"Much of the equipment in seed processing facilities is driven by variable-frequency drives (VFDs)," says Arlin Friesen, One-Step's automation specialist. "Clients want to adjust motor speeds based on the quality of product they see coming off the processing equipment, and they want to monitor product quality with live camera feeds."
Consequently, Friesen used Opto 22's groov platform and its web browser without plug-ins to build One-Step's own operator interface that can be used on PCs, tablet PCs and smart phones. "This allows our users to control VFD speeds using groov's adjustable buttons or sliders, while the interface also displays live product flows via IP cameras on their equipment," adds Friesen.
While groov doesn't have direct alarm capabilities yet, users can add whatever alerts or alarms they want when building their interfaces. Also, groov and its optimized displays (Figure 1) are based on HMI best practices for building screens with prioritized data, minimal graphics and muted colors.
On the HMI hardware side, Red Lion Controls reports its new Graphite operator interface panels include cast-aluminum construction and full-color touchscreens, and combine a range of plug-in modules with protocol conversion, data logging and web-based monitoring and control. The plug-ins reduce development and commissioning time compared to traditional systems, which typically use an HMI paired with separate I/O, PLCs and other controllers, and require more programming and configuration (Figure 2).
Management and More Documentation
Back at Greenwood Energy Center, Dobel explains that management buy-in and commitment were crucial to GWEC's alarm rationalization project, not just for funding and resources, but to give the team the authority to make rationalization decisions and require operators stick to them--even though there are some exceptions. "For example, if your facility had a historical event, has to meet an EPA requirement or must carry out a particular management requirement, then these just have to be done," adds Dobel.
In all, Dobel, Dage and their colleagues spent about eight hours a day for three months hashing out alarms. "That was too much, so we'd recommend a schedule of doing rationalization in the morning and then gathering information in the afternoon," says Dobel. "So far, we're done with rationalizing alarms for 80% to 85% of our I/O components, and we're also still working on the logic for our smart alarms and maintaining the existing alarm system. And we're still meeting once a week to do more rationalization. In fact, on his own, John triaged that last 20% of our alarms and made them Priority 4, so operators can assign priority levels later.
"Alarm rationalization includes many different devices, but the basic questions for each are always the same: 'Do the operators need to know about this alarm?' and 'What are the consequences?' adds Dage.
Dobel adds, "After documenting your alarm rationalizations, it's also important to be consistent with the rationalization rules you come up with, and as you build those rules, you need to document them too. And get started doing alarm rationalization now. Don't wait for an incident or accident."
Besides continuing its rationalization efforts, GWEC and the team are doing more continuous improvement, and have set up another whiteboard to aid communications between operators, IT and other players on items to work on. For example, it lists the Top 20 alarms each week and addresses the bad actors behind them, which has already reduced the number and severity of these alarms.