【摘 要】 CP AUTOSAR作為整個汽車行業(yè)一種標(biāo)準(zhǔn)化的開放式架構(gòu)，隨著汽車行業(yè)的發(fā)展，在車載軟件開發(fā)中運(yùn)用得越來越廣泛，同時汽車作為人們出行的重要交通工具，汽車的安全性也越來越重要。為了開發(fā)滿足ISO 26262的車載軟件，文章分析ISO 26262對軟件安全的要求，并結(jié)合CP AUTOSAR開發(fā)規(guī)范以及CP AUTOSAR的功能安全機(jī)制，對CP AUTOSAR的功能安全機(jī)制進(jìn)行深入研究，同時基于ISO 26262的軟件安全要求提出基于AUTOSAR架構(gòu)進(jìn)行軟件安全機(jī)制的應(yīng)用方案，對當(dāng)前車載軟件功能安全的實施具有重大意義。

      目前基于CP AUTOSAR架構(gòu)開發(fā)汽車電子軟件是主流的主機(jī)廠和汽車電子控制器供應(yīng)商最常見的一種開發(fā)方式。由于汽車電子控制器開發(fā)難度大，在開發(fā)的過程中必須遵循一定的開發(fā)和測試流程，目前汽車行業(yè)最重要的開發(fā)流程是ASPICE和ISO 26262[7]。ASPICE側(cè)重于開發(fā)功能安全相關(guān)性不大的汽車電子控制器，而ISO 26262作為標(biāo)準(zhǔn)的汽車電子控制器安全開發(fā)標(biāo)準(zhǔn)，對于車載電子控制器的安全開發(fā)流程做了嚴(yán)格的定義。ISO 26262從系統(tǒng)設(shè)計、軟硬件設(shè)計、測試、項目管理等方面提供了嚴(yán)格的流程和開發(fā)標(biāo)準(zhǔn)。在ISO 26262中，和軟件開發(fā)密切相關(guān)的主要有3大角度，分別是軟件開發(fā)和測試流程、軟件安全分析以及接口免于干擾的要求，軟件安全機(jī)制的實施基于接口免于干擾的要求設(shè)計和實現(xiàn)[6]。

      針對CP AUTOSAR架構(gòu)下的軟件功能安全的開發(fā)必須要明確ISO 26262 內(nèi)對軟件功能安全的要求，基于ISO 26262的要求，將CP AUTOSAR提供的安全機(jī)制應(yīng)用到汽車電子控制器軟件開發(fā)中[5]。在CP AUTOSAR的軟件安全機(jī)制中，主要提供了內(nèi)存保護(hù)（Memory Protection）、時間保護(hù)（WdgM and OS Timing Protection）、數(shù)據(jù)一致性（E2E算法）等安全機(jī)制來實現(xiàn)ISO 26262對接口免于干擾的要求。最終基于AUTOSAR的安全機(jī)制得出應(yīng)用結(jié)論，用于安全機(jī)制在項目中的實施[8]。

      本文以ISO 26262中對軟件開發(fā)的安全要求為基礎(chǔ)，通過識別和選擇CP AUTOSAR內(nèi)提供的安全機(jī)制，并且對安全機(jī)制進(jìn)行應(yīng)用研究和測試，從而針對CP AUTOSAR下的軟件功能安全開發(fā)提供一套完整的方案。整體設(shè)計架構(gòu)如圖1所示。

圖1 整體設(shè)計架構(gòu)圖

1 CP AUTOSAR介紹

      汽車電子開發(fā)不像其他產(chǎn)品的開發(fā)，有著自己一套嚴(yán)格的規(guī)范和流程，在汽車行業(yè)主要是V模型，它定義了汽車電子產(chǎn)品開發(fā)一套從需求到軟硬件設(shè)計開發(fā)再到最終測試交付的完整體系。AUTOSAR（Automotive Open System Architecture，汽車開放系統(tǒng)架構(gòu)）是主流汽車OEM、供應(yīng)商、芯片企業(yè)等制定的一套軟硬件可以分離復(fù)用、應(yīng)用算法與底層驅(qū)動分離、下層的芯片企業(yè)與上層OEM或者ECU供應(yīng)商基于同樣的規(guī)范，獨(dú)立并行開發(fā)的軟件開發(fā)體系。AUTOSAR 標(biāo)準(zhǔn)嚴(yán)格遵循了V 模型的軟件開發(fā)流程，在AUTOSAR標(biāo)準(zhǔn)中定義了從軟件需求（通用全面的需求）到架構(gòu)設(shè)計的完整體系，根據(jù)AUTOSAR規(guī)范就可以開發(fā)滿足這些規(guī)范的代碼程序。在AUTOSAR架構(gòu)中主要分為3層架構(gòu)，分別是APP（Application Layer，應(yīng)用 層）、RTE（Running Environment，運(yùn)行環(huán)境）、BSW（Basic Software，基礎(chǔ)軟件層）。整個AUTOSAR架構(gòu)分層如圖2所示。

