ZenOps for Automotive Software Engineering

A modern vehicle is no longer only a mechanical machine with some software added to it.

Software now participates directly in propulsion, braking, charging, diagnostics, thermal management, driver assistance, infotainment, energy optimization, communications, and increasingly the overall behavior of the vehicle.

That makes automotive software engineering part of the core vehicle architecture.

ZenOps therefore treats software as one part of the same complete transformation:

x → NDD → Requirements → ORIGIN → Patterns → Software Architecture → Implementation → StoryQ → Evidence → QT

The goal is not merely to write code.

The goal is to preserve a traceable chain from human need to verified software behavior.

Software Starts With x Too

Suppose the customer says:

“I need the car to remain predictable and safe when something fails.”

That is not yet a software requirement.

It is part of x.

The NDD may decompose it into needs such as:

Maintain Predictable Vehicle Behavior
│
├── Detect Important Failures
├── Enter Defined Degraded Modes
├── Avoid Unsafe Commands
├── Inform Driver When Necessary
└── Recover When Conditions Permit

These needs may eventually create software requirements.

For example:

The control software shall detect loss of valid wheel-speed information within the defined diagnostic time.

The software requirement therefore exists because a higher-level need exists.

Do Not Start With Code

A dangerous development sequence is:

Feature Idea
↓
Code
↓
Test Later

ZenOps reverses this.

Human Need
↓
NDD
↓
Requirement
↓
Behavior
↓
Software Architecture
↓
Implementation
↓
Verification
↓
Evidence

The code is not the starting point.

It is one implementation artifact inside a much larger reasoning chain.

Software Is an Object Network

ORIGIN models the automotive domain as:

Objects + Relations

The same principle applies inside software.

A simplified control chain might contain:

WheelSpeedMeasurement
VehicleState
TractionController
TorqueRequest
MotorController
DiagnosticEvent

Relations might include:

WheelSpeedMeasurement
   consumed by
TractionController
TractionController
   produces
TorqueRequest
TorqueRequest
   consumed by
MotorController
TractionController
   produces
DiagnosticEvent

Software becomes another domain network rather than a disconnected body of source code.

Connect Software Objects to Physical Objects

Automotive software is cyber-physical.

Therefore the model should connect software directly to the real vehicle.

For example:

Wheel-Speed Sensor
   produces
Wheel-Speed Measurement
Wheel-Speed Measurement
   consumed by
Traction Software
Traction Software
   produces
Torque Command
Motor Controller
   executes
Torque Command
Motor
   changes
Wheel Torque

This gives us a complete chain:

Physical Reality → Data → Software Decision → Physical Action

That chain is central to automotive control systems.

Software Requirements Should Describe Behavior

A weak software requirement might say:

Implement traction-control functionality.

That is a task description.

A stronger requirement describes observable behavior:

When driven-wheel slip exceeds the defined threshold under applicable conditions, propulsion torque shall be reduced according to the defined control strategy.

Now the requirement can become a StoryQ scenario.

Scenario: Excessive driven-wheel slip
Given the vehicle is accelerating
And the road surface is low friction
When driven-wheel slip exceeds the defined threshold
Then propulsion torque shall be reduced
Until wheel slip returns within the permitted range

The software team now knows what behavior must emerge.

StoryQ/Gherkin Bridges Requirement and Code

This is especially powerful in software engineering.

The chain can become:

Requirement
↓
Gherkin Scenario
↓
Software Test
↓
Implementation
↓
Test Result
↓
Evidence

A scenario can exist before the implementation.

That gives development a target.

Instead of asking:

Is the feature coded?

we ask:

Does the scenario pass?

Patterns Reduce Repeated Software Reasoning

Automotive software contains recurring patterns.

For example:

Sense → Validate → Interpret → Decide → Act

Another:

Detect Fault → Isolate → Degrade → Report → Recover

Another:

Receive Command → Validate → Execute → Confirm

These can become reusable software patterns in the ZenOps Pattern Library.

A pattern might contain:

Software Pattern
│
├── Purpose
├── Inputs
├── Outputs
├── States
├── Failure Modes
├── Timing Constraints
├── Interfaces
├── StoryQ Templates
└── Tests

