Fundamentals of Semiconductor ISO 26262 Certification: People, Process and Product

Find the Latest SoC Solutions
for... Automotive... IoT... Security... Audio... Video

Many in the semiconductor engineering community are new to the ISO 26262 functional safety standard and the automotive industry. This paper explains the changes in the role of the semiconductor industry in the automotive supply chain and seeks to enhance the reader's knowledge regarding all aspects of the ISO 26262 standard. This paper also discusses the standard's applicability not only to electronic products, but also to the people and processes employed to create them.

Campbell, CA, Aug. 15, 2018 – 

Introduction

Developers of automotive semiconductor devices and electronic systems beware: There may be some vendors who claim their products meet the ISO 26262 safety standard requirements for integration into the production of passenger vehicles without fully understanding the nature of the challenge. These claims might be superficial if they fail to account for the people and processes that are used to make a product intended for an automobile. If system designers fail to carefully assess a vendor's qualifications, they risk difficulties getting their product accepted by customers in the automotive supply chain.

Participants in the automotive supply chain are responsible for performing their own functional safety assessments of each vendors' offering, taking into account their suppliers' documented Assumptions of Use (AoU) which describe how the vendor's product is expected to be used in an automotive system. Vendors tailor their own analysis to specific configurations and use cases that will hopefully match those of their integrator customer. A third-party ISO 26262 certification for an element1 to be used in an automotive system can help the system integrator perform this analysis, but it does not replace the obligation of integrators to analyze their vendor's product in the context of the integrator's own use.

This paper explores the fundamentals of ISO 26262 certification for the people, processes and products involved in designing functionally-safe electronic systems for automobiles. The end goal is to make development teams, executives and investors more aware of the responsibilities involved in complying with the details of automotive safety standards. That, in turn, will provide more information on the efforts and costs associated with compliance and will also enable more efficient communications between supply chain members.

All electronic systems for passenger vehicles must satisfy rigorous safety requirements before they are integrated into an automobile manufacturers' product. The suppliers to this industry have established a sophisticated supply chain in order to deliver these systems, along with proof of the products' ability to meet these safety requirements. This system of information sharing requires detailed exchanges between intellectual property (IP) vendors, semiconductor system-on-chip (SoC) developers, component suppliers, software providers, electronic system designers, and many others to ensure that all critical components comply with ISO 26262 guidelines, procedures, training levels, audits, and assessments.

However, the automobile industry is currently witnessing rapid change as more and more mechanical features transition to electronic systems. As a result, the functions that were in the past performed by a human driver are being supplemented by advanced driver assistance systems (ADAS), which are evolving into autonomous driving systems. These two trends are fueling a wave of economic growth and technological innovation in the automobile industry. The promise of rapid market growth is spurring new entrants who are aiming to participate in the automobile industry's electronics boom.

What recent entrants might lack is experience in developing and delivering their products in accordance with the ISO 26262 functional safety standard. While these vendors may state that their products are ready to comply with auto safety standards, the companies in the supply chain will still demand an extensive, careful review and assessment of the personnel and procedures involved in developing the product before it is integrated into larger systems. It is important to note that the ISO 26262 standard applies to the people and processes that make the products as much as the product itself.

One way for participants in the automotive electronics supply chain to proactively address this issue is to obtain ISO 26262 certifications from accredited assessment bodies. However, most electronic products targeted for automotive use are not complete standalone systems that can be certified to the ISO 26262 standard with complete knowledge of how the product will be integrated and used in a vehicle. Therefore, it is important for any development team that is serious about serving this market to explore their vendors' claims regarding functional safety whether a certification is claimed, or not. While third-party product certifications can be a part of this process, an evaluation of any component must go deeper and must be done by the company using and integrating the product. Failure to conduct assessments on a vendor's personnel, process and product qualifications could result in rejection by customers further along the supply chain.

The International Standards Organization (ISO) states the following:

Electrification of vehicle systems continues at a rapid pace, both in terms of the total content of the car and in terms of advanced control capabilities. This trend is propelling a growth spurt in innovation, and it is also attracting larger investments, greater research and development efforts, and new entrants to the automotive market.

What many of these new entrants might not know is that compliance with automotive safety standards requires information sharing through every part of the supply chain. Experienced development teams at every level are challenged by these standards because requirements are evolving and there are only a few experts available throughout the industry to guide projects through this process. In addition, participants in the semiconductor and software supply chains are usually secretive about how their IP was developed and how it works in detail.

