Air Traffic unification Part 3

[RomanPszonka]

This pull request unifies and simplifies the configuration and usage of simulated air traffic data providers across the codebase and documentation. The main theme is to replace provider-specific steps and configuration sections with a single, consistent "Stream Air Traffic" interface, making it easier to author scenarios and maintain the code. In addition, the codebase is refactored to use a single internal step decorator for air traffic simulation steps, and configuration models are streamlined.

Unified configuration and scenario authoring:

• Consolidated provider-specific simulator settings (blue_sky_air_traffic_simulator_settings, bayesian_air_traffic_simulator_settings) into a single air_traffic_simulator_settings block in both config/default.yaml and config/pull_request.yaml, reducing duplication and simplifying overrides. [1] [2]
• Updated scenario authoring documentation and example scenarios to use the unified Stream Air Traffic step with a provider argument, replacing previous multi-step and provider-specific approaches. This change is reflected throughout docs/daa_scenario_authoring_guide.md, scenario markdowns, and the scenario example YAML. [1] [2] [3] [4] [5] [6] [7] [8] [9]

Codebase refactoring and simplification:

• Replaced the use of the @scenario_step decorator with @internal_step for internal air traffic simulation methods, clarifying their intended usage and reducing confusion in air_traffic_client.py and bayesian_air_traffic_client.py. [1] [2] [3] [4] [5] [6] [7]
• Simplified type imports and configuration models in base_client.py by unifying simulator config types under a single SimConfig alias, and updated all relevant class methods to use this unified type. [1] [2] [3] [4]

These changes collectively make scenario authoring more consistent and reduce code and config duplication, while clarifying the distinction between internal steps and user-facing scenario steps.

[Copilot]

Pull request overview

This PR continues the “Air Traffic” unification by removing provider-specific simulator config sections and UI panels, consolidating defaults into a single air_traffic_simulator_settings, and introducing an internal_step decorator to keep provider-internal helper steps out of the YAML-callable step registry.

Changes:

• Web editor: removes BlueSky/Bayesian simulator config panels and makes air_traffic_simulator_settings optional in scenario config types.
• Backend: removes BlueSkyAirTrafficSimulatorSettings / BayesianAirTrafficSimulatorSettings config models and updates air-traffic default resolution to use the unified settings section.
• Steps/docs: marks legacy provider-specific generator steps as internal_step and updates scenario/docs examples to use “Stream Air Traffic”.

Reviewed changes

Copilot reviewed 26 out of 26 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
web-editor/src/types/scenario.ts	Removes provider-specific simulator settings types; makes air_traffic_simulator_settings optional.
web-editor/src/hooks/tests/useScenarioRunner.test.ts	Updates test fixtures to drop BlueSky config from web-editor scenario config.
web-editor/src/hooks/tests/useScenarioFile.test.ts	Updates test fixtures to drop BlueSky config from web-editor scenario config.
web-editor/src/components/ScenarioEditor/ConfigEditor.tsx	Removes BlueSky/Bayesian config sections; consolidates updates into unified air-traffic settings UI.
web-editor/src/components/ScenarioEditor.tsx	Updates default editor config to match unified air-traffic settings.
web-editor/README_GROUPS.md	Updates groups documentation examples toward “Stream Air Traffic”.
web-editor/async_implementation_guide.md	Updates async scenario authoring example to “Stream Air Traffic”.
tests/test_suite_scenario_merge.py	Removes assertions for deleted provider-specific config sections.
tests/test_reporting_output.py	Removes deleted provider-specific config model usage in report tests.
tests/test_client_settings.py	Updates settings mapping tests to use unified AirTrafficSimulatorSettings.
src/openutm_verification/core/steps/air_traffic_step.py	Reads unified simulator defaults and resolves config_path from data_files based on provider.
src/openutm_verification/core/execution/scenario_runner.py	Adds internal_step decorator and optional registry registration in ScenarioStepDescriptor.
src/openutm_verification/core/execution/config_models.py	Deletes provider-specific simulator config models; makes unified simulator settings optional in AppConfig.
src/openutm_verification/core/clients/opensky/opensky_client.py	Converts “Fetch OpenSky Data” to @internal_step.
src/openutm_verification/core/clients/air_traffic/blue_sky_client.py	Converts BlueSky generator steps to @internal_step.
src/openutm_verification/core/clients/air_traffic/bayesian_air_traffic_client.py	Converts Bayesian generator/session steps to @internal_step.
src/openutm_verification/core/clients/air_traffic/base_client.py	Unifies settings from_config typing to the single simulator settings model.
src/openutm_verification/core/clients/air_traffic/air_traffic_client.py	Converts GeoJSON generator/session steps to @internal_step.
scenarios/README.md	Updates scenarios documentation to use “Stream Air Traffic”.
scenarios/airtraffic-simulations/stream_air_traffic_example.yaml	Removes the unified example scenario file.
docs/scenarios/sdsp-f3623/verify_sdsp_metrics.md	Updates execution flow to “Stream Air Traffic”.
docs/scenarios/sdsp-f3623/sdsp_track.md	Updates to “Stream Air Traffic” background step description.
docs/scenarios/airtraffic-simulations/openutm_sim_air_traffic_data.md	Updates to “Stream Air Traffic” semantics for simulated traffic.
docs/daa_scenario_authoring_guide.md	Updates DAA authoring examples to use “Stream Air Traffic”.
config/pull_request.yaml	Removes provider-specific simulator config sections; keeps unified simulator defaults.
config/default.yaml	Removes provider-specific simulator config sections; keeps unified simulator defaults.

