The internet industry has showcased impressive development speeds and execution skills, which resulted in a diverse service and product offering in the digital area. Some of the services have a monopoly position and at the same time an overwhelming user acceptance, such that OEMs see themselves motivated to integrate these services into the car. Now the general question for the automotive and transportation industry remains, to which extent and under which conditions to open up their systems. The focus lies on cross-functional approaches to combine the best of both worlds: agility, flexibility, and execution from the digital world with reliability and safety from the automotive world.
This is why FEV has put forward various research projects to evaluate the concept of an open service platform (open service cloud). The aim of this platform is to translate the key success factors and benefits of the open source and open innovation world (for example Linux, Android) into the automotive world.
What are the differences of vehicle software in contrast to consumer software?
During the development process of vehicle focus a strong focus lies on reliability, safety and security. As a result, a complex multilevel validation approach is used to test this software. At the same time, more and more attributes from consumer software – e.g. customizability and updatability – are being transferred to the automotive sector.
Adaption to individual needs and to environmental changes is expected to “just work” in the vehicle and the overall system has to provide a seamless user experience embodying continuous improvements and up-to-date services. In contrast to consumer software, there is only a very low tolerance for faults and failures when it comes to vehicle software.
Which components does a vehicle service system landscape consist of and which functionalities do these components include?
In a vehicle service system there are normally three interacting elements involved. The first element is the vehicle environment consisting of control units with sensors, the HMI, the infotainment system as well as Advanced Driver Assistant Systems (ADAS). In addition, the communication level provides the functionality to exchange information with cloud services. First the server environment providing a certain set of services like traffic information services, route optimization services, energy management support, driving strategy optimization, etc. And finally the vehicle environment, consisting of control units, the HMI, – and other components like sensors.
>> THE THIRD PARTY DESIGN OF SERVICES OR APPS IS CHALLENGING DUE TO INTERFERENCES AND INTERDEPENDENCIES WITH OTHER SERVICES
How can third parties be integrated into this landscape?
Support to potential third parties with regard to this system means to open up and share the last two environments without compromising safety, data privacy and data security. This includes sharing portions of the vehicle state and measurement data, sharing the HMI for input and output and sharing the communication infrastructure and data transmission channels.
Which efforts must be taken to integrate these third-parties and which initial measures must be taken?
The third party design of services or apps is challenging due to interferences and interdependencies with other services. They are partially hard to predict and have to be tested together. FEV has been a competent partner for integration and validation for many years. The documentation and managerial efforts are very large and require open, well documented and well- supported interface standards. In addition, to take advantage of open innovations, we believe, that a development platform has to be established.
How can safety and data security be guaranteed despite of the integration of third-party players?
It is possible to design an open service system without compromising standards in safety, data privacy, or data security. The data provision system of the vehicle can stay completely closed without any access by third parties. The only necessity is access to a commonly agreed service interface. The data can be transmitted by the closed part of the communication environment and be distributed via cascaded cloud communication systems to the relevant service parties. Of course, the vehicle’s data transmission system and the OEM server stay under full control of the manufacturer. In case the vehicle enters a safety critical state, full computing and transmission capacity must be used for safety relevant services.
The vehicle remains the last decisions of data transmission and can optimize and prioritize the data transfer flow when multiple services request the same data. For this purpose, FEV has developed a security gateway which prevents the data exchange between communication module and vehicle electronics from external interferences with help of parallel hardware and software solutions.
Which experiences can FEV offer in this context?
For many years now, FEV is highly involved in series integration and validation of such systems and has taken part in various research and consulting projects – and is still doing so. In the context of open service system the publicly funded research project named O(SC)²ar – Open Service Cloud for the Smart Car. In this project, together with partners, FEV established a scenario with a continuous unidirectional data transmission from a distributed and heterogeneous fleet of electric vehicles to an energy supplier. Here, the transmitted data set contained detailed information about the battery status and recent energy consumption together with location data of the vehicle. FEV together with its partners implemented data transmission to the cloud service. In another, still ongoing project, called City-e, Denso and FEV are researching and developing connected mobility services using the complete set of car-to-X technology. More than 100 cloud service ideas were developed, and the most promising were implemented and tested using an open development platform together with HMI concepts, in a vehicle fleet with an (partial) open innovation approach to demonstrate the feasibility and the potential of connected assistance systems.
Your studies are a good prove of the open service concept but what needs to be done to start the implementation of the open innovation approach?
A final design of an open innovation approach has still to be defined and has not been decided yet. Open questions include the membership model, open access, fee structure and more. A simple copy of existing open innovation approaches to the automotive world is not that easy, due to the high safety and security standards. Yet, in the area of transmission protocols, the provision of open standards and available reference implementations with approved licenses (as by OSI) for commercial usage are without doubt reasonable. In this context FEV would also like to point to the W3C effort to establish a web standard for the automotive sector, which specifies the vehicle data portions of interest for third party services and defines an interface for access to the current state of the vehicle that can be provided without compromising vehicle safety.