Building a Manufacturing Service Bus (MSB) with WSO2 ESB

Prabath SiriwardenaJuly 30th, 2013Last Updated: July 29th, 2013

0 107 6 minutes read

Before getting in to the subject, I would like to introduce few terminology commonly used in the manufacturing industry.

The term Manufacturing Execution System (MES) was coined by AMR Research in 1990, the MES concept has evolved for almost three decades from the development of advanced, computer information systems for manufacturing. Following is the definition on an MES from the Manufacturing Execution System Association (MESA).

Manufacturing Execution Systems (MES) deliver information that enables the optimization of production activities from order launch to finished goods. Using current and accurate data, MES guides, initiates, responds to, and reports on plant activities as they occur. The resulting rapid response to changing conditions, coupled with a focus on reducing non value-added activities, drives effective plant operations and processes. MES improves the return on operational assets as well as on-time delivery, inventory turns, gross margin, and cash flow performance. MES provides mission-critical information about production activities across the enterprise and supply chain via bidirectional communications.

MES while in operation has to talk with multiple – heterogeneous systems. Some are listed below.

Product Lifecycle Management (PLM)
Enterprise Resource Planning (ERP)
Customer Relationship Management (CRM)
Human Resource Management (HRM)
Process Development Execution System (PDES)
Supervisory Control And Data Acquisition (SCADA)
Programmable Logic Controllers (PLC)
Distributed Control Systems (DCS)
Batch Automation Systems

Let’s have a look at how information flows between MES and other connected systems.

From MES To PLM: production test results
From PLM To MES: product definitions, bill of operations (routings), electronic work instructions, equipment settings

From MES To ERP: production performance results, produced and consumed material

From ERP to MES: production planning, order requirements

From MES To CRM: product tracking and tracing information

From CRM To MES: product complaints

From MES To HRM: personnel performance
From HRM To MES: personnel skills, personnel availability

From MES To PDES: production test and execution results
From PDES To MES: manufacturing flow definitions

I haven’t mentioned all the system there in the flow. The reason is, the systems mentioned above belong to a category called Level-4 Systems which is defined by ISA-95 standard.

ISA-95 as it is more commonly referred, is an international standard for developing an automated interface between enterprise and control systems. This standard has been developed for global manufacturers. It was developed to be applied in all industries, and in all sorts of processes, like batch processes, continuous and repetitive processes.

A common data definition, B2MML(Business-to-Manufacturing Markup Language), has been defined within the ISA-95 standard to link MES systems to these Level 4 systems.

The B2MML standard defines a format for exchange of ISA-95 information and defines the specific method (XML documents) for exchanges. B2MML is what makes the ISA-95 standards implementable. The schemas are freely available at www.mesa.org.

So, all the Level-4 Systems and the MES should understand B2MML.

The other systems like SCADA, PLC, DCS and Batch Automation Systems belong to ISA-95 Level 2 systems.

From MES To PLC: work instructions, recipes, set points
From PLC To MES: process values, alarms, adjusted set points, production results

Most MES systems include connectivity as part of their product offering. Direct communication of plant floor equipment data is established by connecting to the Programmable logic controllers (PLC). Often, plant floor data is first collected and diagnosed for real-time control in a Distributed control system (DCS) or Supervisory Control and Data Acquisition (SCADA) system. In this case, the MES systems connect to these Level 2 system for exchanging plant floor data.

The industry standard for plant floor connectivity is OLE for process control (OPC).

Manufacturing Execution Systems (MES) deliver the information required for factory personnel to effectively manage the manufacturing process from order launch to the production of finished goods.
The MES layer, which is responsible for managing the factory, sits below the ERP, which manages the business.

