johanl/projects/vitruvius/vitruvius_… · web viewthe former two cooperate in sensing (1,2),...

VITRUVIUS -1 (33) - 2023-05-18

BSN Requirements and Usage Scenarios Specifications D1.1 v0.99

Versatile Interface for TRUstworthy VItal User (oriented) Services

BSN REQUIREMENTS AND USAGE SCENARIOS SPECIFICATIONS

IOP: VITRUVIUS

VITRUVIUS -2 (33) - 2023-05-18


IOP: VITRUVIUS

VITRUVIUS -3 (33) - 2023-05-18


Change History

Version Date Description Affected Sections

0.01 2009-05-18 Created the TOC

0.02 2009-5-29 Input from S. Hajiamini

0.03 2009-5-29 Input from S. Chen

0.04 2009-6-8 Input from S. Chen

0.04 26-12-2009 Rewrite by Johan Lukkien

0.05 26-12-2009 Revision by Jean-Paul Linnartz

0.99 17-01-2009 Input by Hartmut Benz

Final editing by Johan Lukkien

List of Contributors

Participating party Contributing Individuals

TU/e

WMC

J.J. Lukkien, S. Hajiamini, S.Chen, J.P. Linnartz

Hartmut Benz

IOP: VITRUVIUS

VITRUVIUS -4 (33) - 2023-05-18


IOP: VITRUVIUS

VITRUVIUS -5 (33) - 2023-05-18


Table of Contents1 Introduction 6

2 Overall System Architecture 6

2.1 Preliminary assumptions and boundary conditions 6

2.2 Stakeholders and use cases 8

2.2.1 Use case 1.1: uploading an application-specific component 9

2.2.2 Use case 1.2: data collection and reporting 10

2.2.3 Use case 2.1: Transparent control 10

2.2.4 Use case 2.2: installing a component by the user 10

2.2.5 Uses cases 4.1 and 4.2: installing physical components 10

2.2.6 Uses cases 4.3 and 4.4: Programming Sensors 11

2.3 Logical view 11

3 Main security requirements 14

4 Choice of system components 17

4.1 Sensor programming 17

4.2 Sensors and body hub 17

4.3 Federations 17

4.4 Expert system17

4.5 Methodology 18

5 Related work 18

6 Bibliography 18

1 Appendix: Trust4all 20

2 Appendix: OSAS 21

3 Appendix: Federations of Personal Networks 24

3.1 Interface to the Federation Agent 24

3.2 Installation of the Body Hub software 27

IOP: VITRUVIUS

VITRUVIUS -6 (33) - 2023-05-18


IOP: VITRUVIUS

VITRUVIUS -7 (33) - 2023-05-18


1 INTRODUCTIONBody Sensor Networks (BSNs) can be used for an increasing number of applications ranging from monitoring for medical purposes, sport coaching to computer gaming. Although these BSNs are in many cases still a special-purpose platform, the use of sensing to interact with ambient electronics and to perform long-term monitoring will increase. In order for such monitoring to become more common there is a need for management of the BSN platform as well as of the data that is collected. A foreseen typical use that parties external to the human subject put monitoring applications on the BSN and retrieve and analyze the collected data. Besides the plain concerns of secure communication we need to have policies and mechanisms to express and control the data uses such that the humn subject can transparently own, and manage his BSN and understand by whom and for what purposes the data is collected and used. In addition, it is vital that the platform remains functioning under any changes. The VITRUVIUS research project proposes a particular platform architecture of the BSN and develops a software architecture on top of that to support these advanced applications while addressing these concerns.

This document is Deliverable 1.1 of the project. Its purpose is to examine typical use cases for the BSN described from the perspective of different stakeholders. Together with security concerns this yields the requirements for the architecture. The architecture is described in a second document, D.1.1a which takes the form of a deck of slides.

We use this document as a working document, publishing revisions when new insights have taken into account. Rather than working with change documents we simply override previous versions by publishing a new release. Releases have whole numbers.

The document is structured as follows. Section 2 describes the global system architecture and main use cases. Section 3 lists and analyses requirement, in particular the ones pertaining to security. Section 4 gives initial system decisions. Section 5 gives some related work.

2 OVERALL SYSTEM ARCHITECTUREFor the description of our system we use the guidelines of IEEE standard 1471 [6]. According to this standard a system is described from the viewpoint of several stakeholders, each having certain models of the system that address concerns these stakeholders have. A collection of models addressing a concern is called a view. The same name is used for the collective concerns of a single stakeholder. Kruchten [7] defines a collection of standard views, viz. for users, programmers, system integrators and system engineers. In this document we focus on different types of end-users and on system integrators. We use the term ‘human subject’ commonly to mean the wearer (owner) of the BSN.

2.1 PRELIMINARY ASSUMPTIONS AND BOUNDARY CONDITIONS

We have some given boundary conditions, i.e., a number of à priori choices that represent initial ideas about the system and limit the design freedom we assume to have.

First, we assume that the BSN consists of two parts: a collection of sensors, battery powered and with limited resources and a more powerful device called the body hub or body gateway. These are

IOP: VITRUVIUS

VITRUVIUS -8 (33) - 2023-05-18


connected in a single (wireless) network. The body hub controls the BSN and is the primary access point. Separating different BSNs will need to be addressed in the design.

Second, at a more global level, a BSN may connect to a so-called backend system. This implies some form of connection setup between the BSN and the domain in which the backed system resides (i.e., via a network or physical connection). Through such a connection the backend system communicates with the BSN with the purpose of retrieving data and installing software.

The backend systems hosts an expert system (or Decision Support System) which is capable of understanding and diagnosing sensor readings. For the purpose of off-line operation, the expert system can upload some intelligence into the body hub in the form of software components (either in the form of native code, interpreted code or the configuration of an embedded application). This uploaded software, in combination with resident run-time information in the body hub is then capable of gathering the required data, analysing relevant events and taking appropriate actions, all done locally on the hub.

FIGURE 1: Vitruvius global system architecture. The BSN consist of body hub and sensors, communicating via a short-range wireless standard like 802.15.4. The BSN is an autonomous system that receives configuration instructions and code from an expert system on a backend system. The body hub can connect to the backend domain through the Internet via e.g. a local area network like 802.11. On top of that a secure connection exists between the expert system and an access control service in the body hub, which we call the body firewall. Through this secure connection the expert system can reach the component runtime service. The sensors will also require protection over the wireless communication (not show).

Given these assumptions, we adopt the global architecture of Figure 1 with the following responsibilities for the different parts.

Expert system on the backend system: the expert system generates guidelines (rules) in the form of software components. The result of executing these components is that the BSN is programmed towards a certain monitoring and analysis task as determined by the expert using the expert system. The expert system can upload these components to the body hub. Medical experts can use the expert system as a Decision Support System (DSS) to do long-term monitoring and analysis on the user’s physiological conditions.

IOP: VITRUVIUS

VITRUVIUS -9 (33) - 2023-05-18


Body hub (gateway): the body hub manages the sensors making the BSN a single logical network, guarding sensor access and protecting sensor data. The body hub receives data from the sensors and stores and processes it according to the instructions from the dynamically loaded components. The body hub must be capable of autonomously responding to abnormal conditons found in the data, like contacting the user or the expert system in case of an emergency. Most importantly, the body hub maintains the trustworthiness of the system with regard to dependability as well as the user’s privacy. As such it must give a transparent and coherent view on these towards the user. The exact nature of this is one of the research targets of the project. In this respect, the proposed architecture offers a protective shield that controls the secrecy of the obtained information from the human body.

Sensor nodes: the program of the sensor nodes determines the data which is sent to the a body hub. The sensors are programmed in principle by the body hub. For the purpose of the project we assume the sensors to be pre-programmed with only minor configuration possibilities. We focus on the security and privacy aspects of the connection rather than on the programming.

2.2 STAKEHOLDERS AND USE CASES

We will examine the concerns and views of stakeholders through use cases. These will first be rather high-level. When we detail the architecture we will detail these use cases into structured use cases or scenarios. We consider the following stakeholders, and use cases.

1. Users of the expert system, which may have different roles. We consider for example the roles of a medical doctor, a nurse, a personal trainer or other social care givers, or even a gaming application. In our vision, they work with the graphical user interface of the expert system. They determine parameters (e.g. blood pressure, heart rate) based on which the body data is extracted and eventually sent back to the backend system. The guidelines describing the sensor configuration are translated to algorithms in the form of software components and then uploaded to the body hub. The execution of these components by the body hub results in the configuration of the body sensor nodes. The human subject can choose to accept the components and to set the privacy of the released body data. The use cases are:

1. Installing an application, typically for prolonged off-line monitoring or alarming. This includes uploading application-specific components to the body hub and starting applications.

2. Collecting and examining data.

2. The human subject using the BSN.

1. The human subject is capable of examining and managing all activities the body hub is involved in. We call this transparent control.

2. Also the human subject can take the initiative to install applications. This amounts to downloading components to the body hub.

3. The owner of the BSN.

IOP: VITRUVIUS

VITRUVIUS - 10 (33) - 2023-05-18


1. The owner / paying organisation typically wants to prevent tampering, misuse, restrict the scope of usage,.. This role is not elaborated in Vitruvius.

4. A system integrator putting sensors and BSN together.

1. Assigning a body hub to a person.

2. Adding sensors to the BSN.

3. Programming sensors

4. Initial programming of the body hub

This gives us eight use cases which we discuss below.

2.2.1 USE CASE 1.1: UPLOADING AN APPLICATION-SPECIFIC COMPONENTIn the first use case (Figure 2) an application-specific component is constructed and uploaded to the network. In the text we refer to this figure by mentioning the numbers that appear in it. We follow the example of a doctor configuring the system for a particular application. Two typical uses are foreseen:

a) for pro-longed monitoring, the characteristics of the data to be collected are specified by the doctor (e.g. frequency and type (like blood pressure or heart rate) of data) (1);

b) for alarming the doctor needs to define some diagnostic parameters (1). These parameters typically specify thresholds against which collected data are compared so that a warning message can be sent in case of problems.

IOP: VITRUVIUS

VITRUVIUS - 11 (33) - 2023-05-18


FIGURE 2: Use case for generating and uploading a component. Description in the text.

The doctor defines these via the expert system which is used as a means of communication interface between the doctor and the BSN. The parameters are translated by the expert system into rules and algorithms, and subsequently generated in the form of components, along with corresponding descriptions (2). The expert system is further responsible for uploading the components into the body hub (3). The body hub then checks the components, by verifying the source (4.1), verifying the access

IOP: VITRUVIUS

Doctor

Expert system

setting medicalparameter (s)

Body hub

Sensor (s)

1

2

3

4.1

4.2

4.3

setting heart rateparameter

setting heart ratethreshold parameter

setting bloodpressure parameter

setting bloodpressure threshold parameter

«extends»

«extends»

«extends»

«extends»

authorization

authentication

trustworthiness

uploading bloodpressure component

uploading heartbeat component

«extends» «extends»

«uses»

«uses»

«uses»4

4.2.1

4.3.1

generating

component

uploading

componentinstalling

component

checking component

running component

VITRUVIUS - 12 (33) - 2023-05-18


rights of the author and his role (4.2) and examining the trustworthiness of the system that would result from installing the component into the BSN. Installation includes configuring the sensors (4.2.1). Finally, the body hub starts the application which then starts the sensors (4.3).

2.2.2 USE CASE 1.2: DATA COLLECTION AND REPORTINGIn Figure 3 we draw this use case with four actors: sensors, body hub, wearer and backend system. The latter three can all take the initiative to establish a connection between body hub and backend system (5). The former two cooperate in sensing (1,2), storing (3) and processing (4) sensor data. After the connection has been established, data can be retrieved or streamed for a longer time, depending on authentication and authorization. Must adapt the picture.

sensing data

tranferring data

storing data

processing data

contacting backendsystem

Body hub

wearer

expert system

«extends»

«extends»

1

2

3

4

5

Sensor node

FIGURE 3: sensing, storing and processing data. At any time during this process a connection with the backend system can be established.

