NoMAC Documentation

Model In One Minute

The tool estimates a daily A/n-classification metric by sampling active drone positions from a normalized Dn traffic map, grouping nearby drones into blue disks, calculating local free area per drone, and applying a proposed binary DAA rule. U-plans are evaluated separately as planned routes with speed, altitude, departure time, and geofence-band checks.

Workspace and live demonstration

The interface separates Scenario, Live demo, Results and Compare runs. More detail exposes diagnostics; the Geofence and U-plan editors have separate inspector switches. Select a U-plan card to open its properties and highlight its route. Results shows the 2D decision map; mathematical explanations are collected on this page.

Live demo captures twelve five-minute snapshots over one hour of simulated day one, using the same random stream, grouping and A/n classification as the shared engine. The hour contains the earliest U-plan departure, or starts at midnight if there are no plans. The status names the scenario hour; the clock shows elapsed time within it. Earlier random draws are consumed when inspecting a later hour so its samples remain aligned with the full run.

Drag the time slider to inspect any moment, or use the previous/next snapshot icons to move between samples. At 60:00, the last background sample (55:00) remains visible; there is no extra thirteenth sample. The view has no automatic playback. The Airborne in this snapshot badge beside the map title counts sampled background drones, excluding the separately planned U-plans.

Find a group or select its disk to inspect the enclosing geometry, free area and threshold. Focus group enlarges it; Fit map restores the overview. The compact note above the map explains the calculation chain. Aggregate statistics for the full simulation remain in Results.

Background positions are held for inspection and replaced every five simulated minutes; they do not represent continuous drone trajectories. U-plans follow continuous planned paths as the selected time changes. The two layers are evaluated separately. The view shows the A/n research model, not executed avoidance maneuvers or physical collisions. See the interface review for detailed semantics and validation.

Traffic Field: Dn Overlay

Dn is the relative traffic weight stored in the GeoJSON file. The colored overlay shows where sampled active drones are more or less likely to appear. It is not a direct real-time probability that a drone is currently there.

Here p_i is the probability of selecting grid cell i for one active-drone position in one five-minute snapshot. It is not a probability for an exact point or for an entire day. After selecting a cell, the position is sampled inside that cell. High Dn cells are therefore sampled more often. The displayed map is a bounded analysis scenario, not the full reachable world. Transparent or uniform-looking areas are retained exactly as represented by the loaded grid; the tool does not invent synthetic Dn outside or between source cells.

The overlay displays the current adapted Dn weights. Its colours are contrast-enhanced and clipped near the high end, so colour differences are relative rather than a linear probability scale. Satellite imagery is an ArcGIS World Imagery backdrop and does not enter any calculation.

Source: LiU probabilistic traffic map, QRA demand-map approach, and the local GeoJSON Dn field. Display scaling is an implementation choice.

Geofences

A geofence is a polygon that blocks traffic in the horizontal Dn map. A cell is blocked when its centre lies inside the polygon. Its probability mass is moved to nearby unblocked edge-cell candidates.

For each blocked cell, the nearest configured number of candidates receive mass using inverse-distance weights. The altitude band, for example 0-3000 m, is used for U-plan crossing checks. The density-based Dn simulation itself is still horizontal.

RWY5K is a bundled local geometry preset for scenario work; the cited material does not establish it as an authoritative airspace restriction.

Source: Product description for geofences/height restrictions; QRA and AST notes motivate boundary congestion. The exact edge-push algorithm and its parameters are project sensitivity choices.

U-plans

A U-plan is one planned drone route. It does not replace the Dn background simulation; it is evaluated as a separate planned route layer. In the current implementation, one U-plan represents one drone mission.

Generated U-plans sample start and end points from adapted Dn, add 1-3 bend waypoints, vary speed/altitude/departure, and reject active geofence-band crossings when possible. They do not avoid other generated U-plans until rerouting is requested. After creation, select a U-plan card to open its properties and edit its name, speed, altitude and departure. The route is drawn on top of the other routes with a stronger outline and endpoint rings; unselected routes fade. The keyboard-accessible route name button selects the same properties.

The route row reports whether it is manual or Dn-generated, number of legs, first-leg heading, total distance, calculated duration, altitude, speed, and geofence-band crossings. Together with the global U-plan conflict output, this supports strategic route feasibility: can the mission avoid restrictions and remain separated from other planned missions at the same time? It does not contribute to the background level-of-safety KPI.

