# Daily traffic and whole-study results 24 September 2026. Compiler `geographic-3.0.0`; engine `traffic-reference-0.6.0`. Current: compiler `geographic-3.1.0` (delivery projects without an explicit altitude use the documented 80/120 m layers) and engine `traffic-reference-0.7.0` (see TRAFFIC_MODEL.md). ## Scenario → Simulation → Results The red/blue toggle beside NoMAC selects the simulation model. Scenario contains Run length: an actual-aircraft-flight-hour target (default 1,000) or a number of independent days (preset 30). Capacity experiments are an optional expanded section. Sample mode retains its independent spatial snapshots. New trajectory scenarios combine terminal deliveries, optional background transit and scheduled U-plans in one continuous 3D world. The same engine executes a single day, independent batches and capacity levels. Rendering is not a second simulation model. Each terminal has its own expected deliveries/day, operating window, service radius, aircraft profile and DAA profile. Its name can identify an operator/depot. Several terminals can share profiles, but their daily demand is specified separately. Delivery includes outbound travel, off-grid descent, service hover and return. B weights destinations within the service area; it does not determine the number of requests. There is no finite fleet, vehicle reuse, charging or ground turnaround model. Background traffic is optional. It has a separate expected missions/day and operating window, plus independently selected aircraft and DAA profiles. Each synthetic trip chooses an entry side uniformly and a uniformly chosen node on that side and the opposite side. It uses the route planner and reservations, and can encounter delivery traffic and U-plans. This is a controlled corridor-traffic assumption, not an observed Norrköping OD distribution or free random motion. The finite airborne trip starts/ends at a grid-edge node at cruise altitude, with the reference start/stop kinematics; external incoming traffic is not modeled. Both delivery and background flights pass straight grid junctions without artificial braking. Turns retain the reference acceleration and yaw limits. Route-grid spacing remains 250/500/1000 m. Daily scenarios specify corridor width independently (120 m is the example default): changing an aircraft radius does not silently resize the route network. Protective volumes, body contact and NMAC thresholds remain separate definitions. ## Demand mathematics For source s, expected daily mission count N_s and operating window [a_s,b_s) in seconds: `lambda_s = N_s / (b_s - a_s)` requests/second inside the window, zero otherwise. Independent exponential interarrival times generate a Poisson count with mean and variance N_s. An entered value of 120 is an expected daily count, not exactly 120 scheduled deliveries. Each source has separate seeded arrival and destination streams. Adding background traffic or another terminal leaves the original terminal's requests unchanged for the same seed; their outcomes may change because they now share airspace. The compiler represents the baseline whole-day rate as `sum(N_s)/24`. For capacity levels, the engine scales every generated source by the same factor `tested_daily_total/sum(N_s)`. Operating windows, profile assignments and destination distributions stay fixed. Explicit U-plans are added once per replicate and are not multiplied by the sweep. A zero source mix cannot be scaled to positive demand. Requests beyond the explicit 2,000-flight per-replicate bound abort that replicate rather than being dropped from the denominator. To avoid aborting a batch partway, demand whose expected count plus five standard deviations exceeds the bound is rejected when the scenario is compiled, and capacity studies check their highest level before running. Each source currently has one operating window within 00:00–24:00. Different sources can overlap. Overnight/multiple-window schedules are not inferred. Default quantities, windows, profiles, grid dimensions and thresholds are experiment assumptions; they are not measured or approved operational values. ## Profiles and DAA The common reference aircraft/DAA settings provide the initial profiles. Additional aircraft profiles specify speeds, horizontal and vertical acceleration, climb, yaw, physical size and protection; additional DAA profiles specify sensing, latency, lookahead, clearance, observation errors and geofence policy. Terminals and background traffic choose them independently. All DAA profiles currently parameterize the same pairwise vertical reference controller. This implements distinct per-aircraft configurations, **not** independent supplier algorithms or proven interoperability. Disabled DAA means that aircraft does not issue avoidance commands; its continuous path and cooperative intent still exist. Non-cooperative intruders remain the separate input supported by the engine. A profile that does not fit a corridor is rejected by planning; corridor widths are not silently widened. Layer spacing must exceed every configured aircraft's nominal protection height. The reference DAA switch affects the reference profile in daily scenarios; other profiles retain their own enable state. Legacy short scenarios retain their earlier global/reference behavior. Global traffic management and optional disturbances remain explicit scenario settings. Unsupported multi-aircraft coordination is still a coverage failure. ## Full execution and one-hour replay A replicate starts empty at 00:00, admits generated requests during a 24-hour day, and includes the configured finish period. A batch repeats independent days; it is not a continuous multi-day history or a steady-state estimate. Flights that cannot complete in the horizon remain rejected/unfinished as appropriate; actual airborne exposure is counted even when service or return is incomplete. Results lists NMAC interval starts, DAA activations, aircraft/obstacle contacts and contingencies with day, time and aircraft IDs. Inspect opens the corresponding hour, pauses at the event and selects an involved aircraft. The 3D replay shows at most one hour of a complete executed replicate. Flights already airborne at the start of that hour are retained. Manual day/hour inspection remains available. Inspecting another hour or replicate does not replace aggregate results or the exported study. Replaying a retained seed runs the same engine from the beginning of that day; it does not initialize an empty world at the replay hour. The renderer reads exact recorded trajectory segments. Only one day's paths are loaded for inspection. Batches and capacity experiments retain aggregates, reproducible seeds and the first 400 bookmarks per event type (at most 2,000 overall), in execution order. The event list filters and paginates these bookmarks, shows retained versus total counts when truncated, and travels with JSON/checkpoints. Event retention never affects KPI counts. Earlier checkpoints without an index can resume; the UI reports how many days have event coverage. Capacity bookmarks also retain the demand level because exploration seeds are reused across levels. Single-run exports retain the full event stream. Detailed sensor logs are bounded; truncation is reported and never changes physics or KPI counts. Progress for a flight-hour goal uses completed-day exposure divided by the requested target. It reaches the target after a whole day, so exposure may exceed the requested minimum. A second bar reports the current planning/simulated-time stage. A day-count goal uses completed days; capacity experiments report progress within the current demand level. Sample-based calculations run in a worker, report completed days, and cancel superseded requests. Physical/sensor defaults are unchanged by the longer run-length default. ## KPI accounting - **Flight hours H:** sum of actual airborne seconds for all modeled aircraft divided by 3,600, including delivery hover and non-cooperative intruders when configured. - **Simulated clock time:** sum of the complete replicate horizons, including finish periods. It is different from H. - **Mean airborne:** total aircraft-seconds divided by total simulated clock seconds. Night/empty time and the finish period are included. - **Peak airborne:** largest simultaneous airborne count across all completed replicates, computed from exact departure/end times, not display samples. A simultaneous arrival and departure do not overlap. - **Completed/offered, rejection and delay:** aggregate all requested missions, including explicit U-plans. A delivery is one round trip, not two independent missions. Delivered parcels and delivered-and-returned missions are reported separately per terminal. - **Source table:** request counts and exposure attributed to each terminal, background traffic and U-plans. Prescribed non-cooperative intruders are included in overall safety exposure, but are not offered demand in this table. - **NMAC/flight hour:** continuous pairwise NMAC intervals divided by H. This is not A/n sample classification. Physical contact rate remains separate. Operational acceptance, unsupported-model behavior and statistical evidence are separate. Zero contacts do not alone establish TLS: the conditional Poisson zero-event upper bound is `-ln(0.05)/H`. No software test validates the traffic assumptions or the real-world safety of a supplier DAA implementation. ## Requirements and verification This stage connects REQ-2.3 (aircraft profiles), REQ-2.7 (assigned CA configurations), REQ-2.4 (explicit U-plans in shared traffic), REQ-4.1 (nonvisual batches) and REQ-4.4 (exposure-based safety outputs). It does not complete terrain, fixed-wing dynamics, independent supplier algorithms, empirical traffic calibration, category-specific TLS, RTTA or the ten-million-flight-hour acceptance run. `tests/daily-traffic.test.cjs` checks source means/windows, independent random streams, mixed profiles, disabled DAA, straight-link motion, exact exposure/concurrency, checkpoints and pre-noon flights. Existing CLI tests check ordered parallel aggregation and resume. `tests/daily_browser.py` checks scenario editing, profile/terminal import, aggregate results, hour/replicate inspection and mobile layouts through the actual worker and browser. Existing delivery, sample and 3D interaction regressions remain applicable. Old declarative scenarios remain importable without silently converting short demand periods to days. Old trajectory results/checkpoints from earlier engine versions require rerunning their scenarios. Study-size settings, traffic source definitions, profile catalogs, raw B weights, terminal/U-plan/geofence coordinates and seeds travel with project JSON. See [INTEGRATED_MODEL.md](INTEGRATED_MODEL.md) for CLI checkpoint/resume commands. Large targets are supported as stopping conditions; their runtime feasibility still needs benchmarked scaling work.