How valid and suitable are the evaluation tools, methods and metrics (identified through the research) that are commonly used?

108 6.2. Platform

Table 6.1– Node’s hardware from [5,22,23,62]

Mica2 SunSPOT Imote2

Processor

• ATM128L

• up to 16 MIPS

• ARM920T 32 bit (180 MHz)

• 60 to 200 MIPS

• 320/416/520 MHz PXA271 Intel XScale Processor

Memory

• 128 kB Flash

• 512 kB SRAM

• 4 kB EEPROM

• 4 MB Flash

• 512 kB RAM

• 32 MB Flash

• 32 MB SDRAM

• 256 kB SRAM Communication 868-870; 902-928

MHz IEEE 802.15.4 (TI CC1000)

2.4 GHz IEEE 802.15.4 (TI CC2420)

2.4 GHz IEEE 802.15.4 (TI CC2420)

Weight (g) 18 (exc. battery) 33 12 (exc. battery)

Dimensions

(mm) 58×32×7(exc. battery) 71×42.4×23.2 36×48×9(exc. battery) Cost^‡ US$ 515 for

program-ming board + 2 nodes + 1 sensor board

US$399 for SDK with 3 nodes + base

US$990 for

Imote2.Builder with 3 nodes + 2 sensor boards

‡ – prices are not all current: Mica2 from 2004; SunSPOT are current (2011) from Oracle store;

Imote2 outdated, possibly from 2007.

As such we developed our middleware on the following system (recall figure3.2):

Nodes: are SunSPOTs nodes able to run Java programs; they run the hardware abstraction layer Java library of the middleware;

BS: is a laptop where the hardware and information abstraction layers run using the Java libraries developed;

Libraries: for the hardware and information layer abstraction were developed. The hardware libraries are the same in the nodes and theBS. Nodes do not run the information abstraction library.

6.2.1 Communication Inter process communication

The architecture for deployment, using the Java development environment, is illustrated in figure6.6. In the figure there is a process that handles thepub/subsystem of the middleware, and by extension all theBS’s middleware.

The reason for this separation is to provide a centralized knowledge base and control of resources. If every application was “compiled” with all the middleware this knowledge and control would not be shared. Commonalities between requests would not be discovered, models could be different for different applications, queries would be duplicated and nodes would be independently controlled. This implies that the information abstraction components and theSD daemon should run separated from the applications’ processes.

The same problem would not apply to network abstractions and the command daemon, as they do not store any knowledge, except the information regarding known nodes, which does not

110 6.2. Platform

conflict if duplicated.

The communication between applications and this central middleware component on theBS is done through application modules. As we will describe in §6.3.5, an application instantiates an application module (or several) that will request/subscribe to the inputs the application needs. Figure 6.6illustrates how the Inter Process Communication (IPC) is planned to work.

Applications will use the application module part of the middleware to communicate with the pub/subsystem. Application modules should use a form ofIPCto subscribe and get new values from theRegistrarProduction.

Java Process

Base Station Middleware

Java Process Application Java Process

Application Module Module App

App

Module App

Java Process Node’s Middleware

Network Comm IPC

Figure 6.6– Communication within and in/out ofBS (note thatIPCs are not implemented)

Note that currently theIPCbetween application modules and theBSmiddleware is not imple-mented. The communication developed uses direct method calls, which means that applications are compiled with all the middleware infrastructure. This, as discussed, hinders the functioning of the central component. For testing purposes we developed an application that uses this middleware to issue several requests, simulating several applications. We will discuss this in

§6.2.3.

Daemon message passing

Message passing between daemons on the same Java process (recall figure 3.4) is based on queues. TheNetworkItfsends the raw data to the dispatcher daemon that identifies the daemon registered for that type of message. The dispatcher daemon then builds a message object according to the type and enqueues it on the registered daemon’s queue. After this theNetworkItfgoes back to listen for messages. This queue system is abstracted on a Dae-monMessaging class, which is extended by daemons implementing messaging functionality.

Currently no limit is set on the size of the queue. A timeout is defined for adding to the queue, so as not to lock the dispatcher. Receiving messages is handled in a separate thread.

