Directory

DDS Model and modeling Tools

1.DDS Introduction

1.1 What is DDS

1.1.1 Global Data Space

1.1.2 Domain

1.1.3 Topic

1.1.4 Publishers and Subscribers (Publisher and Suscriber)

1.1.5 DataReaders, DataWriters, and Data Samples

1.1.6 Quality of Service (QoS)

1.2 How DDS works

1.3 Implementation of DDS

2. DDS Modeling tools

2.1 The DDS Technology Plugin's Menu

2.2 General Options option of the DDS plugin

2.3 DDS Plugin Toolboxes

3. DDS Model Example

3.1 DDS Example Models

3.1.1 Model Example 1: HelloWorld

3.1.2 Model Example 2: Net Chat

3.2 PSM – OSPLDDS

3.3 PSM – RTIDDS

3.4 《QosPolicyLibrary》 QoS Policies

4. Afterword

1、Introduction DDS

DDS (Data Distribution Service) is a data-based communication middleware standard that aims to establish high-quality data communication in distributed systems. At present, it is widely used in aerospace, automotive autonomous driving, robotics, Internet of Things and other fields. The essence of DDS is a data bus that enables communication between systems by providing a shared data space.

DDS uses a publish-subscribe communication model to create a decentralized, architecturally independent, scalable, asynchronous network. In the standard framework of DDS, systems can communicate with each other by publishing and subscribing to a topic. QoS can be specified on a topic to guarantee quality of service.

What is DDS

DDS first defines the basis of communication, which is a shared data space, which consists of the following:

•  Global Data Space

•  Domain

•  Topic

Global Data Space

In DDS, the DDS network is referred to as the Global Data Space.

Domain

Within a global data space, you can create a part of a network called a domain. A domain is identified by a domain name and a numeric domain ID. There can be one or more domains within a global data space.

Topic

In a Domain there is a Topic that describes the type of data transmitted over a network. For example, if you have an application that wants to use DDS to receive information about the weather, then the topic could be temperature. If you have the same topic in different domains, they are considered different topics.

The DDS standard model then defines data-based operational objects and quality of service parameters, including:

•  Publishers and subscribers (Publisher and Suscriber)

•  DataReaders, DataWriters, and Data Samples

•  Quality of Service (QoS)

Publishers and Subscribers (Publisher and Suscriber)

Applications that use DDS are called Domain Participants because they participate in the Domain.The applications that send data are called Publishers, and the applications that receive data are called Suscribers.Domain Participants can be Publishers, Suscribers Or both.

DataReaders, DataWriters, and Data Samples

Data is sent and received as a data sample on the DDS network, as specified by the DDS data type. A topic registers a DDS data type, which is then called a Registered Type, to specify the type of data that must be used to communicate about the topic. Publisher uses DataWriter to send data on the DDS network. A Publisher can have one or more DataWriters, and a DataWriter can publish one or more topics. The Subscriber uses DataReader to receive data from the DDS network. A subscriber can have one or more DataReaders, and a DataReader can subscribe to one or more topics.

Quality of Service (QoS)

In addition to being able to send and receive data, you can also specify Quality of Service (QoS) that describes the quality of data transfer for Publishers, Subscribers, or DataReaders, DataWriters. You can assign individual QoS policies to these entities, or you can assign a set of QoS policies called QoS profiles.

In order to better understand the logical relationship between the various objects of DSS, the DSS specification also provides a metamodel, which is a simplified diagram of the metamodel of DSS DCPS:

The working process of DDS

The DDS communication process between the various systems is as follows:

•  Publisher writes data to a topic through DataWriter

•  Subscribers are notified

•  Subscriber reads data from Topic via DataReader.

In order to ensure real-time and performance requirements, you can define QoS (Quality of Service parameters) that can meet performance requirements on the topic, so that subscriptions and notifications can determine the timing of interaction based on QoS parameters, so as to ensure real-time performance.

The following UML sequence diagram illustrates the interaction of the various objects in the DDS subscription notification scenario.

The data publishing process for DDS is as follows:

The process of receiving data from DDS is as follows:

DDS implementation

