OpenICE Community Support Forum

Welcome to the OpenICE community support forum. Use this forum for submitting bugs, asking for help, and solving problems you are having with OpenICE software. For ideas, general questions, and conversation please use the discussion forum.


Jeff Plourde 3 years ago in DDS • updated 3 years ago 0
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.
DDS OpenICE demo-apps

OpenDDS3.12 Monitor tool

Amutha 3 weeks ago in DDS 0

Greeting to All,

I am Using OpenDDS3.12. I follow steps for Monitoring tool which is given in userguide.htm. It is working fine with DCPSInfoRepo - repository mode.  But I want to run the publish , subscribe program as rtps_udp mode. Is there possibility to monitor rtps_udp publish and subscribe program. It is required for my project.

Note : Publish - Program gives data to subscribe periodically. Means that , No termination happend.

Subscribe - program gets data from publish whenever data is alive.



maryem 1 year ago in DDS • updated by Anthony Tenison 10 months ago 1


i follow the instruction of the documentation "open DDS 3.9 version .

ACE_ROOT/ace/config.h exists, skipping configuration of ACE+TAORunning MPC to generate project files

this message error appear : can't open perl script , No such file or directoryError from MPC, stopped at configure line 1136.

can you help me ??

Build x73-idl-ospl-dds failed

K. Ebeling 2 years ago in DDS 0

I have installed an evaluation-version of VortexOpenSplice (6.6.2p1) from PrismTech. If I try execute task "osplIdlppJava" - following errors are thrown:

Generating from ice.idl
/opt/PrismTech/Vortex_v2/Device/VortexOpenSplice/6.6.2p1/HDE/x86_64.linux/bin/idlpp EVALUATION VERSION
*** DDS error in file /home/kieb/workspace/mdpnp/data-types/x73-idl/src/main/idl/ice/ice.idl: Type 'wstring' (defined in DeviceIdentity) unsupported near the token #pragma keylist DeviceIdentity unique_device_identifier
(line: 165, column: 0)
*** DDS error in file /home/kieb/workspace/mdpnp/data-types/x73-idl/src/main/idl/ice/ice.idl: Type 'wstring' (defined in DeviceConnectivity) unsupported near the token #pragma keylist DeviceConnectivity unique_device_identifier
(line: 218, column: 0)
*** DDS error in file /home/kieb/workspace/mdpnp/data-types/x73-idl/src/main/idl/ice/ice.idl: Type 'wstring' (defined in InfusionObjective) unsupported near the token #pragma keylist InfusionObjective unique_device_identifier
(line: 354, column: 0)
*** DDS error in file /home/kieb/workspace/mdpnp/data-types/x73-idl/src/main/idl/ice/ice.idl: Type 'wstring' (defined in InfusionStatus) unsupported near the token #pragma keylist InfusionStatus unique_device_identifier
(line: 390, column: 0)
*** DDS error in file /home/kieb/workspace/mdpnp/data-types/x73-idl/src/main/idl/ice/ice.idl: Undeclared referenced declarator alarm_limit_type near the token #pragma keylist AlarmLimit unique_device_identifier metric_id alarm_limit_type
(line: 424, column: 0)
*** DDS error in file /home/kieb/workspace/mdpnp/data-types/x73-idl/src/main/idl/ice/ice.idl: Undeclared referenced declarator alarm_limit_threshold near the token #pragma keylist GlobalAlarmLimitObjective metric_id alarm_limit_threshold
(line: 440, column: 0)
*** DDS error in file /home/kieb/workspace/mdpnp/data-types/x73-idl/src/main/idl/ice/ice.idl: Undeclared referenced declarator alarm_limit_type near the token #pragma keylist LocalAlarmLimitObjective unique_device_identifier metric_id alarm_limit_type
(line: 461, column: 0)
*** DDS error in file /home/kieb/workspace/mdpnp/data-types/x73-idl/src/main/idl/ice/ice.idl: Type 'wstring' (defined in Patient) unsupported near the token #pragma keylist Patient mrn
(line: 531, column: 0)
:data-types:x73-idl-ospl-dds:osplIdlppJava FAILED

