Safety-relevant AUTOSAR Modules Theory and Practice

Transcription

1 Insert picture and click Align Title Graphic. Safety-relevant AUTOSAR Modules Theory and Practice Dr. Simon Burton Vector Consulting Services GmbH AUTOSAR Symposium, 04. November Vector Consulting Services GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V

2 Functional safety and safety-relevant software ESP Electr. Parking Brake Adaptive Cruise Control Airbag Functional Safety: Absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems. Software is considered safety-relevant if: It directly implements safety-relevant functions of the system or failures in the software can negatively influence safetyrelevant functions. Slide: 2

3 Functional safety standards ISO/DIS 26262: Road vehicles Functional safety: Can be considered industry best practice from a product liability point of view. Risk-based approach: Safety goals with related ASILs are derived based on a hazard and risk analysis. The safety goals must be considered in all phases of product development. The strength of argument required to demonstrate that a safety goal has been met is determined by its ASIL. ASIL D ASIL C ASIL B ASIL A QM Strength of argument /cost ASIL: Automotive Safety Integrity Level Slide: 3

4 Eample: AUTOSAR CAN Stack The communication software may need to be integrated into systems with safety goals up to ASIL D. Slide: 4

5 Standard software modules for safety relevant applications What makes standard software different? 1. The safety goals and ASILs of the target system are unknown at the time of development. 2. It is uneconomic to develop all standard software modules to the highest possible ASIL. 3. Standard software is developed once and used many times but can be highly configured for each use. How can standard software modules be safely reused within the contet of safety relevant applications? Slide: 5

6 ISO on safety elements out of contet 1. The safety goals and ASILs of the target system are unknown at the time of development. Standard component Assumptions on safety goals (ASIL capability) confirm Target system Definition of safety goals (ASIL capability) Assumptions on safety requirements confirm Definition of safety requirements Design, implementation and verification Design, integration and verification The assumed safety goals and requirements must be eplicitly documented and delivered with the standard component. Slide: 6

7 Assumed safety goals and requirements Assumed safety goal: The integrity of the communication between applications shall be ensured at all times. Assumed safety requirement: The following fault modes shall be detected in the communication : Repetition, Deletion, Assumed safety requirement: Upon detecting an error in the communication, a status message shall be sent to the application Assumed safety requirements for communication software: Based on standard fault models and the technical safety requirements under development by AUTOSAR. Must be made available to the system integrator during the conceptual design phase. Slide: 7

8 ISO on ASIL decomposition 2. It is uneconomic to develop all standard software modules to the highest possible ASIL. Safety goals can be partitioned into requirements on safetyrelated functions and requirements on safety mechanisms. The combined requirements must ensure the same level of safety as implied by the original safety goal. Partitioned requirements must be allocated to elements that are sufficiently independent. Safety goal ASIL D Decompositions for ASIL D: ASIL C + ASIL A, ASIL B + ASIL B, ASIL D + QM Safety Mechanism ASIL D (D) Safety-related function QM (D) Slide: 8

9 Application of ASIL decomposition Application Application Communication stack ASIL D ASIL D + QM Safety Layer Safety mechanisms Communication Stack (QM) Reused standard SW The safety layer detects and handles possible faults in the communication stack based on the set of assumed safety requirements. The safety layer can be economically developed according to a higher ASIL due to the restricted functionality. The safety layer is developed separately and is an independent component in the system. Slide: 9

10 The safety layer The safety layer ensures the integrity of the communication between applications Fault modes Repetition Deletion Insertion Re-sequence Corruption Delay Masquerade Safety mechanisms to be implemented by the safety layer Sequence number Time stamp Timeout Source and destination identifier Feedback message Cryptographic techniques Identification procedure Safety code (CRC) The safety layer is used to detect systematic failures in the communication stack as well as systematic and random failures in the hardware. Slide: 10

11 ISO on mied ASIL systems 2. It is uneconomic to develop all standard software modules to the highest possible ASIL. Different components can be assigned different ASILs within a single system if the freedom of interference between them can be shown. Eample measures for ensuring freedom of interference in software CPU-Time Time-triggered scheduling, Fied-priority-based scheduling, Monitoring of eecution time, Memory Memory protection, Eecution of tasks in user mode, ERC, CRC, redundant storage, Slide: 11

12 Ensuring freedom of interference Application Safety Layer Communication Stack (QM) Memory Protection Run-time Protection The standard SW must be integrated in a way such that freedom from interference with other SW modules is ensured. Additional safety mechanisms are required to prevent interference regarding shared CPU or memory resources. Must be implemented to the highest ASIL of the system. Either already available as part of the O/S, HW and Basic SW. or must be added to the system in the form of additional components. Slide: 12

13 ISO on configurable software 3. Standard software is developed once and used many times but can be highly configured for each use. Specified Configurable Software Verified Configuration Data Verified Configured Software Verified on the Target System Configuration data must be developed to the same level of rigor (ASIL) as the software. The configured software must be verified in the target environment. Slide: 13

14 Configuration of a communication stack Application Safety Layer Communication Stack (QM) Appro. 5 configurable parameters Appro configurable parameters The configuration data for the communication stack can be specified and verified as usual due to the restricted influence of failures through ASIL decomposition (QM). Errors in the configuration of the safety layer could have an impact on safety. These parameters therefore need to be specified in detail including valid values, ranges and interdependencies and the target values rigorously verified during configuration of the target system. Slide: 14

15 Impact on release documentation Standard release scope Safety-specific integration guidelines.c.c.c Source code Doc Assumed safety goals and requirements Doc Documentation + Doc Evidence of correct implementation Doc Detailed specification of configuration data Doc Pre-requisites for ensuring freedom of interference It is the responsibility of the system integrator to ensure that the integration guidelines are adhered to in the target system. Slide: 15

16 Summary The ISO allows for an economic approach to developing standard software for use in safety-relevant systems. A systematic yet pragmatic approach must be taken and assumptions made during the development eplicitly documented. An early agreement with the system integrator is required in order to ensure that the pre-requisites for safely integrating the standard software are met. The AUTOSAR safety concepts will be applied to facilitate this agreement and ensure that standardized solutions for integrating AUTOSAR software components can be developed. Slide: 16

17 Thank you for your attention. For additional information about Vector Consulting Services please have a look at: Vector Consulting Services GmbH Ingersheimer Str. 24 D Stuttgart Phone: Fa: consulting-info@vector.com Your Partner in Achieving Engineering Ecellence. Slide: 17