蘇萬檣，謝小娟

（奇瑞汽車股份有限公司，安徽 蕪湖 241009）

嵌入式系統(tǒng)是一種完全嵌入受控器件內(nèi)部、為特定應(yīng)用而設(shè)計(jì)的專用計(jì)算機(jī)系統(tǒng)，通常執(zhí)行的是帶有特定要求的預(yù)先定義的任務(wù)。在汽車上嵌入式系統(tǒng)的應(yīng)用也是隨處可見的：發(fā)動(dòng)機(jī)控制、變速器控制、車身控制、ABS、車載導(dǎo)航、車載娛樂系統(tǒng)等，都是嵌入式系統(tǒng)的典型應(yīng)用。但由于汽車是一種可移動(dòng)的高速交通工具，是一種涉及到駕駛員、乘客、周邊人員及環(huán)境的交互復(fù)雜系統(tǒng)，對(duì)于車上與人身安全相關(guān)的嵌入式系統(tǒng)，一旦發(fā)生失效或故障，就可能造成車毀人亡的嚴(yán)重后果，相關(guān)廠家也要承受巨大的車輛召回?fù)p失和商譽(yù)損失。因此，汽車上使用的與安全相關(guān)的嵌入式系統(tǒng)，比如發(fā)動(dòng)機(jī)控制系統(tǒng)EMS、自動(dòng)制動(dòng)防抱死系統(tǒng)ABS、安全氣囊控制系統(tǒng)等，與一般的嵌入式系統(tǒng)相比，對(duì)可靠性的要求更高。與此同時(shí)，隨著各種新技術(shù)的使用，使得汽車嵌入式系統(tǒng)的功能也越來越復(fù)雜，采用怎樣的流程和方法來高效地開發(fā)高復(fù)雜度同時(shí)又具備高可靠性的車用嵌入式系統(tǒng)，一直成為業(yè)內(nèi)開發(fā)人員研究的熱點(diǎn)［1］。

1 基于模型的V字開發(fā)流程

隨著計(jì)算機(jī)技術(shù)的發(fā)展，基于模型的V字開發(fā)流程，已經(jīng)成為高可靠性汽車嵌入式系統(tǒng)開發(fā)方式的主流。這種方式以模型描述業(yè)務(wù)邏輯，通過自動(dòng)代碼生成工具，從描述業(yè)務(wù)邏輯的模型直接生成上層代碼，再與底層手寫代碼及相關(guān)硬件集成，有效解決了開發(fā)高復(fù)雜度嵌入式系統(tǒng)的 難 題［2］。 典 型 的 基于模型的V字開發(fā)流程如圖1所示。

圖1所述各個(gè)流程的活動(dòng)、執(zhí)行人員及交付物詳述如下。

1）系統(tǒng)定義 這個(gè)階段的活動(dòng)是明確所需要開發(fā)的系統(tǒng)的各項(xiàng)性能指標(biāo)，包括可靠性、成本方面的要求。這些性能指標(biāo)必須是可量化可驗(yàn)證的。本階段的輸入材料一般為客戶合同、項(xiàng)目可行性分析報(bào)告、適用的法規(guī)標(biāo)準(zhǔn)等文檔。本階段的執(zhí)行人員一般是項(xiàng)目組織人員及項(xiàng)目管理人員。本階段的輸出交付物為系統(tǒng)定義文檔。

2）需求分析 這個(gè)階段的活動(dòng)是根據(jù)系統(tǒng)定義的要求，從系統(tǒng)使用者的角度制定詳細(xì)的系統(tǒng)開發(fā)需求。為便于需求的管理，此處編寫的需求以條目的形式呈現(xiàn)，要求制定的每一條需求不重復(fù)、不遺漏、可測(cè)試。本階段的輸入材料為1）的輸出交付物系統(tǒng)定義文檔。本階段的執(zhí)行人員一般是系統(tǒng)開發(fā)方的資深工程師、整體架構(gòu)設(shè)計(jì)師等人員。本階段的輸出交付物為需求定義文檔。

3）架構(gòu)設(shè)計(jì) 這個(gè)階段的活動(dòng)是根據(jù)需求定義，對(duì)整體需求劃分模塊，并制定各模塊之間的接口文檔。一般可以劃分為上層業(yè)務(wù)邏輯模塊、底層手寫代碼模塊、硬件模塊，當(dāng)系統(tǒng)比較復(fù)雜的時(shí)候，還可以將這3個(gè)大模塊進(jìn)一步劃分。本階段的輸入材料為2）的輸出交付物需求定義文檔。本階段的執(zhí)行人員一般為系統(tǒng)開發(fā)方的架構(gòu)設(shè)計(jì)師或總體工程師。本階段的輸出交付物為模塊接口文檔。

4）模塊開發(fā) 這個(gè)階段的活動(dòng)是各模塊的開發(fā)人員根據(jù)劃分后的模塊需求和接口文檔，各自進(jìn)行所負(fù)責(zé)模塊的開發(fā)。一般包括上層業(yè)務(wù)邏輯模塊、底層手寫代碼模塊、硬件模塊的開發(fā)。上層業(yè)務(wù)邏輯模塊通過建模工具來實(shí)現(xiàn)業(yè)務(wù)邏輯模型，再利用自動(dòng)代碼生成工具，將此業(yè)務(wù)邏輯模型直接轉(zhuǎn)換為C代碼。底層手寫代碼模塊一般是底層硬件驅(qū)動(dòng)及軟件服務(wù)，根據(jù)接口文檔開發(fā)。硬件模塊則是嵌入式系統(tǒng)的硬件實(shí)體。本階段的輸入材料為2）的輸出交付物需求定義文檔和3）的輸出交付物模塊接口文檔。本階段的執(zhí)行人員為各模塊的責(zé)任開發(fā)工程師。本階段的輸出交付物為策略模型及自動(dòng)生成代碼、底層軟件手寫代碼、控制器硬件樣件及各模塊的設(shè)計(jì)文檔。

5）系統(tǒng)集成 這個(gè)階段的活動(dòng)是將上層業(yè)務(wù)邏輯模型自動(dòng)生成的代碼和底層軟件手寫代碼集成編譯，形成可執(zhí)行文件，并刷入相應(yīng)的控制器硬件中，形成一個(gè)可運(yùn)行的控制器樣件。本階段的輸入材料為4）的輸出交付物策略模型及自動(dòng)生成代碼、底層軟件手寫代碼、控制器硬件樣件。本階段的執(zhí)行人員為系統(tǒng)集成工程師。本階段的輸出交付物為可運(yùn)行的控制器樣件。

6）單元測(cè)試 這個(gè)階段的活動(dòng)是以各個(gè)模塊為單元，按各模塊的設(shè)計(jì)文檔編寫單元測(cè)試用例，測(cè)試各模塊的所有功能是否實(shí)現(xiàn)，并對(duì)軟件模塊的代碼覆蓋率進(jìn)行評(píng)估；對(duì)硬件模塊的設(shè)計(jì)性能進(jìn)行測(cè)試，評(píng)估硬件各項(xiàng)指標(biāo)是否達(dá)到設(shè)計(jì)要求。此階段測(cè)試主要為白盒測(cè)試。本階段的輸入材料為4）的輸出交付物各模塊的設(shè)計(jì)文檔。本階段的執(zhí)行人員為各模塊的責(zé)任開發(fā)工程師。本階段的輸出交付物為各模塊的單元測(cè)試報(bào)告文檔。

7）集成測(cè)試 這個(gè)階段的活動(dòng)是將對(duì)集成后的控制系統(tǒng)進(jìn)行集成測(cè)試，重點(diǎn)測(cè)試各模塊的接口功能。根據(jù)模塊接口文檔編寫測(cè)試用例和測(cè)試計(jì)劃，對(duì)各模塊接口進(jìn)行測(cè)試，并測(cè)試各模塊集成后是否能夠正常工作，編寫集成測(cè)試結(jié)果并跟蹤反饋，此階段測(cè)試為黑盒測(cè)試。本階段的輸入材料為3）的輸出交付物模塊接口文檔及5）的交付物可運(yùn)行的控制器樣件。本階段的執(zhí)行人員為集成測(cè)試工程師。本階段的輸出交付物為集成測(cè)試用例、集成測(cè)試計(jì)劃和集成測(cè)試報(bào)告。

