Tag Archive for: ASPICE

What is ASPICE?

When personal computers first came into common use in the 1980s, the closest a microchip came to an automobile was during transit to its final destination.

Few consumers could have predicted there would come a time when their automobiles would be controlled by computer chips, much less have integrated technologies to manage everything from cell phone calls to satellite radio to entertainment features, GPS mapping, and even drive controls.

The automobile of the 2020s hasn’t just transcended crank starters and wood paneling; today’s automobiles integrate multiple technologies developed by teams across industries all over the globe. The automobile market has evolved to include everything from self- or assisted-driving technology, automated safety features, and various green technologies, including electric and hybrid options.

These marketing forces are creating the following challenges:

  • Surge in connected cars
  • Autonomous vehicles (AV) disrupt regulations
  • Push to electrification of vehicles (EVs) balanced with high technology cost
  • Increased mobility services
  • Product quality that meets safety-critical standards
RELATED: Jama Connect® for Automotive Solution

With all of these new market demands, it’s not uncommon for automobiles to require over 100 million lines of code. By 2030, a late model auto could require as many as 300 million lines of code. Connected cars can process 25 gigabytes of data per hour and generate over 4 terabytes of data per day.

All of this data means that today’s cars can fall prey to software malfunctions, connection interference, or even hacking. And because lives are in the balance, development teams have more incentive—and responsibility—than ever to get it right from beginning to end.

In this complex world of modern automotive development, many companies are adopting the ASPICE standard for software development to meet these new automotive safety challenges.ASPICE

What is Automotive SPICE (ASPICE)?

ASPICE started as a variation of the ISO/IEC 15504, or SPICE, standard. SPICE stands for “Software Process Improvement and Capability determination.” The SPICE standard began as a way to provide a framework for independent assessors to evaluate an organization’s capability for software development.

As other teams and manufacturers looked for software suppliers, this SPICE score could serve as one way to evaluate whether the developer can meet certain standards for performance, safety, and quality. Though the SPICE standard didn’t gain much traction in other development fields, it did start to take hold in automotive as German auto manufacturers began using it.

As the standard became focused more toward automotive, the moniker “Automotive SPICE” or “ASPICE” took hold. As it stands now, ASPICE is a process assessment model and a process reference model for software development in the automotive industry. Software teams who design and develop software for the automotive industry should use ASPICE to document processes and measure the maturity of the organization’s processes.

The SPICE standard began as a way to provide a framework for independent assessors to evaluate an organization’s capability for software development.

Fundamentally, the goal of ASPICE is to define best practices for development of embedded software for vehicles.

Given that a modern vehicle can involve hundreds of millions of lines of code, creating some objective “best practices” can only benefit the teams working on this code. And it’s not just how much code is required that adds complexity — it’s also the fact that companies increasingly work across geographic and industry boundaries. When looking for suppliers, having some objective standards of assessment can be useful.

ASPICE is based on the V-Model — a model that requires logical decomposition of requirements and rigorous evaluation through testing at each stage of development. This model benefits both suppliers and system integrators by giving opportunity to eliminate problems in early development stages and providing a framework for ideation and development.

ASPICE V-ModelIt also ensures continuous innovation and product development. On the left side of the V-Model are initial phases of product development.

  • Requirement Analysis: Discovering, listing, and prioritizing client requirements
  • System Design: Mapping client needs and putting them into a viable work model
  • Architecture Design: Organizing requirements into logical operations
  • Module Design: Creating software requirements that match system requirements and developing service units
  • Coding: Designing and implementing units; this is the point of the V

On the right side of the V-Model are the secondary phases of product development:

  • Unit Testing: Determining if code and design match and standards and requirements are met
  • Integration Testing: Evaluating software architecture and service units
  • System Testing: Integrating everything into the full system and testing
  • Acceptance Testing: Performing final tests

The advantage of the V-model is that it promotes testing and improvement throughout the development cycle. For each point along the V, there is a corresponding testing phase and additional traceability and management processes. Suppliers who follow this ASPICE model can earn certifications according to standardized achievement phases; the ASPICE standard is scored in levels from zero to five, which clients can use to evaluate the proficiency of the development team.

ASPICE levels are as follows:

LEVEL 0 | Basic

Teams at Level 0 are still developing processes or systems. They can, at most, “partially” achieve ASPICE requirements. These teams should focus most of their efforts on managing basic tasks.

