HOW TO WRITE SAFETY GOALS FROM HARA OUTPUTS

Safety goals are the bridge between HARA and the rest of the ISO 26262 safety lifecycle. They express the top-level safety intent needed to avoid unreasonable risk from a hazardous event. If the HARA identifies what can go wrong and how serious it can become, the safety goal defines what the item must achieve to control that risk.

A good safety goal is specific enough to guide engineering work, but abstract enough to avoid prematurely choosing a design solution. It should be traceable to one or more hazardous events, inherit the appropriate ASIL, and create a clear path toward functional safety requirements.

Start from the hazardous event

Begin by reading the hazardous event, not only the hazard label. The malfunctioning behavior, operational situation, and consequence all matter. A safety goal based on "loss of braking support" will be weak if it ignores whether the scenario involves low-speed parking, highway driving, or emergency braking.

The goal should address the unsafe condition in language that reviewers can challenge. For example, instead of "braking shall be safe," a stronger goal might focus on preventing unintended loss of deceleration support in defined operating conditions. The exact wording depends on the item, but the pattern is the same: describe the safety intent, not a vague aspiration.

Keep safety goals solution-independent

A common mistake is writing the safety goal as if the architecture has already been chosen. Safety goals should not usually specify a diagnostic mechanism, software monitor, redundancy pattern, or hardware implementation. Those choices belong later in the functional safety concept and technical safety concept.

Solution-independent wording gives the engineering team room to explore architectures while preserving the safety intent. It also makes later changes easier because the top-level goal does not collapse every implementation decision into the HARA output.

Make the inherited ASIL visible

Safety goals inherit ASIL from the hazardous events they address. When multiple hazardous events map to the same safety goal, the goal generally needs to reflect the highest relevant integrity level. This is a traceability issue as much as a rating issue: reviewers need to see which HARA rows influenced the goal and why the ASIL is appropriate.

Aegis SafeForge helps preserve that chain by connecting HARA rows, safety goals, review state, and downstream requirements in one workflow. AI may assist with drafting candidate wording, but the approval decision remains with the engineering team.

Use verbs that create engineering obligations

Strong safety goals use clear verbs such as prevent, maintain, limit, detect, transition, alert, or control. Weak goals often use generic words such as support, ensure safety, or avoid problems without explaining the required safety behavior. The verb should make the required intent testable later, even if detailed verification criteria are defined downstream.

Checklist for reviewing safety goals

How this fits the HARA cluster

This article supports our Complete Guide to HARA for ISO 26262. Read it together with the guides on ASIL decomposition, traceability, and safety cases to understand how a HARA output becomes a defensible safety argument.