In this post, we discuss Apex.AI’s selection of Jama Connect to shorten development time and increase efficiency.
Award Winning Automotive Software Developer Selects Jama Connect® to Shorten Development Time, Increase Efficiency, and Sail Through Audit Preparation.
Apex.AI, founded in 2017 in Palo Alto, California, is a mobility software company, and makers of the ISO 26262 ASIL-D safety-certified software framework Apex.OS. As a pioneer in modern C++ software development for safety, they are the first organization to certify a modern C++ open-source product to ASIL-D. Their client list is extensive and prestigious, and they are backed by some of the leading venture capital firms in the world, including Lightspeed Ventures, Toyota AI Ventures, Volvo Ventures, and Airbus Ventures.
More about Apex.AI:
Headquartered in Palo Alto, CA in the heart of Silicon Valley with offices in Munich, Berlin, and Stuttgart, Germany and with employees worldwide.
Founded in 2017 in Palo Alto, CA
Expertise: Building robust, reliable, safe, secure, and certified software for mobility systems
Recent Awards for Apex.OS, the safety-certified automotive OS:
Apex.OS wins two awards from the German Design Council (June 2021): “Best of the Best” award and “Innovation of the Year” award
With a mission to enable automotive developers to implement complex AI software, and enable AI developers to implement safety-critical applications, Apex.AI is an innovator in the automotive industry.
Comprised of alumni from top automotive, robotics, and software companies around the world, the Apex.AI team knew that development success starts with requirements management. That’s why they set out to evaluate the top requirements management solutions from the very beginning. The team had clear objectives and knew that their requirements management solution needed to:
Allow the team to create a centralized repository of requirements
Help them demonstrate compliance with stringent automotive standards like ISO 26262
Enable collaboration across a globally distributed team
Be a modern, cloud-based solution that all team members could use
The team did not take the selection process lightly; they knew there was too much at stake. Apex.AI did an analysis of the full requirements management tools and software market and decided to evaluate Siemens Polarion and YAKINDU more in-depth.
After an in-depth analysis of these requirements management (RM) tools – including interviewing current users of these products – Jama Connect was selected as the solution of choice for the team for the following qualities:
End-to-end traceability from requirements all the way through to tests
Powerful, flexible solution that all team members can easily use
Industry-specific templates and expertise in automotive development
An easier path to compliance
“Why would an innovative automotive company consider Jama Connect? From my perspective, Jama Connect is the best of breed requirements analysis and requirements engineering tool… I would highly recommend it and I would use it again without any hesitation on any subsequent project. ”
Neil Langmead – Senior Functional Safety Engineer, Apex.AI
Jama Connect was also the only solution that had Living Requirements™ management, which allows teams to move away from static requirements trapped in disparate documents and creates a digital thread through upstream and downstream activities.
“Jama Connect doesn’t require much in the way of support and overhead. Once we installed the cloud-based solution it ‘just works’ – and that’s the highest validation for any complex piece of software.”
Neil Langmead – Senior Functional Safety Engineer, Apex.AI
In this blog post, experts from Cadence, OpsHub, and Jama Software talk about enabling digital transformation in the hardware and semiconductor industries.
The relentless pace of innovation, rapidly changing markets, and increasing product complexity are creating intense pressures on companies in the semiconductor and hardware space. Some of the biggest challenges relate to scaling effectively and efficiently within the context of digital transformations.
Organizations in all sectors are looking to support faster release cycles and accelerate innovation. Siloed and legacy tool chains create a major hurdle in accomplishing these goals.
Watch the webinar or read the recording to learn more about:
Rich collaboration
Complete traceability
Full transparency among all stakeholders
Faster releases
Improved quality and productivity
Below is an abbreviated transcript and a recording of our webinar.
asd
Jama Connect: the Leading Platform for Requirements
Matt Graham: Thanks everybody for joining. So today, before we get into the agenda just to introduce the three products that there are three subject matter experts about. First of all, something near and dear to my heart, the Cadence vManager, verification management platform which is a scalable, reliable and very feature rich verification planning and management solution from Cadence. That sits on top of a number of our verification and provides a sort of roll up capability. And we’ll describe it in a little more detail in a couple of slides. On the OpsHub opposite side, we’ll be looking at the OpsHub integration manager that enables enterprises to integrate their best of breed tools together that are best suited for the various teams and their various roles and connect those two together for integration and collaboration. And then Jama Connect, which is the leading platform for requirements, risk and test management to help provide that sort of end-to-end compliance solution.
Our agenda today. First we’ll look at some of the challenges of the semiconductor and hardware development ecosystem. This is obviously a very fast paced, highly competitive type of environment and there’s a lot of specific challenges that the integration of the tools I just mentioned can help address and solve. We’ll look at how engineers in this space can scale effectively and efficiently utilizing some of these, the tools to address some of the ongoing transformations in that space. And then specific to semiconductor domain, bridging the gap in what has historically been a very siloed development process. And bringing together for efficiency, quality and reliability all of the various tools that I mentioned and giving it a really nice integrated development and verification environment. We’ll then have a specific use case and demo showing how the three tools work in concert and then look at some key takeaways. And as Marie mentioned, some Q and A.
Standards for Requirements such as ISO 26262
Specifically to the semiconductor and hardware ecosystem, there are a developing set of challenges. And of course they’ve always been challenges in this area. First pass design success is critical for hardware development. Just because the tooling costs are so great. We don’t want to have to respurn hardware. It’s not like just releasing more software. It is it requires expense. But that has been the way of hardware development for some time. In the last several years we’ve seen a need creeping into that environment for even stricter compliance, particularly around mission critical domain such as aero and defense, automotive especially as self-driving and autonomous vehicles come in. And adherence to standards like ISO 26262 presents another layer of requirements and need for management and collaboration on top of an already strict set of sort of design parameters.
As I mentioned, this development environment tends to be very siloed in its nature because it is so specialist. You have specialist designers, specialists verification engineers to test the designs, specialists post silicon, specialists layout engineers and so on and so forth. And all of those silos, well somewhat required of the specialty of each of those tasks tends to hinder collaboration, compromise quality and just impact efficiency and velocity overall. In an area where efficiency and quality is critical. We can’t have bugs in semiconductors going to automotive and we need to be able to turn those new cell phones, those new mobile devices as quickly as possible. So turnaround time is just getting compressed and the requirement for quality is increasing at the same time.
All of that sort of siloed nature of the specialties as well as the need for velocity and quality really ends up in poor traceability of results in terms of compliance and quality issues creeping in. Especially when it comes to doing things like audits for ISO and other similar standards that are becoming the requirement across again aero and defense type applications, automotive type applications and even down into the sort of consumer device applications. And really traceability is a watch word now in the ecosystem of hardware and semiconductor development.
So how does the offering from Cadence, vManager fit into and help provide a solution to those challenges that I just mentioned? Well, for a number of years now, in fact, vManager has been around for about 15 years and in that entire time it’s had the key capability of the verification plan. And the verification plan really exists to provide traceability between what is being executed during the testing or verification of your semiconductor or hardware design. And what were the goals of that or the requirements of that testing or verification project. Things like testing interfaces, both internal and external to the semiconductor, testing compliance with standards like ethernet and USB, such as that, things like that. As well as the internal requirements of the device, it must route packets this fast. It must answer phone calls in this manner or whatever it might be.
And the verification plan in vManager really allows the user to enter those requirements and then connect them to the real results that are occurring. We ran these tests, these tests were associated with a given requirement. Those tests passed therefore the requirement is satisfied. And so the V plan becomes a very natural place. And in fact the appropriate place to connect the rest of the ecosystem via OpsHub, two tool requirements coming from Jama Connect so that we can have traceability across the software development, the hardware development, whatever. The mechanical development et cetera ecosystems. And the vManager and the verification plan is really where that hardware verification, that hardware and semiconductor development information enters that ecosystem through the conduit of the verification plan. So let’s look a little bit more on, well what exactly is in that verification plan that vManager provides.
Enabling Digital Transformation: Static Documents Cause Challenges
And the V plan is really what we call, what we refer to in our vManager sort of pitch if you will as an executable verification specification or an executable verification contract. And what that means is that there’s data incoming to that during the creation, the authoring of that verification plan. Not only through connectivity to tools like Jama but also from say static documents like standards specifications, ethernet that I mentioned before, USB those are standard protocols that have very lengthy standards documents and needs to be a way to import, kind of gather the data from that and put it in the verification plan. Another input to the verification plan is other verification plans. So if you think about a system on a chip that is not a single piece of intellectual property, it’s built up of many, many different pieces, a USB piece, a central processing piece, a memory management piece and so on.
And each of those pieces can have their own verification plans for the verification at that sort of lower block level as well as then can sort of conglomerating or aggregating those verification plans into a single sort of system on a chip verification plan. And the vManager, V plan allows that through sort of parameterization and instantiation and really flexible set of sort of reuse capabilities for verification lands. And then of course just engineers authoring their verification plan. Literally writing, typing in here’s a specific requirement et cetera. And then we have the component of mapping those requirements to items that exist in the actual testing environment. Things like we have a test, did it pass or fail? What requirement is that test related to? So there’s mapping the test to a particular requirement and then did that test pass or fail. Those of you familiar with hardware verification know that tests passing and failing is not the only statistic or metric that we track.
There’s other metrics and statistics such as code coverage, functional coverage, assertion coverage, software coverage, all tracking what scenarios and what stimulus were driven to the specific device under test. And what was the reaction of the device under test? And then what percentage of the device has been exercised during that test? It is all basically statistics gathering from the testing effort. All that data can be mapped into the verification plan, directed to the specific requirement or multiple requirements that it may satisfy. And of course, this gives us the ability to not only specify a requirement, but then capture whether that requirement was met. Was it satisfied? And this is the place where I’ll hand over to Jeremy now to talk about what those requirements in those higher level requirements or system level requirements in the general world and how they’re going to connect into this hardware verification, hardware development world.
Like many industries, the semiconductor industry has seen a dramatic change over the past several decades. Simple, single function devices have evolved into complex multi-function devices with firmware, supporting software and, in some cases, full reference designs. While the products that the semiconductor industry sells are still integrated circuits (ICs), in many cases the supporting software, documentation and system-level understanding are just as important as the product themselves. A key example of this are the products produced for the automotive industry that must meet the Functional Safety requirements of ISO 26262.
Early in the days of integrated circuit design, companies generally focused on developing single function products. The development focus was on continuously optimizing for different applications and in many cases improving performance metrics like power, speed, and bandwidth. Later came an increased focus on reducing product size and cost. The common thinking was that if team could build a product with better performance metrics than the previous generation, there would be a market for the product. For these teams the skill of circuit design and the capabilities of manufacturing were the ultimate competitive advantage. A great deal of system-level understanding is not required, although many teams had Applications Engineers with an understanding of the various applications their products would be used for.
For many companies in the semiconductor industry, circuit design and manufacturing are still competitive advantages. For others, an increased focus on integration has encouraged them to think in terms of providing a complete solution, rather than just products. Increasing levels of integration is often driven by a goal to decrease size and cost of the solution but doing so requires a better understanding of the end application and more systems-level thinking in developing the solution. This understanding of the end application leads to a focus on clearly understanding and communicating the requirements to ensure successful product development. While in single function products the requirements are often simple and the circuit design is the challenge, in more complex products the requirements can become quite complex and truly understanding the need is just as critical as executing on developing a solution.
No aspect of integrated circuit development increased functional complexity as much as adding firmware and software to the overall solution being provided. While adding software and firmware to a solution is often done to solve a specific problem, it quickly opens up such a wide range of functional possibilities that the complexity grows rapidly. While there are still teams focused on advancing the state of the art of circuit design, just as many (maybe more) teams are developing full solutions with a semiconductor element as well as firmware, software and even system integration. The ultimate representation of this trend is semiconductor companies providing complete reference designs that contain nearly all the engineering required to produce an end-product.
In the automotive industry, the trend of providing a complete system-level solution has not been as strong as in other industries like IoT or consumer, but another trend has emerged: providing a safe solution. Integrated circuits sold into automotive applications have long had to achieve some of the toughest reliability standards. Now it is increasingly common for vehicle electronics to impact the safety of the vehicle, so not just reliability is required, but also functional safety. Achieving functional safety requires a lot more than circuit design and process technology. It requires understanding of how failures in an integrated circuit can impact the system. It requires robust development processes not traditionally employed in the semiconductor industry.
Nowhere was the need for this more strongly articulated than at the “Guidance & Application of ISO 26262 to Semiconductors” conference held virtually in August 2021. In the first session of the conference, several automotive OEMs joined forces to explain how important it is for semiconductor suppliers to develop pre-integrated, pre-certified and pre-tested solutions that meet the requirements of ISO 26262 and place the minimum burden on system integrators to integrate the solution into their system and safety case. Functional Safety adds a lot of overhead to vehicle development and receiving complete solutions from their suppliers goes a long way toward reducing that burden.
While many semiconductor suppliers have been playing catch up to meet the requirements of ISO 26262, others are turning it into a competitive advantage. These suppliers are winning business on the strength of their functional safety competency. They have developed robust processes featuring robust requirements management, configuration management and safety analysis. As a result, they can provide their customers complete safety cases that save their customers significant time when integrating their solutions. Some are even furthering the state of the art in functional safety by participating in standards development. It is common for multiple suppliers to have technically equivalent products, so in these cases safety competence can become the deciding factor in which semiconductor solution an OEM or Tier 1 supplier ultimately selects.
With the automotive industry working toward fully autonomous vehicles, the importance of developing safe products is more critical than ever. It will take the whole industry working together to furthering the state of the art in all areas to achieve the goal of full autonomy. That state of the art includes both skillful circuit design and robust process that ensure safety.
Never has there been a time where it was more critical for the semiconductor industry to adopt new skills. Circuit design and manufacturing will always be the core competency of semiconductor companies, but for those focused on the automotive industry safety, it is increasingly necessary for safety to be a core competency. Developing this as a core competency can lead to increased market share in today’s exciting automotive market.
If you haven’t already, check out Part I of our ASPICE 101 blog series to learn about what the standard is and why it’s important to automotive development. In this post, we take a look at ISO 26262 vs. ASPICE and examine the similarities and differences between these two important automotive standards.
ISO 26262 vs. ASPICE for Automotive Compliance
Of course, automotive companies already use ISO 26262, and introducing yet another automotive compliance piece into a very full process may feel overwhelming. It’s understandable why companies would be asking if they need to adhere to both ASPICE and ISO 26262 when they are already focused on ISO 26262 compliance.
The answer, in short, is that while there is no regulatory requirement to use ASPICE, using the model can greatly benefit companies that want to stay competitive in the automotive industry. According to the Project Management Institute, 47% of project failures can be traced back to poor requirements; any guidance or set of standards that can help mitigate that risk is worth the implementation effort.
While ASPICE and ISO 26262 are complementary and do overlap in places, they ultimately serve different purposes. ISO 26262 covers functional safety standards for vehicles. It incorporates safety analysis methods that account for random and systematic errors in electrical and electronic systems and is broadly adopted worldwide. ASPICE is the current standard for software best practices in the automotive industry. It covers how to conduct software and systems design whether or not safety is a concern.
The best approach for automotive development teams is to consider both ASPICE and ISO 26262 guidelines. Below we will give a brief overview of both standards and discuss the similarities and differences.
ISO 26262 Explained
ISO 26262, titled “Road vehicles – Functional safety,” is an international standard for the functional safety of electrical and electronic (E/E) systems within road vehicles. Originating from the more generic IEC 61508 standard for electrical/electronic/programmable electronic safety-related systems, ISO 26262 addresses the specific needs and challenges of automotive E/E systems safety lifecycle management. This standard aims to ensure that E/E systems in vehicles are designed and developed to meet stringent safety requirements, reducing the risk of failures that could lead to accidents and harm.
The ISO 26262 standard is structured into several parts, covering aspects such as vocabulary, management of functional safety, concept phase, product development at the system, hardware, and software levels, production, operation, service, and decommissioning. It also includes guidance on automotive safety integrity levels (ASILs), which are used to classify and manage the safety requirements necessary to mitigate risks to an acceptable level.
Key aspects of ISO 26262 include:
Risk Analysis and Management: It emphasizes the identification, evaluation, and mitigation of risks associated with E/E system failures throughout the vehicle’s lifecycle.
Systematic and Random Hardware Failures: The standard addresses both systematic failures (due to errors in specification, design, manufacture, etc.) and random hardware failures, proposing methods to manage and mitigate their effects.
Functional Safety Assessment: It requires a structured functional safety assessment to be conducted at various stages of the product development process, ensuring that all safety goals have been met.
Automotive Safety Integrity Levels (ASILs): ISO 26262 introduces ASILs, which are assigned based on the severity, exposure, and controllability of potential hazards. ASILs range from A (lowest) to D (highest), dictating the rigor of safety measures needed.
Safety Lifecycle: The standard outlines a safety lifecycle for the development of automotive E/E systems, including specific processes and tasks that must be followed to achieve functional safety.
Documentation and Evidence: Comprehensive documentation and evidence of compliance with the standard’s requirements are critical for the certification process, supporting the safety case of the E/E system.
ISO 26262 is applicable to all types of passenger cars, motorcycles, trucks, buses, and trailers, with its principles also being adapted for use in other automotive applications. The standard is continually evolving to address the advancements in automotive technologies, such as autonomous vehicles and electric mobility, ensuring it remains relevant and effective in managing functional safety in the dynamic automotive industry.
ASPICE Explained
Automotive SPICE (Software Process Improvement and Capability dEtermination) is a framework used within the automotive industry to assess and improve the maturity of software development processes. It is based on the ISO/IEC 15504 standard, often referred to as SPICE, and tailored specifically for automotive software development and related system integration processes. The framework is designed to help organizations develop high-quality automotive software more efficiently, ensuring that it meets both customer expectations and regulatory requirements.
ASPICE provides a structured approach to evaluating the capability levels of an organization’s processes in a consistent manner. It defines a set of process assessment models and practices that organizations can use to measure their processes against industry best practices. The framework focuses on key process areas such as software engineering, project management, quality assurance, and supplier management.
Key features of ASPICE include:
Process Reference Model (PRM): This model defines the processes considered essential for the development and management of automotive software. Each process is described in terms of its purpose, outcomes, and outputs.
Process Assessment Model (PAM): The PAM provides criteria for assessing the maturity levels of the processes defined in the PRM. It outlines capability levels (ranging from 0 to 5) and process attributes that are used to evaluate the performance and capability of processes.
Capability Levels: These levels describe the maturity and capability of processes within an organization. They range from Level 0 (Incomplete) to Level 5 (Optimizing), with higher levels indicating more mature and capable processes.
Assessment and Improvement: ASPICE not only enables the assessment of current process capabilities but also provides a framework for continuous process improvement. Organizations can identify gaps in their processes and implement targeted improvements to enhance their software development capabilities.
ASPICE assessments are typically conducted by certified assessors who evaluate an organization’s processes against the framework’s criteria. The outcome of an assessment can help organizations identify areas for improvement, increase the efficiency of their software development processes, and enhance the quality of their automotive software products.
By implementing ASPICE, organizations in the automotive industry can achieve several benefits, including improved process transparency, higher software quality, reduced development risks, and better alignment with industry best practices. As automotive systems become increasingly software-driven, adhering to frameworks like ASPICE is becoming more critical for manufacturers and suppliers aiming to meet the high safety, reliability, and performance standards expected in the industry.
ISO 26262 vs. ASPICE: Similarities and Differences
There are several key distinctions between ASPICE and ISO 26262:
Stay tuned for our next post in the ASPICE 101 blog series where we discuss goals, requirements, and levels of ASPICE compliance.
Editors note: This post was written partially assisted by artificial intelligence. It was reviewed for accuracy by McKenzie Jonsson and Deco Wilkerson.
If you’ve worked in product development for any time at all, you’ve probably heard the term “ISO” used in conjunction with the terms “standards” and “compliance” (along with a variety of four- and five-digit numbers).
But what does that all mean, and how does it affect you? In this article, we will provide you with a basic guide to understanding ISO standards.
What is ISO and What are ISO Standards?
The International Organization for Standardization is a nongovernmental organization. It consists of a network of standards bodies from 165 member countries (currently), with one body representing each member country. The American National Standards Institute (ANSI), for example, represents the United States. The organization maintains a central office in Geneva, Switzerland, to oversee this network.
Because “International Organization for Standardization” is a mouthful and would have different acronyms in different languages, the organization’s founders chose ISO—derived from the Greek ‘isos’, meaning equal—as its official abbreviation. As the group’s website proclaims: “Whatever the country, whatever the language, we are always ISO.”
ISO’s purpose is to help unify standards on an international basis. ISO standards are designated by the term ISO followed by a number, like ISO 9001. In some cases, ISO standards share a numeric code with an industry association, as in the case of ISO/IEC 12207. IEC stands for the International Electrotechnical Commission, which prepares and publishes international standards for electrical, electronic, and related technologies.
Nearly 800 ISO technical committees and subcommittees are tasked with standards development. As of June 2021, ISO has published some 23,886 international standards covering almost all aspects of technology and manufacturing.
What Are the Benefits of ISO Standards?
ISO forms a bridge that links the public and private sectors. Many of its member institutes are either departments of their national governments or mandated by them. Other member organizations are rooted solely in the private sector, having been set up by industry association partnerships within their country. ISO helps these diverse bodies reach consensus on solutions that meet both the requirements of business and the broader needs of society.
ISO standards help make the world a safer place and give consumers confidence that the products they buy are safe, reliable, and of high quality. Regulators and governments count on ISO standards to help develop better regulation, knowing they have a sound basis thanks to the involvement of globally recognized experts.
Finally, compliance with ISO standards gives companies an advantage in the marketplace. ISO certification provides assurance to potential customers that the company adheres to industry best practices. In many industries, companies require that their suppliers are certified to certain relevant ISO standards.
The ISO process for creating a new standard begins when an alliance of industry associations or consumer groups submits a request. ISO then recruits subject matter experts and industry stakeholders to form a technical committee or subcommittee. This committee executes a two-round drafting process and then takes a formal vote on the second draft. This second draft is called the Final Draft International Standard (FDIS). If the FDIS is approved, it is certified by the central secretariat, and ISO publishes it as an official international standard.
As technologies and best practices evolve, industry associations may request an update of an ISO standard. Different versions of the standard are distinguished by the year the revision was published appended to the standard designation. For example, the latest version of ISO 9001 is ISO 9001:2015.
What ISO Standards Are Related to Product Development?
ISO 9001
The ISO 9000 family of quality management standards is easily the most popular set of industry standards in the world. Of these, ISO 9001 is the only one to which companies can be certified.
ISO 9001 describes how to put a Quality Management System (QMS) in place to better prepare your organization to produce quality products and services. Today, over one million companies in more than 170 countries are certified to ISO 9001:2015.
ISO/IEC 12207
ISO/IEC 12207, Systems and software engineering – Software lifecycle processes aims to define all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.
First introduced in 1995, ISO/IEC 12207 establishes a common framework for software life cycle processes with well-defined terminology that can be referenced by the software industry. It defines the processes, activities, and tasks to be applied during the acquisition of software products or services, as well as during the supply, development, operation, maintenance, and disposal of software products and to the software portion of firmware, as well.
ISO/IEC 12207 also provides a process that can be employed for defining, controlling, and improving software life cycle processes.
ISO 8887
ISO 8887 specifies the requirements for the preparation, content, and structure of technical product documentation (TPD) of the design output for the cycles of manufacturing, assembling, disassembling, and end-of-life processing of products. It describes the TPD needed at the critical stages of the design process.
Beyond those requirements, the standard also identifies and describes methods and conventions appropriate to the preparation of documentation necessary to realize a design, including the application to multiple life cycles. ISO 8887 also incorporates guidance on the ultimate reusing, recovering, recycling, and disposing of the components and materials used.
ISO/TS 16949
Based on ISO 9001, ISO/TS 16949 is a technical specification (TS) aimed at the development of a quality management system that provides for continual improvement within the automotive industry. First published in 1999, it emphasizes defect prevention and the reduction of variation and waste in the automotive industry supply chain and the assembly process.
According to the British Standards Institution (BSI), the ISO/TS 16949 standard was created by the International Automotive Task Force (IATF) to help streamline this process. It focuses on the avoidance of errors and defines the requirements for the development, production, and installation of automotive-related products. Today, certification is required by almost all Tier 1 companies, many of whom require their Tier 2 and Tier 3 suppliers to certify. As a result, over 50,000 certifications have been issued to date against this standard.
ISO 26262
ISO 26262, Road vehicles – Functional safety applies to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars. Introduced in 2011, this standard addresses possible hazards caused by malfunctioning behavior of E/E safety-related systems, including the interaction of these systems.
With the increased number and interaction of electronic systems within passenger vehicles, this standard is being adopted rapidly within the automotive industry.
ISO 13485
Unlike many ISO standards, ISO 13485, Medical Device Quality Standards, is a single document and does not belong to a family. It was originally published in 2003 and revised in 2016.
ISO 13485 puts a quality management system in place for the production of medical devices and equipment and is very specific to the health industry. It is often implemented with ISO 9001 to show that an organization is qualified to do business in the medical device field.
ISO 13485 is a regulated standard against which over 25,000 certifications have already been issued.
Product developers sometimes ask, “What are the differences between standards and requirements?”
According to Merriam-Webster, a requirement is “something wanted or needed; a necessity” or “something essential to the existence or occurrence of something else.” Other definitions include “a necessity or prerequisite” and “something required or obligatory.”
Webster’s defines a standard as “something set up and established by authority as a rule for the measure of quantity, weight, extent, value, or quality” or “something established by authority, custom, or general consent as a model or example.” In other words, a standard is a principle, example, or measure used for comparison—a benchmark used to evaluate suitability for a purpose.
To meet a requirement, a thing, person or organization must do exactly what the requirement says. To meet a standard, a thing, person or organization must meet the minimum requirements of the standard and align with its intent. Standards typically allow some leeway for tailoring to individual organizational practices and obligations.
As mentioned earlier, many corporate and governmental customers want their suppliers to adhere to certain ISO standards, especially in industries that are multi-tiered or highly regulated. Certification to applicable standards is often a contractual requirement within those industries.
Is ISO Compliance Required by Law?
The ISO standards themselves are not legally binding. There are no laws that compel companies to meet or be certified to any ISO standards.
However, national regulators may refer to ISO standards as examples of good practice. For example, a building regulation might say you must comply with certain local regulations and that one way of complying with those is to comply with a given ISO standard.
Also, while not legally bound, many companies find certification to certain ISO standards is a necessity if they wish to compete for contracts within their industry or with specific customers.
In this guide, we’ve talked frequently about ISO compliance and ISO certification. So, what’s the difference?
Compliance simply means that your product or process conforms to the requirements of the ISO standard. ISO certification, on the other hand, is the result of a formal procedure and thus a bit more complicated.
ISO itself does certify companies directly. Instead, specific certification bodies perform the task of auditing and then certifying an organization’s compliance with a given ISO standard. These bodies, often known as registrars, must themselves be certified under a separate standard, ISO/IEC TS 17021.
During the certification process, the registrar audits the organization to ensure that its operations are in compliance with processes outlined in the current ISO standard. Where inconsistencies or “non-conformities” are found, the organization must typically create a program for correcting these problems before the registrar will issue a certificate.
Once an organization is granted certification, it receives a certification mark that can be used on its company stationery, websites, etc.
When it comes to ISO standards governing ongoing business practices, like ISO 9001 for example, approval is typically valid for a period of three years. After that, the company must recertify to the current form of the standard.
Applying ISO Standards in Lifecycle and Requirements Management
What tools can help meet ISO standards in the realm of product lifecycle management? Jama Software provides several.
First and foremost of these is our flagship product, Jama Connect. For example, let’s say your organization is seeking certification to ISO 9001. To achieve that certification, you need to demonstrate you have put in place a defined, repeatable process for assuring quality. Jama Connect is a tool built specifically for requirements management and requirements traceability. Not only does Jama Connect simplify the tracking and tracing of requirements, it also makes it simpler and easier to maintain and demonstrate a robust quality process. That’s because Jama Connect automates so much of your requirements management process.
Finally, to learn more about choosing the right requirements management tools to help your company attain or maintain ISO certification, download our Requirements Management Buyer’s Guide.
This post on functional safety for autonomous driving is Part III in our three-part series with automotive expert Patrick Freytag. If you haven’t already, please go back and read Part I, which talks about how the automotive sector is changing – and Part II, which discusses ways to address functional safety.
Since functional safety has a product lifecycle approach, it has a wide impact on all processes in a company. As a newcomer to functional safety, it’s challenging to focus on the most important aspects, especially for new entrants in the knowledge-intensive automotive sector. Here are best practices based on my observations and experience.
Functional Safety for Autonomous Driving – Best Practices for New Market Entrants
Executive Management Team: Pay Attention to Functional Safety
Product safety should be at topic of conversation for the Executive Management Team (EMT) because of the legal responsibilities placed upon the company by deploying a vehicle to customers. The EMT should understand that it needs dedicated resources to achieve product safety. One of the most important tasks of the EMT is to implement a Safety Engineering Management and to assure that roles and responsibilities for quality and safety are defined and communicated in the company. Members of the safety team need a specific skill set, so it is important to invest in functional safety education and qualification. It is important to foster a quality and safety culture in the company. For that reason, quality and safety should be part of goal agreement and performance evaluation. Quality and safety have to be recognized as a core responsibility and a performance indicator for employees.
Project Management: Plan and Track Functional Safety
Project management has to incorporate functional safety in the product concept and development plan. The Project Manager (PM) should consider the additional time and cost in the project plan and the project budget. Product development plans must include quality and safety milestones and the related work products. What should be done if the PM doesn’t receive proof that quality and safety milestones are reached at the gate reviews, for example? Well, that’s for sure a red flag. Situations like these may point to deeper rooted issues, and should not be brushed under the rug. The PM should start a GAP analysis and request an action plan. I recommend escalating the issue to the executive team ASAP in case there is missing proof of product safety. It won’t get better without commitment and planned actions, the longer you wait the worse the situation will get. Since safety considerations most typically permeate several layers of system design, it is not an attribute that can be tagged on shortly before the start of production, it has to be implemented from the beginning.
Development & Functional Safety Team: Implement and Validate Functional Safety
Industry experience shows that functional safety is not a topic you can assign to one responsible person. For example, a technical safety concept is created by a team of software, hardware, and system-level experts and moderated by a systems architect in collaboration with functional safety engineers. This means that the functional safety manager is a role that is played a few times in a company, while the role of a safety engineer can be assigned to even an entire team. As mentioned, functional safety requires specific domain knowledge and safety engineering expertise. But what can be done if this expertise is missing in-house? My recommendation is to compensate it with external resources as an interim solution. Start functional safety education and qualification as a long-term solution. Safety must be addressed in product development with adequate engineering methods and domain knowledge to define safety requirements. These safety requirements have to be implemented, tracked, managed, verified, and validated to make sure that risk reduction is realized, and the product is safe.
The Evolution of Functional Safety for Autonomous Driving
The functional safety focus is on avoiding and mitigating failures in E/E systems. That also works well for Advanced Driver Assistance Systems (ADAS). When a failure is detected, the driver gets alerted, and mitigation measures are performed to reach a safe state. These systems are called fail-safe. Let’s take Adaptive Cruise Control (ACC) as an example. When a failure is detected, a warning will be displayed in the Instrument Cluster. This visual warning is typically combined with an acoustical warning to get the attention of the driver. The ACC function will be switched off, and the driver is in charge to control the vehicle’s speed and keep a safe distance again.
Additional Safety Considerations for Autonomous Driving
The ADAS safety mechanism described above will not be sufficient for a fully autonomous vehicle. It’s not possible to switch off the automated driving system because there is no driver in the loop to take over. An Autonomous Vehicle (AV) has to work under all (failure) conditions, it has to be fail-operational. An AV without a driver in the loop also needs situational awareness, understand the surrounding world, decide, and act. This situational awareness is created by data fusion from a variety of complex sensor systems based on lidars, cameras, and radars. The combined data is then interpreted to plan and take action. This interpretation and planning are achieved by complex algorithms, driven by Artificial Intelligence (AI) and Machine Learning (ML).
Today, many connected and ADAS-equipped cars are already available. Connectivity features and information sharing are increasingly used for updating vehicle features, maintenance-related diagnostics, and traffic services. This development will also increase the attractiveness of an attack on vehicles by hackers with different motivations and it introduces additional risks for vehicle cybersecurity.
Safety Concerns Due to System Limitations and Misuse
What happens if an automated driving system has no system failure but doesn’t work as intended? Unsafe behavior could be triggered by limitations in the sensor systems, extreme conditions, or unforeseen situations. In addition, misuse could confuse the AI algorithms and result in unsafe behavior too.
An example of misuse of an ADAS was showed by Consumer Reports. Consumer Reports reported in April 2021 that it was able to trick a Tesla into driving in autopilot mode with no one at the wheel. Real-life proof followed in May – Police arrested Tesla driver for operating his car from the back seat while traveling on a San Francisco Bay Area freeway. The officer confirmed the sole occupant was in the backseat, so he took action to stop the car and saw the occupant move to the driver’s seat before the car stopped. In response, Tesla activated the cabin camera with a software update to detect and alert driver inattentiveness while autopilot is engaged for Model 3 and Model Y end of May.
Here a typical example of limitations, an AV is driving and confronted with black ice conditions. While an experienced driver should be able to comprehend the situation and respond properly, an AI-based AV might not. Without sensing the icy road condition, an AV might drive faster than is safe for the condition.
As a result, there has to be an addition to functional safety considering safety violations that occur in absence of a system failure.
Safety of Intended Functionality or SOTIF (ISO/PAS 21448)
The publicly available specification ISO/PAS 21448, titled “Road vehicles — Safety of the intended functionality” was published in 2019. SOTIF is defined in the standard as: “The absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons.” The goal of SOTIF is to avoid situations where vehicles are working as designed, but are failing under real-world scenarios. ISO 21448 provides guidance on the design, verification, and validation measures to achieve the SOTIF. The current version covers Advanced Driver Assistance Systems (SAE J3016 L1 and L2). It can be considered for higher levels of automation; however, additional measures will be necessary.
The Standard for the Evaluation of Autonomous Products (ANSI/UL 4600)
The UL 4600 standard was issued in April 2020 with the scope of the Safety Evaluation of fully Autonomous Driving Systems that operate without human intervention. The goal of UL 4600 is to ensure that a comprehensive safety case is created, including safety goals, argumentation, and evidence. UL 4600 covers the safety principles, risk mitigation, tools, techniques, and life-cycle processes for building and evaluating a safety argument for vehicles that can operate in an autonomous mode without human supervision. Therefore, the ML-based system aspects of the autonomous operation are covered. UL 4600 works well with existing automotive safety standards such as ISO 26262 and ISO/PAS 21448 by building on their strengths while also filling their autonomy-specific gaps.
Conclusion
The safety challenge for autonomous vehicles can’t be addressed with a single standard as of today. As we move on from existing Advanced Driver Assistance (L1 and L2+) to fully Automated Driving Systems (L5) the standards and methods will evolve too.
Current state-of-the-art automotive safety is achieved with a combination of different engineering methods and processes:
Functional Safety (ISO 26262)
Guards the E/E malfunction behavior due to systematic and random hardware failures for vehicles with a human driver present responsible for safe operation
Safety of the Intended Functionality (ISO/PAS 21448)
Deals with the functional limitation regarding the absence of unreasonable risk due to hazards resulting from functional insufficiency of the intended functionality or reasonably foreseeable misuse by persons. SOTIF covers L1 & L2 ADAS vehicles with a human driver present responsible for safe operation.
Cybersecurity engineering (ISO/SAE 21434)
Protects road vehicle systems and components from harmful attacks, unauthorized access, damage, or anything else that could interfere and compromise safety functions
Evaluation of Autonomous Products (ANSI/UL4600)
Proofs the safety of fully autonomous road vehicles that can operate without human supervision
Take Away:The combination of different engineering methods is needed on the way to fully Autonomous Driving
Functional Safety helps you to do things right
Safety of Intended Functionality helps you to do the right things
Cybersecurity helps to protect the safety functions from being compromised
Evaluation of Autonomous Products helps you to provide proof that you did enough safety engineering work to achieve a safe autonomous product
This blog post concludes the 3-blog miniseries on automotive insights and best practices on the way to autonomous driving. Special thanks to Jama Software for the opportunity to share my observations and experience with you. I hope you enjoyed reading my thoughts and got useful insights into the complex and interesting world of automotive safety and autonomous driving.
My last blog post covered why and how the automotive sector is changing fast over the last few years – you can find that post here. A common expectation is that our future cars will be connected, automated, shared, and electric. In a current Motional Consumer Mobility report, Americans were asked what is their most important consideration to use a self-driving vehicle. Nearly two-thirds of Americans (65 percent) say safety is the most important consideration when deciding to use a self-driving vehicle. So let’s take a closer look at automotive functional safety and how to deliver a safe product.
Safety Considerations for Product Design
Modern cars are a complex piece of technology. They are connected, have sophisticated Infotainment Systems (IVI) and Advanced Driver Assistance Systems (ADAS). You will be surprised about the amount of software used in the 30 to 70 electronic control units in a car. There are up to 100 million lines of code deployed in a modern high-end car today. System complexity will increase even more when we move beyond ADAS-supported driving to Automated Driving Systems (ADSs) in the future.
The challenge for the industry is that new potential hazards may arise with the increasing use of electronics and software in cars. Apart from complex technology and consumers’ expectations, we will get regulations covering the safety of future cars. In the U.S., this is the responsibility of the National Highway Traffic Safety Administration (NHTSA).
Defined by the Vehicle Safety Act in 1966, the NHTSA has the sole authority to make final decisions on rules and safety standards for future road vehicles. Once the NHTSA establishes a standard, the Agency is required to ensure that manufacturers comply when producing new vehicles.
In 2016 the NHTSA published “Vision for Safety,” a non-regulatory approach to automated vehicle technology safety. “Entities are encouraged to follow a robust design and validation process based on a systems-engineering approach to design ADSs free of unreasonable safety risks. The overall process should adopt and follow industry standards, such as the functional safety process standard for road vehicles…”
Which industry standard is the NHTSA referring to?
The mentioned standard is the ISO 26262 standard. First issued by International Organization for Standardization (ISO) in 2011 and later updated in 2018. The ISO 26262 is titled “Road vehicles – functional safety,” the first comprehensive voluntary industry standard for safety engineering of Electrical and Electronic Systems (E/E) in road vehicles. This standard recognizes that safety is a system attribute and can be addressed using systems engineering methods. ISO 26262 emphasizes the importance of implementing a safety engineering management and fostering a safety culture.
What is functional safety and how to comply?
Functional safety is defined as the “absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic systems.” The goal of ISO 26262 is to ensure safety from the earliest concept to the point when the vehicle is retired. To ensure vehicle safety, the standard outlines an automotive safety life cycle that describes the entire production life cycle.
Specific steps are required in each phase of the safety life cycle. One of the most important steps at the beginning of the safety life cycle is the Hazard & Risk Analysis of potential hazards (HARA). The result is an Automotive Safety Integrity Level (ASIL) classification of the hazard and the formulation of an overall safety goal. Safety goals are basically the level of safety required by a system or component to function without posing any threats to the vehicle.
An ASIL is assigned by evaluating three risk parameters, severity, exposure, and controllability. Severity defines the consequences to the life of people due to the failure that may occur.Exposure is the likelihood of the conditions under which a particular failure would result in a safety hazard.Controllability determines the extent to which the driver will be able to control the vehicle should a safety goal be breached due to the failure or malfunctioning. An ISO 26262 method provides guidance on how to assign the ASIL for a hazard once severity, exposure, and controllability are determined.
In the next step, a functional safety concept is developed for each safety goal. The functional safety concept defines functional safety requirements within the context of the vehicle architecture, including fault detection and failure mitigation mechanisms, to satisfy the safety goals. Then the technical safety concept is developed to specify the technical safety requirements within the system architecture. The technical safety concept is the basis for deriving the hardware and software safety requirements that are used for developing the product. These safety requirements have to be traced, managed and validated through product development to assure the delivery of a safe product.
Functional Safety describes a risk-based system engineering approach to avoid unreasonable risk. From a business aspect, using ISO 26262 as a guideline helps you to avoid costly product recalls due to safety hazards. Tesla recalled roughly 135,000 Model S and Model X vehicles over Touch-Screen failures in February 2021. The move came after the National Highway Traffic Safety Administration requested a safety recall. NHTSA asked for the recall because the center display in some models can fail when a memory chip runs out of storage capacity, affecting safety functions such as windshield defogging and defrosting controls, exterior turn signal lighting, and rearview backup camera display.
Following the standard minimizes the risk of harm to people and non-acceptance of your products by the market. In particular, automobile manufacturers have a legal responsibility to design their vehicles to guarantee driver, passenger, and pedestrian safety. As a consequence, automobile manufacturers can be named as defendants in a product liability suit. For example, Toyota Motors agreed to pay $1.2 billion to settle the Justice Department’s criminal investigation into whether the company hid safety defects related to unintended acceleration in 2014.
Takeaway
Functional safety is an essential part of product development and needs to be addressed early in the concept phase and considered through the full product life-cycle. ISO 26262 offers an engineering guideline and methods to avoid or at least mitigate systematic failures and random hardware failures of Electrical and Electronic Systems. The derived functional safety requirements have to be implemented at the lowest level up to the system level, both from a hardware and software perspective. This offers the ability to prove that the added E/E-systems are free of unreasonable safety risks.
The pragmatic engineering approach is to use existing knowledge, or how I call it, to use the industry’s memory. You should look at the ISO 26262 series as the framework, and set of guidelines and methods. ISO 26262 can help you with system engineering methods for a safe product and still give you some flexibility in the development process. This is especially helpful for newcomers to the automotive industry, who may lack specific automotive safety engineering experience.
Let’s put it that way, using existing engineering methods and knowledge is like standing on the shoulders of a giant – you can see further. This is even more true for automotive product safety because there is no room for trial and error.
Stay tuned: The next blog post in this series will give real-life advice on how to implement functional safety in your organization and products, and a glance at the evolution of functional safety for autonomous driving.
2020 has been a year that’s been described as “unprecedented” and “unparalleled” – as well as other descriptors probably best left out of our blog. As we close out this year, it’s hard to say what awaits us in the new one. One thing that we can be sure of is that innovation in medicine, science, and technology shows no sign of slowing down.
As we enter a new year of technological advancements, Jama Software asked select thought leaders – both internal and external – across various industries for the trends and events they foresee unfolding over the next year and beyond.
In Part III of our four-part series, we asked Adrian Rolufs, Director of Solutions Architecture at Jama Software, to weigh in on trends he sees in automotive development for 2021. You can also go back and read Part I and Part II and Part IV of our 2021 predictions series, which focus on predictions for medical device development and airborne systems development (respectively).
Note: Now that our 2021 Predictions Series is complete, you can also go back and read Part I, Part II, and Part IV.
What product, systems, and software development trends are you expecting to take shape in 2021?
Adrian Rolufs:
I expect to see a continuation of the existing trend of more and more companies taking functional safety seriously. Fewer companies will be trying to do the bare minimum for safety and instead will be focused on establishing the robust engineering methods that are encouraged or required for functional safety.
In terms of product and systems development, what do you think will remain the same over the next decade? What will change?
Adrian Rolufs:
I expect to see an increase in focus on systems engineering. Today many components are still developed by electrical engineering and software engineering teams working in loose coordination. Increasing complexity is going to force an increasing reliance on systems engineering to coordinate between the traditional disciplines and architect optimized solutions.
How do you foresee regulations shifting in automotive development over the next decade?
Adrian Rolufs:
I expect to see more and more government imposed regulation similar to the medical device and airborne systems industries. So far, government regulations for automotive development have been largely focused on physical properties of the final vehicle. I expect to see this move into requiring more rigorous documentation around design processes. We are already starting to see some activity by the National Highway Traffic Safety Administration (NHTSA) in this regard.
Any major disruptions to automotive industry you’re anticipating in 2021?
Adrian Rolufs:
I expect that 2021 will continue to decide winners and losers among the elective vehicle and autonomous vehicle startups. Some of the players are inevitably not going to survive. I believe that the companies who are able to show compelling enough products to move past frantically trying to build a working prototype into establishing robust engineering machines will be the companies to survive in 2021.
What sorts of process adjustments do you think development teams will need to make to be successful in 2021?
Adrian Rolufs:
Established automotive development teams are going to have to rethink how they work to become more Agile and innovative. The startups are poised to become very disruptive in 2021 and traditional automotive organizations will not survive if they aren’t able to adapt. Traditional automotive OEMs are very good at heavily reusing components they have and slowly evolving their vehicle designs. That won’t be good enough for the 2020s. I envision some repeats of how Nokia went from being the untouchable and dominant cell phone manufacturer in the 2000s to virtually nonexistent in the 2010s.
What do you think will be some of the differentiators between a company surviving to see 2030, and those that do not?
Adrian Rolufs:
Companies that survive to 2030 will find the right balance between innovative new technology like AV, EV, and connected cars and robust engineering methodologies that allow the development of reliable, safe, and high quality automobiles.
Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2021 approaches?
Adrian Rolufs:
As all automotive companies strike the balance between developing innovative products and following robust engineering methods, many engineers who have never before been engaged in requirements engineering will have to learn how. Those engineers want a tool that is modern, easy to use, and powerful enough to meet the requirements of ISO 26262, Automotive SPICE, and future regulations that don’t exist yet. Jama Connect is the best solution for getting those engineers authoring and reviewing requirements in a system that enables traceability.
Stay tuned for the final segment in our 2021 Predictions Series. In the meantime, to see more information specific to the automotive development industry, we’ve compiled a handy list of valuable resources for you!
Best Practices for Evaluating Product Development Tools for ISO 26262 Compliance
Vehicles have always been complex machines to build, but connectivity is adding a new dimension to the challenges—especially when it comes to ISO 26262 compliance in modern automotive product development.
Whether it’s a smart dashboard or driving assistance technology, there’s a significant increase in the amount of software and electronics implemented in cars, trucks, vans and beyond. And that’s before even mentioning the future of autonomous vehicles.
These exciting changes are driven by consumer demand, which is leading to intense global competition around developing and releasing cutting-edge features and technology as quickly as possible.
As a result, development teams feel intense pressure from having to adapt to these changing market realities. That includes using new development methods to tackle the significant risks that must be accounted for in the design and validation and verification process with safety standards such as ISO 26262.
Modernizing Safety
In this new, accelerated market, relying on chaotic document software and outdated legacy tools will only leave your team further behind and even potentially increase the likelihood of disaster.
When it comes to ISO 26262 — the international standard for the functional safety of electronics systems in production automobiles — using yesterday’s development processes not only slows you down but leaves your company open to catastrophic risks.
This is why a modern product development platform is so important. If you’re creating a certified ISO 26262 process, you need to trust that it’s been certified as “fit for purpose” in the design and development of safety-critical products. Otherwise, you’re potentially using a buggy platform that could inadvertently lead to a product malfunction disaster, resulting in injuries or fatalities, which plunges your company into deep litigation and potential bankruptcy.
Automotive OEMs and suppliers must be able to trust that the workflows they’re using to identify, build, and test products in a development platform meet critical functional safety requirements.
The process you use to gain assurances that a product development platform will allow you to build compliant automotive equipment varies, but at a minimum, you should be looking for some distinct criteria.
For starters, confidence in the platform should be measured. That can be done by sizing up the platform against your current development process, as well as the validation measures and success stories of the tool itself.
Next, you’ll want to look at given scenarios if something goes wrong with the platform. For instance, if there’s some sort of systemic error within the platform, you’ll want to make sure all its customers would be informed immediately so it doesn’t impact a system that’s already under development.
Whichever product development platform you’re considering, you should also ensure its safety manual guides users on how to apply the tool for the development of safety-relevant systems. That includes some instructions on critical use case scenarios and specific safety measures.
Discovering the Right Fit
By evaluating a product development platform in this way, it’ll be more helpful when it comes time to be audited for safety standards such as ISO 26262.
During audits, often times the key focuses are within the areas of project management and quality management. A platform that provides features where you can prove that you have full traceability from requirements through testing will go a long way.
Every company will follow a different path when it comes to proving compliance and validation. One thing you don’t want to do is get caught flat-footed in such a turbulent and competitive time. That’s why upgrading your development process with a solid platform can make all the difference.
For a deeper dive into how teams creating products for any safety-critical industry can lower the costs and risks of complying with functional safety standards, check out the webinar, “Jama ISO 26262 Certification & Best Practices for Development.”
To see more information specific to the automotive industry, we’ve compiled a handy list of valuable resources for you!
Editor’s Note: This post on the difference between being ISO 26262 compliant and ISO 26262 certified was originally published here from LHP Engineering Solutions on July 16th, 2020, and was written by Steve Naheem, the leader of strategy an solutions architects at LHP.
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.
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.
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.
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.
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 learn more about how Jama Connect for Automotive can help your team simplify compliance, streamline development, and speed time to market, download our solution overview.
asd
If you haven’t already, check out 
If you’ve worked in product development for any time at all, you’ve probably heard the term “ISO” used in conjunction with the terms “standards” and “compliance” (along with a variety of four- and five-digit numbers).
My last blog post covered why and how the automotive sector is changing fast over the last few years – 
Editor’s Note: This post on the difference between being ISO 26262 compliant and ISO 26262 certified was originally published