OpenSysML

OpenSysML MDK — Runtime Environment and Development Kit

The OpenSysML Runtime Environment and Development Kit (OpenSysML MDK) is a SysML v2 and KerML 1.1 implementation in Go. It provides a language server, an interactive REPL, an execution runtime, an embeddable Go API, and Python, Node/TypeScript, Java, Rust, Julia and MATLAB client libraries, covering the lifecycle from authoring through execution with the integrated tooling systems engineers expect from a modern language ecosystem. It is the runtime of OpenSysML, the open source SysML v2 suite of the OpenMBEE community; this repository is the MDK, and the pages below use "OpenSysML" for it where no confusion with the suite is possible. The MDK is the second generation of OpenMBEE's Model Development Kit, expanded and updated for SysML v2; its Cameo plugin is OpenSysML MDK for Cameo.

It runs the model. A validator reads declarations; an expression evaluator computes a value from the ones it is handed. OpenSysML materializes the instances a model describes, evaluates their features through the whole part tree with units carried and checked, performs actions on those objects and advances state machines on a clock, and decides requirements, analysis objectives and satisfaction claims against what it finds. Because it runs the model, it finds what reading cannot: a mass rollup whose one unvalued leaf makes the total incomputable, a calculation whose result comes out in the wrong dimension, a well-formed action with no step to start at. The runtime showcase is a set of small models built around exactly those questions, run and reported; the first of the examples below is the shortest version.

It is fast. The public Apollo 11 SysML v2 model — 28 files, 7,200 lines — parses in 8 ms (42 MB/s on one core) and loads, resolves and validates against the full standard library in 0.27 s. The measurement and how to repeat it are in performance. The same model is where the runtime earns its keep: the pinned OMG pilot validator passes it without a finding and OpenSysML reports no error, yet its calculations and its mission action each stop at a defect only execution reaches — see the showcase's Apollo 11 section.

The basis for these claims, and their limits, are documented in spec compliance and the pilot differential: every diagnostic is compared against the pinned OMG pilot implementation over that implementation's own corpora, and no conformance certification is claimed.

Quick start

Introductory material: the guide and the document generation manual

Complete searchable documentation: https://runtime.opensysml.org/ — the same pages as docs/, rendered from develop.

Install

Install script — picks the release build for this machine, verifies it against the release's SHA256SUMS.txt, and installs sysml and sysml-lsp:

# Linux and macOS: /usr/local/bin when writable, otherwise ~/.local/bin
curl -fsSL https://opensysml.org/install.sh | sh

# Windows: %LOCALAPPDATA%\Programs\OpenSysML, added to the user PATH
irm https://opensysml.org/install.ps1 | iex

Both scripts take a release (--version v0.9.1, nightly), a tool list (--tools sysml, sysml-lsp, sysml-grpc, sysml-jupyter-kernel, sysml-mcp, or all for every tool the chosen release published, read from its SHA256SUMS.txt) and a destination (--prefix, or -InstallDir on Windows), and --dry-run shows the choice without installing; sh -s -- --help lists the rest. The scripts are install.sh and install.ps1 in this repository, so a checkout runs them as ./install.sh.

Download pre-built binaries by hand:

# Linux x64 (use opensysml-linux-arm64.tar.gz on arm64)
wget https://github.com/Open-MBEE/OpenSysML/releases/latest/download/opensysml-linux-amd64.tar.gz
tar xzf opensysml-linux-amd64.tar.gz && sudo mv sysml sysml-lsp /usr/local/bin/

# macOS (Intel or Apple Silicon) — see the note below
brew install Open-MBEE/tap/opensysml

With a Go toolchain (no download, never quarantined):

go install github.com/Open-MBEE/OpenSysML/cmd/sysml@latest
go install github.com/Open-MBEE/OpenSysML/cmd/sysml-lsp@latest

sysml -version then reports the release it was built from (sysml v0.11.0), or the commit when installed from a checkout.

Or build from source:

make build
./bin/sysml

macOS — use the install script or Homebrew. The released binaries are not Developer ID signed or notarized, so a tarball downloaded in a browser carries com.apple.quarantine and Gatekeeper shows "cannot be opened because the developer cannot be verified". The install script and Homebrew both download with curl, which never sets that attribute, so neither meets the prompt. When the tarball is downloaded directly (curl -fL ... opensysml-darwin-arm64.tar.gz, followed by xattr -d com.apple.quarantine), see the guide. Signing and notarization are the intended long-term resolution — docs/project/macos-distribution.md.

