RAPTOR Studio Reference Manual

Project Settings is the Inspector page (Model ▸ Project Settings, or the Project Settings entry in Model Explorer). It is not a modal: the page stays open beside the canvas. Run settings are edited in the Run panel; the Inspector shows read-only echoes for those fields. Model-wide fields (units, flow generated, costs, flags) are edited here.

Open from View → Panels → Data Tables. It edits the model as spreadsheets, one tab per element type or per section of the .rbds file. Only some cells are editable; invalid values revert on entry. Blocks, Nodes and Events show the hierarchy level currently on the canvas; the header says “current level: 8 of 17 blocks…” when the model has nested levels. Use Model Explorer to reach the others.

Data ▸ Block Defaults sets what a block you add to the diagram starts with: its failure and repair distributions (all three parameters, labelled for the law you pick, with the resulting Mean and Std Dev shown) and its sparing type. Reset Defaults returns to the factory values (Exponential failure, Lognormal repair, infinite spares).

Block template starts from a block of a library: after Data ▸ Import Library the list holds Default plus every block in that library, and choosing one fills the distributions from it. Until a library has been imported the list is greyed, with the reason in its tooltip. The defaults are yours, not the model’s: they are remembered between sessions and never change a block already in a model.

Select two or more elements, then Data ▸ Mass Edit. There is one tab per kind of element in the selection, and only the tabs for what you selected apply. Each tab has a Rename row with three modes:

Leave the text blank to keep all names. The whole edit is one undo step.

RAPTOR Studio applies Raptor 7’s own input checks, with Raptor 7’s own messages, wherever you edit: the Inspector, Data Tables, the dialogs, the canvas, the raptor command line and the MCP server.

Warnings in the app name the affected element — and, for a link, its From and To endpoints — and say which setting to change. Source-code references are kept in developer/API output, not shown in the UI.

A file written by another tool is still opened, as Raptor 7 opens it. The Issues list (the Issues button on the Model tab, or the badge at the right of the status bar) shows anything in it that Raptor 7 would refuse to draw or type as a warning, and a problem a model already has never blocks an unrelated edit. Choosing a growth/decay type fills in the values Raptor 7 puts back when it refuses the current ones (a base of 1, a limit either side of the mean), so the type can be changed before the rate.

The distribution lists offer what Raptor 7 offers for each choice, with one addition: a failure law can also be Fixed (a block that fails at the same time on every run). Raptor 7’s failure list leaves Fixed out, but it runs a model that uses it. Only a block’s failure and repair laws can be Empirical (their data points are kept in the file); the repair list also has None. A value a file already holds outside a list is kept and shown, marked as not offered by Raptor 7 there.

After a run (or a stepped Finish) the Results dock offers:

Every setting that describes a run is edited in the Run dock, tabbed alongside Results and Data Tables at the bottom of the window, raised automatically on the Simulate tab (and openable any time from View ▸ Panels ▸ Run Panel, or the Simulate tab’s Run Settings… button).

The Run panel is the single editor for trials, stop condition, statistics start, analyses, recording and cores. The Simulate ribbon’s Trials and Cores boxes, the Inspector’s Project Settings page and Preferences are read-only echoes. Green/Yellow and Yellow/Red thresholds are edited in Results ▸ Bands, not in Project Settings.

If the model has a display unit (say years on an hours-native model), the run length and statistics start are shown in that unit and stored in the model’s own. Under Stop at: system failures or phase cycles the run-length figure is a plain count and is never converted — the row label changes to say which kind of number it is.

A readiness line at the top says whether the model can run, and why not when it cannot, rather than presenting a greyed button with no explanation. The panel locks while a run is in progress: the values it holds are the ones the run is actually using, and a 20-minute batch must not have its settings changed underneath it.

A stepped session spans the run count the model is configured for. Jump lets the current run finish and stops at the next run’s first change; Finish completes every run that is left and shows the results of all of them.

Run (F5) runs at full speed in the background, splitting the trials across the processor cores in the Cores box beside it on the Simulate tab, and in the Run panel beside Trials (one setting, shown in both). The box reads, say, "8 of 8": the cores a run will use, out of the cores this computer has. The same count is shown in the status bar, in the Run panel’s readiness line and in the Sweep and Compare windows before they start. The Run panel’s Cores field is the editor; Automatic uses every core.

