汽車功能安全標準于2011年作為ISO標準正式頒布，此后，汽車業界開始采納應用該標準。

雖然標準的采納是自愿的，但在這樣的背景和趨勢之下，無論是汽車廠商還是零部件供應商，為了滿足ISO 26262的要求，要盡快調整體制，完善規章制度，構筑基于規格的生產流程，并由負責ISO 26262認證的第三方機構進行認證。

一、功能安全

什么是功能安全？所謂的“功能安全”，就是通過安全功能和安全措施來避免不可容許的功能風險的技術總稱。功能安全（Function Safety）的“功能”指的是監控受控對象和控制器的安全裝置起的作用。通常我們將計算機作為安全裝置，如果控制器發生故障，則該計算機將會關閉受控對象，并向用戶發出危險警告。安全裝置所實現的這種安全性作用，被稱為“功能安全”。功能安全可以說是通過使用計算機等的安全裝置所設計出的安全措施。

但是，在這里不得不提醒大家，安全本身并不是通過增加某種電子安全設備來保證的，而是通過“去除”導致危險發生的設計或機械故障的安全機制來保證。這種安全機制被稱為“本質安全”。

舉個栗子，這是一個非常經典的例子：

比如在鐵路道口，我們常常有這樣的危險顧慮，就是有人或者車輛進入到了鐵道入口，和火車相撞，導致死亡?！氨举|安全”就是從根本上避免危險的措施，把危險源直接“除掉”，方法是可以把這個鐵道道口改為立交橋。但是在某些情況或某些制約下，不能把鐵道道口“除掉”，自然就會想到附加一個安全設施，這就是功能安全。因為某些制約，不得不設置鐵路道口，但大家還要想避免這樣的交通事故，那怎么辦呢？這是功能安全。

歐美已經頒布了成套的功能安全相關產品指令和設計標準，并深入到各個領域，在核電行業、石油、化工、電廠等過程工業，工業機器、電梯扶梯、智能電網、家電軟件評估、汽車行業、醫療軟件評估領域廣泛應用。

這里，我們只談汽車功能安全。

二、功能安全制定的歷程

功能安全標準化的運動起源于20世紀90年代。

上世紀70年代開始，隨著各種現代化及其的使用，以及工業生產過程的自動化程度越來越高，以電氣、電子、可編程電子產品的大量應用為標志的現代化控制系統越來越多的滲透到各個領域，參與著各種控制過程。

但是，工業文明在給人類帶來利益的同時，也帶來了災難。由于系統設計不合理、設備元器件故障或失效、軟件系統的故障導致的事故、人身傷害、環境污染，越來越頻繁的危及著我們的生命安全和賴以生存的環境。

人們開始認識到，必須采取措施，用標準和法規來規范領域內安全相關系統的使用，使技術在安全的框架內發展，使人類既能盡可能享受新技術帶來的安全和舒適，同時又能掌控危險。功能安全標準研究從此展開。

然而，安全控制系統或設備執行安全功能時的可靠性問題，限制了用戶使用新技術的積極性。由于沒有公認的評價體系，制造商很難說服用戶使用新技術，尤其在關系人身財產安全的重要領域使用新技術。另外，不同行業對安全要求的不同，也限制了安全設備的產業化生產規模。制造商迫切需要一個公認的標準來建立一個與用戶對接的公共平臺。

于是，2000年5月，國際電工委員會正式發布了IEC61508標準，名為《電氣/電子/可編程電子安全相關系統的功能安全》。

IEC61508中，系統中的安全設備（減少風險的手段）由中繼控制器或PLC（Programmable logic控制器）等設備構成，我們把安全設備將實現其安全功能的可靠性的概率稱為安全完整性水平，即SIL（Safety Integrity Level）。換句話說，基于這個等級標準，即，如果與構成安全系統的部件的故障率低，則由此構成的整個安全系統的故障率也是低的。

但是，有一種觀點認為，在SIL定義中加入概率因素并不合適的。為什么不合適呢？那是因為功能安全標準不僅涉及了硬件部分，還涉及了軟件部分。僅論硬件故障發生的概率，除了初始故障和損耗故障以外，偶發故障基本是隨機發生的，如果把設計錯誤分開，那么加入概率因素是非常合適的。與此相對的軟件故障可不是隨機的了，所以軟件故障(bug)是很難去計算其發生的概率的。例如，如果軟件的設計中混入了bug，只要其發生路徑和條件具備，那么故障的發生概率就是百分百！

