Continuous engineering assurance: from engineering change to readiness impact
In short
Continuous engineering assurance means re-evaluating verification status and readiness each time an engineering change is approved, instead of reconstructing it before every review.
Each change is traced to the requirements, evidence, tests and reviews it affects, so engineers can decide what must be re-verified while there is still time. In AEAIP this is a concept, not a released capability.
01
Readiness decays between reviews
A review gate is a snapshot. The evidence package is assembled, checked and presented, and the board decides. The next day, the programme keeps changing: change requests are approved, nonconformances are dispositioned, software builds are released.
Each change is managed correctly on its own terms. What is not continuously maintained is the answer to the readiness question: given everything that has changed, what do we still know to be verified? That answer is rebuilt, by hand, before the next review. Continuous assurance aims to keep it current instead.
02
From change to readiness impact
- 01Engineering change approved
- 02Impact analysis through the evidence graph
- 03Affected evidence flagged At Risk
- 04Verification reopened where engineers decide it must be
- 05Readiness impact shown for each upcoming gate
- 06Retest or re-analysis on the new configuration
- 07Closure re-approved; readiness restored
The graph does the tracing; engineers make the judgements. Impact analysis follows the Engineering Evidence Graph™ from the changed item to evidence produced on its earlier revision, to the requirements that evidence closed, to the reviews that relied on them.
03
Illustrative example: a flight-computer change
Engineering change
Flight computer processor board revised (Rev D → Rev E)
AEAIP follows the change through the Engineering Evidence Graph: requirements allocated to the board, evidence produced on Rev D, and reviews that rely on that evidence.
12
requirements affected
4
verification results potentially invalidated
3
tests may require rerun
2
qualification artefacts affected
1
cybersecurity assessment affected
TRR readiness
Changes from GO to GO WITH CONDITIONS
Illustrative result on sample data, to explain the concept. Continuous assurance is at Concept status; this is not a released capability.
- 12 requirements affected
- Requirements allocated to the processor board or to functions it hosts, such as timing, power draw and fault detection.
- 4 verification results potentially invalidated
- Results produced on board Rev D whose subject the change could influence: power consumption, thermal dissipation, boot timing and watchdog behaviour.
- 3 tests may require rerun
- Tests an engineer is likely to re-run after disposition, such as a HIL timing regression, a thermal-cycling functional test and a conducted-emissions check.
- 2 qualification artefacts affected
- Qualification evidence that cites the earlier revision, for example the board's qualification test report and its similarity rationale.
- 1 cybersecurity assessment affected
- The secure-boot assessment was performed on Rev D, whose boot ROM configuration changed.
04
From suspect links to suspect evidence
Requirements management tools commonly flag a trace link as suspect when an item at one end changes. That is valuable, and it works within the tool's own data.
Continuous assurance extends the idea in two directions: from links to evidence validity, by comparing the configuration evidence was produced on with the current baseline; and across tool boundaries, so a change in a PLM system can affect a test result held in a test system and a review package held somewhere else.
05
What stays a human decision
- Whether a change actually affects a piece of evidence, or can be retained with a rationale.
- Whether to re-test, re-analyse or accept a residual risk.
- Whether a gate proceeds, proceeds with conditions or waits.
Continuous assurance narrows the question engineers have to answer. It does not answer it for them, and it never closes a requirement or changes a gate decision on its own.
06
What a programme needs for this to work
- Configuration identifiers on every item, build and document that evidence refers to.
- Evidence recorded against the configuration it was produced on, not only against the requirement.
- Change control that names the items affected, so impact can be traced from them.
- Agreed rules for which changes need re-verification, and who decides.
None of this is new; it is good configuration management. The difference is using it continuously rather than at audit time. See configuration-aware evidence validity.
References / Engineering Sources
Explanations on this page are original GAMYAA paraphrase. Standards are referenced, not reproduced; paid standards link to their publisher. Referencing a framework does not imply compliance with it.
- 01NASA Systems Engineering Handbook — 6.5 Configuration Management (opens in a new tab)
NASA
Baselines, change control, status accounting and configuration audits.
- 02NASA Systems Engineering Handbook — 5.3 Product Verification (opens in a new tab)
NASA
Verification methods, qualification, acceptance and recording the product and requirement versions verified.
- 03SAE EIA-649C, Configuration Management Standard (opens in a new tab)
SAE International
Configuration management functions and principles.
- 04ISO 10007:2017, Quality management — Guidelines for configuration management (opens in a new tab)
ISO (TC 176)
Configuration management planning, identification, change control, status accounting and audit.
- 05ECSS-M-ST-40C Rev.1, Space project management — Configuration and information management (opens in a new tab)
European Cooperation for Space Standardization
Configuration and information management for space projects.
- Published by
- Gamyaa AeroSystems — Engineering Assurance Research
- Last reviewed
- Status
- Status: Concept