Systems engineering · Arcadia · SysML v2 · Git-native

Your system architecture, as reviewable text.

ArcLang is MBSE as code: Arcadia models written in plain text, checked by a compiler that never lies, diffed by meaning, gated like flight software, and open both ways, to Capella and to SysML v2.

Open the playground → Read the source
0 diffCapella round-trip, byte-identical
100%SysML v2 round-trip, checked by the OMG pilot
100%client-side — models stay on your machine
requirements safety {
  req "REQ-AEB-001" "Obstacle detection" {
    description: "Detect obstacles at ≥ 150 m"
    safety_level: "ASIL-D"
  }
}

architecture logical {
  component "Sensor Fusion" {
    id: "LC-001"
    function "Fuse radar and camera" { latency: 25 ms }
  }
}

trace "LC-001" satisfies "REQ-AEB-001"

$ arclang gate model.arc --standard iso26262
✓ GATE PASS — 5/5 requirements verified,
  timing budget 90 ms ≤ 100 ms, HARA consistent

01 / WHY TEXT

Diagrams you can't diff are architecture you can't review.

Graphical MBSE tools lock your architecture inside opaque databases: no pull requests, no blame, no CI. ArcLang moves the model into text — so 50 engineers can branch, review and merge a system the way they merge software — and keeps the diagrams: one per Arcadia viewpoint, generated from the model and always in sync.

  1. Write.

    Arcadia layers — operational, system, logical, physical, EPBS — in a strict, typed language: latency: 25 ms is a duration, not a string. Unknown constructs are localized errors, never silent skips: error at line 42, column 7.

  2. Verify.

    The compiler resolves every trace, port and allocation. Dangling references fail the build. The production gate checks requirements coverage, HARA/ASIL consistency and timing budgets against ISO 26262 / DO-178C.

  3. Review.

    arclang diff compares versions by stable identity: moving a block is no change, renaming is a modification — a change list of meaning, not lines.

  4. Exchange.

    Round-trip with Capella (byte-identical), requirements via ReqIF to DOORS and Polarion, architecture skeletons to Simulink and System Composer, FMI 2.0 interface descriptions.

02 / ARCADIA × SYSML V2

Arcadia's method. SysML v2's expressiveness. One text.

Arcadia gives systems engineering its method: operational need, system, logical and physical architecture, each traced to the level above. SysML v2 has since given models the language they lacked. ArcLang carries both, and translates between them without losing a thing it does not tell you about.

  1. Definitions you reuse.

    A connector type gives every port its pins, an interface type every exchange its protocol, an allocation type the kinds of its ends: trace "PN-BECU" allocates "LC-BMS" { is: "Software deployment" } is checked.

  2. One architecture, a whole product line.

    Variations hold their variants, and a configuration picks one of each. The compiler rejects an impossible product; the diagrams draw the one you name.

  3. Views by concern.

    Tag what matters, tags: ["Safety"], and a safety view is one line that keeps itself up to date: tagged: ["Safety"].

  4. Analyses that verify requirements.

    A test case asserts constraints, and its verdict is computed on every build. A requirement whose analysis fails is not verified, and the gate says so.

  5. Ports that hold ports, buses with any number of ends.

    wheel.nuts.lugNut is checked however deep; ends: [ecu.can, door.can, seat.can] is one exchange, drawn meeting at a junction.

  6. Any SysML v2 model in.

    Several files, resolved against the OMG standard library; parts, connections, performed actions, messages and views become an Arcadia model that compiles. What cannot come is counted and named.

  7. Every Arcadia model out.

    To SysML v2, accepted by the OMG pilot with the same abstract syntax; back to Capella byte-identical, with what Capella cannot hold flattened and noted.

03 / VERIFIED SIMULATION

From architecture to verified simulation.

A requirement is verified when something checked it. ArcLang closes that loop for physics: the ports of the physical architecture become Modelica connectors, a test case simulates it in OpenModelica, and the verdict reaches the same gate and the same pipeline as every other check. A tool that is missing gives an inconclusive verdict, never a pass.

  1. Architecture as code.

    A port says what it carries: physics: electrical, mechanical_rotational, thermal, signal. Connect two ports that carry different physics and the model does not compile.

  2. Modelica simulation as code.

    arclang export -f modelica writes the structure of the physical architecture, drawn, so Modex and OMEdit display it. The physics is a Modelica package you write and keep: regenerating never overwrites a line of it.

  3. A verdict, not a plot.

    A test case says what to simulate and what must hold: min("PN-BATT".soc) >= 0.1. arclang verify runs OpenModelica, locally or in Docker, and checks the units. In the electric-vehicle example, at −10 °C and 100 km/h, the 82 kWh pack ends the 300 km trip with 28.7 % of its charge and the 64 kWh pack with 8.7 %.

  4. The gate.

    A failing simulation is a blocker. A verdict that is missing or stale counts as not verified, and the gate says which command to run. The verdict is cached under a key of the model and the Modelica sources.

  5. CI.

    The same commands run in GitHub Actions, GitLab CI, Azure DevOps or Jenkins, and the pull request gets one comment that says what the change does to the model.

SIM-01new in 4.6

A requirement that fails, found before the road

Both packs drive the 300 km. Only the evidence differs, and it is in the build: the standard pack ends at 8.7 %, under the 10 % reserve, so the requirement is not verified and the gate fails. This output, abridged, is the one the documentation shows, run against OpenModelica 1.27.1.

$ arclang verify ev_range_simulation.arc
✗ TC-RANGE-STD "Winter range, standard pack": FAIL
    FAIL min(batteryPack.soc) = 0.08693
✓ TC-RANGE-LR "Winter range, long range pack": PASS
    ok   min(batteryPack.soc) = 0.2874
$ arclang gate ev_range_simulation.arc
✗ [requirements.verification] REQ-RANGE:
    verification cases fail
PRODUCTION GATE: FAIL ✗ (1 blockers)
OMEdit, the OpenModelica editor, showing the drive unit of the electric vehicle: a torque-controlled motor, the rotor inertia and the reduction gear from the Modelica Standard Library, a current source on the high-voltage bus, wired to the connectors that ArcLang generates

The drive unit in OMEdit (OpenModelica 1.27.1): Modelica Standard Library motor, inertia and gear, wired to the connectors ArcLang generates from the physical architecture.

OMEdit showing the vehicle body: a rolling wheel, the car's mass and the drag and rolling resistance force, Modelica Standard Library components, between the wheel connector and the speed output that ArcLang generates

The vehicle body: wheel, mass and drag force. The physics is a Modelica package you write and keep; regenerating the structure never overwrites it.

OMEdit after simulating the touring configuration: the plot of the battery state of charge over the trip, falling from 1 to 0.287 when the 300 km are driven after 10 803 seconds, with the variables browser

The same model simulated in OMEdit: the long range pack ends the 300 km at 28.7 %, the value arclang verify checks against the 10 % reserve.

SIM-02new in 4.9

How likely the requirement holds, not whether it held once

Cars meet cold mornings and fast drivers. Give a test case its uncertain parameters and ArcLang draws them as a Latin hypercube, runs every sample in OpenModelica, and passes the case only when the probability that the requirement holds is shown to reach the one required, at the confidence you ask. The gate takes that verdict. R or Python read the same samples for the statistics an engineer wants next.

$ arclang verify ev_range_simulation.arc
✓ TC-RANGE-LR "Winter range, long range pack": PASS
    Monte Carlo: 40 samples, 40 hold
    probability between 92.78 % and 100 % at 95 % confidence
    what moves the charge left:
        -0.88  speedController.target_speed
        +0.50  vehicleBody.ambient
VS Code with an ArcLang model on the left, a test case that samples the outside air and the cruising speed, and on the right its Monte Carlo results: a failing verdict, the probability interval below the 90 % required, a histogram of each margin with its bound and the failing samples in red, and the parameters that move each margin

In VS Code, the test case and its results side by side: 200 OpenModelica runs of the standard pack, from −20 to 30 °C and 75 to 115 km/h. 154 hold, so the probability lies between 71.6 % and 81.8 %, below the 90 % required: the requirement is not verified. The cruising speed drives the charge left (−0.94).

