Technologies

I like to use the application TweetDeck first thing in the morning to quickly scan Twitter posts from the trade press and trade analysts, #PAuto (the established hashtag for "Process Automation"), Emerson folks and brands, and specialized searches on DeltaV, Emerson, and me. This helps me quickly spot news and trends going on in our world of process automation. TweetDeck is nice since it has a multi-column format for each of these tweet filters.

By using this mechanism, I discovered the Process Control Musings blog post, Roadrunner Fast. I discovered this post in the DeltaV search column from this tweet:

New blog post at http://bit.ly/JMPSA - Exploiting the new capabilities of Electronic Marshalling and Discrete CHARMS in #DeltaV V11.3

The blog's author, Bruce Greenwald, has done a number of posts about the version 11 release of the DeltaV system. What I like about his posts is his hands on approach to testing and documenting different aspects from the release. In this post, he sets up a test with Continuous Pulse Outputs in the discrete output (DO) CHARMs. He describes an example of how these pulsed outputs might be used:

So for instance, if the duty cycle was set to 5 seconds and the output of the loop was 80%, the DO would turn on for 4 seconds, then go off for 1 second. So this was great for applications that used electric heat - you could create a PID loop for temperature control with a final control element of a pulsed heater.

He describes the duty cycle specs for the DO CHARM:

The Pulse Period (duty cycle) for a DO CHARM can be set anywhere between 2 ms and 130 seconds. That wasn't a mistype - 2 milliseconds... If my duty cycle can be as fast as 2 ms, how fast can an output from DO CHARM be turned on, then off? Turns out it's 1 ms.

He shows a Fluke meter screen capture of this 1ms performance. This granularity provides an opportunity for very exact control. Bruce closes the post with how to configure a very precise digital output pulse width of 57msec.

If you have a DeltaV system in your facility, you may want to subscribe to the Process Control Musings RSS feed to be notified when tomorrow's post on counting those pulses with a DI CHARM is published.

MP3 | iTunes

Update: As promised, Bruce comes through with a post today on the DeltaV digital input (DI) CHARM, A Lot Less Blood, Sweat, and Tears for the Spinning Wheel.

Emerson's Mike Boudreaux shared a Control Engineering Asia article written by the renowned process safety expert, Paul Gruhn. The article, Providing Process Safety, analyzes some of the latest trends in safety instrumented systems (SIS) designs for the process industries.

Mike manages the DeltaV SIS brand and highlighted many of the areas in the article where the process safety system design considerations were incorporated into the DeltaV SIS system.

With respect to the size of safety applications and fit of the SIS, the author notes:

However, not all systems are 1,000 plus I/O. Some vendors therefore developed safety PLCs targeted for small I/O applications. However, using one system for small applications and a completely different system for large applications in the same facility is hardly an ideal solution (even though they may be from the same vendor). A number of vendors have recently released systems that can be small and standalone, as well as large and distributed, all using the same hardware.

Mike explained that an early design consideration was to modularize the logic solver function to be able to scale from small to very large applications. In a whitepaper, DeltaV SIS Large System Capabilities the size range is described:

Each modular logic solver has 16 channels of configurable I/O. The smallest system could have a single logic solver with only 16 I/O, but logic solvers can be added as needed - up to 30,000 I/O...

This is very different from the traditional approach where hundreds of SIFs are all placed in a single safety PLC and the effect of changing a single register or the addition of a SIF could affect all of the logic that is running. The DeltaV SIS architecture isolates safety instrumented functions (SIFs), eliminates single points of failure, and simplifies change management.

The author goes on to describe how the first safety PLC's that were designed in the mid-1980's were triplicated, but the newer systems provide flexible redundancy to better fit the needs of the process:

Flexible redundancy, all within one system, allows the system to more closely match the safety and reliability requirements for each loop in a cost effective manner.

In the same DeltaV SIS Large System Capabilities whitepaper, the flexible redundancy that is provided by DeltaV SIS is described as follows:

For increased process availability, DeltaV SIS logic solvers are also available as a redundant pair. Both simplex and redundant logic solvers are SIL 3 rated, TÜV certified. Furthermore, the architecture allows for 'flexible redundancy' - that is, put redundant logic solvers only where you need them, and they can be on the same node as simplex logic solvers. In addition to protection against random hardware failures that might cause spurious trips, redundancy also provides the ability for online replacement, online proof testing, and online firmware upgrades.

The author describes the advantages and issues with the traditional approach in having separate control and safety systems:

Control and safety systems do need to communicate with each other, and this can be done using either an industry standard protocol (e.g. Modbus, OPC), or using the same proprietary highway as the control system (often using some form of gateway)...

This traditional approach has the advantage of allowing the user to purchase what they believe to be the best of both worlds, i.e., a control system from one company and a safety system from another. However, this means the user must deal with two different vendors, learn two different hardware and software platforms, send people to more training courses, experience the frustration of getting both systems to communicate together effectively, etc.

The analysis is spot on. Connecting disparate systems together has its challenges and troubleshooting communications issues over time is another challenge that process manufacturers often face. This communications is critical for historical data capture for post-event analysis. Mike pointed to another whitepaper, Business Issues Driving Safety System Integration that highlights the integration between the DeltaV and DeltaV SIS systems:

DeltaV SIS uses the same workstations for operations, engineering, and maintenance, with a rigorous user manager to ensure that only the right people have access to safety functions. The use of a common software platform gives the operational benefits of a high level of integration of control and safety.

The author points to the downside of the integrated approach:

However, this approach also introduces more potential common cause problems (a single failure causing multiple items to fail) due to errors with hardware, software and personnel.

In the same business issues whitepaper, it highlights how this design issue was addressed in DeltaV SIS through an integrated but separate architecture:

