鄭偉 茍斌 吳澤民

摘要：隨著汽車對整車電子系統(tǒng)的開發(fā)需求與依賴程度日益提升，電子控制單元軟件的開發(fā)也越來越復(fù)雜。汽車電子軟件的開發(fā)不同于一般的軟件開發(fā)，除了需要符合軟件開發(fā)標(biāo)準(zhǔn)流程外，還需要滿足功能安全相關(guān)標(biāo)準(zhǔn)。指的推薦的實(shí)施功能安全的有效方式是在企業(yè)已建立的CMMI過程體系基礎(chǔ)上，加入ISO 26262的重要工作產(chǎn)品，將安全生命周期融入產(chǎn)品生命周期當(dāng)中。本文就兩者的融合進(jìn)行了詳細(xì)研究，不但能夠降低實(shí)施功能安全的成本，電同時保證了功能安全活動得到有效執(zhí)行。

關(guān)鍵詞：CMMI-DEV; IS0 26262;功能安全;融合;安全生命周期

1 CMMI-DEV概念

CMMI是一套融合多學(xué)科的、可擴(kuò)充的產(chǎn)品集合，其研制的初步動機(jī)是為了利用兩個或多個單一學(xué)科的模型實(shí)現(xiàn)一個組織的集成化過程改進(jìn)。CMMI的本質(zhì)是軟件管理工程的一個部分。軟件過程改善是當(dāng)前軟件管理工程的核心問題，50多年來計算機(jī)的發(fā)展使人們認(rèn)識到要高效率、高質(zhì)量和低成本地開發(fā)軟件，必須改善軟件生產(chǎn)過程?；谀Ｐ偷倪^程改進(jìn)是指采用能力模型來指導(dǎo)組織的過程改進(jìn)，使之過程能力穩(wěn)定的進(jìn)行改善，該組織也能變得更加成熟。

所謂CMMI-DEV即CMMI for Development開發(fā)模型。該模型主要用于軟件工程、硬件工程、系統(tǒng)工程等產(chǎn)晶開發(fā)領(lǐng)域，基本上覆蓋了產(chǎn)晶研發(fā)的各個過程領(lǐng)域，包括：項目管理、需求、設(shè)計、開發(fā)、驗證、確認(rèn)、配置管理、質(zhì)量保證、決策分析以及對研發(fā)的改進(jìn)和培訓(xùn)等一系列活動。該模型按照成熟度等級的逐步提高，產(chǎn)品開發(fā)企業(yè)的產(chǎn)品研發(fā)風(fēng)險越來越低，研發(fā)效率和質(zhì)量越來越高。

CMMI-DEV包含22個流程領(lǐng)域，其中有16個為核心流程領(lǐng)域，1個為共同使用流程領(lǐng)域，并且有5個為CMMI-DEV所專有的流程領(lǐng)域。所有CMMI-DEV模式中的執(zhí)行方法都是針對發(fā)展者組織的活動，其中5個專門針對發(fā)展相關(guān)之執(zhí)行方法的流程領(lǐng)域分別為需求發(fā)展、技術(shù)解決方案、產(chǎn)品整合、驗證及確認(rèn)。

2 車輛功能安全融合

