EDDL Supports Automatic OPC Server Configuration

by Jim Cahill

Emerson's Jonas Berge is an active member in the ISA SP104 committee, responsible for advancing the Electronic Device Description Language (EDDL) standard (also known as IEC 61804-3.) You may recall Jonas from earlier EDDL posts. This standard creates interoperability between digital field devices from simple sensors to complex devices (drives, analyzers, etc.) with control and asset management systems. Interoperable communications include device diagnostics, asset management and user interface displays.

Jonas has written a short piece, OPC Made Easy, in the April issue of Control Engineering Asia magazine. In this article, he describes how EDDL can save many hours of OPC server configuration, which can help speed up a project's completion. For background, he begins by reminding readers how this important standard makes sharing data between OPC servers and OPC clients easy:

…external software in HMI clients and other users can easily access the wealth of detailed diagnostics and information in hundreds or thousands of intelligent devices around the plant.

Configuring OPC clients is easy: just point and click on data in the OPC server.

The challenge is in the configuration of the OPC server:

Configuring the OPC server includes entering device addresses and communication settings as well as creating the "namespace" which entails entering tag or descriptor for each and every piece of information along with the memory register address for the parameter as well as its data type, and range where applicable. This parameter "mapping" is the most time consuming and error prone part of OPC integration, but once done the rest is easy.

Jonas explains how EDDL can automate the creation of the OPC server configuration for devices digitally communicating via HART, Foundation fieldbus and Profibus. He writes:

Automatic OPC server configuration is made possible because EDDL is a descriptive technology similar to XML or HTML, declaring the properties of the data in the device for use by the auto-configuration mechanism. EDDL is the only device integration solution that is declarative.

Although not in the article, Jonas relayed an example to me where an AMS OPC Server was used to pass a slug flow alert from a Micro Motion HART device to an older distributed control system (DCS) that did not support HART communications pass-through. Before the solution was implemented to send this alert to the DCS via OPC, slug flow would cause over-charging of materials added to a batch. Now, the operators are alerted to slug flow conditions and can pay special attention to the surrounding process equipment.

The EDDL.org website remains the best source for information about this standard. You can also join the EDDL email list hosted by ISA to keep up and participate in the conversation around this standard.

Technorati Tags: | | | | | | | | |

May 6, 2008 in Alarm Management, in Interoperability, in Measurement | Comments (0)

Successful Alarm Management Strategies Begin with Early Planning

by Jim Cahill

My RSS feeds pointed me to a great ChemicalProcessing.com article on batch manufacturing alarms. The article, Rethink batch-manufacturing alarm systems, was written by Joseph Alford.

He opens with provocative questions:

Do operators sing the praises of your plant's alarm system? No? Well, do they at least agree that generated alarms represent real abnormal situations requiring a response and that the automation/control system presents alarms in a timely, accurate and reliable way? No again? Well why not? Aren't operators the primary customers of your alarm system? Perhaps it's time for an alarm remediation project.

Many with continuous processes would agree that their alarm strategies implemented inside their automation systems need work. The complexity is amplified in batch processes because unique operating conditions are created within all of the numerous steps along the way.

The article boils down the crucial steps to take:

The key considerations in achieving effective alarm systems include defining objectives early in a project's life (i.e., in a plant's alarm philosophy or a system's functional requirements), adhering to the definition of an alarm, and implementing alarm-management best practices.

I ran this article by Todd Ham, a senior principal engineer in Emerson's Life Sciences industry organization. You may recall Todd from earlier posts.

Todd agrees completely that a successful alarm strategy begins in the functional requirements stage of a project. The project teams work with pharmaceutical and biotechnology manufacturers early on in a project to document their alarm requirements.

Todd stressed that a good strategy examines not only what conditions require an alarm—typically an adverse effect to personnel, product, or equipment—but also what is the desired response. Is alarm annunciation sufficient? Does this require a device interlock? Should this put the batch in hold? Does quality assurance (QA) need to be notified? This is called exception handling.

