Managing Road Vehicle Product Quality in Compliance with ISO 26262
Designed for series production cars, ISO 26262 provides a series of steps to manage functional safety and to regulate product development on a system, hardware and software level throughout the entire product lifecycle — from concept development through decommissioning.
Increasing complexity in the hardware, electronic and software systems used throughout automotive technologies has increased the complexity of achieving safety compliance for automotive manufacturers. New automotive standards like ISO 26262, released in November of 2011, aim to provide a common standard to measure how safe an automotive system will be in service.
PTC Windchill Quality Solutions offers a comprehensive line of reliability analysis and quality management tools designed to work together as a single software suite to reduce product and process risk, ensure system reliability, and improve quality and performance.
Analyzing System Safety
Following the concept development phase, during which ASIL (Automotive Safety Integrity Level) values and their related system and sub-system safety requirements are established, a process of System Safety Analysis takes place throughout product design and development. This process verifies that the system — as designed, developed, produced and maintained — is in fact meeting the ASIL levels established during earlier requirements development activities. This process typically leverages a set of reliability engineering methodologies, including the following:
- Reliability Prediction, which calculates the probability of failure for a system or sub-system based on the probability of failure of its component parts. It is used to inform part and system design changes early during product design — before physical prototypes are developed — to improve system reliability by reducing part, sub-system and system failure rates. This in turn improves product safety by reducing the risks attributed to part, sub-system and system failures.
- FMEA (Failure Mode and Effects Analysis), which provides an inductive, bottom-up risk analysis for each component part in a system or sub-system. It is used to pinpoint all possible failure modes associated with system components and to identify their causes and effects from a Design, System and Process standpoint. A FMEA also provides quantitative methods to evaluate the severity of possible failures and thereby validate whether or not earlier ASIL goals have been met. Finally, it is used to introduce risk-control measures where needed to mitigate or eliminate the effects of failures, evaluate the effectiveness of these risk controls and reevaluate system safety based on new risk-control measures, to ensure that ASIL goals have been met in system designs. To further enhance risk control, the FMEA outputs DVPs (Design Verification Plans) ― or Test Plans ― which assign testing procedures to ensure risk-control measures and system designs are effective and meet their safety and reliability goals as defined by the requirements and design phases. It also outputs Manufacturing Control Plans used to reduce risks that could be introduced during the production phase of product development.
- FTA (Fault Tree Analysis), which provides a deductive, top-down method for risk analysis that starts with a negative end-event and considers all possible contributing factors throughout the system, sub-system and parts levels ― while also considering external factors and human errors that can further contribute to the negative end-event. Like the FMEA process, a FTA also offers quantitative methodologies to calculate the likelihood of an event or series of events that can contribute to the negative end-result.
Using Reliability Engineering Techniques Together
These reliability engineering techniques can be used independently or together for a more robust analysis. For example, the failure rate of a system, sub-system or part — as calculated during reliability prediction — can be used to inform the likelihood of a risk under analysis in the FMEA or FTA when that risk is due to part failure. Similarly, a FMEA — with its comprehensive analysis of component parts and sub-systems that lead to certain negative end-events — can be used to construct a FTA to determine how those potential component failures may together contribute to other various negative end-results.
Less Read More
Additional Reliability Engineering Techniques and ISO 26262
These and other reliability engineering methodologies ― such as Reliability Block Diagrams
, which predict reliability and maintainability needs for more complex system configurations; Event Tree Analysis, which is an inductive technique related to FTA; Markov, which considers systems that exhibit complex transitions between operational states; and Maintainability Prediction
, which calculates maintenance needs and outputs service plans — all contribute to system design and development. These methodologies work in concert with other System Safety Analysis methods to verify and validate that the real-world system, as designed, has met its intended goals and target ASIL values for safety, reliability and quality.
Tracking Field Failures to Meet ISO 26262 Requirements
Finally, the operation, service and decommissioning phases of the product lifecycle are also essential to the ISO 26262 standard, which indicates a field monitoring process for functional safety events that do occur in fielded products. This process is typically facilitated by a FRACAS (Failure Reporting, Analysis and Corrective Action System). A FRACAS supports the required monitoring of real-world maintenance, repair and decommissioning activities associated with fielded products, as well as the reporting of failure events and incidents.
A FRACAS provides for the trending of reported failures, the analysis of critical failures and incidents, and the escalation of these issues to a root cause analysis and corrective/preventive action process — which is then traceable through to a review process to evaluate effectiveness and issue resolution. In this way, the FRACAS provides a complete, closed-loop system ensuring every reported failure or issue is addressed, and thereby helps to mitigate or eliminate critical part or system failures in future products.
Data analysis in a FRACAS may be supplemented by Weibull — or Life Data — analysis, a methodology for the statistical calculation of failure trends, including warranty metrics and costing. Used together with the risk and reliability analyses performed during the earlier System Safety Analysis processes of the product design and development phases, these become even more powerful tools. They capture and communicate real-world product performance metrics back to the reliability prediction and FMEA analyses — enabling these calculations to account for the actual performance of parts and systems in the field, and yield even more accurate safety and reliability results during next-generation product design.
Less Read More
Related Resources for ISO 26262
ISO 26262 and Requirements Management
As a risk-based safety standard, ISO 26262 is designed to assess and address possible hazards caused by the malfunctioning of electronic and electrical systems. It begins with a process of defining top-level requirements — both general and safety-related — from internal and external stakeholders, including customers. Top-level requirements are broken down further into specific system requirements and allocated to their component sub-systems.
Determining Safety Levels
Throughout this process, safety goals and hazard levels are determined for safety-critical requirements. Safety and hazard are represented with a value known as ASIL, or Automotive Safety Integrity Level, which quantifies the impact on the driver and other road users by combining probability of exposure, controllability of the situation and severity of the failure. Each ASIL is associated with a safety goal (i.e., safety requirement) to represent the value that the sub-system or system must achieve to fulfill that requirement. ASILs are critical to the product development process that follows the requirements development phase. They inform subsequent system design, test, production, operation, service and decommissioning activities, which must be completed with the ultimate objective of achieving the ASIL goal.