ZenOps for Autonomous and Assisted Driving Systems

Autonomous and assisted driving systems create a particularly difficult automotive engineering problem.

A conventional vehicle largely responds to commands from a human driver.

An assisted or automated vehicle increasingly participates in deciding:

• What exists around the vehicle
• What those objects are doing
• What may happen next
• What maneuver should be performed
• How the vehicle should execute that maneuver
• When control should remain with the human
• What should happen when the system becomes uncertain

This changes the engineering problem fundamentally.

The vehicle is no longer merely executing commands.

Parts of the vehicle are interpreting reality.

ZenOps provides a useful structure for managing this complexity:

x → NDD → Requirements → ORIGIN → Patterns → Driving Architecture → Scenarios → Evidence → QT

The objective is not simply to create an autonomous-driving algorithm.

It is to build a traceable system that connects human need to demonstrated behavior in the real driving environment.

Start With the Human Need

The starting point should not be:

Build an autonomous vehicle.

“Autonomous vehicle” is already a proposed solution.

The original need may be closer to:

Help people travel safely and efficiently while reducing the amount of continuous driving effort required from the human.

Different users may have different needs:

Mobility
│
├── Reduce Driving Workload
├── Improve Safety
├── Support Long Journeys
├── Assist in Congestion
├── Improve Parking
├── Support Limited-Mobility Users
└── Reduce Human Driving Errors

These needs can lead to very different solutions.

Perhaps the correct solution is lane assistance.

Perhaps adaptive cruise control.

Perhaps automated parking.

Perhaps highly automated highway operation.

Perhaps eventually full automated driving.

ZenOps keeps the distinction between need and solution visible.

Build the Automated-Driving NDD

Suppose the system is intended to provide assisted highway driving.

The NDD might contain:

Provide Assisted Highway Travel
│
├── Maintain Safe Following Distance
├── Maintain Lane Position
├── Recognize Relevant Traffic
├── Respond to Changing Traffic
├── Respect Operating Boundaries
├── Maintain Driver Awareness
├── Detect System Limitations
├── Transfer Control Safely
└── Enter Safe State When Necessary

These needs become the foundation for requirements.

The system architecture should emerge from them.

Driving Is a Closed Loop

A useful high-level pattern is:

Observe → Understand → Decide → Act → Observe Again

For an automated-driving system:

Environment
↓
Sensors
↓
Perception
↓
World Model
↓
Decision / Planning
↓
Vehicle Control
↓
Actuators
↓
Vehicle Motion
↓
Environment

This is a continuous loop.

Every action changes reality.

Reality produces new observations.

The system must then evaluate the new state.

Model the Driving Domain With ORIGIN

The relevant objects are not confined to the vehicle.

They may include:

Vehicle
Driver
Camera
Radar
Other Vehicle
Pedestrian
Cyclist
Lane
Road
Traffic Sign
Traffic Signal
Obstacle
Weather
Map
Localization System
Control Software
Brake System
Steering System

Relations might include:

Camera
   observes
Pedestrian
Vehicle
   travels in
Lane
Vehicle
   follows
Other Vehicle
Driver
   supervises
Driving Function
Driving Function
   commands
Steering System

The domain model therefore extends beyond the physical boundary of the car.

The road environment becomes part of the operational model.

Perception Converts Measurements Into Meaning

A sensor does not simply tell the vehicle:

There is a pedestrian.

It produces measurements.

Software interprets those measurements.

The chain may be:

Physical Person
↓
Light / Radar Reflection
↓
Sensor
↓
Measurement
↓
Perception Algorithm
↓
Detected Object
↓
Classification
↓
World Model

Every transformation introduces uncertainty.

That uncertainty must be understood.

A Detection Is Not Reality

Suppose the perception system reports:

Object:
Pedestrian
Position:
X,Y
Velocity:
V
Confidence:
92%

That is not the pedestrian.

It is the system’s interpretation of sensor evidence.

The distinction is critical.

ZenOps should therefore model both:

Real-world object

