Section 4: Interviews with TSOs
4.5 Evaluation measures
In §5.1.1 we described a structure for storing the location of nodes in the human body.
However, we do not have yet a global coordinate system for it. Further research is needed to adopt a system that fits our framework, perhaps basing it on the work done by the International Society of Biomechanics [136]. Moreover, there are several medical terms databases that aim to provide a connection between the medical language and computer systems. The objective being that the latter canunderstandthe former. Good examples areSNOMED-CT[55] from the International Health Terminology Standards Organisation andUMLS[72] from theUSANational Library of Medicine11. These thesauri also define anatomy terms and thus identify body parts.
Combining both systems, a coordinate accurate positioning with a recognizable body location, would provide an interesting challenge.
Signal “cleaning” modules could pose some issues for the current middleware. These type of modules would try to “cleanup” signals according to known noise models or similar approaches.
11UMLScombines definitions from several other databases includingSNOMED-CT.
102 5.4. Conclusion They would thus produce as output a “cleaned” version of their input, which would be the same type of information. Given the framework we described, this could cause some problems when subscribing to the information. Other modules could impose some requirements on the information that would lead the Policy to choose the “cleaned” version. However, if the information would not be clearly marked as a different type the “cleaning” module would receive its own output from thepub/subsystem. A way to mark this functionality should be defined by the middleware so as to allow these types of modules to differentiate their own production.
TheRegistrarProductioncan have more than onePolicy. However, when a request or a subscription is done only one policy is used to calculate the requests. The subscriber can state which policy to use for the request; this enables using different policies on different requests. A default policy is used when no policy is specified. Although this approach adds the flexibility mentioned, it also creates the problem of optimizing the different requests according to different policies (e.g. optimizing to the least error possible could conflict with energy saving). This point leads to the issue of application prioritization. Some applications might need a more detailed and
“energy costly” information while others want to prolong theBANas long as possible. Currently priorities are not handled in the framework. Priorities lead to decisions on: i) at what rate can we sense and send, ii) given current energy level what should we sense and iii) given a limited bandwidth what should we send. The centralization of the information about the network and its active functionalities enables a better planning of this. However, network usage is not easily predictable even with this centralization. Nodes, as mentioned, are dumb and will be oblivious to application priorities and data usage or its statistical significance12. As such, all prioritization must be done on the BS. At the optimization phase, application priority may be used to decide when conflicts occur, informing the application of the degraded quality (lower frequency of collection or sending, lower confidence interval, etc.) as we discussed in §4.3.1.
When requests are already being served but there is a change in circumstances (energy going low, communication problems which lead to network congestion, etc.) the BSneeds to re-evaluate the optimization based on the new context. To detect measurement losses (due to communication problems) some mechanism should be instantiated to monitor the frequency of measurements arrival. Energy thresholds can be detected with ModuleAlarm.
Actuators have not been addressed in this chapter. Clearly we have been focused on acquiring information as opposed to acting. Applications however, would want to act on theBANaccording to the information received. Although actuators would not see a direct fit onto a model as we described, we could take the closed-loop approach mentioned in §4.2.1. In this approach, the model could be expanded to have rules to actuate on theBAN, based on the information collected, where the “output” of the modules would be commands to the actuators.
12In TinyDB [69], nodes prioritize data to sent based on the statistical quality improvement of sending that particular data when compared to sending other data.
6 Implementation
H
aving described the architecture, we now discuss an implementation of it. We will start by describing how the two middleware layers interact, proceed with a description of the platform used for development and discuss the Application Program Interface (API) giving some code examples to better illustrate its usage. At the end of the chapter we will make final observations on the implementation.6.1 – Layer interaction
In §5.1.1we saw that aDataValueis the structure that holds the information produced in the information layer. This value will be associated with aDataProfilefrom the hardware layer to describe it. The DataProfilefrom §3.5.1defined the data produced. ADataType is the structure for handling data on the hardware abstraction layer. It allows encoding data into messages. The DataValue holds a DataTypefor cases where this encoding might be needed or when theDataValuedirectly results from a sensor reading, which is the case for a ModuleSensor. Figure6.1.a shows these relationships and theDataValueattributes. Note that the accuracy will be defined by each module that processes the information, regarding the error it introduces. The time relates to the time of production. The size defines the size in bytes of the data held.
Every producer module will have associated a DataProfile. As described above, when producing information the newDataValueis associated with aDataProfile, thus the module needs to know the data profile it produces.
A module needs inputs to produce its outputs, they may be mandatory or optional. The optional inputs allow the module to produce outputs with different characteristics, e.g. lower
103
104 6.1. Layer interaction
6.1.a:DataValue relationship with hardware layer
6.1.b:Module relationship with hardware layer
Figure 6.1– Information layer components and hardware layer components
error. These “needs” are expressed in the dual relation toInformationTypein figure 6.1.b.
Note that some modules may not need any input, e.g. ModuleSensor gets its data “directly” from the sensors.