智能汽車操作系統安全性如何保障？

前言

汽車行業正在經歷一場翻天覆地的變革，從機械化到電子化、電動化，再到自動化、智能化，以及未來的云計算化、車路云協同化……智能網聯汽車時代已經拉開序幕，智能汽車的誕生推動汽車行業從硬件主導的傳統方式轉變為以軟件為中心的個性化模式。

汽車電子產業鏈也在發生巨變與重塑，面向部件的整體功能式供應鏈轉為硬件+平臺化軟件+定制化開發的聯合形態，急需構建圍繞主機廠和最終用戶需求的智能計算基礎平臺和產業鏈生態，智能汽車操作系統必將成為產業核心，推動和引領智能網聯汽車的發展。只有智能汽車操作系統才能支撐打造跨車型、應用定制，適配不同異構分布硬件的統一汽車智能駕駛產業化平臺合作模式，實現軟硬解耦、功能應用解耦、車型解耦的靈活開發模式，真正賦能主機廠的自主開發。

縱觀歷史，每一次科技變革，一定會帶來一場舊思想的顛覆和新思想的滲透與沖擊！對于汽車行業的巨變，隨之帶來的是新思想新理念新技術的融合與創新。

傳統車企多年沉淀的優勢在于強大的集成能力與規范且規模化的生產制造能力，傳統汽車行業零部件供應商具有良好的電子零部件開發及供貨能力，但是二者在大規模平臺化軟件開發方面經驗欠缺，缺乏較大型軟件規劃、架構、設計等方面的正向積累，所以傳統汽車行業的各路玩家是無法獨自撐起一個完整的智能網聯汽車時代，在這樣智能汽車取代傳統汽車的大時代背景下，融合車企規范性和ICT先進性的高科技平臺軟件公司必將登上歷史舞臺，作為中堅力量，向下實現跨車型跨硬件的擴展集成，向上賦能車企深入到軟件開發中，真正實現定制化應用軟件的自主開發。

由此誕生的智能計算基礎平臺、智能汽車操作系統，作為承上啟下的時代新產物，大家對它的認知還需要時間的沉淀，而我們作為智能計算基礎平臺，智能汽車操作系統最早的定義者和引領者，在行業內不斷的授人以漁，慢慢的讓行業各路資深玩家們開始覺醒，認同，并開始協同合力共創智能網聯汽車時代華章。

對于智能網聯汽車，安全是最為關注的話題。從功能安全ISO26262到預期功能安全ISO21448，標準只是提供最基本的方法論，而如何真正做到安全是需要每一個從業者深度思考、深入研究以及深刻實踐的。智能汽車操作系統作為支撐智能網聯汽車產業的核心產品，其安全可靠也是我們一直以來追求的目標，傳統的安全標準雖然按部就班的給出相應的開發指導，但是對于智能汽車操作系統而言，所需支持的應用場景復雜多變，AI 算法作為服務嵌入其中，功能邏輯復雜，代碼量巨大，大量開源代碼的使用，基于linux內核開發的廣泛應用……這些似乎都與傳統的功能安全背道而馳，新生的預期功能安全似乎也還處于一種混沌狀態，那么智能汽車操作系統安全性如何保障？

智能網聯汽車的安全是否有明天？在智能汽車操作系統功能安全上，我們就好像是“孤身走暗巷”的孤勇者一樣，雖然對峙絕望但也算一路披荊斬棘，摸索開拓出一條屬于智能汽車操作系統功能安全的正確之路，也希望能把這些經驗與理念傳播給行業內為了確保安全而奮力作戰的同行者們，大家共同真正推動落實智能汽車操作系統的安全可靠性。

智能汽車操作系統的安全入場券

智能汽車操作系統的安全性如何保障？毋庸置疑，一定是先站在巨人的肩膀上，標準是行業智慧的體現，是經過時間見證的優秀方法論，標準不一定是最好最先進的，但一定是最基礎的理論，所以對于智能汽車操作系統的安全之路第一步一定是先買入場券，我們在公司范圍內建立安全體系，在基礎質量體系基礎上建設穩固的ASPICE體系、再在此基礎上融合功能安全體系和預期功能安全體系，萬丈高樓一定需要堅實的地基與框架。

