​
Overview

There are ten fundamental elements in Dalus that serve as the foundational building blocks for complex system modeling.
ElementPurpose
VariableRepresents the quantities and units for Part attributes, Action inputs/outputs, and Interface connections.
RequirementDefinition of a customer or system-level need. Includes assigned systems, functions, owner(s), and quantitative constraints that determine verification status
PartStructural / spatial / logical unit or block. Can be decomposed indefinitely to build a hierarchical system structure.
PortAttach to Parts to represent an inlet or outlet.
StateRepresents the different “modes” or states your system can be in; assignable under any Part.
ActionRepresents the different actions your system can perform; assignable under any Part.
InterfaceConnect two Ports together to represent physical contact. Interfaces can contain multiple connections, each of which represents a flow of information, mass, energy, or force.
TransitionConnect two States together. Defines the conditions under which the transition is triggered and which Actions get executed when triggered.
SignalConnects Actions together to represent a sequence. Propagates output Variables to inputs and triggers the next Action to execute.
FunctionRepresents an abstract capability in the functional decomposition hierarchy; independent of physical architecture and assignable to Requirements and Parts.

​
Variables

A Variable consists of a name, value, and unit (optional). They show up as:
  • Part attributes (e.g., mass: 200 kg)
  • inputs and outputs on Actions (e.g. voltage: 10 V)
  • connections inside interfaces, and connection properties (e.g. flow_rate: 8 kg/s, T: 25 C, p: 90 psi)
Variable values are defined by mathematical expressions, i.e. 1 + 2*(43^5), and can also reference other variables by name, i.e. total_mass = mass1 + mass2.

​
Requirements

A Requirement captures a stakeholder need or obligation that the system must satisfy. Core schema:
  • level – abstraction level of the need (mission, system, subsystem, component)
  • name – short, human-readable title
  • statement – the text of the requirement expressed as a shall/should clause
  • constraints – a list of quantitative checks such as mass < 100 kg. Each constraint references one Variable, an operator (<, >, =, <=, >=), and a limit (numeric value + optional unit).
  • status – verification state automatically derived from the constraints (e.g., complete when every constraint is true, failed when any constraint is false, in progress when one or more referenced variables lack a value)

​
Verification

The status of the requirement is determined by the interplay between Constraints, Variables, and Actions:
  • Constraints, i.e. mass < 100 kg, evaluate to true or false. Constraints are evaluated continuously as their reference Variable changes, i.e. mass.
  • A requirement’s status is automatically determined based on its constraints, i.e. complete, failed, etc..
  • Actions can set Variables globally using python.
These are the core mechanisms at work in your system model that keep a requirement’s status true and traceable to the Part and its attributes or Interface and its Connections Requirements are also assigned to specific systems, functions, or persons to mark ownership and traceability.

​
Parts (Physical Decomposition)

  • The fundamental structural element in Dalus is the Part. A Part is a self-contained portion of your system, whether hardware or software, that you treat as a black box.
  • Parts can be nested indefinitely to capture system decomposition: spatial decomposition for hardware (physical assemblies, sub-assemblies, components) and logical decomposition for software (infrastructure, software layers, services, modules).
    Whenever you create a Part, you are drawing a clear system boundary. Boundaries should reduce cognitive load, localise changes, and align with team member ownership/responsibilities.
  • Part properties are called attributes which are simply Variables that belong to parts.
SysMLv2 Parts Diagram

Figure 1. Structural decomposition of the Griffin SV satellite

​
Ports

Ports are the exposed entry or exit points on a Part’s boundary. They mark where the part interacts with the outside world. By dropping a Port onto a Part in Dalus you are literally poking a hole through the system boundary you established when you created that Part.
SysMLv2 Ports Diagram

Figure 2. Example ports on Griffin SV and their connection to mission control centers

​
Interfaces

Interfaces define what is actually flowing between Parts through Ports. An Interface itself has a name, and optionally a color, and one interface can consist of multiple Connections, —the individual flows of matter, information, energy, or mechanical load (binding) that actually move between the Parts.

​
Connections

