您当前的位置:检测资讯 > 科研开发

用架构设计提升电子产品可靠性的方法

嘉峪检测网        2022-12-01 10:11

       大家是不是经常听人提到架构,朦胧中也会觉得这是个好东西,可落实到现实中,架构到底是个什么玩意儿?看个书又弄的高大上,错综复杂,忙绕无头绪。用大白话,用通俗方式,讲述简单而深刻的道理,便是我的方向。
 
       管理学上有个名词,结构效率远远优于运营效率。
 
       例如:一个大设备的生产,有10道工序(假设工序用时是均匀的),1人完整的装配完1台需要1天(10h小时),10人1天里每人装了1台,在每道工序上耗费的时间为1h。该人每天每道工序的装配水平就是1h的水平。他每天多加1h班在某道工序上,也不过在该道工序上是2h的水平。
 
       现在改成流水线作业,10个人每人负责一道工序,10个人一起完成这一天总共10台的工作,这样1人1天(10h)对负责的工序重复了10次,试想一下,一个人一天在一道工序上重复了10遍和做了1遍相比,哪个更熟练效率更高?后者不用加班,每天就是10h的熟练程度。
 
       前者靠加班提升,这是运营效率;后者靠分工的组织架构提升,这是结构效率。
 
       另一个例子,一锅炉温度监测软件,在一个大程序架构里,A、B、C三位工程师均会用到温度参数,分别根据测量结果用于调节通风、送煤、报警。于是ABC分别各自编写了这几行并不复杂的程序。
 
       A调试时,遇到了测量结果偶超出100度的问题,于是加了上下限判断干扰数据丢弃处理;
 
       B调试时,遇到了前后两个测量时间相隔几秒但温度却差别很大,水温不应该出现的干扰情况,于是B加了温度变化率的判错功能。
 
       C调试时,发现了一个50Hz工频干扰,于是加了50Hz陷波搞定。
 

 
 
图1
 
       如上编程的话,三个人各有各的经验,却相互之间不能共享,当到了用户现场后,万一A遇到了B、C的问题,而A的代码里没有相应措施,是不是会带来召回或维修?通过ABC三人之间的交流来弥补各自的欠缺,管理效率上是不是也会有较大的漏洞?
 
       如果将此软件架构改成图2的形式,单独设置ADC()函数,A、B、C三位工程师分别调用该函数的功能,A发现超限,则反馈给ADC函数的编程人员,将上下限判断的功能加入ADC();B将温度变化率的判错功能、C将数字滤波的功能也都加入函数ADC()。这样ABC三人的代码,每个人是不是都享受到了三个人的经验?
 

 
 
图2
 
      再例如:一个硬件的大系统,外围有诸多的功能,中央控制单元用一个大型的MCU实现调度和控制(图3左图),可想而知,各个部分之间的时序分配、中断的交叉,对硬件设计师和软件设计师会有多少逻辑上的复杂需求;
 
       改变一下思路,换成图3右图的架构方式,能独立出去的终端功能用独立的小型MCU实现,用一种“分散、自治、多元化”的设计思想,将一个强力中央单元的功能分散到诸多个诸侯国去,中央单元仅实现各部分之间的调度,将数据处理功能有各自单元独立完成。试想一下,软件调度逻辑和每部分的硬件难度是否可以大大降低。一个不太方便明说的示例,就是中美领导架构的对比,我们国家的高层领导的工作难度就比美国要难得多,原因是大事小情都得上面操心,而美国,联邦是联邦,各州是各州,分散了。是否与此同理?
 
 
图3
 
      类似的事儿还有很多,比如DCDC电源种类的选择(并不是归一化就真的好)、晶振频率的选择、结构布局等等,从架构的角度去考虑设计方案,甚至有可能会颠覆曾经一直以为是宇宙绝对真理的三观。
 
      架构的改善,带来的将是质的提升。但架构却又是一个“好人不愿干,差人干不好”,“干好了没人知道,干坏了也没人知道”的事儿,当然更多的是,做架构设计的人、被差的架构祸害的人,被好的架构荫庇的人,好多都还没意识到架构的价值和方法。
 
   

 
分享到:

来源:Internet