制造執行系統本質上來說就是按照訂單狀態演變及其工藝流程的主線將人機料法環測等制造要素與業務執行過程進行關聯并進行管理的一個系統。隨著工業互聯網的發展，各種或先進或奇異的技術架構層出不窮，希望能夠改變或緩解MES高度定制性的問題，其中說的很多的是模塊化或服務化的架構模式，期望能夠通過復用，加快MES開發實施的進度。但這個事并不容易。筆者結合自己多年的經驗，做一些簡單思考，給出一些不成熟的總結或者想法吧，僅供參考。
（1）按照業務反向牛鞭效應入手，逐層向前進行分解
我們知道的牛鞭效應是從根部的微小震動向鞭梢進行擴大傳播， Mes的定制性很強，就是變化很大的末端業務，不同企業是存在比較大的差異，如果這個方面穩定了，那基本上就沒什么定制問題了。但是很可惜，這是不可能的。
如果要實現模塊化的穩定，肯定不是說作為表面的業務表現出穩定，而更多的是對業務支撐內部的子模塊作用鏈條或網絡逐步的向穩定性進行沉淀。因此，從某種程度上來，如果有誰說自己的MES功能模塊，可以完全或很大程度上復用，這個基本上可以判斷是基本脫離了具體企業的實際需求的。
（2）不管是從宏觀的整體MES還是從微觀的模塊內部及其之間的遞進與關聯，模塊組織與交互的引擎或類似總線都是必須的
很早以前提的SOA以及現在提的微服務架構，其實都可以在這個方面提供支持的。對于mes來說，沒有任何模塊是孤立存在的，一定是要與其他的模塊發生關聯的，否則這個模塊很有可能不具有存在的意義，最起碼也要為mes運行的指標分析提供支持，再說了，整個mes就是對制造執行過程的一個管理，如果不和過程發生關聯，怎么會有這種模塊呢？
不管是從宏觀還是微觀 MES，其實里面存在著兩條主線，一條主線是訂單的狀態主線，另外一條主線是訂單的工藝流程。從整體上來說我們的模塊首先要和工業環節發生聯系，并進一步的為訂單來提供支持，這是最基本的含義。
（3）最基本的模塊是面向各種制造要素的管理模塊，所謂的業務模塊就是在這些基本要素模塊基礎之上基于主線或擴展要求下構建彼此之間的關聯關系
人機料法環測，以及有些人也會說還包括安全等，每個要素本身就具有很多的內涵，每一個制造要素內容都很豐富。但是這個基本上是我們分析的基本入手出發點了，更別說這些要素之間的關聯關系，兩者之間，三者之間，四者之間，五者之間，甚至六者之間，就具有更加復雜的關聯關系。
但反過來說 mes的定制性這么強，就是因為企業的業務存在著很大的差別。如果一個供應商建立這么一種普適性的底層模塊架構，其復雜性是極其龐大的，甚至對于軟件廠商的生存或者mes的實施周期，其復雜性甚至是提升而不是降低。同時，恐怕就是這么做了，也只是針對具體細分的行業而已。因此從某種程度上來說，我并不看好這種深度的模塊化，但是這種思路可以用于分析一個mes的構成，或者說對其進行規劃，類似解析或者庖丁解牛。
（4）高內聚的模塊也必須要實現耦合，而這種耦合與中臺其實有很多內在的關系
我感覺很多企業或者說一些技術開發者，提出了數據中臺或者業務中臺的概念，其實感覺是出于這種考慮的一種變通。
首先希望通過數據的視角，以一種集中的方式來進行統一的管理，避免將數據和業務糾纏在一起，實現一種分層的控制與管理，這樣的話收縮了范圍也便于分析其中的共性。
其次提出的那種業務中臺，其實就類似一種流程引擎，以便將不同的模塊或者不同的處理過程關聯起來，形成一個特定的業務流程或網絡。
雖然現在中臺的概念被大家詬病很多，但其實任何一個系統，或多或少的都有中臺的影子，否則這個系統根本就沒法組織和運行。這個方面我們也是要給予正確認識的。
再進一步想一下，對于硬件來說，德國工業4.0將一個連續的類似固定式的生產線分解離散為各個可以通過OPCUA等方式是獨立控制的小模塊兒，通過構建與硬件相對應的各個service，通過服務或代理（agent）之間的層次化關聯，從而可以實現對生產線的柔性重構。其實對于軟件來說也是類似的，只是更加復雜而已，但其實有很多思想都可以借鑒的，也許將來的趨勢必定是這個樣子的。
模塊化的事比較復雜。我這篇文章就是拋磚引玉吧，能引起大家思考就好。文中觀點僅供參考。
作者信息：王愛民，北京理工大學數字化制造研究所所長，長期從事MES、APS等技術研究、系統開發與實施應用。
筆者公眾號：智能制造隨筆，歡迎關注。
歡迎交流討論，微信號：TimePatient