原创 由avan的一幅图想到的...

2007-12-7 09:56 5279 5 8 分类: 工程师职场

    昨天在avan的博客上看到了一幅硬盘读盘失败的故障树,由于我现在的工作与硬盘关系很大,今天早上又细看了一遍。这一看可不得了,引发我把最近的许多思考都联系了起来。本想回复在avan的博客上,可是越写篇幅越大,还是放到自家博客上来吧。


    原图转载如下:


c735dbb9-6323-4710-9ffb-066309ad4b1d.jpg


    这幅图的意义不仅仅在于它提供的硬盘故障信息。


    在硬件调试过程中,经常需要从故障现象反推回故障原理。在这样复杂的一个树根图上,从树根的底部可以一步到达树的主干;从树的主干想要到达树根底部可就难多了。从结果向原因逆向推导太难了。


    与此相同的是小时候玩的纸面迷宫游戏,从入口走向出口难,不但容易走上岔路,还容易从另外的出口走出去;但是反过来从出口走向入口就容易多了,至少已经知道出口在哪里。 riple


8fc2e53c-5b14-4ff6-8d60-e01fb51701dc.jpg


    另一个有相同现象的游戏是“扫雷”。最近LP大人很喜欢玩这个游戏,往往以能够通关为傲。我在一旁侧眼观瞧,发现确实有些门道:游戏设计者生成一幅雷区分布图很容易,这是正向设计;扫清雷场有时候就是逻辑推导不能胜任的,必须加上点猜测。一些决策分枝点很关键,也是决定输赢的转折点,在这些点上存在完全等价的多种可能。 riple


    “扫雷”之所以难玩,也之所以好玩,就在于游戏设计者和游戏玩家的信息不对称。一幅地雷分布图设计出来,其周围的指示数字就唯一确定了,不会存在模棱两可的情况;但是在整个雷场灰蒙蒙一片的时候,玩家只有关于雷场局部情况的不完全信息,这些信息的价值也不完全相等,而且相互之间有一定的关联。即使玩家能够准确的评估这些信息的价值,并且建立这些信息之间的有效联系,在某些情况下仍然不能确定下一步的走向——由于缺少一个或几个关键信息,根据现有的信息会产生不唯一的决策。这时,没有别的办法,只能硬着头皮“踩”一下。 riple


fc7c2ebf-b096-4fd5-b522-0649efb7bc8d.jpg


    与此相似,在获知cannot read data的信息时,如果不能获得区分cannot find data和data missing两种情况的一个或几个关键信息,就不能决定该向哪一条分枝走下去。 riple


    我在硬件调试中经常会遇到这种情况,而且还会遇到更严重的情况:不仅不知道如何选择,甚至不知道有几个选项。这时候就必须通过证明或证伪的方法获得缺失的关键信息,从而决定该向决策分枝的哪一个支路走下去。证明,就是通过合理设置测试条件,通过有效的观察和分析,获得可靠的信息,推论出异常现象的直接原因,正向获取决策信息,从而判断应该选择哪一条支路;证伪,就是先假设一种可能分支,通过这个假设的分支进一步获取信息证明该假设是错误的,从而排除这一分支。证明和证伪的方法往往要交替使用,并且由于人的主观因素,经常会判断失误,经常要走回头路。如何获取信息,如何根据获取的信息作出正确的判断是调试成功的关键。反复实验,合理地增加和去除调试信息,反复分析实验结果,大胆假设,小心论证是成功调试的不二法门。 riple


    进一步,一个产品的设计和工程项目的计划也有相似的情况。理想情况下,在项目立项之初,要把所有不确定的因素确定下来,也就是获得所有信息,这样才能保证项目目标的实现,包括产品的质量和项目的工期。获得的信息可以构成一幅导致项目失败或延期的“故障树”,在我们的文档里称之为“风险列表”。在立项评审时,只有风险定义明确并且解决措施完备的项目才能够通过评审。 riple


    avan在日志里补充道:


 


嫦娥探月工程总指挥栾恩杰说:“分析故障产生的原因,每一个故障可能有几个原因,一层一层地画下去,就画出了‘故障树’。原来我提出的是出了问题要‘举一反三’,现在要求在设计的时候同时把可能出现的故障都找出来,回答出现这个故障怎么办。在设计的过程当中,就把可能出现的问题和我们将要采取的措施和办法做进去。”


