Veröffentliche eine Notiz:

Abstract

The automotive industry is in a parallel transition from combustion engines to electric vehicles and at the same time from hardware centric products to products which are defined by software, supporting autonomous driving capabilities and feature updates over the air. This revolutionary change is requiring new electric / electronic (E/E), and software architectures based on the decoupling of hardware from the software.

Organizational changes in the automotive development and engineering process from siloed organizations to agile and DevOps based processes are required to address the cross functional collaboration and increase the development speed and flexibility.

The base for such a revolution is a Software Defined Vehicle (SDV) and an integrated DevOps approach which includes the update of software up into the vehicle.

This paper describes the principles of a SDV, the challenges it can address, and most importantly, a DevOps approach which covers the real end-to-end process. This can enable new business opportunities for OEMs not only around the standard vehicle, but in its whole ecosystem around shared mobility and smarter environments.

About this document

In this document we introduce the Software-Defined-Vehicle hardware and software concepts and the related architectural changes. The software defined changes in the automotive industry are compared with other industries.

The focus of the document is on automotive vehicles, primarily on passenger cars, but can also be applied to trucks, busses, and motorcycles. When the term car is used, the emphasis is on passenger cars.

With the SDV, automotive OEMs will become software companies. The development and operational processes will shift to more agile processes based on DevOps principles. We describe how DevOps principles can be applied to the whole ecosystem of vehicles and cloud-based services to develop and operate the future vehicles. DevOps for automotive includes security, backend vehicle services and over-the-air updates, a continuous integration and deployment process, the usage of containerized, hybrid integration testing and software- and configuration management.

The transition to the SDV requires fundamental changes in the OEM organization from siloed domain-oriented departments to more cross functional and agile organizations. These changes and the changes in the collaboration of OEMs and suppliers are shortly summarized.

The SDV requires different architectural changes. We are providing some reference architectures for the vehicle-onboard-architectures, the edge-connectivity of the vehicle, for over-the-air-updates, for containerized testing of artificial intelligence (AI) and machine learning ML solutions, and a Continuous Integration / Deployment reference architecture including hybrid testing.

At the end of document, we assess the SDV market opportunities and give some recommendation how IBM should address this increasing market.

Introduction

In the last decades several industries, like the PC industry, mobile and telco industry, were disrupted by decoupling of software from hardware, which enabled updateable and upgradable products and new business models. In addition to more flexible software-based products, these products are always connected to the internet for providing online information, and consume and produce huge amounts of data, which can be monetized in new business models.

In the automotive industry, functional safety is paramount. A braking system needs highest reliability to assure passenger safety. The flexibility to change the braking system is low compared to other areas of the car like the infotainment system, where the consumers expect frequent updates and new features. The automotive industry is challenged by different new requirements:

• Customers expect the same user experience in the vehicle as with their mobile devices. This requires integration of apps and mobile operating systems like Android and iOS into the car.
• Cars need to provide different level of autonomous driving, which requires artificial intelligence (AI) and machine learning technologies (ML).
• Environmental regulations and climate change lead to electrified vehicles. These regulations vary from country to country.
• Shared mobility concepts and combining private and public transport offer new business models.
• Always connected vehicles allow continuous communication with the infrastructure and new after-sales opportunities for automotive OEMs.

These changes in the automotive industry, often referred as the ACES (autonomous driving, connected cars, electrified vehicles, and shared mobility) require fundamental changes in the vehicle and backend architecture. These innovations will be all implemented in software based on an electric/electronic architecture providing powerful computing resources. Software defines the future vehicle. The creation of business values changes from hardware to software.

The software defined vehicle (SDV) separates hardware from software, is updateable and upgradeable, autonomous, learning, always connected, interacts with its environment, and supports service-based business models.

Software-defined in other industries

In the telco industry, the introduction of software defined networks (SDN) separated the data pane from the control plane, enabling flexible applications on top. By this separation, the administration of networks was simplified by software configuration instead of hardware configuration like the configuration of firewall rules, network address etc.

SDN provides a programmable, central control of the network traffic without any manual configuration. This separation of hardware and software and the provisioning of flexible services is comparable with the automotive industries efforts towards a software defined vehicle.

Looking at PCs and smartphone industries, some parallels can be identified which can be transferred to the automotive industry. In the PC and smartphone industries, the software in form of applications is creating an ecosystem based on a software platform, which de-couples the hardware from underlying software. The software platform abstracts from hardware details and provides a consistent set of SDKs or APIs which can be used by the application developers.

Decoupling of hardware from software and the introduction of software abstraction layers and platforms are the fundamental concepts seen in the telco, PC and smartphone industries which can be applied to the automotive industry.

Successful software platforms are available for multiple generations of hardware. Never versions of the software platform can be installed on older hardware. In this case, some features requiring the new hardware, will not be available on the old hardware with the new software platform, but the latest apps will still run on the old hardware.

Android Automotive provides a software platform for the automotive infotainment domain. In other automotive domains, such as ADAS/AD, body, powertrain etc., automotive OEMs build their custom platforms, leveraging middleware components such as AUTOSAR. However, the level of abstraction and standardization is low. Feature updates in these domains to new and old hardware generations is complex and difficult if achievable at all. For both PC (and Mac) and smartphone (iOS, Android) comprehensive app stores are available making software installation and update easy. With Android Automotive and Apple CarPlay, we see first implementations of app stores for the automotive infotainment domain. Both the PC software and smartphone apps are based to a high degree on open-source software (OSS). The usage of OSS increases productivity of software development significantly. With the SDV, the percentage of OSS used in automotive applications will also be increased.

Software defined vehicle fundamental concepts

Fundamental changes of the vehicle E/E and hardware architecture are required to enable the decoupling of hardware from software, which is the core concept of the software defined vehicle. Based on this separation, further software architectural changes provide the required flexibility.

Evolution of the hardware architecture

The in-vehicle E/E architectures of the vehicles are currently changing from a distributed architecture over domain-oriented to zonal and central architectures (see Figure 2).

