ecu software module development process changes in autosar · pdf fileecu software module...

ECU Software Module Development Process Changes in AUTOSAR

Nigel Tracey, Ulrich Lefarth, Hans-Jörg Wolff, Ulrich Freund

ETAS GmbH

Borsigstraße 14

70469 Stuttgart

1 Abstract

The AUTOSAR approach to develop ECU Software modules requires a totally different ap-proach than today. To allow a smooth transition, several migration concepts are built-in in AUTOSAR or already available by modeling and code-generation tools. This paper shows how to construct AUTOSAR software-components to realize control-algorithms which can be used in a migration phase today as well as in future AUTOSAR vehicle networks.

2 Introduction

Current E/E-Architectures are characterized by a high number of ECUs (up to 70 in luxury cars), highly interconnected functions and more often than not late changes of functionality prior Start of Production (SOP). Furthermore, especially in chassis control applications, real-time-requirements and safety aspects become more and more prominent.

Using the traditional, ECU-centric approach to design E/E-architectures, the vehicle manufac-turer writes a specification of all the software involved, sometimes given to the supplier as an executable prototype. To ensure the interoperability of all functions, a communication matrix of all CAN messages is derived and given in parts to the appropriate supplier. Then, every sup-plier involved will start its own development cycle according to the V-model[10]. This situation is depicted on the left side of Figure 1. The first integration attempt (Integration Stage 1) with the final ECUs at the vehicle manufacturers premises usually leads to a failure. As a rule, some suppliers have to redesign their system only to see it failing again at the next integration (Inte-gration Stage 2), e.g. to problems with another ECU. Even worse, an ECU centric approach prevents the reuse of functionality across different vehicle platforms.

SupplierA

SupplierB

SupplierC

IntegrationStage 1

DistributedDevelopment

IntegrationStage 2

IntegrationStage 3

ModificationStage 1

Mod.Stage 2

SupplierB

SupplierC

SupplierA

Figure 1: Integration Problems in ECU Networks

Analyzing the reasons for failure in the integration phase exhibits the following problems: tim-ing problems, interface problems, and communication problems between the ECUs. The only problems which can be addressed during the integration phase at CAN message level are com-


munication problems. Interface as well as timing problems are associated to application design problems and can be sorted out much earlier in the design cycle – at the application level which is the appropriate level of abstraction. The limitations of the ECU centric design approach were detected quite early and let to the development of middleware-based ECU software architec-tures in development-projects like TITUS[5] and publicly funded research projects like AEE[9], Forsoft-Automotive[4], and EAST-EEA[11]. The efforts culminated in the creation of the AUTOSAR development partnership[12] which finished its phase I in December last year leveraging the results of all precedent efforts.

3 AUTOSAR, a Middleware-Based Software Architec-ture

To sort out interface problems much earlier in the design cycle than in the current, ECU-centric approach, AUTOSAR uses the so-called virtual functional bus to design the control-algorithms for the overall vehicle. On this virtual functional bus, all control-algorithm related interface problems are resolved. The virtual functional bus is organized in hierarchically interconnected software-components. In a mapping and configuration step, the virtual functional bus is trans-formed to networked ECUs running parts of the control-algorithm.

The main technical concepts of AUTOSAR[2] are:

• a virtual functional bus view of interconnected application software-components

• a software-component description of interfaces, internal behavior, and runnables

• an ECU network-description

• a system constraint description with pre-mapped signals

• a mapping description of software-components to ECUs, connectors to frames and run-nables to tasks

• a layered ECU software architecture with configurable basic software modules

• a configuration description of the basic software modules

Figure 2: The AUTOSAR Approach

