23 — Integration, verification and acceptance

A vehicle can contain all the specified components and still fail to perform its intended job. Interfaces may be incompatible, controls may respond incorrectly, or the chosen requirements may omit an important operating condition. Integration, verification, validation and acceptance address related but different questions. Keeping their decisions distinct makes it possible to understand what has been demonstrated and what remains uncertain.

Integration brings elements together into a functioning whole. Verification establishes whether specified requirements are met. Validation establishes whether the product meets the intended need in its intended context. Acceptance is the authorised decision to receive a deliverable against agreed conditions. NASA's Systems Engineering Handbook treats verification and validation as distinct product-realisation processes. Its guidance provides a useful conceptual reference; it does not impose NASA acceptance rules on the utility vehicles. NASA product verification and product validation.

Decide what evidence will answer the question

Verification begins while requirements are being established. A requirement that cannot be interpreted consistently cannot support a reliable pass decision. Identify the characteristic, applicable conditions and acceptance criterion, then select a method capable of establishing it. Inspection, analysis, demonstration and test serve different purposes. A dimensional inspection can establish a defined clearance; analysis can predict thermal behaviour within stated assumptions; a controlled test can measure a response under recorded conditions. The method must match the claim.

The verification plan should identify each requirement and revision, its allocated product or interface, the method, procedure, responsible organisation, planned configuration and evidence needed for closure. It should also identify dependencies: a vehicle-level cooling test may depend on accepted instrumentation, known engine calibration, an established loading condition and completed subsystem checks. A requirement-to-report link is useful only when the report actually addresses the requirement's applicable conditions.

Customer requirements reside in DOORS in this programme. That does not settle where all derived requirements, procedures and results are authored. Assign ownership for each information class and maintain controlled relationships between them. A requirement link must preserve the baseline being assessed; otherwise a report produced against an earlier requirement can appear to support a changed one merely because the identifier stayed the same.

For the cooling module, plan evidence for the mechanical attachment, fluid connections, electrical interface and integrated thermal function. These claims have different boundaries. Supplier evidence for the bought radiator may establish component characteristics without establishing the installed vehicle's thermal performance. Supplier evidence for the engine and transmission likewise needs interpretation in the actual installation and operating envelope.

Validation asks whether the specified characteristics enable the intended work. A cooling test may satisfy its specified conditions while an operational trial reveals that the assumed duty cycle omits prolonged stationary operation needed by the customer. Plan representative use with intended operators and record configuration and environmental limitations. Such a finding may expose an incomplete requirement rather than defective manufacture. Contractual acceptance follows its agreed conditions; a successful test or customer signature does not silently resolve the uncovered need.

Integration is controlled learning

A sensible integration sequence reduces uncertainty in stages. Confirm individual interfaces before exercising the complete vehicle under demanding conditions. Establish mechanical fit and secure installation, appropriate fluid-system readiness, electrical compatibility and control behaviour. The precise sequence depends on the design and the hazards of the activity; it should be defined by competent engineering and test personnel, not inferred from this conceptual example.

Integration procedures need entry conditions and stop criteria. Entry conditions establish that the configuration, resources, people and safeguards are ready. Stop criteria establish when an unexpected observation requires the activity to pause. The test lead can control the activity within the approved procedure, but cannot waive an unmet product requirement simply to continue the schedule. Engineering assesses anomalies; quality and assurance functions provide the oversight assigned by the programme.

Test equipment and enabling products form part of the evidence context. Identify instrumentation, calibration status where relevant, data-processing methods, fixtures and temporary software. A test adaptor can introduce behaviour absent from the delivered configuration. If that difference matters to the claim, justify its representativeness or perform the necessary additional work. A temporary arrangement must not disappear from the record because it was absent from the final bill of materials.

Before restarting an interrupted test, record technical clearance for the identified configuration and operations, executable instructions and entry conditions, available resources and safeguards, and acknowledgement by the test team. Remaining exposure requires acceptance by its delegated authority. Approval to install a remedy does not itself clear the interrupted test to resume.

Know exactly what was tested

A test result belongs to an identified configuration. Record the vehicle, installed hardware instances at the necessary granularity, relevant definition revisions, software and calibration identities, outstanding concessions and temporary provisions. Include the procedure revision, environmental and operating conditions, equipment, observations, raw data references and analysis used to reach the conclusion. The required detail follows the claim and its consequences.

Part identity, revision, occurrence and instance each contribute. The fan type identifies the defined kind of equipment; its revision identifies the applicable definition; its occurrence locates its use in the vehicle; its serial or other physical identification establishes which actual item was exercised. A replacement of the same type can leave design evidence relevant while requiring new unit-specific installation or functional evidence.

Software and calibration are physical-configuration concerns even when delivered electronically. Fan control settings, engine control software or supplier firmware may affect the test response. Record the loaded state that matters to interpretation and control its later alteration. A hardware-only configuration list can make a result impossible to reproduce or invalidate a comparison between two vehicles.

Preserve unsuccessful results and interrupted runs. They establish what occurred and may expose a failure mechanism. A later successful run needs its own record and a justified relationship to the earlier failure. Replacing the failed report with the successful one removes the basis for judging whether the problem was understood.

Changed hot-climate requirements

The customer revises hot-climate operating requirements in DOORS while Vehicle 01 is in build, Vehicle 02 has major equipment ordered, and Vehicles 03 and 04 are being planned. First identify the proposed requirement change and its contractual disposition. Do not silently judge existing evidence against a newly edited live requirement. Establish the applicable agreed baseline and vehicle scope.

