IoB Insiders: Quocirca analyst Clive Longbottom assesses the challenge of analyzing and aggregating data in increasingly complex IoT architectures.
If asked what an IoT device looks like, what springs to mind? Do you think of a small item – something like a single-function temperature-monitoring sensor? Or maybe something a little more complex, a personal wearable like a fitness band, for example? How about a train, or an autonomous vehicle? Surely these are far too big and complex to be regarded as a single IoT entity?
For organisations dealing with IoT architecture, getting to grips with these kinds of definitions – even with such a broad level of granularity – is increasingly vital.
Keeping track of connected trains
Take, for example, Hitachi; the Japanese company is currently building new Intercity Express passenger trains for the UK’s rail network at its factory in Durham.
Unlike the trains they will replace, each of these new trains is loaded with measuring and monitoring devices. By using Hitachi’s own IoT platform, Lumada, an underlying system has been created that works at different levels for data collection, analysis and the actions that need to be carried out based on that analysis.
For Hitachi, this means it can gain information on the ‘health’ of an individual train, pulling systems out of service for maintenance work well before any problem escalates to become an issue that impacts passengers.
In the UK, the rail network itself is looked after by a separate entity, Network Rail. It runs a fleet of under 100 dedicated trains across the whole of the UK, of which fewer than 30 are dedicated to rail monitoring. These trains can only operate when there are no high-speed scheduled services being run on the same line. As such, they only cover a very small area of the rail network annually.
For Network Rail, the Hitachi trains are of more than passing interest as they are continuously monitoring the health of the network as they travel along – at full speed, in real time.
Hub and spoke
If all of this data was transmitted over the Network Rail data network, it would be flooded and the system would not work. A hub and spoke architecture is needed that enables intelligent data management.
Consider the train itself: Hitachi needs to monitor everything to do with the engines, because each train has the capability to be run either by overhead electricity or by diesel engines fitted under the powered units.
Each separate engine system has a large number of sensors generating masses of data. By using aggregation systems within the train (hubs), that data can be pre-analyzed and assessed for usefulness on the train itself. And, in some circumstances, local action can be taken – for example, using actuators to shut down one part of a system and start up an auxiliary one.
Only when an a major anomaly is identified should a small chunk of data be sent to a central environment for more detailed analysis and action, such as pulling the train out of service.
Read more: NetSuite’s cloud vision: one architecture for all devices
When things go wrong
Likewise for the rail monitoring system. Network Rail does not need to know that everything is working well – it needs information that points to where things may be going wrong.
Each Hitachi passenger train will monitor multiple aspects of the health of the rail and the sleepers, ballast and so on, carrying out data analysis in-situ.
If a problem is identified, Network Rail will be alerted so that it can carry out deeper analysis and take remedial actions as required. As such, Hitachi and Network Rail see each train as a single IoT device, with a capability to drill down beyond that entity to all the other IoT devices inside the train.
Now consider an autonomous vehicle: if an individual vehicle is dependent on a central point for analysis of all the data associated with it, along with all other autonomous and non-autonomous vehicles around it, plus all the non-vehicular artefacts that also need to be borne in mind (pedestrians, animals, street furniture and so on), crashes would happen too frequently, due to the latency between the incoming data and the actions taken by the vehicle.
Instead, groupings of different sensors and actuators need to be created with data from these being analyzed and acted on in-situ to minimize latency. For example, the sudden appearance of an unexpected object, such as an animal in the road, will need a signal to be sent to actuators to apply the breaks or to move around the object. As such, a hub and spoke architecture is required.
However, certain types of data, such as traffic levels, recognition of emergency road works and so on, need to be sent to a central point that can analyze them further and then propagate that data back out to all other vehicles, enhancing their knowledge of the environment. As such, the vehicle has to appear as a single IoT device in itself.
My advice? Any business putting together an IoT architecture needs to take the same approach. Use aggregation devices that group together individual IoT devices working on the same area. Use local data analytics to identify if the data coming in from the individual IoT devices requires any action. If not, drop the data – it is of no further use.
Ensure that the aggregation devices can both feed the useful data back to a central point – and that this central system can securely drill through to each device as required, in order to gain more detailed data or, as in the case of actuators, to force any action that is required to prevent a minor issue from becoming a major problem.
Read more: Over the IoT data waterfall, in a barrel