10年前，我們經歷了從匯編語言到C語言的轉變，現在，我們是時候經歷從C語言到Simulink模型的轉變了……

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

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

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

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

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

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

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

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

你不是因為強迫癥要關注代碼嗎？

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

MC/DC覆蓋是否已經達到了100%？

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