VS Code with GitHub Copilot Chat: the engineer asks @arclang for a Monte Carlo test case on the range envelope, and @arclang answers with a test case that samples the outside air and the cruising speed in 300 samples at 0.99 probability, compiled by arclang before it is shown, then applied in the editor

@arclang in GitHub Copilot Chat writes the Monte Carlo case from one sentence: two laws, 300 samples, 0.99 at 95 % confidence. The compiler checks it before it is shown; one click puts it in the model.

The Monte Carlo page in VS Code after the analysis in R: for each margin, the share of failing samples, the failure probability of a normal fit, and the partial and standardized rank regression coefficients of each parameter with their intervals

R reads the same 200 samples without simulating again: partial rank correlations and standardized rank regression with bootstrap intervals, in base R.

A failing sample replayed on the physical architecture in the ArcLang workbench: each part shows its values, the battery pack is outlined in red at the instant its charge falls below 10 %, and a time bar names the failing expectation

A failing sample replayed on the diagram: the battery pack outlined in red at the instant its charge falls below 10 %.

USE CASEdata center · AI

Cooling an AI hall: ten scenarios, verified

An AI hall modeled in ArcLang, from the operational need to the physical architecture, then simulated: sixteen GPU racks on liquid cooling, from the cold plates to the dry coolers. A pump that stops at the hottest hour, a generator five minutes late, a leaking rack, racks of 200 kW: each is a test case simulated in OpenModelica, and each failure says what the design must change.

Read the use case →
The ArcLang diagram viewer on the physical architecture of an AI hall: GPU racks, coolant distribution unit, facility water loop, dry coolers and chiller, outdoor air and the cooling controller, joined by physical links and exchanges

04 / CAPABILITIES

Everything a systems team ships with — verified in CI, not promised.

TF-CORE

A compiler that never lies

Strict parsing with source positions, deterministic element identity (UUIDv5 — same id, same UUID, everywhere, forever), and semantic analysis that treats a dangling trace as a build failure. If it compiles, the traceability graph is real.

# identity is frozen by golden-value tests
LC-001 → 8006ab91-390c-5908-8464-b353219dfc1f
# …and cross-checked against an independent
# implementation, on every commit
VW-01new in 4.0

Diagrams you navigate, not redraw

The compiler draws one diagram per Arcadia viewpoint: operational, system, logical and physical architecture with functions inside their components and exchanges on their ports, plus capabilities, data, modes and states, scenarios and the product breakdown. Follow an element across layers to what it realizes, fold a container or open it as a diagram of its own, arrange blocks by hand. The arrangement is a file next to the model, so it is versioned and reviewed with it.

$ arclang diagram aeb.arc -f html -o aeb.html
✓ 9 kinds of view · one self-contained file
# Across layers
"SensorFusion"  satisfies    "REQ-AEB-002"
"SensorFusion"  realized by  "FusionModule"
# aeb.layout.json — folds and placement, in Git
EX-01zero diff

Capella round-trip

Import native Capella models (184 elements matched on the reference project), edit as text, sync back by UUID — the XML comes back byte-identical when nothing changed.

EX-02ISO 26262 · DO-178C

Production gate

One command answers "can we release this design?": requirement satisfaction and verification, ASIL recomputed from S/E/C, timing budgets summed along functional chains, ICD completeness.

EX-03

ReqIF exchange

OMG ReqIF import/export for the DOORS / Polarion loop: text, hierarchy and relations read, foreign identifiers kept on the way back.

EX-04

Simulink & FMI

System Composer architecture scripts, hierarchy and Stateflow included, and FMI 2.0 interface descriptions validated against the standard, GUIDs that change only with the interface.

EX-05

SysML v2, both ways

Imports any SysML v2 model, in one file or many, against the OMG standard library: connections, allocations, sequences and views. Exports every model, checked element by element against the OMG pilot. Open the Simple Vehicle Model of the specification.

LG-01

Multi-file models

import "subsystem.arc" — each team owns its fragment, the compiler assembles and cross-checks the whole. Circular imports and identity collisions are caught.

LG-02

Semantic diff

Model review as a change list of identities. CI-gateable: exit 1 on unreviewed model change.

LG-03new in 4.0

A typed metamodel

