Mini-MES: A Microservices-Based Apps System for Data Interconnecting and Production Controlling in Decentralized Manufacturing

: Manufacturing factories and their resources are moving towards being networked, ﬂat, ﬂexible, and diversiﬁed in the context of social manufacturing. It is urgent to manage the increasingly complex and variable manufacturing processes e ﬀ ectively in such cross-factory production. This paper proposes a brand-new microservices-based Mini-MES (M 2 ES) Apps System, which adopts the decentralized and distributed architecture to comply with the needs of software supported manufacturing. The basic properties of the M 2 ES Apps System, such as its running logic and its data organization, are discussed, and a real-world industrial case is described to illustrate how it works. Results show that the proposed M 2 ES Apps System has better performance, reliability, and scalability than the initial information systems.


Introduction
Manufacturing Execution Systems (MES), a kind of computerized system, is widely used in manufacturing, to track and document the transformation of raw materials into finished goods. MES has become involved in production planning and control, and it significantly evolved into a more and more powerful system as computing technologies and integration levels become more advanced [1]. MES, together with other information systems, such as Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), Supply Chain Management (SCM), and Product Data Management (PDM), is widely employed by manufacturers to deal with production management and control [2].
Many manufacturers looking to implement a new MES system will, no doubt, end up considering the industry's some biggest behemoths: SAP [3], Oracle [4], and Siemens [5]. These vendors are clear market share leaders and have well-established product lines. However, all the above MES systems are developed with a centralized architecture, where various data, resources, and functions of its modules are highly coupled with each other. What's more, the data type and processing flow should be figured out and defined before starting programming due to the complexity of the data and business logic [6]. This situation could lead to the development of an oligopoly where once a manufacturer opts for one system, there is almost no opportunity to use others because of the higher replacement cost.
Nowadays, manufacturers must respond to local and global market shifts as well as to changing regulatory and customer demands more quickly than their competitors. This means manufacturers have to face the music when upgrading their MESs to adapt to new production needs. Their systems' vendors always tend to quote at an astronomical price, since only they can access their own software to customize it. Vendors like SAP have already taken the upgradation and customization issues into consideration, and some Application Program Interfaces (APIs) are released along with the standardized products. But this still brings about some difficulties in customized programming and personalized maintenance in a non-open source system.
In the meantime, several strategies for manufacturing have been developed, such as Industry 4.0 in Germany, Industrial Internet in the USA, and Made in China 2025 in China [7]. These initiatives encourage the applications of New Generation of Information Technologies (NGITs) [8] in manufacturing, such as big data, edge computing, artificial intelligence, and so on. NGITs drive manufacturing to become more and more flat and interconnected. More participants and roles are involved in the same production process than ever, which makes the interconnection of software and sharing of data more and more important. In terms of MES, its goal has become collaborative control all over the industry chain instead of accomplishing the internal planning or scheduling inside an enterprise or a workshop. Objectively, these changes have driven the evolution of data governance from centralized to distributed and decentralized.
It is believed that the MES in the future will take over the manufacturing ecosystem, which is not limited to its original definition. It will combine with the information systems of ERP, CRM, and others, to extend more customized functions. Also, a future MES must have the microservice-based feature to fit in the dispersion of data and use the lightweight and flexible architecture to adapt to the more complex functions in discrete manufacturing. In other words, embedded Apps in the future will not need to be downloaded and installed [9]. Users will only need to Open, Use, Share, and Close. As a consequence, the characteristics of next-generation MES can be summarized as follows.

Supporting the Distributed and Decentralized Manufacturing
The boundaries between different workshops, different factories, and different enterprises have been blurred in the context of Service-based Manufacturing and Cloud Manufacturing. Software interoperability and data sharing have become major trends in current manufacturing. While existing MES products have achieved great success in centralized manufacturing [10], there are some difficulties in supporting life-cycle manufacturing at the industrial ecosystem level. Lots of suppliers, outsourcers, vendors, logistics providers, and even the customers prefer to access the information system by themselves to track or control the production. So, it seems possible to realize distributed and decentralized manufacturing supported with software by considering the security and permissions issues [11]. With this architecture and edge computing technology, Apps can be deployed anywhere in the Industrial Internet of Things, further enabling an on-demand configuration.

Enabling Extensible Ongoing Development
Functional modules are relatively fixed in existing MES systems, which means they can only use the established features to help to control the production. Nevertheless, business logic in the era of intelligent manufacturing or social manufacturing will change frequently. It is important to design a specific new environment for service-oriented App to enable extensible ongoing development. In the new development environment, the addition of a new App will definitively not affect all previous ones, and the new App can request the raw or processed data from other existing Apps. When a new production scenario develops that requires the supporting of software, the only thing to do is to customize a functionally independent App for this new scenario, and the rest of the system will continue operating without any interruption. Besides this, an efficient workshop dataspace [12] will be also employed to manage the heterogeneous and heterologous data [13].

