在《BMS功能安全開發流程（三）：ASIL等級》中介紹了功能安全概念的目的是從安全目標（SR）中得出功能安全要求（FSR），并將其分配給相關項的初步架構要素或外部措施。

技術安全要求導出

圖1說明了通過分層的方法，從危害分析和風險評估得出安全目標，再由安全目標得出功能安全要求。

圖1?安全目標和功能安全要求層級

圖2給出了ISO26262相應部分中的安全要求的結構和分布的說明。將功能安全要求分配給初步架構要素。

圖2?安全要求的結構

技術安全要求（TSR）是對功能安全要求（FSR）提煉，細化了功能安全的概念，同時考慮功能性的概念和初步的體系架構。通過分析技術安全需要來驗證符合功能安全需求。在整個開發生命周期，技術安全需求是要落實功能安全概念的技術要求，其用意是從細節的單級功能安全要求到系統級的安全技術要求。

技術安全要求應根據功能安全概念、相關項的初步架構設想和如下系統特性來定義：

a.???外部接口，如通訊和用戶接口，如果適用；

b.???限制條件，例如環境條件或者功能限制；以及

c.????系統配置要求。

在第三篇文章中，從安全目標道出了BMS的一個功能安全要求，圖3是對功能安全要求FSR1.2a導出的技術安全要求。

圖3

系統設計

基于概念階段的基本系統架構，功能安全概念，技術安全要求和非功能性要求，按照ISO26262的下一步流程就是系統設計了。在這個階段，系統及子系統需要上面所定義的貫徹技術安全要求，需要反映前面定義的安全檢測及安全機制。

技術安全要求的應分配給系統設計要素，同時系統設計應完成技術安全要求，關于技術安全要求的實現，在系統設計中應考慮如下問題：

a.? 系統設計的可驗證性

b.??軟件硬件的技術實現性

c.??系統集成中的執行測試能力

系統和子系統架構應該滿足各自ASIL?等級的技術安全需求，每個元素應實現高的ASIL技術安全需求，如果一個系統包含的子系統有不同的ASIL?等級，或者是安全相關的子系統和非安全相關的子系統，那么這些系統應該以高的ASIL等級來處理。

在系統設計階段，為了避免系統系失效，ISO26262針對不同的ASIL等級推薦了不同的分析方法，如FMEA,FAT等。如表1。由于內因或者外因而引起系統失效應當避免或者消除。

表1

為減少系統性失效,?宜應用值得信賴的汽車系統設計原則.?這些原則可能包括：

a.???值得信賴的技術安全概念的再利用；

b.???值得信賴的要素設計的再利用,?包括硬件和軟件組件；

c.???值得信賴的探測和控制失效的機制的再利用,?及

d.???值得信賴的或標準化接口的再利用。

為了確保值得信賴的設計原則或要素在新相關項中的適用性,?應分析其應用結果,?以及應在再利用之前檢查其基本設想。

ASIL A、B、C、D?規定：為避免高復雜性帶來的故障，架構設計應該根據表2?中的原則來展現下列的屬性：模塊化，層次化，簡單化

基于上面定義的TSR和概念階段定義的基本架構圖，圖4是精煉之后的BMS系統架構圖。

圖4

下一步是定義系統架構，分配TSR給硬件和軟件，同時定義好軟件硬件接口HIS。

軟硬件接口規范應規定的硬件和軟件的交互，并與技術安全的概念是一致的，應包括組件的硬件設備，是由軟件和硬件資源控制支持軟件運行的。軟硬件接口規范應包括下面屬性：

a.???硬件設備的工作模式和相關的配置參數， 硬件設備的操作模式，如：缺省模式，

b.???初始化，測試或模式， 配置參數，如：增益控制，帶通頻率或時鐘分頻器。

c.????確保單元之間的獨立性和支持軟件分區的硬件特性

d.???共享和專用硬件資源，如內存映射，寄存器，定時器，中斷，I / O?端口的分配。

e.???硬件設備的獲取機制，如串口，并口，從，主/從

f.????每個涉及技術安全概念的時序約束

硬件和其使用的軟件的相關診斷功能應在軟硬件接口規范中規定：

a.???硬件診斷功能應定義，例，檢測過流，短路或過熱

b.???在軟件中實現的硬件診斷功能

軟硬件接口規范在系統設計時制定，在硬件開發和軟件開發時被進一步細化。應使用表3列出的方法驗證系統設計對于技術安全概念的符合性和完備性。