With all the discussion of the Internet of Things (IoT) and Industrial IoT (IIoT), many organizations may be pushing wireless as an easy way to, at a minimum, gain experience in this field and be able to claim that they are making progress. There is, of course, a difference between “doing something” and “making progress,” but to some people, that’s splitting hairs unless you are an engineer, in which case you want wireless to solve a real problem.
Because complete industrial wireless systems that support protocols are approximately an order of magnitude more costly than other single-purpose alternatives, the economic incentive certainly exists for using lower-cost devices. Once again, we need to be mindful of not just the purchase price but the lifecycle cost, including labor and risks associated with installing, maintaining and operating a device.
The single-purpose radios not only cost less because they have fewer features and hence parameters and options to configure, they're often much simpler to integrate and support. In many cases, the single-purpose radio (because it's effectively paired with one or two devices or a single access point with a limited number of channels and one frequency) is closer to plug-and-play than the wireless system option supported by an international standard and associated trade organization such as WirelessHART and ISA100.11a.
The reliability of simple and inexpensive, single-purpose, signal-repeater devices needs to match the application. If you require end-to-end integrity guaranteed at all times (something I would suggest is a good idea for control or custody transfer, and optional for monitor-only signals), you likely want to spend the money and invest in a protocol supported by the major vendors. This extra money gets you features such as stale data and time stamps to tell if the device was working, which could be very difficult to detect without this capability.
The wireless protocols employed by major vendors all have excellent security for configuration and signal integrity, plus, when you need it, technical support from either the local representative or their central support facility, which is available 24/7. The lower-cost alternatives may not have the same level of cybersecurity or technical support of the industry protocol-based systems. Then again, the single-purpose units may not require much in terms of technical support because they're relatively simple to configure and install.
A system based on one of the protocols also is likely to be easier to fully integrate into the balance of the control system, using, for example, EDDL to verify span, range and connectivity without the use of a gateway. If, however, all you need is the analog value and can connect that to an analog input on your controller, easy and simple may be the way to go. Pulling in an analog signal is not, however, IIoT, which means digital communications to the end device itself.
Regardless of the how you get the signal into the control system, once the information is in the controls database, integration with the balance of enterprise is no longer a function of the protocol other than what parameters are available and which ones are worth using, storing and analyzing.
If you make a simple statement that you must be able to detect failures, such as loss of connectivity, end-to-end connection (cybersecurity) or message time-out, then you can eliminate a lot of legacy system interfaces and many lower-cost products that may not be well-suited to process control applications.
In the end, the need for a “complex” protocol solution versus a “signal repeater” comes down to the application. If I only need a temporary method of transmitting an analog signal over a reasonable distance, the solution is likely much different than if I'm planning to integrate multiple signals into a control loop or safety alert, in which case I want to know the original message will always arrive within a predetermined interval.
About the author: Ian Verhappen
