introduce
For years, manufacturing IT consultants using Manufacturing Operations Management (MOM)-based applications have tried to convince manufacturers of the high value of these types of applications. Real-time MOM solutions are the only set of IT applications capable of precisely optimizing a plant's day-to-day operations, bringing deliverable value to its availability processes, yet manufacturers have been slow to recognize the difference between the actionable metrics resulting from implementing any given part of MOM and the periodic key performance indicators (KPIs) used for visibility and interfaces.
Decision makers are often very reluctant to start any type of MOM implementation in their plant or enterprise due to the large scale, high risk and high cost of these projects. Historically, many MOM projects have had major issues ending on time or on budget due to poor customer understanding of the software. This is usually due to someone on the project, whether it's a salesperson, a programmer, or even the customer, trying to make the solution 100% satisfy the customer's needs in the solution's first MOM project. All parties do not agree on an achievable MOM project and feature roadmap. As a result, project participants often lose sight of the real and achievable goals of the project.
The I3 concept described in this article is based on well-known standards, including ISA-95 and B2MML, and adds some further capabilities for integration between enterprise resource planning (ERP) systems and process control systems.
This article describes the I3 approach and provides an example of how the standard can be applied in "real life".
MOM projects are subject to conflicting priorities between operating units and corporate groups, so it is always difficult to maintain project focus when goals are far apart in the time function. When the project team does not focus on near-term goals, the original goals are almost never achieved.
In the MOM space, companies face the "eternal software dilemma", apply simple solutions using commercial off-the-shelf (COTS) software tools that only need to be configured (no programming) to perform project functions and tasks; save a lot of development time and money (but increase interface and reporting costs), and end up with a solution that only meets 80% of your needs, or apply programming tools and modify the solution to exactly meet your needs, although doing so requires a lot of programming, long time and good architectural skills.
In the i3 methodology, there are elements of both - some standard software and some programming.
Rather than forcing companies to implement a so-called comprehensive MOM solution, it's best practice to start small to address cultural adoption and alignment and then expand functionality into the roadmap. A project approach called "Intelligent Integration Interface" (I3) is detailed in this chapter.
MOM project and feature roadmaps are critical to the success of long-term (eg, year X) business goals and/or a defined and specified strategy that incorporates project stakeholder requirements. With such a roadmap in place, project members can use these goals and strategies as guiding milestones in the project and revisit them at any time to confirm that they are on track.
But to achieve guided milestones on time and within budget, short-term goals should always be clearly defined and communicated effectively so they are easy to see and achieve.
In the I3 project, the core functionality of any MOM solution is addressed in the integration between IT systems to simplify implementation to suit the client's business needs. Based on an established integration baseline, the functionality can be extended later when customers and their organizations are ready and need to expand. These are best practices for the surest and safest way for customers to succeed with a comprehensive MOM solution.
Many of the same issues described in this article are faced in every project, whether the solution provider is a software vendor or a software-independent consulting firm.
Solutions in the MOM space vary widely in size and complexity from manufacturer to manufacturer and even factory to factory.
This paper, part of the MESA/ISA-95 Practice, describes the practice of developing a Manufacturing Operations Management System based on the ISA-95 MOM standard.
Persuade and educate with MOM-based solutions
The ISA-95 standard describes the relevant domain measurement hierarchy in detail. However, this oversimplified figure is often used in MOM-related articles and sales presentations. So, in the mind of a production manager who has seen many of these presentations, this is how the MOM system or architecture looks and works. In the production manager's mind, the MOM solution is just a "white box" installed between the ERP layer and the process control layer.
In many companies, experienced MOM consultants have spent years trying to convince plant and production managers that a MOM solution is the only solution to optimize their day-to-day operations and add business value. MOM systems are advertised as containing the only effective feature set to control workflow variation and minimize waste. Through event- and alert-driven responses, MOM systems use actionable metrics to minimize the impact of abnormal conditions or suboptimal operating states.
After analyzing the types of functionality already in their factories, manufacturers found that most of the MOM functionality (as defined by ISA-95) was already there, possibly without the plant manager or production manager even being aware of it. However, there is no proper integration between the different systems and no common, consistent definition across the plant. That functionality is often distributed across many different systems, including paper-based, word processing, spreadsheet, and database applications—some are commercial products, others are created by employees. If plant personnel are asked about software applications for quality assurance, maintenance, traceability, etc., they will usually say that the company uses Excel, databases, or COTS software packages designed for this purpose to handle MOM functions and tasks.
In practice, operators are unaware of the differences between their ERP systems and process control systems (levels 4 and 2 in the ISA-95 model) and other surrounding systems, as well as internally between ISA-95 level 3 systems. The size of the huge integration gap between. Companies can gain enormous value from bridging these gaps, as they will benefit from automated interfaces that exchange the required data within the required response time, thereby minimizing the impact of unexpected events. Automated data collection and interfaces eliminate paper forms and manual data entry (and attendant transcription, typing, and translation errors) in production areas to provide reliable, real-time information on which to base decisions.
From a software provider's perspective, one way to bridge the integration gap is to sell companies a new MOM solution that will replace or replace all these disparate "MIM silos of disparate data." However, best practice recommends starting small by first consolidating a set of high-value systems into a Phase 1 MOM solution. The Phase 1 MOM solution is developed according to the agreed MOM roadmap with small projects with a defensible return on investment (ROI), thereby building greater understanding and acceptance of the MOM solution within the company.
With this approach, the recommendation to start with the core MOM functionality should be based on establishing an Integrated baseline. So they can exchange data in an intelligent and efficient manner. The I3 approach goes a step further than just integrating or connecting systems; it also adds some intelligence to the solution to execute and respond effectively in plant operations.
This is where I3 as an integrated concept comes into play.
What is I3?
The I3 concept is based on placing software functional blocks between the planning and control levels, forming a MOM solution (layer 3 in ISA-95). I3 covers some parts of Manufacturing Operations (Layer 3 in ISA-95) and some of the production operations management activity models defined in ISA-95 Part 3. This is described further later in this article.
The solution consists of the following three layers:
- Layer 1 - Interface
This layer handles communication with different types of software systems and hardware components in the control layer. This interface layer also handles communication with other surrounding systems if desired and desired.
- Layer 2 - Queues
Layer 2 receives, queues, and processes rapidly incoming data from the interface layer. It stores data until the business logic layer is ready to process them and saves the sequence of messages to the next layer.
- Layer 3 - Business Logic
The business logic layer takes messages from the queue and mainly handles communication with enterprise systems such as ERP, product lifecycle management (PLM), supply chain management (SCM) or customer relationship management (CRM). But in addition to basic communication with these systems, this layer also provides "smart" error and/or exception handling if something goes wrong in the communication. This layer can also provide visualizations and various dashboards for monitoring manufacturing operations if required. This layer is the most "smart" layer in the solution and can also be described as the exception handling layer.
These three layers are described in further detail in the following sections.
Interface (Layer 1)
The main function of layer 1 in this model is to communicate with the control hardware in the process layer. and other peripheral systems:
- Programmable Logic Controller (PLC)
- Operation panel (OP panel)
- Other I/O (barcode reader, barcode printer, scale, etc.)
Other peripheral software systems that may receive information:
- Supervisory Control and Data Acquisition (SCADA)
- LIMS/QA Laboratory Information Management/Quality Assurance)
- Distributed Control System (DCS)
- Computerized Maintenance Management Software (CMMS)
- Other systems that incorporate the functionality defined in ISA-95 Part 3
Starting from the bottom of Figure 7-1, layer 1, the interface, receives process data or event records from the control layer hardware and software through the "I/O communication" block. When communicating with process control hardware such as PLC in the production workshop, the OPC server can greatly reduce the difficulty of communicating with the process control hardware in the production workshop. Often, there is a need for MOM communication with simpler hardware or other software systems; therefore, the I/O communication block handles serial and file-based interfaces, for example.
The "Determine Transaction/Command" block takes an incoming message, extracts the desired command/transaction type, and determines where in the process line the message came from.
Commands in the "Append Id to Command" block virtually have a unique ID appended to them before passing them to the queue (layer 2) via the "Provide Command" block. The ID identifies which device or software system sent the command. This information is stored locally in the "provide command" block for later use.
The "provide command" block simply accepts the command and puts it into the layer queue. Since the queue is based on a table in the database, the "provide commands" block inserts commands using ordinary Structured Query Language (SQL).
Tier 1 looks at the Tier 2 queues to see if there are any results or messages ready to be processed. This is done in the "Get Next Message" block on the right side of the diagram.
Figure 7-1: Layer 1, interface
The above unique ID is used in the "Result Id" block to direct the result or message back to the correct device through the "I/O Communication" block. After the message is sent, the flag is set back in the "Get Next Message" block, indicating that the I/O communication block is ready to process the next message.
Of course, other functions, such as visualization, alarm handling and data acquisition, can also be added to this layer.
Tier 1 is usually based on standard software such as SCADA/HMI packages from Wonderware, Rockwell, Siemens, GEIP, etc.
Queue (Tier 2)
A queuing layer was added to the solution to separate the "real time" world of PLC and SCADA systems from the slower world of business logic transactions (a very important feature) without losing the order of incoming messages (first come ) from layer 1. In most MOM solutions, the order of maintenance events is particularly important. Therefore, the queue layer is implemented as a first-in-first-out (FIFO) queue.
As a bonus, the queuing layer buffers messages/events in case the connection to the ERP system or process control level is lost.
The queue layer is actually divided into two queues:
- Production Plan
- production performance
The production performance queue contains messages related to events from the process, while the production planning queue contains messages to be sent from the ERP system to the process. The names of the two queues are taken from the ISA-95 standard.
Layer 2 functions can be programmed, but can also be handled by Microsoft Message Queue, IBM's MQ family, or similar standard middleware.
In a MOM project, the best practice is to build two queues at tier 2 in the database structure according to the ISA-95 definition of production schedule and production performance.
As mentioned earlier, the "provide command" block in tier 1 takes the message from the physical process and inserts the data into the correct table in the production performance table of the database.
The "Get Next Message" block in Tier 1 fetches new messages from different tables in the Production Planning section of the database.
Of course, one of the advantages of a MOM standard like ISA-95 is that an international standard makes it easier to change one of the surrounding layers (for example, use standard middleware or the latest version of middleware), as long as the new layer's data structures and interfaces conform to the ISA-95 standard.
Business Logic (Layer 3)
communicate
Layer 3 of the I3 concept serves as the main communication interface with the planning level (layer 4) of the ISA-95 model. The interface must be realized based on the site or the company's ERP system. Some ERP systems directly support the standard ISA-95-based protocol B2MML, which makes it easier to process data directly from ISA-95-based tables in the queue layer. For example, other ERP systems use high-level programming interfaces (APIs) or file-based (CSV, XML) interfaces.
Determining the protocol recommended and applied depends on the specific ERP system, the company's ambitions and the size of the project.
If possible, the most obvious way to interface with I3 is to use B2MML, since the database of the MOM solution is based on the ISA-95 structure. But like the rest of the solution, it is not necessary to make the interface more complex than necessary to meet the needs of the project. In some cases, a simple text-file-based interface may be more than sufficient. By analyzing the complete business requirements of present and future interfaces, and selecting the appropriate interface protocol, process and system adaptability can be part of the design, thereby significantly reducing the total cost of ownership of the solution.
error handling
Layer 3 includes the ability to detect communication errors (for example, loss of connection to an ERP system) and to handle data errors when sent/received messages have incorrect content.
One of the first things to achieve in order for this layer to work properly is to be able to actually realize that there is an error in the message returned from the communication counterparty. Part 5 of ISA-95 describes how to handle this particular functionality in a standardized way. In Section 5, a message receiver (which is processing data) is defined to respond with a message stating whether the request was accepted, rejected or modified.
In the actual example later in this article, this is exactly the functionality required to handle communication errors that were initially defined and programmed manually in each new project of the solution.
Business logic
The most important function of layer 3 is the set of rules for handling expected situations or use cases. Special and customized rules ("logic rules") deal with situations in day-to-day operations and business that require company- or site-specific decisions that cannot be covered without costly damage by the company's manual procedures. Today, many companies send alerts about such errors to operators or management, and then a single person makes decisions and makes manual adjustments to processes, work orders, set points, etc.
Layer 3 automates the response to different error scenarios as much as possible.
As shown in Figure 7-2, whenever the "ready to receive next message" flag is set, the "get next message" block is used to select the next message (determined by a timestamp) from the layer-2 database table. The "Determine Transaction" block takes the message and decodes the ERP transactions required to process the message. Next, the block takes out the relevant parameters of the message and sends the transaction to the ERP system. As mentioned earlier, the protocol used depends on the ERP system.
Figure 7-2: Layer 3, business logic
When a "result" message is received from the ERP system (automatically. by polling data, or through other functions - again depending on the interface implemented), the "error handling" block first detects whether it is an abnormal (not error) message or returns an error.
If it's a normal message, the "provide message/result" block writes the data back to the correct layer 2 table, setting the "ready to receive next message" flag.
If the ERP system returns an error message, activate the "Business Logic" block. The business logic block tries to handle this situation automatically and then (if necessary) sends a different transaction to the ERP.
In general, this layer should be able to handle local (site-specific) rules. The business logic layer also handles global (enterprise-wide) rules, such as whether the company's quality assurance rules allow normal materials to be placed in storage bins that hold environmentally regulated materials.
A big challenge with the business logic layer is that the business logic rules are (of course) very different, and very different from one company to another, and sometimes even between sites within the same company. Therefore, it is difficult to reuse many functions from one project to another. Historically, this layer and its blocks have thus been programmed per project.
example
There are many situations (error scenarios) where the business logic layer is applied. Some examples of these situations are described below.
- Example 1: A machine breaks down on a production line. First, a decision must be made whether the production or work cell order should be paused or processed on another machine. If machining is to be done on another machine, an alternate route and/or machine must be identified. Then, a decision must be made as to whether changes to the production plan are required, such as splitting the order into smaller batches or merging orders into larger batches. Some of the specific functionality in this example can (and is often) covered directly by recipe or route modeling software, but if no such external functionality exists, the decision logic will automatically cover it without operator intervention in this block.
- Example 2: Business logic is often required to manage storage locations in continuous processing facilities such as animal feed mills or flour mills.
For example: When an ERP system wants to load material into a specific silo, many experienced MOM integrators hesitate which solution to use.
- Example 1: According to the ERP system, a particular silo has enough room to ship material, but in reality (due to inaccurate physical measurements or material stuck inside) the silo is actually full before all materials are fully filled. The MOM business logic layer needs to automatically decide which bin the remaining material will be directed to and update the ERP with the actual quantities and locations of all batches. This decision and logic is dependent on a number of weighted factors, e.g., the contents of previously available bins (to avoid material cross-contamination or to avoid mixing environmentally regulated material with normal material) or the best location to unload based on knowledge of the next container materials.
- Example 2: After receiving grain into a 100 ton bin, the bin "high" volume sensor senses that the bin is full and reports "100 tons" back to the ERP system. After a period of time, the material will compress into a smaller volume. The operator physically checks the bin to see that there is now room for more material, so he manually directs more material to that bin. The process control system then reports that the material has been moved to (according to the ERP system) the full bin. Likewise, the MOM business logic layer needs to automatically update the ERP with the actual quantities and locations of all batches.
- Example 3: A common problem with business logic block processing is batch tracking when a large number of materials are layered on top of each other. The scenario is that batch 2 is physically added to a bin that already contains batch 1. In fact, the bins containing the stratified batches interact in a conical fashion during discharge, where a small amount of mixing of the two materials takes place. This type of hybrid rheology is difficult to model and program logic in any kind of software, so one of the other two models is usually chosen.
The "pseudo-material" (1+2) logical model uses a "pseudo-material" layer (data-wise) between the two layers to cover the mixing of the two materials, which needs to be placed when the material flows out of the silo.
The last-in-first-out (LIFO) model says that new material that is physically loaded into the top of the bin is always logically (data-wise) placed at the bottom of the bin. In practice, this is close to what actually happens, but the physical mixing rheology is Difficult to model and implement in material traceability applications.
In order to define the rules for these types of site or company-specific scenarios, empirical modeling must be done through a series of projects to apply a thorough analysis of how physical processes work and how they should be modeled and programmed.
demand analysis
When it comes to programming the business logic layer, one challenge is to get the customer to actually define his or her business and operational logic rules in a programmable form. If they are not 100% defined, they cannot be programmed into the solution.
Depending on the complexity of the project, there are various ways of defining and specifying rules. In some simple cases, customers directly and quickly state what the rules are. But in most cases, business, operational and physical processes must be thoroughly analyzed to determine interactions, dependencies and how different situations are handled. For business and operational processes, the business process management (BPM) approach describes business rules and processes as "well-established". For physical processes, empirical data collection and modeling must be done through a series of engineering tests. Typically a Design of Experiments (DOE) approach is applied. This article does not deal with DOE methods and empirical modeling.
The first step in defining the business and operational logic rules is to use a process operations team composed of end-user working groups. They consist of people from all levels and functions of the manufacturing organization. The Process Action Team describes how the company handles processes, information flow, error handling, etc. These discussions resulted in the BPM diagram. MOM's BPM map graphically shows how business and operations handle different day-to-day situations and the rules to use. This makes it easier to implement rules in the solution described here.
Map I3 to ISA-95
A core part of the I3 concept relies heavily on the ISA-95 standard.
Standards that define operations management functions, tasks, and exchanges within Layer 3 and between Layers 2 and 4 are an excellent way for global manufacturers to design next-generation MOM solutions.
Some models in the ISA-95 standard explain how the functionality of I3 maps to the standard. Figure 7-3 shows which specific parts of the production operations management activity model described in ISA-95 Part 3 have been implemented in the solution.
Figure 7-3: Activity model for production operations management
Production Data Collection is used because production data is collected from the process and exchanged to the ERP system. Production Tracking is used because a summary of resources used (materials, locations and machines) and production materials (intermediate and finished products, actual and planned) is reported to the ERP system.
A small part of "Production Scheduling" is used by providing operators with a simple scheduling list of production orders.
B2MML messages can be used to communicate with the ERP to establish a company's baseline standard for integration to predefined interfaces. In some cases, the B2MML interface can be applied from the ERP system to the process control system through the I3 system. Of course, this can be changed more easily from one system to another (ERP-I3-PCS) if required later.
in conclusion
Starting with the core functionality of any MOM solution (integration between IT systems) will simplify projects and solutions, adapting them to the manufacturer's current needs while meeting future needs at a lower cost. If this is done, extended capabilities could be rapidly deployed as global markets drive changes in manufacturers' organizations. Manufacturers owe their success to adaptable MOMs and the integrated solutions themselves. Since I3 concepts are built in modules, it's very simple to build what you need and then add functionality later. Just add the functionality "offline" to the correct module, test the functionality and interface, then swap the old and new modules.
The described concept (I3) is best suited for plants that have installed an ERP system and a process control system (which is responsible for most of the execution) and only need a communication interface between the two.
Although I3 is a simple solution to the communication problem between the manufacturing process and the ERP system, implementing this solution may still be "overkill" in some sites. I3 should be considered as an option based on future functional requirements, even if the interface is kept simpler, e.g. there may not be a need to handle the site's business logic and/or exceptions.
On the other hand, if the need to handle business logic is very complex, it is advisable to consider standardized off-the-shelf solutions instead of trying to program the solution from scratch. This will save the company time and money.
In cases where a manufacturer has a greenfield plant implementing a system from scratch, it is often best to start with the core functionality and then expand on it.
The solutions described in this article are not "products". It is simply a method or concept to deal with the interface between production and ERP, which has been successfully applied by many innovative manufacturers. There has been and will be a certain amount of reuse from one project to the next. But in new projects, the MOM and interface requirements need to be analyzed to determine the necessary functionality and decide whether I3 is the best approach.
The MOM Transformation Roadmap remains critical to the success of long-term (eg, year X) business goals and a defined and specified strategy that incorporates project stakeholder needs. As mentioned earlier, it is critical to always keep the overall goals and picture in mind, and to conduct an initial analysis of the company's business needs now, future expectations, and the value of the system. Can be found in X years (i.e. define guidance milestones). This can be difficult or impossible if you don't understand or understand the possibilities of a MOM solution and the possible pitfalls such as integrating many disparate IT systems.
Therefore, the best course of action for manufacturers is to work with an experienced MOM consultant who has tried similar things before and can steer the solution in the right direction.