01 — What engineering means

Engineering begins with an intended outcome

A utility vehicle is commissioned to do useful work. The organisation must determine what that capability means in use, what constraints apply, and how a physical vehicle and its supporting arrangements can satisfy the need. A list of equipment and a geometrical arrangement cannot, by themselves, answer those questions.

Engineering means defining and justifying how a product will meet its intended need, then supporting its realisation and lifecycle with controlled information and evidence. Its lifecycle scope is consistent with NASA's description of systems engineering as encompassing design, realisation, technical management, operations and retirement. Source: NASA systems engineering fundamentals.

The four customised vehicles provide a common setting for following these decisions from need to physical delivery.

Design is a body of decisions and their resulting definition

Design is both an activity and an outcome. As an activity, it resolves needs and constraints into a solution. As an outcome, it is the information specifying that solution.

A designer deciding where to place the cooling module is making more than a spatial decision. The location affects connections, structural support, environmental conditions, installation sequence, inspection access and eventual removal. Those consequences may require calculations, interface agreements, supplier commitments and maintenance studies before the location is adequately justified.

A computer-aided design (CAD) model can represent shape and arrangement. Depending on its content, it can also carry dimensions, tolerances and other product-definition information. It does not automatically contain the originating requirement, the assumptions behind a calculation, the supplier's contractual obligation or the evidence that an installed item passed its acceptance test.

The engineering definition therefore comprises related information with different purposes:

These are related views, not a mandatory sequence of documents or a requirement to use one application.

The cooling module makes this distinction tangible. Its radiator and fan need mechanical mounting to the vehicle; its hoses need compatible fluid connections; its fan needs an electrical supply and a compatible harness interface. A geometrical arrangement can show where these items sit, but the team must also define the conditions each interface must satisfy. Mounting, hose access and harness routing constrain each other. Moving the module to simplify one connection may obstruct maintenance of another.

The definition of those connections, the operations that make them and the records showing their completion serve different purposes. A planned connection is not evidence that a technician made it on Vehicle 01. Detailed assembly boundaries and joint ownership belong in Chapter 05 and Chapter 05a; here the point is that engineering must make the relationships understandable before anyone can rely on them.

Requirements must be understood before they can be designed against

Customer requirements are held in DOORS and can change during design. Suppose the customer changes the required hot-climate operating conditions. Recording the request does not establish technical feasibility, contractual agreement or permission to modify a vehicle. Engineering must assess cooling, cabin heating, ventilation and air conditioning, electrical demand, packaging and the evidence needed to assess the revised requirement. The result might require further investigation rather than an immediate design change.

Retain the requirement baseline used for a decision, the change disposition, vehicle applicability and downstream implementation evidence. A baseline is the identified reference set against which the team makes and controls subsequent decisions. This does not assume a particular DOORS edition, automatic synchronisation or automatic acceptance of a customer request.

A requirement is useful when its meaning, context and means of assessment are sufficiently clear to guide a decision. A statement that equipment must be maintainable is not yet enough to define access, tools, removal arrangements or acceptable maintenance effort.

Engineering investigates the intended maintenance activity, identifies constraints and develops measurable criteria. It then allocates those criteria to the equipment, its surroundings and the supporting arrangements. A supplier may be responsible for the internal serviceability of a package while the vehicle integrator remains responsible for access to it.

That division creates an interface. Both parties can satisfy their own isolated assumptions and still produce an unmaintainable installation. The engineering organisation must make the shared assumptions explicit and establish who controls them.

Requirements analysis, architecture and detailed design therefore interact. Analysis can expose an infeasible requirement or a missing constraint. Supplier information can invalidate an assumed interface. A sound process allows these discoveries to change the definition through controlled decisions.

Buying equipment does not transfer every engineering responsibility

Consider a bought-in cooling module for our fictional four-vehicle programme. The supplier may own its detailed internal design. The vehicle programme still needs to define the required duty, installation constraints, interfaces, required information, acceptance evidence and support deliverables.

Procurement owns the commercial sourcing and agreement process under the organisation's delegated authority. Engineering owns the technical definition and assessment within its assigned authority. Supplier quality, manufacturing, support and programme management contribute their own requirements and decisions.

The purchase specification must connect to the contractual deliverables. If installation depends on approved interface information by a particular date, that information is itself a managed deliverable. Waiting only for the physical equipment to arrive is too late.

Likewise, receipt of a supplier drawing does not establish that the interface has been accepted. Technical review, commercial acceptance, release for use and payment milestones may be related, but they are distinct decisions. The operating model must define their relationships.

Manufacture, testing and maintenance are design concerns

A product definition must enable someone to realise the intended product. Engineering and manufacturing engineering jointly establish such matters as material requirements, tolerances, joining requirements, inspection access and assembly constraints within their respective responsibilities.

