24 — Safety, assurance and security

A vehicle can match its drawings and still be unsuitable for its intended use. The drawings may embody an incomplete requirement, a test may omit an important operating condition, or maintenance may defeat a protection that worked at delivery. Assurance is the disciplined explanation of why a particular commitment is justified by the available evidence. It connects the intended use, the possible consequences of failure, the definition being assessed and the conditions under which confidence remains valid.

Safety concerns harm arising from the system and its use. Security concerns protection against threats, including deliberate interference with products, information and supporting services. Quality concerns whether controlled processes and products meet their requirements. These responsibilities overlap without becoming interchangeable. A correctly manufactured connector may have an unsuitable interface design; a valid test report may be maliciously substituted; an authorised software update may invalidate an earlier safety assessment. Each problem requires a different investigation and a connected disposition.

Establish the obligation before choosing the evidence

The programme must establish which obligations govern each product, activity and delivery. Inputs include the intended operating environment, customer contract, applicable legislation, supplier commitments and any explicitly adopted standards. Record the source, applicability, accountable interpreter and required demonstration. A customer acceptance signature does not replace an external obligation, and a supplier declaration does not automatically demonstrate the integrated vehicle's behaviour.

The four utility vehicles do not acquire a universal certification route merely because they contain engines or will operate in difficult conditions. Road use, workplace use, customer restrictions and destination may lead to different obligations. Resolve those particulars with competent specialists before making the affected commitment. The engineering record should state which determination was made and where its supporting evidence resides, rather than simply displaying a generic compliance flag.

This operating model assigns an obligation owner to maintain that record and a technical authority to determine the engineering response. Commercial authority determines the contractual commitment. Where an external approval is required, identify its actual decision maker and timing. No internal change board can grant an approval reserved to someone else.

Build an argument that can be challenged

An assurance argument starts with a bounded claim: this identified configuration is suitable for this identified use under stated conditions. Supporting reasoning decomposes that claim into questions that can be answered. What hazardous situations have been considered? Which preventive or protective measures address them? What evidence establishes the measures' effectiveness? Which assumptions remain dependent on operators, maintainers or suppliers?

Keep the claim, reasoning and evidence distinguishable. A test result is evidence of what happened during an identified procedure on an identified configuration. The argument explains why that result supports a wider conclusion. If the tested configuration differs from the delivery configuration, an explicit equivalence argument or further work is needed. A folder containing many reports does not supply this reasoning by itself.

NIST Special Publication 800-160 Volume 1 Revision 1 treats security as part of systems engineering across the lifecycle. It supplies a conceptual foundation for integrating security concerns into engineering work; it does not establish a vehicle certification route or validate a particular enterprise implementation. NIST, Engineering Trustworthy Secure Systems.

For this programme, maintain an assurance record linking important claims to requirements, hazards or threats, design measures, verification results, unresolved findings and operating restrictions. The representation can be a controlled document or connected records. Its essential property is that a reviewer can follow the reasoning and identify where confidence depends on incomplete work. A green workflow state without those relationships is inadequate.

Proportionate challenge and authority

The engineer creating a design should explain its justification. The design authority accepts responsibility for its technical adequacy within the assigned boundary. Assurance personnel challenge the argument, evidence and omissions. Manufacturing and service personnel contribute evidence about whether the intended controls can actually be executed. The person accepting residual exposure must have the delegated authority and information necessary for that decision.

Independent challenge means freedom to question the work and escalate unresolved concerns without the delivery owner quietly closing them. It does not necessarily require a separate organisation for every minor change. Choose the degree of separation, competence and review depth according to consequence, novelty, uncertainty and applicable obligations. A change affecting a protective function warrants more challenge than correcting an unambiguous publication error. The reason for the routing should be recorded so that schedule pressure cannot silently redefine significance.

A review finding needs an owner, a disposition and evidence of closure. “Accepted” is incomplete if it does not say what was accepted, by whom, for which configurations and under which conditions. Some findings prevent release; others permit a bounded commitment with a hold point before later work. Distinguishing these outcomes allows manufacture to proceed where justified while preserving genuine barriers.

Hot-climate requirements during manufacture

Vehicle 01 is in build, Vehicle 02 has major equipment ordered, and Vehicles 03–04 remain in planning when the customer requests changed hot-climate operating conditions in DOORS. The requirement proposal is an input to assessment. It does not automatically amend the contract or authorise modifications.

The systems team identifies affected cooling, heating, ventilation and air conditioning (HVAC), electrical demand, packaging and operating assumptions. The bought engine and transmission suppliers must provide relevant limits and interface information within their contractual scope. The HVAC and harness suppliers assess their own equipment and interfaces. The vehicle technical authority owns the integrated conclusion; separate supplier acceptances cannot establish that conclusion by addition.

