什麼是自動代碼生成技術？這種技術有什麼優點？

12-31

新年首答！這個話題很有意思，正好詳細解釋一下。

1. 什麼是自動代碼生成技術？或者說什麼是基於模型的設計？

在汽車行業，2010年之前，大多數控制軟體，比如發動機控制軟體，自動變速箱控制軟體，車身控制軟體等等，都是手寫C代碼的。歐洲汽車行業使用很多外包公司來進行這項重複性的腦力活動，甚至把很多寫代碼的活兒外包到印度降低成本。一個大型軟體比如發動機控制軟體，甚至需要超過上百個碼農在像網吧一樣的大辦公室裏手動撰寫不同模塊的代碼，之後再進行拼裝。

2010年之後到現在，在汽車行業手寫C代碼的情況已經非常少了，如下表所示來自Infineon的預測，到2020年手動C代碼在整個汽車行業所佔的比例會只剩下10%左右，就這個估計我覺得還是保守的，其實現在除了少數一些發展中的車企和微型公司，C代碼已經很罕見了。

那麼如果不用手寫C代碼，汽車控制軟體編譯前的代碼怎麼得到呢？就是通過自動代碼生成技術，或者說基於模型的設計。如果你用過類似 Matlab 中的 Simulink 或者其他圖形化的語言就會知道，在建模和模擬的過程中很少直接使用 C 代碼。Simulink對比C代碼，就好像 Windows 操作系統對比 DOS 操作系統一樣，一個是圖形化的控制，一個是基於命令行。Simulink 的圖形和 C 代碼之間是可以雙向轉換的，比如下圖這段代碼：

那麼在這個背景下， Simulink 可以搭配專門的自動代碼生成工具，比如Targetlink或者Matlab自己的Embedded Coder，軟體設計者只需要編寫圖形化的 Simulink 代碼，之後通過上面說到的兩個工具之一自動生成對應的C代碼，最後可以直接編譯再刷寫到具體的電子控制器上使用。

2. 這種技術有什麼優點？

在使用自動代碼生成技術前，汽車控制軟體的主要一部分開發流程是下圖這樣的：

首先系統和功能設計工程師需要制定軟體的功能和需求，並設計控制模型，系統和功能設計工程師可能完全不懂C代碼。
之後功能設計工程師提供具體的需求和設計說明書給軟體工程師或者外包公司的碼農。
碼農將系統工程師的設計理念從模型轉化為C代碼，編譯後刷寫到電子控制器。
最後系統工程師或者測試工程師再拿到刷寫好的軟體去測試自己設計的功能。

而使用了自動代碼生成技術之後，軟體開發流程就成了下面這樣：

碼農下崗了。
軟體開發中，功能設計工程師不再需要浪費時間給碼農解釋自己的設計理念，也不需要等待碼農輸出C代碼，只需要使用Targetlink，Embedded coder加上其他軟體工具來自動生成和編譯圖形化的代碼。

那麼相對於上面的手動C代碼，基於模型的設計有顯而易見的巨大進步：

節約了閉環設計中無數的時間和人力成本，那一房間上百個碼農都可以節約下來了。
系統和功能設計工程師可以獨立完成軟體的輸出，可以很容易避免因為技術文檔描述不準確或者歧義而導致的從功能到代碼的錯誤設計。
軟體功能修改後可以快速自動生成代碼而不需要經過複雜的流程由碼農來做修改。
軟體一致性不會像以前一樣因為使用不同的碼農而不同，代碼也會由自動工具統一優化。
圖形化的軟體設計和Windows一樣更易懂，類似Simulink中完整的診斷和查詢顯示功能也可以更容易對軟體進行糾錯，找到bugs。

基於模型的設計和自動代碼生成技術對於包括汽車和航空航天在內的很多行業可以說是革命性的進步，也是目前汽車行業最多金和最熱門的技術研發領域。

關於其他基於模型的軟體設計以及設計流程、工具鏈的超多乾貨，請關注我兩周後的 Live：知乎 Live 入口

時候把老胡的文章貼出來了~（以下文章摘自老胡的公眾號，基於模型設計）

---------------------------------------------------------------------------------------------------------------

為什麼要基於模型設計？——董淑成

