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.

A stronger system work package might be:

Demonstrate controlled braking under wheel-speed signal failure.

This naturally brings together all required disciplines.

The domain model can still assign sub-work to individual teams.

But the outcome remains integrated.

Avoid the Hardware-Software Handover

One dangerous workflow is:

Hardware Team
↓
"Finished"
↓
Hand Over
↓
Software Team

This creates late discovery.

Instead:

Hardware
↔
Software
↔
Interface
↔
Continuous Integration

should evolve together.

Interfaces should be tested early, even with temporary implementations.

Digital Twins Can Support Integration

A system model can represent both real and simulated objects.

For example:

Real Controller
↔
Simulated Battery
Real Software
↔
Simulated Vehicle
Real Sensor
↔
Simulated Environment

This can reduce dependency on complete physical prototypes while maintaining system-level testing.

Simulation becomes one part of the evidence chain.

One Requirement, One Evidence Network

Suppose:

The vehicle shall reduce propulsion torque when excessive wheel slip is detected.

Evidence may include:

Sensor Test
↓
Controller Input Test
↓
Software Algorithm Test
↓
Network Timing Test
↓
Motor Response Test
↓
Vehicle Low-Friction Test

No single result proves the whole claim.

Together they form an evidence network.

QT Evaluates the Integrated Result

A Propulsion Control QT might ask:

[ ] Sensor behavior verified
[ ] Interface timing verified
[ ] Control algorithm verified
[ ] Hardware execution verified
[ ] Actuator response verified
[ ] Failure modes verified
[ ] Vehicle-level scenario verified

The threshold is crossed when the complete chain is credible.

Hardware and Software Are Different, but Not Separate

The disciplines remain different.

Mechanical engineering has its own methods.

Electronics has its own methods.

Software engineering has its own methods.

ZenOps does not erase those differences.

It creates a common layer above them:

Need

Requirement

Objects

Relations

Scenario

Evidence

Different disciplines contribute to the same outcome.

The Complete Cyber-Physical Chain

The system can be represented as:

HUMAN NEED
      ↓
NDD
      ↓
VEHICLE REQUIREMENT
      ↓
SYSTEM BEHAVIOR
      ↓
┌───────────────┬───────────────┐
↓               ↓               ↓
HARDWARE      SOFTWARE      CALIBRATION
↓               ↓               ↓
└───────────────┴───────────────┘
              ↓
         INTERFACES
              ↓
       INTEGRATED SYSTEM
              ↓
          STORYQ
              ↓
            TEST
              ↓
          EVIDENCE
              ↓
             QT
              ↓
       VEHICLE RELEASE
              ↓
        FIELD EVIDENCE

That is the integrated engineering model.

Manage the Behavior, Not the Departments

The deepest principle is simple.

Customers do not experience:

hardware behavior

and then separately:

software behavior.

They experience:

the car.

When they press the brake pedal, they expect the vehicle to slow down.

When they plug it in, they expect it to charge.

When a sensor fails, they expect the vehicle to remain predictable.

The human need is holistic.

The vehicle behavior is holistic.

Therefore the engineering model must eventually become holistic too.

ZenOps manages hardware and software as one system by asking every discipline to participate in the same traceable chain:

What human need does this behavior serve?

Which objects participate?

How are they related?

Which part is implemented in hardware, which in software, and which exists in the interface?

How can the chain fail?

What evidence proves the complete behavior?

When those questions remain connected, hardware and software stop being two projects that happen to meet inside a vehicle.

They become what they always were in reality:

two different forms of implementation inside one system.