Why we want Calvin available on as many devices as possible

In our series of blog posts on Calvin, we have discussed the motivation behind it, how it simplifies application life cycle management, and even how Calvin offers a financially viable business model for IoT. We have, until quite recently, not supported the really small devices — the "T" in the IoT. This shortcoming is about to be fixed.

It has been our intention from the start to make Calvin available on as many devices as possible. Ideally, we would like to have Calvin up and running on anything – all the way down to the microcontrollers in the smallest of sensors. The standard platform, which is feature-rich with all the trimmings, requires at least something on par with a Raspberry Pi to run. Clearly, we have to make some sacrifices when leaving the comforts that a full operating system brings.

In this installment, we will look at the latest addition to the Calvin family — a small runtime aimed at devices with limited resources. For the impatient, it is available for download on GitHub. For the rest of you, we will now present calvin-constrained.

Calvin for constrained devices

Not all functionality included in the standard calvin-base implementation is feasible to include on a constrained device with limited memory and processing power. Consequently, we recently released the latest addition to the Calvin family, called calvin-constrained. The new release contains a subset of the calvin-base platform written in C, targeting smaller, constrained devices with limited resources.

In order to still be a full member of a distributed Calvin system, the constrained runtime offloads some of the heavier lifting to a designated calvin-base runtime. This makes it slightly less flexible than the standard runtime, and the selection of actors is currently quite limited, but it should serve well as a starting point for work on smaller devices.

Example with IPv6 over Bluetooth Smart

The new runtime has, among other things, been tested on an nRF51 DK board from Nordic Semiconductor. In one test setup, which will most likely be quite close to how a Calvin system with constrained devices will be used in practice, we have three calvin-constrained runtimes:

• One hosted by an nRF51 acting as a sensor producing data
• One on a Raspberry Pi with a Bluetooth 4.0 and a WiFi USB dongle used for off-loading and to relay tokens
• One on a laptop used to visualize token data

In this particular setup, the sensor and the laptop are unable to communicate directly, so a relay actor is introduced between them. This will likely be a common situation in practice and Calvin offers a simple and straightforward way of handling it.

The listing below shows a small Calvin application involving the std.CountTimer, io.Print and std.Identity actors. Next to it is a graphical representation of the executing application, with the sensor (represented by the timer actor) located on the nRF51, a relay (represented by the identity actor) placed on the Raspberry Pi and the display (the print actor) placed on the laptop. In this small example, the nRF51 is acting as a sensor producing data, and the Raspberry Pi is simply relaying tokens between the sensor and the display actor. There is not yet support for token routing — i.e. having a runtime forward tokens between other runtimes not directly connected — but it is on our to-do list. Once it is in place, the explicit relay will no longer be needed, and the application can be reduced to just the source and the sink actors.

Vision

With the constrained runtime we are targeting, among other things, battery powered devices with limited capacity executing both on the bare metal and on top of an operating system. These devices will typically use wireless low power networking technologies and discovery mechanisms to find a Calvin runtime which it can then use to route data over network borders and to off-load computationally expensive tasks, enabling a constrained device to become a member of a full Calvin system, while minimizing power consumption.

Caveat

The state of the implementation is experimental, and the purpose is to explore new platforms, transport interfaces and protocols. It goes without saying that it should not be used in production in its current state, but it does provide an excellent starting point for further experimentation.