模型質(zhì)量目標(biāo)（Model Quality Objectives，以下簡稱 MQO）的標(biāo)準(zhǔn)是由一流的汽車廠商和 MathWorks 公司共同制定，目的是當(dāng)在嵌入式軟件開發(fā)中 OEM 和供應(yīng)商進(jìn)行 Simulink 模型共享時，可以清晰定義并簡化雙方的協(xié)作，并最終提高軟件產(chǎn)品的質(zhì)量和完整性。

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

為什么制定模型質(zhì)量目標(biāo)

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

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

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

因此，有可能出現(xiàn)超出計劃的開發(fā)人力投入、問題、與職責(zé)相關(guān)的爭論等。為避免這種情況，文章旨在闡明設(shè)計模型在嵌入式軟件開發(fā)中的作用，并規(guī)范可測量的標(biāo)準(zhǔn)，以驗證其質(zhì)量。

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

制定模型質(zhì)量目標(biāo)的目的是：

為軟件開發(fā)定義設(shè)計模型的主要用例

根據(jù)它們的用例，定義評估模型質(zhì)量的標(biāo)準(zhǔn)和通用方法

軟件開發(fā)和模型設(shè)計

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

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

基于模型設(shè)計/MQO 的軟件開發(fā)生命周期包含五個具體階段，見圖 1 中標(biāo)示的 1 到 5。后面也將講述有關(guān)階段的更多細(xì)節(jié)。

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

圖 2：基于模型設(shè)計/MQO 的軟件階段與其他工業(yè)標(biāo)準(zhǔn)的對照[3][4][5][6]

軟件計劃階段

本節(jié)定義了在準(zhǔn)備使用設(shè)計模型前必須執(zhí)行的計劃活動。這些活動在使用功能模型時是推薦的，在使用架構(gòu)、組件設(shè)計和組件實(shí)現(xiàn)模型時是強(qiáng)制要求的。這些概念中的大多數(shù)已經(jīng)在諸如 DO-331[5]之類的安全標(biāo)準(zhǔn)中得到貫徹。

范圍定義：不是所有的設(shè)計模型都適用于所有的項目。例如，基于模型設(shè)計的范圍可以簡化為單個軟件組件的開發(fā)，或者只被用于支持軟件架構(gòu)設(shè)計規(guī)范。項目應(yīng)定義設(shè)計模型所支持的軟件開發(fā)階段。在所屬的軟件開發(fā)階段，每個設(shè)計模型都應(yīng)該作為其所屬階段的工作產(chǎn)品被獨(dú)立管理。

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

標(biāo)準(zhǔn)定義：在進(jìn)入軟件架構(gòu)階段之前，應(yīng)該定義用于支持設(shè)計模型開發(fā)的建模標(biāo)準(zhǔn)。在進(jìn)入軟件組件實(shí)現(xiàn)階段之前，應(yīng)該定義用于支持設(shè)計模型開發(fā)的編碼標(biāo)準(zhǔn)，或者最好在進(jìn)入軟件組件設(shè)計階段之前定義。

MQR 識別和分配：在項目開始時，項目相關(guān)方應(yīng)識別并同意 MQR。一些 MQR 應(yīng)該隨項目需求（例如，模型和代碼覆蓋度準(zhǔn)則）而調(diào)整。每個 MQR 都將被分配給項目相關(guān)方。

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

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

軟件需求階段

本節(jié)重點(diǎn)介紹軟件需求階段開發(fā)的功能模型。功能模型的作用是澄清和細(xì)化復(fù)雜的動態(tài)行為，這些行為將被轉(zhuǎn)化為軟件需求。

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

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

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

圖3：功能模型的例子（防抱死系統(tǒng)）

軟件架構(gòu)設(shè)計階段

本節(jié)重點(diǎn)介紹軟件架構(gòu)設(shè)計階段開發(fā)的架構(gòu)模型。架構(gòu)模型用于軟件體系結(jié)構(gòu)設(shè)計規(guī)范。

圖形符號天然適合定義組件組織結(jié)構(gòu)、表述接口和連接、說明組件的調(diào)度。對于復(fù)雜的架構(gòu)，如果沒有合適的建模語言，或者是像 Simulink 這樣的計算機(jī)輔助設(shè)計工具，要開發(fā)這樣的圖是無法想象的。