At the same time, the hardware and networks of the SIS and BPCS are kept separate, using entirely different technologies, software, and protocols. This architecture allows each SIS controller to be a standalone, self-contained logic solver with its own pair of redundant CPUs, power supply, and I/O processor. If required, it can be installed on the same carrier as standard BPCS modules, while maintaining complete independence of power supplies, communication networks, hardware, and operating systems. Non-safety related communications between SIS and BPCS are automatically implemented on the control network without the need for mapping of tags between SIS and BPCS. All alarm handling, configuration, time synchronization, security, and device health monitoring are provided invisibly and automatically. All of the data in the SIS is available to BPCS on a read only basis. Emerson's DeltaV SIS offers separate control and safety hardware and networks along with a single set of engineering tools.

A final point to highlight in the article is with regard to diagnostics in the SIF sensors and final control elements. The author writes:

But how can a sensor communicate extensive diagnostic information on a standard 4-20mA signal? One such method is the use of Hart (highway addressable remote transducer), which combines additional information such as device diagnostics along with the standard 4-20 mA signal. Hart devices have been available for decades, but it has only been very recently that some safety PLCs have been able to incorporate Hart information directly.

These diagnostics were a key design consideration in DeltaV SIS, which has the only safety logic solver that provides direct access to HART information. Another whitepaper, DeltaV SIS HART Capabilities, summarizes these capabilities:

...to either pass on the diagnostics to an Asset Management System (AMS) or the Basic Process Control System (BPCS) or to use the diagnostics in the SIS logic. This capability has many added benefits over traditional SIS:

• The SIS can use the HART diagnostics to determine if a field device is unhealthy. If the device is unhealthy the SIS can take action to remove the device from voting or trip the system if required.
• The HART diagnostics can be displayed on detailed operator faceplates or displays to efficiently alert the operator and the maintenance group of unhealthy devices.
• Historization of HART alarms can be recorded with the same tool as the BPCS and SIS alarms.
• The alarm banner on the operator graphics can show HART alarms, which will quickly alert the operator of critical devices that are unhealthy and require greater monitoring from the operator.
• Different HART signals can be used to monitor and alarm various conditions in the field without the requirement to run separate wiring for these signals - resulting in significant cost savings.

The article covers much more ground including safety fieldbuses, certification issues, redundancy levels, human issues, and fire & gas systems and is well worth your time to read if your responsibilities include process safety.

MP3 | iTunes

Yesterday, I saw two tweets (here and here) from the ARC Advisory Group, from their ARC_Advisory twitter account. These tweets shared news of YouTube interview postings with Emerson Process Management's Chief Strategic Officer, Peter Zornio. In part 1 and part 2 of the interview, ARC's Larry O'Brien asked Peter about Human Centered Design (HCD) and how it is being applied in product development.

I sent a note to Larry this morning asking if it would be OK to embed the videos in this post and he gave me the green light. I'll highlight a few of Peter's comment from both parts of the video.

In part 1, Peter describes HCD as a method to look at the user and the tasks this user performs. The goal is to design products to simplify, reduce, and eliminate steps in these tasks. Process automation suppliers have introduced lots of great technologies, but many of these technologies are coming faster than process automation professionals can understand, use, and from which receive value. The demographics of automation and operations personnel are also causing a "brain drain", which exacerbates the situation.

Peter highlighted three key reasons for apply an HCD approach to product development to help these technologies deliver the benefits they are capable of delivering. The first is increased usability, ease of use, and less training required to take advantage of the technology. The second is the ability to embed knowledge and work practices to help less experienced process manufacturing personnel become proficient. The third is to seek out and deliver a reduction or elimination of work processes.

Peter described this HCD process beginning 5 years ago with a partnership with Carnegie Mellon University, a leader in design. This joint collaboration led to the development of a central Emerson Process Management group to work with all of the division's product development groups to instill HCD design practices.

Peter shared one example of the results of this design process, Electronic Marshalling in the latest DeltaV system release. He noted that wiring practices for conventional I/O has not really changed in the 35 years since the distributed control system (DCS) was introduced. The process of stringing "home run" cables from the process areas back to marshalling panel and then connecting the wires from the marshalling panels over to the DCS I/O cabinets has been largely unchanged. Incremental improvements on I/O density and terminal blocks have occurred, but not a look at the overall process for ways to reduce or eliminate work.

The HCD approach required stepping back, looking at what project teams are trying to achieve, and looking at ways to streamline the tasks. Electronic Marshalling combined the two practices around marshalling and I/O wire connections into a single, flexible process. As the wires are landed from the process areas, they can be characterized on a channel-by-channel basis and electronically connected with the appropriate controller. This flexible approach also means inevitable late project changes can be quickly accommodated without rewiring.

This HCD approach has been institutionalized into a Human Centered Design Institute for product development efforts across the Emerson Process Management brands.

Last week was the official unveiling of the Emerson Innovation Center in Marshalltown, Iowa. I shared insights into the event through the lens of social media. In addition to Emerson Process Management technologies used throughout this facility, technologies come from other Emerson businesses as well including Industrial Automation.

I exchanged emails with Evan Reed who oversaw the Control Techniques drives that are used in the Innovation Center, or Marshalltown Flow Lab in local vernacular. These drives are used on all aspects of the facility from environmental to process control applications. In most cases, the drives are used in standard applications--mostly variable torque fluid handling. All of the drives are connected into the plant's DeltaV control system. From any of the DeltaV operator stations, the technologists can monitor and control every drive in the facility as they perform their tests.

Evan described a few of the applications used to produce the extremely high-volume flow rates up to nominal pipe size (NPS) 36 and 240 bar (3,500 psig). The largest drive controls a 1250HP motor. Multiple pumps and compressors supply the 36" piping system with the largest drive controlling a 600HP motor.

