Designing Safety into the Object Network

Automotive safety is often discussed as though it belongs to a dedicated subsystem.

Airbags.

Brakes.

Crash structures.

Driver-assistance systems.

Safety controllers.

These are all important.

But a vehicle is not safe because it contains a collection of “safety components.”

A vehicle is safe because the relationships between its objects continue to produce acceptable behavior, including when parts of the system fail.

That is a much stronger idea.

In ZenOps, safety can therefore be designed directly into the automotive object network.

The chain becomes:

x → NDD → Requirements → ORIGIN → Safety Relations → FMEA → StoryQ → Evidence → QT

The goal is not merely to ask:

Which objects are safety-critical?

It is to ask:

Which object relations must remain trustworthy for the human need to remain protected?

Safety Begins With Human Need

The highest-level safety requirement is not:

Install airbags.

Nor:

Use redundant controllers.

Those are solutions.

The need is closer to:

Protect human life and reduce unacceptable harm during vehicle operation.

That can be decomposed through the NDD:

Protect Human Life
│
├── Avoid Preventable Accidents
├── Maintain Vehicle Control
├── Detect Dangerous Conditions
├── Protect Occupants During Collision
├── Protect Other Road Users
├── Manage Failures Safely
└── Support Emergency Response

These needs then become engineering requirements.

Only after that should architecture and technology enter.

Safety Is Distributed Across the Vehicle

Consider emergency braking.

The safety outcome may depend on:

Driver
↓
Brake Pedal
↓
Sensor
↓
Controller
↓
Software
↓
Actuator
↓
Brake
↓
Wheel
↓
Tire
↓
Road

If any critical part of this chain behaves incorrectly, braking performance can degrade.

Safety therefore exists across the network.

It is not localized in one object.

This leads to a central principle:

A safety property belongs to a path through the object network.

Safety Requirements Can Attach to Relations

Suppose:

Wheel-Speed Sensor
   reports to
Brake Controller

That relation may carry safety constraints such as:

• Maximum acceptable latency
• Signal validity rules
• Error detection
• Timeout behavior
• Recovery behavior

The relation itself becomes safety-relevant.

This is important because many failures occur not because an object stops existing, but because communication or interaction becomes incorrect.

Model Safe and Unsafe Relations

A normal relation might be:

Sensor
   reports
Wheel Speed
   to
Controller

A failure relation might be:

Sensor
   reports
Incorrect Wheel Speed
   to
Controller

The second relation may drive unsafe behavior unless detection exists.

Therefore the object network should not model only intended relations.

It should also model:

• Missing relations
• Delayed relations
• Corrupted relations
• Contradictory relations
• Unintended relations

This connects naturally to FMEA.

Safe Behavior Must Exist Under Failure

A robust vehicle is not one where components never fail.

That is unrealistic.

A robust vehicle is one where important failures are anticipated and the system responds appropriately.

Suppose one wheel-speed sensor fails.

The intended response might be:

Sensor Failure
↓
Detect Invalid Data
↓
Isolate Failed Signal
↓
Use Degraded Control Strategy
↓
Limit Function if Required
↓
Record Diagnostic Event
↓
Inform Driver if Necessary

The safety architecture therefore includes both:

normal behavior

and:

failure behavior.

Safety Can Be Modeled as State Preservation

Another useful perspective is to define acceptable system states.

For example:

NORMAL
↓
DEGRADED
↓
SAFE STOP

A failure should not allow the system to jump unpredictably into an unsafe state.

Instead, the architecture should define permissible transitions.

For example:

Normal
   ↓ sensor failure
Degraded
   ↓ multiple failures
Restricted Operation
   ↓ critical condition
Safe Stop

Safety becomes a controlled state-transition problem.

Safety Patterns Belong in the Pattern Library

Many safety structures repeat.

For example:

Detect → Isolate → Degrade → Report → Recover

Another:

Observe → Cross-Check → Reject Invalid → Continue Safely

Another:

Command → Verify Actuation → Detect Mismatch → Enter Safe State

These can become reusable ZenOps patterns.

