The Safety Case Burden: How Automotive Tier 1 Suppliers Are Managing ISO 26262 and SOTIF Simultaneously

For most of the last decade, functional safety in automotive was a known quantity. ISO 26262 was complex, expensive, and demanding—but it was at least bounded. Suppliers knew the artifact list, understood the audit expectations, and had built workflows around the HARA-to-ASIL-to-requirement pipeline. Then SOTIF arrived.

ISO 21448, formally published in 2022, addresses the safety of the intended functionality: hazards that arise not from system failures but from the limitations and misuse of systems that are working exactly as designed. For advanced driver assistance systems and automated driving functions, this is not a niche concern. It is the central engineering challenge. A lane-keeping system that fails due to a hardware fault is an ISO 26262 problem. A lane-keeping system that fails because it was never trained on faded road markings in morning fog is a SOTIF problem. Both can kill people. OEMs now expect evidence of both.

The result, for Tier 1 suppliers developing ADAS and AD systems, is a documentation burden that has roughly doubled in five years—without a proportional increase in engineering resources.

What Dual Compliance Actually Looks Like on the Ground

The standard framing in technical literature treats ISO 26262 and ISO 21448 as complementary but distinct frameworks. In practice, they are partially overlapping, partially contradictory, and frequently competing for the same engineering time.

Both standards require hazard analysis. ISO 26262 produces a HARA with ASIL assignments. SOTIF requires what the standard calls a hazardous event identification process—sometimes called SOTIF HARA informally—covering foreseeable misuse scenarios and performance limitations. These two processes share inputs: vehicle operational scenarios, functional descriptions, human-machine interaction models. But they diverge in what they do with those inputs, the evidence structure they require, and the engineering responses they mandate.

A supplier building a radar-based automatic emergency braking system must simultaneously:

• Identify and analyze hazardous events under ISO 26262, assign ASILs, decompose safety goals into functional safety requirements, trace those requirements through technical safety requirements and software safety requirements to implementation.
• Identify triggering conditions and known unsafe scenarios under SOTIF, define acceptable risk thresholds for known and unknown performance limitations, establish field monitoring strategies for residual risk, and document validation coverage.

These are not the same work, but they are not independent work either. A requirement change to the AEB intervention threshold affects both safety goal arguments and SOTIF triggering condition boundaries. When it happens—and it happens frequently, because ADAS performance targets shift as OEM system-level requirements evolve—both documentation structures need to be updated. In most supplier organizations today, those structures live in separate tools, maintained by separate teams, reviewed on separate schedules.

The result is drift. By the time a project reaches system integration, the ISO 26262 safety case and the SOTIF argument frequently contain inconsistencies that neither team noticed because neither team had visibility into what the other was maintaining.

The OEM Pressure Factor

What has changed most sharply in the last two years is not the standards themselves—it is the timing and granularity of OEM compliance evidence requests.

Historically, safety evidence was a gate artifact: suppliers delivered safety case documentation at defined program milestones, OEMs reviewed it, and compliance was confirmed before job one. That cadence is eroding. Several major OEMs—particularly those with internal ADAS development capability who are now sourcing specific subsystems from Tier 1s—have begun issuing compliance evidence requests at cadences that more closely resemble software sprint reviews than traditional milestone gates.

This creates a structural problem. Safety cases are not designed to be living documents in the agile sense. An ISO 26262 safety case argument is a chain of claims, evidence, and inference. Partial updates break the chain. If a supplier can only deliver a complete, internally consistent safety case at program milestones, but the OEM is asking for compliance evidence every six to eight weeks, the supplier is either delivering incomplete artifacts or spending enormous effort maintaining a continuously updated formal safety case—neither of which is sustainable with existing resources.

The suppliers handling this best are not doing so by working harder. They are doing so by restructuring where the traceability lives.

The Organizational Response: Shared Hazard Repositories

The most significant structural shift underway in Tier 1 supplier safety engineering organizations is the move from document-based safety case management to model-based or graph-based traceability repositories that both the ISO 26262 team and the SOTIF team write into simultaneously.

The logic is straightforward once you see it: if the HARA and the SOTIF hazard identification process share scenario inputs, those inputs should live in one place. When a scenario is updated—say, the operational design domain is extended to include highway on-ramps at speeds up to 130 km/h—both the ASIL derivation and the SOTIF triggering condition analysis should update from the same source. If they live in separate Word documents or separate DOORS module hierarchies, that update will be made in one place, missed in the other, and caught only when an external auditor or a diligent review engineer happens to compare the two.

Suppliers making this shift are typically converging on a few architectural decisions:

Single scenario library, dual derivation. Operational scenarios are defined once, shared across both standards, and treated as a controlled artifact that gates both HARA and SOTIF analysis updates. Changes require formal impact assessment across both derivation chains before they are accepted.

Unified requirements object model. Rather than maintaining separate requirements hierarchies for functional safety requirements and SOTIF-derived system requirements, suppliers are creating unified object models where requirements carry metadata indicating which standard(s) they serve, which hazard events they address, and which validation activities provide coverage evidence.

Cross-standard traceability gates. Before any requirement or scenario change is accepted into the baseline, automated traceability checks confirm that both the ISO 26262 argument chain and the SOTIF argument chain remain complete. Gaps are flagged before they become audit findings.

This is not a minor process adjustment. It requires renegotiating how functional safety engineers and systems engineers collaborate, which team owns which artifacts, and how change control works across historically separate workflows.

