MBD下的軟件開發模式

2024年3月1日發(作者：公園里)

MBD模式下的軟件開發流程介紹

王淳

（聯創汽車電子有限公司，上海 浦東 201203）

【摘要】

以模型為基礎的軟件開發，我們稱之為MBD（Model-Bad Design）。和傳統的嵌入式軟件開發模式相比，MBD模式無疑是一個巨大的進步，肯定會在今后幾年內普及，并完全代替現有嵌入式軟件的開發模式。

【主題詞】MBD，軟件開發流程及工具，MIL，SIL，PIL，HIL

一、變革的力量：

上次的變革：

90年代，國內嵌入式軟件開發還停留在匯編語言的層次，匯編語言雖然靈活、效率高，但是在處理浮點計算、復雜邏輯運算等問題上，軟件開發的工作量相當大。而同期國外已經大面積普及了以C語言為基礎的嵌入式系統開發流程。當年很多程序員對于C編譯器的正確性、可靠性、效率還都抱有過懷疑的態度，但是隨著keil、tasking等公司不斷推出的優質的C編譯器，這種疑慮很快被打消。C代碼不需要程序員關心浮點算法；對復雜邏輯的設計也很方便；而且針對于嵌入系統硬件資源有限的情況，很多專用的C編譯器都提供各種優化選項；通過對堆棧的靈活運用，解決了RAM空間不足的問題；代碼的可移植性、可繼承性也遠強于匯編語言。

短短幾年時間，C語言編程在國內嵌入式系統的開發中已經普及。

先進工具可以大大提高勞動生產率，這一點在這次變革中體現的非常明顯。

現在的革命：

而基于模型進行嵌入式系統開發流程，其優越性以及對傳統開發方式的顛覆，一點也不比當年的變革小。

對于嵌入式系統開發而言，存在以下一些具體的問題：

? 現在嵌入式系統的復雜程度，比起幾年前又上了一個臺階，傳統C語言開發采用流程圖的輔助設計方式，已經很難表達復雜的程序邏輯；

? 以手工編寫C代碼，還是會出現很多低級錯誤；

? 現在的系統開發周期越來越短，再沿用過去那種硬件設計->軟件設計->集成調試的流程，無法開展硬件和軟件的并行開發；

? 隨著系統復雜性的增加，用戶對最終功能的確定也越來越模糊，很多情況下，用戶都需要在得到樣機后，才能開展測試，并提出修改意見，從而導致開發的反復，大大增加了開發成本和時間。

? 雖然C代碼已經在各個嵌入平臺上普及，但是因為代碼設計者設計思路的局限，加之傳統流程圖的單線設計思路，軟件模塊的可繼承性還是比較差。

國外的企業已經從90年代后期，逐步開始采用MBD開發流程，使用建模工具對復雜嵌入式系統進行分析設計。隨著建模工具及配套設備的完善，使得自動代碼生成的工具鏈也逐漸清晰。現在已經有很多極復雜系統，如電噴控制器等等，全部采用了MBD的設計流程。MBD工具鏈的可靠性、穩定性已經無需懷疑。

? 以建模工具對復雜邏輯進行設計、分析、仿真，使得系統需求分析和軟硬件開

?

?

?

?

?

發結合得更加緊密，系統分析不再僅僅停留在文檔階段，而是直接和設計掛鉤。

采用了MBD的設計流程后，在硬件設計的同時，軟件設計即可全面展開，大大縮短了開發周期。

從軟件開發的第一步開始，工程師就可以觀察結果，調試邏輯，大大加快調試進度。

采用成熟工具，可以實現代碼自動生成，完全避免了手工編碼的低級錯誤。并且在設計修改后，極短時間內即可重建系統軟件，而無需進行多次反復測試。

采用建模工具及輔助設備，可以在模型建立后，立即實現快速原型仿真，用戶馬上可以看到設計運行的結果，工具可以協助用戶及時修改需求，在最短的時間內完善需求設計。

模型的可移植性，遠強于C代碼，可以方便的建立公司內的系統設計模型庫，節約開發成本。

二、MBD開發流程的環節和作用：

2.1 系統設計定義階段

系統設計定義階段的目的是：

針對用戶提出的初步需求，逐步細分，將功能需求拆解為可實現功能定義，并且建立系統級模型，包括控制器模型（controller）、被控對象模型（plant）、測試案例模型（reference

position）。

其中，測試用案例模型和被控對象模型，是系統設計工程師根據用戶需求設計的。在整個開發流程中會多次使用，也是系統設計定義階段重點關注的內容。

系統設計定義環節本身也將在整個設計流程中反復迭代，用戶需求會在不同的階段逐步完善，這些修改最終都需要反饋到系統設計定義中，主要是反饋至測試用案例模型中。

控制器模型也在系統設計定義階段直接輸出，這樣后續的工作都可以在統一的模型上完成，而不需要在代碼、模型、文檔之間頻繁切換，一方面可以節約時間，一方面可以始終得到最準確的需求文檔。