Animate is the other way to run: one core, with each event drawn on the diagram as it happens. The Cores box, in both places, greys out while it is on, and while any run is going, and says why when you point at it.

The core count is a setting of this computer, not of the model. It is not saved in the .rbd or .rbds file, so a model opened on another computer runs on that computer’s own cores, and a count set higher than a computer has is capped at what it has.

Will I get the same numbers as a colleague?

The two rows are statistically the same answer but not identical to the last digit, because the multi-core run draws its dice from different parts of the random streams. The difference is usually within about ±2×SEM (the standard error the results report); with few trials it can be large, as any small sample’s is. To repeat a result exactly, run it the same way: on one core (Animate, or Cores 1) to match Raptor 7, or on any number of cores from 2 up to match another multi-core run. A computer with a single core always runs the one-core way.

Stop and Pause work on a multi-core run between slices: Stop keeps the trials already finished, Pause starts no new slice until you resume. Jump (skip one trial) is unavailable on a multi-core run, because trials are run in slices; its tooltip says so.

Sweep and Compare (Simulate ▸ Batch) always run at full speed on the chosen cores, on a copy of the model: the open model is not changed.

File ▸ Differences… says what is different between the open model — as it is now, unsaved edits included — and another model:

It compares the models themselves, not their results (for results, run them side by side with Simulate ▸ Compare, whose What’s different? button opens this window for the selected model). Nothing is run.

Rows are grouped by element: a field that changed shows its value in the other model and in this one; an element only in this model reads new here, one only in the other only in that model; renames are listed as such, and their links still match. Connections, rates, system settings, spare pools, resources, triggers and phases are compared the same way. Double-click an element to find it on the canvas, on whatever hierarchy level it is.

Elements are matched by name (and by ID when names do not settle it; against the saved file, by ID, so a rename is a rename). Positions, and the values a model computes from its links and distributions, are left out unless Also show layout and computed values is ticked. Export… writes the list as CSV or Markdown.

The same comparison is raptor diff A B on the command line and the diff_models tool for AI assistants.

In Simulate ▸ Compare, the Add models button is a menu: choose a file, or a model open in another window, which is run as it is now, unsaved edits included.

A second model opens in a second window. Open, New and the examples do this whenever the window you are in holds a model worth keeping, meaning one with a file or one you have edited. A window with nothing in it, or with a new model you have not touched, is reused instead. If the file you choose is already open, that window is brought forward rather than opening it twice.

Each window is a whole RAPTOR Studio window with its own model, undo history and results. To keep the older behaviour, where opening a model replaces the one in the window, set Preferences ▸ Working ▸ Open another model in to this window.

The windows know about one another in two places: Compare’s Add models menu and Differences' An open or recent model list both offer the models open in other windows (see Comparing two models). Crash recovery keeps one copy per window; the first window you open after a crash offers all of them.

RAPTOR Studio includes a Model Context Protocol (MCP) server, so an AI assistant can build, validate, simulate and explain models with the same engine as the app and the raptor command line. The assistant works on its own copies in a workspace folder; it never changes a model open in this window.

The server is an optional extra:

File ▸ AI Assistant (a top level entry in the File view, repeated on the Help tab) opens this page. Step-by-step setup for Claude Code, Claude Desktop, OpenCode and any other MCP client, with worked examples, is in the User Guide: RAPTOR from an AI Assistant. The generated reference for every tool, option and transport is the MCP server reference.

Over stdio the client starts the server itself:

To keep one server running for several clients, use Streamable HTTP:

The token (at least 16 characters) is required; the User Guide’s MCP chapter shows how to make one.

The installer build of RAPTOR Studio does not include the MCP server; use the Python package above.

Recording is chosen in the Run panel’s Recording section (above) and is stored with the model, so two models open side by side each keep their own choices. Plot and log collection is opt-in: unticked items are never collected, so long simulations cost no extra memory, and ticked items are streamed to a temp file as the run progresses, never held in RAM.

The four kinds are:

Use the Graphs tab’s Export Data… button to save a plot’s rows to a file. If a FailSim/CycleSim run reaches the t = 10,000,000 safety bound without meeting its termination condition, a warning is shown in the status bar and the Summary notes — the numbers then cover only the simulated portion.