and:

system representation of that object.

This prevents the internal model from being confused with reality itself.

Relations Can Carry Uncertainty

A normal ORIGIN relation might be:

Camera
   observes
Vehicle

For automated driving, we may need richer semantics:

Perception System
   estimates with confidence C
Object Type = Vehicle

Uncertainty becomes part of the relationship.

This matters because driving decisions may depend on the quality of the observation.

Sensor Fusion Is a Relation Pattern

Different sensors have different strengths.

An architecture may combine:

Camera
+
Radar
+
Other Applicable Sensors
↓
Sensor Fusion
↓
World Model

The important engineering question is not merely:

How accurate is each sensor?

It is also:

How do their observations interact?

What happens when they agree?

What happens when they disagree?

What happens when one disappears?

These become explicit scenarios.

The World Model Is a Critical Object

The automated-driving system needs some internal representation of its surroundings.

For example:

WORLD MODEL
│
├── Ego Vehicle
├── Road Geometry
├── Lanes
├── Vehicles
├── Pedestrians
├── Cyclists
├── Obstacles
├── Traffic Controls
└── Predicted Motion

Planning operates on this representation.

Therefore errors in the world model can propagate into vehicle behavior.

Planning Converts Understanding Into Intent

Suppose the system determines:

Vehicle Ahead
↓
Distance Decreasing
↓
Current Speed Unsuitable

Planning might decide:

Reduce Speed

The chain becomes:

Observation
↓
Interpretation
↓
Prediction
↓
Decision
↓
Maneuver

Each transformation can have requirements.

Each can have failure modes.

Each can generate evidence.

Control Converts Intent Into Physical Motion

Planning might request:

Decelerate to 70 km/h.

Vehicle control must translate that into physical action.

Desired Motion
↓
Control Software
↓
Brake / Motor Commands
↓
Actuators
↓
Vehicle Dynamics

This connects automated driving directly to the hardware-software object network discussed in previous ZenOps entries.

The autonomous-driving stack cannot be treated independently of the vehicle underneath it.

Define the Operational Boundary

One of the most important questions is:

Under what conditions is this function intended to operate?

The answer may depend on:

• Road type
• Speed
• Weather
• Visibility
• Lane markings
• Geography
• Traffic conditions
• Sensor availability
• Vehicle condition

The operating boundary should become explicit.

For example:

Driving Function
   permitted when
Operating Conditions = Valid

Outside those conditions:

Driving Function
   shall not claim
Normal Automated Operation

Knowing when not to operate is part of correct behavior.

Boundary Detection Is a Requirement

It is not enough to define an operational boundary on paper.

The vehicle must determine whether the current situation remains inside it.

Therefore:

Operating Boundary
↓
Observable Conditions
↓
Detection Logic
↓
System State

This generates requirements.

For example:

The system shall detect when required lane information is no longer sufficiently reliable.

That requirement can become a scenario.

StoryQ Turns Driving Situations Into Tests

Consider lane assistance.

Scenario: Lane information becomes unreliable
Given assisted driving is active
And lane information is initially sufficient
When lane information falls below the defined reliability criteria
Then the system shall detect the limitation
And shall transition according to the defined degraded strategy
And shall inform the driver when driver action is required

Now the operating-boundary concept becomes observable behavior.

Scenario Engineering Becomes Central

Automated-driving systems face enormous numbers of possible situations.

Examples include:

Vehicle cuts in ahead
Vehicle brakes suddenly
Lane disappears
Road construction changes lane geometry
Pedestrian enters roadway
Sensor becomes obstructed
Heavy rain reduces visibility
Emergency vehicle approaches
Stationary object appears ahead
Driver fails to respond to takeover request

Each scenario represents a question to the system.

Scenarios Should Become Domain Objects

A scenario can have identity:

SCN-00421
Name:
Vehicle Cuts In
Initial State:
Highway driving
Actors:
Ego Vehicle
Target Vehicle
Trigger:
Target enters ego lane
Expected Behavior:
Maintain safe trajectory