Lightweighting Application Logic
From the perspective of the entire industrial ecosystem, the future MES will not only consider the needs of deployment and application for core enterprises, but will also think about small and micro individuals. And these small and micro enterprises will not frequently invest in high-configured servers and clients. They just want to make full use of their limited hardware and software resources to develop an easy-to-use App with a simple function. In recent years, lightweight architecture has been becoming more and more popular. Some HTML5 Web-App based software architectures have begun to emerge [14], such as the WeChat Mini Programs [15]. As part of the next generation of the mobile Internet, Web-App and Mini Programs are developing rapidly toward the "micro, light, and small", and developers may develop a new App or Program quickly. In addition, these Apps and Programs may be easily accessed and easily disseminated in Platform [16].

Achieving Industry 4.0-Oriented Intercommunication
In a smart factory for Industry 4.0, smart machines will deal with the production orders, which are composed of the smart workpieces, via the Human-Machine Interface (HMI) or the social sensors [17,18]. Under these circumstances, smart devices will get the same positions and permissions as ordinary workers, and the users of MES will no longer limited be to real people, but will extend to machines, tools, and workpieces. Intercommunication in this manufacturing scenario would be more like a Multi-Agent System (MAS) [19], where the interactions between any two Agents are Peer-to-Peer, instead of using the traditional industrial Fieldbus.

Ensuring High-Level Safety and Reliability
The production logic is becoming more sophisticated in intelligent manufacturing, and the data types and data dimensions are becoming more disordered. This puts high demands on the authority and data security management in the next generation MES. It is necessary to ensure efficient and reliable running of the system, and to prevent sensitive data from being leaked and tampered with in a more open-up manufacturing ecosystem than ever.
For a better application of MES in the context of intelligent manufacturing, we propose a brand-new microservices-based Mini-MES (M 2 ES) Apps System. It can be seen as the next generation MES, which is developed for the software supporting in more complex production situations. M 2 ES Apps System is defined as a computerized system with microservices-based architecture, including a series of feature-independent Apps, to help to cope with any life-cycle production issues. M 2 ES Apps System is also a highly scalable system, and each App in it has a lightweight architecture. M 2 ES Apps can work independently and be networked via the Industrial Internet. Also, some Apps can be combined in order to solve some complicated cases. Additionally, since the manufacturing process has many similar business scenarios, the M 2 ES Apps System can meet the requirements of reusing in analogical scenes at different time, and the Apps are easy to migrate and to promote. As an information system adapts to new manufacturing paradigms and new production models, M 2 ES Apps System will enable manufacturing processes to receive more support from computer software with less effort required on development. This paper focuses on some basic properties, especially its data organization and dataspace, of M 2 ES Apps System and its applications. The rest of the paper will be arranged as follows: Section 2 reviews the related work on the Distributed Information System, Microservices-based Architecture, and Industrial Dataspace. Section 3 clarifies the running logic of the M 2 ES Apps System and describes its framework of data organization, together with some key enabling technologies. Furthermore, an industrial case is described in Section 4 to illustrate the application of the M 2 ES Apps System. Finally, discussions and conclusions are given.

Related Work
Several computer-aided methods and NGIT have been developed for manufacture controlling in some new production scenarios over the years. This section will elaborate on the related works from the following three aspects.

Distributed Information System
Manufacturing ecosystem for individualized products in the context of advanced manufacturing paradigms, especially in Cloud Manufacturing [20] and Social Manufacturing [21], is now likely to involve a number of distributed autonomous organizations. In fact, quite a bit of research [22] has Appl. Sci. 2019, 9, 3675 4 of 17 been done on logical decentralization of the information system, and MAS can be seen as a typical kind of physical decentralization inside a smart factory [23]. MAS has succeeded in superseding traditional MES functions through distributed autonomy of numerous resources [24]. The autonomous communication and negotiation in distributed manufacturing can be represented as individual behaviors among the agents. Although the centralization versus decentralization debate has been with us since early computing, there are no good or bad conclusions [25]. Some scholars also tried to use the Ontology [26] or API [27] to realize the interconnection of existing information systems in the workshop floor. In addition, an information system orienting Industry 4.0 should sustain multi-enterprise collaboration [28], which requires MES to have the function of authority controlling when running cross-enterprise or cross-workshop.

