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
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?
senior automation engineer
Use Secondary Logic
One approach that many of our customers implement is the idea of a secondary alarming system. Bring the device alarms into a second system where you can apply additional logic to determine which device alarms are important and require notification or operator action.
For example, a single device alarm might not be important, but the persistence of this alarm for five minutes or 10 occurrences of the device alarm within 30 minutes could be significant.
A secondary alarm system allows this type of logic to be customized while leaving the vendor alarms alone. The secondary "smart alarms" can then be the events that are acted upon or reported. As Kevin suggested, they also can be summarized and reported (e.g., daily report via email) in addition to notifications at the time of the events.
software product development,
Exele Information Systems
These Standards Will Help
ISA18.2 is a standard which uses the term "instrument diagnostic alarm." The NAMUR NE107 recommendation is the industry standard for categorization of instrument diagnostic alarms as common/uniform "status signals" for "failed," "off specification," "maintenance required," and "check function." This means device diagnostic alarms from all kinds of devices can be filtered and displayed consistently across all kinds of software. For instance, you can chose to only alarm operators in case the alarm is "failed," affecting the process, not for the less serious "off-specification" and "maintenance required" that do not impact the process yet and should only be routed to the maintenance system.
See the "Device Diagnostics Deployment and Adoption Guide." The ISA108 committee is also working on the work process for using the NAMUR NE107 capability.
Make sure to use devices and systems supporting NAMUR NE107. For example, http://bit.ly/1fdS9ao.
director, applied technology,
Emerson Process Management, Singapore
Demote the False Alarms
Read the 2009 ISA-18.2 standard on alarm management. Alarms are notifications that meet the definition of an alarm. An alarm is defined as "an audible and/or visible means of indicating to the operator an equipment malfunction, process deviation or abnormal condition requiring a response." The key required elements: "to the operator," "abnormal" and "requiring a response."
Many things that vendors call alarms do not meet the definition. The alarm system is reserved only for things that meet that definition. Everything else should be handled in some other way than use of the alarm system.
Most alarm systems are mixtures of important things that meet the definition and trivial things that do not. There is also a Linkedin group on alarm management.
If you want a white paper on understanding and applying ISA-18.2, just send me an email at firstname.lastname@example.org.
principal alarm management and HMI consultant,
As a system integrator with 23 years working on projects, for me there are two problems here that must be solved.
First, deal with the alarm avalanche. That means that with an alarm like 'Pump Stop,' there are many other alarms chained with that one; i.e., Network Failure, Motor Overtemperature, High Pressure, etc. The first step is to implement a logic that only accepts the first alarm and inhibits the chained ones. That minimizes the alarm quantity and makes it faster to identify and solve the problem.
Second, make alarms that must represent a sector or large or crítical equipment. If the person who receives the message wants to have more information, he can communícate with the plant or access a remote visualization from a cellphone, tablet or notebook.