Applying MOM systems in Industry 2.0 in manufacturing

introduce

What are the best practices for Manufacturing Operations Management (MOM) systems and IT architectures?

What do industry experts advise on manufacturing types and supply networks?

Is management thinking and corporate culture becoming obsolete due to changing global markets?

Is MOM technology too expensive, and is the IT architecture unable to adapt quickly to market changes?

Manufacturing companies have long been reluctant to adopt new thinking for operational workflows. While factory equipment continues to evolve, smart device-enabled workflows are still largely based on paper transactions to execute production orders, as if to say, “Our methods have worked for years, why change them now?” With this in mind, the world of smart technology has moved forward and left manufacturing companies behind. Few manufacturing companies worldwide have kept up with the latest developments in smart operating methods, and only truly progressive companies have adopted these smart manufacturing developments, usually through a 10-15 year process of trial and error.

As shown in the 2008 Aberdeen Group and 2010 MOM studies, these 20 percent of “best-in-class” progressive companies outperform their competitors by adapting to market changes more quickly and easily. They are not constrained by inflexible legacy systems that are difficult to change, or numerous "point-to-point" interfaces that prevent application changes and new product introductions faster. The flexibility of their MOM system allows them to generate higher Overall Equipment Effectiveness (OEE) and increase perfect orders, reducing factory operations and supply chain cash-to-cash costs. Their flexible MOM system allows them to respond to manufacturing metrics in real time and actually improve operations through better communication, reducing waste and increasing efficiency. These companies also typically have a lower total cost of ownership (TCO) for their manufacturing software applications, further reducing operating costs and increasing their competitive advantage.

Unfortunately, most manufacturing companies are in a truly sad situation. Non-progressive manufacturing technologists, the people in organizations responsible for implementing and maintaining manufacturing technologies such as manufacturing execution systems (MES), MOMs, and automation, are clearly letting their companies down by focusing on departmental-based point solutions. However, this isn't just the fault of the manufacturing technicians. Manufacturing technology vendors, as well as old-fashioned end-user management with no vision, must bear the brunt.

Most manufacturing system vendors would rather spend their research dollars improving their current (often outdated) architectures and adding new functionality to outdated software than developing new, incremental architectures. It is also a better business case to have the integration technology as part of the application rather than abstracting it from the application and providing it as a Web service. If integration can be provided as a service, why should customers "rip and replace" or continue to support installed applications when they scale? Even with the advent of OLE for Process Control (OPC) many years ago, this idea still prevails among a handful of distributed control system (DCS) vendors and the automation community. Only after progressive end users started requesting (or even insisting on) OPC connectivity did OPC become the de facto standard at the automation level.

According to Aberdeen research, more than 80% of end-user manufacturing technicians don't know what's better; they take whatever their tech vendor tells them about service support and don't think about it anymore because they're often so called by the vendor's software Blinded by the "new and improved" features.

So, what change of thinking do end-user manufacturing technicians and manufacturing software vendors (MES/MOM vendors) need to have?

These groups need exposure to the ideas and concepts of Manufacturing 2.0 (Mfg. 2.0) developed by the Gartner Group and then supported by case studies and best practice research from industry organizations such as MESA and ISA-95 Best Practices working groups. Once manufacturing companies start demanding flexible MOM systems based on the Mfg. 2.0 architecture, suppliers will have to follow suit (as mentioned above, even DCS suppliers will eventually embrace OPC connectivity, even if reluctantly).

This article explores the four main perceptions and hurdles that the aforementioned "best in class" progressive companies must overcome in order for their MOM system architecture to become widely accepted as a corporate strategy.

This article discusses four barriers or perceptions to demonstrate that the mindset of end-user manufacturing technicians and suppliers is not proactive but reactive. these are:

1. Why MOM and not MES?

2. Why use Service-Oriented Architecture (SOA) in manufacturing?

3. Why choose to use MDM for manufacturing?

4. Is EMI best positioned with or in conjunction with Business Intelligence (BI)?

For each of these concepts, what they mean and where they fit will be explored individually to enable manufacturing technicians to understand the concepts as well as embrace and work towards this vision. The paper concludes by evaluating different ensemble methods used over the years and comparing them with currently proposed "best practices" and Mfg. 2.0.

Why MOM and not MES?

New thinking has long since moved beyond the old MES and into the realm of Manufacturing Operations Management or MOM (including MES).

Manufacturing operations management itself is nothing new; it's been around longer than MES. What is new is that MESA and ISA have adopted the MOM definition from the ISA-95 standard, rather than the "old" MES concept.

What makes the ISA-95 MOM different? The ISA-95 MOM includes many operational activities and functions that are not traditionally part of MES as it is defined by AMR Research (Gartner Group). The coverage of the ISA-95 MOM is also much broader than the traditional 11 domains developed by MESA in the 1990s. These outdated AMR or MESA models cannot be used to guide and design systems. In addition, the word MES, although it has a long history, has always been confusing. If you ask 10 people to define MES in their understanding, be prepared to get 10 different definitions. MOM, on the other hand, is easier to define because it uses the framework in the ISA-95 Part 3 (MOM) standard.

APICS (The Operations Management Society, formerly the American Production and Inventory Control Society) defines operations management as:

1. The planning, scheduling, and control of activities that transform inputs into finished goods and services.

2. Key research areas. Effectively plan, schedule, use, and control the operations of a manufacturing or service organization by studying design engineering, industrial engineering, management information systems, quality management, production management, inventory management, accounting, and other concepts affecting functions.

3. A Manufacturing Execution System is a program and system involved in shop floor control that uses: (1) program logic controllers and process control computers for direct and supervisory control of manufacturing equipment; (2) systems that collect historical performance information and then generate reports Process Information Systems, (3) Graphical Displays; (4) Alarms/Alarms/Triggers to notify operators of current and recent plant conditions.

Quality control information is also collected as defined in ISA-95 Part 3, where a Laboratory Information Management System: (LIMS) or Quality Management System (QMS) may be part of this configuration to link workflow and conversion process conditions to quality data. This allows causal relationships to be identified, analyzed, and proactively programmed into the system. This is manufacturing intelligence. Sometimes quality data influences the control parameters used to meet product specifications, either dynamically or offline. The MOM system can be any system that supports this feature.

The standard definition of ISA-95 MOM provides the required framework for specifying the functions, tasks, and data exchange of systems. ISA-95 Part 3 defines MOM as "The activities, functions and communications of people, equipment and materials in manufacturing that are coordinated within Level 3 of a manufacturing facility." It includes Production Operations Management, Maintenance Operations Management, Quality Operations, and Inventory Operations Management (See Figure 1-1, third floor).

Although it has been in ISA-95 since 2000, only a moderate number of manufacturing technicians and a limited number of suppliers have accepted MOM into their solutions. Fewer efforts are actively building and supporting the ISA-95 MOM, and more are sticking with the obsolete term MES.

The thought and use of the term "ISA-95 MOM system" in a general panel discussion shows the audience that a technologist or vendor may have actually read, seen, or heard of the ISA-95 standard.

Figure 1-1: ISA-95 Functional Hierarchy Model for a Manufacturing Company

Why Use Service-Oriented Architecture (SOA) in Manufacturing?

The next evidence that manufacturing companies are falling behind is their lack of a standards-based vision for integration. Controlling technology standardization at the MES/MOM level is different from an integration-based vision. This lack leads to big data integrity issues due to the use of point-to-point interfaces and lack of a coordinated information model. The "fork and replace" program is not based on a standards-based vision for integration. For most companies, these standardization moves are cost-prohibitive and impractical.

What is a standards-based integration vision?

First, it is a vision where data transfer and transfer functions are abstracted from the applications themselves into a standards-based service layer as a manufacturing information model that operates independently of changing business processes.