Microservices-Based Architecture
Microservices-based architecture is an architectural style that structures an App as a collection of services that are highly maintainable and testable, loosely coupled, independently deployable, organized around business capabilities [29]. As a popular distributed App development ecosystem, Microservices-based architecture enables rapid authorization and management [30]. Many famous and large Internet companies have provided authorization services, such as Google Accounts, Facebook, Alipay, WeChat, Microblogging, QQ, and other third-party interactive tools [31]. These architectures offer a lightweight infrastructure that allows developers to pay more attention to the core business workflow design and help users enjoy the process of Opening, Using, Sharing, and Closing. At the moment, microservices-based architecture is still at an early age in the field of manufacturing or production, and there are only some conceptual proposals about microservices either in the digital factory [32] or in IoT-based manufacturing [33] at present.

Industrial Dataspace
Dataspaces was first introduced as a novel abstraction for data management [34] in 2005. In the informatics field, modeling of data, integrating and relationship discovering of entities, indexing of information, etc. have been studied [35]. In the manufacturing field, industrial dataspace was regarded as a broker to run Cyber-Physical Systems (CPS) [36] by mediating between bottom data and upper Apps via mappings. And it refers to the semantic representation of multi-source and heterogeneous data [37]. As to industrial applications, Ontology-Based Data Access (OBDA) and Knowledge Graph (KG) were widely used to integrate, store, index, semantically query, and knowledge reason [38]. General Electric (GE) also proposed a semantic-driven framework SemTK, which realized storage and access of heterogeneous big data. In addition, the benefits of constructing and querying Polystore knowledge graphs with SemTK were employed in four industrial cases [39].

Running Logic and Data Organization of the M 2 ES Apps System
In order to design a lightweight and distributed architecture of M 2 ES Apps System, which is very different from the traditional MES, this section elaborates its software implementation architecture and data organization logic, as shown in Figure 1.  Each resource, whether it is a physical one like a machine or a virtual one like an order, will be registered as an entity in industrial dataspace. Then the central Resource DB, which is also called Basic DB, assigns a data table for each of them. This table will save the properties and status data of the entity. The Resource DB will be placed in the centralized computer room normally, and only data that is not relevant to the manufacturing process will be saved in.
As for the processing and implementation of the function, they are handled by each distributed M 2 ES App. Every App is developed, debugged, and deployed independently under a unified instruction, and each of them has its own separate database. The functionality of an App is relatively simple and independent strictly, and resource entities need to follow the OAuth 2.0 [41] architecture in logging in and using. What's more, M 2 ES Apps can also request and pull data from others through an Application Programming Interface (API). It should be noted that module calls in cross-App are not permitted, and only API-based data requests can be allowed.

Configuration and Running of M 2 ES Apps
Running an M 2 ES App can be divided into four major stages mainly, seen in Figure 3.
(1) System design and development. It can be subdivided into two segments. The first one is designing a description framework of resources, that is, the industrial dataspace; the other is building the software platform with permissions, authorization, API, frameworks, UI, and other specifications.
(2) M 2 ES App design, develop and deploy. The M 2 ES App is designed and developed according to the relevant functions. Each App will get an isolated DB that stores process-related data only, by using the protocol defined in stage (1).

M 2 ES Apps System Architecture
Manufacturing processes involve a variety of physical resources and operational processes, so the first step in establishing M 2 ES Apps System is defining all the related resources and processes uniquely. The concept of industrial dataspace is introduced to meet requirements imposed by M 2 ES Apps System, which refers to the semantic representation [40] of multi-source and heterogeneous data.  Each resource, whether it is a physical one like a machine or a virtual one like an order, will be registered as an entity in industrial dataspace. Then the central Resource DB, which is also called Basic DB, assigns a data table for each of them. This table will save the properties and status data of the entity. The Resource DB will be placed in the centralized computer room normally, and only data that is not relevant to the manufacturing process will be saved in.
As for the processing and implementation of the function, they are handled by each distributed M 2 ES App. Every App is developed, debugged, and deployed independently under a unified instruction, and each of them has its own separate database. The functionality of an App is relatively simple and independent strictly, and resource entities need to follow the OAuth 2.0 [41] architecture in logging in and using. What's more, M 2 ES Apps can also request and pull data from others through an Application Programming Interface (API). It should be noted that module calls in cross-App are not permitted, and only API-based data requests can be allowed.

