翟輝

摘? 要：隨著E/E系統(tǒng)在當(dāng)代汽車中應(yīng)用比重的增加，E/E系統(tǒng)的安全問題引起廣泛關(guān)注，占據(jù)E/E系統(tǒng)中主要位置的軟件更是成為焦點。ISO國際標(biāo)準(zhǔn)化組織已經(jīng)頒布了功能安全、信息安全以及預(yù)期功能安全（SOTIF）相關(guān)的標(biāo)準(zhǔn)ISO26262、ISO21434以及ISO21448。本文結(jié)合本公司十幾年為歐美OEM供應(yīng)功能安全相關(guān)車載ECU的經(jīng)驗，主要總結(jié)針對功能安全ASIL B級車載ECU軟件開發(fā)的經(jīng)驗。

關(guān)鍵詞：功能安全;ISO26262;GB/T34590;車載ECU軟件;ASIL B

中圖分類號：U461.91? ? ?文獻(xiàn)標(biāo)識碼：A? ? ?文章編號：1005-2550（2021）04-0043-05

Key points of software development for ASIL B automotive ECU

ZHAI Hui

（ ALPS System Integration （Dalian） Co.， Ltd. Dalian 116023， China ）

Abstract： With the increasing proportion of E/E system application in modern automobile， the safety problem of E/E system has aroused widespread concern， and the software occupying the main position in E/E system has become the focus. ISO has issued ISO 26262， ISO 21434 and ISO 21448 on functional safety， information security and intended functional safety. Based on our company's experience in supplying functional safety related on-board ECU for European and American OEMs for more than ten years， this paper mainly summarizes the experience in software development of ASIL B automotive ECU for functional safety.

1? ? 前言

安全環(huán)保已成為當(dāng)今社會對汽車產(chǎn)品的重要價值取向，在汽車中占有最重要位置的E/E系統(tǒng)的安全性自然成為焦點。國際標(biāo)準(zhǔn)化組織于2011年在IEC61508 E/E系統(tǒng)功能安全標(biāo)準(zhǔn)的基礎(chǔ)上制定并發(fā)布了第一版道路車輛功能安全標(biāo)準(zhǔn)集ISO26262 ，并在2018年更新了第二版。我國也于2017年發(fā)布了相應(yīng)的標(biāo)準(zhǔn)集GB/T34590，本文中統(tǒng)稱為功能安全標(biāo)準(zhǔn)。這些標(biāo)準(zhǔn)基于“東西總會壞、人總會犯錯誤”的假設(shè)，針對隨機(jī)硬件故障和系統(tǒng)性故障，從產(chǎn)品開發(fā)流程和技術(shù)應(yīng)用兩個維度提出了要求。作為業(yè)界功能安全的最高準(zhǔn)則（state of the art），被廣大汽車OEM所采用，作為安全相關(guān)車載ECU產(chǎn)品的開發(fā)標(biāo)準(zhǔn)。該標(biāo)準(zhǔn)集的第六部分描述了對于車載E/E系統(tǒng)中軟件開發(fā)的相關(guān)要求。我司與集團(tuán)母公司一起從IEC61508時代開始即為全球各大整車OEM提供功能安全相關(guān)車載ECU產(chǎn)品，積累了十幾年的開發(fā)經(jīng)驗，本文結(jié)合這些開發(fā)經(jīng)驗，重點總結(jié)了ASIL B級車載ECU軟件開發(fā)的要點。

2? ? 功能安全軟件開發(fā)流程

2.1? ?ASPICE

汽車行業(yè)的軟件開發(fā)基本采用ASPICE（Automotive Software Process Improvement and Capability dEtermination）模型框架，作為研發(fā)流程改善及供應(yīng)商能力評價的標(biāo)準(zhǔn)。該標(biāo)準(zhǔn)是SPICE（ISO15504 ）在汽車行業(yè)的應(yīng)用。多數(shù)汽車OEM 要求供應(yīng)商的軟件開發(fā)能力要達(dá)到Level 3以上。車載ECU供應(yīng)商一般會基于該標(biāo)準(zhǔn)，在第三方咨詢公司的幫助下，結(jié)合本公司實際情況建立適合本公司的流程體系，以明確產(chǎn)品開發(fā)中的各種活動，活動的輸入輸出，參與活動的各種角色以及應(yīng)采用的模板、指南和檢查清單等輔助工具。我司 與集團(tuán)母公司一起早在2006年即基于ASPICE建立了自己的品質(zhì)管理系統(tǒng)，并在為某歐系OEM的產(chǎn)品開發(fā)中取得了Level3的認(rèn)證。該系統(tǒng)不僅包含了軟件開發(fā)活動，同時也彌補(bǔ)了ASPICE的不足將系統(tǒng)及硬件開發(fā)活動也納入了該系統(tǒng)。這與功能安全標(biāo)準(zhǔn)的思路一樣，從產(chǎn)品開發(fā)的整體上明確了流程和技術(shù)要求，如圖1所示：

