今天的汽車行業面臨最大的挑戰之一，就是從過去基于硬件的車輛過渡到軟件定義汽車的時代。當軟件成為造車行業發展的主要領域，越來越多的OEM和零部件供應商逐步轉型為軟件公司。汽車也單純的從出行工具變成了移動的計算機，汽車的開發越來越像在四個輪子上去開發車載電腦。
隨著智能網聯汽車的快速發展，新技術不斷涌現，如可通過OTA技術遠程進行軟件更新升級或實現與個人數字設備的集成等等。這些智能網聯汽車上新技術的廣泛應用對整車的信息技術安全（或稱網絡安全）提出了額外的要求，典型的如ISO21434國際標準，道路車輛信息安全工程的關于網絡安全方面的專業標準，此標準也給工程應用實踐提供了一系列的解決方案。

當前大多數OEM 及零部件供應商遵循功能安全的開發過程，考慮基于ISO 26262功能安全和ISO21448的預期功能安全開發過程。結合新增的對網絡安全層面的需求，那又如何理解現有的功能安全標準和網絡安全標準的關系，各過程之間又應該如何協調呢？對于基于模型的開發(MBD)過程，尤其是當我們在利用MATLAB Simulink或者TargetLink的模型開發框架去構建我們的應用的時候怎樣才能保證相關項的功能安全的同時還能保障足夠的網絡安全，從而最終能確保我們所開發的軟件的質量？這是我們接下來要討論的內容。
先讓我們回憶一下相關安全相關的幾組重要標準，首先我們從宏觀的概念上去理解區分不同的安全概念。為了更方便地描述自動駕駛系統，ISO TR 4804:2020標準當中引入可信性的概念。可信性定義為系統提供服務或功能的能力，包括了可靠性、可用性、可維護性、功能安全性、網絡安全性等幾大特性（英文簡稱為RAMSS）。可信性術語涉及了所謂的可靠性、可用性、功能安全、網絡安全各方面的知識領域，涵蓋了典型汽車工程實踐中需要考慮的功能安全、預期功能安全、網絡安全等內容，最初定義了安全相關的一些功能的基本要求。功能安全標準ISO 26262旨在源于E/E系統與E/E系統的故障行為引起的危害進而導致的不合理風險；預期功能安全 ISO 21448討論的是不存在因預期功能的不足或者合由于合理可預見的人員誤操作而導致的不合理風險。功能安全和預期功能安全強調要防止因系統功能層面的故障不足或誤用導致的不合理風險。ISO 21434從網絡安全的角度去評估，側重于“故意地操縱”導致的危害，描述資產受到充分保護，道路車輛部件或者其功能部件、子部件功能免于威脅的狀況。系統安全相關功能當中的可用性也是一個相當重要的話題，ISO26262中涉及到相關部分內容。

圖1. 安全標準的可信域涵蓋

ISO 26262的標準在功能安全領域已經廣泛應用且為人熟知。針對潛在的功能不足和人為的誤用，又提出了一個補充的預期功能安全標準ISO 21448，不久前此標準又出了新版本。而針對信息或網絡安全規范，業內提出了網絡安全標準ISO SAE 21434。除了三大標準以外，對于自動駕駛車輛，主要利益相關方給出了一個綜合性的、特定領域的特定標準ISO 48 TR 4804。ISO 48 TR 4804是有關現有安全標準的一個補充，它的目的是實現積極的風險平衡，或者避免不合理風險或者網絡安全相關威脅，并給出了相應的建議指南和更具體的方法。當然相關內容更多的是一些技術性的闡述，強調安全設計的重要性，安全系統依賴于安全系統設計方法來保障。此外，標準也給出了一些關于自動駕駛系統的驗證和確認的方法。在ISO 48 TR 4804標準中引入可信性的概念，可信性定義為系統提供服務或功能的能力，包括可靠性、可用性、可維護性、功能安全性和網絡安全性（RAMSS）。

ISO 26262初版于2011年提出， 18年又進行了修訂，現在絕大部分公司開發都遵循該標準。預期功能安全標準最初提出于 2019 年，2022年更新發布了新版的功能安全標準。關于網絡安全標準ISO21434，它其實來源于SAE的J3061標準，于2016年提出《信息物理融合系統網絡安全指南》，后來被ISO采納轉化為ISO 21434的《道路車輛的網絡安全工程》標準，也是本文討論的網絡安全標準的主題內容。關于自動駕駛的ISO的標準，其實來源于更早的名為《自動駕駛系統：安全第一》白皮書，后被ISO納入ISO/TR 4804 的標準。標準日后還在更新，被采納為ISO/TS 5083的技術規范。功能安全、預期功能安全、網絡安全構成可信域的要件如圖 1。

那么不同的安全標準之間有怎樣的關聯？我們摘錄了兩句話來描述這種關系。第一句摘自Serpanos1教授的一篇文章，當中提到傳統上功能安全、網絡安全通常認為是不同的知識領域，由不同的專業人士來負責。但是我們觀察他們的特征并類比得出的結論是，他們實際上是相互依存的。特別功能安全其實是依賴于信息安全或者網絡安全的。或者可以說網絡安全是功能安全的保障，也就是說沒有網絡安全，就無法保證功能安全。另外一句摘錄，Aileen Ryan在《There is no safety without security》2一文中也強調網絡安全可被視為功能安全的保障，沒有網絡安全就沒有功能的安全。可能之前汽車行業從業者對網絡安全關注比較少，但是最近隨著智能網聯汽車的快速發展，網絡安全問題應對越來越重要。這就促使我們不僅要關注功能安全層面的問題，還需要更系統地關注網絡安全的問題。

圖2. 功能安全、網絡安全的概念視圖

接下來我們討論二者如何區分。這里我們提供一個更直觀的關于功能安全和網絡安全的概念視圖來幫助理解，如圖2。網絡安全強調保護我們的系統，無論是產品還是設備的數字型資產，免受外部威脅。當然這是對于我們中心的系統來說，其更廣義上涵蓋系統內部和外部的網絡安全。威脅則來源于人或外部環境。一個典型的例子是黑客試圖通過WIFI無線網絡連接汽車來操縱車內的ECU。而功能安全強調的是防止系統故障引起的危害導致的風險。功能安全意在保護人或者環境免受來自系統故障運行導致的傷害。典型例子比如高速行駛的車輛行進過程當中智能防抱死的系統ABS故障系統抱死失效引發危害造成對人的傷害。

為了容易理解，我們引入典型的例子來說明，汽車安全的研究人員發現，我們完全可以通過車載的電腦，以無線的方式來遠程控制汽車。曾經有這樣的實際發生的情況，研究人員可以通過通用汽車的OnStar，福特的Sync這樣的汽車工具訪問車載的計算機，通過車載電話的藍牙網絡連接到整個汽車網絡，甚至于控制汽車的剎車、門鎖、中控儀表等幾乎所有安全關鍵的系統。

所以我們汽車行業的從業人員希望能夠更系統地去研究開發網絡安全的汽車系統。歐洲在功能安全、網絡安全領域的研究項目EmbeddedSafeSec由柏林投資銀行和歐洲區域發展基金會資助，專門研究如何更好地實施功能安全和網絡安全的協同工程。下面我們分享一些網絡安全和功能安全協同工程的框架，以及協同工程的最佳實踐。

圖3. 功能安全生命周期(ISO 26262)

首先我們來看對于各自的功能安全標準或者信息里是如何去描述相應的生命周期的活動？對于功能安全來說，ISO 26262當中有相應的功能安全生命周期，這里我們傾向關注更多的是系統和軟件層面，如圖3（當然除此以外還存在同步的硬件開發生命周期，圖中沒有顯示出來）。虛線以上描述系統層面的一些活動，虛線以下描述軟件層面的活動，在系統層面，從危害分析風險評估開始，從功能安全的角度出發識別評估系統的潛在危害及相關風險，確定ASIL等級，得出相應的安全目標并作為頂層的安全需求。從功能安全概念推導具體的技術安全概念等一系列相應規范以及如何在硬件和軟件層面實現系統功能安全方面的需求。技術安全概念之后，繼續深入分解到下面軟件層面，指定軟件安全需求，進行軟件架構設計、軟件單元設計、軟件實現，然后過渡到對應左側的不同層次的測試驗證，即單元集成系統及整車層面的驗證，最后確認是否實現了最初的安全目標。如此構成一個典型的功能安全的產品開發生命周期。另外，后續還有相應的生產運維報廢等過程，組成全面的功能安全生命周期的迭代過程。

圖4. 網絡安全生命周期(ISO SAE 21434)

同樣ISO 21434標準中也提出了一種類似的網絡安全生命周期，如圖4，與功能安全生命周期極其類似。網絡安全生命周期從網絡安全目標開始，提出網絡安全的概念，進行相關項的產品開發，后續的生產運維、報廢等一個重復迭代的周期，最終實現預期的網絡安全水平。更具體地說，網絡安全的目標到網絡安全概念再到系統軟硬件的設計，如展示了一些通用的步驟，具體因為我們每個公司組織架構的不同，而甚至項目的不同而已。這里面提到了一些關于系統組件的設計，子組件部件的設計，不同層面的設計活動。子組件驗證系統驗證等，網絡安全產品開發的周期經過迭代不斷更新，甚至可以通過OTA技術，實現系統的無限的遠程更新和快速迭代，直到最終符合預期的網絡安全目標。

功能安全和網絡安全標準當中，其實也存在一些關于不同知識領域之間交叉引用的通用描述。如ISO 26262標準中提到，標準要求組織應在功能安全、網絡安全和其他與實現功能安全相關的知識領域之間建立并保持有效的溝通渠道。而在網絡安全標準ISO 21434中也提出：組織應確定與網絡安全相關或交互的領域，并建立和維護這些領域之間的溝通渠道，以確定網絡安全是否以及如何融入現有流程并協同相關信息的交流。協同包括在領域之間共享流程和策略工具的應用。關于具體的信息，詳情請參照相應的章節，還可以在備注當中看到具體對應章節的展開的信息。

同時在標準當中另外體現功能安全、網絡安全協同的信息：功能安全和網絡安全的開發過程之間的關系取決于項目的組織和范圍，因此沒有描述交互的方法或技術內容。可由組織確定最適合這種交互的方法。
所以功能安全網絡安全的協同考慮引入所謂的協同工程的概念，其思路即如何通盤地考慮功能安全和網絡安全及其相關的活動過程（圖5），比如哪些相關的系列活動能夠協同進行？哪些活動必須是分開進行？可并行的活動之間如何關聯？如何交互？對于不同過程之間的溝通，比如典型地關于產品開發階段軟件開發過程的一系列的過程交互，相應的功能安全生命周期與網絡安全生命周期的映射關系。

圖5. 功能安全和網絡安全活動的協同

協同工程當中對應安全生命周期的產品開發階段，尤其是軟件產品開發階段一系列的活動，遵循V型開發流程從需求到設計到實現及不同層面的驗證測試。功能安全和網絡安全標準當中都有相關的需求提及，具體到軟件單元集成和驗證子章節，如網絡安全標準ISO 21434中10.4.1章節提到關于產品開發設計階段需求規范，10.4.2章節當中涉及集成和驗證的規范。對應映射到功能安全標準當中的6.9章部分的軟件，如軟件單元驗證部分，如圖6。

圖6. 功能安全生命周期與網絡安全生命周期的活動集映射

比如我們在圖7中看到的是關于產品開發階段軟件開發過程的活動。相應功能安全生命周期的活動對應映射到網絡安全生命周期的產品開發階段的活動。如根據網絡安全的需求進行架構總體設計及細化設計，對應功能安全過程中的軟件產品開發階段，派生出具體的軟件開發需求（這里我們只關注軟件層面），進行軟件架構設計，實現及軟件單元和集成的驗證和軟件系統的測試。

圖7. 協同工程的軟件產品開發過程中的軟件單元驗證

協同工程根據關于相關項操作環境的現有信息，不同的現有的輸入信息進行單元和集成層面的驗證，最終會形成相應的軟件集成和驗證的規范。
協同工程在軟件單元驗證階段系列活動的目標在于：

1）提供軟件單元設計滿足分配的軟件需求以及網絡安全需求并適合實施的證據；

2）驗證從安全導向分析中得出的安全措施是否得到正確實施；

3）提供證據證明已實施的軟件單元符合單元設計規范，并滿足分配的軟件需求和相應的ASIL等級；

4）提供足夠的證據，證明軟件單元不包含非預期的功能或非預期的的功能安全和網絡安全屬性。

這里我們還著重要強調二者之間在項目當中的溝通協同活動包括了在知識領域之間共享的流程和使用的策略。關于開發驗證或者測試的種種策略在各標準中的要求描述中也是類似的，開發測試所用的工具共享可以最大限度的幫助我們高效實現我們的驗證目標。

