Overview of TSOs and their activities

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).

90 5.2. Component interactions

5.2.1 Requests

Requests are done by modules that need information to function: application modules for the application, other modules for storage, calculations, etc. There are two main ways of receiving data: pull and push.

As expected,pullis a one-time query that is made as needed. The requesting component may need to get a list of producers from which to request the information it needs. The pull can lead to a push based request if the value is not available; e.g. the producer module does not have the inputs needed to produce, or has not yet received them. The pull request can also have a minimum “freshness”, where the requester can restrict the “age” of the information. This type of request is mainly used for getting information that is already being produced for apushrequest, as it does not entail any of the “information flow building” process.

The “push” request implies a subscription of the type of information requested and can have requirements associated. As illustrated in figure 5.5, this request leads to a chain of requests to anoptimumcalculated module tree. This tree is calculated by thePolicycomponent so as to produce the requested information. The RequestOutputSeqDiagchecks the modules to verify they are able to produce the requested values. This serves as a double check because the Policycomponent should have already enquired about this (see next section, §5.2.2). It also encompasses starting production, if not yet started, or changing the settings if this request is stricter than the currently served one. Subscription to the needed inputs is also done by the module at this point.

Figure 5.5– Request push value – subscribe (using an application as example)

5.2.2 Optimization

ThePolicycomponent is responsible for calculating the modules and their requirements to be used to comply with the subscription request. This calculation also involves optimizing the

cost of the solution according to the internally implemented policy. This “implementation-based”

policy enables the use of different strategies for optimization (battery life, higher accuracy, etc.).

ThePolicycomponent is thus responsible for discovering the tree of modules needed and the settings (capabilities) they need to use. Modules are oblivious to settings of other modules, they must however state their requirements for answering a specific request. When asked to produce within specific requirements, they subscribe to their required inputs and assume that the modules that produce them have been requested with (at least) the requirements the module needs. This centralization enables thePolicycomponent to have a wider view and control of the whole set of requests and modules being used.

Each capability has an associated cost (see figure5.6) that is used in the optimization problem.

Capabilities are also used to describe the requirements set by the requester. As seen in figure5.6, examples of parameters of these requirements/capabilities are accuracy (error), frequency of updates and sending rate. For cost we have processing, delay, energy and Input/Output (IO).

For sensor modules some of these capabilities and costs are directly related to the underlying characteristics of the sensor’s hardware (e.g. accuracy, energy, etc.).

Figure 5.6– Module’s capability and associated cost

In figure 5.7 we illustrate retrieving the producers for the inputs needed and assessing the inputs they need for the re-quest/requirements and their current de-tails. When evaluating a new request the Policy takes into account the current settings for every module and the require-ments set by the request. Since the new request can only increase or maintain the capabilities needed it only issues stricter or the same requirements. The result of the Policy optimization call is which modules to change settings (including starting their production), the ones to stop and the ones with no change (they are used in the request, but do not need to change their current settings).

Figure 5.7– Get producers

92 5.2. Component interactions

5.2.3 Producer un-registering

A producer may decide to stop producing due to change in sensing behaviour, detected malfunctioning², battery draining³, etc. The module should inform the RegistrarProduc-tion of this action. This leads to a re-assessment of the solution used. We illustrate this in figure5.8. The modules that were currently subscribing to the information being produced by the stopping module are found and the strictest request that each was serving assessed. After this, a search for another producer module (or combinations of modules) for substitution is done.

If it is not possible to find a replacement module, the requests are all re-done as if they were new requests. This re-request is done after an un-subscription to the previous requests, so as to clear the affected requests.

Figure 5.8– Producer un-registering

2Note that the middleware can detect communication losses with nodes (described in §3.6.1), but hardware malfunctioning is not part of current functionality. As such this would be implemented internally by the Operating System (OS) on the node. The middleware provides a call to notify of this stoppage.

3This function could be implemented in a policy and lead to a re-assessment of the modules to be used.

5.2.4 Alarms

In figure5.9we show the sequence for instantiating an alarm for notification of a value going out of specific bounds (e.g. seeing if Blood Pressure (BP) is within certain limits). The sequence illustrates a module creating theModuleAlarmand setting the bounds and type of value to be watched. TheModuleAlarmsubscribes to theDataValueto be monitored, with the require-ments needed according to the request from AlarmedModule. This triggers the request for production of this DataValueas was discussed in §5.2.1. TheAlarmedModulethen subscribes to the value being produced by theModuleAlarm, this type is returned when setting the bounds.

The ModuleAlarmreceives the new inputs of the DataValue being watched. When the value gets out-of-bounds theModuleAlarmpublishes the alarm. TheRegistrarProduction then sends it to the AlarmedModule. Removal of the ModuleAlarm is, of course, optional.

This implies that ModuleAlarmis no longer needed and thus ModuleAlarmunsubscribes to DataValue.

Note that the ModuleAlarm did not register its production. As such it can not be quer-ied by other modules. The rationale is that setting bounds is very specific, and pollutingthe RegistrarProductionwith this production type is unnecessary⁴.

Figure 5.9– Alarm example

5.2.5 Producer unavailable

When thePolicytries to find the modules’ tree to fulfil a request it may be unable to find a producer of a neededDataValue. In this case the requester should be notified that the request

4An argument could be made for theModuleAlarmdirectly calling back theAlarmedModuleinstead of publish-ing it. We opted for maintainpublish-ing the defined flow of data per thepub/subarchitecture.

94 5.2. Component interactions was unsuccessful. The request may additionally enter a “pending-requests” list, so that when a producer capable of producing the needed information registers, the request may be fulfilled. In figure5.10we see the associated sequence.

Figure 5.10– Producer unavailable

5.2.6 New information/value

In figure5.11we can see the sequence of messages when a new value is produced with the chaining of modules shown as the loop ofnewinput()s. In the example sequence an application is the final destination of the correlated data. We will see the case for when a sensor produces the information in the next chapter.

Figure 5.11– Data new value

5.2.7 Un-subscription

When a module unsubscribes to an input (e.g. aModuleApp) it may trigger several un-sub-scriptions from the tree of modules working for the unsubscribed information. Each producer module re-assesses its requirements according to the new strictest request, which might not

change if the un-subscription did not pertain to it. TheRegistrarProductioncentralizes the un-subscription and informs all the producers affected by this change. The modules may need to change their subscriptions; make new and/or unsubscribe to current subscriptions. Note that the Policycomponent always informs the modules of the requests they are serving even if they are not stricter⁵. As such, the modules know what they are servicing. The system is always tuned to the strictest request according to the optimization criteria used.