1 / 27

VITRUVIUS D1.1a: Architecture and Interfaces

VITRUVIUS D1.1a: Architecture and Interfaces. Johan Lukkien Shervin Hajiamini Hartmut Benz. Contents. Overall architecture Federations Body hub Use cases. Applications. Conceptual architecture from proposal. Body Hub (DSP). Sleep management. Patient Monitoring. Posture Coach.

yates
Download Presentation

VITRUVIUS D1.1a: Architecture and Interfaces

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. VITRUVIUSD1.1a: Architecture and Interfaces Johan Lukkien Shervin Hajiamini Hartmut Benz VITRUVIUS D1.1a - v0.2

  2. Contents • Overall architecture • Federations • Body hub • Use cases VITRUVIUS D1.1a - v0.2

  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 … VITRUVIUS D1.1a - v0.2

  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 VITRUVIUS D1.1a - v0.2

  5. Contents • Overall architecture • Federations • Body hub • Use cases VITRUVIUS D1.1a - v0.2

  6. 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 VITRUVIUS D1.1a - v0.2

  7. 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 VITRUVIUS D1.1a - v0.2

  8. Communication Structure for Distributed Expert System Firewall Gateway fAC 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 VITRUVIUS D1.1a - v0.2

  9. 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 VITRUVIUS D1.1a - v0.2

  10. Contents • Overall architecture • Federations • Body hub • Use cases VITRUVIUS D1.1a - v0.2

  11. Vitruvius system Privacy: good (3) Openness: neutral (1) Connection: stand-alone VITRUVIUS D1.1a - v0.2

  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 Kempen haeghe VITRUVIUS D1.1a - v0.2

  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 / 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 VITRUVIUS D1.1a - v0.2

  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 VITRUVIUS D1.1a - v0.2

  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 VITRUVIUS D1.1a - v0.2

  16. Contents • Overall architecture • Federations • Body hub • Use cases VITRUVIUS D1.1a - v0.2

  17. FedNet: use case VITRUVIUS D1.1a - v0.2

  18. FedNet: sequence diagram VITRUVIUS D1.1a - v0.2

  19. Uploading component: use case VITRUVIUS D1.1a - v0.2

  20. Uploading component: sequence diagram VITRUVIUS D1.1a - v0.2

  21. Data access: use case VITRUVIUS D1.1a - v0.2

  22. Data access: sequence diagram VITRUVIUS D1.1a - v0.2

  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 VITRUVIUS D1.1a - v0.2

  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 VITRUVIUS D1.1a - v0.2

  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 VITRUVIUS D1.1a - v0.2

  27. To Do • Define interfaces explicitly • class diagrams • Make a process view VITRUVIUS D1.1a - v0.2

More Related