浅谈“鲁棒性”

只看该作者 · 2008-1-24 15:23

wxj1952的问题大家来解答下... 关注！

架构结构>>策略方式方法>>补丁；
系统设计运行中多用理论，通过系统的测试手段获取运行数据验证理论；

另外介绍一种设计方法，强壮的系统必须是束敛的，既系统允许在一定范围内震荡且系统具不断自我修复向最佳状态靠拢的能力（束敛），设计师如果在设计的一开始就假定系统本身是不稳定的，则设计出的系统在错误修复能力上就会好很多，目前我们多数系统设计者理所当然认为一切都是预定轨迹的在运行，这是设计观念造成的差别，如果在观念中建立这个设计前提，则你很多思考问题的方式都会改变，这种感觉是全新的！

只看该作者 · 2008-1-24 17:29

只看该作者 · 2008-1-25 13:44

  　你的理解基本正确。
　　因为程序越大，表明单片机代码空间肯定是大的，单片机型号，速度，性能等也肯定是越好的。
　　软件方面，你的程序越大，模块就越多越完善，就越可以做一些类似上面说的“鲁棒性”东西，如果是小单片机考虑到代码容量等问题，反而不敢加。
　　如果每个模块都能做到完整封装（需要解释），在一个好的结构的支配下，各个程序是无BUG的。

　　这里需要对模块作一下解释：

模块
A、    只能有一个入口，一个出口。
B、    用最少而且最完善的参数作为入口
C、    尽量采用完整封装，并对封装作说明。
完整封装：
（1）在没有外界的影响下，对外界没有影响（功能式）
（2）在有外界的影响下，外界与内部的读写不相同，即对某一变量，若外界只读，内部可读写，若内部只读，外部可读写。

D、    其它人员不调用的功能子模块，根据速度代码积，尽可能封装在功能模块内
如I2C读写模块，对于其ACK(确认)，StartBit(开始位),SotpBit(停止位)，外部人员不关心，而且代码很少，所以应该封装在I2C_ReadByte (读一个字节)、I2C_WriteByte(写一个字节)
E、    对于多功能模块，必须外加各种可能使用的包装模块。
F、    尽量减少顶层模块数量
如I2C可以一次读取多字节，如果再编写一个模块在很多场合是多余的，因为可以用I2C_ReadByte代替。
这样速度代码积不会增加。
G、    对同一功能，在所有算法中，保留速度代码积最优的一个，速度代码积在同一个数量级的，可以保留备用。
H、    对于扫描型模块，必须注明 “中断时间”及“扫描时间”，
中断时间：该模块需要多少时间调用一次(必须)
扫描时间：该模块调用一次在一般情况下会用多少周期（必须）
最大情况下会用多少周期
最小情况下会用多少周期

　　这只是我的《程序书写规则》里面的一点点。如果需要的朋友可以联系我。

只看该作者 · 2008-1-25 13:48

程序可靠性问题完全值关注,而且非常重要!

只看该作者 · 2008-1-25 13:52

　　系统必须具备自我修复能力，很多高层软件或底层软件在丢失数据或文件后，无法启动，或运行异常，是因为他们首先认为这个文件或数据已经存在了，事实上完全可能丢失。
　　这个时候系统要么创建一个新的缺省文件，或者缺省数据，或者通知用户数据已经丢失，请用什么方法重新建立。

只看该作者 · 2008-1-25 17:23

只看该作者 · 2008-1-27 00:02

鲁棒性（robustness）就是系统的健壮性。它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。
控制系统中的“鲁棒性”，是指控制系统在一定（结构，大小）的参数摄动下，维持某些性能的特性。

只看该作者 · 2008-1-27 13:45

就是不管如何拿根棒子敲下去，看系统能不能正常运行

1万 · 2008-1-27 13:55

哈哈哈。。。。。。。。

只看该作者 · 2008-1-28 20:58

在用51时，曾经碰到受到电机干扰产生复位，因电路中有12887，顺手就将关键数据保存在12887中，程序启动时先恢复现场，
后用AVR，它有复位源寄存器和eeprom，也做了同样的处理（尽量少写eeprom），
极少发现程序异常动作

3万 · 2008-1-30 13:14

而硬件设计则很难制定一个完全统一的规范，我也一直试图在做这些工作以及增加更多的测试设备。我们现在设计软件都要考虑在线升级或者远程设计的功能，因此有时遇到Bug还有挽救的可能性，但如果硬件设计出了问题，则是致命的，产品召回完全有可能将一个搞垮，建议多讨论一些硬件设计方面的问题以及配合软件如何提升可靠性。
现在很多认为搞产品开发就是搞单片机，而搞单片机就是搞C语言编程，所以很多掌握了一些编程方法或者OS的人都自以为“牛人”，这样对在校的学生影响很大，他们出来之后几乎都是轻硬件，这种现象是非常可怕的，对整个产业的影响都是非常可怕的，希望能够正确引导年轻人。

只看该作者 · 2008-1-30 20:21

只看该作者 · 2008-1-30 21:54

  这并不是让软件去纠硬件的错，而是尽可能让一部分的错误不至于急剧扩大而影响其它的方面，很多时候偶发的错误，正确处理的话，几乎不会造成任何影响，即便有时会丧失一部分的功能，也比造成灾难性的后果要好得多。
  这些例子是很多的，阿丽亚娜一次爆炸就是因为程序的一个switch的default没有处理，虽然正常情况下不应该有这种情况，程序员不加这个不能说是bug，但是如果加上了，就可以避免这一次严重的事故。
  增强软件的鲁棒性，最基本的就是要对传入的参数进行检查，除非是完全由自己的模块传入的，在传入前已经进行了严格的检查的函数。只要是对外的函数，都要假设传入的参数是不可信的，是会越限的。不能让这个越限的参数使你的模块数据发生错误，那么这个错误就被你阻击了，而不会继续漫延下去。可能过一会它就好了，或者在本次运行周期内不会产生影响。那么这次错误就会和没发生看起来一样，你的系统的可靠性就提高了。

1万 · 2008-2-1 10:18

只看该作者 · 2008-2-2 08:54

动不动就判断是否有效，无效返回，或printf，不过移植到单片机上就删掉了；太麻烦，又没有地方显示

只看该作者 · 2008-2-10 10:09

就拿步进电机加速过程来说，一但飞了什么抗干扰都没用

只看该作者 · 2008-2-15 16:24

看见了这哥们的题目多说几句!
鲁棒性这个词应用于最多的是控制领域!其次就是图像处理领域,拿个没有什么太大意思什么软件啊..端口来贴意思实在不妥!
鲁棒性实际意思就是:一个人生病了!他自身免疫能力如何!帮助他摆脱暂时不正常的状态的能力!
拿一个图像处理领域一个典型例子说吧!一个数学模型的建立,比如跟踪一个动目标.镜头突然发生偶尔的遮挡,造成跟踪丢失!这时应当有相应的预测机制,对于下次目标可能处于的位置进行预测.方法有很多比如设置双波门波门,计算图像的中心矩矢量,或利用适合的小波基函数进行小波变换分层处理等等!
只是感觉鲁棒性这个在这里解释的太差了!

只看该作者 · 2008-2-16 14:25

只看该作者 · 2008-2-23 15:10

有种观念叫“契约式”编程，就是大家约定一些条件后，保持１２分的信任。
比如Ａ的输出是Ｂ的输入，且约定好这个变量正常范围=0~7，那么B就可以充分信任输入参数合法，这样就避免了无谓的验证，程序的可读性也好些。

现在社会上世风日下，雷锋成了傻子，处处风声鹤唳、草木皆兵，效率低下。

写程序也一样。
可分两种环境，两种策略

1、在一个安全的环境里，应该尽可能讲究“契约式”编程，不要动不动就“if（p==NULL）”，而应代已“assert（p）”，交付时尽可去掉断言。
2、在不安全的环境里，该草木皆兵的就要草木皆兵。

风险应该控制住，不能向下传递。

譬如假*，收钱的时候一般都验钞，但交给老婆的时候，老婆很少去拿验钞机，就是因为夫妻之间有种契约，那就是诚信。
老公对外收钱是讲究“鲁棒性”的，老婆对老公则是“契约式”，绝对信任的，因为假*已经在上一层过滤了。

鲁棒性随处用，就好比父子反目、夫妻相疑，不和谐鸟。

只看该作者 · 2008-2-23 15:19

不过：
要保持模块的通用性，输入检查是必要的。

浅谈“鲁棒性”

wxj1952的问题大家来解答下... 关注！

只得学习

回复－＞1+1等于几

绝对支持

wxj1952 说得对

听课

意外学习

鲁棒性是不是这样可以解释

LS有意思，鲁棒性 = 鲁莽地拿根棒子敲下去

保存现场

软件的问题相对好办，可以制定编程规范来规避。

这个和软件抗干扰有一定区别

软件鲁棒性是必须要注意的

程序菜鸟留名

软件方面容错性的判断，pc机软件里做得比较全

该分开应用场合！！！

看见了这哥们的题目多说几句!

受教育了

鲁棒性与和谐性

楼上很对

以坛为家

精英会员奖章

奔腾之江水

技术高手奖章

突出贡献奖章

湍急之河流

七世轮回

技术奇才奖章

核心会员奖章

沉静之湖泊

技术新星奖章

希望之星奖章

荣誉元老奖章

坚毅之洋流

常驻人口

无冕之王奖章

十世金身

社区建设奖章

涓涓之细流

wxj1952　说得对