Virtual Prototypes and Simulation as Evidence

Automotive development becomes faster when engineers can answer important questions before building physical hardware.

That is the promise of virtual prototypes and simulation.

A digital vehicle model can be used to explore:

• Thermal behavior
• Structural loads
• Crash response
• Energy consumption
• Aerodynamics
• Control logic
• Sensor behavior
• Manufacturing processes
• Vehicle dynamics

In ZenOps, simulation is not treated merely as a convenient engineering tool.

It can become part of the evidence chain.

The question is not simply:

Did we run the simulation?

The stronger question is:

Is the simulation credible enough to support the engineering decision we are trying to make?

The ZenOps chain becomes:

Need → Requirement → Virtual Prototype → Simulation → Result → Evidence → QT

Simulation can therefore become evidence.

But only when its assumptions, context, validity, and limitations are understood.

A Simulation Is a Model of Reality

The first principle is simple.

A simulation is not reality.

It is a model.

Suppose we simulate battery temperature during fast charging.

The simulation may include:

Battery Heat Generation
Coolant Flow
Heat Exchanger
Ambient Temperature
Thermal Mass
Control Logic

The result may predict:

Maximum battery temperature = T.

That number is not a physical measurement.

It is the result of a model operating under assumptions.

The quality of the evidence therefore depends on the quality of the model.

Virtual Prototypes Answer Questions Early

Suppose the engineering team wants to know:

Can the proposed thermal architecture maintain acceptable battery temperature during repeated fast charging?

The physical system does not yet exist.

A virtual prototype can provide an early answer.

Requirement
↓
Virtual Battery Model
↓
Thermal Simulation
↓
Predicted Temperature
↓
Evidence

If the predicted result is clearly unacceptable, the team may avoid building a poor architecture.

That is valuable progress.

The Purpose of the Simulation Must Be Explicit

A simulation should begin with a question.

For example:

Does the proposed front structure keep predicted deformation within the defined limit under Load Case X?

That is much stronger than:

Run structural simulation.

The question defines:

• Model scope
• Inputs
• Output
• Acceptance criterion
• Evidence purpose

The simulation becomes part of a controlled reasoning process.

Simulation Can Support Different Types of Evidence

Virtual prototypes can contribute evidence for many different domains.

Structural

Load
↓
Finite Element Model
↓
Stress + Deformation
↓
Requirement Comparison

Thermal

Heat Sources
↓
Thermal Model
↓
Temperature Distribution
↓
Requirement Comparison

Vehicle Dynamics

Driver / Controller Input
↓
Vehicle Dynamics Model
↓
Vehicle Response
↓
Handling Requirement

Energy

Drive Cycle
↓
Vehicle Model
↓
Energy Consumption
↓
Range Prediction

The pattern is the same.

Model → Predict → Compare → Evidence

Virtual Prototypes Should Have Identity

A simulation result is only meaningful if the exact model configuration is known.

For example:

VIRTUAL-PROTOTYPE-017
Vehicle Mass:
M1
Battery Model:
B4
Motor Model:
M7
Aerodynamic Model:
A3
Software:
v5.4
Calibration:
C218

Now the evidence can be traced to the virtual configuration that produced it.

Model Versioning Is Essential

Suppose:

Battery Model v4

predicts one result.

Later:

Battery Model v5

includes improved thermal behavior.

The previous simulation result may no longer represent current knowledge.

Therefore:

Simulation Result
   generated by
Model Version

must be explicit.

The simulation model itself is a configuration-controlled engineering object.

Assumptions Must Be Visible

Every simulation contains assumptions.

For example:

Assumption:
Coolant properties constant
Assumption:
Battery heat generation follows Model H
Assumption:
Ambient airflow represented by boundary condition A
Assumption:
No manufacturing variation

These assumptions matter because the result is only valid inside the world created by the model.

ZenOps should preserve them as part of the evidence context.

The Operating Range Must Be Defined

A model may be accurate under some conditions and poor under others.

For example:

Thermal Model
Validated Range:
-20 C to +40 C
Unvalidated:
Below -20 C
Above +40 C

If an engineer uses it to predict behavior at -35°C, the result may have weak evidential value.

Therefore every important model should answer:

Where is this model valid?

Model Confidence Is Not Binary

