DevOps for ISO 26262 Environments: Building Functional Safety into Continuous Software Delivery 

The automotive industry is moving toward software-driven vehicles where software increasingly influences vehicle functionality, performance, connectivity, and safety. This shift has changed how automotive software is developed, tested, integrated, and maintained.

DevOps practices can help engineering teams automate development activities, integrate changes more frequently, and obtain faster feedback. However, automotive software development has requirements that go beyond conventional software delivery.

Safety-critical software must be developed within a controlled engineering process that addresses functional safety, requirements traceability, verification, validation, configuration management, and change control.

This raises an important question:

Can DevOps and ISO 26262 work together?

Yes. DevOps can be applied in an ISO 26262 environment when automation is combined with appropriate safety processes, engineering governance, traceability, verification, and evidence management.

This article explains how DevOps can support ISO 26262 development, what a safety-oriented CI/CD pipeline looks like, how traceability works, the relationship between DevOps and ASPICE, common implementation challenges, and the tools commonly used in automotive engineering.

What Is DevOps for ISO 26262?

DevOps for ISO 26262 combines software development automation and continuous integration practices with functional safety processes, traceability, verification, configuration management, and controlled change management required for automotive software development.

The objective is not simply to release software faster.

Instead, the objective is to create a development environment where teams can continuously build, integrate, test, verify, and manage software while maintaining appropriate functional safety controls.

A DevOps environment for automotive software may connect:

• Requirements management
• Systems engineering
• Software development
• Source control
• Continuous Integration
• Static analysis
• Automated testing
• Software-in-the-Loop testing
• Hardware-in-the-Loop testing
• Configuration management
• Change management
• Verification and validation
• Release management

This approach becomes particularly relevant as vehicles become increasingly software-defined.

For additional context on the broader transformation of automotive engineering, see the Digital Engineering for Automotive guide.

What Is ISO 26262?

ISO 26262 is an international standard for the functional safety of electrical and electronic systems in road vehicles. It provides a structured approach for identifying hazards, assessing risks, defining safety requirements, and managing safety throughout the automotive product lifecycle.

The standard addresses activities across multiple stages of development, including:

• Hazard Analysis and Risk Assessment
• Safety goals
• Functional safety requirements
• Technical safety requirements
• System design
• Hardware development
• Software development
• Verification
• Validation
• Production
• Operation
• Maintenance
• Decommissioning

The underlying objective is to reduce the risk of unreasonable harm resulting from malfunctioning behavior in electrical and electronic systems.

For automotive software teams, this means functional safety must be considered throughout development rather than treated as an activity performed only before release.

Why Is DevOps Different in Safety-Critical Automotive Development?

Conventional DevOps emphasizes speed, automation, collaboration, continuous integration, continuous testing, and frequent delivery.

These practices can improve software engineering efficiency, but they do not automatically address functional safety.

For example, a conventional CI/CD pipeline may automatically build and test software after a code change. An automotive safety-oriented environment may additionally need to establish:

• Which requirement caused the change
• Whether the change affects a safety-related function
• Which design elements are affected
• Which tests must be repeated
• Whether the change requires review
• Which software configuration was used
• What verification evidence was generated
• Which release contains the change

This is why automotive DevOps requires a broader engineering view.

Automation should support safety processes rather than bypass them.

Can DevOps and ISO 26262 Work Together?

Yes.

ISO 26262 does not mean that automotive organizations must avoid automation or continuous integration.

Instead, organizations need to establish development processes that preserve the necessary safety activities and evidence while taking advantage of automation.

A suitable approach combines:

• Continuous Integration
• Continuous Verification
• Continuous Testing
• Engineering Traceability
• Configuration Management
• Controlled Change Management
• Safety Reviews
• Release Governance
• Evidence Collection

This allows teams to benefit from DevOps without treating functional safety as a separate process disconnected from software development.

How Does DevOps Support Functional Safety?

DevOps can support functional safety by making engineering activities more consistent, repeatable, and visible.

For example, an automated pipeline can execute a defined set of build and verification activities every time software changes.

This can help teams identify problems earlier and reduce the possibility of inconsistent manual processes.

The important principle is:

