VITRUVIUS

Use cases and initial architecture

January 22

Johan Lukkien

TU/e, System Architecture and Networking

1

Contents

• Overall architecture

• Federations

• Body hub

• Security considerations

• Use cases

2

Conceptual architecture from proposal

App

licati

ons

Sens

or N

ode

Body

Hub

(DSP

)

Application Specific

Component

Application Specific

Component

Security Interface (Gate Keeper / Body Firewall)

Multi-Sensor Signal Processing

Storage: Historic data engine

BAN, IEEE 15.4 ZigbeeIEEE 1455, IEEE 1073,

Sleepmanagement

Patient Monitoring

Posture Coach

Social Care

Actuator

Single Signal Processing

Sensor

Local Decision Support engine

Application Specific

Component

IEEE 1073, Continua, HL7Tr

ust a

nd O

wne

rshi

pM

onito

r eng

ine

Secu

re U

ploa

d an

d Co

nfigu

ratio

n M

anag

er

Sens

or N

ode

Actuator

Single Signal Processing

Sensor…

Application-Specific Compound Decision Support

3

Example• Raw data: ECG signal

• Low level events:– heart rate

– heart beats with time stamps• can compute on nodes to save energy

• High level events:– indicators for seizure

– combine with other sensors, e.g. accelerometer

• Human parameter – health condition, epilepsy condition

– mood

4

ICCE, CCNC 2010

Overall architecture

5

BSN

Backend domain 1

Backend domain 2

Accelerometer

ECGsensor

Body hub

....

internet

Expert system-1 onBackend system 1

Expert system-2 on Backend system 2 secure connection

body

firew

all

component runtime upload & configure

802.15.4

802.11

Three levels of connections• an internet connection as the basis• to setup a secure and controlled connection• which is then used to connect expert system and runtime

Terminology• both BSN domain and backend domain are called personal networks

Contents

• Overall architecture

• Federations

• Body hub

• Security considerations

• Use cases

6

Personal Network Federation

Body Hub

BS BS BS

Imprinting Device

Imprinting Device

Doctor’s PCBackendProcessing

Doctor’s PCBackendProcessing

Imprinting Device

CareGiver

Imprinting Device

PN

PN

PN

PN

PNf

PNf

PNf

7

PN2 homecluster

Gateway / fAC

PN1 homecluster

Gateway / fAC

InfrastructureSecure PN Pipe

PNf Structure

PN1 cluster(Body Hub etc.)

Gateway / fAC

NAT

fAC = Federation Access Controller

Secure PNf-Pipe

NAT NAT

8

Communication Structure for Distributed Expert System

Decision SupportSystem

Decision SupportSystem

DS

S A

PI (T

CP

?, SO

AP

?)

Service 1

Service 2

Service 1

Service 2

GatewayfAC

Firew

allV

PN

Term

inationA

uthent. & A

uthorization

GatewayfAC

Fire

wal

lV

PN

Ter

min

atio

nA

uthe

nt.

& A

utho

rizat

ion

9

Hardware and Component View

Sensors Body-Hub Gateway/Proxy Back-office Terminal

Client PN Service Provider PNFederation

Basic Signal ProcessingSignal Fusion

Sensor Driver

Decision Support Decision Support

Sensor NWRadio

WLAN(GPRS,UMTSInter/Intranet)

Ethernet

Symmetric Encryption? WPA, VPN VPN VPN

Internet

PN-FirewallPNf service GW

PN-FirewallPNf service GW

CodeRepositoryPNf descriptionsPNf policies

Trust4AllCode Loader etc

Trust4AllCode Loader etc

PNf-ManagerPNf descriptionsPNf policies

PNf-Manager

10

Contents

• Overall architecture

• Federations

• Body hub

• Security considerations

• Use cases

11

Vitruvius system

Privacy: good (3)Openness: neutral (1)Connection: stand-alone

Sensor ID Install Data Monitor Event

ECG 10 dr. Richman

Heart rate(0.2 Hz)

Dr. RichmanDr. Young

SMS

Accel 98 Dr. Young

Posture Dr. Young

none

Accel 47 Yourself

Sensor(10 Hz)

Playstation

12

Vitruvius system

Privacy: good (3)Openness: neutral (1)Connection: stand-alone

