deploy dds applications -凯发k8网页登录

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:

ensure that your model is configured correctly. verify that the model ports are configured and mapped appropriately for dds. for more information, see .
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. if your target vendor is eprosima, additional setup is not required. if your target vendor is rti, you must also install rti connext. for more information, see dds blockset system requirements.
build the application model. on the dds tab, click build.
run the executable and connect your application to the dds network.

overview of generated files

when you build your dds application model, the following folders and files are generated in your current working folder:

application executable — the executable that you can deploy to connect the application to the dds network.
embedded coder build folder — the generated c code files.
simulink project folder (slprj) — the model simulation files.
simulink data dictionary file — the associated dds dictionary (.sldd) file.
dds application model — the simulink model for the application.
exported xml/idl file — the xml/idl specifications of your dds application.

display of current folder containing generated folders and files.

you can use these generated files to analyze, deploy, and port your dds application. additionally, you can use the packngo functionality to relocate and rebuild your application.

portability of dds applications

to relocate, unpack, and rebuild your dds application in another development environment, you can use packngo. the packngo function enables you to relocate files so that you can recompile for a specific target environment or rebuild in a development environment where matlab^® is not installed. by default, the function packages the files as a flat folder structure in a zip file within the code generation folder. after you relocate the zip file, use a standard zip utility to unpack the compressed file.

to configure your model to build with packngo:

open the configuration parameters dialog box.
select pack code and artifacts.
on the toolstrip, click build.

for more information, see (embedded coder).

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.

to programmatically configure the class name and class namespace, use the embedded coder api functions (embedded coder), (embedded coder), (embedded coder), and (embedded coder). for more information, see (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 .

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 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 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.

deploy dds applications -凯发k8网页登录