Coming from distributed E/E architectures, additional electronic control units (ECUs) were introduced with new vehicle functions. Over time, the number of ECUs and the wiring and weight also increased significantly.

To reduce wiring complexity and weight, domain controllers were introduced. For the different domains, like ADAS/AD, body & chassis, energy & powertrain and infotainment, domain ECUs are connected to ECUs of this domain via different bus systems. Domain controllers are used to consolidate domain functions, previously implemented on different ECUs of the domain.

With the introduction of high-performance computers (HPC) and in-vehicle high bandwidth networks like Gigabit Ethernet, the E/E architecture can be even further consolidated and centralized. HPC are a key element to enable the software defined vehicle. HPC allow execution of vehicle functions of different domains on a powerful compute-platform and allow easier update and upgrade of in-vehicle software.

HPC can be used to consolidate software of different domains. For example, ADAS/AD, Infotainment and Body control can be executed on a single HPC. Cross domain use cases can be implemented on HPCs utilizing access to the domain controllers and direct access to the vehicle busses. Latest E/E architectures use zone controller ECUs instead of domain controller ECUs. Zone controllers are in different physical regions of the vehicle and are connected to the smart sensors and actuators of this zone. Zone controllers are connected via Ethernet to HPCs. This zonal architecture leads to reduced and simplified cabling and wiring and reduced weight. Zone controllers can provide intelligent power management, serve as power hubs, and provide smart fuses. The zone controller handles the input/output (I/O) and abstracts I/O from high level computation.

HPCs will not replace other types of ECUs. The present and future E/E architecture will combine µController and µProcessor based ECUs and consists of different bus systems.

HPCs often are connected to the internet and provide gateway functionality. The dynamic and flexibility of HPC software is very high. For the SDV the HPCs are the major deployment unit to implement new vehicle features. Over-the-air-update (OTA) concepts are therefore an integral part of any HPC based architecture.

Today’s E/E architectures contain different bus systems, like Ethernet, CAN, LIN and Flexray. Each bus has distinct advantages and disadvantages regarding real-time capabilities, bandwidth, speed, and cost etc. A major difference between the different busses is the communication principle used. Ethernet allows service-oriented communication as used in the IT industry on PCs, servers, and mobile devices, enabling microservice software architectures in the vehicle and to the backend. Buses like CAN and Flexray are using signal-oriented communication. Deterministic signal-oriented communication is necessary for hard real-time use cases. The SDV needs to fulfill safety and real-time requirements but shall also provide flexibility by providing service-oriented software designs. This leads to a hybrid, or layered communication architecture combining signal and service communication.

With ADAS/AD smarter sensors, sensor fusion and artificial intelligence (AI) are integral part of the SDV. This data centric processing requires sufficient bandwidth (Gigabit Ethernet), and ECUs with powerful GPUs or NPUs. Low latency and high bandwidth connectivity to the cloud and HD maps are also a mandatory prerequisite to enable level 3 to 5 autonomous driving.

Vehicle functions like antilock braking systems (ABS), airbag control, or electric steering and engine management have hard real-time requirements and demanding functional safety requirements (ASIL D). These functions are controlled by µControllers, typically connected to Flexray or CAN buses. The communication is signal based. Smart sensors and actuators are also using µControllers. AUTOSAR Classic is commonly used for this type of ECUs. The AUTOSAR Classic basic software (BSW) includes an OSEK real-time operating system (see Figure 3). In AUTOSAR Classic, Applications are implemented as software components (SWC), which communicate via a virtual function bus provided by the AUTOSAR Runtime Environment (RTE).

µController applications provide the fundamental safety-relevant and real-time constrained vehicle functions. µController applications are relative static compared to other vehicle software. Nevertheless, the SDV will provide means to update this software over-the-air (OTA).

Typical vehicle functions for ASIL level B are the control of the headlights and the brake lights. A Domain ECU or Zone ECU is providing ASIL-B functions. For these functions, µProcessors are used. Additional to CAN and/or Flexray connectivity, Domain / Zone ECUs may be connected to an automotive Ethernet and communicate with other ECUs on protocols like SOME/IP. The communication is service-oriented.

Gateway ECUs provide inter-bus communication and are connected to two or more vehicle busses (Ethernet, CAN, Flexray, LIN) and can translate message or signals between the different busses. For Ethernet to CAN, Flexray, LIN communication they transform the service-oriented messages to signals and vice versa. In case of a telematics / connectivity ECU (TCU), the ECU may have an internet-connection and will need cryptographic and other security features and provide access to the other ECUs for OTA.

µProcessor applications are running typically on the AUTOSAR Adaptive stack, which is requiring a POSIX based operating system like QNX or Linux. Applications are typically written in C++ and will be more dynamic in terms of feature updates compared to µController applications. New vehicle features will require changes at least to these high-level applications.

Multiple µController or µProcessor and µController are often combined in ECUs in a System-On-Chip (SoC). In these ECUs, communication within the ECU is performed via IPC methods like shared memory.

ADAS/AD functions like radar and camera-based cruise-control are also mainly ASIL-B applications. Powerful ECUs are required for these demanding use cases. The ECUs for these types of applications are based on high performance µProcessor architectures and include GPUs and NPUs on the SoCs to perform artificial intelligence algorithms based on sensor fusion.

On top of the HPC hardware, a virtualization layer (Hypervisor) is used to run multiple operating systems in parallel. For example, a Linux OS can be executed with the AUTOSAR Adaptive stack and an Android Automotive operating system on the same hardware. In parallel, Android Automotive can be used to provide an environment for Infotainment and run the instrument cluster UI.

The AUTOSAR Adaptive stack can be used for example to implement body control functions or ADAS/AD functions. AUTOSAR Adaptive requires a POSIX operating system like Linux. For running safety critical applications, the Linux OS needs to be certified for functional safety (ISO 26262). The target ASIL level for Linux is ASIL-B. AUTOSAR Adaptive executes applications as processes of the POSIX operating system. This provides flexibility, as the applications can be updated during runtime.