8）系統(tǒng)測(cè)試 這個(gè)階段的活動(dòng)是根據(jù)需求定義文檔，編寫系統(tǒng)測(cè)試用例和系統(tǒng)測(cè)試計(jì)劃，將控制器樣件接入硬件在環(huán)測(cè)試設(shè)備進(jìn)行全面的系統(tǒng)功能和性能測(cè)試，最后編寫系統(tǒng)測(cè)試結(jié)果報(bào)告并跟蹤反饋。本階段的輸入材料為2）的交付物需求定義文檔及5）的交付物可運(yùn)行的控制器樣件。本階段的執(zhí)行人員為系統(tǒng)測(cè)試人員。本階段的輸出交付物為系統(tǒng)測(cè)試用例、系統(tǒng)測(cè)試計(jì)劃及系統(tǒng)測(cè)試報(bào)告。

9）標(biāo)定驗(yàn)證 這個(gè)階段的活動(dòng)是根據(jù)系統(tǒng)定義文檔，在控制器的具體應(yīng)用環(huán)境下，調(diào)整控制參數(shù)，驗(yàn)證各項(xiàng)性能指標(biāo)達(dá)到要求。本階段的輸入材料為1）的交付物系統(tǒng)定義文檔及5）的交付物可運(yùn)行的控制器樣件。本階段的執(zhí)行人員為標(biāo)定驗(yàn)證工程師。本階段的輸出交付物為最終軟件參數(shù)數(shù)據(jù)及驗(yàn)收?qǐng)?bào)告。

這種基于模型的V字開發(fā)流程，對(duì)于多變復(fù)雜的業(yè)務(wù)邏輯，采用圖形化的建模方式來實(shí)現(xiàn)，圖形化的模型可以直接對(duì)應(yīng)需求，便于溝通理解，也能夠通過模型仿真等手段驗(yàn)證模型的正確性。驗(yàn)證正確后的模型通過自動(dòng)代碼生成工具直接生成代碼，效率極高的同時(shí)避免了手工編寫業(yè)務(wù)邏輯代碼引入的人工編碼錯(cuò)誤。底層軟件手寫代碼一般是涉及硬件驅(qū)動(dòng)及標(biāo)準(zhǔn)化的底層軟件服務(wù)，其代碼相對(duì)比較固定，可重用度高，往往可以選擇以往項(xiàng)目中已經(jīng)過充分測(cè)試和驗(yàn)證的底層手寫軟件代碼，略加修改甚至無需修改來實(shí)現(xiàn)。因此可以大大提高整個(gè)軟件開發(fā)的效率及可靠性。對(duì)于硬件平臺(tái)，可以選擇業(yè)內(nèi)成熟主流且集成度高的方案，可以保證硬件平臺(tái)的可靠性。因此這種開發(fā)技術(shù)和方案，可以保證開發(fā)者 “正確地做事”。

在開發(fā)流程的這9個(gè)階段中，1～5階段為開發(fā)階段，遵循自頂向下，逐層細(xì)化的原則，下一個(gè)階段的開發(fā)依據(jù)直接來自上一個(gè)階段，保證了從需求到設(shè)計(jì)到實(shí)現(xiàn)的一致性和可追溯性；6～9階段為測(cè)試驗(yàn)證階段，遵循自底向上，逐步整合的原則。每一個(gè)階段的測(cè)試依據(jù)直接來自相應(yīng)開發(fā)階段的設(shè)計(jì)輸入，即對(duì)于每一個(gè)被測(cè)試的開發(fā)階段，其測(cè)試依據(jù)和開發(fā)依據(jù)完全一致，因此可以在流程上保證能通過測(cè)試的開發(fā)結(jié)果一定會(huì)符合原來設(shè)計(jì)時(shí)的需求。因此這種流程設(shè)計(jì)和要求可以保證開發(fā)者 “做正確的事”。

此外，對(duì)于第6階段的單元測(cè)試，由于屬于白盒測(cè)試，涉及到代碼的具體實(shí)現(xiàn)，一般建議由此模塊的開發(fā)工程師來完成，以保證開發(fā)效率。第7、8、9階段的集成測(cè)試、系統(tǒng)測(cè)試及標(biāo)定驗(yàn)證，一般應(yīng)該由一個(gè)獨(dú)立于開發(fā)團(tuán)隊(duì)的測(cè)試驗(yàn)證團(tuán)隊(duì)人員來完成，以保證測(cè)試的客觀性和有效性。

2 奇瑞艾瑞澤7轎車的ECU開發(fā)流程

