Node.js is Viriciti’s Go-to Dev Platform for Real-time Electric Vehicle Fleet Monitoring

Buckle up Node.js fans, this Enterprise Conversation is longer than usual, but oh so worth it. Viriciti, a company focused on electric vehicle fleet monitoring, orchestrates hundreds of thousands of messages per second into real-time dashboards using Node.js, microservices, and serverless. They use Express Gateway, an open source API gateway built on Express.js, to make data available through their API tier. The Viriciti team wrote their own service to support the application for CI/CD in IoT. This device manager, which they plan to release as open source, is based on Buildroot (Linux OS), Docker (App layer), Gitlab (git & Docker registry), MQTT (central configuration & data hub) and of course Node.js to tie it all together.

Our Enterprise Conversation maestro Tierney Cyren chatted recently with Viriciti CTO Simon Rijk and Backend Developer Tamme Thijs to learn more about this classic Node.js Everywhere use case. (Check out the video podcast on YouTube and read the entire transcript below).

Because you might be short on time, here’s the tl;dr.

Viriciti’s tech stack starts with the custom system on a module they put on a PCB, install on vehicles (electric-powered public buses for example) and connect to the CAN line, the main data line. These mighty little devices send between 1,200 and 1,800 messages a second — per vehicle — to Viriciti’s cloud where they aggregate and convert this data into real-time dashboards and alerts.

Explains Rijk “this data line is like one big source of information where electric components can put data on and get data off. For example, if you accelerate, it will be put on the CAN line. The battery system, the battery management system is also connected to this CAN line. So, it posts data there about all the currents that are flowing through all the modules, and the cells, and all the temperatures, and all the voltages.”

Viriciti transforms the data into usable engineering units and provides back a real-time representation of what that vehicle is currently doing. Is it driving? Are the doors open, closed? What’s the temperature? What’s the RPM? What’s the GPS location, and all the battery, and the currents, and the voltages. Every time something changes, whenever there’s a new data on the CAN line or it actually changed, we can send over this data.

Viriciti’s microservice-based Node.js web interface is designed so that the user can follow specific vehicles and get real-time information on everything going on with them. The Node.js platform will find the vehicle, subscribe to the data — GPS data, state of the charge, errors, warnings etc- and instantly establish a real-time flow between that vehicle and what the browser. In addition to the real-time dashboards, Viriciti also computes and reports on things like estimated range based on the state processes.

And when Viriciti wants to leverage their vehicle-based device to surface a new piece of data, say a mechanical aspect of the vehicle, they use a custom CI/CD device manager to update the on-board software. This device manager allows them to extend their agile, container-based continuous delivery model to their embedded devices.

Node.js is Viriciti’s go-to development framework because of its JavaScript-inherited event-driven design, the massive ecosystem and “Everywhere” hardware support. In Rijk’s words “really important for us was connecting to hardware, connecting to serial ports, connecting to GPS devices using the modules that are out there. They all compile to our architecture, and being able to get that information straight into the V8 virtual machine was also really awesome, and a big reason for our choice for Node.js on the hardware side.” Node.js fits perfectly with Viriciti’s continuous development approach, which requires rapid iteration.

Watch for the Viriciti team to expand their API tier by leveraging Express Gateway. Tamme Thijs explains “Express Gateway provides you the perfect tools to create your own API Gateway in Node.js. It’s a thin layer on top of Express.js. For our new chart station domain, we build our own API Gateway in Node.js using Express Gateway. You can completely customize it, much like you write middleware in Express. The gateway entities, like pipelines and plugins that you use to customize the internal logic, these are just wrappers around Express Middleware.”

They are also investigating how to take advantage of advances in machine learning and big data to provide even more useful and predictive insights to their customers. And last but not least, they plan to open source some of the tech they’ve built to manage their embedded devices.

Tierney Cyren: Thanks everyone for coming to today’s enterprise conversation. We have with us two individuals from ViriCiti. Do you guys want to introduce yourselves?

Simon Rijk: Yeah, it’s Simon, CTO from ViriCiti, founder and my colleague Tamme Thijs.