Reroute uses a strategic grid planner. It keeps the original start/end points, searches for new intermediate waypoints with A*, blocks active geofence bands, and rejects route segments that are too close to other U-plans at the same time. If geometry alone is not enough, it tests small altitude and departure shifts. A start point inside an active geofence band is reported as an error because rerouting cannot both preserve that start and produce a fully valid route. Reroute all processes plans sequentially, so its result is heuristic and can depend on route order.

Pairwise route conflicts use a continuous closest-point-of-approach calculation on every overlapping constant-speed route-leg interval. If the relative velocity is zero, their separation remains constant during that interval. The output counts merged conflict intervals; the same pair may count more than once if it separates and later conflicts again. This checks the time between displayed samples as well, so a fast crossing cannot pass unnoticed between two time steps.

Source: Product description for U-plans, randomized flights, and {course, distance, height} route legs; QRA route-GUI inspiration. CPA and A* routing are project implementation choices.

Inspecting conflicts and planned flight

The conflict list shows the participating plans, interval start/end, interval duration and minimum horizontal/vertical separation. Select a closest approach to move the preview to that instant and highlight the pair on the map. The timeline and play/pause controls follow planned constant-speed positions. Missions appear only during their flight interval, including the exact departure and arrival instants; zero-length missions are not shown as airborne. This is planned-flight playback, not a simulation of an avoidance maneuver.

Large conflict lists are paginated, while every interval remains available in JSON export. A multi-drone route warning requires at least three plans in the same connected conflict group at the same instant. Conflicts between different pairs at different times do not create a shared group. Exact shared boundary instants can produce a zero-duration warning.

Original and current plan

Every plan keeps an immutable original geometry, speed, altitude and departure time. Expand its original/current comparison to inspect distance, efficiency, flight duration, departure/arrival shift and altitude change. Repeated reroutes and route-setting edits keep that original. Both plans are exported. When an older file has no recorded original, the imported current plan becomes the baseline.

Zero-denominator ratios are undefined and exported as null. A shorter current route may have efficiency above 100%. These compare strategic plans; actual flown distance and CA activation duration require a maneuver model.

Blue-disk logic and A/n

A blue disk is a local group of drones connected by pairwise horizontal distance. If drone A is close to B, and B is close to C, all three belong to the same blue disk even if A and C are not directly close.

The current blue disk is a circular implementation envelope centred on the component mean x̄; it is not a minimum enclosing circle. Its boundary touches the outer edge of the furthest red safety circle and contains every other red circle. Extra space at other edges is expected: changing the centre to tighten the circle would change A and possibly the classification. localClearArea is the estimated area inside that envelope that is not inside geofences. The tool estimates this with 72 deterministic area samples. Red safety disks are included in this free area: they represent safety margins, not blocked airspace. A green sample contributes to A even if it lies inside one or more red disks; each sample is counted once. Red sample dots lie inside geofences (shown in grey) and are excluded. The larger dark dots mark drone centres. The canvas boundary is not treated as a wall: a blue disk may extend outside the displayed map without losing area. Only geofences reduce localClearArea.

Grouping is transitive: if A connects to B and B connects to C, all three form one component. This resembles the Java prototype's recursive enclosing-disk idea, but the geometry is not identical. The Java code merges disks recursively; this tool first finds the complete connected component and then uses the mean-centred envelope above. Radii are therefore not simply added as 3r, 5r, and so on.

Source-backed concept: LiU conflict graph/connected components and ATM overlapping safety disks. Mean-centred envelope and 72-point area estimate: project implementation choices.

Two concrete three-drone examples

Both diagrams use the same scale, three drones on a straight line, and no geofences. Each red safety disk has radius r = 50 m, diameter 100 m and area πr² ≈ 7,854 m². Red disks represent safety margins around drone centres, not physical drone bodies. The blue envelope is centred on the middle drone.

Left: neighbouring centres are 25 m apart, so R = 25 + 50 = 75 m. A/3 ≈ 5,890 is below 7,854, giving one NMAC-classified group. Right: neighbouring centres are 100 m apart, so R = 100 + 50 = 150 m. The touching red disks still connect all three drones, but A/3 ≈ 23,562 exceeds 7,854: the group is not NMAC-classified. Overlap alone does not decide the A/n result. Equality at the threshold is also not classified, because the rule uses a strict less-than sign.

With geofences, A is only the free part of the blue disk. The classification counts one group observation, not three collisions. Neither outcome establishes whether a real physical collision occurs.

Binary DAA Rule

The current DAA rule is an explicit research hypothesis and is replaceable. It classifies each blue disk as either NMAC-classified or not classified.

