模型質量目標（Model Quality Objectives，以下簡稱 MQO）的標準是由一流的汽車廠商和 MathWorks 公司共同制定，目的是當在嵌入式軟件開發中 OEM 和供應商進行 Simulink 模型共享時，可以清晰定義并簡化雙方的協作，并最終提高軟件產品的質量和完整性。

首先，基于軟件開發生命周期的四個不同階段用到的四種設計模型，本文定義了一套軟件開發方法。然后，針對每種模型，提出了一個名為 MQO 的特定質量目標。每個目標被定義為一組質量特征和一些可衡量的標準，稱為模型質量要求（Model Quality Requirement，MQR）。此外還提供了一些額外的規范，來管理與 MQO 和 MQR 相關的計劃和質量評估活動。在文章最后也對汽車工業采用 MQO 的預期影響進行了總結。

為什么制定模型質量目標

為了加速嵌入式軟件的開發，用 Simulink 軟件開發的設計模型在業界廣泛使用。這些模型使工程師能夠完成各種工程任務，如頻域分析、桌面仿真、形式驗證和自動代碼生成。這個開發過程被稱為基于模型設計。

出于驗證需求和快速地探索設計方案的目的，可以在非常早期的階段開發設計模型。這些模型也可以逐步改進，直到它們達到一定成熟度，可生成符合國際軟件安全標準的代碼。為了逐步增加設計模型的成熟度，需要涉及到系統工程、控制工程和軟件工程等不同的工程學科。使用相同的語言、工具和模型進行協作，是提高工程師之間的溝通、降低工程費用和縮短開發時間的好方法。然而，由于在不同的項目階段使用設計模型有不同的規程，可能會出現關于模型的作用和它們代表的內容間的混亂。

對模型代表的內容的錯誤解釋會導致錯誤地使用這些模型，并最終影響所產生的軟件的質量。參與制定 MQO 的 OEM 和一級供應商分享了許多關于成熟度不夠或存在漏洞的模型被過早地確定為“可用于編碼”的慘痛案例。

因此，有可能出現超出計劃的開發人力投入、問題、與職責相關的爭論等。為避免這種情況，文章旨在闡明設計模型在嵌入式軟件開發中的作用，并規范可測量的標準，以驗證其質量。

這種方法的靈感來自于2010 年由一些汽車廠商和 MathWorks 定義的軟件質量目標（Software Quality Objectives，SQO）[1]，當時汽車制造商和供應商之間的大多數交流都是基于文本規范和手工代碼。在以下方面，這種方法還可更進一步：模型共享的規范化，于 2014 年由 Bosch [2]所定義；ISO 26262-6 等軟件安全標準所推薦的技術與措施的實現 [3]。

制定模型質量目標的目的是：

為軟件開發定義設計模型的主要用例

根據它們的用例，定義評估模型質量的標準和通用方法

軟件開發和模型設計

文章定義了一種基于四類設計模型的開發方法，這些設計模型支持 V 流程的左側。

圖 1：基于模型設計/MQO 軟件生命周期

基于模型設計/MQO 的軟件開發生命周期包含五個具體階段，見圖 1 中標示的 1 到 5。后面也將講述有關階段的更多細節。

圖 2 列出了基于模型設計/MQO 的軟件開發生命周期與業界其它軟件開發生命周期的映射關系。設計模型所支持的階段已用黑色背景突出顯示，基于模型設計（Model-Based Design，簡稱為 MBD）。

圖 2：基于模型設計/MQO 的軟件階段與其他工業標準的對照[3][4][5][6]

軟件計劃階段

本節定義了在準備使用設計模型前必須執行的計劃活動。這些活動在使用功能模型時是推薦的，在使用架構、組件設計和組件實現模型時是強制要求的。這些概念中的大多數已經在諸如 DO-331[5]之類的安全標準中得到貫徹。

范圍定義：不是所有的設計模型都適用于所有的項目。例如，基于模型設計的范圍可以簡化為單個軟件組件的開發，或者只被用于支持軟件架構設計規范。項目應定義設計模型所支持的軟件開發階段。在所屬的軟件開發階段，每個設計模型都應該作為其所屬階段的工作產品被獨立管理。

工具定義：在項目開始時，支持設計模型的開發和驗證的工具應該被鑒別和分類。如果項目要求，這些工具應是合格的。

