首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

硬件开发流程

硬件开发流程

本帖最后由 look_w 于 2017-9-22 21:36 编辑

开发流程经验:
图2 硬件开发流程框图2
        基本思想是使每一步流程具有严密的逻辑;每一步流程可操作;每一步流程的输入、操作及输出受控。
        1、硬件系统需求
        硬件系统需求直接来源于对产品需求的分解。个人觉得产品需求下尽量不要存在产品系统方案或总体方案等文档,再由系统方案分解出硬件、电源、软件、机械等需求。原因在于:
       (1) 个人觉得,这样的文档体系过于复杂,维护成本过高;
       (2) 另一点是在实际工作中的体会,一般这样的文档是需要多个专业组共同维护的,这种公共文档存在极高的出错可能。一方面,在变更管理中,各个专业组的受影响文档往往仅会到专业组需求级,而“惯性”地遗忘系统方案这一上层文档,造成公共文档处于无人维护状态;另一方面,即使某一专业组在变更管理中对公共文档进行了维护,但由于这份文档牵涉到其它专业组,存在误更改的风险。最后,系统方案等上层文档往往是由系统工程师完成的,由于其所处的层次,往往在文档撰写中具有随意性,会将某个专业组的需求放大或加入不相关的需求,从而造成测试的困难。比如,系统方案对硬件的描述为“具有报警音功能,且音量符合XX标准。”音量符合XX标准,往往应该是整机需要验证的内容,但现在却加入到了硬件需求中,而硬件可能并不具备相关的标准知识和测试手段去验证它,这就造成了无法封闭的可能性。
         在硬件系统需求阶段时,除了归档《硬件系统需求》文档外,还应当归档《硬件系统测试方案》。这样做的原因在于:在归档技术文件进行测试前,研发人员会对硬件各个版本进行自测,而此时测试方案未归档受控,这就存在“作假”的可能性,比如按照某一条判断标准,某项测试是不能通过的,如果分析认为此项FAIL不会带来影响,便不会从根本上去查找原因并进行更改,反而可能通过修改判断标准让此项测试得以PASS。另一方面,在需求提出时,测试方案也就应该提出了,测试项与需求项是一一对应的。
        在撰写需求和测试需求时,个人认为需要注意以下几点:
        (1) 对应性。硬件需求应与产品需求对应,不可多也不可少。少了则意味着需求没有被完全分解,有遗漏项;多了则意味着有错误的需求或不相关的需求。同理,测试方案应与需求对应,同样是不可多也不可少。
        (2) 准确性。需求是可验证的。所谓可验证,最简单的方法就是让很多个从未从事过此项测试工作的人,按照撰写的测试需求,可以进行测试操作并且得出的结论一致。下面这个例子便属于需求不准确所造成的不可验证:某项测试标准为“LED灯发出明亮的红光。”粗略一看,似乎没有什么问题,但如果实际去测试,就会发现“明亮的”无法验证,或者说不同的人去测试很有可能会得出不同的结论。
        2、硬件系统方案
        根据硬件系统需求,得到硬件系统方案,为硬件单元划分、互连的重要参考文档,关系硬件系统的架构。
        方案文档体现的是设计指导,是一种过程文档。虽然在一些审查中,不会被关注,因为审查一般的思维是“我需要实现什么需求?”和“这个需求最终有没有被验证实现”,因此其关注的重点更多在于需求类文档和测试类文档。但不能由此就轻视了方案文档。不同的设计虽然可以实现同样的功能,但一个好的稳定的方案,可以减少后续因不满足需求而导致的方案更改,同时还可使产品获得更高的性能、更低的成本。
        3、硬件单元需求
        硬件单元为最小可验证功能单元,不一定是指某一个单板,可能是实现某一个功能的所有单板组合。硬件单元需求来源于硬件系统需求,需与其对应。在归档硬件单元需求时,同样也需要归档硬件单元测试需求。
        4、硬件单元方案
       根据硬件单元需求,得到硬件单元方案,为硬件板卡原理图和PCB设计的重要参考文档。
        5、硬件单元测试
        硬件单元测试是对硬件单元需求的验证,其是在硬件单元测试方案的指导下进行的。
        如前所述,硬件单元测试需在板卡技术文件生效后进行。除此之外,还需要将测试用到的软件和工装生效,如果借用以前的工装,需要保证工装在校准有效期内;测试设备也同样需在校准有效期内。这样,测试所需的输入便全部受控。
        测试过程中,需要严格按照测试需求执行操作,并准确记录结果,每一项测试都应记录测试人和测试时间。
        测试完成后,需要输出并归档测试报告。如果测试发现问题,个人理解有两种封闭方法,有时考虑到更改成本,可以进行风险分析,按照严重程度和发生概率,如果在ACC内,便可通过出风险分析报告进行封闭;另一种方法则是启动变更管理对设计进行更改,升版DHF和DMR,并重新进行测试。
        6、硬件系统测试
        硬件系统测试是对硬件系统需求的验证,其是在硬件系统测试方案的指导下进行的。
        同样,在测试前,需将所有的输入归档受控;测试过程中,严格执行和记录;测试完成后,进行报告归档及问题处理。
