致力于汽車行業基于模型設計流程的實現以及電控單元開發方面的技術咨詢工作。他專注于嵌入式代碼生成、系統集成、模型驗證、處理器在環（PIL）實現、模型架構設計以及MBD工具定制等方面的開發及工具鏈的深入應用。在加入邁斯沃克之前，李智慧曾供職于法雷奧、德爾福、中汽中心等公司，有10年的汽車行業產品開發經驗。

圖形化建模是架構設計普遍使用的方法。而 Simulink 已經成為許多系統工程師進行架構設計的利器。不管是在仿真驗證階段還是快速原型階段，都可以利用 Simulink 非常方便地對復雜控制模型進行功能的組織、劃分、調度等工作。

本文參考 ISO 26262 的要求，同時考慮 AUTOSAR 代碼生成的兼容性，給出使用 Simulink 實現軟件架構設計的一些建議。

應用層軟件功能劃分

ISO 26262-6 要求創建層次化結構的軟件組件（Software Components — SWC）。軟件組件應滿足規模適中、高內聚、低耦合的要求。軟件組件加上ASIL（Automotive Safety Integration Level，汽車安全完整性等級）的要求就決定了開發及驗證的方法。軟件架構中的最小實體（Entity）就是軟件單元（Software Unit）。

在 AUTOSAR（Automotive Open System Architecture）中，應用層軟件由應用軟件組件組合（Compositions of Application Software Components）組成。一個應用軟件組件（Application Software Component — ASWC）要符合特定的模板，而且通過虛擬功能總線（Virtual Functional Bus — VFB。）與其他應用組件進行通信（在控制器內部，VBF 的具體實現是運行時環境 Run-time Environment — RTE）。Runnable（或可譯為運行實體）是應用軟件組件提供的、可以獨立調度的最小代碼片段。

【注】在 AUTOSAR 文檔中，軟件組件（通常指的是原子軟件組件 - Atomic Software Component）可以細分為應用軟件組件（Application Software Component）和傳感器-執行器軟件組件（Sensor-Actuator Software Component）。本文考慮與 Simulink 建模的相關性，只講應用軟件組件。如果傳感器-執行器軟件組件也用 Simulink 建模實現，可以參照應用軟件組件開發方法，在 Simulink 建模層面不強調其差異性。

不管在 ISO 26262 還是 AUTOSAR 中，對于軟件單元在層次化結構中的具體定位都沒有明確規定，實踐中通常根據具體軟件架構以及應用復雜度而定。

在 ISO 26262 架構下，如果某個軟件組件功能獨立而且實現簡單，它本身就可以是一個軟件單元；如果功能復雜，則可以進一步劃分為幾個軟件單元。

在 AUTOSAR 中情況類似：一個應用軟件組件可以只包含一個（也可能是幾個）運行實體，而且功能簡單，那么這個應用軟件組件本身就可以使一個軟件單元；如果包含多個運行實體而且功能較為復雜，每個運行實體可以是軟件單元；如果某些運行實體的功能非常復雜，則可以進一步將一個運行實體劃分為幾個軟件單元來實現。

在 Simulink 中，功能劃分體現在：將模型虛擬分組來創建抽象層；根據調度需求將模塊（block）分組；利用模型引用（Model Reference）來控制模型的規模。具體的軟件分層類似于以上提到的 AUTOSAR 中的分層。軟件單元通常要求為獨立模型，以便于單獨開發、驗證以及管理。其他層次根據復雜度而定。

下圖給出了一個 ISO 26262、Simulink、AUTOSAR 三者的映射關系示例：

該示例表示的是最為復雜的一種情況：一個應用軟件組件包含多個復雜運行實體，而運行實體進一步劃分，有多個軟件單元模型實現。從上到下都是通過模型引用的方式逐級展開。以下各個章節都是基于這種情況示例。

軟件單元（Software Unit）

MathWorks建議

使用 Simulink模型來表達軟件單元

相比于子系統庫而言，一個模型有自己的仿真及代碼生成配置參數，可以單獨仿真、測試以及增量式生成代碼。由于模型的使用，多個軟件單元可以并行開發，并且在配置管理系統中可以單獨管理。

MathWorks建議

使用模型引用（Model Reference）集成軟件單元

