DDS Middleware Data Patterns

There can be hundreds of topics in a system developed with DDS. It will be difficult to consider and decide separately which topic should be communicated with which service quality. When we examine data transmission in systems using DDS, we see that we can bring together topics that show certain behaviors. We can classify these as Use Cases or Data Patterns. Mostly used DDS Data Patterns are as follows:

Continuous Data Pattern:
Usually, measurement data periodically read from a sensor fall into this classification. Examples include temperature data update, stock updates, vehicle position and speed information update.
For data that fit the Continuous Data pattern, DDS quality of service settings will be as follows:
Reliability: Best Effort. If data is lost while being transmitted to subscribers, it will not be transmitted again. Some subscribers may have received the data, while others could not.
Durability: Volatile, In this case, only data will be transmitted to subscribers who are subscribed at that time.
History: Last 1 or N samples: The last status of each record will be kept.

State Data Pattern:
We have specified state information as the properties of an object that change over time. The state data of the objects changes less frequently, and their state information is published as a DDS topic when their state changes. Since the status information changes less frequently, when an application enters the system later, it should not wait for the status information to change and should be able to access the latest status information. Examples of status information are the departure time of the trains, the operating status and mode of the radar, and the maintenance status of the vehicle.
For data that fit the Status Data pattern, the DDS quality of service settings will be as follows:
Reliability: Reliable. Status information will definitely be communicated to all subscribers.
Durability: Permanent in Local Memory (Transient_Local) or Permanent in Service Memory (Transient): an application that subscribes later will be transmitted as much status data (usually the last one) in the history.
History: Last 1 or N cases. : Last 1 or N status data will be stored.

Command Pattern
Commands are sent to a component and used to change the state of objects in that component. For example, a stop broadcast command can be given to a radar, and the vehicle can be given a stop command. It is essential that the commands be transmitted to their destination.
For data that fit the command data pattern, the DDS quality of service settings will be as follows:
Reliability: Reliable. Command information will definitely be transmitted to all subscribers.
Durability: Volatile: Command data will be transmitted only to the currently active subscribers.
History: Last 1 or N cases. : All commands will be stored and transmitted.

Configuration Pattern:
It contains all kinds of information about the configuration of the system. Subscribed applications usually need this data at startup. The configuration data such as the maximum number of users allowed in the system, the state in which the radar is turned on, are kept permanently on the DDS. In particular, the configuration data that is required by more than one component, which is mission-critical (data can be corrupted), can be managed by the DDS middleware.
DDS service quality settings for data that fit the Alarm Data Pattern will be as follows:
Reliability: Reliable. Alarm information will definitely be communicated to all subscribers.
Durability: Persistent on the disk: Even when the system is turned off and on, data is stored and data is provided to each subscriber.
History: Last 1 or: The last status of the configuration will be stored and transmitted.

Event Pattern:
Used to notify recipients that an event has occurred. Events can be triggered at any time (asynchronously) and are anonymous. So there is no connection between generating the event and using the event.
For data that fit the Event Data Pattern, the DDS quality of service settings will be as follows:
History: Last N cases. : All events will be stored and forwarded.
The Event Data pattern may have specialized safe or bona fide use cases. If it is absolutely required to be transmitted in the application, Reliability is set as secure.
Events are generally considered as volatile and permanent. They only forward the same to the apps that are currently subscribed. Depending on the needs of the application, it is possible to use Permanent in Local Memory (Transient_Local) or Permanent in Service Memory (Transient) or even persistent on disk.

Alarm Data Pattern (Command Pattern):
A sudden situation should be communicated to the relevant subscribers quickly. An example is the shutdown of a device, the temperature data exceeding the limit value. The alarm data Pattern is actually a specialized case of the Event Data Pattern.
DDS service quality settings for data that fit the Alarm Data Pattern will be as follows:
Reliability: Reliable. Alarm information will definitely be communicated to all subscribers.
Durability: Volatile: Alarm data will be transmitted only to the currently active subscribers.
History: Last 1 or N cases. : All alarms will be stored and transmitted.

Survival (Watchdog) Pattern:
The subscribing application may be asked to be aware of the survival status of critical applications on DDS. For example, in an in-vehicle system, we need to know whether the application that provides GPS data is alive or not. This design pattern can be managed by Deadline and / or Liveliness available in DDS.
For data that fit the survival pattern, DDS quality of service settings will be as follows:
Reliability: Reliable. Watchdog information will definitely be communicated to all subscribers.
Durability: Volatile: Only valid for the current active subscribers.
Deadline: X milliseconds. If a record is not updated for X milliseconds, a notification occurs in the application subscribed to that data. The relevant application decides what to do in this situation. In more critical systems, features such as automatic transition to another source providing the same data can be provided by using ownership service quality.