“打死MES”?谈谈MES/MOM的架构和未来

科技
2阅读

从“打死MES”到微服务

最近,有一篇文章“打死MES”。作者主张主要按人、机、料、法、安、环、测生产要素进行拆分,每个生产要素都提供一些单点应用或融入到已有的应用,借助集成平台、微服务、容器化、工作流引擎等将他们互相集成起来。

图 拆掉MES

微服务强调的一个重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用,这些小应用之间通过服务完成交互和集成。微服务在支撑“拆掉MES”上是不谋而合的。

必须承认微服务有很多好处,微服务其实是双刃剑,有利也有弊。在用来描述微服务好处的例子中,必定会谈到独立的微服务。对于MES/MOM来说,你可能无法找到合适的划分方法,能够同时很好实现服务的独立部署、以及服务之间的低耦合。

微服务的一个好处是低耦合,但是通常最难的也是低耦合。微服务在MES/MOM的实现时,当你进入泥泞的细节时,你会发现MES/MOM不同业务之间存在复杂的协同和交互,比你预期的更具挑战性。

笔者认为,企业级应用使用微服务架构必须谨慎,创建微服务看起来不错,但这可能会将你带向一个错误的道路上。笔者从事MES/MOM相关的软件规划和架构设计十余年,经历了产品多次重构,下面是笔者的一些思考。

生产环节从来就是各种信息和各种业务的汇集地,工厂几乎其他所有的业务环节都是为生产产品服务的,这一点本质上决定了核心是支撑生产的MES系统与其他业务板块存在复杂的协作。如下图,从产品生命周期维度、价值链维度、信息化层次等维度来看,制造都是信息和业务汇聚的核心。

制造是各信息和业务的汇聚点

业务之间紧密协作

生产是集大成者,是制造的核心,是实现产品价值增值的过程。计划排程、仓储物流、生产执行、质量控制、资源维护等业务环节在制造过程中各自发挥着作用,为生产提供支撑,虽然各部分有一定的独立性,但各业务之间也存在紧密的协作。

若干核心业务领域的协同

微服务的主要目标就是加强服务的内聚性,减少服务之间的耦合。服务之间依赖越强,服务隔离也就越困难,因此也就越难单独进行测试和布署。看起来你可以孤立地部署每一个服务,你会发现由于服务之间的相互依赖关系,你必须将这些服务组合部署,没有获得微服务预期的好处,实际上是变相的单体。

MES/MOM业务之间紧密协作的例子非常之多,例如:

1) 计划排程驱动生产执行,排程和调度依赖于众多的紧急插单、资源能力、物料齐套、生产进度等实时状态;

2) 生产计划提前驱动仓库物料的拣配和暂存,生产执行按需拉动物料的精准配送;

3) 供应商来料驱动来料检验,检验合格驱动收货入库;生产过程驱动了过程检验,结果驱动在制品转序和不合格品处理;

4) 设备、工具、人员、物料几乎参与到所有的环节,生产、检验、仓储、物流、维护业务,微服务化意味着重复存储、数据一致性和完整性风险;

5) ……

职能与流程的冲突

生产管理部、生产车间、采购部、品管部、设备管理部…是比较典型的工厂组织架构,按照组织职能划分部门,这种在工业化时代“职能分工制”理论基础上形成的“职能驱动型”组织,已很难适应现代管理的需要。MES/MOM的一个核心价值就是帮助建立流程驱动型组织,实现跨职能横向的高效协作。

按组织职能或生产要素划分应用更容易形成信息孤岛

按生产要素“人机料法环测”的拆分应用的方法,基本与按组织职能拆分应用的方法基本一致,这种划分方法导致数据烟囱,信息孤岛和碎片化,造成了横向沟通和协调的困难。不同厂商应用的架构技术、开发平台和工具不统一,加之系统的规范标准缺失,使各个系统间的兼容性和集成性成为问题。

边界问题的困扰

首先,单点应用厂商之间的边界也不是绝对清晰的,存在复杂的重叠和交叉。将这些零散的单点应用集成起来,因为不同单点应用的差异和不同的组合,技术难度本身就是非常高的,可以很负责地告诉您,每个客户都是不一样的,实现这样的集成都是高度个性化的,难度非常非常地高。

单点应用之间没有清晰的边界、存在重叠和交叉

