27 42 60 - Information Broker (IB)

AL ANBAR INTERNATIONAL AIRPORT
Information and Communication

Technologies
INFORMATION BROKER
Technical Specification
SECTION 27 42 60
AL ANBAR INTERNATIONAL AIRPORT TECHNICAL SPECIFICATION DOCUMENT
AL ANBAR - RAMADI 27.06.2023
CONTEXTS
PART 1 GENERAL....................................................................................................................... 3
1.1 SUMMARY..................................................................................................................... 3
1.2 RELATED DOCUMENTS ................................................................................................... 3
1.3 DEFINITIONS.................................................................................................................. 3
1.4 SYSTEM DESCRIPTION .................................................................................................... 3
1.5 APPLICABLE LAWS, CODES, RULES, REGULATIONS AND STANDARDS ................................. 4
1.6 DELIVERY, STORAGE AND HANDLING .............................................................................. 4
1.7 SUBMITTALS .................................................................................................................. 5
1.8 WARRANTY ................................................................................................................... 5
1.9 SOFTWARE SERVICE AGREEMENT ................................................................................... 5
PART 2 PRODUCTS .................................................................................................................... 6
2.1 SYSTEM REQUIREMENTS ................................................................................................ 6
2.2 DESIGN REQUIREMENTS................................................................................................. 6
2.3 PERFORMANCE REQUIREMENTS ..................................................................................... 6
2.4 SYSTEM MANAGEMENT ................................................................................................. 7
2.5 OPERATIONAL REQUIREMENTS....................................................................................... 7
2.6 HARDWARE ................................................................................................................. 18
2.7 SOFTWARE .................................................................................................................. 18
PART 3 EXECUTION ................................................................................................................. 19
3.1 GENERAL ..................................................................................................................... 19
3.2 INSTALLATION ............................................................................................................. 19
3.3 COORDINATION ........................................................................................................... 19
3.4 PROTECTION................................................................................................................ 19
3.5 QUALITY CONTROL AND TESTING ................................................................................. 19
3.6 CLEANING ................................................................................................................... 19
3.7 DEMONSTRATION AND TRAINING................................................................................. 19
3.8 FINAL REVIEW AND ACCEPTANCE ................................................................................. 19
3.9 SERVICE LEVEL AGREEMENT ......................................................................................... 19
INFORMATION BROKER 27 42 60 - Page 2 of 19

SECTION 27 42 60
INFORMATION BROKER
PART 1 GENERAL
1.1 SUMMARY
A. Section 27 42 60 contains the technical specification for AL ANBAR INTERNATIONAL AIRPORT’s

INFORMATION BROKER (IB) and hereinafter is collectively referred to as IB.
B. Comply with Section 27 05 00
1.2 RELATED DOCUMENTS
A. The following reference documentation shall provide guidance to the Employer in the detailed
design and execution of the project. During the course of Project implementation, Document
references which are not included below will be provided when available.
1. 27 05 00 - Common Works for Airport Systems
2. 27 42 10 - Airport Operational Database System (AODB)
3. 27 42 20 - Flight Information Display System (FIDS)
4. 27 42 40 - Baggage Reconciliation System (BRS)
5. 27 42 50 - Local Departure Control System (LDCS)
6. 27 42 70 - Travel Document Authorization System (TDAS)
1.3 DEFINITIONS
A. Comply with Section 27 05 00
1.4 SYSTEM DESCRIPTION
A. The IB is the interface between the Airport Operational Database (AODB) and other systems sharing
airport operations data. The IB ensures that revelant data is shared and available in all connected
systems, containing schedules, reference data and information about resources used within the
airport operation. This data is processed and distributed according to specific business and
operational rules. These rules depend on the operator’s procedures, guided by international
standards and regulations.

B. The Information Broker solution shall provide data integration and brokering services that require
access to data in a real -time message queuing format. It is recommended that the overall architecture
follow a Hub-and-Spoke model; with the Information Broker servi ng as the primary integration “hub”
and various system Host Adapters serving as “spokes”. The hub is responsible for managing all key
integration-related functions, such as routing, endpoint management, as well as ensuring security and
reliability of integration scenarios. This model will ensure strict separation between data providers
and consumers.
C. The IB specification shall include the following:
1. System core hardware and software, including all required licenses
2. Management workstation hardware, software and all necessary software licenses.
3. All interfaces required for the operation of the system as described.
4. System and supervision tool
5. Analysis and documentation of the business rules for the FIDS required by the Employer
6. Tests Plan, systems testing and commissioning
7. System Warranty as specified
8. Training
9. Test platform
10. Spare parts
1.5 APPLICABLE LAWS, CODES, RULES, REGULATIONS AND STANDARDS
B. The IB shall be compliant to latest following codes and Standarts;
1. Aviation Information Data Exchange (AIDX)
2. IATA Airport Handling Manual 32nd Edition or later
3. AO Annex 17-4.3.1
4. ACRIS working group definitions for web service interfaces.
1.6 DELIVERY, STORAGE AND HANDLING

1.7 SUBMITTALS
1.8 WARRANTY
1.9 SOFTWARE SERVICE AGREEMENT

PART 2 PRODUCTS
2.1 SYSTEM REQUIREMENTS
2.2 DESIGN REQUIREMENTS
B. The Information Broker shall be:
1. Modular in design to provide the message processing and queuing mechanism for processing
host data adaptor feeds into a common XML format for universal communication between
systems.
2. Open design to maintain compatibility by interfacing easily with other systems as well as
being portable and scalable. Information Broker shall use industry standard languages and
interface standards including XML, XSLT, HTML, and DHTML.
3. Reliable with ability to run continuously (24 hours a day 7 days a week) with service ori ented
architecture that is designed and developed to maintain maximum uptime. The services
should be self-correcting and should continue processing regardless if errors occur. SNMP
functionality may also be embedded in each service for health monitoring as well as other
monitoring activities.
4. Robust with testing to handle up to 50 database write changes per second.
5. Flexible interface utilizing host data adaptor services that exchange data with any external
data feed using a vast array of communication mechanisms as required.
6. Easy to Support and Manage via a web application client. This will allow users to monitor
data flowing through the Information Broker as well as system performance. Additionally,
users will be able to configure, add and remove host interfaces from the web application as
well as perform maintenance tasks.
2.3 PERFORMANCE REQUIREMENTS
A. General
1. The IB is classified as Critical.
2. The IB management application shall be capable of supporting fifty (50) concurrent users as a
minimum.
3. The IB shall be capable of registering unlimited number of users.
4. The IB shall be capable of managing unlimited number of inbound and outbound queues.

5. All interface messages shall be processed within three hundred (300) milliseconds.
B. Comply with Section 27 05 00
2.4 SYSTEM MANAGEMENT
2.5 OPERATIONAL REQUIREMENTS
B. General
1. The IB shall be implemented utilizing Commercial -Off-The-Shelf (COTS) middleware software.
2. The IB shall use XML as the primary interface description language, HTTP and FTP as pri ma r y
network protocols and SOAP (XML-RPC) as primary protocol.
3. The IB shall fully support AIDX as defined in IATA RP 1797a both receipt of data and
distribution of data to connected systems like DDS and BRS.
4. The IB shall support multiple middleware products.
5. The IB shall comply with the standards for open systems architecture, e.g., the IB shall
support TCP/IP and other industry standard network protocols.
6. If multiple middleware products are used for the IB, the Contractor shall integrate these
products into a single IB architecture.
7. The IB shall send data received from connected systems that are necessary to support daily
Airport operations to the AODB.
8. The IB shall ensure the data integrity of the message contents.
9. The IB shall guarantee the message delivery; if a failure occurs at any stage during the
message delivery process, the IB shall detect the failure and re-send the message.
10. The IB shall re-send all messages not received by a system due to system unavailability as
soon as the system becomes available.
11. The IB shall have the capability to initiate and send messages in response to events, e.g., the
IB shall detect and identify a system which becomes unavailable and notify all related
systems.
12. The IB shall have the ability to handle different message types, analyzing and parsing the data
for distribution across heterogeneous environments.
C. Hgh Availability

1. The IB shall initiate a life-check of a System if no data is received from a System during a ti me
greater than a pre-determined, user modifiable, interval.
2. The Contractor shall determine the maximum time interval allowed for no data reception by
the IB for each System that interfaces to the IB.
3. The IB shall be fully configurable, tunable and maintainable in full on-line produc ti on mode.
Therefore, a piece of equipment, sub-system and/or rule(s) for message distribution can be
added/removed and configured without degrading any IB functionality. Similarly, various
parameters such as time-out intervals, load-balancing factors and priorities may also be
changed dynamically in full production mode.
4. If a processor or a node fails or needs maintenance, then the current IB load on that
processor/node shall migrate to another processor/node of the computer without
interruption to the system processes.
5. The IB shall remain fully functional regardless of the failure of other system components.
D. Scalability
1. The initially defined handling capacity of the IB shall support the data exchange volumes
associated with an Airport handling:
i. 5 Million passengers per annum (mppa).
ii. 2.4 million baggages per annum.
iii. 3 flight departures per hour.
iv. 90 flight movements per day.
v. 600 flight status updates per day.
vi. Volume of non-aeronautical information equal to volume of aeronautical information.
2. The IB shall be designed with enough expansion capability to support the additional data
exchange volume associated with a 50% increase of initially defined capacity without major
changes to the hardware or software.
3. The IB shall be scalable by transaction volume, message length, complexity of rule(s) for
message distribution, total connected users and future expansion of components.
4. The IB expansion shall be possible without degrading availability, so that a new configuration
can be added dynamically as needed without interruption to the operation of the system.
E. Security
1. The IB input messages shall be identified to an owner. The owner of a particular message is
usually the source of the message and the responsible party who determines the handling of
the message taking into account, among other things, the security aspects of the message
and the recipients of the message.

2. The IB shall be implemented with a security feature that will prevent a remote instruction
being sent via the IB to halt or interrupt a System’s processing.
3. The IB shall provide security features on authorization, authentication and mes sage
encryption which are compliant to industry standards. These features shall be extended to
both all connected systems.
4. The IB shall have the capability to customize the security features depending upon the
security requirements of that system, e.g., a connection from the IB to system A may require
authorization only, while a connection from the IB to system B may require authorization,
authentication and message encryption.
5. The IB security features shall not carry a substantial performance overhead to either the IB or
the connected systems.
6. The IB shall provide full audit capability and traceability to allow the IB Administrator to
detect security problems.
F. High Performance
1. The IB shall store and access the processing rules in the IB computer’s memory (RAM) dur i ng
operations to preclude processing delays inherent in disk file input and output activities.
2. The IB shall send messages over the Infrastructure directly from the originating System to the
destination’s IB element without routing the message through intermediate IB servers.
3. The IB shall perform message parsing, repackaging, and distribution functions in active
memory, versus using physical disk media, to minimize message throughput times.
4. Processing time of the IB shall reflect the criticality of data delivery to connected systems.
Maximum allowable processing time will depend on the rules invoked but shall not exceed:
i. 10 milliseconds for direct forwarding (without parsing or repackaging).
ii. 200 milliseconds for messages requiring data analysis (content based routing).
5. The IB shall detect and stop the transmission of messages from sending Systems that do not
conform to pre-defined formats, and inform the sending Systems as well as the IB operator
when this happens.
6. The IB shall detect and throttle or stop the transmission of out of control message bursts, i.e.,
at an rate or frequency significantly greater than defined for normal operation (e.g. greater
than could be expected to clear a three hour back log), onto the network from Systems. This
is to prevent broadcast storms on the network. The sending Systems and the IB operator
must be informed when this happens.
7. The IB shall have ability to improve performance and load balancing automatically or with
minimum IB administrator assistance.

8. The IB shall have the ability to interrupt the processing of messages from or to designated
Systems in cases of Airport emergencies, such as a crisis, either automatically or with minimal
IB Administrator assistance.
G. Data Processing:
1. The proposed IB System shall provi de the following capabilities in the implementation of the
messaging interface(s):
i. Holding, Queuing and Rebroadcast capability.
ii. Prioritization of messages to / from different systems using user defined parameters,
such as message type or system priority.
iii. Guaranteed ordering by preserving the sending sequence when delivering messages.
iv. Interface failure detection and notification using alarms, SNMP, paging and e-mail.
v. Multiplexing Capability with ability to distribute messages in a one-to-many or ma ny -

to-one pattern.
vi. Guaranteed delivery by ensuring that messages are transmitted and received exactly
once, regardless of any network or communication failures.
vii. Load balancing by allocating messages and distributing load among interchangeable
servers.
viii. Transactional messaging by transmitting messages utilizing database type

transactions.
ix. Request/Reply services.
x. Publish/Subscribe with Multicast service to subscribers.
xi. Ability to filter information based on their contents.
xii. Business rules where messages, flows in and out of the AODB engine; the rules should
govern the generation of the out-going data from the incoming messages.
xiii. The interface shall include an authentication mechanism to ensure that a connection
may be established only with an authorized system.
H. Processing Rules
1. The IB shall pass incoming multi -record files to the destination System(s) without repackaging
if no parsing of records is required.
2. The IB shall send multi -record files that need repackaging between Systems to an internal
RAM buffer, where the multi-record file shall be parsed.

3. The IB shall then retrieve, repackage, and send the data as one or more new messages to the
destination System(s).
4. The IB shall time-stamp, and log to a permanent disk file, information about all messages
received and sent by the IB. This disk file can be displayed or be printed later for analysis. This
activity logging includes movement of data to and from the AODB. At a minimum the
transaction log shall consist of a time stamp, message ID, sending system, receiving
system(s).
5. Outgoing messages that cannot be delivered to the destination System(s) immediately due to
communications link problems or destination System non-availability shall be s tor ed wi thi n
the IB system.
6. The IB shall retrieve and forward data temporarily stored when communications link
problems or System non-availability situations are corrected.
7. The Contractor shall be responsible to define all IB data processing scenarios during the
System development. The data processing scenarios must be submitted to the Emp loyer for
approval.
8. The Contractor shall implement all IB scenarios identified and approved during development,
including, but not limited to, the following scenarios:
i. A forwarded message comprised entirely of data from the incoming message shall be
forwarded unchanged to the destination System(s).
ii. A forwarded message comprised partially of data from the incoming message shal l be
repackaged as a new message to the destination System(s).
iii. One or more forwarded messages based on the content of the incoming message and
comprised of:
a. All or partial data from the incoming message.

b. A combination of AODB data and data from the incoming message.
c. Predefined messages.
iv. A forwarded message comprised of some or all of the data from the incoming
message and some existi ng data from the AODB shall be repackaged as a new
message to the destination System(s). The IB software must retrieve the existing data
from the AODB to add to the new message.
v. When data from an incoming message must be repackaged with data that is not in the
AODB, the incoming message data shall be stored in the IB for later repackaging as a
new message when one of the following events occurs:
a. A second message containing the required data is received by the IB. The IB
software must retrieve the first mess age’s data and repackage it with the data
from the second message as a new message to the destination System(s).
b. The contents of a field in a second message received by the IB contains a pre-
defined value(s). The IB software must retrieve the first message’s data and

repackage it with the second message’s data as a new message to the destination
System(s).
I. Rule Management
1. Definition and maintenance of rules shall be done utilizing a graphical interface allowing
drag-and-drop assembly of rules.
2. It shall be possible to introduce new rules and amend existing rules in the operational IB
environment.
3. New rules can be prepared from scratch or be based on copies of existing rules.
J. Maintainability and Administration
1. The IB configuration shall be easy to maintain.
2. The IB shall have a set of user friendly System Management tools to monitor and administer
as a minimum the following functions:
i. The current status of each system and its network condition.
ii. The current status of all messages in the communication queues.
iii. A reporting capability including but not limited to audit trails and tracing and output
them either to the system management monitors or other third party device
supported by the operating system the IB is running.
iv. Performing the global administration tasks from a single console.
3. The IB shall provide all information necessary to the IB administrator to efficiently manage
the entire IB function.
4. The IB shall have the ability to handle the addition, modification and deletion of IB
element(s)/module(s) without affecting the operational effectiveness of the IB.
5. The IB shall have warm restart capability performing recovery functions after failure.
K. Error and exception handling
1. The IB shall provide warning messages and error and exception handling capability due to
system and communication failure or malfunction.
2. The IB shall have a reporting function and the capability to alert the IB Administrator to any
significant event essential for the operation of the IB.
L. Flexibility
1. The IB shall have the flexibility to handle technology provided by both sender and receiver of
messages, e.g., if system A sends a 10 megabyte image file on a regular basis to system B, the
IB shall have the flexibility to perform co-ordination of message transmission. The

information required for the image file, the sender and receiver shall be sent by system A to
IB, for recording or hand-shaking purposes, but the actual image file shall be transferred
directly from system A to system B. In this way the processing load on IB shall be reduced and
unnecessary network overhead avoided, hence improving overall performance.
2. The IB shall have the flexibility to provide different application program interface calls in
more than one interface.
M. Interface Management
1. The following interface management tasks and/or requirements shall be available withi n the
Integration Broker web application:
i. Manage Message Queues:
a. The Information Broker shall manage all message queues.
ii. Queue Connection List:
a. All message queue connection information, such as queue names and queue
paths, should be stored in and loaded from the database.
iii. Rules:
a. Data handling rules shall be configurable from the web application.
iv. Control Host Interfaces
a. The Information Broker shall control the host interface with the ability to stop,
start and restart them on demand.
v. Add Interfaces
a. Users shall be able to add installed host interfaces to the Information Broker.
vi. Remove Interfaces
a. Users shall be able to remove active host interfaces from the Information Broker.
vii. Configure Interfaces
a. Users shall be able configure host interfaces from the client web application such
as source message queue information. The meta -data shall be stored in the
database and retrieved by the host interface when it is started.
viii. Lists - Provide Code Mapping for Fields
a. Certain data may be expressed in different ways by different destination or

sources; interfaces should be able to convert values from one to the other. For

example some airports use IATA codes while others use ICOA, the interface should
be able to accept either and output either. Developers should additionally have
the ability to program lists which can be managed within the Client web
application.
ix. Interface Statistics Alert Thresholds
a. When statistics reach certain configurable thresholds, there shall be an option to

send an alert via several different protocols such as e-mail or SMS.
x. J. Some Recommendations of Interface Statistical Alerts Include:
a. Number of messages on queue:

 If there are too many messages on the queue, this could indicate that the
service has stopped processing, or is processing slowly.
b. Process times exceeded:

 If messages are taking too long to process, this could indicate performance
issues with the code or the system.
c. Minimum Transaction Rates:

 This should indicate the minimum number of transactions that should be
processing through the interface in a specified time frame. If the service is not
processing enough messages in a specified time frame it could indicate that
there are performance issues with the code or with the system.
d. Maximum Time Between Messages:

 This should indicate the maximum amount of time between processing two
transactions. The resulting alert could indicate the source is not sending
transactions, or there is an issue retrieving messages from the queue.
xi. Interface Error Handling
e. Interface errors should be dealt with in several ways:

 Manual: The error may require manual user intervention to determine how to
proceed. The user can decide to purge the message from the queue and
continue with the next message, or let the message continue retrying until it
succeeds
 Purge: In some cases, there is nothing that can be done to make a message
succeed and the message shall need to be removed from the queue and
skipped.
 Restart: If the host interface has become frozen or unresponsive, the interface
service may need to be restarted to continue processing.
N. Data Handling Requirements
1. The following data handling tasks and/or requirements shall be available within the
Integration Broker web application:

2. Host Interface Management
i. From the dashboard of the web application, users shall be provided with a high -level
overview of the current state of the Information Broker system. Users shall then be
able to navigate to more detailed information from the dashboard.
3. Message Queue Management
i. Users shall be able to add, remove, and edit message queue information from the web
app. Users shall also be able manage what interfaces queues are subscribed to.
4. Message Re-Injection
i. Messages that are re-injected may be subjected to a review process before being
placed back on the host interface queue. Users shall be able receive approval requests
to re-queue past messages. If the message is approved to be reprocessed by the
interface, it will be placed back onto the host interface queue for processing.
ii. Available Approval Processes shall include:
a. Manual
 Message must be manually approved by a user before being sent back to the
interface queue
b. Automatic
 Message is automatically approved and sent back to interface queue.
5. Data Flow Menu Item
i. The Information Broker shall have the ability to autonomously graph the installed
interfaces within a simple Logical Interface Diagram.
6. Data flow Visualizations
i. GUI items shall be used to allow the user to get a visual idea of how data is flowing
through the interface.
7. Data Viewer
i. Users shall be able to view inbound data, outbound data, and log information from
the web app.
8. Data Information Lists (Airlines, Airports, IATA/ICOA)
i. Lists of data, such has IATA/ICOA codes, should be stored in the database.
9. Graph Incoming Data
i. Statistics on incoming data shall be viewable in graph form from the web app. These
graphs shall update in real -time and shall also include system performance
information.
10. HIF Configuration

i. All configuration information for the host interfaces should be stored and loaded fr om
XML in the database. This shall allow editing of interface.
O. Support Log Requirements
1. The following support log tasks and/or requirements shall be available within the Integrati on
Broker web application:
2. Data Logging
i. All logging information shall be written to tables in the database, including data
received and data sent by an interface.
3. Inbound Log
i. Inbound transaction data shall be stored in the database. This data shall be
displayable from the client application.
4. Outbound Log
i. Outbound transaction data shall be stored in the database. This data shall be
displayable from the client application.
5. Error Log
i. Error information shall be logged in the database. This data shall be displayabl e fr om
the client application.
6. Audit Log
i. Ties Inbound, Outbound, and error log together by message GUID and indicates
whether message succeeded or failed.
7. Interface Logging
i. Data shall be stored with information that identifies witch host interface generated
the log so information can be shown per host interface.
8. Search Logs using keywords
i. Log data shall be searchable using keywords from the client application
9. Event Notifications
i. Notifications shall be generated when statistics reach certain configurable thresholds ,

for example when the transaction rate limit has been reached. The notifications can
then be sent using one or multiple protocols. Available Protocols shall include: SNMP,
E-Mail and SMS
10. Message Routing

i. Subscription information for different interfaces should be stored in the database.

This shall be used to determine everywhere a particular message needs to be
published.
P. Administration, Security and Redundancy Requirements
1. The following administrative, security and data redundancy tasks and/or requirements s ha l l
be available within the Integration Broker web application:
2. Backup Connection String
i. Client shall fail-over and use the backup connection string in the event that the
primary database is unavailable.
3. Log Shipping
i. Data shall be transferred from the primary database to the secondar y database(s)
using log shipping.
4. Log Settings
i. Ability to select interface applications and threads to log
5. DB Heartbeat
i. Service shall periodically write information to the database to indicate that the
interface is still running, and to check that the data base is still running. If the service
stops writing to the database, it may be frozen and need to be restarted. If the service
can’t reach the database, it needs to fail -over to the secondary database.
6. Purge
i. The Information Broker client web application shall allow users to adjust purging rules
for the interfaces such as purge thresholds.
7. Enterprise Level Encryption
i. Sensitive data such as user names, passwords, and transaction data that shall be
stored in the database and transferred between queues shall be encrypted using AES
(Advanced Encryption Standard)
8. Users/Passwords
i. User name and password information shall be encrypted using AES.
13. The web application shall allow a user to monitor data flowing through The Information
Broker and system performance. Users shall also be able to configure, add, and remove host
interfaces from the web app, as well as perform other maintenance tasks.

2.6 HARDWARE
2.7 SOFTWARE
B. INTEGRATION
1. All data interfaces between the IB and other AIT shall utilize the Airport ESB/IB System. The
systems which requires integration are listed below but not limited to:
i. AODB
ii. BRS
iii. FIDS
iv. LDCS
v. TDAS
vi. CUPPS/CUTE
vii. CUSS
viii. MCS

PART 3 EXECUTION
3.1 GENERAL
3.2 INSTALLATION
3.3 COORDINATION
3.4 PROTECTION
3.5 QUALITY CONTROL AND TESTING
3.6 CLEANING
3.7 DEMONSTRATION AND TRAINING
3.8 FINAL REVIEW AND ACCEPTANCE
3.9 SERVICE LEVEL AGREEMENT

27 42 60 - Information Broker (IB)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

27 42 60 - Information Broker (IB)

Uploaded by

Copyright:

Available Formats

AL ANBAR INTERNATIONAL AIRPORT

Information and Communication

INFORMATION BROKER 27 42 60 - Page 2 of 19

A. Section 27 42 60 contains the technical specification for AL ANBAR INTERNATIONAL AIRPORT’s

B. Comply with Section 27 05 00

1.2 RELATED DOCUMENTS

1. 27 05 00 - Common Works for Airport Systems

2. 27 42 10 - Airport Operational Database System (AODB)

3. 27 42 20 - Flight Information Display System (FIDS)

4. 27 42 40 - Baggage Reconciliation System (BRS)

5. 27 42 50 - Local Departure Control System (LDCS)

6. 27 42 70 - Travel Document Authorization System (TDAS)

A. Comply with Section 27 05 00

1.4 SYSTEM DESCRIPTION

INFORMATION BROKER 27 42 60 - Page 3 of 19

C. The IB specification shall include the following:

1. System core hardware and software, including all required licenses

2. Management workstation hardware, software and all necessary software licenses.

3. All interfaces required for the operation of the system as described.

4. System and supervision tool

6. Tests Plan, systems testing and commissioning

7. System Warranty as specified

10. Spare parts

1.5 APPLICABLE LAWS, CODES, RULES, REGULATIONS AND STANDARDS

A. Comply with Section 27 05 00

B. The IB shall be compliant to latest following codes and Standarts;

1. Aviation Information Data Exchange (AIDX)

2. IATA Airport Handling Manual 32nd Edition or later

4. ACRIS working group definitions for web service interfaces.

1.6 DELIVERY, STORAGE AND HANDLING

A. Comply with Section 27 05 00

INFORMATION BROKER 27 42 60 - Page 4 of 19

A. Comply with Section 27 05 00

A. Comply with Section 27 05 00

1.9 SOFTWARE SERVICE AGREEMENT

A. Comply with Section 27 05 00

INFORMATION BROKER 27 42 60 - Page 5 of 19

2.1 SYSTEM REQUIREMENTS

A. Comply with Section 27 05 00

2.2 DESIGN REQUIREMENTS

A. Comply with Section 27 05 00

B. The Information Broker shall be:

4. Robust with testing to handle up to 50 database write changes per second.

2.3 PERFORMANCE REQUIREMENTS

1. The IB is classified as Critical.

3. The IB shall be capable of registering unlimited number of users.

INFORMATION BROKER 27 42 60 - Page 6 of 19

B. Comply with Section 27 05 00

2.4 SYSTEM MANAGEMENT

A. Comply with Section 27 05 00

2.5 OPERATIONAL REQUIREMENTS

A. Comply with Section 27 05 00

1. The IB shall be implemented utilizing Commercial -Off-The-Shelf (COTS) middleware software.

4. The IB shall support multiple middleware products.

8. The IB shall ensure the data integrity of the message contents.

INFORMATION BROKER 27 42 60 - Page 7 of 19

i. 5 Million passengers per annum (mppa).

ii. 2.4 million baggages per annum.

iii. 3 flight departures per hour.

iv. 90 flight movements per day.

v. 600 flight status updates per day.

vi. Volume of non-aeronautical information equal to volume of aeronautical information.

INFORMATION BROKER 27 42 60 - Page 8 of 19

i. 10 milliseconds for direct forwarding (without parsing or repackaging).