This is not document sharing. It is a structured data model: the item's functions, interfaces, operating conditions, and assumed users are defined once as structured fields. When any downstream analysis references an item function — "emergency braking" — it is referencing the same data object, not a copied description in a separate document.

The practical consequence: when "emergency braking" is updated — a new triggering condition is added, a new interface is defined — every downstream work product that references it is automatically flagged for review. The engineer sees a prioritized list: HARA Hazardous Event HE-07 references this function, TARA Damage Scenario DS-03 references this function, SOTIF Triggering Condition TC-12 references this function. The change impact is explicit before any document is updated.

The HARA Workflow

The HARA module follows ISO 26262-3 Clause 7 directly. Engineers enter hazardous events with structured severity (S0–S3), exposure (E0–E4), and controllability (C0–C3) ratings. ASIL calculation is automatic and displays immediately as ratings are entered.

What distinguishes the ISO WIZ HARA from a spreadsheet:

  • Safety goal derivation is linked, not copied. Safety goals derived from hazardous events are stored as child objects of the hazardous event. A change to the hazardous event description propagates a review flag to all derived safety goals.
  • FTTI is a structured field. The Fault Tolerant Time Interval is entered as a data field with unit. It is referenced automatically by the safety architecture module when evaluating whether proposed safety mechanisms can respond within the required window.
  • Cross-standard flags are automatic. When a hazardous event is marked as potentially reachable via cyberattack, the system creates a draft TARA damage scenario entry linked to that hazardous event, with the severity pre-populated from the HARA S-rating.

The TARA Workflow

The TARA module implements the ISO 21434 Clause 15 process. Threat scenarios are created from the asset list; attack paths are modeled with feasibility ratings using the CVSS-derived methodology. CAL assignment is automatic from the impact and feasibility ratings.

This bidirectional link is what makes co-engineering tractable. In separate tools, the link exists only in documentation. In ISO WIZ, it is an enforced data relationship.

The SOTIF Module

SOTIF analysis is structured around the four-quadrant model from ISO 21448 Clause 8: known safe, known unsafe, unknown unsafe (residual risk), and unknown safe. Engineers identify triggering conditions — the specific operational scenarios where the system's intended functionality may produce unsafe outcomes — and map them to the applicable functional insufficiency.

The SOTIF module connects to the ASPICE software requirements module. A SOTIF-derived performance requirement (e.g., "object detection recall rate ≥ 99.2% under fog conditions") becomes an ASPICE SWE.1 software requirement with a linked test case in the verification plan.

Field monitoring requirements from SOTIF Clause 9 — the ongoing data collection program to detect emerging triggering conditions — are tracked as open process items with configurable review cadences.

The ASPICE Process Module

The ASPICE module tracks process capability against PAM 3.1 process areas: SYS (systems engineering), SWE (software engineering), SUP (support), and MAN (management). Each process area has a structured checklist of base practices and generic practices. Work products are linked to the process practices they satisfy.

The critical integration: ASPICE work products are not managed separately from functional safety work products. An ISO 26262 software safety requirements specification satisfies both the ISO 26262-6 requirement for a software safety requirements document and the ASPICE SWE.1 requirement for software requirements documentation. It appears in both the functional safety work product list and the ASPICE process evidence list — without duplication.

This matters because ASPICE assessors ask for evidence of process practices, and safety assessors ask for evidence of safety work products. In programs where these are managed separately, the same document gets created twice in different formats. ISO WIZ treats them as the same artifact assessed against two different frameworks.

The Gap Detection Engine

The gap detection engine runs continuously across all active work products. It looks for three categories of gaps:

Consistency gaps: A safety mechanism is claimed to achieve 99% Diagnostic Coverage, but the referenced FMEDA shows 94%. An ASIL decomposition claims independence between two channels, but the hardware architecture diagram shows them on the same power rail.

Staleness gaps: A work product references another work product that has been updated since the reference was last reviewed. The reference may still be valid, but it has not been confirmed since the referenced document changed.

Each gap surfaces as a finding with a severity rating, a description of the inconsistency, and a direct link to the work products involved. Findings are assigned to engineers and tracked to closure. The audit trail records who reviewed each finding, what action was taken, and when it was closed.

What ISO WIZ Does Not Do

It is worth being explicit. ISO WIZ is not a requirements management tool in the general sense — it is scoped to automotive safety and compliance workflows. It does not replace DOORS or Polarion for general systems requirements management. It does not replace your simulation environment for SOTIF validation data collection. It does not replace your code analysis tool for MISRA compliance.

What it does: it provides the unified traceability backbone that connects those tools to the four automotive safety standards, maintains the cross-standard links that no individual tool manages, and surfaces the gaps that emerge when standards-mandated work products are not fully linked.

For programs managing two or more of ISO 26262, SOTIF, ISO 21434, and ASPICE simultaneously — which is now nearly every ADAS, EV, and connected vehicle program — ISO WIZ eliminates the coordination overhead that would otherwise be absorbed by manual traceability maintenance, cross-team review meetings, and last-minute certification preparation.