Engineering & Technology · Systems Engineering, Integration & Validation
Configuration, change control and lifecycle information
A report says “the station passed,” but the installed software has since changed. Without knowing which hardware, software, data definitions and settings were checked, the statement cannot reliably support the current product. Configuration gives the evidence a specific subject.
Use the design and measurement chapters for requirement wording, comparisons and evidence. This chapter introduces its systems vocabulary directly; later reliability, control and economics work develops specialised models. NASA guidance supplies general process concepts, not universally applicable industry or certification rules.
Back to the chapterAfter reading, you can
Identify a known product baseline and assess how a change affects interfaces, requirements and evidence.
Keep the product and its records consistent
A configuration identifies the relevant arrangement and versions of product items and supporting information. A baseline is an agreed reference configuration under the project’s change process. Identify the requirements, interfaces, software, hardware, data definitions and settings needed to distinguish the subject of a decision. The necessary detail depends on the product and consequences.
A version label is useful only when it resolves to a known content and relationship. Record what was specified, built, tested and installed, including relevant differences. A station with the same software file but different catalogue schema or timeout setting can behave differently. The evidence record should enable that distinction rather than relying on an informal claim that everything is current.
Control a proposal through its effects
Our original baseline A contains hardware H1, software S1, data schema D1 and requirement R1. Test T1 records observations on that arrangement. A proposal changes the duration field to a different representation in D2 and updates the receiver to S2. Listing both new identifiers does not establish that every producer, stored record and diagnostic tool understands the change.
Assess affected functions, interfaces, operational states, support materials and evidence. Identify the authority and rationale for the decision, the implementation plan and how the resulting configuration will be checked. Retain unresolved impacts explicitly. If an external catalogue is owned separately, its change schedule and compatibility agreement are part of the integration question.
Evidence belongs to a scope and configuration
Some earlier evidence may remain applicable after a change; other evidence may need repeating or replacing. Determine that through the change’s effects and the original claim. An unchanged enclosure drawing may support the same geometric claim, while an altered message path can invalidate a response-time conclusion even when the timing requirement is unchanged.
Keep previous baselines and results retrievable. Record deviations between intended and installed configurations and resolve them through the responsible process. A restoration plan also needs compatible data and external relationships; restoring one old software component does not automatically restore the whole prior system state. Good records support operation, maintenance and eventual retirement as well as initial delivery.
Assess an apparently small schema change
Suppose D1 represents a duration in whole seconds and D2 represents whole milliseconds. An original value 120 becomes 120000 for the same intended interval. A producer updated to D2 and a receiver still using D1 could interpret that value as 120000 seconds. Correct arithmetic within each module would not prevent this interface failure.
The change assessment therefore identifies both ends, stored values, configuration selection and relevant checks. Preserve T1 as evidence about baseline A. After the agreed conversion and integration work, create new observations on the identified baseline B. The example illustrates the scope of a change; it is not a migration procedure for an actual system.
Try the reasoning
Does an unchanged requirement mean every old test result still applies?
Show the answer and reasoning
No. The implementation, configuration or conditions relevant to that claim may have changed.
Why preserve baseline A after baseline B is accepted?
Show the answer and reasoning
It supports traceability, investigation and understanding of which earlier results concerned which product.
Can restoring S1 alone guarantee restoration of baseline A?
Show the answer and reasoning
No. Data, settings, external systems and other configuration items may no longer match.
What to carry forward
Give every result a known configuration, and carry a proposed change through its affected relationships before reusing old conclusions.
References
Teaching resources and research supporting this lesson’s explanations and examples.