針對這個問題，對IEC 61508重新修訂制定了ISO 26262標準。2011年11月，ISO 26262正式頒布。

ISO 26262 不同于 IEC 61508，它“不是一個可靠性標準”，它并沒有為可接受失效概率設定準確的數字。ISO 26262基于概率論的定量危害分析僅限適用于硬件，其次，基于目標產品的使用條件和使用方法，針對整個系統進行危害分析和風險評估，識別出系統危害并對危害的風險等級——ASIL等級（Automotive Safety Integration Level，汽車安全完整性等級）進行評估。IEC 61508定義了安全完整性等級 (SIL)，而 ISO 26262 則定義了汽車安全完整性等級 (ASIL)。

ASIL有四個等級，分別為A，B，C，D，其中A是最低的等級，D是最高的等級。然后，針對每種危害確定至少一個安全目標，安全目標是系統的最高級別的安全需求，由安全目標導出系統級別的安全需求，再將安全需求分配到硬件和軟件。ASIL等級決定了對系統安全性的要求，ASIL等級越高，對系統的安全性要求越高，為實現安全付出的代價越高，意味著硬件的診斷覆蓋率越高，開發流程越嚴格，相應的開發成本增加、開發周期延長，技術要求嚴格。

三、ISO 26262是什么

ISO 26262是針對汽車電子的功能安全標準。

車載電子系統，即車輛所搭載的電子設備和計算機(包括軟件)，是ISO 26262的直接認證目標對象。在今年頒布的第二版ISO 26262中，車輛對象范圍還擴大到了到巴士、卡車、兩輪車輛。

ISO 26262的目的是確?！鞍踩?，為了實現這個目的，不僅要考慮ISO26262直接針對的電子系統，還要考慮構成電子系統的其他元件是否安全。此外，還必須明確ISO 26262的應用場景，從整體上確保車載電子系統的安全性。

圖1為ISO 26262的體系結構

ISO 26262的內容包括：

Part 1：定義術語

Part 2：功能安全管理

Part 3：概念階段

Part 4：產品開發：系統層面

Part 5：產品開發：硬件層面

Part 6：產品開發：軟件層面

Part 7：生產、運行、服務和報廢

Part 8：支持過程

Part 9：基于ASIL和安全的分析

Part 10：ISO 26262導則

Part 11：半導體應用指南

Part 1是定義標準中使用的術語的詞匯表。

Part 2中的功能安全管理定義了涉及安全相關系統開發的組織和人員應滿足的要求。

在Part 3概念階段，ISO 26262給出去了災害分析和風險評估的要求。主要做三件事：項目定義、安全生命周期初始化、災害分析和風險評估。

在Part 3中獲得的安全需求，將在技術安全中詳細說明，并分解在Part 4系統層面的安全設計中。然后，根據硬件和軟件層面的開發安全要求（Part 5和6）進行系統集成，最后對系統級功能安全進行測試驗證。

在開發階段，完成系統級產品設計后，將技術安全需求規范分解到相應的軟硬件技術安全需求規范里，進而開展軟硬件級產品設計，而在硬件層面（Part 5），必要的活動和產品開發過程包括技術安全概念的硬件實現、潛在的硬件故障及影響分析、與軟件開發的協調。

在Part6的軟件層面開發中，通過V字模型流程，遵循技術安全概念，實施軟件安全要求的導出、軟件架構設計、軟件單體設計和細化。并在此基礎上實施編碼，完成編碼后，進行軟件單元測試，軟件集成（模塊組合）和集成測試，以及軟件安全要求的驗證。

Part 7規定了直到廢棄前的批量生產、服務、市場監管的安全要求。

Part 8規定了對供應商的開發委托要求，所要支持的系統過程（安全要求的管理、配置管理、變更管理、驗證、書面化），以及軟件工具認證、軟件組件認證、硬件組件規定與認證有關的要求，對多個過程進行橫向參與。

Part 9提供了關于ASIL認定和技術分析方法的指導，并且與第8部分一樣，涉及多個流程。

Part 10是作為Part1～9的補充，對特定項目的解說及事例的指南。

盡管對于 Part 5對于硬件層面已經有相關說明，但是關于半導體層面的要求還是有限的。

