Modularized middleware architecture for smart home smart home lab
This presentation is the property of its rightful owner.
Sponsored Links
1 / 14

Modularized middleware architecture for smart home & smart home lab PowerPoint PPT Presentation


  • 91 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Modularized middleware architecture for smart home & smart home lab

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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

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


Design characteristics

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


Middleware architecture overview

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


Middleware architecture layers 1 4

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


Middleware architecture layers 2 4

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

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

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

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


Requirements for smart home lab 2 3

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


Requirements for smart home lab 3 3

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


Device normalization integration

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)


Why ejb osgi 1

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


  • Why ejb osgi 2

    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.


  • Login