Concrete example without geofences, with r = 50 m and two drones separated by distance d. Their mean-centred blue-disk radius is R_blue = r + d/2. At d = 20 m, R_blue = 60 m and A/n = π · 60²/2 ≈ 5,655 m², which is below the 7,854 m² threshold: NMAC = 1. At d = 100 m, the drones are still connected exactly at 2r, but R_blue = 100 m and A/n = π · 100²/2 ≈ 15,708 m²: NMAC = 0. A geofence cutting either disk reduces A and can move the same geometry toward NMAC = 1.

The πr² boundary is not a validated DAA law. It operationalizes the project idea of mapping r and local A/n to a binary result so that the prototype can be tested. It does not model real sensor range, field of view, latency, nuisance alerts, or avoidance manoeuvres.

Source: Product description for black-box DAA and parameterized capability. Exact πr² threshold: project research hypothesis, not paper-derived.

Output and Safety KPIs

Confidence diagnostics in saved runs and exports

Positive-event intervals use between-day variation with a Poisson variance floor. With zero observed classifications, the one-sided 95% Poisson upper bound is −ln(0.05) divided by simulated flight hours. These are uncertainty diagnostics for the simulator, not certification evidence.

At a classification-rate target of 1e-7, a zero-event run needs at least −ln(0.05)/1e-7 ≈ 29.96 million simulated flight hours before its exported confidence assessment can be pass. The default scenario provides 80 · 750 = 60,000 flight hours, so zero classifications would still produce insufficient confidence evidence. The Results card would show 0 < 1.00e-7 in green because it compares the point estimate only. A high observed rate can produce fail in the exported confidence assessment.

Source: Product description for ALS/TLS. Confidence handling uses standard Monte Carlo sampling uncertainty and the exact zero-count Poisson upper bound.

Charts

The A/n decision map shows the research hypothesis A/n < πr². Its radius axis covers the configurable 10–500 m range. The former 3D surface encoded exactly the same classification as height 0 or 1, adding no extra physical dimension or numerical evidence, so Results now contains only the 2D map.

Source: Visual design inspired by the supplied sharp 0/1 boundary reference; calculation is the project research hypothesis.

Map presets

Add RWY5K preset adds the bundled restriction. Add crossing U-plans adds two perpendicular, equally long routes to the current scenario, using the new-route speed, altitude and departure. They meet at the same altitude and time. Select a route to inspect its properties, then try Reroute all and compare planned conflicts. Existing traffic settings, restrictions and routes are preserved; adding U-plans does not alter the background simulation results.

The crossing preset is available again after its two routes have been removed. Sample JSON files remain in examples/ for CLI runs, import and regression checks.

Import and Export

Export JSON stores the scenario inputs, DAA radii, geofence geometry and settings, U-plan geometry and settings, satellite and Dn-overlay choices, and calculated outputs. Import JSON validates the stored inputs, restores them, and recalculates outputs against the local Dn dataset and current tool version. Stored result values are not trusted as current results. The current format is schema version 1 and references, rather than embeds, the local GeoJSON dataset.

The existing JSON field names, including tlsRatePerFlightHour and evidenceStatus values pass/fail/insufficient, are retained for compatibility. evidenceStatus remains a confidence-based assessment of the A/n metric; Results displays a separate, direct comparison of the point estimate with the configured target.

Completed exports additionally record the effective random seed, shared engine version, map bounds, multi-drone statistics, U-plan original plans and strategic efficiency. The dataset content is identified by SHA-256 when the browser supports secure hashing (HTTPS or localhost); otherwise the hash remains missing. A saved seed preserves the exact sampling sequence for the same inputs and dataset. Import warns when recorded data, map bounds, traffic field or engine differ from the interactive tool.

An incomplete background run is marked insufficient. Its inputs can be exported for correction, but it cannot be added to saved-result comparisons as evidence of zero observed events.

Implementation feature for reproducible scenarios; not a mathematical model assumption.

U-plan results

Results separates the background snapshot simulation from planned-route checks. The U-plan panel uses the existing continuous pair-conflict calculation, with 2r horizontal separation and the U-plan vertical separation setting. It updates when routes, timing, altitude, separation settings or geofences change.

Pair conflict intervals counts each continuous conflict between two routes once. The per-route table counts intervals involving that route, so each interval appears in two routes' counts. Routes crossing geofences counts affected routes; the intersection total counts each route–geofence pair once within the geofence's altitude band, even if that route crosses the same polygon repeatedly.

Planned distance sums the current route lengths and compares their total with the original plans. Changed from original includes geometry, speed, altitude and departure edits as well as rerouting. Arrival shift includes both departure and flight-duration changes. These are strategic plan differences, not measurements of executed avoidance maneuvers.

Closest flagged approach is the smallest horizontal separation among detected pair conflicts; its displayed vertical separation and time belong to that same encounter. It is not the minimum separation across all non-conflicting flights. Inspect on map opens the existing conflict preview. Route names open their properties in Scenario. The table shows six routes per page while the totals include every route. With no U-plans, the panel offers a link to add routes rather than displaying a completed result.

Comparing saved runs

Set the DAA radius directly in Scenario. Compare runs collects completed outputs for every recorded model: Add current run captures the current result; Import JSON files accepts multiple exported files in one selection and CLI batch files. Reading comparison files preserves the active scenario.

The matrix places model/radius settings on rows and runs on columns. Select a metric: NMAC per flight hour, NMAC per day, groups with 3+ drones per day, or largest group. Filter by model when comparing many settings. The reference run appears first. Input summaries above each column show daily traffic, flight duration, geofences and U-plans; U-plans remain separate from the background metric.

Cell bars use a shared linear scale from zero across the displayed, comparable values. Δ is the percentage change from the reference at the same radius; its tooltip gives the absolute change. With a zero reference, Δ shows the absolute change because a percentage is undefined. A changed radius gets a separate row. Missing settings and values show a dash, with an explanation. The optional 95% interval applies to the per-flight-hour rate only.

Expand Runs & scenario settings to rename or remove runs, inspect provenance and changed inputs, or use Open in Scenario. Opening validates and restores the saved inputs, geofence rings and altitude/adaptation properties, U-plan waypoints, speed, altitude, departure, and original plans. Results are recalculated with the current local engine and Dn dataset; the captured comparison values remain fixed. Files without complete geometry lists cannot be opened through this action. CLI runs beyond the interactive tool's input limits can still be compared, but must be adjusted separately before opening.

Export all saves the comparison as a reusable JSON batch, including full scenario geometry and original plans. The reference is written first so it becomes the initial reference when imported into an empty comparison. The comparison otherwise lasts until page reload. Limits are 30 runs and 10 MB per file; a combined export above 10 MB is rejected with a message to export fewer runs.

Differences are descriptive comparisons, not significance tests. Different snapshot lengths, engines, dataset hashes/fields/bounds, recorded assumptions or radii prevent numerical deltas and comparison bars for the affected cells; expand Not comparable for the reason. Older exports remain readable, with unrecorded metadata shown as Not recorded. Files containing only scenario inputs need to be simulated and exported first. An invalid file or batch entry does not discard other valid uploaded runs.

Command-line and larger runs

The browser and Node.js command line use simulation-core.js for the same background calculations. Node.js 18 or newer is required, with no external dependencies. Run this command from the project directory:

npm run simulate -- --scenario examples/01-baseline.json --seed workshop --output result.json

For a batch, repeat --scenario or provide --batch with a JSON array of scenario filenames. --days supports exposure beyond the interactive limit. --data changes the GeoJSON input and --window-minutes changes the independent snapshot interval (it must divide a day exactly). --progress prints progress separately from JSON output. Use node scripts/simulate.cjs --help for details.

At 3,000 flights/day and 15 minutes/flight, --days 13334 represents 10,000,500 operational flight hours. Such a run has been completed with the real Dn data at five-minute intervals during development. Increasing exposure tests execution and reduces sampling uncertainty within this model; it does not validate physical collision risk.

Load CLI outputs in Compare simulation runs. Interactive scenario import retains its 300-day, five-minute-window limits and fixed map/presets. The CLI runs background snapshots only; it preserves U-plan inputs while explicitly marking route evaluation as unavailable. See README for commands, verification and web-host upload instructions, and implementation status for requirement coverage.

Known Limits

• The Dn simulation is horizontal; altitude is currently used for U-plans and geofence-band checks only.
• Independent snapshots do not represent persistent drone identities or unique encounters across time.
• U-plans are evaluated separately from the main level-of-safety KPI.
• Strategic U-plan rerouting is implemented, but dynamic collision-avoidance manoeuvres and return-to-normal are not.
• The edge-push model, blue-disk envelope, local area sampling, and πr² rule are research approximations rather than validated DAA behaviour.
• No real SAAB DAA implementation is modeled yet.
• The 95% intervals quantify Monte Carlo uncertainty only; they do not account for model-form uncertainty or validate the A/n hypothesis.