Sensor ID Install Data Monitor Event

ECG 10 dr. Richman

Heart rate(0.2 Hz)

Dr. RichmanDr. Young

SMS

Accel 98 Dr. Young

Posture Dr. Young

none

Accel 47 Yourself

Sensor(10 Hz)

Playstation

13

Dr. Richman requests you to join the Kempenhaeghe federation. On account of the Dutch Ministry of health we can trust this is true.

Accept Decline

Kempenhaeghe

(C) sensor abstraction layer

ACCdriver

ECGdriver

Ruleprogram

Ruleprogram

database

4(a) sensor & history data access

(5) sensor-specific functions & behavior, invocation, registration, multiplexing of same sensor types

body firewall

SENSORS

body hub

(1) see architecture descriptionof fednet

(3) external data access and call-back(Web services / P&S protocol / proprietary )

(A) control &authorization

(2) rule program installation (upload, download)

policy & user consent

Body hub layering

14

(B) rule engine

4(b) sensor management, discovery

State and management

15

(A) control &authorization

policy & user consent

System state

sensors• id, type, installed

privacy indexopenness

connections• initiator, federation, user

modules• signer, (up)loader, user

history trace

User interface

Hub

‘Remote rule engine’

16

(B) rule engine

Ruleprogram

Ruleprogram

Rule (engine) proxy

DSS Standard interactionrule engine – DSS(separate processes)

Protocol – choice:- Vitruvius proprietary

- enough for the proxy to map to the RE-DSS protocol

- Open, making a ‘generic’ connection technology possible- Connection setup:

- which partner has initiative?

Backend

Hub

Contents

• Overall architecture

• Federations

• Body hub

• Security considerations

• Use cases

17

Security considerations

18

MAC, secure channel secure channel,service access control

trustworthinessof components

BSN

Backend domain 1

Backend domain 2

Accelerometer

ECGsensor

Body hub

....

internet

Expert system-1 onBackend system 1

Expert system-2 on Backend system 2 secure connection

body

firew

all

component runtime upload & configure

802.15.4

802.11

Threats and attacks• a sensor may transmit wrong data (malfunction)• wireless communication may be disrupted by interference

(malfunction) or by a malicious person (malicious)• the body hub may be tricked into running a wrong composition of

components (mishandling)• a sensor may be attached to the wrong patient (mishandling)• an intruder might overhear or steal data (malicious), i.e., raw data

from sensors, processed data from body hub or backend system• an intruder might install malicious software on the sensors, the hub

or on the backend system (malicious)• through physical interference the BSNs of two different persons may

become mixed up (malfunction)• a sensor may be associated with the wrong network, i.e. another

patient carries the sensor (malfunction, mishandling)

19

Two privacy concerns• Privacy: transparent control on what is done with data

– beyond just security

• Information leaking– what can a particular receiver infer after seeing partial data

20

Contents

• Overall architecture

• Federations

• Body hub

• Security considerations

• Use cases

21

FedNet: use case

22

FedNet: sequence diagram

23

Uploading component: use case

24

Uploading com

ponent: sequence diagram

25

Data access: use case

26

27

Data access: sequence

diagram

Adding / Removing a Device (sensor)

• New device handed to User in state Factory Default• User ‘touches’ it with Imprinting Device

– New device gets access/communication keys– New device gets initial configuration for PN– Enters state imprinted– Communicates only with Body Hub

• User ‘touches’ device with Imprinting Device orsends it ‘kill’ command from Home PC or presses a reset– Device removes all keys and configuration– Device reverts to Factory Default

• User hands back device

28

(Re)programming sensors & drivers

• Sensor code as well as driver code is uploaded

• Two possibilities:– using interface 4(b) passing code via Control &

Authorization

– using interface 4(a) as part of the code of the rule program

29

Envisaged implementation• SAL: OSAS programming environment

– treats drivers and sensor programs the same– define interfaces 4 and 5 as system calls in the OSAS system

• FedNet: software by WMC

• Rule engine: distributed implementation of Rule Engine of Medecs

• Expert system: Gaston

30

First demonstration• OSAS layer, implement srudimentary SAL• Simple processing in a library, represents rule engine +

rule program• Information is streamed towards backend

• Integrated with FedNet

31