07 — Architecture and interface management

Separate teams can each deliver a satisfactory component and still produce an unsatisfactory vehicle. A fan can meet its own specification while the harness cannot supply its demand. A cooling module can fit its allocated envelope while its hoses cannot be installed or serviced. Architecture and interface management address the responsibilities and relationships that component-level approval leaves unresolved.

Architecture describes the organisation of the system and the reasoning behind it: which elements perform which functions, how they interact and which constraints govern their combination. An interface is a boundary across which elements exchange something or constrain one another. That may be energy, material, information, force, space, access or responsibility. An interface remains an engineering concern even when a purchase boundary or assembly tree hides it from one team's normal view.

Choose boundaries for decisions

The cooling module contains the radiator, fan, hoses and mounting brackets. It contributes to thermal management but depends on the engine, electrical supply, control behaviour, chassis and surrounding airflow. A supplier may deliver it as a package, manufacturing may install it as one module and service may replace the fan separately. These boundaries support different decisions and need not coincide.

A functional boundary identifies a responsibility such as heat rejection. A physical boundary identifies interacting components and installation features. A contractual boundary identifies supplied scope and obligations. A manufacturing boundary identifies the work and resources needed to assemble or install. Confusing them can leave a hose connection outside both suppliers' scope or assume that a purchased package arrives ready for every vehicle-side operation.

The systems lead should define the architecture views needed to expose these relationships. Each view must identify its purpose, elements, applicable configuration and links to other views. The architecture is useful when a change can be traced through responsibilities and interactions. A complete-looking diagram without controlled endpoint definitions provides little protection against incompatible releases.

NASA's interface-management guidance addresses interface definition, compatibility, configuration control and responsibilities across boundaries. It provides a useful engineering reference; its institutional process is not automatically a contractual obligation for these vehicles. NASA Systems Engineering Handbook, interface management

One compatibility decision, several technical owners

Each endpoint owner controls its own definition. The cooling supplier defines its module-side characteristics; the harness authority defines the mating electrical installation; the chassis authority defines the mounting provisions. An accountable integration authority maintains the compatibility decision and resolves conflicts within delegated limits. This role need not author every detail. It must ensure that both sides agree the same boundary and that changes reach all affected owners.

An interface agreement should identify the endpoints in context, responsible organisations, required characteristics, source definitions, applicable revisions, assumptions, verification obligations and change route. Where a characteristic remains unresolved, assign an owner and a closure date tied to the affected commitment. “To be confirmed” without consequence is not a usable interface constraint.

A supplier can own both mating halves while the programme retains responsibility for the vehicle-side effects. The pair may alter power demand, routing, access or replacement arrangements. Conversely, ownership by different suppliers demands explicit agreement rather than reliance on similar catalogue descriptions. Commercial scope must support technical responsibility through defined notification duties, deliverables and rights to the information needed for integration.

The integration authority escalates issues that exceed its delegation: a changed vehicle requirement, unacceptable safety exposure, contract amendment or delivery impact requires the appropriate programme decision. Interface agreement cannot authorise every consequence merely because the engineers agree the two parts will mate.

Budgets expose shared constraints

A budget divides a constrained resource or performance allowance among contributors. Vehicle mass, electrical demand, heat rejection and occupied space are familiar examples. A budget record needs the overall limit or target, operating case, allocations, predicted or measured contributions, uncertainty and reserve. Those categories should remain distinguishable. A target is not a measured result, and unallocated reserve should not be consumed independently by several disciplines.

For electrical demand, identify which consumers operate together in each case. Simply adding catalogue maxima may be unnecessarily conservative; assuming they never coincide may be unsafe or technically inadequate. The responsible engineers justify the combination rule. A higher-demand fan must be assessed against generation, distribution, protection, control and the relevant operating modes. Nominal supply compatibility alone is insufficient.

Thermal budgets need boundary conditions and heat sources. Mechanical packaging needs envelopes, tolerances, movement and installation access rather than only nominal surfaces. Mass allocation must identify whether it represents a prediction, authorised allowance or measured state. The systems lead reconciles these contributions and retains the assumptions behind the vehicle-level conclusion.

Budget review should focus on decision exposure. An uncertain fan selection may be tolerable during initial layout while becoming unacceptable before harness manufacture. Margin is not permission to ignore uncertainty; it is an explicitly managed part of the argument. No numerical limits or reserve percentages can be prescribed without the actual vehicle obligations and technical basis.

The cooling interfaces as one compatible set

At the coolant boundary, define the relevant endpoint characteristics, operating conditions, route constraints and responsibilities for supporting and connecting the hose. At the mounting boundary, control geometry, loads, tolerances and the installation constraints needed by both module and chassis designers. At the fan boundary, control electrical characteristics, mating definitions, signal meaning and behaviour. Treat these as interacting constraints: moving a mount may change hose routing and harness support even if neither connector type changes.

