One of the underlying pillars of our work here at MD PnP is to discover and document what requirements and specifications have to be met for a universal medical device interoperability platform to be adopted and successful. Enterprise is complex because the requirements are often complex. One requirement I certainly did not foresee at the outset of my tenure here was the requirement from medical device manufacturers (paraphrasing here) that the technology stack used shall be standards based. DDS is standards based; ZMQ et al are not (with the exception of MQTT which recently became an Oasis standard). The standards based middleware requirement, amongst other requirements related to distributed system functionality, initially informed the decision to prototype with DDS. The OpenICE platform is defined by more than a single piece of technology in the stack - it aims to be a lot of things to a lot of people. As our prototyping efforts continue, we mount evidence for and against the requirements and obviously change technologies when they do not work. For example, initially the web demo was backed by Apache Camel but as the site was developed, Camel collapsed when trying to serve multiple realtime waveforms. The tech was swapped out for Node.js which has been working great.

We are not married to DDS, but in the near term (6 month time frame) for us to walk away from what has been developed already would be a massive undertaking and require a very strong case to justify it. This case would be composed of requirements, use cases, and/or functionality that could not be met or provided by the DDS layer of OpenICE. There is not enough evidence against the use of DDS to motivate us to stop what we are doing and rebuild the platform with a different middle layer. I'm encouraging you, and anyone else reading this, to provide input into what requirements and functionality they expect a medical device interoperability platform to meet and provide respectively.

"I require the platform to have message latency of less than 10ms between an x-ray unit and a ventilator so that I can synchronize the radiation exposure to the phase of respiration of the patient." This is kind of input I dream about because we can derive a lot of requirements from it about the OpenICE platform, the hospitals infrastructure, the ICE application, etc. Help us ensure that what we are building will meet the community's needs.

You eluded to but did not directly state a requirement that applications developed to run on the OpenICE platform should have minimal technological complexity to ease adoption. This is a very good point and one we have been considering internally. I would love to see us develop an application host environment that is decoupled from the middleware layer and/or transport layer protocol to provide exactly the minimal complexity you mention. The challenge is doing so in a way that allows the application developer to leverage the full power and potential of the platform without abstracting away too much. This is something I can't wait to work on! Exciting stuff...

With respect to bench tests: we could run bench tests for every message queue system (ZMQ, RabbitMQ, etc) and separately test every distributed system middleware (DDS, etc) but what message latency is acceptable? What raw message throughput is acceptable (at what average message size)? What requirements does this place on the infrastructure? Can we minimize the network requirements to maximize adoptability? (Remember that many small to mid sized hospitals have very limited infrastructure, if any.) We are prototyping to explore and document what requirements and specifications are required. We need reason for our development efforts and have to justify what we build with evidence, not anecdote.

I am not here to defend DDS. For the record, from my initial exposure to ZMQ, I like it a lot. I'd love to spend some time exploring it past what you can simply read on the wiki page - but it does not fit into the current iteration of OpenICE. Down the road when/if we find reason that the DDS piece does not fit into the OpenICE puzzle, we will change it. Again if you think that time is now, please please help us inform the initial prototype of OpenICE with requirements that are not being met.

Your initial question was about "DDS interoperability with commercial and open source based systems". We have a requirement that requires the middleware implementations be interoperable. If we find this to not be true with no obvious solution, this would be a strong piece of evidence for us to move away from DDS - but we haven't encountered this.

I hope this helps,
Jeff

Hi Tim,

The base standard for DDS is interoperable between vendors. We are constantly trying to inform the community of any issues with interoperability that we discover. For example, OpenICE no longer uses colons (::) in the Topic names because it is not approved by the standard and breaks interoperability. The intent of our current work is not to comprehensively test the DDS standard implementations. We do however test our system and ensure that DDS works.

I do not have a working knowledge of TICP - or any knowledge past what you can read on the link you provided. I'm not sure what aspects of the functionality DDS provides would be analogous to the functionality that TICP provides. I am confident enough in my understanding to say that they are different technologies with different purposes. DDS aims to provide an API into the underlying global data space, essentially abstracting many aspects of the underlying distributed system architecture. From my understanding, TICP is a transport protocol you can build an application on top of.

Our current development actions (6 month timeframe) are geared towards prototyping the system as best as we can understand it now. There are requirements that we are discovering as we build. If/when our requirements cannot be met by our current stack, we will research what tools will actually meet our needs. Frankly, there is no reason to rebuild work that has been completed successfully at this point. In the future, when optimization is a priority and we have a thorough and comprehensive understanding of what requirements our platform must meet, we may 'bench test' TICP among other transport layer protocols. Until that point, we will be using DDS.

