1

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:

  • DDS 2.2.3 Supported QoS
  • RTPS 8.7.2 DDS QoS Parameters
  • RTPS 8.4.2.1.3 The timing characteristics of all implementations must be tunable.

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.

rnd_nr_gen
  • 2,203
  • 3
  • 36
  • 55

1 Answers1

0

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.

rip...
  • 996
  • 5
  • 20
  • all your interpretations about "real-time" are all right and just meet what I unusually understood about RT. The point is: many similar technologies also define their "deterministic" behaviour and are well deployed in high perf RT system; but they don't sell themselves by putting "real-time"such serious term in the specification title. This bothers and confuses me. As we know, the real-time achievement depends highly on application requirement. I expect DDS/RTPS defines more and states more clearly.. Or I miss some important sections from specs that you can advice me. – rnd_nr_gen Sep 06 '20 at 15:13
  • The point I was making was, it is the application or system that defines the facets (accuracy, time) of the answers it needs, and OMG-DDS provides the necessary information about whether those constraints are being met. So "real-time" is used here to indicate that it is /capable/ of real-time, which is all that /any/ "real-time" application or system can claim. Is OMG-DDS deterministic? When used correctly, yes. Will it tell you if your system is not meeting the real-time constraints that *you* have applied, yes. So why not use 'real-time'. – rip... Sep 11 '20 at 21:39
  • Can you give some text example where DDSI-RTPS "provides the necessary information about whether those constraints are being met"? I read some timing constraint definition in spec but addressed as optional or DDS implementation vendor dependent which make "real-time" spec very weak. I am looking for clear mandatory constraint on implementater and application; of course it is then bad for vendors. I am very OK to sell industry something with attractive word like "real-time" but just want to make sure I don't miss important parts in the spec.. – rnd_nr_gen Sep 13 '20 at 06:35
  • Real-time provisions in DDS are vendor dependent. This surprises you? If that means to you, that you can't, in good conscience, sell someone OMG-DDS because a vendor may not have implemented the complete spec to your complete satisfaction, don't. Real-Time means correct answer on time and that's defined by the system architect. If you are the SA and you don't think DDS is "rt" enough? fine, use something else. – rip... Sep 16 '20 at 03:14
  • there is no surprise to me. DDS is absolute a good choice in many ways and for rt applications. Maybe I just tried to compare the detail of a real-time OS's spec with DDS's "real-time" pubsub one. It is pretty OK to me that DDS Spec defines as less as possible and give vendor freedom to design their timing constraint. I am sure the question or discussion is beyond technical level :p – rnd_nr_gen Sep 16 '20 at 19:08