來源 | Vehicle攻城獅

一、汽車E/E架構(gòu)：分布式->域集中->中央計(jì)算機(jī)

目前的汽車有多達(dá)幾十甚至上百個電子控制單元并連接到多種總線上，平均來說，目前的汽車大約采用25個ECU，但一些高端車型已經(jīng)超過100個ECU。在過去，汽車電子電氣架構(gòu)一直遵循著“一個功能一個盒子”的分布式架構(gòu)模式。如變速箱控制由TCU負(fù)責(zé)，發(fā)動機(jī)控制由EMS負(fù)責(zé)，雖這兩個同樣在動力域但分別由供應(yīng)商提供各自的硬件和軟件。在這樣的汽車電子電氣架構(gòu)形式下，每增加一個功能，就需要動相應(yīng)的控制器，涉及多方的交流和維護(hù)成本，進(jìn)一步增加系統(tǒng)的復(fù)雜性和成本。最終會導(dǎo)致一個規(guī)模更大且復(fù)雜的車載網(wǎng)絡(luò)和布線，也從另一方面影響整車的輕量化。 

面對汽車功能和軟件復(fù)雜度的提升，需要對汽車E/E架構(gòu)進(jìn)行重構(gòu)，建立更加靈活的體系架構(gòu)。域控制器也是最近這些年才熱起來的，所謂的域就是將整車劃歸為不同的區(qū)，如動力域、車身域、底盤域、娛樂域等，每個域只掛載單個控制器來負(fù)責(zé)所在域的功能，減少之前一個功能、一個“盒子”的分布式E/E架構(gòu)復(fù)雜的布線和集成：其實(shí)就是將多個控制器的軟件糅合進(jìn)一個控制器，例如對于純電車，動力域有BMS、MCU、VCU、DCDC等控制器，將這些控制器的功能全部放在一個控制器里，并交給一方來做，不僅省了其他控制器硬件成本的錢，也由對接多方轉(zhuǎn)為對接一方，想想也美滋滋。

域控制器可大大降低控制器數(shù)量和整車布線，而多核異構(gòu)芯片、Hypervisor等技術(shù)都從軟硬件方面為域控制發(fā)展和應(yīng)用提供了支持。目前BOSCH等供應(yīng)商都已有相應(yīng)的域控制器產(chǎn)品，但實(shí)現(xiàn)真正的域集中E/E架構(gòu)依然還需要很長時間，畢竟這不是一己之力才能實(shí)現(xiàn)的，需要OEM、供應(yīng)商等共同大力合作和推進(jìn)才能實(shí)現(xiàn)。例如同一個域控制器中軟件可能由多個供應(yīng)商提供，每個供應(yīng)商除了負(fù)責(zé)各自軟件的升級，還涉及復(fù)雜且不同類型軟件的集成和測試，那么使集成和升級工作變的相對容易些就是一個問題。再比如不同域的域控制器由不同供應(yīng)商與OEM合作開發(fā)，又會帶來很多新的問題。

域控制器最終的目標(biāo)是中央計(jì)算機(jī)架構(gòu)，中央計(jì)算機(jī)由異構(gòu)的多核處理器構(gòu)成，將整車功能集中到一起。

二、在基于信號通訊的基礎(chǔ)上引入面向服務(wù)（SOA）的通訊，并融合兩者的優(yōu)勢

基于信號的通訊方式，即信息發(fā)送者不Care誰接收而只負(fù)責(zé)將信號發(fā)送出去，接收者也不Care是誰發(fā)送的而只負(fù)責(zé)接收自己的想要的即可。基于信號的通訊可將某節(jié)點(diǎn)的某信息通過總線傳送給需要該信息的其他節(jié)點(diǎn)，信息主要為一些物理狀態(tài)值及一些控制值，如發(fā)送機(jī)轉(zhuǎn)速、車速等，信號有周期、事件或混合觸發(fā)方式。

基于信號的通訊是目前車載總線普遍采用的，如控制器之間通過CAN總線進(jìn)行的信息傳輸，我們關(guān)注的是通訊矩陣上的幀、幀中所包含的信號、周期和交互的節(jié)點(diǎn)等信息。

