Interoperability

We began this week with a post about the compatibility of the OPC Express Interface (Xi) standard with the existing OPC classic real-time, alarm & events, and historical data access servers to provide interoperability of process automation software and systems.

The OPC Foundation recently held a webinar highlighting this interoperability. Supplier participants included Advosol, Cogent Real-Time Systems, Emerson, Iconics, InduSoft, Kepware, MatrikonOPC, MobiForm Software, OSIsoft, Smar, Software Toolbox, Transpara.

The full OPC Xi Technology Demonstration hour-long webinar recording is available on the OPC Foundation website if you have an OPC Foundation account.

One of the demonstrations I'd like to highlight from this webinar is InduSoft's Web Studio software connected with Emerson's DeltaV system. I've embedded this 9:17 video from the InduSoft YouTube channel with permission from the InduSoft team.

The first two minutes gives some background on InduSoft and Web Studio and the following minute how the OPC Xi server is part of the DeltaV system. At 3:00, an architecture diagram show the information flow of real-time process, alarm, event, and historical data flow to OPC Xi clients, even through firewalls and across the internet.

This is possible as described in the post earlier this week since OPC Xi is built on top of the secure Windows Communication Foundation (WCF), part of the Microsoft .Net framework.

At 3:30, the demonstration shows how a connection is made from Web Studio across the internet to a DeltaV OPC Xi server. The content inside the OPC Xi server is fully browseable (shown at 5:40). At 7:15, the selected real-time temperature coming from a wireless temperature transmitter [actually located on top of the parking garage at the Emerson Austin facility] is configured and displayed on the Web Studio graphics screen.

This demonstration and all of the others from the webinar show how OPC Xi extends interoperability to address and connect through the complexities of today's highly secure networks. The result is to get the information into the hands of the right people, no matter where on the planet they happen to be.

I've heard that the other videos will soon be available on the OPC Foundation YouTube channel and will update this post when I see them out there.

Update: The videos are now available on the OPC Foundation YouTube channel. There are three: OPC MobiForm, MatrikonOPC, and this same InduSoft one.

Update and bump: I want to thank Randy Kondor for giving me permission to add the architecture pictures to the post below!

Reading through my RSS feeds this morning, I came across this post, OPC UA and Xi for users and developers, by OPC Foundation president Tom Burke. The post pointed to some recorded webinars for OPC UA [Unified Architecture] and OPC Express Interface (Xi).

I've described the advancement of the OPC Xi standard in several blog posts, so I had a keen interest in the OPC Xi webinar. There are three recorded webinars available:

• Webinar 1: Migration from Classic OPC to OPC Xi
• Webinar 2: Hands-On: Migration to OPC Xi with Converters
• Webinar 3: Migration to OPC Xi for Software Developers

You must register in order to view these tutorials. I took the plunge and registered so I could watch the first one. It is primarily geared for automation professionals instead of IT professionals. The total run time is 30 minutes, but it is the first 19 minutes that is valuable for plant engineers. The narrator, OPC Training Institute's Randy Kondor, very clearly explains what OPC Xi is, how it helps integrate plant communications, and how it interoperates with existing OPC classic communications such as OPC Data Access (DA), OPC Alarms & Events (A&E), and OPC Historical Data Access (HDA).

The video presentation describes two fundamental changes between OPC Xi and the OPC classic communications standards. The first is the change from using Microsoft's DCOM as the communications and security transport to Microsoft's Windows Communications Foundation (WCF), part of their family of the .NET Framework. What all this jargon means for automation engineers is that the communications is built on the authentication, authorization, encryption, and other security measures required for robust, secure communications. DCOM was never designed for the complexities of networks with firewalls, DMZs, and other methods of network security.

The other fundamental change was to borrow an OPC UA concept to add an information model specification layer on top of the DA, A&E, and HDA servers. This provides a way for logical objects, such as pumps or valves, based on some of the existing IEC, ISA, OAGi, and other information model standards.

At 12:35 in the webinar, Randy shows various architectures that connect classic OPC servers and clients with OPC Xi servers and clients. A converter or driver wraps a classic OPC server and provides its data to OPC Xi clients. Likewise, a classic OPC client has a converter to connect to OPC Xi servers. The architecture pictures really show the interoperability and backward compatibility between OPC classic and OPC Xi. I've asked if I can embed some of the pictures from the video and will update the post if I get the OK from Randy.

At 15:25, he shows how OPC Xi can consolidate separate OPC DA, OPC A&E, and OPC HDA servers into a single OPC Xi server. It can also consolidate OPC servers from different suppliers into one common OPC Xi server. Also the reverse is shown where multiple OPC Xi servers can be connected to one common classic OPC server, again to support full backward compatibility.

Just past the 19 minute mark the presentation shifts to OPC Xi Developer Toolkits and may be of interest to your IT community. At 24:45, the video highlights the growing list of suppliers who are involved with an OPC Xi interoperability demonstration.

A section on the OPC Foundation website has more on the OPC Express Interface (Xi) communications standard.

MP3 | iTunes

In my email this morning was the monthly Electronic Device Description Language (EDDL) digest. It's one of many ISA email discussion lists. Emerson's Jonas Berge is the driving force behind the EDDL educational information that comes out in this email list and on the EDDL.org website.

One of the items in the email was a mention of an updated section to the EDDL website, Intelligent Device Management. I took a closer look at one of the sections in this category, Calibration Trim. Here are a few points I gleaned from the page and one of the linked whitepapers, Intelligent Device Management: Calibration.

Process manufacturing facilities have hundreds to thousands of field devices including measurement instrumentation, analyzers, and final control elements such as valve positioners. It's quite a bit of work to setup & configure, calibrate, and perform ongoing troubleshooting and maintenance tasks on all of these devices.

Technology has helped as these field devices have incorporated microprocessors and digital communications protocols such as HART, Foundation fieldbus, and Profibus to connect these devices with asset management and process automation systems. These technologies have made centralized management of all these devices possible.

International standard EDDL (IEC 61804-3) provides a common language for device graphics and procedural wizards to provide a common user experience into these devices from software such as the AMS Device Manager and handheld devices such as the 475 Field Communicator across these various digital communication protocols.

I was casually familiar with device calibration trim, but the whitepaper helped to describe its components: sensor trim, range setting, and current trim. Sensor trim addresses drift which may occur in the transmitter's sensing device--although modern transmitters are extremely stable over time. An accurate physical input (pressure, level, temperature, etc.) is applied to the sensor. From a handheld device or software screen, the zero, lower, and upper sensor trims can be set.

For HART devices that have a hybrid analog and digital signal, the range setting translates into the analog 4-20mA current range. For instance, a pressure transmitter that is ranged from 0-1000psig has the 4mA output when the sensor measures 0psig and 20mA when the sensor measures 1000psig. The span of the transmitter is 1000psig. For purely digital protocols such as Foundation fieldbus and Profibus, the range is set in the controller. The whitepaper mentions differential pressure (DP) flow and level as an exception.

Current trim is limited to HART devices with their 4-20mA current signals. Current trim adjustments can be performed in the very rare case where the output current circuitry within a transmitter drifts.

EDDL wizards simplify the calibration trim process. Calibration tasks are guided by wizards to perform: sensor zero trim, sensor lower trim, sensor upper trim, lower range value set, upper range value set. For HART devices, 4mA current trim and 20mA current trim wizards assist in the calibration process. The wizards reduce opportunities for technician error and help enforce consistency.

The EDDL standard also supports instructional and procedural documentation, historical device audit trails, and scheduled maintenance tasks. Given the hundreds to thousands of field devices within a typical plant, this common approach from EDDL helps to simplify the process from setup and calibration through lifecycle maintenance.

MP3 | iTunes

Emerson Process Management's chief strategic officer, Peter Zornio, shared his thoughts on how IEC 62591 WirelessHART and ISA100.11a could converge in a recent Control Engineering article, News and comment: Can WirelessHART and ISA100 converge?

The HART Communications Foundation (HCF) noted in a recent IEC 62591 approval press release:

The overwhelming approval by IEC fulfills the request of users for a single international wireless communication standard that is supported by major automation suppliers.

Peter described a path how this convergence can occur:

Emerson believes it is important and possible to both address end users demands for a single wireless standard for process automation and also preserve their significant investments in IEC 62591, WirelessHART products. In addition, Emerson would like to complete ISA100.11a by adding the key element that will make it interoperable. We believe that the best way to achieve convergence between WirelessHART and ISA100.11a is to create a Process Automation Application Profile for ISA100.11a that incorporates the international standard IEC 62591, WirelessHART, as the Application Profile for process automation.

He noted that WirelessHART devices have over 100 million hours of cumulative run time and that there are more than 26 million installed HART devices, which can be connected wirelessly with products such as the Smart Wireless THUM adapter.

Peter adds that the ISA100.11a standard as it exists today:

...is designed for but does not yet have any Application Profiles defined. In order to be interoperable among a wide variety of suppliers, ISA100.11a needs Application Profiles. Without an Application Profile, ISA100.11a is just a means to wirelessly transmit a message of digital data. There is nothing in the specification to specify how the collection of digital data can be interpreted. Adding a Process Automation Application Profile that is based on IEC 62591, WirelessHART ensures end users have a choice of an open and interoperable application layer supported by the 200+ member companies of HCF.

Peter closed by expressing Emerson's commitment to work with ISA100 to address convergence between the respective standards.

MP3 | iTunes

Emerson's Adam Lund has a great article, Human Centered Design Supports Improved Job Performance, in the February edition of Maintenance Technology magazine. Adam highlights some reasons why human centered design is growing in importance for process automation suppliers.

The rapid advancement of technology is breathtaking. Those like me with an affinity for gadgets follow the latest developments in Engadget and Gizmodo. While very cool and fun, Adam points to rapid technology advancement's downside for process automation professionals:

Years of professional analysis of industry work practices show that personnel are often overwhelmed with multiple systems and user interfaces, making it difficult to find critical information, especially while on a job in the field.

Technology's increasing capabilities and associated complexities are further heightened by the:

...demographic challenge as knowledgeable maintenance veterans retire and their places are taken by less experienced personnel.

Adam describes the human centered design (HCD) concept as being:

...aimed at identifying the information most needed by plant personnel and getting it to them in an easy-to-use format. This requires understanding the tasks frequently performed by end-users and presenting helpful information in a consistent fashion.

He describes the process in improving usability in the AMS Device Manager software and Emerson smart devices with familiar brand names such as Fisher, Rosemount, Micro Motion, CSI, DeltaV, Ovation, etc. Device dashboards in the AMS Device Manager were redesigned to:

...give workers an instant view of the critical items they need to evaluate, diagnose, and configure each device. Expert guidance is also provided to streamline the most important and frequently performed tasks by plant operations, engineering and maintenance personnel.

With the most common task performed by maintenance technicians identified, the software screens were reorganized into 3 primary areas: Overview, Configure, and Service Tools. This reorganization provides a quick glance when devices are working properly or not--and when not--highlights a path to quickly diagnose and troubleshoot the problem.

Much HCD work was performed on the smart device side to provide the same appearance to information coming from devices with different digital communications protocols including HART, WirelessHART, Foundation fieldbus, and Profibus. The device description (DD) varied widely among suppliers and different products within a single supplier. Emerson's Jonas Berge noted in an email to me that the IEC 61804-3 EDDL standard reduced this variation since the standard incorporates standard graphics. You can learn more about EDDL at the EDDL.org website and its email list.

Creating this common look and organization by task helps reduce complexity for maintenance technicians and allow them to:

...use the same procedures to manage devices regardless of communication protocol.

Beyond the Emerson brands mentioned in the article and this post, Jonas also noted the most automation suppliers support the IEC 61804-3 EDDL standard on the smart device side and the asset management and/or process automation system side.

The article describes how Emerson partner with Carnegie Mellon University to set a forward path in HCD. This work was the precursor to Emerson's creation of a Human Centered Design Institute. Adam describes it:

Emerson's new Human Centered Design Institute was established after more than five years of work-practice analysis, new product development re-engineering and organizational training. The Institute's goal is to bring about a significant improvement in ease-of-use and workforce productivity products that are reliable, compatible and cost-effective. User work practices and improved task completion (usability or workforce productivity) are at the heart of every new Emerson product.

The path going forward for all the technology developments across Emerson Process Management is to apply human center design concepts to reduce complexity and provide rapid discovery to its productivity-enhancing capabilities.

MP3 | iTunes

It's been a while since I've shared an update from Emerson's Lee Neitzel on the OPC Xi standard. If you're not familiar with this new addition to the OPC Foundation's family of communications standards, here are three prior posts that give an overview of this Microsoft .Net-based standard:

• Secure, Firewall Friendly Communications
• OPC Xi Builds on Process Manufacturing Communication Standards
• OPC Express Interface (OPC Xi) Technical Overview Slidecast

The OPC Foundation website describes OPC Xi as:

...the result of collaboration among several OPC vendor companies from the process industry to develop an easily integrated and secure solution for a variety of plant communications. OPC Xi's primary objective was to provide a .NET-based migration path from OPC Classic. Additionally, OPC Xi may be used as a standard .NET WCF [Window Communication Foundation] interface for newly developed OPC servers.

A lot has changed over the 14 years the OPC standards have been helping process manufacturers connect applications together in a standards-based way. Cyber-security has grown in importance, as have the network technologies such as firewalls. OPC Xi updates the original Microsoft COM technologies to .Net to take advantage of the security, authentication, and other security/performance improvements.

The latest news from the OPC Foundation is that Lee and fellow OPC Xi developers are starting the Xi Implementation and Demo project. This project is open to all OPC Members, that will be conducted using weekly teleconferences to review the Xi Reference Implementation code for clients and servers to show developers how to adapt the wrapper code to their servers, and how to use the client code to quickly integrate Xi into client applications. Automation suppliers participating in this project are expecting to test their products, first over the internet, and then at the OPC Interop, tentatively planned for May of this year.

Lee shared that the teleconferences will be recorded and made available to OPC members. Anyone wishing to attend or needing more information should contact Lee.

One upcoming event is a June 29^th OPC Foundation WebDemo (I hope to provide a link when it becomes available). It will highlight OPC Xi access to OPC Data Access (DA), Historical Data Access (HDA), and Alarms & Events (A&E) servers by 3-D client applications, Microsoft Silverlight applications, and handheld devices. Another event where OPC Xi will be presented is at Connectivity Week 2010 May 24-27, in Santa Clara, Ca.

One final note I wanted to share is that the OPC Xi code is available on the OPC Foundation website to members and non-members. If you are not a member, the set of documents include OPC Xi Specifications, OPC Xi Introduction, and a License Agreement. The source code, freely available to anyone, includes Source Code Projects containing the base projects (libraries) for an OPC Xi Server implementation.

Members receive an additional OPC Xi WCF Performance Comparisons document and additional source code including:

• Wrapper Projects: Source Code Projects containing reference "wrappers". These wrappers allow you to wrap an OPC Classic DA, A&E and/or HDA Server, enabling access from Xi Clients
• Client Projects: Source Code Projects containing the base projects (libraries) for an OPC Xi Client implementation
• Discovery Server Projects: Source Code Projects containing examples of Discovery servers for querying the availability of OPC Xi Servers during runtime
• Contracts and Constants: Source Code Projects containing core implementation of OPC Xi
• WCF Performance Testing of Xi: Source code Projects and Batch files for automated testing of OPC Xi Performance using various WCF bindings

If you're an automation engineer, you may want your IT developers to know about these developments and to participate if your organization has in-house applications currently running on OPC DA, OPC HDA, and/or OPC A&E.

MP3 | iTunes

Update: Lee shared this news item, OPC Xi Implementation and Demo Project Launch, posted at the OPC Training Institute site. It includes a link (registration required) to an OPC Xi Overview whitepaper.

In the Control magazine article, Playing Well with Others, Editor in Chief Walt Boyes describes how process analyzers can use OPC Xi and OPC ADI to better communicate with control systems. These communications standards help address challenges that Walt articulates:

