王曼，張舟云，張冀，陳雷，潘緒前

(1.上海汽車電驅(qū)動(dòng)有限公司 電控開發(fā)部，上海201806；2.上海汽車電驅(qū)動(dòng)工程技術(shù)研究中心有限公司 專家委員會(huì)，上海201806)

0 引言

隨著汽車電子電氣架構(gòu)逐漸從分布式轉(zhuǎn)向集中型，逐漸集中的汽車電子電氣架構(gòu)對(duì)車載ECU的嵌入式系統(tǒng)軟件提出了多方面、更復(fù)雜的需求，軟件需求作為軟件開發(fā)的初始輸入，來源多為與客戶一起建立并不斷更新的需求和軟件開發(fā)、測(cè)試、管理等提出的需求[1-2]。嵌入式系統(tǒng)軟件開發(fā)的全生命周期都在需求指導(dǎo)下展開，需求一旦出錯(cuò)或?qū)?dǎo)致軟件的缺陷或產(chǎn)品返工，需求缺陷經(jīng)變更糾正后，往往要針對(duì)需求變更進(jìn)行大量回歸驗(yàn)證測(cè)試，造成人力、物力和時(shí)間的巨大耗費(fèi)，導(dǎo)致項(xiàng)目延期以及開發(fā)成本超出預(yù)算的惡性后果。此外，鑒于乘用汽車的應(yīng)用場(chǎng)景，安全相關(guān)需求問題導(dǎo)致的缺陷，一旦流出到用戶端或?qū)砣松砩踩碾[患。因此，對(duì)嵌入式系統(tǒng)軟件安全需求的管理重要性極高，作為開發(fā)工作的前級(jí)，需求管理必須依據(jù)一定的原則謹(jǐn)慎開展。

1 嵌入式系統(tǒng)軟件需求管理的常見問題

車載ECU嵌入式系統(tǒng)軟件需求條目多，牽涉范圍廣，隨項(xiàng)目實(shí)際情況不斷更新，變更時(shí)間緊。在需求管理中存在的常見問題[3]，一是需求不明確，用戶對(duì)產(chǎn)品的需求定義不明確，或者收集需求時(shí)解讀需求出現(xiàn)解讀錯(cuò)誤、遺漏，導(dǎo)致后續(xù)產(chǎn)品開發(fā)過程頻頻變更需求。二是需求追溯困難，來自客戶的需求多為企標(biāo)、國(guó)標(biāo)、技術(shù)規(guī)格要求等，常以word格式或者pdf格式提出，需求范圍過大，梳理困難，需求的劃分界限模糊，需求驗(yàn)證易遺漏。三是項(xiàng)目時(shí)間緊張導(dǎo)致需求的細(xì)致程度不足，需求的細(xì)致程度很難掌握。四是需求變更頻繁，需求變更在產(chǎn)品開發(fā)中是必然存在的，頻繁的變更需要更完善的變更管理及良好的溝通機(jī)制。

傳統(tǒng)的需求管理工具多為文本文檔或表格，存在以下問題：一是需求存儲(chǔ)時(shí)版本多，需要有專人管理各個(gè)版本的需求，工程師從特定人員處獲得某版本的需求，浪費(fèi)人力。二是追溯困難，通過在需求后加備注說明的形式進(jìn)行追溯，容易出錯(cuò)并且多層次需求的組織結(jié)構(gòu)顯示不直觀。三是需求變更時(shí)對(duì)人工操作依賴太多，多個(gè)變更流程同時(shí)進(jìn)行時(shí)流程復(fù)雜，出錯(cuò)概率大大增加。四是需求存儲(chǔ)常以復(fù)制副本方式進(jìn)行備份，對(duì)版本共享造成不便。五是權(quán)限分配難細(xì)分，修改需求時(shí)常常是串行工作，甲和乙無法同時(shí)編輯，或者甲無意間篡改了乙的內(nèi)容，導(dǎo)致需求內(nèi)容出現(xiàn)差錯(cuò)。

2 功能安全標(biāo)準(zhǔn)對(duì)軟件安全需求的要求

ISO/FDIS 26262是以IEC 61508為基礎(chǔ)[4]，為滿足道路車輛上特定電子電氣系統(tǒng)的需求而編寫，適用于道路車輛上特定的由電子、電氣和軟件組件組成的安全相關(guān)系統(tǒng)在安全生命周期內(nèi)的所有活動(dòng)。ISO/FDIS 26262-8在6.4 Requirements and recommendations章節(jié)中提出了企業(yè)在進(jìn)行車載ECU軟件開發(fā)過程中對(duì)軟件安全需求的要求。軟件開發(fā)參考階段模型見圖1，技術(shù)安全概念、測(cè)試要求、設(shè)計(jì)階段驗(yàn)證是軟件安全需求的輸入，安全需求是進(jìn)行軟件架構(gòu)設(shè)計(jì)的重要前提[5]。

圖1 軟件開發(fā)參考階段模型

在需求管理下的安全需求應(yīng)有如下特性：

a）需求的描述應(yīng)明確，沒有歧義。b）相關(guān)者對(duì)需求的理解能達(dá)成共識(shí)。c）一條需求不能被劃分為兩個(gè)以上的獨(dú)立安全需求。d）內(nèi)在一致性，每個(gè)單獨(dú)的安全需求不包含自相矛盾的內(nèi)容。e）在項(xiàng)目開發(fā)的條件限制(資源、最新技術(shù)等)下，需求應(yīng)可以在技術(shù)上實(shí)現(xiàn)，并且可以接受項(xiàng)目的約束條件。f）需求應(yīng)該可以被驗(yàn)證，提供證據(jù)證明需求被滿足。g）需求的必要性，如果它被移除或刪除，就會(huì)存在產(chǎn)品或過程的其他能力不能滿足的缺陷。需求適用于當(dāng)前項(xiàng)目，不會(huì)隨著時(shí)間的推移而過時(shí)，并應(yīng)有符合預(yù)期的截止日期或適用日期。h）需求的目標(biāo)是實(shí)現(xiàn)獨(dú)立的執(zhí)行，應(yīng)避免對(duì)軟件架構(gòu)設(shè)計(jì)施加不必要的限制。i）需求的表述是清晰的，沒有隱含進(jìn)一步的擴(kuò)展。j）需求應(yīng)符合適用的政府、汽車行業(yè)、產(chǎn)品標(biāo)準(zhǔn)、規(guī)范和接口要求。安全需求的集合應(yīng)具有如下特性：

a）分層結(jié)構(gòu)，安全需求是由幾個(gè)連續(xù)層面構(gòu)建而成的，這些層面與相應(yīng)的設(shè)計(jì)階段保持一致。b)依據(jù)恰當(dāng)編組原則建立有組織的結(jié)構(gòu)。c)完整性，一個(gè)層面的安全需求完整的實(shí)施了前一層面的全部安全需求。d)外部一致性，多個(gè)安全需求不互相抵觸。e)分層結(jié)構(gòu)中任意一層的信息不重復(fù)，安全需求的內(nèi)容不重復(fù)出現(xiàn)在分層結(jié)構(gòu)同一層面的其它安全要求中，并且每個(gè)分層層面都是如此。f）可維護(hù)性，需求集合可以被修改或擴(kuò)展，例如新版本需求的引入，或者在需求集合中添加/刪除需求。

