We build and support a lot of one-off machines, so we deal with a variety of networked hardware and components. The components get smarter all the time, and often phone home with problems and events that are as much a nuisance as anything else. Device suppliers all seem to have different and often laborious steps to ﬁlter the nuisances, while not crippling the important device diagnostics. Are there standards or standards-based approaches to this?
− From December '13 Control Design
SEE ALSO: DuPont's Global Alarm Management Story
Make It Meaningful
While we'd usually agree "more is better" when it comes to operational data phoning home, the key phrase becomes "more meaningful is better."
In our experience developing material handling solutions with predictive maintenance alerts and sorting through constant data pushing back to the OEM, we've found it best to first understand exactly what all this data means and then how it translates to actionable requests of the user/maintenance staff. It is easy to lose the critical calls to action if you're drowning in "FYI" information.
Give the Problem to the Controller
Maintaining a current, accurate alarm and event status in an architecture can be challenging. Because a traditional alarming system stores the status and alarm state in the human-machine interface (HMI), keeping the view from operator-operator or database-database has been difficult. Rebooting an alarm server might require rebuilding the state of the alarm manually, but then you're left with the question of whether the alarm is acknowledged or if it's suppressed.
As part of the Services Platform, Alarms and Events provides components that allow FactoryTalk-enabled products to participate in a common, consistent view. It manages alarms and events throughout a FactoryTalk system.
You can eliminate the problems of traditional alarm and event systems, such as programming required in both the controller and the HMI software; alarms being detected and processed twice; heavy polling between the HMI and controller tags resulting in heavy network overhead; and alarm time stamps being delayed because they are applied by the HMI after polling and processing.
Our Alarms and Events creates a consistent user interface for visualization and management across the entire control system and significantly reduces network traffic due to alarm reporting by exception.
networks and security business,
Divide and Conquer
Machines do tend to want to tell you all about their day in great detail. Generally, there are a couple ways to address this situation.
From a high level, one way to limit this communication is to break your network up into different subnets. This means any multicast or broadcast messages sent by your industrial machines are contained within the local subnet, thus not "spamming" the rest of your industrial network with messages others don't care about. Just remember that once you use subnets or VLANs to achieve this segmentation, you will need a router somewhere on your network.
Another approach is to use a router/firewall with deep packet inspection (DPI). With this function enabled, an intelligent firewall device can filter out certain types of messages and allow or disallow accordingly. Coincidentally, this same router/firewall appliance can also filter out broadcast messages, thus limiting the amount of chatter on your network, as mentioned previously.
product marketing manager,
Industrial Ethernet Infrastructure
[Here are parts of the thread of responses we received when we posted the question on LinkedIn's Automation.com group.]
How About a Daily Summary?
To address this, my question would be: "Do we really need all of the warnings, faults and alarms that are programmed into the control system?" Could they not simply be tallied and examined at the start of the morning shift, for example?