VSDEL user guide

Getting started

VSDEL runs in the browser at app.vsdel.com. Sign up with your email — no invitation needed. On first sign-in you either create a team (you become its admin, with a workspace all your own), join with an invite code a team admin gave you, or seed a demo team to explore a ready-made satellite model.

Once you're on a team, the project picker lists your team's projects. + New project offers three starts: Blank, the MBSE skeleton (Structure / Behavior / Requirements / Use cases packages ready to fill), or start from a sample: the OrbitalRelay satellite (a compact model across every lens), the Notation Gallery ground station — every diagram kind and notation in one model, ideal for learning what each symbol means — or the Constellation mission — relay satellites, a patrol aircraft on a waypoint route, ground stations, sensors, coverage requirements and a baseline scenario, ready to run in the Mission scenario analysis lens — the Doorbell camera — a compact product model whose CAD, fit chain, safety factor and first mode all bind to pre-verified requirements — the Argo-550 robot arm — a collaborative arm whose torque margin, stop arc, mass rollup and per-motor duty-cycle thermal window all evaluate live — or the Aurora-1 EO satellite — a 116 kg Earth-observation smallsat with every budget closed: mass and power rollups over a variation-point propulsion slot, GSD and link-margin calcs, a Tsiolkovsky Δv, states, sequences, FMECA, fault tree and a telescope trade study.

Your first model in ten minutes

A hands-on path from empty project to a verified requirement. Every step uses the mouse-first canvas; the same model is equally editable as SysML v2 text, and you'll touch both.