It seams that type "wstring" is unkown in VortexOpenSplice and I can't see declarators "alarm_limit_type" and "alarm_limit_thresold" in file "x73-idl/src/main/idl/ice.idl"?

Can you help me please?


DDS Interoperability with commercial and open source based systems

Tim 3 years ago in DDS • updated by Paul Ourada 2 years ago 13
MDPnP et al,
I wanted to find out where the focus in regards to the DDS would currently and in the future?
  • Will RTI-DDS and Prismtech-DDS be implemented together? 
  • or one or the other DDS technologies used provided by the above stated vendors?
  • Are RTI-DDS, Primstech-DDS and OpenDDS interoperable with each other?
  • Does OpenDDS not satisfy all the requirements compared to RTI and Primstech DDS technologies?
  • According to OMG specification the DDS is embedded on top of UDP or TCP, is that correct?
  • How is DDS different from RTP/RTCP/RTSP and IEC 61850-GOOSE, if we are trying to achieve and implement real-time communication layer?
  • Have you guys had any thoughts of looking into Transport Information Collection Protocol (TICP) on top of IP?

What are RTI-dds & OpenSplice for?

Hyungi Kim 3 years ago in DDS • updated by Jeff Peterson 3 years ago 3
Hi, guys!

What are RTI-dds & OpenSplice for? on OpenICE.
I think RTI using the transform of idl to java.
that's right?

I want to know the exact usage.


Jeff Peterson 3 years ago
Hi Hyungi,

DDS is a distributed system abstraction layer that passes messages between the OpenICE nodes. DDS is technically a standard with commercial implementations distributed by RTI and PrismTech (OpenSplice). OpenICE is distributed with a community edition of RTI DDS.

More information about how we use DDS in OpenICE can be found in the working-draft of OpenICE App Architecture Description.

Under review

Good DDS Tutorial?

Bradford Needham 2 years ago in DDS • updated by Jeff Peterson 2 years ago 1
Do you have a recommended/favorite DDS introduction/tutorial? I'm finding that having a grounding in DDS would help in my understanding of how to use OpenICE.


DDS Time_t origin, range?

Bradford Needham 2 years ago in DDS • updated by Jeff Plourde 2 years ago 3
The RTI DDS documentation for Time_t simply states that it represents "a moment in time". It doesn't document an origin or range. What is the origin and range for this field? I ask because I want to know when it will rollover, and how to convert to/from Linux seconds-from-the-epoch.

The constructor takes an int seconds, and Java defines the default int to be signed 32 bits. From a quick calculation, that number will overflow in about 68 years from the origin.

Any idea what the origin for DDS Time_t is?

Under review

Device Adapter Written in C++

Alejandro Figar 3 years ago in DDS • updated by Jeff Plourde 3 years ago 1
I'm writing my own device adapter in C++. I've been able to receive demo_apps supervisor HeartBeat data. Also I'm able to publish my own HeartBeat topic data every two seconds, along with DeviceIdentity topic, with the image icon and all. I haven't published to TimeSync topic from my c++ app yet.
Could you point me in the right direction?
What are the steps I should follow to be able to see my c++ app as a connected device on your MDPnP demo_app? 

DDS OpenICE demo-apps

Anyone in here have lis-link experience?

toodles45 2 years ago in DDS • updated by Jeff Peterson 2 years ago 1

At the beginning of integrating a middleware which I would prefer not to write a driver myself per one of the focuses that OpenICE is trying to get rid of. Does anyone have any suggestions or experience integrating/facing with this software? I have not seen the lab end integrated into OpenICE which I hope can come soon... If I can help integrated that aspect it is probably bigger than the medical device conundrum.