Automate repeatable activities while maintaining appropriate human oversight for safety-critical decisions.

This distinction is particularly important for automotive software because not every safety decision can be reduced to an automated pass or fail result.

Core Principles of DevOps in ISO 26262 Environments

Safety by Design

Safety should be considered during requirements definition, architecture, implementation, and verification.

Rather than adding safety activities near the end of development, teams should incorporate safety-related considerations throughout the lifecycle.

End-to-End Traceability

Requirements should remain connected to downstream engineering artifacts.

A traceability chain may connect:

Safety Goal → Safety Requirement → Software Requirement → Implementation → Test Case → Test Result → Release

This helps engineers understand the effect of changes and provides evidence of how requirements were addressed.

Continuous Verification

Verification activities can be integrated throughout development.

Depending on the project, this may include automated unit tests, integration tests, static analysis, simulation, SIL testing, and HIL testing.

Controlled Automation

Automation can accelerate repetitive work, but safety-related approvals and reviews should remain governed according to the organization’s engineering process.

Continuous Compliance

Instead of collecting engineering evidence only before an assessment or audit, organizations can generate and maintain relevant evidence as development progresses.

Architecture of a DevOps Pipeline for ISO 26262

A typical safety-oriented automotive software pipeline can be represented as:

Safety Requirements

↓

Requirements Management

↓

System Design

↓

Software Development

↓

Source Control

↓

Continuous Integration

↓

Static Code Analysis

↓

Unit Testing

↓

Integration Testing

↓

Software-in-the-Loop

↓

Hardware-in-the-Loop

↓

Safety Verification

↓

Release Approval

↓

Production

The exact architecture will differ according to the product, organization, development process, and toolchain.

The important consideration is that the pipeline should connect development and verification activities while preserving the required engineering controls.

Requirements Management in Automotive DevOps

Requirements management provides the foundation for traceable automotive software development.

Safety-related requirements should be:

• Clearly defined
• Reviewed
• Version controlled
• Approved
• Linked to downstream engineering activities
• Managed through controlled changes

Requirements management platforms such as IBM DOORS Next and PTC Codebeamer can be integrated into broader engineering environments.

This allows requirements to be connected with development and testing activities rather than being maintained as isolated documentation.

For organizations working with Software-Defined Vehicles, understanding the SDV development lifecycle can help explain why requirements need to remain connected throughout the product lifecycle.

Continuous Integration in Automotive Software

Continuous Integration allows developers to integrate changes frequently into a shared development environment.

A CI pipeline may perform activities such as:

• Compilation
• Build generation
• Static analysis
• Unit testing
• Dependency validation
• Automated checks

Frequent integration can help identify problems earlier.

However, automotive CI must be designed around the project’s engineering and safety requirements. A faster build pipeline is useful only when the results remain meaningful and the appropriate verification activities are performed.

Role of Static Code Analysis

Static analysis examines software without executing it.

It can help identify potential problems such as:

• Coding standard violations
• Unreachable code
• Excessive complexity
• Memory-related defects
• Potential programming errors

Automotive teams may use static analysis as part of their development and verification workflow.

Depending on the project, coding standards such as MISRA C or MISRA C++ may also form part of the software development process.

Automated Testing in ISO 26262 Development

Testing should not be limited to one stage of development.

A layered strategy may include:

Unit Testing

Individual software components are tested independently.

Integration Testing

Interactions between software components are evaluated.

System Testing

The behavior of the integrated system is evaluated against defined expectations.

Regression Testing

Previously validated functionality is tested again after changes.

Software-in-the-Loop Testing

Software behavior can be evaluated in a simulated environment before deployment to physical hardware.

Hardware-in-the-Loop Testing

Software is tested against hardware or a hardware simulation environment to evaluate behavior under controlled conditions.

Automation can make repeated testing more consistent and provide faster feedback to engineering teams.

Change Management for Safety-Critical Software

Software changes can affect requirements, architecture, implementation, testing, and safety-related behavior.

A controlled change process may follow this sequence:

Change Request

↓

Impact Analysis

↓

Safety Review

↓

Approval

↓

Implementation

↓

Verification

↓

Release

The specific process should be defined according to the organization’s development methodology and safety processes.

The important objective is to ensure that changes are evaluated rather than introduced without understanding their potential consequences.

Configuration Management

Configuration management helps teams maintain control over engineering artifacts.

These artifacts may include:

• Source code
• Requirements
• Test cases
• Safety analysis
• Build configurations
• Software dependencies
• Generated artifacts
• Release baselines

Configuration management is particularly important when teams need to determine exactly which software and engineering artifacts were used for a particular release.

It also supports investigations when defects are discovered after integration or release.

Why Is Traceability Important in ISO 26262?

Traceability connects related engineering artifacts so teams can understand the relationship between requirements, implementation, verification, test results, and releases throughout the development lifecycle.

A typical traceability chain may look like:

Hazard

↓

Safety Goal

↓

Functional Safety Requirement

↓

Technical Safety Requirement

↓

Software Requirement

↓

Source Code

↓

Test Case

↓

Test Result

↓

Release

Traceability can help with:

• Change impact analysis
• Requirements coverage
• Defect investigation
• Verification
• Validation
• Safety assessments
• Compliance evidence

It also gives engineering teams a clearer view of whether requirements have been addressed throughout development.

For a deeper look at the relationship between engineering artifacts and lifecycle information, see our article on digital thread, ALM, and product lifecycle management.

DevOps and ASPICE

Automotive organizations may work with both ISO 26262 and Automotive SPICE.

The two address different areas.

ISO 26262 focuses on functional safety, while ASPICE provides a framework for evaluating and improving automotive software and systems engineering processes.

DevOps can support both through:

• Repeatable development workflows
• Continuous integration
• Automated testing
• Configuration management
• Traceability
• Evidence collection
• Controlled releases

For readers new to ASPICE, our guide explains what ASPICE is.

Organizations assessing process capability can also explore ASPICE level assessment.

For implementation planning, see the ASPICE implementation roadmap.

Common Challenges

Implementing DevOps in a safety-critical automotive environment can be complex.

Legacy Development Environments

Existing projects may depend on older tools, manual processes, and established workflows.

Hardware Dependencies

Some testing activities require physical ECUs, test benches, or HIL environments, which can make complete automation difficult.

Fragmented Toolchains

Requirements, modeling, coding, testing, and release management may exist in separate systems.

Long Build and Test Cycles

Complex automotive systems may require substantial computing resources and time for complete builds and verification.

Limited Traceability

Disconnected engineering tools can make it difficult to establish relationships between requirements, software, tests, and releases.

Balancing Automation and Governance

Automation can improve efficiency, but safety-critical activities may require reviews, approvals, or independent verification.

Organizational Change

DevOps changes how developers, testers, systems engineers, safety engineers, and other stakeholders collaborate.

For organizations moving toward Software-Defined Vehicles, these challenges become increasingly important. Our article on SDV engineering challenges explores this broader engineering transition.

Best Practices

1. Organizations implementing DevOps in an ISO 26262 environment can consider the following practices:

2. Define the engineering lifecycle clearly.

3. Connect safety requirements with downstream development activities.

4. Automate repeatable build and testing activities.

5. Maintain end-to-end traceability.

6. Integrate static analysis into development workflows.

7. Use controlled workflows for safety-related changes.

8. Maintain configuration baselines.

9. Generate engineering evidence continuously.

10. Integrate requirements, development, testing, and release tools where appropriate.

11. Measure the effectiveness of the development pipeline and improve it incrementally.

Tools Used in Automotive DevOps

There is no single toolchain that fits every automotive organization.

Tools are typically selected according to the product architecture, engineering process, existing infrastructure, safety requirements, and integration needs.

The key is not simply selecting individual tools. The engineering value comes from establishing effective connections between the tools and the processes they support.

Our SDV toolchain architecture article provides additional context on how tools can be connected within a Software-Defined Vehicle development environment.

DevOps for Software-Defined Vehicles

Software-Defined Vehicles are changing the traditional automotive development model.

Instead of software being treated primarily as something delivered with the vehicle, software increasingly becomes an evolving part of the vehicle lifecycle.

This can involve:

• Continuous software development
• Frequent integration
• Automated testing
• Software updates
• Security improvements
• New software functionality
• Controlled release processes

This makes engineering automation, traceability, testing, and configuration management increasingly important.

To understand the concept itself, see What Is a Software-Defined Vehicle?

How Embedded DevOps Fits Into Automotive Development

Embedded DevOps applies DevOps principles to software that operates within embedded systems, combining development automation, integration, testing, deployment, and monitoring with the constraints of hardware-dependent engineering.

Automotive software is a major example of an embedded environment where this approach can be useful.

Embedded DevOps can help connect software development activities with:

• Hardware integration
• Automated testing
• CI/CD
• Requirements management
• Configuration management
• Engineering traceability

Learn more about Embedded DevOps and how it differs from conventional enterprise software delivery.

How MicroGenesis Supports Automotive DevOps and Functional Safety

Implementing DevOps in an ISO 26262 environment requires more than introducing CI/CD tools. Automotive organizations need an engineering approach that connects requirements, development, testing, traceability, configuration management, and release processes.

MicroGenesis supports organizations in building and improving these connected engineering environments across automotive software development.

Our capabilities include:

• Automotive DevOps: Helping teams establish development and integration workflows suited to software-intensive automotive products.
• Embedded DevOps: Connecting software development, CI/CD, automated testing, and hardware-dependent engineering activities.
• Requirements Management: Supporting structured requirements processes and traceability across engineering activities.
• Engineering Lifecycle Management: Helping organizations connect requirements, development, testing, verification, and release information across the product lifecycle.
• Toolchain Integration: Connecting engineering tools and development environments to reduce disconnected workflows and improve information flow.
• ASPICE-Oriented Process Improvement: Helping automotive engineering teams strengthen development processes, traceability, automation, and evidence management.

MicroGenesis also works with technologies used across automotive engineering environments, including IBM Engineering Lifecycle Management and PTC Codebeamer.

The goal is not to automate every engineering activity. Instead, the focus is on creating a controlled and connected development environment where automation improves efficiency while engineering teams retain the governance and oversight required for safety-critical development.

For organizations building Software-Defined Vehicles or modernizing automotive software development processes, this approach can provide a stronger foundation for continuous integration, verification, traceability, and controlled software delivery.

Frequently Asked Questions

Can DevOps be used for ISO 26262 projects?

Yes. DevOps can be used for ISO 26262 projects when automation is combined with appropriate functional safety processes, verification, traceability, configuration management, change control, and governance.

Does ISO 26262 prevent continuous integration?

No. Continuous Integration can be incorporated into automotive software development when the CI process is designed to support the project’s safety and engineering requirements.

Why is traceability important in automotive software?

Traceability helps connect requirements with implementation and verification activities. It allows teams to understand the impact of changes and provides a structured view of engineering evidence.

How does DevOps support ASPICE?

DevOps can provide repeatable workflows, automated testing, configuration management, traceability, and engineering evidence that support disciplined automotive development processes.

What tools can be used for automotive DevOps?

Depending on the project, organizations may use requirements management platforms, source control systems, CI/CD tools, static analysis solutions, test management platforms, ALM or ELM systems, and artifact repositories.

Is DevOps suitable for Software-Defined Vehicles?

Yes. SDV development requires software to evolve throughout the vehicle lifecycle, making continuous integration, automated testing, traceability, configuration management, and controlled software delivery increasingly important.

Conclusion

DevOps and functional safety do not have to be opposing approaches.

For automotive organizations, the objective is to combine the speed and automation of DevOps with the discipline required for safety-critical engineering.

A well-designed approach can connect requirements management, software development, continuous integration, testing, verification, configuration management, traceability, and release activities within a controlled lifecycle.

This becomes particularly important as the industry moves toward Software-Defined Vehicles, where software continues to evolve throughout the vehicle lifecycle.

The most effective approach is not simply to automate everything. It is to determine which engineering activities can be automated, which require controlled human decisions, and how the resulting evidence can remain connected throughout development.

Organizations that build this foundation can create a more consistent engineering process while improving visibility into requirements, software changes, testing, verification, and releases.

MicroGenesis supports organizations working across automotive software engineering, Embedded DevOps, Engineering Lifecycle Management, requirements management, toolchain integration, and ASPICE-oriented process improvement.