Generating Custom IDL

Generating Custom IDL

This guide covers extending the LDM with your own SysML-modelled data types, and using the resulting generated C++ types in your own application. It's written for customers modelling their own data on top of an LDM/AstuteDDS system.

For viewing/validating a Rhapsody model, exporting IDL, and compiling it with astutedds-idl, see the Bohemian SysML Viewer guide — that guide is the canonical reference for the tool itself. This page picks up from there: what the generated naming conventions mean, and how to actually use the compiled types in a DDS application.

If you only need to write a DDS client against the existing published LDM release (no new IDL of your own), see the LDM SDK Reference instead.

Overview

The LDM uses a Model Driven Architecture (MDA) approach where data models are created as Platform Independent Models (PIMs) in SysML/UML, then automatically translated to deployable code for DDS communication.

flowchart LR subgraph Design["Design Phase"] A[SysML Model
IBM Rhapsody] --> B[Platform Independent
Model PIM] end subgraph Transform["Translation Phase"] B --> C[Platform Specific
Model PSM] C --> D[OMG IDL Files] end subgraph Deploy["Deployment Phase"] D --> E[C++ Types
AstuteDDS] E --> F[Your Application] end

Key Concepts

Platform Independent Model (PIM)

The PIM captures the data requirements without any implementation details. It defines:

  • Classes: Data structures representing entities (sensors, actuators, vehicles)
  • Attributes: Properties of each class
  • Operations: Commands that can be sent to entities
  • Associations: Relationships between classes
  • Types: Enumerations, structures, and typedefs

Platform Specific Model (PSM)

The PSM is automatically generated from the PIM and adds DDS-specific elements:

  • Topic types with DDS annotations
  • Key fields for instance identification
  • Command and response structures
  • Metadata for tracking

Platform Specific Implementation (PSI)

The final generated code (IDL → C++) ready for integration into your application.

The MDA Translation Process

flowchart TD subgraph PIM["Platform Independent Model"] UC[Use Cases] --> DOM[Domain Model] DOM --> SEQ[Sequence Diagrams] SEQ --> CLASS[Class Diagrams] CLASS --> STATE[State Diagrams] end subgraph PSM["Platform Specific Model"] CLASS --> |PIM Translator| PSMCLASS[PSM Classes] STATE --> |PIM Translator| PSMSTATE[State Types] end subgraph PSI["Platform Specific Implementation"] PSMCLASS --> |PSM Translator| IDL[IDL Files] PSMSTATE --> |PSM Translator| IDL IDL --> |astutedds-idl| CPP[C++ Types] end

Workflow with Bohemian

Bohemian simplifies the translation process by providing a graphical interface for viewing Rhapsody models and generating IDL files directly.

Step 1: Design Your Model

Create your SysML model in IBM Rhapsody following the LDM Methodology:

  1. Define Use Cases describing system capabilities
  2. Create a Domain Model partitioning the system into subject areas
  3. Design Sequence Diagrams showing interactions
  4. Build Class Models defining data structures
  5. Add State Models for stateful entities

Step 2: View, Export, and Compile with Bohemian

Open your model in Bohemian to validate its structure, export it to IDL, and compile the IDL into C++ types with astutedds-idl. These steps — and the full command-line reference for both tools — are covered in the Bohemian SysML Viewer guide:

Step 3: Use Generated Code in Your Own Project

astutedds-idl generates plain C++ DDS-PSM-CXX types only — it does not generate the internal QtWrapper*PubSub.h Qt-signal wrapper classes used by the shipped ATLAS/TALOS/HERMES applications. Those wrappers are produced by an internal CMake macro that requires the full GVA product line source tree; they are not something the packaged astutedds-idl compiler or ldm-sdk produces on their own.

For your own application, use the generated types with a plain AstuteDDS publisher/subscriber, the same way the LDM SDK examples do:

#include <dds/dds.hpp>
#include "P_Sensors_PSM.h"   // generated from your exported IDL

dds::domain::DomainParticipant participant(domainId);
dds::topic::Topic<P_Sensors_PSM::C_Sensor> topic(
    participant, P_Sensors_PSM::KC_Sensor_TopicName);
dds::pub::Publisher publisher(participant);
dds::pub::DataWriter<P_Sensors_PSM::C_Sensor> writer(
    publisher, topic, writer_qos_for_topic(topic.name()));

P_Sensors_PSM::C_Sensor sensor_data;
sensor_data.A_Temperature(25.0f);
writer.write(sensor_data);

Use the gva_qos.hpp / gva_command_response.hpp helpers shipped with ldm-sdk (see Common helpers) to resolve the correct QoS for your topic's pattern, and to drive command/response pairs — rather than hand-rolling QoS or a response wait loop. Remember to complete platform registration (see Registration — basic flow) before publishing anything else.

LDM Translation Rules

The translators apply consistent naming conventions:

SysML Element IDL Naming Example
Package P_<PackageName> P_Alarms_PSM
Class C_<ClassName> C_Alarm
Type (Enum) T_<TypeName> T_AlarmType
Type (Struct) T_<TypeName> T_Position
Attribute A_<AttributeName> A_Severity
Enum Literal L_<LiteralName> L_Warning
Topic Constant KC_<Class>_TopicName KC_Alarm_TopicName

DDS Annotations

The PSM Translator adds DDS X-Types annotations for extensibility:

  • @mutable: Allows adding/removing optional fields
  • @key: Marks fields used for instance identification
  • @optional: Fields that may not be present
  • @autoid(HASH): Automatic member ID generation

Reference Documentation

For the official LDM Methodology and Modelling Standard, the GVA Translator Guide, and other modelling reference documents from the LOSA Portal, see Related Documentation in the Bohemian guide.

Best Practices

Model Design

  1. One domain, one subject: Keep each domain focused on a single subject matter
  2. Avoid pollution: Don't mix application logic with technology-specific details
  3. Use counterparts: Represent the same entity in different domains using counterpart classes
  4. Follow naming conventions: Use the LDM naming patterns consistently

Development Workflow

  1. Validate early: Use Bohemian to check model structure before export
  2. Incremental changes: Make small, focused changes to the model
  3. Test generated code: Build and test after each model change
  4. Version control: Track both model files and generated IDL

Deployment

  1. Match QoS policies: Use appropriate DDS QoS for each topic type
  2. Register resources: All resources must register with the GVA Registry
  3. Handle extensibility: Use X-Types annotations for forward compatibility