03 — Model-based systems engineering

Can the vehicle perform its intended work, and what justifies that judgement? An attractive assembly model cannot answer this alone. The four customised internal-combustion utility vehicles must carry their agreed loads, reject engine heat, supply electrical consumers, withstand their environment and remain maintainable. These outcomes interact. Increasing fan capacity may improve cooling while increasing electrical demand, changing harness protection and reducing packaging space. Engineering must expose these dependencies before a local improvement becomes a vehicle-level failure.

Model-based systems engineering (MBSE) uses structured models to support that reasoning. Here a model is a deliberate representation of selected aspects of the system, with defined meaning, assumptions and intended uses. A function table, behavioural representation, allocation relation or performance model may be relevant; a model need not be three-dimensional. INCOSE promotes the transition of systems engineering to model-based practice, but its initiative does not prescribe this programme's tool or approval workflow. INCOSE MBSE Initiative

From need to allocation

Begin with the intended use. The customer needs a vehicle that carries an agreed payload in an agreed operating environment. A requirement turns part of that need into an obligation with conditions and an assessable outcome. The customer statement, the engineering interpretation and an internal design target should remain distinguishable. Otherwise the business cannot tell whether it has accepted an obligation or merely explored a solution.

A functional view asks what the vehicle must do: propel itself, carry load, reject heat, control temperatures and supply power. Functions describe required transformations or behaviour. They should include relevant modes: starting, sustained operation, shutdown and degraded operation can impose different demands. A cooling design that works in motion may fail during low-speed work. The model must make the operating case visible rather than hide it in an analyst's assumptions.

A logical architecture groups responsibilities without immediately selecting every component. A thermal-management element may coordinate heat rejection and fan control; an electrical-supply element provides energy and protection. A physical architecture allocates those responsibilities to the bought-in engine, radiator, fan, control equipment, wiring and associated installation. This sequence is a reasoning aid, not a compulsory waterfall. Supplier constraints or existing parts can force reconsideration of the logical grouping and even the requirement interpretation.

Allocation records responsibility for satisfying an obligation or performing a function. It is not proof of satisfaction. Nor is every allocation one-to-one. A cooling outcome depends jointly on airflow, coolant circulation, heat-exchanger performance, controls and installation. If each discipline receives the entire vehicle requirement without a defined contribution, everyone can assume someone else supplies the missing margin. The systems engineer therefore proposes a decomposition and identifies shared constraints; discipline authorities accept their contributions; the chief engineer resolves incompatible allocations.

The model should preserve the reason for decomposition. A derived electrical-demand constraint is justified by the selected thermal solution and operating case. If that solution changes, the derived constraint may need revision even when the customer's words remain unchanged. Conversely, a customer payload change may affect braking and structure without changing every cooling requirement. Typed relationships make those distinctions inspectable.

Analyses are arguments with conditions

An analysis predicts or evaluates an aspect of behaviour. Its result is meaningful only with its inputs, method, assumptions and configuration. For the cooling module, a thermal analysis needs the applicable engine duty, ambient conditions, radiator and fan definitions, airflow restrictions and treatment of uncertainty. A packaging analysis answers a different question, using geometry and installation envelopes. An electrical analysis assesses demand, supply and protection under identified cases. None can silently substitute for the others.

The model record links each result to the input revisions, scenario, analyst, checking decision and permitted use. A preliminary estimate may support reserving space but be insufficient to approve a supplier order. This does not make the estimate worthless: it defines its authority. Reusing it outside that authority requires an explicit judgement, not merely access to its file.

When the customer requests hotter operating conditions, the systems engineer first identifies which cases changed. Thermal specialists reassess rejection capacity; electrical specialists assess fan demand and control; mechanical specialists assess mounting, routing and clearances; manufacturing and supplier representatives identify committed work. The model brings their claims together. It does not choose a larger radiator automatically. The right outcome could involve a changed installation, operating limitation, different component combination or negotiation of the requested obligation.

Verification and validation

Verification asks whether specified requirements are met. Validation asks whether the resulting vehicle meets the intended need in its intended context. Passing a temperature test verifies only the obligations and conditions actually covered. If the agreed duty cycle omitted the customer's real working pattern, successful verification can coexist with unsuccessful validation.

