Behaviour Planning with a Hierarchical State Machine for Urban Scenarios

The problem

A motion planner needs to know what to do before it can plan how: follow, stop, yield or overtake. Behaviour planners in many systems are still state machines because they are easy to read and verify. Designing one that handles mixed urban traffic without deadlocks or unsafe transitions is a good exercise in requirements, state design and testing.

Objectives

• Write behaviour requirements for a set of urban situations.
• Design a hierarchical Stateflow chart with clear transition conditions.
• Connect the chart to a simple motion layer in simulation.
• Test every requirement with scripted scenarios and measure transition coverage.

What you need

Key concepts

Hierarchical state machine

States nested inside super-states, such as Driving containing LaneFollow and CarFollow, which keeps charts readable and lets common transitions be written once.

Guard conditions

Boolean expressions on inputs, such as a gap being larger than a threshold, that must be true for a transition to fire.

Deadlock

A situation where the system waits forever, for example yielding to a pedestrian who has stopped, which needs timeouts or extra rules.

Step-by-step guide

1. 1

   Write the behaviour requirements

   List situations and required behaviour: follow lane when the road is clear; follow a leader at a time gap; stop at a stop line and proceed when the junction is clear; yield to pedestrians on a crossing; overtake a stopped vehicle when the opposite lane is clear for a set distance; and perform a minimal-risk stop when perception is invalid. Number each requirement and write measurable conditions.

   Checkpoint: A numbered requirement list with measurable conditions for each behaviour.

2. 2

   Define inputs and outputs

   Define the inputs the chart needs: ego speed, lead vehicle gap and speed, distance to stop line, junction clear flag, pedestrian on crossing flag, oncoming gap and perception valid flag. Define outputs: target speed, target lane offset and a behaviour label. Create a Simulink bus for inputs so the interface is clear. Decide on signal rates and units. Agree default values for missing inputs.

   Checkpoint: A documented interface table and bus definition.

3. 3

   Design the chart

   In Stateflow, create a top level with Driving and MinimalRiskStop. Inside Driving, create LaneFollow, CarFollow, ApproachStop, Stopped, Yield and Overtake states, with Overtake containing sub-states for pull-out, pass and return. Write guard conditions with hysteresis and minimum dwell times to avoid chattering. Add a timeout in Yield and Stopped to prevent deadlock. Keep each guard short and name thresholds as parameters rather than hard-coded numbers, so they can be tuned and traced back to the requirement that set them.

   Checkpoint: A chart that compiles and shows expected transitions when inputs are changed by hand.

4. 4

   Build the motion layer

   Connect the chart to a simple vehicle model: a longitudinal controller that tracks the target speed with acceleration limits and an intelligent-driver-style car-following law in CarFollow, and a lateral controller that tracks the target lane offset. This does not need to be sophisticated; it lets the behaviour be observed in closed loop. Keep the motion layer simple and fixed through testing, so that failures can be traced to the behaviour chart rather than the controllers.

   Checkpoint: The ego follows lane, follows a leader and stops at a line in a simple scenario.

5. 5

   Build the scenarios

   Create scenarios with the Driving Scenario Designer: a clear road, a slow leader, a four-way junction with a stop line and crossing traffic, a pedestrian crossing with pedestrians arriving at different times, a stopped car with and without oncoming traffic, and a perception dropout. Compute the chart's inputs from scenario ground truth with simple logic. Name each scenario after the requirement it tests so the traceability stays clear.

   Checkpoint: Each scenario runs and produces the inputs the chart expects.

6. 6

   Test against requirements

   For each requirement write at least one test case with pass criteria, such as the ego stops within 1 m before the stop line with speed under 0.1 m/s. Run them in Simulink Test or with a MATLAB script. Record pass or fail and investigate every failure, which usually points to a missing guard or wrong threshold. Fix and rerun the full set each time.

   Checkpoint: A test report with every requirement passing or failures explained.

7. 7

   Measure coverage

   Check that every state and transition was exercised by the tests using Simulink Coverage if available, or by logging state activity. Add tests for any unvisited transitions, especially those into MinimalRiskStop and timeout paths. Look for unreachable states and remove or justify them. Record why any transition cannot be reached by a test, and ask a teammate to review the chart for missing transitions, for example from Overtake back to MinimalRiskStop when perception fails mid-manoeuvre.

   Checkpoint: State and transition coverage report with all transitions exercised.

8. 8

   Report

   Document requirements, chart design with screenshots, interface, scenarios, test results and coverage. Discuss limitations of state machines, such as growth in complexity as situations are added, and where learned or optimisation-based behaviour planners might help. State that the work is simulation only. Include a traceability table that links each requirement to its states, transitions, test cases and results, which is what a reviewer will check first when assessing the chart.

   Checkpoint: A final report and demo of the chart in action across scenarios.

Testing & validation

• Pass or fail result for each requirement-based test case.
• State and transition coverage.
• Absence of chattering and deadlocks in tests.
• Stopping accuracy and time gaps in closed-loop runs.

Expected results

A hierarchical Stateflow behaviour planner for urban situations, connected to a simple motion layer and verified against numbered requirements with full transition coverage.

Take it further

• Add right-of-way rules for unsignalled junctions with mixed traffic.
• Generate C code from the chart with Embedded Coder.
• Replace one behaviour decision with a learned policy and compare.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.