嵌入式軟體開發為什麼要使用基於模型的設計？

對這個問題，最不希望聽到的回答是：因為GM在使用基於模型設計，因為BMW在使用基於模型設計，所以我們也要使用基於模型設計...,好吧，或許他們可以作為借鑒，但是，我們是否認真想過：基於模型的設計能給我的開發帶來什麼樣的好處？

弄清這個問題，是我們在後續有效使用基於模型設計開發嵌入式軟體的前提。

這裡我引用一下若干年前MathWorks公司CEO Jack Little的說法，在嵌入式軟體開發過程中，基於模型的設計至少可以給我們帶來四個方面的好處：

1. 圖形化設計

對於基於模型的設計來講，圖形化設計是天然的、固有的。圖形化的優勢，工程師們都非常清楚，明確、清晰、唯一，便於交流、便於維護，這也是為什麼就算我們不用基於模型設計的方式開發軟體，也需要在設計文檔中畫流程圖、狀態機的原因。

需要注意的是，我們需要把Simulink模型畫到清晰、明確，便於交流、便於維護。

2. 早期驗證

話說軟體開發過程中，bug的引入難以避免，人非聖賢、孰能無過，引入bug不可怕，能否儘快發現bug對整個開發過程至關重要。這裡提到「早期」，什麼是「早期」？你某一個階段的工作產品出來之後，緊跟著就要做驗證工作。對於早期驗證，以前的方式比較單一，通常我們使用評審的方式去實現最早期的驗證，以至於PeerReview在很多公司的流程中被固化下來了，寫完文檔要評審，做完設計要評審，寫完代碼還要評審，寫好測試用例也要評審。如果我們翻看一些軟體工程的教材或者文獻，大家對評審的評價非常高，因為在這個階段每發現一個錯誤，都會給後續的開發過程帶來很多便利，但遺憾的是，評審的效率通常不高。

使用基於模型設計去開發軟體，除了評審，我們還有更高效的早期驗證方式，包括Simulink模型本身固有的模擬以及通過形式化方法工具對模型進行形式化的分析。

3. 代碼的自動生成

自動生成代碼通常是使用基於模型設計進行軟體開發的古今中外的工程師最容易關注的優勢。代碼都不用寫了，「碼農」從此跟我無干，還有什麼比這事更美好的呢？確實，從開發效率來講，這個環節，對於效率的提升，是無法量化的，原本需要一個月時間寫完的代碼，現在可能只要一個上午或者兩個小時就可以搞定，誰幫我算一下工作效率提升了多少？不少人對代碼生成的開發效率沒有質疑，但對生成代碼的代碼效率卻不夠放心。這事，很多人都比過，SAE上也能找到這樣的論文，通俗點講，從效率上，生成的代碼在各種效率上（RAM、ROM、執行時間等）不比大學畢業後工作了5年的工程師差。當然，遇到那種「寫代碼像寫詩一樣」的工程師，代碼生成工具還是要甘拜下風的，話說，「寫代碼像寫詩一樣」的工程師我們有見過幾人？

4. 文檔自動化

對於文檔，我說兩點：工程師大多不願意寫文檔，而開發過程中文檔又是不可缺少的，有三個字足以證明上面兩條，那就是「補文檔」。在基於模型設計的開發過程中，我們可以通過軟體讀取模型中相關信息並自動創建文檔，實現文檔自動化。

上面提到了基於模型設計能給我們帶來的好處，因為基於模型的設計可以給我帶來上述好處，所以我們才應該使用基於模型的設計。

除上述優勢之外，軟體規模的爆炸式增長也是使用基於模型設計開發軟體的一個重要原因，我想很多人都會有很深刻的體會，近年來軟體規模在快速膨脹，各種機電產品的功能、性能大多通過軟體的方式去實現、去提升。

NASA做過研究，汽車、航天器等產品的代碼量這些年都在呈指數級增加，戰鬥機從1960年的F-4約8%的功能由軟體實現到2000年的F-22約有80%的功能由軟體實現，其他機電系統也差不多。軟體規模的快速膨脹，給驗證和實現都帶來了很大困難，原有的開發模式難以應對，新的開發模式必然會出現。即便是沒有MathWorks、沒有Simulink，也會有其他產品去實現基於模型的設計，這不是單單一個MathWorks能夠推動的，而是技術發展到這一階段的必然。