架構(gòu)模型完全確定了靜態(tài)軟件架構(gòu)設(shè)計（如，組件模型、接口），向?qū)⒁獦?gòu)建或者已構(gòu)建好的組件設(shè)計模型提供了鏈接/參考。架構(gòu)設(shè)計模型與數(shù)據(jù)字典關(guān)聯(lián)，該字典定義了軟件及其組件的數(shù)據(jù)和接口。

架構(gòu)模型直接用于設(shè)計活動，因此要符合行業(yè)質(zhì)量標(biāo)準(zhǔn)、安全標(biāo)準(zhǔn)，及/或架構(gòu)標(biāo)準(zhǔn)（如，對需求的可追溯性，與架構(gòu)標(biāo)準(zhǔn)的兼容性。）

圖4 架構(gòu)模型的例子

軟件組件設(shè)計和測試階段

本節(jié)重點(diǎn)介紹組件設(shè)計模型，這些模型是在軟件組件設(shè)計和測試階段產(chǎn)生的。組件設(shè)計模型的作用是：提供軟件組件設(shè)計的完整規(guī)范，并支持其動態(tài)驗證和靜態(tài)分析驗證。

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

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

組件模型直接用于開發(fā)活動，因此需符合行業(yè)質(zhì)量標(biāo)準(zhǔn)、安全標(biāo)準(zhǔn)，及/或設(shè)計標(biāo)準(zhǔn)（如，符合建模規(guī)范，對需求的可追溯性。）

圖 5 展示了一個組件設(shè)計模型的例子，它具有完整定義的接口和用狀態(tài)機(jī)實(shí)現(xiàn)的子功能。

圖 5：組件設(shè)計模型的例子

軟件組件實(shí)現(xiàn)和測試階段

本節(jié)重點(diǎn)介紹組件實(shí)現(xiàn)模型，這些模型是在軟件組件設(shè)計和測試階段產(chǎn)生的。組件實(shí)現(xiàn)模型的作用是：為特定的嵌入式目標(biāo)和基本軟件生成產(chǎn)品代碼。

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

組件實(shí)現(xiàn)模型生成的代碼直接用于開發(fā)活動，因此要符合行業(yè)質(zhì)量標(biāo)準(zhǔn)和安全標(biāo)準(zhǔn)、及/或編碼標(biāo)準(zhǔn)（如，MISRA C）。每個組件實(shí)現(xiàn)模型都與一個定義其接口參數(shù)和監(jiān)視信號的數(shù)據(jù)字典相關(guān)聯(lián)。

圖 6：組件實(shí)現(xiàn)模型的代碼生成配置的例子

設(shè)計模型間的關(guān)系

每個設(shè)計模型都應(yīng)該在其所屬的軟件開發(fā)階段，作為工作產(chǎn)品單獨(dú)進(jìn)行管理。與此同時，設(shè)計模型可以共享設(shè)計信息，并保持一致。例如，圖 5 中的組件設(shè)計模型與圖 4 的架構(gòu)模型共享接口定義。任何需要一致性的時候，都應(yīng)該鼓勵重用。

圖 7 顯示了在設(shè)計模型間哪些方面可以重用（“reuse” 箭頭），它還提供了關(guān)于設(shè)計模型的哪些方面可以被部分重用（“refine” 箭頭）的指導(dǎo)，以加速開發(fā)。圖 7 中的箭頭可以應(yīng)用于設(shè)計模型的以下建模方面：

架構(gòu)方面：接口、調(diào)度、分塊、組件間的控制和數(shù)據(jù)流等

算法方面：數(shù)學(xué)計算、組件控制和數(shù)據(jù)流、狀態(tài)機(jī)、真值表等

代碼生成方面：內(nèi)存管理、數(shù)據(jù)訪問、函數(shù)原型、代碼優(yōu)化等

因上述方面的成熟度級別和重要性不同，設(shè)計模型也各不相同?；谝韵露x和描述，圖 7 展示了成熟度和重要性的級別：

成熟度：高（產(chǎn)品）/ 低（原型）