If you have platform/system requirements in mind that you feel we do not currently meet, please please share them. We'd love to hear from you.
Thanks,
Jeff

Hi Nathan,

Thank you for your interest! Currently the MD PnP software does not support exporting data to a file or database. We are currently experimenting with two different functionalities: clinical data logger powered by MongoDB and a flat file export tool. Both are purely experimental right now and non-functional for clinical use. We are working on building these tools into our platform and I hope to see something ready for the world within the next couple months. If you are interested in exploring a "one-off" solution, I would recommend looking through the OpenICE sourceforge repository at https://sourceforge.net/p/mdpnp/code/ci/master/tree/.

You are absolutely correct about the DB9 to RJ45 console cable. It is not a Cisco console cable ... at all (...not even close). Stupid mistake on my end - thank you for catching it. I have updated the tutorial to reflect the actual pinout of the cable and even drew a little diagram to help. Check out the update here:
https://www.openice.info/device-adapter-setup.html#required-hardware-mp70

More updates to come soon! Thank you so much for taking the time to read through our work. I hope that we can help you be successful with your research. Happy New Years!
Jeff

Hey Tim,

Lots of questions packed into one question here...

1. "Will RTI-DDS and Prismtech-DDS be implemented together?" - Yes. The base standard of DDS is interoperable. The demo-apps package is built using the RTI DDS community edition. We have also used the PrismTech OpenSplice community edition to run apps on the network! Applications running both RTI and PrismTech community distributions were interoperable. It is the choice of the developer which distribution they would like to use. In the future state, OpenICE apps will be implemented using both distributions.
2. "or one or the other DDS technologies used provided by the above stated vendors?" - The demo-apps distribution comes packaged with RTI DDS included. The user could replace the RTI libraries with any other vendor if interested.
3. "Are RTI-DDS, Primstech-DDS and OpenDDS interoperable with each other?" - Yes, in theory. We have never used OpenDDS though because it does not support dynamic data types and has poor support for Java.
4. "Does OpenDDS not satisfy all the requirements compared to RTI and Primstech DDS technologies?" - OpenDDS does not implement x-types, does not support dynamic data in their API, is tightly coupled with CORBA, the build process for Java is complex, and does not have the same support offered by RTI and PrismTech. It is very usable, it just lacks certain features we have implemented.
5. "According to OMG specification the DDS is embedded on top of UDP or TCP, is that correct?" - DDS is an API for the  RTPS protocol which has standardized implementation using UDP.
6. "How is DDS different from RTP/RTCP/RTSP and IEC 61850-GOOSE, if we are trying to achieve and implement real-time communication layer?" - What about these protocols interests you? DDS seems like a good fit for our purposes. 
   1. http://en.wikipedia.org/wiki/Real-time_Transport_Protocol
      
   2. http://en.wikipedia.org/wiki/RTP_Control_Protocol
      
   3. http://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol
      
   4. http://en.wikipedia.org/wiki/Generic_Substation_Events#Generic_Object_Oriented_Substation_Events
7. "Have you guys had any thoughts of looking into Transport Information Collection Protocol (TICP) http://planete.inria.fr/ticp/ on top of IP?" - Never heard of this; seems interesting. Thanks for the link. Is there anything about this that caught your eye?

Thanks,
Jeff

Hi Alejandro,

I just loaded an RPi with Raspbian and demo-apps-0.4.2 and sure enough I reproduced the exact same error. Good find. I will figure something out ASAP and get back to you. Sorry for the inconvenience.

Jeff

Hi Alejandro, thanks for your question!

If you are trying to run the pre-built demo-apps binary (downloaded from mdpnp.sourceforge.net), DDS is included in the binary and should automatically run without further configuration. Essentially, you should not need to use the RTI DDS port in addition running the demo-apps. Try removing the RTI DDS libraries that were added.

Another quick step to try is to unset the NDDSHOME environment variable. To do this, enter "unset NDDSHOME" at the console. This will trigger the Java code in demo-apps to extract its own DDS libraries.

Let us know if this works and if there is anything else we can help with. I look forward to hearing back.
Jeff

Yes it is supported! Send an email to support@openice.info to automatically generate a request for help and we'll answer your question as quickly as we can. Thanks!