ECU （Engine Control Unit，發(fā)動(dòng)機(jī)控制器）就是典型的一種高復(fù)雜度又需要具備高可靠性的車用嵌入式系統(tǒng)。以圖2所示的2013年7月26日正式上市的奇瑞艾瑞澤7轎車的ECU開發(fā)為例，此ECU為聯(lián)合汽車電子有限公司提供的ME17型ECU。該公司是中聯(lián)汽車電子有限公司和德國(guó)博世的合資公司，主要從事汽油發(fā)動(dòng)機(jī)管理系統(tǒng)、變速器控制系統(tǒng)、車身電子、混合動(dòng)力和電力驅(qū)動(dòng)控制系統(tǒng)的開發(fā)、生產(chǎn)和銷售。

1）在系統(tǒng)定義階段，ECU系統(tǒng)定義文檔的內(nèi)容應(yīng)該包括目標(biāo)車型、目標(biāo)市場(chǎng)，目標(biāo)市場(chǎng)適用的排放法規(guī)及油耗法規(guī)，客戶要求的動(dòng)力性及各種配置等內(nèi)容。

2）在需求分析階段，以ECU的怠速控制需求為例，可定義為：在發(fā)動(dòng)機(jī)達(dá)到暖機(jī)狀態(tài)時(shí)，不開空調(diào)，怠速轉(zhuǎn)速為800r／min，轉(zhuǎn)速波動(dòng)在±30r／min之內(nèi)。

3）在架構(gòu)設(shè)計(jì)階段，ECU的模塊接口文檔包括軟件接口文檔及硬件接口文檔。軟件接口文檔描述發(fā)動(dòng)機(jī)上層應(yīng)用軟件與底層驅(qū)動(dòng)軟件之間的接口函數(shù)定義、全局變量定義等，硬件接口文檔描述ECU硬件需要具備的各個(gè)引腳功能及電氣性能、電磁兼容性能、環(huán)境耐久、機(jī)械性能等要求。

4）在模塊開發(fā)階段，發(fā)動(dòng)機(jī)控制策略的開發(fā)人員，通過建模工具，完成噴油邏輯、點(diǎn)火邏輯、怠速控制邏輯等模塊的建模，根據(jù)發(fā)動(dòng)機(jī)應(yīng)用層軟件與底層驅(qū)動(dòng)軟件接口文檔配置自動(dòng)代碼生成工具的參數(shù)，然后通過自動(dòng)代碼生成工具生成能夠帶相應(yīng)接口的C代碼，可以和底層手寫的驅(qū)動(dòng)軟件代碼集成在一起，同時(shí)還能自動(dòng)生成設(shè)計(jì)文檔。底層軟件開發(fā)人員根據(jù)底層軟件需求手工編寫代碼。硬件設(shè)計(jì)人員開發(fā)ECU硬件。

5）在系統(tǒng)集成階段，集成工程師將模型自動(dòng)代碼生成的C代碼和底層手寫的代碼放在一個(gè)工程里進(jìn)行編譯調(diào)試通過，生成一個(gè)可執(zhí)行的S19文件，并刷入到ECU硬件樣件里，就形成了一個(gè)可運(yùn)行的ECU樣件。

6）在單元測(cè)試階段，由發(fā)動(dòng)機(jī)策略開發(fā)工程師進(jìn)行發(fā)動(dòng)機(jī)上層應(yīng)用模型的單元測(cè)試，包括模型在環(huán)測(cè)試 （MIL）、軟件在環(huán)測(cè)試 （SIL）及處理器在環(huán)測(cè)試 （PIL）。MIL是模型在仿真的環(huán)境里執(zhí)行，驗(yàn)證模型邏輯的正確性；SIL是將模型轉(zhuǎn)換成代碼，在仿真環(huán)境里驗(yàn)證代碼的正確性；PIL是將模型生成的代碼通過專門的工具下載到處理器芯片中去，驗(yàn)證模型所生成的代碼在真實(shí)芯片中執(zhí)行的正確性。底層軟件代碼通過單元測(cè)試工具進(jìn)行分支覆蓋測(cè)試、條件覆蓋測(cè)試、修正條件判定覆蓋等白盒測(cè)試。對(duì)于ECU硬件樣件的測(cè)試，按照硬件接口文檔和硬件開發(fā)需求文檔來進(jìn)行。

