ASIL B車載ECU功能安全軟件開(kāi)發(fā)要點(diǎn)

翟輝

摘? 要：隨著E/E系統(tǒng)在當(dāng)代汽車中應(yīng)用比重的增加，E/E系統(tǒng)的安全問(wèn)題引起廣泛關(guān)注，占據(jù)E/E系統(tǒng)中主要位置的軟件更是成為焦點(diǎn)。ISO國(guó)際標(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)驗(yàn)，主要總結(jié)針對(duì)功能安全ASIL B級(jí)車載ECU軟件開(kāi)發(fā)的經(jīng)驗(yàn)。

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

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

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

2.1? ?ASPICE

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

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

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

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

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

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

2.2.2 需求定義

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

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

2.2.3 框架設(shè)計(jì)

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

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

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

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

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

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

2.2.5 單元驗(yàn)證

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

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

2.2.6 集成驗(yàn)證

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

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

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

2.2.7 功能驗(yàn)證

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

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

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

3.1? ?軟件組件的無(wú)干涉設(shè)計(jì)

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

3.1.1 時(shí)序

時(shí)序故障指發(fā)生以下問(wèn)題：

A）執(zhí)行被阻塞

B）死鎖

C）活鎖

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

E）同步錯(cuò)誤

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

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

3.1.2 存儲(chǔ)

存儲(chǔ)故障指發(fā)生以下問(wèn)題：

A）內(nèi)容損壞

B）數(shù)據(jù)不一致（如數(shù)據(jù)更新過(guò)程中被讀?。?/p>

C）堆棧溢出

D）對(duì)其他軟件組件存儲(chǔ)區(qū)讀寫訪問(wèn)

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

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

3.1.3 通信

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

A）信息重復(fù)

B）信息丟失

C）信息延遲

D）信息插入

E）信息偽裝

F）信息的不正確尋址

G）信息次序不正確

H）信息損壞

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

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

K）通信信道阻塞

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

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

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

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

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

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

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

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

分析的具體步驟如下：

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

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

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

④分析每個(gè)故障的可能原因;

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

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

4? ? 結(jié)束語(yǔ)

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

參考文獻(xiàn)：

[1]GB/T 34590.3-2017道路車輛 功能安全 第6部分：產(chǎn)品開(kāi)發(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)集成（大連）有限公司，任主任工程師，主要研究方向?yàn)檐囕d嵌入式軟件開(kāi)發(fā)，從事車載嵌入式軟件開(kāi)發(fā)工作已有14年。