圖2 AUTOSAR架構(gòu)分層圖

      APP層主要是實現(xiàn)特定ECU功能的邏輯算法，這一層也是CP AUTOSAR架構(gòu)里定義的各個OEM和供應(yīng)商在實現(xiàn)上存在競爭的一層。一般在APP層會設(shè)計出ECU中各個軟件單元模塊的上層應(yīng)用架構(gòu)，而這部分架構(gòu)并不是一個統(tǒng)一的CP AUTOSAR架構(gòu)，OEM和供應(yīng)商可以根據(jù)自己的應(yīng)用層邏輯去設(shè)計自己上層應(yīng)用需要的SWC數(shù)目、各個SWC模塊之間的數(shù)據(jù)流和控制流。在CP AUTOSAR架構(gòu)中，各個APP的調(diào)度、數(shù)據(jù)交互等通過RTE實現(xiàn)。

      RTE提供基礎(chǔ)的通信服務(wù)，支持SWC之間和SWC到BSW的通信（包括ECU內(nèi)部的程序調(diào)用、ECU外部的總線通信等情況）。RTE同時實現(xiàn)對APP層SWC的函數(shù)調(diào)度。RTE使應(yīng)用層的軟件架構(gòu)完全脫離于具體的單個ECU和BSW。

      BSW層是整個CP AUTOSAR的核心，內(nèi)部按架構(gòu)上的分層主要分為微控制器抽象、復(fù)雜驅(qū)動層、ECU抽象層、服務(wù)層4大部分。各部分的作用如下。

      1）微控制器抽象層（Microcontroller Abstraction Layer）是在BSW的最底層，包含了訪問微控制器的驅(qū)動。微控制器抽象層使上層軟件與微控制器相分離，以便應(yīng)用的移植。

      2）復(fù)雜驅(qū)動（Complex Drivers）可以實現(xiàn)應(yīng)用層通過RTE直接訪問硬件，也可以利用復(fù)雜驅(qū)動封裝已有的非分層的軟件，以便向CP AUTOSAR軟件架構(gòu)逐步實施。

      3）ECU抽象層（ECU Abstraction Layer）封裝了微控制器層以及外圍設(shè)備的驅(qū)動，將微控制器內(nèi)外設(shè)的訪問進(jìn)行統(tǒng)一，使上層軟件應(yīng)用與ECU硬件相剝離。

      4）服務(wù)層（Service Layer）位于BSW的最上面，將各種基礎(chǔ)軟件功能以服務(wù)的形式封裝起來，供應(yīng)用層調(diào)用。服務(wù)層包括RTOS、通信與網(wǎng)絡(luò)管理、內(nèi)存管理、診斷服務(wù)、狀態(tài)管理、程序監(jiān)控等服務(wù)。

2 ISO 26262對軟件安全的要求

      ISO 26262是從電子、電氣及可編程器件功能安全基本標(biāo)準(zhǔn)IEC 61508派生出來的，主要定位在汽車行業(yè)中特定的電氣器件、電子設(shè)備、可編程電子器件等專門用于汽車領(lǐng)域的部件，旨在提高汽車電子、電氣產(chǎn)品功能安全的國際標(biāo)準(zhǔn)。在汽車電子軟件功能安全開發(fā)過程中，主要關(guān)注ISO 26262的Part6的要求[4]。針對整個ISO 26262-6對軟件開發(fā)的要求，在圖1中已經(jīng)展示，即軟件開發(fā)測試流程、接口免于干擾以及安全分析。軟件和測試流程的要求需要流程管理進(jìn)行控制，安全分析主要借助一些專業(yè)工具進(jìn)行分析，而對于接口免于干擾的設(shè)計在ISO 26262中提出了明確的要求，而這些接口免于干擾的設(shè)計需要在軟件開發(fā)中提供相關(guān)的安全機(jī)制來實現(xiàn)。根據(jù)ISO 26262的接口免于干擾的要求，主要從Timing and Execution、Memory、Exchange of Information這3個方面進(jìn)行分析[12]。

