安全是汽車行業的質量特征

安全性是所有汽車制造商的關鍵設計考慮因素。現代汽車的復雜性正在上升，因此，它們包含數千個電子部件。因此，很難確保它們單獨和集體都表現良好，以安全地提供所需的功能。目前部分或全自動駕駛汽車的發展及其持續發展，提高了以現代和有條不紊的策略解決安全問題的需求。

為了滿足功能安全的需求，國際標準化組織 （ISO） 引入了道路車輛電氣和/或電子系統功能安全的 ISO 26262 標準。ISO 61508 是對 IEC 26262 工業安全標準的改編，側重于將風險降低到可接受的水平，管理和跟蹤安全要求，并確保設計、驗證、測試和驗證中的標準化安全程序。

當安全對您的設計成功至關重要時，您可以依靠我們久經考驗的經驗來幫助您滿足功能安全要求，同時最大限度地降低成本和開發時間。我們廣泛的功能安全就緒和功能安全兼容DSC33數字信號控制器（DSC）產品組合提供集成的硬件安全功能、故障模式、影響和診斷分析（FMEDA）報告、安全手冊和診斷軟件庫，以開發符合ISO 26262要求的安全關鍵型應用。在設計功能安全應用時，使用滿足安全標準要求的開發工具可以使系統集成商更輕松地創建兼容的系統。

Microchip已獲得TüV南德意志集團的MPLAB? XC16 C編譯器認證，符合ISO 26262功能安全標準，以幫助系統集成商在其應用中實施系統級功能安全，我們為MPLAB開發工具生態系統提供完整的認證包，以幫助認證開發工具鏈。

以下部分涉及 ISO 26262 中定義的標準術語。有關這些標準術語的定義，請參閱附錄。

在開發安全關鍵型應用程序時，必須遵循標準規定的第1 項實施的邏輯流程圖。完整的程序必須用于標準規定的車輛級別的項目（對整個車輛或大部分車輛）。以下是在項目級別必須遵循的實現流程中的關鍵步驟：

項目定義：正在開發的系統的描述

危害分析和風險評估（HARA）：定義物品用戶可能遇到的所有危害和風險

安全目標：設計中解決危害的目標

要求：實現安全目標的一套高級功能要求、技術要求和詳細的軟硬件要求

安全機制：用于提高解決危害的技術要求性能的硬件和/或軟件技術

流程圖：

汽車安全完整性等級 （ASIL）

ASIL代表汽車安全完整性等級，是根據ISO 26262定義的風險分類方案。三個因素的組合決定了ASIL的要求。

嚴重程度：對人們生命造成損害的嚴重性或強度

暴露：車輛處于危險狀態的概率的度量

可控性：衡量駕駛員控制危險情況的可能性

ASIL = 嚴重性×（暴露×可控性）

ASIL 級別（ASIL A、B、C 和 D）是根據 ISO 26262 標準定義的分配表分配的，其中每個類別下的 1 級為低，4 級為高，如下所示：

S3、E4 和 C3（三個參數的極端值）共同表示極其危險的條件。因此，被評估的組件被歸類為 ASIL D，表示它需要盡可能高的安全預防措施。

脫離上下文的安全元素 （SEooC） 的定義和假設

為了管理用作系統/項目元素的微控制器等組件的安全要求，需要引入一個新概念，即脫離上下文的安全元件（SEooC）。在汽車領域，ISO 26262中定義的SEooC是在車輛中使用最初不是為該特定項目設計的組件的方法：

安全元件（例如微控制器）并非專門設計用于該商品

它在市場上有售（現成的）

它可以實現請求的功能

所描述的實現過程部分偏離了上面顯示的實現流程的內容，因為涵蓋的設計不是指項目，而是指元素。

假設規范：通常，考慮四組假設，然后根據特定元素進行定制。在某些應用環境中，微控制器可以假定為安全元件。以下是規格：

預期用途：描述 SEooC 的目標、設計原因以及如何使用

預期功能：描述 SEooC 的設計目的以及它應該做什么

使用上下文：描述如何在整個系統/項目中使用 SEooC 來執行所需的功能

外部接口：描述 SEooC 如何在硬件和軟件方面與系統的其余部分進行交互

需求規范：上述假設允許定義 SEooC 必須符合的要求

開發：涉及SEooC的有效設計

驗證：如果系統/項目設計在硬件設計期間包含 SEooC，則根據系統/項目硬件安全要求和設計規范驗證 SEooC 假設

假設的第二次驗證是在SEooC的集成和測試階段進行的

微控制器作為安全系統 （SEooC）

以下是實施流程中的關鍵步驟：

在項目層面，還進行危害分析、風險評估和安全目標的定義。

功能安全手冊提供了有關 FMEDA 報告中指定的故障檢測方法的詳細信息。它包括相關故障的說明以及用于檢測系統故障的硬件功能，可用于開發診斷庫。根據允許的不安全故障率，可以按如下所示評估風險級別：

及時失效 （FIT） 是一個單位，表示故障率以及每 109 小時發生的故障數。

審核編輯：郭婷