Each pattern can contain:

Safety Pattern
│
├── Purpose
├── Context
├── Objects
├── Relations
├── Failure Modes
├── Required Responses
├── StoryQ Scenarios
├── Tests
└── Evidence

Safety knowledge becomes reusable.

Redundancy Is a Relation Strategy

Redundancy is often treated as “adding another component.”

But in object-network terms, redundancy changes the relation structure.

For example:

Sensor A
    ↘
    Controller
    ↗
Sensor B

Now the controller can compare independent information sources.

The safety logic might be:

Sensor A
+
Sensor B
↓
Cross-Check
↓
Agreement?
├── Yes → Continue
└── No → Degraded / Diagnostic

The safety benefit comes not from merely having two sensors.

It comes from the relations between them.

Diversity Can Improve Robustness

Two identical sensors may fail for the same reason.

A stronger architecture may use diverse information sources:

Wheel-Speed Sensor
+
Vehicle Acceleration Estimate
+
Motor-Speed Estimate
↓
Plausibility Evaluation

Now one source can challenge another.

This may reduce common-cause risk.

Again, the important property exists in the network.

Safety Boundaries Must Be Explicit

Modular architecture can help safety if boundaries are well defined.

Suppose:

Brake Module

exposes:

• Command interface
• Status interface
• Diagnostic interface
• Safe-state behavior

Other systems can then rely on a defined contract.

But if safety assumptions remain hidden inside the module, integration becomes dangerous.

A safe module should explicitly state:

What do I guarantee?

Under what conditions?

What happens when those conditions are violated?

This turns the module boundary into a safety contract.

Safety Contracts Connect Modules

Consider:

Vehicle Controller
   commands
Brake Module

The interface may require:

Controller promises:

• Commands remain within defined range
• Communication timing remains within limits

Brake Module promises:

• Valid commands are executed
• Invalid commands are rejected
• Communication loss triggers defined fallback

This creates bidirectional responsibility.

The interface is no longer just a data connection.

It becomes a behavioral contract.

FMEA Tests the Safety Network

FMEA asks:

What happens when an object or relation fails?

For each safety-relevant relation, we can ask:

What if the message is missing?
What if it is late?
What if it is wrong?
What if the sender fails silently?
What if two failures occur together?

This systematically explores the safety network.

The results can generate requirements, mitigations, scenarios, and tests.

Safety Requirements Should Generate StoryQ Scenarios

Suppose the safety requirement says:

The vehicle shall prevent unsafe propulsion after a critical inverter fault.

A Gherkin scenario might be:

Scenario: Critical inverter fault during propulsion
Given the vehicle is producing propulsion torque
When a critical inverter fault is detected
Then propulsion torque shall be reduced according to the defined safe strategy
And the fault shall be recorded
And the driver shall be informed according to the defined warning strategy

Now the safety claim becomes observable behavior.

Failure Injection Is Essential

A safety mechanism that has never been tested under failure is only a design intention.

If the architecture says:

Sensor failure is detected,

then deliberately create sensor failure.

If it says:

Communication timeout leads to safe degradation,

then interrupt communication.

If it says:

Actuator mismatch is detected,

then inject a mismatch.

The loop becomes:

Safety Claim
↓
Failure Scenario
↓
Failure Injection
↓
Observed Behavior
↓
Evidence

Safety becomes demonstrated rather than assumed.

Safety QTs Should Be Evidence-Based

A safety QT might include:

SAFETY QT
[ ] Critical hazards identified
[ ] Safety-relevant relations identified
[ ] Failure modes modeled
[ ] Safety mechanisms implemented
[ ] Degraded states defined
[ ] Failure scenarios tested
[ ] Safety interfaces verified
[ ] Residual risks evaluated
[ ] Evidence accepted

The safety threshold is not crossed because the safety document exists.

It is crossed because the evidence is sufficient.

Safety Should Be Recursive

The same reasoning applies at multiple levels.

At component level:

Sensor
↓
Failure Detection
↓
Safe Output

At module level:

Brake Module
↓
Degraded Mode
↓
Safe Control

