Air Traffic unification Part 3

config/default.yaml

@@ -24,29 +24,13 @@ opensky:
     client_id: "your-client-id"
     client_secret: "your-client-secret"
 
-# Air traffic data configuration
+# Default air traffic simulator settings (can be overridden per step in scenario YAML)
 air_traffic_simulator_settings:
   number_of_aircraft: 3
   simulation_duration: 10
   single_or_multiple_sensors: "single" # this setting specifies if the traffic data is submitted from a single sensor or multiple sensors
   sensor_ids: ["a0b7d47e5eac45dc8cbaf47e6fe0e558"] # List of sensor IDs to use when 'multiple' is selected
-  session_ids: ["ee9405e564ea4373823e37d950858e6a"] # List of session IDs to use when 'multiple' is selected, a session id is needed in Flight Blender to depict a period of time these observations were made (this assumes the observations may not be continuous); if empty, random UUIDs will be generated
-
-# Bluesky Air traffic data configuration
-blue_sky_air_traffic_simulator_settings:
-  number_of_aircraft: 3
-  simulation_duration: 30
-  single_or_multiple_sensors: "single" # this setting specifies if the traffic data is submitted from a single sensor or multiple sensors
-  sensor_ids: ["562e6297036a4adebb4848afcd1ede90"] # List of sensor IDs to use when 'multiple' is selected
-  session_ids: ["ee9405e564ea4373823e37d950858e6a"] # List of session IDs to use when 'multiple' is selected, a session id is needed in Flight Blender to depict a period of time these observations were made (this assumes the observations may not be continuous); if empty, random UUIDs will be generated
-
-# Bayesian Air traffic data configuration
-bayesian_air_traffic_simulator_settings:
-  number_of_aircraft: 3
-  simulation_duration: 30
-  single_or_multiple_sensors: "single" # this setting specifies if the traffic data is submitted from a single sensor or multiple sensors
-  sensor_ids: ["562e6297036a4adebb4848afcd1ede90"] # List of sensor IDs to use when 'multiple' is selected
-  session_ids: ["ee9405e564ea4373823e37d950858e6a"] # List of session IDs to use when 'multiple' is selected, a session id is needed in Flight Blender to depict a period of time these observations were made (this assumes the observations may not be continuous); if empty, random UUIDs will be generated
+  session_ids: ["ee9405e564ea4373823e37d950858e6a"] # List of session IDs to use when 'multiple' is selected
 
 # AMQP/RabbitMQ configuration for event monitoring
 # Set AMQP_URL environment variable or configure here
@@ -84,7 +68,6 @@ suites:
   air_traffic_simulations:
     scenarios:
       - name: openutm_sim_air_traffic_data
-      - name: stream_air_traffic_example
       - name: opensky_live_data
       - name: bayesian_sim_air_traffic_data
       - name: bluesky_sim_air_traffic_data

config/pull_request.yaml

@@ -18,27 +18,12 @@ opensky:
     client_id: "your-client-id"
     client_secret: "your-client-secret"
 
-# Air traffic data configuration
+# Default air traffic simulator settings (can be overridden per step in scenario YAML)
 air_traffic_simulator_settings:
   number_of_aircraft: 3
   simulation_duration: 10
-  single_or_multiple_sensors: "multiple" # this setting specifiies if the traffic data is submitted from a single sensor or multiple sensors
-  sensor_ids: ["a0b7d47e5eac45dc8cbaf47e6fe0e558"] # List of sensor IDs to use when 'multiple' is selected
-
-# Bluesky Air traffic data configuration
-blue_sky_air_traffic_simulator_settings:
-  number_of_aircraft: 3
-  simulation_duration: 30
-  single_or_multiple_sensors: "multiple" # this setting specifiies if the traffic data is submitted from a single sensor or multiple sensors
-  sensor_ids: ["562e6297036a4adebb4848afcd1ede90"] # List of sensor IDs to use when 'multiple' is selected
-
-# Bayesian Air traffic data configuration
-bayesian_air_traffic_simulator_settings:
-  number_of_aircraft: 3
-  simulation_duration: 30
   single_or_multiple_sensors: "multiple" # this setting specifies if the traffic data is submitted from a single sensor or multiple sensors
