ICT in Road Vehicles – The VehicleICT Platform
Vehicles are not just a means of transportation anymore, but they are also moving entities that collect and transmit a great amount of local data, captured by sensors from the internals of the vehicle and from its environment as well. The consumers of this information include the passengers, especially the driver, and the environment, i.e. other vehicles, intelligent gates, centralized storage systems and data processing solutions. In order to maximize the value provided to the passengers, other vehicles and also the urban society, vehicle services utilize the local nature of the data. This document introduces the VehicleICT platform.
The VehicleICT Platform
The idea behind the VehicleICT framework was to identify a reasonably rich set of functionalities that typical connected car applications need; to implement and test these functionalities, and offer them as building blocks in a centralized manner. The approach enables application developers to focus on their domain-related logic. By using the building blocks, application development becomes more efficient and leads to a more stable software artefacts in the end.
Applications and services in the connected car domain can be divided into three separate parts: (i) the sensors, (ii) the local processing and visualization, and (iii) the background processing and analytics (Figure 1). The VehicleICT framework answers developers’ needs in all three of those areas.
Figure 1: The VehicleICT architecture
Sensors
The main sources of data are the vehicle sensors themselves. The VehicleICT framework provides two ways to access the sensor data: through the OBD-II port or by connecting directly to the CAN bus.
The OBD-II port can be found on the panel of every car manufactured in the last decade, but until recently, it was mainly used by repair shops to detect faults in the internals of the vehicle, even though it has much more potential in it. Nowadays, small inexpensive devices are available, which can access sensor data through the OBD-II port and do not require special expertise to install, making them a convenient choice for average customers.
The OBD-II port is itself connected to the vehicle’s CAN bus, but enables access to a limited set of vehicle sensors only. That is why a special device has been developed, which can be connected directly to the CAN bus, bypassing the restrictions of the OBD-II. The downside of this solution is that it requires an expert to install the device, so use cases are restricted. Both devices broadcast the data they collect via Bluetooth.
Local processing and visualization
A background component running on the user’s device (smartphone, tablet), which we call the Client Platform, is responsible for abstracting away the differences in the previously described methods.
A client application connects to the Platform, and requests some data, e.g. the engine RPM (the frequency of its rotation). The Platform connects to the available collector device via Bluetooth, acquires the same data from the vehicle sensors and delivers it to the application. The application does not need to concern itself with the origins of the data.
The Platform is prepared to serve an arbitrary number of applications at the same time. The standard operation involves providing a set of data to applications periodically, so it is possible to optimize the access to the sensor devices by requesting data only once, even if multiple applications need it.
After acquiring a data set, the Platform forwards it to the backend infrastructure, a process entirely transparent to the client applications, although they are given the possibility to enrich the data set with custom data fields, which are not available through the Platform. The applications receive the data sets via hook-methods, and can perform custom processing steps on them.
To promote the uniformity of the applications based on the framework, we also created a UI library with domain-specific UI components, such as drag-n-drop speedometers.
Background processing and analytics
On the infrastructure side, the data collected from the vehicles and transparently forwarded by the Client Platform, is aggregated, processed and loaded into a data store. Based on the predicted data volume, the data store can be a relational database, or if the volume is sufficiently large, a state-of-the-art data storage cluster, equipped with the Apache Big Data Stack (a.k.a. Hadoop).
A relational database has the advantage of being well-known in the developer community, and all the usual tools and methods can be applied to the data, e.g. standard BI tools, centralized processing logic (either streaming or batch), etc.
Developing for a Hadoop cluster requires more effort, however, several tools are available which effectively support service developers. The VehicleICT framework implements a process, which makes it possible for developers to view their data stored in Hadoop as if in a relational database (with a few restrictions), but also enables them to use the full power of the Hadoop stack (running distributed machine learning and data mining algorithms, stream-processing and others). The environment supports service developers to focus on the data at the abstraction level that best fits their needs, contributing to the ease of development.
Besides automatically handling the data, we developed various building blocks, which application developers can use in their application logic. The simplified query API can be used to query application data via HTTP, so no JDBC connection is needed. Simple filters can be applied that are usual in the domain, such as filtering by users, GPS location and the timestamp of the data. Another service addresses the issue, when the developer wants to send custom messages to the user’s device from the application logic, without knowing the exact identity and location of the device she is logged in at the moment. A common use case is when the data is streamed and processed, and based on the processing, some alerts need to be forwarded to the user. We have also implemented a simple method to determine when a vehicle starts or stops, which can be useful in many applications.
Independently of the core services, data can be accessed via ODBC/JDBC as well, so any standard BI tool can be used to generate reports on the data.
Summary
The VehicleICT platform represent a significant value at the BME Faculty of Electrical Engineering and Informatics, Department of Automation and Applied Informatics (BME AUT), some aspects of which we highlight:
Common basis for VehicleICT developments: both on client and server side supports the effective application and service development.
The concept can be migrated to other domains (application areas). The sensors and data collection requires domain-specific development. However, the client and server components of the framework provide methods for data collection, local processing and data visualization, data transmission to the server side storage, data analysis, and using the information in different ways to build services and applications. Other domains are health industry, manufacturing and production lines, smart city applications, and industrial internet (Industry 4.0).
Documentation: http://atleast.aut.bme.hu:9080/redmine/projects/vehicleict-platform-releases/documents
Platform releases: http://atleast.aut.bme.hu:9080/redmine/projects/vehicleict-platform-releases/files
Contact
Web: http://aut.bme.hu/VehicleICT
László Lengyel
Péter Ekler