符合ISO 26262标准的安全档案
如今，道路车辆上（Road Vehicles）越来越多的安全相关功能由电子/电气系统实现。这些系统如果出现功能故障（Malfunction），就有对车辆乘员或者其他道路使用者造成伤害的风险，比如，电动助力转向系统（Electrical power steering, EPS）如果出现助力反向的功能故障，车辆将不能按照驾驶员预期的方向行驶，可能会导致严重车祸，造成人员伤害。为了保证安全，应考虑如何将风险降低到可接受的范围。2011年11月正式发布的道路车辆功能安全标准ISO 26262[1]就是为了解决这一问题，该标准为开发安全相关系统提拱了过程和要求，其中一个很重要的要求就是生成安全档案（Safety Ca），安全档案的目的是通过结构化论证（Argument）来证明安全相关系统是可接受安全的。但是，ISO 26262 标准对安全档案的描述的篇幅很短，并没有给出开发安全档案的指南。本文基于安全气囊系统来介绍如何利用GSN（Goal Structuring Notation）[2]方法开发符合ISO 26262 标准的安全档案。
本文的结构为：第二部分介绍安全档案的起源和概念，安全档案的描述方法GSN；第三部分介绍如何用GSN的方法来开发安全气囊系统的安全档案。
一、安全档案
其他行业如核工业、化学工业、海上石油、铁路行业等，都有法律法规要求在其设施正式投入使用之前，必须提交安全档案以证明其产品是可接受安全的。安全档案起源于1957年英国温茨凯尔火灾（Wind
scale 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-bad argument），通过证明产品的开发过程满足标准中定义的过程，安全计划、项目计划、确认措施报告等都是与过程相关的工作产品。标准中关于探测系统失效的措施属于安全论证，比如FMEA分析报告、安全措施等都是与产品相关的工作产品。将安全论证和置信度论证分开有利于安全档案的复用[6]和管理和评审。
安全档案是为了向有关机构呈现的，证明系统的安全的。如何撰写论证清晰的安全档案也是很重要的一个问题。安全档案可以用纯文字描述，但是纯文字的描述方式很难使读者识别安全档案的元素和结构，所以用图表的方式会更清楚，比如：表格式的（tabular）[4]、跟踪矩阵式的（traceability matrix）[7]、Goal Structuring Notation(GSN)。每种方式各有优缺点，这里我们选用GSN方法，因为其语法、语义清晰、简单，支持模块化[8]、复用，并且有可遵循的使用指南[9]。
在这里简单介绍一些GSN各个符号，关于符号的详细介绍以及GSN六步构造方法请参考文献[8]
excel两列数据对比找不同
Context ID
Context
statment
A
饿了么客服电话Assumption ID
Assumption
statment
In context of
乔迁之喜
图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 nsor）。当条件达到或者超过阈值时，安全气囊控制单元触发气体产生点火器，快速的打开尼龙织物气囊。当车辆乘员撞到或挤压气囊的时候，气体以受控的方式通过出气孔排放气体。
2) 危害分析和风险评估（Hazard Analysis and Risk Asssment）
本文章主要针对安全气囊系统中的危害事件“气囊非预期打开”，这个危害事件被分为ASIL D等级，其中暴露率E为E4，可控性C为C3，严重度为S3。
3) 安全目标和安全概念（Safety Goal and Safety Concept）
安全目标为防止气囊非预期打开，ASIL D，安全状态为关闭安全气囊系统。
功能安全概念为：探测故障并且关闭安全气囊系统。
由于篇幅有限，我们基于以上信息来建立安全气囊系统的安全档案。
图5是安全气囊系统的安全档案，图6是对图5中危害分析和风险评估置信度模块的论证，图7是对图5中功能安全概念合理性模块的论证。
等都与图5 安全气囊系统功能安全论证
5/7
