Azure IoT Edge on wheels

At Aptus we have already completed several projects where we combine Azure IoT Central with Azure IoT Edge. Recently we realized a new project at Molcy where we pull in and aggregate the data from the CAN bus of their new electric terminal tractor "on-the-edge". This data is then sent to IoT central every X time.

CAN bus, you say, what's that?

Controller Area Network or CAN bus is a robust communication network to allow different components or microcontrollers to talk to each other. Initially it is designed to reduce the amount of wiring. CAN bus also contains the word bus, which means when parts on the bus send something, all other parts on the bus receive this message. A message or frame on the bus always contains small packets of data and can be sent very frequently on the bus. Each part connected to the bus has a unique ID.

Each frame therefore consists of a unique ID and data specific to this component. If we limit ourselves to a vehicle, a few examples on the CAN bus are ABS, brakes, cruise control, electric windows, airbags, ... all reasonably important parts. Actually you can compare the CAN bus with the nerves in the human body.


Why Edge Computing in a Vehicle?

In the context of this project, the customer developed a new "battery-powered" tractor (i.e. a full-electric vehicle). In the long run, the aim is to focus on preventive maintenance. In order to arrive at the right algorithms, we first need to collect data on how the vehicle reacts in which circumstances. In addition to the above objectives, we also want to know how the vehicle is used and especially gain insight into how the battery behaves.

Containers on the edge

An important aspect of an edge gateway in combination with a vehicle is that you want to manage everything remotely. The vehicle should be on the road as much as possible and we want to avoid that the vehicle has to be brought in for software maintenance. What leans very well here is the use of containers on the edge. Each individual software component runs in its closed container and can easily be replaced by a new version without impacting the others.

The entire concept of modules in IoT Central is based on containers. A module or container on IoT Edge can be managed from the cloud. The edge agent makes sure that all modules are started, new versions are started, ...

Image for post

Architecture

For this Edge architecture we made the choice to work with different microservices, each taking up a specific function.

Image for post

CAN Connector

The CAN connector creates the bug between the two CAN buses and IoT Edge. All messages that arrive on the CAN bus are published on the local Edge Hub. Any component that wants to receive these messages from the CAN bus can listen to them.

GPS publisher

The GPS publisher is very similar to the CAN connector but publishes messages with the GPS coordinates at a fixed interval.

CAN decoder

The messages published by the CAN connector are the raw data of the CAN bus. To make it understandable for the other processes, these raw messages are converted in HEX into an object with properties with understandable values.

Aggregator

The aggregator is going to capture the data of the various messages and send them to the cloud at a certain time.

How do the messages go exactly?

Below you can see a visual representation of how the data enters the gateway and how the flow between the different components runs.

Image for post

Offline support

The edge computer runs IoT Edge. It takes care of numerous tasks, including offline caching. This is of course very important in this setup. Since the vehicle is in motion, it often happens that the 4G connection is lost. IoT Edge also supports the buffering of messages when there is no connectivity to the cloud.

This buffering is handled by the Edge Hub, by default the messages are stored for 2 hours after which they are deleted. It is possible to extend this to about 2 million! (wow!) On the Edge Hub it is possible to adjust these settings via the module twin or in the deployment manifest.

"$edgeHub": {
  "properties.desired": {
      "schemaVersion": "1.0",
      "routes": {},
      "storeAndForwardConfiguration": {
          "timeToLiveSecs": 7200
      }
  }
}

If you want the messages to be saved during a reboot, you can also set a path for the Edge Hub to write its data to. In the Edge Hub's container configuration, you need to give the container access to the local storage and the path to the storage folder.

Image for post

How do you manage such a thing?

We talked in detail about the Edge side of this solution but how do you manage such a solution? Here comes the power of IoT Central. IoT Central is a layer of software on various Azure components such as IoT Hub, Digital Provisioning Service, Time Series Insights, ...

Image for post

Everything starts in IoT Central with the creation of a device template, when creating a device template you have to choose between a device or Edge gateway.

Image for post

When creating a device template with IoT Edge you also need to provide the manifest file that defines the configuration of the IoT Edge configuration such as which containers to boot with which settings, ...

Creating a device template in IoT Central is done in a visual way. A device template is defined:

  • What modules there are and what their telemetry data is that will be sent
  • What cloud properties are of the device such as what type it is, where it is installed, ...
  • What visualization is there when you go to a detail page of the device and what settings you can set

Image for post

Adding the device can also be done via IoT Central itself.

Image for post

After adding an Edge gateway, it is automatically provided with the necessary configuration based on the manifest file. Once everything is started, you can click through to the device and follow the telemetry data live.

Image for post

In addition to the above, it is also possible to set rules and perform an analysis on the raw data that comes in.

What are the next steps?

Because of the large amount of messages that pass by on a CAN bus, with the current connectivity it is more difficult to send these messages in real time to the cloud. This functionality would be extremely useful to perform a comprehensive diagnosis of the real-time streaming of CAN messages to the cloud. The perfect technology for this is 5G and has the bandwidth and latency to make this possible. Aptus has already taken the first steps with 5G to validate such scenarios.

If you want to know more about 5G and everything around it, be sure to read colleague Alexander's interesting presentation.

In most cases it is not necessary to send all messages from the CAN bus to the cloud (imagine, capturing 10 messages every 50ms), but one does want to be notified when there is abnormal behaviour. To detect this abnormal, the first steps have already been made towards data capture and the first version of the algorithm that will report abnormal behaviour when it does so.

A next step in that project is also to offer insights to the owner of the vehicle. Here we think of things such as:

  • Loading usage
  • Track and trace of the vehicle
  • Messages from the vehicle
  • Current status
  • Maintenance history

Conclusion

The combination of IoT Edge with IoT central makes the management and rollout of the project perfectly possible. This is one of the many projects in which the knowledge and skills of Aptus comes to the surface. The combination with the Edge processing in combination with the capture of different signals and to combine this in one whole and visualize it in IoT Central.

If you are looking for a party that can support you in implementing the above solution or others, look no further!