Module 10: Automotive & Industry 4.0
MBSE in automotive (ISO 26262, AUTOSAR, SOTIF) and smart manufacturing — domain-specific adaptations and digital twins.
Prerequisite: MBSE Module 9
Automotive MBSE Landscape
The automotive industry is undergoing its most dramatic transformation in a century. Three megatrends — electrification, autonomous driving, and software-defined vehicles (SDVs) — are converging to make modern vehicles among the most complex engineered systems on Earth. This complexity is driving rapid adoption of MBSE across OEMs and Tier-1 suppliers.
The complexity explosion
A premium vehicle today may contain over 100 electronic control units (ECUs), more than 100 million lines of software code, thousands of signals flowing between subsystems, and hundreds of safety-relevant functions that must be verified against regulatory standards. By comparison, a modern commercial aircraft has roughly 15 million lines of code. The car has become a computer on wheels.
The software content of vehicles is doubling approximately every 3–4 years. A Level 4 autonomous vehicle may require over 500 million lines of code when sensor fusion, planning, and actuation software are included. Managing this complexity without model-based methods is increasingly untenable.
Why traditional approaches are breaking down
Document-based systems engineering worked when a car had a handful of ECUs with simple interactions. Today, the combinatorial explosion of interactions between software, electronics, and mechanical subsystems means that:
- Requirements documents become thousands of pages long, with cross-references that are impossible to maintain manually.
- Interface specifications between ECUs change frequently as software is updated over-the-air (OTA), invalidating static documents.
- Safety analysis (e.g. FMEA, FTA) must be repeated for every architecture change — a manual process that cannot keep pace with agile development cycles.
- Traceability from customer need to test result spans multiple organisations (OEM, Tier-1, Tier-2) and multiple tools, making end-to-end coverage analysis nearly impossible.
MBSE addresses these challenges by replacing static documents with a single source of truth — a structured, queryable system model that keeps architecture, requirements, safety analysis, and test coverage in sync.
Standards and Frameworks
The automotive domain has developed a rich ecosystem of standards that govern how systems must be designed, verified, and certified. MBSE does not replace these standards — it provides a structured way to implement them consistently and traceably.
ISO 26262 — Functional Safety
ISO 26262 is the international standard for functional safety of road vehicles. It defines the Automotive Safety Integrity Level (ASIL) classification — from ASIL A (lowest) to ASIL D (highest) — which determines the rigour of development and verification activities. MBSE supports ISO 26262 by:
- Enabling ASIL decomposition directly in the architecture model — allocating safety requirements to redundant subsystems.
- Maintaining traceable links from hazards, through safety goals, functional safety requirements, and technical safety requirements, down to design elements and test cases.
- Automating safety case construction by generating argument structures (e.g. GSN) from model relationships.
AUTOSAR — Software Architecture
AUTOSAR (AUTomotive Open System ARchitecture) standardises the software architecture for ECUs. AUTOSAR Classic provides a layered architecture for deeply embedded real-time systems, while AUTOSAR Adaptive supports high-performance computing platforms for autonomous driving. MBSE models can be mapped to AUTOSAR component definitions, enabling automatic code generation and configuration.
SOTIF / ISO 21448 — Safety of the Intended Functionality
ISO 21448 (SOTIF) addresses a different safety concern: situations where the system functions as designed but still creates hazards due to limitations in sensors, algorithms, or operational conditions. This is critical for autonomous vehicles, where a radar sensor may fail to detect a stationary object in certain weather conditions. MBSE helps by modelling the Operational Design Domain (ODD) and triggering conditions systematically.
EAST-ADL — Architecture Description Language
EAST-ADL is a domain-specific architecture description language for automotive systems. It provides abstraction layers (vehicle, analysis, design, implementation) that map naturally to MBSE practices. EAST-ADL models can be integrated with SysML and AUTOSAR models to bridge the gap between systems engineering and software engineering.
| Standard | Focus | How MBSE Helps |
|---|---|---|
| ISO 26262 | Functional safety (ASIL A–D) | Traceable safety decomposition; automated safety case generation; impact analysis when architecture changes |
| AUTOSAR | Software architecture (Classic & Adaptive) | Map system-level functions to AUTOSAR SW components; generate configuration files from models |
| ISO 21448 (SOTIF) | Safety of intended functionality | Systematic ODD modelling; triggering-condition analysis; scenario coverage tracking |
| EAST-ADL | Architecture description language | Multi-level architecture views aligned with MBSE abstraction layers; bridges SysML and AUTOSAR |
When starting MBSE adoption in an automotive organisation, begin with ISO 26262 traceability — it is the area where auditors already demand structured evidence. Building your system model around safety cases gives you an immediate, auditable return on investment.
MBSE for Autonomous Systems
Autonomous driving pushes the boundaries of systems engineering. The system must perceive the world, make decisions, and act — all within milliseconds, across an essentially infinite variety of driving scenarios. MBSE provides the rigour needed to define, bound, and verify what the autonomous system should and should not do.
Operational Design Domain (ODD) modelling
The ODD defines the specific conditions under which an automated driving system is designed to function. This includes road types, speed ranges, weather conditions, time of day, geographic boundaries, and traffic density. Modelling the ODD explicitly in a system model ensures that every stakeholder shares a precise, unambiguous understanding of the system's operational envelope.
Example — Level 3 Highway Autopilot ODD:
- Road type: Divided highway with at least two lanes per direction, clear lane markings.
- Speed range: 0–130 km/h (active above 0 km/h in traffic jam assist, up to 130 km/h in highway assist).
- Weather conditions: Dry or light rain; not active in heavy rain, snow, fog (visibility < 100 m), or icy roads.
- Time of day: All hours, provided lane markings are detectable.
- Geographic scope: Mapped highway segments with HD map coverage.
Think of a driving instructor assigning routes to a learner driver. The instructor does not say "drive anywhere you like." Instead, they carefully define where the learner is allowed to drive: "residential streets only, speed limit 50, daylight hours, dry weather, no motorways." The ODD is exactly this — a formal definition of where and when the autonomous system is allowed to operate. As the system proves its competence, the ODD can be expanded, just as the instructor gradually allows highway driving.
Scenario-based testing
Autonomous systems cannot be validated by driving billions of kilometres on public roads alone. Instead, engineers define scenarios — abstract descriptions of situations the system must handle (e.g. "cut-in by another vehicle at highway speed"). MBSE enables:
- Scenario catalogues linked to ODD parameters, ensuring complete coverage.
- Parametric variations (speed, distance, angle) generated from model constraints.
- Traceability from each scenario to the safety requirements it validates.
Sensor and actuator architecture modelling
An autonomous vehicle typically combines cameras, LiDAR, radar, ultrasonic sensors, and GNSS receivers. MBSE models capture the sensor layout, field-of-view coverage, fusion architecture, and degradation modes. This allows engineers to analyse whether the sensor suite provides sufficient redundancy and coverage for every ODD condition before committing to hardware.
Industry 4.0 and Digital Twins
Industry 4.0 treats the factory as a system. Just as MBSE models the architecture of a vehicle, it can model an entire production line — robots, conveyors, inspection stations, human operators, and the control logic that orchestrates them. The goals are the same: manage complexity, ensure safety, enable change.
MBSE for production line design
A modern automotive assembly plant is a cyber-physical system (CPS): physical machines are tightly coupled with software controllers, network infrastructure, and data analytics. MBSE helps by:
- Modelling the physical layout (stations, conveyors, buffers) as a system architecture.
- Defining interfaces between robots, PLCs, MES (Manufacturing Execution Systems), and ERP systems.
- Specifying timing and throughput requirements as constraints that can be simulated.
- Capturing safety zones and human-robot collaboration boundaries.
From engineering model to digital twin
A digital twin is a runtime replica of a physical asset or process, continuously updated with sensor data. The connection to MBSE is direct: the engineering model created during design becomes the blueprint for the digital twin used during operations.
- Design-time model (MBSE): Defines structure, behaviour, requirements, and constraints of the production line.
- Runtime digital twin: Instantiates the model with live data — actual cycle times, sensor readings, fault states — enabling monitoring, prediction, and optimisation.
Think of the MBSE model as the blueprint and the digital twin as the living building. The blueprint defines what should be built; the digital twin reflects what is actually happening. When discrepancies arise — for example, a robot arm taking longer than its modelled cycle time — the digital twin flags it, and engineers refer back to the MBSE model to diagnose the root cause and plan corrections.
Example: smart factory assembly line
Consider a battery-pack assembly line for electric vehicles:
- Station 1 — Cell sorting: Incoming cells are tested and sorted by capacity and internal resistance. A robot picks and places cells into module trays.
- Station 2 — Module assembly: Cells are welded into modules. A vision system inspects weld quality in real time.
- Station 3 — Pack integration: Modules are mounted into the battery housing with thermal interface material applied by a dispensing robot.
- Station 4 — End-of-line test: The assembled pack undergoes electrical testing, leak testing, and functional verification.
An MBSE model of this line would define each station as a subsystem with ports (material in, material out, control signals, quality data), behavioural models (cycle time, failure modes), and requirements (throughput, yield, safety). The digital twin would mirror this structure, populating it with live sensor data to track OEE (Overall Equipment Effectiveness) in real time.
Cross-Domain Patterns
Automotive and manufacturing may seem domain-specific, but many of the MBSE patterns used here are shared with aerospace, medical devices, rail, and energy. Recognising these patterns helps organisations build reusable MBSE frameworks rather than starting from scratch in each domain.
Shared patterns across domains
- Safety analysis integration: Whether it is ISO 26262 (automotive), ARP4754A (aerospace), or IEC 62278 (rail), the pattern is the same — link hazards to safety requirements, decompose them through the architecture, and trace to verification evidence.
- Architecture trade-offs: Centralised vs. distributed computing, redundancy strategies, power/weight/cost optimisation — these trade-off patterns recur in every safety-critical domain.
- Lifecycle management: From concept through design, production, operation, and decommissioning, the need for a model that evolves with the system is universal.
- Supplier integration: Multi-tier supply chains require shared interface models and contract-based design — a pattern common to automotive, aerospace, and defence.
The trend in the MBSE community is toward domain-agnostic toolchains. Tools like SysML v2, Capella, and MBSE frameworks built on Eclipse are designed to work across industries. Domain-specific content (safety standards, architecture patterns, library components) is layered on top of a shared modelling foundation. This means skills and methods learned in one domain transfer readily to another.
The convergence ahead
As vehicles become software-defined and factories become cyber-physical, the boundary between "product engineering" and "production engineering" is blurring. MBSE is the common language that spans both — from the vehicle system model to the factory digital twin, from design-time analysis to runtime monitoring. Organisations that invest in MBSE capabilities now are building a foundation that will serve them across domains and across the product lifecycle.