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.
All of us are aware of the amount of data available from modern control systems, their field devices and the algorithms used to infer additional information from that data. The challenge is managing and understanding that data by converting it first into information that we as humans can understand, and then into knowledge upon which we can take appropriate actions.
We have learned a lot about how to display data since the introduction of the DCS and computer displays in the 1970s, when the display was a colour version of the Piping & Instrumentation Diagram (P&ID) with key process values shown numerically and electronic versions of strip charts to allow operators to observe process trends. We then “progressed” to Windows-based HMIs with even more distractions of spinning pump impellers, fluidized beds and all the wizardry of computer gaming at that time. Fortunately, research has shown simplicity and low-key use of colour is better, with this information being codified in the work of two ISA standards committees: ISA18—Instrument Signals and Alarms and ISA101—Human Machine Interfaces.
From its purpose and scope on the ISA web site, the ISA18 committee “develops standards, technical reports and guidelines for alarm systems including annunciators, process automation systems and the general development, design, installation and management of alarm systems in the process industries. They do so by establishing terminology and practices for alarm systems, including the definition, design, installation, operation, maintenance and modification and work processes recommended to effectively maintain an alarm system over time.”
In addition to updating the 2004 revision of the ISA18.1 standard on ‘Annunciator Sequences and Specifications,’ it is focused on the development of a series of technical reports on ‘Management of Alarm Systems for the Process Industries’ as part of the ISA18.02 standard set.
Each of the six working groups are developing reports as follows:
• WG1—Alarm Philosophy: Provides guidance for successful management of the alarm system. The resulting work will cover the definitions, principles and activities by providing overall guidance on methods for alarm identification, rationalization, classification, prioritization, monitoring, management of change and audit.
• WG2—Alarm Identification and Rationalization: Addresses the processes to determine the possible need for an alarm or a change to an alarm, systematically compare alarms to the alarm philosophy and determine the alarm setpoint, consequence, operator action, priority and class. To accomplish this work, the resulting outputs will address the identification, justification, prioritization, classification and associated required documentation for the creation and maintenance of individual alarms and associated support systems.
• WG3—Basic Alarm Design: Covers the selection of alarm attributes such as types of alarms, deadbands and delay times. Because each control system has different capabilities with respect to alarms, the resulting implementation of this work may be specific to each control system.
• WG4—Enhanced and Advanced Alarm Methods: Will provide guidance on additional logic, programming, or modeling used to modify alarm behaviour. The resulting tools to support advanced alarm methods will likely include dynamic alarming, state-based alarming, adaptive alarms, logic-based alarming, predictive alarming, as well as a number of approaches to logically implement designed suppression of redundant and condition-based alarms.
• WG5—Alarm Monitoring, Assessment and Audit: Focuses on monitoring, assessment and audit for the continuous monitoring, periodic performance assessment and recurring audit of the alarm system to keep system and operator performance from deteriorating over time. Fortunately, many modern alarm systems contain the tools to assist in this activity already.
• WG6—Alarm Design for Batch and Discrete Processes: Providing guidance on the application of alarm design of batch and discrete processes.
Similar to ISA18, the ISA101 committee’s purpose and scope are to establish standards, recommended practices and/or technical reports pertaining to human-machine interfaces in all manufacturing industry applications.
The areas covered within ISA101’s work will include: menu hierarchies, screen navigation conventions, graphics and colour conventions, dynamic elements, alarming conventions, security methods and electronic signature attributes, interfaces with background programming and historical databases, popup conventions, help screens and methods used to work with alarms, program object interfaces and configuration interfaces to databases, servers and networks.
As you can see from the above there is significant activity underway to ensure that we will be able to properly manage the plethora of data available in today’s control systems. The one thing that modern HMI and operator interfaces, both in the control room and on smaller devices, are doing is helping us to make informed decisions faster, less stressfully and with less chance for error.
This article originally appeared in the March/April 2013 issue of Manufacturing AUTOMATION.