1、方案架构:
图1 物流行业中转场业务场景示意图
如图1所示,在物流行业一票快件的运输过程中会经过数个中转场,因此各个中转场之间通过快件产生关系。每个中转场地部署了一条或多条实体分拣,当快件经过中转场时会通过分拣线进行分拣,同时上报带有实体分拣线编码的处理信息,这个信息是业务相关的基本信息。由于分拣环节可能会因为某些原因分拣失败,比如快件挤在一起,比如分拣设备没有识别到正确的运单号等;因此会在实体分拣线上部署多种解决特定问题的设备,比如多角度拍照的相机设备,比如AI补码设备;由于多种设备来源于不同厂家,所以各个设备处理运单之后上报到云端的数据包含的设备编码是厂家自己的编码体系,这样会导致在运单无法整合不同设备对运单的处理结果,因此无法实现具体的业务价值。
当前采用的方式是通过人工维护映射关系,记录“实体分拣-相机设备-AI补码设备”,当各种设备处理运单之后上报到云端后,通过人工维护的映射关系来整合数据。
随着实体分拣线的不断增加,随着各类处理设备不断拓展,映射关系错综复杂,人工维护映射难度越来越大,数据质量和时效性都难以保证,保证不了正常业务需求。
图2 本方案核心框架示意
如图2所示,物流问题领域中本方案是以实体分拣线为主设备,目标是生成具体某一个主设备上的附属设备有哪些,即生成设备关联关系。其中附属设备可以若干种,图示只表示了A类设备和B类设备,例如A类设备是AI摄像头,B类设备是红外检测仪等,而每类设备可以在全网存在多个,例如设备1,设备2...到设备N,其中设备A和设备B在全网存在的设备数可以不相等,即没有强制要求每条实体分拣线上有一个A设备必须配备一个B设备。
因此,实体分拣线主要会处理运单的分拣任务,并上传分拣信息,A类设备主要处理运单的图片扫描任务,并上传运单图片的处理结果,B类设备主要处理场地分拣线设备运转监测信息,会上传运单位置位置信息等。于是,我们可以计算每个设备之间处理的运单的重叠数量,即设备处理的运单相似度,基于此来判断哪些设备属于同一条实体分拣线,因为一条分拣线上流经的运单更大概概率也会被该分拣线上的设备处理到,而不会别的分拣线上的设备处理到。
2、基于运单相似度的设备关系生成
图3 基于运单相似度生成设备映射关系
如图3所示,中转场实体分拣线为主设备,则附属设备可以是相机设备,AI补码设备,红外设备等,分别记为A类设备,B类设备,C类设备,当然设备类型和设备类别数量不限于三种,可以根据具体情况拓展。每类设备计算流程一样,下面拿A类设备做说明,假设A类设备有N个分别是附属设备1,附属设备2.....附属设备N,部署于不同中转场,安装在不同的实体分拣线上,实体分拣线数量是M,因此可以计算出附属设备1与M条实体分拣线上处理过的相同运单数量。若相同运单数量最大的设备1对应的实体分拣线是m,则取“设备1——分拣线m”作为当天的备选方案。
A类设备与主设备相同运单计算 |
主设备(实体分拣线) |
||||
设备1 |
设备2 |
... |
设备M |
||
附属设备(A类设备) |
设备1 |
657 |
432 |
|
981 |
设备2 |
678 |
774 |
|
359 |
|
... |
... |
... |
... |
... |
|
设备N |
364 |
568 |
|
342 |
表1 A类设备与主设备相同运单数量计算示例
其中对于A类设备,设备1,设备2...设备N与M个主设备之间处理的相同运单数量计算结果如表1所示,对于类别B和类别C的附属设备同样存在类似计算结果,如表2所示。可以发现对于类别B和类别C的设备数量分别是P和Q,不要求与A类设备数量N相同,这个是符合实际情景,例如场地安装的相机设备与红外设备的数量可以不相同。
B类设备与主设备相同运单计算 |
主设备(实体分拣线) |
||||||||||
设备1 |
设备2 |
... |
设备M |
||||||||
附属设备(B类设备) |
设备1 |
371 |
857 |
|
981 |
||||||
设备2 |
280 |
945 |
|
456 |
|||||||
... |
... |
... |
... |
... |
|||||||
设备P |
674 |
346 |
|
657 |
|||||||
C类设备与主设备相同运单计算 |
主设备(实体分拣线) |
||||||||||
设备1 |
设备2 |
... |
设备M |
||||||||
附属设备(C类设备) |
设备1 |
456 |
765 |
|
362 |
||||||
设备2 |
678 |
786 |
|
234 |
|||||||
... |
... |
... |
... |
... |
|||||||
设备Q |
256 |
345 |
|
984 |
表2 B,C类设备与主设备相同运单数量计算示例
A类设备与主设备相同运单计算 |
主设备(实体分拣线) |
||||
设备1 |
设备2 |
设备3 |
设备4 |
||
附属设备(A类设备) |
设备1 |
657 |
432 |
665 |
981 |
设备2 |
678 |
774 |
453 |
359 |
|
设备3 |
452 |
371 |
762 |
875 |
|
设备4 |
364 |
568 |
327 |
342 |
表3 少量设备举例示例
下面通过简单案例进行说明,如表3所示,这里用4台A类设备与4台实体分拣线举例。根据实际情况,认为一条实体分拣线主设备上可以安装多种设备,比如A类设备和B类设备,但每一个附属设备只可以安装在唯一一个主设备上。因此可以看到每台A类设备与每条实体分拣线处理的相同运单数量,因此可以确定附属设备1与主体设备4处理过的相同运单数量最大是981,类似的附属设备2与主体设备2处理的相同运单数最大是774,附属设备3与主体设备4处理的相同运单数最大是875,附属设备4与主体设备2处理相同运单数最大是568。
附属设备(A类设备) |
主设备(实体分拣线) |
设备1 |
设备4 |
设备2 |
设备2 |
设备3 |
设备4 |
设备4 |
设备2 |
表4 少量设备映射关系示例
从而可得到A类设备与实体分拣线的映射关系,如表4所示。计算出的映射关系表名,实体分拣线设备4上安装了A类附属设备1和A类附属设备3,实体分拣设备2上安装了A类附属设备2和A类附属设备4。满足一个主设备可以对应多个附属设备,一个附属设备只属于一个主设备。
3、时效性与准确性的平衡机制
因为基于历史数据生成的设备关系与历史数据紧密同步,这样虽然可以解决人工维护时效性差的问题,但是过于灵敏,对于个别主设备临时故障的短暂状态有可能会导致生成的设备关系有波动,因此需要根据实际问题场景确定一个时间窗口用于增强稳定性减少灵敏度的作用,实现设备某天临时故障不会影响映射关系错误变化,而当设备搬迁或永久下线的情况,也可以感知出异常的同时更新映射关系,本方案选用的窗口大小为7天。
由于个别设备故障或搬迁可能会导致映射关系改变。因此仅通过一天的数据生成的映射关系存在不准确问题,比如对于设备1临时故障,因此当天设备1上没有处理运单,因此映射关系可能变为“设备2——分拣线m”,这样仅因为临时故障造成生成的映射关系与事实不符。因此为了增加算法稳定性,本方案加入临近7天映射关系评价机制,即取最近7天的映射关系,如果“设备1——分拣线m”出现次数最多就认为当天的映射关系确实是“设备1——分拣线m”,从而不会因为设备临时故障导致设备映射关系出现错误,而当设备确实搬迁时,算法可以在第三天时感知设备关系变更,从而生成“设备2——分拣线m”。
时间 |
附属设备(A类设备) |
主设备(实体分拣线) |
当天 |
设备1 |
设备3 |
设备2 |
设备2 |
|
设备3 |
设备4 |
|
设备4 |
设备2 |
|
前一天 |
设备1 |
设备4 |
设备2 |
设备2 |
|
设备3 |
设备4 |
|
设备4 |
设备2 |
|
前两天 |
设备1 |
设备4 |
设备2 |
设备1 |
|
设备3 |
设备4 |
|
设备4 |
设备2 |
|
前三天 |
设备1 |
设备4 |
设备2 |
设备2 |
|
设备3 |
设备4 |
|
设备4 |
设备2 |
|
前四天 |
设备1 |
设备4 |
设备2 |
设备2 |
|
设备3 |
设备4 |
|
设备4 |
设备2 |
|
前五天 |
设备1 |
设备4 |
设备2 |
设备2 |
|
设备3 |
设备4 |
|
设备4 |
设备2 |
|
前六天 |
设备1 |
设备4 |
设备2 |
设备2 |
|
设备3 |
设备4 |
|
设备4 |
设备2 |
表5 少量设备时效性与准确性机制示例
如表5所示,演示了7天窗口来保证时效性和数据准确性,先来看附属设备1的映射关系,当天计算得到的映射关系是“设备1”对应“设备3”,而前面六天里“设备1”都是对应“设备4”,因此有理由相信当天的“设备1--设备3”关系不可信,很可能是主设备4临时故障导致最大相同运单数量取到了主设备3上,因此结合前6天的结果取附属设备1出现关系最多的“设备1--设备4”作为当天附属设备1的映射关系。再来看附属设备2,再前两天的计算结果出现了一次“设备2”对应“设备1”,但从七天整体来看多数是“设备2”对应“设备2”,所以有理由相信“设备2”的正确关系是“设备2--设备2”而不是“设备2--设备1”。这种机制从而实现不会因为当天设备的临时故障或者近期设备临时故障导致映射关系生成错误。同时,如果一个设备永久下线的情况会在未来7天内逐步出现新的映射关系,并且占大多数,从而实现设备映射关系的时效性,当窗口设置为7时,一般3天就可以感知到设备关系的改变,而人工维护的方式可能几个月半年难以确认关系的改变,从而无法及时更新映射关系。
4、新设备拓展方法说明
附属设备(A类设备) |
主设备(实体分拣线) |
||
设备1 |
设备4 |
||
设备2 |
设备3 |
||
设备3 |
设备1 |
||
设备4 |
设备2 |
||
附属设备(B类设备) |
主设备(实体分拣线) |
||
设备1 |
设备1 |
||
设备2 |
设备3 |
||
设备3 |
设备4 |
||
设备4 |
设备2 |
||
附属设备(C类设备) |
主设备(实体分拣线) |
||
设备1 |
设备2 |
||
设备2 |
设备1 |
||
设备3 |
设备3 |
||
设备4 |
设备4 |
||
附属设备(新增设备) |
主设备(实体分拣线) |
||
设备1 |
设备3 |
||
设备2 |
设备2 |
||
设备3 |
设备4 |
||
设备4 |
设备1 |
表6 多种设备映射关系示例
主设备(实体分拣线) |
附属设备(A类设备) |
附属设备(B类设备) |
附属设备(C类设备) |
附属设备(新增设备) |
设备1 |
设备3 |
设备1 |
设备2 |
设备4 |
设备2 |
设备4 |
设备4 |
设备1 |
设备2 |
设备3 |
设备2 |
设备2 |
设备3 |
设备1 |
设备4 |
设备1 |
设备3 |
设备4 |
设备3 |
表7 新设备拓展和映射关系融合示例
如表6所示,每类附属设备会生成一组与主设备映射关系,而业务场景一般需要整合不同种类的附属设备,当新增新种类附属设备时也可以计算得到新类别设备与主设备的映射关系,最终同样需要把新拓展设备的映射关系融合进来。如表7所示,当我们按照主设备为主键,把各类附属设备的映射关系平铺开,即可得到一条实体分拣线“设备1”上安装了“A类附属设备3”,“B类附属设备1”,“C类附属设备2”,“新增附属设备4”。
主设备(实体分拣线) |
附属设备(A类设备) |
附属设备(B类设备) |
附属设备(C类设备) |
附属设备(新增设备) |
设备1【5089】 |
设备3【4403】 |
设备1【3875】 |
设备2【3879】 |
设备4【3546】 |
设备2【6783】 |
设备4【3242】 |
设备4【4654】 |
设备1【2131】 |
设备2【3456】 |
设备3【2340】 |
设备2【1340】 |
设备2【2109】 |
设备3【389】 |
设备1【1207】 |
设备4【3772】 |
设备1【3400】 |
设备3【2894】 |
设备4【1207】 |
设备3【1789】 |
表8 新设备拓展和映射关系融合示例
由此便可以基于整合后的设备映射关系对业务数据进行整合,若A设备是相机设备,B类设备是AI补码设备,C类设备是红外设备,那么可以得到实体分拣线(设备1)上处理了5089个运单,其中相机设备处理了4403个运单,AI补码设备处理了3875个运单,红外设备处理了3879个运单,新增设备处理了3546个运单,从而实现物联网情境下的得多设备数据整合。
物流分拣线的设备映射问题基于场地运单分拣数据与设备处理运单的数据按照本方案进行计算,同理换到类似场景首先确定主设备和附属设备,然后确定设备处理对象,从而可以快速直接移植本方案到其它问题领域。