WO2005117389A1

WO2005117389A1 - Device abstraction layer for local networking system

Info

Publication number: WO2005117389A1
Application number: PCT/IB2005/051670
Authority: WO
Inventors: Anthony Adamson; Douglas R. Hoskins; Robin J. Blackwell; Philip A. Rudland
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2004-05-24
Filing date: 2005-05-23
Publication date: 2005-12-08
Also published as: KR20070033338A; RU2006145862A; JP2008501202A; MXPA06013703A; GB0411528D0; CN1957583A; EP1757060A1; BRPI0511455A; WO2005117389A8; TW200616398A

Abstract

A local networking system comprises a processing platform (110) and target devices (151-153), such as home appliances. The platform supports an open services gateway framework, such as that of the Open Services Gateway Initiative (OSGi), and executes applications (130) to control the target devices (151-153). The target devices are each represented by an entity (133) which can be manipulated by the application (130) across an application programming interface (API, 134). The entities follow a common hierarchical structure of device types, in which an entity representing a device type lower in the hierarchy inherits the properties of device types higher in the hierarchy. This presents a consistent API to applications. The entities can form part of an abstraction layer which uses a common language, such as the Home Uniform Control Language (HUCL). Each entity can be registered with the framework as a device service or a single device service (146) can be registered with the framework which represents multiple entities (147).

Description

DESCRIPTION

DEVICE ABSTRACTION LAYER FOR LOCAL NETWORKING SYSTEM This invention relates to a local networking system, to a platform for use in the system and to instructions which operate the platform.

There is considerable interest in networking appliances within the home environment and a variety of networking protocols have been developed in recent years. The Universal Plug and Play Protocol (UPnP) has mainly been adopted for personal computer peripherals, and audio visual (AV) extensions to the protocol allow AV devices such as media severs and media players to determine what content is available on similar devices and to control the transfer of that content between devices. UPnP is regarded as a fairly 'heavyweight' protocol which can make considerable demands of a host device, including processing power and power consumption. Consequently, it is not ideally suited to use in low (battery) powered equipment which has limited resources and which would otherwise require only minimal processing capability. Other protocols, such as the European Home Systems (EHS) protocol, ZigBee and X10 have each been used for controlling home appliances. A home network is likely to include a diverse range of equipment, which will vary from a personal computer and media players with powerful processing capabilities, to simple devices which only require simple on/off instructions, such as small appliances, thermostats and light switches. The Open Services Gateway Initiative (OSGi) is an open, managed framework that aims to allow applications (or 'services') to be deployed, installed and run in local networks such as homes, cars and small offices. The heart of the local network is a gateway, which supports an OSGi Service Platform which executes the OSGi framework. The latest published version of the OSGi Service Platform Specification is version 3, March 2003 from The OSGi Alliance' and more information about OSGi can be found at www.osgi.org. Part of the Service Platform specification covers the access of devices connected to the service platform. The Specification introduces two types of entities to achieve this: 'device' entities, which represent concepts such as 'printer', 'mouse', 'lamp' etc. and 'driver' entities, which represent concepts such as 'USB', 'Serial', etc. For example, to represent a 'USB Mouse' the OSGi Driver Selector entity would select a suitable device and driver and put these together. In order to be open and extensible, OSGi has not defined a common interface to these device entities from the application nor a common interface between device and driver entities. This has resulted in companies developing their own proprietary Application Programming Interfaces (APIs), which reduces the openness of the specification. Figure 1 shows a simplified model of the existing OSGi Device Access Specification. An application 10 represents software that implements a particular service. In this simple case, the application 10 controls two lamps 20, 30 within the home, turning them on and off at particular times of the day. The first lamp 20 that needs to be controlled operates according to the European Home Systems (EHS) protocol. The second lamp 30 that needs to be controlled operates according to the ZigBee protocol. Both EHS and ZigBee are existing protocols for home networking. Base drivers 22, 32 for each respective lamp 20, 30 discover new hardware and register a corresponding 'device service' 25, 35 with the OSGi framework. Each device service 25, 35 is a software representation of the actual hardware device 20, 30 that is to be controlled. Application 10 must know about each possible lamp device 25, 35 that it interacts with, and must know the details of each API 26, 36 that interfaces the application 10 with the device service 25, 35. An EHS representation 25 of a lamp device is very different from a ZigBee representation 35 of a lamp device. Consequently, application 10 becomes a complex piece of software, even for simple applications. Furthermore, because the device services are not standardised, a different vendor is free to represent the same hardware device (e.g. lamp 20) in a different way, using a different driver 21 and device service representation 25. Considering an example where a second application 11 is supplied by a different vendor, but also needs to turn lamp 20 on and off, the developer of the second application 11 must either know the details of the API 26 or must provide their own device and driver which can control the lamp 20. The present invention seeks to provide an improved interface within a local networking architecture, such as the OSGi framework.

