模型測試

當今的汽車或航空用的電子控制單元（ECU）中，越來越多的控制器使用基於模型的開發方法，其特點為通過模擬快速測試，自動代碼生成以及自動測試。

其開發步驟大致如下：

1》書寫需求，通過BTC EmbeddedSpecifier進行需求的形式化（讓計算機理解需求）

2》基於需求，手動構建Simulink模型進行控制策略測試

3》使用TargetLink和BTC EmbeddedValidator通過窮舉法進行靜態驗證模型是否滿足需求（單元測試），如果模型過於複雜，使用動態的基於模擬的形式驗證（集成測試）

4》使用TargetLink生成代碼，使用BTC EmbeddedTester做全自動等效性測試（單元及集成測試）

5》評估並把驗證后的所有代碼對ECU進行刷寫，做硬體在環測試（HIL），使用BTC RTT-Observer進行自動驗證ECU的輸入和輸出，看是否滿足系統需求（系統測試）

6》ECU的真車測試及參數標定

7》ECU軟體和硬體結合量產

本文主要集中介紹等效性測試的環節：

在遵循ISO26262的流程進行基於模型的開發（Model Based Development）時，ISO26262的9.4.3章和10.4.3章推薦執行等效性測試（Back-to-back testing）來比較模型（Simulink/TargetLink模型）和由模型自動生成的實現（C代碼）。

等效性測試的目標是在給予同樣的輸入的情況下，判斷實現（C代碼）和模型是否有同樣的輸出。

1》模型和C代碼為滿足需求的不同的軟體表現形式，是否一致需要做等效性測試。

2》代碼生成器（例：TargetLink）為了生成高效的C代碼，對C代碼進行優化，需要對優化結果進行確認。

3》定點小數點代碼時，需要比較定點小數點C代碼和模型（浮動小數點計算）的輸出誤差。

4》對於C語言一些特有的缺陷進行測試，比如除數為零。

5》滿足ISO26262的要求。

1》模型本身必須是已經通過基於需求的測試，即模型本身是正確的，其輸出可作為參考值用於對實現（C代碼）的比較。

2》對於所有的輸入測試用例，實現（C代碼）和模型的輸出差值應該在允許誤差範圍內。

3》測試用例需要滿足實現（C代碼）高水平的覆蓋率（ISO26262推薦覆蓋率量化種類：MC/DC ）。

1》如何高水平的驗證模型是滿足需求的，因為只有模型滿足需求，模型才是可用於代碼生成和隨後的等效性測試。

2》如何製作測試用例，來達到ISO26262所要求的MC/DC級別100%的覆蓋率。

3》測試環境該如何搭建，對各個測試用例輸出結果進行比較，用人工來做將非常耗時，並容易出錯。

歐美和日本主要汽車和飛機控制器開發現場所使用的解決方案是使用專業測試工具來輔助測試完成測試目標。

一般使用BTC EmbeddedPlatform的EmbeddedSpecifier和EmbeddedValidator功能來自動測試並證明模型（例：TargetLink）是否滿足需求。該工具使用簡潔易懂的形式語言技術（Model Checking），可對模型通過窮舉法進行全自動驗證。如果被證明滿足需求，接下來就是代碼自動生成和等效性測試。

以下為基於需求測試示意圖：

方法一：使用窮舉法對模型進行靜態解析看是否滿足需求，不滿足需求時自動生成調試模型。

缺點是對複雜模型解析能力受限，這時需要用方法二即使用模擬進行自動測試

方法二：使用模擬進行自動測試

使用BTC EmbeddedSpecifier把需求形式化后，自動生成基於需求的測試用例和需求觀察器，需求觀察器可自動並聯到測試對象中，完成自動測試並輸出報告。

使用BTC EmbeddedTester自動生成滿足C代碼MC/DC級別100%覆蓋率的測試用例，然後自動進行等效性比較（Back-to-back）並生成測試報告。由於BTC EmbeddedTester可以設定比較誤差值，因此測試擔當者的工作可以僅看測試報告就可以判定該實現（C代碼）是否和模型等效。

以下為Back-to-back的示意圖：

第一步：逆向解析C代碼，自動生成滿足C代碼MC/DC級別100%覆蓋率的測試用例

第二步：使用自動測試用例，自動進行Back-to-back測試

總結

我國的汽車/航空電子控制器軟體開發雖然起步較晚，利用好后發優勢，有很多成熟的既有技術可以快速應用，可以避免發達國家走過的一些技術彎路。更快更好的對標國際OEM的控制器開發水平，一個方法就是參考ISO26262並嚴格定義開發流程，做好開發過程的各個階段的評價，利用好現有工具，降低開發成本，縮短開發周期，提高質量。假以時日，中國的自主開發的品質和性能必將上一個台階，實現質的轉變。