About the Author
Ian Verhappen is an ISA Fellow, Certified Automation Professional and a recognized authority on industrial communications technologies with 25+ years' experience. You can contact him at [email protected], via his blog at community.controlglobal.com/kanduski, or check out his Google+ profile.
For many automation engineers and integrators the words that often equate to "potential problems" are "third-party integration."
Of course, if you work on a time-and-materials basis, it also often equates to "billable hours" and profits. Not so good on a fixed-price project. However, the problem is that, since automation is often the final hurdle before start-up, the pressure is on to start operations, so stress mounts quickly. If you're unable to deliver, then your reputation can suffer, and it's off to find a new customer, rather than having a satisfied, repeat client.
SEE ALSO: Productivity Through Integrated Engineering
With the increasing use of modules in all forms of construction from automation cells to skid-based processes in the continuous and batch industries, the requirement for third-party integration will grow.
Fortunately, managing a third-party integration follows the same principles as any other engineering project and starts with proper planning up-front. The most basic component of that plan is to have a single database identifying all the project I/O points, not just their source and destination, but the actual tag names. Because tag names are the master index or pointer to all other databases and information in a control system, it's critical that each tag name be unique. A common database to prevent duplication of devices on modules (i.e. two 10-PIT-10s) is necessary.
ISA5.1 is used as the basis for most tag-naming practices, and it has both the granularity and flexibility to meet the needs of practically any application, including the power industry. Propagating a tag-naming convention across a project as part of the front-end engineering design (FEED) or design basis memorandum (DBM) to all suppliers will reduce the risk of tag duplication, and ease integration when all the parts come together at construction and commissioning.
With the increasing use of digital communications on projects, it's also fortunate that most industries, or at least facilities and projects, restrict themselves to one or two industrial protocols. If we look at the 19+ protocols in the IEC standards, they've pretty much sorted themselves by vertical niches or applications. Foundation fieldbus, HART and Profibus-PA are primarily used in the process industries. BACNet and LONworks are in building automation and by corollary often in pharmaceuticals and biotechnology, where ambient temperature control is important. ODVA languages are used in factory automation, and versions of CAN are used in the automotive sector. The combination of these industry-niche protocols and projects limiting the number of approved networks helps with module integration, since all the modules are likely to be using the same protocol(s).
The most widely used digital protocol is Modbus. It's often the common denominator and, unfortunately, often the default protocol specified on projects. Using a digital protocol with an electronic data sheet, such as an EDS, DD, GSD, FDI, etc., manages the mapping of data from the device registers into fields that reduce the manual labor required by other methods, such as Modbus or other protocols without these features. If you use digital communications that require manual mapping, then another form of planning is required. That is, to allocate the appropriate contiguous registers for each data type as part of your planning process — again communicating this to all suppliers, so they comply as well.
One benefit to the engineering company or integrator of manual mapping is that it does result in billable hours, but it's not the most productive use of the available time of project staff.
In the early 1990s, the Society of Automotive Engineers' (SAE) Truck and Bus Control and Communications Sub-committee started development of a CAN-based application profile for in-vehicle communication in trucks. The result of this work was the J1989 series of standards that we find today in all our vehicles, as well as diesel- and gas-powered electrical generator sets.
At the risk of starting another round of bus wars or complicating the Modbus protocol. we might want to consider developing similar Modbus "application profiles" for specific applications in which some of the existing buses are not a good fit or have too much overhead for the industry or sector where they're being used.
