Monitoring and control of vehicle carbon emissions with EcoLogic

26 Feb 2019

Index

Abstract
System design
Hardware
- Arduino
- RaspberryPi
Cloud μ-services
Conclusion and future work

Abstract

Today, the electronic devices such as sensors and actuators, forming the Internet of Things (IoT) are presented naturally in the people’s day to day life. Billions of devices are sensing and acting upon the physical world and exchange information. All major industries like transportation, manufacturing, healthcare, agriculture, etc. adopt IoT solutions. Not only people and industry are affected in a positive way by IoT, but also the nature and environment. The IoT is recognized as a key lever in the urge to save the climate. It has a major potential in reducing air carbon emissions and polution. Taking into account the promising sectors of IoT application, i am presenting a solution for monitoring and control of carbon emissions from vehicles. It consists of hardware device that ingests data related to vehicle’s carbon emissions and cloud based services for data storage, analysis and representation. It controls the carbon emissions via notifications and vehicle’s power restrictions.

System design

The EcoLogic system is composed of two big parts: hardware modules and cloud-native microservice applications. The hardware modules are located in vehicles and the microservice applications are deployed on a cloud platform. The architecture of the system is shown in Figure 1 and 2. The history of physical computing technology showed us that each physical computing system contains at least one hardware device, but nowadays the Internet of Things paradigm, which extends the physical computing technology, is showing us that except hardware devices each IoT system should use also Cloud or Fog platform, which enables massive scale, reliability and efficiency. It becomes a standard for IoT systems to incorporate Cloud and Fog computing platforms in its architectures as main components that give a lot of benefits like enormous computing power for artificial intelligence algorithms, including machine learning and data mining, high availability, disaster recovery, big storage and near real-time speeds.

The hardware module of the system has sensors and measures several physical parameters. It can also extract parameters from the onboard diagnostic system of the vehicle. The data is sent to cloud-native applications in the cloud platform. The measured physical parameters are:

Air/fuel ratio, which is measured by lambda sonde sensor, which is located into the exhaust system of the vehicle.
Absolute pressure of the air that is consumed by the engine, which is measured by sensor located in the air intake manifold of the vehicle.
Temperature of the air that is consumed by the engine, which is measured by sensor located in the air intake manifold of the vehicle.

The cloud-native applications are implemented as microservices, which are designed in a platform agnostic way in order to have the possibility for deployment on different cloud platforms. The cloud applications store data in a relational database, which is represented by backing service from the cloud platform. They process the incoming data, store it into the database and analyse it. The hardware modules communicate with the cloud with wireless network via HTTPS or MQTT protocols. The following physical parameters are calculated on top of the incoming sensor data:

Mass of the consumed air by the engine.
Mass of the consumed fuel by the engine.
Mass of the carbon dioxide emissions, exposed into the atmosphere.

The database contains all measured and calculated physical parameters. A cloud-native Analytics application executes an anomaly detection on the streamed data and outlines vehicles that have not optimal amount of carbon dioxide emissions or system failures. Clustering analysis is made in order to detect anomalies. The hardware module is notified when some vehicle is detected by the system as an anomaly, with suboptimal amount of emissions. Then the hardware actuator is started automatically to reduce the amount of emissions. This comprises a feedback control loop. In this way the system monitors and controls the amount of carbon dioxide emissions in the atmosphere in real time. The hardware modules are equipped with three actuators:

Liquid crystal display (LCD), which visualize the measured and calculated physical parameters to the driver.
Light-emitting diode (LED), which indicates to the driver that the amount of carbon dioxide emissions is not optimal or there is a system failure (not optimal parameters).
Actuator, which controls the amount of injected fuel in the engine and regulates the amount of emissions.

Currently, only the display and LED actuator are implemented in EcoLogic. The purpose of the LED actuator is to notify the driver to intentionally reduce the acceleration and change the driving behaviour, which leads to reduction of the amount of burned fuel and emissions.

The cloud applications provide web user interface, on the base of HTML5, JavaScript and CSS resources. It’s endpoint is publicly available and accessible by clients via HTTPS protocol.

