John Rezabek is a process control specialist for ISP Corp., Lima, Ohio. Email him at [email protected]Fieldbus is too hard, so let's make Modbus easy! That's the message you might hear when reading Editor-in-Chief Paul Studebaker's update from the Schneider Electric Global Automation Conference, "The End of System Integration"). Schneider is the proprietor of all things Modicon, heritage creators of the nearly universal de facto standard of digital integration; now the company's Grant Le Sueur proposes that the popular 30-year old standard should become the fieldbus of the future. [Please note that I simply reported the session, it did not necessarily represent my position or that of Control, nor does this column. –Paul Studebaker]
Modbus has become a lot easier than in the early days, when the vagaries of RS-232 hard-wired handshaking, duplex, half-duplex and so on could be intimidating. Who remembers soldering tiny jumpers in D-25 or D-9 connectors, so that the master or slave weren't idling waiting for a "clear to send"? There was a lot of trial and error, and systems-level (DCS or PLC) specialists were nearly always involved in the effort. Then there was the equally trial-and-error task of setting baud rates and stop bits and parity and so on, oftentimes with DIP switches and/or cryptic commands.
It's true we've gotten good at Modbus after flailing away at it for 30 years. It wasn't always easy, and it still isn't something your everyday instrument tech can implement without significant involvement from the DCS boys or girls. Per Studebaker's update, Foundation fieldbus and Profibus are kicked to the curb for being "too hard" or "too sophisticated" for our technicians. And somehow we will make their jobs easier with Modbus. In the Modbus future, more clever Modbus devices (made cleverer by whom is hard to tell) will auto-configure after auto-announcing their capabilities to the master (host).
Le Seuer's vision all smacks of "DICED" (auto-detect, auto-interrogate, auto-configure, auto-enable and auto-document), a passion of ExxonMobil's upstream guys Sandy Vasser and Tim Madden. (See "Incremental thinking won't solve automation challenge") My grasp of DICED is that all hardware―systems, I/O, junction boxes, cables, devices―are ordered as standard catalog numbers. The customization and configuration of all this hardware is achieved solely in software.
[pullquote]Le Seuer takes the vision a step further. He suggests (someday) we'll just scan a P&ID (to the cloud, perhaps) and everything from spec sheets to POs to configuration will spring forth. ExxonMobil needs this because they keep finding oil in hostile places (Siberia, Niger Delta, Angola) where it's hard to get scarce I&C specialists to go. Sandy and Tim are weary of being on the critical path for getting an asset to start making money for the company. So if DICED can be made to work―and many suppliers like Schneider Electric are eager to make it so―automation infrastructure will just become another piece of pig iron that plops into place and does its thing.
Modbus had been around for 10 years when the ISA SP50 committee was meeting to determine the standard for digital integration of field devices, the successor of 4-20 mA. Per committee chairman Dick Caro, Modbus wasn't even in the running. At the time, perhaps 9,600 or even 19,200 baud was considered slow, but even at today's speeds with Modbus TCP, the protocol lacks a property critical to process control specialists: determinism. If I have 16 Modbus nodes my "master" is polling for data, it just goes through nodes sequentially. If node 13 has something important to announce, for example, the turbine is stuck at a critical speed, it has to wait patiently for the master to get around to polling it. There is no autonomy (provision for a node to interrupt with an important update) and no prioritization of messages.
Determinism―or the lack of it―has impacts in many facets of process control. For example, in an operating plant we're often asked to determine the actual sequence of events preceding an upset or shutdown, sometimes down to a fraction of a second. When the plant is in pieces, can you see yourself looking the plant manager in the eye and saying, "I can't really tell you if the operator move preceded the alarm or the overspeed condition"? DCS historians and event journals are only as good as the subsystems that feed them.
Le Seuer's objective is to get engineers out of the business of mapping soft I/O and to keep it from inflating the cost of projects. I welcome such efforts, but not at the expense of throwing process fieldbuses under the bus. These protocols were tailor-made for process control and, and, as we did with Modbus, after a decade or so we're getting really good at them.
