Modularized middleware architecture for smart home & smart home lab

1. Modularized middleware architecture for smart home & smart home lab Software Engineering Laboratory Department of Computer Science Iowa State University

2. Design goals • Reconfigurability • Service coordinator (Service composer) • A new description language or a extended version of BPEL4WS • Service execution engine • Scalability • Fully modularized/Impendent layers • operating system independent • Application interchangeability by supporting Uniform APIs • Easy to add/remove new services • Component-based services to support “plug-and-play” • Modularity • Boundary between the layers for the smart home and the ones for the smart home lab • Our architecture includes the features that are required for experiments and help write lab-only-used applications • Two Java-based frameworks • Minimize overhead at the deployment phase

3. Design characteristics • Service • All the services of the smart home are context-aware. • Thus, service design also includes context analysis. • Two levels of services to be associated • Context-based service (high-level) • The service delivered to a customer based on their necessity or preference • Device-specific service (low-level) • The description of basic functionalities of a device such as sensors or controllers • Layered Middleware architecture • Clear interface definitions between the layers • EJB-based component support • Java can work with (or over) OSGi • JavaME is available for small devices • Easy to interact with other services by extending smart home services to web services

4. Context analysis module Middleware architecture overview Web-based interface Application Security Safety Availability Service support Dev/Exp support Knowledge DB (KDB) Case- Based module Audit module Service Execution module Service DB (SDB) Design module Device normalization/Integration Physical

5. Middleware architecture layers (1/4) • Physical • Consist of a variety of devices and appliances such as cell phones, PCs, PDAs, sensors, detectors, controllers (for example, X10), etc. • Device normalization/Integration • Wrap any devices and appliances of the physical layer in a software service to construct device-specific services • Register them with service framework interfaces (SFIs) • Java-based integration environment for services • Communication management, Message processing, etc. • Shared databases • Knowledge database (KDB) for context-awareness • Service database (SDB) for service publication and discovery

6. Middleware architecture layers (2/4) • Service support • Context analysis module • Reason a situation based on diverse context through the KDB • Associate a context with a service in order to construct context-based services • Types of context • Static context: Bar code, RFID tag, … • Dynamic context: the data of sensors/controllers • Service execution module • Binding a service with real software • Question: Need dynamic service composition?  Inference engine • Invoke services though the SDB • Implicitly based on the context analysis • Explicitly by the occupant

7. Middleware architecture layers (3/4) • Development/Experiment support • Design module • Register/Publish an service • Manage the SDB • Describe using a standard service description language such as WSDL • Case-based module • Define an association of a context with services • Manage the KDB • Describe using a new language or an extended version of BPEL4WS • Audit module • Logging/Extracting data and status information • Publish exceptional conditions • Interact with the SDB and the KDB

8. Middleware architecture layers (4/4) • Application • Manage/Scheduling independent programs to monitor/control services • Examples • Context descriptor • Audit analyzer • Service composer • Service simulator • Service administrator • Web-based Interface • Optional to offer a consistent interface to occupants • Provide ubiquitous accessibility by making applications web-accessible • Support remote access via both wired and wireless internet

9. Requirements for smart home lab (1/3) • The key requirements for the smart home lab • SHL/SH shall have wireless/wire network • SH shall be operated normally when the middleware architecture is abnormal • SHL/SH shall have the security mechanism • SH shall have the ability to detect occupants’ context and identification if there are more than one occupant • Middleware Architecture • The middleware architecture shall accept inputs/commands from • Cell phones • PCs • PDAs • Sensors • detectors • Controllers (such as X10) • The middleware architecture shall have the ability to communicate with other organizations

10. Requirements for smart home lab (2/3) • The key requirements for the smart home lab (cont) • Middleware Architecture (cont) • The middleware architecture shall give commands/outputs to • Cell phones • PCs • PDAs • Devices • Other organizations • The middleware architecture shall store data such that it can be imported/exported in some specific formats (efficiently) • The middleware architecture shall be able to discover plug-in devices • The middleware architecture shall have the ability to integrate appliances/devices • The middleware architecture shall automatically turn on/off some appliances/devices if some specific events occur • The middleware architecture shall be able to change its behavior for time- and situation-awareness • The middleware architecture shall be able to remind the occupants for some specific things

11. Requirements for smart home lab (3/3) • The key requirements for the smart home lab (cont) • Device Control • Researchers shall be able to enable/disable devices • Researchers shall be able to view/retrieve the status of a device • Researchers shall be able to operate all the functions of a device • Experiment Simulation Capability • Researchers shall be able to create the services/simulations/experiments over the middleware architecture • Researchers shall be able to extract system status information • Researchers shall be able to develop their new applications

12. Mobile telephone Tablet PC GSM WLAN Indoor Communication Outdoor Communication Powerline B/S/H/ Residential Gateway Device Normalization/Integration • OSGi (Open Services Gateway Initiative) • EJB (Enterprise Java Beans)

13. Why EJB/OSGi? (1) To support component-based software architecture • Modular Components (EJB/OSGi) • Reusability (EJB/OSGi) • Collaborative Model (OSGi) • Highly Dynamic (OSGi) • Software Lifecycle Management (OSGi) • EJB • Visual assembly of applications • OSGi • Open industry framework and service-oriented architecture • Deployment of services in platforms

14. Why EJB/OSGi? (2) • Advantages of OSGI • OSGi defines a framework to mange bundles (units of distribution) and the services they export • Services can be obtained by querying the framework through a set of properties • Disadvantage of OSGi (cons of EJB) • Assemblies are not static. Connections between bundles occur depending on the availability of services • Solutions [Cevantes02] • Use bundles as distribution units that contain JavaBeans • Make these bundles export some particular services that allows for the creation of instances of the JavaBeans they export • Give JavaBeans access to the OSGi framework, so that they can quey for services in a complete way [Cevantes02] H. Cervantes and J. Favre, “Comparing JavaBeans and OSGi Towards an Integration of Two Complementary Component Models”, Euromicro Conference, 2002.