The user management of the system is composed of two roles: driver and operator. The lifecycle of the system is the following:

Dealer sells a hardware module to a driver.
The driver installs the hardware module into vehicle. This step can also be accomplished by an authorized service.
The driver registers the vehicle with the hardware module and sensors via the web user interface. All components have unique identifiers.
Drivers are authorized to monitor and control their own registered vehicles.
Operators are authorized to monitor and control all registered vehicles by regions.
Each driver gets score points proportional to the amount of carbon dioxide emissions exposed in the atmosphere from their vehicles.
The score points can be integrated with tax systems of countries and city halls. In this way the taxes can be reduced proportionally to the score points. Drivers can also participate in greenhouse gas trading schemes with their score points.

Important aspect of the design of the system is it’s security. Security is major problem in all IoT applications, because of the big number of heterogenous devices, the data, which is distributed across many locations and the need for high-speed communication. New protocols and schemes that incorporate symmetric and asymmetric cryptography are developed in order to resolve these problems. The current system uses TLS v1.2 protocol with it’s built-in asymmetric and symmetric cryptography for the network communication between components.

Hardware

The embedded hardware system contains two embedded subsystems: Arduino Uno and Raspberry Pi 3 B+. The Arduino operates on the low-level hardware sensors and actuators in the vehicles, while the Raspberry Pi works on higher level. It aggregates the data from the low-level hardware and communicates with the cloud platform in bidirectional way.

Arduino

The Arduino Uno embedded system has the following capabilities:

Measure physical parameters of internal combustion engine.
Visualize the measured parameters on 4x16 liquid crystal display.
Control of actuator (light emitting diode).
Communication with Raspberry Pi embedded system.

The physical parameters are measured in two ways: by sensors or extracted from the onboard diagnostic system (OBD2), which is provided by the electronic control module of the vehicle. If the onboard diagnostic interface exposes the necessary parameters in the Application Programming Interface (API), no additional sensors will be installed in the vehicle. If the onboard diagnostic interface API does not expose the necessary parameters, additional sensors, which measure these parameters, will be integrated. There is also a possibility to reuse the already existing default sensors of the vehicle. In this way the hardware module is flexible and can be installed on huge amount of vehicles.

The Arduino embedded system has deployed application in its local storage and executes it. The application is implemented on the C++ programming language. It is publicly available and can be downloaded from the following location: vehicle-monitor-controller-hw-controller source code. The repository from the link contains information for the build, deployment and execution on local Arduino-based hardware module. The application consumes Wiring library, which is part of the Arduino SDK (Software Development Kit). The Wiring library executes on the concrete Arduino microcontroller via drivers. Currently, the Arduino Uno hardware is used, which has Microchip ATmega328 microcontroller based on RISC architecture. This hardware module executes a critical calculations from physical sensors in real time. This is the reason why it’s a separate module with own independent computational resources and with software application written in fast low-level programming language like C++.

RaspberryPi

The Raspberry Pi B+ embedded system delegates the communication between the Arduino embedded system and the applications in the cloud platform. Its architecture is shown in Figure 3.

The communication between the Raspberry Pi B+ embedded system and the Arduino embedded system is via serial UART (Universal Asynchronous Receiver/Transmitter) protocol with a custom application messaging protocol on top of it. The Raspberry Pi B+ embedded system is connected to the cloud platform via 4G broadband cellular network. The measured physical parameters by the Arduino embedded system are ingested into the Raspberry Pi B+ embedded system, which caches them in a local cache storage for further processing and sends them to the cloud platform. It sends the data to the cloud platform via HTTPS or MQTT protocol. The Adapter cloud-application is the facade, which is the only endpoint seen by the Raspberry Pi B+ embedded system. When it sends the data to the cloud platform, it receives response that contain information about the state of the vehicle, including the amount of the carbon dioxide emissions. There are two possible states: optimal (eco) and not optimal (not eco). The Raspberry Pi module notifies the Arduino embedded system once the emissions are not optimal. Then the Arduino embedded system activates the low-level hardware actuator in order to reduce the quantity of emissions. The main component inside the Raspberry Pi embedded hardware is the System on a Chip (SoC), which is using ARM architecture and Linux based operation system, currently Raspbian. It executes the V ehicleAgent application, which is implemented in the Java programming language and it runs on top of a Java Virtual Machine. The VehicleAgent application is publicly available and can be downloaded from the following location: vehicle-monitor-controller-hw-proxy source code. The repository from the link contains information on how to build the application locally, how to deploy it on any Raspberry Pi-based hardware module and how to execute it.

