Streamline ISO 26262 & ISO 21434 Compliance With Automated Testing

In the automotive industry, ISO 26262 addresses software safety in product development and outlines various testing methods to ensure the delivery of safe vehicles. Similarly, many organizations must meet software security and verification requirements recommended by ISO 21434.  

Essential verification methods like static analysis, unit testing, structural code coverage, and requirements traceability can be time-consuming and labor-intensive. Discover how to automate them within the natural workflow of software development to reduce labor costs, expedite time to market, enhance code quality, and ensure compliance with ISO 26262 and ISO 21434 functional safety and security standards.  

Key Takeaways

• Integration is Key: You can integrate cybersecurity requirements into your existing safety processes, making it easier to manage both.
• Continuous Testing: Adopting continuous testing practices within your CI pipeline is a best practice for major automotive manufacturers.
• Automation Benefits: Automating tests like static analysis, unit testing, and code coverage reduces labor costs, speeds up time to market, and improves code quality.
• Tooling Matters: Using the right tools, like GoogleTest for unit testing and integrating them with coverage and traceability solutions, is vital.

The V-Model and Testing Levels

ISO 26262, particularly Part 6 for software development, uses a V-model. This model shows different phases of development on the left side (requirements, design, implementation) and corresponding testing phases on the right (unit testing, integration testing, system testing). While the V-model is a recommended process, it’s not a development methodology like Waterfall or Agile.

ISO 21434 also uses a similar V-model approach for development and verification, emphasizing the need to test security functions at different levels. This means unit testing encryption functions, integration testing boot processes, and system testing communication protocols to ensure data exchange is secure.

Learn best practices for accelerating ISO 21434 compliance with automated testing.

Connecting Safety and Security Testing

ISO 21434 states that cybersecurity should be integrated into existing processes. Since many in the automotive industry are already familiar with ISO 26262, integrating security is more straightforward. This often involves systems engineers working closely with security engineers to define requirements, perform hazard analysis for safety, and threat analysis for security.

Both standards require similar verification methods:

1. Requirements-Based Testing: Linking tests directly to safety/security requirements.
2. Static Analysis: Checking code for potential issues without executing it.
3. Dynamic Analysis: Includes unit, integration, and system testing.
4. Code Coverage: Ensuring that tests exercise the code sufficiently. For security, metrics like Modified Condition/Decision Coverage (MCDC) are important, as they go beyond simple statement or branch coverage.

Automating Compliance with CI/CD

Many automotive manufacturers are adopting continuous integration (CI) and continuous delivery (CD) workflows. These pipelines help predict software delivery, manage requirement changes, and reduce issues reported by quality assurance. The focus is on automation at scale.

Frameworks like GoogleTest are popular for unit testing in C++. They are easy to use, have a clear syntax, and integrate well with build systems like CMake. However, to get the most value, these frameworks can be enhanced with tools that add structural code coverage and requirements traceability.

A Typical Workflow Example

Here’s how a streamlined workflow might look:

1. Feature Branch Development: Developers work on new code in a separate branch, often linked to requirements in tools like Jira.
2. Local Testing: Developers test their code locally using GoogleTest and their containerized toolchain.
3. Pull Request: A pull request is created, triggering an automated pipeline.
4. Automated Gates: This pipeline includes quality gates for testing, such as code coverage. If these gates aren’t met (e.g., insufficient MCDC coverage), the pull request fails.
5. Analysis and Fixes: Developers analyze the pipeline reports (often published to GitHub Pages or viewed via IDE extensions) to identify gaps and add missing test cases.
6. Merge: Once all issues are fixed and the pipeline passes, the code is merged into the main branch.
7. Main Branch Pipeline: Merging triggers another pipeline that monitors the stable branch, sending results to a reporting system like Parasoft DTP for aggregated analysis and compliance reports.

Cost Considerations

When comparing open-source tools with commercial solutions, several cost factors come into play:

• Acquisition Cost: Open-source tools may seem cheaper initially.
• Qualification Effort: Commercial tools are often pre-certified, reducing the qualification overhead for your team.
• Integration Cost: Tools that integrate easily into automated workflows (like command-line tools) are less expensive to implement.
• Training Cost: Open-source tools might not require extensive training if developers are already familiar with them.
• Test Case Creation: Frameworks that simplify test case creation, like GoogleTest, can be very efficient.
• Achieving Coverage Goals: Tools that provide hints and detailed reports for achieving higher coverage, especially MCDC, can significantly reduce the effort and cost.

By automating verification methods and integrating them into your development workflow, you can effectively reduce labor costs, speed up your time to market, improve code quality, and ensure compliance with ISO 26262 and ISO 21434.