Evan shared that a wide variety of drives are used in the lab including Commander SK, Unidrive SP, Unidrive SP free-standing, and packaged drives. During the construction phase, electrical contractors were buying the drives and putting them into enclosures. The project management team was not initially aware of the Control Techniques team's packaging capabilities. After a quick comparative analysis, the project management team found it more cost effective to buy a packaged solution. Taking this path saved time & money and help the overall project timeline.

These packaged drive solutions are developed at the Control Techniques Ft. Meyers facility. They provided packaged drives from just a few HP up to multiple hundreds of HP.

As mega-train liquefied natural gas (LNG) facilities, refineries, and newly-designed nuclear facilities require designs and technology to handle and control ever higher flow rates, the flow lab provides the test environment to develop and prove out these technologies. The goal of the innovations developed in the lab is to reduce costs and make these plants run quieter and with reduced greenhouse emissions.

MP3 | iTunes

Update: Even shared a picture which I've embedded into the post.

Update 2: I received a note from my friends in Marshalltown letting me that they're not using "flow lab" in its name, so I've updated the title and struck the reference I'd made to this terminology.

Let's close the week with a peek at a new whitepaper from Emerson's DeltaV team, Emerson Process Management's Human Centered Design Philosophy: Conquering Complexity. The team is led by DeltaV brand manager, Rune Reppenhagen. The intent of this human-centered design (HCD) focus is to eliminate unnecessary work, to reduce the applied technology's complexity, and to embed knowledge into the technology.

The advancement of technology has made advanced predictive diagnostics possible in process manufacturing facilities. The challenge is to focus this wealth of information into actionable insights for the plant operators, engineers, and maintenance staff. The whitepaper shares several examples of how products were redesigned with the three HCD tenants in mind.

AMS Device Manager has added Profibus DP device configuration and diagnostics capabilities. Work steps were eliminated to get these diagnostics into control systems like the DeltaV system. Profibus drives & motor starters and their associated diagnostics are part of the system and can be incorporated into control strategies, alarm strategies, and historical data collection. The past practice has been to hardwire or use serial connections to connect these devices. Engineering was then required to map the data into landing areas in the control system. This hurdle meant this integration was often not done. Through the HCD process, the steps were analyzed and ways to reduce the complexity incorporated.

Another example shared in the whitepaper is integrated machinery protection. Most plant turbomachinery and other rotating equipment often give advanced warning when problems develop. These warnings occur through changes in vibration levels and frequencies. Even if the machinery is instrumented with vibration and other monitoring sensors, the engineering challenge has been to bring this information into the control system to provide operators and maintenance personnel these early warning signs. By taking an HCD approach, the AMS Machinery Manager and DeltaV technologists mapped the existing process to integrate information between the DeltaV system, AMS Machinery Manager software and CSI 6500 Machinery Health Monitor systems.

Existing methods required more than 30 setup and configuration steps for each signal for an operator to see. Multiplying by the number of signals and the number of pieces of equipment it was apparent what a difficult task this was. The complexity was reduced by having the AMS Machinery Manager scan the CSI 6500 for what was available. An engineer then selects the appropriate parameters and alarms for the operator to be able to see and with which to interact. This file is then imported into the DeltaV system where the control modules and function blocks are created.

There are more examples including turbomachinery diagnostics via AMS Asset Portal powered by Meridium, DeltaV S-series hardware and I/O on Demand, and more. The common thread with all these developments was an analysis of current practices with an eye to eliminate unnecessary steps, reduce existing complexity, and embed the expertise of specialists into something that can be easily used--without requiring a mountain of engineering to climb over.

MP3 | iTunes

In my Emerson Process Management RSS news feed was news of a new wireless vibrating fork liquid level switch from Emerson's Rosemount measurement team. Not being familiar with this technology, I connected with product manager, Kevin Cullen. I asked him about this technology and how it fits in the world of liquid level sensing applications.

He first explained that there are a number of liquid level sensing technologies in addition to vibrating fork including ultrasonic, capacitance, and electro-mechanical. To understand the principle of operation, I turned to the Rosemount 2160 data sheet:

...designed using the principle of a tuning fork. A piezo-electric crystal oscillates the forks at their natural frequency. Changes to this frequency are continuously monitored.

The frequency of the vibrating fork sensor changes depending on the medium in which it is immersed. The denser the liquid, the lower the frequency. When used as a low level alarm, the liquid in the tank or pipe drains down past the fork, causing a change of natural frequency that is detected by the electronics and switches the output state to a Dry condition.

When the 2160 switch is used as a high level alarm, the liquid rises in the tank or pipe making contact with the fork, causing the output state to switch to a Wet condition.

The output state, along with other parameters, are regularly transmitted over a secure wireless connection to a Smart Wireless Gateway.

Kevin noted that these vibrating fork liquid level switches come in a range of models to address applications from very simple ones rated for unclassified areas to ones like the 2160 with advanced diagnostics rated for environments with temperatures from -94 degF (-70 degC) up to 500 degF (260 degC) and pressures to 1450 psig (100 bar g). This sensing technology is largely unaffected by liquid turbulence, foam, vibration, solids content, or coatings on the tuning fork. An adjustable delay for turbulent/splashing applications prevents false trips of the switch.

Kevin shared some of the advanced diagnostics available to spot problems with the device or surrounding process. These included external damage to the fork, internal damage to the sensor, coating buildup on the fork, and excessive fork corrosion. Alerts can be set to notify operations and maintenance of these conditions before they impact the process with a false trip condition.

