Simplifying complex systems with Internet of Things

This article originally appeared in Internet of Things-Architecture's community newsletter and reprinted with permission.

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

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.