05a — Joints, connections and installation definition
Evidence checked: 10 November 2026. Vendor statements below describe capability scope, not the selected installation.
A module is not connected merely because its parts are listed
The fictional programme comprises four customised internal-combustion utility vehicles. Its cooling module contains a radiator, fan, hoses and mounting brackets. Listing these items establishes what is present. Positioning them establishes where they are intended to sit. Neither answer alone tells the business whether the module can be installed, connected, accepted and maintained.
At the chassis mounting, somebody must define the joined features and required joint characteristics. At the coolant boundary, somebody must establish compatible mating interfaces and the installed hose arrangement. At the fan, electrical connectivity must become a physical termination and an installed mating connection. Each boundary also needs an authorised way of making the connection and evidence appropriate to accepting the resulting vehicle.
Vehicle 01 is in build, Vehicle 02 has major components ordered, and Vehicles 03 and 04 are being planned. These illustrative stages make connection readiness a delivery question. A team may be ready to manufacture a bracket while a fan connector remains unresolved, provided the commitment does not depend on that unresolved interface or its exposure has been explicitly accepted. The programme does not wait for every vehicle detail to be complete; it establishes what must be known before each particular commitment.
Connection control must preserve design intent, executable work and evidence without confusing their authority. The actual technical criteria depend on the product and applicable programme obligations.
Put information where its meaning and authority belong
A connection joins identified endpoints in a defined product context. Its definition says what relationship is required and what characteristics govern it. The associated parts and consumables say what material is needed. Manufacturing planning says how the relationship will be realised. Execution records say what happened on a physical instance. Acceptance evidence supports the decision that the result meets the applicable criteria. These are related information responsibilities, even if a particular implementation presents several together on one screen.
A requirement explains a needed outcome or constraint. Architecture identifies functions and interfaces. Analysis supports a choice or demonstrates a predicted behaviour. Product definition specifies the intended connection. A process plan translates that definition into executable work. An inspection or test result records an observation; an acceptance decision gives that observation its authorised disposition. Moving a value between applications does not change which of these meanings it has.
NASA's interface-management guidance calls for interface definition, physical and electrical characteristics, compatibility control and configuration documentation. This supports treating the interface as an engineering responsibility that persists across organisational boundaries. It does not prescribe this record schema or make NASA practice a contractual obligation for these vehicles. NASA Systems Engineering Handbook, §6.3.
For each characteristic, identify its authoritative definition, responsible role and permitted derivations. A manufacturing engineer can then develop an operation without silently changing product intent. If the chosen process cannot achieve the definition, the issue returns for an authorised technical disposition. Copying a requirement into an instruction should preserve its source and revision rather than create an independent competing requirement.
Mechanical mounting: the fastener is only part of the joint
Consider a cooling-module bracket attached to the chassis. The fastener has a reusable part identity. Its occurrence identifies this particular use in the vehicle structure. The joint relates the relevant bracket and chassis features, together with the applicable fastener arrangement and other specified material. A bag of the correct fasteners does not establish that this particular mounting has been correctly defined or made.
The design definition needs enough information to establish the intended joint: which features meet, their geometry and permitted variation, the required joining arrangement and any governing characteristics. The responsible engineers determine what is necessary for the actual design and substantiate it through appropriate requirements and analysis. This chapter prescribes no fastener material, tightening value, locking treatment or universal installation standard.
Torque illustrates why assigning information by vocabulary fails. An explicitly specified tightening requirement may be part of controlled product definition. A process engineer may instead derive an installation parameter from an authorised joint requirement and an approved method. A tool may subsequently record the actual result during assembly. These are respectively a design characteristic, a derived process requirement and an execution record. They require different provenance and approval even when all three use the same unit of measurement.
Trace a derived process parameter to its design basis and approval, including conditions under which it remains valid. Changing material, surface condition, fastener arrangement or method may require reassessment; the relevant engineering authority decides the actual dependencies. An operator's recorded result does not retrospectively authorise the parameter used. Equally, an approved instruction is not evidence that the operation was performed.
If a bracket is welded, the same information distinction remains useful: intended joint geometry and characteristics, controlled process definition, then evidence of completed work. The applicable welding requirements and qualifications must be selected for the programme before prescribing them. No aerospace welding standard is assumed to govern this vehicle. Inspection scope and retained evidence should follow the adopted requirements and risk, rather than a rule that every connection needs an identical record package.
Fluid connections: define the interface and the installed arrangement
A radiator outlet and a hose end are endpoints, but their names are insufficient to establish compatibility. The controlled definition must identify the mating interface characteristics relevant to this design, the specified connection components and the intended installed arrangement. The responsible fluid-system and mechanical engineers must determine which requirements apply, including any necessary sealing, retention, routing, support, clearance and accessibility constraints.
The hose also has another end. A locally compatible radiator connection does not establish that the complete hose assembly reaches and connects to the engine-side interface as intended. Its route can cross module boundaries and depend on supports attached to surrounding structure. Those support relationships need their own definition or explicit links; they should not disappear because a supplier's delivery boundary ends at the radiator.
The process plan identifies the authorised installation method, preparation, sequence, resources and checks derived from that definition. Actual records identify the installed configuration and the required observations or test results. Acceptance criteria and methods must come from approved programme requirements. This is a conceptual description: it supplies no pressure, tightening instruction, seal selection or leak-test prescription.
A fuel connection provides a useful counterexample. It may resemble a coolant connection in a simplified assembly view, yet that resemblance establishes neither interchangeability nor common acceptance requirements. Its fluid, interfaces, environment and governing obligations must be assessed on their own basis. Reusing a generic connection template should therefore reuse the information questions, not silently reuse engineering answers.
Electrical relationships: circuit, termination and mating
The fan participates in an electrical function, occupies a place in the cooling module and connects to a vehicle harness. Those descriptions refer to the same installed equipment through different views. Logical connectivity identifies which electrical functions or terminals must connect. It does not by itself completely specify the physical harness or establish that the vehicle connector has been mated correctly.
For this conceptual model, distinguish the connector housing, its identified cavities, the contacts or terminals associated with those positions, and the wire terminations. A cavity designation locates a position within a particular connector context; it is not a globally unique electrical endpoint. The supplier's terminology and controlled component information must resolve whether a designation refers to a housing position, contact, equipment pin or schematic connection point.
The fan-side connector occurrence and harness-side connector occurrence must have a controlled mating relationship. Within the harness, a wire termination must relate the conductor to the specified contact and position. A splice relates conductors at a defined physical junction; it is not interchangeable with a detachable mating interface. Where shielding or grounding is required, its intended continuity and termination arrangement need explicit definition. Merely drawing a line between the fan and power source leaves these physical decisions unresolved.
Physical harness definition also addresses routing and support interfaces. Installation must reconcile that definition with the surrounding vehicle and the module's service access. Manufacturing the harness termination and mating the completed harness to the fan are separate operations, potentially performed by different organisations at different times. Evidence from harness manufacture does not establish that the later vehicle mating operation occurred.
The detail required for termination instructions, inspections and tests depends on the adopted component specifications, process controls and programme obligations. A record chain relates the applicable harness design to its manufacturing instruction, the resulting harness instance, vehicle installation and required acceptance evidence. It must preserve enough context to distinguish an incorrect cavity assignment in the design from an incorrectly executed termination or an unmated installation.
Siemens describes Capital as covering electrical connectivity, harness design, manufacturing, documentation and after-sales, with connectivity, components and topology among harness-design inputs. That capability scope supports investigating linked electrical representations; it does not verify the precise cavity schema, installed applications or automatic transfer into vehicle execution records. Siemens, Electrical design.
A conceptual connection record
The following is an information checklist for the fan mating interface. The illustrative label “fan mating connection” names a concept, not a Teamcenter object type. Actual implementation may distribute the information across controlled records and relationships. Unresolved fields remain visible; a descriptive label must not imply release readiness.
| Information | Cooling-module example and purpose |
|---|---|
| Connection identity and kind | Stable identity for the fan mating relationship; distinguish it from internal terminations and module mounting joints. |
| Endpoint A occurrence and context | Fan-side connector use within the fan and cooling-module occurrence, including the controlled mating features or positions. |
| Endpoint B occurrence and context | Mating connector use within the vehicle harness occurrence; retain vehicle installation context even across assembly boundaries. |
| Endpoint definitions and revisions | References to both controlled component definitions and the relevant interface information at identified revisions. |
| Applicability and baseline | Which vehicle configurations and approved baseline use this pairing; applicability decisions for Vehicles 01–04 remain explicit. |
| Characteristics | Required mating compatibility, position relationships and any approved installation constraints; reference authoritative definitions rather than invent values. |
| Source and rationale | Requirement, interface agreement, supplier definition and supporting analysis, with source revisions and approval context. |
| Owner and contributors | Accountable compatibility authority, endpoint design authorities and supplier responsibilities. |
| Material and process links | Applicable connector/contact material definitions, harness termination operations and vehicle mating operation. |
| Evidence and disposition links | Expected evidence categories, physical instance references when available, actual results, exceptions and acceptance disposition. |
A part identity answers which reusable definition is involved. A revision answers which controlled state of that definition is referenced. An occurrence identifies its use in a parent context. Applicability says where a definition or change is intended to apply; a baseline establishes an approved configuration reference. A physical instance is the actual installed item or assembly. None can substitute for the others.
For example, two connector occurrences can use the same part revision but have different circuit assignments and installation locations. Conversely, one occurrence position can be populated by different approved definitions for different vehicle configurations. The evidence must resolve the intended configuration at the time of work and the physical result, rather than follow an unrestricted link to whatever definition is newest today.
Who owns a connection crossing an assembly boundary?
The operating model assigns one accountable compatibility decision owner for each governed interface, with both endpoint owners contributing controlled definitions. For the cooling module, the supplier may own its connector definition while the vehicle harness authority owns the mating definition. The integration authority resolves compatibility, applicability and exceptions within delegated authority. Commercial responsibilities for notification and delivered evidence must support that arrangement.
This does not require the integration authority to author every detail. It requires a decision route when the two sides disagree or mature at different times. If the supplier owns both mating halves, the programme still needs the vehicle boundary, replacement implications and change obligations defined. If an assembly grouping changes, the connection's identity and endpoint context must be deliberately retained or migrated; compatibility cannot depend on its original folder location.
Early release should identify the interface information being committed, outstanding assumptions, affected work and authority accepting exposure. Purchasing a fan against a provisional connector assumption differs from releasing a fully agreed mating definition. Neither should be represented merely as “module released”. The detailed readiness and change processes belong elsewhere in the manuscript; here the essential requirement is that the connection exposes the information those decisions need.
Follow a supplier connector change
Suppose the cooling-module supplier proposes changing the fan connector. This is a fictional change with no predetermined technical outcome. Begin with the supplier's changed definition and reason, then compare both mating sides and their applicable revisions. Determine whether the change affects housing compatibility, position assignments, terminals, harness manufacture, routing, access, installation instructions, inspection or service replacement. A connector substitution cannot be assessed solely through the cooling-module material list.
Assess the four vehicles separately. Vehicle 01 may already contain material or completed terminations requiring inspection and a disposition. Vehicle 02's orders may need amendment, retention or segregation decisions. Vehicles 03 and 04 may adopt a revised pairing after approval. These are possible paths to assess, not assumed outcomes. Stock, work in progress, supplier deliveries and installed equipment each need identified configuration and authorised treatment.
The impact review also asks whether the changed interface affects a customer requirement held in DOORS. A customer requirement revision, supplier proposal, technical approval and contractual authorisation are separate decisions. No DOORS edition or automatic synchronisation is assumed. The programme must retain the relevant requirement baseline and disposition even if the change proves to have no requirement impact.
Once authorised, update the affected product definitions, connection applicability, process plans, purchasing information and support instructions. Specify the evidence needed for each affected physical unit and work package. Rework, where required, needs its own authorised instruction and subsequent evidence. Preserve earlier results and their dispositions so a later reviewer can reconstruct what was originally built and what changed.
Close the change through implementation evidence appropriate to each disposition. Releasing a new connector definition establishes intended future information; it does not prove that a harness was changed, an order amended or Vehicle 01 accepted. CM-II provides the change-management basis; the illustrative chain does not establish detailed framework conformance.
Map responsibilities before configuring applications
NX is the selected mechanical computer-aided design platform. Its role is mechanical geometry, mounting and interface product definition, with suitable controlled annotations or linked specifications. Whether a particular characteristic is authored in NX or referenced from another controlled definition requires implementation design. No specific joint object, licence or downstream instruction automation is established here.
Capital is the intended authoring environment for the relevant electrical connectivity and harness detail, subject to selected applications. Teamcenter, the selected product lifecycle management platform, is a candidate for governing linked product configuration, engineering and manufacturing structures, process definitions and controlled change. SAP, the selected enterprise resource planning platform, is a candidate for purchasing and production context and selected quality or service records. These intended responsibilities do not establish native connection schemas or universal mastership.
Implementation must resolve stable identifiers, revision resolution, occurrence mapping, applicability exchange, supplier packages and permissions. It must also decide where execution and acceptance records live and how their links survive migration. Dedicated manufacturing execution, quality, analysis, software or service capabilities may be needed. The presence of the four selected platforms does not settle these responsibilities, and SAP is not assumed to be the as-built authority.
Scale the relationships and preserve their history
At major defence and infrastructure scale, millions of connections and occurrences, multi-year manufacture and thousands of people make local memory inadequate. The information architecture must support scoped impact queries across endpoint uses, revisions, applicability, supplier boundaries and physical instances. Opening a complete geometric assembly should not be the only way to find affected connections. These are requirements for implementation evaluation, not measured performance claims for any platform.
Long-lived evidence must retain meaning after designs, suppliers and applications change. Preserve the definition used for the work, the instruction revision, instance context, results and disposition with durable references and readable content. A link that resolves only to today's latest model cannot explain an earlier acceptance decision. Retention, access and migration arrangements require explicit programme decisions.
Control should remain proportionate. A repeated low-complexity connection may use an approved common definition with contextual occurrences and the required evidence, rather than a separately authored dossier for every use. Critical or unusual boundaries may warrant deeper review. The governing question remains practical: can the responsible person determine what was required here, who authorised it, what was actually done and why the resulting configuration was accepted?