The GAL Middleware Platform

Transcription

1 Lower Saxony Research Network Design of Environments for Ageing The GAL Middleware Platform Architecture and Experiences Dr. Marco Eichelberg OFFIS-Institute for Information Technology

2 2 Introduction Technical Components of AAL Assistive Systems AAL assistive systems are technical systems with some typical components Sensors: capturing of information about user and environment On the body: vital parameters, acceleration In the environment: camera, microphone, motion sensor, electrical devices Actuators Controlling e.g. building automation (lighting, heating, doors, windows) Network (cabled or wireless) connecting sensors, actuators and IT Data processing: the system s intelligence Use of context knowledge: floor plan of the flat, user preferences, etc. Making decisions: alarm, interaction, controlling actuators This is software operating on a computer Interaction: with the inhabitant and with external users Graphical user interface (GUI) on a computer display or TV set New devices and forms of interaction (multi-modal: speech, sound, light, ) Telephone, , Fax, Web, SMS etc.

3 3 Technical Challenges in Building AAL Systems #1 Connecting Sensors and Actuators Connecting sensors/actuators from different domains Medical devices: ECG, pulse oximetry, blood pressure etc. Building automation: switches, temperature sensors, motion sensors, door contacts etc. Household appliances: oven, cooker, fridge etc. Cabled and wireless networks Cabled: USB, Ethernet, RS 232, KNX/EIB, LON... Wireless: Bluetooth, Zigbee, Z-wave, EnOcean, FS20... Many rivaling data formats For example ECG: DICOM, SCP-ECG, HL7 aecg, MFER, ISO/IEEE or proprietary? Processing software needs an abstract view of the data When checking an ECG for tachycardia, the network and protocol over which the data arrive are totally irrelevant!

4 4 Technical Challenges in Building AAL Systems #2: Flexible Execution Environment for Software Components User requirements change over time Change of health status Change of appliances in the apartment Assistive systems must adapt to the user s needs! Nobody wants to buy and install a separate PC for each new function! What is needed is an execution environment (platform) that supports, according to current needs Connecting sensors and actuators Installing software for processing the data This also enables the use of data from one sensor for multiple functions e.g. fall recognition and burglary alarm

5 5 Technical Challenges in Building AAL Systems #3: Commodity Hardware Most prototypes of assistive systems require a PC as software execution environment Expensive (ca EUR) high-maintenance product But: high processing power, lots of memory Better suited: embedded systems such as DSL routers or set-top boxes for satellite TV Cheap (ca. 100 EUR), low maintenance But: Little memory and processing power Moore s law: CPU power + memory double every 18 months Challenge: Design software such that a (later) transfer to an embedded device is possible & easy No display, no keyboard, no MS Windows

6 6 Technical Challenges in Building AAL Systems #4 Middleware Certain functions are needed again and again by different assistive systems: Connecting sensors and actuators Persistent storage of data Floor plan of apartment, position of sensors Interaction with inhabitant and outside world Exchange of health information with doctor/hospital Remote maintenance, backup It makes sense to implement such functions only once and make them usable by different assistive modules This is the GAL Middleware Platform: Software execution environment with reusable infrastructure services Sensor/actuator connection Supports standard PCs and commodity hardware

7 7 GAL Middleware Platform: General Execution Environment APIs Drivers Hardware OSGi Applications Device Abstraction JAVA JNI Operating System Protocols Security Services Networks (WAN, LAN, KNX, Bluetooth, RS232, )

8 8 What is OSGi? Execution environment for Java software components ( bundles ) Components are managed dynamically Install, load, start, stop, update, de-install at runtime Applications are designed as SOA Communication by services Implementation of components against service interfaces Manages component dependencies Works on every system with Java VM Enables remote maintenance Provide many standard functions logging, configuration, HTTP, XML, user management,

9 9 GAL Middleware Platform: Structure User Interface A Configurations Application C Application B Persistence: DB Interface Persistent Storage Application A Abstraction Abstraction OSGi Bundle: Sensor B OSGi Bundle: Actuator A OSGi Bundle: Sensor A OSGi OS Driver OS Driver OS Driver OS Interface Interface Interface Hardware platform Sensor B Actuator A Sensor A

10 10 Device Abstraction A development by OFFIS and Universität Rostock from the OSAmI project Decouples applications from devices ( Function Level Device Access ) Applications only depend on functional services, e.g. ECG service Supports Established network technologies: RS232, USB, Bluetooth, Newer network technologies: DPWS (web services), UPnP, ZigBee, DPWS Same interface for devices of same type

11 11 Sensors in GAL (selected) Physical Sensors Cameras, Microphones Building automation: door contact, light barrier, switches, outlets, presence sensor Domotics: cooker, fridge, oven etc. Body Area Network: ECG, blood pressure, SpO2, temperature, acceleration Ultrasound distance sensors Electricity sensor Virtual Sensors Position (from ultrasound, camera, audio) Use of electrical devices Fall recognition (from camera, accelerometry) Activity recognition (multiple sources) Voice commands Pulse and breathing frequency (from ECG)

12 12 Infrastructure Services of the GAL Technical Platform Yw Multi-modal user interface service Output of messages to the inhabitant, e.g. via speech, audio, light Service for Graphical User Interfaces Accessible by web browser Consistent look and feel Service for connecting with the personal health record Storage and retrieval of health related data Service for persistent storage (database) Remote backup service Service for alarms and message routing to external users Decision support system Floor plan and sensor positions Xw

13 13 Alarms and Message Routing to External Users Escalation Chain recipients message priority recipient priority timeouts for confirmation System Behavior Communication Channels: POTS, Internet/DSL, UMTS Media: Phone, SMS, Fax, Technical Integration AVM Fritz ISDN card vbox3 voice box Jetty web server CapiFax fax module Confirmation Phone (dial tone) Hyperlink In both cases a transaction ID is sent that terminates the escalation chain

14 14 Personal Health Record AAL assistive systems support health related services and produce health information at home. PHR component within the GAL platform serves as repository of health data at home Health information produced at home Training reports from exercise training Reports about falls, behavioral changes etc. Health information needed at home, e.g. training parameters / individual limits Architecture: Information system with web-based GUI, but located at home! Structured data: medication, diagnoses, etc. Documents: HL7 CDA Remote access with user-defined access rights Exchange of information with healthcare IT planned, using IHE standards (XDR, XPHR)

15 15 Tool Chain An important part of an AAL Middleware platform is the definition of a tool chain for software development that helps developers to develop, test and deploy new modules. Within the GAL project, the following tool chain is used Eclipse as IDE Apache Maven with PaxConstruct plug-in as build system Maven server as repository for deployed bundles Subversion as source code repository VMware virtual machine as execution environment for testing Non-trivial learning curve (especially OSGi and Maven), but supports distributed development teams fairly well

16 16 Experiences All in all, the platform works fairly well so far Variants also used in a number of other projects (HaH, OSAmI, PAGE) Java / OSGi platform simplifies ports to different platforms PC with Linux and real-time kernel PC with MS Windows Set-top box, DSL router (work in progress) Difficulties in unexpected places Linux and OSGi are available for embedded platforms such as Set-top boxes, but Java 1.5 may not. Java language level is a real problem, since run-time is language level dependent Work with the tool-chain really needs time & experience: Maven/Pax woes (and poor documentation), getting used to OSGi etc. have slowed down development significantly for the first couple of months.

17 17 Conclusion The GAL Middleware Platform provide reusable building blocks for assistive systems: Flexible, scalable execution environment Abstraction layer for sensors and actuators Infrastructure services This allows developers to concentrate on the real challenges: Dependable decision support systems Usability Integration of medical and nursing care On the long term a vendor neutral middleware standard for AAL with large user base will be needed, but this is a long way to go!