On-line analyzers vary from simple pH meters to complex hydrocarbon analyzers and online scanning electron microscopes (SEMs), and they speak different languages. An at-line analyzer can be completely different from the on-line analyzer sitting next to it because they were designed to meet different specifications, to do different jobs, and to communicate in completely different ways.

In an earlier post, OPC Express Interface (OPC Xi) Technical Overview Slidecast, Emerson's Lee Neitzel described the OPC Xi standard and how application developers and process manufacturing IT staff could use this standard to connect applications and devices together.

The article has a succinct overview of how OPC Xi works that was adapted from a whitepaper, Introduction to Express Interface (Xi). This whitepaper, written by Lee and DeltaV product strategist, Chris Felts, summarizes the OPC Xi standard:

Xi is a new Microsoft .NET based interface designed for secure and reliable access to real-time and historical process automation system data. Xi provides a standard, .Net based interface for "classic" OPC server functionality, OPC Data Access (DA), OPC Alarms & Events (A&E) and OPC Historical Data Access (HDA) and represents a natural progression of Microsoft communication technology from Microsoft Component Object Model (COM) to .Net.

The OPC Xi standard addressed the legacy issue with the original OPC Data Access standard:

Xi provides the same functionality as the classic OPC servers while addressing some of the known shortcomings of classic OPC. The classic OPC servers are based on COM communications, which was state of the art when the OPC specifications were created, but since the introduction of OPC DA in 1996, Microsoft has moved from COM to .Net communications. COM is efficient for local server access but can be difficult to configure for remote server access and problematic for communication through firewalls.

The whitepaper highlights the underlying technology platform in OPC Xi:

Xi is based on Windows Communication Foundation (WCF), the latest communications technology available from Microsoft. Using WCF, a Xi server is able to offer industry standard communication protocols, such as the Transmission Control Protocol (TCP), the Hypertext Transfer Protocol (HTTP) and Secure Hypertext Transfer Protocol (HTTPS).

If you're a developer or process manufacturing IT professional, you may want to visit the Express Interface web site for specifications, demonstration code, and other development-related information.

MP3 | iTunes

Update: I spoke with the OPC Foundation's Marketing VP, Manny Mandrusiak. The development tools on the Express Interface site mentioned in the last paragraph above will be moving over to the OPC Foundation site. I'll update this post with the new link when the transition occurs.

In an earlier post, Secure, Firewall Friendly Communications, I described the new OPC Express Interface (Xi) standard. It overcomes some of the inherent issues in securely communicating information between process automation and asset management systems with other applications in a process manufacturing facility.

I asked Emerson's Lee Neitzel, who was the technical lead for the Xi project, if he would consider doing a slidecast presentation to provide an Xi technical overview of the standard. He agreed, so without further adieu, here is a 15-minute, narrated overview. The presentation is also available for download.

In this presentation, Lee provides a layman's overview of what OPC Xi is, why it was developed, and how it is a common interface for the OPC Data Access (DA), OPC Alarms & Events (A&E), and OPC Historical Data Access (HDA). He describes the security and performance models.

After this introduction, the presentation gets more specific and provides more detail for software developers. I found Lee's clear descriptions easy to follow even as a non-software developer.

You can also find out more about the OPC Xi specification and sample code at the Express Interface site.

Update and bump:The OPC Foundation has officially endorsed the Xi interface and it is known as OPC Express Interface or OPC Xi for short. I've updated the post to reflect the new name.

Emerson's Alan Harris has written a new whitepaper, DeltaV SIS HART Capabilities. It describes various HART capabilities that can be used with the DeltaV SIS system as well as HART diagnostics implementation best practices. For those unfamiliar with HART, the HART Communications Foundation describes it:

HART (Highway Addressable Remote Transducer) Protocol is the global standard for sending and receiving digital information across analog wires between smart devices and control or monitoring system.

Alan describes the importance of HART diagnostics in safety applications:

The HART diagnostics provide much more information on the health of a field device than can be determined from a standard 4-20 mA signal. For this reason, greater SIL (by turning Dangerous Undetected failures into Dangerous Detected failures) and longer proof testing intervals can be achieved by field devices running HART diagnostics.

He also makes the strong point that HART is not a safety-rated platform and that you should never substitute HART signals for hardwired signals, when the hardwired signal is being used to detect a hazardous condition with a SIL (safety integrity level) rating. HART only should be used for diagnostic purposes.

Alan does describe ways it can be used, especially in safety instrumented systems like DeltaV SIS that can incorporate these diagnostics directly into the SIS logic. One example is upon recognition of sensor faulty status; the SIS logic can degrade the transmitter voting:

...remove the transmitter from the voting logic (i.e. a 2oo3 voted group of transmitters degrades to 1oo2 or 2oo2 with the bad transmitter viewed as faulty) or the transmitter can be simply alarmed via operator graphics.

In the case of a problem with a final control element with a HART-enabled digital valve controller:

...HART device status signals can be used to trip valves that use a HART-enabled positioner or alarm the valve via operator graphics.

Other conditions the SIS logic can monitor in sensor devices through the HART diagnostics include PV out of limits, analog-digital mismatch, PV output saturated, PV output fixed, loss of digital communications, and field device malfunction.

For safety-application rated digital valve controllers like the Fisher DVC6000 SIS, diagnostics available to the SIS logic or asset management software include: loop current, auxiliary contact status, output pressure, % travel, position, drive signal, valve setpoint, pressure, differential pressure, and DVC internal temperature. Also, this digital communications provides a path for the SIS logic or asset management software to initiate manual or scheduled partial stroke tests (PST), which:

...checks for valve movement without fully stroking the valve. Many applications will allow 10% movements to verify valve response without upsetting the critical process line. Diagnostic data is collected and an alert is given if the valve is stuck.

Alan's whitepaper describes some of the diagnostics available in other Emerson devices such as the Rosemount 3051S pressure and 3144P temperature transmitters, and the Micro Motion Coriolis flow transmitters. He describes the purpose of these diagnostics to give the reader ideas of how they might be incorporated into their SIS logic to improve diagnostic coverage and safely increase overall availability by reducing spurious trips.

If you're responsible for your plant's safety instrumented system, you might consider giving this whitepaper a read.

MP3 | iTunes

Emerson's Jonas Berge, whom you may recall from earlier EDDL-related posts, has written a great summary of the EDDL demonstration at the recent ISA Expo 2009. I'll highlight a few of his key points and embed a slideshow of some pictures from the event.

For those unfamiliar with EDDL or Electronic Device Description Language, Jonas summarized it:

EDDL is the leading international standard for device integration and is known as IEC 61804-3. The EDDL standard enables device management software and handheld communicators to display device information so that technicians can setup and commission a device, calibrate, perform diagnostics and troubleshooting, and other device management tasks.

From a host system perspective, Jonas wrote:

Five different hosts including handheld field communicator, laptop software, and integrated control systems supporting EDDL enhancements were on display, and these are just some of the systems supporting EDDL. All leading DCS have by now passed the Fieldbus Foundation Host Registration Process (HRP), supporting EDDL enhancements. A handheld field communicator with color graphics was shown as well. Visitors to the booth could see how system software interoperates with devices from other manufacturers, implementing the EDDL enhancements. The EDDL standard allows a single software application or a single handheld field communicator to work with different types of devices from many manufacturers. That is, a single open solution takes the place of many proprietary tools.

He briefly summarized the history of the EDDL standard:

Traditional DD was introduced in 1992 but lacked graphics. It became an international standard in 2004. In 2006 the graphical enhancements were added to the standard making it possible to support sophisticated (complex) devices, meeting this and all the other NAMUR NE 105 requirements.

The list of device suppliers who participated was quite impressive. Jonas described it:

Simple temperature and pressure transmitters were provided by Emerson, Endress+Hauser, Microcyber and Siemens. Other devices included pH transmitter from Knick as well as Current to Fieldbus Converter from Microcyber. Sophisticated (complex) devices included radar and magnetostrictive level transmitters from Emerson, ISE-Magtech, Siemens, and Vega as well as control valves with positioners from Emerson, Foxboro-Eckardt, Metso, Samson, and Siemens. A variable speed drive was provided by Siemens and fieldbus diagnostics module (a relatively new type of device that monitors signal and noise level of the bus infrastructure) by MTL.

EDDL extended to WirelessHART devices:

Some HART devices were demonstrated with a WirelessHART adaptor. Since EDDL is independent of the communication path, these devices are integrated using the same EDDL file as when they communicate HART over the wire.

The summary report described aspects of the live demonstration including graphics and wizards, look and feel consistency, settings and diagnostics expert help, ease of integration, integrated device diagnostics, data access, and the EDDL role in automation systems' control strategies.

Jonas concluded the report:

State-of-the-art systems and devices support EDDL enhancements in the 2006 edition of the IEC 61804-3 standard. The ISA104 EDDL demonstration at ISA Expo confirmed what the report from BIS found: EDDL is interoperable and meets the requirements of NAMUR NE 105.

The EDDL.org website remains the best source for news, articles, videos, and other information on this important standard.

MP3 | iTunes

One of the issues with the proven OPC standard has been the communications between OPC client and OPC server when a firewall separates them. The cyber-security challenges that process manufacturers face were not envisioned in the original release of the OPC specification in the mid-1990s. The network transport is based on Microsoft's distributed component object model (DCOM), and the challenges of using DCOM with firewalls are well documented.

An initiative was formed among process automation suppliers to solve the security challenges of the DCOM model by using the secure network communications services in Microsoft's .NET framework. Current members of this initiative include Advosol, Emerson Process Management, Honeywell, Iconics, InduSoft, Matrikon, Mobiform, Mynah Technologies, OSIsoft, Smar and TiPS.

The result of their efforts is the Express Interface (Xi) and is described on a newly created Express Interface website:

Express Interface (Xi) is a new Microsoft .NET interface designed for secure and reliable access to automation systems. Xi provides an integrated set of methods for accessing both run-time and historical data, events, and alarms. It has been designed for fast and secure communication through firewalls and for simple implementation and use. Xi defines a Service Oriented Architecture (SOA) that is based on MMS (Manufacturing Messaging Service) and WCF (Windows Communication Foundation).

The site is primarily for client and server developers and includes a specification overview, specification and sample code downloads, internet-accessible Xi demo servers, and the Xi public license. There are also products and tools available to help accelerate software development.

At the recent Emerson Exchange, DeltaV product strategist, Chris Felts, described how the Express Interface communications technology was being incorporated into the upcoming release of the DeltaV system. Like OPC, Xi is a client-server architecture for data exchange between the ISA95 level 2 (control system level) and level 3 (manufacturing execution / operations management level). It also supports the same functionality as OPC Data Access (DA), OPC Historical Data Access (HDA), and OPC Alarms and Events (AE).

Unlike OPC, Xi incorporates the secure aspects of the .NET framework using both firewall-friendly HTTP/HTTPS services and secure web services via Microsoft's Windows Communication Foundation. This communications framework also incorporates levels of robustness not found in the earlier DCOM communications. For example, if communications are lost between the client side and server side, the Xi interface will retain the current state of the connection and allow the client to re-establish communications without losing its original configuration.

At the Emerson Exchange, there were 10 Xi servers and 15 Xi clients in the demonstration area including Emerson's DeltaV system, Ovation system, and Syncade operations management software, as well as ones from Advosol, Iconics, Indusoft, Matrikon, Mobiform, Mynah, OSIsoft, SMAR, and TiPS. Specifically for the DeltaV system, the version 10.3.1 release adds Xi Data Access, Xi Alarms & Events, and Xi Historical Data Access via one Xi interface. The existing DeltaV OPC DA, HDA, and AE servers will remain to support existing OPC applications. Xi and OPC can reside together in the same system.

Chris suggested some uses for the Xi interface including secure communications through firewalls, communications to non-Windows clients, real-time and historical supervisory control and data acquisition, high throughput (100Mb typical bandwidth) and high tag count applications.

MP3 | iTunes

Update: Updated the links above to the ExpressInterface.com site for the change from HTML to ASPX pages.

Emerson's indefatigable Jonas Berge shared with the ISA EDDL list today that ISA has upgraded its email list server software. You may recall Jonas from his leadership on the electronic device description language (EDDL) web site and in many posts here on this blog. For those not already familiar with this device description language standard, it provides a common way for automation suppliers to describe the information inside their intelligent field devices. Information such as:

...function blocks, device parameters, calibration procedures, menu structures, and presentation of diagnostics.

With field device suppliers having a standard way to describe this data, it provides the suppliers of handheld devices, asset management software, and automation systems a method to present this information from the various suppliers' devices in a consistent, intuitive way.

Most folks already subscribed to one or more of the ISA email lists should have been automatically transferred to the new email list management system. Jonas wrote:

ISA has upgraded the list server. ISA members and customers have been migrated automatically. If you don't see [eddl] within brackets in the subject of this message you must manually transition to be part of the EDDL discussion list and to continue to receive the monthly update. Follow this procedure:

1. Create an ISA account (free)
2. Create list server password
   - Wait for confirmation email and click on link in it.
3. Join the EDDL discussion list
   - Log in
   - Click Join, enter your name, and click join
   - Wait for confirmation email and click on link in it.

In case you're not already on the EDDL list, Jonas also shared a few articles, which you may find of interest:

• Interface level made easy with EDDL
• Polymer Plant Achieves Interoperability and Intelligent Device Management with EDDL

The Polymer Plant article was a great example of a process manufacturer, Synthomer, quantifying the benefits of their application of automation and asset management. Things such as output 30% over nameplate rating, 30% faster batch turnarounds, and 15% reduced recipe development time. I'm guessing the engineers behind these quantified results are getting their next capital appropriation requests approved more easily!

The email also linked to the archive of articles on the EDDL.org site. There was also links to presentations, videos, news, technical white papers, and literature. Now you know why I used the word indefatigable to describe Jonas' efforts in educating process automation professionals on the value of this standard.

MP3 | iTunes

I saw ARC Advisory Group's Larry O'Brien's post this week, Emerson Profibus Membership is One More Step toward Common Ground. In it, he writes:

In fact, Emerson has supported Profibus for some time. The PNO membership officially seals the deal and gives Emerson a hand in future PNO development activities, most importantly the implementation of EDDL or Electronic Device Description Language in future iterations of Profibus. EDDL is a common technology that is shared across the Profibus, Foundation Fieldbus, and HART protocols, and serves essentially as a markup language that describes the characteristics of devices and how data should be stored and displayed. EDDL files are similar to XML files, and are used to describe equipment parameters, such as device status, diagnostic data, and configuration details. EDDL is operating system independent and host system independent.

Readers of this blog know that we do discuss EDDL and its cross-protocol applicability and importance to process manufacturers--a consistent view into devices from multiple suppliers, multiple digital communications protocols, and multiple operating systems. In one post, I summed it up:

Following the EDDL standard, device suppliers create Electronic Device Description (EDD) files for their smart field devices. These files provide a standardized form and structure for automation systems and handheld communicators to access and display device diagnostic and setup information, independent of communication protocol or operating system.

Emerson's Terry Blevins gave a nice, quick demonstration of this interoperability including WirelessHART devices at last year's ISA Expo.

The EDDL.org team also has quite a number of demonstration videos on their wwwEDDLorg YouTube channel. Emerson's Jonas Berge provides a lot of the energy behind the new content on EDDL.org. He had a conversation last fall with Automation World's Gary Mintchell, recorded in Gary's Feed Forward blog podcast.

As Larry notes, Profibus has been supported around Emerson for a long time. One example is Profibus DP support in the DeltaV system introduced back in the v5.1 release.

Common ground is a good thing when it comes to access to the information in the smart devices which touch your process and have the ability to warn you of abnormal situation which might impact your plant's performance. The advancement of the EDDL standard is one example of this common ground.

MP3 | iTunes

Update: Thanks to the person who spotted and alerted me to the broken link to Larry's post. I've fixed it above and added it here.

Three automation suppliers' host systems have just passed the Fieldbus Foundation's Host Profile Registration Process, including Emerson's DeltaV system and AMS Device Manager software. The DeltaV and AMS Device Manager software achieved Class 61 - Integrated Host registration by successfully completing the test procedures outlined in the FF-525 Host Profile Registration Process checklist.

The Fieldbus Foundation describes the benefit of this host testing process:

Both automation suppliers and end users will benefit from host registration. Like the current device registration process, host registration will strengthen fieldbus interoperability and system integration. The updated host profile specification is easier to understand than current specifications, and eliminates inconsistent features in favor of defined host profiles.

I caught up with DeltaV product manager, Randy Balentine on what this means for process manufacturers. His first point is that this host interoperability testing enforces a new level of consistency, interoperability, and integration between Foundation fieldbus (FF) host systems and FF field devices. It also highlights the significance of the Electronic Device Description Language (EDDL), because two pieces, DD v5 Visualizations, Methods and DD v5 Persistent Data, are mandatory in this testing. I've discussed in numerous posts, the importance of EDDL in providing a consistent view of information from intelligent field devices.

This host profile registration testing was performed this month in the DeltaV Interoperability test labs in Austin, Texas. Two representatives from the Fieldbus Foundation administered and witnessed the testing process. The tests confirm support for the features contained in the FF-569 (Host Interoperability Support Test Procedures Revision 2.1).

Randy highlights two important tests that only the DeltaV and AMS Device Manager software have passed so far. The first is DD v5.1 Device-Level Access, which provides the ability for the software to present the user with information from FF function, resource, and transducer blocks in a single view rather than multiple views--one for each block. This common view makes operations and troubleshooting easier since tasks can be organized into logical groupings of related information. The artificial barriers based on where the data resides in FF devices are removed.

A second unique test passed is support for Enhanced Parameter Download Support Services, which means that the DeltaV and AMS Device Manager host is able to read a list of parameters in an FF device and prevent a host download from overwriting the values in the device that the suppliers never want to be overwritten. This allows the DeltaV and AMS Device Manager software to perform automatic FF device commissioning and replacement operations without the need for personnel interaction with a software screen.

Randy noted that the following versions of software were part of the successful test:

• DeltaV software, v10.3
• DeltaV v10.3 ProfessionalPLUS Workstation
• DeltaV MD Controller, software revision 10.3.0
• DeltaV Fieldbus H1 Interface Card, Series 2, software revision 4.86
• AMS Suite: Intelligent Device Manager version 10.5

Congratulations to the whole Emerson team who developed the test plans and worked with the Fieldbus Foundation to successfully pass this host registration profile process. Tests like these help improve interoperability amongst products from many automation suppliers.

MP3 | iTunes

I wanted to give a quick mention of the HART Communications Foundation's annual HART Plant of the Year End Users' Award. They are encouraging nominations from all world areas through May 31. I mention this because some process manufacturers have begun to include WirelessHART into their plants to do some applications that were not possible or practical with a wired approach.

If your organization has been using the diagnostics available in your HART and/or WirelessHART devices to improve your process and/or better manage your assets, you may want to nominate your plant here.

The HART Communications Foundation's Executive Director, Ron Helson stated:

We are seeking the plant that has taken the capabilities of HART instruments beyond configuration and calibration, or one that is using real-time diagnostics and process variables in their HART-enabled devices integrated with their control, information, asset management and safety systems... This is the opportunity for end users to share their success and tell the world how HART technology has helped lower their operating cost and increased plant availability.

My good friends who manage the AMS Device Manager brand brought this award to my attention. They also pointed out that three of the past four winners: PDVSA Petropiar oil refinery, Statoil Hydro Ormen Lange onshore facility, and Sasol Solvents and Olefins incorporate AMS Device Manager as part of their use of the HART diagnostic information.

If you're using HART-based field devices and would like some recognition for the innovative work to improve operating costs and increase plant availability, take a moment to nominate your plant.

MP3 | iTunes

I received an email recently from Emerson's Jonas Berge. As a member of the ISA104 Electronic Device Description Language (EDDL) committee, Jonas works to educate process manufacturers on how this standard fosters interoperability between intelligent field devices, asset management software, and process automation systems from various automation suppliers.

Jonas is a large contributor to the EDDL.ORG website. This site provides a basic overview of the standard, news updates, demonstration videos, and other educational materials.

I'll highlight a few recent videos that Jonas and his team have added to the EDDL YouTube page. This first video shows how trend chart data and a level radar echo curve can be exported to Excel for analysis. It includes a Rosemount 3144P temperature transmitter and Rosemount 5400 radar level transmitter in Honeywell SDC-625 software.

The second video shows how the device manufacturer's expert provides their know-how in the form of context sensitive help text for parameter settings and diagnostics. It also shows how device management software provides easy access to device manuals as well as drawings and procedures, and ability store notes. It includes a Rosemount 3051S and Siemens TH300 transmitter, AMS Device Manager and Siemens PDM software, and a 375 field communicator.

The third video shows how the configuration of a device can be printed. It includes a Rosemount 3144P shown in Siemens PDM software and a Rosemount 3051S shown in AMS Device Manager.

There are plenty of other videos on the EDDL YouTube page, which show how EDDL is applicable to different communication protocols and is independent of the underlying communication hierarchy. Applications built on this standard can interoperate with data from HART, WirelessHART, Foundation fieldbus, and Profibus devices--all in the same application.

MP3 | iTunes

The term "wireless" gets bandied about quite often these days among process manufacturers and automation suppliers. As process automation and IT professionals take an interest and look more closely, they begin to see different areas where wireless might be applied. Standards like WirelessHART for field device networks, asset management software and automation systems help provide interoperability.

Wireless plant networks, on the other hand, provide higher-level applications like mobile worker, safety mustering/personnel tracking, and plant video coverage to name a few applications.

I caught a sneak peek of an article written by Emerson's Neil Peterson for Canadian Process Equipment and Control News. The soon-to-be-published article, Choosing a wireless network provider? Look to a standards-based solution., offers guidance for incorporating a wireless plant network.

A key recommendation is make sure the wireless technology is compliant to the 802.11 standards for communications, security and quality of service. Neil notes that these standards are driven by the IT community and not specific to the process manufacturing industry. Choosing a solution that is proprietary causes "vendor lock in" and change comes at a price. If the vendor you rely on is no longer in business, you may be stuck without a good path to standards-based wireless solutions. Also, with a standards-based solution, the infrastructure costs can be shared among the various wireless application projects and plant departments that use this infrastructure. Many applications not economically viable with a wired solution become viable with wireless technology.

When executing a wireless plant network, Neil advises to look for a single-source contractor to integrate the standards-based solution to be responsible and a single point of contact for issues when multiple vendor products are involved. This selection provides choices on wireless devices and suppliers and competition on quality, form factor, ease of use, etc.

Unlike self-organizing WirelessHART field device networks, wireless plant networks usually require a radio frequency (RF) site survey to understand the challenges and obstacles to reliable wireless communications. The survey is important in the network architecture design and planning process to assure the required quality of service for the intended application. Neil offers a video application example where both the video application and the wireless equipment must support the quality-of-service provisions covered under 802.11e in order for the video to share the wireless network properly.

Neil sums up his thoughts that a standards-based approach to your plant wireless network infrastructure helps you to take advantage of new applications conforming to the standard as they become commercially available. With a proprietary approach, you're limited to what the supplier develops and when it gets developed.

MP3 | iTunes

At this ISA Expo 2008 this past October in Houston, Texas, I had the chance to catch Dr. Kris Pister's keynote presentation, From Smart Dust to Smart Plants: The Evolution of Wireless Sensor Networking. Kris is the Founder and chief technology officer for Dust Networks, which began operations in 2002.

Beginning in the early 1990s, Kris saw the impact of Moore's Law on sensing, computation and communications technologies--ever falling costs and increasing power. He believed wireless sensor technology's size, power, and cost would also follow these trends and committed his energies to this pursuit.

His research led to the vision for "smart dust" in the late 1990s. The components included passive communications, sensing, thick-film battery, solar cell recharging, power capacitance, analog I/O with digital signal processing (DSP) and laser diode communications--mostly built with Microelectromechanical systems (MEMS) technologies. In his research at University of California at Berkeley, he and his research team had a working prototype by the end of the 1990s.

The team's work over the next several years was in the areas of ultra-low power and radio frequency (RF) communications. I had a great quote from his keynote in my notes, "RF is challenging. It's robust today because the team saw so many failures a decade ago."

The basis for the smart dust vision was cheap, easy, off the shelf RF systems. It had a wide cross-section of possible uses in academic, military, and industrial applications. Kris shared an example of an earthquake engineering research center where wired, seismic testing cost $5000 per node for real-time data acquisition. The cost per node with wireless seismic sensors was $200 per node. They had similar successes with temperature sensors in an HVAC application on the UC Berkeley campus, deploying 50 wireless sensors in 3 hours and reducing the cost per node from $800 (wired) to $100 (wireless).

For industrial applications, the team looked at research into the primary barriers for adoption of wireless sensor technology. The top four in order of concern were reliability, being standards-based, ease-of-use, and power consumption.

Recognizing the need for industry standards for broad adoption of new technologies, they are participating in several:

Dust Networks currently has leadership positions in several industry groups, including: the Wireless HART working Group (HART Foundation), the Internet Engineering Task Force (IETF), ISA's SP100.11 working group (ISA SP100) and the Wireless Industrial Networking Alliance (WINA).

Specific to the WirelessHART standard:

Dust Networks joined the HART Communications Foundation (HCF) in October 2005. Since then, Dust contributed its Time Synchronized Mesh Networking (TSMP) protocols and technology and collaborated with the HART Foundation and its member companies to develop the industrial automation market's first wireless standard for sensors.

In an earlier post, I discussed some of the diversity techniques used in the WirelessHART standard to achieve greater than 99.9% reliability to address this top concern among process manufacturers in the adoption of wireless sensors.

Kris also discussed their work on minimizing power consumption. Again turning back to my notes I captured this thought from the keynote, "Power- turning radios off is easy. Turning it on is hard... that's why time synchronized is so important. If all nodes in a mesh are within 0.1 msec, than A will wake up and listen for that length of time. A sends ACK to B. Keeps networks synchronized to 100 microseconds or so."

Nice, elegant design... let every device in a self-organizing network get their sleep to conserve power and make sure they wake together in a window of time to communicate and re-synchronize before their next nap.

A steady stream of news shows that Kris and the team's work on the vision of smart dust has paved the way for rapid adoption of self-organizing wireless networks across many industries and world areas.

MP3 | iTunes

I'm lucky enough to receive a copy of Andrew Bond's Industrial Automation Insider newsletter each month through an Emerson subscription agreement. Andrew covers the happenings among the automation suppliers and standards bodies. You can also find some of Andrew's writings on the ControlGlobal.com site.

In the November 2008 newsletter, one item that caught some attention around here was this nugget:

...first TÜV-approved SIL3 Foundation fieldbus safety valve controller to appear on the market. The device delivers status changes automatically via Foundation fieldbus and incorporates real time alarm management eliminating the need for external wiring or I/O cards.

I have the privilege of working in the vicinity of two very knowledgeable people with respect to process safety, Riyaz Ali and Mike Boudreaux.

Riyaz notes that the Foundation SIF specifications are still under development. In a recent Fieldbus Foundation release, it quotes ARC's Larry O'Brien:

It is very clear that end users want this technology and are striving to include FF-SIF systems in their project specifications. Many major end users will probably be specifying FF-SIF systems for their new projects starting in 2011.

A September 2008 ARC whitepaper, Foundation Fieldbus Safety Instrumented Functions Forge the Future of Process Safety, provides background on the Foundation SIF standard advancement and its current draft status. Mike and Riyaz were present at the successful May 2008 Foundation SIF end user demonstration project in Amsterdam, and Mike shared his experiences with me. Riyaz also shared that one of the function blocks, the SIF_DO block, will not be available from the Fieldbus Foundation until the first half of 2009.

Many automation suppliers are developing products based on the current Foundation SIF draft, including Emerson. I asked Riyaz about the current solution Emerson provides until the standard is ratified. Riyaz responded:

The current solution for use in a Foundation fieldbus SIS application is to use the DVC6000f PD instrument. Several hundred units have been supplied worldwide to process manufacturers where partial stroke test scripts are run from host systems, such as the DeltaV system and AMS Device Manager.

In this application, process manufacturers use a solenoid valve operated by a hardwired digital output from the SIS logic solver.

Riyaz expects that until process manufacturers have sufficient experience, they will continue to use an independent solenoid valve to take the SIS valve to the fail state, while at the same time using a DVC6000f PD for partial stroke diagnostics using Foundation fieldbus through the basic process control system (BPCS).

Mike notes that both the DeltaV and DeltaV SIS systems are capable of performing these safety instrumented function predictive diagnostics. The DeltaV system is being used to perform partial stroke testing with the DVC6000f PD using Foundation fieldbus communications. The DeltaV SIS system is being used to automate partial stroke testing with the DVC6000 SIS safety valve controller using HART communications. This additional diagnostic coverage assists process manufacturers with their IEC 61511 safety lifecycle efforts.

Using diagnostics enabled by Foundation fieldbus and HART communications, the DeltaV and DeltaV SIS systems with DVC6000 digital valve controllers can provide many of the benefits today that are promised by Foundation SIF in the future.

MP3 | iTunes

Update: Next week is the Thanksgiving holidays in the U.S. and I'll not be posting. We'll be upgrading our version of Movable Type software. Wish us luck!

When it comes to level 3 of the ANSI/ISA95 model, the production/operations management level, Emerson's Joanne Salazar and Bob Lenich are two very knowledgeable folks. I caught up with them recently in a discussion around this standard.

For those not steeped in the ISA95 standard, Enterprise-Control System Integration, it is the industry standard for information exchange between enterprise and manufacturing control activities and their supporting IT systems. This standard is oriented toward the definition of data models, work activity, and information exchange. ISA has defined four levels within a manufacturing operation that help companies optimize functions, processes, and data. These levels are based on the Purdue Reference Model for Computer Integrated Manufacturing (CIM). The levels include:

• Level 0: physical equipment and facilities
• Level 1: instrumentation, measurements, and equipment health
• Level 2: automation, asset management, and process data collection
• Level 3: operations management, workflow execution, and document management (MES)
• Level 4: transaction-based enterprise management (ERP)

Joanne noted that the level 3 functions are important because they include key work processes: workflow management, recipe control, maintaining records, and optimizing the production process. By addressing these functions, process manufacturers can reduce costs, increase efficiencies, and optimize resource utilization. Manufacturers face price pressure and increasing global competition, and seek ways to squeeze efficiencies from their manufacturing operations. Joanne also commented that process manufacturers have struggled to implement successful solutions that link the real-time plant floor activities with the transactional-based business planning functions.

Bob responded that level 3 functionality can be addressed in a comprehensive manner-including a single recipe for batch-based processes that address both manual and automated activities, life cycle documentation management, and integration of data that is not real-time-but impacts the product (such as lab results.) These level 3 solutions provide "closed loop" control for operations beyond the automated processes, which enables the manufacturer to make better and faster business decisions and optimize their resources.

While Joanne supported this vision, the practical implementation of these solutions has been difficult. Software integration interfaces have historically been time consuming and require extensive testing-not to mention the difficulties that can arise when the support staff must maintain and upgrade the software.

Bob believed this is where standards, such as ISA95 Enterprise Integration, play a big role. By defining data models, common terminology, and information exchange definitions, the integration of various software packages becomes practical in a working plant. Level 3 manufacturing operations software suppliers who adopt these standards make it easier for the process manufacturer to connect solutions from different companies.

By sitting on the ISA95 committee, Bob has had the opportunity to help define this standard. The collaborative effort of suppliers and users in this standard has helped provide a framework for software suppliers that can help to achieve some of the operational efficiencies sought. Bob pointed to Emerson's automation and operations management solutions that communicate--using the ISA88 recipe model--so that the batch process manufacturer can define a single recipe in a single engineering environment. This recipe spans all functions of an operation, both manual and automated, and enables comprehensive data collection. This single recipe approach may streamline change control and reduce the engineering effort.

And that just might squeeze some more efficiency from the manufacturing operations.