7）在集成測(cè)試階段，可以制作一個(gè)車輛模擬器來對(duì)ECU進(jìn)行集成測(cè)試。這種車輛模擬器可以發(fā)出轉(zhuǎn)速信號(hào)、相位信號(hào)、車速信號(hào)、水溫信號(hào)、進(jìn)氣壓力信號(hào)等傳感器輸入信號(hào)給ECU。車輛模擬器同時(shí)還能接收ECU發(fā)出的噴油、點(diǎn)火等執(zhí)行器控制信號(hào)，并在模擬器面板上以指示燈或顯示屏的方式顯示出來。利用這種模擬器可以測(cè)試ECU能否正確讀取輸入信號(hào)、正確處理信號(hào)、正確輸出控制信號(hào)，屬于一種開環(huán)測(cè)試。

8）在系統(tǒng)測(cè)試階段，將ECU接入專用的硬件在環(huán)測(cè)試 （HIL）設(shè)備來進(jìn)行系統(tǒng)測(cè)試。HIL設(shè)備的硬件接口能夠提供與實(shí)車完全一致的實(shí)時(shí)硬件信號(hào)給ECU，也能夠?qū)崟r(shí)地讀取ECU輸出的控制信號(hào)。HIL設(shè)備上的高速處理器還會(huì)運(yùn)行一個(gè)發(fā)動(dòng)機(jī)模型來對(duì)ECU的控制結(jié)果進(jìn)行實(shí)時(shí)反饋，真實(shí)模擬ECU在實(shí)車環(huán)境下的工作，實(shí)現(xiàn)閉環(huán)測(cè)試。根據(jù)需求編寫可運(yùn)行在HIL設(shè)備上的系統(tǒng)測(cè)試用例，實(shí)現(xiàn)全面高效的系統(tǒng)測(cè)試。

9）在標(biāo)定驗(yàn)證階段，將ECU裝到目標(biāo)車型上，進(jìn)行標(biāo)定參數(shù)調(diào)整，并通過整車排放測(cè)試、整車油耗測(cè)試、整車駕駛性評(píng)價(jià)等試驗(yàn)，驗(yàn)證確定最終開發(fā)的產(chǎn)品能夠完全滿足客戶的要求。

3 過程管理在基于模型的V字開發(fā)流程中的應(yīng)用

如前所述，為了開發(fā)高可靠性的汽車嵌入式系統(tǒng)，采用了基于模型的V字開發(fā)流程。在此流程中要求從系統(tǒng)定義到需求分析到設(shè)計(jì)實(shí)現(xiàn)到測(cè)試驗(yàn)證，環(huán)環(huán)相扣，保持一致性和可追溯性。對(duì)于現(xiàn)代汽車上越來越復(fù)雜的嵌入式系統(tǒng)而言，涉及到系統(tǒng)定義及需求的條目往往很多，多的可以達(dá)到數(shù)千條至上萬條細(xì)化需求，再加上每個(gè)需求對(duì)應(yīng)的設(shè)計(jì)及實(shí)現(xiàn)，以及需求對(duì)應(yīng)的測(cè)試用例及測(cè)試結(jié)果，需要保持一致性和可追溯性的內(nèi)容非常龐大。再加上開發(fā)過程中系統(tǒng)定義和需求經(jīng)常會(huì)發(fā)生變更，測(cè)試中發(fā)現(xiàn)問題，設(shè)計(jì)和實(shí)現(xiàn)也經(jīng)常要修改，而且復(fù)雜系統(tǒng)的開發(fā)往往是一個(gè)團(tuán)隊(duì)多人開發(fā)，還需要實(shí)現(xiàn)大型開發(fā)團(tuán)隊(duì)的協(xié)調(diào)工作。這整個(gè)開發(fā)過程如果采用手工的方式，來維護(hù)從系統(tǒng)定義、需求、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、驗(yàn)證的一致性，對(duì)稍微復(fù)雜一點(diǎn)的系統(tǒng)都是難以實(shí)現(xiàn)的，高可靠性的開發(fā)也就無從談起。因此需要引入需求管理工具和配置管理工具來實(shí)現(xiàn)這個(gè)流程。