Configuration and Running of M 2 ES Apps
Running an M 2 ES App can be divided into four major stages mainly, seen in Figure 3.
(1) System design and development. It can be subdivided into two segments. The first one is designing a description framework of resources, that is, the industrial dataspace; the other is building Each resource, whether it is a physical one like a machine or a virtual one like an order, will be registered as an entity in industrial dataspace. Then the central Resource DB, which is also called Basic DB, assigns a data table for each of them. This table will save the properties and status data of the entity. The Resource DB will be placed in the centralized computer room normally, and only data that is not relevant to the manufacturing process will be saved in.
As for the processing and implementation of the function, they are handled by each distributed M 2 ES App. Every App is developed, debugged, and deployed independently under a unified instruction, and each of them has its own separate database. The functionality of an App is relatively simple and independent strictly, and resource entities need to follow the OAuth 2.0 [41] architecture in logging in and using. What's more, M 2 ES Apps can also request and pull data from others through an Application Programming Interface (API). It should be noted that module calls in cross-App are not permitted, and only API-based data requests can be allowed.

Configuration and Running of M 2 ES Apps
Running an M 2 ES App can be divided into four major stages mainly, seen in Figure 3.
(3) Initialization. All resources are registered as entities in the industrial dataspace, and each of them gets its own data table in the basic DB. Users, represented as entities, can log in the M 2 ES App with its Uniform Resource Identifier (URI) [42].
(4) Running. Entities (users) will Open, Use, Share, and Close the Apps. The change of the attribute & status data of the entity itself is updated to the basic DB. And dynamic data generated in the course of the operation will be saved in the M 2 ES App DB. Obviously, this stage is the core of the M 2 ES Apps System, so its workflow will be elaborated on in detail.

Data Organizational Logic When Running an M 2 ES App
As mentioned above, each M 2 ES App performs only one independent function. What it needs to do is to process the input data, calculate and optimize, and format the output in accordance with certain organizational logics. Figure 4 shows how a user (entity) uses an M 2 ES App. When the user opts an M 2 ES App from the App Store, this selected will collect data as needed. The input data of the App is primarily from four aspects. The first is the attributes and the status data of resource entity from the Basic DB. The second is the private data taken out from the independent DB of this App according to the entity's URI. The third is the linked data from other Apps' independent DBs, which is pulled according to the entity's URI via API. The last is the raw running data from sensors, which represents the working conditions of equipment and devices.
The output of an M 2 ES App usually includes two aspects, i.e., the running results and newly generated data. Running results are used to guide production and decision making, and all procedures and final data will be saved reliably. Some basic attribute data will be modified in Basic DB, and procedure and result data related to the function of the App will be stored in its independent DB. (1) System design and development. It can be subdivided into two segments. The first one is designing a description framework of resources, that is, the industrial dataspace; the other is building the software platform with permissions, authorization, API, frameworks, UI, and other specifications.
(2) M 2 ES App design, develop and deploy. The M 2 ES App is designed and developed according to the relevant functions. Each App will get an isolated DB that stores process-related data only, by using the protocol defined in stage (1).
(3) Initialization. All resources are registered as entities in the industrial dataspace, and each of them gets its own data table in the basic DB. Users, represented as entities, can log in the M 2 ES App with its Uniform Resource Identifier (URI) [42].
(4) Running. Entities (users) will Open, Use, Share, and Close the Apps. The change of the attribute & status data of the entity itself is updated to the basic DB. And dynamic data generated in the course of the operation will be saved in the M 2 ES App DB. Obviously, this stage is the core of the M 2 ES Apps System, so its workflow will be elaborated on in detail.

Data Organizational Logic When Running an M 2 ES App
As mentioned above, each M 2 ES App performs only one independent function. What it needs to do is to process the input data, calculate and optimize, and format the output in accordance with certain organizational logics. Figure 4 shows how a user (entity) uses an M 2 ES App.
Appl. Sci. 2019, 9, x FOR PEER REVIEW 6 of 16 (3) Initialization. All resources are registered as entities in the industrial dataspace, and each of them gets its own data table in the basic DB. Users, represented as entities, can log in the M 2 ES App with its Uniform Resource Identifier (URI) [42].
(4) Running. Entities (users) will Open, Use, Share, and Close the Apps. The change of the attribute & status data of the entity itself is updated to the basic DB. And dynamic data generated in the course of the operation will be saved in the M 2 ES App DB. Obviously, this stage is the core of the M 2 ES Apps System, so its workflow will be elaborated on in detail.