有關(guān)功能安全最初的國際標(biāo)準(zhǔn)是IEC 61508，針對一般工業(yè)領(lǐng)域的電氣/電子/可編程電子相關(guān)系統(tǒng)的功能安全評估與管控方法加以規(guī)范。而車載電控系統(tǒng)與一般T業(yè)用E/E系統(tǒng)有著一些差異，如成本考量或可靠度要求等，因此在2011年發(fā)布了專屬車輛領(lǐng)域的國際標(biāo)準(zhǔn)ISO 26262，其適用于3.5噸以下客車所裝載的車載電控系統(tǒng)，本標(biāo)準(zhǔn)使得研發(fā)項目清楚定義功能安全相關(guān)系統(tǒng)、硬件與軟件所應(yīng)遵循的共同目標(biāo)，并明確標(biāo)示系統(tǒng)達(dá)成的安全門檻，可作為安全設(shè)計的產(chǎn)品開發(fā)資料。因此企業(yè)在導(dǎo)人CMMI-DEV的同時也應(yīng)加入ISO26262功能安全要求，運(yùn)用在技術(shù)，產(chǎn)品開發(fā)，透過產(chǎn)品開發(fā)生命周期的需求發(fā)展、高階設(shè)計、細(xì)部設(shè)計至系統(tǒng)測試等階段，逐步將安全要求融入到車輛產(chǎn)品設(shè)計中，以兼顧功能安全及產(chǎn)品可靠度，滿足車輛使用者需求。

2.1 ISO 26262標(biāo)準(zhǔn)概述

ISO 26262涵蓋車輛整個生命周期，由管理、開發(fā)、生產(chǎn)、經(jīng)營、維修至報廢皆有相應(yīng)的要求。采用車輛安全完整性等級（簡稱ASIL）的指標(biāo)來評估車載電控系統(tǒng)符合功能安全的程度，ASIL由嚴(yán)重度（ Severity）、暴露幾率（Probahility of Exposure）與可控度（Controllahility）決定，等級分為QM（ Quality Management）與ASIL A至D五種，其中QM等級無需適用ISO 26262，比照一般車輛產(chǎn)業(yè)質(zhì)量管理系統(tǒng)ISO/TS 16949要求即可，而ASIL等級越高，系統(tǒng)功能安全要求越多，故ASIL D設(shè)計開發(fā)的安全考量最為嚴(yán)密。

2.2 產(chǎn)品安全生命周期

車輛產(chǎn)品的安全議題要包含功能導(dǎo)向與質(zhì)量導(dǎo)向的開發(fā)活動與工作產(chǎn)品，ISO 26262正是清楚定義研發(fā)項目的功能安全相關(guān)系統(tǒng)、硬件與軟件所應(yīng)完成的開發(fā)活動與工作產(chǎn)品，形成產(chǎn)品的安全生命周期（Safety lifecycle）的各個階段，完整的架構(gòu)并以V模型為開發(fā)流程模型，如圖1所示。

安全生命周期涵蓋ISO 26262 Part 2至Part 7，整個生命周期分為概念階段、產(chǎn)品開發(fā)與生產(chǎn)交付后等三階段，由綜合說明的功能安全管理起始，往下就是大V模型開始的概念階段，接著是系統(tǒng)層、硬件層、軟件層的產(chǎn)品開發(fā)與結(jié)束的產(chǎn)品和運(yùn)行，其間系統(tǒng)層產(chǎn)品開發(fā)包含硬件層產(chǎn)品開發(fā)與軟件層產(chǎn)品開發(fā)兩章，形成系統(tǒng)、子系統(tǒng)的層級架構(gòu)，而軟、硬件開發(fā)又各成一小V模型，兩者并有相互關(guān)聯(lián)，確保系統(tǒng)開發(fā)是軟硬兼顧。詳見圖2所示。

3 CMMI-DEV與IS0 26262比較

ISO 26262只專注于功能安全，作業(yè)與CMMI-DEV的ML2與ML3流程相當(dāng)，需搭配系統(tǒng)工程CMMI-DEV完整的路線圖，才能有效導(dǎo)入組織運(yùn)作，兩者關(guān)系的異同比較如圖3所示。

進(jìn)一步比較CMMI-DEV與ISO 26262如表1所示，尋找ML3流程與安全生命周期的相互關(guān)聯(lián)，以建立完整的機(jī)制，密切相關(guān)的流程有RD、PP、TS、PI與V&V;。

組織級過程焦點(diǎn)（ OPF）與需求管理（ REQM）雖未直接對應(yīng)ISO 26262安全生命周期，但前者透過過程行動計劃（ PAP），將功能安全要求融入流程，而后者對安全需求在生命周期進(jìn)行管理。

