1、SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 1 (47) Contract number: ITEA2 10039 Contract number: Eurostars 6095 Safe-E Safe Automotive soFtware architEcture (SAFE) & Safe Automotive soFtware architEcture Extension (SAFE-E) WP3.2.1 System and softwar
2、e models enhancement Deliverable D3.2.1.b: Final proposal for extension of meta-model for software and system modeling Due date of deliverable: 28/02/2013 Actual submission date: 04/03/2013 Organization name of lead contractor for this deliverable: AVL Editor: Elvira Biendl Contributors: WT3.2.1 Par
3、ticipants Reviewer: Philippe Cuenot, Christoph Ainhauser; Markus Ortel, Hans-Leo Ross, Stefan Voget Safe-ESAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 2 (47) Revision chart and history log Version Date Reason 0.1 12.11.2012 1st Draft based on D3.2.1.
4、a 0.2 04.02.2013 Update hierarchical structure of the document. Specification of System- and Software-package added. Interfaces to other SAFE meta-model packages added. Preparation for 1st Review 0.3 05.02.2013 Integration of review comments from contributors 0.4 12.02.2013 Update of document struct
5、ure as preparation for internal review 0.5 18.02.2013 Update Chapter 5.1, 5.2 und 7 for final review with work task participants 1.0 25.02.2013 Update during final review 1.1 28.02.2013 Integration of review comments update of chapter 7 1.2 01.03.2013 Editorial changes SAFE an ITEA2 project / SAFE-E
6、 an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 3 (47) 1 Table of contents 1 Table of contents . 3 2 List of figures . 4 3 Executive Summary . 5 4 Introduction . 6 4.1 Abbreviation, Special Terms, Akronyms . 7 4.2 Scope of the document . 8 5 System Package Specification . 9 5.1 Arch
7、itectural Overview . 9 5.1.1 Hazard . 10 5.1.2 System . 11 5.1.3 Requirements . 13 5.2 Vehicle Level . 14 5.2.1 Item Definition . 14 5.3 Item Level . 15 5.3.1 Item Structure . 15 5.3.2 Safety Concept . 17 5.4 System Level . 22 5.4.1 System Design . 22 6 Implementation of the SAFE meta model . 24 6.1
8、 Description of the SAFE meta-model . 24 7 Further Topics and Outlook . 25 7.1.1 Further Topics addressed to Package Requirement . 25 7.1.2 Further Topics on Item Level . 28 7.1.3 Further Topics on System Level . 33 7.1.4 Further topics on software level . 40 7.1.5 Further topics on hardware level .
9、 43 7.1.6 Safety Validation . 44 7.1.7 Process Activities. 44 8 SAFE References . 46 9 Acknowledgments . 47 SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 4 (47) 2 List of figures Figure 1: SAFE meta-model . 5 Figure 2: Scope of this Document . 8 Figur
10、e 3: Architectural Overview . 9 Figure 4: Interfaces to Hazard packages . 10 Figure 5: Item Architecture overview . 11 Figure 6: Interfaces to Requirements packages. 13 Figure 7: Item Definition . 14 Figure 8: Item Structure . 15 Figure 9: Item Architecture . 16 Figure 10: Safety Concept . 17 Figure
11、 11: Functional Safety Concept . 18 Figure 12: Safety Measures . 19 Figure 13: Safety Mechanism Structure . 21 Figure 14: System Design . 22 Figure 15: System-Array . 23 Figure 16: SAFE meta-model . 24 Figure 17: Outlook - Safety Requirements . 27 Figure 18: Outlook - Item Environment . 28 Figure 19
12、: Outlook - Safety Element out of Context (SEooC) . 29 Figure 20 : Outlook Warning- and Degradation Concept . 30 Figure 21: Outlook - Safety Measures . 31 Figure 22: Outlook - Architectural Elements . 32 Figure 23: Outlook - Decomposition . 34 Figure 24: Outlook - Decomposition Function + Safety Mec
13、hanism . 35 Figure 25: Outlook - Hardware Software Interface Specification . 36 Figure 26: Outlook - Failure Propagation on system level . 37 Figure 27: Outlook - Safety relevant failures . 38 Figure 28: Outlook - Safety Analyses . 39 Figure 29: Outlook - Interface to Software Package . 40 Figure 30
14、: Outlook - SW-System Architecture . 41 Figure 31: Validation of external measures . 44 SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 5 (47) 3 Executive Summary The automotive industry uses more and more electronically controlled equipment in passenge
15、r cars that covers safety critical functionality. This leads to an increase of systematic failures and random hardware failures. Many of those failures are able to cause harm to people. These safety relevant failures shall be reduced to a level of unreasonable risk. ISO 26262 contains a guidance to
16、avoid or mitigate the risks caused by safety relevant failures by providing appropriate requirements and processes. Currently the automotive industry is applying the requirements and processes specified in the ISO 26262 to provide new systems that are able to avoid the increasing risks or at least m
17、itigate them to an appropriate level. The objective of this project is to analyze existing models like EAST ADL, SysML or AUTOSAR with the requirements given in the ISO 26262. The result of this analysis shall provide input for creation of a model that can be used to describe safety relevant systems
18、 in accordance with the requirements given in the ISO 26262. The solution that is described in this document is a draft version and shall be used as a starting point for discussion with other users of EAST ADL, AUTOSAR and ISO 26262 to find an effective solution that is easy to use in future develop
19、ment projects. Figure 1: SAFE meta-model SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 6 (47) 4 Introduction Up to now the automotive industry is already doing systematic failure analysis. But now the ISO 26262 defines the need to avoid unreasonable r
20、isk. Therefore this kind of analysis is getting more important for future automotive development projects. The increasing use of electronically controlled equipment in the car leads to a changed behavior of the driver. Actions of the driver are guided by electronically controlled features, e.g. adap
21、tive cruise control, electronic stability control, etc. All these features are able to help the driver to handle critical traffic situations. In a time of increasing number of cars on the road and increasing diversion for the driver during driving on the road, the driver trusts more and more in the
22、new features of the car. All these topics lead to a changing of the common level of unreasonable risk. Based on the fact that unreasonable risk depends on a certain context according to valid societal moral concepts the automotive industry recognizes the challenge to handle the environmental context
23、 during development. The actual level of unreasonable risk in the target market of the vehicle in development is a new topic that shall be established in the already existing development process landscape. SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium
24、 7 (47) 4.1 Abbreviation, Special Terms, Akronyms The following table describes the special terms used in this document. Abbreviation/ Accronym Description ASIL Automotive Safety Integrity Level AUTOSAR Automotive Open System Architecture Component A component is an element of system that contains a
25、 single functionality (e.g. steering, break, powertrain, chassis .). The component can consist of hardware elements, software elements, systems, sensors, actuators . Therefore the component contains all elements to fulfill the specified function. Controllability Controllability is the ability to avo
26、id a specified harm by any action of the driver or other persons involved during the hazardous event that is currently under analysis. EAST-ADL Electronics Architecture and Software Technology - Architecture Description Language Element Element is a term that is used on each architectural level in a
27、 different way. At system level (e.g. system = vehicle) a system element is one part of the vehicle (e.g. wheel, window, mirror .) At component level (e.g. component = powertrain) the element is one part of the powertrain (e.g. transmission. At part level (e.g. part = C) the element is one part of t
28、he C (e.g. a pin) Exposure Exposure is the state of being in a hazardous event that meets with the failure mode that currently is under analysis without regarding any already planned safety measures. FAA Function Analysis Architecture FDA Function Design Architecture Hazard A hazard is a potential s
29、ource of physical injury or damage to the health of persons caused by malfunctioning behavior of the item Hazardous Event A hazardous event is a combination of a hazard and an operational situation. Operational situation An operational situation is a scenario that can occur during a vehicles life. p
30、reliminary Preliminary is used to classify the maturity of an element. It means that the element is not finally verified or validated. RTE Real Time Environment SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 8 (47) safety relevant failure Safety releva
31、nt failures are failures that are identified during safety analyses to have the potential to lead to a violation of a safety goal Severity Severity is the estimation of the extent of harm to one or more individuals that can occur during the hazardous event that currently is under analysis. 4.2 Scope
32、 of the document Figure 2: Scope of this Document This document is created based on the requirements allocated to work task WT3.2.1. The allocation of the requirements is documented in the referenced deliverables D2.1.b 5. Based on these requirements the specification of SAFE meta-model package syst
33、em was created. It describes how to model a safety relevant item according to ISO 26262 by using already existing models like EAST-ADL and AUTOSAR. This specification shall be used as a base for discussions with the EAST-ADL and AUTOSAR consortium how to handle the described topics in future. SAFE a
34、n ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 9 (47) 5 System Package Specification This chapter contains the specification of elements that are needed to fulfill the requirements allocated to WT3.2.1. The system package contains description of the differen
35、t architectural level of an item Safety measures and safety mechanisms to avoid, mitigate, detect or control safety relevant failures Safety Architecture as a base for safety related analyses. The SAFE meta-model shall provide a solution that contains all relevant information about the safety releva
36、nt item in a consistent way. This can be reached by maintaining traceability between the safety goal analyzed in the Hazard Analysis and Risk Assessment and the technical solution described in the safety requirement documentation. 5.1 Architectural Overview The following chapters describe the archit
37、ecture of the SAFE meta-model packages that have interfaces to the system package. Figure 3: Architectural Overview SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 10 (47) 5.1.1 Hazard Figure 4: Interfaces to Hazard packages The safety goals are derived
38、 from hazardous events analyzed in the Hazard Analysis and Risk Assessment. Hazardous event is a combination of a hazard with an operational situation. The hazard analysis and risk assessment shall be executed based on the item definition. Further details according to Hazard Analysis and Risk Assess
39、ment are described in D3.1.1.b 6. The safety goals shall be described as functional safety requirements (see 5.1.3) and allocated to architectural elements (see 5.3.1.1) of the item. Safety Analyses shall be executed to identify safety relevant failures. A technical solution shall be defined to dete
40、ct or control random hardware failures that have the potential to lead to a violation of the allocated safety goal and/or avoid or mitigate systematic failures that have the potential to lead to a violation of the allocated safety goal. SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 20
41、11 The SAFE & Safe-E Consortium 11 (47) 5.1.2 System Figure 5: Item Architecture overview This package contains all needed artifacts to model a safety-related system in accordance to the requirements of the ISO 26262. The ISO 26262 is defined for safety-related systems that include E/E-systems that
42、are installed in a series production passenger car with a maximum gross vehicle mass up to 3500 kg. Therefore the item is defined as a sub-system of a vehicle. Safety Analyses shall be done on different levels of the item architecture. Therefore the SAFE meta-model provides different architectural l
43、evels. SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 12 (47) Vehicle Level: The vehicle level is defined as the top level of the architecture. It describes the context of the item as well as the architectural splitting up to different items. Item Leve
44、l: The item level describes the functionality of the item as well as the architectural splitting up to different systems. System Level: The system level describes the architectural elements of the system. A system contains at least one sensor, one controller and one actuator. The architectural split
45、ting up of each sensor, controller, actuator to components is also part of this level. Another part of this level is the allocation of the different elements to software and hardware components. The architectural description of the interfaces between the Components is also part of this level. Softwa
46、re Level: The software level contains the architectural splitting up of each software component to software Units. The architectural description of the interfaces between the Software Units is also part of this level. Hardware Level: The hardware level contains the architectural splitting up of each
47、 hardware component to Hardware Parts. The architectural description of the interfaces between the Hardware Parts is also part of this level. SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 13 (47) 5.1.3 Requirements Figure 6: Interfaces to Requirements
48、 packages Safety Requirements shall be categorized into different groups: Functional Safety Requirement Technical Safety Requirement Constraint Constraints describe for example architectural assumptions or design constrains given from the higher level architecture. Further details to constraints see
49、 chapter 7.1.1.1. Detailed description of safety requirements see D3.1.2.b 7 SAFE an ITEA2 project / SAFE-E an Eurostars project D3.2.1.b 2011 The SAFE & Safe-E Consortium 14 (47) 5.2 Vehicle Level 5.2.1 Item Definition An Item is a system or array of systems to implement a function at the vehicle l
50、evel that is able to cause harm to people inside or outside the vehicle. It shall be possible to describe interfaces, interactions and dependencies to other items. The ISO 26262 is focused on E/E-technologies, therefore the technology used to realize an item shall be categorized into E/E technologie
