Emerson Exchange 365

SIS is limited in how many control modules they have so it was pretty much a requirement for the functionality and why alarm groups were created.

The PAS controllers don't have this number of control module limitation (other than Control Free Time and Free Memory), just split the items you want to alarm into different control modules as alarm groups will almost assuredly never be created for PAS configurations.

Taking a step back, the BPCS and SIS are two very different systems, which leads to different design approaches for their respective modules. The BPCS would typically follow the P&ID diagrams. The Alarm system is part of the BPCS system, providing a secondary layer of protection for when the Automatic controls of the BPCS are unable to keep the process within desired operational limits. The SIS provides the extra layers of protection to avoid incidents when the BPCS is unable to maintain safe operation. Add to that the extreme flexibility of modern DCS systems in how they allow the system to be configured. It is easy to lose sight of the alarm system requirements and how best to achieve its goals when "Alarms" can be created anywhere.

There are two things I think about with DeltaV. First, I want to design my control loops for an appropriate response time. That is, a PID loop would have it's input and output IO linked directly to the module. After all, that is the design intent of DeltaV. Second, I look to the P&ID to determine if I expected alarms. DeltaV handles alarms as a group by module, providing the ALARMS[] parameter to show the highest priority alarm for the module. So if the P&ID calls for Alarms on all transmitters, that drives us to have a module for each transmitter, monitor and/or Control.

When a control module requires two or more inputs, these two considerations sort of collide. If there were two AI's for a signal select to an PID loop, and the P&ID showed alarms on both, I would question that approach. The Process alarms should be on the selected PV so that there is one alarm requiring action. A Fault alarm on each input would be valid to help identify a maintenance activity. Some might create two AI modules each with the prescribed alarms to satisfy the P&ID design requirements. But this does two things, it adds IO latency into the loop execution, and it creates duplicate alarms, which is against the ISA 18.2 best practices.

The problem with placing alarms on AI modules that are then used in Control modules is that the direct alarm access features of DeltaV will take the operator to the AI tag when navigating through the alarm banner and alarm lists. Then the Operator must find the control module where he can take an action. This is another reason to make sure the process alarms are on the right module to facilitate the "recommended" action the operator would be expected to take. The P&ID's were not designed with the eventual DCS platform so where alarms are shown may not be the best location for implementation. This is probably the biggest reason to do an Alarm Assessment as part of the design so we avoid creating duplicate alarm scenarios and make sure the alarms are on the right module given the expected response by the Operator.

I would place the process alarms on the PV of the PID loop in the PID control module. If the module has two transmitters with a signal selection, the alarms would be on the PID/PV value, which ever transmitter is providing the working PV. I would not have duplicate alarms on each transmitter.

If the module had two different signals, say the primary PV value and a FeedForward, or a pressure compensation, I would expect the second AI to come from a monitoring module and as such the alarms for the process value would be in that module. This way, the closed loop execution remains in a single Module for minimum IO latency, and I have dedicated alarms for the different process values.

Some systems have adopted the approach of landing AI values in AI modules allowing the value to be consumed by other modules. There are two main reasons this happened (in my opinon). First, earlier DeltaV systems (pre v12) the AI signals was counted for each module that referenced it to determine the IO Licensing. Referencing the AI channel in an AI module and then directly again for closed loop PID module would count as two AI DST's. In v12, the IO Counting changed so that the AI signal is counted once if one or more modules use it. This actually would allow a user to have AI modules with separate Alarms and then use that AI directing in a PID module to avoid signal latency between the two modules in closed loop control. (I'm not recommending this but it is possible) The second reason was that with FF, transmitters and valves on different segments could not be referenced in the same module as there was no way to schedule block execution across two segments. Here, users landed FF AI's in their own AI module and could then reference the AI Process value in the PID module that had the AO block from the valve positioner. The PID block could then be in the controller or in the FF device. The expected design was to have the AI and AO devices on the same segment to allow control in the field with a very low IO latency, resulting from the block scheduling in the macro cycle.

With SIS, many SIS modules have multiple transmitters and even multiple SIF's Prior to alarm Groups, these AI signals were read by BPCS modules located in the local gateway controller to provide Alarms for each named transmitter. The question comes up as to whether having SIS process based alarms are actually needed. If the process has already deviated from normal and BPCS alarms of appropriate priority have already alerted the Operator, do they need additional process based alarms? SInce the SIS can be used for various applications, such as Fire and Gas detection, then yes, SIS alarms are valid. Alarm Groups replace the need for "shadow" modules in the BPCS. However, there must still be a proper hazard assessment and appropriate number of alarms that, by definition, are actionable and have consequence. Alarming two or more sensors that operate in a voting scheme might not be appropriate. Different sensors covering an area could indicate the level of dispersion for the gas leak and rather than having multiple sensors alarming individually, a multi sensor condition would drive a more appropriate alarm.

I can't possibly tell you what your system requires in the way of alarms, nor is that my intent. I just think that alarms need to be carefully thought through and applied to the module the Operator will need to act on in the case of controlled PV's. Each module has its Faceplate, Detail and Process graphics that are directly available to the operator in the Alarm Banner and Alarm lists. The alarm Response and consequence must be considered to arrive at the alarm priority, but also how the Operator will be enabled to act appropriately. Fewer better alarms is what I look for.

Andre Dicaire