安全苛求系统及其评估.ppt

安全苛求系统及其认证,同济大学徐中伟,主要内容,引言功能安全性安全苛求系统的开发容错和故障安全技术系统可靠性形式化方法验证、确认和测试质量管理铁路信号EN标准和安全性认证典型的高安全系统实例,引言关键领域中应用的安全苛求系统,领域：核工业、航空、航天、军工、交通、医疗等特点：嵌入式的、实时的、安全相关的系统失效的后果往往是灾难性的名称：安全苛求系统（Safety-criticalSystems）,功能安全性（FunctionSafety）,概念：是系统不危及生命或环境的属性两种安全性：信息安全性与功能安全性（SecurityandSafety）安全性与可靠性可信性（Dependability）：RAMS安全性范围：硬件和软件、系统边界基于计算机的控制和防护系统:优点和缺点,安全苛求系统的开发,故障、错误和失效（Fault、ErrorandFailure）故障分类：随机性故障和系统性故障避错（faultavoidance）、纠错（faultremoval）、检错（faultdetection）和容错（faulttolerance）V型生命周期模型验证和确认,系统需求,可靠性（Reliability）：系统在给定条件，给定的时间内实现所要求功能的可能性可用性（Availability）：系统在任意时刻能完成规定功能的可能性故障安全操作（Fail-Safe）系统完整性（SystemIntegrity）：系统检测到故障并通知操作员的能力数据完整性（DataIntegrity）系统恢复（Systemrecovery）可维护性（Maintainability）可测试性（Testability）可信性（Dependability）系统需求之间冲突,安全性需求,识别危害危害分类确定处理危害的方法可靠性和可用性需求的分解确定适合的安全完整性水平符合选定安全完整性水平的开发方法规范,危害分析技术,失效模式和影响分析（FMEA）失效模式、影响和危害性分析（FMECA）危害和可操作性研究（HAZOP）事件树分析（ETA）故障树分析（FTA）等等,生命周期不同阶段的安全性分析,初始危害识别（PHI）初始危害分析（PHA）安全性评审安全性计划系统危害分析系统风险评估独立安全性审计,误动作的后果危害严重等级,注：不同领域有不同标准规定,误动作的可能性频率,频繁经常有时很少极少几乎不可能注：不同领域有不同标准规定,风险矩阵,风险=严重度x频率风险矩阵,注：不同领域有不同标准规定,风险分类,风险接受原则实例ALARP原则(AsLowAsReasonablyPracticable),注：其他还有GAMAB原则、最小内在死亡率（MEM）原则,风险评估和验收实例,风险缩减过程,允许风险,组合:外部设施系统设计程序结构调整元件设计,实际风险缩减,产生实际风险缩减,最小风险缩减,现有风险,安全完整性SI,在指定的时间范围内和指定的条件下，系统圆满完成规定的安全功能的可能性。,安全需求和安全完整性,系统需求规范,非安全需求,安全需求,安全需求规范,安全完整性需求,系统失效完整性,随机失效完整性,安全功能需求,安全完整性等级SIL,SIL4SIL3SIL2SIL1SIL0,SIL表,V型生命周期模型,概念,系统定义和应用条件,风险分析,系统需求,系统需求分配,设计和实现,制造,安装,系统确认,系统验收,运行和维护,停用和处置,开发方法,需求和危害分析规范正确性完备性一致性无二义性规范原型化自顶向下设计细化设计模块实现模块测试系统集成系统测试分层设计安全内核和防火墙可测试性的设计面向维护的设计人因差错的考虑安全性管理安全评估和认证,故障类型,硬件故障类型单固定故障短路故障开路故障硬件设计和规范故障等等软件故障类型软件规范故障编码故障栈溢出故障使用未初试化便量故障等等故障覆盖率,容错和故障安全技术,冗余技术多系备份技术（热备、冷备）多系表决技术设计多样性技术硬件软件故障诊断技术功能检查一致性检查信号比较信息冗余指令监测回环测试看门狗总线监测电源监测,硬件容错和故障安全技术,静态容错技术三模冗余TMRN模冗余表决技术动态容错技术备份技术自检验对技术混合容错技术带有备份的N模冗余技术硬件容错的模块同步和多样性固有式故障安全技术组合式故障安全技术反应式故障安全技术电磁兼容设计防雷设计,固有式失效-安全,这种技术允许一个安全相关功能由单个项执行，前提是假定项的所有可信失效模式均为非危险的。,组合式故障-安全技术,A中出现第一个故障,每个安全相关功能应至少由两个项来执行。各项之间应相互独立，以避免共因失效。只有当必要数量的项取得一致时，才允许进行非限制行为。应能检测出一个项中的危险故障并在足够的时间内加以屏蔽，以避免第二个项发生相同故障。,反应式故障-安全技术,功能A,功能A故障检测,屏蔽,输出,功能A,检测,输出,T,安全状态,A中出现第一个故障,第一个故障被检测出,屏蔽输出,A中出现第一个故障后的检测和屏蔽时间T不应大于规定的潜在危险性瞬间输出时间限制,这种技术允许一个安全相关功能由单个项执行，前提是通过快速的危险故障检测和屏蔽来确保它的安全操作(例如通过编码，多路计算和比较，或通过连续的测试)。尽管只由一个项实施实际的安全相关功能，但检查/测试/检测功能应被看作为第二项。检查/测试/检测功应是独立的，以避免共因失效。,软件容错和故障安全技术,多版本编程技术恢复块选择合适的程序设计语言设计良好、清晰的软件架构软件模块化，减少模块相互依赖防御性编程软件注释软件测试,系统可靠性基本概念,失效率浴盆曲线MTTFMTTRMTBF可用性,可靠性模型,可靠性方框图串联并联串并联组合失效的独立性马尔可夫模型离散马尔可夫模型连续马尔可夫模型其他模型,可靠性预测和评估,硬件可靠性预测软件可靠性预测,形式化方法概要,传统的诸如测试、故障树等检错、纠错和容错技术擅长处理由随机产生、系统老化或系统单部件引起的，而不是由复杂的交互作用引起的故障。它们是在假设系统的设计正确的情况下，对软件、硬件故障进行处理。同时，软件的故障处理主要借鉴于硬件故障处理技术。然而硬、软件的故障性质是有差别的，软件具有离散性，更适合用集合、格、群等数学工具来表达。一种更为严格和客观安全保障方法形式化是指使用离散数学和逻辑学的技术来分析需求、设计和构建计算机系统及其软件，用严格的数学符号和数学法则对目标系统的的结构与行为进行有效的综合分析和推理的方法，它为系统的说明、开发验证提供了一个框架，以利于发现目标系统需求中的不一致、不完整的情况。,形式化方法分类,形式化规范描述顺序系统行为的形式规范方法：典型有Z、B、VDM等。这类方法中状态使用集合、关系和函数等数学结构来表示；状态转移使用前置条件和后置条件来表示。描述并发系统行为的形式规范方法：典型有CSP、CCS、时序逻辑和I/O自动机。这类方法中状态只使用简单的数学类型例如整数或对状态根本没有定义；系统的行为用序列、树或事件的偏序关系来表示。集成的形式规范方法：典型有SDL和RAISE。它们把两种不同的方法结合起来，既能表示复杂的状态类型又能描述并发系统的特性。形式化验证模型检验(modelchecking)：模型检验是对有限状态系统的一种形式化确认方法，具体做法是：采用一种形式语言描述系统的规范说明，构造一种算法来遍历根据系统规范设计的实现模型，确认实现模型是否满足系统的规范说明。由于系统的状态是有限的，所以该算法必然会终止。定理证明：定理证明的原理是：首先我们定义一种数学逻辑，该逻辑系统实际上是一个形式化的系统，由一系列公理和推理规则组成。然后我们用这种数学逻辑分别表示被验证系统和其被期望的特性。所谓定理证明就是从系统的公理出发使用推理规则逐步推导出其所期望的特性的证明过程。证明所需要的步骤依赖于系统的公理和推理规则，在某种程度上也依赖于其派生定义和中间引理。与模型检验不同!定理证明可直接处理无限的状态空间。,形式化方法的开发过程,验证和确认计划,验证和确认人员必须满足独立性要求,动态测试,功能测试结构测试随机测试动态测试技术基于等价类划分的测试案例基于边界值分析的测试案例状态转移测试概率测试基于结构的测试过程仿真猜错播错实时和内存测试性能测试压力测试环境仿真安全性测试,静态分析技术,走查/设计审核检查表形式证明Fagan检查控制流分析数据流分析符号执行度量,建模技术,形式化方法软件原型性能建模状态转移图时间Petri网数据流图结构图环境建模,测试策略,测试覆盖率完备测试不可能语句覆盖率分枝覆盖率组合判定覆盖率等等测试充分性准则基于需求的准则基于结构的准则时间特性测试开销,质量管理,软件工程ISO9001质量管理体系CMM/CMMI软件能力成熟度模型（1-5级）,铁路信号EN标准族,安全性的证据：安全性例证SafetyCase,质量管理报告,组织结构质量计划和程序需求规范设计控制设计验证和评审应用工程采购和生产产品鉴别与可追溯能力处理与贮存检查和测试；,不一致及其更正包装和交货安装和交付使用运行与维护质量监督和反馈文件和记录配置管理/修改控制人员能力与培训质量审计与追踪报告系统退役和处置,系统生命周期,概念,系统定义和应用条件,风险分析,系统需求,系统需求的分配,设计和实现,制造,安装,系统确认（包括安全性验收和交付使用）,系统验收,运行和维护,系统退役和处置,运行监测,修改,重新应用生命周期,安全性生命周期-V形周期,系统需求规格,危险分析和风险评估,安全性需求规格,系统结构设计,硬件设计,软件设计,硬件确认,软件确认,集成和安装测试,功能安全性测试/确认,系统测试确认,安全性功能需求安全性完善度需求,系统性失效完善度随机性失效完善度,质量管理报告安全性管理报告技术安全性报告,测试计划/安排,安全组织,建立一个适当的安全组织使用能胜任工作的职员各自担任明确的角色，不同角色之间应有适当的独立性按公认的标准对职员的能力，包括技术水平、学历、相关经验和适当培训经历必须进行评价并形成文档,不同角色的独立性安排,PM,DES,VER，VAL,ASSR,PM,DES,VER,VAL,ASSR,DES,DES，VER，VAL,VER，VAL,ASSR,ASSR*,或,SIL3和4,SIL1和2,SIL0,安全验证和确认,应验证生命周期的每一阶段能满足前一阶段的安全需求说明应确认已完成的系统/子系统/设备能满足最初的安全需求规范所有验证和确认工作,包括适当的测试和安全性分析工作都必须进行并作完整的记录任何系统/子系统或设备进行修改或扩展以后，都应重复这些工作根据安全权威机构的意见,评估员可以是供应商组织的一部分,也可以是顾客组织的一部分。此时，评估员应：由安全性权威机构认可完全独立于项目团队直接向安全性权威机构报告,不同安全完整性等级的系统和产品设计的验证和确认指南（表E.9）,不同安全完整性等级的系统和产品设计的验证和确认指南（续表E.9）,技术安全性报告的格式,引言功能正确运行的保障故障的影响外界干扰下的运行安全性相关的应用条件安全性合格测试,功能正确运行的保障,包括所有用以表明系统/子系统/设备在无故障正常情况下正确运行、符合规定的运行和安全性需求的证据材料。主要有分以下几个方面：系统结构描述接口定义系统需求规范的实现安全性需求规范的实现硬件功能正确性的保障规定环境条件的实现软件功能正确性的保障,故障的影响,本节应论证系统/子系统/设备持续符合规定的安全性要求，包括在发生随机硬件故障时量化的安全性指标。此外，尽管应用了质量和安全性管理程序,系统故障仍然可能存在，本节应当证实为了使残留风险降至合理且可行的最低水平采用了哪些技术措施。本节还应证实安全性完善度等级低于整个系统的系统/子系统/设备中的故障不会影响整个系统的安全性。主要有分以下几个方面：单一故障的影响部件的独立性单一故障的检测故障检测后的措施(包括安全状态的保持)多重故障的影响系统故障的防护,外界干扰下的运行,应论证在遭受系统需求规范中所论述的外部干扰时，系统/子系统/设备：继续满足规定的功能需求继续满足规定的安全性需求(包括故障情况)安全性例证只在规定范围的外界干扰内有效。在这些限制之外，则没有安全性保证，除非提供附加的特殊措施需完整解释和论证抵御规定的外界干扰的方法,安全性相关的应用条件,规定了系统/子系统/设备应用时应遵守的规则、条件和限制，包括任何相关子系统或设备的安全性案例给出的应用条件,安全性合格测试,应包括说明在运行条件下成功完成安全性合格测试的证据材料,安全性例证分类,通用产品安全性例证(独立于应用)-能被重用于不同独立应用的通用产品通用应用安全性例证(针对一类应用)-能被重用于一类具有共同功能的应用的通用应用特定应用安全性例证(针对特定应用)-仅用于某特定装置的特定应用,安全性认证,安全性评估报告应解释安全性评估员采取的行动，以判明系统/子/系统/设备（硬件和软件）如何设计来满足规定的需求，并规定系统/子系统/设备运行可能需附加的条件。评估的深度和独立程度建立在如EN50126-2所述风险分类的结果上。为了增加置信度，安全性评估员可要求进行特定的测试。整个文档性证据应包括：系统(或子系统/设备)需求规范安全性需求规范安全性例证安全性评估报告一旦安全性案例证明所有安全性验收条件已得到满足并且符合安全性独立评估结果，系统/子系统/设备就通过了相关安全性管理机构的安全性认证。认证包含了满足安全性评估员所提出的附加条件(暂时的或永久的)。,安全性接收和认证过程,系统需求规范,系统需求规范,系统需求规范,安全性需求规范,安全性需求规范,安全性需求规范,通用产品安全性例证第一部分第二部分第三部分