在基于模型的開發(fā)（MBD）中，Stateflow是一款功能強大的工具，尤其是在汽車等對狀態(tài)機和復雜邏輯的精確控制要求極高的行業(yè)中。然而，要高效應用Stateflow，必須克服一些常見的挑戰(zhàn)，例如語法問題以及性能優(yōu)化方面的考量。

在本文中，我們將探討來自MES模賽思調查報告中的關鍵洞察，并提供可操作的優(yōu)化建議，助您優(yōu)化Stateflow模型的性能、可靠性和可維護性。

文章目錄

本文共四節(jié)，并附上主題直播活動預約鏈接：

• 行業(yè)專業(yè)人士如何使用Stateflow：調查報告
• 在使用Stateflow進行基于模型的開發(fā)（MBD）時面臨哪些挑戰(zhàn)？
• 掌握Stateflow的十大策略
• 總結：通過建模規(guī)范管理Stateflow的復雜性

行業(yè)專業(yè)人士如何使用Stateflow：調查報告

Stateflow在基于模型的開發(fā)（MBD）中的應用程度
為持續(xù)了解行業(yè)實踐，我們于2022年聯(lián)合來自梅賽德斯-奔馳集團、博世集團、大陸集團等企業(yè)的30位專家開展了聚焦Stateflow的專項調研。

我們首先詢問這些從事基于模型的開發(fā)（MBD）工作的專業(yè)人士是否使用Stateflow。

如下方柱狀圖所示，大多數用戶在其20%到50%的模型中使用了Stateflow。

圖片：受訪者在模型中使用Stateflow的比例

Stateflow首選動作語言

我們提出的第二個問題是關于用戶使用的動作語言（Action Language）。

如下方餅圖所示，多數用戶更傾向于使用MATLAB而非C語言進行動作腳本編寫。

這一結果反映出MATLAB的簡潔性，并且能夠更好地實現(xiàn)與Simulink生態(tài)系統(tǒng)的集成。

圖片：受訪者使用哪種動作語言（Action Language）？

使用Stateflow時遇到的常見障礙

第三，我們詢問了受訪者在使用Stateflow時遇到的挑戰(zhàn)。

最常見的障礙是缺乏相關知識（Lacking knowledge），值得注意的是，相當一部分用戶表示完全沒有遇到困難（None）。功能缺失（Missing features）是最少被提及的問題，這表明：通過加強培訓和完善文檔，可以幫助用戶更好地克服在使用Stateflow時遇到的困難。

圖片：受訪者在使用Stateflow時遇到的困難

使用Stateflow進行算術運算

第四個問題涉及是否使用Stateflow進行算術運算。

調查結果顯示，56%的受訪者對此表示肯定。這凸顯了Stateflow的多功能性，表明其能夠處理汽車系統(tǒng)中常見的復雜運算。

圖片：受訪者在Stateflow中使用算術運算的情況

最常用的Stateflow元素/模式

最后，我們調查了受訪者最常用的Stateflow元素和模式。

調查結果顯示，各類元素的使用分布整體較為均衡。其中，狀態(tài)圖（Statecharts）和條件動作（Condition actions）的使用率略高，而框（Boxes）的使用率最低。

這表明受訪者更傾向于采用結構化、基于條件的建模方式，特別是在系統(tǒng)中實現(xiàn)決策邏輯時。

圖片：Stateflow元素和模式的使用情況

關鍵發(fā)現(xiàn)

我們的調研再次證實，Stateflow已成為基于模型的開發(fā)（MBD）專業(yè)人員工具鏈中的重要組成部分。然而，調查結果也揭示了用戶在使用Stateflow的過程中面臨的若干挑戰(zhàn)。

基于這些反饋，MES模賽思團隊梳理出了常見痛點與改進方向。接下來，本文將深入剖析這些挑戰(zhàn)，并提供最佳實踐方案，助力提升Stateflow建模的效率與可靠性。

在使用Stateflow進行基于模型的開發(fā)（MBD）時面臨哪些挑戰(zhàn)？
使用Stateflow進行基于模型的開發(fā)（MBD）雖功能強大，但同時也存在影響可維護性和開發(fā)效率的挑戰(zhàn)。主要困難包括：