Verification planning identifies the requirement revision, method, conditions, expected result, responsible organisation and configuration to be assessed. Completed evidence adds what was actually done, the physical vehicle or specimen, equipment and procedure identities, results, deviations and review. A relationship labelled “verified by” must distinguish a planned test from accepted results. NASA's handbook provides examples connecting modelled requirements and verification work products; these are useful guidance rather than this programme's adopted metamodel. NASA Systems Modeling Handbook

In this operating model, the verification lead judges evidence adequacy and the authorised acceptance role decides whether the obligation is discharged. The designer may explain an unexpected result but cannot erase it by updating a model. Where evidence is reused for Vehicle 04 from a Vehicle 03 test, the decision needs an equivalence argument covering relevant differences. Similarity of vehicle names is insufficient.

Governing a model that people can trust

A useful model has an owner, declared scope, controlled elements and review criteria. The systems lead owns the cross-system consistency argument. Discipline authorities own technical content within their competence. Configuration personnel preserve the identified baseline and relationships. The programme's technical authority approves its use for a stated commitment. These roles may be held by few people on the vehicle programme, but their decisions remain distinct.

Model integrity checks include unresolved allocations, inconsistent units, missing interface owners, unsupported derived requirements, obsolete analysis inputs and evidence linked to the wrong revision. Automated checks can find missing fields or broken links. They cannot determine whether the decomposition represents the real physics or whether the operating scenario is adequate. Model review needs engineers who can challenge the assumptions as well as maintain the notation.

A baseline identifies a coherent set of model elements and referenced information for a purpose. It should be reproducible even when authoring continues. A model diagram exported last week and an independently updated requirement list do not necessarily form a consistent decision basis. Baseline membership, referenced versions and unresolved exceptions need to be recoverable.

Concurrent commitments

Vehicle 01 is in build; Vehicle 02 has major equipment ordered; Vehicles 03 and 04 remain in planning. A hot-climate request therefore creates different exposures. Work on Vehicle 01 may continue within unchanged interfaces while cooling installation is held. Vehicle 02 may require a supplier hold or amendment. Vehicles 03 and 04 can incorporate an approved solution before equivalent commitments. These are illustrative dispositions requiring actual assessment, not predetermined instructions.

For an early bracket-manufacture decision, the required model maturity is local and explicit. The decision needs an agreed mounting envelope, loads and interface assumptions, the applicable bracket definition, remaining uncertainties, the consequences of later change and an accountable owner. It need not wait for every trim component. If fan selection remains capable of changing bracket loads or geometry, that dependency must either be closed or accepted as exposure by the authorised role.

This is the practical value of connected models: they explain why a work package is sufficiently defined and what would invalidate that judgement. They do not make early work risk-free. The lifecycle framing allows iterative and concurrent processes but does not prescribe this local release gate. ISO/IEC/IEEE 15288:2023 scope

From systems model to enterprise

The working definition of a model-based enterprise extends beyond MBSE to the business arrangements connecting engineering decisions with contracts, purchases, manufacturing plans, execution and support. A system allocation is not an engineering bill of materials, a manufacturing operation or proof that a fan was installed. Those information classes need their own authority and controlled relationships.

The selected platforms have distinct intended roles: DOORS holds customer requirements, NX supports mechanical definition, Capital electrical-system definition, Teamcenter product lifecycle management, and SAP enterprise resource planning. These selections do not establish a complete systems-modelling and acceptance environment. The information model defines the logical distinctions; requirements and interfaces develop the decisions. Exact modules, exchanges and authoritative fields require implementation design.

At major defence or infrastructure scale, millions of occurrences, years of manufacture and thousands of people make personal recollection unusable as configuration control. Models need partitioning, delegated ownership, supplier boundaries, access controls and repeatable baseline queries. A central team cannot manually inspect every relation at every release. It must define risk-based review and automated integrity checks while retaining technical challenge for consequential decisions. The four vehicles need the same clarity of meaning with proportionate administration, not the full staffing structure of a major programme.