4 融合具體方案

因為ISO 26262專注要求功能安全，需搭配系統(tǒng)T程CMMI-DEV完整的路線圖，才能形成完整的機(jī)制，滿足車載電控系統(tǒng)安全又可靠的需求。進(jìn)一步說明表1的對應(yīng)內(nèi)容，提供研發(fā)流程融人功能安全的可行方案。

4.1 通用實(shí)踐（GP）

CP2.1組織政策需含2-5整體安全管理、CP2.3提供資源則是納入6-5軟件層產(chǎn)品開發(fā)初始化與8 -10文檔化。

4.2 組織過程定義（OPD）

SP1.1建立標(biāo)準(zhǔn)過程同前，需包含2-5整體安全管理、SP1.2建立生命周期模型說明則納入2-6安全管理、SP1.3建立剪裁準(zhǔn)則和指南需增加3-6安全生命周期初始化。

4.3 組織培訓(xùn)管理（OT）

培訓(xùn)管理政策同前，需包含2-5整體安全管理。

4.4需求開發(fā)（RD）

集成產(chǎn)品和過程開發(fā)（ Inlegrated Prndwt and Process Development，IPPD）的系統(tǒng)集成團(tuán)隊同前，需包含2-5整體安全管理、SP1.1引導(dǎo)需求與SP1.2轉(zhuǎn)化關(guān)鍵人員需要為客戶需求兩者均需含3—5項目定義、軟件需求規(guī)格（ SRS）增加3-6安全生命周期初始化、3-7危害分析與風(fēng)險評估，3-8功能安全概念，4-6技術(shù)安全需求規(guī)范，5-6硬件安全需求規(guī)范。

4.5 項目計劃（PP）+集成項目管理（IPM）

集成項月執(zhí)行規(guī)劃書（ IPEP）增加安全管理計劃，包含安全生命周期、系統(tǒng)/硬件/軟件層、軟/硬件零件再用。

4.6 項目監(jiān)督與控制（PMC）+集成項目管理（IPM）

集成項目執(zhí)行規(guī)劃書（ IPEP）的項目監(jiān)督與控制（ PMC）計劃增加2-6安全管理與4-10功能安全評估計劃與執(zhí)行。

4.7 供貨商協(xié)議管理（SAM）

集成項目執(zhí)行規(guī)劃書（ IPEP）的供貨商協(xié)議管理（ SAM）計劃增加8-5分布式開發(fā)接口、執(zhí)行面需含8 -12軟件組件條件與8-13硬件組件條件。

4.8 風(fēng)險管理（RSKM）

集成項目執(zhí)行規(guī)劃書（ IPEP）的風(fēng)險管理（ RSKM）計劃增加3-7危害分析與風(fēng)險評估。

4.9 技術(shù)解決方案（TS）

系統(tǒng)設(shè)計說明書（ SDS）增加2-6安傘管理，2-7項目生產(chǎn)交付后的安全管理，3-6安全生命周期初始化、3-7危害分析與風(fēng)險評估，3-8功能安全概念，4-6技術(shù)安全需求規(guī)范，4-7系統(tǒng)設(shè)計，5-6硬件安全需求規(guī)范，5-7硬件設(shè)計，5-8硬件架構(gòu)指標(biāo)評價，5-9安全目標(biāo)因硬件隨機(jī)失效影響評價，6-5軟件層產(chǎn)品開發(fā)初始化，6-6軟件安全需求規(guī)范，6-7軟件架構(gòu)設(shè)計，6-8軟件單元設(shè)計與執(zhí)行，6-11軟件安全需求確認(rèn)，7-5生產(chǎn)，7-6操作與服務(wù)（保養(yǎng)、維修）和報廢，8-12軟件組件條件，8-13硬件組件條件，8-14應(yīng)用證明，9-5對ASIL剪裁的需求分解，9-6組件的共存準(zhǔn)則，9-7相關(guān)失效分析，9-8安全分析。

