——基于ASPICE與ISO26262的模型質(zhì)量保障深度實踐
作者 |小新
小編 |不吃豬頭肉
隨著汽車電動化與智能化的不斷深入，基于模型的開發(fā)（Model-Based Development，MBD）已成為復雜系統(tǒng)開發(fā)的核心范式。在此背景下，模型靜態(tài)測試憑借其早期缺陷檢測能力，以及企業(yè)對開發(fā)效率、功能安全及ASPICE合規(guī)的日益重視，在汽車電子系統(tǒng)開發(fā)中得到廣泛應用。
本文將從開發(fā)效率提升和行業(yè)合規(guī)實踐兩個維度，系統(tǒng)闡述模型靜態(tài)測試的技術(shù)必要性。通過分析其在質(zhì)量保障體系中的關(guān)鍵作用，幫助開發(fā)者深入理解該技術(shù)在智能汽車開發(fā)流程中的戰(zhàn)略地位。

從高效 MBD 開發(fā)視角：模型質(zhì)量是效率基石
在 MBD 中，模型是功能實現(xiàn)的載體，需求通過模型轉(zhuǎn)化為可執(zhí)行邏輯，代碼由模型自動生成，且模型本身是早期測試驗證的原型。因此，保障了模型質(zhì)量，MBD效率也會得到基本保障。

模型質(zhì)量需從雙維度考量

設(shè)計質(zhì)量：關(guān)注模型的內(nèi)在結(jié)構(gòu)特性，模塊化、可讀性、穩(wěn)健性等等。功能質(zhì)量：模型是否符合功能需求。
二者相輔相成，并且設(shè)計質(zhì)量的好壞會影響功能的實現(xiàn)，以及后續(xù)對功能的驗證。那么我們?nèi)绾未_保設(shè)計質(zhì)量呢？
首先我們可以通過遵循業(yè)內(nèi)權(quán)威機構(gòu)發(fā)布的建模規(guī)范，如MAB、MISRA AC SL/SF，這些規(guī)范源自專家專業(yè)知識的“最佳實踐”。

圖1 建模規(guī)范
其有助于提高模型的可讀性、可維護性、防止使用風險結(jié)構(gòu)、避免常見錯誤、增強魯棒性和提高建模效率并能夠改進生成的代碼。

如：

db_0141-Signal flow in Simulink models 對信號流的檢測，遵守可提高可讀性。

示例：

圖2 規(guī)范db_0141示例

sdt_sc004-Strong Data Typing of Arithmetic Blocks對算數(shù)模塊涉及到的信號的數(shù)據(jù)類型的檢測：必須設(shè)置選項“Require all inputs to have the same data type”、輸入信號的縮放和最小/最大值必須一致、輸出數(shù)據(jù)類型的數(shù)據(jù)范圍必須足以容納四則運算的任何結(jié)果。遵守此規(guī)范可以改進生成的代碼，增強代碼魯棒性。示例：

圖3 規(guī)范sdt_sc004示例
另外可以通過分析模型的復雜度和耦合程度等，了解模型對于可測性和可維護性的支持程度。
上述內(nèi)容均屬于模型靜態(tài)測試的范疇，所以只有通過靜態(tài)測試提前筑牢設(shè)計質(zhì)量，才能實現(xiàn) MBD 流程的高效運轉(zhuǎn)，避免后期因模型缺陷導致的反復返工。

從ASPICE和功能安全視角：靜態(tài)測試是合規(guī)的重要保障
2.1ASPICE 合規(guī)性
在 ASPICE SWE.4 中，明確要求對軟件單元實施靜態(tài)驗證，并建立軟件單元與靜態(tài)驗證結(jié)果之間的雙向可追溯性。盡管標準未明確提及模型靜態(tài)測試，但如前文所述，模型靜態(tài)測試可以顯著提升軟件質(zhì)量、降低缺陷率，因此將其納入實踐，是確保符合 ASPICE 要求的重要保障。

圖4 ASPICE標準概覽
2.2功能安全合規(guī)性
在功能安全中明確推薦將MBD方法應用在安全關(guān)鍵型軟件的開發(fā)當中，并要求模型設(shè)計應具有一致性、可理解性、適用性、正確性、簡潔性、魯棒性和可驗證性。為實現(xiàn)這些模型屬性，ISO 26262:2018第6部分軟件級產(chǎn)品開發(fā)中提出了系統(tǒng)的設(shè)計原則，具體體現(xiàn)在三個表格中：表一，建模和編碼指南應該涵蓋的主題；表三，軟件架構(gòu)設(shè)計的原則；表六，軟件單元設(shè)計和實現(xiàn)的設(shè)計原則。

圖5 IS0 26262系列標準概述
其中軟件架構(gòu)設(shè)計原則中提到的軟件組件的有限大小和復雜性，接口的有限大小，軟件組件內(nèi)的強內(nèi)聚，組件間的松散耦合等等，需要了解相關(guān)的模型屬性之后才能去遵守。

示例：MXAM分析當前子系統(tǒng)復雜度為470，復雜程度較高。

圖6 更改前模型

經(jīng)過更改之后復雜程度降為165，模型的可讀性隨之變高。

圖7 更改后模型
建模和編碼指南應該涵蓋的主題和軟件單元設(shè)計和實現(xiàn)的設(shè)計原則則可以通過遵循建模規(guī)范去滿足。
如建模規(guī)范jc_0642-Integer rounding mode setting對應的是表T1.1b Use of Language Subsets 的設(shè)計原則。
jc_0650-Block input/output data type with switching function符合的是表T6.1g No Implicit Type Conversions 的設(shè)計原則。
當然上述內(nèi)容均屬于模型靜態(tài)測試的范疇，所以想要符合功能安全模型靜態(tài)分析是重要保障。

專業(yè)工具賦能：MXAM 助力靜態(tài)測試高效落地
面對復雜的建模規(guī)范與安全要求，手動檢查和修復模型效率低且易漏判，所以我們推薦使用靜態(tài)模型分析工具MXAM ，其可以幫您解決軟件開發(fā)過程中的痛點：

1.提供全面的定制化，支持更多來自MAB、MISRA、dSPACE、MES等行業(yè)機構(gòu)發(fā)布的建模規(guī)范。

2.交互式報告頁面可指導用戶直達模型出現(xiàn)問題的部分，且可自動修復部分不符合規(guī)范的建模。

自動修復示例：mes_slsf_1301 Redundant Condition Actions具有相同目的地的不同轉(zhuǎn)換線不應該包含相同的條件動作。

圖8 自動修復示例

3.更豐富的模型度量指標并且包含模型重構(gòu)功能，幫助您快速重構(gòu)您的模型。

圖9 MXAM工作流程

總結(jié)
模型靜態(tài)測試不僅是 MBD 開發(fā)提效的 “加速器”，更是ASPICE和功能安全合規(guī)的 “關(guān)鍵基石”，通過模型靜態(tài)測試企業(yè)可在開發(fā)早期筑牢質(zhì)量根基，避免后期高額返工成本。MXAM 的應用，讓靜態(tài)測試從 “人工經(jīng)驗驅(qū)動” 升級為 “數(shù)據(jù)與工具驅(qū)動”，助力企業(yè)在智能化浪潮中實現(xiàn)高效開發(fā)與安全合規(guī)的雙重目標。