四個必須避免的汽車功能安全錯誤
作者 : Poornima Jha & Vaibhav Anand，Embitel
在汽車生態系統中，一個利益相關者的疏忽也會影響其他利益相關者。同樣地，在從事安全攸關的專案時使用未受過ISO 26262標準訓練的資源也有其自身風險…
OEM和一線(Tier-1)供應商等汽車利益相關者必須將功能安全性(FuSa)視為其整個組織的實踐。這說起來容易做起來難，實施符合ISO 26262的FuSa帶來了一連串的挑戰。如果未能解決這些困難，則會導致專案管理錯誤，以至於延誤專案並增加成本。管理不善的情況可能與組織中整體缺乏安全意識或跨職能團隊之間的協調不佳有關。
在汽車生態系統中，一個利益相關者的疏忽也會影響到其他利益相關者。如果Tier-1供應商沒有大面積地進行危害分析，那麼未辨識到的危害以及涉及的風險可能充斥著整個架構設計。同樣地，在從事安全攸關的專案時使用未受過ISO 26262標準訓練的資源也有其自身風險。本文整理必須不惜一切代價加以避免的一連串此類FuSa管理錯誤。
組織缺乏安全意識
功能安全性並不僅限於從事安全攸關汽車專案的安全團隊。從開發人員到測試工程師與專案經理，團隊中的每個成員都必須瞭解ISO 26262標準及其指南。在組織中整體缺乏安全意識時可能犯哪些FuSa錯誤？
- 缺乏安全文化：安全文化在本質上意味著每個利益相關者在開發車用軟體或硬體時都要對功能安全嚴正以待。不忽視任何風險，關注安全生命週期的每個階段，資源相互協調並協同工作。僅僅擁有一名功能安全經理(顧問)而不專注於建立安全文化是組織最常犯的錯誤。
- 關注文檔而非安全：文檔是ISO 26262標準中重要的組成部份。這些文檔在OEM進行認證時可作為依據。然而，僅關注文檔而非實際的安全需求、目標和機制則會適得其反。
- 基於假設的ASIL規定：必須規避在沒有進行危害分析和風險評估(HARA)的情況下來確定汽車模組的汽車安全完整性等級(ASIL)值的這種常規做法。不建議基於業界規範ASIL的假設，因為這可能會有遺漏的風險。例如，資訊娛樂系統通常被認為是ASIL B。因此，許多資訊娛樂開發公司只是將ASIL B視為解決方案而不去執行HARA。如果資訊娛樂系統還包含可用於自動執行車輛中某些操作的攝影機資料又如何呢？這是一個嚴重的安全隱患，但由於業界假設而被忽略了。
圖1：HARA這個過程是ISO 26262指導架構和團隊理解功能安全和汽車功能的結晶。(圖片來源：Embitel)
破壞功能安全引發的安全監管不善事例
一些汽車供應商或技術供應商瞭解ISO 26262標準及其細節。然而，為了節約成本和縮短上市時間，往往會削弱某些安全攸關元件的功能安全。然而，這種忽視安全需求或偶發風險可能危及車內人員的生命。
- 低估整個專案的週期/工作量：一旦考慮安全性以及ISO 26262標準，工作量就會顯著增加，週期也會延長。一般來說，ASIL A意味著工作量增加10-15%，而對於符合ASIL D的專案，這一數字會上升到100%。在不考慮安全需求和目標的情況下低估這項工作，則是另一個需要避免的ISO 26262規範性錯誤。如果公司為了遵循預先設定的截止日期而壓縮到實施部份以及干預時，專案就會受到影響。
- 產品生命週期結束時考慮安全性：如前所述，ISO 26262解決方案的架構設計是基於軟體和安全需求而創建的。在開發符合ISO 26262標準的汽車解決方案時，必須從產品生命週期開始即遵循這項標準。由於以下因素，等到生命週期結束時或在第二次迭代中加入這些標準，業經證實是巨大的錯誤：
- 由於初始設計未包含安全方面，以至於設計重做的情況嚴重。
- 由於不符合ISO 26262標準，無法重用之前的程式碼。檢查先決條件、在發送/接收訊號的模組之間使用包裝器(wrapper)以及引入新模組，意味著可能需要編譯大量新的程式碼。
- 有時候，整個設計需要更改，而這可能會導致MCU平台發生變化。這意味著產品要從頭設計。
- 工具和工程技能投資不足：許多組織都認為擁有功能安全經理人就足以符合ISO 26262標準。然而，這是一種對安全持有麻木不仁的態度，而且這很可能是在使用符合標準的工具或者提高對應資源技能的情況下。建議訓練每個符合ISO 26262專案的相關資源，而且從開發人員和測試人員到專案經理，每個利益相關者對於ISO 26262標準的實作都必須抱持正確的態度。
圖2：功能安全不可事後考慮，特別是在汽車設計中是生命攸關的。(圖片來源：Embitel)
利益相關者之間協調不善導致FuSa管理不當
符合ISO 26262標準的專案所涉及資源來自不同團隊及其不同技能，包括開發人員、測試工程師、硬體專家、專案經理、功能安全經理等等。
- 團隊之間缺乏合作：為了完成各種安全活動需要組織內不同團隊之間的合作。例如，要執行硬體失效模式影響和診斷分析(FMEDA)，軟體團隊必須清楚地瞭解安全機制。但是有的時候，團隊並不瞭解這種合作的重要性。
- OEM和Tier 1之間的協作不利：在某些情況下，OEM無法在安全合規方面提供足夠的支援和準備。忽略了危害、未能正確執行安全分析等各種此類管理不善的情況接踵而至。另外，OEM沒有對Tier 1供應商的工具是否合規進行評估，也會對專案產生危害。
技術與管理錯誤的混合
由於缺乏預算或是缺乏常用的ISO 26262知識，都會超出專案管理的管控範疇，導致對技術的干擾：
- 安全攸關系統的標準設定得太低：當我們開始忽略危險並放寬驗收標準時，專案就會受到威脅。例如，模組中可能只有一個安全問題需要ASIL C的認證，但我們卻忽略它並堅持用ASIL B。這是組織所犯的嚴重錯誤。造成這種錯誤的主要原因還是因為增加成本。測試所有極端用例、執行額外的安全分析以及對工具授權的投資都會增加專案成本。測試時還存在燒毀電路板、LED和馬達的風險。當然，為了安全起見，還是需要檢查這些故障。
- 低估SOTIF和ASPICE等相關標準的重要性：除了功能安全之外，還有如ASPICE和Cybersecurity (ISO/SAE 21434)等針對專案需求的其他標準。所有這些標準都涉及編碼與測試的指導原則，因此其間可能會有很多重疊之處。在制定安全計畫時未考慮這些標準之間的相互關係，是最常見的錯誤。有的任務可以平行處理，甚至可以合併處理以節省時間。例如，ASPICE所推薦的軟體鑒定測試與ISO 26262所推薦的軟體整合測試和能力成熟度模型整合(CMMI)十分相似。原則上來說，它們都可用來檢測軟體的高階架構。因此，以同等標準來合併此類相似的流程可以節省大量時間和精力。在使用不同標準時，未考慮當前標準對另一個標準的影響，也是另一個常見的錯誤。
- 過度工程：並非每個汽車模組都對安全至關重要。只有在執行HARA時，才會知道其關鍵程度。當然，組織有時不希望執行所有安全活動，但為了安全起見，他們假定模組有更高的ASIL等級。這導致安全機制的實施甚至是不必要的。所以，必須避免此類做法以最佳化成本和上市時間。
ISO 26262是一個廣泛的標準，組織無法在短期內達到功能安全實踐的成熟度。但是，透過避免上述的錯誤，有助於組織加快這個過程。
(參考原文：Four automotive functional safety mistakes that must be avoided，by Poornima Jha & Vaibhav Anand)
從無線連接、更快的處理和運算、網路安全機制、更複雜的虛擬實境(VR)到人工智慧(AI)等技術，都將在未來的每一個嵌入式系統中發揮更關鍵功能。「嵌入式系統設計研討會」將全面涵蓋在電子產業最受熱議的「智慧」、「互連」、「安全」與「運算」等系統之相關硬體和軟體設計。
會中將邀請來自嵌入式設計相關領域的研究人員、代表廠商以及專家，透過專題演講、產品展示與互動交流，從元件、模組到系統，從概念設計到開發工具，深入介紹嵌入式系統設計領域的最新趨勢、創新和關注重點，並深入分享關於嵌入式系統設計的經驗、成果以及遇到的實際挑戰及其解決方案。
加入LINE@，最新消息一手掌握！
