Case Study

86 5.1. Pub/Sub system

Application

Base Station

Hardware Abstraction Application

Registrar Production Policy

Information Abstraction

Middleware

Module

Figure 5.1– Pub/sub architecture

(e.g. sport news, medical information) or on the content of the event (e.g. events that mention Body Area Network (BAN)).

In our system, modules (the Software (SW) components that correlate information) subscribe to a type of event and publish to the system the information they produce. This is portrayed in figure5.1. A specific component acts as the broker (RegistrarProduction) and aPolicy component is responsible for finding the best module configuration (i.e. the set of modules that will produce the information requested while satisfying requirements) for the current application requests, using the models provided. The hardware abstraction layer enables requesting and receiving the “raw” sensor data.

As such ourpub/subsystem has:

• software modules that correlate information by publishing their outputs and subscribing to their required inputs;

• a framework to allow optimization of resource usage, taking into account modules’ “costs”;

• different types of modules providing different functionalities.

In the next sub-sections we describe the different modules and brokerage.

Figure 5.2– Module types

As we discussed, a restriction imposed is that the dependency graphs (e.g. figure4.1) do not have any loops. This is so as not to cause feedback loops in thepub/subsystem and to facilitate the optimization process. As such, the graphs are Directed Acyclic Graphs (DAGs), where the direction is given by the information flow.

A module has some capabilities and a cost that describes how it is capable of producing a specific output. Modules can (and should) be implemented by the application developer if a specific correlation or functionality is not present. There are several types of modules already developed. These are abstracted in an inheritance tree as shown in figure5.2.

Registrar Production

Module Sensor Measurement

ToRegistrar DaemonGW

Registrar

Hardware Abstraction Service

Discovery Daemon

Dispatcher

Daemon Sensor Hardware Abstraction Service

Base Station Node

Figure 5.3– Module sensor data flow Some notes:

• A module is a “dumb” component, in that it does not take any action regarding optimization.

Modules always assume that some outside component coordinates the different modules for the production of the cascading outputs. As such they only subscribe to inputs needed, assuming that their frequency, accuracy, etc. have been set by this other component (in §5.2.2we provide more detail);

• A module knows about the requests made to it that are currently active. This is used for un-subscriptionssent to it (it changes to the most stringent requirement that it currently holds).

88 5.1. Pub/Sub system The first module we discuss, is the one that represents the sensors from theBAN. Figure5.3 shows the interaction of the different middleware layers for discovering a new node and receiving data from nodes. When a new node appears in the system it advertises itself using the Service Discovery (SD) function, as described in §3.6.1. This is received by theSDdaemon on the Base Station (BS) which notifies a DaemonGWRegistrar. This component then creates as many sensor modules as the sensors the node advertised. The information regarding the node and the sensor characteristics is kept in the structures pictured in figure5.4. The location of a node is defined as a point with set coordinates in the body. A sensor is positioned according to this coordinate system¹. ADataValue, or a measurement, is related to a sensor as we mentioned in chapter3.

Figure 5.4– Module sensor AModuleSensor maps the requests made to

it to commands for the sensor. When the sensor produces data it flows to theBSusing the specific communication system. TheDispatcherDaemon component is responsible for de-multiplexing the messages received by the network, in this case a message with a measurement. This is sent to the MeasurementToRegistrarcomponent that dir-ects it to the module that is responsible for this sensor. The module then publishes the data on the RegistrarProduction.

The ModuleCalc abstracts a type of module that does calculations. It can be a formula-based module (ModuleFormula) where formula-based

calculations are done (e.g.O₂DelF ormula); a statistics-gathering module (ModuleStats) or a table-based output module where the output results from a table lookup (ModuleTable).

ModuleApplicationis the counterpart of the application. This is used by the application to interact with the architecture, where it subscribes to the information requested.

TheModuleStorageis a module that enables storage of values produced outside the module and access to that data.

ModuleAlarmchecks the value of the information subscribed to and sees if it is within some specified limits. It is a simple check of being within a range. If an average or other statistic over time is needed, a combination withModuleCalccould be used (discussed further in §5.2.4).

The interfaces represented in figure5.2: ModuleSubscriber, ModuleRequesterCall-back and ModuleCallbackSubscriber define respectively the interface for subscribers, requesters (where a callback is defined for error information) and both subscribers and requesters.

Data structures

The relevant data structures used in the information abstraction layer are:

• DataValue: this is the structure that carries the information produced. It entails an accuracy attribute that is updated as the modules compute the values in the modules’ chain. Part

1Although we have a data structure for this we have not yet defined the coordinate system to use. We come back to this in §5.4.1.

of the metadata is also a timestamp that defines when the data was produced. Forrawsensor data, the sensor details are also included together with the location of the sensor (see figure5.4);

in this case they contain the measurements from the sensors;

• Requests: a request contains the information needed and the requirements (delay, error, etc.) for getting it. It is used when subscribing or asking for a specific output. AModuleRequest is used by thePolicyclass (see §5.2.2) when calculating the modules needed for producing a specificDataValue.

Modules are in essence programmable components that take inputs and produce an output.

As anothermoduleexample, they could re-order out of order measurements/data values received.

In §3.5.2, we mentioned that only if a reliable connection is established messages arrive in-order.

A module could, for the case where the channel is unreliable, check the timestamp of said measurements and re-order them. In most cases, what is more natural is to discard out-of-order or delayed measurements. This illustrates that a module can provide a varied set of functionalities.

However, its strength is also its ability to be re-used. As such, a module should be develop to provide a single functionality.

Modules can be instantiated and managed by other modules, the registrar or an application.

When modules create other modules some attention is due, as this may lead to problems if, when the owner module stops or is destroyed, it also stops/destroys its owned modules (that in the mean time were being used by others).