A Hazard Analysis and Risk Assessment (HARA), as defined in ISO 26262, is structurally identical to an FMEA: you identify what can go wrong, assess the risk, and define what must be done about it. In KF, both are modeled with the same primitives — items, events, and actions. No special mode or separate workflow is needed for HARA.

Mapping HARA concepts to KF

ISO 26262 concept	KF element
Item (system under analysis)	`Item`
Hazardous event	`Event` on the item, with ASIL rating
Safety goal	`Action` on the hazardous event
Safe state	Child `Action` of the safety goal
Functional safety requirement	Child `Action` of the safety goal or safe state

The ASIL rating (A–D, or QM) is an attribute of the `Event`, which is where it belongs: ASIL is determined by the hazard's severity, exposure, and controllability — properties of the hazardous situation, not of the response.

Building a HARA in KF, step by step

1. Define the item

Create an `Item` representing the system or subsystem being analyzed — for example, Electric power steering unit.

2. Add hazardous events

For each hazardous event identified in the HARA, create an `Event` on the item. Set the ASIL rating as an event attribute.

Example:

• Event: Loss of steering assist at highway speed
• ASIL: C

KF calculates the corresponding ASIL level when ISO 26262 severity, exposure and controllability are used in the event risk fields:

• Severity: S1 to S3. Field in KF: Severity
• Exposure: E1 to E4. Field in KF: Ocurrence / Likelihood
• Controllability: C1 to C4. Field in KF: Detection / Controllability

The risk matrix used for that event is then the ASIL table from ISO 26262.

3. Define the safety goal

Create an `Action` on the hazardous event. This is the safety goal — the top-level required response to the hazard.

Example:

• Action: Ensure controlled reduction of steering assist force upon failure detection

4. Define safe states as child actions

A safety goal is satisfied by reaching a safe state. Add child `Actions` to the safety goal representing the safe state or states.

Example:

• Child action: Reduce assist torque to zero within 200 ms of fault detection

If multiple safe states are candidates, use the alternate edge (see below).

5. Decompose further as needed

Each safe state action can have its own child actions representing functional safety requirements, diagnostic measures, or verification steps. The tree grows exactly as it would in an FMEA.

Using alternate edges for safety goals and requirements

In standard KF, a parent action is complete when all its child actions are complete (AND semantics). This is sufficient for safe states and verification steps that must all be achieved.

For requirements and design decisions, a second composition mode is available: the alternate edge.

How it works

When the edge from a parent action to a child action carries the attribute `alternate`, the parent is complete when any one of the alternate children is complete. This models a solution space: multiple implementation candidates exist, and one must be chosen and realized.

When a decision is made, mark the chosen child with `accepted` and the rejected alternatives with `rejected`. The rejected alternatives are preserved — not deleted — so the design rationale remains traceable.

Example

Safety goal: Ensure controlled reduction of steering assist upon failure

Alternate child actions (role=alternate):

• Reduce assist torque linearly over 200 ms — accepted
• Switch to reduced fixed-gain manual mode — rejected
• Apply regenerative braking to slow vehicle before assist loss — rejected

The safety goal is satisfied when the selected implementation is complete and verified.

Requirements as actions

In KF, a requirement is modeled as an `Action` — optionally labeled requirement — rather than as a separate element type. This is a deliberate design choice, not a simplification.

The reasoning is as follows.

A requirement that cannot be expressed as something an agent must do or ensure is underspecified. "The system shall not cause unintended acceleration" only has engineering value when it is translated into something designable, implementable, and testable. The requirement is the obligation to act; the SHALL is the compliance marker.

Modeling requirements as actions has a direct consequence: compliance is just task completion. A requirement is met when its action — or one of its alternate child actions — is complete and ticked off. No separate compliance tracking mechanism is needed. The same OK tick that closes a corrective action in an FMEA closes a requirement in a HARA.

The alternate edge is what makes this formally correct. Without it, a requirement-as-action implies a single predetermined implementation, which confuses the requirement (what must be true) with the solution (what is done to make it true). With alternate edges, the requirement action holds the solution space open until a design decision is made — at which point one alternative is selected, the rest are retained as rejected candidates, and the requirement is closed by the chosen implementation.

This model covers the full lifecycle: requirement stated → alternatives explored → decision made and recorded → implementation verified → requirement closed.