Thursday, June 12, 2014

Podcast: Internet of Things with Red Hat's James Kirkland


James Kirkland, Chief Architect for Intelligent Systems at Red Hat, discusses the material economic impact that the "industrial Internet of Things" can bring to many businesses. In particular, James discusses a number of the specific scenarios in which transportation companies, such as railroads, are looking to IoT in order to dramatically improve the efficiency of their operations. James caps off this discussion with a look at IoT security.

Links:
Red Hat Embedded Program

Listen to MP3 (0:17:37)
Listen to OGG (0:17:37)

[Transcript]

Gordon Haff:  Hi, everyone. This is Gordon Haff here at Cloud Expo 2014. I'm here with James Kirkland, who's the Chief Architect for Intelligent Systems and the Internet of Things [at Red Hat], which is even more buzzwords than I have in my title. Welcome, James.
James Kirkland:  Thank you very much. Thanks for having me on.
Gordon:  James, let's talk about the business angle of Internet of Things. There's probably been a lot of attention paid to consumer‑type stuff. That I could put up my window shades without having to get up from my sofa, but that's probably not where money is with Internet of Things. How are we going to make money off of this thing?
James:  We classify it as the industrial Internet of Things or the enterprise Internet of Things. The way they're going to be able to drive lower costs and higher asset utilization is by, I call it, "the data cycle."
They're going to gather data out from these sensors on the edge and in the Internet of Things. That data is going to be shuttled along into the back office and into the cloud. You're going to use data analytics applications to mine that for ways to optimize your system.
For example, the freight railroads in the United States, if they're able to increase their average fleet speed by one mile an hour, it's $256 million in profit a year.
They're always looking at ways to optimize the fleet speed, controlling with predictive analytics, track failures, equipment failures and things like that. They would rather pull equipment out of service earlier rather than having it fail on the line and stop traffic. It's things like that, the predictive analytics side.
The other side is looking for patterns where you can optimize flows and look for data where you see customer patterns or patterns within things. For example, with smart grid one of the issues is...I'll use an example of electric vehicles and charging those electric vehicles.
With electric cars, there are two challenges with that. One is they have to detect when customer are adding electric cars in particular neighborhoods and areas, so that they can provision additional capacity to handle that as far as transmission.
More importantly, they need to develop algorithms that are based on data so that, when they detect that they're in peak load in certain areas, they can then decide which charging stations they can shut off, which air conditioning units they can raise the temperature on, things like that.
It's the big data analytics on the backside, on the cloud, where they're going to be able to look at that aggregate data, where they did fail, be able to analyze it and find patterns so that next time that it happens, they can handle it in a more efficient manner, without having to provision additional generation capacity.
A lot of what they do is have emergency generation capabilities that are higher cost, like oil, that they turn on in these peak periods. If they can avoid that by shutting off things like the charging stations temporarily, it makes a big difference in their profitability.
Gordon:  Implicitly, it seems a common thread what you're talking about here is money is involved. Again, going back to my comment at the beginning, I think a lot of the popular press excitement is for other things that are very, very far off and very theoretical, or cool and neat and glitzy.
But, it's not clear that they necessarily relate to saving money or having a direct business impact. Not to put words in your mouth, but where the Internet of Things is really going to be exciting is when there's a direct, near‑term, achievable making more money.
James:  That's it exactly. You've got to find the use cases where there's going to be return on the investment. If there's not a return on the investment, having a refrigerator that glows green when you've got enough food or texts you when you're out of milk...Those are interesting applications, but I think that they're a flash in the pan.
The long‑term return on these things is improving profitability using the resources that you have, the best possible. Also, there's a societal thing which, especially when you look at transportation and smart grid, is environmental. Getting the most bang for your carbon buck, so to speak, and reducing emissions as much as possible.
There's a ton of different reasons why you would do it, but it comes back basically to profitability. That's completely it.
Gordon:  For one thing, when you talk about putting in new sensors, whether it's at the consumer level or whether it's at the business level, of essentially making investments, of getting rid of things that were there today, that are presumably working at some level.
Again, am I going to buy a new refrigerator because it glows red when I'm out of milk? Probably not, but if you're a railroad and investing in some new sensors pays for itself in a year, that makes a lot more sense.
James:  Right. From the railroad examples, it's really important for them to keep everything moving at speed and also to limit misdirections.
For example, it's really important for them to do that as a train comes into a switching yard. They have to determine through analytics what cars are part of that train, how to break the train apart, and then reassemble new trains from it.
There's some percentage of misdirection that happens. A car will get misdirected to the wrong city and has to be sent back, so there's customer dissatisfaction. There's the cost, there's the wear and tear.
We're doing things like working with the railroads to improve their car detection and routing programs based on the combination of new sensors being deployed in the field like you're talking about, replacing systems that have been there 20 or 30 years, and then using the analytics on the backside to develop new rules based on the analysis of where they went wrong and where the failures happened.
Gordon:  Let's talk a little bit more about those data analytics and about the learning algorithms and the like. Are these repurposing of the types of algorithms, the types of analytics software that we have today? Or is this a new area? Is this somewhere where research needs to be done, where product development needs to be done?
James:  I definitely think there are some algorithms that are out there today. A lot of the ones that exist today came out of research 10, 20 or 30 years ago in academia. There's growing interest today in finding new sets of rules that are relevant to these systems within the Internet of Things.
I think there's going to be a burgeoning, whether it's academic, whether it's in the private research labs or whatever. We need people researching how we find these optimizations, how we detect these patterns.
It gets back to ‑‑ you and I talked about this before ‑‑ machine learning is still in its infancy. We can find the easy patterns and we can program for them, but we really need something that is smart and diligent, is going to look for patterns in and of itself through this data, find them and then bring them to your attention.
That's an area that the academics need to mature over the next five years. Then it comes out of academia and gets productized like any of these things.
Gordon:  Do you see there being specific breakouts, or is this going to be the typical type of thing, whether there's a lot of blocking and tackling and incrementally knocking off particular use cases?
James:  I think it's going to be a lot of blocking and tackling. One of the companies that I work with does acoustic detection along fiber optic lines. There's essentially a dark fiber optic cable that runs along a railroad track or along a pipeline.
It has devices every few hundred yards that are listening on that for acoustic signatures of failures or of equipment breaking. The sound of a rail with microfractures in it is different than the sound of a rail that is sound.
They are going out into areas where there are rails. They're setting these up. They're recording them and then looking for failures, and seeing the signatures of that. But it's difficult because you have to take into account that with these things the humidity in the air, the type of geography, sound propagates differently.
In this case, it's a private company working in conjunction with a railroad industry body that's like an institute and going out to all these different geographies in places with different weather patterns and different humidities and learning what failure sounds like. Running railroad cars with a flat wheel or with a frozen bearing over these and finding the signature for them.
Gordon:  Internet of Things, I'm not sure that's something most people would really associate Red Hat with. Yet here we are at the Internet of Things Expo, Big Data Expo, Cloud Expo, all the buzzwords expo. What are some of the specific things that Red Hat is doing that touch on Internet of Things?
James:  We've got several areas that we bring something special to the Internet of Things. Obviously, we have Linux. Everybody knows that we have Red Hat Enterprise Linux. Red Hat Enterprise Linux fits within a subset of these devices that are out in the field.
It obviously fits within the cloud and the data center, but also controllers, gateways and more complicated sensors. A Red Hat Enterprise Linux makes a lot of sense.
We have a suite of middleware products that are lightweight and allow us to deploy into the field and into the cloud a consistent stack of products that allow you to do things like messaging‑oriented middleware to move data around. Our Fuse ESB, which allows you to transform and translate data and act on changing the data when you need to do that from legacy formats or to interfaces like REST.
We've got a business rules management platform. Our BRMS platform allows you to tag data that comes in and when it matches particular rules, go ahead and take action, whether that action's a notification or triggering a controller that turns on or off a switch.
We also have JBoss Data Grid. If you're having to do real‑time analysis, you can store that real‑time data in the in‑memory data grid, and then have the business rules monitoring that in‑memory data cache so that you get high‑performance, real‑time analysis of that data.
When you look, you have those same, consistent tools in the back office and in the cloud also paired with things like Data Virtualization to abstract the complexities of the data from your developers. Obviously, OpenShift and OpenStack for cloud management and PaaS. We have a broad range of products that lend themselves very well to tackling the types of problems that you run into.
Typically, these are the building blocks that either individual implementers or our partners are going to use to build their own products to do these sorts of things.
Gordon:  One of the things that strikes me as you were going through that is, again, I think people tend to think of the sensors, the thermostat or whatever, but, what you're really describing is very much a massive, distributed system.
James:  That's it exactly. We looked at the industrial Internet of Things and enterprise Internet of Things as having three tiers. You've got that sensor edge device that's was going to be a temperature sensor or is going to be a vibration sensor or whatever. You may have a gateway. That gateway, there's potential legacy sensors onto the Internet.
But, there's a central tier that resides in the field, in a yard, in an airport or in a substation that gathers that data, amalgamates it, does quick analysis for quick, tactical business rules management and complex event processing, and then sends summarized data back into the cloud for long‑term, deep, strategic analysis to find new rules.
That's the complex architecture. It takes complexity to each of those levels and broad system management, programming and capabilities to be able to meet these use cases. It happens not only at the sensor edge, but at that control tier and in the cloud. It takes all three to work.
Gordon:  Just one last topic area before we close. Security.
This is obviously a pretty hot topic in the Internet of Things. What are your views on architectures and approaches? There can be some pretty serious consequences if train signals are hacked, for example.
James:  There's several aspects that are important. One is that the heritage of embedded systems is that you build an embedded system and you buy enough for 15 years. You deploy them and you don't touch them again until they die.
That's going to be a thing of the past. All these are going to be network‑connected. In some form or fashion, the level of complexity is going to depend...
But, you're going to need to manage these systems for configuration management. You're going to need to have some form of AAA [authentication, authorization and accounting] on it. You're going to need to have patching. You're going to need to have all those sorts of things.
You're going to manage it sort of like you do a cloud. You're not going to do deep, heavy system management like you would on a database system, but you have to have some control over it. I expect to see tools for that sort of management evolve over the next couple of years.
The other side of it is that you need to look at encryption and certificate‑based authentication. Certificate‑based authentication works whether you're encrypting your data or not, because it allows you to authenticate that actor is who they say they are and that it's not somebody spoofing.
Then encryption. You've got to look at encryption at rest, whether you need to encrypt your data when it's sitting, whether that's in memory somewhere, or in a file system or wherever the data sits. Can you personally identify someone from that data or can that data be used to compromise your system?
If so, you need to, fundamentally, encrypt it and keep it encrypted until it needs to be used again versus "That's just aggregate data," or data that you can't trace back or use. In that case, you may want to just encrypt it in flight.
There is some data where you may not need to encrypt it at all, but you definitely need to use certificates to authenticate that the actors in that system are who they say they are.
Gordon:  Thank you for your time. Have any last words?
James:  Yeah, I would say please come and check out redhat.com/embedded. It's the beginnings of our embedded story there. We're going to be continuing over the next few weeks releasing additional white papers and information at that site.
Please catch me on Twitter. I'm @jkirklan and would love to have a conversation with anybody that's interested in the topic.
Gordon:  Great. Thanks very much, James.

James:  Thanks. Have a great day.

No comments: