XSMP Configuration (.xsmpcfg)

Configuration files define reusable values that can be applied to component instances.

This page documents the user-facing configuration grammar in detail: root declarations, nested component configurations, includes, values and paths.

Document comments and metadata

Configuration files use the shared document-comment rules described in Shared Syntax: Comments, Paths, Templates and Values.

Use a leading documentation comment with the shared root-level tags @title, @date, @creator and @version when you want to enrich exported SMP metadata.

Example:

/**
 * Nominal avionics configuration.
 * @title Avionics Nominal Configuration
 * @creator alice
 * @date 2026-03-27T08:00:00Z
 * @version 1.0
 */
configuration AvionicsNominal

Root structure

A Configuration declares one reusable configuration and then fills it with component-specific values and optional includes.

Syntax

configuration <name>
    (<component-configuration> | <include>)*

Required:

• configuration
• the configuration name

Optional:

• any number of nested component configurations
• any number of include statements

Example:

configuration AvionicsNominal
/avionics: demo.avionics.AvionicsUnit
{
    modeState = demo.foundation.Mode.Nominal
}

Component configuration blocks

A Component Configuration block targets one component instance path and assigns values inside that component subtree.

Syntax

<path> [: <component-or-assembly>]
{
    (<include> | <component-configuration> | <field-value>)*
}

Required:

• one target path
• a block body

Optional:

• : <component-or-assembly>

Behavior:

• the path selects the configured component instance
• the optional : <component-or-assembly> states explicitly which component or assembly context this block is written for
• when an assembly context is provided, nested paths may reuse that assembly's template parameters
• nested blocks let you configure children inline

Example:

/avionics: demo.avionics.AvionicsUnit
{
    modeState = demo.foundation.Mode.Nominal
}

Nested component configuration

A Nested Component Configuration block lets you continue configuring child components without repeating a full absolute path.

Example:

power: demo.avionics.BatteryPack
{
    commandedMode = demo.foundation.Mode.Nominal
    stateOfCharge = 82
}

include

An Include reuses another named configuration, either at the current level or below a child path.

Syntax

include <configuration-name> [at <path>]

Required:

• include
• one configuration name

Optional:

• at <path>

Behavior:

• without at, the included configuration is applied at the current level
• with at, it is applied below a child component path

Examples:

include SensorCalibration

include SensorCalibration at sensor

include LegacyCalibration at unsafe sensor

Field assignments

A Field Assignment writes one concrete value into one configurable field.

Syntax

<field-path> = <value>

Required:

• a path to the target field
• =
• one value

Examples:

modeState = demo.foundation.Mode.Nominal
stateOfCharge = 82
lineVoltage = 28.2

Values

Configuration Values group the literal forms you can assign to configurable fields.

Configurations support three value families:

• simple values
• arrays
• structures

The shared scalar literal rules, including numeric suffixes such as i32, u16, f64, lit, d and dt, are documented in Shared Syntax: Comments, Paths, Templates and Values and Numeric suffixes.

Simple values

Simple Values cover the shared scalar literals commonly used in configuration files.

Use the common value reference for the full list of supported scalar forms. In configuration files, those simple values are typically used for field assignments inside one component subtree.

Examples:

retryCount = 3i32
lineVoltage = 28.0f64
modeState = 1lit
startupDelay = "PT10S"d

When the target type is already clear from the field being assigned, you may also write plain integers and floats instead of suffixed numeric literals.

Arrays

An Array Value assigns an ordered list of values to one array-typed field.

Syntax

[<value>[, <value>]*]

Required:

• opening and closing brackets
• zero or more array elements

Optional:

• commas between elements

Behavior:

• each element is validated against the item type of the target array
• element count is validated against the target type where relevant

Examples:

tuning = [1.0, 0.6, 0.3, 0.1]

enabledChannels = [true, false, true]

Structures

A Structure Value assigns several member values at once to one structure-typed field.

Syntax

{
    <value-or-designated-field>[, <value-or-designated-field>]*
}

Required:

• opening and closing braces
• zero or more structure elements

Optional:

• commas between elements
• designated member names inside the literal

Structure elements may be:

• positional values
• designated field assignments

Behavior:

• positional values follow the declared member order
• designated fields let you initialize members by name
• you may mix both forms when the target structure type allows it

Designated field syntax

A Designated Field targets one named member explicitly inside a structure literal.

[unsafe] <field-name> = <value>

Required:

• one field name
• =
• one value

Optional:

• unsafe

Behavior:

• unsafe keeps the textual member name even when it cannot be resolved safely

Examples:

thermal = {
    sensor = 17.5,
    target = 20.0,
    heater = 12,
    enabled = true
}

legacy = {
    unsafe deprecatedField = 2
}

Paths

A Configuration Path identifies which component or field receives the configured value.

Configuration paths are used in:

• component configuration headers
• include ... at ...
• field assignments

Configuration paths use the shared path model described in Shared Syntax: Comments, Paths, Templates and Values and the shared unsafe behavior documented in unsafe.

Behavior:

• an absolute path starts from the configuration root
• a relative path starts from the current configuration block
• . keeps the current level and .. moves to the parent level

Important note

Configuration paths may use template placeholders when they are resolved inside an assembly context, for example in a component configuration declared with : <assembly> or inside one of its nested blocks.

Examples:

/avionics

power.battery

../router

tuning[0]

unsafe child.sensor

Minimal complete example

/**
 * @title Avionics Nominal Configuration
 * @creator alice
 * @date 2026-03-27T08:00:00Z
 * @version 1.0
 */
configuration AvionicsNominal

/avionics: demo.avionics.AvionicsUnit
{
    modeState = demo.foundation.Mode.Nominal
    thermal = {
        sensor = 17.5,
        target = 20.0,
        enabled = true
    }
    include SensorCalibration at power
}