Building the Complete Automotive Domain Model
A car is easy to recognize.
Defining everything that belongs to the domain of a car is considerably harder.
Is the driver part of the automotive domain?
Certainly.
What about the road?
The charging station?
The factory robot that installed the battery?
The supplier that manufactured the brake controller?
The diagnostic event generated seven years after the vehicle left the factory?
The software version installed during a service visit?
The crash-test result that justified releasing the vehicle for production?
If our objective is simply to draw the mechanical structure of an automobile, most of these things can remain outside the model.
But ZenOps has a larger objective.
We want to maintain a traceable transformation:
Human Need → Model → Engineering → Manufacturing → Vehicle → Operation → Evidence
That requires something larger than a component diagram.
It requires a complete automotive domain model.
From ORIGIN to Domain Model
In the previous step, ORIGIN gave us two fundamental concepts:
Objects
and:
Relations
We might model:
Battery suppliesMotorDriver operatesVehicleWheel interacts withRoad
This provides the conceptual foundation.
But a production automotive system contains thousands of object types and an enormous number of relations.
The next task is therefore to organize them into a coherent domain.
A simplified first view might be:
Automotive Domain│├── Human├── Vehicle├── Environment├── Infrastructure├── Engineering├── Manufacturing├── Supply├── Operation├── Service└── Evidence
This is no longer merely a model of the car.
It is a model of the world in which the car is conceived, created, operated and evaluated.
1. The Human Domain
ZenOps began with human need, so humans must remain visible throughout the model.
Possible objects include:
Person│├── Customer├── Driver├── Passenger├── Pedestrian├── Cyclist├── Technician├── Engineer├── Factory Operator└── Emergency Responder
These objects participate in different relations.
Customer ownsVehicleDriver operatesVehicleVehicle transportsPassengerVehicle interacts withPedestrianTechnician servicesVehicleEngineer designsComponentOperator performsManufacturing Operation
The automobile is therefore not modeled independently from people.
People are part of the domain because the vehicle exists in relation to them.
2. The Vehicle Domain
Now we enter the product itself.
At the highest level:
Vehicle│├── Body├── Chassis├── Propulsion├── Energy├── Steering├── Braking├── Suspension├── Thermal Management├── Electrical System├── Electronic Systems├── Software├── Interior├── Safety Systems└── Human-Machine Interface
Each branch can be decomposed further.
For an electric energy system:
Energy System│├── Battery Pack│ ├── Battery Module│ │ └── Battery Cell│ ├── Battery Management System│ ├── Contactors│ ├── Sensors│ └── Housing│├── High-Voltage Distribution├── Charging System├── DC/DC Conversion└── Thermal Management
The domain model can continue until it reaches the level of detail required by engineering.
3. The Software Domain
A modern automobile is also a software system.
Therefore software should not be treated merely as an invisible property of electronic hardware.
It can be modeled explicitly:
Vehicle Software│├── Control Software├── Diagnostic Software├── Safety Software├── Infotainment Software├── Communication Software├── Energy Management├── Driver Assistance└── Human-Machine Interface
Relations then connect software to physical reality.
Sensor producesMeasurementSoftware readsMeasurementSoftware producesCommandController executesCommandActuator changesPhysical State
Now cyber and physical behavior exist inside the same conceptual model.
4. The Environment Domain
A vehicle operates inside an environment that continuously affects its behavior.
Relevant environmental objects might include:
Environment│├── Road├── Traffic├── Weather├── Temperature├── Rain├── Snow├── Ice├── Wind├── Sunlight└── Road Contaminants
Relations include:
Snow affectsRoad FrictionTemperature affectsBattery PerformanceRain affectsSensor VisibilityRoad Salt affectsMaterial CorrosionRoad applies forces toTire
The environment is not an afterthought.
It participates directly in vehicle behavior.
5. The Infrastructure Domain
Vehicles also depend upon infrastructure.
Infrastructure│├── Road Network├── Bridge├── Tunnel├── Parking Facility├── Fuel Station├── Charging Station├── Electrical Grid├── Communication Network└── Navigation Infrastructure
For an electric vehicle:
Vehicle connects toCharging StationCharging Station receives energy fromElectrical GridCharging Station supplies energy toVehicleVehicle communicates withCharging Station
This reveals an important point.
Some vehicle functionality exists only through interaction with external systems.
The effective automotive system can therefore extend far beyond the physical boundary of the automobile.
6. The Engineering Domain
We also need to represent the knowledge used to create the vehicle.
Possible engineering objects include:
NeedRequirementPatternArchitectureSystemComponent DefinitionInterfaceCAD ModelSoftware ModuleSimulationTest SpecificationTest ResultEngineering Change
Now traceability becomes possible:
Need producesRequirementRequirement constrainsSystemSystem containsComponent DefinitionComponent Definition implemented byPhysical ComponentRequirement verified byTestTest producesTest Result
The engineering model and physical vehicle begin to connect.
7. The Manufacturing Domain
A vehicle architecture cannot become a commercial product until it can be manufactured repeatedly.
The manufacturing domain might contain:
Factory│├── Production Line│ ├── Workstation│ ├── Robot│ ├── Tool│ ├── Operator│ └── Inspection Station│├── Material├── Component├── Manufacturing Operation├── Assembly├── Calibration└── Quality Inspection
Relations might include:
Production Line containsWorkstationRobot performsManufacturing OperationManufacturing Operation installsComponentComponent becomes part ofVehicleInspection Station verifiesAssembly
The factory is therefore another object network.
The same conceptual approach used for the car works for the system that builds the car.
8. The Supplier Domain
Automotive manufacturing depends on large supplier networks.
We can model:
Supplier│├── Facility├── Component├── Material├── Process├── Certification└── Delivery
Relations might include:
Supplier manufacturesComponentSupplier shipsComponentFactory receivesComponentComponent satisfiesComponent SpecificationComponent installed inVehicle
Now supplier quality can connect directly to vehicle configuration.
If a component fails in the field, the model can potentially trace backward:
Field Failure ↓Physical Component ↓Production Batch ↓Supplier ↓Manufacturing Process
The domain model begins turning into a powerful traceability structure.
9. The Individual Vehicle
There is an important distinction between:
Vehicle Type
and:
Physical Vehicle Instance.
Engineering may define:
Vehicle Model
but manufacturing produces:
Vehicle #000001Vehicle #000002Vehicle #000003...
Each physical vehicle can possess its own identity.
For example:
Vehicle Instance│├── Identity├── Configuration├── Installed Components├── Software Versions├── Manufacturing History├── Test Results├── Service History└── Diagnostic History
This changes the domain model significantly.
We are no longer modeling only what a vehicle should be.
We can model what a specific vehicle actually is.
10. Configuration Becomes Explicit
Suppose Vehicle A contains:
Battery Pack #B39184Motor #M77120Brake Controller #BC912Software Version 4.17
while Vehicle B contains:
Battery Pack #B39201Motor #M77204Brake Controller #BC945Software Version 4.18
These vehicles belong to the same model range but are not informationally identical.
If a field problem appears only in vehicles containing a particular component batch and software version, the domain model can expose the relationship.
This is far more powerful than treating all vehicles of the same model as interchangeable records.
11. The Service Domain
Manufacturing is not the end of the vehicle lifecycle.
The service domain might contain:
Service CenterTechnicianService VisitDiagnostic EventFaultRepairReplacement ComponentSoftware UpdateInspectionMaintenance Operation
Relations could include:
Vehicle generatesDiagnostic EventTechnician investigatesDiagnostic EventDiagnostic Event indicatesFaultTechnician performsRepairRepair replacesComponentService Visit updatesVehicle History
The vehicle’s domain model continues evolving throughout its operational life.
12. Evidence Is Part of the Domain
ZenOps ultimately cares about evidence.
Engineering says:
We believe this design satisfies the need.
Reality must answer.
Evidence objects might include:
Simulation ResultTest ResultInspection ResultManufacturing MeasurementDiagnostic EventWarranty ClaimService RecordCustomer ReportField FailureCrash DataReliability Data
Now we can create relations such as:
Requirement verified byTestTest producesTest ResultTest Result provides evidence forRequirementField Failure challengesEngineering Assumption
Evidence is no longer buried in disconnected documents.
It becomes part of the domain itself.
13. Build the Traceability Chain
Now the complete model begins to reveal its real purpose.
Imagine a customer need:
“I need reliable transportation during winter.”
That might become:
Human Need ↓NDD-020Operate During Winter ↓REQ-247Cold-Temperature Operational Requirement ↓Thermal Architecture ↓Battery Thermal System ↓Heating Component ↓Supplier Component Definition ↓Physical Component #H7811 ↓Vehicle #000142 ↓Winter Test ↓Test Result ↓Field Evidence
We can move from human reality all the way to a physical component inside a particular vehicle.
And potentially back again.
That is far more than documentation.
It is a knowledge network.
14. The Domain Model Is Not the Organizational Chart
A critical principle follows.
Do not divide the domain simply because the company is divided.
Reality does not care whether one department owns braking and another owns software.
Consider emergency braking:
Environment ↓Camera ↓Perception Software ↓Decision Software ↓Controller ↓Brake Actuator ↓Wheel ↓Tire ↓Road
This chain may cross multiple departments, suppliers and engineering disciplines.
The domain model should preserve the real system relationship.
Organizational responsibility can then be attached to it.
The organization should map onto reality.
Reality should not be forced into the organization chart.
15. The Domain Model Is Not the Database
Another distinction is equally important.
The domain model describes meaning.
A database describes storage.
We may later persist the domain as tables, documents, serialized objects, graph structures, BLOBs or an object-network database.
Those are implementation choices.
The conceptual model should first answer:
What objects exist?
What do they mean?
How are they related?
Only then should we ask:
How should they be stored?
This preserves the same principle we used earlier:
Need before solution.
16. Give Everything Identity
For a complete digital automotive domain, identity becomes essential.
Important objects can receive persistent identities:
Need IDRequirement IDPattern IDSystem IDComponent Definition IDSoftware IDSupplier IDManufacturing Operation IDPhysical Component IDVehicle IDTest IDDiagnostic Event IDService Event ID
Relations can then reference identities rather than relying only on document position or human interpretation.
The domain becomes navigable.
From a failed component, we can find the vehicle.
From the vehicle, the manufacturing operation.
From the operation, the component specification.
From the specification, the requirement.
From the requirement, the need.
This is the foundation of end-to-end traceability.
17. The Model Can Grow Without Losing Its Foundation
The complete automotive domain will be enormous.
That is not necessarily a problem.
The objective is not to place everything on one diagram.
The objective is to establish a consistent conceptual foundation:
Objects
Relations
Identity
Traceability
Evidence
Different views can then expose different parts of the same underlying model.
A customer view might show needs.
An engineer might see systems and requirements.
A manufacturing engineer might see operations and components.
A technician might see diagnostics and service history.
Management might see Quality Threshold status.
Different views.
Same domain.
18. From Digital Thread to Living Model
The automotive industry often speaks about a digital thread connecting information across the product lifecycle.
ZenOps pushes this idea toward something even more explicit.
Instead of merely connecting documents produced by different stages, we can attempt to maintain a persistent domain model whose objects survive the transitions between those stages.
A requirement does not disappear when engineering begins.
A component definition does not disappear when manufacturing begins.
A vehicle does not become disconnected from its engineering definition when it leaves the factory.
Field evidence does not remain isolated from the need that originally justified the system.
The domain persists.
19. The Complete Automotive Object Network
At the highest level, we can now imagine:
HUMAN NEED
│
↓
NDD
│
↓
REQUIREMENTS
│
↓
ORIGIN
Objects + Relations
│
↓
PATTERNS
│
↓
ARCHITECTURE
│
↓
ENGINEERING
│
┌───────────┴───────────┐
↓ ↓
SOFTWARE HARDWARE
│ │
└───────────┬───────────┘
↓
SUPPLIERS
│
↓
MANUFACTURING
│
↓
VEHICLE INSTANCE
│
↓
OPERATION
│
┌────────┴────────┐
↓ ↓
SERVICE DIAGNOSTICS
│ │
└────────┬────────┘
↓
EVIDENCE
│
↓
LEARNING
│
└────────────→ NDD
Now the automobile is no longer merely a manufactured object.
It is one physical manifestation of a much larger knowledge structure.
The Car Becomes a Domain
We began this series by asking:
What problem is the car actually supposed to solve?
That gave us x.
We decomposed x through the NDD.
We transformed needs into requirements.
ORIGIN gave us objects and relations.
Now those objects and relations have expanded beyond the physical boundaries of the automobile.
The complete domain contains:
the human who needs the vehicle,
the engineers who define it,
the systems that constitute it,
the suppliers that contribute to it,
the factory that creates it,
the environment in which it operates,
the infrastructure upon which it depends,
the technicians who maintain it,
and:
the evidence that tells us whether it actually works.
This is the complete automotive domain model.
Not merely:
What is the car made of?
But:
What entire network of objects and relations must exist for a human need to become a functioning vehicle — and for reality to tell us whether we succeeded?
Once that model exists, automotive development can become something more than a sequence of disconnected engineering phases.
It can become a continuous transformation of knowledge:
from need, to model, to machine, to evidence, and back to knowledge again.
