关于MES模块化的一些思考

文章来源:火凤凰软件
2021-03-21

制造执行系统本质上来说就是按照订单状态演变及其工艺流程的主线将人机料法环测等制造要素与业务执行过程进行关联并进行管理的一个系统。随着工业互联网的发展,各种或先进或奇异的技术架构层出不穷,希望能够改变或缓解MES高度定制性的问题,其中说的很多的是模块化或服务化的架构模式,期望能够通过复用,加快MES开发实施的进度。但这个事并不容易。笔者结合自己多年的经验,做一些简单思考,给出一些不成熟的总结或者想法吧,仅供参考。

     (1)按照业务反向牛鞭效应入手,逐层向前进行分解
        我们知道的牛鞭效应是从根部的微小震动向鞭梢进行扩大传播, Mes的定制性很强,就是变化很大的末端业务,不同企业是存在比较大的差异,如果这个方面稳定了,那基本上就没什么定制问题了。但是很可惜,这是不可能的。
        如果要实现模块化的稳定,肯定不是说作为表面的业务表现出稳定,而更多的是对业务支撑内部的子模块作用链条或网络逐步的向稳定性进行沉淀。因此,从某种程度上来,如果有谁说自己的MES功能模块,可以完全或很大程度上复用,这个基本上可以判断是基本脱离了具体企业的实际需求的。

      (2)不管是从宏观的整体MES还是从微观的模块内部及其之间的递进与关联,模块组织与交互的引擎或类似总线都是必须的
         很早以前提的SOA以及现在提的微服务架构,其实都可以在这个方面提供支持的。对于mes来说,没有任何模块是孤立存在的,一定是要与其他的模块发生关联的,否则这个模块很有可能不具有存在的意义,最起码也要为mes运行的指标分析提供支持,再说了,整个mes就是对制造执行过程的一个管理,如果不和过程发生关联,怎么会有这种模块呢?

       不管是从宏观还是微观 MES,其实里面存在着两条主线,一条主线是订单的状态主线,另外一条主线是订单的工艺流程。从整体上来说我们的模块首先要和工业环节发生联系,并进一步的为订单来提供支持,这是最基本的含义。
         
       (3)最基本的模块是面向各种制造要素的管理模块,所谓的业务模块就是在这些基本要素模块基础之上基于主线或扩展要求下构建彼此之间的关联关系
        人机料法环测,以及有些人也会说还包括安全等,每个要素本身就具有很多的内涵,每一个制造要素内容都很丰富。但是这个基本上是我们分析的基本入手出发点了,更别说这些要素之间的关联关系,两者之间,三者之间,四者之间,五者之间,甚至六者之间,就具有更加复杂的关联关系。
         但反过来说 mes的定制性这么强,就是因为企业的业务存在着很大的差别。如果一个供应商建立这么一种普适性的底层模块架构,其复杂性是极其庞大的,甚至对于软件厂商的生存或者mes的实施周期,其复杂性甚至是提升而不是降低。同时,恐怕就是这么做了,也只是针对具体细分的行业而已。因此从某种程度上来说,我并不看好这种深度的模块化,但是这种思路可以用于分析一个mes的构成,或者说对其进行规划,类似解析或者庖丁解牛。

      (4)高内聚的模块也必须要实现耦合,而这种耦合与中台其实有很多内在的关系
         我感觉很多企业或者说一些技术开发者,提出了数据中台或者业务中台的概念,其实感觉是出于这种考虑的一种变通。
        首先希望通过数据的视角,以一种集中的方式来进行统一的管理,避免将数据和业务纠缠在一起,实现一种分层的控制与管理,这样的话收缩了范围也便于分析其中的共性。
        其次提出的那种业务中台,其实就类似一种流程引擎,以便将不同的模块或者不同的处理过程关联起来,形成一个特定的业务流程或网络。
         虽然现在中台的概念被大家诟病很多,但其实任何一个系统,或多或少的都有中台的影子,否则这个系统根本就没法组织和运行。这个方面我们也是要给予正确认识的。

         再进一步想一下,对于硬件来说,德国工业4.0将一个连续的类似固定式的生产线分解离散为各个可以通过OPCUA等方式是独立控制的小模块儿,通过构建与硬件相对应的各个service,通过服务或代理(agent)之间的层次化关联,从而可以实现对生产线的柔性重构。其实对于软件来说也是类似的,只是更加复杂而已,但其实有很多思想都可以借鉴的,也许将来的趋势必定是这个样子的。
       模块化的事比较复杂。我这篇文章就是抛砖引玉吧,能引起大家思考就好。文中观点仅供参考。