About the Author
Ian Verhappen is an ISA Fellow, Certified Automation Professional, and a recognized authority on industrial communications technologies with 25+ years experience predominantly in the process control field.Today's control systems and components are more complicated and more integrated as a system than ever before. The challenge faced is how to integrate the vast amount of data these systems provide and convert it into information. The first step is to get the various components to communicate with each other digitally and share more than the process variable or analog signal alone. There are many open and standard communications protocols available. Some could be considered "legacy" applications, while others are relatively new and, though rich in content, not yet widely deployed. The challenge we face today is to integrate these products in a single seamless (at least to the end user) environment.Many of you have at least one story about being asked to transmit a signal used by your control system from one protocol, through a second protocol, to a third, and likely proprietary, protocol. Now, because the control system supports the intermediate protocol and the protocol carrier indicates they communicate with the first protocol, the person(s) who asked you to do this feels it is trivial and should be done "automatically" by the system.Take the example of the relatively common Level 0-1 protocols of HART, Modbus and an "ABC" control system. The ABC control system, like all control systems of any size, supports open Modbus with a special serial communications port. Unfortunately, ABC is unable to interpret the additional capabilities of the HART protocol beyond the analog signal, and this diagnostic information is needed to warn the operator when the device has failed and to indicate some of the "secondary" signals such as an upstream differential pressure measurement. I realize there are products from a number of manufacturers that output this signal as a second analog input. I only use this as an example. The designer may actually want multiple signals from this single transmitter.So, the technician will have to "map" the HART register for this variable to a register in the Modbus device, and then again map the Modbus register to the control system register to which the application engineer will "point" to access the information for the control system. This is for a single point; imagine doing this for an entire system of gas detectors or an analyzer and its sample system with multiple devices from a variety of manufacturers. The complexity increases dramatically, especially since each manufacturer might not use the same register for the same parameter.There's more: If there is a communication fault at any point in this system, all the fingers will point to the other protocol as the culprit, meaning that the technicians and engineers also will have to be "expert" network troubleshooters for protocols that only have minimal troubleshooting tools.This is why a designer should-as much as possible-use a control system I/O card that directly and fully supports the protocol used. If it is necessary to use multiple protocols, then each of these protocols should have its own host I/O card. The benefits are that no third-party protocol conversion is required since the control system supports the protocol directly and will likely have "automated" tools to ease the capture of the necessary information and, secondly, a single source of assistance can be obtained from the control system supplier.The above describes only some of the difficulties associated with getting data from the field level into the control system, however much of the desired enhanced information is not used by the control system, so it must be passed to at least level 2 of the enterprise, which means another "mapping" exercise.Fortunately, most control systems now support OPC. Unfortunately, not all control systems support OPC to the same degree and, in some cases, have no way or an inconsistent way of capturing and transmitting simple items such as the status bit of a transmitter. The OPC Foundation recognized that there is room for improvement of its technology, so they formed an End User Council to provide this type of feedback. In addition, a number of organizations are developing open standards, normally based on XML, to create libraries and object dictionaries to integrate the enterprise with the control system. Included in this group are ISA and its ISA-95 committee, the Machinery Information Management Open Systems Alliance (MIMOSA), the Chemical Industry Data Exchange (CIDX), the Open Applications Group (OAG), and others including the OPC Foundation.I encourage you to help solve this "dilemma" by participating in one or more of these organizations to share your knowledge. It is only by working together that we will be able to solve these problems.