Install by the fully-qualified name. Homebrew 6 requires third-party taps to be trusted before their Ruby is loaded, and brew install Open-MBEE/tap/opensysml trusts just that formula. brew tap Open-MBEE/tap && brew install opensysml needs brew trust --formula Open-MBEE/tap/opensysml in between.

Examples

A model that runs. saturnIBAscent is an analysis case bound to a two-stage rocket; its outputs are computed from the rocket equation over the stages' masses and specific impulses, with units, and its objective is a requirement. Arguments in parentheses rebind its inputs:

$ sysml -quiet -analysis DeltaVBudget::saturnIBAscent examples/runtime-showcase/delta-v-budget.sysml
✓ package DeltaVBudget
✓ DeltaVBudget::saturnIBAscent
  stage1DeltaV = 3037.6966629706967 [SI::'m/s']
  stage2DeltaV = 6432.955324716369 [SI::'m/s']
  margin = 70.65198768706614 [SI::'m/s']
  objective reachesOrbit: satisfied
  standing: value (observed: 1 run under reverse)

$ sysml -quiet -analysis "DeltaVBudget::saturnIBAscent(required = 9800 ['m/s'])" examples/runtime-showcase/delta-v-budget.sysml
✓ package DeltaVBudget
✗ DeltaVBudget::saturnIBAscent(required = 9800 ['m/s'])
  stage1DeltaV = 3037.6966629706967 [SI::'m/s']
  stage2DeltaV = 6432.955324716369 [SI::'m/s']
  margin = -329.34801231293386 [SI::'m/s']
  objective reachesOrbit: not satisfied: margin > 0 ['m/s']
  standing: value (observed: 1 run under reverse)

The same file's InjectionDeltaV types a gravitational parameter as a force. Every name resolves and every operator applies, so validation passes it; the runtime computes the number and refuses to store it as a speed:

$ sysml -quiet -calc "DeltaVBudget::InjectionDeltaV(3.986E14 [SI::N], 6563000 [SI::m], 384400000 [SI::m])" examples/runtime-showcase/delta-v-budget.sysml
✓ package DeltaVBudget
sysml: calc invocation failed: calc DeltaVBudget::InjectionDeltaV: result: type mismatch: cannot write 3135.1638390999387 [kg**0.5/s] (dimension M^0.5·T^-1) to a feature typed by SpeedValue (dimension L·T^-1)
  standing: not covered (…)

The runtime showcase continues from here: a recursive mass rollup, a reliability requirement asserted of two missions, a mission action that branches on its remaining budget, a clocked state machine, and the Apollo 11 model under the same tool.

Interactive modeling:

$ sysml
sysml> part def Wheel { attribute diameter = 16.0; }
✓ part def Wheel

sysml> %instantiate Wheel
✓ Created instance of Wheel
  ID: 1
  Use %features Wheel to inspect

sysml> %features Wheel
Instance: Wheel (ID: 1)
Features:
  diameter = 16.0
  ownedPorts = []
  performedActions = []
  ownedActions = []
  exhibitedStates = []
  ownedStates = []
  shape = []
  envelopingShapes = []
  boundingShapes = []
  voids = []
  isSolid = true
  subitems = []
  subparts = []
  checkedConstraints = []

Behavioral execution:

sysml> calc add { in x; in y; x + y }
✓ calc add

sysml> %calc add 10 20
✓ add(10, 20)
  = [30]
  standing: value (observed: 1 run under reverse)

sysml> constraint ValidSpeed { 65 <= 120 }
✓ constraint ValidSpeed

sysml> %constraint ValidSpeed
✓ Constraint ValidSpeed passed
  standing: holds (observed: 1 run under reverse)

Action & state debugging:

sysml> action MyWorkflow { attribute result = 0; first start; then action compute { assign result := 42; } then done; }
✓ action MyWorkflow

sysml> %action MyWorkflow
✓ Started action executor for "MyWorkflow"
  State: Running
  Tokens: 1

Use %step to advance, %tokens to inspect, %continue to run to completion

sysml> %break compute
✓ Breakpoint set at node "compute"
  %continue runs until a token reaches it

sysml> %continue
⏸ Paused at breakpoint "compute"
  State: Suspended
  Tokens: 1

Use %tokens to inspect, %step or %continue to resume

sysml> %tokens
Active tokens (1):
  Token 1 @ compute
  Values:
    result = 0

sysml> %continue
✓ Action completed
  Final state: Completed
  Results:
    result = 42

sysml> state TrafficLight { entry; then red; state red; state green; transition first red then green; }
✓ state TrafficLight

