Thus, in addition to improving compliance, the customer hoped to improve operational efficiency, tank utilization, and accounting accuracy as well. The fundamental challenge to reconciliation is the quantity of data required, so there are two common approaches to improving compliance:
- Take manual inventory more often.
- Bring more field data into the TAS.
For smaller terminal operators like Blendtech’s customer, neither option is attractive, since either hiring more personnel or expanding infrastructure might require an investment of hundreds of thousands of dollars.
Blendtech’s task was to find a third option—a way of automating this costly process that would be feasible for their customer.
Several years ago, Blendtech began working in the space of information technology (IT) and operations technology (OT) convergence, as more of their projects required bringing data from field PLCs into TASs.
Initially, they experimented with Ignition SCADA® to bridge these systems, but later used Node-RED on Opto 22’s groov Box™, because it didn’t require deploying and maintaining a PC. Blendtech had used Opto 22 products for over 25 years, integrating SNAP PAC controllers, G4/G1 I/O, and SSRs into their own TAS product.
For this project, they envisioned a similar solution, and looked to the latest generation of industrial connectivity products, including MOXA gateways and Opto 22’s groov EPIC®.
Their goal was to build a transaction history in the customer’s site historian using the data reported to the TAS. In particular, they needed data from custody transfer-certified meter registers (such as those shown in the image at right), which were located at each loading rack, and from pipeline manifolds where incoming fluid transfers are measured.
With an accurate transaction history in place, it would be possible to reallocate personnel currently used for reconciliation and have back-office operations staff audit tank usage more frequently. It would also be possible for accounting staff to perform more accurate internal audits, providing a basis for continuous improvement.
So if meter register data was already reported to the TAS, why didn’t the customer already have an accurate transaction history they could use?
The short answer is that there simply wasn’t a bridge between where the data was available and where it needed to be. There was no connection between the TAS, which resided on a corporate network, and the site historian, which was part of the control network. Further, the data stored in the TAS required normalization—additional processing to format data items consistently—before it could be added to the site historian.
The control network contained an Allen-Bradley® PLC that provided some aggregation of field I/O data, but it lacked connections to the loading rack meters and the functionality to read and process data from the TAS database. The flow meters themselves were controlled by their own embedded logic, independent of the field PLC, and reported their values back to the TAS using a proprietary protocol that wasn’t accessible to the rest of the control system.