Simulation credibility is rarely just:

trusted / not trusted

A more useful view might be:

Crash Model:
High Confidence
Battery Degradation Model:
Medium Confidence
Long-Term Corrosion Model:
Low Confidence

The strength of evidence should reflect this.

A low-confidence model can still be useful for exploration.

It may not be sufficient for production release.

Simulation Evidence Should Match the Decision

This is where QT matters.

At Concept QT:

simulation may be enough to answer:

Is this architecture plausible?

At Prototype QT:

simulation may need physical correlation.

At Production QT:

critical claims may require strong production-intent physical evidence.

The evidence requirement becomes stronger as commitment increases.

Concept
↓
Simulation Evidence
Prototype
↓
Simulation + Physical Evidence
Production
↓
Validated Model + Production-Intent Evidence

A Simulation Can Reject a Bad Idea Early

Suppose a proposed body architecture fails structural simulation badly.

The result may be sufficient to reject it immediately.

There is no reason to manufacture an obviously weak prototype merely to prove what the model already shows convincingly.

This is one of simulation’s greatest advantages.

It moves failure earlier.

But Passing Simulation Does Not Automatically Prove Reality

A simulated pass is not always enough.

Unexpected physical effects may include:

• Material variation
• Assembly tolerance
• Friction
• Sensor noise
• Manufacturing defects
• Unmodeled heat paths
• Real-time software behavior

Therefore:

Simulation PASS
≠
Automatic Physical PASS

The strength of the claim determines what additional evidence is required.

Physical Prototypes Validate Virtual Ones

A strong ZenOps loop is:

Virtual Model
↓
Prediction
↓
Physical Test
↓
Measurement
↓
Comparison
↓
Model Update

The physical result teaches the simulation.

The simulation then becomes more useful for future questions.

Model Validation Is Itself an Evidence Problem

Suppose a thermal model predicts:

72°C

and the physical test measures:

74°C

That comparison provides evidence about the model.

Now suppose this happens across many representative conditions.

Confidence increases.

The model itself can therefore have a QT.

MODEL QT
[ ] Physics / logic defined
[ ] Inputs controlled
[ ] Assumptions explicit
[ ] Representative cases validated
[ ] Prediction error understood
[ ] Applicability range defined
[ ] Limitations documented
[ ] Evidence accepted

A simulation tool is not exempt from verification.

Simulation Should Predict Before the Test

One useful discipline is to record the prediction before the physical result is known.

Why?

Because adjusting the model after seeing the answer can hide weaknesses.

A stronger loop is:

Model
↓
Blind Prediction
↓
Physical Test
↓
Compare
↓
Update

This gives a more meaningful measure of predictive capability.

StoryQ Can Drive Simulation

A Gherkin scenario can define a virtual test.

For example:

Scenario: Battery cooling during repeated fast charging
Given the battery begins within the defined operating temperature range
And the specified ambient condition applies
When the defined repeated fast-charging profile is executed
Then battery temperature shall remain within the permitted range

This scenario can first execute virtually.

Later, it can execute physically.

The same behavioral requirement survives both environments.

One Scenario, Multiple Evidence Sources

For example:

SCN-021
Battery Thermal Performance
│
├── Simulation
├── Hardware-in-the-Loop
├── Module Test
└── Vehicle Test

Different methods contribute to one evidence body.

The QT evaluates the combined strength.

Simulation Is Powerful for Parameter Exploration

Physical tests are expensive.

Virtual prototypes can explore large parameter spaces.

For example:

Temperature:
-30 to +45 C
Vehicle Mass:
M1 to M3
Battery State:
S1 to S5
Charging Power:
P1 to P4

Thousands of combinations may be simulated.

This can reveal sensitive regions.

Physical testing can then focus on the most important cases.

Simulation Can Discover Edge Cases

Suppose the nominal architecture works well.

Parameter exploration reveals failure only when:

Low Temperature
+
Low State of Charge
+
High Power Demand

That combination becomes a new engineering scenario.

Simulation has discovered a question worth testing physically.

Virtual Testing Can Guide Physical Testing

The relationship should not be:

simulation versus physical test

but:

simulation guides physical test

and:

physical test validates simulation.

The two reinforce each other.

Simulation Can Support FMEA