3 基于DOORS的軟件安全需求管理活動(dòng)實(shí)踐

需求管理的傳統(tǒng)方法，即依靠word或excel文件管理安全需求已遠(yuǎn)不能滿足功能安全國(guó)際標(biāo)準(zhǔn)ISO/FDIS 26262對(duì)軟件安全需求集合管理的要求，為了支持對(duì)安全需求的管理，ISO/FDIS 26262推薦使用合適的要求管理工具。IBM Rational DOORS是一款需求管理應(yīng)用程序[6]，可以捕獲、連接、跟蹤、分析和管理用戶需求信息以保證實(shí)施的項(xiàng)目與需求規(guī)格說明和標(biāo)準(zhǔn)一致[7]。以專業(yè)的需求管理工具DOORS替代傳統(tǒng)word、excel方式進(jìn)行需求管理，一方面符合ISO/FDIS 26262、第三方評(píng)審機(jī)構(gòu)在認(rèn)證評(píng)審中對(duì)需求管理工具的要求，另一方面可以實(shí)現(xiàn)需求細(xì)化存儲(chǔ)、版本控制、方便評(píng)審、需求多層追溯、簡(jiǎn)化流程、權(quán)限細(xì)分，解決傳統(tǒng)管理方式存在的一些問題。

3.1 評(píng)審安全需求

