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.