2.2.3 USE CASE 2.1: TRANSPARENT CONTROLUse cases 1.1 and 1.2 also involves the human subject as a stakeholder. He will be involved in both steps 3 and 4 of 1.1, authorizing the steps that are taken. During this process and while the system is running the user has a transparent view on what is happening. Similar remarks hold for use case 1.2. Use case 2.1 therefore captures three activities: monitoring and control of the system behavior, control capturing giving consent to certain actions and actively changing the control state of the system. Correspondent actions will be interwoven with the functionality.

2.2.4 USE CASE 2.2: INSTALLING A COMPONENT BY THE USERIn Figure 4 we show the use case of the user taking the initiative to install an application component. Step 1 means that the backend system is now acting as a client of the body hub. Not shown is that a connection must be established up front. Steps 3, 4 and 5 are similar as in Figure 2. An important observation from this use case is that security and trust are dealt with differently than in Figure 2: it is the user that must select the loaded components rather than the external expert.

2.2.5 USES CASES 4.1 AND 4.2: INSTALLING PHYSICAL COMPONENTS

IOP: VITRUVIUS

VITRUVIUS - 13 (33) - 2023-05-18


Assigning a body hub to a user means making an association between user and hub. This can first be done by a simple form of registration, either through the hub itself or while it is connected via a bootstrap connection to the backend system. Installing sensors in the BSN will require some form of feedback, for example, using a one-time key as in bluetooth associations. During this process, any initial security material may be installed as well. For the time being we consider these use cases less important.

FIGURE 4: Installing an application-specific component by the user. Parts are similar as in Figure 2; the control and the choice of components are now at the user.

2.2.6 USES CASES 4.3 AND 4.4: PROGRAMMING SENSORSProgrammability of the sensors can range from fully static deployment to simple configuration to full reprogrammability. The requirements from the our problem description is that at least configuration is possible (e.g. logging frequency, on/off). In order to study tradeoffs between on-node (pre-)processing and off-line processing as well as new algorithms and behavior, reprogramming ‘over-the-air’ would be preferable. In both cases the nodes are equipped with a sufficienctly powerful run-time system upon deployment. The architecture must further support the reprogramming and reconfiguration through the body hub. This may either be part of the loaded components or through a special connection with the backend system.

2.3 LOGICAL VIEW The logical view comprises a high-level, usage oriented view of the system. The viewpoint is that of the functionality the system provides to its users. The view describes the main visible components the user interacts with, their interfaces, and their interactions according to the given use cases.

Figure 5 gives a possible view on UI of the body hub, showing status information of sensors and installed services. Figure 6 gives a structural representation of the entire system in the form of a class

IOP: VITRUVIUS

wearer

Body hub

selectingcomponent source

downloadingcomponent

checking component

installingcomponent

running component

trustworthiness

authorization

authentication

heart beatcomponent

blood pressurecomponent

«extends»

«extends»

«uses»

«uses»

«uses»

1

2

3

4

5

VITRUVIUS - 14 (33) - 2023-05-18


diagram, where the functions in the diagram correspond to functionality in the use cases. Figure 7 gives an interaction diagram corresponding to use case 1.2. Need to adapt both. Other use cases are straightforward to translate into such diagrams; we leave them out for now.

FIGURE 5: An example about how a Body Hub User Interface might look. On the left a possible view at runtime. On the right a possible view when a backend system contacts the BSN. Details explained later.

IOP: VITRUVIUS

VITRUVIUS - 15 (33) - 2023-05-18


IOP: VITRUVIUS

int, in BPthresh : int, in HRthresh : int)+receiveDataGateway (out data : byte, in sensorID : int, in gatewayID : int)+accessPatientData (in patientID : int, in sensorID : int)+authenticationRequest ()+checkSessionValidationRequest ()

-doctorName : string-expertSystemName : string

Expert system GUI

Users GUI

1

1..*

1

1..*

Upl oads c onfi gur ati on c o m

ponent

FIGURE 6: A logical view on the system interfaces as experienced by a user. The description focuses on the elements visible to the user.

+contactList(in userID : int, in address : string, in phoneNumber : string)+accessData(in sensorID : int, in patientID : int)

-userName : string-userID : int

BSN user GUI

+downloadComp(in compID : int, in gatewayID : int, in SW component)+receiveDataSensor (inout data : byte, in sensorID : int)+sendDataEGUI (in data : byte, in expertSystemName : string, in sensorID : int)+displayData(in data : byte, in sensorID : int)+checkComp(in compID : int, in SW component)+checkSessionValidationReply() : bool+authenticationReply() : bool

-hubID : intBody hub

+installComponent (in sensorID : int)+runComponent(in sensorID : int)+sendDataGateway (in gatewayID : int)

-sensorID : intSensor node

1..*

1..*

Upl

oads

c om p

1

1

+generateComp() : <unspecified>+setParam(in BP : int, in HR : int, in sensorID : int, in patientID :

VITRUVIUS - 16 (33) - 2023-05-18


:Doctor :Expert system :Body hub(gateway) :Sensor node

reConfigParam(BP,HR,sensorID, patientID, threshold)

setParam(BP,HR,sensorID, patientID, threshold)

downLoadComp(compName,compID,gatewayID)

receiveData(sensorID)

[session is valid=1] return data

return data

authenticationRequest

checkSessionValidation

upload completed

generateComp

runComp

DataReadyToSend

select comp

comp properties

display local data

authentication failed

display

Sensor wearer

CheckComp

install comp

check failed

readData

alt 1edtionAcceptauthentica

else

alt

1compValid

else

FIGURE 7: Sequence diagram corresponding to use case 2.1

IOP: VITRUVIUS

VITRUVIUS - 17 (33) - 2023-05-18


3 MAIN SECURITY REQUIREMENTSThe core functional requirements to be derived from the above description are relatively straightforward.

On one person’s BSN, multiple services are run, possibly for different stakeholders. The execution of these services share the data coming from the same sensor nodes.

The body sensor hub must sustain case of dynamic behavior of the BSN such as varying the number of the sensor nodes, changing the communication behavior between the body hub and the sensor nodes, or installing new components.

The body hub must be able to assert the effects of a composition before it is realised.

There are different modes of operation, viz., a setup or docked mode in which a body hub is attached to the backend and a run mode in which it is detached.

In addition, there must be a initialization phase that represents physical deployment and BSN physical modification.

The system must be able to deal with different flows: streaming data flow and separate control flow.

The system must be capable to deal with different roles of stakeholders in terms of authorization.

Data format. The information obtained from the sensor nodes must be formatted in such a way that it can be easily analyzed for further processing. In this regard, the sensed information can be formatted and conveyed to the body hub using Health Level 7 (HL7) standards. This must be further determined in the design phases.

Although for a full design getting such a complete list of functional requirements is important, we want to concentrate on the concerns of privacy and dependability for all stakeholders as they are a prime motivation and goal for the project. These are, in fact, extra-funtional properties. We give three definitions for the terms we use.

Definition: Privacy is the level of control of information that an owner of this information has.

Definition [8]: Dependability is the ability to avoid service failures that are more frequent and more severe than is acceptable by a given bound. Dependability is further detailed in Availability, Reliability, Safety, Integrity and Maintainability.

Definition [8]: Trust represents the degree to which a trustor has a justifiable belief that a trustee will provide an expected service.

Privacy and dependability are endangered by threats. These can be categorized as follows.

a) Information interception, ormore generally, unauthorized access to the data