A Connection captures four key fields:
FieldDescription
TypeMatter, Information, Energy, or Binding
DirectionFlow orientation relative to the owning Part (e.g. in, out, both)
SubtypeOptional subtype (e.g.) Ethernet, O2 gas, Electrical
VariableThe numeric value and unit (e.g. 2 kg/s, 28 V)
Properties(Optional) list of variables to further define the connection (e.g., 128 kHz, 5°C, 85 Pa)
You can also create reference connections that duplicate an existing Connection elsewhere in the model. A reference connection stays automatically synchronized with its source, letting you reuse the same flow definition without manual duplication.
SysMLv2 Interfaces Diagram

Figure 3. Interface connecting two Griffin SV subsystems

️Coming Soon: Define Port constraints to limit quantity ranges (e.g., ≤ 10 A), allowed connection types, and permitted flow directions.

​
States

Let’s shift gears a bit. Up until now, we’ve been discussing how to model system structure, and we were fundamentally constrained by space. States mark our shift in this guide to modeling system behavior. A State captures a distinct mode a Part can inhabit at any given time during its lifecycle (e.g., OFF, NOMINAL OPERATION, EXPENDED). To assign a State to a Part, it is simply add it inside that Part.

​
Transitions

A Transition links one State to another. Within Transitions, you define what Actions execute when the transition occurs. Transitions can then be manually triggered by you, the modeler, to execute those Actions.
️Coming Soon: Specify triggers and guards (boolean conditions) to program when a transition fires. The transition fires if and only if any trigger is true AND all guards are false.
 Using States and Transitions, you can form a State Machine for any particular Part, which defines what the states are and when or under what conditions the Part transitions between them.
Rocket Engine State Machine

Figure 4. State machine of 'Rocket Engine'

​
Actions

Actions are the functions that a Part performs. Like States, every Action you create shows up as its own node nested under the Part that owns it, keeping behaviour and structure aligned. Each action:
  1. Consumes input variables
  2. Runs a short Python code snippet to do the work, and
  3. Produces output variables.
Rocket Engine Combustion Action

Figure 5. 'Combustion' Action computes combustion pressure and chamber temperature of the Rocket Engine

Actions can be chained so that the outputs of one action feed directly into the inputs of the next, allowing data to propagate naturally through a workflow. Once all of its input variables have been provided, an Action fires automatically, ensuring that chained actions execute in the correct sequence. Within the Python snippet you have global read/write access to every Variable in the model, so an action can inspect or update values beyond its declared inputs and outputs when necessary, to update Constraints on Requirements, for example.

​
Signals

A Signal connects Actions together in a sequence: it propagates output Variables from the sending Action to the input pins of the receiving Action and triggers that next Action to run. An Action in the chain fires only after all of its inputs have been provided by preceding Actions.

​
Functional Decomposition

Up until now we’ve been fleshing out the system’s functions in the form of Actions performed by various Parts. Sometimes, however, it’s useful to step back and describe the system purely in terms of the functions it must accomplish, independent of where in the physical architecture they live. Dalus lets you do this by building a functional decomposition tree in parallel with the physical one. You can subsequently assign these high-level Functions to both Requirements and to the Parts that ultimately implement them, closing the loop between why a function exists and where it is realised.
AttributePurpose
levelAbstraction tier where the function lives (mission-0, system-1, subsystem-2, component-3)
nameShort, human-readable title
descriptionPlain-language explanation of what the function accomplishes
failure modesExplains ways the function can fail
success criteriaExplains expected behavior / outputs
This dual-hierarchy approach enables top-down physical and functional decomposition, letting you map each function to the structure that owns it as well as to the requirements it satisfies.

​
Conclusion

We’ve now covered the core modeling concepts– from system structural / logical decomposition, to functional and behavioral decomposition, and how to create and enforce Requirement traceability. If you haven’t already, be sure to do the Quickstart for a hands-on guide on how to apply these concepts. To learn more about the modeling language that Dalus is based on, check out the following resources: I’ll leave you with a few words of advice: Start by identifying a clear and concise goal you aim to achieve by adopting a model-based approach. Then, instead of trying to “boil the ocean”, model only the necessary components of your system to achieve that goal. Feel free to contact us for any help founders@dalus.io Remember, the goal is not just a diagram, but a single source of truth for your system that you can analyze, simulate, and evolve with confidence. Happy modeling!