The information that vendors must provide includes analyses, education and documentation for every element of a system which has a safety goal. This information must be provided by every member of the supply chain. Semiconductor IP vendors supply this information to developers of SoC devices. The chip design teams use this information to analyze their custom systems and pass the results along to Tier-1 electronic system suppliers. These Tier-1 suppliers then perform their own analysis and send the results to the vehicle manufacturers and their customers.

These relationships in the automotive supply chain are becoming more complex because traditional semiconductor vendors who are making or designing chips to enable autonomous driving applications are nowadays sometimes competing with Tier-1 electronic system designers and OEMs, who may be making their own chips or providing explicit requirements to their semiconductor vendor partners. Additionally, new entrants like Uber, Waymo and Apple are designing their own complete systems, despite their relative lack of experience in the automotive industry. ISO 26262 mandates high levels of collaboration and information sharing throughout the value chain that may be unfamiliar to new entrants.

Increasing complexity throughout the automotive industry is driving continuing efforts to enhance the safe operation of these systems. Here is a simple example of how safety analyses can be affected in this transition from mechanical to electronic systems: Modern automobiles use "by-wire" systems such as throttle-by-wire, where the driver pushes on the accelerator and a sensor in the pedal sends an electrical signal to an electronic control unit (ECU). This electronic system replaces the past mechanical method of using a metal cable attached to the accelerator pedal and mechanical throttle control plate. The ECU is smarter than the mechanical approach: It analyzes several factors such as engine speed, vehicle speed, and pedal position and then relays a command to the throttle.

Even in this simple example of the electrification of systems in cars, we can see that testing and validating the throttle-by-wire system is more difficult than testing the older mechanical version. Complexity has exploded as we have replaced mechanical systems with electronic ones, electrified drivetrains, and added ADAS and autonomous driving capabilities to cars. The goal of ISO 26262 is to have a unified functional safety standard that addresses all of these automotive electronic systems.

New functionalities such as driver assistance, electric propulsion, in-vehicle dynamics control, and active and passive safety systems increasingly touch the domain of system safety engineering. The greater technological complexity, software content and mechatronic implementation come with greater risks of systematic hardware failures, which are produced by human error during system development. ISO 26262 provides guidance on how to minimize risks by prescribing requirements and processes.

For designers of semiconductor SoC devices and IP, the requirements of ISO 26262 compliance are more abstract when compared to the guidelines for complete systems. Therefore, the developers of IP must perform additional analyses regarding many sets of assumptions to determine IP readiness for integration into a functionally-safe automotive system. Appendix A, "ISO 26262 Fault Reference Chart," provides more information regarding categories of faults, types of fault analyses, and the parts of the ISO 26262 standard that discuss these. By following best practices and adopting them throughout an organization, a company can provide the required proof that its IP is a safe and reliable component for automotive systems. Successful companies also emphasize employee training as evidence of their commitment to comply with the requirements of ISO 26262 and ensure a strong safety culture.

The goal of ISO 26262 is to provide a unified safety standard for all automotive electronic systems. Achieving system safety requires that several safety measures be implemented in a variety of technologies such as mechanical, hydraulic, pneumatic, electrical and electronic systems, and that these safety measures be applied at various levels of the development process.

ISO 26262 defines various automotive safety integrity levels (ASIL)–QM, A, B, C and D–to help map the required processes, development efforts, and in-product functional safety mechanisms to levels of acceptable risk. These five levels of rigor span the broad range from basic quality management to systems where malfunction can lead to fatal accidents. In this latter case, ASIL D requires the single point fault metric (SPFM) in an automotive system to be less than 1%. Table 1, below, has more information relating ASIL levels to fault metrics.

Automotive SoCs offer diagnostic coverage through specific hardware capabilities to ensure compliance with ISO 26262. These on-chip functional safety mechanisms include techniques such as error correction code (ECC) and parity protection for data links and internal memories; intelligent duplication of processing elements through smart interconnect fabric; built-in self-test (BIST); and error reporting mechanisms.

Although ISO 26262 is concerned with the functional safety of E/E systems, it actually provides a framework that addresses the entire lifecycle of a safety-related system. ISO 26262 provides guidance on the following:

• Lifecycle management, product development, production, operation, service, decommissioning, and tailoring the necessary activities during these lifecycle phases
• Applicable safety requirements according to a hazard's severity, the probability of exposure, and controllability to avoid unreasonable residual risk
• Validation and confirmation measures to ensure a sufficient and acceptable level of safety
• Requirements for relationships with suppliers

All of this seems onerous at first but understanding the gist of ISO 26262 can be simplified by focusing on three main areas, the "3P's":

1. People
2. Process
3. Product

