注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

晨枫小苑

来的都是客,相逢握握手

 
 
 

日志

 
 
关于我
晨枫  

西西河水浪打浪,一浪打到网易上。我本是喜欢纸上谈兵的一介草民,在西西河那边开了一个小铺子,这是海外华人的一个精神家园。我是一个一坐下来就不动窝的懒人,但架不住友人的邀请,到网易也开了一个茶摊。阿庆嫂是怎么说来着:来的都是客。希望您能喜欢我这小号。来来来,先握一个手! 当然,主有主规,客有客道。请勿随地吐痰,喧哗扰众,或者乱贴小广告。不欢迎指桑骂槐,更不准恶语伤人。

网易考拉推荐

从丰田车控谈工控编程(下)  

2014-01-01 11:31:18|  分类: 科海泛舟 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
6、对操作系统的代码没有深度校核,选用的操作系统没有通过认证

操作系统应该认证。丰田使用未经认证的系统,这是自找麻烦。但使用应用软件的人,很少有本事或者工具对操作系统的代码深度校验,这个要求过分了。美国海军使用Windows NT作为宙斯盾的平台,香港赤腊角机场管理也是,早期曾出现死机问题。他们这样人力物力丰厚的地方都没有能力深度校核操作系统深层代码,一般工业公司就更不可能了。

 

7、关键进程死后,公用变量没有保护

如前所述,控制系统中公用变量和一般程序中有所不同,所有测量量、控制作用都是公用变量,这些公用变量不受关键进程死机的影响,它们和物理变量相连接。另一种公用变量是关键进程的计算结果,但这个数据是公用的,比如化工厂里反应器的转化率。这样的数据一般是放在专用的placeholder里,施主进程不更新,数据就保持不变;施主进程死机了,数据也就冻结了。由于数据本身是合理的(不是乱码,不超限),简单的校验是看不出数据是不是正确。冻结检测可以发现数据已经超过一定时间没有变化了,但这不一定可靠,有时候这数据确实就是长时间不变的;延长检测窗口最终是可以发现冻结,但要等很长时间才能确定冻结,发现的时候就太晚了。另一个办法是由施主进程在写入计算结果的时候,同时写入一个心跳heartbeat)信号,现在是0,就写一个1;现在是1,就写一个0。受主进程在读用 计算结果的时候,同时检测这个心跳,如果超过一定时间心跳冻结在一个数值,这就是说施主进程死机了。这时有几个办法:一个办法是不用计算结果,但有时这是 不可能的;还有一个办法是降低控制增益甚至冻结控制输出,直到信号恢复;要是这不是唯一的输入的话,可以在几个同质输入中调整加权,降低冻结信号的加权, 维持控制。


8
、内存分配容量不足,位置不合理,堆栈溢出造成任务分配表错乱