Those who have worked on enterprise integration projects think of it as Service-Oriented Architecture (SOA), but SOA is generally a dirty word in manufacturing - not because the concept is unreasonable, but because manufacturing technologists and their suppliers are so obsessed with SOA I don't know enough to accept it and work with enterprise architects who want to apply SOA technologies in manufacturing. After all, based on project thinking, point-to-point integration is much faster and easier than long-term implementation of SOA-based integration. Manufacturing technologists would rather protect their integration vision to the exclusion of enterprise architects than attempt to understand and apply the technology. This cultural gap between manufacturing engineering and enterprise IT is a persistent battleground.

Most manufacturing technologists believe that applying SOA concepts to manufacturing is outrageous and will never work. Most people who have talked to enterprise architects realize that enterprise architects just don't understand the complexities of the manufacturing environment. As a result, manufacturing technologists have long been skeptical of any discussion of IT architecture, such as Web services as the foundation of SOA. But skeptical manufacturing technologists must see what SOA actually does, according to Gartner and MESA, and then consider how it applies to manufacturing, and MOM in particular. The end result of the disagreement between manufacturing system technicians and enterprise IT is generally poor data integrity for independent data model sets based on independent systems. So when a typical industrial plant requires 15 to 20 systems to process a single production order, data corruption is the norm as data is aggregated into reporting, scheduling, planning and supply chain activities. SOA allows the creation of composite business applications from independent, self-describing and interchangeable code modules (called "services"). These services are available on a Service Bus where they are arranged into business processes or composite applications using process orchestration. When SOA is used as an integration strategy, it brings a self-describing catalog of atomic business services that are used together to create business processes (including manufacturing operations processes).

For SOA, my idea is that business and market needs drive IT systems, rather than IT systems determine how the business operates. This brings flexibility, which is one of the main requirements of a MOM system, as manufacturing requirements change frequently.

Many companies, including manufacturing companies, have implemented enterprise service buses (ESBs) specifically to simplify integration. These ESB architectures have not yet penetrated into manufacturing itself, and for good reason. The Enterprise layer (Tier 4) and the Manufacturing Operations layer (Tier 3) are not the same, do different jobs, and have completely different priorities, data types, transaction types, and business and operational processes. Only a small subset of manufacturing process data can go up to the enterprise level, and then usually only in aggregated form. However, a large amount of manufacturing process data is shared within the factory's 1st to 3rd floors to process a single production order among 15 to 20 systems.

From this we can conclude: "For MOM, a separate Manufacturing Service Bus (MSB) is required due to the high transaction volume, high parameter data load, and near real-time requirements of operational applications. The MSB can be scaled down to A region, or across multiple production facilities, depending on the transaction/data load and response requirements of the operational workflows supported by the plant applications."

Therefore, we need to define SOA for manufacturing (GSOAm) for workflow, which looks very different from SOA for supporting enterprise business processes. We will also have an ESB and an MSB in our manufacturing enterprise architecture. The question is, how do we sell this concept to enterprise architects and manufacturing technologists? Each of them has a specific view of the world, as shown in Figure 1-2: Enterprise SOA - a work in progress.

SOA is shown as functional layers, as shown in Figure 1-2. The bottom layer consists of existing or legacy applications that lay the foundation for how business data is used. These are "mission critical" applications that keep the day-to-day running of the business. The next layer provides integration. In SOA, the integration layer is implemented using an enterprise service bus (ESB). The ESB layer provides security, transport, mediation and event services. It can also provide business metrics and a workflow or business process engine.

The business services (middle) layer is the abstraction layer of services for the underlying IT systems. These services are the work in SOA. They are expressed using the Web Services Description Language (WSDL) that wraps business applications.

The business process layer consists of business processes created by combining services in the business services layer to produce composite applications. Composite applications are a new approach to performing application development in SOA (discussed in more detail later).

Figure 1-2: Work in progress on Enterprise SOA-A"