2.2? ?功能安全標(biāo)準(zhǔn)的軟件開發(fā)要求

功能安全標(biāo)準(zhǔn)的第六部分描述了對軟件開發(fā)的要求，主要活動包括需求定義，框架設(shè)計，單元設(shè)計及實現(xiàn)，單元驗證，集成驗證，功能驗證等活動，如圖2所示。

這些活動從流程上與ASPICE的要求沒有本質(zhì)區(qū)別。在技術(shù)應(yīng)用上，功能安全標(biāo)準(zhǔn)針對各活動定義了一些具體的措施。本文結(jié)合ISO26262-2018 的最新要求，針對ASIL B的要求對各活動的措施加以說明。

2.2.1 計劃階段應(yīng)考慮的內(nèi)容

軟件開發(fā)項目啟動時應(yīng)考慮采用何種開發(fā)手段和方法，例如采用何種開發(fā)語言，是否采用基于模型的開發(fā)，是否需要遵守MISRA-C標(biāo)準(zhǔn)等。但這些手段和方法不應(yīng)在項目計劃時臨時考慮，應(yīng)該作為組織開發(fā)流程的一部分明確定義并作為組織過程資產(chǎn)積累。表1規(guī)定了ASIL B需要滿足的具體要求。如果組織采用基于模型的開發(fā)手段，如MATLAB，Rhapsody等，并建立了統(tǒng)一的建模及命名規(guī)范，而且實施規(guī)范化的滿足MISRA-C的代碼解析活動，即可充分滿足這些要求。

2.2.2 需求定義

OEM在整車層次進(jìn)行相關(guān)項定義時明確了系統(tǒng)功能和邊界，然后進(jìn)行HARA（危害分析及風(fēng)險評估），確定安全目標(biāo)（Safety Goal）及相應(yīng)ASIL 等級。進(jìn)而制定FSC/FSR和TSC/TSR，提供給供應(yīng)商作為輸入。不同OEM，不同項目提供的安全需求形式可能不同，作為供應(yīng)商要積極從OEM獲取或配合OEM制定明確的安全需求，做好跟蹤管理，確保設(shè)計檢證活動對需求的充分覆蓋。

通過對OEM安全需求的解讀，制定系統(tǒng)/子系統(tǒng)級的技術(shù)安全需求，并分配給硬件即軟件組件。對于分配給軟件的安全需求，應(yīng)明確定義以下內(nèi)容，并記錄到軟件安全需求文檔中。

2.2.3 框架設(shè)計

經(jīng)過需求分析之后，獲得了分解的需求點，這些需求點需要部署給某一軟件單元來實現(xiàn)?？蚣茉O(shè)計就是要結(jié)合需求點設(shè)計軟件結(jié)構(gòu)，明確構(gòu)成軟件的單元有哪些。然后在評審階段充分驗證結(jié)構(gòu)及接口的合理性。軟件開發(fā)組織應(yīng)建立標(biāo)準(zhǔn)的開發(fā)指南，將表3中要求的設(shè)計原則轉(zhuǎn)換為明確的設(shè)計要求。

車載嵌入式軟件的結(jié)構(gòu)會根據(jù)是否采用操作系統(tǒng)等SEOOC組件而不同，這在項目企劃階段就應(yīng)決定，并在采購SEOOC時明確安全級別。在框架設(shè)計階段需根據(jù)構(gòu)成軟件的所有組件的安全特性決定是否采用分區(qū)（Partition）機(jī)制。近幾年采用AUTOSAR 分層結(jié)構(gòu)的ECU產(chǎn)品越來越多，在采購AUTOSAR軟件包時應(yīng)注意提前考慮安全相關(guān)需求。

