由蓋世汽車、AUTOSAR組織、上海車展三方聯(lián)合主辦的SDVF2021第二屆軟件定義汽車高峰論壇暨AUTOSAR2021中國(guó)日于4月19-21日在上海舉辦，本次活動(dòng)也是2021上海車展的同期活動(dòng)之一，同時(shí)也是AUTOSAR組織在中國(guó)區(qū)唯一官方會(huì)議。本次會(huì)議邀請(qǐng)到了維克多汽車技術(shù)（上海）有限公司商業(yè)開發(fā)經(jīng)理曲越先生在本次論壇進(jìn)行了題為《基于AUTOSAR的功能安全解決方案》的主題演講，以下是他在本次演講的主要內(nèi)容：

大家下午好，我是維克多商業(yè)開發(fā)經(jīng)理曲越，這幾天有非常多嘉賓和專家分享了一些比較宏觀的主題，非常的硬核。而今天我們帶來的是具體的解決方案，AUTOSAR下的功能安全解決方案。今天的演講主要分為四個(gè)部分：第一部分，解釋一下功能安全相關(guān)的概念。第二和第三部分詳細(xì)介紹維克多針對(duì)Classic AUTOSAR和Adaptive AUTOSAR的功能安全解決方案。最后第四部分同樣是趨勢(shì)性的內(nèi)容，詳細(xì)介紹Fail-Operational系統(tǒng)中，安全架構(gòu)設(shè)計(jì)所面臨的挑戰(zhàn)。

ISO26262規(guī)范于2011年推出，2018年更新，其中詳細(xì)描述了汽車電子系統(tǒng)安全相關(guān)的概念。目的是在現(xiàn)有的技術(shù)層面，盡可能地降低汽車電子系統(tǒng)所帶來的風(fēng)險(xiǎn)。

什么是功能安全？首先，這里需要區(qū)分一下我們經(jīng)常提及的Safety 和 Security。Functional safety目的是防止由EE系統(tǒng)造成的意外的、不可預(yù)估的風(fēng)險(xiǎn)，這些風(fēng)險(xiǎn)可能會(huì)造成人身造成傷害。而Cyber Security 目的是防止黑客對(duì)系統(tǒng)的攻擊，這種風(fēng)險(xiǎn)是種人為的主動(dòng)因素，是可預(yù)測(cè)的。總結(jié)來看，Safety保護(hù)的主體是人身安全，而Security保護(hù)的主體是財(cái)產(chǎn)也就是汽車系統(tǒng)本身，那么實(shí)際歸根結(jié)底還是會(huì)回到人身安全。

ISO26262提出了FFI原則，F(xiàn)reedom from Interference。指的是，不同安全等級(jí)的模塊之間，故障產(chǎn)生的相互影響必須避免，也就是要防止級(jí)聯(lián)性故障。比如，一個(gè)ASIL A的模塊，原本來說自身的故障影響比較低，但如果ASIL A模塊自身故障影響了其他ASIL D的高風(fēng)險(xiǎn)模塊而導(dǎo)致了級(jí)聯(lián)性故障，那這個(gè)高風(fēng)險(xiǎn)模塊評(píng)估為ASIL D就失去意義。

故障方面，分為系統(tǒng)性故障和隨機(jī)故障。隨機(jī)故障通常發(fā)生在硬件方面，對(duì)于隨機(jī)故障當(dāng)前已經(jīng)有很多不同的數(shù)學(xué)模型可供使用以評(píng)估硬件的安全性。這不多做討論。而軟件方面一般會(huì)產(chǎn)生的是系統(tǒng)性故障，由一些特定的人為因素引起。系統(tǒng)性故障是可以被檢測(cè)到的。但是，當(dāng)前為系統(tǒng)性故障建立數(shù)學(xué)模型的所有嘗試都沒有成功，也就意味著比較難以預(yù)測(cè)。所以要避免系統(tǒng)性故障，需要從開發(fā)流程方面下手。

軟件方面的系統(tǒng)性故障一般分為三個(gè)方面：內(nèi)存方面的故障，比如野指針，堆棧溢出，變量的寫入越界等等。時(shí)間上的故障，比如死循環(huán)，過高頻率的中斷，還有由于一些不正常的輸入導(dǎo)致的計(jì)算時(shí)間過長(zhǎng)等。通訊故障，最典型的比如報(bào)文丟失、重復(fù)、損壞以及延遲等等。

