11 — Configuration, variants, options and effectivity

“Build the latest design” is an inadequate instruction when one vehicle is already in assembly, another has equipment on order and two remain in planning. The latest definition may be unapproved, incompatible with purchased equipment or intended for only one operating environment. Configuration control makes the intended combination explicit and preserves the evidence of what each vehicle actually became.

Identity, revision and contextual use

A configuration is an identified arrangement of product elements and their relevant characteristics. Selecting it requires more than collecting current part revisions. The selection includes applicable requirements, interfaces, hardware, software and calibration, and the decisions that permit their combination.

Part identity denotes a kind of item; revision denotes a controlled version of its definition. An occurrence denotes a use in a particular structure. Vehicle applicability says which units or contexts may use that occurrence or definition. A physical instance is the actual item built or installed. These distinctions prevent a change to one use from accidentally altering every use of the same part.

For example, a common bracket may occur twice within a vehicle. A local installation change may alter the fastener or orientation at one position while leaving the bracket definition unchanged. Conversely, revising the bracket's material changes its definition but does not automatically approve that revision for every vehicle. The configuration record must preserve both the item version and the context in which it is authorised.

This operating model gives the configuration authority responsibility for selection rules and baseline integrity. Design authorities approve technical content; system authorities approve compatibility; manufacturing and support authorities approve the corresponding planned and service configurations. Commercial authority resolves contractual applicability. Configuration control records those decisions and exposes conflicts; it cannot substitute administrative approval for technical judgement.

Options and constrained combinations

An option is a selectable feature; a variant is a permitted alternative product configuration. Their precise implementation terminology varies, so the programme must establish its own unambiguous vocabulary. A hot-climate capability might be offered as an option, while a payload class might distinguish alternative vehicle arrangements. Neither label establishes technical feasibility.

Rules identify required, excluded and conditional combinations. Selecting a higher electrical-demand cooling arrangement may require a compatible power supply, protection, harness and controller calibration. A rule should state the engineering dependency and its rationale. Where feasibility depends on analysis rather than a simple selection, the rule must require that assessment rather than suggest that selecting a checkbox proves adequacy.

Separate feature intent from product content. “Hot-climate capability” expresses a required outcome; it is not synonymous with one fan part number. The technical solution can change while the feature meaning remains stable. Conversely, changing the required operating envelope can change the feature definition even if the installed hardware initially remains unchanged.

Siemens describes Teamcenter product-configuration capabilities for features, rules and product content. Its Product Configurator material distinguishes variability definition from content definition. Siemens product configuration and the Product Configurator fact sheet support those broad capabilities. They do not establish the installed modules, rule syntax or default precedence in this programme.

Effectivity must select an exact unit

Effectivity identifies conditions under which a definition or change applies. Serial, date and lot conditions answer different questions. A vehicle serial condition can identify the intended end units. A date condition can govern a planned introduction point, but must specify the event and time basis: order release, manufacture, installation or another defined event. A component lot identifies a production population and may support pedigree or containment; it does not necessarily identify the vehicles that eventually received its members.

The programme should prefer explicit end-unit applicability for decisions affecting these four vehicles. Dates and lots remain useful for planning and supply control, with traceable allocation to actual units. Vehicle 02 can be built after Vehicle 03; a component can remain in stock beyond its planned introduction date. These ordinary events make an unexplained date threshold unreliable evidence of installed configuration.

A configuration query therefore needs a defined context: the end-unit identity, structure view, baseline or decision date, option selections, revision-selection policy and applicable exceptions. It must return exactly one authorised solution for required positions, or an explicit unresolved condition. No selection and multiple incompatible selections are both errors requiring disposition. A missing result must not silently mean “use latest”.

Conflicts arise when a general introduction rule selects a new fan but a vehicle-specific exception retains the old harness. The rules need an explicit precedence policy, yet precedence alone cannot resolve technical incompatibility. The configuration authority raises the conflict for engineering disposition; it does not allow a more specific rule to legitimise an impossible combination. Approved exceptions identify scope, reason, evidence and closure or continuing validity.

Resolve Vehicle 02 before issuing work

Consider a general introduction rule selecting the revised fan and harness for future manufacture, while a Vehicle 02 exception retains its already-ordered earlier harness. A date-based query selects the new fan; the exception selects the old harness. Individually authorised records now produce an incompatible combination. Selecting the most recently approved record conceals rather than resolves the conflict.

First establish Vehicle 02's identity, structure view, agreed requirements baseline and approved change context. Resolve candidate content, then check compatibility across positions, including software and calibration. The result identifies conflicting rules and affected occurrences. It cannot provide a buildable cooling configuration until technical disposition establishes a compatible set.

