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
Top Related