Posts

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.

It 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.

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: Watch a demonstration of the 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.

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.

Stay tuned in the coming weeks for additional posts on ASPICE 101 to learn more about this important automotive standard.

In today’s competitive market, automobile makers are racing to define the future of transportation. And given the complexity of modern, connected automobiles, it’s imperative that vehicle safety is adequately accounted for in the product development process.

Plus, as vehicles become more complex — e.g. autonomous driving and connected systems — so too are the standards for emissions, fuel economy, functional safety, cybersecurity, and system designs.

That’s why we’ve partnered with LHP Engineering Solutions (LHP) to ensure our visionary clients comply with all relevant functional safety and cybersecurity standards — like ISO 26262 and SAE J3061 — by seamlessly integrating compliance into the product development process.

Founded in 2001 with the mission to make safer products, LHP provides a variety of engineering services and products to assist customers in speeding up their product development cycles and solving product design and testing issues.

We recently spoke with the LHP team to talk about modern challenges in complex product development, and how this new partnership between LHP and Jama Software can help. Let’s dive into what customers can gain from this partnership:

Jama Software: Can you give us a rundown of the state of the automotive industry? How is it different than 10 years ago?

LHP: The next generation of automobiles are increasingly incorporating modern electronic technologies, from on-board diagnostics to engine controllers to infotainment systems to driver assist systems. As technology advances, the trend is to partially/fully automate vehicles. While some new features are entertainment- and convenience-based, the trend for autonomous vehicles is, to a large extent, functional safety related. The end goal is to reduce the number of deaths on public roadways by providing vehicles with the ability to recognize and avoid hazards or security threats.

Safety and security are the two biggest barriers to innovation and we’re helping companies overcome those barriers. The biggest reason why we don’t see self-driving cars everywhere is because, before that happens, we must prove that they’re not going to harm people, that they’re safe, and that the software can’t be compromised and used for unintended usage.

JS: What are some of the biggest challenges facing product development teams in the automotive industry today?

LHP: Compliance to ISO 26262 and SAE J3061 involves a change in culture that is difficult for established product development teams to implement. Part of this change means looking at the product(s) being developed differently, and part is a change in infrastructure to better control the product development lifecycle and the development artifacts.

Learn more about ISO 26262 and automotive electronics development.

JS: How does leveraging the partnership between LHP and Jama Software help customers when it comes to overall functional safety as well as complying with ISO 26262?

LHP: ISO 26262 complements good systems engineering practices by requiring that hardware and software safety concerns be addressed and documented in a systematic way throughout the product development lifecycle. In the past, safety design was considered part of general requirements activity. But merely identifying and tracing requirements in the software and hardware designs is not enough. The common practice of hardware and software teams working in silos will not guarantee the level of safety coverage required by ISO 26262.

Part of LHPs offering is development of data, infrastructure consultation, and process optimization. Now, thanks to our partnership with the Jama team, we can implement proper functional safety workflows in Jama Connect, with templates to facilitate the creation of data. Additionally, Jama Software customers in the automotive industry who have questions and concerns about how to use Jama Connect to support a safety lifecycle can tap into LHPs extensive knowledge and experience in functional safety and ISO 26262.

In order to demonstrate compliance with ISO 26262, you must have the ability to manage safety requirements, including traceability. Typically, our respective customers would need to address functional safety and requirements management separately. Working together, LHP and Jama Software can address both sets of concerns in concert.

Learn how Jama Software worked with TÜV SÜD on our ISO 26262 certification process, and how you can lower the costs and risks of complying with functional safety standards, by watching our webinar.

JS: What does LHP bring to the table that other requirements management platforms might not have access to?

LHP: What makes us better and unique compared to a lot of the other organizations is our wealth of knowledge. Our functional safety team actually came out of the aerospace industry with multiple decades of experience implementing safety-critical systems. The experience that they bring with them has time and time again proven to make us stand above the rest.

Just like Jama, LHP excels at custom integrations and tailoring flexible solutions for our customers. At LHP, we consult on and implement the latest automotive industry practices to ensure vehicle systems are safe, reliable, and secure. Customers come to LHP for our deep knowledge in embedded controls, integration support, and overall implementation of functional safety and cybersecurity processes.

Proving compliance with functional safety and cybersecurity standards like ISO 26262 and SAE J3061 requires a harmonious balance of processes, people, and tools. And together with LHP Engineering Solutions, Jama Software is helping automotive companies safely and confidently bring the future of transportation to market.

To learn more about how to maintain compliance with automotive functional safety standards and how to avoid common ISO 26262 mistakes, download our whitepaper, “Top 15 ISO 26262 Snafus.”

In Part II of our six-part automotive series, our experts discuss how to ensure functional safety compliance using Jama Connect for Automotive. If you’re new to our Automotive Development blog series, you may want to go back and read Part I and the Series Intro.