Engineering assesses cooling, HVAC, electrical demand, packaging, control and powertrain consequences. The resulting solution may preserve some existing evidence and invalidate other evidence. A bracket inspection may remain applicable if its definition and relevant loading assumptions are unchanged. A thermal analysis based on the earlier operating environment needs reassessment. The decision follows the evidence dependencies, rather than a blanket rule to repeat everything or reuse everything.

Vehicle 01 requires a known build state and an implementation plan before the revised test configuration can be established. Vehicle 02's purchased engine, transmission, cooling and HVAC provisions need reconciliation with the intended solution. Vehicles 03 and 04 can incorporate the changed definition into their planned builds. Their common design does not remove the need to demonstrate each vehicle's correct assembly and applicable acceptance conditions.

The payload change is related but distinct. It may alter structure, suspension, braking and powertrain assessments, as well as the conditions under which integrated performance is evaluated. Determine which claims depend on the changed loading basis. A hot-climate result cannot establish payload suitability merely because both changes are part of the same customer discussion.

Supplier change and a failed run

Now suppose the supplier connector change is accepted for a subset of vehicles. Verification must address the changed interface and any affected integrated function. The customer requirement may remain unchanged. This is why a supplier change cannot be managed solely as a requirement revision: the product's means of satisfying the same requirement has changed.

If a fan-control check fails on Vehicle 01, record the exact installed pair, relevant software and calibration, procedure, conditions and observations. Contain the affected configuration and preserve diagnostic evidence. Investigation may find incorrect assembly, an incompatible supplied item, an inadequate procedure or a design error. Each route has different consequences for disposition and for the validity of previous evidence.

Authorise the remedy through the appropriate technical and quality route. Then decide the retest scope from what changed and what was disturbed. Replacing a connector might require electrical checks and renewed integrated functional evidence; removing the module may also affect mechanical and fluid-joint evidence. The test lead should not choose a smaller scope merely because the failed step now passes in isolation.

Close the anomaly only when the remedy, retest and affected evidence decisions are recorded. If the cause remains uncertain, a successful repeat may provide limited evidence of current behaviour without proving that recurrence has been prevented. Acceptance authority needs that distinction clearly stated, particularly where a concession or operating restriction is being considered.

Reuse evidence with an explicit argument

Evidence reuse is valuable when it avoids work that adds no knowledge. It requires an argument that the earlier evidence covers the new claim. Compare requirements, configuration, interfaces, operating conditions, manufacturing processes and relevant variation. Identify differences and explain why they do or do not matter. Record the reviewer and the scope of the conclusion.

A common cooling-module design assessment can support several vehicles if their applicable configurations and conditions fall within its justified scope. It cannot prove that Vehicle 04's actual hose was connected correctly. Conversely, repeating an extensive design test on every unit may provide less useful assurance than checking the unit-specific workmanship and function that can vary. Separate evidence of design adequacy from evidence of individual product conformity.

Supplier test reports need the same scrutiny. Establish what item and revision were tested, which requirements were assessed, what conditions applied and whether the supplied unit or design is represented. A supplier's general certificate cannot be expanded into claims it does not contain. Contractual acceptance of a document is also distinct from the engineering judgement that it establishes a particular requirement.

Acceptance is an authorised conclusion

Acceptance combines evidence and authority. Define who can accept the vehicle, the contractual conditions, required records, permitted outstanding items and any rights retained by the customer or other authority. Technical approval establishes engineering acceptability within its scope; commercial acceptance establishes the contractual decision. Applicable regulatory approvals, if any, require their own identified basis. None should be implied by a generic “approved” status.

Prepare an acceptance dossier as an indexed argument rather than a folder of unexplained reports. Identify the delivered configuration, applicable requirements baseline, coverage and results, concessions, unresolved anomalies, operating limitations and support information. Distinguish passed, failed, not performed, not applicable and accepted by concession. A completion percentage must not conceal which important claim remains unsupported.

An authorised concession can permit acceptance of a defined departure under agreed conditions. It does not turn a failed verification into a pass. Preserve the requirement, result and acceptance decision separately. If the customer accepts a restricted operating envelope, the delivered instructions and support records must carry that restriction, and its applicability must remain visible for the affected vehicle.

Acceptance also needs a configuration freeze point or equivalent controlled reference. Changes after the evidence review require impact assessment before delivery release. Replacing an engine control unit after testing may affect loaded software or calibration even if its hardware identity is unchanged. Establish whether further checks are needed and update the delivered physical record.

Evidence across a large programme

At millions of occurrences over years of manufacture, the central problem is maintaining the scope of each claim. Thousands of people and expensive supplier contracts create many legitimate sources of evidence, each with its own authority and limitations. Stable identifiers, baseline-aware links and durable retention allow the programme to assemble a coherent acceptance argument without requiring every participant to read every report.

The core platforms supply parts of that information chain. DOORS holds customer requirements; NX and Capital provide relevant design definition; Teamcenter controls lifecycle relationships in the chosen architecture; SAP supports business and production transactions. Test authoring, data acquisition, result management and acceptance evidence require explicit implementation choices. Neither ERP completion nor a lifecycle release status establishes a test result automatically.

Use configuration-sensitive coverage views to expose missing evidence and invalidated claims. Preserve raw evidence and the interpretation that supported the decision, including later corrections. This allows delivery and support organisations to understand what the vehicle was shown to do, under which conditions, and with what remaining obligations. Acceptance then becomes a defensible commitment about a particular product rather than a ceremonial signature at the end of manufacture.