LEVEL 1 | Performed

Teams achieving Level 1 either nearly or completely deliver standard ASPICE requirements, but likely have gaps in their processes.

LEVEL 2 | Managed

Level 2 teams can reliably deliver work products and almost or completely achieve ASPICE standards.

LEVEL 3 | Established

At Level 3, teams have established and set performance standards and are engaged in continuous improvement to constantly evaluate and learn.

LEVEL 4 | Predictable

Level 4 teams measure, record, and analyze outcomes; evaluate outcomes and processes objectively; and consistently meet performance standards.

LEVEL 5 | Innovating

Level 5 teams have reached a stage where they are not only consistently delivering high performance and quality products, but also engaging and investing in continuous improvement. These teams also analyze performance standards for quantitative feedback and causal analysis resolution.

ASPICE does not prescribe tools or techniques for teams, but rather gives a framework for examining the approach to internal development methods. The ASPICE standard is mostly generic and largely tool and process “agnostic” — that is, it gives a framework for evaluating the process and outcomes, but does not dictate the best processes or methods for every team. Because every team is different, this generic approach can help bring order and improvement to any team operating in any automotive system or space.

ASPICE levels look daunting, and for a start-up or young team, the idea of achieving Level 5 might seem out of the question. However, it’s important to note that Levels 4 and 5 are aspirational; most teams that achieve these levels are part of very large corporations. Level 2 is a more realistic initial target, and by the time teams are at Level 3, they are functioning at a standard broadly considered “excellent.”

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

How ASPICE Affects Automotive Development

The world of automotive development is only becoming more complex.

Some factors that are increasing complexity:

Consumer demand: A connected world means that consumers want seamless connectivity across their entire lives. The lines between work, home, and leisure are increasingly blurry, and consumers who still need vehicles to get from point A to point B will want all of those pieces of their lives to be integrated — even behind the wheel.

Increasing regulation: With the increasing complexity of auto systems and a focus on reducing climate impact, auto manufacturers will have to comply with new and possibly shifting regulations across different entities.

Rapid innovation: Technology continues to change and innovate at a breakneck pace. With systems increasingly integrated into automobiles, manufacturers will have no choice but to keep up with innovation. In fact, as of 2019, 80% of product innovation in automotive comes through software development

Fortunately, ASPICE can help auto suppliers and original equipment manufacturers (OEMs) respond to this increasing complexity in multiple ways:

Control the process: ASPICE gives teams clear guidance for evaluating and controlling their development processes, which can help ensure product quality, shorten time to market, and reduce costs.

Streamline supplier selection: By clearly defining levels of achievement, ASPICE can help OEMs assess and evaluate suppliers. If suppliers achieve Level 2 or 3 in ASPICE, OEMs can be fairly certain they are getting quality products.

Reduce costs and improve time to market: Because ASPICE is more concerned with process than with specific regulations or safety guidelines, using the standard can help teams reduce costs and improve efficiency, thereby improving overall market competitiveness.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Automotive

How to Ensure Compliance with ASPICE

Most automotive developers are rigorously working towards ASPICE compliance and there are many advantages to aiming for it.

1.) It’s possible that compliance will be required some time in the future, so working toward it now is a positive step in preparation.

2.) Automotive development is only getting more complicated, not less, and development will continue to require teamwork across industries, companies, and geographies. Working within the ASPICE standard will help ensure consistency.

3.) Working within ASPICE will give teams a competitive edge over other suppliers and OEMs who are not yet using the standard.

But knowing that compliance is desired and actually achieving it are two different things. How can teams ensure compliance with the ASPICE standard?

Start with an honest assessment.

Teams can’t know where to go until they know where they are. A good place to start is to draft current processes and compare them to the ASPICE V-model. This effort can provide good insights into current levels compliance and where improvements can be made.

Confront the gaps and missing pieces.

Most teams will have some gaps in their processes or procedures. Likewise, some teams will have unclear separation between steps in the V-Model. Look at the gaps and assess how to close them, and identify where additional steps should be introduced.

Include stakeholders.

Be sure that all stakeholders have complete visibility into the ASPICE compliance efforts, and clearly define the resources those stakeholders can provide where necessary.

Test every phase.

Testing is vital to ASPICE compliance. Be sure to include rigorous testing at every phase in the process.