b) Interruption of the system

c) Destroying system integrity

IOP: VITRUVIUS

VITRUVIUS - 18 (33) - 2023-05-18


These threats are not entirely independent; for example, if system integrity is jeopardized, unauthorized data access is possible.

Threat threats are materialized by attacks, a particular behavior or interaction with the system. These attacks succeed because of vulnerabilities that make them possible. For example, the interception threat can be materialized by simply listening in to the radio communication which succeeds if the information is not protected (= vulnerability). A systematic way of analyzing attacks is by using attack trees [9], which are and-or trees with vulnerabilities in the leaves. For our purpose this is slightly overdone and we simply list the considered attacks in a textual manner.

Attacks can be caused by mishandling, by malfunctioning and by malicious behavior.

1) a user may lose a sensor, physically or because it stops working (malfunction)2) a sensor may transmit wrong data (malfunction)3) wireless communication may be disrupted by interference (malfunction) or by a malicious

person (malicious)4) the body hub may be tricked into running a wrong composition of components (mishandling)5) a sensor may be attached to the wrong patient (mishandling)6) an intruder might overhear or steal data (malicious), i.e., raw data from sensors, processed

data from body hub or backend system7) an intruder might install malicious software on the sensors, the hub or on the backend

system (malicious)8) through physical interference the BSNs of two different persons may become mixed up

(malfunction)9) a sensor may be associated with the wrong network, i.e. another patient carries the sensor

(malfunction, mishandling)

Countering these attacks typically addresses the vulnerabilities that make them turn into real threats. By analyzing this we obtain requirements on our system as well as some further research questions.

1) Countering attack 1) is not really possible; however, the system must be such that it detects it. A soft-state protocol for this would probably work [10]. Reverse engineering a node that is found or stolen may not lead to a fully compromised system, or full access to the data of a particular patient. Secure hardware , e.g. physical unclonable functions, to protect data of the sensor node mitigate the risks.

2) To counter 2), the system must analyze sensor data and perhaps sensor state continuously such as to detect anomalies in the behavior. Possible methods are pattern matching against historic data and outlier detection [11]. Some literature exists that matches measured physiological data, such as ECGs, as a form of biometrics, e.g. [12].

3) This is, in fact, similar to 1). The soft state protocol can be augmented to deal with this communication loss as well. It might be made intelligent to discern the four cases: sensor loss, communication loss, sensor malfunction, malicious intrusion.

4) This attack is much more involved and we need, in fact, to design more precisely how our system loads and runs components. We follow in this the approach of the Trust4all framework which is described in more detail in Appendix 1. In this approach a component is a set of models, where a model can be any abstraction of functionality. Example models are: the executable code, documentation or a performance model. The relationship between different models is certified by an authority, e.g. as in [13]. An example is the following:

IOP: VITRUVIUS

VITRUVIUS - 19 (33) - 2023-05-18


a. models: executable code and a resource description

b. certificate: ‘authority Z says that this executable and this resource description belong together on platform X; the resource description is guaranteed by company Y’

This leaves us with the problem to decide on the certification authority and what the exact certification structure should be. We leave this for now as a research topic. Similarly, how to determine (evaluate) the relevant properties of a component is a research issue.

The information retrieved from certificate and new component composition is the basis for an access control algorithm. The Trust4All framework bases this on a trust computation that we need to specify while going forward with the design.

Besides this access control, we want to monitor the behavior of a loaded component in order to see if it adheres to the specification or if it otherwise does not do anything wrong. Also here we propose to follow the Trust4All approach as sketched in Appendix 1 which proposes a “middle man” approach.

5) This case is similar to case 2) perhaps extended with consistency across sensors in the same BSN. Biometric verification of measured sensor data can mitigate the risks. This topic requires further study, because the reliability of biometrics are not yet adequate. False negatives occur too frequently to block functioning with a mismatch is detected.

6) In order to counter this, proper encryption is required to ensure secure channels. This pertains to several places:

a. Connection body hub – sensors. A research question is which encryption is useful for low-resource devices and how and when to establish keys.

b. Connection body hub – sensors. We adopt here the approach that the BSN as a whole joins the domain of the backend system before any further communication can take place. Both the BSN and the backend domain are regarded as federations, and their joining: a federated network or fednet [14]. This connection between two federations, which extends the concepts of a Virtual Private Network, then determines the admitted services at both sides.

c. Backend system. Here, information might be lost due to regular attacks and proper methods need to be installed to counter this.

d. Sensor Hub. The electronic system of the sensor hub may be attacked. In our Vitruviius model, this hub is owned by the patient.

e. Sensor nodes. Presumably the largest risk is that a malicious or negligent manufacturer creates sensors which can easily be compromised.

7) The upload procedure includes proper authentication and authorization. This can be done partly through the fednet. A major concern is the activities of the user himself as indicated by use case 2.2. The trustworthiness computation indicated in case 4) must take this into account. It would imply that the body hub needs internal modeling of admitted/malicious

IOP: VITRUVIUS