sysml> %state TrafficLight
✓ Started state machine executor for "TrafficLight"
  Current state: red
  Time: 0.0
  Events: 1

Use %events to see queue, %current for state, %advance <time> to step

sysml> %advance 30
✓ Advanced to 30.0 (1 event(s) processed)
  Current state: green
  Last event at: 0.0
  Remaining events: 0
  Action state: Completed
  Tokens: 0
  The action runs in a context of its own, whose clock advanced from 0.0 to 30.0

✓ Action completed
  Results:
    result = 42

Further demonstrations are available in examples/repl-behavioral-demo.sysml.

Overview

The project provides the tooling familiar from the Python, Rust and Go ecosystems, applied to SysML v2:

• Execution Runtime — More than a validator: instantiate parts, evaluate constraints against concrete values and execute calc and analysis cases. Actions and state machines run for the subset the compliance map lists (activity fork/join parallelism, decision guards, hierarchical/orthogonal states, choice/junction pseudostates, TimeEvent/ChangeEvent/AcceptEvent, sourceless transitions); every conformance case passes, self-assessed against the Kernel Semantic Library, since no external referee executes behavior. A default run is one tool-chosen linearization of the order the model states, and explore/check show the whole set, up to their budgets (a result that hit one says so). See spec compliance for the measured behavioral coverage and the runtime showcase for what running a model finds that validating it cannot.
• Language Server — A standard LSP server (sysml-lsp) with live diagnostics, semantic hover, go-to-definition, find references, completion, signature help, workspace-wide symbol search, formatting, rename, semantic tokens, quick fixes, code lenses and inlay hints. A VS Code extension with TextMate grammars for .sysml and .kerml ships in editors/vscode — its diagram panel draws the model beside the editor with zoom, pan and fit, click-to-select highlighting, show/hide of relationship kinds, drag-to-layout and an ELK auto layout that writes nothing — and any editor with a generic LSP client can drive the server directly — guide chapter 8 walks through both. Not yet: the extension is not on a marketplace — install the nightly opensysml-sysml.vsix or build it from source — and the server answers no semantic token delta requests.
• Interactive REPL — An exploratory modeling environment: define models incrementally, evaluate expressions interactively, instantiate parts, run calculations and inspect runtime state, comparable to IPython or Jupyter for systems engineering.
• Jupyter Kernel — sysml-jupyter-kernel runs the REPL session behind the Jupyter protocol, so notebook cells hold SysML: declarations accumulate across cells, expressions evaluate, every % command works as at the prompt, and views and documents render as Mermaid, SVG, Markdown, tables, HTML or JSON. pip install jupyter-opensysml-kernel && python -m jupyter_opensysml_kernel install registers it (guide chapter 12).
• MCP Server for Coding Agents — sysml-mcp serves the toolchain to OpenCode, Claude Code, Cursor, Codex, VS Code Copilot, Gemini CLI, Devin and any other Model Context Protocol host over stdio: the language server's workspace, the runtime's one-shot service and persistent REPL sessions as tools an agent calls. npx -y @openmbee/sysml-mcp runs it with nothing preinstalled, sysml-mcp -http 8765 serves one long-lived server over Streamable HTTP for remote agents or several agents over one workspace (loopback as it is, any other address behind a bearer token), and sysml-mcp -print-config <host> writes the host's configuration block, in URL form with -http (MCP server reference).
• Constraint Solving (experimental) — In addition to evaluating what holds of an object, an external SMT solver determines whether a constraint, requirement or satisfaction assertion can hold, which conditions conflict when it cannot, which values would satisfy it, which variants a model permits, and what optimizes an analysis def's objectives. The solver is optional and discovered at runtime. The REPL command reference documents each command, and installing a solver describes how to obtain one. The design follows OpenMBEE's HMF (see Acknowledgements).
• Embeddable Go API — client/opensysml is the public Go surface: parse, look up symbols, evaluate expressions and instantiate parts from Go code, answered in process by the engine the calling binary already links (no port, no child process and no serialization round trip), or over the Connect protocol against an externally hosted service. See client/opensysml/README.md.
• Python Client Library — gRPC-based Python bindings for programmatic access: parse models, resolve symbols, evaluate expressions, instantiate parts, execute actions/state machines. Includes IPython display hooks for Jupyter notebooks and pandas DataFrame integration. Constraint, requirement, satisfaction and calc verdicts are available as RPCs (verify_constraint, verify_requirement, verify_satisfaction, calc).
• Node/TypeScript Client Library — @openmbee/opensysml for Node and the browser, over the Connect protocol with protobuf bodies: parse, evaluate, look up symbols and instantiate, with values as discriminated unions. No native addon; npm installs a per-platform optional dependency with the service binary (client/node/README.md).
• Java Client Library — org.openmbee:opensysml for a JVM host application it does not own, on the JDK's own java.net.http.HttpClient, so no gRPC, Netty or tcnative reaches the host (client/java/README.md).
• Rust Client Library — A blocking client for the local sysml-grpc service, with no asynchronous runtime in its default dependency tree, available from the Rust crate documentation.
• Julia Client Package — OpenSysML, a thin JSON-over-HTTP client (HTTP.jl + JSON.jl only) for Julia 1.10+: parse, evaluate, instantiate, execute and query, with call reaching the whole RPC surface (client/julia/OpenSysML/README.md).
• MATLAB/Octave Client Package — +opensysml, the same thin JSON-over-HTTP client for MATLAB R2019b+ and GNU Octave 7+, so the environment a modeler already runs talks to the service directly (client/matlab/README.md).

