The ISO 26262 standard mandates complete, consistent, and demonstrable traceability across the automotive development lifecycle. Every safety requirement must be linked to hazards, safety goals, design specifications, and verification results. Yet, for an OEM managing a network of suppliers, keeping these chains intact is sometimes one of the most difficult compliance tasks. Each supplier typically uses its own engineering tools, follows its own process, and delivers documentation in different formats. If traceability is not managed systematically, the result is unfortunately predictable: broken links between requirements and tests, inconsistent deliverables, and the impossibility of demonstrating evidence during audits. These gaps not only jeopardize compliance risks, but they also create costly rework and project delays.
This article provides a first structured look at how OEMs and Tier 1 suppliers can establish and maintain traceability across their supply chain in line with ISO 26262 expectations. It presents a practical, step-by-step framework combining examples of rigorous processes and best practices with the right level of tool support.
ISO 26262 is the international standard for Functional Safety in Road Vehicles. It provides a framework for identifying and reducing the risks of failures in electrical and electronic (E/E) systems across the whole safety lifecycle, from concept and design to validation, production, and operation.
This standard introduces ASILs (Automotive Safety Integrity Levels), which classify the risk associated with potential hazards based on severity, exposure, and controllability. ASIL levels range from A (lowest safety requirement) to D (highest). Each level defines the necessary rigor for requirement definition, design, implementation, and verification.
ISO 26262 comes from the generic functional safety standard IEC 61508, adapted specifically for the automotive industry to address the increasing complexity of electronic and software-based systems. The first edition was published in 2011, and the current 2018 edition expanded the scope to include trucks, buses, semiconductors, and motorcycles, and reflects the rapid evolution of vehicle technology and supply chains.
ISO 26262:2018 is organized into 12 parts (10 normative and 2 informative), each covering a distinct phase or process of the automotive safety lifecycle. Within each part, numbered clauses define detailed objectives and requirements.
Fig. 1 – ISO 26262:2018 parts and their role in traceability
ISO 26262 structures the automotive safety lifecycle around the relationship between development activities and their corresponding verification and validation tasks. This relationship is commonly represented through the “W” Model (See Fig. 2), which reflects the logical sequence of work products defined across the standard parts.
This mirrored structure highlights ISO 26262’s core principle: maintaining bidirectional traceability between safety goals, requirements, design elements, and verification results. It ensures that every safety requirement can be traced forward to its implementation and backward to its origin, providing a clear audit path throughout the lifecycle.
Fig. 2 – The ISO 26262:2018 “W” Model (Source: ISO/FDIS)
Maintaining end-to-end traceability across complex automotive supply chains presents several recurring challenges for both OEMs and their suppliers. Compliance with the ISO 26262 standard requires not only the establishment of traceability links but also continuous validation and synchronization across multiple tools, domains, and organizations.
Engineering teams often work with a mix of MBSE, ALM, and PLM tools that are not natively interoperable. This fragmentation makes it difficult to maintain consistent and up-to-date traceability links. Solutions include using cross-tool linking approaches based on open integration standards like Linked Data and OSLC or adopting link management platforms that enable federated data exchange, without forcing teams to leave their preferred tools.
Even when traceability is established, ensuring the ongoing validity of those links is a persistent challenge. Changes to requirements, architectures, or test cases can quickly render trace links obsolete. Automated link-validation mechanisms and change-impact analysis capabilities can help point out and correct inconsistencies early in the lifecycle.
Aligning OEM-level requirements with supplier system specifications is critical for compliance. Yet, this process often involves interpreting large volumes of technical data and documentation. AI-assisted tools can support this effort by suggesting potential relationships between and accelerating link creation. However, the ultimate accountability for maintaining accurate traceability remains in the human hands of engineering teams.
Addressing these challenges requires a structured, repeatable approach combining process discipline with robust interoperability, lifecycle consistency, and traceability assurance capabilities. The following steps outline how OEMs and suppliers can establish and maintain ISO 26262-compliant traceability throughout the entire development lifecycle.
The first thing to do is to decide what must be traced. Interpreting Clause 6 of ISO 26262-2 :2018 (Assessment Scope), traceability should be established from the very beginning of the safety lifecycle, ensuring that requirements management and bidirectional trace links are in place from project initiation. In parallel, ISO 26262-8:2018 (Supporting Processes), Clause 6 requires that all safety-related work products be identified, versioned, and controlled under a defined configuration management process.
In practice, this implies that every project must begin by defining the scope of traceability, identifying which artifacts are safety-relevant, and how they connect. This includes mapping OEM-level safety goals down to supplier functional and technical safety requirements, and further to the test cases that verify them.
Defining the scope at project kickoff prevents ambiguity later. OEMs and suppliers should agree on which artifacts must be linked, the level of granularity (for example, requirement-to-test case or requirement-to-model element), and the formats or exchange mechanisms to be used. Documenting this in a traceability policy or visual flow diagrams, showing how OEM safety goals relate to Tier 1 and Tier 2 deliverables, makes expectations explicit and reduces interpretation risks during audits.
Even with scopes defined, misalignment between OEMs and suppliers can still create compliance gaps. ISO 26262-2:2018, Clause 6 (Management of Safety Activities) requires clear assignment of roles, responsibilities, and work-product ownership. Meanwhile, ISO 26262-8:2018, Clause 5 (Documentation) specifies documentation rules for all safety-related activities.
To satisfy these expectations, OEMs should align with suppliers on traceability standards, deliverables, and ownership boundaries. This involves defining deliverable templates for safety plans, requirements specifications, and verification reports, and ensuring each supplier knows which work products they are responsible for maintaining. It includes explicit traceability clauses in supplier contracts, covering deliverable format, link completeness, and review cadence, which helps formalize these expectations.
An internal “traceability alignment checklist” that captures these agreements can also serve as a practical reference during project execution and audits.
Suppliers rarely use the same tools as the OEM. Some rely on IBM DOORS Next for requirements, others on Siemens Polarion, Cameo, or IBM Rhapsody for modeling, or even spreadsheets for test tracking. Left unconnected and separated, these silos ineluctably break the traceability toolchain.
ISO 26262-8:2018, Clause 11 (Tool Qualification), requires that tools used for safety-related development are qualified to ensure they do not introduce or fail to detect errors. Although the standard does not prescribe specific integration mechanisms, consistent traceability across distributed environments is an implied compliance need. And one of the most effective approaches is to rely on open interoperability standards, grounded in Linked Data principles.
Linked Data provides a standardized way to describe and reference engineering information across tools using web-based identifiers (URIs). Instead of exchanging static files, each requirement, model, or test case can be linked through semantic relationships that express meaning, such as “verified by”, “implemented by”, or “satisfies”.
OSLC (Open Services for Lifecycle Collaboration) builds on Linked Data principles to connect heterogeneous tools while preserving context and maintaining consistency. In practice, OSLC links enable live, bidirectional traceability between systems like IBM DOORS Next, Cameo, and IBM Rhapsody, without duplicating data.
For ISO 26262 compliance, these connections must remain valid and verifiable. IBM’s Engineering Lifecycle Management (ELM) suite supports this with a validity service that monitors link consistency after changes and the Jazz Reporting Service (JRS) that generates traceability and coverage reports as audit evidence. Together, they ensure trace links are accurate, current, and demonstrable.
By decoupling engineering data from tool constraints, OSLC and Linked Data principles enable OEMs and suppliers to maintain an integrated, auditable traceability network across organizational boundaries.
Link management tools maintain links across client tools within a centralized link repository. For teams working across diverse or legacy toolchains, these collaborative platforms can extend interoperability beyond OSLC. These solutions can connect document-based and non-OSLC tools while staying compatible with OSLC ecosystems, ensuring a continuous and verifiable traceability chain throughout the development lifecycle.
Even when traceability links are established, their validity must be checked. ISO 26262-8:2018, Clause 9 (Confirmation Measures) requires confirmation reviews and functional-safety audits to verify the adequacy and completeness of safety-related work products. Clause 6 (Change Management) requires that modifications preserve consistency and traceability among those work products.
Automation supports these objectives by detecting missing, outdated, or inconsistent trace links early. Manual checks alone carry their share of risks and errors, especially in a multi-supplier environment. Regular scans can reveal missing links, broken relationships, orphaned artifacts, or misaligned requirement chains before they propagate into later phases.
IBM Jazz Reporting Service (JRS), which we have already mentioned, can generate and schedule traceability and coverage reports to reveal missing or outdated relationships. For instance, it can be requirements without linked test cases or associated design elements. These reports provide transparency and support confirmation reviews without requiring manual data collection.
Structuring reporting with controlled human verification creates an early-warning system that detects traceability issues before confirmation reviews. It results in greater consistency, fewer surprises during audits, and a more reliable demonstration of compliance across the project lifecycle.
Traceability must remain consistent as requirements evolve and designs change. Yet, suppliers must keep the pace. As seen in previous sections, ISO 26262-8:2018, Clause 6 requires controlled management of safety-related changes. Clause 9 mandates confirmation reviews after major updates.
Without a strong and effective collaboration chain among OEMs and suppliers, a single change can disrupt entire trace chains. When a requirement is modified at the OEM level, suppliers must see and confirm its impact before implementation. Using a shared environment supports that workflow.
Platforms that enable collaborative reviews, for example, by displaying linked requirements, design elements, and test results in one view, guide teams to assess impact quickly and maintain trace integrity. This approach ensures that updates stay synchronized across suppliers and that each modification is documented, reviewed, and verified before closure.
Before functional-safety audits or formal release, compliance evidence must be demonstrated. ISO 26262-2:2018, Clause 6.4.8 (Safety Case) requires a safety case compiling all evidence of compliance. And as already explained, ISO 26262-8:2018, Clause 9 calls for mandates confirmation reviews, but also functional-safety audits, and assessments to verify that the safety case and its supporting evidence are complete and compliant.
Automated reporting tools can assemble this evidence directly from engineering data, mapping each requirement, design, and test to the relevant ISO 26262 clauses. For example, centralized platforms that aggregate cross-domain information enable engineering teams to visualize end-to-end traceability and generate up-to-date traceability and coverage reports.
The result is an audit-ready evidence package that is consistent, traceable, and reproducible. Instead of scrambling to collect documents at the end, teams deliver structured proof of compliance, reducing effort and increasing auditor confidence.
The Role of AI in Traceability WorkflowsAI-based assistance is now being explored in engineering workflows, including requirements analysis and model consistency checks. However, its role in safety-related development must remain carefully defined. For instance, under ISO 26262, AI cannot perform or replace validation activities, nor can it be relied upon to certify completeness or correctness of safety evidence. What AI assistants can actually do is analyze engineering data and suggest possible trace relationships between requirements, design elements, and test cases based on the information available in the engineering environment, or even highlight inconsistencies. These suggestions help engineers during initial trace link creation or when reviewing large sets of requirements, models, or test artifacts. It helps teams focus their effort on where it is most needed, especially in multi-supplier environments. All AI-suggested links must be reviewed, confirmed, and approved by engineers using, for instance, established change review processes or collaborative team review environments. AI acts only as a background helper, never as a decision maker. And used this way, AI is a real support for engineering efficiency, without altering the formal responsibilities, human oversight, or evidence expectations defined by the ISO 26262 standard. |
Maintaining Traceability across multiple suppliers is not a smooth ride, but it becomes fully manageable when processes and engineering data are aligned and controlled consistently across the entire safety lifecycle. ISO 26262 not only requires the establishment of traceability links, but it also requires that they remain accurate, up-to-date, and demonstrable throughout development.
When organizations approach traceability as an ongoing engineering practice (not to say a discipline), rather than a series of tasks addressed at the final stages of development, where it’s just about passing audits, teams reduce late surprises. They make better-informed decisions and build safety evidence steadily and with confidence as the project evolves.
For OEMs and Tier 1 suppliers, this mindset is essential. It is what enables predictable programs, reliable collaboration, and safer vehicles on the road...
Maintaining end-to-end traceability requires both process know-how and the right technology, at the right time. SodiusWillert combines deep expertise in model-based systems engineering with solutions that connect and align your toolchain
Our OSLC Connectors create live, standards-based links between engineering tools, enabling real-time visibility and traceability across requirements, design, and test environments.
Our SECollab platform plays a key role in maintaining traceability across tools that do not support OSLC natively. It supports a broader range of engineering environments, enabling the creation and management of trace links between systems that would otherwise remain disconnected. SECollab can also generate traceability and coverage reports that serve as auditable evidence for ISO 26262 compliance.
Beyond traceability, SECollab centralizes model and document reviews, providing a unified, web-based workspace where teams and suppliers can review, comment, and validate engineering data collaboratively.
For decades, SodiusWillert has been a trusted expert in the IBM Engineering Lifecycle Management (ELM) suite, supporting OEMs and suppliers in meeting ISO 26262 traceability requirements. IBM Jazz Reporting Service (JRS) within IBM ELM provides automated reports on the traceability and coverage of requirements throughout the lifecycle. This enables teams to check completeness and prepare evidence for audits.
IBM DOORS Next provides a rigorous environment for capturing and managing safety requirements, maintaining bidirectional trace links, generating traceability reports, and supporting structured reviews.
IBM Rhapsody enables model-based systems design aligned with those requirements, ensuring that architecture and implementation stay consistent with defined safety goals. Rhapsody also supports the RAAML (Reliability Analysis and Assessment Modeling Language) profile, allowing engineers to model safety analyses such as FMEA and FTA and trace these analyses back to the originating safety requirements.