打印

浅谈“鲁棒性”

[复制链接]
楼主: 程序匠人
手机看帖
扫描二维码
随时随地手机跟帖
21
happystar| | 2008-1-22 19:23 | 只看该作者 回帖奖励 |倒序浏览

同意匠人

如果看过林锐博士写的那本《C语言陷阱》(具体名字好像这样的),大家都明白这个道理了。这本书写的很详细,讲的也类似匠人的说法。
我写程序一直有这样的习惯的,我还一直把它当成我程序中的“陷阱”呢,嘿嘿。其实这个真是很关键的,如果你程序中存在着BUG(在你没查出来之前),在程序运行的期间,很有可能要执行这些意外情况的。比如说按照匠人的例子:程序执行这条语句时if(++i == 9),那么有可能你的BUG导致此时i=10了,而你的程序没有i==10的跳转,所以指针开始走向意想不到的地方了。
同样换成if(++i > 8),则不会出现这种情况的(可能弥补了程序中的bug)。

使用特权

评论回复
22
谈的元| | 2008-1-22 20:17 | 只看该作者

什么是知己,匠人就是

一个程序员对异常做到的处理都是很少一部分,他们大多完成任务就觉得OK了

如果有朋友还埋怨老是死机,单片机不好。在这里就应该找到答案。

强干扰干扰到单片机后,许可单片机短暂不正常,但至少要做到干扰去了后,

单片机能正常工作。呵呵

使用特权

评论回复
23
yewuyi| | 2008-1-22 20:25 | 只看该作者

失效分析才是正道~~

失效分析是指导我们降低失效概率的唯一手段~~

使用特权

评论回复
24
IceAge| | 2008-1-22 23:39 | 只看该作者

鲁棒性对于我等控制出身的人来说

并不陌生。另外一个是浑沌理论,通俗的说法是 蝴蝶效应,都是研究系统稳定性的理论。
首先,控制软件不存在 发散性 问题,也不存在稳定性 问题,甚至不应存在收敛 问题。判别 鲁棒性 的一个标志就是收敛性,即扰动后回复的速度。
== 与 >= 的使用,表面上是 收敛 速度的差别,但问题的关键还是在于造成 == 失效的原因。农民讲习所所说的是真知灼见:

个体的技巧,代替不了硬件解决的技术。

如果 == 真的实效了,那么一定就是:1)软件有 bug, >= 不是解决之道 2)硬件系统不稳定,软件补救也不是解决之道 

出现错误并不可怕,怕的是把头埋进沙子里。

使用特权

评论回复
25
老狼| | 2008-1-23 01:17 | 只看该作者

农民讲习所

其实我们是一伙的,只不过我说的委婉一点,哈哈,怕西红柿和臭**蛋,更怕板砖!

皮之不存,毛之安在! 硬件是皮,软件是毛!

其实,很多时候,我们混淆了程序的Bug与程序的健壮性!为什么?因为我们的测试没有专门的测试人员,在这方面,不如软件公司。为了能够在程序的bug出现时,能够正常复归或及时补救,才有了
“1、我们要让一个变量做递增运算,每次+1,达到某一个阀值时清零。那么你在做阀值判断时,是判“等于”,还是判“大于等于”?(正确答案:判“大于等于”)”,    这一类无奈的处理方法,但是,从程序的表象上看,这样的程序的确比较健壮,我也用这样的方法,无奈的选择,但是如果在想下去,这样的方法真的可靠么?已经出错了,能保证程序其他部分是正确的么?在运行下去,能纠正错误,还是在错误的路上走得更远?如果真的异常了,也许 大不了从头再来---复位,或是更好的选择。

  一个MCU这么将就可以互弄客户,难以批量性符合客户要求。----------说的是stm32的扩容事儿?

使用特权

评论回复
26
machunshui| | 2008-1-23 11:43 | 只看该作者

分析问题,编程不要有遗漏

分析问题,编程不要有遗漏。
各种情况都要尽量处理.

使用特权

评论回复
27
农民讲习所| | 2008-1-23 13:49 | 只看该作者

和老狼握手

讲得非常好。

俺课本上要加一条:软件纠[硬件的错,越错越远。

站长的鲁棒性,是如何可靠设计软件系统,可以深入讨论,别和软件抗干扰连在一起。

使用特权

评论回复
28
taoyubai| | 2008-1-23 15:56 | 只看该作者

受教了,

使用特权

评论回复
29
mapleyang| | 2008-1-23 16:18 | 只看该作者

FMEA

贴一个FMEA的过程:
General Steps in the FMEA
1. For each Process Step, list ways that it can vary or go wrong
(Failure Modes)
2. Identify Effects associated with each Failure Mode
3. List all Causes for each Failure Mode
4. List the Current Controls for each Cause
5. Create Severity, Occurrence, and Detection rating scales
6. Assign Severity, Occurrence and Detection ratings by going
down the FMEA in each of these columns.
7. Calculate the risk priority number for each potential Failure mode
scenario
8. Determine recommended actions, with responsible parties
assigned and estimated date of completion, to reduce High RPNs
- Estimate effect of Actions on RPN (PSEV, POCC, PDET).
9. Take appropriate actions and re-calculate all RPNs

简单说就是列出各种可能的failure mode以及其发生的概率、危害性,得出一个量化的数据(RPN),然后找解决办法减小或消除其危害性,重新计算RPN。
主要因素是错误类型、概率、影响,导致错误的原因

使用特权

评论回复
30
guoqi| | 2008-1-23 16:42 | 只看该作者

FMEA,公司今天正在搞这个,也来凑个热闹

其实FMEA分为DFMEA和PFMEA。
都是分析潜在失效模式的。(只不过一个是针对设计,另一个是针对生产过程)

主要是分析其中的严重度,问题出现频率,和不宜探测度三个方面。
然后得出一个风险优先指数R.P.N (= 严重度×频率×不宜探测度)如果该指数超过一定的值,就要优先考虑并解决。


还是比较繁琐,况且这个文件不是一个人能搞定的,,,,,
有个小组叫什么APQP多功能小组

使用特权

评论回复
31
ldy216| | 2008-1-23 18:04 | 只看该作者

说得对

  这位朋友说得非常对,我在程序中比他说的做过更多研究,比如程序效率,代码可利用性,可阅读性,程序结构等。
    只是后面IO输出开缓存这个不对。
  严格来说,IC本身在运行情况下RAM及其他寄存器是不会出错的,都是受用户指挥的,你只要开个位变量就行了,用变量去刷新输出,不需要定时刷新,变了才刷新,这是百分百安全的,如果输出到底到了硬件没有,可以用闭环控制的方法,用另一个脚去测试硬件的相应位置(如果非常重要)。
  如果有好的程序结构,根本不会发生BUG。
  我做了10年产品,出厂后还没发生过BUG之类的(BUG在写完模块的当时就发现了,因为这是我的习惯,必须验证模块),只有说功能不全。
  程序越大我反而觉得越安全,越稳定,运行越快(一般人无法理解,就像WINDOWS比DOS快一样,但已经成为事实)。一般的程序结构,程序越大跑得越慢,越容易发生意外。
  信不信就由你了。
  硬件也是如此。

使用特权

评论回复
32
1加1等于几| | 2008-1-23 18:24 | 只看该作者

re ldy216

"程序越大我反而觉得越安全,越稳定,运行越快(一般人无法理解,就像WINDOWS比DOS快一样,但已经成为事实)。一般的程序结构,程序越大跑得越慢,越容易发生意外。"

人不可能写每一个程序都没有BUG,也不可能所有的BUG都能保证出场前测试出来。你既然可以保证大程序模块没BUG,那么你也一样可以保证小程序也没BUG。而你说大程序比小程序稳定(保证是一个人写的),为什么呢?

按我的理解就是你程序比较大后,各个模块的耦合性比较小。所以当发生错误的时候(假设有BUG),你也可以类似匠人那样用软件来弥补它或者说对整个程序的运行的结果产生很小的影响(有可能达到无关紧要的地步)。

而程序代码小的时候,每个模块对系统的稳定性影响很大了,所以当一个模块BUG了,那么就严重影响程序的结果。
这样理解对吗?请指教。

使用特权

评论回复
33
程序匠人|  楼主 | 2008-1-23 22:05 | 只看该作者

匠人单独开贴淡“鲁棒性”,就是不想和软件抗干扰搅和在

 农民讲习所 发表于 2008-1-23 13:49 侃单片机 ←返回版面    

29楼: 和老狼握手 

讲得非常好。

俺课本上要加一条:软件纠[硬件的错,越错越远。

站长的鲁棒性,是如何可靠设计软件系统,可以深入讨论,别和软件抗干扰连在一起。 
 

使用特权

评论回复
34
hujiahua| | 2008-1-23 23:17 | 只看该作者

深有体会

我的工作就是做产品的黑盒测试,大部分是功能测试。
我们是做汽车多媒体系统的。每一次软件的改动都要做详尽的测试,一般都要做2周以上的测试。我们从使用者的角度出发去做每一个可能发生的操作观察产品是否能正确的响应每一个操作。比如,多个按键同时按,快速的按,机器退碟时强制堵住不让退碟等等。如果说在这些操作中机器死机了,这个软件就不能被用于生产,需要再改进。
关于电源波动,我们会用设备模拟车上各种极端的电源波形加到产品上。对这些波形,产品都应该做到“从容应对”。死机是决不允许的。

可能这种BT的测试对某些产品有些苛刻,但对于汽车电子来说这些都是基本的要求。如果做不到,应该考虑是否能够竞争这块市场。

以上只是个人工作中的体会,如有不妥也请手下留情,不要拍砖!

使用特权

评论回复
35
hujiahua| | 2008-1-23 23:20 | 只看该作者

^-^

不过这个工作做久了之后就会有个职业病,观察实物就会寻找它的缺陷。总是会发现这个不好,那个不好。呵呵

使用特权

评论回复
36
老狼| | 2008-1-23 23:36 | 只看该作者

hujiahua,只是做黑盒测试是不够的。

还应该做白盒测试,哈哈!

使用特权

评论回复
37
hujiahua| | 2008-1-24 10:47 | 只看该作者

那是自然,只不过由其它部门的同事负责,呵呵

使用特权

评论回复
38
wxj1952| | 2008-1-24 15:01 | 只看该作者

证书考试不会去考谁的个人抗干扰经验或方法。

人民大学计算机软件硕士
软件水平考试>>软件水平考试指导>> 正文

2005年5月系统分析师论文考前练习--软考工程(1)
**出处:  发布时间:2006-07-10


试题1 论系统的健壮性设计 
系统的健壮性(robustness)也称为系统的坚固性或坚实性,这是衡量一个系统能否从各种出错条件下恢复能力的一种测度。引起出错的条件可以是来自系统内部,也可以是系统外部的。比如:一个健壮的系统可以容许数据输入的错误,也可以允许内部组成部件的故障。虽然在健壮性与可靠性之间有着一定的联系,但是两者是不同的测度。根据你实际参与开发的经验,论述下列三个问题: 
[问题1] 
简述你参与开发的系统与软件概要和你所担任的工作。 
[问题2] 
具体叙述你所参与分析与开发的系统和软件中,是如何进行健壮性设计的。采用了哪些主要设计 思想 与设计技术?遇到过哪些问题?采取过什么相应的措施? 
[问题3] 
简述健壮性设计的一般原则。你所实际采用的设计技术和措施的具体效果。现在你认为还有哪些可改进之处以及如何去改进?

 

使用特权

评论回复
39
圆圈| | 2008-1-24 15:23 | 只看该作者

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

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

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

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

使用特权

评论回复
40
2_1_I_C| | 2008-1-24 17:29 | 只看该作者

只得学习

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则