VITRUVIUS Use cases and initial architecture January 22

1
VITRUVIUSUse cases and initial
architectureJanuary 22

• Johan Lukkien
• TU/e, System Architecture and Networking

2
Contents

• Overall architecture
• Federations
• Body hub
• Security considerations
• Use cases

3
Conceptual architecture from proposal
Applications
Body Hub (DSP)
Sleep management
Patient Monitoring
Posture Coach
Social Care

Application-Specific Compound Decision Support
IEEE 1073, Continua, HL7
Security Interface (Gate Keeper / Body Firewall)
Application Specific Component
Application Specific Component
Storage Historic data engine
Local Decision Support engine
Application Specific Component
Secure Upload and Configuration Manager
Trust and Ownership Monitor engine
Multi-Sensor Signal Processing
BAN, IEEE 15.4 Zigbee IEEE 1455, IEEE 1073,
Sensor Node
Sensor Node
Single Signal Processing
Single Signal Processing
Actuator
Sensor
Actuator
Sensor

4
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
5
Overall architecture

• 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

6
Contents

• Overall architecture
• Federations
• Body hub
• Security considerations
• Use cases

7
Personal Network Federation
Doctors PC
Backend Processing
Imprinting Device
PNf
PN
PNf
Imprinting Device
PN
PN
PNf
PN
8
PNf Structure
Infrastructure
PN2 home cluster
PN1 home cluster
Gateway / fAC
Gateway / fAC
NAT
NAT
Secure PNf-Pipe
Secure PN Pipe
NAT
Gateway / fAC
PN1 cluster (Body Hub etc.)
fAC Federation Access Controller
9
Communication Structure for Distributed Expert
System
Gateway fAC
Firewall
VPN Termination
Authent. Authorization
DSS API (TCP?, SOAP?)
Gateway fAC
Firewall
VPN Termination
Authent. Authorization
Service 1
Service 1
Service 2
Service 2
Decision Support System
Decision Support System
10
Hardware and Component View
Trust4All Code Loader etc
Trust4All Code Loader etc
Code Repository PNf descriptions PNf policies
PNf-Manager
PNf descriptions PNf policies
PNf-Manager
PN-Firewall PNf service GW
PN-Firewall PNf service GW
Sensor Driver
Symmetric Encryption?
WLAN (GPRS,UMTS Inter/Intranet)
Sensor NW Radio
Ethernet
Internet
Sensors
Body-Hub
Gateway/Proxy
Back-office
Terminal
11
Contents

• Overall architecture
• Federations
• Body hub
• Security considerations
• Use cases

12
Vitruvius system Privacy
good (3) Openness neutral (1) Connection
stand-alone
Sensor ID Install Data Monitor Event
ECG 10 dr. Rich man Heart rate (0.2 Hz) Dr. Richman Dr. Young SMS
Accel 98 Dr. Young Posture Dr. Young none
Accel 47 Your self Sensor (10 Hz) Playstation
13
Vitruvius system Privacy
good (3) Openness neutral (1) Connection
stand-alone
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
Sensor ID Install Data Monitor Event
ECG 10 dr. Rich man Heart rate (0.2 Hz) Dr. Richman Dr. Young SMS
Accel 98 Dr. Young Posture Dr. Young none
Accel 47 Your self Sensor (10 Hz) Playstation
14
Body hub layering
(1) see architecture description of fednet
body firewall
body hub
(2) rule program installation (upload, download)
(A) control authorization
policy user consent
(3) external data access and call-back (Web
services / PS protocol / proprietary )
4(b) sensor management, discovery
(B) rule engine
Ruleprogram
Ruleprogram
4(a) sensor history data access
(C) sensor abstraction layer
database
(5) sensor-specific functions behavior,
invocation, registration, multiplexing of same
sensor types
ACC driver
ECG driver
SENSORS
15
State and management

• System state
• sensors
• id, type, installed
• privacy index
• openness
• connections
• initiator, federation, user
• modules
• signer, (up)loader, user
• history trace

User interface
(A) control authorization
policy user consent
Hub
16
Remote rule engine
Backend
DSS
Standard interaction rule engine DSS (separate
processes)
Rule (engine) proxy

• 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?

(B) rule engine
Ruleprogram
Ruleprogram
Hub
17
Contents

• Overall architecture
• Federations
• Body hub
• Security considerations
• Use cases

18
Security considerations
PRIVACY
trustworthiness of components
secure channel, service access control
MAC, secure channel
19
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)

20
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

21
Contents

• Overall architecture
• Federations
• Body hub
• Security considerations
• Use cases

22
FedNet use case
23
FedNet sequence diagram
24
Uploading component use case
25
Uploading component sequence diagram
26
Data access use case
27
Data access sequence diagram
28
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

29
(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

30
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

31
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