2.1 Timing and Execution

      ISO 26262中對時間和執(zhí)行時序相關(guān)的要求做了明確的定義，主要從圖3 列出的5 個方面進(jìn)行設(shè)計和評估。Timing和Execution的分析主要是防止執(zhí)行的函數(shù)被阻塞的時間過長；防止函數(shù)執(zhí)行超過一定的時間；防止函數(shù)調(diào)度過快；防止執(zhí)行時間分配不正確；元素接口等元素不同步。

圖3 Timing and Execution分析內(nèi)容

2.2 Memory

      ISO 26262中對Memory相關(guān)要求做了明確的定義，主要從圖4列出的5個方面進(jìn)行設(shè)計和評估。Memory的分析主要是防止數(shù)據(jù)在內(nèi)存中破壞；保證數(shù)據(jù)訪問的一致性；防止內(nèi)存?？臻g的上溢出和下溢出；防止數(shù)據(jù)讀寫內(nèi)存地址越界。

圖4 Memory分析內(nèi)容

2.3 Exchange of Information

      ISO 26262中對Exchange of Information相關(guān)的要求做了明確的定義，主要從圖5列出的5個方面進(jìn)行設(shè)計和評估。Exchange of Information的分析主要是防止數(shù)據(jù)錯誤；防止數(shù)據(jù)重復(fù)操作；防止數(shù)據(jù)丟失；防止數(shù)據(jù)中插入其他數(shù)據(jù)；防止數(shù)據(jù)偽造或者數(shù)據(jù)地址篡改；防止數(shù)據(jù)操作序列出錯；防止數(shù)據(jù)一發(fā)多收出錯；發(fā)送的數(shù)據(jù)被部分接收；數(shù)據(jù)操作被阻塞。

圖5 Exchange of Information分析內(nèi)容

3 CP AUTOSAR安全機(jī)制

      CP AUTOSAR中根據(jù)ISO 26262的安全相關(guān)需求（Timing and Execution、Memory、Exchange of Information），提出了對應(yīng)的安全機(jī)制，即通過時間保護(hù)（WdgM and OS Timing Protection）、內(nèi)存保護(hù)（Memory Protection）、數(shù)據(jù)一致性（E2E算法）等安全機(jī)制來實現(xiàn)[12]。

3.1 Timing and Execution的安全機(jī)制

      針對功能安全對Timing and Execution 的安全機(jī)制，AUTOSAR 中主要依靠2 個主要的功能來保證，分別是AURTOSAR的WdgM協(xié)議棧以及OS的Timing Protection。每個被監(jiān)控的函數(shù)稱之為一個SE（Supervisor Entity）。在WdgM整個協(xié)議棧中，主要提供了3種監(jiān)控手段，具體的監(jiān)控作用內(nèi)容如下。

      1）Alive Supervisor監(jiān)控：周期函數(shù)在特定的時間內(nèi)調(diào)用不能頻率過快或者過慢。SE的WdgM_Checkpoint Reached每調(diào)用一次，對應(yīng)的Checkpoint的Alive Counter就會加1，主函數(shù)在定義的監(jiān)控周期內(nèi)會去檢測Alive Counter的數(shù)目。只有Alive Counter在該周期內(nèi)屬于定義的次數(shù)范圍才認(rèn)為該SE處于正常的模式，如果Alive Counter小于定義的調(diào)度次數(shù)最小值則認(rèn)為所監(jiān)控的SE 執(zhí)行太慢，相反Alive Counter大于定義的調(diào)度次數(shù)最大值，則認(rèn)為SE執(zhí)行得太快。

      2）Deadline Supervisor監(jiān)控：監(jiān)控2個函數(shù)調(diào)用間隔的時間限制。Deadline Supervision主要用于監(jiān)控非周期運(yùn)行的SE，主要定義了某個事件發(fā)生后，在特定的時間窗內(nèi)去執(zhí)行相應(yīng)SE的Checkpoint，一般認(rèn)為在事件發(fā)生后在定義的最短時間和最長時間內(nèi)去執(zhí)行相應(yīng)的Checkpoint，認(rèn)為程序?qū)儆谡５膱?zhí)行，如果在事件發(fā)生后執(zhí)行相關(guān)SE的Checkpoint時間小于最小的時間，或者大于最大的時間去執(zhí)行SE的Checkpoint都認(rèn)為是錯誤的。

      3）Logic Supervisor監(jiān)控：監(jiān)控程序按照設(shè)計的調(diào)用邏輯進(jìn)行調(diào)用。主要用于監(jiān)控程序是否按照正確的邏輯轉(zhuǎn)換條件去執(zhí)行。對于每一個Logical Supervision都有一個調(diào)用關(guān)系圖來表示SE中各個Checkpoint點在控制流上的轉(zhuǎn)換關(guān)系。