接下來，我們分別來探討Classic AUTOSAR以及Adaptive AUTOSAR的功能安全解決方案中，對(duì)于這些故障的檢測(cè)和處理措施。

首先介紹一下Classic AUTOSAR功能安全解決方案。Vector對(duì)于AUTOSAR的解決方案統(tǒng)稱為MICROSAR，功能安全解決方案主要分為圖中的五個(gè)部分。

SafeOS需要提供Memory Protection，配合硬件提供的MPU (Memory Protection Unit) 來實(shí)現(xiàn)內(nèi)存保護(hù)，目的是達(dá)到FFI原則。SafeRTE除RTE的基本功能外，能夠提供ECU內(nèi)部不同ASIL等級(jí)之間的交互，并保障交互的安全性，目的也是達(dá)到FFI要求。SafeWDG用于監(jiān)測(cè)代碼執(zhí)行時(shí)間以及代碼執(zhí)行順序等錯(cuò)誤，目的是防止代碼跑飛。SafeE2E用來檢測(cè)剛剛提到的通訊方面的諸多問題。SafeBSW，除了剛剛我們提及的模塊以外，SafeBSW是其他所有底層模塊的統(tǒng)稱，整體使用SafeBSW可以提高系統(tǒng)性能，后面會(huì)介紹在技術(shù)方面，SafeBSW的選擇依據(jù)。除此以外，SafeBSW中的很多模塊還提供一些額外的安全特性，比如使用安全ECUM進(jìn)行正確的初始化過程，使用NvM安全讀寫非易失內(nèi)存的數(shù)據(jù)，保護(hù)數(shù)據(jù)存儲(chǔ)的一致性等等。

接下來我們分別來看，首先是SafeOS部分，除了OS代碼本身需要達(dá)到ASIL-D以外，AUTOSAR定義了四個(gè)OS等級(jí)，能供提供額外的安全機(jī)制。

SC1是基礎(chǔ)OSEK OS + Schedule Table。SC2在SC1基礎(chǔ)上添加了Timing Protection功能，可以預(yù)先規(guī)劃Task和二類中斷的時(shí)間預(yù)算來進(jìn)行監(jiān)測(cè)，超出時(shí)間預(yù)算的代碼將會(huì)跑進(jìn)OS Protection Hook中，讓用戶自定義代碼處理。SC3在SC1基礎(chǔ)上添加了Memory Protection功能，也就是配合MPU做內(nèi)存保護(hù)。出于成本考慮，功能安全項(xiàng)目通常是混合ASIL等級(jí)的情況，基本都是需要SC3以上等級(jí)的OS。SC4相當(dāng)于SC2+SC3，既有內(nèi)存保護(hù)也有時(shí)間保護(hù)。

當(dāng)然，Vector提供的所有等級(jí)的SafeOS都可支持單核或者多核的使用場(chǎng)景。

Safe WDG。 AUTOSAR看門狗架構(gòu)如這張圖所示，看門狗以CheckPoint為單位進(jìn)行監(jiān)測(cè)，也就是代碼中嵌入的監(jiān)測(cè)點(diǎn)。WdgM能夠提供三種監(jiān)測(cè)方式：Deadline Monitoring，定義時(shí)間預(yù)算，監(jiān)測(cè)兩個(gè)check point之間的時(shí)間是否超出預(yù)算。Alive monitoring，定義的是執(zhí)行次數(shù)，監(jiān)測(cè)特定時(shí)間段中，達(dá)到checkpoint的次數(shù)是否在預(yù)算范圍內(nèi)。比如定義某個(gè)checkpoint需要在100ms時(shí)間內(nèi)，要運(yùn)行2-3次，如果超出或者沒達(dá)到該次數(shù)，則認(rèn)為監(jiān)測(cè)失敗，引起復(fù)位。Logic monitoring程序流監(jiān)控比較復(fù)雜，定義的是程序跳轉(zhuǎn)軌跡。比如定義從checkpoint1只能跳到2和3，如果跳到4，就認(rèn)為監(jiān)測(cè)失敗，引起復(fù)位。

通常在混合安全等級(jí)系統(tǒng)中，可以根據(jù)不同安全等級(jí)來定義不同的監(jiān)測(cè)實(shí)體，然后針對(duì)不同的監(jiān)測(cè)實(shí)體使用不同的監(jiān)測(cè)方式，以這么一種組合的形式對(duì)系統(tǒng)整體進(jìn)行監(jiān)測(cè)。

