Digital Operator: How To Make Technology Work for Operators
As a solutions consultant, the most value I can add for a customer is to maximize their previous digital investments (systems, knowledge, resources) in support of their digital goals. If gaps are identified between tools they have and tools they need, then goal requirements can help guide tool selection (based on support, cost, complexity, etc.). The reason I make a stated point here: the solution and software I am going to discuss below are custom fit to the water utility industry based on common funding and resource disconnects. That does not mean other similar tools would not work in this industry, nor that these tools would not work extremely well in various other scenarios. However, since previously argued, water utilities (and especially rural water utilities) are on the front line of critical infrastructure, a successful solution would need to address ease of use, cost of software installation/ implementation, and ability to be locally owned. Otherwise, the solution would not appropriately fit the problem.
For the use case, please see: https://www.linkedin.com/pulse/use-case-example-empowering-water-utility-operators-kevin-white/?trackingId=PoOfrl5%2FS7G3L03qDuulsA%3D%3D.
It describes using 3 software tools, and in this edition, I am making a single software substitution based on complexity and cost. I have found for rural water utilities, a better solution is provided with Canary as a historian, event generation, calculation engine, and visualization tool.
So, let’s “grade” these tools as they relate to the use case described (an operator takes a sample which then should trigger them to adjust a system control to return the parameter to specification). Our goal is not to just replace a single operational data sheet or just digitize one set of corrective actions; the goal of the solution is to identify how we can standardize these activities (read: digitize these activities), knowing standard ops result in safety improvements, cost savings, and operational improvements. Using the initial use case as a template, digitization should allow us to replicate this human, non-automated control loop in a standard manner across various activities, industries, and operations.
So, if we’re going to discuss the merits of this turnkey solution for rural water, it will require a rough definition of which I used and what they mean. Since these are subjective, qualitative scales, others may freely disagree with my assessment, but here are the 3 metrics I will use to support the digital solution for rural water utilities.
1. Ease of Use
Rough definition: Is the solution “sticky”? How much training is required for an operator to understand how to use this tool? Does it address a current problem operators are experiencing? Can operators train operators on this tool?
To solve repeatable problems, a tool requires repeatable use. Senior rural operators (the true process knowledge owners) are key to a tool’s adoption and success; while the tool will definitely be “different”, it should not be “difficult”.
2. Local ownership potential
Rough definition: Can my local resources support this tool (updates, configurations, expansion) with minimal external support? How many monthly hours will the local subject matter experts need to devote to this solution? Can the tool fit multiple problems across different groups? How difficult is it to change or update something in the tool to integrate quick process improvements?
One of the easiest ways to lose local interest in a tool is requiring someone outside your organization to be necessary to make any change, update, or trial. Finding a solution which addresses multiple problems drives its worth, ensuring it is locally manageable drives its uptake, and allowing operators to change it to fix operations drives the solution’s local ownership.
3. Replicability
Rough definition: Can the tool be “cut and paste” into other use cases easily? If we want to add functionalities, assets, procedures, will the tool allow for this flexibility? Can other similar user groups provide their local solutions to address common operational opportunities? Does the solution provide more value every time it is applied to a similar process in a separate location?
Very few logsheets, process control instructions, or sampling requirements apply to a single parameter for a single piece of equipment. Utilizing tools that quickly leverage templates, asset groupings, and common parameters allows a standardized process piloted in a single area to quickly be introduced to the facility, where the impacts multiply and can be fully appreciated.
Using these grading criteria and operational examples within several water facilities, I would propose the following software tools combined for a Turnkey Engineered Solution applicable to any rural water facility with a SCADA system:
The Canary System (Canary) and OpsTrakker (Enhanced Information Solutions (EIS)), (utilizing the eDatasheet and eForms module).
The information for how these software tools integrate is presented here fully on the webinar (https://www.youtube.com/watch?v=HAc6F5h5U1M), but below is a simple chart explaining where each interaction in the scenario occurs:
With an engineered solution driven by the metrics described above, I would argue this turnkey solution would address many of rural water’s digital opportunities for improvement, utilizing tools which leverage institutional plant knowledge to drive standard, safe, efficient processes in the water facilities. Once established and lightly trained, I believe the solution would be easy to use, locally owned, and replicable across various locations – all results that are required for the impact to be felt quickly across these rural water communities. As we look to improve our critical infrastructure’s digital infrastructure, focus must be paid to the operators and teams who are tasked with these important operations.
This video also demonstrates the Static Tag Analyzer, which assesses your PI Data Archive to identify:
• Tags no longer receiving data
• Tags being overly compressed, thus losing information
• Under-compressed tags that waste resources
• Where tags are being used (PI Vision Displays, PI DataLink, etc…)
• Duplicate tags using the same Point Source
