汽車系統設計現可以使用dSpace從模型轉Code，那某些功能手寫代碼的必要性在哪裡或者還有必要嗎？

01-09

現在車企可以使用Simulink 聯合 dSpace Targetlink直接基於模型設計後生成高效代碼，為什麼還有很多的功能開發或者某些公司開發功能時候要求手寫而不使用這些工具。那麼要求工程師手寫可能會存在哪些原因呢？代碼生成的準確性？效率？演算法無法通過模型編程實現？
相關問題可能是：「Matlab模擬結論在工業界認可度低」是否屬實？ - 知乎
謝謝！
08052017補充:
今天和同事請教了一下，也和大家回答的基本是一樣的，好處直觀可靠便於理解，並且不是每一個控制工程師都有較強的C能力，而熟練地程序員可能並沒有了解過比較多的控制理論，熟練指達到計算機專業碼農的程度；而要求手寫代碼的因素有比如dSpace某些功能的缺陷達不到要求，比如dSpace按照自己的Protocoll可能會生成很多但實際上無用的代碼，還有就是貴，hardware也貴，licence也貴。

由此可見。。。
會控制又編程一流的就。。。

這個問題在我以前的Live中基本每場都會被問到，而且也是做控制軟體需要回答的第一個問題：Matlab/Simulink/Targerlink相對C語言有什麼優勢和劣勢？
而這個問題的答案正解決了什麼時候用哪個工具，你所要做的就是揚長避短而已。

這裡就再次總結一下：
Simulink/Targetlink做基於模型的設計相對C語言最大的優勢就是下面三個：

1. 極大簡化了一些邏輯編程的複雜程度。其實控制演算法的很大一部分就是邏輯運算。除了最簡單的與，或，非，還有更加複雜的狀態決策，條件判斷整合(Merge)等等，通過使用Simulink/Targetlink強大的組件庫（其實就是編寫好的程序模塊）, 對比C語言可以極大簡化代碼複雜程度。

最為典型的一個例子就是Simulink中的Stateflow, 可以對系統所在狀態的邏輯決策進行基於模型的設計。如果一個系統有上百個狀態，狀態之間又有交錯的if else傳遞條件，用Stateflow的話你所得到的是一張條理清晰的流程圖，可能幾個小時就可以編寫完成還不易出錯。但是用C語言的話你需要用到幾百甚至上千的if else或者循環語句，不僅代碼量巨大，而且因為上百狀態之間並行和串列還有跳轉的關係很容易出現bug。

2. 第二個優勢就是標準圖形化所帶來的從編程，到代碼維護，直至找錯的易用性。Simulink/Targetlink對比C語言就好像用Windows對比DOS系統，一個完全是基於用戶友好的圖形界面，另外一個基於純文字語法。很多沒有編程經驗的工程師上手Simulink/Targetlink也會非常迅速，在控制軟體設計上入門工程師也可以很快高效編程。

代碼維護上Simulink模型比C語言更易讀理解，找錯上Simulink本身就有強大的糾錯和模型檢查功能，同時基於圖形界面的設計也更容易通過不同模塊來追溯bug源頭。

比如下圖所示的是Simulink VV模塊，可以對模型的質量針對不同的標準進行檢查：