為什麼要基於模型設計？-基於模型的設計

其實我們每天都在用的編譯器、虛擬機都是「代碼生成器」，目的當然是幫助你站在更高的抽象層次去解決問題，但使用代碼生成器也應該遵守一個原則 —— 生成出來的代碼不應進入版本控制、不應修改生成的代碼，甚至都不要嘗試去閱讀生成的代碼，否則就會適得其反，再次陷回更低層次的代碼。

1. 基於模型設計主要還是迭代方便，模擬方便，可以快速驗證演算法。

2. 和配套工具鏈結合，文檔等可以直接生成減少工作量。

3. 如果不用模擬功能的話，就是一個圖形化寫c代碼的工具，浪費最精華的功能。

4. 系統工程師多少還是需要了解一點c語言知識

5. 目前底層和故障管理，診斷通信，BootLoader還需要手工寫，效率最高，不過隨著晶元性能提高，部分可以用模型替代。

6.合適的工具做合適事情，不要妄想一個工具解決所有問題

以上。

作為曾經的汽車系統攻城獅，先拋個磚:

個人認為自動代碼生成技術是一種基於模型的工具，這種工具要求先根據需求設計控制演算法(模型)，然後按照工具和ECU的要求設置各種輸入輸出變數和中間量的屬性，比如數據類型是標定量還是變數、全局變數還是模塊內變數、物理值和ECU二進位值的轉化公式等，然後利用工具自動生成代碼進行後期的集成和測試等工作。

相比於手動代碼，自動代碼的效率非常高，而且出錯率低，便於模塊升級和平台化。

一般來說Simulink是汽車行業比較常用的自動代碼工具，當然有些供應商會有自己開發的工具，如BOSCH的ASCET。

不過自動代碼生成畢竟只是一個工具或者手段，核心內容還是在控制演算法的設計上，這才是最有技術含量的工作。

推薦一個可視化的自動化代碼工具，基於流程圖，採用拖拽控制項，幾乎零學習成本，相當靈活強大，生成任何語言、框架代碼，不妨試試，萬能代碼生成器

代碼自動生成只是汽車電控開發的一個環節而已，顧名思義就是自動生成代碼，不像過去那樣人工手寫C代碼。simulink自帶的embedded coder模塊能自動生成代碼，覆蓋範圍廣，普通的嵌入式開發可以運用這個模塊來生成代碼。但車輛的電控系統相當複雜，很多汽車公司會用dSPACE公司的targetlink軟體，這套軟體比較貴但是行業標杆。

目前自動生成代碼還是需要人工手寫底端驅動的，因為不同的晶元的初始化、埠等設置都是不同的。汽車行業正在減少人工寫代碼的工作量，例如現在的AUTOSAR架構，它不僅能讓軟體的結構標準化，也能避免重複性的編寫手工代碼。

代碼自動生成可以看成簡化人類工作的一個工具，結合汽車電控V流程開發會有更加深刻的理解，車輛電控開發的重點和難點還是在控制規律、標定等方面。

具體概念可參考前面幾位很詳細的介紹。

我這裡的代碼生成主要指汽車領域控制器開發階段的代碼生成

個人感覺：

1，容易維護。即便公司人事更迭，通過圖形化方式維護原有的演算法，要比維護手工代碼效率更好。你可在圖形化工具中方便的插入需求與模塊描述

2 便於模塊化開發，好的演算法模型可以方便的集成在模型中，作為庫模型

3 方便驗證，可住通過圖形化模型對與你的演算法快速進行驗證，這個對於手工代碼操作還是很麻煩的。

4 代碼符合相關標準，你不需要花更多的精力去研究諸如misra之類的標準。

等等

缺點的話，集成工作不比手寫方便，尤其是對於變更需求，不比手寫代碼迅捷，需要先把模型轉換成代碼，還需要針對平台進行集成。可能需要手寫介入。

需要對於工具有一定的了解，前期平台搭建甚至需要較為深厚的專業知識。

代碼生成雖然弱化工程師對於手工代碼的需求，但任然要求工程師有紮實基礎的c語言背景。