09 — Electrical, control and software engineering

Define behaviour before wiring

The cooling fan must respond appropriately to vehicle conditions. Specifying a wire between a controller and a fan does not define when the fan runs, what happens when a sensor fails or how the vehicle reports a fault. Electrical and control engineering begin with required behaviour, power availability, operating modes and interfaces. The four customised combustion-engine vehicles share much of this definition, but their payload and hot-climate requirements may demand different configurations.

Capital provides the electrical authoring environment. Siemens describes its electrical suite as covering connectivity, harness design, manufacturing, documentation and after-sales. This supports a capability category, not a claim that the selected installation includes every function. Siemens Capital electrical design is the primary capability source. Clear allocation of authority prevents gaps between disciplines.

The electrical authority owns circuit definition and electrical compatibility. The controls authority owns required behaviour and control logic. The software authority owns executable release integrity and its supporting development evidence. The mechanical authority owns installation geometry and physical interface constraints. The system authority resolves interactions and approves the integrated solution. A supplier may retain detailed design authority, but the programme must still obtain the interface definition and evidence needed to accept its equipment.

A functional definition describes what the electrical and control system does: sensing temperature, commanding fan operation, supplying power and reporting faults. A connectivity definition identifies endpoints and their electrical relationships, including connector identities, cavities, signals, power paths, protection and grounding intent. These are different questions. One functional relationship may require several conductors and a network message; one physical harness may serve several vehicle functions.

The physical harness definition specifies construction: wires and cables, terminals, connector housings, seals, splices, shielding, lengths, branches and protection. Its relationship to a three-dimensional route includes support locations, bend and movement constraints, thermal exposure, abrasion risks and installation access. A mechanical envelope is therefore an input to harness design, while harness construction feeds back into packaging. Responsibility for each shared attribute must be agreed before transfer between tools.

Manufacturing planning converts harness definition into preparation, termination, assembly and test operations. Execution evidence records the actual work and checks. A correct connectivity model does not demonstrate that a particular terminal was crimped correctly or that an installed harness avoided a hot surface. Conversely, continuity alone cannot establish correct control behaviour.

Control definition adds operating states, transitions, commands, limits, timing expectations and fault responses. Engineers define the meaning and units of exchanged signals and what stale, missing or implausible values cause. They distinguish required behaviour from its implementation in controller software, configurable parameters or supplier hardware. A calibration change can materially alter vehicle behaviour even when the executable binary is unchanged.

Software belongs to the vehicle configuration

The release record identifies the software item and version, executable artefact, build provenance, relevant dependencies, compatible hardware, calibration set and deployment instructions. The programme chooses integrity checks and retention methods suitable for its obligations. A source-code label alone is insufficient to identify the binary loaded into a controller; an installed version string alone may be insufficient to reproduce that binary.

Software governance requires requirements allocation, review, controlled builds, defect disposition, testing and authorised deployment. The named core platforms do not by their presence establish a complete software development or application lifecycle management environment. Capital portfolio descriptions must not be read as proof that a particular team has the necessary source control, build pipeline, network development, cybersecurity or safety-assurance capability. Those responsibilities remain explicit architectural decisions.

A supplier controller may expose only an approved firmware package and interface documentation. In that case, the programme records the supplier release identity, compatible equipment, limitations, evidence and support arrangements. It must not claim source-level reproducibility it does not possess. Contract and assurance decisions determine whether this evidence is adequate.

Changes with distinct origins

Suppose the customer changes the required hot-climate conditions in DOORS while Vehicle 01 is in build and Vehicle 02 has equipment ordered. The change remains proposed until technical and contractual disposition. Engineers assess thermal demand, fan electrical loading, available generation, protection, wiring, control behaviour and packaging together. A more powerful fan is an alternative to evaluate, not an assumed answer.

