ENSURING INTEROPERABILITY IN A HOME NETWORKING SYSYTEM: A CASE STUDY

1
ENSURING INTEROPERABILITY IN A HOME NETWORKING
SYSYTEM A CASE STUDY
2
Outline

• Introduction
• The interworking problem in the home
• European Home Systems
• Communication
• Energy Management System
• Conclusions

3
Introduction

• Definition of home networked systems (HNS)
• Technological factors and market forces
• Under attack from different industries
• A successful HNS
• Several specifications already exist
• CEBus, EHS, EIB, BatiBUS, LonWorks, HBS, X10, etc
• VESA Home Networking Group IEEE P1394
• ATM-based and IP-based home networks

4
Introduction(contd)

• Two problems
• Cost and technology
• Reliable self-configurable application
  integration through interworking/interoperability
  standardization work.
• The ultimate target in the home will be the
  seamless integration of services and applications

5
The interworking problem in the home

• No matter what road the networking technology
  takes and what prevails in the end, the need for
  concerted and standardized work is obvious.
• The more open, the greater benefits.
• The HNSs were concerned initially with the
  specification of the communication system for
  control.
• How to provide for soundest interworking in the
  face of both the evolution of devices in time and
  the existence of numerous devices with very often
  minute functional differences?
• Object-oriented approach to the definition of
  the internetworking standards is accepted as the
  only feasible way to model the HNS applications.

6
The interworking problem in the home(contd)

• Two approaches may be identified in the existing
  definitions of an object model
• One that follows a relatively rigid abstract
  structure, based on multicast communication and
  with explicit non-evolving definition of data
  types.
• One that follows a hierarchical model with
  automatic discovery and trading mechanisms
  leading to component binding(at ad-hoc discovery
  at run-time).
• The issue becomes more influential if the choice
  of the communication model was made to support OO
  language at the application or user level.

7
European Home Systems

• EHS is a European specification for home
  networking systems.
• European Home Systems Association (EHSA)
• EHS exhibits full plug and play characteristic by
  allowing the installation/connection of the
  devices into the system and the discovery of the
  services /devices in the network without (or with
  very minimal) any user intervention.
• EHS uses a client/server architecture.
• The servers in EHS are comparatively simple.

8
European Home Systems (contd)

• The discovery of the services (called trading)
  relies on the multicast communication
• Each server offers its services to the system
  clients establish the application links or
• Each client broadcasts (multicasts) requests for
  particular services.
• The specification distinguishes between logical
  processes and physical units.
• Each process is called a device.
• A server device is called a Complex Device, while
  a client is called Feature Controller.

9
Communication

• EHS follows OSI 7-layer Reference Model, but only
  four of the layers are actually specified, namely
  the Physical Layer, the Data Link, the Network
  Layer, the Application Layer.
• EHS devices can use power line, twisted pair
  media, coaxial cable, or wireless(RF and IR)-
  although only power line and twisted pair media
  are used in practice.
• Network Layer provides packet routing in the
  network.

10
Communication(contd)

• Application Layer is divided into two service
  modules the Message Transfer Service Element and
  the Command Language Service Element (CLSE).
• CLSE is the interface between the underlying
  communication system and the user application,
  which is specified using the EHS Command
  Language(CL).
• EHS is a message-driven system. A client
  activates via a message some services in an
  object residing in the servers, requiring the
  execution of a routine or the value of some data.
  The format of a CL message is

11
Communication(contd)

• The objects are classified into groups
  corresponding to major household activities or
  applications, such as heating, energy management,
  security etc.
• Within the group the hierarchy is flat, with no
  guidelines to further refine existing objects in
  structured way.
• Services are basically remote operation
  procedures like read(RD), write(WRT) etc.
• Objects are built through cooperation of industry
  partners in EHSA IWGs

12
Communication(contd)

• The process of discovering and establishing
  application links between devices is called
  enrolment.
• The main object used in the discovery process is
  the name of a device, which is called device
  descriptor.
• The device discovery process is enriched further
  by providing extended trading mechanisms that
  allow detailed queries to be built during the
  enrolment process.
• A device could be seen as a class or an
  interface.
• Not all of the identified and standardized
  objects will be implemented in a particular
  device/system.
• How will other devices in the HNS get knowledge
  of the capabilities of a device?

13
Energy Management System

• Electricity industry
• Two strategies are followed by the electricity
  utilities to realize energy management Direct
  Load Control (DLC) and Demand Side Management
  (DSM)
• In Europe it is mainly the second method and
  variations that are used. Ex Denmark, France and
  UK, UK.
• The information that utility provide to home
  system is usually in the form of arrays of
  tuplets price, time.

14
Energy Management System (contd)

• The information is distributed by radio broadcast
  (UK), ripple control (France), public paging
  system (Denmark), or PSTN (UK, Denmark)
• This information is to be used by the home system
  in any of the following ways

15
Energy Management System (contd)

• The objectives of the interoperability
  specification in ETHOS includes
• Make manufacturers interested in including energy
  management functionality.
• Products from different manufacturers should work
  together in the same AP.
• The products should not interfere with products
  for a different application.
• The manufacturers should be free to compete at
  the level of functionality or features provided
  in their devices.
• Application Environment, Configuration, and
  Device Type Hierarchy.

16
Application Environment

• The main function of the specification is the
  provision of a common resource advice to the
  home system (heating system and domestic
  appliances) to use the given resources.
• The common refers to its being the same device,
  with the same interface, independent of the
  country of deployment, utility policy, utility
  communication methods.
• The generic application is based on the
  assumption that the utility/supplier transmits at
  regular intervals a tariff profile to the
  customers premises.
• The utility/suppliers may as well provide
  resource management advice.

17
Configuration

• The entities participating in the application are
  suppliers, users, and home system components.
• ETHOS System Architecture

18
Configuration (contd)

• The configuration consists of meter, utility
  interface, and other components.
• Meters provide the system with information about
  consumption, its rate, and possible warnings to
  the system that it is overusing the resources.
• Utility interface(UIF) provides the
  interpretation of the tariff and cost-related
  information sent by the utility / supplier to
  commonly understood values for the in-house
  system.
• Other components uses the information provided by
  the meter and the UIF devices.

19
Configuration (contd)

• The main information is the Advise Profile build
  by the utility interface based on the
  price/indicative cost/indicative price
  information provided by the supplier(s).
• Information model

20
Device Type Hierarchy

• The requirement is to allow home appliances from
  the different manufacturers that implement energy
  management services to be able to operate across
  different countries, and transparent to the
  possible change of the electricity supplier or
  the contract.
• The first step is the adoption of the Advice
  Profile.
• But still the differences between the countries
  and/or suppliers operating in these countries are
  such that the utility gateway interface will
  different.
• The solution adopted in this case is the
  definition of a type hierarchy of devices that
  implement the defined functionality.

21
Device Type Hierarchy(contd)

• A definite data structure is associated with each
  of the services supported.

22
Device Type Hierarchy(contd)

• The problem of having several objects identified
  as optional could be solved in two ways
• An application management mechanism is defined
  that allows for testing the presence or not of a
  particular object from the general pool of
  objects identified in the Basic, Rate and Flow
  Meter types.
• A difference device descriptor is assigned to
  different device subtypes.

23
Colusions

• In the HNS it is made more difficult owing to the
  existence in and around the home of a large
  number of entities with very different
  capabilities in minute features.
• One approach to solve this problem is the use of
  object-oriented modeling to build a device type
  hierarchy.
• A successful field trial in four countries in
  Europe.