HeartBeat

The OpenICE systems need to track the presence and availability of various devices in the system. There are a lot of possible ways to maintain the known "liveliness" of remote participants. Here are some of the ways we have tried in the past and the solution which we have converged upon during OpenICE development.

• Participant Liveliness
  • Our first mechanism was to use DDS metadata to track the liveliness of remote participants. In principle this worked but it had several drawbacks and unmet requirements...
    • It may not always be desirable to maintain a 1:1 correspondence between participant and device. For instance a participant accepting connections from bluetooth devices might actually communicate data for a number of such devices through one DDS Participant.
    • Participant meta-data does not usually get relayed between DDS networks. Further, when data is relayed to a remote network (perhaps at the central monitoring or data center scope) it is presented to that network through a new participant local to that network.
    • Configuration of discovery-related parameters is vendor-specific so establishing compatible settings can be difficult.
• DeviceIdentity instance Liveliness
  • Our next attempt was at using the Liveliness of DeviceIdentity instances to track remote device liveliness.
    
    • This successfully breaks the undesirable 1:1 correspondence participant and device.
    • The problem here is that DeviceIdentity is not frequently republished. Meaning that once a reader has received a DeviceIdentity instance sample it *will* properly mark that instance "NOT ALIVE" when it fails to communicate a heartbeat; but later when the connection is re-established there is no new sample to communicate and the state of the instance will not become ALIVE until a new sample is produced.
• A distinct HeartBeat topic
  
  • To meet our requirements we created a Topic in the system expressly for the purpose of discerning liveliness.
  • By contract devices all must publish a new sample of Heartbeat every two seconds. The sample size is deliberately kept very small; including only UDI and a device type.
  • Because this is "user" level data (and not metadata) from the DDS perspective it will "properly" traverse routes and links between DDS systems.
  • This topic is described in our IDL. Our QoS settings are in a profile called "heartbeat" within ice_library.xml.
  • You can view realtime Heartbeats from devices in our lab on our diagnostics page.