The smartphone has conquered almost every person’s daily life. In the morning, it wakes you up with exotic sounds, presents the current news, and later on gives motivational assistance as a personal trainer during sports in accordance with your vital signs. In the evening, it suggests interesting events in the local area before calculating the cheapest way home.
The fact that the smartphone assists in such different situations is partly due to the fact that it is full of sensors and can access any services through its connection to the internet. Consequently, smartphone data can be accessed by a large number of developers in order to develop interesting and innovative applications.
The car is yet another companion of many people’s daily life. Just like the smartphone, the modern car is full of sensors. However, a continuous connection to the internet and a possibility to openly extend vehicle functions or even add new vehicle applications is missing. While OEMs and supplier yet cope with such challenges proprietarily, a common infrastructure or at least standardized interfaces would significantly ease development activities and strengthen collaboration and innovation in terms of IoT, Cloud, and 5G technologies.
Additionally, such an environment would ease a large number of interesting applications. For example, when buying a vehicle, the decision of whether to buy or not to buy a navigation system and a cruise control technology could be flexibly postponed to a certain point in time, for instance, when a long holiday has been scheduled that certainly makes such technologies very worthy.
Furthermore, the unpleasant situation of a breakdown could be significantly improved, since an alarmed rescue service would already have access to a detailed list of the problems encountered and consequently could pack all the appropriate tools and spare parts this specific rescue would require. In accordance, traffic lights could be switched to the ambulance’s route convenience, in order to provide the most interruption-free ambulance route that is possible.
The features of the 5G technology enable ubiquitous connection of vehicles to the internet and thus allow the scenarios described above. What is missing is a platform that enables the vehicles to be equipped with such new functionalities.
Eclipse Kuksa addresses exactly this point. It provides a development ecosystem for building the cloud and vehicle infrastructure for Car2X scenarios. Eclipse Kuksa is licensed under EPL 2.0 that allows the development of an extensible open infrastructure that is standardized between vehicle manufacturers.
Structure of the Kuksa Ecosystem
The development of an infrastructure for Car2X scenarios comprises three areas as shown the Figure below: An in-vehicle platform, a platform in the cloud back-end and an IDE for the development of new functionalities.
In order to cope with the various scenarios of a networked vehicle infrastructure, not only a sophisticated network and cloud architecture is required, but in particular a new type of hardware component in the vehicle.
On the one hand, this hardware component is intended to ensure bi-directional communication with the outside world across ECUs and, on the other hand, it also contains a wide variety of technologies to be able to carry out updates, upgrades, maintenance, or diagnostic work, and data exchange of any kind in a secure, error-free, authenticated and verified manner.
A reliable basis for such a component is Automotive Grade Linux (AGL), which has proven to be most suitable for the intended development activities compared to other platforms.
First implementations have already shown that the lightweight adapted AGL image can comprise a standardized Kuksa layer that grants access to required functions of the automotive domain. A key part of the implementations is developed by a separate security group, in which existing technologies are checked for security gaps and suitable methods are selected to protect vehicles from all kinds of attacks from the network. Furthermore, the Kuksa vehicle component provides a runtime environment for verified applications.
Accordingly, new and individual functions can be managed similar to a smartphone but under stricter conditions such that new market potentials in the networked automotive sector can be accessed. One of the main incorporated methodologies is the secure access to telemetry data and vehicle functions. With the help of centralized and decentralized data acquisition of vehicle data and states, it is intended to support autonomous driving, and enable globally optimized traffic. For a future-proof infrastructure, it is crucial that the ecosystem basis and the associated protocols and communication technologies are used independently by manufacturers.
The IDE provided under Eclipse Kuksa not only support the development of applications for the vehicle component, but also the creation of applications for the cloud. Users should be able to choose between two different workspaces and technology stacks that contain the preconfigured and embedded APIs as well as software libraries of the respective applications to be developed. This allows the car to be equipped with new functions and new services to be deployed in the cloud.
Kuksa offers various APIs for implementing vehicle applications, a project template for cloud services, and wizards for easily providing vehicle applications in the App Store via the IDE. The extensive provision of the various APIs and libraries in the IDE enables accessing existing communication interfaces for the secure data transmission, storage, management, and authentication without having to take separate measurements for processing or interpreting the data.
Kuksa also supports the simplified deployment of new applications for both the cloud and vehicle components. This is provided by a pre-configured Eclipse Che stack, to which only the address of a target platform must be specified. Configuration, building and deployment can be done at the push of a buttonwithout further configuration or processing. Depending on the application, different development tools (e.g. Logging, Debugging, Tracing,…) can be included. Of course, syntax highlighting, code completion, and other necessary IDE functions are supported. For instance, the in-vehicle Eclipse Kuksa Che stack for AGL development activities features including Yocto based SDKs in order to support target specific programming shown in the screenshot below. After compiling and building software, specifying a target IP allows also the deployment process.
In order to make new applications applicable to a greater amount of vehicles, applications need to be centrally checked, managed, and organized with regard to various in-vehicle derivatives and variants in such a way that only vehicle-appropriate applications are accessible. Similar to a Smartphone App Store, it has to be possible to add new functions and applications to their vehicle or perform updates or upgrades. Therefore, standardized interfaces of the in-vehicle and cloud platforms are required and they must offer the most diverse and yet simple infrastructure for vehicle owners. Authentication methods, security concepts, variant management, and suitable data transmission technologies in combination with the publicly accessible ecosystem form mandatory components as well as the difference to existing solutions.
The cloud back-end is the counterpart to the services provided by the in-vehicle platform. It offers basic services regarding connectivity, authentication, authorization, device update and data management. These services are realized by open source Eclipse IoT technologies, which are tailored to the requirements of a connected vehicle platform.
Central functionalities rely on a unified and secure communication between the back-end and the in-vehicle platform. In this regard, the connectivity for a large number of vehicles is realized using Eclipse Hono, which receives telemetry as well as event data and allows to transmit information to the vehicles. Open communication protocols such as AMQP and MQTT are accompanied by vehicle identity management.
The large amount of collected data can either be processed by big data analysis applications via streaming or persisted using database management systems. In addition, the state on the individual vehicles is managed using Eclipse Ditto, a digital twin implementation, which allows the synchronization of their physical and virtual representations.
A device management component takes care of provisioning software updates to the vehicle, both in terms of the core system as well as adding or modifying vehicle functionality through apps. The former comprises so-called rollout management, which controls the distribution of the software to a large number of vehicles. This component is represented by Eclipse hawkBit. Applications augmenting the functionality of the vehicles are provisioned by the vehicle manufacturers or external developers via an app store.
A set of core services provide the access to the vehicles managed within the cloud back-end. In this regard, an authentication and authorization component ensures that malicious access by third-party services is prohibited. This involves all major components of the back-end infrastructure.
Eclipse Kuksa is currently in incubation status and just recently got its initial contribution committed by the beginning of June (2018). Since then, committers are working on CQs in order to add appropriate third-party technologies and provide consistent implementations to be used and adapted conveniently. Documentations and tutorials are also planned and will include tutorials on how to build adapted AGL-Kuksa images for a Raspberry PI3 or other HW platforms supported by Yocto, transfer data to a cloud instance, and implement cloud or in-vehicle applications using the provided Eclipse Che Kuksa stack. With its origins in the ITEA3 research project APPSTACLE, some related documents, deliverables, and planned activities can also be found at the research project’s ITEA website.
In addition, various technologies such as new authentication or security methods as well as use case examples will be added to the corresponding repositories. For instance, a software rollout OBD scenario (shown in the following picture) is currently being developed.
The scenario uses Eclipse hawkbit, a Kuksa-Application store, and various AGL-based layers and services, e.g. an AGL service implementing the W3C standard, or a download manager AGL service. A variety of device and application management components are also incorporated in order to cover the complete application provisioning process right up to the vehicle.