四、ASIL

在ISO 26262中，ASIL是危害的風險等級的指標。

依據ISO 26262標準進行功能安全設計時，首先對系統的功能進行逐個分析，識別系統所有的危害，然后依據三個因子（S\E\C）來評估危害的風險級別。

嚴重度（Severity）

嚴重度是指一旦風險成為現實，對駕駛員、乘員、或者行人等涉險人員的傷害程度。比如電子鎖故障就比剎車故障的嚴重程度低。

嚴重性用SX表示，X取值可以是0/1/2/3，級別從低到高，級別越高，傷害越嚴重。S0無傷害；S1輕微或有限傷害；S2嚴重或危及生命的傷害（可生還）；S3危及生命的傷害（有死亡可能）或致命傷害；

風險S0S1S2S3內容沒有傷害輕度或中度傷害重度或危及生命（還有生存的可能性）威脅生命安全（幾乎沒有生還的可能）

暴露率（Exposure）

暴露率，描述風險出現時，人員暴露在系統的失效能夠造成危害的場景中的概率?；谀繕宋ｋU事件的情景，根據道路環境、天氣、車輛周六的情況、失去等等來判斷該指標。比如底盤出現異響比乘員座椅故障暴露率低。

暴露率，用EX表示， X取值從0至4，共5個等級。E0是幾乎不肯能暴露于危險中，E4是可能性極高。

風險E0E1E2E3E4內容沒有可能可能性非常低可能性低有一半的可能可能性高

可控性（Controllability）

可控性，描述風險出現時，駕駛員或其他涉險人員能夠避免事故或傷害的可能性。比如，輪胎緩慢漏氣比剎車失靈可控性高。

可控性，用CX表示，最低C0可控，最高C3幾乎不可控，共4個級別。

風險C0C1C2C3內容可控簡單可控、一般可控、幾乎不可控

ASIL等級的確定基于S、E、C這三個影響因子，下表中給出了ASIL的確定方法，其中D代表最高等級，A代表最低等級，QM表示質量管理（Quality Management），表示按照質量管理體系開發系統或功能就足夠了，不用考慮任何安全相關的設計。確定了危害的ASIL等級后，為每個危害確定至少一個安全目標，作為功能和技術安全需求的基礎。

通過危害分析和風險評估，我們得出系統或功能的安全目標和相應的ASIL等級。當ASIL等級確定之后，就需要對每個評定的風險確定安全目標，安全目標是最高級別的安全需求。安全目標確定之后，就需要在系統設計、硬件、軟件等方面進行設計、實施和驗證。

從安全目標可以推導出開發階段的安全需求，安全需求繼承安全目標的ASIL等級。那么，要如何繼承項目的安全需求呢？

接下來我們將先為大家說明如何繼承安全需求。

五、產品開發階段中功能安全需求的繼承

下圖為功能安全需求繼承的流程圖：

1.安全目標設定

如何提出系統安全需求是系統安全設計的第一步，系統安全需求的指導方針在現代安全法規中通常被表述為“安全目標設定”，它描述了所需實現的系統安全目標，并根據系統安全目標選擇相應的實現方法和途徑。

對所實施ISO 26262的項目，應用危險分析和風險評定以及評估ASIL等級，來避免不可接受的風險，并確定項目的安全目標。所謂的安全目標，就是為了防止在特定駕駛狀態下發生危險事件而采取的功能需求。通過危害分析和風險評估，為每一個風險確定一個ASIL等級，而安全目標就是為了每一個風險而設定的。

2.功能安全需求的設定（功能安全概念）

為了符合功能安全目標，在功能安全概念中規定了項目的功能安全需求。

所謂的功能安全概念，是指得出實現安全目標所需的功能安全要求，并將他們分配到初步的設計架構，或者外部減少危險的措施當中去，以確保滿足相關的功能安全。

所謂的功能安全需求，是一種安全措施（減少有害影響的活動或解決方案），且該安全措施不依賴于以安全目標為基礎的項目安全行為規范和實施。

安全目標和功能安全需求之間的關系是分層的，如下圖所示。

3.技術安全需求的設定（技術安全概念）

為了在項目中實現功能安全需求，必須根據技術安全概念，將項目級別的功能安全需求細化為系統級別所需要的技術安全需求。

所謂的技術安全需求，是為了實現功能安全需求，系統應具備的技術性安全措施。

所謂的技術安全概念，是說明如何實現技術安全需求規范。

在整個開發生命周期，技術安全需求是要落實功能安全概念的技術需求，其用意是從細節的單級功能安全需求到系統級安全技術需求。

4.系統設計

在系統設計階段，系統及子系統需要按上面所定義的貫徹技術安全要求，設計出符合系統規范的開發方法。這里，不僅考慮安全需求，還考慮非安全需求(ASIL等級表中被判定為“QM”的要求)。為了實現技術安全要求，必須考慮到系統設計的可驗證性，實現功能安全的技術能力以及系統集成期間的測試可行性。

將實施所需規范中的技術安全要求集合，即為系統規范樣式。

系統規范應直接或通過進一步細化到硬件，軟件或兩者兼有。此外，設計硬件 - 軟件接口（HSI），規定硬件和軟件的交互，并應與技術安全的概念一致。

另外，系統規范必須驗證對技術安全概念的符合性和完整性。

5.硬件安全需求和功能安全的硬件開發

根據分配給硬件的技術安全要求，可以獲得硬件安全需求。硬件安全需求主要用于保證控制器內部硬件故障的安全機制的安全要求。

ISO 26262所要求的硬件設計的要點，一是定量地實施對硬件架構指標的評估，二是由于偶發硬件故障而導致的隨機失效率的評估。

硬件架構指標，是用于評估硬件架構對硬件的偶然故障的影響（魯棒性）的指標，且為定量數值，由標準定義的公式來確定。

隨即失效率，是基于概率論，用來評價安全機制在安全性的邏輯支持之下的有效性。

6.軟件安全需求的規范

軟件安全要求以因故障引起技術安全要求偏離的功能為對象，并將其細化定義至可實施/驗證軟件的等級。

在軟件安全要求的設計方面，需要考慮指定的系統和硬件配置，硬件/軟件接口，硬件安全要求，時間限制，與項目外部視圖的接口，受軟件影響的車輛，系統以及硬件涉及的各個動作模式。

軟件安全要求規范還必須驗證與技術安全概念、系統規范、硬/軟件接口規范的兼容性和一貫性。

六、功能安全的軟件級開發

符合功能安全的軟件開發有什么不一樣的嗎？

1.軟件安全要求的可追溯性

ISO 26262要求將各危險風險降低設定為安全目標，并且在整個開發過程中，保證測試結果都可以通過其驗證測試、實施、規范和要求來追溯。這就是功能安全的可追溯性?？勺匪菪钥赏ㄟ^給需求添加ID號碼來識別。

在軟件開發中，ID號碼用于關聯軟件安全需求標準的軟件安全需求（相當于軟件功能設計）、軟件架構設計標準的軟件組件以及軟件單元設計標準的函數（如下圖）。 這使得安全需求的關系明確，并且通過驗證和試驗，可以有效地發現對于上級要求來說的下級要求存在的遺漏，以及對函數不良影響的條件的影響等。

關于需求的可追溯性管理，可使用軟件開發中的需求管理工具來實現。

2.設計方法

在ISO 26262中，軟件想要達到系統所分配的更高安全目標的ASIL D等級，就需要更加嚴謹的軟件架構。

在軟件架構設計中，如果想要達到符合ASIL D等級，就必須滿足軟件組件的分層化、軟件組件大小的限制、適當的調度、軟件組件的內聚、耦合限制和中斷限制。

在各種軟件設計的方法中，結構化設計方法已經不是什么新鮮的方法了。但在ISO 26262中，顯然，該方法是處理應對ASIL相應等級的必須手段。

在軟件架構級別的錯誤檢測階段中，對于ASIL D的要求，必須進行輸入輸出數據的范圍檢查、數據有效性檢查、外部監控、控制流監視和軟件冗余設計。

在軟件架構級別的錯誤處理階段中，對于ASIL D的要求，必須具有發生錯誤時的縮退功能以及并行的冗余。

在單體軟件設計階段中，對于ASIL D的要求，相關函數只能有1個出入口，限制動態安全對象（例如堆棧區域），執行變量初始化，禁止相同變量名稱，限制使用全局變量，限制指針使用，禁止隱式類型轉換，禁止隱藏數據流/控制流，禁止無條件跳轉，禁止遞歸調，ISO 26262沒有深入涉及建模設計。關于汽車建模設計（基于模型的開發），MATLAB / Simlink被認為是典型方法，盡管如此，執行建模設計并不一定有助于導入功能安全。