標準定義：在進入軟件架構階段之前，應該定義用于支持設計模型開發的建模標準。在進入軟件組件實現階段之前，應該定義用于支持設計模型開發的編碼標準，或者最好在進入軟件組件設計階段之前定義。

MQR 識別和分配：在項目開始時，項目相關方應識別并同意 MQR。一些 MQR 應該隨項目需求（例如，模型和代碼覆蓋度準則）而調整。每個 MQR 都將被分配給項目相關方。

MQR 的實現策略：一旦為項目定義了 MQR，就應該定義實現這些目標的策略。策略可以包括與項目里程碑對應的中間步驟，特定培訓，或工具遷移流程。例如，建議逐步提高覆蓋度標準；不要等有了軟件的最終版本，再執行大部分的測試開發工作。

MQR 一致性證明：在項目結束時，應該規劃并證明項目 MQR 的一致性。對每個 MQR 的驗證都應提供報告，這些報告由負責 MQR 的項目相關方提交。當不滿足 MQR 時，必須提供充分的理由（例如，覆蓋度未達標需要被證明是合理的）。負責合規評估的人應當具備理解這些理由的必要技能。

軟件需求階段

本節重點介紹軟件需求階段開發的功能模型。功能模型的作用是澄清和細化復雜的動態行為，這些行為將被轉化為軟件需求。

在大多數情況下，功能模型和軟件需求由負責軟件需求的人同時開發。功能模型工程師幫助固化軟件需求（what），而在鑒別好的設計方案（how）方面則有待在設計和實現階段進一步精細化。功能模型通常被稱為可執行規范，因為它提供了滿足功能需求的功能行為。然而，功能模型并不能取代軟件功能需求。功能模型用于軟件需求的驗證活動。

功能模型側重于算法和方程的正確性，它不必考慮與嵌入式軟件開發相關的設計約束。然而在開發功能模型時，應該預測硬件平臺的主要特征及其對軟件需求的影響。

如果軟件功能需求易于實現，則可能不需要功能模型，也無需在功能模型中表達全部功能需求。圖 3 展示了一個連續時間功能模型的例子，它實現了大型軟件中的一個小功能。

圖3：功能模型的例子（防抱死系統）

軟件架構設計階段

本節重點介紹軟件架構設計階段開發的架構模型。架構模型用于軟件體系結構設計規范。

圖形符號天然適合定義組件組織結構、表述接口和連接、說明組件的調度。對于復雜的架構，如果沒有合適的建模語言，或者是像 Simulink 這樣的計算機輔助設計工具，要開發這樣的圖是無法想象的。

架構模型完全確定了靜態軟件架構設計（如，組件模型、接口），向將要構建或者已構建好的組件設計模型提供了鏈接/參考。架構設計模型與數據字典關聯，該字典定義了軟件及其組件的數據和接口。

架構模型直接用于設計活動，因此要符合行業質量標準、安全標準，及/或架構標準（如，對需求的可追溯性，與架構標準的兼容性。）

圖4 架構模型的例子

軟件組件設計和測試階段

本節重點介紹組件設計模型，這些模型是在軟件組件設計和測試階段產生的。組件設計模型的作用是：提供軟件組件設計的完整規范，并支持其動態驗證和靜態分析驗證。

使用高級建模和編程語言可以更好地管理復雜的算法，并減少設計錯誤的可能性。由于支持仿真和靜態分析，它有助于消除設計錯誤。

組件設計模型完全確定了算法和方程式——這將是嵌入式軟件的一部分，并且排除了用于調試或原型設計的任何元素，例如測量點或重載機制。每個組件設計模型都與一個數據字典相關聯，它定義了模型的接口、參數和監測信號。

組件模型直接用于開發活動，因此需符合行業質量標準、安全標準，及/或設計標準（如，符合建模規范，對需求的可追溯性。）

圖 5 展示了一個組件設計模型的例子，它具有完整定義的接口和用狀態機實現的子功能。

圖 5：組件設計模型的例子

軟件組件實現和測試階段

本節重點介紹組件實現模型，這些模型是在軟件組件設計和測試階段產生的。組件實現模型的作用是：為特定的嵌入式目標和基本軟件生成產品代碼。

組件實現模型完全確定了軟件組件的實現。實現細節被添加到數據字典中，以細化如何在目標內存中表征參數和信號。定義代碼配置項和定制項，用于將生成的代碼與特定的基本軟件功能集成在一起，以便它們與目標的特征（例如字節順序）匹配，并滿足針對該軟件組件的代碼內存占用和執行性能方面的要求。