頂層模型（集成模型）只是一個整體框架，具體的各個軟件單元通過模型引用連接。在這種架構下，利用 Simulink 本身的模型更新（快捷命令 Ctrl+D）功能，可以很容易地完成軟件單元集成后的靜態驗證。可以檢查軟件單元之間的接口是否匹配，可以檢查軟件單元模型與頂層集成模型配置參數的兼容性（例如解析器的選擇、硬件相關設置等）從而保證代碼生成的一致性。

運行實體（Runnable）內部軟件單元（SU）的集成

在頂層模型這一層，Simulink 模塊可以顯示軟件單元的模型信息以及數據流和模塊執行順序。

MathWorks建議

使用模型引用的方式測試軟件單元

通過頂層模型（Top Model。也可稱之為測試框架 – Test Harness）引用軟件單元模型的方式來進行單元測試（Unit Test）。單元測試的基本要求之一是測試人員不可以修改被測單元（不管是模型還是代碼）。所以要建立測試框架，輸入激勵信號以及輸出的觀測都要在測試框架環境下完成。對于模型，可以采用模型引用（Model Reference）實現被測模型與測試環境的獨立。

模型 SU1 進行 PIL 模式單元測試的框架模型

一個軟件單元模型可以在多種模式下測試驗證：

正常仿真模式（Normal Mode）

模型在環（Model-in-the-loop -- MIL）

軟件在環（Software-in-the-loop -- SIL）

處理器在環（Processor-in-the-loop -- PIL）

上圖所示的測試框架模型可以由 Simulink 軟件自動生成（上圖由 Simulink Test 生成，也可以根據實際需要，由 Simulink Verification and Validation 或者 Simulink Design Verifier 生成類似的測試框架）。工程師只需要根據功能需求，輸入測試用例（測試數據或測試序列）即可。

同樣的測試框架模型以及測試用例可以在各個測試階段重復使用：

模型階段 – 正常仿真模式或模型在環 – MIL

在 PC 機上驗證生成的代碼 – SIL

在目標處理器上驗證生成的代碼 – PIL

Simulink 自帶的仿真數據觀測器（Simulation Data Inspector）可以很方便的完成測試數據觀測及分析：

不同測試用例數據（輸入或輸出）圖形化顯示或對比

不同測試階段結果對比（比如 MIL 和 SIL 對比，MIL 和 PIL 對比等）

用仿真數據觀測器分析數據

此外，Simulink Design Verifier還可以幫助工程師生成一些特定目的的測試數據來提高測試覆蓋度。

AUTOSAR運行實體（Runnable）

MathWorks 建議

使用函數調用子系統（Function-call Subsystem）

描述運行實體

AUTOSAR 當中，一個運行實體（Runnable）是指一個原子軟件組件（AUTOSAR Atomic Software Component）提供的最小代碼段，同時也是一個可以被單獨調度的任務。函數調用子系統提供了調度控制機制，可以很容易地實現模型各個部分周期性或非周期性的調度控制。

函數調用子系統描述運行實體

每個函數調用子系統由一個或幾個互相連接的軟件單元（如圖：運行實體內部軟件單元的集成）組成。運行實體間數據交互的完整性采用AUTOSAR 運行實體間變量（Interrunnable Variable，簡稱IRV）機制來保護。因為所有函數調用由一個統一的觸發源產生，所以仿真的時候不會產生數據完整性問題。

軟件組件（Software Component）

對于應用層軟件來說，ISO 26262當中的軟件組件（SWC）對應于 AUTOSAR 中的應用軟件組件（ASWC）。

MathWorks建議

采用獨立模型來描述AUTOSAR應用軟件組件(ASWC)

在一個Simulink模型里將一個軟件組件對應的所有函數調用子系統封裝起來，在用Embedded Coder生成代碼時，這些函數調用子系統會自動映射到相應的運行實體（Runnable）。

MathWorks建議

要對應用模型架構與AUTOSAR 的兼容性進行驗證

在架構設計的早期，工程師可以只創建運行實體（Runnable）模型框架，其中的軟件單元（Software Unit）為空模型（只有頂層輸入及輸出，內部沒有邏輯及連接，如下圖所示）。

空白的軟件單元模型

Embedded Coder（要求包含 AUTOSAR 支持包）可以分析模型架構，確認各個應用軟件組件（ASWC）是否可以根據 AUTOSAR（指定版本）的要求正確地訪問數據接口以及是否可以正確地使用運行實體間變量（IRV）。

AUTOSAR 接口配置驗證

