Type Reference

bool with an optional default:

Eight integer types select the storage width and signedness the embedded software expects: u8, i8, u16, i16, u32, i32, u64, i64.

On the configuration side, integer values can be written as plain numbers (sampleTime: 50), as strings in decimal or hex notation, both with _ separators for readability, a decimal one also with an exponent when the value is whole ("1e3"), or with a unit:

display: "hex" only affects how tooling presents the value; it does not change what the configuration author may write. It cannot be combined with a unit, as a hex value takes none.

f64 is the floating point type, with the same min, max, default, unit, and display options as the integers (see the sensorSupplyVoltage example above). There is no f32 type; if the embedded software uses a narrower float, document it with embeddedTypeHint. A float value may also be written as a string ("1.5e3").

unit names the unit the value is stored in. A built-in unit takes prefixes, so a configuration may write "2 MHz" for a parameter stored in kHz, and Confµgami normalizes it to 2000:

An integer must be convertible to a whole number in the stored unit, so "1.5 ms" is an error for a parameter stored in ms. Tooling shows each value with the best-fitting prefix.

literalsExhaustive and literalsNonExhaustive are mutually exclusive, and every literal must itself satisfy pattern if one is set.

Choose between enum and string literals deliberately: enum literals must be identifiers and become real enum types in generated code; string literals may be arbitrary strings ("front-left") and stay strings in generated code.

An enum declares a closed set of identifier literals, here from the TurnIndicator example:

Literals are SCREAMING_SNAKE_CASE identifiers (they become enum constants in generated Rust and Python code) and must be unique, ignoring case. A literal off the convention is an error, allowLiteralNameDeviation: true on the enum allows it for literals spelled by an external format. default must be one of the literals.

linkerSymbol types a parameter as the name of a symbol resolved by the embedded linker, for example a callback function:

language is required and currently supports "C"; values are checked against the C identifier rules. minLength, maxLength, and default are available like on strings. The embeddedTypeHint shown here is a documentation hint rendered in hover and inlay hints; it carries no semantics but tells the integrator the expected C signature. It applies to value types only and is rejected on an entity and a struct.

filePath types a parameter as the path to a file or folder. Validation resolves the path and checks it on disk:

globPattern reads like a .gitignore line. *, ?, {a,b}, [0-9] and [!0-9] match within one path segment.

The merged model holds the resolved path relative to the CfgSpace root, starting with .. when the target lies outside it. The merge, constraints and the export all see this form, so two files naming the same target through different relative paths agree. resolveFilePathOnExport: false keeps the value as written instead, validation still checks it on disk.

A default has no file to resolve against, so it always stays as written. A constraint therefore matches it with a resolved value only when it is written relative to the CfgSpace root.

An entity aggregates children and has identity (name/id) in the configuration. Entities are the only elements that can be referenced by ref and merged across files:

This also demonstrates inherits: the sensor entity extends the reusable SensorEcu::SensorBase type, see Reusable types.

A configured list of sensors then looks like this:

A struct groups parameters without identity. Use it when the group is pure data and never needs to be referenced or merged on its own:

Structs cannot contain entities, cannot inherit, and have no name/id in the configuration.

Both aggregate children; the difference is identity. An entity is a named object boundary in the domain model, a struct is local composition under its parent.

Choose entity when:

Choose struct when:

The choice is visible in the configuration and the generated schemas: an entity accepts the common keys name, id, $description, $comment, and (as a union member) the $type discriminator. name identifies the instance among its siblings and id globally; an instance takes one or the other, never both, and the id doubles as the name. A struct accepts none of these, it is anonymous by construction.

Reuse is not the differentiator: both entity and struct types can be declared under types and shared via typeRef and scope: "public", like the SensorEcu::Filter struct in the running example. When in doubt, start with a struct; turning it into an entity later is a smaller change than taking identity away from something other files already reference.

A union lets the configuration author choose between several types:

The members are named type paths (entities or structs, at least two). By default unions are discriminated: the configuration states the chosen type with $type:

A ref points at an entity configured elsewhere:

refTargetTypes lists the type paths the target entity may have. In the configuration, the reference value takes one of two forms:

The path segments are the configured entity identities (name, else id), starting at the definition name. They are not the definition’s relation names. A reference can also be written as an object to attach documentation; this one addresses its target with the id: form:

References are validated: the target must exist, be an entity, and its type must be one of the refTargetTypes.

typeRef is not a data type but a reuse mechanism: the element takes the shape of a named type declared elsewhere. See Reusable types and inheritance, which also covers the recursive case.