There are many common information requirements shared by the ERP and MES. An example is raw material inventory data. The ERP needs to know current raw material levels for inventory valuation purposes and for advanced planning. The MES needs to know current raw material inventory levels so that it can dispatch the correct raw materials to the correct work center at the right time. The difference has to do with the granularity of the information that is required. For the ERP, knowing the total on-hand inventory for each raw material is sufficient – it can use this data to calculate the current value of the inventory, and to plan future allocations of material to production. However, for the MES, this degree of detail is insufficient.

In order to optimize inventory usage, the MES needs to know each individual sub-lot of inventory, its quantity, its location, and its current status.   There are significant business benefits to well-implemented ERP-MES integration: lean business processes that flow seamlessly across the ERP-MES boundary; data synchronization, so that the plant is always making product according to current specifications and the ERP can always plan based on current and accurate information from the shop floor.

Let’s summarize everything we discussed above in a diagram.

We already discussed about how to use B2MML to connect Layer-4 systems with MES. Now, let’s focus on OPC and see how to use that to connect MES with Layer-2 systems.

OLE for Process Control (OPC), which stands for Object Linking and Embedding (OLE) for Process Control, is the original name for a standards specification developed in 1996 by an industrial automation industry task force.
The standard specifies the communication of real-time plant data between control devices from different manufacturers.

Later OPC Foundation has officially renamed the acronym to mean “Open Platform Communications”.

The change in name reflects the applications of OPC technology for applications in Process Control, discrete manufacturing, building automation, and many others. OPC has also grown beyond its original OLE (Object Linking and Embedding) implementation to include other data transportation technologies including XML, Microsoft’s .NET Framework, and even the OPC Foundation’s binary-encoded TCP format.

An OPC Server for one hardware device provides the same methods for an OPC Client to access its data as any and every other OPC Server for that same and any other hardware device. The aim was to reduce the amount of duplicated effort required from hardware manufacturers and their software partners, and from the SCADA and other HMI producers in order to interface the two.

Once a hardware manufacturer had developed their OPC Server for the new hardware device their work was done to allow any ‘top end’ to access their device, and once the SCADA producer had developed their OPC Client their work was done to allow access to any hardware, existing or yet to be created, with an OPC compliant server.

OPC servers provide a method for many different software packages (so long as it is an OPC Client) to access data from a process control device, such as a PLC or DCS. Traditionally, any time a package needed access to data from a device, a custom interface, or driver, had to be written. The purpose of OPC is to define a common interface that is written once and then reused by any business, SCADA, HMI, or custom software packages.

In January’2004 the OPC Foundation tasked a working group to create a new architecture that would take OPC to the forefront of technology and provide an interoperability framework that would be viable for the next 10 years and beyond. The result of that was the OPC-UA.

OPC UA supports two protocols. This is visible to application programmers only via changes to the URL. The binary protocol is opc.tcp://Server and http://Server is for Web Service. Otherwise OPC UA works completely transparent to the API.

The binary protocol offers the best performance/least overhead, takes minimum resources (no XML Parser, SOAP and HTTP required, which is important for embedded devices), offers best interoperability (binary is explicitly specified and allows fewer degrees of freedom during implementation) and uses a single arbitrarily choosable TCP port for communication easing tunneling or easy enablement through a firewall.

The Web Service (SOAP) protocol is best supported from available tools, e.g., from JAVA or .Net environments, and is firewall-friendly, using standard http/https ports.

The WSDL for SOAP binding can found here.

All we discussed so far is the background. What is the use of an Manufacturing Service Bus (MSB) in a manufacturing flow/process? Let’s focus on that now.

Here the ESB/MSB act as connecting layers for the MES between Layer-2 and Layer-4 systems. If we take a typical manufacturing flow, MSB will carry out the instructions provided to it by the MES. MES will have the information about the required recipes, the routes or the execution order of PLCs and the material information.

After each PLC invocation from the MSB, the response data it receives will be passed back to the MES. These stored data can be consumed by the Layer-4 ERP, CRM systems.

By now, the following information flow between MES and the ERP (which we mentioned at the beginning) will be more meaningful.