因为不同供应商应用之间的边界不够清晰,要进行这样的集成,经常会触及到某些供应商的利益。这时技术的或非技术性的,人为的或非人为的问题造成的技术问题、缺少足够的接口、高昂不合理的费用、各种莫名的不配合,不仅伤及集成服务商,客户也成了冤大头。

我在工业软件领域软件开发和实施应用摸爬滚打二十年,这种故事真真切切、反复反复发生在我身边,为了避免项目的失败,有些供应商就是大爷,集成商和客户都得认栽,低声下气求开放,求被割肉,效果还难以保证。

显然,无论从技术上还是商业层面,提供这样的集成服务是复杂的、难度极高的,成本也是极高的,不但集成服务商搞不定,而且也远远超出了客户的技术能力和可控制范围。MES/MOM的内部还是挺复杂的,而且不同业务之间的协同也是非常复杂,拆掉MES谈何容易?

内部复杂性的暴露

计划排程、生产执行、质量检验、仓储管理、物流执行、设备维护等这些服务没办法单独部署和运行,许多模块之间存在双向的集成和协同,这与微服务之间尽量解耦、单向依赖是有冲突的。

MES/MOM系统如果没有拆分为微服务,那么模块间集成和测试是系统内部的事情,但是一旦拆分为多个微服务,那么这种集成就变成外部第三方的事情,或者必须要显性的事情。如果这些微服务由不同厂商提供,无疑将更多的内部复杂性暴露了出来。

要做到完全微服务模块独立,那么数据库也拆分开了,开发模式和效率上就会带来巨大的变化。数据库间还不能随便相互连接和访问,只有这样微服务模块才能做到独立部署和管理。那么跨表查询无法实现了,只能通过接口,这不但影响了性能,也增加了复杂性,数据分析也会变得更困难。

复杂的微服务依赖关系

当服务的数量增加,业务之间的协作变得频繁和紧密,服务调用关系也越来越错综复杂。如果维护一个这样的架构,你每天的宝贵时间可能都浪费在了维护服务和接口的调用关系上,浪费在不同供应商的争吵之中,系统变得越来越难以运维,为此失去了钻研更有价值的业务的精力。

微服务的运维要求比较高,如果有专家这可能不是问题。的确通过有效的自动化、监控和编排微服务,这一切都是可能的,但挑战是找到能够有效使用这些技术的人。目前这些技能需求非常高,相关技能的人可能很难找到。

另外,顶层架构分解和接口设计能力不在单个微服务模块开发商手里,客户通常需要具有较强的IT规划和架构设计能力,才可能一开始就划分好微服务模块,并且设计好微服务模块间的接口,但是通常制造业客户不是IT行业的专家。

在企业IT建设中,如果连粗粒度的业务系统以及它们之间的集成都管理不好,那么更没有能力管理细粒度的微服务模块。按本人从事MES/MOM近20年的经验,MES/MOM平台的复杂度也超出了绝大多数的集成服务商和咨询公司所能驾驭的能力。

谈起MES/MOM,就不得不提ISA-95标准、IEC/ISO62264国际标准,迄今为止,我认为这两个标准仍然是定义MES和MOM的最好标准,本人从事MES/MOM产品规划研发工作近20年,实践反复证明这一点。

ISA-95定义了MOM ( M anufacturing O perations M anagement,制造运营管理)的概念, 该标准正是在软件厂商各自为战、概念和术语不一致、集成和协同问题严重的背景下诞生的。

MOM在企业信息化层次架构中的位置

ISA-95标准、IEC/ISO62264国际标准的一个重要目标,就是要统一概念和术语,统一基础数据模型,实现生产执行(Production)、质量控制(Quality)、物流执行(Inventory)、资源维护(Maintenance)等制造业务领域之间的紧密协同。显然“拆掉MES”与这个理念背道而驰!

(1)从术语和概念角度分析

从术语和概念的维度,国际标准的第一部分(Part1:Models and terminology)定义了统一的术语和概念,基于标准实现的MES/MOM系统自然使得工厂的不同业务板块使用统一的语言进行交流。

如果拆掉MES,这种术语和概念统一性就难以保证了,不同的厂商总会创造出不同的术语来,就像中国不同地方有不同的方言,即使单点应用之间只存在少量的差异,也足以让人感到困惑。

术语和概念不一致的问题

(2)从数据模型角度分析

从数据模型角度,国际标准第二、四部分定义了对象数据模型(Part2 & Part4:Object models),设备模型、人员模型、物料模型、计划模型、产品定义、绩效模型、能力模型等,这些公共模型广泛应用于各个MES/MOM的各个业务模块。

