This article is authored by Ulrich Freund from Robert Bosch GmbH.
The automotive industry is a mechanical industry, where a passenger car consists of a powertrain, chassis, and body, with the body typically integrated into the chassis—forming a monocoque shell. The manufacturing of passenger cars has been optimized to accommodate mass production, and all other elements must adapt to this process. Over the years, the automotive industry has evolved into an ecosystem encompassing development, production, and aftermarket stages. Typically, the organizational structure of original equipment manufacturers (OEMs) and tier-one suppliers reflects these stages. Until recently, this ecosystem defined certain rules that the design of distributed embedded systems had to follow.
One of these rules states that unit production costs are critical, while development costs are merely an expense that can be disregarded. ECUs, networks, and software are all developed according to this model. For electronic products, the procurement price of silicon determines production costs, while software must be capable of fitting into chips.
In the field of computer science, the focus of software engineering is on reuse to reduce development workload. Application Programming Interfaces (APIs) in high-level programming languages (such as C or C++) are prerequisites for software reuse, while abstraction layers ensure that the appropriate API is found at the required level of abstraction.
Operating systems with kernel and user modes ensure that user processes are not disturbed through Memory Protection Units (MPUs). To execute code efficiently in RAM, Memory Management Units (MMUs) decouple virtual memory addresses from physical memory addresses. This is accompanied by appropriate inter-process communication methods and file systems for non-volatile data storage.
Cache hierarchies, multi-core processors, and multithreading were research topics in the early 1990s but have since become common knowledge.
Control engineering, including system theory and identification, aims to find suitable control algorithms and adjust a set of parameters based on the system. Nonlinear systems do not have available analytical solutions, thus requiring simulation and testbed/track-based approaches, supplemented by efficient measurement and calibration solutions.
Production cost-driven ecosystem
Twenty-five years ago, a computer scientist entering the automotive industry as a software developer would have been surprised by the software engineering methods employed at that time. For instance, subroutines were clearly the chosen method, while exchanging information between subroutines via global variables was mainstream—exactly what every software engineer learns in university as “what not to do.” However, with a little thought, one can identify a structure in the code that remains valid to this day.
According to task scheduling, data exchange between tasks requires dual global variables, while subroutines represent schedulable elements. However, it must be remembered that the transition from pure assembly language to C language was not realized until the late 1990s.
While this approach seems feasible in the powertrain and chassis domains, it first exposed its flaws in body electronics due to a higher degree of distribution and the need for reliable communication drivers.
CAN bus and OSEK operating system[4] and its task schemes, as well as a comprehensive approach for designing distributed deeply embedded automotive systems, were still missing at that time. However, the German and French automotive industries initiated preliminary development and research activities, ultimately leading to the birth of the publicly funded research project EAST-EEA[2] in 2001. By mid-2002, rumors about another initiative first emerged, which eventually became AUTOSAR in 2003.
TITUS[1] is a relatively closed approach, EAST-EEA encompasses multiple research directions, while OSEK-COM has yet to gain popularity, and AUTOSAR has received full support from the automotive industry. Over the past 20 years, AUTOSAR Classic has been recognized for its achievements:
• A meta-model-based design language, as described in research papers on architectural description languages at the time, aimed at overcoming the shortcomings of UML 1.x methods:
» The services required by components are as important as the services provided. In AUTOSAR terminology, there exists a type of interface that is instantiated as port prototypes in the context of software components.
» The hierarchy of software components, adopting the concept of delegation.
• Embedded automotive additional functionalities drew from EAST-EEA and ERCOS[3]:
» Clear distinction between data and method communication, including supplementary definitions for provided and required services.
» The so-called runnable entities describe the dynamic behavior of components, thus replacing the concept of processes in ERCOS. These runnable entities are mapped to tasks during OS/RTE configuration, addressing a flaw in the OSEK specification and associating behavior with entities in the architectural description language.
• The transparent ECU software architecture defines multiple abstraction layers and functional groups. These layers define the relationship of µC and ECU independence beneath the RTE. Functional groups categorize ECU software into vertical groups, such as communication, diagnostics, persistence, or encryption. Special functional groups are systems, including the operating system and I/O parts. The latter, together with dedicated sensor and actuator software components (SWC) (located above the RTE), form the reverse measurement chain of the system’s physical layer.
• The main pillar of the layered ECU software architecture is a unified communication stack, which not only provides signal-based communication solutions but has recently also supported service-based communication, such as SOME/IP. It supports various communication networks, from CAN-based LIN to FlexRay and Ethernet, the latter including TCP/UDP/IP.
• Real-Time Environment (RTE) generation is the key to merging computer science with the production cost-driven automotive ecosystem. One might think that the most resource-saving implementation is spaghetti code, while AUTOSAR provides the necessary elements to create well-structured spaghetti code. Suitable system and software component designs provide a C-API that software component implementers can rely on. Mapping/deployment information in system and software component descriptions is used to consolidate the C-API into a set of global variables, allowing for thread-safe information exchange between components. Thus, the source code of the software component implementation is merely a part of the “truth,” while the supplementary part is the system’s arxml design—or, in modern terms, the meta-information. The downside of this approach is that it requires establishing a very detailed system model in the early design stages and must have a thorough understanding of how the system works.
• The parameter configuration of basic software modules requires strict syntactic and semantic schemes. AUTOSAR adopts a rather unique approach to configuring basic software. Parameter definition files reflect the hierarchy of BSW modules. Configuration values reference parameter definitions for correct interpretation during header file generation.
• AUTOSAR supports unique handling of UDS (ISO 14429) diagnostics. This includes a set of C-APIs, parameter definitions, and exchange information (DEXT). There are also links between the diagnostic program and the application software components.
Thus, AUTOSAR Classic has become the common language for deeply embedded connected automotive ECU software design in a purely production cost-driven automotive ecosystem.
Without AUTOSAR, the principles of computer science would still apply in a purely production cost-driven automotive ecosystem, but with AUTOSAR, everything becomes transparent while adhering to common sense.
Case Study Driven Ecosystem
Thirty years ago, telecommunications and data communication professionals debated the attributes of communication channels, representing different ecosystems as we speak today. Although telecom network switches and mobile phone protocols have utilized a significant amount of software, the invention of IP voice and ultimately the connectivity of smartphones marked a disruption in the telecommunications industry, sometimes referred to as “digitalization.”
The implicit backend connectivity of smartphones popularized the term “ecosystem” and broadened the meaning of the term “operating system.” The embedded “voice communication” feature of phones is now merely an application on smartphones.
For the automotive industry, this “digitalization” is still ongoing, and the transition from a production cost-driven ecosystem to a CASE-driven ecosystem[5] is evident. Will the embedded electronic functions previously used for powertrains, chassis, and bodies merely be an application on a POSIX-based central ECU? AUTOSAR’s answer is: it depends.
From a computer scientist’s perspective, the technical implications of C.A.S.E are as follows:
-
Connectivity: Connecting vehicles to the internet poses the risk of attacks, necessitating security measures to protect the integrity of the systems. Achieving this requires additional hardware and software measures.
-
Automation: This is the goal that the entire industry and IT/tech companies are striving to achieve. Video perception algorithms require GPUs and hardware accelerators. Fusion and prediction algorithms demand powerful computing capabilities, making application processors and POSIX-based operating systems feasible. For neural network training, a permanent connection between the vehicle (more accurately, instances) and the backend of perception providers is preferred.
-
Sharing: Sharing vehicles instead of owning them means that users’ smartphones connect with the backend of the sharing company and the vehicle. This implies connectivity and security for shared vehicles.
-
Electrification: Pure electric vehicles require software that goes beyond pure powertrain management to enable medium to long-distance travel. This includes route planning, battery regulation, charging station reservations, billing, and more.
Other obstacles to “freedom driving,” such as road tolls, urban taxes, and parking management, require software-defined solutions for automatic access and billing.
Since 2003, computer science has evolved, with many non-theoretical concepts, particularly multi-core architectures and multithreaded operating systems, as well as reliable backpropagation neural networks, becoming common knowledge. Coupled with low-power SoCs, virtual machines, containers, and high-speed gigabit Ethernet connections, the differences between traditional computer science and embedded automotive software are narrowing.
On one hand, AUTOSAR reflects the progress of computer science by introducing the Adaptive Platform (AP) and renaming existing specifications as the Classic Platform (CP). Additionally, AUTOSAR explores new hardware features to appropriately enhance platform performance. On the other hand, the C.A.S.E driven ecosystem spans backend and vehicle boundaries and meets other paradigms, such as RESTful communication using appropriate object models (like COVESA and SOVD), or seamless deployment and orchestration of containers on target platforms or in the cloud (like SOAFEE). Furthermore, there are middleware solutions specifically for autonomous driving, such as using the AUTOSAR Adaptive Platform as a µP-based ROS runtime on SoC-based target platforms.
Conclusion
Over the past 20 years, AUTOSAR has created a comprehensive approach to designing deeply embedded software in a product cost-driven ecosystem with its Classic Platform.
As computer science advances, the AUTOSAR Classic Platform continues to play a role in the C.A.S.E driven ecosystem, driving hard real-time systems that power sensors and actuators, as well as SoC monitoring.
The AUTOSAR Adaptive Platform serves as the foundation for µP-based automotive systems while also establishing itself in SoC-based central ECUs. Thus, automotive software will transition from merely optimizing automotive mechanical components to becoming a core component connecting vehicles to the cloud. In fact, vehicles are evolving into rolling IT edge devices. It seems that combining AUTOSAR with COVESA, SOVD, and SOAFEE has the potential to lay the foundation for an open software-defined automotive platform.
REFERENCES
[1] [2] [3] [4] [5] U. Freund et al: Interface Based Design of Distributed Embedded Automotive Software – The TITUS
Approach, in VDI-Berichte (1547), Elektronik im Kraftfahrzeug, Baden-Baden 2000
U. Freund: EAST-EEA – A Middleware Based Architecture for Networked ECUs, Dagstuhl Workshop
for Software Intensive Embedded Systems—with Special Emphasis on Automotive, Dagstuhl 2003
S. Poledna, Th. Mocken, J. Schiemann, T. Beck: ERCOS – An Operating System for Automotive
Applications, SAE Paper No. 960623, Detroit 1996
John, D. (November 1998). “OSEK/VDX history and structure”. IEE Seminar on OSEK/VDX Open
Systems in Automotive Networks (Ref. No. 1998/523). 1998: 2/1–214.
Automotive World: C.A.S.E-“the future of the automotive industry”, www.automotiveworld.com/
articles/c-s-e-future-industry