Can you solve the logic for a “test-reset-acknowledge” annunciator function in three relays or less? When refurbishing a previously-owned analyzer shelter with lower explosive limit (LEL) combustibles detectors and ambient oxygen sensors, the engineer decided he could replicate the local alarming and annunciation with a few conventional mechanical relays. For decades, the accepted functionality included a test circuit—a pushbutton to invoke the alarms and ensure the horn (audible alarm) sounded and all the lamps (visual indications) became illuminated, along with individual or common trouble alarms for the house. The other pushbuttons were acknowledge (to silence the horn) and reset (to return the annunciator to the normal state following a test or an actual alarm). It’s been canned-in, built-for-purpose annunciators since the mid-20th century.
You can still specify and purchase the built-for-purpose annunciator in a variety of shapes and sizes, and they include even more features like LED lamps for long service life, multiple colors for alarm prioritization, even OPC servers for communication with a host system. But you may not need all that for a few alarms from an analyzer shelter or a truck loading rack, and it might be challenging to install them in a classified area (e.g. NEC Class I, Div. 2) or even make them weatherproof. So the engineer tasked with refurbishing the analyzer shelter sketched the ladder logic, and ended up with a half-dozen relays, pilot lamps, and three pushbuttons for test-reset-acknowledge.
Meanwhile, another application for a local test-reset-acknowledge alarm system was needed, this time for a horn and beacon to alert operators to a flooded trench inside a tank dike. Rather than solving it with relays, this engineer found a “smart relay” capable of sufficient I/O, suitable for hazardous areas, and programmable with familiar ladder logic. The savings were immediately apparent, as it was much simpler.
I’d like to view this “smart relay” as a very rudimentary edge device—microprocessor-based and capable of performing relatively complicated tasks independent of the host. I just Googled “smart relay” and found a half-dozen all priced under $200, each with about 10-14 discrete I/O. Even in this price range, many support Modbus RTU over RS-485 or even Ethernet TCP/IP connections, so you can network these together if you want to bring data back to a centralized host system. Given the price and the capabilities, I can see a proliferation of such devices. But there’s a rub: like all microprocessor based, networked devices, what's the plan when one needs to be replaced?
With today’s fieldbus devices and host systems, we're just beginning to see some potential help for the less tech-savvy maintenance guy who has to replace a device with no DCS engineer onsite. If you're happy with a single-vendor solution, for example, DeltaV’s latest incarnation supports auto-replacement for a certain subset of Emerson devices. At the same time, FieldComm Group is defining standards for ITK7 and host profiles that will incorporate a screwdriver-only replacement for all newly released devices and host systems. But this standard only addresses fieldbus devices. What about the proliferation of other “smart” devices like the relays in the example above?
The linchpin of the fieldbus approach is that the host system can configure and store any device’s “logic”—the configuration and linkage of its function blocks—in a unified database. When a device is replaced, at least (in the present day) with a nearly identical device, its identity and stored configuration is downloaded to the new device.
Though they support some nifty networking, many edge devices use a custom, proprietary interface for configuration. As long as someone maintains the laptop and remembers how to hook it up, perhaps a configuration from years ago can be restored. Why not have a unified database and configuration tool that incorporates all these new intelligent “edge” devices we’d like to use? For the efficacy of our engineering cleverness to endure, we need all our edge devices to migrate to a sustainable, standardized path like those supported by the FieldComm group.