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.模块的参数个数与模块接受的输入变元个数一致;