Hello all,
I am working on a solution for Reconfigurable Manufacturing System using Connext as the middleware and Zigbee as communication protocol. If anyone has any supporting literature, suggestion, insight or any related work, kindly let me know.
Many thanks in advance.
Hi,
Take a look at the DDS-related papers here: http://community.rti.com/dds_papers there are several that describe the use of OMG DDS (specifically RTI Connext DDS) for industrial-automation systems.
In addition we are preparing a manufacturing example. It is still not complete but in 3 or 4 weeks it will be available in the RTI Connext DDS GitHub repository.
Gerardo
Thank you so very much Gerard. The link is very helpful.
Does Connext support data transmission over Zigbee or do I need to find any Pluggable Transport?
I don't know of any pluggable transport for Zigbee networks. It would be an interesting proof of concept, but utility might be difficult to achieve. I'm thinking that pumping the RTPS protocol load over low-power WPANs would have a very high noise-to-signal ratio (assuming around 1 equivalent IP frame per second for the non 2.4Ghz spectra...), plus there's the problem with Zibgee's certification requiring two years' battery life for a device.
Depending on the Zigbee Endpoint Device's host's characteristics, you could run Micro or DDS on it, so I suppose under certain conditions a Zigbee pluggable transport would be theoretically possible, with the the low-bandwidth transport (for disadvantaged, intermittant and lossy [DIL] networks... and I guess that the Zigbee is all of that :/) stacked on top of it for good measure.
If I were tasked with this, I would use a custom bridge (or Routing Service Adapter, which is the type of thing it is designed for) that was DDS on one side, and Zigbee on the other. State of the Zigbee Mesh, and the state of the individual ZEDs, would be maintained by the bridge, and I would make no assumptions about what the Zigbee radios were attached to.
Published DDS instances would be subscribed to by the bridge, converted into the necessary information for the targeted ZED, and then sent however the Zigbee stack requires it. This would allow configuration/control and send/receive to mapped devices, and at the same time remove the underlying RTPS overhead from what the radios were being asked to transmit.
That said, this is the type of thing (Academic Research) that is needed to generate the empirical evidence needed, to make a yes/no decision, so: Have fun!
Hello,
If you want to look into creating an RTI Connext DDS transport plugin for Zigbee these two links should be useful:
Gerardo