北京理工大学：《软件可靠性和安全性设计准则》.pdf_大学文库

JB/Z102-97 在结构图中,模块的直接上级模块个数 3.3扇出fan-out 在结构图中模块所属的直接下级模块个数 34功能剖面 functional profile 软件需求分析阶段定义的软件应完成的诸处理任务及其相应执行概率的集合。 35安全关键信息 safety critical information 其错误可能导致系统严重危险的信息。 36安全关键软件 safety critical software 其错误可能导致系统严重危险的软件。 3.7安全关键功能 safety critical function 其错误可能导致系统严重危险的功能 38软件可靠性 software reliability 在规定的条件下和规定的时间内,软件不引起系统故障的能力。软件可靠性不但与软件存在的差错有关,而且与系统输入和系统使用有关。 39软件安全性 software safety 软件运行不引起系统事故的能力一般要求开发高可靠软件首先必须采用软件工程方法,搞好软件开发工程化。应特别注意以下几点 a.软件开发规范化。应按照GJB2786和GJB438A的规定,将软件开发过程分为若千阶段,每个阶段编制必要的文档并进行检查、分析和评审,实行配置管理。图形符号、程序构造及表示应符合GB1526和GB13502的规定; b.尽可能采用先进、适用的软件开发工具,并确保软件开发工具免受计算机病毒侵害; c.加强软件检查和测试。应尽早开展软件检查和测试,采取措施(如自检、互检、专检相结合的“三检制",制定设计检查单等)使检查工作切实有效,软件测试应达到规定的要求。 5详细要求 5.1计算机系统设计 5.1.1硬件与软件功能的分配原则对具有高可靠性和安全性要求的功能,应权衡用硬件实现还是用软件实现的利弊,作出妥善决策 5.1.2硬件与软件可靠性指标的分配原则软件的可靠性指标应与硬件的可靠性指标大体相当,可根据具体情况作适当的调整,但调整不宜过大,并且所分配的指标应能验证。 5.1.3安全关键功能的人工确认在系统控制回路中,安全关键功能的执行在可能时必须经操作人员确认或启动

GJB/Z102-97 5.1.4安全性内核在安全关键的计算机系统中,应当设计一个称为安全性内核的独立计算机程序,用来监视系统并防止系统进入不安全状态。当出现潜在不安全的系统状态或者有可能转移到这种状态时,它将系统转移到规定的安全状态。 5.1.5自动记录系统故障必须采取措施自动记录检测出的所有系统故障及系统运行情况。 5.1.6禁止回避检测出的不安全状态在系统设计时考虑故障的自动检测,一旦检测出不安全状态,系统应作出正确响应,不得回避。 5.1.7保密性设计系统设计应能防止越权或意外地存取或修改软件。 5.1.8容错设计对可靠性要求很高的系统应同时考虑硬件和软件的容错设计,而不能只考虑硬件容错设计 5.1.9安全关键软件的标识原则通常应将在附录B(参考件)中所述的A级和B级软件定为安全关键软件。例如,下述软件应定为安全关键软件 a.故障检测的优先级结构及安全性控制或校正逻辑、处理和响应故障的模块; b.中断处理程序、中断优先级模式及允许或禁止中断的例行程序; c.产生对硬件进行自主控制信号的软件; d.产生直接影响硬件部件运动或启动安全关键功能的信号的软件; 其输出是显示安全关键硬件的状态的软件。 5.2硬件设计嵌入式软件的运行过程与相关系统硬件的运行过程相互交错,密不可分,设计因素相互影响。进行软件可靠性和安全性设计时必须考虑与硬件设计有关的要求。有关硬件的某些设计要求见附录C(参考件)。 5.3软件需求分析 A.软件需求分析必须遵守GJB1091的规定,确保软件需求规格说明的无歧义性、完整性、可验证性、一致性、可修改性、可追踪性和易使用性 b.对安全关键软件,必须列出可能的不期望事件,分析导致这些不期望事件的可能原因, 提出相应的软件处理要求 c.对有可靠性指标的软件,在确定了软件的功能性需求之后,应考虑该软件的可靠性指标是否能够达到以及是否能够验证还应与用户密切配合,确定软件使用的功能剖面,并制定软件可靠性测试计划。 54软件危险分析对安全关键软件,应按照GB900的要求,在软件开发的各个阶段进行有关的软件危险分析

GJB/Z102-97 5.5安全关键功能的设计 a.安全关键功能必须至少受控于两个独立的功能。 b.安全关键的模块必须同其它模块隔离;安全关键的模块必须放在一起,以便对其进行保护安全关键功能必须具有强数据类型;不得使用一位的逻辑“0”或“1”来表示“安全”或危险”状态;其判定条件不得依赖于全“0”或全“1”的输入 d.安全关键的计时功能必须由计算机控制,使操作人员不能随意修改。 e.在启动安全关键功能之前,必须对可测试的安全关键的单元进行实时检测。当检测到不安全的情况时,软件必须采取措施对其进行处理;如软件无法处理这种情况,则应保证将控制转换到硬件的安全子系统。 5.6冗余设计 56.1软件冗余 5.6.1.1考虑失效容限,确定冗余要求一般依据软件安全关键等级,确定软件的失效容限要求,根据软件的失效容限要求,确定软件冗余要求。例如,对于A级软件,推荐的失效容限为2,要进行5版本程序设计;对于B级软件,推荐的失效容限为1要进行3版本程序设计;对于C、D级软件,不考虑失效容限,无需软件冗余。对无法实现N(>2)版本程序设计的安全关键软件,建议采用恢复块技术。 56.1.2N版本程序设计 N版本程序设计由N个实现相同功能的(必要时,在考虑特殊处理后可包括按功能降级设计的)相异程序和一个管理程序组成,各版本先后运算出来的结果相互比较(表决)确定输出。在表决器不能分辨出错模式的情况下,应当采取少数服从多数的表决方式,甚至可以根据系统安全性要求采取“一票否决”的表决方式。 N版本程序设计还可以对每一版本运算的结果增加一个简单接受测试或定时约束的功能,先期取消被证明是错误的结果或迟迟不能到达的结果,以提高表决器的实时性和成功率。要选用各种不同的实现手段和方法来保证版本的强制相异,以减少共因故障。注:仅依靠不同的设计队伍并对其它设计因素不作强制要求而开发的软件称为随机相异软件;不仅依靠不同的设计队伍,而且对方法、手段、工具、模型、语言(或语言的子集)作出强制规定而开发的软件称为强制相异软件 5.6.1.3恢复块软件需求规格说明中应对恢复块作单独的定义和说明。恢复块由一个基本块、若干个替换块(可以是功能降级替换块)和接受测试程序组成。基本工作方式是:运行基本块;进行接受测试,若测试通过,则输出结果;否则,调用第一个替换块,再进行接受测试;……;若在第N个替换块用完后仍未通过接受测试,便进行出错处理。 5.62信息冗余 a.安全关键功能应该在接到两个或更多个相同的信息后才执行。 b.对安全关键信息,应保存在多种或多个不同芯片中,并进行表决处理 c,对可编程只读存储器(PROM)中的重要程序进行备份(例如,备份在不同的PROM

GJB/Z102-97 中),万一PROM中的程序被破坏,还可通过遥控命令等手段使系统执行其备份程序。 d.对随机存取存储器(RAM)中的重要程序和数据,应存储在三个不同的地方,而访问这些程序和数据都通过三取二表决方式来裁决。 5.7接口设计 5.7.1硬件接口要求 a.CPU之间的通讯必须在数据传输之前对数据传输通道进行正确性检测。建议实施定期检测,以确保数据传输的正确性。 b需要从接口软件中得到两个或更多安全关键信息的外部功能不得从单一寄存器或从单一输入/输出(I/O)端口接受所有的必要信息,而且这些信息不得由单一CPU命令产生。 c,对于所有模拟及数字输入输出,在根据这些值采取行动之前,必须先进行极限检测和合理性检测。 5.7.2硬件接口的软件设计 a.硬件接口的软件设计必须考虑检测外部输入或输出设备的失效,并在发生失效时恢复到某个安全状态。设计必须考虑所涉及硬件的潜在失效模式 b.在设计硬件接口的软件时,必须预先确定数据传输信息的格式和内容。每次传输都必须包含一个字或字符串来指明数据类型及信息内容。至少要使用奇偶校验与检验和来验证数据传输的正确性。 c.在硬件接口的软件设计中必须考虑硬件接口中已知的元器件失效模式。 d.安全关键功能应使用专用I/O端口,并使这种I/O端口与其它I/O端口有较大区别。 57.3人机界面设计 a.人机交互软件要便于操作员用单一行为处理当前事务,使系统退出潜在不安全状态, 并恢复到某一安全状态。 b.在启动安全关键功能时,必须由两个或多个人员在“与”方式下操作,并有完善的误触发保护措施,以避免造成无意激活。例如,在启动某个安全关键功能时,最少应由两个不同按键来启动,并且在设计这两个按键时,应使这两个按键在操作键盘或操作面板上保持一定的距离,以免误触发。两个操作员应独立地、最好在不同的操作键盘或操作面板上同时启动,且一个操作员不能同时启动也不能采取措施强迫另一操作员启动。 c.向操作员提供的显示信息、图标、及其它人机交互方式必须清晰、简明、且无二义性 5.7.4报警设计 a.必须向操作员提供声光报警,声音报警信号必须超过预期的背景噪声,并同时提供表明软件正在操作的实时指示。要求几秒钟或更长时间的处理功能在处理期间必须向操作员提供一个状态指示。 b.报警的设计必须使例行报警与安全关键的报警相区别,并应使得在没有采取纠正行为或没有执行所要求的后续行为以完成该操作的情况下,操作员无法清除安全关键的报警。 5.7.5软件接口设计在设计软件接口时必须确保 a.模块的参数个数与模块接受的输入变元个数一致;

GJB/Z102-97 b.模块的参数属性与模块接受的输入变元属性匹配; c.模块的参数单位与模块接受的输入变元单位一致; d.模块的参数次序与模块接受的输入变元次序一致; e.传送给被调用模块的变元个数与该模块的参数个数相同; f.传送给被调用模块的变元属性与该模块参数的属性匹配; g.传送给被调用模块的变元单位与该模块参数的单位一致; h.传送给被调用模块的变元次序与该模块参数的次序一致; i.调用内部函数时,变元的个数、属性、单位和次序正确 j.不会修改只是作为输入值的变元 k.全程变量在所有引用它们的模块中都有相同的定义; 1.不存在把常数当作变量来传送的情况。 5.8软件健壮性设计 581配合硬件进行处理的若干设计考虑 5.8.1.1电源失效防护软件要配合硬件处理在加电的瞬间电源可能出现的间歇故障,避免系统潜在的不安全初始状态;在电源失效时提供安全的关闭;在电源的电压有波动时,使它不会产生潜在的危险 5.8.1.2加电检测软件设计必须考虑在系统加电时完成系统级的检测,验证系统是安全的并在正常地起作用;在可能时软件应对系统进行周期性检测,以监视系统的安全状态。 5.8.1.3电磁干扰对于电磁辐射、电磁脉冲、静电干扰,以及在太空中使用的计算机可能遇到的宇宙重粒子的冲击,硬件设计应按规定要求将这些干扰控制在规定的水平之下,软件设计要使得在出现这种干扰时,系统仍能安全运转。 5.8.1.4系统不稳定若某些外来因素使系统产生不稳定,不宜继续执行指令,软件应采取措施,等系统稳定后再执行指令。例如,具有强功率输出的指令所引发的动作对系统或计算机系统的稳定性有影响,软件应使计算机在该指令输出并等系统稳定后,再继续执行指令。 58.1.5接口故障应充分估计接口的各种可能故障,并采取相应的措施。例如软件应能够识别合法的及非法的外部中断,对于非法的外部中断,软件应能自动切换到安全状态。反馈回路中的传感器有可能出故障并导致反馈异常信息,软件应能预防将异常信息当作正常信息处理而造成反馈系统的失控。同样,软件对输入、输出信息进行加工处理前,应检验其是否合理(最简单的方法是极限量程检验)。 5.8.1.6千扰信号对被控对象的变化信号中伴同存在的干扰信号采用数字滤波器加以过滤时,采样频率的确定不仅要考虑有用信号的频率,而且要考虑千扰信号的频率。 58.1.7错误操作 6

GJB/Z102-97 软件应能判断操作员的输入操作正确(或合理)与否,并在遇到不正确(或不合理)输入和操作时拒绝该操作的执行,并提醒操作员注意错误的输入或操作同时指出错误的类型和纠正措施。 58.2监控定时器的设计 a.必须提供监控定时器或类似措施,以确保微处理器或计算机具有处理程序超时或死循环故障的能力。 b.监控定时器应力求采用独立的时钟源,用独立的硬件实现;若采用可编程定时器实现, 应统筹设计计数时钟频率和定时参数力求在外界干扰条件下定时器受到干扰后定时参数的最小值大于系统重新初始化所需的时间值,最大值小于系统允许的最长故障处理时间值。 c.与硬件状态变化有关的程序设计应考虑状态检测的次数或时间,无时间依据的情况下可用循环等待次数作为依据,超过一定次数作超时处理。 583异常保护设计必须仔细分析软件运行过程中各种可能的异常情况,设计相应的保护措施。特别当采用现成软件时,必须仔细分析原有的异常保护措施对于现有的软件需求是否足够且完全适用。异常处理措施必须使系统转入安全状态,并保持计算机处于运行状态。 59简化设计 5.9.1模块的单入口和单出口除中断情形外,模块应使用单入口和单出口的控制结构 5.9.2模块的独立性模块的独立性,应以提高内聚度,降低耦合度来实现,设计时必须遵循下述准则 a.采用模块调用方式,而不采用直接访问模块内部有关信息的方式; b.适当限制模块间传递的参数个数; c,模块内的变量应局部化; d将一些可能发生变化的因素或需要经常修改的部分尽量放在少数几个模块中 593模块的扇入扇出在设计软件时,将模块在逻辑上构成分层次的结构,在不同的层次上可有不同的扇入扇出数。模块的实际结构形态应满足下述准则 ,模块的扇出一般应控制在7以下 b为避免某些程序代码的重复,可适当增加模块的扇入; c.应使高层模块有较高的扇出,低层模块有较高的扇入 594模块的耦合方式根据GJB2255的规定,模块间耦合的方式有五类,按其优选顺序排列如下 a.数据耦合; b.控制耦合; c.外部耦合 d.公共数据耦合; 内容耦合