软件工程课件 09关键系统规格说明.ppt

1、关键系统规格说明,Critical Systems Specification,关键系统规格说明,开发一个系统可获性，可靠性，安全性和保密性的规格说明的过程和技术 （Processes and techniques for developing a specification for system availability, reliability, safety and security）,Objectives,说明如何通过分析关键系统所面临的风险来识别出系统的可信度需求。 说明如何从系统的风险分析中获得安全需求。 解释保密性需求的来历。 描述用作可靠性规格说明的测量尺度。,Topics c

2、overed,基于风险驱动的规格说明 安全性规格说明 保密性规格说明 软件可靠性规格说明,可信度需求,用功能需求来定义差错检查、恢复工具和对系统失效的防范措施。 用非功能需求来定义系统所需要的可获性和可靠性。 用排它需求来定义千万不能发生的状态和条件。,基于风险驱动的规格说明,关键系统的规格说明应该是由风险驱动的（ risk-driven ）。 该方法已经在安全和保密性至关重要的系统上广泛使用。 规格说明过程的目标应该在于了解系统所面临的风险以及说明降低这些风险的需要做的事情。,风险分析的步骤,风险识别（Risk identification） 识别出可能发生的潜在风险。 风险分析和分类（Ri

3、sk analysis and classification） 评估每个风险的严重程度 风险分解（Risk decomposition） 找出风险的潜在根源 降低风险评估（Risk reduction assessment） 说明在系统设计阶段如何消除和降低每一个风险。,基于风险的规格说明,风险识别,识别出关键系统所面临的风险。 在安全性关键的系统中，风险就是那些能够导致意外的危险。 在保密性关键的系统中，风险就是那些对系统的潜在攻击。 在风险识别中，需要识别出风险的类型及风险在这些分类中的地位 服务失效； 电气上的风险； ,胰岛素泵的风险,胰岛素过量（服务失效）。 胰岛素剂量不足（服务失效）

4、。 由于电池耗尽引起的电源故障（电气的） 与其它医疗设备的电气接口（电气的）。 传感器和致动器的接触很差（物理的）。 在体内的机器部件脱落（物理的）。 由于引入机器而导致感染（生物的）。 对原料或胰岛素的过敏反应（生物的）。,风险分析和分类,包含对发生一个风险的可能性以及对将要发生的一个意外或事故的潜在后果的理解 把风险分类为： 不可接受的（Intolerable）。必须不能让它发生或不能让它引起一个意外。 在实际许可下尽可能低的（ALARP）。在给定成本和进度的限制下，必须使风险的可能性降到最小。 可以接受的（Acceptable）。风险的后果是可以接受的，并且不需要付出额外的成本来降低危险

5、的可能性。,风险级别,风险的社会接受度,一个风险的接受度是被社会和政治的因素所左右的。 在大多数社会而言，随着时间的推移，上面的三角形区域中的两条边界会逐渐向上靠，也就是说，社会越来越不愿意接收风险 例如，虽说清除污染的成本可能会小于预防成本，但这可能不为社会所接受。 风险评估是主观的 风险被认定为类似于“大概的”，“可能的”等等。这取决于由谁来进行评估。,风险评估,评估风险的可能性和严重程度。 通常不可能很精确，因此用一些相对值表达，例如“不太可能的”、“很少的”、“很高的”等等。 目标是排除那些最有可能发生的或者是后果严重的风险。,胰岛素泵的风险评估,风险分解（decomposition）

6、,在一个特定的系统里，找出风险的主要原因（root causes） 技术大多来源于安全性关键的系统，并可以是： 归纳法（Inductive），自下而上的技术。从提出的一个系统失效开始，评估由该失效可能导致的危险。 演绎法（Deductive），自上而下的技术。以一个危险为起点，推断出可能引起它原因是什么。,失误-树（Fault-tree）分析,一种自上而下的演绎法技术。 把风险或危险放在树的根上，再找出可以导致该危险的系统状态。 在合适的地方加入and 或 or条件。 目标应该是使引起系统失效的单一原因（single causes）的数量降至最低。,胰岛素泵的失误-树,降低风险的评估,这个过程

