EN 
DE The (r)evolution of automotive software is progressing.
Author: Dr.-Ing. Detlef Zerfowski, ETAS GmbH
Contribution – Embedded Software Engineering Congress 2018
A look back at the „(R)Evolution“ of last year
The article „(R)Evolution of Automotive Software Architectures: How New Software Technologies Are Changing the Automotive Industry“ [2], presented at the ESE Congress 2017, reported on the triggers of the revolutionary changes in the automotive software industry. The trends described in the article have been confirmed in the past year. The revolution in the automotive software industry continues to progress.
The industry continues to grapple with the changes and the associated challenges. On the one hand, the transition from microcontroller-based, classic embedded control units to microprocessor-based or cloud-based solutions presents enormous challenges for development departments, such as how to change or expand the competency profiles of software engineering departments.
In Figure 1 (see. PDF) [2] the change in the required software profiles becomes clear. The software of the „Deeply Embedded ECUs“, which is strongly influenced by signal-based control algorithms, is characterized by strict real-time requirements, Automotive SPICE (ASPICE), V-model development, etc.
New vehicle computers currently under development are based on entirely different operating systems originating from the IT world and are introducing new software engineering paradigms to the automotive industry. The classic requirements-driven component development approach for vehicle computers is increasingly shifting towards a separation of software and hardware.
In addition, applications from smartphone ecosystems are increasingly penetrating the vehicle (Figure 1 bottom right).
Technological change in automotive software is accompanied by organizational changes in order to adequately address the challenges.
See Figure 2 (PDF)
As already explained in [2], we are faced here with 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.“
This means that products and their architectures follow the organizational structures. The existing embedded ECU business, which is focused on control unit components, is vertically organized from the OEM down to the suppliers. Examples of this are the long-established assignment of functions to dedicated control units, which in turn are located within long-established domains and organizations.
From microcontroller with classic AUTOSAR to microprocessor with adaptive AUTOSAR
The embedded development described above is highly vertically integrated. The target hardware determines the maximum available resources, which are then allocated to the software functionalities via time-slice-oriented real-time operating systems. Communication structures between the various components in the vehicle are also severely restricted. Key design elements are statically defined CAN matrices that determine, even during development, which message is sent to whom and at what time interval.
This structure is also evident at higher functional levels. Functions assigned to control units once cannot be moved across control unit boundaries later, or only with very high effort.
On the other hand, a significant advantage of this approach lies in the enforced determinism of the control unit's behavior and the resulting ease of managing safety requirements. However, this design simultaneously hinders the adoption of modern software technologies originating from the IT industry.
Of course, aspects of horizontalization have also been promoted in the deeply embedded field. Examples include diagnostic standards and AUTOSAR. However, even in this context, the following applies: This is a centrally defined standard for basic software stacks for microcontroller ECUs, which has evolved over many years. The approach was to standardize as high a proportion as possible of hardware-related and application-independent basic software. However, in day-to-day operation, this horizontalization of functions is not apparent.
The situation is fundamentally changing with the advent of microprocessor-based vehicle computers.
Due to current market demands regarding connectivity, automated driving, electrification (Figure 3, see...). PDF) and new ownership concepts for vehicles result in massive shifts in functionalities between the computer nodes present in the vehicle, as well as entirely new functions that cannot be efficiently represented on µC-based systems.
This is where the new AUTOSAR Adaptive standard comes into play. This standard, designed for microcontroller systems, supports, for example, dynamic software changes, highly parallel architectures, and service-oriented communication. With these approaches, microcontroller-based computers are now being opened up not only to existing infotainment applications but also to functions with higher safety requirements than those found in the infotainment environment (Figure 4, see Figure 4). PDF).
Due to the dramatic increase in available computing resources (e.g., more than 1000 times the memory) during the transition from microcontroller to microprocessor systems, different basic software systems and development methods must be used. The use of POSIX operating systems derived from consumer electronics is absolutely essential.
It should be noted that the goal is not for AUTOSAR Adaptive to replace classic AUTOSAR. Both systems will coexist in vehicles (Figure 5, see below). PDF), since pure microprocessor systems are not suitable for real-time critical applications. Estimates suggest that fewer than 10% of the control units installed in vehicles will be microprocessor-based, but these will carry by far the largest share of the vehicle software.
This lays the foundation for greater horizontalization of the software within the vehicle. Decoupling the software from the hardware through the use of service-oriented architectures supports a significantly more modular structure of higher-level software layers.
See Figure 5 (PDF)
Horizontalization using the example of security
The increasing horizontal integration of systems can be illustrated in this context using the example of security. In the past, vehicles were "implicitly" protected by their physical boundaries. To gain unauthorized access to the vehicle network, physical access to the vehicle was necessary. Consequently, only the specific vehicle targeted could be manipulated.
With increasing connectivity, the attack vector changes completely (Figure 6, see below). PDFPhysical access to the vehicle is no longer strictly necessary, and a successful attack could potentially affect a large number of vehicles immediately.
To address this situation, security concepts and solutions must be established that do not stop at ECU boundaries. Multi-layered security concepts are required. These cannot be limited to parts of the software used in the control units. While the current security requirements in classic AUTOSAR represent an important building block, they are insufficient when it comes to ensuring security between AUTOSAR-based and other control units and vehicle computers. Holistic approaches are needed, such as those provided by ETAS subsidiary ESCRYPT. The fact that ETAS established its own automotive security company several years ago underscores the need for a more horizontal approach to security.
The introduction of vehicle computers must address the following challenges:
- Significantly more potential entry points for attackers need to be secured.
- Dynamic communication infrastructures require the use of security measures from the IT industry.
- The integrity of software that changes dynamically within the E/E architecture must be ensured.
- Security measures must be established that are effective across ECUs and vehicle boundaries.
- Security updates must be available over the air interface throughout the vehicle's lifecycle.
With all these challenges, it must be ensured that all components installed in the vehicle and their external interfaces function flawlessly from a security perspective. A single control unit can cripple the entire E/E network if communication is faulty (Figure 7, see Figure 1). PDF).
This necessarily implies that security is not a control unit-specific issue, but extends beyond their boundaries, across the entire vehicle, and into the manufacturing processes at the OEM and Tier 1 suppliers.
RTA-VRTE and AUTOSAR Adaptive
As mentioned above, AUTOSAR Adaptive represents a key component for vehicle computers and will further advance the horizontalization of software within the vehicle. Only one instance of AUTOSAR Adaptive on a vehicle computer was considered in this context. As long as only a single application domain runs on a vehicle computer, the use of AUTOSAR Adaptive software with a suitable POSIX operating system as the base software may be sufficient.
Regarding the requirements of future E/E architectures, AUTOSAR Adaptive is a necessary first step, but not a sufficient one.
Future vehicle computers, which serve as integration platforms for software functions from different areas with varying ASIL requirements, need platforms that meet these different safety requirements.
Flexible platforms are needed that scale via mixed µC-µP systems using hypervisor technologies and thus via classic AUTOSAR and AUTOSAR Adaptive (Figure 8, see below). PDF).
Furthermore, support for hypervisor solutions is required, enabling mixed ASIL applications with different operating systems to run on the same vehicle computer. This necessitates appropriate platform concepts to meet both safety and security requirements (e.g., freedom from interference).
For this reason, Bosch and ETAS are developing the RTA-VRTE (Real-Time-Application Vehicle Run Time Environment), which is AUTOSAR Adaptive compliant and provides additional, cross-ECU relevant platform functions. Particular emphasis is placed on an open, flexible framework to support easy integration of third-party software.
See Figure 9 (PDF)
VRTE thus represents another example of software horizontalization in the automotive sector. Future vehicle computers will therefore be built from a multitude of horizontal and vertical software components within the application domains. This results in a division and shifting of responsibilities, even leading to organizational changes, to counteract the effects of Conway's Law.
Summary
With the advent of microprocessor-based vehicle computers, the separation of software from hardware continues. At the same time, a significantly stronger separation of software into horizontal and vertical components will occur, leading to organizational changes in automotive companies.
List of abbreviations
|
HW |
Hardware |
|
SW |
software |
|
ECU |
Electronic Control Unit (Electronic Control Unit) |
|
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. |
|
RTA-VRTE |
Real Time Application – Vehicle Run Time Environment. |
List of illustrations
Figure 1: SW ≠ SW – Different types of software are penetrating the automotive domain
Figure 2: Conway's Law hits the automotive industry
Figure 3: Connectivity, automated driving and electrification are changing the automotive sector
Figure 4: AUTOSAR Adaptive closes the gap between classic AUTOSAR and infotainment
Figure 5: AUTOSAR Adaptive and classic AUTOSAR remain in the vehicle in parallel.
Figure 6: Security attack vectors are changing
Figure 7: Impact when security fails
Figure 8: VRTE beyond AUTOSAR Adaptive
Figure 9: Different software levels (L1 to L5) addressed by the VRTE
Bibliography
[1] Conway, Melvin E. (1968): How do committees invent?
https://www.melconway.com/Home/Conways_Law.html
[2] Detlef Zerfowski, SK Niranjan: „(R)Evolution of Automotive Software Architectures. How New Software Technologies Are Changing the Automotive Industry.“ Proceedings of the Embedded Software Engineering Congress 2017, Sindelfingen, December 4–8, 2017, pages 411–424
author
Dr.-Ing. Detlef Zerfowski (Vice President, ETAS GmbH) joined Robert Bosch GmbH after completing his doctorate in computer science (Karlsruhe Institute of Technology) in the field of medical signal processing. 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 became Managing Director of the Bosch subsidiary ETAS Automotive India Prv. Ltd. From 2015 to 2018, Mr. Zerfowski was responsible for the strategic direction of software topics in the automotive sector at Bosch within the Corporate Sector Automotive System Integration. Since May 2018, he has been responsible for security and vehicle runtime environments at the Bosch subsidiary ETAS.
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.
