Modularized middleware architecture for smart home & smart home lab

Modularized middleware architecture for smart home & smart home lab

Software Engineering Laboratory

Department of Computer Science

Iowa State University

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 s

mart 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

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 prefere

nce• 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 ser

vices to web services

Middleware architecture overview

Physical Physical

Device normalization/IntegrationDevice normalization/Integration

Service supportService support

Security

Security

Safety

Safety

ApplicationApplication

Web-based interfaceWeb-based interface

Dev/Exp supportDev/Exp support

DesignmoduleDesignmodule

Case-Basedmodule

Case-Basedmodule

Service Execution

module

Service Execution

module

Contextanalysismodule

Availability

Availability

AuditmoduleAudit

moduleService

DB (SDB)Service

DB (SDB)

KnowledgeDB (KDB)

KnowledgeDB (KDB)

Middleware architecture layers (1/4)

• Physical– Consist of a variety of devices and appliances such as cell phon

es, PCs, PDAs, sensors, detectors, controllers (for example, X10), etc.

• Device normalization/Integration– Wrap any devices and appliances of the physical layer in a softw

are 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

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

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

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

Requirements for smart home lab (1/3)• The key requirements for the smart home lab

1. SHL/SH shall have wireless/wire network2. SH shall be operated normally when the middleware architect

ure is abnormal3. SHL/SH shall have the security mechanism4. SH shall have the ability to detect occupants’ context and iden

tification if there are more than one occupant5. Middleware Architecture

1) The middleware architecture shall accept inputs/commands fromi. Cell phonesii. PCsiii. PDAsiv. Sensorsv. detectorsvi. Controllers (such as X10)

2) The middleware architecture shall have the ability to communicate with other organizations

Requirements for smart home lab (2/3)• The key requirements for the smart home lab (cont)

5. Middleware Architecture (cont)3) The middleware architecture shall give commands/outputs to

i. Cell phonesii. PCsiii. PDAsiv. Devicesv. Other organizations

4) The middleware architecture shall store data such that it can be imported/exported in some specific formats (efficiently)

5) The middleware architecture shall be able to discover plug-in devices6) The middleware architecture shall have the ability to integrate applianc

es/devices7) The middleware architecture shall automatically turn on/off some applia

nces/devices if some specific events occur8) The middleware architecture shall be able to change its behavior for ti

me- and situation-awareness9) The middleware architecture shall be able to remind the occupants for

some specific things

Requirements for smart home lab (3/3)

• The key requirements for the smart home lab (cont)6. Device Control

1) Researchers shall be able to enable/disable devices

2) Researchers shall be able to view/retrieve the status of a device

3) Researchers shall be able to operate all the functions of a device

7. Experiment Simulation Capability1) Researchers shall be able to create the services/simulations/experim

ents over the middleware architecture

2) Researchers shall be able to extract system status information

3) Researchers shall be able to develop their new applications

Device Normalization/Integration• OSGi (Open Services Gateway Initiative)• EJB (Enterprise Java Beans)

B/S/H/Residential Gateway

Tablet PCMobile telephone

WLA

NGSM

Powerline

Indoor Communication

Outdoor Communication

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 archite

cture– Deployment of services in platforms

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 bund

les 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.