• 1

pulsar, pulsar consulting




The PACS and AirSideCap applications were built using Pulsar's framework called GidPro (iRadExpert to register all pages, actions and navigation links and Pulsar’s class loader) and the following standard technologies:

  • Velocity, CSS and Javascript for writing the HTML pages
  • Struts actions as a link between business logics and database access
  • Oracle database and Hibernate as ORM layer
  • Eclipse as Java development environment
  • PowerDesigner to design and generate the original Oracle database
  • PLSQLDevl to manage the Oracle database
  • Tomcat as web application server; Apache as web listener & HTTPS server
  • LDAP as User Authentification Repository

Some time ago, the causes for flight delays were in majority related to airspace management. After a big effort has been made on that side, the proportions changed and it became important to tackle also the causes related to airport management. In that prospect, the need for accurate data gave birth to the PACS project, the target of which was to get more accurate data from the airports. In exchange, the local airports would use for free the tools allowing analyzing and visualizing these data. 

Based on those considerations, the Eurocontrol Agency initiated the PACS Project. Pulsar won the development contract for PACS and led this project to a successful end.

PACS stands for Pan-European Airport Capacity and Delay Analysis Support. 

The general purpose of the PACS project is to progressively store both input and output data of various airport activity analysis tools into a common European repository, for later re-use of the data and scenarios, assuring data confidentiality and security.


Project Scope

The PACS Development project included:

  • building a database structure taking into account the requirements of several existing or future applications so that they can all store their input and output data into PACS repository
  • giving support to these applications for accessing and using PACS datawarehouse
  • developing a web-based application (called PACS) that allows managing and visualizing PACS datawarehouse datadeveloping a web-based application (called AirSideCap) in compliance with the existing tool for airport capacity analysis, the Eurocontrol commonly agreed Camaca.

Three services developed by third party companies can already store their data in compliance with PACS datawarehouse

  • TSG (Traffic Sample Generator) builds simulations of aeronautical traffic
  • Metstat computes statistics on weather conditions affecting the airports
  • AHCA (Airport Handling Capacity Analyzer) analyzes aeronautical traffic samples 


Business Flow - Demand (Air Traffic) / Offer (Airport Capacity)

The main concept called “traffic sample” (1) represents movements of an aircraft during a flight. It can be obtained by different ways either by uploading a local file (2), or by requesting it from the CFMU database (3) or by requesting it from the TSG tool (4). The analysis of a traffic sample (made by the AHCA tool (5)) can be visualized graphically into PACS application.

Based on user-defined parameterized scenarios, and on selected traffic samples, the AirSideCap tool (6) computes the theoretical capacities of an airport. These theoretical capacities can be visualized graphically as well.

The traffic forecast (7) is a set of predictions concerning the yearly load of an airport.

The theoretical capacities computed by AirSideCap are used together with the traffic forecast to build a planning profile (8). This planning profile lets the user visualize on the same graph the increase of the traffic demand and the airport capacity, for various planning options.

The user can also request meteorological statistics through the Metstat tool (9) and visualize the impact of weather conditions on an airport capacity.

PACS home page displays to the public indicators (a measurement giving a characteristic of an airport) on a map.

The user can select in a list an indicator such as:

  • Declared Capacity (official nb of movements of an airport)
  • Experienced Delay (real delay time which happened at an airport)
  • Total Accomodated Flights
  • Maximum Realizable Capability
  • and so forth

Then it is possible to select the wanted validity period before launching the search.

The complete results appear in a table, while the first rows of the table appear on the map.


After login, authorized users may access more detailed information concerning their own aiports. The first screen in the user area gives an overview of an airport with its coordinates, its map, its runway configuration.

The user may request a Traffic Sample analysis for a specific Traffic Sample within a specific period of time and with a specific time unit. 

This gives 2 sets of data:

1) The Throughput Distribution is represented by a graph with 3 curves:

  • the nb of arrivals per time unit
  • the nb of departures per time unit
  • the total nb of movements per time unit
The time unit may be a few minutes, hours, days, weeks, months or a year. E.g.: the graph above shows the traffic fluctuation each 3 hours during 4 days and 3 nights. The first day, we had 130 movements around 15:30 and 14 around midnight (blue curve, total capacity).
2) The Maximum Realizable Capability graph shows the number of arrivals compared to the number of departures, with one curve per considered percentile (a percentile is a value above and below which a specified percentage of cases fall).

E.g.: on the green curve, we can see that, in 90 % of the cases (percentile of the green curve), when we have 40 arrivals we can have a maximum of 18 departures.

The user can deal with theoretical capacities (nb of movements that are, in theory, possible at an airport, under specified conditions).

  • either by entering the data as lists of points
  • or by uploading csv files containing these lists of points
  • or by requesting a capacity calculation from AirSideCap.

All the conditions to be considered by AirSideCap are specified in a scenario that can be built from AirSideCap application interface.

We can distinguish static capacities (showing the capacity at a certain fixed moment) and dynamic capacities (showing the capacity evolution in time). The user can compare distinct scenarios for static capacities by displaying several of them on the same graph.

Static Capacities appear on 2 graphs:

  • number of departures per number of arrivals
  • number of departures per percentage of
    arrivals (pa)

E.g.: on the first graph, the blue curve shows that, when we have 81 arrivals, we can’t have any departure. On the second graph, when 25 % of the movements are arrivals, then we have 57 movements.

 Dynamic Capacity graphs display optionally
  •  the traffic (demand) statistics
    • for arrivals
    • for departures
    • in total
  • the capacity
    • for arrivals
    • for departures
    • in total
The time appears on the x-axis. The same x are used for all curves. The y-axis is used for the mvts/time unit, either for the demand, or for the theoretical capacity.

The user can build a correspondence between Meteo analysis results (output of Metstat) and theoretical capacities and then visualize the impact of weather on capacity in a graph. This is done through the following steps:

  • a correspondence table is built with 2 columns filled in with the selected Metstat output
    • the RVR (Runway Visual Range) conditions, defining the considered visibility on the runway
    • the corresponding percentage of runway usability, percentage of the cases where the RVR applies.
  • the user may complete that correspondence table by selecting an AirsideCap scenario for each line (i.e. for each RVR). The 2 other columns are then automatically filled in with the data of this scenario.
    • the radar separation used in that scenario
    • the average value of the theoretical capacity computed for that scenario
  • A graph is built showing the capacity against the runway usability.

E.g.: in 80% of the cases (corresponding to RVR > 850m), the capacity reaches 45 nb of movements. In the next 5% of the cases (corresponding to RVR between 500m and 850m), the capacity falls to 29.

A forecast scenario gives predictions on the annual number of movements for an airport.

The numbers in bold in the forecast table are the baseline for the annual predictions. It is the begin of the corresponding line in the graph. The user enters the data via the “edit” button, either manually or by uploading a csv local file.

Another graph, very similar, is displayed for the planning profile where the user can see at the same time these forecasts and actual annual capacities (see black line in the graph here below).