VITRUVIUS

D1.1a: Architecture and Interfaces

Johan Lukkien

Shervin Hajiamini

Hartmut Benz

21-04-23 VITRUVIUS D1.1a - v0.2 1

Contents

• Overall architecture

• Federations

• Body hub

• Use cases

221-04-23 VITRUVIUS D1.1a - v0.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

321-04-23 VITRUVIUS D1.1a - v0.2

Overall architecture

21-04-23 VITRUVIUS D1.1a - v0.2 4

BSN

Backend domain 1

Backend domain 2

Accellerometer

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

• Use cases

521-04-23 VITRUVIUS D1.1a - v0.2

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

21-04-23 6VITRUVIUS D1.1a - v0.2

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

21-04-23 7VITRUVIUS D1.1a - v0.2

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

21-04-23 8VITRUVIUS D1.1a - v0.2

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

21-04-23 9VITRUVIUS D1.1a - v0.2

Contents

• Overall architecture

• Federations

• Body hub

• Use cases

1021-04-23 VITRUVIUS D1.1a - v0.2

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

1121-04-23 VITRUVIUS D1.1a - v0.2

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

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

21-04-23 VITRUVIUS D1.1a - v0.2

(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

13

(B) rule engine

4(b) sensor management, discovery

21-04-23 VITRUVIUS D1.1a - v0.2

State and management

14

(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

21-04-23 VITRUVIUS D1.1a - v0.2

‘Remote rule engine’

15

(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

21-04-23 VITRUVIUS D1.1a - v0.2

Contents

• Overall architecture

• Federations

• Body hub

• Use cases

1621-04-23 VITRUVIUS D1.1a - v0.2

FedNet: use case

21-04-23 VITRUVIUS D1.1a - v0.2 17

FedNet: sequence diagram

21-04-23 VITRUVIUS D1.1a - v0.2 18

Uploading component: use case

21-04-23 VITRUVIUS D1.1a - v0.2 19

Uploading com

ponent: sequence diagram

21-04-23 VITRUVIUS D1.1a - v0.2 20

Data access: use case

21-04-23 VITRUVIUS D1.1a - v0.2 21

21-04-23 VITRUVIUS D1.1a - v0.2 22

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

(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

21-04-23 VITRUVIUS D1.1a - v0.2 24

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

21-04-23 VITRUVIUS D1.1a - v0.2 25

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

21-04-23 VITRUVIUS D1.1a - v0.2 26

To Do• Define interfaces explicitly

– class diagrams

• Make a process view

21-04-23 VITRUVIUS D1.1a - v0.2 27