Alarm Management Challenge 3: Multiple Points of Configuration
Many alarm systems in use today require an additional alarm server or require tags to be configured multiple times, adding to inefficiencies in engineering and hindering the process of creating a proper alarm management system.
zenon’s alarm management solution 3: tags defined one time, object-oriented engineering
With zenon, variables are only defined once. For example, if a pressure transmitter is being read from an Allen Bradley ControlLogix PLC, this is just one variable in zenon. This one pressure transmitter variable can be displayed on HMI screens, recorded in the Historian, plotted in the Extended Trend diagram, or used to generate an alarm. Therefore, if the alarm condition must be modified for the pressure transmitter it must only be done once, in a single location.
To take object-oriented engineering a step further, zenon supports the creation of custom and structured datatypes. All zenon variables are based upon a driver (e.g. Siemens S7), a driver object type (e.g. Ext. Datablock), and a datatype (e.g. Real). There are multiple benefits in creating and using custom datatypes in zenon. For example, it is possible to create a custom datatype for the pressure transmitter. This can be set as a Real datatype and will inherit the properties of the default Real type in zenon. The new pressure transmitter can then be customized even further by adding the measuring units of psi, showing three decimal places, and defining a series of four limits on the datatype.
As you can see in the figure above, the creation of this custom datatype for the pressure transmitter will take an engineer approximately five minutes to configure and check. The savings and benefits come in at the next step, since the engineer must display 150 pressure transmitters in the SCADA system, each with the above configuration and limits configured. This process in zenon will only take the engineer one minute since he is able to create an array of 150 elements for the pressure transmitters which will automatically inherit the properties set on the pressure transmitter datatype set in the figure. Of course, individual instances can still be customized and “unlinked” with the datatype.
Not only is this a huge time saver, it also guarantees that every individual pressure transmitter is configured accurately. If, after two weeks of operation, the operations manager wants the Low-Low limit for the pressure transmitter changed to only alarm at < 56 psi, the engineer only needs to make this change at the pressure transmitter datatype, and all 150 pressure transmitters will be updated automatically with the new Low-Low limit of < 56 psi. After the configuration is changed, the zenon Editor downloads the updated files to the Runtime server via zenon Remote Transport over the network, then the engineer remotely reloads the project with a mouse click. The changes are live and deployed throughout the zenon network to all connected servers, clients, and web clients in just a few moments, all happening without any downtime, operational inconvenience, or concern.
See “Alarm Management Challenge 2: Managing a Diverse Infrastructure” here.