The criteria for DDS are specified by the Object Management Group (OMG) standard. The standard provides specifications that explain how to configure a DDS network and how an application should use a DDS network. The DDS standard is implemented by several different DDS vendors. Each vendor can implement the DDS standard using the programming language of their choice. Despite various low-level implementations, applications from various DDS vendors are interoperable (applications from one vendor can communicate with applications from different vendors) because their vendors are implemented in accordance with the DDS standard. DDS applications, consisting of the previously described definitions (e.g., Domain, Topic, Data Sample, Publisher, Subscriber) can be defined in a programming language-agnostic manner using XML or IDL specifications. These XML and IDL specifications provide the ability to port DDS applications between different vendors with different programming language implementations.

DDS Modeling Tools

DDS is essentially a data bus-based communication specification that defines the relevant objects, properties, and interaction Model . The use of UML in the DDS specification defines the relevant object model, interaction model, and state rules. To fully and thoroughly understand DDS, you need to be able to read the canonical model of DDS and model the application of DDS.

As a mainstream modeling tool for UML and Sys ML, EA provides a DDS modeling plug-in, which provides a DDS profile on the basis of UML.

The DDS plugin for the modeling tool EA supports:

•  PIM modeling for DDS

•  Conversion of PIM Model to PSM Model

•  Generation from PSM model to code

The following is an introduction to the functions and operation of EA's DDS extension.

The DDS Technology plugin's menu

The DDS Technology plug-in submenu looks like this:

General Options option of the DDS plugin

The options in the General options tab are used to specify the general behavior and QoS properties of the MDG technology used for DDS.

Qos Policy Specifications Dialog

QoS Policy Specifications:

This dialog is used to specify which Qos Policy Specifications will be used as the default classifier for QosProperty elements when a new DDS entity is created. Each policy can be specified by any of the QoS policy specifications defined for that policy.

You can use the Defaults button to automatically enable MDG Technology to assign specifications to this project.

MDG Technology for DDS AddIn requires RTIDDS or OpenSplice DDS Middleware products to be installed on the same computer, otherwise it is not possible to generate a fully executable project based on a specific DDS Middleware.

Configure RTIDDS:

Configure OpenSplice DDS

RTIDDS Options

The options in the RTIDDS option label are used to specify the behavior of the PIM-to-PSM conversion implemented by RTIDDS.

Note: The version of RTIDDS used is specified by the %NDDSHOME% environment variable.

OSPLDDS Options

The options in the OSPLDDS options tag are used to specify the behavior of the PIM-to-PSM conversion implemented by OpenSplice DDS. Note: The version of OpenSplice DDS used is specified by the %OSPL_HOME% environment variable.

Toolboxes for the DDS plugin

The following describes the Toolbox provided by the MDG technology for DDS.

•  Domain

•  Local Reconstruction

•  Types

•  QoS

•  Application Target

Domain

The Domain Toolbox provides elements and connectors for designing a data-centric publish-subscribe (DCPS) service (for DDS systems).

Toolbox	Element	Description
	Package	A package element that contains and organizes other DDS elements.
	Domain	A part element that represents the stereotype of the DDS DCPS domain.
	Domain Participant	A constructed component element that represents a DDS DCPS Domain Participant. It applies the following tag value: domain: The DDS DCPS domain in which this DomainParticipant participates.
	Subscriber	Represents the stereotyped part element of the DDS DCPS subscriber. It is modeled as a child element of a DomainParticipant and can contain one or more DataReader elements as its children.
	Data Reader	A constructed Port element that represents a DDS DCPS DataReader . It is modeled as a child element of the Subscriber and can be connected to the DDSTopic it reads.
	Publisher	Represents the construction part element of DDS DCPS Publisher. It is modeled as a child element of a DomainParticipant and can contain one or more DataWriter elements as its children.
	Data Writer	A constructed Port element that represents a DDS DCPS DataWriter . It is modeled as a child element of Publisher and can be connected to the DDS Topic it writes to.
	Qos Property	A constructed part element that represents the DDS Qos Policy of a DDS DCPS Entity. It is modeled as a child element of the following DCPS entities: •  DomainParticipant •  Subscriber •  Publisher •  DataReader •  DataWriter •  Topic The name of the attribute specifies the Qos Policy defined by the attribute. It is also specified by the type of QoS policy specification, which defines the specific properties of that policy. Tip: QoS attributes must be defined by the QoS policy specification in order to provide the correct tag value for the QoS policy. For more information about QoS policy specifications, see DDS QoS Policies.
	Topic	A part element that represents the construction of a DDS DCPS topic. A DDS topic is connected to one or more DataReader and DataWriter elements that perform the role of reading or writing data to that topic. It applies the following tagged values: •  expression: a string expression that is used as a filter (CONTENT_FILTERED) applied to that topic, or as a subscription query applied to that topic (MULTI_TOPIC) •  kind: an enumeration that represents a topic type - STANDARD, MULTI_TOPIC, CONTENT_ FILTERED •  type: type The element is an IDL class.
	Connector	A connector that connects DataReader/DataWriter to a topic