(圖片來自：Features - Simulink Verification and Validation - MATLAB amp;amp;amp; Simulink）

3. 將系統工程師的工作和軟體工程師的工作進行整合，極大簡化開發流程。使用基於模型的設計和自動代碼生產，系統工程師和軟體工程師的工作的界限變得不再那麼明顯。系統工程師不再需要使用類似SysML這樣的圖形化工具來定義系統和軟體功能以及需求，可以直接使用Simulink/Targetlink。

下圖顯示的是圖形化的SysML工具界面，已經完全可以由Simulink來替代。

這樣系統工程師對軟體功能進行初步設計後軟體工程師就可以直接在同樣的工具Simulink/Targetlink中對模型細化直接生成代碼，而不需要再手動翻譯成C語言。

前面說了三點Simulink/Targetlink的優勢，雖然基於模型的設計是大勢所趨，但是對比C語言他也有自己下面的一些缺點：

1. Simulink/Targetlink圖形化的長處在於邏輯控制設計，而不是純數據運算，調用和管理。純數據運算介面定義內存管理之類的功能如果使用Simulink設計反而會變得更加複雜而得不償失。這也是Matlab和Simulink的區別。

目前市場上大部分控制軟體經典的選擇是ASW（上層Application Software）使用基於模型的設計，而BSW（底層Basic Software）使用C代碼編寫。

2. Simulink/Targetlink相對C代碼需要額外的軟體開發和測試步驟。量產使用的大型控制軟體，經常生產自動代碼這一步就需要超過1個小時。而因為模型模擬測試結果MiL（Model In the Loop）和生產C代碼後的測試結果SiL （Software In the Loop）會因為模型和代碼生成設置而出現潛在的不同，所以基於模型的設計需要進行多種測試，模擬的MiL結果也需要和C代碼SiL結果進行對比和相互驗證。

3. 開發工具成本。不同於免費的C開發工具，基於模型設計的一系列軟體非常昂貴。裝備一套單機版的Matlab + Simulink + Targetlink 可能就需要花費10-20萬甚至更多，取決於版本，配套組件的選擇和你所在的國家地區。

所以如果你比較上面我提到的Simulink/Targetlink和C語言各自的優缺點的話就會發現：

如果你編寫的是複雜控制邏輯的大型量產軟體，且需要多人參與，公司也有比較完整複雜的系統工程師和軟體工程師分工，那麼你適合使用Simulink/Targetlink。
反之如果你編寫的是簡單的邏輯控制（使用額外的開發步驟得不償失），或者是底層的數據計算，介面調用，內存管理（不是Simulink擅長功能），或者你的預算以及公司規模有限（成本限制），那麼使用手寫C代碼可能是最為明智的選擇。

我看到有人提到工程師個人經驗對於代碼工具選擇的影響，確實也是一個決定因素。比如很多公司以前的老代碼都是手寫C，工程師也都是C語言背景，那麼將這些代碼轉換成為模型以及讓工程師開始使用Simulink/Targelink確實會花費非常多的額外人力物力。

我也見過一些公司走捷徑直接把現成的C代碼做成Function大塊大塊嵌入Simulink模型，並且稱之為基於模型的設計。首先這種方式肯定不能算作真正意義上的基於模型的設計，也遠遠沒有辦法利用到上面說到的基於模型設計的優勢。從手寫C轉換到基於模型的設計是很多行業發展（尤其是汽車和航空航天）必然需要經歷的痛苦過程，如果現在不做適應的話未來肯定會被更加高效和高質量的工具所淘汰。

===================================

我的相關Live：

車載控制軟體設計，從需求到量產：知乎 Live - 全新的實時問答

控制策略在 Simulink 中的實現：知乎 Live - 全新的實時問答

Simulink 中 Stateflow 的進階應用：知乎 Live - 全新的實時問答

代碼的轉變趨勢，其實就是變得越來越容易看懂與維護。

由傳統的C代碼到模型，就是出於這樣的一個目的。但是如果一個模型寫出來的代碼，

還不如手寫更讓人明白的話，那為啥一定要升級為模型呢？而且有些手工代碼已經經過了

無數SOP的驗證，突然升級為模型代碼反而帶來的風險更大。

在汽車開發中，仍然有不少模塊依舊保持著手動開發的原則，比如：

控制器的底層與基礎軟體，像pin腳配置，複雜驅動，中斷函數，os系統，網路管理~UDS~

刷新等模塊。依舊保持著手動代碼，涉及到結構體與指針等高級的操作，手動代碼反而優勢

更加明顯。

1.標準庫沒有或者性能有限時

2.底層開發，或者一些複雜驅動比如etpu,gtm的

3.BootLoader

因為這些公司要麼沒錢，要麼沒人

單純的控制策略或者數學模型肯定是沒問題，但是一些複雜的功能可就不一定能實現了，畢竟大家有共性的需求也有各自的特點。比如我們希望動力學模型能夠支持碰撞檢測，但是現有的檢測庫大都是c＋＋的，dspace現在對這部分生成代碼功能支持的還不好，就只能自己做。

主要是一些偏底層和複雜的驅動，以及用模型描述起來更難更麻煩的情況。當然，也有的情況是自己的策略比較簡單，手寫就能全部搞定，沒必要換一個新的開發方式（與另一個答案里的那種公司沒錢也沒人的情況類似）。

BMS/Asw的來說一下：

一個原因是Targetlink提供的模塊不完整。

我司使用的3.4版本（比較老了），工作中有幾個方面不能實現：

1. 矩陣計算

2. 數組的Sorting

前者是Stateflow都沒辦法實現，後者是Stateflow實現起來麻煩，還不如手寫代碼實現的效率高。另外對於產品軟體的通用化上也有一些局限。

所以這兩部分都用手寫啦。

不是做汽車的。。。舉個別的例子吧

FPGA某模塊，手寫的基本15k LE左右，某所用轉換的辦法做了一個，150k LE......

認為自己很牛逼罷了，其實只是不了解dspace的強大。

先佔坑

我下周問問我司工程師( ?° ?? ?°)

PS: 我是Anfordrungsmanagement崗