Accordingly, a first aspect of the present invention provides a platform for use in controlling target devices in a local network, comprising a processor which supports an open services gateway framework, and which can execute at least one application to control the target devices, wherein each of the target devices are represented by an entity which can be manipulated by the application across an application programming interface (API), the entities following a common hierarchical structure of device types, in which an entity representing a device type lower in the hierarchy inherits the properties of device types higher in the hierarchy, whereby to present a consistent API to applications. The open services gateway framework is preferably, although not limited to, the Open Services Gateway Initiative (OSGi) framework. The use of entities with a consistent hierarchical structure allows applications to communicate in a simplified, yet powerful, manner with target devices. The entities form part of an abstraction layer which abstracts away from each device-specific and network-specific API, and which preferably uses a common language. Preferably, the hierarchical structure is provided as part of a lightweight protocol, such as the Home Uniform Control Language (HUCL). This allows application developers to access each device service, and hence target device, on the system in a standard and user-friendly way. Developers can independently write applications with the certainty that they can be reliably used with target devices within the OSGi framework. In addition, the interface between the 'HUCL driver' and 'HUCL device service' objects on the system is standardised, now using a common HUCL interface across all pairings. This allows a simple application to control target devices, which are connected to the platform by different networking protocols, based on a single device service. New target devices can be added, using new protocols, while still using existing service applications. HUCL can be used as a common language between all of the device services and bridging drivers, which interface to local networking protocols that connect to the target devices. Other advantages of using HUCL are the lightweight nature of the protocol, which makes low demands on host equipment. HUCL can use compressed XML messages, and provides a basic and extended description, which can reduce messaging overheads. The main features of HUCL are described in International patent applications: WO 2004/015926, WO 2004/015927, WO 2004/015928 and WO 2004/015929. HUCL was originally developed as a lightweight protocol for controlling devices, but it has been realised that HUCL can also provide an ideal protocol for use within an OSGi gateway. HUCL, together with the lower level Base Drivers, gives both network independence (a common language) and protocol independence (standardised device commands within that language, including command sets, parameters, functionality, etc). Other protocols lack the capability for bridging, supporting composite devices, the ability to support more than one layer of sub-devices or the open specification provided afforded by HUCL and thus are unsuitable for use as an abstraction layer. Applications communicate via the target device's 'device service', which is specific to the device type of the target device, and which is obtained from the HUCL Bundle in a similar way to that used for UPnP in OSGi. These device services might be seen as 'helper bundles', as they present a device- specific Java interface to the application, but may communicate with the lower level drivers using XML, or compressed XML, messages. If the target device uses a protocol which is not HUCL, e.g. UPnP, X10 or ZigBee, HUCL Drivers

(bridging drivers) convert from HUCL to the protocol used by the target device. Two main methods of handling device services are proposed. In the first method, each target device is represented by a HUCL device service which is registered with the OSGi framework. The device services have a hierarchical structure of device types which follows the target devices, and functionalities of the target devices, that they represent. One preferred way of achieving the hierarchical structure is by using a hierarchical Java class structure where lower-level Java classes inherit the properties of higher-level classes from which they depend. However, as described more fully in the detailed description below, there are other ways of achieving this hierarchical functionality. In the second method, a single device service is registered with the OSGi framework, and the device service is a HUCL composite device which is capable of representing a large number of sub-devices. Each sub- device is referenced by an identifier and includes a HUCL equivalent version of the device service used in the first method, which follows the same hierarchical structure of device types and functionalities. The second method has the benefit of reducing the number of entities that need to be registered and tracked by the OSGi framework. Although an entity, or device service, usually maps to an individual hardware target device, the OSGi specification notes that it is not limited to this. This invention is applicable to any platform that implements an OSGi framework and controls target devices. This includes residential gateways, set top boxes, PCs, personal digital assistants (PDAs), media servers and other consumer electronic or medical devices. The functionality described here can be implemented in software, hardware or a combination of these. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. Accordingly, another aspect of the invention provides instructions for a platform which controls target devices in a local network, the instructions causing a processor of the platform to support an open services gateway framework, and to execute at least one application to control the target devices, wherein each target device is represented by an entity which can be manipulated by the application across an application programming interface (API), the entities following a common hierarchical structure of device types, in which an entity representing a device type lower in the hierarchy inherits the properties of device types higher in the hierarchy, whereby to present a consistent API to applications. It will be appreciated that the software may be installed on the gateway at any point during the life of the equipment. The software may be stored on an electronic memory device, hard disk, optical disk or other machine-readable storage medium. The software may be delivered as a computer program product on a machine-readable carrier or it may be downloaded directly to the platform via a network connection. A further aspect of the invention provides a library of entities for use with a platform which supports an open services gateway framework, and which can execute at least one application to control the target devices in a local network, each entity representing a target device in the network and being manipulable by an application across an application programming interface (API), and wherein the entities following a common hierarchical structure of device types, in which an entity representing a device type lower in the hierarchy inherits the properties of device types higher in the hierarchy, whereby to present a consistent API to applications. The library can be hosted by the gateway or by a remote server which is accessible by the platform. Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:- Figure 1 shows an example scenario of controlling a lamp using a conventional OSGi framework; Figure 2 shows an overall model for an OSGi residential gateway; Figure 3 shows an OSGi framework in accordance with an embodiment of the present invention; Figure 4 shows the same scenario as Figure 1 implemented on the framework of Figure 3; Figures 5A and 5B show two ways of implementing the framework of Figure 3; Figures 6A and 6B show message flows which occur when a new target device joins the network; Figures 7A and 7B show message flows which occur when an existing target device is removed from the network; Figures 8A and 8B show message flows which occur when an application controls a target device; Figures 9A and 9B show examples of a hierarchy of device services used within the framework; Figure 10 shows a mechanism for notifying applications of events within target devices; and Figure 11 shows an example of a platform which can implement the framework of Figure 3.