This turns successful software experience into reusable knowledge.

State Machines Become Explicit

Automotive software often depends on states.

For example:

OFF
↓
WAKE
↓
INITIALIZE
↓
READY
↓
ACTIVE
↓
DEGRADED
↓
SAFE

Each transition should have meaning.

What causes it?

What conditions are required?

What behavior is allowed?

What happens if the transition fails?

ZenOps can model these as explicit objects and relations rather than leaving them buried in code.

State Transitions Can Become StoryQ Scenarios

For example:

Scenario: Enter degraded mode after sensor failure
Given the control function is operating normally
When the required sensor signal becomes invalid
Then the function shall enter the defined degraded state
And unsafe control output shall not be generated
And the diagnostic event shall be recorded

Now the state transition becomes a verifiable contract.

Timing Is Part of the Requirement

Automotive software often has real-time behavior.

It is not enough that something eventually happens.

It may need to happen within a defined time.

For example:

Sensor Event
↓
Software Detection
↓
Decision
↓
Actuator Command

Each relation may have timing constraints.

A requirement might state:

The fault shall be detected within T milliseconds.

Another:

The actuator command shall be issued within D milliseconds after fault detection.

Timing therefore belongs in the domain model and the evidence model.

Interfaces Are Critical Software Objects

Software failures often occur at interfaces.

Examples:

• Wrong message
• Missing message
• Late message
• Stale message
• Wrong unit
• Wrong signal interpretation
• Version mismatch

Therefore the interface itself should become a first-class object.

INTERFACE-042
Sender:
Battery Controller
Receiver:
Vehicle Controller
Data:
Available Power
Timing:
Defined
Validity Rules:
Defined
Failure Behavior:
Defined

The interface can then have requirements, tests, failure modes, and QT status.

Interface Contracts Reduce Coupling

A module should not need to understand the internals of every other module.

For example:

Battery Software
   provides
AvailablePower
   to
Propulsion Software

The propulsion software should depend on the defined contract, not on hidden implementation details.

This allows software modules to evolve more independently.

Software Modules Should Align With Responsibilities

A useful software architecture might contain:

Vehicle Software
│
├── Energy Management
├── Propulsion Control
├── Brake Control
├── Thermal Control
├── Diagnostic Services
├── Communication Services
├── HMI Services
└── Update Services

Each module should have a clear responsibility.

Each should expose controlled interfaces.

This mirrors ZenOps modular vehicle architecture.

Software and Hardware Must Be Versioned Together

A software version does not exist independently of the hardware on which it runs.

Suppose:

Brake Controller HW v2.1
   executes
Brake Software v5.3

A future software version may require:

Brake Controller HW v2.2

Compatibility must therefore be explicit.

The domain model should be able to answer:

Which software versions are valid for which hardware versions?

Vehicle Configuration Must Include Software Configuration

A physical vehicle may contain:

Vehicle #000142
Brake Software v5.3
Battery Software v4.8
HMI Software v7.2
Gateway Software v3.1

Another vehicle may contain different versions.

That means two mechanically identical vehicles may behave differently.

Software configuration is part of vehicle identity.

Software Changes Can Invalidate Evidence

Suppose:

REQ-331
Status: PASS

based on software version 5.3.

Then version 5.4 changes the relevant control logic.

The old evidence may no longer be sufficient.

ZenOps should ask:

Software Change
↓
Affected Objects
↓
Affected Requirements
↓
Affected Scenarios
↓
Affected Tests
↓
Evidence Revalidation

This is much stronger than rerunning arbitrary tests.

Regression Testing Becomes Traceability-Driven

Instead of:

Run the full regression suite because software changed,

the model can identify:

Which scenarios are connected to the changed objects and relations?

That creates a more intelligent regression strategy.

Some tests remain mandatory globally.

Others can be selected based on impact.

Every Serious Bug Should Become a Scenario

Suppose a field vehicle reveals a software defect.

The fix should not merely change code.

It should ideally leave behind:

Field Failure
↓
Root Cause
↓
Requirement Update
↓
New Gherkin Scenario
↓
Regression Test
↓
Permanent Evidence

The bug becomes organizational memory.

FMEA Applies to Software Too

Software can fail in many ways:

• Incorrect calculation
• Incorrect state transition
• Missing transition
• Timing violation
• Deadlock
• Resource exhaustion
• Invalid input handling
• Recovery failure
• Configuration mismatch

These failure modes can become FMEA objects.

Software Function
↓
Failure Mode
↓
System Effect
↓
Mitigation
↓
Scenario
↓
Test
↓
Evidence

Software FMEA becomes part of the same vehicle knowledge network.

Fault Injection Is Important

If software claims to survive a communication loss, test it.

If it claims to detect invalid data, inject invalid data.

If it claims to recover after restart, force the restart.

Software Claim
↓
Fault Injection
↓
Observed Behavior
↓
Evidence

That converts assumptions into demonstrated behavior.

FLEXI Fits Software Development Naturally

Software can use FLEXI micro-sprints particularly effectively.

Instead of:

Work on battery diagnostics.

use:

Make Scenario SCN-188 pass.

A micro-sprint might be:

Question:
Does the software detect a frozen sensor value?
Implement detection
↓
Inject frozen signal
↓
Observe response
↓
Record result
↓
Update evidence

Each small cycle reduces uncertainty.

One-Day Software Micro-Sprints

Many software questions can be attacked in short cycles.

Examples:

• Verify one state transition
• Implement one diagnostic
• Validate one interface timeout
• Test one failure mode
• Remove one ambiguity in a requirement
• Reproduce one field issue

The complete system may take years.

Learning can still occur daily.

Quality Thresholds for Software

A software QT might look like:

SOFTWARE QT
[ ] Requirements traceable
[ ] Architecture defined
[ ] Interfaces defined
[ ] Core scenarios passing
[ ] Timing verified
[ ] Failure behavior verified
[ ] Diagnostics verified
[ ] Regression evidence accepted
[ ] Hardware integration verified
[ ] Configuration controlled
[ ] Residual risks accepted

The software is not ready because development says:

Coding complete.

It is ready because the evidence supports release.

Lines of Code Are Not Progress

This is an important ZenOps principle.

A million lines of source code do not prove that the software satisfies the vehicle need.

Nor does:

• Number of commits
• Number of features
• Number of closed tickets

The central question remains:

Which required behaviors can we support with evidence?

Source code is implementation.

Evidence is confidence.

Software QT Can Be Recursive

Different layers can have their own QTs.

Software Release QT
│
├── Module QT
│   ├── Requirement Evidence
│   ├── Unit Evidence
│   └── Interface Evidence
│
├── Integration QT
│
├── Timing QT
│
├── Diagnostic QT
│
└── Vehicle-Level QT

This mirrors the recursive structure of the vehicle itself.

Test at Multiple Levels

Software evidence can come from:

Unit Test
↓
Module Test
↓
Software Integration Test
↓
Hardware-in-the-Loop
↓
Vehicle Integration Test
↓
Field Evidence

Each level answers different questions.

A unit test can prove local logic.

It cannot prove full vehicle behavior.

Hardware-in-the-Loop Connects Software to Reality

Hardware-in-the-loop testing is especially useful because it allows software and controllers to experience realistic signals and system behavior before full vehicle availability.

In ZenOps terms:

Requirement
↓
Scenario
↓
HIL Environment
↓
Controller + Software
↓
Observed Behavior
↓
Evidence

This provides early evidence while physical prototypes are still limited.

Simulation Is Evidence, But Not All Evidence

Simulation is valuable.

Software-in-the-loop is valuable.

Virtual testing is valuable.

But the strength of evidence depends on what is being claimed.

A simulation can strongly support some claims.

Other claims eventually require real controllers, real timing, real networks, real sensors, or full vehicles.

QT should determine whether the evidence is sufficient for the decision.

Automotive Software Is Increasingly Distributed

Modern vehicle behavior may span many controllers.

For example:

Sensor Controller
↓
Vehicle Network
↓
Central Compute
↓
Domain Controller
↓
Actuator Controller

A function may therefore be distributed across multiple machines.

The software architecture must model:

• Ownership
• Data flow
• Timing
• States
• Failure propagation
• Recovery

The function exists across the network.

Distributed Functions Need End-to-End Tests

Testing each controller independently is not enough.

