蘇萬檣,謝小娟
(奇瑞汽車股份有限公司,安徽 蕪湖 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]。
隨著計(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è)試的客觀性和有效性。
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)品能夠完全滿足客戶的要求。
如前所述,為了開發(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所示。
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)值
要完成前面所述的高復(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)定工具。
為了滿足高可靠性汽車嵌入式系統(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.