整個WdgM功能安全監(jiān)控機(jī)制如圖6所示。

圖6 WdgM功能安全監(jiān)控機(jī)制

      在WdgM中，每一個SE都有一個自己的Local Status來表示自己SE的Alive／Deadline／Logic Supervision的狀態(tài)，同時WdgM還有一個全局的Global Status來表示整個監(jiān)控功能的狀態(tài)[3]。在WdgM初始化完成后，每個SE的各個子功能監(jiān)控的Local Status以及Global Status 的狀態(tài)都是OK 的狀態(tài)。每個SE的Local Status以及Global Status都包含了OK、DEACTIVATED、FAILED、EXPIRED狀態(tài)。在每個SE的功能進(jìn)行監(jiān)控的時候，會根據(jù)監(jiān)控結(jié)果在MainFunction中設(shè)置對應(yīng)的Local Status。其中Alive Supervision有單獨(dú)的狀態(tài)設(shè)置，而Deadline和Logic Supervision共用一個Local Status。在使用時，可以根據(jù)每個SE 的3 個監(jiān)控設(shè)計的條件在MainFunction中設(shè)置對應(yīng)的狀態(tài)，同時MainFunction根據(jù)定義的所有SE的狀態(tài)輸出對應(yīng)的Global Status，如果最終的Global Status出現(xiàn)錯誤，User可以認(rèn)為系統(tǒng)的時間或者函數(shù)的調(diào)度功能已經(jīng)導(dǎo)致程序出現(xiàn)了Error，那么可以去觸發(fā)相應(yīng)的錯誤處理以及故障反應(yīng)。

      除了WdgM對程序的執(zhí)行以及邏輯進(jìn)行時序的監(jiān)控之外，在Task執(zhí)行的時候，可以通過OS的Timing Protection功能實現(xiàn)對函數(shù)調(diào)度以及Task被Block的時間監(jiān)控。相比于WdgM的監(jiān)控，OS Timing Protection的函數(shù)監(jiān)控更側(cè)重于非功能安全的任務(wù)Task調(diào)度以及被Block時間監(jiān)控。OS Timing Protection功能安全監(jiān)控機(jī)制如圖7所示。

圖7 OS Timing Protection功能安全監(jiān)控機(jī)制

      圖7中綠色的是低優(yōu)先級的Task，紅色的是高優(yōu)先級的Task。在實時搶占的系統(tǒng)中，低優(yōu)先級的Task可以被高優(yōu)先級的Task搶占。OS Timing Protection主要考慮低優(yōu)先級的Task在被高優(yōu)先級的Task搶占的情況下執(zhí)行時間不能超過圖中LOW Deadline定義的時間；保證被中斷或者高優(yōu)先級Task Block 的時間不能太長；保證LOW Inter-Arive Time的時間不能調(diào)度太快。在OS Timing Protection中，當(dāng)達(dá)到上述定義的錯誤時，可以選擇相應(yīng)的安全反應(yīng)（Reset操作、結(jié)束函數(shù)調(diào)用等）來保證程序的正常運(yùn)行。

3.2 Memory Protection安全機(jī)制

      在AUTOSAR中為了保證數(shù)據(jù)訪問過程中不能相互篡改，減少低功能安全等級或者QM的數(shù)據(jù)影響到功能安全的數(shù)據(jù)，需要增加內(nèi)存隔離和內(nèi)存保護(hù)。在AUTOSAR提供了基于Application級別的功能安全內(nèi)存保護(hù)機(jī)制，通過將不同的軟件組件分配到不同的Application中實現(xiàn)內(nèi)存訪問的隔離和內(nèi)存保護(hù)。Memory Protection功能安全監(jiān)控機(jī)制如圖8所示。