A standard Java VMs like OpenJ9 is not certified for functional safety and therefore can be used only for ASIL-QM vehicle functions, such as cloud integration and as an alternative to Android Automotive to implement user interfaces.

Evolution of the software architecture

Decoupling hardware from software is the key concept to enable the SDV. The automotive industry invested heavily in standards like AUTOSAR since 2002. AUTOSAR Classic standardizes the software architecture of ECUs and improves the complexity management of integrated E/E architectures through increased reuse and exchangeability of software modules between OEMs and suppliers. It provides a standardized basic software (real-time operating system) and middleware (virtual function bus). AUTOSAR classic supports signal-based communication on CAN, LIN busses etc., It is used in deeply embedded systems with up to ASIL-D functional safety level, like engine control systems or braking systems. Applications for AUTOSAR classic are written in the C programming language.

Updating of these systems was initially not considered when AUTOSAR classic was specified. With the introduction of ADAS systems and their extended computing power and OTA updates, a more flexible solution than AUTOSAR classic was needed, which was specified as AUTOSAR adaptive. AUTOSAR adaptive supports a service-based communication based on Ethernet and SOME/IP. AUTOSAR adaptive is used typically on high-performance systems, like ADAS/AD systems, which can be updated over the air. Applications for AUTOSAR adaptive are written in the C++ programming language. The AUTOSAR adaptive software stack requires to run on POSIX operating system.

Although AUTOSAR decouples hard- from software and provides standardization and middleware, the application development for automotive applications is still complex and slow compared to PC and smartphone applications. Functional safety requirements require intensive testing and validation.

Automotive E/E, hardware and software is a system of systems. Developing a new feature in software needs to consider the whole system. For the SDV the OEM needs to provide software-platforms, including full software stacks for specific E/E hardware configurations. OEMs often call this a operating system (e.g. VW.OS, MB.OS), which should not be confused with an operating system like Windows or Linux. Instead, these automotive OS, include a complete software stack of bootloaders, hypervisors, device drivers, operating systems (Linux, real-time OS, Android), middleware (AUTOSAR classic, adaptive etc.), virtual machines / containers etc.).

AUTOSAR classic and adaptive are key software standards for the automotive software. Additional standards and initiatives like the Eclipse SDV and SOAFEE initiatives are required to realize the vision of a vehicle operating system for the software-defined-vehicle.

Container technology used in the vehicle

To support flexibility and easy, consistent deployments, containers became popular in the IT industry and cloud environments. Containers are software packages that include the code and its dependencies like libraries, tools, settings, and required runtime components. Container images can be layered, means they can depend on already existing images, which themselves depend on other images and so on. This layered approach is a great means to define clear dependencies without overhead. Containers therefore provide a big advantage in managing the complexity of interdependencies of software components. In the automotive industry, the version and configuration management across different vehicle models and configurations is a major challenge and will even increase with more and more vehicle functions implemented as software. Containers are lightweight, portable, secure, and are providing an insulated space, which increases stability of the system. By separating the software from the operating system, containers can be easily transferred, which is a big advantage for OTA.

Although container technology requires more hardware resources, it is used more and more in the vehicle. To execute the containers, a container runtime like Podman or more sophisticated platforms like Kubernetes on top of a Linux operating system on the HPC is required. The middleware will integrate V2X access to the cloud, provide service-oriented in-vehicle communication and utilize container technology for OTA.

Container technology successfully used in the IT industry can be used in the automotive industry to simplify over-the-air update, enhance scalability and robustness, and manage the dependencies of hardware and software configurations.

Platform and API management

Application programming interfaces (API) define the services provided by the cloud backend to the connected vehicle. The SDV will use a multitude of services for the different vehicle domains. Over time, these services and their APIs will change. The in-vehicle software will change during the lifetime of the vehicle, due to feature updates and new features provided by the OEM or by external organizations, including V2X scenarios with smart infrastructure. With the introduction of new vehicle generations, the feature set will increase, requiring additional backend services. Other backend services will be updated, resulting in a new version of the API, or removed if not used anymore. In this complex scenario of software and service configuration and dependency management, the in-vehicle software platform and the service APIs need to be managed. In the IT industry, http-based APIs are commonly used to manage microservice based solutions. Microservice architectures, including concepts to secure the vehicle to backend communication, can be leveraged for the connected vehicle. API management is an essential part of the solution to manage the services provided by the backend in dependency of vehicle hardware and software configurations and changes to the set of provided features.

With the increasing use of microservice based communication from the vehicle to the cloud backend and the continuous update of software defined features, software platform and API management becomes a necessity to manage the increasing complexity of API and software dependencies.

Infotainment

Car owners expect that apps (like Spotify or Netflix) running on their smartphones to be available on their car’s head-units and rear seat entertainment systems. Android Automotive targets this market and provides Android apps customized for the use in the vehicle, considering special requirements like the avoidance of driver distraction, different screen sizes etc. Some OEMs have decided to integrate Android Automotive into their cars. Other OEMs only support Android Auto, or Apple Carplay, which mirror the app content on the head-unit display, but don’t integrate deeply into the car. Considering the high value of vehicle data and dependencies of OEMs on Google in case of Android Automotive, OEMs are considering alternatives to Android Automotive. One possible solution is the development of a custom Android Automotive solution based on Android Automotive open source (AOSP). In this scenario the OEM needs to provide a custom app store, because the custom Android Automotive device is not certified by Google and therefore not allowed to access the Google Playstore. The regional availability of internet services needs to be considered. For example, China requires different service providers than the EU or US. Google Play Services are only available for certified Android Automotive devices and not available in China.

Apple announced in June 2022 to upgrade its CarPlay solution to integrate not only with the vehicle infotainment system, but also with the instrument cluster user interface. This deeper vehicle integration and functional safety requirements requires a closer collaboration of the OEM with Apple.