Figure 2 shows a simplified overall model for an Open Services Gateway Initiative (OSGi) residential gateway. A service gateway 110 is located within a home, office, car or similar. The service gateway 110 includes a service platform 112 which supports the OSGi framework. Applications 130, which provide various services within the home, are executed by the platform 112 to control target devices 20-23. Applications can have a variety of purposes, including control of appliances, such as consumer electronics, white goods, heating and ventilation, lighting etc. The target devices 20-23 can include lamps 20, electrical appliances 21 , or any other electrical devices. The gateway 110 connects to the target devices 20-23 using local networking protocols. A typical home will include target devices which operate according to a range of target network protocols, such as ZigBee, X10, UPnP, EHS, KNX and Echelon. The physical network layer to each hardware device may be wireless (e.g. IEEE 802.15.4 in the case of ZigBee, IEEE 802.11 or similar) or wired (e.g. serial bus, Ethernet cabling, electrical cabling (X10)). In Figure 2, network 40 is a ZigBee network and network 45 is an X10 network. A remote server 50, outside of the home, can communicate with the gateway 110. Services may be delivered to the gateway by the server 50 or, in some circumstances, applications 120 on server 50 can control target devices 20-23 within the home. The remote server can also be used for network management and to provide new services or updated services to the gateway 110. Figure 3 shows the general architecture of an OSGi gateway 110. A Service Platform 112 supports an OSGi framework, which is typically provided by software executed by a processor within the gateway. Applications which control target devices in the network can either be executed remotely on server 50 (application 120), or locally on the Service Platform 112 (application 130). In accordance with an embodiment of the invention, the Home Uniform Control Language (HUCL) is used as an abstraction layer within the OSGi framework supported by the service platform 112. Each target device 151-153 which exists in the local network is represented by a 'device service' 133. This is a representation, in software, of the actual physical device 151-153. A full device service includes the following information: - Basic information for interacting with a device, including the HUCL version and minimum supported HUCL version; - Basic information for identifying a device including: a device type list (a list of HUCL device type codes, each standardised to represent a specified device type, e.g. a lamp), a similar list of device types this device can control; - various extended data, e.g. device name, location string, manufacturer, model name, serial number, Ul URL (user interface URL); - functionality to send commands to the target device, and to receive responses and events.

