3. Usage

3.1. Overview

RTI Connext DDS Network Binding Library is comprised of a single directory ($NDDSHOME/resource/app/app_support/integration_toolkit_for_autosar_adaptive/rti_ara_com_binding_dds) and contains the following:

  • A C++ library implementation of the AUTOSAR Adaptive Platform DDS Network Binding

  • C++ Example applications, including their respective AUTOSAR models in ARXML format

  • Trivial implementations of AUTOSAR Adaptive Platform standard types

  • API documentation

  • CMake-based build files

3.2. Dependencies

The following sections describe the dependencies of RTI Connext DDS Network Binding Library and how to install and configure them.

3.2.1. RTI Connext

RTI Connext contains the core libraries and tools upon which RTI Connext DDS Network Binding Library is built.

RTI Connext is installed as part of Connext Drive. For more information, please refer to Installing Connext Drive.

The location of RTI Connext is commonly held in an environment variable called NDDSHOME.

3.2.2. RTI Connext AUTOSAR Runtime Adaptive Code Generator

RTI Connext AUTOSAR Runtime Adaptive Code Generator produces application-specific DDS Network Binding artifacts from AUTOSAR Adaptive ARXML exports defining:

  • Service Interfaces

  • DDS Service Interface and Instace Deployments

  • Adaptive Application SW-Cs and their ports

  • Executables

  • Mappings between all of the above

RTI Connext AUTOSAR Runtime Adaptive Code Generator is installed as part of Connext Drive. For more information, please refer to Installing Connext Drive.

3.3. Configuration

3.3.1. Configuring RTI Connext

Configuring rti-ara-com-binding-dds through CMake requires only two parameters:

  • CONNEXTDDS_DIR: installation directory of RTI Connext

  • RTIARAGEN: path to the RTI Connext AUTOSAR Runtime Adaptive Code Generator executable

So, from the rti-ara-com-binding-dds directory run:

$ mkdir build
$ cd build
$ cmake \
  -DCONNEXTDDS_DIR=$NDDSHOME \
  -DRTIARAGEN=$NDDSHOME/bin/rtiaragen \
  ..

3.3.2. Configuring RTI Connext Micro

Configuring rti-ara-com-binding-dds through CMake requires only three parameters:

  • CONNEXTDDS_MICRO_DIR: installation directory of RTI Connext Micro

  • CONNEXTDDS_ARCH: target architecture of RTI Connext Micro, matching one of the available target architectures built under CONNEXTDDS_MICRO_DIR/lib.

  • RTIARAGEN: path to the RTI Connext AUTOSAR Runtime Adaptive Code Generator executable

So, from the rti-ara-com-binding-dds directory we run:

$ mkdir build
$ cd build
$ cmake \
  -DCONNEXTDDS_MICRO_DIR=$NDDSHOME/rti_connext_dds_micro-2.4.14.3 \
  -DCONNEXTDDS_ARCH=x64Linux4gcc7.3.0 \
  -DRTIARAGEN=$NDDSHOME/bin/rtiaragen \
  ..

Replace x64Linux4gcc7.3.0 in the code above with one of the available target architectures built under CONNEXTDDS_MICRO_DIR/lib.

3.3.3. Configuring RTI Connext Cert

Configuring rti-ara-com-binding-dds through CMake requires only three parameters:

  • CONNEXTDDS_MICRO_CERT_DIR: installation directory of RTI Connext Cert

  • CONNEXTDDS_ARCH: target architecture of RTI Connext Cert, matching one of the available target architectures built under CONNEXTDDS_MICRO_CERT_DIR/lib.

  • RTIARAGEN: path to the RTI Connext AUTOSAR Runtime Adaptive Code Generator executable

So, from the rti-ara-com-binding-dds directory we run:

$ mkdir build
$ cd build
$ cmake \
  -DCONNEXTDDS_MICRO_CERT_DIR=$NDDSHOME/rti_connext_dds_micro_cert-2.4.16.0 \
  -DCONNEXTDDS_ARCH=x64Linux4gcc7.3.0 \
  -DRTIARAGEN=$NDDSHOME/bin/rtiaragen \
  ..

Replace x64Linux4gcc7.3.0 in the code above with one of the available target architectures built under CONNEXTDDS_MICRO_CERT_DIR/lib.

3.4. Build

After a successful configuration, the steps to build the library and the examples are no different from any other CMake build. Just issue the following command from <path>/rti-ara-com-binding-dds/build:

$ make

Or:

$ cmake --build .

Common CMake/make parameters for parallel builds, Release/Debug configuration, target enumeration and selection, etc. can also be used.

Upon build completion, executables and deployment configuration should now exist under <path>/rti-ara-com-binding-dds/build/examples.

3.5. Examples

Shipped examples are structured as follows:

  • Feature-oriented examples:

    • examples/discovery: example client and server applications demonstrating dynamic Service Instance discovery.

    • examples/events: example client and server applications demonstrating event-based communication (static discovery, i.e. client and server use a pre-agreed instance identifier).

    • examples/fields: example client and server applications demonstrating field-based communication through notifiers, getters and setters (static discovery, as above).

    • examples/methods: example client and server applications demonstrating regular and fire-and-forget method-based communication (static discovery, as above).

    • examples/triggers: example client and server applications demonstrating regular and fire-and-forget trigger-based communication (static discovery, as above).

  • Use case-oriented examples:

    • examples/lights: example client (dashboard, steering) and server (master) applications immitating interactions in a lightning control system:

    • dashboard is a display-only component, showing the different status of the lightning system to the driver

    • steering represents the lightning controls in or around the steering wheel, like turning on low or high beam.

    • master represents the master lightning controller, sending status information to all the other components, and receiving requests from steering.

3.5.1. Running examples

After a complete build is successful, executables can be run from any directory, but it is advisable to do so from the directories contained under <path>/rti-ara-com-binding-dds/deployment, where run-time deployment configurations are located. If those are not found, the applications will still run, but default values will be selected when setting up service instances, possibly leading to malfunction.

  • Feature-oriented examples above shall be run from deployment/standard, preferrably in different terminal sessions to observe interactions side by side. For example:

    terminal-1$ cd deployment/standard
terminal-1$ ../../build/examples/discovery_proxy
terminal-2$ cd deployment/standard
terminal-2$ ../../build/examples/discovery_skeleton

A similar approach can be used for events, fields, methods and triggers examples.

  • The case-oriented example above shall be run from deployment/lightning, preferrably in different terminal sessions to observe interactions side by side:

    terminal-1$ cd deployment/lightning
terminal-1$ ../../build/examples/lights/master
terminal-2$ cd deployment/lightning
terminal-2$ ../../build/examples/lights/steering
terminal-3$ cd deployment/lightning
terminal-3$ ../../build/examples/lights/dashboard

3.6. API documentation

Complete documentation of all library APIs can be found in the installation folder of Connext Drive.