VITRUVIUS - 20 (33) - 2023-05-18


behavior in some form. This is again a research question. A further point of attention is the initialization and modification of this information. In fact the attacker may make use of a compromized decision support system to create certificates for his malicious code.

8) At the physical or MAC level there must be an association established between sensor and BSN identity, e.g. upon installation. Further solutions are in 9) below.

9) This situation is slightly different from 5). In fact in 5), a sensor measurements need to be verified against (historic) patient data, while in 8) sensor data can to be verified against other (real-time) data from other sensors in the same network. From a security perspective, protection against 5) is offered by biometric verification, while protection against 9) can be given by key generation based on common randomness created by body physiological systems. For instance at two locations on the body one sees the same heart beating.

As a last aspect to the issue of privacy, in order to provide control over personal data the operations that a data consumer can do with the data should be specified and certified as well. For example, when a back-end system consumes data from the body hub it must be known to the user what is done with the data, and that some authority certifies that this is indeed the case. Furthermore, the user must be able to see the identity of any user of the data, even when this data is stored offline. We can thus work on a privacy index or privacy level and certification thereof. This is an interesting and perhaps new research area.

4 CHOICE OF SYSTEM COMPONENTSBesides the restrictions and assumptions mentioned in the beginning of section 2, we have some early decisions that simplify the design and take knowledge and tools represented by the partners into account. In D.1.1a these components will be detailed in the architecture.

4.1 SENSOR PROGRAMMING

Since the sensors are not the prime focus of the project, we use the OSAS programming system [15] of TU/e SAN developed in the WASP project as described in Appendix 2. In this system the body hub acts as a (simulated) sensor node fully integrated with the real nodes. In the course of the past year a heart beat detection algorithm as wel as step/fall detection algortihm has been developed with this system which makes it readily available for practical test.

4.2 SENSORS AND BODY HUB

For the sensors we use the Sensixa nodes [16] for the time being as they are fully functional with the OSAS programming system. Each sensor has 60kB ROM, 10kB RAM and an IEEE 802.15.4 wireless link with a range of 50m. Later we may move towards Acquis Grain nodes or other ones when, for example, clinical tests require a certain form factor. The body hub will initially be represented by a netbook.

4.3 FEDERATIONS

For the Fednet implementation we use software developed by WMC, summarized in Appendix 3.

4.4 EXPERT SYSTEM

IOP: VITRUVIUS

VITRUVIUS - 21 (33) - 2023-05-18


Medecs [ref] has developed a tool called Gaston that is really an expert system in the medical domain. It contains a Decision Support System in the form of a rule engine that can relate data sets to diagnostics. It is described in Appendix 4.

4.5 METHODOLOGY

We use the methods and approaches for trustworthy systems as developed in the Trust4all project. This is described in Appendix 1.

5 RELATED WORKRecent years have seena rapid rise of a new sensing and monitoring devices for healthcare monitoring and patient care. UbiMon[1] aims to provide a distributed mobile monitoring system for patient in order to capture life threatening events. This project also investigates the use of implantable sensors for post surgical car.e The concept of a tree structured three layer network has been proposed by [2]. The structure of the network consists of a leaf node layer as a patient sensors, an intermediate node layer as local processor, and a root node layer as a central monitoring processor. The main novelties of the proposed network architecture are overcoming the bandwidth bottleneck between the leaf node and root node levels and overcoming the processing bottleneck at the root node level. The authors in [3] have proposed a real time monitoring method that can shorten the recovery time of patients after the surgical operations. In order to do so, they have used a kind of sensors that can capture a range of activities in addition to physiological measurements. Capturing the range of activities implies the amount of mobility of a patient which can be used as an indicator of the recovery rate of the patient post operation. This health postoperative care method investigates processing on node algorithms by which the amount of radio transmission and subsequently the overall power consumption can be reduced significantly.

A method for the placement of sensors in the body area network has been introduced in [4] in a temperature sensitive environment. The distance among the any two sensors must not drop below a critical seperation. In other words, if multiple sensors operate in close proximity of one another, the surrounding temperature increases due to operation of an isolated sensor can exceed the threshold. In terms of network architecture, [5] explores the implication of architecture on power and delay efficiency. According to the obtained results, experimented on the star and multihop network topologies, it is concluded that the star offers the better delay efficeincy whilst the multihop outperforms in terms of power consumption when the sensor nodes are far away from the sink. Using this idea, a star topology would be a good architectural decision in small environments, e.g., a hospital room, where a sufficient number of sensors are scattered in the area.

6 BIBLIOGRAPHY1. Yang., G.Z. Ubimon-ubiquitous-immplantable-sensors. London : Imperial College London, 2007.

2. The mobile patient: wireless distributed sensor networks for patient monitoring and care. Bauer, P. and Sichitiu, M. and Istepanian, R. and Premaratne, K. sl : IEEE EMBS International Conference on Information Technology Applications in Biomedicine, 2000.

IOP: VITRUVIUS

VITRUVIUS - 22 (33) - 2023-05-18


3. Real-Time Pervasive Monitoring for Postoperative Care . Steffen Leonhardt, Thomas Falck and Petri Mähönen. Aachen : 4th International Workshop on Wearable and Implantable Body Sensor Networks, 2007.

4. Towards a covered and connected body sensor network for healthcare applications. Das, Nibedita and Murthy, Sudheendra and Sen, Arunabha. Breckenridge, Colorado : ACM, 2008.

5. Investigating network architectures for body sensor networks. Natarajan, Anirudh and Motani, Mehul and de Silva, Buddhika and Yap, Kok-Kiong and Chua, K. C. San Juan, Puerto Rico : ACM, 2007.

6. IEEE Recommended Practice for Architectural Description of Software Intensive Systems, Std 1471-2000.

7. Architectural Blueprints -- The 4+1 View Model of Software Architecture, Philippe Kruchten, IEEE Software, 12(6):42-50 (November 1995).

8. , (internal) deliverable 1.2 of the Trust4All project, Andrew Tokmakoff, Johan Muskens, http://www.hitech-projects.com/euprojects/trust4all/, June 2006.

9. Attack trees, B Schneier, Dr. Dobb's journal, 1999 (note: this is the original article with a few hundreds of references).

