CODEWITHSUNDEEP
real-timedata-distribution-service
rnd_nr_gen
rnd_nr_gen

Reputation: 2281

any "real-time" constraint defined by DDS/RTPS (data-distribution-service)?

Data Distributed Service DDS/RTPS is promoted as standard for "real-time" middleware/application, at least the RTPS states for Real-Time Pub-Sub. However, when I read the specs, I did not find any clear definition or constraint about real-time requirements (e.g. classic soft/hard real-time aspects).

RTPS defines some methods to make DDS as efficient as possible, but selling it as "Real-time pub/sub" is not really precise IMHO.

Sure, there are a lot of projects/products involving DDS and their performance can meet their real-time requirement. But It still depends on vendor implementation of DDS and actual system setup which not relevant to DDS.

Do I miss any point about the real-time aspect in DDS?

I found some relevant sections in specs respectively:

but I don't really see any clear definition of requirement on implementation (e.g. RTPS 8.4.2.1).

Same logic: C/C++ is great for high performance and real-time application, but no one put "real-time programing language" as the title of its standard spec.

Upvotes: 1

Views: 392

Answers (1)

rip...
rip...

Reputation: 1024

Not sure where you got your definition of "classic hard/soft real-time" or how you are applying it.

Hard real-time is defined by the requirements, and is covered by two facets. A) What amount of accuracy in the result, and B) how much time is allowed to the system to generate the answer, to the accuracy required by point A. Those are defined by the system architecture, not by the definition of hard or soft realtime (To be complete, so you know where I'm arguing from, generally, "soft" real time means you can arbitrarily violate one of the two facets -- a close answer on time, or a correct answer even if it's late).

So how does DDS achieve "hard real-time"? It is deterministic, and with the correct QoS settings, will announce to the application that the hard-real-time constraints -- required by the application -- are/are not being met. It is up then to the application to decide if this is acceptable or not.

If you say you need an answer correct to 5% (ie, can be wrong 95 times out of 100) and I have until the heat-death of the universe to provide the first answer, then it is rilly rilly simple for me to meet those hard real-time constraints.

On the other hand, if you say you need an answer correct to the infinitth decimal point, and you needed it 30 seconds prior to the event that generated it, no system in the world would be able to provide that, so there is nothing that is hard RT in that system.

It's deterministic, and the messages that it supplies to the application determine its "real-time"edness, based on the requirements of the system using it.

Upvotes: 0

Related Questions