《嵌入式软件可靠性设计要注意的问题.docx》由会员分享，可在线阅读，更多相关《嵌入式软件可靠性设计要注意的问题.docx（7页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、嵌入式软件可靠性设计要注意的问题xuliyuan导语：嵌入式软件可靠性设计需注意的问题有四个方面：软件接口，软硬件接口，软件代码。嵌入式软件的最大特点是以控制为主，软硬结合的较多，功能性的操作较多，模块互相间调用的较多，外部工作环境复杂容易遭到干扰或干扰别的设备，且执行错误的后果不仅仅是数据错误而是有可能导致不可估量的灾难，所以总结起来，嵌入式软件可靠性设计需注意的问题有四个方面：1、软件接口先讲软件接口中容易出问题的地方和编程人员容易犯的错误。软件接口调用一般会有数据的赋值，赋值变量的数据类型可能会存在强迫的数据转换；需加以检查。假如为了防备出问题的话，能够添加对数据范围和数据类型的检查。赋
2、值数据的数量不对路，多了少了的都不好，会出现意外的赋值结果，不过还好，这项错误比拟好检查。软件编程中，会有对某一功能操作代码的复用，比方对某个端口的数据检查和控制，在整个程序中只会发生两次，为了图省事，可能就直接把该段代码直接插入实际程序模块中去了，这样，在源程序代码中，就出现了两段完全一样，完成一样功能，只是服务于不同模块的代码，按道理来讲，这样设计其实也没啥问题，是的，你没错，但你的行为会使别人无意中犯错。就像青年男女相处，女孩子纯粹是想和男孩子充共享受温馨的气氛和心情，并不想更深化的发生什么，但女孩子邀请男生去的是她的家，在家里换上了家居的睡衣，窗户紧闭，放着的还是暗昧的音乐，被男孩子半
3、强迫发生后，无限哀怨地讲“我没想到结果会是这样的，那怪得谁来呢？在代码方面，您的这种做法与貌似引诱男孩上钩的无异。有人会讲了，我这样写代码怎么就算引诱呢？原因是程序可能会升级，您这几行代码在实际应用经过中也不能保证是尽善尽美的，发现不完善的地方后，势必会修改，假如你还能想得起来，可能不会遗漏，假如修改此代码的是别的人，改了一个地方，别的地方没改，是不是还留着隐患？那怎样做呢？方法不难，把这段功能单独做成一个模块即可，对此端口的读取和控制赋值均由此独立模块完成，假如数据的正确性影响大的话，还需要对端口数据的正确性进行检查和判定。嵌入式软件可靠性编程方法的四个目的是防错、判错、纠错、容错。对端口数
4、据的判定属于判错的内容，假如数据有错的话，纠错和容错的设计方法应该不用我深化讲解了吧？2、软硬件接口硬件如男人，对外的执行都靠它来实现，一旦出现问题，执行后的后果就不可控了，周总理讲过“外交无小事。但怎样注意呢？对读进来的硬件接口的数据要判定其真伪；对输出的数据的执行效果要检测；对输出的数据的可能后果要进行预防性设计，数据输出的经过，我们从设计上要做一个分析，分析的思路是一般容易局限在稳态经过，忽视了过渡经过。举例讲明，比方我们控制一个支路的供电，从软件控制来讲，直接给继电器一个启动信号，让开状态的触点闭合就能够了，非“关即“开，是受控继电器的两个稳态状态，但事实上，在从开到闭合的经过中，支路
5、供电的电压并不是一个简单0V24V(24V为示例罢了)的跳变状态，而是一个抖动，有冲击信号的经过，这种情况在硬件上的防护是必不可少的，但在软件上也不是能够事不关己、高高挂起的。另外在逻辑上，宜将容易被干扰和容易产生的干扰控制动作从时序上控制好，予以分开隔离。比方，控制继电器的经过是容易产生抖动尖峰脉冲而干扰数据总线和控制信号总线的，这时候从控制上，不宜同时施行数据的发送和接收工作，不宜作出其他的控制动作，惹不起咱躲得起，躲过这一阵干扰的时候总能够了吧？3、软件代码软件的可靠性是随着时间的推移，可靠性逐步增加的，这一点区别于电子可靠性、机械可靠性。电子可靠性服从指数分布，在整个生命周期内，其失效
6、率为一个常数；机械可靠性由于磨损、腐蚀、运动等因素的存在，随时间推移可靠度会下降。因而也就有了软件可靠性设计的一个特定规律和注意事项。既然需要通过时间推移，通过不断改良，软件可靠性得到提升。那么软件的可维护性就是一个大问题了。这也是为什么软件工程管理方面十分关注软件文档、注释的原因了。但做这些要求的人只是人云亦云，并不理解如此做法的真正动机。至于注释怎样去做、变量怎样命名、软件配置管理怎样操作，这里面既有很常规的方法，也有一些我们习以为常然而是错误的做法。信手举上几个值得注意的细节供参考。变量定义时宜将变量类型的变量名程中体现于其中；如AD_result_int、Cal_result_floa
7、t等。这样为的好检查，防止数据类型的强迫转换或强迫赋值时出现数据类型的错误；注释要充分；代码的布局风格宜统一，便于浏览查找；不可出现非受控的default流程，所有数值和变量，不管是调用函数时赋予的、读取接口读进来的、还是中间变量计算出来的，在应用前都宜作数据有效性的判定，并对断定的所有可能结果均做受控的对应处理。关于软件可维护性编程方法方面的文章资料在网上是铺天盖地，不予赘述，综合采用之即可。很多文章把软件可维护性编程规范推荐做成企业的嵌入式软件可靠性设计规范，实在是有点以偏概全，有失偏颇的，用一句娱乐圈的话来讲，“爱情是生活的重要内容，但它不是生活的全部，软件可维护性编程方法亦然。软件代码
8、在执行中容易出现的下一个问题是跑飞，程序指针遭到干扰，跳转到了一个非受控位置，执行了不该执行的代码。假如执行了不该执行的代码，假如在程序中参加了足够的变量判定、读值判定、状态检测判定等，那倒还好了，后果也不会太严重，甚至最终还是可能本人跑回来的。但有一种跑飞是比拟可怕的，一般我们在ROM中存放的程序目的代码是1-3字节的指令，就是最多3条字段的目的码组成了执行动作，假如程序指针跑飞到了某个3字节指令的第2个字节上的时候，执行的后果是什么，可就真的没人知道了，即便在程序上作了足够的数据判错、逻辑跳转的防备措施，结果也不会好。而且ROM一般是不可能全部都被程序代码填满的，总有充裕空间，充裕空间中的
9、默认内容是啥，这些默认字节能否也会导致一些操作呢？单片机中的默认空间是0FFH，DSP的我没查过，大家有兴趣查一下，跳到这些字段里，也是容易出费事的。好了，不再罗嗦，直接给出解决方法吧，就是每隔一段程序代码或控制区域，就人为放置上几个NOP指令，在NOP指令后放置一个长跳转的ERR处理程序。注意NOP最少放置3个，这样任何的跑飞最多只能占用2个NOP，第三个NOP一样还是能把程序代码揪回来，揪回来后就执行ERR处理程序。假如碰到安全性、可靠性等级要求比拟高的程序，推荐的处理方法能够采用热备份的处理方法，即用两段代码同时执行同一个功能，执行的结果进行比照，假如一致则放行通过，假如结果不一致，咋处理就看您的喽。但是国人有的是办法，为了图省事，你领导不是要求我编热备份程序吗，那好，我就把原来的代码复制一遍，重新插入到某个地方，您这和明朝时代冯保太监(还是严嵩、张居正阿？拿不准了，大家有兴趣的翻看（明朝那些事儿）查阅下)玩的没啥两样，本人写奏章，本人给本人审批奏章。既然是备份就是为了防止一个人出问题，那最好的办法自然是不同的人来编这段，假如原理计算方法上也不同，数据收集通道也不同，那就过年带娶媳妇的，好上加好了。安全性和可靠性的编程细节注意事项还有很多，窥一斑难见全豹呵，诸位仁兄一起努力钻研了。0