Quantities carry their unit and dimension, so a latency compared to a bandwidth is caught. Enumerations, multiplicities, constraint assertions and your own types with specialization. The metamodel document is generated from the compiler, and a test fails when the two disagree.

EX-06new in 4.0

Systems Modeling API

arclang serve exposes the model, element by element, with one API commit per Git commit and a diff by identity. Writes are opt-in, token-protected, and land as Git commits that keep your comments.

SC-01new in 4.3

Cybersecurity analysis

Primary assets, threats and their scales, at the level they belong to, as Capella's security viewpoint has them. They go to Capella and to SysML v2 and come back whole.

IDE-01new in 4.3

A workbench in VS Code

The model text on one side, its diagrams, tree and properties on the other, the same compiler behind both. Click or type: the file is the same, and an AI agent edits it through the compiler.

GIT-01new in 4.6

Semantic git: review and merge a model, not its lines

Compare a model with any revision by element identity, and the report carries what the change does: the gate before and after, the budget it breaks. Every element has a history. A merge driver merges two branches that touched different attributes of the same line, and marks a real conflict around the element. A baseline binds the gate verdict, the coverage and the exports to a git tag that an auditor can verify.

$ arclang diff brake.arc --from HEAD
~ modified SystemFunction 'Detect obstacle'
    latency: "40 ms" -> "80 ms"
Production gate: PASS -> FAIL
  + blocker: functional_chain 'Detection to braking':
    sum of function latencies 130.0 ms
    exceeds the 100.0 ms budget
$ arclang baseline verify v1.0
Baseline 'v1.0': VERIFIED
GIT-02new in 4.9

Branches, snapshots, merges and time travel

A bar along the workbench walks the model's history: each commit drawn as it was, the snapshots as flags, the merges as diamonds, and what changed since any earlier moment marked on the diagram. Restore one element or the whole model from the past as an edit you review; history is never rewritten. Branches merge by element: only an element changed differently on both sides needs a decision.

The ArcLang workbench in VS Code at the commit tagged v1.0, compared with the snapshot design-review-1: the driver monitor added since is outlined in green, the steering actuator modified in amber, the side panel lists both with the safety level going from ASIL-B to ASIL-C, and the timeline bar shows five commits with two snapshot flags and a merge

The model at v1.0, compared with the snapshot design-review-1: the driver monitor added since in green, the actuator raised from ASIL-B to ASIL-C in amber.

The workbench at the commit that added the driver monitor, the new component marked added in green, the timeline bar below

One commit back: the model as it was when the driver monitor was added.

A merge of two branches that both changed the steering actuator: the Resolve conflicts view names that element alone, and the file holds both versions of it, whole, between markers

A merge where both branches changed the actuator: that element alone is in dispute, each side whole.

CI-01new in 4.6

The gate in your pipeline

arclang ci init writes the pipeline for GitHub Actions, GitLab CI, Azure DevOps or Jenkins; the check named ArcLang gate can be required on the default branch. SARIF 2.1.0 goes to code scanning, and a pull request gets one comment, updated on each push. The generated files are tested as files; the first run on your provider is their test, and the documentation says so.

IM-02

Impact analysis, and the what-if before the edit

What a change reaches, by link and by distance, with the path that explains it. arclang impact --change applies a proposed edit to a copy, compiles it, and says what it would break before you touch the model. In VS Code the same analysis is a live tab, with Apply as one undo.

The impact analysis in VS Code: what if the latency of the sensor fusion function were 80 ms. Computed on a copy, nothing written: the production gate goes from PASS to FAIL, the braking chain is 145 ms against its 100 ms budget, the constraint is violated, with Apply the change and Discard buttons, counts by severity, layer and category, and the graph of what is reached

What if the sensor fusion took 80 ms? Computed on a copy before anything is written: the gate goes from PASS to FAIL, the braking chain needs 145 ms against its 100 ms budget. Apply the change writes it as one undo; Discard leaves the model untouched.

TB-01

Live tables and matrices

Requirement coverage with the verdict of each test case, traceability, allocation, N² interfaces and the ICD, computed by the compiler. Edit a cell and the model changes; export CSV or Excel, or paste into PowerPoint.

AI-01