For a distributed function, the real requirement may apply to the complete chain.

Sensor
↓
Network
↓
Software
↓
Network
↓
Actuator

The end-to-end behavior must eventually be verified.

This is another reason ZenOps focuses on relations.

Diagnostics Should Be Designed With the Software

Diagnostics should not be bolted on afterward.

For every important software function, ask:

How can it fail?
How will the system detect the failure?
What data will be recorded?
What degraded behavior follows?
How will service identify the cause?

Diagnostics become part of the design.

Diagnostic Events Can Be Domain Objects

For example:

DIAG-00721
Triggered by:
Wheel-Speed Signal Invalid
Associated Function:
Traction Control
Vehicle Effect:
Degraded Control
Related Requirement:
REQ-441

A field occurrence of this diagnostic can then connect directly back to engineering.

The Fleet Becomes a Software Evidence Source

After launch, real vehicles generate new knowledge.

For example:

Software v5.3
   associated with
Failure Pattern A
Software v5.4
   associated with
Reduced Failure Rate

Field evidence can therefore validate or challenge software assumptions.

The released software continues to participate in the learning loop.

Software Updates Reopen the Vehicle Model

If software changes vehicle behavior, then an update is an engineering change to the physical product’s behavior.

The process should therefore be:

Software Change
↓
Impact Analysis
↓
Requirements
↓
Scenarios
↓
Tests
↓
Evidence
↓
QT
↓
Release

An update should not escape the need-to-evidence chain merely because no hardware changed.

Patterns Can Support Software Reuse Across Platforms

Suppose several vehicles use the same diagnostic pattern.

The implementations may differ.

But the knowledge can be reused:

Vehicle A
↓
Diagnostic Pattern v2
↓
Evidence
Vehicle B
↓
Diagnostic Pattern v2
↓
More Evidence
Vehicle C
↓
Diagnostic Pattern v3

Software reuse becomes evidence-informed rather than simple code copying.

Reuse Behavior, Not Just Code

This is an important distinction.

Copying source code is not the same as reusing engineering knowledge.

A reusable software package should ideally carry:

• Purpose
• Requirements
• Interfaces
• Assumptions
• Failure modes
• Tests
• Evidence
• Known limitations

That gives future engineers the context needed to use it safely.

The Software Domain Should Stay Connected to the Vehicle Domain

Avoid creating a separate universe where software teams have their own isolated models.

Instead:

Vehicle Requirement
↓
Vehicle Function
↓
Software Function
↓
Software Object
↓
Hardware Controller
↓
Physical Actuator

The software remains part of the vehicle.

This keeps system-level reasoning intact.

The Complete ZenOps Software Chain

The full model can be expressed as:

HUMAN NEED
      ↓
x
      ↓
NDD
      ↓
VEHICLE REQUIREMENT
      ↓
SOFTWARE REQUIREMENT
      ↓
ORIGIN
      ↓
SOFTWARE OBJECTS + RELATIONS
      ↓
PATTERNS
      ↓
SOFTWARE ARCHITECTURE
      ↓
STORYQ / GHERKIN
      ↓
IMPLEMENTATION
      ↓
UNIT + INTEGRATION + HIL + VEHICLE TEST
      ↓
EVIDENCE
      ↓
SOFTWARE QT
      ↓
RELEASE
      ↓
FIELD EVIDENCE
      ↓
UPDATED SOFTWARE MODEL

The loop continues for every software version.

Code Is Not the Product

This is perhaps the most important conclusion.

Automotive software engineering can easily become code-centric.

But the real product is not the source code.

The real product is vehicle behavior.

Code exists to produce that behavior.

Tests exist to observe it.

Evidence exists to justify confidence in it.

ZenOps therefore asks software engineering to preserve one continuous chain:

Why does this software exist?

What behavior is it responsible for?

Which objects and relations does it interact with?

How can it fail?

Which scenarios define correct behavior?

What evidence shows that the behavior is real?

When those questions remain answerable, automotive software stops being an invisible layer buried inside controllers.

It becomes a traceable part of the vehicle’s domain model.

And that is the ZenOps view of automotive software engineering:

not code for code’s sake, but software as an evidence-backed transformation of human need into vehicle behavior.