OpenICE Community Support Forum

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.

Hi,

I noticed that at least one other user has had difficulties using OpenICE with Philips Rev K devices.

I have been able to successfully connect to Philips MP70 and MP50 devices with Rev G (and I believe the MD PnP lab has Rev J).

I recently had the opportunity to test OpenICE on a Philips X2, Rev K.2. The X2 does not have a serial port, so I used the LAN port on the external battery pack, and ran the monitor in demo mode. OpenICE was able to successfully connect, and is able to extract the numerics alright, but there are problems with the waveforms. Initial waveforms appear in the GUI, but then stop (I was using version 0.6.3 of OpenICE).

The log file shows that the waveforms have "no new samples to emit", and that the physioId of one of the signals is being read in as 0. There is also a DDS error indicating that the participant information was not available for device identity publication (see log file excerpt below).

Initially, and occasionally afterwards, there is valid waveform data in the sample array updates (viewed in the debugger). However, very quickly after starting, the updates start coming back empty. I have written code to export the numerics/waveform data to csv; the numerics data is written fine, but not even the first packet of waveform data is recorded.

I remember seeing the flags INVALID | QUESTIONABLE | UNAVAILABLE in the debugger for the MeasurementState of SampleArrayObservedValue objects (with physioId = 0).

I later tried testing on an X2 with rev J, and the software worked without problems. So there does seem to be a problem with rev K (and possibly newer) devices.

I have compared the export interface manuals for both Rev H and Rev K, and the differences between the two appear to be minimal (a few new objects have been defined).

Unfortunately I have had to send back the X2 rev K I had on loan, so I am unable to do much more hands-on troubleshooting myself at the moment. I do still have log files, and I did spend some time with a java debugger stepping through the code (mostly in AbstractDemoIntellivue and AbstractDevice), so I might be able to answer some questions... But hopefully the above information will be helpful when one of you needs to troubleshoot rev K or higher devices!

Regards,
Nathan

---------------------------------------------------