Operate under the new guidelines.

Once the plan is in place, implement it immediately.

Reassess and improve.

After completing a new product under the new ASPICE compliant processes, reassess, evaluate, and look for ways to improve. This constant focus on improvement is what allows teams to achieve higher levels of ASPICE compliance.

ASPICE

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, and Part II, where we examine the similarities and differences between ISO 26262 and ASPICE. In this post, we take a look at the goals of ASPICE and the different compliance levels.

Fundamentally, the goal of ASPICE is to define best practices for development of embedded software for vehicles.

Given that a modern vehicle can involve hundreds of millions of lines of code, creating some objective “best practices” can only benefit the teams working on this code. And it’s not just how much code is required that adds complexity — it’s also the fact that companies increasingly work across geographic and industry boundaries. When looking for suppliers, having some objective standards of assessment can be useful.

ASPICE is based on the V-Model — a model that requires logical decomposition of requirements and rigorous evaluation through testing at each stage of development. This model benefits both suppliers and system integrators by giving opportunity to eliminate problems in early development stages and providing a framework for ideation and development.

ASPICE V-ModelIt also ensures continuous innovation and product development. On the left side of the V-Model are initial phases of product development.

  • Requirement Analysis: Discovering, listing, and prioritizing client requirements
  • System Design: Mapping client needs and putting them into a viable work model
  • Architecture Design: Organizing requirements into logical operations
  • Module Design: Creating software requirements that match system requirements and developing service units
  • Coding: Designing and implementing units; this is the point of the V

On the right side of the V-Model are the secondary phases of product development:

  • Unit Testing: Determining if code and design match and standards and requirements are met
  • Integration Testing: Evaluating software architecture and service units
  • System Testing: Integrating everything into the full system and testing
  • Acceptance Testing: Performing final tests

The advantage of the V-model is that it promotes testing and improvement throughout the development cycle. For each point along the V, there is a corresponding testing phase and additional traceability and management processes. Suppliers who follow this ASPICE model can earn certifications according to standardized achievement phases; the ASPICE standard is scored in levels from zero to five, which clients can use to evaluate the proficiency of the development team.

ASPICE levels are as follows:

LEVEL 0 | Basic

Teams at Level 0 are still developing processes or systems. They can, at most, “partially” achieve ASPICE requirements. These teams should focus most of their efforts on managing basic tasks.

LEVEL 1 | Performed

Teams achieving Level 1 either nearly or completely deliver standard ASPICE requirements, but likely have gaps in their processes.

LEVEL 2 | Managed

Level 2 teams can reliably deliver work products and almost or completely achieve ASPICE standards.

LEVEL 3 | Established

At Level 3, teams have established and set performance standards and are engaged in continuous improvement to constantly evaluate and learn.

LEVEL 4 | Predictable

Level 4 teams measure, record, and analyze outcomes; evaluate outcomes and processes objectively; and consistently meet performance standards.

LEVEL 5 | Innovating

Level 5 teams have reached a stage where they are not only consistently delivering high performance and quality products, but also engaging and investing in continuous improvement. These teams also analyze performance standards for quantitative feedback and causal analysis resolution.

ASPICE does not prescribe tools or techniques for teams, but rather gives a framework for examining the approach to internal development methods. The ASPICE standard is mostly generic and largely tool and process “agnostic” — that is, it gives a framework for evaluating the process and outcomes, but does not dictate the best processes or methods for every team. Because every team is different, this generic approach can help bring order and improvement to any team operating in any automotive system or space.

ASPICE levels look daunting, and for a start-up or young team, the idea of achieving Level 5 might seem out of the question. However, it’s important to note that Levels 4 and 5 are aspirational; most teams that achieve these levels are part of very large corporations. Level 2 is a more realistic initial target, and by the time teams are at Level 3, they are functioning at a standard broadly considered “excellent.”

How ASPICE Affects Automotive Development

The world of automotive development is only becoming more complex.

Some factors that are increasing complexity:

Consumer demand: A connected world means that consumers want seamless connectivity across their entire lives. The lines between work, home, and leisure are increasingly blurry, and consumers who still need vehicles to get from point A to point B will want all of those pieces of their lives to be integrated — even behind the wheel.

Increasing regulation: With the increasing complexity of auto systems and a focus on reducing climate impact, auto manufacturers will have to comply with new and possibly shifting regulations across different entities.