另外，安全分析是框架設(shè)計階段的重點工作，具體實施方法可參照本文第3章3.2節(jié)的描述。

2.2.4 單元設(shè)計及實現(xiàn)

構(gòu)建完軟件框架，進(jìn)行單元設(shè)計時，應(yīng)遵循表5和表6中的要求。這些要求應(yīng)轉(zhuǎn)換為設(shè)計指南、編碼規(guī)范中的具體規(guī)則，且應(yīng)用于組織中所有軟件開發(fā)項目。

此階段的重點工作是實現(xiàn)軟件安全需求以及安全分析后定義的各種安全機(jī)制，常用的安全機(jī)制可參考本文第3章3.1節(jié)的描述。軟件單元的具體實現(xiàn)方法與QM級別軟件的實現(xiàn)并無本質(zhì)區(qū)別，但采用的工具應(yīng)滿足對應(yīng)安全級別的工具可信度等級（TCL）要求。

2.2.5 單元驗證

在設(shè)計單元測試用例時應(yīng)充分實施等價類劃分等方法，并利用Bullseye、TestWell CTC++等覆蓋率分析工具檢查測試用例的有效性。對于ASIL B需至少滿足語句和分支覆蓋要求。

本司的單元測試采用CUnit框架，并在模擬環(huán)境和目標(biāo)環(huán)境同時實施。

2.2.6 集成驗證

集成驗證階段的測試方法包括常規(guī)的需求分析，接口測試，同時遵循MISRA-C的代碼解析是必要且有效的手段。Helix QAC及CodeSonar這樣的工具被廣泛使用，一些嵌入式IDE的編譯器也支持基本的MISRA規(guī)則檢查。

另外，ROM、RAM及堆棧使用情況，任務(wù)執(zhí)行時間等需要確認(rèn)，以確保集成后軟件的性能。

具體的用例設(shè)計時，等價類劃分及邊界值測試也是必要手段。

2.2.7 功能驗證

供應(yīng)商的功能驗證因為沒有整車環(huán)境，一般在模擬環(huán)境（如HIL硬件在環(huán)）下進(jìn)行。最終整車OEM會在整車環(huán)境進(jìn)行驗證。實施功能驗證時充分利用組織過程資產(chǎn)中歷史問題是重要的手段，避免同類重大問題的再發(fā)。用例設(shè)計同樣采用需求分析及等價類劃分這樣的常規(guī)手段。另外，結(jié)合嵌入式軟件運行模式及情景（如啟動時、診斷時、降級時、掉電時、休眠時、標(biāo)定時、EOL下線檢查時、軟件更新時的相關(guān)行為）的分析方法也是有效的。

3? ? 軟件組件的安全分析及相關(guān)故障分析

安全分析及相關(guān)故障分析應(yīng)該在軟件架構(gòu)層面實施。本節(jié)將介紹軟件組件典型的安全相關(guān)的故障，實際ASIL B系統(tǒng)常用的安全機(jī)制，以及如何進(jìn)行安全和相關(guān)故障分析。

3.1? ?軟件組件的無干涉設(shè)計

引起軟件組件間相互干擾，從而違反安全需求的故障有三類，即時序、存儲和通信。

3.1.1 時序

時序故障指發(fā)生以下問題：

A）執(zhí)行被阻塞

B）死鎖

C）活鎖

D）執(zhí)行時間錯誤

E）同步錯誤

可以采用的安全機(jī)制包括周期性調(diào)度，固定優(yōu)先級調(diào)度，時間觸發(fā)調(diào)度，執(zhí)行時間監(jiān)視，程序順序監(jiān)視及到達(dá)率監(jiān)視等。

針對ASIL B系統(tǒng)，常通過窗口型看門狗、時鐘監(jiān)視、任務(wù)時間監(jiān)視等設(shè)計實現(xiàn)上述安全機(jī)制。

3.1.2 存儲

存儲故障指發(fā)生以下問題：

A）內(nèi)容損壞

B）數(shù)據(jù)不一致（如數(shù)據(jù)更新過程中被讀取）

C）堆棧溢出

D）對其他軟件組件存儲區(qū)讀寫訪問