Local Reconstruction

The DLRL Toolbox provides elements and connectors for designing Data Local Reconstruction Layer (DLRL) services (for DDS systems).

Toolbox	Element	Description
	Class	A Class element that represents the construction of the DDS DLRL class. It applies the following tag values: •  mappedTopic: The DDS Topic that this DLRL class is mapped to.
	Attribute	A stereotype of an Attribute that represents an Attribute in a DLRL Class. It applies the following tagged value: mappedField: This property is a field of type DDSTopic that the DLRL read and write operation is mapped to.
	Cache	A stereotype of a Component that represents a DDS DLRL cache. It can contain one or more ObjectHome elements as its children and be associated with the DLRL class it processes.
	Object Home	A stereotype of a part, which represents a DDS DLRL ObjectHome. . It is modeled as a child of the Cache element and can be related to a set of DCPSTopic.
	Topic Manager	A port stereotype that represents a DDS DLRL TopicManager. It is modeled as a port for an ObjectHome element, and can be connected to a specific DCPS topic on behalf of its related ObjectHome.
	Filter Criterion	A stereotype of a Class element that represents a DDS DLRL FilterCriterion. It applies the following tag values: •  filterClass: The DLRL Class that implements the filterCriterion "check_object" operation.
	Relationship	Description
	Key	A stereotype of an Attribute Topic field that represents the identity of the corresponding Topic example. Some topics may have more than one key field to determine their identity.
	Foreign Key	A stereotype of an Attribute Topic field, which represents a reference to a key field of another Topic. It is used to form relationships between topics.
	Shared Key	A stereotype of an Attribute Topic field, which is both a primary key and a foreign key.
	Relation	A stereotype that represents the Association relationship between two DLRL classes.

Types

The DDS Types Toolbox provides type and feature for DDS Types diagram.

	Element	Description
	Module	Represents the stereotype of IDL Module, Class.
	Struct	Represents the stereotype of IDL Struct, Class.
	Valuetype	Represents the stereotype of IDL Valuetype, Class.
	Array	Represents the stereotype of IDL Array, Class.
	Enumeration	Represents the stereotype of IDL Enumeration , Class.
	Interface	Represents the stereotype of IDL Interface, Class.
	Sequence	Represents the stereotype of IDL Sequence, Class.
	Typedef	Represents the stereotype of IDL TypeDef, Class.
	Union	Represents the stereotype of IDL Union, Class.
	Features	Description
	Field	Represents the stereotype of IDL field, Attribute.
	Key	Represents the stereotype of the IDL field as a unique identifier (or part of).
	Foreign Key	Represents the stereotype of the IDL field, which is a key field of another IDL Element.
	Constant	Represents the stereotype of IDL Constant, Attribute.
	Method	Represents the stereotype of IDL Method, Operation.

QoS

The DDS Qos Policies Toolbox provides elements to use on the DDS Qos Policies Library diagram.