軟件單元（Software Unit）集成完成之后，在應用軟件組件（ASWC）生成代碼之前，可以利用 Embedded Coder 分析模型的 AUTOSAR 符合性，包括軟件單元（Software Unit）建模正確性分析，比如數據的耦合性檢查、全局數據存儲檢查、全局跳轉模塊檢查等等。

Embedded Coder 在生成 C 代碼的同時，還會生成對應的 arxml 文件，該文件符合指定的 AUTOSAR 版本，可以導入到外部 AUTOSAR 編輯工具（AAT）進一步完成系統級集成。

MathWorks建議

在 Simulink 環境下完成

AUTOSAR應用軟件組件的測試驗證

應用軟件組件（ASWC）這一級的集成測試可以完全在 Simulink 的環境下完成。

為了驗證生成的源代碼，Embedded Coder 將生成的代碼編譯打包成 S 函數（S-Function），創建軟件在環模塊（SIL block）。由于選擇了 autosar.tlc 作為系統目標文件（System Target File），S 函數運行所需要的 AUTOSAR RTE 接口會自動配置（不需要RTE代碼生成）。

軟件在環（SIL）和處理器在環（PIL）模塊可以在原始模型測試環境下直接替換被測模型（采用模型引用配置）。

同一測試環境完成不同測試

軟件組件（Software Component -- SWC）的層次化結構

MathWorks建議

用虛擬子系統描述應用抽象層

ISO 26262 建議采用層次化的結構來組織軟件組件（參照 ISO 26262-6 第 7 章）。在AUTOSAR 中，應用軟件組件（ASWC）集成在一起稱為組合（Composition）。在 Simulink 中，采用虛擬子系統對功能模塊進行分組，從而實現抽象層的概念。組合（Composition）加上被控對象模型（Plant Model），可以仿真運行整個應用系統（下圖省略了調度部分）。

系統級模型

在組合層次采用模型引用來集成軟件組件：

組合模型引用軟件組件模型

應用軟件調度

ISO 26262 要求指定每一個算法塊的調度方法及執行順序。

運行實體（Runnable）內部軟件單元（SU）的執行順序

MathWorks建議

如果沒有對具體數據的依賴性，要將執行順序顯示出來

在函數調用子系統（Runnable）內部，Simulink可以顯示每個模型（軟件單元 - SU）的執行順序（參考上圖：運行實體內部軟件單元的集成）。如果模型之間存在數據依賴，Simulink可以自動判斷并設定執行順序。如果沒有依賴，Simulink根據輸出端口編號給出推薦的執行順序，用戶可以通過優先級選項修改執行順序。

運行實體的調度（Scheduling of Runnables）

MathWorks建議

使用Stateflow 或MATLAB模塊創建集中的調度器

Simulink 中的函數調用子系統由函數調用事件（Function-call Event）觸發。可以產生觸發事件的模塊有 Stateflow、MATLAB 模塊及函數調用生成器（Function-call Generator）。為了清楚表達所有軟件單元復雜的調度關系，建議使用 Stateflow 狀態圖。

Stateflow 實現集中化調度示例

在Stateflow中，時間邏輯（Temporal Logic）可以用來產生周期性觸發事件，數據輸入端的轉移條件可以用來產生非周期觸發事件。每個并行狀態右上角的數字顯示了該狀態的執行次序。每個狀態里的事件列表定義了觸發的先后順序。

應用層通常有許多觸發事件。為了提高效率，可以用 MATLAB 腳本自動創建這樣的調度器，并且自動連接到相應的函數調用子系統。

軟件集成人員在 AUTOSAR RTE 中進行運行實體（Runnable）的運行任務分配時，可以參照用 Stateflow 描述的任務調度。反過來，也可以參照 RTE 中的任務分配調度，設計 Stateflow 調度器。

應用層軟件接口

ISO 26262 要求完整定義軟件單元（SU）及軟件組件（SWC）之間的接口。

ISO 26262 建模標準檢查（Model Advisor）可以驗證軟件單元建模的合規性。通過運行模型更新檢查功能，Simulink 引擎自動檢查接口連接及數據定義的正確性。Embedded Coder（包括 AUTOSAR 支持包）可以用來確認應用軟件組件（ASWC）接口定義是否完整以及是否符合 AUTOSAR 的要求。

Simulink 軟件提供的工具鏈（主要用到算法開發類、測試驗證類、代碼生成類等工具箱）以及開發方法可以很好地滿足符合 ISO 26262 及 AUTOSAR 要求的應用軟件開發。