The problem
An ADAS function is a chain of runnables, sensor processing, fusion, control and actuation, spread over tasks with different periods. Even if each task meets its deadline, the data age from sensor to actuator can be much longer than expected. AUTOSAR OS scheduling and timing analysis are how engineers prove a function reacts in time, and timing problems are a common integration failure.
Objectives
- Model a multi-rate controller and generate runnables with Embedded Coder.
- Map runnables to tasks with priorities following AUTOSAR OS concepts.
- Measure execution and response times on the STM32.
- Compare measurements with response-time analysis.
- Analyse end-to-end latency and data age along cause-effect chains.
What you need
Tools and toolboxes
- Simulink — A multi-rate ADAS controller model with 5, 10 and 50 ms rates.
- AUTOSAR Blockset — Modelling the controller as a component with several runnables and timing events.
- Embedded Coder — Generating runnable code for the STM32.
- STM32CubeIDE with FreeRTOS — A fixed-priority preemptive kernel configured to behave like AUTOSAR OS basic tasks.
- Python — Response-time analysis, trace processing and latency statistics.
From the EV Embedded Development Kit
- STM32F103C8T6 microcontroller unit (Arm Cortex-M3)
- CAN bus interface with screw terminal
- Analog potentiometer input
- Serial UART interface
- RGB LEDs and a buzzer
Software
- STM32CubeIDE with FreeRTOS
- MATLAB, Simulink, AUTOSAR Blockset and Embedded Coder
- Python 3 with python-can, NumPy and pandas
- Logic analyser software such as PulseView
Extra parts and data
- USB logic analyser — Captures GPIO toggles marking task start and end for accurate, non-intrusive timing traces.
- USB-CAN adapter — Supplies input frames at controlled times and timestamps the output frames for end-to-end latency.
Key concepts
- AUTOSAR OS scheduling
- Based on OSEK: tasks with fixed priorities, full or limited preemption, activated by alarms or schedule tables, with resources using the priority ceiling protocol.
- Response-time analysis
- A calculation of the worst-case time from a task's release to its completion, including interference from higher-priority tasks: R = C + sum over higher tasks of ceil(R / T) × C, solved iteratively.
- Cause-effect chain
- The path data takes from an input event through several runnables to an output. Its latency depends on periods and offsets as well as execution times.
- Data age and reaction time
- Data age is how old the input is when the output based on it is produced; reaction time is how long until an input change first affects the output.
Step-by-step guide
- 1
Define the controller and chains
Build a small ADAS-like controller: a 5 ms task reads a CAN frame with object range and the potentiometer as a speed sensor; a 10 ms task runs a filter and TTC calculation; a 50 ms task runs an ACC-style controller and mode logic; a 10 ms task sends the command frame. Define two cause-effect chains, from range input to brake command and from speed input to display, with required maximum latencies.
Checkpoint: A diagram of runnables, rates and the two chains with latency requirements.
- 2
Model and generate runnables
Build the controller in Simulink as an AUTOSAR component with separate runnables for each rate, using rate transition blocks or explicit inter-runnable variables between them. Configure the timing events in the Code Mappings editor and generate code with Embedded Coder. Inspect how data crosses between rates in the generated code, since this determines data consistency and latency later. Record which rate transitions are buffered and which add a delay of one period.
Checkpoint: Generated code with one function per runnable and explicit data exchange between rates.
- 3
Map runnables to tasks
Configure FreeRTOS with preemption and fixed priorities, one task per rate, released by a periodic timer or vTaskDelayUntil to mimic AUTOSAR OS alarms. Assign priorities rate-monotonically, shortest period highest. Protect shared data with a short critical section or a mutex with priority inheritance, noting that AUTOSAR OS uses the priority ceiling protocol. Write a thin RTE glue layer that calls the runnables and copies inter-task data.
Checkpoint: All tasks run at their periods, confirmed by GPIO toggles on the logic analyser.
- 4
Measure execution times
Toggle a dedicated GPIO at the start and end of each task and also record cycle counts with the DWT counter. Measure execution times over many thousands of activations under varying inputs, including paths that execute more code such as mode changes. Report minimum, mean, maximum and high percentiles. Note that measured maxima are not guaranteed worst-case execution times and add a margin, stating how you chose it.
Checkpoint: An execution time table per task with distribution plots and the chosen design WCET.
- 5
Calculate response times
Implement response-time analysis in Python for fixed-priority preemptive scheduling, including blocking from critical sections and the kernel tick overhead you measure. Compute the worst-case response time of each task with your design WCETs and check it against the deadline, equal to the period here. Compute CPU utilisation and the margin before the task set becomes unschedulable by scaling execution times.
Checkpoint: Calculated response times, utilisation and a scaling margin for the task set.
- 6
Measure response times
From the logic analyser traces, measure the time from each task's release to its completion over long runs. Compare with calculated worst cases. Add an artificial load, such as a busy loop of configurable length in a low-priority task and an interrupt storm from CAN frames sent fast from the PC, and check that higher-priority tasks still meet deadlines while lower ones degrade as predicted.
Checkpoint: Measured versus calculated response times under nominal and added load.
- 7
Analyse end-to-end latency
For each chain, calculate the best and worst-case data age and reaction time from task periods, offsets and response times, considering that each task reads the latest value written by the previous one. Then measure: the PC sends a step change in the range frame at random times and timestamps the brake command frame in response. Collect thousands of samples and compare the distribution with the calculated bounds.
Checkpoint: Measured latency distributions for both chains within the calculated bounds.
- 8
Optimise and compare designs
Try design changes that reduce chain latency: aligning task offsets so the consumer runs just after the producer, merging the 10 ms filter and output tasks, or a logical execution time approach where inputs are read and outputs written at fixed instants. Measure latency, jitter and CPU load for each design. Discuss the trade-off between low latency and the determinism that LET gives.
Checkpoint: A table comparing latency, jitter and CPU load for at least three task designs.
- 9
Report
Document the controller, task mapping, execution and response time measurements, the analysis, chain latency results and design comparison. Explain how this would be done for a production ECU: AUTOSAR OS configured from ARXML, with timing tools from industry used for analysis and tracing. State limits: FreeRTOS as a stand-in for AUTOSAR OS, measured rather than proven WCET and a single-core MCU.
Checkpoint: A report linking analysis to measurements for every task and chain.
Testing & validation
- Task periods confirmed on the logic analyser.
- Execution time distributions with chosen WCET margins.
- Measured response times within calculated bounds.
- Chain latency distributions within calculated data age and reaction time bounds.
- Comparison of task designs on latency, jitter and load.
Expected results
A timing-analysed multi-rate controller on the STM32 kit with response-time analysis confirmed by measurement and end-to-end latency quantified and optimised along two cause-effect chains.
Research angle for your M.Tech thesis
Research questions: how closely do analytical response-time and chain-latency bounds match measurements on a low-cost MCU, and which task design gives the best latency-determinism trade-off for an ADAS chain? Metrics: measured versus calculated response times, chain data age and reaction time distributions, jitter and CPU load. Comparing offset-aligned, merged and LET designs with released traces gives quantitative results for an M.Tech thesis on automotive timing.
Take it further
- Port to an open-source OSEK/AUTOSAR OS kernel and compare overheads.
- Add timing protection that detects execution budget overruns.
- Model the chain latency in Simulink with task-level simulation.
- Study multi-core mapping on a dual-core MCU.
Viva and review questions
Why can a chain miss its latency requirement when every task meets its deadline?
Each task only promises to finish within its period. Data may wait for the next activation of each consumer task, so latencies add up along the chain.
Why is a measured maximum execution time not a guaranteed WCET?
The test inputs may not have hit the worst path or worst cache and pipeline state, so a margin or static analysis is needed for a safe bound.
What does logical execution time give you?
Inputs are read and outputs written at fixed instants regardless of when the task actually runs, which removes jitter and makes latency predictable, at the cost of always waiting the full period.
Why does AUTOSAR OS use the priority ceiling protocol?
It bounds blocking time and prevents deadlock when tasks share resources, by raising a task's priority to the ceiling of the resource it holds.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.