1.定義狀態

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

不同的自動駕駛功能可能具有不同的狀態機，狀態的定義是由功能決定的，系統需要在不同的條件下正確地執行相應的行為和功能。同時，狀態機的設計原理也應該為系統的擴展和維護提供了便利，使得系統能夠適應不斷變化的需求和環境；比如在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（泊車完成）等狀態。

2.事件定義

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

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

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

3.轉換規則

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

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

4.動作和行為

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

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

5.錯誤處理

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

6.代碼生成與測試

**狀態機是一個比較有歷史的東西，很多廠家為了它做了相關的開發，方便我們使用和測試。

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

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

1. 狀態機建模 ：Stateflow提供了豐富的建模元素，如狀態、轉換、事件、條件、動作等，可以直觀地描述系統的狀態和狀態之間的轉換關系。通過拖拽和連接這些建模元素，可以輕松地構建狀態機模型，并定義狀態之間的轉換條件和相應的動作。
2. 事件驅動 ：Stateflow基于事件驅動的模型執行方式。系統的狀態轉換是通過觸發事件來驅動的。可以定義各種類型的事件，如輸入信號、定時器、條件判斷等。當滿足轉換條件時，Stateflow會相應地執行轉換并觸發相應的動作。
3. 動作執行 ：在狀態轉換過程中，可以指定特定的動作或行為。這些動作可以是簡單的賦值操作、函數調用，或者是復雜的算法邏輯。Stateflow提供了豐富的動作語言和函數庫，可以靈活地定義狀態轉換過程中需要執行的動作。
4. 狀態檢測 ：Stateflow提供了靈活的狀態檢測機制，可以檢測系統處于的當前狀態，以及特定條件下的狀態轉換。這些檢測可以用于系統的監控、故障檢測和安全保護等方面。
5. 代碼生成 ：一旦完成狀態機的建模和設計，Stateflow可以自動生成相應的代碼，以便集成到實際的系統中。生成的代碼可以是C/C++代碼、MATLAB函數或Simulink模塊，可以與其他系統組件進行無縫集成。

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

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

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

7.結語

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

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