The product

One pass over one model

MBE3Dstudio has a deliberately small shape. There is one model, one analysis entry point, and one output currency. Everything on this page follows from that: the viewport, the report, the bill of materials and the trace matrix are all views of a single computation, so none of them can quietly disagree with another.

Model to findings

The model graph is the hub. Importers write into it, the analysis pass reads it, and every view is a projection of it, so no two of them can disagree.

requirements → graphSysML v2, ReqIF, XMI and spec documents, imported into the graph rather than referenced from it
geometry → graphSTEP AP242 assemblies and materials, as envelopes and ports
networks → graphARXML, DBC and signal catalogues
one analysis passmass, power by mode, voltage drop, clearance, thermal, occlusion, trace
a findingmeasured value, limit, unit, and the requirement tag it traces to
graph → viewsthe viewport, the report and the BOM are projections, never separate copies

The rule

A finding carries a number

Every check in the tool reports in the same shape: a severity, a category, what was measured, what it was measured against, the unit both are in, the entities it points at, and, where one exists, the requirement tag it traces to. That constraint on the output format is what stops the tool producing anything an engineer cannot act on.

“Mass budget exceeded” is not a finding. “Sensor pod shell and everything in it masses 16.25 kg against a 14 kg budget, traces to SYS‑001” is a finding: it can be triaged, argued with, and closed. In r6 of the worked example it was closed, by pocketing the baseplate and thinning the shell, not by moving the budget.

Findings sort by severity, then category, then title, so the list is stable between runs and diffs cleanly. Clicking one selects the parts it names in the 3D view.

The analysis pass

What each check actually measures

All of it runs on every edit, locally, in single-digit milliseconds for a model of this size.

Mass properties

kg · m · kg·m²

Placement composes down the assembly tree, so a part's world position is its own placement applied through every parent above it. Mass sums over the tree; the centre of gravity is the mass-weighted mean of each part's centre of mass in world coordinates; the inertia tensor is accumulated about that CoG with the parallel-axis term included. A part with no stated centre of mass defaults to its envelope centroid, and density is derived from mass over envelope volume, which is what makes an implausible material visible as a number rather than an opinion.

Power, by operating mode

W, per declared mode

Each part states a default draw and, optionally, a draw for named modes: standby, nominal, autonomy. The budget is rolled up once per mode and adds the power actually dissipated in the harness, so the total is what the source has to supply rather than what the loads happen to consume. A mode a part does not mention falls back to its default, which keeps sparse models honest instead of silently zero.

In the worked example, autonomy mode draws 319.6 W (316 W in components and 3.62 W lost in copper) against a 320 W budget. It passes by 0.4 W, so the harness is the term that decides it.

Clearance and interference

m (negative = overlap)

Every pair of non-phantom parts is screened for the gap between their envelopes in world space. A negative gap between two unrelated parts is an interference and is raised as an error whether or not anyone wrote a clearance constraint, because two parts cannot occupy the same volume regardless of what the requirements say. A part overlapping its own parent is measured and labelled as nesting rather than raised, since a card sitting inside its chassis is where it belongs, but the gap is still reported, so a card overhanging that chassis is still visible. Parts explicitly marked phantom (datums, keep-out volumes, reference bodies) are excluded entirely, so a keep-out can overlap the thing it constrains without generating noise.

Harness length and voltage drop

m · V · % · W · kg

A run is routed through explicit waypoints, so its length is the polyline through its two endpoints and everything in between, plus a stated slack for service loops and strain relief. That makes the length a measurement rather than an optimistic straight line. Gauge and conductor count give resistance; resistance and current give the drop, the percentage of nominal, the copper mass and the watts turned into heat, which feed straight back into the power budget and the thermal screen.

Routed the long way round the pod, as the 12 V compute feed was until r5, that one run costs 3.29 m of AWG 14 and a 9.99 % drop against a 5 % interface limit, and 26.39 W of the 26.77 W total harness loss. Routed direct it drops 1.23 %.

Thermal screening

W · W/m³ · m

Each part declares what fraction of its draw becomes heat, so dissipation is computed per mode alongside power rather than guessed from it. Two screens run: volumetric heat density over a scope, and adjacency: pairs of dissipating parts whose envelopes sit closer than a threshold. Adjacency is reported at the peak-power mode, because that is the case that decides whether the pair is a problem.

Sensor coverage and occlusion

% of declared field of view

A sensor declares a modality, a horizontal and vertical field of view, a useful range and a boresight. Rays are cast across that field and tested against every other body in the scene, including the host vehicle carried as reference geometry. The result is the unoccluded fraction and, named explicitly, the part responsible for the largest share of the blocking, which turns “the camera looks wrong” into a part number and a percentage.

The lidar in the worked example sees 91.11 % of its declared field against a 97 % minimum. The blocker is named: the cellular / V2X antenna mast, at 8.89 %.

Traceability, derived

% coverage, four ways

The matrix walks requirement → function → component → verification and is recomputed from the graph every time it is shown. There is no stored trace document, so there is nothing that can drift from the model. Four coverage fractions come out of it: satisfied by a function, allocated to a component, covered by a verification activity, and verifications actually passing. Draft and obsolete requirements are excluded from the denominators, so coverage cannot be inflated by parking work in draft.

It also reports the things that fall out of the edges: functions allocated to no component, components performing no function, and requirements referenced by nothing.

Model integrity

structural

Before any physics is attempted, the model is checked for the kinds of damage that make physics meaningless: cycles in the assembly tree, parents that do not exist, connections whose endpoints do not resolve, duplicate requirement tags, and masses that are negative or zero. Fifteen structural checks run in all, including ports wired to the wrong kind or direction, conductors with no gauge, sensors with no field of view, links that exceed the data rate they carry, and requirements or verifications pointing at things that are not there. These surface as findings like everything else, so a broken import is legible rather than mysterious.

Executable constraints

Eight kinds, evaluated not read

A constraint is typed data with a limit, a scope and a unit, not a sentence someone has to remember to check. Each kind is evaluated by a named function that returns the measured value alongside the limit, which is why a violation can say by how much. Tie a constraint to a requirement and every finding it raises inherits that requirement's tag.

Kind	What it bounds	Scope
massBudget	Rolled-up mass, in kilograms	A subtree, or the whole model
powerBudget	Total draw in one named mode, in watts	Per mode
clearance	Minimum gap between any two envelopes, in metres	Whole model
cgEnvelope	Centre of gravity inside an allowed box, in metres	Whole model
harnessLength	Routed length of a run, in metres	One run, or the longest
voltageDrop	Drop as a fraction of nominal	One run, or the worst
sensorCoverage	Unoccluded fraction of a declared field of view	One sensor
thermalDensity	Volumetric heat rejection, in watts per cubic metre	A subtree, or the whole model

What comes out

Four exports, one source

Export	Format	Contents
Project	.mbe.json	The complete model. Nothing an engineer decides lives anywhere else, so the file is the whole of the work.
Review	Markdown	Verdict, constraint table, mass properties, power by mode, harness table, sensor coverage, trace matrix and findings, generated from the same analysis object the screen is showing.
Bill of materials	CSV	Part numbers, suppliers, quantities, unit and extended cost, rolled up from the assembly tree.
Viewport	PNG	Exactly what is on screen, for the review pack.

Open the studio Read the model schema