1. Create the project. Sign in at app.vsdel.com → + New project → MBSE skeleton. You get Structure, Behavior, Requirements and Use cases packages, ready to fill.
2. Add two parts. Open Structure → Interconnection, press + Add ▾ → part twice, and rename them in the inspector — say Charger and Battery. Drag from one node's port handle to the other to connect them.
3. Give Battery numbers. With Battery selected, the inspector's + attribute adds mass = 12 [kg]. Typed attributes show on the node's compartment and roll up automatically through the assembly.
4. Say what must be true. In Requirements → Req. table, add a requirement — "The system mass shall not exceed 20 kg" — and give it the constraint sum(mass) <= 20 [kg]. Write the unit in the brackets: a limit with no unit, compared against a value that has one, never passes — the inspector reads ? not verified until you add it. Link it to the system part with satisfy (drag on the req. diagram, or the inspector's trace section).
5. Watch it verify. The requirement row now carries a live ✓ — the constraint is evaluated against the model's rolled-up numbers on every edit. Change mass to 25 and it flips to ✗; Model health (Analysis) lists the violation. Change it back.
6. Try the text. The canvas toggle's ◫ Side by side shows the same model as SysML v2 text beside the diagram. Click a node — its lines highlight. Type a new part Cable; inside the package braces — it appears on canvas as you pause. One working set, two notations.
7. Check in. Everything you did is staged — the Check in (N) button shows the count. Open the drawer, review each change (discard any), and check in with a message. That's a version: the History drawer shows the commit, and branching, diffing and merge-with-conflicts work from day one.
8. Bring your team. Team admins mint an invite code (Team settings); teammates join with it and open the same project — presence, live sync and per-element check-out locks keep simultaneous editing sane.

From here, each section below is self-contained — jump to whatever your project needs next: requirements, CAD and the rest of the MCAD seat, sequences, parametrics, or AI agents.

Orientation: finding your way around

The workspace has four standing regions:

• Explorer tree (left) — every element, grouped by kind and nested by ownership. Click to select, double-click a diagram to open it, drag an element onto the canvas to add it to the open diagram.
• Pillar tabs & views (top) — Structure, Behavior, Requirements, Parametrics, Analysis, Assurance, Collaborate. Each pillar holds views; every view is a live lens over the same model, so an edit in one view shows up in all of them.
• Canvas (center) — the active diagram. A named diagram shows its SysML frame (bdd [package] Structure); the view tab without a diagram shows the overview canvas of everything the view can render.
• Inspector (right) — every property of the selected element, plus contextual actions (add features, create instances, decompose, trace links).

Getting around fast

Press ⌘K/Ctrl+K for the command palette — jump to any element, diagram, or view by name. Press ? for the keyboard cheatsheet. The Diagram gallery (top of the tree) shows schematic thumbnails of every named diagram. New to the notation? ⌘K → Notation reference opens a built-in SysML v2 cheat-sheet that draws every glyph and line with the same engine as your diagrams.

The model is a repository

Every element — parts, requirements, states, even diagrams — is a versioned element. Edits stage into your personal working set as you make them (the N staged counter, bottom bar). Nothing is shared until you check in.

• Check in (top right) opens the drawer: review each staged change, uncheck any to leave for later, discard what you don't want (Discard checked (N) clears a whole set), write a summary, commit. Commits are atomic. More than six changes are grouped by the part they belong to — one group per part, its geometry with it — with a study's results in their own group, and each group's box checks or unchecks all of it. A long set opens the drawer taller, and its footer (the summary, "N of M" and Check in) stays in view.
• Branches — spin a sandbox for a trade study from the branch picker in the top bar; merge back with conflict resolution, where each conflict shows the differing field with both branches' values and the base's.
• Reviews — open a review on a branch and let a colleague walk the diff and approve (Collaborate pillar); by default a review merges only after someone other than its author approves it.
• History — any commit can be diffed, tagged as a baseline, or exported as a document (⟲ icon, top bar).
• Undo/redo (⌘Z) work on your staged edits; check-out locks (inspector) reserve an element when you need pessimistic safety.

Definitions — the general view of your system's types

The Definitions view (SysML v2's general view of definitions — v1 called it a Block Definition Diagram) defines your system's types: part defs, attribute defs, interface defs, constraint defs. A definition's own structure renders as compartments — parts, references, attributes, constraints, operations, receptions, flow features, and ports — added from the inspector's quick-add grid or the definition's right-click menu.

Vocabulary. SysML v2 is the tool's default language everywhere — palette (part def, attribute def…), lens tabs (Definitions, Interconnection, State transition, Individuals — v2 defines no BDD or IBD, and no "block" for them to diagram), guides, tooltips and diagram frame corners (general, state transition). Team coming from v1? Toggle Vocabulary: classic names in the command palette (⌘K) — per user, persisted — and the familiar v1 words return. Attribute rows read v2 feature order: mass : Real = 9 [kg].

Choosing the right connection

The toolbar's connect as picker arms what the next drawn line becomes; the inspector switches an existing line's kind, its aggregation, its pinned sides, and straight vs. right-angle routing — and the same LINE ROUTING controls appear on every relationship line (specializations, typing, dependencies), so a role decomposition can anchor each line exactly where it should meet the actor.

Interconnection — parts and connectors

The Interconnection view (v1's Internal Block Diagram) shows how part usages connect: parts (nested parts render inside their parents), ports on part boundaries, connectors between parts or ports, and item flows labelled with what moves. Drag part→part or port→port to connect; involve an item and the line becomes a labelled flow arrow. Drop a part onto another to nest it.

Use cases — who needs what

Frame the system: a system boundary rectangle names the subject; use cases (ellipses) go inside it; stick-figure actors stand outside. Drag actor↔use case to associate them (either direction works), use case→use case for «include», actor→actor for generalization. Drop a use case onto the boundary to move it inside.

Decompose a use case into its scenario

In SysML v2 a use case is a kind of action, so its scenario is an action flow of its own steps. Right-click a use case (or use the inspector's ACTION FLOW section) → Create action flow; once it exists the same spots read Open action flow. Steps you add on that diagram are owned by the use case — a real decomposition.

Action flows — behavior as steps

Actions connected by successions (control flow), with decisions, forks, joins, and merges where paths split, and pins carrying object flow between actions. Guards on successions label conditional branches. Two terminators: the bullseye activity final ends the whole activity, while the circle-with-X flow final ends just one token. The ▶ Activity simulation panel token-walks the flow — and honors both, so a token reaching a flow final is consumed while parallel flows keep running.

Recursive decomposition

Any action can decompose into its own lower-level flow: right-click → Decompose into action flow. Nodes that have a sub-flow show the ⋔ rake badge — the drill-down cue. One flow per subject, nested as deep as your model needs. Use SuccessionAsUsage for control edges here — TransitionUsage belongs to state machines and won't render on activity canvases.

States — modes and transitions

States (rounded), transitions with triggers, initial and final markers, and composite states. A composite state — one that owns substates — draws as a solid rounded region its substates nest inside. Nest substates directly, or right-click a state → Decompose into state diagram for a submachine of its own (⋔ badge on the parent). The state simulation walks transitions by trigger.

Instances — concrete configurations

An instance specification is a specific configuration of a definition — this spacecraft, not the type. It draws in UML instance notation: its name and type render underlined (dish #1 : Antenna). Select a definition → inspector + Instance, fill slot values, link instances to each other. Slots are validated against the definition.

ConOps — the mission's operational phases

The ConOps (Concept of Operations) lens lays out a mission as a timeline of operational phases — launch, commissioning, nominal operations, safe mode, disposal, and whatever else the mission passes through — so the sequence and duration of what the system does is visible at a glance.

• Phases on a timeline: name each operational phase and place it in order across the mission.
• The operational narrative: capture how the system is intended to be used, from first activation through end of life.
• A shared reference: the phase breakdown gives every other lens a common vocabulary for when a behavior, mode or requirement applies.

When to use it. Use ConOps to frame the operational story early and keep it in view — it answers "what phases does this mission move through, and in what order." It is distinct from the Mission scenario lens: ConOps is the phase timeline, not the 3D orbital and coverage simulation. Reach for Mission scenario when you need the physics; reach for ConOps when you need the phased concept of operations.

Text — SysML v2 textual notation

Every graphical model carries a Diagram | Text toggle — flip any diagram to its SysML v2 textual notation in place (there is no separate Text tab to hunt for). It is not a separate document — it is the same model the graphical views show, so edits round-trip: type a change in the text and it appears on the diagrams; edit a diagram and the text updates to match. Packages render as nested package { … } blocks with their documentation.

• Read and author in text: express part defs, parts, requirements, states and the rest directly in the v2 language when that is faster than drawing.
• One model, two representations: the text is synchronized with the graphical views — no export step, no drift between the notation and the picture.
• Copy, paste & precise editing: select and reuse whole fragments of the model as text, and set exact names, types and multiplicities where a pointer is fiddly.
• Readable diffs: because the model has a textual form, a commit's changes read as a text diff in version history.

When to use it. Reach for the Text view when you are a power user who thinks in the language, when you want to bulk-author or paste structure faster than clicking, or when you are reviewing a commit and a line-by-line diff is clearer than a redrawn diagram.

Official-notation friendly. Paste real SysML v2 files — the parser is layout-insensitive (one-line bodies, wrapped declarations, tight name: Type spacing all read), and constructs beyond VSDEL's structured subset are preserved as textual statements — real, owned model elements that carry their exact text, round-trip verbatim, and delete honestly when you remove them. Every statement of every file of the official SysML-v2-Release training and example corpus (196/196 files, 100% of statements) lands in the model — the majority as fully structured elements and relationships, the rest as owned textual statements; nothing is dropped, nothing is fatal.

Side by side. The toggle is three-way: ▦ Diagram · ◫ Side by side · </> Text. Split mode shows the canvas and the textual notation together over the same working set — select a node and its lines reveal and highlight; put the cursor in an element's text and the node selects on canvas; edit either side and the other follows. A drag-handle divides the panes; your choice persists. Author a whole model as text and the lens converges: once everything you typed is staged, it re-derives the canonical form (never while you are still typing) so line highlighting and click-to-select stay armed on freshly authored models too. The text pane carries its own 🔍 search and folding: collapse every { … } body to its opening line (the package stays open), expand one block from its gutter chevron, and find anything with the editor's full find widget. The split sits text left, diagram right by default — a ⇄ control swaps the sides and remembers your choice.

Dialect coverage. The parser now accepts all 65 probed v2 statement forms — up from 49: multi-target specialization (part def Imager :> Instrument, Payload round-trips, the printer joins the clause back), a typing and a specialization in one clause, verification objective { verify R; } (staged as the verify relationship, direction correct), multi-line require constraint { … } and assert constraint bodies, split entry;/then X; initial states, the transition A then B accept t; shorthand, bare first a then b; successions with if/else guards, allocate/interface feature chains, and lossy-safe skip blocks for metadata usages and view bodies. Earlier forms stay — scoped feature-chain connects (flow from a.b to c.d), v2 transitions (first A accept t if g do e then B), requirement bodies with doc + require constraint, entry; then X; initial successions, satisfy/include/assert one-liners and multi-line docs. Lines still outside the subset are kept, not deleted: the sync reports "N lines outside the subset (kept, deletions suspended)" and applies only what it positively parsed, so pasting full-spec v2 text degrades gracefully.

Checked by the official engine as you type. When the SysML v2 language service is available, every edit is parse-checked by the official grammar in milliseconds, and the full semantic validation runs in the background — an edit stages in well under a second. Only a syntax error on a line you changed holds the sync (the status reads "N errors — fix to sync"); names the engine can't resolve on its own are warnings, and the lens's own text always passes. A handful of VSDEL shorthands the official grammar doesn't accept — transition A then B accept t;, async message ping from A to B; — still author normally, and the line is marked "VSDEL dialect — not portable SysML v2" so you know what to change before handing the text to another tool. Without the language service the lens works exactly the same, minus the engine markers.

Renames keep their links. Rename an element by editing its declaration alone — port can → port canBus — and the change stages as a rename: its connections, flows and attributes stay attached, even while the rest of the text still says the old name and you keep editing elsewhere. Once your edits are staged, the lens rewrites the remaining references to the new name.

Sequence — ordered interactions over time

A sequence diagram (Behavior pillar) shows who talks to whom, in what order. Each participant is a lifeline drawn from a real part in your model, and messages run between them down the page — time flows top to bottom. Every named interaction is its own diagram, so one model can hold many scenarios (nominal startup, a fault response, a specific mission phase) side by side.

• Lifelines are your parts. Add a participant by picking an existing part, so the diagram stays connected to the model — rename or delete the part and the lifeline follows. Messages are ordered; reorder them to change the choreography.
• Messages carry intent. Name each message for the signal, command or call being exchanged, so the diagram reads as a protocol or a step-by-step exchange rather than a sketch.
• Combined fragments (alt / opt / loop) wrap a chosen run of messages in a labeled box. A fragment covers its messages, not row numbers — reorder the choreography and the box follows its content; if every covered message is deleted the fragment remains as a small chip you can select and remove. An alt takes an else divider from the toolbar — pick the message the second operand starts at and the dashed operand rule draws above it, the full UML alternatives form.
• Self-messages and activations. Pick the same part as sender and receiver for a self-message — a part invoking its own behavior, drawn as the classic hairpin. Activation bars derive automatically: every message activates its receiver, and a sync call keeps the receiver's bar alive until its reply comes back, so the diagram shows who is busy when without any extra authoring.
• Messages are text too. The interaction round-trips through the Text lens as message 'power on' from Battery to PDU; lines (async/reply prefixes carry the arrow kind) printed in interaction order — reorder the lines and the diagram reorders; add a line and a new message appears; the choreography is diffable, reviewable text like everything else.
• One interaction per diagram. Keep each scenario focused; the diagram list lets you jump between them.

When to use it. Reach for a sequence diagram when the order and direction of exchanges matters: a handshake or bus protocol between subsystems, the choreography behind a mode transition, an operational scenario walked step by step, or an interface's request/response timing. It pairs naturally with the Interconnection view — which says which parts are connected, the sequence says how they talk across those connections — and with Use cases, which name the goals a scenario satisfies. Where a single behavior is a flow of steps inside one part, an Action flow is the better fit; use a sequence when the story is the back-and-forth between parts.

Geometry — spatial layout & interference

The Geometry lens (Structure pillar) gives your parts a shape and a pose (position and orientation) and lays them out in space — a lightweight packaging and layout study that lives on the same parts as every other view. See the arrangement as 2D plan / front / side projections or spin it in the WebGL 3D viewport, define coordinate frames to measure against, and let bounding-box interference checks flag parts that overlap.

• Shape & pose per part. Give a part a simple solid (box, cylinder, sphere…) and set its size, position and rotation. Because it is the same spatial part the CAD and Board lenses use, placement, mass and requirement budgets all carry through.
• Projections & 3D. Switch between orthographic plan/front/side for dimensioned layout work, or the 3D viewport to judge the arrangement as a whole.
• Coordinate frames. Define reference frames (vehicle, payload, sensor…) so positions and clearances are stated against a meaningful datum.
• Live interference. Overlapping courtyards are found by a bounding-box check and surfaced as findings in Model Health; the offending outline draws red so a fit problem is visible the moment it appears.

When to use it. Use Geometry early, for spatial reasoning before you commit to detailed CAD: rough packaging and envelope studies, checking reach and clearance, sanity-checking that everything fits inside the enclosure, or establishing the coordinate frames the rest of the model will reference. A structural enclosure can be flagged as an envelope: its box defines the volume the others sit inside, so it neither counts as an interference with its own contents nor adds shell-solid mass to the geometry rollup — while still bounding the assembly extents. It is the low-fidelity rung of the spatial story — when you need real solids, booleans and STEP interchange, declare a CAD geometry realization on the same part (see the fidelity ladder) and move to the CAD lens; when the layout is a printed-circuit board, the Board lens is the specialized spatial view. Geometry keeps the whole thread connected from a first sketch to a released solid.

MCAD & ECAD — the engineering guide

Mechanical CAD, electronics and the engineering workspaces have their own guide: the MCAD & ECAD wiki. It covers the workspaces CAD, Board, Schematic and Harness open in; parts from sketch to features, sheet metal and surfacing; assemblies and drawings; stress, thermal and CFD; CAM, mould tooling and additive; PDM and rendering; boards, schematics, circuit simulation, signal and power integrity, harnesses, RF, FPGA pin-outs and packages; and exchanging CAD and ECAD files.

The model is shared: a part's solid, mass and analysis results, and a board's components and nets, are elements of the same SysML model this guide describes.

Requirements

Requirements live in two synchronized places: the requirements table (unique IDs, rich text, custom attribute columns, rationale, saved views, package-scoped levels, e-signature approvals) and the requirement diagram (boxes with «satisfy»/«derive» traces). Every requirement shows a live ⚠ until something satisfies it.

The ▸ chevron beside a requirement's ID opens it under its row: the full requirement text at a readable size, its rationale and constraint, every custom attribute, and what it traces to — what satisfies it, its V&V cases, its parent and sub-requirements, each a link that selects that element. The details stay in view while you scroll the table sideways. With a row highlighted, → opens it and ← closes it.

• Notation: each «requirement» box shows its short-name id and a labelled text compartment, the way SysML v2 draws it.
• Satisfy: drag a design element → requirement (diagram) or use the trace tree.
• Verify: "+ V&V" on a table row stages a verification case wired to the requirement.
• Suspect links: editing a requirement's text flags its traces ⚠ until re-confirmed. Clicking ⚠ suspect lists each suspect link and asks before clearing; only Mark reviewed — clear suspect stages the change.
• Derivation: requirement → requirement «derive»; switch stereotype (refine/trace/copy…) in the inspector.
• Export & upload: the table's ⬇ CSV / ⬇ Excel buttons export the current (filtered) view; ⬆ Import uploads a CSV/Excel back — rows matched by ID, edits and new requirements staged for review.

Limits carry units

Write a constraint's limit as a SysML v2 quantity: mass <= 450 [g], max(maxTempC) <= 85 ['°C'] (or [degC]), min(minWallMm) >= 1.8 [mm]. The limit converts to the bound value's unit, so 450 [g] checks correctly against a mass bound in kilograms. A unit of the wrong kind (a length against a mass) is refused with the reason.

A limit with no unit, compared against a value that has one, never passes: mass <= 450 could mean grams or kilograms, and the tool won't guess. It can still fail. The requirement's inspector BUDGET section reads ? not verified with the warning, and the table's verdict reads ? 0.219 kg — unit check ⚠. A limit of 0 and limits on pure numbers (safety factors, percentages) need no unit. Celsius is written ['°C'] or [degC], because a bare C is the coulomb.

Adding the units. When any requirement or TPM limit is in that state, the Requirements lens shows a notice — ⚠ N limits without a unit — listing each one with the bound attribute, its value and its unit. Add unit… proposes the bound value's unit and shows the resulting text; Confirm stages one ordinary edit, and Cancel stages nothing. Review all walks every listed limit at once. Where the number's scale doesn't match the bound value (450 against 0.219 kg), the panel offers both readings — 450 [kg] or 450 [g] — with no default, and Confirm waits until you pick.

Verification cases that follow the value

A requirement counts as verified only when every V&V case on it passes and none is stale. A new case on a requirement with a constraint starts as auto: its pass or fail is derived from the live evaluation, so it follows the value as the design changes (the table reads auto pass or auto fail). A case you set by hand records the value it judged, and reads ⚠ stale when that value moves or the evaluation contradicts it — re-verify it, or set the case's result to auto (follow evaluation) in the inspector. A hand-set pass that recorded no value also reads stale and offers Switch to auto (the Requirements lens can switch them all at once); a hand-set fail keeps failing. From the API, Python or an agent, create the case with result: "auto" — that is the authoring form; a result: "pass" sent without a resultBasis (the value it judged) is a hand-set pass with nothing recorded, so it reads stale at once.

Where a bound number came from

Every result bound from the CAD lens carries a provenance record. Select the attribute and the inspector's PROVENANCE section shows how the value was obtained — the method, the load case, the material and mesh where the solver recorded them, and when and by whom it was bound; the part's attribute list shows the summary on hover. A result from a different analysis case is kept beside the first rather than overwriting it, whoever writes it — the lens, an MCP agent, Python or the raw API — because the server merges it: for a worst-case attribute (a safety factor, a temperature) the value becomes the envelope, and the governing case is named. A value with no case named is kept as a case of its own; re-running the same physical case (at a finer mesh, too) replaces its value. Structural, nonlinear and fatigue results record their full set-up; other binders record when the value was bound and what it replaced. CFD results also record their flow case (natural convection, or forced flow with its speed and direction), so natural and forced results are kept as separate cases. Every CAD-derived result also records the CAD document it was computed on, and a stress, nonlinear or CFD result where it ran: computed on this browser, or the cloud machine with its threads and run time. It reads ⚠ stale when the part is re-linked or its realization re-pointed, and computed on modified geometry when it was bound from an edited or unsaved feature tree; a verdict that reads such a value says so (stale — re-verify). Provenance lives in the model and the API; the text lens doesn't print it.

Parametrics & computed verification

Constraint blocks hold equations; a constraint's parameters render as small boxes on its boundary, and a binding connector pins a part onto a specific parameter. The unit-aware solver then computes verification verdicts: a mass budget reads ✓ 2.48 kg ≤ 2.5 and recomputes on every commit. Give values units in the inspector.

Bindings feed the result. Drawing a binding is not just a trace — it scopes the evaluation: a constraint bound to specific parts computes over just those parts, so the same expression can read a subsystem's budget rather than the whole model's. An unbound constraint falls back to the whole-model roll-up (aggregated over composition).

TPMs — technical performance measures

Technical Performance Measures track the key engineering parameters that decide whether the design is on course — mass, power, latency, and the like — each as a current value against a threshold (the value that must be met) and an objective (the value aimed for), with the margin computed for you.

• Current vs. threshold vs. objective: state where a parameter stands today against both the must-meet and the target values.
• Computed margin: see how much headroom remains before a measure breaches its threshold.
• Trends with the model: as the design changes, a TPM's current value moves, so a tightening margin shows up as it happens.
• Aggregated by meaning: a TPM over many parts combines them the way the quantity means. Safety factors, margins, walls, clearances, temperatures, stresses and strains take the worst case (min or max), and the row names the governing part; mass, power, energy, cost, volume and counts sum. Percentages, ratios and fractions (routedPct, a utilisation) take the worst case and never sum. The row shows the rule (min (auto) of 4). A name the tool can't read, such as lengthMm, keeps summing: set combine as (sum, min, max or average) in the TPM's inspector to say what you mean.
• A scope: a TPM measures the requirement it tracks (set tracks, or put the requirement's id in its name, such as (REQ-012)), over the same parts with the same rule, so the two read the same value; or an explicit part scope; or, by default, the single top-level assembly, with mould tooling left out (with several, the whole model, and a warning to set the scope). An optional case filter narrows it to matching analysis cases. Each row says what it is over.
• Units in thresholds: write thresholds and objectives with their units, as for requirement limits; a unit-less threshold against a dimensioned value reports unset.

When to use it. Track a TPM for any parameter whose margin you need to watch across the program. TPMs pair naturally with Parametrics & computed verification — a solved roll-up such as a live mass budget is exactly the kind of computed value that feeds a measure — and with the requirements that set the threshold in the first place. The TPM register also appears, with the same statuses, in the generated specification.

Matrix diagrams — rows × columns × relationships

The classic dependency/allocation matrix as a named diagram (Analysis → Matrix diagram): pick a row set and column set — elements specializing a root (a role tree), children of a category block, or an explicit list — and cells show the relationships from the row element to the column element (association endLabel text, e.g. CRUD grants). Rows inherit their ancestors' cells down the specialization tree (shown muted, with the source on hover), scrolling keeps the headers frozen — which is what makes a role hierarchy readable as one table instead of six diagrams.

• The role tree is visible: parents render bold, children carry a ↳ with depth indentation and a hover tooltip naming what they specialize — and this works whatever way the rows were picked (explicit lists included), because the hierarchy is read from the model's specialization relationships, not the axis mode.
• Keep as many matrices as you need: each is a named diagram persisting its own rows, columns, and relationship type — the toolbar's + New creates another, and all of them live in the explorer, gallery, and version history like any diagram.
• Edit in place: double-click any cell to write its label — updating the relationship, or creating it if the cell was empty. Everything stages for review like any edit.
• Crosshair: clicking a cell lights up its row and column headers (and faintly tints both lanes), so you always know exactly which row × column intersection you're editing, however wide the matrix.
• Export: ⬇ CSV or ⬇ Excel (a real .xlsx) of the live grid, inherited cells marked with *.
• Upload: ⬆ Import a CSV/Excel table back — rows and columns matched by name, differences staged (new relationships created, labels updated); unchanged and inherited cells are left alone.

Mission scenario analysis

The Analysis pillar's Mission scenario lens is a multi-domain mission simulation. The model carries the design — and every element declares how it moves through typed attributes: satellites on orbits, aircraft/ships/vehicles on waypoint routes, fixed sites. One scenario mixes them all. Scenarios are persisted artifacts, like trade studies: each picks participants, overrides parameters, sets start time and span, and chooses the propagator — exercising the model without changing it.

• Photoreal model store: an instance admin can upload a photorealistic model (binary glTF .glb) per element kind in the Admin panel's 3D models tab. Uploaded models are served from the instance's own origin — no CDN — so the strict client CSP and the air-gapped self-host edition keep working; kinds without an upload use the built-in procedural model.
• 3D models: every element renders as a recognizable 3D model on the globe — satellites with solar wings and dishes, aircraft and fighters with swept wings, helicopters with rotor disks, ships and submarines with hulls and sails, ground vehicles, and ground-station dishes — oriented along the velocity vector so movers point where they travel. (Models are built procedurally so the whole tool stays offline and self-contained.)
• Three views, one continuous scene — transitions are smooth camera flights, never hard cuts: Space frames the Earth, the Earth–Moon system, or the whole System when a mission goes celestial; Sky flies the camera above any observer looking straight down, so aircraft and ground assets read like a live map; Element eases into tracking one element with its live position, altitude and speed.
• Beyond Earth: missions extend to the Moon, Mars and heliocentric space — orbits around other bodies, and transfer missions (launch from a parking orbit, a guided cruise that chases the moving target, then a near-side landing or orbit capture). The Moon and Mars occlude line of sight, and the deep-space geometry follows the scenario's start date. Ephemerides are visualization-grade circular mean orbits — right scale and period.
• Template elements: pull ready-made platforms into the model from the lens — imaging (SSO), GEO comms and LEO broadband satellites, ISR aircraft, fighter jet, helicopter, long-endurance drone, ship, submarine, ground vehicle, ground station. Each stages a real model subtree: the platform part with movement attributes plus subsystem parts carrying their own typed attributes. A separate Add payload picker attaches more sub-elements to whichever element is selected — EO/IR sensors, SAR, surveillance radar, SIGINT, Ka/UHF/optical comms, SATCOM, tracking antenna, GNSS — all reviewed and checked in like any edit, and equipping the platform in the analysis. Weapon sub-elements (air-to-air / air-to-ground / cruise / anti-ship missiles, guided bombs, SAM, torpedoes, naval gun, CIWS) attach the same way, as modeled loadout parts with range and quantity attributes.
• Tailor and save for reuse: every attribute on a platform or sub-element is a real, editable model value — change altitude, sensor cone, weapon range, data rate, anything. Then Save as template captures that element with its whole subsystem subtree and tailored attributes as your own reusable template, which appears in Add element under "Saved" for stamping into any scenario or project.
• Scenario time: each scenario has a start date-time and span (6 hours to 7 days); watch in real time (1×) or accelerated (60× / 600× / 1800×), pause, and scrub anywhere in the span. Click a pass in the access table to jump the clock to it.
• Scenarios like trade studies: create as many as you need (+ New); participants, situation overrides ("what if 700 km?"), start, span and propagator persist on the scenario artifact — versioned and reviewed like everything else. Save results stores windows and per-pair metrics on it for side-by-side comparison.
• Physics by default: orbital elements integrate the two-body + J2/J4 zonal field numerically (sun-synchronous precession ≈0.99°/day is emergent); two-body Keplerian is selectable; Load… accepts a user-defined propagator (propagate(orbit, tSeconds) → [xKm, yKm, zKm]) that runs only in your browser session. Access analysis covers site↔mover passes, mover↔mover crosslinks with Earth occlusion, and sensor detections — including events shorter than a sampling step.
• Start fast: the Constellation mission sample mixes three relays, a patrol aircraft, two ground stations and sensors; the Lunar transfer mission sample launches a crew vehicle from Earth parking orbit to a Moon landing with a lunar relay orbiter and the three-site deep-space network.

Parts without movement attributes still fly as a default LEO train so any structural model gets a live globe.

Analysis & assurance lenses

The Analysis and Assurance pillars read the same model: Model health (coverage gauges, orphans, dangling references — every finding one click from its element), matrices (dependency + editable allocation; for a configurable, exportable rows × columns table see Matrix diagrams), dashboards, queries, FHA (severity→DAL), FMECA (S×O×D→RPN), fault trees, a 5×5 risk register, TPMs, lifecycle review gates, trade studies, and a ConOps mission timeline.

Dashboards — Visualization Studio

The Dashboards lens is a Visualization Studio for building trade-study dashboards with charts (powered by ECharts) over your model and trade-study data — a place to see the numbers and compare alternatives visually rather than reading them off a table.

• Charts over model data: visualize values drawn from the model and from study results.
• Trade-study dashboards: assemble charts into a dashboard for comparing options side by side.
• ECharts rendering: a full charting library backs the plots.

When to use it. Build a dashboard when you want to see a comparison — weighing alternatives from a trade study, plotting the time-series a co-simulation run produced, or presenting how a set of measures stands. It is the visualization surface for the analysis lenses.

Trade study — weighted decision matrix

The Trade study lens is a weighted decision matrix: define the alternatives you are choosing between and the criteria that matter, weight the criteria by importance, score each alternative against each, and read a ranked recommendation.

• Alternatives × criteria: lay out the options against the factors that decide between them.
• Weighted scoring: assign each criterion a weight and score every alternative, so the ranking reflects what matters most.
• Ranked result: the matrix rolls the weighted scores into an ordered recommendation.
• Persisted as an artifact: the study is saved with the model, so the decision and its rationale live alongside everything else.

When to use it. Reach for a trade study whenever a design decision comes down to a defensible choice among options against weighted criteria — architecture selection, component choice, a build-vs-buy call. Feed it hard numbers from a co-simulation run, and visualize the comparison in a dashboard. Every study, with its matrix and recommendation, is part of the generated specification.

Runs — FMU co-simulation

The Runs lens executes FMU co-simulation runs and shows the resulting time-series. An FMU (Functional Mock-up Unit, from the open FMI standard) packages a simulation model; running one exercises the behavior over time and produces data the rest of the analysis lenses can use.

• Execute FMU runs: drive a co-simulation from the model and collect its output.
• Time-series results: view how the simulated quantities evolve over the run.
• Feeds studies & dashboards: run results become inputs to trade studies and are plotted in dashboards.
• Open-standard interop: FMI/FMU is an open co-simulation interface, so models from many sources can be run here.

When to use it. Use Runs when a decision needs simulated behavior rather than a static number — dynamic response, transient performance, anything an FMU computes over time. The time-series it produces is the quantitative backbone for a trade study or a dashboard.

Queries — saved model queries

The Queries lens holds saved, re-runnable queries over the model, expressed through the OMG Systems Modeling API (the standard programmatic interface to a SysML v2 model). A query finds the elements matching a set of constraints; saving it means you can run it again, and share it, without rebuilding the search.

• Find by constraint: return the elements that match the conditions you specify.
• Save and re-run: keep a query as a named artifact and execute it again whenever you need the current answer.
• Reuse and share: a saved query is available to the team, so a useful search is written once.
• Standard API: queries run over the OMG Systems Modeling API, the same standard interface used for programmatic access.

When to use it. Save a query for any question you ask of the model more than once — "every requirement without a satisfy," "all parts over a mass threshold," "elements owned by this package." It turns an ad-hoc search into a reusable, shareable check.

Safety — Functional Hazard Assessment

The Safety lens runs a Functional Hazard Assessment (FHA): identify the system's functions and the hazards associated with their failure, assign a severity to each, and derive the Development Assurance Level (DAL) the function must be developed to — following ARP4754A.

• Functions & hazards: enumerate the functions and the hazardous conditions that a failure could cause.
• Severity classification: rate the consequence of each hazard.
• DAL derivation: turn severity into the assurance level required, per ARP4754A.

When to use it. Use the Safety lens on safety-relevant systems to establish, early and traceably, how rigorously each function must be developed. The DALs it produces set the assurance targets that flow down into the rest of the program's safety work.

FMECA — failure modes & effects

The FMECA lens supports FMEA / FMECA: enumerate the ways parts and functions can fail, rate each failure mode for Severity, Occurrence and Detection, and compute the Risk Priority Number (RPN = S × O × D) so the worst modes rise to the top.

• Enumerate failure modes: capture how each element can fail and what the effect is.
• Rate S × O × D: score how bad, how likely, and how detectable each mode is.
• Compute RPN: multiply the ratings into a single priority number.
• Prioritize: rank the failure modes by RPN to focus mitigation where it counts.

When to use it. Run an FMECA to systematically work through a design's failure modes and decide which ones warrant action first. It complements top-down analyses like the fault tree: FMECA reasons bottom-up from individual failures, the fault tree reasons down from a top-level event.

Fault tree — top-down failure logic

The Fault tree lens builds a Fault Tree Analysis: start from a top event (the failure you care about) and decompose it downward through AND / OR gates to the basic events that can cause it, then roll up probability from the basic events to the top.

• Top event down to basic events: model the logical chain from a system-level failure to its root causes.
• AND / OR gates: express whether causes must combine or any one suffices.
• Probability roll-up: assign probabilities to basic events and propagate them up the tree to the top event.

When to use it. Reach for a fault tree when you need to reason from a specific undesired outcome back to its causes and quantify how likely it is. It is the top-down counterpart to the bottom-up FMECA, and pairs with the Safety lens's hazard work.

Risk — register & 5×5 matrix

The Risk lens is a risk register that scores each risk on a 5×5 matrix of likelihood × consequence, giving a rated position from low to high, and tracks the mitigation for each.

• Register of risks: keep every identified risk in one place.
• Likelihood × consequence: score each risk on the 5×5 grid for a consistent, comparable rating.
• Mitigation tracking: record the action being taken against each risk and follow its status.

When to use it. Use the Risk register as the program's standing view of what could go wrong and what is being done about it — technical, schedule or programmatic risks alike. Where the Safety, FMECA and fault tree lenses analyze specific failure mechanisms, the risk register is the higher-level ledger that tracks and prioritizes risk across the whole effort.

Notes & annotations

Every diagram's + Add → note (annotation) drops a sticky-note Comment — a real model element (versioned, reviewed) scoped to that view. Select an element first and the note anchors to it. Edit the body in the inspector.

Editing gestures

Named diagrams get the SysML frame with a corner tag; the PNG button exports the diagram — notation, frame and all — for review decks.

Keyboard shortcuts

Import & export

In: No Magic/Cameo SysML v1 (.mdzip or XMI — the full v1→v2 conversion: package structure, blocks/interfaces/constraint blocks, value types and enums, parts with multiplicities, value properties with defaults, ports, generalizations, requirements with satisfy/derive/refine/trace, use cases and actors, activities with control flow, state machines with triggers and guards, and sequence diagrams (interactions with lifelines and messages) — re-import updates in place, and every import stores a conversion report: what each v1 construct became, what was skipped and why — and the XMI export writes the same coverage back for Cameo round-trips), ReqIF, DOCX requirement extraction, FMU co-simulation units, reusable definition libraries, and KiCad boards/netlists (.kicad_pcb/.net) into the Board lens. Out: XMI, ReqIF, generated specification documents from any commit (HTML to print as PDF, or Word .docx — see below), diagram PNGs, ICD exports, KiCad .kicad_pcb/.net, and a board BOM as CSV. Mechanical and board geometry travels as STEP (AP242 with PMI), IGES, STL, 3MF, glTF, JT, DXF, IDF, IDX, Gerber and G-code — see Interchange. Programmatic access via the OMG Systems Modeling API, an OSLC provider for DOORS/Jama/Polarion-class tools (bearer tokens minted in-app), and a stdlib-only Python client.

Generated specification

The Spec and DOCX buttons in the explorer generate a system specification from the checked-in baseline, computed with the same rules the workspace uses. In order:

• System structure: the part hierarchy with attributes and ports.
• Interconnections and definitions.
• Requirements & traceability: grouped by package, with satisfy, derive and V&V links.
• Verification: each requirement constraint's computed value, margin and verdict.
• Technical performance measures: current value, threshold, objective, margin and MET / MARGINAL / BREACH. A row that can't be trusted, such as mixed units or an objective on the wrong side, says why.
• Trade studies: the weighted decision matrix and its recommendation. A tie or a missing score is reported as such, never as a silent pick.
• Safety & assurance: FHA, FMECA and the risk register.
• Diagrams: every named diagram as a numbered vector figure.

A diagram is drawn with your saved arrangement; one you've never arranged is laid out automatically, the way the canvas lays it out. Arrangements aren't versioned, so a figure uses the current one.

In the Word file, figures are embedded as SVG, which Word 2016 and later (Microsoft 365) render. Older readers show a blank placeholder; the HTML version carries the same figures.

Self-hosting

VSDEL ships Dockerfiles, a compose file (including an optional MCP service), and a Helm chart for buyer-hosted installs. Self-host licensing uses signed keys; the MCP server runs beside your install with VSDEL_MCP_URL pointed at it, so agent tokens never leave your network.

Teams, roles & presence

Teams own projects; members hold per-project read / write / admin roles, and team admins manage every project in the team (Access button, top bar). Live presence shows who's working where; staged changesets are per-user so nobody tramples anybody; element locks are there when you want hard reservation. Invite teammates with an invite code from Team settings.

For scripts and integrations: every staged change carries a version, and the changeset PUT honors If-Match: "<version>" — a stale write returns 412 with the current version instead of silently overwriting a concurrent edit ("0" asserts create-only). Raw-API writers get compare-and-set safety; the app itself stays on live sync.

The fidelity ladder

Systems engineering starts at low fidelity and grows toward higher-fidelity models — CAD geometry, structural (FEA), thermal, behavioral. VSDEL keeps that a connected thread: any element can declare higher-fidelity realizations that stay linked to it and version with it. Select an element and open the Fidelity ladder in the inspector to add one.

• Declare a realization: pick a kind (CAD geometry, FEA, thermal, electrical, mission scenario, behavioral/FMU, physical prototype), set its maturity (concept → preliminary → detailed → released), and link the artifact (a STEP file, external CAD, a document, or an internal model element).
• Change capture across fidelity: edit the abstract element and its realizations are flagged suspect — the same mechanism requirement trace links use — so drift between the systems model and the high-fidelity model is never silent. Re-sync clears the flag.
• One spine, every domain: CAD is only the first kind; FEA, thermal, and behavioral realizations plug in identically. This is the bridge that lets fidelity grow without losing traceability.

Instance administration

Above team admins sits the instance admin — the operator of the whole VSDEL instance, configured by email on the server (ADMIN_PRINCIPALS). When an instance admin signs in, an Admin button appears on the project-home screen, opening a three-tab panel:

• Dashboard: registered users (with 7-day active count), teams, projects, unique visitor IPs and request volume over the last 30 days — collected by the server itself, no external analytics.
• Accounts: every principal that has signed in or holds membership — teams and roles, first/last seen, API tokens. Block disables an account instance-wide (sign-in still succeeds at the identity provider; every API call is refused until unblocked); Revoke tokens clears a principal's API tokens.
• 3D models: upload photorealistic .glb models per element kind, served same-origin (no CDN) with automatic procedural fallback — see the mission lens.
• Billing: every team with its leader(s) (team-admin members), plan (free / pro / enterprise), seats (members in use vs. purchased quantity, editable for direct deals and grants), project count, total storage (bytes of model data across the team's projects, committed + staged, with the element-version count), AI use (metered tokens this period and all-time), and the attached marketplace subscription. The plan dropdown overrides a team's plan directly; a paid plan with no subscription is badged manual grant — the mechanism for comps and gov/academic grants — and the marketplace webhook re-syncs subscribed teams on their next lifecycle event.

Plans & seats

VSDEL bills per seat: a team's seat count is its purchased subscription quantity, and the AI allowance scales with it. Team settings shows your seats in use and AI tokens consumed against the monthly allowance.

When a team uses its included AI tokens for the month, the assistant pauses until the reset — add seats for a larger allowance. Government and academic teams can request a free Pro grant from the instance administrator (see Instance administration).

Milestones — lifecycle review gates

The Milestones lens tracks the program's lifecycle review gates — SRR, PDR, CDR, TRR and the rest — each with its date, status, and entry / exit criteria, so the schedule of formal reviews and the bar each one sets are captured with the model.

• The review gates: record each program milestone (SRR, PDR, CDR, TRR…).
• Dates & status: track when each gate is due and where it stands.
• Entry / exit criteria: state what must be true to enter a review and to pass it.

When to use it. Use Milestones to plan and monitor the formal review cadence of a systems-engineering program and to hold the criteria each gate must meet. It complements the model-level Reviews workflow — Milestones is the program's schedule of lifecycle gates, Reviews is the change-by-change approval of the model itself.

Reviews — propose, discuss, approve, merge

The Reviews lens is a model-review workflow: propose changes on a branch, discuss them, approve, and merge — a pull request for the model. Work is proposed against a branch, walked and commented on, and only merged into the mainline once it is approved.

• Propose on a branch: open a review over the changes staged on a branch rather than committing straight to the mainline.
• Discuss the diff: reviewers walk the proposed changes and comment. The change list is exactly what Merge would apply (the three-way result from where the branches split), each line naming its owner and value (old → new for a change); past 30 lines it pages.
• Approve & merge: someone other than the author approves; the review then merges, with conflicts resolved in the review (pick a side per element; each conflict shows the field and both branches' values). New commits after approval need a fresh approval. A branch under review can't be merged around its review. A team admin can turn this off for a solo team (Team settings → Require independent review approval).

When to use it. Open a review whenever a change should be seen before it lands — a trade-study branch, a colleague's contribution, or a claimed set of AI-agent proposals. It builds on the tool's branch-and-versioning model, giving human sign-off on the model the way a code review does for source.

Email notifications. Project members get an email when a review is opened, commented on, approved, merged, or closed (never for their own actions) — so a review request reaches you even when the workspace is closed. Membership is the boundary: only explicit project members are notified.

Slider, the AI assistant

Slider is the built-in AI helper (Collaborate pillar, paid plans), docked at the foot of the inspector — a little slide-rule that comes alive while it's working. It reads the live model through the same API as any client and can build model content on request, and every edit it proposes lands as a staged change in your working set, reviewed and checked in like any human edit. It streams its tool activity so you can watch what it reads and writes. Click Slider to open the full chat.

✨ Generate from text. Paste a specification paragraph (+ Add ▾ → Generate from text) and Slider extracts the model it implies — requirements with their shall-statements, the parts and attributes they mention, and the satisfy links connecting them — staged as one reviewable batch in your check-in drawer. Nothing commits until you check it in.

🔍 AI review. Before checking in, the drawer's AI review button has Slider read your staged set alongside the model's own health checks and validation rules, then report findings ordered by severity — grounded in the actual checks, flagging problems rather than silently rewriting your work.

Bring your own AI. Prefer to run Slider on your own model? Click the provider chip on Slider and choose a provider — Anthropic, OpenAI, Azure OpenAI, or any OpenAI-compatible endpoint (Ollama, vLLM, OpenRouter, LM Studio) — then enter your key and model. Slider keeps the same knowledge of your model; only the AI engine changes. Requests run on your own account and bill, so the plan's monthly AI allowance doesn't apply. Your key is stored only in your browser and sent to VSDEL only to run your requests — never saved on our servers. The model must support tool calling. Self-hosters pointing at a local model (e.g. Ollama on localhost) enable it with VSDEL_ALLOW_LOCAL_AI=1.

External AI agents (MCP)

A team admin can authorize an outside agent — Claude Code, Claude Desktop, or any MCP client — to work in the team's projects. Mint a token in Team settings → AI AGENTS (shown once; revocable), point the client at the hosted MCP endpoint, and the agent can read models and topology, stage elements, relationships, diagrams and deletes, arrange layouts and drill-down decompositions, and run the same CAD, analysis and board tools the lenses use — every change it makes is a proposal under its own identity. It cannot check in, merge, or administer anything; the server enforces that for every agent credential.

Agent proposals appear under the 🤖 badge in your check-in drawer — Claim into my changes adopts them (with "proposed by" provenance; anything skipped is reported, never silently dropped), then you check in as yourself. The bundled vsdel-modeling skill teaches agents the SysML vocabulary and the house conventions, so their output arrives claim-ready.

What agents can run. The tools run the lenses' own code on your project, staged work included, so an agent gets the answer you would get in the lens:

• Model: read elements and diagrams, export a diagram as SVG, and stage elements, relationships, diagrams, sequence messages and fragments.
• CAD and analysis: evaluate and save parts, then run stress, modal, buckling, nonlinear, thermal, fatigue, CFD, DFM, CAM, mould and print-prep analyses, binding results with their provenance — see Agents and the CAD kernel.
• Boards: import KiCad, Altium, Eagle, IPC-2581, PADS and ODB++ boards; check DRC, DFM, constraints and fab rule decks; analyse impedance, signal and power integrity, channel eyes and DDR timing; place, fan out and autoroute; and export Gerber, IPC-2581, ODB++, drawings and openEMS projects.
• Schematics: import KiCad, Altium and Eagle sheets, annotate, run the electrical rule check and simulate a sheet.
• Harness, RF, FPGA and packages: report, size, propose and 3-D route harness wires; compute matching networks and filters; check an FPGA's pin-out and banks; design a BGA package.

Placement, routing, imports and anything else that changes a design arrive as proposals in your check-in drawer; checks, analyses and exports return their results to the agent and change nothing. Long runs — CFD, autorouting — run as background jobs the agent polls. Vendor native code, such as an IBIS-AMI library, never runs on the server.

Sequence authoring & safe concurrent writes. Agents can build interactions first-class — stage_message (sync/async/reply, self-messages included) and stage_fragment (alt/opt/loop with else operands) — and every agent write is a compare-and-set: a concurrent human or agent edit to the same staged change makes the agent re-read and rebase instead of overwriting it.