Data Organizational Logic When Running an M 2 ES App
As mentioned above, each M 2 ES App performs only one independent function. What it needs to do is to process the input data, calculate and optimize, and format the output in accordance with certain organizational logics. Figure 4 shows how a user (entity) uses an M 2 ES App. When the user opts an M 2 ES App from the App Store, this selected will collect data as needed. The input data of the App is primarily from four aspects. The first is the attributes and the status data of resource entity from the Basic DB. The second is the private data taken out from the independent DB of this App according to the entity's URI. The third is the linked data from other Apps' independent DBs, which is pulled according to the entity's URI via API. The last is the raw running data from sensors, which represents the working conditions of equipment and devices. When the user opts an M 2 ES App from the App Store, this selected will collect data as needed. The input data of the App is primarily from four aspects. The first is the attributes and the status data of resource entity from the Basic DB. The second is the private data taken out from the independent DB of this App according to the entity's URI. The third is the linked data from other Apps' independent DBs, which is pulled according to the entity's URI via API. The last is the raw running data from sensors, which represents the working conditions of equipment and devices.
The output of an M 2 ES App usually includes two aspects, i.e., the running results and newly generated data. Running results are used to guide production and decision making, and all procedures and final data will be saved reliably. Some basic attribute data will be modified in Basic DB, and procedure and result data related to the function of the App will be stored in its independent DB.

Comparative Analysis with Traditional MES
As M 2 ES Apps can be defined as the next generation MES, it is necessary to figure out the differences between M 2 ES Apps System and the traditional MES clearly, as shown in Table 1.

Identification of Key Enabling Technologies for M 2 ES Apps System
Developing M 2 ES Apps System needs the support of some key enabling technologies. Therefore, it is quite important to identify what key enabled technologies for M 2 ES Apps System are. In general, there are five main supporting technologies to ensure the smooth operation of M 2 ES Apps System, which are as follows.

Creating Data and Knowledge Graph
As mentioned in Section 3.1.1, the Semantic Web seems to be the basis of M 2 ES Apps System. So, a schema for entity-centered resources will be created in order to describe the resources and manage  Table 1. there are five main supporting technologies to ensure the smooth operation of M 2 ES Apps System, which are as follows.

Creating Data and Knowledge Graph
As mentioned in Section 3.1.1, the Semantic Web seems to be the basis of M 2 ES Apps System. So, a schema for entity-centered resources will be created in order to describe the resources and manage them. Semantic technologies, such as especially OWL 2 ontology, are ideal models for the heterogeneous resources to enable the data exchange across different entities [43]. OWL 2 provides a rich and flexible modeling language for creating a domain ontology, which uses shared vocabularies to describe classes, properties, individuals, and data values. An ontology model of an entity can be denoted as where C denotes the ontology classes and class hierarchy. P stands for the property collection of the entity. In the meantime, it's needed to create a data Table in the Basic DB for each entity resource O in the operating level, which can save the properties and status data of the registered resource in the form of "propertyName: propertyValue".

Apply for Webpage Authorization for an M 2 ES App
Should the user visit an M 2 ES App, the App can obtain basic information on users via the authorization mechanism, thereby achieving business logic. Specifically, there are four steps in authorizing an App, which are shown in Figure 5. In the meantime, it's needed to create a data Table in the Basic DB for each entity resource O in the operating level, which can save the properties and status data of the registered resource in the form of "propertyName: propertyValue".

Apply for Webpage Authorization for an M 2 ES App
Should the user visit an M 2 ES App, the App can obtain basic information on users via the authorization mechanism, thereby achieving business logic. Specifically, there are four steps in authorizing an App, which are shown in Figure 5. The code acts as a note for exchanging access_token, with the code used for webpage authorization being different each time. Each code can be only used once and will expire automatically in 5 min.

Process Functional Decomposition and its App's Design
MES is intended to track and document the transformation of raw materials to finished goods frequently, which involves very numerous and interrelated processes. In order to ensure the independence of each App's functions, it is necessary to model the processes and decompose the functions of the whole manufacturing task. Finer granularity always goes with more Apps, which will decrease convenience. So, it is vital to decompose the functions with appropriate granularity. Figure 6 shows a kind of typical decomposition of manufacturing tasks, in which each function corresponds to an M 2 ES App. The code acts as a note for exchanging access_token, with the code used for webpage authorization being different each time. Each code can be only used once and will expire automatically in 5 min.

Process Functional Decomposition and its App's Design
MES is intended to track and document the transformation of raw materials to finished goods frequently, which involves very numerous and interrelated processes. In order to ensure the Appl. Sci. 2019, 9, 3675 9 of 17 independence of each App's functions, it is necessary to model the processes and decompose the functions of the whole manufacturing task. Finer granularity always goes with more Apps, which will decrease convenience. So, it is vital to decompose the functions with appropriate granularity. Figure 6 shows a kind of typical decomposition of manufacturing tasks, in which each function corresponds to an M 2 ES App.