Guidance on selecting a client, the coverage of the six clients, and the functionality they intentionally defer to a future version is provided in docs/reference/clients.md.

• Modern Toolchain — Incremental compilation, a bundled standard library and persistent semantic caches. A model is a set of files, named on the command line or opened by the editor.

Goals

• Performance: sub-millisecond parsing, a single static binary, and no JVM or Eclipse runtime
• Completeness: SysML v2 textual notation support (110 of 110 standard library files parse cleanly: 94 vendored OMG files and 16 OpenSysML extensions)
• Executable models: instantiate, evaluate and simulate, turning specifications into running systems
• Practical ergonomics: multi-file workspaces, incremental analysis and detailed diagnostics

Status

The project is under active development, with the core infrastructure operational:

Measured against the pinned reference (PILOT_TAG=2026-08, artifact 0.62.0). Every number below is generated by make docs-counts from the committed baselines and gated; none of them is typed in by hand.

• Corpus agreement: 515 of 916 files agree diagnostic-by-diagnostic; 366 diagnostics are ours alone and 2444 the reference's alone, and the first number must be read by root: the aggregate includes candidate conformance differences, intentional execution-scope warnings on reference corpora and diagnostics from our own examples (differential, go run -C tools ./cmd/pilot-diff).
• Declared-diagnostic silence: of the 512 declared errors rows in the reference's own Xpect suites, we report nothing for 0. 245 we report word-for-word; 248 wording-only and 7 location-only differences are agreement in substance and are not counted as gaps; 0 more we report as a warning and 2 elsewhere in the file (Xpect oracle, go run -C tools ./cmd/pilot-xpect).
• Scope agreement: 230 of 230 declared scope assertions match exactly (same source).
• Permissiveness gaps: of 344 invalid models we wrote ourselves, the reference rejects 4 that we accept by default, and 328 both reject; 4 further cases agree only when we are asked strictly. We authored every one of these cases ourselves, so the denominator measures the reach of our own corpus and not our conformance; agreement reached only under an opt-in strict mode is weaker evidence than agreement by default (rejection oracle, go run -C tools ./cmd/pilot-reject).
• Declared errata: the registry declares 16 defect(s) in the published reference material — 9 with a specification-derived correction, 7 documented without one, since no intended reading can be inferred (OMG issues, tools/oracle/errata). Every figure above is as published and stays the conformance statement; running the same oracles over the corrected text instead reports 516 of 916 files agreeing, 365 diagnostics ours alone and 2444 the reference's alone, 0 declared rows we are silent on, and 0 of 344 authored cases the reference alone rejects. The corrected figures are diagnostic only: an erratum never reclassifies a divergence category, and the published corpus is never edited.
• Self-assessed surface: the action, state-machine and classifier-behavior rows have no external referee at all — the four refereed figures above cannot see them, because the pinned artifact evaluates expressions but executes neither actions nor state machines. Spec compliance counts them.

What these numbers cannot show: the OMG corpora are demonstrations rather than an official conformance suite; the differential is one-directional, comparing the diagnostics the two implementations report on the same files; the Xpect suites are the pilot authors' test intent rather than a certification oracle; and none of these is a percentage of the specification — no global compliance figure is claimed anywhere.

Row bookkeeping: the ✅/⚠️/❌/⛔ status of each tracked rule stays in spec compliance as a census of our own row list, counted when the documentation site is built rather than committed. It moves when rows are rewritten and does not move when an oracle does, so it is not the progress measure.

