Model-based engineering enterpriseSearch the book
In this chapter

02a — The engineering lifecycle and technical reviews

Decisions from need to retirement

An engineering lifecycle connects an intended outcome to a product that can be delivered, used, supported and eventually withdrawn. It includes the supporting systems needed to manufacture, test, operate and maintain that product. A vehicle that performs well in a demonstration but cannot be maintained in its intended setting is an incomplete delivery outcome.

ISO/IEC/IEEE 15288:2023 provides a framework of system lifecycle processes. Its public scope includes development, production, use, support and retirement, with iterative, concurrent and recursive application; it does not prescribe a particular development model. This permits reasoning about overlapping work without treating every lifecycle activity as a single sequential phase. ISO, scope. The INCOSE Systems Engineering Handbook, fifth edition, provides companion lifecycle and tailoring guidance. INCOSE, publications overview.

A technical review asks whether evidence supports a defined next commitment. The names System Requirements Review (SRR), Preliminary Design Review (PDR) and Critical Design Review (CDR) are familiar institutional conventions, not universal obligations imposed by those names alone. NASA's Systems Engineering Handbook explains such reviews within NASA's programme lifecycle. The vehicle review arrangements below apply that decision logic to the teaching example, rather than claim NASA contractual applicability. NASA handbook, chapters 3 and 6.

Concept and stakeholder needs

Concept work establishes who needs the capability, how it will be used and what would make a solution worthwhile. The customer, drivers, maintainers, production teams and support organisations can have different needs. Their needs must be reconciled with commercial, environmental and applicable legal constraints before a promising sketch becomes a delivery promise.

For the utility vehicle, payload has meaning only in an operational context. Loading arrangements, terrain, duty, crew activity and support conditions can alter what a useful solution requires. Hot-climate operation similarly concerns more than radiator size: engine cooling, cabin conditions, electrical demand and maintenance access interact. Concept comparison asks whether alternative arrangements can plausibly satisfy that combined need and what uncertainties would dominate further development.

The concept decision needs an agreed problem, credible alternatives, explicit assumptions and a plan to investigate the largest uncertainties. It should leave a reasoned basis for selecting an approach, rather than a claim that the selected arrangement is already proven. If a critical operating condition remains unclear, the next authorised step may be investigation or a demonstrator, with production commitments withheld.

Support and retirement already matter. An arrangement requiring inaccessible routine service or unavailable specialist equipment can undermine the original capability. Early decisions also establish which obligations require specialist assessment; a generic lifecycle diagram cannot decide the vehicle's road approval or contractual assurance regime.

Requirements and the SRR

Requirements translate needs into conditions against which a solution can be assessed. Customer requirements are captured in DOORS. Engineering clarifies their meaning, identifies conflicts and develops the allocated requirements needed by systems and suppliers. A requirement baseline identifies the controlled reference used for decisions; it does not make later customer requests impossible.

An SRR examines whether this requirements basis is sufficiently clear, feasible and assessable to support the next work. Its entrance evidence includes the operational context, identified requirement versions, unresolved conflicts, initial allocation, assessment methods and significant risks. The reviewers need enough preparation time to challenge that evidence. A presentation assembled on the review morning cannot substitute for it.

For the hot-climate requirement, reviewers ask what operating conditions and vehicle configurations the requirement covers, which functions contribute and how eventual evidence will address it. A requirement without a credible assessment method can conceal disagreement until acceptance. Exit criteria therefore concern the adequacy of the requirements and the disposition of material gaps. An unresolved term affecting cooling-module selection may prevent that selection even if unrelated requirements are satisfactory.

A payload change raised after Vehicle 01 enters build reopens the relevant reasoning. Structure, suspension, brakes and powertrain require impact assessment; no predetermined redesign follows merely from entering a new value in DOORS. Technical feasibility, contractual agreement and implementation authority remain separate. The review records which requirement state it assessed and which vehicles its conclusions cover.

Architecture and preliminary design

Architecture allocates functions and responsibilities, identifies interfaces and explains how the elements cooperate. Preliminary design develops a credible solution with enough analysis and definition to justify detailed work. Requirements, architecture and analysis iterate: a packaging conflict can expose an allocation problem, while analysis can reveal an infeasible requirement.

The cooling module needs mechanical mounting, coolant connections and electrical/control interfaces. Its supplier can own internal design while the vehicle authority governs integration. The preliminary arrangement must account for loads, space, cooling duty, electrical demand, routing and access at the level needed for the decision. It need not reveal every proprietary supplier detail, but missing boundary information cannot be dismissed as proprietary if compatibility depends on it.