Tamme Thijs: Hi, thanks for having us. I’ve worked at ViriCiti for the last five months as a Backend Developer, and I mainly focus on our API design. So, how do we expose our data to the clients and also internally between the services.

Tierney Cyren: Yeah, awesome.

Tierney Cyren: What are your roles with the company? Within the company, what do you do day-to-day at ViriCiti?

Simon Rijk: Right. Well, I’d say my main role is to make sure that our business and our architecture remains scalable, flexible, is easy to adopt new technologies, and is easy to update to Buck fix and to scale. Make sure that any competition, any new kid on the block could not compete due to choices that we are currently constantly making. I consider that my role, and with that I try to address as much people in the organization also thinking about it. Especially my IO, or the developers basically, to let everybody know what is important to ViriCiti.Let everybody also come up with great ideas, with new ideas on technology and how to use it.

Simon Rijk: Together we try to make the best move there, whilst still enabling our customers with new features and extending there. So, it’s broadening up, beginning up the market that we are in, which is expanding. Making sure that we not run into bottlenecks, but at the same time also extend our functionalities to become a way, more complete products, and more complete proposition in the business that we work for. That’s for electric vehicles and the operation of them.

Tamme Thijs: I mainly focus on the backend of our services. We have a lot of services, they all expose data. We have our own clients with web apps and mobile app. We also would like to expose this data to third party clients.

Tierney Cyren: You mentioned electric vehicles. Can you elaborate a bit on that?

Simon Rijk: What everybody knows is that it’s cheaper every mile. This is especially interesting for public transport or even trucks. For public transport you have a more controlled atmosphere where these vehicles are operating in. Although the main drawback is initial investment. Electric vehicles are more expensive, especially due to the battery technology, and the amount of energy that you can carry around is way less.

Simon Rijk: You could say you bought an iPhone 10 with a really bad battery in it, and you need to energy manage that thing during the day if you don’t want it to stop working. Even worse, every day your energy consumption can vary due to environmental influences like the weather. If it’s colder you have to turn on your heater, your heater will draw the energy from your battery. That’s the same energy origin where you also need to drive your miles with. Your routes could change, it could be more. The traffic could be different from day to day, so your energy consumption can differ, and that makes operators not want to transition into sustainable transport like electric vehicles.

Simon Rijk: This is something we try to resolve, we try to take that drawback away of not knowing when your battery actually depletes. In order to transition and to speed up the transition from combustion engines to where it’s electric vehicles. On one end we are supporting the financial incentive there that it is actually cheaper, the amount of maintenance is lower, the amount of energy cost per mile is lower. So, there is a turning point where it becomes more cheap, although you’ll have to really facilitate it with a really good monitoring system. That maybe even talks back to the vehicle and influences the energy consumption in order to maintain the objectives that the vehicle need to do during the day. That’s also where we try to optimize and save costs.

Simon Rijk: Now, this is all from a vehicle perspective and vehicles are an energy user. On the other hand we have a charging infrastructure. If you have 40 vehicles driving around, you also need to charge them. If they all charge at the same time or if there is a queue in front of the charger, this is all not what you want. Especially energy peaks in a network can be very costly for companies. You have to really pay for them. So, also charging, providing the energy to the electric vehicles needs to be a part of the equation that needs to be optimized. So, that’s basically what ViriCiti is all about.

Tierney Cyren: How do you help solve that problem. Are you aggregating the data about electricity usage and then individual vehicle usage, and then surfacing that to companies who are using electric vehicles? You’re trying to help solve that problem of understanding these bits of it? I’m I right in that?

Simon Rijk: So we have created our own piece of hardware, which is just simply… You can buy these days this system on a module. It’s basically a small computer. It sits on something that looks like a piece of RAM, right? Just like a DIMM, like that. You put it on a PCB, and then you connect the main vehicle data line to it. The main vehicle data line is a Bus where all electric components inside a vehicle post whatever they are doing and whatever information they’re creating, but they can also subscribe to other data.