在汽車行業里，很多人對于功能安全和預期功能安全的理解只停留在標準層面上，因此會有很多誤解，認為它側重在文檔功夫上，甚至有些人認為它很雞肋，但很多時候都是無知者無畏。真正的功能安全與預期功能安全一定是和技術融為一體，在開發過程中自然而然能夠考慮到，也會自然而然去解決。文檔作為一種載體和體現形式，雖然不是產品能夠設計好的充分條件，但是一定是產品卓越的必要條件。

傳統功能安全聚焦于電子電氣設備的失效，對于硬件有形產品，硬件固有屬性隨著時間的推移會產生隨機失效，例如一個電阻元器件可能隨機產生開路、短路、阻值漂移等隨機失效模式，如果它在一個電路中處于很關鍵的角色，那么它的失效可能帶來整個電路、模塊或設備、的失效，如果這個產品又是一個安全相關產品，它的失效就可能導致人身傷害的危險事故。

而對于軟件這種無形產品，軟件人員能力差異，開發過程的疏忽，所使用的工具的準確度偏差都會影響最終軟件的質量，這些不可量化的失效統稱為系統性失效，系統性失效無法完全消除且一旦運行環境或條件達到相應觸發臨界點時，便一定會發生，同樣，對于安全相關軟件，系統性失效可能導致人身傷害的事故發生。因此功能安全的終極使命便是降低隨機性失效和系統性失效，把一切風險控制在可接受的范圍。

ISO26262基于對抗這兩種失效給我們提供了一套最基礎的方法論。總體概括，它包括兩部分內容：功能安全技術和功能安全管理。功能安全技術包括逐層細化的功能安全分析，架構層面的功能安全方案設計，硬件的安全架構設計、失效探測、診斷措施、隨機失效的度量與定量計算，軟件的安全架構設計、故障檢測與故障處理機制，各層級測試技術的充分運用。功能安全管理包括安全文化的建立、功能安全認可、功能安全審核、功能安全評估、配置管理、質量管理、變更管理、驗證管理等內容。

同時ISO26262給我們提供了兩種開發思路：一種是自上而下的開發，從概念階段的HARA分析到功能安全概念FSC，到系統階段的技術安全概念TSC，再到軟硬件層面的安全需求、設計與測試，一切基于相關項定義進行分析與分解。另一種是自下而上的開發，也就是SEooC開發（脫離上下文環境的安全要素開發），我們選定要開發范圍后假設它的上一層需求，以便推導出它的安全需求，然后進行相應的分析、設計和測試等一系列的活動，當它工程化實踐落到實際應用場景中時，假設條件與實際條件進行相應的匹配與偏差分析。這兩種開發思路的區別在于，第一種思路就是根據客戶的需求進行定制；第二種思路是正向開發產品進行客戶營銷。

對于智能汽車操作系統，顯然SEooC的開發方式更符合它的基因，而功能安全技術和功能安全管理是缺一不可的。

隨著智能網聯汽車的發展，面對復雜的應用場景，人們開始意識到事故的發生不僅僅來源于電子電氣的失效，也有可能是功能不全、性能不足以及人的誤操作。但早在傳統功能安全誕生時，專家們就武斷的給功能安全下了一個“針對電子電氣失效”的緊箍咒，因此這些新型可能導致危害的情況衍生了一個功能安全的孿生體——預期功能安全。

ISO21448在這種混沌的狀態下誕生，立足對自動駕駛安全影響廣泛的非故障安全領域，重點關注智能汽車的行為安全，解決因自身設計不足或性能局限在遇到一定的觸發條件（如環境干擾或人員誤用）時導致的整車行為危害。

ISO21448預期功能安全方法論總體概括也可分為兩部分內容：一是功能設計、分析與優化；二是場景的驗證與確認。前者包括功能規范設計、分析系統功能、危害識別與風險評估、改進系統設計進行功能優化；后者包括已知危險場景的評估和未知危險場景的評估。
?

在ISO21448標準中，從安全性和已知性角度，將車輛行駛場景劃分為4類：

?????? 已知安全場景（區域1）

?????? 已知危險場景（區域2）

?????? 未知危險場景（區域3）

?????? 未知安全場景（區域4）