Rapid innovation: Technology continues to change and innovate at a breakneck pace. With systems increasingly integrated into automobiles, manufacturers will have no choice but to keep up with innovation. In fact, as of 2019, 80% of product innovation in automotive comes through software development

Fortunately, ASPICE can help auto suppliers and original equipment manufacturers (OEMs) respond to this increasing complexity in multiple ways:

Control the process: ASPICE gives teams clear guidance for evaluating and controlling their development processes, which can help ensure product quality, shorten time to market, and reduce costs.

Streamline supplier selection: By clearly defining levels of achievement, ASPICE can help OEMs assess and evaluate suppliers. If suppliers achieve Level 2 or 3 in ASPICE, OEMs can be fairly certain they are getting quality products.

Reduce costs and improve time to market: Because ASPICE is more concerned with process than with specific regulations or safety guidelines, using the standard can help teams reduce costs and improve efficiency, thereby improving overall market competitiveness.

How to Ensure Compliance with ASPICE

Most automotive developers are rigorously working towards ASPICE compliance and there are many advantages to aiming for it.

1.) It’s possible that compliance will be required some time in the future, so working toward it now is a positive step in preparation.

2.) Automotive development is only getting more complicated, not less, and development will continue to require teamwork across industries, companies, and geographies. Working within the ASPICE standard will help ensure consistency.

3.) Working within ASPICE will give teams a competitive edge over other suppliers and OEMs who are not yet using the standard.

But knowing that compliance is desired and actually achieving it are two different things. How can teams ensure compliance with the ASPICE standard?

Start with an honest assessment.

Teams can’t know where to go until they know where they are. A good place to start is to draft current processes and compare them to the ASPICE V-model. This effort can provide good insights into current levels compliance and where improvements can be made.

Confront the gaps and missing pieces.

Most teams will have some gaps in their processes or procedures. Likewise, some teams will have unclear separation between steps in the V-Model. Look at the gaps and assess how to close them, and identify where additional steps should be introduced.

Include stakeholders.

Be sure that all stakeholders have complete visibility into the ASPICE compliance efforts, and clearly define the resources those stakeholders can provide where necessary.

Test every phase.

Testing is vital to ASPICE compliance. Be sure to include rigorous testing at every phase in the process.

Operate under the new guidelines.

Once the plan is in place, implement it immediately.

Reassess and improve.

After completing a new product under the new ASPICE compliant processes, reassess, evaluate, and look for ways to improve. This constant focus on improvement is what allows teams to achieve higher levels of ASPICE compliance.


ISO 26262 vs. ASPICEIf 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:

  1. Risk Analysis and Management: It emphasizes the identification, evaluation, and mitigation of risks associated with E/E system failures throughout the vehicle’s lifecycle.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

ISO 26262 vs. ASPICE

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.


Automotive Product and Systems Development

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.

RELATED: Watch a demonstration of the Jama Connect for Automotive Solution

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!

SEE MORE RESOURCES

ISO 26262Editor’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.

RELATED: Watch a demonstration of the Jama Connect for Automotive Solution

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.

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.

DOWNLOAD NOW

In Part I of our six-part automotive series, our experts discuss how to accelerate automotive SPICE (ASPICE) capability with Jama Connect for Automotive.

Modern automobiles are complex systems of systems that must be reliable and safe. One way to increase reliability and safety is for automotive OEMs and suppliers to follow established development processes. Following established processes is generally expected of companies developing automotive products.

Note: Now that our automotive development blog series has concluded, you can go back and read series intro and Part II.

Automotive SPICE (ASPICE)

One major component of many automotive systems is software, and the high-level development processes for software development are documented clearly in automotive SPICE. ASPICE is both a process assessment model and a process reference model. It documents the processes that software teams should follow when developing automotive software and it provides a way of measuring how mature an organization’s processes are.

A major component of ASPICE is a robust series of processes for requirements management and traceability. The processes require that organizations develop system requirements, decompose them into software requirements, document a software architecture and detailed design for each software unit. The software must then be fully verified against all requirements and specifications. The processes require that traceability between the requirements, specifications, and verification activities be maintained and all documentation carefully reviewed.

Jama Connect for Automotive

A requirements management tool like Jama Connect® for Automotive reduces the manual effort required in adhering to Automotive SPICE processes. Jama Connect for Automotive’s traceability features are ideally suited to maintaining and analyzing the required traceability. And the review features are the ideal way to ensure documentation is fully reviewed and approved by a cross-functional team. The export features of Jama Connect for Automotive generate well-formatted documents for many of the work products required by ASPICE.

The flow diagram below summarizes the Automotive SPICE processes that can be managed in Jama Connect for Automotive. The boxes with an orange border represent the recommended work products to be captured in Jama Connect for Automotive. The boxes with a gray border represent the work products that benefit from being captured in Jama Connect for Automotive, but some organizations might choose to capture elsewhere.

High-Level Automotive SPICE Process in Jama Connect for Automotive

Jama Connect for Automotive includes a fully functional framework that software teams can use to start getting value from Jama Connect for Automotive immediately. The solution also includes complete documentation for how to complete each process most efficiently in Jama Connect for Automotive. Industry-specific Professional Services are also included to guide customers through the inevitable customizations needed by each organization. A complete list of the processes for working in Jama Connect for Automotive that align with ASPICE are listed in the table below.

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.

DOWNLOAD NOW

How to Choose the Right Tool for ASIL D Requirement Management ISO 26262 / IEC 61508

Editor’s Note: This posts on tool selection around ASIL D requirement management for ISO 26262 / IEC 61508 was originally published here by LHP Engineering Solutions and written by Steve Neemeh. When the options for choosing a requirements management tool are endless, what factors should you be looking at to help make your decision? This article provides some concrete considerations you may use to guide your selection.

requirement management

 

Which tools should I use for ASIL D requirement management ISO 26262 / IEC 61508?

There are a multitude of requirements management tools in the marketplace (e.g., IBM DNG, Siemens Polarion, Jama Software, Helix). How does an organization make the important decision of which is best for its needs when the options are endless or when using Microsoft Word/Excel or Google Docs for requirements management can be considered? Is there even one tool that can meet all of the organization’s needs? This blog will describe why selecting a tool based on one specific departmental need, such as requirements management, might be impractical.

To begin the search, here are five items that might be considered:

1. Cost of Tools
  • The range of costs can vary significantly. For a small organization, some of the larger toolchains may not be affordable. On the other hand, some of the smaller tools may not address parts of requirements management that are critical for ASIL D development.
2. Size and Distribution of the Organization
  • How many engineers need the tools and in how many locations? Some license agreements are floating so utilization could be optimized if the tools are used across multiple time zones (e.g. India and USA).
3. Number of Requirements and Requirements Hierarchy
  • Are there 100 safety-critical requirements or 5,000? Out of these requirements, how many of them are related to software, hardware, or test cases? How large is the HARA and how many safety goals are there? This will define the size of the requirements hierarchy.
4. Existing tools
  • The selection and integration of a new tool will inevitably impact the use of the exiting toolchains.
5. Full ISO 26262 workflow
  • Refer to V diagram.
requirements management ISO 26262 / IEC 61508

LHP’s requirements management V diagram for the Application Lifecycle Management toolchain

 

When researching tools for an organization, it is a common discovery that there is not one tool that meets all of the needs. The tools industry has not caught up with the complexity of the safety lifecycle. What is found in the marketplace are versions of Application Lifecycle Management (ALM) tools, but what is really needed is an LHP ecosystem-based Safety Lifecycle Management (SLM) toolchain. This SLM is based on guidelines for safety-critical development as defined in the 700+ pages of requirements, work products, and methods in standards such as ISO 26262 or the Safety of The Intended Functionality (SOTIF).

What is the Workflow for Functional Safety, ASPICE, and Other Safety-Critical Applications?

The V diagram covers the foundational items that need to be considered in addressing a standard like ISO 26262: project management, task management, and change management. In this particular case, four tools have been considered: ANSYS Medini, Jama Software, Atlassian JIRA, and National Instruments. All four tools provide partial solutions to meeting the needs of functional safety.

  • ANSYS Medini: HARA and systems-level modeling, as well as hardware metrics calculations (Parts 3 & 5 of ISO 26262)
  • Jama Software: Requirements management (required by ISO 26262, emphasized in Part 8)
  • Atlassian JIRA: Project management and change management
  • National Instruments Tools: Automated test and test scripting