While safety has long been an important aspect of developing automotive systems, traditional safety considerations have largely involved mechanical systems. The modern automobiles, however, are increasingly relying on electronic systems and significant amounts of software. This increase in electronics in vehicles brings in new considerations when it comes to functional safety compliance.

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

Functional Safety Compliance: ISO 26262

The standard that is concerned with the functional safety of electronic systems is ISO 26262. ISO 26262 is actually a series of standards that provides a framework for developing both electronic hardware and software systems where functional safety must be achieved. The standard describes a process for identifying risks in a system and provides guidance for mitigating those risk. The guidance is provided in the form of requirements and processes that are understood by the industry as the current state of the art for achieving functional safety.

A major component of ISO 26262 is a robust series of processes for requirements management and traceability. The processes require that organizations develop safety goals, translate those into functional requirements, technical requirements, and eventually both hardware and software requirements as appropriate for the system. The system must then be fully verified against all requirements and specifications. Critically, 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 ISO 26262. Jama Connect for Automotive’s traceability features are ideally suited to maintaining and analyzing the required traceability. The review features are the ideal way to ensure documentation is fully reviewed and approved by a cross-functional team. The export features generate well-formatted documents for many of the work products required by ISO 26262.

The flow diagram below summarizes the ISO 26262 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 ISO 26262 Process in Jama Connect for Automotive

Jama Connect for Automotive includes a fully functional framework that software teams can use to start getting value immediately. This 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 ISO 26262 are listed in the table below.

ISO 26262 Alignment to Jama Connect Processes

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

This post on innovation in automotive engineering is part of a series. You can find Part II on legacy software pains here, Part V on moving from DOORS to Jama Connect here, and Part VI on migration solutions here.

Few industries are as visibly affected by digital transformation as the automotive industry. Over a century ago, Henry Ford started to produce the production of the famous Model T and jump-started the success of the car as a consumer item. There has been lots of incremental innovation ever since, but nothing compared to what we are seeing today, like self-driving cars, over-the-air feature enablement, or transportation as a service.

Challenges for New and Established Organizations

It is unclear who is in a better position for exploiting the exciting opportunities in the automotive market. Established vendors have a solid, financially-strong foundation to operate from, combined with decades of experience in building cars. But this legacy is also slowing innovation down, as manufacturing processes and production lines are based on long development cycles. There are reasons for it: Existing automotive design processes evolved from a paper-based mindset, where every additional iteration in is expensive. Likewise, the production line was tuned for high throughput at low per-unit prices, but this makes changes very expensive.

New players in automotive engineering, on the other hand, are generally more agile and open. They can react faster and are willing to think outside the box. But their lack of experience can result in major issues with respect to compliance and production, creating expensive delays at late stages in development.

The First Generation of Requirements Management Tools

For decades, the automotive industry had recognized requirements as a key factor for success. The German automotive industry, in particular, started to introduce dedicated requirements tools in the ‘90s, and they encouraged their suppliers to do the same. Their solutions were establishing a new paradigm, using an item-based data model, rather than documents. This means that every requirement was an atomic item, with its own attributes, like priority and version history.

IBM® DOORS® (IBM Engineering Requirements Management – DOORS Family) was pioneering the idea of item-based requirements, and until the mid 2000s, there was really nothing like it available on the market. But by that time, some of the shortcomings of DOORS were becoming apparent. As a result, requirements specifications with tens of thousands unstructured requirements were not unusual, leading to redundancies and inconsistencies.

As a result, the first generation of requirements management tools were effective in helping the industry to scale. To a degree, they also helped in managing complexity. But they did not help in making the industry more innovative.

See how one Fortune 100 semiconductor company is managing the complexity of automotive development in our whitepaper. Read now.

Innovating with the Current Generation of Requirements Management Tools

Jama Connect™ was created to address the shortcomings of the first generation of requirements management tools. Specifically, Jama Connect was designed to solve the top challenges faced by regulated systems development teams. This fits the situation in the automotive industry today, and the following capabilities are key enablers for innovation:

Ease of Use – Requirements are used by everyone involved in automotive engineering. Not just the development team, but also engineering, quality, product marketing, sales, and leadership rely on requirements for an up-to-date product description. Good requirements also help departments make informed decisions. By contrast, first-generation tools were so hard to use that many important stakeholders refused to use them.

Single Source of Truth – Innovation requires trade-offs, which must be based on facts. It is crucial that facts — possibly derived from various sources — are instantly available. The first generation of tools typically only held a fraction of key data, and generating meaningful reports was a tedious, manual process.

Collaboration – Innovation requires heavy collaboration. First-generation tools did not have collaboration features, which meant that it took place outside the tool, i.e. via email or in meetings. But that creates a lot of friction and leads to situations where important information is missed. Modern solutions, by contrast, allow collaboration in context. This means that you have visibility into all relevant data and access to all relevant stakeholders while collaborating. And not just that…

