智物联,引领工业物联

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

咨询服务

技术干货丨灵活使用MixIOT解决各种问题


【摘要】: MixIOT里面能提供的东西是确定的,比如统计计算,是命题式的周期统计计算,而且它能支持的计算方法也是确定的。但是,现实中的需求却是不确定的,在遇到现有的服务组件不能满足,或者不能完全满足实际需求的时候,我们该怎么做呢?下面通过两个例子,来对这个问题做个解释。

MixIOT里面能提供的东西是确定的,比如统计计算,是命题式的周期统计计算,而且它能支持的计算方法也是确定的。但是,现实中的需求却是不确定的,在遇到现有的服务组件不能满足,或者不能完全满足实际需求的时候,我们该怎么做呢?下面通过两个例子,来对这个问题做个解释。

 

实例一
假设,我们通过映射表,形成了一个对象,该对象里面有99个FV,S001~S099。该对象的数据,是以数据拼图(马赛克)方式保存在时序数据库里面。

我们可以用Dashboard(显示板)把这些时序数据实时显示出来,还可以做各种统计计算,这些都是很熟悉流程。

 

如果有这么一个需求,需要实时做这样一个计算:

这是一个FV的计算,但是,涉及到的数据,并不是当前FV的值,而是过往FV的值,而且公式里面很多东西可能会变,比如,FV会变,“最近多少个”也会变。

 

很显然,在MixIOT里面找不到能够做这个计算的应用,也就是说,无论如何,都要做一个新的应用,这个应用的每个项目,就是确定这些FV和“最近多少个”。

我们把公式里面可变的东西提炼出来,变成9个参数。这个应用就用PHP或别的工具来开发,利用API-X 等获取需要的数据,然后每5秒钟计算—次。应用开发好了,创建第一个项目,每30秒钟计算一次:

 

参数1=30,参数2=“S031”,参数3=45,参数4=“S038”,参数5=60,参数6=“S064”,参数7=“S071”,参数8=120,参数9=“S062”

 

这一类公式的计算,我们随便取个名字叫“杰克逊估计值”,然后,可以在离线数据里面,创建一个标识,比如JacksonEV。应用把这个值算出来后,就通过API-Q插入到离线数据表(Collectos)。这样的话,以离线数据JacksonEV为标识的数据,每30秒就有一个。

 