A vendor must provide customers with documents that detail the steps taken by the organization to prepare the people, processes, and products to comply with the standard. Armed with a broad perspective on the role of the "3 Ps" within the semiconductor IP market, SoC architects and design teams can make informed choices in selecting the appropriate IP. Knowledge of organizational and operational characteristics of the IP provider leads to better chips, safer passenger vehicles and more efficient development.

Functional safety involves all parts of the development process including specification, design, implementation, integration, verification and validation. It also includes the production, management and service processes. There is a high degree of difficulty in building an organization that designs IP for automotive SoCs because of the specific demands of the safety standards. Additional training, assessments, evaluations, analyses, and documentation required for customer qualification and third-party ISO 26262 certification can add significant expense to the development of IP for the automotive market.

Proof of these functional safety activities must be communicated up the supply chain. As a result, every organization that provides products to the automotive semiconductor market must be able to document that development activities comply with the standard. The documentation covers the personnel involved, the processes used to develop the solution, and the analyses of the products that are needed to comply with ISO 26262 standards.

The first step towards ISO 26262 compliance for a semiconductor IP is to train the people involved in IP development. Many companies take the "shortcut" of training a small group of people, usually the ISO 26262-required functional safety manager (FSM) and a handful of "safety engineers".

However, this may not be sufficient to meet the spirit of ISO 26262 because of the requirements of ISO 26262 Part 2, "Management of functional safety," specifically clauses 5.4.2 "Safety culture," and 5.4.3 "Competence management." Ensuring a sustainable safety culture where team members have a sufficient level of skills, competences and qualifications corresponding to their responsibilities requires that functional safety knowledge be broadly known throughout an organization. This requires substantial employee training.

While training involves engineers, it also needs to include other people within the organization who are involved in product development and support. This can include executives, marketing personnel, engineering staff, documentation teams, quality assurance managers, application engineers and others. The organization's assigned and trained functional safety manager (FSM) is tasked with promoting a strong safety culture among all the people involved in product development and the FSM is usually responsible for providing in-house or third-party training for all these employees. Proof of employee functional safety training is often required by customers–called "integrators" in ISO 26262–of semiconductor IP as well as third-party ISO 26262 assessors.

As an example of a practical implementation, more than 50 of Arteris IP's employees have been trained and certified as ISO 26262 Functional Safety Practitioners (FSP) by ISO 26262 consultancy exida, who is also an ANSI-accredited certification body for the ISO 26262 standard. Arteris IP has an experienced FSM on staff, and it promotes a safety culture not only through its extensive ISO 26262 training programs but also with the establishment of functional safety processes that ensure quality throughout the semiconductor IP development process. Appendix B, "In-Person ISO 26262 Training and Certification Courses for Individuals and Teams," lists providers of employee training and certification. Appendix C, "Online ISO 26262 Training Resources," is a list of free and low cost online introductory training resources.

Using good processes is crucial to avoiding systematic faults. Systematic faults are tied to a specific cause in a predictable way and can only be eliminated by a change in the design, manufacturing, operational procedures, documentation, or other relevant factors of the system. In short, systematic faults are "designed into" the system. Quality processes help avoid designing faults into systems.

Because we are engineers, much of the attention to ISO 26262 processes gets caught up in the use of technologies and software tools to address the details of ISO 26262 Part 8 titled "Supporting processes." This is the wrong approach.

The key to a good safety process, or any product development process in general, is not the expert use and integration of tools for requirements management, change management, verification and other parts of the development process, but rather the continual use of a quality management system (QMS) by all employees.

Any process that meets the ISO 26262 Part 8 requirements for quality management systems is acceptable for ISO 26262 compliance. However, there are already existing software, hardware, and automotive system development QMS that are state-of-the-art and can be the foundation of a vendor's process.

Table 2 below provides some examples:

Third-party assessment companies provide certifications for each of these quality management systems. Nevertheless, as a supplier in the automotive supply chain, your customers will perform independent audits of your processes, whether you have obtained a third-party process certification or not. Although the reports accompanying third-party process certifications can help your customer assess your processes, your customer still has an obligation to confirm your compliance with ISO 26262.

In the case of Arteris IP, which develops semiconductor IP for use inside chips used in the automotive market, the company implements the CMMI® (Capability Maturity Model® Integration) for Development (CMMI-DEV) quality management system. This QMS provides more specific guidance for software and semiconductor IP development than any other system, and thereby stipulates more relevant and "strict" guidelines for development with fewer process areas left under-defined or ambiguous.