The interaction of these concepts is shown in Figure 2. In the top, there are the application software-components with their ports. The ports are typed by interfaces and can be either of sender/receiver type (arrow shape) or of client/server type (UML lollipop notation). Addition-ally, there are so-called service ports which require standardized ECU services like NV-RAM management or diagnostics. Ports of the application software-components are connected by connectors. These connected application software-components establish the virtual functional bus and contain the control-algorithms. It is virtual because no assumptions are made on the underlying E/E-architecture because it can be designed completely independent of it. Therefore, the AUTOSAR approach allows a relocation of software-components from one ECU to another in different vehicle types (Baureihen).

The E/E-architecture is reflected in AUTOSAR by the ECU resource description and the so-called system constraint description. They describe the employed ECUs (and gateways) and their connection to the vehicle networks. They are shown in the middle of Figure 2. The system constraint description might also contain a mapping description of system signals to frames. It

ECU I

Virtual Functional Bus

AU

TO

SA

RS

W-C

1

AU

TO

SA

RS

W-C

2

AU

TO

SA

RS

W-C

3

AU

TO

SA

RS

W-C

n

...

ECU II

AU

TO

SA

RS

W-C

1

AU

TO

SA

RS

W-C

2

AU

TO

SA

RS

W-C

3

ECU m

AU

TO

SA

RS

W-C

n

RTE

Basic Software

RTE

Basic Software

RTE

Basic Software

...

VFB view

Mapping

System ContraintDescriptionECU

Descriptions

Tool supporting deploymentof SW components

Gateway

SW-CDescriptions

SW-CDescriptions

SW-CDescriptions

SW-CDescriptions


therefore constitutes a partial communication matrix. The application software-components are mapped to ECUs:

• All connectors, connecting software-components which are mapped to different ECUs, are subject to signal mapping. This means that the data-elements of the port’s interface are allocated to frames on the bus-system. After all of these “remote” connectors have been mapped, the communication matrix is established and the COM stack of all E-CUs can be configured.

• All connectors, connecting software-components which are mapped to the same ECU, will be realized by the runtime-environment (RTE).

The resulting system is shown in the lower part of Figure 2. Here all software-components are mapped to ECUs, and all basic software modules are configured.

A more detailed view of the AUTOSAR ECU Software-Architecture[3] is given in Figure 3. In the centre, there is the AUTOSAR runtime-environment (RTE) which realizes the middleware. On top of the RTE, there are the application software-components, as well as their dedicated counter-parts, the sensor- and actuator software-components. The difference is that generic application software-components can be relocated to other ECUs while the sensor- and actuator software-components come along with the ECU where the sensors and actuators are physically connected to.

Figure 3: The AUTOSAR ECU Software Architecture

Basic software modules, which reside the below the RTE in the AUTOSAR layered software architecture, are available for diagnostics-, the NV-RAM-management, and communication. However, their lower layer is given by the micro-controller abstraction layer (MCAL), which provides a very lean abstraction on the µC’s registers. Sensors and actuators are either coupled by the a combination of the ECU-abstraction layer or by complex-device-drivers. Both modules respect RTE-interfaces on the top while the ECU-abstraction layer uses the MCAL for register access of standard peripherals whereas the complex device drivers are using dedicated periph-erals for complex actuators, e.g. high-pressure injectors. Needless to say that AUTOSAR oper-ating systems leverage all advantages of OSEK operating systems. Other services are the func-

tion inhibition manager and the ECU-state-manager. In total, AUTOSAR specifies 46 basic software modules.

The AUTOSAR approach is accompanied by a methodology[1] as sketched in Figure 4. This methodology assumes that the ECU description, the system-constraint description and the soft-ware-component description is specified by the vehicle manufacturer. The software-components are mapped to ECUs and the interfaces of the software-components are generated. The result is a system-description. The ECU-extract of the system description, now containing the bus-signal description as well as description of the mapped software-components including the interfaces of the components (i.e. the generated header-files), is given to the supplier who implements the behavior of the software components, i.e. the .c file of the runnables, performs the mapping of runnables to OS tasks and configures the basic software modules like the COM-stack. Afterwards, the software is compiled, built and flashed to an ECU.

