在安全计划和安全需求建立过程中,需要充分的考虑V模型。V模型是贯穿于功能安全开发的每个环节,如顶层设计,确认测试计划,详细设计,集成测试计划等等。而项目的具体实施只是位于V模型的最底层。
步骤7:目前的情况,一个新的功能安全的评估认证时间会较长(一般大于10个月),这个过程中,功能安全项目的开发团队和认证评估机构沟通会有很多。在制定计划时,最好指定专人负责项目的协调。建立一个功能安全管理(FSM)计划,也就安全计划(safety plan)。该计划应包括与该项目安全相关的各个方面内容以及项目预期的安全完成性等级(SIL);并且记录在开发过程中使用的所有软件工具;如果相关人员参加了培训(无论是专业培训或自学),还需提供这些培训记录。
——其实FSM是一个管理体系内容,范围比较宽泛,safety plan也是一个较大的概念,我无法详细说明,大家可以结合自己的项目再参看ICE 61508的第一部分,相信感悟会更深。只是在认证的过程中,管理体系的选择方式是比较灵活的,大家可以依据所在企业的特点开展工作。有的公司已经建立了完善的功能安全管理体系,项目直接依托公司管理体系即可;有的公司已经有了ISO 9000体系,其项目可以依托这个体系再补充项目级别的安全相关管理文件即可;如果标准的公司级别的管理体系也没有,就可以考虑直接在安全计划中建立项目级别安全管理体系。
第8步:当完成safety plan后,我们可以把重心放在产品需求规范(functional requirements)方面了。我个人感觉,其实在认证过程和IEC 61508标准钟强调的“安全需求规范”(Functional safety requirements),就是来源于产品需求规范要求;只是安全类产品更强调这个概念而已。这个步骤说起来很简单,但这往往是在开发过程中最难的步骤——很多的项目可能会直接跳过这步,进入开发实施阶段。举个例子,认证公司曾经提及西门子在进行安全PLC的开发过程,为完成“安全需求规范”,西门子花了2年多的时间,用了大量的金钱和精力去走访用户和元件供应商,从而获得现场的第一手资料完成“风险分析”(risk analysis),然后有针对性的进行产品需求分析。
第9步,当需求分析完成后,我们开始建立验证和确认计划(Verification plan and Validation planning)。随之而来的,正规的文件要求(Documentation)、测试计划,以及每个过程的复审都是项目开发必须的流程,均必须予以认真的规划。
第10步:结构设计将确定如何划分安全项目产品的硬件和软件的功能。硬件和软件要求的分配也将完成。——由于我这个项目不涉及软件,因此我会以硬件架构为例子进行说明。在准备做详细设计之前,团队还是花了不少精力分析系统的结构。
——我们的安全继电器还参考了一个标准ISO 13849-1:2008——机械行业的安全标准。这个标准如果大家陌生,对另外一个机械相关安全标准EN 954-1(ISO 13849-1的前身——由于新的机械指令在2006年已发布,ISO 13849-1将EN 954-1取代,并在今年12月份结束过渡期并生效)熟悉的人一定很多。在EN 954-1里,结构(Architecture)是一个重要的概念,着力于评判系统的安全等级的高低。虽然,IEC 61508已经弱化了结构的概念,但是其作用还是很重要的。
在这个阶段完成的其他任务包括:
•集成测试规划
•正式文件
•故障模式与影响分析(FMEA)——其主要目标是,以确定硬件的故障模式为手段或方法,可以从设计初始就检测和预防产品故障。
文章评论(0条评论)
登录后参与讨论