In the next couple of years, there are expected to be 2
billion people connected to the Internet. At the same time, the instrumentation
and interconnection of the world‚ human-made and natural systems, from cars to
water to even cows, is exploding‚ which could mean that there soon will be more
things connected to the Internet than there are people who are connected.
This
Internet of Things promises to give people a much better understanding of how
complex systems work, so they can be tinkered with to make them work better.
But to open up these opportunities for everyone significant strides need to be
achieved to make programming sensors and wireless networks easy. Thankfully
there are several scientists including Dr. Thorsten Kramp at IBM Research in
Zurich that are addressing this very problem.
"Sensor networks are instrumental in creating a smarter
planet, therefore it is critical to make them easy to pro-gram", comments
Thorsten Kramp, co-developer of a technology called Mote Runner. IBM Mote
Runner is a run-time platform and development environment for wireless sensor
networks. He adds "We invented Mote Runner to enable developers to take
advantage of the skills they have and apply them to programming wireless sensor
networks. This should proliferate the use of sensor networks around the world."
The IBM Mote Runner SDK bundles a set of tools to develop
WSN applications together with the IBM Mote Runner edge server and the IBM Mote
Runner firmware for selected hardware platforms. On-mote applications can be
developed using Java and C#, and can be run in a simulated environment and on
real hardware alike.
Applications further can be dynamically loaded and deleted
over the air without requiring physical access to the mote. The SDK further
facilitates source-level debugging in Eclipse against the simulation
environment, and the development of web applications to visualize and inter-act
with wireless sensor networks running IBM Mote Runner.
Thorsten has been with IBM for more than ten years.
Initially he worked on IBM JCOP, IBM's JavaCard solution, which the company
sold to NXP in 2007. Before IBM's involvement in this area everybody thought
that Java was too slow on smartcards, until the IBM JCOP implementation proved
that the benefits of programming smartcards in Java actually did not come at the
cost of diminished performance at the application level. Today the code is on
millions of VISA smart cards and electronic passports.
It was this experience in developing virtual machines for
small devices with a matching tool ecosystem that sparked IBM's interest in
wireless sensor networks and eventually led to IBM Mote Runner.
Aside from technical advantages such as being able to
program a wireless sensor network in a high-level object-oriented language, IBM
Mote Runner's shielding of applications from the underlying hardware by means
of a virtual machine separates application developers from run-time platform
providers and hardware manufacturers. As such, in combination with high-level
APIs, it allows the encapsulation of underlying hardware particularities within
the run-time platform which otherwise riddle application code and generate
vendor lock-ins.
Mote Runner makes wireless sensor networks easier to program
IBM Mote Runner hereby introduces a layer of interoperability
at a level where different actors in the current IT business theoretically
should be able to profit from. This process resembles key issues in IoT-A in a
sense that interoperability (technically and semantically) has to be handled at
one particular layer instead of being spread out across all layers and spilled
into application code. Otherwise there won't be one Internet of Things but
rather lots of Intra-nets of Things.
At the same time it is crucial that intelligence is
distributed within the Internet of Things. That is, local sensor net-works and
devices do not need to be connected to the Cloud all the time but may operate
autonomously over extended periods of time. In an open office, for example, it
makes no sense to light up the whole office when only one person is working
late.
Yet studies show that with only a single lamp illuminating just the late
worker's desk, humans feel uncomfortable and start seeing things in dark
corners. A situation not really helping them to concentrate and focus on what
they are there for in the first place. Manually configuring a pleasant ambient
light setting is not a solution either, but a wireless sensor network of floor
lamps based on IBM Mote Runner could do the trick. In this example, floor lamps
detect their relative position to each other themselves and in combination with
motion detection sensors determine a suitable ambient light setting
automatically. Another example is active escape route signaling.
Here a wire-less sensor network running IBM Mote Runner
dynamically classifies what escapes routes are possible in case of emergency
based on conditions such as visibility, temperature, or toxic gas
concentration. Since in emergency situations there may be no backend
connectivity anymore, the system has to run and execute decisions on its own.
In general, as life is real time, things and situations
change in real time as well. We therefore should not think about our systems as
being ideal breakdowns are always possible. This, however, also has legal and
liability implications. For instance, in the current legal frame-work it is
virtually impossible for large clients like air-ports not to have default
escape routes laid out and warning systems installed that are heavily
connected.
These issues also have broader connotations for making decisions on
a large scale. Holland, for example, aims at improving its water infrastructure
to basically make decisions autonomously on the best real-time data and
scenarios within the next couple of years as managers and civil servants might
be too slow or overwhelmed by the amount of data at critical moments. So, in a
way, one could say that their new role is more in the middle of the process,
assessing procedures and outcomes in an iterative way, much more resembling the
design process itself.
In its Smarter Planet vision, IBM identified these as
real-world issues and focused, among other things, on harmonizing the back-end
processes. Selling sensor nodes is not the priority for IBM, but sensor network
most certainly are important as an interoperable backbone, as a means to an
end. The IBM Mote Runner specs therefore are open and free (and, according to
IBM's download statistics, used by quite a lot of people), for others to build
functionally compatible platforms. IoT will engender and facilitate many
networks and their need to be interoperable both from a technical and
architectural point of view. That is where IoT-A comes in. As a concept of
interoperability it is complimentary but it also addresses the higher ground of
policy and contributes to the discussions on broader architectural issues.
In general, there are three types of sensor-network applications.
Firstly, those people not knowingly interact with like active escape route
signaling. Secondly, those that we somehow know of a little bit but not really
can edit or modify. Home care and elderly care systems come to mind. And
thirdly, those that people can set up, program, and interact with themselves,
for example a wine maker putting sensors in a vineyard to monitor current soil
humidity conditions and trigger irrigation systems in response.
Each type of application requires different types of interaction,
reliability, liability, and security. IBM has focused so far largely on the
first two, but as developments in the Internet of Things are enabling groups of
people to self-organize more on all kinds of services, it is conceivable that
they will be vectoring in other qualities, looking for the cutoff point of
interoperability and plug and play in that third type of application.
In the past two years, for example, local pollution and
noise and energy sensors grabbed a lot of publicity in the social networking
and blogging sphere, whereas IBM has been negotiating with key decision makers
in institutions, cities, and governments. It is also there that the social and
psychological issues are becoming more important. And even though it may be
that the Facebook Generation seems to be not really worried about the way they
share data and personal information, there is another trend towards more privacy
awareness. In many applications such as smarter ticketing, for example, privacy
concerns have to be considered right at the beginning of the engineering and
design process.
It is precisely because the back end and real world issues
(the "front end") are coming together so fast that collaboration on
infrastructure becomes so important, not only for IBM, but for all kinds of IT
providers. One of IBM's core businesses is data analytics and data management
making sense of large amounts of data, in a word.
That is what IBM offers and
having a framework which allows interoperability on different layers then
becomes obviously very important. IBM therefore welcomes and facilitates open
standards and open platforms. If we can agree on not competing on but sharing
functional specifications, then we can differentiate and compete on
non-functional features such as performance, privacy, security and reliability.
Nobody can live on its own which makes IoT-A such an important project as it
tries to establish this kind of common understanding.