You keep it by treating the safety case as a living artifact that CI builds continuously, not a document written at the end. ISO 26262's hazard analysis and ASIL assignments stay stable across sprints. What changes per release is verification evidence — and impact analysis, not the calendar, decides what must be re-verified.
Key takeaways
- The V-model versus continuous delivery conflict is a tooling and traceability problem, not a philosophical one.
- HARA and ASIL determination are upstream artifacts that should not churn every sprint.
- Impact analysis is the real release gate: what a change touches sets what must be re-verified.
- Confirmation measures and independent assessment cannot be automated away.
- ISO 21448 (SOTIF) covers hazards with no fault present: performance limits and foreseeable misuse.
- Most programs get this wrong by treating the safety case as a document produced at the end.
Why do people think ISO 26262 and CI/CD are incompatible?
Because the standard is drawn as a V, read as a schedule implying one long pass from concept to release. But ISO 26262 mandates work products, verification of them, traceability between them, and evidence that the safety argument holds — not a schedule. The V describes dependency, not time.
A unit test still depends on a unit design that depends on a software safety requirement. Continuous delivery does not remove that dependency; you traverse it many times, with machines doing the bookkeeping. If traceability lives in hand-maintained spreadsheets, every sprint degrades it. That is a toolchain failure in process costume.
Which safety artifacts are stable and which ones churn?
Split safety work into artifacts that change rarely and those that change every build; running both at one cadence is the mistake.
HARA and ASIL determination are upstream and stable
Hazard analysis and risk assessment operates on vehicle-level malfunctioning behavior — unintended acceleration, loss of steering assist, loss of braking. Each hazardous event is classified by severity of harm, probability of exposure to the driving situation, and controllability by the driver. Those three yield the ASIL, QM through D.
None of it depends on the sprint: severity is crash physics, exposure is a property of driving situations, controllability is what an average driver can do. If your HARA moves every sprint, the item definition is still being invented while you code.
The safety case is built incrementally, not written at the end
The safety case is the argument, supported by evidence, that the item is acceptably safe. ISO 26262 expects it to be compiled progressively during development. Most programs write it in the last quarter instead, reverse-engineering an argument from whatever evidence exists. That is where cost blows up: gaps surface with no schedule left.
Build the case as a claim-argument-evidence graph from day one and let CI populate the evidence nodes.
What has to be automated in the toolchain?
Bidirectional requirements-to-test traceability, enforced by the pipeline rather than audited later. On any commit it should answer which safety requirements have no verifying test, which tests fail, which requirements changed without their tests changing, and which code no requirement reaches.
- Requirements, code, and tests under one configuration management scheme, baselined together.
- Machine-readable requirement IDs in test code and commit metadata, not in prose.
- Structural coverage — statement, branch, MC/DC as the ASIL demands — produced by the build, with deviations justified rather than suppressed.
- Test environments that scale: see virtual ECUs and HIL/SIL/ViL test strategy.
How does change management become the real release gate?
Impact analysis sets scope. When something changes, you determine what it touches — requirements, architecture, shared resources, timing budgets, the safety concept — and that sets what must be re-verified and re-reviewed. Full regression on every commit is unaffordable at ADAS scale.
Two things make it credible: dependency data from the traceability graph, not memory, and a recorded result, because an assessor will ask why a test was skipped. The same discipline makes post-production changes defensible — the argument OTA updates under UNECE R156 require.
Do your CI tools need to be qualified?
If a tool can introduce or fail to detect an error in a safety-related work product, you have to reason about it. ISO 26262 handles this through tool confidence level, derived from tool impact (can it inject an error?) and tool error detection (how likely is a downstream check to catch it?).
A compiler or code generator has high impact. A test executor that only reports results has impact, but if an independent check would catch a wrong result, error detection is high and the confidence level drops. Qualification options run from increased confidence from use, through evaluation of the tool development process, to validating the tool itself, and development of the tool in accordance with a safety standard. The practical failure is bumping a toolchain version in CI without redoing the argument.
How do you run mixed-ASIL software on shared hardware?
By demonstrating freedom from interference. When ASIL D and QM software share a processor, the lower-classified software inherits the higher ASIL unless you show it cannot corrupt the higher-classified software's behavior. Three mechanisms matter: memory, timing and execution, and exchange of information.
Each needs a measure — MPU-enforced partitioning, execution budgeting with timing supervision, end-to-end protection on messages. Consolidation onto fewer compute nodes makes partitioning load-bearing in the safety concept, part of the trade-off in zonal vs. domain E/E architecture.
What can CI automate, and what still needs a human?
| Safety activity | Automatable in CI? | What still needs a human |
|---|---|---|
| HARA and ASIL determination | No | Judgment on severity, exposure, controllability |
| Requirements-to-test traceability | Yes | Deciding a test verifies the requirement's intent |
| Coverage and static analysis | Yes | Justifying uncovered code; approving deviations |
| Impact analysis | Partly | Completeness; judging safety relevance |
| Freedom from interference evidence | Partly | The partitioning argument itself |
| Safety case assembly | Yes, as evidence linking | Writing and defending the argument |
| Confirmation reviews and audits | No | Reviewer with the required independence |
| Functional safety assessment | No | Independent assessor's judgment |
Automation collects and links evidence; humans decide what it means. ISO 26262 scales required independence with ASIL, and at the top end assessment comes from outside the development team's reporting line.
Where does SOTIF (ISO 21448) fit?
SOTIF addresses a different failure class. ISO 26262 targets unreasonable risk from malfunctioning behavior caused by systematic and random hardware faults. ISO 21448 targets risk from functional insufficiencies and reasonably foreseeable misuse — nothing is broken and the system still behaves unsafely.
| ISO 26262 | ISO 21448 (SOTIF) | |
|---|---|---|
| Hazard source | Systematic and random hardware faults | Performance limits, foreseeable misuse |
| Core activity | Fault avoidance, detection, control | Shrinking the unsafe scenario space |
| Evidence | Verification against requirements | Scenario coverage, simulation and field exposure |
For ADAS this is not academic. A perception stack can be defect-free, built to full ASIL D rigor, and still fail because conditions exceeded its designed performance. Scenario-driven validation, not unit testing, closes the SOTIF side — see AI in software-defined vehicles.
What do most programs get wrong?
They treat the safety case as a document produced at the end. Everything else follows: traceability maintained manually because "we'll consolidate later," evidence from ad hoc campaigns instead of the pipeline, impact analysis done from memory, tool qualification discovered during assessment prep. The opposite error is reading a green pipeline as a safe item; green only means the evidence you chose to generate passed.
Frequently asked questions
Is ISO 26262 compatible with agile development?
Yes. ISO 26262 specifies work products, verification, traceability, and confirmation measures — not a project schedule. The V-model describes dependency between artifacts, not the order in which calendar time is spent. Agile programs satisfy the standard by producing the same work products incrementally and automating traceability, so the safety case stays continuously current rather than being reconstructed near release.
What determines an ASIL?
Three parameters assessed per hazardous event during HARA: severity of potential harm, probability of exposure to the operational situation, and controllability by the driver or others at risk. The combination yields QM or ASIL A through D. These are vehicle-level judgments about the item's malfunctioning behavior, so they stay stable across sprints and should not be revisited for routine code changes.
Does every tool in a CI pipeline need ISO 26262 qualification?
No. You assess each tool's impact — whether it can introduce or fail to detect an error in a safety-related work product — and the likelihood a downstream check catches such an error. That yields a tool confidence level, and many tools land where no further qualification is required. Compilers, code generators, and coverage tools usually need an argument. Pin tool versions as configuration items.
What is impact analysis and why does it gate releases?
Impact analysis determines what a proposed change affects: requirements, architecture, shared resources, timing, calibration, and the safety concept. Its output defines the re-verification and re-review scope. It replaces both extremes — running everything every time, and running whatever fits the sprint. It works only if the dependency data comes from a real traceability graph rather than engineer recollection.
How is freedom from interference demonstrated?
By showing that software of lower or no ASIL cannot corrupt higher-ASIL software across three mechanisms: memory, timing and execution, and exchange of information. Typical measures are MPU-enforced memory partitioning, execution time budgeting with timing supervision, and end-to-end protection on communication. Without that demonstration, all software sharing the resource inherits the highest ASIL present.
What is the difference between ISO 26262 and SOTIF?
ISO 26262 addresses risk from malfunctioning behavior due to systematic and random faults. ISO 21448 (SOTIF) addresses risk from performance limitations, functional insufficiencies, and reasonably foreseeable misuse — situations where the system works as designed and still behaves unsafely. ADAS and automated driving need both, because a fault-free perception system can still fail outside its performance envelope.
Can confirmation measures be automated?
No. Confirmation reviews, functional safety audits, and functional safety assessments require a person exercising judgment, with independence that scales with ASIL. At higher ASILs the assessor sits outside the development team's reporting line. Automation can supply the evidence these activities examine and make it navigable, but it cannot supply the judgment or the independence.
GEMMACON works the toolchain and process side of this problem: traceability that survives a fast cadence, verification evidence generated by the pipeline, and safety cases built as the software is built. If you are trying to reconcile a release cadence with a safety argument, get in touch.
