This self-paced video training provides a faster and more flexible way to learn the ISO 26262 compliant processes and standards for Model-Based Design. The course is intended for advanced Simulink users, function developers and safety managers who already work with Simulink and want to develop automotive applications based on ISO 26262 safety standard. Please consider our MATLAB and Simulink trainings to refresh your modelling skills. Basic knowledge of C programming language and ISO 26262 standard are recommended. In this training the practical workflows of ISO 26262 are mapped to the qualified Simulink toolchain. Model-Based Design and essential requirements of ISO 26262 are presented in a didactically structured way. The trainee gains the related expertise naturally while viewing the instructions.
Hazard Analysis is not possible without an adequate understanding of the Item. Item Definition describes at the vehicle level how the functionality is intended. Item Definition details the interactions with the driver, the environment around the vehicle and other relevant Items at the vehicle level. Item Definition contains existing product presentations, drawings and other relevant information in the form similar to the patent applications. Item Definition is the prerequisite for analysis of malfunctions including failure modes and hazards.
During Hazard Analysis we systematically identify the hazardous events at the vehicle level. We describe all operational situations and operating modes of the vehicle relevant for the item. We describe all possible malfunctions of the item assuming no internal safety mechanisms. Now we systematically combine our findings about the behavior of the vehicle to see how functional failures of the item can compromise the safety. As a result, we create a list of hazards and related malfunctions.
The Risk is defined in ISO 26262 as a combination of the probability of occurrence of harm (Exposure) and the Severity of it. In some situations the risk can be controlled by the ability of the driver to avoid it. During Risk Assessment all identified hazards shall be classified with respect to Severity, probability of Exposure and Controllability. For each hazardous event an Automotive Safety Integrity Level (ASIL) is a function of such classification. A Safety Goal (top-level safety requirements as a result of the HARA at the vehicle level) shall be determined for each hazardous event with an ASIL higher than QM. The Confirmation Review of the Hazard Analysis and Risk Assessment (HARA) shall be performed with the highest independence level I3.
In the Functional Safety Concept we use the information about the item, the identified hazards and related malfunctions to specify the functional behavior of the item in accordance with its safety goals. Safety goals are the top-level safety requirements. We investigate how to detect and how to control the relevant faults in order to specify the measures to achieve the required safety integrity level. Then we derive and allocate the functional safety requirements to the system elements and specify the safety validation criteria for later verification.
The malfunctions of software tools used for development of critical systems introduce the risk of systematic faults in the developed product. The Tool Qualification in the user environment provides the confidence in the use of software tools. We first evaluate the Criteria like Tool Impact (TI) and Tool Error Detection (TD) to determine the Tool Confidence Level (TCL) which defines the rigor of how to qualify the tool. The tool Vendors can simplify the qualification process on the user side by providing the pre-qualification evidence in the form of Qualification Kits.
For detection and control of random hardware failures we use a standard way to compare the reliability. The symbol λ [lambda] is used to represent the unit for Failures In Time (FIT). The FIT rate is the approximated number of expected failures per one billion device-hours of normal operation. It remains low and constant during useful life period. The Bathtub Curve is a model which illustrates how a component FIT rate changes over its life cycle. In the early operation period, the FIT rate is high but decreasing as production defects will be discovered. In the end-of-life period the FIT rate is growing because of physical degradation of materials. The Bathtub Curve model helps predicting when failures are most likely to occur to improve the functional safety.
In an item without a Safety Mechanism the fault will cause a malfunctioning behavior resulting in a hazardous event. The time between the fault and the hazardous event is called the Fault Tolerant Time Interval (FTTI). It is obvious that the Safety Mechanism shall handle the fault faster than that. The Safety Mechanism is a technical solution to detect faults in order to maintain intended functionality. Fault Handling consists of Fault Detection and Fault Reaction. For reliable fault detection we will need several diagnostic cycles. The fault reaction includes an immediate transition to a safe state or a driver alert such that the driver is expected to control the emergency.
The Static Model Verification is very cost effective. No models have to be executed. No requirements have to be analyzed. No test cases have to be written. The potential modeling errors will be detected early in the process. In a safety related projects the IEC 61508 defines a generic software development standard from which all other industry specific standards were derived: Railway, Process Industry, Machines, Gas & Measure Technologies, Medical and Automotive. The model architecture and software units shall be developed and verified in compliance with required methods. Static model verification is one of the required methods for all safety integrity levels. Static model verification begins with the definition of model guidelines which is error-prone and very time-consuming. After model analysis multiple model modifications are needed. The model compliance shall then be systematically approved by using the checklists during manual reviews. Some rule deviations are acceptable or even necessary for project specific tasks. Such deviations need to be documented. The resulting verification reports shall include sufficient evidence of positive results for each single guideline and deviation. All the steps will be repeated after every model modification. So tool automation is a must for static model analysis.
Please note: this is a short transcript of the training video above.
Need for more Model-Based Design insight? Need for more Automotive Safety insight?