The portal/dashboard layer consists of data aggregation and visualization. The problem with Figure 1-2 is that the Manufacturing Operations (or MOM) system is just one of many other systems that need to be integrated with other enterprise systems. However, for most companies, these other (non-MOM) systems are already integrated and operate at the enterprise level, where the MOM system is distinct and operates at the plant or site level. MOM systems are typically not a single system per site, but may consist of multiple systems that all execute real-time workflows based on available resources. This complicates things and is one of the biggest reasons why layer 3 systems have not been integrated using ESB based architectures.

There is hope, however, as there are several case studies showing that some companies have already implemented SOAm within Layer 3 proposed in this paper. These case studies come from Gartner, ARC, Aberdeen and MESA.

The SOA architecture proposed by Gartner and MESA in white paper #27 "SOA in Manufacturing Guidebook" is shown in Figure 1-3: SOA for Manufacturing. (SOAm) Some key real-time differences. As shown in Figure 1-3, the architecture is closely related to this architecture. The enterprise architecture is shown in Figure 1-2.

In Figure 1-3, the MOM system is depicted as a component, while the enterprise application is depicted as just one of many systems that need to be connected to the manufacturing service bus. Figures 1-3 emphasize that, as mentioned above, separate MSBs are required due to the large number of transactions, high parameter data loads, and near real-time requirements of operational applications. Depending on the transaction/data load and response requirements of the operational workflows supported by the plant application, an MSB can scale down to a single plant or area of ​​a plant, or scale up to multiple production facilities. A key aspect of Mfg. 2.0 is that it explains that manufacturing master data management (mMDM) differs from MDM on an enterprise business process ESB. Mfg MDM serves a different set of manufacturing operations management applications, such as scheduling, route execution, and alarm and event applications, which have a finer-grained set of objects, attributes, and production rules than MDM representing enterprise planning, (master) scheduling, and logistics.

Figure 1-3: SOA for Manufacturing (SOAm): some key real-time differences

Therefore, the architecture is similar but serves a different purpose. With this perspective in mind, manufacturing technologists have a good counterpoint to discussing the real-time architecture of decharacterized workflows with enterprise IT architects and communicating to them the difference between the enterprise view (Figure 1-2) and the manufacturing view (Figure 1-3). Based on the high variability required for optimization, manufacturing technologists can now justify the need to isolate the MSB from the ESB (even with the same technology).

So, what is the right number of MSBs in a global enterprise? One per manufacturing plant or campus?

Support transactional traffic as needed? We're not sure about this, but it makes sense for each geographic site to have at least one MSB linking to the ESB. It would be difficult to implement a bus for each site without an architectural strategy and roadmap for the MSB as a common infrastructure element and without burdening any single software project with installing the MSB itself. This lack of a long-term manufacturing architecture vision may be another reason why SOA as an application concept has not been widely accepted.

Why Choose MDM for Manufacturing?

Few manufacturing technologists have heard of master data management (MDM), and few understand what MDM actually means. This further proves the conservative thinking of more than 80% of end users. Enterprise solutions have long relied on MDM systems to ensure naming consistency and data translation between different enterprise-level solutions. Manufacturing technologists haven't even thought about this, as seen in the proliferation of point-to-point interfaces between manufacturing systems.

One thing to note in Figures 1-2 and 1-3 is the different MDM components in each architecture. MDM is a tool for correlating data between different applications.

So, what is master data and why is it important?

"Master Data Management (MDM) includes a set of processes and tools that consistently define and manage an organization's non-transactional data entities (possibly including reference data). The goal of MDM is to provide processes for collecting, aggregating, matching, integrating, quality assurance, persisting and distributing such data throughout the organization to ensure consistency in the ongoing maintenance and application use of this information."

Common processes in MDM solutions include source identification, data collection, data transformation, normalization, rules management, error detection and correction, data integration, data storage, data distribution, and data governance.

