Workload-Adaptive HMI that Changes Alerts by Rider Workload

The problem

EV clusters generate many messages: low SOC, regeneration limits, temperature, connectivity and service reminders. Shown at a busy moment, a low-priority message competes with the road for attention; held back too long, a critical warning arrives late. Alert scheduling that adapts to rider workload is an open research problem, especially on low-cost embedded hardware.

Objectives

• Define a set of alerts with criticality levels and allowed deferral times.
• Build a real-time workload estimator on the STM32 from MPU6050 motion, potentiometer throttle activity and an emulated speed and manoeuvre profile.
• Implement an adaptive alert arbiter that defers, bundles or escalates alerts based on the workload estimate.
• Evaluate against a fixed-priority baseline with a detection response task and subjective workload ratings.
• Quantify missed or late critical alerts as a safety constraint.

What you need

Key concepts

Rider workload

The share of a rider's attention and control effort the riding task is using at a given moment. It cannot be measured directly, so it is estimated from proxies such as control activity, motion and task difficulty.

Detection response task (DRT)

A standard method (ISO 17488) where a participant presses a button whenever a small stimulus appears. Slower or missed responses indicate higher attentional load.

NASA-TLX

A widely used questionnaire for subjective workload across six dimensions. It gives a per-condition rating to set against the real-time estimator.

Alert arbitration

Deciding which of several pending alerts to show, when and how. An adaptive arbiter adds workload as an input while guaranteeing a maximum delay for critical alerts.

Fixed-point features

The STM32F103 has no FPU, so variances and filters on IMU data are computed in Q15 or Q31 integers to keep the estimator within its time budget.

Step-by-step guide

1. 1

   Frame the research questions and safety constraints

   State the hypotheses: adaptive scheduling lowers DRT response time and subjective workload without increasing late critical alerts. Classify alerts into critical (thermal, insulation-type fault emulation, low SOC cut-back), advisory and informational, each with a maximum deferral time. Write the hard rule that critical alerts are never deferred beyond a fixed bound. Prepare the participant protocol, consent material and an application for institutional ethics approval before any data collection.

   Checkpoint: A written alert catalogue with criticality and deferral bounds, a study protocol and an ethics submission or approval.

2. 2

   Build the PC riding scenario

   Write a PC-side riding task: a road that curves and has events (junctions, overtakes) of known difficulty, steered with the arrow keys and controlled for speed with the kit potentiometer as throttle. The PC streams the emulated vehicle speed and a ground-truth difficulty label to the STM32 over UART at 20 Hz. Explain in the thesis that speed is emulated because the kit has no wheel-speed sensor.

   Checkpoint: The scenario runs repeatably from a seed and the STM32 receives speed and difficulty frames with no parse errors over a 10-minute run.

3. 3

   Configure the board and RTOS

   In CubeMX enable I2C for the MPU6050 at 400 kHz, ADC1 with DMA for the potentiometer, USART for the PC link, GPIO for the LCD, keypad, RGB LEDs, buzzer and the DRT button. Enable FreeRTOS and move the HAL timebase to a spare timer such as TIM4. Plan tasks: sensor acquisition at 100 Hz, workload estimation at 20 Hz, alert arbiter at 20 Hz, HMI output and UART logging. Set DIP switches for the IMU, LCD, keypad, LEDs and buzzer blocks.

   Checkpoint: All tasks run with stack high-water marks above 25 per cent and the heap usage recorded.

4. 4

   Acquire and condition the signals

   Read accelerometer and gyroscope registers in a burst from register 0x3B, set the MPU6050 digital low-pass filter, and compute features over a 1 s sliding window: gyroscope yaw-rate variance, accelerometer jerk energy, throttle rate-of-change and steering activity forwarded from the PC. Implement them in Q15 with running sums so each update costs a few microseconds. Verify against a floating-point Python version on the same logged data.

   Checkpoint: On-board features match the Python reference within 1 per cent on a recorded session, and the task's execution time is measured with the DWT cycle counter.