A PDR tests whether the preliminary solution is credible enough to develop further. Entrance evidence includes the allocated requirements, architecture, interface definitions, analyses with assumptions, major trade decisions, supplier commitments and plans for manufacture, verification and support. Exit criteria ask whether the remaining uncertainties can be resolved through the planned detailed work within the authorised exposure. NASA's handbook describes PDR as establishing a basis for detailed design and CDR as assessing maturity for fabrication and integration. These meanings inform the example; the programme must define its own binding criteria. NASA handbook, Appendix A review definitions.

A successful cooling-module PDR might support detailed bracket and hose design while requiring further evidence about a fan interface. It does not establish that the complete vehicle meets its requirements. Vehicle-level review must still examine the module's combined effect with the engine, electrical supply and surrounding installation.

Detailed design and the CDR

Detailed design converts the selected solution into controlled product definition. Geometry, materials, tolerances, interfaces, electrical connectivity, software and calibration states must be defined sufficiently for their intended use. Analysis substantiates choices; product definition tells downstream teams what to realise. Neither is evidence that a particular physical vehicle has been built correctly.

At a CDR, reviewers assess whether the defined design and remaining work support the intended implementation commitment. Entrance evidence includes the applicable product definition, interface agreements, supporting analyses, requirement coverage, manufacturing and integration plans, verification arrangements and open risks. Software and calibration cannot disappear because the review pack centres on mechanical models. Their versions, dependencies and evidence must be addressed wherever they affect the reviewed behaviour.

Exit criteria require justified maturity for the identified scope. Suppose the bracket definition is complete but the supplier's electrical connector is unresolved. The decision can distinguish bracket manufacture from harness termination and vehicle installation. It must establish whether any bracket characteristic depends on the unresolved connector's packaging or access. If it does, apparently local completeness is insufficient.

BS 8888 concerns technical product specification and documentation. It supports precise product definition rather than supplying the entire lifecycle or review regime. BSI, BS 8888 overview. A well-specified drawing does not establish that requirements are adequate, production is ready or a delivered vehicle is acceptable.

Manufacture before global design completion

Vehicle 01 is building, Vehicle 02 has major components ordered, and Vehicles 03 and 04 are being planned. A single whole-vehicle maturity label cannot describe every commitment across those stages. The programme needs staged reviews and releases whose boundaries match the work being authorised.

Unchanged chassis members might proceed while the cooling-module installation continues to develop. That requires a controlled basis for the committed geometry and interfaces, explicit assumptions about remaining work and an assessment of access and rework exposure. Withholding unresolved mounting features is useful only if their later completion is technically and industrially credible. Someone with delegated authority must accept the bounded exposure; a schedule target cannot provide that authority.

Review pass, release and acceptance answer different questions. Review pass records an evidence-based readiness judgement. Release authorises an identified definition or work package for a specified use. Acceptance disposes of the delivered result against agreed obligations. A review recommendation may be a prerequisite to release, but does not automatically amend an order, instruct a technician or accept a vehicle.

After the customer changes hot-climate conditions, the programme must determine whether the earlier commitment basis remains valid. By contrast, a supplier connector change starts with a changed equipment interface, even if it later affects requirement satisfaction. Both changes need impact and applicability decisions, but they are different initiating events. CM-II provides the change-management basis; this review model does not assert detailed framework conformance.

Manufacturing and integration readiness

Manufacturing readiness concerns the ability to realise the required product repeatedly and under control. Its evidence includes released inputs for the work, material availability and identity, process capability, competent people, suitable equipment, supplier readiness, inspection arrangements and a credible sequence. A Production Readiness Review (PRR) can consolidate those questions for an appropriate production scope. Its depth should reflect consequence and repetition rather than the prestige of the review name.

For the cooling module, a bench assembly may be ready before vehicle installation. The bench operation needs its own material, instructions and checks. Installation additionally depends on compatible chassis mounts, coolant endpoints, the vehicle harness and access in the current build sequence. Passing the bench review cannot resolve an unavailable vehicle-side connector definition.

Integration readiness examines how lower-level products will be combined and checked. Both mating sides must be identified by definition, revision and use context. A connector part identity can recur at several positions; evidence for one occurrence cannot silently stand for every occurrence. The physical module installed in Vehicle 01 is an instance, distinct from the reusable module definition and its revision. NASA's integration guidance addresses sequences, procedures and configuration adequacy, supporting this distinction between having components and being ready to combine them. NASA handbook, §5.2.

Execution records then establish what actually happened: applicable instruction, installed items, completed operations, observations and dispositions. The enterprise architecture must locate those records and retain their configuration context. SAP does not become the authority for every as-built fact merely because it supports production transactions.

