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
Applications
Sleep
management
Patient
Monitoring
Posture
Coach
Social Care
Application-Specific Compound Decision Support
IEEE 1073, Continua, HL7
Application
Application
Specific
Application
Specific
Component
Specific
Component
Component
Local Decision
Support engine
Storage: Historic
data engine
Secure Upload and
Configuration Manager
Trust and Ownership
Monitor engine
Body Hub (DSP)
Security Interface (Gate Keeper / Body Firewall)
Multi-Sensor Signal Processing
Single Signal
Processing
Sensor
Actuator
…
Sensor Node
Sensor Node
BAN, IEEE 15.4 Zigbee
IEEE 1455, IEEE 1073,
Single Signal
Processing
Sensor
Actuator
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
ICCE, CCNC 2010
4
Overall architecture
Expert system-1 on
Backend system 1
Accelero
meter
8
0
2
.
1
5
.
4
component
runtime
body
firewall
....
Backend domain 1
upload & configure
secure connection
internet
Body hub
ECG
sensor
BSN
8
0
2
.
1
1
Expert system-2 on
Backend system 2
Backend domain 2
Terminology
• both BSN domain and backend
domain are called personal
networks
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
5
Contents
•
•
•
•
•
Overall architecture
Federations
Body hub
Security considerations
Use cases
6
Personal Network Federation
Backend
Processing
PNf
Doctor’s PC
Imprinting Device
PN
Body Hub
BS
BS
BS
Backend
Processing
Doctor’s PC
PNf
Imprinting Device
Imprinting Device
PN
PN
PNf
CareGiver
PN
Imprinting Device
7
PNf Structure
PN1 home
cluster
PN2 home
cluster
Gateway / fAC
Gateway / fAC
NAT
NAT
Secure PNf-Pipe
Secure PN Pipe
Infrastructure
NAT
Gateway / fAC
PN1 cluster
(Body Hub etc.)
fAC = Federation Access Controller
8
Decision Support
System
Firewall
VPN Termination
Authent. & Authorization
Service 2
DSS API (TCP?, SOAP?)
Service 1
Firewall
VPN Termination
Authent. & Authorization
Communication Structure for
Distributed Expert System
Gateway
fAC
Gateway
fAC
Service 1
Service 2
Decision Support
System
9
Hardware and Component View
Trust4All
Code Loader etc
PNf descriptions
PNf policies
Trust4All
Code Loader etc Code
Repository
PNf-Manager
PNf descriptions
PNf policies
PN-Firewall
PNf-Manager
PN-Firewall
PNf service GW
PNf service GW
Decision Support
Signal Fusion
Basic Signal Processing
Sensor Driver
Symmetric Encryption?
WPA, VPN
Client PN
Sensor NW
Radio
Sensors
Body-Hub
WLAN
(GPRS,UMTS
Inter/Intranet)
Gateway/Proxy
Decision Support
VPN
VPN
Federation
Service Provider PN
Internet
Ethernet
Back-office
Terminal
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
ECG
10
dr. Rich
man
Heart
rate
(0.2
Hz)
Dr.
Richman
Dr.
Young
Accel
98
Dr.
Young
Posture
Dr.
Young
Accel
47
Your
self
Sensor
(10 Hz)
Playstatio
n
Event
SMS
none
12
Vitruvius system
Kempen
haeghe
Privacy:
good (3)
Openness: neutral (1)
Connection: stand-alone
Dr. Richman requests you to join
the Kempenhaeghe federation. On
account
ofInstall
the Dutch
of Event
Sensor
ID
Data Ministry
Monitor
health we can trust this is true.
ECG
10
Accept
dr. Rich
man
Heart
rate
Decline
(0.2
Hz)
Dr.
Richman
Dr.
Young
Accel
98
Dr.
Young
Posture
Dr.
Young
Accel
47
Your
self
Sensor
(10 Hz)
Playstatio
n
SMS
none
13
Body hub layering
(1) see architecture description
of fednet
body firewall
body hub
(2) rule program installation
(upload, download)
(A) control &
authorization
4(b) sensor
management,
discovery
policy &
user consent
Rule
program
Rule
program
(B) rule
engine
(3) external data access and call-back
(Web services / P&S protocol /
proprietary )
4(a) sensor & history data access
(C) sensor abstraction
layer
ACC
driver
ECG
driver
database
(5) sensor-specific functions &
behavior, invocation, registration,
multiplexing of same sensor types
SENSORS
14
State and management
System state
sensors
• id, type, installed
privacy index
openness
connections
• initiator, federation,
user
User interface
(A) control &
authorization
policy &
user consent
modules
• signer, (up)loader,
user
history trace
Hub
15
‘Remote rule engine’
Backend
DSS
Standard interaction
rule engine – DSS
(separate processes)
Rule (engine) proxy
(B) rule
engine
Rule
program
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?
Rule
program
Hub
16
Contents
•
•
•
•
•
Overall architecture
Federations
Body hub
Security considerations
Use cases
17
Security considerations
Expert system-1 on
Backend system 1
Accelero
meter
Backend domain 1
....
component
runtime
body
firewall
8
0
2
.
1
5
.
4
upload & configure
secure connection
internet
Body hub
ECG
sensor
BSN
trustworthiness
of components
MAC, secure channel
8
0
2
.
1
1
Expert system-2 on
Backend system 2
Backend domain 2
secure channel,
service access control
18
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 component: sequence
diagram
25
Data access: use case
26
Data access: sequence
diagram
27
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 or
sends 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