打开APP

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列出的方法验证系统设计对于技术安全概念的符合性和完备性。

来源:第一电动网

作者:129Lab

本文地址:

返回第一电动网首页 >

相关内容
全部评论·0
暂无评论
我要评一下