An AI you choose, a compiler that decides

Eight providers, from VS Code's own models to Anthropic, OpenAI, Mistral, Google, Azure, a local Ollama or any compatible server. Every proposal is compiled on a copy first, and Apply is one undo. Off sends nothing.

MB-01mobile

An architecture studio in your pocket

On a phone, the playground becomes an AI design studio: describe a system — or photograph a whiteboard — and read the compiled architecture dossier on the spot. The same verified compiler, anywhere. Try that with a desktop MBSE suite.

you> 📎 whiteboard.jpg — "model this"
ai>  6 components, 4 requirements, deployed
✓ compiled — GATE PASS · dossier ready to share
# from the back of a taxi
IM-01handoff

From architecture to first commit

The model becomes code you can build on — contracts only, never invented behavior. Deterministic exports ship C99 headers that compile clean and Protobuf that turns into Java, C++, Python, Go or TypeScript via protoc. And the AI assistant reads your stack: an FPGA node gets VHDL entities, CAN links get C plus a DBC sketch, a JVM service gets gRPC interfaces — proposed in context, generated on demand, downloaded in one tap.

# the assistant reads your architecture
node "SignalFPGA"   → "Want the VHDL entities?"
link protocol: CAN  → "C headers + DBC matrix?"
node "OrderService" → "gRPC + Java interfaces?"
⬇ interfaces.vhd · interfaces.h · interfaces.proto
ArcLang diagram viewer on the logical architecture of an automotive emergency braking system: one tab per viewpoint, the model tree, components with their functions, ports and exchanges, and for the selected component the requirement it satisfies and the physical components that realize it

The logical architecture of the AEB reference model, drawn by the compiler: functions inside their components, exchanges on their ports, ASIL badges. Sensor Fusion is selected, with what it satisfies and what realizes it one layer down. Click through to compile it yourself.

05 / TRUST

Built to be depended on for thirty years.

Aerospace and automotive programs outlive tools. ArcLang's governance is designed for that timescale.

Qualification-ready

A tool-qualification support kit ships in the repository: ISO 26262-8 §11 TCL analysis, DO-330 TQL determination, function/malfunction inventory, and an evidence matrix into the actual test suite.

Verifiable supply chain

MIT-licensed. RustSec dependency audit on every commit. Releases ship binaries with SHA256SUMS and GitHub build-provenance attestations.

Stability guaranteed

The language is semver'd and a major version ships with its migration note, identity derivation is frozen by golden tests, and every output is deterministic: a diff always means a change, never noise.

06 / OFFER

Free where it spreads. Paid where it matters.

FREEMIT

Open source — forever

The language, the compiler, the CLI, the gate and this playground. Attested releases, qualification support kit in the repo. No lock-in is the feature: your models are text files you own.

TEAMearly access

Team workspace

Hosted model review with visual semantic diff, gate dashboards per program, ReqIF exchange flows, SSO. Built for suppliers and design offices.

Get early access →
ENTERPRISEon-prem

Enterprise, air-gapped

On-premise deployment, long-term support, tool-qualification assistance (ISO 26262-8 / DO-330), Capella migration services and training. Advanced interface generators on the enterprise roadmap: AUTOSAR ARXML, DDS IDL, Ada/SPARK specs, CAN DBC matrices.

Talk to us →
AI

AI-native by design

The playground ships an AI design assistant: describe your system, the model writes ArcLang, the compiler verifies it — the loop runs until the gate passes. And because ArcLang is text with a strict compiler, it's what makes AI-assisted systems engineering safe: the AI proposes, the compiler never lies. An MCP server ships in the repository for Claude and other assistants.

you> design a battery management system, ASIL-C
ai>  writing model… 4 components, 6 requirements
✓ compiled in 3 ms — GATE PASS (6/6 verified)

07 / TRY IT

The full compiler runs in your browser. Your model never leaves it.

The playground is the real ArcLang compiler — the same Rust core as the CLI — compiled to WebAssembly. Compilation, validation, the safety gate and the architecture explorer all execute client-side. Nothing is uploaded, ever. Paste a confidential model with a clear conscience. And it works on your phone: sketch, describe, review — the full toolchain fits in your pocket.