控制器模型的詳細設計可以由后續的環節完成，在系統設計定義階段可以只定義為頂層模型。不必細究。

系統設計定義階段，建議使用MATLAB提供的Simulink Verification and Validation(V&V)工具，使用這個模塊，可以將需求與模型關聯起來，通過Signal Builder（Simulink Library

Browr->Sources->Signal Builder）來設計測試案例，通過V&V工具，對模型執行覆蓋度分析；也可以用工具（Design Verifier）自動為模型生成符合模型覆蓋度要求的測試用例。這種測試用例和需求文檔（doors），可以做一一對應的關聯。

2.2 模型設計階段

在MBD開發流程中，模型設計階段的主要工作就是設計控制器模型，根據系統需求的要求，采用MIL技術，對控制器的控制邏輯進行細化。

細化的過程從頂層模型開始，直接使用系統設計定義階段設計的案例模型和被控對象模型，對細化后的控制器模型進行仿真測試，這個步驟就是MIL(Model In Loop)模型在環仿真。

MIL的最終結果，是得到一個可以實現所有控制邏輯的控制器模型，這個模型可以不必關系具體的硬件接口，因為被控對象模型及案例激勵都是以模型形式存在的，整個環路的仿真可以直接在MATLAB環境下運行。

模型設計階段的目的是：

算法設計，完成算法有效性檢驗；

比例擴放設計，溢出檢測，為后續定點化取得基礎數據；

用例跟蹤，對測試用例的結果進行記錄，并反饋不合理值，修改系統設計定義。

模型設計階段，整個模型都以浮點運行，所以保證了計算的精度和合理的取值范圍。建議使用第三方提供的RCP工具，如dSpace公司的AUTOBOX等，對MIL的結果進行實際驗證。

這類工具不需進行模型定點化，硬件IO定制也非常簡單，可很

方便地將模型下載運行。通過簡單電路調整，即能直接控制被控對象。

在RCP工具的幫助下，軟件設計階段時用戶已經能夠參與系統開發，直觀地看到系統運行的結果，并及時地修改完善系統需求。

2.3 C代碼生成及調試階段

在模型開發完畢后，需要將PC機上運行的浮點模型，轉換為可以在定制嵌入CPU上運行的模型代碼，考慮到現階段嵌入式CPU的資源還不夠豐富，系統開發對成本的限制需求等等，直接在CPU上進行浮點運算的方案還是比較少。

C代碼生成及調試階段，要通過SIL（software in Loop），對模型進行定點化驗證。

所謂SIL，就是在保證代碼效率、兼顧計算精度和數據表達范圍的情況下，采用auto scaling等技術，將模型進行定點化。然后用自動代碼生成工具，把模型轉換為標準C代碼，再將C代碼封裝為可以在MATLAB環境中執行的模塊，代替原有浮點模型，進行軟件在環仿真。

浮點運算和定點運算在精度和數據表達范圍上存在巨大差異，不進行驗證直接轉換模型肯定會帶來無法估量的誤差；MATLAB模型中，如果不加強制限制，各個模塊的計算順序是由MATLAB自己設定的，可能和工程師的看法完全不同；而在MATLAB的模型內，對各個環節的算法，是以MATLAB自己的M語言、庫函數、采樣周期、時序結構來進行的，其計算步長可能是變化的，而這些都和實際嵌入式C代碼存在很大差異（由簡單的積分環節組成的常微分方程，在MATLAB中可能采用龍格庫塔法等迭代算法進行計算，而在普通嵌入式C代碼中，總是對一個個的積分進行累加計算），這種算法上的差異，也會導致最終結果的完全不同，這也是必須要進行SIL仿真的原因。

這個階段非常關鍵，也是國內走MBD路線進行嵌入式系統軟件開發時比較容易忽略的一環。正常情況下，設計一個可以正確運行的模型并不難，但是要進入工程設計，將模型轉換為實際的嵌入式C代碼，就必須按部就班地完成以上步驟。

在SIL環節，采用自動代碼生成工具，將控制器模型轉換為標準C代碼，算法和時序都可以由工程師確定，再將模型生成的C代碼（僅限于控制邏輯部分，IO部分暫不包括），以S函數的方式（或其他方式）封裝為模塊，這種模塊可以直接在MATLAB里運行，其內部運行機制取決于C代碼本身。然后再取代原模型中的控制器模型，聯合測試用案例模型和被控對象模型，進行仿真。這一步目的是為了檢查定點化以后代碼的計算精度、算法是否合理、是否產生溢出等，然后及時修改原模型，反復進行SIL仿真后，保證模型定點化的正確性。

C代碼生成及調試階段，建議使用MATLAB內自帶的RTW，或者dSpace公司的TargetLink等工具。

2.4 硬件代碼生成調試階段

在這個階段，硬件設計必須已經完成。