基于标准实现的MES/MOM系统可以确保单一的数据源,确保信息的共享和相互链接关系。例如设备不仅用于设备维护,生产需要下发工艺参数到设备、驱动设备生产、监控设备运行状态,质量检验需要使用检验设备,物流过程需要使用AGV等物流设备,维护过程中也会使用维修设备进行维修。

单点应用导致的问题

拆掉MES会导致这些数据分散在许多单点应用之中,存在大量的冗余存储,很容易形成信息孤岛,数据集成无疑会增加复杂度和成本,会使得信息经常需要进行分发、同步,数据存在一定的延迟,导致数据一致性和完整性风险。

(3)从业务流程的协同角度

如下图,国际标准的第一部分(Part1:Models and terminology)定义了MOM的边界,以及每个业务板块之间的数据流和协同关系,粗虚线框以内的部分就是MOM最主要关注的部分。

国际标准关于MOM边界划分及数据流分析

国际标准的第三部分定义了MOM的“Part3:活动模型(Activity models)”,对生产、质量、物流、维护等核心业务进行了抽象,定义了:定义管理、资源管理、详细调度、分派管理、执行管理、数据采集、分析管理、溯源管理等活动。通用模型经过实例化,可适用于生产、维护、质量等业务过程,标准同时也定义了业务之间的协同关系。

下图展示了PLM、ERP、MOM、SCADA等系统集成关系,也体现了设计与生产、计划与生产、生产与质量、生产与采购、仓储与生产、生产与设备管理等跨职能部门的协同流程。

MOM平台相关的核心流程

如果我们将MES/MOM拆掉,本来MES/MOM内部复杂性就暴露给了外部。本来统一的概念和术语可能变得不统一,单一数据源的数据变得分散,存在数据一致性和完整性风险,不同单点应用之间的业务协同本来是MES/MOM的内部实现,现在也变成外部的问题。

微服务技术不适合应用于企业信息系统。微服务技术能够发展起来的确是因为他能解决一些问题,但它适合的领域是有限的。对于MES/MOM来说,应用拆分和微服务不带来显著的价值,相反其带来的弊端却很明显。

互联网很多企业推行微服务架构更多的还是考虑到巨大的业务并发量下的系统弹性扩展能力,而MES/MOM并没有如此巨大的海量数据和并发需求。通过代码优化、数据库调优和集群部署完全可以达到要求。

模块化有许多种方式,微服务化只是其中的一种方式。如果MES/MOM能够很好的模块化,清晰定义各个模块的边界,即使是单体应用也可以实现不同的部分独立开发。

按层次进行拆分

对于MES和MOM来说,更有价值的不是按组织职能或生产要素进行拆分,而是进行分层,下图是建议的分层方式。

MES/MOM更好的拆分方式是分层

1. 技术平台 可以解决架构和技术问题,屏蔽技术细节和复杂性,并提供低代码开发的相关能力,提高整个系统的扩展性和灵活性。

2. MES/MOM产品平台 解决提供覆盖制造运营全业务流程的共性模块,从而最大限度实现重用,满足共性需求,满足跨组织的协同要求,封装内部的复杂性。

3. 行业扩展 满足特定行业的扩展,例如提供各个行业层的扩展,实现对细分领域的深耕,从而更好为细分领域客户创造价值。

4. 客户扩展 是为单个客户而开发的,满足单个客户的共性需求。

其中,第1、2层应该由业界有实力的公司研发,需要很大的投入。第3、4层可以由具有领域Know How和商业资源的集成服务商、实施服务商承担,这样可以很好分工,发挥各自优势,建立合作伙伴生态。

生产相关的业务之间本来就是紧密协作的,为啥非要解耦呢?我们一定要理解微服务的微,并不是一定要将紧密相关的业务拆分。

当服务的粒度太小的时候就会遇到沙粒陷阱。微服务的微并不意味着服务越小越好。该拆的拆,不该拆的就不应该拆,与应用的大小无关!!!

MES/MOM产品对于其中有一定独立性的部分,与其他部分低耦合的部分也可以拆分成独立的应用或服务,甚至是集成第三方的应用和服务。

IT本身就是互联网企业核心竞争力,互联网企业的IT系统或运营的APP就是其核心竞争力,但是IT通常不是制造企业的核心竞争力。