Why do you need to differentiate between enterprise MDM and manufacturing MDM (mMDM)? According to MESA, in the vast majority of cases, general recipes for engineering bills of materials (BOMs), routings or enterprise resource planning (ERP) or recipe/product lifecycle management (PLM) systems lack the necessary level of detail:

• Run detailed routes through shared store resources.
• Set the processing logic executed by the batch system.
• Adjust batch sizes to match local equipment assets and provide limited capacity scheduling for those assets.
• Set detailed machine settings.

Heterogeneous legacy systems, trust/distrust in controlled MOM systems, data ownership issues and data inconsistencies compound this issue. The absence of a strong common data architecture fosters a proliferation of unregulated data definitions, point-to-point integration, and narrow data management policies. In a manufacturing environment, all of this translates into multiple types of waste and increased costs.

The master data required to execute production processes is highly dependent on individual process, asset, and site-specific considerations, all of which change at a much higher frequency than typical corporate processes such as new product introduction, continuous improvement, order entry, or accounts payable processing. Manufacturing master data is thus mixed with site-level details such as customer IDs or high-level product specifications shared between enterprise order entry systems and factories, and site-specific or "local" details such as equipment operating characteristics (which may vary with local humidity, temperature and drive speed) or even local raw material characteristics. Data requirements can also vary by culture or country, such as trucking regulations, transit times, and customs requirements, which can all affect production and shipping planning.

In addition, even if the physical manufacturing process is similar, financial regulations can affect how various factory operations are wired, partitioned, and consolidated, and how raw materials are accounted for as they turn into finished goods.

This natural delineation between enterprise master data and "native" or manufacturing master data suggests a specific architectural approach to menu-factored master data management (mMDM), which borrows heavily from the enterprise MDM model but has been tailored to the manufacturing environment. Specific requirements have been adjusted.

Think of a company that has acquired various manufacturing entities over time. It has integrated its enterprise systems, but at the site level, things are different. Different sites may have different names for the same raw material (e.g., 11% HCl, hydrochloric acid, pool acid, 11% hydrochloric acid), and this same raw material is used in batch systems, SCADA systems, LIMS, storage systems, It may also have a different name in the MOM system. This lack of consistency made it difficult for the COO to report hydrochloric acid consumption from a COO perspective, because without mMDM, consumption queries would have to be customized for each site and system in order to extract order consumption.

Another approach, of course, is to initiate a naming standardization effort, which may take years to complete, as most Tier 2 and Tier 3 systems will require changes. And that's not even taking into account the redevelopment of visualization and retraining of operators. The problem is, once the naming standardization is done:

• Who has master naming rights and naming rules?
• Who makes sure the plant doesn't diverge again over time as new products, materials, processes and equipment are added and changed?

The example above is a very simple one, for one raw material, but it must also apply to other resources, utilities, equipment, operating parameters, recipes, WIP and products. Otherwise, data corruption is a proven result. For example, if a company has implemented a barcode scanning solution, the material number for a particular product or component may vary from supplier to supplier. Taking this to a global level, consider how language translations and local regulations affect how objects are named in the system and how objects are classified, and the complexity of displaying object data not just on screen, but in the user's local language, while still Make data available for integration.

How does the system know which products/components have been received or sent to the factory without some translation somewhere?

As such, mMDM solves many of the problems that manufacturing companies today face when enabling more flexible integration between Layer 3 and Layer 4 systems.

Figure 1-4 shows the relationship between mMDM, MDM, SOA, and SOAm and how they work together.

The goal of the proposed split of architecture between enterprise and plant is to increase application flexibility without reducing the effectiveness and efficiency of integration between systems. It also abstracts the interface mechanism from the application into a service that runs regardless of application changes. This approach will prevent many point-to-point interfaces from corrupting data and make the system more flexible in adapting to changing conditions.

Figure 1-4: The supply network is a fusion of E-SOA and SOAm