Figure 4: Overview of the AUTOSAR Methodology

In the long run, an AUTOSAR interface of an application software-component is realized by standardized ports, interface-types, and data-elements whose resolution in physical interpreta-tion is standardized too. This means that the virtual functional bus will consist of a great num-ber of standardized components and interfaces. Since the standardization of number and type of application is a long and winding road and the advantages of the software-component-based approach can leveraged today, there is a migration phase where the communication-matrix constitutes the system-constraint description, and the resolution of the bus-signals prescribe the scaling of data-elements in sender-receiver interfaces. Furthermore, in a migration phase not all software-components have to respect the AUTOSAR interface. As a result, AUTOSAR soft-


ware modeling concepts as well as the basic software modules can be validated in real vehicles without constructing the entire E/E-architecture of a vehicle from scratch.

4 The Virtual Functional Bus and Vehicle Dynamic Software Design

Figure 5 shows the chassis-control excerpt of a typical virtual functional bus. There are soft-ware-components for providing the wheel- and vehicle-speed, the lateral-acceleration and the steering-angle. This information will be used by an ABS-, a traction-control-, an ESP-, and a cruise-control-algorithm realizing the internal behavior of application software-components. These software-components provide data for the brake-actuators, the engine management a.s.o., also represented as application software-components using AUTOSAR interfaces. Signals are clustered in interfaces. E.g. the speed interface clusters the vehicle-speed and four wheel-speeds, and is provided to the ABS-, the ESP-, and the cruise-control-software-components.

Figure 5: Virtual Functional Bus Description of a Typical Cruise-Control System

As one can see, application software-components play an important role in the virtual func-tional bus description. The control-algorithms running the software-components are dynamic. Especially in chassis-control, they are developed using design techniques based on simulation, rapid-prototyping, and Hardware-in-the-Loop (HiL)-testing. If one uses model-based design, the models can be re-used in several stages of the design[10]. This situation is depicted in Figure 6. The logical architecture represents the software-components of the virtual functional bus. The internal behavior of the software-components is developed by means of a block-diagram language and is tested in the first step against a model of the driver, the vehicle and their environment. These tests are typically performed on a PC. In a second step, some soft-

ware-components are tested in the vehicle by means of rapid-prototyping where the control-algorithms are refined w.r.t. the real vehicle-dynamics. In both steps, the software-components realizing the control-algorithm use floating point arithmetic. This gives an early feedback whether the applied control-law will work at all without caring for implementation details like quantization and overflow. In step 3, production C-Code will be generated for the software-components which are mapped to ECUs. Production C-Code generators typically assume that the ECU does not support floating point arithmetic and require model annotation with quantiza-tion formulas. After having performed step 3, ECUs are tested against a vehicle-model running on a Hardware-in-the-Loop test system. If the ECUs have passed all test-cases, they are mounted into the vehicle. In step 5, the characteristics of the ECU software are now fine-tuned with respect to an actual vehicle.

Figure 6: State-Of-the Art in Model-Based-Embedded Automotive Software Development


With the current approach to design E/E-architectures, there are more than thousand communi-cation signals in a vehicle - clustering of signals is indispensable. The interface concept of AUTOSAR was especially developed for this purpose. For example, in the system-architecture shown in Figure 5 the antilock-braking system is embedded into a virtual functional bus along-side sensor-algorithms, an ESP, and a cruise-control system.

5 Application Software-Component Modeling in AUTOSAR

Application software-components are either composite or atomic. Only atomic software-components can carry internal behavior. The internal behavior of an atomic software-component is given by its runnables. Runnables trigger portions of the control-algorithm. For example, a multi-rate control-algorithm whose parts run in a 5ms and a 10ms loop, is realized typically in two runnables. The runnables are later on mapped to OS-task having the appropri-ate cycle-time. Runnables are not only limited to cyclic execution, but can also be triggered events like data-element received or mode-switch event.