Current commit: All tests pass (go test -race ./...), builds clean (go build ./...). Test coverage: top-level Test functions (counted from the _test.go files, as go test ./... runs them) covering parsers, semantics, runtime (actions, states, instances, operators, validation), behind golden ASTs, negatives, execution conformance cases, golden traces, runtime robustness cases and gRPC conformance and robustness cases. The figures are counted from the tree when the documentation site is built into the test inventory of spec compliance, never committed, so a branch adding a test does not rewrite this page. A test skips only for want of something the run did not provide, and says what: the held-image round trip declines a conformance case that creates no instance, a few gate on a PDF or Mermaid toolchain, a pinned pilot artifact, the PSSM suite, a locale, a case-insensitive filesystem or a live Flexo stack, and the OMG corpus gates skip until the corpora are downloaded unless asked to fail. Parser coverage: 110/110 bundled library files parse cleanly — the 94 official SysML v2 standard library files and the 16 non-normative OpenSysML extensions: OpenSysML Libraries/AnalysisRecords.sysml, DiagramLayout.sysml, DocumentQueries.sysml, IdentityMetadata.sysml, MOSA.sysml, MigrationMetadata.sysml, OOSEM.sysml, OpenSysMLMathFunctions.kerml, OpenSysMLRenderings.sysml, RandomFunctions.kerml, Simulation.sysml, StateActivity.kerml, StateMachines.sysml, StateSpaceIntegration.sysml, Stochastic.sysml and SysMLValidation.sysml. Conformance verified by stdlib_conformance_test.go. Grammar reference: OMG Xtext grammar. Behavioral execution: Calc/constraint/requirement/satisfy functional. Action/state executors handle nested invocation, control flow keywords, loop and conditional statements and the send statement (every conformance case passing). Coverage is self-assessed against the specification text and the normative library: the pinned OMG pilot implementation evaluates expressions but does not execute actions or state machines headlessly, so no external implementation currently adjudicates these rows. See spec compliance. Reference differential: 916 files compared diagnostic-by-diagnostic against the pinned OMG pilot implementation (2026-08), 515 in full agreement; every divergence is enumerated and adjudicated in the differential, reproducible with go run -C tools ./cmd/pilot-diff. Rejection oracle: the reverse direction — do we reject what the reference rejects? 344 hand-written invalid models validated by both implementations, 332 rejected by both, 0 the pinned pilot rejects and we accept; the remainder only we reject — the control-node succession rules the pinned pilot leaves unimplemented and a non-Boolean succession guard it accepts once the standard library types it — and every permissiveness gap is enumerated with a reproducer and likely root cause in the rejection oracle, reproducible with go run -C tools ./cmd/pilot-reject. We wrote every case, so the count measures our coverage of the rejection surface, not our conformance — a sample, not a proof. Training examples: 100/100 files report no semantic errors, gated by tests/corpus/testdata/training_examples_expected.txt; the gate does not count execution-scope warnings. Download with ./scripts/download-training-examples.sh (from the OMG training directory). See training examples for analysis. Semantic layer: a complete implementation of runtime operators, feature chains and validation rules. See examples/semantic-layer/ for a full demonstration.

Architecture

┌─────────────────────────────────────────────────────────┐
│  Frontends: LSP Server │ Interactive REPL               │
├─────────────────────────────────────────────────────────┤
│  Workspace: Multi-file documents, incremental reindex   │
├─────────────────────────────────────────────────────────┤
│  Semantic Engine: Types, resolution, validation         │
├─────────────────────────────────────────────────────────┤
│  Execution Runtime: Expressions, instances, behaviors   │
├─────────────────────────────────────────────────────────┤
│  Parser/Lexer: Hand-written recursive descent           │
├─────────────────────────────────────────────────────────┤
│  AST: Syntax-only, immutable (semantics in side tables) │
└─────────────────────────────────────────────────────────┘

Key design principles:

• Incremental and lazy: parse immediately and resolve semantics on demand, following the precedent set by gopls and rust-analyzer
• Immutable AST: all semantic state resides in side tables keyed by node or symbol
• Pluggable validation: tiered passes (syntax → names → types → constraints)
• Separated concerns: the static analysis pipeline feeds the execution runtime

Module structure