SafeE2E方面，AUTOSAR定義了諸多E2E Profile類型，Vector所提供的E2E lib現(xiàn)在直接包含了所有AUTOSAR標(biāo)準(zhǔn)的Profile類型以供用戶自行選用。對(duì)于一些OEM定義的特殊Profile可以單獨(dú)提供。

Safe RTE，除了RTE最基本的功能以外，還要提供不同安全等級(jí)模塊的交互。使用過AUTOSAR的觀眾都知道，維克多作為基礎(chǔ)軟件供應(yīng)商，通常提供的代碼包分幾個(gè)部分，一部分是靜態(tài)代碼，屬于不需要人為修改的靜態(tài)部分。一部分是由工具生成的動(dòng)態(tài)代碼。RTE這里比較特殊，RTE代碼全部是由工具生成，也就意味著在功能安全方面需要做單獨(dú)的考量。

既然RTE代碼全部由工具生成，也就是說，我們需要評(píng)估工具的安全性。在ISO26262第八部分同樣定義了工具的置信度，TCL等級(jí)。不同TCL等級(jí)需要不同的驗(yàn)證過程。其中，TCL1不需要額外的驗(yàn)證。

TCL等級(jí)有兩個(gè)影響的因素。TI表示工具的功能異常情況下，會(huì)對(duì)安全需求造成影響的可能性。TD表示工具能夠提前預(yù)防或者檢測(cè)出軟件錯(cuò)誤的置信度。最后綜合判斷出工具的置信度 TCL等級(jí)。

達(dá)芬奇Configurator PRO工具，可以達(dá)到TI2和TD1等級(jí)，最終證明為TCL1。 TI2不需要額外的證明，那么如何證明達(dá)到TD1呢？

首先DaVinci Configurator Pro中的插件，RTE Generator需要經(jīng)過很多額外的開發(fā)工作量，所生成的代碼也需經(jīng)過ISO26262第六部分來進(jìn)行測(cè)試，這只是Vector這邊的工作。那么對(duì)于用戶來說，拿到代碼包之后，首先在配置過程中，達(dá)芬奇工具已經(jīng)具備了一些驗(yàn)證和自查的功能。與此同時(shí)，我們會(huì)隨功能安全代碼包提供一個(gè)RTE檢測(cè)工具叫做RTE Analyzer。用戶在配置生成RTE代碼后，需要通過RTE Analyzer檢測(cè)并生成報(bào)告，對(duì)報(bào)告進(jìn)行分析并優(yōu)化配置項(xiàng)。

通過這種配合，工具整體也就認(rèn)為能夠達(dá)到TD1，最終生成的RTE代碼也就能夠達(dá)到相應(yīng)的ASIL等級(jí)。

一個(gè)功能安全的系統(tǒng)通常是混合安全等級(jí)的。Vector對(duì)此提出了兩種安全策略，Partitioning和High Performance Integrity。比如圖中ECU1所分配的功能僅有QM，也就是說沒有功能安全需求，不做討論。對(duì)于ECU2，兩個(gè)主要功能是QM等級(jí)，一個(gè)是ASIL，也就是說大部分功能是安全不相關(guān)的。那么通常使用Partitioning的功能安全策略。先看ECU4，它所有功能均帶有ASIL等級(jí)，那么通常采用High Performance Integrity策略，所有模塊都需要具有ASIL等級(jí)，且安全等級(jí)需要額外提升。反觀ECU3，一半一半，那么兩種策略二選一即可。

那么剛剛提到的兩種安全策略區(qū)別是什么呢？先說Partitioning局部功能安全策略，這種策略是從所有模塊中，摘取了最小化的核心模塊做成帶有ASIL等級(jí)，比如RTE、E2E、OS、WDG以及EcuM初始化序列。High Performance Integrity策略，所有BSW模塊均需要按照系統(tǒng)中的最高安全等級(jí)來提供，成本比較高。兩者區(qū)別就在于是否需要具有Safe BSW。

那么SafeBSW選擇依據(jù)是什么呢？首先，我們說BSW中服務(wù)層是能夠提供非常多服務(wù)接口給到應(yīng)用層的，這就存在一種情況。假如我們的應(yīng)用層SWC和提供服務(wù)的BSW不在同一個(gè)安全等級(jí)下，也就是不在同一個(gè)內(nèi)存分區(qū)中，這種跨內(nèi)存分區(qū)的調(diào)用方式會(huì)消耗額外的運(yùn)行時(shí)間。也就是說，考慮到整個(gè)系統(tǒng)的運(yùn)行效率，如果多數(shù)功能具有功能安全，選擇ASIL的SafeBSW更加劃算，反之選擇QM BSW即可。這只是技術(shù)上的衡量因素，實(shí)際還有很多因素需要考量，比如成本。

