The vision thing
It’s easy to over engineer an automation project, but just keep it simple
By Michael Carey
It just seems so simple and basic, but defining and communicating an automation vision is essential for having a unified automation strategy during the system’s design, development, and maintenance phases.
The automation vision can be just a brief document that identifies the extent of automation when the system is operating in automatic and manual modes and the level of interlocking required across both modes. The automation vision is critical during the design and development phase because it guides designers in their automation strategy development and helps them to make consistent decisions on the large amount of automation choices during the project. The automation vision is even more critical during the maintenance phase because as the system expands, new project teams need to maintain consistency between the old and new to ensure users have a unified experience.
Keep it simple
When defining the automation vision, one of the goals is to reduce complexity. The system should be as simple as possible while ensuring safety to personnel, product, and equipment. The business object for any automation system is to provide cost effective manufacturing while controlling quality. Designing systems with excessive complexity never meets the business objective; rather it opposes the business objective by increasing maintenance costs and possibly increasing down time because operators may not have the ability to manually bring the system back into specification when problems arise. Over designing the system is something that needs to be continuously monitored because it is too easy to slowly make the system more complex than it has to be. Creating and using an automation vision is a tool to help prevent over-complexity from creeping in.
The vision plan should have a definition for continuous and batch processes. The automation vision is normally more complex on batch processes because batch processes can be run in automatic or manual modes; whereas in continuous processes, you may have an automatic or manual startup, but once started the system is fully automatic. A batch process better illustrates the need for an automation vision because in a batch process the batch operation can execute automatically through a batch manager, manually by having operators manually command devices and actuate valves, or semi-automatic by running phases outside the batch manager. In an ISA88 designed batch process, the equipment can be in just control modules or grouped together in equipment modules. The control module modes are easy to handle, but cascading mode control through the control modules within the equipment modules is more complex and needs proper evaluation. Another critical component for the automation vision is the system’s usability via the human computer interface (HCI). The HCI is a combination of the human machine interface (HMI) and how the operators should use the system, both via the HMI screens and interaction with the control and equipment modules. One area that will need evaluation is the possible complexity of the HCI. Finally, the automation vision must include the interlocking strategy. The number of interlocks and possible cascading effects need proper identification.
The underlying drive for defining the automation vision is to define how the operators interact with the system. The organization’s evaluation of their operators’ competency is the prime factor for defining an automation vision that either gives the operators control over the system or protects the system from the operators by prohibiting operator interaction. A good automation vision needs to take a strong stance on one of these sides. An automation system somewhere in between the two will be burdensome for the owner because in effect there is not a single vision. Once the owner clearly defines the role of the operator, the automation vision can focus on system mode operation, equipment module control, HCI, and interlocking.
The system mode operation (automatic, semi-automatic, or manual) greatly depends on the operators’ competency. Organizations that have competent operators need to allow them to have full control over the system and should permit semi-automatic and flexible manual mode operation, trusting the operators will maintain proper operational conditions. Organizations that question their operators’ competency need to prohibit semi-automatic operation and greatly inhibit manual mode operation. One factor normally overlooked when defining the automation vision is the business restrictions. For example in a FDA regulated industry, most companies by law cannot manufacture in a manual mode because their licensing requires adherence to the approved procedures normally based upon the system running in automatic mode. In this case, even if you believe you should prohibit operator control, adding extra complexity to limit operation in manual mode is futile because the plant cannot produce in manual mode. The only reason why the system would be in manual mode is if there is an operator intervention to try and return the system to specification, and in this case the operators need all the flexibility available.
Equipment module control is very challenging when the equipment modules need to account for mode propagation among the contained control modules and the ability to manually override specific control modules within the equipment module. An example equipment module is a loop control module (indicator and control valve) and a block valve control module where the block valve automatically actuates based upon the loop’s output. When adverse operating conditions occur and the block valve needs actuation separately from the loop, how will the automation vision allow this operation to occur, and if so, how complex is the operation? An automation vision that prohibits operator manipulation would not allow anyone to override the block valve, while an automation vision that supports operator control would allow him to override the block valve. The complexity on how anyone can override the block valve would come from the HCI automation vision.
The design off automation systems, like any computerized system, should be for user operability. The HCI, which is a combination of the HMI and its interaction with the control and equipment modules, must undergo an adequate definition process in the automation vision. Automation visions that prohibit operator control have a simple HCI because the operator really does not need to interact with the system too much since they cannot do much with it. An automation vision that supports operator control will have a more complex HCI because the operator needs to interact with more of the system.
When designing the HCI to support operator control, the design can contain more specific faceplates, graphics, and control modules, reducing operator complexity while increasing code complexity—or the design can contain more general faceplates, graphics, and control modules, increasing operator complexity while decreasing code complexity. The automation vision definition should guide the designers to which solution to use. An extremely important point with the HCI design is an HCI design that prohibits operator control must also allow for supervisors or engineers to take control of the system in adverse operational conditions. Having HCI components designed to prohibit operators but allow flexibility for supervisors and operator will increase the amount of code.
Interlocking, like politics and religion, is a very personal subject where every engineer has their own strong feelings. Some engineers believe they should use interlocks only in critical situations, while others use interlocking as a method for controlling equipment under normal operational conditions. Some engineers believe interlocks should only interlock a single power source, while others use interlocks across multiple power sources. Some engineers believe the interlocking strategy should not rely on cascading interlocks; others believe cascading interlocks are acceptable. A discussion about effective interlocking strategies can go into great depth, but as far as an automation vision goes, the interlocking strategy must be as simple as possible to achieve the business objectives.
The automation vision will then affect interlock complexity. Systems that allow operators more control will have simple interlocking strategies, while systems that prohibit operator control will have more complex interlocking strategies.
An automation vision that supports operator control would have the following interlocking strategy: Interlock only in critical situations, interlock only a single power source, and do not cascade interlocks. Automatic mode control can provide similar functionality to interlocks under different operational conditions. For example, a tank agitator should only turn on when the tank level is higher than the blades, but when the tank is cleaned-in-place the agitator must be on even though the tank level is below the blades. The user can solve this by using an automatic mode solution that controls on level in auto mode and does not control on level in manual mode or an interlock solution that interlocks the motor when not in CIP mode. Both solutions are valid but the first one supports operator control while the second one prohibits operator control. A user should refer to the automation vision when making the decision on which solution to use.
Projects that do not take the time to define and communicate an automation vision fumble continuously over questions on the level of automation to provide. Because the designers do not have an agreed upon scope to base their decisions on, the level of automation can be inconsistent across different designers and across different functions. Defining and communicating the automation vision on system mode operation, equipment module control, HCI, and interlocking is time well spent and can reduce development time while increasing the system’s usability.
ABOUT THE AUTHOR
Michael Carey is director of MES and Information Systems at Panacea Technologies Inc., an automation systems consulting firm. His e-mail is firstname.lastname@example.org.
Return to Previous Page