可以采用的安全機(jī)制包括存儲包含，奇偶校驗，錯誤糾正碼（ECC），錯誤檢查碼（EDC），循環(huán)冗余校驗（CRC），冗余保存，存儲區(qū)訪問限制，靜態(tài)解析，靜態(tài)分配等。

針對ASIL B系統(tǒng)，常通過堆棧上下溢出監(jiān)視、RAM/ROM ECC/EDC、關(guān)鍵模塊或數(shù)據(jù)的同質(zhì)/異質(zhì)冗余等設(shè)計來實現(xiàn)上述安全機(jī)制。

3.1.3 通信

通信故障指發(fā)生以下問題：

A）信息重復(fù)

B）信息丟失

C）信息延遲

D）信息插入

E）信息偽裝

F）信息的不正確尋址

G）信息次序不正確

H）信息損壞

I）從發(fā)送方傳送到多個接收方的信息不對稱

J）發(fā)送方發(fā)送的信息只能被部分接收方接收

K）通信信道阻塞

針對ASIL B系統(tǒng)，常通過數(shù)據(jù)ID、Alive/Sequence counter、CRC、超時判斷等設(shè)計來實現(xiàn)上述安全機(jī)制。AUTOSAR已經(jīng)將這些設(shè)計進(jìn)行了明確定義且廣泛被整車OEM采用，可參考文獻(xiàn)[3]。

另外，不同的通信協(xié)議（如LIN/CAN等）本身，會有信息回讀、基于優(yōu)先級的仲裁等機(jī)制，同樣可以作為保證安全的手段使用。

3.2? ?FMEA與HAZOP結(jié)合

上一節(jié)我們明確了軟件組件的故障種類，本節(jié)將說明如何分析軟件是否會發(fā)生這些故障。

軟件框架設(shè)計階段，構(gòu)建好構(gòu)成軟件的單元之后，會針對每個單元是否能夠?qū)崿F(xiàn)安全需求以及是否會發(fā)生這些故障進(jìn)行分析。業(yè)界幾乎都采用FMEA和HAZOP引導(dǎo)詞相結(jié)合的方式同時進(jìn)行安全分析和相關(guān)故障分析。

FMEA的模板一般采用表格的形式，其中一般需包含以下內(nèi)容：

常見的HAZOP引導(dǎo)詞包括：

借助這些引導(dǎo)詞的提示，激發(fā)想象思維，通過提問過程，識別軟件單元中的故障。各組織可以根據(jù)自己的業(yè)務(wù)特性構(gòu)建適用于自己的引導(dǎo)詞。

分析的具體步驟如下：

①框架設(shè)計構(gòu)建出軟件單元;

②針對每個單元，借助引導(dǎo)詞，識別故障模式;

③確認(rèn)該故障模式是否違反安全需求（如不違反則該單元的分析結(jié)束）;

④分析每個故障的可能原因;

⑤針對每個原因，從流程、軟件及硬件角度導(dǎo)出對策;

⑥如有必要更新安全需求;

4? ? 結(jié)束語

本文結(jié)合本公司的經(jīng)驗，描述了安全相關(guān)車載嵌入式軟件的一般開發(fā)流程，介紹了軟件組件間相互干擾的主要故障類型，重點說明了ASIL B軟件常用的安全機(jī)制，并簡單說明了安全分析和相關(guān)故障分析的方法和步驟。希望對安全相關(guān)車載軟件開發(fā)提供些許參考。

參考文獻(xiàn)：

[1]GB/T 34590.3-2017道路車輛 功能安全 第6部分：產(chǎn)品開發(fā)：軟件層面.

[2]ISO 26262.6-2011， Road vehicles — Functional safety —Part 6： Product development at the software level.

[3]ISO 26262.6-2018， Road vehicles — Functional safety —Part 6： Product development at the software level.

[4]AUTOSAR Specification of SW-C End-to-End Communication Protection Library AUTOSAR_SWS_ E2ELibrary.

[5]E2E Protocol Specification， AUTOSAR FO Release 1.5.1.

翟? ?輝

工學(xué)碩士，現(xiàn)就職于阿爾卑斯系統(tǒng)集成（大連）有限公司，任主任工程師，主要研究方向為車載嵌入式軟件開發(fā)，從事車載嵌入式軟件開發(fā)工作已有14年。