接下來介紹Adaptive AUTOSAR功能安全解決方案。首先，在Adaptive AUTOSAR的模塊中，除了代碼本身需要達(dá)到相應(yīng)的ASIL等級(jí)要求之外，所提供的安全機(jī)制與Classic AUTOSAR是基本類似的。對(duì)于通訊上的保護(hù)仍然使用E2E。AP使用的是基于服務(wù)的SOA通訊，而基于服務(wù)的通訊是動(dòng)態(tài)數(shù)據(jù)長(zhǎng)度的，AUTOSAR中的Profile4、6、7可以支持這種動(dòng)態(tài)數(shù)據(jù)長(zhǎng)度。AP中提供平臺(tái)健康管理PHM模塊，該模塊類似于CP中的看門狗，同樣提供Alive、Deadline、Logic的監(jiān)測(cè)方式。另外對(duì)于內(nèi)存，需要確保數(shù)據(jù)的完整性和一致性。比如對(duì)于相同數(shù)據(jù)的讀寫操作不能同時(shí)，以確保一致性。另外可以對(duì)數(shù)據(jù)添加CRC校驗(yàn)，以保證完整性。

但是前面說的這些故障檢測(cè)機(jī)制對(duì)于Fail Operational系統(tǒng)來說就不再夠用了，后面我們會(huì)詳細(xì)討論Fail Operational系統(tǒng)的要求。

前面談到的僅僅是AP中提供的安全機(jī)制，而AP只是一個(gè)中間件，除此以外，還需要考慮Posix OS和C++代碼本身的功能安全問題。C++語(yǔ)言的使用給功能安全帶來很多全新的挑戰(zhàn)。最典型的問題是如何處理動(dòng)態(tài)內(nèi)存分配。操作系統(tǒng)在運(yùn)行時(shí)需要請(qǐng)求和釋放內(nèi)存，這會(huì)帶來一些新的故障。

對(duì)于Fail Safe系統(tǒng)，代碼層面的風(fēng)險(xiǎn)比較典型的是懸空指針造成的use after free UAF，懸空指針指一個(gè)長(zhǎng)生命周期的指針指向了一個(gè)短生命周期提前被釋放的變量。再比如重復(fù)使用、分配或者釋放內(nèi)存等等。要解決這些問題，開發(fā)階段需要遵照一些代碼規(guī)則手冊(cè)，以及使用靜態(tài)代碼分析工具進(jìn)行分析等，比如使用VectorCast。

對(duì)于Fail Operational系統(tǒng)，代碼風(fēng)險(xiǎn)包括內(nèi)存溢出，內(nèi)存分配不連續(xù)導(dǎo)致的內(nèi)存碎片等等。由于需要確保系統(tǒng)的可用性，那么對(duì)于故障的可接受程度也會(huì)更低。常規(guī)的解決策略包括使用恒定時(shí)間的內(nèi)存分配，使用OS預(yù)留的內(nèi)存，以及使用邊界內(nèi)存等等。

另外，ISO26262第六部分的Table6提及了一些軟件單元設(shè)計(jì)和實(shí)現(xiàn)的原則，包括需要避免Exceptions，這點(diǎn)在MISRA規(guī)范中同樣有所體現(xiàn)。原則上來說，一個(gè)函數(shù)僅能夠含有一個(gè)入口和出口，而Exceptions的情況會(huì)在出現(xiàn)故障時(shí)，在函數(shù)正確出口到達(dá)之前就錯(cuò)誤的改變了程序流向，引向了其他出口，這會(huì)干擾關(guān)鍵系統(tǒng)的可預(yù)測(cè)性。AUTOSAR中定義的API都已經(jīng)避免了Exceptions。

還存在一個(gè)問題，C++中的Templates模板，包括函數(shù)模板或者類模板，目的是相同類型代碼的重復(fù)使用，但這些模板的使用也是之前在C語(yǔ)言中沒有遇到的。尤其是對(duì)于Templates的測(cè)試來說，需要額外的測(cè)試過程，而手動(dòng)的創(chuàng)建測(cè)試用例比較耗時(shí)而且很容易有疏漏，所以通常這種測(cè)試需要使用額外的測(cè)試工具來支持，比如Vector這邊能夠提供的VectorCast工具。

