Signals — The Data

If blocks are the operations of a model, signals are the data. A signal is a typed value that flows along a connection from one block’s output port to another block’s input port, once per solver step. Everything a Modeloop model computes is expressed as signals; there are no hidden shared variables and no side channels.

This has an important consequence: the entire behavior of a model is visible in the diagram. If two blocks exchange data, there is a wire between them.

Signals vs. connections

• A connection is the wire you draw: it links exactly one source output port to one destination input port.
• A signal is the typed value that travels on it.

One output port can drive many connections (fan-out), so a single signal may feed any number of consumers. The reverse is prohibited: an input port accepts exactly one incoming connection, so every value in the model has exactly one unambiguous producer.

The type system

Every signal has an explicit data type composed of a base type and a shape.

Base types

Category	Types
Floating point	float32, float64
Signed integer	int8, int16, int32, int64
Unsigned integer	uint8, uint16, uint32, uint64
Logic	bool
User-defined	Enumeration types (see below)

float64 is the default for numeric work. Narrower types (float32, fixed-width integers) matter most for code generation, where they map one-to-one onto the corresponding C types on the embedded target.

Shapes: scalars, vectors, matrices

A signal’s shape declares its dimensionality:

• () — a scalar
• (n,) — a vector of n elements
• (n, m) — an n × m matrix

Math blocks operate element-wise on tensor signals, and the code generators emit the corresponding loops automatically — MISRA-compliant fixed-bound loops in C.

User-defined enumeration types

You can declare named enumeration types (for example DriveMode with members ECO, NORMAL, SPORT) in the model’s data definitions. Enum-typed signals give discrete modes real names instead of magic numbers:

• Constants and inputs can take enum values (DriveMode.SPORT).
• Comparators and state chart guards can test against enum members.
• Generated C code declares a proper typedef enum with named constants; generated Python uses the same symbolic names.

Type checking and propagation

Modeloop is strict about types, and it is strict early:

1. At connection time — when you draw a wire, Modeloop checks that the source type is compatible with the destination. Incompatible wires are rejected on the spot with a diagnostic.
2. At analysis time — before simulation or code generation, Modeloop infers and verifies the type of every signal in the model, propagating types through blocks that adapt to their inputs.
3. In generated code — every type conversion is an explicit cast; nothing is converted implicitly.

The practical effect: a model that passes validation will not surprise you with a type error at runtime or an implicit narrowing on the target.

Signals at boundaries

Signals cross structural boundaries only through interface blocks:

• Within a diagram, connections are direct: producer block to consumer block.
• Between the levels of a hierarchy, signals pass through Virtual Input / Virtual Output ports on containers.
• At the model boundary, Model Input / Model Output blocks define the model’s public interface — in generated code, the model’s inputs and outputs.
• Between tasks at simulation time, published outputs are exchanged through named topics with last-value semantics: a consumer always reads the most recently published value. This mirrors how real embedded middleware (sender–receiver communication) behaves.

Naming signals

Signal names matter — they become topic names in simulation, column names in CSV exports, and variable names in generated code. Name interface signals after their meaning (wheel_speed_rps, not in1), and include units in the name where ambiguity is possible. The Modeling Guidelines cover naming conventions in detail.