External Applications

External Applications

The GVA architecture supports integration of external applications through a standardised DDS-based interface. This enables third-party software to operate within the vehicle environment while maintaining system integrity.

Overview

External applications can:

  • Display content in the HMI control area
  • Receive user input via soft keys
  • Access GVA services (Registration, Alarms, UACM)
  • Communicate with other systems via DDS

Two Approaches to External Application Integration

The UK MOD's Generic Vehicle Architecture (GVA) standard, through DEF STAN 23-009 and the Land Data Model (LDM), defines a Display Extension Service Specification (v1.1, February 2024) — a DDS-based protocol allowing third-party applications to inject widgets into a host HMI without modifying its source code.

There are two fundamentally different approaches to implementing this integration:

Traditional Approach: Co-located Widget Sessions

The GVA Display Extension specification defines a layered architecture where third-party applications coexist on the same compute node as the HMI. They communicate via DDS shared-memory transport, publishing createWidget, setText, or sendImageData commands. The HMI subscribes to these messages, renders the requested widgets, and fires user interaction events back.

While this achieves interface decoupling via message passing, it introduces practical constraints:

  • Co-location required — Large image transfers rely on shared-memory transport, meaning apps run on the same machine as the HMI
  • No spatial arbitration — Multiple sessions can create overlapping widgets without enforcement
  • Limited widget types — Five fixed types (Text, Table, Image, PPI, Video) with no custom rendering
  • HMI lifecycle coupling — If the HMI restarts, all sessions are lost and must re-register

Astute Systems Approach: True Network Decoupling

The ATLAS HMI implements the full Display Extension protocol with a critical architectural difference: third-party applications are genuinely headless services communicating over the network via UDP multicast, not co-located processes sharing compute.

Key advantages:

  • Deploy anywhere — Sensor apps run on their own embedded compute (Cortex-A class), no GPU required
  • Keep-out enforcement — DisplayExtensionManager allocates screen real estate per functional area, preventing widget overlap
  • Hot-swap capabilities — Add/remove sensors by connecting/disconnecting nodes, zero HMI code changes
  • Multi-display support — One headless app serves Commander, Gunner, and remote displays simultaneously
  • F17 integration — The HMI transparently handles label toggle zoom without app awareness
Metric Traditional Astute External Widgets
Adding a new sensor display HMI rebuild + re-certification Deploy headless app — zero HMI changes
UOR integration timeline 6–18 months Days to weeks
Sensor node hardware Requires GPU + display stack Headless — MCU/SBC class sufficient
Multi-crew-station support Separate app per display Single app serves all displays
Widget isolation None — overlaps possible Keep-out enforced per functional area
Network topology Same machine mandatory Any node on vehicle DDS domain

Comparison Diagram

The following diagram compares the traditional monolithic approach (left) against the Astute Systems external widget architecture (right), including the Astute Inspect debugging tool:

GVA Display Extension — Traditional vs External Widget Architecture

Architecture Detail

This diagram shows the DDS network fabric and how headless applications communicate with the HMI via Astute DDS:

External Widget Architecture

Integration Architecture

graph TB subgraph "HMI" CA[Control Area] SK[Soft Keys] FS[Function Select] end subgraph "External App" APP[Application Logic] REN[Renderer] INP[Input Handler] end subgraph "GVA Services" REG[Registration] ALM[Alarms] UACM[UACM] end subgraph "DDS Network" DDS((DDS)) end APP --> REG APP --> ALM APP --> UACM REN -->|Display Data| DDS DDS -->|Display Data| CA SK -->|Key Events| DDS DDS -->|Key Events| INP FS -->|Select App| DDS DDS -->|Activate| APP

Message Sequence

Application Lifecycle

sequenceDiagram participant App as External App participant DDS as DDS Network participant Reg as Registration participant HMI as HMI participant Op as Operator Note over App: Application starts App->>DDS: Register application DDS->>Reg: Store registration DDS->>HMI: Update app list HMI->>HMI: Add to Function Select Note over Op: Operator selects app Op->>HMI: Press Function Select HMI->>DDS: FunctionSelect event DDS->>App: Application activated Note over App: Application active App->>DDS: Publish display data DDS->>HMI: Render in Control Area loop User interaction Op->>HMI: Press soft key HMI->>DDS: KeyEvent DDS->>App: Handle key App->>DDS: Update display DDS->>HMI: Refresh display end Note over Op: Operator switches app Op->>HMI: Select different function HMI->>DDS: FunctionSelect event DDS->>App: Application deactivated App->>App: Pause/save state Note over App: Application stops App->>DDS: Deregister DDS->>Reg: Remove registration DDS->>HMI: Update app list

Display Rendering

sequenceDiagram participant App as External App participant DDS as DDS Network participant HMI as HMI participant GPU as Renderer Note over App: Render frame App->>App: Generate graphics commands App->>DDS: Publish DisplayData Note right of App: drawCommands[],
width, height,
timestamp DDS->>HMI: Receive DisplayData HMI->>GPU: Execute draw commands GPU->>GPU: Clear control area loop For each command GPU->>GPU: Parse command alt DrawRect GPU->>GPU: Draw rectangle else DrawText GPU->>GPU: Render text else DrawImage GPU->>GPU: Blit image else DrawLine GPU->>GPU: Draw line end end GPU->>HMI: Frame complete HMI->>HMI: Swap buffers

Soft Key Handling

sequenceDiagram participant Op as Operator participant HMI as HMI participant DDS as DDS Network participant App as External App Note over App: App requests key labels App->>DDS: Publish SoftKeyConfig Note right of App: key[0]="ZOOM IN"
key[1]="ZOOM OUT"
key[2]=""
key[3]="EXIT" DDS->>HMI: Update key labels HMI->>HMI: Display labels Note over Op: Operator presses key Op->>HMI: Press Soft Key 1 HMI->>DDS: Publish KeyEvent Note right of HMI: keyId=1,
state=PRESSED DDS->>App: Receive KeyEvent App->>App: Handle zoom out App->>DDS: Update display HMI->>DDS: Publish KeyEvent Note right of HMI: keyId=1,
state=RELEASED DDS->>App: Key released

External Application Interface

Display Data

Field Type Description
applicationId string Unique application ID
width int Display width in pixels
height int Display height in pixels
commands list Draw command list
timestamp datetime Frame time

Draw Commands

Command Description
CLEAR Clear display area
RECT Draw rectangle outline
FILLED_RECT Draw filled rectangle
LINE Draw line
TEXT Draw text
IMAGE Draw image/sprite
ARC Draw arc
POLYGON Draw polygon

Soft Key Configuration

Field Type Description
applicationId string Application ID
keys array[6] Key label strings
enabled array[6] Key enabled flags

Key Events

Field Type Description
applicationId string Target application
keyId int Key number (0-5)
state enum PRESSED, RELEASED
timestamp datetime Event time

Application Types

Information Display

Applications that display static or slowly-changing information:

  • Map overlays
  • System status displays
  • Documentation viewers
  • Reference tables

Interactive Tools

Applications requiring user input:

  • Configuration editors
  • Diagnostic tools
  • Planning aids
  • Communication interfaces

Games and Training

Applications for operator training and entertainment:

  • Simulation games
  • Training scenarios
  • Skill development tools

Best Practices

Registration

  1. Register immediately - Don't delay registration
  2. Unique application ID - Use organisation prefix
  3. Meaningful name - Operators see this in menus

Display

  1. Respect boundaries - Stay within control area
  2. Consistent styling - Match GVA visual language
  3. Efficient rendering - Minimise draw commands
  4. Handle resize - Support different display sizes

Input Handling

  1. Clear key labels - Max 8 characters
  2. Disable unused keys - Set enabled=false
  3. Responsive feedback - Update display quickly

Resource Management

  1. Clean shutdown - Deregister properly
  2. Memory efficiency - Don't leak resources
  3. CPU considerate - Yield when inactive

Troubleshooting

Application Not Listed

  • Check registration is published
  • Verify systemType is APPLICATION
  • Ensure HMI is receiving registrations

Display Not Updating

  • Verify application is active
  • Check DisplayData topic
  • Ensure timestamp is updating

Keys Not Responding

  • Check KeyEvent topic subscription
  • Verify applicationId filter
  • Ensure SoftKeyConfig is published