In a batch process, the requirements may differ based on the process step. For example, the alarm may be critical during processing, but not important during cleaning. Further, the alarm may only need to be monitored once the process is at steady state. In these scenarios, the control strategy developed by the project team will selectively enable/disable alarms at the appropriate point in the sequence.

Todd cautions that this is not a "one size fits all" exercise. The project team and manufacturer's staff must step through each process unit/system and ask a series of questions to arrive at a solution where alarms are both appropriate for a particular operating state and relevant for alerting operators to abnormal situations.

Todd agrees with the author that this work must be done up front, or the alarm flood, nuisance alarm scenario described in the article will be the result. You can't wait until the end of the project to think about alarm management. When you come right down to it, it's just as important as defining the control requirements for the project.

Technorati Tags: | | | | |

February 29, 2008 in Abnormal Situation Prevention, in Alarm Management, in Project Services | Comments (0)

Avoiding Abnormal Situations with Better Alarm Management

by Jim Cahill

Earlier this month my DeltaV News RSS feed announced the availability of an alarm management whitepaper written by the ARC Advisory Group. The paper, Emerson Strategies for Abnormal Situation Avoidance & Alarm Management, describes an issue many process manufacturers face in dealing with too many alarms. This makes it hard for their operators to distinguish between critical impending abnormal events and nuisance alarms.

The Emerson approach to address better management of alarms is based upon ARC's Six-Sigma DMAIC (Define, Measure, Analyze, Improve, Control) model and

…includes data collection, statistical analysis, alarm evaluation, and system improvement – all within the context of ongoing evaluation and continuous improvement.

Relative to alarm management, the whitepaper describes the DMAIC process:

Define relates to philosophy development, Measure relates to determining alarm behavior and alarm effectiveness, Analyze relates to root cause analysis and performance benchmarking, and Improve relates to the remedial action necessary to align the prevailing implementation with the alarm philosophy. Finally, Control relates to alarm execution.

Advancing technology is a source of the alarm proliferation. The authors note:

In the days of hardwired controls and alarms, engineers were very stingy with alarms, in part because each alarm point had a cost. The primary issue with alarm systems is there is too much information for an operator to assimilate and act on. Ten years ago, it cost about one thousand dollars to add an alarm. Current automation systems have essentially eliminated the cost of adding more alarms and, therefore, the incentive to limit or rationalize their number.

I have an upcoming post that discusses the importance of up-front planning your alarm strategy when you're planning your project's functional requirements. But what do you do in an existing facility with an alarm overabundance?

The whitepaper addresses building a business case to justify and alarm management project. The keys areas build the business case include safety, unplanned downtime, better information management and reduced troubleshooting time, and changing the role of the operator toward higher-value activities.

ARC notes that unplanned shutdown costs process manufacturers on aggregate between 2 percent and 5 percent annually. This may be a justification opportunity by looking at root causes of unplanned shutdowns in your plant. A review of the alarm and event logs around these incidents can reveal the number alarms the operators saw and the actions they took as a result.

The whitepaper also addresses the important role of the EEMUA Publication 191—Management of Process Alarms in developing your alarm management strategy. A guiding principle described in EEMUA 191:

…a usable alarm system must be relevant to the user's role at the time, indicate clearly what response is required, and be presented at a rate the user can deal with, and be easy to understand.

With this backdrop, the paper explores the applications within Emerson's DeltaV system like the Event Chronicle, integration with 3rd-party alarm management applications via the OPC alarms and events communication standard, and the DeltaV Analyze alarm analysis program. Coupling these applications with alarm management services can help process manufacturers through the process of data collection, statistical analysis, alarm evaluation, and system improvement.

And much like the safety lifecycle as defined by the IEC 61511 international safety standard, ongoing evaluation of the overall alarm strategy is important throughout the lifecycle of the plant.

Technorati Tags: | | | | | | |

February 27, 2008 in Alarm Management, in Operator Performance | Comments (0)