Seamless integration of smartphone apps into the infotainment of the cars is expected by the users. Android is used as an operating system and software platform which is running on the infotainment ECUs. In case the OEM decides to use the open-source version of Android (AOSP), the OEM needs provide services and App stores comparable with Google Play Services and the Google Play Store.

DevOps for vehicles

The SDV requires an integrated backend and in-vehicle architecture (see Figure 4). To support continuous development and roll-out of features, DevOps methods and tools can be applied to automotive software development and operations.

The SDV is always connected to an edge service provider (telco) to access services provided by the backend. New technologies like 5G networks provide high bandwidth with low latency. These mobile networks enable new mobile services for vehicles and their passengers. The SDV is connected to a content delivery network (CDN) to receive OTA updates of its firmware and software and multimedia or streaming content. All communication to the cloud is strictly secured by cybersecurity components. OTA updates include all layers of the vehicle software including

• board support packages, drivers etc.
• the Hypervisor used for virtualization on HPCs
• different operating systems (Linux, ROS, Android Automotive, AUTOSAR Classic), including Container runtimes and platforms
• middleware components (Adaptive AUTOSAR, Java JRE)
• application software (AUTOSAR Classic Apps / SWC, AUTOSAR Adaptive Apps, Android Apps, Java Apps)

Security build-in

Security is an integral part of the SDV across all components. On the backend, a security operations center (V-SOC) for the fleet of vehicles is necessary.

With a vehicle always connected to the internet and using more and more different online services, the vehicle attack vector for cybersecurity attackers is increasing. The cybersecurity threats need to be carefully addressed.

A security operations center (SOC) is a centralized organization that deals with security issues on an organizational and technical level. By using analytics and vehicle remote access, the V-SOC can analyze cybersecurity threats and provide counter measures such as providing an OTA update to a certain group of vehicles. All OTA updates are managed in the vehicle operation center. Exact and up to date configuration and version information and compatibility of software components is required to release and distribute OTA updates to specific vehicles.

All vehicles and their users are identified and access to the vehicle is controlled in the vehicle operations center. Identity and access management supports use cases like lost keys or vehicle theft. Identity, access, and vehicle data are sensitive information. The vehicle operations center provides means to enforce country specific data security and privacy rules for the vehicles and their users.

Backend vehicle services

The cloud backend provides services to the SDV and allows flexible and fast implementation of new revenue streams for the OEM. Some vehicle services are:

• Apps and streaming of media content in in-vehicle infotainment systems.
• Emergency services like eCall are already mandatory in some geographies. Crash and pre-crash data can be collected to improve machine learning algorithms for autonomous driving.
• Remote services provide already common features to detect the vehicle location, control access, and provide information such as remaining range, next scheduled maintenance etc.
• Navigation, parking, and weather services will be extended by future vehicle to infrastructure and other external information (vehicle to everything, V2X). The vehicle will be deeply integrated into the infrastructure and get online information about its environment. Current HD maps with linked context are essential for autonomous driving (AD).
• Maintenance and repair services are based on remote diagnostics and combined with analytics and AI to support maintenance and continuous feedback for product improvement.
• Fleet management services provide up to date information about a vehicle fleet and individual cars to leasing companies or other fleet operators. Fleet management is a cornerstone for shared mobility.
• Partner portals allow external companies, such as insurance companies, access to fleet and individual vehicle information.
• Electric vehicles services provide calculation of routes based on available charging stations and vehicle battery status.

To develop and operate the SDV, a new integrated approach is required. In the IT industry, DevOps processes based on cloud infrastructure to develop and operate products are successfully established. As software becomes the focus for automotive OEMs, DevOps principles can be applied to vehicle development, maintenance, and operations.

The cloud infrastructure hosts all IT processes. Different cloud hyperscalers, and public and OEM private clouds will be used. Therefore, a multi cloud management and common cloud security are required. Different OEM processes will exchange data and connect via APIs, managed by an API management solution. The OEM will be connected to telcos and other edge providers, but also to external environments, such as content providers (like Netflix), service providers (such as weather information providers), the suppliers of the OEM, and the public infrastructure.

Over-the-air updates (OTA)

As the network connectivity becomes ubiquitous, over the air updates or OTA is the natural choice for vehicle updates.

The two key aspects that makes OTA compelling includes:

1. Regular updates to the critical and non-critical software
2. New vehicle features may be bought or are subscribed by the car owners during the full lifecycle of the car pushed via OTA with possibilities of features as a service. Thus, providing new revenue streams to the OEM

The software-defined-vehicle is the essential framework for the overall OTA that can be technically categorized into two parts:

1. Software Over the Air Update (SOTA) as the name indicates, includes updating software components within the vehicle and
2. Firmware Over the Air Update (FOTA) that includes the process of updating firmware over the air i.e., the system software that controls the underlying hardware.

Further OTA can be functionally categorized as the following:

1. Infotainment and Navigation Updates – includes IVI and navigation updates targeting user experience as well as to maintain map currency
2. Energy Management Updates – crucial for electric vehicles, updates may range from updating heating / cooling system control, extended range etc.
3. Driving Control updates – includes all the drivability improvements and updates e.g., ADAS, adaptive cruise control, electric motor software, Body Control Module, Powertrain Control, intelligent brake, lane assist updates etc. Usually, these updates are pervasive in nature and thus can be updated only when the vehicle is stationary
4. Safety updates – includes critical safety updates to the powertrain, airbag, brakes, stability control etc.
5. Device and other feature updates – include updates to devices such as telematics, camera, Lidar etc. and other features such as voice assist, climate control etc.

There are several factors that must be considered while designing end to end, effective OTA solutions. Scalability is a key concern which is a function of the number of vehicles, vehicle models, fleet size, geographical coverage, types of OTA, number of features / devices being targeted etc. With several solutions for OTA updates and remote data gathering among the top Tier 1 suppliers and major OEMs, ensuing compatibility with OTA is a challenge. The choice between a proprietary platform vs a standardized open platform will be key from the standards aspect. Compliance and policies are two other factors that must be considered e.g., regulatory compliance such as GDPR, WP29, ISO22900 or other enterprise compliance. Similarly, the ability to configure multiple custom policies including notification, campaign deployments, rollback, installation, dependency, and variant management must be supported.

