While at Dell EMC World 2017 I had a very interesting chat with Jason Shepherd, Dell EMC’s Director of IoT Strategy & Partnerships. To be clear, I’m not an expert on the Internet of Things (IOT), and our discussion was a useful reminder how much difference perspective makes when evaluating a technology.

 

 

Internet Of Things: Use Cases

When I think about IOT the first thing that comes to mind — naturally enough — are the items most applicable to me, like a smart thermostat, smart door locks, smart light bulbs, and so forth. I work in an enterprise, so I also think about building management in the enterprise, to include things like smart lighting, HVAC, presence sensors, temperature monitoring and more. Both of these environments are ripe for IOT functionality, and are the ones that most of us are likely to encounter on a daily basis.

However, it’s probably obvious that there are many more use cases for IOT devices, including for example:

• industrial (monitoring critical equipment like motors, valves, temperatures, flow meters)
• metropolitan (city-wide automotive/pedestrian traffic monitoring, traffic flows)
• agricultural (monitoring water levels, animal health, production volumes, environmental)
• automotive (monitoring the car’s engine, location, mechanical and electronic systems)
• commercial (presence sensing, environmental, lighting, security)
• utility (SCADA, etc.)
• and more…

The name Internet Of Things is rather ironic because it implies connectivity to the Internet, but in particular for many commercial/industrial systems it is neither desirable to expose these services to the Internet, nor in some cases possible. A better name might be Network Of Things With Which We Can Communicate (NOTWWWCC), but I appreciate that it makes a terribly unmemorable abbreviation so for now I’ll stick with IOT. The thing is that while some needs, like security, apply across all use cases, other needs and approaches are likely to be unique to the use case, so one size very much does not fit all.

The Great Thing About Standards

As the saying has it, the great thing about standards is that there are so many of them to choose from. Karen López also reminded me that if you have twelve standards and attempt to write one standard to replace them all, you end up with thirteen standards. IOT devices may be one of the most egregious examples of multiple competing standards making it a nightmare to support. Anybody who has tried to buy smart devices for their home has almost certainly discovered that there is more than one standard at play, not just in terms of proprietary control protocols, but even in the various (usually wireless) transmission protocols offered, almost all of which are also very low bandwidth, as that’s one of the ways to save power. Moving outside the home, things don’t get much better; there are industry-specific standards (e.g. HVAC typically uses BACnet, SCADA usually uses Modbus, automotive vehicles use CANbus). Just as in the home, mixing and matching different devices and trying to manage or monitor them all can be a nightmare. I’ve borrowed the image below from a Dell EMC overview slide as a sample of the challenges being dealt with by anybody trying to unify communication in the Internet Of Things space:

The good news is that Dell EMC – and 49 other companies – have joined together to create that “thirteenth standard”, called EdgeX Foundry. EdgeX effectively provides a common SDK / API for the various IOT protocols needed by different systems, and is architected using the principals espoused by Pivotal Cloud Foundry, i.e. a highly scalable, cloud-native, microservice-based application.

One big advantage of EdgeX is that the translation layer between a protocol-specific command and reporting structure and a shared command and reporting structure can be written once, then used by everybody else. This avoids the situation we’ve seen so often in the past where each vendor’s implementation of a standard turns out to be slightly different and incompatible with another vendors. EdgeX becomes a consistent lingua franca for all the devices. It is early days for EdgeX however, and only time will tell where it will end up.

The Importance of Being Honest

Imagine a temperature sensor which reports the current temperature every second and reports it back to a monitoring system. Picture an industrial environment where many hundreds of these temperature sensors have been deployed. Two obvious problems should be immediate:

1. Cumulatively, there’s s a lot of data going to the monitoring system;
2. The monitoring system has a lot of data to store and analyze.

During our conversation, Jason Shepherd posed this question: If the temperature is unchanging, how many times is it actually necessary to keep reporting the same thing? A constant temperature of, say, 85 degrees F, will mean the number 85 being sent 60 times each minute, and the monitoring system has a lot of data on which to run its analytics each time. It might be nice to have a device sitting between the sensor and the monitoring system which could process the sensor data locally and send on either a slower periodic temperature report, or send on the temperature data only when there’s a change (at some specified resolution for the data). The monitoring system can presume that if no data is received in a specified time period, the sensor is up but has nothing new to report, and it can interpolate the data accordingly. The same could apply to a wide variety of other sensors where given a set of rules to determine when a system is operating nominally and when it is not, data can be processed at the intermediary device without necessarily needing to be sent on to the monitoring system.

Coincidentally, Dell EMC’s Edge Gateway Router does exactly this; it’s able to speak multiple protocols so it can provide a single point of aggregation for multiple disparate sensor feeds, perform analytics on-device and decide what data should be sampled, and what data or alerts should be sent upstream immediately. The Edge Gateway also provides a single, secure access point between the wider IP networks and the IOT systems, thus significantly reducing the attack surface as seen from outside the gateway. This edge device would be categorized as Fog computing, a term coined by Cisco to describe the concept of extending the cloud to a location in between the end devices and the cloud itself.

Analytics

An industrial system may have a device monitoring the rotational speed of a motor, another monitoring vibration levels, and another monitoring the motor temperature. The analytics I mentioned in the previous section may be critical in order to identify a motor which is running slower than usual (for unknown reasons) and is beginning to overheat. Perhaps there’s a higher vibration as well, and this may be related. Historically this kind of failure would most likely go unnoticed until the motor simply stopped working, but a good analytics engine should be able to identify an impending failure and raise an alert. This is known as predictive analytics. Readers in the USA may have noticed that IBM has recently been bombarding the TV airwaves with commercials showing Watson™ identifying problems before they occur; and that’s exactly what I’m describing here. Prior to the EMC acquisition, Dell sold its own Statistica predictive analysis engine as part of the sale of the Dell Software group in 2016. That leaves Dell EMC without a product to sell, but it also means it is open to partnerships. Coincidentally, one of those partners (actually an Executive Partner) is … drumroll … IBM Watson, and together they’re offering a Factory Optimization Solution using Dell Edge Gateways and IBM Watson predictive and prescriptive analytics.

Helpfully, Jason then moved on to describe prescriptive analytics, where the system not only identities the impending problem but also recommends what to do about it. He gave the example of Dell and GE working together for a customer with a number of very remote operating locations, for whom a typical truck roll for an on-site repair would cost $1000 before any parts costs. Their analytics system has been designed to predict when parts are expected to fail (based on the reported IOT sensor data) and then when an imminent failure is predicted, the system also looks for components which are likely to fail within a reasonable window of time thereafter, and recommends replacement of those parts at the same time in order to save the cost of another truck roll a short period afterwards. For other components, the analytics will determine the relative cost of ongoing repairs vs a full replacement, and advise which is the most cost effective path.

Clearly while a Nest thermostat might be fairly smart, these industrial systems put home automation analytics in the shade.

Did You Know?

As I said at the beginning of this post, I’m not an expert on IOT. Nonetheless, one of the reasons I’ve written this post is because I had the opportunity to see a side of Dell EMC which was new to me; I had no idea that Dell EMC was a player in the industrial and enterprise IOT markets. I hope that this has been new and interesting to some of my readers as well.