The problem
On an Adaptive platform, applications do not simply start at boot. Execution Management launches processes according to manifests, and State Management decides which function-group states are active, for example which ADAS functions run while parking or driving. Handling a crashed perception process correctly is a safety concern. This project builds these mechanisms in simplified form to study startup order, mode switching time and failure reactions.
Objectives
- Explain Adaptive Execution Management, State Management, function groups and execution manifests.
- Write manifests for perception, fusion, planning and logging processes with dependencies.
- Implement a supervisor that starts processes in dependency order and reports execution state.
- Implement a state manager with function-group states and transition rules.
- Measure startup and mode-switch times and failure-reaction behaviour.
What you need
Tools and toolboxes
- C++17 with CMake — Implements the supervisor, state manager and the stand-in ADAS processes.
- Linux process control (fork, exec, signals, cgroups) — Starts, stops and monitors processes and limits their resources.
- Stateflow — Models the state-manager logic first and checks transitions before coding.
- vsomeip (COVESA) — Carries state requests and execution-state reports between processes.
- Python with pandas and matplotlib — Analyses timing logs and plots startup sequences.
Software
- Ubuntu Linux
- C++17 toolchain
- MATLAB with Stateflow
- vsomeip
- Python
Extra parts and data
None beyond the software above.
Key concepts
- Execution Management
- The Adaptive platform service that starts and stops application processes according to their execution manifests and the requested function-group states.
- Function group
- A named set of processes whose states are switched together, for example an ADAS function group with states Off, Parking and Driving.
- Execution manifest
- A configuration describing a process: its executable, arguments, dependencies on other processes, resource limits and the function-group states in which it should run.
- Execution state reporting
- A process tells Execution Management when it has finished initialising and is running, so dependants are only started once it is ready.
Step-by-step guide
- 1
Define the application set and modes
Choose five stand-in processes: CameraPerception, RadarPerception, Fusion, ParkAssist and DriveAssist, plus a Logger. Define function-group states for an ADAS function group: Off (Logger only), Parking (Camera, Radar, Fusion, ParkAssist), Driving (Camera, Radar, Fusion, DriveAssist). Write requirements for maximum startup time to Driving, maximum mode-switch time and the reaction when Fusion crashes. Draw a first dependency sketch showing that Fusion needs both perception processes before it can run.
Checkpoint: A table of processes per state and numeric timing and failure-reaction requirements.
- 2
Write the manifests
Write a manifest per process as JSON or a simplified ARXML-style file listing executable path, arguments, start-up dependencies (Fusion depends on both perception processes reaching Running), the function-group states it belongs to, a termination timeout and a restart policy. Write a machine manifest listing the function group and its states. Validate the files with a small schema checker so typos fail early.
Checkpoint: Manifests that pass schema validation, with a dependency graph drawn from them.
- 3
Build stand-in processes
Write a small C++ template process that simulates initialisation time with a configurable delay, reports Running to the supervisor through a local socket or SOME/IP, then runs a periodic loop with configurable CPU load. It handles SIGTERM by cleaning up within a set time. Use it for every ADAS process, with different settings, so timing behaviour is controllable. Add an option that makes the process crash or hang on purpose, for later fault tests.
Checkpoint: Each stand-in starts, reports Running after its configured delay and exits cleanly on SIGTERM.
- 4
Model the state manager in Stateflow
Model the function-group states and transitions in Stateflow: requests from a vehicle-mode input (ignition, gear, speed), guard conditions such as only entering Parking below a speed threshold, and failure transitions such as moving to a degraded Driving state when Fusion fails. Simulate request sequences and check that illegal transitions are refused. This model becomes the specification for the C++ state manager.
Checkpoint: Stateflow simulation results for normal and illegal request sequences matching the requirements.
- 5
Implement the supervisor
Implement the execution supervisor: parse manifests, compute start order from dependencies with a topological sort, start processes with fork and exec, wait for their Running reports with timeouts, and stop processes in reverse order with SIGTERM followed by SIGKILL after the termination timeout. Detect unexpected exits with waitpid and report them. Put each process in its own cgroup with a CPU limit from the manifest.
Checkpoint: The supervisor brings up the Driving process set in dependency order and logs every state change with timestamps.
- 6
Implement the state manager
Implement the state manager in C++ following the Stateflow model. It receives vehicle-mode inputs, decides the target function-group state and asks the supervisor to switch. During a switch it computes which processes to stop and which to start, so processes common to both states, such as perception, keep running. It reports the active state and refuses new requests until a switch completes.
Checkpoint: Switching from Parking to Driving stops ParkAssist, starts DriveAssist and leaves perception running.
- 7
Handle failures
Inject failures: kill Fusion, make CameraPerception hang without reporting Running, and make ParkAssist ignore SIGTERM. Implement reactions from the requirements: restart Fusion once, then move to a degraded state if it fails again; time out a hanging start; force-kill a process that does not stop. Log each failure, the decision taken and the time to reach a safe state. Run every injected fault in both Parking and Driving, because the right reaction may differ by state.
Checkpoint: A log for each injected fault showing detection, reaction and time to the defined safe state.
- 8
Measure timing
Measure boot-to-Driving time, Parking-to-Driving switch time and fault-reaction times over 50 runs each with varied initialisation delays and CPU load. Plot startup sequences as Gantt-style charts from the timestamps. Compare measured worst cases with requirements and identify which dependency chain dominates startup time. Keep the machine otherwise idle during measurements, and repeat the worst runs with tracing enabled to see where time is spent. Record kernel version and CPU settings with the results.
Checkpoint: Timing distributions and Gantt charts with the critical startup chain identified.
- 9
Back-to-back test against the model
Feed the same vehicle-mode request sequences to the Stateflow model and to the C++ state manager and compare the resulting state sequences step by step. Any mismatch is either an implementation bug or a model ambiguity; fix and document each one. Aim for full transition coverage in the Stateflow model with the chosen sequences. Store the request sequences as files so the same set reruns after every code change.
Checkpoint: Matching state sequences for all test cases and a transition coverage figure for the model.
- 10
Report
Document requirements, manifests, the Stateflow model, supervisor and state-manager design, failure handling and timing results. Relate each element to its Adaptive platform counterpart and state what a real platform adds, such as platform health management, identity and access management and certified behaviour. Discuss limitations: a general-purpose Linux kernel and stand-in workloads. Include the Gantt charts and fault logs, and give build instructions so the work can be repeated.
Checkpoint: A report with traceable requirements, model, code and measured results.
Testing & validation
- Dependency-ordered startup confirmed from timestamps.
- Correct process sets after each function-group state switch.
- Failure reactions and time to safe state for each injected fault.
- Back-to-back agreement between the Stateflow model and C++ implementation.
Expected results
A simplified Adaptive-style execution supervisor and state manager running a set of ADAS stand-in processes, with measured startup, switching and failure-reaction times and a verified state model.
Research angle for your M.Tech thesis
Research questions: how should function-group states and restart policies be designed to minimise time to a safe degraded mode after a perception failure, and how does dependency structure drive startup time? Metrics: boot-to-function time, mode-switch time, fault-reaction time and availability of the ADAS function under injected failures. Baselines: start-all-at-boot and naive sequential start. Comparing policies on a reproducible fault-injection campaign gives a basis for a conference paper on Adaptive platform configuration.
Take it further
- Add a watchdog-style health monitor with alive supervision and deadline checks.
- Run on a PREEMPT_RT kernel and compare timing.
- Add a second function group for logging with independent states.
- Replace stand-ins with real perception processes from another project.
Viva and review questions
Why keep perception running when switching from Parking to Driving?
It is needed in both states, so stopping and restarting it would waste time and leave a gap in perception during the switch.
What is the difference between Execution Management and State Management?
Execution Management starts and stops processes as configured; State Management decides which function-group states should be active and requests them.
Why model the state manager in Stateflow first?
It gives an executable specification that can be simulated and covered, and later compared back-to-back with the hand-written code.
What happens if a process never reports Running?
The supervisor times out, records the failure and applies the configured policy, such as one retry and then a degraded state.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.