Hello,
First, some background information.
A part of the radar system I work on contains a sensor and a tracker. Data is published by the sensor in a topic called Receiver_Samples. The tracker subscribes to Receiver_Samples, processes the data, and detects tracks in the data.
I would like to be able to implement a "signal_injector" application that could be run to inject a target-like signal into the Receiver_Samples data. It would need to subscribe to Receiver_Samples, modify the data, and re-publish it.
I know I can use Exclusive Ownership and Writer Strength QoS settings on the to ensure that the tracker will receive data only from the injector when the injector is present, and only from the sensor when the injector is NOT present.
But how do I gt the injector to receive only the samples published by the sensor, and prevent it from receiving data samples that it has itself published?
If I were to use Exclusive Ownership QoS on the injector's reader, it would only ever see its own samples, not those published by the sensor.
Any Ideas?
How much latency can you live with?
How much latency?
Hard to say... What are you thinking?
Hello Dallas,
I think this HOWTO may address the use-case you describe: https://community.rti.com/kb/how-do-i-get-datareader-ignore-datawriter-belongs-same-domainparticipant
Gerardo
Being able to inject faults or fuzz to test behavior or for training is a tricky thing. The "easy" way is to write a bridge application that subscribes to the output of the Radar subsystem on (Domain N), and then re-writes the data (either without modification or with fuzz or additional tracks or etc...) on the domain where the Tracking subsystem resides (Domain !N)
The bridge has to be bidirectional, so if a C2 application is on the Tracker domain, the bridge has to intelligently filter Radar subsystem commands over onto the Radar domain.
Implementing a bridge* adds latency, since you are adding a hop. On the other hand fuzzing the data (using a recorded track in replay for example) should take very little additional time if it is scripted rather than algorithmic, and you can add an artificial delay to the "no change" path, so that the time to receive un-fuzzed data is similar to fuzzed data.
* I've done this with Routing Service plug-ins, where the fuzzed data was injected using java plug-ins. It wasn't a Radar system so I could accept latencies in RS and in Java that would horrify your average radar person. Routing Service has a lot of capability ... and you pay for that in latency, but the latency is less elastic than you would think. If you only have two or three topics to bridge, a tightly written, threaded c/c++ application will probably inject little latency, but the latency scales with the number of Topics. If you are talking many more than that, Routing Service will probably serve well.
You can also run everything in non-bridged mode by simply running the Radar subsystem on the Tracking system's domain. This will also allow you to collect data on what kind of latencies you are seeing across the bridge.
I'm unsure about one thing. While Gerardo's link will allow you to configure the DP to ignore it's own publications, I'm unsure where the OWNERSHIP_STRENGTH comes in to play:
1) A:DataWriter on topic Foo, Ownership = Owned
2) B:DataWriter "Weak" on topic Foo, Owned, strength = 0
3a) C:DataWriter "Strong" on topic Foo, Owned, strength = 10, Domain Participant has been configured to ignore its own published traffic.
3b) C:DataReader on same participant as Strong publisher.
With the above setup, how does the Domain Participant C react when told to ignore its own traffic. My guess is that it will ignore its own DATA and META-DATA (ie, the "Strong" DataWriter and its ownership strength 10 is ignored because the Participant never wired it up)m so the DataReader will continue to get the data published by the "Weak" publisher B).
This seems counter-intuitive or at least a leak in the spec, or I'm mis-remembering the exact text so should go review it. The point of ownership strength is to prevent a weaker writer from having its data seen by readers, but in this case, it may still get through.
Thanks Guys,
I know I could write a bridge application that could either publish into a different domain, or publish to a different topic name, but I want the system to be able to run normally in the absence of this signal injector application. Ideally, I should be able to start and stop the injector in real time while the radar is actually operating.
I think the information in the link Gerardo posted looks promising. I can use ownership strength to ensure the tracker will receive the right data, and the ignore_participant feature to ensure the injector does not receive its own publications.
I described this solution to a colleague. He said that he can picture a guy standing on a soap-box shouting, but wearing ear-muffs. :-)
Dallas
One never knows what others' abilities are :)
Still have questions about the behavior vis-a-vis the QoS, and a Participant being told to ignore itself, and whether that means that the High-Strength publisher is ignored entirely, or the Participant both knows/doesn't know (it knows there is a high-strength DataWriter, so it ignores the lower strength DataWriter, but then it ignores the data from the High because it has been instructured to do so, or it ignores the High so much, that it never registers it so still accepts the Low).
That's one for RTI. Mostly because I don't know what the "commander's intent" is here. What was intended, and does that intent provide the opportunity for a side effect.
Hi Rip,
Note that you could have a DomainParticipant completely ignore entities on another DomainParticipant as well. However in https://community.rti.com/kb/how-do-i-get-datareader-ignore-datawriter-belongs-same-domainparticipant we are using a finer grain resolution and having specific DataReaders ignore DataWriters in the same DomainParticipant.
This is actually a pretty "normal" thing to do, many of RTI's "DDS Services" do exactly that, otherwise you would get unreasonable self publishing loops. For example the RTI Persistence create DataReaders on topic "T" in order to store the data published by DataWriters that have DURABILITY kind TRANSIENT or above. It also creates DataWriters to send the stored data to DataReaders that specify DURABILITY kind TRANSIENT or above. Except the Persistence DataWriter explicitly ignores the DataReader on that same Persistence Service... Otherwise the Persistence Service would get an undesirable "echo" of all data back to itself.
When a DataWriter ignores a DataReader it is as if it did not exist (or was never Dicovered). The DataReader could still get data if it happened to be listening a a multicast address and there was another DataReader that caused the DataWriter to send to that multicast. For that reason the DataReader should also do the same and "ignore" the DataWriter in the same DomainParticipant. If a DataWriter is ignored there can be no instances owned by that DataWriter as the DataReader never receives them. The ignore (even if multicast messages are received) is happened at a much lower level in the protocol stack before it even knows which Topic or instance the data is for. If you do these two things there are no side-effects as far as I can think of...
Gerardo
DataReaders