4.10 產(chǎn)品集成（Pl）

系統(tǒng)集成測試規(guī)劃書（ STP）增加2-6安全管理，4-5系統(tǒng)層產(chǎn)品開發(fā)初始化，4-6技術(shù)安全需求規(guī)范，5-6硬件安全需求規(guī)范，5-10硬件集成與測試，6-10軟件集成與測試，6-11軟件安傘需求確認(rèn)，8-13硬件組件條件，8-14應(yīng)用證明。

4.11 驗證（VER）

集成項日執(zhí)行規(guī)劃書（ IPEP）的驗證（ VER）計劃增加2-6安全管理、執(zhí)行面需含3-7危害分析與風(fēng)險評估與3-8功能安全概念、同業(yè)互查（ Peer Review）增加4-6技術(shù)安全需求規(guī)范，4-7系統(tǒng)設(shè)計，5-6硬件安全需求規(guī)范，5-7硬件設(shè)計，5-8硬件架構(gòu)指標(biāo)評價，5-9安全目標(biāo)因硬件隨機(jī)失效影響評價，6-5軟件層產(chǎn)品開發(fā)初始化，6-6軟件安全需求規(guī)范，6-7軟件架構(gòu)設(shè)計，6-8軟件單元設(shè)計與執(zhí)行，6-9軟件單元測試，6-10軟件集成與測試，6-11軟件安全需求確認(rèn)，8-9確認(rèn)。

4.12 確認(rèn)（VAL）

集成項目執(zhí)行規(guī)劃書（ IPEP）的確認(rèn)（ VAL）計劃增加2-6安全管理，4-5系統(tǒng)層產(chǎn)品開發(fā)初始化，4-6技術(shù)安全需求規(guī)范。

4.13 測量與分析（MA）

集成項日執(zhí)行規(guī)劃書（ IPEP）的測量與分析（ MA）計劃增加5-8硬件架構(gòu)指標(biāo)評價，5-9安全目標(biāo)因硬件隨機(jī)失效影響評價。

4.14 過程和產(chǎn)品質(zhì)量保證（PPQA）

集成項目執(zhí)行規(guī)劃書（ IPEP）的過程和產(chǎn)品質(zhì)量保證（ PPQA）計劃增加2-6安全管理。

4.15 配置管理（CM）

集成項目執(zhí)行規(guī)劃書（ IPEP）的配置管理（ CM）計劃增加8-7配置管理，8-8變更管理，8—11在用軟件工具信任，8-12軟件組件條件，8-13硬件組件條件，8-14應(yīng)用證明。

5 結(jié)論

ISO 26262與CMMI-DEV必須相輔相成，缺一不可。藉由CMMI-DEV ML3建立的流程、生命周期與系統(tǒng)工程方法，再融入ISO 26262功能安全要求，使車載電控系統(tǒng)兼顧功能安全與產(chǎn)品可靠度。

參考文獻(xiàn)：

[1]P. A. Trisha Jansma and Ross M.Jones Advancing the Practice of Systems Engineering at JPL. Systems Engineering Advam：ement （SEA） Projecr， Jet PropulsionLaboratory （JPL）， 2006.

[2]NASA Headquarters. System Engineering Handbook，1th Edition. National Aeronautics and SpaceAdministration （NASA）， Washington D.C.， 2007.

[3]SE Handbook Working Group. System EngineeringHandbook， 3.2.2 Edition. Intemational Council oiiSystem Engineering （INCOSE）， San Diego， 2011

[4]CMMI for Development， Version 1.3. CMMI ProductTeam. CMU/SEI-2010-TR-033， 2010.

[5]Road vehicles-Functional safety， Part 1-10. ISO/TC22/SC3， 2011.