AUTOSAR uses a type/prototype concept, where prototypes have the role of parts which be-come eventually instances on an ECU. Having a more detailed look on the Software-Component-Template, one realizes that an Interfaces-Type uses several Data-Elements as pro-totypes. These interfaces type the ports of a software-component type. Since a component can have several ports of the same type, they are prototypes too. The software-component type can exists several times as prototype in a compositions, where the top-level composition realizes the virtual functional bus.

Figure 7: Software Components of a Brake Slip-Control Algorithms

An example how to use the AUTOSAR software-component modeling means to develop chas-sis control-algorithms is shown Figure 7. It shows the structure of a simple brake slip control-algorithm[13] as used in ABS systems. The composition brake-slip control aggregates for each wheel a prototype of the atomic software-component WheelSlipControl. For every wheel-speed signal there is a port-prototype of interface type Speed_SRI, which is also used for the vehicle-speed. The same pattern is applied to the pressure request for each wheel. The WheelSlipCon-trol component has also two required ports1 with sender-receiver interfaces and one provided port, also using a sender-receiver interface. These ports are connected to ports of the brake slip control composition using delegation connectors. However, the VehicleSpeedDeMux software-component has to be added for compatibility reasons. Delegation connectors, which convey information from the “outer” ports of a composition to the ports of the “inner” components, must neither dispatch nor merge data. This means that the vehicle-speed signal must not be dispatched directly to the component prototypes but has to be relayed to a dummy component which uses then assembly connectors which are allowed to dispatch data. One solution to avoid the dummy dispatch component is to delegate the data to be dispatched to a component on the top-level, then dispatch to all receivers, and delegate down to the real receiver prototype.

Data dispatch can be arbitrarily done in an atomic software-component. A data-element-prototype in a sender-receiver-interface is read at a provided port-prototype in a runnable asso-ciated to a software-component and can be used in arbitrary expressions. If one wants to keep a structure similar to software-component-prototypes in the internal behavior, the modeling tool has to support this approach. The association of ASCET[6] with AUTOSAR can be used to achieve this goal. Software-components for behavioral modeling can be represented by ASCET classes, the methods are their runnables. These classes can be instantiated in ASCET modules where the methods are called from ASCET processes. Methods can be clustered to processes.

The brake-slip-control-algorithm, realized in ASCET as seen in Figure 8, consists of a class slip-control with two methods: One is called calc and expects the actual wheel-speed and the vehicle-speed as input and performs the computation, the other is called controlPressure and provides a pressure request according to the relative wheel slip. This class is instantiated for each wheel in the module brake-slip-control, which expects the wheel-speeds for each wheel and the vehicle velocity as input and provides a pressure request for each wheel as output. The runnable of the module, the process, calls at first the calc-runnables for each of the wheels by passing data from the receive-message to the formal arguments of the method calc. Afterwards, the process runnable calls the controlPressure method of every wheel-slip-control instance and put the values to the output-messages.

1 The term port is used for simplicity reason in the text and the fact that they realize port proto-types is neglected.


Figure 8: ASCET Model of a Brake-Slip-Control-Algorithm for all Wheels

Besides the brake-slip-control-algorithm, the simple ABS system does also contain a brake-deceleration algorithm, and an arbitration algorithm between both algorithms. All these algo-rithms come along as dedicated components. AUTOSAR compositions can be used to aggre-gate these prototypes of these components as shown in Figure 9. Assembly connectors are used to transfer the pressure requests from the slip-control component and the deceleration control component to the control-coordinator component, which uses a percentage of each algorithm’s request to calculate the actual request. Given the fact that all 3 components might bring along 4 runnables each from there atomic software-component, the ABS algorithm will be decomposed of 12 runnables which are likely to run on the same activation cycle.

If the internal behavior of all software components is modeled in tools like ASCET, the ABS control-algorithm can be tested on a PC against a vehicle and environment model, consisting of the wheel (including the tire), vehicle and road-surface model as shown in arrow 2 of Figure 6. It can be also run on a rapid-prototyping system (as shown in arrow 3 in Figure 6) and tested in the vehicle.