SOAm architecture also abstracts business processes and their orchestration from individual applications to an operational business process management layer. Now, a person can interact with multiple applications to track or manage production orders without even realizing that he/she is jumping between applications.

Figure 1-4: The supply network is a fusion of E-SOA and SOAm, illustrating the relationship of SOAm roles to enterprise SOA. Mfg 2.0 is a SOA approach rather than an application that embraces diversity, complexity and new dynamism in demand-driven manufacturing while:

• Take advantage of scarce manufacturing talent.
• "Give up and capitalize on manufacturing investments instead of ripping them out and replacing them with better 'mouse traps'."
• Eliminate software availability and rigid data models as barriers to building, deploying, and adopting manufacturing applications.
• Collaborate on internal and extended enterprise products and operational processes.
• Transform to applications and governance that excel at changing business and operational processes easily and at low cost.

Even with SOAm and mMDM, integration will not be efficient and effective unless message structures and data exchange are in a standard format.

This is where ISA-95 again plays an important role in ensuring interface validity and consistency. Even mMDM and SOAm cannot achieve interface reuse without standardized data exchange structures and patterns.

ISA-95 provides information exchange standards and standardized data structures and XML message schemas based on the Business-to-Manufacturing Markup Language (B2MML) developed by the World Batch Forum (WBF, now merged with MESA International), including verbs and nouns for data exchange. Standardizing across manufacturing operations ensures that standard services are developed to accommodate multiple applications.

Is EMI best positioned to counter business intelligence (BI), or leverage BI?

A final piece of evidence of the backward state of manufacturing systems thinking is the slow adoption of enterprise manufacturing intelligence (EMI) in manufacturing. Most plant managers and COOs want to use EMI, but their manufacturing technologists can't do it, and traditional business intelligence (BI) technologies are already being used at the enterprise level. As a result, manufacturing is forced to implement enterprise BI solutions that were not designed for real-time data and processes. This results in a high number of failed projects and poor integrity data in reporting, scheduling and planning, and the supply chain.

But if a company has already implemented a BI solution, why implement EMI?

To answer this question, see Figure 1-4. In this isolated architecture, both BI and EMI (called OI or Operational Intelligence in the diagram) are shown. EMI and BI have different purposes, targeting problem sets and audiences. Forms MDM works for the same reasons as MDM because the content, context and data frequency of the data in BI are different for manufacturing-specific reporting and intelligence.

Data in BI solutions is often traded at the same low frequency as in ERP systems, such as daily values. BI isn't enough for plant managers who want to understand what's happening on a shift or hour-by-hour basis. The real-time nature of manufacturing operations and their very high data rates are often not considered in the design and implementation of BI tools. As a result, BI cannot handle the high frequency data ingestion and fast response times required for reporting/visualization required by manufacturing operations.

Executives use BI tools as a strategic analysis and decision-making tool for their companies. From their BI system, they can see the profitability of individual factories and sites over time, which enables them to make decisions such as whether to close factories or change manufacturing strategies. Because their data is based on defined time periods, BI systems often deal with numbers and results that are easier to confirm and verify than real-time workflow EMI; executives want to be sure they have accurate data when making decisions.

Validation/validation or audit steps often add considerable time between the actual event and the data finally entering the BI solution.

However, field-level production personnel cannot wait for details to be reviewed and verified before taking action. If a report or EMI dashboard indicates a problem, it is their responsibility to investigate and take corrective action. If the feed rate is lower than planned, the production manager does not wait until tomorrow for results awaiting confirmation in the BI system to take corrective action. He/she will investigate, or have someone else investigate, and if it turns out to be a false positive, all is well, crisis averted. If something goes wrong, the manager takes corrective action, or doesn't, otherwise, the manager at least knows and expects no bad results from the BI system tomorrow. Production executives hate surprises, even good ones.

Therefore, the EMI system serves three purposes:

1. Get real-time early warnings of potential issues so people can make decisions or take action.
2. Provides "slicing and dicing" of historical data to improve processes.
3. Provides a large library and methods for interface addressing of layer 2 devices and layer 3 systems.

