Title: Product Lines and Variant Safety | ISO 26262 Academy URL: https://iso26262.academy/features/concepts/product-line-variant-safety Description: Keeping ISO 26262 evidence valid across a family of vehicles: variability models a safety argument can trust, family HARA scope, feature interaction screening, Annex C configuration and calibration data, constraints that make unsafe configurations unbuildable, and a modular safety case. --- Concept guide · ISO 26262-6 Annex C + Part 8 · 13 chapters # 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. 13 Chapters 6 Sources of variability 5 Binding times 4 Enforcement gates Included in Expert [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fproduct-line-variant-safety&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters Inside the course 1. 01 **One Vehicle Is Many Vehicles** 2. 02 **What ISO 26262 Says About Variants** 3. 03 **Modeling Variability** 4. 04 **Variants in the HARA** 5. 05 **Feature Interactions** The short version ## 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. Keep going, free - [Demo exam · no account Test yourself with 7 exam-style questions](https://iso26262.academy/demo-exam) Why this course · ISO 26262, Part 6 ## 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. After the course ## 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. The curriculum · 13 chapters ## Chapter by chapter 1. 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 2. 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 3. 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 4. 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 5. 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 6. 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 7. 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 8. 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 9. 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. 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. 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. 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. 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 Built for ## 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 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. ## 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. [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fproduct-line-variant-safety&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing)