Software for the Connected Car - A secure open source platform for an app-centric SW architecture


A new, open SW architecture is required to enable the connected car with mandatory components like cloud access, smartphone integration, app frameworks and related security and privacy requirements. At the same time, the SW platform has to comply with the “traditional” automotive requirements for quality, safety, cost, maintainability of variants and time-to-market. We propose an architecture based on Linux OS, a fast developing operating system, which is already widely used in the smartphone industry and which adds new state-of-the-art technologies to the automotive domain in a fast and reliable way. The next important development step is the separation of safety-relevant functions from connectivity- and cloud-oriented functions by virtualization. Standardized APIs make it possible to integrate the car into the IoT sphere. A key success factor is the open source and community development paradigm.

1. Challenges for IVI Systems

The architecture of IVI systems has evolved considerably over time. A major change was the integration into the vehicle internal networks, mostly CAN, but increasingly also Ethernet. Heterogeneous storage media and phone connectivity are also necessary. Traditional functions as FM/DAB reception and navigation are still important. In addition, safety relevant driver assistance functions will be realized on the IVI system. These are often video based like parking assistance or lane departure warning.

However, a real game changer is the integration into large-scale networks, usually called “internet”. This immediately raises new challenges like ensuring IT security and including regular SW-updates. Initial implementations are usually based on closed connections to a proprietary, protected server. The next challenge is to open the system. This means downloading and installing applications (apps) during the lifetime of the device. These apps require access to dedicated data or the option of uploading information about the car to a backend, i.e., to an infrastructure-based server. A safe and secure cloud connection will also be a necessary prerequisite for autonomous driving.

2. Classical design Approach

The classical SW-design for IVI systems is based on a monolithic approach. Especially the HMI is big and complex, although it is the basis for a differentiation in the market.

The supplier receives a detailed specification of the complete functionality and architecture; realizes an implementation, tests it and it supplies it to the customer. Then it will be operated with this unchanged feature set for the rest of its lifetime, usually 10 to 15 years.

To guarantee proper operation intensive testing is necessary. Possible updates need a similarly intensive release test. In addition, the possible reuse of SW was poor as most of the SW was developed by one Tier 1 for one OEM. Only some specialized functions from Tier 2 suppliers were reused in different projects. As a consequence, a lot of similar functions were developed redundantly and independently by different parties.

3. Open Source or Closed Source Software

With the explosion of the requested amount of features, this approach does not scale anymore, neither commercially nor technically. Facilitating the reuse of SW from different industries and among projects from the automotive IVI sector was a driver for a change.

Fig.  1: Software Stack with OS and Middleware

Modern IVI system can contain more than 25 million lines of code.  Much of this code resides both, within the kernel and middleware layers.   The software stack to the right shows a typical IVI software stack.  HMI and Applications reside outside what we typically consider as the OS. This combination of kernel and middleware (along with other tooling and sometimes proprietary software) is typically considered the “distribution”; either as a commercial product or as OSS solution.

The development of a complex operating system with the necessary automotive, multimedia, and connectivity components is time consuming and expensive. This leads to a significant cost overhead per device.

One solution to this problem is to build up company alliances to share development costs and resources and to increase the number of installations. The drawback of such a closed partnership is the exclusion of ideas and contribution from the rest of the industry and also from other industry domains. This is of particular importance as many infotainment innovations are driven from the CE industry.

One of the biggest concerns with a proprietary OS is the inflexibility of the architectural design. Designs of the operating system and components are more or less fixed by the supplier, whereas with an open source based solution such as Linux, one can configure or design the operating system with more flexibility.

Accessibility of the source code for open source components provides transparency to developers; this visibility allows an OEM or Tier 1 to fully understand the subtle details and interdependencies of the software components, thereby achieving greater control of the final implementation.  Another strong advantage of open source is that the associated developer community directs the feature evolution and validation of any given component.  Additionally, innovative developers are highly motivated to contribute back to the community, which the maintainer(s) – the leading developers in OSS projects - will ultimately accept or reject, but the strongest case moves forward. So if an individual or organization feels strongly about a topic, they can join the supporting community to influence feature evolution. 

Also safety and security are important drivers for following the open source paradigm as examples from train control [1] and avionics [2] show.

Linux OS

Hence, it was an obvious step towards an alternative to the classical approach to choose Linux as the operating system. One of the primary value propositions for Linux is that it is truly an open source platform.

As a fast developing operating system used in industries such as the IT server domain, desktop computing and smartphone business, it adds new, state-of-the-art technologies to the automotive domain in a fast and reliable process. This process is based on a large number of developers contributing each day in an open and cooperative way, which adds benefits for all the parties involved. The operating system benefits from the contributions from the different domains.

Fig.  2: Linux is used in different industries and provides the best of all worlds


Several communities and focused distributions developed around the Linux operation system.  Linux is strongly represented in supercomputing, banking and internet server and lots of CE devices. It is the backbone for connected TV Sets and AV devices where it dominates the market. [3]

In 2009 Bosch Car Multimedia decided to base all new IVI projects on a Linux environment. The supposed risk of having no responsible supplier for an open source based solution did not arise. A large network of SW partners is available in the domain, which makes it feasible to meet quality, time and development constraints.

Of course Linux also brings the advantage of having no license fee. This is an advantage, even if you consider the cost for professional support and maintenance.

4. GENIVI Approach

The next step was to enable the reuse of domain-specific SW components. This was the motivation for the foundation of the GENIVI alliance. The alliance aims to select appropriate OSS components for the automotive IVI domain and to jointly cooperate on the development of non-differentiating functions. The basis of the platform is the Linux Operating System.
The second element is the standardization of APIs for IVI application, which will enable the reuse of SW components from different suppliers.

Commercial Impact

The GENIVI/Linux platform hit the road and gained more and more market share. Bosch Car Multimedia alone is already selling about 3 million devices per year with a fast growth rate.

Fig.  3: Evolution of the development time compared to the functionality and relative development of the total development costs of the SW platform   (* in progress)

Also it can be shown that after some initial effort the development cost are going down.

5. New development paradigm

The selection of an open source platform was an important step, but just an enabler for a new development paradigm for the IVI domain.

The classical design approach of a complex monolithic platform under an even more complex monolithic HMI is no longer the answer to the connected world.

The SW design has to consider a modular architecture arranged around the required applications. It has to be “app-centric”.

Each application brings its own logic, architecture and HMI and is based on a small number of basic services. The application and the services need to be as independent from each other as possible. An isolated update of the application and the platform is a key characteristic of the new architecture paradigm. Already known from the smartphone industry, this design concept needs to be introduced to the IVI automotive domain to meet the challenges of the connected world, simultaneously preserving the existing safety relevant characteristics.

6. Commercial concept and use cases of an App-Centric SW platform

The first-use case for an app framework is the installation of user apps in the device in the car. These apps could either be linked to the car and remain there even if the car is transferred to a new owner, or these apps might stay with the user and they are installed automatically after identification in the user’s new or second car.

But the flexibility of an application oriented architecture, which will be explained in the next chapter in more details, is not just for “apps” like on a smartphone, but the basis for new use cases.
Connected Car

The second usage of an IVI application platform is the realization of the “connected car”. First implementations of connected car applications have been realized in the classical way with proprietary components.

It has proven difficult to enhance services over the lifetime of the car. In addition, there is no interoperability between the common services of the different manufacturers. Independent of the nature of the applications this situation makes it difficult to develop and install new connected car applications.

A platform for the connected car should be interoperable with independent providers and users to allow a vibrant, innovative evolution. Also it should not be a preinstalled function of the device but realized on the basis of an open platform. These elements will enable the evolution of services and the installation of new services over the lifetime of the car.

There are two classes of connected car applications. The first one is for the user or the car itself, and provides information or entertainment. The main information flow is downstream to the car. This application usually has a user interface.

The second kind of applications is infrastructure-oriented. In this case, the device collects and uploads information to a backend service. The information flow is upstream to the infrastructure. Similar kinds of information are collected from different cars and aggregated or interpreted to generate a service.
A possible example could be a car-sharing organization which installs a company app in their cars. As a result, the company would receive status information about their fleet like vehicle position, fuel-level status, closed or open doors, etc. This would be made possible just by software, i.e., without the installation of an additional device in the car. If the car is sold the app/agent could be uninstalled; the best being with a remote command from the app operator.

The 2nd kind of application is also often called an InternetOfThings – IoT – type application, whereby the communication architecture follows the Vehicle-to-Infrastructure (V2I) concepts. Some of the functionalities have been discussed under the label “Telematic” earlier. With the rollout of such SW platforms, no dedicated HW modules seem necessary for passenger cars.

Addon-SW and SW update

An obvious result of SW update capabilities is the possibility to install new SW in the car during the lifetime of the car which can generate additional turnover. Very interesting is also the concept of realizing HMI functions for later installed HW periphery. This is relevant for professionally used cars, like taxis, company fleets, emergency vehicles or commercial cars with specialized installations. After connecting the additional HW to the vehicle bus the associated HMI could be installed in the IVI system.

Together with the trusted interfaces into the vehicle the update mechanisms could be extended to the whole car to realize Software /Firmware Over the air (OTA) scenarios. [4]

Internet access

The inherent security mechanism (see chapter 8) of isolated applications makes such a platform a good choice for free internet access and browsing.

Monitoring of the operation of cars

The car manufacturer or the Tier 1 supplier of essential components has a vested interest in the operation of the car. The SW platform should be able to collect information from the car´s components and aggregate it.