Suppose FMEA identifies:

Cooling pump loses 50% capability.

The virtual prototype can inject:

Pump Flow = 50%
↓
Thermal Simulation
↓
Battery Temperature
↓
System Response

This can rapidly explore failure consequences.

Later, representative physical tests can validate the conclusions.

Fault Injection Can Be Virtual

Software and system simulations can inject:

• Sensor failure
• Communication delay
• Stale data
• Actuator limitation
• Power loss

For example:

Normal Model
↓
Inject Sensor Failure
↓
Control Software Responds
↓
Observe System
↓
Evidence

This makes failure analysis much faster.

Software-in-the-Loop Is a Virtual Prototype

A software-in-the-loop environment can represent:

Vehicle Physics
+
Sensors
+
Environment
+
Control Software

The software behaves against a virtual vehicle.

This is particularly useful for:

• State machines
• Control algorithms
• Failure handling
• Regression testing

Hardware-in-the-Loop Increases Realism

Hardware-in-the-loop adds real control hardware.

Real Controller
+
Real Software
+
Virtual Vehicle
↓
Observed Behavior

This introduces:

• Real processor timing
• Real interfaces
• Real electrical behavior

The evidence becomes stronger for some types of claims.

Digital Twins Can Become Long-Lived Virtual Prototypes

A digital twin can preserve the configuration of a real vehicle.

It can then support future simulations.

For example:

Vehicle #000142 Twin
↓
Current Configuration
↓
Simulate Software Update
↓
Predict Behavior

The virtual prototype does not disappear after design.

It continues through the lifecycle.

Manufacturing Can Be Simulated Too

Virtual prototypes are not limited to the vehicle.

A factory model might simulate:

Material Flow
Workstation Capacity
Robot Motion
Assembly Sequence
Cycle Time

The question might be:

Can the planned line achieve required production volume?

The result can support Manufacturing QT.

Process Simulation Can Prevent Factory Problems

Suppose a robot path causes interference.

Virtual manufacturing can detect it before equipment is installed.

That saves expensive physical changes.

Again:

discover failure earlier.

Virtual Prototypes Can Support Ergonomics

Human interaction can also be simulated.

Examples include:

• Visibility
• Reach
• Seating position
• Control accessibility
• Packaging

The virtual prototype can reveal problems before physical mock-ups exist.

Not All Human Experience Can Be Fully Simulated

Some qualities remain difficult to predict reliably.

Examples may include:

• Perceived comfort
• Sound quality
• Steering feel
• Interior tactile quality

Virtual evidence can contribute.

But physical human evaluation may remain necessary.

ZenOps should not force every need into a virtual method when the method is weak.

Evidence Strength Must Be Explicit

A useful evidence object might state:

Evidence:
SIM-882
Supports:
REQ-211
Strength:
Preliminary
Basis:
Validated model within known range
Limitation:
Does not include manufacturing variation

The evidence does not pretend to be stronger than it is.

Simulation Can Be Wrong for the Right Reasons

Suppose a model predicts failure.

The physical system passes.

The simulation was wrong.

That is still valuable.

It reveals a model deficiency.

Likewise, simulation may pass while physical testing fails.

That identifies missing physics or assumptions.

The discrepancy itself is evidence.

Model Disagreement Generates FLEXI Work

For example:

Simulation:
PASS
Physical Test:
FAIL

This creates a clear question:

Why?

A FLEXI sprint can investigate:

• Boundary conditions
• Material model
• Sensor behavior
• Test setup
• Geometry
• Software configuration

The disagreement drives learning.

Virtual Prototype Results Should Be Reproducible

A strong simulation evidence package should preserve:

• Model version
• Inputs
• Parameters
• Software version
• Solver / algorithm configuration
• Scenario
• Output
• Acceptance criterion

Another engineer should be able to reconstruct the result.

Reproducibility strengthens evidence.

Simulation Changes Need Impact Analysis Too

Suppose the model itself changes.

That can affect previous results.

The chain becomes:

Model Change
↓
Affected Simulations
↓
Affected Evidence
↓
Affected Requirements
↓
Re-Evaluation

Virtual evidence must be configuration-controlled just like physical evidence.

Virtual Evidence Can Feed the Pattern Library