The VehicleAgent application depends on the Pi4J and WiringPi libraries, which support the serial communication between the two embedded systems. An USB WiFi adapter is used for the 802.11n communication between the Raspberry Pi embedded hardware and a hotspot, which provides the 4G broadband cellular network to the cloud platform. The adapter is connected to one of the USB ports of the Raspberry Pi. The communication with the cloud platform can be achieved by several application layer protocols: HTTPS or MQTT. The decision which protocol will be used is taken according to the supported protocol by the cloud platform. The modular architecture of the application enables easy extension with other application layer protocols. Because the communication network to the cloud platform is constrained it is expected to exist glitches and that’s why the application caches the latest data in the local cache storage. After successful reestablishment of the connection with the cloud platform, the application retries to sent the locally cached data. The application can be configured by configuration file (config.xml), which is located into the local file system storage. It contains unique identifiers for the vehicle, sensors and type of the communication with the cloud platform (HTTPS, MQTT, etc). The driver or operator, who registers the vehicle into the system, should populate the configuration file and save it.

This hardware module serves as a communication proxy and need to have capabilities to work with a lot of communication networks and protocols. This is the reason why it’s a separate hardware module, which can work with many hardware adapters or antennas supporting different communication networks. The software application is written in high-level programming language like Java, because it needs to work with many communication protocols and serialize data in different formats.

The whole hardware diagram with connections between Ardiono and RaspberryPi can be seen in Figure 4.

Cloud μ-services

EcoLogic is composed of several cloud-native micro-service applications, namely Controller, Adapter, Web user interface and Analytics applications. Each application is described below.

Controller application

The Controller application is the main cloud application, which manages all vehicles with their hardware modules and sensors, make calculations, persists data into database, executes artificial intelligence algorithms on the data and provides HTTP REST API. It is implemented using the Java Enterprise Edition programming language using JPA and Apache CXF services framework. The Controller application is publicly available and can be downloaded from the following location: vehicle-monitor-controller-backend source code. The repository from the link contains information on how to build the application locally, how to deploy it on a web container in any cloud platform or local server and how to execute it. The application has the following functionality:

Compose a data model, which has the following relations: users, which have vehicles, which have sensors, which have measurements of physical parameters.
Orchestrates the lifecycle of all users, vehicles, sensors and measurements.
Persists the data into a relational database, which is provided as a backing service exposed by the cloud platform. The application is database-agnostic, which means that it can work with any relational database, which provides Java connectivity. If it does not provide Java connectivity, an adapter can be used. The database is composed of four tables: User, Vehicle, Sensor and Measurement. You can see the whole DB model in Figure 5.
Calculates the total mass of the carbon dioxide emissions disposed into the atmosphere by vehicles.
Manages the state of each vehicle: optimal (eco) state and not optimal (not eco) state. This is a simple state machine with two states.
Calls the API of an Analytics application, which executes clustering analysis and anomaly detection. The purpose is to find vehicles, which have not optimal amount of carbon dioxide emissions per region.
Provides HTTP REST API which is used by the Adapter applications and web user interface.

Adapter application