The Results ▸ Overview tab opens with one line describing the run these numbers came from: trials, stop condition, analyses, what was recorded, the model’s content hash and a short run id. The full manifest is in the line’s tooltip.

That is deliberate. Simulation is an experiment, not an animation, and a number you cannot trace to the settings that produced it is an animation with figures attached. The model hash covers the engineering content only — distributions, topology, dependencies, phases — so changing the trial count for a convergence sweep does not retroactively invalidate results already on screen, while changing a failure distribution does.

The Debug tab’s Step group carries the verbs you press in a loop: Step (F6), Next Time (Shift+F6), Finish, Terminate and Restart, plus a More Steps menu for the less common ways to advance. The parameters those need — multi-step count, run-to time, breakpoint block — are in the Run panel’s Stepping section, where there is room to label and explain them.

Press Step to start an interactive single run: the first press performs the kickoff at t = 0, every later press advances one event, the diagram re-colours live, and the status bar narrates. Next Time advances every event at the current sim time in one click. More Steps holds Step to next change, Multi (advance N events) and Run to time. The breakpoint stops stepping when the chosen block enters Repairing. Restart discards the stepped run and begins a fresh one; Terminate finalizes at the current sim time and keeps partial results; Finish completes the run and produces full reports.

While Animate is on, the status bar carries a live system-status square (green = fully working, yellow = degraded, red = fully down) and cumulative readouts — Ao, MTBDE, MDT, tracked average R (mission success), and the green/yellow/red time split. Turning Animate off runs at full speed on several cores (see Cores, Animate and repeatable results); the speed dial then greys out, because an animation speed only means something when something is being animated.

Animate is a display setting, not part of the model. Toggling it never marks your file unsaved, adds nothing to the undo stack, and works while a stepped run is paused. It is remembered between sessions (Preferences ▸ Working ▸ Animate by default), exactly like the zoom level and the pan position are.

Failure Effects opens Failure Effects View: the model is shown all-operating (phase 1, for a phased model), with nothing simulated and no dice thrown. Click a block to fail it, click it again to put it back; an element a dependency has forced to fail, idle or into maintenance is drawn hatched, and clicking a hatched block cycles through the other outcomes its dependency allows. Fail and Repair do the same for the selected block or event (or arm the next click). On a phased model Prev Phase and Next Phase move through the phases (applying each phase’s Cut, Linked and stress changes), Clear Failures repairs everything but stays in the phase, and Reset All returns to phase 1 with everything operating. Status opens the system-status summary (failed components, induced failures, down and degraded nodes, system colour) and Log appends the same text to a file, byte for byte what a Failure Effects log contains. They sit on the Debug tab beside the stepping verbs. Failure Effects View and a run are separate modes: Run and Step are unavailable while it is open, and editing the model closes it. raptor fev does the same from the command line. The Weak Link, Capacity and Cost switches are run settings, so they live on the Simulate tab next to Run. A walkthrough is in the User Guide’s debugger chapter.

Select one hierarchy oval and press Extract Hierarchy… on the Simulate tab. The hierarchy becomes a standalone model: its input node is the start and its output node the end, so its input is always available. The dialog lists what crosses the hierarchy’s boundary and how each kind is treated: elements that follow something outside (assumed always up, or following the extract’s own end), spare and resource pools shared with outside blocks (the whole pool, or scaled by the share of users inside), and random streams shared with outside elements (kept, or each given its own). Save the extract as an .rbd or .rbds; it can be opened in this window and run like any model, and raptor run --hierarchy NAME and raptor extract do the same from the command line, and the MCP simulate tool takes a hierarchy argument.

Its results are labelled as an isolated run. No treatment can make an isolated run reproduce the draws the hierarchy would have had inside the whole model, so compare averages, not individual runs.

File ▸ Print and Export ▸ Export Tables… (also a button on the Data Tables and Results docks) writes the model’s tables, and a run’s result tables, to files.

Pick the tables in two groups:

Then pick the formats — any combination:

Files go to a folder called Tables beside the model file (change it with Browse…), named <model>_<table>.<ext>, or <model>_tables.xlsx / <model>_tables.txt for the workbook and combined report. Files of the same names are replaced — the dialog counts them before you export. The tables reflect the model as it is on screen, including edits you have not saved. Your format choices are remembered.