組件實現模型生成的代碼直接用于開發活動，因此要符合行業質量標準和安全標準、及/或編碼標準（如，MISRA C）。每個組件實現模型都與一個定義其接口參數和監視信號的數據字典相關聯。

圖 6：組件實現模型的代碼生成配置的例子

設計模型間的關系

每個設計模型都應該在其所屬的軟件開發階段，作為工作產品單獨進行管理。與此同時，設計模型可以共享設計信息，并保持一致。例如，圖 5 中的組件設計模型與圖 4 的架構模型共享接口定義。任何需要一致性的時候，都應該鼓勵重用。

圖 7 顯示了在設計模型間哪些方面可以重用（“reuse” 箭頭），它還提供了關于設計模型的哪些方面可以被部分重用（“refine” 箭頭）的指導，以加速開發。圖 7 中的箭頭可以應用于設計模型的以下建模方面：

架構方面：接口、調度、分塊、組件間的控制和數據流等

算法方面：數學計算、組件控制和數據流、狀態機、真值表等

代碼生成方面：內存管理、數據訪問、函數原型、代碼優化等

因上述方面的成熟度級別和重要性不同，設計模型也各不相同。基于以下定義和描述，圖 7 展示了成熟度和重要性的級別：

成熟度：高（產品）/ 低（原型）

重要性：強制（實線）/ 建議（虛線）

圖 7：設計模型間的關系及對原型開發和產品開發的作用

功能模型應該有結構化的算法，用于通過建模和仿真來對軟件需求進行驗證。用于快速原型的模型代碼生成配置，對在實時環境下驗證軟件需求非常有用。開發的重點應該放在軟件需求上（沒有在圖上表示出來）。整個模型應被視為原型。

架構模型應定義軟件架構中的組件接口和調度。功能模型的架構設計可以作為啟動產品軟件架構開發的基線（1a）。功能模型的原型算法可以移植到架構模型，以便在仿真中對模型進行早期動態驗證，以評估架構對功能行為的影響（2a）。

可以創建軟件架構標準（如 AUTOSAR）的原型代碼生成配置，從而在早期驗證實時環境和軟硬件集成（例如 AUTOSAR RTE）對功能行為的影響。

組件設計模型應對軟件組件的結構、調度和算法進行充分設計定義。模型的接口應該與架構模型（1b）一致，并且可以從架構模型中重用。為功能模型開發的原型算法，可以作為定義產品算法（2b）的基線。原型代碼生成配置可以用于早期驗證，發現設計模型對生成代碼的深層次影響（例如，符合編碼標準，代碼覆蓋率與模型覆蓋率的級別，代碼擴展）。

組件實現模型應該定義軟件組件的設計和實現。結構、調度和算法應該從軟件組件設計模型（1c、2c）中重用。算法的實現方式能隨非功能性需求（例如優化、安全）而調整。代碼生成配置將用于產品代碼生成，并與軟件編碼標準和目標硬件兼容。

設計模型的質量

由于設計模型對于采用基于模型設計的軟件開發非常關鍵，其質量必須仔細評估。設計模型可以自動轉換為其他設計形式，如文檔、源代碼或可執行文件。因此，設計模型定義的質量目標應能影響模型本身及其派生產品。各種類型的設計模型各有其特定的質量目標以對應其特定的角色。

表格 1：設計模型的模型質量目標

表格 2 提供了適用于達到各種類型設計模型的質量目標的模型質量要求。

表格 2：模型質量目標的模型質量要求概覽

M：強制

R：推薦（對于早期驗證）

注：在 DO-331 中需要附加額外從模型到源代碼驗證的模型質量要求。

表格 2 中所有模型質量要求的詳細說明

本文論述了 Simulink 設計模型如何從軟件需求規范到軟件實施以加速開發和驗證活動。介紹了四種服務于特定目的的設計模型類型，每種類型均有特定的質量目標以控制其合適的使用。每個質量目標均為一組帶滿意度量化標準的可度量指標，以便于促進和規范模型質量評估。

應用本文所述概念的組織將能體驗到以下好處：

在組織內部共享基于模型設計的理解

應用合格的模型于基于模型設計項目，且符合行業軟件質量和安全規范

在項目不同階段評估模型質量

與合作伙伴協同實施基于模型設計的組織在應用本文所述概念時將能體驗到以下好處：

在項目初期厘清各方責任

達成對模型質量的同等理解

交換模型時達成對模型質量的同等期望