Although choosing, using, and managing a relevant quality management system is the most important process-related ISO 26262 activity, there is one area where technologies and tooling greatly help in achieving ISO 26262 compliance. That process area is traceability.

In the chip design world, most design teams already have state-of-the-art systems to trace specification items through implementation and then on to verification testing. However, ISO 26262 requires two-way traceability of safety-related requirements, and their implementations, from concept phase–ISO 26262 Part 3–through to production and operations–ISO 26262 Part 7. This means that a quality assurance (QA) test result could be traced backwards through its verification tests, implementation, specification and requirements. Also, configurations, changes, and documentation need to be kept current and part of the traceability information chain.

This level of traceability is usually new to semiconductor design teams that have not developed products serving the automotive market. It's very difficult for these teams to change their spec implementation and verification systems that have worked well in the past to adopt a new system that supports broader traceability. One solution is to implement a traceability system that integrates and "wraps around" the existing development systems in use by engineering to provide the required level of traceability.

For example, Arteris IP has been using the Atlassian Jira issue tracking tool as the core of its product development spec-implementation-verification processes for both semiconductor IP and associated IP configurability software. In the past, items from Microsoft Word-based market requirement documents (MRD), product requirement documents (PRD) and specifications were used as inputs to the Jira system and associated with engineering development tasks, where their status was tracked, and verification tests automatically generated and logged.

Today, because of the need to meet the more complete traceability requirements of ISO 26262, requirements entry and tracking are performed by Arteris IP using a system from Jama Software, which links to the items and activities in the existing Jira system. The combined Jira and Jama system helps the Arteris IP team maintain links between requirements, specification items, implementation, verification and QA while also addressing change management traceability and documentation automation.

The bottom line on the ISO 26262 process is that most companies targeting the automotive market must do the following:

1. Choose an ISO 26262-compliant quality management system, use it, and be able to explain your use of it to third-party assessors and your customers' assessors.
2. Implement a broader level of automated traceability to cover requirements all the way to QA, delivery and support.

At this point, we can clearly state that if a vendor claims that its products "meet the safety requirements of ISO 26262" without first training its employees and documenting its processes, then it is not in compliance. Once people are trained and quality processes are in place and being used, the next step is to analyze the product with respect to ISO 26262 and provide documentation of the analyses to the semiconductor integrator. For semiconductor and semiconductor IP vendors, performing this analysis requires documentation of a set of agreed-upon assumptions because the chip or IP vendor will not have complete knowledge of the system in which it will be a part.

Here is the issue in a nutshell: ISO 26262 analyses are predicated on the assumption that a "system" is the entity being developed and analyzed, and Part 1 of ISO 26262 defines a system as, "a set of elements that relates at least a sensor, a controller and an actuator with one another." Obviously, a chip and the IPs used to make it are not systems per ISO 26262. So, what are they?

Chips and their IP ingredients are usually developed as "elements" of a (usually unknown at design time) system. Because knowledge of the complete system of which they will eventually be a part is not 100% understood, chips and IP are classified as special types of elements in ISO 26262, specifically, "Safety Elements out of Context," or "SEooC." Analysis of a SEooC requires the IP provider or integrator to document Assumptions of Use (AoU) that reflect the expected safety concept, safety requirements, and safety mechanisms to be used by the integrator/user of the IP.

Additional assumptions regarding which parts and clauses of ISO 26262 are relevant to the implementation and analysis of the IP element are documented in a process called "tailoring." In addition, based on assumptions of the characteristics and safety goals of the end system and the validated hardware metrics (see FMEDA below) of the IP, "ASIL tailoring" is performed to determine which configurations of elements can meet ASIL QM, A, B, C or D requirements.

Because there are so many assumptions regarding SEooC, AoU, and tailoring for chips and IP, the ISO 26262 requires IP vendors and chip integrators to agree upon a Development Interface Agreement (DIA) defining the assumptions used by and responsibilities of both parties. This DIA document will explain the ASIL tailoring from the IP supplier and the reasoning behind this tailoring, as well as an explanation of all assumptions of use. As an illustration, Arteris IP provides a complete DIA document explaining the ASIL tailoring related to FlexNoC and Ncore products and the expected responsibilities delegated to the customer, with the reasoning behind those decisions. For instance, since Arteris IP is implemented within a chip as RTL components, all the ISO 26262 requirements related to process technology usage are delegated to the customer because they are the one choosing the technology node for their SoC.

