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

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

文章目錄

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

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

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

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

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

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

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

Stateflow首選動(dòng)作語言

我們提出的第二個(gè)問題是關(guān)于用戶使用的動(dòng)作語言（Action Language）。

如下方餅圖所示，多數(shù)用戶更傾向于使用MATLAB而非C語言進(jìn)行動(dòng)作腳本編寫。

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

圖片：受訪者使用哪種動(dòng)作語言（Action Language）？

使用Stateflow時(shí)遇到的常見障礙

第三，我們?cè)儐柫耸茉L者在使用Stateflow時(shí)遇到的挑戰(zhàn)。

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

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

使用Stateflow進(jìn)行算術(shù)運(yùn)算

第四個(gè)問題涉及是否使用Stateflow進(jìn)行算術(shù)運(yùn)算。

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

圖片：受訪者在Stateflow中使用算術(shù)運(yùn)算的情況

最常用的Stateflow元素/模式

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

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

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

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

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

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

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

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

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

掌握Stateflow的十大策略

1. 確保轉(zhuǎn)移標(biāo)簽語法正確

在Stateflow中使用正確的轉(zhuǎn)移標(biāo)簽語法，既能提升模型的可讀性、可維護(hù)性和可預(yù)測(cè)性，又有助于在TargetLink等工具中生成準(zhǔn)確的代碼。結(jié)構(gòu)化的方法有助于創(chuàng)建清晰、可靠且易于維護(hù)的模型。

首先，讓我們對(duì)轉(zhuǎn)移標(biāo)簽各部分的含義進(jìn)行分解和解釋：

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

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

trigger [condition] {condition_action} /transition_action

需要注意的是，并不一定需要使用以上所有。通常建議避免使用事件（Event），而優(yōu)先使用條件（Condition），因?yàn)檫@種方式更為標(biāo)準(zhǔn)。此外，應(yīng)在條件動(dòng)作（Condition Action）或轉(zhuǎn)移動(dòng)作（Transition Action）間做出選擇。

圖片：轉(zhuǎn)移標(biāo)簽的正確語法示例

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

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

應(yīng)避免使用歷史結(jié)點(diǎn)，因?yàn)樗鼈兛赡軐?dǎo)致：

• 導(dǎo)致模型解釋錯(cuò)誤。
• 驗(yàn)證流程復(fù)雜化。
• 隱藏功能，使系統(tǒng)更難理解和維護(hù)。

下圖展示了以H符號(hào)標(biāo)識(shí)的歷史結(jié)點(diǎn)，這可能引發(fā)上述問題。

圖片：可能導(dǎo)致錯(cuò)誤的歷史結(jié)點(diǎn)

還應(yīng)避免使用事件（Events），因?yàn)樗鼈兛赡埽?/p>

• 導(dǎo)致遞歸問題。
• 造成非預(yù)期功能。
• 隱藏功能，導(dǎo)致模型難以理解和維護(hù)。

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

3.正確使用條件動(dòng)作和轉(zhuǎn)移動(dòng)作

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

避免在條件動(dòng)作和轉(zhuǎn)移動(dòng)作中寫入變量：在條件動(dòng)作或轉(zhuǎn)移動(dòng)作中修改變量可能導(dǎo)致非預(yù)期行為，并增加調(diào)試難度。

圖片：在條件或轉(zhuǎn)移動(dòng)作中修改變量可能導(dǎo)致錯(cuò)誤

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

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

單一轉(zhuǎn)移動(dòng)作寫入：為保持可預(yù)測(cè)的行為，一個(gè)變量在狀態(tài)之間轉(zhuǎn)移時(shí)應(yīng)僅由單個(gè)轉(zhuǎn)移動(dòng)作進(jìn)行修改。

圖片：為保持可預(yù)測(cè)的行為，一個(gè)變量在狀態(tài)之間轉(zhuǎn)移時(shí)應(yīng)僅由單個(gè)轉(zhuǎn)移動(dòng)作進(jìn)行修改

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

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

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

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

在下圖中，可以看到明顯的跨越并行狀態(tài)邊界的轉(zhuǎn)移。避免這類交叉非常重要，因?yàn)樗鼈兛赡軐?dǎo)致混淆和潛在的建模錯(cuò)誤。

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

5. 避免在浮點(diǎn)數(shù)中使用相等運(yùn)算符

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

應(yīng)避免使用以下相等比較運(yùn)算符比較浮點(diǎn)數(shù)：

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

由于浮點(diǎn)數(shù)采用二進(jìn)制表示，通常會(huì)產(chǎn)生微小的舍入誤差，因此精確比較不可靠。這可能導(dǎo)致錯(cuò)誤的結(jié)果，因?yàn)閮蓚€(gè)在數(shù)學(xué)上相等的值在內(nèi)存中可能存在微小差異。因此，對(duì)于浮點(diǎn)數(shù)來說，不建議使用硬等值比較（嚴(yán)格逐位比較）。

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

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

Stateflow不支持回溯。這說明所有已執(zhí)行的動(dòng)作均保持有效，無論轉(zhuǎn)移路徑是否達(dá)到預(yù)期的最終狀態(tài)。如果某個(gè)轉(zhuǎn)移路徑未能到達(dá)有效的結(jié)束狀態(tài)，可能會(huì)導(dǎo)致非預(yù)期的行為。

為了避免這樣的問題，應(yīng)確保每一個(gè)轉(zhuǎn)移路徑包括一個(gè)無條件的默認(rèn)路徑。此外，應(yīng)僅在轉(zhuǎn)移的最后一段使用條件動(dòng)作，或改用轉(zhuǎn)移動(dòng)作。

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

請(qǐng)見以下回溯問題示例：

圖片：Stateflow中回溯導(dǎo)致問題的示例

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

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

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

下圖展示了在Stateflow圖中引入一個(gè)新的事件（Event1）后，轉(zhuǎn)移的執(zhí)行順序如何發(fā)生變化，強(qiáng)調(diào)了手動(dòng)指定執(zhí)行順序的重要性。

圖片：添加Event1會(huì)改變轉(zhuǎn)移順序，因此建議手動(dòng)控制

8. 避免使用全局Stateflow函數(shù)

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

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

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

此外，啟用“允許Simulink調(diào)用導(dǎo)出函數(shù)”（自R2014b起可用）會(huì)增加函數(shù)管理和數(shù)據(jù)流方面的復(fù)雜性，因此不建議啟用該選項(xiàng)。

圖片：避免選擇“允許Simulink調(diào)用導(dǎo)出函數(shù)”選項(xiàng)

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

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

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

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

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

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

圖片：dSPACE的TargetLink Property Manager

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

Stateflow為用戶提供了強(qiáng)大的建模功能，但如果使用不當(dāng)，也可能帶來風(fēng)險(xiǎn)。

為了更好地管理復(fù)雜性，請(qǐng)遵循以下最佳實(shí)踐：

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

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

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