7、的目标是识别出可信度需求，即说明应该如何管理风险以及确保不会发生意外和事故。 降低风险的策略（strategies） 风险规避（Risk avoidance）； 风险检测与排除（Risk detection and removal）； 危害限制（Damage limitation）。,策略应用（Strategy use）,通常在关键系统上要综合使用降低风险的策略。 在一个化工厂的控制系统中，它含有检测和校正反应器过压的传感器。 然而，它也含有一个单独的保护系统，以便在检测到危险高压后打开某个安全阀（relief valve）。,胰岛素泵的软件风险,算术误差（Arithmetic error）

8、一个计算导致一个变量值上溢（overflow）和下溢（underflow）； 可能包含一个对每类算术误差的例外句柄（exception handler）。 算法误差（Algorithmic error） 把将要分发的剂量与前次剂量或与安全最小剂量进行比较。如果剂量太高则要降低它。,胰岛素泵的安全需求,SR1：每次注射剂量不能超过系统用户的指定最大量。 SR2：每天注射的累计剂量不能超过系统用户的指定最大量。 SR3：系统应该含有一个硬件诊断设施，每小时至少执行4次。 SR4：系统应该含有一个可以针对所有已经识别的例外的处理程序。 SR5：当发现任何硬件和软件的异常以及收到诊断信息的时候，发出声

9、音警报。 SR6：在系统警报时，胰岛素注射应该中止，直到用户消除警报和进行系统复位为止。,安全性规格说明,一个系统的安全性需求应该分别进行说明。 这些需求应该建立在对风险和对可能发生的危险的分析基础上。 安全性需求通常被应用于一个系统的整体而不是个别的子系统。在系统工程术语中，一个系统的安全性是一种自然特性（emergent property）。,国际电工委员会标准(IEC 61508),是一项专门为保护系统而设计的安全管理国际标准，它并不适用于所有的安全性关键的系统。 它结合了一个安全生命周期模型，涵盖了从范围定义到系统退役的所有安全管理的方面。,控制系统的安全需求,Ian Sommervi

10、lle 2000Dependable systems specification Slide 26,安全生命周期,安全性需求,功能安全性需求（Functional safety requirements） 这些需求定义了保护系统的安全功能，即定义了系统应该提供什么样的保护。 安全完整性需求（Safety integrity requirements） 这些需求定义了保护系统的可获性和可靠性。它们以预期的用法为基础并且采用从一至四个安全完整性级别进行分类。,保密性规格说明,与安全性规格说明有些相似 对保密性需求进行定量规格说明是不可能的； 需求常常用“不应该”而不是用“应该”来描述。 差别 对一

11、个保密性管理的生命周期还没有定义完备的观念。它没有标准； 只有一般性的威胁而没有系统特定的危险； 具有成熟的保密技术（加密，等等）。然而，当把这些技术转化到一般性的用途上的时候就会出现问题； 单独的供应商（微软）的主导地位意味着大量的系统可能会受到保密性失效的影响。,保密性规格说明过程,保密性规格说明步骤,财产识别和估值 识别出财产（数据和程序）和它们所需要的保护程度。保护程度依赖于财产的价值，因此一个密码文件要比一组公共网页更有价值。 威胁分析和风险评估 要识别出可能发生的保密性威胁，并要估计到与每个这种威胁有关的风险。 威胁分配 把已经识别的威胁与财产联系起来，这样就可以就每个已经识别的财

12、产列出一张与威胁关联的表格。,Stages in security specification,技术分析 对获得的保密技术及其是否可用在识别出的威胁上进行评估。 保密性需求规格说明 要对保密性需求进行规格说明。在规格说明中适当的地方，要明确解释保密技术用在保护系统免受各种不同威胁的作用。,保密性需求的种类,Identification requirements. 识别需求。 Authentication requirements. 鉴定需求。 Authorization requirements. 授权需求。 Immunity requirements. 免疫需求（抗病毒性）。 Integri

13、ty requirements. 完整性需求。 Intrusion detection requirements. 侵入检测需求。 Non-repudiation requirements. 非否定需求。 Privacy requirements. 隐匿需求。 Security auditing requirements. 保密审计需求。 System maintenance security requirements. 系统维护保密性需求。,LIBSYS 保密性需求,系统可靠性规格说明,硬件可靠性（Hardware reliability ） 硬件组件失败的可能性有多大以及修复该组件需要多长

