Main Content

Deploy DDS Applications

DDS Blockset connects applications modeled in Simulink® to DDS by providing out-of-the-box support for the DDS vendors RTI and eProsima. To use out-of-the-box DDS, create and model a DDS application in Simulink, set up the environment, and use Embedded Coder® to build the application model. The build creates exported XML, generated C++ code, and an application executable that you can use to directly connect to the DDS network.

Build and Deploy DDS Applications

To deploy your application on the DDS network:

  1. Ensure that your model is configured correctly. Verify that the model ports are configured and mapped appropriately for DDS. For more information, see Interactively Configure DDS Interface.

  2. Set up the environment.

    • DDS Blockset generates an executable specific to the DDS vendor that you select, RTI or eProsima. To verify or change your vendor selection, you can use the Configuration Parameters dialog box to review the toolchain setting for your application.

    • To build an executable of your application, set up your environment in a supported platform with a supported C++ compiler. You can use the mex -setup C++ command in the MATLAB® Command Window to verify which compiler you are using. For compiler requirements for each platform, see DDS Blockset System Requirements.

    • If your target vendor is eProsima, no additional setup is required besides ensuring your path includes the eProsima dynamic linked libraries. For example, in the MATLAB Command Window, you can enter this to include the libraries in your path: 

      setenv('PATH',[getenv('PATH') ';' fullfile(matlabroot,'sys','FastDDS','win64','bin')])

    • If your target vendor is RTI, you must also install RTI Connext. For more information, see DDS Blockset System Requirements.

  3. Build the application model. On the DDS tab, click Build.

  4. Run the executable.

Overview of Generated Files

When you build your DDS application model, these folders are generated in your current working folder:

  • model_ert_rtw — Embedded Coder build folder. This folder contains the generated C++ code files and build subfolders:

    • exe — Application executable folder. This folder contains the executable and deployment support files.

    • services — Services folder. This folder contains the service code interface files, including .hpp header files and static library files.

  • slprj — Simulink shared folder. This folder contains generated files that can or must be shared between multiple models. For more information, see Build Process Folders (Embedded Coder).

Display of current folder containing generated folders and files.

In the exe folder that contains the executable and other deployment files, DDS Blockset code generation exports an XML file containing the exported DDS definitions. For applications that use the eProsima vendor, the generated XML file includes locator elements (within <locator> </locator> XML tags). If needed, you can suppress the locator elements from being exported by setting the environment variable DO_NOT_USE_LOCATORS to a nonzero number. For example, in the MATLAB Command Window, enter:

setenv('DO_NOT_USE_LOCATORS', '1');

You can use the generated files to analyze, deploy, and port your DDS application.

Implementation Details and Generated C++ Code

The implementation of DDS is specified by the Object Management Group (OMG) standard and implemented by several vendors in several different programming languages. The DDS Blockset provides out-of-the box integration with the DDS vendors RTI and eProsima. Specifically, the blockset supports the C++ implementation of the DDS standard provided by RTI and eProsima. If you are interested in these vendor APIs, refer to your vendor documentation.

The basic architecture of the generated C++ code is that the application is composed of message classes, vendor helper classes, and the main file. The message classes enable the application to send and receive data. The vendor helper classes are specific to the vendor and load the application profile, register the data types, create and initialize the DDS entities, and wrap the send and receive message classes specific to the vendor API. The main file then performs the application logic. If you would like to examine the generated C++ code, view the Embedded Coder build folder.

Generated C++ Class Name and Namespace Customization

If you would like to customize the generated C++ code for your DDS application, you can control the generated class name and namespace for your DDS application model interactively or programmatically.

To interactively configure these aspects of the generated code, from an open model, on the DDS tab, click Code Interface, select Class Name & Namespace, and customize the names in the opened configuration dialog box.

Dialog box for configuring C++ class name and namespace.

For more information, see Configure class namespace (Embedded Coder).

Debug and Troubleshoot

A few common build issues you can troubleshoot are the following:

Incorrect environment setup

  • Description — If you select RTI as your vendor but do not install RTI Connext, then you are unable to deploy your application.

  • Action — Download and install RTI Connext.

Missing or invalid mapping for inports and outports in application model

  • Description — If the inports or outports have not been configured correctly the model does not build.

  • Action — Map the inports and outports in the application model to DDS Topics and configure the ports with the corresponding DDS data types.

Inconsistent data management of the DDS definitions

  • Description — If you map an inport or an outport to a Topic and then delete or change the data type for the Topic the model does not build.

  • Action — Verify that the DDS definitions are available in the associated DDS Dictionary.

Considerations and Limitations

  • RTI Connext Micro Adapter — The default network interface names for your system may differ from the default interface names used in the RTI Connext Micro Adapter, RTIMicroAdapter.hpp. In such cases, the participant may not initialize properly. Check and update the strings used for the names and manually rebuild the executable.

  • RTI Connext Micro DataReader and DataWriter capacity limits — The default number of allocated DataReaders (remote_reader_allocation) and DataWriters (remote_writer_allocation) for an application is 48. Depending on other DDS applications running and your network conditions, the number of readers and writers my exceed 48. You can configure the RTIMicroQosDefn.inl to increase this limit or you can change to a Domain where less readers and writers are currently occupied.

  • Folder Names with Special Characters — The build process might produce an error if a build-related folder path contains:

    • Unicode characters that do not belong to the system locale.

    • A Japanese (multibyte) character where the final byte is equal to the 5c hexadecimal character. The make and compiler tools might incorrectly interpret the final byte as the '\' (backslash) character.

  • DDS Model Hierarchy Configuration — DDS Blockset requires configuration parameter settings to be consistent throughout the model hierarchy, including configuration settings for referenced models. Referenced configuration sets are not supported. Before building and generating code, ensure that configuration settings for models and model references in the hierarchy are consistent.

  • DDS Target Specification — DDS Blockset does not support compiling the code generated from a DDS application model for a non-DDS application.

  • DDS Definitions — The DDS Topics and QoS for your application are retrieved from the DDS Dictionary associated with your application model. Ensure that this dictionary is on your MATLAB path to appropriately build your model.

  • Code Generation Data Types — The generated C++ code does not provide support for certain data types. Multidimensional arrays are not supported for code generation.

  • Security — There are security risks inherent in communication platforms. These risks include the potential of malicious users to attempt to listen to or spoof DDS communication. Additionally, late-joining readers can potentially access previously transmitted data. To increase protection against these security risks, download and use the secure version of your vendor. The version of eProsima included with DDS Blockset is not the secure version.

Related Topics

External Websites