05 — Product structures and assembly boundaries

Start with the decision the assembly supports

A radiator, fan, hoses and mounting brackets can be called a cooling module. That name leaves several practical questions unanswered. Does the supplier deliver it complete? Can the factory install it before fitting the vehicle harness? Does the service technician replace the whole module when the fan fails? Does releasing the module authorise manufacture of its brackets, purchase of its radiator, or installation into a particular vehicle? An assembly boundary becomes useful when it answers a decision of this kind.

The fictional programme contains four customised internal-combustion utility vehicles. Vehicle 01 is in build, Vehicle 02 has major components ordered, and Vehicles 03 and 04 are being planned. Design and manufacture overlap: the business must make justified local commitments while other parts of the vehicle remain unresolved.

Boundary, identity and authority rules make commitments understandable: what definition is being used, for which vehicle, by whose authority, with what remaining dependencies?

An assembly is a defined combination of constituent products for some purpose. A useful boundary gives people a tractable responsibility without hiding the relationships crossing it. NASA's product-integration guidance treats integration as engineering subsystem interactions as well as assembling lower-level products and checking the integrated result. This supports looking beyond a parts tree, although NASA guidance is not an imposed compliance regime for these vehicles. NASA Systems Engineering Handbook, §5.2.

Several views of the same cooling module

System design asks what the cooling arrangement must accomplish and how it interacts with the engine, environment and electrical supply. Customer requirements reside in DOORS, the selected requirements tool; its edition and integration remain undecided. A hot-climate requirement may influence cooling and cabin heating, ventilation and air conditioning together. Functional allocation does not decide that every contributing component belongs in one physical assembly. Analysis predicts behaviour; a component list identifies constituents. Neither substitutes for the other.

The spatial view asks where equipment fits and what space must remain accessible. A front-of-vehicle zone can contain the radiator, fan, chassis members and wiring belonging to several design responsibilities. Grouping those objects for a packaging review does not make the zone a purchased product. Access and removal space may concern items outside the cooling module's own geometric boundary.

Computer-aided design (CAD) gives the mechanical designer a representation of geometry and arrangement. A CAD assembly can include surrounding references to check clearance. Those references must be distinguishable from supplied constituents. Otherwise a chassis member shown to position a bracket could be mistaken for material delivered with the module. The rule is to state the purpose of each CAD inclusion and reconcile material-bearing inclusions with the controlled product definition.

The engineering bill of materials (EBOM) expresses the intended product composition. Its cooling-module definition identifies the fan, radiator and other constituents required by the chosen design, with applicable revisions and configuration rules. It need not reproduce every convenience grouping used in CAD. Conversely, a required non-geometric item must not disappear merely because it has no useful solid representation.

The manufacturing bill of materials (MBOM) organises material for how the product will be made and assembled. The factory might build a radiator-and-fan module on a bench, deliver hoses separately and fit the brackets to the chassis first. A manufacturing grouping can therefore cross or subdivide the EBOM boundary. The bill of process describes planned work and sequence; it is distinct from the MBOM's material composition. Instructions, completed work records and acceptance evidence add further information rather than becoming interchangeable names for this structure.

Procurement asks what the contract and order require a supplier to deliver. A bought radiator-and-fan package may exclude vehicle hoses and chassis brackets. Alternatively, the supplier may deliver a complete module against an agreed interface definition. The purchase boundary needs to specify included items, excluded items, technical definition and deliverable evidence. A single commercial order line does not by itself explain the package's engineering constituents.

Service asks what can be identified, inspected, removed, repaired or replaced in use. The fan might be replaceable separately even though manufacturing installs the cooling module as one unit. A replacement kit might contain a fan and installation items without reproducing the original manufacturing package. The service structure should express the approved maintenance strategy and applicability; it cannot be inferred simply by copying the supplier's invoice.

These views are related answers to different questions. The operating model preserves their relationships rather than forcing identical trees. A system allocation links a fan to an electrical function; a material relationship places that fan in the cooling module; a manufacturing assignment places its installation in a work package. Each relationship changes a different decision.

A small breakdown with explicit identities

The identifiers below are invented teaching labels, not proposed Teamcenter or SAP object types. This partial breakdown deliberately omits detailed connection hardware; a production definition would have to account for all required material through controlled relationships.

Suppose CM-100 revision A uses BRK-130 revision A in two positions, labelled left mount and right mount. BRK-130 identifies the reusable kind of bracket. Its revision identifies a controlled state of that definition. The two occurrences identify where the definition is used within this parent context. They remain separate uses even though both refer to the same part revision. Their placement and relationships can differ.

