狀態機模塊在自動駕駛系統中扮演著關鍵的角色，它負責管理和控制各個功能的狀態轉換和行為執行。今天我們來聊聊如何設計自動駕駛系統的狀態機?。

0.閑談

作為自動駕駛系統工程師，從參與項目開始，就必不可少的與狀態管理模塊打交道，因為狀態機在系統運行的全功能周期內起管理作用。狀態機這個模塊，從技術實現角度來說，并沒有什么難度，在網上有很多關于FSM(Finite-state machine）的介紹文章，有興趣可以自行了解。但如何設計得巧妙、周到、精致，卻很考驗設計者的底蘊與對系統的理解。

大部分的ADAS功能都需要狀態機進行狀態管理，筆者手中就有不下十幾份狀態機的設計文檔，包括FCW/LDW/AEB/ACC/LKA/NOP/APA/AVP等等，設計大相徑庭，但細細想來內核卻大同小異。其中NOP功能的狀態跳轉還是比較復雜的，涉及橫向、縱向控制與功能降級等邏輯，需要長期的雕琢與迭代才能設計出符合項目要求的效果。

筆者最近也在負責APA功能的狀態機設計，雖然比較簡單，但還是想借此機會對狀態機模塊做一點總結，也是對以往工作的回顧。

1.模塊概述

狀態機模塊的主要作用是跟蹤系統的當前狀態，并根據特定的事件和條件進行狀態轉換。它可以根據傳感器數據、車輛狀態和系統輸入來判斷當前功能的可用性和執行條件。狀態機模塊還能夠監控系統的運行情況，及時響應來自駕駛決策或用戶的指令，并根據需要觸發相應的功能執行。

狀態機模塊通過定義和維護一組狀態，以及狀態之間的轉換條件和行為，確保系統在不同的場景和條件下正確地執行相應的功能。例如，當檢測到前方車輛與本車距離過近時，FCW功能會被觸發，狀態機模塊會根據預設的邏輯條件和行為來切換到相應的預警狀態，并觸發聲音或振動等警示措施。

狀態機模塊的設計需要考慮各個功能之間的優先級、依賴關系和沖突情況。它需要具備靈活性和可擴展性，以應對不同的道路情況和交通場景。比如cat-in、cat-out情景、自動變道時的變道空間判斷等等。同時，狀態機模塊還需要具備高效的算法和實時性能，以保證系統的快速響應和可靠性。

總之，狀態機模塊在自動駕駛系統中扮演著決策和控制的關鍵角色。通過有效地管理和控制各個功能的狀態轉換和行為執行，狀態機模塊能夠確保系統的穩定性、安全性和可靠性，它是實現ADAS功能的基礎模塊之一。

2.設計原理

狀態機的設計原理是基于狀態、事件和轉換的概念。狀態表示系統或功能在某一時刻的特定狀態，事件表示觸發狀態轉換的條件，而轉換則表示狀態之間的切換過程。

首先，需要定義系統或功能的各個狀態。狀態可以是具體的行為狀態，也可以是抽象的控制狀態。每個狀態都代表了系統的一個特定方面或功能，例如“Standby”、“OFF”、“Parking”等。

接下來，定義觸發狀態轉換的事件。事件可以是傳感器的觸發信號、用戶的輸入指令或系統內部的條件判斷。通過檢測事件的發生，狀態機能夠判斷是否需要進行狀態轉換。

然后，定義狀態之間的轉換條件和行為。轉換條件是判斷是否可以進行狀態轉換的邏輯條件，例如滿足一定的時間限制、特定的傳感器數據或用戶指令。轉換行為是在狀態轉換時執行的操作，例如觸發警報、調整車速或切換到下一個狀態。

為了更好地設計和管理狀態機，可以使用狀態表和狀態轉換圖。狀態表是一個表格，列出了系統的各個狀態和相應的轉換條件。狀態轉換圖則是通過節點和箭頭表示各個狀態和轉換，直觀地展示了狀態之間的關系和轉換規則。

EA示例 狀態轉換圖

EA示例 狀態表

在設計狀態機時，需要確保其特性，包括確定性、完備性和可達性。

確定性表示每個狀態都有明確的轉換規則，不會出現歧義或沖突。

完備性表示系統的所有可能狀態都被考慮到，并定義了相應的轉換規則。

可達性表示系統能夠從任意初始狀態達到目標狀態，確保狀態機的可靠性和穩定性。

通過使用狀態機的設計原理，可以清晰地定義系統的各個狀態和轉換規則，確保系統在不同的條件下正確地執行相應的行為和功能。同時，狀態機的設計原理也為系統的擴展和維護提供了便利，使得系統能夠適應不斷變化的需求和環境。

4.定義狀態

狀態定義：明確定義系統中的狀態，確保每個狀態都是清晰且互斥的。每個狀態應該具有明確的含義和行為。

不同的自動駕駛功能可能具有不同的狀態機，狀態的定義是由功能決定的，系統需要在不同的條件下正確地執行相應的行為和功能。同時，狀態機的設計原理也應該為系統的擴展和維護提供了便利，使得系統能夠適應不斷變化的需求和環境；比如在NOP功能設計時，應考慮到如何與LCC/ACC等功能進行切換。

L0的ADAS功能，比如FCW/LDW/BSD等等基本不涉及車輛控制，僅起到預警作用。其狀態定義也較為簡單，可以分為以下幾個狀態：

OFF:系統關閉，未進行工作。

Standby：系統滿足運行條件，正在待機。

Warning：符合預警觸發條件，正在報警。

Inhibit：預警被用戶抑制。

Error：系統故障。

根據國標法規要求，Warning狀態中可能還包括Pre-Warning狀態。

L1的AEB/LCC等功能僅涉及橫向或縱向的單一控制，比如AEB主要負責緊急制動功能，會在FCW Warning后增加Brake的狀態。而ACC根據功能定義，會存在Speed Control、Distance Control、Override、Temp Stop等狀態。LCC則會存在Lane Keeping等狀態。由此可以看出，狀態機主要是為功能服務，圍繞核心功能而分解為不同狀態。

State Flow 邏輯系統建模教材 圖來源于筆者

由于L2級別的NOP功能需要同時對車輛進行橫向、縱向控制，主狀態中的橫向控制和縱向控制狀態會同時在運行，受限于ODD范圍還存在降級的要求，比如Safe Stop等狀態，邏輯相對復雜，對兼容性要求較高。

而泊車功能狀態機，當然會存在Searching（搜索車位）、Parking（泊車過程）、Suspend（泊車中斷）、Completed（泊車完成）等狀態。

5.事件定義

事件定義：識別系統中可能發生的事件，并為每個事件定義清晰的觸發條件。事件可以是傳感器輸入、用戶操作或其他系統內外的變化。

舉例說明，在很多系統中，OFF->Standby的觸發事件為“車輛的為IGN ON狀態”即車輛已經上電，這個事件可以被認為是車輛狀態輸入。Stadnby->Active的觸發事件可能為“用戶點擊中控屏幕上的功能開啟按鍵”，這個事件可以被認為是用戶操作，等等。

如果系統中存在多個事件，并且它們可以同時發生，那么需要考慮事件的優先級。事件優先級決定了在多個事件同時觸發時，哪個事件會被優先處理。例如，緊急制動事件可能具有比前方障礙物檢測預警事件具備更高的優先級。

6.轉換規則

轉換規則：確定狀態之間的轉換規則，即在特定事件發生時如何從一個狀態轉換到另一個狀態。轉換規則應該考慮到系統的邏輯和約束條件。

當我們考慮轉換規則時，應當盡量全面而細致，確保狀態機的完備性，即確保狀態之間的所有可能轉換都已經定義和覆蓋。缺乏完備性可能導致系統出現未定義的行為或狀態異常，從而使狀態機跳入死循環無法跳出bug。通過仔細分析系統需求和設計，期望確保所有可能的狀態轉換都被考慮和定義。

7.動作和行為

動作和行為：為每個狀態和狀態轉換定義相應的動作和行為。這些動作可以是執行特定的功能、發送控制命令、更新狀態變量等。

當我們考慮狀態時，可以輔以該狀態下的工作描述。比如在APA自動泊車系統中，當我們進入Parking狀態后，狀態機應當負責與車輛控制系統進行握手，握手成功后由Control模塊進行控車。（此處僅為舉例，握手也可以由其他模塊完成）

8.錯誤處理

錯誤處理：考慮系統可能發生的錯誤和異常情況，并為其設計相應的處理機制。包括錯誤狀態的定義、錯誤處理流程以及恢復機制，一般統一由Error狀態進行處理和管理。

9.代碼生成與測試

狀態機是一個比較有歷史的東西，很多廠家為了它做了相關的開發，方便我們使用和測試。現在有很多成熟的能夠自動生成狀態機代碼的工具，筆者以前也參與過相關項目，公司使用的是MATLAB/Simulink中的一個工具庫State Flow，還為此斥巨資30大洋買過一本書，簡單聊聊。

?

Stateflow是MATLAB/Simulink中的一個工具，用于建模和設計復雜的狀態機。它提供了一個圖形化界面，可以輕松地創建、編輯和調試狀態機模型，并自動生成相應的代碼。

Stateflow的主要功能包括以下幾個方面：

狀態機建模：Stateflow提供了豐富的建模元素，如狀態、轉換、事件、條件、動作等，可以直觀地描述系統的狀態和狀態之間的轉換關系。通過拖拽和連接這些建模元素，可以輕松地構建狀態機模型，并定義狀態之間的轉換條件和相應的動作。

事件驅動：Stateflow基于事件驅動的模型執行方式。系統的狀態轉換是通過觸發事件來驅動的。可以定義各種類型的事件，如輸入信號、定時器、條件判斷等。當滿足轉換條件時，Stateflow會相應地執行轉換并觸發相應的動作。

動作執行：在狀態轉換過程中，可以指定特定的動作或行為。這些動作可以是簡單的賦值操作、函數調用，或者是復雜的算法邏輯。Stateflow提供了豐富的動作語言和函數庫，可以靈活地定義狀態轉換過程中需要執行的動作。

狀態檢測：Stateflow提供了靈活的狀態檢測機制，可以檢測系統處于的當前狀態，以及特定條件下的狀態轉換。這些檢測可以用于系統的監控、故障檢測和安全保護等方面。

代碼生成：一旦完成狀態機的建模和設計，Stateflow可以自動生成相應的代碼，以便集成到實際的系統中。生成的代碼可以是C/C++代碼、MATLAB函數或Simulink模塊，可以與其他系統組件進行無縫集成。

State Flow開發界面 圖來源于網絡

開發界面如上圖所示，總的來說該軟件還是比較好用的，上手簡單，對于代碼能力要求較低，只要跑通流程后，后續開發和維護的難度較小。在調試方面，該軟件也非常出色，能夠拉出每個信號的值直接進行仿真驗證，有助于快速定位和解決問題。

剛畢業那陣幾個同屆的小姑娘在軟件組就是負責開發狀態機的，后來都做得有聲有色以至于現在都去了各大供應商卷了，畢竟這種技能一般還是在Tier 1零部件供應商那邊比較有用....

10.結語

以上是筆者總結的一些狀態機設計的要點，根據具體的應用場景和系統需求，可能會有其他特定的要求和注意事項。在設計狀態機時，重點是要充分理解系統的功能和目標，并與團隊成員進行密切合作，確保設計的狀態機能夠滿足系統的要求和預期效果。

在開發階段，設計也可以由簡到繁，先思考清楚有哪幾個狀態，確認每個狀態的跳轉條件應該包含哪些方面，然后根據項目進度不斷去迭代設計。筆者在項目中的設計狀態機時，在初版需要思考清楚系統邊界，但每個狀態的跳轉條件可能只有一個激活信號，或者車速信號；后續在開發不斷成熟的過程中，再逐步豐富設計，完善子狀態與跳轉條件，這樣能夠使開發既敏捷又穩重。

審核編輯：湯梓紅