SOA是一種軟件架構(gòu)，同時也是一種軟件設(shè)計(jì)方法和理念，在IT領(lǐng)域已有數(shù)十年的應(yīng)用經(jīng)驗(yàn)。SOA具備 “松耦合”、”接口標(biāo)準(zhǔn)可訪問”和”易于擴(kuò)展”等特點(diǎn)，使得開發(fā)人員能以最小的軟件變更應(yīng)對迭代多變的客戶需求。迄今為止，對于面向服務(wù)的架構(gòu)（Service-Oriented Architecture，SOA）還沒有一個公認(rèn)的定義，許多組織從不同的角度對 SOA 進(jìn)行了描述，較為典型的有以下三個：

（1）W3C 的定義：SOA 是一種應(yīng)用程序架構(gòu)，在這種架構(gòu)中，所有功能都定義為獨(dú)立的服務(wù)，這些服務(wù)帶有定義明確的可調(diào)用接口，能夠以定義好的順序調(diào)用這些服務(wù)來形成業(yè)務(wù)流程。

（2）Service-architecture.com 的定義：服務(wù)是精確定義、封裝完善、獨(dú)立于其他服務(wù)所處環(huán)境和狀態(tài)的函數(shù)。SOA 本質(zhì)上是服務(wù)的集合，服務(wù)之間彼此通信，這種通信可能是簡單的數(shù)據(jù)傳送，也可能是兩個或更多的服務(wù)協(xié)調(diào)進(jìn)行某些活動。服務(wù)之間需要某些方法進(jìn)行連接。

（3）Gartner 的定義：SOA 是一種 C/S 架構(gòu)的軟件設(shè)計(jì)方法，應(yīng)用由服務(wù)和服務(wù)使用者組成，SOA 與大多數(shù)通用的 C/S 架構(gòu)模型不同之處，在于它著重強(qiáng)調(diào)構(gòu)件的松散耦合，并使用獨(dú)立的標(biāo)準(zhǔn)接口。

那如何理解SOA呢？理解SOA要以下面的例子先了解服務(wù)、服務(wù)接口和服務(wù)相關(guān)角色三個概念：

服務(wù)指的是某種功能的函數(shù)或方法，如上面的Weather Service和Map Service可分別提供天氣和地圖信息，就是一種服務(wù)。而服務(wù)接口則是服務(wù)與外界聯(lián)系的窗口，及作為服務(wù)模塊與外界能夠進(jìn)行信息交互的API。

常用的服務(wù)接口有方法Method、事件Event和字段Feild（可參考本公眾號車載以太網(wǎng)那兩篇），如下：

服務(wù)相關(guān)角色我們常接觸的有服務(wù)器端Server、客戶端Client和服務(wù)注冊和代理方，首先服務(wù)注冊和代理實(shí)現(xiàn)服務(wù)的注冊/訂閱/發(fā)布等；客戶端用于使用服務(wù)接口調(diào)用使用服務(wù)，而服務(wù)器端則用于實(shí)現(xiàn)服務(wù)。

汽車為何要引入SOA？首先基于SOA的通訊方式有如下優(yōu)點(diǎn)：

1、服務(wù)高內(nèi)聚，軟件易重用：一個服務(wù)往往只關(guān)注一件事并把這件事做好，這件事的內(nèi)容（功能）需要從業(yè)務(wù)的角度進(jìn)行梳理，

2、服務(wù)的靈活部署：通過服務(wù)發(fā)現(xiàn)機(jī)制，可在控制器運(yùn)行時獲取服務(wù)的位置和提供方，并可在整車生命周期內(nèi)調(diào)整服務(wù)角色的部署位置，使功能分配更靈活。

3、軟件更新升級更快捷：一個功能改變可能只需要升級和更新一個服務(wù)，而且服務(wù)是一個獨(dú)立可執(zhí)行單元可單獨(dú)安裝升級，因此軟件維護(hù)和擴(kuò)展更容易。

因此基于上面的優(yōu)勢，伴隨著汽車智能化、網(wǎng)聯(lián)化、共享化的趨勢，終端用戶對車輛功能的預(yù)期也悄然發(fā)生著改變，汽車在實(shí)現(xiàn)高等級自動駕駛/輔助駕駛功能的同時，也更趨向于提升用戶體驗(yàn)，例如滿足快速的功能更新和升級，可以提供個性化、人性化、差異化的功能與服務(wù)等。面向服務(wù)的軟件架構(gòu)(Service-Oriented Architecture)正為未來的車輛軟件服務(wù)提供良好的解決方案。不同于傳統(tǒng)汽車電子電氣架構(gòu)中面向信號的架構(gòu)，面向服務(wù)的軟件架構(gòu)(SOA)通過標(biāo)準(zhǔn)化的服務(wù)接口，松耦合的服務(wù)機(jī)制以及可組合擴(kuò)展的服務(wù)特性