EMI owns the data, applications that are provided at the granularity and frequency that individuals provide. This can vary from seconds to days, depending on specific operational requirements. Data is also available for each piece of equipment, production line or processing unit and can be aggregated by hour, shift, day or week. The granularity of EMI systems is closer to real-time, and they are often used as real-time dashboards for operations managers.

Evolution of Ensemble Methods

In addition to the above issues, the reason for the slow adoption of the Mfg 2.0 vision is that different companies develop at different speeds. The integration vision of the manufacturing technologist develops based on experience, new thinking, and the current integration state of the enterprise. Over the years, as technology has improved and developed, ensemble theory has changed and adapted to new knowledge. Every company adopts its own vision or strategy based on the needs of the company when creating a vision, and few companies regularly review and update their vision or strategy based on new knowledge.

With this in mind, what are the "best practices" for enterprise integration proclaimed by industry groups such as ISA, OAGi, and MESA, and how have they evolved over time?

1. application-centric

The first and simplest and most commonly used approach to enterprise integration is the "application-centric" approach, as shown in Figure 1-5. In this method, code is generated to establish peer-to-peer data transfers between applications. It's still wildly popular due to the project mentality, as it's fast and cheap (at least initially) and requires no new training for field personnel. Therefore, development can begin as soon as the requirements are identified.

Figure 1-5: Application-centric approach to enterprise integration

The problem with this approach is that new interfaces are usually developed from scratch each time with minimal reuse, increasing development costs. Using this approach means that all items are implemented in a custom way. This, in turn, is likely to lead to data inconsistencies, as data translation between systems is often manual or hard-coded. Any change to one application would require expensive custom changes to the interfaces, and since those interfaces were custom developed, they were brittle and slow to change. Due to the need to integrate between multiple systems, the same or similar data needs to be provided in different custom formats, new interfaces need to be developed for each requirement. This proliferation of custom point-to-point interfaces often leads to an unmanageable interface "spaghetti" effect. When the original developer of the application or interface is promoted from his or her "super user" role, the high application of this method can increase the cost significantly.

1. data-centric

The next evolution is a "data-centric" approach, as shown in Figure 1-6. In this approach, a central database or data warehouse is established to organize data from multiple applications into a common data store. Extract, transform, load (ETL) tools are used to move data from applications into data stores. A data modeling environment is required to ensure proper contextualization of data in the data store, and a data warehouse environment and data quality tools are often used to ensure data validity and storage. Reporting tools related to data warehouses are also required to ensure effective visualization of data.

Figure 1-6: A data-centric approach to enterprise integration

This approach provides a central, common source of data where standard reports and dashboards provide the same view to all users. Sophisticated analysis can be performed and operational performance can be predicted based on trends. This approach improves "delivery" performance with re-aggregated data. This approach can be used effectively in simple reporting and analysis processes where decisions are made in weeks and months rather than days, hours or minutes.

The problem with this approach is that the data model is difficult to change, so data usage needs to be well understood up front. Also, the data may be old due to ETL latency or asynchronous update frequency. Because there is only one-way data flow, this is primarily a reporting approach rather than a data integration approach.

1. Interface-centric

The "interface-centric" approach shown in Figure 1-7 uses enterprise application integration (EAI) tools such as WebSphere, Tibco, and Vitria in the adapter development environment. Instead of developing a point-to-point interface, the development adapter extracts (or publishes) data into the common EAI bus. The bus transmits the data; and other subscribed adapters load (or consume) the data into applications that need the data.

Figure 1-7: An interface-centric approach to enterprise integration

This approach is used for company-wide integrations, where a central transport medium must be able to access all data, and publishing and subscribing is essential. A bus typically has a rules engine for writing rules to govern business and operational processes within the bus environment. This method also manages message delivery and provides guaranteed data delivery. It is typically a single-vendor solution that reduces complexity with a single integration environment. It also has the advantage of abstracting the interface from the application itself, which means that changes to the application do not necessarily require changes to the adapter.