這張圖是Adaptive AUTOSAR的整體架構(gòu)。AP是一個(gè)在POSIX OS之上的中間件。而OS在功能安全方面扮演的角色也非常重要，所以同樣需要考慮OS的功能安全實(shí)現(xiàn)。當(dāng)前我們的AP產(chǎn)品已實(shí)現(xiàn)集成在PikeOS、QNX、風(fēng)河的Vxworks、GHS的Integrity以及Linux等POSIX OS之上。

這里是Vector Adaptive Microsar產(chǎn)品的Roadmap，其中最基本的模塊已經(jīng)都具備量產(chǎn)條件了，并且也已經(jīng)有了OEM在基于我們的AP產(chǎn)品做量產(chǎn)。這里可以看到一些額外模塊的開發(fā)進(jìn)度。最下方是我們AP產(chǎn)品支持的AUTOSAR版本變動(dòng)情況。其中帶有功能安全的AP產(chǎn)品預(yù)計(jì)在2021年底將會(huì)正式釋放。

前面我們提到了Fail Operational，那么含義究竟是什么呢？Fail Operational如何實(shí)現(xiàn)呢？

隨著自動(dòng)化駕駛程度越來越高，安全相關(guān)的功能處理措施也在發(fā)生演變，從最初的ABS功能需要做數(shù)據(jù)冗余，ESP功能需要做內(nèi)存分區(qū)，到緊急剎車需要做前面提到的高性能功能安全集成。再到后面越來越高的自動(dòng)化程度，可能直接需要做功能的冗余而不單單是數(shù)據(jù)冗余了。這就牽扯到了Fail Safe系統(tǒng)到Fail Operational系統(tǒng)的演變。

Fail-Safe系統(tǒng)指的是，如果車輛出現(xiàn)故障，故障需要能夠檢測(cè)到，然后允許直接去禁用故障的功能，甚至是減速至停車。Fail-Operational指的是，車輛出現(xiàn)故障時(shí)，仍然需要提供基礎(chǔ)功能，以滿足系統(tǒng)的基本運(yùn)行。之前Fail Operational系統(tǒng)通常是用于航空航天方面這種不能停的交通工具，故障后，也最起碼要能夠維持飛行之類的最基本操作。汽車自動(dòng)化程度高了之后，不再全靠人為操作車輛了，那么同樣需要實(shí)現(xiàn)fail-operational系統(tǒng)。

隨著自動(dòng)駕駛程度的提升，故障處理的方式也在逐漸變化。對(duì)于Level 0 QM的系統(tǒng)，安全不相關(guān)，不多做考慮。對(duì)于較低自動(dòng)化程度的系統(tǒng)，比如Level 1和2，通常使用Fail Safe。這類系統(tǒng)的故障處理措施關(guān)鍵字是檢測(cè)，這要求故障必須要被檢測(cè)到，故障功能也可直接關(guān)閉。故障檢測(cè)主要針對(duì)時(shí)序、內(nèi)存管理、通訊等方面。一旦發(fā)生故障，需要由駕駛員充當(dāng)Fallback的角色，接管車輛逐步安全停車。

對(duì)于高自動(dòng)化程度的系統(tǒng)，比如Level 3、4、5，就需要使用Fail-Operational來進(jìn)行處理了，這時(shí)駕駛員不再充當(dāng)接管故障系統(tǒng)的角色。那么所有基本功能都要求是可用的，或者要能夠修復(fù)的。功能可以降級(jí)，但不可以失效。那么這里就要求，通過合理的開發(fā)流程，避免系統(tǒng)性故障。

對(duì)于Fail-Operational系統(tǒng)，處理故障的方法有兩種，一種是Tolerance容錯(cuò)，ISO26262將其描述為，盡管系統(tǒng)軟件存在故障，容錯(cuò)的機(jī)制仍然要試圖讓系統(tǒng)保持正常運(yùn)行。容錯(cuò)通常通過冗余來實(shí)現(xiàn)，而這種冗余要求具有多樣性，防止在特定條件下，冗余和原系統(tǒng)同時(shí)發(fā)生故障。我們認(rèn)為，這種冗余的方式對(duì)于基礎(chǔ)軟件層面來說并不適用，冗余的機(jī)制要求基礎(chǔ)軟件開發(fā)兩套完全不同的代碼同時(shí)運(yùn)行。既浪費(fèi)硬件資源，也浪費(fèi)人力。

