martin.becker@iese.fraunhofer.de

1. Software Architecture and Technology for AAL Martin Becker martin.becker@iese.fraunhofer.de Dagstuhl Seminar AAL 16.11.2007

2. Fraunhofer Institute for Experimental Software Engineering • Kaiserslautern, Germany • 180 Employees • Applied Research & TT in Systems & Software Engineering • InternationalPositioning • USA, Hungary, India, Japan, and Korea • Innovative Cooperation Model • “Research Labs” • High International Reputation in • “Systems & Software Engineering” • No. 1 in Europe (JSS, 2005)

3. Content • Ambient Assisted Living (AAL) • Architectural Considerations • Promising Technology • Remarks, Questions & Wrap Up

4. Ambient Assisted Living (AAL)

5. Ambient Assisted Living (AAL) Equipment and services for the independent living of people, via the seamless integration of info-communication technologies within homes and extended homes, thus increasing their quality of life and autonomy and reducing the need for beinginstitutionalised[source: www.aal169.org] Goals: • Increase quality of life • Reduce need for external assistance • Reduce health and care costs for the individual and the society • Avoid stigmatisation • Ease human care

6. Home ExtendedHome AAL Landscape Social Environment Health & Care Services & Goods Safety, Security & Privacy

7. Home ExtendedHome AAL Landscape Social Environment Wellness Health & Care Mobility Big Bang will fail Reha Hospital Social Interaction Home Care Med. Practitioner EmergencyService Services Services & Goods Safety, Security & Privacy SecurityService Domotic Household Goods Delivery Where to start first? Poor integration in overlapping areas this time

8. Projects: BelAmI Bilaterial German-Hungarian Collaboration on Ambient Intelligence Systems Research Activities in • Microelectronics and Sensors: Low power systems, dynamic sensors networks • Mobile Communication: Adaptive QoS • Software Engineering: Dynamic reconfigurable architectures, context awareness, resource optimized programming • Human Computer Interaction: Usability engineering for flexible and adaptive systems, adaptive HCI • Safety&Security:Analysis and engineering techniques for safe, secure and dependable AmI applications • System and Software Integration: Position, activity and vital data tracking technology, integration into AAL system architecture and application Applicationdomain: Assisted living • Home care assistance in daily routine + health monitoring Funding: BMBF, RLP, FhG Duration: 10.2004 – 09.2008 Partners: Fh IESE, TU-KL, BayAmI, TU Budapest, Uni Szeged

9. Assisted Living Lab • "Demonstrator-driven" research closely related to application • Integration of partial solutions together with research and industrial partners • Realistic simulation of the environment • Requirements elicitation • Testing of individual technologies (prototypes) • Pre-studies for field tests • Evaluation of safety and security, reliability, accuracy, usability, speed, acceptance (before operation) • Partners: • Partners from Industry and Research • Hospital (Westpfalz-Klinkum): Medical Expertise, User Representative • Nursing Home (Westpfalz-Klinikum): Users, Real Life • Emergency Medical Service (Rettungsleitstelle Kaiserslautern): Acute Medical Competence Centre

10. AAL Service Classification Emergency Treatment Autonomy Enhancement Comfort prediction detection prevention drinking eating cleaning cooking dressing medication logistic services services for finding things infotainment services Indoor prediction detection prevention shopping traveling banking transportation services navigation services Outdoor • Dependance decreases to the right • Relevance of a function can change over time (e.g., communication service)

11. Assisted Living Lab

12. Projects: EMERGE Applicationdomain: Emergency assistance in the home environment Funding: EU IST-045056 Duration: 02.2007 – 10.2009 Partners: FhG IESE, Siemens, Westpfalz-Klinikum, NCSR Demokritos, EMIC, e-ISOTIS, AoT, Bay Zoltan, Med. Uni. Graz

13. Projects: AmbiComp • Objective: • Streamline Development of AmI/AAL Solutions • Low cost / high quality solutions • Development of „AmI Construction Set“: • Software Engineering Method (Dynamic Integration, Adaptivity, …) • Software: Development Platform • Reusable Components • Development Environment • Hardware: wireless Nodes with BT/Zigbeeand Infrared Communication Applicationdomain: Safety and Security (intelligent fire alarm) Funding: BMBF-SE2006 Duration: 05.2006 – 12.2008 Partners: Universität Karlsruhe, Beecon GmbH, Alcatel SEL AG, Fraunhofer IESE, Hochschule der Medien Stuttgart

14. Architectural Considerations

15. Required Qualities Usability User Experience Accessability Quality tradeoffs! Suitability Affordability Performance Dependability & Privacy Integratability Relevance to achievement of user goals? Quality model required! Extensibility Controlability Changability Anticipatory Personalization

16. Human Capability Model HumanCapabilities a perfect existing disabilities b ht = ft (p1, p2, . . . . , pn) normal c critical emergency time

17. Closed Loop Controller • Information: Activities, Position, Vital Data Feedback enableslearning!

18. AAL System – an intelligent environment AmiNode User Interaction

19. Service Oriented Architecture (SOA) • Separate the contract from the implementation  Loose-coupling • Allows alternate implementations • Dynamically discover and bind available implementations • Based on contract (interface) • Components are reusable • Static vs. dynamic binding Virtualization! Events? QoS?End-to-End?

20. watchTV controlhome monitoractivity World is changing Cost sharing? 1:1 n:m Money is made with services! watchTV 1:n n:m Revenue sharing?

21. Peer-To-Peer • peer-to-peer computer network exploits diverse connectivity • cumulative bandwidth of network participants • equal peer nodes • ad hoc networking • interesting qualities: robustness, performance

22. Other Relevant Styles • Event Driven Architecture • Multi Agent Systems • Enterprise Service Bus • Service Area Networks • Service Oriented Device Architecture (SODA) Some of these styles will converge QoS managementwill be central

23. Conceptual Organisation AAL System Structure systemlike real world! Easy to understand!

24. Context-Awareness • “…Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves.” • “…Context-awareness is a property of a system that uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task.” [Anind Dey] • Types: Device, User, Physical Context is key!

25. Context-Awareness • All components can provide/use context • Context can be exchanged between Nodes  information distribution • Processed information can be considered as context • Context Manager  Information broker Some kind of blackboardcan be realized! Meta-model required!AAL concept model?

26. Context-Awareness • Any data flow can be realized • Access of data can be controlled by context management • Context will become very important • Quality of context has to be considered: precision, reliability, cost L A A L What is context? P P P Standard formats?

27. Adaptation Support • Support external and self-adaptation (adaptivity) • Treat adaptation / adaptivity as an aspect (orthogonal) Global optimization! Consistentoptimization!

28. Promising Technology

29. Middleware • provide complete decentralized communication among components • provide extensibility and exchangeability • provide conflict resolution • Technologies: RMI, Corba, HAVi, Jini, JXTA, UPnP, OSGi, …

30. JXTA • open source, peer-to-peer protocol • by Sun Microsystems in 2001 • set of XML messages • any device connected to a network can exchange messages and collaborate independently of the underlying network topology • most mature general purpose P2P framework Conflict Management?

31. UPnP – Universal Plug and Play • a set of computer network protocols • offers an easy way to connect electronic devices on a local network • without any user configuration • simple control possibilities for the services of the networked devices by a Control Point • an ISO standard

32. UPnP features • Service discovery • Media and device independence • Operating system and programming language independence • Internet-based technologies (IP, TCP, UDP, HTTP, and SOAP, XML) • Extensibility Conflict Management?

33. OSGi • Problems of nowadays: • Increased functionality, software complexity • Shortened product cycles • Different manufacturers, interoperability problems • The solution: • OSGi technology is the dynamic module system for Java™ • universal middleware • provides the standardized primitives for the collaborative components • change the composition dynamically without requiring restarts • provides a service-oriented architecture • enables these components to dynamically discover each other for collaboration

34. The buildup of the OSGi system • System services • OSGi Framework • Bundels

35. OSGI framework • provides a standardized environment to applications (called bundles) • The layers: • L0: Execution Environment • L1: Modules: defines the class loading policies • L2: Life Cycle Management • L3: Service Registry • Founds the basis of Eclipse IDE • no model break • enables continuous, holistic engineering

36. OSGI Framework • Allows applications to share a single Java VM • Classloading • Isolation/Security • Communication & Collaborations between applications • Life cycle management • Policy free

37. BELAMI OSGI Platform/Overview • dynamic reconfiguration • model based adaptation BELAMI Platform R-OSGi OSGi TCP/IP

38. AMIGO • usability of a networked home system • developing open, standardized, interoperable middleware • service discovery and service composition strategies • each component is responsible for the application of such strategies • strategies are not public or transparent to the application developers • semantic description of services • some components will be publicly available Nice documentation!

39. AMIGO

40. DynaMITE • component topologies, which are determined by a data flow model • components: multimodal input and output, dialogue, strategy components, actuators. The different • semantic channels: • define specific strategies for distributing messages • enable the cooperation of components and the fragmentation of messages into sub-messages • strategies can be implemented in a distributed way across the software infrastructure QoS?

41. Other Middleware Approaches Cope with several middlewares! • AlarmNet, EASY-LINE+, I2Home, I-LIVING, INHOME, INTERPLAY, LARES, MONAMI, MPOWER, NETCARITY, OASIS, OLDES, Oxygene, PERSONA, SENSACTION-AAL, SOPPRANO … • Specific qualities • No One-Size-Fits-All • Middleware should be an open standard Be prepared for change!

42. Sementic Web Models • Resource Description Framework (RDF) • data interchange formats • RDF Schema (RDFS) • Web Ontology Language (OWL) • formal description of concepts, terms, and relationships within a given knowledge domain If not applicable, at least some concepts can be used!

43. Context Models • Standard Ontology for Ubiquitous and Pervasive Applications (SOUPA) • Person, Policies, Agent & Belief-Desire-Intentions, Time, Space, Events • Context Ontology (CONON) • RDF based • computational entity, location, person, and activity • … [conon]

44. Context Management Systems • u2m.org [PhD Heckmann] • manages information about users, about their contexts and the, situation in general • SOCAM • rapid prototyping of context-aware services based on CONON • AMIGO • well defined interfaces • … [Amigo] quality is oftenunclear

45. Remarks, Questions& Wrap Up

46. Some remarks • Clearly separate architecture and technology • it should be possible • Separate function (service) and data (context) • they evolve differently • Separate between devices and services • greater flexibility • ease integration, better interoperability • Providing technology is not enough • specifications (function, quality), proof of value are required • Go for standardized interfaces and information exchange

47. Some Questions • How to get a sound domain/feature model of AAL? • Who architects the holistic AAL system? • we will provide only components to it • we would profit from standardized interfaces • Who manages the architecture? • Who assesses the suitability of technology We could as a Community do some!

48. Wrap up • Promising technology is available • its applicability is unclear (context dependence, quality) • Integration of solutions is possible • but at what quality (effort)? • Personalized infomation will be key • how to keep in control of it • From devices to services • new business models required • Proposal: set up a interdisciplinary AAL network with a clear shaped mission

49. AAL Innovation Model We can to matchboth worlds [ www.aal169.org]