Figure 9: Simple ABS Control-Algorithm

In AUTOSAR, all software-components are meant to run on series production ECUs which typically require that the data-elements in the interfaces are integers representing physical val-ues in fixed point arithmetic. If the ASCET model shall run as a software-component on an RTE, the generated code has to obey fixed point arithmetic. As written above, this can be achieved by annotating implementation details to the model. Therefore, an implementation type for each variable and parameter of the algorithm has to be given. Its implementation-range is given by the bit-pattern, e.g. from 0 to 65535 for a unit16. The physical range is given by the resolution, e.g. from 0 to 255,89 km/h where one bit represents 0,125 km/h. Each data-element prototype in the interface has to reflect the implementation type. Look for example at the ASCET model of the wheel-slip determination of a very simple ABS control-algorithm as shown in Figure 10. The wheel-slip is given by the difference of the wheel velocity and the vehicle velocity (the latter is represented by the reference speed). It is normalized by the limited vehicle velocity (represented by the reference value) and written to the variable WheelSlip as second statement of the method calc of the wheel-slip-control class (whose four instances are shown in Figure 8).


Figure 10: ASCET Model Extract for Wheelslip Determination

All modeling elements used in Figure 10 are of model type cont. As can be seen in Figure 11, the model type cont is translated to a real64 type and has no physical limits. The resulting C-code is generated straight forward.

Figure 11: Default Annotation for Rapid-Prototyping Systems

self->WheelSlip->val=(referenceSpeed-wheelSpeed)/self->ReferenceValue->val;

This changes completely when floating point arithmetic is abandoned and fixed-point arithme-tic is introduced. This means not only to use integer values instead of floats, but also to imply a physical meaning. Of course, this quantization has to be reflected by the generated C-Code, where additional operations are introduced.

Figure 12: Annotation for a 16 Bit Implementation

_WheelSlip=(sint16)((referenceSpeed-wheelSpeed<<8)/(sint32)_ReferenceValue);

The bit patterns are represented in the type of the data-elements in a sender-receiver interface. In the migration phase, the AUTOSAR RTE assumes a fixed mapping from integer ranges to basic software types for configuration. From a modeling perspective, this means that a control-algorithm using floating point arithmetic employs different interfaces than a control-algorithm using fixed point arithmetic. If software-components are used for rapid-prototyping and AUTOSAR production ECUs, the different interface descriptions have to be reflected.

6 Model-Adaptation for the Virtual Functional Bus

The simple ABS control-algorithm is a composition of the components brake-slip-control, deceleration-control and control-coordinator. This composition requires the vehicle-speed, the wheel-speeds, and provides a pressure-request for each wheel. The composition and all its aggregated component prototypes assume fixed point arithmetic in their runnables and ports. In the simple ABS example, this composition realizes the control-algorithm-composition of the ABS functionality. In a migration phase, the system-constraint-description is the communica-tion-matrix. This means that signals are already mapped to frames. A first migration step is to create so-called migration-compositions. These migration-compositions have ports which are typed by sender-receiver interfaces derived from the frame types in the communication matrix. In particular, the data-elements of the sender-receiver interface are given by the signals in the CAN-frame. The resolution of the data-elements and hence their type is given by the resolution specified in the communication matrix. Quite often, these interfaces might carry additional status information. This requires that a considerable number of signal adaptations and re-groupings have to be done because there are adaptations which are not limited to different reso-lutions, but also use inbound coding likes 0xFFFF to indicate an invalid value of the vehicle-speed. These kind of adaptations cannot be handled by current code-generators and are also not meant to be handled by the runtime-environment. Therefore, dedicated adaptation-components have to be used in the migration phase and reflect the interfaces of the migration-composition. There are adaptation-components for required and provided ports. The required port adapta-tion-component de-multiplexes data-elements from the CAN-Frame derived interface type to an interface type specified in the required ports of the control-algorithm-composition. The migra-tion-composition for the ABS-function is shown in Figure 13. It consists of the control-algorithm-composition for the simple-ABS algorithm, but also of a signal de-multiplexer and a signal-multiplexer.

