This post was written by Jimmy Asher, director of product strategy for Savigent Software. 

There are many issues facing manufacturers today: increasing regulation, a changing workforce, and unprecedented demands for operational performance. As these factors affect a business's bottom line, individual departments have sought out processes and systems to remove or mitigate the impact of their associated constraints. However, typically these processes or systems only address a particular departmental need, optimizing a portion of the enterprise at the expense of the whole. For example, the quality department may seek a quality management system (QMS), or the operations group may implement a performance management system to track operational metrics.

As manufacturers evolve, they need a more holistic understanding. It is the combination of the shared data from all these systems that delivers the information needed to react to business events or eventually predict future business performance. In the past, it was acceptable to arrive at this combined informational understanding via reports from each of the systems, which were passed between departmental managers. With market demand for decreased lead times, this information must be shared in near real time.

Business system integration has come a long way from the early days of computer systems. Originally, users had to enter data twice to get information from one system to another. As computer systems progressed, information technology (IT) began to reduce this effort via integration projects. These early integration projects, which took years to complete and were often obsolete before the integration was complete, now have been replaced by more successful projects requiring less than a year. This performance increase is largely due to the standardization of data in the manufacturing space, with standards like ISA95 and efforts of the Manufacturing Enterprise Solutions Association. Technology increases for computing platforms have also assisted, as most systems now communicate via Ethernet.

Traditional business integration

Over the years, business integration has evolved. There are now several common approaches.

Point-to-point

Traditional business integration often involves point-to-point integration via a client and server paradigm. The server needs to be aware of the client, and the client aware of the server, with a commonly defined protocol to communicate. This approach gets very complicated the more systems participate.

Each system client/server has its own data schema and interface method. Maintaining this paradigm is complex. As a system is updated or replaced, all the systems need to be updated. Because manufacturing systems need to be reactive to the needs of the business, new product information must be reflected in each of the systems and interface methods.

Extract, transform, and load

Propriety communication methods gave way to database integration, still with the above point-to-point integration. Extract, transform, and load (ETL) is used to migrate or share data from one database to another.

• Extract: read the data from the database
• Transform: convert the extracted data from its original form into the target form
• Load: write the data into the target database

In a point-to-point integration, each system must maintain several ETL methods (one for each integration).

Enterprise application integration

Enterprise application integration (EAI) uses methods such as ETL, however, with a central hub that handles the data. While an improvement, the ETL method is often mixed with application logic.

Service-oriented architecture

IT has combated the limitation of both point-to-point and EAI with a service-oriented architecture (SOA). This approach uses services to loosely couple units of functionality that can implement an action. Although SOA addresses connectivity, it does not address the need for orchestration logic. This requires the integration transformation and orchestration logic to be placed within individual systems.

The challenge

As you can see, a number of approaches may be used to convey information from one business system to another. A typical manufacturing plant has several manufacturing applications, such as product life management (PLM) and enterprise resource planning (ERP); a manufacturing execution system (MES), advance planning and scheduling (APS), and a quality management system (QMS); and the programmable logic controller/human-machine interface (PLC/HMI). Figure 4 is an overview of some of the applications.

The systems play different roles within the organization, but with decreasing time to market and increased production rates, they need to share information. Enterprise applications typically are capable of communicating via an SOA approach (enterprise service bus [ESB]), enabling them to share data with each other. However, manufacturing systems, for a variety of reasons, do not participate in the ESB.

Beyond the technology of integration, the value of the integration is sharing data to enforce or aid in a business process. This business process may involve systems, equipment, and people.

What is workflow?

Workflow is a series of event-triggered tasks or actions within an organization to produce a final outcome. The actions may be performed by people, systems, or machines. Workflow is a way of describing the order of execution and the dependent relationships between both long-running and short processes without the need to dictate coding details. This orchestration manifested itself in businesses with business process management systems. These same concepts are now available in the manufacturing space with purpose-designed workflow engines that have the added consideration of robustness, speed, and quick deployment that manufacturers need.

An example workflow scenario

The figure below represents a simple process that runs every time a changeover occurs on the factory floor. This process is triggered by a machine event requesting changeover. Following the process, the system obtains the discrete schedule from the APS. It then processes the schedule, looking for the order with the highest priority allocated for that machine cell (which is presented and verified by the operator in this case; however, it may be completely automatic in some cases). It then loads the specifications and recipes from the PLM system. Next, the process order is started at the machine cell. Once production begins, consumption of raw materials is updated in the ERP system. Also during the production process, the inspection plan is retrieved from the QMS. Depending on the inspection plan, a sample may be taken, and the results automatically posted to the QMS (during the "UpdateInspection" step). Once the production is complete for that particular production order, the production counts are updated in the ERP system, and the QMS records are marked with the corresponding status.

In the execution of this handful of steps, this process interfaced with:

•    APS
•    PLM
•    ERP
•    PLC/HMI
•    People

The example in the figure illustrates the capability of workflow systems to capture the business process. But in addition to that, each one of the actions is interfacing with a different system. It is important to note that the method used to interface with the corresponding system is independent of the integration method. The ERP system is interfaced via an ESB method, and the QMS system is an ETL.

Because of this abstraction, manufacturers can choose to upgrade a point system with minimal impact. The "UpdateInspection" action in figure 5 is valid, no matter which QMS system or interface is used. This allows any system to be decomposed into two elemental transitions-actions and events-for each type of functionality needed. To aid in this decomposition process, you can use the standards, such as OAGIS from the Open Applications Group.

As the actions in the model represent the true business value of the system, they can be combined in such a way that a new process can be quickly and easily enforced. Workflow can also leverage traditional concepts, such as SOA and ETL, while providing true business orchestration.

Conclusion

Business system integration is evolving; however, manufacturing must contend with a variety of integration methods. The orchestration of business processes is what drives the value of the integration. This orchestration needs to be quickly modifiable in today's manufacturing landscape.

A workflow-based approach is an alternate method of business integration that allows greater flexibility. Workflows can wrap existing purpose-based systems, allowing for easier integration while, at the same time, remaining flexible for evolving business needs. Beyond this added flexibility, an approach will be identified that allows subject matter experts to create the integration without a separate IT effort. Workflow-based integration allows a purpose-based system to be extended to maximize value in ways not possible with traditional business integration methods.

About the Author
Jimmy Asher is the director of product strategy for Savigent Software. Jimmy has been active in manufacturing and systems integration for more than 20 years. A mechanical engineer, he started his career in machine design and robotics; as his career progressed he focused more on controls systems and integration. He has many years of experience programming PLC, HMI, DCS, and MES systems in a variety of discrete and process industries across many industry verticals, both regulated and nonregulated.

Connect with Jimmy:

A version of the article also was published at InTech magazine.