所謂PIL，就是將經過SIL設計的模型，在工具的協助下，生成可以在指定CPU上運行的嵌入式C代碼，并下載至指定CPU的DEMO板上直接運行，通過數據接口，和MATLAB上的測試用案例模型及被控對象模型進行數據交互，進一步驗證代碼準確性。

因為SIL環節的C代碼是在INTEL系列CPU的PC機上運行的，雖然C代碼的正確性得到了驗證，但是如果轉換為匯編機器碼，INTEL芯片代碼和我們嵌入式系統的指定芯片的代碼還是有差別的。進行PIL的目的就是為了檢驗這兩種代碼間差異是否可以接受。同時，在PIL環節，模型生成的嵌入式C代碼直接在指定CPU上運行，模型邏輯控制部分的代碼和最終實際運行的代碼完全一致，并且運行環境也大體相當，可以對代碼時序的精確性進行進一步驗證。

PIL的技術過程是，建模工具提供接口，通過串口之類的通道，和下載到DEMO板上的控制邏輯代碼進行交互，把測試用例模型的輸出數據下載到DEMO板，把控制邏輯代碼的計算結果返回到被控對象模型，形成一個完整的閉環仿真。PIL需要有特殊硬件支持，部分芯片可能無法進行PIL環節仿真。

接下來需要把經過SIL、PIL驗證的模型，生成特定CPU的機器碼，再加入部分和硬件相關的IO驅動代碼，一起編譯，下載至我們自己設計的硬件運行。主要目的，是將自動生成的代碼將和硬件一起聯調，解決IO驅動和模型代碼之間的接口問題，并形成穩定的IO驅動代碼庫，保證后續修改模型時，不用再次修改底層驅動。

這個階段建議使用RTW及TargetLink，以及專用的C編譯器、PIL仿真用DEMO板。

2.5 硬件在環

HIL（hardware in Loop），是指控制器采用實際硬件，加上由模型生成的C代碼（也許有部分手工設計的底層驅動程序）。而被控對象，可以由模型仿真實現。這個步驟主要是針對那些被控對象復雜、實驗費用高昂、有著繁瑣測試邏輯的系統設計而言。在這類系統中，采用模型仿真被控對象，可以大大加快實驗進度，覆蓋診斷案例（如發動機飛車處理等）。如果被控對象簡單，可以不用軟件進行仿真，而采用labcar之類的實物直接驗證。

HIL階段，可以發現設計中被忽略的問題，如實際線纜的干擾、人工輸入的錯誤等等，將這類問題及處理方法需要及時反饋到測試用例、被控對象模型、控制器模型中，進一步完善系統設計定義。

硬件在環階段，建議使用labcar或者AUTOBOX之類工具，模擬實際被控對象，自動測試、自動記錄，對控制邏輯進行覆蓋性測試。

2.6 實車測試

實車測試階段和傳統開發流程的實車測試階段并無區別，只是在發現問題后，需要返回對系統定義設計階段的相關模型進行修改，并在控制器模型的基礎上，修改控制策略，解決問題，經過仿真迭代后再回到實車測試。這樣可以保證模型的正確性，代碼和模型的統一。

三、總結語

在整個設計開發流程中，所有的文檔都可從模型工具直接生成，任何對模型的修改，都能立即反應到文檔中。模型本身也可以作為一個最詳細設計文檔，只要加入適當的變量說明和必要注釋，這種文檔包含的內容非常清晰，其可理解性、準確性、一致性，遠遠超過普通的文本文檔。

MBD模式下的嵌入式軟件開發流程，雖然看起來很復雜，但是只要正確使用合理的工具鏈，諸如MIL、SIL、PIL、HIL等環節，并不會占用研發工程師的太多時間。整個工具鏈合理配置后，所有的工作都自動進行，大大提高了測試效率。

采用MBD模式下的嵌入式軟件開發流程，上面介紹的環節，都強調“在環仿真”的概念，設計修改好的模型，都需要在有控制對象、固定的測試用例的條件下，反復多次仿真驗證，保證設計一貫性、完整性、正確性。

浮點模型和定點代碼之間的轉換，以及和硬件相關部分代碼的集成，是傳統開發流程中不存在的部分，需要小心謹慎。

工程師的主要工作集中在模型設計、仿真驗證、以及和用戶溝通上，不再去擔心代碼本身質量。

模塊化的測試用例、模塊化的被控對象、模塊化的控制邏輯，都以模型的形式存在，不同的項目間可以很方便的移植，最終在硬件代碼生成調試階段，和特定編譯器的集成即可。

【參考文獻】

[1] Software Development Process for a Drive-by-wire Powertrain——DaimlerChrysler AG

2002

[2] Using Simulink——The MathWorks Inc.

作者簡介：王淳，男，畢業于哈爾濱工業大學自動控制專業,研究方向為發動機控制器。

通訊地址：中國上海祖沖之路899號11號樓

郵編：201203

聯系電話：（0）50797828-639(王淳)

Email:*****************