OTAP Method

In addition to the results of this thesis and [P1], the implementation of a router node of low latency TUTWSN [104] was ported on HybridKernel in a research project [161].

The router nodes listened continuously for incoming packets. Compared with a non-interrupting loop kernel, HybridKernel port increased the packet receiving capability of the router nodes by reducing the packet handling delay. As a result, HybridKernel port improved low latency operation. In addition, HybridKernel port reduced code complexity. Respectively, it increased both data and program memory consumption.

The increase in the data memory consumption was 477 B that was 12% of the avail-able data memory. Energy consumption was not considered, since the low latency TUTWSN routers are mains powered due to the continuous listening.

3.2.3 Discussion of the Results

The requirement for hybrid design has been discussed in the literature. Strazdins et al. [190] reasoned that both cooperative and pre-emptive scheduling should be supported by the WSN OS according to the reported WSN deployments. Watfa and Moubarak discussed the same requirement in [213]. Both articles were published after the publication of HybridKernel.

HEROS [132] has a similar hybrid design as HybridKernel, but was published five years later in 2014. TinyOS and Contiki have external libraries for pre-emptive tasks.

These libraries are not integrated into the kernel design, which requires special API functions that require attention from the application programmer. LIMOS is a hybrid kernel, but it conducts pre-emption inside cooperative event-handlers, which does not reduce overheads or improve timing accuracy between the event-handlers.

3.3 OTAP Method

An OTAP method is needed to fix software errors and add new features to OSs, protocol stacks, applications, and other WSN software when the WSN is deployed.

VMs and loadable library methods only allow the applications and predefined soft-ware components to be updated. In addition, both methods add execution overhead.

Firmware dissemination methods are not suitable for small updates and new applica-tion disseminaapplica-tion, which is solved by incremental disseminaapplica-tion methods. However, they have complex and device specific implementation, add overhead, and degrade in efficiency on large updates. Rateless codes can be used to reduce transmitted data, but they add execution overhead and do not provide any new methods.

WSN Node HW

Applications PDL Process

Y 2. PIDP Node specific applications are disseminated

separately as PDL processes through the WSN protocol stack

GW

Fig. 15:The firmware OTAP and the application dissemination method with PIDP and PDL.

The combination of PIDP and PDL forms a robust and energy efficient method for a WSN OTAP that allows both firmware updates and application dissemination as pre-sented in Figure 15. PIDP allows the same firmware to be used for the whole WSN.

The newly deployed nodes are automatically programmed with the newest firmware, which reduces maintenance and tracking of software versions. PDL allows node-specific applications, which can be dynamically and automatically updated. Both PIDP and PDL have been implemented for PIC18F8722 MCU and have been shown to feasible with proofs of concept in [P2] and [P6].

PIDP [P2] is a firmware dissemination method that clones all of the new software hop-by-hop from node to node. PIDP does not require fail-safe firmware on an energy-consuming external flash, since it has a robust fall-back method. Since PIDP is not part of the updated firmware, PIDP can always start a new transfer with a neighbor through an advertisement channel, if the updated firmware or the transfer fails. PIDP ensures that the whole network is eventually updated, even if some nodes are not within the reach of the network when the update starts. Furthermore, a new node without existing firmware can be deployed to the network and the PIDP will automatically clone the newest version from one of the neighbors.

Similar to other firmware dissemination protocols, PIDP is not well suited for

ap-3.3. OTAP Method 37

plication dissemination. The application software must be the same for of all the nodes, which wastes program memory and complicates the network configuration.

Also, a separate configurator program is needed to define which applications can run on which nodes [P2 - P3]. Using PDL for the applications solves this issue. It is presented in detail in Chapter 5 and [P6]. PDL describes the application process as a byte code, and the PDL processes are disseminated using the WSN protocol stack, similar to the VM updating method. This method allows for unique application pro-cesses for each node, which can be added, updated, and removed separately of the WSN firmware updated by PIDP.

3.3.1 Proof of Concept Implementation

PIDP requires 6389 B of program memory and 22 B of data memory when imple-mented on a PIC18F8722. A receiving node consumes 1469 mJ of energy and 74 s of MCU time during one update on the TUTWSN WSN node platform at 4 MHz.

A sending node consumes 1550 mJ of energy and 49 s of MCU time. The execu-tion time difference is due to the verificaexecu-tion of the transferred firmware. The energy consumption difference is due to the different radio listening times. If the advertise-ments can be done as part of the protocol stack signaling, as in TUTWSN, they do not increase energy consumption. As a result, one update on PIDP consumes under 0.01% of the available 20000 J energy. The PDL proof of concept implementation is covered in Chapter 5.

3.3.2 Discussion of the Results

The related OTAP methods are not efficient for both tasks of updating software and disseminating applications. This thesis shows that software updates can be efficiently and robustly done with PIDP. It does not require energy consuming external flash, updates all of the software, and has a robust fall-back method. To allow application dissemination, a separate abstraction of PDL provides an efficient solution for fre-quent application changes on heterogeneous nodes, as it works on top of the WSN stack. In conclusion, PIDP and PDL complete each other. PDL could be replaced with a VM approach, but PDL has a higher service level abstraction through the em-bedded cloud, as presented in Chapter 5.

4. REVIEW ON INFRASTRUCTURE ABSTRACTIONS FOR