Device Controller

A PROMISE Device Controller (DC) provides the interface function between components that can support the PROMISE Messaging Interface (PMI) and those which cannot. One example would be when dealing with “simple” PEIDs that do not have any significant processing power (see PROMISE PEID Grouping for the list of PEID capabilities). In such a situation, the Device Controller may be regarded as a "PEID Reader", via which data can be read from and written to a PEID.

The Device Controller may be an embedded component of a PROMISE Data Services implementation, or it may be a distributed Device Controller implementation, in which case the PROMISE Messaging Interface (PMI) is the interface between the DC and PROMISE Data Services (middleware). These two alternatives are highlighted in the diagram to the right.

A PROMISE Device Controller might normally correspond to a single reader device, however it could also be part of a more complex implementation where a group of reader devices collect data from multiple PEID sources, even ones where the technology type is not the same, such as a mixture of barcode, RFID and wireless sensor devices. In this situation data filtering, transformation and aggregation may be accomplished by special routines integrated in the Device Controller.

This flexibility allows very specialised Device Controller implementations that can perform data transformation appropriate to the type of PEIDs being used, the need to aggregate inputs from different PEID types, or even transformations which are influenced by the location of the DC and the role it has to perform in interfacing to PEIDs. Device Controllers that have the responsibility to filter and aggregate data from different PEIDs, or sensors attached to PEIDs, may also need to provide buffering services.

Whenever the connection or disconnection of a PEID is detected by a Device Controller, the DC should create a Device Management event which is then accepted by PROMISE Data Services. The latter then uses the event to trigger or interrupt other processes which depend on the availability of the detected PEID.

Device Controller Technologies

A PROMISE Device Controller may be implemented in a variety of different ways. It may be tightly-coupled to a PROMISE Data Services implementation using a closed, proprietary interface - the embedded DC component shown in the diagram above. Alternatively, it may be a loosely-coupled or distributed implementation, in which case it must implement the PMI in order to connect to a PROMISE Data Services infrastructure.

The Device Controller may be implemented on almost any suitable technology platform ranging from a complete PC, embedded systems, PDAs, mobile phones, etc, It can have a persistent or on-demand connection to the middleware (PROMISE Data Services). Depending on the complexity of its application, it will have one or more "downstream" interfaces. These interfaces may include the PROMISE Core PAC Interface for connecting PROMISE-compliant PEIDs. However they may extend to any open or proprietary interface that is necessary to connect to PEIDs or AIDC devices, such as barcode interfaces, various RFID standards, Bluetooth, Zigbee, and so on.

Device Controller Security

The Device Controller (DC) may also have to operate as the proxy for managing PEID security. A PEID may contain secure data, which might for example be encrypted, but might also be “clear” data limited to be read only by users with appropriate permissions. The DC must respect such security attributes. It may be necessary for the DC to retrieve the metadata structure for a PEID from the PEID itself or a Metadata Manager in order to determine the correct attributes.

Similarly the DC must be responsible for ensuring that data is written to a PEID according to the security attributes defined in its corresponding metadata structure. It may also be a requirement to be able to limit the scope of authority of certain Device Controllers, e.g. maybe certain DCs are only permitted to read and never write data.