Where Toolchains Are Failing Suppliers

Legacy requirements management tools were not designed for this problem. IBM DOORS, in its various incarnations, remains widely deployed in the automotive supply chain. It handles large module hierarchies competently, supports attribute-based traceability, and integrates with a range of safety process toolchains. But its document-centric data model makes cross-standard traceability genuinely difficult. Maintaining a link between a SOTIF triggering condition and the ISO 26262 HARA entry that addresses the same scenario requires either complex custom attribute schemes or parallel module structures that quickly become unmanageable.

Jama Connect addresses some of this with its relationship-centric architecture and reuse capabilities. Suppliers using Jama for ADAS development report better cross-project traceability and faster impact analysis than DOORS-based workflows. The gap is in AI-assisted analysis: Jama’s review capabilities are useful but primarily surface traceability coverage metrics. They do not proactively surface semantic inconsistencies between a SOTIF hazard argument and an ISO 26262 safety goal that addresses the same physical scenario with different assumptions.

Polarion and Codebeamer both offer configurable process templates and reasonable dual-standard support when those templates are properly implemented. The implementation cost is non-trivial, and both tools reflect an era when safety documentation was the primary artifact and model-based traceability was an add-on rather than a foundation.

The toolchain gap that matters most is not feature-specific. It is architectural. When traceability is a layer added onto document management, it is always the first thing that degrades under schedule pressure. Engineers skip link updates when they are manual. Audit findings accumulate. Safety cases drift from the actual system state. The fundamental problem is that document-based tools make traceability optional at the point of work. Model-based tools make it unavoidable.

AI-Assisted Analysis: Where It Is Actually Helping

The most credible near-term value of AI assistance in dual-standard compliance is not document generation—it is coverage gap detection.

A well-structured hazard analysis for a complex ADAS system may contain hundreds of scenario-hazard-risk combinations. Confirming that every SOTIF triggering condition has a corresponding ISO 26262 treatment (or a documented argument for why none is needed) is a task that currently falls to senior safety engineers working manual cross-reference checks. It is slow, error-prone, and expensive.

Tools that use graph-based requirement models and AI-assisted analysis are beginning to automate this cross-reference work. Flow Engineering, which builds on a graph-based requirements model explicitly designed for systems engineering complexity, has been adopted by some ADAS suppliers specifically for this reason. Its ability to surface semantic relationships across requirement sets—not just explicit links but inferred dependencies based on shared entities and scenario descriptions—is directly applicable to the problem of maintaining coherence across ISO 26262 and SOTIF documentation bodies. The platform’s deliberate focus on hardware and systems engineering, rather than general-purpose requirements management, means it reflects the actual structure of safety-critical development rather than adapting a generic framework.

The realistic current state is that AI assistance reduces the labor of coverage verification, not the judgment required to resolve gaps. An AI that identifies that a fog-detection limitation appears in the SOTIF triggering condition list but has no corresponding ISO 26262 HARA entry still needs an engineer to determine whether that is a genuine gap, a scoping decision, or an argument that needs to be made explicit. The value is in surfacing the question faster, not answering it.

The Headcount Equation

The industry framing around dual-standard compliance tends toward two positions: either suppliers need significantly more safety engineers, or tooling will solve the problem. Neither is fully accurate.

Suppliers that have successfully contained headcount growth while expanding dual-standard compliance programs share a consistent pattern: they invested early in shared infrastructure and paid the process restructuring cost upfront. Suppliers that deferred that investment—maintaining separate DOORS hierarchies for ISO 26262 and SOTIF, staffing separate teams, and planning to reconcile at milestone gates—are now facing either chronic audit findings or chronic overtime.

The arithmetic is not complicated. If maintaining traceability across two standards requires 30% more documentation review effort per requirement change, and a complex ADAS program processes hundreds of requirement changes across the development cycle, the cumulative labor is enormous. If shared infrastructure and automated cross-reference checks reduce that per-change overhead to 10%, the program economics look completely different.

The restructuring cost is real. Migrating from document-based to model-based traceability mid-program is painful. Starting a program with the right architecture requires upfront investment in toolchain selection and process design that many supplier organizations, under pressure to respond quickly to OEM RFQs, defer.

Honest Assessment

The dual-standard compliance burden for ADAS and AD suppliers is real, is growing, and is not going away. ISO 26262 revision discussions continue to expand scope. Regulatory pressure around SOTIF compliance is increasing in Europe and beginning to appear in US NHTSA guidance. OEM evidence requests will continue to shift earlier in development cycles as vehicle software complexity increases.

The suppliers who will manage this without unsustainable headcount growth are those treating safety traceability as engineering infrastructure rather than documentation overhead—building it into how requirements are created, changed, and reviewed, rather than assembling it before audits.

That requires organizational restructuring, toolchain investment, and the willingness to absorb upfront process change costs. It also requires honest assessment of whether the toolchains currently in use were designed for this problem or adapted to it. For most of the automotive supply chain, the answer is the latter—and that gap is now showing up in audit findings, compressed delivery schedules, and safety engineers working weekends before program milestones.

The tools are improving. The AI assistance is beginning to deliver on specific, bounded use cases. But the organizational decisions—shared repositories, unified object models, cross-standard traceability gates—are what determine whether improved tooling translates into sustainable compliance capability or just faster generation of the same fragile documentation.