Suppose a thermal pattern is repeatedly simulated and later validated physically.

The Pattern Library can retain:

Thermal Pattern
│
├── Model
├── Validated Range
├── Known Failure Regions
├── StoryQ Scenarios
├── Simulation Evidence
└── Physical Correlation

Future programs inherit more than a design.

They inherit a validated way of reasoning about the design.

Virtual Prototypes Accelerate Platform Development

A modular vehicle platform may allow rapid configuration:

Battery A
+
Motor B
+
Body C
+
Software D
↓
Virtual Vehicle

Many combinations can be tested digitally before hardware exists.

This helps identify promising configurations early.

Simulation Can Help Manage Complexity

Complex systems are difficult because many variables interact.

Simulation allows engineers to manipulate those variables deliberately.

Instead of waiting for reality to produce a rare condition, we can create it virtually.

This makes complexity explorable.

But Simulation Can Also Create False Confidence

Highly detailed graphics can make a simulation appear convincing.

A complex model can feel authoritative.

That does not guarantee correctness.

ZenOps therefore asks:

What evidence supports the model itself?

This prevents model sophistication from being confused with model truth.

The Model Must Be Allowed to Fail QT

If a simulation model cannot reproduce known physical behavior within acceptable limits, its QT should fail.

That may mean:

use for exploration only

rather than:

use for release evidence.

Different models can have different permitted uses.

Evidence Class Can Depend on Model Maturity

For example:

Model State:
Exploratory
Permitted Use:
Concept comparison
Not Permitted:
Production release

Later:

Model State:
Validated
Permitted Use:
Design optimization
Selected verification claims

This makes simulation governance explicit.

Virtual and Physical Evidence Form One Network

The strongest architecture is not:

Virtual Evidence
OR
Physical Evidence

but:

Virtual Evidence
+
Physical Evidence
+
Field Evidence
↓
Engineering Confidence

Each contributes differently.

Field Evidence Ultimately Challenges Both

After launch, real vehicles provide another reference.

Suppose:

Simulation predicts:
Failure Rate A
Prototype predicts:
Behavior B
Fleet shows:
Behavior C

The field result becomes the strongest new learning input.

The models must adapt.

The Complete ZenOps Simulation Loop

The full process becomes:

HUMAN NEED
      ↓
NDD
      ↓
REQUIREMENT
      ↓
QUESTION
      ↓
VIRTUAL PROTOTYPE
      ↓
SIMULATION
      ↓
PREDICTION
      ↓
SIMULATION EVIDENCE
      ↓
QT
      ↓
PHYSICAL PROTOTYPE
      ↓
MEASUREMENT
      ↓
COMPARE MODEL WITH REALITY
      ↓
MODEL UPDATE
      ↓
STRONGER EVIDENCE
      ↓
PRODUCTION
      ↓
FIELD EVIDENCE
      ↓
FURTHER MODEL IMPROVEMENT

The model becomes progressively grounded.

Virtual Prototypes Convert Costly Questions Into Cheap Questions

This may be their greatest value.

A physical crash test can be expensive.

A vehicle prototype can be expensive.

A factory change can be extremely expensive.

A simulation is often much cheaper to repeat.

Therefore the ideal sequence is:

Ask as many useful questions virtually as credible modeling allows, then spend physical resources on the questions that reality still needs to answer.

This is not about replacing physical engineering.

It is about using physical engineering more intelligently.

Simulation Is Evidence When the Model Has Earned Trust

The deepest principle is simple.

A simulation result is not evidence because a computer produced a number.

It becomes useful evidence because the engineering organization can explain:

What was modeled?

Why is the model appropriate?

Which assumptions were used?

Under what conditions is it valid?

How has it been compared with reality?

What requirement does the result support?

How strong is that support?

When those questions are answered, virtual prototypes become powerful parts of the ZenOps evidence system.

When they are not, simulation remains hypothesis.

That distinction matters.

Virtual prototypes let us ask reality-inspired questions before physical reality is affordable.

Physical prototypes tell us whether our virtual understanding was good enough.

And each comparison makes the next prediction stronger.

Managing Hardware and Software as One System

A modern vehicle cannot be understood by separating hardware and software too aggressively.

A brake controller without software is incomplete.