對于已知危險場景2，基于現有用例可以明確評估，通過SOTIF分析方法保證這類場景的殘余風險足夠低。基本思想是通過危害分析識別出風險場景，針對風險場景開發對應策略，再對已知場景搭建仿真環境或實車環境進行測試驗證，根據實驗結果優化系統設計，例如進行功能改進或限制功能使用，從而將相應的危險場景轉移至區域1安全場景。

對于未知危險場景3， SOTIF基于危害分析、開放道路測試、隨機輸入測試等，發現系統設計不足，并將能檢測到的危險場景轉移到區域2當中。區域3的場景和相應用例可以通過行業最佳實踐或者其他方法制定。最終基于統計數據和測試結果，間接證明區域3的殘余風險可接受。

預期功能安全最終目標為評估系統在已知危險場景（區域 2）和未知危險場景（區域3）的殘余風險控制在合理可接受范圍。

智能汽車操作系統作為智能網聯汽車的共性基礎軟件，所需要支持L2到L4不同的自動駕駛應用功能，因此預期功能安全的考慮也是必不可少。

無論是ISO26262功能安全標準還是ISO21448預期功能安全標準，它們只提供了最基礎的方法論，而距離工程化實踐還有很大的距離，按照標準開展相應活動也不過僅僅是智能汽車操作系統功能安全路上的一張入場券而已，后面任重而道遠。

2020年，我們基于智能汽車操作系統的平臺化特性，摸索確定其功能安全目標，由于智能汽車操作系統后續支持的服務及應用廣泛，可能涵蓋多種場景和自動駕駛等級，在不同的自動駕駛等級下，對智能汽車操作系統可能有不同的功能安全要求，所以最終確定按照ISO26262標準最高功能安全等級ASILD的要求對其進行流程體系構建與落地，全面建立功能安全開發流程、文檔模板、檢查單和各種功能安全活動指導手冊。并在同年加入CAICV中國智能網聯汽車產業創新聯盟的預期功能安全工作組，對預期功能安全相關技術開展研究與評價。2021年初順利通過ISO26262-2018標準流程體系認證，標志著我們在智能計算基礎平臺、智能汽車操作系統的安全之路上邁出了重要的第一步。

在智能汽車操作系統ICVOS產品開發過程中，我們也進行了很長時間功能安全開發模式的探索，前期采用自上而下的開發模式，從應用功能角度出發，以HWA和AEB功能為例，進行HARA分析，識別功能安全需求，基于架構分解技術安全需求，再進一步分解……在這個過程中，我們發現這種方式對于智能汽車操作系統的功能安全有兩個弊端：一是對于基礎平臺化軟件，需要支撐各種不同的應用及服務，安全需求如果來源于單純一種或幾種應用及服務并不全面，且這種方式分解出來的特定應用相關需求較多，而基礎平臺軟件安全需求不足；二是這種分解到智能汽車操作系統層面的安全需求顆粒度不夠細化。

因此轉為自下而上的SEooC的分析，從智能汽車操作系統的feature定義入手，進行假設分析，并進一步分解安全需求，這種方式更加聚焦共性基礎軟件的功能安全細節要求，實踐證明這種方式更加適用于智能汽車操作系統的功能安全開發。而從應用角度啟動的自上而下的分析與分解可以作為一種輔助形式，用來作為功能安全需求查缺補漏的驗證。

智能汽車操作系統的安全挑戰探索

智能汽車操作系統作為智能網聯汽車時代的新產品，ISO26262功能安全標準無法覆蓋它的安全性，即使是ISO21448預期功能安全的加持，也不能完全承載它所面對的安全挑戰。

首先，智能汽車操作系統作為一個基礎平臺軟件，需要支持L2到L4級自動駕駛應用，各種應用面臨不同的使用場景，多種場景因素組合又會衍生無窮的新場景；新場景帶來不可預知的功能、性能的局限性以及特定場景可能觸發的失效情況，從而引發安全問題。

而軟件本身的屬性只能對有限的場景或特征輸入進行處理，這就要求對海量的場景進行抽絲剝繭，提取各種場景下共性的、與安全相關的特征進行分析，并最終分配至安全要素，而要完成對安全分析結果正確性驗證則需要對海量場景進行測試，此過程的難度和工作量無疑是巨大的，需要靈活的軟件架構、強大的自動化測試系統做支撐。