At vehicle level:

Vehicle
↓
Critical Failure
↓
Restricted Operation
↓
Safe Stop

Safety can therefore be analyzed recursively.

Safety Is Not Only Crash Safety

Automotive safety is broader than collision protection.

It includes:

• Vehicle controllability
• Electrical safety
• Battery safety
• Thermal safety
• Software behavior
• Charging safety
• Diagnostic integrity
• Manufacturing quality
• Service correctness
• Human-machine interaction

Each area can be represented through objects and relations.

The same ZenOps model applies across all of them.

Human-Machine Relations Are Safety-Critical

Consider a warning.

Vehicle
   communicates
Warning
   to
Driver

The technical system may detect danger correctly.

But if the warning is confusing, delayed, or invisible, the safety mechanism may still fail.

The human-machine relation must therefore be analyzed like any other critical interface.

StoryQ might express:

Scenario: Critical thermal warning
Given a critical thermal condition has been detected
When driver action is required
Then the defined warning shall be presented
Within the required response time
And the warning shall clearly communicate the required action

The human becomes part of the safety network.

Manufacturing Safety Begins With Process Relations

A design can be safe in theory and unsafe when manufactured incorrectly.

Suppose:

Workstation
   installs
Brake Line

Safety-related manufacturing questions include:

• Can the line be incorrectly routed?
• Can the connector be partially seated?
• Can torque be insufficient?
• Can the wrong component be installed?

PFMEA identifies these risks.

Manufacturing controls then become part of the safety architecture.

Production Evidence Belongs to Safety

Suppose a critical connector must be fully engaged.

The factory may verify:

Vehicle #000142
↓
Connector #C-922
↓
Installation Verification
↓
PASS

Now the safety chain extends into production.

The vehicle does not merely inherit design safety.

It must also acquire manufacturing evidence.

Software Configuration Is Part of Safety

A physical vehicle may be mechanically correct but run the wrong software.

Therefore:

Controller
   executes
Approved Software Version

is a safety relation.

Production QT should verify software identity.

Service updates should preserve compatibility.

A mismatched software version is not simply a configuration issue.

It can become a safety issue.

Safety Traceability Should Be Bidirectional

From a hazard, we should be able to navigate downward:

Hazard
↓
Safety Requirement
↓
Safety Pattern
↓
Module
↓
Component
↓
Software
↓
Test
↓
Evidence

From a failed field component, we should be able to navigate upward:

Failed Component
↑
Safety Function
↑
Safety Requirement
↑
Hazard
↑
Human Consequence

This makes safety knowledge navigable.

Field Evidence Must Challenge Safety Assumptions

Suppose development testing predicts a failure to be extremely rare.

Field evidence later shows otherwise.

The safety model must change.

The loop becomes:

Field Event
↓
Diagnostic Analysis
↓
Failure Model Update
↓
Safety Requirement Review
↓
New Scenario
↓
Corrective Work
↓
Regression Test
↓
New Evidence

Safety is therefore not frozen at launch.

It remains connected to reality.

Safety Patterns Improve With Every Vehicle

Suppose a safe-degradation pattern is used across several vehicle platforms.

Each implementation produces:

• Test results
• Failures
• Diagnostic experience
• Service data
• Field evidence

The pattern can improve.

Safety Pattern v1
↓
Vehicle A
↓
Evidence
↓
Safety Pattern v2
↓
Vehicle B
↓
More Evidence

Safety engineering becomes cumulative knowledge.

Common-Cause Failures Must Be Visible

Network modeling is particularly valuable when several systems depend on the same object.

For example:

12V Power Supply
│
├── Sensor A
├── Controller B
├── Communication Gateway
└── Brake Support System

The components may appear independent in separate subsystem analyses.

The object network reveals a shared dependency.

A single power failure may affect all of them.

This exposes common-cause risk.

Safety Is About Controlling Propagation

A small failure is not always dangerous.

The danger often lies in propagation.

For example:

Sensor Error
↓
Incorrect Controller Decision
↓
Incorrect Actuator Command
↓
Unexpected Vehicle Motion
↓
Human Harm

