Mulit-level system integration based on AUTOSAR

The design of distributed embedded real-time system is a challenging task. Besides solving the control-engineering issues, one has to consider real-time scheduling, reliability and production requirements w.r.t. production cost of the electronic control unit (ECU). This has a considerable impact on the employed software design techniques. These design techniques are well known in the automotive software industry, but are applied with different flavors at each vehicle manufacturer and their suppliers. This situation has changed considerably with the results of the AUTOSAR development partnership, which unifies the flavors of automotive software design. Automotive software design is embedded in the so-called V-Cycle of embedded automotive system development[1]. It starts with the requirements analysis which results later on in a model of the control algorithm. The control algorithm is tested against a vehicle model and establishes the topmost level in system integration. The second system integration level is the adaptation of the control algorithm to be run on a rapid-prototyping system. The rapid-prototyping system is integrated into an existing E/Earchitecture. The E/E-architecture consists of the ECUs connected by networks like CAN or FlexRay and gateways. Sensors- and actuators being used by several control algorithms are coupled to an ECU, which might propagate signals to other ECUs via a vehicle network. From the software point of view, the controlalgorithm has now to respect real-time scheduling and the quantization of the sensor- and actuator signals, no matter whether these signals are generated on the rapid-prototyping system or exchanged via the bus with other ECUs. Further development steps in the V-cycle are the software implementation, the ECU- and the network integration. The integrated ECUs and networks are tested against vehicle models running on Hardware-in-the-loop (HiL) systems. If this works fine, the ECUs are integrated in the real vehicle for calibration. The software implementation and the ECU integration are deeply influenced by AUTOSAR. AUTOSAR is a development partnership of all stakeholders in the automotive software development (e.g. vehicle manufacturers and their suppliers) which unifies several software implementation techniques[2]. It describes a common ECU software architecture[3] consisting of configurable basic software modules (BSW), a runtime environment (RTE) and a software component description[4]. The software component description describes the interfaces for dataexchange as well as the access points for the RTE. The basic idea of consisting of interconnected software components which are later mapped to an E/E-architecture. Currently, the VFB structure of AUTOSAR software architectures is mainly driven by the next generation E/E-architectures. The VFB structure forms the third system integration level. The next integration step into an AUTOSAR environment is the integration of the rapid-prototyping tested control algorithm to AUTOSAR software components. Since most VFB descriptions use fixed-point interfaces, the control algorithm has to be transformed to fixed-point arithmetic. If the control algorithm is modelled in tools like ASCET, this conversion can be achieved by code-generation. The same holds true for control algorithms already being used in E/E-architectures without an AUTOSAR software architecture. The VFB-description with the control-algorithms forms the fourth system integration level, which can be simulated with plant-models on a PC by tools like INTECRIO-VP. The fifth system integration level is given by the mapping process as defined in the AUTOSAR methodology[5] and requires the configuration of the RTE and the BSW modules for a single ECU. At this integration level, one can perform HiL testing and calibration in the same way as for non-AUTOSAR systems. Several evaluation projects, e.g. [6] and [7], have shown that the multi-level integration approach is feasible to guide the configuration capabilities of AUTOSAR software architectures.