SeamleSS Implementation. based on ISO 26262

Transcription

1 SeamleSS Implementation of ECU Software based on ISO Growing use of the ISO standard is producing clearly defined requirements for the development and validation of E/E systems. Vector describes a seamless methodology and tool environment for considering ISO in the development of ECU software that includes the Autosar platform. In particular, it is shown how references to safety goals and requirements are represented throughout the entire development. The Autosar basic software also supports Mixed-ASIL systems, which avoids the need to cost-intensively upgrade system functions with lower ASIL to a higher ASIL. In sum, this leads to clear cost advantages in developing safetycritical systems compared to not integrated method and tool environments. 10

2 AutHors Dipl.-Inf. Steffen Keul is Product Management Engineer for Autosar at Vector Informatik GmbH in Stuttgart (Germany). Dr. Eduard Metzker is Senior Product Management Engineer for Systems Engineering Tools at Vector Informatik GmbH in Stuttgart (Germany). Dr. Dieter Lederer is Partner and Managing Director of Vector Consulting Services GmbH in Stuttgart (Germany). Definition As a standard for the development of safety-related applications in the automotive industry, ISO [1] defines a basic framework for development processes and methods. Functional safety is viewed as an integral component of system development and is integrated in this process from the start [2]. To assure full coverage of safety goals and to document their fulfillment, the traceability of requirements must be documented down to the level of individual software work products such as code modules or test cases. If more complex systems are being developed, an integrated tool support is almost mandatory. In the following sections, these aspects are explained in greater detail, and the benefits an integrated tool support for system and software engineering are described. The technical example used for illustration purposes is a Lane Departure Warning (LDW) system. Hazard and Risk Analysis The next step is hazard and risk analysis, which is described in Part 3 of ISO The goal is to examine all system functions and determine the risks that could result from potential failures of the system. The identified risks are initially described based on operating situations and modes in which they could occur. Then they are classified in terms of their probability of occurrence (exposure), severity of their effects and the potential for risk controlling (controllability) in order to minimise any damaging effects. This is followed by assignment of an ASIL (Automotive Safety Integrity Level) to the specific system function. For all critical system functions, i.e. those classified as at least ASIL A, safety goals must now be defined whose fulfillment reduces the specific risk so that unacceptable effects are mitigated. An integrated system engineering tool, such as Vector s PREEvision, provides an environment for this, e.g. in the form of a table view that can be used to conveniently perform a hazard and risk analysis, 1. Operating situations and modes can be predefined and standardised, and automated ASIL assignment can be used. Functional Safety Concept In creating the functional safety concept, safety goals are refined by functional safety requirements, and allocated to the system functions that should fulfill these requirements. This approach progressively leads to the functional safety concept, which is independent of later implementation of functions in hardware or software. 2 shows which system functions must contribute towards attaining the relevant safety goals. Underlying them are the associated safety requirements. TeCHnical safety concept In creating the technical safety concept, functional safety requirements are refined 1 Hazard and risk analysis 05I2013 Volume 8 11

3 2 Functional safety concept into technical safety requirements, and system functions are assigned to elements of the technical system architecture, 3. In an early stage of development, it is sufficient to make assignments to the components of the system. In a later stage, the implementation in hardware or software elements is done. c shows an excerpt of the component network that is relevant for the LDW system. Safety functions and requirements are assigned to the involved components. Automated consistency checks immediately reveal, for example, whether the ASIL of the system function to be implemented and the previous qualification of components are incongruent with one another, see the components framed in red. Once the development has progressed to refinement to the software elements to be implemented, the resulting software architecture can be exchanged and enhanced with other tools, based on an Autosar-conformant description. This ensures consistency and traceability beyond tool boundaries. Safety Analyses Safety analyses such as FMEA or FTA are conducted to check the technical safety concept. The goal of these analyses is to identify potential weaknesses in the safety concept and eliminate them by suitable improvements. 4 shows the schematic of a system FMEA, which is applied to the safety concept. The advantage of an integrated tool is evident here as well: The FMEA is performed based on the data describing the existing 3 Technical safety concept 12