多年来,在总结成功经验与失败教训的基础上,栾恩杰创造性地提出了“质量技术问题归零”的概念,并确立了五条判别标准:“定位准确,机理清楚,问题浮现,措施有效,举一反三。”组织制定了一整套具有开创性的航天工程管理与质量管理的新思路和新办法。


 


    在我工作的单位,我们对于每一个项目都要进行预研、立项、概要设计、详细设计、调试、结项一系列的工作。这些天,我正在准备最近一个项目的结项工作。回顾这个项目的开发过程,虽然预研工作很充分,还预留了一定的调试时间,中间还有多个阶段提前完成,可是最后还是延期了。究其原因,是信息的缺失,包括开发者个人的知识储备,开发者个人认识、解决问题方法上的不足,以及对预期问题的缺乏准备和解决难度的低估,等等等等。总之一句话:风险失控。 riple


    失控的原因就是立项时风险预期不充分,解决方法不完备,没能形成一棵健壮的“故障树”。 riple


    往往在一个项目结项时,才能充分地认识到立项工作准备的不足。在立项之初,往往耐不住性子,不愿意多花时间在预期可能出现的问题(风险分析)上下功夫。 riple


    缺乏耐心是一个因素,缺乏经验是另一个因素。现在看来,结项工作真的很重要,当前项目的结项,是为下一个项目的立项储备知识。像我这样缺乏项目开发经验的人,就是通过一次次结项工作,总结经验和教训才能成长起来的。总结经验,就是不断地完善“故障树”的分支,在立项前,心中有了一棵枝繁叶茂的“故障树”,才能做到胸有成竹始下笔。     riple

文章评论3条评论)

登录后参与讨论

ash_riple_768180695 2007-12-11 11:30

从一个角度反映了器件运行整体模型的一个方面。

ash_riple_768180695 2007-12-11 11:27

一棵“故障树”,就是一个很好的模型。

ash_riple_768180695 2007-12-11 11:23

硬件调试(可能软件调试也一样)是很难的,需要调试者全身心的投入,在脑海中建立一个器件运行的模型,然后根据这个模型来判断硬件运行的异常现象,由异常现象推导出故障的所在。

建立模型和抓取异常现象是这里的关键。人脑的记忆力有限,能够集中精力思考的时间也很短,所以必须从无限的信息里抓取有限的关键信息,用这些信息构建局部模型,与异常现象提供的局部信息进行比较。

建立模型需要收集硬件正常运行的信息,并加以总结和分析,掌握它的规律。抓取异常现象需要总结测试条件的变化规律,增加重现的几率,并根据脑海中正常运行的模型推测造成异常的可能原因,然后构建这样的条件,并观察和比较结果。这一建模-分析-重现-假设-证明的过程往往需要多次反复,脑海中的模型也会多次修正和充实。

如果有仿真工具和测试用例的话,就不需要在人脑中建立复杂的模型了,只需要运行测试用例,并观察大量的仿真信号即可。可现实中,构建准确的仿真模型和真实的测试用例是很难的,往往在时间、物质条件的限制下不能实现。这时还要回到人脑建模上来。

相关推荐阅读
ash_riple_768180695 2015-12-18 11:06
学习示例程序:FPGA快速系统原型设计--敏捷实践
        学习与开发板配套的示例程序,是敏捷实践的起点。示例程序是厂商针对开发板上提供的硬件资源和接口量身定做的工程,可以展示其FPGA芯片的功能和性能特点。从示例程序入手最大的好处就是:示...
ash_riple_768180695 2015-11-03 16:46
开发板选取:FPGA快速系统原型设计--敏捷实践
    既然是“实践”,就不能只谈编码和仿真,必须要上板运行、调试。这个虚拟项目的目标是实现一块兼容Intel82574L以太网控制器的千兆网卡,需要运行在一块具备PCIe接口和10/100/10...
ash_riple_768180695 2015-10-22 12:41
开篇:FPGA快速系统原型设计--敏捷实践
    虽然借用了 “系统原型开发”的标题,本系列文章将围绕FPGA IP级别的开发这个主题展开,如果可能的话,将扩展至FPGA System级别的开发。     先上一篇PPT:RSPwFP...
ash_riple_768180695 2013-08-26 10:21
学习SystemVerilog(二)——学习它的理由
    学习SystemVerilog的理由也很多,我在阅读SystemVerilog for Design 和 SystemVerilog for Verification两本书前言的过程中,总...
ash_riple_768180695 2013-08-26 10:19
学习SystemVerilog(一)——不学习它的理由
    想要学习SystemVerilog已经很久了。曾经尝试通过Accellera网站上给出的LRM学习,怎奈内容众多,找不出入手点和重点,只能望而却步。虽然手头有三本SystemVerilog...
ash_riple_768180695 2011-06-26 23:20
Hardware-Assisted IEEE1588 Implementation Analysis
06/18/11 11:00:05 PM         最近一段时间在研究IEEE1588-2008精确时间同步协议(PTP)。该协议可以在软件中实现,如果需要提高时间同步...
我要评论
3
5
关闭 站长推荐上一条 /2 下一条