技术干货丨灵活使用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之前，这个叫空窗。如上图，如果黄二走了，张三没来，中间有一段时间是空窗。空窗期怎么处理，那就看需求按什么规则了，这里不再细说。
如有疑问或想了解更多，请咨询：0755-23740592
