BMS功能安全开发流程（四）：技术安全要求导出

在第三篇中介绍了功能安全概念的目的是从安全目标（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列出的方法验证系统设计对于技术安全概念的符合性和完备性。