Audit Trail – While first generation tools already had proper versioning, modern solutions go much further: For instance, the context-based collaboration leaves an audit trail in the tool (rather than in Outlook). This is crucial for efficient risk management and compliance. Developing new, innovative products typically results in much more activity. Context-based collaboration records decisions, issues, and answers exactly where you need them for compliance, and where you find them when you make reviews and trade-offs.

Learn how to avoid some of the biggest mistakes while developing automotive products for ISO 26262 compliance. Read the guide.

Managing Change – More than anything else, innovation requires the ability to react to change, no matter whether from the outside (new market needs) or inside (new technologies). The first generation of tools already acknowledged that by offering traceability-based functionality. But it was cumbersome to create and maintain the traceability, and many traceability-related issues were not apparent during day-to-day work but required running special reports. Modern solutions, by contrast, offer actionable traceability: Gaps in coverage or items that are marked as suspect due to change are visualized in many places, and allow fixing with a few clicks. This takes most of the friction out of the management of the traceability and allows for faster development iterations.

Reuse – Ironically, using what we already designed is an enabler for innovation. Without effective reuse, a lot of time and energy is wasted on re-designing what had already been designed and to re-test what had already been tested. It allows to focus our energy on the 20% that are truly new and truly innovative.

Integration – Last, the first generation of requirements tools created internal silos by making it very hard to get data in or out. Large vendors often offered half-hearted integration with their own software tools. While this was better than nothing, it often resulted in mediocre tool chains that were not based on need, but on availability. Jama Connect, by contrast, embraces openness by offering powerful interfaces that encourage integration with best-of-class tools.

Innovation in automotive engineering is only possible if all stakeholders can collaborate effectively, even in the context of very complex products, without being held back by the need to collect data from multiple places, or burdensome regulatory overhead. This is only possible with current generation requirements tools like Jama Connect.

*IBM® and DOORS® are registered trademarks of IBM Corporation.

Learn how the combination of Jama Connect and our Automotive Services tightens your development process by reading our datasheet.

As a child and then an adult during the great age of Sunday morning cartoons, I was especially taken with two shows that depicted the opposite ends of human development: The Flintstones and The Jetsons. The heroes both had spouses, children and pets, but while Fred Flintstone had to travel the streets of Bedrock powering his vehicle with his own two feet, George Jetson whizzed around space in his personal space capsule.

In recent years, technological advancements in the automotive industry have pushed us closer and closer to driving the vehicles of the future, where the modes of transportation in The Jetsons may someday become reality. But with the rapid pace of development in the automotive industry comes a host of problems related to safety, system compliance and consistency, which remind us that as engineers we still need to stay grounded.

Automotive companies such as Tesla (and even tech giants like Google) are leading the charge in developing autonomous vehicles, generating dozens of new headlines with each software rollout or press release. For design teams working on these vehicles, the task of merging complex, ever-changing software with the rigid confines of an automobile’s hardware has become increasingly complicated.

Developing autonomous vehicles presents multiple challenges for engineers and developers. For one thing, it’s a highly uncharted and heavily scrutinized field. With the cost of failure being injury, or even death, automotive manufactures must ensure that any new technology or tool implemented throughout the design process will not result in a catastrophic result. The National Highway Transportation Safety Agency recently published its Federal Automated Vehicles Policy, providing a list of 15 areas that organizations wishing to develop an autonomous vehicle must comply with before it can even be considered road-legal.

Standards, such as ISO 26262, are not necessarily new to the automotive industry, but have since become more broadly applicable given the fluid and dynamic state automotive development. ISO 26262 provides a system of steps for managing functional safety and regulating product development on the system, hardware and software levels. The standard provides guidelines and recommendations throughout the development process of an automobile, from conceptual development through decommissioning. During each phase of development, ISO 26262 requires that certain risk levels be placed on a system or component, as well as the overall test process, to ensure safety and system compatibility.

Automotive manufacturers have begun integrating new development tools and technologies in their design processes to further evolve how teams are aligned, ensure they are building the right products and to verify the functional safety of what they design. Product development software has proven itself to be a key tool in predicting single point of failure, while also highlighting the impact of specific changes on the product in the long run. New software platforms have integrated ISO 26262 and other compliance standards and regulations in their own verification and validation kits, preventing mistakes and providing evidence to assist in meeting functional safety standards.

Regulations and standards within the automotive industry are not new things, and the criteria for compliance among developers will only increase as advancements in autonomous vehicle technology increases. While we’re likely decades away from owning the personal spaceships depicted in The Jetsons, the rapid pace of development in the automotive industry makes such a future seem less like fiction. For automotive engineers and developers, it’s important to use modern tools to ensure system compliance between the hardware and software systems in an automobile. Doing so will reduce costs, ensure compliance and reduce the risk to human life as we steer toward the future.

For more on the standards impacting tractability, risk management, validation and verification, read our paper on ISO 26262 & Automotive Electronics Development.