DDS11 — Filtered_out_lifecycle_state Issue

Issue# 2050 Filtered_out_lifecycle_state Issue [Boeing SOSCOE] ? Sometimes the receiving application needs to know that data is being filtered-out. In some use cases this situation is different from the case where data is not being produced. ? A related question is whether the presence of filters (content-based, time-based) can be the cause of a DataReader to miss a requested deadline. It depends whether the deadline is interpreted to mean that data is produced at that rate, or else that data that passes the filter must be produced at that rate. ? SOSCOE thinks that the filter should not cause a deadline to be missed, rather the reader should receive explicit notification that the data was filtered-out. At least that data is starting to be filtered-out, not necessarily each time something is filtered out. ? In any case filters should not cause loss of liveliness. ? A typical use-case may be that a display-device is showing the tanks in a certain area (the one relevant to that particular display). The display has a filter to indicate that region of interest. When the tank leaves the region of interest, the display wants to know that. That way it can stop displaying it; however the display does not want to internally discard all the information about the tank immediately in case the tank appears again. The display needs to therefore know that the data for that tank instance is being filtered out. This situation is different from missing a deadline which may indicate that the data is not being generated as intended. ? Note that if a filter is present and a deadline is set, it would be necessary for the implementation to send some information to the reader so that the deadline would not fire. However, bandwidth is very important in some cases, so sending any information when the data is being filtered may be too expensive. ? One option may be to have the application change the deadline to a larger value when it finds out that the data is being filtered. Another possibility is to specify two values of the deadline, one when the data is not filtered and the other when the data is being filtered (the second one could be specified along with the filter). In this case the information that the middleware implementation sends to avoid missing the deadline could be sent at the lower rate. ? This facility may be hard to implement for all cases. For example in the case where the filter is applied at the source and the reliability QoS is BEST_EFFORTS it is not guaranteed that said notification would be received by the reader. If this is indeed the case then we would not require the filtered-out notification to be guaranteed if the reliability setting is BEST_EFFORTS. Proposal [Boeing SOSCOE] ? Add FILTERED_OUT lifecycle state to allow user to know that data is being filtered out. The usage of this state should be an option for the user. ? If the option is on, the state is set on a sample when the sample was filtered out and the previous sample was not filtered out. Only one notification of filtering is required, not one per sample being filtered. ? Optionally introduce a deadline_while_filtered QoS on the ContentFilteredTopic which would transition the deadline to a larger value when the data is being filtered.