智物联,引领工业物联

我们始终以技术创新创造价值,并夜以继日的将互联和工业智能的力量融入到各行各业
以前所未见的高度、速度、精度和深度,让关键所在 逐一实现。

咨询服务

技术干货丨工业设备如何实现在线诊断?


【摘要】: 什么是在线诊断? ODS(Online Diagnosis Service)是MixIOT体系中的一个在线诊断服务组件。

什么是在线诊断?
ODS(Online Diagnosis Service)是MixIOT体系中的一个在线诊断服务组件。

 

“在线诊断”的定义比较复杂:
选择一个长度合适的时间段,作为诊断的计算分析周期;

  • 有明确的诊断对象;
  • 有明确的、该对象需要诊断的“问题”;
  • 有明确的、该对象所发生的一种或多种表象特征;
  • 在计算分析周期内可以跟踪记录该对象的这些表象特征;
  • 有预知的,或者可以预设的,一个或多个这些表象特征与问题之间概率关系;
  • 有预知的,或者可以预设的,一个或多个表象特征之间的概率关系;
  • 有预知的,或者可以预设的,一个或多个问题之间的概率关系;

 

以这些概率关系为条件,以计算周期内该对象的表象特征为依据,连续计算该对象会发生这些问题中的某一种(或某几种)的概率。

 

这个定义实在是不太好懂,我们以人得病为例,逐个来解释。

  • 1. 要选择一个合适的时间段作为计算周期。比如,是一天、一周,还是一个小时、一个月。假设我们选择了一个月(30天),并不是说只从12月1日到12月31日,而是说,我们计算的数据是计算这个时候之前30天之内的数据,半年前的数据是不用的。一般来说,这个周期越长,诊断的可靠性就越高,但是,所需要消耗的算力也就越大,出结果就越久。具体要怎么选择,还是需要根据实际情况。对那些时效性很强的问题,选择太长时间周期的数据并没有太大意义。但是如果周期选择的太短, 很可能就诊断不出什么。

 

  • 2. 要明确诊断的对象是谁,这个好理解。比如,一个人。

 

  • 3. 我们需要有明确的可以诊断的“问题”,一个或者多个。这里说的问题,是一个人的病症。这不是采集出来的,而是需要判断出来的,比如“窦性心律不齐”,这就是一个问题。在ODS系统中,“问题”就是一个目录。这个我们后面会讲到。

 

  • 4. 表象特征。这是我们能测量的,能采集的。比如体温、血压、血糖、胆固醇、心电图、脑电波、X光片,或者咳嗽,吐血、便秘等,就像临床症状。我们看到一个人的心电图上波澜起伏,这些都是客观的表象特征,医学上就叫临床特征。而医生根据这个心电图和其他的体温、血压等,做出这个患者是“窦性心律不齐” 的判断,这个是一个诊断结果。

 

  • 5. 刚才说的这些表象特征,在计算周期之内我们是可以不断采集到的,也是可以不断统计计算出来的。

 

  • 6. 预知的、预设的表象特征与问题之间的关系,就是临床症状跟诊断结果之间的关系,比如,“血糖高” 是“窦性心律不齐” 这个病症的概率是13%。这个是怎么来的,可能是之前的统计结果、研究结果,也可能是经验。如果之前我们并没有这个值,就可以设定一个值,未来等数据多了再去修改。

 

  • 7. 表象之间的关系,这就像临床症状之间的关系,比如血糖和血压,血糖高同时血压也高的概率是21%。

 

  • 8. 问题之间的关系,比如窦性心律不齐(问题A)和冠心病(问题B)是两个问题,有问题A的患者患问题B的概率是67%。

 

  • 9. 最终的诊断结果就是基于这些表象特征数据(临床症状)和相互关系而计算出来的。

 

我们在《工业互联网核心引擎原理与实现》一书中,多次讲过一个道理,工业设备(尤其是复杂的工业设备和装置) 的机理是非常复杂的,我们看到的绝大多数故障的成因非常复杂,很难用简单的因果关系来解释。ODS实际上是提供了复杂的多元因素跟结果之间综合关系的一个计算服务,理性科学地揭示多元因素对一个结果的共同作用的可能性,在没有规律的地方发现规律。

 