Toolbox	Element	Description
	Deadline	A stereotype of a Class element that specifies the Deadline Qos Policy . It applies the following tagged values: •  period: The duration is in nanoseconds ( the default is -1) .
	Destination Order	A stereotyped Class element that specifies the Destination Order Qos Policy. It applies the following Tagged Values: Specifies the Destination Order Qos Policy, which is a stereotype of Clas. It applies the following tagged values : •  kind : Enumeration: BY_RECEPTION_TIMESTAMP (default), BY_SOURCE_TIMESTAMP.
	Durability Service	Specifies the Durability Service Qos Policy, which is the stereotype of the class. It applies the following tag values: •  history_depth: Integer depth value (default 1) •  history_kind: Enumeration: KEEP_LAST (default), KEEP_ALL •  max_instances: Integer maximum value (default -1 to keep all instances) •  max_samples: Integer maximum samples (default -1 to keep all samples) •  max_samples_per_instance: Integer maximum samples per instance (default -1 to keep all samples per instance) •  service_cleanup_delay: duration in nanoseconds (default 0).
	Durability	A stereotyped Class element that specifies the Durability Qos Policy. It applies the following Tagged Values: •  kind : Enumeration: TRANSIENT, TRANSIENT_LOCAL, VOLATILE (default), PERSISTENT.
	Entity Factory	A stereotyped Class element that specifies the EntityFactory Qos Policy. It applies the following Tagged Values: •  autoenable_created_entities : Boolean (default true).
	Group Data	A stereotyped Class element that specifies the Groupdata Qos Policy. It applies the following Tagged Values: •  datavalue : String.
	History	A stereotyped Class element that specifies the History Qos Policy. It applies the following Tagged Values: •  depth : Integer (default 1) •  kind : Enumeration: KEEP_LAST (default), KEEP_ALL.
	Latency Budget	A stereotyped Class element that specifies the LatencyBudget Qos Policy. It applies the following Tagged Values: •  duration : duration in nanoseconds (default 0).
	Lifespan	A stereotyped Class element that specifies the Liveliness Qos Policy. It applies the following Tagged Values: •  duration : duration in nanoseconds (default 0).
	Liveliness	A stereotyped Class element that specifies the Deadline Qos Policy. It applies the following Tagged Values: •  kind : Enumeration: AUTOMATIC (default), MANUAL_BY_PARTICIPANT, MANUAL_BY_TOPIC •  lease_duration : duration in nanoseconds (default -1).
	Ownership Strength	A stereotyped Class element that specifies the Ownership Strength Qos Policy. It applies the following Tagged Values: •  value : Integer (default 0).
	Ownership	A stereotyped Class element that specifies the Ownership Qos Policy. It applies the following Tagged Values: •  kind : Enumeration: SHARED (default), EXCLUSIVE.
	Partition	A stereotyped Class element that specifies the Partition Qos Policy. It applies the following Tagged Values: •  name : String.
	Presentation	A stereotyped Class element that specifies the Presentation Qos Policy. It applies the following Tagged Values: •  access_scope : Enumeration: INSTANCE (default), TOPIC, GROUP •  coherent_access : Boolean (default false) •  ordered_access : Boolean (default false).
	Reader Data Lifecycle	A stereotyped Class element that specifies the ReaderData Lifecycle Qos Policy. It applies the following Tagged Values: •  autopurge_nowriter_samples_delay : duration in nanoseconds (default -1).
	Reliability	A stereotyped Class element that specifies the Reliability Qos Policy. It applies the following Tagged Values: •  kind : Enumeration: BEST_EFFORT (default), RELIABLE. •  max_blocking_time : Integer (default -1).
	Resource Limits	A stereotyped Class element that specifies the Resource Limits Qos Policy. It applies the following Tagged Values: •  max_instances : Integer maximum value (default -1 to keep all instances) •  max_samples : Integer maximum samples (default -1 to keep all samples) •  max_samples_per_instance : Integer maximum samples per instance (default -1 to keep all samples per instance).
	Time Based Filter	A stereotyped Class element that specifies the Time Based Filter Qos Policy. It applies the following Tagged Values: •  minimum_separation : duration in nanoseconds (default 0).
	Topic Data	A stereotyped Class element that specifies the Topic Data Qos Policy. It applies the following Tagged Values: •  value : String.
	Transport Priority	A stereotyped Class element that specifies the Transport Priority Qos Policy. It applies the following Tagged Values: •  value : Integer (default 0).
	User Data	A stereotyped Class element that specifies the User Data Qos Policy. It applies the following Tagged Values: •  value : String.
	WriterData Lifecycle	A stereotyped Class element that specifies the WriterData Lifecycle Qos Policy. It applies the following Tagged Values: •  autodispose_unregistered_instances : Boolean (default true).

Application Target

The DDS Application Toolbox provides elements and connectors to use on the DDS Application diagram.

Toolbox	Element	Description
	DDS Application	Represents the DDS application, which is the stereotype of the Component. It is used to represent a compilable software artifact for a single DomainParticipant (using the Use relation). The Application Component is a DDS application that is used by the conversion process to specify the PSM of the DDS implementation. It applies the following tagged values: •  language: An enumeration representing the target software language for this application implementation - C, C++, Java and C#。 •  platform: An enumeration representing the target implementation platform for this application implementation - i86Win32, i86JDK13。
	Connections	Description
	Domain Participant / Cache Use	The stereotype of the Dependency relationship, which represents the application's use of the DDS DomainParticipant or Cache. Many applications can use the same DomainParticipant/Cache to create heterogeneous DDS designs as needed.
	Association	An association relationship. A DLRL cache is required to associate a related DCPS DomainParticipant.