MP3 | iTunes

Earlier this week, I listened to Gary Mintchell's personal podcast, Automation Minutes Episode 59 (iTunes | RSS feed). Gary interviews Emerson's Jonas Berge, a member of the ISA104, Electronic Device Description Language (EDDL) standards committee. EDDL is also recognized globally by international standard IEC 61804-3. A few weeks earlier, Gary had interviewed a member of the FDT (a competing standard) marketing committee.

Jonas provides a detailed summary of what EDDL means to process manufacturers. It's a standard to display information in intelligent field devices communicating via HART, WirelessHART, Foundation fieldbus and Profibus back to the device management software and automation system. EDDL files are standards-based compressed text files that reside in the device management software to provide a consistent view to devices from different manufacturers for setup, calibration, diagnostics, etc. Through the EDDL file, the device manufacturer tells the system what command to send to get information from the device, how to decode it, and how this manufacturer would like to present the data.

Jonas offers a great analogy of how EDDL is like HTML. Both are text-based files. Client software (device management software and web browser) renders both, both are platform independent since they are text files and not installed programs, and both are version independent again since they are not installable programs. And similar to how devices like PCs, MACs and smart phones render HTML pages, PCs and handheld devices with device management software render smart device information.

Also, in how HTML supports sophisticated displays, EDDL supports sophisticated ways to render valve signatures, vibration spectrums, radar level "echo curves", dial gauges, historical trends, and step-by-step "wizard" procedures. Jonas points out that these graphical enhancements were added to the EDDL standard in 2006 to address the NAMUR NE 105 requirement to support access to full functionality in complex devices in the way the device manufacturers want this functionality to be displayed. These complex devices include valve positioners, variable speed drives, machinery health transmitters, wireless gateways, and bus diagnostic modules to name a few.

The design basis behind the EDDL standard is that the device manufacturer knows best what information their devices contain and how it should be displayed. The device manufacturers can make the full functionality of their devices visible and available on any system. The device management software suppliers know best how to provide a consistent view of trends, gauges, step-by-step procedures, etc.

For plant staff members who manage the device management software, the EDDL files do not become obsolete as the operating system is revised or security patches are added. Since these are text-based files, multiple versions can exist together within the device management software to address the plant realities of different devices, from different vendors, communicating with different digital protocols.

The information presented from these various devices have a common look and feel for the instrument technician and others who access the information. And the integrated diagnostics provided by the EDDL standard meet the NAMUR NE 91 requirements.

I captured a quick video at the recent ISA Expo 2008 in Houston, Texas. I just received some photos and ISA104 / EDDL Booth Report that show systems from ABB, Emerson, Invensys, and Siemens interoperating with advanced valve positioners and transmitters from Emerson, Endress+Hauser, Invensys, Masoneilan, MTL, Metso, Samson, and Siemens. These pictures demonstrate this interoperability in action:

MP3 | iTunes

I spent the day yesterday at the ISA Expo in Houston, Texas to listen to some of the presentations and see some of the demonstrations taking place this week.

I caught up with Emerson's Terry Blevins who is showing the interoperability and view of smart device information with the EDDL standard in the ISA104 booth.

Terry was gracious enough to let me put him on the spot by doing an on-the-fly tour of the EDDL booth with my handy flip video camera. He gives a short three and half minute overview of different devices from different automation suppliers, communicating over different digital communications protocols--all being displayed on a single software package that supports the standard.

Without further adieu, here's Terry:

Thanks for the quick tour, Terry!

The HART Communications Foundation has published another WirelessHART white paper that describes various scenarios for low-latency PID loop control. The paper, Peer-to-Peer Communication with WirelessHART describes this transmission of information between network participants on a WirelessHART network.

This standard is designed to support applications like monitoring, diagnostics, alarm and event detection, and more complex data forms required for vibration monitoring, valve signature testing and process control.

A simple, cooling jacket temperature loop is the basis for five scenarios ranging from everything communicating wirelessly to everything wired in the field, but communicating wirelessly back to the WirelessHART gateway. The example loop includes a temperature transmitter, a control valve with a digital valve controller and a controller running in the WirelessHART gateway or process automation system.

The scenarios vary where the PID control resides and what devices in this control loop are hardwired.

For example, the first scenario has the temperature transmitter hardwired via a 4-20mA HART signal to the digital valve controller. Both these devices are wired to a WirelessHART transmitter that communicates back to the gateway. The PID control runs in the digital valve controller. Monitoring and setpoint changes are done via wireless communications from the process automation system.

Another scenario has the control running back in a process automation system controller or in the gateway with the transmitter and digital valve controller connected wirelessly to the gateway. The measurement value, valve target position and valve actual position communicate via the WirelessHART protocol.

There are power considerations if control is resident in one of the field devices. On way to address this is to run power as mentioned in the first scenario. The second way is to use the publish-subscriber communications built into the WirelessHART standard. From the whitepaper:

In WirelessHART, wireless devices are designed to support publisher-subscriber communications using multiple burst mode commands. Burst mode commands sent by the publisher (e.g. transmitter) are received by the gateway, cached, and then redistributed to the subscribing clients (e.g. valve) that are registered for notifications.

This burst mode communications happens on a periodic schedule and includes a timestamp, so that the other devices and applications subscribing to this information know its freshness. A WirelessHART Network Manager handles the security/encryption/validation of this communications along with the routing and scheduling.

The white paper concludes:

The WirelessHART protocol allows for secure, highly reliable, low latency control with almost no impact on the bandwidth and absolutely no impact on process performance. All of this is automatically built into the WirelessHART standard with little or no input from users. WirelessHART is simple, reliable, and secure.

Consider giving this white paper a read to see how you might apply WirelessHART to some of your low-latency control applications.

Update: I inadvertently picked up the wrong hyperlink for the whitepaper. Both links have now been updated. Sorry about that!

The ISA recently issued a press release around demonstrations of Electronic Device Description Language, EDDL (international standard IEC61804 and ANSI/ISA-61804-3) and FDT (ISA103) technologies at the ISA Expo 2008 in October in Houston, Texas.

For those not familiar with EDDL, I described it in an earlier post as a text-based language that is used to describe the characteristics of field devices. Following the EDDL standard, device suppliers create Electronic Device Description (EDD) files for their smart field devices. These files provide a standardized form and structure for automation systems and handheld communicators to access and display device diagnostic and setup information, independent of communication protocol or operating system.

Emerson's Terry Blevins has been working closely with other automation suppliers on the EDDL demonstration. He also is the ISA104 committee chairman. This committee has adopted the EDDL standard, IEC61804, as an ANSI/ISA standard. The release describes what will be shown in the ISA104 booth at ISA EXPO 2008:

The ISA104 EDDL booth at ISA EXPO 2008 is a demonstration by major DCS manufacturers such as Invensys, ABB, Siemens and Emerson that illustrates the technical strengths of the EDDL standard, IEC61804, to support advanced user interfaces for diagnostics and device setup independent of the communication technology support by the device. Devices such as valve position[er]s based on HART, Foundation Fieldbus, and Profibus from Metso, Samson, Invensys, Fisher Controls, and Siemens are used to illustrate how manufacturers are using EDDL to document their device capabilities in a single, open and consistent format. A live demonstration of diagnostic information being accessed using a WirelessHART adapter connected to a wired HART device and through wireless access to a self-powered WirelessHART device illustrates how EDDL supports the latest wireless devices.

The demonstration provides the exhibit attendees the opportunity to see the advanced interfaces for device diagnostics and device setup that are available from the major DCS manufacturers that use device EDD's. This demonstration will also show how the EDDL technology is by DCS supplier to provide interfaces to support wireless devices based on the WirelessHART standard.

In the release, Terry and the ISA104 committee also describe recent activities to continue to advance the IEC61804 standard:

International Electrotechnical Commission's Technical Committee 65 (IEC TC65) met in Tokyo, Japan, the week of 18 May. The working group responsible for the EDDL international standard, IEC SC65E WG7, met on 20 May and discussed future EDDL enhancements that will be incorporated into the existing standard, IEC61804. A number of guests from Japan and China that attended the WG7 meeting expressed an interest in learning more about EDDL. Thus, following the WG7 meeting, Christian Diedrich and Terry Blevins put on a workshop that provided more detail on EDDL and showed examples of how EDDL is used to write device descriptions.

If your plans include Houston the 14-16^th of October, make sure to stop by and visit with Terry and the other automation suppliers to see how this standard provides a common, interoperable way to present smart device information to you.

A colleague forwarded a recent ARC Advisory Group report, FDT Reaches Out to Process End Users. It described a recent briefing by representatives of the FDT Group to the ARC team. A few parts of the report that really raised some eyebrows among members involved in the ISA104, Electronic Device Description Language (EDDL) standard (a.k.a. IEC 61804-3).

The first part I'll highlight:

FDT technology essentially standardizes the communication interface between field devices, control systems, and asset management systems. FDT is communication protocol independent, supporting devices that use HART, PROFIBUS, and more recently, Foundation Fieldbus (FF). It allows users to access device data and settings through any protocol or operating system.

Emerson's Jonas Berge, a member of the SP104 committee sent me the following response after he had a chance to read this report:

Although it is true that both open and proprietary protocols are supported by FDT/DTM, it is not correct that any operating system is supported. FDT/DTM is based on Microsoft technology and only works for Windows. Operating system independence is a unique characteristic of EDDL so it protects investment in software and devices against obsolescence as new Windows versions, service packs, and hot fixes are introduced over the life of the system. With EDDL, workstations can freely be upgraded. Because it is not tied to Windows, EDDL also avoids registry conflicts when new device types and versions are introduced. This in turn enables EDDL to be loaded on the DCS operator console (device management need not be an isolated console) so operators can see device failures and take evasive action and inform the technicians (who are in the field, not in front of maintenance console). This is a key capability to integrate predictive diagnostics into daily work processes. Moreover, new device types and versions can be integrated without divulging the administrator password. Operating system independence is a necessity even if you use Windows workstations. It also makes EDDL suitable for handheld field communicators (the technician's best friend for fieldwork) which are embedded devices not based on Windows. Thus, EDDL is supported in all tools from DCS engineering station for configuration, handheld communicators for commissioning and field service, device-management software part of asset management solutions during operation, and laptop software for the workshop. This is the reason why you only need EDDL and need not grapple with two technologies. EDDL with enhancements need not be complemented.

Another part of the report notes:

One major difference between FDT and EDDL is FDT's standard interface between field devices (DTMs) and supervisory system (frame application software). Due to the standardization and openness of FDT, DTM's from any supporting vendor can operate on frame applications from any supplier. The frame application provides a HMI to display device configuration, diagnostics, predictive alerts and more. EDDLs require an application that typically is proprietary, developed by vendors for their products that can be applied to multi-vendors with appropriate testing.

Jonas responds:

Device management software using EDDL are not proprietary. EDDL is an international standard IEC 61804 established since many years ago. Every control system supports the original EDDL from 1992 and most if not all support enhanced EDDL or have announced they will. Millions of devices from hundreds of manufacturers support EDDL including all HART and FOUNDATION fieldbus plus many PROFIBUS devices.

The OPC Foundation also supports the EDDL standard. Jonas recently wrote an article, OPC Made Easy, about the integration of the important OPC standard and its relationship with EDDL.

The ARC report also highlights an FDT evaluation report:

FDT further discussed the results of the WIB lab FDT evaluation report, dated November, 2007, executed by Shell Global Solution (SGS) using the FF protocol. The WIB International Instrument Users' Association, of which SGS is a member, executed the unbiased test on behalf of WIB in their facilities. SGS compared specific FF functionality and evaluated the ability FDT to access and utilize device data for commissioning and maintenance purposes. Five distributed control systems (DCS) with standalone framework applications were tested with five field devices that supported both EDDL and FDT/DTM in all feasible combinations.

Jonas adds these observations to this report:

The WIB report, if read in its entirety, has some interesting observations. Although only one device was compared (so not all EDDL capabilities were seen), it makes clear EDDL is unique in supporting FOUNDATION fieldbus block configuration. Several times over, it mentions EDDL is the technology with no interoperability issues. The EDDL approach has a clear structure for configuration and setup. It also implies EDDL does a better job of commissioning and parameterization with a single tool. It also suggests EDDL has a less manufacturer specific, more consistent, look and feel. Lastly, it hints EDDL is more attractive for DCS systems because the files are not executable.

Although it may be true that combining EDDL with FDT/DTM you get some benefits from both, unfortunately you also get the drawbacks of both. Since FDT/DTM adds little or nothing to enhanced EDDL (they both do the same thing, albeit differently) there is no additional benefit to speak of. However, the drawbacks of mixing both technologies are plenty. For example, on its own EDDL protects the system investment because it is independent of Windows. Mix in FDT/DTM and your system no longer has this advantage. Similarly, the ability to integrate diagnostics in operator stations is lost as is consistent look and feel. The ability to add new device types or versions without conflicts is also lost.

Update: Welcome Feed Forward blog readers! I welcome your thoughts on this.

It's often difficult to understand the value a new international standard brings to your process manufacturing operations. Emerson's Jonas Berge has been hard at work in his capacity on the standards committee ISA104, Electronic Device Description Language (EDDL) to educate process automation professionals. In addition to the standards committee Jonas contributes his energy to the EDDL.org website and the EDDL email list. You can also see some of the other times I've featured his work.

His latest article, Temperature Transmitters: Warming Up to EDDL, in Industrial automation asia magazine, describes how enhancements to EDDL (a.k.a. IEC 61804-3) have improved setup and diagnostics of temperature transmitters.

Jonas describes how the technology in temperature transmitters has advanced to provide diagnosis of their health, the sensor wiring and the temperature-sensing element. This diagnostic information is communicated back to the asset management and/or automation system via digital protocols such as HART, WirelessHART and Foundation fieldbus.

An example Jonas offers is a temperature element burnout. The temperature device uses the EDDL standard to

...provide image displays, switched dynamically, that illustrate the problem.

Some of the more sophisticated temperature transmitters have dual sensing elements. Sensor drift can be determined and reported back to an operator or maintenance technician if a maximum difference is exceeded between the two measurements. These dual sensors can also operate in a hot-backup mode if they measure the same point. They are set in a primary/standby mode where failure of the primary sensor causes its value to be ignored and the backup sensor to be used.

Jonas also describes a loop-testing scenario typically performed by maintenance technicians:

Systems and software that fully implement IEC 61804-3 support EDDL wizards that take the technician through required steps to check the temperature transmitter as defined by its manufacturer.

The wizard reminds the technician to inform the operators that a loop test will be performed so the associated control loop can be changed to manual to prevent upsetting the process when temperature is simulated.

The EDDL standard provides a standard way for device manufacturers to embed help into these devices, which reduces learning hurdles for operators and maintenance techs to use these diagnostics.

Thanks to Rohit Kadam for pointing this story to me in his Nice To Meet You..! blog. Rohit is an active member in our DeltaV Twitter Community.

When I posted last week on WirelessHART reliability, I had a chance to speak to Emerson's Russ Muller who is a senior PlantWeb specialist. As we discussed the reliability figures, Russ mentioned that the sites that applied the best practices saw reliability figures much higher than 99%. If you've seen the PlantWeb University Wireless course, in the Wireless 203- Self Organizing Networks section, it shows this figure:

Even in this extreme example of low reliability links, by designing multiple paths for each device, a self-organizing network can reach that level of performance by constantly choosing the path that offers the best reliability at the time. With self-organizing networks, it's important to note that site surveys are not required. Russ shared with me some best practices learned from the early wireless installations which I'll pass along to you.

The first consideration is the size of your facility. If you have a large facility like a refinery or chemical plant, the wireless field network should be scoped to a single process unit. For vertically arranged facilities like power plants or some pharmaceutical sites, the self-organizing network should be scoped to a single floor.

Next, it is extremely helpful to have a scaled drawing of the single process unit or floor where the network will be installed. In an earlier post, I discussed the creative use of Google Earth to zoom in on an outdoor facility where they didn't have scaled drawings handy. These building drawings are typically available for inside facilities, which is a good thing since the satellite photos can't see inside a building... yet!

With the scaled drawing, plot the location of wireless devices. Consider the immediate ones you want to install as well as possible future ones. Every wireless device should have multiple neighbors to provide path redundancy for higher overall communications reliability. Based on the experience gathered from hundreds of installations to date, each wireless self-organizing network should be designed with a minimum of five wireless devices to provide this path diversity.

As you look at the devices plotted on your scaled drawing, it's ideal that each device have three neighbors as potential paths of communication.

Next, consider the placement of the wireless gateway. In small networks, the smart wireless gateway should be located in the center of the network. For larger networks or installations that require the wireless gateway mounted in a control or rack room, you should build the self-organizing network around the location of the wireless gateway, closest ones first, per your plot plan. Also, remember that the gateway needs to connect the network to your host automation or asset management system using common industry communications standards like OPC, MODBUS and MODBUS TCP.

The wireless gateway should have a direct wireless connection (connected without a hop through another device) to 25% of the devices in the self-organizing network. It will still be reliable if less than 25%, but greater than 25% is optimal. You can add wireless devices or repeaters to help achieve this best practice.

During installation, add devices outward from the gateway to reach other areas in the process unit. This installation process helps you see the devices as they are being added and helps verify the robustness of the communications.

I hope sharing these best practices in addition to the PlantWeb University Wireless courses provides you the background to try a wireless field network application in your facility.

I received a sneak peak of a white paper in the works by Dr. José Gutierrez, corporate director of technology with Emerson. This paper, based on the Why WirelessHART? article, discusses diversity techniques to achieve the reliability design objectives in the WirelessHART standard.

José begins with some history of proprietary point-to-point wireless "cable replacement" solutions. Data transmission was required for these applications but cables were not economically feasible to install. These wireless solutions also typically were not designed to scale.

Process manufacturers have been under constant market pressure to improve efficiency and productivity. This pressure has spurred innovations by automation suppliers on numerous fronts including advanced diagnostic algorithms, improved sensor technologies and improved communications technologies especially in the area of wireless communications.

In the 1990s, the U.S. Defense department invested in wireless communications research with high reliability, highly secure and extremely low powered design objectives. This basic research fed into future developments by leading industrial and technology companies on the IEEE 802.15.4 radio-communications standard for wireless sensor and actuator applications. José served as chief technical editor of the IEEE 802.15.4 standard.

During this time in 2003, the HART Communications Foundation started its wireless efforts that culminated in the release of the WirelessHART standard in the fall of 2007. This standard is designed to support a range of applications including process monitoring, process control, equipment monitoring, environmental monitoring, energy management, asset management, predictive maintenance and advanced diagnostics.

What makes this range of applications possible is the advanced diversity techniques designed to achieve reliability greater than 99%. When best practices like three or more communications paths per device are applied, the reliability is significantly higher--approaching 100%.

The WirelessHART standard employs five methods of diversity: time, coding, frequency, path and power. Here's my brief summary of each from the white paper.

Time diversity involves the use of intelligent data transmission scheduling to minimize collisions and recover from losses. WirelessHART uses synchronized time division multiplexing.

Coding diversity uses the radio spectrum where specific transmissions can be separated from noise and other simultaneous communications.

Wireless devices use frequency diversity (a.k.a. channel hopping) to dynamically choose different communications frequencies to avoid jamming or to mitigate interference from other wireless systems.

Path diversity comes from the self-organizing, mesh-communications network formation of wireless devices in a point-to-multipoint fashion back to the automation system and/or asset management system.

The final diversity technique used in the WirelessHART standard is power diversity where radio power transmission is controlled to a minimum level to destination devices to cut down on radio frequency noise for other devices using the same frequency spectrum.

I hope some of this background helps give you an appreciation for the techniques used to achieve high wireless communications reliability. The proof comes by giving it a try in your plant on measurements not currently possible or practical to wire.

Emerson's Dale Perry and Jonas Berge teamed up for a look at EDDL (Electronic Device Description Language) technology from a pressure measurement device perspective in a recent Industrial Automation Asia article, Pressure Transmitters: EDDL Equals Easy.

Their summation describes well why you might have an interest in this interoperability standard:

Given the breadth of transmitters and other field devices throughout process facilities, interoperability is essential for integration and ease of use. EDDL is the key to interoperability in a digital plant architecture as it merges functionality of devices using HART, Foundation fieldbus, or WirelessHART into the same single software structure so they can be managed together from a single dashboard.

Dale and Jonas describe the problem the enhanced EDDL standard addresses from the perspective of a pressure transmitter supplier:

Historically there was no display standardisation. The dilemma was that the pressure transmitter manufacturer could not dictate the system display or accessible transmitter functionality on a system.

It was primarily left up to the system vendor to create specialised screens that may or may not have included all the specialised functionality of pressure transmitter. It was not uncommon that devices that did not come from the system vendor itself was at a disadvantage.

The article highlights some of the information presented by Rosemount pressure transmitters via enhancements to the EDDL standard. The authors note that before these enhancements:

...there was no graphics for quick visualisation of the pressure transmitter diagnostic status nor could you look at the current PV and tell what the pressure was two minutes ago. And if the device had multiple variables there would be multiple numbers to look at and do math and correlation in your head.

The article displays and describes screen captures as seen in AMS Device Manager that supports enhanced EDDL including: trend charts, device diagnostic summary status, graphical gauges, detailed diagnostics, and even specialized charts that device suppliers can create. One Rosemount pressure transmitter example is a standard deviation chart showing process noise. In this case, it typically signals a plugged impulse line.

Dale and Jonas sum up the article by defining the responsibilities for both the device and software application providers:

Although the transmitter manufacturer controls what information is made available from the transmitter and how it is laid out on the screen, the look & feel details such as the appearance of buttons as well as activation of the help, printing, acceptances of changes, and comparison is handled by the device management software ensuring all devices work consistently regardless of manufacturer, type, or protocol.

Update: I updated the link to a PDF version of the article.

You may have seen some of the coverage of last week's Foundation for Safety Instrumented Functions (SIF) End User Demonstration (DeltaV News, Sound OFF! blog, and ARC's Larry O'Brien's blog to name a few.) This event highlighted demonstrations of Foundation Fieldbus Safety Instrumented Systems (FF-SIS) which were held at Shell Global Solutions in Amsterdam, Saudi Aramco in Dhahran, BP in Gelsenkirchen, Germany and Chevron in Houston.