圖8 Memory Protection功能安全監(jiān)控機(jī)制

      根據(jù)功能安全的目標(biāo)，將模塊劃分為QM、ASIL-B、ASIL-D。對于每個等級的模塊組件按照功能安全等級進(jìn)行劃分。需要在內(nèi)存中定義QM、ASIL-B、ASIL-D的3個等級的RAM和ROM空間，并按照圖8的模塊將模塊內(nèi)的變量和代碼分別映射到QM、ASIL-B、ASIL-D的3個等級的RAM和ROM空間，同時結(jié)合圖8中灰色的圖框[硬件MPU（Memory Protection Unit）功能]實現(xiàn)對內(nèi)存的保護(hù)[10]。一旦出現(xiàn)低ASIL等級、QM函數(shù)或變量操作到高功能安全等級的，將會觸發(fā)硬件MPU保護(hù)措施，并根據(jù)實際應(yīng)用進(jìn)行錯誤處理。基于硬件MPU保護(hù)的實現(xiàn)邏輯如圖9所示。

圖9 基于硬件MPU保護(hù)的實現(xiàn)邏輯

      如圖9所示，內(nèi)存保護(hù)機(jī)制是基于OS進(jìn)行管理的，因此在實現(xiàn)內(nèi)存保護(hù)機(jī)制中必須依賴于OS的運(yùn)行。在集成OS操作系統(tǒng)中程序運(yùn)行在初始化階段會根據(jù)需要將內(nèi)存保護(hù)的地址設(shè)置成默認(rèn)值，或者將芯片全部內(nèi)存設(shè)置為都可以訪問[9]。在OS 使用的嵌入式軟件中會存在多個Application，每個Application含有多個Task，OS在運(yùn)行的時候可以通過調(diào)度切換Application和Task的執(zhí)行，因此OS執(zhí)行過程中會實時對Application和Task進(jìn)行判斷。當(dāng)檢測到正在運(yùn)行的Application或者Task存在內(nèi)存保護(hù)機(jī)制后根據(jù)設(shè)計中定義好的地址范圍操作MPU硬件的RAM和ROM地址，將該Application或者Task訪問的范圍寫入到MPU的寄存器，一旦程序接下來運(yùn)行的地址超過了定義的范圍，MPU硬件單元便會觸發(fā)硬件錯誤，軟件集成者便可以捕獲該錯誤，并設(shè)計錯誤回調(diào)函數(shù)進(jìn)行錯誤處理。

3.3 Exchange of Information安全機(jī)制

      針對功能安全提出的對數(shù)據(jù)傳輸和交互過程中出現(xiàn)的要求，在AUTOSAR中提供了E2E（End to End）相關(guān)的算法來保證數(shù)據(jù)在ECU與ECU之間或者ECU內(nèi)部之間的數(shù)據(jù)傳輸?shù)囊恢滦?/span>[2]，圖10展示了E2E保證數(shù)據(jù)傳輸一致性的原理。

圖10 Exchange of Information功能安全監(jiān)控機(jī)制

      AUTOSAR E2E Lib 提供了多種數(shù)據(jù)一致性保護(hù)的算法，主要包括以下幾個方面[11]。CRC Lib：通過填充CRC算法實現(xiàn)；Sequence Counter incremented：發(fā)送方增加，接收方Check 是否增加；Alive Counter：發(fā)送方增加，接收方Check變化，不Check增加；Data ID：每個IPDU Group表明特定的安全元素，特定的ECU信息，Data ID 也會用于CRC 計算；Timeout Detection：接收方檢測數(shù)據(jù)通信超時。

      圖10中3種AUTOSAR提供的數(shù)據(jù)一致性實現(xiàn)的方案采用了E2E Protection Wrap（每一個需要保護(hù)的數(shù)據(jù)都會使用一個單獨(dú)的E2E接口函數(shù)，同時保護(hù)數(shù)據(jù)的傳輸必須基于結(jié)構(gòu)體進(jìn)行）[1]。其中，路徑①代表在同一個ECU中同一個OS Application對發(fā)送和接收的數(shù)據(jù)進(jìn)行保護(hù)，主要采用E2E中的CRC算法實現(xiàn)。路徑②代表數(shù)據(jù)在同一個ECU不同的OS Application進(jìn)行數(shù)據(jù)傳遞，同時需要增加額外的機(jī)制來解決跨OS Application的數(shù)據(jù)交互，即圖10中的IOC模塊，通過增加IOC模塊來保證不同Application數(shù)據(jù)傳輸?shù)囊恢滦?。一般只采用CTC算法實現(xiàn)。路徑③實現(xiàn)了在不用的ECU之間數(shù)據(jù)一致性的保護(hù)機(jī)制，通常這種保護(hù)機(jī)制一般需要借助ECU之間的通信總線實現(xiàn)，常見的通信總線包括了CAN、LIN、Ethernet等。

4 結(jié)論

      上文針對功能安全要求以及對AUTOSAR提供的安全機(jī)制分析，將功能安全的要求和安全機(jī)制進(jìn)行了一一對應(yīng)。針對軟件功能安全中的時間和時序的保護(hù)可以使用AUTOSAR架構(gòu)中的WdgM協(xié)議棧，集成WdgM的Alive監(jiān)控、Deadline監(jiān)控以及Logic監(jiān)控實現(xiàn)對程序的時間監(jiān)控，集成OS的時間保護(hù)機(jī)制可以實現(xiàn)對Task級別的時間保護(hù)，避免調(diào)度時間出錯導(dǎo)致功能安全目標(biāo)的違背；針對軟件功能安全要求的內(nèi)存保護(hù)，可以結(jié)合AUTOSAR架構(gòu)中的OS提供的內(nèi)存保護(hù)機(jī)制設(shè)置Application訪問的內(nèi)存區(qū)間，結(jié)合MPU硬件模塊實現(xiàn)對內(nèi)存的訪問權(quán)限隔離，達(dá)到內(nèi)存保護(hù)的目的；針對軟件功能安全要求的數(shù)據(jù)交互的保護(hù)，主要借助于AUTOSAR提供的E2E算法實現(xiàn)ECU內(nèi)部數(shù)據(jù)交互以及ECU與ECU之間數(shù)據(jù)交互的保護(hù)。

      本文通過研究ISO 26262 的軟件安全要求，結(jié)合AUTOSAR提供的安全機(jī)制，從時間、內(nèi)存和數(shù)據(jù)交互3個方面提出了軟件安全機(jī)制的實現(xiàn)方案，對當(dāng)前車載軟件功能安全的實施具有重大意義。

參考文獻(xiàn)：

[1]陳燦，楊興達(dá)，方菱.基于決策表的AUTOSAR操作系統(tǒng)一致性測試研究[J].計算機(jī)工程與科學(xué)，2023，45（4）：622-629.

[2]宋俊飛，翟成超，范慧，等.基于AUTOSAR跨ECU平臺的E2E保護(hù)機(jī)制的實現(xiàn)[J].汽車電器，2023（3）：25-28.

[3]李思健，石春，吳剛，等.基于AUTOSAR的控制流檢測模塊的設(shè)計與實現(xiàn)[J].儀表技術(shù)，2022（4）：1-6，60.

[4]辛強(qiáng)，朱衛(wèi)兵，胡璟.基于ISO 26262的新能源汽車電子電器部件功能安全開發(fā)簡介[J].汽車零部件，2021（6）：63-65.

[5]李爭鵬.基于ISO 26262的驅(qū)動電機(jī)系統(tǒng)功能安全概念設(shè)計及測試[J].汽車實用技術(shù)，2022，47（23）：160-164.

[6]彭斐.ISO 26262保證汽車功能安全的新思路[J].汽車與配件，2015（37）：30-33.

[7]劉佳熙，于世濤，郭輝.符合ISO 26262要求的汽車起停系統(tǒng)功能安全開發(fā)[J].上海汽車，2014（4）：59-62.

[8]ISO 26262—2018，Road vehicles——Functional safety[S].

[9]葛紋材，朱元，王恩東，等.基于AUTOSAR標(biāo)準(zhǔn)的軟件內(nèi)存保護(hù)機(jī)制實現(xiàn)[J].信息通信，2020（11）：5-7.

[10]謝凌云.基于ISO 26262混合ASIL系統(tǒng)設(shè)計應(yīng)用研究[J].傳動技術(shù)，2021，35（4）：32-38.

[11]白志浩，張麗，吳肇蘇，等.基于ISO 26262的EV用動力電池系統(tǒng)功能安全設(shè)計[J].電源技術(shù)，2021（5）：626-629.

[12]還宏生.汽車設(shè)計中的安全要求及ISO 26262標(biāo)準(zhǔn)[J].汽車零部件，2012（10）：41-43.

[13]方曉穎.基于AUTOSAR標(biāo)準(zhǔn)的E2E保護(hù)[J].汽車與駕駛維修（維修版），2020（3）：81-83.

轉(zhuǎn)自智能汽車設(shè)計