One possible disposition retains the earlier pair if supply and the agreed obligations permit it. Another amends the order and adopts the revised pair with the required installation and verification work. If the changed hot-climate obligation already applies to Vehicle 02, retaining earlier hardware needs a substantiated performance argument. Purchased stock supplies no such argument. Commercial authority resolves order consequences separately.

The configuration authority records the scoped decision and preserves resolved membership in the work-package baseline. Reproduction must recover the same intended selection after general rules change. Receiving and installation then establish whether physical items match. A different fan found in the shop triggers a discrepancy and disposition; editing intent to match an unexplained installation would destroy the evidence needed to investigate it.

Baselines preserve decisions

A baseline is an identified, controlled set of information and relationships established for a purpose. A design-review baseline may include requirements, architecture, analyses and unresolved assumptions. A manufacture baseline identifies the definition authorised for specified work. An acceptance baseline identifies the configuration and evidence supporting delivery. Their contents differ because their decisions differ.

A baseline must retain or reproducibly resolve its members, revisions, relationships and selection context. A saved report referencing mutable “latest” objects may fail to preserve the decision. The baseline owner establishes completeness criteria and records outstanding limitations. Change control governs subsequent alteration while history remains available.

Customer requirements in DOORS can change without automatically replacing the agreed requirement baseline. The requirement proposal, technical assessment, commercial agreement and implementation authorisation are distinct events. A new requirement baseline may apply to Vehicles 03–04 while Vehicles 01–02 remain under another agreement, provided the contractual and technical decisions support that distinction. Acceptance evidence must be assessed against each vehicle's actual obligations.

Four views of the same vehicle

As-designed configuration records intended engineering definition. As-planned configuration records the materials, processes and work arrangement intended to realise it. An engineering bill of materials and a manufacturing bill of materials can organise the same product differently; their reconciliation must account for content and meaning rather than demand identical trees.

As-built configuration records what was actually made and installed, including serial or lot identity where required, software loads, approved deviations, rework and supporting evidence. As-maintained configuration extends that record through replacement, modification and service. Publishing a design structure establishes none of these physical facts.

The mapping between views should identify how an engineering occurrence is realised, where relevant material is consumed and what evidence confirms completion. A cooling module can be a purchased assembly while its fan remains separately replaceable in service. Service removal changes the installed instance at a position without necessarily changing the approved design definition. If the replacement requires new software or an adaptor, the maintenance plan must implement the complete compatible combination.

Follow a change through all four vehicles

Suppose a hot-climate requirement change leads to a revised cooling solution. Separately, the supplier changes the connector; the records retain distinct origins and decisions even where implementation overlaps. Engineering identifies affected thermal, electrical, packaging and service interfaces. The technical decision specifies the compatible fan, mating connector, harness definition, control software and calibration. It records which existing evidence remains valid and what additional verification is needed.

Vehicle 01 is in build. The team establishes its actual installed and staged configuration before choosing rework or retention. Any retention must satisfy the applicable agreed requirement or follow an authorised disposition; being difficult to change does not establish acceptance. Vehicle 02 has equipment ordered, so the implementation plan considers supplier progress, order amendment and material segregation. Vehicles 03–04 can adopt the new configuration when the complete compatible set is ready.

The change record assigns unit applicability explicitly. Manufacturing planning updates work packages and test instructions. Procurement updates affected orders; stores identifies old and new stock; execution records confirm installation and software loading. Configuration closure checks these downstream results, including justified exceptions. Approval of the new engineering revision is an intermediate decision, not evidence that all four vehicles received it.

Manufacture may continue on unaffected work. For affected work, release identifies stable interfaces and bounded commitments. A chassis operation can proceed while the fan choice remains open if its consequences are understood and the released envelope accommodates the remaining alternatives. If the connector position constrains a hole pattern, that interface must be fixed or the dependent operation withheld. Configuration control enables selective progress by making dependencies visible.

Scale without indiscriminate bureaucracy

Four vehicles allow named-unit decisions to remain readable. Millions of occurrences across years of manufacture require automated selection, rule validation and impact queries. Thousands of people need access to the applicable configuration at their point of work, including suppliers and service teams operating under different agreements. Rules and reference data therefore need accountable owners, controlled changes and representative validation cases.

The same rigour does not require a major review board for every clerical correction. Route decisions according to technical and contractual consequence while preserving identity and history. A description correction may follow a narrow approval route; a change that alters interchangeability requires affected engineering, logistics and support decisions. Proportional routing depends on reliable classification of impact.

Teamcenter is the intended lifecycle environment for controlled product configurations and relationships; SAP supports the associated material and order commitments; NX and Capital supply discipline definition. The exchange contract must preserve configuration context and report rejected or partial updates. Neither a successful transfer nor matching revision labels proves that as-designed, as-planned and as-built records agree. Reconciliation must compare the meaning of the selected content and the evidence of its realisation.