A demonstration version of the Fisher DVC6000f SIS was included at each of the demonstration sites. Also, Emerson participated in the demonstrations of Foundation SIF technology by providing special demo versions of Rosemount, DeltaV, Fisher, and AMS Suite products.

Emerson's Mike Boudreaux was at this event held in Amsterdam. Mike presented the results of Emerson's participation the Chevron demonstration held earlier this month. For this demonstration, Emerson provided a logic solver that communicated with field devices using the FF-SIS protocol. Demo versions of devices from various suppliers were specially developed to demonstrate the capabilities of the FF-SIS protocol. The demonstration tested the capabilities of the FF-SIS protocol and interoperability of devices.

These components were included in the demonstration project:

• Rosemount pressure transmitter
• ABB pressure transmitter
• Magnetrol level transmitter
• Siemens level transmitter
• Emerson logic solver
• Fisher DVC6000f SIS control valve
• Westlock positioner
• Pepperl+Fuchs power conditioners with diagnostics
• Fieldbus Diagnostics FF-SIS packet analyzer
• DeltaV HMI and engineering tools
• AMS Suite: Intelligent Device Manager
• Fisher ValveLink SNAP-ON

I hope Mike doesn't mind, but I've lifted the account of the demonstration from his Emerson-internal blog:

The demo system was originally assembled at Emerson in Austin, TX where we did some preliminary testing to make sure that everything worked. When the demo unit was delivered to Chevron, it was set up and running in less than an hour. It was simply a matter of plugging in cables and powering the system up. There were a couple of devices that required software resets, but for the most part the system started up with ease. We used AMS Suite: Intelligent Device Manager for configuring devices and clearing fault states. The functionality of AMS Suite easily transferred to FF-SIS.

We implemented two SIF's with 1oo2 voting. The first was a high pressure shutdown, acting on the DVC6000f SIS. The second SIF is for a high level shutdown, acting on the Westlock positioner. We tested various trip scenarios. In one case, we demonstrated degraded mode operation, where the voter block was configured to ignore a value if the PV status was bad based on device diagnostics. The function blocks operated as expected, with the same functionality that is available in the DeltaV SIS system today using HART I/O.

In addition to using AMS Suite for configuring devices, we also demonstrated the partial stroke test using ValveLink SNAP-ON. The partial stroke test was executed flawlessly with all of the features of ValveLink available for the FF-SIS device as is already available today through HART or FF. In addition to a standard partial stroke test, we also demonstrated a scenario where a trip occurs during the PST cycle. The valve behaved as it should, aborting the PST and closing the valve.

In his presentation, Mike described how the use of Foundation SIF technology could help process manufacturers to run safer and more reliable processes. His first point was that more advanced diagnostics are available to detect random and systemic failures while reducing spurious trips. Another was that test intervals for final control elements could be increased through the initiation of partial stroke testing from the operator stations. Also, the maintenance of devices involved in the SIFs is simplified with the integration of their diagnostics with the operator stations. This integration also facilitates easier commissioning and testing of these devices.

This end user FF-SIS demonstration testing is another milestone in the path of this technology becoming available for your future process safety applications. End users who participated at the event in Amsterdam indicated that they will continue to internally test the Foundation SIF technology. Most people expect that it will be 2-3 years before an actual implementation will occur in a process manufacturing facility. Key milestones for the future will be the finalization of the FF-SIS specifications, development and testing of commercial devices, and device certification for IEC 61508 compliance.

I had the opportunity to visit with Emerson's Tom Wallace who was here in Austin recently. I like to joke with Tom that a post I had done with him comparing and contrasting HART and Foundation fieldbus caused such a stir, that it produced one of this blog's highest monthly visitor totals to date.

So let's see what we can do this month! Tom takes a comparative look at some of the swirl that surrounds EDDL and FDT/DTM in a new paper, FDT/DTM, and Enhanced EDDL, what's best for the user. These are both technology enablers for field devices, automation systems and asset management applications.

If this is all acronym soup to you, here's Tom's brief description of these technology enablers:

Device functionality is invoked using Electronic Device Description Language, EDDL or DTM's [Device Type Manager]. The DD or DTM tells the host what functionality the device has, and how the functionality is invoked. It also tells the host how to do common maintenance functions such as calibration, trims, tests, and other device activities.

I'll start with Tom's conclusion and then highlight some of his supporting points. He concludes:

In my opinion, there is a better technical implementation based primarily on ease of implementation and support. That solution is to use EDDL for all devices where EDDL is technically capable of delivering complete device functionality, and to use a DTM or a snap-on application to handle only the exceptions. I make this recommendation because it is simpler to implement a single solution than a combined solution. EDDL is a single solution that will work for the vast majority (95%) of HART, Foundation fieldbus, and Profibus PA devices.

Tom's point for commissioning Foundation fieldbus devices contrasts installable programs versus data files:

Commissioning Foundation fieldbus devices on most control hosts require DD's [device descriptions]. Most control hosts have a set list of applications that are considered safe to install on the host engineering or operator station. Each DTM is an application, and the testing required to ensure hundreds, or potentially thousands of DTM's are compatible with a control host user interface is not practical. EDD's are files, not application programs. Therefore there is no program installation risk loading EDD's on a control host.

On data availability, Tom writes:

...EDDL is the path for data availability that originates from a device, or is going to a device. The OPC Foundation support for the enhanced EDDL will broaden the use of EDDL for applications such as ERP, maintenance management, and other applications.

For the display of data in field devices, Tom notes:

EDDL is supported in the host by DD services. DTM is supported in the host by a frame or FDT. For many applications and hosts either EDDL or DTM can be used for data display. For hosts that are not based on a windows operating system, EDDL will be used as DTM requires a windows operating system. EDDL has defined display objects such as charts, graphs, etc. DTM is more of a free form environment using a variety of programming languages.

The choice for the enabler technology to use is EDDL or a combination of EDDL and DTM. Tom lists some considerations for your discussion based on operating systems, operating system version management, functionality and complexity of the device and if a custom display needs to be created.

Tom sums all this up with the following recommendation:

The final recommendation is to use EDDL as the required standard since each device must have a DD. Allow the use of DTM's on an exception basis where the functionality is required, and EDDL cannot provide it. Make sure that all the functionality to replace a failed device, or place a new device in service is available in EDDL. This will simplify implementation and maintenance, mitigate operating system migration issues, and provide a lower risk more error free working environment.

Update: Welcome readers of Gary Mintchell's Feed Forward blog! Join the conversation and add your comments below or on Gary's post.

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.

Courtesy of Emerson's VP of wireless technology, Bob Karschnia, I received a draft copy of a whitepaper circulating about redundancy in WirelessHART device networks. It's not yet finished so I don't have a link, but here are some of the key thoughts I gleaned from it.

Redundancy, in this context, is defined as a duplication of critical system components to reduce the probability of a failure caused by a single component. This redundancy is available at three levels including the network of wireless field devices, the access points and the gateways to the control and/or asset management systems.

Starting with the wireless field devices, the WirelessHART standard supports communications redundancy through multiple paths (spatial diversity), multiple transmission frequencies (frequency diversity) and multiple timing possibilities (time diversity).

Consider a wireless temperature transmitter mounted in your process communicating with other wireless devices--say a pressure and level transmitter. This device creates a self-organized communications path through one of the other devices back to an access point or directly to a wireless gateway. If the path through this device is obstructed, the temperature transmitter will retry at a slightly different time, frequency and path to the other device. If it fails, it will retry--again adjusting time, frequency, and path.

As we discussed in an earlier post, Planning Your Wireless Instrument Installation, it's important that each wireless device have at least two other devices to communicate with to provide alternative paths when needed.

An access point is a specialized WirelessHART device with a high-bandwidth communication interface to the gateway. Multiple access points can be connected to the gateway to provide path diversity and increased bandwidth across the network. There is no limit to the number of access points in the field network.

At the highest level of the field network is the gateway, network manager software and security manager software. The network manager performs scheduling and routing services. The security manager performs security key generation and storage as well as field device authentication services. All three components can reside within a physical gateway or can be distributed in separate gateways.

Using a mechanism similar to redundant controller pairs available in most automation systems, primary/backup redundancy management is being developed and stress-tested for these gateways.

I'll keep a sharp eye out for the finished whitepaper and update this post with a link.

I read Dick Caro's, Which Way Wireless article published last Friday on the ControlGlobal.com site. It discusses WirelessHART and ISA100.11a and their paths to standards. He describes ISA100:

ISA100.11a is the name of the first standard being developed by the ISA SP-100 standards committee. The committee was officially chartered in 2005, with an editing team created in early 2007 to actually write the standard. Completion of the standard's first draft is scheduled for November 2008, and it may be that this schedule will be met.

Let's check this schedule against past standards to get a reading of when products might be expected.

The only standards effort in which I was fortunate to participate was the original launch of the OPC standard--then called "OLE for Process Control." A task force with Microsoft in a consulting role and five automation suppliers: Emerson (then Fisher-Rosemount), Intellution, Rockwell Software, Opto 22, and Intuitive Technologies announced the initiative at the ISA show in October 1995. The objective was to create a real-time communications standard based on Microsoft's OLE and COM technologies. Emerson served as master editor for this initiative.

The first draft of the specification was released in December 1995 and a second draft in March 1996. Three global seminars were held to teach interested parties about the standard's scope from April through August of 1996. Version 1.0 of the specification was release at the end of August 1996.

A beta release of the initial DeltaV system came out late in the fall of 1996, and the general release occurred in the spring of 1997. It was one of the first, if not the first, OPC server and OPC client commercially available. From the announcement of the task force in the fall of 1995 to commercially available products in the spring of 1997, this has to be one of quickest standards development efforts in process automation history. This standard, now referred to as OPC-DA, is maintained by the OPC Foundation and is still widely used today as a way to integrate software, systems, and devices.

I think this effort progressed quickly because Microsoft technologies were becoming increasingly important in process automation solutions and the existing method of communication, DDE, had its limitations that most acknowledged.

I haven't been real close to the WirelessHART path to standard, so I called Terry Krouth, Emerson Process Management's Chief Technology Officer, to understand its path to a standard. The wireless portion came with the HART 7 specifications formally approved by the HART Communication Foundation (HCF) members last June and authorized for release by the HCF board in September.

The HCF launched the WirelessHART initiative in November 2004. Its objective was to establish a wireless communication standard for process applications and enable wireless access to existing HART devices whose installation numbers more than 20 million. More than 25 companies were involved in its development including most of the major automation system suppliers. This HCF whitepaper, Why WirelessHART, shows a timeline with the major milestones on its successful path to ratification.

Terry noted that while the WirelessHART spec was being written, an extensive field-testing program was designed and conducted. Hundreds of prototypes were installed in actual field conditions to verify that the specification correct and workable. To make sure the standard would meet its objective, use cases of application scenarios were developed to make sure the standard could be used. HCF also donated these use cases to the ISA100.11a effort in June 2006.

Just last month, Emerson announced it is taking orders for the first products compliant to the WirelessHART standard. This comes a year and a half after the first wireless field network products became available in October 2006. Like the OPC standard, it takes time once the final standard is ratified until products become orderable and commercially available from the automation suppliers.

Like the immediate value OPC standard created around interoperability, the WirelessHART standard is making around "hard to get at" diagnostic information. I've chronicled some of the successful applications like wellhead pressure measurement and tank farms level measurement.

Other applications that have been spotlighted include railcar temperature measurement, temperature profiling, hot strip mill water flow, and remote pumping.

WirelessHART-based field networks open up possibilities to provide diagnostic information that is not practical or perhaps even possible to get at with conventional wiring. Process manufacturers are quickly realizing the value when they install these networks as these examples demonstrate.

Update: I'd also like to point out a webcast, The Range of Wireless, that Automation World magazine is hosting. It will be held April 17, at 2pm Eastern U.S. time.

I recently joined the Electronic Device Description Language (EDDL) mailing list to follow the work of this important standard. For those not familiar with this standard, EDDL.org describes it:

Electronic Device Description Language (EDDL) technology is used by major manufacturers to describe the information that is accessible in digital devices. Electronic device descriptions are available for over 15 million devices that are currently installed in the process industry. The technology is used by the major process control systems and maintenance tool suppliers to support device diagnostics and calibration.

In prior posts, I've discussed how this text-based standard makes the exchange of information from smart field devices and maintenance software and/or automation systems easy so that information from different suppliers field devices can be presented to you in a common way. These smart field devices are based on the popular digital communications protocols HART, Foundation fieldbus and Profibus. EDDL can theoretically be used with any protocol. The standard declares device parameters and their dependencies, visual representations, user interactions, and how systems access information.

Emerson's Jonas Berge is an active participant in EDDL and the ISA104 Committee and recently posted a summary of activities that I thought I'd share:

BIS test find EDDL meets NAMUR NE 105

EDDL Workshop, Frankfurt Germany, 8 April 2008

ISA Electronic Device Description Interoperability Guideline Gains ANSI Approval

ISA Electronic Device Description Gains ANSI Approval

Recent Articles
EDDL makes Foundation fieldbus easier

EDDL: Unlocking Device Information

EDDL allows interoperability for devices to constantly gather information

News/Events Archive
EDDL demo and presentation at CIA2007 in Singapore 27-30 November

ISA104 explains EDDL at ISA EXPO 2007

EDDL demo and presentation in Japan in November 2007

EDDL demo and presentation in Singapore in November 2007

Forum
Make sure your colleagues involved with bus technology and intelligent device management also join this EDDL forum. There will be more important announcements shortly.

Jonas noted to me that the first link to the BIS test (BIS Prozesstechnik--subsidiary of Bilfinger Berger Industrial Services) used devices and control systems from different suppliers to see if the EDDL meets the requirements in NAMUR recommendation 105 for field device integration in engineering tools. This tested the IEC 61804-3 standard and how it is used by device and control system manufacturers, and the advantages the new EDDL standard has for plants in the commissioning, operation, and maintenance phases of the lifecycle.

The test is described:

A wide range of device types were tested including everything from the simple temperature and pressure transmitters to sophisticated radar level transmitters, valve positioners, and frequency converters (variable speed drive) connected via HART, FOUNDATION fieldbus, PROFIBUS DP and PROFIBUS PA bus systems.

Findings include:

The study found that EDDL meet the requirements also for complex devices, further software tools are not required. EDDL wizards, images, and trend charts enable good usability and intuitive operation also for complex use cases (e.g. Partial Stroke Tests).

Jonas and those involved in the EDDL standards effort have been quite busy in communicating their activities. I hope this post helps bring some additional visibility to these efforts.

In the early days of Foundation fieldbus back in 1996 and 1997, we used to do capital expenditure (CAPEX) comparisons of installations installing Foundation fieldbus versus what they would have cost installing conventional I/O. The savings were pretty eye opening in terms of material and labor savings, commissioning time, and control room space savings.

The big part we missed, because there hadn't been enough run-time, was the much larger operational benefits available through abnormal situation prevention, predictive maintenance, and improved control.

I bring all this up because I found in RSS feeds recently the article, Reviewed resource: Profibus PA and Foundation Fieldbus--a cost comparison, on the Control Engineering website. The whitepaper was developed by the Profibus Trade Organization.

The focus of this study was a CAPEX look at the differences between Foundation fieldbus (FF) and Profibus PA installation. The report concluded that: Profibus PA devices are less expensive, one can fit far more PA devices on a segment than comparable FF devices, the links are less expensive, and PA is easier.

My initial reaction was not suitable for family reading, so I ran it by some folks, including Emerson fieldbus consultant Dan Daugherty, who is both a Foundation fieldbus expert and a Certified Profibus Network Engineer. His initial response to me was also not suitable for family reading, so I put the post I'd worked up aside for several days of calm reflection. So now, here we go...

One argument made was that PA devices cost less than FF devices due to extra memory and processing power needed in Ff. While not conceding that this is true, and not wishing to discuss pricing on this blog, I'll simply say from classic economics 101, that price is determined by the market, based on the value received and not the cost to make.

I'm not sure what automation system was considered in the analysis, but the study claimed costs associated with a "linking device" in Foundation fieldbus. In systems like the DeltaV system, the FF segment connects directly to an FF input card in the I/O subsystem, as do other buses like Profibus DP, DeviceNet, and AS-i bus. A PA device cannot be directly connected to a host system, but rather must come through a linking device. In the DeltaV system, a PA device is connected through a linking device to a Profibus DP segment.

As Dan points out, this introduces increased engineering, increased maintenance, and a higher probability of failure on demand with these additional components. This impacts both capital expenditures and ongoing operational expenditures.

Another claim in the whitepaper is that more PA devices can be put on a segment than FF devices. Dan notes that since communications on a PA segment are not deterministic, to deliver the same control update period as FF, say the 400msec mentioned in the whitepaper, it must oversample and reduce the number of devices. In this 400msec case, an FF segment can run 6 control loops (12 devices.) A PA segment would need to drop from 24 to 12 devices and sample at 200msec to achieve this 400msec control update period.

Voltage drop on a bus-powered bus is also a constraint. It's a function of the length of the segment (trunk plus spurs) and the current draw of the devices on the segment. In order to get the bus lengths typically seen in process manufacturing applications, there's little chance of ever finding 24 devices on a segment. FF can allow 16 bus-powered devices, but the typical practical loading, constrained by voltage drop (same rules for PA) usually makes 12 devices a more typical real-world implementation. Also, typical plant practices partition segments by geographic region, process criticality, and future growth capacity, which also limit segment device counts.

The easier/less-complex claim is the biggest head scratcher. PA and FF have the same physical layer so grounding and other physical installation considerations are similar. From a device-commissioning standpoint, I'm not sure what's easier than connecting a Foundation fieldbus device to a segment, having it automatically recognized by the system, and quickly commissioned into operation. When you have to introduce a linking device into the mix, it gets harder, not easier. Especially when there is RS-485 running on DP and bus-powered Manchester Biphase on PA, each requiring separate tools and linking devices.

This post could go on and on to discuss the operational benefits associated with Foundation Fieldbus in abnormal situation prevention, robustness, ongoing calibration savings and even autotuning within the device, but I think this is a good stopping point.

Automation World magazine's editor in chief, Gary Mintchell, wrote a post yesterday on his Feed Forward blog. The post, The Saga Continues - FDT v EDDL describes some of his discussions with people involved in both groups about the relative merits of their respective approaches to smart device communications. Lest I be accused of tossing around acronyms too casually, EDDL stands for Electronic Device Description Language and FDT stands for Field Device Tool.

Because I subscribe to Gary's RSS feed with Outlook 2007, I was able to forward his post much like an email message to Emerson's Terry Blevins and Tom Wallace for their views. Here is the text of their comments posted on the Feed Forward site.

From Terry:

Gary, It is good to see your interest in EDDL. As you may be aware, EDDL is the international electronic device description language standard for the process industry (IEC 61804).

Through the work of the ISA SP104 committee the IEC61804 standard was officially adopted last year as an ISA/ANSI standard. The SP104 committee worked with ISA to establish the www.eddl.org web site. At this web site you will find information on the benefits of EDDL and the advantages that EDDL has over other technologies.

In particular, you may find the paper and the tutorial that the SP104 committee presented at ISA2007 EXPO to be of help in examining this topic in more detail - please see www.eddl.org/files/ISA2007_EDDLTutorial_Presentation.pdf and www.eddl.org/files/ISA2007_EDDLTutorial_Paper.pdf.

Best regards,

Terry Blevins
Chair, SP104

From Tom:

Gary,

First, some good comments from you, thanks. I have a few thoughts to add to yours. First is a technical clarification. EDDL is the language used to write DD's. The DD is not in the device, it's in the host. Next, FDT/DTM is not used by any control host to my knowledge. It's used for asset management, therefore it's not in the DCS, the DCS usually is the path for information from the field to the FDT application. Regarding differences, because EDDL is operating system agnostic, DD's written using EDDL can reside in a handheld. FDT/DTM requires a PC level Windows operating system. As such, it won't work on devices that use an embedded operating systems such as linex, or Windows CE. Also, control hosts frequently use DD's. For example, Yokogawa CENTUM CS3000 uses EDD's to understand and use the capability of FF field devices. To my knowledge, DTM's are not used in this way. The net result is that the user will need DD's for intrinsically safe handhelds, and will in many cases also need DD's for the control host to correctly function with FF devices.

DD's will provide the functionality to perform maintenance functions on just about any HART, FF, or Profibus PA device in existence. Adding FDT/DTM where it's not needed adds to end user maintenance cost and time. Both EDD's and DTM's must be installed and maintained. Why add maintenance work if it's not needed? In addition, EDD's have been forward compatible for many years. What this means is that if a user installs a newer version of device to their plant, an older DD will work with the newer device. It may not know about enhanced functionality in the newer device, but it will perform the basics of configuration and maintenance. When it's 2AM and you're trying to avoid a shutdown, or get the plant back up, the last thing you want is to find you don't have the latest configuration file you need to configure your device. Although DTM's could be written to be forward compatible, to date most are not. I recommend users of FDT/DTM have a complete set of DD's available and on tools they use regularly so they can avoid this potential problem. There are some cases where EDDL is not sufficient, and a supplementary technology is needed. Some devices require calculation capability beyond that provided by EDDL for initial device setup. These devices usually have a separate Windows based configuration program already available to provide the added capability. DTM's have potential use here, but alternate solutions already exist. At this point I think that DD's will always be in the plant, and DD's will continue to be needed to perform functions and in environments that FDT/DTM cannot serve. One other issue I'm seeing with FDT/DTM is that it is not being used as a complementary technology to EDDL, it's being used as a replacement for EDDL to perform functions that have been and will continue to be completely supported with EDDL. These functions include device configuration and maintenance for devices that have been completely supported by DD's in the past, and continue to be completely supportable by EDDL or enhanced EDDL today. Since EDDL is an IEC standard, I am concerned about FDT/DTM, or any technology that is being used to move users away from standards, especially since the standard, EDDL will provide all the functionality needed for the vast majority of devices in all plants worldwide today. Another concern is that FDT/DTM may be slowing the implementation of the full functionality of EDDL in host systems. As such, it's not a complementary technology, but a competing one. Finally, I'd like to make a recommendation for the end user community. It strongly aligns with your recommendations, but has some additional points. The first is that the end user community encourage their host vendors to fully implement all the features supported by EDDL in their hosts. The second is that the end user community encourage their host vendors to move with speed and dedication toward the solution being worked by the EDDL / FDT/DTM working group. When this solution is available it should provide the best of both EDDL and FDT/DTM. The third is that I recommend the end user community use EDDL as their standard solution and add FDT/DTM on an exception basis. Since FDT/DTM is being positioned as a complementary technology to EDDL, I encourage the end user community to use it that way. Use FDT/DTM only if and where it provides needed functionality that is not available through EDDL.

Although I am strongly pro-EDDL, and cautious about FDT/DTM, I hope these comments have some merit, and you will consider posting them.

Thanks and regards,

Tom Wallace

If you have thoughts to share, join the conversation on the Feed Forward site or here.

Advancing industry standards remains a vibrant activity in the process automation business. These standards foster faster market acceptance of new technologies by providing interoperability among many suppliers' devices compliant to the particular standard.

InTech magazine has a nice update on one of these standards efforts, Electronic Device Description Language (EDDL) which is an extension of the International Standard IEC 61804-2. The article, EDDL allows interoperability for devices to constantly gather information, was written by ISA104 committee members, Christian Diedrich, Ludwig Winkel, and Emerson's Jonas Berge and Terry Blevins.

The authors succinctly summarize the benefit of the EDDL standard for process manufacturers:

Using this technology, it is possible to provide an interoperable environment where distributed process control systems or handheld communicator can gather information available in modern automation sensors and actuators to configure, calibrate a device, diagnose problems, and provide data and alarms for user-interface displays.

They also note that the technology is pervasive in smart field devices:

For a user to garner Foundation Fieldbus (FF) certification, EDDL is a requirement, and it is the only device description language supported by the HART Communication Foundation. Because of that, virtually every Process Control Systems vendor worldwide supports EDDL. On top of that, Electronic Device Descriptions' (EDD) are available for any FOUNDATION, HART, and some Profibus based field devices.

EDDL's text-based data structure allows it to be platform independent:

EDDL provides a well-defined structure for supporting the most simple to the very complex field device. Since EDD's are text-based interpreted by the host system, these files are independent of operating systems and control platforms. This structure allows the same EDD to have a common look and feel across applications, which reduces the learning curve and supports multiple host applications. Also, this enables field device additions to come into play without affecting the runtime stability of the control system.

The biggest benefit for users is that a consistent graphical user interface can be used to display the EDD information in smart devices, even when these devices come from different automation suppliers. The article states:

Graphical visualization supported by EDDL such as graphs and charts take full advantage of the capabilities of the host automation system. These capabilities can benefit engineers and maintenance personnel by providing a consistent look and feel during device configuration and maintenance.

Applications like Emerson's AMS Device Manager and 375 Field Communicator provide graphical views of graphs, charts and calculations into devices supporting EDDL. These views also include complex instruments such as digital valve controllers, radar level gauges and multivariable meters.

When engineering a project with Foundation fieldbus, one element to consider is the electrical loading on each segment. I received an email the other day asking:

...to find required formulas to calculate FOUNDATION FIELD BUS loading... I am using [brand X] product and I have come across a web site that you can provide information. If you have those formulas... it would be nice if you could share them.

I also did some Googling around, and saw a few things, but did not see our Emerson Segment Design Tool listed in the search results, at least not in the first few pages. The segment design tool development team released version 5 of this tool in September, just before the Emerson Exchange meeting.