Case Study
To demonstrate how to implement the M 2 ES Apps System in actual industrial scenarios, this section reports a real-world case on designing, developing, deploying, and operating an M 2 ES Apps system. The system in this case comes from an industry chain combined with several manufacturers, and it aims to achieve collaborative quality control in the level of a cross-workshop. Figure 7 shows the main production process of Component T (seen in Figure 8) in an industry chain, and there are 9 related workshops in association with this simple component. Assembly Plant plays the role of the Customer for Component Center, which is the core of the entire industry chain. Component Center has three independent departments, namely Management, QC station, and Storeroom. Besides, two suppliers A and B provide standard parts and raw materials, respectively, and three outsourcing factories A, B, and C provide manufacturing services for Component Center. These nine located in different places, so it is meaningful to design an MES to realize the information sharing and management of the whole production process.

Industrial Background
Prior to the implementation of the M 2 ES Apps System, the SAP system managed the relevant planning tasks. SAP was only accessible within the Component Center, production plans and controls relating to external suppliers and outsourcers are with paper or E-mail. At the same time, inventory management was based on an isolated self-developed program that only has basic functions of the inbound and outbound storage. And it runs in a single PC, which obviously cannot share data with SAP. Moreover, the inspection process was also based on the paper documents, and an NCR (Non-Conformity Report) system was operated independently.

Architecture Configuration
The architecture configuration can be mainly divided into Hardware layout optimization, Manufacturing resource description, and Software environment configuration.

APIs for Data Pulls between M 2 ES Apps
As mentioned above, M 2 ES Apps can request and pull data from Basic DB (Graph DB) and other Apps' DBs (Relational DB) through the unified APIs. So, establishing reasonable APIs with the complete and reliable protocol is the basis for determining the efficient operation of the M 2 ES Apps system. Since the order of development of the Apps is different, the new App must be compatible with the old ones when developing. Specific to the database and business logic design, developers of each App must obey the established naming rules when defining a DB. And the DB development document should be shared out for the later developers. Basic DB in the centralized server room stores some basic information in the form of graph database, and the data Table of each DB should be named as "appName_tableName". Noted that only the processing data can be saved in App DB.

Case Study
To demonstrate how to implement the M 2 ES Apps System in actual industrial scenarios, this section reports a real-world case on designing, developing, deploying, and operating an M 2 ES Apps system. The system in this case comes from an industry chain combined with several manufacturers, and it aims to achieve collaborative quality control in the level of a cross-workshop. Figure 7 shows the main production process of Component T (seen in Figure 8) in an industry chain, and there are 9 related workshops in association with this simple component. Assembly Plant plays the role of the Customer for Component Center, which is the core of the entire industry chain.

Industrial Background
Component Center has three independent departments, namely Management, QC station, and Storeroom. Besides, two suppliers A and B provide standard parts and raw materials, respectively, and three outsourcing factories A, B, and C provide manufacturing services for Component Center. These nine located in different places, so it is meaningful to design an MES to realize the information sharing and management of the whole production process.

Hardware Layout Optimization
Firstly, the networking of all resources is realized, in which the WIFI-based industrial Internet was built in the Component Center, and the existing Internet and Internat can be used outside. The centralized server was placed in the computer room, and two distributed servers for deploying M 2 ES Apps were added to it. Additionally, some clients were deployed where needed. The hardware layout and photos can be seen in Figure 8.

Manufacturing Resource Description
Based on the generic ontology model, a domain ontology for static resources-cantered resources was created, as presented in Figure 9. Entities need to be tagged in the M 2 ES Apps System with URI,

Hardware Layout Optimization
Firstly, the networking of all resources is realized, in which the WIFI-based industrial Internet was built in the Component Center, and the existing Internet and Internat can be used outside. The centralized server was placed in the computer room, and two distributed servers for deploying M 2 ES Apps were added to it. Additionally, some clients were deployed where needed. The hardware layout and photos can be seen in Figure 8.

Manufacturing Resource Description
Based on the generic ontology model, a domain ontology for static resources-cantered resources was created, as presented in Figure 9. Entities need to be tagged in the M 2 ES Apps System with URI, so it is also important to define the encoding rules (Bar code). Prior to the implementation of the M 2 ES Apps System, the SAP system managed the relevant planning tasks. SAP was only accessible within the Component Center, production plans and controls relating to external suppliers and outsourcers are with paper or E-mail. At the same time, inventory management was based on an isolated self-developed program that only has basic functions of the inbound and outbound storage. And it runs in a single PC, which obviously cannot share data with SAP. Moreover, the inspection process was also based on the paper documents, and an NCR (Non-Conformity Report) system was operated independently.

