Functional specification – Airport operational database

PROJECT NAME :…………………

IT SYSTEMS PACKAGE – AIRPORT

OPERATIONAL DATABASE
Functional specification – Airport operational database

Table of Contents
 Functional specification – Airport operational database

1. INTRODUCTION

MENTION THE PROJECT INTRODUCTION BRIEF………………………………………….

2. SCOPE

The primary requirement of the system being sourced via this request for proposal is to serve as central
airport operation database for multiple airports as per the system requirements listed down in this
document. The successful contractor/OEM/ system provider shall provide a complete turnkey solution to
meet the minimum specification mentioned here. The system proposed shall be capable of performing
below mentioned key process for multiple airports simultaneously with maintaining isolation of the process
per airport. The following are the key business process

 Flight planning and real time flight management

 Flight Information management & display solution
 Resource Management
 Schedule/Seasonal Flight Import System

In addition, operational support is also required for

 Management Information & Reporting, and
 Systems Management

A centrally maintained database is required for managing the airport operational data along with the
necessary quality of service, i.e. high data quality, reduced resource consumption and more efficient
system and business operations. This will be implemented in the form of an AODB. The information
related to Flights, Flight Displays and Resource Management will reside in the AODB.

This information can be used for the following purposes:

 Effective management of all resources.
 Timely and accurate display of relevant information to management, staff and public.
 Long-term planning.
 Statistical analysis through the integration of 3rd party products.

3. FUNCTIONAL AND TECHNICAL REQUIREMENTS

Functional - Flight Planning and Management

 Flight Management System should have a user Interface application for
creating/updating/deleting Airport Master Data such as Airline Masters, Airport Master, Aircraft
Masters, Resource Master (Check-in, Gate, Stand and Carousal)
 Flight Management System should be able to create flight record
 Flight Management System should be able to do real time daily flight processing
 Flight Management System should be capable of flight plan collection and maintenance by
season.
 Flight Management System should be capable of dynamic flight plan collection and maintenance
for next day’s schedule whereby the period should be set for the particular day.
 Functional specification – Airport operational database

 Flight Management System should be capable of dynamic flight plan collection, maintenance and
dynamic update for day’s schedule.
 Flight Management System should be capable of flight operation of merging, separating and
binding.
 Flight Management System should be capable of managing unusual, non-scheduled or special
flights.
 Flight Management System should be able to collect and maintain information via interfaces to
the system that supply climate weather data, NOTAM, METAR, AFTN and ACARS.
 Flight Management System should be able to highlight the flight status in different colours, for e.g.
yellow for ten mile out, green for taxiing and blue for landing.
 Flight Management System should be able to create a graphical flight and position diagram to
view the current operational status of the flights
 Flight Management System should be able to handle conflicts that could cause delay of flights.
 Flight Management System should be able to provide standard flight related reports that can be
displayed on the computer monitor.
 Flight Management System should be able to join and split the flight rotation.
 Flight Management System should be equipped to handled return taxi, return flights and towing
management.
 Flight Management System should be able to segregate the flights whether flight is operational,
scheduled or training flight
 Flight Management System should be able to store passenger and load information flowing from
airline systems.
 Flight Management System should be able to share the number of aircraft on ground, overnight
stay details.
 Flight Management System should be able to automatically calculate some flight values/remarks
on receiving the respective data.
 All flight updates should be recorded based on the timestamp, old value, new value along with
user details for audit trails.
 Flight Management System should be possible to refresh screen based on data files received
from Air traffic control at frequent intervals of time
 Once the flight is landed/take-off, any changes to flight should not be possible by a normal user. It
can be overridden by admin person.

Functional – Resource Management System and Auto Allocation

 Resource Management System should be able to perform aircraft stand allocation and gate
allocation.
 Functional specification – Airport operational database

 Resource Management System should be able to do check in counter allocation

 Resource Management System should be able to perform baggage belt allocation. System
should be able to handle swing gate/carousal allocation.
 Resource Management System should have the capability of being available in off-line mode.
 Resource Management System should be a rule-based system and should be able to perform
allocations automatically for the resources based on the defined rules. System should permit to
create auto allocation rules based on different- different parameters such as aircraft, sector,
capacity, flight type, peak time/lean time, etc…
 All resources should have a validity window and not available window as well.
 There should be a provision to override the existing rules if need arises. The overridden rules
should be kept in a log.
 Resource Management System should be able to provide real time allocation and monitoring of
locations.
 Resource Management System should be able to analyse the type of check-in counter (occupied
and not occupied).
 It should be possible to analyse the duty times for different airlines.
 It should be possible to configure the resources (technically and geometrically).
 Dynamic editing of airlines (manual input of airline information - basic data) should be possible.
 Automatic counter allocation should be possible based on rules that are easy to change.
 It should be possible to allocate counters manually (modification of results of the automatic
counter plan).

Functional –Management Information System

 It should be possible to print summary and full representations of the schedule.

 System should be able to give the details of aero bridge connect time and disconnect time.
 Various reports which are required for airport functioning such as flight daily operation, On Time
Performance, Delay Analytics, Overnight Stay, Hourly aircraft on ground, Resource
Utilization/Occupancy, Load and Passenger reports etc... Should be available as standard
reports. Other required reports will be defined by airport stakeholders who will be covered as the
part of this scope.
 System should be able to generate the belt efficiency (baggage arrived, and baggage cleared).

Functional – System Integration

 There should be a direct interface to the database for data interchange and handling any
language specific characteristics.
 Functional specification – Airport operational database

 An interface to the ATC should provide the touchdown time and take-off time.
 An interface to AFTN and ACARS should be possible to receive the flight plans, notam, metar,
arrival, departure, delay and cancellation automatically
 Integration with SITA network should be possible to reduce the effort required to handle SITA
telexes such as MVT, LDM, PTM, BSM, etc..
 System should be able to interface with VDGS,BHS,BRS, GPU/PCA and Into Plane System.
 System should be able to interface with Aviation Billing System.
 System should be able to interface it with information Kiosk system to display flight information.
 System should be able to interface with website to send/display flight schedule and flight update
information.

Functional – Seasonal Schedule Management

 Slot management should act as a visual guide for planners, to assess need for incorporating
change in aircraft arrival details, so as to initiate re-planning whenever required.
 Schedule Flight Import System should allow import of flights in SCORE or SSIM format,
specifying typical flight schedule information such as start/end date, days of operation, airline,
flight number, up to 5 via airports for arrivals and 5 via airports for departures, capability to
match arrival and departure flights.
 Schedule Flight Import System should allow import of all flights for a complete Season (for
example Summer 2015)
 Schedule Flight Import System allow either manual override or override based on defined rules, in
the case where flights already exist but with different information
 Schedule Flight Import System should ensure that invalid flight data is not inserted into the
AODB.
 Schedule Flight Import System should give a count at the end of the flight import process of how
many new flights were added, updated, joined and split.

Functional – Flight Information Display System

 Flight information for all the FIDS equipment should be provided from the AODB
 FIDS should be capable of receiving of flight information data from the AODB in real-time.
 FIDS should be capable of calculating the time parameters to automatically remove flights from
the display or to display new flights.
 FIDS should be capable of synchronizing time on all displays with reference to a centralized time
signal.
 Functional specification – Airport operational database

 FIDS should be capable of monitoring the status of the displays, i.e. evaluating any error
messages and passing the error status on to the AODB.
 FIDS should be capable of periodic refreshing of the entire display
 FIDS should be capable of displaying test information.
 FIDS software should support LCD and other electronic display devices for presenting arrival,
departure and baggage belt information.
 FIDS software should support displays with Windows based display controllers as well as other
graphic controllers such as GT2.
 It should be possible to define the layouts of the public display screens
 FIDS should be provided with a page-editing module.
 For each window, within FIDS, the screen designer should be able to display text, data from
AODB, graphics, video clips and date/time.
 FIDS Thin client application should be able to communicate with CUTE application to allow
authorised users to change the status (open/close) of check-in counters and gates and associate
them with flights.
 FIDS pages should be able to display the weather information of the destination airport.
 FIDS display should be work in cluster mode- For eq - if no of flights to be shown on display is 50
and one display can only show 17 flight then remaining flight should display on 2,3, and 4 display
so on..
 First FIDS display of the cluster should always show next 15-17 flight and remaining flights can
be with pagination/scrolling.
 FIDS display should toggle the pages in English and other local language based on defined
interval.
 Ground Handlers and Airlines should be able to enter First Bag/Last Bag details by pressing the
buttons to update the respective flight information.
 FIDS should have a flight viewer which can be opened on workstations, notebooks and other
mobile devices to get flight information.

Functional – Access Control System, Auditing and Performance Level

 Authorised users should be able to access the relevant flight data of the airlines and the air traffic
control.
 It should be possible to perform the processor-intensive tasks on behalf of the workstations.
 It should be possible to control and manage the access authorities to data and services
 It should be possible to control fault management and automatic error reporting to the system
administrator or user
 It should be possible to create a log of the system status. The logging should be configurable.
 Functional specification – Airport operational database

 The log-in, log-out and other key actions of all the users will be automatically recorded in audit
files.
 It should be possible to handle applications (local or remote) that require access to the database.
 There should be a provision of checking data from the interface processes for accuracy and
consistency and taking appropriate action.
 It should be possible to prepare graphical view of sequence of incoming aircrafts at Airport.
 It should be possible to identify aircraft details by clicking on the aircraft icon on the viewer.
 Each user shall have an individual access profile.
 Each user shall log on to the system using his or her own user ID and password. These are to
be created by the system administrator. The user shall be able to change his or her personal
password.
 The validity period of the user ID and password shall be freely defined by the system
administrator. The system administrator shall also be able to suspend a user ID or reset or
change the password.
 Each user can belong to one or more user groups. The number of user groups in the system shall
be unlimited.
 The assignment of access rights can be made for individual users or for groups of users.
 The access rights shall extend to cover function, list and file and data element level.
 In the ID it shall also be possible to specify which events will result in an alarm being displayed on
the desktop.
 Simple functions, especially those performed from the workstations, shall have response times of
less than 2 seconds.
 Simple batch processing functions and other functions that affect a limited data quantity shall
have response times of not more than 5 seconds.
 Complicated batch processing functions, especially those which affect a large quantity of data
shall have response times of not more than 15 seconds.
 Semi-automatic planning functions shall not exceed 5 seconds per processing step.

Integration
Following the list of expected integrations/interfaces for AODB systems
 Aviation billing system
 BHS system (SAC, Flight information, BSM etc.)
 PA system (Automated announcement system for flight information)
 ATC integration (ETA, ETD, 10 miles out information etc.)
 IVRS (Flight information)
 Websites (Flight information)
 VDGS
 Functional specification – Airport operational database

ANY OTHER INTERFACES REQUIRED TO BE ADDED. ABOVE MENTIONED INTERFACES TO BE

ELOBORATED IF REQUIRED.
 Functional specification – Airport operational database

Technical – System Architecture, System Availability

 System architecture should be client server architecture. Database should be secured and
normalised. System should be completely modular.
 Proposed system shall be centrally located at the company headquarters and shall serve the
clients located across various airports.
 System should be on high availability with 99.999% availability.
 Reliability: The architecture should be designed in such a way to avoid single points of failure:
Should a critical component fail; another component would take over the task of the failed
component.
 Data Consistency: In order to avoid redundancy of data, the concept of a central database for
airport operational data is used. This eases information exchange and also ensures that all
systems use the same up-to-date data.
 Scalability: The system would be designed in a way that could accommodate easy addition of
newer systems based on the business needs of the airport in the future.
 The hardware components should not be on the verge of their respective end-of-life.
 Any preventive maintenance, patch management should be performed without shutting down the
system.
 System should be able to raise alerts and notify the admin by email/sms.
 System time should be synchronized with Master Clock (NTP) time.
 System backup should be taken from any backup tool which can be restored on any machine.
 Operation and Maintenance Support is required with various options (1 Year,3 Year and 5 Years)
- onsite/remote/hybrid.
 All the required documentation such as Solution architecture document, Design Review
Document/System Architecture Document, User Manuals, System Manuals, Installation and
Commissioning document, Testing Document and training contents and material will be the part
of the scope.
 Training to airport core users, system admins and end users along with proper training material.
 Subcontractor will meet/interview the required stakeholders (IT/Finance/TOPS/Apron/etc) and
capture their requirements to configure the system in order to meet localise requirement.
 Any customization in the system will be the part of the scope.
 Functional specification – Airport operational database

4. SUBMITTALS

 Preliminary design:
Contractor to submit a system architecture and concept design along with tender submission.
System design proposed shall me the minimum specification mentioned here in this document.
 Detail design:
Contractor to submit a detailed design of the system with all the necessary inputs captured from
all the involved stakeholders and upon approval shall then initiate the system configuration.
Contractor to submit system architecture, design document, configuration management plan,
quality plan, test plan along with test cases and operating manuals. Contractor shall also submit
the training plan. All the mentioned documents and plans shall be submitted for approval before
considered for work.
 Business Rules & process
Contractor to submit a complete list of business rules & processes that will be configured in the
airport operation database for approval. Upon acceptance the rules shall be configured for
subsequent testing and certification of the system
 Interface Control Document (ICD)
Contractor to submit ICD’s for the interfaces with the systems mentioned in requirement section.
 Test Plan
Contractor to submit detailed testing plan for each scenario for approval the contractor to
schedule the testing of the system prior notice of one week.
 Training Plan
Contractor to submit detailed training plan for each airport location in coordination with the
stakeholder for approval. Upon approval the contractor shall commence the training. Contractor
shall provide train the trainer plan also to train the key members of the team whom later can do
the trainings to stakeholders once the project is completed.

5. APPLICABLE LAWS, CODES, RULES, REGULATIONS AND STANDARDS

All equipment, materials, construction and installation of the system to be in compliance with the
applicable requirements and following codes and standards:

1. IATA Recommended Practices

2. ACI Recommended Practices
3. ICAO regulations.
4. Euro Control A-CDM
 Functional specification – Airport operational database

The Contractor to provide compliance with all national and local applicable laws, codes and
requirements for the execution of the Works. It is the Contractor’s responsibility to make themselves
aware of these requirements.

6. PERFORMANCE REQUIREMENTS

 System Availability
 Fully redundant core system to be used 24 hours per day, 7 days per week.
 The total system availability to be at least 99.999 % within a 30-day period.
 The Airport Operational Database is considered Critical.
 No more than 2 percent of the total number of end-user devices (which includes workstations
and printers) to be simultaneously out of service, with a maximum of 5, at the same time at
the same area.
 During the estimated technical lifetime of the AODB, the following MTBF and MTTR
requirements to be met for the enlisted individual components and/or systems, taking into
account the total system availability as specified above and a minimum time between failures
of an individual component of 60 days:
a. Workstation device
b. MTBF > 2 year
c. MTTR < 1 hours
 The MTTR to include the diagnostic time, active repair/replacement time and the
adjustment/testing time on site.

 System Capacity
The system to allow for:
a. --------------Air Traffic Movements each day/AIRPORT
b. -----------million passengers per annum/AIRPORT
c. 2 years flight schedules, including the operational seasonal schedule.
d. Online retrievable:
1) 90 days of historical operational processed data.
2) Operational seasonal schedule.
3) Next seasonal schedule.
2. System network capacity requirements:
a. Interconnect system components and provide automatic communication of status
changes, commands, field-initiated interrupts, and other communications
required for proper system operation.
b. Communication not to require operator initiation or response and to return to normal
after partial or total network interruption such as power loss or transient upset.
 Functional specification – Airport operational database

c. System to automatically annunciate communication failures to the operator and identify

the communication link that has experienced a partial or total failure.
3. Detection of network loss and intrusion: The system to ensure that loss of network connectivity
of individual or groups of peripherals is detected, and a high-level alarm is generated in the
system. Network intrusions to be limited as far as possible by appropriate firewall and VLAN
configuration.

C. System Response Times

1. Processing time for data entry and provide response within 0.5 seconds.
2. Field device network to provide a system end-to-end response time of 1 second(s) or less for
every device connected to the system.
3. Flight schedule changes to be processed and status updated in the system within 1 second of
receipt,
4. Flight schedule changes to be forwarded to all interfaced systems within 0,5 second after
status has been updated.

7. DEMONSTRATION, TRAINING AND INSTRUCTION

Training to be provide , not taking into account additional training for staff that fails, to include:

1. Provide a minimum of 10 hours of operational training per class, class size not to exceed 8
persons, Operational training to be conducted in multiple batches.
2. Provide a minimum of 10 hours of administrator/supervisor training per class, class size not to
exceed 5 persons, total number of trainees not to exceed 20 persons.
3. Training to cover the operation of the system for assigning flights and users, operations and flight
maintenance processes. Training to include user and AODB administration and assigning user
privileges.
4. Class to include 4 hours hands-on training with simulated flight operations.
5. On-the-job training to be provided:
 Provide trainers for 40 hours per week for 3 weeks, according to a schedule agreed with
the Employer.
 Training to be split over:
1) Administration, supervision and operations
2) Terminal / airport operations areas