Tuesday, 07 March 2017
Those who work with Kerrco on developing operational technology (OT) plans and programs will have heard us repeatedly make the comment that investments in OT and IT should be made the same way we “buy trousers for a six-year-old”. While most of us intuitively grasp that to mean “leave some room to flex and grow”, it’s probably worth putting a bit more detail around the catchphrase. Especially because so many vendors use the same words to describe technologies that have big differences in their capabilities. There’s a lot of ground to cover, so this is going to become a series of posts all bound around making it easier to compare and contrast enabling technologies for Industrial Internet systems.
Let’s start with another hackneyed phrase: “Big data”. We’re as guilty as anyone else of using it, after all. If you’re reading this blog, you’re probably already well aware that industrial Big Data solutions need to have different characteristics than the sort of tools retailers use to analyse sales or that insurance firms use to derive risk models in their world. But even on the industrial side, there’s a casualness around numbers that bears looking at. Some perspective – a single 1MW generator (with associated power management gear and fuel system) would have ~150-200 variables that could usefully be monitored as part of a reliability optimisation regimen. Those values, polled at a fairly slow rate (say every 5 seconds), could generate up to 65 million values per month. Allowing for some scaling or deadband logic at the point of data collection, that could mean a significantly lower volume that ultimately needs to be stored but that’s still a much, much higher volume of information to parse than is seen in typical enterprise data management scenarios.
That volume (and let’s not kid ourselves – many industrial asset data collection strategies need to allow for faster poll rates on bigger data point counts) has enormous ramifications in two critical areas. Setting aside questions about the differences in scalability between different platforms on the collection side, there are other issues that bear consideration:
- App performance – and related design considerations for data flows & management - If you’re always ingesting a flood of data, the underlying data store had best be optimised for query and retrieval as well as for collection. That’s easy enough to do when the desired reporting and analytics are reasonably well-understood, and fairly simple in form. But there’s a world of difference between being able to deliver a fast-performing solution that’s essentially delivering trending or simple aggregations vs delivering a system whose data is used to drive visualisation & reporting content, triggers for human and digital work processes and as the raw base for streaming, real-time multivariate analysis.
- Mix of functionality in the user environment – So many of the IoT examples we see are based on simple user interactions where a “result” is presented visually (a number, a graphic, whatever). But the promise of the Industrial Internet is to enable new ways of working. Let’s consider the a field service engineer’s work; their app “cockpit” might include KPIs, summary information, analytic results with supporting details, access to longer term trend and event data, and also provide the means to use the underlying asset data to drive triggers/functions across multiple back-end systems (maintenance work orders, material stores requisitions, purchasing/supplier systems and the like). So the data management platform has to be able to keep up with interactions that may differ from instance to instance and in terms of the breadth and granularity of quickly available detailed source data needed to support a particular service call
And the answer can’t simply be: "Throw more resources at it in the cloud". Ultimately, if the platform you choose scales only in relation to ever-expanding processing, storage and memory demands, that will be reflected in the costing.
So – mixing our metaphor with the practical matter at hand – some questions to bear in mind when investigating “data management platforms/trousers for a 6-year-old”:
- How much logic can be applied at the point of collection? Can rules be applied as data is polled so that the volume of data that needs to moved from source to data platform and stored there can be minimised?
- Is the data management platform itself natively optimised for high levels of read/write activity? Platforms built on technology that’s closely derived from common enterprise platforms may not keep up with the challenges posed by high volumes of high-fidelity data
- Is a federated approach supported – a mix of on-premise and cloud enabled capability that are harmonised to common system processes, data models and analytic modes may open up options that pure cloud systems cannot
Each of these needs to be considered not only in respect of immediate plans or needs, but also with a realistic view of how your business processes may change as your Industrial Internet solution matures. So try to imagine what that 6 year old will look like in a few years, and make sure that the fit and fashion will keep up!
Next up – “Analytics! Huh! What Are They Good For? (Actually, a fair number of things, but not without some planning in advance!)”