Architecture Configuration
The architecture configuration can be mainly divided into Hardware layout optimization, Manufacturing resource description, and Software environment configuration.

Hardware Layout Optimization
Firstly, the networking of all resources is realized, in which the WIFI-based industrial Internet was built in the Component Center, and the existing Internet and Internat can be used outside. The centralized server was placed in the computer room, and two distributed servers for deploying M 2 ES Apps were added to it. Additionally, some clients were deployed where needed. The hardware layout and photos can be seen in Figure 8.

Manufacturing Resource Description
Based on the generic ontology model, a domain ontology for static resources-cantered resources was created, as presented in Figure 9. Entities need to be tagged in the M 2 ES Apps System with URI, so it is also important to define the encoding rules (Bar code).

Software Environment Configuration
As mentioned above, there are two major kinds of servers in the M 2 ES Apps system. The one is the Centralized server for the platform, which is configured in the centralized server room. The other is the M 2 ES App servers, which is configured in Storeroom 2 and QC station. The centralized server mainly deploys services such as M 2 ES App Store, M 2 ES App Authorization, and Graph DB

Software Environment Configuration
As mentioned above, there are two major kinds of servers in the M 2 ES Apps system. The one is the Centralized server for the platform, which is configured in the centralized server room. The other is the M 2 ES App servers, which is configured in Storeroom 2 and QC station. The centralized server mainly deploys services such as M 2 ES App Store, M 2 ES App Authorization, and Graph DB Management Systems (DBMS). App servers are supposed to deploy separate Apps, and only two servers were used in this case due to the small numbers of Apps. It should be noted that the B/S architecture was selected in order to enable the clients to use the M 2 ES Apps easily.

Function Decomposition and M 2 ES App Development
According to Section 4.1, the M 2 ES Apps System mainly implements the functions shown in Figure 10 in this case, and the corresponding M 2 ES App can be designed and developed. There are 9 Apps totally in the first phase, each of them has relatively simple and strictly independent functions. And each App has its own isolated databases. Production and QC related Apps were deployed in the server in the QC station, and Inventory and Kanban related Apps were in Storeroom 2. Each App has a B/S architecture that follows a unified style on code and UI. Data can be requested among them through the API, and they can also access and modify the Graph DB located in the computer room through the DBMS.

Running of M 2 ES Apps System
What M 2 ES Apps System presents to the user is an M 2 ES App Store after configuring. Users can select Apps as needed to assist in solving production problems. Figure 11 demonstrates the user interface and data interaction of the In-stockroom App. It should be noted that this App can retrieve data from other Apps (QC App in the case) but cannot modify or save new-generated data in other Apps' DBs. Each App has a B/S architecture that follows a unified style on code and UI. Data can be requested among them through the API, and they can also access and modify the Graph DB located in the computer room through the DBMS.

Running of M 2 ES Apps System
What M 2 ES Apps System presents to the user is an M 2 ES App Store after configuring. Users can select Apps as needed to assist in solving production problems. Figure 11 demonstrates the user interface and data interaction of the In-stockroom App. It should be noted that this App can retrieve data from other Apps (QC App in the case) but cannot modify or save new-generated data in other Apps' DBs.

Running of M 2 ES Apps System
What M 2 ES Apps System presents to the user is an M 2 ES App Store after configuring. Users can select Apps as needed to assist in solving production problems. Figure 11 demonstrates the user interface and data interaction of the In-stockroom App. It should be noted that this App can retrieve data from other Apps (QC App in the case) but cannot modify or save new-generated data in other Apps' DBs.

Benefits Analysis of M 2 ES Apps System
The M 2 ES Apps system has obvious architecture benefits compared to the traditional MES in dealing with the distributed manufacturing. This section will detail the performance, reliability, and scalability of the system on the basis of the proposed case.
Performance of the M 2 ES Apps System mainly depends on System deployment time and Response time. A comparative experiment has been conducted for measuring the above metrics when