Safety mechanisms attempt to break the chain.

Sensor Error
↓
Plausibility Check
↓
Error Detected
↓
Command Blocked
↓
Degraded Mode

Safety design can therefore be understood as interrupting dangerous propagation paths.

Safety Objects Can Include Hazards

Hazards themselves can become domain objects.

For example:

HAZARD-018
Unintended Propulsion
Threatens:
Occupant Safety
Pedestrian Safety
Related Objects:
Motor Controller
Accelerator Sensor
Vehicle Software
Mitigated By:
Torque Plausibility Pattern
Safe-State Pattern

Now hazards participate in the same knowledge network as requirements and tests.

The Object Network Can Become a Safety Map

Imagine selecting a hazard and seeing:

Hazard
│
├── Causes
├── Affected Objects
├── Affected Relations
├── Safety Requirements
├── Mitigations
├── Failure Modes
├── StoryQ Scenarios
├── Tests
└── Evidence

The domain model becomes a safety navigation system.

This is far more useful than isolated documents.

Safety Is a Property of the Whole Transformation

Quality failures can enter the vehicle at many stages.

A misunderstood need can create the wrong safety requirement.

A bad requirement can create the wrong architecture.

A poor architecture can create dangerous coupling.

A manufacturing defect can invalidate a safe design.

A service error can introduce a new hazard.

Therefore safety must extend through:

Need
↓
Requirement
↓
Architecture
↓
Component
↓
Software
↓
Manufacturing
↓
Vehicle
↓
Service
↓
Field Evidence

Safety is a lifecycle property.

Designing Safety Means Designing the Failure Paths

The normal engineering path asks:

How does the vehicle succeed?

Safety engineering must also ask:

How does the vehicle fail?

And then:

How does it fail safely?

That produces a more complete architecture:

Normal Operation
      ↓
Failure
      ↓
Detection
      ↓
Containment
      ↓
Degraded Operation
      ↓
Recovery / Safe Stop

The failure path is not an exception.

It is part of the design.

The Complete ZenOps Safety Loop

The full model can now be expressed as:

HUMAN NEED
      ↓
NDD
      ↓
SAFETY REQUIREMENTS
      ↓
ORIGIN
      ↓
OBJECTS + RELATIONS
      ↓
HAZARDS
      ↓
FMEA
      ↓
SAFETY PATTERNS
      ↓
MODULES + INTERFACES
      ↓
STORYQ / GHERKIN
      ↓
FAILURE INJECTION
      ↓
EVIDENCE
      ↓
SAFETY QT
      ↓
VEHICLE
      ↓
FIELD EVIDENCE
      ↓
UPDATED SAFETY MODEL

The loop continues throughout the vehicle’s life.

Safety Is Not Added at the End

A dangerous engineering pattern is:

Design the vehicle first, then ask the safety team to prove that it is safe.

ZenOps suggests the opposite.

Safety should influence:

• Needs
• Requirements
• Object relations
• Patterns
• Module boundaries
• Interfaces
• Failure modes
• Software states
• Manufacturing controls
• Test strategy

before the finished vehicle exists.

The goal is not to inspect safety into the final product.

It is to build safety into the model that creates the product.

A Safe Vehicle Is a Safe Network

The deepest conclusion is simple.

A safe component does not automatically create a safe vehicle.

A safe module does not automatically create a safe vehicle.

Even a collection of individually verified systems does not automatically create a safe vehicle.

Safety emerges from their relationships.

A sensor must report correctly.

A controller must interpret correctly.

Software must respond correctly.

An actuator must behave correctly.

A human must receive the right information.

And when one of these fails, the rest of the network must react in a controlled way.

That is why ZenOps treats safety as a property of the object network.

Safety is not merely what each object does when everything works.

Safety is what the complete network does when reality stops behaving as expected.

Design those relations deliberately.

Model their failure modes.

Test them.

Collect the evidence.

And keep learning from every vehicle that enters the real world.

That is how safety becomes part of the architecture itself.