The cooling module illustrates the assurance chain. Mechanical mounting must remain compatible with the chosen installation. Fluid connections must meet the controlled connection definition and be accessible for execution and inspection. Electrical interfaces must preserve the intended fan behaviour and diagnostic functions. Software and calibration may influence that behaviour, so the assessment identifies their applicable releases as well as the radiator, fan, hose and bracket definitions. These are assessment questions, not an assertion that a particular component must change.

The team compares existing analysis and test coverage with the changed conditions. Where evidence no longer supports the claim, it defines additional work or restricts the claim. Vehicle 01 may continue unaffected activities while a hold prevents closing access needed for inspection or rework. For Vehicle 02, procurement identifies the contractual exposure before equipment changes are instructed. Vehicles 03–04 can adopt an approved revised planning baseline when the technical and commercial decisions have been made. None of these stages justifies fleet-wide acceptance by default.

The change disposition records unit applicability, required definition changes, affected assurance claims and evidence needed for each vehicle. A representative test can support multiple units only when the argument identifies the relevant similarities and differences. Installation inspection remains unit-specific where workmanship or actual fitted configuration matters. Closure therefore includes both the general technical justification and the individual implementation evidence.

A supplier connector change is a different trigger

A supplier then proposes a revised cooling-module electrical connector. This is a change to supplied definition, not a customer requirement revision. Assess both mating sides, harness termination, routing, sealing provisions, assembly access, inspection and service tooling. A connector that physically mates may still be unsuitable for the intended circuit or environment; apparent fit cannot replace the interface assessment.

The supplier supplies the change description, affected identifiers, compatibility statement and supporting evidence. The harness design authority evaluates its side, while the integrated interface owner resolves cross-boundary compatibility. Purchasing establishes whether the supplier may substitute the item under the order. Quality establishes containment and inspection needs for deliveries already received. These decisions must converge before the revised item is installed.

If Vehicle 01 already contains the earlier connector, its configuration may remain acceptable under a justified disposition while later vehicles use the new interface. Alternatively, rework may be necessary. Record the actual result and the basis for accepting it. An instruction to use the new revision from now on cannot explain the state of equipment already fitted or in transit.

Security includes the engineering evidence

Protecting the product also requires protecting the information used to approve it. Unauthorised edits to a harness definition, corrupted calibration packages or substituted supplier reports can undermine otherwise sound engineering. Identify information assets, threat scenarios, access needs and recovery requirements together with the product architecture.

Separate permission to read, author, approve and deploy. A supplier may need interface data without receiving unrelated customer information. A maintainer may need an approved software package without permission to alter the master release. Emergency access should leave an attributable record and receive subsequent review. Access restrictions must also permit the competent reviewer to obtain sufficient evidence; hiding important information from assurance is not a satisfactory control.

Preserve provenance when evidence crosses organisational boundaries: issuer, revision, configuration scope, receipt, review and any limitations. Where authenticity or integrity controls are needed, select and validate them against the threat and operating environment. Do not assume that a file attached to an approved object is authentic, or that a cryptographic integrity check establishes engineering correctness. Integrity and technical adequacy answer different questions.

Evidence over time and at scale

Assurance must be revisited when assumptions change. Field incidents, supplier withdrawals, new threat information and changed operating conditions can undermine a previous conclusion without altering the drawing. Establish a route for these signals into configuration assessment and controlled change. Retain earlier arguments so that investigators can understand what was known and why an earlier decision was reasonable.

For a small programme, a compact linked register and competent review may be sufficient. At defence or infrastructure scale, millions of occurrences, years of manufacture and thousands of people create many simultaneous applicability boundaries. Organise assurance by meaningful system and contractual boundaries, with explicit assumptions at each boundary. Reuse evidence through justified applicability rather than copying a report into every unit folder. Preserve the ability to identify which units depend on a withdrawn assumption.

The selected platforms support information responsibilities rather than supplying assurance automatically. DOORS holds customer requirements; NX and Capital contribute mechanical and electrical definition. Teamcenter can serve the controlled product-lifecycle role in the reference architecture, while SAP supports procurement and other enterprise resource planning activities. Hazard and threat analysis, software release control, execution evidence and specialist assurance tools still need assigned ownership and validated exchanges. No native object schema or automatic synchronisation is assumed here.

Before authorising a commitment, the decision maker needs the relevant baseline, open findings, applicable obligations, evidence coverage and restrictions. After authorisation, the output is a bounded decision with accountable follow-up, not a claim that uncertainty has disappeared. As-built configuration and traceability explains how that decision remains connected to the vehicle actually delivered.