The problem with this approach is that users must adhere to proprietary EAI vendor standards, so application vendors cannot develop open industry standard solutions. All information also flows through the central bus, hindering the scalability of the approach. Also, EAI licenses are often very expensive.

1. model-centric

A "model-centric" approach, where services are developed instead of adapters. Tools used typically include registries/repositories, BPM or workflow tools, security, monitoring, and service development environments for governance and lifecycle management.

This approach is especially useful when business and operational processes or underlying IT technology changes frequently to configure changes in business processes or technology at different sites. Therefore, this approach is well suited to today's operating environment, where changes are frequent and each global site has its own infrastructure, processes and working methods.

This approach facilitates the development and adoption of industry standards for interfaces such as Machine Information Management Open Systems Alliance (MIMOSA), ISA-95, Open Application Group Integration Specification (OAGIS), Business-to-Manufacturing Markup Language (B2MML). Integration capabilities can be provided by any ERP or MOM vendor, providing the agility and flexibility necessary to rapidly change processes without impacting interface services or data exchange. In this approach, IT technology is separated from business processes. Data transfer services are also abstracted from the application in an "interface-centric" approach, as is the business process rules engine. This approach can also be used to combine traditional technologies with "best practice" approaches, enabling incremental adoption.

The reason this "best practice" approach has not been more widely adopted is that it requires a steep learning curve for developers; it requires comprehensive governance and service management; and it requires "good" services to maximize reuse. Additionally, vendors have been slow to release applications and services that are compatible with Web services.

This approach is also defined by MESA as part of the Mfg 2.0 architecture.

ERP/MOM Integration "Best Practices"

As integration methods evolved over time, standardization was attempted at the technical level (first with data warehouses, then with EAI). A model-centric approach (Mfg 2.0 architecture) not only abstracts the interface from the application, but also removes the application from the underlying technical infrastructure.

For the Mfg 2.0 architecture to work, standards need to be defined and implemented within the manufacturing company. According to Gartner (and underwritten by MESA), "Application interoperability requires interface standardization. Only 5% of the interface is a function of the middleware. The other 95% is a function of the application semantics." It is therefore important to focus less on technical standardization and more on standardization of the semantics used during data exchange. This Mfg 2.0 architecture combined with ISA-95 not only provides a mapping of zero-activity integration architectures, but also provides common standards and common languages ​​that make true integration possible.

in conclusion

Moving from the current vision of legacy systems and integration to a standards-based integration vision will obviously not happen overnight. What is needed now is a pragmatic approach that combines current integration efforts with a phased approach to achieving the standards-based vision.

A pragmatic Mfg 2.0 architecture built on legacy systems, in which standard services are developed and then implemented for systems that are not yet integrated or based on SOAm architecture. For already integrated applications, develop services to bridge legacy technologies with new architectures. These legacy applications are phased out over time, if appropriate, or are retained until end of life before being replaced without losing support for real-time workflows.

With this pragmatic approach, legacy infrastructure is combined with new thinking. However, for this pragmatic approach to succeed, businesses will need a long-term Mfg 2.0 strategy supported by passionate manufacturing technologists. For manufacturing technologists to be enthusiastic about Mfg 2.0, they must overcome their prejudices, embrace enterprise architects, and start researching and applying new thinking.

So, they need to start using MES instead of MOM as this will put them in the right frame of mind. They need to start to understand SOA and have to move away from "application-centric integration" because the concept of services is fundamental to the Mfg 2.0 architecture. They need to start figuring out how MDM can help and stop taking the easy way out and promoting "interface proliferation". They need to properly position EMI or OI by understanding what BI actually does and how EMI/OI differs from BI in order to provide manufacturing managers with the correct information for decision making. Manufacturing companies that do not change their minds will stagnate in system development.