Menu

Four guidelines for successful skid integration of batching operations

Successful skid integration for batch manufacturing operations can be challenging. Following best practices such as standardized communications and defining status feedback can make the process a much smoother one.

Robbie Peoples, Cross Company
08/03/2018
Four guidelines for successful skid integration for batching operations

Image courtesy: Bob Vavra, CFE MediaNew processes, or the expansion of existing processes, typically include original equipment manufacturer (OEM) skids. Skid mounted equipment can provide a faster implementation time versus conventional process system building from scratch.

Skid equipment can provide fast deployment with a high-quality cost-effective solution for both utility and main processing functions. The integration of skid equipment can be simplified if there is minimal interaction with the overall processing system. In this case, only data collection or minimal interaction are required to work with the main distributed control system (DCS) or supervisory control and data acquisition (SCADA) system. However, seamless integration of the skid equipment into an overall process can be challenging. Tight integration of skid equipment into processing activities such as batching operations requires a much deeper level of cohesive interaction to achieve a high level of process efficiency.

The challenges of skid integration for batching operations

The primary challenge of integrating a 3rd party system into a process is that both upstream and downstream operations must be coordinated and share a cohesive operating philosophy. Typically, utility system equipment skids simply provide the desired functions at a designed capacity, on demand. On the other hand, OEM skid equipment that is chained together or act as a puzzle piece in a much larger process requires additional coordination of the upstream and downstream units to achieve efficient equipment utilization.

Most skid equipment comes complete with its own dedicated processor, I/O, and are generally designed to operate independently. Meaning, they operate without anticipation of upstream feeds or downstream demands. Often, the operation of the overall process is forced to work-around the OEM functional characteristics. In many circumstances, the operating attributes of the OEM skids are a direct result of the system programming and not a limitation of the equipment capabilities. Meaning, OEM skid equipment is not built to act as a true slave or servant to the overall process coordinator or master controller.

The independent operating philosophy of OEM skids is generally a result of commodity selling of the canned packages. Changes to an existing operating function represent a risk to the supplier and they are generally reluctant to augment system functions upon request. Integration of skid packages into a true batching system is inherently difficult because most skid packages are not programmed using an ISA S88.01 standards.

Most skid programs are comprised of ladder logic that was originally built to provide multiple processing options. This allows a single system software application to cover a multitude of processing options. Ladder logic can be designed to follow programming standards but it does require some additional effort to do so. Not utilizing industry standard programming practices, over-complicating the application with multiple processing functions that are not being used, and a risk-averse supplier can make it very difficult to seamlessly integrate the system into an overall batching solution.

Four guidelines for successful skid integration for batching operations

The integrating of OEM skid equipment into an overall batch management system requires a clearly defined level of coordination between the slave and master (DCS or SCADA) systems. Simple commands to the slave system do not provide the operator with a visual representation of the system. If everything works perfectly, a simple master command to the slave system will suffice. But when an exception condition happens, it will be very difficult to detect and/or troubleshoot without having to go out to the equipment's local human-machine interface (HMI) to determine the issue.

This creates delays in operation, increasing the batch cycle time, reduction in equipment utilization, and reducing the overall operating efficiency. The solution to tightly integrate a slave OEM system into an overall master processing system can be achieved by following four simple guidelines:

The solution is to synchronize two different pieces of equipment by defining an agreed upon method of interactions. A flexible batch solution includes a respective isolation between different functions, which standardizes how they interface with other functions. This type of definition allows for the equipment entities to operate independently and promotes the reuse of a base code of functions. The reuse of code reduces overall engineering time as well as minimizing the possibilities of human error.

1. Allocate the operating modes

Operating modes of remote equipment can be tricky if boundaries are not clearly defined. Can an operator make changes to the equipment locally if the control variables have been commanded remotely from an overall recipe? Should the recipe go to a "hold" state when a specific operating status changes? These are just a few questions that should be considered when integrating remote equipment. The interface rules and operating philosophy between the master and slave system should be clearly defined to provide a continuous and uniform interface between the two systems.

2. Follow the standard operating states

Standardizing operating states allows for a mechanism to handle the difficult part of a batch, which is the exception condition. An exception condition can be defined as an event that occurs outside of the normal or desired behavior of the process. Handling, processing, and recovering from these types of conditions is a critical element of batch production. Not only is exception handling important for process safety, but it is essential for product quality and critical to achieving a high level of operating efficiency. Programming exceptions can represent up to 70% of the programming effort and must be considered a goal in the batch design process.

3. Define status feedback

Status feedback is an essential part of efficient operations between two different systems. This information should be structured and defined for modes, operating states, and error conditions as well. The representation of the standard modes and states should be common across all equipment but the error conditions should be specific to each piece of equipment. Specific error feedback from a slave or remote system can provide operations a visual indication of the current condition. Error states can also be used to detect preventative actions to increase equipment utilization and boost the overall operating efficiency of the system.

4. Standardize communications

Communications between systems can be achieved in a very efficient manner by utilizing single integer value designations. The communications can be very simplistic, using a single word for commands to the slave system and providing a status word coming from the slave system. The general command status can be common to follow the operating mode and states. However, additional parameters or system variables may need to be written down to the slave programmable logic controller (PLC) as a result of an overall recipe setting in the main system. Standardizing on the communication types for remote or 3rd party equipment make the control system more easily maintained and expanded over the life-cycle. Development of the communication standards for remote interfaces must be designed broad enough to fit application types, but specific enough have value.

The solution

The integration of slave or remote systems can be challenging, but standardized interfaces make the process more easily managed. Two out of the four guidelines identified above are clearly defined within the ISA S88.01 standards. The status feedback and packaging of the communication data between the systems can be defined to cover all 3rd party solutions. A common interface design promotes a consistent coordinated effort across the system that allows for easy maintenance and expansion.

The common interface solutions should be documented in a design deliverable provided as a User Requirement Specification (URS) to OEM vendors to meet the standards. This will ensure the remote system programming complies with the expected operations. Standardizing the interactions to include exception conditions shall provide a system that is more easily operated and maintained to achieve a high level of operating efficiency.

Robbie Peoples, integration manager, Cross Company. This article originally appeared on Cross Company online. Cross Company is a CFE Media content partner. Edited by Emily Guenther, associate content manager, Control Engineering, CFE Media, eguenther(at)cfemedia.com.

Channels

Products

Visit Our Sites

Contact Us

Settings

Close Home
click me