github.com/Open-MBEE/OpenSysML
├── cmd/
│   ├── sysml/              # Interactive REPL and CLI binary
│   ├── sysml-lsp/          # LSP server binary
│   ├── sysml-grpc/         # Service binary the clients talk to (gRPC, gRPC-Web, Connect)
│   ├── sysml-jupyter-kernel/ # Jupyter kernel binary
│   ├── sysml-mcp/          # Model Context Protocol server binary for coding agents
│   ├── sysml-wasm/         # Combined WebAssembly module
│   └── sysml-engine/, sysml-core/, sysml-syntax/   # Smaller WebAssembly builds
├── internal/               # One directory per layer; a package imports only the layers below it
│   ├── syntax/             # source, diag, lexer, parser, ast, pack, format, semtok
│   ├── semantic/           # symbols, resolve, suggest, semantics, identity, highlight, query
│   ├── ir/                 # lower, queryplan, docplan, view, imagefile
│   ├── check/              # passes, edit
│   ├── exec/               # runtime, solve, smt, analysis, engines, objref, fmi, hostcap, ingest, runtrace, simresults
│   ├── translate/          # rdf, export, xmi, mtip, migrate, deferred, convert, codegen, interop, fmi, filename
│   ├── doc/                # queryexec, docir, docrender, docpdf
│   ├── workspace/          # model, modeldoc, modelrt, notebook, libs, project, envvar
│   └── frontend/           # core, engine, combined, protoconv, grpc, jsonrpc, lsp, repl, jupyter, stdiorpc, symbolfacts, syntax, buildinfo, usage
├── client/opensysml/       # The public Go API (in-process and remote)
├── client/java/           # Java client (org.openmbee:opensysml)
├── client/node/           # Node/TypeScript client (@openmbee/opensysml)
├── client/python/         # Python client bindings (opensysml)
├── client/rust/           # Rust client (opensysml) and its conformance runner
├── client/julia/          # Julia client package (OpenSysML) and its conformance runner
├── client/matlab/         # MATLAB/GNU Octave client (+opensysml) and its conformance runner
├── docs/                   # Design specs, architecture docs
└── tests/                  # Black-box suites, benchmarks, shared fixtures (tests/parser, tests/testdata, …)

Technology

• Language: Go 1.25 or later (goroutines for concurrency, a single static binary, and an established record in language servers)
• Parser: hand-written recursive descent (no framework overhead, full error recovery, sub-millisecond parses)
• Grammar source: OMG pilot Xtext grammars (SysML.xtext and KerMLExpressions)
• Spec compliance: OMG SysML v2.1 Beta 1 / KerML 1.1 (2026-08 release)
• Standard library: 94 files from SysML v2 Pilot Implementation 2026-08, byte-identical, plus the sixteen non-normative OpenSysML Libraries/ extensions (OpenSysMLMathFunctions, DocumentQueries, IdentityMetadata, DiagramLayout, OOSEM, MOSA, StateSpaceIntegration, Stochastic, RandomFunctions, Simulation, MigrationMetadata, AnalysisRecords, OpenSysMLRenderings, StateMachines, SysMLValidation and StateActivity). The extensions are maintained upstream at Open-MBEE/OpenSysML-Extensions-Library — for any SysML v2 tool — and vendored here pinned by scripts/extension-libraries-pin.sh (pin, sync and contract)
• CI/CD: GitHub Actions checks pull requests; CircleCI builds and tests main and develop and publishes releases from tags

Releases

Pre-built binaries for Linux, macOS, and Windows are available on the Releases page.

Supported platforms:

• Linux (x64, ARM64)
• macOS (Intel, Apple Silicon)
• Windows (x64)

Release process:

• Every commit: build and test
• Tagged releases (v*): the suite runs again on the tagged commit, then multi-platform binaries are published to GitHub Releases. Maintainer procedure: docs/project/releasing.md; what changed per release: CHANGELOG.md
• The Python client is released by the same v* tag, which uploads opensysml to PyPI at the core's version — v0.9.0 publishes opensysml 0.9.0 — so pinning one version (pip install opensysml==0.9.0, OPENSYSML_GRPC_VERSION=v0.9.0) gets the package and the sysml-grpc binary that were tested together
• The Java client is released by the same v* tag, whose release workflow signs and uploads org.openmbee:opensysml to Maven Central at the core's version; no release is on Central yet, so until one is, install the client from a checkout
• The Node client is released by the same v* tag, which publishes @openmbee/opensysml and the five per-platform packages that carry the service binary at the core's version
• The Rust client is released by the same v* tag, which publishes opensysml to crates.io at the core's version
• client/opensysml, the public Go API, requires no release of its own. It is part of this module, so a Go program pins it with go get github.com/Open-MBEE/OpenSysML@v0.3.0