Software without sensors, networks, controllers, actuators, power, and mechanical systems cannot move the vehicle.

The behavior the customer experiences emerges from both.

ZenOps therefore treats hardware and software as one integrated object network.

The chain becomes:

Human Need → NDD → Requirement → Hardware + Software Objects → Relations → Behavior → Test → Evidence

The question is not:

Is the hardware finished?

or:

Is the software finished?

The stronger question is:

Does the complete cyber-physical system produce the required vehicle behavior?

The Vehicle Is Cyber-Physical

Consider traction control.

A simplified behavior chain might be:

Wheel
↓
Wheel-Speed Sensor
↓
Electrical Signal
↓
Controller Hardware
↓
Software
↓
Torque Command
↓
Motor Controller
↓
Motor
↓
Wheel Torque
↓
Road Interaction

Where does the “traction-control system” actually exist?

Not in one component.

Not purely in software.

Not purely in hardware.

It exists across the complete chain.

This is why ZenOps models both objects and relations.

Hardware and Software Share the Same Need

Suppose the NDD contains:

Maintain controllability during low-friction acceleration.

That need might generate requirements involving:

• Wheel-speed measurement
• Signal validity
• Control timing
• Torque reduction
• Motor response
• Diagnostic behavior

Some are implemented physically.

Some are implemented in software.

Some are implemented through the relation between the two.

The need does not care which engineering department owns them.

Reality sees only the final behavior.

Stop Treating Software as an Attachment

A traditional sequence can look like:

Mechanical Design
↓
Electronics
↓
Software Added Later

That is increasingly dangerous.

Software often influences fundamental architectural choices:

• Sensor selection
• Controller capability
• Network bandwidth
• Power requirements
• Diagnostic strategy
• Fail-safe behavior
• Actuator characteristics

Software must therefore enter the architecture early.

The better model is:

Requirement
↓
System Behavior
↓
Hardware Responsibilities
+
Software Responsibilities
↓
Integrated Architecture

Allocate Responsibility Explicitly

Suppose the requirement is:

Prevent battery operation above a defined temperature limit.

Responsibility might be distributed across:

Temperature Sensor
→ measures
Controller Hardware
→ receives measurement
Software
→ evaluates temperature
Thermal Actuator
→ changes cooling
Battery Contactors
→ isolate energy if required

No single object owns the whole outcome.

The architecture must explicitly assign responsibility across the network.

The Interface Is the Boundary

Hardware and software meet at interfaces.

Examples include:

• Sensor signals
• ADC values
• Network messages
• Interrupts
• Commands
• Status flags
• Diagnostics
• Calibration parameters

An interface should therefore be treated as an engineering object.

For example:

INTERFACE-TEMP-017
Source:
Battery Temperature Sensor
Receiver:
Battery Controller
Meaning:
Cell Temperature Estimate
Range:
Defined
Update Rate:
Defined
Validity Rules:
Defined
Failure Behavior:
Defined

The interface now has meaning, not merely bits.

Incorrect Interface Meaning Can Be Dangerous

Suppose hardware reports:

temperature = 85

What does 85 mean?

85°C?

85°F?

Raw ADC value?

Scaled integer?

Invalid signal?

Without an explicit contract, software can behave incorrectly even though both hardware and software are individually “working.”

Many failures exist at the semantic boundary.

ZenOps therefore treats interface meaning as first-class engineering knowledge.

Timing Belongs to Both Worlds

Automotive behavior is often real-time.

Suppose:

Sensor
↓ 5 ms
Controller Input
↓ 10 ms
Software Decision
↓ 5 ms
Command Output
↓ 20 ms
Actuator Response

The total response time is:

40 ms

The requirement may apply to the entire chain.

Therefore timing cannot be owned only by software or hardware.

It is an end-to-end system property.

End-to-End Requirements Are Stronger

Instead of writing:

Software shall respond within 10 ms.

ask whether the real requirement is:

The physical system shall begin the required actuator response within X milliseconds of the triggering event.

Then allocate the timing budget:

Sensor        5 ms
Network       5 ms
Software     10 ms
Output        5 ms
Actuator     20 ms

Now the requirement reflects actual vehicle behavior.

Software Configuration Is Part of Hardware Configuration

A controller is not fully defined by its part number.

Suppose:

Brake Controller #BC-8841

executes:

Brake Software v5.4.2

Then the effective system object is:

Hardware
+
Software
+
Calibration
+
Configuration

Change one of these and behavior may change.

The vehicle configuration must therefore track all of them.

A Physical Vehicle Is a Hardware-Software Configuration

A real vehicle instance might contain:

Vehicle #000142
Battery Controller HW 3.1
Battery Software 4.8
Brake Controller HW 2.2
Brake Software 5.4
Gateway HW 1.9
Gateway Software 3.6

Two mechanically identical vehicles may behave differently if their software differs.

Therefore software belongs in the vehicle’s product identity.

Calibration Is a Third Layer

Automotive behavior often depends not only on code but calibration.

For example:

Control Algorithm
+
Parameter Set
=
Actual Behavior

A traction-control algorithm may be unchanged while calibration values alter:

• Slip thresholds
• Torque reduction
• Recovery rate
• Driver feel

The domain model should therefore distinguish:

Software Definition
Calibration Definition
Hardware Definition

and connect all three to the physical vehicle.

Hardware Changes Can Invalidate Software Evidence

Suppose software passes all tests using:

Controller HW v2.1

Then the controller changes to:

Controller HW v2.2

Perhaps the processor changed.

Perhaps timing changed.

Perhaps ADC behavior changed.

Perhaps network handling changed.

Old software evidence may no longer be fully valid.

ZenOps should trigger impact analysis:

Hardware Change
↓
Affected Software
↓
Affected Interfaces
↓
Affected Requirements
↓
Affected Tests
↓
Evidence Revalidation

Software Changes Can Invalidate Hardware-System Evidence

The reverse is equally true.

Suppose the mechanical braking system does not change.

But brake-control logic changes.

Previous vehicle-level braking evidence may need to be reconsidered.

Therefore:

Software Change
↓
Affected Vehicle Behavior
↓
Affected Requirements
↓
Affected Tests
↓
New Evidence

Hardware and software configuration management must be connected.

The Domain Model Should Capture Compatibility

Suppose:

Software v5.4
requires
Controller HW >= 2.2

while:

Software v5.3
supports
Controller HW 2.0–2.2

These are relations.

The vehicle configuration engine can use them to prevent invalid combinations.

Compatibility becomes explicit engineering knowledge.

Modular Architecture Helps

ZenOps modular architecture can define cyber-physical modules.

For example:

Brake Module
│
├── Brake Hardware
├── Sensors
├── Controller
├── Embedded Software
├── Calibration
├── Communication Interface
└── Diagnostic Interface

This is more useful than placing software in a separate organization-only hierarchy.

The module represents a complete responsibility.

A Module Should Expose Behavior, Not Internals

Other parts of the vehicle should not need to know every internal software function.

The Brake Module may expose:

Input:
Requested Deceleration
Output:
Actual Brake Status
Guarantee:
Respond Within Defined Limits
Failure Behavior:
Defined Degraded State

Internally, implementation may evolve.

The external contract stays controlled.

StoryQ Tests the Complete System

Suppose we have:

Scenario: Low-friction emergency braking
Given the vehicle is travelling on the defined low-friction surface
When the driver requests emergency braking
Then the vehicle shall decelerate within the required limits
And directional controllability shall remain within the accepted range

This scenario does not care which part is hardware and which is software.

That is exactly the point.

The scenario validates system behavior.

Lower-Level Scenarios Still Matter

System-level tests are not enough by themselves.

We may also have:

Scenario: Brake controller rejects invalid wheel-speed data

and:

Scenario: Brake actuator responds to valid command

The evidence hierarchy becomes:

Software Unit Evidence
↓
Controller Evidence
↓
Module Evidence
↓
System Evidence
↓
Vehicle Evidence

Each level answers a different question.

Hardware-in-the-Loop Becomes a Bridge

Hardware-in-the-loop testing is especially useful for cyber-physical systems.

It allows real controller hardware and software to interact with simulated physical environments.

The structure becomes:

Real Controller Hardware
+
Real Software
+
Simulated Vehicle
↓
Observed Behavior
↓
Evidence

This creates evidence before a complete vehicle exists.

Software-in-the-Loop Has a Different Role

Software-in-the-loop can test:

• Algorithms
• State machines
• Interfaces
• Fault logic
• Large scenario sets

But it may not expose real:

• Processor timing
• Electrical behavior
• Network hardware effects
• Actuator response

Different test levels produce different strengths of evidence.

QT determines when the evidence set is sufficient.

FMEA Must Cross the Boundary

Hardware failure can cause software problems.

Software failure can cause hardware behavior.

Interface failure can affect both.

Example:

Sensor Failure
↓
Invalid Input
↓
Software Misinterpretation
↓
Incorrect Command
↓
Actuator Movement

FMEA should therefore model the complete chain.

Not separate “hardware FMEA” and “software FMEA” that never meet.

Common-Cause Dependencies Matter

Suppose several safety functions depend on one compute platform.

Central Compute
│
├── Braking Support
├── Steering Support
├── Thermal Control
└── Diagnostics

A single hardware or software fault may affect multiple functions.

The object network makes this shared dependency visible.

System safety analysis must consider the combined consequence.

Power Is Also Part of the Software System

Software cannot execute without power.

A controller may depend on:

12V Supply
↓
Power Management
↓
Controller Hardware
↓
Software

A voltage drop may cause:

• Restart
• Corrupted state
• Lost communication
• Delayed recovery

This is a cyber-physical failure path.

The software architecture should understand its physical dependencies.

Network Architecture Is Both Hardware and Software

Vehicle communications include:

physical network

plus:

communication software

plus:

message definitions

plus:

timing

plus:

fault handling.

Therefore:

Communication System
=
Hardware
+
Protocol
+
Software
+
Message Semantics
+
Timing

Treating these separately can hide system-level problems.

Diagnostics Must Understand Both

A diagnostic event should often identify more than:

Software error.

It may need to distinguish:

• Sensor physical failure
• Wiring failure
• Communication failure
• Controller hardware failure
• Software logic failure
• Configuration mismatch

The diagnostic model should therefore connect across the whole object network.

Manufacturing Must Install Both Systems

The factory installs physical components.

But it also installs software.

Production may include:

Install Controller
↓
Verify Hardware Identity
↓
Flash Software
↓
Apply Calibration
↓
Verify Compatibility
↓
Run End-of-Line Test
↓
Record Configuration

The manufacturing process creates the cyber-physical vehicle.

Production QT Must Include Software

A vehicle should not cross Production QT merely because physical assembly is ready.

A production gate may need:

[ ] Hardware configuration released
[ ] Software configuration released
[ ] Compatibility verified
[ ] Flashing process validated
[ ] Calibration process validated
[ ] End-of-line behavior verified
[ ] Traceability operational

Production readiness is joint readiness.

Service Must Preserve Compatibility

Suppose a controller is replaced during service.

The replacement process may require:

Install Hardware
↓
Identify Hardware Version
↓
Select Compatible Software
↓
Flash
↓
Apply Calibration
↓
Verify
↓
Update Vehicle History

A mechanically correct repair can still fail if the wrong software is installed.

The service domain must therefore preserve the same hardware-software relationships.

Over-the-Air Updates Are Product Changes

An over-the-air update can change the behavior of an already manufactured vehicle.

Therefore it should be treated as a product change:

Software Update
↓
Impact Analysis
↓
Regression Tests
↓
Evidence
↓
Release QT
↓
Deployment
↓
Field Monitoring

The physical hardware remains fixed.

The product behavior changes.

Field Evidence Should Include Configuration

Suppose a failure appears in the fleet.

The important question is not simply:

Which vehicle model failed?

It may be:

Which combination of hardware, software, calibration, supplier batch, and environment failed?

For example:

Failure Pattern
↓
Brake Controller HW 2.1
+
Software 5.4
+
Calibration C17
+
Low Temperature

Object-network thinking makes these correlations discoverable.

FLEXI Can Cross Hardware and Software Teams

A useful FLEXI micro-sprint might be:

Verify end-to-end brake response after a wheel-speed sensor failure.

Contributors may include:

• Sensor engineer
• Electrical engineer
• Software engineer
• Brake engineer
• Test engineer

The sprint is organized around the system question, not the department.

That is important.

Organize Work Around Behavior

A work package such as:

Develop brake software

is useful but incomplete.