前言

軟件定義汽車時代車載軟件爆炸式增長，向控制器中加入更多功能，或者向現(xiàn)有的電子電氣架構中增加更多的控制器的增量式擴展路徑都已經(jīng)無法應對越來越復雜的系統(tǒng)集成和越來越高的硬件成本，我們必須重新思考電子電氣和軟件架構的新模式。

隨著電子電氣架構從分布到集中再到高性能高連接的發(fā)展，軟件架構也經(jīng)歷了軟硬件高度耦合到基于組件再到面向服務的演變。

面向服務的架構（SOA）給汽車行業(yè)帶來了新的挑戰(zhàn)：

1）SOA 對于汽車行業(yè)還是個新事物，開發(fā)人員是否需要從頭開始學習包括中間件在內的新架構和方法論？

2）傳統(tǒng)的軟件架構平臺和 SOA在一定時期內還將長期共存，是否需要不同的開發(fā)方式甚至人員組織來對應？

3）原有相關測試驗證的知識經(jīng)驗、工作流程和軟件資產是否還能重用？

面對上述問題，汽車行業(yè)的相關從業(yè)人員都會想知道：當前廣泛采用的基于模型設計是否還能用于面向服務的應用開發(fā)？

我們的回答是肯定的。

Simulink 陸續(xù)推出的一系列功能支持 SOA 開發(fā)，包括但不限于：

1）在建模仿真能力增加了軟件架構設計和面向服務的語義建模；

2）在自動化代碼生成能力上拓展了對新的中間件平臺標準以及 GPU 和 FPGA 等新的硬件架構的代碼生成支持；

3）在系統(tǒng)化測試驗證能力上覆蓋了從模型到代碼、從測試到分析的完整功能安全軟件驗證要求。

案例演示

SOA 最核心的機制是面向服務的通訊（SOC），本文通過一個案例來展示 SOC 建模、集成測試、代碼生成和部署標定，希望給大家一點啟示。

1） 面向服務的通訊建模

傳統(tǒng)的嵌入式控制中基本數(shù)據(jù)流是通過信號傳遞的，而 SOA 的基本數(shù)據(jù)流是消息。

信號涉及 writer 和 reader，只有最后被 writer 寫入的數(shù)據(jù)才對 reader 有效；而消息涉及 sender 和 receiver，receiver 可以處理 sender 發(fā)送過來的歷史數(shù)據(jù)。

Simulink 提供了消息的發(fā)送、接收、隊列和時序等基本模塊用于消息和事件機制的建模。

我們采用消息的收發(fā)模塊來建立基本的 SOC 通訊，exServer 模型通過封裝了消息發(fā)送基本模塊的 Event Send 發(fā)送數(shù)據(jù)，而 exClient 模型通過封裝了消息接收基本模塊的 Event Receive 接收數(shù)據(jù)。

Event Send 和 Event Receive 位于 AUTOSAR Blockset 的模塊庫中。

2） 集成測試

在簡單架構的集成時，可以直接采用模型引用的形式；對于復雜軟件架構設計，可以采用 System Composer 的軟件架構設計功能。

exServer 的輸出信號、轉換為消息收發(fā)的數(shù)據(jù)和 exClient 接收到的消息轉換之后的信號之間的對比，可以看到與信號對比消息有顯著的“事件”特性。

此外還可以采用時序圖模塊觀測消息的收發(fā)對象、時序和數(shù)據(jù)關系。

3） 代碼生成

要生成面向服務的 C++ 代碼需要選定中間件平臺進行配置，這里以 Adaptive AUTOSAR 標準為例，在數(shù)據(jù)詞典中定義服務接口和端口、配置端口實例的標識號和服務發(fā)現(xiàn)機制。

在 Simulink 模型中完成 Adaptive 對象與模型輸入輸出的映射。

在代碼生成配置中選擇 autosar_adaptive.tlc 系統(tǒng)目標文件；考慮到后續(xù)部署需要工具鏈選擇 AUTOSAR Adaptive Linux Executable， 這樣在生成代碼的同時會生成用于 Linux 平臺可執(zhí)行文件編譯的 CMakeLists 文件。

在生成的符合 Adaptive 通訊接口標準的 C++ 代碼同時生成相關的清單文件。

4） 部署和標定

在 Linux 平臺下采用 CMAKE 編譯生成可執(zhí)行文件即可進行部署，如果有標定需求可以采用XCP 協(xié)議。

案例中的可標定參數(shù) mode 和 gain 都在 exServer 模型中，因此 exServer 在生成代碼前需要進行額外的標定配置，這里的 mode 參數(shù)可以選擇產生三角波信號或者正弦信號，gain 參數(shù)用于對信號進行縮放。

在配置中設置 XCP slave 的配置，包括傳輸層協(xié)議、可執(zhí)行文件所在機器的 IP 地址和端口號，這樣會同時生成用于標定的 XCP 協(xié)議代碼。

生成代碼后得到的 a2l 文件中沒有實際的參數(shù)地址，需要在編譯后輸入可執(zhí)行文件進行地址替換。

替換地址后的參數(shù) mode 和 gain 在 a2l 文件中的信息如下：

我們用 INCA 導入 a2l 文件進行觀測和標定，下如兩處紅框分別是 mode 從 0 到 1 和 gain 從 1 到 2 標定修改時的信號變換。

總結

以上我們展示了采用基于模型設計開發(fā)面向服務應用的過程，軟件架構設計、面向服務的語義建模、中間件標準支持、異構平臺代碼生成和人工智能算法引入等一系列能力使 Simulink 正逐漸支撐軟件定義汽車時代的面向服務的應用開發(fā)，從軟硬件耦合架構到基于組件開發(fā)再到面向服務的應用，讓用戶以算法為核心最大程度地重用原有的模型資產和開發(fā)流程。

而行業(yè)用戶已經(jīng)非常熟悉的基于模型的功能安全測試驗證流程也將繼續(xù)助力面向服務的應用開發(fā)。

責任編輯：lq