嵌入式软件可靠性设计规范Word文件下载.docx
《嵌入式软件可靠性设计规范Word文件下载.docx》由会员分享，可在线阅读，更多相关《嵌入式软件可靠性设计规范Word文件下载.docx（25页珍藏版）》请在冰点文库上搜索。
9、 软件健壮性设计 11
9.1、 电源失效防护 11
9.2、 加电检测 11
9.3、 电磁干扰 11
9.4、 系统不稳定 12
9.5、 接口故障 12
9.6、 干扰信号 12
9.7、 错误操作 12
9.8、 监控定时器的设计 12
9.9、 异常保护设计 12
10、 简化设计 13
10.1、 单入和单出 13
10.2、 模块的独立性 13
10.3、 模块的扇入扇出 13
10.4、 模块耦合方式 13
10.5、 模块内聚顺方式 13
10.6、 其他特殊考虑 14
11、 余量设计 14
11.1、 资源分配及余量要求 14
11.2、 时序安排的余量要求 14
12、 数据要求 14
12.1、 数据需求 14
12.2、 属性控制 14
12.3、 数值运算范围控制 15
12.4、 合理性检查 15
13、 防错程序设计 15
13.1、 参数化 15
13.2、 公用数据和公共变量 15
13.3>
标志 15
13.4、 文件 15
13.5、 非授权存取的限制 16
13.6、 无意指令跳转的处理 16
13.7、 程序检测点的设置 16
13.8、 寻址模式的选用 16
13.9、 数据区隔离 16
13.10、 安全关键信息的要求 16
13.11、 信息存储要求 17
13.12、 算法选择要求 17
14、 编程要求 17
14.1、 语言要求 17
14.2、 汇编语言编程限制 17
14.3^高级语言的编程限制 17
14.4、 圈复杂度指数（McCabe） 17
14.5、 软件单元的规模 18
14.6、 命名要求 18
14.7、 程序格式要求 18
14.8、 程序注释要求与方法 18
14.8.1、 注释的一般要求 18
14.8.2、 模块头注释要求 1914.8.3、 模块内注释要求 19
14.8.4、 安全关键内容注释要求 19
14.9程序设计风格 19
14.9.1、 通用类 19
14.9.2、 结构类 20
14.9.3、 说明类 20
14.9.4、 输人输出类 21
14.9.5、 语言类 21
15、 多余物的处理 21
15.1、 文档中未记载特征的清除 21
15.2、 程序多余物的清除 21
15.3、 未使用内存的处理 21
15.4、 覆盖的处理 22
16、 软件更改要求 22
17、 嵌入式软件测试 22
17.1、 需求遗漏或不明确 22
17.2、 配置保存的生效 22
17.3、 缺省配置的影响 23
17.4、 报警和清除 23
17.5、 菜单选项测试 23
17.6、 缺省配置测试 23
17.7、 系统测试注意事项 23
附录1：
推荐的软件安全关键程度分级 23
附录2：
软件开发各阶段的适用准则和要求 24
7
0、概述
嵌入式软件是电子系统的重要组成部分，它具有不同于硬件系统的可靠性特征和可靠性设计方法。
随着系统应用时间的推移，系统功能逐步完善，bug逐步修复，其可靠性不会随时间下降，相反会随着时间推移而上升。
软件可靠性不但与软件存在的差错有关，而且与系统输入和系统使用有关。
嵌入式软件可靠性应达到的判定标准是判错、防错、纠错、容错。
同时，系统工程师应考虑到为实现判、防、纠、容而需要配套的硬件设计。
1、 定义
1.1、 定义
a） 扇入：
在结构图中，模块的直接上级模块个数。
b） 扇出：
在结构图中，模块所属的直接下级模块个数。
c） 安全关键信息：
其错误可能导致系统严重危险的信息。
d） 安全关键软件：
其错误可能导致系统严重危险的软件。
e） 安全关键功能：
其错误可能导致系统严重危险的功能。
f） 圈复杂度：
合理的预防错误所需测试的最少路径条数。
数量上表现为独立现行路径条数，用来衡量一个模块判定结构的复杂程度。
程序的可能错误和高的圈复杂度强相关。
1.2、 说明
本规范中用到的“须”、“应”等提法均指强行性采用；
本规范中用到的“禁止”、“禁用”等提法均指强制性禁用；
本规范中用到的“推荐”等提法均指建议优选，如果采用非推荐方案，需充分论证和考虑其负面影响并采取规避风险措施；
2、 计算机系统设计
2.1、一般要求
嵌入式软件开发的最大特点是可读性、可视性差，所以软件可靠性设计的过程宜过程监控和软件测试并重。
通过对开发过程的软件工程化管理，可以从细节上发现问题，预防问题的发生。
具体体现在以下几点：
•按照公司规模、项目规模，将软件开发过程划分为几个阶段（可根据实际情况处理），每个阶段编制必要的文档并进行检查、分析和评审，实行配置管理，图形符
号、程序构造及表示应符合GB1526和GB13502的规定；
•采用先进、适用的软件开发工具，并确保软件开发工具免受计算机病毒侵害；
•在早期开展软件检查和测试，自检、互检、或专互检结合，制定checklist,并作实质性过程检查。
2.2、 硬件与软件功能的分配原则
对电子器件的参数稳定要求较高的功能，如可能宜考虑用软件实现；
对用硬件实现时成本较高的功能，宜用软件实现；
运算较复杂、逻辑关系较复杂的功能，宜用软件实现；
对反应时间效率要求较高的功能，宜用电路硬件实现；
在权衡由软件实现、还是硬件实现的功能上，可对项目团队中软件工程师和硬件工程师的相对资深程度进行比较，优选由较资深的一方实现。
2.3、 硬件与软件可靠性指标的分配原则
软件可靠性的评价考核推荐用质量指标替代可靠性评价指标，以便直观地建立起软件设计与软件可靠性之间的联系，且该指标必须配套以可行的评价方法。
如：
设计规范符合度不低于90%（通过抽查几个模块的编程方法，逐项检查），不符合项宜逐项通过评审组的审查确认，一致通过后方可放行。
设计规范需包括如下表各种三方面内容:
软件运
行水平
软件运行
软件安装方便、运行正常、可靠性高、兼容性强，退出或中断后恢复原系统状态
软件性能
各功能正确无误，划分明确合理，响应速度快
软件容错性
软件对错误输入和错误操作的容忍性强
软件操
作水平
用户指导
附有用户手册，内容完备，表述简明，便于使用
操作使用性
操作界面友好，步骤明确，使用简便
辅助功
能水平
求助与管理
求助功能强，具有一定的管理功能
性价比
教学软件的教学性价比高
开放扩展性
具有内容调整、组合、更新和补充等开放性和可扩展性功能
2.4、 安全关键功能的人工确认
在系统控制回路中，安全关键功能的执行，必须经操作人员确认或启动方可执行。
2.5、 安全性内核
在安全关键的计算机系统中，应当设计一个称为安全性内核的独立计算机程序，用来监视系统并防止系统进入不安全状态。
当出现潜在不安全的系统状态、或者有可能转移到这种状态时，它将系统转移到规定的安全状态。
2.6、 自动记录系统故障
须有自动记录检测出所有系统故障及系统运行情况的措施。
2.7、 禁止回避检测出的不安全状态
在系统设计时考虑故障的自动检测，一旦检测出不安全状态，系统应作出正确响应，不得回避。
2.8、 保密性设计
系统设计应能防止越权或意外地存取或修改软件。
2.9、 容错设计
对高可靠性要求系统应硬件和软件容错设计并行，不能只考虑硬件容错。
2.10、 安全关键软件的标识原则
附录1中的A级、B级软件定为安全关键软件，一般包括：
a） 故障检测的优先级结构及安全性控制、校正逻辑、处理和响应故障的模块；
b） 中断处理程序、中断优先级模式及允许或禁止中断的例行程序；
c） 产生对硬件进行自主控制信号的软件；
d） 产生直接影响硬件部件运动或启动安全关键功能的信号的软件；
e） 其输出是显示安全关键硬件的状态的软件。
3、硬件设计
为实现软件可靠性，与硬件设计有关的技术要求也是必不可少的因素。
3.1、 硬件选用
a） 优选可靠性、维修性符合要求的成熟硬件，正确选择和确定供货单位。
b） 统一运行环境，在同一系统内采用优选、系列化的少数几种MCU或机型。
c） 优选的CPU须具有指令和数据分开的存储器及总线。
d） 元器件须经过检测筛选，并优选有自我纠错能力的元器件。
3.2、 总线检测
a） 指令和数据公用存储器及总线的CPU,要通过测试来确定总线上各功能间必须隔
开的最小时钟数，以确保CPU不致于采集到非法信息。
b） 实施周期性的存储和数据总线检测，测试顺序安排应能检测并隔离单点或多点故障。
3.3、 加电检测
a） 系统设计中必须加入加电检测过程，确保系统在加电时处于安全状态，并确保安全关键的电路和元器件受到检测，以验证其能被正确操作。
b） 过压欠压的处理，过压高，过压低（正常），欠压高（正常），欠压低四个门限。
如果我们采样过快，带宽过高可能会引入很大的干扰噪声和误差。
电源跌落，需要快速检测出电源跌落的过程，以便我们能关闭负载，降低单片机的工作负荷，存储重要的数据。
因此我们的采样速度不能过低，过低导致响应过慢，模块的功能等级变低。
3.4、 电源失效的安全措施
在电源失效的情况下，提供一种安全的关闭方法，并使电源的脉动不会产生潜在的危险状态。
3.5、 主控计算机失效的安全措施
系统能检测出主控计算机的失效，并且在失效时能自动进入安全状态。
3.6、 反馈回路传感器失效的防护措施
反馈传感器失效时，接口软件不会出现失控的情况。
3.7、 电磁干扰的防护措施
EMI干扰到信号质量时，软件须有对信号质量的判别设计，并能在受扰状态下，系统不会出现失控的动作；
软件设计要有独立的纠错和容错设计措施。
3.8、 维修互锁措施
须提供维修互锁措施，消除对维修人员的危害。
互锁措施应确保互锁不会被无意地暂时取消，且一旦系统恢复到运行状态时，互锁应能恢复。
4、软件需求分析
a） 软件需求分析遵守GJB1091的规定，确保软件需求规格说明的无歧义性、完整性、可验证性、一致性、可修改性、可追踪性和易使用性；
b） 对安全关键软件，列出可能的不期望事件，分析导致这些不期望事件的可能原因，并提出相应的软件处理要求。
c） 对有可靠性指标的软件，在确定了软件的功能性需求之后，应考虑该软件的可靠性指
d） 标是否能够达到以及是否能够验证，还应与用户密切配合，确定软件使用的功能剖面，并制定软件可靠性测试计划。
5、 软件危险分析
对安全关键软件，在软件开发的各个阶段进行软件风险分析。
对发生概率、危害程度做出分析，对发生概率较高且危害程度较大的事件，需要作出特殊的处理，或者降低发生概率、或者降低危害程度。
6、 安全关键功能的设计
a） 安全关键功能必须至少受控于两个独立的功能。
b） 安全关键的模块同其它模块隔离；
安全关键模块放在一起，并对其保护。
c） 安全关键功能须具有强数据类型，不得使用一位的逻辑“0”或“T'
来表示“安全”或“危险”状态；
其判定条件不得依赖于全“0”或全T'
的输入。
d） 安全关键的计时功能必须由计算机控制，操作人员不能随意修改。
e） 在启动安全关键功能之前，必须对可测试的安全关键的单元进行实时检测。
当检测到不安全的情况时，软件必须采取措施对其进行处理；
如软件无法处理这种情况，则应保证将控制转换到硬件的安全子系统。
7、 冗余设计
7.1、 指令冗余设计
处理器指令由操作码和操作数两部分组成。
区别操作码和操作数则由取指令的顺序决定，操作时序由程序计数器PC控制，CPU取指令时先取操作码后取操作数。
当PC因干扰出错时，程序会失控跑飞，引起程序混乱失控，严重时会导致程序陷入死循环和误操作。
因此，在由单片机或DSP等构建的嵌入式系统中，在关键位置插入一些单字节空指令NOP或将有效单字节指令重复，即为指令冗余。
对于各种异常情况，可尽快将程序引入正常的工作状态。
具体做法如下：
在对程序流向起决定作用的指令之前插入两条NOP指令，以保证弹飞的程序迅速纳入正常，如汇编语言中的RET、RETI、ACALL、LCALL,SJMP、AJMP、LJMP、JZ、JNZ、JC、JNC、JB、KNB、JBC、CJNE,DJNZ等。
7.2、 软件陷阱与软件拦截技术
在一般系统中未用完的剩余空间，对单片机而言，未用的ROM空间数据保持OFFH;
9
对指令系统来说，它是单字节指令MOVR7,A:
当程序受干扰而跑飞至该区时，就依次执行这一指令”或形成死循环。
针对这种情况，可采用软件陷阱技术，强行将捕获的程序指针引向处理错误程序的地址。
如错误处理程序标号记为ERROR,则软件陷阱为“LJMPERROR"
指令；
为加强捕捉效果，一般在其前而加两条NOPo软件陷阱设置在4种位置：
A未使用的中断向量区
中断向量区应设置为各中断服务程序跳转指令，当干扰触发未使用的中断或程序指针跑飞到此区时，可引起未发生中断而执行中断服务程序的混乱，可在中断向量区两种位置设置陷阱指令：
1） 在未使用的中断向量处设置陷阱，引导被触发的未使用中断；
2） 在使用的中断向量跳转指令前设置陷阱，捕捉非正常调用中断服务的程序指针，示例如下：
NOP
LJMPERROR；
在已使用中断跳转指令前设置陷阱
LJMPINTI_SER；
使用的INTI中断服务程序跳转指令
在未使用的中断向量处设置陷阱
B未使用的FlashROM区
在未使用的FlashROM区，每间隔1k的存储空间设置1-3个软件陷阱（推荐），对于实时性要求高的嵌入式系统，可设置更多的陷阱或采用软件陷阱来填充未使用的FlashROM区。
C程序区
程序区是由一系列的执行指令构成的，不能在其中随意安置陷阱，但在这些指令系列中常有一些断裂点。
正常执行的程序执行到断点时不会继续往下执行，而是按照设计要求跳转执行，这类指令有LJMP、SJPM、AJMP、JMP、RET、RETI等；
当跑飞的程序落到断点的操作数上或前面指令的操作数上，又没设置指令冗余或软件陷阱时，程序将出现运行错误。
对此，可采用模块化程序设计，在程序各模块之间的断点处设置指令冗余或软件陷阱，程序正常运行时不会进入陷阱，只有出现跑飞等异常情况时，才进入设定陷阱。
D表格区
单片机程序设计中常遇到两种表格：
1） 数据表格，供“MOVCA,@A+PC”指令或“MOVCA,@A+DPTR”指令使用，其内容完全不是指令；
2） 散转表格，供“JMP@A+DPTR”指令使用，其内容为一系列的二字竹指令LJMP或两字节指令AJMP»
由于表格内容和检索值有一一对应关系，在表格中间安排陷阱，将会破坏其连续性和对应关系，可在两种表格的最后安排陷阱，或者在散转表格的每条散转指令前添加软件陷阱，保持其连续性并修改检索指令。
注意：
陷阱前面放几条NOP指令。
软件陷阱使跑飞程序自动恢复正常状态的条件同样有两个：
1、弹飞的程序必须落到程序区；
2、执行到软件陷阱。
因此，同指令冗余一样，只能有限地解决系统软件的干扰问题,对于程序陷入死循环或跑飞至其它位置（如内部RAM,EEPROM和数据表格区）等情况无法处理。
7.3、软件冗余
•冗余要求
依据软件安全关键等级，确定软件的失效容限要求，从而确定软件冗余要求。
对A级软件，推荐的失效容限为2,要进行5版本程序设计；
对B级软件，推荐的失效容限为1,要进行3版本程序设计；
对于C、D级软件，不考虑失效容限，无需软件冗余。
•N版本程序设计
N版本程序设计由N个实现相同功能的相异程序和一个管理程序组成，各版本先后运算出来的结果相互比较来确定输出。
在比较不能分辨出错模式时,采取少数服从多数的方式，甚至根据系统安全性要求“一票否决”的方式。
N版本程序设计还可以对每一版本运算的结果增加一个简单接受测试或定时约束的功能，先期取消被证明是错误的结果或迟迟不能到达的结果，以提高比较的实时性成功率。
选用不同的实现手段和方法来保证版本的强制相异，以减少共因故障。
仅依靠不同的设计队伍、并对其它设计因素不作强制要求而开发的软件为随机相异软件；
不仅依靠不同的设计队伍，而且对方法、手段、工具、模型、语言（或语言的子集）作出强制规定而开发的软件称为强制相异软件。
•恢复块
软件需求规格说明中应对恢复块作单独的定义和说明。
恢复块由一个基本块、若干个替换块（可以是功能降级替换块）和接受测试程序组成。
基本工作方式是：
运行基本块——进行接受测试——测试通过则输出结果；
否则调用第一个替换块，再进行接受测试...若在第N个替换块用完后仍未通过接受测试，便进行出错处理。
•信息冗余
a.安全关键功能应该在接到两个或更多个相同的信息后才执行。
b.对安全关键信息，应保存在多种或多个不同芯片中，并进行比较处理。
c对可编程只读存储器（PROM）中的重要程序进行备份（如备份在不同的PROM中），万一PROM中的程序被破坏，还可通过遥控命令等手段使系统执行其备份程序。
d.对随机存取存储器（RAM）中的重要程序和数据，应存储在三个不同的地方，访问这些程序和数据都通过三取二的比较方式来裁决。
8、接口设计
8.1、 硬件接口要求
a） CPU之间的通讯须在数据传输之前对数据传输通道进行正确性检测，推荐定期检测，以确保数据传输的正确性。
b） 需要从接口软件中得到两个或更多安全关键信息的外部功能不得从单一寄存器或从单一输入/输出I/O口接受所有信息，而且这些信息不得由单一CPU命令产生。
c） 对于所有模拟及数字输入输出，在根据这些值采取行动之前，必须先进行极限检测和合理性检测。
8.2、 硬件接口的软件设计
a） 对硬件接口进行读写的软件，涉及内容须包括的功能有：
检测外部输入或输出设备的失效、在失效时软件能恢复到某个安全状态、软件设计上须考虑所涉及硬件的潜在失效模式。
b） 在设计硬件接口的软件时，须预先确定数据传输信息的格式和内容。
每次传输都必须包含一个字或字符串来指明数据类型及信息内容，至少要使用奇偶校验与检验和来验证数据传输的正确性。
c） 安全关键功能应使用专用I/O端口，并使这种I/O端口与其它I/O端口有明显区别。
8.3、 人机界面设计
a） 人机交互软件的设计功能中，要便于操作员用单一操作即可使系统退出潜在不安全状态，恢复到安全状态。
b） 在启动安全关键功能时，必须由两个或多个人员在“与”方式下操作，或者一个人在至少2个以上的操作下才能触发，并有完善的误触发保护措施以避免造成无意激活。
例如：
在启动某个安全关键功能时，最少应由两个不同按键来启动，且这两个按键在操作键盘或操作面板上须保持一定的距离，以免误触发；
如果是两个操作员启动，二人应独立地、最好在不同的操作键盘或操作面板上同时启动，且一个操作员不能同时启动也不能采取措施强迫另一操作员启动。
向操作员提供的显示信息、图标、及其它人机交互方式必须清晰、简明、且无二义性。
8.4、 报警设计
a） 软件须向操作员提供声光报警，声音报警音量须超过预期背景噪声20dB,并同时提供表明软件正在操作的实时指示。
要求几秒钟或更长时间的处理功能在处理期间必须向操作员提供一个状态指示。
b） 报警须分级，例行报警与安全关键的报警在声、光、指示文字或图形等方面有明显的区别，并确保未结束纠正措施前、或未执行所要求的后续行为以完成该操作的情
况下，操作员无法清除安全关键的报警。
8.5、软件接口设计
软件接口注意事项：
a） 模块的参数个数与模块接受的输人变量个数一致；
b） 模块的参数属性与模块接受的输入变元属性匹配，尤其注意避免强制转换数据类型会导致的数据变化；
c） 模块的参数单位与模块接受的输入变量单位一致；
d） 模块的参数次序与模块接受的输入变量次序一致；
e） 传送给被调用模块的变量个数与该模块的参数个数相同；
f） 传送给被调用模块的变量属性与该模块参数的属性匹配；
g） 传送给被调用模块的变量单位与该模块参数的单位一致；
h） 传送给被调用模块的变量次序与该模块参数的次序一致；
i） 调用内部函数时，变量的个数、属性、单位和次序正确；
j） 不会修改只是作为输入值的变量；
k） 全程变量在所有引用它们的模块中都有相同的定义；
l） 不把常数当作变量来传送的情况。
9、软件健壮性设计
软件健壮性设计主要体现在软硬件结合处理方面，具体如下：
9.1、 电源失效防护
加电的瞬间，电源可能出现间歇故障，或系统因电源商店过程的抖动或上电顺序不一致
而导致系统出现运行问题，软硬件配合处理在这两种状态下的潜在不安全初始状态；
在电源失效时提供安全的关闭措施；
电源有波动时，系统不会产生潜在的危险。
9.2、 加电检测
系统加电的过程，软件对系统进行检测，验证系统安全且在正常运行；
软件对系统进行周期性检测，以监视系统的安全状态。
9.3、 电磁干扰
对于电磁辐射、电磁脉冲、静电干扰，硬件设计须有防错措施，软件设计须有判错、纠错、容错等处理的语句和措施，确保系统安全。
9.4、 系统不稳定
外来干扰使系统产生不稳定，不宜继续执行指令时，软件应有等系统稳定后再执行指令的措施。
如具有强功率输出的指令所引发的动作对系统或计算机系统的稳定性影响较大,软件应使计算机在该指令输出并等系统稳定后，再继续执行指令。
继电器的开关即为一例。
9.5、 接口故障
应对接口故障全面分析，并采取措施。
软件应能够识别合法的及非法的外部中断，对于非法的外部中断，软件能自动切换到安全状态。
反馈回路中的传感器有可能出故障并导致反馈异常信息，软件应能预防将异常信息当作正常信息处理而造成反馈系统的失控。
软件对输入、输出信息进行加工处理前，应检验其是否合理（最简单的方法是极限量程检验）。
9.6、 干扰信号
数字滤波时，采样频率的确定要考虑有用信号的频率，也要考虑干扰信号的频率。
9.7、 错误操作
软件应能判断操作员的输入操作正确（或合理）与否，并在遇到不正确（或不合理）输入和操作时拒绝该操作的执行，并提醒操
升级会员 