重要性：強(qiáng)制（實(shí)線）/ 建議（虛線）

圖 7：設(shè)計模型間的關(guān)系及對原型開發(fā)和產(chǎn)品開發(fā)的作用

功能模型應(yīng)該有結(jié)構(gòu)化的算法，用于通過建模和仿真來對軟件需求進(jìn)行驗證。用于快速原型的模型代碼生成配置，對在實(shí)時環(huán)境下驗證軟件需求非常有用。開發(fā)的重點(diǎn)應(yīng)該放在軟件需求上（沒有在圖上表示出來）。整個模型應(yīng)被視為原型。

架構(gòu)模型應(yīng)定義軟件架構(gòu)中的組件接口和調(diào)度。功能模型的架構(gòu)設(shè)計可以作為啟動產(chǎn)品軟件架構(gòu)開發(fā)的基線（1a）。功能模型的原型算法可以移植到架構(gòu)模型，以便在仿真中對模型進(jìn)行早期動態(tài)驗證，以評估架構(gòu)對功能行為的影響（2a）。

可以創(chuàng)建軟件架構(gòu)標(biāo)準(zhǔn)（如 AUTOSAR）的原型代碼生成配置，從而在早期驗證實(shí)時環(huán)境和軟硬件集成（例如 AUTOSAR RTE）對功能行為的影響。

組件設(shè)計模型應(yīng)對軟件組件的結(jié)構(gòu)、調(diào)度和算法進(jìn)行充分設(shè)計定義。模型的接口應(yīng)該與架構(gòu)模型（1b）一致，并且可以從架構(gòu)模型中重用。為功能模型開發(fā)的原型算法，可以作為定義產(chǎn)品算法（2b）的基線。原型代碼生成配置可以用于早期驗證，發(fā)現(xiàn)設(shè)計模型對生成代碼的深層次影響（例如，符合編碼標(biāo)準(zhǔn)，代碼覆蓋率與模型覆蓋率的級別，代碼擴(kuò)展）。

組件實(shí)現(xiàn)模型應(yīng)該定義軟件組件的設(shè)計和實(shí)現(xiàn)。結(jié)構(gòu)、調(diào)度和算法應(yīng)該從軟件組件設(shè)計模型（1c、2c）中重用。算法的實(shí)現(xiàn)方式能隨非功能性需求（例如優(yōu)化、安全）而調(diào)整。代碼生成配置將用于產(chǎn)品代碼生成，并與軟件編碼標(biāo)準(zhǔn)和目標(biāo)硬件兼容。

設(shè)計模型的質(zhì)量

由于設(shè)計模型對于采用基于模型設(shè)計的軟件開發(fā)非常關(guān)鍵，其質(zhì)量必須仔細(xì)評估。設(shè)計模型可以自動轉(zhuǎn)換為其他設(shè)計形式，如文檔、源代碼或可執(zhí)行文件。因此，設(shè)計模型定義的質(zhì)量目標(biāo)應(yīng)能影響模型本身及其派生產(chǎn)品。各種類型的設(shè)計模型各有其特定的質(zhì)量目標(biāo)以對應(yīng)其特定的角色。

表格 1：設(shè)計模型的模型質(zhì)量目標(biāo)

表格 2 提供了適用于達(dá)到各種類型設(shè)計模型的質(zhì)量目標(biāo)的模型質(zhì)量要求。

表格 2：模型質(zhì)量目標(biāo)的模型質(zhì)量要求概覽

M：強(qiáng)制

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

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

表格 2 中所有模型質(zhì)量要求的詳細(xì)說明

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

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

在組織內(nèi)部共享基于模型設(shè)計的理解

應(yīng)用合格的模型于基于模型設(shè)計項目，且符合行業(yè)軟件質(zhì)量和安全規(guī)范

在項目不同階段評估模型質(zhì)量

與合作伙伴協(xié)同實(shí)施基于模型設(shè)計的組織在應(yīng)用本文所述概念時將能體驗到以下好處：

在項目初期厘清各方責(zé)任

達(dá)成對模型質(zhì)量的同等理解

交換模型時達(dá)成對模型質(zhì)量的同等期望