How to design ADAS system functional state machine (Part 2)

1. Define the state

State definition: Clearly define the states in the system, ensuring that each state is clear and mutually exclusive. Each state should have a clear meaning and behavior.

Different autonomous driving functions may have different state machines. The definition of the state is determined by the function, and the system needs to correctly execute the corresponding behavior and function under different conditions. At the same time, the design principle of the state machine should also facilitate the expansion and maintenance of the system, so that the system can adapt to changing needs and environments; for example, when designing the NOP function, it should be considered how to switch with functions such as LCC/ACC.

L0 ADAS functions, such as FCW/LDW/BSD, etc., basically do not involve vehicle control, but only serve as warnings. Their state definitions are also relatively simple and can be divided into the following states:

OFF: The system is off and not working.

Standby: The system meets the operating conditions and is on standby.

Warning: The warning trigger conditions are met and the alarm is being sounded.

Inhibit: The warning is suppressed by the user.

Error: System failure.

According to national standards and regulations, the Warning status may also include the Pre-Warning status.

L1's AEB/LCC and other functions only involve single lateral or longitudinal control. For example, AEB is mainly responsible for emergency braking, and will add the Brake state after FCW Warning. According to the functional definition, ACC will have Speed ​​Control, Distance Control, Override, Temp Stop and other states. LCC will have Lane Keeping and other states. It can be seen that the state machine mainly serves the function and is decomposed into different states around the core function.

State Flow logical system modeling textbook diagram from the author

Since the L2-level NOP function requires simultaneous lateral and longitudinal control of the vehicle, the lateral control and longitudinal control states in the main state will be running at the same time. Due to the limitations of the ODD range, there are also downgrade requirements, such as the Safe Stop state. The logic is relatively complex and has high compatibility requirements.

The parking function state machine will of course have states such as Searching (searching for a parking space), Parking (parking process), Suspend (parking interruption), and Completed (parking completion).

2. Event Definition

Event definition: Identify possible events that may occur in the system and define clear trigger conditions for each event. Events can be sensor inputs, user actions, or other changes inside or outside the system.

For example, in many systems, the trigger event of OFF->Standby is "the vehicle is in IGN ON state", that is, the vehicle is powered on. This event can be considered as vehicle state input. The trigger event of Stadnby->Active may be "the user clicks the function start button on the central control screen", which can be considered as a user operation, and so on.

If there are multiple events in the system and they can occur at the same time, then the event priority needs to be considered. Event priority determines which event will be processed first when multiple events are triggered at the same time. For example, an emergency braking event may have a higher priority than a forward obstacle detection warning event.

3. Conversion rules

Transition rules: Determine the transition rules between states, that is, how to transition from one state to another when a specific event occurs. The transition rules should take into account the logic and constraints of the system.

When we consider the transition rules, we should try to be comprehensive and detailed to ensure the completeness of the state machine, that is, to ensure that all possible transitions between states have been defined and covered. Lack of completeness may lead to undefined behavior or state anomalies in the system, causing the state machine to jump into an infinite loop and unable to jump out of the bug. By carefully analyzing the system requirements and design, we hope to ensure that all possible state transitions are considered and defined.

4. Actions and Behaviors

Actions and behaviors: Define corresponding actions and behaviors for each state and state transition. These actions can be executing specific functions, sending control commands, updating state variables, etc.

When we consider the state, we can provide a description of the work in that state. For example, in the APA automatic parking system, when we enter the Parking state, the state machine should be responsible for handshaking with the vehicle control system. After the handshake is successful, the Control module will control the vehicle. (This is just an example, and the handshake can also be completed by other modules)

5. Error handling

**Error handling: Consider the errors and exceptions that may occur in the system and design corresponding handling mechanisms for them. **Includes the definition of error status, error handling process and recovery mechanism, which are generally handled and managed by the Error status.

6. Code generation and testing

**The state machine is a relatively old thing, and many manufacturers have developed it to facilitate our use and testing.

Stateflow is a tool in MATLAB/Simulink for modeling and designing complex state machines. It provides a graphical interface that allows you to easily create, edit, and debug state machine models and automatically generate corresponding code.

The main functions of Stateflow include the following aspects:

1. State machine modeling: Stateflow provides a rich set of modeling elements, such as states, transitions, events, conditions, actions, etc., which can intuitively describe the state of the system and the transition relationship between states. By dragging and connecting these modeling elements, you can easily build a state machine model and define the transition conditions and corresponding actions between states.

2. Event-driven: Stateflow is based on event-driven model execution. The state transition of the system is driven by triggering events. Various types of events can be defined, such as input signals, timers, conditional judgments, etc. When the transition conditions are met, Stateflow will execute the transition accordingly and trigger the corresponding actions.

3. Action execution: During the state transition process, you can specify specific actions or behaviors. These actions can be simple assignment operations, function calls, or complex algorithmic logic. Stateflow provides a rich action language and function library that can flexibly define the actions that need to be executed during the state transition process.

4. State detection: Stateflow provides a flexible state detection mechanism that can detect the current state of the system and the state transition under specific conditions. These detections can be used for system monitoring, fault detection, and security protection.

5. Code generation: Once the state machine modeling and design are completed, Stateflow can automatically generate the corresponding code for integration into the actual system. The generated code can be C/C++ code, MATLAB function or Simulink module, which can be seamlessly integrated with other system components.

The State Flow development interface diagram comes from the Internet

The development interface is shown in the figure above. In general, the software is easy to use and requires low coding skills. Once the process is completed, subsequent development and maintenance are relatively easy. In terms of debugging, the software is also very good. It can pull out the value of each signal for direct simulation verification, which helps to quickly locate and solve problems.

When I just graduated, several girls in my class were responsible for developing state machines in the software group. Later, they all did a great job and now they are applying for jobs at major suppliers. After all, this skill is generally more useful at Tier 1 component suppliers...

7. Conclusion

The above are some of the key points of state machine design summarized by the author. Depending on the specific application scenario and system requirements, there may be other specific requirements and considerations. When designing a state machine, the key is to fully understand the functions and goals of the system and work closely with team members to ensure that the designed state machine can meet the requirements and expected effects of the system.

**During the development phase, the design can also be from simple to complex. First, think clearly about the states, confirm what aspects the jump conditions of each state should include, and then iterate the design according to the project progress. **When designing the state machine in the project, the author needs to think clearly about the system boundaries in the first version, but the jump condition of each state may only have an activation signal or a vehicle speed signal; in the subsequent process of continuous development, the design is gradually enriched, and the sub-states and jump conditions are improved, so that the development can be both agile and stable.