WIXLIB

E/E Architectures with AUTOSAR AdaptiveMore Performance, Please!Assistance systems for semi-automated driving, regular over-the-air updates and the subsequent installation of additionalsoftware will soon be standard features in many vehicles. Without new architectures and high-performance ECUs, however,these sophisticated electronic functions cannot be realized. What role does the new software standard AUTOSAR Adaptiveplay in this?Due to the above-mentioned functions, the amount andthan previously used real-time operating systems. To seam-complexity of software in the vehicle continues to increaselessly integrate these microprocessors into the existing ve-rapidly. This trend is by no means new. But right now, anhicle network, the middleware running on top of the oper-extraordinary number of sectors in the automotive indus-ating system is based on the standard AUTOSAR Adaptive.try are undergoing significant changes to meet new marketrequirements. This is particularly true for automotive elec-The E/E architecture of a vehicle is also going through atronics. Since the computing power required for the newchange. Domain and central server architectures integratetasks is high, microprocessors are increasingly being used inthe mentioned high-performance computers into the vehi-electronic control units (ECU) and complement the micro-cle. Supported by fast data networks and powerful proces-controllers previously used in the automotive sector. One orsors, the focus is no longer on efficient data transmission,more of these microprocessors, often in combination withbut on stronger decoupling of individual ECUs. Changing aa microcontroller, form so-called high-performance ECUs.single ECU should have as little impact as possible on theThe microprocessors in these ECUs are very similar to thoserest of the system. A typical approach is, for example, intro-used in smartphones or PCs and require new software ar-ducing service-oriented architectures.chitectures. One aspect of such an architecture is thePOSIX-compliant operating systems typically used to effi-New E/E Architecture with Central Serversciently utilize the computing resources. These operatingIn addition to decoupling individual components, increasingsystems allow a more dynamic handling of the executedthe reusability of hardware and software is another goal.software and abstract more thoroughly from the hardwareThis means that components can be used across vehicles01

Technical Article / May 2019Bild 1a: Distributed architectureBild 1b: Domain architectureBild 1c: Central server architecture02

Technical Article / May 2019and even manufacturers. With the classic E/E architec-each other in their properties. One example is the fastertures of recent years, this requirement cannot be met.start time of the microcontroller. After being switched on,Figure 1.a shows such an ECU-oriented architecture. Here,it is quickly ready for operation and can thus participate ina function is realized by exactly one ECU. It brings along ancommunication with other ECUs and perform its function.associated set of sensors and actuators and receives addi-Furthermore, even the highest timing requirements in thetional data from the vehicle network. The communicationmicrosecond range with low jitter can be met with a micro-matrix of the vehicle describes these necessary communi-controller. The microcontroller is also better suited if thecation channels between the ECUs. Such a design, howev-implemented function requires frequent interrupts.er, restricts reusability. Sensors and actuators are directlyThe microprocessor has its strengths in other areas. Mostconnected to a functional ECU. If these values need to beimportant is of course its performance. The used comput-used by other bus participants, the communication matrixing cores provide a higher clock rate and bring along manyneeds to be changed. To overcome this problem, the do-functions like high multi-scalarity or jump predictions,main controller architecture has been established (Figurewhich improve the average performance. Larger caches1.b). Typical domains are e.g. “Body”, “Drivetrain” and “Info-also allow the connection of slower but larger externaltainment”. The basic idea of this architecture is using onememory devices. In addition to more resource capacity, mi-powerful controller per domain, to which a large part of thecroprocessors offer better hardware virtualization support,necessary sensors/actuators is connected. In the domain, itmaking it easier to use hypervisor technology.also coordinates the subsequent ECUs. This greatly in-A further advantage of the heterogeneous equipment withcreases the flexibility for extending functionality within amicrocontroller and microprocessor lies in the fulfilment ofdomain, since adaptations often result in domain-localsafety requirements. According to ISO 26262, current pro-changes only. But the use cases mentioned at the begin-cessors achieve integrity levels up to ASIL B. By using re-ning cannot be assigned directly to a domain. Highly auto-dundancy, the ASIL D level required for highly automatedmated driving functions require information from all do-driving can nevertheless be achieved. In such a system, themains and also feed data back to them.additional microcontroller performs two tasks: On the oneThe next development step of this approach is the centralhand, it executes monitoring functions. Yet, it can also beserver architecture (Figure 1.c). The domains are combinedused to provide degraded functionality in the event of ain a large high-performance computer or computer cluster.fault, so that the system can continue to perform its func-However, there are more differences to the domain archi-tion with a high degree of reliability. This is an importanttecture than this. It is, for example, no longer possible tofeature required for fail-operational systems, i.e. systemsconnect the sensors/actuators directly to the central con-that must continue to function in case of failure (Figure 2).trol unit, since so many I/O peripherals cannot be connected to processors available today. Sensors/actuators areThe fact that the ECU is equipped with several program-now connected directly to the network as so-called “Smartmable components results in another aspect: From theSensors” and “Smart Actuators” and perform mechatronicoutside, it is still a single ECU. Internally, however, many in-tasks. Hence, they become ECU and vehicle independent,dependent software components implement the ECUsenabling a modular system design with a high reuse poten-functionality. This leads to technical and organizationaltial. With low-cost sensors, though, this procedure wouldchallenges. From a technical point of view, the componentsnot have a good cost-benefit ratio. To use these sensors,must be able to communicate with each other to provide athey can also be connected directly to the integration nodescommon function. The task of the ECU manufacturer isshown in Figure 1.c in blue. These node ECUs also have an-now to connect the components by using inter-processorother important function: They act as a gateway betweencommunication (IPC) and to describe the exchanged data.the bus systems of the sensors and actuators, i.e. CAN, LIN,This is a new task for the ECU manufacturer, as this stepFlexRay and Ethernet. In this network, Ethernet representsdid not occur in the previous workflow. Only the data ex-the main bus system in the direction of the central comput-change between the ECUs had to be described so far. How-er. A modular and functionally expandable architecture isever, this responsibility lays exclusively in the hands of thecreated by a suitably abstracted interface to the sensorvehicle manufacturer. The same applies to diagnostic func-and actuator ECUs.tions, software update and network management of thesystem: what has been defined by one party for more sim-Complex Architectures of a Central Serverple ECUs now requires distributed and coordinated realiza-Central servers or integration nodes are complex ECUs.tion.They usually consist of several microcontrollers and micro-From an organizational point of view, integrating the vari-processors. This heterogeneous structure offers some ad-ous software components represents an increasing chal-vantages, because controller and processor complementlenge. The modular design of the ECU and the POSIX-com-03