基于上面的介紹，基于信號的通訊僅支持發(fā)送和接收模式，支持的數(shù)據(jù)類型簡單且可擴(kuò)展性差，適用于有限大小數(shù)據(jù)交互的應(yīng)用場景。而諸如自動駕駛等先進(jìn)應(yīng)用場景加入后，大量數(shù)據(jù)的動態(tài)交互必須采用面向服務(wù)的通訊方式以提高通訊效率降低負(fù)載，在該種方式下，接收者作為客戶端，只需要查找、訂閱服務(wù)等待接收信息即可，而發(fā)送者作為服務(wù)提供者只需要給訂閱者提供服務(wù)和信息即可，因基于SOA的通訊支持請求/響應(yīng)模式，可擴(kuò)展性強(qiáng)且支持復(fù)雜數(shù)據(jù)的傳輸，因此應(yīng)發(fā)揮各自優(yōu)勢。

三、軟件合作模式：靈活豐富的合作開發(fā)模式

繼開創(chuàng)“軟件定義汽車”的特斯拉風(fēng)生水起后，一時“軟件定義汽車”的妖風(fēng)四起，在大眾成立軟件開發(fā)獨(dú)立部門之后，豐田也正式成立軟件子公司-Woven Planet Holdings，專注于開發(fā)自動駕駛、新的汽車操作系統(tǒng)以及高清地圖等軟件業(yè)務(wù)。國內(nèi)上汽等主機(jī)廠也紛紛成立自己的軟件中心，例如上汽的零束，都想在這次變革中掌握軟件開發(fā)的主動權(quán)。

傳統(tǒng)開發(fā)模式為，整車廠提供需求，供應(yīng)商負(fù)責(zé)實(shí)現(xiàn)軟硬件，類似BOSCH、大陸等這些跨國500強(qiáng)，在這些零部件的軟硬件開發(fā)上經(jīng)驗(yàn)豐富，產(chǎn)品迭代了幾十代，無論從成本還是穩(wěn)定性，相比整車廠自己開發(fā)的軟件可以說是碾壓的存在，而且還有專利加持，整車廠轉(zhuǎn)型軟件可以說是舉步維艱，就拿 ESP 車身穩(wěn)定系統(tǒng)來說，日系的廠家開發(fā)出了同樣的功能，但是由于專利限制，甚至連 ESP 的名字都不能叫，改名 VSC ，可想而知其在開發(fā)階段為了規(guī)避專利風(fēng)險，到底饒了多少彎路。這些對于要轉(zhuǎn)型軟件開發(fā)的整車廠也是一樣的，行業(yè)壁壘不是那么容易破除。再有就是實(shí)實(shí)在在的高端軟件人才吸引能力，汽車屬于典型的重資產(chǎn)行業(yè)，要造車的話需要買地建廠買設(shè)備建產(chǎn)線，而當(dāng)前火熱的軟件開發(fā)IT 行業(yè)，人的工資就是最大的投資成本，說白了，汽車行業(yè)軟件從業(yè)人員的公司，和互聯(lián)網(wǎng)無法站在同一競技擂臺上進(jìn)行比對，所以整體上是缺少高端軟件人才的，這樣造成了當(dāng)前整車廠軟件開發(fā)的轉(zhuǎn)型困境。

基于如上幾點(diǎn)，整車廠已經(jīng)發(fā)現(xiàn)軟件開發(fā)不在是傳統(tǒng)的單個工廠物料而已，很快就會成為自家公司的核心競爭力，所以開始下重力氣建立軟件研發(fā)團(tuán)隊(duì)，進(jìn)行核心軟件開發(fā)。尤其目前智能化、網(wǎng)聯(lián)化和電動化的趨勢下，使大家最大程度的站在了同一起跑線下，因此整車廠想從之前的“組裝廠”模式開始研發(fā)和生產(chǎn)自己的軟硬件，并自己進(jìn)行產(chǎn)品的改進(jìn)和價值創(chuàng)造。因此在這種趨勢下，以前供應(yīng)商全包的模式將逐漸弱化，而是與OEM合作開發(fā)的模式，比如供應(yīng)商僅提供硬件，主機(jī)廠進(jìn)行軟件的開發(fā)。

 