对于这一段,很怀疑原作者对于堆栈溢出理解错误:丰田的系统里,正好有这么两块相邻的内存块。第一块被称为堆栈(Stack,这是所有Task存储它们运行状态的地方,大小为4KB。与之相邻的地 方储存了操作系统进行任务分配的记录。那么可以想象,如果很多Task给堆栈里写入太多东西,超过4KB,那么就会错误地写入与之相邻的任务分配表。这种 错误被称为堆栈溢出这样的指针管理错误实在太低级。堆栈是后进先出的,如果中断层次超过堆栈尺寸,最近的中断地址就没地方放了, 程序就执行不下去了,这就是我理解的堆栈溢出,但绝不是把数据存到相邻的内存区。丰田很可能堆栈区没有设计有足够的尺寸,递归更加使得堆栈问题无法控制, 但溢出到相邻内存应该是误解。


9
、没有用task来监视task,没有用watchdog自动重启系统

task来监视task, 这就是看门狗。看门狗是实时程序中常用的东西,但看门狗最不能做的事情就是自动重启系统。系统如果当机,不弄清楚是怎么进入这个当机状态的,直接重启,很 可能造成无限重启,问题更大。另外,看门狗要看性质,有时不是系统全面当机,只是局部功能死机,自动重启就是下下策。如前所述,计算机控制系统重启可不是PC机重启,这也是办公室IT和自控IT思维的关键差别。如果办公室PC出了毛病,哪怕还没有死机,IT支持经常首先要你重启一下,如果毛病没有了,就当从来没有出现过这毛病;如果毛病还在,再进一步查找。这是办公室IT的标准程序。但控制系统是24/7/365的,没有天大的事情,决不能贸然重启。不光重启期间全过程要失控,重启后的初始化更要火烛小心,否则就真的搬起石头砸自己的脚了。在工业工程中,看门狗用于提醒操作工或者系统人员:出现异常,这时就要人工按预案补偿、修复。对于不可能人工干预的情况,比如汽车的发动机-刹车控制系统,这就要考虑多余度备份,必要的时候保留模拟控制通道,保持简化的基本控制。丰田在看门狗叫唤的时候是怎么做的,我不知道,但自动重启是要不得的。


10
watchdog只用于监视CPU过载,但容许CPU过载1.5

CPU过载是不好的,但也要具体情况具体分析。实时系统的特点是程序按固定周期反复执行。最起码的要求是在指定周期内要完成所有计算和I/O。但具体分起来,前台(foreground)程序必须在指定周期内必须完成,否则就是overrun错误;累计overrun到一定程度,系统就认定已经无法再完成任务,或者选择性地关闭坏程序,但也可能的是全面崩溃。后台(background)程序则容许见缝插针,在前台程序执行空闲的间隙执行,一个周期完不成,就溢出到下一个周期。要是连续几个周期都完不成,那也引起overrun错误。另一方面, 计算机虽然是数字式的,非黑即白,但在过载问题上,就和汽车发动机转速红线一样,这是指导性的,但不是硬性的。换句话说,发动机转速经常保持在红线上,发 动机肯定要出毛病;但偶尔上红线甚至略为超过一点,并不至于损坏发动机。至于到了红线是否立刻切断油路,这要看应用场合。民用汽车发动机没有太性命交关的 应用,到红线就切断油路是妥当的;飞机发动机就不一样了,有时候飞行员就是要争取这关键的几秒钟,否则就撞山了,这是你给他切断油路,还不如直接给他一枪 自杀算了。控制系统CPU过载也是一样,由于不到万不得已不宜关机重启,适当容许过载一定的时间并无不妥,当然这个容许时间要小心掌握,在使用中也要时刻关注,要是经常出现进入过载但还不到容许时间极限的情况,这就要警惕了,有重大隐患,不能心存侥幸。


11
、用硬件时钟喂狗

硬件时钟喂狗是不妥的,这只监视硬件。根据不同系统,要是时钟死了,整机也就死了;心脏停跳了,还要大脑指挥手脚做反应,这就是荒唐了。


12
Brake Echo Check

如果我理解没错的话,brake echo check是根据刹车片位置传感器的反馈来确认刹车动作,这在化工上也常用,叫valve open/close switch, 泵机等也有类似传感器。这牵涉到控制和逻辑的基本设计思路:一种是开环,根据控制意图发布指令,但发布指令后并不检查是否完成;另一种是闭环,发布指令后 检查系统状态,确认指令得到完成,然后再做下一步。显然,闭环方法更好,但首先需要更多的传感器掌握系统状态,控制逻辑的复杂程度大大提高,而且执行时间 更长,因为要等到确认了系统状态才能进入下一步。这也多了一个新的隐患。有的时候,第一次指令发出后,动作没有完成;控制系统根据系统状态反馈,发出下一 次指令;几次下来,动作完成了。从控制逻辑的角度来说,万事大吉,达到设计要求了。但这实际上留下了一个隐患:为什么第一次没有完成动作?为什么总是要到 第三次才完成?如果能确认原因,这通常引向一个系统的特质,然后针对性地改进设计,可以大大提高执行的可靠性,而不是依靠状态反馈。状态反馈是好东西,但 也会掩盖深层问题,忽略了深层问题而依靠状态反馈擦屁股,最终是要被踢屁股的。有时问题是累计性的,前面几次依靠状态反馈最后完成了,但反复尝试的次数越来越多,最后再试也不管用了,这时就晚了。还有一点:多一个状态反馈,就多一个出错点。如果状态反馈传感器故障,控制动作正确执行了也不管用,控制系统还是傻等。开环方法还是闭环方法要看具体应用的关键性,还要看执行机构和传感器的相对可靠性,否则会自己给自己上枷锁。


13
、刹车触发动作change of state

原文中对刹车触发动作的描述语焉不详,可能这是latched logic还是momentary logic的差别?前者根据系统状态将控制输出锁定在指定位置,后者则用脉冲信号将输出一次性推到指定位置,然后控制信号回中。两者各有优点。比如汽车车灯就是latched,而照相机快门就是momentary。还有一个可能是指根据系统状态(是0还是1)做出控制动作,还是根据系统状态变化(从0变到1或者从1变到0)做出控制动作。这一段看不懂作者在说什么,不大好评论。


14
、顶层设计:没有考虑mutually exclusive actioncross check

 

原文指责丰田在顶层设计没有考虑mutually exclusive actioncross check,这确是对关键控制动作的基本检查。不过针对不同控制任务,mutually exclusive action集是不同的,有的时候绕了几个圈子后可能发生冲突,要很小心,别把自己绕住了。比如说,驾车时,右脚在油门踏板上,就不能在刹车踏板上,这在通常是对的,但飙车时是可以heel and toe的,也就是在踩刹车的时候同时拖一点油门。这是为了保持发动机转速不掉下来,在出弯的时候可以更快地加速。即使不做heel and toe,驾车人也可能错误地左脚踩刹车,右脚踩油门。对于开惯手动车的人来说,如果新换上自动车,还不习惯,左脚找不到离合器的时候,偏一点踩到刹车上,这是很可能出现的错误。如果控制系统死板地认定刹车和油门不可能同时踩下,而对控制逻辑做相应的设计,这就要出大问题。作者后面提到刹车优先,在刹车踏板踩下时,无条件关闭节气门,切断动力。认为如果这一点做到,即使上述mutually exclusive action没有做到,也可以保证安全。同样的问题,这不能解决heel and toe的问题,也容易在意外同时踩下两块踏板时过度减速,造成追尾。如果刹车优先在刹车踏板踩到80%以上才启动,可以解决这个问题。


15
、节气门大开导致刹车助力不足

 

这个不知道是Michael Barr的错误还是解读他的人的错误,汽车发动机进气系统的节气门与刹车是两个系统。轿车刹车是独立的液压系统,与发动机进气没有关系。即使是卡车上的气刹车也与发动机进气没有关系。(这一点我的理解有误,真空助力确实是和节气门有关)

丰田的控制编程可能有很多严重问题,相信Michael Burr是有根据的。原文的解读也是花了功夫的,作者似乎是软件业内人士,至少对 软件工程很熟悉,但对于实时控制软件的很多基本特点不甚了了,而是套用通用软件的概念,得出的结论就容易有偏差。但是作者的一些观点还是正确的。控制从业 人员越来越借助计算机实现控制算法,编程早已不是选择之一,而是主要吃饭家伙。另一方面,控制从业人员的基本训练中,软件工程训练不足。这本来就是一个无 底洞。软件发展那么快,几乎所有新颖软件都有控制应用,比如说,HTML已经广泛用于人机界面设计,JAVA也开始大量使用。随着机翼不同软件平台的MESDCS的进一步整 合,未来跨平台应用都会出现。控制从业人员一方面要不断提高自身软件工程的素质,另一方面也依赖软件行业提供更先进、有力的软件环境,帮助、鼓励甚至迫使 控制从业人员采用软件工程的原则。隔行如隔山,有软件专业人员编写控制程序就像由药剂师开处方一样,说到底是十八般武艺用错了地方。对于控制软件和应用来 说,软件专业人员的贡献更在于提供工具,而不在于具体解决问题,自控还是应该由自控专业人员主导,只有他们才更理解控制问题的特质。

  评论这张
 
阅读(3225)| 评论(46)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2016