Multidisciplinary compatibility includes more than physical fit. Electrical compatibility includes the meaning and timing of control signals and behaviour when signals or supply are absent. Mechanical compatibility includes access for assembly and service, relative movement and the tolerance conditions under which a connection must work. Fluid compatibility requires the responsible specialists to define the applicable characteristics and acceptance basis; this chapter does not select a hose standard, pressure or test method.

A logical fan-control connection is therefore distinct from the harness termination and from the installed mating operation. The architecture establishes responsibilities and governing boundary conditions. Detailed connection definition establishes the relevant endpoints and characteristics; manufacturing planning defines the operation; actual records establish completion and inspection. Joints, connections and installation definition develops those detailed distinctions. Architecture must nevertheless identify the connection owner and evidence responsibility now, rather than delegate an undefined problem downstream.

Baseline an interface before relying on it

An interface baseline identifies the agreed boundary definition and its configuration context. It should reference both endpoint definitions, shared characteristics, assumptions, review decisions and applicable vehicles. Baselining only the supplier drawing can leave the vehicle side unconstrained. Baselining a general diagram can leave the actual mating definitions unresolved.

Before releasing an early work package, determine which interface characteristics that work commits. Bracket manufacture may require fixed mounting geometry and loads while leaving unrelated harness detail open. If a pending fan selection can change those loads or the envelope, assess the exposure and either close the dependency, restrict the work or obtain authorised acceptance of the consequences. “The module is released” is too coarse a statement when different commitments need different information.

Manufacture and design can therefore overlap through bounded commitments. The baseline must make the boundary of that permission clear, including what may continue, what is held and what event requires reassessment. Manufacturing personnel need accessible instructions and applicability; they should not have to interpret a systems model to infer whether today's operation is authorised.

Change the interface without losing the vehicle

The cooling supplier proposes a different fan connector. Begin with the reason, changed characteristics and proposed introduction, then identify both endpoint uses. Assess mating compatibility, circuit assignment, demand and protection, routing, harness manufacture, installation access, inspection and service replacement. A connector that fits mechanically may still be electrically wrong; matching part-family names is not an engineering compatibility argument.

Vehicle 01 is in build, Vehicle 02 has major components ordered and Vehicles 03 and 04 remain in planning. Establish the actual position of material and work before choosing a disposition. Vehicle 01 may retain the earlier compatible pair, or require an authorised modification. Vehicle 02 may need an order amendment and supplier segregation. Vehicles 03 and 04 may adopt the revised pairing at their planned release. These outcomes depend on the assessed change, contractual basis and vehicle obligations.

The interface authority records the compatible combinations and explicit applicability. Configuration control preserves the old baseline and links the new one to the change decision. Procurement confirms order implementation; manufacturing confirms revised instructions and work disposition; verification confirms the evidence needed for each configuration. Service receives the replacement implications. Closure requires those downstream results, not just approval of a new connector drawing.

A hot-climate requirement change follows the same architecture through a different entry point. Starting from the changed DOORS requirement, reassess thermal performance, fan duty, electrical demand, packaging and verification cases. Preserve evidence that remains valid and identify precisely which assumptions or configurations invalidate the rest. A requirement change does not automatically mandate one component substitution, and an interface change does not automatically change the customer obligation.

Models, tools and scale

NX provides the selected mechanical design environment; Capital the selected electrical design environment. Siemens describes Capital capabilities across electrical connectivity and harness engineering, but exact applications, versions and integrations determine what is available. Siemens Capital electrical design

Teamcenter can support controlled lifecycle information and SAP the enterprise transactions affected by a change. Neither platform name establishes where the interface agreement lives, how endpoint references resolve, how supplier data is exchanged or where installation evidence is authoritative. Define these logical responsibilities and test the exchanges against a complete connector-change scenario before prescribing native object types. Systems architecture, analysis, software and execution capabilities may require additional tooling and integration.

Across millions of occurrences, years of manufacture and thousands of people, the interface inventory must support scoped queries by endpoint, revision, supplier, work package and applicable physical configuration. Delegated authorities need clear boundaries and escalation; suppliers need controlled packages rather than uncontrolled copies of the whole architecture. Automated checks can identify missing owners, incompatible selection rules and unresolved characteristics, while engineering review judges whether the definition captures the relevant physics and behaviour.

The four vehicles can use a smaller inventory and combine roles. They still need explicit compatibility decisions wherever independent teams or commitments meet. The administrative burden should follow the consequence of error and the complexity of the boundary, while preserving the information needed to know what can safely be committed next.