Now scenarios can connect to:

Requirements
Hazards
Objects
Failure Modes
Tests
Evidence
QT

The scenario library becomes part of the domain model.

Scenario Variation Creates the Real Challenge

“Vehicle cuts in” is not one situation.

Parameters may include:

Relative Speed
Distance
Cut-In Angle
Road Curvature
Surface Friction
Lighting
Weather
Vehicle Type
Ego Speed
Traffic Density

A scenario therefore becomes a parameterized space.

Testing must explore that space intelligently.

Scenario Outlines Can Represent Variations

Conceptually:

Scenario Outline: Vehicle cuts into ego lane
Given assisted driving is active
And ego speed is <ego_speed>
And the target vehicle is at <distance>
When the target vehicle enters the ego lane
Then the system shall maintain the defined safety criteria
Examples:
| ego_speed | distance |
| V1        | D1       |
| V2        | D2       |
| V3        | D3       |

The exact engineering parameter set can be maintained separately.

The behavioral pattern remains readable.

Normal Driving Is Not Enough

A system can perform beautifully during ordinary driving and still fail in rare but important situations.

Therefore the scenario library must include:

Normal Scenarios
Boundary Scenarios
Failure Scenarios
Rare Scenarios
Recovery Scenarios

FMEA and safety analysis help generate the negative cases.

FMEA Becomes Scenario Generation

Suppose:

Failure Mode:
Front camera unavailable

Potential effect:

Reduced perception capability

This can generate:

Scenario: Front camera becomes unavailable during assisted driving
Given assisted driving is active
And the front camera is operating normally
When the front camera becomes unavailable
Then the failure shall be detected
And the driving function shall enter the defined degraded state
And the driver shall be informed according to the defined strategy

The FMEA has become executable behavior.

Safety Exists Across the Entire Chain

Consider:

Pedestrian
↓
Sensor
↓
Perception
↓
World Model
↓
Prediction
↓
Planning
↓
Control
↓
Brakes

A failure anywhere can affect the final outcome.

Therefore safety analysis must consider complete propagation paths.

The question is not only:

Did the pedestrian detector work?

It is:

Did the complete vehicle respond safely to the pedestrian situation?

Human Supervision Is Part of the System

For assisted-driving systems, the human may remain responsible for part of the driving task.

Therefore:

Driving System
↔
Driver

is a critical relation.

The architecture must define:

• What the system controls
• What the human controls
• What the human must monitor
• How control transitions occur
• How the system communicates limitations

Ambiguity here is dangerous.

Mode Confusion Is an Engineering Problem

Suppose the driver believes:

The vehicle is controlling steering.

while the system has actually disengaged.

That is a failure in the human-machine relation.

Therefore system state must be communicated clearly.

Actual System State
↓
HMI
↓
Driver Understanding

The final safety property depends on all three.

Takeover Is a Complete Process

A takeover should not be modeled simply as:

Show warning.

The chain may be:

System Detects Limitation
↓
Takeover Requested
↓
Driver Receives Request
↓
Driver Understands Request
↓
Driver Becomes Ready
↓
Control Transfers
↓
Vehicle Remains Stable

Each relation can fail.

The complete process requires evidence.

What If the Driver Does Not Respond?

The architecture must explicitly consider this.

Takeover Request
↓
No Driver Response
↓
Escalation
↓
Defined Fallback
↓
Risk-Reducing Maneuver

Failure handling is part of normal system design.

It cannot be postponed until validation.

Minimal-Risk Behavior Is a Pattern

A reusable ZenOps pattern might be:

Detect Limitation → Request Intervention → Escalate → Reduce Risk → Reach Defined State

Different vehicle systems may implement this differently.

But the pattern can be reused.

The Pattern Library can contain:

Purpose
Assumptions
Objects
Relations
States
Failure Modes
StoryQ Scenarios
Verification Methods
Evidence

Driving Software Is State-Heavy

An assisted-driving function may contain states such as:

UNAVAILABLE
↓
AVAILABLE
↓
READY
↓
ACTIVE
↓
DEGRADED
↓
TAKEOVER REQUESTED
↓
FALLBACK

Transitions must be explicit.

For each transition:

What triggers it?

What conditions permit it?

What does the vehicle do?

What does the driver see?

What happens if the transition fails?

This turns hidden software logic into engineering knowledge.

Every State Transition Can Become a Scenario

For example:

Scenario: Assisted driving becomes unavailable
Given assisted driving is active
When required operating conditions are no longer satisfied
Then the system shall transition out of normal automated operation
And the driver shall receive the defined indication
And vehicle behavior shall remain within the required safety limits

The state machine becomes testable.

Evidence Must Exist at Multiple Levels

Automated-driving evidence may come from:

Unit Tests
↓
Software Integration Tests
↓
Simulation
↓
Software-in-the-Loop
↓
Hardware-in-the-Loop
↓
Closed-Course Tests
↓
Vehicle Tests
↓
Field Evidence

No single level answers every question.

Simulation provides scale.

Physical testing provides reality.

Field evidence provides operational learning.

Simulation Is Especially Important

The number of relevant driving scenarios can be enormous.

Physical testing alone cannot efficiently explore every useful combination.

Simulation can evaluate large scenario spaces:

Scenario
×
Speed
×
Distance
×
Weather
×
Road Geometry
×
Actor Behavior

This produces evidence rapidly.

But the simulation itself must be credible for the claim being made.

Evidence About the Simulator Matters Too

If simulation is used to support a critical decision, we should ask:

Why do we trust the simulation?

That creates another evidence chain:

Simulation Model
↓
Validation Against Reality
↓
Model Evidence
↓
Simulation Credibility

Evidence generation itself may require evidence.

ZenOps can preserve that relationship.

Physical Tests Anchor the Model

Simulation results can be compared with:

• Proving-ground tests
• Controlled traffic scenarios
• Hardware measurements
• Real sensor data
• Vehicle dynamics data

The comparison improves confidence in the virtual environment.

The loop becomes:

Simulation
↔
Physical Test
↔
Model Refinement

Scenario Coverage Is Better Than Kilometer Counting Alone

A statement such as:

We drove millions of kilometers.

sounds impressive.

But the stronger question is:

Which relevant situations occurred during those kilometers?

Ten million kilometers of easy highway driving may tell us less about one critical rare scenario than a carefully designed test.

ZenOps therefore emphasizes scenario evidence, not merely accumulated distance.

Evidence Should Connect to Scenario Space

Imagine:

SCN-421 Vehicle Cut-In
Parameter Coverage:
Speed        ██████████
Distance     █████████░
Weather      ███████░░░
Night        █████░░░░░
Low Friction ███░░░░░░░

Now engineering can see where evidence is strong and where uncertainty remains.

UNKNOWN becomes actionable.

FLEXI Can Target Scenario Gaps

Suppose the model reveals:

Scenario:
Pedestrian crossing
Night + Rain:
Evidence = UNKNOWN

That creates a FLEXI question:

How does the current system behave for this scenario under night-and-rain conditions?

The team can:

Configure Scenario
↓
Run Simulation
↓
Analyze Result
↓
Run Physical Test if Required
↓
Collect Evidence
↓
Update Model

FLEXI becomes a mechanism for reducing scenario uncertainty.

Quality Thresholds Should Evaluate Behavior

An assisted-driving QT might contain:

ASSISTED DRIVING QT
[ ] Operating boundary defined
[ ] Boundary detection verified
[ ] Core perception scenarios verified
[ ] Planning behavior verified
[ ] Control behavior verified
[ ] Driver interaction verified
[ ] Failure modes verified
[ ] Degraded modes verified
[ ] Takeover behavior verified
[ ] Fallback behavior verified
[ ] Scenario coverage accepted
[ ] Residual uncertainty accepted

The system does not pass because:

Development is 95% complete.

It passes because the evidence is sufficient for the decision.