While most vehicle OEMs currently deal primarily with infotainment area, with SDV becoming a center point, the possibilities and need to extend across all the above functions will be necessary.

Continuous integration and deployment

Based on the cloud infrastructure, common continuous integration, and deployment (CI/CD) services are the foundation for the execution of the different OEM DevOps processes. CI/CD is key to fast development, integration, and test of new vehicle features. Common CI/CD services are version and configuration management for all development artifacts and source code. Packaged executable software is stored and managed in an artifact repository. The CI/CD environment provides build and test pipelines for software. Build, integration, and test is performed on different stages, from developer stage, over module, ECU to the whole vehicle integration stage. Software is continuously deployed to simulation, virtual test, software-in-the-loop (SiL) and hardware-in-the-loop (HiL) environments. Exact status information about success / failure and quality and KPIs are provided to make the process as transparent as possible.

On top of the CI/CD tool chain, the different engineering and software development, maintenance and operations processes are implemented:

• The E/E engineering process starts with the definition of vehicle features and requirements. These are the anchor points for all subsequent development, maintenance, and operation processes. Functional safety (ISO 26262) as well as vehicle security (ISO 21434) needs to be considered in the DevOps processes and is based on the principles of intentionality, reproducibility, and traceability. The E/E engineering software related processes include sub processes for the logical function architecture, the software and service design, the design of the hardware and network topology, and the design of the signal and the service-oriented communication. Hardware oriented processes include the hardware component architecture, the electronic circuit design, the wiring design, the geometric topology, and the harness design.
• Vehicle software is developed top down for vehicle features. In-vehicle software is developed in agile teams and based on DevOps principles. Goals are to completely automate the software development process and to reduce the number of different tool chains currently used. Nevertheless, Android Automotive and AUTOSAR Classic and Adaptive require different tool chains. Open-Source tooling avoids vendor lock-in and will be used more frequently for microservice applications and user experience applications and other high-level software. The vehicle software needs to be packaged in different containers to be provided to OTA and manufacturing processes.
• Software for autonomous driving is based on artificial intelligence (AI) and machine learning (ML) algorithms and training of deep neural networks (DNN), which require huge amounts of data. Data is ingested in a data lake and then labeled, filtered, and curated as training data. Analytics are required to get insights on the big datasets. The trained models need to be tested and validated by using simulations. The approved software is packaged and stored in the artifact repository.
• The connected vehicle mandates simultaneous development of in-vehicle software and backend-services. For backend services, different cloud-native technologies, such as microservices, can be used. Backend services are developed based on agile tooling and cloud toolchains. The backend services provide APIs to be used by in-vehicle software or by other backend services.

Containerized hybrid integration testing

As described in the previous chapters, the automotive in-vehicle system development process comprises various heterogeneous hardware and software components. For agile processes, frequent build, and early testing and validation, also known as shift-left, are mandatory. Traceability of requirements from design to their actual implementation is another key requirement to fulfill the compliance to automotive standards. The vehicle software is developed by several teams and close collaboration of the teams is very important. An overview of the status of the different teams and software applications and modules are necessary to track progress of the overall software development process.

Modern CI/CD systems provide multiple stages for improving maturity of the software from design to deployment. The processes and tools used in these stages are different for different organizations and depend upon the different types of software developed. For example, a deep embedded microcontroller with AUTOSAR classic requires a completely different process and tooling than an Android Automotive infotainment solution. Therefore, the CI/CD system needs to provide a high flexibility and it needs to be tailored for the specific team requirements. Although the tools and processes are adopted to the specific team needs, the overall processes for software integration and progress reporting needs to be consistent and standardized across the organization.

In the IT industry, cloud-based CI/CD systems using container technology are becoming the standard. As shown in Figure 5, a typical stack for a cloud native CI/CD system consists of following components:

Embedded software development is characterized by a very heterogenous tool landscape. Execution of several embedded tools in the cloud is not possible. To integrate these tools in a common CI/CD process, special plugins or containers implementing adapters to a physical tool installation can be implemented.

In-vehicle software is tested in software-in-the-loop (SIL) and hardware-in-the-loop (HIL) environments, using special simulations, test tools and hardware equipment. With the introduction of container technology in the vehicle, leveraging cloud-native CI/CD systems is possible. An AUTOSAR Adaptive application running on Linux can be executed in a cloud-native CI/CD system. The interaction of these virtual ECUs with other virtual ECUs can be tested using a virtual Ethernet between the containers. Beginning with virtual ECUs in the early stages of the development process, these ECUs can be replaced by physical ECUs connected to the CI/CD tool chain. This can be achieved by implementing plugins or container adapters to the physical devices. This approach can be visualized with a “reality slider”: Starting with virtual execution of the software, over to a hybrid scenario with a mix of virtual and physical devices, the software finally is deployed to the physical test devices and in the end to the real vehicle.

Based on containerized CI/CD systems, integrating virtual and physical tests can be used to integrate and test the vehicles software and backend services as early and as fast as possible.

Software version- and configuration management

The software version- and configuration management (SCM) is an important topic to support the OEM as a software company. With the increasing complexity of features, implemented as software, APIs and services, the compatibility of these components according to specific configurations and versions must be carefully managed. In case of issues, a traceability to the root cause is necessary for regulatory reasons and to provide fine-grained updates to fix the issue even for cars developed ten years ago.

An effective software company fosters re-use of software components, libraries etc. Therefore, the available artifacts to be re-used need to be easy to find for the developers and easy to consume. Some software companies like Google and Facebook use so called mono-repositories. In a mono-repository all software artifacts of a company are stored in a single repository. All developers have access to the company’s whole source code. Other companies use poly-repositories. The source code of different projects or domains are stored in different repositories. Both approaches have pros and cons which cannot be discussed in this article and are specific to an organization. Mono- and poly repositories can also be combined. For example, an automotive OEM may decide to store all sources of a domain (e.g., ADAS/AD) in a mono-repo and have another repo for other domains, like the infotainment domain.