需求管理工具主要實(shí)現(xiàn)以需求為中心的對(duì)整個(gè)開發(fā)流程各個(gè)階段信息流的管理。需求管理工具通過建立各個(gè)階段之間的條目的鏈接關(guān)系，從系統(tǒng)定義條目可以通過鏈接跟蹤到需求分析條目跟蹤到設(shè)計(jì)實(shí)現(xiàn)，也可以跟蹤到相應(yīng)的測(cè)試條目，也可以從測(cè)試條目或設(shè)計(jì)實(shí)現(xiàn)追溯回相應(yīng)的需求分析條目及系統(tǒng)定義條目。當(dāng)需求發(fā)生變更時(shí)，需求管理工具要能夠自動(dòng)列出與此需求相關(guān)的需要同步更新的其他階段條目。各階段信息的鏈接關(guān)系如圖3所示。

需求管理工具至少需要實(shí)現(xiàn)V字流程的左臂的各開發(fā)層級(jí)的條目之間的雙向鏈接關(guān)系，及V字流程的左臂和右臂之間各層級(jí)開發(fā)要求和對(duì)應(yīng)層級(jí)測(cè)試用例及測(cè)試結(jié)果之間的雙向鏈接關(guān)系。

配置管理工具主要實(shí)現(xiàn)對(duì)開發(fā)項(xiàng)目配置及人員的管理，記錄產(chǎn)品開發(fā)的過程。通過控制、記錄、追蹤，對(duì)軟件的修改和每個(gè)修改生成的軟件組成部件來實(shí)現(xiàn)對(duì)軟件產(chǎn)品的管理功能設(shè)定，配置各個(gè)開發(fā)人員的權(quán)限和開發(fā)角色，實(shí)現(xiàn)并行開發(fā)協(xié)同工作，達(dá)到開發(fā)團(tuán)隊(duì)的有效管理。一個(gè)典型軟件配置管理基本流程如圖4所示。

4 ISO 26262的要求

ISO 26262是從電子、電氣及可編程器件功能安全基本標(biāo)準(zhǔn)IEC 61508派生出來的一個(gè)國(guó)際標(biāo)準(zhǔn)，主要定位在汽車行業(yè)中特定的電氣器件、電子設(shè)備、可編程電子器件等專門用于汽車領(lǐng)域的部件，旨在提高汽車電子、電氣產(chǎn)品功能安全的國(guó)際標(biāo)準(zhǔn)。適用于最大質(zhì)量不超過3500kg批量生產(chǎn)的乘用車。ISO 26262從2005年11月起正式開始制定，已于2011年11月正式頒布，成為國(guó)際標(biāo)準(zhǔn)。中國(guó)也正在積極進(jìn)行相應(yīng)國(guó)標(biāo)的制定。目前國(guó)內(nèi)越來越多的廠家也開始重視這一標(biāo)準(zhǔn)［3］。

此標(biāo)準(zhǔn)主要針對(duì)安全性相關(guān)的汽車電子系統(tǒng)進(jìn)行分析和指導(dǎo)，其概覽如圖5所示［4］。

可以看到ISO 26262的流程在系統(tǒng)級(jí)產(chǎn)品開發(fā)部分與我們前面討論的基于模型的V字開發(fā)流程是極為相識(shí)的，整體也是一個(gè)V字開發(fā)流程。除了系統(tǒng)級(jí)別的產(chǎn)品開發(fā)環(huán)節(jié)外，ISO 26262還增加了概念階段和生產(chǎn)及運(yùn)行階段的流程開發(fā)要求，覆蓋了一個(gè)項(xiàng)目從概念到設(shè)計(jì)開發(fā)到生產(chǎn)運(yùn)行到最終報(bào)廢的全生命周期過程，其流程要求的覆蓋更為全面。

ISO 26262中的關(guān)鍵概念是汽車安全完整性等級(jí) （Automotive Safety Integrity Level， 縮 寫 為ASIL）。ASIL分為A、B、C、D四個(gè)等級(jí)，其中ASIL D為最高等級(jí)。等級(jí)越高，代表一旦此功能失效，導(dǎo)致的人身安全風(fēng)險(xiǎn)越高，則此項(xiàng)功能對(duì)應(yīng)的設(shè)計(jì)方法、可靠性、測(cè)試方法等技術(shù)指標(biāo)就要求越高。ASIL從3個(gè)方面進(jìn)行評(píng)估：功能失效造成的危險(xiǎn)對(duì)駕駛員或其他交通參與人員造成傷害的嚴(yán)重程度S，會(huì)出現(xiàn)此種危險(xiǎn)的工況出現(xiàn)概率E，危險(xiǎn)出現(xiàn)時(shí)駕駛員和其他交通參與人員及時(shí)采取控制行動(dòng)以避免危害的可控性C。

