蘇萬檣，謝小娟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 ISO 26262的要求

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

此標準主要針對安全性相關的汽車電子系統(tǒng)進行分析和指導，其概覽如圖5所示［4］。

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

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

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

表1 ASIL確定表格

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

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

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

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

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

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

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

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

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

表2 隨機硬件失效率目標值

5 工具鏈介紹

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

6 總結

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

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

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

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

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