Manufacturing engineering then develops the process, sequence, resources and instructions needed to produce the result. Product and process definition influence each other. An apparently valid component design can be impractical to manufacture or impossible to install in the planned build sequence.

Testing also has to be designed. The organisation needs to know what will be demonstrated, using which method, on what configuration, with what acceptance criteria. Access, instrumentation and test facilities can create design requirements long before a test takes place.

Maintenance design addresses the product in service: access, diagnosis, isolation, removal, replacement, repair, tools, spares and supporting information. These decisions can change the physical design. Treating maintenance information as a document-writing exercise after design completion misses those decisions.

Verification establishes whether specified requirements are met; validation addresses whether the product meets the intended need in its intended context. Both need a defined subject and usable evidence. Source: NASA systems engineering fundamentals.

Engineering continues while manufacture proceeds

The programme begins manufacture before every part has been designed. The resulting problem is to determine which commitments are justified by the information available.

Ordering a long-lead equipment package, fabricating a structural assembly and installing equipment require different information. Each decision needs an identified scope, controlled inputs, sufficient interface definition and an understanding of unresolved dependencies.

Assess readiness for the particular commitment. A released work package can be complete for its authorised use while other parts of the vehicle remain under development. Where assumptions remain, the decision should identify their owner, the permitted bounds and the consequences if they change.

Suppose a supplier proposes an interface change after Vehicle 01 is in build, Vehicle 02 has major components ordered and the remaining vehicles are still in planning. The technical solution may be common, but implementation need not be identical. One vehicle may need rework, another a contract variation, and another only an update before its first release. The disposition must establish the applicable configuration for each vehicle and preserve evidence of the decisions and completed work.

A revised model alone cannot close that change. The organisation also needs to resolve affected purchases, manufacturing plans, work in progress, installed items, test arrangements and support information. CM-II provides the change-management basis; approval must lead to controlled implementation and evidence of the affected work.

What changes at major-programme scale

Consider the same identification problem on a major defence or infrastructure programme with millions of occurrences, years of manufacture and thousands of people. These are scale conditions for comparison, not quantities claimed for our four vehicles. One bracket part number might be used at many installation positions. Its revision identifies a particular definition; an occurrence identifies a particular use within a product structure. The physical bracket fitted at that position is an instance. Changing the part definition does not establish which occurrences require the change or which physical items have received it.

For example, a supplier's revised connector may affect one cooling-module installation already completed, another awaiting its harness and a third still being planned. The team needs to find the relevant occurrences and mating interfaces, then establish applicability and disposition. A catalogue search for the connector part number cannot by itself answer whether a particular installation was completed to an earlier authorised definition. That answer depends on the configuration context and its execution and inspection records.

At large scale, no single engineer can approve every local decision or personally inspect every installation. Delegate bounded decisions to responsible teams while retaining shared interface constraints and discoverable evidence. A local installation team needs the authorised inputs and acceptance criteria for its work package. A coordinating authority needs to see unresolved cross-boundary effects and which decisions exceed that team's remit. Supplier evidence must remain associated with the configuration it describes, even as other teams move to later revisions.

This calls for explicit responsibility and reliable queries, rather than an expectation that everyone knows the latest conversation. It does not require the same administrative burden for replacing one agreed component as for changing an interface across many suppliers. The extent of assessment and approval should reflect the commitment and its consequences. This does not establish regulatory compliance or measured performance.

What makes the organisation model-based

For this reference, a model-based organisation uses explicit, controlled models and their relationships to perform engineering work and support decisions. A system model can connect requirements, architecture and verification planning. Mechanical, electrical, analytical and manufacturing models provide their own specialised views.

NASA's Systems Modeling Handbook provides an example of system modelling supporting requirements and verification/validation work products. It is a useful conceptual reference, not the governing process for this fictional vehicle programme. Source: NASA-HDBK-1009A.

The enterprise model extends those connections into contracts, manufacturing execution and through-life records. It must distinguish what was intended, what was authorised, what was actually built and what is currently installed. A link is useful only when its meaning, applicable version and ownership are understood.

NX for mechanical CAD, Capital for electrical systems, Teamcenter for product lifecycle management and SAP for enterprise resource planning are the selected core platforms for this book. Their implementation chapters will explain how they support the operating model. The architecture must also assign responsibility for system modelling, software, analysis, execution and service information; naming the four core platforms does not resolve every responsibility.

The practical test is whether a team can follow a decision through the enterprise: identify the need it satisfies, the definition it changes, the vehicles and commitments it affects, the authority that approved it and the evidence that it was implemented correctly.

Where the argument goes next

The remaining chapters explain how to make these connections dependable. The book map separates the enterprise model, technical disciplines, configuration and change, industrial delivery, assurance and platform implementation.