Overview

GVA Services Overview

The GVA (Generic Vehicle Architecture) framework defines several core services that enable interoperable vehicle systems. The LDM SDK provides complete implementations of these services.

Service Architecture

graph TB subgraph "GVA Service Layer" REG[Registration Service] ALM[Alarms Service] UACM[UACM Service] TILES[Tile Server] end subgraph "DDS Middleware" DDS[(DDS Domain)] end subgraph "Applications" HMI[HMI Application] BMS[BMS Application] EXT[External Apps] end REG <--> DDS ALM <--> DDS UACM <--> DDS HMI <--> DDS BMS <--> DDS EXT <--> DDS TILES --> BMS TILES --> HMI style REG fill:#4CAF50 style ALM fill:#f44336 style UACM fill:#2196F3 style TILES fill:#9C27B0

Core Services

Registration Service

The Registration Service manages system discovery and health monitoring across the GVA network.

Key Functions:

  • System registration and deregistration
  • Capability advertisement
  • Health status monitoring
  • Heartbeat management

Learn more about Registration →

Alarms Service

The Alarms Service provides standardised alarm management with priority queuing and acknowledgement handling.

Key Functions:

  • Alarm raising and clearing
  • Priority-based queuing (Warning > Caution > Advisory)
  • Acknowledgement tracking
  • Audio/visual annunciation

Learn more about Alarms →

UACM Service

The Usage and Condition Monitoring (UACM) Service tracks equipment usage and system health for maintenance planning.

Key Functions:

  • Usage hour tracking
  • Fault recording
  • Maintenance scheduling
  • Data persistence

Learn more about UACM →

Tile Server

The Tile Server provides offline map tile syncing and local HTTP serving for the BMS and HMI applications.

Key Functions:

  • Pre-download map tiles for specified geographic areas
  • HTTP tile serving on port 8070 (XYZ slippy map format)
  • Support for 50+ tile sources (OSM, ESRI, Sentinel-2, Geoscience Australia, etc.)
  • OAuth2 authentication for Copernicus Data Space
  • Licence-compliant offline caching of free and open data sources

Learn more about Tile Server →

Service Interaction

All GVA services communicate via DDS (Data Distribution Service) topics. This enables:

  • Loose Coupling: Services operate independently
  • Scalability: Multiple instances can run concurrently
  • Reliability: QoS policies ensure message delivery
  • Interoperability: Any DDS-compliant system can participate
sequenceDiagram participant App as Application participant Reg as Registry participant Alm as Alarms participant UACM as UACM Note over App,UACM: Application Startup App->>Reg: Register(systemId, capabilities) Reg-->>App: Acknowledged App->>UACM: Report(usageHours) Note over App,UACM: During Operation App->>Alm: RaiseAlarm(warning, "Engine overheat") Alm-->>App: AlarmId assigned App->>Reg: Heartbeat() Note over App,UACM: Shutdown App->>Alm: ClearAlarm(alarmId) App->>Reg: Deregister()

Running Services

Start All Services

# Start registry (must be first)
./bin/gva-qt6-registry &

# Start alarms service
./bin/gva-qt6-alarms &

# Start UACM service
./bin/gva-qt6-uacm &

# Start tile server
./bin/gva-tile-server &

Using the HMI Script

A convenience script starts all services with the HMI:

./run_gva.sh

Service Configuration

Services can be configured via:

  1. Command line arguments
  2. Environment variables
  3. Configuration files

DDS Domain

All services must use the same DDS domain:

# Set domain via environment
export LDM_DOMAIN_ID=0

Logging

Control log verbosity:

# Enable debug logging
export GLOG_v=2
./bin/gva-qt6-registry

Best Practices

  1. Always register your application with the Registry
  2. Send heartbeats at regular intervals (default: 5 seconds)
  3. Handle alarms appropriately based on category
  4. Report usage to UACM for maintenance tracking
  5. Deregister cleanly on application shutdown