The data coming from the vehicle hardware modules is intercepted and adapted by the Adapter cloud-native applications. Then it is routed to the Controller application. The Adapter applications are implemented using the Java programming language. Currently there are two types of Adapter applications that handle HTTPS and MQTT network protocols: ControllerAdapterHttps and ControllerAdapterMqtt, respectively. ControllerAdapterMqtt application communicates with MQTT broker. It is broker independent, so: Mosquitto, HiveMQ, Mosca or other type of MQTT broker can be used. The MQTT broker and the Adapter applications have publicly available URL endpoints, which are called by the vehicle hardware modules. The traffic is routed by the cloud platform to the concrete application depending on the application layer protocol that is used. The traffic is routed to the ControllerAdapterHttps application if HTTPS protocol is used. The traffic is routed to the MQTT broker if MQTT protocol is used. This routing behaviour of the cloud platform is based on TCP routing mechanism. TCP routing enables cloud platforms to support applications, which communicate with different non-HTTP protocols. TCP routing is used by one of the industry standard cloud platforms, called Cloud Foundry (Cloud Foundry TCP Routing).

The flow of the MQTT traffic is the following:

On creation of new vehicle, the Controller application registers two topics with names vehicles/{id}/sensors/{id}/measurements and vehicles/{id}/state. The ControllerAdapterMqtt application subscribes for that topics.
The concrete hardware module also subscribes to both topics and start to publish new measurements to vehicles/{id}/sensors/{id}/measurements topic.
On receiving of new message with measurement by the ControllerAddapterMqtt application, it adapts the measurement and sends it to the Controller application via the HTTP protocol.
The ControllerAddapterMqtt application receives the state of the concrete vehicle and publishes it to the vehicles/{id}/state topic.
The concrete hardware module is subscribed to the state topic and receives a response with the state of the vehicle, whether it is in optimal state or not. In this way vehicle is notified.

This flow represents how ControllerAddapterMqtt application adapts the data from MQTT to HTTP in both directions.

Web user interface

A web server serves static HTML5, JavaScript and CSS resources, which are assembling the web user interface. The web resources do not contain any back-end logic, but only front-end code, which assembles a responsive and user-friendly interface. This functionality for serving of static web resources is lightweight and it’s supported by the most cloud platform providers. It makes many simultaneous AJAX (Asynchronous JavaScript and XML) requests to the HTTP REST API endpoint exposed by the Controller application. Public access is provided and the drivers and operators of the system are using it.

The web user interface is based on the model-view-controller architecture and supports the following capabilities:

Handles the whole lifecycle of the users, vehicles, sensors and measurements: supports create, read</ins>, update, and delete operations.
Display all historic and live measured parameters in real-time.
Static manual control of the state of all vehicles by appropriate user interface controls, which leads to control of the vehicle’s actuator. Tis is achieved with manually configured threshold.
Automatic dynamic control of the state of the vehicles, which is based on the value of emissions or parameters that are not optimal per region.
Visualization of all vehicles with not optimal emissions or parameters - anomalies (outliers).

Analytics application

The Analytics application executes a clustering analysis algorithm on the stored data. The algorithm takes two parameters as input: engine capacity of the vehicles and total mass of carbon dioxide emissions exposed in the atmosphere. In this way it partitions vehicles that have similar engine capacity and emissions amount in clusters and finds the vehicles which are anomalies. The analytics application uses K-Means algorithm for clustering analysis. The number of engine capacities of the registered vehicles represent the number of clusters (K) in the alogorithm. The application is connected to the database backing service and consumes the stored relational data.

Algorithm results

This section proves the relevancy of the EcoLogic algorithm by presenting a case study with two datasets: test dataset and real dataset. The goal of the case study is to test the capability of the algorithm to find outliers in the dataset, which represent vehicles with not optimal carbon dioxide emissions in the context of a region with many vehicles. The experiment is carried out with one real vehicle with installed hardware module. The vehicle has internal combustion engine with a capacity of 1800 cubic centimetres, working on petrol fuel. In order to acquire bigger dataset, the collected real data is expanded with proportional simulated data. The final operative dataset contains data for vehicles with many engine capacities and carbon emission amounts. The x-axis contains the engine capacity measured in cubic centimetres (cc). The y-axis contains the mass of the carbon dioxide emissions, measured in milligrams (mg). The outcome clusters obtained after execution of the clustering algorithm are shown in Figure 6. The data points, which have unique IDs, corresponds to the vehicles.