首先需要承認(rèn)整車廠想把握主動權(quán)并進(jìn)行自身軟硬件能力的提升是正確的，而且軟件合作開發(fā)模式將成為以后的一種主流，但真正做好真的還任重道遠(yuǎn)，為啥呢？

跑在汽車上的軟件，第一要義就是穩(wěn)定可靠，而且在高震動，復(fù)雜電磁環(huán)境，大溫差的前提條件下，能保證百萬級的量產(chǎn)車不能出現(xiàn)嚴(yán)重軟件bug，每輛車數(shù)十甚至上百的控制器，要保證億數(shù)量級的產(chǎn)品穩(wěn)定，這還是基本盤。可以看下由于軟件bug造成的歷史著名事件，豐田剎車門，手機(jī)電腦可以死機(jī)，汽車別說死機(jī)，就是一個小小的位反轉(zhuǎn)，都有可能喪失生命，汽車電子軟件工程本身是復(fù)雜度和高可靠性要求集合。

汽車電子軟件開發(fā)發(fā)展到今天，已經(jīng)形成了完整的行業(yè)規(guī)范流程和功能安全等級驗(yàn)證，可以參考部分法律執(zhí)行，不僅要求結(jié)果正確，還要求程序正義。在這一行，可以說不僅要求開發(fā)出的軟件滿足所需功能和需求，以及功能安全網(wǎng)絡(luò)安全要求，還要滿足開發(fā)過程遵循 ASPICE ,有完整的過程文檔記錄和追溯，甚至?xí)?xì)化到開會評審的記錄文檔，如果有個別楞頭，就是說我們軟件很優(yōu)秀，管你這個流程那個要求，放車上跑就完事了。對于這種，被使用的資質(zhì)都沒有更不用說在量產(chǎn)車上用了。所以現(xiàn)階段汽車上跑的軟件，從源頭上就不存在個人小作坊開發(fā)，都是公司里正規(guī)軍團(tuán)隊(duì)經(jīng)歷很長時間才能完成。

四、汽車總線基于SOA的需求將逐漸采用以太網(wǎng)為主干網(wǎng)，多種總線共存的狀態(tài)

汽車上的總線技術(shù)包括：LIN、CAN、CAN FD、FlexRay、MOST及Ethernet。就目前汽車上的應(yīng)用情況，成本低、可靠性高、應(yīng)用普遍的有Lin、CAN通訊，CAN FD也是最近幾年才逐漸得到應(yīng)用，CAN FD是對傳統(tǒng)CAN總線的一種擴(kuò)展和過渡，其目的就是Make CAN Fast，首先其不會對原有的整車網(wǎng)絡(luò)帶來大的變更，具備很好的兼容性又具有可觀的傳輸速率。在開發(fā)遷移量、時間成本、硬件成本等方面的考慮下，CAN FD在當(dāng)前階段是很好的過渡方案。

但隨著汽車電子電器架構(gòu)復(fù)雜度的提升尤其當(dāng)前輔助駕駛系統(tǒng)、無人駕駛技術(shù)的快速發(fā)展，傳統(tǒng)的LIN、CAN總線已不堪重負(fù)且無法滿足未來高帶寬的要求，例如無人駕駛技術(shù)涉及攝像頭、激光雷達(dá)等傳感器及不同控制器之間大量數(shù)據(jù)的采集、傳輸和處理。當(dāng)同時考慮X-By-Wire應(yīng)用場景和更高的帶寬要求時，CAN FD可能也無法滿足，因此對于線控應(yīng)用場景，F(xiàn)lexRay是一種不錯的方案，因FlexRay是專為車內(nèi)局域網(wǎng)設(shè)計(jì)的一種具備故障容錯的高速可確定性車載總線系統(tǒng)，采用了基于時間觸發(fā)的機(jī)制且具有高帶寬、容錯性好等特點(diǎn)，在實(shí)時性、可靠性及靈活性方面都有很大的優(yōu)勢，非常適用于安全性要求較高的線控場合及帶寬要求高的場合。但FlexRay的應(yīng)用對OEM的能力要求相比CAN會提高很多，同時全部升級為FlexRay會帶來開發(fā)遷移量、時間成本、硬件成本等方面的同步提升（所有節(jié)點(diǎn)必須升級為FlexRay節(jié)點(diǎn)）。此外，就我個人觀點(diǎn)而言，F(xiàn)lexRay后續(xù)得到普遍應(yīng)用的可能性不是很大，首先成本方面與車載以太網(wǎng)差不多而通訊速率又遠(yuǎn)低于它，而車載Ethernet在未來得到推廣的可能性要比FlexRay高很多。需要注意的是CAN FD在市場推廣實(shí)施還沒有幾年，第三代CAN總線-CAN XL也即將登場，CAN XL傳輸速率將達(dá)到10Mbit/s，可填補(bǔ)CAN FD和百兆車載以太網(wǎng)（100BASE-T1）之間的鴻溝，從這點(diǎn)也可以看出車載通訊的快速發(fā)展及對通訊帶寬的越來越高的要求。