A physical bracket fitted at the left mount of Vehicle 01 is an instance of that definition. Its actual traceability might use a serial number, a batch reference or another approved record; this chapter does not mandate serialisation of every bracket. The occurrence tells the business where a bracket is required. The physical record tells it what was actually fitted there and what evidence supports that statement.

Applicability answers which configurations or vehicles a definition or change is authorised to affect. A baseline identifies an agreed controlled configuration at a stated decision point. Neither is another name for revision. Revision B of the bracket may exist while Vehicle 01 remains authorised to use revision A. A baseline should resolve the relevant definitions and their relationships sufficiently for its intended commitment; a reference to whichever revision happens to be latest would leave that commitment ambiguous.

If the illustrative common arrangement were authorised for all four vehicles, two brackets per module and one module per vehicle would imply eight installed bracket positions. That is a calculation of this example's product demand, before spares, losses or other planning allowances. It is not a claim that eight brackets have been purchased or fitted. Configured demand, purchasing demand and actual installation answer different questions.

The fan demonstrates another counting trap. FAN-120 appears in the cooling module and participates in an electrical circuit. Electrical participation does not create a second fan to purchase. Likewise, displaying it in a spatial zone does not add another material occurrence. The rule is to count material through the selected configured composition and use references for other views. If another location genuinely needs another fan, it requires a distinct material occurrence, not merely another functional relationship.

Reconciliation must also avoid counting a bought package and its contents twice. Where procurement orders CM-100 complete, its constituent radiator supports technical visibility and service planning but should not automatically generate an additional radiator purchase. Where the factory builds CM-100 from separately procured constituents, the demand treatment changes. The planning rule must state which boundary supplies the material and how lower levels are treated for that purpose.

Choosing a boundary worth controlling

A new assembly definition carries a cost: someone must maintain its composition, interfaces, release basis and changes. The test is whether the grouping supports a commitment that needs its own stable identity. The following criteria make that judgement concrete.

• Independent delivery or acceptance: Can a team or supplier deliver this combination against an identifiable definition and acceptance boundary?
• Integration sequence: Can it be assembled, handled, checked or installed as a coherent intermediate product?
• Design responsibility: Is there a meaningful authority for its internal definition and compatibility with neighbouring products?
• Reuse and variation: Will the combination recur, or vary together, sufficiently to justify controlling it as a unit?
• Support strategy: Does maintenance require identifying, replacing or tracking this combination separately?
• Commitment and change exposure: Would its own release clarify what can proceed and what a later change affects?

These criteria need judgement rather than a mandatory score. A bench-built cooling module may justify a managed definition because it is delivered to installation as an identifiable intermediate product. A temporary CAD selection containing every object visible from the front may need only a saved navigation view. Giving the selection a part number would imply a product responsibility that nobody needs.

A manufacturing kit illustrates the middle ground. Its contents may need control for picking and delivery even though the kit does not remain an installed assembly. The business should name that purpose explicitly and map its contents to installed demand. Whether a selected platform implements this through a kit, grouping, phantom or other mechanism requires version-specific verification. Those labels cannot establish the policy by themselves.

Boundaries should also make crossing relationships visible. The cooling module connects to the chassis, engine coolant path and vehicle electrical harness. An integration authority resolves compatibility decisions with the relevant endpoint owners. Moving the fan inside a supplier package does not remove the vehicle team's responsibility to establish compatibility with the harness. Detailed connection characteristics, operations and evidence belong in Chapter 05a.

Make or buy changes responsibility, not just the order

In an in-house arrangement, the programme could define the brackets and module composition, buy the radiator and fan, and assemble the module itself. The engineering authority would control the intended combination; manufacturing would define its assembly approach; procurement would order against the applicable technical requirements.

Buying a supplier-designed module changes the information needed at the boundary. The programme needs an agreed account of vehicle interfaces, environmental and functional requirements, permitted variation, change notification and acceptance deliverables. It also needs enough constituent visibility for its support and traceability obligations. This does not necessarily mean acquiring every detail of proprietary supplier design. The required visibility is a contractual and engineering decision.

A supplier can own internal design while the programme controls the vehicle-level integration decision. That division needs to survive a change of supplier. If a second supplier offers a nominally equivalent module, purchasing similarity does not establish engineering interchangeability. The responsible authority must assess the applicable requirements, interfaces, installation and support consequences before authorising substitution.

