10 YE ARS AUTOSAR ME THOD OLO GY
OEM SOFTWARE INTEGRATION INTO AN ASIL D CONTROL DEVICE Today, AUTOSAR defines the standard for enabling the tool-based exchange and reuse of software components across different OEMs. By its modular structure, AUTOSAR mitigates some potential safety issues. To meet the demands of the ISO 26262 standard, functional safety concepts remain indispensable, especially at the application level. Continental Engineering Services presents an efficient approach for integrating customer software into existing controller boxes, successfully used for software components up to Automotive Safety Integrity Level (ASIL) D.
AUTHORS
DR. MARTIN GRIESSER is Head of Chassis Engineering at Continental Engineering Services GmbH in Frankfurt/Main (Germany).
10 0
DR. FRANK SCHREINER is Head of Functional Safety Management at Continental Engineering Services GmbH in Frankfurt/Main (Germany).
DR. DOMINIK DÜCHS is Specialist for Functional Safety Management at Continental Engineering Services GmbH in Frankfurt/Main (Germany).
JÖRG CUNZ is Head of Chassis Software Platforms at Continental Engineering Services GmbH in Frankfurt/Main (Germany).
PROJECT DELINEATION
AUTOSAR mitigates some potential safety issues arising from obscure architectures often found in legacy software and also supports certain safety mechanisms at the basic software (BSW) level. Even so, functional safety concepts remain indispensable to meet the demands of the ISO 26262 standard. Continental Engineering Services (CES) developed an efficient approach to integrating customer software into existing controller boxes, which was used to integrate more than a dozen software components (up to ASIL D), and a four-digit number of communication interfaces between them, into a brake ECU. The project featured unprecedented collaboration between several of the OEM’s as well as the supplier’s departments. The accompanying test strategy using the automated CesATA test suite allows for full coverage of the requirements defined by ISO 26262. MOTIVATION AND OBJECTIVES
Two main objectives when developing safety-related software according to ISO 26262 are firstly to avoid systematic errors during software development; and secondly to implement safety measures
against random failures of the hardware used, in particular of the microcontroller. The latter goal is conveniently met by using modern microprocessors with safety features like dual-core redundancy which were themselves developed according to ISO 26262. Systematic errors, on the other hand, represent a greater obstacle. In the integration process of OEM application software, the runtime environment (RTE) is the central software layer handling the communication between application software components. It may contain thousands of potentially safety-related signals and is generated from description files by tools. Verifying such automatically generated code according to ISO 26262 long remained a challenge because the encountered complexity typically renders manual reviews unfeasible. Likewise, safety measures contained in the AUTOSAR BSW specification such as end-to-end (E2E) protection (especially for external signals), memory partitioning to aid in ensuring freedom from interference, time-out monitoring via watchdogs, or program flow monitoring cannot in general address all potentially arising systematic failures of the generated RTE, or they may drive up resource consumption during runtime to unacceptable levels. Breaking this deadlock,
CES has developed a cost-efficient, highly automated and ISO 26262compliant methodology to verify a generated RTE. PROCESS DEFINITION AND EX AMPLE FROM A CHASSIS ECU
The following example from a series project shall describe how customer software components have been integrated into an existing controller box and then the integration has been verified using highly automated processes. Both safetyrelevant (up to ASIL D) and non-safetyrelevant (QM) software components were encountered, with each ASIL level assigned its own memory protection unit (MPU) controlled RAM partition. The process is structured into several “gates”, ➊, which must be passed before proceeding to the next one. Once the last gate is passed, the integration process – including automated testing – is completed and the RTE has been verified in accordance with ISO 26262. At Gate I, as the first step in each integration stage, artefacts describing the customer software components (in an AUTOSAR-compliant way) in different files are delivered by the customer. They include the software component description (SWCD) as well as timing informa-
➊ Software integration and test process – mapping to the different chapters of ISO 26262-6 October 2013
AUTOSAR
101
10 YE ARS AUTOSAR ME THOD OLO GY
tion (Artime, Arexec), diagnostics (ODX), and communication (Fibex) information. The completeness of all artefacts is checked here to ensure a valid integration starting point. Afterwards, at Gate II, the input files received for Gate I must oftentimes be double checked regarding consistency, design or parser failures, or otherwise be made fit for use. So a consolidated set of system description files (SWCD etc.) is created at Gate III, BSW modules are modified or configured. The software architecture is created or modified. Software and interface requirements and a test specification are created. In the next step, Gate IV, the RTE is generated according to the consolidated system description files from Gate III using Continental’s own AUTOSAR development environment CessarCT (an Artop/Eclipse extension) and the RTE generator Cessar-RTE. Gates V and VI include BSW configuration and test development (design and implementation) and an integration test using stubbed versions of the customer software components. Finally, in Gate VII to VIII, the customer software is integrated and integration tests thereof are carried out and reviewed. Upon the passing of Gate VIII, the integration is complete. The various process steps of the software integration process relate to the chapters of ISO 26262-6, establishing the full ISO compliance. AUTOMATED INTEGRATION TESTING
Crucial to the ISO 26262-compliant verification of the integration process described above is an automated Continental test suite called CesATA. It generates stubs to be run in a Hardware-inthe-Loop (HiL) environment in lieu of the customer’s software components and writes its output into automated reporting files, such as spread sheet format, ➋. The part of CesATA verifying the RTE deserves particular mention. The RTE and the entire underlying layers of the BSW are assumed to be a black box. Since the RTE generator (Cessar-RTE, run on Cessar-CT) was deemed too complicated to be verified on a standalone basis, it was instead decided to verify the generated code on the target. A careful analysis of potential systematic failure modes of the RTE (ECU-internal and
10 2
➋ Automated integration testing using CesATA
external communication) yielded the need to test both the successful transmission of data as specified in the AUTOSAR system description files, ②, as well as the absence of cross talk in RAM and NVRAM blocks (freedom from interference) between the (many) buffers specified therein. Moreover, far from being restricted to merely the RTE, CesATA can be used to test all interfaces of an AUTOSAR software component, including, for example, NvM or DEM/ DCM services, parameter handling such as access to calibration parameters, or the dynamical behaviour of the software component scheduling. On the concrete customer software integration project, more than 1600 interfaces were exchanged via the AUTOSAR RTE for software components occupying approximately 1.2 MB of object code and using approximately 48 KB of RAM. As the project progressed toward completion,
the pass/fail ratio of the automated tests continuously improved despite integrating an increasing number of interfaces, ➌. SUMMARY
This article has shown that the ISO 26262-compliant integration of (many) safety-relevant customer software components can be carried out efficiently in the AUTOSAR framework. However, practical knowledge relating to the ISO 26262/AUTOSAR nexus remains scarce in the automotive industry. The longstanding experience of CES in this area affords their customers a high degree of planning security, thereby reducing the overall development risk. In this vein, CES can offer full-service packages including BSW, tools, training in methodologies, software integration services as well as Continental’s extensive product range.
➌ Failure rate and number of components versus project progress
INTERNATIONAL ENGINE CONGRESS 2014 ENGINE TECHNOLOGY IN THE VEHICLE WITH CORRESPONDING EXHIBITION
18 and 19 February 2014 Baden-Baden | Germany
SAVE THE DATE
MAIN SUBJECT AREAS: Basic Engine | Charge Exchange | Combustion (Gasoline/Diesel/Gas) | Exhaust Aftertreatment | Engine Management | Thermal Management
PROGRAM AND REGISTRATION: www.ATZlive.com
© Chisnikov - Fotolia.com
THREE PARALLEL STRANDS OF LECTURES ON PASSENGER CAR AND COMMERCIAL VEHICLE ENGINE TECHNOLOGY
