※ [本文转录自 Programming 看板] 作者: JohnLinq (林约翰) 看板: Programming 标题: [心得] 如何强化嵌入式(系统)软体可靠度 时间: Sun Apr 12 00:23:14 2009 我在KEIL的官方论坛，看到一篇关於「如何强化嵌入式(系统)软体可靠度」的文章， 我个人觉得蛮有参考价值的，所以.希望能够把这篇文章介绍给大家。 KEIL官方论坛的讨论串在此： http://www.keil.com/forum/docs/thread14537.asp 这个讨论串起源於其他杂七杂八的闲聊，而後由Per Westermark所发起， Per Westermark是一位来自瑞典的嵌入式系统专家， 也是KEIL官方论坛的主要贡献者(解答问题的人)之一。 或许是有感於，从事嵌入式系统开发的人越来越多， 对於嵌入式系统「品质与可靠度」的关注，却越来越少， 所以，Per Westermark才会公开发表以下这篇文章。 Some concepts for hardening embedded software Copyright (c) Per Westermark, 2009 http://iapetus.neab.net/download/8dc2ac48-635ac1a9/hardening.html Per Westermark表示，关於系统开发的流程、方法论、规范标准等等， 大家都可以找到各式各样的丰富资料， 但是，在实际进行软体开发的时候，应该注意哪些关键，却很少有人提及； 所以，Per Westermark给大家提供了21项建议， 而这些建议，所着眼的，并不是如何写出洗练的程式码，也并不是如何减少Bug的出现， Per Westermark的建议，是实在地告诉我们， 当一个系统出错的时候，软体应该如何处理； 至少，对於鄙陋如我而言， Per Westermark的建议，让我能够以截然不同的角度，看到全新的视野。 uint16_t buf[BUF_SIZE]; unsigned idx; for (idx = 0; idx < BUF_SIZE; idx++) { ... if (idx >= BUF_SIZE) { do_something(); } else { buf[idx] = new_data; } } 在一个idx由0开始，直到小於BUF_SIZE为止的回圈里， 写下if (idx >= BUF_SIZE) then do_something()的代码，看来似乎是相当地外行？ 其实不然。 uint16_t buf[BUF_SIZE]; unsigned idx; for (idx = 0; idx < BUF_SIZE; idx++) { ... if (idx >= BUF_SIZE) { // loop variable has for some reason been corrupted. Take proper // action. perform_corrective_action(); } else { buf[idx] = new_data; } } 嵌入式系统的应用领域非常广泛， 从太空梭、弹道飞弹、战斗机、民航机、汽机车，到数位机上盒都有可能。 在以下这串杂七杂八的闲聊里，提到了一些例子： http://www.keil.com/forum/docs/thread14479.asp (这个讨论串很长，更糟的是很乱。) 姑且把所有的系统错误都称为Bit Error/位元错误， 也就是说，原本为0的Bit突然变成了1，原本为1的Bit突然变成了0； Bit Error可能因为各式各样的原因而发生， 或许是因为系统瑕疵，或许是因为旁边有高压电塔， 或许是因为被雷打到，或许是因为一只黑猫刚好走过去。 也或许，因为这个嵌入式系统用在电子作战， 它必须干扰敌方的系统，并且不被敌方干扰； 也或许，因为这个嵌入式系统用在吃角子老虎， 刚好有人想要作弊，刚好有人想要破台。 当Bit Error发生的时候，软体应该怎麽做？ 1. Duplicated data 重要的「设定值」与「状态值」应该拥有一份能够自我备援的副本。 2. Checksummed data 「设定值」与「很少变动的资料」，应该具备「自我侦错/纠错」的能力。 3. Recomputed variables 系统闲置时，重新计算「重要的变数」。 4. Refreshing of I/O configuration and state 系统闲置时，重新写入重要的「设定值」。 5. Cross-correlation of time from multiple sources 系统应该具备侦测能力，以评估「时间/时钟的来源」是否可靠。 6. Age-tracking of sensor data 系统应该具备侦测能力，以评估「感测器所传回的数值」是否可靠。 7. Explicit range checking 对於「资料区域的位址上/下限」，应该明确的定义并且加以侦测， 以确保资料区域不被损毁。 8. Stack highwater marks Stack应该拥有清楚的识别Pattern，让系统能够对Stack进行保护， 以确保Stack不被损毁。 9. Corruption fingerprinting 资料储存区应该填入Magic value，让系统能够进行资料损毁的侦测。 10. Magic values/hamming distance for states 以数值来表示状态的时候，相邻的两个状态值应该具备充分的区别性， 以防止错误。 所以，0表示FALSE、非0表示TRUE，有时候并不是一个好主意， 因为，0x00与0x01只相差一个Bit。 11. Trend analysis of repairs/resends/… 系统应该具备「故障倾向」的侦测能力，比如说： 电压逐步下降，Error Rate逐步上升。 12. Interrupt lockup detection 对於可预期的系统事件，系统应该加以侦测， 一旦事件应产生而未产生，则表示故障。 13. Interrupt loop detection 对於可预期的系统事件，系统应该加以侦测， 一旦事件应结束而未结束，则表示故障。 14. Processor load supervision 15. Hardware watchdog 16. Inter-thread software watchdogs 17. Avoiding infinite loops 18. Checksummed firmware 19. Duplicated firmwares 20. Wear-leveling of flash and EEPROM 21. Static allocation Per Westermark期待能够与有兴趣於此的人士交流，有任何意见请到 KEIL官方论坛的相关讨论串留言： http://www.keil.com/forum/docs/thread14537.asp (KEIL的官方论坛相当地自由开放，无须注册就可以发表留言。) (虽然它希望你以Real Name署名，但是它并不强制。) --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 118.232.210.60 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 118.232.210.60