TITLE: J A TRAFFIC FLOW MANAGEMENT (ATFM) SYSTEM · 2019. 2. 15. · j) Doc 9882 - Manual on Air...
Transcript of TITLE: J A TRAFFIC FLOW MANAGEMENT (ATFM) SYSTEM · 2019. 2. 15. · j) Doc 9882 - Manual on Air...
JAMAICA CIVIL AVIATION AUTHORITY TECHNICAL SPECIFICATION
THIS COLUMN TO
BE
COMPLETED BY
TENDERER
COMPLIANCE
STATEMENT
Tenderer must state
below, against every
item, Compliance or
Non Compliance.
Failure to complete and
return this form may
invalidate the bid.
RFP# JANUARY 2019
TITLE:
JAMAICA AIR TRAFFIC FLOW MANAGEMENT (ATFM) SYSTEM
It is strictly prohibited for Tenderers to alter this document. Only the originator of the
specification may provide amendments.
TENDERER NAME:
Background:
The Jamaica Civil Aviation Authority (JCAA) intends to formally implement Air Traffic Flow
Management (ATFM) within the Kingston Flight Information Region (K-FIR) as a part of its overall
modernization program. There is one air traffic control centre that provides area radar service to aircraft
transiting the K-FIR and approach radar service to arriving and departing aircraft to/from 3
international airports and 3 local aerodromes.
Currently there are no formal ATFM tools in existence at the JCAA and ATFM measures are executed
primarily in the form of contingencies.
It is the Authority’s intention to procure an ATFM system that is fully integrated and automated to
generate and monitor all the elements of ATFM.
RFP# DECEMBER 2018 Page 2 of 39
TITLE: JAMAICA AIR TRAFFIC FLOW MANAGEMENT (ATFM) IMPLEMENTATION COMPLIANCE
STATEMENT
SECTION A – INTENT AND STANDARDS
TENDER REQUIREMENTS
1. OBJECTIVE
The Jamaica Civil Aviation Authority (JCAA) intends to procure, a fully integrated, ATFM
System to include the following:
a) Demand Capacity Balance (DCB) Monitoring
b) Demand monitoring
c) Traffic Situation Display
d) Simulated Traffic Situation
e) Collaborative Decision Making (CDM) Platform
f) Operational Information System
g) Weather Impact Evaluation
h) Airspace Management System
i) Multi-source for flight data management
j) Planning, evaluation and managing future workload
k) Post Operational Analysis
l) Capability to connect to FAA SWIM data source
m) Training
n) Network Component
o) Spares
p) Warranty
2. SCOPE
2.1. This procurement consists of a fully integrated ATFM system to automate airspace
organisation and management, generate demand/capacity balance results, predict Air Traffic
Management (ATM) system demands and facilitate collaborative decision making (CDM) in
traffic management measures (TMMs) within the airspace jurisdiction of the Jamaica Civil
Aviation Authority; and secondly to establish and maintain a VPN data connection to the
Federal Aviation Authority’s (FAA) System Wide Information Management (SWIM) system
for data exchange purposes. The System shall be compliant with all ICAO Annexes and
SARPs that guide the varied areas of ATFM service provision. The Tenderer is expected to
provide all services necessary to install, integrate, test and commission the System, as well as
train operational, technical and maintenance personnel.
2.2. The Tenderer may provide costing for a redundant ATFM system that will be available to
provide the same level of service in the event of a loss of service at the main location. This
portion of the tenderer’s submission is optional.
2.3. The Tenderer shall be responsible for the assessment of the current operation and provide the
most suitable suite of software and equipment to enable the full implementation of ATFM
within the JCAA.
3. EXPERIENCE
3.1. The Tenderer shall demonstrate corporate experience involving the supply of complex
systems consisting of software applications and associated hardware/software platforms and
the ability to provide a mature and proven product that are key factors to the success of the
project. This is especially so with this project, given the tight timeline envisaged (6 months
from Contract Signing to Initial Operational Commissioning).
Page 3 of 39
SECTION A – INTENT AND STANDARDS
3.2. The Tenderer shall demonstrate at least 8 years of experience in ATFM systems
implementation. This experience must be within the last 6 years.
3.3. The Tenderer shall demonstrate that they have installed at least two (2) ATFM Systems in
two or more countries outside their (home) country that are in normal operation.
3.4. The Tenderer shall provide a list of references (names, contact details; such as email address,
phone numbers) and letters of recommendation from two (2) customers.
3.5. It is preferred that the Tenderer possess ATFM implementation experience and/or knowledge
in the ICAO NAM/CAR Region including attendance to ICAO meetings or Regional
Workshops.
3.6. The Tenderer shall demonstrate experience with ATFM Inter-operability testing by clearly
outline by references.
3.7. The Tenderer should demonstrate with appropriate documentation inter-operability testing of
its ATFM systems with ATFM systems of other vendors for implementation of a cross-border
ATFM network.
3.8. The Tenderer should demonstrate inter-operability of its ATFM systems with ATM systems
and AIM systems of other Tenderers for data mining purposes.
3.9. The Tenderer shall demonstrate the ability to connect to the Federal Aviation Authority’s
(FAA) System Wide Information Management (SWIM) system.
3.10. The Tenderer shall demonstrate through appropriate documentation inter-operability of its
ATFM system with the FAA SWIM network system for the exchange Traffic Flow
Management (TFM) data between the JCAA and the FAA.
3.11. The Tenderer shall provide all licensing applicable for all of the server-based and workstation-
based software applications to be supplied with The System.
3.12. The Tenderer shall provide all the licenses required for the software applications to be
provided with the proposed system.
4. MANDATORY SITE SURVEY AND TECHNICAL MEETING
4.1. A mandatory site visit is required to be conducted by the Tenderer, to become familiar with
the ATM infrastructure layout of the JCAA. This is to be done at the tenderer’s own expense,
prior to the submission of the tender. The design shall take into consideration all local
constraints and site particularities. Lack of knowledge of the exact local conditions will not
absolve the Tenderer, under any circumstance, from fulfilling his contracted mandate. All site
visits shall be coordinated through the JCAA. A synopsis of the site visit shall be included in
the proposal.
4.2. The Tenderer shall coordinate and schedule the Site Survey and Technical Meeting through
the appropriate JCAA personnel.
5. STANDARDS
5.1. All designs, retrofit, materials, manufacturing techniques and workmanship shall be in
accordance with the highest accepted international and national standards for this type of
equipment.
5.2. The Tenderer should indicate and provide evidence if ISO certified or provide equivalent
certification in Quality Assurance Systems (ICAO and Non-ICAO reference documents).
Page 4 of 39
SECTION A – INTENT AND STANDARDS
5.3. The Tenderer shall also state, where applicable, the standards to which the whole, or any
specific part, of the equipment and/or software complies.
5.4. Where applicable, the equipment shall fully comply with or exceed the requirements of the
following documents (latest edition plus any related amendments and any other applicable
documents):
5.4.1. The System shall be compliant with the following ICAO standards.
a) The System shall be compliant with the following ICAO Standards.
b) Annex 3 - Meteorological Services.
c) Annex 5 - Units of Measurement.
d) Annex 10 - Aeronautical Telecommunications.
e) Annex 11 - Air Traffic Services.
f) Annex 15 - Aeronautical Information Services.
g) Doc 4444 - Procedures for Air Navigation Services - Air Traffic Management.
h) Doc 9971 – Manual on Collaborative Air Traffic Flow Management.
i) Doc 9854 – Global ATM Operational Concept.
j) Doc 9882 - Manual on Air Traffic Management System Requirements.
k) Doc 9883 - Manual on Global Performance of the Air Navigation System.
l) Doc 9674 - World Geodetic System - 1984 (WGS -84) Manual
m) Doc 9426 - ATS Planning Manual
n) CAR/SAM ATFM CONOPS
5.4.2. NON-ICAO Referenced Documents
a) ISO 19107: Geographic information — Spatial schema
b) ISO 19108: Geographic information — Temporal schema
c) ISO 19109: Geographic information — Rules for application schema
d) ISO/IEC 40500:2012 - Information technology -- W3C Web Content Accessibility
Guidelines (WCAG) 2.0.
e) ANSI/ISO/ASQ Q9000 Series: Quality Management Standards
f) FAA SWIM Governance Policies version 3.0
6. TENDER SPECIFICS
6.1. Alternatives
6.1.1. The Tenderer is free to offer any equipment, design or service, which in their opinion, is equal
to or superior to the requirements of this specification. Any such alternative(s) or variation(s)
must be fully and clearly defined and supported so that equivalence or superiority can be
readily determined through demonstration.
6.1.2. All alternative(s) or variation(s) proposed shall be described and quoted separately with an
explanation of the improvements which would result from their implementation.
6.2. Tender Documentation
6.2.1. Compliance Statement: All offers shall be accompanied by a correctly completed
Compliance Statement in the form of this specification with the Tenderer indicating in
the right hand column, Compliance (C) or Non Compliance (NC), along with evidenced
references to sections, pages and paragraphs of the proposal. If compliance is indicated,
any further references, statements, comments or notes, will not waive the liability of the
Tenderer on the stated Compliance. The Tenderer shall reference the compliance statement
to the appropriate sections of their supporting documentation. Lack of such definitive
indication for any requirement may invalidate the offer. Tender documentation is to be
provided in English and in three copies. The Tenderer shall provide in CD form an electronic
copy of their tender documentation.
Page 5 of 39
SECTION A – INTENT AND STANDARDS
6.2.2. The proposal shall be supported by adequate technical documentation including data sheets,
performance sheets, drawings, illustrations, etc. so that a complete and detailed evaluation of
The System can be made. In the proposal, the Tenderer shall present the detailed description
of the equipment including designs, specifications and basic plans indicating all the
characteristics, sources, makes, capabilities, powers, codes, standards, manufacturing
processes, diagrams and other information that will show the design, quality and operating
characteristics of the System being offered.
6.2.3. Note: Whilst the attachment of brochures and supporting literature is strongly
encouraged and may in some cases be necessary to illustrate certain features of the
product, it does not relieve the Tenderer of the obligation to fully complete the
compliance statement of this specification as indicated above.
6.2.4. Supporting documentation shall clearly identify by a remark, any optional equipment and
features that are not included in the proposal.
6.2.5. A spares list, accessories and consumable goods list and installation cost breakdown list shall
be provided. The Tenderer shall furnish the necessary instructions for the assembly, operation,
maintenance, and lists of spare parts of the elements and accessories that will be provided for
the implementation of the System under this procurement.
6.2.6. The Tenderer shall provide the necessary documents, permitting the evaluation of the quality
and functionality of the work proposed for the project infrastructure.
6.2.7. The financial offer shall provide prices itemised to the Line Replaceable Unit (LRU) level.
7. PROJECT MANAGEMENT
7.1. Preliminary Project Plan
7.1.1. The Tenderer shall submit with their proposal a preliminary project management plan and
GANTT chart containing the design, manufacture, Factory Acceptance Tests (FAT), training,
installation, Site Acceptance Tests (SAT), Operational Readiness Demonstration (ORD), and
Final Site Acceptance Tests (FSAT) and commissioning tasks for review.
7.2. System Design Document
7.2.1. The successful Tenderer shall submit, within thirty (30) days after contract signature, a System
Design Document (SDD) which shall contain a detailed listing of the scope of supply and
related costs, (including spare parts/accessories), technical/operational description of the
proposed equipment, preliminary civil works, training plan, and the equipment functional and
operational characteristics. The SDD shall be delivered in hard copy, three copies in English
and also provided on CD. This document shall be prepared using standard Microsoft tools.
7.2.2. The Successful Tender shall submit within thirty (30) days of the contract award the following
items for the JCAA’s approval:
a) A complete and detailed final project work schedule.
b) A transition plan describing how the proposed equipment can be installed and commissioned
with minimum disturbance and disruption to the existing air traffic services operations.
c) A calendar presented in weekly segments from contract award to commissioning with the
following major milestones:
i. Preliminary design review,
ii. Final design review,
iii. Factory manufacturing/assembly,
iv. FAT,
v. Civil works,
Page 6 of 39
SECTION A – INTENT AND STANDARDS
vi. Site preparation,
vii. Training,
viii. Installation,
ix. Provisional SAT,
x. Final SAT,
xi. Commissioning.
7.2.3. The System Design Document and program schedule shall be subject to the JCAA approval.
If the document(s) in question are rejected, the Tenderer shall have ten (10) days to correct
the document(s) and revise them at no additional cost.
7.2.4. Thirty (30) days after contract signature, the Tenderer shall submit for approval, the necessary
architectural and structural requirements to be completed by the JCAA, for system
implementation and integration.
7.2.5. The Tenderer shall, at no extra cost, update the approved project plan on a monthly basis until
contract completion.
8. SCHEDULE OF IMPLEMENTATION
8.1. It is desirable that the overall project implementation does not exceed 6 months (Contract
Signing to Initial Operational Commissioning).
9. TENDERER’S RESPONSIBILITY
The Tenderer shall assume total responsibility for the following matters:
a) Proposed project, layout and distribution of all works.
b) Damages caused to the owner’s installation or any other sub-Tenderer due to
negligence while executing his work or actions attributable to his personnel.
c) Ensuring that any equipment, material, tools and surplus material is not left in areas
of circulation on the site.
d) Consultation and familiarization with the architectural, electrical and mechanical
plans to correctly place the system.
e) Any deviations of the specifications shall be corrected at the tenderer’s own
expense.
f) Ensure personnel are provided with procedures and instructions and any necessary
elements in order to avoid work related accidents.
RFP# DECEMBER 2018 Page 7 of 39
TITLE: JAMAICA AIR TRAFFIC FLOW MANAGEMENT (ATFM) IMPLEMENTATION COMPLIANCE
STATEMENT
SECTION B - GENERAL EQUIPMENT CONDITIONS
1. POWER SUPPLY
1.1. The System shall operate on a single phase mains power with a voltage of 110 -240V ± 10%
and a frequency of 50-60 Hz ± 5 Hz.
1.2. The Tenderer shall comply with Jamaican power and electrical supply regulations during all
site activities.
2. OPERATING TEMPERATURES
2.1. All equipment shall be capable of being operated in a normal air-conditioned office environment
without the need for additional ventilation.
2.2. In the event of air-conditioner outages, all equipment supplied shall be capable of operating in
a temperature range of -5C to +45C with a humidity factor of up to 80%.
2.3. Tenderers shall specify the operating and storage temperature ratings of all of the types of
equipment that are to be provided.
3. OPERATING SYSTEM
3.1. All servers and workstations shall use a Licensed Linux and Windows operating system(s)
respectively.
3.2. The Operating System(s) used shall be non-proprietary, i.e. not specific to a particular hardware
vendor/platform.
3.3. The Tenderer shall identify in the proposal, the operating system(s) to be used.
4. SERVERS CONFIGURATION The ATFM Main System which will normally be used operationally shall be implemented with
redundant servers configured to operate in Active/Hot-standby mode. The Main System shall
include the following equipment:
4.1. Hardware
4.1.1. Hardware shall include:
Redundant servers or sets of servers.
ATFM operator or supervisor workstations.
ATFM Technical maintenance/Monitoring workstations.
Network components (routers, switches, firewalls etc.) to support a high speed
redundant (duplicated) LAN network at the central site for the main System.
LAN/WAN Connections to local operator workstation with connections to remote
locations.
Equipment enclosures and Accessories Redundant UPS Systems. Server grade
computer platforms shall be used for core ATFM applications.
4.1.2. Each server computer shall be equipped with a SCSI-compatible hardware-RAID system
comprising at least 3 pairs of hard disk drives (one pair to be used for application software and
the remaining pairs to be used for data storage).
4.1.3. Hard Disk Drives shall not be shared between redundant servers, i.e. each server will have its
own set of redundant RAID disks.
Page 8 of 39
SECTION B - GENERAL EQUIPMENT CONDITIONS
4.1.4. Failure or replacement of a single hard disk drive in a paired set shall not affect the operation
of the server in terms of functionality, performance or data integrity.
4.1.5. The hard disk shall be used in RAID level-6 configuration.
4.1.6. All hard disk drives in the servers shall be hot pluggable so that there is no requirement to shut
down the server to remove/replace a hard disk drive.
4.1.7. The hot-pluggable drives shall be easily accessible, preferably from the front of the servers.
4.1.8. All servers shall have high speed DVD/RW drives.
4.1.9. The servers shall have redundant power supply units.
4.1.10. All servers shall be powered via UPS Units.
4.1.11. The server’s redundant power supplies shall be powered from different power sources, e.g. UPS
‘A’ provides power to Server power supply ‘A’ and UPS ‘B’ provides power to Server power
supply ‘B’.
4.1.12. The servers shall have redundant network interfaces (100/1000 Base-TX Ethernet).
4.1.13. The servers shall have easily accessible USB 3.0 ports (or latest available version), with access
on the front panel of the servers.
4.1.14. All servers shall be rack mounted.
4.1.15. Servers forming a redundant (Active/Hot-standby) pair shall be housed in different racks for
diversity.
5. The (Operational) Main System
5.1. The ATFM System, which will be used operationally, shall be implemented with redundant
servers configured to operate in Active/Hot-standby mode.
5.2. Operator/ATFM Supervisor Workstations
5.2.1. The System shall be supplied with Operator/Supervisor workstations, which shall allow
operational staff to operate and supervise the operation of the ATFM System.
5.2.2. The Operator/Supervisor workstations shall have redundant connections to the System via the
dual ATFM LAN.
6. HARDWARE
6.1. All hardware shall be of the latest generation / models.
6.2. Where possible all hardware used in the System shall be Commercial Off-The-Shelf (COTS)
hardware using industry standard components.
6.3. The COTS hardware shall be widely-available brands and produced by reputable manufacturers
with world-wide distribution and support networks.
6.4. Where possible hardware to be used shall be from manufacturers who have authorized
dealerships in Jamaica capable of the future supply, maintenance and support of the System
hardware.
6.5. Where possible the Tenderer shall avoid the use of proprietary hardware in the System.
Page 9 of 39
SECTION B - GENERAL EQUIPMENT CONDITIONS
6.6. The Tenderer shall identify in the proposal any items of hardware, which are proprietary.
6.7. As performance and capacity are increasing with each new generation of hardware, no absolute
minimum requirements are given in this software requirements specification (SRS). The
Tenderer shall list in the proposal, the make, model and physical configuration (e.g. CPU speed,
RAM, hard disk).
7. CABLING
7.1. The Tenderer shall standardize cable types and lengths in the installations.
7.2. The cables shall be laid out, depending on the location, in cable troughs, elevated floors,
suspended ceilings, pipes, or cable shafts.
7.3. Cables shall be placed side by side and tied at regular intervals along their routing and grouped
by function.
7.4. To avoid induction, low-level signal cables shall be separated from power cables by a minimum
of .25 m and shall cross at perpendicular angles.
7.5. Each cable shall be identified at its extremities by a coloured label containing the following
information:
Cable function.
Cable number (this number shall identify the nature of the cable, its source and its
destination).
7.6. The Tenderer shall provide the appropriate cable documentation which shall contain the
following information for each cable:
Source
Destination
Cable type
Cable function
Cable number
8. SOFTWARE DESIGN AND DEVELOPMENT
8.1. The System software shall conform to International Standards Organization (ISO) standards
and to Open Systems Interconnect (OSI) standards.
8.2. The software system shall have a modular architecture which is supported by the Tenderer’s
software development principles.
8.3. The Tenderer shall adhere to recognized software system development coding, inspection and
testing standards.
8.4. The Tenderer shall indicate the software design methodology that is used in the production of
its ATFM product.
8.5. All application software shall be written in a modern high level language (e.g. Java) which is
highly portable across hardware platforms and operating systems.
8.6. The Tenderer shall indicate the programming language(s) used to implement the System.
8.7. The System software shall be easily expanded / enhanced to include new functionality as
required by evolving ICAO ATFM SARPs.
Page 10 of 39
SECTION B - GENERAL EQUIPMENT CONDITIONS
8.8. The software shall have a robust design, validating all data entries so that the System does not
fail or malfunction resulting from the incorrect input of data.
8.9. The software system shall be designed so that changes to system configurations which require
a stop and restart of the software application for the configuration changes to take effect are
kept to an absolute minimum.
8.10. All user access shall be username and password controlled.
8.11. It shall be possible to set restrictions on the minimum composition of a password, e.g. minimum
length of a password, requirements for the password to contain a combination of alpha and
numeric characters and/or a combination of upper-and lower-case characters.
8.12. The software system shall provide additional operator authorization or access control, based on
user roles (or user groups), i.e. access to certain system functions or groups of functions can be
restricted to only those users with a particular role (in a particular user group).
8.13. It shall be possible to allocate multiple roles to a user (or attach the user to multiple groups).
8.14. The System shall ask for operator confirmation prior to executing commands which could have
a significant detrimental effect on the System and/or its availability (e.g. the operator attempting
a cold start of The System).
9. SOFTWARE MANAGEMENT AND CONFIGURATION
9.1. The Tenderer shall provide a system to safely and securely recover from any system failure by
providing recovery procedures for all versions of software applications, configuration data
and documentation.
9.2. In the event of a problem with a new software release it shall be possible to easily roll-back to
the previous proven version of the software application.
9.3. Backup & Recovery
9.3.1. The data shall be backed up to an external hard drive or tape storage each day to ensure quick
recovery of data in the event of a failure, intentional destruction of data or a disaster.
9.3.2. The supplier shall provide all the equipment required to facilitate complete full backups.
10. NETWORKS
10.1. Redundant (duplicated) LANs shall be provided for the central ATFM Network.
10.2. In the event of a failure of one of the LANs, the other LAN shall be able to support the entire
operation of the ATFM system with no loss of functionality or capacity.
10.3. In the event of a LAN failure, the switching of ATFM connections between LANs shall be
automatic, without any loss of data or any discernible impact on the operation of the ATFM
system.
10.4. The network hubs, switches and routers shall conform to 100/1000 Base-T 10GB Ethernet
standards.
10.5. The Tenderer shall incorporate the security of the ATFM Network in the design of the Network.
10.6. The Tenderer shall provide all equipment (e.g. firewall hardware and software applications)
required to provide the level of security required.
Page 11 of 39
SECTION B - GENERAL EQUIPMENT CONDITIONS
10.7. The Tenderer shall indicate security features/mechanisms contained within their solution and
propose mitigating strategies to protect the JCAA Network from being compromised through
interconnectivity with the ATFM System.
11. EQUIPMENT ENCLOSURE AND ACCESSORIES
11.1. The Tenderer shall provide 19” (483 mm) equipment enclosure to house the ATFM servers and
network equipment.
11.2. For diversity, all items of redundant equipment shall be mounted in different enclosure, e.g.
Item ‘A’ of a redundant pair in Enclosure ‘A’ and Item ‘B’ of the pair in Enclosure ‘B’.
11.3. All equipment within an enclosure shall share a common flat panel screen, keyboard and mouse.
11.4. These shall be housed in a low profile sliding drawer so that they can be folded away and housed
within the enclosure when not in use.
11.5. Each distribution panel shall be connected to a different UPS.
11.6. The distribution boards shall have spare capacity, i.e. not all of the sockets should be utilized
by The System as delivered.
12. INTERFACE MANAGEMENT
12.1. The Tenderer shall evaluate and provide input to the Purchaser on any external interfaces to the
System prior to the Purchaser’s Acceptance Inspection.
12.2. The Tenderer shall document any proposed changes or updates to interfaces required resulting
from analysis or surveys.
12.3. The Tenderer shall support the Purchaser in resolving interface issues that may arise during the
installation and phase of the project.
13. Tenderer’s Software Licensing Policy and Software Pricing
13.1.1. The Tenderer shall, in his proposal, provide Software Licenses applicable to all of the server-
based and workstation-based software applications to be supplied with the System.
13.1.2. The Tenderer shall, in his proposal, include Server licensing costs for the first 5 years of the
initial contract.
13.2. Licensing for Workstation-based Software Applications
13.2.1. The Tenderer shall, in his proposal, provide all licensing for any User Agent Software
Application.
13.2.2. The Tenderer shall, in his proposal, include Workstation based software application licensing
costs for the first 5 years of the initial contract.
13.3. Licensing for Server-based Software Applications
13.3.1. The Tenderer shall, in his proposal, provide all licenses for server-based software applications
on a per-system or per-server i.e. whether a redundant (1+1) server system required twice as
many software licenses as a non-redundant server system.
13.3.2. The Tenderer shall, in his proposal, include server-based application licensing costs for the first
5 years of the initial contract.
RFP# DECEMBER 2018 Page 12 of 39
TITLE: JAMAICA AIR TRAFFIC FLOW MANAGEMENT (ATFM) IMPLEMENTATION COMPLIANCE
STATEMENT
SECTION C – TECHNICAL REQUIREMENTS
1. ATFM USER HARDWARE AND SOFTWARE
The vendor shall provide hardware and Software that at minimum, shall meet the
specifications, below.
**The vendor can propose alternative hardware and software solutions / specifications that
will match or exceed optimum levels of system performance as indicated below.
1.1. CPU
1.1.1. CPUs: 8 Core Processors
Memory: 128 GB RAM
1.2. Hard drive
1.2.1. Hard Drive 1: – 500GB SSD
Hard Drive 2 - Data -2 TB 7200 RPM
**Provisions should be allocated for expandability
1.3. RAM
1.3.1. Minimum 128 GB ECC DDR4
1.4. Display
1.4.1. Dual 26 inch screens
Resolution -1024x768 (1600x1050 or higher recommended)
with True Colour Workstation Video /
Dedicated Graphics Card- NVIDIA Quadro M6000
1.5. Operating System
1.5.1. Microsoft Windows Professional (Latest version) –Solid State
1.6. Printers
1.6.1. All printers shall be LAN-based.
1.6.2. All printers used for logging purposes or used from the Operator/Technical workstations
shall have redundant LAN interfaces.
1.6.3. All printers shall be of a low-noise type i.e. suitable for use in operational areas with noise
levels below 50 dB(A).
1.6.4. Unless otherwise required, the printers shall be of the same make and model.
1.7. System Availability
1.7.1. The System shall be available continuously, i.e. 24 hours per day, 7 days per week.
1.7.2. The hardware used in the System shall be deployed in a redundant way that allows for the
exchange of components without any interruption of service.
1.7.3. The Tenderer shall include in the proposal, the Mean Time Between Failure (MTBF) and
Mean Time To Repair (MTTR) statistics derived from the ATFM systems that they have
deployed operationally in the last 5 years.
1.7.4. The Tenderer shall detail in the proposal the strategies that they use to ensure no single
points of failure in the System (hardware and software).
Page 13 of 39
SECTION C – TECHNICAL REQUIREMENTS
1.7.5. The Tenderer shall include in the proposal, details of the MTBF and MTTR predictions for
the System. These should include the manufacturer’s MTBF figures for the different
hardware components proposed for The System.
1.7.6. The System shall not lose any data.
1.8. System Management
1.8.1. Overall System Management requirements
1.8.1.1. The System shall provide a system management interface which is consistent across all
ATFM components of The System. This includes the support and management of applicable
AMHS functionalities for seamless integration.
1.8.1.2. The ATFM components of the System shall be managed from the same software application
which utilizes a single GUI.
1.8.1.3. The System management functionality shall include:
Management of the System configuration (operational and technical).
Management of the functioning of the overall system (Switching between Active
and Hot standby systems, rebooting systems, reinitializing systems etc.).
The monitoring, logging, retrieval and inspection of system events (alarms,
faults etc.).
The monitoring, logging and retrieval of operator commands.
Management of data storage and archiving.
Retrieval and inspection of all statistics generated by the System: - system
performance, resource utilization and availability statistics.
1.8.1.4. Although most system management activities will be performed via a GUI, it shall be
possible also to perform certain system management activities via the use of scripts, e.g.
archiving data, creating backups, exporting data to external media.
1.8.1.5. It shall be possible to schedule the execution of such scripts.
1.9. System Monitoring
1.9.1. Operational System Monitoring
1.9.1.1. The Operator/Supervisor workstations shall allow the operational users to monitor and
process operational events and alarms.
1.9.1.2. It shall be possible to associate a specific alarm with an event.
1.9.1.3. An alarm shall contain the date and time of the occurrence of the event.
1.9.1.4. An alarm shall identify the object concerned, e.g. circuit, queue.
1.9.1.5. An alarm shall contain a numeric identifier to allow filtered selections of particular
alarms/events from The System event logs.
1.9.1.6. An alarm shall have a type associated with it, e.g. general, technical or operational. This
will enable different types of alarms to be sent to different user groups / roles and to
different logging printers.
1.9.1.7. It shall be possible to change the textual part of the alarm.
Page 14 of 39
SECTION C – TECHNICAL REQUIREMENTS
1.9.1.8. It shall be possible to configure whether or not an alarm is generated when an event occurs
(i.e. configurable activation or de-activation of alarms).
1.9.1.9. It shall be possible to configure alarms with different severity levels and associate different
colours with the different severity levels when displaying the alarms.
1.9.1.10. It shall be possible to configure per severity level, whether or not an alarm creates an
audible and/or visual alert to the user.
1.9.1.11. It shall be possible to configure per alarm, whether or not an alarm creates an audible
and/or visual alert to the user. This will take precedence over the per severity level setting.
1.9.1.12. It shall be possible to configure per severity level, whether or not an alarm requires an
acknowledgement from the user.
1.9.1.13. It shall be possible to configure per alarm, whether or not an alarm requires an
acknowledgement from the user. This will take precedence over the per severity level
setting.
1.9.1.14. It shall be possible to configure per severity level, whether or not an alarm is automatically
printed to a logging printer.
1.9.1.15. It shall be possible to configure per alarm, whether or not an alarm is automatically printed
to a logging printer. This will take precedence over the per severity level setting.
1.9.1.16. It shall be possible to direct alarms to different logging printers configurable per type of
alarm (e.g. general, technical, operational).
1.9.1.17. It shall be possible to configure by alarm type which alarms are presented to which user
groups or roles. This will provide the capability for different user groups or roles to be
responsible for processing the different type of alarms.
1.9.1.18. All operational alarms and events shall be logged.
1.9.2. Logging of System Events and Operator Commands
1.9.2.1. In addition to logging message traffic, the System shall log all:
System Events e.g.: - Alarms. - Failures. - Changes to system status which has
occurred without operator input.
Operator commands (which have resulted in changes to the configuration or
status of The System).
1.9.2.2. These logs shall be available on-line for a minimum of 6 months.
1.9.2.3. The length of time that the logs are kept on-line shall be configurable per type of log.
1.9.2.4. The System shall provide a facility for archiving the logs to external media.
1.9.2.5. The logs shall not be deleted from the System, either automatically or manually,
unless they have been flagged as having been archived to external media.
1.9.2.6. The user shall be able to retrieve data from the System Events logs using a
number of filters or combinations of filters, e.g.:
Time span
Identity of event/alarm.
Type of event / alarm.
Page 15 of 39
SECTION C – TECHNICAL REQUIREMENTS
Severity of event / alarm.
Type of equipment / sub-system.
1.9.2.7. The user shall be able to retrieve data from the Operator Command logs using a
number of filters or combinations of filters, e.g.:
Time span.
Type of command / configuration change.
Operator / user ID.
1.9.2.8. The user shall be able to select one or more records from the retrieve logging data and
perform one of the following.
Print the records.
Save the records to a file in a human readable format (plain text), and write the
file to external media.
1.10. Data Storage and Archiving
1.10.1. The System shall not limit the on-line storage of data e.g.: Message logs, System event logs,
Operator command logs, Statistical data to a maximum period set within the application.
1.10.2. On-line storage of data shall only be limited by the physical storage capacity of the System,
i.e. the hard disk storage capacity.
1.10.3. The maximum period for data to be stored on-line shall be configurable.
1.10.4. The System shall incorporate an automatic disk space management system to prevent the
loss of data due to insufficient disk space. For example, deletion of the oldest message logs
when the disk capacity gets to a configurable threshold level e.g. 90%.
1.10.5. On-line storage of data shall take into account the year number, i.e. it must be possible to
have data on-line concurrently for the same day number and month number for multiple
years, e.g. for 24-JUN-2017 and 24-JUN-2018. This applies especially to Message logs.
1.10.6. For efficiency and performance, the System may divide the on-line storage of the data
between the database and on-line archive files.
1.10.7. If a system of on-line archiving is used then the System shall automatically archive data
from the database once the data has passed an age threshold, i.e. when the data is more than
a specified number of days old.
1.10.8. The age threshold to be used for on-line archiving shall be configurable.
1.10.9. By default, all archive files, whether for on-line or offline storage, shall be generated for
periods of one day.
1.10.10. The names of the daily archive files shall incorporate the date of the archive.
1.10.11. It shall be possible to schedule the automatic generation of archives at a configurable
time so that the archive can be performed by the System at a quiet local time, e.g. in
the middle of the night.
1.10.12. It shall be possible to export archives to external media.
1.10.13. It shall be possible to schedule the automatic export of archives to external media to
occur at a configurable time so that the export can be performed by the System at a
quiet local time, e.g. in the middle of the night.
Page 16 of 39
SECTION C – TECHNICAL REQUIREMENTS
1.10.14. The destination for the export, i.e. the type of media to be used, shall be configurable
to any of the types of external media supported by the System.
1.10.15. It shall be possible to delete archives from the System but only if the archive has
already been exported to external media.
1.10.16. It shall be possible for the operator to create an archive for a period longer than one
day, e.g. for archiving monthly data.
1.10.17. The archives shall contain all of the data that was stored in the database, i.e. no
information is lost when the data is stored in an archive.
1.10.18. It shall be possible to re-introduce data into the System (database) from an on-line or
off-line archive.
1.10.19. For historical or investigation analysis it is sometimes useful to be able to re-introduce
multiple day’s data into the System. The amount of re-introduced data that can be
present concurrently on The System shall not be limited to a single day’s worth of
data.
1.11. Statistics
1.11.0. The System shall collect, at a minimum, statistics relating to:
System performance, resource utilization and availability.
1.11.1. The System shall maintain statistical data online for a period of at least 2 years.
1.11.2. The Tenderer shall list in the proposal, the types and extent of statistical data that the System
can generate.
1.11.3. Statistics shall be generated for a number of different time periods:
• Hourly • Daily • Monthly • Yearly
1.11.4. Statistics shall be stored in a Statistics Database for easy retrieval.
1.11.5. The operator shall be able to access all statistics via a GUI and view the statistics in tabulated
and graphical formats.
1.11.6. The Tenderer shall provide in the proposal examples of the GUI displays of statistical data.
1.11.7. The operator shall be able to sort tabulated statistical data by column (e.g. monthly channel
traffic statistics sorted by Channel ID or by total message counts).
1.11.8. The System should be able to generate ‘trend graphs ’which plot monthly averages of the
statistical parameter for a specified period, or over the operational lifetime of the System.
1.11.9. In the case of statistical data required to generate ‘trend graphs’, The System shall
maintain the data online for a minimum of the last 5 years, and should maintain the
data online back to the operational commissioning of the System.
1.11.10. The System shall support the printing of statistical data in both tabulated and graphical
format.
1.11.11. The System shall be able to export statistical data to disk or removable media (e.g.
DVD or USB flash drive) in formats which can be read by or imported into COTS
software packages.
Page 17 of 39
SECTION C – TECHNICAL REQUIREMENTS
2. SIMPLE NETWORK MANAGEMENT PROTOCOL (SMNP) CAPABILITY
2.1. The System parameters shall be SNMP capable. The parameter shall include bandwidth
utilization, user status, printer status, sever status, etc.
2.2. The System shall be able to send SNMP version 3 traps (SNMPv3) over an IP network.
2.3. MIB file shall be included.
3. DATA MANAGEMENT AND INTEGRATION
3.1. The System shall support local AMHS connections from other ‘automated systems’ e.g.
ATM, AIM or MET systems which have AMHS messaging capabilities.
3.2. These connections shall use the X.400 P3 Protocol over TP0/RFC1006/TCP/IP.
3.3. The Tenderer shall provide Application Program Interface (API) and relevant Interface
Control Documents (ICD) for IP-based connections, to support future connectivity of other
ATN/AMHS applications (e.g. ATM, AIS/AIM, MET systems) via P3/P7 standards.
3.4. The System shall support IP-based AMHS/AFTN connections.
3.5. The System shall be capable of supporting the following types Ethernet 10/100/10GB.
3.6. The System shall be capable of correlating data from multiple sources and present it in a
common view to the user.
3.7. The System shall be capable of accepting AIXM v5.1.1 or later data format from compliant
databases.
3.8. The System shall be capable of accepting FIXM v4.1.0 or later data format from compliant
databases.
3.9. The System shall be capable of accepting data format WXXM v2.0 or later from compliant
databases.
3.10. The System shall be capable of accepting data from SOAP and/or REST services data
providers.
3.11. The System shall be capable of accepting data from existing third party AMHS, AFTN and
CNS network systems.
3.12. The System shall be capable of accepting aircraft data from airlines, Official Airline Guide
(OAG), ARINC, SITA etc. and direct message from aviation stakeholders.
3.13. The System shall be capable of accepting RADAR and ADSB data from existing systems.
3.14. The System shall be capable of receiving and processing ASTERIX data in all ICAO
standard formats and at a minimum shall include:
a) CAT 034 and 048 (SSR,MDR, RDP),
b) CAT 002 and 008 (weather radar)
c) CAT 062 and 63 (SDPS)
d) CAT 20 (MLAT)
e) CAT 21 Standard 260B (ADSB)
3.15. The System shall be capable of sourcing data from static and real time database to build a
historical, current and forecast picture of demand and capacity.
Page 18 of 39
SECTION C – TECHNICAL REQUIREMENTS
3.16. The System shall be capable of restricting and filtering data based on user access level.
3.17. The System shall provide the user with a form-based menu interface for the users to issue
queries to remotely located archives of data and return results.
3.18. The System shall provide automated data export to external users/systems. The delivered
application shall facilitate the dissemination of data to the appropriate individuals/systems
and shall have a method for easily creating data extraction processes and for automatically
scheduling or otherwise arranging for these processes to generate data.
3.19. The System shall be able to create reports and queries based on the custom fields that have
been defined.
4. FAA System Wide Information Management (SWIM) connectivity
4.1. The Tenderer shall be capable of making the JCAA an International Data Producer (IDP)
for FAA SWIM data exchange program.
4.2. The Tenderer shall be capable of making the JCAA consume data generated by the FAA
SWIM, without a degradation in service.
4.3. The Tenderer shall provide equipment for the purpose of flight data exchange and usage.
4.4. The Tenderer shall survey what flight data (i.e., radar data, surface data, scheduled data,
modelled data, etc.) is available for data exchange, in what form/format those data exist, and
how those data can be accessed.
4.5. The Tenderer shall be able to filter out sensitive data prior to the transmission.
4.6. Data Conversion
4.6.1. IDP’s flight data shall be converted to the specified standard (e.g., FIXM including GUFI,
message format, WebLogic JMS settings for the environment.)
4.6.2. The System shall be capable of converting Traffic Flow Management System (TFMS) Data
to the native format (if necessary) for IDP use.
4.7. The Tenderer shall be capable of establishing and maintaining VPN connection to the FAA
SWIM database, for the exchange Traffic Flow Management (TFM) data between the FAA
and the JCAA.
4.8. Database
4.8.1. The Tenderer shall identify the size and capability of database to store the TFMS.
4.8.2. The Tenderer shall provide the servers to create the database.
4.8.3. The server size shall be large enough to manage the load of input TFMS data from FAA
SWIM database.
4.8.4. The Tenderer shall provide information on basic and extended data recovery in case of
failure.
4.8.5. Information on data archive is required.
Page 19 of 39
SECTION C – TECHNICAL REQUIREMENTS
4.9. Connectivity to SWIM
4.9.1. The Tenderer shall be capable of obtaining access to FAA’s SWIM as Producer to send
IDP’s flight data and as Consumer to received TFMS Data.
4.9.2. The Tenderer System shall be capable of data exchange continuously for twenty-four hours
every day (24/7).
5. AIR TRAFFIC SITUATION DISPLAY
5.1. The System shall be equipped with an air traffic situation display (ASD) that shall represent
the position of an aircraft as a symbol.
5.2. The System shall be capable of displaying active flights based on radar and or ADSB data
correlation.
5.3. The System shall be able to display an aircraft position based on filed flight plan
information.
5.4. The user shall be able to differentiate between an active flight based on radar data correlation
and a flight track based on flight plan information.
5.5. The System shall be capable of display an aircraft track position within one minute of its
actual geographical position.
5.6. A user shall be able to select an individual aircraft and obtain in a tabular view the following
aircraft information at a minimum:
Aircraft Identification
Departure Aerodrome
Destination Aerodrome
Aircraft Type
Estimated Time of departure
Filed Route
Altitude
5.7. The System shall be able to create a simulated traffic forecast based on flight data received
from filed flight plans.
5.8. The System shall be capable of creating and displaying re-route information on an aircraft
as text.
5.9. The System shall be capable of creating and displaying re-route information on an aircraft
graphically as a flight track overlay on a map.
5.10. The System shall be capable of Strategic, Pre-Tactical, and Tactical Demand Monitoring.
5.11. The System shall be capable of filtering and selecting traffic flows (e.g., by airport, airspace
sector and airway).
5.12. The System shall be capable of displaying the current occupancy count of an airspace sector.
6. DEMAND CAPACITY BALANCE
6.1. The System shall be able to provide Demand Capacity Balance (DCB) monitoring for
airports based on runway configuration, meteorological conditions, NAVAIDs availability,
airway segment, and available air to ground communication.
6.2. The System shall be able to predict capacity/demand imbalances.
Page 20 of 39
SECTION C – TECHNICAL REQUIREMENTS
6.3. The System shall be able to predict the air traffic demand for airports, a Flight Information
Region (FIR), airspace sectors, routes and fixes.
6.4. The System shall be able to display the capacity of resources such as runway, FIR,
airspace sector, route and airport under different conditions and parameters.
6.5. The System shall come equipped with database repository that can accept and store
capacity information on airports, airways, and airspaces sectors based on operational
configuration.
6.6. The System shall have the capability to display the DCB monitoring results graphically as
type of charts, graphs and histograms, which shall be configurable in scale, colours,
attributes, units of measurement directly by the operator.
6.7. The System shall be able to display the DCB results graphically as histograms over user
configurable time intervals (fifteen minutes, thirty minutes, hourly etc.).
6.8. The System shall be able to provide DCB monitoring for a generated map of a Flow
Constraint Area (FCA) or a line drawn as a Flow Evaluation Area (FEA).
6.9. The System shall be able to provide DCB monitoring for airports based on runway
configuration, meteorological conditions, available NAVAID, airway segment, and
available air to ground communication.
6.10. The System shall be able to provide DCB monitoring for airspace sectors and FCA based
on airspace volume (vertically and laterally), airway segment and available
communication, navigation and surveillance facility and meteorological conditions.
6.11. The System shall be capable of displaying historical, real time and auto-scale graphing.
6.12. The System shall have the capability to display the DCB monitoring results graphically in
real time. A new query shall not be necessary to have an updated view of the DCB.
6.13. The refresh rate of displayed charts, graphs or tables shall be one minute or less.
7. TRAFFIC MANAGEMENT MEASURES PLATFORM
7.1. The System shall be capable of generating traffic management measures (TMM) to solve
DCB.
7.2. The System shall have an Airspace Flow Tool (AFT) that is capable of constructing,
managing and executing a Ground Delay Program (GDP) with the capability to generate
Calculated Take Off Time (CTOT) and Calculated Off Block Time (COBT) and
disseminated to affected aircraft.
7.3. The System shall have an Airspace Flow Tool (AFT) that is capable of constructing,
managing and executing an Airspace Flow Program (AFP) with the capability to generate
Calculated Time Over (CTO) boundary waypoints or flow constraint area, for affected
aircraft and issue the notice by appropriate means.
7.4. The System shall be capable of predicting possible and developing issues that will require
TMM.
7.5. The System shall be capable of issuing TMM notification alerts to users.
7.6. The System shall be capable of issuing operational alerts to in advance of an issue, such as
a capacity overload in an airspace sector.
Page 21 of 39
SECTION C – TECHNICAL REQUIREMENTS
7.7. The alerts shall be configurable to ensure that only concerned users will receive
notifications applicable to them.
7.8. The System shall be able to store and archive previous TMM, by last date first.
7.9. The System shall be able to predict the operational impact of a TMM or an alternative
TMM on the overall system capacity.
7.10. The System shall be able to show the impact on system resources of adjusting an active
TMM.
7.11. The System shall be capable of indicating all flights that a TMM will affect.
8. WEATHER ANALYSIS TOOL
8.1. The System shall be equipped with a weather analysis tool that shall be capable of
translating weather elements.
8.2. The weather tool shall be an integrated graphical display of forecasted or reported severe
weather phenomena.
8.3. The weather tool shall be layered and shall enable authorized users to add or remove the
weather layer from the traffic situation display, and/or vary the transparency of the weather
layer.
8.4. The weather tool shall enable users to add or remove the different weather attributes.
8.5. The System shall be capable of but not limited to displaying weather attributes;
precipitation, snow, icing, cloud cover, wind speed and direction at different flight level.
8.6. The weather tool shall be capable of displaying convective weather activity and translate
the intensity or severity of the phenomenon using colour coded distinction.
8.7. The weather tool should be capable of accepting data from the NSSL Multi-Radar Multi-
Sensor system (MRMS) project, for improved severe weather forecasts and warnings.
8.8. The System shall be capable of analyzing the impact of weather on airspace resources and
create alerts for weather activity.
8.9. The System shall be capable of creating alerts specifically for airport weather activity.
8.10. The System shall be capable of displaying satellite imagery of weather phenomenon.
8.11. The System shall be capable of automatically creating SPECI, METAR, GAMET, TAF,
SIGMET, etc. and displayed as text or graphical messages from human driven at the user
interface and input from other weather tool.
9. OPERATION INFORMATION SYSTEM
9.1. The System shall provide a web based Operation Information System (OIS).
9.2. The OIS module shall be compatible with the latest version of the most popular web
browser (chrome, Firefox, Safari, Internet Explorer, etc.). Identify any limitation.
9.3. The OIS shall be able to serve at least 1000 access and display points, distributed across a
highly geographically area.
Page 22 of 39
SECTION C – TECHNICAL REQUIREMENTS
9.4. The OIS shall be capable of displaying airport demand information.
9.5. The OIS module shall be capable of displaying locally created ATFM Daily Plans; users
shall have access to daily plan via the internet.
9.6. The OIS module shall be capable of displaying CNS serviceability status of different
facilities.
9.7. The OIS module shall be capable of displaying current traffic management measures to
users with the appropriate user access.
9.8. The OIS module shall be capable of displaying archived TMMs to users with the
appropriate user access.
9.9. The OIS module shall be capable of displaying current NOTAMs, BIRDTAM etc.
9.10. The OIS shall provide users/stakeholders with a form-based menu interface to enter
information about their area of responsibility.
9.11. The System OIS shall be so configured that prior approval is needed from the appropriate
authority before any information is posted.
9.12. The OIS web application shall have a contemporary user interface providing a rich user
experience.
9.13. The OIS application shall be compliant with HTML5 (W3C) markup language or later.
9.14. The OIS application shall be compliant with W3C CSS validator, for all the style
definitions including standard normal and headlines CSS3 and HTML.
9.15. The system shall be able to integrate with Active Directory for determining user groups
and assigning user access permissions.
9.16. The System OIS shall be customised in terms of the JCAA’s corporate colours and logos.
10. COLLABORATIVE DECISION MAKING PLATFORM
10.1. The system shall be equipped with a collaborative decision making (CDM) platform to
facilitate CDM sessions between stakeholders.
10.2. The System shall be configured to serve as a web based access point for all Airspace Users
and ATFM stakeholders to coordinate and share information (access rights shall be definable
by the JCAA).
10.3. The System shall be capable of hosting a library of selected reference material for users’
access.
10.4. The System shall be capable of advising on the need for a collaborative decision making
session.
10.5. The System shall have calendar capabilities to step up CDM sessions.
11. THE ATFM DAILY PLANNING
11.1. The System shall have the capability to generate ATFM Daily Plans for airspace sectors,
airport or a flight information region.
Page 23 of 39
SECTION C – TECHNICAL REQUIREMENTS
11.2. The ATFM Daily Plan shall be easily generated from compiled information input from users
with the appropriate user access rights.
11.3. The fields of the ATFM Daily Plan shall be defined by the JCAA.
11.4. The ATFM Daily Plan shall have the followings fields but not limited to:
Anticipated Demand Information
TMM Planned
Weather Activity
Constraints
Special Events
Equipment Outages
Volcanic Ash Activity
11.5. The ATFM Daily Plan shall be easily generated from compiled information and displayed
or exported in PDF format for messaging and printing.
11.6. The ATM Daily Plan must be compiled from the latest available information.
11.7. The System shall be capable of archiving the ATFM Daily Plan at a set time every day.
11.8. The ATFM Daily Plan shall be accessible by all stakeholders; the user access right shall be
defined by the JCAA.
12. USER INTERFACE
12.1. The System Management GUI shall comply with the general User Interface Requirements
specified in the System Design Document and Implementation requirements sections.
12.2. The GUI shall provide access to on-line documentation and help, as per the documentation
requirements.
12.3. The update rate for windows displaying on-line (dynamic) information shall be
configurable, preferably on a per window basis.
12.4. Each user shall have the ability to adjust and sort the default position and size of individual
windows to be used upon accessing the System, i.e. default window configuration
parameters are to be saved by username.
12.5. The GUI shall provide users with methods to view, sort and search by user-selected fields.
12.6. All operator commands or interactions with the System which cause a change to the system
configuration or system status shall be logged.
12.7. The GUI shall allow a user to graphical view, indicating the status, of all message queues
currently containing messages.
12.8. It shall be possible to select a single queue from the bar chart and then access the messages
in a single list or view them filtered by priority.
12.9. The user shall be able to select one or more messages in a queue and perform at least the
following actions:
View;
Delete; or
Print.
Page 24 of 39
SECTION C – TECHNICAL REQUIREMENTS
12.10. The input and modification of system configuration parameters shall be via a system of
menus and graphical input windows which ensure for syntactic and semantic of all user
input.
12.11. The System shall cross-check the values input by the user against the existing configuration
to prevent clashes or inconsistencies in the configuration.
12.12. The majority of configurable system parameters shall be configurable on-line without the
need to restart the application for them to take effect.
12.13. Where appropriate, the System shall provide default values for ‘standard’ configuration
parameters, which the user will then have the option to change, rather than having to enter
all configuration parameters from scratch.
12.14. All changes to The System configuration shall be logged.
13. GEOGRAPHIC INFORMATION SYSTEM
13.1. The System shall provide a geographic information system (GIS) web application
comprising of at least a server and a client.
13.2. The GIS web application shall allow stakeholders to have access to aeronautical, weather,
and spatial databases.
13.3. The GIS web application shall be compatible with all popular web browsers.
13.4. The GIS web application shall have navigation capabilities such as pan and zoom, including
but not limited to:
zoom to coordinates;
Zoom to pre-defined area or initial extent.
13.5. The GIS web application shall have the ability to turn individual or grouped layers, on and
off.
13.6. The GIS web application shall have the ability to turn individual attributes/features (such as
terrain, cloud cover) of layer on and off.
13.7. The GIS web application shall provide multiple basemaps and allow user to toggle between
the basemaps.
13.8. The GIS web application shall have and allow users to view the legend.
13.9. The GIS web application shall have the capability that enables a user to adjust the legend or
transparency of a layer.
14. MAPPING TOOL
14.1. The GIS shall have a web mapping tool; the background colours shall be definable within a
range of RGB true colours which should not be distorted in the ambient lighting conditions.
14.2. Various layers of data shall be discretely definable in relation to the background colour, but
which does not conflict with the foreground colours.
14.3. The map functions shall be dynamic and shall be capable of displaying distance between
point to point and aircraft to point.
Page 25 of 39
SECTION C – TECHNICAL REQUIREMENTS
15. AIRSPACE CONFIGURATION
15.1. The System shall be capable of generating an optimum airspace configuration scheme based
on staff availability.
15.2. The System shall allow the user to define a new airspace sector as needed.
15.3. The System shall be capable of generating an optimum airspace configuration scheme based
on air traffic demand.
15.4. The System shall be capable of generating an optimum airspace configuration scheme based
on equipment outages.
15.5. The System shall be capable of generating an optimum airspace configuration scheme based
on weather conditions.
15.6. The System shall be capable of generating an optimum airspace configuration scheme based
on terminal or en-route constraints.
15.7. The System shall be capable of generating an optimum airspace configuration scheme based
on pre-defined special events.
16. REPORT METRICS AND ANALYSE PERFORMANCE
16.1. The System shall have an operational dashboard that provides strategic, tactical and post
operational metrics reporting and performance analysis.
16.2. The System shall provide the capability to capture and log all causes of delay. These shall
include but not limited to:
Weather Delays
Air Traffic Control Delays
Airport Delays and
Airspace Disruptions.
16.3. The parameters for the statistics being captured shall be configurable by the user.
16.4. The System shall be able to differentiate Traffic Volume statistics based on route, airport,
fix/NAVAID, airspace, sectors and TMM applied.
16.5. The System shall be configurable to provide specific ICAO Key performance indicators
such as:
Average delay per movement for departures
All-causes departure delay by hour of the day
Total Flights
Total Regulated Flights
Total Delayed Flights
Percentage of Regulated Flights
Percentage of Delayed Flights
Total Delay in Minutes
Average Delay per Movement
Average Delay per Regulated Flight
Average Delay per Delayed Flight
Page 26 of 39
SECTION C – TECHNICAL REQUIREMENTS
17. SYSTEM PERFORMANCE, RESOURCE USAGE AND AVAILABILITY
STATISTICS
17.1. Statistics
17.1.1. The System shall be able to generate the following types of monthly/yearly statistics
relating to The System:
Overall System Availability / MTBF / MTTR.
System Component Availability / MTBF / MTTR.
Average Resource Usage per computer, e.g.: - Average CPU Utilization -
Average Memory Usage - Average Disk Usage.
Peak Resource usage per computer, e.g.: - Peak CPU utilization - Peak
Memory Usage - Peak Disk Usage.
Circuit/Channel Availability.
System events e.g. component/link failures, automatic switching (failovers) of
redundant servers or network connection.
Number of alarms generated (per alarm type).
RFP# DECEMBER 2018 Page 27 of 39
TITLE: JAMAICA AIR TRAFFIC FLOW MANAGEMENT (ATFM) IMPLEMENTATION COMPLIANCE
STATEMENT
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
Page 28 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
1. DOCUMENTATION
1.1. General
1.1.1. Documentation shall be provided covering all aspects of The System.
1.1.2. All documentation shall be at a level of detail, which enables the Purchaser’s operational
and technical staff to fully understand and utilize The System.
1.2. System Implementation/Project Plan
1.2.1. The Tenderer shall appoint a certified Project Manager.
1.2.2. The Tenderer shall provide documentation indicating System Implementation Plan.
1.2.3. The Tenderer shall provide a detailed project schedule for System Implementation.
1.3. System Integration
1.3.1. The Tenderer shall provide documentation indicating how it will interaction/integration with
the JCAA Corporate network, if such interaction/integration is deemed necessary for
operation.
1.3.2. The Tenderer shall provide the following user documentation:
System Overview
System Design Documents
System Interface Documents
Operator manuals/handbooks covering all specialist roles and include quick
reference guides.
System maintenance and management manuals.
Software Detailed Design
Software User Manual (SUM).
1.3.3. The Tenderer shall provide examples of both operational and technical documentation with
its proposal submission so that the quality and thoroughness of the documentation can be
evaluated.
1.3.4. Any documentation being provided in soft-copy format (e.g. on removable media such as CDs
or DVDs, or via email) shall be in Microsoft Word format, protected document format or in
a format as otherwise agreed by prior arrangement with the Purchaser.
1.3.5. Unless otherwise stated, all documentation shall be provided to the Purchaser’s Project
Manager.
1.4. Technical Manuals
1.4.1. Standard Technical Manuals shall be supplied which provide comprehensive coverage of all
components of the System.
1.4.2. The Technical Manuals shall include the following at a minimum:
Top level functional descriptions.
Physical data and counting instructions.
Installation, configuration and operating instructions.
Page 29 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
Site level maintenance instructions and Line Replaceable Unit (LRU)
descriptions.
Interconnection wiring diagrams.
Schematics to the component level for specified equipment.
Operational user’s guide.
Formats and protocols for all interfaces (if required).
Service.
Spare Parts.
1.4.3. Technical Manuals shall be supplied with the equipment and systems delivered under the
contract.
2. ON-LINE DOCUMENTATION AND HELP
2.1. The System shall supply On-line Documentation and On-line Help.
2.2. On-line Documentation and On-line Help shall be provided for each of the sub-system user
interfaces, i.e.:
Air Traffic Situation Display
Traffic Management Measure
Collaborative Decision Making Platform
Operational Information System
Geographic Information System
AFTM Daily Planning
2.3. The On-line Help shall be:
Accessible from the screen that the user is currently using (i.e. provision of context
specific help).
Easy to use, e.g. provide the ability to navigate via links to access more detailed
help or help on related topics.
Detailed enough to be self-explanatory, without the user having to reference other
documentation.
2.4. The Tenderer shall provide examples of On-line Documentation - both operational and
technical - with its proposal submission.
3. QUALITY ASSURANCE PROGRAM
3.1. The Tenderer shall have or establish and maintain a Quality Assurance (QA) Program in
accordance with ANSI/ASQC-Q-90011994, American National Standard: Quality Systems
Model for Quality Assurance in Design, Development, Production, Installation and Servicing
and ANSI/ASQC-Q-9000-3, American National Standard: Guidelines for the Application of
ISO 9001 to the Development, Supply, Installation and Maintenance of Software.
3.2. The Tenderer does not have to be certified in order to satisfy this requirement, but shall have
a Quality Assurance Program in place, that fulfil the requirements in 3.1.
3.3. The Tenderer shall support the survey and audit of their Quality Assurance Program by the
Purchaser.
3.4. Such access shall be in accordance with a mutually agreed upon schedule, and will require
escort by Tenderer personnel.
Page 30 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
3.5. It is understood and agreed that the Purchaser will have no right to control or direct the
Tenderer to make any changes to its commercial operations.
4. TESTING
4.1. Inspection and Test
4.1.1. All items to be furnished hereunder shall be subject to source inspection by the Purchaser
prior to shipment (e.g. at the occasion of the FAT).
4.1.2. The Tenderer, if awarded contract, shall make available to the Purchaser the necessary
records, test equipment, operators, and personnel to assist the Purchaser’s inspection.
4.1.3. Such source inspection shall not relieve the Tenderer of the obligation to deliver items
which meet the applicable drawings and specifications.
4.1.4. The Tenderer shall be able to demonstrate that all required inspections and tests have been
performed on all products supplied as part of this contract.
4.1.5. The demonstration shall include, but not be limited to, inspection data, acceptance status,
as-built configuration, test data, and requirement/validation compliance matrix.
4.1.6. As-built configuration records shall be maintained at the shipping configuration level and
supplied with each delivered item.
4.1.7. The Tenderer, if awarded contract, shall supply a "Certificate of Compliance" with the
delivery of the System.
4.1.8. The Purchaser reserves the right to witness any testing performed by the Tenderer and/or to
perform any of the inspections or tests set forth in the specification when such actions are
deemed necessary to assure supplies and software conform to specified requirements. The
Purchaser also reserves the right to perform additional tests to prove compliance with the
specifications.
4.1.9. Records of inspections and test data, including serial number and revision, for each production
lot shall be shipped with the hardware (if applicable) and a copy kept complete and available
to the Purchaser for a period of at least 3 years from the end of the contract.
4.2. Verification requirements of this specification
4.2.1. The detailed verification philosophy, process, responsibilities and procedures shall be
described in the Tenderer’s Test Plan.
4.2.2. The verification of all requirements in the System specification shall be verified as early as
possible in the procurement process.
4.2.3. The verification level(s) and method(s) for each requirement shall be defined in the Test Plan.
4.2.4. The Tenderer shall provide all test equipment, tools services and all other facilities required
for all the tests identified in the Test Plan.
4.2.5. A data traffic simulator (data generator) shall be used to validate the System data handling
capacity and performance under peak loading.
Page 31 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
4.2.6. Where practicable and appropriate, the Tenderer shall make use of automated testing tools
which provide efficiencies and ensure repeatability of the testing.
4.3. Test Plan
4.3.1. The Tenderer shall generate a Test Plan and submit for approval by the Purchaser.
4.3.2. The Test Plan shall be consistent with the Requirements Compliance Matrix.
4.3.3. The Test Plan shall include a schedule of activities for the following:
Factory Acceptance Test.
System Integration and Testing (SI&T).
Site Acceptance Test (SAT).
System Stability Testing (SST).
Operational Readiness Testing.
4.3.4. The Tenderer shall provide Acceptance Test Procedures (ATPs) prior to commencement of
FAT and SAT.
4.3.5. The ATPs shall be comprehensive and include all of the details necessary to ensure that the
individual test procedures making up the overall Test Procedure and the associated testing can
be used to satisfactorily demonstrate that the equipment, software application, subsystems and
overall system comply with the specified requirements.
4.3.6. Each individual test procedure within an ATP shall include the following information:
Name of Test.
Test Objective.
Technical Specification Requirement(s) to be verified.
Verification method.
Relationship to other tests.
System element(s) required.
Test equipment or special facilities required (e.g. message simulator, data
recorders)
External equipment, facilities, services or interfaces required.
A step-by-step procedure for processing through the test.
Identification of the results that are to be recorded.
Criteria for determining the success or failure of the test.
Expected results at each step.
Any other comments or information relevant to the test.
4.3.7. The Tenderer shall provide in the tender submission, examples of FAT and/or SAT test
procedures used in recent tests of its ATFM system.
4.4. Factory Acceptance Testing (FAT)
4.4.1. The FAT shall be conducted at the Tenderer’s premises.
4.4.2. Factory Acceptance Test procedures and all related technical documentation required to
perform the FAT shall be provided.
Page 32 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
4.4.3. The Tenderer shall give to the JCAA thirty (30) days prior written notice with the details of
the time, date and place of factory acceptance tests.
4.4.4. At the occasion of the FAT, the Tenderer shall present all the system hardware to be provided
by the Tenderer.
4.4.5. The test procedures shall contain step-by-step instructions with an explanation of each test.
4.4.6. The FAT shall last a minimum of five (5) working days.
4.4.7. The FAT shall be performed in the presence of the Purchaser’s employees.
4.4.8. The Purchaser’s employees attending the FAT shall be allowed to actively participate in the
FAT.
4.4.9. The Tenderer's proposal shall include the cost for airfare to and from JCAA (business class),
travel medical insurance, hotel accommodation, ground transportation (hotel to factory) and
terminal transportation (airport to hotel and return) and Daily Subsistence Allowance
(USD$160 per day each participant) for five (5) personnel from the JCAA.
4.4.10. The Tenderer should provide in the tender submission, references to FATs which have been
performed with the System within the last three years.
4.4.11. All results of the Factory Acceptance Test shall be duly recorded and shall be signed by the
Tenderer’s representative and the JCAA.
4.4.12. All observations agreed on, and discrepancies noted during the Factory Acceptance Tests shall
be corrected by the Tenderer before the SAT.
4.4.13. If the JCAA appointed representative does not issue and sign the Factory Acceptance
Certificate (FAC), s/he shall immediately notify the Tenderer in writing with proper reference
to any tests in the approved Acceptance Test schedule or to any part of the Specifications
which the equipment has failed to meet. Minor failures, which do not adversely affect the
performance or operation of the equipment for the purpose intended, and subsequently subject
to modification by the Tenderer, shall not be considered as items preventing JCAA Factory
Acceptance.
4.5. Systems Integration and Testing (SI&T)
4.5.1. Following the installation of the System at the Purchaser’s premises and completion of any
system integration activities that is required, the Tenderer shall perform whatever tests are
necessary to ensure that the System is properly installed and integrated and ready for the
commencement of the SAT.
4.6. Site Acceptance Testing (SAT)
4.6.1. After the installation and integration of the System in Jamaica, the Tenderer shall perform a
SAT in accordance with the approved Site Acceptance Test Procedures.
4.6.2. The Tenderer shall submit the Site Acceptance Test Procedures four (4) weeks prior to the
test for review.
4.6.3. The SAT shall be designed to verify the full compliance of the installed equipment with this
specification in a manner satisfactory to the Purchaser.
Page 33 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
4.6.4. The tests shall be such that all aspects of the System’s functionality and compliance with the
specifications.
4.6.5. The Purchaser will ensure that the facility is properly prepared for installation in accordance
with the Tenderer’s specification.
4.6.6. The Tenderer shall list all dependencies that are required of the Purchaser including
Customer-furnished equipment.
4.6.7. The Tenderer shall prepare and submit an Installation Plan for Equipment.
4.6.8. The Tenderer shall provide an initial As-Built-Drawing Package.
4.6.9. Final submission of the As-Built-Drawing Package shall be made.
4.6.10. The Tenderer shall be responsible for ensuring that the installation, testing and commissioning
of the new ATFM system does not interfere in any way with the operation of the AMHS
system. In particular, it shall not cause any loss of, or delays to, AFTN/AMHS message traffic.
5. WAIVER/DEVIATION APPROVALS
5.1. The Tenderer shall request prior written approval for any waivers and deviations (non-
compliance) to the SOW and contractual requirements prior to submitting the non-compliant
item to the Purchaser for acceptance.
5.2. Any requests shall contain, as a minimum, a definition of the non-compliance, the effect on
applicable specification(s) and corrective action to preclude recurrence.
6. Corrective and Preventative Action
6.1. For any Quality Assurance findings (i.e. defective workmanship, non-compliance with
standards, etc.) a Corrective and Preventive Action (CAPA) will be issued to the Purchaser
by the Tenderer.
6.2. The Tenderer shall appoint a CAPA owner who is responsible for working the CAPA
internally and for providing the completed CAPA response to the Purchaser.
6.3. The completed CAPA response shall contain descriptions of Root Cause Analysis, Proposed
Corrective Action and Proposed Preventive Action along with the associated implementation
dates and objective evidence of all stated corrective and/or preventative action.
7. TRAINING
7.1. Comprehensive Training
7.1.1. The Tenderer shall provide comprehensive training so that the JCAA staff is able to utilize
the ATFM system to its full potential.
7.1.2. The tenderers proposal shall include all training costs and be itemized and shall include air
tickets (business class), hotel accommodations, ground transportation (hotel to factory),
transportation (airport to hotel), and Daily Subsistence Allowance (DSA) of USD$160 per
day per participant.
Page 34 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
7.1.3. The training shall have but not limited to the following:
The medium of instruction for all training courses shall be English, with presenters
fluent to ICAO level 6 English language proficiency.
All training materials and documentation shall be in English.
The Training shall be provided by qualified and experienced personnel.
Technical and Operational Training shall be provided.
The Training shall include formal training courses and on-the Job Training (OJT).
Each course shall consist of theoretic and practical components so that attendees
become familiar with the equipment/applications that they will be using.
For each of the courses, the Tenderer shall stipulate any pre-requisites for the attendees
e.g. qualifications and prior experience needed to derive maximum benefit from the
course.
The Tenderer shall provide in the tender submission, a course outline and syllabus for
each course which is proposed.
The Tenderer shall provide in the tender submission, samples of:
o Training notes/manuals
o Training Aids (PowerPoint presentations) from recently presented ATFM
system courses.
The Tenderer shall indicate the proposed duration of each course and the maximum
number of attendees for each course.
The Tenderer shall indicate the proposed duration of each course and the maximum
number of attendees for each course.
Each person attending a course shall be provided with comprehensive training notes /
manuals.
In addition to the above, 4 additional hard copies of the training notes / manuals shall
be provided for each course.
Soft copies of the documentation used for each course (e.g. slides and notes/manuals)
shall be provided in an editable format (e.g. Power Point presentations and Word
documents) so that the course material can be modified and used by the Purchaser’s
training staff to present courses to JCAA staff in the future.
The Tenderer shall provide an overall Training Plan document.
The Tenderer shall provide a document containing an outline for each training course
that is to be presented.
8. TRAINING COURSES
8.1. Where necessary, training/internship must be provided at vendor’s site or in an existing
operational environment, on a system already installed by the Tenderer.
The following courses shall be provided:
i. ATFM Overview
ii. ATFM System Operator/Supervisor Course
iii. AFP and GDP Development
iv. System Technical Maintenance Course
8.2. ATFM Overview
Training shall provide a comprehensive overview of ATFM – its concepts, components and
implementation.
8.2.1. Training shall include an overview of the Tenderer’s ATFM system.
8.2.2. Training should be a minimum of four (4) days in duration.
Page 35 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
8.2.3. Each training shall be presented a minimum of two (2) times. Each course shall be presented
to a minimum of five (5) attendees. Attendees will vary based upon the specific course.
8.3. ATFM Operator/Supervisor Course
8.3.1. The Tenderer shall provide the operational training required for the operational end users
(operators and supervisors) to perform their day-to-day activities whilst utilizing the System
features and functionality to their maximum potential and benefit.
8.3.2. Training shall cover all aspects of the operational configuration, usage and supervision of the
delivered ATFM system.
8.3.3. Training should be a minimum of five (5) days in duration.
8.3.4. Training shall be presented a minimum of two (2) times.
8.3.5. Each course shall be presented to a minimum of five (5) attendees.
8.3.6. Attendees shall be capable of explaining the functions and features of the System to other
users, after completing this training.
8.4. AFP and GDP Development
8.4.1. Training shall include a module that teaches user how to develop and apply an Airspace Flow
Program and a Ground Delay Program.
8.4.2. Training should be a minimum of three (3) days in duration.
8.4.3. Each training shall be presented at least once. Each course shall be presented to a minimum
of five (5) attendees.
8.5. ATFM Technical Maintenance Course
8.5.1. The Tenderer shall provide the technical training required for the technical staff to perform
their day-to-day activities whilst maintaining and using the technical aspects of The System
to its maximum potential and benefit.
8.5.2. Training shall cover all aspects of the technical support and maintenance of the delivered
ATFM system.
8.5.3. Training shall cover the technical maintenance and operation of the ATFM switch (servers
and associated operator workstations) and the ATFM User Agent terminals.
8.5.4. Training shall cover:
System installation and configuration.
System administration.
Use of The System Monitoring tools.
Fault diagnostics and the use of diagnostic tools.
Hardware fault repair (at the LRU level).
Use of software and hardware test tools and procedures.
Page 36 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
Release of Software upgrades and fixes supplied by the Tenderer during the
warranty and ongoing maintenance periods.
Stopping, starting and switching the operational systems (active and hot-
standby).
Switching to Contingency operations.
8.5.5. Training should be a minimum of ten (10) days in duration.
8.5.6. Training shall be presented two (2) times.
8.5.7. Each course shall be presented to a minimum of five (5) attendees.
9. PROGRAM REPORTS
9.1. The Tenderer shall provide status reports to the JCAA every two (2) weeks.
9.2. The purpose of such reports shall be for the Tenderer to provide insight into the Tenderer’s
progress, program planning and overall management approach.
9.3. All action items opened during the two weeks shall be recorded and tracked to resolution.
9.4. The reports shall be the basis for teleconferences to be held monthly or as otherwise agreed
between the Tenderer and the Purchaser.
10. REVIEWS
10.1. Monthly conference calls or video conferences shall be scheduled between Tenderer and
Purchaser personnel to address any issues that arise.
10.2. Quarterly Program Reviews (PMRs) shall be scheduled which will be conducted at alternate
facilities or via video conferencing. The PMRs will be scheduled to take account of current
project activities.
11. MODIFICATIONS
11.1. The Tenderer shall advise the Purchaser of any changes to form, fit or function in the design
of any item, unit or sub-system developed after the equipment has been supplied.
12. SPARES
12.1. In the case of COTS hardware, the Tenderer shall provide guarantees from the manufacturer
or local Tenderer that spares for the hardware will be available for a minimum of 10 years
following the end of the warranty period.
12.2. In case of the proprietary hardware, the Tenderer shall provide certificate guaranteeing a cost
escalation of not more than 25 % for the spares for a period of 10 years after expiry of the
warranty on the equipment.
13. WARRANTY
13.1. A three-year warranty shall be provided to cover the complete system.
Page 37 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
13.2. The warranty period shall commence upon the Purchaser’s formal acceptance of the System
following the successful completion of the SAT.
13.3. All hardware (servers, workstations, routers etc.) shall have a warranty of 3 years or for the
period specified by the manufacturer, whichever is longer.
13.4. The warranty shall include the provision of a help-desk service.
13.5. The Tenderer shall specify the baseline coverage to be provided by the help-desk (hours*days)
and the guaranteed response times for the warranty.
13.6. The Tenderer shall specify the guaranteed initial response times that will be in effect during
the warranty, i.e. the maximum elapse time, within which the Tenderer will initiate a response
following the logging of a fault.
13.7. The Tenderer shall indicate whether a 24*7 help desk facility can be provided.
13.8. The upgrading of the warranty’s normal help desk coverage to a 24*7 coverage shall be
offered as a separately priced option.
13.9. Software support shall be available for any operating system, database and application
software issues which arise during the period of the warranty.
13.10. The Tenderer shall provide procedures detailing how to exercise warranty actions from the
Purchaser’s sites in Jamaica.
13.11. In addition to providing telephone and email support, the Tenderer shall be able to connect to
The System remotely to resolve defects and issues.
13.12. During the warranty period the Tenderer shall provide all updated versions of the software
which have been produced to rectify problems with the baseline system or to meet the latest
ICAO requirements for the ATFM.
13.13. All warranty issues raised during the warranty period shall be deemed to be valid until they
are resolved.
13.14. All components used in the ATFM system shall be supported and available from the
equipment Tenderer for at least ten (10) years from the start of the warranty period.
13.15. The Tenderer shall be able to supply ongoing maintenance support for the System for a period
of at least five (5) years following the end of the initial warranty period.
13.16. The Tenderer shall provide in the tender submission, outlines of its standard or recommended
post-warranty maintenance approach for the software and hardware systems to be delivered
to Jamaica.
13.17. The Tenderer shall provide details of the coverage that is provided by their ongoing
maintenance support program(s) and any options that might exist.
13.18. The ongoing maintenance support shall include regular updates of all software applications
to keep the Purchaser’s system up-to-date with the Tenderer’s baseline product and compliant
with the latest ICAO requirements for the ATFM.
Page 38 of 39
SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS
13.19. The Tenderer shall indicate the number of software releases to be provided per year as part of
the ongoing maintenance support.
13.20. The Tenderer shall provide ongoing maintenance support for an initial period of five (5) years
at a fixed annual price for the duration of the 5 years.
13.21. The initial five-years Ongoing Maintenance Support shall be offered as a separately priced
option.
13.22. The Tenderer shall provide the option for the Purchaser to roll-over the ongoing maintenance
support for a period of a further five (5) years also at a fixed annual price for the duration of
the 5 years.
13.23. The Tenderer shall guarantee that the annual pricing of the second 5-year support period does
not exceed that of the first 5-year support period by more than a fixed amount (e.g. 25%). This
maximum escalation figure will be determined and set during Contract negotiations.
Page 39 of 39