MBEstudio
Evaluate the design in the model
One SysML v2 source connects the assembly, 3D geometry, interfaces, requirement margins, state behavior and design trades.
Architecture
How we construct the digital twin
A digital twin is only worth trusting when its electrical, software and mechanical parts are one model, not three models kept in step by hand. MBEstudio builds the twin around a single hub: a typed, directed model graph. Its nodes are model elements (parts, ports, requirements, states) and the artifacts linked to them; its edges are typed relations such as owns, typed by, specializes, connects, satisfies, verifies and derived from. Every tool is a spoke. A spoke either writes into the graph or reads what is derived from it, and no spoke ever calls another.
SysML v2 cannot hold every kind of engineering data, and it is not asked to. The SysML v2 text is the authoritative serialization of the system model portion of the graph: MBEstudio's compiler builds that portion from the text today, with its owned by, typed by, specializes, subsets and redefines relations shown on the Ontology page. CAD solids, PCB layouts, meshes, simulation time series, FMUs, source code and test logs stay in their own tools' formats and attach to the graph as linked artifact nodes that record the source tool, the file and its version or hash. Artifact nodes are planned, not built yet.
- prompt → graphthe agent generates a model, validates it through the compiler and repairs what fails
- imports → graphKiCad netlists, Onshape BOM CSV, ReqIF, MATLAB and CSV tables, mapped onto existing parts
- editors → grapha change in 3D, a diagram or a table becomes an edit to the SysML text, and the graph follows
- graph → 3D and verdictsgeometry, placement, requirement margins, budgets and safety findings
- graph → behaviour and tradesstate machines run over time; trade studies swept to a Pareto front
- MCP, both waysoutside agents validate, evaluate, edit and simulate through the same compiler
- artifacts → graph (planned)CAD solids, PCB layouts, FMUs, code and test logs linked in their own formats, with source tool, file and version or hash
One model, three disciplines
Electrical and electronic
ports · buses · power railsElectronics are parts with typed ports, joined by interfaces. Each part states what it draws from or supplies to a bus or rail: positive consumes, negative supplies. The compiler sums every bus and reports its margin, and a bus with demand but no declared supply stays indeterminate instead of passing. A KiCad netlist brings component values, footprints and pin to net membership onto the parts it describes.
Software
states · latency · integrityBehaviour is written as state machines with timed transitions, guards and assignments, and the simulator runs them so each requirement is checked across the states where it applies. Latency and data rate are budgets on the same buses the hardware rides. Integrity levels and isolation groups flag any connection that crosses a partition without a barrier.
Mechanical
envelopes · bodies · placementEvery part has at least an envelope, and can state its real shape as lofts, extrusions and revolves whose dimensions are expressions over its attributes, so a trade that moves an attribute moves the geometry. Placement follows the interface graph, and mass and packaging are evaluated against those shapes. An Onshape BOM maps onto part attributes, and STEP export writes the envelopes out.
What the architecture will not let you do
- Tool A never talks to tool BBoth talk to the graph. A second copy of the design would be a second place for it to disagree with itself, so an import, an agent and a drag in the 3D view all end as the same thing: an edit to the SysML text that the compiler accepts or refuses.
- One compiler, everywhereThe studio, the MCP server and the command line run the same Rust compiler, built to WebAssembly, so the verdict in the browser is the verdict an agent or a CI job gets.
- Every value carries its sourceAn evaluated value says whether it was stated, computed from an expression or estimated and flagged for review. A missing input stays indeterminate; it never defaults to a pass.
Import source files stay in the browser; only the mapped values enter the model. Imports that add a part with its provenance written into the part (for example, imported from a KiCad netlist) and place it in the decomposition, with the owner suggested from the ontology, are in progress. FMU co-simulation and rigid body physics are planned spokes on the same hub and are not built yet. Connect an agent over MCP.
Mass and budgets
Declared quantities and equations feed the engineering views. Inspect the BOM and budget inputs instead of treating a target as a measured result. The hatchback separates itemised concept masses from its allowance for remaining hardware, fluids and trim.
Requirements across states
State entry assignments change values during a discrete run. Timed transitions and guards determine the sequence. Requirement assumptions identify when each check applies, and the run records its worst margin and failure intervals.
Geometry and packaging
Authored solids retain detailed body shapes while envelopes support layout and packaging checks. An overlapping envelope is a finding to investigate; it does not prove that material intersects inside a hollow or cut part.
Ports and connections
Typed part ports connect through interface usages. Inspect the same connections in 3D, Interfaces and internal block diagrams. Model-level connectivity provides an integration view; detailed cable routing and manufacturing evidence require additional work.
Inputs must support the claim
A temperature threshold and timed protection response can be modeled without pretending to solve the vehicle thermal system. The hatchback injects a stated coolant-temperature excursion to evaluate its control sequence. It does not calculate coolant temperature from combustion heat or airflow.
Sensor fields of view
Sensor placement, orientation, horizontal and vertical angles, and range define the displayed sensing volumes. The ICE hatchback includes cameras, radars and an ADAS controller. Geometric coverage does not establish detection probability, weather performance or fault coverage.
A link needs a result
A satisfy relationship connects a requirement to its subject. Executable expressions then evaluate that subject against the requirement. Missing inputs stay indeterminate. A computed pass belongs to the declared configuration and assumptions, not to every possible physical design.
Trades and review
A declared trade study sweeps alternatives and design variables against objectives and constraints. The aircraft example demonstrates this workflow. Compare candidate results, inspect the selected design and export the source and report for review.