开发排除故障:      学生频繁出现“卡壳”现象:看似很简单的设计,却死活调不出来,人都快疯掉了。大约一周前,小陈来找我的时候,一副悬崖上抓不牢树枝,就想自己松手跳崖的样子,猴急的都想给我说难听话了。这两天,小陈的问题找到了,解决了,又快乐了。但是常伟的问题又来啦。

       用MSP430F169单片机给程控增益放大器PGA280实施SPI控制,正常,同一个单片机给一个24位ADS1259实施控制,也正常。但是两个同时都焊上,用CS片选分别控制,就不行了。问题就这么简单,却让他焦头烂额。

       解决问题是迟早的事情,我不担心,并且发现问题解决问题,本身就是对他们的锻炼,我才高兴呢。但是,我发现他们无一例外的,都陷入了一种混乱的状态:出现问题,开始左试试,右试试,有时成功了,高兴了,吃饭回来,又不行了,接着试。就这么反复折腾,总有崩溃的时候,就开始发火,焦躁,然后满世界找人帮忙,特别像落水以后找稻草。这种状态持续3天以上,他们就开始对我发火了。

      我告诉他们:故障出现是好事,第一锻炼了你们,第二排除了隐患。不到万不得已的时候,我是不会出马的,我只需要教会他们排查故障的三大必须,就可以了。

       排查故障是一门学问,深得很。但笼而统之,就三大必须,有了这三条,没有排查不了的故障:第一、心态,第二、策略,第三、耐心。


第一条心态       你必须对出现的故障,有强烈的感激。谢谢上天给了我这个机会,我要牢牢把握住。你可以想象自己是福尔摩斯,已经好几个月没有接活了,和华生天天闲聊已经没有意思了,急切希望有个案子,苏格兰场束手无策了,等着你出马了。只有这种心态,才能让你能够在后续的长期斗争中保持亢奋的头脑、缜密的思路以及足够的耐心。

       我最大的特点就在于此。学生给我汇报故障的时候,我通常是特别兴奋,一字一句听,像听考题一样,他们漫不经心的,我的眼睛却犀利如刀。我特别希望我的学生能够学会这一点。


第二条策略
这是技术活。细讲太多,粗粗说点儿。

1)让故障重复出现,避免随机性故障。对随机性故障,我找机会另说。

2)保护故障现场,不轻易乱动。动的无论是软件还是硬件,都应保证可以恢复。因此,别随意焊下芯片,焊下的芯片也要放好,能找回来。另外,软件一定要按照序号备份。

3)不要一次做两个以上的改变。

4)养成习惯,用个小本记录所有的动作和事实。换了个电源,看似小事,有可能由A故障变成了B故障,你脑子就乱了。因此,如果要换电源,也要记录。

5)重视仪器和操作方法。每次记录事实,一定要确保事实是真的。

6)学会用逻辑的思维。主要是,造成这种故障现象的可能性有多少种,一一列出,可能性最大的到可能性最小的。

