VITRUVIUS D1.1a: Architecture and Interfaces

1
VITRUVIUSD1.1a Architecture and Interfaces

• Johan Lukkien
• Shervin Hajiamini
• Hartmut Benz

2
Contents

• Overall architecture
• Federations
• Body hub
• 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
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

5
Contents

• Overall architecture
• Federations
• Body hub
• Use cases

6
Personal Network Federation
Doctors PC
Backend Processing
Imprinting Device
PNf
PN
PNf
Imprinting Device
PN
PN
PNf
PN
7
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
8
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
9
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
10
Contents

• Overall architecture
• Federations
• Body hub
• Use cases

11
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
12
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
13
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
14
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
15
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
16
Contents

• Overall architecture
• Federations
• Body hub
• Use cases

17
FedNet use case
18
FedNet sequence diagram
19
Uploading component use case
20
Uploading component sequence diagram
21
Data access use case
22
Data access sequence diagram
23
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

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

25
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

26
First demonstration

• OSAS layer, implement rudimentary SAL
• Simple processing in a library, represents rule
  engine rule program
• Information is streamed towards backed
• Integrated with FedNet

27
To Do

• Define interfaces explicitly
• class diagrams
• Make a process view