Release artifacts: per-binary archives (sysml-<os>-<arch>.tar.gz, sysml-lsp-<os>-<arch>.tar.gz), opensysml-<os>-<arch>.tar.gz bundles containing both binaries, sysml-mcp-<os>-<arch>.tar.gz (.zip on Windows) with the MCP server, its manual page and the LICENSE, and SHA256SUMS.txt. Windows also gets an installer, opensysml-<x.y.z>-windows-amd64.msi (sysml, sysml-lsp, sysml-grpc, sysml-mcp, optional bundled Z3 solver; see packaging/msi), built by the GitHub Actions release workflow after CircleCI publishes the release, with its digest in SHA256SUMS-windows-msi.txt. macOS binaries are not Developer ID signed or notarized; see docs/project/macos-distribution.md. Windows binaries and the MSI are Authenticode signed through SignPath Foundation once the project's application is approved; the signed files are published as separate *-signed* assets beside the unsigned ones that SHA256SUMS.txt covers. See the Code signing policy.

Code signing policy

Free code signing provided by SignPath.io, certificate by SignPath Foundation.

The Windows binaries (sysml.exe, sysml-lsp.exe, sysml-grpc.exe, sysml-mcp.exe) of a tagged release are built by the GitHub Actions workflow .github/workflows/release-windows.yml from the tagged commit of this repository and submitted to SignPath for signing from that workflow, so every signed file traces back to a public commit and a public build log. The signed files are published on the GitHub release as sysml-windows-amd64-signed.zip, sysml-lsp-windows-amd64-signed.zip, sysml-grpc-windows-amd64-signed.exe, sysml-mcp-windows-amd64-signed.zip, opensysml-windows-amd64-signed.zip and the installer opensysml-<x.y.z>-windows-amd64-signed.msi (built from the signed executables and itself signed), with their digests in SHA256SUMS-windows-signed.txt. Every signed executable carries ProductName OpenSysML and the release tag as ProductVersion/FileVersion. The Z3 solver the MSI optionally bundles is upstream open-source software and is never signed with the Foundation certificate; the installer carries it unsigned, as the SignPath Foundation terms allow. Signing is not in effect until the project's SignPath application is approved; releases made before that carry only unsigned Windows assets (including the unsigned MSI).

Team roles

• Authors may commit to this repository without additional review: @Open-MBEE/opensysml-authors.
• Reviewers review all pull requests from non-committers before they are merged: @Open-MBEE/opensysml-reviewers.
• Approvers approve each signing request in SignPath before a certificate is applied; a release ships no signed Windows binaries without that manual approval: @Open-MBEE/opensysml-approvers and the owners of the Open-MBEE organization.

All Authors, Reviewers and Approvers must have multi-factor authentication enabled on their GitHub accounts and on their SignPath accounts.

Privacy policy

This program will not transfer any information to other networked systems unless specifically requested by the user or the person installing or operating it.

In particular, none of sysml, sysml-lsp and sysml-grpc checks for updates, collects telemetry or downloads anything on its own. The only network activity any of them performs is what the operator asks for by name: sysml-lsp speaks only over its standard input and output, sysml-grpc serves the address it is started with and answers only the clients that connect to it, sysml -sync-diff / sysml -sync-apply contact a SysML v2 API / Flexo MMS repository only when the operator names that endpoint's http:// or https:// URL on the command line, and sysml -convert reads or pushes a Flexo MMS project branch only when the operator names its branch URL (http(s)://…/projects/{p}/branches/{b} or flexo://{p}/{b}) there. The OMG pilot corpora and reference tools used by the test suite are fetched by developer scripts under scripts/, which are not part of the shipped binaries.

Building

# Build all binaries
go build ./...

# Run tests
go test ./...

# Build LSP server
go build -o bin/sysml-lsp ./cmd/sysml-lsp

# Build REPL
go build -o bin/sysml ./cmd/sysml

# Build gRPC service
go build -o bin/sysml-grpc ./cmd/sysml-grpc

Test and conformance reports

Both cross-implementation harnesses write their results in machine-readable form as well as prose, so a CI system can render them without parsing text:

make conformance      # bin/conformance-report.json + bin/conformance-report.xml
go run -C tools ./cmd/conformance -report - -junit bin/conformance-report.xml
go run -C tools ./cmd/pilot-diff   # build/pilot-diff/pilot-diff.{txt,json,xml,sarif}