表象特征和问题
ODS 里面,表象特征和问题这两个概念是比较难弄清楚的。

 先说“问题” :“问题”就是我们已知的一些“疾病”的名称,仅仅是名称而已。要记住,这些名称是医学人士给的,不是“病症”。这一点我们经常容易搞混。比如,小李今天请病假,你问他什么病,他可能会告诉你“发烧”。其实,发烧是可以用体温计测量出来的,假设我们定义,体温超过38摄氏度就是发烧,那么“发烧” 并不是“疾病”,而是“临床症状”。小李去看医生,医生的诊断是“上呼吸道感染”,这才是“疾病”。如果小李去另一个医院看病,另一个医生可能诊断并不是 “上呼吸道感染”,而是“急性肺炎”,这也是“疾病”。

 

那么,会不会有某个医生给小李的诊断结果是“旺火”这个疾病呢?不会!因为在医生的字典里,并没有“旺火”这个名字的疾病。小李是“上呼吸道感染”也好,“急性肺炎”也罢,不管是什么,诊断的结果都应该在医生的疾病字典里面。换句话说,医生是不会诊断出不在这个字典里面的疾病的。临床症状与疾病的关系,可以用下图来表示。

▲ 临床症状X与已知疾病的概率关系

上图的意思是,首先我们有一个“已知疾病”的字典,这就是我们的“ 问题表”;其次,我们还要有一个某个临床症状与这些疾病之间概率关系的值。我们也可以倒过来说:疾病A、B、C会出现临床症状 X 的概率分别是多少。

 

如果医生只凭一个临床症状就可以来诊断我们的病,那也未免太草率了。我们平时去医院看病,都会抱怨医生为什么要让我们做这么多检查,其实,这就是因为医生希望得到多个表象特征。


▲ 临床症状Y与已知疾病的概率关系

如图临床症状Y与已知疾病的概率关系。如果除了X,我们还能拿到另一个表象特征 Y,Y也与问题库中的某些问题有对应的概率关系。见上图。


▲ 同时发生临床症状X、Y与已知疾病的概率关系

那么,这个对象的两个表象特征与问题表中问题项的概率关系,就变成了上图这样。我们就可以看到,有两个表象特征的时候,对应问题B的概率就大了。

 

是不是表象特征越多,对定位问题就越准确呢?

 

表象特征和表象特征之间&问题和问题之间

 

上面我们说了,表象特征和问题之间的关系,感觉应该表象特征(临床症状)信息越丰富、数据越多,问题(疾病)定位就应该越准确。这不能说是错,但是并不准确。因为这种说法没有考虑到两个很重要的因素:一个是表象特征与表象特征之间的关系,一个是问题与问题之间的关系。

 

有时候,当一个表象特征(临床症状)出现的时候,十有八九会伴随着另一个表象特征的出现, 这个在医学上叫“并发症”;而有时候诊断出来一种疾病,很有可能还同时患有另一种疾病。

 

这就是所谓的表象之间、问题之间的关系。


▲ 表象之间的概率关系

 

这也是我们一个非常重要的计算依据。这些概率关系是需要预先设置的,见上图。

 


▲ 问题之间的概率关系

 

我们关注问题之间的关系,可以判断是否还会有一种新的可能,这可以理解为隐藏更深的疾病,见上图。

 

初级诊断和高级诊断
目前ODS还是个初级诊断模型,这是因为只用了一组诊断方法,即概率的方法,如下图所示。从这个意义上讲,现在的ODS只是一个连续计算复杂概率关系的计算器。

▲ 初级诊断示意图

 

那么,高级诊断又是什么呢?那就是同时使用多组诊断方法,这样就可以对诊断结果进行交叉验证。

 

所谓诊断方法,就是诊断依据,概率的方法只是其中一种。当我们能引入第二种方法的时候,ODS就成为一个高级诊断,如下图所示。

 


▲ 高级诊断示意图

 

诊断报告

ODS是MixIOT体系中的一个服务组件,以项目形态来管理。首先需要创建ODS项目、设置项目属性、写脚本等,这个套路我们应该很熟悉了,就不花篇幅去说明了。具体怎么用还是需要去看ODS的使用指南,最重要的是掌握表象特征表达式的写法,这个在使用指南里面有详细的说明。

 

ODS的结果,是以诊断报告的形式输出的。所谓诊断报告,其实也就是一个诊断结果的简要文字描述。诊断报告生成的时间,是按诊断项目规定的诊断周期来确定的。

 

关于周期,这里有两个概念,一个是诊断的时候用多久以来的数据,比如最近的一个月、一周还是多久;另一个就是诊断的间隔,多长时间去计算一次,一般来说可以一天一次,这样,诊断报告就一天出一个。

 


▲ MixIOT系统中诊断报告界面

 

与其他的几个服务组件不同的是,ODS需要做很多的基础信息准备工作,这就是前面说的,表象特征与问题之间的概率关系,问题与问题之间的概率关系,表象与表象之间的概率关系。也就是所谓的“先验概率表”,这是一个挺大的难题,是需要长期积累的,而我们之前未必已经有这方面的数据和信息,要想让ODS发挥作用,还需要对这些基础信息进行准备。

 

所以,ODS并不是一个立竿见影的东西,从我们启用开始,到能真正产生作用, 还需要一些时间和积累。这就像我们要学完医科毕业后,还要几年实习,才能去开诊所治病救人。

 

再论“问题”
ODS最核心的地方,就是“问题”。

 

尽管前面做了很详细的介绍,但是要真正理解“问题”并不是一件容易的事情。所以,我们不得不回过头来,再加以理论,因为这个概念稍有混淆,ODS就可能得出没有意义的诊断结果。

 

首先要理解,“问题”就跟医学上定义的“疾病”是一样的,这只是一个主观的定义,就是一个名称,而不是一个现象。我们举个例子,如果看到“美尼尔氏综合症”,你可能根本不知道这是什么,但是,这就是一个确定的疾病名称。

 

一个患者被诊断为“美尼尔氏综合症”,是医生根据患者的各种临床症状“表象特征”给出的诊断结果,表象特征是客观的,诊断却是基于客观依据的主观行为。换句话说,“美尼尔氏综合症”是一个客观存在的名称,临床特征也是客观存在的事实,诊断是医生把这些客观存在的“临床特征”与“美尼尔氏综合症”这个客观存在的疾病名称关联起来的一个主观行为。所以,另一个医生有可能把相同的“临床特征”与“地中海贫血”关联起来也不一定。

 

这可能是ODS在实际使用中存在的最大问题,很多人尝试用ODS去诊断故障的发生,这是没问题的。但是如果这个故障我们本身就能采集到,是无须去诊断的。我们要诊断的是问题,这个问题可能是故障,也可能是故障背后的原因。

 


▲ 设备表象与诊断问题

 

ODS与线索构造

在MixIOT体系中,我们讨论过“线索构造方法”,并介绍了把线索构造方法用于判断 Aprus适配器问题的应用(Aplec)。你现在一定在想,线索构造也是用来发现问题的,ODS也是诊断问题,它们不是一个东西吗?它们的区别又是什么?在实际项目中,我们是用线索构造方法好呢,还是用ODS诊断好呢?

 

“线索构造方法”跟ODS其实是两回事,“线索构造方法”是去构造“与某个概率事件有一定关系”的“线索”集合的方法。我们上面的例子,只是用线索构造方法来判断适配器是不是有问题而已。

 

在ODS里面,我们需要有一个先验概率表,就是我们需要已经掌握很多“某个特征表象跟某个问题之间概率关系”的信息,这有点像“老师傅的经验”,如果我们之前完全没有这方面积累,那这个ODS我们也没法用得很好。

 

“线索构造”不是“经验”,而是“推理”。比如,如果平台收到一个适配器的N报文,我们就可以肯定,这个适配器在收到这个报文的前4个小时肯定是在工作的;如果我们把该适配器最近4个小时的全部报文拿出来看看,没有发现其中有I报文,那我们还可以肯定,这个适配器在前面4个小时里面肯定没有重启过;如果最近4个小时的报文里面,R报文超过480个,也就是平均每30秒有一个,那我们至少可以认定之前的4个小时里面的工作是“基本正常”的;如果最近4个小时报文中,我们还能看到一个D报文,而且这个报文中诊断是正常的,那么我们就可以根据刚才说的几条线索:
● 有一个N报文;
● 没有I报文;
● R报文有480个;
● D报文自诊断没问题。

来断定这个适配器是OK的。

 

说到这里我们顺便说一下另一个话题。本文介绍的ODS也好,之前介绍过的“线索构造”也好,它们的目的都是为了去“判断”或者“识别”,如果我们往大里说,这就有点“人工智能”的味道。实际上,“人工智能”有三个分支:以推理为主的、以知识和经验为主的和以学习为主的。以学习为主的这个分支,就是所谓的“机器学习”分支。我们都知道,机器学习需要大量的“学习资料”,如果没有这些学习资料,那机器学习也就只能是无米之炊。

 

虽说工业物联网是当下热点,但毕竟也还处于起步阶段,工业企业在“学习资料”方面的积累基本为零。所以,我们事实上并没有办法一步到位,只能老老实实从“推理”开始,逐步积累“知识和经验”,把这些“推理”的结果、“知识和经验” 形成“学习资料”,才可能最终进化到真正的“机器学习+人工智能”。

图片名称
图片名称