So it’s like one big source of information where electric components can put data on and get data off. For example, if you accelerate a pedal, push down, it will be put on the CAN line. For example, the power train sees it and knows, “Hey, I need you, accelerate to a certain speed.” It will do and comply. The battery system, the battery management system is also connected to this CAN line. So, it posts data there about all the currents that are flowing through all the modules, and the cells, and all the temperatures, and all the voltages.

All of that information is available, so we connect to this line. It is behind the firewall, so we mostly connect it to a diagnostic line, as it’s called. All of this data, it’s like 1200, 1800 messages per second, is being streamed to our cloud. Of course, we do a few optimizations there but there is an active web-link between the vehicle and our cloud system, where every vehicle has its own little state process.

There, the CAN data, as it’s called, is My data as it is going in, we transform that to actually engineering units. So you can understand them, but because they’re in the cloud, they’re basically a realtime representation of what that vehicle is currently doing. Is it driving? Are the doors open, closed? What’s the temperature? What’s the RPM? What’s the GPS location, and all the battery, and the currents, and the voltages? So every time something changes, whenever there’s a new data on the CAN line or it actually changed, we can send over this data. This ties very close together with choosing Node.js as an event-driven platform.

So, this web-link is always maintained and it’s always connected to its state process. If you’d have 40 vehicles, you’d have 40 state processes, and they could all publish their data as well. Now, if I want to make a web interface that for example follows this vehicle and all the parameters that come off of them, I just build a small microservice based on Node.js. I’ll make sure it can respond to web circuit request. So, we’ll have an active connection from the browser to that surface. That surface for example gets the request, “Hey, follow this vehicle.”

So within our framework, it will find the vehicle, it will subscribe to the data that for example your nephew needs. The GPS data, the state of the charge, maybe some other data like errors and warnings. Instantly, a realtime flow is established between what that vehicle is currently doing and what you’re seeing in the browser. Now, this is a realtime feature which is great and it’s nice, but you want to be able to act upon it. So, we have other surfaces that request for example estimated range from this kind of state processes.

If estimated range goes beneath a certain threshold for that route, it can trigger an alert to anyone. To an operator or send an SMS, or that kind of stuff. We can do more, we can do computations in other processes, and the outcomes of that could go back to the vehicle. That could be written to the CAN line again to influence, for example, the driver dashboard. To show the driver how he’s currently behaving, or if he should charge, or if should maybe even skip a charge because he is late on his schedule.

Tierney Cyren: Awesome. I think that really goes well into the next topic we wanted to discuss about, which is the use of Node.js. It does seem like you’re using that to aggregate the data or process the data, and then show it to the end user or the person who is a controller of these fleet of vehicles. So, yeah, I’d definitely be interested more in the specific use case you have. You mentioned microservices and you mentioned a web dashboard. I’m curious to know a bit more about that implementation, your usage.

Simon Rijk: Do you know Resin.io?

Tierney Cyren: I think, yeah.

Simon Rijk: It’s basically a platform that ties together with the Docker layer. Basically what you could do, is you can make a small process that continuously checks if the ride so varies, for example running on your vehicle. With this you can always, after market, after your sale has been done, update your applications, make them better, make them web free, or maybe add a feature in the future.

Maybe you haven’t realized yet that you want to also control or connect to some kind of machinery in the vehicle. You can later do that because you’re using basically something with the Docker layer and the containers that are running in it, and a small process that controls them. Also, the operating system itself needs to be updated. When you create, so as we call it, a data hub, we also saw that the micro services approach is not just for frameworks, and not just for sucker packs or cumulative stacks, but also for basically hardware inside a vehicle.

That’s a pretty nice approach for us, so we can always be more extensible and more secure than the competition. So this is hardware side. Where were we going? So I already explained to you the realtime ness of part the framework. Obviously we are also on the slide doing analysis, and also aggregate that data into our more to be database surface. This is where you can … For example, if you have a feature like ‘Download all your reports’, like what asset has been in underperforming with for example a kilowatt hour usage. That’s per mile, that’s lower than a certain threshold.

Well, basically you have a source of the accelerometer that’s on our hardware. You can also say, “Where is the driver that I have and how can I help him improve his driving behaviors?” Because as you know, driving electrically is not just about the way you cruise or the way you accelerate, but also if you do regenerative braking. We can access that through the same data source, that’s nice. ‘Reporting to’ is out there, but also ‘Exports’.

