1 / 31

VITRUVIUS Use cases and initial architecture January 22

VITRUVIUS Use cases and initial architecture January 22. Johan Lukkien TU/e, System Architecture and Networking. Contents. Overall architecture Federations Body hub Security considerations Use cases. Applications. Conceptual architecture from proposal. Body Hub (DSP). Sleep management.

borka
Télécharger la présentation

VITRUVIUS Use cases and initial architecture January 22

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Applications Conceptual architecture from proposal 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 Sensor Actuator Sensor Actuator …

  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. Body Hub Backend Processing Doctor’s PC BS BS BS Imprinting Device CareGiver Imprinting Device Personal Network Federation Backend Processing Doctor’s PC Imprinting Device PNf PN PNf Imprinting Device PN PN PNf PN

  8. Infrastructure PNf Structure PN1 home cluster PN2 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 Authent. & Authorization VPN Termination Firewall Service 1 Service 1 Service 2 Service 2 Decision Support System Decision Support System

  10. Decision Support Decision Support Signal Fusion Basic Signal Processing VPN VPN WPA, VPN Client PN Federation Service Provider PN 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 Internet Ethernet 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

  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 Kempen haeghe

  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 / P&S 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

More Related