What Is SOLM (Satellite Operations Language Metamodel)?

solm · ground-systems · standards

Historically, exchanging spacecraft operation procedures between satellite manufacturers (integrators) and ground station operators has been a fragmented process — proprietary scripting languages, non-standardized flowcharts, text manuals. Published by the Object Management Group (OMG), SOLM 1.1 addresses this interoperability problem by defining a Platform Independent Model (PIM) for spacecraft operational procedures.

With SOLM, procedures written for command transmission, telemetry verification, and ground system configuration can be transferred across different ground systems, or executed directly, without vendor lock-in.

Architecture: the M2 Metamodel Layer

SOLM functions as an M2 metamodel layer within the standard Model-Driven Architecture (MDA) framework:

• M2 Layer (SOLM Metamodel) — defines the core language rules, structures, and semantic elements (Commands, Parameters, Activities, etc.)
• M1 Layer (PIM Models) — the actual operational procedures designed for a specific spacecraft
• M0 Layer (Execution/Runtime) — the execution instance of a procedure, populated with real-time parameter values and timestamps

The Five Core Packages

1. Procedure Invocation — procedure definitions and invocation structures

• ModeledProcedure: procedures represented through structured UML activity models
• NativeProcedure: procedures written directly in the ground system's native scripting language
• ProcedureArgument: input/output arguments passed to procedures

2. Activities — execution control logic and activity flows

• ControlFlow & ObjectFlow: direct the execution sequence and data pass-through
• DecisionNode, MergeNode, ForkNode, JoinNode: conditional logic, branching, and multi-threaded parallel execution

3. Parameters — spacecraft and ground system parameters

• XtceParameter: telemetry and command definitions aligned with the XTCE standard
• GemsParameter & GroundParameter: ground equipment parameter references
• Time, SpecificTime, TimeInterval: time representation for scheduled delays and execution intervals

4. Command Transmission — command and directive delivery

• Command & CommandArgument: telecommands sent directly to the spacecraft
• Directive: instructions issued to ground station hardware or support equipment

5. Procedure Actions — atomic operations performed within procedure steps

• Send: transmits commands or directives
• Verify, VerifyExpression, VerifyRange: validates telemetry values against expected bounds
• Wait, WaitOnTime, WaitOnExpression: pauses execution until specific conditions or time intervals are met

Conformance Levels

Ground systems implementing SOLM can claim compliance across three levels:

Level	Required features & capabilities
Level 1	Conditionals, loops, timed waits, XTCE object support, NativeProcedure invocations, exception handling
Level 2	Everything in Level 1, plus GEMS equipment parameters and directives
Level 3	Everything in Level 2, plus parallel execution threads within a procedure

Mapping SOLM to Execution Languages: a SpacePython Example

SOLM models captured in XMI format can be mapped bi-directionally to Domain Specific Languages (DSLs) such as SpacePython and Comet Control Language (CCL). Here's a SOLM-compliant procedure in SpacePython:

# SOLM-compliant SpacePython Procedure Sample

from solm.actions import send, verify, wait_on_time
from solm.parameters import XtceParameter

def execute_power_on_sequence():
    # 1. Read solar panel voltage telemetry
    panel_voltage = XtceParameter("SOLAR_PANEL_VOLTAGE").read()

    # 2. Verify range before powering on payload
    if panel_voltage > 28.0:
        # Send command to spacecraft
        send("PAYLOAD_POWER_ON", argument={"MODE": "SAFE"})

        # Wait 5 seconds for telemetry update
        wait_on_time(seconds=5)

        # Verify status
        verify("PAYLOAD_STATUS_PARAM", expected_value="ON")
    else:
        raise Exception("Insufficient voltage to power on payload!")

Why it matters

The SOLM 1.1 specification is a foundation for modernizing satellite ground segment operations. By decoupling procedure logic from proprietary execution engines, space agencies and private operators can maintain, re-use, and validate operational scripts throughout the entire spacecraft lifecycle.