In-product functional safety mechanisms are used to detect, mitigate, and correct faults and failures caused by random errors when a system is in operation. Single event effects (SEE) –electrical disturbances caused by cosmic rays and the ionization energy emitted when they interact with semiconductors–are the cause of random errors. These random errors can have transient (temporary) or permanent effects. Examples of random, transient effects–also known as "soft errors"–include single bit upsets (SBU), such as "bit flips" in memory cells or logic flops, and single event transients (SET), which are voltage glitches that may or may not cause an error. There are also instances where these can occur simultaneously, resulting in multiple bit upsets (MBU). "Hard errors" caused by SEEs resulting in permanent damage include single event latch-up (SEL), single event burnout (SEB), and singe event gate rupture (SEGR).

Because the cause of these errors is natural physical phenomena and they will occur randomly, it is important to detect and mitigate their effects to achieve and maintain system safety. To do this, engineering teams develop safety-specific technical features within their products. Below are examples of these features, also known as functional safety mechanisms:

• Adding and checking parity or ECC bits added to on-chip communications traffic
• Duplicating logic and comparing results
• Triple mode redundancy (TMR) or majority voting
• Communication time-outs
• Hardware checkers that verify correctness of operation
• Safety controller to gather error messages from throughout the system, make sense of them, and communicate higher up the system
• Built-in self-test (BIST) for all functional safety mechanisms

Now that we have described the assumptions required for analysis of IP and chips, and their failure modes and safety mechanisms, we will now discuss the actual analysis processes.

Once the design team understands its element functionality, failure modes, and functional safety mechanisms, it is time to perform and document a qualitative safety analysis, called the Failure Mode Effects and Analysis (FMEA). The FMEA is a is a step-by-step approach for identifying all possible means of failure in a design (failure modes) and the consequences of those failures (effects). Design teams often fail to pay enough attention to the qualitative analysis of their item, preferring to jump right into quantitative analysis. This is a mistake! Correctly performing the FMEA, first, is the key to correctly defining how to mitigate faults and is the foundation of latter quantitative analysis used to validate the FMEA.

After completing the FMEA, the design team must further analyze the element, failure modes and safety mechanism using quantitative analysis, called Failure Mode Effects Diagnostic Analysis (FMEDA). Although assumptions regarding the diagnostic coverage (i.e., "protection") of most functional safety mechanisms can be estimated, most semiconductor integrators insist on IP providers using fault injection techniques to validate the diagnostic coverage of functional safety measures implemented in the item. Detailed knowledge of the IP implementation is required to determine where faults must be injected to trigger a functional safety mechanism, and where the mechanism's outputs should most efficiently be observed. In addition, complex clocking schemes and other behaviors can mask faults which can either affect safety or appear as "safe faults," depending on the use case.

Although fault injection analysis is important to validate the FMEA, it alone is not sufficient for the FMEDA. Other techniques are used in concert to validate diagnostic coverage that cannot be easily demonstrated using fault injection. An example is validating an Assumption of Use that defines a safety mechanism that the customer must integrate along with the element. This is quite common for safety mechanisms that reside outside an IP block, such as clock and voltage monitors. The additional techniques that can be used in addition to fault injection to validate FMEA include Fault Tree Analysis (FTA), Dependent Failure Analysis (DFA), and pin-level FMEA. Arteris IP uses a combination of these techniques to validate the qualitative FMEA for its interconnect IP and delivers this analysis to integrators as part of the FMEDA report.

The FMEDA report–created by the IP development teams–allows fully-trained safety managers to review all the information regarding adherence to ISO 26262. A third-party assessment firm or consultancy, hired by either the IP provider or semiconductor integrator, can also review the analysis and development processes to help assess functional safety compliance.

Satisfying the standards of functionally-safe components for the automotive market under ISO 26262 is a difficult and arduous process involving the people, processes and products of the supplier. Creating products and technologies that meet these needs requires operational and engineering focus, robust safety culture, management commitment, and significant investments in both time and money. If a vendor offers such a product, it is up to the integrator to discover if the vendor has taken all the steps beyond the product level to determine if the claims are valid. Failure to investigate further leaves integrators at risk of using components that will not stand up to the assessments and audits required to achieve ISO 26262 compliance by their customers further up the supply chain.

Projects that rely on incomplete information about the people, processes and analyses involved in product development of items with a safety goal might invalidate efforts to enter the emerging electronic system designs for passenger vehicles, including those for ADAS and autonomous cars. Electronic system integrators must offer proof to automotive manufacturers that all of the components of the system have been evaluated thoroughly to validate claims that they are safe and reliable. Failure to understand and follow the standard, and to communicate how the standard was followed, could result in additional work or rework by an automotive supplier.

 Back