Developer Workflow¶

This guide describes the SysML-based development workflow for creating and deploying GVA-compliant data interfaces using the Land Data Model (LDM) SDK and Bohemian.

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.

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++ → Qt wrappers) ready for integration.

The MDA Translation Process¶

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 and Validate with Bohemian¶

Open your Rhapsody project in Bohemian to explore and validate the model:

./build/bin/bohemian /path/to/project.rpyx

Navigate the model tree to verify:

• All classes have proper attributes and types
• Associations are correctly defined
• Operations have appropriate parameters
• State diagrams are complete

Step 3: Export IDL Files¶

Use Bohemian to generate IDL files:

Interactive Mode:

1. Open the project in Bohemian
2. Select File > Export IDL...
3. Choose the output directory
4. Click Export

Command Line Mode:

./build/bin/bohemian --export-idl ./ldm/UK/GVA/v10.0.0/IDL /path/to/project.rpyx

Step 4: Compile IDL with AstuteDDS¶

Use the astutedds-idl compiler to generate C++ types from your IDL files:

# Generate C++ code from IDL files
astutedds-idl -o ./generated/cpp -I ./ldm/UK/GVA/v10.0.0/IDL mymodule.idl

# Generate with verbose output
astutedds-idl -v -o ./generated/cpp -I ./includes shapes.idl

# Generate Python bindings instead
astutedds-idl -l python -o ./generated/python mymodule.idl

# Generate C code
astutedds-idl -l c -o ./generated/c mymodule.idl

AstuteDDS IDL Compiler Options¶

Step 5: Build the LDM SDK¶

The LDM SDK automatically compiles IDL files and generates Qt wrappers:

cd /path/to/ldm
mkdir -p build && cd build
cmake ..
make -j$(nproc)

Step 6: Use Generated Code¶

Include the generated Qt wrapper classes in your application:

#include "QtWrapperCSensorPubSub.h"

// Create a publisher
auto publisher = std::make_unique<ldm::pubsub::QtDdsPublisherCSensor>(
    domainId, P_Sensors_PSM::KC_Sensor_TopicName, 
    ldm::pubsub::LdmMessagePattern::eState);

// Connect signals
connect(publisher.get(), &ldm::pubsub::QtDdsPublisherCSensor::OnSamplePublished,
        this, &MyClass::onPublished);

// Publish data
P_Sensors_PSM::C_Sensor sensorData;
sensorData.A_Temperature(25.0f);
publisher->publish(sensorData);

LDM Translation Rules¶

The translators apply consistent naming conventions:

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¶

Official LDM documentation, SysML models, and tools are available from the Land Open Systems Architecture (LOSA) Portal:

• Portal: https://landopensystems.mod.gov.uk
• LDM Repository: https://gitlab.landopensystems.mod.gov.uk

Key Documents¶

The following documents are available from the LOSA Portal:

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