10年前，我們經(jīng)歷了從匯編語言到C語言的轉(zhuǎn)變，現(xiàn)在，我們是時候經(jīng)歷從C語言到Simulink模型的轉(zhuǎn)變了……

從第一次看到這句話到現(xiàn)在又一個10年過去了，10年的時間，很多領(lǐng)域在控制算法軟件開發(fā)中已經(jīng)完成了從C語言到Simulink模型的轉(zhuǎn)變，當然，也有一些行業(yè)正在經(jīng)歷這樣的轉(zhuǎn)變，Simulink模型生成C代碼已經(jīng)成為非常成熟的技術(shù)。稍微有些遺憾的是，10年的時間，并沒有像匯編語言到C語言的轉(zhuǎn)變那樣，讓工程師們幾乎徹底忘掉匯編語言，即便是在基于模型設(shè)計最為成熟的汽車行業(yè)，也依然有工程師還有翻看自動生成代碼的習慣。

下面我來簡單說說和自動代碼生成相關(guān)的幾個原則：

拿正確的模型去生成代碼。代碼生成工具不具備糾錯功能，最完美的代碼生成工具，也只能忠實于模型的描述，并將其轉(zhuǎn)化為C代碼。如果我們不確定模型正確與否，那我們得到的代碼也同樣是不能確保正確。

不對自動生成的代碼做任何手工修改。從軟件工程的角度上來講，在基于模型的開發(fā)模式下，模型應該是我們工作和維護的工作產(chǎn)品，所有我們希望在代碼里實現(xiàn)的內(nèi)容，都應該通過模型或者模型配置去實現(xiàn)。如果我們手工修改自動生成的代碼，那么整個開發(fā)過程的可維護性就大大降低，每次面對模型發(fā)生變更后生成的代碼，我們都需要經(jīng)過手工修改。

不看代碼。不看代碼并不絕對，這里主要是指不看算法的實現(xiàn)代碼。在生成的.C和.H文件中，H文件作為和其他模塊的接口文件，還是會有工程師去看看你這個模塊到底定義了哪些全局的函數(shù)以及變量的。

管理你關(guān)心的數(shù)據(jù)。代碼生成階段的主要工作是數(shù)據(jù)管理工作，配置Simulink模型中需要關(guān)注的數(shù)據(jù)，這里主要是信號和參數(shù)，并將其按照項目的要求，生成為C代碼中的變量和參數(shù)。對于那些不需要關(guān)注的數(shù)據(jù)，不建議做過多的配置，只要按照默認的規(guī)則生成變量即可。再羅嗦一句，我們只管理我們關(guān)心的數(shù)據(jù)，比如，跟其他模塊之間的接口數(shù)據(jù)、需要標定的參數(shù)以及需要觀測的變量。

代碼的驗證。這里我要扯一下ISO 26262的大旗，沒辦法，ISO 26262出現(xiàn)之前，我也曾堅持在這種開發(fā)模式下無需對代碼做靜態(tài)驗證，也無需對代碼做動態(tài)測試，很多人難以接受我的觀點，現(xiàn)在好了，在客戶面前，我不再說這是我的觀點，而是ISO 26262里面的條款。傳統(tǒng)模式下的靜態(tài)、動態(tài)驗證不需要了，但是，代碼是否就無需驗證了呢？非也，代碼依然要經(jīng)過充分驗證，只是，在假設(shè)模型已經(jīng)經(jīng)過充分驗證的前提下，這里只要再驗證代碼和模型一致即可，驗證的方法，也就是我們非常熟悉的SIL和PIL，ISO 26262里面稱之為back-to-back測試。

我個人觀點，盡量不要在代碼生成這件事上耗費過多的心思。當然，“強迫癥患者”我也接觸過一些，雖說道理上講理解可以不看代碼，但還是忍不住要去關(guān)心代碼，希望代碼生成工具能夠生成出來自己希望看到的代碼。我是工程師，不是老中醫(yī)，我這里沒有藥到病除的方子，我希望能做到的是讓你的病情轉(zhuǎn)移。

你不是因為強迫癥要關(guān)注代碼嗎？

那你的模型測試是否充分？

MC/DC覆蓋是否已經(jīng)達到了100%？

強迫自己把模型測到盡可能充分吧，這才是有利于你產(chǎn)品品質(zhì)提升的事情。