Product Lines and Variant Safety

Not as a dedicated clause. The standard regulates a lifecycle for a defined item and leaves it to engineering method to run that lifecycle efficiently across a family. What it does provide are mechanisms that carry the weight: the item definition as the anchor for scope, HARA obligations that configuration can shift, ISO 26262-6 Annex C for configurable software and data, configuration management and change management in Part 8, verification of configurations, SEooC provisions, and the release for production decision. The guide works through each one, what it gives and where it stops, so a program neither invents obligations the standard never stated nor assumes a problem is solved that the standard has only named.

They are separated because they fail differently and because their ASIL rules differ. Configuration data selects or structures behavior, for example feature activation or resource sizing, and it takes the highest ASIL of the configurable software to which it is applied. Calibration data supplies values used to achieve the intended operation and performance, for example thresholds, curves and controller gains, and it takes the highest ASIL of a software safety requirement it can violate. Wrong configuration data tends to produce the wrong software; wrong calibration data produces the wrong physics. Both need a specification covering valid values, intent, ranges, units and, the ingredient programs most often skip, interdependencies within and across sets.

It depends on what changed, and the guide gives review triggers rather than a rule the standard does not contain. Changed actuation authority, a changed user or supervision situation, a changed vehicle dynamics class, a changed operating environment and new feature combinations normally re-open something, sometimes hazard identification itself and not only the classification. A pure implementation substitution with identical function, performance, interfaces and installation typically leaves the HARA standing, with the impact landing in the safety analyses and evidence instead, provided that rationale is recorded. One point the guide is firm about: the take rate of an option is not a discount on exposure, because exposure concerns how often the operational situation occurs for a vehicle equipped with the item.

No, and the guide is explicit about the limits. Interaction coverage complements boundary, requirement-based and risk-based selection; it does not replace them. A covering array must be generated over the valid set so that every selected configuration can actually be built, strength must be escalated deliberately according to hazards, architecture and past faults rather than treating pairwise as a universal minimum, and the resulting claim has to be stated precisely: a green campaign shows the selected tests exercised every feasible two-way value combination for the modeled factors. It is not evidence that all configurations were tested, and adequacy still depends on oracles, inputs, timing, states and environment.

Thirteen chapters: why one vehicle is many vehicles and where variability comes from; what ISO 26262 does and does not say about variants; modeling variability with feature models, superset representations and binding times; variants in the HARA; feature interactions and how to screen them; configurable software and calibration under Part 6 Annex C; defining, proving and enforcing the valid configuration set; variant-aware fault trees, FMEA, dependent-failure analysis and hardware metrics; work products and the modular safety case with contracts; change impact across the family; testing and release per member; a worked parking assist family that threads the whole page together; and a pitfalls chapter with a ten-point self-check.