Test readiness, verification and validation

A Test Readiness Review (TRR) asks whether a specified test can proceed safely and produce interpretable evidence. Entrance evidence includes the identified test article configuration, procedure, criteria, facilities, instrumentation status, personnel, hazards, prerequisites and anomaly arrangements. Exit criteria require those conditions to be adequate for that test. Readiness for one component test is not readiness for every vehicle test.

A cooling-module test must identify the module, relevant software or calibration, boundary conditions and measurement basis. If it uses a surrogate vehicle interface, the differences need justification and limits on evidence reuse. Otherwise a result can be technically sound yet irrelevant to the vehicle configuration being accepted. A later connector substitution requires assessment of whether earlier evidence remains applicable.

Verification establishes whether specified requirements are satisfied. Validation examines fitness for the intended use and stakeholder need. Analysis, inspection, demonstration and test can contribute as appropriate; a test result alone is not a complete argument. The engineering authority must relate results to the applicable requirements and disposition anomalies. NASA's system design and product realisation guidance distinguishes these activities. NASA handbook, chapters 4–5.

A vehicle may satisfy a measured cooling criterion yet remain unsuitable for its operational task because maintenance access or actual duty was misunderstood. Validation addresses that wider question. Conversely, a persuasive user demonstration cannot waive an unmet contractual requirement without the necessary authority. Verification and validation evidence must preserve their assumptions, configuration and scope.

Acceptance and transition into use

Acceptance review brings together the delivered configuration, required evidence, departures and contractual deliverables. Entrance criteria include a sufficiently complete account of what is being offered, requirement results, unresolved anomalies, authorised concessions and support readiness. Exit criteria concern whether the authorised recipient can accept that defined delivery, with any limitations explicitly dispositioned.

Technical staff judge technical adequacy within their remit. Commercial authority determines contractual consequences; acceptance authority acts under the relevant agreement. A review chair cannot create authority missing from that agreement. An outstanding action affecting a mandatory acceptance condition prevents acceptance unless the governing arrangements permit and authorise an alternative disposition.

Configuration audits can support this decision. A Functional Configuration Audit (FCA) examines evidence that the configured product meets its functional and performance requirements; a Physical Configuration Audit (PCA) examines correspondence between the realised product and its configuration documentation. The scope and contractual use of those audit names must be specified. Neither replaces operational validation or the customer's acceptance decision.

Transition also needs trained users, maintenance information, spares, tools and operating constraints. Acceptance of one vehicle does not establish readiness of all four. Vehicle 02 may retain a different authorised connector pairing, while Vehicles 03 and 04 adopt a later configuration. Their evidence must follow those differences rather than a fleet-wide claim based on the latest model.

Operation, support and retirement

Operation generates evidence about failures, duty and maintenance that can challenge earlier assumptions. Support engineering assesses that evidence, manages replacements and modifications, and preserves the relationship between the approved design and the current installed configuration. A replacement part's catalogue description alone cannot establish compatibility with an earlier harness or calibration.

Modification therefore repeats selected lifecycle work: clarify need, assess requirements and interfaces, define the change, prepare implementation and demonstrate the resulting configuration. Repetition is targeted to the affected argument. Unchanged evidence can be reused where its applicability is justified, while invalidated assumptions require fresh work.

Retirement requires planning for withdrawal, isolation, disposal or recovery, retained records and closure of support obligations. Relevant environmental, safety and contractual requirements determine the actual methods. A disposal-readiness decision asks whether those arrangements are adequate for the specific asset; it does not follow automatically from deciding that operation should cease.

Review actions, recursion and scale

Every review record should identify scope, evidence versions, criteria, participants, authority, findings and the decision. Open actions need an owner, required closure evidence, due point and an explicit effect on progression. A conditional outcome must state what may proceed and what remains held. Administrative closure without resolving the underlying technical issue cannot justify the next commitment.

Reviews recur at vehicle, system, module and supplier levels where their decisions are useful. Lower-level evidence informs higher-level judgement but cannot settle interactions outside its scope. Tailoring can combine reviews or use focused peer assessment for modest work, provided the necessary decisions and evidence remain visible. It should remove unnecessary ceremony rather than necessary reasoning.

At major defence and infrastructure scale, millions of occurrences, years of manufacture and thousands of people require delegated review authority and durable evidence. Review records must remain intelligible after staff, suppliers and tools change. The organising principle remains the same as for the four vehicles: identify the commitment, establish its evidence and dependencies, and assign the authority that can make and later revisit the decision.