Changing from buying a complete module to assembling it internally may preserve the delivered vehicle function while changing procurement demand, manufacturing work, inspection responsibilities and records. The identity decision depends on the programme's approved rules for definition and interchangeability. Record that reasoning rather than declaring that every sourcing change always requires either a new part number or only a revision.

Release while the rest of the vehicle evolves

Vehicle 01 need not wait for every Vehicle 04 detail before its cooling work proceeds. It does need a sufficient definition for the particular commitment. Releasing a bracket for manufacture requires controlled geometry and specification, a resolved basis for its interfaces, applicable configuration and authority to accept any remaining exposure. Releasing a purchased module requires an adequate technical purchase package. Authorising installation requires compatible receiving interfaces and an applicable installation definition.

These commitments can mature at different times. A preliminary packaging arrangement may support analysis without authorising purchase. A module may be ready to order while its vehicle installation instructions remain under development. The release record therefore states the intended use, prerequisites, unresolved assumptions, responsible decision owner and limits of authority. Whole-vehicle design completeness is not the only gate, but a local release cannot silently authorise downstream work for which information is missing.

Consider the customer changing hot-climate operating conditions while Vehicle 01 is in build. The changed requirement in DOORS initiates assessment; it does not automatically authorise a different fan. System design assesses thermal and electrical implications, mechanical design assesses packaging, and manufacturing and procurement identify committed work and orders. Service and verification responsibilities contribute before the business decides the change's disposition and vehicle applicability.

The resulting decision could retain the existing arrangement for one vehicle and authorise a revised arrangement for others, subject to the required technical and contractual decisions. The outcome is intentionally unspecified here. A defensible record distinguishes the requested change, agreed requirement state, approved technical configuration and authority to implement it. It then traces affected definitions and work to the relevant vehicles.

A supplier's connector change similarly reaches beyond the supplier assembly. It can affect the mating harness, ordered material, installation readiness and service replacement compatibility. The structure supplies the affected-use map; Chapter 05a explains the connection detail. Changing a released definition is not evidence that Vehicle 01 has been modified. Implementation requires records showing the actual disposition of its affected material and work. CM-II supplies the change-management basis; this example does not establish detailed framework conformance.

Scale the relationships and authority

The four vehicles make the reasoning visible. A major defence or infrastructure programme may involve millions of occurrences, multi-year manufacture and thousands of people. At that scale, a reusable bracket definition can have many contextual uses across products, suppliers and work packages. Its revision history alone cannot reveal which installed positions require action.

The model must support scoped questions: which applicable uses reference this definition, which baselines and contracts are affected, which work packages have committed material, and which physical instances need disposition? People should not have to open an entire geometric model or inspect every occurrence manually to answer them. This is an information and governance requirement, not a performance claim for the selected tools.

Large structures also need boundaries that fit delivery. A supplier package, installation zone and functional system can intersect without sharing one hierarchy. Delegated authorities need published interfaces and escalation routes so that a local change does not bypass a neighbouring design authority. Stable contextual references and controlled mappings allow work packages to remain intelligible over years of changing staff and suppliers.

Control should follow consequence. A temporary review grouping does not require the same release machinery as a contracted module. A small task within an established definition can use proportionate controls, while a change to a widely reused interface needs broader impact assessment. Programme scale justifies disciplined relationships and delegated decisions; it does not justify identical bureaucracy for every edit.

Implement the decisions after defining them

NX, Capital, Teamcenter and SAP are the selected core platforms. The allocation is to use NX for mechanical definition, Capital for the relevant electrical definition, Teamcenter for controlled product and manufacturing structures, and SAP for agreed enterprise resource planning responsibilities. These responsibilities require an implementation design and verification of the installed capabilities.

Before configuration, the business must decide who controls each definition and relationship, how views reconcile, which identities persist across tools, and where actual vehicle configuration is recorded. Requirements, architecture, analysis, product definition, manufacturing planning, execution and acceptance evidence retain distinct responsibilities even when linked through the same platform. Additional systems-engineering, execution or service capabilities may be needed.

Implementation validation should exercise the worked example: reuse the bracket in two positions; show the fan in several views without duplicate demand; buy a complete package without buying its contents again; and apply a change to selected vehicles while retaining the earlier authorised configuration elsewhere. Platform versions, modules, licensing and integration behaviour determine how these responsibilities can be implemented. The successful outcome is a traceable commitment and its implementation, supported by software configured to preserve the distinctions explained here.