-  sensor_ids: ["562e6297036a4adebb4848afcd1ede90"] # List of sensor IDs to use when 'multiple' is selected
-  session_ids: ["ee9405e564ea4373823e37d950858e6a"] # List of session IDs to use when 'multiple' is selected, a session id is needed in Flight Blender to depict a period of time these observations were made (this assumes the observations may not be continuous); if empty, random UUIDs will be generated
+  sensor_ids: ["a0b7d47e5eac45dc8cbaf47e6fe0e558"] # List of sensor IDs to use when 'multiple' is selected
 
 data_files:
   trajectory: "config/bern/trajectory_f1.json" # Path to flight declarations JSON file

docs/daa_scenario_authoring_guide.md

@@ -165,13 +165,12 @@ steps:
     arguments:
       state: ACTIVATED
   - id: generate_traffic
-    step: Generate BlueSky Simulation Air Traffic Data
+    step: Stream Air Traffic
     arguments:
+      provider: bluesky
       config_path: config/edmonton/bluesky_<tag>.scn
       duration: 130                     # > encounter window
-  - step: Submit Simulated Air Traffic
-    arguments:
-      observations: ${{ steps.generate_traffic.result }}
+      target: flight_blender
     background: true
   - step: Wait X seconds
     arguments:
@@ -186,7 +185,7 @@ steps:
       state: ENDED
     needs:
       - Submit Telemetry
-      - Submit Simulated Air Traffic
+      - generate_traffic
   - step: Stop AMQP Queue Monitor
     needs:
       - update_state_ended
@@ -256,13 +255,12 @@ steps:
 
   # Intruder traffic
   - id: generate_traffic
-    step: Generate BlueSky Simulation Air Traffic Data
+    step: Stream Air Traffic
     arguments:
+      provider: bluesky
       config_path: config/edmonton/bluesky_<tag>.scn
       duration: 210
-  - step: Submit Simulated Air Traffic
-    arguments:
-      observations: ${{ steps.generate_traffic.result }}
+      target: flight_blender
     background: true
   - step: Wait X seconds
     arguments:
@@ -302,13 +300,13 @@ steps:
     arguments:
       declaration_id: ${{ steps.setup_declarations.result.declarations[0].id }}
       state: ENDED
-    needs: [submit_alpha_telemetry, submit_bravo_telemetry, Submit Simulated Air Traffic]
+    needs: [submit_alpha_telemetry, submit_bravo_telemetry, generate_traffic]
   - id: end_bravo
     step: Update Operation State of declaration
     arguments:
       declaration_id: ${{ steps.setup_declarations.result.declarations[1].id }}
       state: ENDED
-    needs: [submit_alpha_telemetry, submit_bravo_telemetry, Submit Simulated Air Traffic]
+    needs: [submit_alpha_telemetry, submit_bravo_telemetry, generate_traffic]
 
   - step: Stop AMQP Queue Monitor
     needs: [end_alpha, end_bravo]

docs/scenarios/airtraffic-simulations/openutm_sim_air_traffic_data.md

@@ -9,15 +9,12 @@
 
 The scenario executes the following sequence of steps:
 
-### 1. Generate Simulated Air Traffic
-- **Step:** `AirTrafficClient.generate_simulated_air_traffic_data`
-- **Action:** Generates a set of simulated flight observations (e.g., positions, velocities) representing local air traffic.
-- **Context:** Unlike live tracking, this uses internal simulation logic/templates to create predictable traffic patterns for testing.
+### 1. Stream Air Traffic
+- **Step:** `Stream Air Traffic`
+- **Arguments:** `provider: geojson`, `target: flight_blender`
+- **Action:** Generates simulated flight observations using the GeoJSON provider and submits them to Flight Blender's air traffic data feed.
+- **Context:** Uses internal simulation logic/templates to create predictable traffic patterns for testing.
+- **Verification:** Ensures observations are generated and the API accepts the payload.
 
-### 2. Submit Traffic Data
-- **Step:** `FlightBlenderClient.submit_simulated_air_traffic`
-- **Action:** Submits the generated observations to Flight Blender's air traffic data feed.
-- **Verification:** Ensures the API accepts the payload (typically a bulk submission of observations).
-
-### 3. Completion
+### 2. Completion
 - **Action:** The scenario completes successfully upon meaningful submission callback.

docs/scenarios/sdsp-f3623/sdsp_track.md

@@ -14,11 +14,10 @@ The scenario executes the following sequence of steps:
 - **Action:** Initiates a new SDSP session with a unique UUID.
 - **Context:** Signals the beginning of a data provision session.
 