不基于模型設計的軟件開發代碼質量，與基于模型設計的軟件開發代碼質量是相同的。在建模設計中提高模型的質量，也有助于由此產生的產品（項目）的安全性。關于設計模型時的指南，ISO 26262結合編碼指南定義了設計指南的要求。

3.驗證

所謂“驗證”，就是確認已“正確”完成產品開發。

在ISO26262中，關于軟件架構設計、軟件單體設計和實現(編碼)，規定需要完成與ASIL等級相對應的驗證。

對于軟件架構設計驗證，如果是ASIL A級別，只要排查就足夠了。但如果是達到符合ASIL D級別，則必須進行檢查，動態（可執行模型）仿真，原型設計，控制流/數據流分析。

對于軟件單一設計和實現（編碼）驗證，如果是ASIL A級別，只要排查就足夠了。但如果是達到符合ASIL D級別，就必須進行檢查，半正式驗證（使用基于模型的仿真驗證等），控制流/數據流分析，靜態代碼分析。

4.確認

所謂“確認”，就是通過提供客觀證據對特定的預期用途或應用要求已得到滿足的認定。通過試驗來確認是否產生了滿足要求的成果物。

對于ASIL D等級要求，無論是軟件單元測試還是軟件集成測試，都必須進行基于需求的測試、接口測試、故障注入測試、資源測試和背靠背測試。

在測試用例的導出方法中，需求分析，等價類的創建和分析以及邊界值分析是對于符合ASIL D等級的基本要求。

對于軟件單元測試的覆蓋率，ASIL A可以執行100％的C0覆蓋（指令覆蓋率），而ASIL D則要求100%實施C1覆蓋(分支網羅率)及MC/DC(Modified Condition/Decision Coverrage) 。

對于軟件集成測試，ASIL D要求100%實施功能覆蓋和調用覆蓋。

5.軟件工具的認證

為了軟件開發而使用導入的各種軟件工具（以下簡稱為工具），ISO 26262為它們設定了可靠性評估指標，只有被認定為符合指標的工具才能夠用于開發。

所以，首先第一步，我們需要看看工具是否符合ISO 26262的認證標準。

為此，我們需要驗證軟件工具對于安全功能的影響（TI），也要同時考評軟件工具，針對自身可能出現的內部錯誤的診斷能力（TD），并最終生成該軟件工具的置信等級（TCL）。

TI是對軟件工具是否對正在開發的設計產生直接的安全相關影響的評估。TI分為兩個級別，TI1和TI2。TI1意味著對設計沒有直接影響，而TI2則表示對設計有直接影響。當軟件工具故障對項目或者組件完全沒有影響時，可選擇TI1。其他情況則選擇TI2。

TD指對工具由于誤操作而引起錯誤輸出防護手段，以及工具發生錯誤時候檢測能力的信賴性，,用TD1，TD2，TD3三個等級來評價。當對于誤動作以及對應的誤輸出的防護和檢測手段信賴性要求比較高時候，選擇TD1；信賴度要求處于中等程度的時候選擇TD2，其他情況選擇TD3。

例如，假設某工具用于檢測設計模型的錯誤。該工具對模型執行靜態分析。當靜態分析良好時，該工具不能檢測模型中的所有可能違規行為。還有一點值得注意的是，這并不一定意味著該模型是錯誤的，而僅僅表明需要額外的測試。該例是一種中等程度的置信水平，即TD2。

根據TI和TD，我們可以通過以下矩形表格來確定TCL

判定為TCL1的工具無需認證即可使用，而判定為TCL2和TCL3的工具則需要附加鑒定方法，以下為適用的四種認證方法：

1a 信賴度通過使用而增強

只有提供了標準規定的工具實際應用的有關證據，才能基于使用歷史，提升工具的信賴度。

1b 評估工具開發過程

該工具開發的開發過程是否開發流程，開發標準。

1c 軟件工具確認確認

確認滿足標準所判定的指標的方法。

1d 按照安全標準進行開發

工具開發是否符合ISO26262，IEC61508和RTCA DO-178（航空系統和設備的安全標準）等標準。