An AI assistant using the MCP server can read and write the same tables with list_tables, get_table and export_tables; see the MCP chapter of the User Guide.

View ▸ Appearance ▸ Preferences… is one scrolling page of sections: New models, Working, This model, Advanced and Developer. The list on the left jumps to a section; the Filter box above it hides every setting (and section) that does not match what you type, across all sections at once, so you never have to hunt through them. Settings in This model are stored with the model file; the rest belong to you and are remembered between sessions.

Working also holds Open another model in: a new window (the default) or this window (see Several models at once).

The Display unit setting accepts either one of the built-in choices or a unit name of your own (say cycles); durations are then shown in that unit and stored in the model’s own.

Preferences, Help and the other dialogs do not lock the application: the Help window stays usable, and can be closed, while a dialog is open.

RAPTOR Studio is an RBD simulator, not an analytical IEC 61078 solver. The standard defines series, parallel and m-out-of-n logic and the Boolean/BDD/closed-form methods for evaluating it. This application simulates the same structures, which lets it include repair, spares, phases, dependencies and limited resources.

There is no standards-specific menu or results page. The one Annex D feature is Run ▸ Analysis ▸ Importance measures, which estimates Birnbaum, RAW, RRW and Vesely-Fussell importance by re-simulation and shows them in Results ▸ Final Results ▸ Importance. It costs one extra batch per block (two with Birnbaum), so it is off unless selected. The definitions and equations are on the Formulas page (Help ▸ Formulas) and are deliberately not repeated in the tab. The User Guide appendix carries the in-app clause comparison, and docs/IEC61078.md in the repository records the full table. Neither is an application control.

What is supported:

What is not implemented: minimal cut/tie sets, Boolean/BDD evaluation, analytical (non-simulated) importance factors, criticality and DIM importance, PFD_avg, Vesely/unconditional failure intensities, repeated/common blocks, multi-port transfer gates, non-coherent blocks, PAND/SEQ and CCF beta factors.

The numerical regression checks against the standard’s worked examples run as part of the project’s test suite.

RAPTOR Studio’s engine is a port of the simulation in Raptor 7, built from its source and checked against the real program. This section says how far that goes and where it stops.

What is checked. More than 200 models were run in Raptor 7 itself and the results compared with this engine’s: the End of Run and Final Results reports, the detailed event log line by line, the random numbers drawn (where Raptor 7’s draw log was captured), the Single Point Failure file, the Failure Effects View log, the points at which Step and Jump stop, the input checks Raptor 7 refuses to run, and the start-up trace and developer hover text of its /d and /dev switches. Every comparison made matches, apart from two models whose draw logs could not be compared. The models were chosen to exercise every feature: standby and cold standby, spares and repair resources, preventive maintenance, dependencies, phases, events and hierarchies.

What is not proven. When several things become ready at the same simulated instant, the original’s runtime decides which goes first, and its rules are not published. This engine uses rules worked out from the source and from captures, and they reproduce every captured model exactly. They are fitted rules: they have not been shown to be the original’s rules, so a model with a tie shape no captured model has could in principle order such events differently. This can only change the order of lines in the event log that carry the same time, or, in a rare tie, which of two blocks fails or is repaired first. It does not change the maths: availability, MTBF and the other results stay statistically the same, and any one run’s results move only if the order of those events changes.

Where this port differs on purpose.

One core or several. Only a one-core run (Animate, or Cores set to 1) reproduces Raptor 7’s numbers exactly; a run on several cores gives the same answer statistically but not to the last digit (see Cores, Animate and repeatable results). Compare with Raptor 7 on one core.

If a result looks wrong. Compare the model with Raptor 7 if you have it, and keep the Run Info (the seed, the software version and the model’s digest are recorded with each result set) so the run can be repeated. The project’s repository documents every rule it reproduces from Raptor 7, and its status, for anyone who wants the detail.

Every ribbon tab, group and control with its tooltip and shortcut.

Each ribbon tab, group by group: the control’s name, what its tooltip says, and its shortcut (or, for a field, its kind and current value).

RAPTOR Studio: reliability block diagram modelling and Monte Carlo simulation. The ribbon reference above is produced from the application itself, so it always matches the controls you see.