-### 2. Generate and Submit Air Traffic
-- **Step:** `Generate Simulated Air Traffic Data`
-- **Action:** Generates simulated flight observations.
-- **Step:** `Submit Simulated Air Traffic` (Background Task)
-- **Action:** Starts submitting the generated observations to Flight Blender in a background process.
+### 2. Stream Air Traffic
+- **Step:** `Stream Air Traffic` (Background Task)
+- **Arguments:** `provider: geojson`, `target: flight_blender`
+- **Action:** Generates simulated flight observations and submits them to Flight Blender in a background process.
 - **Context:** Simulates a live feed of aircraft tracking data being pushed to the system.
 
 ### 3. Initial Wait

docs/scenarios/sdsp-f3623/verify_sdsp_metrics.md

@@ -8,12 +8,10 @@
 
 ## Execution Flow
 The scenario executes the following sequence of steps:
-1. **Generate Bayesian Simulation Air Traffic Data** - Create synthetic air traffic data streams that mimic real-world SDSP inputs, including various flight parameters and metadata.
-2. **Fetch Session IDs for Bayesian Simulation** - Retrieve the session identifiers for the generated air traffic data to track and correlate metrics accurately throughout the test.
-3. **Submit Simulated Air Traffic** - Ingest the generated air traffic data into Flight Blender, ensuring that the system processes the data as it would in a live environment.
-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.
+1. **Stream Air Traffic** (`provider: bayesian`, `target: flight_blender`) - Generate synthetic air traffic data using the Bayesian provider and submit to Flight Blender, mimicking real-world SDSP inputs including various flight parameters and metadata.
+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.
 
 
 ## Expected Outcomes

scenarios/README.md

@@ -53,31 +53,14 @@ Use the optional `groups` section to define named step collections:
 
 ```yaml
 name: opensky_live_data
-description: Fetch live flight data and submit to Flight Blender.
-
-groups:
-  fetch_and_submit_opensky:
-    description: Fetches OpenSky data and submits it to Flight Blender
-    steps:
-      - id: fetch
-        step: Fetch OpenSky Data
-
-      - id: submit
-        step: Submit Air Traffic
-        arguments:
-          observations: ${{ group.fetch.result }}
-
-      - id: wait
-        step: Wait X seconds
-        arguments:
-          duration: 3
+description: Fetch live flight data from OpenSky and submit to Flight Blender.
 
 steps:
-  # Execute the group once
-  - step: fetch_and_submit_opensky
-
-  # Execute the group in a loop
-  - step: fetch_and_submit_opensky
+  - step: Stream Air Traffic
+    id: stream_opensky
+    arguments:
+      provider: opensky
+      target: flight_blender
     loop:
       count: 5
 ```

scenarios/airtraffic-simulations/opensky_live_data.yaml

@@ -7,5 +7,6 @@ steps:
     arguments:
       provider: opensky
       target: flight_blender
+      duration: 10
     loop:
-      count: 5
+      count: 2

src/openutm_verification/core/clients/air_traffic/air_traffic_client.py

@@ -13,7 +13,7 @@
 from openutm_verification.core.clients.flight_blender.base_client import (
     BaseBlenderAPIClient,
 )
