EWM与IoT设备集成方案(自动仓、输送设备、AGV等)

2024-01-05 15:30

本文主要是介绍EWM与IoT设备集成方案(自动仓、输送设备、AGV等),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

前言

本专栏主要是整体介绍下EWM作为一个专业的仓库管理系统与IoT设备的集成方式,包括AS/RS、AGV、堆垛机、Shuttle、MiniLoad、码垛机器人等等。分别从技术角度和业务角度阐述每一种集成方式的特点。

本文章是开篇的第一章,只是从宏观上说明整体对接模式,后续会针对每一种方式介绍系统的实现方式,相对来说更加偏重于技术实现。

欢迎与各位专业人士一起沟通交流


目录

前言

整体方案介绍

方案1:直接使用EWM MFS对接IoT设备(White Box)

方案2:EWM对接第三方WCS,由第三方WCS对接PLC(Semi White Box)

 方案3:EWM对接第三方WMS,由第三方WMS对接WCS(Black Box)

 总结


结合EWM自身提供的标准功能和大量自动仓集成的经验,总结大概有以下几种:

(1)方案1:直接使用EWM MFS对接IoT设备(White Box)

(2)方案2:EWM对接第三方WCS,由第三方WCS对接PLC

         从技术对接方案来看可细分以下两种方案:

         a)使用EWM-WCU interface对接WCS

         b)自开发接口对接

        从业务功能覆盖范围来看,可以细分成以下三方方案:

         a)半自动仓

         b)全自动仓

         c)全自动仓-Black Box

(3)方案3:EWM对接第三方WMS,由第三方WMS对接WCS(Black Box)


整体方案介绍

方案1:直接使用EWM MFS对接IoT设备(White Box)

 MFS是EWM内部的功能,主要用于实现直接与PLC的对接,不再需要额外的WCS系统,EWM将任务按照实际的路径拆分成每段可执行的任务,通过接口下发至PLC,设备执行完成之后,再将结果反馈至EWM系统,当然实际执行过程中可能更加复杂,在后续章节介绍MFS系统实现的时候再详细介绍。下面主要说下使用MFS所具备的核心功能:

(1)对接自动仓过程的中的一些扫描设备,获取扫描到的条码;

(2)提前校验一些异常的HU(如体积或者重量超出自动仓能力的),控制其不进自动仓;

(3)EWM结合LOSC,可根据实际的路径对主任务进行拆分成多条可执行的段任务(主要是根据设备的通讯点来进行拆分);

(4)设备发生故障之后,可以将故障信息发送至EWM;

(5)EWM会对通信点位或者输送段进行能力的管理;

(6)可以设置交叉执行(比如堆垛机的出库任务和入库任务),减少设备的空载,以便提高设备的利用率;

(7)EWM和PLC采用TCP/IP的通信方式,握手机制,使得接口稳定可靠。

针对用户的操作层面,具备以下管理功能:

(1)监控和跟踪整个自动仓的运行情况;

(2)评估和检测消息报文的想要时间;

(3)跟踪每个HU当前所处的位置以及对应的任务号;

(4)主动停止或者重启设备对应的额通信点;

(5)锁定通信点、输送段或者资源;

(6)可针对异常报文重新发送;

(7)针对异常可人工进行任务确认等等。

目前MFS与PLC的对接方式主要有以下两种种方式

(1)直连方式,使用ABAP PUSH Channel(APC)直接与PLC进行对接

(2)中间件方式,可以使用SAP Plant Connectivity(Pco)作为中间件,连接EWM和PLC

后续章节会详细介绍使用APC方式连接的详细步骤,目前这种方式也是SAP推荐的的一种方式。直连的方式是可以直接在EWM中查看或者监控报文信息,中间件的方式的话,还是需要去Pco中进行监控。

MFS的集成方案目前在国内应该很少,我知道的是没有,如果有人做过或者知道有客户实施的话,可以一起交流下。查了一下SAP的资料,国外倒是有不少案例的,特别是德国本土的企业相对较多。国内比较少用的原因可能主要有以下几个方面:

(1)第一点就是咨询公司或者实施顾问更愿意使用比较有保障或者风险较低(自己有把握)的方案;

(2)第二点就是实施方法论,国内自动仓的一般设计过程是先立项,然后进行招标,其中的技术文档都是由甲方进行撰写的,其本身对EWM与IoT设备集成的方案也不是非常了解,供应商在讲解方案的时候也都是按照自身所有的架构给甲方介绍,好的供应商或者集成商一般都是有独立的WMS和WCS,也有的WMS和WCS是集成在一起的,这样前期的设计方案基本上都已经定型了(基本上就是下面要介绍的方案2或者方案3),等到EWM实施商再进厂的时候,很难再去改变整体架构。所以我觉得如果要实施MFS,则EWM的实施商前期就要参与到项目当中,或者说直接对接集成商PLC的方案在前期招标的过程中就要明确。

(3)第三点就是使用MFS,对咨询公司或者顾问个人来说,也是比较有挑战的,需要具备一定的知识,如TCP/IP的通信技术、设备执行层的执行原理和过程(如PLC、通信点,输送段,输送设备等),但是大多数顾问来说一般都比较注重仓库管理层面,没有或者说不太容易深入到执行层,特别是有IoT的执行。

(4)第四点是MFS的应用场景,MFS可以用在单体IoT相对简单的仓库,比如单个AGV仓库,单个AS/RS仓库,针对设备集成比较复杂的仓库,特别是一些零售企业或者流通企业,同时有多种IoT设备(如输送设备、堆垛机、Shuttle、MiniLoad、箱式分拣机,皮带分拣机、语音拣选等),这要求任务的调度就相对非常复杂,使用MFS的会会面临大量的增强和开发,所以采用更加专业的WCS来说更加合理。

方案2:EWM对接第三方WCS,由第三方WCS对接PLC(Semi White Box)

这种方案在国内还是比较普遍的,EWM负责库存管理和主要的出入库策略,但是不太关注货物实际执行的路径,路径的拆分和任务的调度由集成商的WCS负责,EWM主要将创建的出库任务、入库任务、HU信息、移仓任务、盘点任务等发送给WCS,由WCS按照任务的优先级,实际的通信点和输送段进行拆分任务,并将任务下发给PLC执行,大多数情况下PLC和WCS都是同一家供应商或者集成商。

技术此种方案的技术对接可细分两种方式(本章先简单介绍下对接的总体逻辑,后续章节将对此方案的实现进行详细的讲解)

(1)使用EWM-WCU interface对接WCS

WCU主要是采用Idoc的数据传输方式,其主要传输的对象是仓库任务,系统提供的标准接口如下:

a)仓库任务传输(至第三方系统);

b)接收仓库任务(自第三方系统);

c)任务确认接口(自第三方系统);

d)任务取消(自第三方系统);

e)波次传输接口(至第三方系统);

f)仓位冻结(自第三方系统);

g)库存移动(主要指的是HU的移动)(自第三方系统);

h)Pick HU创建和下发(自第三方,至第三方)。

(2)自开发接口对接

实际的项目中,有更多的案例实际上采用的是全自开发接口的方式,通信协议主要采用WebService和RestFul居多。如下所示是相对比较经典的接口:

a)任务传输接口(EWM->WCS);

b)任务执行结果接口(WCS->EWM);

c)任务取消和变更接口(EWM->WCS);

d)设备状态接口(WCS->EWM); 

当然实际不同项目或者不同行业会有更复杂的场景,需要有更多的接口来满足业务,比如如果有自动装车设备,则需要有装车的接口,如果需要符合HU去向是否正确,则需要有复核的接口等等。

在方案对接上还可以细分三种业务对接模式(从业务层面来看)

(1)半自动仓

所谓半自动仓,指的是仓库内的设备不是全自动的,比如叉车仓库,这种对接相对比较简单,可以选择将任务传输到WCS,也可不传输,WCS执行完成之后直接反馈执行结果就好了(可以使用纸质的单据或者无纸化),比较典型的就是外接第三方的RF系统。如下所示,是入库的一种模式。

 (2)全自动仓

所谓全自动仓库,指的是仓库内的设备都为自动话设备,如AS/RS、AGV仓库等,这种仓库的内部结构相对复杂,EWM与WCS集成度更高,以便自动完成仓库内部作业,一般会结合ID&Pick Point一起使用。EWM需要考虑设备的情况和仓库的布局,以便能够创建更加合理的仓库任务。

如下所示,是入库的一种模式,EWM将对应的HU建议到中间仓位(即ID Point),然后等到了中间仓位之后,WCS再来询问EWM最终的目的仓位,或者由WCS自身基于当前设备的运作情况,建议更加合理的仓位,然后将HU输送到建议的仓位上之后,向EWM返回消息。

  (3)全自动仓-Black Box

所谓的黑盒,是说EWM只管理的存储类型级别(存储类型下面只有一个仓位),具体的仓位库存在第三方的WMS系统中管理,特别是要说明的是,这时候对接的是第三方的WMS系统(因为要管理仓位库存和库存出入库策略),而不是直接对接WCS。

一般情况下,如果甲方没有EWM的实施资源,会采取这种措施,将更多的仓库内部管理功能都在第三方的WMS中实现。

典型的收货示意图如下所示:

 方案3:EWM对接第三方WMS,由第三方WMS对接WCS(Black Box)

在方案2中实际上已经提到了使用WCU的方式对接WMS作为一种黑盒模式,所谓的黑盒模式就是EWM只管理一个总库存,仓位库存和库存策略以及任务的调度都由第三方系统来处理。

WCU的对接方式还是依托于任务来进行对接的,除此之外还有一种对接方式,就是在单据层面直接进行对接,所有的执行层面都在第三方WMS系统中处理,比如包装,码盘,第三方系统完成上架之后,将最终结果信息返回至EWM即可,这种我称之为“纯黑”,一黑到底。系统架构如下所示:

 典型的入库模式如下所示:

 总结

以上总结了EWM作为一个专业级的仓库管理系统与IoT设备集成的方式,不管是从技术层面还是业务层面做了相对比较全面的分析。每一种方式都具有自身的优劣势,不能说哪一种方式就是最优的,或者最劣的,这往往跟甲方的策略或者说未来IT的基础架构战略有关,比如是否由有足够的EWM运维资源,未来是否会持续投入,同时也要要实际考虑项目实施的周期和成本,仓库的大小以及复杂程度等等。总的来说要结合自身的情况选择适合自己的一款就可以了。

本章节主要是介绍总体的架构和集成方式,后续的章节会陆续详细介绍每种对接方案系统的详细实施步骤。

这篇关于EWM与IoT设备集成方案(自动仓、输送设备、AGV等)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/573323

相关文章

MyBatis Plus实现时间字段自动填充的完整方案

《MyBatisPlus实现时间字段自动填充的完整方案》在日常开发中,我们经常需要记录数据的创建时间和更新时间,传统的做法是在每次插入或更新操作时手动设置这些时间字段,这种方式不仅繁琐,还容易遗漏,... 目录前言解决目标技术栈实现步骤1. 实体类注解配置2. 创建元数据处理器3. 服务层代码优化填充机制详

防止Linux rm命令误操作的多场景防护方案与实践

《防止Linuxrm命令误操作的多场景防护方案与实践》在Linux系统中,rm命令是删除文件和目录的高效工具,但一旦误操作,如执行rm-rf/或rm-rf/*,极易导致系统数据灾难,本文针对不同场景... 目录引言理解 rm 命令及误操作风险rm 命令基础常见误操作案例防护方案使用 rm编程 别名及安全删除

Python实现批量CSV转Excel的高性能处理方案

《Python实现批量CSV转Excel的高性能处理方案》在日常办公中,我们经常需要将CSV格式的数据转换为Excel文件,本文将介绍一个基于Python的高性能解决方案,感兴趣的小伙伴可以跟随小编一... 目录一、场景需求二、技术方案三、核心代码四、批量处理方案五、性能优化六、使用示例完整代码七、小结一、

C#使用Spire.Doc for .NET实现HTML转Word的高效方案

《C#使用Spire.Docfor.NET实现HTML转Word的高效方案》在Web开发中,HTML内容的生成与处理是高频需求,然而,当用户需要将HTML页面或动态生成的HTML字符串转换为Wor... 目录引言一、html转Word的典型场景与挑战二、用 Spire.Doc 实现 HTML 转 Word1

使用Python实现Word文档的自动化对比方案

《使用Python实现Word文档的自动化对比方案》我们经常需要比较两个Word文档的版本差异,无论是合同修订、论文修改还是代码文档更新,人工比对不仅效率低下,还容易遗漏关键改动,下面通过一个实际案例... 目录引言一、使用python-docx库解析文档结构二、使用difflib进行差异比对三、高级对比方

深入浅出Spring中的@Autowired自动注入的工作原理及实践应用

《深入浅出Spring中的@Autowired自动注入的工作原理及实践应用》在Spring框架的学习旅程中,@Autowired无疑是一个高频出现却又让初学者头疼的注解,它看似简单,却蕴含着Sprin... 目录深入浅出Spring中的@Autowired:自动注入的奥秘什么是依赖注入?@Autowired

SpringBoot集成XXL-JOB实现任务管理全流程

《SpringBoot集成XXL-JOB实现任务管理全流程》XXL-JOB是一款轻量级分布式任务调度平台,功能丰富、界面简洁、易于扩展,本文介绍如何通过SpringBoot项目,使用RestTempl... 目录一、前言二、项目结构简述三、Maven 依赖四、Controller 代码详解五、Service

基于Redis自动过期的流处理暂停机制

《基于Redis自动过期的流处理暂停机制》基于Redis自动过期的流处理暂停机制是一种高效、可靠且易于实现的解决方案,防止延时过大的数据影响实时处理自动恢复处理,以避免积压的数据影响实时性,下面就来详... 目录核心思路代码实现1. 初始化Redis连接和键前缀2. 接收数据时检查暂停状态3. 检测到延时过

springboot2.1.3 hystrix集成及hystrix-dashboard监控详解

《springboot2.1.3hystrix集成及hystrix-dashboard监控详解》Hystrix是Netflix开源的微服务容错工具,通过线程池隔离和熔断机制防止服务崩溃,支持降级、监... 目录Hystrix是Netflix开源技术www.chinasem.cn栈中的又一员猛将Hystrix熔

Python多线程应用中的卡死问题优化方案指南

《Python多线程应用中的卡死问题优化方案指南》在利用Python语言开发某查询软件时,遇到了点击搜索按钮后软件卡死的问题,本文将简单分析一下出现的原因以及对应的优化方案,希望对大家有所帮助... 目录问题描述优化方案1. 网络请求优化2. 多线程架构优化3. 全局异常处理4. 配置管理优化优化效果1.