In the sequence diagrams discussed, the active (running on a separate thread) components are delimited graphically by two extra vertical lines. TheDaemonGWRegistrarand the Meas-urementToRegistrarare not active. However, the daemons that call them spawn a thread to

call back all the registered components for the respective callback type.

6.2.2 Library details

In this prototype we have not optimized the libraries in terms of size and, as we mentioned, the same code for the hardware abstraction runs on nodes and on theBS. Therefore, the blocks from figure3.3on the sensor node and theBSshare the same code with different instantiations in each. This leads to a current SunSPOT library size of approx 284 KB (accounting for the specific sensors of the SunSPOT). Being in Java (albeit the binary format for the SunSPOT’sVM) also increases its size. The SunSPOT has 512 KB of RAMand as such the current size is not considered a problem.

As we saw in §6.1.1, when theBSbootstraps, it starts all the active components of the system.

As expected those components will be “live” as long as the middleware is running. Modules instantiated in the BSwill also “live” as long as the middleware is running. They will not be processing at all times as they will not be always needed. The same applies for sensor modules, they exist as long as the sensors are on theBAN, but may be idle if the sensor is not active³. The module alarm we discussed in §5.2.4is an exception. As it is very specific (the thresholds are defined for a particular purpose) it will only live as long as the component that created it needs.

Messages,DataValues andDataTypes are passed by reference and the last component to use them will release the reference. Garbage collection is automatically handled by the JavaVM.

6.2.3 Test application

Pulse Oximeter

HR

O2 Sat

Optic Hb reader

Hb

CO FormulaV

SV CO

ElectCard Reader SV

O2 Del Formula

O2 Del

V

Heart Rate Reader

Figure 6.7– Dependency diagram for test ap-plication

For testing the general framework we developed a test application. The application is able to request any information produced by the available modules.

Some modules will be sensor modules others will be formula based, which will need inputs from other modules. The formulae known by the middleware for this test are the ones portrayed in figure 6.7.

As we mentioned previously, they are based on cor-relations from Law and Bukwirwa [64] for oxygen delivery (O₂Del) and the Windkessel model (see Sun et al. [111]) for Cardiac Output (CO).

For generating sensor data we developed sensor services for the SunSPOTs that produce fake val-ues of: Heart Rate (HR), oxygen saturation (O2Sat), hemoglobin (Hb), Stroke Volume (SV) and ElectroCardioGram (ECG) readings⁴. There is a SunSPOT representing itself, with its light, accel-eration (on all axes) and temperature sensors.

There is a default policy implemented. A Policyis the component that performs the optim-ization, as described in §5.1.2. This default policy

3Recall that the heart-beat system from §3.6.1informs about a node’s disappearance.

4TheECGvalues were based on input we collected from a wearableECGsystem, Equivital from Hidalgo [46]

112 6.2. Platform searches for the first modules that satisfy the requirements of a request, preferring the modules that are currently already producing. This is a simple policy that, while searching, takes into account the settings (production on or off) of the modules it needs. This is the current approach of the middleware. Policies will perform a search for the current request being able to access modules’ current settings, however they do not have access to the list of active requests. This differs from the algorithm discussed in §4.2.2, which took into account all active requests. As such the implementation we made of the §4.2.2algorithm is not yet incorporated in the middleware as a policy.

In figure6.8 we can see a screen-shot of the test application that runs on theBS. Here we can see a list of available sensors, nodes and modules. It is possible to check the metadata for these components (the buttonsShow) and request the output production of any of the available modules. This request will “run” the default policy for discovering the modules to produce the requested information. In the figure there are also dialogues with the values that were being requested (O₂Del, temperature andHR). Note thatO₂Del is currentlyNot yet Available. This means that the middleware is lacking information that is needed for some module(s) that were on the tree found to produce O2Del. When that information is made available (new nodes appear) the system will make the requests to the modules and start the production. The formulae forCO and O2Del are already on the modules list. At the moment of the screen-shot, only a SunSPOT node and a (fake) Equivital node were available. This Equivital node only senses HRand temperature, so we are still missingSV,O₂Sat and haemoglobin to be able to produce oxygen delivery.

A regular application would issue the request(s) for the required information, instantiating ModuleApp(s) to receive the outputs. We will discuss this in §6.3.5.

Figure 6.8– Prototype screen-shot