Benefits Analysis of M 2 ES Apps System
The M 2 ES Apps system has obvious architecture benefits compared to the traditional MES in dealing with the distributed manufacturing. This section will detail the performance, reliability, and scalability of the system on the basis of the proposed case.
Performance of the M 2 ES Apps System mainly depends on System deployment time and Response time. A comparative experiment has been conducted for measuring the above metrics when deploying Apps between centralized and distributed under the same network, and the results are shown in Figure 12. It can be seen that the distributed architecture is superior in both Total System Deployment Time and Total Response Time. It can also be seen that the deployment time is shorter due to the multiple servers, and the response time is shorter on account of the shorter network routes between the server and the client. deploying Apps between centralized and distributed under the same network, and the results are shown in Figure 12. It can be seen that the distributed architecture is superior in both Total System Deployment Time and Total Response Time. It can also be seen that the deployment time is shorter due to the multiple servers, and the response time is shorter on account of the shorter network routes between the server and the client. Reliability of the M 2 ES Apps system is mainly reflected in the fact that it will only affect limited Apps when a disturbance causes a node to out of service. Geographically separated and microservicebased architecture has enhanced the robustness of system greatly, and it has a greater tolerance for the crash or error reporting of a single App. Besides, the design of the independent App is good for authority management, where it can be achieved by just assigning different Apps to different users.
Scalability of the M 2 ES Apps system mainly focuses on the problem of frequent changes or adjustments in the current production. There are two types of changes normally. The first one is planned and controllable, such as the introduction of new products, the addition of new production Reliability of the M 2 ES Apps system is mainly reflected in the fact that it will only affect limited Apps when a disturbance causes a node to out of service. Geographically separated and microservice-based architecture has enhanced the robustness of system greatly, and it has a greater tolerance for the crash or error reporting of a single App. Besides, the design of the independent App is good for authority management, where it can be achieved by just assigning different Apps to different users.
Scalability of the M 2 ES Apps system mainly focuses on the problem of frequent changes or adjustments in the current production. There are two types of changes normally. The first one is planned and controllable, such as the introduction of new products, the addition of new production lines or equipment, the changes in business processes and so on. Another change is unpredictable, such as the change of delivery time or quantity, the sudden interruption of production equipment, the quality problems of materials, and so on. The advantage of implementing an M 2 ES Apps system is that no matter changes are needed, developers only need to pay attention to the new business logic and design, and develop some supplementary M 2 ES Apps, without focusing on the compatibility issues. For the users, M 2 ES Apps system can also adapt to more usage scenarios by using different arrangements and combinations of Apps.

Discussions
With the rapid changing of production, quite a few enterprises are facing the music on upgrading the existing information system in order to realize the flexible management in new production paradigm. The emergence of the M 2 ES Apps system seems to address this thorny problem. The M 2 ES Apps system has distributed and decentralized architecture, which can achieve extensible ongoing development. And its lightweight App logic enables it to have the ability to handle more complex dataspace in the level of cross-workshop. Furthermore, its microservices-based architecture also makes the M 2 ES Apps system more efficient, reliable, and scalable.
In many industrial cases, the specialized or single-featured system offers a solution that is superior to an integrated one. But the question is how to make them interconnected easily because more integrations always go together with higher costs. M 2 ES App, which is easy-to-develop, easy-to-deploy, easy-to-use, and easy-to-maintain, provides a sustainable information system architecture. Its authorization mechanism can also reduce the cost of use effectively under the premise of ensuring the security of data. In addition, decentralization of the M 2 ES Apps drives localized saving of sensitive data, which also reduces the possibility of data leaking or tampering in the case of cross-domain usage.
In fact, thanks to blockchain technology, there might be more than one centralized server in M 2 ES Apps system, without affecting the reliable synchronization of data. In other words, any companies in the industry chain can establish a self-centralized server as long as the data it owns is legal and trustworthy. The centralized servers can use the Distributed Ledger to maintain the consistent and untamed of data. In this way, the M 2 ES Apps System will have a four-tier architecture, which includes the Distributed Ledger, the authorization and resources and data server, the M 2 ES App server, and the user terminal.

Conclusions
A future-oriented MES called M 2 ES Apps System is proposed here to play the role of a manufacturing ecosystem by being combined with ERP, CRM, and other information systems. M 2 ES Apps System has a microservice-based feature and uses lightweight and flexible architecture to solve more complex logic functions in intelligent manufacturing. Users only need to Open, Use, Share, and Close its M 2 ES Apps to assist production without uploading or downloading from the software.
This paper focuses on some basic properties and applications of M 2 ES Apps System. M 2 ES Apps System is developed as the software supporting more complex production situations. It is also an information system in connection with new manufacturing paradigms and production models. Then, a real industrial case using M 2 ES Apps System is analyzed, and the result shows that it has better performance, reliability, and scalability than traditional MES.
The value of M 2 ES Apps System lies in the deep integration of intelligent manufacturing and the industrial Internet, which can promote the transformation of systems to become digitalized, networked, and intelligent. In this process, M 2 ES Apps System not only promotes enterprises to build new platforms, but also promotes the generation of new economies, new paradigms, and new ecosystems.

Conflicts of Interest:
The authors declare no conflict of interest.