2015-05-26 14:38:23,524 | WARN | Bean with key 'timeManager' has been registered as an MBean but has no exposed attributes or operations | org.springframework.jmx.export.MBeanExporter | JavaFX Application Thread
2015-05-26 14:38:23,576 | ERROR | [D0000|Reader(80000807)|T=DeviceIdentity|GET_MATCHED Participant DATA]DDS_DataReader_get_matched_publication_participant_data:ERROR: Failed to get discovered_participant_data | com.rti.dds | EventLoopHandler
2015-05-26 14:38:23,576 | WARN | Unable to get participant information for DeviceIdentity publication | org.mdpnp.apps.testapp.DeviceListModelImpl | EventLoopHandler
2015-05-26 14:38:23,617 | INFO | Connecting to >126.3.145.100< | org.mdpnp.devices.DeviceDriverProvider$SpringLoadedDriver | Thread-15
2015-05-26 14:38:23,849 | INFO | Start emit fast data for period 2000ms | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | Network Loop
2015-05-26 14:38:24,375 | INFO | ProductionSpecification | org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
2015-05-26 14:38:24,376 | INFO | [[specType=SERIAL_NUMBER,componentId=ID_COMP_PRODUCT,prodSpec=DE037A8036], [specType=PART_NUMBER,componentId=ID_COMP_PRODUCT,prodSpec=M3002A], [specType=PART_NUMBER,componentId=ID_COMP_APPL_SW,prodSpec=S-M8102-1501A ], [specType=SW_REVISION,componentId=ID_COMP_APPL_SW,prodSpec=K.21.39 ], [specType=PART_NUMBER,componentId=ID_COMP_CONFIG,prodSpec=S-M8102-1401A ], [specType=SW_REVISION,componentId=ID_COMP_CONFIG,prodSpec=K.21.39 ], [specType=PART_NUMBER,componentId=ID_COMP_BOOT,prodSpec=S-M8000-1301A ], [specType=SW_REVISION,componentId=ID_COMP_BOOT,prodSpec=A.16.24]] | org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
2015-05-26 14:38:24,378 | ERROR | [D0000|Reader(80000807)|T=DeviceIdentity|GET_MATCHED Participant DATA]DDS_DataReader_get_matched_publication_participant_data:ERROR: Failed to get discovered_participant_data | com.rti.dds | EventLoopHandler
2015-05-26 14:38:24,379 | WARN | Unable to get participant information for DeviceIdentity publication | org.mdpnp.apps.testapp.DeviceListModelImpl | EventLoopHandler
2015-05-26 14:38:24,382 | ERROR | [D0000|Reader(80000807)|T=DeviceIdentity|GET_MATCHED Participant DATA]DDS_DataReader_get_matched_publication_participant_data:ERROR: Failed to get discovered_participant_data | com.rti.dds | EventLoopHandler
2015-05-26 14:38:24,382 | WARN | Unable to get participant information for DeviceIdentity publication | org.mdpnp.apps.testapp.DeviceListModelImpl | EventLoopHandler
2015-05-26 14:38:27,442 | WARN | No ObservedValue for 0 | org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
2015-05-26 14:38:27,443 | WARN | No ObservedValue for 0 | org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
2015-05-26 14:38:27,444 | WARN | No ObservedValue for 0 | org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
2015-05-26 14:38:27,469 | WARN | No SampleArraySpecification or RelativeTime for handle=2006 rt=null sas=null sar=null unitCode=null | org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
2015-05-26 14:38:28,002 | WARN | MDC_IMPED_TTHOR 1827 will repeat 109 old samples to make up a shortfall | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:28,002 | WARN | MDC_IMPED_TTHOR 1827 filling in 109 zeros; this should not continue happening | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:28,006 | WARN | MDC_ECG_LEAD_III 1817 will repeat 872 old samples to make up a shortfall | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:28,006 | WARN | MDC_ECG_LEAD_III 1817 filling in 872 zeros; this should not continue happening | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:28,020 | WARN | MDC_ECG_LEAD_II 1817 will repeat 872 old samples to make up a shortfall | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:28,020 | WARN | MDC_ECG_LEAD_II 1817 filling in 872 zeros; this should not continue happening | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:28,034 | WARN | MDC_ECG_LEAD_I 1817 will repeat 872 old samples to make up a shortfall | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:28,034 | WARN | MDC_ECG_LEAD_I 1817 filling in 872 zeros; this should not continue happening | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:28,464 | WARN | No ObservedValue for 0 | org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
2015-05-26 14:38:28,466 | WARN | No ObservedValue for 0 | org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
...
org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
2015-05-26 14:38:30,001 | WARN | MDC_IMPED_TTHOR 1827 no new samples to emit | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:30,002 | WARN | MDC_ECG_LEAD_III 1817 no new samples to emit | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:30,002 | WARN | MDC_ECG_LEAD_II 1817 no new samples to emit | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:30,002 | WARN | MDC_ECG_LEAD_I 1817 no new samples to emit | org.mdpnp.devices.philips.intellivue.DemoEthernetIntellivue | taskExecutor-1
2015-05-26 14:38:30,516 | WARN | No ObservedValue for 0 | org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
2015-05-26 14:38:30,518 | WARN | No ObservedValue for 0 | org.mdpnp.devices.philips.intellivue.AbstractDemoIntellivue$IntellivueExt | Network Loop
2015-05-26 14:38:30,518 | WARN | No ObservedValue for 0 |
...
2015-05-26 14:38:33,593 | ERROR | [D0000|Reader(80000807)|T=DeviceIdentity|GET_MATCHED Participant DATA]DDS_DataReader_get_matched_publication_participant_data:ERROR: Failed to get discovered_participant_data | com.rti.dds | EventLoopHandler
2015-05-26 14:38:33,593 | WARN | Unable to get participant information for DeviceIdentity publication | org.mdpnp.apps.testapp.DeviceListModelImpl | EventLoopHandler


-----------------------------------------------

Hi,
I have cloned the repo of mdpnp with git. The java jdk I use is 1.8.0_40 (Oracle Corporation 25.40-b25) and gradle is version 2.3. I work on Mac OS X 10.10.4 x86_64. If I try to build OpenICE with command "gradle build" from root directory of mdpnp following error is thrown:
FAILURE: Build failed with an exception.

* Where:
Build file '/Users/kieb/Documents/workspace_openICE/mdpnp/interop-lab/demo-apps/build.gradle' line: 16

* What went wrong:
A problem occurred evaluating project ':interop-lab:demo-apps'.
> Could not resolve all dependencies for configuration 'classpath'.
> Could not resolve org.bitbucket.shemnon.javafxplugin:gradle-javafx-plugin:8.1.2-SNAPSHOT.
Required by:
unspecified:unspecified:unspecified
> Could not HEAD 'http://repository-javafx-gradle-plugin.forge.cloudbees.com/snapshot/org/bitbucket/shemnon/javafxplugin/gradle-javafx-plugin/8.1.2-SNAPSHOT/gradle-javafx-plugin-8.1.2-20141008.214348-1.pom'.
> org.apache.http.client.ClientProtocolException (no error message)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

I also have tried to import OpenICE as Gradle-project into Eclipse Luna (4.4.2) with same result. I switched to openICE-tag 0.6.3 - same result. What is wrong?