The Car as Objects and Relations — Applying ORIGIN
At this point in the ZenOps automotive process, we have deliberately avoided designing the car too early.
We began with x — the problem existing in reality.
We transformed customer wishes into explicit needs.
We structured those needs through the Need Definition Document (NDD).
We separated needs from proposed solutions.
Now we can begin asking a different question:
What actually exists in the system, and how does everything relate?
This is where ORIGIN enters the automotive process.
The fundamental idea is remarkably simple:
Thinking → Objects
Feeling → Relations
An automobile can therefore be understood as a network of objects and relations.
Not merely as a collection of parts.
Not merely as a Bill of Materials.
Not merely as a hierarchy of engineering departments.
But as a system in which objects acquire meaning through their relationships with other objects.
The Car Is Not a Pile of Components
Imagine taking a vehicle completely apart.
We place the wheels in one area.
The battery in another.
Seats somewhere else.
Controllers on a table.
Motors on the floor.
Sensors in boxes.
Thousands of mechanical and electrical components are carefully catalogued.
Do we still have a car?
Physically, perhaps we possess everything required to construct one.
Functionally, we do not.
A motor sitting on the floor does not transport anyone.
A battery sitting beside it does not provide useful propulsion.
A wheel lying nearby does not create mobility.
The vehicle emerges when these objects are connected through the correct relations.
Battery │ supplies energy to ↓Motor │ produces torque for ↓Drivetrain │ transfers torque to ↓Wheel │ interacts with ↓Road
The functionality exists in the network.
This is the ORIGIN perspective.
Begin With Objects
Consider a simplified automobile.
We might identify objects such as:
VehicleDriverPassengerCargoBodyDoorWindowSeatWheelBatteryMotorInverterChargerSteering SystemBrake SystemSuspensionCameraRadarTemperature SensorWheel-Speed SensorControllerSoftwareRoadCharging StationService CenterEnvironment
Immediately something interesting happens.
Not every important object is physically part of the vehicle.
Driver is an object.
Road is an object.
Charging Station is an object.
Environment can be modeled as an object.
Service Center can be an object.
The system boundary begins to expand.
That matters because a vehicle does not operate in isolation.
Then Discover Relations
Objects alone tell us very little.
We therefore ask:
How is this object related to other objects?
For example:
Driver operatesVehicleVehicle transportsPassengerVehicle carriesCargoBattery suppliesInverterInverter controls energy toMotorMotor drivesWheelWheel interacts withRoadBrake System deceleratesWheelSteering System changes direction ofWheel
Now behavior begins to emerge.
The system becomes understandable not because we discovered more nouns, but because we discovered the relationships between them.
Relations Give Objects Meaning
Consider a battery.
By itself:
Battery
tells us almost nothing about its purpose.
Add relations:
Battery storesEnergyBattery suppliesInverterBattery receives energy fromChargerBattery reports state toBattery Management SystemThermal System regulates temperature ofBattery
Now the battery has context.
Its meaning emerges through its relations.
This is true throughout the automobile.
A sensor has little meaning until we know:
what it observes,
who receives its information,
and:
what decisions depend upon it.
From Hierarchy to Network
Traditional decomposition often produces a hierarchy:
Vehicle│├── Body├── Chassis├── Powertrain├── Electrical System├── Interior└── Software
This is useful.
But the actual automobile does not behave as a hierarchy.
Suppose the driver presses the accelerator.
The resulting behavior may involve:
Driver ↓Accelerator ↓Sensor ↓Controller ↓Software ↓Power Electronics ↓Motor ↓Drivetrain ↓Wheel ↓Road
At the same time, other objects may participate:
BatteryTraction ControlWheel-Speed SensorsThermal SystemStability ControlInstrument Display
The real system is therefore a network.
The hierarchy tells us where things belong.
The network tells us how things work together.
Connect ORIGIN Back to the NDD
ORIGIN should not appear independently from the needs discovered earlier.
Suppose the NDD contains:
Maintain vehicle control on low-friction surfaces.
We can now ask:
Which objects participate in satisfying this need?
The answer might include:
DriverTireWheelRoadWheel-Speed SensorBrakeMotorSteering SystemControllerSoftware
Then we identify their relations.
Wheel-Speed Sensor observesWheelWheel interacts withRoadController receives data fromWheel-Speed SensorSoftware evaluatesWheel BehaviorController commandsMotorController commandsBrake
The original human need has begun transforming into a system model.
ORIGIN Prevents Component Isolation
Consider a braking problem.
A traditional component-oriented discussion might ask:
Is the brake functioning correctly?
ORIGIN encourages a broader question:
Which object relations must function correctly for the vehicle to decelerate as intended?
The answer could involve:
Driver → Brake Pedal
Brake Pedal → Sensor
Sensor → Controller
Controller → Brake Actuator
Brake → Wheel
Wheel → Tire
Tire → Road
Suddenly the road surface matters.
Tire condition matters.
Software matters.
Sensor accuracy matters.
Driver input matters.
The braking system is no longer merely a mechanical component.
It is a network of cooperating objects.
Model Information as Relations
Modern vehicles are increasingly information systems.
A camera produces observations.
Sensors generate measurements.
Controllers exchange messages.
Software creates decisions.
Displays communicate information to humans.
ORIGIN can represent these relationships explicitly.
Camera observesEnvironmentCamera sends data toControllerController executesSoftwareSoftware identifiesHazardController requests action fromBrake SystemBrake System changes motion ofVehicle
This creates a continuous chain:
Physical Reality → Observation → Information → Decision → Physical Action
That pattern appears repeatedly in modern automobiles.
The Driver Is Part of the System
One of the most important consequences of the ORIGIN perspective is that the human does not sit outside the model.
Consider:
Vehicle communicates speed toDriverDriver observesRoadDriver commandsSteering SystemDriver commandsBrake SystemDriver commandsPropulsion System
Now consider an assisted-driving system:
Camera observesRoadController interpretsCamera DataVehicle communicates warning toDriverDriver responds toWarning
The human-machine relationship becomes explicit.
This can reveal problems that a component hierarchy may hide.
A warning can be technically correct yet practically useless if the driver cannot understand it in time.
The relation matters.
The Environment Is Part of the Model
The vehicle also interacts continuously with its environment.
For example:
Snow reduces friction betweenTire and RoadTemperature affectsBatteryRain affectsCameraRoad Salt affectsBodySunlight affectsCabin Temperature
The environment is not merely a test condition added at the end.
It participates in the object network from the beginning.
This connects directly back to x.
If the vehicle exists to provide transportation in Norwegian winter conditions, winter is not an edge case.
Winter is part of the problem definition.
Relations Can Cross Engineering Disciplines
This is where ORIGIN becomes particularly useful for complex engineering organizations.
Consider the relation:
Temperature affects Battery.
Understanding and controlling that relation might involve:
- Battery engineering
- Electrical engineering
- Mechanical engineering
- Thermal engineering
- Software engineering
- Safety engineering
- Manufacturing
- Testing
The physical relationship does not care how the company organizational chart is structured.
Reality crosses departments.
The ORIGIN model should therefore describe the system according to the relationships that actually exist, not according to administrative boundaries.
Relations Can Become Interfaces
As the model becomes more detailed, many relations become engineering interfaces.
For example:
Controller communicates withInverter
Eventually this relation may need to specify:
- Communication protocol
- Message structure
- Timing
- Error behavior
- State transitions
- Electrical interface
- Failure handling
Likewise:
Motor connects toDrivetrain
may eventually become:
- Mechanical interface
- Torque limits
- Speed limits
- Mounting geometry
- Thermal constraints
- Vibration constraints
The conceptual relation discovered in ORIGIN gradually becomes a precise engineering contract.
Objects Can Be Physical or Logical
Not every object needs to be physical.
An automotive ORIGIN model may contain:
Physical objects
Battery, wheel, door, motor, sensor.
Human objects
Driver, passenger, technician.
Environmental objects
Road, snow, temperature, charging infrastructure.
Information objects
Vehicle state, diagnostic event, sensor measurement.
Software objects
Control algorithm, software service, state machine.
Organizational objects
Supplier, factory, service center.
This allows the model to extend beyond the mechanical automobile.
It can eventually describe the complete lifecycle of the vehicle.
The Factory Can Use the Same Model
The same principle can be applied to manufacturing.
Consider:
Supplier providesComponentRobot installsComponentOperator supervisesWorkstationWorkstation performsManufacturing OperationInspection System verifiesAssemblyVehicle passes throughProduction Line
Again we have objects and relations.
The conceptual machinery used to model the vehicle can therefore also model the factory that produces it.
This is important for ZenOps.
The transformation does not stop at engineering.
It continues into physical production.
Service Can Use the Same Model
Now move beyond manufacturing.
Vehicle generatesDiagnostic EventDiagnostic Event identifiesAffected SystemTechnician investigatesDiagnostic EventService Center replacesComponentReplacement updatesVehicle Configuration
The same object network can continue through the operational lifetime of the vehicle.
Design, manufacturing, operation and service no longer need to exist as disconnected information worlds.
From Object Network to Traceability
Now imagine that every object and relation has an identity.
A motor is not merely “motor.”
It is a specific engineering object.
A requirement can reference it.
A test can reference it.
A manufacturing operation can reference it.
A physical component can reference it.
A diagnostic event can reference it.
The chain might become:
Human Need ↓NDD Node ↓Requirement ↓ORIGIN Objects + Relations ↓Architecture ↓Engineering Objects ↓Manufacturing ↓Physical Vehicle ↓Diagnostic Evidence
The vehicle becomes traceable from human purpose to physical reality.
ORIGIN Exposes Missing Relations
One of the most useful properties of an object-and-relation model is that omissions become easier to see.
Suppose we have:
SensorControllerBrake
But no explicit relation connecting the sensor to the controller.
Something is missing.
Or perhaps:
BatteryMotor
exists, but thermal management has no relationship with the battery.
Again, the model exposes a question.
This does not mean every missing relation represents a design defect.
It means the model gives us a systematic way to ask:
What must interact for this need to become true?
From Objects and Relations to Patterns
Once enough automotive systems have been modeled, recurring structures begin to appear.
For example:
Sensor ↓Controller ↓Decision ↓Actuator
The specific objects may change.
Camera → Controller → Brake
Temperature Sensor → Controller → Cooling System
Wheel-Speed Sensor → Controller → Motor
But the structure repeats.
That recurring structure is a pattern.
This is the next major step in ZenOps.
Instead of solving every automotive problem as though it were completely new, we begin identifying reusable structures of objects and relations.
The Car Becomes a Living Network
The ORIGIN perspective changes how we see the automobile.
A vehicle is no longer merely:
10,000+ components assembled into one product.
It becomes:
a network of objects whose relationships collectively produce behavior.
The battery matters because of what it stores, supplies, receives and communicates.
The wheel matters because of how it interacts with the drivetrain, brake, tire, road and vehicle structure.
The sensor matters because something observes reality, something receives the observation, and something acts upon it.
The driver matters because the entire system ultimately exists in relation to human activity.
This gives us a deeper representation of the automobile:
Objects are what exist.
Relations describe how existence becomes a system.
And from those relationships, the behavior we call the car emerges.
From Need to Network
The ZenOps automotive chain has now progressed significantly:
Reality ↓x ↓Customer Wishes ↓NDD ↓Engineering Requirements ↓ORIGIN ↓Objects +Relations ↓Object Network
We started with:
What problem must be solved?
Now we are asking:
What must exist and interact for the solution to work?
The next question follows naturally:
Which of these object-and-relation structures occur again and again?
That takes us from ORIGIN into patterns.
And patterns are where individual engineering experience begins turning into reusable engineering knowledge.
