| Origin of Functional Safety | Disasters had led to requests by authorities to increase industrial safety. |
| 4x Safety Aspects | - functional safety
- safety of use
- cyber security
- safety of the intended functionality (SOTIF) |
| Product Liability | A product must provide the level of safety (acceptable risk). The manufacturer has to show that he is not responsible for a fault. It is guilty until proven otherwise.
Manufacturer's liability is excluded if
• A failure can not be avoided/detected
• Using current state-of-the-art technology and development processes when
launching the product |
| ASIL & QM | Safety Integrity Levels (SILs) = Quantify the magnitude of risk reduction
- QM, SIL 1 … SIL 4 (highest)
- SIL levels define additional measures to mitigate risks |
| Safety Plan | planning of the activities and procedures for achieving functional safety
- tailored safety activities
- planning of the safety activities
- supporting processes
- integration and verification activities
- scheduling of the confirmation reviews
- confidence in the usage of software tools |
| Safety Case | - Complete documentation, actual work products from all lifecycle phases e.g. item definitions
- Compilation of all information to prove Functional Safety Achievement |
| Safety Management | - organization must have safety culture
- management of safety anomalies regarding functional safety : detect, tackle and communicate safety anomalies
- competence management : organization ensures that personals involved in safety lifecycle is capable of doing do
- quality management system : organization has quality management system that support achieving functional safety |
| DIA | - define interactions and dependencies between customers and suppliers for development activities
- allocation of responsibilities
- work products to be exchanged |
| Audit & Assessment | - Assessment confirms that a product achieves Functional Safety according to ISO 26262
- Required Documentation: Work Products as required by the Safety Plan, Functional Safety Audit Result, Review of the implemented safety measures
- Done parallel to the development and has to be completed before „Release for Production"
- Assessor can be third party (not mandatory but safer) |
| HARA | Harzard Analysis and Risk Assessment
- identify and classify the hazardous events (and risk) caused by malfunctioning behavior of the item
- formulate the safety goals with their corresponding ASILs |
| HARA team | – different experts - prepare HARA
– HARA moderator - invite discussion
– Functional Safety Manager (optional)
HARA reviewed by independent party |
| HARA procedure | - Item definition (define functions)
- Derive item malfunctions
- Define relavant situations (worst case of vehicle state, environment, driving scenerio)
- Combine malfunctions with relevant situations = hazardous situation
- Evaluation of risks for every hazardous situation (Exposure, Severity & Controllability)
- Derive ASIL
- Define safety goals with ASIL and safe state |
| Item Definition | - Describe work content for safety life cycle (HARA)
- Name + Description (purpose, what does it do bla bla) + Attributes (electrical, interfaces etc.) |
| Focus of Functional Safety | concentration on the functional safety aspects during the design, development, and validation stages, as well as ongoing monitoring and maintenance |
| HARA Evaluation Criteria | - Severity (S0-S3), no injuries -> fetal injuries : estimate extent of harm to indivisual(s) that can occur in potential harzardous event
- Exposure (E0-E4), incredible -> high probability : operational state that can be hazardous, time and frequency
- Controllability (C0-C3), controllable -> uncontrollable : ability to avoid harm or damage through timely reaction |
| HARA outcome | ASIL and Safety Goal
- safe state
- fault tolerance time interval
- warning concept
- degradation concept and emergency operation |
| FTTI | Fault tolerance time interval (FTTI)
Time-span in which a fault can be present in a system before a hazardous event occurs |
| FHTI | Fault handling time interval = Fault detection time interval + Fault reaction time interval
Time from the fault is detected until transition to safe state |
| Functional Safety Concept | Specification of the functional safety requirements (implementation-independent safety behaviour, or implementation-independent safety measure, including its safety-related
attributes to achieve safety goals), with associated information, their allocation to architectural elements and their interaction necessary to achieve the safety goals |
| ASIL Decomposition | ASIL Levels can be reduced by “decomposition”:
a) Implementation of redundant safety requirements at the next level of detail, and that these are allocated to sufficiently independent design elements; and
b) to apply ASIL decomposition according to permitted ASIL decomposition schemas.
c) Cascading decomposition is allowed. |
| Technical Safety Concept | collect technical safety requirements and the corresponding system architectural design that provides rationale as to why the system architectural design is suitable to fulfil safety requirements resulting from activities described in ISO 26262-3 (with consideration of non-safety requirements) and design constraints
Procedure :
1) develop draft system architecture design that takes into account technical requirements
2) specufy technical safety requirements and functional safety concept from draft
3) refine draft to safeguard the architecture design
4) refine technical safety requirements
5) Verification of system architectural design, hardware-software interface (HSI) specification and the specification of requirements for production, operation, service and decommissioning and the technical safety concept |
| System Architectural Design | Requirements of the OEM, own guidelines, Environmental Requirements, functional constraints, Functional Safety Concept |
| System Design Verification | - Deductive analysis: Fault Tree Analysis (FTA)
- Inductive analysis: Failure Mode and Effects Analysis (FMEA) |
| System and Item Integration & Testing | The integration and testing phase comprises three sub-phases and three objectives
• sub-phase 1 : integration of the hardware and software of each element
• sub-phase 2 : integration of the elements that comprise a system to form a complete item
• sub-phase 3 : integration of the item with other systems within a vehicle
(table with ++ must do, + depend on agreement (magna don't), - no need) |