Prompt:

•  Currently, only RTIDDS conversions support C#.

Sample DDS model

In order to better understand and use DDS, we have built a model example of DDS, which is as follows:

The DDS model sample provides the following contents:

•  DDS Example Models: PIM (Platform Agnostic Models) with 2 model examples

        •  Model example 1: HelloWorld

        •  Model Example 2: Net Chat

•  PSM – OSPLDDS: Mapping of platform-dependent Model for OSPLDDS

•  PSM – RTIDDS: Mapping of platform-dependent Model for RTIDDS

•  《QosPolicyLibrary》 QoS Policies : QoS Policy Library

Let's go through each of them below.

DDS Example Models

This DDS example model exemplifies the effective use of DDS's UML Profile for modeling DDS applications.

An example of the use of UML to model the data-centric Publish-Subscribe (DCPS) layer and the data-local reconstruction layer (DLRL) to produce an executable source code model for better integration is also exemplified.

Model example 1: HelloWorld

Field Diagram: Hello World DCPS

Here's a map of the Hello World DCPS domain:

This diagram contains the data-centric publish-subscribe elements that are used in the Hello World DDS app.

This diagram defines 2 participants, one responsible for publishing and subscribing to the topic data, which is defined by the Hello World topic.

Type diagram: Hello World

This diagram contains the DCPS theme and IDL type elements of the Hello World DDS application, which defines the DDS theme and its corresponding data structure. These data structures are defined by the Hello World Type.

Application diagram: Hello World

This diagram contains the domain contributors and the application target elements that define each implementation of the Hello World app.

Each application goal defines the "usage" of the implementation by a domain actor who defines the software language and platform.

Model Example 2: Net Chat

DCPS

Domain Diagram: Net Chat DCPS Domain Diagram

This diagram contains data-centric publishing and subscribing elements. These elements are defined for the Net Chat DDS app.

This diagram defines 2 participants who can publish and subscribe to topic data, which is defined by users and message topics.

Type diagram: Net Chat

This diagram contains elements of the DCPS and IDL types of the Net Chat DDS Application, which define the topics of the DDS and their corresponding data structures (which are defined as message and user types).

DLRL

 Net Chat Local Reconstruction Diagram

This diagram contains the DLRL classes and cache elements of the Net Chat Application that define the contents of the local reconstruction, and each DLRL class defines a local reconstruction of the DCPS topic data, which is served by NetChat's cache elements that provide reconstruction services to participants in the ChatRoom realm.

Mapping

This diagram contains the DLRL class and IDL type elements of the Net Chat Application. They define the mapping between the DDRL class and the subject data. Each DLRL class defines properties that can be mapped to specific fields, which are defined in the corresponding IDL subject type. They also define the "relationships" between each other, and these relationships establish data dependencies between the 2 classes.

Application

Net Chat Application diagram

This diagram contains the Domain Participant and Application Target elements. They define each implementation of the Net Chat Application. Each Application Target defines the "usage" of a Domain Participant's implementation for a specific software programming language and platform.

PSM – OSPLDDS

Platform Specific Models (PSM)—OpenSplice DDS.

This diagram contains a collection of Model that are automatically generated for each example application. Each package contains a collection of software classes. These software classes implement each application for the Open Splice DDS platform.

PSM – RTIDDS

Platform Specific Models (PSM)—RTI DDS.

This diagram contains a collection of Model that are automatically generated for each example application. Each package contains a collection of software classes. These software classes implement each application for the RTI DDS platform.

《QosPolicyLibrary》QoS Policies

QoS Policy Library.

This diagram contains DoSe policy elements, which provide a "library" of QoS policy values for a DDS design.

By defining qosProperty items that are typed by these elements, each DCPS element can use these elements.

For more information about DDS model examples, please visit Model Library: DDS Model Samples

4、Afterword

I hope you have benefited from reading this article.

If you are interested in sharing your experience, please feel free to contribute to us, and if you are interested in our training, consulting and Tools , please learn about:

• Modeling Tools: EA

• MBSE platform:iSpace

• Course: System Design and Modeling Based on SysML and EA

• Course: System Analysis and Design Based on UML and EA

• Consulting Solution: MBSE (Model-Based Systems Engineering).

• Consulting Solution： Model-driven development based on UML

•  All modeling-related courses: http://www.mbse-x.com/course/index_en.asp

•  Consulting Solution： Model-Based Project Management

If you would like to learn more: