modularized middleware architecture for smart home smart home lab
Download
Skip this Video
Download Presentation
Modularized middleware architecture for smart home & smart home lab

Loading in 2 Seconds...

play fullscreen
1 / 14

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


  • 138 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Modularized middleware architecture for smart home & smart home lab' - laksha


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.

ad