當(dāng)然所有總線的應(yīng)用都是分所在的域和場景的，例如對于安全要求很高的場合，采用了基于時間觸發(fā)機(jī)制的FlexRay因?qū)崟r性和確定性更高可能更合適，再比如在后續(xù)基于SOA的高帶寬數(shù)據(jù)傳輸應(yīng)用場景，車載以太網(wǎng)則更適合。而對于一些動力域控制器本來就可通過CAN滿足需求的何必花精力和額外的成本去用其他總線技術(shù)取代。因此相比說要取代，我認(rèn)為更應(yīng)該是并存，每種總線技術(shù)都有其存在的價值，在滿足要求的前提下，采用成本低、成熟的總線技術(shù)肯定是首選。

 

五、多核異構(gòu)處理器應(yīng)用將為主流

為什么需要多核處理器，我主要基于四點(diǎn)闡述下原因：

1、汽車電子電器架構(gòu)和整車功能越來越復(fù)雜，需要計(jì)算能力更強(qiáng)大的硬件來支持越來越復(fù)雜的軟件功能，隨著ADAS、自動駕駛等應(yīng)用場景的加入及未來域集中甚至中央計(jì)算機(jī)的E/E架構(gòu)變更，多核系統(tǒng)的需求將更加明顯。

2、并行計(jì)算的需求：例如某些功能的輸出計(jì)算需要多個輸入要素在相同時間片內(nèi)執(zhí)行并在同一時刻輸入到該功能模塊。

3、相同時間片內(nèi)多個任務(wù)的串行計(jì)算需求：例如多個功能需要在相同的時間內(nèi)被串行執(zhí)行。

4、系統(tǒng)響應(yīng)能力的需求：例如對于那些對時間要求特別高的中斷處理需要單獨(dú)在一個核上運(yùn)行，而周期性任務(wù)則放到另外一個核上運(yùn)行，從而提高整個系統(tǒng)的響應(yīng)能力。

當(dāng)然多核系統(tǒng)的軟件開發(fā)集成相比單核，在項(xiàng)目時間、復(fù)雜度、成本以及給攻城獅帶來的額外工作量都是成倍增加的。多核處理器的應(yīng)用也會帶來諸多挑戰(zhàn)，例如滿足ISO26262功能安全的挑戰(zhàn)、合理分配各核計(jì)算負(fù)載、多核系統(tǒng)數(shù)據(jù)一致性挑戰(zhàn)等等。

六、更加注重軟件架構(gòu)的設(shè)計(jì)

軟件架構(gòu)這部分，我們拋開一些閉源的諸如特斯拉的軟件，來談?wù)劥蠹移毡榻佑|的的Classic Autosar和Adaptive Autosar。我們整車上的控制器，分動力域的控制器，如發(fā)動機(jī)控制EMS、TCU等，還有信息娛樂域的控制器比如車機(jī)顯示燈，不同控制器的實(shí)時性要求等方面是不一樣的。例如發(fā)動機(jī)控制器ECU、或者整車控制器VCU實(shí)時性和功能安全要求要比與其他功能或信息娛樂性控制器高，動力域的基本基于Autosar經(jīng)典平臺開發(fā)，因其具有如下特點(diǎn)：

1、硬實(shí)時，可在us時間內(nèi)完成事件的實(shí)時處理，硬實(shí)時任務(wù)必須滿足最后期限的限制，以保證系統(tǒng)的可靠運(yùn)行。

2、高功能安全等級，其可達(dá)到ASIL-D的安全等級。

3、對CPU、RAM或Flash等資源具有較低的占用率。

4、軟件功能通常是固化不可動態(tài)變更的。

而信息娛樂性控制器，則正好與上相反，其一般會占用較大的硬件資源，且一般實(shí)時性要求相對低，因其一般運(yùn)行在嵌入式PC上，如LINUX，而不是汽車級操作系統(tǒng)上，所以其即使出現(xiàn)故障也不會造成嚴(yán)重的安全事故。而ApdativeAutosar則是連接這兩者的橋梁，其具有如下特點(diǎn)：

1、軟實(shí)時，具有毫秒級內(nèi)的最后期限，且偶爾錯過最后期限也不會造成災(zāi)難性后果。

2、具有一定的功能安全要求，可達(dá)到ASIL-B或更高。

3、與經(jīng)典平臺不同的是，它更適用于多核動態(tài)操作系統(tǒng)的高資源環(huán)境，如QNX。

Adaptive Autosar與Classic Autosar相比，雖實(shí)時性要求有所降低，但在保證一定功能安全等級的基礎(chǔ)上，大大提高了對高性能處理能力的支持，以支持智能互聯(lián)應(yīng)用功能的開發(fā)，因此C++將成為AdaptiveAutosar平臺的主要開發(fā)語言。

Adaptive Autosar的出現(xiàn)并不是為了取代ClassicAutosar平臺，而是針對不同的應(yīng)用場景實(shí)現(xiàn)兩者的共存和協(xié)作，Classic Autosar平臺支持高安全性和高實(shí)時性的應(yīng)用場景，因此對于深度嵌入式的軟件功能需部署運(yùn)行在經(jīng)典平臺上，而Adaptive Autosar則支持并行處理的需要高性能運(yùn)算的功能則需要運(yùn)行在Adaptive平臺上。

當(dāng)然在軟件架構(gòu)方面本來是多樣的，采用哪種就看主機(jī)廠如何考量和能力如何了，多軟件架構(gòu)，諸如Autosar、Adaptive Autosar、ROS等將會耦合集成。

七、標(biāo)準(zhǔn)和流程方面

為了滿足汽車軟件開發(fā)高質(zhì)量的標(biāo)準(zhǔn)，ASPICE 過程模型被建立，ASPICE是安全和保障的基礎(chǔ)，樓主相信這是未來保證軟件開發(fā)質(zhì)量的一個重要方面，不管是供應(yīng)商還是各大OEM都應(yīng)逐漸應(yīng)用起來。

ISO26262標(biāo)準(zhǔn)則在流程和方法論方面定義了系統(tǒng)開發(fā)中功能安全的影響，對于軟件架構(gòu)，功能安全是一個非常關(guān)鍵的因素，如何設(shè)計(jì)車內(nèi)系統(tǒng)使其能符合功能安全標(biāo)準(zhǔn)要求是一個巨大挑戰(zhàn)，特別是在日漸增加的應(yīng)用復(fù)雜性以及產(chǎn)品上市時間的緊迫性的雙重壓力之下。電子系統(tǒng)面臨的挑戰(zhàn)是構(gòu)建的系統(tǒng)需要能夠防止危險故障的發(fā)生或至少在出現(xiàn)故障時能夠有效地進(jìn)行控制。功能安全標(biāo)準(zhǔn)已應(yīng)用于車輛安全系統(tǒng)，如安全氣囊或 ADAS。ISO26262是從IEC61508標(biāo)準(zhǔn)派生而來，針對道路乘用車車輛內(nèi)的電氣/電子系統(tǒng)。該標(biāo)準(zhǔn)應(yīng)對架構(gòu)、功能和程序方面的問題，包括汽車安全生命周期，以避免并控制系統(tǒng)錯誤以及隨機(jī)硬件故障。ISO 26262指定了四個ASIL等級(A至D)以確定標(biāo)準(zhǔn)的必要要求以及用于避免不合理殘余風(fēng)險的安全措施，其中D表示最嚴(yán)格的安全等級，A表示最寬松的安全等級。通過考量任務(wù)數(shù)據(jù)中系統(tǒng)故障可能導(dǎo)致傷害的那部分(即出現(xiàn)概率)；駕駛員應(yīng)付系統(tǒng)故障并避免傷害的能力(即可控性)；以及可控性操作失敗會導(dǎo)致的人身后果(即嚴(yán)重程度) 這三點(diǎn)，進(jìn)行車輛層面的危險分析和風(fēng)險評估，確定適當(dāng)?shù)腁SIL等級。