The addition of WirelessHART communications is the part that Kevin said excites many process manufacturers. Most every plant, production field or platform, or mill has a need for level measurement in areas that are currently too costly to measure using wired switches, due to either inaccessibility or economics. One application example is using the 2160 for overfill protection in a tank that did not have convenient instrumentation wiring access.

Not knowing much about vibrating tuning fork technology before I started this post, I learned a lot from Kevin. I hope if you were similarly not well versed, that you did too.

MP3 | iTunes

ControlGlobal.com hosted a recent whitepaper, Guided Wave Radar vs. Differential Pressure Transmitters for Liquid Level Measurement. The paper was developed by an automation supplier, which offered guided wave radar level measurement devices. The message seemed to be that the newer technology, Guided Wave Radar, could displace much of the more established, differential pressure level measurement applications.

Since Emerson offers both differential pressure (DP) and Guided Wave Radar (GWR) technologies, I turned to Emerson's Lori Egbers, a Rosemount level measurement application specialist for her thoughts. She shared some background information that looks at the various level measurement technologies and their best application fits.

The choice of level measurement technologies is vast. This list includes both manual and continuous measurement methods such as DP, tuning fork, bubbler, dipstick, capacitance, ultrasonic, radar, sight glass, nuclear, displacer, gage glass, ultrasonic gap, hydrostatic, and weight. Obviously, for so many level measurement technologies still to be in use, it stands to reason that they have advantages and limitations in application.

One area of consideration is the application condition. Some of these conditions include levels of steam, vapors, dust, liquid density changes, pressure changes, liquid viscosity, abrasiveness, foaminess, corrosiveness, temperature range, and amount of agitation. Another area of consideration is the physical installation. Agitators, blades, baffles, and other obstructions in the vessel where level is being measured will determine the subset of available technologies.

Lori notes that both DP and GWR level measurements are considered contacting since they "touch" the process. Other level measurement technologies in this category include capacitance, magnetostrictive, and displacer. Examples of non-contacting level measurement devices include radar, ultrasonic, laser, and nuclear.

A ControlGlobal.com article, Beginner's Guide to Differential Pressure Level Transmitters offers a great description on how DP level measurement works:

Differential pressure level measurement technology infers liquid level by measuring the pressure generated by the liquid in the vessel. For example, a water level that is 1000 millimeters above the centerline of a differential pressure transmitter diaphragm will generate a pressure of 1000 millimeters of water column (1000 mmWC) at the diaphragm. Similarly, a level of 500 millimeters will generate 500 mmWC. Calibrating [ differential pressure transmitter for 0 to 1000 mmWC will allow it to measure water levels of 0 to 1000 millimeters.

The advantages of differential pressure in measuring levels are that it's reliable (no moving parts), simple, and well understood. Its use is flexible in measuring level, density, liquid interface, and mass. It can be applied in vessels with agitation and foam. DP measurement can be used in vessels with internal physical obstacles. Diaphragm seals extend DP measurement to applications with high temperatures, corrosive liquids, dirty or viscous liquids, or sanitary considerations.

DP level limiting factors include measurement errors from changing density, temperatures beyond 600degF, trickiness of high-vacuum applications, highly corrosive processes, highly abrasive processes (potentially damaging diaphragms), and liquid-only measurement. From a physical installation standpoint, the bottom-mount technology is a potential source of leakage and DP measurement often requires two taps.

How the Guided Wave Radar technology works is:

...based on Time Domain Reflectometry (TDR) principles. Low power nano-second-pulses are guided along an immersed probe. When a pulse reaches the surface, part of the energy is reflected back to the transmitter, and the time difference between the generated and reflected pulse is converted into a distance, which calculates the total level or interface level...

Lori shares many GWR application advantages including direct measurement of solids and liquids, effective interface measurement, no moving parts, and no impact to changing densities/dielectrics/conductivities. It's tolerant of foam, turbulence, heavy vapors, and condensation. From an installation standpoint, it's a better fit for small tanks, tanks with difficult geometries, small connection sizes (< 2"), and threaded nozzles. Finally, GWR is proving to be an easy replacement technology for displacer and capacitance level devices as it is very easy to swap by using the same connections. GWR is better than non-contacting radar measurement technologies for applications with heavy vapors, such as anhydrous ammonia.

GWR is limited from applications with agitators, blades, and baffles which may interfere with the probe placement. Coating on the probe from very sticky fluids may affect the measurements. If the level has an emulsion instead of clearly defined interfaces between separated liquids, the readings may not be accurate or will require more care in configuration. Finally, for taller (>50 ft) solid measurement applications, the height and associated pull forces need to be evaluated to determine suitability of GWR measurement.

I know that these are a lot of things to consider. Clearly, there isn't one specific level technology, which is appropriate in every tank. It's important to carefully consider tank and process conditions to ensure a good technology match. To help you select the right level measurement technology, Lori pointed to a Level Selection Guide. It shares the advantages and limitations of these and other level measurement technologies to help you find the best ones for your application.

MP3 | iTunes

With respect to future releases, research is a key part of the Emerson planning process. The research team asked if I'd share a new survey on control systems they are currently conducting.

The survey shares various types of process control systems with you. Each type has a variety of features, and you will be asked to select which one you would be most likely to purchase. These products may or may not exist yet, and you'll find some options more appealing and some less appealing. These questions allow the research team to understand which products are more appealing to you as a buyer and user.

Key areas they want to learn more about are system security, maintenance tools, total system lifecycle costs, integration with plant sub-systems, system setup and configuration, operator effectiveness, advanced process control, abnormal situation prevention, and price.

They survey presents a series of selections of three systems with varying degrees of capabilities in each of these areas. Through these selections, your choices help determine what's important in the tradeoff of capability versus price.

Depending on how deeply you consider the choices, the survey should take from 15 to 30 minutes. For your time and efforts, each person who completes the survey will be entered into a drawing for one of four American Express gift cards worth $250 USD each.

The survey will run through the rest of 2009 and into the first week of 2010. I hope you can find some time to share your thoughts and help influence the forward direction of Emerson process automation technology.

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 Trever Ball presented Smart Meter Verification Enhancements Improve Safety and Process Availability at the 2009 Emerson Exchange conference.

Trever began by defining terms. Calibration is performed at the factory. It establishes the relationship between flow and signal produced by the sensor. Validation confirms flow performance by comparing a primary flow standard to the sensor. Verification establishes confidence in performance by analysis of the secondary variables associated with flow. Many times these terms are used interchangeably. Also, frequently calibration or validation is done when only verification is needed.

During factory calibration, baseline measurements are performed in which the smart device can self-check against once operating in the field. For example, Micro Motion Coriolis meters check tube stiffness and Rosemount E-series magnetic flowmeters check against a magnetic field signature to perform ongoing verification.

Smart meter verification is verification on demand, whenever you want on demand or on a schedule. It provides diagnosis of the whole system including the sensor, drive, and signal processing. This verification process provides absolute confidence in measurement performance

For Micro Motion Coriolis Smart Meter verification, the Coriolis meter has no moving parts. Coating and corrosion can impact the stiffness of the meter tubes. Smart Meter verification measures the meter's mechanical characteristics so when a change in the tube stiffness is detected, performance is checked to see if it remains within factory specifications.

Rosemount magnetic flowmeters also have no moving parts and has an expectation that the meter calibration will never change. Over time, the calibration may be impacted if there is a shift in the coils due to vibration, thermal cycling, etc. Smart Meter verification measures the sensor's magnetic field strength characteristics, and when a change is detected, it determines whether the meter's performance remains within factory specifications.

A final example Trever described was the Rosemount 8800 Vortex flowmeter. The vortex sensor is a piezo crystal, which provides a low-level voltage when it is flexed. Vortices in the flow cause the sensor to pulse. The vortex electronics take the frequency of these pulses to deliver a flow output.

Historically, vortex verification has been difficult. It's become easier since properly functioning electronics can be verified by testing with a known frequency. The vortex sensor can be verified by measuring signal strength with a handheld device or via applications, such as AMS Device Manager software.

Trever closed his presentation with some quantified results of Smart Meter verification savings versus traditional maintenance and verification practices. Maintaining these flow devices within factory specification also improves plant availability, product quality, and reduces waste and rework.

MP3 | iTunes

You have to love the march of technology as it applies to handheld devices, such as smart phones. Calling, texting, tweeting, emailing, web browsing all continue to get easier. In our world of process automation, technology also advances, although not quite at the same pace. Automation suppliers need to contend with explosive and corrosive environments. To be successfully used in these environments, extensive testing and certification for intrinsically safe operation with agencies such as CENELEC/ATEX, FM, CSA, FISCO, IECEx, etc. is required.

I mention all this because a new Emerson handheld device, the 475 Field Communicator, is coming on to the scene. These handhelds began years ago with the 268 HART Communicator in the mid 1980s, the 275 HART Communicator in the early 1990s and the 375 Field Communicator in the early 2000s.

The first thing an instrumentation professional will notice in the 475 is the color display. In prior EDDL-related posts, I discussed how this standard provides a form and structure for automation systems and handheld communicators to access and display device diagnostic and setup information. The 475 color display makes these diagnostic and setup screens more quickly recognized and understood.

The other big thing is full support for HART 7, which includes WirelessHART. The 475 provides configuration, device diagnostics, and advanced troubleshooting for HART, Foundation fieldbus, and WirelessHART devices.

I asked brand manager, Alan Dewey, to name some other key improvements over the 375. The size and weight are reduced to make it easier to carry and use around the plant. Battery life doubles both in use and in standby. Alan mentioned that usability was also a focus for the design team and they reduced boot up time and device display call up times.

With Bluetooth becoming prevalent in PCs, it made sense for the 475 technology team to add this protocol to provide fast, secure data transfer with the AMS Device Manager application on the PC and the Easy Upgrade Utility (which helps users keep their communicator up-to-date with the latest system software and device drivers). Like the 375, Infrared (IrDA) communications is also available, but the transfer rate is doubled.

I hope to see a few "YouTube unboxing" videos out in the wild as instrumentation folks get their hands on these. You can bet I'll have my RSS search going to be on the lookout!

MP3 | iTunes

Update: Added link to the 475 Field Communicator site.

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've gotten some feedback from some Emerson sales people in the different world areas that some fear, uncertainty and doubt (FUD) is being spread about the DeltaV system. The FUD goes that it's an "old" system.

This was once a very powerful argument before the days that all automation suppliers adopted commercial off-the-shelf (COTS) technologies in their systems. This is because the automation supplier had to design, test and support a greater proportion of the hardware, firmware and software required. This made "playing catch-up" more difficult.

I went and blew the dust off the initial sales binder (back in the days when sales binders were used) to see what the specs were on the Dell PCs used the engineering and operator workstations for the first DeltaV release.

I'm pleased to report the Moore's Law about functionality doubling every few years is alive and well. Check out these "powerful" specs from 1996:

• Microprocessor - Pentium, 166Mhz
• RAM - 32 Mb
• Cache - 256 Kb
• Drives -4X CDROM, 3.5-inch floppy, 1 Gb Hard Drive
• Operating System - Microsoft Windows NT 3.51
• Ports - 1 Parallel, 2 Serial, 1 or 2 10BaseT Ethernet
• PC Options - 28.8 FAX modem
• Display Resolution - 1024 x 768

Wow, my Mobil PC phone has more processing power and storage.

Today's DeltaV workstations are continuously updated based on the latest configurations from Dell. Right now, they are at 2.33 GHz Core Duo Intel microprocessors, 2 Gb RAM, 80 Gb hard disks, etc.

If your plant has DeltaV v1 software on the original hardware, it is indeed old. If you're running the current version, v9.3, you'll see something completely different. The first is the growth in capacity. It grew from 500 I/O in its initial release to a size that is currently operating:

Across the 10 plants and utilities there are over 48 000 control loops, with about 166 000 I/O tags and around 25 000 points hardwired to the automation system. There are 40 000 instruments and some 13 000 intelligent devices networked in the world's largest Foundation Fieldbus installation.

A few other things that have been added along the way, taking advantage of Moore's Law and COTS are embedded advanced control and simulation, integrated batch, Foundation fieldbus and other digital communications busses, safety instrumented systems, and enterprise integration and security.

Version 10 release of the DeltaV software is coming later this year that will add innovations in engineering productivity, hardware performance, wireless connectivity, SIS, operating systems, batch and more.

I share all this because the only thing old is the FUD you may hear.

Update: Welcome readers of the Industrial Automation Insider newsletter. I invite your comments on Andrew Bond's recap of this post in the newletter's September 2008 edition. Also, if you're going to be at Emerson Exchange later this month, make sure to see Andre Dicaire's presentation on the historical timeline of DeltaV controller improvements. I'll try to catch this one and blog it for those who can't join us.

I've seen a number of stories about applications for wireless transmitters, but not for wireless valve monitoring. That all changed earlier this week when I received a Twitter direct message "tweet" from a colleague. For those not yet on Twitter, it's an option to send direct communications, unseen by others, when you have a reciprocal follow relationship with one another. It's like instant messaging but comes with the stream of others' short notes in your follow list. I have it set up where these direct messages come as text messages to my phone as well. I mention all this because it's another way communications are rapidly evolving from the world of email in which we've lived over the past many years.

The Valve magazine article, The Reliability and Security of Wireless Valve Monitors, is written by Emerson's Kurtis Jensen, an instruments product manager for Fisher and Valve Automation products.

One of Kurtis' closing paragraphs provides the primary reasons process manufacturers may consider wireless monitoring on some of their valves:

Most operations have a large number of "blind valves" that are either manual or semi-automatic but provide no valve position feedback, normally because of cost or location. As such valves age, their performance can degrade to sluggish, slow operation. The true position of the valve may be questionable, and operators have to start visiting certain trouble-prone valves to verify their position. Where valve position monitoring does not currently exist, wireless monitoring is a great way to start using this technology with minimum risk."

If you've ever come across the ModelingandControl.com blog, you'll know that sluggish valve performance is a contributor of deadtime that impacts overall control performance and plant efficiency.

As with any newly introduced technology, its ease of use is critical in its adoption. Kurtis notes that an upcoming release of a wireless position monitor product is non-contact and does linkage-less position sensing. After attaching and calibrating the device, it sends valve position information wirelessly across the self-organizing network to the automation system or asset management software.

He discusses some of the reliability and security aspects that I've described in earlier posts. The reliability aspects are largely to do with the self-organizing nature of the WirelessHART field networks. Alternative communications paths are taken from the devices to the wireless gateway when permanent or temporary obstacles happen.

Security is addressed in the WirelessHART standard and described by Kurtis through its changing encryption, message authentication, data verification and frequency hopping.

An important point made is that, "...wireless should not be viewed as a direct replacement for wired instrumentation." It's well suited for:

...hard-to-reach locations, in areas hazardous to plant personnel, where power does not exist and where running wires is not allowed or prohibitively expensive, to name a few.

This certainly opens up opportunities in many facilities to reduce the number of blind spots the operations staff face that must be covered by periodic manual inspection. The opportunities for wireless monitoring may be with the valves were early notification of performance degradation can help avoid overall poor control performance.

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.

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.

I was reading the great Control magazine article, Data Analytics in Batch Operations, by Lubrizol's Robert Wojewodka and Emerson's Terry Blevins. It describes the challenges in applying on-line analytics in batch production for early fault detection and prediction of end of batch quality parameters. If done right, this can help avoid out of spec batches, waste and rework and the opportunity cost of the lost batch. This can be critically important in specialty chemical and pharmaceutical manufacturing, which in the words of the authors, "depend heavily on batch processing to produce low-volume, high-value product."

The reward is great if you can make these on-line analytics work but the challenges are great. One of the biggest is the time differences between batches. Operators and events can halts and restarts to process. These may be for manual additive additions, waiting on common equipment to become available or abnormal conditions that may develop.

Another challenge is that online measurement of quality parameters "may not be technically feasible or economically justified." These lab samples must be available to online analytics toolset to perform these analytics.

Other challenges they noted included variations in feedstocks, varying operating conditions, concurrent batches and the assembly and organization of the data.

The concept of "Golden Batch" has been around a long time, which is the concept of comparing batches in progress, or just completed with ideal ones from the past. The authors point out two big weaknesses with this approach. The first is conditions indicated by each measurement may affect the product quality in different ways. Secondly, this is a univariate approach to a multivariate problem--no knowledge is gained of the relationships of process variations.

In a prior post, I've discussed some of the analytic tools, PCA and PLS. By applying these online, "...changes can be made in the batch to correct for detected faults or deviations in the predicted value of key quality parameters."

I mentioned to Terry that I gave this article a close read and was working on a blog post. He told me the really innovative thing they were able to do was to apply dynamic time warping (DTW). The article describes its use:

...allows such [batch time length] variations to be addressed by synchronizing batch data automatically using key characteristics of a reference trajectory.

This normalization process is covered in detail in the Greg McMillan and Mike Boudreau's book, New Directions in Bioprocess Modeling and Control and discussed in the article, PAT Tools for Accelerated Development and Improvement.

It's hard to give the article justice in a short blog post, so if you have 18 minutes and 30 seconds to spare, watch to the interview Walt Boyes did with Bob, Terry and Philippe Moro at last year's Emerson Exchange.

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.

Automation World magazine's Wes Iverson recently had a nice article, The Great Safety Debate. He described the various approaches to safety instrumented systems (SIS) and their connections with basic process control systems (BPCS). The article highlights where the SIS suppliers products fall in the ARC Advisory Group's four categories of SIS: separate, interfaced, integrated and common.

Separate defines complete separation between the BPCS and SIS. Interfaced defines a connection via a gateway using OPC, MODBUS or other communications method to share information, particularly at operator displays. Integrated defines a closer connection perhaps sharing common engineering tools, operator displays, alarms, etc. Common defines a single box does both control and safety.

The article references ARC's viewpoint:

...integrated control/safety systems as one of its "top automation technologies and trends to watch in 2007."

Emerson's Chuck Miller, whom you may recall from earlier process safety-related posts, described DeltaV SIS as being part of the integrated category. He's quoted:

In the Emerson architecture, "our safety and control systems are completely segregated in all the ways that count," says Miller. "The operating systems are different. The hardware is different. The only thing we do share are engineering tools, and even those are password protected for all safety integrated functions," Miller points out. And while integrated DeltaV SIS and DeltaV systems are linked with a dedicated communications channel for information sharing, that link is one-way, he adds. "The SIS sends information out to the BPCS, and while the SIS can see information from the BPCS, that information does not alter the safety instrumented functions implemented in the SIS."

Chuck also added:

"You no longer have to map your safety system into your DCS via Modbus or OPC. You no longer have to run a separate bus for time synchronization to the different subsystems, and you no longer need a stand-alone sequence-of-event system," he explains. "All of those functional subsystems are built into our integrated BPCS/SIS environment."

The article did point offer critiques by suppliers of other suppliers' approaches. The SISs in the separate and interfaced categories point to issues like common mode failures, inadvertent changes in SIS and reliance on functional or logical separation instead of physical separation. The article references that some have called this FUD, as did a blog post from last year, which I confess caused me to LOL.

As the article noted:

Various integrated safety/control systems are on the market today that have met this requirement, say their vendors, as evidenced by certifications received from TÜV [hyperlink added], an independent international certification organization. And once a system is TÜV-certified as meeting international standards for use at a specific safety integrity level, or SIL, that should end any debate, these vendors contend.

If you're looking to address your organization's IEC 61511 safety lifecycle requirements, this article is worth a read to understand the various SIS approaches and critiques of these approaches.

Update: I received an email from DeltaV SIS Product Manager, Mike Boudreaux who notes that beyond the engineering tools, the operator station (HMI) software and asset management software (AMS Intelligent Device Manager) are also shared by both the DeltaV system and DeltaV SIS.

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.

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 wrote this post while on a flight back from a meeting in Rome. As an engineer, one can't help but be inspired by the buildings and architectural wonders created by the engineers in the Roman Empire. Talk about built to last!

I think about engineers today who worked on this mobile smartphone I used to compose this post while on the plane. These phones have a life span of a couple of years at best. I saw a colleague with a newer version of my model. It includes a global positioning system (GPS). He downloaded Google Maps and it automatically connected with his GPS. This is not only cool, but also very useful as it gave real-time positioning information as we walked the streets of Rome.

Imagine the contrast of old and new as we used it to find historic monuments like the Pantheon. Here is something with a life span of a few years to find something that has lasted thousands of years.

Thankfully, in our world of process automation our work may live on a decade or two. These systems are not without change as the hardware and software continues to advance. These systems take advantage of the work of really smart engineers who keep advancing the technology.

I tie this all back to a press announcement of four really smart Emerson engineers, Terry Blevins, Deji Chen, Mark Nixon, and Willy Wojsznis receiving an excellence in documentation award from the ISA. The award was for their ISA EXPO 2006 technical paper, Improving PID Control with Unreliable Communications.

As part of the DeltaV technology team, they have played a major role in some of the innovations automation engineers around the world use every day to improve their process operations and their business results.

A sample of the innovations include Foundation fieldbus, OPC, on-the-fly process modeling for real-time control performance, EDDL, embedded MPC, fuzzy logic, neural network with the other common control block.

Congratulations to Terry, Deji, Mark, and Willy on their award and helping to advance the craft automations engineers apply.

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.

At last week's ISA Expo 2007, Emerson's Gary Law received the Douglas H. Annin award. This award is award is in recognition of Gary's outstanding technical achievements in the design, development and application of automatic control systems. The ISA describes this award:

The Douglas H. Annin Award recognizes an outstanding achievement in the design, application, or development of the components in an automatic control system from the input measurement through the final control element. The award is in honor of Douglas H. Annin, a pioneer in modern-day control valve actuation and control valve body design.

I've known Gary for many years in our work advancing the DeltaV system. He is now a technologist with the DeltaV architecture team. He is responsible for the system architecture, and future developments of DeltaV system and PlantWeb architecture.

Gary was instrumental in the design and introduction of the DeltaV SIS (safety instrumented system.) He was a part of eight different patents for this development and holds more than a dozen overall through his career. This Douglas H. Annin award was recognition for this innovation. Specifically:

For design and development of a safety instrumented system logic solver that is built into a basic process control system input/output card.

DeltaV SIS was the first SIS to take advantage of smart instruments (sensors and final control elements) used in safety applications communicating via the HART communications protocol. The diagnostics from these instruments can be used to monitor continuously the health of each safety instrumented function (sensor + logic solver + final control element.)

In earlier posts, I've discussed some of these innovations and their application. These include performing partial stroke tests automatically within the safety instrumented function, separation between control and safety systems, and the ability to do complex safety shutdown sequences.

Scalability is another key aspect that was brought to safety instrumented systems with the design of DeltaV SIS. Logic solvers are added in small increments (16 I/O channels) for process manufacturers' SIL 1-3 safety instrumented functions. The hardware, software, and communications running in the logic solvers are different from the DeltaV automation system, but the configuration software is the same. This design provides the separation proscribed by the IEC 61508 global safety standard.

Much of the innovations in the DeltaV hardware and its interactions with the configuration software are thanks to Gary's efforts. You can see some of his enthusiasm in the digital bus videos created several years ago.

Congratulations to Gary for this recognition of his work to advance the state of technology in our world of process automation.

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.

Earlier I mentioned Emerson's Dean Taggart's work with complex sequences in safety instrumented systems, based on an ongoing oil sands gasification project. John Kingston, from Emerson local business partner Spartan Controls, is presenting on this topic along with Emerson's Chuck Miller at the upcoming ISA Expo 2007.

I received a copy of the submitted paper that, among other things, explores the separation between basic process control systems (BPCS) and safety instrumented systems (SIS). Historically, the SIS was a separate entity, but with technological advances, this has begun to change. The authors note that the IEC 61508 international safety standard does not provide a definition of separation. It does mention physical separation as a highly effective technique. Given that the standard is much more performance-based than prescriptive-based, they note that there are few statements defining separation.

The paper refers to a few specific clauses in 61508-1 such as 7.5.2.4, where when the control system places a demand on one of the safety-related systems, then it "...shall be separate and independent" from the safety-related systems. In order to satisfy this clause the control system must be proven sufficiently independent from the SIS. Certification agencies like the various TÜV organizations and other third-party testing labs help provide this proof for SIS suppliers per the IEC 61508 performance standards.

61508-1 Clause 7.6.2.7 addresses common cause failures by requiring functional diversity, technology diversity, diverse parts, services, and support, and that the BPCS and SIS not share common operational, maintenance, or test procedures, and that they be physically separated. Safety instrumented systems like DeltaV SIS address these in the authors' words:

Those factors [governing independence] include diversity, which essentially means that the BPCS and SIS should have different components, operating systems, chip sets, central processing units, etc. When looking at sharing parts, services, and support systems, once must ensure that the BPCS and SIS have different power sources, and that a safety network dedicated to safety related communications is used. They should not share test procedures, which means that if you are testing either the BPCS or the SIS, that those tests should be able to be run completely independently of each other. Finally, physical separation applies to how the architecture of the system is laid out, and how cabinetry is designed; in essence, this is where one would look at separating DCS cabinets from SIS cabinets, and perhaps maintaining the SIS from a different workstation than the one used for the BPCS.

A final clause that is discussed, 61508-2 Clause 7.4.2.3 explores how non-safety functions implemented in an SIS need to be treated as safety-related unless it can be shown it is sufficiently independent (that the failure of any non-safety-related functions does not cause a dangerous failure of the safety-related functions.) This implies that control and safety functions can exist within the same system as long as sufficient care is taken in design and throughout the IEC 61511 safety lifecycle.

The authors summarize the implications of separation well:

Essentially, everything all boils down to good engineering designs and practices. One must consider the standards carefully, and understand the implications before going down a certain path. One cannot simply look at a system and know if it satisfies these requirements, because almost every system has a different level of independence. One must look at the specific details of a system to verify that it satisfies the requirements.

Dean summed up how these applied to the asphaltene gasification project:

The complexity of the process led to a need for integration as well as separation. Integration brings the benefits of integrated development and operating environments, less training cost, simpler architectures, faster and more reliable communications, reduced integration time, better handling of status information, and improved fault handling. The safety requirements of gasification focus on preventing damage to the burner, reactor, and syngas cooler, as well as operator safety. The process itself leads to the need for an intricate startup, as well as multiple methods of shutting down the process depending on the current state. An integrated but separate solution can provide several advantages while still providing the required amount of separation.

Austin, Texas is where I call home and is home to some of the leading technology providers in the world. I recently had lunch with a colleague at Freescale discussing life and business here. The brains in much of the DeltaV hardware is powered by Freescale microcontroller chips. For those not close to this industry, Freescale is a 2004 spinoff of Motorola's semiconductor business.

I spoke with some of Emerson's DeltaV technologists responsible for hardware design and they described the history of working with these microcontrollers all the way back to the early 1980s with the Motorola 6801 and 6802 chips. Around this same time, I was working with the 6809 microprocessor chip in my days as an electrical engineering student at the University of Texas. The 6809's assembly language is now only a distant memory.

As Moore's Law predicted, the rapid exponential advances in performance over this twenty-five year span have certainly helped increase the capabilities within automation systems and have reduced the need for many separate host computer-level applications. These applications have migrated into the automation systems where they can run in robust, industrially hardened and redundant environments.

Some of the current generation of microcontroller chips like the Freescale MPC8360E can provide the processing capabilities to handle even more complex model predictive control algorithms, adaptive control, sophisticated phases/operations/unit procedures/procedures for batch processes, and other complex applications. These innovations continue to find there way into each new DeltaV release.

Over the years, it has been beneficial to have DeltaV technologists located in the same city as the Freescale design team. When issues arise, they can be discussed people who have met and gotten to know one another. These relationships can help improve the quality of future designs and supporting tools and documentation.