Overview

ATLAS Services Overview

ATLAS

ATLAS

The ATLAS suite includes a set of GVA services that run alongside the HMI to provide system discovery, alarm management, and usage monitoring. These services implement the core service layer defined by DEF STAN 23-009, enabling any GVA-compliant application to register, publish alarms, and report health status over DDS without vendor-specific integration.

The Problem

Without a shared service layer, every vehicle subsystem must implement its own discovery handshake, alarm routing, and health reporting — leading to duplicated logic, inconsistent behaviour, and integration headaches when subsystems from different vendors are combined on the same platform.

How ATLAS Services Solve It

ATLAS ships three lightweight, standalone service daemons (Registry, Alarms, UACM) that own the service contract for the entire vehicle. Subsystems register once over DDS and immediately gain alarm annunciation, heartbeat monitoring, and usage tracking. The services run as systemd units, start in any order after the registry, and require zero configuration beyond a shared DDS domain ID.

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[TALOS] 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 converts LRU-reported conditions into platform alarms, keeps the Alarm Register, and drives crew annunciation per Def Stan 23-009 Alarms Service Specification v3.0.

Key Functions:

  • Subscribes to C_Alarm_Condition samples raised by LRUs
  • Owns the platform Alarm state machine and publishes C_Alarm
  • Persists the Alarm Register (PostGIS) across power cycles
  • Publishes the Warning / Caution / Advisory category taxonomy
  • Drives Annunciation LDM audio + visual events
  • Processes Acknowledge / Clear / Annotate / Override / Remove Override commands with CRP responses

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 LRU as LRU (subsystem) participant Reg as Registry participant Alm as Alarms participant UACM as UACM participant HMI as HMI Note over LRU,HMI: Application Startup LRU->>Reg: Register(systemId, capabilities) Reg-->>LRU: Acknowledged LRU->>UACM: Report(usageHours) Note over LRU,HMI: During Operation — a fault occurs LRU->>Alm: C_Alarm_Condition (Active) Alm->>Alm: Raise alarm, persist register Alm->>HMI: C_Alarm (Active_Unacknowledged) Alm->>HMI: C_Annunciation_startEvent HMI->>Alm: C_Alarm_acknowledge Alm-->>HMI: Command Response Note over LRU,HMI: Fault resolves LRU->>Alm: C_Alarm_Condition (Inactive) Alm->>HMI: C_Alarm (Resolved) Note over LRU,HMI: Shutdown LRU->>Reg: Deregister()

Running Services

Start All Services

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

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

# Start UACM service
./bin/gva-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

Configuration file locations and overrides

Registry, Alarms, and UACM each read a JSON policy/spec file at startup. All three follow the same convention:

Service Packaged default Operator override (never overwritten)
Registry /etc/gva/registry/platform-config.json /etc/gva/registry/platform-config.local.json
Alarms /etc/gva/alarms/alarm_specifications.json /etc/gva/alarms/alarm_specifications.local.json
UACM /etc/gva/uacm/uacm_specifications.json /etc/gva/uacm/uacm_specifications.local.json

Resolution order (highest to lowest precedence):

  1. --config/-c on the command line.
  2. The .local.json override file, if present. This file is never shipped by the package, so it survives every upgrade — create it to customise a service's configuration without editing the package-owned default in place.
  3. The packaged default .json file. Overwritten on every package upgrade.
  4. Built-in fallback behaviour if neither file exists (see each service's own Configuration section for what that fallback looks like).

See Registration, Alarms, and UACM for the file schema each service expects.

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-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