• 復雜性增加：隨著狀態(tài)轉移數量的增長，管理它們變得更加困難。
• 可擴展性問題：狀態(tài)機可能會迅速擴展，使模型變得更難閱讀和維護。
• 語法限制：為了確保一致性并防止錯誤，必須遵循嚴格的語法規(guī)則。
• 設計要求高：必須采用結構化的方法，并以規(guī)范化的方式使用Stateflow，以避免出現(xiàn)意外行為并提升模型的清晰度。

掌握Stateflow的十大策略

1. 確保轉移標簽語法正確

在Stateflow中使用正確的轉移標簽語法，既能提升模型的可讀性、可維護性和可預測性，又有助于在TargetLink等工具中生成準確的代碼。結構化的方法有助于創(chuàng)建清晰、可靠且易于維護的模型。

首先，讓我們對轉移標簽各部分的含義進行分解和解釋：

• 事件（Event）：指定觸發(fā)狀態(tài)轉移的事件。
• 條件（Condition）：指定一個布爾表達式，當其為true時，允許執(zhí)行該轉移。
• 條件動作（Condition Action）：當條件被評估為true時立即執(zhí)行的動作。
• 轉移動作（Transition Action）：在條件滿足且轉移目標被判定為有效后執(zhí)行。

如下展示了一種可能的語法。其格式為：

trigger [condition] {condition_action} /transition_action

需要注意的是，并不一定需要使用以上所有。通常建議避免使用事件（Event），而優(yōu)先使用條件（Condition），因為這種方式更為標準。此外，應在條件動作（Condition Action）或轉移動作（Transition Action）間做出選擇。

圖片：轉移標簽的正確語法示例

2. 遵循安全建模語言子集

基于建模規(guī)范：mes_slsf_3110 | misra_slsf_047_ab | misra_slsf_046_a

應避免使用歷史結點，因為它們可能導致：

• 導致模型解釋錯誤。
• 驗證流程復雜化。
• 隱藏功能，使系統(tǒng)更難理解和維護。

下圖展示了以H符號標識的歷史結點，這可能引發(fā)上述問題。

圖片：可能導致錯誤的歷史結點

還應避免使用事件（Events），因為它們可能：

• 導致遞歸問題。
• 造成非預期功能。
• 隱藏功能，導致模型難以理解和維護。

哪些Stateflow動作規(guī)范是安全的？
建議選擇一種動作類型（條件動作、轉移動作或狀態(tài)動作），并在整個模型中保持一致。

3.正確使用條件動作和轉移動作

基于建模規(guī)范：misra_slsf_045_e | misra_slsf_045_f | misra_slsf_045_g

避免在條件動作和轉移動作中寫入變量：在條件動作或轉移動作中修改變量可能導致非預期行為，并增加調試難度。

圖片：在條件或轉移動作中修改變量可能導致錯誤

避免在后續(xù)轉移中讀取由轉移動作寫入的變量：在轉移動作中被修改的變量不應在后續(xù)的轉移中被讀取，否則可能導致執(zhí)行順序不一致。

圖片：在轉移動作中讀取被修改的變量可能導致執(zhí)行不一致的情況

單一轉移動作寫入：為保持可預測的行為，一個變量在狀態(tài)之間轉移時應僅由單個轉移動作進行修改。

圖片：為保持可預測的行為，一個變量在狀態(tài)之間轉移時應僅由單個轉移動作進行修改

4. 避免在Stateflow中出現(xiàn)交叉轉移

基于建模規(guī)范：mes_slsf_3109

為了保持清晰性并防止圖形重疊，應避免在Stateflow圖中使用跨越狀態(tài)邊界的轉移。交叉的轉移會使圖表難以閱讀，從而增加誤解和錯誤的風險。

此外，布局雜亂會使調試和維護變得更加復雜，使得跟蹤執(zhí)行流程更加困難。通過對轉移進行合理組織并保持路徑清晰，可以提高模型的可讀性、可維護性以及整體可靠性。

在下圖中，可以看到明顯的跨越并行狀態(tài)邊界的轉移。避免這類交叉非常重要，因為它們可能導致混淆和潛在的建模錯誤。

圖片：跨越并行狀態(tài)邊界的轉移

5. 避免在浮點數中使用相等運算符

基于建模規(guī)范：jc_0481 | mes_sltl_002

應避免使用以下相等比較運算符比較浮點數：

• ==
• !=
• ~=
• <>

