E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
E.02.14 - D2.3 - CASSIOPEIA - AGENT MODELS
Document information
Project title
Project N°
E.02.14-D2.3-CASSIOPEIA-Agent Models
Project Manager
The Innaxis Foundation and Research Institute
CASSIOPEIA Agent Models
Deliverable
Name
Deliverable ID
E.02.14
2.3
Edition
00.00.03
Template version
02.00.00
Task contributors
The Innaxis Foundation and Research Institute, Universidad Politécnica de Madrid, University of Westminster
Abstract
This document fits in the modelling architecture of the CASSIOPEIA project. In particular, the
document describes an agent-based modelling architecture for the three case studies selected for the
project: modelling Local Restrictions Limiting Airport and Terminal Airspace Capacity; ATFM Slot
Allocations as a Tradable Commodity; and Dynamic Cost Indexing use by a significant number of
airspace users..
The document includes the current thinking of the CASSIOPEIA team on the best agent modelling
architecture for the project. The lack of standardisation in agent-based modelling techniques led to a
review of a number of different approaches in order to select the best elements that constitute the
architecture. Hence, the models for the three case studies are defined with details on the different
processes that the agents will execute during the simulations.
This document is to be used by a number of tasks within the project. In particular, deliverables D2.7
Data Requirements and D3.3 Model Dataset are derived from the different elements of the
architecture. Additionally, the software design tasks need to take into account all elements of the
architecture, including this document.
1 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
Authoring & Approval
Prepared by
Name & Company
Position & Title
Date
Innaxis CASSIOPEIA team
Consortium Coordinator
11/05/2012
University of Westminster team
Consortium Member
11/05/2012
Universidad Politécnica de Madrid – Facultad
de Informática
Consortium Member
11/05/2012
Name & Company
Position & Title
Date
Jacqui Loadman / The Innaxis Foundation
and Research Institute
Communications
Marketing
Reviewed by
and
11/05/2012
Approved by
Name & Company
Position & Title
Date
David Perez / The Innaxis Foundation and
Research Institute
Consortium Coordinator
11/05/2012
Document History
Edition
Date
Status
Author
Justification
00.00.02
11/05/2012
Submitted
INNAXIS
New Document
00.00.03
22/08/2012
Submitted
INNAXIS
Rev.
including
comments
ECTL
Intellectual Property Rights (foreground)
This deliverable consists of foreground owned by one or several members or their affiliates.
2 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
Table of Contents
0
1
Executive Summary ............................................................................................ 5
Introduction ......................................................................................................... 6
1.1
1.2
1.3
1.4
2
Agent Modelling Architecture ............................................................................ 8
2.1
2.2
2.3
2.4
2.5
3
Purpose of the document ........................................................................................ 6
Intended readership ................................................................................................. 6
Inputs from other projects ....................................................................................... 6
Acronyms and Terminology .................................................................................... 6
Definition of The User .............................................................................................. 9
Definition of the Agent Environment ...................................................................... 9
Definition of the Agent ........................................................................................... 11
Agent Classes and Sub Classes ........................................................................... 11
CASSIOPEIA Architecture ..................................................................................... 12
Agent Models for Each Case Study ................................................................ 13
3.1 Case Study 1 – Local Restrictions Limiting Airport and Terminal Airspace
Capacity ............................................................................................................................ 13
3.1.0 Description of the Case Study ............................................................................... 13
3.1.1 Definition of the User ............................................................................................. 15
3.1.2 Definition of the Agents ......................................................................................... 15
3.1.3 Agent-environment Definition ................................................................................ 23
3.2 Case Study 2 – ATFM Slot Allocations as a Tradable Commodity .................... 24
3.2.0 Case Study Description ......................................................................................... 24
3.2.1 Definition of the User ............................................................................................. 26
3.2.2 Definition of the agents.......................................................................................... 26
3.2.3 Agent-environment Definition ................................................................................ 33
3.3 Case Study 3 – Dynamic Cost Indexing (DCI) ...................................................... 33
3.3.0 Description of the Case Study ............................................................................... 33
3.3.1 Definition of the User ............................................................................................. 34
3.3.2 Definition of the Agents ......................................................................................... 35
3.3.3 Agent-environment Definition ................................................................................ 43
4
References......................................................................................................... 44
3 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
List of Tables
Table 1: Agents modelled in each case study ..................................................................................... 13
Table 2: 10 Busiest Airports in Europe ................................................................................................ 14 Table 3: Airport Agent Attributes, Case Study 1 .................................................................................. 17 Table 4: Airport Agent Subclasses, Case Study 1 ............................................................................... 17 Table 5: Airport Agent Objects, Case Study 1 ..................................................................................... 18 Table 6: Airport Class Instances, Divided by Subclass ....................................................................... 19 Table 7: Main attributes of the airline agent definition, Case Study 1 .................................................. 20 Table 8: Airline Agent Subclasses ....................................................................................................... 20 Table 9: Airport Agent’s Flight Attributes ............................................................................................. 22 Tables 10 -12: Case Study 2, Agent Based Modelling Example ......................................................... 25 Table 13: Case Study 2, AG.01 Airline Description and Attributes ...................................................... 27 Table 14 Case Study 2: Agent Environment ........................................................................................ 27 Table 15 Case Study 2, Description of Objects ................................................................................... 28 Table 16: Case Study 2 Objects - List of Flights Attributes ................................................................. 28 Table 17: Case Study 2 Objects – Resource Allocation List Attributes ............................................... 29 Table 18: Case Study 2 Objects – Passenger List Attributes .............................................................. 29 Table 19: Global environment objects observed by the network manager .......................................... 31 Table 20: Case Study 3 AG.01 Airport Attributes ................................................................................ 36 Table 21: Case Study 3, AG.01 Agent Environment ........................................................................... 37 Table 22: List of Sequence (AG.01.OB001) Attributes ........................................................................ 37 Table 23: Case Study 3, AG.02 Airline Attributes ................................................................................ 38 Table 24: Case Study 3, AG.02 Agent Environment ........................................................................... 39 Table 25: Case Study 3, AG.02 Objects .............................................................................................. 39 Table 26: Case Study 3, List of Flight (AG.02.OB001) Attributes ........................................................ 40 Table 27: Case Study 3, Passenger List (AG.02.OB002) Attributes ................................................... 40 Table 28: Case Study 3, AG.01 Agent Environment ........................................................................... 42
List of Figures
Figure 1 - Cassiopeia Architecture……………………………………..……………………..….13
Figure 2 - Case Study 1 processes……………………………………………………………....17
Figure 3 - Case Study 3 processes………………………………………………………………37
4 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
0 Executive Summary
This document fits in the modelling architecture of the CASSIOPEIA project. In particular, the
document describes an agent-based modelling architecture for the three case studies selected for the
project: modelling of local capacity restrictions and their impact across the European air transport
network; real-time enroute slot trading; and dynamic cost indexing use by a significant number of
airspace users.
The document includes the current thinking of the CASSIOPEIA team on the best agent modelling
architecture for the project. The lack of standardisation in agent-based modelling techniques led to a
review of a number of different approaches in order to select the best elements that constitute the
architecture. Hence, the models for the three case studies are defined with details on the different
processes that the agents will execute during the simulations.
This document is to be used by a number of tasks within the project. In particular, deliverables D2.7
Data Requirements and D3.3 Model Dataset are derived from the different elements of the
architecture. Additionally, the software design tasks need to take into account all elements of the
architecture, including this document.
5 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
1 Introduction
1.1 Purpose of the document
The goal of CASSIOPEIA is to explore different modelling techniques not explored in the ATM
environment and specially suited to the modelling of complex systems. Although not every ATM
technology or procedure should be classified under the category of "complex" as understood by the
SESAR WP-E complexity thread, there are several scenarios in which the high number of actors
involved, the diversity of strategies and/or the uncertainty of the environment in which the actors
develop their strategies, sets a scenario that brings complexity elements. In those cases "traditional"
modelling using either analytical and deterministic approaches provide little information about the
design of those technologies or procedures. It is in those cases where new modelling techniques
could be of great help to design those technologies and procedures, understanding better the
implications of their implementation.
The CASSIOPEIA modelling framework includes a number of modules that, far from being
exhaustive, provide a coherent set of modelling elements in order to drive the project towards
implementation.
In particular Agent Based Modelling (ABM) is an umbrella for a collection of modelling techniques that
sit between science and engineering, having a close relationship with artificial intelligence,
economics, software engineering, game theory and, in some cases, even robotics. The multi-agent
systems field is highly interdisciplinary: it takes inspiration from economics, philosophy, logic, ecology
and social sciences. In general, the applicable field of ABM, is that of large, distributed network
systems and covers all those scenarios in which a number of agents interact with one another by
exchanging messages through some computer network infrastructure.
The goal of the agent modelling effort in CASSIOPEIA is to define in detail a number of agents that
are actively taking decisions in the three case studies chosen for the project. There is no universally
accepted definition of the term agent, and indeed there is much on-going debate and controversy on
this very subject. Autonomy is the central notion of the agency, but there is little agreement beyond
this, as detailed in CASSIOPEIA deliverable D2.1A.
To be concrete on how an agent should be defined, this document also provides a definition of a valid
agent under the CASSIOPEIA modelling framework, in Section 4. Following from that definition, which
incorporates all elements needed to define the model of the agents that will be valid for the three case
studies, this document defines the agents active in these cases, in Section 5.
The working methodology to build the architecture allowed the case studies to develop independently,
since this has been the best approach found by the project team. There will be a cross-case study
rationalisation process further downstream, mainly during the software design phase.
1.2 Intended readership
This report is written for the professional reader and assumes an understanding of air transport and
ATM. Without detriment to appropriate referencing and delineation, the text is not cluttered with
explanations of common acronyms or principles.
1.3 Inputs from other projects
No inputs from other projects have been used.
1.4 Acronyms and Terminology
Term
Definition
ABM
Agent Based Modelling
ANSP
Air Navigation Service Provider
ATFCM
Air Traffic Flow Capacity Management
ATFM
Air Traffic Flow Management
6 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
Term
Definition
ATM
Air Traffic Management
CAD
Communication and Dissemination
CDM
Collaborative Decision Making
CTA
Calculated Time of Arrival
CTAp
Calculated Time of Approach
CTO
Calculated Times Over
CTOT
Calculated Take Off Time
DCI
Dynamic Cost Indexing
FAA
Federal Aviation Authority
FPL
Flight Plan
GAIA
Methodology for agent-oriented analysis and design.
GCD
Great circle distance
ICAO
International Civil Aviation Organization
KPI
Key Performance Indicator
NOP
Network Operation Plan
PRB
Performance Review Body
RAD
Route Availability Document
SES
Single European Sky (initiative)
SESAR
Single European Sky ATM Research Programme
SJU
SESAR Joint Undertaking (Agency of the European Commission)
SODA
Methodology for agent-oriented analysis and design.
7 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
2 Agent Modelling Architecture
The three case studies chosen for the CASSIOPEIA project aim to define particular procedures that
will increase the delegation of certain decisions to the users. For instance, in the case of local
regulations that limit airport capacity, for environmental reasons the users (airlines) will be given a
certain number of possibilities on how to react, from stopping the operation of the flight to re-directing
them to other airports. In the case of flexible enroute slot allocation, airlines will be able to set their
own priorities in the context of the tactical situation, in which certain flights are delayed by the Network
Manager without taking into account the airline's interests, and instead following a first-come-firstserve policy.
Game theory was once largely the preserve of economists who were interested in using it to study
and understand interactions among economic entities in the real world. However, the tools and
techniques of game theory have found many applications in computational multi-agent systems
research, particularly when applied to problems such as negotiation, and that is the main rationale for
the use of ABM as the modelling paradigm.
In general, procedures that take into account reactive systems are more difficult to engineer than
functional ones and all procedures in which negotiation takes place need to be considered reactive
systems. An agent engaging in a non-terminating relationship with its environment must continually
make decisions that have long-term consequences, for the agent and for the society of agents (in our
case, the air transportation network). The goal is precisely the analysis of these long-term
consequences of different policy options in order to help the policy designers make an assessment of
the different outcomes they might expect.
Contrary to the goal of many simulation techniques, the goal of CASSIOPEIA in modelling the
different actors of the system is not to forecast the future in certain conditions, but to make an
assessment of the different potential futures that different policies may bring. This activity is typically
defined as "foresighting" and, as opposed to forecasting, requires different models. While
forecasting is only achievable when existing data about the same situation is accessible and only a
few variables change, foresighting is the right technique to be used when disruptive technology or
procedures are introduced. Foresighting through ABM allows us to make an assessment of the
potential actions of different agents. The goal is the design of "adaptive systems" that can cope with a
wide number of potential future scenarios while defining policies with a maximum likelihood of driving
the system to a manageable state. In this sense, foresighting through ABM techniques can be
considered part of the adaptive systems design tasks.
Different systems will require different types of agents, in terms of their autonomy and the relationship
with their model and computing environment. In what follows, the environment of the agent will be
called "agent-environment" to avoid any misunderstanding with the word "environment" as used
when referring to the natural world.
In CASSIOPEIA, the following characteristics have been considered essential to describe the agents
that will exist in the model of the three case studies:
•
•
•
•
•
•
•
Agents needs to be designed. Also their "society" needs to be designed.
Agents are capable of interacting with other agents, not just in terms of data exchange but
also in different kinds of dialogues: coordination and negotiation.
Agents are at least capable, to some extent, of autonomous actions. The agents decide
themselves what they need to do in order to satisfy their design goals.
Encounters are executed between self-interested entities, typically with no common goals:
agents are primarily concerned with their own welfare.
Normally, an agent will have a repertoire of actions available to it. This set of possible actions
represents the agent's ability to modify its environment, but not all actions can be performed
in all situations.
Actions may have pre-conditions associated with them, which define the possible situations in
which they can be applied.
As the design of the agents is refined there are design choices mostly related to the business
process (e.g. from the airlines, the airports, the network manager) that is the owner of the
agent. The data and control structures of the agent will be defined as part of the architecture
of the ABM. The operations that may be performed on these data structures and the control
flow between them will be the core of the ABM architecture.
8 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
•
•
•
•
•
•
Edition: 00.00.03
A utility function is a numeric value representing how "good" a certain state is. The higher
the utility, the better that state is for a particular agent. The task of the agent is to bring about
states that maximize utility, but typically it is not specified to the agent how this is done.
The agent very often acts under imperfect information, both in terms of intrinsically uncertain
information (such as the weather) and systematically uncertain information (such as lack of
knowledge about delay costs). Agents' attempts to maximise utility are therefore nearly
always based on imperfect information regarding their utility function. The most important of
the capabilities of the agents is the ability to react to changes in the environment and to
exploit opportunities when they arise.
With very complex systems, even if an accurate picture of the system's architecture or
business processes are available, a "virtual" design of this behaviour might not be
practicable.
Agent-environments are assumed to be historically dependent. The next state of an agentenvironment is not solely determined by the action performed by the agent and the current
state of the agent-environment. The actions made earlier by the agent also play a part in
determining the current state. Second, this definition allows for non-determinism in the agentenvironment. There is uncertainty about the results of performing an action in a given state.
The basic model of agents interacting with their agent-environment is as follows. The agentenvironment starts in a particular state and the agent begins by choosing an action. The
agent-environment can respond with a number of possible states. However, only one state
will actually result - though, of course, the agent does not know in advance which it will be.
On the basis of this second state, the agent again chooses an action to perform. The agentenvironment responds with one of a set of possible states; the agent then chooses another
action and so on.
Agent architecture is software architecture intended to support this decision-making process.
The architecture encompasses techniques and algorithms that support this methodology.
Different architectures embody different approaches to rational decision-making
2.1 Definition of The User
This is the user of the model. The user will be described and defined in terms of its characteristics,
goals, inputs to the system and performance assessment objectives.
•
•
•
User Profile: the user profile shall be defined for every case study. In particular, the user
definition shall include characteristics of the professional profile, objectives when using the
CASSIOPEIA platform, skills needed to accomplish a simulation exercise and the level of
proficiency with computers needed. In principle the user profile will be the same for the three
case studies selected.
User Inputs: the data that define the agent-environment of the simulation. This data will be
defined for each case study and should be different for each of them. The data shall define
the agent-environment in detail, including, for instance, the network specification, all the data
needed for the agents and even the data that define the regulations that the user is interested
in.
User-level Goals: The goals of the user will be defined in terms of high level expectations
after running a simulation. The user will aim to analyse the case studies in detail, obtaining
certain performance metrics relating to the evolution of the system and making an
assessment of the achievement of the goals through the analysis of those metrics. This
assessment will be made analysing different indicators (KPIs) as outputs of the system. The
user is in charge of interpreting those indicators and deriving some trends, or even making
different simulations, in order to find inputs that lead to a better system-wide performance.
System outputs will be the aforementioned numerical indicators or even more expressive
visualisation techniques (such as graphics).
2.2 Definition of the Agent Environment
As one classic definition of an autonomous agent defines it (Franklin and Graesser, 1996), an agent is
situated within and part of an environment, both sensing and acting on it. This definition stresses the
role of the environment as a "logical" or physical structure in which agents are "living together".
Some agent-oriented methodologies cope with the environment such as SODA, GAIA and
Prometheus. However, they provide a vague conceptualization of the agent-environment in the design
9 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
phase. In SODA, the environment is the space in which agents operate and interact and in GAIA
"modelling the environment involves determining all the entities and resources that the multi-agent
system can exploit, control or consume when it is working towards the achievement of the
organizational goal" (Zambonelli et al., 2003). Those definitions denote a lack of guidelines for
defining what entities are part of the agent-environment and which are not.
In CASSIOPEIA's agent based model, the agent-environment is conceptualized as a "building-block"
(i.e., an independent piece of software that encapsulates agent-environment functionalities). A good
abstraction of the agent-environment is essential for helping to deal with the inherent complexity of
the ATM domain. This is why CASSIOPEIA's agent model goes beyond consideration of the agentenvironment as a simple agent container or an intermediary for agent communication (Odell et al.,
2003). CASSIOPEIA's agent-environment abstraction aims to provide the following logical
functionalities:
The agent-environment structure is a shared space in which agents are situated, making up a
heterogeneous multi-agent network or organization.
•
•
•
•
It encapsulates available resources and services to be accessed by agents, enabling and
controlling this accessibility.
Enables communication, both direct (i.e., message paradigm) or indirect (i.e., creating or
changing a communication object in the environment in order to be consumed by another
agent). This leads to modelling the agent-environment as a coordination medium, in which
different coordination laws and rules are supported
Promotes the observability of different resources and components, defining them with a
formal representation language.
Defines the rules and protocols for interactions among agents in order to keep the whole
system consistent.
In CASSIOPEIA, the agent-environment is modelled as one, or a set of, modules promoting interoperability among them. These modules or "building blocks" provide different interfaces to allow the
communication and coordination among agents. Furthermore, they provide a function or service to
allow the agents to perceive the agent-environment status.
Each agent will be able to exploit the accessibility to different modules (i.e., local perception of the
agent-environment) in order to achieve their goals, trying to achieve the best outcome.
CASSIOPEIA's model agent-environment abstraction will involve the following modules:
•
•
•
Regulation: each regulation should be composed of the combination of several pertinent
criteria (timing, scope, degree of impact, relationship with agents, etc.). Each regulation
change will be perceived by various agents to different extents. (Note: We are using the term
"regulation" in the legal context, to be discussed further in Deliverable 2.1. We are not
referring to ATFCM regulations - restrictions used to manage traffic flows.)
Exogenous Factors: this module covers different external factor such as meteorological
factors, fuel price or passenger demand. Those factors introduce uncertainty in each agent
decision since the agent has a partial observability of the global agent-environment.
Concretely, these factors not only add dynamicity to the global agent-environment, but also
add non-determinism: each agent doesn't know the outcomes of an action in a deterministic
way, so it makes predictions about those outcomes (e.g., an airline is not aware about the
effects of an action, such as rescheduling or increasing fares, on passenger demand. It is
only able to make a prediction). In many cases, each agent is not able to act over the agentenvironment modelled by this module (e.g., meteorological factors). It is only able to perceive
it through the agent-environment and react to it, trying to adapt. The exogenous factors will be
covered in CASSIOPEIA's deliverable D2.4.
ATM Network Modelling: this module specifies the current state of the ATM network and its
evolution as a whole system. Each agent will have a local perception of this module's
components (e.g., each airline is able to access only their flight plans), consuming it and
updating their local knowledge. CASSIOPEIA's deliverable D2.2 "ATM Network Models" will
tackle this topic.
The CASSIOPEIA architecture is designed with flexibility and scalability in mind. In order to obtain the
aforementioned features and functionalities, each module will be a system input. The user will be able
to parameterize these inputs.
10 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
It is also worth mentioning the temporal scope of the model and simulations. The global-environment
is defined in a temporal scale and the processes of the agent are framed consequently.
2.3 Definition of the Agent
The architecture of the CASSIOPEIA framework will be defined by the number of agents and their
characteristics. As discussed in previous sections, there is no consensus on the best practices
regarding the definition of the architecture for agents, so the CASSIOPEIA team has decided on a
number of elements to define each one of the agents to be involved in the simulations. In particular,
an agent is autonomous, persistent and social with its own control flow software entity representing a
real world individual or collective. CASSIOPEIA embraces agent "specialisation" (i.e. it includes
agent types and sub-types) in order to model different behaviours and business rules. The following
characteristics determine an agent or agent sub-type:
•
•
•
•
•
•
Description and Attributes: The description and attributes are used to specify some
properties of an agent. They are local to each agent type, allowing the identification of an
agent.
Agent-environment: this represents a shared "logical" entity in which the agents "live". Each
agent has a local perception of the agent-environment. Usually this information, perceived by
an agent, is used to carry out its business processes (e.g. decision-making processes).
CASSIOPEIA's framework defines the agent-environment in terms of external databases or
information resources (e.g. legacy systems), other software entities (e.g. the network
operating plan) and sets of agents with which the agent is able to communicate.
Processes: these describe the agent's behaviour. Processes encapsulate the function that
maps any given percept sequence from the agent-environment to an action. In these
processes, decision-logic to achieve their local goals is defined. Thus, an interaction protocol
(i.e. interaction rules) is specified.
(Local or Agent-level) Goals: each agent has self-interests. These interests are represented
through local goals. However, CASSIOPEIA agents are usually dealing with conflicting goals.
Thus, a utility function will be modelled in order to express the appropriate trade-off among
different preferences. This utility function will provide a performance measure of each action
to be carried out (action outcome). Due to the stochastic and partial observability of the
agent-environment, sometimes agents work with an approximate function: expected utility.
Instances: agent types and subtypes are instantiated in order to represent concrete entities.
The instantiation process is carrying out the assignment of the corresponding value to each
attribute.
Objects: The CASSIOPEIA framework deals with a large number of agents. The modelling of
some 'potential agents' as objects instead, reduces the computational burden. An object
differs from an agent in that an object cannot interact with the agent-environment
autonomously: it's behaviour is entirely determined by agent actions. A flight, for example, is
an object, not an agent. Note that in order to avoid confusion between the abstraction level
with the design or even implementation levels, we simply assign objects as attributes of the
agent instead of formally using software object terminology.
2.4 Agent Classes and Sub Classes
An agent class gathers all the characteristics of an entity and determines a common structure.
Afterwards, by assigning values to the parameters, these classes are realised into instances.
However, in some cases, the particularities of an entity go beyond the attributes. For example,
modifying the behaviour. When an instance requires more than attributes to be defined, a new
common structure is defined, the subclass. A subclass inherits properties from a unique parent class,
and overrides those properties which are explicitly defined for the subclass.
11 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
2.5 CASSIOPEIA Architecture
Figure 1 - CASSIOPEIA Architecture
12 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
3 Agent Models for Each Case Study
In this section the theoretical framework of section 2 is applied to three case studies. For each case
study, the following items are characterized:
•
•
•
The user of the system; the trigger of the simulation.
The agents; the entities under examination.
The environment; a shared context between the agents.
There are in total three agents: Airline, Network Manager and Airport. Only relevant actors are
modelled in each case study, the following table shows the agents modelled in each:
Case Study 1
Case Study 2
Case Study 3
Airline
Network Manager
Airport
Table 1: Agents modelled in each case study
3.1 Case Study 1 – Local Restrictions Limiting Airport and
Terminal Airspace Capacity
3.1.0 Description of the Case Study
3.1.0.0 Background
Future air transport growth must be compatible with environmental restrictions. The environmental
impact of air transport has both global effects (related to the emissions of greenhouse gases along
the full flight path and some secondary effects in the high atmosphere) and local effects (linked to the
quality of the air around the airport and to noise). Measures are being taken by airports and local
authorities to limit local effects. Some of these measures are economic, by imposing charges or
taxes, while others directly restrict or prohibit operations at certain hours of the day (i.e. night flights).
They can even include a ban on the operation of certain types of aircraft, either totally, or during a
certain period of the day.
These local environmental restrictions at airports have the potential to reduce capacity by limiting the
available operating hours. They can also redistribute local impact effects by moving the most polluting
aircraft types to less restricted areas.
Air transport noise reduction has historically been based on a mix of measures called a “balanced
approach” by the International Civil Aviation Organization (ICAO). This approach covers four
elements: reduction of noise at source, noise abatement procedures, land-use planning and operating
restrictions. ICAO recommends each individual airport should use the right combination of these
elements for achieving the optimum noise alleviation at the minimum cost.
At some airports, some of the most challenging air quality targets currently relate to NOx (nitrogen
monoxide and nitrogen dioxide). In future, it is anticipated by many that other species of pollutant,
such as particulate matter, could become of equal concern. EC Directive 2008/50/EC of the European
Parliament and of the Council On Ambient Air Quality and Cleaner Air for Europe, entered into force
on 11 June 2008 as part of the Air Quality Framework Directive. Heathrow, Gatwick, Stansted,
Manchester, London City, Paris Charles de Gaulle, Brussels, and Amsterdam Schiphol are among
many airports where growth is being directly constrained by breaches in local air-quality standards.
Three other major European airport hubs are operating at full capacity: Düsseldorf, Frankfurt, Milan
Linate (in addition to Heathrow and Gatwick).
13 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
3.1.0.1 Objective and Impact
The objective of this case study is to understand the impact and implications of airport environmental
regulations on the airlines affected and on the rest of network, taking into account the rescheduling of
flights and a regionalisation of night traffic (in particular). It is important to perform a cost-benefit
analysis for quantifying the economic cost of each measure on the airline operators versus the
environmental benefits (noise alleviation, reduction of emissions). In many cases this analysis is only
made at local level, without taking into account the network impact.
3.1.0.2 Complexity Theory Application
As a result of the introduction of strict environmental regulations under many national and
international legislative initiatives, several studies have analysed the impact of such regulations on
single airports; for example, (Ferrar, 1974; Morrell and Lu, 2000; Upham et al., 2004). Yet when
major, unrestricted (24-hour operation) airports are affected by these types of restrictions, a shift in
demand from the restricted interval to the last period of the day could create some capacity problems
if saturation is reached. Resulting regionalisation/re-scheduling could therefore produce a
redistribution of traffic (e.g. away from airports with prohibited night-time flights) that has important
consequences at a network level.
These network effects should be studied, taking into account the interdependencies of multiple
stakeholders over multiple scales. The emergent behaviour over multiple scales and impacts on
capacity and flow management are currently not well understood.
3.1.0.3 Agent Based Modelling
Stakeholders: Airports, airlines, aircraft manufacturers, local authorities, pressure groups, regulators.
In the modelling of this case, initial action is taken by the airports (typically in response to regulators
and pressure group requests), adopting measures within the general legal constraints. The actions
taken by the airports have direct consequences on the operations of the airlines and the ANSPs.
Airlines will then have the choice of rescheduling or moving to less restricted airports, according to
their business model (e.g. a hubbing carrier may not wish to move significant traffic from an existing
hub to a regional airport, to which it does not operate many flights).
3.1.0.4 Proposed Regulation
For this case study, the proposed regulation studied is the application of a curfew on the 10 busiest
airports in Europe (in terms of number of passengers). The curfew imposed will be based on
Frankfurt's current curfew, imposed by a resolution of a court of law. The following table represents
these airports:
Charles de Gaulle
Orly
Frankfurt
Munich
Fiumicino
Barajas-Madrid Airport
Barcelona
Schiphol
Gatwick Airport Limited
Heathrow
Table 2: 10 Busiest Airports in Europe
14 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
3.1.1 Definition of the User
3.1.1.1 User Profile
The user of the CASSIOPEIA model in this Case Study will be an ATM analyst or expert looking into
the implications at network level of a combined regulation that impacts the capacity limits of several
hub airports simultaneously. This regulation could be of different kinds although the case study
focuses on the regulations based on environmental limitations (noise).
Technical background on the understanding of computing tasks and data reports is also assumed.
Programming skills shall not be necessary, but the user must me acquainted with spreadsheets, text
files and images. And to some extent, the user shall not need specific training to use the software
platform.
3.1.1.2 User inputs
The user needs to define the local capacity constraints, namely a curfew on a number of the busiest
European airports. The user will define the details of the regulation in terms of duration and severity of
it.
3.1.1.3 User-level goals
The final aim of the user is to understand the potential implications over the network of the different
noise regulations when they are applied and to receive feedback from the system in the form of key
performance indicators and graphical representations reflecting the different effects of the regulation.
The user will not be the owner of any of the agents of the system and, hence, will be an impartial
observer. Since it is very unlikely that all local regulations are under a common European regulator on
the subject, most likely the regulations could appear in a non-coordinated way. Therefore the role of
the user is to understand the potential implications at network level and raise awareness among the
stakeholders involved.
The performance assessment of resulting network activity after the application of the regulations will
be performed in accordance with the performance framework established in the Performance
Indicator Model, to be defined in D2.5.
3.1.2 Definition of the Agents
3.1.2.0 Introduction to the Case 1 Processes
Case study 1 processes are designed to allow airlines affected by curfew to reallocate their flights to
the most suitable schedule.
They will first be advised by the affected airports; afterwards, the airlines will provide a preferable
schedule to the destination and to the alternative airport. Both airports will search their slots, and the
connecting airport slots, to find the schedule that best suits the airline (considering their own
preferences). They will inform the airlines of their slot availability and the airlines will decide whether
to change the schedule, the destination, or cancel the flight. After selection, the airline will inform the
airports to confirm or cancel the reserved slot. Finally, the airports will also inform the connecting
airports of the final schedule selection.
The following sequence diagram identifies the different processes that take place in this case study. A
more detailed description will be given for the different agents.
15 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
Figure 2 - Case Study 1 processes
3.1.2.1 AG.01 Airport - CS1
It is important to consider as agents all those airports that may be involved in the different processes,
as well as those which may have their capacity compromised due to traffic regionalization.
The airport agents description will be divided into classes and subclasses when necessary. A class
will contain all those properties common to all airport agents: attributes, context, objects, and common
processes; while the subclasses will contain the particular properties such as goals and subclass
processes.
3.1.2.1.1 Description and Attributes
The Airport Agent Class
The airport agent class includes all airports within the European airspace considered in the sample
data managed in the case study and which have more than certain number of movements (actual
number to be decided during the Case Study definition). All of them will have in common the context
of the system, since they will receive the same information from external sources such as the NOP.
Likewise, they will also have the same objects, and will have one process which applies to all airport
agents as shown below.
When we refer to the airport as an agent, we are actually representing the airport manager, that is,
the person/program responsible for airport operations. The airport agent needs to ensure that the
airport complies with the regulations imposed. In order to do this, it will be notified that a regulation is
imposed and then the airport agent will identify those flights operating in its airport that do not meet
the restrictions.
16 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
The key performance indicators obtained at each airport are part of its attributes. In some case
studies, the airport agents may be able to make decisions based on these attributes:
Airport agent attributes:
ID
Description
Comment
AG.01.AT001
Opening hours
AG.01.AT002
Number of operations per hour
AG.01.AT003
% of capacity
AG.01.AT004
Noise per hour
AG.01.AT005
Total daily operations
AG.01.AT006
Max MTOW for operations
AG.01.AT007
Population affected by noise
Units: number of affected persons.
AG.01.AT008
Hub airlines
List of names of airlines using this airport as a hub.
AG.01.AT009
Flight capacity
Maximum number of passengers per day.
AG.01.AT010
Passenger capacity
Maximum number of passengers per day.
Table 3: Airport Agent Attributes, Case Study 1
Each airport agent will have a capacity assigned (AG.01.AT009). With the information received from
the NOP they will develop a list of slots for those times of the day considered necessary. As is done in
real life, some airports will be coordinated through the busiest hours of the day while others will never
need to be coordinated.
The capacity of each airport is measured in movements per hour; these movements will be described
in the airport's slot availability list. The slot availability list (AG.01.AT011) will be modified by the
airport once it has agreed a certain operation with an airline. In case the capacity of an airport is
unknown, it will be established based on the number of runways.
Airport Agent Subclasses
There are two airport agent subclasses, namely:
ID
Name
comment
AG.01.01
Airports with
regulations
Ten busiest airports in Europe
AG.01.02
Airports without
regulations
Rest of airports in Europe with more than approximately 20 000
movements
Table 4: Airport Agent Subclasses, Case Study 1
3.1.2.1.2 Agent-environment
For any of the airports considered agents, according to the definition above, its agent-environment will
be represented by those flight plans in the NOP that plan to arrive or depart from that airport. The
airports will also receive direct messages from airlines and other airports that will be considered
context.
3.1.2.1.3 Objects
Each airport agent owns some objects as their internal knowledge. This knowledge will be updated
through the perception of the agent-environment.
The airport agent has the following objects:
ID
Name
Comment
AG.01.OB001
Airline
List of airlines operating in that airport
17 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
Attributes of an Airline is specified in Section 3.1.2.2:
ID
Name
Comment
AG.01.OB002
Slot
List of available slots
Table 5: Airport Agent Objects, Case Study 1
3.1.2.1.4 Processes
The following process applies to all the airport agents, regardless of subclass:
Process name: Flight reallocation confirmation
Process code: AG.01.PR.04
Trigger: This process will be triggered by AG.02.PR.03 Reschedule acceptance process.
Description:
The airlines will first request certain operations at different airports, and the airports will reserve the
slots until the airlines decide which option to take. This process will be the acceptance or rejection of
the slots reserved.
The airline will send the message to the airports contacted, and these airports will contact the related
airports to inform them of the decision, so they can all update their respective slot availability list.
(AG.01.AT011)
Regulated Airport Subclass (AG.01.01) Processes
Process name: Airports Inform Affected Airlines
Process code: AG.01.PR.01
Trigger: This process will be triggered by receiving regulations from the user.
Description: Once the restricted airports receive the regulations from the user, these airports will
search through their slot availability list for flights affected by the regulation. These airports will inform
the different airlines.
This process will trigger process AG.02.PR.01 Reschedule request.
Process name: Regulated Airport Flight Reallocation
Process code: AG.01.PR.02
Trigger: This process will be triggered by AG.02.PR.01 _Reschedule request process.
Description: Once the respective airports inform the airlines affected by a regulation, they will request
a change in schedule as close as possible to the previous schedule. The airport will receive these
messages and establish a scheduling prioritization process in order to optimize profit. In order to do
this, the airports will consider certain attributes of the airlines such as their home base, type of aircraft,
or
type
of
airline.
Since a change in schedule will probably affect the previous or next flight scheduled with the same
aircraft, the regulated airport will contact the affected airports and check slot availability. Once it has
found the best schedule available, it will provide it to the relevant airline.
Result: This process will trigger process AG.02.PR.02 Reschedule option selection.
Non-regulated Airport Subclass (AG.01.02) Processes
Process name: Alternative Airport Flight Reallocation
Process code: AG.01.PR.03
Trigger: This process will be triggered by AG.02.PR.01 Reschedule request process.
18 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
Description: Once the regulated airports inform the airlines affected by a regulation they will request a
change in schedule as close as possible to the previous schedule. At the same time, they will request
from the alternative airport a slot maintaining the schedule as close as possible to the original. Since a
change in schedule will probably affect the previous or next flight scheduled with the same aircraft,
the alternative airport will contact the affected airports and check slot availability. Once the best
schedule available has been found, it will provide it to the relevant airline.
Result: The airline will then begin the reschedule option selection AG.02.PR.02
3.1.2.1.5 Agent-level Goals
Regulated airport subclass (AG.01.01) goals
The main goal of regulated airports is to comply with the regulations imposed by the user. Regulated
airports will have freedom to prioritise flights to maximize profit. However, the airlines may decide to
go to another airport or not operate the flight if the change in schedule varies too much.
Non-regulated Airport Subclass (AG.01.02) Goals
The non-regulated airports (those to which the regulation studied does not apply) will try to
accommodate the airlines’ requests as closely as possible to their original request.
3.1.2.1.6 Instances
The ten busiest airports in Europe manage about 25% of the traffic and 30% of the passengers (2010
data; personal communication from ACI). With the regulation imposed, we expect to have about
10.000 flights per week affected (about 12% of the total flights at those airports). The alternate
airports are determined by proximity and convenience.
The following table contains the airport class instances, divided by subclasses.
Regulated airport (AG.01.01) instance
Non-regulated airport (AG.01.02) instance (alternative)
Heathrow
Stansted
Gatwick
Stansted
Charles De Gaulle
Beauvais-Tillé
Frankfurt
Hahn
Amsterdam
Rotterdam The Hague
Madrid
Valladolid
Fiumiccino
Ciampino
Munich
Stuttgart
Barcelona
Girona
Orly
Beauvais-Tillé
Table 6: Airport Class Instances, Divided by Subclass
Note that whether the alternative airport can accept the flight will depend on its capacity constraints
and other acceptance criteria, such as its maximum MTOW for operations (AG.01.AT006).
3.1.2.2 AG.02 Airline – Case Study 1
3.1.2.2.1 Description and Attributes
The airline manages its flights and ensures that its flight plans are accepted. In order to do so, the
airline agents are continuously monitoring the Network Operating Plan (NOP). This NOP is the list of
all flight plans for a specific day, and includes typical flight plan information plus inputs from the
network manager, or the airports involved.
19 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
The following table summarises the main attributes of the airline agent definition:
ID
Name
Comment
AG.02.AT001
User name /ID
Identifies instances in the model
AG.02.AT002
Type of airline (e.g.
LCC, full-service)
Serves the classification of results/behaviour
AG.02.AT003
Homebases
Certain airlines (hub and spoke normally) are strongly
linked to certain airports considered home-base/hubs
Table 7: Main attributes of the airline agent definition, Case Study 1
3.1.2.2.1.1 Airline Agent Subclasses
There will be the following subclasses of airline agents:
ID
Description
AG.02.01
Cargo Carriers
AG.02.02
Charter Operators
AG.02.03
Integrators
AG.02.04
Low Cost Operators
AG.02.05
Network Companies
AG.02.06
Regional Companies
Table 8: Airline Agent Subclasses
Note that the list of subclasses is not exhaustive; there will be airline agent class instances which do
not belong to any subclass.
The following describes the different subclasses of airlines.
AG.02.01 Cargo
There are important differences between the transport of goods and traveller transport that lead to the
existence of specialized airlines, and increasingly also specialized airports. The main features of the
transport of goods are:
•
•
•
•
•
Transport is normally not bi-directional.
High price / weight ratio of the cargo.
Need for larger resources for handling and storage.
Great heterogeneity in the goods.
Huge competitiveness with surface transport (ship, train, truck).
The three big segments in the transport of goods are:
1. Emergency Transport: Exclusively unidirectional, needing a precise real time follow-up of
the goods. In turn it is not predictable, which results in high frequency in the programming of
the flights.
2. Transport of Perishable Goods: Either because of physical obsolescence, as for dairy
products for example, or because of economic obsolescence, as for Press for example.
Remarkably unidirectional, require a lot of handling and storage resources, and by it's very
nature, demands punctuality.
3. Logistical Transport: Used by the big multinational companies in order to not have large
stocks of their products in very different parts of the world. The supplies of commercial aircraft
are a good example of this category.
Attributes Cargo airlines will focus on maintaining their schedule. Therefore we will establish a
maximum schedule deviation of 2 hours. The exact function for prioritisation is yet to be defined, but
in the trade-off between schedule and destination, we will assign about 95% priority to maintenance of
schedule.
20 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
AG.02.02 Charter
Charter companies, originally from Europe, arise thanks to the restrictive regulations in Europe that
existed before 1993. They address a single segment of the market, tourism trips (vacations), and
base their strategy on the sale of sets of seats to tour operators and travel agencies, which are those
who sell the tickets to the passengers, generally together with a wider vacation package (hotel,
activities, etc.). Unlike the rest of the airlines that transport passengers with pre-established and
regular frequencies and schedules, the charter companies offer their flights under demand. Their load
factor is usually very high, and the part of the package price attributed to the flight is at a rate
considerably lower than that of regular flights (until the appearance of the low cost carriers).
Attributes: Given the on-demand characteristic of charter airlines, we will consider that charter
airlines show some flexibility in schedule, however, they will not be willing to compete in cases where
the airport raises charges, which is what would happen if the airport was overloaded at closing and
opening times.
AG.02.03 Integrators
Integrators are big multi-modal companies that specialize in delivering door-to-door within a maximum
specified time. Their aeronautical divisions are very important and employ hub and spoke strategies
for the distribution of their deliveries. The most important ones, on a worldwide scale, are Federal
Express, UPS and DHL
Attributes: Due to the schedule importance in this type of airlines, they will have no flexibility to a
schedule change, and prefer an alternative, if available, without losing time.
AG.02.04 Low Cost Carriers
Low cost carriers compete on prices and frequencies in short and medium range routes, with point to
point traffic, offering very few different rates, sold mainly by telephone or internet, giving a minimal
service for a very low price. The reduction of the unitary cost is obtained not only by offering fewer
services to the passenger, but also through a better utilization of their productive means, minimizing
the diversity of aircraft they use (generally all their aircraft belong to the same model) and achieving
greater flying hours per day (by reducing greatly the turnaround times).
Attributes: Low cost carriers will in principle have the same priority as the charter airlines, although
this may change later through the programming.
AG.02.05 Network airline
Network airlines, also called Legacy Companies for being, in many cases, inheritors of the former
national airlines of many countries before privatisation. Their main features are:
•
•
•
•
•
•
•
Hub-and-spoke strategy: allows them to offer a diversified network of routes,
concentrated in one or more hub airports (distribution centre) and to base their traffic on a
high number of connecting passengers.
Operate different models of aircraft, with different capacities and ranges as result of their
variety of routes.
Multi-product strategy, with several classes in cabin (first class, business class and tourist
class), corresponding to different levels of service to the passenger.
Wide variety of rates.
Passenger loyalty programmes (FFP-Frequent Flyer Programmes).
Participation in Strategic Alliances (Airline Alliance).
High volume of sales through travel agencies.
Attributes: Network airlines will have a different behaviour if they are operating at the hub or out of it.
Any operation in the hub will have a lot of schedule flexibility, and will not consider alternative
destinations. Out of the hub, the airline will be less flexible on the schedule, and more flexible with
regards to the destination.
AG.02.06 Regional Airline
These companies specialize in passenger transport in, generally, short range routes, and for this
reason, very often in domestic flights, or in the European case, intra-communitarian ones. They
operate fleets of aircraft of the so-called regional models, with planes of less than 100 seats. Some of
21 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
them operate in an independent way, but the majority of them operate as franchisees or with some
type of agreement with a network.
Attributes: Regional airlines will behave as network airlines, however they will be considered to have
less economic margin, therefore, if an airport becomes coordinated (saturated), it is expected that the
airport will raise charges and regional airlines will have less chance of competing with network
airlines.
3.1.2.2.2 Agent-environment
The airlines’ agent-environment will be the NOP, and the schedule change options received from the
airports.
3.1.2.2.3 Objects
The airline agent's objects are its flights. Each airline will have a list of flights with the flight plan
information. This information needs to be updated with the NOP information to have all the
information necessary for each flight.
ID
Name
Comment
AG.02.OB001
Flights
List of flights belonging to that airline
Each flight will have the following attributes:
ID
Name
AG.02.OB001.AT001
Flight number
AG.02.OB001.AT002
Origin
AG.02.OB001.AT003
Intended Destination
AG.02.OB001.AT004
Time of Departure
AG.02.OB001.AT005
Time of Arrival
AG.02.OB001.AT006
Aircraft Type
AG.02.OB001.AT007
Aircraft Noise Level
AG.02.OB001.AT008
Slot of Departure
AG.02.OB001.AT009
Slot of Arrival
AG.02.OB001.AT010
Previous Flight Number
AG.02.OB001.AT011
Next Flight Number
Table 9: Airport Agent’s Flight Attributes
3.1.2.2.4 Processes
The following processes belong to the
automatically inherent to all airline subclasses:
airline
agent
class,
and
therefore
they
are
Process name: Reschedule request process
Process code: AG.02.PR.01
Trigger: This process will be triggered by AG.01.PR.01 Airports inform affected airlines
Description:
After the regulated airports inform the airlines of their noncompliance, the airlines will request these
airports assign them a new schedule. The airline will supply the previous or next flight to the flight
affected and other information such as turnaround time so the airport can arrange a new schedule
with
the
airports
affected.
22 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
In order to compare the new schedule provided by the original destination with the schedule at an
alternative airport, the airline will also request the alternative airport to arrange flights as close as
possible to the original schedule.
Result: This process will trigger processes AG.01.PR.02 Regulated airport flight reallocation
process, and AG.01.PR.03 Alternative airport flight reallocation process
Process name: Reschedule option selection
Process code: AG.02.PR.02
Trigger: This process will be triggered by AG.01.PR.02 Regulated airport flight reallocation
process
Description:
Once the airline receives the best available schedules from the original and the alternative airport, it
will
have
to
select
one,
or
cancel
the
flight.
Depending on the airline agent subclass, a weighing factor will be established that will indicate the
priority for the airline. The decision making process will be based on the level of priority assigned to
the subclass attributes. This weight is a factor that identifies the level of priority which is better for the
subclass in the trade-off between maintaining a schedule in an alternative airport at a given distance
from the original destination, and keeping the destination with a different schedule. The result will be
input to the Reschedule Acceptance Process AG.02.PR.03.
Result: This will trigger process AG.02.PR.03 Reschedule Acceptance Process.
Process name: Reschedule Acceptance Process
Process code: AG.02.PR.03
Trigger: This process will be triggered by AG.02.PR.02 Reschedule option selection
Description:
After a selection has been made between cancelling, changing the schedule, or going to the alternate,
the result will be sent to the airports involved for them to confirm reservation of the slots, or cancel
those reservations.
Result: This process will trigger process AG.01.PR.04 Flight reallocation confirmation
3.1.2.2.5 Agent-level goals
The main goal of the airlines is to optimize the options offered by the airports within the imposed
regulations. As explained through the processes, this will be achieved by considering different factors
which depend on the type of airline subclass.
3.1.3.3.6 Instances
Once the full dataset of flights which will be affected is defined, the identification of the subclass
entities will be performed. This will be achieved by identifying those flights operating within the
affected airports. Once the flights and the respective airlines are identified, they will be classified into
the subclasses. This will be achieved through WP3, Model Dataset Definition.
3.1.3 Agent-environment Definition
The agent-environment is a common factor for every agent within CASSIOPEIA. It provides access to
any additional information necessary for their process, this information is also called the contextual
information, and is primarily determined, but not limited to, by the Network Operation Plan.
The contextual information is not part of the agent itself, but a common resource shared to some
extent by all the agents. Some agents may be able to modify this information, while others can only
read part of it.
23 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
3.1.3.1 The Network Operation Plan
The main objective of the network operation plan is to provide a common framework for all the agents
so that the network is balanced in terms of airport capacity and airspace capacity throughout the
simulation time. There are two key questions when describing the Network Operation Plan. First,
'what is the precise information contained in this context?', and, second, 'how the agents can access
this information?'.
3.1.3.1.1 Information
This network operation plan comprises the latest scheduled information and it is meant to be up to
date at any given time. For each flight it contains a record of fields such as: ID, carrier, departure and
arrival times, and airports, type of aircraft, etc. Every flight considered by CASSIOPEIA should be
recorded in the NOP as the airline agents will try to achieve a suitable accommodation of flights within
it.
ID
Carrier
Departure Airport
Departure Time
Arrival Airport
Arrival Time
Aircraft
3.1.3.1.2 Access
Access to the NOP is limited by the class of the agent. It has to be thought of as a common shared
resource with asynchronous access. Some agents may be able only to query information regarding
their own records. Meanwhile, some other agents may be able to modify some fields. This
modification should always be made with extreme caution and always respect the flights-slots
correspondence.
The complete set of details will be defined in the following CASSIOPEIA deliverable, D2.2 ATM
Network Models.
3.2 Case Study 2 – ATFM Slot Allocations as a Tradable
Commodity
3.2.0 Case Study Description
3.2.0.1 Background
Air Traffic Management (ATM) must be capable of handling additional flights if air transport growth is
to be possible, and for other initiatives, such as airport CDM, to be fruitful. To this end, the priority in
Europe is to realise the Single European Sky (SES) initiative. The plan is to have just nine functional
airspace blocks within Europe, and this should provide greater flexibility and open up more direct
routings. Today in Europe, Air Traffic Flow and Capacity Management (ATFCM) is performed by
EUROCONTROL through the Central Flow Management Unit (CFMU). The objective is managing the
balance of demand and capacity by optimising the use of available resources and coordinating
adequate responses, in order to enhance the quality of service and the performance of the ATM
system. ATFM slot-swapping is referred to under Line of Change #3 in the SESAR Master Plan, and
is a component of airport CDM considered in SESAR WP6.
3.2.0.2 Objective and impact
The objective of this case study is to understand the effect of considering ATFM slot allocations as a
tradable commodity, analysing the impact on the airspace capacity and the cost advantages for
airlines (taking into account the potentially higher cost of the traded slot versus savings in flight time,
delay at the destination, fuel consumption, emissions reduction, etc.). The legal framework in this
case would be determined by aviation authorities / regulators, allowing slot trading within predetermined boundaries.
3.2.0.3 Complexity Theory Application
Within this case study, the main dynamics of the system will be created by various independent
entities (represented by the agents described in the next section), interacting and trying to maximize
their pay-off by implementing different strategies (Bonabeau, 2002). These dynamics may give rise to
24 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
complex behaviour of the system, including unexpected emergent phenomena, that should be
analysed and understood within the framework of complexity theory. Complexity theory has indeed
been applied to similar systems, such as, for example, stock markets, with the aim of understanding
and identifying the forces driving such markets, and how to improve their efficiency (LeBaron, 2001;
Tesfatsion, 2002). In this case study, complexity can be used to analyse slot trading as well as the
resulting network created after trading slots, to understand the impact on airline economics and ATM
indicators. A generic issue with this type of approach is understanding the multiple scales which need
to be considered when trading off efficiency (the effectiveness of the economic instrument) against
equity (the unbiased treatment of all users), and balancing local versus network outcomes.
3.2.0.4 Agent-based Modelling
Initial action is taken by the airlines, looking to maximise their economic margins through network
optimisation, and sometimes by selling slots with a high market value. Slot coordinators have to
monitor the developments in real time to avoid traffic disruption and significant sub-optimal solutions.
The interaction of the ATFM slot allocation system with the airport allocation system is essential in this
context. Airlines, airport authorities, ANSPs and the network manager would all be central agents,
since they will have the flexibility to negotiate and trade slots in alignment with their particular interests
and
constraints.
This research will draw on complementary work exploring deterministic optimisations of the European
ATFM situation (Lulli and Odoni, 2007) and novel mechanisms for slot allocation based on market
principles, which enable airlines to pay for delay reduction or receive compensation for delay
increase. This approach can be implemented in a distributed way that does not require airlines to
disclose confidential information, whilst still including them in CDM (Castelli et al., 2010). This also
links with research previously undertaken by members of the study team, investigating, in particular,
how flight prioritisation may be driven by aircraft- and passenger-centric cost of delay functions (Cook
and Tanner, 2011; Cook, 2011).
The following table illustrates a preliminary example of what is intended to be analysed. In this very
simple example we treat only three aircraft subjected to regulation which have different Calculated
Times Over (CTOs), that is, estimates for their entry point to the regulated sector. It is very important
to understand that while the regulation applies to a common sector, routes and departure times of all
flights involved in the trading do not have to be the same. Regulation is enforced over a sector that
can be hours away after the departure of some of the flights, and since we need our trading to be
happening on the ground (because CTOT times are assigned for departure, not once the aircraft is
airborne), it is truly about CTOs that we trade, not about CTOTs (Calculated Take-off Time when a
ATFM slot is issued). The numbers shown in the example are rough numbers. More accurate
research and development of cost functions will have to be made. Each agent will bid for a final
sequence looking for win-win scenarios. We will try to determine which is this sequence in each case
we analyse following the Agent-Driven model.
Tables 10 -12: Case Study 2, Agent Based Modelling Example
25 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
3.2.1 Definition of the User
3.2.1.1 User Profile
The user of the CASSIOPEIA model in this Case Study will be an ATM analyst or expert looking into
the implications of alternative policy options to the enroute slot allocation under abnormal (i.e.
regulated) circumstances. As an alternative to the existing First Planned First Served paradigm, the
user will explore the outcomes of auction mechanisms between airlines when alternative slot
allocation regulations are applied. It is assumed that the user has a global understanding of the air
traffic system in Europe, and a deeper understanding of the regulation framework in this context.
Technical background on the understanding of computing tasks and data reports is also assumed.
Programming skills shall not be necessary, but the user must be acquainted with spreadsheets, text
files and images. And to some extent, the user shall not need specific training to use the software
platform.
3.2.1.2 User inputs
The user needs to define the location, duration and severity of the regulation. This input will mean a
"perturbation" over the scenario presented and which therefore the different agents will have to
accommodate, through the new scenario while striving to reach their individual goals.
Apart from the perturbation details, the user may also input certain aspects about the regulation and
the auction protocol. At first, flights will be accommodated on a first-come-first-served basis, but
further initial prioritizations could be explored. Once the initial slots are distributed, the auction will
begin, and the details of the negotiation process will become part of the Network Manager. Initially the
auction will be a discriminatory price type, in several rounds. But the user may want to explore
different types of auction mechanics.
3.2.1.3 User-level goals
The final aim of the user is to understand the potentials of the new slot allocation process and
determine, prior to the implementation, any further consequences, misbehaviours and, in general,
gains in efficiency. In order to achieve these goals, the user will receive feedback from the system in
the form of key performance metrics and graphical representations reflecting the different effects
resulting from the regulation applied. The metrics will not only be calculated based on actual state-ofthe-art, but also provide insights from other SESAR projects where new ways of measuring metrics
are being analysed (i.e. POEM).
The performance assessment of the result of the network activity after the application of the regulation
will be executed in accordance with the performance framework established in the Performance
Indicator Model. The Performance Indicator Model will be defined in D2.5.
3.2.2 Definition of the agents
The case study presented will be modelled through two agents, namely: Airlines (AG.01) and the
Network Manager (AG.02).
The user defines a capacity shortfall in a high traffic area in Europe, altering therefore the context.
The Network Manager marks the zone as regulated and a number of flights become affected. Airline
agents negotiate the delay distribution using a bidding process regulated and supervised by the
Network Manager.
It is worth noting that the user will not be necessarily the owner of the Network Manager agent but an
independent observer that is looking into the stability of the trading system. The Network manager will
act as supervisor and regulator of the trading mechanisms, imposing certain limits to trading if the
simulation leads to cases in which fairness of the allocation process is compromised.
3.2.2.1 AG.01 Airline
3.2.2.1.1 Description and attributes
26 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
CASSIOPEIA's Case Study 2 essentially aims to be a design tool for enroute slot auction between
airlines from the network perspective. In the context of a hypothetical scenario defined by the user,
some airspace sectors become overloaded due to the differences between the scheduled flights and
the actual available capacity and it is no longer possible to accommodate all the scheduled flights.
This situation triggers a negotiation process between the airlines to arrange who flies when. Each
airline should assess its own cost of delay in order to bid an appropriate monetary amount for the
available slots and assess a value of its utility function, often with non-perfect information. The highest
bidders, those for which the slot represents a higher value, will be able to make use of the available
capacity, the rest will have to be rescheduled for the next time slot window.
The model is restricted to the relevant aspects of the slot-trading mechanisms, namely: short-time
planning and flight delay cost evaluation. The latter will be implemented through delay cost
function. This function will have the same form for all the airport agent instances, and it will depend
on the number of passengers (and their connections, status, etc.), the distance and the future leaps
(e.g. propagation of the delay, due to a previous delayed aircraft or crew). However, the delay cost
function of each instance will have a unique set of attributes (i.e. parameters) which will make them
behave uniquely. For instance some airlines will give priority to the propagation and not to the
passengers.
The delay cost function itself will be an attribute of the object flight defined below. Each flight will have
its particular set of parameters but here we present the global parameters, such as the weight of each
factor.
ID
Description
Use/comment
AG.01.AT001
User name/id
Identifies instances in the model
AG.01.AT002
Type (e.g. low cost, classic)
Helps in the classification of the results/behaviour
AG.01.AT003
Point-to-point
distribution
Is a parameter in the delay cost function (leaps)
AG.01.AT004
Passenger weight in the delay
cost function
or
spoke-hub
Importance of the passengers when considering
delaying a flight
Table 13: Case Study 2, AG.01 Airline Description and Attributes
3.2.2.1.2 Agent-Environment
The airline agent interacts with the environment essentially through the Network Manager. The
Network Manager determines which flights are affected initially and assigns a list of ATFM slots. For
this reason each agent will perceive the same regulation in a different way. Exogenous factors are
also present in the airline agent. The passenger demand, and the fuel price are parameters in the
delay cost function and the weather will determine the alternative routes and flight levels available, if
any.
Regulation
Determines which flights are affected and how the auction is conducted
Passenger demand Parameter in the delay cost function
Fuel price
Parameter in the delay cost function
Weather
Affects available routes and flight levels
ATM network
Determines the current situation of the network, e.g. second order effects.
Table 14 Case Study 2: Agent Environment
3.2.2.1.3 Objects
There are three objects in an airline agent: flights, resources and passengers. Despite the fact that
they are all related, and for the sake of cleanliness, we will keep the distinction described in the
following table.
ID
Name
Use/Comment
27 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
AG.01.OB001
Flights
List of flights belonging to that airline. Is used to determine affected
flights, and to compute alternatives.
AG.01.OB002
Resources
List of matching resources. It is used in the delay cost function to
determine connections and further propagations.
AG.01.OB003
Passengers
List of customers. It is used as a parameter to the delay cost function.
Table 15 Case Study 2, Description of Objects
In turn, each of these objects also contains a set of attributes. The following tables show the object's
attributes and meanings.
3.2.2.1.1 List of flights (AG.01.OB001) attributes
Every airline agent contains a list of scheduled flights and their current situation. Thus under an ATFM
regulation the affected flights can be determined. Each flight in AG.01.OB001 is composed of the
following attributes:
ID
Name
Use/Comment
AG.01.OB001.AT001
Flight number
Used to identify a flight inside the model
AG.01.OB001.AT002
Origin
Used to coordinate ATFM and departure slots
AG.01.OB001.AT003
Destination
Used to coordinate ATFM and arrival slots
AG.01.OB001.AT004
Time of departure
Used to coordinate ATFM and departure slots, and to
compute departure delays
AG.01.OB001.AT005
Time of arrival
Used to coordinate ATFM and arrival slots, and to
compute total delays.
AG.01.OB001.AT006
Aircraft type
Accounts for the physical limitations
AG.01.OB001.AT007
Slot of departure
Used to coordinate with ATFM slots
AG.01.OB001.AT008
Slot of arrival
Used to coordinate with ATFM slots
AG.01.OB001.AT009
Registration
number
Identifies the aircraft
AG.01.OB001.AT010
Requested
level
AG.01.OB001.AT011
Alternative routes
to compute the associated cost of taking an alternative
route.
AG.01.OB001.AT012
Competitors
for a given route, this will determine the soft costs of the
delay
(e.g. if there were no competitors, the risk of losing
customers would be zero)
flight
Some airlines will probably avoid regulations by flying
below the affected sector
Table 16: Case Study 2 Objects - List of Flights Attributes
3.2.2.1.2 Resource Allocation List (AG.01.OB002) Attributes
In order to evaluate the operational cost of delaying a flight, or even to consider selling a slot, the
airline agent model also bears aircraft and crew pairings, so the consequences of a potential delay
can be effectively judged.
The pairing list will contain the following fields:
ID
Description
Use/Comment
AG.01.OB002.AT001
Crew assignments
Determines if the delay introduced by delaying a
particular flight will propagate by means of delayed
crew.
AG.01.OB002.AT002
Aircraft connections
Determines if a future flight will be delayed because
28 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
of a previously delayed aircraft.
AG.01.OB002.AT003
Turn around time for
each connection
Determines possible delay propagation
Table 17: Case Study 2 Objects – Resource Allocation List Attributes
3.2.2.1.3 Passenger List (AG.01.OB003) Attributes
In addition to the scheduled flights, and crew-aircraft pairings, some instances or subclasses also
carry passenger information. The amount of passenger integration into the agent depends greatly on
the instance. Some carriers would keep track of the number of passengers, their seat category (e.g.
tourist, business) and even their flyer status, whereas other airlines will not consider their passengers
at all.
The passenger list AG.01.OB002 contains the following fields:
ID
AG.01.OB003.AT001
AG.01.OB003.AT002
Description
Total number of
passengers per flight
Passengers travelling on
Business class per flight
AG.01.OB003.AT003
Gold status passengers
per flight
AG.01.OB003.AT004
Passenger full route
(steps)
Use/Comment
A parameter in the cost of delay function
(weighted by airline attributes).
When computing the cost of delay function, some
airlines might take into account the class of
passengers delayed
Some airlines might consider the frequent flyer
status of their passengers, into the cost delay
function.
Determines missed connections due to delayed
flights.
Table 18: Case Study 2 Objects – Passenger List Attributes
3.2.2.1.4 Processes
The following processes describe the logic behind the airline agent and will determine its final
behaviour. However, these processes are not fixed procedures (i.e. a starting configuration and a
definite flow), but a set of general directives. These directions are selected such that the agent still
has some autonomous decision margin.
Basically there are three main processes: look for alternatives, cost estimation, and negotiation
process. First of all, under abnormal circumstances the airline would try to determine the set of
possibilities. Secondly, the cost estimation will allow the airline to take rational decisions, for instance
avoiding negative pay-offs unless it is forced to do so. This cost estimation will depend on the
particular instance of the agent class, but the underlying logical process is common for all the
instances in the same agent class or sub-class
Finally, the negotiation process will allow the airline to iterate with other agents and under the
supervision of the network manager. Under certain circumstances the agent would change its own
strategy depending on the decisions taken by other agents that could, for instance, raise the price of
the slot. This collaborative decision making process is in line with the current SESAR approach.
Process name: Search for an alternative route or time slot
Process code: AG.01.PR.01
Trigger: This process will be triggered by AG.
Description:
Before going into the ATFM slot regulation the airline would try to find an alternative route of different
flight level. The cost of each alternative are evaluated with (AG.01.PR.02) and will be considered as
an upper bound in the bidding process.
This process will trigger process AG.
Process name: Estimate Cost of Delay (Delay Cost Function)
29 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
Process code: AG.01.PR.02
Trigger: This process will be triggered by AG.01.PR03
Description:
The estimation of cost of delay will be mainly based on the works already done by Andrew Cook &
UoW in this field.
Main variables are:
- Aircraft Type (AG.01.OB001)
- Number of Passengers (AG.01.OB003)
- Crew time limitations (possible triggering of extra crew) (AG.01.OB002)
- Duration of the flight (REG 261/2004) (AG.01.OB001)
- Connecting Passengers (AG.01.OB003)
Also the type of airline and the rest of attributes (AG.01.AT002-4) will be taken into account in the cost
estimation.
This process triggers AG.01.PR.03
Process name: Place a Bid / Put up for sale
Process code: AG.01.PR.03
Trigger: This process will be triggered by AG.02.PR.02
Description:
First the airline computes the cost of delay (AG.01.PR.02) of the current ATFM slot, in each iteration
this value is called current cost. Secondly, the airline computes the cost of delay for all other available
slots. If any of these has a lower cost, then the airline places a bid for the best available slot. The
initial value of the bid is given by the difference between the current cost and the smallest cost of
delay.
This process continues with AG.02.PR.02
3.2.2.1.5 Agent-level Goals
In the end, the airline agent class models a business entity so there is a clear overall goal; to
maximize profit. However, a typical airline will not in general follow a greedy strategy. Some airlines
may be more aggressive, but to some extent all of them are aware that in the long-term an excellent
quality of service (e.g. low delays and high predictability) is a valuable asset.
Under case study 2 ATFM slots will be considered as a tradable commodity so that, in the case of a
route affected by an airspace regulation, the airline agent class will be given three options: bid for a
better slot, reroute when possible, or put their slots up on the market. This choice will depend on the
outcome of the delay cost function and will be taken to maximize the incomes.
The use of a delay cost function, parameterized according to the agent instance, ensures a sound
bidding policy. Ultimately the delay cost function accounts for all the cost, so an airline will bid for a
slot when its price is below this cost, and will try to sell the slot when the potential benefit outweighs
the cost. Note that each airline instance will evaluate the ATFM slots with different parameters, so the
real value will be relative to the airline. This will ultimately trigger the auction process.
3.2.2.1.6 Instances
An agent class is a skeleton structure shared by all the airline entities, and more in detail, an instance
is a realization of an agent class, it states all the attributes (e.g. parameters) and objects. Usually,
each instance corresponds to a real airline, and tries to capture its particularities.
On the one hand, the abundance of different instances ensures more confident results. On the other
hand, each instance increases the workload. In both terms: definitions and computational. A large
number of instances could easily make the computational load infeasible.
CASSIOPEIA deliverable D3.3 "Model Data Set" gives an answer to the optimal number of agents (a
number large enough to capture any phenomena, while keeping computational workload bounded)
30 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
meanwhile D2.7 "Data Requirements Report" investigates the available sources to fill in the agents
instances.
3.2.2.2 AG.02 Network Manager
3.2.2.2.1 Description and Attributes
The Network Manager takes care of the coordination of the network from a global point of view,
ensuring optimal usage of limited resources, such as airport/sector capacity. In order to accomplish its
goal, whenever an agent airport declares an abnormal operation situation (i.e. weather, system error,
accident, etc.), the Network Manager provides a set of mechanisms to avoid further overloads and
delays. Probably the most common mechanism is to establish regulated slots, limiting the capacity in
the affected airports or airspace sectors.
Once the regulations are established, the Network Manager distributes the scheduled flights on a firstcome-first-serve basis. This distribution is fair, but does not account for the interest of the users and
there is no collaborative decision process. However, in CASSIOPEIA Case Study 2, a different
mechanism is proposed, the users (airlines) will be able to negotiate and agree on how they are going
to share the delay. To do so, when a sector is regulated, slots become a tradable commodity.
In Case Study 2, the Network Manager has two roles. First of all, the Network Manager supports and
coordinates the bidding process. Initially, no user should be excluded from the bidding process, all the
users should be aware of the bidding status and have the same bidding options. However, it is
possible that the Network Manager ban some behaviour, for instance as a punishment for some
unwanted behaviour. Secondly, the Network Manager should ensure that the agreed solutions will not
lead to an unbalanced network, and that the final distribution of delay does not imply an extreme
suboptimal usage of the limited resources.
3.2.2.2.2 Objects
As a coordination agent, the Network Manager does not have any own objects. All the necessary
information is obtained either from the context or from its attributes. Note that all flight plans are an
accessible part of the Network Manager's context.
3.2.2.2.3 Agent-Environment
The following items of the global environment are perceived by the network manager:
Regulation
The Network Manager is responsible for its application
Passenger demand Not present
Fuel price
Not present
Weather
Determines the severity and duration of the capacity shortfall
ATM Network
The Network Manager coordinates the network
Table 19: Global environment objects observed by the network manager
3.2.2.2.4 Processes
Process name: Initial ATFM slots distribution
Process code: AG.02.PR01
Trigger: This process will be triggered by AG.
Description:
Once the sector over which the regulation is applied, a list of entry estimates for each flight should be
31 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
handed to the Network manager. Based on the hourly capacity constraint (i.e. 30 airplanes per hour),
the Network manager starts assigning Entry Times to each aircraft with a reasonable time-spacing
(i.e. 2 minutes per aircraft), also making sure that at the same time not more than a given number of
airplanes are in the sector (i.e. 12 aircrafts). That is, he has to make a first-come-first-serve list based
on:
- Capacity per hour (and space their entries/exits accordingly).
- Analysis of the maximum number of airplanes that, at the same time, will be inside the sector.
This process will trigger process AG.02.PR02.
The Network Manager agent class has three basic processes: trigger the negotiation process,
coordinate the auction process and validate the achieved solution. First of all, when an unexpected
situation occurs (e.g. weather, system error, etc.) the Network Manager determines which flights are
affected, produces a list of ATFM slots (distributed to the affected flights on a first-come-first-serve
basis), and activates the auction process.
Secondly, the Network Manager supervises the auction, keeping track of the bids, and determines the
winner in each round. Finally, once a solution is achieved, the Network Manager checks if the network
is, capacity-wise, balanced and there is not too much unused capacity (entropy of the system does
not exceed a certain limit).
Process name: ATFM slot auction coordination
Process code: AG.02.PR02
Trigger: This process will be triggered by AG.
Description:
1) List of slot assignments is published so all AG.01 know the whole picture.
2) Each agent starts bidding for a certain CTOT.
3) At CTOT - taxi time - 20', the auction stops and the winner is announced (20' margin is thought to
be enough for boarding if the airline had decided to leave passengers in the terminal).
4) Airlines that do not comply with a bought slot, lose it and go back on the queue.
This process will trigger process AG.
Process name: validate ATFM slots distribution
Process code: AG.02.PR03
Trigger: This process will be triggered by AG.02.PR02
Description:
Once a bid is placed, the Network Manager verifies if this slot allocation has further implications. In
other words, some slots-user's combinations may be banned because they may lead to extremely
suboptimal use of the limited resources. For instance, an airline asking for a slot which it is very
unlikely
to
accomplish.
In addition, if a user decides to stay out of the bidding process and simply accepts its ATFM assigned
slot, it should not be penalised, nor rewarded.
This process may be continued by AG.02PR.02, or finish the simulation.
Note that the Network Manager is a key actor in the Air Traffic system and CASSIOPEIA's deliverable
D2.2 "ATM Network Models" will describe this agent in deeper detail.
3.2.2.2.5 Agent-level Goals
Currently the Network Manager has a clear goal; to reduce congestion to the maximum possible
value, making the best use of the available capacity, whilst ensuring safety and lack of bias
32 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
throughout the network. Note that the user preferences do not affect the current Network Manager
goals, however, in Case Study 2 the Network Manager shall also consider the user's preferences.
The Network Manager should ensure a fair bidding process. It will be its new responsibility to ensure
that all the affected users are aware of the situation, and are given the same bidding options. Also,
the Network Manager supervises the bidding process, playing the role of the coordinator and referee.
These auction-oriented goals will be achieved through the process, as they are built in such a way.
In order to make the best use of the available capacity, the Network Manager will also check the slot
distribution provided by the users, through the bidding process, so the limited capacity is effectively
used (i.e. there are no free slots) and no unbalanced situations appear along the network. The
Network Manager will not determine which is the best distribution, but ensures that the achieved
distribution is feasible and makes use of all available resources.
3.2.2.2.6 Instances
Note that in contrast to other agents, there is only one instance of the Network Manager. The
European Network Manager is the Central Flow Management Unit (CFMU) operated by
EUROCONTROL. CASSIOPEIA deliverables D2.7 "Data requirements report" and D3.3 "Model
Dataset" will investigate the data requirements and possible sources.
3.2.3 Agent-environment Definition
In case study 2, the main object of the agent-environment will be a Network Operations Plan (NOP).
This NOP will contain the ATFM slots issued to the different airlines.
The Network Manager will publish in the NOP, the ATFM slots that are issued to the airlines on a first
come-first served basis. The airlines will be able to bid through the NOP, and follow the different
processes to reach a balanced solution.
In this case study, one of the busiest sectors in Europe will be simulated to have a capacity shortfall.
The sector selected is the Nicky Sector, both High and Low, of the Maastricht Upper Area Control
Centre Airspace. This sector is known for its complexity, since it has main departure and arrival flows
of 4 main airports in Europe: Amsterdam Schiphol, London airports, Frankfurt, and Paris Charles de
Gaulle.
This sector can usually manage up to 100 aircraft per hour (per subsector), and the capacity will be
diminished to different levels to check the agents reactions.
3.3 Case Study 3 – Dynamic Cost Indexing (DCI)
3.3.0 Description of the Case Study
3.3.0.1 Background
Airlines have had to find ways to reduce their fuel consumption, almost continuously since the first oil
crisis in 1973. This involves not only their own strategic and tactical operations but also those of other
air transport stakeholders: aircraft and engine manufacturers, ANSPs and airports. The way airlines
operate aircraft (flight level and speed) has a large impact on fuel consumption. Modern aircraft
incorporate flight management systems (FMSs) that allow pilots and airlines to define the flight plan
very precisely, optimising variables such as fuel consumption and flight time. The FMS ‘cost index’
(CI) trades the cost of time (delay) versus the cost of fuel, although this is usually used only (very)
crudely by airlines. Early research in this field (dynamic cost indexing) was undertaken by the
University of Westminster (Cook et al., 2009) under funding from the EUROCONTROL Experimental
Centre.
Decision-making in the context of uncertainty is particularly challenging, especially regarding the cost
of delay, as the tactical situation (such as passenger connections), dynamically develops and
because of the unpredictability of weather. Since January 2012 air transport has been included in the
European Emissions Trading Scheme, adding further pressure to airlines regarding the need to
optimise fuel consumption, whilst balancing these demands against those of developing their
business in an increasingly competitive environment.
33 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
3.3.0.2 Objective and Impact
Although reducing CO2 emissions and saving fuel are mutually consistent goals, since CO2
emissions are directly linked to fuel burn, this poses a further challenge in terms of dynamic cost
indexing, requiring the incorporation of current and future market prices of CO2 (carbon permits).
This case study will explore the impact on KPIs (for ATM in general, and airlines in particular), of
aircraft flying with different departure times and/or flight profiles, with different speeds and/or CI
values, to optimise fuel and CO2 costs. In particular, we wish to explore the network-level impacts of
new behaviours. Usefully, the deployment of minimum fuel speeds to absorb ATFM delay has
recently been explored by Prats and Hansen (2011) and Delgado and Prats (2011).
3.3.0.3 Complexity Theory Application
The determination of the flight profile is a responsibility not only of the airlines, but also of the ANSP,
and a potential speed reduction may contribute to the saturation of airspace and airports. It is also
necessary to understand the impact of a potential increase in the flight duration on passenger choice
and market share, especially in a long- or medium-haul market. The total number of flights in the
system could actually be reduced, diminishing mobility indicators of the network.
It should be noted that the expected system-wide impact is not the result of the sum of each individual
change in flight planning. Due to the complexity of the air transport system, a small modification in the
trajectory of one flight may have unexpected consequences in the dynamics of other (in principle,
independent) flights, thus creating system-wide emergent behaviours. Therefore, the impact shall be
studied through complexity science to understand different trends in the various key performance
areas.
The complexity of these issues is further compounded by the need to take account of delay costs as
they propagate over multiple scales, as explored in terms of their economic impacts by members of
the project team (Cook and Tanner, 2011). The costs of delay are generally dominated by the
passenger cost of delay to the airline. The contribution of the reactionary (propagated) cost varies
from context to context, but may often be the second highest factor. After the passenger costs, and
depending on the delay duration, the next highest contribution is typically fuel costs for the enroute
phase (becoming proportionately less as the length of the delay increases). These costs are a nonlinear function of the primary delay duration: in other words, two 15 minute delays cost less than one
delay of 30 minutes.
3.3.0.4 Agent-based Modelling
Notwithstanding a broad cross-section of stakeholders, from passengers, airlines and aircraft
manufacturers, through ANSPs and airports, to regulators and the Network Manager, our focus in
terms of the agents modelled needs to be tighter in order to make the modelling tractable. The
passenger and regulatory perspective will be captured through the regulation model itself (since
Regulation 261 addresses passenger rights – see later). The primary agents will be the airlines,
airports and the Network Manager. Certain airlines will attempt to optimise their performance (e.g. on
cost and punctuality) through the use of Dynamic Cost Indexing (for example), which may result in a
request to either reduce or increase speed, relative to the last-filed / original flight plan. The Network
Manager will try to make the most efficient use of the available capacity whilst also attempting to meet
such airline demands; the airports will try to accommodate such demand whilst maintaining maximum,
safe flight throughput.
3.3.1 Definition of the User
3.3.1.1 User Profile
The user of the CASSIOPEIA model in this case study will be an ATM analyst or expert looking into
the implications, at network level, of a combined use of dynamic cost indexing (DCI) by a significant
number of airlines in a significant number of operations. The use of DCI may cause various airports
and the network manager to face different challenges in terms of traffic changes and slot allocations.
However, these actors will be considered autonomous agents of the system and will not act on behalf
of the user. The user will be exploring the impact of the different extents of DCI application.
34 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
A technical background regarding the understanding of computing tasks and data reports is also
assumed. Programming skills will not be necessary, but the user must me acquainted with
spreadsheets, and text file handling. The user will not need (much) specific training to use the
software platform.
3.3.1.2 User Inputs
The user needs to define the capacity constraints for a number of the busiest European airports and
enroute sectors, as well as the prevalence of the use of DCI techniques. For example, the number
and nature of the airlines using dynamic cost indexing, the parameters and delay recovery rules
employed (if any), and the routes/flights and times of day for which the airlines would be using DCI
(some may only use it on hub-feeder flights, some may only use it later in the day to recover delays).
3.3.1.3 User-level Goals
The final aim of the user is to understand the potential implications over the network of the different
levels of penetration of DCI. Although in principle the user should have no authority to limit the level of
penetration of these techniques, the goal of the user is to devise an assessment of the impact of the
use of dynamic cost indexing and to understand if there are:
•
•
•
Applicability limits in terms of the number of airlines that use the procedure;
Schedules for which the procedure induces significant changes to the network;
Routes/airports for which the perturbations are especially harmful (as well as to the network).
The performance assessment of the result of the network activity after the application of the
regulations (to be defined in D2.1) will be performed in accordance with the performance framework
established in the Performance Indicator Model, to be defined in D2.5.
3.3.2 Definition of the Agents
Case Study 3 will be modelled with three agents, namely: Airports (AG.01), Airlines (AG.02) and the
Network Manager (AG.03). The basic behaviour of the agents is the following: Airlines will try to
optimize their own performance by means of Dynamic Cost Indexing, the Network Manager will try to
make the most efficient use of the available resources, and Airports will try to accommodate the
maximum number of flights.
The following sequence diagram identifies the different processes that take place in this case study. A
more detailed description will be given for the different agents - the following sections develop the
methodology explained in section 2.3 "Agent Definition" for each agent present in Case Study 3.
35 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
Figure 3 - Case Study 3 processes
3.3.2.1 AG.01 Airport
3.3.2.1.1 Description and Attributes
The airport agent in this case will be what is currently known as an arrival manager. The Dynamic
Cost Index (DCI) will introduce last minute changes to the electronic flight plans that are the basis for
Air Traffic Flow Management (AFTM). ATFM ensures that all sectors within the European airspace do
not overload. The airport agent will assess from a tactical point of view the schedule changes
produced by the last minute airspeed variations. With the variations in estimated time of arrival, the
airport agent will pursue the accommodation of all flights, by assigning a Calculated Time of Approach
(CTAp) and the Initial Approach Fix (IAF). This will generate a sequence and thus delay different
aircraft, which must be accounted for in the performance model to measure the counter-effects of
DCI.
ID
Description
Use/comment
AG.01.AT001
Arrival Capacity
Determines how many aircraft per hour can land
AG.01.AT002
Number of arriving
runways
Each flight will have to be assigned to a landing runway
AG.01.AT003
Opening - Curfew
Time limits for opening/closing the airport (if applies)
AG.01.AT004
Arrival spacing
Will depend on aircraft times/Runway Capacity/ATC
performance
AG.01.AT005
Outgoing taxi time
Useful for Departure Tolerance Window calculations made
by AG.03
Table 20: Case Study 3 AG.01 Airport Attributes
36 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
3.3.2.1.2 Agent-environment
The airport agent will acquire the necessary information for flights from the NOP. The airport agent
will also have access to certain fields of the NOP in order to issue restrictions to the flights, such as
CTAp.
Other external information, such as weather conditions, will be obtained from the agent-environment.
Regulation
The airline is responsible for the response to Regulation 261 (see also tables 24 and
28)
Passenger
demand
Not present
Fuel price
Not present
Weather
If too bad, might provoke missed approaches and closing of the airport, thus
remaking approach sequence (can me modelled statistically, i.e. 10% of GoA if
visibility < 300m)
ATM network
Each agent might vary its capacity depending on time/number of runways in use
Table 21: Case Study 3, AG.01 Agent Environment
3.3.2.1.3 Objects
The airport agent will maintain an approach sequence based on information from the NOP.
ID
Name
Use/comment
AG.01.OB001
Sequence
List of assigned Calculated Times of Approach to each flight
Each object has a set of attributes, and are listed in the following tables.
The sequence will contain the following attributes for each flight
ID
Name
Use/comment
AG.01.OB001.AT001
Flight number
e.g., IBE6123
AG.01.OB001.AT002
Aircraft type
Necessary for wake turbulence separation.
AG.01.OB001.AT003
CTAp
Calculated Time of Approach
Table 22: List of Sequence (AG.01.OB001) Attributes
3.3.2.1.4 Processes
The following processes are performed by the airport agent:
Process name: Receiving information of incoming traffic
Process code: AG.01.PR.01
Trigger: This process will be triggered by AG.03 (Network Manager)
Description:
The airport needs to be notified of any change made in the flight plans of the NOP. If the change is
made before the activation of the flight plan, it will be considered a pre-tactical change, which will
follow a flow management filter for approval in the NOP . However, if the change is made after the
activation of the flight plan, the airport agent will have to handle the arrival time change through the
sequencing process.
This process will trigger process AG.01.PR.02 Sequencing
Process name: Sequencing
Process code: AG.01.PR.02
Trigger: This process will be triggered by AG.01.PR.01
37 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
Description:
The airport agent will continuously monitor the arrival sequence taking into account the CTAp s
supplied for the approach, and if necessary, will enforce delays to random flights. Thus, maintaining
arrival flow under capacity limits.
3.3.2.1.5 Local Goals
The arrival manager tries to maximize the total amount of incoming traffic, preserving safety in the
operations. Capacity might be reduced as a local goal of the arrival manager if events such as bad
weather or industrial action take place.
3.3.2.1.6 Instances
The airports modelled as agents will be decided after careful study of the approach sectors, and the
distribution traffic between the different airlines.
3.3.2.2 AG.02 Airline
3.3.2.2.1 Description and attributes
Case Study 3 is a network impact assessment tool, studied under different scenarios of airlines
applying dynamic cost indexing (DCI) techniques. Different airlines will take the decision (on a perflight basis) of using DCI, with potential impacts on flight times and airspace use.
This may trigger a different airspace usage situation that would then need adjustments from the
network manager. These adjustments might be changes to the slots allocated and therefore might
mean that new tactical slots have to be issued, not only to those airlines using DCI, but also to others,
as a consequence of the different airspace usage.
In this case study, airlines using DCI would not enter into negotiation with other airlines and we would
not include any slot trading.
ID
Description
Use/comment
AG.02.AT001
User name/ID
Identifies instances in the model
AG.02.AT002
Type of airline (e.g. LCC,
full-service)
Serves the classification of results/behaviour;
parameter in the delay cost function
Table 23: Case Study 3, AG.02 Airline Attributes
3.3.2.2.2 Agent-environment
Regulation
Regulation 261/2004 (existing legislative framework and potential changes being
reviewed by the Commission); other regulations may also be considered, such as
those relating to slot adherence and amending regulations to civil aviation aircrew
rules.
Regulation 261/2004 needs to be followed closely, particularly the potential extension
of the legislation to cover passengers’ missed connections, which is not covered by
current law. SESAR is chairing one of the main ACARE working groups to define a
new European air transport research and innovation perspective: "[…] placing aviation
in a global, intermodal context that will put the air transport passenger/customer at the
core of the system." This work will form part of the Commission’s ‘Strategic Research
and Innovation Agenda’, due to be published in July 2012.
Cost of
delay
Includes a particular focus on passenger delay costs
Cost of
delay
recovery
Focuses on fuel cost, routing options, and aircraft characteristics
Weather
Affects available routes and flight levels
ATM
Determines the current situation of the network, e.g. heavy inbound congestion to
38 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
network
Edition: 00.00.03
certain airports, congested sectors.
Table 24: Case Study 3, AG.02 Agent Environment
3.3.2.2.3 Objects
ID
Description
Use/comment
AG.02.OB001
Flights
List of flights belonging to an airline. Used to determine
affected flights, to compute alternatives and calculate cost
functions.
AG.02.OB002
Passenger
dependencies
Passenger attributes, used as a parameter in the delay
cost function.
AG.02.OB003
Non-passenger,
reactionary
dependencies
Used in the delay cost function to determine connections
and further delay propagation potential. Modelled as
dependent flight attribute.
Table 25: Case Study 3, AG.02 Objects
List of Flight (AG.02.OB001) Attributes
Each flight in AG.02.OB001 is composed of the following attributes:
ID
Description
Use/comment
AG.02.OB001.AT001
Flight number
Used to identify a flight inside the model
AG.02.OB001.AT002
Origin
Used to coordinate ATFCM and departure slots
AG.02.OB001.AT003
Destination
Used to coordinate ATFCM and arrival slots
AG.02.OB001.AT004
Time of
departure
Used to coordinate ATFCM and departure slots, and to
compute departure delays (relative to schedule)
AG.02.OB001.AT005
Time of arrival
Used to coordinate ATFCM and arrival slots, and to
compute arrival delays (relative to schedule)
AG.02.OB001.AT006
Aircraft type
Partly determines delay recovery performance
AG.02.OB001.AT007
Departure slot
Used to coordinate with ATFCM slots
AG.02.OB001.AT008
Arrival slot
Used to coordinate with ATFCM slots
AG.02.OB001.AT009
Registration
number
Identifies the aircraft
AG.02.OB001.AT010
Requested
Flight Level
Some airlines will probably avoid ATFCM regulations by
flying below an affected sector
AG.02.OB001.AT011
Alternative
routes
To compute the associated cost of taking an alternative
route.
AG.02.OB001.AT012
Competitors
For a given route, this will help to determine the soft costs
of the delay (e.g. if there are no competitors, the cost is
statistically lower)
AG.02.OB001.AT013
Combined
distance and
DCI potential
A parameter based on the distance of the flight (e.g.
using GCD) and the potential to recover delay. For
example, a longer-haul flight, or a flight not highly restricted
by the RAD (e.g. on a heavily congested city pair) will have
a higher delay recovery potential.
AG.02.OB001.AT014
Type of flight
E.g. hub-feeder or not; long-haul or short-haul. Parameter in
the delay cost function
AG.02.OB001.AT015
Crew costs of
delay
Determines if a flight delay will incur associated crew costs.
Note - it is out of scope to model this explicitly in Case
Study 3, as so many resources will be dedicated to
39 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
estimating the passenger costs. Costs will be assigned
statistically depending on other attributes, such as whether
the flight is operating through an airline hub or high intensity
centre. Includes reactionary delay.
AG.02.OB001.AT016
Non-crew, nonpassenger
costs of delay
A statistical (non-explicit) estimate of all other costs of
delay. Includes reactionary delay costs (although these will
be relatively small compared with those covered by the
crew [AG.02.OB001.AT015] and passenger [AG.02.OB002]
components).
Table 26: Case Study 3, List of Flight (AG.02.OB001) Attributes
Passenger List (AG.02.OB002) Attributes
For each passenger, the following attributes need to be set. Note that, because of the complexity of
assigning these attributes to each passenger, each of these attributes is binary.
ID
Description
Use/comment
AG.02.OB002.AT001
Connecting or non-connecting
Used to determine passenger delay cost
function
AG.02.OB002.AT002
Onward flight short-haul or longhaul
Used to determine passenger delay cost
function
AG.02.OB002.AT003
Economy or (any) premium class
Used to determine passenger delay cost
function
AG.02.OB002.AT004
High or status FFP membership,
or other
Used to determine passenger delay cost
function
Table 27: Case Study 3, Passenger List (AG.02.OB002) Attributes
3.3.2.2.4 Processes
Note. A request to change the flight plan can be made strategically, pre-tactically or tactically
(including the use of DCI). However, we should also bear in mind that any AO request which involves
a large increase in fuel burn obviously needs to made before the aircraft declares itself ready for
pushback. Officially, the airline only needs to inform ATC if a planned change of speed of >5% of the
FPL is intended. In terms of enroute aircraft actively wishing to change speed, if the average TAS at
cruising level between reporting points varies, or is expected to vary, by ±5% or more of the speed
declared in the flight plan, this should be notified to ATC. Controllers monitor separation rather than
speed, partly due speed at given level varies so little and mostly due wind. (Rules of the Air, Annex 2
to the Convention of International Civil Aviation, 1990).
Process name: Flight plan pre-activation
Process code: AG.02.PR.01
Trigger: This process will be triggered 30 minutes before the expected time of departure.
Description:
This process will establish the beginning of the flight plan in the NOP. Once the airline pre-activates a
flight, it will request the network manager calculate the electronic flight plan.
This process will trigger process AG.02.PR.02 Cost Index/re-route calculation
Process name: Cost Index/re-route calculation
Process code: AG.02.PR.02
Trigger: This process will be triggered by AG.02.PR.01 and repeated after certain intervals or if the
airline is notified of a restriction for a flight.
40 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
Description:
This process will calculate and update the cost index and route of the operation involved. A new
airspeed/route will be assigned for the flight which will be notified to the network manager, and the
NOP will be updated.
In case this process takes place after activation of a flight plan, the change must be approved by the
network manager before updating the NOP.
This process will trigger process AG.03.PR.01 Electronic flight plan calculation
Process name: Flight plan activation
Process code: AG.02.PR.03
Trigger: This process will be triggered 5 minutes before departure.
Description:
This process will activate the flight plan, which means that any changes there after will be considered
tactical changes.
This process will update the status in the NOP.
3.3.2.2.5 Local Goals
Although airline goals are to maximise profitability, the trade-off between minimising delay costs and
maintaining punctuality targets is often opaque. To complicate matters, different functions (flight
planning, maintenance scheduling, passenger re-accommodation, performance management) may be
operating with conflicting objectives.
3.3.2.2.6 Instances
A cross-section of airlines and flight types using the Nicky Sector (Maastricht Upper) will be
considered for inclusion in Case Study 3. Initially 50% of traffic crossing the sector will be focused
upon, with the most frequent airspace users (mainly LCC and full-service airlines) supplemented with
regional and hub-feeder carriers to ensure a mix of flights with connecting/non-connecting
passengers. The inclusion of airlines involved in the DCI break-out session at the joint
CASSIOPEIA/POEM stakeholder workshop (January 2012) may offer an insight into their decisionmaking process, and the application of such rules to similar airlines crossing Nicky. If required, the
level of traffic assumed to be using DCI will be increased beyond 50%. The implication for re-routes
outside of the Nicky sector will be considered later.
3.3.2.3 AG.03 Network Manager
3.3.2.3.1 Description and Attributes
As noted under the airline agent, the use of dynamic cost indexing may trigger a different airspace
usage situation that would need adjustments from the network manager. These adjustments might be
changes to the slots allocated and therefore might mean that new tactical slots have to be issued, not
only to those airlines using DCI, but also to others, as a consequence of the different airspace usage.
Challenges may (and do) arise, however, when the network manager is unaware of such intentions
until the aircraft is airborne. Furthermore, the airline only needs to inform ATC if a planned change of
speed >5% of the FPL is intended. In terms of enroute aircraft actively wishing to change speed, if the
average TAS at cruising level between reporting points varies, or is expected to vary, by ±5% or more
of the speed declared in the flight plan, this should be notified to ATC.
En-route notifications of speed changes are not usual in the upper airspace, mainly due to the fact
that the aircraft has been loaded with the fuel necessary to complete the flight (plus the safety
margins) taking into account an engine setting. Not only may the aircraft request an increase in
speed, but a speed reduction may also be requested to save fuel. Speed change requests may often
be accompanied with changes of flight level
3.3.2.3.2 Agent-environment
Regulation
The network manager is not responsible for its (their) application. It will continue to
41 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
operate under 'first-planned-first-served' principles, although ATFCM adjustments
may be made to allow for revised aircraft requests.
Passenger
demand
Not present
Fuel price
Not present
Weather
Affects available routes and flight levels
ATM network
The network manager coordinates the network
Table 28: Case Study 3, AG.01 Agent Environment
3.3.2.3.3 Objects
As a coordination agent, the network manager does not have any proper objects. All the necessary
information is obtained either from the context or from its attributes. Note that all flight plans are an
accessible part of the network manager's context.
3.3.2.3.4 Processes
Process name: Electronic flight plan calculation
Process code: AG.03.PR.01
Trigger: This process will be triggered by AG.02.PR.02 Cost Index/re-route calculation
Description:
At the beginning of a flight, the airline will inform the network manager of the pre-activation of a flight,
with its respective intended speed. This process will also take place upon a change of intended
speed. In this process the network manager will proceed and calculate the route and timing of the
trajectory.
Based on the flight plan introduced in the NOP before departure, the network manager will calculate
an expected time over the IAF and assign a CTAp.
If the flight has not been activated, this process will trigger process AG.03.PR.02 AFTM process.
If the flight is already activated, this process will trigger process AG.03.PR.03 Tactical changes
approval .
Process name: AFTM process
Process code: AG.03.PR.02
Description:
Once the electronic flight plan has been calculated, the network manager will perform the AFTM
function. This process will ensure that the aircraft trajectory does not overload any of the sectors. A
capacity limit will be set for the sectors studied, and calculated take-off times (CTOTs, or ATFM slots)
will be issued as necessary to maintain airspace demand under maximum capacity.
This process also occurs when an airline makes a pre-tactical change (before activation).
After this process takes place the network manager will update the NOP and inform the relevant
sectors (including the airport agent) of the new estimates.
If no changes are necessary to the flight, this process will trigger process AG.01.PR.01 Incoming
traffic update.
If the flight needs to be assigned a restriction, this process will be linked with process AG.02.PR.02
Cost Index/re-route calculation.
Process name: Tactical changes approval
Process code: AG.03.PR.03
Description:
The network manager will have to deal with tactical changes to the flight plans. In this case, the
network manager will check the sectors studied for capacity limits. Since one of the objectives is to
understand the impact of DCI on the air traffic sectors, different reactions of the network manager
42 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
upon tactical changes will be designed in order to be able to quantify the effect of those DCI. The
acceptance or rejection will be incorporated into the airline process AG.02.PR.02 Cost Index/reroute calculation. In the case of approval, the NOP will be modified as requested by the airline.
If no changes are necessary to the flight, this process will trigger process AG.01.PR.01 Incoming
traffic update.
If the flight needs to be assigned a restriction, this process will be linked with process AG.02.PR.02
Cost Index/re-route calculation.
3.3.2.3.5 Local Goals
The network manager has a primary goal; to reduce congestion to the maximum possible value,
making the best use of the available capacity, whilst ensuring safety and lack of bias throughout the
network. As a secondary goal, the network manager shall avoid any preferential treatment between
the users.
3.3.2.3.6 Instances
Note that in contrast to other agents, there is only one instance of the network manager. The
European network manager is the Central Flow Management Unit (CFMU) operated by
EUROCONTROL. CASSIOPEIA deliverables D2.7 "Data requirements report" and D3.3 "Model
Dataset" will investigate the data requirements and possible sources.
3.3.3 Agent-environment Definition
As in case study 1, the agent-environment is a common object for every agent. It provides access to
the information necessary for their processes. This information is also called the contextual
information, and is primarily determined by, but not limited to, the Network Operation Plan (NOP).
The contextual information is not part of the agent itself, but a common resource shared to some
extent by all the agents. Some agents may be able to modify this information, while others can only
read part of it.
3.3.3.1 The Network Operation Plan
The main objective of the Network Operation Plan is to provide an updated image of the status of all
flights currently flying and planned. There are two key questions when describing the NOP: First, what
is the precise information contained in this context; and second, how can the agents access this
information.
3.3.3.1.1 Information
This network operating plan comprises the latest scheduled information and it is meant to be up to
date at any given time. For each flight, it contains a record of fields such as: ID, carrier, departure and
arrival times, and airports, type of aircraft, CTAp, etc. Changes in the fields of the NOP may trigger
different processes, such as changes in CTAp’s.
ID
Carrier
Departure
Airport
Departure
Time
Arrival
Airport
Arrival
Time
Aircraft
Status
Route
3.3.3.1.2 Access
Access to the network operation plan is limited by the class of the agent. It has to be thought of as a
common shared resource with asynchronous access. Some agents may be able only to query
information regarding to their own records. Meanwhile, some other agents may be able to modify
some fields. This modification should always be made with extreme caution and always respecting
the flights-slot correspondence.
The complete set of details will be defined in the following CASSIOPEIA deliverable, D2.2 ATM
Network Models.
43 of 44
E.02.14
2.3 CASSIOPEIA Agent Models
Edition: 00.00.03
4 References
Reference
Bonabeau, E., 2002. Agent-based modelling: methods and techniques for simulating human systems,
Proc. Nat. Acad. Sci. USA 99 (3), 7280-7287.
Castelli, L., Pesenti, R., Ranieri, A., 2010. The design of a market mechanism to allocate air traffic
flow management slots, Transportation Research Part C, doi:10.1016/j.trc.2010.06.003 (on-line preprint).
Cook, A. and Tanner, G., 2011. A quantitative exploration of flight prioritisation principles, using new
delay costs, Journal of Aerospace Operations (accepted for publication; doi unavailable)
Cook, A. and Tanner, G., 2011. European airline delay cost reference values, University of
Westminster, for EUROCONTROL Performance Unit, March 2011.
Cook, A., 2011. How will ATM implement future flight prioritisations? Air Traffic Technology
International Showcase 2012 (September 2011), UKIP Media and Events Ltd.
Cook, A., Tanner, G., Williams, V. and Meise, G., 2009. Dynamic cost indexing - managing airline
delay costs, Journal of Air Transport Management, 15(1) 26-35.
Delgado, L. and Prats, X., 2011. Simulation of airborne ATFM delay and delay recovery by cruise
speed reduction, First SESAR Innovation Days, Toulouse.
European Commission, 2004. Regulation No 261/2004 of 11 February 2004 establishing common
rules on compensation and assistance to passengers in the event of denied boarding and of
cancellation or long delay of flights, and repealing Regulation (EEC) No 295/91.
Ferrar, T.A., 1974. The allocation of airport capacity with emphasis on environmental quality,
Transportation Research 8(3), 163-169.
Franklin, S and Graesser, A, 1996 Is it an agent or just a program? A taxonomy for autonomous
agents. In Muller, J, Wooldridge, M and Jennings, N (eds.), Intelligent Agents III. Agent Theories,
Architectures, and Languages (Lectures Notes in Artificial Intelligence, 1193). Berlin: Springer, pp. 21-35.
International Civil Aviation Organization, 1990. Rules of the Air, Annex 2 to the Convention of
International Civil Aviation, ninth ed., (3.6.2.2(b): Variation in true airspeed).
LeBaron, B., 2001. Evolution and time horizons in an agent-based stock market, Macroeconomic
Dynamics, 5(2), 225-254.
Lulli, G. and Odoni, A., 2007. The European air traffic flow management problem, Transportation
Science, 41 (4), 431-443
Morrell, P. and Lu C. H.-Y., 2000. Aircraft noise social cost and charge mechanisms – a case study of
Amsterdam Airport Schiphol, Transportation Research Part D: Transport and Environment 5(4), 305320.
Odell, J et al., 2003, Modelling agents and their environment. In Giunchiglia, F, Odell, J and Weiß, G
(eds.), Agent- Oriented Software Engineering III (Lecture Notes in Computer Science, 2585),
Bologna, Italy. Berlin: Springer, pp. 16--31.
Prats, X. and Hansen, M., 2011. Green delay programs - absorbing ATFM delay by flying at minimum
fuel speed, Ninth USA/Europe air traffic management research and development seminar, Berlin.
Tesfatsion, L., 2002. Agent-based computational economics: growing economies from the bottom up,
Artificial Life 8 (1), 55-82
Upham, P., Raper, D., Thomas, C., McLellan, M., Lever, M. and Lieuwen, A., 2004. Environmental
capacity and European air transport: stakeholder opinion and implications for modelling, Journal of Air
Transport Management 10(3), 199-205.
Zambonelli, F et al., 2003, Developing multiagent systems: the GAIA methodology. Transactions on
Software Engineering and Methodology 12(3), 317--370.
44 of 44