Additionally, a composite device, which can represent multiple target devices, includes references to the sub-devices it represents. In contrast to the devices 25, 35 used in Figure 1 , device services 133 have a hierarchical structure. This allows applications 130 to control target devices to as great an extent as possible, as will be explained below. Types of target devices (appliances) such as a lamp, television, fridge etc. each have a standardised device service 133. The API which allows an application 130 to communicate with each device service 133 is well-defined, and no longer something that is proprietary. This allows applications 130 to communicate with the device services 133 in a simple, standardised manner. One way of achieving the hierarchical structure is by using a standardised set of Java™ objects or another programming language which provides a hierarchy of class types although other methods can be used. Applications 120, 130 running within the OSGi framework do not need to know what type of networking protocol (e.g. UPnP, ZigBee) is used by their target devices, which considerably simplifies the application. Multiple applications can use the same device services 133 and APIs. A HUCL bundle 140 connects the drivers 141 , 142, 143, registers device services 133 with the OSGi framework and provides general management features, such as a HUCL Messaging System. The drivers 141 , 143 for ZigBee and UPnP are each shown as a single entity. However, they can be split in the same manner as is shown for the drivers for X10, with a base driver 163 and a refinement driver 142, which uses some of the functionality of the base driver 163. It is possible to minimise the role of the central management entity by allowing the device services 133 to register themselves with the OSGi framework, manage event subscriptions (described more fully below) and to pass HUCL messages to the drivers, and allowing the drivers to perform all of the translations to protocols used by target networks. In this case, the main tasks of the HUCL bundle 140 are: - central management - store version ID, etc. - track drivers and device services (such as by using the OSGi framework's relevant subscription mechanisms); - register device services (for each device service in Fig 5A; in Fig.5B a device service can be registered only for composite devices); - engage in OSGi driver locator interactions (or network interactions for a HUCL driver acting as a low level base driver); - manage event subscriptions (so as to be able to send events as required); - communicate using HUCL; - perform protocol translations (between HUCL and target network protocol); - marshall/unmarshall HUCL message strings from/to a programmer-friendly Java API. Drivers 141 , 142, 143 manage target devices on the target networks and present them as HUCL device services 133 within the OSGi framework. This allows device services 133 to communicate with the drivers 141 , 142, 143 across a standardised HUCL interface. Drivers 141 , 142, 143 can be written in Java, native code, or can be written in a mixture of Java and native code. Where a target network driver exists, a HUCL bridge driver converts to the standard HUCL API so that other networks can use HUCL too. Figure 4 shows the same scenario as Figure 1 , in a gateway which implements the HUCL abstraction layer. A lamp controlling application 130 turns two lamps 20, 30 on/off at predetermined times. Each lamp 20, 30 is now represented by a common, generic lamp device service 133 which has a standardised API 134. Application 130 can pass instructions to the lamp device 133, via API 134, in the same manner regardless of whether the target hardware device is lamp 20, connected to an EHS network, or lamp 30 connected to a ZigBee network. A HUCL/EHS driver 144 bridges the HUCL layer to a driver for the EHS protocol. Similarly, a HUCL/ZigBee driver 141 bridges the HUCL layer to a driver for the ZigBee protocol. Figures 5A and 5B show the two main options for the HUCL bundle 140. Firstly, in Figure 5A, the HUCL bundle 140 acts as a base driver and registers individual HUCL device services 133, each representing a target device 20, with the OSGi framework. The OSGi framework provides a service repository, i.e. a queryable list of registered device services 133. As an alternative, the HUCL bundle 140 can listen for new devices discovered by the EHS base driver 160, and then translate them to HUCL devices. In this case the HUCL bundle 140 is a refining driver rather than a base driver. All communication across the interface 160 between the HUCL bundle 140 and device services is in the form of API calls, such as SendHUCLMsg() and ReceiveHUCLMsgQ. Application 130 calls functions on the HUCL device service 133, which communicates directly or indirectly with the bridging driver 144. The HUCL Bundle 140 tracks all existing bridging drivers 144. In Figure 5B the HUCL Bundle 140 registers itself as a HUCL device service with the OSGi framework. In this case, the HUCL device service is a HUCL composite device 146. The composite device 146 can represent a large number of device services 147 and this has advantages if there is a large number of target devices 20 on the target network as it uses less system resources. As an example, if there are ten different target devices 20, in the scheme shown in Figure 5A this would require ten device services to be registered with the OSGi framework. In contrast, in the composite device scheme shown in Figure 5B only one composite device 146 is registered with the OSGi framework. The concept of a HUCL composite device is described in International Patent Application WO 2004/015927. This makes the system more scalable as it can more easily cope with a large number of target devices 20. The main components of the API 165 (which is equivalent to API 160 in Figure 5A) between the HUCL bundle 140 and application 130 are the commands SendHUCLMsg() and ReceiveHUCLMsg(). While some additional addressing information is required within these calls to identify which sub- device 147 of the HUCL composite device 146 is identified in each message, the overall volume of messaging is reduced. Other than a few housekeeping commands, these are the only commands required for API 165. The use of a composite device 146 can also allow a simpler interface, either between the gateway 110 and the back-end server 50, or across a Java-Native Interface (JNI). In accordance with a feature of the HUCL protocol, as described in International Patent Application WO 2004/015956, an application 130 can query the composite device 146 for a simple description and an extended description of the device service. Figures 6A-8B show examples of the message flows which occur within the framework of Figure 3 for three typical actions. In each example, the message flows are shown both for the situations where an individual device service is used (as in Figure 5A) and where the general HUCL bundle and composite device 146 are used (as in Figure 5B). For clarity, pseudocode is used in these and subsequent examples. For simplicity, the example shows a lamp 20 as the target device, but it will be appreciated that the target device could be more complex. Figures 6A and 6B show the message flows which occur when a new target device 20 is added to the system. Figure 6A shows the message flows where an individual device service is used. When the new device (lamp 20) is first added to the system, this is recognised by the EHS driver 160 and there is bus activity at step 201. Driver 160 sends a message 202 to the HUCL bundle 140 via the HUCL/EHS driver 144 of the form: eventListener.indicate( EHSDriver, NEW_DEVICE, <type>) At step 203, a new device service 133, representing a lamp, is created with the name 'myHUCLLamp2' and the function: Framework.registerNewDevice(myHUCLLamp2) is called on the OSGi framework to register the new device service 133. The function can be called by the driver 144, the HUCL bundle 140 or by the device service 133 itself. A service tracker within application 130 is notified of the new device service 'myHUCLLamp2' at step 204. The service tracker feature of OSGi is described more fully in the OSGi Service Platform Specification (Chapter 19 of version 3.) Referring back to step 201 , the exact manner in which a new target device joins the system varies according to the target network protocol. In some protocols, a new target device 20 causes a 'new device' event on the bus. In others, new target devices are discovered by a polling mechanism within the target network. For X10 there is no indication of a new device, and it must be added manually to the system by the user. Increasingly, security requirements require a user to be involved in the interaction. For WiFi, once a user enters an encryption key for the new target device, the low-level driver 160 on the gateway identifies the new device, and can request a description. A HUCL/UPnP bridge driver 143 will recognise this and the new device identification continues up the stack. Figure 6B shows the message flows where the general HUCL bundle and composite device 146 are used. When the new device (lamp 20) is first added to the system, this is recognised by the EHS driver 160 and there is bus activity at step 211. As before, driver 160 sends a message 212 to the HUCL bundle 140 via the HUCL/EHS driver 144 of the form: eventListener.indicate( EHSDriver, NEW_DEVICE, <type>) However, in this case the new device is represented as a sub-device within a HUCL composite device 146. The information stored for the sub-device is a HUCL equivalent of the information that is stored for a service device, as previously described, and includes a list of device types in the hierarchy above the actual device. All applications 130 which are subscribed as listeners of the HUCL bundle are sent a message 213: HUCLEvent("<deviceDescriptionChanged>") Application 130 is subscribed as a listener of the HUCL bundle 140. The event listener within Application 130 is notified, at step 214, of the update to the HUCL bundle 140 and discovers the newly added sub-device. The newly added sub-device is not explicitly registered with the OSGi framework. Figures 7A and 7B show the message flows which occur when an existing device is removed from the system. Figure 7A shows the message flows where an individual device service 133 is used. When the existing device (lamp 20) is removed from the system, this is recognised by the EHS driver 160 and there is bus activity at step 221. Driver 160 sends a message 222 to the HUCL bundle 140 via the HUCL/EHS driver 144 of the form: eventListener.indicate( EHSDriver, GONE_.DEVICE, ID) At step 223, the 'myHUCLLamp2' device service is stopped. The service tracker of application 130 is notified of the removal of device service 'myHUCLLamp2' at step 224. Figure 7B now shows the message flows where the general HUCL bundle is used. When the existing device (lamp 20) is removed from the system, this is recognised by the EHS driver 160 and there is bus activity at step 231. Again, driver 160 sends a message 232 to the HUCL bundle 140 via the HUCL/EHS driver 144 of the form: eventListener.indicate( EHSDriver, GONE_DEVICE, ID) The sub-device representing the lamp is removed from the HUCL composite device 146 at step 233. A message of the form: HUCLEvent("<deviceDescriptionChanged>") is sent to all subscribed listeners, notifying them of the removal. At step 234 the event listener of application 130 is notified of the update and discovers the sub-device that has been removed. Again, the OSGi framework is not explicitly notified of the removal. It is preferred that a user confirms the removal of a device, such as by clicking a confirmation icon on a user interface. In the third example, Figures 8A and 8B show the message flows which occur when an application 130 wishes to control a device that is already registered with the system. In this example application 130 sends a control message to turn lamp 20 on and lamp 20 is registered with the system with the name 'myHUCLLamp'. Figure 8A shows the message flows where an individual device service 133 is used. Firstly, application 130 sends a message, at step 241 , to the HUCL lamp device service 133 of the form: myHUCLLamp.on() At step 242 the lamp device service 133 sends a HUCL message of the form: sendHUCLMsgC'... <param 1 >255</param 1 >...") This is translated by the HUCL/EHS driver 144 into a message, which is sent 243 to driver 160, of the form: EHSDev5.sendEHSMsg( TURN_ON) The translation may simply be a trivial reformatting of the message, or it may involve translating commands by use of a look-up table. Finally, driver 160 issues a message 244 in the format of the target network to lamp 20 which causes lamp 20 to turn on. Figure 8B shows the message flows where a general HUCL bundle 140 is used. Firstly, application 130 sends a message, at step 251 , to the HUCL bundle 140 of the form: sendHUCLMsgAddressedTo(DevlD, "... <param 1 >255</param 1 >...") This is delivered to the particular sub-device 147 of the composite device service 146, where 'DevlD' is an identifier which identifies the sub-device 147 of the HUCL composite device 146 representing lamp 20. HUCL bundle 140 issues a control message which is translated by the HUCL/EHS driver 144 into an EHS message, at step 252, of the form: EHSDev5.sendEHSMsg(TURN_ON)

This message is delivered to the EHS Driver 160. Finally, driver 160 issues a message 253 in the format of the target network to lamp 20 which causes lamp 20 to turn on. Referring back to Figure 5A, the messages passed between application 130 and the HUCL device objects, across API 134, are standardised, such as LampOnO, LampOff(), TVOn(), TVOff(), SetChannel(int num), SetVolume(int level). Developers of applications 130 will be provided with a standard set of these. As described above, HUCL has a hierarchical arrangement of device services. Figure 9A shows an example hierarchy of device services 300, with a general HUCL device 301 at the top. The function 'getSubDevices()' returns the device service of the next layer of sub-devices, if any are present. Moving down the hierarchy, device services have an increased level of detail/functionality. Thus, device service 302 represents a target device which has the ability to turn on/off. Moving down the left-hand side of the hierarchy, device service 303 defines a basic lamp, which inherits the feature of the class above it, i.e. it can also turn on/off. Device service 304 defines a dimmable lamp, i.e. a lamp with the function of being set to a particular brightness value within a range of possible values. Device service 304 also inherits the features of 302 and 303 above it, i.e. it is a lamp and it can turn on/off. Moving down the right hand side of the hierarchy, device service 305 defines a door bell which inherits the features of a HUCL on/off device 302. In this example, if an application (e.g. application 130) does not know how to talk to a device of the type "HUCLDimmableLamp", it can still use the "HUCLBasicLamp" definition or even the basic "HUCLDevice" definition with the certainty that the device service will understand that functionality. Effectively, HUCL allows an application to 'walk up the hierarchy tree', and if an application finds that it does not recognise a device type (e.g. dimmable-lamp) then it checks the other device types listed in the device type list provided as part of the device service 133. Similarly, an application which has the ability to turn something on/off can drive a lamp, door bell or any other type of device which is capable of being turned on/off since the device services representing all target devices will follow the hierarchy. A target device is represented at every level above its 'lowest', most accurate representation. This approach allows devices to be manipulated to the fullest extent possible, even in situations where the developer does not know the full details of a particular device. Figure 9B shows a further example of a hierarchy. A platform - in this case a personal digital assistant (PDA) 320 - supports the OSGi framework described above and a control application. The application running on the PDA 320 is unable to recognise the specific commands used by the dimmable lamp 304 or the lamp 303, but it recognises the device type code for an OnOffDevice (i.e. a code representing a type of device which can be turned on/off), and thus it is able to control the lamp to a useful extent, even though it cannot control the dimmable function of lamp 304. Similarly, the application running on the PDA 320 only supports device services to the level of 'thermostat' 308 and lacks the ability to control features of a medical or industrial thermostat. The application running on PDA 320 cannot use the advanced features of the medical thermostat 309 or industrial thermostat 310, but it can still turn each of the thermostats 357, 358 on and off and obtain basic temperature readings. This allows manufacturers of target devices to provide products which will interoperate to a certain level, but also to add unique features to their products which will differentiate them from other products. In the composite device model previously described with reference to Figure 5B, the information stored for each sub-device 147 within the composite device 146 follows this same hierarchical structure. As described above, many programming languages offer related functionality. For instance, in Java™ every object is an instantiation of a 'class', and classes can extend other classes, forming a class hierarchy. The hierarchy shown in Figures 9A and 9B can be implemented using this class hierarchy of a set of objects in Java or another programming language. Alternatively, the hierarchy can be implemented in a way which does not use the 'built in' class hierarchy of the programming language. One method of operating a device hierarchy without using the class hierarchies of the programming language in which it is implemented is to represent devices by instantiations of a single fixed class, perhaps called HUCLDevice, this having only generic, non-device-specific methods such as "sendMessage (commandText)", "setVariable (variablelD, variableValue)" or "invokeCommand (commandlD, commandParameterl , ...)". In this case the hierarchy is documented on paper, and is implemented in the programming of the software components, either by coding the response to each individual invocation (i.e. non-object-oriented code), or by an object-oriented design of non-exposed APIs (i.e. using object-oriented code but not representing this in the API). In each case we can expect extended devices to react correctly to all of the messages, variables and/or command invocations understood by the simpler devices, and also to understand and implement responses to some additional commands and functionality. In this second situation the device hierarchy still exists (at the very least conceptually) and is useful, but it is not directly implemented by using the programming language's built in class hierarchy. As an example, consider a basic lamp that supports the functions On() and Off(), and a ComplexLamp that also supports the function Dim(). In non- object oriented code we might implement this using a switch statement. There follows example pseudocode for the HUCLdevice software for a basic lamp: #include <lamp.h> // contains #defines for CMD_LAMP_*, and declares functions On( ) and Off( ). invokeCommand( commandlD, commandParamList[ ] ) { switch( commandlD ) { case CMD_LAMP_ON: On(); break; case CMD_LAMP_OFF: Off(); break; default: UnknownCommand( commandlD, commandParamList[ ]); } }

The pseudocode for the HUCLdevice software for a complex lamp is: #include <lamp.h> // contains #defines for CMD_LAMP_*, and declares functions On( ) and Off( ). #include <complexLamp.h> // contains #defines for

CMD_COMPLEX_LAMP_*, and declares the function Dim( ). invokeCommand( commandlD, commandParamList[ ] ) { switch( commandlD ) { case CMD_LAMP_ON: On( ); break; case CMD LAMP_OFF: Off( ); break; case CMD_COMPLEX_LAMP_DIM: Dim( commandParamList[0] ); break; default: UnknownCommand( commandlD, commandParamList[ ]);

}

Here the code for 'ComplexLamp' implements all of the functionality of the 'lamp', and also the additional command as defined in the ComplexLamp specification. Both programs will also implement functions On( ), Off( ) and UnknownCommand( ... ), and the ComplexLamp will additionally implement a function Dim ( dimLevel ). This example implements a device hierarchy without using the class hierarchy of the programming language. It is also possible to implement the hierarchy in this second way, but with some object- oriented programming features. Example pseudocode for the HUCLdevice software for a complex lamp is: #include <lamp.h> // contains #defines for CMD_LAMP_^*, and declares the Lamp class. #include <complexLamp.h> // contains #defines for

CMD_COMPLEX_LAMP_*, and declares the ComplexLamp class, which extends the Lamp class. invokeCommand( commandlD, commandParamList[ ] ) { ComplexLamp myComplexLamp = environment.getTargetDevice( ); switch( commandlD ) { case CMD_LAMP_ON: myComplexLamp. On( ); break; case CMD_LAMP_OFF: myComplexLamp. Off( ); break; case CMD_COMPLEX_LAMP_DIM: myComplexLamp. Dim( commandParamϋst[0] ); break; default: UnknownCommand( commandlD, commandParamList[ ]); } } Here the API presented to applications is the same as the previous example, and still does not directly use the class hierarchy of the programming language. However, in this example the classes ComplexLamp and Lamp have been used within the pseudocode for a complex lamp to make the software clearer, or more maintainable. Target devices are controlled in a manner that conceals any low-level HUCL code from the developer. In the model of Figure 5A, the device service classes themselves take responsibility for translating the high-level method calls (e.g. LampOn(), SetChannel(int num)) into low-level HUCL code, while in Figure 5B wrapper functions 162 may be used. Wrapper functions perform the translation of developer-friendly, high-level, Java commands into lower-level HUCL codes. In Figures 8A and 8B it was shown how an application 130 can issue a control message to control a target device 20. This could arise where an application is required to turn a target device on/off at times known to application 130. However, there are situations where it is desirable for an application to respond to a particular event which occurs at a target device. As an example, when a target device, in the form of a movement sensor, detects movement within a room, it is desirable to inform a security application running on the gateway 110, so that the application can alert a user. The existing OSGi framework does not provide a mechanism to support this type of notification. Figure 10 shows a simple mechanism for alerting applications of events. At the lowest level, a driver 160 polls a target device 20 on a periodic basis, such as every couple of seconds. If there is a change in the status of the target device 20, the driver 160 notifies the device service 133. It is possible from the driver's API to detect any changes in status. This can be achieved by means of a method call from the driver 160 to the HUCL bundle 140, or by means of the HUCL bundle 140 polling the driver 160 to observe its status. The HUCL bundle 140 forms the information gained from the driver 160 into a HUCL event message. These events are then passed to the device service 133, which formulates them into Java event objects. Applications 130 subscribe to those device bundles that they control, or that they are interested in being informed the status of. Each device service 133 maintains a listening subscription list 180, listing those applications that have registered an interest (adding each to a java.util.Vector as it registers, for instance). Each application 130 includes an event listener 182 for receiving notifications of events. The message, sent by driver 160, indicating the new status of the lamp is received by the device service 133. The device service 133 decides 183 whether a reportable event has occurred and, if so, notifies all interested applications that are registered 180. An example of using this mechanism will now be described for a target device which is a dimmable lamp. According to the hierarchy shown in Figure 9A, a DimmableLamp device 304 extends the functionality of a HUCL Basic Lamp device 303 and an OnOffDevice 302. It is therefore preferred that the event hierarchy mirrors this object hierarchy. This means that applications that are subscribed to a DimmableLamp device service also receive notifications of any on/off events. For a more complex target device, which is represented by a device service that inherits the events of many higher level classes, an application would receive notifications of all of the events inherited by that device service. As with the hierarchical device service structure, this provides a simple yet powerful tool for application developers. The Appendix includes further details of code for implementing the event hierarchy in this example. As described above, the HUCL Management entity is responsible for registering drivers and device services. The OSGi Framework provides a mechanism for notifying any interested bundles of the arrival of any new device services on the system. By providing a HUCL Management bundle on the system this can listen for the arrival of any new device services, and add them to a collection of device services if they represent HUCL devices. This bundle then provides access to this collection to any other bundle interested in using these device services.

HUCLDevice[] devices = huclBundle.getDevices(); for (int a=0; a<devices. length; a++) { if (devices[a] instanceof HUCLLamp) { HUCLLamp lamp = (HUCLLamp) devices[a]; lamp.turnOn(); } else if (devices[a] instanceof HUCLDoorbell) { HUCLDoorbell bell = (HUCLDoorbell) devices[a]; bell.activate(); } } The above code snippet shows how bundles interested in using these device services could then obtain a list of all device services from the HUCL Management bundle. Device services can be queried for the HUCL device interfaces that they implement, and can be used accordingly. This code is an illustration of how a developer uses polymorphism to discover whether he is interested in a device. In this example, the developer is interested in HUCLLamp and HUCLDoorbell. The 'instanceof operator is used to see whether the current HUCLDevice is an 'instance of a device of interest. If it is, the HUCLDevice is cast to the class of the discovered device. The cast object can now be used to control the device. The gateway described above can be implemented on a variety of processing platforms, such as a general purpose PC or a dedicated processing unit. Figure 11 shows the main components of the processing platform. A central processing unit 401 executes software, as previously described, to support the OSGi framework, applications and the HUCL abstraction layer. Typically, the central processing unit 401 has a native operating system (e.g. based on Linux) which supports a Java Virtual Machine (JVM). The JVM hosts the OSGi framework and applications. Non-volatile memory 402 and volatile memory 403, such as a hard disk, store the operating software and libraries of device services and are used by the processing unit 401. A modem 406, such as a broadband ADSL or cable modem, connect to a communication line 407 which joins the gateway to a remote server (50, Figure 2) on which applications may also be supported. The broadband modem 406 may be external to the gateway 110. Control messages to/from controlled devices are carried by local network connections 415, which use a combination of wired 412 and wireless 411 technologies. Appropriate hardware may be provided to support the particular local network such as: a local area network card; a wireless, infrared or power line (X10) modem. User inputs can be provided directly to the gateway by input devices 410 such as a keypad, keyboard, mouse or tablet. Alternatively, user inputs may be received from a remote control unit which is locally networked with the gateway 110, or from the communication link 407. As an example, if a user is away from their home and wishes to send instructions to the gateway to control appliances within the home, a user will interact with a remote terminal and send instructions, via line 407, to the gateway 110. An output may be directly presented to a user via a display driver 408 and display 409, to a local remote control unit or to a remote terminal via link 407. A bus 405, or combination of buses of different types, connect the above units. A wide variety of applications 130 can be executed on the gateway 110, or on a remote server 50. Examples of these include: home control, such as simulating occupancy of a building by turning lamps on and off at predetermined times, control of heating and ventilation, programming a video recorder; control of entertainment and consumer electronics devices; remote monitoring of security of a building or the health of an occupant of a building; remote fault reporting/diagnosis. It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The words "comprising" and "including" do not exclude the presence of other elements or steps than those listed in the claim. In the description above, and with reference to the Figures, there is described a local networking system which comprises a processing platform (110) and target devices (151-153), such as home appliances. The platform supports an open services gateway framework, such as that of the Open Services Gateway Initiative (OSGi), and executes applications (130) to control the target devices (151-153). The target devices are each represented by an entity (133) which can be manipulated by the application (130) across an application programming interface (API, 134). The entities follow a common hierarchical structure of device types, in which an entity representing a device type lower in the hierarchy inherits the properties of device types higher in the hierarchy. This presents a consistent API to applications. The entities can form part of an abstraction layer which uses a common language, such as the Home Uniform Control Language (HUCL). Each entity can be registered with the framework as a device service or a single device service can be registered with the framework which represents multiple entities.

APPENDIX

Further explanatory material for the event reporting feature.

The base event class could be:

public class OnOffDeviceEvent extends Java. util.EventObject { /* Used by getEventTrigger(), indicates a Device ON event */ static int DEVICE_ON;

/* Used by getEventTrigger(), indicates a Device OFF event */ static int DEVICE_OFF;

/^* Returns one of the event constants, explaining what triggered this event */ public int getEventTrigger();

/^* Creates a new OnOffDeviceEvent */ public OnOffDeviceEvent(int trigger); }

A DimmableLampEvent, which will notify subscribed applications of events on the DimmableLamp device can be specified by a class:

public class DimmableLampEvent extends OnOffDeviceEvent { static int BRIGHTNESS_CHANGED;

/* Overridden from OnOffDeviceEvent ^*/ public int getEventTrigger();

public DimmableLampEvent(int trigger); } Applications register their interest in these events by implementing suitable Event Listener interfaces. An example of such an interface for an OnOffDevice is: public interface OnOffDeviceListener extends EventListener { public void onOffDeviceEventOccurred(OnOffDeviceEvent e); }

Claims

1. A platform (110) for use in controlling target devices (151-153) in a local network, comprising a processor (401) which supports an open services gateway framework, and which can execute at least one application (130) to control the target devices, wherein each of the target devices (151- 153) are represented by an entity (133) which can be manipulated by the application across an application programming interface (API), the entities (133) following a common hierarchical structure of device types, in which an entity (133) representing a device type lower in the hierarchy inherits the properties of device types higher in the hierarchy, whereby to present a consistent API to applications (130).

2. A platform according to claim 1 wherein the entities (130) form part of a device abstraction layer which uses a common language.

3. A platform according to claim 2 wherein the abstraction layer further comprises bridging drivers (141-143) which translate messages between the common language and a protocol which is used to interface with the target devices (151-153).

4. A platform according to claim 2 or 3 wherein the common language is the Home Uniform Control Language (HUCL).

5. A platform according to any one of the preceding claims wherein an entity (133) which represents a target device is registered with the framework as a device service.

6. A platform according to any one of the preceding claims wherein a device service (146) is registered with the framework which is capable of representing a plurality of target devices, each target device being represented by an individual entity within the device service.

7. A platform according to claim 6 wherein the device service comprises a HUCL composite device (146), each target device being represented by an entity which is a sub-device (147) of the composite device (146).

8. A platform according to claim 6 or 7 wherein an API (165) between the device service and an application comprises a command to send a message to the device service and a command to receive a message from the device service.

9. A platform according to any one of claims 6 to 8 wherein a wrapper function (162) is provided at an application (130) to translate high- level commands into lower-level messages used across the API (165).

10. A platform according to any one of the preceding claims wherein if an application (130) determines that it is not able to control a target device at a particular level of the hierarchy of device types, it finds a lower level of the hierarchy at which it is able to control the target device.

11. A platform according to claim 10 wherein the entity (133) includes a list of device types higher in the hierarchy whose properties have been inherited.

12. A platform according to claim 10 wherein the application (130) determines the lower level of the hierarchy at which it is able to control the target device by using knowledge of the hierarchy of device types.

13. A platform according to any one of the preceding claims wherein entities (133) are arranged to notify the application of the occurrence of an event at a target device.

14. A platform according to claim 13 wherein an entity (133) maintains a list of applications (130) that wish to be notified of the occurrence of an event and informs those applications when the event occurs.

15. A platform according to claim 13 or 14 wherein the entities (133) have a consistent hierarchical structure of event notification, with entities inheriting the events of higher members of the structure.

16. A platform according to any one of the preceding claims in the form of a residential gateway.

17. A residential gateway according to claim 16 which is connectable to a communication link for communicating with a remote server (50), wherein the framework supported at the gateway provides an interface to an application (120) executed by the remote server.

18. Instructions for a platform (110) which controls target devices (151-153) in a local network, the instructions causing a processor of the platform to support an open services gateway framework, and to execute at least one application (130) to control the target devices, wherein each target device (151-153) is represented by an entity (133) which can be manipulated by the application (130) across an application programming interface (API), the entities (133) following a common hierarchical structure of device types, in which an entity representing a device type lower in the hierarchy inherits the properties of device types higher in the hierarchy, whereby to present a consistent API to applications.

19. Instructions according to claim 18 wherein the entities form part of a device abstraction layer which uses a common language.

20. Instructions according to claim 19 wherein the abstraction layer further comprises bridging drivers (141-143) which translate messages between the common language and a protocol which is used to interface with the target devices.

21. Instructions according to claim 19 or 20 wherein the common language is the Home Uniform Control Language (HUCL).

22. Instructions according to any one of claims 18 to 21 wherein an entity which represents a target device is registered with the framework as a device service.

23. Instructions according to any one of claims 18 to 22 wherein a device service (146) is registered with the framework which is capable of representing a plurality of target devices, each target device being represented by an individual entity (147) within the device service.

24. Instructions according to claim 23 wherein the device service comprises a HUCL composite device (146), each target device being represented by an entity which is a sub-device (147) of the composite device.

25. Instructions according to claim 23 or 24 wherein an API (165) between the device service and an application comprises a command to send a message to the device service and a command to receive a message from the device service.

26. Instructions according to any one of claims 23 to 25 wherein a wrapper function (162) is provided at an application (130) to translate high- level commands into lower-level messages used across the API.

27. Instructions according to any one of claims 18 to 26 wherein if an application determines that it is not able to control a target device at a particular level of the hierarchy of device types, it finds a lower level of the hierarchy at which it is able to control the target device.

28. Instructions according to claim 27 wherein the entity includes a list of device types higher in the hierarchy whose properties have been inherited.

29. Instructions according to claim 27 wherein the application determines the lower level of the hierarchy at which it is able to control the target device by using knowledge of the hierarchy of device types.

30. Instructions according to any one of claims 18 to 29 wherein device services are arranged to notify the application of the occurrence of an event at a target device.

31. Instructions according to claim 30 wherein an entity maintains a list of applications that wish to be notified of the occurrence of an event and informs those applications when the event occurs.

32. Instructions according to claim 30 or 31 wherein the entities have a consistent hierarchical structure of event notification, with entities inheriting the events of higher members of the structure.

33. A computer program product comprising a machine-readable medium which carries the instructions according to any one of claims 18 to 32.

34. A library of entities (133) for use with a platform which supports an open services gateway framework, and which can execute at least one application to control the target devices in a local network, each entity representing a target device in the network and being manipulable by an application across an application programming interface (API), and wherein the entities following a common hierarchical structure of device types, in which an entity representing a device type lower in the hierarchy inherits the properties of device types higher in the hierarchy, whereby to present a consistent API to applications.

35. A platform, instructions, a computer program product or a library of entities according to any one of the preceding claims wherein the open services gateway framework is an Open Services Gateway Initiative (OSGi) framework.