Currently we do that serverless. If you want to download wherever your vehicle has been, and what all the error codes were, and what your battery has been doing all the time, you’ll need a lot of time series data, which we manage through the serverless part. Yeah, this is all kinds of things, how you can for example make reports, and see where your operation is actually going.

Tierney Cyren: That’s super awesome.

Simon Rijk: At the same time we are also stepping into live feeds like routes, route information, route changes of course. Also, overtime, where is the vehicle on that route? What is the current schedule for this vehicle today? Is the driver behavior influencing or is it creating any, yeah, I won’t say sweet spots? Or basically in the charging strategy, is it still compliant with how the energy drainage of this vehicle is currently going? Those are all questions that we try to answer for a customer.

Tierney Cyren: Awesome. I think there’re kind of … Some of the bits in each of these, discussion, lead to the next topic, which is why did you choose Node.js? The playing with Docker, onto the IoT devices, and then using it in the cloud to manage and process and output data, and then using it in the cellular space. I’m curious to see now what the decision was behind choosing Node.js and what lead you to the path of Node.js. You mentioned it with the event-driven model?

Simon Rijk: Yeah.

Tierney Cyren: Yeah, I’m curious to hear your input on that.

Simon Rijk: Yeah, exactly. Yeah, before using Node.js I was a PHP developer. When starting this company we could think of at least new tools and something that seemed like extensible. That time yet Node got .10, I believe. Yeah, that’s five.

Tamme Thijs: That was five years ago.

Tierney Cyren: Oh, well. Yeah, you’ve been around a while.

Simon Rijk: Event-driven and the non IO blocking promises, but especially the event-driven was key for us. We had no clue how much data we would process, but we wanted to be extensible at the same time. We could have chosen Java, but I don’t think we could have had and maintained the fast iteration cycles and the reduction of complexity. Node.js just provided the tools to prototype really, really fast, but that was during the prototyping stage. It turned out that in production it would even scale well as well. We never had any regrets on choosing Node.js.

Tierney Cyren: 2000?

Simon Rijk: Yeah.

Tierney Cyren: One of the things I’m interested in is you said you started around Node.js .10, which was I think three, four years ago at this point, maybe up to five. Back then, were you thinking about doing the IoT side of it? Were you doing the IoT side of it with Node.js? Or was that a down the line decision that, “Oh, hey, this also works here.”?

Simon Rijk: Node.js was our choice and was our go-to language. Also, for the hardware side, at that moment we didn’t have any funding or whatsoever, so we had to do off-the-shelf vehicle computers that would just run Ubuntu Linux or something. They would supply them with and then they would run a small Node.js program to handle all these kind of messages and to stream them to the cloud.

Simon Rijk: We just didn’t know how CPU intensive it was going to get, but we knew at that moment the design of our hardware was not modular, it was not really extensible. We had no good ways to update the operating system that basically could lead to really big problems in terms of scaling. We just wanted to make a really small Node.js program, we wanted it to be streaming as well. We found streaming API very important argument as well for doing that part of the job at the time.

Tierney Cyren: That’s awesome. Again, that kind of leads to the next topic which is, how has Node.js helped your business grow and what have been the benefits to the actual business side of the company in terms of growth and success?

Simon Rijk: Yeah, that’s a good question. I think versatility, the amazing amounts of modules that are out there. You want to use a GPS … Oh yeah, I forgot to mention, what was also really important for us was connecting to hardware, connecting to serial ports, connecting to GPS devices using the modules that are out there. They also basically compile to your architecture, and being able to get that information straight into V8 virtual machine was also really awesome, and also a big reason for our choice for Node.js on the hardware side.

Simon Rijk: Basically for the rest of our framework, how did it help impact our business? We were always able but that also ties a little bit with the choice of microservices. We were always able to migrate or to shift towards where we wanted to be. We could always make changes, make small changes and make them fast by basically changing our Node.js script. The adaption of our new employees was also super fast in that sense. We do a lot of internal training to get young, enthusiastic guys from university to really work in a project where you have to put Node.js to the text. Put it actually in prediction and it actually needs to work there.