Separately, the supplier announces a connector change. Its record remains distinct from the customer hot-climate request even if implementation is coordinated. The interface owner checks both mating halves, terminal suitability, cavity assignments, polarity, sealing, strain relief and service access. A supplier's statement that a connector is equivalent does not establish compatibility in this installation. The harness supplier, cooling-module supplier and vehicle integration team agree a controlled interface revision and its intended unit applicability.

Vehicle 01 may retain the existing arrangement if accepted requirements and evidence support it, or require rework if they do not. Vehicle 02 needs an order-impact decision before procurement changes its delivery instructions. Vehicles 03–04 may use the revised configuration once released. Each decision identifies hardware, harness, software and calibration compatibility. A date on a supplier notice does not determine which physical vehicle received which arrangement.

Early harness manufacture can proceed for stable branches if their endpoints, construction requirements and reserved interfaces are controlled. An unresolved fan branch may remain outside that commitment. Manufacturing engineering must assess whether later completion or modification is feasible without damaging already completed work. The release names the permitted work rather than implying whole-vehicle readiness.

Release hardware and behaviour together

Suppose the hot-climate assessment selects revised fan control using existing controller hardware. The executable might remain unchanged if an authorised calibration set implements the required behaviour. The controls engineer still needs to establish parameter meaning, permitted ranges and interactions with operating modes and fault responses. A loading tool accepting a file format does not establish compatibility with the installed fan.

Release identifies the compatible controller hardware, executable, calibration, fan and harness definitions. Deployment instructions identify the vehicle and controller position, preconditions and confirmation checks. The actual load record captures artefact identities and outcome. A planned version in a structure and successful file transfer do not by themselves prove that the intended controller operates with the authorised behaviour.

The separate supplier connector change may require only a harness revision if signal meaning and electrical characteristics remain unchanged. Changed assignments or behaviour may instead require control changes. Compare endpoint definitions before deciding. Continuity can reveal some wiring errors but cannot establish correct interpretation under all required modes.

Vehicle 01 rework preserves its actual starting configuration and records the complete resulting combination. Vehicle 02's order names the required configuration rather than requesting the latest harness. Vehicles 03 and 04 adopt the revised set once released. A failed deployment retains its failure and recovery evidence; restoring an earlier load requires that combination to remain authorised for the installed hardware and vehicle obligations.

Evidence at each boundary

Verification begins with allocated requirements and an identified configuration. Circuit checks examine connectivity and applicable electrical constraints. Harness checks examine construction and workmanship against its definition. Controller tests examine logic, interfaces and fault handling. Integrated tests examine the actual vehicle combination under the required operating conditions. The programme selects methods and acceptance criteria rather than assuming a universal test sequence.

A bench test using a simulated temperature signal can support logic verification while leaving airflow and installed thermal performance unresolved. A vehicle thermal test may demonstrate cooling under the tested conditions while leaving an unexercised sensor-failure response unverified. Evidence records therefore state what was tested, the procedure and criteria, actual configuration, results, anomalies and authorised conclusion. Test substitutions need an explicit argument explaining their limits.

A software correction after testing prompts impact assessment: which requirements, interfaces and prior results are affected? The controls and verification authorities determine justified regression coverage. Repeating every test automatically can waste time; repeating none can leave the changed behaviour unsupported. An unresolved defect may require a restricted release or a formal acceptance decision under the programme's quality process.

Connected tools and distributed work

Capital is the electrical authoring environment; NX supplies mechanical installation context; Teamcenter controls released relationships and product structures; SAP supports material and purchasing commitments. These responsibilities are a reference architecture, not verified default integration behaviour. Exchanges must preserve identifiers, revision, units, coordinate context where relevant, applicability and acceptance status. Reconciliation must expose failed or partial transfers before downstream use.

At the scale of thousands of engineers and millions of occurrences, a connector change needs a queryable compatibility relationship, not an email list assembled from memory. Multi-year manufacture also requires retention of older software tools, supplier releases and test configurations where needed to support delivered units. Common libraries reduce repeated work, but their changes require assessment of all contextual uses. Electrical definition continues into part identity and configuration selection; physical installation records remain distinct from intended design.