Skip to main content
Concept guide · ISO 26262-8 §8 · 10 chapters

Change Impact Analysis for Carryover & Modified Systems

Most automotive programs are brownfield. Learn how ISO 26262-2 Clause 6.4.3 and ISO 26262-8 Clause 8 keep carryover parts, variants, and facelifts safe through a disciplined six-step impact analysis that decides what must be re-verified.

Chapters
10
Chapters
Impact-Analysis Steps
6
Impact-Analysis Steps
Change Categories
7
Change Categories
Re-Verification Zones
4
Re-Verification Zones
Included inExpert
Why this course · ISO 26262, Part 2, Clause 6.4.3

Why it pays for itself

A defensible six-step method

Turn "is this change safe?" into a documented six-step impact analysis - from precise change description to approval - that tells you exactly which lifecycle activities must be repeated, updated, or validly reused.

Re-test what matters, not everything

The four-zone regression triage and ASIL-scaled justification let you scope re-verification with evidence instead of habit, avoiding both dangerous under-testing and weeks of wasteful full re-runs.

Carryover arguments that hold

Learn to validate SEooC assumptions line by line against a new context and close coverage, metrics, and evidence gaps - so reused elements enter the safety case with a defensible argument.

After the course

What you’ll be able to do

Run a six-step impact analysis

Describe a change precisely, identify and propagate to affected work products, assess safety goals, scope re-activities, and document for approval.

Classify changes and scope ripple effects

Sort any change into one of seven categories and use the required-activity matrix to predict where its effects propagate.

Validate carryover and SEooC assumptions

Check a safety manual line by line against a new context and run a structured gap analysis before reusing an element.

Define risk-based regression scope

Apply the four-zone test triage and ASIL-scaled justification to re-verify what matters without re-running everything.

Anchor analysis to controlled baselines

Set up configuration management baselines that make impact analysis defensible and prevent silent configuration drift.

Drive change requests through the workflow

Move a change from request through the change control board to re-release, assigning roles and re-triggering confirmation measures when required.

The curriculum · 10 chapters

Chapter by chapter

  1. 01

    Most Projects Are Brownfield

    Why disciplined change and impact analysis is the everyday reality of automotive safety work, since well over 70% of reused electronic control unit (ECU) software is carried over with only minor modifications.

    • Facelifts, variants, carryover parts, feature additions
    • Invisible ripple effects and the "small change" trap
    • Two mechanisms: lifecycle-initiation and change management
  2. 02

    Modifications in ISO 26262

    Where change is governed in the standard: Part 2 impact analysis at lifecycle initiation (Sections 6.4.3 and 6.4.4) versus Part 8 Clause 8 change management during and after development.

    • Clause map: Part 2, Part 8 Clause 7, 8, 14, SEooC
    • Every change request triggers analysis, no de minimis
    • Item versus element scope and upward propagation
  3. 03

    The Impact-Analysis Method

    A documented, traceable six-step process (Section 8.4.3) that determines which lifecycle activities must be repeated, partially updated, or reused after a change.

    • Six steps from precise description to approval
    • Traceability as the engine of the analysis
    • Required content and common failure modes
  4. 04

    Carryover & Reuse Arguments

    What must be re-examined when an existing element is reused in a new context, centred on validating Safety Element out of Context (SEooC) assumptions and operational design domain changes.

    • Validating SEooC assumptions against the new context
    • Operational design domain gaps that ripple up to the safety analysis of hazards and risks
    • Coverage, metrics, and evidence gap analysis
  5. 05

    Classifying Changes

    Seven change categories, each with characteristic ripple patterns, mapped through a change-type to required-activity matrix and a cascade-effect propagation model.

    • Functional, calibration, hardware, software, supplier, tool, process
    • Change-type to required-activity matrix
    • Bounding the cascade with a propagation depth limit
  6. 06

    Regression & Re-Verification

    A risk-based regression strategy that avoids both dangerous under-testing and wasteful over-testing, using a four-zone test triage and ASIL-scaled justification for evidence reuse.

    • Four zones from must re-test to not applicable
    • Regression strategy scaled by ASIL level
    • Evidence-reuse declarations backed by independence arguments
  7. 07

    Configuration & Baselines

    Configuration management (Part 8 Clause 7) as the prerequisite that makes impact analysis possible, anchoring every analysis to a controlled, reconstructable baseline.

    • Plan, comply, baseline, and maintain across the lifecycle
    • Development, release, safety case, and field baselines
    • Configuration drift as the silent enemy
  8. 08

    Change-Management Workflow

    The end-to-end flow from change request to re-release, covering roles, records, independence requirements, and the link back to confirmation measures.

    • Seven stages: request to re-release and baseline update
    • Roles, responsibilities, and independence for ASIL C and D
    • When changes re-trigger confirmation reviews
  9. 09

    Worked Example

    A completed impact-analysis table for swapping a narrow-field radar for a wide-field radar on an existing lane-keeping platform, where a "simple sensor swap" turns into 12 affected work products.

    • Twelve work products assessed, one reused with justification
    • Probabilistic Metric for Random Hardware Failures (PMHF) re-run as the critical path
    • Wider field of view forces a re-examination of the hazard analysis
  10. 10

    Pitfalls & Checklist

    The most dangerous patterns seen across audits and field post-mortems, paired with a practical review checklist for any change impact analysis report.

    • Invisible ripples, stale assumptions, ignored tool changes
    • Review checklist across description, coverage, and approval
    • Before, not after: the analysis authorises the change
