VI.

Airport Operational Database:

AD-1 The system must allow, based on the data, to manage
programming of the airlines and the planning of the
airport resources associated with the operations to be
carried out with following information:
 Airport information enroute, selectable by
ICAO/IATA code airport.
 Obtain information from aircraft
operators, selectable by the ICAO/IATA
code of the airline.
 Obtain data from the aircraft operated at
the airport, selectable by the ICAO/IATA
code of the aircraft.
 Details of specific configurations
selectable by number registration of the
aircraft.

AD-2 The should be able to configure aircraft with

Manufacturer, Series, Model, Registrations, owner,
operators etc.
AD-3 Flight schedules can be incorporated into the system
from airlines or air navigation entities by SCR
messages following the IATA standards set out in
Chapter 6 of the SSIM manual.
AD-4 AODB must have portal interfaces (customer
interface) to import flight information (seasonal
calendar or daily updates) of airlines, ground support
companies and / or government agencies and
approval process from authorized personnel from
CAAN or Airports
AD-5 There should be a feature for the management of the
operation of the planning of seasonal flights as of the
daily flights, and allow to:
 Generate the schedule of seasonal
flights.
 Manage the allocation rules based
on priorities so that the system
automatically allocates the
necessary resources for each
operation.

AD-6 The system must allow management of flights that do

not come from the seasonal schedule, such as

92
 unplanned airline flights, military flights, aero-
ambulances, corporate flights, trainings, etc.

AD-7 Users should be able to make adjustments to the

planning imposed by day-to-day incidents, such as
cancellations, delays, detours, route changes and
others. This information that can be provided by the
airline through ICAO/IATA messages, must be
processed and automatically incorporated into the
system.

AD-8 Through this module it must be possible to automate

the assignment of the different elements that can be
used during an operation, such as boarding gates,
luggage belts, etc.

AD-9 System should have the ability to manage the

additional data to the operation, which will influence
the subsequent check-in process, such as passengers,
times of use of the equipment, refueling of fuel, etc.
AD-10 It must have a tool for generating scenarios, or
simulations (analysis "what if"), whose objective is to
anticipate the availability of airport resources based
on certain simulated conditions: new operations,
changes in the schedules of the same or works in the
infrastructures of the airport that affect the resources.

AD-11 The main ODA module should include different sub-

modules, clearly identified, to:
 The configuration and
parameterization of the General Data
of the Airport.
 The management of the operation of
the planning of seasonal flights as of
the daily flights.

AD-12 The parameterization submodule, among others,

should allow to configure parameters of:
 Cargo Units
 Mail Unit
 Types of fuel
 Minutes of Arrival and Departure
Delay independently.
 Minutes of Control of Collection first
suitcase.
 Taxi time by default.
93
  Minimum time of stay in parking
position.

AD-13 As for the resources of the Airport, the submodule of

parameterization should allow to configure among
others:
 Types of Airports (domestic or
international)
 Types of Schedules (Peak Time, Not
Peak)
 List of airports with IATA and ICAO
codes, Name, city, state, and country.
 Runways of the Airport.
 Terminals.
 Parking Positions.
 Check-in/ check-in counters.
 Baggage Claim Straps.
 Boarding Gates.

AD-14 It should allow to configure the seasons established

by ICAO/IATA in reference to the summer and
winter season, with the dates marked in the
ICAO/IATA World Slot Guidelines (WSG).

AD-15 The AODB will need to be integrated with the

Resource Management System (RMS), Flight
Information Display (FIDS) and Billing modules.
This integration must be in "native" mode i.e., it will
not necessarily require going through the integration
platform.

AD-16 AODB, through the Integration Platform, should

exchange information with at least the following
systems:
 Common Use Passenger processing System
(CUPPS)
 State of counters and doors (open, closed),
flight closure, number of passengers.
 AODB- BHS (Baggage Handling System)
and BRS (Baggage Reconciliation System)
 Flight Information, Planning, Changes and
assignment of parking positions of aircraft
and luggage etc.
 BHS - AODB: First / last luggage etc.

94
  AODB – FDPS/AMHS: flight information,
planning, changes etc.
 FDPS/AMHS – AODB: landing clearance,
aircraft number, hours landing and take-off
etc.
 The exchange of information between AODB
and ATC System.
 Corresponding website: flight related
information
 Mobile app: flight related information

AD-17 AODB, through the Integration Platform, should

receive information at least as
 Information on movements and schedules
(estimated time of arrival / departure, etc.), the
seasonal forecasts of the companies, the
number of passengers, etc.
 Flight plan, information on take-off, arrival
and departure aerodromes departure and
destination, NOTAMS, etc.
 External weather information: weather
information on the origin and destination of
the flight
 Message Format: ICAO recommended Type,
Type B Message and XML

AD-18 The AODB, through the Integration Platform, must

provide, real time flight information related to the use
of contact doors boarding or remote positions to the
different parties: Companies, airlines, ground support
companies, etc.
Specifying, for example, the time of boarding, the
arrival time of bus to the remote position as well as
the following data:
 Flight Code
 Boarding gate
 Remote position
 Scheduled date and time
 Date and time of the effective operation
 Date and time of boarding bridge availability
 Date and time of availability of land vehicles
 Number of land vehicles

AD-19 AODB shall have to generate Pre-billing information

that will record the following:

95
  Domestic flight contact position
 First 30 minutes or half-hour or fraction of an
hour additional
 Related services
 Water, internet, and electrical services
 Remote position of air conditioning
 Land transport of vehicles
 Disembarkation of land vehicles
 International flights
 Contact position
 Use of track lights (markup)

AD-20 The AODB must provide, on time information on

aircraft type (ICAO code) flights and the type of
aircraft (ICAO code and domestic, international
code) including boarding points or remote parking
positions to prepare for departure or take-off, for each
departure flight, information on the passengers on
board, the distance travelled and the type of flight
(national, international). This information shall be
sent to the billing system.

AD-21 The solution must make it possible to simultaneously

manage several airports as centralized configuration.
This solution must be based on:
 Common platform environment.
 Unique databases and tables consolidating
information from flight, etc. centralized
airports.
 Unique reference data for centralized airports.
 Configuration data and configurable
operating rules potentially different by
airport.
 Views, masks, screens, color codes, etc.
configurable potentially different by airport.
 A dynamic reconfiguration of access rights
through different airports. Some users can
access multiple airports, while others are
limited to airports.
 Flight reports at an airport can be used to
determine flight reports at another airport
managed by the same solution.
 A consolidated data warehouse containing the
data from centralized airports, allowing

96
 dashboards general, without multi-database
queries being required.
 The multi-airport configuration must be able
to be fully managed at distance, and
dynamically. For example, adding rules
operations, or new resources at an airport
should not impact other airports, and must be
able to operate without having need to reboot
the system.

AD-22 Authentication and access control:

 The system should use same connection
mechanisms of AODB username and a
password.
 The system must allow a system administrator
to restrict user access to any component of the
system.
 The system must allow user authentication
and access to resources through LDAP and /
or the active airport directory.
 The system must allow the definition of roles
and / or associated profiles security levels and
access rights.
 The system should provide control
mechanisms for access to data stored in the
database, to create, query, update, erase data
and tables accordingly profiles of end users
and technicians.
 The system should provide for the possibility
of activating audit mechanisms for data and /
or tables.

AD-23 End user interface:

 The system should provide an end user
interface based on the use of user-friendly
windows.
 The system must allow the use of filters on the
screens of the different system modules.
 The system must use and be compatible with
IATA, ICAO codes for airport codes,
countries, cities, airlines, types of aircraft.

AD-24 The AODB shall provide essential information for the

proper functioning of the internal processes of the
airport, as well as processes associated with airlines,
ground support companies and airport organizations.
97
AD-25 The interface graphic (GUI) will allow an authorized
user to add, modify or manually delete fields
associated with a flight. The screens (forms) will
facilitate the entry of all data, no data will be saved
directly in the data tables without verification by the
system.

AD-26 The system must be intuitive and easy to use

(interface-based configurable graphic). It must
support client technology lightweight to ensure the
mobility of the airport.

AD-27 AODB should capture and store relevant data for its
functioning from internal and external systems. The
sources of data can be:
 Manual update by airlines, ground support
companies or airport authorities directly from
limited portal accessible to them.
 Automatic update by airlines, airlines ground
handling companies or airport authorities (to
be through processes such as Excel sheet
loading containing updates, etc. ...)
 Updated through ICAO/IATA messages or
any other program such as SITATEXT/Type
B Message
 Updated by airport staff.

AD-28 AODB shall be able to centrally enter, store and

maintain all relevant master data. This shall include
but shall not be limited to:
 Customer master data (i.e., airlines, flight
schools)
 Aircraft master data (i.e., aircraft type,
specific aircraft data)
 Airport master data (i.e., origin/destination
airport countries, zones and specific airports
with clear name IATA and ICAO code)
 Resource master data (parking positions,
piers, check in counters, baggage belts,
resource times)
 Billing master data (tariffs, condition rules
and prices)

AD-29 Passengers on arrival and departure must be

registered for each flight, broken down at least into:
98
  Paid passengers.
 Children
 diplomats
 Other tax-exempt passengers
 Passengers in transit
 PMR passengers (reduced mobility using an
access with assistance and wheelchair)

AD-30 The system must provide a user-friendly interface for

creating and the management of business and
operational rules, without programming and without
contacting the suppliers.

AD-31 Flight recordings must be kept active for 90 days at

least. A long-term data storage system should be set
up, in which the archiving of data that are no longer
active and facilitating access to information.

AD-32 AODB should handle daily and seasonal flights.

 Seasonal Flight Planning
 Unlimited number of flight seasons
 Unlimited periods per season
 Import functionality to import from flight
plan coordination or airline systems.
 Daily Flight Planning
 Automatic generation of daily flight plan
from flight plan
 Easy means of entering ad hoc movements
(general aviation, search and rescue
operations)
 Support user to enter timestamps like ET/AT
by creating timestamp.
 Support user to enter master data references
like registration, airport by auto completers
and search functionality.
 Plausibility check for all master data fields
(i.e., PAX number plausibly for aircraft)

AD-33 The system must allow several operators to access the

same data simultaneously. Data refresh and
synchronization must be done entirely in real time,
without any intervention of the user.

99
AD-34 The system must provide an undo /redo function users
to test a feature and return to the state before if
necessary.

AD-35 The system should help detect any irregular situation

occurring in an airport and likely to have negative
repercussions on the downstream processes and
service levels and must help to result. It must be
possible to visualize these situations on dashboards in
real time. These dashboards must be configurable by
authorized airport users. This functionality must be
achieved either within the AODB or within the
Resource Management System (RMS).

AD-36 The following information is required at least for

airport operations:
a) Nature of the flight
 Address (country of arrival / departure
number)
 Type of flight (planned, charter, cargo,
military, general aviation, ambulance .... etc.)
b) Information posted for the airline.
 The name of the airline (ICAO/IATA)
 Airline code share code (ICAO/IATA)
c) Name of airline
 Abbreviated name of the airline
 Name of airline
 Other name of airline
 Airline company membership group (if
applicable)
 Airline Marketing Alliance, If applicable
d. Flight information
 flight number
 Flight exploitation number
 Code share code flight (s)
e. Flight time
 Date and time of scheduled flight (arrival /
departure) (schedule)
 Date and approximate time of arrival /
departure flight (ETA / ETD)
 Actual date and time of arrival and departure
of the flight (Touchdown and Take off)
 Actual date and time of the aircraft station and
its exit of parking
f. Route information

100
  Destination - Channel 1, Channel 2 Channel
3 (IATA standard - upstream of three previous
cities)
 Origin - 1.2 of 3 (IATA standard - up to three
cities downstream)
g. Aircraft Information
 Aircraft type and series (ICAO/IATA)
 Aircraft subtype (ICAO/IATA)
 Other type of aircraft
 Aircraft number
 Maximum take-off weight (MTOW) of the
aircraft
h. Location and resources of the flight
 Terminal identification
 Terminal name
 Gate assigned.
 Previous gate assigned.
 Closing time of the door
 Door opening time.
i. Information on ground assistance
 Handling Identification / Ground Service
Company
 Other identification of service providers
 Food Delivery (Yes / No) (Catering)
 Flight season start date.
 Flight season end date
 Other areas (airline, aircraft type, etc.)

AD-37 The system must allow the establishment of flight

schedules seasonal and pre-allocation of resources
over the coming seasons.

AD-38 The system must have automatic or manual

mechanisms for entering and recording seasonal
flight schedules from external systems, with different
types and file formats.

AD-39 The system must generate daily information on

flights from seasonal flight schedules.

AD-40 Each flight movement must be considered as a unique

record in the system, regardless of the planning. The
management of a flight in real time must not lead to
any loss of functionality at any time in the future or
the past (where a cancelled flight does not cancel

101
 scheduled flights in the base for rest of the season,
etc.).

AD-41 The system must allow the daily operation and

movement of aircraft and resources, whether
automatic or manual, based on information available
and received from the different internal systems.

AD-42 The system must allow the recording and

management of flights not from seasonal schedules,
such as unplanned airlines, general aviation flights,
etc.

AD-43 The system must be able to adjust the daily planning

of incidents, such as cancellation, delay, variances,
changes itinerary, etc.

AD-44 The daily operational programming must contain at

least the following information:
 Scheduled arrival or departure times.
 Real flight gates.
 Carousels / tracks for arrival flights.
 First and last baggage delivery for arrival
flights.
 Aircraft types and categories.
 Registration numbers
 Positions of stationing the aircraft.
 Flight status.
 Irregular operations for the flights to be made,
return to the block, diversion, and
cancellation.
 Number of passengers by man, woman, child.
 Number of passengers for flights and by class
of service.
 Number of passengers exempt from tax.
 Counting passengers requiring special
assistance for flights and type of assistance.

AD-45 The system must be able to manage the information

from the transponders of the aircraft, collected
through a system of Mode-S / ADS-B receivers.
The integration with this sub-system shall be done
through web services.

102
AD-46 Of those aircraft that comply with the ADS-B
standard, the identification of the flight number
and/or Call Sign must be tracked.

AD-47 The following time tags and time tags must be

automatically recorded in the AODB:
 Date, time, and minute of landing / take off.
 Time elapsed from Landing / Take Off to
abandon / enter runway.
 Date, time, and minute of departure/entry by
taxiway (apron)
 Elapsed time from exit /entry in taxiway to
parking position.
 Date time and minute of Arrival /
abandonment of parking position, which can
be considered as time of On Block / Off
Block.

AD-48 Records must be processed and stored in the AODB

for subsequent check-in to the airline based on the
parameters established in the contract.

AD-49 The Airport Management system must have a

predictive module. This module should compare the
history of operations of the last 5 equivalent seasons
(Summer / Winter) along with the planning of the
next season. Of the result, the predictive module must
 Give the indicators of the expected occupancy
of passengers with expected percentage of
cargo on the declared seats.
 Forecast of delays.

AD-50 Prediction of Pax Flow in the different areas of the

terminal by hourly sections in the following areas:
 Billing Area.
 Security Checkpoints.
 Immigration.
 Boarding Area.

AD-51 Reporting:
 The system should provide the standard
reports list that include all reports required in
general year cycle and for general auditing
propose.

103
  The system should allow the editing of reports
by hour, daily, weekly, monthly, and yearly.
 The system must enable the recording,
traceability and generation of summaries
associated with performance data such as:
number of messages per interface (sending
and receiving), number of messages for a
period of (sending and receiving), number of
errors, number of connections.
 All reports must be accessible in text and / or
in the form of graphics.
 All reports must be exportable into text,
Excel, XML or pdf files.
 These reports must be able to be automatically
generated at intervals regular configurable by
standard tool, with file server backup.
 The reporting solution must work in real time
and KPI (aircraft punctuality, etc.).
 The system shall be display synchronized
Gantt charts and dashboards on up to 4
separate screens with the ability to display
separately defined resources on separate
screens.
 The schema of the Data Warehouse database
must be published and extensible.
 The system must be able to maintain an Audit
trail of all changes to system data.
 Able to generate various reports. Example:
OTP report; Delayed flight report for both
arrivals & departures on daily or weekly or
any other definable intervals on need basis.
 Able to select the output of the reports (table,
chart type, colors, etc.)
 Able to generate customizable reports.
 Heavy usage of the reporting solution should
have no impact on the operational systems
(AODB etc.)

AD-52 Dashboard Tools

 The system shall provide interactive
dashboards that can present users with a
graphical view of ACI airport KPIs, measures
and metrics.

104
  The system must be able to provide
dashboards and analytics for use on a mobile
device.
 System shall contain a dashboard view of the
current resource plan, current KPI
performance, all upcoming tows, all rule
violations, all warnings, notifications, and
cancelled flights on one screen.
 The system shall provide dashboard with user
customizable widgets to monitor operational
KPIs and widgets, maintaining full situational
awareness with respect to KPI performance.
Users with sufficient access credentials can
setup the multiple Dashboards to track
various pre-defined KPIs.
 Users shall be able to create new Dashboard
as and when required.

AD-53 Daily/monthly Aircraft Movement, Pax movement,

cargo, sector/time wise, aircraft occupancy rate, and
other required by CAAN record should be maintained
as per the requirement of airports individually and in
consolidated form.
The data source shall be other system where
application otherwise data entry portal should be
available.

VII. Resource Management System (RMS)

No Requirement Compliance Supplier
(Full/Part/Non) Remarks
RM-1 The RMS system is the platform by which the
different airports resources are managed, planned and
allocated, such as embarkation, luggage conveyors,
aircraft parking slots, etc. The module should be
available in the system.

RM-2 The RMS system must provide the necessary

functionalities to allocate resources to flight
schedules based on one or more rules that represent
the mode of operation of an airport.

105
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
RM-3 The RMS must allow to manage airport resources in
a comfortable manner with a graphical environment
that includes the possibility of allocating resources
through a simple "drag and drop".

RM-4 If the AODB has not been able to automatically

allocate a resource, the RMS must automatically
create virtual resources, clearly differentiated by
another color and located at the top of the screen, in
which it will leave the assigned operation without a
physical resource, so that the operator performs the
assignment manually.

RM-5 It must allow the user to customize the work

environment through different colors, being able to
assign a specific color to an airline, to facilitate the
identification of operations.

RM-6 The RMS must allow to perform the following

functions:
 Resource occupancy blocks.
 Creation of aircraft earthworks.
 View in historical mode.
 View of the planning of future days,
by entering dates.
 Automatic allocation of resources
using the rules defined in the AODB.
 Access to ICAO/IATA messaging.
 Modification of the schedule of an
operation.

RM-7 The Airport Management system must include a

graph module in the plant, in which the operator can
see in a synoptic plane the resources of the AODB
and make queries of the operations assigned to each
resource.

RM-8 This module should allow the system administrator to

include drawings by terminals and areas.

RM-9 On the drawings, user should be able to configure the

resources and it should be automatically integrated
with the codes established in the AODB Database.

106
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
RM-10 By means of color coding, it should indicate whether
the resource is free or busy and should give
information about the assigned operation, as well as
the next planned operation.

RM-11 The RMS system must operate fully in real time with
the AODB.

RM-12 The RMS system should be centrally manageable and

accessible from the multiple airport terminals.

RM-13 The architecture of the RMS system should allow a

centralized definition of users and roles, with the
ability to configure different levels access to
applications and data.

RM-14 The RMS system must be easily scalable and

configurable, especially in the case of an addition or
a removal of services (new screens, new type of
information or new sources of data to be monitored).

RM-15 It must be possible to modify the list of resources and

their characteristics by working in the planning and
in real time without restarting the application.

RM-16 The RMS system must make it possible to create

"what if" scenarios in parallel with his operation.

RM-17 The RMS system shall be configured to meet the

requirements operational requirements and
performance requirements of multiple users
connected simultaneously in the multi-airport
platform system.

RM-18 The RMS system should allow simple and efficient

management of airport resources with graphical
environment including displaying Gantt charts and
allocating resources by drag and drop.

RM-19 The solution must make it possible to quickly find a

flight in a list or a Gantt chart, using any element
describing its characteristics (origin, destination,
aircraft type, registration, transporter, ground
assistance provider, etc.)

107
No Requirement Compliance Supplier
(Full/Part/Non) Remarks

RM-20 The solution must allow to filter the Gantt charts for
display only resources with certain characteristics as
well as certain types of flight assignments. E.g., cargo
planes and posts cargo, or international aircraft and
movements International.

RM-21 The solution must allow an allocation of resources

entirely manual, semi-automatic and fully automatic.

RM-22 The system must be able to receive LDM and MVT

messages and display the information in a graphical
form on a dashboard.

RM-23 All data managed by the RMS interface must be

stored in the AODB database.

RM-24 The operator of the RMS system must be able to

allocate / decommission flight resources.

RM-25 Resources included in the resource management

system should be, as a minimum:
Aircraft parking slots.
Boarding and disembarking gates.
Baggage carousels.
Check-in counters and / or check-in stations (tables,
kiosks, zones)
Aircraft towing vehicles
Bus for passengers and cabin crew.

RM-26 The RMS system must allow the following:

allocation / distribution of human resources,
equipment and infrastructure for management and
operation of the airport resource reservation blocks
creation of aircraft ground movement visualization of
the planning of future days, by entering the dates,
automatic allocation of resources using rules pre-
defined, access to ICAO/IATA messaging through
the integration platform change of program of an
operation.

RM-27 Resource management:

The RMS system must allow the allocation of specific
resources.

108
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
The RMS system must be able to generate scenarios
to allow the optimal choice to the operator.
The RMS system coupled with the AODB must be
ready to operate in an A-CDM environment

RM-28 RMS system should help define rules and priorities

associated with resource allocation.

RM-29 The solution must allow to fully configure the delay,

standard separation between two consecutive
assignments of the same resource, considering all the
known characteristics of departure or arrival flights.

RM-30 Towing must be clearly identifiable in the diagram. It

must be possible to modify the towing directly from
the Gantt chart and enter planned and actual times as
needed.

RM-31 The RMS system must allow the definition of times

and dates (start and end) for the different rules
defined.

RM-32 The RMS system must allow the declaration of

resources such as not operational or unavailable,
considering a resource individual, by resource group
and / or period.

RM-33 The RMS system should make it possible to define

the maximum capacities of resources to consider in
the allocation process.

RM-34 The check-in desk management system must allow:

The number of counters allocated according to the
characteristics.
 Managed flights.
 Common check-ins
 Possibility of assigning multiple separate
counters to all or part of flights including code
sharing or flight movement.
 Possibility of assigning specific counters to
classes of different passengers.

RM-35 Planning, restrictions and conflict management:

109
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
 RMS should allow users to identify and create
their own restrictions and define the rules.
 RMS should provide automatic conflict alerts
stations. Including conflict resolution
functions.

RM-36 Simulation and scenario management:

 The RMS system must allow the generation
of scenarios allowing to simulate resource
management.
 The RMS system must have a scenario
generation tool, or simulations, the objective
of which is to anticipate the availability of
resources according to certain simulated
conditions:
 New operations or stop operations.
 Schedule changes
 Airport infrastructure works affecting
resources.

RM-37 Stands/Bays:
 The user shall be able to maintain stand/bay
rules that specify which aircraft are allowed
for each resource.
 The user shall be able to specify any
constraints for using stands/bays. E.g., certain
aircraft types cannot be parked together or
must be allocated to a specific location.
 The user shall be able to maintain preferences
for using stands/bays. E.g., airlines specific
agreements for stand/bay usage and buffer
times.
 The user shall be able to create overlapping
stands. E.g., where a bay can take different
configurations depending on the type of
aircraft.

RM-38 Gates:
 The user shall be able to define which gates
(arrival and departure) are allocated to a
stand/bay. Note: Gates and bays can have
different numbers.

110
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
 The user shall be able to maintain preferences
for using gates. E.g., airlines specific
agreements for gate usage.
 The user shall be able to allocate a gate to a
bus departure point.
 The system must allow both arrival and
departure gates.
 The user shall be able to control the activation
or deactivation of gate display screens.
 Airlines shall be able to manage the control
and content of gate displays allocated to them.

RM-39 Baggage Reclaim:

 The user shall be able to maintain reclaim
rules that specify which reclaim belts are
available for each arrival.
 The user shall be able to specify constraints
for using baggage reclaims.
 The user shall be able to maintain preferences
for using baggage reclaims. E.g., Using
reclaims belts in a specific order to avoid
congestion or comply with airline specific
preferences.
 The system must be able to support a single
aircraft using multiple reclaim belts and
multiple aircraft using a single reclaim belt.
 The system should be able to support the
recording of first bag/last bag operations.
 The system could have the ability to calculate
baggage unloading progress so that this can be
shown on display screens.

RM-40 Counters (Check-in):

 The user shall be able to maintain counter
rules that specify which check in desks can be
allocated for departure flights.
 The user shall be able to maintain preferences
for allocating counters. E.g., Assigning airline
counter preferences in priority order.
 The user shall be able to specify lead time for
a counter. E.g., the number of minutes before
the flight departs that the desk will close.

111
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
 The user shall be able to specify the duration
that the counters are allocated by airline.
 The user shall be able to override counter
allocation to suit operational requirements.
 The user shall be able to control the activation
or deactivation of check-in display screens.
 Airlines shall be able to manage the control
and content of counter displays allocated to
them.
 The system should be able to smart allocate
counters based on number of passengers.

VIII. Flight Operation Management

No Requirement Compliance Supplier
(Full/Part/Non) Remarks
SM-1 The system should have airline operation certificate
(AOC)/renewal management module as per CAAN
policies and practices.
SM-2 The system should have aircraft
registration/deregistration and renewal module that
have registration/renewal request and approval
process as per CAAN policies and followed practices.
SM-3 System should have option to register, deregister,
renew and flight permission request and approval for
the other aircraft such as Ultralights, Parachutes,
paragliding, drones etc.
SM-4 The system must have module to manage flight
permissions process as per CAAN policies and
practices.
SM-5 The system must be integrate with financial core
mode to assist with required information for approver
before approved registration/deregistration/renewal
of aircraft. For example mandatory checklist met or
not, all dues cleared or not, safety auditing
requirement met or not etc.
SM-6 The system must be able to record student/trainee
approval and recommendation management.
SM-7 System must be able CPL, ATP examination, pilot
skill management etc.
SM-8 The CAAN has to manage aeronautical technical
manpower (Pilot, Flight Operation Officers, Aircraft

112
 Maintenance Engineers etc.), their license,
certificates, heath fitness records, flight hours etc. as
per CAAN policies. The system must be able to
manage such operation and approval process as per
CAAN business process.
SM-9 Flight Operation management module shall be
integrated with AODB, and Financial Management
Module.
SM-10 System should have computer based examination
and manual screening test records, fitness test
records options etc.
SM-11 Technical manpower List, License Expiration Report,
Renewal Alerts, Individual License Reports, etc.

IX. Engineering Service

No Requirement Compliance Supplier
(Full/Part/Non) Remarks
EN-1 The responsibility of engineering
Department/division is to procure, manage, maintain
all the Engineering equipment at all airports, offices,
and project sites. The system must have a module to
help the department to manage their jobs in the
system like quality assurance of purchased goods,
timely repairs, and maintenance of equipment,
always ensure availability of important spare parts,
etc.

EN-2 All engineering departments shall be able to maintain

Tasks that they carry out within the system. These
tasks can have many sub tasks as well. When creating
these tasks, it shall be possible to add the required
skills, time factors as well as to materials. The system
shall be able to manage the dependencies between all
steps. Therefore, the timelines for Service Order
(SO)’s can be estimated from the system itself.
EN-3 When an equipment is purchased, system should
automatically create the asset card with detailed
information like serial information, manufacturer
details, service details, technical details. Etc.

EN-4 The purchase module should be directly integrated

with the finance module for automated accounting
entries and payment processing.

113
No Requirement Compliance Supplier
(Full/Part/Non) Remarks

EN-5 Quality check should be performed for each newly

purchased item. System should have the ability to
create a quality checklist for the item. When the
quality check is completed, user should enter update
the checklist in the system. Only on passing the
criteria defined, system should allow to use the asset.
Otherwise, process for returns or repairs should
initiate.

EN-6 The module should allow to create list of all

assets/equipment’s that is managed by the division
that needs regular as well as random basis servicing
and repairs. Each asset should be uniquely identified
in the system.

EN-7 There should be a feature to import service schedules

for each asset. System should provide reminders for
service based on this schedule. The completion of
regular service should also be tracked with this
service schedule.

EN-8 System should have a feature to attach service

manuals as electronic documents or scan copies of the
manual for future reference.

EN-9 List of spare parts and their specification should be

maintained for each asset.

EN-10 Due to the emergency nature of services provided by

engineering divisions, there will be a store located for
each division. Therefore, the system shall be able to
manage more than one store. It shall be possible to
manage these stores as sub stores of the main store as
well as to individually maintained stores.

EN-11 The system shall cater for the generation of Service

Request. SR are created by authorized users. But, for
assets requiring scheduled maintenance, the system
shall generate the SR for that particular asset
automatically.

EN-12 All SR created shall be directed to the necessary

person to be approved. During the approval process,

114
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
a service engineer should also be assigned to that
work order.

EN-13 Service engineers list with their specification should

be maintained separately.

EN-14 The assigned service should be notified through email

and the workorder should show in his dashboard.

EN-15 The assigned service engineer after proper

assessment of the asset, creates a service order with
fault codes, spare parts requirement, manpower
requirement. The created service order should be sent
for approval.

EN-16 Based on the inventory level and requirement,

inventory requisition planning should be available in
the system.

EN-17 Once a fault is reported by an employee, the system

shall notify the relevant personal to take necessary
action to rectify the issue. At this stage, the system
shall suggest actions to be performed which shall be
selected from past records of faults.

EN-18 The SO number shall be generated from the system.

The formation of the numbering system shall be done
consulting each department.

EN-19 If the SO is created without a SR, the system shall be

capable of assigning an asset number to the SO.

EN-20 The system shall give an option for the requester of a

SR to define the due dates based upon urgency of the
matter. This should help engineering division to set
priority for important jobs first.

EN-21 The approver should assign a resource person for

repairs. If the necessary skill requirements cannot be
matched within the current work force of the
company, there shall be an option to hire the
necessary expertise from external entities. Memo
should be generated and forwarded to concern
department for approval.

115
No Requirement Compliance Supplier
(Full/Part/Non) Remarks

EN-22 The system should maintain service person list.

Based on the service orders assigned, service persons
availability should be evaluated, and next service
should be assigned accordingly.

EN-23 Once everything is finalized, the system shall be

capable of creating a costing for the SO. At this stage,
the system shall consider the cost for material and
services as well.

EN-24 A service calendar should be maintained in the

system with planned date for service orders and
resources assigned.

EN-25 All engineering departments shall be able to maintain

Tasks that they carry out within the system. These
tasks can have many sub tasks as well. When creating
these tasks, it shall be possible to add the required
skills, time factors as well as to materials. The system
shall be able to manage the dependencies between all
steps. Therefore, the timelines for SO’s can be
estimated from the system itself.

EN-26 Because the tasks are maintained in the system, at the

time of the SO generation, it shall be possible to
attach these tasks to the SO. By going to step further,
the system shall be capable to identifying similar
SO’s and suggest tasks automatically.

EN-27 Once the Service Order is created, the relevant

engineering division shall be able to request items
from the inventory. For this, it shall be possible for
them to view the current levels of stock and if the
stock on hand is not enough, it shall be possible to
request for a “Not Available Form”. Once this is
approved from the stores section, the “Purchase
Requisition” shall be created using the NAF as the
based document.

EN-28 With the new system, the link between all relevant
documents shall be maintained. Therefore, it shall be
possible for users to move from one document to
another by clicking on the respective document. i.e.

116
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
work order, service order, inventory requisition,
purchase order.

EN-29 Each division shall have the capability to view their

respective SR with the current status. They shall also
have the option of drill down on any document that
they require by clicking on the respective document
number.

EN-30 All management parties shall be able to view reports

which shall contain allocation of resources, time,
costing, etc.

EN-31 Requisition for inventory should be notified to store

user through email and should show in his dashboard.

EN-32 The store person should have the ability to see the
service order details from the requisition order.

EN-33 The store person should be able to issue inventory

using the inventory requisition document.

EN-34 Inventory should be received by the service

department.

EN-35 Before the service is started, service department

should ensure that NOTAM is issued where required
as per ICAO guidelines.

EN-36 When the service is started, service engineer should

update the service order status as started.

EN-37 Upon completion of service order, the status should

be updated as completed and the service order should
close.

EN-38 Inventory quantity and value should decrease and

charged to repair and maintenance expenses of that
particular asset.

EN-39 The completion of service should be notified to the

service requester, service manager and the relevant
division manager of that asset.

117
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
EN-40 After the service is completed, service department
should ensure that NOTAM is closed for the services.

EN-41 Assets that could not be repaired should be marked

specifically and reported to all the related divisions.
Replacement process should begin from here.

EN-42 Detailed Service history should be maintained for all

assets.

EN-43 On service of insured assets, the system should allow

user to process insurance claims for that asset.

EN-44 For assets under warranty, system should report that

the asset is under warranty. Maintenance for such
asset should be procured from the vendor or warranty
claim should be processed from the service order
completed.

EN-45 Reports:
 Pending Work Orders
 Pending Service Orders
 Upcoming Services for Scheduled
maintenance
 Service Plan Report
 Assets under maintenance
 Service History
 Service Efficiency based on work order date
to service completion date.
 Inventory Consumption report
 Inventory Issue Report
 Inventory Availability Report
 Inventory Requirement Plan
 Inventory Movement reports
 Assets Under Warranty
 Insured Assets
 Insurance Claims
 Service Claims for assets under warranty
 Service Calendar
 Service Engineer Performance
 Division wise service report
 External Service Purchased
 Quality Assurance Report

118
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
 Assets Replacement Requirement
 Resources Calendar & Availability Report

X. Integration System (IS)

No Requirement Compliance Supplier

(Full/Part/Non) Remarks
IS-1 The CAAN have diverse system are implemented
with diverse platform the scope of integration shall
include following module but not limited. The
integration shall be part to integrate all system
implemented in contract period.
 AODB, CUPPS, CUSS, AMHS
 Immigration System
 BMIS, DDMS
 Employee Fund Management System
 Drone Registration, Safety Audit, Licensing
System
 FIDS
IS-2 The integration system ensures communication
between heterogeneous applications of airport
facilities. System must be able to send / receive
information to external entities and integrate it into
airport systems using open protocol software to allow
incorporation of application from different suppliers.

IS-3 This module concerns the supply of a complete

interfacing and the integration of all airport systems
providing critical data and offer a standard for the
integration of applications through a secure platform.

IS-4 The AODB must provide the real time information

through the integration system to concern systems of
the various parties involved: airlines, ground
handling companies, etc., Specifying, for example,
the opening time for boarding, the arrival time of bus
at the remote position as well as the following data:
 Flight Code
 Boarding gate
 Remote position
 Scheduled date and time

119
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
 Date and time of actual operation
 Date and time of availability of land
vehicles
 Number of land vehicles
 Parking hours
 The use of the parking position, the
use of land vehicles, electric power
 Remote parking positions to prepare
for departure or take-off
 Boarded passenger information,
distance travelled and the type of
flight (national, international)

IS-5 The Integration System solution will integrate the

continued Multiplatform Airport Operations Systems
but does not limit to the following:
 Airport operational database (AODB) and
Data Warehouse (DW).
 Resource Management System (RMS).
 Baggage reconciliation solution (BRS)
 Flight information display system (FIDS)
 Terminal equipment for common use
(CUPPS), kiosk for common use (CUSS)
 Aeronautical billing
 AFTN / AMHS
 Mobile application (timetable guide)
 Accounting interface with ERP
 FDPS/Radar interface

IS-6 The proposed solution, which will later be integrated

into this architecture, already part of the scope of this
contract.

IS-7 The solutions must be able to integrate applications

built on heterogeneous platforms. This includes all
individual airport applications and systems that must
be integrated.

IS-8 Allow interconnection and exchange of messages and

information between airport systems, device or
terminal based systems, systems associated with
airlines and systems associated with air traffic.

120
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
IS-9 Allow and control the synchronous or asynchronous
transfer of messages and information, allowing to
define the delivery times of the messages, the number
of delivery attempts, etc.

IS-10 Receive and send messages in XML, HTTP, SOAP

formats to and from different systems.

IS-11 Receive and send files via FTP / SFTP from and to
different systems.

IS-12 Receive and send SQL requests, via ODBC, JODBC

connections to and at from different systems.

IS-13 Allow the use of message and information exchanges

using technologies based on WEB SERVICES, SOA,
REST, JSON etc.

IS-14 Allow the exchange of messages and information,

using mechanisms security such as encryption, digital
certificates, etc.

IS-15 Allow the possibility of exchanging messages and

information through translation or data conversion
mechanisms (for example, IATA codes translate into
ICAO code and vice versa).

IS-16 The system should have mechanisms to define and

control routing, sending / receiving and purging of
messages according to different criteria.

IS-17 The system should provide mechanisms and tools to

control, reconcile and debug erroneous or pending
messages, considering identifying the causes and the
measures taken.

IS-18 The system should allow to develop interfaces with

new systems based on API in the delivered platform.

IS-19 The system should provide tools to monitor

connections by real time.

121
No Requirement Compliance Supplier
(Full/Part/Non) Remarks
IS-20 The system should provide possibilities for
notification of the general situation and system status
in real time through the graphical interface.

IS-21 The integration system should be easily scalable and

configurable, in particular to add or remove services
(new screens, new types of information or new data
sources etc.)

XI. Internal Audit

No Requirement Compliance Supplier

(Full/Part/Non) Remarks
IA-1 System shall process all necessary tools and
procedures which are needed for Auditing purpose.

IA-2 The system shall permit Head of IA to access all data

which is input into the system by all the other
Department/divisions may be with pass word control.

IA-3 Head of IA in turn shall be permitted to make

available such information as and when necessary to
the IA staff enabling them to carry out their assigned
tasks.

XII. Detail Hardware/Environment Requirements

Bidder shall propose minimum server, storage and other hardware infrastructure for deployment
and operation including testing environment for next 10 years with justifiable clauses. The bidder
should proposes general specification for the hardware infrastructure without recommending for
any specific component or any specific platform. The system should proposed with active DR
and cool DR solutions. The specification should be a Fault tolerant High Availability solution.
The CAAN IT shall manage hardware and other infrastructure in virtualized and shared basis by
analyzing the requirement of bidder. For the testing or initial live period bidder shall to work on
minimum infrastructure platform provided by CAAN IT.

122