John Rezabek makes the case for hardware standardization

[sidebar id =1]Having a searchable database of all human knowledge, events, weather, trivia, reviews and history in our pocket or purse is practically a foregone conclusion. And while we have our fashion choices of iPhone or Android, there’s a degree of indifference to the hardware. “Phone” functionality is almost entirely a function of the carrier’s network. Jazzy frills (like being submersible in champagne) and tribal affinities aside, one could easily argue that for smart phones, hardware no longer matters.

Even before fieldbus aroused sensitivities about differentiation and commoditization, Fisher-Rosemount’s intrepid “Hawk” team of the 1990s was intimating that hardware didn’t matter. And software didn’t matter. Large portions of the DeltaV (as in change in velocity or acceleration) DCS were assembled from other people’s technology and parts. The controllers and I/O bore an uncanny resemblance to MTL 8000 I/O for good reason—MTL manufactured them. The HMI software was from Intellution (now part of GE). And the original “block ware”—the way you configured the system—was largely based on Foundation fieldbus function blocks. The Austin, Texas, team even conceived a hardware-independent way to settle the bill with their customers: selling licenses for “DSTs” (device serial tags? I’m still not sure what those are), which broadly represented one’s I/O consumption. The idea that DCS suppliers would transition from selling hardware to selling services (apps) was the zeitgeist, and DeltaV seemed to be betting on it.

[pullquote]Since then, somehow, the market has transformed the “hardware doesn’t matter” origins of DeltaV to a marketing model that seems more focused on proprietary, built-for-purpose hardware, networking and engineering tools. I have the impression that this conversion was driven largely by their very conservative process industry customers, and the well-worn pathways for marketing systems and winning jobs. Perhaps hardware didn’t matter, but end users (and their EPC firms) buy a DCS because they want to “drive the car,” that is, utilize it to control a process—not assemble the car, test the car, tinker with the car, etc. As a community, our expectation is that the DCS functions as an integrated entity with little or no assembly required. And we also expect the supplier to have an army of competent and meticulous individuals, who have flogged and beaten the bugs into the corner and stomped on them, and will spring into action if you happen across any others.

The conservatism that drives this mindset stems in part from the fact that we aren’t the real end user. We serve an enterprise and an operating organization that use the controls and the dashboard of measurements—the deliverable for which we are accountable—to make the useful products that pay the bills.

[sidebar id =2]The operators who deal with our choices have to do so for hours at a time, and unlike us, work isn’t their favorite place to be. Operations managers and plant managers have even less patience for unforeseen foibles of the control system. No wonder we’re intimidated when our “app” runs on an agglomeration of Windows boxes and complex, inscrutable, microprocessor-based gadgetry. Hardware may not matter, but accountability does.

The nebulous accountability for open specifications like fieldbus has been a challenge. It’s taken a decade to evolve testing and specifications that leave little grey area for bugs to live. But today, it does work. Any field device with an analog input (AI) block can be deployed on any segment on any system, and deliver a digitally integrated measurement.

Hardware, to a degree, doesn’t matter. This should embolden us for extending standardization to the next level, per the ambitions of ExxonMobil and Lockheed Martin. We’ll need a new model for accountability. And if there’s a future where hardware doesn’t matter and the deliverable is the artfulness of our app, let’s hope for less than a decade of torments.

[sidebar id =3]