业务驱动而非技术驱动,IT系统的建设和架构选型要匹配业务目标,选择当前最合适的架构方案,包括业务价值实现和IT投入产出最大化。

制造运营的业务复杂度是非常高的,选择成熟的MES/MOM产品平台,可以大幅度降低实施MES/MOM项目的风险,实现成本合适、更高质量、更快地交付。

成熟的MES/MOM产品平台主要体现在:

(1) 全制造链覆盖

能够覆盖主要的制造工艺链条,避免选择多个系统造成碎片化和孤岛。集团性企业的MOM平台应具备能力打破单个工厂空间、时间的约束,基于互联网实现全制造链上的多工厂之间的协同,甚至与供应商的协同。

MOM平台应该覆盖全制造链

(2) 跨职能部门协同

MOM平台不仅仅重视生产,对制造相关质量控制、设备管理、库存控制、物流执行,甚至是采购协同的支持和协同同等重视。MOM平台帮助建立一种跨部门的横向协作流程,而不像传统基于直线职能组织的协作,打破部门、地域的限制,可以显著提高协作效率。

实现各业务部门协同

(3) 中央治理分布应用

建立统一架构的、单数据源的MOM平台,实现全制造链多工厂、跨职能部门、跨地域的协同,消除数据孤岛,统一部署和管理,不同组织,基于互联网、移动互联网分布式应用。

另外为了确保系统的运行效率,应对大并发、海量数据,系统总体基于B/S架构,采用集群、负载均衡技术,针对不同的数据采用不同的管理方式,除了使用关系数据库,还可以使用NoSQL数据库和时序数据库。

(4) 柔性可配在线开发

产品支持采用模型驱动、动态可配置的低代码开发方式进行个性化定制开发。对系统的扩展不应该直接修改产品平台本身,而是基于产品平台提供的工具扩展实现,这样才能建立合作伙伴生态。

柔性可配置包括两个方面,一个方面是面向业务人员的,包括集成服务商、用户方业务人员。业务人员通过系统提供的工具可以快速建立和修改业务模型,从而实现业务调整快速适配,下面举例说明了部分业务建模的工具。

MOM需支持的低门槛的业务建模能力

另一个方面是面向IT工程师提供的低代码开发工具,通常包括:数据库结构建模、用户界面表单设计、菜单结构设计、报表看板设计、工作流设计、基于脚本的插件开发、组织结构建模、权限建模等方面的工具。

这些建模工具应该针对特定的用途分别设计,低门槛,易于使用,便于集成服务商或用户对系统进行持续快速、低成本地维护,满足客户的个性化需求,以及需求的快速变化。

(5) 精益为本智能管控

精益生产的理念是减少浪费,消除制造多余的、不必要的消耗。这就需要通过IT系统掌握具体的、实时的生产信息,支撑对生产过程准确分析。精益管理的水平依赖于数据管理水平,MOM平台可以为精益管理提供相关的数据,是支撑实现精益生产理念最重要的信息平台。

基于MOM平台的信息化工具是对精益的重要支撑

许多企业更多的精益改善是在单点级,现在需要提高精益改善的层次,通过避免数据孤岛,更大范围内的协同,实现从单点到车间,再进一步到工厂,甚至到供应链的优化。

MOM平台支撑更高层次的协同、精益改善

精益生产既是智能制造的基础,也是智能制造的目标,让精益生产贯穿制造整个生命周期。MOM平台是支撑精益和智能制造的重要平台,智能制造在MOM平台中的技术手段主要包括:拉动式供应链规划、有限产能排程、智能物流管控、制造过程的防呆防错、预防性质量控制、工艺参数优化、预防性设备维护、管理的自动化、自适应与自主决策,人机协同与决策等。

(6) 数据驱动与精益成长

基于MOM平台获取准确、实时的采购、生产、质量、物流、设备、安全、环境、人员等数据,让数据驱动业务和管理,进行监控、预测、控制和决策优化,实现精益成长,依靠跨业务的数据融合分析实现增值。

传统模式下缺少量化绩效体系,问题不容易暴露,失去了改善的机会。而且以不信任的方式去监管、控制,给干部或员工很不好的感觉。MOM平台变“主观的监控”为“客观的监控”,变“人的监管”为“数据的监管”,这些问题便得以解决。

精益成长是企业数据驱动的核心目标。MOM平台不能仅仅利用数据为日常的生产运作提供支持,更重要的是,利用MOM平台的数据,为不同的业务部门以及更高层的管理,对计划、生产、物流、质量以及他们之间的协作等进行持续优化,实现精益成长。

(7) 软硬一体数字孪生

MOM平台的一大趋势就是实现软件与硬件更深度的结合,在常见的硬件方面,以及特定细分领域形成软硬件一体解决方案,构建更大范围的合作伙伴生态,从而实现软硬一体化解决方案的快速实施,推进自动化、精益化和信息化融合。

MOM软硬件一体化解决方案

(8) 基于国际标准的坚实基础

选择符合ISA-95、IEC/ISO62264、GBT20720标准的MOM平台,因为这些标准可以确保所研发的MOM平台基于坚实的基础,确保MOM平台的通用性和广泛适应性,以满足企业不同业务领域、不同生产组织、不同生产工艺、不同职能部门的差异化需求。

符合国际标准对于大型企业、集团企业尤为重要,因为集团企业的业务领域更为广泛,产品特点和生产工艺更为多样化,工厂之间、部门之间的协同更为复杂,对系统的灵活性和扩展性要求也更高,基于国际标准的MOM平台可以更好满足集团企业的复杂性、多样性、灵活性和扩展性需求。

(9) 安全和自主可控

国际环境风云变换,中兴事件、华为事件,无不昭示国人,核心技术问题不解决,不管是在硬件还是软件领域,中国的制造和持续发展就会始终受制于人。知识产权自主可控对于集团性企业,尤其是国防军工企业是至关重要的,甚至是生死攸关的。

MOM平台安全自主可控的要求

一般来说,国产产品和服务容易符合自主可控要求,实行国产MOM平台替代国外MOM平台对于达到自主可控是完全必要的。在国家强力政策推动及需求快速提升的双重作用下,国产MOM平台正在快速完善,与国外MOM平台的差距越来越小。

对中小企业的建议

对于中小企业,要谨慎缺少总体规划,各自为战,头痛医头,脚痛医脚的方式,集成这些不同厂家的单点应用难度很大,企业发展以后,不少应用只能抛弃,成本和时间的代价非常高。

由于投资能力的限制,尽量可以选择成熟一体化可扩展的平台,优先选择部分重要的模块,对核心的业务进行支撑,未来再考虑增加模块,而且尽量采纳已有的成熟的模块和方案,避免过多的定制开发。

对于MOM厂商,也应该提供功能模块可选配的产品,针对不同层次的企业灵活定价。产品要支持随着中小企业的持续成长,具备持续增加模块,可快速灵活、低成本地进行配置的能力,与客户共成长。

制造运营平台MOM是制造系统的大脑,要实现多生产资源的计划排程和动态调度,确保生产资源的优化和高效利用,必须实现MOM中信息流和实物流的一致,并通过工业智能、自主控制实现对工厂的动态调度和优化,从而实现大脑的作用。应该考虑建设统一的MOM平台,兼顾局部优化和全局优化,避免信息系统碎片化,避免多脑指挥。MOM应该覆盖零部件到总装发货全制造业务链条、实现异地多工厂协同,各组织职能横向高效协同,支持人机料法环全生产要素、支持与供应商的协同等。

MOM平台应该是柔性可配置的。从业务角度,应提供包括了对产品工艺、柔性单元产线、计划排程、生产资源、仓储物流、质量控制、设备联网、分析优化等方面的建模能力。从IT角度,MOM提供一种低代码可配置的开发方式,提供包括数据结构建模、基于脚本的插件开发、在线的表单设计、在线的报表看板设计、在线的集成接口开发等工具,可以快速对已有的功能模块进行扩展,也可以开发出新的模块。

对于高度自动化的工厂,为了实现柔性自动化生产,MOM平台建议具备与产线集成、支持柔性生产建模、工业IOT物联的相关模块。FMS(柔性制造系统)的功能与MOM平台中许多模块,如计划排程、生产执行、物料配送、质量管理、设备监控等均有相关关系,利用“工业物联”模块用来连接自动化生生产、仓储和物流设施。

对于中小企业,建议选择成熟一体化可扩展的平台,优先选择部分重要的模块,对核心的业务进行支撑,未来再考虑增加模块。而且尽量采纳已有的成熟的模块和方案,避免过多的定制开发。

the end
免责声明:本文不代表本站的观点和立场,如有侵权请联系本站删除!本站仅提供信息存储空间服务。

精选推荐

随机推荐