Technical Article / May 2019Figure 2: Typical safety architecture for autonomous driving with AUTOSAR Classic and Adaptive.pliant operating system make it easier to integrate soft-With a service-oriented approach, however, informationware from several independent teams. As a result, however,can be subscribed.the role of the ECU integrator is becoming increasinglyBut there are other, less obvious advantages: The hardwarecomplicated. This makes it even more important to supportdrivers and the high-level software are more strictly sepa-the ECU integrator with professional tools for his challeng-rated. The hardware-independent applications in the vehi-ing task.cle are therefore highly portable. This enables much greaterresource optimization than with AUTOSAR Classic ECUs.AUTOSAR Adaptive as Platform for Central ECUsFor example, software in the development phase can easilyAs already described, the software components executedbe moved between different ECUs if the resource limit ison the microprocessor are generally not based on the AU-exceeded to avoid changes in the hardware design. AnotherTOSAR Classic standard. Instead, AUTOSAR Adaptive isadvantage: The reusability of software components forused on this hardware to meet the requirements for modu-several vehicle types is increasing.larity, dynamics and update capability. AUTOSAR AdaptiveIn AUTOSAR Adaptive projects, the separation of softwareis becoming the de facto standard for high-performancefrom hardware also enables a completely new work distri-computer platforms in vehicles. The AUTOSAR Adaptivebution between vehicle manufacturers and suppliers.middleware uses POSIX-compliant operating systems suchWhereas previously functionality was always ordered as aas Linux, PikeOS or QNX and completes them with all nec-physical device in the vehicle, it can now be fully purchasedessary automotive extensions. One of the main functionsin software. To make this work, each AUTOSAR Adaptiveof AUTOSAR Adaptive is the communication layer ara::com.application is now a separate binary file. Application devel-This enables communication with other AUTOSAR Adap-opment is therefore independent of ECU development.tive applications as well as with other software compo-The driver of the vehicle can thus become an integratornents (SWC) in the vehicle (Figure 3).himself by installing additional applications from an appDiagnostics as well as security and safety functions supple-store.ment the functional features. This may sound very muchBut who is responsible if malfunctions occur in the systemlike AUTOSAR Classic basic software. However, there areon the road? An untested combination of applications couldseveral architectural and technological differences. For ex-be installed in the vehicle. This situation conflicts with theample, ara::com is a service-oriented middleware. This al-typical integration approaches in AUTOSAR Classic ECUs,lows dynamic communication paths to be established atwhere each configuration is thoroughly tested. To avoidruntime. This dynamism is a prerequisite for applicationtesting all app combinations, the freedom from interfer-software that can be installed during runtime. A classicence between the applications must be guaranteed. Com-communication matrix would have to be adapted to sendmercial operating systems can guarantee that memorynew content to an ECU.limits are not exceeded for safety-relevant applications.04