芯耀
1304
今天的汽車行業(yè)面臨最大的挑戰(zhàn)之一，就是從過去基于硬件的車輛過渡到軟件定義汽車的時代。當軟件成為造車行業(yè)發(fā)展的主要領(lǐng)域，越來越多的OEM和零部件供應商逐步轉(zhuǎn)型為軟件公司。汽車也單純的從出行工具變成了移動的計算機，汽車的開發(fā)越來越像在四個輪子上去開發(fā)車載電腦。
隨著智能網(wǎng)聯(lián)汽車的快速發(fā)展，新技術(shù)不斷涌現(xiàn)，如可通過OTA技術(shù)遠程進行軟件更新升級或?qū)崿F(xiàn)與個人數(shù)字設(shè)備的集成等等。這些智能網(wǎng)聯(lián)汽車上新技術(shù)的廣泛應用對整車的信息技術(shù)安全（或稱網(wǎng)絡安全）提出了額外的要求，典型的如ISO21434國際標準，道路車輛信息安全工程的關(guān)于網(wǎng)絡安全方面的專業(yè)標準，此標準也給工程應用實踐提供了一系列的解決方案。
當前大多數(shù)OEM 及零部件供應商遵循功能安全的開發(fā)過程，考慮基于ISO 26262功能安全和ISO21448的預期功能安全開發(fā)過程。結(jié)合新增的對網(wǎng)絡安全層面的需求，那又如何理解現(xiàn)有的功能安全標準和網(wǎng)絡安全標準的關(guān)系，各過程之間又應該如何協(xié)調(diào)呢？對于基于模型的開發(fā)(MBD)過程，尤其是當我們在利用MATLAB Simulink或者TargetLink的模型開發(fā)框架去構(gòu)建我們的應用的時候怎樣才能保證相關(guān)項的功能安全的同時還能保障足夠的網(wǎng)絡安全，從而最終能確保我們所開發(fā)的軟件的質(zhì)量？這是我們接下來要討論的內(nèi)容。
先讓我們回憶一下相關(guān)安全相關(guān)的幾組重要標準，首先我們從宏觀的概念上去理解區(qū)分不同的安全概念。為了更方便地描述自動駕駛系統(tǒng)，ISO TR 4804:2020標準當中引入可信性的概念?？尚判远x為系統(tǒng)提供服務或功能的能力，包括了可靠性、可用性、可維護性、功能安全性、網(wǎng)絡安全性等幾大特性（英文簡稱為RAMSS）。可信性術(shù)語涉及了所謂的可靠性、可用性、功能安全、網(wǎng)絡安全各方面的知識領(lǐng)域，涵蓋了典型汽車工程實踐中需要考慮的功能安全、預期功能安全、網(wǎng)絡安全等內(nèi)容，最初定義了安全相關(guān)的一些功能的基本要求。功能安全標準ISO 26262旨在源于E/E系統(tǒng)與E/E系統(tǒng)的故障行為引起的危害進而導致的不合理風險；預期功能安全 ISO 21448討論的是不存在因預期功能的不足或者合由于合理可預見的人員誤操作而導致的不合理風險。功能安全和預期功能安全強調(diào)要防止因系統(tǒng)功能層面的故障不足或誤用導致的不合理風險。ISO 21434從網(wǎng)絡安全的角度去評估，側(cè)重于“故意地操縱”導致的危害，描述資產(chǎn)受到充分保護，道路車輛部件或者其功能部件、子部件功能免于威脅的狀況。系統(tǒng)安全相關(guān)功能當中的可用性也是一個相當重要的話題，ISO26262中涉及到相關(guān)部分內(nèi)容。
ISO 26262的標準在功能安全領(lǐng)域已經(jīng)廣泛應用且為人熟知。針對潛在的功能不足和人為的誤用，又提出了一個補充的預期功能安全標準ISO 21448，不久前此標準又出了新版本。而針對信息或網(wǎng)絡安全規(guī)范，業(yè)內(nèi)提出了網(wǎng)絡安全標準ISO SAE 21434。除了三大標準以外，對于自動駕駛車輛，主要利益相關(guān)方給出了一個綜合性的、特定領(lǐng)域的特定標準ISO 48 TR 4804。ISO 48 TR 4804是有關(guān)現(xiàn)有安全標準的一個補充，它的目的是實現(xiàn)積極的風險平衡，或者避免不合理風險或者網(wǎng)絡安全相關(guān)威脅，并給出了相應的建議指南和更具體的方法。當然相關(guān)內(nèi)容更多的是一些技術(shù)性的闡述，強調(diào)安全設(shè)計的重要性，安全系統(tǒng)依賴于安全系統(tǒng)設(shè)計方法來保障。此外，標準也給出了一些關(guān)于自動駕駛系統(tǒng)的驗證和確認的方法。在ISO 48 TR 4804標準中引入可信性的概念，可信性定義為系統(tǒng)提供服務或功能的能力，包括可靠性、可用性、可維護性、功能安全性和網(wǎng)絡安全性（RAMSS）。
ISO 26262初版于2011年提出， 18年又進行了修訂，現(xiàn)在絕大部分公司開發(fā)都遵循該標準。預期功能安全標準最初提出于 2019 年，2022年更新發(fā)布了新版的功能安全標準。關(guān)于網(wǎng)絡安全標準ISO21434，它其實來源于SAE的J3061標準，于2016年提出《信息物理融合系統(tǒng)網(wǎng)絡安全指南》，后來被ISO采納轉(zhuǎn)化為ISO 21434的《道路車輛的網(wǎng)絡安全工程》標準，也是本文討論的網(wǎng)絡安全標準的主題內(nèi)容。關(guān)于自動駕駛的ISO的標準，其實來源于更早的名為《自動駕駛系統(tǒng)：安全第一》白皮書，后被ISO納入ISO/TR 4804 的標準。標準日后還在更新，被采納為ISO/TS 5083的技術(shù)規(guī)范。功能安全、預期功能安全、網(wǎng)絡安全構(gòu)成可信域的要件如圖 1。
那么不同的安全標準之間有怎樣的關(guān)聯(lián)？我們摘錄了兩句話來描述這種關(guān)系。第一句摘自Serpanos1教授的一篇文章，當中提到傳統(tǒng)上功能安全、網(wǎng)絡安全通常認為是不同的知識領(lǐng)域，由不同的專業(yè)人士來負責。但是我們觀察他們的特征并類比得出的結(jié)論是，他們實際上是相互依存的。特別功能安全其實是依賴于信息安全或者網(wǎng)絡安全的?；蛘呖梢哉f網(wǎng)絡安全是功能安全的保障，也就是說沒有網(wǎng)絡安全，就無法保證功能安全。另外一句摘錄，Aileen Ryan在《There is no safety without security》2一文中也強調(diào)網(wǎng)絡安全可被視為功能安全的保障，沒有網(wǎng)絡安全就沒有功能的安全?？赡苤捌囆袠I(yè)從業(yè)者對網(wǎng)絡安全關(guān)注比較少，但是最近隨著智能網(wǎng)聯(lián)汽車的快速發(fā)展，網(wǎng)絡安全問題應對越來越重要。這就促使我們不僅要關(guān)注功能安全層面的問題，還需要更系統(tǒng)地關(guān)注網(wǎng)絡安全的問題。
接下來我們討論二者如何區(qū)分。這里我們提供一個更直觀的關(guān)于功能安全和網(wǎng)絡安全的概念視圖來幫助理解，如圖2。網(wǎng)絡安全強調(diào)保護我們的系統(tǒng)，無論是產(chǎn)品還是設(shè)備的數(shù)字型資產(chǎn)，免受外部威脅。當然這是對于我們中心的系統(tǒng)來說，其更廣義上涵蓋系統(tǒng)內(nèi)部和外部的網(wǎng)絡安全。威脅則來源于人或外部環(huán)境。一個典型的例子是黑客試圖通過WIFI無線網(wǎng)絡連接汽車來操縱車內(nèi)的ECU。而功能安全強調(diào)的是防止系統(tǒng)故障引起的危害導致的風險。功能安全意在保護人或者環(huán)境免受來自系統(tǒng)故障運行導致的傷害。典型例子比如高速行駛的車輛行進過程當中智能防抱死的系統(tǒng)ABS故障系統(tǒng)抱死失效引發(fā)危害造成對人的傷害。
為了容易理解，我們引入典型的例子來說明，汽車安全的研究人員發(fā)現(xiàn)，我們完全可以通過車載的電腦，以無線的方式來遠程控制汽車。曾經(jīng)有這樣的實際發(fā)生的情況，研究人員可以通過通用汽車的OnStar，福特的Sync這樣的汽車工具訪問車載的計算機，通過車載電話的藍牙網(wǎng)絡連接到整個汽車網(wǎng)絡，甚至于控制汽車的剎車、門鎖、中控儀表等幾乎所有安全關(guān)鍵的系統(tǒng)。
所以我們汽車行業(yè)的從業(yè)人員希望能夠更系統(tǒng)地去研究開發(fā)網(wǎng)絡安全的汽車系統(tǒng)。歐洲在功能安全、網(wǎng)絡安全領(lǐng)域的研究項目EmbeddedSafeSec由柏林投資銀行和歐洲區(qū)域發(fā)展基金會資助，專門研究如何更好地實施功能安全和網(wǎng)絡安全的協(xié)同工程。下面我們分享一些網(wǎng)絡安全和功能安全協(xié)同工程的框架，以及協(xié)同工程的最佳實踐。
首先我們來看對于各自的功能安全標準或者信息里是如何去描述相應的生命周期的活動？對于功能安全來說，ISO 26262當中有相應的功能安全生命周期，這里我們傾向關(guān)注更多的是系統(tǒng)和軟件層面，如圖3（當然除此以外還存在同步的硬件開發(fā)生命周期，圖中沒有顯示出來）。虛線以上描述系統(tǒng)層面的一些活動，虛線以下描述軟件層面的活動，在系統(tǒng)層面，從危害分析風險評估開始，從功能安全的角度出發(fā)識別評估系統(tǒng)的潛在危害及相關(guān)風險，確定ASIL等級，得出相應的安全目標并作為頂層的安全需求。從功能安全概念推導具體的技術(shù)安全概念等一系列相應規(guī)范以及如何在硬件和軟件層面實現(xiàn)系統(tǒng)功能安全方面的需求。技術(shù)安全概念之后，繼續(xù)深入分解到下面軟件層面，指定軟件安全需求，進行軟件架構(gòu)設(shè)計、軟件單元設(shè)計、軟件實現(xiàn)，然后過渡到對應左側(cè)的不同層次的測試驗證，即單元集成系統(tǒng)及整車層面的驗證，最后確認是否實現(xiàn)了最初的安全目標。如此構(gòu)成一個典型的功能安全的產(chǎn)品開發(fā)生命周期。另外，后續(xù)還有相應的生產(chǎn)運維報廢等過程，組成全面的功能安全生命周期的迭代過程。
同樣ISO 21434標準中也提出了一種類似的網(wǎng)絡安全生命周期，如圖4，與功能安全生命周期極其類似。網(wǎng)絡安全生命周期從網(wǎng)絡安全目標開始，提出網(wǎng)絡安全的概念，進行相關(guān)項的產(chǎn)品開發(fā)，后續(xù)的生產(chǎn)運維、報廢等一個重復迭代的周期，最終實現(xiàn)預期的網(wǎng)絡安全水平。更具體地說，網(wǎng)絡安全的目標到網(wǎng)絡安全概念再到系統(tǒng)軟硬件的設(shè)計，如展示了一些通用的步驟，具體因為我們每個公司組織架構(gòu)的不同，而甚至項目的不同而已。這里面提到了一些關(guān)于系統(tǒng)組件的設(shè)計，子組件部件的設(shè)計，不同層面的設(shè)計活動。子組件驗證系統(tǒng)驗證等，網(wǎng)絡安全產(chǎn)品開發(fā)的周期經(jīng)過迭代不斷更新，甚至可以通過OTA技術(shù)，實現(xiàn)系統(tǒng)的無限的遠程更新和快速迭代，直到最終符合預期的網(wǎng)絡安全目標。
功能安全和網(wǎng)絡安全標準當中，其實也存在一些關(guān)于不同知識領(lǐng)域之間交叉引用的通用描述。如ISO 26262標準中提到，標準要求組織應在功能安全、網(wǎng)絡安全和其他與實現(xiàn)功能安全相關(guān)的知識領(lǐng)域之間建立并保持有效的溝通渠道。而在網(wǎng)絡安全標準ISO 21434中也提出：組織應確定與網(wǎng)絡安全相關(guān)或交互的領(lǐng)域，并建立和維護這些領(lǐng)域之間的溝通渠道，以確定網(wǎng)絡安全是否以及如何融入現(xiàn)有流程并協(xié)同相關(guān)信息的交流。協(xié)同包括在領(lǐng)域之間共享流程和策略工具的應用。關(guān)于具體的信息，詳情請參照相應的章節(jié)，還可以在備注當中看到具體對應章節(jié)的展開的信息。
同時在標準當中另外體現(xiàn)功能安全、網(wǎng)絡安全協(xié)同的信息：功能安全和網(wǎng)絡安全的開發(fā)過程之間的關(guān)系取決于項目的組織和范圍，因此沒有描述交互的方法或技術(shù)內(nèi)容?？捎山M織確定最適合這種交互的方法。
所以功能安全網(wǎng)絡安全的協(xié)同考慮引入所謂的協(xié)同工程的概念，其思路即如何通盤地考慮功能安全和網(wǎng)絡安全及其相關(guān)的活動過程（圖5），比如哪些相關(guān)的系列活動能夠協(xié)同進行？哪些活動必須是分開進行？可并行的活動之間如何關(guān)聯(lián)？如何交互？對于不同過程之間的溝通，比如典型地關(guān)于產(chǎn)品開發(fā)階段軟件開發(fā)過程的一系列的過程交互，相應的功能安全生命周期與網(wǎng)絡安全生命周期的映射關(guān)系。
協(xié)同工程當中對應安全生命周期的產(chǎn)品開發(fā)階段，尤其是軟件產(chǎn)品開發(fā)階段一系列的活動，遵循V型開發(fā)流程從需求到設(shè)計到實現(xiàn)及不同層面的驗證測試。功能安全和網(wǎng)絡安全標準當中都有相關(guān)的需求提及，具體到軟件單元集成和驗證子章節(jié)，如網(wǎng)絡安全標準ISO 21434中10.4.1章節(jié)提到關(guān)于產(chǎn)品開發(fā)設(shè)計階段需求規(guī)范，10.4.2章節(jié)當中涉及集成和驗證的規(guī)范。對應映射到功能安全標準當中的6.9章部分的軟件，如軟件單元驗證部分，如圖6。
比如我們在圖7中看到的是關(guān)于產(chǎn)品開發(fā)階段軟件開發(fā)過程的活動。相應功能安全生命周期的活動對應映射到網(wǎng)絡安全生命周期的產(chǎn)品開發(fā)階段的活動。如根據(jù)網(wǎng)絡安全的需求進行架構(gòu)總體設(shè)計及細化設(shè)計，對應功能安全過程中的軟件產(chǎn)品開發(fā)階段，派生出具體的軟件開發(fā)需求（這里我們只關(guān)注軟件層面），進行軟件架構(gòu)設(shè)計，實現(xiàn)及軟件單元和集成的驗證和軟件系統(tǒng)的測試。
協(xié)同工程根據(jù)關(guān)于相關(guān)項操作環(huán)境的現(xiàn)有信息，不同的現(xiàn)有的輸入信息進行單元和集成層面的驗證，最終會形成相應的軟件集成和驗證的規(guī)范。
協(xié)同工程在軟件單元驗證階段系列活動的目標在于：
- 提供軟件單元設(shè)計滿足分配的軟件需求以及網(wǎng)絡安全需求并適合實施的證據(jù)；
- 驗證從安全導向分析中得出的安全措施是否得到正確實施；
- 提供證據(jù)證明已實施的軟件單元符合單元設(shè)計規(guī)范，并滿足分配的軟件需求和相應的ASIL等級；
- 提供足夠的證據(jù)，證明軟件單元不包含非預期的功能或非預期的的功能安全和網(wǎng)絡安全屬性。
這里我們還著重要強調(diào)二者之間在項目當中的溝通協(xié)同活動包括了在知識領(lǐng)域之間共享的流程和使用的策略。關(guān)于開發(fā)驗證或者測試的種種策略在各標準中的要求描述中也是類似的，開發(fā)測試所用的工具共享可以最大限度的幫助我們高效實現(xiàn)我們的驗證目標。
在軟件開發(fā)當中，尤其是應用層軟件設(shè)計時，我們常用基于模型的設(shè)計（MBD）方法，比如我們會借助MATLAB Simulink/Stateflow或TargetLink建模工具實現(xiàn)功能建模?；谀Ｐ偷脑O(shè)計遵循大家所熟知的V模式的開發(fā)迭代過程如圖8。建模過程主要包括根據(jù)軟件的需求，進行相應的行為建模，功能建模和實現(xiàn)建模，繼而從模型生成代碼?；谀Ｐ偷脑O(shè)計方法的優(yōu)勢之一是使后續(xù)V模型的右側(cè)的各層面的測試驗證工作可以前置到V模型的左側(cè)，因而后續(xù)對代碼的測試可以前置為對模型的測試過程，借助合規(guī)的代碼生成工具的支持，代碼層面的測試在某些情況下可等同于對應模型的測試。通過早期對模型軟件的測試，可盡早的發(fā)現(xiàn)軟件的缺陷，最大限度的保障軟件質(zhì)量的安全。
同時在ISO 21434網(wǎng)絡安全的標準當中在開發(fā)階段當中也提到：適用于設(shè)計、建?；蚓幊陶Z言而本身未保障符合網(wǎng)絡安全需求的準則應由設(shè)計、建模和編碼指南或開發(fā)環(huán)境涵蓋3。例如對安全編碼的要求，應使用MISRA C或CERT C在“C”編程語言中進行安全編碼。這方面的網(wǎng)絡安全相關(guān)的屬性由相應的設(shè)計、建?；蚓幋a的規(guī)范保證，如C代碼的安全性適用MISRA C和CERT C標準，保證編程語言的安全。
另外，適用于設(shè)計建模編程語言的指南如運用語言子集，執(zhí)行強類型實現(xiàn)，使用防御性的實現(xiàn)的技術(shù)等，在MBD的早期開發(fā)階段保障編程語言符合對于網(wǎng)絡安全的要求。具體來講，比如對于強類型實現(xiàn)，假設(shè)我們用TargetLink建模工具去開發(fā)的應用程序如圖9，實現(xiàn)和的加和與飽和限制的運算。TargetLink對于所有整數(shù)運算，輸出數(shù)據(jù)類型和中間變量的指定值范圍必須足以避免溢出。在TargetLink模塊集中，原則上通過使用飽限模塊來避免溢出和下溢，通過使用具有足夠位長度的數(shù)據(jù)類型進行輸出和保存中間結(jié)果，避免整數(shù)算術(shù)中通過整數(shù)溢出飽和選項進行飽和約束。
再比如編碼規(guī)則CERT C中對于浮點類型數(shù)據(jù)的限制規(guī)則，不應使用對象表示方法比較浮點對象。用Simulink建模比較浮點數(shù)的等值性，圖10（左下）給出了一個具體形象的反例。在Simulink模型chart圖表定義數(shù)據(jù)類型double時，判斷邏輯當中給出比較相等的關(guān)系判定，是不允許的。建議的做法是給出相應的誤差，確保二者的誤差在相應的容差范圍之內(nèi)，圖10（右下） 。
當然不管是對模型還是對于代碼的規(guī)則，怎樣去具體的在開發(fā)中進行正確的建?；蚓幋a檢查，我們并不需要手動進行。比如我們可以借助建模檢查的高效工具，MES Model Examiner來實現(xiàn)模型對于特定建模規(guī)則的一致性。比如ISO 26262或者 ISO 21434中強調(diào)的建模編程設(shè)所適用的規(guī)則或指南，已經(jīng)全面涵蓋在MES Model Examiner的規(guī)則庫當中。除此以外，MES Model Examiner還集成了功能安全及業(yè)界最佳實踐的規(guī)則規(guī)范，指導幫助工程師自動地檢查模型并修復模型錯誤。關(guān)于給定的安全規(guī)則執(zhí)行檢查，MES Model Examiner可以給出模型違反具體規(guī)則的一致性報告結(jié)果，并可自動糾正違規(guī)模型，幫助建模人員更高效地執(zhí)行靜態(tài)分析的各項規(guī)則檢查并生成獨立完整的報告，保障模型對安全性需求的可追溯性，最終符合功能的特定ASIL需求，并保障編程語言的網(wǎng)絡安全性。MES Model Examiner工具自動化分析并修正模型報告界面如圖11。
沒有網(wǎng)絡安全，就沒有相應的功能安全。功能安全和網(wǎng)絡安全的協(xié)同工程需要全面全生命周期的協(xié)作和系統(tǒng)考慮。傳統(tǒng)意義上講，功能安全、網(wǎng)絡安全是由不同領(lǐng)域的專業(yè)人員從事的不同專業(yè)方向研究，也有著不同的專業(yè)內(nèi)容，但在系統(tǒng)的安全層面上，他們又是相互協(xié)調(diào)統(tǒng)一的整體，應該通盤考慮。汽車知識領(lǐng)域功能安全的管理人員，同時也應協(xié)同考慮預期功能安全，網(wǎng)絡安全的需求，需要多方互相協(xié)調(diào)，在矛盾與統(tǒng)一中確定影響系統(tǒng)的主要矛盾與措施優(yōu)先級，綜合全面考慮系統(tǒng)設(shè)計方案與安全措施，從而最大限度的保證系統(tǒng)的安全。
下載ECAD模型
