Product Quality & ISO 26262

PTC Windchill Quality for Road Vehicles Functional Safety

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 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 subsystem 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, subsystem, and system failure rates. This in turn improves product safety by reducing the risks attributed to part, subsystem, 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 subsystem. 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. An 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 re-evaluate 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, subsystem, and parts levels, while also considering external factors and human errors that can also contribute to the negative end event. Like the FMEA process, a Fault Tree 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, subsystem, or part – as calculated during reliability prediction – can be used to inform the likelihood of a risk under analysis in the FMEA or Fault Tree when that risk is due to part failure. Similarly, an FMEA – with its comprehensive analysis of component parts and subsystems that lead to certain negative end events – can be used to construct a Fault Tree, to determine how those potential component failures may together contribute to other various negative end results.

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 Fault Tree analysis; 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, and 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 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.

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 stakeholders both internal and external to the organization, including customers. Top-level requirements are broken down further into specific system requirements and allocated to their component subsystems.


Determining Safety Levels

Throughout this process, safety goals and hazard levels are determined for safety-critical requirements. Safety and hazard is 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 (safety requirement) to represent the value that the subsystem 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 level goal.