Evaluating ISO 26262 tooling requires separating features that look impressive in demos from features that solve real program problems.

HARA Management: More Than a Table

Every compliance tool provides a table for recording HARA entries. The differentiator is what happens after the table is populated.

The HARA is not a one-time deliverable — it is a living analysis that must be updated whenever the system boundary changes, when new operational scenarios are identified, or when the hazard analysis reveals that severity, exposure, or controllability ratings need revision. A tool that treats HARA as a static document provides no help with the most expensive HARA activity: change impact management.

What to look for: structured severity/exposure/controllability fields with ASIL auto-calculation, versioning of individual entries (not just document versioning), and linked derivation of safety goals from hazardous events. A safety goal that is linked to its parent hazardous event as a data relationship, not a text reference, makes change impact analysis tractable.

FMEDA Integration

FMEDA is the most technically demanding work product in ISO 26262. It requires component failure rate data (typically from IEC 61709 or supplier data), diagnostic coverage estimates, SPFM/LFM calculation, and PMHF calculation against the targets from ISO 26262-5 Table 4 (PMHF < 10 FIT for ASIL D, < 100 FIT for ASIL C, etc.).

Most HARA-and-safety-plan tools do not integrate FMEDA. FMEDA is managed separately. This creates the fundamental gap: when the FMEDA shows that a hardware element does not meet its PMHF target and the safety architecture must change, the change propagates to the safety concept, the technical safety concept, and possibly back to the HARA — but in a non-integrated toolchain, none of these links are automated.

What to look for: either native FMEDA capability or documented integration with FMEDA tools. The safety concept's safety mechanism list should be linked to the FMEDA entries that validate those mechanisms.

Cross-Standard Traceability

This is the feature most underspecified in RFPs and most critical in practice. The question is not "does the tool support traceability?" — all tools do. The question is: "can the tool maintain traceability across ISO 26262 and ISO 21434 as a single linked graph?"

If the tool cannot answer "which TARA damage scenarios are linked to ASIL D hazardous events?" in a single query, it is not providing cross-standard traceability — it is providing two separate single-standard traceable tools.

Change Impact Analysis

Software safety requirements change throughout development. Hardware architectures change. HARA assumptions change as the system boundary is refined. In a spreadsheet-based compliance infrastructure, each change triggers a manual search through linked documents.

In a well-designed compliance tool, change impact analysis is a first-class feature: a change to any work product propagates flags to every downstream work product that references it, with enough context to determine whether the downstream work product is affected or can be confirmed as unaffected.

This feature prevents the most common failure mode in safety programs: a change approved in isolation that, three months later, turns out to have invalidated an assumption somewhere else in the safety case.

The Spreadsheet Ceiling

Spreadsheets are not an anti-pattern for early-stage development. A small team doing initial concept work can manage a HARA in a spreadsheet. The problem is that spreadsheets do not scale to the complexity of a production safety program.

The specific failure modes of spreadsheet-based compliance:

No enforced consistency. Nothing prevents a safety goal from being deleted from one tab without removing its references in another tab. Broken links accumulate silently.

No change history at the field level. Document version control records that a file changed. It does not record which cell changed, by whom, and why. Reconstructing the history of a specific ASIL rating decision requires reading through email chains.

No automatic impact propagation. Changing a hazardous event requires manually identifying every downstream document that references it. This is a process discipline problem, not a spreadsheet limitation — but process discipline degrades under schedule pressure.

What ISO WIZ Provides

ISO WIZ was built as a purpose-designed alternative to the spreadsheet-and-DOORS approach for programs managing automotive safety compliance.

The design philosophy: automotive safety work products are structured data, not formatted documents. A HARA entry is not a row in a spreadsheet — it is an object with defined fields (hazardous event description, operating scenario, severity rating, exposure rating, controllability rating, derived ASIL, linked safety goals, linked TARA damage scenarios) that can be queried, linked, versioned, and propagated through a change impact system.

For program managers evaluating tooling: the evaluation question is not "what features does the tool have?" It is "how does the tool behave when a safety architect changes a core assumption and you need to understand every downstream work product that may be affected?" A tool that answers that question in 30 seconds is worth significantly more than a tool that requires two weeks of manual review to answer it.

ISO WIZ is designed to answer that question in 30 seconds.