在需求開發(fā)完成之后，需要進(jìn)行分配評(píng)審，DOORS管理每一條安全需求時(shí)以需求模塊為管理單位，在模塊中每條需求和其附屬的屬性以一行對(duì)象形式存儲(chǔ)，層次清晰，方便評(píng)審。需求集合應(yīng)滿足如下要求：

a)在整個(gè)安全生命周期中保持不變的唯一標(biāo)識(shí)。安全要求應(yīng)是可追溯的，以ID號(hào)為需求的唯一標(biāo)識(shí)。b)對(duì)需求內(nèi)容的明確描述。c)明確主要責(zé)任人。d)與該需求有關(guān)聯(lián)的關(guān)系追溯，例如安全目標(biāo)分解成下一個(gè)層次的需求。e)該需求相關(guān)，必須提供的一些屬性，例如ASIL等級(jí)、FTTI等。f)需求的實(shí)時(shí)狀態(tài)。例如完全滿足，正在驗(yàn)證，設(shè)計(jì)階段，發(fā)起變更，正在評(píng)審，評(píng)審未通過，評(píng)審?fù)ㄟ^，未滿足。g）需求模塊擁有版本號(hào)，以區(qū)分不同需求版本。

3.2 安全需求追溯管理

使用DOORS工具進(jìn)行需求管理，最大的優(yōu)勢(shì)在于維護(hù)不同層次需求之間的追溯關(guān)系。需求之間的追溯關(guān)系通過建立鏈接來體現(xiàn)[8]，分為模塊內(nèi)鏈接和模塊間鏈接以及外部鏈接。鏈接指向的常用規(guī)則是，由底層需求指向上層需求，例如測(cè)試項(xiàng)指向功能塊，功能塊指向TSR，TSR指向FSR，F(xiàn)SR指向最頂級(jí)的需求安全目標(biāo)SG。

鏈接建立完成之后，DOORS會(huì)自動(dòng)建立一個(gè)鏈接模塊，和已建立的正式模塊并列存儲(chǔ)，存放鏈接的信息。鏈接模塊是需求之間建立追溯的前提條件及重要追溯工具。

3.3 使用基線

使用基線可以有效備份多個(gè)版本，為提高管理效率，需要定期創(chuàng)建模塊的基線，每次變更涉及到的模塊需要打基線，使用基線時(shí)應(yīng)描述變更內(nèi)容?；€是模塊的只讀版本，復(fù)制基線時(shí)，將創(chuàng)建新模塊，新模塊可以復(fù)制基線中的所有信息，新模塊與基線包含的數(shù)據(jù)完全相同，新模塊不包含任何歷史記錄信息和任何鏈接。

3.4 變更評(píng)審

安全需求的變更，是多方共同協(xié)商認(rèn)可的結(jié)果，因此變更過程及結(jié)果需變更發(fā)起人通知所有相關(guān)方。開展需求變更分析[9-10]，分析結(jié)果應(yīng)明確變更相關(guān)的任務(wù)，并評(píng)估完成變更相關(guān)任務(wù)所需資源及工作量，需求變更分析將有助于領(lǐng)導(dǎo)層作出更適宜的決策。需求的變更引起需求版本的更迭，需求儲(chǔ)存在模塊中，模塊的版本管理通過基線實(shí)現(xiàn)。變更驗(yàn)證需比較同一個(gè)模塊兩次基線之間的不同，可以使用DOORS工具提供的過濾器或者基線比較功能，或者模塊比較功能。

3.5 權(quán)限控制

DOORS工具支持對(duì)需求管理進(jìn)行權(quán)限細(xì)分，不僅可以對(duì)模塊進(jìn)行權(quán)限分配，更可以對(duì)每一行對(duì)象進(jìn)行人員權(quán)限控制，允許多人同時(shí)編輯，權(quán)限分配可做到極為精細(xì)，節(jié)省大量人力物力。

4 結(jié)語

需求管理是開啟嵌入式系統(tǒng)軟件開發(fā)工作的前提條件，貫穿于整個(gè)項(xiàng)目生命周期中，基于 DOORS工具的軟件安全需求管理，可以提高安全需求管理效率，解決了需求管理的細(xì)分、追溯、版本控制、權(quán)限控制等問題?；贒OORS工具的軟件安全需求管理，應(yīng)遵循ISO/FDIS 26262的指導(dǎo)思想，才能在需求管理中充分實(shí)踐發(fā)揮作用，縮短理論和實(shí)踐之間的距離。