T-SwAr-P安全软件设计概述I1.ppt

信息隐藏/封装（完）适用条件采用模块化开发方法或面向对象开发；软件变更可以预见的限制及问题如果采用面向对象开发，与类继承有冲突相关策略模块化开发方法；面向对象开发方法；其它限制变更传播技术T-SwAr-P安全软件架构设计架构设计策略（第3、4、5和6部分）总结覆盖了8种策略两大设计原则软件多样性与信息隐藏/封装恢复程序块包含软件多样性与向后恢复三种恢复策略向后与向前恢复重试故障恢复包含向后恢复优雅降级与动态重构针对硬件故障引起的软件组件失效动态重构是优雅降级的‘极端’表现T-SwAr-P安全软件架构设计软件架构规范EN50128的规范表达及结构要求完整性一致性清晰性精确性明确性可验证性可测试性可维护性可行性需求跟踪T-SwAr-P安全软件架构设计软件架构规范（续）软件架构视图IEEE1471标准引入视图和视角两个概念EN50128本身没有引入视图这个概念但要求软件架构要识别所有软硬件互动并对分析其接口所有组件（包括既有软件组件）所有故障处理措施现有行业没有对视图数目有统一说法常见有3视图、4+1视图和6视图T-SwAr-P安全软件架构设计软件架构规范（续）软件架构理由同样，适用于IEEE1471标准而不是EN50128但EN50128也明文规定对关于不同的SIL等级相应所选的开发技术、措施及工具提供合理的解释作为最佳实践的一部分，这里的合理解释应该包括当前所选方案符合设计要求的理由曾考虑过其它的可选择方案及被否定的理由决策背后相关的设计权衡研究（如果有的话）决策相关的假设及局限EN50128也要求对软件结构的划分时需考虑到软件架构的规模与复杂性的平衡并提供合理解释T-SwAr-P安全软件架构设计软件架构规范（完）软件架构理由当涉及不同的SIL分配到软件组件时，其不同SIL组件之间的独立性也要提供证据解释如果采用了既有软件例如COTS软件或以前项目开发过的软件，并且该既有软件的安全完整性等级是SIL3/4，其架构理由应包括该既有软件的所有故障模式通过软件错误影响分析相关的故障检测策略例如一致性检查相关的故障处理策略例如重试T-SwAr-P安全软件架构设计软件架构设计实例（续）软件需求规范假定已经建立70%软件需求已经稳定下来T-SwAr-P安全软件架构设计软件架构设计实例（续）第一步输出高风险场景不正确的命令计算方法系统性故障传感器故障随机性故障处理器故障随机性故障硬件更新引起不正确的关键代码修改系统性故障T-SwAr-P安全软件架构设计软件架构设计实例（续）设计第二步设计输入是高风险的故障场景及其它重要质量属性要求找出适用技术措施并决定合理的架构方案识别出合适的设计策略（那就是技术或措施）列出每个策略的适用方面、局限及问题必要时进行设计权衡研究作出架构决定建立架构理由设计输出是架构决定及理由T-SwAr-P安全软件架构设计软件架构设计实例（续）T-SwAr-P安全软件架构设计场景EN50128技术措施适用理由不正确的操舵命令计算防御性编程适用，因为不正确操舵计算可以部分检测出来故障检测适用，因为不正确操舵计算可以部分检测出来多样性编程适用，因为不正确计算可以是人为开发错误引起恢复程序块不适用，因为该软件是时间关键系统向后恢复不适用，因为该软件是时间关键系统向前恢复适用，因为不正确操舵计算部分可以修正重试故障恢复不适用，因为该软件是时间关键系统动态重构不适用，因为没有足够资源支持优雅降级不适用，因为降级也无法使操舵计算正确信息隐藏/封装不适用，因为这不是由软件变更引起架构决定所解决的场景架构理由引入控制软件模块和监控模块：监控模块负责检测控制模块的合理性计算，监控模块与控制模块互相独立开发，并采用不同算法来监控N8，N9，N10，N16，N17，N19与其实现多个软件控制计算版本，这个方案相对便宜而且很有效计算机硬件结构采用2乘2取2N18，N19现在处理器价格较便宜，而且系统的可用性也大大提高引入独立双组LVDT/RVDT传感器N16，N17系统的可用性也提高引入硬件抽象层N20提高系统可维护能力软件架构设计实例（续）设计第三步设计输入是现阶段的架构决定选择软件架构视图并建模基于架构决定选择适用的架构视图假定架构视图分类已预先定好对所选视图进行建模架构决定与建模的联系没有严格的定义对于同样的架构决定，不同人可能有不同的建模方案建模本身的完整性由建模方法及工具来保障设计输出是已建好的架构视图