10. On the consistency of soft - state based service registration , M. Tjiong, J.J. Lukkien, 2008 IEEE GLOBECOM.

11. Outlier detection for high dimensional data , CC Aggarwal, PS Yu - ACM Sigmod Record, 2001.

12. Biometric statistical study of one-lead ECG features and body mass index, T Shen, W Tompkins, in Medicine and Biology Society. 27th, 2005.

13. A compositional claim-based component certification procedure , Mei, J Lukkien, J Muskens Proceeding Euromicro Conference, 2004.

14. Fednets : Context-aware ad-hoc network federations , IG Niemegeers, SMH De Groot, Wireless Personal Communications, Springer 2005.

15. An integral approach to programming sensor networks , R Bosman, J Lukkien, R Verhoeven, 6th IEEE CCNC, 2009.

16. http://www.sensixa.com/

17. A component framework for consumer electronics middleware, J Muskens, MRV Chaudron, JJ Lukkien - Lecture Notes in Computer Science 3778, 2005.

18. http://www.win.tue.nl/~rbosman/

19. On-node processing of ECG signal, R Verhoeven, D Albu, J Lukkien, Proceedings 7th IEEE CCNC, 2010, to appear.

20. Energy effects of on-node processing of ECG signals, R Verhoeven, D Albu, J Lukkien, B Bilos, in: Digest of papers of the IEEE ICCE 2010.

IOP: VITRUVIUS

http://www.win.tue.nl/~rbosman/

http://www.springerlink.com/index/f172600116688114.pdf

http://www.sensixa.com/

http://wasp.cefriel.it/download/public/publications/WSN-PM-final.PDF

http://www.springerlink.com/index/N615V7167812XL63.pdf

http://doi.ieeecomputersociety.org/10.110910.1109/EURMIC.2004.1333430

http://portal.acm.org/citation.cfm?id=376284.375668

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4746637

http://www.hitech-projects.com/euprojects/trust4all/

http://www.win.tue.nl/~wstomv/edu/2ip30/references/Kruchten4+1.pdf

http://www.win.tue.nl/~wstomv/edu/sep/ieee/software-architecture-std1471-2000.pdf

VITRUVIUS - 23 (33) - 2023-05-18


21. Service and Resource Discovery in Smart Spaces Composed of Low Capacity Devices, Önder Uzun, Tanır Özçelebi, Johan Lukkien, Remi Bosman, in: Digest of papers of the IEEE ICCE 2010.

IOP: VITRUVIUS

VITRUVIUS - 24 (33) - 2023-05-18


1 APPENDIX: TRUST4ALLTrust4All is an ITEA project concerned with the trustworthiness of consumer terminals upon changes in embedded software, through user or system initiated downloads. The results of this project include those of two predecessors (Robocop and Space4U) and are way too large to summarize here easily. The contributions of Robocop and Space4U are readily summarized in [17]. The main two aspects that are useful for VITRUVIUS are the component model and the trusth model.

1.1 COMPONENT MODEL

FIGURE 8: Robcop component model (from ref). A component is represented as a set of models and relations.

A Robocop component is a set of models and relations. These models describe different aspects of the same underlying entity. Example models are: source code, documentation, resource use, behavior, executable etc. Example rules specify relations between models like the fact that a certain model belongs to another model (executable belong to source). This allows one to take a step back from specific component implementations. For VITRUVIUS the useful aspect of this is that for the loadable components we should also have certified descriptive models.

1.2 TRUST MODEL

Trust4All defines the roles of trustor and trustee (see also our definition) which can be any actor in the system, including components, a run-time system etc. Figure 9 below gives an overview of the model. In case of Vitruvius the Trustee will be a loaded component which will come with a description of the qualities of the component, e.g., which data will be examined and what information is passed through, perhaps on behalf of whom it can be executed. In addition, resource use and other properties can be specified here.

1.3 TRUST FRAMEWORK

IOP: VITRUVIUS

VITRUVIUS - 25 (33) - 2023-05-18


The trust framework introduces mechanisms to perform access control and to impose behavior according to certain policies. This consist of a quality monitoring and decision making based on those

FIGURE 9: Trust model of Trust4All. In case of a loaded component, the quality properties of the Trustee are specified as a model. For VITRUVIUS specific quality properties can be specified.

illustrated in Figure 10 below. In the end the (binary) decision whether to trust a component dependens on the evaluation of a trustworthiness function, and whether it exceeds a given threshold. In order to monitor a component whether it conforms to the specified behavior or just for security reasons a middle man approach is suggested in which all interfaces of a component are led through a component that verifies each interface interaction against a policy.

IOP: VITRUVIUS

VITRUVIUS - 26 (33) - 2023-05-18


FIGURE 10: The mechanism requires a run-time system to monitor the current situation. In addition, primitives are required to express quality attribute decisions

IOP: VITRUVIUS

VITRUVIUS - 27 (33) - 2023-05-18


2 APPENDIX: OSASOSAS, (Open Service Architecture for Sensors) is described in [15] and has a website [18]. It has been developed as part of the IST WASP project. Here we summarize its functionality. OSAS is a system for programming systems of sensors with an emphasis on low-resource use. An OSAS network consists of nodes equipped with a specific run-time system. An OSAS application is a single program for the entire network that defines services as well as connections between these services. Services expose time-triggered eventing to the network and actions that can be called from the network; connections (subscriptions) connect an event generator with an action (called a handler in that case), most often on different nodes. Both services and subscriptions can be installed and removed on-the-fly by any node that is sufficiently authenticated. The single program for the entire network can be extended on-the-fly as well.

Local node functionality is made available to the run-time system by a set of system calls. The run-time system can be run also on a powerful node, e.g. a laptop. A connection with the IP infrastructure is formed by a gateway node – having access to both regular IP infrastructure and the wireless sensor protocol like 802.15.4- and running the run-time system on that node as well. In this way we overlay the sensor network into the IP infrastructure.