Software version- and configuration management is the foundation for successful software companies fostering cross cross-team collaboration and software re-use and to manage the complexity and dependencies between software components and services.

Autonomous driving – the big loop

Machine learning for autonomous driving is based on sensor data. The training of neural networks depends on the quality of the training data. For higher level of autonomous driving even unusual events like avoiding a collision with deer needs to be trained. For these and other non-standard driving situations, the training data is rare. One possibility is to simulate these events, another possibility is to collect data from driving vehicles. The problem of collecting data from the vehicle fleet is to select or filter the right data from the huge amount of data generated during driving. It is not possible to transfer every sensor information to the backend for every driving situation. Important is to collect sensor information from certain driving situations, which can improve the training data set. An approach to identify and select interesting driving scenarios to improve the training data set is called the big loop (see Figure 6). The robotic loop to control the vehicle during driving is extended by a vehicle external loop to the backend to improve the machine learning algorithms by improving the training data set. The big loop consists of following process steps:

This closed loop between vehicle and software realizes a continuous improvement process for the machine learning algorithms.

Autonomous vehicles mandate unique architecture requirements with higher reliance on “fail-operative” strategy rather than “fail-safe” or “fail-soft”. The following are important considerations that are key in designing software defined vehicle architecture for autonomous vehicles:

Thus, there is high focus on in-vehicle computer systems to handle real-time sensor data processing, need for a range of sensor and vehicle module data processing, seamless integration with cloud to refresh the retrained model into the vehicle.

AI models and ML algorithms for ADAS/AD can be continuously improved by establishing the big loop, a continuous process to share vehicle data with the backend to update the AI models and ML algorithms.

Organizational Changes

The software-defined vehicle requires organizational changes and the introduction of open-source, agile and DevOps methods and practices in the automotive industry.

Automotive OEMs can also learn from the IT industry by utilizing and embracing open-source software (OSS) and practices. The usage of open-source practices in a company is called inner-source. Software companies can benefit of from inner-source practices to improve the open communication and collaboration and by merit-based decisions and proper quality-assurance. This is a fundamental change in the culture of the organization.

Today, many automotive OEMs are organized by the different vehicle domains or even by specific ECUs. According to Conway’s law, these organizations will design products reflecting their communication structure. Even with the introduction of the SDV, the different automotive domains will remain a hardware / software backbone to provide customer features. On top of this backbone and with the rise of centralized architectures and service-oriented architectures, the importance of cross-functional, cross-domain software will require changes to the organizational structure of the OEMs. Simply adding a layer on top of the existing domains will result in ineffective communication and not achieve the intended flexibility and speed of development. Therefore, new organizational structures and agile principle must be established. Software companies like Spotify use agile organizational structures like tribes and guilds and methods like Scrum and Kanban with great success. The automotive industry has specific challenges like hardware engineering and functional safety requirements. Applying agile methods and organizational patterns to an automotive organization needs careful investigation.

The increasing complexity of software leads to a high demand of automotive software developers. Automotive software includes embedded software and mostly written in C/C++. These automotive software skills are hard to find ion the market. The war for talent has just begun. To address this, use of open-source, and collaboration in an eco-system of open-source communities, suppliers, middleware providers and collaboration between OEMs for non-competitive software is key.

The SDV will lead to new collaboration models between OEMs, suppliers, and cloud providers.

With the need for high performance compute units in the infotainment and autonomous driving domains, the traditional collaboration model between automotive OEMs and suppliers is going to change. OEMs directly partner with chip makers like Qualcomm (e.g., BMW, Volkswagen) or Nvidia (e.g., Mercedes). Tier 1 suppliers try to establish own software platforms and partner with cloud providers (e.g., Bosch, Microsoft).

Key takeaways

• The software defined vehicle (SDV) separates hardware from software, is updateable and upgradeable, autonomous, always learning, always connected, interacts with its environment, and supports service-based business models.
• Decoupling of hardware from software and the introduction of software abstraction layers and platforms are the fundamental concepts seen in the telco, PC and smartphone industries which can be applied to the automotive industry.
• Fundamental changes of the vehicle E/E and hardware architecture are required to enable the decoupling of hardware from software, which is the core concept of the software defined vehicle. Based on this separation, further software architectural changes provide the required flexibility.
• With the introduction of high-performance computers (HPC) and in-vehicle high bandwidth networks like Gigabit Ethernet, the E/E architecture can be even further consolidated and centralized. HPC are a key element to enable the software defined vehicle. They allow execution of vehicle functions of different domains on a powerful compute-platform and allow easier update and upgrade of in-vehicle software.
• AUTOSAR classic and adaptive are key software standards for the automotive software. Additional standards and initiatives like the Eclipse SDV and SOAFEE initiatives are required to realize the vision of a vehicle operating system for the software-defined-vehicle.
• Container technology successfully used in the IT industry can be used in the automotive industry in the vehicles and in the cloud-backend to simplify over-the-air updates, enhance scalability and robustness, and manage the dependencies of hardware and software configurations.
• With the increasing use of microservice based communication from the car to the cloud backend and the continuous update of software defined features, software platform and API management becomes a necessity to manage the increasing complexity of API and software dependencies.
• Seamless integration of smartphone apps into the infotainment of the cars is expected by the users. Android is used as an operating system and software platform which is running on the infotainment ECUs. In case the OEM decides to use the open-source version of Android (AOSP), the OEM needs to provide services and AppStores comparable with Google Play Services and the Google Play Store.
• The SDV requires an integrated backend and in-vehicle architecture (see Figure 4). To support continuous development and roll-out of features, DevOps methods and tools can be applied to automotive software development and operations.
• Security is an integral part of the SDV across all components. On the backend, a security operations center (V-SOC) for the fleet of vehicles is necessary.
• As the network connectivity becomes ubiquitous, over the air updates or OTA is the natural choice for vehicle updates.
• Based on the cloud infrastructure, common continuous integration, and deployment (CI/CD) services are the foundation for the execution of the different OEM DevOps processes. CI/CD is key to fast development, integration, and test of new vehicle features.
• Based on containerized CI/CD systems, integrating virtual and physical tests can be used to integrate and test the vehicles software and backend services as early and as fast as possible.
• AI models and ML algorithms for ADAS/AD can be continuously improved by establishing the big loop, a continuous process to share vehicle data with the backend to update the AI models and ML algorithms.
• The software-defined vehicle requires organizational changes and the introduction of open-source, agile and DevOps methods and practices in the automotive industry.
• The SDV will lead to new collaboration models between OEMs, suppliers, and cloud providers.