7)学会排查次序。影响排查次序的有两个主要因素,第一故障可能性,第二排查难度。我们当然要先试探可能性最大的,且排查难度最小的。但是两者并不总是这么巧。比如,你怀疑是A芯片坏了,这可能性最大。但是把它焊下来很费劲,排查实施难度较大,就可以先排查别的可能。这一项有点运气成分,也有点经验成分。

8)学会二分法并巧妙使用。二分法,就是把故障分为两部分(或者三部分,别太多,否则会乱),然后制造一些情况,想办法确定是哪部分,然后再细分,逐渐缩小包围圈。以前日本鬼子查城区里面哪里在发报,就用这方法:一个区域一个区域停电,看哪里一停电就导致电报信号消失,就能确定发报者在哪个区域,然后再缩小区域停电,最终找到我们的地下工作者。几句话还是说不清,我找机会再说吧。

       当按照这种缜密的思维方式,罗列了所有故障可能性,且一一排查均无结果的时候,你应该更加亢奋。就像给一个1k电阻加了一个1V直流电压,测量的电流却不是1mA一样,你应该有这种心态:活见鬼了,难道欧姆定律都不成立了吗?

        此时,找老师,找朋友,找什么人都行。但是,有谁做到这一步呢?多数学生都在这个阶段,彻底崩溃了。


第三条,足够的耐心
       我曾遇到一个故障,就是电源电流太大。密密麻麻一大堆芯片,工作也算正常着,就是电源指示电流偏大,我知道一定是哪里短路了或者临近短路了。但是怎么查啊?关键是整个系统工作是正常的。

       当时我自己告诫自己,要耐心,我不同于一般人,我有足够的耐心一定能查到。于是,我先用放大镜把板子上所有位置都看了一遍,看有没有焊接短路或者飞溅焊锡,花了很久时间,记不得了。然后,我看着电脑上的PCB图,把所有在10mil附近的间距,都用万用表查了一遍,还是没有。有点恼火了,于是我又告诫自己,不是一般人,不是一般人,接着来。

       这次我干什么了呢?谁也不会想到我有多大的恒心:我计划把芯片的每一个管脚,或者叫电路板中的每一个节点,都和其它不应该连接的节点,都测一遍。这得测量多少次啊?但我豁出去了。于是,我开始干了。好在当时的芯片,都是DIP封装的,管脚不是甚多,我一个个查,终于查到了。其实时间也不是太长,一两个小时而已。

       结果是,两根完全不相干的输出线,短接了,而电阻不是0,记不得是多少,大约就是几个欧姆的样子。我左看右看,他们都不会相连,只有一段大约几个厘米的区间,它们两根线平行走过。我割断,不短路了,短路局限在10cm左右了,再割断,最后局限在1cm左右的空间中,两线平行,但是短路。而两线的间距有差不多3个mm。

       这板子已经被我折腾的不成样子了,但留下了一个千古疑问:两根间距3mm的线,在1cm长度内,居然短路了。我用放大镜看着,没有痕迹。我举起来对着刺眼的台灯,仔细看,一条细细的痕迹出现了,那么细,那么曲里拐弯,就有一根不透明的细线。

       我举起割刀,在3mm的间距中深深的割了几刀,短路消失了。

       这是上世纪九十年代中期的故事,我记忆犹新。

      没有如我当时之耐心,这样的故障是难以查到的。

      可能会有人说,这是一个个案,印制板的质量不好,你查到又有什么用呢?板子已经废了。但我有不同的认识,查到了,我就可以拍胸脯了,自信心比什么都重要。至今我仍然能够保持足够的自信,学生遇到问题,我不急,慢慢查着去,过了我的期限,我绝不相信,到我这里还查不出来。

       心态好,有缜密的策略,有足够的超乎寻常的耐心,是排查故障的三大必须。很多人可能会注重技术性的策略,这当然很重要。但我发现,最重要的恰恰是第一条和第三条,它们不是想学就能学到的,而是要悟要养的。
返回列表