Ian Verhappen, P.Eng.
Ian Verhappen, P.Eng. is an ISA Fellow, ISA Certified Automation Professional, and a recognized authority on Foundation Fieldbus and industrial communications technologies. Verhappen leads global consultancy Industrial Automation Networks Inc., specializing in field level industrial communications, process analytics and heavy oil / oil sands automation.
The present version of the IEC 61158 standard includes 19 different protocols. However, while at an ISA meeting recently, I was approached by a Japanese organization about the addition of another, so I believe we will soon be up to 21 protocols in a single standard — and this is only for industrial processes.
One important part of machine safety is the associated electrical approval for installation in operating environments. A new standard from IEC — IEC 61010-2-201, “Safety requirements for electrical equipment for measurement, control and laboratory use” — will impact the way these approvals are made and, therefore, is something that is likely to affect the way you specify and purchase control equipment.
Is “Configurable I/O” making fieldbus technology obsolete/redundant? My definition of Configurable I/O is a termination assembly that has sufficient flexibility so that the individual signal termination (typically the pair of wires connected to the field device) is independent of the I/O card residing in the backplane.
I am still waiting to see the ‘killer application’ for wireless sensors, though some of the work being done in the areas of RFID and passive wireless sensors is likely to drive this breakthrough. Many of today’s applications are simply using wireless networks to replace wires, without thinking, “what else can I do without my tether?” The presenters and participants at the third annual Passive Wireless Sensor Workshop sponsored by the ISA Communications Division in May 2013 are working on that question.
Though only mentioned in my last column, the Field Device Initiative (FDI) is continuing to move forward. The reason this is important is because I estimate that 95 per cent of the field devices used in the process industry are based on DD technology.
HART, Profibus and Foundation Fieldbus are all based on DD technology and these groups are working with FDT and OPC to have the resulting documents out for IEC ballot as Committee Draft for Vote with the expectation for publication early next year, with products released at approximately the same time. As always, one challenge of releasing products is coordinating the timing of field devices and host systems to support the new capabilities. It is this factor that will drive the timing for use of FDI in the plant environment. Let’s have a look at what has led to the development of EDDL and just how FDI will change the way we interact with our field devices.
As a declarative language, EDDL describes the capabilities of the field device, leaving it to the host system to determine how to access all data and properties of all devices. As a result, EDDL tends to be used for device configuration with limited graphical support conducive to maintenance activities. Hence, the FDT organization developed DTMs. FDT is independent from any communication protocol and the software environment of the host system.
A device DTM can be used to access device parameters, configure and operate the device and diagnose problems. A second DTM, called a Gateway or Communications
DTM, is used to connect to the device DTM and handle protocol transformation.
A key group in the development of FDT and recent additions to EDDL technology is the NAMUR organization of end user manufacturers. The recommendations in its document NE105, “Specifications for integrating fieldbus devices in engineering tools for field devices,” was one of the guiding documents identifying the requirements for FDI.
So what is FDI, beyond another acronym to learn? The core of FDI technology is the scalable FDI package containing up to four different elements. The FDI package is a collection of files: The Electronic Device Description (EDD), based on
Electronic Device Description Language (EDDL, IEC 61804-3), includes the device definition (Def) that serves as the information model of the device and describes the device data and type; business logic (BL) outlines the rules for accessing the device data and any dependencies and is used to define if and how the data may be viewed when interpreted by the server; and user interface description (UID). The optional user interface plugin (UIP) offers the advantages of freely programmable user interfaces based on Windows Presentation Foundation (WPF) used by FDT as software components that define special device functions/application information and user interfaces to run on the client.
Attachments are also optional and include things like product manuals, images and electronic certifications. To prevent inadvertent errors, a number of safeguards are built into the protocol so that if there are EDD constructs (including built-in functions) that are not known to the FDI Server, the execution of the business logic shall be cancelled and if the FDI client’s UID Interpreter is not able to interpret and/or visualize a part of the UID, the user shall be informed that the resulting information is likely invalid.
The device manufacturers define via the FDI Device Package which data, functions and user interfaces are stored on the FDI Server. This makes version management of FDI packages much easier as they are managed centrally within the FDI Server.
Device packages created by device manufacturers will be certified and registered by their respective technology foundation, so it will still be best to verify the device package you are using on the relevant technology foundation approved lists on their website.
Because the EDD, DTM and new FDI Package exist only on the computer, not in the device, it is possible to migrate from DTM or EDD to FDI without changing the devices, thus protecting the existing investment of your field devices. However, one of the requirements of FDI is that the major revision of all clients, servers and packages in a given system shall be the same. FDI servers support all FDI packages following the same version or lower.
FDI clients can typically be connected to FDI servers that are implemented following the same FDI technology version or higher.
An FDI client may access multiple devices, while User Interface Descriptions and User Interface Plug-ins may only access a single device. FDI clients can communicate with the FDI server through proprietary protocols; however, if the FDI server supports third-party FDI clients, it shall support OPC UA as well so that generic OPC UA clients with no knowledge of FDI can connect to the FDI server.
The comprehensive set of services provided by OPC UA enables the “how” of system integration while the basic building blocks of the “what” of system integration are defined by OPC UA’s an extensible object model. OPC UA services act on an object model, which is managed by the server and discoverable by a client. Information is conveyed using standard and vendor-defined data types, and servers define object models that clients can dynamically discover.
Though an FDI communication server can be embedded within a communication device or can be provided via a separate server, the FDI server is usually distinct from the servers that provide run-time data to the operator, engineering and maintenance stations.
Though it appears that FDI will be more complicated than the EDDL we are using now, a lot of effort is being made to hide this complexity from the end user by providing an integrated graphical environment in which it will no longer be necessary to become protocol experts to keep your devices working and THAT is always a good thing—and a definite upgrade from today.
This article originally appeared in the June 2013 issue of Manufacturing AUTOMATION.
The industrial networking environment is continuing to evolve with additions to protocols, new tools and, with the Field Device Initiative (FDI), even amalgamation to some extent. However all the ‘buzz’ continues to be about wireless and cybersecurity, which is relevant regardless of the network you are operating.
Many of us forget that cybersecurity is about more than the network but starts with policy, procedures and physical access. With wireless, physical access includes managing your wireless footprint. This includes such things as the power levels of your transmitters and gateways as well as, if used, the associated antennas.
There are a number of open source tools to help you manage the footprint of your wireless network including:
• Netstumbler (Netstumbler.com), one of the original wireless network tools that was often used by hackers to find networks while roving.
• Netsurveyor (www.performancewifi.net/performance-wifi/main/NetSurveyor.htm), which is similar to Netstumbler but also has a recording/playback feature and comes with ‘add ins’ such as NetStress, which is a comparison tool to see how your network is doing over time.
• CommView for WiFi, which allows you to capture packets and then search them for specific strings and packet types. This is the wireless version of Wireshark (wireshark.org) for wired networks which, rather than gathering data on the network layer, allows you to diagnose problems in other layers as well.
• inSSIDer from Metageek (www.metageek.net/products/inssider/), which is similar to Net Stumbler and is designed to detect wireless networks and report on their type, maximum transfer rate and channel usage. InSSIDer includes graphical representation of each wireless network’s amplitude and channel usage
• Azulstar developed Wireless Wizard (www.azulstar.com/support/wireless-wizard/) to provide a series of diagnostic tests to see how well your wireless network is performing. More commonly used on ‘the home front,’ it also includes a spectrum analyzer that recommends the best wireless channel to use.
Staying with the “Open Source” concept, there is also an “Open source” antenna, or cantenna as it is affectionately known, with instructions available from a number of web sites. The cantenna was the created in July 2001 from an empty Pringles chips can and hence the name. The cantenna is a directional 2.4 Ghz wireless network 12dB yagi antenna, with a collector rod assembly, compatible with 802.11b and 802.11g wireless networks.
Open source is also coming to our assistance on the cybersecurity side with a test suite from the Open Information Security Foundation (OISF). OISF has created an Open Source Intrusion Detection and Prevention Engine called Suricata. The United States Department of Homeland Security’s Directorate funds Suricata for its Science and Technology HOST (Homeland Open Security Technology) program, the U.S. Navy’s Space and Naval Warfare Systems Command (SPAWAR) and other consortium members.
The Suricata Engine and the HTP Library, an HTTP normalizer and parser written by Ivan Ristic of Mod Security are available to use under GNU General Public License (GNU GPL) version 2. The HTP library is required by the engine integrates and provides very advanced processing of HTTP (Hyper Text Transfer Protocol – the same protocol used to read/display web pages) streams for Suricata. Suricata is available for download at www.openinfosecfoundation.org/index.php/download-suricata.
One more tool to help you manage your network is Network Diagnostic Tool (NDT) (www.internet2.edu/performance/ndt/) which is designed to quickly and easily identify a specific set of conditions that are known to impact network performance. NDT does this by performing the following tasks: simple bi-directional test to gather E2E (End To End) data; gather multiple data variables from the server; compare measured performance to analytical values; and then translate network values into plain text messages for interpretation by yourself or your network administrator.
This article originally appeared in the May 2013 issue of Manufacturing AUTOMATION.
Seminar: Innovative Technologies and Applications for the Industrial Flow MarketTuesday, 04 November 2014Read more