圖8. 基于模型的設計V模式的開發迭代過程

在軟件開發當中，尤其是應用層軟件設計時，我們常用基于模型的設計（MBD）方法，比如我們會借助MATLAB Simulink/Stateflow或TargetLink建模工具實現功能建模。基于模型的設計遵循大家所熟知的V模式的開發迭代過程如圖8。建模過程主要包括根據軟件的需求，進行相應的行為建模，功能建模和實現建模，繼而從模型生成代碼。基于模型的設計方法的優勢之一是使后續V模型的右側的各層面的測試驗證工作可以前置到V模型的左側，因而后續對代碼的測試可以前置為對模型的測試過程，借助合規的代碼生成工具的支持，代碼層面的測試在某些情況下可等同于對應模型的測試。通過早期對模型軟件的測試，可盡早的發現軟件的缺陷，最大限度的保障軟件質量的安全。

同時在ISO 21434網絡安全的標準當中在開發階段當中也提到：適用于設計、建模或編程語言而本身未保障符合網絡安全需求的準則應由設計、建模和編碼指南或開發環境涵蓋3。例如對安全編碼的要求，應使用MISRA C或CERT C在“C”編程語言中進行安全編碼。這方面的網絡安全相關的屬性由相應的設計、建模或編碼的規范保證，如C代碼的安全性適用MISRA C和CERT C標準，保證編程語言的安全。
另外，適用于設計建模編程語言的指南如運用語言子集，執行強類型實現，使用防御性的實現的技術等，在MBD的早期開發階段保障編程語言符合對于網絡安全的要求。具體來講，比如對于強類型實現，假設我們用TargetLink建模工具去開發的應用程序如圖9，實現和的加和與飽和限制的運算。TargetLink對于所有整數運算，輸出數據類型和中間變量的指定值范圍必須足以避免溢出。在TargetLink模塊集中，原則上通過使用飽限模塊來避免溢出和下溢，通過使用具有足夠位長度的數據類型進行輸出和保存中間結果，避免整數算術中通過整數溢出飽和選項進行飽和約束。

圖9. TargetLink建模算術運算的強類型實現

再比如編碼規則CERT C中對于浮點類型數據的限制規則，不應使用對象表示方法比較浮點對象。用Simulink建模比較浮點數的等值性，圖10（左下）給出了一個具體形象的反例。在Simulink模型chart圖表定義數據類型double時，判斷邏輯當中給出比較相等的關系判定，是不允許的。建議的做法是給出相應的誤差，確保二者的誤差在相應的容差范圍之內，圖10（右下） 。

圖10. Simulink建模關于浮點型數據的比較

當然不管是對模型還是對于代碼的規則，怎樣去具體的在開發中進行正確的建模或編碼檢查，我們并不需要手動進行。比如我們可以借助建模檢查的高效工具，MES Model Examiner來實現模型對于特定建模規則的一致性。比如ISO 26262或者 ISO 21434中強調的建模編程設所適用的規則或指南，已經全面涵蓋在MES Model Examiner的規則庫當中。除此以外，MES Model Examiner還集成了功能安全及業界最佳實踐的規則規范，指導幫助工程師自動地檢查模型并修復模型錯誤。關于給定的安全規則執行檢查，MES Model Examiner可以給出模型違反具體規則的一致性報告結果，并可自動糾正違規模型，幫助建模人員更高效地執行靜態分析的各項規則檢查并生成獨立完整的報告，保障模型對安全性需求的可追溯性，最終符合功能的特定ASIL需求，并保障編程語言的網絡安全性。MES Model Examiner工具自動化分析并修正模型報告界面如圖11。

圖11. MES Model Examiner工具自動化分析并修正模型

沒有網絡安全，就沒有相應的功能安全。功能安全和網絡安全的協同工程需要全面全生命周期的協作和系統考慮。傳統意義上講，功能安全、網絡安全是由不同領域的專業人員從事的不同專業方向研究，也有著不同的專業內容，但在系統的安全層面上，他們又是相互協調統一的整體，應該通盤考慮。汽車知識領域功能安全的管理人員，同時也應協同考慮預期功能安全，網絡安全的需求，需要多方互相協調，在矛盾與統一中確定影響系統的主要矛盾與措施優先級，綜合全面考慮系統設計方案與安全措施，從而最大限度的保證系統的安全。