Reference Architectures

The following reference architectures are opinionated and shall demonstrate how SDV topics can be addressed. The reference architectures only provide some examples and need further discussions in specific scenarios to meet the individual requirements.

Vehicle Onboard Architecture

The in-vehicle reference architecture basically splits workload based on its criticality (Figure 7).

• ASIL-D applications will run as AUTOSAR classic application with its integrated safety RTOS on top of Microcontrollers. Over-the-updates of these applications is not planned.
• Applications with safety levels up to ASIL-B can run on x86 or ARM Microprocessor architectures or GPUs. The applications are AUTOSAR adaptive, custom POSIX / Linux applications or Java or Android applications. Update of these applications over-the-air (OTA) is possible.

The in-vehicle communication is performed over the vehicle network / buses using communication protocols such SOME/IP or other automotive standards.

Red Hat is developing an in-vehicle Linux operating system with functional safety certification. This Linux will run on Arm, x86 or GPU based ECUs.

A typical HPC software-architecture includes a virtualization layer to run several operating systems in parallel. To run ASIL-B applications, this hypervisor needs to be ASIL-B certified as well. Virtualization is optional and Linux can run also run directly on the ECU hardware.

Updating the applications and managing the dependencies of applications and middleware components can benefit from container technology. To run containerized in-vehicle software, a container runtime like Podman can be integrated into the Linux OS.

For OTA, an agent software needs to run in the vehicle to connect to the cloud-based backend for receiving update packages.

IBM IEAP Edge AI & Middleware Technology

On the international automotive fair (IAA) 2021 in Munich, IBM presented our vision of an in-vehicle software solution for the management of software container, Java applications and AI models, incorporating our edge and middleware technology. The demo (please see Figure 8) showcased the following aspects:

• How to efficiently manage the lifecycle of in-vehicle
  • Software Container
  • Java apps and
  • AI models
• The enterprise level edge device management for vehicles
• A platform for managing all vehicle centric applications; can be used as OEM-specific app store
• The flexibility for orchestrating workloads from vehicle/edge to cloud
• How to enhance portability, productivity and maintainability of applications and system software
• It leverages the future Red Hat Vehicle OS incorporating all vehicle-specific required enhancements including a continuous safety certification for ASIL-B

The IAA demo was based on following technologies:

• IBM Embedded Automotive Platform, a Java Open J9 – Java Runtime environment for in-vehicles app
• Edge AI SDK by IBM Research, embeddable libraries of data and AI algorithms
• IBM Edge Application Manager (IEAM), for managing container workloads on edge devices from the cloud. IEAM is based on the Linux Foundation open-source project Open Horizon.

Over-the-Air Updates and data pipeline

Over-the-air (OTA) updates are essential to achieve the required flexibility of the software-defined vehicle. Vehicle features can be updated or upgrade over-the air. OEMs can also implement new features for an existing fleet of vehicles and distribute these via OTA updates of the vehicle software.

The eSync alliance of automotive suppliers is simplifying OTA deployments by defining and standardizing features and APIs for OTA updates and diagnostics. eSync seamlessly crosses boundaries of all in-vehicle networks to reach any eSync compliant module (TCU, ECU, IVI, ADAS, etc.). It covers cloud-to-car connectivity, vehicle gateways, data management, and middleware with end-to-end cybersecurity (Source: eSync alliance).

Excelfore and Red Hat created a reference architecture based on the eSync standards (Source: “Excelfore and Red Hat standardize automotive OTA updates”, see Figure 9).

The back end of this architecture consists of an eSync platform based on an OTA-server running on Red Hat OpenShift. In the vehicle, the eSync client runs on the gateway ECU, while agents in the vehicle run on ECUs or zonal or domain ECUs or sensors. Containers can be used for in-vehicle software and provide multiple benefits for the update and upgrade of the vehicles. Containers are self-contained entities, which ship with all the dependencies they need to be executed. They are lightweight and foster the re-use of common components and are therefore reducing the sizes of updates.

To support containers in the vehicle, a POSIX-compliant operating system, like the Red Hat in-vehicle OS, is required. This Linux includes a lightweight container runtime like Podman to run and stop the containers on the ECU.

Testing AI and MIL on SiL & HiL Environment based on OpenShift

Developing and testing autonomous driving (AD) systems requires the analysis and storage of more data than ever before. Clients who can deliver insights faster while managing rapid infrastructure growth will be the industry leaders. To deliver these insights faster, the underlying IT technology must support both new big data as well as traditional applications with security, reliability, and high-performance. To handle massive, unstructured data growth, the solution must scale seamlessly while matching data value to the capabilities and costs of different storage tiers and types. IBM provides solutions for artificial intelligence (AI) workloads with a focus on IBM Storage for AI with NVIDIA DGX support.

Artificial intelligence (AI) and machine learning (ML) infrastructures are essential to accelerate the development of autonomous driving. AI and ML are the underlying technology for all the major components in autonomous vehicles, including perception and localization, high-level path planning, behavior arbitration, motion controllers. It is required to rapidly build, validate, and manage scalable AI and ML jobs using a portfolio of integrated machine learning solutions that support the entire development lifecycle. The autonomous driving companies need to run quick experiments, enable re-usability and seamlessly build, deploy, and operate ML model’s at large scale. Software in the Loop (SiL) and Hardware in the Loop (HiL) testing is an integrational part of the testing process.

The machine learning lifecycle is a multi-phase process to obtain the power of large volumes and variety of data, abundant compute, and open-source machine learning (ML) tools to build intelligent applications. At a high level, there are four steps in the lifecycle:

• Data acquisition and preparation to make sure the input data is complete, and of high quality
• ML modeling, including training, testing, and selection of the model with the highest prediction accuracy
• ML model deployment in the application development process, and inferencing
• ML model monitoring and management, to measure business performance and address potential production data drift.

Machine learning developers are primarily responsible for ML modeling to ensure the selected ML model continues to achieve the highest performance metrics of interest. The key challenges ML developers face are:

• Selecting & deploying the right ML tools (ex. Apache Spark, TensorFlow, PyTorch, etc.)
• Complexities and time required to train, test, select, and retrain the ML model that provides the highest prediction accuracy
• Slow execution of ML modeling and inferencing tasks because of lack of hardware acceleration
• Repeated dependency on IT operations to provision and manage infrastructure
• Collaborating with data engineers and software developers to ensure input data hygiene, and successful ML model deployment in app dev processes.

A solution for autonomous driving AI and big data management requires following components

• A high-performance storage solution for big data
• A hybrid cloud infrastructure to host a container platform like OpenShift or Kubernetes
• A scalable, high-performance AI/ML server platform
• Integration with HiL / SiL

A reference architecture for autonomous driving AI and big data management is shown in the following diagram (Figure 10):

IBM Storage enables IBM’s customers to start small with affordable solutions for early experimentation, and then expand the performance and capacity to support production AI, analytics, and commercial applications at virtually unlimited scale.

RedHat OpenShift and Kubernetes containers are key to accelerating the ML lifecycle as these technologies provide data scientists the much-needed agility, flexibility, portability, and scalability to train, test, and deploy ML models. Red Hat OpenShift is the industry’s leading container and Kubernetes hybrid cloud platform. It provides all the benefits of container management and orchestration. The integrated DevOps capabilities and integration with hardware accelerators, OpenShift enables better collaboration between data scientists and software developers and accelerates the roll out of intelligent applications across hybrid cloud (data center, edge, and public clouds).

SuperPOD is NVIDIA’s next generation cloud-native, multi-tenant AI supercomputer. IBM supports SuperPOD with its storage solution ESS 3200. ESS 3200 is highly scalable. Adding systems linearly adds throughput, which is a great match to the SuperPOD architecture.

Based on IBM Spectrum Scale, ESS is part of IBM’s hybrid cloud strategy and so provides seamless access to all an organization’s data around the world with enterprise storage services. This enables businesses to leverage the power of SuperPOD across all their enterprise data.

CI/CD and hybrid testing

Organizations developing and operating software-defined vehicles require state of the art continuous integration and deployment (CI/CD) processes, including fast and reliable quality assurance. In the automotive industry software-in-the-loop (SiL) and hardware-in-the-loop (HiL) processes are commonly used. Current HiL/SiL processes are often performed with manual steps, interrupting the fully automated development and deployment process of the software. Setting up and updating HiL environments are difficult and expensive tasks. Testing of all possible vehicle models and variants is with HiL environments is not possible. This leads to the idea of virtual testing. Instead of testing against physical hardware, the communication partners of ECUs can be simulated. Virtual testing can already be utilized in the very early phases of the ECU development when other ECUs are not available yet. In later phases of the development virtual ECU will be replaced by physical ECUs and the testing becomes hybrid, including the traditional SiL and HiL tests.

Container technology provides mechanisms to easily manage and start

• test containers including virtual ECUs
• test containers connecting to HiL or SiL environments
• tool containers providing development tools like compilers, simulations etc.
• build pipelines to perform building and testing the software

The implementation of a CI/CD tool chain including hybrid testing is client specific and depends on the environments and tools available and necessary to build the software

• A cloud hyperscale to provide the cloud infrastructure
• A container platform, like Kubernetes or OpenShift
• A CI/CD tool chain based on Tekton, Jenkins, Argo (CD only)

A process implementation for the specific organization, adapting the available tools to the specific process requirements

An integration to artifact repositories to store the build results for late use during testing and deployment

An integration to a source code repository such as git, bitbucket etc. which contains the source code und version- and configuration control

Standards, initiatives, and open-source projects

Glossary of acronyms

• ACES Autonomous driving, Connected cars, Electrified vehicles, and Shared mobility)
• ADAS / AD Advanced Driver Assistance System / Autonomous Driving
• AI Artificial Intelligence
• API Application Programming Interface
• ASIL Automotive Safety Integrity Level, component of ISO 26262 functional safety, levels QM, A, B, C, D. With ASIL D having the highest functional safety requirements
• AUTOSAR worldwide development partnership of vehicle manufacturers
• CAN Controller Area Network, a vehicle bus system
• DevOps Development and Operations
• DevSecOps Development, Security, and Operations
• E/E Electric / Electronic
• ECU Electronic Control Unit
• FOTA Firmware Over The Air update
• Flexray serial, deterministic and fault tolerant bus system
• GPU Graphical Processing Unit
• HIL Hardware In the Loop
• HPC High Performance Computer
• I/O Input Output
• IVI In-Vehicle Infotainment
• LIN Local Interconnect Network, serial communication system for sensors and actuators
• ML Machine Learning
• NPU Neural Processing Unit
• OEM Original Equipment Manufacturer
• OTA Over The Air update
• OS Operating System
• OSS Open-Source Software
• Podman a container engine to run containers on Linux
• ROS Robot Operating System
• TCU Telematic Control Unit
• SCM Software Configuration Management
• SDK Software Development Kit
• SDN Software Defined Network
• SDV Software Defined Vehicle
• SOAFEE Scalable Open Architecture For Embedded Edge (SOAFEE)
• SOTA Software Over tThe ir update
• SIL Software In the Loop
• SOC Security Operations Center
• UX User Experience
• V2X Vehicle to Ev