Product Lines and Variant Safety
ISO 26262 governs one item; production ships a family. Learn how to describe variability precisely, decide what is shared and what is variant-specific, and release evidence that covers every member instead of one idealized specimen.
- Chapters
- 13
- Chapters
- Sources of variability
- 6
- Sources of variability
- Binding times
- 5
- Binding times
- Enforcement gates
- 4
- Enforcement gates
Quick answers
- Does ISO 26262 have requirements for product lines and variants?
- 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.
- What is the difference between configuration data and calibration data under Annex C?
- 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.
Why it pays for itself
Close the gap the standard leaves open
ISO 26262 regulates a lifecycle for one item and never says how to run it for a family. This guide names the mechanisms that do carry the weight, states exactly where each one stops, and keeps normative obligations visibly separate from product-line method.
Stop paying for variants linearly
Analyses annotated once and derived per member, work products sorted into platform, annotated and generated, and a where-used query that answers which members a change reaches: the cost of the next variant becomes proportional to what actually differs.
Argue coverage instead of hoping for it
Applicability conditions in the HARA, constraints compiled from safety findings, configuration proofs run on every model release and enforcement at four gates turn "we believe that combination cannot be ordered" into a claim a reviewer can test.
What you’ll be able to do
Build a Variability Model Safety Can Use
Separate problem space from solution space, express variation points and constraints precisely, and put the model under configuration and change management with a named owner.
Scope a Family HARA Honestly
Write applicability conditions per hazardous event, record why the claimed worst case bounds every other member, and recognize which variant changes re-open the analysis.
Screen Feature Interactions Systematically
Run a guideword screen over safety-relevant feature pairs, close each pair with a defined verdict, and escalate to higher-order groups where architecture and hazards justify it.
Apply Annex C to Configuration and Calibration Data
Assign the correct ASIL rule per data type, specify valid values with their interdependencies, verify each released set, and select data-integrity measures for the field.
Make Unsafe Configurations Unbuildable
Compile safety findings into constraints with rationales, run configuration proofs on every model release, and enforce one rule source across order, build, plant coding and runtime checks.
Scope Change and Regression by Computation
Use presence annotations and traceability to answer which members a change reaches, then size regression and re-validation to that answer instead of to fear or to a deadline.
Chapter by chapter
- 01
One Vehicle Is Many Vehicles
Why the singular grammar of the standard collides with plural production, the six directions variability enters from, and the arithmetic that kills every naive coverage promise before it is made.
- Six sources of variability
- Configuration arithmetic
- The clone-and-own default
- 02
What ISO 26262 Says About Variants
There is no product line clause. Instead there are load-bearing mechanisms across Parts 2, 3, 6, 7 and 8, each with a precise limit, and a habit of reading every work product family-first.
- What each mechanism gives and where it stops
- Obligations versus methods
- Five questions to be ready for
- 03
Modeling Variability
Why an option catalog cannot carry a safety argument, what a feature model with cross-tree constraints adds, how the 150 percent representation works, and why binding time changes the shape of the argument owed.
- Problem space versus solution space
- 150 percent models and pruning
- Five binding times
- 04
Variants in the HARA
Configuration reaches severity, exposure and controllability through three separate doors, and can remove hazardous events entirely. Covers family scope, coverage rationales and the triggers that re-open the analysis.
- Exposure is not sales frequency
- Worst case per event, not per variant
- Six re-open triggers
- 05
Feature Interactions
The blind spot built into per-feature engineering: behavior that exists only when two options meet, first co-occurring on an order sheet rather than a test plan. A pairwise screen with guidewords and defined verdicts.
- Five interaction mechanisms
- Pairwise screen with verdicts
- Design it away, constrain it, or bound it
- 06
Configurable Software and Calibration
The most explicit treatment of software variation in the standard, ISO 26262-6 Annex C: three distinct objects, two different ASIL rules, specification duties including interdependencies, and field data integrity.
- Configuration data versus calibration data
- Specification with interdependencies
- Table C.1 integrity measures
- 07
Valid and Forbidden Configurations
Compiling safety findings into constraints on the variability model, proving properties of a set too large to enumerate, and enforcing the same rule source from the order system down to runtime plausibility.
- Constraints with rationale and owner
- Recurring proof obligations
- Four gates, one model release
- 08
Variant-Aware Safety Analysis
Annotate the analysis once over the superset design, then derive per member. Fault trees change shape and not just numbers, FMEA rows become conditional, and independence claims acquire a configuration scope.
- Cut sets move when you prune
- Conditional FMEA rows
- Metrics across hardware alternatives
- 09
Work Products and the Modular Safety Case
Three homes for every artifact (platform, annotated, generated), an argument split into platform modules, a configuration-validity module and thin per-variant binding modules, joined by explicit safety contracts.
- Platform, annotated, generated
- The configuration-validity hinge
- Guarantee and assumption pairs
- 10
Change Impact Across the Family
Change management gains a second axis: which members does this reach? The where-used query answers it from models rather than meetings, and baselines make a released member a real, reproducible object.
- The three-hop where-used query
- Overshoot and undershoot
- Why deleting a rule is the dangerous change
- 11
Testing and Release Across Variants
Four different questions hide inside asking whether it was tested. Covers reusable platform evidence, per-set data evidence, interaction coverage over the valid set, and per-member release criteria.
- Covering arrays over valid configurations
- Which physical vehicles earn a prototype
- Per-member release checks
- 12
Worked Example: A Parking Assist Family
The whole page assembled on one teaching family: three members, one feature model, one family HARA, the interaction screen, the constraint set, the derived analyses, the modular case and a release board.
- One thread through every chapter
- A release board frozen mid-program
- A second radar source, priced by query
- 13
Pitfalls, Checklist and Outlook
Ten recurring failure modes of variant-rich programs, a ten-point self-check to run before an assessor does, and why software-defined vehicles and ECU consolidation raise the pressure rather than relieve it.
- Ten failure modes
- Ten-point self-check
- Later binding, higher stakes
Who this guide is for
- Safety managers whose safety case has to cover an option and market matrix, not one specimen
- Engineers writing family HARAs and deciding whether the family is one item or several
- Calibration and configuration owners bringing data sets under ISO 26262-6 Annex C
- Architects maintaining platform elements consumed by several vehicle lines
- Assessors and reviewers asking which exact set of variants a safety case claims
- Change and configuration managers scoping impact across a released family
Frequently Asked Questions
Common questions about Product Lines and Variant Safety
Start the course today
A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required.