There are many technological possibilities in manufacturing automation that are often discussed but rarely done. Probably the greatest of these is the control-to-enterprise connection. This connection is, of course, commonly made to deliver production data up to an ERP system for transactional reporting purposes. Far more rare is the connection of these two worlds for bi-directional automated workflow purposes. Even rarer is the company who will talk about it publicly.
Fortunately, Tim Morrison, business process manager, production execution, at Dow Corning, shared his experiences around this shop floor-to-top floor technology connection at the 2015 Siemens Automation Summit.
Morrison explained that this project, which officially began about a year ago, involved the connection of multiple control systems from different vendors installed at 22 globally dispersed plants to the company’s centrally located SAP enterprise resource planning (ERP) system. One of the main reasons driving the need for this integration was system communication complexity. According to Morrison, “Complexity limits our ability to respond to manufacturing and supply chain initiatives.” And as transaction volumes across these systems continued to increase, communication between all these systems was only becoming more complex.
To break this cycle of increasing complexity, Morrison said Dow Corning saw a clear need for “a simplified manufacturing integration framework using a globally standardized and proven system” that leveraged the Siemens PCS7 process control platform on which Dow Corning had standardized. He was quick to point out that the framework to be developed also had to integrate with non-Siemens control systems across Dow Corning facilities and be usable by other Dow Corning business operations such as warehousing and maintenance.
To build this framework, Morrison said two key standards came into play: ISA95 and ISA88. “We used ISA88 to map the entire enterprise and define links and data stores with ISA95.” The standard definitions in ISA95 were used to “level set the project team” and lay out the requirements for the project.
He added that a third party integrator was also brought in to help “define a multi-generational plan and document the technical approach.”
The functional scope of the integration framework had, as its basis, four key business drivers: real-time schedule management, real-time material management, asset utilization, and manufacturing analytics. These functions required bi-directional communication capabilities between the ERP system and the shop floor controllers, such as:
— Downloading SAP process orders into the Siemens batch engine;
— Automating material consumption and production;
— Automating the recording and classification of batch loss events; and
— Generating and recording structured batch execution data.
According to Morrison, the specific business values delivered by these capabilities include: visibility into and automated delivery of the production schedule directly to operations via the PCS7, ensuring the timeliness and accuracy of inventory data in SAP, improved OEE metrics, and providing a data foundation for batch analytics which can be used to drive continuous improvement.
The integration tool used to enable the transfer of data between the control and enterprise systems is SAP’s MII (Manufacturing Integration and Intelligence). According to SAP, the MII tool is a Netweaver (Java-based) information interface that ensures all production data—such as orders, materials, machine status, quantities, cost and product quality—are visible to all connected components in real time.
“We’re using MII and an operational service bus that recognize process order XML files from SAP and send them into a data store for processing and placement into the PCS7 batch engine,” said Morrison. “Functions are delivered from SAP using SAP control recipes. The batch engine then runs the batch and captures events and data. This information is then sent back up to SAP using Siemens’ Simatic Batch API.”
He noted that the teams initially struggled with “pulling in all the events and data from the control system.” The struggle mainly involved determining if they should use OPC, the Batch API, or Siemens Simatic Process Historian to handle the task. The team finally decided to use the Process Historian because there was “no additional impact on the running systems,” said Morrison.
Once these issues were settled, Morrison maintains that the process was, overall, straightforward and not very complex. However, he did add that getting the business LAN to play nice with process control LAN across firewalls proved to be a little tricky, but not insurmountable.
Looking back, Morrison said the key lesson learned in creating this bi-directional, automated communication connection between the enterprise and shop floor is to “get the team on same page early and use standards to help achieve this.” He also says it’s important to define and constantly remind team members about the project scope. “This is especially important when you get SAP and process controls people in same room” because everyone gets excited with the possibilities of what could be done. That’s why it’s important to “manage expectations early with separate SAP and process control reviews and alignments.”
Leaders relevant to this article: