OSIsoft's Michael Kanellos
IIoT
To classic operations engineers, IIoT means “everything outside of SCADA.” Ops engineers have employed SCADA and similar equipment to reduce downtime and improve the overall performance of their facilities for decades. IIoT, therefore, can’t be new if it’s that: it must be something else. Thus, operations engineers generally view IIoT as the collection of sensors, software and technology made for the devices that haven’t (to date) been wired, i.e. a pump at the fringes of a wastewater network, a mixing bowl in a food-processing factory that predates the invention of Ethernet, HVAC systems that churn valuable data but not valuable enough to retrofit their existing system. Often, these are lumped into the category of “the secondary network.”
To IT teams, IIoT means “everything including SCADA.” If you’re talking to a machine, and using that data for a higher business purpose, it’s IIoT regardless of how the data was gathered, they argue. Consider the isolated pump example from above. The only difference between the isolated and the pumps currently being monitored is that it was never connected. Once wired, you will use the data in the same way. The “everything including SCADA” crowd also points out that most of the IIoT projections—$144.6 billion in hardware, software and service sales by 2027 according to Navigant—take this broader view into consideration.
Analytics
There are two general categories of analytical problems. There are the complex, time-consuming analytics requiring millions of data streams, cutting-edge algorithms, the hardware backbone available at Pentagon-sized data centers and lots of time. Then there are the analytics your employees perform every day while peering into their consoles and making reasoned decisions about maintenance priorities or production goals.
But what do you call them and what differentiates one from the other? The number of data streams? Whether the problem needs to be solved in six months or 24 hours? The complexity? Bandwidth? Some people divide these problems into edge and cloud analytics. Others divide them into operational vs. strategic analytics.
Personally, I look at posture. Lean-in analytics are those immediate problems that you solve by leaning forward into your console and diagnosing problems like a doctor. Lean-back analytics are research problems: you have lots of time and resources and need to tilt back in your chair to see the big picture.
Edge
People disagree about edge. To OT, edge is a device like an IoT gateway. To IT, anything outside the cloud is an edge. A factory or an oil refinery is an edge. OT engineers can take umbrage to that definition: to them, the facility they’ve turned into a well-oiled dynamo is the center of the universe. It’s the profit center of the company upon which everything else depends (which generally is correct.) IT counters by saying, yes, but it’s not the center of the network.
Research firm IDC has developed a compromise where IoT gateways and independent devices are relabeled “endpoints,” while factories and facilities become the critical edge. Whether this terminology takes off is anyone’s guess.
Digital twin
Is it a digital model combined with real time data? Can it be a digital representation of a process or device? Or must it also contain the ability to provide predictions and recommendations? Are CAD/CAM models to digital twins what still photographs are to movies? Does the value of a digital twin come from greater clarity or does it come from making it possible for more people to understand and use the data? Or both?
Are digital twins new or just a new term for technology we already have?
These are actual debates I have had with grownups in the last six months. It seems like we all know what a digital twin is supposed to be, but we can’t agree on the particulars.
So you disagree with all of the above? OK, what’s your take?
