Ahem. Long time no talk on this blog… sorry about that  🙄

I have been spending the last few months working on the definition of what would be the requirement of an Open Source M2M development environment, which has led to the Koneki project proposal. You may have not seen the proposal, so let me use this blog post to explain the purpose of Koneki with more details than in the proposal.

M2M you said?

Yup, M2M. I apologize to Modeling Gurus, but I do not really mean “Model-to-Model”, but rather “Machine-to-Machine“. That is to say, the technologies that allow both wireless and wired systems to communicate with other devices of the same ability.

Let me take the example of a company who sells a home automation solution. This company wants to provide the end-user with a turnkey packaging including a communicating box acting as a gateway between the peripherals (thermostats, light dimmers, alarm system, …) deployed in the house, and a server in charge of centralizing the collected data. The server will then allow both the house owner to remotely monitor is house (e.g. use an iPhone application to turn the heat down), and the solution vendor to manage its fleet in centralized manner (deploy firmware upgrades, collect usage statistics, etc.).

Tooling for M2M development

While it is fairly reasonable to say that half of the time needed to develop an M2M solution is spent solving problems related to the embedded nature of such a development, there are still a few areas that are not covered by nowadays embedded development

Protocols support

M2M solutions usually involve the use of two different kinds of protocols, both of which need to be supported by an M2M-oriented IDE.

1. Embedded protocols – These are the protocols allowing an M2M module to communicate with the assets it is connected to. In the Home Automation use case, that would be the dimmers, the temperature sensors, and so on, and the protocol would likely be X10. For other use cases, we would have Modbus, Zigbee, or virtually any kind of proprietary communication protocol over Ethernet, RS-232, or whatever.
   Supporting these protocols in Eclipse consist in giving developers the ability to interact with the assets independently of their protocols: configure them, access values, send commands, etc. It is also interesting to provide a protocol analyzer (a la Wireshark) allowing to get a human-readable “dump” of all the frames exchanged by the M2M module and its assets.
2. Client/server protocols – These are the protocols allowing a box to communicate with an M2M Server. The M2M server is in charge of centralizing data (temperature, …) and events (fire alarm, …) sent by all the devices paired with it, as well as to send commands (dim the light, …) to these devices. The M2M server usually exposes Web Services APIs to allow system integrators or end-users to manipulate the data to build their own UIs (web sites, mobile phone applications, …).
   There are many M2M use cases where the communication between the box and the server is made using GPRS or 3G connection (Home Automation might not be one of these use cases, because the Internet connectivity is likely provided by an ADSL box…). For these use cases – where we’re speaking of thousand of billboards, solar panels, power meters, … – it is very important to use a dedicated protocol which optimizes the bandwidth usage. Koneki will provide the developer with a way to easily “decode” binary frames into a human-readable form, relying on an extensible mechanism allowing to plug-in support for any protocol.
   Since mobile communication costs tend to be quite expensive,  we want to give the developer more visibility on the bandwidth consumption of its application. For example, will it use more bytes to send a temperature value every 5 minute, or instead send 12 acquired values every 1 hour (possibly benefiting from a compression algorithm).

Component model

In order to enhance software reuse across different M2M applications, Koneki will expose a data/event-driven component model allowing to isolate correctly every functionality of the system. The development environment will use the component model to provide the developer with ways to validate the consistency of its application, to generate its documentation, or even use a visual programming approach to design components graphically (a la Google App Inventor)

Simulation

M2M servers usually are hosted solutions (SaaS or PaaS), making it a bit difficult to diagnose communication problems of an M2M embedded application. Koneki will provide an M2M server simulator to give the developer a better understanding of how his M2M box is interacting with the server, how it deals with timeouts, communication errors, etc.

Lua support

Many M2M modules are programmable using the Lua language (very lightweight scripting language). We not only want to improve the support of Lua itself in Eclipse (another Eclipse project may be created as soon as this tooling becomes mature enough), but also improve the integration of vendor-specific stuff such as: packaging of Lua libraries, communication with remote applications using LuaRPC, etc.

Contribution opportunities

If you’ve gone through the Koneki proposal, you’ve seen that Sierra Wireless’ initial seed will be largely Linux oriented, since this is the OS that Sierra modules are running. However, there are many other M2M modules out there, some of them offering a JVM with an OSGi runtime, other are running dedicated RTOS (e.g. Nucleus) exposing C or C++ APIs, etc. And we want Koneki to seamlessly support all theses different flavors of M2M environments.
Kai Kreuzer from openHAB (a very-cool OSGi-based runtime for Home Automation, with Eclipse tooling easing the configuration of the system) has already expressed interest in the project, and we are also looking forward to work with the Itemis guys behind Yakindu (a modeling environment for embedded systems) to come up with a common component model for M2M systems.

Koneki project is in its proposal phase, so please let us know (best way to do so is to use the dedicated Eclipse Forums thread) if you have any interest in it, … the more the merrier!

Learn more

I will be at EclipseCon this week, along with my workmate Gaétan Morice, so please feel free to come ask us further information on Koneki. Also, we will run a “Machine-to-Machine at Eclipse” BoF on Wednesday, 7.30pm (be careful, the room is likely to change). The aim of the BoF will be to discuss not only the requirements for an M2M IDE – which is the scope of Koneki, but, more generally, what an M2M reference environment should be: standard client/server communication protocol(s), programming model, component model, etc.

Oh, and by the way, Koneki is a Maori word meaning “here”, “this place” ; and is  a great metaphor of M2M: you communicate with many remote devices without moving from where you are.