因此應(yīng)用ISO 26262以提高安全相關(guān)的嵌入式系統(tǒng)可靠性時(shí)，首先要從S、E、C三個(gè)維度去分析ASIL等級(jí)。如表1所示。

表1 ASIL確定表格

S分為S0、S1、S2、S3四級(jí)，從0到3，代表傷害程度逐級(jí)增強(qiáng)，S0代表無傷害，S3代表危及生命的重傷或致命傷。E分為E0、E1、E2、E3、E4五級(jí)，從0到4代表工況發(fā)生概率從小到大，E0代表此工況不可能發(fā)生，E4代表此工況是常見工況。C分為C0、C1、C2、C3四級(jí)，從0到3代表危險(xiǎn)發(fā)生時(shí)可控制程度從容易到困難，C0代表完全可控，C3代表幾乎無法控制。

S0、E0和C0滿足任何一個(gè)時(shí)，認(rèn)為此項(xiàng)功能不影響安全性，因此表1中沒有列出。其他的情況下，根據(jù)不同的S、E、C級(jí)別組合，可以從表1中查得相應(yīng)的ASIL等級(jí)。其中QM代表在這種組合下，此項(xiàng)功能不影響安全性，通過一般品質(zhì)管理即可保證。

汽車安全完整性等級(jí)分析在項(xiàng)目開發(fā)的概念階段完成，確認(rèn)當(dāng)前開發(fā)的嵌入式系統(tǒng)涉及的功能需要滿足的ASIL等級(jí)后，就可以進(jìn)入產(chǎn)品開發(fā)的V字流程。在產(chǎn)品開發(fā)的V字流程中，根據(jù)確認(rèn)的ASIL等級(jí)，ISO 26262標(biāo)準(zhǔn)詳細(xì)規(guī)定了各個(gè)階段每一種ASIL等級(jí)應(yīng)采取的技術(shù)方案、測(cè)試方案、過程組織要求，使得最終開發(fā)出的產(chǎn)品可以達(dá)到所要求的ASIL等級(jí)。

因此，對(duì)于與人身安全相關(guān)的汽車嵌入式系統(tǒng)開發(fā)，在前述基于模型的V字開發(fā)流程基礎(chǔ)上，采用需求管理工具及配置管理工具進(jìn)行過程管理控制。再按ISO 26262的要求進(jìn)一步擴(kuò)展，在概念階段進(jìn)行汽車安全完整性等級(jí)分析，然后按相應(yīng)的ASIL等級(jí)在V字開發(fā)流程的各個(gè)階段采用標(biāo)準(zhǔn)所指定的技術(shù)方案，并補(bǔ)充實(shí)施生產(chǎn)及運(yùn)行階段的要求，就可以使整個(gè)項(xiàng)目符合ISO 26262的要求。

仍以奇瑞艾瑞澤7轎車的ECU的開發(fā)為例，這個(gè)ECU是用于電子節(jié)氣門的發(fā)動(dòng)機(jī)控制，一種可能導(dǎo)致危險(xiǎn)發(fā)生的失效是ECU對(duì)發(fā)動(dòng)機(jī)的電子節(jié)氣門控制失效，導(dǎo)致電子節(jié)氣門一直處于全開狀態(tài)。為了確定這種危險(xiǎn)對(duì)應(yīng)的安全完整性等級(jí)，我們分析這種危險(xiǎn)的嚴(yán)重程度，如果電子節(jié)氣門一直處于全開，會(huì)導(dǎo)致車輛一直處于加速狀態(tài)，可能導(dǎo)致車毀人亡的嚴(yán)重后果，因此嚴(yán)重程度可以設(shè)為S3；分析發(fā)生這種危險(xiǎn)的工況可能性為一般常見，概率等級(jí)設(shè)為E3；分析發(fā)生這種危險(xiǎn)時(shí)駕駛員對(duì)車輛的可控性，一般駕駛員只要不過于慌亂，可以通過猛踩制動(dòng)、將檔位掛入低檔、擦撞護(hù)欄等方式使車輛停下，可控性設(shè)為C2。根據(jù)表1可查得，對(duì)于這種危險(xiǎn)將其汽車安全完整性等級(jí)設(shè)為ASIL B。

對(duì)于ASIL B等級(jí)的功能，要求ECU進(jìn)行軟件設(shè)計(jì)時(shí)，對(duì)相關(guān)信號(hào)的可靠性設(shè)計(jì)專門的在線診斷程序，當(dāng)發(fā)現(xiàn)電子節(jié)氣門信號(hào)不可靠時(shí)，ECU將噴油量和點(diǎn)火角限制到一個(gè)安全值，使車輛無法持續(xù)加速。在硬件可靠性方面，根據(jù)

ISO 26262中的要求［4］， 不 同

ASIL等級(jí)對(duì)隨機(jī)硬件失效率有不同的要求，如表2所示。因此根據(jù)表2，ECU的

ASIL等級(jí)被定為B時(shí)，其硬件的可靠性設(shè)計(jì)要按隨機(jī)硬件失效率低于10-7每小時(shí)的要求進(jìn)行。

表2 隨機(jī)硬件失效率目標(biāo)值

5 工具鏈介紹

要完成前面所述的高復(fù)雜度、高可靠性的車用嵌入式系統(tǒng)開發(fā)，先進(jìn)的開發(fā)工具鏈?zhǔn)潜夭豢缮俚?，筆者此處也介紹一些主流的開發(fā)工具。對(duì)于需求管理及配置管理方面，IBM公司提供的Rational DOORS、 Rational ClearCase、 Rational ClearQuest，是多個(gè)行業(yè)廣泛應(yīng)用的工具。建模方面Mathwork公司的Matlab產(chǎn)品及ETAS公司的ASCET產(chǎn)品是汽車行業(yè)內(nèi)常用的建模工具，dSPACE公司的Simulator產(chǎn)品及ETAS公司的LABCAR產(chǎn)品是汽車行業(yè)內(nèi)常用的系統(tǒng)測(cè)試硬件在環(huán)工具。ETAS公司的INCA系列產(chǎn)品是汽車行業(yè)內(nèi)常用的標(biāo)定工具。

6 總結(jié)

為了滿足高可靠性汽車嵌入式系統(tǒng)的開發(fā)要求，提出了基于模型的V字流程開發(fā)方式，這種開發(fā)方式采用基于模型的嵌入式軟件開發(fā)技術(shù)，流程上以需求為核心，自頂向下逐層細(xì)化開發(fā)，由下而上，逐步集成測(cè)試，每一層次的開發(fā)依據(jù)和相應(yīng)層次的測(cè)試依據(jù)保持一致，保證所有需求都能夠得到正確的實(shí)現(xiàn)。引入自動(dòng)化的需求管理和配置管理工具，形成合理的開發(fā)工具鏈，使得開發(fā)過程中龐大的信息流及團(tuán)隊(duì)人員組織得到有效的管理，確保系統(tǒng)的高效開發(fā)。對(duì)于人身安全相關(guān)的車用嵌入式系統(tǒng)，進(jìn)一步引入ISO 26262功能安全標(biāo)準(zhǔn)，通過對(duì)汽車安全完整性等級(jí)分析，確認(rèn)功能安全等級(jí)，對(duì)產(chǎn)品V字流程開發(fā)中的各個(gè)階段采用標(biāo)準(zhǔn)規(guī)定的相應(yīng)功能安全等級(jí)的技術(shù)方案，從而進(jìn)一步提高最終產(chǎn)品的可靠性和競(jìng)爭(zhēng)力。

［1］鄭宇平，王強(qiáng).汽車嵌入式系統(tǒng)開發(fā)方法體系架構(gòu)及相關(guān)流程探討［J］.電子制作， 2013 （15）： 209.

［2］魏學(xué)哲，戴海峰，孫澤昌.汽車嵌入式系統(tǒng)開發(fā)方法、體系架構(gòu)和流程［J］.同濟(jì)大學(xué)學(xué)報(bào) （自然科學(xué)版），2012，40 （7）： 1064-1070.

［3］劉佳熙，郭輝，李君.汽車電子電氣系統(tǒng)的功能安全標(biāo)準(zhǔn)ISO26262［J］. 上海汽車， 2011 （10）： 57-61.

［4］ ISO 26262， Road vehicles Function safety［S］.2011.