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).
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.
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.
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!
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:
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
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.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
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.)
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.
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 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.
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.