In more detail, a service has a state, generated events and event handlers. The flow of the program is determined by the events and a service can generate events through event generators or consume events through event handlers. The process of linking the event generator of one service to the event-handler of another is called a subscription. When a subscriber subscribes to an event, the event generator is triggered periodically. The triggering period is determined by the subscriber. There could be many subscriptions on a single service and the subscription period may differ per subscription. When an event generator is triggered, it tests its condition to fire an event. A generated event takes the form of calling the handler as an asynchronous remote procedure call. In Figure 10 we show a picture of the run-time organization of a single node. The services run as part of the run-time system and are represented in a specially designed bytecode [15]. (i.e. a neighborhood communication facility) is assumed. For the communication the availability of a link layer (i.e. a neighborhood communication facility) is assumed. This makes it possible to bind OSAS messages easily to a sensor MAC as well as to e.g. an UDP overlay.

FIGURE 11: OSAS runtime organization

IOP: VITRUVIUS

VITRUVIUS - 28 (33) - 2023-05-18


The programming platform is realized using a toolchain as shown in Figure 12. A program is written in WASP [16] Service Composition Language (WaSCoL), to define services and compose them (subscriptions). The output of this is a set of service definitions and subscriptions that are packed into messages and can be handled as independent objects.

FIGURE 12: The OSAS Toolchain: .wsp files contain the network program and are compiled into byte code (.wbc) as well as an .xml description. The latter is used as input to the compiler if someone wants to add new services. It also contains the available system calls. The run-time system can be run on a simulator as well thus giving a powerful integration with the IP-based infrastructure, allowing to integrate more powerful nodes into the sensor network. Simulators are connected using UDP connections that extend the sensor broadcast domain. The simulator is configured using a description in a .wnl file.

Program deployment is done by emitting the generated messages to the network. This is typically done by the loader but can be done by other nodes as well. For example, a node may store a message to establish a certain subscription at run-time upon a condition, by simply emitting this message; in a similar manner it may install a service.

The power of the system comes from the fact that there is a single program, hence no need for complicated interpretation and lookup inside the nodes. The symbol table (the .xml file in Figure 12) maps names of system calls, services, subscriptions, handlers, events and variables onto short IDs such that messages remain small. These IDs are static and globally defined in the network. The updated symbol table generated by the compiler can be used to extend or reconfigure an already running network. Different applications can be run concurrently by using a separate application id.

There are two high level constructs for communication in OSAS/WaSCoL. SendMessage is used to flood a message (representing an asynchronous remote procedure call) to the whole network whereas SendToSubscribers is used to route a packet to subscribers of a service. A route is set from the service provider to the subscriber either via a subscription request (automatically) or by flooding of a SetRoute message. Therefore, a subscription can only be issued by the subscriber. Each node exposes a SubscriptionHandler. When called with the proper arguments, this handler will issue a subscription. WaSCoL provides content based addressing (CBA) besides regular addresses. In a CBA

IOP: VITRUVIUS

VITRUVIUS - 29 (33) - 2023-05-18


the destination is determined by a predicate. Besides the mentioned SubscriptionHandler there is a handler to install bytecode. Together, these make up the basic functionality of the system.

The system has been used for a number of sensor systems. Within Vitruvius and WASP we have developed an on-node ECG processing algorithm that report heartbeats or heart rates rather than raw ECG sensor values [19,20]. By putting a run-time system on the hub we obtain a good starting point for the BSN organization. In [21] it is further elaborated how to have a simple management layer.

In order to deal with VITRUVIUS requirements, OSAS has to be extended with appropriate security technology and the ability to deal with several distinct networks.

IOP: VITRUVIUS

VITRUVIUS - 30 (33) - 2023-05-18


3 APPENDIX: FEDERATIONS OF PERSONAL NETWORKSThe networks of the hospital and the Patient are modeled as independent Personal Networks (PN), where in the case of the hospital it is rather an entity instead of a person.

A Personal Network securely connects all devices & services belonging to the PN’s owner, wherever these devices are and whichever network access technology they use, as long as they can make a connection.

A Fednet is the federation of two or more PNs and provides them with a secure communication path for a set of clearly defined services.

For the defined use cases, hospital and patient federate their respective PN’s allowing the hospital (doctor) to deploy an application to the body hub of the patient, and both the body hub application and the hospital back-office system to contact the respective other via a secure channel.

The steps involved in setting up the Fednet1 are as follows:

1. The doctor (representing the hospital) creates and advertises a Fednet for the individual patient

2. The patient discovers a and joins this federation

Step 1 is performed implicitly by the software as part of the creation of the patient record (the specific rules and settings in the hospital’s knowledge processor). The process involves copying a template Fednet description for the specific application area (i.e., epilepsy monitoring), filling in patient-specific data, and registering it to the hospital’s Federation Agent.

Step 2 requires the patient to actively scan for the hospital’s Federation Agent, locate her specific federation, (read, understand, and accept the Fednet’s conditions and requirements), and accepting to join the federation.

3.1 INTERFACE TO THE FEDERATION AGENT

The hospital’s Federation Agent offers an XML-RPC based service with the following interface:

//-------------------------------------------------------------------------/** * Inteface of the FA towards the ownwer's PN. * This interface allows processes in the PN to manage (create,delete) * federations, and (un)register services. * * @author hartmut benz, ti-wmc */public interface FAInternalServer {

public static final String SERVICE_NAME = "FedNetAgentInternal";

//-------------------------------------------------------------------------/** * Returns the XML document all available Federation Advertisements. * Advertisements are all short, i.e. no current users, serivceOfferings etc. * @return an XML document with a list of short fednet advertisements

1 We assume that the PNs are created and managed already – PN creation and management are outside the scope of VITRUVIUS.

IOP: VITRUVIUS

VITRUVIUS - 31 (33) - 2023-05-18


* in this FA */public String getShortAdvertisementList() throws XmlRpcException;

//-------------------------------------------------------------------------/** * Creates a new FedNet. * The Fednet Agent creates the relevant certificates and assigns a UUID * * @param advertisement the fed net adver * @param joinOwnerAsRole the role name as which to join the PN owner, or * <code>null</code> for not joining the owner * automatically * @returnan XML string representing the completed advertisement * @throws FedNetException if creation or registration of the fednet failed * @throws XmlRpcException if communication to the FA failed */public String createAdvertisement( String advertisement, String joinOwnerAsRole )

