Introduction to M2M at Eclipse – welcome Koneki
Originally appearing in JAX Magazine, Benjamin Cabé introduces Koneki – the new Eclipse venture into M2M technology – included in the Juno release train
——One of the biggest challenges companies are faced with when building M2M solutions is that they have to deal with a lot of engineering problems, from embedded development to web development – including industrial protocols like manipulation – and there are many different tools to address these different tasks. Koneki aims to provide a set of tools that put them all in a single place. Just a year after its creation, the Koneki project is part of the Eclipse Juno simultaneous release. Koneki you say? Koneki is a word from the Māori language that means “this place”. The goal of this project is to deliver tools that integrate seamlessly into the Eclipse environment and to allow an M2M developer to develop, simulate and test his or her application more easily. On the next few pages, you will learn more about Machine-to-Machine (M2M), and will be walked through the most interesting features of Koneki.
Introduction to Machine-to-MachineYou may be familiar with the term Internet of Things (IoT). Both that and M2M come down to the same idea of connecting virtually every object you can think of to the Internet – allowing devices to share important data, as well as to be remotely controlled.
By 2020, there will be around 50 billion connected physical world devices.
There are many domains of everyday life where M2M is changing the way we interact with objects, and it is opening the door to a tremendous number of applications. One good example of such a domain is healthcare, illustrated in Figure 1. Connecting things such as blood pressure or heartbeat sensors to the Internet enables third parties to create modern web or mobile applications using the collected data, while enabling the sensors’ manufacturers themselves to upgrade them remotely.
However, most of the M2M solutions already deployed usually rely on proprietary technologies and communication protocols, which seriously hinders the growth of the M2M market…
M2M Industry Working Group Initative
At the end of last year, a number of members of the M2M ecosystem decided to create an Industry Working Group under the umbrella of the Eclipse Foundation to address the main issue of solutions currently being developed: their lack of interoperability. The objective of the M2M Industry Working Group (M2MIWG) is to collaborate on providing the enablers for M2M solutions development: communication libraries, application frameworks, and development tools (Figure 2).
There are at the moment two Eclipse Technology projects coordinated by the M2M Industry Working Group: Paho and Koneki (EDITOR’S NOTE: Mihini arrived in August, not longer after publication date)
Paho is a project that aims to provide implementations of lightweight protocols that can be used in M2M and IoT applications. The initial contribution to the project is from IBM and Eurotech, in the form of C and Java client libraries for the MQTT protocol. MQTT (Message Queue Telemetry Transport) is a messaging protocol over TCP/IP enabling bandwidth-efficient exchanges between communicating devices.
As stated in the introduction of this article, Koneki’s goal is to deliver tools that simplify the development of end-to-end solutions, from the creation of embedded applications to the simulation of communication scenarios, including the development of end-user applications.
Lua, a very lightweight yet powerful programming language
Lua (pronounced “loo-ah”) is a programming language invented in Brazil in 1993. It was originally designed to be easy to embed into other applications. As a consequence, it is very lightweight and written in pure ANSI-C, which makes it easily portable to various platforms as small as microcontrollers with only a few hundreds of kilobytes of RAM and Flash. There is also an optimized flavor of Lua, called eLua, which goes a step further in terms of optimizing the Lua runtime for very constrained targets.
Lua is very easy to learn, and many vendors of game and mobile development platforms now propose it as the primary language for writing applications.
Lua for Machine-to-Machine Development
You may wonder why the biggest component of Koneki is an IDE for Lua, called Lua Development Tools (LDT), and not something with a stronger M2M focus. The answer is very simple: We believe that one of the biggest obstacles to create industrial M2M solutions is the complexity to develop the applications that are embedded on the communicating devices on the field.
But keep in mind that there are many domains with business opportunities for M2M solutions, and people do not want to have to learn a complex language such as C, when all they want to do is manipulate a few data structures and send them to a remote server. What if Lua could be used to simplify the development of embedded applications, thus following the path of numerous mobile and game? Lua is very easy to learn and used by many vendors of game and mobile development platforms.
Getting Started with Lua Development Tools
Lua Development Tools can be installed either from the Juno repository (in the Programming Languages category) or from the Eclipse Marketplace. The easiest way for you to start using LDT is by creating a new project using the File | New | Other… | Lua Project wizard. You can either start an empty project, or reference existing Lua sources. When finishing your wizard, you will be asked to switch to the Lua perspective (which you should use!) – and voilà!
In order to provide a really smooth experience for developers not necessarily familiar with programming in the first place, it was important to have first-class Lua support in Koneki.
Lua is a dynamic language, which means that it can be very tricky to provide content-assist, code navigation, etc. when there is no typing nor real distinction between variables, function declarations, etc. LDT is built on top of DLTK (Dynamic Languages Toolkit), which helps in providing basic code editing features, but we had to work on enriching the code parsing so the IDE can be —to some extent— type-aware.
One of the key enablers of this feature is that we worked on the definition of a documentation language that allows a fine description of Lua modules’ APIs. Not only does it allow to offer nice documentation views and pop-ups (à la Javadoc), but it is also what makes content-assist possible, as well as code navigation (e. g. quickly go to the declaration of a method). In the listing below, you can see what the documentation of the Lua standard IO module looks like, and how it enables content-assist (Figure 3).
------------------------------------------------------------------------------- -- Input and Output Facilities. -- The I/O library provides function for file manipulation. -- @module io ------------------------------------------------------------------------------- -- a file handle. -- @type #file ------------------------------------------------------------------------------- -- This function opens a file, in the mode specified in the string `mode`. It -- returns a new file handle, or, in case of errors, nil plus an error message. -- The `mode` string can be any of the following: -- "r": read mode (the default); -- "w": write mode; -- "a": append mode; -- "r+": update mode, all previous data is preserved; -- "w+": update mode, all previous data is erased; -- "a+": append update mode, previous data is preserved, writing is only -- allowed at the end of file. -- The `mode` string can also have a '`b`' at the end, which is needed in -- some systems to open the file in binary mode. This string is exactly what -- is used in the standard C function `fopen`. -- @function [parent=#io] open -- @param filename -- @param mode -- @return #file ------------------------------------------------------------------------------- -- Equivalent to `file:close()`. Without a `file`, closes the default -- output file. -- @function [parent=#io] close -- @param file -- [...]It is possible to use a mechanism similar to the target platforms of PDE (Plug-in Development Environment) that allows storing in a ZIP file the definition of the Lua APIs visible from a developer. We call this file an Execution Environment, and while we don’t deliver any of them in Koneki yet, we have made available the Lua 5.1 Execution Environment on Sierra Wireless’ GitHub repository.
Debugging a Lua application
Besides its very powerful content-assist mechanism, Lua Development Tools 0.8 comes with a debugger that can be used with virtually any Lua runtime. It comes in the form of a DBGp (DeBuG protocol) client written in Lua, which can instrument a Lua script to make it talk to the debugging server running in the IDE.
In order to use the debugger, you just need to include two files (debugger.lua and debugintrospection.lua) in your Lua path, and add the following statement before the code you actually want to debug: “require(‘debugger’)()”. It is also possible to automatically inject the debugger into any existing script by using the following command-line syntax: “lua -e “require(‘debugger’)();” MyApp.lua”.
Since debugging works by opening a server in the IDE, you have to launch your debug configuration prior to running the instrumented Lua script. Creating a debug configuration is done via the usual Run | Debug Configurations… menu (Figure 4).
As long as your Lua virtual machine is not too funky (e. g. it is better to have loadstring support), basically every debugging feature you would get when developing for Java will be available to you: breakpoints (including conditional breakpoints), variables exploration and modification, interactive expressions, console, multi-threading (coroutines) debugging, etc.
Other tools available in Koneki
Earlier this year, we made available an Eclipse plug-in that allows configuring and running OMA-DM simulations. OMA-DM is a standard communication protocol widely used in the telecommunications industry to monitor and synchronize the state of communicating devices such as mobile phones, or the kind of modules you might find in an M2M solution.
The user interface of the simulator is a forms editor that offers a visual representation of the simulated device’s data tree, and an interactive dashboard allowing monitoring of the OMA-DM packets going back and forth between the client and the server (Figure 5).
While it is still at a very early stage, we are working on the definition of a model of M2M applications whose goal will be to express important information such as: data manipulated by an application as well as the protocols used to exchange this data with other actors of an M2M solution, dependencies towards specific hardware capabilities or software libraries, etc.
We believe that such a model will facilitate the creation of extensible tools, by allowing third parties to develop their own extensions, for example, a bandwidth estimator for a specific communication protocol. We also think that this model can be leveraged at runtime, for example by letting an M2M developer have data access APIs that hide the complexity inherent to the serialization/deserialization of data on the wire.
The first version of this M2M model is already available in the Git repository of the project, and focuses on the description of the data manipulated by an application. It addresses the specifics of M2M, for example by allowing a distinction to be made between data that is to be only sent to another machine vs. data that can also be updated remotely, or to describe operations that can be executed remotely.
The requirements for this M2M model are discussed within the M2M Industry Working Group, where real-life use cases are used to nail down the core notions that the model should cover.
You may wonder what is to be expected for the next releases of Koneki, especially what we will do to add more M2M content to Koneki. Our next hot topic is to work on the contribution of a Lua application framework that could run on virtually any kind of Linux platform, and would simplify the remote management of the system, the IOs manipulations, the access to the network, etc. We are also looking at addressing the huge community of makers and hobbyists who demand a platform that would simplify access to communication APIs (SMS, 3G connectivity, etc.), remote management of embedded systems (over-the-air firmware upgrade, monitoring of network status), and so forth.
Also, the Koneki team is really looking forward to working on providing a complete M2M-oriented modeling environment, together with the Damos team. Damos is a recently proposed Eclipse Tools project whose scope is to provide an integrated development environment for developing data flow-oriented systems using block diagrams.
We are working on the plan for our 0.9 release that we expect to deliver at the end of the year, and are very much looking for community inputs, so feel free to stop by our forum or our mailing-list to raise your voice! We want to release a 1.0 version together with the Kepler train next year, fun times ahead!
This article appeared in the JAX Magazine.