嵌入式软件可靠性设计应注意的问题

命名方式可防止局部变量与全局变量重名。

禁用易混淆的标识符(R1和Rl，DO和D0等)来表示不同的变量、文件名和语句标号。

除了编译开关/头文件等特殊应用，避免使用_EXAMPLE_TEST_之类以下划线开始和结尾的定义。

全局变量是战略性资源，它决定了模块和模块间的耦合度，需在项目上提升到一个足够高的高度，慎用全局变量，不得不用的时候，要单独为每一个全局变量编写独立的操作模块或函数，在修改全局变量的时候，要检查是否有别的函数在调用它并且需要此数值保持稳定。

对变量代表某个特定含义的时候，尽量不要仅仅用位来代表什么，比如用某变量的第零位代表某个状态(0000 0001，其中仅用1代表某个内容，这样01H、03H、05H… 会有很多个组合都能代表这个状态);位容易受干扰被修改，信息出现错误的几率大很多。

也不要用00H、FFH等数据代表，就像我们面试一群人一样，第一个被面试人和最后一个被面试人容易被记住，00H和FFH亦然，系统默认状态是00和FF的时候较多，他们容易被复位或置位成这类数值。推荐以四位的二进制码的某个中间值为状态变量，如1001。

变量数据在应用之前宜作数据类型和数值范围的判断;

数据在存储过程中也容易出现问题，EEPROM、RAM等都有过类似的案例。数据出错时避免不了的，解决的办法是学花旗银行等美国金融企业，之所以在9.11后他们能很快恢复业务，基本没有数据方面的损失，原因何在?因为他们有异地容灾数据备份系统，知里面有两个关键词，异地、备份。我们的信息也同样，首先选择存在不同的介质中、或相同的介质但迥异的存放环境和位置下，双重备份的结局是两边不一致的时候，数据被怀疑并拒绝反映执行，但嵌入式软件很多时候是要靠数据来推动执行机构的，即使发现数据有问题也不允许行政不作为，这种情况下，作为我们也很难办，2个不同的数据，有明显问题的还好排除，都在有限范围内可如何判定哈?这种时候没办法只好三备份，少数服从多数是唯一的选择了。石头剪刀布的方式不好用，葛优的分歧终端机也不适用，就只好选择这种最原始最有效的办法了，唯一需要注意的是数据宜存放于三种不同的备份环境下，不然岂不成了你家哥俩儿，咋表决都占便宜阿。

以上仅就嵌入式软件可靠性的关注方面分了几大类，进行了基本的描述，实际应用中，需要关注的点还有很多很多，如果是准备自行制定设计规范的话，以上的思路应该也可以给与一些启迪了。