The problem
Software-defined vehicles aim to add and update features without rewiring or reflashing many ECUs. That depends on a service-oriented architecture where functions are split into services with stable interfaces. Students often hear the term without designing one. This project takes one concrete feature, decomposes it into services, implements them and measures what changes when the feature is modified.
Objectives
- Decompose a vehicle feature into services with defined responsibilities and interfaces.
- Specify service interfaces with versions, data types and timing.
- Implement the services in C++ on Linux using a lightweight messaging layer.
- Implement a signal-based monolithic version as a baseline.
- Compare coupling and change effort for a feature update in both designs.
What you need
Tools and toolboxes
- C++ with CMake — Implements each service as a separate Linux process.
- vsomeip (COVESA) — SOME/IP middleware for service offering, discovery and events between processes.
- Linux with systemd — Starts, stops and restarts services independently to test deployment and updates.
- Wireshark — Observes service traffic to confirm which services talk to which.
- Python — Simulates vehicle inputs such as speed, door state and ambient light, and analyses logs.
Software
- Ubuntu Linux
- C++ toolchain with CMake
- vsomeip
- systemd
- Python
- A diagramming tool for architecture views
Extra parts and data
None beyond the software above.
Key concepts
- Service-oriented architecture
- A design where functions are offered as services with published interfaces and consumers depend only on the interface, not on where or how the service is implemented.
- Interface versioning
- Each interface carries a major and minor version. Minor changes add optional content and stay compatible; major changes break compatibility and need consumers to be updated.
- Coupling
- How much one component depends on details of another. Lower coupling means a change in one part touches fewer other parts.
- Software-defined vehicle
- A vehicle whose features are mainly defined in software running on central or zonal computers, so features can be updated or added after sale.
Step-by-step guide
- 1
Specify the feature
Write user-level requirements for the lighting feature: when the driver unlocks the car in low ambient light, the exterior lamps turn on for a set time; after locking, they stay on for a departure period; they never activate above a walking-speed threshold. Add a planned future change, for example a new animation pattern for a new market. Keep requirements numbered and testable, with times and thresholds stated.
Checkpoint: A numbered requirement list with thresholds and a written description of the future change.
- 2
Decompose into services
Identify services: VehicleState (speed, lock state, door state), AmbientLight (light level), LightingPolicy (decides when lighting is wanted) and LampActuator (drives the lamp outputs). Draw a service diagram showing who provides and who consumes each interface. Assign each service one responsibility and justify the cut. Note which services might later be reused by other features, such as VehicleState. Mark which data each service owns, so no two services publish the same information and confuse consumers.
Checkpoint: A service diagram and a responsibility table, reviewed for single responsibility.
- 3
Write interface specifications
For each service define methods, events and fields with data types, units, update rates and a version number. For example VehicleState publishes a LockState event on change and a Speed event at 10 Hz in km/h. Specify the behaviour when data is missing or stale, such as LightingPolicy switching lamps off if VehicleState is silent for 500 ms. Record service and event IDs for the middleware.
Checkpoint: One interface sheet per service with IDs, types, rates, versions and stale-data behaviour.
- 4
Implement the input simulator
Write a Python or C++ simulator that provides VehicleState and AmbientLight from a scripted scenario file: approach, unlock, door open, door close, drive away, park, lock and walk away, at various light levels. Make the scenario file readable and versioned, so tests are repeatable. The simulator offers its services through the same middleware as real services would. Include edge cases in the scenarios, such as unlocking while the car is still rolling slowly, so the speed threshold is exercised.
Checkpoint: The simulator publishes scenario-driven events that a test subscriber receives with correct values.
- 5
Implement the services
Write LightingPolicy as a C++ process using vsomeip that subscribes to VehicleState and AmbientLight and implements the requirements as a small state machine with timers. Write LampActuator to receive lamp commands and log or display lamp state. Keep each service in its own repository folder with its own build and configuration. Run each as a systemd unit so they can be started and restarted separately.
Checkpoint: All four services run as separate processes and the lamps follow the scenario correctly in the log.
- 6
Build the signal-based baseline
Write a single program that reads the same simulated signals from a shared signal list, with all logic and actuation in one place, mimicking a traditional ECU design. Use the same requirements and scenarios. This baseline is not wrong; it is simpler to start. It gives a fair comparison for change effort and coupling. Keep its code quality similar to the service version so the comparison is not biased.
Checkpoint: The baseline passes the same scenarios with the same lamp timings as the service version.
- 7
Test against the requirements
Write automated scenario tests that replay each scenario and check lamp on and off times against requirements, with tolerance. Add fault tests: stop VehicleState mid-scenario and check the stale-data behaviour, and restart LightingPolicy while lamps are on. Record pass or fail for each requirement in both designs. Use Wireshark once to confirm that only the intended services exchange messages. Keep the test scripts independent of either design, so the same file verifies both.
Checkpoint: A requirement traceability table with pass results for both designs, including fault cases.
- 8
Apply the planned change
Implement the future change in both designs: a new animation pattern selected by a market parameter. Count files touched, lines changed, components rebuilt and components redeployed in each design. In the service design, aim to change only LightingPolicy and LampActuator and bump only their minor interface versions. Record anything that forced a wider change, because that reveals hidden coupling. Measure the effort in hours as well, and note how long the rebuilt services took to retest.
Checkpoint: A change-impact table comparing touched files, rebuilt and redeployed components for both designs.
- 9
Measure runtime cost
Measure end-to-end latency from unlock event to lamp command in both designs over 200 repetitions, plus CPU and memory use of all processes. A service design normally costs some latency and memory for the middleware; quantify it rather than assume it. Note whether the measured overhead matters for this feature's timing requirement, which is relaxed compared with braking functions. Run both designs on the same machine with the same background load for a fair comparison.
Checkpoint: Latency distributions and resource figures for both designs, compared with the requirement.
- 10
Report
Present the feature, service decomposition, interface sheets, implementation, test results, change-impact comparison and runtime cost. Discuss when a service-oriented design pays off and when a simple signal-based design is good enough. State limitations: one small feature, simulated inputs, one host. Include diagrams of both architectures side by side and the scenario files so the work can be repeated. Add a short section on what would change on a real vehicle computer with several ECUs.
Checkpoint: A report with both architectures, traceable test results and a reasoned conclusion on the trade-off.
Testing & validation
- Scenario tests pass for every requirement in both designs.
- Stale-data and restart fault tests behave as specified.
- Change-impact counts for the planned feature change.
- End-to-end latency and resource use for both designs.
Expected results
A lighting feature built as cooperating services and as a monolithic baseline, with traceable tests and a measured comparison of change effort and runtime cost.
Take it further
- Add a second feature that reuses VehicleState and measure reuse effort.
- Package each service in a container and test independent updates.
- Model the architecture in SysML and generate interface stubs.
- Add access control so only LightingPolicy may command LampActuator.
Viva and review questions
Why split the feature into four services rather than one?
Each service has one responsibility and a stable interface, so a change to policy or actuation does not force changes to the input services, and inputs can be reused by other features.
What does a minor version change promise to consumers?
That existing consumers keep working without change, because only optional, backward-compatible content was added.
What is the cost of the service design?
More processes, middleware overhead in latency and memory, and more interfaces to specify and test, which I measured against the baseline.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.