OpenICE Community Support Forum

• 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.

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.

hello

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.

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?

• 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) http://planete.inria.fr/ticp/ on top of IP?

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.