The ISO 26262 Safety Plan: Write It to Be Used

Most safety plans that fail an assessment were not written badly. They were written once. A template was copied from the last program, the item name was replaced, dates were left as "tbd", and every activity was owned by "the safety team". Six months later it describes the program as it was imagined at kickoff, not the one being built.

ISO 26262-2:2018, Clause 6 treats the safety plan as the safety manager's working tool, not a deliverable to file. Here is what that means in practice, with one running example: a shift-by-wire gear selector that already exists on one vehicle and is now carried over to a new platform. Assume the hazard analysis on the original vehicle gave it a safety goal at ASIL C.

Start with the impact analysis, not the template

Before the first row of the plan, the standard asks one question about the item: is it a new development, a changed version of an existing item, or an unchanged item placed in a modified environment? The answer decides how much of the lifecycle you plan.

Our selector is the third case. The hardware and software are unchanged, but it now sits in a different vehicle, talks to a different powertrain controller and sees a different temperature and vibration profile. The item definition has to describe the new vehicle. The hazard analysis has to be checked against new operating situations. The interfaces, the environmental assumptions and the validation have to be redone. A lot of the hardware and software work products can be reused with a documented argument.

Every activity you drop or change on that basis is tailoring. Tailoring is allowed, and on carry-over programs it is normal. The rules are short: the tailored activity is written in the safety plan, and it comes with a rationale for why the result is still sufficient, considering the ASIL. Someone independent reads that rationale, when the plan is confirmed or at the latest during the assessment, and "reused from program X" alone will not pass.

What a planned activity actually looks like

A line that says "DFA: Q3" is a reminder, not a plan. The standard expects each activity to be planned concretely enough that someone else can check it.

For the selector, the analysis of dependent failures might read: the objective is to show that the two position sensors cannot fail together from a shared cause on the new platform; it depends on the updated environmental specification and the new harness routing; a named engineer performs it, with two weeks of effort and access to the vehicle packaging data; it finishes before the system design review; and it produces an updated DFA report. Every part of that sentence can be checked, which is exactly the point.

Name a person, not a department

The safety manager plans and coordinates the safety activities, maintains the plan, and tracks progress against it. Other people can detail parts of the planning and perform the work, but responsibility for each activity has to be assigned to someone and communicated. "Safety team" is not an assignment. When an activity slips, someone has to notice, and the plan has to tell you who.

The safety plan also has to sit inside the project's planning, either referenced from the project plan or included in it in a way that keeps the safety activities visible. A plan that lives in a separate folder, unknown to the project manager who sets the dates, is how verification windows silently disappear.

A plan that sharpens as the project moves

Nobody can plan software unit verification in detail during the concept phase, and the standard does not ask for it. It asks that the plan be updated at least at the start of each phase, with that phase planned in detail. Later phases can stay coarse.

For the selector, the first version details the concept phase work and keeps hardware and software as coarse blocks with the reuse argument noted. At the start of system development, the plan gets the interface verification against the new powertrain controller, with owners and dates. By integration, it names the vehicle tests that validate the safety goal on the new platform.

The plan is reviewed too

The safety plan is itself checked in a confirmation review by people independent of its authors, and it schedules the other confirmation measures, including the functional safety audit and assessment. How much independence each one needs depends on the ASIL. Planned late, they become a rush before start of production. And if a supplier does part of the work, the plan has to connect to the supplier's plan through a Development Interface Agreement.

The Safety Plan concept page covers the full contents of a plan and how to build its activity table, tailoring rationales that survive review and the ones that do not, monitoring and escalation while the project runs, what each confirmation measure needs at your ASIL, and a complete worked example.