What is technical safety requirements ISO 26262?
ISO 26262 is a motor vehicle functional safety standard (functional requirements) that went into effect at the end of 2011 and aims to improve overall motor vehicle functional safety (automotive safety lifecycle phases). According to the concept outlined there, “Functional Safety Managers” (FSM) are responsible for ensuring that functional electrical systems and/or electrical safety-related items, such as airbags, driver assistance systems, and lane departure warning systems, comply with ISO 26262 requirements specification on behalf of their company as well as personally. The automotive industry (auto industry) considers this standard to be the state of the art in terms of technology and engineering, and it is widely applicable within the auto industry.
Table of content:
- Introduction to ISO 26262
- IP and semiconductor collaboration
- Rigidity versus flexibility
- Semiconductor / Tier 1 collaboration
- How can product safety aspects in IATF 16949 be met by following ISO 26262
- ISO 26262 safety lifecycle
- Risk assessment process of ISO 26262
- ISO 26262-LDRA
- How is ASIL evolving
- Safe failure fraction (SFF)
- What is the single point fault metric?
- Software tools
- Getting the picture
Introduction to ISO 26262
The standard “Functional Safety – Road Vehicles” uses a process-oriented technique to systematize a company’s responsibilities in the concept phase, development, and production of automotive electronic control units (ECU’s), while also taking into account statutory safety regulations (which are not specified in the standard). As a technological standard, it also establishes legal constraints for producers’ conduct, and thus represents a typical situation of law and technology colliding. To put it another way, in technical terms: Technical standards and legal requirements combine to provide a hybrid source for evaluating existing safety-related systems both technically and legally. Standards and legal requirements may only be understood in this context if they are seen from an interdisciplinary perspective.
As a result, ISO 26262 is usually used as a supplement to contract law and product liability law when construing and evaluating technical products; legislation simply states that a product must be safe, but it does not and cannot specify how functional safety aspects are to be ensured in detail. Despite the fact that the standards originated in private-law organizations, they are legally required to be followed because of their importance and extensive use in practice.
IP and semiconductor collaboration
Safety-critical automotive industry goods (automotive functional safety goods) created over an extended supply chain demands coordination between participants. This collaboration has grown increasingly more vital as system levels have become more sophisticated, pushing towards “supercomputers on wheels” and a “internet of cars.” People are being affected by change from two directions: First, as they shift from single-function MCUs to massive SoCs, established automotive microcontroller unit (MCU) producers are responding to virtually unimaginable increases in semiconductor complexity. Second, eager newcomers are only beginning to learn about vehicle safety functionality concepts.
These adjustments provide some unique learning opportunities. Assumptions of use (AoUs) are one stumbling block for designers . Natural language constraints will always have some element of ambiguity, no matter how well expressed they are. AoUs are a means to tighten up the specification by including supplier expectations and requirements for using a particular IP or system. One important element to remember is that a functional safety engineer must thoroughly review the AoUs before construction. A functional safety engineer may read an AoU and believe it will be covered, only to check again when the design is nearly complete and discover a critical interpretation has been missed. Members of the functional safety team are occasionally brought into a SoC design after the register-transfer level (RTL) has been frozen or the chip has tapped out.
The customer (or “integrator” in ISO 26262-speak) may then invite the functional safety provider to discuss potential solutions. Naturally, the supplier will assist in the resolution of this issue because it appreciates solid partnerships. Reconfiguring the network-on-chip, other IP, or software (software development), reviewing certain trial configurations, re-analyzing diagnostic coverage, and/or recommending the dreaded post-tape out engineering change order (ECO) are some of the suggestions that may be made. Whatever the safety case may be, the supplier and integrator are required to work together to resolve the issue.
Still, these are last-ditch attempts to overcome a difficult problem, and this is no way to manage a company. There is usually a solution to meet the necessary system-wide automotive safety integrity level (ASIL). However, this is not always the case. Using late-in-the-schedule measures is not only dangerous but also inefficient compared to finding difficulties earlier in the entire development process. Now, if the integrator makes a mistake, that company is unquestionably liable for resolving the issue. And it’s a positive thing if the integrator makes a mistake and the supplier assists in resolving the issue. Functional safety process improvement is essential, as it is with all quality and functional safety requirements, and repeated instances of failing to meet AoUs are indicative of systematic failures in a company’s product development process (automotive product development phase).
Bottom line: Read The Fine (Safety) Manual (RTFM) at the start of the design process and ask questions.
At the start of a chip project, the integrator should have well-documented safety goals and functional criteria. This is so that IP and software providers can assess (functional safety assessment) their work products’ appropriateness for the intended applications and provide extra information that may affect these goals. When goals are clearly established, there is a shared context, and everyone understands what is going on. A partner cannot be expected to have unlimited patience on this journey of discovery if the client does not know the desired outcome or is hesitant to share information with its providers.
Rigidity Versus Flexibility
Returning to the subject of regulation vs. guideline, what is more important: attaining a functional safety measure (level of safety goal) or arranging a table exactly as someone learned in a training course? Engineers may take more than they meant from training, such as expecting all failure types, effects, and diagnostic analysis tables to have the same columns in the same order as those learned in class. Instead, safety engineers should transmit the details of safety coverage by following the intent. Each organization has its own reasons for changing the format from time to time. If the tables provide all of the information needed, that should suffice. [As a side note, the IEEE P2851 Working Group and the Accellera Functional Safety Working Group are collaborating to develop standards for the interchange and interoperability of safety analysis and verification data. Please join us in these working groups if you are interested in addressing these challenges]
Semiconductor / Tier 1 Collaboration
Often, the integrator will need to work with a Tier 1 or original equipment manufacturer farther up the value chain. A functional safety issue in the larger system can sometimes be traced back to chip design. Perhaps the supplier discovered another flaw, such as a missing safety mitigation, and the RTL code has already been frozen. What other alternatives do you have? If the loss of coverage is minor, there may be a debate between the chip manufacturer and the Tier 1 provider. Whose fault was it anyhow, and is it really that significant in the grand scheme of things? Should we include a late repair to correct a minor gap in diagnostic coverage, even though the system will still meet its ASIL? Alternatively, by creating systematic flaws, will late fixes really reduce system-level safety?
Corrective action is, of course, necessary if the impact is critical. This could be a little software repair (though software engineers never conceive of them as “minor”), an engineering change order (ECO) to the hardware that necessitates work on the netlist. Throughout the design phase, open communication and collaboration between IP and software providers and chip integrators is crucial for lowering the frequency and severity of difficulties.
How can product safety aspects in IATF 16949 be met by following ISO 26262
Product Safety is essentially a subset of Functional Safety. When used across your design, development, and production processes for ALL safety requirements, a comprehensive Functional Safety Process will aid your business in satisfying Product Safety criteria. For characteristics that are either not statistically capable or unstable, the organization must implement a reaction plan that is stated on the control plan and evaluated for its impact on compliance with specifications.” Because both product and functional safety features should be defined as Safety Critical Special Characteristics, all Safety items should be included in the Reaction Plans.
ISO 26262 Safety Lifecycle
ISO 26262 defines requirements for overall organizational safety management as well as guidelines for a safety life cycle for the development and manufacturing of individual automotive products/automotive equipment (automotive safety lifecycle). The following functional safety management concepts are used in the ISO 26262 safety life cycle outlined in the next section:
A Safety Life Cycle: A Hazardous Event detect and assess hazard safety hazards (hazard analysis), develop specific safety requirements to decrease those risks to acceptable levels, and monitor and track those requirements to produce reasonable assurance that they are met in the delivered product. That is, each hazardous event is evaluated through a hazard analysis in terms of the severity of potential injuries, taking into account the amount of time a vehicle is exposed to the possibility of an automotive hazard occurring, as well as the likelihood that a typical driver will be able to act to prevent the injury.
Hazard analysis and safety risk assessment are performed at the start of the safety life cycle, culminating in an assessment of ASIL for all identified hazardous occurrences and safety goals. Each hazardous occurrence is assigned a classification based on the severity (S) of injuries it is likely to cause: Classifications of Severity (S):
- S0: No Injuries
- S1: Light to moderate injuries
- S2: Severe to life-threatening (survival probable) injuries
- S3: Life-threatening/fatal injuries (survival uncertain)
Risk management understands that the severity of a potential harm is influenced by the likelihood of the injury occurring; that is, a hazardous event is deemed a lower risk for a given hazard analysis if it is less likely to occur.
Risk Assessment Process of ISO 26262
The probability of an injurious hazard is further classified within the hazard analysis and risk assessment process of this standard as per a combination of Automotive Safety Integrity Level D hazardous event (abbreviated ASIL D) is an event with a reasonable possibility of causing a life-threatening/fatal injury.
ISO 26262-LDRA
By automating the needed validation (requirements for validation) and verification tasks and providing traceability throughout the life cycle, the LDRA tool aids on the path to compliance. A key component of the LDRA tool suite contributes to the verification of the design process by reference to the control and data flow analysis of the code derived from it. LDRA tool suite’s capability to perform Data coupling analysis and Control coupling analysis is a great aid for verifying these design principles when the code is available.
The LDRA tool suite includes measures such as complexity metrics derived from interface analysis, cohesion measurements derived from data object analysis, and coupling metrics derived from data and control coupling analysis to verify standard compliance.
Manual review is inefficient, error-prone, repeatable, and demonstrable. Automating the relevant checks with the LDRA tool set is significantly more efficient, error-prone, repeatable, and demonstrable. Functional, call, statement, branch, and MC/DC coverage are among the metrics suggested by ISO 26262 and given by the LDRA tool suite.
The development tool then generates code (the code must have met the coding standards), which is instrumented by the LDRA tool suite and then executed in either Software in the Loop (SIL or host) or Processor In the Loop (PIL or target) mode.
How is ASIL evolving?
With the rise of self-driving cars, ISO 26262 will have to rethink its concept of “controllability,” which presently applies only to human drivers. The absence of a human driver, as stated in the standard, means that Controllability will always be C3, the extreme of “uncontrollable.” Severity (injury) and Exposure (probability) are two more variables that will almost certainly need to be revisited.
The ISO 26262 standard aims to ensure the functional safety of a motor vehicle system with electrical/electronic component(s). ASIL classifications are used within ISO 26262 to express the level of risk reduction required to prevent a specific hazard, with ASIL D representing the highest hazard level and ASIL A the lowest.
Key benefits are:
- Establishing safety requirements to reduce risks to acceptable levels
- Ensuring that standardized safety protocols have been followed in the final product.
- Managing and tracking safety requirements
Note: Engineers measure three key characteristics for each electronic component in a vehicle:
| Intensity | the type of injuries to the driver and passengers |
| Amount of exposure | how often the vehicle is exposed to the hazard |
| Possibility of control | how much the driver can do to prevent the injury |
There are sub-classes for each of these variables.
Safe Failure Fraction (SFF)
The term “safe failure fraction” refers to the percentage of failures that are either “not hazardous” or “harmful but revealed by some auto-test.” To put it another way, it’s one minus the proportion of ‘unrecognized dangerous failures.’ According to the degree of redundancy used, the IEC 61508 standard establishes levels of safe failure fraction required to claim conformity to a certain SIL target. There are two tables of rules that determine whether a piece of equipment or key component is simple (with well-defined failure modes, known as Type A) or complicated (with well-defined failure modes, known as Type B) (such as a programmable instrument, known as Type B). The term “safe failure fraction” appears frequently in SIL certificates.
What is the single point fault metric?
The single point fault metric (SPFM) is a hardware architectural measurement that determines whether or not the safety mechanisms’ coverage is sufficient to prevent risk from single point errors in the hardware design.
Software Tools
The TCL and ASIL are used to determine the software tool’s level of certification. To measure the level of confidence, two specific areas are assessed: Any safety requirement assigned to the safety-related item or element to be developed could be violated by a malfunctioning software tool and its erroneous output. The likelihood of identifying or preventing such faults in its output TCL1, TCL2, TCL3, or TCL4 is the tool of degree of confidence, with TCL4 being the highest degree of confidence and TCL1 being the lowest degree of confidence.
The following tool qualification work products are required by ISO 26262:
- Software Tool Documentation
- Software Tool Qualification Plan
- Analysis of Software Tool Classification
- Report on Software Tool
- Qualification Plan on Software Tool
- Qualification Early in the development life cycle of a safety-related item
- The Software Tool Qualification Plan (STQP) is prepared.
Getting the picture
It’s critical to remember that the ISO 26262 standard is just that: a framework. By having a clear understanding, expectations, and rules, practical partners are willing to adjust to each other in order to meet the spirit of the framework. There will always be some uncertainty, interpretation, discussion, and eventually shared understanding in value chain interfaces between organizations that produce distinct types of deliverables (IP vs. software vs. chips vs. systems). Good preparation, clear communication, and a culture of working together to reach a common goal are what make ISO 26262 work.
Additional Information on ISO 26262
- The International Electrotechnical Commission (IEC) has published an international standard called IEC 61508 that describes how to implement, design, deploy, and manage automatic protection systems known as functional safety-related systems.
- Validation/confirmation measures determine if intermediate or final items meet the standards of the next level in the supply chain.
- “The organizations participating in the execution of the safety lifecycle shall have an operational quality management system complying with a quality management standard, such as standard ISO/TS 16949″, ISO 9000:2008, or equivalent,” according to ISO 26262.
- The standard describes five ASIL levels, with QM-ASIL being the lowest level, ASIL A, ASIL B, ASIL C, and ASIL D being the highest safety-related level. Fulfilling compliance requirements can be a tedious process.
- A classic definition of an original equipment manufacturer (OEM) is a corporation whose products are utilized as components in the automotive product development phase of another company, which then sells the final thing to end consumers.
- Malfunctions caused by incompatible software/electronic systems that the system can’t process or by hack attacks are becoming increasingly common.
- Given the impossibility of achieving absolute safety, safety arguments might be used to demonstrate that the system is free of unreasonable risk.
- Hazard analysis and safety risk assessments reveal potential dangers that must be mitigated.
- In order to ensure functional safety in a particular system, because a vehicle’s safety is dependent on the control systems’ reflexes.
- The goal of functional safety development is to detect potentially dangerous situations.
- Whether you’re building traditional automotive components (such as integrated circuits) or virtual ones, adhering to the safety requirement is critical (e.g., automotive hypervisors).
- A safety integrity level (SIL) is a relative level of risk reduction given by a safety function, or a target level of risk reduction specified by a safety function.
- ISO 26262, developed from IEC 61508, is a risk-based safety standard.
- Unit testing concentrates on individual software procedures or functions, whereas integration testing verifies that safety and functional criteria are met when units work together.
- Although ISO 26262 and ISO/TS 16949 have some overlap, they are largely complementary because ISO/TS 16949 pertains to corporate processes and ISO 26262 is focused on products.
- The goal of functional safety development is to detect potentially dangerous situations. The harmful conditions are rated based on their severity, and safety procedures are used to minimize or limit the impact of an occurrence, ensuring that the response is commensurate to the risk.
- A loss offunctional safety occurs when a malfunction occurs that has a potentially dangerous effect.
- International automotive manufacturers require a component supplier industry to apply the ISO 26262 within their product development (development of safety).
- ISO 26262 is a functional safety standard for automotive equipment applicable throughout the safety life cycle of all electronic and electrical safety systems in automobiles.