并且汽車行業里很多標準來源于國際標準，或由國際標準轉化的國家標準，而智能網聯汽車安全與場景強相關，因此也具有一定的地域性，國外的標準理論固然可以借鑒，但是并不能真正徹底指導和解決中國的自動駕駛問題，中國特色的標準還在構建與規劃中，還有待進一步完善。

智能汽車操作系統的軟件規模也是空前龐大，隨著整車電子電氣架構從分布式向集中式的演變，智能計算基礎平臺承擔越來越多原來單個ECU的功能，因此智能汽車操作系統軟件代碼量巨大，邏輯異常復雜，由此帶來很多不確定性因素，系統性失效率可能隨著代碼量的增加而倍增，因為繁瑣的流程和效率在一定程度上會存在沖突，大規模軟件的安全性可靠性魯棒性必然面臨巨大挑戰。

智能汽車操作系統中可包含算子庫，對于AI算法，AI模型屬性上存在一定的模糊性，參數在不斷變化，沒有固定的標準去評估下一次計算結果正確性，也就沒有了功能安全上所謂的診斷依據。神經網絡的不確定性與錯誤率是不可避免的，訓練數據無法確保其完整性與全面覆蓋，實際運行時數據與原始訓練數據也會存在分布偏差，訓練環境與實際運行環境可能存在差異，都可能導致輸出結果偏差，這些問題無法通過功能安全方法論解決，也無法完全靠預期功能安全理論方法就能完美消除。

智能汽車操作系統底層采用linux內核，并且內部含有第三方的庫函數和一些開源代碼，從傳統功能安全的角度，這些都是標準要求所不能接受的，而linux系統本身與智能汽車操作系統特性又高度契合，作為開源操作系統，Linux統治了服務器端75%的市場，在多年的使用、更新迭代的過程中，Linux自身具備了強大的、適應服務軟件的穩定性、可靠性和安全性，同理，開源代碼一般都是經過不斷迭代，千錘百煉沉淀下來的行業智慧，很多時候自研代碼性能未必優于開源代碼。這些矛盾，就好像是一邊是心之所向，一邊是道德倫理；又好像一邊是理想主義，一邊是現實所趨，那么智能汽車操作系統如何面對這些挑戰，解決這些矛盾呢。

我們在2021年到2022年的項目實踐與探索中，逐漸意識到這些挑戰，也逐步開始認知這些挑戰背后的本質，對新生事物與理念首先是抱著一種接受的態度而不是本能的拒絕，放下安全相關標準的條條框框，用第一性原理去看待分析每一個問題，也從第一性原理去解決每一個安全問題。智能汽車操作系統作為功能安全路上的孤勇者，誰說站在光里的才是英雄，誰說只有照搬標準才算安全？！

智能汽車操作系統安全的落地化實踐

在經過長達一年多的實踐與探索中，我們終于對智能汽車操作系統安全實現了落地化。“世上本沒有路，走的人多了，也便成了路。”對于智能汽車操作系統的安全，我們的策略是繼承與創新。既繼承功能安全標準與實踐中的優良經驗，也允許在本質趨向安全、風險可控的范圍內接受一定的創新。

首先，我們定位智能汽車操作系統的安全目標的安全完整性等級，毋庸置疑，無論是其中的功能軟件還是系統軟件，一定要以ASILD為目標去實現，才能承載智能汽車操作系統跨車型跨平臺跨自動駕駛等級的歷史使命。

智能汽車操作系統中系統軟件是基礎，功能軟件是核心，而功能軟件的重中之重則是數據流，負責節點的部署、調度與編排。系統軟件其實相對成熟，操作系統內核與中間件都有比較成熟的框架和協議，也有大量的應用實踐數據可以參考借鑒。而功能軟件相對較新，它能更好的支持SOA架構，是軟件定義汽車時代的重要產物，所以我們的安全策略是以數據流為中心，將功能軟件作為重要的核心內容徹底安全化。因此我們將功能軟件進行全面的功能安全產品認證，并且在基礎服務中添加全面的安全機制可供應用及服務自由使用。

通過建立平臺化的安全監控框架實現故障監測與故障處理的解耦，通過全面的安全分析識別安全監控所需提供的安全措施，實現以下內容：

?故障碼設計

?異常檢測對象管理

?異常處理對象管理

?異常監測

?異常處理

?異常發布

?異常訂閱

?異常信息查詢

?系統資源監控

