前言

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

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

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

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

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

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

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

我們的回答是肯定的。

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

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

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

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

案例演示

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

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

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

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

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

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

Event Send 和 Event Receive 位于 AUTOSAR Blockset 的模塊庫(kù)中。

2） 集成測(cè)試

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

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

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

3） 代碼生成

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

責(zé)任編輯：lq