The question: When looking at functional safety, what is the difference between being ISO 26262 compliant and being ISO 26262 certified?

When asking such a question, it is very important to consider that functional safety is based on standards, and those standards are written as guidelines. In the automotive industry, ISO 26262 is the primary guideline for functional safety. The methods in the standard are defined with recommendations that an organization can use to be compliant to functional safety. The aerospace, medical devices, and other transportation industries, have their own guidelines. IEC 61508 is the parent of ISO 26262, the aerospace standards ARP 4754, DO-178, and others follow a similar structure.

FSXpressway Ebook Download

 

The reason there is a difference between ISO 26262 “compliant” and “certified” is because those guidelines can be adopted in many different ways. The implementation methods are the keys to success for organizations. An organization can decide to adopt parts of the standard or all of the standard. Therefore, implementation is truly a spectrum. As long as an organization has a defensible position when it comes to safety, it can be considered compliant.

This isn't only true in the automotive industry; it's true for most safety-critical industries, such as medical devices, which have to deal with the FDA, and aerospace, which has to deal with the FAA. The spectrum of implementation also exists in related processes or maturity-based standards, such as CMMI or ASPICE or IATF 16949. In some industries, following the standards completely is much more likely to gain favor with the regulators for an organization. Currently in automotive, self-certification is very popular and still acceptable. This leads organizations to claim compliance instead of pursuing third-party assessments (i.e., certification).

Understanding the Foundation of the Safety Standard ISO 26262

To answer the original question, it is vital to understand the principles of the automotive safety standard ISO 26262.

Understanding the multiple parts of ISO 26262 is fundamental to getting a better perspective of why being compliant and being certified are different. There are parts and methods in the standard for management, systems engineers, hardware engineers, software engineers and production, and then supporting processes and guidelines for the entire organization.

Part 2: Organizational Structure and Management, describes what the leadership in an organization needs to do to be compliant to functional safety. It covers things like rules and decision-making the organization for functional safety. It covers evidence of competence, quality management, how an organization assesses functional safety, and what kind of measures are in place. It also addresses details such as evidence of field monitoring for safety issues. These work products result in an organization which has a management structure that can be compliant to functional safety and reliably produce safety-based products. For example, there is a requirement in the standard which says a project manager shall ensure that the safety manager is appointed in accordance to Part 5, 4, 3, or another section in the standard. It requires that the project has a safety manager with a specific authority level, which is defined in the standard. processes across 

Parts 3 and 4 address systems engineering. From an organizational standpoint, it addresses the safety goals definition, the hazards definition, the verification methods for those hazards, and the requirements that define the technical solution. These sections also define the Automotive Safety Integrity Level (ASIL) classification, which is the basis for the implementation methods.

Safety plans, safety assessments and requirements, verification reports, and analysis are all done as a portion of Part 3 for functional safety. There are a couple dozen work products that need to be produced to meet the requirements in this section.
 
ISO 26262 Certification

Parts 5 and 6 are for hardware and software engineers. There are recommendations for designers of hardware and designers of software, and tables for the kinds of analyses that need to be produced. Furthermore, there are descriptions of verification artifacts that need to be produced.

Part 7 covers the production aspects of the product development lifecycle from the equipment used to the repair station requirements. Part 8 covers the infrastructural items of an organization such as the quality aspects, vendor management, requirements management, and the tool chains. Overall, there are over 900 pages of recommendations.


The Difference Between Being ISO 26262 Compliant and Being Certified

Going back to what the difference is between being compliant and being certified, let's take a couple of specific organizational examples. For compliance with ISO 26262, the recommendations given by ISO 26262 need to be addressed and integrated into the organization’s workflow process, tool chains, and designs. The organization will then have a defensible position which is independently audited through its own quality organizations.

This implies that a company does have a quality organization capable of auditing against the standard. For many startup companies, this is not the case. Therefore, being compliant is much more difficult for smaller organizations that don't currently have the formality or process-adherence methodology.

Being certified to functional safety means that in addition to being compliant, a third party such as TÜV NORD, has audited and provided a certificate of completion that validates that the company has effectively implemented guidelines for functional safety.

Vendor Selection 

When an organization is attempting to select a vendor and they are compliant to functional safety, it implies that they have made an attempt to address the items described in ISO 26262 to the best of that organization’s knowledge. It also implies that the organization believes that they have addressed all the items and have a defensible position when it comes to developing safety-critical products.

When selecting a certified vendor, it implies that they also attempted a compliant implementation for functional safety and a third party has validated that work. Some organizations will use that credibility to help sell its products. ISO 26262 certification is becoming one of the criteria that affects vendor selection. Being certified gives the vendor a third-party approval for functional safety; being compliant may require audits to verify implementation.

To summarize, ultimately “compliant” and “certified” have the same intent. The organization is saying that it has taken functional safety seriously, and it has attempted full ISO 26262 implementation. When certified, it implies a third party has validated that process, and it lends more credibility to the process.

New call-to-action

Which Should You Pursue?

Choosing  between pursuing compliancy or certification depends on various factors such as budget and requirements or expectations from the organization’s customers. It is strategic for a company to have its development process be compliant with the ISO 26262 standard. That implies that the company has established the necessary management systems with the necessary processes to meet the standard. The compliance is determined by the company itself on a self-evaluation after establishing the processes.

To be certified carries the additional value of having these developed processes and management systems being audited by an external company. The certification will give more credibility to the processes since it is provided by an external entity, but it also requires more time and can be a bigger investment.

The decision of moving to compliance or certification might also consider an input or request from a customer expecting compliance or certification from their suppliers. Ultimately, there is no right or wrong answer. Both options are a strategic decision to get ahead of the curve and LHP can help your organization achieve either.

To get in touch with an LHP team member, reach out to our team today! 


CONTACT US

 

 

Steve Neemeh

Written by Steve Neemeh

Steve joined LHP in 2015 to lead the expansion of the west coast operations. He is the leader of the strategy and solutions architects as well as president of the delivery consulting organization. Steve has over 25 years of Functional Safety experience prior to joining LHP. Steve has launched multiple start-up operations and has taken them to full production. Notably, a complete ground up electronics and software development group to service commercial aerospace electronics and military vehicle power electronics. For LHP, Steve pioneered the implementation of safety critical applications in California, launching functional safety for autonomous driving applications as well as air mobility.