接下来,就是要解决这个计算出来的“杰克逊估计值”的显示的问题了。把原来这个对象的映射表稍微修改一下,增加一个FV,比如,S100:
[“S100”, “JacksonEV”, “杰克逊估计值”,…,&Collectos("JacksonEV”), ...]

 

那么,该对象就多了一个FV。

既然这个计算值X已经变成了这个对象FV的一员了,就享有跟别的FV一样的待遇,可以在显示板上显示(卡片,仪表,曲线等等),参与统计计算,参与数据分析。

 

除了这个“杰克逊估计值”,还会经常计算另一个值,我们姑且称之为“瓦西姆估计值”,计算公式是这样的:

一样的,把这个计算也纳入应用,把计算结果以“WaximaEV”作为标识。创建项目的时候,可以选择是要计算杰克逊还是瓦西姆,如果是杰克逊,就用JacksonEV为离线标识写到Collectos,如果是瓦西姆,就用Waxima为离线标识写到Collectos。

 

总结一下,这其实就是离线数据的用法了,离线数据在MixIOT中是一个机制,应该学会灵活运用,举一反三,活学活用。

 

实例二
某企业有4台设备夜以继日生产产品,该企业要对12个工人进行绩效管理,以绩效决定工资。绩效工资的计算不仅与产品的产量和良品率有关,还与设备的故障率、开机率、设备能耗有关。假设通过MixIOT标准的统计和计算能够计算出每个小时里的这些值。

每小时的绩效考核工资计算的公式是这样的:

 

从这个公式可以看出,每小时的绩效工资,是每小时的基本工资48.5元加上产量绩效,减去不良品率绩效,加上开机率绩效,减去故障率绩效,再加上节能绩效。

 

在MixIOT中,不管是马赛克时序数据,统计数据还是离线数据,其实都有两个属性,一个是标识,一个是时间。MixIOT的机制是不允许修改的,MixIOT的统计计算是标准的,不允许对数据增加别的属性,也增加不了。

 

那么问题来了,数据并没有工人的属性,该怎么去计算工人的绩效工资呢?

 

在MixIOT中,可以用一个标准的方式来解决这类的问题。分两步走:

第一步,创建工人与这些数据属性的“关联关系索引”;

第二步,做一个应用,以这个“关联关系索引”去组织需要的数据,进行计算,并保存计算结果。

 

所谓创建工人跟这些数据属性的关联关系,一个是时间,一个是标识,说白了,就是建立一个表:

这其实就是一个排班表了,这个排班表,随时可以变。计算绩效工资,每小时计算一次,并把记录保存起来。这样,一个月,我们就把这些计算结果都加起来,就是工人这一个月的绩效工资。

 

MixIOT中,需要有这么一个排班表,通常这样的表都是在客户的诸如ERP系统、CRM系统或者是员工管理系统里面。假设,是来自工厂的工人排班管理系统,应用通过一个接口,每小时去更新一次。

我们在这个应用里面,维持了一个“关联关系索引”表。而且,这个表是与工厂的工人排班管理系统同步的,至于这个排班管理系统的数据是怎么来的,也许是工人上班打卡,也许是别的什么方式,我们不用去管。

 

 

有了这个表,下面的事情就很显然了。这是第一步。

 

第二步,我们让这个应用,打开另外一个表,记录计算结果:

 

后面怎么去加加减减的,算出工人每个月的绩效工资,就不在这里细说了。

 

下面说一个另外的一种情况。假如,排班的情况不是实现计划好的,而是根据工人实际打卡的情况而来,也就是说,某台设备从张三换到李四,并不是在整点发生,可能张三在1#机台的实际时间,是09:22-15:42。李四的站台时间是15:42-22:34,那又该如何呢?

 

其实,做法是一样的,只是稍微复杂一些:
1、这个“关联关系索引”方式的表述有所不同;
2、需要对“统计结果数据”进行“分割”。

 

先来解释上面第二点。
MixIOT的统计,是标准的,周期的。比如,计算15-16这个统计时段,在MixIOT中是无法改变的。假设1#机台算出来,在15-16这个时段的绩效工资是82.36元。但是,这一个小时,张三和李四是分别站台的:


张三,15:00-15:42;李四,15:42-16:00

 

MixIOT统计计算的时候,不会理会这个小时是谁在站台。那么,1#机台的业绩,是张三和李四共同的贡献,这没办法再精细了,只能平均分配或者根据站台时长按比例分配吧。

 

再解释第一点。
前面说的“排班表”,是一种静态的“关联关系索引”,尽管这个排班表随时可以更新,但毕竟是预先准备的,所以,我们把这组索引归置为静态索引。

 

除了静态索引,还有一种“动态索引”。

 

我们通过一个规则,在计算时段准备计算的时候,去获取该计算区间到底谁在站台。
 

那么,上面这张图是怎么被记录下来的呢?这里就需要引入一个概念,叫“Check-In”和“Check-Out”,就像住酒店的时候,办理入住就叫Check-In,走人的时候退房,就叫“Check-Out”。

 

这个Check-In和Check-Out的方式可能是打卡、App、按指纹、扫码、人脸识别等等。

 

Check-In和Check-Out,上面的图已经说得很清楚了,只需要掌握两个原则:
第一,如果一个设备机台只能有一个位置Check-In,那么,只要有Check-In,前面的一个就被自动Check-Out。无论前一个人是走了,还是没走,什么时候走的,走的时候有没有打卡。即便Check-Out过一段再打卡,也不做记录;

 

第二,某个设备机台,在Check-Out之前,如果没有Check-In发生,就视为前一个Check-In—直有效。Check-Out后,到下一个Check-In之前,这个叫空窗。如上图,如果黄二走了,张三没来,中间有一段时间是空窗。空窗期怎么处理,那就看需求按什么规则了,这里不再细说。

图片名称
图片名称