GJBZ 102-1997 软件可靠性和安全性设计准则

代码说明：

GJBZ 102-1997 软件可靠性和安全性设计准则 评审文件可以借鉴相关内容附录B推荐的软件安全关键程度分级(参考件)………附录C有关硬件的某些设计要求(参考件)…………(18)中华人民共和国国家军用标准软件可靠性和安全性设计准则GJB/102一97Software reliability and safety design criteria1范主题内容本指导性技术文件给出了计算机软件可靠性和安全性设计的准则和要求。1.2适用范围本指导性技术文件主要适用于式器装备嵌入式软件的需求分析、设计和实现。其它软件亦可参照执行。13应用指南应用本指导性技术文件时需根据软件的具体情况加以剪裁。附录A(参考件)给出了软件开发过程有关阶段应考虑的相应内容。2引用文件GB1526-89信息处理数据流程图、程序流程图程序网络图和系统资源图的文件编制符号及约定GB/T11457-1995钦件工程术语GB13502-92信息处理程序构造及其表示的约定GB438A-97武器系统软件文档编制格式和要求GJB900-90系统安全性通用大纲GJB1091-91军用软件需求分析UB1389-92系统电磁兼容性要求GJB2255-94军用软件产品GJB2786-96武器系统软件开发3定义本指导性技术文件除采用GB/T11457定义的术语外,还采用如下定义的术语。3.1失效容限 failure- tolerance系统承受规定数目规定级别失效的能力32扇入fan-in国防科学技术工业委员会1997-11-05发布1998-05-01实施GB/2102-97在结构图中,模块的直接上级模块个数。3.3扇出fan-out在结构图中,模块所属的直接下级棋块个数34功能剖面 functional profile敏件需求分析阶段定义的敦件应完成的诸处理任务及其相应执行概率的集合35安全关键信息 safety critical information其错误可能导致系统严重危险的信息。36安全关键软件 safety critical software其错误可能导致系统严重危险的软件。3.7安全关键功能saet! critical function其错误可能导致系统严重危险的功能38软件可靠性 software reliability在规定的条件下和规定的时间内软件不引起系统故障的能力。软件可靠性不但与软件存在的差错有关,而且与系统输入和系统使用有关。3.9软件安全性9 oftware safety软件运行不引起系统事故的能力。4一般要求开发高可靠软件首先必须果用钦件工程方法,搞好软件开发工程化,应特别注意以下几点a.软件开发规范化。应按照GJB2786和GJB438A的规定,将软件开发过程分为若千阶段,每个阶段编制必要的文档并进行检查、分析和评审,实行配置管理。图形符号、程序构造及表示应符合GB1526和GB13502的规定;b.尽可能采用先进适用的软件开发工具,并确保软件开发工具免受计算机病毒侵害;c.加强软件检查和测试。应尽早开展软件检查和测试,采取指施(如自检、互检、专检相结合的“三检制”制定设计检查单等)使检查工作切实有效,软件测试应达到规定的要求。5详细要求5.1计算机系统设计5.1.1硬件与软件功能的分配原则对具有高可性和安全性要求的功能,应权衡用硬件实现还是用软件实现的利弊,作出妥善决策。5.1.2硬件与软件可靠性指标的分配原则软件的可靠性指标应与硬件的可靠性指标大体相当,可根据具体情况作适当的调整,但调整不宜过大,并且所分配的指标应能验证。5.1.3安全关键功能的人工确认在系统控制凹路中,安全关镄功能的执行在可能时必须经操作人员确认或启动。GJB/2102-975.1.4安全性内核在安全关健的计算机系统中,应当设计一个称为安全性内核的独立计算机程序,用来监视系统并防止系统进入不安全状态。当出现潜在不安全的系统状态或者有可能转移到这种状态时,它将系统转移到规定的安全状态。5.1.5自动记录系统故障必须采取措施自动记录检测出的所有系统故障及系统运行情况。5.1.6禁止回避检测出的不安全状态在系统设计时考虑故障的自动检测,一旦检测出不安全状态,系统应作出正确响应,不得回避。5.1.7保密性设计系统设计应能防止越权或意外地存取或修改软件5,18容错设计对可靠性要求很高的系统应同时考虑硬件和软件的容错设计,而不能只考虑硬件容错设5.1.9安全关键软件的标识原则通常应将在附录B(参考件)中所述的A级和B级软件定为安全关键软件。例如,下述软件应定为安全关键软件庭.故障检测的优先级结构及安全性控制或校正逻辑、处理和响应故障的模块;b.中断处理程序、中断优先级模式及允许或*止中断的例行程序c.产生对硬件进行自主控制信号的*件;生直接影响硬件部件运动或启动安全关键功能的信号的软件e,其输出是显示安全关键硬件的状态的软件5.2硬件设计嵌入式软件的运行过程与相关系统硬件的运行过程相互交错,密不可分,设计因素相互影响。进行软件可靠性和安全性设计时必须考虑与硬件设计有关的要求。有关硬件的某些设计要求见附录C(参考件)。53软件需求分析且,软件霱求分析必须遵守OB1091的规定,确保软件需求规格说明的无歧义性完整性、可验证性、一致性、可修改性、可追踪性和易使用性b.对安全关键软件,必须列出可能的不期望事件,分析导致这些不期芽事件的可能原因,提出相应的软件处理要求。c,对有可靠性指标的软件,在确定了软件的功能性需求之后,应考虑该软件的可靠性指标是否能够达到以及是否能够验证还应与用户密切配合,确定软件使用的功能剖面,并制定软件可靠性测试计划。54软件危险分析对安全关键软件,应按照GJB900的要求,在软件开发的各个阶段进行有关的软件危险分析CJB/L102-975.5安全关键功能的设计a.安全关键功能必须至少受控于两个独立的功能。b.安全关键的模块必须同其它棋块隔离:安全关键的模块必须放在一起,以便对其进行保护。c,安全关键功能必须具有强数据类型;不得使用一位的逻辑“q”或“1来表示“安全”或危险”状态;其判定条件不得依赖于全“0”或全“1”的输入。d.安全关键的计时功能必须由计算机控制,使操作人员不能随意修改。e.在启动安全关键功能之前,必须对可测试的安全关键的单元进行实时检测。当检测到不安全的情况时,软件必须采取措施对其进行处理;软件无法处理这种情况,则应保证将控制转换到硬件的安全子系统。56冗余设计5.6.1软件冗余5.6.1.考虑失效容限,确定冗余要求般依据软件安全关键等级,确定软件的失效容限要求,根据软件的失效容限要求,确定软件冗余要求。例如,对于A级软件,推荐的失效容限为2,要进行5版本程序设计;对于B级软件,推荐的失效容限为1要进行3版本程序设计;对于C、D级软件,不考虑失效容限,无需软件冗余。对无法实现N(>2)版本程序设计的安全关健软件,建议采用恢复块技术。56.12N版本程序设计N版本程序设计由N个实现祁同功能的(必要时,在考虑特殊处理后可包括按功能降级设计的)相异程序和一个管理程序组成,各版本先后运算出来的结果相互比较表决)确定输出。在表决器不能分辨岀错模式的情况于,应当采取少数服从多数的表决方式,甚至可以根据系统安全性要求采取“一票否决”附表决方式。N版本程序设计还可以对每一版本运算的结果增加一个简单接受测试或定时约束的功能,先期取消被证明是错误的结果或迟迟不能到达的结果,以提高表决器的实时性和成功率。要选用各种不同的实现手段和方法来保证版本的强制相异,以减少共因故障。注:仅依靠不同的设计队伍并对其它设计因素不作强制要求而开发的软件称为随栈相异软件不仅依靠不同的设计驮伍,而且对方法、手段、工具、模型语言或语言的子集)作出强制规定而开发的软件称为强制相异软件。5.6.1.3恢复块软件需求规格说明中应对恢复块作单独的定义和说明。恢复块由一个基本块、若千个替换块(可以是功能降级替换块)和接受测试程序组成。基本工作方式是:运行基本块;进行接受测试,若测试通过,则输出结果;否则,调用第一个替换块,再进行接受测试;……;若在第N个替换块用元后仍未通过接受测试,便进行出错处理5.62信息冗余a.安全关键功能应该在接到两个或更多个相的信息后才执行。b.对安全关键信息,应保存在多种或多个不同芯片中,并进行表决处理。c.对可编程只读存储器(PROM)中的重要程序进行备份(例如,备份在不同的PROMGJB/Z102-97中)万一PROM中的程序被破坏,还可通过遥控命令等手段使系统执行其备份程序。d.对随机存取存储器(RAM中的重要程序和数据,应存储在三个不同的地方,而访问这些程序和数据都通过二取二表决方式来裁决。5.7接口设计5.7.1硬件接口要求a.CPU之间的通讯必须在数据传输之前对数据传输通道进行正确性检测。建议实施定期检测,以确保数据传输的正确性。b需要从接口软件中得到两个或更多安全关键信息的外部功能不得从单一奇存器或从单一输入/输出(O)端口接受所有的必要信息,而且这些信息不得由单一CPU命令产生。c.对于所有模拟及数字输入输出,在根据这些值采取行动之前,必须先进行极限检测和合理性检测。5.7.2硬件接口的软件设计a.硬件接口的软件设计必须考虑检测外部输入或输出设备的失效,并在发生失效时恢复到某个安全状态。设计必须考虑所涉及硬件的潜在失效模式。b,在设计硬件接口的软件时,必须预先确定数据传输信息的格式和内容。每次传输都必须包含一个字或字符串来指明数据类型及信息内容。至少要使用奇偶校验与检验和来验证数据传输的正确性。c.在硬件接的软件设计中必须考虑硬件接口中已知的元器件失效模式。d.安全关键功能应使用专用I/O端口,并使这种[/O端囗与其它I/O端门有较大区别。5.7.3人机界面设计a.人机交互软件要便于操作员用单一行为处理当前事务,使系统退出潜在不安全状态,并饮复到某一安全状态。b.在启动安全关键功能时,必频由两个或多个人员在“与”方式下操作,并有完善的误触发保护措施,以避免造成无意激活。例如,在启动某个安全关键功能时,最少应由两个不同按键来启动,并且在设计这两个按键时,应使这两个按键在操作键或操作面板上保持一定的距离,以免误触发。两个操作员应独立地、最好在不同的操作键盘或操作面板上同时启动,且一个操作员不能同时启动也不能采取施强迫另一操作员启动。C.向操作员提供的显示信息、图标及其它人机交互方式必须清晰简明、且无二义性5.7.4报警设计a.必须向操作员提供声光报警,声音报警信号必预超过预期的背景噪声,并同时提供表明软件正在操作的实时指示。要求几秒钟或更长时间的处理功能在处理期间必须向操作员提供一个状态指示。b.报警的设计必须使例行报警与安全关键的报警相区别,并应使得在没有采取纠正行为或没有执行所要求的后续行为以完成该操作的情况下,操作员无法清除安全关键的报警5.7.5软件接口设计在设计软件接口时必须确保a.模块的参数个数与模块接受的输入变元个数一致;GJB/Z102-97b.模块的参数属性与模块接受的输入变元属性匹配;c.模块的参数单位与模块接受的输入变元单位一致;d.模块的参数次序与模块接受的输人变元次序一致;传送给被调用模块的变元个数与该模块的参数个数相同;f.传送给被调用模块的变元属性与该模块参数的属性匹配;g.传送给被调用模块的变元单位与该模块参数的单位一致h,传送给被调用模块的变元次序与该模块参数的次序一致;i.调用内部函数时,变元的个数属性、单位和次序正确;i.不会修改只是作为输入值的变元;k.全程变量在所有引用它们的模块中都有相同的定义;.不存在把常数当作变量来传送的情况58软件健壮性设计58.1配合硬件进行处理的若干设计考虑5.8.1.1电源失效防护软件要配合硬件处理在加电的瞬间电源可能出现的间歇故障,避免系统潜在的不安全初始状态;在电源失效时提供安全的关闭;在电源的电压有波动时,使它不会产生潜在的危险。5.8.1.2加电检测软件设计必须考虑在系统加电时完成系统级的检测,验证系统是安全的并在正常地起作用;在可能时软件应对系统进行周期性检测,以监视系统的安全状态。5.8.1.3电磁千扰对于电磁辐射、电磁脉冲、静电千扰,以及在太空中使用的计算机可能遇到的字宙重粒子的冲击,件设计应按规定要求将这些干扰控制在规定的水平之下,软件设计要使得在出现这种干扰时,系统仍能安仝运转。58.14系统不稳定若某些外来因素使系统产生不稳定,不宜继续执行指令,软件应采取措施,等系统稳定后再执行指令。例如,具有强功率输出的指令所引发的动作对系统或计算桃系统的稳定性有影响,软件应使计算机在该指令输出并等系统稳定后,再继续执行指令。58.1.5接口故障应充分估计接口的各种可能故障,并采取相应的措施。例,软件应能够识别合法的及非法的外部中断,对于非法的外部中断,软件应能自动切换到安全状态。反馈回路中的传感器有可能出故障并寻致反馈异常信息,软件应能预防将异信总当作正常倍息处理而造成反馈系统的失控。同样,软件对输入、输出信息进行加工处理前,应检验其是否合理(最简单的方法是极限量程检验)。5.8.1.6千扰信号对被控对象的变化信号中伴同存在的于扰信号采用数字滤波器加以过滤时,采样频率的确定不仅要考虑有用信号的频率,而且要考虑干扰信号的频率。5.8.1.7错误操作GIB/Z102-97软件应能判断操作员的输入操作正确(或合理)与否,并在遇到不正确(或不合理)输入和操作时拒绝该操作的执行,并提醒操作员注意错误的输入或操作,同时指出错误的类型和纠正措施。58.2监控定时器的设计a.必须提供监控定时器或类似措施,以确保徽处理器或计算机具有处理程序超时或死循环故障的能力。b.监控定时器应力求采用独立的时钟源,用独立的硬件实现;若采用可编程定时器实现应统筹设计计数时钟率和定时参数,力求在外界平扰条件下定时器受到干扰后定时多数的最小值大于系统重新初始化所需的时间值,最大值小于系统允许的最长故障处理时间值。c.与硬件状态变化有关的程序设计应考虑状态检测的次数或时间,无时间依据的情况下可用循环等待次数作为依据,超过一定次数作超时处理。58.3异常保护设计必须仔细分析软件运行过程中各种可能的异常情况,设计相应的保护措施。特别当采用现成软件时,必须仔细分析原有的异常保护措施对于现有的软件需求是否足够且完全适用。异常处理揩施必狮使系统转入安全状态,并保持计算机处于运行状态。59简化设计59.1模块的单入口科单出口除中断情形外,模块应使用单入口和单出口的控制结构。5.9,2模块的独立性模块的独立性,应以提高内聚度,降低耦合度来实现,设计时必须遵循下述准则:a.采用模块调用方式,而不采用直接访问模块内部有关信息的方式;b.适当限制模块间传递的参数↑数;c模块内的变量应局部化;d.将一些可能发生变化的因索或需要经常修改的部分尽量放在少数几个模块中9.3模块的扇入扇出在设计软件时,将模块在逻辑上构减分层次的结构在不同的层次上可有不同的扇入扇出数。模块的实际结构形态应满足下述准.模块的扇出一般应控制在7以下;b.为避免某些程序代码的重复,可适当增加棋块的扇入;应使高层模块有较高的扇出,低层模块有较高的扇入。594模块的藕合方式根据GB2255的规定,模块间耦合的方式有五类,按其优选顺序排列如下a.数据耦合;b.控制耦合;c,外部耦合;d.公共数据耦合;e.内容耦合。