14、时间？ 软件可靠性（Software reliability ） 一个软件组件产生不正确的输出的情况是怎样的。软件和硬件失效的区别在于软件是没有损耗的。即使是在产生不正确的结果之后它也能继续运行。 操纵员可靠性（Operator reliability ） 一个系统操作员出差错（make an error）的情况是怎样的？,功能可靠性需求举例,需要定义出操作员全部输入值的预定范围，系统应该对所有落在该预定范围的操作员输入值进行检查。 在系统初始化的时候，它应该对所有磁盘上的坏块进行检查。 系统必须用N版本编程方法来实现减速控制系统。 系统必须才用Ada安全子集来实现，并用静态分析方法进行检查。

15、,系统可靠性所需要达到的水平必须能够定量表达出来。 可靠性是动态的系统特性，与源代码有关的可靠性规格说明是没有意义的。 每1000行的失误数目不大于N个； 它只对软件交付后的过程分析有用。那时你可以试着对你的开发技术有多好做出评价。 需要选择合适的可靠性标尺来说明整个系统的可靠性。,非功能可靠性规格说明,可靠性标尺是系统可靠性的测量单位。 系统可靠性测量是通过计算操作失效次数来实现的。并且在适当的地方，还要把测量与加在系统上的要求和系统已经运行了多长的时间联系起来。 评估关键系统的可靠性需要一个长期的测量计划。,可靠性标尺(metrics),可靠性标尺(metrics),请求失效率POFOD(

16、Probability of failure on demand) 当发出一个服务请求时系统失效的可能性。例如，0.001的响应失效率意味着1000次服务请求中有一次可能会失效 失效发生率ROCOF(Rate of failure occurrence) 出现未预期行为的发生概率。例如，2/100的失效发生率的意思是指在每100个操作时间单位里可能会失效2次。有时也把它称为失效强度。 失效平均时间MTTF(Mean time to failure) 观察到系统失效的平均时间。例如一个500MTTF的意思是在每500个时间单位里可能有一次失效。 修复平均时间MTTR(Mean time to r

17、epair) 从一个系统失效到它恢复服务的平均时间 可获率AVAIL(Availability) 在一个给定时间内系统可以获得使用的概率。例如，一个0.998的可获率意味着在每1000个时间单位里系统可以获得998个。,请求失效率（POFOD),这是系统在接到服务请求时失效的几率。这对于服务请求不连续和比较稀少的情况来说是有用的。 适合于保护系统，其中的服务请求偶尔发生并且如果不交付服务可能会产生严重后果。 相应于许多具有例外管理组件的安全性关键系统 一个化工厂里的紧急关闭系统。,失效发生率（ROCOF）,反映系统失效的发生比率。 失效发生率等于0.002 意味着在每1000个操作时间单位里可

18、能有2次失效。例如1000小时的运行失效2次。 相对于操作系统或事务处理系统而言，其中系统要频繁处理大量的类同的请求 信用卡处理系统，航线预定系统。,失效平均时间(MTTF),是观察到系统失效的相隔时间度量。对稳定的系统来说，它是失效发生率的倒数。 失效平均时间等于500意味着失效相隔的平均时间是500个时间单位。 对应于长时交易系统，即系统处理要很长时间。失效平均时间应该大于交易时间 计算机辅助设计系统，其一个设计者要用好几个小时进行设计工作，还有文字处理器系统。,可获率（AVAIL）,系统可以获得使用所占的时间比率值。 计入修复和重新启动系统的时间。 可获率等于0.998意味着在1000个

19、时间单位里有998个是可获得的。 对应于不中断的、连续运行的系统 电话交换系统、铁路信号灯系统。,非功能需求规格说明,可靠性测量没有考虑到失效的后果。 瞬时失误可能没有什么实际后果，但除此之外的其它失误却可能导致数据损失或毁坏，甚至使系统不服务。 有必要区别不同的失效类型并对每种类型采取不同的测量标准。一定要构建好可靠性规格说明。,失效后果,在对可靠性进行规格说明的时候，不仅要考虑系统失效的数目，而且要考虑这些失效的后果。 很显然，失效的后果远比能够修正和恢复的那部分损害要大得多。 因此，在某些情况下要针对不同的失效类型定义不同的可靠性规格说明。,失效分类（Failure classification）,对每个子系统，分析可能发生的系统失效结果。 通过系统失效分析，把失效划分成适当的类型。 对分出的每种失效类型，采用合适的测量标准来测定可靠性。可以用不同的标准针对不同的可靠性需求。 识别功能可靠性需求以降低严重失效的发生机会。,可靠性规格说明步骤,银行自动出纳系统,每台在网络上的机器每天使用300