Comments suppressed due to low confidence (1)

web-editor/src/components/ScenarioEditor/ConfigEditor.tsx:90

• updateAirTrafficSettings can create a partial air_traffic_simulator_settings object when the existing config is undefined (e.g., only sensor_ids gets set). The backend AirTrafficSimulatorSettings model requires number_of_aircraft and simulation_duration, so sending a partial object can trigger 422 validation errors. Consider initializing missing required fields here (or omitting air_traffic_simulator_settings entirely until it’s complete).

    const updateAirTrafficSettings = (field: string, value: string | number | string[]) => {
        onUpdateConfig({
            ...config,
            air_traffic_simulator_settings: {
                ...(config.air_traffic_simulator_settings || {}),
                [field]: value
            }
        });
    };

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The UI default for simulation_duration is now 30 when unset, but the editor’s getDefaultConfig() (and config/default.yaml) use 10. This inconsistency can lead to confusing behavior depending on whether the value was explicitly set. Consider aligning the fallback default here with the app’s default config value.

[Copilot]

This test config uses air_traffic_simulator_settings: {}. In the backend, AirTrafficSimulatorSettings requires number_of_aircraft and simulation_duration, so a real /session/reset call with this payload would fail validation. Prefer omitting air_traffic_simulator_settings entirely when not needed, or include the required fields in the test fixture.

Suggested change

	air_traffic_simulator_settings: {}
	air_traffic_simulator_settings: {
	number_of_aircraft: 1,
	simulation_duration: 60
	}

[Copilot]

This test config uses air_traffic_simulator_settings: {}. The backend AirTrafficSimulatorSettings requires number_of_aircraft and simulation_duration, so this payload would be invalid if exercised against the real API. Consider either omitting the field or populating the required values in the fixture to reflect actual runtime behavior.

Suggested change

	air_traffic_simulator_settings: {}
	air_traffic_simulator_settings: {
	number_of_aircraft: 1,
	simulation_duration: 60
	}

[Copilot]

The example workflow still refers to a “submit” step/result (Set submit's observations…, later ${{ group.submit.result }}), but the updated group example only defines a single stream step. Update the text (and any subsequent references) so the step IDs/results referenced actually exist in the shown group definition.

[Copilot]

The execution-flow list numbering is now inconsistent (1, 4, 5, 5) after consolidating steps into “Stream Air Traffic”. Renumber these items so the list is sequential and doesn’t repeat step numbers.

Suggested change

	4. **Start SDSP Session** - Initiate and terminate SDSP sessions to simulate real-world usage patterns, allowing for the measurement of session-related metrics such as active session count and data volume.
	5. **Verify Reported Metrics in Flight Blender** - Check the Flight Blender dashboard and logs to confirm that the metrics for active SDSP sessions, data volume, and update frequency are accurately reported based on the actions performed in the previous steps.
	5. **Stop SDSP Session** - Terminate the SDSP sessions to ensure that the system correctly updates the metrics to reflect the cessation of data streams and session activity.
	2. **Start SDSP Session** - Initiate and terminate SDSP sessions to simulate real-world usage patterns, allowing for the measurement of session-related metrics such as active session count and data volume.
	3. **Verify Reported Metrics in Flight Blender** - Check the Flight Blender dashboard and logs to confirm that the metrics for active SDSP sessions, data volume, and update frequency are accurately reported based on the actions performed in the previous steps.
	4. **Stop SDSP Session** - Terminate the SDSP sessions to ensure that the system correctly updates the metrics to reflect the cessation of data streams and session activity.

[Copilot]

The internal_step docstring says the step “won't appear in the UI”, but it’s ambiguous which UI this refers to (operations list vs execution results/reports). Since internal steps still emit StepResults and get streamed on /run-scenario-events (often with id=None), consider clarifying that this means “not registered / not callable from YAML and not listed as an available operation”.

Suggested change

	handling — it just won't appear in the UI or be callable from YAML scenarios.
	handling, but it is not registered as an available operation, will not
	be callable from YAML scenarios, and will not be listed wherever
	STEP_REGISTRY-backed operations are shown.

[atti92]

Looks good, can you resolve the Copilot comments? If what it says is true there are some bugs it caught.

[hrishiballal]

I think this looks OK as well, just the Copilot comments please