It is essential that the owner of the vehicle always has control over the apps or agents and the kind of information transferred. In the case of fleet management, this is not always the driver.

7. Framework architecture

A new, enhanced SW architecture is necessary to implement the described use cases. In contrast to the classical approach, an incremental update should be possible.

An app-centric approach and standardized APIs are essential for the realization. Key concerns are security, integrity and privacy of the data. As far as the infrastructure is concerned, an adopted architecture is necessary.

In general, it has to be an open platform with standardized interfaces. Therefore, an open source development model seems to be most appropriate.

Bosch Car Multimedia has developed such a new SW platform – called APERTIS – which realizes the app-centric approach and the new development paradigm. The platform is based on the Linux operating system and other open source components. The development will be open to enable a rich community of contributors and users.

Fig.  4: App-centric OS and software stack. Enables the installation of apps and incremental updates during lifetime

App-centric architecture

As described earlier, the platform needs to enable diverse kinds of applications and use cases. A consequence of this requirement is that all the elements necessary for one use case need to be bundled on an independent entity, i.e., all layers of a software stack from the GUI, business logic, services down to protocols and their related web service for a specific scope have to be bundled into one entity. An asynchronous, independent update of each such entity is a key characteristic.
The platform dependencies are standardized in a SDK-API in order to guarantee backward compatibility.

Development Environment

At the same time, a general purpose, reasonably easy-to-use development environment needs to be publicly available. This environment should cover all layers of the SW stack and should be usable without special knowledge of the underlying platform.

A simulated in-car environment facilitates the development usable even for SW developers not used to the embedded automotive environment. A direct way to the download server is possible from the development environment.

In a more open environment, for example with 3rd party developments, a verification of quality and security aspects is recommended.

Fig.  5: Development procedure and upload mechanism

8. Security, privacy and integrity

A key concern is, of course, the security of the system and the privacy and integrity of the user data. To realize security in an open platform, a clear separation of in-car software and the open application platform is necessary.

The basis for the separation is the implementation of 2 or more operating systems on a virtualized platform.

Fig.  6: virtualized instances of operating systems

The “automotive domain” is realized according to the classical design approach with extensive testing. Updates here will only take place from what we know as a “trusted source”. Access rights to automotive parameters are defined here. 

The CE Domain is an open platform with asynchronous update possibilities. One element in the security concept is the fast fix of new discovered security problems.

Standardized and secured interfaces

Access to the automotive domain is realized via a set of standardized interfaces. Proxies could provide relevant information like speed, heading, position, fuel-level status, video signals and data from other ECUs in the car. Authorization will be codified per application and per parameter in a manifest. Only registered applications will have access to the automotive parameters for which they are authorized. The proposed realization is based on AppArmor a security framework used in several Linux distributions.

9. Backend infrastructure and IoT applications

The access for any update and installation is realized via a trusted portal, usually operated or contracted by the car manufacturer. All applications will be available in a “store” after passing a quality and security check. News and updates will be presented to the user.

Fig.  7: Download path to the car

At the same time, 3rd party applications will be allowed to communicate to their own backend infrastructure. This is a necessary element for the realization of IoT applications.

10. Automated driving

The discussed architecture targets the connected car and enables applications for driver assistance and entertainment as well as the knowledge generation based on IoT approaches.

But the proposed architecture will be relevant for even more challenging use cases, like automated driving. A clear and secure separation of the drive control function and the navigation from the connected part of the software stack has a direct impact on the safety of the cars operation.  Of course, additional requirements like real-time constraints will come into the picture here as well.

11. Outlook

The chosen open source and community development model will reduce the entrance barrier for independent applications to a reasonably low level, which will facilitate the development of independent and innovative or specialized applications. At the same time, the trusted source and security approach guarantees security and privacy for the car manufacturer and the car user.

12. Summary

Challenges and constraints for modern IVI systems have been shown. The exploding amount of required functionality is only realizable with a reuse of SW from different industries and among different projects from the automotive IVI sector. The key for this approach is the usage of the open source community concept.

The upcoming IVI systems will realize the gateway functionality between the automotive domain and the open internet. A modular update functionality was presented to allow the evolution of the in-car system over the lifetime of the car. A new SW architecture based on virtualized instances of operation systems and software stacks was presented to enable the secure “Connected Car”. Due to its fundamental nature a provider independent solution for the underling SW platform is essential to guarantee long term security and the privacy of the car user. Therefore, the development of this architecture will follow the open source and community approach.

13. References

[1] Open Source in Train Control applications
[2] Open Source in avionics applications
[3] OSS and Linux in consumer electronic devices
[4] Klaus Schneider, Kai Zimmermann : “Secure and fast vehicle firmware & software update Over-The-Air”; VDI Konferenz “Electronics In Vehicles” 2015

Authors of this article

G. Spreitz, A. Zahir, T. Kropf, Robert Bosch Car Multimedia, Hildesheim