The topic I want to deal with today is in the context of Smart Mobility, but also the Internet of Moving Things.
What do I want to write?
I would like to examine and discuss with you how, based on Oracle IoT Cloud Service, you can implement a Vehicle Fleet Monitoring system, such as a fleet of public transport buses, or a company’s fleet of vehicles, for example for car sharing.
But, as you will see, the system could easily be extended to other mobile means, which are able to provide in real time their GPS coordinates, such as trains and ships.
Such a monitoring and management system could have the following functionalities:
- Show in real time the position of any vehicle in the fleet;
- Say which is the last message received by a vehicle and which is the last known position;
- Register if a vehicle has left a demarcated area on the map, or if it has entered a delimited area;
- Register if a vehicle exceeds a certain speed, or if it has been stationary for a long time;
- Register if the engine or the on-board instrumentation signals an anomaly;
This is just a list of the main features, but of course we can think of others.
Specifically, in this article, I also want to tackle a topic that is more technological and less tied to business functionalities, which often occurs when we have to deal with a set of vehicles with “old” devices, that we want to integrate into a new IoT solution, and we cannot modify them and they do not use modern IoT protocols.
In IoT, the theme is often labeled with the term “retrofitting”. The device is not able to speak directly the language of a modern IoT Cloud and therefore we have to introduce “an intermediary”, a Cloud Gateway, which translates the native protocols of the devices into those supported by our Cloud.
Finally, the article can also be used from another point of view: we want to better understand how it is possible to create the software for a Gateway that must be connected to the Oracle Oracle IoT.
In the article, in more detail, we will examine two different cases:
- A Cloud Gateway that supports incoming messages based on the HTTP protocol;
- We will see how to extend the gateway in order to support, in input, the MQTT protocol.
Many solutions born in the pre-IoT world, when for example the acronym M2M was used, are based on the HTTP/S protocol for the communication between device and server-side solution. Today, in IoT field, the MQTT protocol is more and more adopted, due to its superior efficiency and reliability.
The implementation presented here was born for a Proof of Concept (PoC) for a specific customer, in which case the protocol used by the vehicles is HTTP and the application message consists of a string of characters, with a defined format.
Then, at a later time, I have extended the Gateway to support the MQTT protocol as well.
All the code is made available in the GIT repository.
The overall architecture of the solution is shown in the following picture.
It is hypothesized that:
- The Cloud Gateway runs inside a first virtual machine (VM), distributed in Oracle Cloud Infrastructure (Oracle Generation 2 Cloud, OCI);
- The Visualization Server, based on an OpenSource (Traccar), runs in a second OCI VM;
- Support for the MQTT protocol requires an MQTT broker (shown in blue), which is assumed to be distributed in the same VM of the Gateway.
Obviously, alternative distributions could be considered. For example: deploy the Gateway, Visualization Server and Broker in three Docker containers, orchestrated via Kubernetes (K8S), or Docker Compose.
Regarding the dependencies on external components and modules:
- The Gateway is distributed in a single, self-consistent JAR file;
- To support the MQTT protocol, as mentioned above, the Gateway requires a broker MQTT, accessible via the network, preferentially located on the same host of the Gateway;
- The Gateway must access the Visualization Server and the IOT Cloud Service via the network.
The arrow coming out from Oracle IoT Cloud Service represents other possible integrations, for example via HTTPS protocol, with Enterprise Applications (it is a built-in functionality in Oracle IoT CS).
Open Source and other libraries.
The gateway is implemented in Java.
The build and packaging of the entire project (developed using the Eclipse IDE, of course) was made using Maven.
To support HTTP protocol, I have used Eclipse Jersey and the embedded HTTP listener used is Grizzly.
To support the MQTT protocol it is necessary to run, in the same VM where the Gateway runs, an MQTT broker (listening on port 1883). In my case I have adopted Eclipse Mosquitto: a simple and lightweight MQTT broker, but perfect for my purposes. Obviously, you can use any other MQTT broker, which supports version 3.1.1 of the protocol.
The Java code implementing support for MQTT protocol uses the Eclipse PAHO library.
As a Visualization Server I have used Traccar, an Open Source server built entirely in Java. Communication between the Cloud Gateway and Traccar employs the OwnTracks protocol.
Integration with Oracle IoT Fleet Monitoring.
In the overall solution I also considered an integration with Oracle IoT Fleet Monitoring (FM).
The integration is native, it is sufficient to register the vehicles in Oracle IoT Fleet Monitoring and it automatically create the definitions for the devices in Oracle IoT core. You need also to register the device model that will be used to model data transmitted from vehicles to Cloud.
The integration allows you to use the visualization features of Oracle IoT FM.
It also allows you to implement, in a simple and effective way, functionalities such as the ability to define demarcated geographic areas (GeoFence) and to define Alerts that are generated when a vehicle enters or exits from such an area.
Many solutions are possible to display the real-time position of vehicles on a map.
One, briefly described in the previous chapter, is based on the use of Oracle IoT Fleet Monitoring.
In the PoC I have also explored the features deriving from the use of Traccar: a modern free and OpenSource GPS tracking system. Another interesting element of evaluation is the fact that Traccar uses the OpenStreetMap maps.
Traccar supports an impressive number of GPS devices. But, in my case, I exploited the possibility of a server-side integration, using the support that Traccar offers for what they call the “OwnTracks” protocol.
In summary, the Gateway is able to transform incoming messages (both via HTTP and MQTT) into the format defined by the “OwnTracks protocol” and send them, via HTTP POST to Traccar.
The following figure shows, as an example, a Traccar screen with the display of the position of two vehicles (in yellow).
Sending messages from vehicles is mediated by the Cloud Gateway.
Therefore, the only module that has a direct trusted relationship with Oracle IoT Cloud Service is the Gateway.
The Gateway must be registered as a device in Oracle IoT and the provisioning file, produced during registration, must be accessible to the Gateway, together with the password protecting its access.
Communication between Gateway and Oracle IoT is made secure, encrypted (using TLS 1.2), using Oracle IoT’s mechanisms.
The mobile devices (vehicles) communicate with the Gateway, which then, on their behalf, sends the messages to the IoT Cloud.
It is the Gateway, employing the Oracle IoT SDK, which is responsible for sending messages securely and on behalf of the devices.
Obviously, in order to have an end-to-end security, appropriate to the context, communication between the device and the Gateway must be protected.
In the code available today on the project GIT repository, no security mechanism is implemented for this last aspect. Obviously, there is a whole set of security measures that can (and should) be adopted: from encrypting and protecting communication between devices and gateways through TLS, up to implementing mechanisms for identifying and authenticating mobile devices.
All Java sources are contained in the project’s GIT repository.
Sources are available and can be used, as part of the license adopted: MIT.
Insights on implementation.
The project was born to support the HTTP protocol. Data from a vehicle (location, speed) is sent via an HTTP POST.
The choice we made is to manage the protocol using Eclipse Jersey.
The project was created using a Maven archetype, from Eclipse Jersey site.
The AVMResource class contains the doPost () method that handles the HTTP request from mobile devices.
The method after verifying that the parameter passed in the request is correctly formed invokes, in order:
- The send() method of the IoTGatewayClient, to send the message to Oracle IoT Cloud;
- The sendToVServer() method of TraccarClient, to send data to the Visualization Server, based on Traccar.
The logic that transforms and sends data to Oracle IoT C.S. it is encapsulated in IoTGatewayClient.
IoTGatewayClient uses the Oracle Virtualization API for Gateways.
The method that handles sending messages to Oracle IoT is the send () method.
This method performs a “lazy registration” of the devices (which logically correspond to the vehicles).
The method uses a Hashtable (hDevices) to contain (key, value) pairs, where the key is the vehicle ID and the value is the virtualDevice. If the element related to the device is not found, the device is registered and the item added.
The virtualDevice is the handle to change the status of the device and then send the messages, with the new status, to Oracle IoT CS.
Obviously, the class supplied is a prototype to be refined for a real implementation to be used in production.
The DeviceModel is now hard-wired. In the case we used “ora_obd2_device_model”, but for now we really only use the fields to store latitude, longitude and speed.
Parsing of the string that contains incoming data is done by the ParserDati class.
To subscribe to the MQTT protocol, a subscriber has been created, using the Eclipse PAHO library.
The class that implements the subscriber is AVMMQTTSubscriber.
In the current implementation, the subscription is made on a single topic. You could use a topic hierarchy using the wildcard mechanism.
After receiving an MQTT message, the logic followed is similar to that followed in the case of the HTTP protocol. In this case too, the following are class used to send messages to the backend systems: IoTGatewayClient and TraccarClient.
In (little) free time, I’m working on a distribution based on Docker containers and Docker Compose: the MQTT broker, the Visualization Server and the Gateway are distributed in three distinct Docker containers. In this way it is possible, for example, to easily add Grafana and Prometheus to monitor the infrastructure.