In literature various names are used for our target devices. The word mote was common in early research on wireless sensor networks, as was sensor node, or simply device, although the latter is also used for larger, more powerful devices. In this dissertation we will use the terms sensor node or just node interchangeably to refer solely to the type of severely resource-constrained devices used in both WSN and IoT applications.
When reprogramming these nodes, a new programme must be sent to them by a more powerful device. This role is referred to in literature by various names, including server, gateway, master, controller, or host, depending on the exact design of the network and the way it is reconfigured. For the work in this dissertation these differences are not relevant, and we will use host to refer to the source of the code that is uploaded to the sensor node, which is assumed to be a more powerful device with desktop-class processing capabilities.
Since our VM is an Ahead-of-Time compiler, the Java source code is transformed into native code in two steps. We will use compile time to refer to the compilation of Java code to bytecode on the host, and translation time to refer to the translation of this bytecode into native code on the device.
Finally, we follow Dalvik in naming our virtual machine after a coastal town. In this case the beautiful city of Cape Town, where parts of CapeVM were developed over the course of two trips.
Figure 1.2: Cape Town workplace
Chapter 2 Background
This chapter will introduce some necessary background knowledge on the target hardware platform, Java and the Java Virtual Machine, and JIT and AOT compilation.
2.1 Wireless Sensor Networks and the Internet of Things
Both Wireless Sensor Networks and Internet of Things are relatively new research areas.
Both deal with networks of connected devices that have to cooperate to achieve some goal.
There is a large overlap between the two, but there are also key differences.
Wireless sensor networks is commonly understood to refer to networks of very resource-constrained devices. They are usually homogeneous, dedicated to a specific application, and in many cases battery powered. On the other hand, Internet of Things applications may contain the same class of resource-constrained devices but mix in more powerful ones as well. They may have a combination of battery- and mains powered devices, and the devices used may be a combination of devices dedicated to a particular task and smart devices that happen to be in the user’s environment. One of the main challenges of IoT research is to develop ways to use the capabilities that are present in the smart devices around us to build new and useful applications.
It is this combination of heterogeneous devices, and the need to reprogramme them to run new tasks that were not part of the original programming, that makes the platform independence and safe execution environment offered by a VM an attractive option.
While there is a wide range of IoT devices, they can be roughly divided in two cate-gories. We will describe the capabilities and limitations of each of them below.
2.1.1 High-end IoT devices
Another decade of miniaturisation since the start of WSN research has allowed us to scale down devices capable of running a normal OS stack, to the size of a few centimetres.
Some of the most popular examples include the Raspberry Pi range, with the Raspberry Pi Zero measuring only 65x30 mm, and the Intel Edison at 35.5x25 mm.
These devices have capabilities similar to that of desktop PCs only a few generations ago. They can run a normal operating system like Linux and all the standard protocols and tools that come with it. Compared to the traditional resource-constrained sensor nodes, they can perform much more complex tasks, but the smallest devices in this class are still significantly larger than sensor nodes, more expensive, and most importantly, consume significantly more power.
Tung et al. [92] report measurements on the Intel Edison, one of the most low-power devices in its class, showing an active power consumption of up to 130 mA and sleep power consumption of 1.8 mA, at 3.7 V. Additionally, the wake-up response time was measured around 380 ms, while the resource-constrained CPUs described below can wake up in only a few cycles or milliseconds, depending on their configuration.
Since devices in this class are capable of running normal, well established VMs, we do not consider them in this dissertation, but instead focus on the second class of devices:
sensor nodes.
2.1.2 Resource-constrained sensor nodes
The second class of devices, wireless sensor nodes, are distinctly less powerful. They are designed to be deployed at low cost and potentially in large numbers, and to be capable of running for weeks or months on a single battery charge. As a typical example, the MICAz node [21] uses only 30mA when active and 16μA in sleep mode. More recently, the Arduino family of devices, based on similar hardware, has led to a very active community
Table 2.1: Main characteristics of the ATmega128 and MSP430F1611 CPUs
ATmega128 [65, 64] MSP430F1611 [88, 87]
Number of registers 32 12
Register size 8-bit 16-bit
RAM 4 KB 10 KB
Flash 128 KB 48 KB
Frequency up to 16 MHz up to 8 MHz
Simple instruction cost 1 cycle 1 cycle
Memory access cost 2 cycles 2 to 6 cycles
Branch cost (taken/non-taken) 2 / 1 cycles 2 cycles
Active power consumptiona 7.5 mA 4.3 mA
Deep sleep power consumption 0.3 μA 0.2 μA
Can execute code from Flash Flash and RAM
aat 8MHz and 2.7V
of both research and hobby projects.
While an enormous number of different hardware platforms have been developed, the components they use come from a limited set. Two of the most popular families of CPUs used in these platforms are the Atmel AVR and Texas Instruments MSP430. Both families of CPUs come in a large number of variations with different amounts of memory, IO ports, and physical packages, but the underlying architecture is similar for all. Table 2.1 lists the main characteristics for two popular members for both families, the ATmega128 and the MSP430F1611. Below we will describe the most important properties for this class of devices that are relevant to the work in this dissertation.
Memory Memory is split into persistent flash memory for code, and volatile RAM for data. The MSP430 CPUs have a von Neumann architecture and can execute code from both, while the ATmega’s Harvard architecture can only execute code from flash memory.
Flash memory is typically in the range of 16 KB to 256 KB, while RAM, which consumes energy even in sleep mode, is restricted to up to 10 KB. There are no caches, and since both memories are on chip, access times are constant and take only a few cycles.
Simple architecture These CPUs achieve their extremely low cost and power consump-tion by restricting themselves to a very simple design. Each instrucconsump-tion takes a fixed num-ber of cycles, varying only for taken or non-taken branches. Since most instructions only take one or two cycles, there is no pipelining or need for branch prediction. There are also
no protection rings, no memory management unit, and no floating point support.
Operating system The severe resource restrictions on these devices mean that a normal layered architecture with an OS, networking stack, and applications running on top of that is not possible. The closest thing to a widely accepted OS for sensor nodes is TinyOS [54] which provides several basic services for IO, communication and task management.
Contrary to a normal OS, TinyOS does not ’load’ an application, but is statically linked with the application’s code to form a single binary which is then programmed into the node’s flash memory. Thus, sensor node applications are often a single binary, running directly on the CPU.
Several systems exist that allow over the air reprogramming of sensor nodes [75]. In some cases these allow the entire application code to be replaced, including the reprogram-ming protocol itself [77]. In other cases the reprogramreprogram-ming system may be permanent and include other basic services, more closely resembling an operating system. But even in these cases the restricted amount of flash memory means that such a system cannot afford to spend large amounts of memory on library functions that may never be used by the application, so the services provided by such an ’operating system’ are quite restricted, leaving much of the low level work to the application.
A number of sensor node virtual machines have been developed that allow the appli-cation to be updated remotely. These obviously provide a higher level of abstraction from the underlying hardware. However, it is important to note here that these virtual machines are not an extra layer, between a lightweight OS and the application, but often replace the OS entirely, so the VM runs directly on the CPU. This kind of cross layer optimisation, or complete merging of layers is typical of many sensor networks.