Here's a bit about what this calculator tool does:
The Segment Design Tool is a Windows 98/NT/W2K/XP compatible program designed to provide a general guide for reducing the time required to engineer a Foundation fieldbus H1 segment for the DeltaV system, Ovation system and the Rosemount 3420 Fieldbus Interface. The Segment Design Tool checks the segment layout utilizing the Fieldbus Foundation's guidelines governing cable lengths, power consumption and proper segment termination. This tool now supports a variety of hazardous area protection techniques, including FISCO, FNICO and Entity Concept for Intrinsic Safety.

One of Emerson's Fieldbus consultants, Dan Daugherty, whom you may recall from earlier posts, helped me find the URL for this tool. He also added this bit of wisdom that I passed back to the person who originally emailed me:

My advice for people who can't find an exact match in the Segment Design Tool's component library for their cable or other components is to find something close and then use enough design margin that it won't matter if it isn't exact.

I'll also pass along that the segment design tool team invites comments and questions. Feel free to take them up on their offer, or leave a comment on this post, and I'll pass it along to the team.

Dr. José A. Gutierrez is Corporate Director of Technology at Emerson. As such, he not only advises our wireless experts in Emerson Process Management, but also across the other Emerson businesses.

At the recent ISA Expo, he presented the paper, Reliable Wireless: Mitigating the coexistence Challenge. His key point is that through a number of communications diversity techniques, high communications reliability on the order of 99.9% or higher is achieved. These diversity techniques are supported the IEEE communications standards and are used in the new wireless field network standard, WirelessHART.

José had quite a bit of expertise to share and has a long history of participating with many standards bodies. Some of these include IEEE LAN/MAN, editor-in-chief of the IEEE 802.15 Working Group-Task Group 4, program manager of the ZigBee Alliance, board of directors' member of the Wireless Industrial Network Alliance, and chairman of the Networking Working Group of the ISA SP100 committee.

He began his presentation by defining the term coexistence from the IEEE 802.15.2-2003 Part 15.2 standard:

The ability of one system to perform a task in a given shared environment where other systems have an ability to perform their tasks and may or may not be using the same set of rules.

Collisions and coexistence issues can happen when two or more packets overlap in both time and frequency with sufficient energy to interfere with one another. Coexistence can be measured by the end-to-end message delivery success rate overall all operational conditions.

Different country's governmental regulations address the sharing of the radio frequency (RF) spectrum in different ways. The common approach has been in assigning different bands for applications such as TV, AM and FM radios, cell phones, toys to name but a few. You can get an idea of how these frequencies are divided with the U.S. frequency band allocation chart. A personal aside--it also makes for a great eye chart!

José discussed the unlicensed bands referred as ISM bands, short for industrial, scientific and medical bands. These bands are allowed for usage in a variety of applications and in some cases with worldwide availability. Only device certification is required for use in this band. Limits are imposed on the radiated power of devices transmitting at these frequency and they require governmental certification for the country in which they operate. These bands include 900MHz (902-928 MHz), 2.4GHz (2.4-2.4835GHz), and 5.7 GHz (5.725-5.875Ghz). For you non-electrical engineers, an Hz or Hertz is one frequency cycle per second. These unlicensed bands are very crowded.

The good news for process manufacturers is that the responsibility rests with automation suppliers to get their wireless devices certified for use.

The presentation covered the various ways information could be transmitted on these frequencies. It's enough for a future post, but I'll list some of the methods here: narrow band, frequency hopping, direct sequence spread spectrum (DSSS), orthogonal frequency division multiplexing (OFDM) and ultra wide band (UWB).

Tying all this back to coexistence, the IEEE 802 standard committee is the authority on wireless coexistence and ensures that these technologies will effectively coexist with all previous technologies.

José posed the question about what wireless suppliers can do to eliminate the coexistence challenge. The solution is to apply techniques that create diversity to mitigate this coexistence challenge. These diversity techniques include:

• Path Diversity: Mesh Networking
• Frequency Diversity: Channel Hopping
• Time Diversity: Time Division Multiplexing
• Power Diversity: Power control over multiple communication links
• Space Diversity: spatial location of sensing devices (not practical for WSNs)
• Coding Diversity: Use of advanced DSSS technology

The key for wireless field networks is to use a combination of these techniques to deliver the necessary high end-to-end message delivery success rate for reliable wireless operation. These diversity solutions used in IEEE-based standards applied in industrial applications including DSSS, OFDM, and UWB and used in the WirelessHART standard help eliminate coexistence issues as one of your considerations.

You can learn more about wireless basics, the technologies, cases for how they can be applied in plant applications and IT considerations by visiting the on-line wireless courses at PlantWeb University.

While at the recent ISA Expo 2007, I had the chance to listen to Emerson's Jonas Berge's presentation on software for automation. Jonas is an active member in the ISA SP104 committee. This committee is responsible for advancing the Electronic Device Description Language (EDDL) standard.

A few years back he wrote a book, Software for Automation: Architecture, Integration, and Security. His presentation covered some of the ideas from the book. Specifically, he discussed these key points:

• Select technologies for software architecture
• Justify investment to management
• Where and how to deploy DCOM vs. Web
• Where each OPC flavor is used and how
• Integrate with business and coexist with legacy
• Troubleshoot DCOM and OPC
• Apply software and make the PC rugged
• Engineer and document software
• Backup, administer, and optimize
• Make it robust, safe, secure, and 21 CFR Part 11 compliant

The body of knowledge that an automation professional must understand to perform their job effectively continues to expand. As Jonas describes, the software architecture is as important to design as the hardware architecture. Information flows from devices connected from digital busses all the way through the automation systems to enterprise-level software applications.

Security concerns must be addressed and be part of this design. Cyber-security is an area of specialization unto itself and you can follow many of the issues and advancements at the Digital Bond and Unfettered blogs.

Jonas describes setup of networks and OPC, ODBC, and web services communications across networks and tips for troubleshooting these. One everything is functioning properly, methods of management and administration including backup and restore procedures are covered.

Jonas highlights the fact that this is a lot to plan and get right. If you find yourself overwhelmed and too busy to become an expert in this area, you are not alone. Many process manufacturers are working with their automation suppliers versed in this level of expertise to help on the project front-end and to help maintain these software packages and integration methods through their useful lifecycle. One example is Emerson's SureService support services.

For those attending the ISA Expo 2007 this week in Houston, Texas, there is quite a number of Emerson experts presenting papers. Topics being presented include: safety, analyzer integration, statistical analysis, EDDL, wireless, applied Foundation fieldbus, project justification, building automation, mesh networks, and predictive maintenance.

I'll be coming in to listen in on some of these and meet with some members from our automation blogging community.

I had a chance to catch up with ModelingAndControl.com's Terry Blevins who will be co-presenting, Keeping Systems and Communicators Up-to-date using EDDL. Here's a quick preview if this standard is something you want to learn more about. Terry also chairs the ISA104 committee that is working to advance this standard.

This tutorial explores the history of the Electronic Device Description Language (EDDL) developments, how the technology works, the benefits of the approach taken, recent advancements, how systems and communicators are changing because of these advancements, and demonstrations. EDDL, or IEC 61804-3, is an international standard and is endorsed by four major interoperability foundations: Fieldbus Foundation, HART Communications Foundation, Profibus Nutzerorganisation e.V (PNO), and the OPC Foundation.

EDDL is a text-based language that is used to describe the characteristics of field devices. Following the EDDL standard, device suppliers create Electronic Device Description (EDD) files for their smart field devices. These files provide a standardized form and structure for automation systems and handheld communicators to access and display information, independent of communication protocol or operating system.

The goal of this technology is to provide an interoperable environment where automation systems and handheld communicators for the purpose of configuration, calibration, diagnostics, and operating data and alarms for display can access information available in smart field sensors and actuators. There are more than twenty million smart devices installed in the world that have EDDs. These first began to appear in the early 1990s in HART devices, and was adopted into the Foundation fieldbus and Profibus standards in 1994. The EDDL.org site provides much more on the history and activities in the advancement of this standard.

Recent enhancements to the standard include better parameter organization, support for charts, graphs help better visualize the information in the smart field devices, and persistent data storage to convey historical information. These enhancements were approved in 2006 as a part of the IEC 61804-3 maintenance cycle.

The next phase of enhancements includes additional support for devices connect to the process including the ability to pass procedures like device setup and maintenance. Other enhancements include increase data access to databases and lookup tables, extended product information access, OPC UA information model, and support for modular devices.

The common threads through the demonstration of EDDL in action is the versatility in support from simple to very complex field devices, the independences of operating systems and control platforms, the common look and feel from an information visualization standpoint, and the ability to add devices on the fly without affecting the running automation system.

The ISA104 committee is meeting at the ISA Expo, so stop by to speak with Terry and the committee members at booth 1356 to find out more first hand.

I caught up with Emerson's Terry Blevins who has been leading the standards efforts around Electronic Device Description Language (EDDL) with his work as chair of the ISA SP104 committee. From the EDDL.ORG website:

The Electronic Device Description Language (EDDL) standard advances interoperability of devices in control systems. Integration of simple sensors through complex drives is facilitated. Device diagnostics, asset management, and user interface displays enhance reliability and performance.

Terry will be presenting a paper at this year's ISA Expo (Oct 2-4 in Houston, Texas USA) along with Emerson's Jonas Berge and other committee members from Siemens and the Institut für Automation und Kommunikation Magdeburg (ifak). This two-hour tutorial is scheduled for Tuesday afternoon.

In the exhibition area of the ISA Expo, they will be demonstrating the benefits process manufacturers derive from sensors, actuators, control systems, and handheld communicators that support the EDDL standard. These benefits come from the ability to configure, calibrate, diagnose, and provide data and alarms back to operators. Terry extends an invitation to those of you going to the Expo to stop by the ISA Booth to visit with him and some of the SP104 members. Terry also mentioned that he'd be doing a talk on EDDL at the ISA booth on Thursday afternoon.

As the paper notes, EDDL is required for Foundation fieldbus, HART, and some Profibus devices, which means that virtually every automation system supplier supports it. Some of the key advantages cited by this paper include:

• A well-defined structure for supporting simple to very complex field devices
• EDD files are text-based (not code-based) and thus independent of operating systems and control platforms
• EDD files being text based also makes switching versions, revisions, and supplier brands simpler

If you want to follow the progress of this standards effort, you can visit the EDDL.ORG website, or subscribe to their mailing list.

I also encourage you to take Terry up on his offer to visit with him and see the presentation of this paper.

Control magazine provided excellent blog coverage of the recent ISA Wireless Summit. Control's editor in chief Walt Boyes in his post, Editorial Comment! offered his review of Emerson's John Berra's speech:

I just want to add that I am floored with the honesty and accuracy of what John Berra said this morning. He is exactly right. I want everybody to read what he said, and I'm going to ask him for the text of his remarks, so I can post them as an open letter on ControlGlobal.com. I hope he agrees.

John did agree and the speech text is available on the ControlGlobal.com site. Walt has blogged frequently on the efforts and difficulties in creating standards in the process automation industry. I'll highlight some of John's points from the speech.

John began with the benefits and noted that technology for technology's sake is not enough:

But if what we do as a technology doesn't transfer into allowing plants to run better, safer...it isn't going to survive.

Lack of information can lead to situations like unplanned shutdowns:

When you dig down into what causes unplanned shutdown, you find that it is usually the result of something quite simple, that we didn't know about. Most of the incidents that occur in plants can be traceable to things like that.

He discussed how wireless allows affordable access to information and offered the example of how wireless video cameras have provided affordable security solutions. In the process industries, manufacturers have installed 20 million HART devices, but "almost nobody has invested in the wiring needed to monitor these devices together." A wireless adaptor for these devices can free the stranded diagnostics and send them back to the control system to help see more of the plant and avoid situations like unplanned shutdowns.

With regard to the path to standards, John notes how competing standards like those that we see in the consumer space with Blu-Ray and HDVD slow market acceptance and the suppliers' recovery of R&D costs. John said:

Standards increase user willingness to buy. They give us confidence the approach we're taking will be accepted in the marketplace. But mostly, standards are good for our customers. That's why Emerson has supported standards efforts for a long time. We continue to contribute people, time, money and intellectual property. Our engineers are active in both SP-100 and WirelessHART activities. We have introduced pre-standard wireless products so users can start getting experience and benefits right away - but guaranteed that buyers will have a path to eventual standards. People ought to get started.

The development of standards has historically been a challenge in the process automation industry. John notes some of the experiences with the fieldbus standards development as an example. End user involvement is critical in the process to focus the efforts around the benefits and to develop the use cases for how the technologies will be applied. John recommended:

1. Move as quickly as possible to provide practical standards at the field level.
2. Take advantage of wireless standards already in place at levels above the field sensor network, and fill in the gaps.

On the first point, John notes that the HART Communications Foundation and ISA SP-100 committee have more in common than not. They agree upon the IEEE 802.15.4 radio and mesh network technology.

He urged the SP-100 team to take advantage of the work already done by WirelessHART and focus their efforts on the remaining portions of the standard.

John also noted that that the SP-100 team has role in addressing issues outside the IT-based wireless standards space in hardening, ease of use, and plant network management.

He summed everything up:

There's no question that arriving at a standard can be a struggle. But it's not about one faction or another winning or losing. It's about coming to agreement on how to make it easier for users to put this wonderful technology to work. And if we don't succeed, we all lose. The sooner standards are in place, the better for everyone. We need to get on with it. Suppliers will sell more products, and users will get more of the results that make wireless so valuable. The wireless potential of unlocking predictive intelligence so people can have a fighting chance to make their plants run better- this is what an automation professional is standing ready to deliver, and wireless is a key to delivering those benefits.

Update: Welcome readers of Gary Mintchell's Feed Forward blog! Gary points to Automation World magazine's Wes Iverson, who has a great summary article, High Interest, Slow Adoption for Industrial Wireless which includes his take on John's speech.

Update 2: Eric Murphy,at the OPC Exchange Blog, looks at John's speech and compares it with the efforts on furthering the OPC standard. Have a read of his post, Wireless and the Familiar OPC Story and add your thoughts.

I came across an email that the ISA Honors & Awards Committee has selected the paper, Improving PID Control with Unreliable Communications, for its excellence in documentation award. Emerson's Deji Chen, Mark Nixon, Terry Blevins, Willy Wojsznis and the University of Texas, Department of Computer Sciences' Jianping Song and Aloysius K. Mok wrote the paper.

The paper examines PID control in a wireless network where intermittent loss of communications is likely to happen. It identifies the poor dynamic response of standard PID algorithms in this loss of communications scenario. The team proposed an enhanced PID algorithm to improve dynamic response under these conditions.

Terry Blevins summarized the paper well in an earlier post on the Modeling and Control blog. The post, PID Modifications for Unreliable Communications describes the situation:

One of the technical challenges is that the 2.4 GHz spectrum defined by IEEE 802.15.4 is also used by Wi-Fi and Bluetooth devices. Also, some electrical devices found in industry generate noise in this frequency band. Thus, at times it is expected that a transmission will be corrupted. To help minimize the impact of these other devices on communications, the Time Synchronized Mesh Protocol (TSMP) selected for wireless HART uses frequency hopping. Even so, at times it is expected that multiple transmissions of a measurement used in control or multiple communications of control actions to an actuator may be lost.

Terry describes how the loss of communications can cause the PID loop to continue executing and wind up due to the reset action. This reset action can be disruptive to the control of the loop. And, if the derivative (the D in PID) action is used, the loss and resumption of the control measurement signal can cause a spike, again bumping the control of the loop.

The Emerson and UT technologists worked through a solution to minimize the impact of this loss of communications. Terry sums up the change:

However, by modifying the reset and derivative calculation to account for the time since the last measurement update, then it is possible to minimize the impact of loosing multiple measurement transmissions.

If you want to look at the math behind this innovation, check out the overview presentation, PID for Unreliable Communications, given at ISA 2006.

Congratulations to the team for their contribution to furthering the advancement of wireless technologies in process automation!

