By Walt Boyes
You cannot measure what you cannot see. You cannot control what you cannot measure. You cannot protect what you cannot control. If your job is OT Asset Management you have even more problems because you can’t see or measure, protect, or control your assets.
You have tried spreadsheets. You have tried flat file databases. You have tried relational databases. You have tried digitizing maintenance logs. You have tried to interpret years-old “as-built” drawings and spreadsheets. You have managed to completely confuse yourself and your employees because none of the spreadsheets, databases, logs, and drawings agree with each othe,r and none of them are accurate as more than a “time-slice” picture of your assets. This, of course, makes them more than useless. If you rely on them to give you confidence in your OT assets, you have misplaced your trust.
There is an old saying among commissioning engineers that “as-built” drawings and device tables are only accurate for about 10 minutes after the plant is started up. The reason for this is that changes, both minor and major, are made constantly, and there is no way to keep the “as built” as-built. You do not know the context of the devices, networks, and software that make up some of your most important assets. You need more than a list of IP addresses and host names. You need the exact configuration of each device down to the serial number, firmware configuration, and model number—all the way to level zero. If the device runs configurable programs, you need to know the software, installed applications, OS that it runs on… You see the picture. This is a huge, nearly impossible job to do manually. So, most plants don’t do it. But not doing it and hoping that nobody catches you is whistling past the graveyard with a vengeance.
So the next thing you try is to put together a spreadsheet taken from the “as builts” in an attempt to digitize and contextualize all the specifications, operating information and data. This is almost always a manual exercise and is only as accurate as the data entry you give it. It is also only as accurate as the operators and maintenance people who you send out to collect the information. Sometimes what they collect is accurate, or was, when they collected it. Sometimes it is wishful thinking because the operator didn’t have time to write the context down or maybe it is entirely fictitious to start with.
The same thing happens with both flat-file and relational databases. They are only as good, only as accurate, as their input data was, when it was originally input. The minute the data is input, its accuracy starts to degrade and its usefulness is lessened. Sending a maintenance operator out on a dark and stormy night to repair or replace a pressure transmitter that is located twenty-five feet above a catwalk that can only be accessed by a jerry crane is bad enough. But when the operator finally reaches the device and finds out that it is a completely different unit than the replacement he has lugged all the way out there, the confusion and potential for catastrophic error is huge, especially since that pressure transducer is shutting down an entire process line. But your database said it was an XYZ not an ABC.
As an OT engineer, you aren’t just looking for the networks. And the network intelligence tools don’t tell you about the level zero devices at the edge of the network. You need to start with the level zero devices and work back to the networks. You need an evergreen, always repopulated, database of devices that include manufacturer’s name, the make and model of the device, and what application it is being used for. A pressure transmitter, for example, can be used for multiple applications like flow, level, pressure, density, and so forth. So just knowing it is a pressure transducer doesn’t tell you very much. You need to capture the serial number, firmware version, installed software if the device runs updatable apps, what the measurement range is, and what it means.
Then you can get to the network, to the IP and MAC addresses. You can discover connectivity issues and see the I/O modules (with their own firmware, software, version information, and serial numbers).
Unless you can install that evergreen database, everything you know is outdated and possibly erroneous. Bad data in the oil and gas industry is often fatal data.
So, what is a poor OT engineer to do? It is specifically designed to solve the problems we’ve been talking about and do it in near-real-time.