Most ISO 26262 Projects Are Modifications. Treat Them That Way.

Very few safety engineers start from a blank item. The usual project is last year's drive unit, brake system or steering controller with something added, taken out or moved to another vehicle. ISO 26262 expects this. Before any planning, ISO 26262-2:2018, Clause 6 asks for an impact analysis at item level that decides whether the item is new, modified, or unchanged in a modified environment. The safety plan post covered that fork. This one is about what comes after it when the answer is "modified": deciding how much of the old safety evidence still counts.

That decision is where modification projects are won or lost. Reuse too little and the project pays for a development it did not need. Reuse too much and the safety case argues about a vehicle that no longer exists.

What the standard asks

For a modified item, the clause asks the team to describe what changed in the design, in the implementation and in the environment, then to evaluate what that means for functional safety and name the safety activities that follow. Two details are worth reading slowly. A new operating mode or new calibration data counts as a design modification, not as a parameter tweak. And every activity the team decides not to repeat is tailoring, which needs a rationale in the safety plan that someone independent will read.

Changes that come up later, during development, go through change management under ISO 26262-8:2018, Clause 8. The reasoning about evidence is the same.

A small change to a drive unit

Take the electric drive unit of a production car: inverter, motor, and the software that turns the accelerator pedal into a torque request. Its safety case covers unintended acceleration. For the next model year, product management wants one-pedal driving. With the old calibration, lifting off the pedal gave a gentle coast with about 0.05 g of regenerative drag. In the new mode it gives up to 0.2 g, enough to stop the car in traffic without touching the brake pedal.

The software change is small: a mode switch and a new region of the torque map, about 150 lines. Nobody touches the inverter, the motor or the current control.

Evidence rests on premises

Every piece of evidence in the old safety case was produced under premises. A few are written down, most are not. The useful way to run the impact analysis is to ask, for each piece, what it assumed, and then hold those assumptions against the change. How close the evidence sits to the changed code is a much weaker guide.

For the drive unit, one premise breaks: that releasing the pedal is harmless. Three pieces of evidence rested on it.

The hazard analysis had looked at unintended deceleration at 0.05 g and found nothing that needed an ASIL. Strong braking that the driver did not ask for, at motorway speed with traffic behind, is a different hazardous event. It has to be rated, and it may well produce a new safety goal.

The hardware analysis of the pedal sensor path had classified "pedal signal reads zero" as a safe fault, because with the old map it only removed torque. Under the new map the same failure brakes the car. Not one component on that path changed, yet its analysis has to be redone, and the hardware metrics, which are evaluated per safety goal under ISO 26262-5:2018, Clause 8, do not exist yet for the new goal.

The software integration tests of the torque request path are partly stale, because the path now contains a mode it did not have.

The rest still counts. The inverter hardware metrics were computed for unintended acceleration, on hardware that did not change. The current control unit tests ran on unit code and a tool chain that did not change. The vehicle tests for unintended acceleration still address the same safety goal on the same vehicle. Each can be reused with a short rationale that names the premise still holding.

Lines of code are a poor guide

Now compare a second change to the same drive unit: a rewrite of the diagnostic event memory, about 4,000 lines, running in a QM partition. By diff size it is the bigger change by a factor of more than twenty. By effect on the safety case it is far smaller. The partitioning argument and the integration tests have to be checked again, and nothing else moves, because none of the safety evidence assumed anything about how the event memory works.

This is why a reuse decision taken from the change request alone tends to go wrong in both directions. The one-pedal mode looks like a calibration job and reopens the hazard analysis. The rewrite looks like a project and leaves the hazard analysis, the safety concepts and the hardware evidence where they were.

A rationale that survives review

The impact analysis at item level gets its own confirmation review, by someone independent of its author and of project management, so every reuse decision in it will be read by a person who did not make it. A rationale that only says "unchanged" will not convince that reader. One that names the premise each piece of evidence rested on, and shows why the change leaves it intact, will. It also tells the team that handles the next modification where to look first.

The Change Impact Analysis concept page covers the full method at item and element level, how carried-over elements and their assumptions are re-validated, how changes are classified and re-verified, the configuration baselines that make the analysis possible, a complete worked example of a sensor change, and a review checklist for impact analysis reports.