Adaptation-components perform all adaptations which go beyond different signal-resolutions. All necessary signal adaptations like grouping and generating the invalid values are done in the port adaptation-component.


Figure 13: Simple ABS Control-algorithm with Adaptation Components

Figure 14: Adapted ASCET Model of the Simple ABS

The merit of the migration phase is to show that algorithms using AUTOSAR software-component structuring means (interface, runnables, and multiple instantiation) are able to run on rapid-prototyping systems as well as on an AUTOSAR ECU software architecture using an RTE. The ASCET model of the migration composition is shown in Figure 14. The AUTOSAR structuring means for control-algorithms, the concept of migration-compositions as well as limiting the virtual functional bus to a single ECU and using the system constraint description have been successfully evaluated in body-electronics[8] and vehicle-dynamic applications[7].

7 Conclusion

AUTOSAR provides means for an easy integration of software-components based on a virtual functional bus description. AUTOSAR software-component design techniques can also be used for a detailed specification of control-algorithm structures. Applying these concepts to ASCET-models, AUTOSAR software-components can easily be tested on a PC, on a rapid-prototyping system, and on an AUTOSAR ECU employing an RTE.

Leveraging the AUTOSAR system-constraint description in a migration phase, the virtual func-tional bus can be limited to a single ECU while existing network description and communica-tion matrices are re-used, but the software-components have to be augmented by dedicated port adaptations. Appropriate tooling is the prerequisite to master all ECU software module devel-opment process changes in AUTOSAR.

8 References

[1] AUTOSAR: The Methodology, www.autosar.org

[2] AUTOSAR: Technical Overview, www.autosar.org

[3] AUTOSAR: The Layered Software Architecture, www.autosar.org

[4] Braun, P., Rappl, M.: A Model-Based Approach for Automotive Software Development, in OMER – Object-oriented Modeling of Embedded Real-Time Systems, Lecture Notes in Informatics (LNI), Volume P5, GI 2002

[5] Eisenmann, J., et al.: Entwurf und Implementierung von Fahrzeugsteuerungsfunktionen auf Basis der TITUS Client Server Architektur; VDI Berichte (1374); pp. 399 – 425; 1997; (in German).

[6] ETAS GmbH: ASCET User Guide V 5.2, Stuttgart, 2006 (www.etas.de)

[7] Freund, U., Möstel, A.: Model-based OEM Software Branding of AUTOSAR ECUs, 5th AUTOSAR Premium-Member Conference, Brussels 2006.

[8] Fuchs, M., Lersch, F., Pollehn, D.: Neues Rollenverständnis für die Entwicklung verteilter Systemverbunde in der Karosserie- und Sicherheitselektronik. In: Electronic Systems for Vehicles (VDI Berichte 1646), p 135 ff. VDI-Verlag, Düsseldorf, 2001.

[9] Migge, J., Elloy, J.P.: Embedded Electronic Architecture, 3 rd. OSEK/VDX Workshop, Bad Homburg 2000.


[10] Schäuffele, J., Zurawka, T.: Automotive Software Engineering, Vieweg Verlag, Wiesba-den, 2003.

[11] Thurner, T., et al.: The EAST-EEA project – a middleware based software architecture for networked electronic control units in vehicles. In: Electronic Systems for Vehicles (VDI Berichte 1789), p 545 ff. VDI-Verlag, Düsseldorf, 2003.

[12] www.autosar.org

[13] Reichel, H.-R.: Elektronische Bremssysteme, expert-Verlag, Renningen, 2003.

ecu software module development process changes in autosar · pdf fileecu software module...

Documents