产品动态-凯发官方首页

        如今，道路车辆上（road vehicles）越来越多的安全相关功能由电子/电气系统实现。这些系统如果出现功能故障（malfunction），就有对车辆乘员或者其他道路使用者造成伤害的风险，比如，电动助力转向系统（electrical power steering, eps）如果出现助力反向的功能故障，车辆将不能按照驾驶员预期的方向行驶，可能会导致严重车祸，造成人员伤害。为了保证安全，应考虑如何将风险降低到可接受的范围。2011年11月正式发布的道路车辆功能安全标准iso 26262[1]就是为了解决这一问题，该标准为开发安全相关系统提拱了过程和要求，其中一个很重要的要求就是生成安全档案（safety case），安全档案的目的是通过结构化论证（argument）来证明安全相关系统是可接受安全的。但是，iso 26262 标准对安全档案的描述的篇幅很短，并没有给出开发安全档案的指南。本文基于安全气囊系统来介绍如何利用gsn（goal structuring notation）[2]方法开发符合iso 26262 标准的安全档案。

        本文的结构为:第二部分介绍安全档案的起源和概念,安全档案的描述方法gsn；第三部分介绍如何用gsn的方法来开发安全气囊系统的安全档案。

 

一、安全档案

        其他行业如核工业、化学工业、海上石油、铁路行业等，都有法律法规要求在其设施正式投入使用之前，必须提交安全档案以证明其产品是可接受安全的。安全档案起源于1957年英国温茨凯尔火灾（windscale fire）事故[3]。该事故发生后，成立了英国核监管部门——核设施监察局（nuclear installations inspectorate, nii), 核设施为了获得运营许可，需要向nii提交一系列报告以证明设计的安全，此被广泛认为是安全档案，虽然这时候还没有采用“安全档案”这个概念。许多标准给出了安全档案的定义[4]，iso 26262标准中的定义为：安全档案应该清晰、全面、合乎情理的论证（有证据支撑）系统在特定的环境中不存在不合理风险。从此定义中可以看出，安全档案包含三个主要的元素：需求(requirement)，论证(argument)、论据(evidence)。需求是指为了保证系统的安全，必须满足的安全需求，对应iso26262中的安全目标以及各阶段的安全需求；论据是指证明安全的证据，对应iso 26262中的工作产品，比如测试报告、fmea 分析报告等。论证指解释论据为什么能够支撑需求。这三个元素之间的关系可以用图1表示。

图1 安全档案三元素之间的关系

        没有证据的安全档案是没有基础的，空洞而不具备说服力；没有论证的安全档案是无解释的，证据和需求之间的关系不清楚。安全档案包含两种类型[5]：安全论证（safety argument）和置信度论证（confidence argument）。安全论证主要证明产品满足危害分析过程中推到出的安全需求，是论证的核心；论证的过程中可能论证的推理或使用的证据有缺陷，比如：测试报告证据，由于测试的人员的能力问题或者测试用例覆盖率不够等原因，使得测试报告的置信度降低，那么论证的说服力也大打折扣。这两个类型的论证是缺一不可，相互补充的。iso 26262标准中关于避免系统失效的措施属于是置信度论证，比如基于过程的论证（process-based argument），通过证明产品的开发过程满足标准中定义的过程，安全计划、项目计划、确认措施报告等都是与过程相关的工作产品。标准中关于探测系统失效的措施属于安全论证，比如fmea分析报告、安全措施等都是与产品相关的工作产品。将安全论证和置信度论证分开有利于安全档案的复用[6]和管理和评审。

        安全档案是为了向有关机构呈现的，证明系统的安全的。如何撰写论证清晰的安全档案也是很重要的一个问题。安全档案可以用纯文字描述，但是纯文字的描述方式很难使读者识别安全档案的元素和结构，所以用图表的方式会更清楚，比如：表格式的（tabular）[4]、跟踪矩阵式的（traceability matrix）[7]、goal structuring notation(gsn)。每种方式各有优缺点，这里我们选用gsn方法，因为其语法、语义清晰、简单，支持模块化[8]、复用，并且有可遵循的使用指南[9]。

        在这里简单介绍一些gsn各个符号，关于符号的详细介绍以及gsn六步构造方法请参考文献[8]

图2 gsn图例

        目标(goal)是指要满足的需求，比如：系统xx是可接受安全的、模块xx是按照asil d的等级开发的。满足一个目标通常需要通过满足子目标，所以一个目标通常需要进行分解；策略(strategy) 放在母目标和子目标之间，用于解释为什么母目标可以分解为子目标；解决（solution） 是指支撑目标的证据；除了以上的核心元素外，环境（context）是指安全论证所处的环境；假设（assumption）是指论证所基于的假设；说明（justification）是指对采用策略或呈现安全目标进行理由说明。元素之间的连接线solved by 表示目标之间以及目标和证据之间的关系，in context of 表示目标或策略和环境之间的关系。除了这些基本图例外，gsn支持模块化[9]，如图3表示了gsn模块，在其他地方展开论证。

图3 gsn模块图例

 

二、安全气囊系统

1)项目定义（item definition）

        安全气囊的初始架构如下图所示（用medini analyze 工具搭建）。

图4 安全气囊系统初始架构

        安全气囊是一种乘员约束系统，当发生汽车碰撞时，气囊快速地打开，避免乘员撞击到车内的物体，比如：方向盘、车窗。安全气囊设计在概念上比较简单；中央控制单元——安全气囊控制单元（airbag control unit， acu）监控车内的碰撞传感器（bumper sensor）。当条件达到或者超过阈值时，安全气囊控制单元触发气体产生点火器，快速的打开尼龙织物气囊。当车辆乘员撞到或挤压气囊的时候，气体以受控的方式通过出气孔排放气体。

2)危害分析和风险评估（hazard analysis and risk assessment）

        本文章主要针对安全气囊系统中的危害事件“气囊非预期打开”，这个危害事件被分为asil d等级，其中暴露率e为e4，可控性c为c3，严重度为s3。

3)安全目标和安全概念（safety goal and safety concept）

        安全目标为防止气囊非预期打开，asil d，安全状态为关闭安全气囊系统。

        功能安全概念为：探测故障并且关闭安全气囊系统。

        由于篇幅有限，我们基于以上信息来建立安全气囊系统的安全档案。

        图5是安全气囊系统的安全档案，图6是对图5中危害分析和风险评估置信度模块的论证，图7是对图5中功能安全概念合理性模块的论证。 

图5 安全气囊系统功能安全论证

图6 危害分析和风险评估置信度论证 

图7 功能安全概念合理性论证

 

三、结论

        iso 26262标准中明确提出要求生成安全档案，但是标准中没有给出生成安全档案的指南，本文主要介绍了安全档案的起源、概念、描述方式，并且以安全气囊系统为例介绍了如何构建安全档案。