Results and comparison
PDF and Compare are the main actions. Technical data, at the bottom, contains Export (.zip), JSON and the seed. AGV batteries holds per-vehicle detail. Compare adds the paused run and immediately opens the session table; the archive remains the place to retrieve saved runs.
Results are collected while the simulation runs. The Results tab reads from the top down: run state, four headline numbers, the verdict, actions, then detail sections. Every run is also saved in your Run archive, and the Run comparison table puts several runs side by side.
What the Results tab shows
At the top of the tab, a switch chooses between Current run (the simulation you are running) and Run archive (runs saved earlier, see Run archive). Before the first run the current view offers a Start run button instead of zeros. Once data exists:
- Run state: Run in progress, Run finished or Paused, the simulated clock and, with a duration, a progress bar.
- Headline KPIs (see below).
- Verdict: once a run has finished, or is paused after at least 10 simulated minutes, one or two sentences with a status dot say what the numbers mean. They are the findings of the PDF report: problems first (gridlock, demand above capacity, AGVs not placed, saturated fleet, heavy traffic or queues, disturbances with a strong impact), otherwise what went well. When the remedy is the number of AGVs, Size the fleet opens Optimize›Fleet.
- Actions: PDF and Compare.
- Sections: Mission times and Bottlenecks open, Fleet usage, Timeline and Events collapsed, and at the bottom Technical data with Export (.zip), JSON and the seed.
Results are never written into the .sim file. Reset and scenario changes clear the current view, but the results produced so far are first saved in the Run archive, where you can reopen and download them later.
Headline KPIs
| KPI | Definition |
|---|---|
| Completed | Missions delivered (unloading finished). |
| Throughput | Missions completed per hour, averaged over the run. |
| Fleet utilisation | Share of time the placed AGVs are busy (not idle). |
| Queued | Orders currently waiting for an AGV. |
A growing queue with high utilisation means the fleet cannot keep up. A short queue with low utilisation means the fleet is oversized for the demand.
With a fleet of tugger trains, a Loads line below the KPIs counts one load per trailer (one per mission for other AGVs), delivered and per hour: a trip of a three-trailer train is one mission and three loads.
Detail sections
Return on investment
Once the ROI costs are complete, this section prices the run with the scenario's current costs. Its header shows the payback; below it are the investment, annual savings, payback, NPV, IRR and cost per mission, AGV against manual. Cost breakdown splits the investment, the AGV annual cost (maintenance, licences, energy, supervision) and the manual annual cost; Edit the costs opens the Scenario step. While inputs are missing the section lists them and offers Complete the costs.
| Measure | Calculation |
|---|---|
| Hours a year | Shifts a day × hours per shift × days a year. |
| Investment | AGVs of each fleet × price, chargers of the layout × price, software and installation. |
| AGV annual cost | Maintenance + licences + energy + supervision (supervisors × hours a year × hourly cost). |
| Manual annual cost | Operators per shift × hours a year × hourly cost + manual trucks × annual cost. |
| Annual savings | Manual annual cost − AGV annual cost. |
| Payback | Investment ÷ annual savings; Does not pay back without savings, beyond the horizon when it exceeds the years given. |
| NPV | −investment plus the savings of every year of the horizon, and the residual value in the last one, discounted at the given rate. |
| IRR | The rate at which the NPV is zero. |
| Cost per mission | AGV: (investment − residual value) ÷ years + AGV annual cost, divided by the missions a year (run throughput × hours a year). Manual: manual annual cost ÷ the same missions. |
The ROI is marked not valid when the run did not place every AGV, completed no mission or did not keep up with demand: at the end more orders are left than the working AGVs plus a small queue cover (the larger of the AGV count and 5% of the orders generated). While the run is in progress the values are a provisional estimate. The ROI is an estimate based on the costs entered and on the simulated model: it is not a quotation or a market price.
Mission times
| Measure | Definition |
|---|---|
| Average lead time | From creation of the order to delivery. |
| Lead time P95 | 95 % of missions were delivered within this time; the tooltip shows the maximum. |
| Average execution | From assignment to an AGV to delivery. |
| Queue wait | Time an order waits before an AGV is assigned (average, and maximum in the tooltip). |
| Average queue | Average number of queued orders, with the maximum. |
| Fleet distance | Total kilometres driven and the share driven loaded. |
Bottlenecks
Total traffic waiting time, the number of managed stops, then a ranking of the five paths with the most waiting (hover for stops and occupancy) and of stations with waits at access or queues. This is the first place to look when throughput is lower than expected.
In a capacity-only run (traffic rules off) the section is called Station waits and lists only stations, because vehicles wait for nothing else; Fleet usage names the same time Station waits, and Technical data shows the mode.
Fleet usage
One bar per AGV splits its time into Loaded transport, Empty travel, Loading / unloading, Return, Waiting for traffic, Disturbance stops (when disturbances are on), Charging and Idle, with utilisation, missions and kilometres; with several fleets the fleet's name appears next to the AGV. With batteries enabled, charge levels are shown too.
Disturbances
Shown when the run simulated disturbances. It lists Fleet availability (the share of time placed AGVs were not stopped by disturbances), the number of stops, the total stopped time and the missions affected; then one line per kind with the number of events and the time lost (hover for average and maximum duration and, for empty pickups and full drops, how many were solved by the backup and how many needed the operator), and the latest events with time, AGV, kind and duration. With zone reservations enabled it also lists the reservations achieved, the AGV waiting time in front of reserved zones and, for each zone, how many times it was reserved and for how long (hover for average, maximum and failed attempts). The Simulate canvas marks a reserved zone with Operator and a stopped AGV in red with ! and the Fleet usage bars show the lost time as Disturbance stops.
Timeline
Three charts, one measure each, sampled every simulated minute: throughput (trailing-hour average), queued orders and AGVs waiting for traffic. Hover a chart to read the value at a given time. Charts appear after two simulated minutes.
With a Production profile, the queue and throughput charts highlight peak intervals. The Production peaks legend names the flows; hovering a peak shows its flow and rate. Overlapping peaks share the shading. Read the queue before, during and after the peak: the end of the highlighted interval restores normal demand but does not clear queued orders or active work. A falling queue after the peak shows recovery; a queue that keeps growing suggests that even the normal demand is too high for this setup. Throughput is a trailing-hour measure, so its response is smoothed over time.
To configure a complete test, follow the worked example: 60 missions/hour, a 30-minute peak at 120, then back to 60.
If the run stops because it reaches the technical limit of 500 active sequences or 1000 pending orders, these charts retain the partial results. Treat the run as interrupted, not as a completed study: reduce the load, inspect the downstream logic or increase service capacity before repeating it.
Events and gridlock
Events lists what happened: assignments, completions, waits, returns and warnings. If every AGV with a mission has been waiting on the others for more than a minute, a Possible gridlock alert appears at the top of the results. In a capacity-only run it means that every AGV with a mission is waiting for an occupied station.
Traffic optimization results
Optimize traffic keeps its trials separate from the ordinary run. The report records duration, five planned seeds (three search and two verification seeds), the seeds actually executed, proposed changes, completed missions, waits, remaining blocks and why the search ended. If a configuration uses no random draws from initialization to the end of the duration, one trial is executed and the report retains the evidence of seed equivalence. Each candidate is checked separately; otherwise all five seeds are executed. Full-duration verification and acceptance remain necessary before keeping an improvement.
Completed missions, throughput and waits are compared as averages per trial, so executing one or five seeds does not by itself change the comparison. Remaining blocks use the worst case; lead time and execution are mission-weighted averages.
When you keep an improvement, or the search applies it on completion, the initial configuration and best kept result are archived with the report; intermediate attempts do not fill the archive. The traffic configuration fingerprint in results lets comparison distinguish before and after. Accepted geometry and transit points are project data; trials and results stay outside the .sim file.
No blockages detected in the completed trials applies to the durations and seeds listed. Local search selects families and defers less promising variants; the AI agent decides which changes to request and when to finish. Deferred alternatives remain untested: completion does not mean every configuration was examined or a global optimum was found. Read the completion or pause reason alongside the remaining blocks. Changing geometry can change the random draw order of disturbances even with the same seed.
Heatmaps
The Heatmap selector in the canvas toolbar colours the layout with the collected data:
| Mode | Shows |
|---|---|
| Occupancy | Share of time an AGV is travelling on each path. |
| Passes | How many times vehicles drove each path. |
| Entry waits | Seconds spent waiting to enter each path. |
| Waiting hotspots | Grid cells where vehicles stood still because of traffic. |
The values are drawn as a heat field: a soft band that glows around each path, or a spot around each waiting cell, on a warm ramp from dark red to pale yellow (from pale yellow to dark red in the light theme). Hotter paths also glow wider, and overlapping bands never add up beyond the legend maximum. A legend shows the scale; the 3D view shows the same field on the floor. Hover a path or a cell to read its value. The image button in the view controls downloads the current view as a PNG, including the heatmap and its legend, ready for a report.
Exporting results
Export (.zip) downloads an archive with:
results.json: formatagv-simulation-resultsversion 1, including the scenario used;- CSV tables:
summary,missions,vehicles,stations,segments,wait_hotspotsandtimeline; with disturbances, alsodisturbances(one row per event: kind, AGV, time, planned and actual duration, mission, station, outcome and backup station) and disturbance totals insummary; with zone reservations,zone_reservations(one row per reservation) andzones(totals per zone); with tugger trains,units_deliveredandunits_per_hourinsummary,unitsinmissions, and the delivered loads and trailer settings invehicles; with complete ROI costs, alsoroi(one row per measure, withvalid) androi_fleets(price and total per fleet), whileresults.jsonadds theroiblock with the costs used.
Column names are stable English identifiers such as throughput_per_hour or lead_time_p95_s, so spreadsheets and scripts keep working across versions. Files include a byte-order mark; the separator and decimal mark follow the interface language: ; and comma in Italian, , and point in English. JSON downloads only the JSON document, with the complete data.
PDF report
PDF creates a formatted A4 report of the run, ready to print or share, in the language of the interface. It works for the current run and for any run reopened from the archive; sections follow one another without empty half pages:
- Summary: run name, project, date, simulated duration and status; missions completed, average throughput, fleet utilisation and orders queued; the run outcome, an automatic reading of the numbers marked OK, CHECK or CRITICAL (demand served or growing backlog, saturated or oversized fleet, AGVs not placed, traffic waiting, mutual blocking); for the current run, the plan with the path occupancy heat map.
- Return on investment (with complete ROI costs): investment, annual savings and payback in the tiles, the not-valid warning when it applies, and the breakdown of investment and annual costs with NPV, IRR and cost per mission.
- Trends over time: throughput (trailing-hour average), orders queued and busy AGVs, on a simulated clock axis.
- Mission timing: average, median, P95 and maximum lead time, queue waits and execution, with the lead time distribution and the routes served.
- Fleet: time breakdown for each AGV (per fleet on large fleets) and one row per AGV with missions, utilisation, distance, loaded share and, when simulated, battery; with several fleets each AGV is labelled with its fleet's name.
- Disturbances (when simulated): fleet availability, random stops and stopped time in the summary tiles and in the outcome, a table by kind (events, time stopped, average, maximum, backup versus operator) the ten longest stops and, for zone reservations, a table per zone.
- Bottlenecks: for the current run, a plan of where AGVs stood still; the paths with the most waiting and the stations with their queues.
- Run parameters: fleets, order generation, dispatch criteria, service times, speeds, safety distance, battery policy and disturbance settings, with a short guide to reading the report.
Archived runs do not store the layout, so their report leaves out the two plans.
The PDF is a summary: long tables show only their first rows and say how many were left out. For every record use Export (.zip) or JSON.
Compare is also available for archived runs and opens the table immediately. Comparison conditions flags different durations, interrupted runs and random components; unequal durations or interrupted runs have no highlighted winners. In the current run, click a path or station in bottlenecks to centre it on the 2D map. Stations in the movement table are clickable too. ZIP and JSON exports are in Technical data.
The seed used by a run
Open Technical data to read the run's seed. Results JSON and the archive also retain its generator identifier. For an archived run, Reuse this seed applies that value to the current scenario through an ordinary scenario change, resetting the current simulation. It copies only the seed: to reproduce the archived run, you also need its layout, scenario and engine version. If the scenario already has that seed, the action is disabled.
Older results without recorded random metadata show the seed as unavailable. Their random choices cannot be reconstructed by assuming the current default. See Randomness for repeatable runs and comparisons with several seeds.
Run archive
The studio keeps every run you make, so you can reopen its results later, from this or another device, without having exported anything.
When a run is archived
- When it reaches its duration: it is saved as completed.
- When its results are about to be cleared, by Reset, by starting a new Start run or by a scenario change that restarts the simulation: the results produced so far are saved as stopped.
- Pause does not create a copy, because you can resume the same run. A run that never advanced beyond time zero is not saved.
Each run gets a name made of the project name, the date and time, and its state, for example Warehouse A · 23/09/2026, 14:05:12 · completed.
Browsing and reopening runs
- Open the archive. In Simulate›Results, click Run archive at the top of the tab. The archive lists only the runs of the open project; the counter shows how many there are.
- Find a run. The newest runs come first; each row shows name, date, state and completed missions. Type in the search box to filter by run name; Refresh reloads the list.
- Open it. Click a run: its full results appear below, marked Archived run · completed or Archived run · stopped, with the same KPIs and sections as the current run, except the event list. Archived runs cannot be added to the comparison table.
- Download it. Export (.zip), JSON and PDF work on the archived run as well.
- Go back. Current run returns to the simulation in progress.
To delete the selected run, press Delete and confirm. Deletion is permanent.
Where runs are stored
Runs are stored on the server in your private space, encrypted, separately from your projects and linked to your account: after signing in you find them on any device. The .sim project never contains them.
If a run cannot be saved right away (for example the connection dropped), it waits in a queue in your browser and a notice shows Runs awaiting save with two actions: Retry sends it again, Run archive opens the archive. The studio also retries automatically when you reopen it. Until the server confirms the save, the run is not visible from other devices. If the browser cannot store the queue, a warning appears and the pending copy lives only in the current tab: do not close it before retrying.
Run comparison
Every run that reaches its duration is added automatically to Run comparison in the bottom dock and announced once. To add a run you stopped by hand, press Compare in Results.
Each row shows the run's inputs (AGV count and, when it differs between runs, the traffic rules, the fleet mix, order interval or Diagram when Plant logic is on, speed, mission priority, AGV selection, battery, disturbances), its duration and its metrics: completed, throughput, lead time, P95, utilisation, maximum queue and traffic waiting.
- Changed inputs are highlighted, so you can see at a glance what differs between runs.
- The best value of each measure is marked with ▲, only when runs really differ. Utilisation is not ranked, because higher is not always better.
- Runs that had a possible gridlock are flagged.
- Remove deletes a row, Clear empties the table, Export CSV downloads it.
With complete ROI costs, the table adds Investment, Payback, NPV and Cost/mission, priced with the scenario's current costs, also for runs made before the costs were entered. A run whose ROI is not valid is flagged with ! and never wins; the investment is not ranked, because more AGVs cost more by design. Export CSV adds the roi_* columns.
The comparison keeps up to 12 runs and lasts for the browser session; it is not part of the project file.
Compare runs of the same duration and change one input at a time. Keep the seed to repeat a scenario, or try the same set of different seeds for each alternative to measure variability. Model changes can alter the order of random draws, so matching seeds do not guarantee matching disturbance times.
Warehouse results
The Warehouse section reports usable capacity, occupied cells, successful storage/retrieval operations, full/empty wait and the stock timeline. Full/empty waits measure simulation time with at least one unresolved stock/capacity request of that kind, including reservation waits; they do not sum overlapping requests. Stock changes at successful service, while mission completion also includes lowering and the required exit.
ZIP includes warehouse summary, per-warehouse capacity/stock with its kind (racking, floor stack or drive-in) and timeline CSVs; mission rows carry cell code, warehouse and operation. JSON and archived runs retain current stock, pending reservations, geometry and initial inventory. PDF includes warehouse totals, stock trend and fleet vertical parameters. Run comparison highlights changed geometry/initial inventory/flows and fleet lift settings; hover the changed input for detail, or export comparison CSV for the full configuration.