Simon Rijk: I’d say, for example, half a year ago, I decided we also had to do chart stations. Monitoring them, making a scalable framework for the chart station side with all their messaging and all the commands that you have to send back and stuff, protocols that you have to implement. With the knowledge that we have, and the tool sets, and Node.js, we were able to kick this off to a full-fledged production tool for different stakeholders. It runs, and it scales. It’s amazing.

Simon Rijk: People that were used to all the back offices for chart stations didn’t know what they saw. They saw realtime things happening in their browser, they saw messages coming in, they saw errors coming in. That currently gives us a very good upside in terms of the competition.

Tierney Cyren: That’s super awesome.

Simon Rijk: Yeah, I’m so happy.

Tierney Cyren: Cool. Great. Final thing I want to talk about, what’s next for your use of Node.js? Where are you going with this? This doesn’t necessarily have to be technical, it could be engaging with more developers, contributing back, contributing to the ecosystem, coming to more events? I’m just curious, what’s next for your usage of Node.js?

Tamme Thijs: Well, currently in ViriCiti we’re working on improving our API. Like we mentioned before, we have a lot of microservices, they all need to expose some data to the outside world. We just launched a new domain with the chart stations, and it was time that we got our own API Gateway. Well, everybody that uses Node.js knows Express and there’s actually a really cool, new project. Relatively new, it’s called Express Gateway, and we investigated it.

Tamme Thijs: Basically, what it does, is that Express Gateway provides you the perfect tools to create your own API Gateway in Node.js. It’s a thin layer on top of Express.js. For example, for the new domain, the chart station domain, we build our own API Gateway in Node.js using Express Gateway. You can completely customize it, much like you write middleware in Express. The gateway entities, like pipelines and plugins that you use to customize the internal logic, these are just wrappers around Express Middleware.

We were able to use our in-house knowledge and even sometimes ready module we have, we could incorporate them in this new gateway. Yeah, we’re right now in production with a fully functional API Gateway that we waited forever to put them in Node.js. I think that’s really cool. I think it’s pretty awesome.

Tierney Cyren: It’s awesome.

Simon Rijk: Yeah, that’s super. Other things, so the device manager that we currently have that allows you to update and upgrade and add to remote devices and considering apps. We are currently in the process of open sourcing it. Mostly because we have two sister companies that would love to use it, but also as a nice, first attempt and trial to see how yeah, open sourcing works.

We have few modules open sourced but if you don’t know what they’re used for or how to use it, they don’t really get traction in the MPM infrastructure. Yeah, we are currently also looking into more open sourcing these kinds of products and see how that goes.

Tamme Thijs: I think that’s also a big strength of using Node.js. It’s like the whole module and ecosystem around its npm is amazing to work with.

Also, if you want to open source your own or use other. It’s amazing.

Simon Rijk: We use library for our Kafka messaging. It’s so easy to just add to it, contribute, and also file issues, and it’s been picked up well.

It’s quite amazing. What we’re currently doing with Node.js is pipelining all the data that we have into our machine learning models. We are now also training models to even better distinguish all the attributes of what an energy usage within a vehicle is actually composed of. How to take them apart, being able to with the weather forecast, and what driver is driving, you can predict better what will happen on a day.

Especially currently when for example, sometimes temperature just drops. For example, last winter we had a bad winter and then at some point it got really, really cold. Then you saw the energy consumption of vehicles go up, and there were problems with some of these electric operations of municipalities. We really had trouble there, so we need to also incorporate our machine learning way more to also compensate for that. Yeah, that too, Node.js helps more.

Tierney Cyren: I was a bit curious, what kind of platform or tooling are you using for machine learning with your data?

Simon Rijk: In the end it would go through TensorFlow.

Tierney Cyren: I think with that we can probably wrap up. Anything else you guys would like to add.

Simon Rijk: No.

Tamme Thijs: No.

Tierney Cyren: Okay. Awesome.

Simon Rijk: Thanks for having us.

Tierney Cyren: Thanks for coming on. I appreciate it and we will hopefully see you again soon.