-from openutm_verification.core.execution.scenario_runner import scenario_step
+from openutm_verification.core.execution.scenario_runner import internal_step
 from openutm_verification.core.flight_phase import FlightPhase
 from openutm_verification.simulator.geo_json_telemetry import (
     GeoJSONAirtrafficSimulator,
@@ -34,7 +34,7 @@ def __init__(self, settings: AirTrafficSettings):
         # but we inherit from it. Ideally, we should refactor to composition over inheritance.
         BaseBlenderAPIClient.__init__(self, base_url="", credentials={})
 
-    @scenario_step("Fetch Session IDs", phase=FlightPhase.PRE_FLIGHT)
+    @internal_step("Fetch Session IDs", phase=FlightPhase.PRE_FLIGHT)
     async def get_configured_session_ids(
         self,
     ) -> list[UUID]:
@@ -55,7 +55,7 @@ async def get_configured_session_ids(
             raise
         return session_ids
 
-    @scenario_step("Generate Simulated Air Traffic Data", phase=FlightPhase.PRE_FLIGHT)
+    @internal_step("Generate Simulated Air Traffic Data", phase=FlightPhase.PRE_FLIGHT)
     async def generate_simulated_air_traffic_data(
         self,
         config_path: str | None = None,
@@ -106,7 +106,7 @@ async def generate_simulated_air_traffic_data(
             logger.error(f"Failed to generate telemetry states from {config_path}: {exc}")
             raise
 
-    @scenario_step("Generate Simulated Air Traffic Data with Latency", phase=FlightPhase.PRE_FLIGHT)
+    @internal_step("Generate Simulated Air Traffic Data with Latency", phase=FlightPhase.PRE_FLIGHT)
     async def generate_simulated_air_traffic_data_with_latency(
         self,
         config_path: str | None = None,

src/openutm_verification/core/clients/air_traffic/base_client.py

@@ -10,13 +10,7 @@
 
 if TYPE_CHECKING:
     from openutm_verification.core.execution.config_models import (
-        AirTrafficSimulatorSettings as AirTrafficSimConfig,
-    )
-    from openutm_verification.core.execution.config_models import (
-        BayesianAirTrafficSimulatorSettings as BayesianSimConfig,
-    )
-    from openutm_verification.core.execution.config_models import (
-        BlueSkyAirTrafficSimulatorSettings as BlueSkySimConfig,
+        AirTrafficSimulatorSettings as SimConfig,
     )
 
 
@@ -35,7 +29,7 @@ class AirTrafficSettings(BaseModel):
     session_ids: list[str] = []
 
     @classmethod
-    def from_config(cls, sim_config: "AirTrafficSimConfig", trajectory_path: str | None = None) -> "AirTrafficSettings":
+    def from_config(cls, sim_config: "SimConfig", trajectory_path: str | None = None) -> "AirTrafficSettings":
         """Create settings from config."""
         return cls(
             simulation_config_path=trajectory_path or "",
@@ -58,7 +52,7 @@ class BlueSkyAirTrafficSettings(BaseModel):
     session_ids: list[str] = []
 
     @classmethod
-    def from_config(cls, sim_config: "BlueSkySimConfig", simulation_path: str | None = None) -> "BlueSkyAirTrafficSettings":
+    def from_config(cls, sim_config: "SimConfig", simulation_path: str | None = None) -> "BlueSkyAirTrafficSettings":
         """Create settings from config."""
         return cls(
             simulation_config_path=simulation_path or "",
@@ -82,7 +76,7 @@ class BayesianAirTrafficSettings(BaseModel):
     session_ids: list[str] = []
 
     @classmethod
-    def from_config(cls, sim_config: "BayesianSimConfig", simulation_path: str | None = None) -> "BayesianAirTrafficSettings":
+    def from_config(cls, sim_config: "SimConfig", simulation_path: str | None = None) -> "BayesianAirTrafficSettings":
         """Create settings from config."""
         return cls(
             simulation_config_path=simulation_path or "",

src/openutm_verification/core/clients/air_traffic/bayesian_air_traffic_client.py

@@ -19,7 +19,7 @@
 from openutm_verification.core.clients.flight_blender.base_client import (
     BaseBlenderAPIClient,
 )
-from openutm_verification.core.execution.scenario_runner import scenario_step
+from openutm_verification.core.execution.scenario_runner import internal_step
 from openutm_verification.core.flight_phase import FlightPhase
 from openutm_verification.simulator.models.flight_data_types import FlightObservationSchema
 
@@ -75,7 +75,7 @@ def __init__(self, settings: BayesianAirTrafficSettings):
         # but we inherit from it. Ideally, we should refactor to composition over inheritance.
         BaseBlenderAPIClient.__init__(self, base_url="", credentials={})
 
-    @scenario_step("Fetch Session IDs for Bayesian Simulation", phase=FlightPhase.PRE_FLIGHT)
+    @internal_step("Fetch Session IDs for Bayesian Simulation", phase=FlightPhase.PRE_FLIGHT)
     async def get_configured_bayesian_session_ids(
         self,
     ) -> list[UUID]:
@@ -98,7 +98,7 @@ async def get_configured_bayesian_session_ids(
             raise
         return session_ids
 
-    @scenario_step("Generate Bayesian Simulation Air Traffic Data", phase=FlightPhase.PRE_FLIGHT)
+    @internal_step("Generate Bayesian Simulation Air Traffic Data", phase=FlightPhase.PRE_FLIGHT)
     async def generate_bayesian_sim_air_traffic_data(
         self,
         config_path: str | None = None,
@@ -275,7 +275,7 @@ def _convert_track_to_observations(
 
         return observations
 
-    @scenario_step("Generate Bayesian Simulation Air Traffic Data with latency issues", phase=FlightPhase.PRE_FLIGHT)
+    @internal_step("Generate Bayesian Simulation Air Traffic Data with latency issues", phase=FlightPhase.PRE_FLIGHT)
     async def generate_bayesian_sim_air_traffic_data_with_sensor_latency_issues(
         self,
         config_path: str | None = None,