By combining the engineering best practices with the tools’ strengths and considering an organization’s main drivers, a workflow can be defined; one that optimizes tool usage and reduces the load on engineers. Ultimately, to be successful within safety-critical development, an organization needs to develop against a standard while also reducing the labor associated with engineering and testing.

Without the latter, the cost and time for development escalate exponentially. Are engineers going to copy and paste data across tools? Are they going to have multiple versions of the same information across different toolchains? As the complexity of systems increases, a non-optimized toolchain can paralyze an organization and its development process.

In the absence of a commercial off-the-shelf fully-compliant SLM tool, the solution of integration tools can provide the same functionality. For this purpose, the tools provide methods of connectivity with REST (Representational State Transfer) API. An example of a REST API between Jama Software and JIRA is shown in the appendix.

Conclusion

When selecting a requirements management tool, it is crucial to consider the needs of the organization as a whole, the safety workflow, and the customization and connectivity for optimization of the tools. In a typical implementation of a safety-critical system, most organizations just consider one, or parts of one, of these critical items, causing large rework and tool spend that can otherwise be avoided.

Take-a-Ways
  • There is no one tool that meets the needs of requirements management in compliance with functional safety.
  • The tool capability varies greatly based on cost, and there is feature overlap between tools.
  • The holistic organization, not just a single department, needs to be involved in making the tool selection. The needs of each department: management, engineering, IT, manufacturing, regulators, and even certification agencies all must be considered.
  • The tool must be appropriate for the size and scale of the organization.
  • There are methods of automating data transfer that significantly reduce labor and cost on development programs (as shown in the appendix).
  • Successful organizations are going to get ahead by creating efficient workflows that allow them to release products faster and more economically in the new electric vehicle/autonomous vehicle (EV/AV) world of transportation.
Appendix: More Details About REST API

Both Jama Software and JIRA provide access to their cloud resources via Representational State Transfer (REST API). REST is a web-based application programming interface that exposes a set of Uniform Resource Locators (URLs) with which to carry out Create, Read, Update, Delete (CRUD) operations in the tool. LHP Engineering Solutions has implemented a Domain Object Model (DOM) connection for both Jama Software and JIRA with a third integration piece to connect the two. The integration piece is a configurable application that implements the customer use cases.

REST API integration

Benefits of Using REST API
  • Ease of implementation
    • REST is a standard specification of how to access web resources
    • All web and cloud-based tools expose REST APIs
    • Returns data, as well as metadata, which allows for conditional and iterative processing
    • Implemented in a JAVA wrapper making it configurable and portable to any system
  • Customizable authentication feature
    • Simple user and password authentication if desired
    • Simple user and access token authentication if more security is desired
    • OAuth authentication is also available but not required
  • Portability of output to Web and other tool frameworks
    • XML/JSON that any tool can consume
    • XML/JSON are standard serialized data formats for web resources
    • Web applications typically take XML/JSON as input files for data exchange, data migration, report building, etc.
REST API Complexities
  • Requires a non-standard mapping of attributes from Jama Software to JIRA and vice-versa. Each customer mapping will need to be customized.
    • The REST specification defines what the API should do but not how it should do it. No standardization of data schema. Therefore, tools will have disparate data models.
    • Attribute A in Tool A must be mapped via a mapping file to Attribute B in Tool B etc. This goes for attributes, links, attachments, and all data elements in each data model.
    • A UI will have to be developed to allow for the mapping creation and management.
Standard Feature Set of REST API
  • Mapping and transfer of attributes and attachments from one tool to the other
    • Data models are mapped as closely to 1:1 as possible
    • UI to build and manage mappings
  • Scheduled and on-demand synchronization
    • Synchronization data between toolsets via UI
    • Synchronize data between toolsets by scheduling a task
  • Intermediate transformations (e.g., risk calculations)
    • Calculating or transforming the data from the source tool before reaching the target tool
  • Linking from one tool to the other via hypertext links
    • URLs from source resources to target resources and vice versa for traceability
  • Reports
    • Since the REST APIs produce a consumable output, any reporting tool that can consume XML/JSON can be used to produce reports.
      • Jama Software reports
      • JIRA reports
      • Requirements gap analysis
      • Test coverage gap analysis
      • Requirements Traceability Matrix
      • Bug reports
      • Customized reports
We’ve compiled a list of helpful resources for requirements management in automotive development, click the button to learn more!
SEE MORE RESOURCES