I can’t say I have any great revelations from the MassTLC’s IoT event held at Bentley yesterday but it was refreshingly non-commercial and helped to reinforce some of the themes I and others have been thinking about at Red Hat as we continue to refine our IoT planning and products. Here are a few points I took down in my notes:
What is IoT? I heard a variety of definitions over the course of the day, but the most common thread was probably around the idea of it being “the confluence of the physical world and the digital world coming together” in the words of Howard Heppelmann of PTC. If you think about it, much of the computing that we have historically done has been pretty data-poor. And you can’t optimize what you can’t see. But tiny, ultra low-power sensors (see e.g. RF energy-harvesting power management units) are going to proliferate and thereby create new value by creating new types of connections between data (think things like traffic route optimization and power management) and processes.
It really is about the data. There’s a hugely important intersection between IoT and Big Data (however one chooses to define both of those often nebulous terms). In fact, there were two separate panels on data during the day. I took away a couple of specific points. The first is that there seems to be a general consensus emerging that we’re talking about using data for two distinct purposes. The first is to take real-time action. “There’s something wrong with the engine; shut it down and/or place a service call.” The second is for retrospective analysis with the goal to learn from the past to prescribe new future behaviors.
Rob Purser of MathWorks explicitly defined a three-tier architecture with respect to data:
- edge nodes: local embedded algorithms and data reduction
- data aggregator: online analytics that are continuous and well-defined (you know what are looking for) and visualization/reporting
- exploratory analysis: historical analytics (more ad hoc; almost forensic) and algorithm development
(At Red Hat, we’ve been referring to the data aggregator tier as a “gateway,” which is Intel’s terminology as well.)
IoT is multi-faceted. At this point, it’s worth highlighting an audience member comment. It was along the lines that you can’t really talk about IoT, its use of data, and the value that it delivers as a singular thing. I think that’s exactly right. So many IoT discussions end up back at refrigerators placing orders for drone-delivered bottles of milk when you start to run low. Admittedly, people might have had similar sentiments for things like TV remote controls back in the day but so many of the home IoT solutions much in the news seem like solutions in search of problems. They shouldn’t eclipse the very real value in a lot of businesses. (I suspect there’s opportunity in home power management but even that is much less interesting than in an industrial context.)
Security, identity management, and data ownership is far from solved. This general topic was poked at throughout the day but I didn’t come away with a lot of specifics. The broad issue is this: One of the visions for IoT is to take previously siloed data from widespread sensor arrays and combine it with other data to uncover new relationships and thereby optimize various types of processes and create new value. But that statement invites lots of questions? Are the end point devices themselves exposed to the public network and, if so, how are they secured and kept secured? What authentication mechanisms are necessary? Who owns various types of data and with whom is it shared? One example. In a few years, your car will know lots of things about its local traffic, weather conditions, even the road that it’s driving on. What’s the protocol for making that data available to others who could use it for genuinely useful things? (And is it appropriate to share that you’re also playing that embarrassing Britney Spears song?) And, by the way, governmental rules for all this may change when you drive from France to Germany.
(I’d also note that there was various grumbling on twitter after the MIT CIO Sloan Symposium a couple of weeks ago when the IoT panel at that conference basically punted on having any discussion of security at all.)
Standards aren’t either. For more on this topic, I encourage you to check out my colleague James Kirkland’s piece from earlier this year. The tl;dr is that a lot of good work is being done to solve different types of problems throughout the IoT solution space but there’s still a lot of fragmentation and it’s not clear we have a holistic view of all the pieces that are needed and of what should be standardized and what shouldn’t be. Obligatory xkcd.
Networks need to adapt. The final point I’ll leave you with from the day is the observation that a gazillion little sensors won’t necessarily deal with a network that’s probably more optimized for watching Orange is the New Blackon Netflix at 7pm local time. As Kris Alexander of Akamai put it "now all of a sudden millions of things are sending small things more frequently. Networks weren’t really designed for this.” Chris Baker of Dyn added that "holding open connections isn’t a core competence of most home routers.” You need to think about the use case. How important is time to your use case? What happens if don’t check in? (If it’s a pacemaker, the answer might be different than if it’s your DVR.)
No comments:
Post a Comment