Diagrams & Visuals

Not just text: the visual toolkit

Brownfield Reality Schematic

Maps the spectrum of brownfield work, from calibration tweaks to architectural changes, against the ISO 26262 mechanisms that govern each.

Impact Ripple Propagation Map

Animates how a single change spreads laterally to interfaces and upward through requirement allocations to affect safety goals.

Carryover & Reuse Argument Flow

Walks through validating SEooC assumptions and closing coverage, metrics, and evidence gaps before confident reuse.

Change Classification Decision Tree

Routes a change request through its category to surface the characteristic ripple pattern and required activities.

Regression Strategy Matrix

Triages each test domain into one of four re-verification zones and scales the strategy by ASIL level.

Configuration Baseline Timeline

Tracks development, release, safety case, and field baselines so every impact analysis anchors to a defined snapshot.

Worked Example

Swapping a Front Radar on an Existing Lane-Keeping System

A facelift replaces a Supplier A narrow-field radar (15 degrees, 80 m) with a Supplier B wide-field radar (60 degrees, 120 m) on an ASIL C lane-keeping and highway driving assist system. Change request CR-HDA-2024-047 walks through a full impact-analysis table.

  • Item definition and system boundary updated for the new sensor
  • Hazard analysis re-examined because the wider field of view introduces new scenarios
  • Technical safety concept timing re-analysed as latency rises from 20 ms to 22 ms
  • FMEDA re-run with Supplier B failure rate data flagged as the PMHF critical path
  • Lane-keeping control software reused after static call-graph analysis proves independence
  • Twelve affected work products versus one validly reused, with owners assigned in the safety plan
Impact Analysis Table: CR-HDA-2024-047
Item Definition (HDA-ID-v3.2): Affected, sensor list and system boundary update required

Unlock the full 12-row impact table with required activities and owners

Built for

Who this guide is for

  • Engineers on facelift, variant, or carryover programs - the brownfield majority
  • Safety managers who must sign off change requests without re-running the whole lifecycle
  • Change control board members deciding what a "simple sensor swap" really touches
  • Anyone whose assessor asked for the impact analysis behind a reused element

Frequently Asked Questions

Common questions about Change Impact Analysis for Carryover & Modified Systems

Change impact analysis is the disciplined evaluation of what a modification to an existing item or element affects, and which safety lifecycle activities must therefore be repeated. ISO 26262 governs it in two places: ISO 26262-2 (Sections 6.4.3 and 6.4.4) requires an impact analysis at lifecycle initiation to decide whether an item is new, modified, or reusable, and ISO 26262-8 Clause 8 governs change management during and after development. The analysis identifies affected work products, assesses effects on safety goals, scopes re-verification, and is documented and approved before the change is made - not after.
Always - ISO 26262 has no de minimis threshold, so every change request triggers an analysis, even a calibration tweak. For carryover into a new context, the key question is whether the original assumptions still hold: SEooC assumptions of use, the operational design domain, environmental conditions, and interface contracts must each be validated against the new vehicle. A wider field of view, a new supplier, or a changed duty cycle can ripple all the way up to the hazard analysis. The course dedicates a chapter to structuring exactly this reuse argument.
With a risk-based regression strategy, not a blanket re-run. The method taught here triages every test domain into one of four zones - from must re-test, through partial and reuse-with-justification, to not applicable - and scales the justification rigor with the ASIL of the affected safety goals. Evidence-reuse declarations need an independence argument showing the change cannot influence the reused result, for example a static call-graph analysis proving software independence. The worked example applies the full triage to a radar swap where 12 work products are affected and exactly one is validly reused.
They are separate clauses with a dependency: configuration management (ISO 26262-8 Clause 7) maintains controlled, reconstructable baselines - development, release, safety case, and field baselines - while change management (Clause 8) governs how a modification moves from request through analysis, approval, implementation, and re-release. Impact analysis is only possible against a defined baseline; without it you cannot even state precisely what is changing. The course covers both, including the roles and independence requirements for ASIL C and D changes and when a change re-triggers confirmation reviews.
It spans 10 chapters covering the six-step impact-analysis method, seven change categories with their ripple patterns, the four-zone regression triage, configuration baselines, and the end-to-end change-management workflow. You get 6 diagrams and visuals, including the ripple propagation map and the regression strategy matrix, plus a complete worked example: a front-radar swap on an ASIL C lane-keeping system with the full 12-row impact table. A free account starts you off, and the Pro and Expert plans unlock more of the library.

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.