單從基礎(chǔ)軟件角度來看，Vector更為傾向第二種方式，Avoidance故障避免，這就要求根據(jù)ISO26262第6部分，規(guī)范開發(fā)流程。代碼需要保證FFI的要求，報(bào)文確保不會(huì)出現(xiàn)重復(fù)、丟失、損壞等各種故障，BSW部分需要確保進(jìn)行正確的模式切換等。Vector的開發(fā)過程中遵循原子設(shè)計(jì)，將單一的功能劃分為較小的單元，降低復(fù)雜度，并且盡可能使單元之間沒有數(shù)據(jù)交互，降低耦合度。另外就是測(cè)試，Vector的Classic AUTOSAR產(chǎn)品從單元到組件測(cè)試覆蓋度全部達(dá)到百分之百。Vector基礎(chǔ)軟件經(jīng)歷了市場(chǎng)常年的檢驗(yàn)，并且有大量的項(xiàng)目經(jīng)驗(yàn)不斷地進(jìn)行完善，已經(jīng)具備了足以支持Fail Operational的條件。

剛剛我們分別介紹了AP，CP下的功能安全，以及Fail Safe和Fail Operational的相關(guān)概念，那么如何結(jié)合這些進(jìn)行部署實(shí)現(xiàn)？

通常，我們建議在微控制器上，比如當(dāng)前一些主流的MCU上，使用Classic AUTOSAR來實(shí)現(xiàn)Fail Operational。軟件層面來看，Classic AUTOSAR比Adaptive AUTOSAR具備更多的靜態(tài)特性和可預(yù)測(cè)性，且Classic AUTOSAR基礎(chǔ)軟件已經(jīng)足夠成熟。硬件方面來看，當(dāng)前的微控制器也比微處理器結(jié)構(gòu)具有更多的安全機(jī)制，如lock step鎖步核等。

對(duì)于在微處理器上運(yùn)行Adaptive AUTOSAR，建議從構(gòu)建Fail Safe系統(tǒng)入手。原因其實(shí)就是反過來看，從軟件方面來說，我們都知道代碼成熟度需要經(jīng)過時(shí)間檢驗(yàn)，當(dāng)前Adaptive AUTOSAR本身發(fā)展的時(shí)間較短，很難達(dá)到Classic AUTOSAR的成熟度。硬件方面，雖然微處理器芯片在高性能計(jì)算等方面有著不可取代的優(yōu)勢(shì)，但目前的微處理器安全機(jī)制仍然不足。當(dāng)然，滿足功能安全的基本要求是可以的，但是對(duì)于Fail Operational系統(tǒng)，硬件上仍然有比較長(zhǎng)的路要走。

我們剛剛提到，在基礎(chǔ)軟件層面，Vector通過Avoidance實(shí)現(xiàn)Fail Operational，這只是基礎(chǔ)軟件層面達(dá)到Fail Operational的要求。

那么從整個(gè)ECU系統(tǒng)層面來看，達(dá)到fail-operational的策略就需要使用Tolerance容錯(cuò)。整個(gè)ECU層面需要部署Fallback的冗余ECU，冗余ECU允許功能降級(jí)。另外，AP部分由于實(shí)現(xiàn)的僅是Fail Safe，所以需要單獨(dú)來做冗余，這個(gè)微處理器的冗余目的不在于提高AP本身的可用性，而是為了保證每個(gè)通道計(jì)算的完整性。這種情況下，那些需要保證可用性需求的功能，也就是fail-operational相關(guān)的部分功能，需要分配給Classic AUTOSAR部分。

這里存在兩種方式，一種是圖中這樣，ECU中分別部署一個(gè)微處理器運(yùn)行AP和一個(gè)微控制器運(yùn)行CP。兩者可以通過以太網(wǎng)等或者SPI等方式連接，自定義IPC通訊。

另外，當(dāng)前的一些微處理器，比如一些SOC異構(gòu)芯片，其中M核或者R核可以運(yùn)行CP，A核用來運(yùn)行AP。這類芯片具有安全島，添加了很多安全機(jī)制，比如鎖步核、MMU或MPU等，同樣為CP的運(yùn)行提供了安全保障，再加上整個(gè)芯片層面的冗余，那么仍然認(rèn)為CP部分能夠達(dá)到Fail Operational。這種情況下，AP與CP之間只需要通過Shared Memory方式進(jìn)行IPC通訊。

當(dāng)前對(duì)于Fail Operational的探討仍然在進(jìn)行，對(duì)于AP的fail-operational實(shí)現(xiàn)也仍然有著很長(zhǎng)的路要走。

下面是維克多汽車在本次大會(huì)中的精彩瞬間：