Break It Before It Breaks

This book teaches you how to predict when things break — before they do. You will build small models of real machines, run them through thousands of possible futures, and read the results like an engineer.

You will use RAPTOR Studio, a free, open program for building reliability block diagrams and simulating them.

The book has twenty-three short chapters, from this welcome to the last capstone. Each chapter adds exactly one new idea. Each chapter has a small, complete example you build or open yourself. The examples are everyday objects: a camping lantern, an espresso machine, a delivery drone, a toaster, a soda vending machine — building up to a data centre engineered to a reliability target.

Start RAPTOR Studio. It opens on the start page: a blank model and some of this guide’s example models to begin from, the files you used recently, and this guide one click away.

Pick Blank model, an example, or a recent file — or press Esc for an empty workbench. The workbench is a ribbon with tabs, a canvas in the middle, and dockable panels around it:

The blue File button, left of the tabs, brings the start page back: New (a blank model, or any example as a new, unsaved copy), a searchable list of your recent files, Open, Save, Save As and Close, and a Print and Export page (Print, Export PDF, Export Tables, Export Diagram SVG, Save Bitmap, Copy View). Press Esc to go back to the model.

The New page offers a blank model and every example: the Basics, one idea each from this guide, and the Advanced ones — a hospital’s emergency power, a water-treatment works, a data centre and a phased flight — larger systems that use several features at once, with a Rates library behind their numbers.

The ribbon tabs:

Reliability simulation answers one question:

To answer it, the simulator needs three things:

That is all. The next chapter starts with one part and one rule.

The Model ribbon has an Annotate group with Text, Rectangle, Ellipse and Arrow tools; their stacking order is on the Arrange ribbon. Click the canvas to place; drag to move; use the corner handle to resize shapes. Right-click an annotation for Colours & Font (border, fill, text colour and font family/size/ bold/italic). Delete with the Del key as usual.

Annotations are saved in the native .rbds format. The older .rbd format cannot store them — RAPTOR Studio warns before dropping them if you save as .rbd.

You are going camping for the weekend. Your trip lasts 48 hours. Your lantern has three parts:

If any part dies, the lantern is dark. You want to know: what is the chance my lantern is still burning at hour 48?

When parts are connected so that every part must work, engineers call it a series connection. Think of old Christmas lights: one dead bulb killed the whole string.

Rules to remember:

You see three blocks in a row between Start and End. That is the whole model.

The rest of this chapter uses the ready-made file, but it is only three blocks, and building one is worth doing once before the models get bigger. There are two ways; both end with the same diagram.

Open the Data Tables panel (View ribbon tab, Panels group). The Blocks tab shows each block’s failure rule:

What does this say?

Press F5, or pick Simulate → Run. Watch the Results panel.

In the Results panel, open the Final Results tab and find the summary table. Look at the Reliability row, Mean column.

With these exact files and 10 trials you should see something like:

The simulator played your camping trip 10 times. Each play is one trial. In each trial:

Reliability = (number of trials alive at hour 48) ÷ 10.

Our long-run answer (thousands of trials) is close to 0.38. So on roughly 4 trips out of 10, this lantern dies before the weekend ends. Time for a better battery pack!

Change the battery pack’s Param 1 from 1.5 to 1.1 in the Data Tables (keep Param 2 = 60). Run again with more trials: set the run count (Trials in the Run panel) to 100 first.

Hint: a smaller shape parameter means failures spread out more, with many early deaths. Does reliability go up or down?

Next chapter: how to make a machine that keeps working even when a part dies.

You run an espresso cart. Your machine has one boiler and one water pump. When the pump dies mid-morning, you sell nothing until it is fixed. Painful.

So you buy a second pump. Now the machine works while at least one pump still lives. Engineers call this redundancy: extra copies of a part so one failure does not kill the system.

Question for the simulator: how much does the second pump really buy me? Mission: survive a 500-hour season without any downtime.

A series chain cannot express "either pump is fine". We need a junction. In RAPTOR Studio a junction is called a node.

Our model:

Open models/Espresso1.rbds. Compare the canvas with the diagram above.

Select the green Either_pump node and look at the Inspector: the node type is Regular, with k = 1 (need) out of n = 2 (inputs).

The block data:

Mission settings: stop at 500 hours, 10 trials.

Set the run count to 10 on the Simulate tab and press F5.

Look at Reliability (Mean) in Final Results. With many trials the long-run answer settles near 0.37.

Now do the comparison that makes the lesson stick. Delete Pump_B (select it, press Del), connect Pump_A straight to Either_pump’s position so the model is a plain series chain again, and run again. One-pump reliability lands near 0.21.

Almost double — from one €40 part.

The Results panel’s Event Log tab shows one trial as a list of moments. Find a trial where both pumps died. You will see lines like:

Read it like a story: Pump_A dies at hour 241. The node notices it lost one of its two inputs, but keeps flowing — Degraded, not dead. The system shrugs and carries on. Later, if Pump_B also dies, the node goes Bad, and End goes down with it.

This ripple — part fails, node re-checks, system re-checks — is how every event in every model travels.

Make the pumps unequal: set Pump_B’s failure Param 1 from 400 to 150 (a cheap, weak pump). Predict first: does 500-hour reliability go up or down, and by roughly how much? Then run 100 trials and check.

Next chapter: what happens to that math when the "backup" secretly answers to the primary.

Remember the espresso cart from Chapter 3, Redundancy: Two Pumps Are Better Than One? Two pumps, either one keeps the pressure up, reliability climbed from about 0.21 to about 0.37. The cart has been running for a season now, and the mechanic who serviced it made one small change to save a part: instead of wiring Pump_B’s activation relay to its own switch, she spliced it into Pump_A’s control board. Cheaper. Fewer wires. The diagram in the shop manual still shows two independent pumps.

Is it still two independent pumps?

Every block you have built so far answers to nothing but its own dice. Real parts are not always so private. A dependent block watches another element and reacts to it: when the thing it depends on goes down, the dependent block is pulled into an Idle state — not failed, not running, just paused. Its own failure clock stops counting. The moment the depended-upon element comes back, the dependent block picks up exactly where it left off.

Open models/EspressoDep1.rbds. On the canvas it is pixel-for-pixel Espresso1: Pump_A and Pump_B feed Either_pump ("need 1 of 2"), then the Boiler, same as before. Look closely at Pump_B’s box, though — a small blue circle sits in its bottom-left corner. Hover over the block and a dashed line appears, running straight to Pump_A:

That badge and its connector are how a dependency shows on the canvas: without them it would have no visual feedback at all, and you would have to keep a separate hand-drawn dependency diagram just to avoid losing track of it. RAPTOR Studio draws the link for you — but only if you notice the badge. Two boxes, two links into a vote node: at a glance, this diagram still looks exactly like chapter 2’s independent pair, which is precisely how the mechanic’s wiring shortcut goes unnoticed until someone hovers, clicks, or opens the Inspector.

Select Pump_B and check its Deps tab. The Dependency group has Dependent on: selected, with the combo pointing at Pump_A block - 001. Underneath, the Effects (%) group reads:

100% Idle, no other outcome possible: Pump_B is set to go Idle, every time, the instant Pump_A is down. Select Pump_A and its own Dependency group shows Independent — it answers to nothing. Both pumps still use the same dice as before — Exponential, mean 400 hours, no repair.

Press F5 at 10 trials, then raise it to 2000 for the long-run number. Watch one trial’s event log for the moment it happens:

Read the last four lines slowly. Pump_A dies. Pump_B — perfectly healthy, still well inside its own 400-hour mean — is yanked into Idle on the very same line, tagged Dependence. The node briefly shows Degraded (one of two branches still reads as up) and then immediately drops to Idle once it notices Pump_B’s branch went with it. The two-branch vote never actually had two independent branches to vote on.

That second number is not a new figure. It is Chapter 3, Redundancy: Two Pumps Are Better Than One's own single-pump result, to three digits. Wiring Pump_B’s relay off Pump_A did not weaken the redundancy a little. It deleted it. Pump_B can be in perfect health for the entire mission — it never once gets the chance to matter, because the moment it would matter (Pump_A being down) is exactly the moment it is forced to sit out.

Before running anything: if you rewired the other way — Pump_A’s relay spliced onto Pump_B’s control board instead, so Pump_A is now the dependent one — would reliability end up higher, lower, or about the same as this chapter’s ~0.21? Write down your answer. Then edit the file (swap which pump carries the depnum/depType/depIdle fields), run 2000 trials, and check yourself. What does the result tell you about whether it was ever really about which pump was better?

Next chapter: voting with more than two — six motors, four needed.

A delivery drone has six motors. Here is the fun part of aircraft design: it does not need all six. Four healthy motors can hold the frame steady. Five is comfortable. Three is a crash.

So the drone flies while at least 4 of its 6 motors work. This rule is called a k-of-n vote. Your laptop’s battery cells, a data centre’s servers, a rocket’s engines — same trick.

The rest of the drone stays simple:

Mission: fly 48 hours of total service time. What are the odds?

The model has three layers:

Open models/Drone1.rbds and select the Motors_need_4 node. In the Inspector you see k = 4, n = 6. Change those two numbers here when you do the exercise.

The block data:

Mission settings: stop at 48 hours, 10 trials.

Press F5. With many trials, long-run reliability settles near 0.59 — call it a coin flip with good odds. Now look at the Results Overview tab and find the System health bar:

You will often see a yellow slice. Yellow means degraded: the drone lost a motor or two, but still flies. The engine tracks three colours at every instant:

Redundancy does not just raise reliability — it buys you warning time. The yellow hours between "first motor died" and "third motor died" are your landing window.

Each motor survives 48 hours with probability e^−48/120 ≈ 0.67. The chance that at least four of six survive works out to about 0.69. The battery and controller survive with about 0.98 and 0.90. Multiply: 0.69 × 0.98 × 0.90 ≈ 0.61 — right where the simulator lands (0.59).

When a simulation agrees with pencil-and-paper theory, both deserve trust. For big models, only the simulator survives.

Cheap airline: the operator removes Motor_6 to save weight and cost. Set k back to 4 but delete Motor_5 and Motor_6 so only 4 motors feed the node (n = 4). Predict reliability before running. Then run 100 trials. Was losing two motors worth it?

Next chapter: the dice themselves. What Exponential, Weibull, and friends actually mean — and why the average alone lies to you.

Three factories sell heating elements. All three claim: "average life about 1000 hours." You run a toaster warranty service. Your warranty: 600 hours, full refund.

Same promise, three contracts. But averages hide the shape of the risk. One factory builds parts that die like clockwork at exactly 1000 hours. One builds parts where any hour is equally dangerous. One builds parts that usually live long but sometimes fail in the first weeks (a bad batch from a dirty oven — it happens).

Question: which factory costs us the least in refunds?

A failure distribution is the dice the engine rolls for each block’s death time. You already met three of them. Now look under the hood:

How to read the curves above:

Open each file and press F5. All three use 40 trials and stop at 600 hours. Then raise the run count to 500 for smoother numbers.

About one in ten toasters from the Exponential factory dies before 100 hours — 1 − e^(−100/1000) ≈ 9.5% — while its brochure still says "average 1000 hours". The Fixed factory never pays a refund but also never surprises anyone. This gap between average and early-failure risk is called the warranty trap, and whole product lines have died in it.

You will meet more dice later (Normal, Gamma, Lognormal, Triangular, Empirical). Two rules cover most choices:

When you have real repair records, the Empirical distribution uses your data directly as the dice — no guessing about families at all.

There is a name for "how risky is this part right now, given it has survived this long": the hazard function. It is not the same question as "what’s the average life" — a part can have a long average life and still be extremely risky at this exact moment.

Three shapes cover almost every real component, and they stack into the classic bathtub curve:

This is why the toaster factories' shapes matter so much: Exponential sits permanently in the flat middle of the bathtub (constant risk, forever), while Weibull-1.5 starts in the falling-risk zone and slides into the rising one. Burn-in testing exists to walk a part past the falling-early-life knee before it ships to you. Chapter 12, Preventive Maintenance: The Careful Commuter exists to pull a wear-out part off the rising edge before it climbs too high, by resetting its clock on a schedule.

The full 22-distribution table — every mean formula and when to reach for each family — lives in the Formulas quick reference; this chapter only needed the three that make the shape argument.

The warranty office proposes cutting the warranty to 400 hours. For Toaster_Expo, compute the expected refund rate by hand: P(die before t) = 1 − e^(−t/1000). Check your answer against a 500-trial run.

Next chapter: parts that get repaired. Availability, MTBF, and why a machine that always breaks can still be a good machine.

A soda vending machine stands on a school corridor. It has two parts that matter:

The machine serves for a full school year: 8760 hours. It will break many times — that is fine. The question is not "will it fail?" but "how much of the year is it actually selling soda?"

Until now, every block had Repair = None: die once, stay dead. Real machines get repaired. Give a block a repair distribution and the engine sends it to a repair queue when it fails:

Open models/Vendo1.rbds and its Data Tables panel (Chapter 2, Your First Model: The Camping Lantern's spreadsheet-like view of every block, one row each):

The same numbers, read off that grid:

Mission: stop at 8760 hours, 20 trials.

Press F5. The Results Overview tab now shows the repair-era metrics (image from a 20-trial run):

Sanity check: 35 stoppages × 7 hours ≈ 245 down hours ≈ 2.8% of the year. Availability ≈ 97.2%. The numbers agree with each other — a habit worth copying.

Scroll to the Final Results tab. Reliability is 0.00. Correct! The chance of surviving a whole year without a single stoppage is essentially zero.

This is the most common beginner mistake in reliability work:

A machine with reliability 0.00 and availability 0.97 is a good machine. A fire alarm with those numbers is a criminal offense. Pick the measure that matches the mission.

MTBDE and MDT are system-level numbers — this report’s own words for "how the whole vending machine behaves". Reliability conversation also uses three component-level letters, and confusing the two levels is the most common mix-up in the field:

The system’s MTBDE is not the smallest component’s MTBF, and it is not their sum either — it depends on the whole diagram (series parts each contribute a chance to bring the system down; redundant parts mostly don’t). Reach for the exact formulas in the Formulas quick reference rather than guessing from a part’s datasheet number.

Buy a spare keypad so repairs take 2 hours instead of 12: change the Keypad’s Repair Param 1 from 12 to 2. Predict the new availability before running. Run 100 trials. Was the spare shelf worth it?

Next chapter: how many trials make a number you can trust.

In Chapter 2, Your First Model: The Camping Lantern, your ten camping trips gave a reliability somewhere near 0.4 — maybe 0.3, maybe 0.5. A colleague runs the same model and gets a different number. Someone asks the awkward question:

The honest answer: neither, exactly. Each is a measurement of the same underlying truth, made with noisy dice. This chapter turns "trust me" into arithmetic.

The engine’s randomness is not truly random. Every block’s dice come from a seeded generator: the same seed produces the same sequence, always. That gives you two superpowers:

There is a third superpower worth knowing about even before you need it: fair comparisons. If you want to know whether a design change actually helped, run the old and the new model on the same seeds. Sharing seeds is called common random numbers — both models see the same run of "luck", so the difference between their results is the change you made, not noise. Comparing two designs on independent seeds buries a real effect under sampling noise that a shared seed removes for free.

Run Lantern1.rbds with these run counts: 10, then 50, then 200, then 1000 (set Trials in the Run panel each time — the dock at the bottom of the window, next to Results). Note Reliability (Mean) after each run:

The purple line is the running answer as trials accumulate; the red dashed line is the long-run truth (about 0.38). Early estimates are wild because one trip is 10% of the whole sample at ten trials. At a thousand trials, one trip barely moves the needle.

This pattern has a name: convergence. Simulation does not remove uncertainty — it shrinks it in a predictable way.

Open Final Results after any run and find the summary table. The last column of the statistics block is SEM — standard error of the mean. Read it as the size of your remaining doubt:

For a proportion like reliability, SEM ≈ √(p(1−p)/n), where n is the number of trials. Two consequences worth memorizing:

The Mean ± 2×SEM interval is a normal approximation — it assumes the estimate’s own uncertainty looks like a bell curve. That is a fine assumption when the answer is somewhere in the comfortable middle, say 0.3 to 0.7. It quietly breaks down near 0 or 1 — exactly where a "99.98% availability" target lives. Chasing a rare event (a four-nines target is really asking the simulator to pin down a probability near 10⁻⁴) needs dramatically more trials than chasing an ordinary one: halving the target unavailability roughly doubles the trials needed for the same relative precision. The Formulas quick reference has the trial counts by target; the data centre in the book’s capstone runs straight into this problem.

More trials cost time, and a modern computer has several processor cores. Run uses them: with Animate off it runs at full speed in the background, splitting the trials across the cores shown in the Cores box beside it on the Simulate tab ("8 of 8": automatic uses them all). The same count is in the status bar and in the Run panel’s ready line.

Animate is the other way to run: one core, every event drawn on the diagram as it happens. Its numbers are the exact sequence Raptor 7 produces. A full-speed run gives each slice of trials its own fresh dice, so its numbers differ slightly from the one-core run, but they are statistically the same answer, and the same on any machine whatever the Cores setting. To repeat a result exactly, run it the same way again.

Two buttons in Simulate ▸ Batch run the model many times at full speed, on a copy (the open model is never changed):

Both show the trials and cores they will use before you press Run, and both export a CSV.

Take Espresso1.rbds. Your boss needs season-survival probability to ±0.02. Start at 25 trials and grow the count until 2 × SEM ≤ 0.02. Record how many trials it took. Compare with a classmate: did you both land near the same count?

You now have the core toolkit: structure (Chapter 2, Your First Model: The Camping Lantern–Chapter 5, Voting: A Drone That Survives Losing Motors), failure physics (Chapter 6, Distributions: Same Average, Different Luck), repair economics (Chapter 7, Repair: The Vending Machine That Keeps Getting Up), and statistical honesty (this chapter). The next chapters put that toolkit to work on logistics, standby, maintenance, and whole systems.

Every model in this book so far has started the same way: at t = 0, every part is brand new. That is not a modelling choice you made — it is the simulator’s own default, and it is not always true to life. A laundromat’s washing machine, fresh out of the crate, is not a fair stand-in for the same machine three years into daily service. If you only ever simulate short missions, you are quietly asking "how good is this thing when it’s new?" — even when the question you meant to ask was "how good is this thing, most of the time, for years to come?"

Open models/Laundromat1.rbds. One block, Washer, Weibull wear-out (shape 2.5, scale 200 hours), repaired in about 12 hours when it breaks. The file ships set to a 200-hour mission — one wear cycle, roughly the kind of mission length Chapter 2, Your First Model: The Camping Lantern through Chapter 8, How Many Trials? Trusting Your Numbers have all used. Press F5 at 200 trials.

That number is not wrong. It is answering a real question: "how does a fresh washer perform over its first 200 hours?" But every one of those 200 trials started the same way — brand new, zero wear, zero chance yet to have failed even once. This early-life advantage is called a startup transient: a real, measurable bias toward optimism that fades only once a system has lived through enough of its own history to behave like itself, not like a showroom model.

Open Project Settings. Stretch the mission from 200 to 2200 hours — long enough that the first 200 "new machine" hours become a small fraction of the whole — and run 200 trials again.

The number moved. Not because anything about the washer changed — the same dice, the same wear curve — but because a longer run dilutes the honeymoon with a much larger stretch of ordinary, already-broken-in behaviour. This is the system settling into its steady state: the behaviour it actually has, most of the time, once "new" has worn off.

Stretching the mission and eyeballing the drift works, but it mixes the honeymoon back in — it is diluted, not gone. RAPTOR Studio has a sharper tool: Statistics start time, in the same Project Settings dialog. Set it to 2000 hours (keep the mission at 2200) and run again:

Watch the event log for the moment it happens:

At exactly t = 2000, every counter in the report — Availability, MTBDE, MDT, all of it — zeroes out and starts over, mid-run, with the washer already mid-life. The final report reads as if the mission began at 2000 hours, in whatever state the system had already reached by then. Everything from 0 to 2000 hours ran, and mattered — it is why the washer is mid-life at the reset — but none of it is counted.

The laundromat’s owner wants to quote new customers a number: "how reliable is this washer in its first week?" Which of this chapter’s two numbers should go on the flyer — and which one should go in the maintenance budget spreadsheet instead? Then verify your instinct: run Laundromat1.rbds at its original 200-hour, zero-delay setting for 2000 trials, and compare the tightness of that estimate (its SEM) against a 2000-trial run of the 2200-hour, 2000-hour-delayed setting.

Next chapter: parts that run out, and what happens when the shelf finally goes bare.

Your taco truck grills with propane. A tank lasts about 200 hours of service, and swapping an empty tank takes 2 hours — you carry spares, so this is no disaster.

But your shelf holds exactly 3 spare tanks. Nobody delivers to the festival grounds. When the fourth tank runs empty, the truck closes for the season. Mission: a 1000-hour season. Will the shelf last?

Until now every repairable block had an invisible assumption: infinite spares. Repairs always found what they needed. RAPTOR Studio makes this explicit. Each block has a sparing setting:

Open models/TacoTruck1.rbds and select Propane_Tank. In the Data Tables or Inspector you see:

The second block, Grill, is ordinary: Weibull wear-out, Lognormal repair, infinite spares.

Mission settings: stop at 1000 hours, 20 trials.

Press F5. Typical results:

Now read the Event Log tab for one trial. The story has three acts:

The fourth failure is different from every failure in earlier chapters. No repair starts. The block goes Done permanently, and so does the truck. With mean tank life 200 h, four tanks last about 800 h — the truck dies in act four, somewhere near hour 800, and availability lands near 800/1000 plus small change.

The supplier offers a bulk deal: Stock 3 → 6. Before simulating, estimate the expected season end time by hand (four more failures × mean 200 h). Then set Stock = 6 in the Data Tables and run 100 trials. Did availability rise the way you predicted?

Next chapter: spares that are not parts on a shelf, but whole machines waiting switched-off in the dark.

A bakery cannot sell bread without one working oven. Running two ovens side by side would work — that is Chapter 3, Redundancy: Two Pumps Are Better Than One. But two full ovens burning all day is expensive, and both wear out twice as collectively fast.

Instead: one oven bakes, one oven waits in the cold. The standby oven does not age while it waits. When the main oven fails, the baker switches over. Waking a cold oven takes about half an hour — you cannot bake during that gap.

Mission: one 720-hour month. How often is the bakery dark?

Chapter 3, Redundancy: Two Pumps Are Better Than One's OR node kept both pumps running. A cold standby node keeps exactly one input running and holds the rest asleep:

Open models/Bakery1.rbds. The pieces:

Press F5. Then open the Event Log for trial 1. It opens like this:

Four beats, worth naming:

Typical numbers at 20 trials: availability about 0.997, about 3 stoppage events per month.

Baker’s nightmare: make the switch manual instead of automatic. In each oven→node link set AProb from 1 to 0.9, AutoTime to 0, ManTime to 3. Now 10% of switches need the owner to drive in: 3 extra dark hours each time. Run 50 trials before and after, and compare availability.

Next chapter: stop waiting for things to break. Service them on a schedule.

Your moped engine wears out. Its lifetime follows a Weibull curve with shape 2.0 and scale 800 h — that shape-2 curve is the classic "wear-out" signature from Chapter 6, Distributions: Same Average, Different Luck: unlikely to die young, increasingly likely to die old.

When it does fail, the breakdown repair is ugly: a Lognormal job averaging about 8 hours, sometimes much longer (that fat right tail again).

You have a better idea: every 400 hours, do a scheduled service. A service takes only 2 hours, and afterward the engine runs like new.

Mission: 2000 hours of commuting. Is the schedule worth it?

Open CarCare0.rbds. One block, Moped_Engine, between start and end:

Now open CarCare1.rbds and select the engine. The PM rows appear:

Run each file at 200 trials (set the run count before pressing F5). The Overview tab summarizes a run at a glance — this one is CarCare1.rbds at 20 trials, so its numbers wobble a little from the 200-trial figures below, exactly as Chapter 8, How Many Trials? Trusting Your Numbers predicts:

Typical results at 200 trials:

Read those numbers like a mechanic would:

The trade in one line: PM converts rare, long, surprise outages into frequent, short, scheduled ones.

Tune the schedule. Try PM intervals of 300, 400, and 500 hours (100+ trials each). For each, record availability and total downtime per run. Plot downtime against interval. Where does the curve bottom out, and why does moving the interval down eventually make things worse?

You now hold the full basic toolkit: series, parallel, k-of-n, all five life distributions, repairs, sparing, standby, and preventive maintenance. The next chapters move from parts to systems: shared pools, hierarchies, capacity, money, and finding your weakest link.

A delivery van has an engine problem and a tire problem. Its diagram so far would be six blocks on one flat sheet: Fuel_Pump and Engine_Core in a row, then four tires voting "at least 3 of 4". Chapter 5, Voting: A Drone That Survives Losing Motors taught you the vote; this chapter is about paperwork.

Real systems do not live on one sheet. A van engineer draws the engine on one page, the chassis on another, and the whole van on a cover page. RAPTOR Studio has exactly this idea: the hierarchy, a box that hides a whole sub-diagram inside itself.

Open models/Van1.rbds. The home level is almost empty — two big ovals and some nodes:

Each oval is a door into a hidden drawing. Double-click Engine_sub (or use the Model Explorer tree) to descend:

Inside lives a plain series chain you could have drawn in Chapter 2, Your First Model: The Camping Lantern. Climb back out (double-click the Out marker or the Up button) and descend into Tires_sub instead:

The four tires fan out from the In marker and rejoin at a vote node — Chapter 5, Voting: A Drone That Survives Losing Motors's k-of-n, wearing overalls.

The oval itself has two readings. Its body colour is the hierarchy’s own status: green when nothing is lost, yellow when it still works but something inside has failed, red when the subsystem is down, plus blue for standby, brown for idle and orange for preventive maintenance. The two downward triangles in the middle are Raptor’s Descendant Status Indicator (DSI): the worst status of the hierarchies inside this one. Green body with a yellow or red DSI means this subsystem still works but something deeper is degraded or down; a red body means the subsystem itself is down. The name sits inside the oval at rest; while a run is animated, stepped or shown with its triangles, it moves under the oval, as in Raptor, so the triangles keep the middle of the body to themselves.

While you animate or step a run, both are live. After an ordinary run (with Weak Link analysis on), the triangles show the share of time, over every run, that the inside was working, partly failed, on standby or down. Point at the oval and it says which.

Here is the claim worth testing: the hierarchy changed nothing physical. VanFlat.rbds is the same six blocks with no ovals at all.

Run both files at 200 trials:

Identical — digit for digit. The engine does not know an oval from a straight line. A hierarchy is pure organisation: it exists so a human can draw, read, and reuse big diagrams without a wall-sized sheet.

So when does a real study need them?

When you are building a big model one part at a time, you often want to know how just the tires behave before the rest of the van exists. Pick the hierarchy (the Model Explorer or the canvas), choose Extract Hierarchy… on the Model ribbon, and RAPTOR Studio builds a small standalone model: the hierarchy’s contents become the whole diagram, its In door becomes the Start and its Out door the End. You can run it, save it. From the command line the same thing is:

What the input means. The extract assumes the hierarchy’s input is always available. Anything upstream of the door is outside and ignored, and every result says so.

What is lost at the boundary. Some things inside a hierarchy are tied to things outside it. RAPTOR Studio scans for three kinds, tells you which it found, and lets you pick what to do about each:

Costs, weak-link and capacity results describe the extract only. A model that ends after N system failures (or N phase cycles) now counts the hierarchy’s failures, not the system’s. If the hierarchy is itself phased, its own Cut or Linked phases are ignored in the isolated run, and you are warned.

Give the van a spare wheel. Inside Tires_sub, add a fifth block Tire_Spare (Exponential, mean 800 h, Fixed 2 h repair) feeding the same vote node, and raise the vote to n = 5 while keeping k = 3. Before running: does availability rise or fall? Then run 100 trials and compare against the table above.

Next chapter: make the pipes matter — capacity, flow limits, and what happens when a surviving part simply cannot carry the load alone.

A small town drinks 180 megalitres of water per hour, pumped through three pipes from the wells to the manifold. Heat wave: the demand is more than any two pipes can carry. The pipes themselves almost never break — but pipes have sizes, and sizes are numbers, and numbers can be compared with thirst.

This is a new kind of question. Until now a part was alive or dead. Now we ask: how much gets through?

Open the model. Three pumps fan out from start, meet at the Manifold, and flow on to end:

Each pipe (the link from its pump into the Manifold) carries two numbers:

The engine fills every pipe to its nominal first. If demand is still unmet, the leftover is spilled into the pipes' headroom, best pipe first, until the ceilings are reached or the thirst is quenched. Whatever thirst remains is lost flow — and lost flow is money (Chapter 15, Cost: The Bill Arrives will bill for it).

Load models/Water1.rbds. In Model → Project Settings notice two settings that were never there before:

Run 200 trials of the 8760-hour mission (one year). The summary still opens with the old friends:

Availability looks perfect — and that is exactly the trap. The system is "up" whenever any path from start to end exists; with three pumps, that is nearly always. Meanwhile the town lost about 63 000 megalitres over the year — roughly one day in twenty, drained away into yellow time that availability cannot see.

The new Capacity section of the end-of-run report tells the real story. The system’s maximum deliverable flow is 190 when all pumps run. Watch what one failure costs, straight from the run-1 log:

The biggest pipe causes the biggest thirst when it dies. Sizing redundancy by "any two cover it" hides this: 140, 130, 110 all sound fine until you remember the town wants 180 every single hour.

The council upsizes Pump_C’s pipe: nominal 60, max 100 (edit the nomFlow/MaxFlow columns of that link in Water1.rbds, or ask for the updated file). Before running: predict the new lost-per-hour when each single pump is down. Then run and check. Which pump’s failure hurts most now — and is the answer still the biggest pipe?

Next chapter: put a price tag on every failure, every repair, and every lost megalitre.

The pumps held, the pipes held — and then the invoice from reality arrived. Every pump repair sends a crew (money per hour) and a callout fee. Every hour the town is completely dry, the utility trucks in emergency water. And every megalitre that never made it through the pipes — the yellow-time shortfall of Chapter 14, Capacity: The Thirsty Town — has a price too.

Simulation already knew about all of it. Cost analysis just adds up the arithmetic.

Open models/Water2.rbds and choose Model → Project Settings:

Money is configured in three places:

Run 200 trials of the 8760-hour mission. The end-of-run report grows a COST section. For one typical run:

Averaged over the year of 200 trials:

Read that table twice. The three pumps — bought, crewed, called out — cost about 335 000 a year. The water the town never received costs 2 500 000. The failure bill is not the repair bill; it is the shortfall bill, and it is seven times larger.

Chapter 14, Capacity: The Thirsty Town's exercise upsized Pump_C’s pipe to nominal 60 / max 100. Do it again on Water2.rbds (edit that link’s nomFlow/MaxFlow in the file), run 100 trials, and compare grand totals. Estimate the yearly saving, then answer: if the bigger pipe costs 250 000 to install, how soon does it pay for itself?

Next: put series, sparing, PM, and cost together on one production line, then find the part that deserves your money — the weak link.

A bottling line: rinse, fill, cap, inspect the cap, label, date-code, form the carton, pack the case, seal it, inspect it, palletize, wrap, ship. Fourteen stations, bolted together in one straight chain. Chapter 2, Your First Model: The Camping Lantern's oldest rule, scaled up fourteen times: one broken link and the whole line stops.

The plant manager has a budget question, not an engineering one: the line carries a modest spares shelf and a maintenance contract that together cost real money every year. Is any of it worth what it costs?

Open models/ProdLine0.rbds — the line exactly as it was commissioned, no changes yet. This time nobody hands you a blame table the way Chapter 17, Weak Links: Blame the Right Part will. Work it out yourself, and notice why it is easier here than it will be there: this line is pure series, with no vote to forgive anything. On a system like that, "how often does a part fail" and "how much does its failure hurt" are the same number — every failure, anywhere, stops the whole line. Chapter 17, Weak Links: Blame the Right Part needs two separate tables because VanFlat’s tires fail constantly but mean almost nothing; this line has no tires. One table is enough.

Run 200 trials, open Data Tables → Sparing, and read Spares_Utilization’s `AveUsed column — for a block still on Infinite sparing, it is simply a per-run failure count. Three stations stand well clear of the rest:

Every other station sits under 3. All three leaders share the same signature — a Weibull curve with shape well above 1, Chapter 6, Distributions: Same Average, Different Luck's wear-out shape. That is not a coincidence you need statistics to see; it is the whole reason ProdLine1 only ever touches these three stations.

Chapter 10, Sparing: The Taco Truck’s Propane Shelf's Taco Truck kept three propane tanks on a shelf that nobody ever restocked — when the fourth failure came, the truck closed for the season. That chapter’s whole point was showing you what happens without a resupply plan. Open ProdLine0.rbds and select Filler: it is Custom-spared, stock 3, exactly like Propane_Tank, right down to the field that made the truck’s ending permanent — RSO=0, no routine spare ordering. Capper carries the same setup, stock 2.

Now open ProdLine1.rbds and select the same block:

RSO=1 turns the shelf into a standing purchase order: a fresh tank arrives every 30 days whether or not one was used, and if the shelf ever actually runs dry anyway, an emergency shipment lands in 48 hours instead of never arriving at all. Case_Packer gets the third piece of the review: scheduled PM every 600 hours (Chapter 12, Preventive Maintenance: The Careful Commuter's pattern exactly), refreshing it before its Weibull clock ever gets the chance to wear it out.

No other station changes between the two files.

Run 200 trials of the 8 760-hour year on each file:

Read that middle row carefully before the cost table: failures per run went up after the fix, not down. A line that is actually running is a line that can fail again; a line stuck dead on its fourth Capper failure, like ProdLine0 spends real time being, cannot rack up a fifth. Count alone would tell you the wrong story — MDT is the number that says each of those failures now costs less than half as much time.

Now the number the plant manager actually asked about. Both files carry a System red cost of $8 000 per down-hour (Chapter 15, Cost: The Bill Arrives's field, same one DC1/DC2 used):

The review spent about $17 000 a year more on parts and maintenance. That $17 000 bought back about $2.07 million a year in avoided downtime. Chapter 15, Cost: The Bill Arrives's lesson from the little bakery repeats here at industrial scale: the line item you can see on an invoice (spares, service contracts) is never the number that decides whether a fix was worth it — the downtime bill is, and on a fourteen-station chain, it dwarfs everything else once even a couple of stations are left unmanaged.

Pick one of the eleven untouched stations. Read its AveUsed from Spares_Utilization and decide honestly whether it belongs anywhere near the top of the table you built above. If it does not, predict — before touching the model — that giving it a Custom shelf and an RSO resupply plan will cost money and buy almost nothing back. Then do it anyway: pick a stock size, turn RSO on, run 200 trials, and check Grand_Total. Were you right?

Chapter 17, Weak Links: Blame the Right Part next turns what you just did by hand — squint at AveUsed, guess, check the cost — into a repeatable two-table method, on a system where frequency and importance genuinely disagree.

The van’s mechanic wants attention paid to the tires — "they fail constantly!" The dispatcher disagrees: "When did a tire ever stop a delivery?" Both are holding real data. Only simulation can settle whose data matters.

The van has two kinds of parts. The four tires fail often — but the 3-of-4 vote from Chapter 5, Voting: A Drone That Survives Losing Motors forgives any single flat, so the van limps on, marked yellow. The fuel pump and the engine core sit in the series chain: when either dies, the delivery dies with it.

So we expect two different league tables:

The weak link is the top of the importance table. Money spent anywhere else buys almost nothing.

Load models/VanFlat.rbds. In Model → Project Settings, tick Weak Link analysis and Apply. That one checkbox tells the engine to keep a per-part timesheet: hours running, hours under repair, per trial.

Run 200 trials of the 2000-hour mission and open one trial’s report. Each part’s timesheet, averaged over the trials:

The tires combined rack up more repair time than either series part — the mechanic’s data is honest. Now the importance table: read 200 event logs (Chapter 3, Redundancy: Two Pumps Are Better Than One's skill) and ask, at every moment the system went down (red), which part was down?

And the same count for yellow (degraded but drivable) moments: the tires own essentially all of them — about 1 900 flat-tire events across the trials, and the van kept driving through nearly every one.

That is the whole trick of weak-link thinking in one table. The tires are the busiest parts in the van and almost the least important. The fuel pump fails a third as often and causes two-thirds of the stoppages.

Results ▸ Show on Canvas ▸ Weak Links paints each block by its availability against two thresholds, Green ≥ 0.95 and Red < 0.90 unless you change them. In a well-designed system every block can sit above 0.95, so everything comes out Green. Press Spread beside it: it moves them to the quartiles of the result set’s averages, so the worst quarter of the blocks turns Red and the best quarter Green. It ranks the blocks against each other, not against an absolute target, so read it as "where to look first".

The fuel pump is guilty. Upgrade it: change `Fuel_Pump’s failure mean from 500 to 1500 hours (F Param 1 in the Data Tables), run 200 trials again, and compare:

Real improvement — MTBDE up four-fifths. But look again at the importance table: the fuel pump’s share collapsed, and Engine_Core inherited the crown (now roughly half of all stoppages). Systems do not run out of weak links; they promote new ones. Tuning is a loop: measure, fix the leader, re-measure — exactly the loop the final chapter’s data centre will put to work.

Without running anything: the engine core now causes about half of stoppages. Predict the MTBDE if Engine_Core’s Weibull mean doubles (shape stays 2, mean 1000 → 2000; F Param 2 in the Data Tables). Then run 200 trials and check yourself. Did the next weak link already appear?

Weak links rank parts by how much time they cost. There is a second question, and it is the one budgets are actually spent on: if I could make one part better, which one buys the most?

Switch on Run ▸ Analysis ▸ Importance measures (leave it on Both) and run the same 200 trials. That costs twelve more batches, one per block per variant, so it takes a few minutes — set Cores above 1 first. Open Results ▸ Final Results ▸ Importance:

Two parts hold 94% of the van’s downtime between them. That matches the weak-link chapter’s story, and it is the same answer reached a different way: weak links read the state timesheet, importance reads what happens to the system when this block is taken out of the picture.

The tires are the interesting row. Their share is a hair below zero, which looks like nonsense until you know what the number is made of: each measurement is two extra batches of simulated futures, and those draw their own random numbers, so a part that does not gate the system lands either side of zero on noise. At or below zero means "no measurable effect", not "fixing this makes it worse". That is why the column has a standard error beside it, and why the page ranks by share of downtime rather than by Birnbaum — in a series van Birnbaum reads about 0.99 for every part, which tells you nothing about which to fix.

Change Measured on to Reliability and the ranking can move: a part can be cheap in downtime and expensive in failed missions. Which of the two you want is a question about your van, not about the arithmetic.

Next chapter: a part that doesn’t wear out at all — it just works or it doesn’t, decided once, in an instant.

You run the fireworks crew for a summer festival. The grand finale is one button press: five shells, wired to one control board, all fired at once. Each shell either lights or it doesn’t — there is no "half a second later" to speak of, no wearing out, no warming up. It works or it is a dud, decided the instant the button goes down.

The crowd will forgive one dud among five. They will not forgive a sad little finale. You need at least 3 of the 5 shells to fire for the show to land. Question: with shells you’d rate at 80% reliable each, how often does the finale actually land?

Every block in this book fails and lives across time — a clock ticks, dice get redrawn, days pass. An event is different: it is a single Bernoulli coin flip, decided once, at the very start of the mission, and never touched again. RAPTOR Studio draws it as a hexagon, not a rectangle, so you can tell the two apart on sight.

Notice this model has zero blocks — the status bar says so. Five events (Shell_1…Shell_5), each an independent 80% chance of firing, feed the same kind of vote node Chapter 5, Voting: A Drone That Survives Losing Motors already taught you: need 3 of the 5 inputs alive for the node — and the mission — to count as a success.

Press F5. Watch the event log for one trial:

Every single line lands at t = 0.000000. Shell_5 was a dud, but four of five still clears the 3-of-5 bar — the health bar shows Yellow, not Red, and the mission still counts as a success. Then the run simply ends: Simulation_Terminate fires immediately, because once every event has resolved, nothing in this model can ever change again. There is no rest of the mission to simulate.

Do the math check: five independent 80% shells, need at least three. P(≥3 of 5) = C(5,3)·0.8³·0.2² + C(5,4)·0.8⁴·0.2 + 0.8⁵ = 0.2048
0.4096 + 0.32768 = 0.94208 — the simulator’s own long-run number, to the fourth decimal. A high-trial run (20 000+) lands on 0.9423; a quick 20-trial run in the app might not, and that is Chapter 8, How Many Trials? Trusting Your Numbers's lesson again, not a new one.

The town council tightens the bar: they now want 4 of the 5 shells to fire, not 3. Before running anything, use the same kind of arithmetic as above to predict the new reliability. Then change the vote node’s k from 3 to 4 in the Data Tables and run 2000 trials to check yourself. How much did one extra required shell cost you?

Next chapter: one system, three different mission stages, and the report that only exists once you tell the engine about them.

Your automatic car wash runs one car at a time through three stations: Soap, Rinse, Dry. Each station takes a couple of minutes, then the next car rolls in and the cycle starts again — all shift long. The dryer’s blower has one job, and it is not needed during Soap: running it into a car covered in suds just blows foam everywhere. So the control system switches the blower out of the circuit for Soap, and back in for Rinse and Dry.

Here is the billing question that matters to the owner: is a blower that is "down" for Soap actually broken? And if a customer complains the wash felt unreliable today, should the owner care about the whole shift, or just the two stations they actually paid to have work?

Every model so far ran under one constant set of rules for its whole mission. A phase lets the model cycle through several stages, each with its own duration and its own rules for how individual parts behave — then wrap back to the first stage and repeat, for as long as the mission runs.

Open models/CarWash1.rbds. Two blocks in series, same shape as Chapter 2, Your First Model: The Camping Lantern's lantern — except one of them looks different:

The diagonal hatching on Blower is RAPTOR Studio’s marker for a phased block. Select it and scroll its General tab to the Phasing group: a "Phased" checkbox, and one dropdown-plus-value pair per phase, named after the phase itself:

Track_Motor, which drives the car through all three stations, carries no phase settings at all — it just runs, the whole shift, exactly like every block in earlier chapters. Phasing is opt-in, block by block.

Press F5. The very first lines of the log show the mission starting already Red — Soap is phase 1, so Blower starts Cut:

At t = 1.94 — Soap’s own draw from Normal(2.0, 0.1) — the wash enters Rinse, Blower rejoins as Good, and the system turns Green again. Watch a later cycle catch a real breakdown instead of a scheduled one:

Same red health bar either way — but the comment differs. A scheduled Cut never produces a Mission_failure line; an actual breakdown during a mission phase does.

Availability counts every red minute — scheduled Soap pauses included — so it lands near 70%, dominated by the roughly 2 of every 7 minutes the blower spends deliberately parked. Dependability tells a different story: about 0.98.

Look back at each phase’s own Mission flag: Soap is Mission=0; Rinse and Dry are Mission=1. The engine keeps a second clock that only accumulates during Mission=1 time, and Dependability is Green-plus-Yellow time on that clock, divided by that clock’s own total — Soap’s downtime never enters the calculation at all, in either the numerator or the denominator.

The Phases… button on the Data ribbon opens the phase list on the left and, on the right, one grid per kind of element (blocks, nodes, events, hierarchies) with a column for every phase. Four buttons change the list:

Each element’s cells move with the phases, so nothing you set is lost. A new phase starts every phased element with a default cell: a block is Active at stress 1, an event is Prior, a node requires its own number of good paths (or is Linked if that number is 0), and a hierarchy is Active. The whole dialog is one undo step per button.

Before running anything: predict what happens if you flip Soap’s own Mission flag from 0 to 1 in the Phases tab, leaving everything else untouched. Then make the change and run 1000 trials. Did Dependability move — and if so, to what?

Next chapter: put every tool in this book to work on one serious system — a data centre engineered to a standard, then tuned until it meets its number.

A colocation provider wants a new hall and hands you a slide with one number on it: 99.98% availability. That is the neighbourhood of what the data-centre industry calls a Tier III facility — Uptime Institute’s tier scheme runs from about 99.67% (Tier I) to about 99.995% (Tier IV), and TIA-942 uses a similar rated-1-to-4 scale. Put the target in hours: one year is 8 760 hours, so 99.98% allows about 1.6 hours of downtime per year. Everything else in this chapter is the pursuit of those 96 minutes.

The industry’s shorthand for redundancy:

You own the tools for all three. Time to build.

Open models/DC1.rbds. Chapter 13, Hierarchies: The Delivery Van, Tidied Up's hierarchy idea, at building scale — the home level is just three ovals in series (power, cooling, IT), because the hall works only if all three work:

Step inside each oval (double-click, as in Chapter 13, Hierarchies: The Delivery Van, Tidied Up):

Twelve blocks, three hierarchies, one cold standby pair, two votes, one series backbone — every shape from the first ten chapters of this book, wearing hard hats.

Run 200 trials of the 8 760-hour mission:

Ninety-nine point nine five percent sounds excellent — and misses the target by nearly three times. The downtime budget was 1.6 hours; the facility spends 4.5. Now do what Chapter 17, Weak Links: Blame the Right Part taught: blame someone. Read the event logs and ask which part was down at each red:

The table reads like a to-do list, sorted.

Open models/DC2.rbds — the same facility after the design review. Three changes, each answering one line of the blame table:

Note what the moves have in common: none of them makes any part less likely to fail. They shrink the consequence of failure — Chapter 17, Weak Links: Blame the Right Part's other dial.

Run 200 trials again:

The target was 1.6 hours; DC2 comes in at about 1.4 — Tier III reached, with a little margin. Notice the price, though: yellow time nearly doubled. Redundancy converts hard stoppages into soft degradation — the CRAC that used to stop the hall now merely trims its margin, the PM that used to be an outage is now a yawn on the health bar. A well-tuned facility is yellower than a fragile one.

And Chapter 15, Cost: The Bill Arrives's question — what does downtime cost? — has a blunt answer here. At a data-centre rate of 300 000 per down-hour, DC1’s year costs about 1.36 million in outages; DC2’s about 0.42 million. The redundancy was not free to build, but the model says it pays for itself in months.

DC2’s own 200-trial run reports Availability Mean 0.999835, SEM 0.0000140. Apply Chapter 8, How Many Trials? Trusting Your Numbers's own rule of thumb:

The whole interval sits above the 99.98% (0.9998) target — DC2 clears its Tier III number with real margin, not by luck of the draw. That might be surprising: the Formulas quick reference warned that pinning down a rare event can need tens of thousands of trials. The difference is what is being counted. A four-nines Reliability figure (ch-events' own territory) is one 0-or-1 coin flip per run — you need enormous trial counts to see enough of the rare "1" outcomes to trust the average. Availability is not a coin flip: every one of these 200 runs already measures a full 8 760-hour year, hour by hour, so even one run carries far more information about the system’s true up/down ratio than one Reliability trial ever could. Precision comes cheap here because the metric itself is generous with data, not because 200 is a magic number — a model reporting Reliability at these odds would need Chapter 8, How Many Trials? Trusting Your Numbers's rare-event math in earnest.

The provider now waves a new slide: 99.99%. DC2 is not there yet — find the next line of the blame table yourself. Run DC2, count the red-stretch causes from the event logs, and identify the single biggest remaining contributor. Then make one change to the model — a second utility feed so the generator never carries, a faster Chill_Pump repair, your pick — and run 200 trials. Did you clear 0.88 hours? What became the new weak link?

You have come a long way from a camping lantern. Same dice, same event log, same three numbers — just aimed at bigger machines. Go point the simulator at something that matters to you.

Next, the strangest lens in the toolbox: watching the simulation think, one event at a time. Then one last capstone — the hardest of the three, because this time nobody hands you the model.

Everything so far ran in the dark: you pressed Run, and minutes of simulated life rushed past as a finished report. But sometimes you want to watch. Why did the system go red at 181 hours? What exactly happened in the half-second the transfer switch was thinking?

RAPTOR Studio has a debugger, the same way program editors do. You step. The machine advances one event. The diagram re-colours. The status bar narrates. You are watching the simulation think.

Open models/Bakery1.rbds and switch the ribbon to the Debug tab. Ignore Run on the Simulate tab — that is the old batch world. Press Step (F6) instead:

The first press does something subtle and important: it starts the run — every block initialised, the standby oven parked in its blue Standby slot — but the clock still reads 0.000000. Nothing has happened yet. Three event-log lines, no time elapsed.

Press Step again. And again. Each press advances exactly one event: a block’s state change, a node’s recalculation, a system colour change. Watch three things move together:

Step about thirty times and you reach the moment Chapter 11, Cold Standby: The Bakery’s Second Oven made famous: Main_Oven Failed at t = 180.974304. The oven’s box turns red, the swap node goes Bad, the end dot goes red, the system line logs State_change Red:

Half an hour of model time later, the next step wakes Standby_Oven — its box shifts from blue standby to green running, the end dot returns to life, and the system, still yellow until the main oven is repaired, limps on. You have now witnessed the wake-up gap that Chapter 11, Cold Standby: The Bakery’s Second Oven only reported as a number.

Thirty presses to the first failure is fine. Three thousand would not be. Open the More Steps menu on the Debug ribbon for the bigger levers:

A comfortable rhythm: Run to time just before the interesting era, then single-step through the drama.

The Debug ribbon tab also has a Failure Effects group. It is a separate mode, not part of a stepped run: press Failure Effects and the diagram shows the bakery all-operating with no dice involved. Click Power and it turns red — a blackout at a time of your choosing, with the cascade and the end dot following at once. This is the simulator’s version of pulling a breaker to see what the building does. Click it again to put it back; Status says in words what is failed, what that induced, and which nodes are down or degraded.

A stepped run in progress is discarded when you open the view (it asks first), and Run and Step are greyed out until you leave it.

To end a stepped run, press Finish. The session completes the run — remaining events, closing bookkeeping — and then every later run the model is set to make, and presents the full reports, exactly like a batch run: summary, event log, the works. A stepped session covers all the model’s runs: Jump lets the current run go by without stopping and pauses at the next run’s first change, with the dice carried on from where the run before left them. The session is single-use; the next Step starts a fresh one with fresh dice.

Load models/DC1.rbds, set a breakpoint on Utility_A, and press Multi with 50 events per press until the breakpoint fires. Then single-step through the transfer: count the event-log lines between Utility_A Failed and Generator waking. That count — each line a state change somewhere in the facility — is what a batch run summarises in one red stretch. Note the moment Power_sub goes Bad and the moment the system goes Red: same instant, one cascade.

That is the whole toolbox: dice, diagrams, redundancy, standby, maintenance, hierarchy, dependency, events, phasing, capacity, money, weak links, a facility tuned to a standard, a line that paid for its own spares — and now a window into the machine itself.

One capstone is left, and it is the hardest of the three: this time, nobody hands you the model.

Optional:

By default the MCP server communicates over stdio: your AI client launches the server as a child process and speaks JSON-RPC to it. Configuration means telling the client the command and arguments. The server can also serve MCP over HTTP; see Section 22.4.1, “Serving over HTTP”.

Nothing outside the workspace is ever written unless --allow-write permits it; open_model only reads the workspace, bundled examples and --allow-read directories. Over stdio the server listens on no network port.

If the server does not appear, see Section 22.11, “Troubleshooting”.

The assistant discovers the tools automatically — you do not need to name them. These examples show what a conversation looks like.