• JSON stays the source of truth for both: aggregate totals, and per scenario or per file every outcome, status, duration and mismatch. The other renderings are derived from the same run.
• JUnit XML — bin/conformance-report.xml holds one suite per configuration and protocol and one case per scenario, so CI shows per-scenario results in its own test report; build/pilot-diff/pilot-diff.xml holds one suite per corpus root and one case per file that drew a diagnostic. CI stores the conformance XML as test results on every run, pass or fail.
• SARIF 2.1.0 — build/pilot-diff/pilot-diff.sarif carries one result per disagreeing diagnostic group, located on the compared model file, for a code-scanning viewer.

The suites themselves are described in conformance/README.md and the pilot differential; nothing in the differential gates CI.

Clients

Seven surfaces reach the same engine: the Go API, used in the calling process, and six clients of the sysml-grpc service. Client libraries states what each covers and how to choose; guide chapter 9 works through each one.

The Go and Python clients cover every RPC the service serves; Node, Java and Rust cover a v1 subset — connection lifecycle, capability negotiation, parsing, diagnostics, symbol lookup, evaluation and instantiation — enumerated in the client libraries page.

Python

opensysml is a Python client library providing programmatic access to OpenSysML's parsing and runtime capabilities over gRPC.

Installation:

pip install opensysml          # from PyPI

# Or from a checkout, in development mode
pip install -e client/python/

Quick example:

import opensysml

# Load and parse a SysML model
model = opensysml.load("vehicle.sysml")

# Evaluate expressions
result = model.eval("2 + 2")
print(result)  # 4

# Instantiate parts
instance = opensysml.instantiate("Vehicle", model_hash=model.hash)
print(instance.slots["mass"])

Features:

• Jupyter notebook integration with rich HTML displays
• pandas DataFrame integration for model analysis
• automatic service lifecycle management
• full runtime API access (evaluation, instantiation, action and state execution)

See the Python client guide for installation and usage, the Python API reference, and client development instructions.

Node/TypeScript

@openmbee/opensysml provides the same access over the Connect protocol, for Node and the browser. It includes no native addon: installation is a standard registry fetch, and the service binary is supplied by a per-platform optional dependency.

import { loads } from "@openmbee/opensysml";

await using model = await loads("part def Wheel { attribute radius : ScalarValues::Real = 0.3; }");
const radius = await model.eval("0.3 * 2");

Version 1 covers loading, evaluation, symbol lookup and instantiation, and negotiates against the capabilities the service advertises. It is published on npm with per-platform packages that carry the service binary. See the Node API and client/node/README.md for the two lifecycle modes (a private child of the calling process, or an externally hosted service), the capabilities and limitations of the browser entry point, and the functionality version 1 omits.

Go, Java and Rust

client, err := opensysml.New()   // in process; opensysml.Dial(addr) for a running service
defer client.Close()
model, err := client.ParseFile(ctx, "vehicle.sysml")
mass, err := client.Evaluate(ctx, model, "mass", opensysml.WithSubject("Demo::sedan"))

The Go API is documented type by type in Go packages and client/opensysml/README.md. The Java client is a try-with-resources Connection over the JDK's HTTP client (Java API, client/java/README.md); the Rust client is published to crates.io at the core's version (cargo add opensysml) and is blocking, with no async runtime in its default dependency tree (Rust API, client/rust/README.md). The Java artifact is on Maven Central at the core's version (org.openmbee:opensysml).

Documentation

• The guide — install, first model, CLI, REPL, checks, behavior, saving, editors, and driving it from your own program
• Client libraries — the Go, Python, Node, Java, Rust, Julia and MATLAB surfaces, and how to choose between them
• Reference — CLI flags, REPL commands, environment, each client's API, service transports, RDF mapping
• Internals — the pipeline, the tiers, testing and performance
• Project status — spec compliance, roadmap and releasing
• Examples — runtime demonstrations and behavioral model examples
• Agent skills — skills an LLM coding agent can load to write, check and run models with OpenSysML

A complete index is available in docs/README.md.

License

Apache 2.0

Acknowledgements

The constraint-solving capability set — satisfiability checking, conflict explanation through unsat cores, value synthesis and objective optimization through an SMT solver — follows the design of the ConstraintSolverService in OpenMBEE's HMF (Hivecore Model Framework) (Apache 2.0). The implementation in internal/exec/solve is independent: it translates conditions to SMT-LIB 2 for an external z3/cvc5 process rather than binding to Z3 in-process.

Contributing

The project is under active development. See CONTRIBUTING.md for build, test and contribution guidelines.

Contact

[Contact information to be added]