Skip to main content

Definition of Scenarios in the light of Agile methodology

AUTHOR: Jovana Kuljanin (UPC)

Pilot3 will be developed following some of the principles of the Agile paradigm. The methodology relies on the idea that different prototype versions are incrementally developed by adding new functionalities into each version, until we reach the fully functional prototype. The functionalities that will be implemented are driven by the prioritisation and selection of experiments to be modelled.

A path from identification to execution –  how did we finally define an experiment?

 

The approach followed to create the pool of potential experiments to be modelled and evaluated in Pilot3 contains several important steps:

  1. preliminary identification of scenarios and case studies carried out by the consortium including elements such as airline characteristics, type of flight (short/medium-haul, long-haul), event triggering the need of using Pilot3.
  2. filtering of scenarios and case studies to reflect the feedback obtained from the consultations with the Advisory Board (Advisory Board meeting, questionnaires, ad-hoc site visits, etc.)
  3. definition of the pool of potential experiments – the definition of potential scenarios and case studies and and the identification of values to be used to model the different sub-scenarios and sub-case studies
  4. selection and instantiation of experiments.

How to define the experiment to better reflect the capabilities of the Pilot3 tool?

The validation of Pilot3 will be based on the simulation of specific flights in given operational conditions. For this purpose, different aspects need to be considered such as, elements related to flight characteristics (e.g. type of aircraft, route length), operational aspects (e.g. airline type, characteristics of arrival TMA), environmental considerations (e.g. weather, ATFM conditions), event which triggers the use of Pilot3 (e.g. late arrival at TOC with respect to planned), or the configuration of Pilot3 tool.

A five-level hierarchy framework has been defined to structure all these different considerations:

  1. Scenario is high-level item linked to specificities of the routes and operations that are modelled. A scenario specifies operational variables such as origin-destination pair, airline characteristics.
  2. Sub-scenario further particularises the operational environment (i.e., external factors), such as, type of weather,  ATM characteristics.
  3. Case study is related to the different events that may trigger Pilot3.
  4. Sub-case study is related to the different possible configurations of Pilot3 (e.g. different ways to estimate the performance indicators).
  5. Parametrisation refers to changing parameters that define a (sub)scenario or (sub)case-study to allow sensitivity studies.

The combination and particularisation of these five components provide a specific condition into where to test Pilot3 and this is considered an experiment.

In order to properly model the impact of Pilot3, not only the route and the flight characteristics are needed, but the whole network for the airline (including follow up rotations of the aircraft and passengers itineraries) might be required. For this reason, when possible Pilot3 will base the scenarios on historical flights with the passengers itineraries as created in the ER3 project Domino.

What kind of scenarios can we expect to see in the validation campaign?

Creating a new scenario requires a significant amount of effort, as data acquisition, preparation and in some cases model training of some of the advance indicators and operational estimators will be required!

For this reason, we aim at modelling a reduced number of scenarios, but providing a wide range of operational environments underpinned by the five-level hierarchy framework.

Nine different scenarios which will be further particularised through lower level of hierarchy have so far been identified from Intra-ECAC flights (e.g. Oslo to Barcelona) to intercontinental routes (KJFK to EGLL). For more details, have a look at D5.1 – Verification and validation plan.