The clustering algorithm should place vehicles, which have equal engine capacity and different amount of emissions preferably in the same cluster. In this way, the vehicles with not optimal emissions will not be placed in any cluster and should be detected as outliers. The algorithm returns 8 clusters (K1-K8) for the current dataset, which represent vehicles grouped in 8 different engine capacities – 1400, 1600, 1800, 2000, 2200, 2500, 3000 and 3200 cubic centimetres respectively. They have different carbon dioxide emissions values, which vary between 2.70 and 50.44 milligrams. Vehicle with ID 8759305 has engine capacity of 1800 cubic centimetres and emissions of 56.07 milligrams. The nearest cluster center located to vehicle with ID 8759305 is those of cluster K3, with distance of 38 milligrams. The maximal internal cluster distance in cluster K3 is 18 milligrams. Vehicle with ID 6947228 has engine capacity of 3200 cubic centimetres and emissions of 81.42 milligrams. Vehicle with ID 5915180 has engine capacity of 3200 cubic centimetres and emissions of 83.86 milligrams. The nearest cluster center located to vehicles with ID 6947228 and 5915180 is those of cluster K8, with distance of 54 and 56 milligrams respectively. The maximal internal cluster distance in cluster K8 is 24 milligrams. The vehicles with IDs 8759305, 6947228 and 5915180 are detected as outliers, because the distance from them to their nearest clusters is bigger than the internal cluster distance. These vehicles don’t have optimal amount of carbon dioxide emissions in the context of the rest of the vehicles, which are located into clusters K1-K8. Important notice for the outlier with ID 8759305 is that this is the real vehicle with parameter values measured during the idle period on cold engine. The outliers with IDs 6947228 and 5915180 have simulated parameters on the base of the real vehicle’s parameters on cold engine. The result obtained from the algorithm is feasible and proves it’s correctness on the real dataset. The hardware modules of the detected anomalies are successfully notified and actuators are activated.

Conclusion and future work

EcoLogic platform has the following advantages:

High availability and velocity during work with big amounts of data due to cloud-native architecture.
Platform-agnostic – possibility to work with different vehicles and clouds. The hardware modules are flexible and easy extendable to work with variety of sensors and/or collect data from the default onboard diagnostic bus or sensors of the vehicles. The implemented cloud-native applications are microservices, which are not vendor locked and can work on different clouds.
Fully completed and validated Open-Source Open-Hardware solution for monitoring and control of carbon dioxide emissions from vehicles, which is ready to contribute in the fight against climate change and reduction of the carbon dioxide emissions in the atmosphere.

The following improvements can be addressed in the latter stages of the project:

The engine capacity and carbon dioxide emission parameters are not adequate to appropriately regulate the amount of fuel injected. The solution could be extended to use also other parameters like vehicle weight and performance requirements for better control.
The measured parameters on cold and hot (with normal working temperature) engine are not deviate between each other. The measurements on a cold engine leads to detection of the outliers. The solution could be optimized to use two separate data sets: data, which is measured on normally working engine and data, which is measured on cold engine.
Different algorithm for anomaly detection or classification can be used. It can be a supervised machine learning algorithm, which takes the data measured on cold engine as a training dataset, which defines not optimal amount of carbon dioxide emissions.
Implementation and usage of more lightweight application network protocols such as CoAP, DDS and AMQP.
Implementation of predictive maintenance algorithm, which makes notifications for potential future failures in vehicles, based on the current and historical data.
Integration of the project with other third party systems such as emissions trading systems, transportation tax institutions and smart cities. For example, the more eco-friendly drivers could pay smaller taxes in tax systems of countries and city halls. The amount of carbon dioxide emissions could determine the traffic routing by the traffic lights in concrete regions of smart cities.

You can find more detailed information about the project in the following papers:

If you have any questions, feedback or want to contribute, feel free to reach me at: