TITLE: J A TRAFFIC FLOW MANAGEMENT (ATFM) SYSTEM · 2019. 2. 15. · j) Doc 9882 - Manual on Air Traffic Management System Requirements. k) Doc 9883 - Manual on Global Performance

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


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


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


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


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.



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


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


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


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


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.



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


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


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


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


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


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


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


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


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


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


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


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


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


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.


on air traffic demand.


on equipment outages.


on weather conditions.


on terminal or en-route constraints.


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


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).



STATEMENT

SECTION D – DOCUMENTATION, TRAINING, TESTING AND SPARE PARTS

Page 28 of 39


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


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


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


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


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


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


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


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


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


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


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