?冗余-類鎖步核-比較器

?檢查點服務

?心跳服務

?安全動態加載/運行/卸載

我們通過功能安全技術全面構建安全的環境模型服務，保障安全的接收環境數據并分類存儲；安全的數據抽象，確保上行和下行數據進行安全的抽象轉換與收發；安全的數據流，確保所承載節點及算法的啟動、加載、部署、調度、編排、運行、退出的安全性，為智能汽車操作系統的功能安全提供全面保障。

針對智能汽車操作系統所面對超出功能安全標準范疇的那些安全挑戰，我們從第一性原理出發挖掘問題的本質，同時也從第一性原理出發，找尋解決辦法。這是一條真正的孤勇者之路，需要探索的勇氣，需要選擇性繼承的智慧，更需要沖破枷鎖的創新。

在智能汽車操作系統的系統軟件內核選擇上，Linux無疑是當前最優選擇，如果僅僅因為其無法確定滿足功能安全標準而棄之不用未免有點太武斷。如果要把一個Linux系統完全轉化為滿足功能安全標準的內核，所花費的成本據不完全統計也是一個天文數字，而借鑒功能安全“ALARP”原則，所花費的成本超過其轉化所帶來的受益程度，那么轉化這件事本身在功能安全理論上也是不支持的，所以由此看來，對于Linux我們不能一味的反對或盲目的接受，而是尋求最優性價比。

因此，我們在對待Linux的態度是“取其精華、去其糟粕”，選取關鍵內容進行充分功能安全分析、驗證與確認，針對安全相關的特定功能對其進行自上而下的實時性和安全性評估，充分利用其自身的安全機制，同時不斷為其添加新的安全機制作為現階段可落地的安全措施。

同理，針對開源代碼和第三方庫函數的使用，也采用此策略，并且實踐是檢驗真理的標準，實踐數據表明集眾人智慧的開源軟件代碼的可靠性往往高于新開發的代碼，所以是默守陳規堅持所有代碼重新按照功能安全標準重新編寫驗證還是根據實際情況評估，選取關鍵且薄弱的部分進行優化更加實際，在我們看來更支持后者，但這不代表我們對標準的漠視，也不代表這樣做工作量會少，而是更加說明對功能安全的深刻理解，從真正的需求與目標出發，不拘泥于形式，只忠于安全本質。

對于自動駕駛復雜多變的場景，數據驅動一定是重點突破口。我們不斷構建場景庫、事故庫，并建立隨機泛化，不斷積累經驗數據。同時，我們也在同步嘗試開展預期功能安全的危害分析與風險評估，不斷的將未知的危險場景轉化為已知危險場景，將已知危險場景轉化為安全場景。在測試方式方法上繼承功能安全、預期功能安全中測試、驗證與確認的相關經驗，借鑒等價類邊界值的用例選取思想，充分進行仿真驗證，HIL臺架驗證及真正的實車測試，并在SIL環境下建立全面的自動化測試機制，注重Corner case的建立、積累與充分測試。

建立中國化標準法規，才能真正適用于本土智能網聯汽車及智能汽車操作系統。我們牽頭和參與了多項智能網聯汽車國標、團標的撰寫工作，對智能網聯汽車產業化落地實施有深刻的理解感悟和十足的信心。

在算法安全性方面，我們目前已對數十萬張圖片進行精確標注用于算法訓練，同時繼承功能安全標準中軟件功能安全開發要求，最大限度的爭取讓算法設計增加可解釋性，并最大限度的爭取降低系統性失效影響。功能安全開發過程中，也對算法的輸入輸出增加檢測機制，確保在輸入輸出端實現故障安全策略，并且在我們的安全機制中可提供軟件冗余機制，在應用及服務需要時實現冗余策略。

對于智能汽車操作系統這種大規模軟件產品開發，我們秉承功能安全高內聚、低耦合的設計要求，采用模塊化設計、軟硬解耦、模塊間解耦的方式進行安全軟件開發，融合繼承傳統車企規范性和ICT行業高效性，創建高效融合的開發流程體系。巨大的代碼量會帶來BUG概率的增加，但我們努力用規范高效的流程來降低BUG發生概率，讓二者處于一個平衡。并在軟件開發過程中，采用系統工程思維，權衡系統安全性、可靠性、可用性、可維護性。
?