4 system, and the resulting measures are assigned directly to system components or elements. This makes it unnecessary to model the system structure in a separate FMEA tool, which would lead to both increased effort and potential inconsistencies and gaps in traceability. Safety Case The goal of the safety case is to demonstrate comprehensively and traceably that the system was developed so that it is free of unacceptable risks. The advantage of the integrated tool support that was presented in the previous chapters is once again evident here: all of the information needed for the safety case exists, is consistent and can essentially be called up at the press of a button and be exported as a report. This can be done at any desired point in time during development. Implementing Mixed-ASIL SysteMS with Autosar Regarding the technical safety concept for a LDW described above, the following challenge arises: if parts of system functions with different ASILs should be implemented on one system component, e.g. the Driver Assistance component shown in c, then in the absence of other actions this component must be developed to the highest ASIL. However, it is best to avoid this in practice, because this increases effort and costs. An advisable solution is to operate the parts of functions with different ASILs next to one another with mechanisms of the Autosar operating system such that they do not interfere with one another. This is referred to as freedom from interference, which must then be verified. This verification must consider three requirements that are described in the following three sections. Achieving Freedom From Interference Implementation of freedom from interference can be achieved by three modules in the Autosar basic software, which fulfill the following requirements: Correct timing behavior of the software: The Watchdog Manager is used to check for correct timing behavior. The user defines checkpoints, and when a checkpoint is reached the application software calls a function. If a checkpoint is not reached within the allowed time frame, or if checkpoints are reached in an incorrect order, a system restart will be triggered. Correct communication: End-to-end protection is used to verify correct communication between software components. Corrupt or missing messages are detected by transmitting and verifying checksums and sequential numbers for each signal group. Avoiding faulty memory accesses: The Autosar operating system forces avoidance of faulty memory accesses at system runtime using a hardware MPU (Memory Protection Unit). This involves partitioning the software into different OS Applications and only assigning those software components to one OS application for which it is known that the risk of mutual interference is acceptably low. The hardware MPU detects and prevents unauthorised accesses from one OS application to the memory area of another OS application. Context SwitCH versus Coexistence of SW Components Partitioning into separate OS applications enables implementation of a Mixed- ASIL system, i.e. safe use of software elements with different ASILs on a common hardware platform. However, when there is frequent communication between different OS applications, this causes longer execution times due to needed for the context switches. To counteract this effect, an alternative approach is to Application SWC Safe SWC Safe SWC SWC SWC Microsar RTE Watchdog Microsar OS Safe Context Microsar SYS Safe Watchdog Manager Microsar DIAG Microsar AMD XCP Microsar MEM Microsar CAN Microsar COM Microsar LIN Microsar FR Microsar IP Microsar MOST Microsar IO Complex Drivers Microsar CAL Microsar EXT Microcontroller Safety mechanism Safety related function Non-safety related function Autosar basic software 4 Autosar architecture with safety mechanisms 05I2013 Volume 8 13

5 strive for safe coexistence of software components within the same OS application. Coexistence can lead to improved performance, especially for basic software components. One method for verification of freedom from interference with regard to memory accesses of the basic software by using a code checker is shown in [3]. Availability Vector Informatik is the first manufacturer to offer an Autosar operating system called MICROSAR SafeContext, which is certified up to the highest safety integrity level (ASIL D). It implements safe management of contexts and thus memory protection for Mixed-ASIL systems. The operating system is supplemented by the certified mechanisms SafeWatchdog and SafeCom from TTTech Automotive GmbH, which are also capable of levels up to ASIL D. These mechanisms assure correct timing behavior and correct communication of software components. d shows an overview of these mechanisms in the Autosar architecture. The individual mechanisms are supplied as Safety Elements out of Context (SEooC). Sufficiently general assumptions were made for the safety goals of the SEooC, and they are specified in detail in the safety manuals. To integrate these mechanisms into their own safety concept, users can perform a check of assumptions, as specified in ISO From Software ArCHitecture to Code As explained in section Technical safety concept the PREEvision tool can be used to generate the specific Autosar extract for each ECU. Based upon this description, another tool such as DaVinci Configurator can be used to create a consistent and optimised configuration of the Autosar basic software, the code of the Autosar RTE and optional templates for implementing the software components. Finally, implementation of the application software is performed in the user s usual development environment or by integrating code that comes from other sources. At the end of the development process, a complete implementation of the ECU software results, including configured Autosar basic software and RTE. The software is strictly based on the initially defined risks and safety goals and exhibits traceability. SuMMary Implementation of ECU software according to ISO using an integrated tool environment, that supports specific methods such as hazard and risk analysis and FMEA on the one hand, and contains all system and software describing data on the other hand, is clearly superior to a not integrated tool environment. Consequently, integrated tool environments are expected to take hold significantly more in the automotive industry over the next five years, than is the case today. References [1] ISO 26262, Road vehicles Functional safety, Parts 1 9, 2011 und Part 10, 2012 [2] Lederer, D.; Ebert, C.: Funktionale Sicherheit Das Gesamtsystem Fahrzeug. In: Hanser automotive 10 (2008), pp [3] Heling, G.; Rein, J.; Markl, P.: Koexistenz von sicherer und nicht-sicherer Software auf einem Steuergerät. In ATZelektronik 7, S7 (2012), pp