前言

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

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

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

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

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

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

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

我們的回答是肯定的。

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

1）在建模仿真能力增加了軟件架構(gòu)設(shè)計和面向服務(wù)的語義建模；

2）在自動化代碼生成能力上拓展了對新的中間件平臺標(biāo)準(zhǔn)以及 GPU 和 FPGA 等新的硬件架構(gòu)的代碼生成支持；

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

案例演示

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

1） 面向服務(wù)的通訊建模

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

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

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

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

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

2） 集成測試

在簡單架構(gòu)的集成時，可以直接采用模型引用的形式；對于復(fù)雜軟件架構(gòu)設(shè)計，可以采用 System Composer 的軟件架構(gòu)設(shè)計功能。

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

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

3） 代碼生成

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

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

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

在生成的符合 Adaptive 通訊接口標(biāo)準(zhǔn)的 C++ 代碼同時生成相關(guān)的清單文件。

4） 部署和標(biāo)定

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

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

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

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

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

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

總結(jié)

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

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

責(zé)任編輯：lq