Perception Needs Its Own Evidence Network

For a pedestrian-detection function:

Pedestrian Detection Requirement
↓
Day Scenario
Night Scenario
Rain Scenario
Partial Occlusion Scenario
Crossing Scenario
Stationary Scenario
↓
Tests
↓
Evidence

A single accuracy number may hide important weaknesses.

The scenario structure provides context.

Planning Needs Behavioral Evidence

Suppose perception correctly identifies another vehicle.

Planning can still fail.

Possible planning failures include:

• Unsafe gap selection
• Excessive acceleration
• Late braking
• Unstable lane change
• Failure to yield

Planning therefore needs its own requirements and scenarios.

Control Needs Physical Evidence

A perfect trajectory in software does not guarantee the physical vehicle can execute it.

The vehicle may encounter:

• Low friction
• Tire variation
• Actuator limits
• Brake temperature
• Steering limitations

Therefore:

Planned Trajectory
↓
Vehicle Controller
↓
Physical Vehicle
↓
Actual Trajectory

must eventually be verified.

Hardware and Software Remain One System

Autonomous driving makes this especially obvious.

The complete chain includes:

Camera Hardware
+
Sensor Software
+
Perception Software
+
Compute Hardware
+
Planning Software
+
Control Software
+
Network
+
Actuator Hardware
+
Vehicle Dynamics

The customer experiences the result of all of them simultaneously.

ZenOps therefore manages them as one object network.

Redundancy Must Be Evaluated as Behavior

Adding two sensors does not automatically create safety.

Suppose:

Camera
+
Radar

Both may fail to provide useful information under some shared environmental condition.

The question is:

Does the complete architecture still produce acceptable behavior?

Redundancy must therefore be verified through scenarios.

Common-Cause Failure Matters

Several systems may depend on:

Shared Power
Shared Compute
Shared Network
Shared Clock
Shared Software Component

These dependencies can defeat apparent redundancy.

The object network helps reveal them.

Diagnostics Become Crucial

When an automated-driving function becomes unavailable, service needs to understand why.

Potential causes may include:

Sensor Hardware
Sensor Obstruction
Calibration
Network
Compute Hardware
Software
Configuration

Diagnostics should connect field events back to the domain model.

Manufacturing Must Preserve Sensor Geometry

For perception systems, manufacturing variation matters.

A camera installed at the wrong angle may alter system behavior.

Therefore production may need evidence for:

Sensor Identity
Sensor Position
Sensor Orientation
Calibration
Software Version
Vehicle Geometry

The automated-driving system begins in engineering but continues through manufacturing.

Service Can Change the Perception System

Suppose a windshield-mounted camera is replaced.

The service process may require:

Replace Camera
↓
Verify Installation
↓
Calibrate
↓
Verify Software Compatibility
↓
Execute Functional Test
↓
Record Evidence

A simple component replacement becomes a system-level operation.

Vehicle Identity Must Include Automation Configuration

A vehicle instance may need traceability for:

Vehicle #000142
Camera HW v3
Radar HW v2
Compute HW v4
Perception SW v8.2
Planning SW v6.1
Control SW v5.7
Calibration Set C218

Field evidence without configuration context can be misleading.

Software Updates Reopen the Evidence Chain

Suppose planning software changes.

Even if hardware remains identical:

Software Change
↓
Affected Behaviors
↓
Affected Scenarios
↓
Regression Tests
↓
Evidence
↓
QT
↓
Deployment

An over-the-air update can therefore change the driving product after manufacture.

Field Evidence Is Essential

Real roads continuously reveal conditions that engineering did not fully anticipate.

A field event might expose:

Unusual Road Geometry
+
Specific Weather
+
Specific Sensor Configuration
+
Specific Software Version
↓
Unexpected Behavior

This should feed directly back into engineering.

Every Important Field Event Should Become Knowledge

The loop is:

Field Event
↓
Reconstruction
↓
Scenario
↓
Root Cause
↓
Requirement / Model Update
↓
Corrective Work
↓
Regression Test
↓
Evidence
↓
Pattern Library

