摘要

本系列文章旨在為中小供應商提供實施 ISO 26262 的實用措施。在第三篇文章中，我們將闡述實施 ISO 26262 的第一個難點：流程實施。我們還將探討 ISO 26262 中常用的一些術語，例如“定制”和“DIA（開發接口協議）”。

上期，我們重點介紹了功能安全的準備工作。本期，我們想解釋一下功能安全流程的實施（構建），它也是準備工作的一部分，但卻是實施過程中的第一個難關，也是最關鍵的部分。

點擊閱讀：ISO 26262實際應用（一）：遵守ISO26262之前，需了解的事項

點擊閱讀：ISO 26262實際應用（二）：確定功能安全人員后應做的“準備工作”

公司的責任范圍

圖 1顯示了 ISO 26262 假定的典型產品的基本配置。

圖1、車載系統的典型配置

企業需要實施功能安全流程的程度顯然很大程度上取決于其開發的產品在目標汽車系統（部件）中的位置。因此，汽車制造商可能需要一個涵蓋 ISO 26262 所有部分的流程。大型供應商可能需要一個與汽車制造商大致相同的流程，或者他們可能只需從系統開發（第 4 部分）開始制定流程即可。

本系列文章所涉及的中小型供應商可能只負責圖 1 中的子系統 A 和 B、B1 和 B2，或者硬件 (HW) 或軟件 (SW)。在這種情況下，必要的功能安全流程可以通過以系統開發（第 4 部分）為中心的流程來處理，在某些情況下，還可以通過硬件開發（第 5 部分）或軟件開發（第 6 部分）來處理。

在實施功能安全流程時，有必要明確貴公司的產品需要滿足 ISO 26262 要求中的哪一部分。

對于中小供應商而言，由于人力和預算資源有限，必須高效地開展響應工作，因此縮小目標范圍至關重要。提前預測各種產品和發展模式，并建立一套能夠應對所有情況的流程，在中長期內或許具有意義。然而，如果重點在于以最小的努力快速實現功能安全合規，那么更現實的做法是首先關注目前可以預測的產品和發展模式，并實施一套僅能應對這些情況的流程。

表 1顯示了產品開發中典型的職責模式。

表1、產品開發中的典型勞動分工

在實際產品開發中，我認為工作分配應針對每個產品的具體工作項進行，而不是像表 1 中那樣進行寬泛且固定的職責劃分。在這種情況下，與其通過查看 ISO 26262 各部分的范圍來縮小貴公司的職責范圍，我認為您可以根據貴公司實際的合同項目或過去的業績來縮小職責范圍，從而創建一個更切合實際的流程。

合同必需流程領域（1）

ISO 26262 第 8 部分第 5 節“分布式開發中的接口”規定了汽車制造商和供應商之間或供應商之間在產品開發之前必須達成一致的各項要求。這不僅包括請求開發所需的技術信息（例如功能規范），還包括管理要素（例如責任范圍、流程和定制細節，參見“流程定制”欄）。換句話說，對于功能安全相關產品，至少此處指明、商定和分配的責任范圍內的工作必須作為公司自身功能安全流程的一部分來實施（構建）。

通過零部件認證實現再利用

基本上，責任范圍將基于上述理念進行縮小，功能安全流程也將根據相關標準的要求進行定義。但是，也有一些例外情況，我想在此簡要提及。

通常情況下，在開發功能安全相關產品時，開發工作必須采用符合相應標準部分要求的流程。然而，ISO 26262 第 8 部分第 12 節和第 13 節分別描述了“軟件組件鑒定”和“硬件組件鑒定”的條件和認證方法。只要滿足這些條件，即使是功能安全相關產品的組件也無需完全符合該標準。

例如，中等復雜度的硬件組件和商用軟件庫如果符合 ISO 26262 第 8 部分的認證要求，并經采用方認證，即可集成到功能安全相關產品中，而無需證明其符合相應部分（硬件為第 5 部分，軟件為第 6 部分）的要求。在這種情況下，僅提供這些組件的供應商無需建立功能安全流程。但是，這些組件的責任在于采用方，因此供應商必須采取一切可能的安全措施，并提供相應的安全證明。

尤其對于中等復雜度的硬件組件而言，很難劃定明確的界限，例如何為中等復雜度，這是一個非常令人擔憂的問題。此外，對于軟件組件，復用技術是一個軟件行業多年來一直在研究但收效甚微的難題，因此必須避免僅僅基于成本而輕易復用。無論如何，我認為采用者和供應商都需要認真權衡認證的益處以及相關的風險和責任。

表 2列出了供應商的典型模式（包括例外情況）以及每種模式所需的功能安全流程。

表2、供應商所需的功能安全流程

合同必需流程領域（2）

由于本系列的重點是需要功能安全流程的中小型供應商，我們將在此結束對例外情況的討論，并回到 ISO 26262 第 8 部分“分布式開發中的接口”的第 5 節。

如前所述，開發接口協議 (DIA) 中約定的流程是與客戶簽訂合同所需的最低功能安全流程。該工作范圍不僅包括產品開發流程（即所謂的工程流程），還包括管理產品開發的管理流程、相關支持流程以及支持任務，例如產品功能安全方面的審核和評估。

表3從DIA的主要需求角度總結了功能安全流程。“功能安全所需流程”一欄中列出的流程僅為示例，因此您可以創建結構或名稱不同的流程，無需擔心。

表3、從DIA角度來看所需的功能安全流程

如表3“相關標準條款”一欄所示，此視角僅從DIA的角度出發，并不一定意味著會實施符合所有標準要求的功能安全流程。然而，大部分主要流程都已包含在內，因此我認為最好以這些流程為框架，然后逐步完善其余部分。如果已有可作為功能安全流程基礎的流程資產，則可以通過與這些資產進行比對，來識別任何缺失的流程或任務。

中小供應商功能安全評估

在表3所示的流程中，對于中小供應商而言，功能安全評估或許是最棘手的。根據ISO 26262第2部分表2的定義，功能安全評估是對“產品”的功能安全性進行評估。對于僅負責產品組件的中小供應商而言，他們不太可能判斷整個產品的功能安全性是否合格，因此直接接受標準要求是不現實的。通常，為實現安全目標而采取的安全措施是在產品層面或整個汽車系統層面考慮的，而從單個組件的角度評估安全性存在局限性。

中小供應商切實可行的做法是，只考慮功能安全評估整體要求的一部分，而不是承擔整個流程。雖然評估整個系統的功能安全性是不可能的，但這種方法可以確保他們負責的產品是按照要求并通過正確的流程開發的。例如，他們可以評估在其職責范圍內開展的驗證活動和功能安全審核的結果，并客觀地評估諸如“安全要求是否得到可靠實施？”、“是否進行了充分的測試？”以及“是否存在任何未解決的問題？”等項目。客觀評估是發現開發人員由于自身先入為主的觀念而可能忽略的問題的有效方法。

然而，具體的評估方法、評估視角、范圍和深度需要與合同方（客戶）協調并達成一致。在某些情況下，客戶將自行開展評估工作。無論如何，正如上次所述，在考慮這些問題時，您應充分考慮自身組織的實際情況，并思考如何開展盡可能有效的活動。

補充說明：關于DIA

這次，我們從大量標準要求中解釋了如何從DIA入手，縮小實施功能安全流程時所需的最小流程要素范圍。

然而，在考慮實際業務時，我們有時會被問及DIA本身的必要性究竟有多大。例如，我們經常會被問到，如果產品開發所需的技術服務（人力服務）并非外包，而是像日本開發基地常見的那樣提供，會發生什么情況。這種情況指的是將其他公司的軟件工程師派駐到公司內部進行產品開發。

DIA（分布式集成協議）基于這樣的理念：當產品以分布式方式開發時，責任應由參與方共同承擔。因此，我認為在像這樣缺乏交付責任的情況下，很難簽訂DIA協議。當然，如果不簽訂DIA協議，責任就無法分擔（責任由客戶承擔），所以客戶需要相應地管理工作。

下期，我將從這里繼續，解釋“流程實施”各個主要部分的實施要點。

（添加微信號NewCarRen咨詢）