事實上，只要執行了附加認證，就可以使用TCL2或TCL3中評估的軟件工具。ISO 26262也列出了關于TCL2和TCL3級工具可接受的認證方法。

ISO 26262-8:2011表4列出了對TCL3級工具可接受的認證方法，表5列出了對TCL2級工具可接受的認證方法。（如圖）

根據工具中開發的項目或ASIL類別的不同，優先選擇應用不同的認證方法。下圖為合并的表格，其中突出顯示了優選方法并且進行了說明。

++表示該方法被強烈建議用于所對應的ASIL

+表示該方法被建議用于所對應的ASIL

注：*沒有如何安全標準完全適用于軟件工具的開發。但可以選擇安全標準的相關子集要求。

在TCL2的情況下，ASIL A/B/C需要附加驗證方法1a和1b，ASIL D需要附加驗證方法1c和1d。

在TCL3的情況下，ASIL A/B 需要附加驗證方法1a和1b，ASIL C/D需要附加驗證方法1c和1d。

實際上，從供應商處購買工具時，用戶很難執行認證。因此，引入符合ISO 26262的第三方認證工具是非常符合現實需求的。

6.通過保護功能防止故障的傳播

在特定軟件組件發生故障時，為了防止對另一軟件組件造成不良影響，ISO 26262一個名為“軟件隔離”的結構技術。當多個不同ASIL等級的軟件組件在同一個MPU上共存時，該技術非常適用。

舉個例子：在沒有分區的情況下，假設有ASIL A，ASIL B和ASIL C三個不同等級的軟件，使用一個MPU和一個資源（共享內存）進行操作，則三個軟件必須符合最高的ASIL等級要求（即ASIL C），導致必須承擔高于必要的開發成本。同時，低等級的任務修改高等級的數據，會造成高等級使用了不可信的數據，影響安全功能。

如果有分區，即使三個不同ASIL等級的軟件在一個MPU上，也可以將最佳的ASIL等級應用于各個軟件組件，可以避免浪費的開發成本。

軟件分區技術有很多，將軟件分區應用于汽車MPU時，從成本方面考慮，一般認為，利用MPU的存儲器保護單元的OS方法是最有希望的。

7.流程改進

在嵌入式軟件領域，要求不斷改進過程標準，如CMMI和Automotive SPICE。

ISO 26262也需要流程改進，但基本上是對現有流程改進的延伸。建議至少通過CMMI Level 2和Automotive SPICE Level 3認證。

在ISO26262中，Part2功能安全的管理規定了確認審查（從技術的觀點驗證成果）和功能安全審核（從過程的角度確認功能安全活動的實施狀態）。通過結合三點功能安全評估的驗證策略（S/E/C）實現獨立評估ASIL等級，該評估項目可評估功能安全的合規性。

ASIL的獨立性被定義為4個級別，最輕的級別是“認證方案應由不同的人實施”，最重的級別是“來自不同部門或組織的人員實施認證”（即并且必須由第三方實施）。根據認證的內容，較高的ASIL級別需要更高的獨立性。

第三方組織可以是公司內的獨立部門，例如質量保證部門，或是外部第三方認證機構。為應對功能安全認證的市場需求，有許多供應商和工具供應商要求知名第三方認證機構進行審核。

七、結論

2011年11月15日，ISO 26262 標準正式頒布。2018年，ISO 26262正式上路。

在這一領域，歐洲、日本應用ISO 26262要早于國內，美國則推出SAE J2980標準。技術咨詢公司在和國內OEM合作時會要求引入功能安全。國際汽車廠商（寶馬、通用、福特等）、汽車零部件供應商（博世、德爾福等）早已采用該標準開發安全相關的電子電器產品，應用在汽車的開發。

ISO 26262涉及汽車電子電氣系統的整個安全生命周期及其管理過程，滿足該標準對汽車企業及供應商來說必將是巨大的挑戰。為滿足ISO 26262，必須在公司安全文化、工作流程制定、產品設計與開發等方面進行持續的改進。

ISO26262標準暫時沒有出現官方層面的強制執行要求，但該標準的執行，將減少因為電子器件失效造成的交通事故和降低潛在召回風險，所以目前國際大型車企非常重視ISO26262標準的應用和推廣。

▲文章來源于：知乎   ?？W城

返回