5. 5

   Build and calibrate the workload estimator

   Start with a transparent baseline: a weighted sum of normalised features mapped to low, medium and high workload. Collect pilot data in which scenario difficulty is known and DRT response times are recorded, then fit the weights (or a small logistic-regression or decision-tree model) offline in Python and port the coefficients as fixed-point constants. Keep the model small and explainable so the arbiter's behaviour can be justified.

   Checkpoint: Offline, the estimator's workload class agrees with scenario difficulty and correlates with DRT response time on held-out pilot sessions.

6. 6

   Implement the adaptive alert arbiter

   Hold pending alerts in a priority queue with timestamps. In high workload, defer advisory and informational alerts and bundle them for the next low-workload window; show critical alerts immediately with red LED, buzzer and LCD text, and escalate if not acknowledged. Enforce each alert's maximum deferral bound regardless of workload. The baseline arbiter shows alerts in fixed priority order as soon as they arrive. Both are selectable from the keypad for the study.

   Checkpoint: Unit tests on the arbiter (run on the PC or in a test build) show that no critical alert exceeds its bound under any injected workload sequence.

7. 7

   Integrate the DRT and logging

   Light a small stimulus (a blue RGB LED flash) at random 3–5 s intervals and timestamp the participant's button press to 1 ms. Log DRT events, workload estimates, alert onsets, acknowledgements and steering error to the PC with a common timebase. Align PC and board clocks with a sync frame at the start of each session. Keep the DRT stimulus independent of the alert LEDs so participants do not confuse the two signals.

   Checkpoint: A pilot session shows DRT hits, misses and response times, and every alert event lines up with the PC log within a few milliseconds.

8. 8

   Run the within-subjects study

   Each participant rides both baseline and adaptive conditions in counterbalanced order, with the same scenario seeds and the same alert schedule. Collect NASA-TLX ratings after each condition. Keep instructions identical and record any session problems. Follow the approved protocol, including the right to stop at any time. Start each session with a familiarisation ride that is not analysed, so participants learn the scenario and controls before the measured conditions. Store consent forms separately from the anonymised data.

   Checkpoint: Complete, quality-checked data for the agreed number of participants with an order table and incident log.

9. 9

   Analyse and test the hypotheses

   Compare DRT response time, DRT miss rate, steering error and NASA-TLX between conditions with paired tests or mixed-effects models, reporting effect sizes and confidence intervals. Report the safety constraint separately: maximum and distribution of critical-alert delay in each condition. Analyse estimator performance as classification accuracy against scenario difficulty. Treat participant as a random effect so individual differences in reaction time do not mask the condition effect. Correct for multiple comparisons where several outcome measures are tested.

   Checkpoint: A reproducible analysis notebook producing every table and figure in the thesis from the raw logs.

10. 10

    Document the testbed and the method

    Write up the alert catalogue, estimator, arbiter policy, firmware timing budget, study protocol and results. Release firmware and analysis scripts with the anonymised dataset if your ethics approval allows. Discuss threats to validity such as the desk-based setting and emulated speed. State the firmware version, scenario seeds and estimator coefficients used in every session, so a reviewer can map each result to the exact software that produced it. List the open questions the study raises for future on-road work.

    Checkpoint: A thesis chapter or paper draft that a reviewer could follow to rebuild the testbed and rerun the study.

Testing & validation

• The arbiter never delays a critical alert beyond its bound in randomised injected workload sequences (property-based tests on the PC build).
• Estimator features on the STM32 match a floating-point reference within a stated tolerance.
• Worst-case execution time of the estimator and arbiter tasks, measured with the DWT cycle counter, fits inside their periods.
• DRT timing accuracy is verified with a simulated button press of known delay.

Expected results

An embedded workload estimator and adaptive alert arbiter running in real time on a Cortex-M3, plus a controlled comparison with fixed-priority alerting on DRT performance, subjective workload and critical-alert delay.

Take it further

• Replace the weighted-sum estimator with a small quantised neural network and compare explainability and accuracy.
• Add alert modality selection, choosing between LED, buzzer and text based on workload.
• Study personalisation by adapting estimator thresholds per rider over sessions.

Viva and review questions