Standards play an important role in fostering technological progress--both in the willingness of consumers to adopt the technologies and suppliers in developing products to meet the standards.

In our world of process automation, standards have continued to advance from base-level digital communications protocols to higher-level data communications standards for process manufacturers. The ISA-95 (S95) or IEC/ISO 62264 family of standards as they are globally known are an example of a set of data standards for the interface between enterprise planning systems and automation systems.

I had a chance to get a preview of a whitepaper that Emerson's Shenling Yang is developing around S95 and the XML-based implementation of this standard called Business To Manufacturing Markup Language (B2MML). You may recall Shenling from an earlier post on project timelines. She is now a data integration specialist in the Life Sciences industry center.

As stated in an ISA press release this past January on B2MML improvements:

B2MML was developed by the WBF's XML Working Group to provide manufacturing companies with a freely available XML Schema implementation of the ISA-95 Enterprise - Control System Integration Standard.

You can get a sense for just how detailed and comprehensive these standards are by viewing some of the schema documents available on the World Batch Forum's B2MML web page. Beyond the common schema organized around the S95 data model, other schemas exist for equipment, extensions, maintenance, materials, personnel, process segments, product definitions, production capabilities, production performance, and production schedules. Warning, these schema documents are not light reading!

On projects requiring workflow improvements and/or paperless operations, Shenling and the team follow B2MML data definitions to be consistent with the S95 standard. Because leading enterprise resource planning (ERP) systems like SAP support B2MML, Shenling finds that it simplifies connectivity and reduces the overall engineering effort for integration between the ERP and manufacturing execution systems like Compliance Suite. Ongoing maintenance is also reduced since the information exchanged between applications follows well-defined data definitions.

An example is an order coming down from SAP in an XML-formatted document complying with the B2MML Production Performance schema. The project team used transaction templates, along with the Compliance Suite support component and the process order XML from SAP to generate the actual transaction documents to be passed from the ERP to Compliance Suite. The automated parts are handled by the DeltaV Batch system and other parts of the process like materials management, laboratory information, and proof of personnel training are sent to their respective workflow processes.

The results of these workflows and batch data from the automation system are consolidated in an electronic batch record, which is a critical piece in reducing the overall cycle time on the way to releasing the product for sale.

Update: Gary Mintchell reports on his Feed Forward blog today that the World Batch Forum has announced version 4 of the B2MML standard and some of the additions to this standard. Here's the announcement from the WBF.

As reported in the Sound OFF! Editors' Blog, the ISA issued a press release announced that the ISA-SP104 committee has completed adoption of EDDL as an ANSI standard specified by IEC 61804. It is now: ANSI/ISA-61804-3 (1004.00.01)-2007, Function Blocks (FB) for Process Control - Part 3: Electronic Device Description Language (EDDL).

So if you are an automation engineer you might ask... so what? I have attempted to address this "so what?" question in prior posts, but it is something I will try again in my quest to simplify in my mind--if not yours.

The best way I can think of it is a text-based file that is associated with your smart Foundation fieldbus, HART, or some of your PROFIBUS devices in your plant. This text-based file presents its operation, diagnostic, performance analysis, operating statistics, calibration and other information in a standard, globally agreed upon way. Applications like your control system, asset management software and handheld devices that support this standard can present the information to you in a standard, intuitive way.

The analogy I have used in the past is the Really Simple Syndication (RSS) standard for publishing and consuming information across the web. Like the smart field devices, web news feeds, blogs, and other RSS-enabled content provide their information in this agreed upon global data standard. You can use RSS readers like my favorite, Google Reader, to read the information to which you choose to subscribe.

Continuing the analogy, your RSS reader presents this information to you in a common way--the look, the fonts, the shortcut keys, etc. The content can come from different suppliers' web servers, be on different operating systems, and even run with different software applications that create these standards-based RSS files.

Likewise, your application that understands the global EDDL standard (like Emerson's AMS Device Manager and 375 Field Communicator) can present the information from various smart field devices, from different suppliers, and even running different digital communications protocols. As ISA-SP104 Committee Chair (and fellow blogger), Terry Blevins said in the release:

Using tools based on EDDL can mean faster device commissioning and loop checkout, as well as reduced field trips and the elimination of unnecessary maintenance.

In an earlier post, I had mentioned the ISA-SP104 committee had established an EDDL.ORG site as an educational site. The committee has been hard at work creating educational information including basic information, participating organizations in this standard, and other news, events, and technical resources.

And, as reported this past April, the EDDL team and another smart device-based standard, FDT Group, agreed to combine efforts and work toward a unified solution for device integration that is compatible with both technologies. ARC Advisory Group sums up this collaborative effort well:

ARC applauds the collaboration efforts of the parties involved. The actions of this group will be remembered as the tipping point where practical common standards for field device integration were founded. Working toward the singular goal of easy equipment configuration and management will provide more value than anyone could have imagined.

A few weeks back, there was a conversation going in the automation-related blogs comparing HART and Foundation fieldbus. I joined the conversation in this post which included a whitepaper written by Emerson's Tom Wallace.

The post caused a few comments and a several email exchanges internally within Emerson among the digital communications protocol research and development teams, and with some of the respective foundations.

Tom has synthesized this feedback and updated the whitepaper. The changes are primarily in the order of the compared Foundation fieldbus and HART capabilities as well as the overall tone of the piece.

For process manufacturers making decisions about the automation technologies they will use to run their plants, I hope that this whitepaper along with other sources help to clarify some of aspects and differences of these important digital communications protocols.

Both Tom and I welcome your comments to further the conversation.

Emerson's Terry Blevins has been a driving force in much of the advancements in process automation. In the early days of the DeltaV system developments, he was at the heart of the Foundation Fieldbus standards development. As technologies advanced and it became possible to put advanced control algorithms in controllers rather than host level computers, Terry was again at the forefront working to add model predictive control, neural networks, fuzzy logic, and most recently continuous control performance monitoring into the DeltaV system.

Over at ModelingAndControl.com Terry shares his wisdom gained over many years for the next generation of automation and control engineers.

So why am I telling you all this? It's because today the ISA announces, ISA Standards Committee Launches EDDL Website. Terry, as the chairman of the SP104 committee, was integral in making this happen. Earlier this year, he summarized the goals of the SP104 committee well in this blog post.

He even enlisted me to seek out the EDDL.org domain, secure it, and donate it to the ISA organization. I was more than happy to help.

The EDDL.org site clearly states what EDDL is all about:

Electronic Device Description Language (EDDL) technology is used by major manufacturers to describe the information that is accessible in digital devices. Electronic device descriptions are available for over 15 million devices that are currently installed in the process industry. The technology is used by the major process control systems and maintenance tool suppliers to support device diagnostics and calibration.

Terry was concerned that information about EDDL was scattered around a number of sites including the HART Communication Foundation, Fieldbus Foundation, and Profibus International. This made it difficult for automation professionals to learn about this important standard. The goal of EDDL.org as described in the press release:

The website is a good way for interested parties to learn how to ensure long-term viability of device management solutions, protect their investment in these systems and easily keep it current, ensure security and robustness... The site also features links to training, technical articles about EDDL, online tutorials, and other related standards efforts.

Standards have played and will continue to play a key role in process automation as process manufacturers increasingly rely on the technologies to get their process operations running efficiently and being able to serve their customers better.

Automation World magazine recently had a great primer article on electronic device description language (EDDL) entitled, Device Descriptors Prove Merit. Application manager, Jim Gray, in Emerson's Rosemount Analytical Liquid division best summarized this important standard by saying:

...the most important thing about electronic device description language (EDDL) is that it makes managing process instrumentation easier.

If you're unfamiliar with EDDL, here's a short summary from an earlier news release:

An international standard -- IEC 1804-3 -- Electronic Device Description Language (EDDL) is a universal interface to diagnostic, real-time and asset management information contained in what is currently a growing installed base of more than 20 million field instruments from a host of manufacturers. With EDDL, a user can calibrate instruments, diagnose problems, provide data for user interface displays, identify process alarms, and obtain information needed for high-level software, such as MES, UI/SCADA, plant historians, asset management and ERP.

Virtually every vendor of process control systems worldwide supports the standard language and the information it describes is available in any HART Communication, Foundation fieldbus, or Profibus based instrument made since 1990.

ModelingAndControl.com's Terry Blevins is heading up the ISA-SP104 standards committee to continue to advance the EDDL standard.

I asked Jim for some examples of how this standard makes thing easier for automation engineers, operators, and maintenance technicians. As Jim sees it, the biggest advantage is that the presentation of the diagnostic and other information in smart field devices is separated from the actual data. This allows software applications to present information from a host of different device suppliers in a common, intuitive way.

The best analogy I can think of is RSS where the data resides in XML files on various websites across the internet. RSS Readers like Google Reader, Internet Explorer 7, Firefox, etc. handle the presentation of this information each in their own unique way. As a consumer of RSS feeds, it's much faster and easier to read the feeds in a common location in a common way with one of these RSS readers.

In the case of Rosemount liquid analytical smart devices like pH, conductivity, and dissolved oxygen transmitters provide EDDL files with their diagnostic, configuration and operating data and make this data available to software packages like AMS Device Manager to present the information. Like the RSS readers, AMS Device Manager presents this data in a standard way including device status, trends, gauges, and advanced device help to name a few. This is true for any suppliers' devices which support the EDDL standard. Also, other application software which supports the EDDL standard can present this information from Emerson devices which support this standard.

Jim sums it up rather nicely in the article:

The whole idea is to let the user know what is going on with the device and any actions that need to be taken, quickly and clearly, and to make configuration commissioning easier.

It's always a pleasure to highlight the work of our technologists around Emerson Process Management. It's even better when their work is recognized by ISA, a premier organization for automation professionals. Congratulations to Martin Zielinski and Carl R. Jones on their recent awards for outstanding achievement.

Martin, the Director of HART and Fieldbus technology in Emerson's Asset Optimization division, was elected to the distinguished grade of ISA Fellow for his significant contributions in the development, standardization, and deployment of digital communications technology. Through his career he has worked in the forefront of some of the automation world's leading open, interoperable communications standards including the HART Field Communications Protocol, the FOUNDATION fieldbus communications standard, and the Electronic Device Description Language (EDDL). In fact, for two years while the Fieldbus Foundation was getting started, Martin served as its Chief Operating Officer. If your automation system or asset management software is receiving diagnostic information from intelligent field devices, you can bet that Martin's leadership and expertise went into it somewhere along the line from his work on these consortia and standards bodies.

Carl, retired from and now consulting with Emerson's Rosemount Analytical division, received the UOP Technology Award for the development of process analyzer applications, particularly those used in spectrophotometry. This award recognizes an outstanding achievement in the conception, design, or implementation of instrumentation and/or process control in an area of activity covered by the scope of the ISA's Automation & Technology Department. Carl developed numerous process analyzer applications, using a full range of liquid and gas process analyzers and holds a patent for a unique electrochemical oxygen sensor and technology that speeds response time. He has contributed numerous publications and presentations serving to advance process instrumentation technologies.

We're honored to have Martin and Carl recognized for their contributions to the advancement of automation technologies which help make process manufacturers more efficient.

As I mentioned in many earlier posts, Emerson has a long tradition for supporting open, interoperable standards. A recent example is the international standard, IEC 61804-3, Function blocks (FB) for process control - Part 3: Electronic Device Description Language (EDDL) which:

...fills the gap between the conceptual FB specification of IEC 61804-2 and a product implementation. It allows the manufacturers to use the same description method for devices based on different technologies and platforms.

The ISA's new SP104 committee is working to adopt this generic device description language specified by IEC 61804. The committee recently issued a press release, ISA SP104 Committee Releases EDDL Draft for Ballot. The key benefit to process manufacturers cited in the release:

Ultimately, tools based on EDDL enable faster device commissioning and loop checkout, as well as reducing field trips and eliminate unnecessary maintenance. Benefits from EDDL-based tools match corporate strategies such as reduced maintenance cost, quality improvement, increased throughput, and reduced downtime.

From a user perspective, applications which support EDDL can display information from these smart devices using familiar dialog boxes to present graphs, charts, and trending of dynamic variables in addition to text, and archived data in a consistent, familiar format.

One of the really great aspects of the EDDL effort was the cooperation among the leading digital communications standards consortia including: Fieldbus Foundation, HART Communications Foundation, PROFIBUS Nutzerorganisation, and OPC Foundation. This cooperation will continue to simplify the dissemination of information from the devices touching the process to those who need it to improve the performance of the process and the business. Emerson continues to incorporate this standard into its technology developments, like this recent announcement for EDDL enhancements for rotating machinery monitoring.

ISA SP104 is chaired by Emerson's Terry Blevins (a fellow blogger who you can see at ModelingAndControl.com.) Terry gave me a quick update that the SP104 committee is making good progress in advancing the adoption of the IEC 61804 standard as an ISA/ANSI standard.

The news of Emerson and Siemens working together to "exchange technology that will extend interoperability and end-user benefits" hit the business wire earlier this week.

The reaction among the small but growing band of bloggers in the process automation space soon followed.

AutomationWorld magazine's editor-in-chief Gary Mintchell wrote in his Interoperability Propelled post:

In both cases, this means more ability for customers of each to integrate more systems. Definitely a win for the customers. Competitors of each of these companies have long grumbled about them being pretty much closed companies when it comes to working with others. I guess this pretty well shatters some of that thought. Good to see them opening up.

Carl Henning over at the PTO PROFIblog wrote in his Wow! Talk about giving users a choice... post:

Emerson is known for supporting Foundation Fieldbus (FF) and Siemens will add support for FF to its devices.

Siemens is known for supporting PROFIBUS and PROFINET and Emerson will support those standards in its offerings.

I'd like to make a quick point that Emerson has a longstanding commitment to interoperability. The DeltaV system and many other Emerson products have supported HART, Foundation Fieldbus, OPC, Profibus DP, DeviceNet, AS-i bus, ODBC, XML, web services, and more recently wireless and many other important interoperability standards. A quick look at this fieldbus interoperability video circa 2001 demonstrates this longstanding commitment to interoperability. Also a quick Google search on Interoperability on the EmersonProcess.com site yields quite a few results.

I caught up with Duncan Schleiss, the marketing VP for Emerson's Process Systems and Solutions business which manages the DeltaV system about this latest announcement. His view is that standards are very important as it gives process manufacturers freedom of choice. The standards must facilitate innovation allowing each supplier to provide increased value to customers. With the innovation flexibility in the standard, the process manufacturer is the clear winner in being able to choose between suppliers yet at the same time being able to select products that have clear differences. It is this innovation that drives technology that improves process manufacturing productivity and adds the most value. So while standards are good, they must endorse and allow innovation.

A final point on difficulty in achieving interoperability from a very good AutomationWorld magazine article by Jim Pinto, entitled The Dichotomy of Open Standards:

End-users continue to ask for interoperability as a means to achieve vendor independence. But that is the exact opposite of what all the primary suppliers want. Standards turn proprietary products into commodities, with lower profit margins.

As Duncan points out, if the standard provides the flexibility to innovate to create value, it is something everyone-- both suppliers and end users alike can support.

Walt Boyes, Editor in Chief for CONTROL magazine, has been closely reporting wireless technology and associated standards efforts in his Sound Off!!! blog. Some recent posts include:

Wireless-- who's to blame?
What about Wireless HART?
Are SP100 and HART Wireless Back on Track? Inquiring Minds Want to Know!
More Emerson Wireless
Bob Karshnia, from Emerson, speaks out on wireless
Emerson Declares Wireless...is it war?

Bill Morrison, Emerson Process Management Group's Director of Worldwide Marketing Communication responded to several of these which Walt posted in today's Emerson Speaks Out on Wireless! post.

A key point which Bill makes is:

Like several of our peers in the HART Working Group, we enthusiastically pursue the development of a standard. We openly share learnings gained from our trials with the Working Group. In fact, nearly 5 months ago (December, 2005), Emerson posted an open letter to the HART Foundation pledging our commitment to the donation of IP in an effort to further the standard. Our commitment to collaborate on a standard is clear, demonstrated through action.