EN 
DE How new software technologies are changing the automotive industry
Authors: Dr.-Ing. Detlef Zerfowski, Niranjan SK, Robert Bosch GmbH Automotive System Integration (C/AIS)
Contribution – Embedded Software Engineering Congress 2017
The entire automotive industry is currently facing dramatic technological changes. These changes result from the introduction of entirely new electrical and electronic architectures (E/E architectures) and, consequently, entirely new software architectures.
Triggers for changes in automotive software architectures
The entire automotive industry is currently facing dramatic technological changes. These changes result from the introduction of entirely new electrical and electronic architectures (E/E architectures) and, consequently, entirely new software architectures. Key drivers of this development include the following:
- Transition from µ-controller-based, classic embedded control units to µ-processor-based or cloud-based solutions
- Transition from control-based algorithms to data-driven algorithms (Artificial Intelligence, image processing, data fusion, connectivity)
- Separation of the software in the vehicle from the underlying hardware
Previously, vehicles could be considered "closed systems" from a software perspective, which, after delivery into series production, could only be modified under special conditions (i.e., in workshops). Today, modern vehicles are more accurately described as parts of the Internet of Things. This development leads to entirely different architectural drivers than in the past and has a direct impact on software architectures in the automotive industry.
Microcontroller-based ECUs and their architecture drivers
Since the introduction of ABS for passenger cars in 1978, a large number of electronic control units (ECUs) have been successively introduced into vehicles over the past decades. Today's premium vehicles now contain around 100 ECUs from various Tier 1 suppliers.
Over the past decades, these components have evolved iteratively within the framework of OEM-specific E/E architectures in the vehicle.
From the perspective of a Tier 1 supplier like Bosch, the ECU-specific architectures in an environment like the one shown in Fig. 1 The OEM retains control over the vehicle and its E/E architecture. According to the E/E architecture, the functions are assigned to the respective ECUs (function deployment). From this, the ECU specifications and interfaces are derived and then provided to the Tier 1 supplier as a requirements specification.
Tier 1 suppliers operate within a similar context for each product segment, working with multiple OEMs and optimizing their strategies through appropriate hardware platform solutions. In this situation, the hardware components define the essential architectural drivers for the software.
(see Fig. 1, PDF)
This pattern of collaboration can be found in the different application domains (body electronics, powertrain, chassis and infotainment) (see PDF, Fig. 2However, there are significant differences (processes, methods, and tools) in how products are developed in the individual areas. Consequently, the architectural approaches differ considerably across these areas. For example, while engine control units (ECUs) with a manageable number of hardware platforms have an extremely high number of software variants, the hardware in body computers varies much more, necessitating that software components for broader application be developed to be more hardware-independent. This led to the development of AUTOSAR approaches for microcontroller-based basic software stacks.
Microcontroller technology imposes restrictive requirements on available memory and processing time. Modern engine control unit software must make do with a modest 8 MB of memory. This results in a memory-optimized architecture for the software, which inevitably comes at the expense of maintainability.
Dynamic memory allocation should also be avoided due to limited resources and security concerns.
In order to meet the deterministic runtime requirements (also with regard to functional safety), real-time operating systems are used, which distribute the computing power among the different tasks via deterministically allocated time slices.
Furthermore, static communication structures (CAN communication matrices defined at vehicle level, which are fixed at the time of development) are used, which on the one hand make the systems less vulnerable to attacks by hackers, but on the other hand do not support flexible service-oriented applications.
Furthermore, the limited computing resources are taken into account by frequently using quantized numbers in integer arithmetic in implemented algorithms.
The listed architectural drivers significantly restrict the solution space for software architectures.
Also shown in Fig. 2 (see. PDFThe domain division shown, which has developed over several years at OEMs and Tier 1 suppliers, implicitly represents a key architectural driver – the distribution of the ECU components (and thus the software contained within them) across the different domains!
This is a case of „Conway’s Law“ [1]: „…organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”
In other words, architectures follow organizational structures. As long as tasks only need to be handled within existing organizational structures, this works well. However, when problems arise that cut across or lie outside of existing structures, suitable architectures often cannot be established. Organizational changes are the necessary consequence.
In the following sections, we will discuss how this development is currently taking place in the automotive industry. In summary, the following (non-exhaustive) software architecture drivers emerge for microcontroller-based systems, which are simultaneously being challenged by new technologies entering the automotive world.
| Architecture drivers | Impact on software architecture |
| Microcontroller hardware:
limited storage |
Memory-optimized software |
| Microcontroller hardware:
limited duration |
Focus on control-based algorithms (close to the physics of the vehicle)
Deterministic runtime conditions. |
| Organizational structures according to application domains | The solution space for software is limited to domain-specific hardware solutions. ECUs are distributed together with the software.
A cross-domain solution is difficult to implement. |
| Static communication structure (CAN matrix) | Data flows cannot be changed, or only with great effort and expense. Data transfer rates are in the lower Mbit/second range. |
| Limited update capability | Software updates are primarily for bug fixes and not primarily for adding new features. |
Microprocessor-based computers are conquering the vehicle
In the previous section, we described the environment in which automotive software has iteratively evolved over the past decades. The increasing networking of the automobile, including its components, and the introduction of microprocessor technology in vehicles are currently leading to a disruptive change in automotive software.
It should be noted that infotainment applications have been running on microprocessor-based systems with Linux operating systems for years. Therefore, some of the statements in the following sections are only partially applicable to the infotainment domain. Due to lower functional safety requirements and significantly less stringent real-time demands, infotainment applications developed separately from embedded applications. With the integration of application functions from different domains onto shared vehicle computers, the previous development paths are increasingly converging again.
Increase in computer resources
The most obvious effect of introducing microprocessors lies in the increased availability of computing resources. While a modern engine control unit has up to 8 MB of memory available (which houses the application software, the real-time operating system, and basic software), the first microprocessor-based systems have 8 GB of memory (SOP 2020), and subsequent systems will have 128 GB (SOP 2023). Although this still seems small from the perspective of consumer electronics, this increase by a factor of 1000 (SOP 2020) or 16000 (SOP 2023) has implications that extend far beyond the mere availability of memory.
The previously existing separation of domain-specific software onto dedicated control units is no longer necessary, as future vehicle computers will be able to represent a wide variety of vehicle functions on a single machine. Memory-optimized software designs and implementations are being replaced by software architectures that focus particularly on hardware independence and thus portability. This means that application software is becoming decoupled from the underlying hardware and can therefore run on computers in a different application domain. This has a direct impact on established business models and development organizations. (see figure). 2 in the PDF).
Departments that previously developed and distributed component-based solutions with integrated software in isolation must now develop cross-domain software solutions. The major challenge here is Conway's Law: existing domain-specific and hardware-oriented software architectures must give way to cross-domain architectures. However, existing organizational structures are hindering this transition. As a result, new, more software-oriented organizational forms are currently emerging in the automotive industry. Software architectures, and therefore software architects, are gaining significant importance and influence on product development.
In addition to the availability of large memory capacities, the increase in computing power from ~4 kDMIPS (current engine control units) to ~17 kDMIPS (SOP 2020) or ~300 kDMIPS (SOP 2023) enables a multitude of new applications that are not feasible on previous systems. The limitation to integer arithmetic, often necessary for microcontrollers, is eliminated, and data-oriented algorithms are increasingly finding their way into vehicles, culminating in artificial intelligence (AI) solutions on graphical processing units (GPUs).
This involves implementing functions that utilize partial functionalities from different domains (including connectivity and cloud services) and therefore can no longer be assigned to the classic automotive domains (see PDF Fig. 3).
Example friction coefficient map
An example of this is the so-called friction coefficient map, which provides drivers with information about dangerous road conditions (such as black ice, aquaplaning, etc.) in near real-time via an internet connection in their display.
The data for this friction map is provided by vehicles ahead, which use their ESP functionality (chassis application domain) to collect information about the current road friction coefficient. This information is sent via a gateway (body computer domain) to the service provider in the cloud (not yet covered by corresponding domains). The data provided by different vehicles is consolidated by the service provider and immediately distributed to the vehicles that have subscribed to the friction map service. Information about the immediate hazard ahead is displayed to the driver as a warning message and on the navigation map (infotainment domain). Additionally, the traffic jam assist system can reduce the vehicle's speed based on this information (powertrain domain). When used in highly automated driving, this information will directly influence the system and thus the driving behavior without driver intervention.
This simple example illustrates that the functional architecture, and therefore also the software architectures, must cover different compute nodes within the E/E architecture. E/E architectures vary from OEM to OEM. This must be taken into account during software design, ensuring a strong abstraction from the hardware.
(see Fig. 3) PDF)
Influences of connectivity
An additional aspect was already mentioned in the example above. Cloud connectivity creates data streams to and from the vehicle that could not be processed in a traditional microcontroller environment. The bandwidth of existing in-vehicle communication networks (CAN, LIN, FlexRay) is no longer sufficient for the resulting communication demands. For this reason, Ethernet (currently 1 Gbit/s) is being introduced in vehicles. An upgrade to 10 Gbit/s Ethernet is also planned.
This increase in bandwidth enables a vast array of new functionalities in and around the vehicle. However, this also means that the software architectures will fundamentally change. The existing communication via the aforementioned static and therefore deterministic communication protocols is advantageous when considering functional safety according to ISO 26262. With the introduction of Ethernet in the vehicle, service-oriented communication solutions will be implemented. Functions that were previously tightly bound to the respective communication interfaces will in the future receive data about services available in the vehicle or provide information about services offered. The available services can change during runtime or have varying levels of quality. This opens up entirely new approaches for fallback solutions.
Example of traffic sign recognition
As an example of service-oriented communication, we will take automatic sign recognition.
We assume that a camera in the vehicle records the traffic situation and, consequently, traffic signs. The vehicle's software detects and recognizes the traffic signs and displays them on the navigation screen. The driver may be informed if their current speed is too high.
Let's assume that for some reason (dirty camera, technical defect, etc.) the sign information is no longer available. Instead of simply omitting the information from the display, a service-oriented architecture can provide the data or local sign information from a cloud service in place of the missing camera information. This data will certainly be of lower quality, as the sign information is not always up-to-date everywhere.
Even if the connection to the cloud breaks down, it is possible to use static sign information from the vehicle's local navigation system.
Software architectures based on Quality-of-Service (QoS) approaches are significantly more flexible for such solutions, as the functions no longer need to consider the data source (including which specific computer in the vehicle). Only the data quality needs to be taken into account. This also makes it easier to move these functions to other computers within the vehicle.
In this context, the currently developing standard AUTOSAR Adaptive plays a key role, defining standards for interfaces for µ-processor-based basic software used in applications with special requirements regarding functional safety (ISO26262 with associated ASIL levels).
Impact of third-party software on the base software
In the preceding sections, we have not yet addressed a crucial aspect of the software for future vehicle computers. Who actually develops the software for these microprocessor-based vehicle computers?
As mentioned above, the scope of the software implemented in the vehicle computers increases by several orders of magnitude compared to the scope of the microcontroller software.
In the latter case, the Tier 1 supplier typically develops the software for the corresponding hardware. This also involves the use of purchased components, such as automotive-specific real-time operating systems and basic software stacks (e.g., AUTOSAR for microcontrollers). OEMs also contribute their own functionalities, which are integrated into the final software. In principle, all software components originate directly from the automotive industry and its suppliers and are therefore familiar with the specific requirements regarding functional safety.
Large suppliers like Bosch are also able to develop and deliver complete systems from a single source, i.e. with a development depth of 100%: the real-time operating system from the Bosch subsidiary ETAS, the basic software as an in-house solution from a cross-functional department for software (also sold on the market via ETAS) and the application software by the commissioned business unit.
This situation changes fundamentally with the use of microprocessors. Firstly, POSIX-compliant operating systems are used, which are not implemented as deterministic real-time operating systems. Secondly, hypervisors are used on vehicle computers to enable virtualization approaches for separating applications with different ASIL levels on a single computer. Neither the POSIX operating systems nor the hypervisors come from traditional automotive suppliers. The market segment for these types of software is currently undergoing rapid development. Therefore, it is all the more important that the automotive-specific solutions built on these systems are adequately encapsulated. A consistent layered architecture for vehicle computer software becomes essential.
Fig. 4 (see. PDFFigure 1 shows the layered architecture of the so-called Vehicle Run-Time Environment (VRTE), which will be used in future vehicle computers. The five layers of the VRTE represent successive encapsulations.
- the hardware-dependent software,
- the operating system-specific software
- the communication channels used (abstraction from CAN, FlexRay, Ethernet etc.)
- Computer-specific services (e.g., computer diagnostics) and
- Vehicle-specific services that are not available on today's microcontroller ECUs (e.g., Life-Cycle Management).
It should be noted that the software shown is not a monolithic structure, but rather a system of different software components from various manufacturers, integrated into a common framework and hardened for series production in the automotive industry.
Particular challenges arise for software integration and its security, as both proprietary "third-party" components and open-source software (e.g., in the operating systems used) must be employed. These aspects must also be considered in the design of the software architectures.
Influences of different types of software
The preceding discussion implicitly assumed that, despite the increased complexity brought about by the new vehicle computers, the fundamental development methodology of software engineers and computer scientists would remain unchanged. However, the reality is quite different.
The software for „Deeply Embedded ECUs“ is shown in Fig. 5 (see. PDFThe elements listed below left characterize the development process. It is particularly worth noting that the development processes are heavily influenced by the V-model and Automotive SPICE (ASPICE), both established in the automotive industry.
New types of software are being introduced with vehicle computers. In addition to operating systems originating from the IT world, other programming languages and paradigms are finding their way into the automotive industry. The classic requirements specification-driven, V-model-based development methodology is now meeting the agile, DevOps-driven development approaches that come from the world of internet development platforms. (See figure.). 5 It becomes clear that vehicle computers have a significantly greater overlap with IT software methods in terms of software. In addition, applications from smartphone eco-systems are increasingly finding their way into vehicles (Fig. 5 bottom right).
Together with the one shown in Fig. 3 The trend towards cross-domain architectures necessitates the consistent description and maintenance of software architectures across different software platforms and target systems. This presents a particular challenge for the automotive industry, whose products, compared to the fast-moving consumer products of the IT world, have significantly longer lifecycles and generally have to meet considerably higher security requirements.
As a consequence of what has been said, the automotive industry needs a significantly larger number of computer scientists with a wide range of software skills, in addition to the existing engineers in the control-based embedded world.
Importance of Functional Safety and IT Security
In the previous sections, an important topic and architectural driver was only touched upon briefly – the combination of functional safety and IT security. (The English language distinguishes the concept of safety much more clearly with the words "safety" and "security.") To our knowledge, the combination of these requirements is more pronounced in this sector than in any other. Even in aviation and rail transport, the situation is different. In both of these sectors, only trained personnel (e.g., pilots, train drivers, etc.) have access to the central systems of the vehicles. In the private car sector, however, every car owner essentially has physical access to the systems. Furthermore, the increasing prevalence of connectivity solutions and cloud-based services creates a growing attack surface for hackers.
This significantly increases the risk of unauthorized access to the vehicle's computer systems, which must be countered by appropriate security measures.
The approaches to functional safety in aviation and rail transport also differ from those in the automotive sector. Due to the comparatively small volumes of aircraft and rail vehicles and significantly lower commodity pressure, the former sectors sometimes employ fully redundant systems. Furthermore, aircraft and rail vehicles are inspected for potential faults at a much higher frequency than cars. Software architectures must address this aspect through appropriate safety and security concepts.
Vehicle computers with applications of varying ASIL levels require the separation or virtualization of application domains using hypervisor technologies. The hypervisor plays a central role in the software system, as it manages and monitors the allocation of computing resources to the different application functions.
This central position of the hypervisor within the system creates another key attack surface for software hackers. Therefore, deployed hypervisors must be thoroughly checked for potential security vulnerabilities.
Software architecture drivers and their documentation
In the preceding sections, we described a number of software architecture drivers that are gaining significant importance with the introduction of vehicle computers. With the increasing complexity and openness of software systems, much greater emphasis must be placed on well-designed software architectures that are coordinated with all relevant stakeholders.
Focusing solely on functional software aspects is far from sufficient. Fig. 6 (see. PDF) provides an overview of the essential domain-independent architecture drivers for µ-processor-based vehicle computers.
As part of the architectural design, it must be ensured that non-functional drivers are adequately considered and clearly documented. Especially in an increasingly heterogeneous and complex software environment, a stronger focus on software architectures is crucial. A starting point for the architectural design is the approach known as arc42, which provides a structuring aid for software architectures and comprises the following chapters or architectural views:
- Introduction and objectives:
Key influencing factors or forces that affect the software architecture. In particular, the business objectives that have a significant impact on the software architecture should be identified. - Boundary conditions:
Technical and organizational constraints, conventions, tools, stakeholders, etc. - Context delimitation:
Technical and professional context, external interfaces, etc. - Solution strategy:
Overview of architecture-relevant, fundamental decisions and solutions (e.g., using purchased software versus in-house programming) - Component view (building block view):
Overview of the first levels (hierarchical) of the system to be designed, including relationships and dependencies between the building blocks. - Dynamic time-of-flight view:
Description (e.g., as runtime scenarios including latency times) of the components, how they behave during runtime (i.e., processes, tasks, activities, interrupt calls, etc.). - Distribution view:
The highest level of hardware and technical infrastructure, describing where each sub-function is to take place. This is particularly important for distributed applications, e.g., software solutions that are not limited to a single processor (multi-processor solutions, connectivity solutions, allocation to different virtual machines, etc.). - Cross-cutting concepts:
Extensive section describing technical concepts (e.g., process control, error handling, logging, parallelization, user interfaces (UX) and much more) - Design decisions:
Key design decisions with reasons - Quality scenarios:
Description of limit or stress scenarios and the expected behavior of the system (e.g. under defined high load on communication buses) - Risks and technical debt
Documents risks from a software architecture perspective, which must also be incorporated into the project's risk management. - glossary
In the practical implementation of architecture descriptions, keeping the various views up-to-date and consistent is a major challenge, as they are often created across multiple documents and tools. For this reason, Bosch developed a corresponding arc42 profile for IBM's Rhapsody software architecture tool. The Rhapsody profile supports architects in designing and maintaining consistent architectures and their views.
We are providing this profile "as it is" as an addendum to the software architects community on the arc42 website. https://arc42.org/download#ibm-rhapsody-format Available for download.
Summary
In the preceding chapters, we discussed the disruptive changes in software development within the automotive industry. The introduction of microprocessor-based computing platforms in vehicles is resulting in a performance explosion in terms of memory, computing power, and connectivity, opening up entirely new solution spaces for previously unaddressed problems.
This explosion in performance is accompanied by
- an extreme increase in software complexity with regard to different types of software,
- different, overlapping development methodologies,
- with a simultaneous increase in the number of software suppliers involved,
- whose software components need to be integrated into vehicle computers and
- covering requirements for functional safety and security.
This situation can only be managed with a strong focus on software architectures and their relevant architectural views. This is the challenge currently facing the entire automotive industry.
List of abbreviations
|
HW |
Hardware |
|
SW |
software |
|
ECU |
Electronic Control Unit (Electronic Control Unit) |
|
OEM |
Original Equipment Manufacturer (in our context, the car manufacturers) |
|
SOP |
Start of Production |
|
kDMIPS |
„"kilo Dhrystone Million Instructions Per Second": a benchmark based on integer arithmetic for comparing computing performance |
|
AI |
Artificial Intelligence or Artificial Intelligence |
|
GPU |
Graphical Processing Unit, which is used as a processor platform for AI algorithms |
|
ESP |
Electronic Stability Program |
|
ASPICE |
Automotive SPICE: Automotive-specific maturity model derived from the ISO standard ISO/IEC 15504 (SPICE) for evaluating the development of electronic control units in the automotive industry. |
|
POSIX |
Portable Operating System Interface: A set of IEEE standards defining the Application Programming Interface (API) for POSIX-compliant operating systems |
|
arc42 |
Freely available structuring approach for architectures |
Bibliography
[1] Conway, Melvin E. (1968): How do committees invent?
[2] IEEE Standards Association: POSIX – Austin Joint Working Group
[3] Dr. Gernot Starke, Dr. Peter Hruschka: arc42 Resources for Software Architects
authors
Dr.-Ing. Detlef Zerfowski (Vice President, Robert Bosch GmbH):
After completing his doctorate in computer science (Karlsruhe Institute of Technology) specializing in medical signal processing, Mr. Zerfowski joined Robert Bosch GmbH. His 18 years of automotive experience cover embedded software development in various domains (body electronics, braking systems, parking assistants).
From 2009 to 2012, Mr. Zerfowski established a development department in India for the Automotive Electronics division. He then took over as Managing Director of the Bosch subsidiary ETAS Automotive India Prv. Ltd.
Since March 2015, Mr. Zerfowski has been responsible for the strategic direction of software topics in the automotive sector at Bosch in the Corporate Sector Automotive System Integration.
Niranjan SK (Senior SW Architect and Product Manager, Robert Bosch GmbH)
After graduating with a degree in Instrumentation Technology from VTU University, India, Mr. Niranjan SK joined Robert Bosch Engineering and Business Solution Prv. Ltd. India (RBEI) in 2005. For 12 years, he gained experience in embedded software development, particularly in the field of AUTOSAR and its application across various domains. From 2013 to 2015, Mr. Niranjan SK was Product Manager for AUTOSAR products at Bosch. Since March 2016, he has been working in the Corporate Sector Automotive System Integration, focusing on the company-wide implementation of software architecture methodologies.
Automotive – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of automotive/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Automotive – Expertise
Valuable expertise in automotive/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