由于浮點數采用二進制表示，通常會產生微小的舍入誤差，因此精確比較不可靠。這可能導致錯誤的結果，因為兩個在數學上相等的值在內存中可能存在微小差異。因此，對于浮點數來說，不建議使用硬等值比較（嚴格逐位比較）。

6. 避免在Stateflow中出現(xiàn)回溯

基于建模規(guī)范：mes_sf_002 | misra_slsf_043_h

Stateflow不支持回溯。這說明所有已執(zhí)行的動作均保持有效，無論轉移路徑是否達到預期的最終狀態(tài)。如果某個轉移路徑未能到達有效的結束狀態(tài)，可能會導致非預期的行為。

為了避免這樣的問題，應確保每一個轉移路徑包括一個無條件的默認路徑。此外，應僅在轉移的最后一段使用條件動作，或改用轉移動作。

（如第三節(jié)所述，選擇使用轉移動作是有充分理由的。）

請見以下回溯問題示例：

圖片：Stateflow中回溯導致問題的示例

7. 遵循設置執(zhí)行順序的最佳實踐

基于建模規(guī)范：mes_is_0002

在Stateflow中，執(zhí)行順序通常按照順時針方向定義，尤其是在并行狀態(tài)中。即使是對圖形布局的細微調整，或新增一個元素，都可能導致執(zhí)行順序發(fā)生變化。

下圖展示了在Stateflow圖中引入一個新的事件（Event1）后，轉移的執(zhí)行順序如何發(fā)生變化，強調了手動指定執(zhí)行順序的重要性。

圖片：添加Event1會改變轉移順序，因此建議手動控制

8. 避免使用全局Stateflow函數

基于建模規(guī)范：mes_slsf_3106

將Stateflow函數在各自的圖中本地定義是保持模塊化并防止產生非預期交互的推薦方法。

使用“導出圖表級函數（設為全局）”功能可以使圖形函數在模型的任何圖中被全局訪問。然而，這些函數難以追蹤（僅能通過搜索函數名稱查找），并且會導致行為不透明。

此外，啟用“允許Simulink調用導出函數”（自R2014b起可用）會增加函數管理和數據流方面的復雜性，因此不建議啟用該選項。

圖片：避免選擇“允許Simulink調用導出函數”選項

9. 避免遞歸循環(huán)

基于建模規(guī)范：jc_0804

確保Stateflow中的圖形函數既不以遞歸方式定義，也不調用其他圖形函數，對于防止非預期行為并保持模型的完整性至關重要。遞歸調用可能導致無限循環(huán)、棧溢出，并增加調試和維護的復雜性。

下圖展示了Stateflow圖形函數中的遞歸循環(huán)問題。當執(zhí)行func1(x)時，它會調用func2(x)，而func2(x)又調用func1(x)，從而形成無限遞歸。為避免此問題，建議在Stateflow圖形函數中避免直接或間接的遞歸函數調用。

圖片：Stateflow中的遞歸循環(huán)，函數func1與func2相互調用，導致無限遞歸

10. 明確定義輸入變量以實現(xiàn)無縫集成
在使用TargetLink、Simulink以及Stateflow時，明確定義輸入變量對于維持接口的一致性和良好的結構十分重要。來自dSPACE的TargetLink Property Manager（如下圖所示）能夠幫助管理這些變量定義，確保模型與最終實現(xiàn)之間的一致性。

圖片：dSPACE的TargetLink Property Manager

總結：通過建模規(guī)范管理Stateflow的復雜性

Stateflow為用戶提供了強大的建模功能，但如果使用不當，也可能帶來風險。

為了更好地管理復雜性，請遵循以下最佳實踐：

• 保持簡單！避免在轉移和狀態(tài)邏輯中引入不必要的復雜性。
• 在Simulink中執(zhí)行算術運算：否則，圖表可能會變得過于龐大而難以控制。
• 遵循既定的建模規(guī)范，以避免出現(xiàn)非預期行為和容易出錯的模式。
• 保持布局清晰且結構化，提高模型的可讀性和可維護性。
• 使用MES Model Examiner? (MXAM)等工具，自動化檢查模型是否符合建模規(guī)范。

通過遵循這些最佳實踐，可以構建穩(wěn)健、高效且易于維護的Stateflow模型，并實現(xiàn)與Simulink和TargetLink的無縫集成。

歡迎您申請MXAM免費試用，如您有任何疑問，也歡迎與北匯信息取得聯(lián)系，我們竭誠為您服務！