throws FedNetException, XmlRpcException;

//-------------------------------------------------------------------------/** * Releases the members of the specified Fednet and deletes the advertisement * from the FA. * * @param uuid the id of the fednet to delete * @throws FedNetException * @throws XmlRpcException */public void deleteAdvertisement( UUID uuid ) throws FedNetException, XmlRpcException;;

//-------------------------------------------------------------------------/** * Registers a PN-internal service with the FA registry * * @param name the name of the service to register * @param address the URI of the service to register */public void registerService( String name, URI address )

throws FedNetException, XmlRpcException;;

//-------------------------------------------------------------------------/** * Deletes a PN service from the FA registry * * @param name the name of the service to remove * @param address the URI of the service to remove * @throws FedNetException */public void deleteService( String name, URI address )

throws FedNetException, XmlRpcException;

The hospital, a Federation advertisement is created like this:

public FedNetAdvertisement createAdvertisement() {final String fedOwner = "Kempenhaeghe Epilepsy Monitoring";final String fedTitle = "EpilepsyMonitor 1548625";final String description = "A Federation for epilepsy monitoring for 1548625";final String audience = "Patient 1548625";final int minParticipants = 2;final int maxParticipants = 2;

// Create a Fednet requestfinal FedNetAdvertisementRequest advRequest =

new FedNetAdvertisementRequest( fedTitle, fedOwner, description,

IOP: VITRUVIUS

VITRUVIUS - 32 (33) - 2023-05-18


audience, minParticipants, maxParticipants, FedNetAdvertisementRequest.DEFAULT_ROLES );

/* * We are free to define their own role names * (replacing the defaults, OWNER & PARTICIPANT, used in the constructor above) */advRequest.setRoles( "Hospital", "Patient" );

// Configure the services offered by the federation rolesServiceIp bodyHubAccess = new ServiceIp( "GASTON@BodyHub", "Connection Monitoring Service -> Patient", ServiceIp.Protocol.TCP, 20888, // the external port ServiceIp.Direction.IN );advRequest.addServiceOffer( "Patient", bodyHubAccess );

ServiceIp backOfficeAccess = new ServiceIp( "GASTON@BackOffice", "Patient -> Connection Monitoring Service", ServiceIp.Protocol.TCP, 20888, // the external port ServiceIp.Direction.IN );advRequest.addServiceOffer( "Hospital", backOfficeAccess );

try {String response = server.createAdvertisement( JibxUtils.toXML( advRequest ), "Hospital" );FedNetAdvertisement adv = JibxUtils.fromXML( response, FedNetAdvertisement.class );logger.info( "Advertisement successfully created" );return adv;

} catch ()

… return null; // Failed

}

The resulting Fednet advertisement request sent to the FA in the createAdvertisement call looks like this as XML:

<?xml version="1.0" encoding="UTF-8"?><fedNetAdvertisementRequest xmlns="http://www.ti-wmc.nl/fedNet/ds"> <FedHeader> <Title>EpilepsyMonitor 1548625</Title> <OwnerName>Kempenhaeghe Epilepsy Monitoring</OwnerName> <Description>A Federation for epilepsy monitoring for 1548625</Description> <Audience>Patient 1548625</Audience> <NrOfParticipants minParticipants="2" maxParticipants="2"/> <Roles> <Role>Hospital</Role> <Role>Patient</Role> </Roles> </FedHeader> <serviceOffers> <serviceOffer role="Patient"> <IPConnection name="GASTON@BodyHub"> <description>Connection Monitoring Service -> Patient</description> <Protocol>TCP</Protocol> <portFrom>20888</portFrom> <portTo>20888</portTo> <direction>IN</direction> </IPConnection> </serviceOffer> <serviceOffer role="Hospital"> <IPConnection name="GASTON@BackOffice"> <description>Patient -> Connection Monitoring Service</description> <Protocol>TCP</Protocol> <portFrom>20888</portFrom> <portTo>20888</portTo> <direction>IN</direction>

IOP: VITRUVIUS

VITRUVIUS - 33 (33) - 2023-05-18

BSN Requirements and Usage Scenarios Specifications D1.1 v0.99 </IPConnection> </serviceOffer> </serviceOffers> <JoinActions/> <ActivateActions/></fedNetAdvertisementRequest>

This federation is registered with the local FA like this:

// Connect to the Federation Agent (FA) creator.connectToServer(); // Via service discovery// creator.connectToServer(URI.create( "http://localhost:8081" )); // OR: To known location

// Register a few services we need for the coming federation creator.registerPnServices();

// Create the federation description and send it to the FA final FedNetAdvertisement adv = creator.createAdvertisement();

Both Hospital and the patient’s Body Hub can explicitly register services with their respective FA’s. Below is an example for the hospital:

/* * Three examples or registering PN services * - A software-download server (i.e. for body-hub SW) running at 10.0.6.2 * - The back office (GASTON) server at the hospital * - A downloaded component in the BodyHub MiniGaston * * Services 1 and 2 would be registered by/at the hospital FA. * Service 3 would be registered by the user-FA by the downloaded SW component */ server.registerService( "Download SW", URI.create( "http://10.0.6.2:80/sw/epilepsyHub" ) ); server.registerService( "GASTON@BodyHub", URI.create( "tcp://10.0.6.2:12345" ) ); server.registerService( "HospitalBackOffice", URI.create( "tcp://10.0.6.2:12345" ) );

3.2 INSTALLATION OF THE BODY HUB SOFTWARE

The application specific software that needs to be deployed on the body hub of the patient as part of the hospital’s service is offered to the patient role as one of the services offered by the hospital (“Download SW”).

If this SW is installed automatically or requires further research, but the Federation Advertisement already supports the declaration of actions to be taken automatically when a user

Joins a federation

Activates a federation (i.e., creates the actual connection), and

Leaves the federation.

For the purpose of installing, an InstallAction( “http://www.kempenhaeghe.nl:80/sw/-

epilepsyHub”, helpText) could be defined, which is automatically triggered when the patient presses “Join”.

IOP: VITRUVIUS

johanl/projects/vitruvius/vitruvius_… · web viewthe former two cooperate in sensing (1,2),...

Documents