A surprising event should become less surprising the next time.

The Fleet Becomes a Scenario Discovery System

Development engineers create scenarios based on what they expect.

The fleet discovers scenarios based on what actually happens.

That creates a powerful feedback loop:

Scenario Library
↓
Vehicle Release
↓
Fleet
↓
New Situations
↓
New Scenarios
↓
Expanded Scenario Library

The model grows with reality.

Patterns Become More Valuable Over Time

Suppose several programs encounter similar problems with sensor obstruction.

The organization can develop a reusable pattern:

Sensor Obstruction Pattern
│
├── Detection
├── Confidence Reduction
├── Functional Limitation
├── Driver Notification
├── Recovery
├── Scenarios
└── Evidence

The next vehicle program inherits the knowledge.

This is how ZenOps turns experience into reusable engineering capital.

Autonomous Driving Is Ultimately an Uncertainty Problem

A conventional deterministic software function may have relatively well-defined inputs.

Driving exists in an open world.

The vehicle may encounter situations not represented exactly in development.

Therefore the system must manage uncertainty.

It should know not only:

What do I think is happening?

but also:

How confident am I?

and:

What should I do when confidence is insufficient?

This is a fundamental architectural requirement.

UNKNOWN Must Be a Valid System Concept

ZenOps already treats UNKNOWN as useful engineering information.

Automated driving needs a similar idea operationally.

If the system cannot establish sufficient confidence, it should not invent certainty.

Conceptually:

Known
↓
Act Normally
Uncertain
↓
Increase Caution
Insufficient Confidence
↓
Degrade / Request Intervention / Reduce Risk

The exact behavior depends on the system and operating context.

The principle is general.

The System Must Know Its Limits

Intelligence is not only the ability to make decisions.

It is also the ability to recognize when available information is insufficient for a reliable decision.

That means the architecture must model:

Capability
+
Operating Boundary
+
Confidence
+
Fallback

Together, these define responsible automated behavior.

The Complete ZenOps Automated-Driving Chain

The full model can now be represented as:

HUMAN NEED
      ↓
x
      ↓
NDD
      ↓
DRIVING REQUIREMENTS
      ↓
ORIGIN
      ↓
OBJECTS + RELATIONS
      ↓
OPERATING BOUNDARY
      ↓
PERCEPTION
      ↓
WORLD MODEL
      ↓
PLANNING
      ↓
CONTROL
      ↓
PHYSICAL VEHICLE
      ↓
SCENARIOS
      ↓
FMEA + SAFETY ANALYSIS
      ↓
STORYQ / GHERKIN
      ↓
SIMULATION + PHYSICAL TEST
      ↓
EVIDENCE
      ↓
QT
      ↓
RELEASE
      ↓
FIELD EVIDENCE
      ↓
NEW SCENARIOS
      ↓
IMPROVED MODEL

The loop continues throughout the vehicle’s life.

From Driving Intelligence to Evidence

The most impressive autonomous-driving demonstration is not necessarily the most important engineering result.

A vehicle can perform brilliantly for an hour and still contain dangerous gaps.

ZenOps asks a different set of questions:

What human need are we solving?

Under exactly which conditions is the function intended to operate?

What does the vehicle need to perceive?

What decisions can it make?

What uncertainty exists?

What happens when sensors or software fail?

What happens when the system reaches the edge of its capability?

What does the human need to understand?

Which scenarios challenge these assumptions?

What evidence demonstrates acceptable behavior?

This changes the objective.

The goal is not merely to create a vehicle that appears intelligent.

The goal is to create a vehicle whose behavior can be understood, bounded, challenged, tested, and supported by evidence.

Because assisted and automated driving ultimately asks a machine to participate in decisions inside a complex physical world.

That makes the ZenOps principle especially important:

Model what the system knows.

Model what it does not know.

Model how it acts.

Model how it fails.

Test the scenarios.

Preserve the evidence.

And let reality continuously improve the model.