​

Overview

There are ten fundamental elements in Dalus that serve as the foundational building blocks for complex system modeling.

​

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.

​

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.

​

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:

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.

​

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.

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.

​

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.

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.

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:

• SysML v2 Specification
• Sandy Friedenthal’s concise SysML v2 Basics slide deck

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!