Device Interoperability Layer

The PROMISE Device Interoperability Layer provides the mechanism by which devices can be automatically discovered by the PROMISE Data Services (middleware) layer. It supports the description of the device’s functionalities, and provides communication mechanisms that allow it to convey and receive the content to and from the middleware layer in a service-oriented, standardized, and uniform way.

The Device Interoperability Layer must support a service-oriented view of the PROMISE Core PAC, i.e. the Core PAC displays its functionalities in a formalized, preferably self-describing way.
The Device Interoperability Layer must support two modes of operation:
  1. Client-Poll Mode for invocation
  2. Server-Push Mode for information
Service access on the Core PAC must be granted by allowing the remote invocation of methods that are provided by the Core PAC. These methods are called actions. The access method on actions must be open, common to all actions, should be platform and programming language independent, and preferably standardized.
Available technologies for the push channel are for example Remote Procedure Call (RPC), Microsoft’s Component Object Model (COM), Java Remote Method Invocation (RMI), or the SOAP protocol. RPC and COM are not however platform independent and RMI is programming language specific, whereas the SOAP standard is a good candidate meeting our functional requirements.
This mode of operation is called control mode.
Each remote device such as a Core PAC has specific information associated with it. For example, the serial number of an RFID tagged product or the temperature of the bearing in a drilling machine are examples of such information. The sum of all this information is called the state of the remote device, and the variables describing the state of the remote device are called state variables. The change of a state variable is called an event.
State variables may be accessed in two fundamental ways:
  1. Actions may be defined on the Core PAC to query the contents of state variables. To keep track of the state of a remote device, we would therefore have to continuously query, i.e. poll the state of all state variables. This is highly inefficient.

  2. The remote device may be configured to report changes in state variables. It can be said that a subscription is made to events on the state variables. Subscriptions to events on state variables are highly efficient with regard to network traffic, and in many cases also utilization level in client applications.
The Device Interoperability Layer must provide an open, preferably standardized way for event subscription and for the format and protocols by which events are conveyed from the remote device to the client application. For example, the General Event Notification Architecture (GENA) is a protocol meeting these requirements.
This mode of operation is called event mode.
State variables and actions are strongly interrelated and may thus be logically grouped. A logical group of a number of actions and a number of state variables is called a service.
Besides control and event mechanisms, the Device Interoperability Layer must provide methods that allow PROMISE Data Services to connect to the Core PAC in a seamless and ad-hoc fashion.
With regard to networking, data should be transmitted using the UDP/TCP/IP protocol suite since this is a prerequisite from most backend applications. It is assumed that Core PACs provide the mechanism to join the IP network of the backend system by some means.
It is necessary for the Core PAC to retrieve an IP address from the network either using the Dynamic Host Configuration Protocol (DHCP), or by obtaining an address from the private IP address space using the Auto-IP protocol. These are the two standard mechanisms to network IP devices without manual configuration.
In order to allow the backend application to connect to Core PACs in an ad-hoc fashion, some type of discovery mechanism must be provided by the Core PAC. Here again, two modes should be supported:
  1. Server Advertisement
  2. Client Search
When a new Core PAC enters a network, it may actively inform PROMISE Data Services about its presence. In order to do this, it should broadcast certain messages in the network which reveal that a new device has joined and is ready to share its services with clients. This step is called advertisement.
Similarly, methods must be provided to un-register Core PACs from the network. The format and content of the messages as well as the methods for broadcasting them must be defined by the Device Interoperability Layer. Examples for such protocols are the GENA-based Web Service Description Language (WSDL) and the Simple Service Discovery Protocol (SSDP).
Examples of application cases in which advertisement is the preferred discovery model are:
  • new PEID sensors are installed in an existing machine, or

  • mobile products (cars, locomotives) enter a service point for maintenance where error codes, usage statistics etc. need to be read from a PEID on-board computer.
In general, this model is appropriate whenever the PROMISE backend is stationary and the Core PAC dynamically connects to PROMISE Data Services.
In contrast, PROMISE Data Services may also need to search for the Core PACs within range. This may be the case when the product containing the Core PACs is immobile and a mobile terminal is used e.g. for maintenance purposes. The maintenance terminal itself may run either a full or partial implementation of PROMISE Data Services. Therefore the Device Interoperability Layer must also define appropriate search mechanisms.
Note that only the core services are common to all Core PACs. Further functionalities may be added in form of application specific services that are not known a-priori to backend applications in general and PROMISE Data Services in particular. Therefore, mechanisms are necessary that reveal the supported services, the actions, the format of their arguments, and the state variables.
This step is called the discovery step and is mandatory to establish a run-time interoperation of previously unknown devices. Here again, WSDL or other XML-based protocols (like the UPnP discovery schema) are applicable.
Therefore, Core PACs require a device interoperability layer which is composed of common functionalities that are provided by semantic middleware such as CORBA, JXTA, UPnP or Web Services. The differences between these semantic middleware technologies are primarily the required infrastructure topology and the concept of how the life cycle of devices is handled.
Regarding the infrastructure, some middleware implementations requires a central directory of all devices and services (e.g. CORBA), whereas other implementations are based on a peer-to-peer approach (e.g. UPnP and JXTA). With respect to life cycle management, some middleware implementations rely on the model that devices are rather physical which are either actively present or absent/down (e.g. UPnP and JXTA), whereas other middleware implementations assume that once services are registered, they are accessible without the notion of being active or inactive and without a physical representation in mind (e.g. Web Services).
For the PROMISE Device Interoperability Layer, peer-to-peer based middleware technologies with a notion of physical devices are considered to be the preferred solution.