technical appendix a – the amhs system requirement definition

Technical Appendix A –

The AMHS System Requirement

Definition

Amendment Record

Issue Date Reasons For Change Section

Amended Author Remarks

Version 1.0 22/12/14 IAA

References and Related Documents

Version 1.0 IAA Tender For AMHS

Appendix A – Technical Requirements

of 275File Name: Log_mifrat_2014_197_0013_00.DOCX Saved: January 29, 2015

Table of Contents

Chapter 0 - Guidelines and Instructions for the Bidder's Technical Response 8

0. Guidelines and Instructions for the Bidder's Technical Response 9

0.1 Chapter's Objectives 9 0.2 Definitions & Terms 9 0.3 Order of Precedence 9 0.4 The Tender's Technical Appendices Structure 9 0.5 The Technical Requirements Document Structure 10

0.5.1 Appendix A 10 0.5.2 Annexes to Appendix A 10 0.5.3 Appendix B 10

0.6 General Highlights and Guidelines 11 0.7 Classification of Requirements in the Technical Chapters 13 0.8 Guidelines for the Bidder’s Response to the Technical Chapters 15

0.8.1 The Required Structure of the Technical Proposal 16 0.8.2 Guidelines to a structure of "Free Text Response" 18 0.8.3 Guidelines to the "Formatted Response" 18

Chapter 1 - Objectives & Background 21

1. Objectives & Background 22

1.1 Background 22 1.2 Project Primary Stakeholders 22 1.3 Telecommunication Center Operations 23

1.3.1 Center’s System & Operations 23 1.3.2 Network and Connectivity Data Flow 23 1.3.3 Flight Plan Data Distribution 24 1.3.4 Challenges with the Current Operations 24

1.4 AMHS Solution Objectives 25 1.5 The AMHS Solution Scope 25

1.5.1 Deliverables 25 1.5.2 System Implementation and Deployment Principals 27

1.6 Governing Standards 28 1.7 Project Requirements 29 1.8 Maintenance Requirements Highlights 30 1.9 Bidder and IAA Scope of Supplies 31

1.9.1 Bidder’s Scope of Supplies 31 1.9.2 IAA's Scope of Supplies 32

1.10 Appendix 1-a1 – Terms & Abbreviations 32 1.11 Appendix 1-a2 – Applicable Standards 32

Chapter 2 - System Architecture and Design Principles 33

2. System Architecture and Design Principles 34

2.1 Major Design Considerations 34




2.2 High Level System Architecture (Q) 37 2.2.1 General 37 2.2.2 System Architecture (schematic diagram) 38 2.2.3 AMHS Core Sites 38 2.2.4 System Users and Interfaces 39 2.2.5 System Architecture Principles 40

2.3 System Description Directives 41 Chapter 3 - User’s Functional Requirements 42

3. User’s Functional Requirements 43

3.1 General 43 3.1.1 AMHS UA Terminal 43 3.1.2 Standards 43

3.2 Messaging 44 3.2.1 Supported Messages 44 3.2.2 Message Creation 44 3.2.3 Message Management 46 3.2.4 Message Mailboxes 47 3.2.5 Message archive 49 3.2.6 Admin 49

3.3 Supporting Tools/Utilities 50 3.3.1 Printing 50 3.3.2 Attachment Handling 50 3.3.3 Statistics & Reports Subsystem 50

3.4 HMI 51 3.4.1 HMI General Requirements 51 3.4.2 HMI Performance Requirements 51 3.4.3 HMI Features 52

Chapter 4 - System Requirements 55

4. Message Handling System Requirements 56

4.1 Introduction 56 4.2 General 57

4.2.1 Highlights 57 4.2.2 Applicable Documents 57

4.3 AMHS Functionality 57 4.3.1 Definitions 57

4.4 ATS Message Server and Message Management Requirements 58 4.4.1 General 58 4.4.2 Message Lifecycle High Level Scheme 59 4.4.3 Message Reception Requirements 60 4.4.4 Messages from External Sources (P, Q) 61 4.4.5 Message Validation Requirements 61 4.4.6 Message Error Handling Requirements 62 4.4.7 Queues and Message Store Requirements 62 4.4.8 Message Routing and Dispatch Requirements 63 4.4.9 Alternate Routing 64 4.4.10 System Logs and Reports 65




4.4.11 System Message Retrieval 65 4.4.12 Correction/Cancellation of Messages 66 4.4.13 Message Re-Transmission and Redirection (Redirect) 67 4.4.14 AMHS / AFTN Gateway and Message Conversion Requirements 67 4.4.15 AMHS Addressing 68

4.5 AMHS System Performance 69 4.5.1 Communication / Switch Performance 69 4.5.2 Capacity 69 4.5.3 Response Time 70

4.6 AMHS System Technical Management 71 4.6.1 General 71 4.6.2 Central System Management 72 4.6.3 Operator / Admin service mailbox 72 4.6.4 AMC Support 74 4.6.5 System Monitoring 74 4.6.6 System Diagnosis and Statistics 76 4.6.7 System Alarms 77 4.6.8 System Fault and Error Handling 78 4.6.9 USERS' Management 78

Chapter 5 - Interfaces Requirements 80

5. Interfaces Requirements 81

5.1 Interfaces with External Systems 81 5.1.1 General 81 5.1.2 Interfaces Overview 82 5.1.3 Interfaces types and characteristics 85

5.2 Interfaces requirements – connected networks 88 5.2.1 AMHS/X.400 Interface (P) (Q) 88 5.2.2 CIDIN/AFTN Interface (P) (Q) 89 5.2.3 SITA Interface (P) (Q) 90 5.2.4 WMO/IMS Interface (P) (Q) 90

5.3 Interfaces requirements – IAA systems 91 5.3.1 AIS/AIM Interface (P) (Q) 91 5.3.2 AODB (CHOCS) System Interface (P) (Q) 92 5.3.3 Frequentis AG Smart Strips System (EFS) and Integrated Operational

Data System (IODS) Interface (P) (Q) 93 5.3.4 A-SMGCS Interface (P) (Q) 94 5.3.5 EWAM Interface (P) (Q) 95 5.3.6 ATIS/VOLMET System Interface 96 5.3.7 TelePC Interface (P) (Q) 97 5.3.8 UAT Interface 97 5.3.9 Command & Control System Interface (P) (Q) 98 5.3.10 Other interfaces (Q) 99

Chapter 6 - Information Technology Infrastructures Requirements 100

6. Information Technology Infrastructure 101

6.1 General 101 6.1.1 General Guidelines 101




6.1.2 System Infrastructure Requirements (IAA's Supplies) 101 6.2 System Environment and Survivability 103

6.2.1 System Environment and operational modes 103 6.2.2 System Robustness and Resiliency 104 6.2.3 System Availability 106

6.3 IT Centers 108 6.3.1 Installation 108 6.3.2 Electrical Environment 109

6.4 Communications Requirements 110 6.4.1 General 110 6.4.2 Communication Links’ Characteristics 111 6.4.3 IP Addressing 111 6.4.4 Communications security 111 6.4.5 Network Time Synchronization Service - NTP Servers 113

6.5 Information Security Requirements 114 6.5.1 Information Security Concept 114 6.5.2 Application Level Security 114 6.5.3 Operating System Level Security 115 6.5.4 LOGs Management 116

6.6 System Control, Management & Monitoring 118 6.6.1 General Requirements 118 6.6.2 Control & Management 118 6.6.3 System Monitoring 119 6.6.4 Maintenance Working Position 120 6.6.5 Reports 121

6.7 Information Technology Software and OS 122 6.7.1 Operating System Guidelines and Requirements 122 6.7.2 Software Integrity Assurance 123 6.7.3 Development and Maintenance Environment and Tools 123 6.7.4 Database / Data Store 123 6.7.5 Licenses 124

6.8 Information Technology Hardware 125 6.8.1 IAA’s General Requirements for Servers Infrastructure 125 6.8.2 Performance 125 6.8.3 Hardware requirements 125 6.8.4 Storage 126 6.8.5 Working Positions & Peripherals Requirements 126

Chapter 7 - Scope of Work (SOW) and Bidder’s Details 128

7. The Project's Scope of Work (SOW) 129

7.1 Background and Highlights 129 7.1.1 Chapter Objectives 129 7.1.2 Overview of the Project's Objectives 129 7.1.3 Overview of the Project's Implementation 130 7.1.4 Major Future Expansion Options 133

7.2 The Bidder, Project Team & Organization – Reference Model 135 7.2.1 Involved Parties (Including Subcontractors) 135 7.2.2. Project's Organization 137




7.2.3. Bidder's Project Team 139 7.3. Project's Lifecycle – System Implementation Process 143

7.3.1. Introduction 143 7.3.2. Setting Up the Complete System / Project Plan – Overview 143 7.3.3. Setting up Future Options 146 7.3.4. Reviews 147 7.3.5. Major Sub- Stages – Activities and Deliverables Overview 149 7.3.6. Project Plan 164 7.3.7. Tests 167 7.3.8. Training 175 7.3.9. Documentation 177 7.3.10. Involvement of the Bidder in the CFE activities 179 7.3.11. Installation Requirements 179

7.4. Project Lifecycle – Reference Managerial Process 183 7.4.1. Introduction 183 7.4.2. Managerial Process Objectives 183 7.4.3. Forums & Meetings 183 7.4.4. Reports 187 7.4.5. Deliverable Management 188 7.4.6. Quality Assurance 189 7.4.7. Risk Management 190

Chapter 8 - Warranty, Service and Maintenance 195

8. Warranty, Service and Maintenance 196

8.1 Introduction 196 8.1.1 SMP Section 8.5.2 Guidelines for the Bidder 196 8.1.2 Definitions 197

8.2 Service and Maintenance Principles 201 8.2.1 General 201

8.3 Implementation Concept 204 8.4 Scope – System's Components 205

8.4.1 Spare Parts 205 8.4.2 The Maintenance Working Position 206 8.4.3 COTS and 3rd Party Components 206 8.4.4 Test Equipment (if required) 207

8.5 Scope – Services 208 8.5.1 The Core Service - Definition 208 8.5.2 The Core Service – Breakdown to Related Services 208

8.6 Procedures 215 8.6.1 AFTN / AMHS Help Desk 215 8.6.2 Fault Severity Classification 215 8.6.3 Diagnostics and Repair Planning 216 8.6.4 Malfunction Repair / Corrective Maintenance 216 8.6.5 Planned / Preventive Maintenance 216 8.6.6 Maintenance Reporting and Documentation 217 8.6.6.1 Maintenance Report 217 8.6.6.2 Configuration Management Report 219 8.6.7 Service Level Escalation 219




8.6.8 Monitoring, Supervising, Control and Coordination 219 8.7 Service Level Agreement (SLA) 221

8.7.1 Required Availability and Service Level Parameters 221 8.7.2 Highlights 222 8.7.3 Fulfillment of required SLA and availability 222 8.7.4 Alternative maintenance model 223 8.7.5 SLA Monthly Report Sample 224

8.8 Failure Scenarios Handling Description 226 Chapter 9 - Bill Of Quantities (BOQ) 227

9. Bill of Quantities (BOQ) 228

9.1 General 228 9.1.1 Guidelines and instructions for the Bidder 228 9.1.2 Quantities and Expandability - Reminder 230 9.1.3 The BOQ Tables 230 9.1.4 The Tables Structure 231

9.2 Setting Up the System 233 9.2.1 Scope of Setting up the Complete System 233 9.2.2 Services during the Service and Maintenance Period 236 9.2.3 System Related Components 237 9.2.4 Spare Parts and Test Equipment 241

9.3 Option 1 – DRP – Third Leg 243 9.3.1 General 243 9.3.2 Scope of Option 1 243 9.3.3 System Related Components 243 9.3.4 Labor Related Components 243

Annex 1-A - Terms & Abbreviations 244

Annex 1-B - Applicable Standards 250

Annex 1-C – Technologies at IAA 253

Annex 1-D - IAA's Quality Assurance Guide Lines 268




Chapter 0 - Guidelines and Instructions for the Bidder's Technical Response




0. Guidelines and Instructions for the Bidder's Technical

Response

0.1 Chapter's Objectives

This chapter contains general guidelines, information and specific directives regarding the way the Bidder should respond to the Technical Requirements chapters of this Tender, as well as the required structure of the Technical Proposal, and how it should be submitted. This information is relevant to the Bidders' selection process and for the purpose of effective evaluation and fair comparison of the Bidders' proposals.

0.2 Definitions & Terms

See Annex 1-A Terms & Abbreviations.

0.3 Order of Precedence

In the event of any conflict among the Tender Documents (including conflict between different documents combining one volume thereto), the Bidder shall be obligated to comply with the stricter requirement on the Bidder's part, unless otherwise determined by the IAA. Any such conflict will be brought immediately to the attention of the IAA.

0.4 The Tender's Technical Appendices Structure

The Technical Requirements and the Bidder's Formatted Response (the Compliance Tables) are organized in two appendices to the Tender Documents:

1. Appendix A – The Technical Requirements: Chapters 0 – 9.

2. Appendix B – Compliance tables (CT) for The Bidder's Formatted Response: CT for chapters 1-8

3. Appendix C – Statement Form;

4. Appendix D – Price Proposal Form;




0.5 The Technical Requirements Document Structure

0.5.1 Appendix A

1. Chapter 0 – Guidelines and Instructions for the Bidder's Technical Proposal (current chapter).

2. Chapter 1 – Objectives and Background.

3. Chapter 2 – Systems' High Level Reference Architecture.

4. Chapter 3 – Functional Requirements Definition.

5. Chapter 4 – AMHS System Requirements Definition.

6. Chapter 5 – Interfaces with External Systems.

7. Chapter 6 – Information Technology and Management. This chapter describes the requirement of end stations, the servers, the communication network, information security and various Information Technology Infrastructure and issues which are required in the system. System Management, both Operational and for Maintenance purposes is introduced as well.

8. Chapter 7 – Scope of Work (SOW) and Bidder’s Details.

9. Chapter 8 – SLA for Warranty, Service and Maintenance.

10. Chapter 9 – Bill of Quantities (BOQ).

0.5.2 Annexes to Appendix A

o Annex 1-A – Terms & Abbreviations o Annex 1-B – Applicable Standards o Annex 1-C – IAA's Security, Information Security and Confidentiality

Guide Lines o Annex 1-D – Technologies at IAA o Annex 1-E – IAA's Quality Assurance Guide Lines

0.5.3 Appendix B

Appendix B is comprised of an Excel document including 3 tables in which the Bidder is requested to provide the Formatted Response as follows:

Table of Compliance Readiness and Provability: The Bidder shall summarize its compliance with each requirement included in the Technical Requirements chapters 1, 2, 3, 4, 5, 6, 7, 8.

Table of Non-Compliance: a table in which the Bidder details each and every requirement that is not fully met by its Response.




Table of Over-Compliance - a table to describe those requirements that the Bidder can offer more than is required by IAA.

A detailed explanation of how to fill these tables is presented in paragraph 0.8.3 - Guidelines to the "Formatted Response".

0.6 General Highlights and Guidelines

1. IAA is looking for a Technical Proposal that adheres to the following principles, as much as possible:

a. Based upon stable and well proven platforms; (The Bidder is requested at Chapter 7 to provide details of previous installations).

b. Based on "off the shelf" products with minimal customization and/or integration and/or development.

c. The Bidder should describe well proven capabilities of the proposed products following the structure of the Technical Requirements Chapters.

The Technical Proposal structure shall directly corresponds to the structure of the Technical Requirements chapters. The response to each of the clauses must follow the structure and details thereof. A detailed explanation of the requested structure of the Technical Proposals presented on paragraph 4. A table of references from IAA’s requirements to various documents’ clauses is unacceptable.

IAA explicitly declares that the Requirements aim to enlarge the requested product(s) capabilities rather than to narrow them. Therefore the Bidder should describe its product's well proven relevant capabilities, even if they extend beyond the scope required by IAA. The Bidder is expected to provide full details of their AMHS solutions. For avoidance of doubts, IAA emphasizes the following:

a. IAA prefers no special software developments that would be made exclusively to fulfil this or other requirement that appears in the Technical Requirements chapters. IAA would like to gain the benefits of a proven solution that is functioning and operational at other sites.

b. An advantage in quality evaluation will be among others:

Operational provability in production.




Number of systems supplied of the same or equivalent such as offered in the Bidder's Proposal.

Compliance with the related functional, performance and maintenance requirements listed within this RFP.

The Bidder should respond to each requirement presented in the Technical Requirement Chapters with two kinds of responses (detailed guidelines are given in clauses below):

a. Formatted response – a response that amounts to marking or inserting a value in a cell of a predefined given table, (e.g. Compliance Table, Non-compliance Table), as detailed on paragraph 0.8.3.

b. Free text response – where the Bidder is required to respond in a free text, with no restrictions such as format, values, etc. The Bidder should be aware that in the evaluation of the Technical Proposal, IAA takes into consideration both the Bidder's Proposal and the risk to IAA it involves. A laconic response such as: "fully complied" or "read, understood and accepted" to a requirement which is classified "Q" and the Bidder was asked to provide details of what is being proposed, may present a risk to IAA. IAA cannot effectively evaluate what is being proposed by the Bidder, thus cannot effectively assess whether the Bidder fully understood what is required by the IAA. Therefore, IAA encourages the Bidder to take full advantage of the "stage" that is given for a comprehensive response and use it to reduce the risk to IAA by doing the following:

i. Demonstrate and prove that it has thoroughly understood the IAA's requirement.

ii. Provide sufficient information and explanation about the way that the Bidder solution meets the requirement and how the request is going to be executed or implemented in a way that minimizes IAA's risk in adopting the proposed solution.

Detailed explanations and examples from other installations / customers / other sources, and the complete end-to-end example which are requested in Chapter 7, paragraph Annex 7-A– Experience, Goodwill and Customers, should also be used by the Bidder to demonstrate that it has fully understood the IAA required solution.

Validation method - as a general guideline, for each requirement within the Bidder's scope of supplies, a written compliance statement by the Bidder's should be an integral part of the validation method. In addition, wherever necessary, an approval from an authorized laboratory and / or an authorized expert (such as a qualified civil engineer, or qualified electrician, etc.) or a documented compliance with a certain industry standard shall also be provided by the Bidder.




Generic product descriptions (such as marketing material) are acceptable only as appendices to the Technical Proposal. Any such appendix included in the Proposal must not replace a complete response that is required for each requirement in the Technical Requirements chapters.

IAA’s RFP process will allow a clarification phase in which Bidders may submit questions and clarifications requests to the RFP documents and requirements. At the conclusion of that phase, Bidders who discover yet another clarification need may make reasonable assumptions based on best experience and understanding of IAA needs, and complete the Technical Proposal based on these assumptions. The Bidder shall clearly specify all the assumptions made.

0.7 Classification of Requirements in the Technical Chapters

1. The classification, if given to a requirement / paragraph, appears either at the paragraph / Section heading or at the requirement body or at the end of the requirement text.

A classification of a paragraph applies to all elements and/or sub-clauses of that clause, unless explicitly indicated otherwise.

Classification definitions:

(P) Technical Project Deliverable Requirements Requirements contained in the Technical Requirements Chapters, including both those without any classification, and those classified with “Q” to which The Bidder responded, form the minimum obligations that The Bidder must fully comply with and shall be referred to as the "Technical Deliverable Requirements". These requirements should be fulfilled at least as described.

Requirements contained in the Technical Requirements Chapters which are classified with (P), form the minimum Contractual obligations that The Awarded Bidder must fully comply with during the Contract's term and shall be referred to as the "Technical Deliverable Requirements".

These requirements should be fulfilled at least as described.

These Requirements are not a mandatory condition for the Proposal Submission the method and the phase(s) for verifying that the System meets these requirements will be defined at the VRTM as stipulated in Chapter 7.

(Q) A clause classified as (Q) shall be evaluated for quality,




and its score will be part of The Bidder’s final score of the Technical Proposal.

A clause may be classified as (Q) and (P) / (O) at the same time by indicating (P, Q) or (O, Q). For instance, a clause classified as (P, Q) means a "P" requirement that is also evaluated for quality as a "Q" requirement.

A clause classified only as (Q), is a highly desired requirement; However the Bidder is not obliged to comply with completely. (E.g., The Bidder may choose whether to comply with the requirement, or to over comply, or to partially comply or not to comply with it). In all cases mentioned above, the proposal will not be disqualified automatically.

The Bidder’s response to each of the requirement classified as (Q) shall be evaluated as part of the Technical Grade of the Proposal.

The Bidder should note that a precondition for evaluation of the Price Proposal is a minimum Technical Grade of 80 points (The Bidder should be aware that there is not a Technical Threshold Grade for a single requirement, the aforementioned threshold is for the entire proposal).

The Bidder is obligated to provide both a "Formatted response" and a "Free Text Response" as specified in section 0.8.2 Guidelines to a structure of "Free Text Response and section 0.8.3 Guidelines to the "Formatted Response", for requirements classified as (Q). Such responses shall constitute an inseparable part of Bidder's Proposal and shall bind the Bidder for any and all matters in connection with the Proposal.

For avoidance of a possible misunderstanding, IAA highlights that by responding Over Comply or Fully Comply or Partially Comply, whatever the Bidder proposed, shall oblige it at the same manner as (P) requirement at the time of implementing the requirement, i .e. the verification method that the System meets the Bidder's Response to these requirements will be defined at the VRTM as stipulated in Chapter 7.

Since (Q) requirements are highly desired, declining




significant amount of the (Q) requirements may cause that such a proposal will not pass the technical threshold grade (80), even if all other requirements will be technically evaluated as 100.

(O) Option: A requirement classified as (O) is optional for IAA and may be implemented during the contract period. However, The Bidder is obligated to propose a solution or to comply with the requirement, but IAA would not be obligated to purchase and/or implement the requirement.

(O,Q) As part of the requirements classified as (O) the IAA may include requirements that will be evaluated as part of the Technical Grade that will be marked as (O, Q). Any requirements classified as (O, Q) will bind The Bidder in the event that IAA will choose to implement such requirement. A requirement within an Option may be marked as (Q) which indicates that the Bidder is not obliged to fully comply with. For avoidance of a possible misunderstanding, IAA highlights that by responding Over Comply or Fully Comply or Partially Comply, Whatever the Bidder proposed shall oblige it at the same manner as (P) requirement whenever IAA decides to exercise any of the Options, i .e. the verification method that the System meets the Bidder's Response to these requirements will be defined at the VRTM as stipulated in Chapter 7.

(P,Q) Such a requirement is a Technical Deliverable requirement (P) that will be evaluated as part of the Technical Grade (Quality) of The Bidder’s response. In addition this requirement will be evaluated as part of the Technical Grade (Quality) of The Bidder’s response.

(E,O) A requirement that is classified (E, O) is an Elective Option. I.e., it is at the sole discretion of the Bidder whether to respond to such a requirement or not. If the Bidder responds to such a requirement it is requested to specify the Cost associated with this requirement in the Cost Forms; However, neither the cost nor the benefits will be evaluated for the either the Cost Grade or the Technical Grade.

0.8 Guidelines for the Bidder’s Response to the Technical Chapters

As mentioned in the general guidelines, the Proposal structure should be in one-to-one correspondence with the structure of the Technical Requirements chapters. This means that the Response shall have similar chapter division as in Appendix A – Technical Requirements.




0.8.1 The Required Structure of the Technical Proposal

1. The Technical Proposal should be written in the English language, using Microsoft Word (and other MS-Office XP/2007 tools, including Visio).

2. The Technical Proposal should have the following sections/chapters:

Chapters of the Bidder's Proposal

Subject Comments

Executive Summary Executive Summary Free format by The Bidder – has no corresponding chapter in the Technical Requirements

Response to Chapter 1 Objectives and Background and high level scope

The Bidder may use its response to Chapter 1 as high level description of its solution's contribution to meet IAA's objectives and specific characteristics. Since Chapter 1 is classified as (Q), the response of the Bidders to Chapter 1 provides it an opportunity to draw its solution in higher level than the single requirement level (which is more frequent in other chapters). The evaluation of the Bidder's response to Chapter 1 will contribute to Bidder's Capabilities evaluation (see Section 10.2 in the Invitation).

Response to Chapter 2 Systems' High Level Reference Architecture

Response to Chapter 3 Functional Requirements Definition

Response to Chapter 4 AMHS System Requirements Definition

Response to Chapter 5 Interfaces with External Systems Response to Chapter 6 Information Technology and

Management

Response to Chapter 7 Scope of Work (SOW) and Bidder’s Details

No additional comments.

Response to Chapter 8 SLA for Warranty, Service and Maintenance

Response to Chapter 9 Bill of Quantities (BOQ) Only quantities without prices (for quality and comparison evaluation)

Annexes Annex 1-A Terms & Abbreviations Annex 1-B Applicable Standards

Appendices / Attachments

Response to Compliance Tables The Bidder should fill in the provided tables a




Chapters of the Bidder's Proposal

Subject Comments

"Technical Appendix B – Compliance Tables"

(3 tables for each chapter: 2, 3, 4, 5, 6, 7, 8)

formatted response as detailed on paragraph 0.8.3 below




0.8.2 Guidelines to a structure of "Free Text Response"

1. This paragraph shall not narrow the requirements set forth in the Invitation regarding the submission of the Proposal.

As its Technical Response the Bidder shall submit the response documents in the structure specified at paragraph 0 above.

The paragraphs' numbering of the Response documents shall directly correspond to the paragraph numbering of the Technical Requirements Chapters 1-9. This is mandatory so IAA can easily identify which response is made to each requirement.

The response should be in free text format and in the English language. It shall follow the general guidelines and any specific directives that may be given in the Requirement text (e.g. "The Bidder shall specify at least 2 examples of…" - such a directive should be strictly followed in the response).

0.8.3 Guidelines to the "Formatted Response"

1. In "Technical Appendix B – Compliance Tables" the Bidder shall provide a formatted summary of its Technical Proposal in the form of three tables.

Definitions of these tables, their meanings and significance, as well as explanations of how to fill them, are specified in the following sub-clauses.

In the event of any conflict between the Bidder's Formatted Response and its Free Text Response, the Bidder shall be bound by the stricter response, unless otherwise decided by the IAA.

0.8.3.1 Table of Compliance, Readiness and Provability

1. For each Chapter with requirements that the Bidder shall respond to, there is a corresponding table of "Data Hiding" & “Compliance, Readiness and Provability”.

Below is an example of such a table, with possible Bidder formatted response in RED "X" detailed explanation for each category follows:

Table "Compliance, Readiness and Provability"

Paragraph & Classification Compliance Readiness Provability

Paragraph item numbers

Paragraph Test Class.

Over

Full

Part.

None Can Be

DevelopedCustomization

Required

Can Be Supplied out

of the Box

POC / Working at R&D

Laboratory Working on a Customer Site

3.2.2 Requirement's text & Class.

X X X




Compliance: The Bidder shall mark with an X the degrees of compliance with

the referenced requirement according to the following levels of compliance: c. Over - the Bidder's proposed solution exceeds, or goes beyond the

specified requirement.

d. Full - the Bidder's proposed solution fully complies with the specified requirement.

e. Part (Partial) - the Bidder's proposed solution only partially complies with the specified requirement, e.g. it can only function with deviations from the specified requirement.

f. None - the Bidder's Proposal does not comply with the specified requirement, either when the Bidder cannot supply what is required at all, or cannot supply it within the timeframe requested.

Readiness: Self-explanatory, see table headings.

Provability: Self-explanatory, see table headings.

0.8.3.2 Table of Non-Compliance

IMPORTANT NOTE:

The IAA shall assume that the Bidder's Proposal fully complies with each and every requirement in "Technical Appendix A – Technical Requirements" unless specified in this table. In other words: if a requirement is not included in this table, IAA shall consider it as having been included, to its full capacity, in the Bidder's Proposal.

In this table, the Bidder shall insert all the paragraphs that appear in Appendix A's "Table of Compliance, Readiness and Provability" for which "Compliance" = "Partial" or "Compliance" = "None".

To remove any doubt, if a paragraph does not appear in "Table of Non-Compliance", this requirement is assumed to have been fully met by the Bidder's Proposal.

0.8.3.3 Table of Over-Compliance

In this table, the Bidder should describe all well proven relevant capabilities of its product that go beyond that requested by the Technical Requirements.

1. The Bidder should describe its product's well proven relevant capabilities, even if they were not explicitly required in the Technical Requirements.




The Bidder shall list the features not requested in the Technical Requirements but that are considered relevant to the proposed system.

For each feature listed, if applicable, the Bidder shall refer to the proposal location or the paragraph numbering of the relevant requirement in the Technical Requirements chapters.

The entries in this table may correspond to a specific paragraph number of the Technical Requirement chapters if the extensive capabilities relate to it, or the Bidder may add entries without a corresponding paragraph number at its own discretion.




Chapter 1 - Objectives & Background




1. Objectives & Background

1. This chapter is an executive summary and provides the Bidder with an overview of this tender's objectives. Any inconsistency between this chapter and the chapters 2-9, chapters 2-9 prevail.

2. The Israel Airports Authority (hereinafter “IAA”) is requesting proposals for a complete integrative solution for Aeronautical Message Handling System (hereinafter "AMHS", and/or "the System") to be installed at Ben Gurion Int. Airport as a Turnkey Project and requested options, with as many COTS components as possible.

1.1 Background

1. The IAA is the government agency that is responsible for the management, operation and maintenance of civil airports and border crossings in Israel. In this capacity, the IAA is also responsible for managing Civil Aviation operations and Air Traffic Services in the Israeli Flight Information Region (FIR). More information about IAA may be found at www.iaa.gov.il

2. As an ATS and ANSP provider, the IAA is responsible for the operations of all ATC operation – tower and control centers, the AIS offices and the connectivity to the international civil aviation networks – the AFTN and other civil aviation networks such as SITA

3. The IAA also operates the civil aviation airports in Eilat, Herzelia, Rosh Pinna, and Haifa and the currently under construction new Ramon airport at Timna (near Eilat)

1.2 Project Primary Stakeholders

1. The IAA telecommunication center (hereafter the "Center") is part of the Operating Center in the Ground Operation department. The Center is located at Ben Gurion international Airport near Tel Aviv. The primary stakeholders are:

The Ground Operation Department Manager – responsible, among other things, on the Operation Center and the Center.

The Operation Center Manager – responsible, among other things, on the Center.

The Center Manager – responsible for the telecommunication staff and systems.

The Center staff – the main users, who are the operating and maintenance personnel of the AMHS.




1.3 Telecommunication Center Operations

1.3.1 Center’s System & Operations

1. The IAA telecommunication center (hereafter the Center) is located at Ben Gurion international Airport near Tel Aviv. The Center staff is considered the primary user group of the AMHS. The Center is responsible for following operational assignments

a. Operating the Telecom center 24/7

b. Monitoring and preventing problems and errors within the MHS Network and hardware and software components

c. Managing problems and errors through resolution within the system and the network domestic and international

d. Maintaining and managing the links to the international communication partners according to the AMC regulations

e. Assisting all users with monitoring flight plan data for all arrival and crossing aviation traffic

f. Locating missing data for per users request

2. The telecom center is functioning 24/7 with 2 shifts operation. The main task of the team is to monitor and maintain the operational critical flow of information throughout the system and ensure uninterrupted operation

3. The following table provides the current message volume for the AFTN system. The table represents a random month volume:

International Link

Messages Received Per Month

Messages Sent Per Month

Larnaca 351,169 361,039

Athens 30,175 28,403

London 113,068 26,233

Cairo 3,834 4,157

Amman 5,156 3,921

Total 503,402 423,753

1.3.2 Network and Connectivity Data Flow

2. The Center is the IAA hub for the data flow in AFTN network. The Centers staff oversees the flow from the IAA AFTN international communication partners:




London, Nicosia, Cairo, Amman and Athens. In addition, there is a vast network of end-users within the IAA network as well as external to the IAA network.

3. Among these end-users are the IAA ATC units, BGN and Eilat AIS centers, airlines, handling companies, military units, Israel Meteo Services and the Ministry of Transportation

1.3.3 Flight Plan Data Distribution

1. One of the critical elements of the MHS for IAA is the sharing of flight plans, ATS messages, NOTAM and METEO data with other IAA internal systems and additional external data clients.

2. In this capacity, the center, through the MHS, facilitates the core of the civil ATM operations throughout the Israel FIR. Therefore, the distribution of the noted data is critical to the continued uninterrupted aviation operations to, from and within Israel.

1.3.4 Challenges with the Current Operations

1. The global transition from the legacy X.25 protocol to the AMHS and X.400 mandated by ICAO requires the IAA to follow suite and make the necessary system adjustments. The IAA communication partners are also gradually transitioning to AMHS based systems and therefore requesting that the connection between the entities be updated accordingly. In addition, the Israel civil Aviation Authority (CAA), the civil aviation regulator, is mandating IAA to acquire an AMHS based system.

MHS ‐AFTN

Airlines

AIS Center

Handling Companies

ATC

AirportsIsrael CAA

Israel Air‐force

IAA Systems

Israel MET

Services




2. The IAA is required to maintain links with certain international communication partners. These lines are challenging for maintenance by the Israel telephone provider.

3. The IAA is facing increasing pressure from communication partners to switch the main lines from the current X.25 based to IP based links. To that end, one of IAA main X.25 lines will be terminated by the end of 2014, thus a solution is urgently required.

1.4 AMHS Solution Objectives

1. Create reliable and secured high performance AMHS based MHS to support current and future IAA interconnectivity needs.

2. Provide solid platform to enable IAA to effectively maintain the domestic and International communication partners and expand the network if necessary.

3. Support long term scalability requirements in the Telecom Center operations.

4. Provide a user-friendly platform to create existing and future interfaces.

5. Improve the Center user experience in terms of functionality and usability.

6. Improve the end-user community experience in terms of functionality and usability.

7. Maintain a high level of data integrity.

1.5 The AMHS Solution Scope

1. The design principle of the AMHS solution shall permit a modular enhancement and expansion of the system which will allow the setting up of additional international and domestic lines as well as system interfaces – as summarized in the sections below and in full detail in Chapters 2 and 5.

1.5.1 Deliverables

1. The system high level architecture is illustrated in the following chart. The required AMHS Solution functional and technical components are described in full detail in the following chapters 2 – 9 of "Appendix A – Technical Requirements".

2. The AMHS Solution components shall be installed at Ben Gurion Airport with clients located throughout Israel.

3. The required Initial AMHS Solution includes:

a. Back to back redundant architecture with no single point of failure.




b. Rubust tier one level system with the following components

i. Primary and Secondary Servers running the AMHS application

ii. Three main types of Working Positions:

(1) Telecom Center working operation positions (2) System Management Working Administrator Position (3) Remote terminals (UAT) for external users

iii. Statistics, reports and archiving subsystem

c. External systems interfaces to (See Chapter 5 for further details):

i. AIS system

ii. ATIS and Volmet system

iii. TelePC (IAA domestic towers FDP)

iv. Frequentis SmartStrips (EFS - Electronic Flight Strips system)

v. Frequentis TAPtools (IODS – Integrated Operational Data System )

vi. BGN AODB

vii. Israel METEO Service

viii. SAAB/Sensis’ Advanced Surface Guidance and Control system (A-SMGCS)

ix. Era’s EWAM system

d. The main groups of users:

i. Telecom Center

ii. AIS Center and Coordination Center

iii. External users




AMHS System High Level Architecture

1.5.2 System Implementation and Deployment Principals

1. The system, once deployed, is to be integrated within the IAA Ben Gurion LAN with all the necessary firewall defenses as defined by IAA personnel.

2. The system is to be implemented side by side with the legacy system, thus allowing parallel operations until the final cutover is achieved. The purpose of this setup is to allow sufficient time for the new system to be stabilized and for the IAA team to reach readiness.

3. The Awarded Bidder should elaborate in regards to the process of establishing the International links with neighboring countries. This process being perceived as the most complex. The vendor should describe the process from the preliminary stage through testing up to the point where the link is in full production - including the ICAO registration

4. The Awarded Bidder is expected to support the process of setting up and establishing the traditional X.25 links and helping passing the AMHS Conformance and Interoperability Tests as part of the project and system scope.




5. The Awarded Bidder shall propose how to support the process of setting up and establishing the International AMHS links as part of the project and system scope as an option to the IAA for every site ready to interconnect

6. The system interconnectivity shall be easily scalable allowing the IAA to add additional international and domestic connections with minimal effort. It is safe to assume that IAA will add additional domestic users and will consider the expansion of the international communication partners network beyond the current five partners: Amman, Cairo, Nicosia, London and Athens

7. The system architecture is to be defined in collaboration with the IAA Telecommunication Center, the IAA Networking and Information/System Security teams (see Annex 1-C). The logic behind the requirement is to ensure a smooth and seamless integration of the new system within the IAA overall network architecture.

8. The system shall be designed in such a manner as allow for a third leg for DRP purposes should the IAA decide to add a DRP location.

9. The IAA is expecting that the proposed system solution should be scalable, and allow for potential future expansion as the IAA needs change over time. in particular the IAA is looking at the following growth aspects:

a. UAT expansion – The IAA envisions a growing need in this area allowing additional users to be able to use UAT. Past experience has shown that new terminals are required to support the growing and evolving operational needs.

b. Operator Workstations – while unlike the UAT, the growth requirements within the Operators’ workstation is more predictable, The IAA would like to keep the current ability which allows for the deployment of additional clients based on the evolving needs.

c. Interfaces – as stated in this chapter, The IAA is expecting constant demands to deploy interfaces to new systems.

d. Offsite DRP system – based on the IAAs DRP plans, it is expected that in the future an additional offsite system will be deployed to support a DRP scenario.

1.6 Governing Standards

1. The IAA is obligated by the CAA to adhere to industry International standards and recommendations. Therefore, the solution shall comply with the International Civil Aviation Organization (ICAO) directives, World Meteorological Organization (WMO) and all additional governing standards for the duration of the system life cycle. The Awarded Bidder is required to support and meet all




regulatory recommended changes by the established operational date set by the relevant agency.

2. A detailed list of relevant standards and recommendations is listed in Appendix 1-a2 – Applicable Standards below.

1.7 Project Requirements

1. The Awarded Bidder shall propose a complete “Out of the box” integrative solution for the required AMHS solution as a Turnkey Project, with as many COTS components as possible. The Scope of Work (hereinafter "SOW") is detailed in chapter 7.

2. All COTS components shall be of tier 1 vendors. The IAA reserves the right to approve and/or request a substitute component. The selected vendor shall be responsible for confirming that all COTS components can be serviced in Israel by a local authorized dealer. Furthermore, all COTS products proposed shall be distributed routinely in Israel.

3. As is frequent with information systems, many issues are identified during the initial time post go-live point – also referred to in chapter seven as the Soak Test. The vendor is expected to provide support during that period and provide all necessary fixes and software updates at no additional cost to the IAA.

4. The required Turnkey Project shall include: site surveys, RRD, design, interface development, customization and FAT, supply, installation and commissioning, assimilation and integration with the IAA Infrastructure and relating applications, including all required adjustments, modifications, interfaces, delivery, documentation, end-user training, technical training, SAT, Soak Readiness Period, Soak and warranty, service and maintenance support (for at least 10 years).

5. The Awarded Bidder shall take full responsibility for the complete integrative solution, which may be comprised of an assortment of components, possibly from different suppliers, without compromising the contents, quality, schedules, functionality and all other requirements specified in this tender.

6. The Awarded Bidder shall function as the Solution Integrator, taking full professional responsibility and accountability for the complete solution provided to the IAA, for the entire duration of the contract, as addressed in chapter 7 (SOW) for the duration of the Project execution, and in Chapter 8 for the warranty, service and maintenance period.

7. The Awarded Bidder shall have in-house, all the necessary capabilities, know-how and supplies required under this Bid. If that is not the case, the Bidder shall present to the IAA its plan to complement its capabilities, qualifications, products and such, using other highly skilled subcontractors with proven successful




experience in supplying services and goods as required in this Tender. The overall responsibilities are of the selected vendor.

8. For more details regarding relevant issues, such as: involved parties, division of roles between the involved parties, minimal experience. Please refer to chapter 7 clause 7.2.1.

9. In order to alleviate all doubt, it is hereby clarified that the provisions of Section 1.5 stipulated above shall not take from any of the Awarded Bidders undertakings and/or obligations and/or warranties stipulated in the tender documents.

10. The Awarded Bidder shall bear sole responsibility for thoroughly and carefully reading the tender documents and for the performance of professional examination of the undertakings and financial implication of the Bid.

11. The Awarded Bidder will carefully study all relevant matters and details that might affect the execution of the project by the Awarded Bidder in accordance with the provisions of the contract, including and notwithstanding, the scopes of supply, works and services and their completion periods and all risks (technical and financial) as related within the Technical Requirements.

12. Project Schedule – The project shall be set in two stages: Basic-AFTN Stage and AMHS Stage. The first stage will cater the same services as the current AFTN services for all its users and the second stage will certify the system ad AMHS ready. The whole project shall take up to 12 months from ARO, where stage 1 shall be completed after up to nine (9) months from ARO and stage 2 up to three (3) months after the completion of stage 1.

1.8 Maintenance Requirements Highlights

Support and maintenance requirements are a critical factor for the IAA. As stated in previous paragraphs, the system is perceived to be mission critical, and as such, there is a strong need for minimal down time. Therefore, the following are the IAA Maintenance and support requirements from the Awarded Bidder:

a. The Awarded Bidder is required to provide back to back system support in order to ensure continued operations

b. The Awarded Bidder shall operate a 24/7 support center during the warrantee and maintenance phases.

c. The support center shall be staffed with trained technicians who shall be able to provide immediate diagnostic support in order to resolve and consult on any problem within the system

d. The IAA requires that upon resolution, the Awarded Bidder shall send a detailed report regarding the problem, the root cause and any relevant preventive action plan.

e. The Support and Maintenance concept shall be subject to the SLA as described in chapter 8.




1.9 Bidder and IAA Scope of Supplies

1.9.1 Bidder’s Scope of Supplies

1. The Awarded Bidder's major supplies for the first Stage of implementation are detailed in chapter 9 BOQ, and will include:

A. Setting Up the Basic System:

Fully redundant AMHS system installed in two (2) different sites at the Ben Gurion Int. airport

All hardware and data communications required for the system

Test environment

AFTN and AMHS links required hardware

Operators workstations clients

End users remote workstation clients

Spare parts as required

Interfaces as described in Chapter 5

Services: project management, complete system installation and deployment, testing (including long term tests – the Soak Test), training, documentation, warranty and maintenance support, support as needed to establish international AMHS and AFTN links

B. Expansion Options:

In addition to the basic system, the IAA may consider to purchase any of the options stated:

DRP – Third Leg

Training Course in Israel (travel cost included)

Training Course at the Bidder's Location

Additional Training Day

Bidder consultancy Rate

Bidder’s project manager Rate

Bidder’s systems analyst Rate

Bidder’s programmer

Bidder’s technician

Special service call

Per Diem Room and Board

Air Travel




1.9.2 IAA's Scope of Supplies

1. Involvement of the Awarded Bidder in accompanying, guiding, controlling and approving of the CFE (Customer Furnished Equipment) and other supplies by the IAA (as detailed in Chapter 9) during the basic system setup and later on in the routine operation, such as:

Server farm space requirements for the systems.

Redundant UPS based power supply requirements.

Dedicated logical network and data communications (LAN & WAN) as needed.

Hardware racks as required – TBD.

Support of the IAA technical teams – Linux, Networking, Sys admin, system security.

Needed onsite logistical support in the form of airside entry permits, parking etc.

Interfacing systems ICD's (if available) and / or support.

1.10 Appendix 1-a1 – Terms & Abbreviations

See Annex 1-A Terms & Abbreviations

1.11 Appendix 1-a2 – Applicable Standards

See Annex 1-B Applicable Standards




Chapter 2 - System Architecture and Design Principles




2. System Architecture and Design Principles

1. The purpose of this chapter is to describe the IAA’s desired AMHS System’s high level architecture, design considerations, principles and concepts, as well as to offer a “free stage” for the Bidder to present the proposed system architecture and characteristics.

2. The Bidder shall give an overview description of his full AMHS Solution in response to this chapter. (Q)

2.1 Major Design Considerations

The System design shall meet the following principles:

1. Reliability:

a. The System shall be able to perform all its required functions under all operational and environment conditions as per the system performance and functional specifications within this tender. (Q)

b. The System shall be built based on high standards and first-tier equipment (e.g. servers, communications, and workstations) and proven software to supply the highest standards of working and stable environment, responsive and user friendly operational conditions. (Q)

c. The System shall be able to monitor the various HW and SW components, detect and alert when system faults occur and bypass (when possible) these faults to allow continuous operation. (Q)

2. Survivability:

a. The System shall have sufficient redundancy to meet the required availability as outlined in the technical requirements of this tender. (Q)

b. Fail Safe - sufficient redundancy shall be provided to carry data to permit some components of the System to fail without any resultant loss of data (Q)

c. Fail Soft - the System shall be designed so that even if an element fails, the effect on other elements shall be such that the system functionality and performance degradation should be minimized and reduced to the failed element.(Q)

d. The System shall be DRP capable, i.e., the System shall support two remote sites (operational and contingency), while providing “Online“ Backup of operational data, and support a switchover capability between them in less than 10 minutes. The distance between the sites can be up to 400 km away, where the network between them should be LAN or WAN. (Q)

e. The system operational/contingency site shall be fully redundant and comprised of two computer nodes (Primary and Secondary), which will comprise the complete AMHS environment. The Primary and Secondary computer nodes will be situated




in different geographical locations, with a standard communications network between them.

f. The system shall be ready to accept a "Third Leg" as an option should IAA decide to deploy one for DRP purposes to an additional remote site. The site can be up to 400 km away and network between them should be LAN or WAN.

3. Interoperability:

a. The System shall comply with related international standards and in complete coordination with the latest ICAO standards , Annex 10( latest version),and standards as detailed in Annex A-2 to this tender and any other applicable standards that provide full operational functionality of the AMHS system.

b. The System shall support the ability to interconnect with external systems by means of standard interface protocols.(Q)

c. The Bidder shall fully cooperate during the selection process and subsequently after the contract signing process, with all external systems’ suppliers that will be involved in the external system interface interconnection with the AMHS. (Q)

d. The Bidder shall provide all relevant information, such as Interface Control Document (ICD), respond to any technical questions, etc. (Q)

e. The bidder should specify all applicable system standards. (Q)

4. Maturity:

a. The proposed System shall be a proven solution that is already working and commissioned at an operational site(s). (Q)

b. The Bidder should describe the previous versions of the System application, which have been installed at other operational sites, describing the major functions and building blocks. (Q)

c. The bidder shall present operational interoperability and functionality approvals. (Q)

5. Vision (Roadmap):

a. The Bidder should describe the system application and software roadmap, all improvements and enhancements to the existing system that he proposes, which have occurred over the last five years, and future enhancement plans. The bidder shall also refer to the following: (Q)

i. The European infrastructure programs SESAR (Single European Sky ATM Research Program) and PENS (Pan European Network Service)

ii. ECG URD ( European Communications Gateway User Requirements Document)

iii. Other future evolution of the ICAO / Eurocontrol standard

b. The Bidder should explain how he plans to maintain the proposed system at an up-to-date level for the next 15 years from the application and infrastructure perspectives. (Q)




6. Standards:

a. The System shall comply with ICAO and EUROCAE standards for AFTN and AMHS. Please refer to Annex 1-B Standards (P)

b. The system shall comply with WMO Message format. (P)

c. The Bidder should briefly present his best practices, standards, working procedures as relating to the following list: (Q)

i. Projects Management Methodologies

ii. Testing Methodology

iii. System Service and Maintenance

iv. Project QA Methodology

v. Software Development Methodologies

vi. Other issues that are part of the Bidder's basic proposal

The standard documents have that have been used as reference material to produce this document and shall be taken into consideration by the Bidder where needed as detailed in Annex 1-B to this tender.




2.2 High Level System Architecture (Q)

2.2.1 General

1. The following furnished scheme is solely for the ease of data gathering purposes. It is intended only as a generic system scheme. The Bidder may adopt it / amend it / omit it or simply use an absolutely different scheme following his best practices / experience / proposed solution / etc.

2. The bidder shall take into consideration that the final architecture will be agreed on with the Telecommunication Center, the IAA Network and Information Security teams. Upon contract award, the Awarded Bidder will have to comply and cooperate with the IAA Telecommunication Center team and the technical teams when designing the architecture. The IAA technical teams have vast experience working together with system vendors to design suitable architectures for systems

3. The topics below are presented in a format that we believe will allow us conduct a comprehensive comparison between Bidders and Systems. We kindly ask that you respond to all sections below even if some of the functionalities or technology requirements that already appear in your response in other Chapters. This will allow us a better understanding of your proposed solution.




2.2.2 System Architecture (schematic diagram)

2.2.3 AMHS Core Sites

1. The operational system shall be comprised of two computer nodes (Primary and Secondary), at different geographical locations, and shall be used to run a fully redundant operational environment.

2. A non-redundant Test system, which will comprise a complete AMHS environment, shall be provided.

3. The System shall be DRP capable, i.e., the System shall support two remote sites (operational and contingency), while providing “Online-Backup” of operational data, and support automatic and manual switchover between the modules in less than 10 minutes. The distance between the sites can be up to 400 km away, where the network between them should be LAN or WAN.

4. The IAA will provide the IT centers infrastructure, communication equipment and the network connectivity between the AMHS system and the remote sites excluding the external AFTN / AMHS interfaces communication needs.




5. COTS hardware shall be proposed for all AMHS components

6. Information security shall be implemented in all the AMHS system elements (see Annex 1-C), i.e. applications, computing infrastructures and communications.

7. A Centralized Control, Management and Monitoring (CMM) application, which enable the control of system's elements functionality and is able to present the current status and events of the AMHS system and all its elements, shall be provided.

2.2.4 System Users and Interfaces

1. The AMHS system shall be connected to the following international network/systems:

a. CIDIN/AFTN interface by X.25/RS232

b. AMHS interface by TCP/IP (possibly PENS)

c. SITA interface by TCP/IP (possibly PENS)

d. WMO interface by TCP/IP

2. The AMHS system shall be connected to the following IAA’s systems:

a. AODB (Airport Operational Database)

b. EFS (Electronic Flight Strips)

c. ASMGCS (Advanced Surface Movement Guidance and Control System)

d. VOLMET/ATIS(Volume Meteorological/ Automatic Terminal Information

Service)

e. TelePC server

f. AMHS (test system comprise a complete AMHS environment)

g. AIS/AIM

h. EWAM

3. The AMHS system shall provide service to users via UAT (User Agent Terminals application). The system shall support various user types (Local and Remote users) and allow separation though various network connections.

4. The system shall support at least 50 fixed stations and 50 simultaneous sessions to the following users:

a. Communications Dept. - Ground Operations Division




b. Coordination Center - Ground Operations Division

c. Meteorological Bureau - Ground Operations Division

d. Airports Control Tower

e. Flight Information Division

f. Airlines companies

g. Civil Aviation Authority

h. Handling companies and Airlines

5. The Bidder shall describe in as much detail as possible, the security specifications for the connection of such remote WS's external to the IAA network such as: Authentication, data security, transport security (Data flow encryption) etc.,(Q)

2.2.5 System Architecture Principles

1. It should be easily possible to integrate the system with existing systems / interfaces. Integration capabilities already performed within the system offered are to be outlined in the offer. (Q)

2. The system should be modular in nature and, by using industry standard components, provide a flexible and expandable combination of components, enabling upward growth. (Q)

3. Appropriate software development principles shall provide the modular architecture required for the system. (Q)

4. The integration of new messaging components shall be easily possible and affordable (e.g. integration of new messaging components triggered by the implementation of AMHS). (Q)




2.3 System Description Directives

1. The System design shall rely on the Bidder's best practices, experience and solutions that best suit and comply with the IAA's planned system functionality and utilization. (Q)

2. The Bidder shall describe the proposed System. The description should include at least the following topics: (Q)

a. Overall description of the proposed Subsystem blocks and interfaces.

b. A functional description of each interface.

c. Information flow and operational logic of the Sub System.

d. Required Communications Infrastructures, layout and minimum requirements (this section is emphasized due to the high dependency of AMHS on these).

e. A schematic diagram of the system network and equipment layout.

f. General list of the deliverables.

g. Installation requirements (Power, footprint, AC etc.)




Chapter 3 - User’s Functional Requirements




3. User’s Functional Requirements

3.1 General

1. This chapter specifies the functional requirements from the following workstations: (P)

a. AMHS User Agent Terminal (UAT)

b. AMHS monitoring and control workstations. (see chapter 4)

3.1.1 AMHS UA Terminal

1. The AMHS UAT application shall support message management and creation, supporting IAA internal and external users. (P)(Q)

2. The UAT application shall support AFTN ATS messaging capabilities using the AFTN and AMHS (X.400) interfaces (P).

3. The UAT shall be based on client-server or Web architecture and shall connect via a central redundant server.(P)

4. The UAT “looks & feel” and functionality should preferably resemble a standard e-mail application. (Q)

5. The UAT application shall operate on a standard Desktop/Laptop PC hardware and MS windows Operating system (windows 7 and above).(P)

6. The UAT application should be able to operate on IAA’s network standard PC workstations, installed and located in a standard office environment. (P)

3.1.2 Standards

1. The AFTN/AHMS UAT shall be fully complied with the following standards: (P)

a. ICAO Doc 4444 ATM / 501 Appendix 2 - Flight Plan and Appendix 3 - Air Traffic Services Messages.

b. ICAO DOC 4444Amd.1, 15th Ed (FPL2012).

c. ICAO Annex 3 - Meteorological Service for International Air Navigation, 16th Edition, July 2007.

d. ICAO ROBEX - ROBEX Handbook, 12th Edition, 2004, Amd. May 2013.




3.2 Messaging

3.2.1 Supported Messages

1. The UAT shall support sending and receiving AFTN and AMHS messages: (P)

a. FPL and related ATS messages.

b. MET Messages.

2. The UAT terminal shall support sending and receiving standard X.400 free-text messages (including the binary file attachments according to Extended ATS Services).(P)

3. AFTN messages format and content shall be complied with ICAO Doc 4444, Amd.1, 15th Ed. (FPL 2012) and future following updates issued by ICAO in the following 5 years.

3.2.2 Message Creation

1. The UAT application shall provide an internal AFTN/AMHS/SITA/WMO message creation capability including the following features:

a. Selection of message header according to message format (addresses, priority, optional heading information) and message text; (P)(Q)

b. Interactive verification mechanisms; (P)(Q)

c. Interactive indication of message text length; (Q)

d. Full syntactical message verification (prior to message submission); (P)(Q)

2. The system shall prevent the user from submitting an outgoing erroneous message (format). (P)(Q)

3. Manually created messages should be acknowledged online, or discarded if any error was found in the message data. (P)(Q)

4. The system shall support storing of message as a draft for future handling.(P)(Q)

3.2.2.1 Message Forms

1. The UAT application shall provide forms to support message creation, data entry, viewing and editing. (P)(Q)




2. The system shall provide at least the following message forms: (P)(Q)

a. FPL, DLA, CNL, CHG, ARR, DEP, EST, AFP, CPL, CDN, ACP, ALR, RCF, SPL, RQS , RQP

b. METAR, TAF, SPECI, AIRMET, SIGMET, SYNOP, RQM, AD WRNG, WS WRNG

c. NOTAM, SNOWTAM, ASHTAM

d. SLOT messages (SAM, SCM, SRM) (Q)

e. Free text message (Like, IAA's unique ATS messages – Local Met Report)

3. The UAT application shall enable storing and retrieving drafts/incomplete forms for future completion/editing. (P)(Q)

4. The Bidder is requested to explain how the forms mechanism supports the user in quick an erroneous data entry.(Q)

5. The Bidder is requested to elaborate on forms and related functionality, preferably by using examples and adding screenshots demonstrating the system’s functionality. (Q)

3.2.2.2 User Forms

1. The UAT should support generating new user message forms/ templates. (Q)

2. User new forms shall be stored in the system and deployed to all UA terminals by system administrator. (Q)

3.2.2.3 Message Text View

1. The UA Terminal application shall support Message Text View. (P)(Q)

2. The user shall be able to switch between Form view and Text View (and vice versa). Message text data should be placed in the correct Form fields of supported message forms. (P)(Q)

3. Messages should be created and edited in Form view and/or Text view, allowing the user to switch viewing mode while editing /viewing a message. (Q)

3.2.2.4 Message Recipients

1. The UAT application shall provide Message Primary recipients list, Copy recipients list and Blind recipients list. (P)




2. The UAT application shall enable the user to a manually add/remove a recipient to the message recipients lists. (P)

3. The UAT application shall enable the user to add a recipient or a recipients group from the Address book. (P)

3.2.2.5 Message Validation

1. The UA Terminal application shall provide syntactic message fields validation.(P)(Q)

2. The UA Terminal application shall provide semantic validation of relevant message fields. (Q)

3. Message validation shall be supported during message creation/editing and prior to message submission. (Q)

4. The user shall be notified on erroneous information by using a clear and visible indication, marking the relevant field/information item and providing textual error description. (P)(Q)

5. The system shall highlight/emphasize erroneous fields, and allow the user to edit and correct errors.(P)(Q)

6. The UAT application shall support address validity of transmitted messages.(P)(Q)

7. The UAT application shall check message data for compliance with destination capabilities before transmission is performed.(Q)

8. The user shall be notified of any validation or compatibility errors, erroneous messages shall not be transmitted. (P)(Q)

9. The Bidder shall explain and elaborate on message validation capabilities, preferably by using examples and adding screenshots, demonstrating system’s validation capabilities and notification’s displayed to the user.(P)(Q)

3.2.3 Message Management

1. The UAT application shall provide the following user actions: (P)(Q)

a. Creating, Deleting, Viewing, Editing, Archiving, Restoring messages.

b. Sending & Receiving Messages

c. Forwarding / replying to selected message

2. All received and transmitted messages shall be archived and stored on the system’s server.(P)




3. The system shall enable message downloading to the UAT Workstations. (P)(Q)

3.2.3.1 Message Attributes

1. The UAT application shall provide the following message attributes and additional functionality:

a. Message priority – prioritizing message delivery (Q)

b. Message importance – marking message importance (P)

c. Message flagging – marking a message flag reminder, including due date indicator. (P)

2. The UAT application shall present message attribute visually to the user on the message form and in the mailbox containing the message. (P)(Q)

3. Message attributes shall be stored as a part of the message data. (P)(Q)

3.2.3.2 Message Supported Charsets & Encoding

1. The UAT Application shall allow receiving and transmitting messages

supporting at least the following Encoding/Decoding and Character sets: (P)

a. International ASCII (IA5)

b. General Text ISO 8856-1 (Latin-1)

2. The Bidder should elaborate the supported message charsets and file formats and explain about message editing based on Microsoft tools and supported message charsets and encoding. (Q)

3.2.4 Message Mailboxes

1. The UAT application shall support mailboxes operation for viewing and handling AMHS messages. (P)

2. Mailboxes could be defined as a single user mailbox or as a shared (group) mailbox. (P)

3. The mailboxes shall allow viewing and handling only messages delivered to the specific user or group definition. (P)(Q)

4. Shared/grouped mailboxes shall reflect any changes/updates between all group members. (P)(Q)

5. The system shall allow mailboxes access to all registered users (on local IAA network and non-local networks). (P)




3.2.4.1 Mailboxes Folders

1. The UAT application shall provide and support operation of the following mailboxes folders, based on a standard emailing applications: (P)

a. Inbox

b. Sent

c. Outbox

d. Drafts

e. Deleted items

2. The UAT application shall support Sub folders definition. (P)(Q)

3. Messages shall be placed or delivered to the folders and sub-folders according to user’s predefined rules. (P)(Q)

4. The user shall be able to purge and restore messages from the “Deleted items” folder. (P)

5. The User shall be able to move messages manually between folders/sub-folders. (P)

6. The user shall be able to store a message in the Drafts sub-folder for future editing (Draft messages could be incomplete) (P) (Q).

7. The user shall be able to sort messages in the messages-folders and view the message list in ascending /descending order according to selected parameter/column (such as – date/time, priority, subject, address, etc...) (P)(Q)

8. The Bidder shall detail the UAT application capabilities regarding mailboxes, message folders and related user functionality. (Q)

3.2.4.2 Searching Messages

1. The user shall be able to search messages in the mailbox folders and retrieve messages according to search criteria (such as – date/time, subject, address, message type, ATS message fields – ADES, ADES, EOBT, etc…) and according to text included in message content. (P)(Q)

2. The UAT application should be able to store and reuse search filters, search shortcuts should be accessible to the user (by using a menu, list, etc...)(Q)

3.2.4.3 Address book

1. The UAT application shall provide address book functionality Supporting the following capabilities: (P)(Q)




a. Creating, deleting, editing, coping and storing address and address’s distribution list.

b. Sorting and Searching addresses.

c. Creating new address entries from received/transmitted AMHS messages.

3.2.5 Message archive

1. The UAT application shall allow the user to archive sent and received messages. (P)

2. The archived messages shall be stored for a period of at least 180 days (P).

3. The user shall be able to search and recall stored messages from the system archive. (P)

4. The Bidder shall elaborate on the UAT and system archive functionality, short and long term message archiving and related functionality. (Q)

3.2.6 Admin

1. The UAT shall provide administrator functionality.(P)

2. The system Administrator functionality shall be performed on the monitoring workstations, as defined in chapter 4. (P)

3. The administrator functionality shall support at least the following services:

a. Users and users group management - creating, configuring, monitoring and deleting UAT users and users groups. (P)(Q)

b. Mailboxes management - creating, configuring, monitoring and deleting user’s mailboxes and shared mailboxes. (P)

c. Form Permission Management – defining per each UAT User/Group its specific message transmission form definitions (i.e.: Meteorological UAT station will be able to transmit only MET messages using MET forms). (P)(Q)

d. Configuring and Monitoring System’s status and application condition (P)

e. Static data management – importing/exporting, configuring and deleting static data base items. (Q)




3.3 Supporting Tools/Utilities

3.3.1 Printing

1. The UAT application shall support printing of messages (received, transmitted, drafts etc...) and additional user information handled by the application (such as statistics data, message attached files). (P)

3.3.2 Attachment Handling

1. The UAT application should provide file handling supported by additional applications which are installed on the workstation (such as PDF reader, Microsoft office etc.) (P)(Q)

2. The Bidder shall elaborate on the system’s functionality in handling attachment files, supported file formats and correlation with additional applications. (Q)

3.3.3 Statistics & Reports Subsystem

1. The UAT application should provide statistics and reports subsystem for the system management purposes. The statistics reports shall be based on the user activity and the message information stored in the system., (Q)

2. The user should be able to use generate reports according to his special needs and requirements. (Q)

3. The Bidder shall describe the proposed system capability in generating statistic information and reports, pre-made reports and additional information available to the user in order to analyze operational activity in the system. (Q)




3.4 HMI

3.4.1 HMI General Requirements

1. The UAT application HMI should support the following guidelines: (Q)

a. The system’s HMI and data presentation should require minimum user

actions and/or intervention (such as data entry, data recall, etc.).

b. The HMI design shall ensure that higher level user functionality should be intuitive and accessible.

c. The HMI should be flexible and adaptable in order to support different users’ requirements and limitations of the working environment.

d. The system shall display, with minimum delay, all required information (such as received information, system status information and alerts) in a clear and comprehensive manner that will support the procedures and response actions needed to be taken by the user.

2. The Bidder should describe how the system’s HMI supports the above-mentioned guidelines and reduces user’s workload and minimizes the required user actions. (Q)

3.4.2 HMI Performance Requirements

1. The User’s HMI shall fulfill the following requirements:

a. Employ a user friendly and familiar means of data entry.

b. The system should support the following data entry devices:

i. Keyboard (P)

ii. Mouse (P)

iii. Virtual keyboard (Q)

iv. Touch screen operation (Q)

c. Minimize the number of required input actions. (Q)

d. Enable the user to make the decisions on actions for which he is responsible. (Q)

e. Ensure a level of user workload which is consistent with efficient and effective activity. (Q)




f. Permit full manual operation in the event of a failure of an automatic function. (P)(Q)

g. Immediately forward alerts to users in the event of a failure or when system performance is degraded. (P)

3.4.3 HMI Features

3.4.3.1 Standard HMI Features & Components

1. The Bidder should give a detailed description of HMI features and components implementation in the System, such as: (Q)

a. Main windows

b. Sub windows & Preview windows

c. Menus

d. Function keys

e. Display controls (color scheme, fonts & sizes, etc...)

2. The Bidder should explain the logic used and the mechanisms available to the user, and when possible, graphic examples should be given. (Q)

3.4.3.2 Input Mechanisms

1. The input mechanism shall be user-friendly and simple.

2. The functions shall be chosen from menus and/or function keys.

3. Commonly used functions shall have a shortcut. (Q)

4. The user's input mechanism should be implemented both with the mouse cursor and keyboard operations (or equivalent). (Q)

5. The Bidder is requested to elaborate about the proposed system’s input mechanism and related logic. (Q)

3.4.3.3 General Settings

1. The System shall enable the end user the following setup from the main view:

a. Restart UAT application & Working Position :

i. The UAT application should be automatically restarted in case of failure (user approval is needed). (Q)




ii. The System should enable the user restarting the working position in case of malfunction. (Q)

iii. In case of a failure or restart upon failure the UAT shall notify automatically the AFTN Telecommunication operator’s monitoring application.

b. User (login):

i. Define the user, from a pre-defined list of users.

ii. On user login the System should load the default setup assigned for this user. (Q)

c. Restore system defaults:

i. Restore the working position default setup (as defined by the system authorized user). (Q)

d. The application should support the following capabilities:

i. Select item (Q)

ii. Select multiple items (Q)

iii. Perform actions on selected item/items (Q)

iv. Release item/items (Q)

3.4.3.4 User’s Preferences

1. The UAT application HMI should be user configurable, enabling the user to set font types/sizes, color schemes, display/workspace arrangement and adaptation. (Q)

2. The UAT application HMI should enable configuration of system’s functionality to suit the user needs (such as – function keys, shortcuts, menus). (Q)

3. The user should be able to save and load different preferences sets. (Q)

4. Preferences sets should be stored in the central server, enabling the user to login and load them from any working position. (Q)

5. The Bidder shall describe the configuration and adaptation capabilities of the proposed system HMI, examples and screenshots should be presented when available. (Q)

3.4.3.5 System Alerts & Warnings

1. The UAT application should Support and generate audio and visual alerts. (P)




2. The UAT application HMI shall provide the ability to alert the user to both operational and system events, and a user input interface.(P)(Q)

3. The UAT application should provide the user notifications, warnings and alerts regarding various events – such as: (P)(Q)

a. Operational events (new messages, unread messages, timeouts etc…)

b. Errors / Faults (receiving erroneous messages / attached data etc.)

c. System events (communication / connection malfunctions, storage problems etc.)

4. The Bidder shall specify and explain about alerts and notification capabilities and related logic of the proposed system HMI, examples and screenshots should be presented when available. (Q)

3.4.3.6 Connection/application Status

1. The UAT application HMI shall present Online application and system statuses and events, which are relevant to the end user (such as connection status, outgoing pending messages, incoming events, storage, etc.) (Q)

2. The Bidder shall detail about the proposed HMI displayed status information. (Q)

3.4.3.7 Online Help

1. The UAT application HMI shall provide the user – Online Help functionality. (P)(Q)

2. Online Help Functionality shall be accessible from the system menu, or directly from related function or data field when applicable.(P)(Q)

3. The help information should be preferably based on HTML techniques and should include screen-shots and links to related topics for ease of reference. The Online Help Functionality should be available for stations with no internet connection (Q)

4. The Bidder shall provide Sample screenshots for the online help. (Q)




Chapter 4 - System Requirements




4. Message Handling System Requirements

4.1 Introduction

The Message Handling System requirements are provided to the Bidder via the

following Structure:

General

Highlights

Applicable Documents

AMHS Functionality

Basic

Service Evolution (Extended)

ATS Message Server and Message Management

General

Message Lifecycle High level Scheme

Message Reception

Message from External Sources

Message Validation

Message Error Handling

Queues and Storage

Routing

Alternate Routing

System Logs and Reports

Message Retrieval

Correction

Re‐Transmition

Message Conversion

Addressing

AMHS System Performance

Communication

Capacity

Response Time

AMHS Professional Management

General

Central System

Admin Service Mailbox

AMC Support

System Monitoring

System Diagnosis

System Alarms

Error Handling

Users' Management




4.2 General

4.2.1 Highlights

1) The following section describes message management in the system. The management process handles the messages from reception onto dispatch and onto destination.

2) The Message Management process involves reception, storage and regular message handling stages.

3) The switching system shall handle messages arriving from various sources, storing and routing them to various destinations linked to the system via the AFTN / AMHS, SITA / PENS (hereinafter SITA) networks. (P)

4) The system shall serve as an AMHS message switching center. (P)

5) The system shall serve to exchange messages via AFTN and/or AMHS/X.400 and/or SITA and/or WMO and/or EAD Gateways (P)

4.2.2 Applicable Documents

1) Messages handling shall comply with ICAO Annex 10 Volume II and ICAO ATN SARPs 9880, Basic and Extended Services. (P)

2) As the AMHS standard may continue to evolve under the control of the ICAO, The Bidder is committed to maintaining compatibility with the standard at all times during the entire term of the Contract

3) The solution delivered shall comply with the version of the standard that is current at the time of delivery.

4.3 AMHS Functionality

4.3.1 Definitions

4.3.1.1 Basic Functionality

Basic ATS Message Services shall provide a nominal capability equivalent from a user

perspective to those provided by AFTN.

4.3.1.2 Extended Functionality (O, Q)

Extended ATS Message Service shall provide enhanced features such as supporting

transfer of more complex message structures (body parts), use of directory service, and

support for security.

The Bidder is requested to elaborate about all the enhanced capabilities reside in its

Proposal.




4.3.1.3 Service Evolution

In a case, the Bidder plans to implement the AMHS system in stages, the Bidder shall

describe the proposed System for each stage

The Description shall incorporate both a graphic scheme and Bill of Quantities.

4.3.1.4 Extended AMHS Configuration (O, Q)

Extended services will generally involve support from an X.500 directory service. The

directory may be used to enhance the AMHS system. The directory will enable

enhanced security services. Other extended services include support for body parts in

other than text format. The Bidder is requested to elaborate about its extended services

that are incorporated in its Proposal. The Figure below illustrates this configuration:

4.4 ATS Message Server and Message Management Requirements

4.4.1 General

1) In order to remove any uncertainty about the term Message (as in Error Message, AFTN Message, a Message from the computerized system, etc.), the term shall be defined as meaning an AFTN / AMHS Message.

2) AMHS System Components are: ATS Message Server, ATS Message User Agent (refer to Chapter 3 of this RFP), AFTN to AMHS Gateway and Address Scheme.

3) The aforementioned components' detailed requirements are introduced in this section.




4.4.2 Message Lifecycle High Level Scheme




4.4.3 Message Reception Requirements

4.4.3.1 General

1) The reception and transmission of a message shall be supported using the existing formats in accordance with the standards specified in Annex 1-B – Applicable Standards, at their most updated version.

2) The system shall extract the header and manage the message according to the transmission protocol attached to the incoming channel.

3) The identification number will be saved in the system as part of the message information, and will be used as a specific means for message identification.

4) The messages shall be stored in a central data storage location, which includes the message data and additional message metadata (such as: message source identification, type, content, destinations, message treatment status, message identification number, timestamp, etc.).

4.4.3.2 Eligible Sources

It is possible to receive a notification / message in the system from any of the following

sources:

1) Manual keying

2) External networks and data systems (such as AFTN, AMHS, SITA, WMO, EAD etc.)

4.4.3.3 Manual Keying requirements (P, Q)

1) The keyed message through the system screens has to be acknowledged on line, and discarded if any error was found in the message data. (For more details please refer to following “Message Error Handling”).

2) The notification keying screen shall include the Header and text in the proper format according to the type of notification.

3) It shall be possible to store temporarily incomplete messages for continued handling later on.

4) Templates - Message templates shall be stored in the system and shall enable a built in keying of the message.

5) It shall be possible to define templates of new transmissions dynamically.

6) Following the keying of a message into the system, the user shall release the message for transmission to its destination.

7) It shall be possible to store a message in a queue prior to its release and retrieve it at a later time.

8) The Bidder shall elaborate about other capabilities that are included within its Proposal.




4.4.4 Messages from External Sources (P, Q)

1) The proposed system shall automatically receive external messages from sources not included in the AFTN / AMHS system (from abroad and locally) and process them a synchronically, while providing full support to ICAO standards.

2) Any error found in the message receiving process shall halt processing and the message shall be stored in an “Error Queue" for later handling.

3) The system should enable corrective operation on an over-length message text (truncate, segment, or reject) for each of the received message formats. As an error is located, a notification shall be sent to the Operation Center.

4) The system shall support reception and transmission of the following messages:

a) Flight plans and related ATS messages (such as: CHG, CNL, DLA, …).

b) CTOT Messages (such as SAM, SCM, …)

c) NOTAM

d) Meteorology

e) Alarms

f) Administrative

g) Etc. (In accordance with ICAO ANNEX 10 most updated version).

4.4.4.1 Messages Numbering Requirements

1) The system shall assign a unique identification number to each incoming and outgoing message.

2) The identification number shall be saved in the system as part of the message information.

3) The identification number shall be used as a specific means for message identification

4.4.5 Message Validation Requirements

1) The System shall validate that all the required data for each message type has been received.

2) The System shall support a syntactic validation of each and every message.

3) The syntactic validation shall include, inter-alia, message structure, illegal values, invalid content, etc.

4) The System shall support amendments to the message structure and valid values for each field in each message type.

5) The System shall support modification by the system manager and/or anyone authorized by him.

6) Modification of either the structure or the valid values list shall not require the Awarded Bidder's intervention and shall not degrade / halt the routine work of the system.

7) The System shall perform all the possible tests and shall accumulate them and report to the user about all the message errors.




4.4.6 Message Error Handling Requirements

4.4.6.1 General

1) The System shall provide automated and manual data correction capabilities.

2) Errors which cannot be rectified automatically shall halt the message processing.

3) The system shall send a notification to the system operator in cases of error message.

4) The system shall enable the receipt of information related to Error Messages, in order to display the messages along with the error status.

4.4.6.2 Error handling for keying a message

1) A message entered with errors shall cause the display of an error message.

2) Any field causing an error shall be distinct.

3) The user shall not be able to continue and perform the activity as long as the error remains uncorrected.

4.4.6.3 Error handling for receipt of a message

1) The proposed system shall automatically receive messages through the various communication systems and process them a-synchronically.

2) Any error found during the message processing shall stop the processing, and the message shall be stored in the Error Queue, for continued processing at a later time by the authorized user.

3) When an error is located, notification shall be sent to the appropriate operation center, identified with the destination code in the notification.

4) The system shall include an inquiry regarding Error Messages that are displayed in an error status. Upon the selection of a message from the list, a message-keying screen shall be displayed, together with the relevant information for data correction.

4.4.7 Queues and Message Store Requirements

1) The messages in the system shall be stored in queues, according to system users and the various other systems connected to the system.

2) The system shall provide separate message queues (e.g. "pending", "paused", "format error", ” non-routable") for each interface.

3) Each message queue shall enable the application of the following functions on selected messages:

a) Diversion to a different communication destination

b) Un-blocking of paused messages.

c) Manual discarding (terminating message transaction by user involvement).

d) Non-delivery execution (AMHS only).

e) Reprocessing / rerouting.

4) The system queues shall support the following functionality:




a) Message Priority management

i) The system shall support Priority management of messages in every queue and between queues.

ii) It shall be possible to define priority levels for any messages in the various queues, according to a group or an individual.

b) Queue Thresholds Management (Q)

i) For each queue it shall be possible to define a threshold from which any deviation shall cause activation of predefined alarm in the system.

ii) Threshold check shall be activated either periodically (every X minutes, configurable parameter) or each time a new message is queued.

iii) Thresholds shall be configurable and defined for the following parameters:

(a) Message Waiting period - max waiting period of a message in the queue, an alarm shall be generated X minutes before the message reaches its maximum defined waiting period (a configurable parameter).

(b) Queue Utilization percentage - utilization of the queue above certain percentage.

(c) Queue Max Message - the number of messages in the queue exceeding a predefined threshold.

(d) General Threshold - Utilization of all queues from a general threshold

4.4.8 Message Routing and Dispatch Requirements

4.4.8.1 General

1) The system shall enable messages to be routed amongst all its users, including external and internal users. In addition, the system shall support routing of messages to all types of interfaces and networks it is linked to.

2) The system shall recognize and identify the routing addresses of all destinations and shall be able to convert addresses as necessary.

4.4.8.2 The Routing Process

The routing process shall include the following stages:

1) Message acceptability check (destination). (P)

2) Message conversion - Identification of the destinations and conversion of the message into the required formats in accordance with each destination definition. (See Message Conversion below). (P) (Q)

3) Message Dispatch - Dispatching of the message to the destination queue: (P) (Q)




a) Dispatch of a message to its destination - in accordance with the message definition, it shall be directed to the destination automatically ("push") or by request (“pull”). It shall be possible to change these definitions dynamically.

b) In the event that the transfer of messages to the destination is not possible, for any reason, a message shall automatically be sent to the message source (sender), including the reason for the failure to transfer.

c) It shall be possible, when dispatching the message, to request a confirmation for successful delivery of the message.

4.4.8.3 Routing Destinations

A message destination may be any entity linked to the system. This includes:

1) Any user in the AFTN / AMHS system

2) The users of interfacing systems, as described above

3) External users -

a) Dialing systems, such as modem, fax

b) Electronic mail in the Internet

4.4.8.4 Multicasting

It shall be possible to dispatch messages to a number of destinations according to:

1) Destinations list, defined in two levels: (P) (Q)

a) Global Circulation lists – predefined lists which are shared among all system users. Definition of these lists shall be performed by the system manager.

b) Private Circulation lists - predefined lists which are defined by a particular user or group of users, in accordance with their needs.

2) The dispatch of messages to all system destinations (locally and abroad). (P) (Q)

4.4.9 Alternate Routing

1) The system shall support alternate routing of a message when the destination is not active or vacant (according to the Threshold definition). (P) (Q)

2) The system shall support alternate routing of messages through an alternate communication infrastructure (for example - sending a message by Fax when the communication line is faulty). (P) (Q)

3) The alternate routing shall be performed automatically with the existing definitions, (such as the definition of alternate routing through the fax when the communication line is faulty, or manually when it is impossible to perform an automatic definition or when it is impossible to use the alternate route). (P) (Q)




4) In a case of AFTN network problem, it shall be possible, by operator’s specific request, to reroute all pending AFTN messages (of any specific or all destinations) to SITA specific address (configurable). In such case the original AFTN address shall be maintained and wrapped with SITA header. That shall be supported for outgoing/incoming messages from SITA. (P) (Q).

5) The Bidder shall provide detailed description of the configuration and operation of main and alternate X.25 PVCs and SVCs for AFTN transport.

4.4.10 System Logs and Reports

1) The system shall meet the requirements specified in ICAO Annex 10 Volume II and ATN SARPs, for the support of message logging, archiving and retrieval for the purpose of Legal Recording and Investigation. (P) (Q)

2) The system shall log and archive the complete message text of each message type, format and conversion as received and sent by the system. (P) (Q)

3) The message and message address logging and retrievable data, shall provide message status and handling information reflecting on the message process and state within the system. (Errors, delays, diversions, special handling, conversion to different formats, exceptions, etc.). (P) (Q)

4) It shall be possible to limit the size of all the saved messages with a configuration parameter in a simple and methodical manner for each message type. (P) (Q)

5) The message log shall provide journal containing information on message error correction and any other operator’s activity that affected the message processing, routing etc. (P) (Q)

6) Message trace report (P) (Q)

a) It shall be possible to trace all types of message flows (journal) of all the messages processed (received, transmitted, delayed, diverted, deleted, etc.) by the system.

b) Starting with a given message received by the system, it shall be possible to perform an immediate forward trace to all resulting messages transmitted by the system.

7) The message log shall contain messages for a configurable period of not less than one (1) month. (P)

8) The maximum period shall not be limited by the software and only be constrained by configuration or available system resources. (P) (Q)

9) The system shall provide a user friendly HMI for investigation and review of the noted system logs. (P) (Q)

10) The Bidder is requested to provide sample screen shots of typical system logs & Message reports functions and their operation. (P) (Q)

4.4.11 System Message Retrieval

1) It shall be possible to search and retrieve messages from the system (queues, logs, archives), by use of search criteria and logical operators in an efficient and practical manner. (Time spans, address filters, search words, logical combinations and operators like "and", "or", "not", etc.). (P) (Q)




2) The Message Retrieval shall be performed by using the message management tool/interface.

3) It shall be possible to send the retrieval messages via Email as a one email message (Q).

4) Message retrieval query shall support at least the following message selection criteria: (P) (Q)

a) Retrieval of a specific message by identification (source/destination addressees, incoming/outgoing circuits/channel, number, etc.)

b) Retrieval of messages according to their time of creation or arrival in the system

c) Retrieval of a message according to its contents - search of a string within the message

d) Retrieval of a message according to its type and priority

e) Retrieval of a message according to status (sent, error, delay, printed, etc.).

f) Logical combination of the above-mentioned criteria with Boolean operators.

4.4.12 Correction/Cancellation of Messages

1) The correction or cancellation of a dependent message shall be carried out by an authorized user. (P) (Q)

2) Message correction should be performed by using an identical HMI used for a new message entry. (Q)

3) Access to the message which has to be modified or canceled shall be gained by means of the specific message number. (P)

4) The administrator shall be able to define message fields that are not allowed to be modified. (P)

5) The system shall produce logs reflecting any modification and/or cancellations. (P)

6) Any modification and/or cancellation shall reproduce the original message including updated details together with the code responsible for the change. (P)

7) The original message shall be stored, as it includes the original information and is updated only in the current status itself. This will make sure that any action performed shall be recorded and documented, enabling control and history whenever required. (P) (Q)

8) The database to be used primarily for message storage and logging, shall also provide storage for and access to:

a) System logging data:

b) Operator commands

c) Alarms

d) System events

9) Statistical data.




4.4.13 Message Re-Transmission and Redirection (Redirect)

1) The system shall support retrieval of a message from the system and retransmission of the message. (P) (Q)

2) It shall be possible to repeat messages to their original destinations (i.e. to the same communication partners as the messages were transmitted to before). (P) (Q)

3) It shall be possible, in accordance with the user authorization, to direct an existing message to different destinations (i.e. Input the messages into the routing process again and reroute the messages to other destinations). (P) (Q)

4) In order to protect communication partners from overload, the system shall enable the operator to control the message repetition load (e.g. by enabling the operator to issue the repetition of bulks of messages). (P) (Q)

5) The System shall be capable of re-transmitting multiple messages at once (at least 200 messages at one time) from a specified queue or destination to the same/different destination. (P)(Q)

6) It shall be possible to filter out and re-direct data based on an AFTN origin address and/or an AFTN destination address to different queues. (P)(Q)

4.4.14 AMHS / AFTN Gateway and Message Conversion Requirements

1) The system shall incorporate Two Way Gateway Functionality, enabling the execution of message format conversion rules/processes/methods, enabling a seamless message transmission between different types of systems at each end. (P) (Q)

2) The following message conversion shall be supported:

a) AFTNAMHS/X.400 Gateway - Conversion between AFTN messages and AMHS messages (as defined in the ICAO DOC 9880) (P)

i) The gateway shall convert AFTN priority and AMHS/X.400 priority conventions.

ii) The gateway shall support AF, MF, XF and CAAS addressing formats with full interoperability between these addressing standards. (As per ICAO Doc 9880 Part II [5] section 2.5.1.4.)

iii) The AFTN/AMHS gateway shall be able to transform the AMHS/X.400 multi address conventions, with messages with up to 1000 recipient addresses into AFTN messages to these addresses. (Q)

iv) The gateway shall implement a self-checking scheme for address conversion to detect and notify discrepancies.

b) AFTNSITA Gateway - Conversion between AFTN messages and SITA messages (P)

c) AMHSSITA Gateway - Conversion between AMHS Messages and SITA Type-X messages (XML) (P)

d) AFTNE-mail Gateway - Connection between E-mail Server via SMTP/POP3 Conversion of AFTN messages and E-mail (Q)




e) AMHSE-mail Gateway - Conversion between AMHS Messages and e-mail Full support of extended services (attachments) (Q)

f) AFTN/AMHSFAX Gateway - Conversion between AFTN/AMHS and FAX (G3) (Q)

g) OLDIFMTP Gateway - Conversion between FDE ICD and FMTP (Q)

h) AFTN/AMHSWMO Gateway- Conversion between AFTN/AMHS Messages and WMO (Q)

3) It shall be possible to display message history for all messages handled by the gateway (incoming message, journal, and outgoing message). (P) (Q)

4) In addition to the ICAO ATN SARPs 9880 specifications the following gateway events should be logged: (Q)

a) MTA-bind - successful completion.

b) MTA-bind - error.

c) MTA-unbind.

4.4.15 AMHS Addressing

The AMHS address includes Common AMHS Addressing Scheme (CAAS) Address

and translated-form (XF) Address.

4.4.15.1 AMC Support

1) It shall be possible to import the following Lookup Tables to the system: (P) (Q)

a) AMC Domain lookup-table,

b) CAAS table and user lookup table via external medium (CD/DVD, USB stick, etc.)

2) The activation of newly imported lookup tables shall be performed by an authorized operator. (P) (Q)

3) The import of new lookup tables shall not require a system restart. (P) (Q)

4) The activation of newly imported lookup tables shall not interrupt normal system operations, enabling a smooth transfer to renewed imported tables. (P) (Q)

5) The System shall enable the generation of Lookup table content, status and elements. (P) (Q)

4.4.15.2 ATN Directory Services X.500 (Option)

1) As an option the system shall be able to provide redundant ATN directory service in compliance with the ICAO DOC 9880. (O) (Q)

2) The access to the directory service shall be possible through DAP and LDAP protocols. (O) (Q)

3) If required this option implementation shall be compliant with the X.500-93 standard version. (O) (Q)




4.5 AMHS System Performance

4.5.1 Communication / Switch Performance

1) The following message related requirements must meet the following message size range: (P)

a) Average message text size: 1,500 bytes;

b) Minimum message text size: 100 bytes;

c) Maximum message text size: 15,000 bytes

2) The System shall be capable of handling 50,000 incoming messages per day and 100,000 outgoing messages a day, with an average message text length of 1,500 characters.

3) The System shall be capable of handling a peak hourly traffic rate of 5,000 incoming messages and 10,000 outgoing messages, with an average message text length of 1,500 characters.

4) The system shall support a sustained message input rate of 100 messages per second, a sustained output rate of up to 300 messages per second, with no accumulation of messages within the system. (P) (Q)

5) For simultaneous input of AFTN and AMHS/X.400 messages, the system shall support a sustained message input rate of at least 60 AFTN messages and at least 40 AMHS/X.400 messages per second, with no accumulation of messages within the system. (P) (Q)

6) The above message rates shall be sustainable regardless of the type and combinations of message addresses. (P) (Q)

7) Each individual interface shall support a sustained message input/output rate of 20 messages per second. (P) (Q)

8) The following simultaneous message transformations shall be supported: (P) (Q)

a) 30 AFTN/SITA to AMHS messages per second

b) 30 AMHS/SITA to AFTN messages per second.

9) The maximum duration from message input to message output shall not exceed 1 (one) second at the maximum sustained message transfer rate. (P) (Q)

10) The system queues’ capacity shall support at least 100,000 messages of any type. (P) (Q)

11) The system performance shall not be adversely affected by the rate and size of all messages under sustained and peak operation. (P)

4.5.2 Capacity

1) The System shall enable expansion of 30% in users’ workstations and interfaces without any need for any financial investment over and above the purchase and integration of the elements, and without the need to replace existing system elements (hardware casings or software applications). (P) (Q)




2) The System shall support the expansion of additional end-devices (WS, etc.) at any site, BGN site and/or at remote sites by means of standard communications protocols via the IAA network. (P) (Q)

a) The system shall support at least 55 concurrent UAT /work stations

b) The system shall be able to accommodate up to 50 serial interfaces.

c) Each serial interface may be configured with asynchronous or synchronous operation.

d) The System shall support a minimum of` 300 channels / ports (AFTN and/or AMHS).

e) The System shall be able to support the following minimum numbers of AMHS connections:

i) 5 MTAs

ii) 120 User Agents

iii) 20 other connections with non-UA systems (e.g. ATM, AIS/AIM or MET systems).

3) The Bidder shall indicate the maximum number of concurrent AFTN and AMHS connections that are supported by the proposed System.

f) All system databases for message storage, logs, event logs etc. shall be independently configurable for the control of the storage size and archive history duration. (For instance storage for a configurable number of months, etc.) (P) (Q)

g) The system databases and message storage, logs, event logs etc. shall not be limited in size or duration, and will be determined only by the available storage capacity, and other required resources of the system. (P) (Q)

h) The System shall store an absolute minimum of 180 days Message traffic and logs on-line in the Message Store database. Given the large storage capacity of hard disks available on the market and their relatively low cost, it is expected that the System will be capable of storing at least a year’s worth of Message traffic and logs on-line (either in the database or in some on-line archived mode).

i) The system shall be able to support a minimum of 5000 Address Indicators.

j) The System shall have the capacity to queue up to 100,000 messages.

4.5.3 Response Time

1) Response time criteria shall be met under maximum capacity conditions. (P) (Q)

2) For remote devices during normal operation, an additional 0.5 second can be added to the total delay of local transaction. (Q)

3) The message transfer time within the system (defined as the period from the end of reception of the incoming message until the end of transmission of the outgoing message) shall not exceed 1 second when operating under a sustained traffic rate of 20 incoming messages per second and 40 outgoing message per second, with an average message length of 1,500 characters.




4) Under normal (95% of all transactions) load conditions the System’s response time for Operator commands shall be less than 0.5 seconds. By all means transactions shall not exceed 1 second.

5) The above system response time requirements may exclude response times for processing complex database retrievals when there are large amounts of data stored on the system e.g. retrieval of messages based on several filters including a message text content filter.

6) In the event of an automatic (failover) switch between the active and standby servers of the redundant Main System, the AMHS system shall be restored to a full

4.6 AMHS System Technical Management

4.6.1 General

1) The proposed AMHS System shall be provisioned with Monitor & Management Software Package and with administration and management workstations to monitor, control, command and manage the SLA and the various components and capabilities of the AMHS System as detailed in the next clause. (P) (Q)

2) All management functions of the system for all types of messages and activities shall be managed by a single integrated management system (Q)

3) The AMHS management tools shall provide, inter alia, the following capabilities (P):

a) Monitoring and management of AMHS computers, Servers workstations, network, and all other peripherals & End Stations. (Q)

b) Monitoring the SLA of the System and its components and generating SLA reports. (Q)

c) Message handling functions and flow control mechanisms. (Q)

d) Recording of all AMHS System components' (HW&SW) events and statuses and alerts (in real time) on predefined events that need attention and treatment. (Q)

e) Operational management information regarding the status and usage of System components, and services. (Q)

f) System configuration capabilities. (Q)

g) Generating reports and automated reports and statistics on System devices and application statuses, message handling processes and devices' utilization. (Q)

h) Recording all System activities and statuses. (Q)

i) System functions (switchover, re-initialization, reboot, etc.). (Q)

j) Monitoring, logging, retrieval, and inspection of faults and erroneous situations encountered. (Q)

k) Security and access controls. (Q)




l) Other tools that the Bidder might see fit. (Q)

4) The above mentioned tools and other capabilities which the Bidder may consider to add and integrate in the System, shall serve several managers with the following roles:

a) Local and remote Bidder's Technical manager and technical team who shall monitor and maintain the System to be Up & Running as required by the SLA agreement, and provide SLA reports. (P) (Q)

b) Local IAA manager to view System situational awareness picture, monitor System overall status (faults and operational) as well as System usage and utilization and passenger tracking status. (P) (Q)

c) Local/remote System administrator, provided by the Bidder, for setting up the System and for other System activities such as backup, user configuration, updating and recovery.

5) The Bidder shall provide detailed description of the management application (in conjunction with operator commands) and of the way it implements a comprehensive management framework for the different message handling components (e.g. communication partners, message queues, message conversions, message errors).(Q)

4.6.2 Central System Management

4.6.2.1 Operator/Admin Working Positions

1) The system shall support several Operator / Admin working stations. (P) (Q)

2) Each operator's working station shall be able to support all system management functions, (users’ capabilities shall be restricted according to user-authorization and security management). (P) (Q)

3) It shall be possible to run several system operator applications on the same hardware platform in parallel (e.g. one application to operate the main system and one application to operate the contingency system run in parallel on the same physical operator position).(Q)

4) The Bidder shall describe how to configure and use such parallel activation (Q).

5) Working position failure

a) A failure of operator working position equipment shall not affect the functionality of the complete system. (P)

b) Data or messages in process at the failed operator position shall not be lost, duplicated, corrupted, or falsified in any way. (P) (Q)

c) Data or messages in process shall be offered for processing at the remaining operator positions. (P) (Q)

6) The response time of the system for user input via the HMI shall be less than 1secs even in case of full load as specified in this document. (P)

4.6.3 Operator / Admin service mailbox

1) The system shall provide an operator mailbox to enable sending messages directly to the system operator. (P) (Q)




2) It shall be possible to define the mailbox as a destination in the routing tables. (P) (Q)

3) It shall be possible to display messages using any selection criteria and/or combinations of criteria. (P) (Q)

4) Mailboxes shall indicate the number of pending messages. (P) (Q)

5) Mailboxes shall include alert capabilities:

a) It shall be possible to configure mailboxes with visible and audible alarm attributes according to predefined rules. (P) (Q)

b) It shall be possible to assign different visual indications (e.g. colors, fonts etc.) to different severity of alarms. (Q)

6) It shall be possible to directly access and review mailbox (by using message viewer). (P) (Q)

7) It shall be possible to load a message from a mailbox into the internal message editor for further processing. (P) (Q)

8) It shall be possible to generate a reply message out of a mailbox message. (P) (Q)

4.6.3.1 System Configuration

1) The system shall support the configuration of the system components in an easy and user-friendly way. (P) (Q)

2) The input and modification of configuration parameters, routing table etc. shall be via menus, intuitive, and syntactically and semantically checked. (P) (Q)

3) The system shall offer a restore function for configuration parameter, routing table etc. The parameter change history shall be retrievable for a predefined period. (P) (Q)

4) All changes to be revoked parameter/configuration change shall be selectable from the retrieved parameter change history. (P) (Q)

5) Cross-checks among associated tables shall prevent from inserting of wrong or inconsistent information, e.g. among AFTN routing tables, AFTN/AMHS/SITA / PENS /WMO gateway tables and AMHS routing tables. (P) (Q)

6) The system shall provide a routing simulation tool to allow verification of routing tables. (Q)

7) The Bidder shall identify system configuration parameters that can be modified and activated online and system configuration parameters which require a restart of the system or specific component of the system. (P) (Q)

8) The majority (as a minimum more than 90% of all system configuration parameters) shall be subject to online modification and activation. (Q)

9) In particular, the configuration of addressing and routing information shall be possible through online modification. (Q)

10) The system shall not limit the size of the configuration parameters/tables (e.g. size of routing tables). (P) (Q)

11) The system shall provide a mechanism to maintain several sets of configuration data, and to activate an appropriate configuration on operator request. (Q)




12) The system shall provide a release-independent structure of a configuration data set so that existing data sets can be reused with new application SW releases. (Q)

13) Apart from hierarchically organized configuration menus, a configuration browsing tool shall be provided by the system, which enables navigation between and direct access to inter-related configuration objects (e.g. AFTN routing indicator AFTN circuit physical interface). (Q)

14) For each configuration object, the browsing tool shall enable direct access to the parameters and diagnostic values of the object in question. (Q)

15) All modifications of the configuration shall be logged in an appropriate database. (P) (Q)

16) The system shall enable the operator to associate free text / comment to the changed operation. (Q)

4.6.4 AMC Support

1) It shall be possible to import the following Lookup Tables to the system: (P) (Q)

a) AMC Domain lookup-table,

b) CAAS table and user lookup table via external medium (CD/DVD, USB stick, etc.)

2) The activation of newly imported lookup tables shall be performed by an authorized operator. (P) (Q)

3) The import of new lookup tables shall not require a system restart. (P) (Q)

4) The activation of newly imported lookup tables shall not interrupt normal system operations, enabling a smooth transfer to renewed imported tables. (P) (Q)

5) The System shall enable the generation of Lookup table content, status and elements. (P) (Q)

4.6.5 System Monitoring

1) The Bidder shall provide 24x7x365 monitoring services to include tracking, recording and notification of the AMHS System usage and failure events and alerts. (P) (Q)

2) The AMHS Management System (AMS) shall be one of the tools to assist the Bidder's technical staff to comply with the SLA requirements (see chapter 8). (Q)

3) The recommended management protocol for all System components (Hardware, Software, and Network) shall be SNMP management protocol. (Q)

4) The AMHS Management System (AMS) shall provide system monitoring and management of all components installed on site and at remote sites. (Q)

5) The AMS shall include diagnostic capabilities that automatically detect and correct when possible, failures in the system and automatically alert the system managers and technicians when a failure occurs. It will enable the technician to test workstations (WS) and Peripherals, and perform remote tasks such as to operate, reconfigure or restart, or update any of the devices. (Q)

6) The AMS shall be capable to configure the various End Stations and peripherals for the desired operation mode and be able to enable/disable some of their functionalities. (Q)




7) The system shall record the following configuration changes (description / timestamp) and status of the following components at the LRU / module level: (P) (Q)

a) Servers (system configuration, user lists and authorizations, data base imports, lookup tables, etc.).

b) Router, switch, firewall, communications network.

c) Physical interfaces and circuits, (connection status, protocols, down times etc.).

d) Application software (updates, module changes, version control, fall backs etc.).

8) All System events and statuses shall be displayed on AMS workstations and shall be recorded in the system database with the appropriate data (e.g. time and date of event, type, device id etc.). The recorded events shall be accessed online at least 2 years and then shall be archived off-line for 5 years. An automatic record deletion on a first-in-first-out (FIFO) basis shall be implemented when the on-line Data base reaches its limits.

9) Each recorded “event” shall provide the following information: (P) (Q)

a) Date and time of event generation.

b) Event type (e.g. “configuration change”, "Routing", "X.25", "Software Exception", "Command" etc.)

c) Event initiator (where applicable).

d) Event outcome (error messages, success, etc.).

10) Additional event information may be provided : (Q)

a) Object concerned (e.g. an interface),

b) Software module that issued the event,

c) Operator’s name ( command entry)

d) Event text (comprehensive and clear description)

11) It shall be possible to retrieve events from the event log using at least the following message selection criteria and any combinations of them (i.e. by means of Boolean expressions):

a) Date and time range, (P) (Q)

b) Event type(s),

c) Operator’s name/identification. (P) (Q)

d) Event text parts (including wildcard search). (P) (Q)

e) Object (O)

f) Software module (O)

12) It shall be possible to generate an AFTN message with each event in order to attract attention of a remote operator. (P) (Q)

13) The system shall additionally display information about the system state and the connectivity to its communication partners by means of graphical depictions. (P) (Q)




14) With respect to the connectivity to the communication partners, the graphical depictions shall be based on geographical maps of the geographical regions concerned. (P) (Q)

15) It shall be possible to change the resolution of the maps (i.e. zooming in and out). (Q)

16) It shall be possible to configure the mapping of colors to the different connectivity states (e.g. "green" indicating communication partners that are "up"). (Q)

17) For communication partners connected via more than one communication line it shall be possible to configure the display of communication partner and communication line separately (e.g. a center connected via two X.25 PVCs). (P) (Q)

18) The Bidder shall contain examples of how the system will provide such graphical depictions. (Q)

19) The system shall provide a HMI for exporting the event log in a human-readable format. (P) (Q)

4.6.6 System Diagnosis and Statistics

1) The system shall continuously collect and store diagnostic (faults, errors, outages, etc.) and statistical data (performance, resource allocation, types of messages, etc.) of the system components and operation. (P) (Q)

2) The Bidder shall specify in detail the nature and amount of diagnostic and statistical information provided by the system. (Q)

3) All stored diagnostic and statistical data shall be accessible online during normal system operation with real-time display of various performance parameters, and a configurable display update rate (default – update once per second). (P) (Q)

4) It shall be able to display statistical data for a selected duration of history time, like last minute, 15 minutes, hour, day, week, month, quarter, six months, and one year. (P) (Q)

5) Diagnostic and statistical data shall be provided at least for the following object levels:

a) messaging (overall, circuit-specific, AFTN-specific, SITA, AMHS/X.400-specific) (P)

b) communication protocols (X.25/HDLC, Asynchronous Byte, TCP/IP, X.400, ATN/TP4) (P)

i) The total number of messages/errors received,

ii) The total number of messages sent,

iii) The number of messages/errors received per channel,

iv) The number of messages type received per channel,

v) The number of messages sent per channel and per priority,

vi) The number of messages type sent per channel

c) physical interfaces (availability, number of link failures)




6) Diagnosis and statistics shall be provided also for the system performance, usage of system resources, usage of component resources, and availability of system components. (P) (Q)

7) The system shall provide statistics for the system-internal message transfer times, calculated separately for queued and normally transferred messages. (Q)

8) The system shall provide an interface for exporting diagnostic and statistical data in human-readable format. (Q)

9) The system shall provide an interface exporting statistical data in CSV format or as a graph. (P) (Q)

10) The statistical data to be exported shall be selectable as follows; (P) (Q)

a) Statistical Source and type of data

b) The duration of selected statistical data

c) The number of statistical data occurrences

11) The system shall enable the file naming and path for exported data. (Q)

12) If statistical data is supported in graph display, it shall be possible to display and print the graph. (Q)

13) If more than one statistical source is selected, the graphs for the statistical counter shall be displayed in different colors. (Q)

4.6.7 System Alarms

1) System alarms shall activate a visual, audio or both (visual & audio) type alert. (P) (Q)

2) It shall be possible to configure and activate a specific alarm type for each type of event. (P) (Q)

3) Individual alarm configuration as well as activation and deactivation of alarms shall be provided in a simple and clear method. (P) (Q)

4) The displayed alarms shall be configurable per operator or workstation type as part of the system administration functionality. (P) (Q)

5) It shall be possible to manually acknowledge alarm alerts and to disable the corresponding alarm indication / audio. (P) (Q)

6) An audio alarm shall sound locally at the corresponding operator position. (P) (Q)

7) A visual alarm shall be presented on the operator position in a way that attracts attention. (P) (Q)

8) The AMS shall provide alarm notifications, on predefined events and/or severity, in the following methods: (Q)

a) Notification to on-site AMS user workstation as noted above.

b) Notification to Bidder's Remote management and Helpdesk site.

c) Notification to support staff via email.

d) Notification to support staff via text message and/or pager




9) The aforementioned notifications shall enlarge the capability to display the malfunction component on the System's schematic description.

4.6.8 System Fault and Error Handling

1) The system shall continuously monitor and display in a clear manner the overall health of the system and its components. (P) (Q)

2) The system shall log all faults and errors detected in an automatic (autonomous) fashion. (P) (Q)

3) All detected faults and errors shall be logged in the system for future retrieval, analysis and corrective action as required. (P) (Q)

4) All system faults and errors shall be stored in the system for a minimum configurable period of one month. (P) (Q)

5) In the event of a component failure (hardware or software) the system shall be able to automatically initiate and perform a switch over to a redundant component or reassign another system resource as necessary. (P) (Q)

6) The switchover to a redundant component or reassigning of another system resource shall not take more than 10 seconds. (P) (Q)

7) In the event of a component switchover or reassignment of another system resource the system shall not lose any data, messages etc. and shall maintain a normal system operation with seamless transition from failed to backup component / resource. (P) (Q)

8) It shall be possible for any failed components in the system to be automatically restarted in attempt to retain their operational status and active contribution to system future health. (P) (Q)

9) The restart of the System should include restoration of pertinent information and actual system configurations of last known status. (P) (Q)

10) Re-initialization: (P) (Q)

a) It shall be configurable whether a re-initialization is automatically performed or not and with or without traffic recovery (pending message transactions).

b) A complete re-initialization (e.g. after power failure) shall not take longer than ten minutes

4.6.9 USERS' Management

1) Users’ management process shall be done by system administrator. (P) (Q)

2) The administrator functionality shall support at least the following services: (P) (Q)

a) Users and users group management - creating, configuring, monitoring and deleting UAT users and users groups.

b) Mailboxes management - creating, configuring, monitoring and deleting user’s mailboxes and shared mailboxes.

c) Configuring and Monitoring System’s status and application condition.




d) Static data management – importing/exporting, configuring and deleting static data base items.

3) User profile functionality: (Q)

a) Users’ profile shall be kept in central redundant data storage location

b) Each individual user shall have its own profile.

c) A User shall not be able to view or update information entities, which are not related to its profile credentials.

d) The profile shall contain the user's access credentials to any system element (servers, subsystems, applications, HMI etc.)

e) The profile shall also contain also the user's permissions to view/modify/create any of system’s data/ parameters/ messages/ menus/ reports etc.

f) The systems shall enable to define numerous shared (Group) profiles; each could be assigned to any individual user.

g) Any change on shared profile permissions will be reflected immediately in users’ permissions, which is based on it.

h) The system will enable modifying the user's privileges , even if it's profile was based on a shared profile

i) The system shale enable to clone any profile (shared or user’s)

4) User security: (Q)

a) The system shall enable blocking any user without the need to change its profile

b) Additional / complementary security requirements are defined at section 6.5 of chapter 6

5) The bidder shall detail the system’s capabilities in reference to all above requirements.




Chapter 5 - Interfaces Requirements




5. Interfaces Requirements

5.1 Interfaces with External Systems

5.1.1 General

1. This chapter defines interfacing requirements to IAA's AMHS system. The external systems interfaces are essential to the proper and complete AMHS operation and shall be described here in detail.

2. The AMHS system shall be capable of interfacing with the current systems/users/networks:

a. UA Terminals

b. IAA systems: (P) (Q)

a. , AIS/AIM

b. AODB- Airport Operational Database (CHOCS)

c. ASMGCS (Advanced Surface Movement Guidance and Control System)

d. EFS/IODS (Electronic Flight Strip/Integrated Operational Data System)

e. EWAM (Eilat Wide Area Multilateration)

f. VOLMET/ATIS

g. TelePC systems

c. X.400 network (PENS). (P)(Q)

d. AFTN network. (P)(Q)

e. CIDIN network (P)(Q)

f. SITA system (PENS) (Q)

g. WMO (Q)

h. IMS (Israel Meteorological Service) (Q)

3. Interface requirements are presented in the following structure:

a. Interfaces Overview

1) The section contains external systems and main dataflow overview drawing and a top level external systems information table.

2) The Bidder should regard the overview section as a reference only.

b. Interfaces Characteristics

1) This section contains general information about the required interfaces types, redundancy and data handling.




2) The Bidder shall use these requirements as guidelines for the specific response that is required for each external system interface.

c. Interfaces Requirements Definition

1) The section describes the requirements for each interface.

2) The Bidder should provide a detailed response regarding each interface.

4. The Bidder shall describe the proposed architecture, taking into consideration the detailed requirements presented in the following paragraphs as well as “Design Considerations" in chapter 2. (Q)

5. At the conclusion of the project, the Awarded Bidder is required to provide an Interface Control Document (ICD) for the system for the purpose of implementation of future interfaces (the ICD might be used internally and/or by a third party vendor). (P)

5.1.2 Interfaces Overview

5.1.2.1 Interfaces and Data Info

1. The following figure presents a top-level view of the external systems relating to the AMHS and the data flow involved.

2. The arrows and their captions describe the following:

a. Data Flow direction;

b. Primary data type (not necessarily all types);

c. Interface required redundancy.

3. The specific data required for each interface is detailed in the relevant paragraphs. Additional information shall be provided, as needed, by the Detailed Design phase.

4. Support for current AFTN clients (P)(Q)

a. IAA current system interfaces as described in this document, connected to the current AFTN system and supporting the AFTN message format.

b. The Awarded Bidder of the AMHS system shall comply with backward compatibility to the existing format without requiring a change to the existing system interfaces.

5. Message Format and data (P)(Q)

a. AFTN messages per ICAO Annex 10 volume 2, ICAO Procedures for Air Navigation Services and ICAO Document 4444 ATM/501 Procedures for Air Navigation Services.

b. METAR messages per ICAO Annex 3, Meteorological Services for International Air Navigation and ICAO Document 8896 Manual of Aeronautical Meteorological Practice.




5.1.2.2 AMHS’s external Interfaces & Data info - Logical diagram

TCP/IP

AFTN

SITA

X.400

AODB / CHOCS

Management

UAT

CIDIN

RS232

X.25

TCP/IP (PENS)

TCP/IP (PENS)

TCP/IP

WMO

TCP/IP

TCP/IP

AMHS

AMHS

EFS/IODS TCP/IP

AIS - CurrentTCP/IP

AIM - Future

TCP/IP

TCP/IP

EWAM TCP/IP

VOLMET / ATIS

TCP/IP

ASMGC TCP/IP

TelePC TCP/IP

IMS




5.1.2.3 System/Client Information

1. The following table presents a summary for the required interfaces with external systems. The detailed requirements are presented at interfaces paragraphs.

2. Description of table's headers:

a. System/Client – system interfacing with AMHS.

b. Interface – Interface type between the external system and the AMHS system (TCP/IP, RS232, etc.).

c. Data Direction & Initiative – The required dataflow direction (in regards to AMHS: Inbound, Outbound) and which system initiate the data transfer:

Inbound - Data is pushed to AMHS from the interfaced system.

Outbound - Data is pushed by AMHS to the interfaced system

d. Redundancy – Interface Redundancy

"H" – Dual Feed Interfaces that implement the "no single point of failure" concept

"L" - Single Feed Interfaces

e. Remarks – Additional supporting information

5.1.2.4 Interfaces to Systems and Networks (P)

Remarks Redundanc

y Data Direction & Initiative

Interface System

Full capability to have one or more AMHS network interface

H Inbound

Outbound

X.400 (PENS)

AHMS network

3 lines: London, Athens, Nicosia

L Inbound

Outbound

X.25 CIDIN

2 lines: Cairo, Amman

The Amman line is partial IP

L Inbound

Outbound

RS232 AFTN

1 line L Inbound

Outbound

TCP/IP (PENS)

SITA

1 line L Inbound

Outbound

TCP/IP

WMO

1 line Inbound

1 line Outbound

L Inbound

Outbound

TCP/IP

IMS




Remarks RedundancyData Direction &

Initiative Interface System

Two systems (+ test)

H Inbound Outbound

TCP/IP AIS - Current [Frequentis California]

TBD H Inbound Outbound

TCP/IP AIM - Future

Two systems H Inbound Outbound

TCP/IP AODB / CHOCS [IAA self-development]

Two systems H Outbound Inbound

TCP/IP EFS/IODS [Frequentis AG]

Two systems H Outbound TCP/IP ASMGCS [Saab-Sensis]

Two systems H Outbound TCP/IP EWAM [ERA/CSSoft]

Two systems H Outbound TCP/IP VOLMET/ATIS [Frequentis AG]

Two systems L Outbound TCP/IP

TelePC [IAA self-development]

At least 40 concurrent connections

L Inbound Outbound

TCP/IP UAT

IAA’s monitoring system H Outbound SNMP Management [HPOV]

5.1.3 Interfaces types and characteristics

5.1.3.1 The Interfaces types

1. IAA distinguishes between two major types of interfaces to external systems: “Dual Feed” Interface and “Single Feed” Interface.

2. Both Single and Dual Feed Interface shall have the same error correction and keep-alive mechanisms to maintain the highest availability possible.

3. The "Dual Feed" Interface shall be implemented for High Redundancy purposes. High Redundancy Interfaces are marked with "H" in the paragraphs above.

4. The status of the Interface health shall be constantly monitored and notification shall be generated by the AMHS system. (P)

5. The Bidder should describe in details the Interface design following the aforementioned emphases for all system interfaces. (Q)

6. All TCP/IP styled interfaces will be segregated from any other external TCP/IP interface connection via either the currently installed and operational IAA FW's, or via new FW's installed specifically for the purpose of protecting TCP/IP connections. The Bidder shall describe in detail how each interface – TCP/IP connection is to be made, what ports (if standard) will be used, what ports (if nonstandard) are needed and why, how the Bidder




sees the security of such connections and what, if any security setups the Bidder's system contains for such connections in as much detail as possible (Q)

5.1.3.2 Dual Feed Interface

1. The goal is to achieve high redundancy and maximum up time for the core application. To that end, the Bidder shall plan for dual system connectivity through two separate physical interfaces, to ensure that the connection has no single point of failure. The Bidder will take into consideration the segregation via FW's as defined previously for all TCP/IP connections external to the system. (P)

2. The Bidder should describe in details how his design of the relevant interface achieves the goal of no-single-point-of-failure. (Q)

5.1.3.3 Interfaces characteristics

1. The system shall be able to communicate with partners using the communication protocols Asynchronous Byte including Teletype (TTY), X.25, CIDIN (Entry, Exit, and Relay), RS 232, TCP/IPv4 and v6, and SMTP. As follows: (P)

a. Serial V.24/V.11 interfaces: (Q)

1) AFTN/ASYNC (RS 232)(direct, leased lines)

2) AFTN/Telegraphic Interface

3) AFTN/X.25 (PVC/SVC)

4) CIDIN/X.25 (PVC/SVC)

5) WMO/X.25 (PVC/SVC)

6) OLDI FDE ICD (X.25 SVC)

7) SITA/BATAP/EMTOX (X.25 PVC/SVC)

b. Ethernet LAN 10/100/1000 Interfaces: (Q)

1) AFTN/TCP/IPv4,6 (bilateral agreement)

2) AFTN/SOAP

3) AMHS P1/ATN (via ATN Router)

4) AMHS P1,P3/TCP/IPv4,6

5) AMHS SOAP (Service for SWIM)

6) FMTP (TCP/IP)

7) SITA/BATAP/MATIP (TCP/IP)

2. When using the X.25 service, the system shall fully support the ITU X.25 standards (1993, 1988, 1984, 1980). (P)

3. The X.25 implementation shall conform to the appropriate ISO 8882 standards and NET-2 test suites. (P)




4. The system shall support validation and invalidation of X.25 PVCs on a per-PVC basis. (P)

5. When using the TCP/IP v6 services, the Bidder should define what requirements there are of the receiving side, the network, FW's, switches and routers for the correct implementation of the RFC. In addition, the Bidder will assure the IAA that the use of IPv4 and IPv6 is according to the worldwide standards and does not include any proprietary settings. (P) (Q)

5.1.3.4 Interfaces configuration / definition

1. Interface configuration (definition) will be implemented using simple HMI (definition of standard well defined parameters) and will not require special code or programming (Protocol, port, address etc.). (P) (Q)

2. IAA requires a system HMI that will enable the IAA technical staff to configure an interface to an external system without the need for professional services and / or special development from the Selected Bidder. The IAA will make use of the Selected Bidders assistance and technical staff if required. (Q)

3. The interface will allow the defining of a messages time frame, messages type and messages scope to be handled/prepared for each system/interface. (P)(Q)

4. The operator shall have the ability to test, monitor and perform diagnostics on each of the defined interfaces. (P)(Q)

5.1.3.5 Messages response time

1. All AFTN data messages and all related updates should be automatically and immediately updated and sent by the AMHS (within 1 minute of their creation).(P)(Q)




5.2 Interfaces requirements – connected networks

5.2.1 AMHS/X.400 Interface (P) (Q)

1. The system shall be configurable to be able to exchange messages via AMHS/X.400.

2. The system shall implement the facilities of the AMHS Message Service as defined in sub volume 3.1 of the ATN SARPs.

3. The system shall be able to communicate with other AMHS/X.400 systems using the X.400 P1 protocol and the following transport services:

a. TP0/RFC1006/TCP/IP,

b. TP0/RFC2126/TCP/IP

c. ATN/ISO TP4/ISO CNLP/ISO LLC1 (to ATN Router)

4. The system shall provide an interface to connect local systems using the X.400 P3 protocol and the following transport services:

a. TP0/RFC1006/TCP/IP,

b. TP0/RFC2126/TCP/IP

5. As alternative to P3 the system shall offer an interface for automated ATM systems to exchange AMHS messages via Simple Object Access Protocol (SOAP). The system shall guarantee the full compatibility to the latest ICAO standards (Annex 10) as well as for any future updates/developments approved by ICAO.

6. The configuration of AMHS/X.400 circuits (i.e. a connection to an adjacent AMHS/X.400 MTA) using one of the above mentioned transport services shall be possible without the need of restarting the system.

7. The system shall be configurable to have one or more AMHS/X.400 connections.

8. AMHS/X.400 connections shall be serviced in parallel without affecting each other.

9. The Bidder shall connect the AMHS system to the AMHS network and execute the tests for the connection of the X.400 communication line according to the following recommended documents:

Title Description

020 - EUR AMHS Manual EUR AMHS Manual, Version 8.0, April 2013

020 - EUR AMHS Manual - Appendix AEUR AMHS Manual - Appendix A - Abbreviations, Glossary and Definitions

020 - EUR AMHS Manual - Appendix B EUR AMHS Manual - Appendix B - European ATS Messaging Service Profile

020 - EUR AMHS Manual - Appendix CEUR AMHS Manual - Appendix C - AMHS Testing Requirements




5.2.2 CIDIN/AFTN Interface (P) (Q)

1. The system shall be able to process AFTN messages in ITA-2 and IA-5 coding as defined in ICAO Annex 10 Volume II.

2. Depending on the routing settings, corresponding code conversions shall be performed.

3. It shall be possible to configure the length of the channel sequence number per communication partner to consist of three or of four figures.

4. It shall be possible to configure the alignment function per communication partner to be CR-LF or CR-CR-LF.

5. For messages received by the system it shall be possible to accept deviations from these alignment functions.

6. For messages transmitted by the system, only the alignment functions configured shall be used.

7. The system shall be able to generate and process AFTN SVC messages automatically, e.g. in case of interrupted message reception the system shall automatically request repetition of the missing messages.

8. Such automatic generation and processing shall be configurable per communication partner.

9. The system shall implement a dedicated handling of AFTN messages with a message text length exceeding 1,800 characters and up to 10,000 characters.

10. For each AFTN routing indicator it shall be possible for the operator to specify maximum message text length acceptable.

11. It shall be possible to refine these specifications per message category (e.g. ADEXP, NOTAM, FPL, etc.).

12. For each specification it shall be possible to select the corrective operation on an over-length message text: truncate (cut), segment, or reject.

020 - EUR AMHS Manual - Appendix DEUR AMHS Manual - Appendix D - AMHS Conformance Tests

020 - EUR AMHS Manual - Appendix E EUR AMHS Manual - Appendix E - AMHS Interoperability Tests

020 - EUR AMHS Manual - Appendix F EUR AMHS Manual - Appendix F - AMHS Pre-Operational Tests

020 - EUR AMHS Manual - Appendix GEUR AMHS Manual - Appendix G - European Directory Service

020 - EUR AMHS Manual - Attachment A

Attachment A - Change Control Mechanism of the EUR AMHS Manual and its Appendices




5.2.3 SITA Interface (P) (Q)

1. The system shall be configurable to be able to exchange messages via SITA Message Format Type B.

2. The system shall be able to communicate with SITA systems via BATAP/EMTOX (X.25) PENS. (X.400)

3. The system shall be able to process SITA messages in as defined in the SITA Type B manual.

4. It shall be possible to configure the alignment function per communication partner to be CR-LF or CR-CR-LF.

5. For messages received by the system it shall be possible to accept deviations from these alignment functions.

6. For messages transmitted by the system, only the alignment functions configured shall be used.

7. The system shall implement a dedicated handling of SITA messages with a message text length exceeding 1.800 characters.

8. For each SITA routing indicator it shall be possible to specify the maximum message text length acceptable.

9. It shall be possible to refine these specifications per message category (e.g. ADEXP, NOTAM, FPL, etc.).

5.2.4 WMO/IMS Interface (P) (Q)

1. The system shall be configurable to be able to exchange meteorological information messages via WMO Message Format.

2. The interface shall allow receive and transmit of traffic in WMO format.

3. The interface shall provide Gateway to AFTN/AMHS/WMO and allow receiving of alpha-numeric MET data and to relay them over the AFTN.

4. The interface shall provide Gateway to AFTN/AMHS/WMO with pre-defined distribution lists.

5. The Bidder shall describe the WMO interface to be provided with the system.




5.3 Interfaces requirements – IAA systems

5.3.1 AIS/AIM Interface (P) (Q)

5.3.1.1 General Overview

1. IAA has implemented a Frequentis California (formerly GWDI) AIS system (Aeronautical Information Service). The AIS ensures the flow of information necessary for the safety, regularity and efficiency of international civil air traffic management.

2. The IAA is in the process of selecting an AIM system that will replace the current AIS system, and the Selected Bidder is required to interface with that future selected AIM system (without an additional cost to IAA). It is foreseen that the Awarded Bidder will have to implement an interface to the current AIS system and once a new AIM system is selected and installed, to the new system as well.

5.3.1.2 General Requirements

1. All AIS transferred data messages and all related updates should be automatically and immediately updated by the AMHS (less than 1 minute of their creation) (P)(Q)

2. The Bidder shall detail its experience in previous projects involving Frequentis California AIS interface implementation. (Q)

5.3.1.3 Survivability, Availability and Characteristics (P) (Q)

1. The AIS – AMHS Interface shall be implemented as a High redundancy interface.

5.3.1.4 Technology (P) (Q)

1. The interface technology shall be based on the IP protocol.

2. It should be implemented on the standard AFTN interface.

3. The interface is Bi a directional interface from the AFTN to the AIS.

4. There are two (2) AIS server (Primary & Backup) and one (1) Test server.

5. The connection will be via a FW

5.3.1.5 Data (P) (Q)

1. The required information to/from the AIS/AIM shall contain all standard AFTN messages.




5.3.2 AODB (CHOCS) System Interface (P) (Q)


1. AODB- Airport Operational Database (CHOCS) is an IAA internally developed application and is used as a central operational database.

2. AODB runs on an IBM AS400 machine and the IAA's ICT division uses the AFTN TCP/IP protocol, for CHOCS external interfaces (Data transference).

5.3.2.2 General Requirements (P) (Q)

1. Basically, all AFTN messages shall be transferred from the AMHS into the CHOCS and departure messages will be transferred from the CHOCS to the AMHS system.

2. The Bidder shall detail its experience in previous projects involving implementation of interface to CHOCS, or if it has not previously done - to any other commercial or proprietary AODB.

3. The Bidder shall detail any experience they have had with connectivity or data transference using Web Services.

4. The Bidder shall coordinate the exact information required by this interface, the data structure to be created and the creation rate with IAA during the site survey and Detail Design phase - AMHS Project Coordinator.


1. The AODB (CHOCS) – AMHS Interface should be implemented as a High Redundancy Dual-Feed Interface.



2. It should be implemented on a standard AFTN interface.

3. The Interface is bi-directional.


5.3.2.5 Data (P) (Q)

1. Data includes all AFTN and CFMU (Through AFTN) messages.




5.3.3 Frequentis AG Smart Strips System (EFS) and Integrated

Operational Data System (IODS) Interface (P) (Q)


1. IAA has implemented a Frequentis AG Smart Strips System (EFS) and Integrated Operational Data System (IODS). The EFS/IODS is used for the electronic smart strip operation and data integration at BGN tower Area Control Centers (ACC) and in the Eilat tower.

5.3.3.2 General requirements

1. Basically, the AMHS messages shall be transferred from the AMHS into the EFS/IODS including FPL and related ATS messages: DEP, CHG, CNL, DEL, PNG, SAM, SRM, SCM, etc. In addition, NOTAMs and METEO messages will be sent as well. (P)(Q)

2. The Bidder should detail its experience in previous projects involving implementation of interface to Frequentis EFS/IODS or if it has not previously done - to any other EFS/IODS. (Q)




3. There are two (2) EFS/IODS servers (Active, Standby) and one (1) Test server.

4. The Interface is bi-directional.


5.3.3.4 Data (P) (Q)

1. Data includes all AFTN and CFMU (Through AFTN) messages.




5.3.4 A-SMGCS Interface (P) (Q)


1. The Sensis Advanced Surface Movement Guiding and Control System (A-SMGCS) is an Air Traffic Control (ATC) system that supports the enhancement of airport capacity, efficiency and safety in all weather conditions.

2. The system uses a variety of surveillance sensors such as radars and Multilateration, along with association and fusion processing, to determine accurate kinematic state information for airport terminal area ground and airborne targets and to present a complete situation awareness picture of the terminal area operations to air traffic controllers.

3. The AFTN interface enables A-SMGCS to obtain flight plan data. The A-SMGCS initiates the communication to the AMHS and handles the required data with the following basic steps:

Accept data from the AFTN data stream once the initial connection has been initialized from the ASMGCS system

Detect, extract and parse only the flight plan data from this stream

Make the acquired data available to the flight plan process FLIP, which will process and disseminate the data in the established fashion.

5.3.4.2 General requirements

1. Basically, the AFTN messages shall be transferred from the AMHS into the A-SMGCS. (P)(Q)

2. The Bidder should detail its experience in previous projects involving implementation of interface to Sensis A-SMGCS or if it has not previously done - to any other A-SMGSC. (Q)




3. There are two (2) A-SMGCS servers and one (1) test server.


5.3.4.4 AFTN Data (P) (Q)

1. Data includes standard AFTN and CFMU (Through AFTN) messages.




5.3.5 EWAM Interface (P) (Q)


1. IAA is implementing ERA Wide Area Multilateration (EWAM) system for Eilat Airport and Airspace. The EWAM system creates a reliable airspace situational picture, which depicts the position and movement of aircraft in the southern Israeli controlled airspace.

2. EWAM supports the Eilat Tower and in the future the new Ramon tower Controllers’ work environment, and enable increased safety, efficiency and situational awareness of operations.


1. All EWAM transferred data messages and all related updates should be automatically and immediately updated by the AMHS (within up to 1 minute since their creation). (P)(Q)

2. The Bidder should detail its experience in previous projects involving ERA WAM interface implementation. (Q)




3. The connection will be via a FW.

4. The interface connection shall be to the Production and Test environments.

5.3.5.4 AFTN Data (P) (Q)

1. Data includes standard AFTN and CFMU (Through AFTN) messages.

5.3.5.5 Survivability and Availability (P) (Q)

1. The AFTN – EWAM Interface shall be implemented as a High Redundancy Dual-Feed Interface.




5.3.6 ATIS/VOLMET System Interface

5.3.6.1 General overview

1. IAA has implemented Frequentis ATIS / VOLMET system.

2. The ATIS/VOLMET system, shall receive Meteorological data in accordance to ICAO Annex 3 – Meteorological Services for International Air Navigation directly from the AMHS.


1. All ATIS transferred data messages and all related updates should be automatically and immediately updated by the AMHS (within up to 1 minute since their creation). (P) (Q)

2. The Bidder should detail its experience in previous projects involving Frequentis ATIS/VOLMET interface implementation. (Q)


1. The ATIS/VOLMET – AMHS Interface shall be implemented as a High redundancy interface.




3. FW use will be decided upon at a later date but the Bidder must take into consideration any and all protection mechanisms for this connection

5.3.6.5 Data (P) (Q)

1. Data includes standard METEO in accordance to ICAO Annex 3 – Meteorological Services for International Air Navigation (Through AFTN) messages.




5.3.7 TelePC Interface (P) (Q)

5.3.7.1 General overview

1. The TelePC system is the Flight Data Processor (FDP) for the small domestic towers. The system provides electronic and paper strips for the controllers


1. The TelePC – AMHS Interface shall be implemented as a low redundancy interface.


1. The interface technology shall be based on TCP/IP protocol.


3. The interface is a single directional interface from the AFTN to the TelePC.

4. There are two (2) TelePC servers (Primary & Backup).

5.3.7.4 Data (P) (Q)

1. The required information from the TelePC shall contain standard AFTN messages.

5.3.8 UAT Interface


1. The UAT (User Agent Terminal) is a module requested within the AMHS system.

2. The UAT- User Agent Terminal is deployed to about 40 dedicated stationed on a dedicated closed network. Terminals are used to view and/or insert flight messages. The terminal will use standard web browser as a client to the AMHS/UAT system.

5.3.8.2 General Requirements (P) (Q)

1. UAT interface to the AMHS system is internal to the AMHS system as the UAT is internal module of the AMHS system.

2. User agent terminals will connect only to the UAT module using:

3. Standard web browser software (MS Internet Explorer v9 and up) (P), (Q).

a. Secured HTTP (HTTPS). The bidder shall supply install and define the SSL certificate.

b. User / Password Authentication mechanism will be used for accessing the UAT system. The bidder shall provide strong user/password mechanism. The bidder shall describe the implemented authentication mechanism.




5.3.8.3 UAT Architecture (Q)

1. Since the UAT is a module which is requested as part of the AMHS system, the Bidder shall describe the UAT module architecture including answers to the following characteristics:

a) Is the UAT integral part and an internal module of the AMHS system? b) If the UAT is a separate system / standalone with interface to the AMHS:

i. Who is the vendor / developer of the system? ii. How are the systems integrated? iii. Is the UAT system installed on the same servers as the AMHS system? iv. Description of other deployments implemented by the Bidder with the

same AMHS / UAT implementation? c) How does the UAT system Interface to the AMHS? d) What security considerations are in place to protect both systems?


1. The UAT– AMHS module Interface shall be implemented as a High redundancy interface and architecture as the AMHS system.




3. The interface is a Bi directional interface from the AFTN to the UAT.

4. FW use will be decided upon at a later date but the Bidder must take into consideration any and all protection mechanisms for this connection

5.3.8.6 Data (P) (Q)

1. The required information to the UAT shall contain standard AFTN messages.

5.3.9 Command & Control System Interface (P) (Q)

1. SNMP Traps and Alerts shall be sent to the IAA central C&C system (HP Open-view and/or Microsoft SCOM) within no more than 10 seconds delay after occurring via a FW using standard protocol ports.

2. The Bidder shall describe the system modules that send their status information and exactly what information is sent from these modules including interfaces statuses.

3. The Bidder shall describe the system statuses and the system component statuses.

4. The Bidder shall specify any relevant MIB supplied within the proposed system that could contribute to better controlling and monitoring of the system and its interfaces.




5. The Bidder shall describe examples for C&C implementation using the Bidders AMHS MIB and SNMP interface.

5.3.10 Other interfaces (Q)

1. The Bidder should describe additional interface available to the AMHS system such as: (Q)

a. Web services XML/Soap interface. b. FTP/SFTP c. Other interfaces available.

2. For each interface, the Bidder should describe: (Q)

a. Standards on which the interface is based upon. b. How to define/configure the interface. c. Data/messages that can be obtained by that interface. d. XML Schema where applicable. e. What qualifications are required to define the interface and will IAA personal be

able to define the interface independently. f. Redundancy – does the interface support high redundancy. g. Inbound, Outbound or bidirectional interface.




Chapter 6 - Information Technology Infrastructures Requirements




6. Information Technology Infrastructure

6.1 General

6.1.1 General Guidelines

1. This chapter describes the Information Technology requirements applicable for the AMHS platform infrastructure.

2. The computer hardware, software and other technological infrastructures shall also comply with all the functionality requirements as defined in chapters 2, 3, 4, 5 and elsewhere in the Tender Documents and will be based on Tier 1 vendors only.

3. To better understand the technological environment of IAA, The Bidder should refer to Annex 1-D.

4. AMHS’s proposed components (SW and HW) shall not be classified "end-of-sale" and/or “end-of-support" and/or "end of life".

5. This Chapter includes requirements both for the AMHS System and Project and for the Bidder’s Proposal.

6. The Information Technology requirements refer to the following areas:

a. System Environment and Survivability

b. Communications

c. Information Security

d. System Management, Monitoring & Control

e. Information Technology Software and Operating System

f. Information Technology Hardware

7. The Bidder response shall refer the above aspects per each of the following components:

a. AMHS System

b. Interfaces with external Systems

c. All types of Working Positions/Stations

d. Auxiliary Equipment (communication, racks etc.)

e. Communication networks

6.1.2 System Infrastructure Requirements (IAA's Supplies)

1. The Bidder shall design the required system infrastructure based on information provided by the IAA and on the data collected during the site survey.




2. IAA's responsibility will be limited to the design and implementation of all communication needs between the end sites and the central site, including but not withstanding cabling, connectors, switches, routers, phone lines, end points (wall sockets), connectors and security equipment (FW's). This applies except in those aspects where the bidder is required to provide internal system security, as well as setting the communications according to the Bidders requirements (within the boundaries of the IAA's definitions).

3. The Bidder shall take full responsibility for the installation and configuration of the AMHS's components such as Servers, Working Positions, Servers Racks, Communication Equipment, Connectors and Cables to the servers, Operating Systems, Applications etc., according to what is agreed upon with the IAA.

4. The IAA shall approve the Bidder's requirements for infrastructures. If the IAA does not approve any of the proposed infrastructure elements or design specifications, the Bidder is required to demonstrate alternatives and/or bypass these whilst maintaining compliance with the RFP requirements.

5. The IAA will make the final decision regarding the selected infrastructure alternative. However, the responsibility for the project’s successful implementation is on the Selected Bidder.

6. The Bidder should describe the all the infrastructure elements required for each component of the system - See table 9.9 section 9.2.3.1.5 for a detailed list of the IAA's Customer Furnished Equipment (CFE). (Q)

7. The infrastructure description should include at least the following requirements and any other relevant requirements that will be needed according to the Bidder's best practices: (Q)

a. Overall power requirements, including the published power consumption for each subsystem and component

b. Floor space needed for each component

c. Environmental conditions

d. Wall space for wall mounted equipment.

e. Network communications

f. Protocols used by TCP/IP communication

8. The Bidder shall submit a complete layout of the proposed system, including all system components, as needed for installation, operation, monitoring and maintenance. (P)




6.2 System Environment and Survivability

6.2.1 System Environment and operational modes

1. The Bidder shall propose a fully redundant system, comprising two server nodes (Primary and Secondary), which will comprise of the complete AMHS environment. (P)

2. The Bidder shall propose a non-redundant Test System, which will comprise a complete AMHS environment. (P)

3. The Bidder should plan, design and describe in its response the proposed solution (with reference to the following requirements) (Q)

4. The bidder will take into consideration that the Test System may not be connected to all system connections, internal or external as the main system, and shall define what he requires for the test environment to work (Q)

6.2.1.1 Operational System

1. Both Primary and Secondary computer nodes shall be used to run a fully redundant operational environment. (P)

2. The Primary and Secondary computer nodes will be installed at different geographical locations (at Ben Gurion Int. airport dedicated computers rooms), with a standard communications network between them, without affecting the overall service.(P)

3. The Bidder should plan, design and describe in its response the Central System consisting of two central computer nodes running all software modules, communications infrastructure and Users' services, needed to utilize a fully redundant AMHS system. (Q)

6.2.1.2 Test System

4. An additional computer node shall be used to run the Test System that will be utilized for the following:

a. System maintenance e.g. hardware fix/upgrade, system parameters tuning or installation of hot fixes for bugs during the project lifecycle. (P)

b. System training and testing of new features developed for IAA during the project lifecycle. (P)

5. The Test System shall meet the following requirements:

a. Support the same and full functionality of the AMHS system. (P)

b. The Test System shall be able to connect directly (or indirectly) to the same interfaces / clients as the Operational system. (P)




c. The Test System shall be similar to the Operational system as much as possible. (P)

d. Using the Test System will not affect the Operational system operation and functionality. (P)

e. No conflict shall occur when both Test and Operational systems are running simultaneously with old and new system versions (for example, when alert acknowledge on the tested System, it shall not affect the Operational system, etc.) (P)

f. The bidder shall provide a restore mechanism to match the Test and Operational systems configuration, for the case of an unsuccessful software installation or configuration change. (P)

g. The Test System will also serve for the training of new Users. (P)

h. The training system shall be planned and designed to serve several working positions concurrently , all types of interfaces and various training programs (e.g., system operators, system administrators) (P)

i. The Test System should enable IAA to use the system as an investigation and analysis of main system malfunction, simulating the operational system scenarios by uploading data from the operational system. (Q)

j. To make sure there will be no confusion between the Operational System and the Test System, the HMI of the Test System shall be marked clearly. (Q)

k. The Test System shall be monitored in the same manner as the Operational and Standby System. (P)

6.2.2 System Robustness and Resiliency

6.2.2.1 General

1. The combined system configuration (Network + Servers + Working positions) shall enable a continuous system operation (24x7) at the required level of availability as defined below. (P)

2. The system implementation should be planned without a single point of failure, on all levels (Servers, Applications, and Network). Any known single points of failure should be described, including the definition of how these do not affect the required system availability (P)

6.2.2.2 System Redundancy

1. The system shall be designed as a fully redundant system. (P)

2. The system redundancy shall ensure no loss of information during and after switchover. (P)

3. Each server will be able to maintain the total and full service of AMHS system. (P)




4. The “fail-over procedure” from Primary to Secondary, or vice versa, shall be automatic and transparent to the user, as well as allow for a manual procedure if the IAA so desires. (P)

5. The Bidder should describe the scenarios, which would cause a failover, the overall System switchover time, as well as describe how this would occur without interrupting the clients’ functionality, the running application and without loss of data; in addition, the bidder will describe the procedure for a manual failover. (Q)

6.2.2.3 Server's Redundancy

1. Each server shall be implemented with no single point of failure, including (but not limited to) dual power supplies, at least two communication cards (LAN), storage array disks in RAID-1&5 format etc. (P)

2. Each server (Primary/Secondary) shall have the ability to backup each other. (P)

3. Any server shall be able to provide full service to the connected interfaces and each working positions. (P)

4. The bidder should describe the servers’ configuration (Active-Active or Active-Passive model), the load balancing between the servers, the load balancing requirements as well as the implications on system’s performance in case of server failure. Usage of an Active-Active will be an advantage. (Q)

5. The Bidder should describe the servers’ failover capabilities. (Q)

6.2.2.4 Application Redundancy

1. The system’s applications shall be redundant and distributed among the redundant servers, thus being failsafe. (P)

2. Applications running on redundant servers shall be able to receive data from all sources as Users, interfaces etc. (P)

3. The Bidder should describe the application failover mechanism in detail for different failure scenarios. (Q)

6.2.2.5 Data Storage

1. The system’s data storage design shall be immune to erroneous data received from any interface or any other device used by the IAA to backup its servers (IBM Tivoli system). (P)

2. The bidder should describe the system storage (database, file etc.) and the redundancy mechanism, for any data type (configuration, logs, messages, etc.) (Q)

3. The system’s Data Storage shall be duplicated for resilience, while maintaining data coherency and integrity, in case of any problem. (P)




4. The Bidder should describe the different scenarios for Data storage failure (hardware or software) and the service continuation implication on the clients’ connectivity, application function and data consistency. (Q)

6.2.2.6 Network Redundancy

1. The Bidders design shall include two redundant communications network. (P)

2. Each server shall connect to two separate LAN switches or modular switch, which will contain the networks' VLANs. (P)

3. The communication center working positions shall have the ability to be connected to both network switches so that on the failure of one route, it will be able to auto-configure to work via the secondary connection (Using two-network connection). (P)

4. The Bidder should describe the server’s network switchover procedures for common failures of the communication network. (Q)

5. The bidder shall take into consideration that the full system network will be behind a FW.

6.2.2.7 Interfaces Resilience

1. The switch over between the servers shall be transparent to the interfacing systems. (P)

2. The Bidder should describe how the AMHS automatically reconnects to all systems’ interfaces as part of the server’s switchover procedure. (Q)

3. The Bidder should describe how the AMHS system would automatically switch over to the second connection in case of a communication failure. (Q)

6.2.3 System Availability

1. The proposed equipment shall be installed and configured in such a way, that all possible essential maintenance can be executed without interrupting the AMHS operation. (P)

2. An MTTR (Mean Time To Repair) of less than 1 hour for any single maintenance action is required. This includes the time required for fault localizing, repair, test and restoration to service. This time does not include the travel time in case of technical attendance is needed in the remote ground stations. (P)

3. The system Availability, excluding agreed maintenance periods, shall be 99.999%, i.e. calculated MTBCF (Mean Time between Critical Failure) of 60,000 hours based on following definition: Availability = MTBCF/ (MTBCF + MTTR) (P)




4. The bidder should present an RMA (Reliability, Maintenance and Availability) analysis of the proposed system configuration meeting the above requirement, both at the Subsystem level and full solution level (Q)

5. The bidder should supply proven availability performance from reference installations. (Q)

6.2.3.1 Boot & Switchover Time

1. System boot time:

i. System boot time (OS and Application) shall not exceed 300 seconds. (Q)

ii. The Bidder shall specify the system boot time (OS and Application) from equipment power-on until providing full functionality. (Q)

2. WP’s boot time:

i. WP’s boot time (OS and Application) shall not exceed 180 seconds. (Q)

ii. The Bidder shall specify the WP’s boot time (OS and Application) from equipment power-on until providing full functionality. (Q)

3. Complete System Switchover time shall be < 5 sec without data loss. (Q)




6.3 IT Centers

1. The IAA is responsible for providing the IT centers and infrastructure, such as, power supply, air conditioning, system’s external communication and the network infrastructure between the sites.

2. The IAA will provide a rack with the communication equipment for the external network connectivity, excluding the serial/x.25 line switching equipment (e.g. splitter, Moxa)

3. The bidder shall provide the details of the communications equipment, which are in the Bidder’s racks and are required for the internal communications between the servers (e.g. the model and amount of LAN switches, routers etc.) (Q)

4. The bidder shall provide a full monitoring system of all network and application aspects. (P)

5. The IAA will provide the cabinets and racks of each site that hosts the system’s computer nodes, LAN switches and other peripherals.

a. All AMHS Servers and communications equipment shall be installed in 19” communications racks. (P)

b. The bidder shall plan to minimize its racks amount, while leaving some space in racks for possible future expansion. (Q)

c. The Bidder should detail the number of racks required and racks’ content by submitting Visio schemes (e.g. servers, communications equipment etc.) (Q)

6.3.1 Installation

1. The equipment shall be designed so that it can be easily installed, removed, and reinstalled with a minimum of special tools and without extensive disassembly (P)

2. The different components in cabinets and consoles shall be implemented in such a way that all units and sub-units are completely accessible. (P)

3. Sliding drawers and tilting panels shall be provided where necessary. (P)

4. Wiring and cabling between units shall be brought together to form a relatively small number of interconnected cables. (P)

5. Cables shall be easily identifiable. Different colors shall be used to identify cables carrying different types of signals, e.g. supply, input, output signals, etc., all connectors shall be labeled clearly. (P)

6. Equipment supplied by the bidder shall be marked and labeled clearly and state it's function. The equipment should also be labeled as IAA property.

7. Test Environment should be labeled and marked in different colors then the operational environment to avoid operational mistakes.




6.3.2 Electrical Environment

1. All equipment shall operate from a single-phase power supply 50 Hz ±2%, 220 vAC phase-to neutral with voltage transients: ±15% over 0.1 to 2 seconds and ± 10% over 2 seconds. (P)

2. All performance requirements shall be achieved without readjustment when voltages vary between these specified limits. (P)

3. In case of failure of the commercial power, operations contingency is maintained using central on-line UPS system supplied by IAA for a period of at least 30 minutes.

4. An existing central power distribution panel with the necessary outlets will be available. It shall be the responsibility of the Bidder to provide the in-rack distribution panels. Each distribution panel shall contain a switch/circuit breaker.




6.4 Communications Requirements

6.4.1 General

1. The IAA will be responsible for supplying the network connectivity between the ATS system, the remote sites including the external AFTN/ AMHS interfaces communication.

2. The IAA WAN (Wide Area Network), in both the central and the remote sites, will be based on communication equipment (Routers, Switches etc.) as well as Fire Walls (FWs).

3. The IAA will provide the serial/X.25 lines and modems. The switching equipment and the connectivity to the system servers are under bidder’s responsibility.

4. The following diagram shows the ATS communications network

Figure 6.1 - AMHS Network Diagram




6.4.2 Communication Links’ Characteristics

1. The Bidder should define and clarify all networks’ bandwidth requirements (including peak loads, packet size and overall spare margins) for the proposed AMHS system. (Q)

2. The Bidder should provide the required AMHS’s inter-elements communications characteristics, which is not via the same LAN switch only. (Q)

3. The Bidder should fill a communications characteristics table (see below) for each of the communications links (Q)

Table 6.1- communications characteristics Between (“element A name”) & (“Element B name”)

1 IP Protocols and initiator/ directivity (tcp/udp) (A->B, B->A)

2 Application protocols and Functional purpose (Http -UI, SNMP -monitoring, etc.)

3 Bandwidth from element A to B (Kbit/Sec) 4 Bandwidth from element B to A (Kbit/Sec)

5 Max. Delay for 99.9% of the packets within a 10 minute interval (millisecond)

6 Max % of Packet loss within a 10 minute interval 7 Packet MTU size 8 Any other relevant parameters / requirements

6.4.3 IP Addressing

1. The AMHS system shall adopt the IAA’s IP Addressing Scheme. (P)

2. The bidder will cooperate with the IAA’s networking staff in respect to network configuration. (P)

3. The AMHS's communications shall support the use of VLANs. (P)

4. The AMHS should be flexible and support both predefined static IP addresses and a dynamic IP address pool (for remote devices e.g. Working stations, Printers, etc.). (Q)

6.4.4 Communications security

6.4.4.1 Network Protection

1. The IAA design of the AMHS Network Communications Security is based on a redundant central Fire Wall (FW), which will be used to separate between the various subsystems elements, as shown in Fig. 6.1. Communication stream encryption shall be performed by the Bidder (P).




2. The communications between the system’s servers and clients over the WAN, such as remote workstations, shall have the option to encrypt data communication using IPSEC VPN. (P)(Q)

3. In order to facilitate the correct use of the FW's, the bidder is required to provide the IAA a predefined list containing all the IP ports and protocols needed for the correct operation of the client-server, server-server interconnection. (P)

4. The IAA does not allow the use of multicast communication. (P)

5. The Bidder’s response should be in the following table: (Q)

Table 6.2- FW communications characteristics

Source-Name

Source-IP

Destination-Name

Destination-IP

Protocol- port

Flow-Direction

Comments

1 TBD TBD

2 TBD TBD

3 TBD TBD

6.4.4.2 Protocols

1. The AMHS’s communications, based on publicly known and approved protocols, should use the standard protocol’s ports. (Q)

2. The IAA will not allow non-standard networking technologies and protocols over the FW, whether WAN or LAN communications where the data is routed via the FW. (P)

3. The Bidder will be allowed to use non-standard ports, for standard applications or protocols, only if approved by the IAAs network and system security teams. (P)

4. The Bidder should specify if the AMHS’s communication makes use of secure protocols such as SSH, SFTP, SSL, HTTPS, SNMP V3, SFTP etc. (Q)

6.4.4.3 Communications Equipment

1. The communications equipment (switches, routers etc.) should be set with access permissions and passwords as per User’s roles. (Q)

2. The communications equipment should be set with ACL's to prevent unnecessary traffic between the IAA AHMS system and the external networks. (Q)

3. The communications equipment should be setup with VLANs for network segmentation between the various elements/ clients. (Q)




6.4.5 Network Time Synchronization Service - NTP Servers

1. To facilitate the interoperability and time synchronization of the AMHS solution, the Bidder shall propose a solution in regards to time generation and synchronization between the AMHS system entities. (P)

2. The proposed solution shall be capable of using any external time source for all AMHS components. (P)

3. All AMHS components should be able to sync with backup Timeserver automatically. (Q)




6.5 Information Security Requirements

6.5.1 Information Security Concept

1. Information security should be included in the AMHS system elements (see Annex 1-C), i.e. applications, computing infrastructures and communications. (Q)

2. The Bidder should describe the proposed AMHS System information security concept, and the available “out of the box” System Security Tools as detailed in the following sections. (Q)

6.5.2 Application Level Security

6.5.2.1 Authentication

1. The system should support individual User/password per User. (P)

2. The system should support hardened password structure (length, special characters). (P)

3. The system should require an authentication for every system logon. (Q)

4. The system should support security attributes, for example, idle session time auto logout, login lock, password change policy etc. (Q)

6.5.2.2 Access Control

1. The system’s entities/applications should support 3 Access Control levels (read only, update, add/delete). (Q)

2. The system shall support numerous Users’ Groups, each shall be mapped to the system’s entities/applications that it is allowed to access (Q)

3. A User may be assigned to any specific Users Group.(Q)

4. A User shall not be able to read or update information entities, which are not related to its Access Control level. If an update is required, AMHS operators will update the system.(Q)

5. The Administrator user of the system shall have the capability to define any Control Level/permission to any user/group on the system and/or hardware to allow the operation and maintenance of the system. (Q).

6.5.2.3 Application Events LOG

1. The System applications should generate LOGs for the following events:

a. All successful logons and any failed log-on attempts; (Q)




b. Listing of users’ add/update/delete operations; (Q)

c. System and application configuration change, parameters change, application data load/restore/backup, SW update etc.; (Q)

d. System and application status messages (start-up, shutdown, abort, switchover); (Q)

e. Any actions performed with administrative privileges, such as Users and roles change (create, delete, update) etc. (Q)

f. The system shall allow specific defined event logs (such as critical process, numerous failed login attempts from same IP and/or user, penetration attempts etc.) to be sent via E-mail/SMS. (Q)

2. For each event, at least the following information should be written in the logs:

a. Date and time; (Q)

b. User identification; (Q)

c. Station identification (name and IP address) (Q)

d. Nature and type of incident; (Q)

e. The information that was updated; (Q)

f. Entity identification; (Q)

6.5.3 Operating System Level Security

6.5.3.1 Authentication

1. The system should support individual User/password per User. (Q)

2. The system should support hardened password structure limitation (e.g., length, special characters). (Q)

3. The system should require an authentication for every system logon.(Q)

4. The system should support security attributes, for example, idle time logout, login lock etc. (Q)

6.5.3.2 Classification

1. Every entity in the system (such as applications, files, binaries, directories, devices, etc.) should be classified. (Q)

2. A User should not be able to read or update entities of a higher class or entities that his user attributes do not allow even if of the same level. (Q)




6.5.3.3 Operating System Hardening

1. The Operating Systems supplied for the system should be of the latest versions with latest patches. (P) (Q)

2. The Operating Systems supplied for the system should be hardened. This should include (amongst other hardening features), stopping/erasing redundant processes, running by default on the new-installed “vanilla system”. (P) (Q)

3. The Bidder should describe the hardening procedures implemented.(P) (Q)

4. The IAA may require additional hardening and will advise the bidder about it. The Bidder should verify that implementing these should not affect the systems operation and performance(Q)

6.5.3.4 End Point Security

1. End Point Security elements, such as Host IPS/Anti X/Personal FW, should be supplied and installed on the system, and updated by IAA (P) (Q)

6.5.3.5 Operating Systems events LOG

1. The Systems’ OSs should generate LOG files for the following events:

a. All successful logons and any failed log-on attempts; (Q)

b. Listing of users’ add/update/delete operations; (Q)

c. process status (entry, initiation, completion, deletion, restart, and abort); (Q)

d. File, volume, and database accesses (open, close, create, delete, rename); (Q)

e. Detected security incidents (including IPS events); (Q)

2. For each event, at least the following information should be written in the logs:

a. Date and time; (Q)

b. User identification; (Q)

c. Station identification (name and IP address); (Q)

d. Nature and type of incident; (Q)

e. The information that was updated; (Q)

f. Entity identification; (Q)

6.5.4 LOGs Management

1. The LOG files should be stored in CSV format. (Q)

2. Only privileged Users, as administrator, shall be able to access the LOG files. (Q)




3. The Bidder should summarize all AMHS's log files their location, type of information and format (Q)

4. The Bidder should describe the Logs' management method, name convention, archiving etc. (Q)




6.6 System Control, Management & Monitoring

6.6.1 General Requirements

1. A designated and Centralized Control, Management and Monitoring (CMM) application shall be provided. (P)

2. The Bidder should propose a redundant CMM application, installed on redundant servers, for high availability of these services. (Q)

3. Any type of failure in the CMM application, shall not affect the AMHS system performance and ability to provide a service. (P)

4. The CMM solution should provide a unified CMM tool (client application on working position) that can be used locally (on site) or by remote Users over the WAN. (Q)

5. The CMM application should support several User levels and operational access rights (from monitoring only through operator to administrator) to the control and maintenance functions of the Management System. (Q)

6. The CMM application shall communicate, with all AMHS system elements over AMHS's network using inbound communications. (P)

7. The CMM application communications with the AMHS system elements should be based on standard protocols, such as SNMP (v3 is preferred) and https for CMM working position (Q)

8. The proposed CMM application should provide a standard SNMP interface that enables extensive monitoring & control of any external third party systems. The Bidder shall provide all the implemented system's MIBs. (Q)

9. The Bidder shall be obligated to provide the data and to implement the interface between the AMHS system and the Monitoring & Control external third party systems. (Q).

6.6.2 Control & Management

1. The CMM application shall enable the control of system's elements functionality and management of system's elements parameters, thresholds, configuration etc. (P)

2. The CMM subsystem should keep (in central repository) the overall system configuration to enable a reconfiguration of the system’s elements in case of a failure recovery.

3. The Bidder should describe the MMC (Multi Management Console) capability to avoid management / configuration conflicts caused by simultaneous operation of multiple Maintenance WPs. (Q)

4. The Bidder should detail the MMC‘s control & management capabilities, per each of AMHS system elements (of any type), at the following aspects:




a. Application (Q)

b. Hardware (Q)

c. Communications (Q)

d. Users management (Q)

e. UAT module and workstations (Q)

6.6.3 System Monitoring

1. The CMM monitoring tool shall be able to present the current status and events of the entire AMHS system and its elements, e.g.: (P)

a. The status of system modules (Computers, applications, processes, network communications etc.);

b. Events that occur during the normal running process (such as faults, switchover etc.) and events that require operator’s attention and action;

2. The status, of AMHS system and elements, should include information such as the operational mode, faults, load, performance etc. (Q)

3. Built-In Test Equipment (BITE) shall be provided for both on-line and off-line testing of the AMHS systems and shall be able to detect any fault affecting the functionality and performance of the system. (Q)

4. The CMM monitoring tool should manage faults collected via different methods (e.g., SNMP, traps and logs). (Q)

5. CMM monitoring functionality shall not affect the AMHS system performance and / or functionality. (P)

6. The CMM monitoring should support events creation triggered when reaching predefined load/performance thresholds (Configurable thresholds). (Q)

7. The CMM monitoring should enable events severity classification (at least 3 levels: info, major, critical) per administrator preferences (Q)

8. The CMM monitoring shall store and manage the Events History for at least 180 days. The Event History amount of days shall be a parameter that can be configured by the Administrator user, but will not allow a value of zero (0). (Q)

9. The CMM tool provided should be simple and easy to operate and maintain the AMHS system and shall provide quick look (glance) indication of the status of each of the individual subsystem and elements of the AMHS. (Q)

10. The CMM system should be able to generate various reports (such as events performance, statistics, status etc.) based on the system’s managed and collected information. (Q)




6.6.4 Maintenance Working Position

1. The Maintenance WP shall include a CMM tool that inter-works with the CMM application, to provide the aforementioned Management, Monitoring & Control functionality. (P)

2. The Maintenance WP shall enable the maintenance technician to monitor the status of the equipment, displaying BITE information and control of its functions. (P)

3. The current AMHS status (e.g. operational/maintenance/failed) will be shown clearly on the top of each WP display (Q)

4. The User Interface should show a schematic/graphic layout of the AMHS elements together with their status (in different colors based on the status), as well as a hierarchical tree intuitive view of the system elements. (Q)

5. Any system event should be indicated with the level of severity (in color), Logs and Problem Codes associated with the failure and contact details for escalation of problem. (Q)

6. The CMM tool should display the faults on a dedicated events/faults display panel, which enables search/filter/sort on any event’s data, and invoke system’s reports (event severity level, event type, event status etc.). (Q)

7. The CMM tool shall support the generation of an audible alert for new system events. The administrator shall be able to disable/enable and set the audible alert tone per event severity classification. (P)

8. The operator shall be able to mute the audible alert triggered by any particular event, but any new events shall retrigger the audible alert. (P)

9. The operator should be able to set the status of any particular event to “maintenance” status, this in order to distinguish between real problem events and proactive maintenance events. (Q)

10. The CMM tool should provide guidance to the technician in the detection and correction of failures. (Q)

11. The Bidder should describe three (3) example fault/alert scenarios, one for each of the aforementioned section. Every scenario shall: (Q)

a. Start from the fault/alert occurrence;

b. Describe the relevant information flow (alert, trap, etc.);

c. Show the relevant management panels and reports;

d. Show the relevant recommendations for fixing the problem;




6.6.5 Reports

1. The system should provide a Reports Tool, which generates reports based on System's logs and stored data (Q)

2. The Bidder should describe the proposed Reports Tool capabilities, including the creation of new reports, edit of existing reports, templates, formats, features and constraints. (Q)

3. The Bidder should describe all the reports that provided by the system, and the types of reports that the tool capable of generate (e.g. Alerts reports, daily/monthly number of movements, Operational availability, maintenance reports etc.) (Q)

4. The Reports should be viewed on any Working Position, depending on users' role (Q)

5. The Bidder should describe possible manipulations on the reports, such as filtering, sorting and merging, based on: time, role, CWP, event type, data parameters etc. (Q)

6. All reports should be printable on shared network printers (B/W, color A4) (Q)

7. The Tool should support report export to a file in a standard format (CSV, XLS, etc.) or to email it, locally on the Working Position. (Q)

8. The reporting tool will enable graphical presentation (Q).




6.7 Information Technology Software and OS

1. System’ software elements shall be provided in the latest formal production version. (Q)

2. Software will be categorized as COTS software if it satisfies the following conditions:

a. It has been developed ready for sale (in stock) prior to receiving the contract. (Q)

b. It is available to the market. (Q)

c. It has an established history of use by multiple customers. (Q)

d. It is a product of a reputable, well-established company. (Q)

e. The vendor maintains it. (Q)

f. The vendor possesses the source. (Q)

g. It is not modified for the contract (customization in the form of setting/tuning parameters is not considered a modification). (Q)

3. The Bidder should provide a detailed list of all the system’s software (COTS, in-house developed or open source code) versions, its functionality, the server it runs on, the software roadmap and next release timetables. (Q)

6.7.1 Operating System Guidelines and Requirements

1. The Operating System (OS) of the system should be the latest version which was approved by IAA. (Q)

2. The Systems OS should be provided with the most recent relevant service pack (SP) issued by the OS vendor.

3. The Bidder should support all future SPs and other software updates issued by the OS vendor as long as the maintenance contract is valid within 2 months of the SP being released by the OS vendor. (P)

4. The Bidder shall describe the support for transitioning from an End of Life OS to a new version as part of the maintenance contract should one occurs during the life of the contract. (Q)

5. The Bidder will describe the procedure for installing and testing any patches they are required to install by the IAA, including OS patches, security patches and service packs. (Q)

6. Since many of IAA mission critical and operational systems run on the Linux based operating system platforms, the Bidder should clarify and explain, whether systems running on a non-Linux based Operating System is proposed and what are the advantages of using these to implement the AMHS system. (Q)

7. The usage of Red Hat Linux OS will be an advantage (Q).




6.7.2 Software Integrity Assurance

1. Software design should follow the guidelines specified in EUROCAE document ED-109 "Guidelines for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) System Software Integrity Assurance". (Q)

2. The software criticality level will depend on the particular equipment function; however, a minimum assurance of level 3 is required. (Q)

6.7.3 Development and Maintenance Environment and Tools

1. All the development and maintenance tools shall be standard, widely accepted, and of a recognized international manufacture. (P)

2. These tools should be usable for the whole duration of the contract allowing version modifications that are transparent to the software developed therein and/or upgrades and migrations. (Q)

3. The Bidder should describe the development environment used for the proposed solution including both software tools and hardware. (Q)

6.7.4 Database / Data Store

1. If used, the Bidder should use a standard Database (DB) for the systems. IAA’s preferred Databases are: (Q)

a. For Linux based server: Oracle DB, MYSQL.

b. For Windows based server: MS SQL.

2. The Bidder should describe the information stored in the system DB / Data Store for operational use and maintenance of the system. (Q)

3. The Bidder shall optimize DB / Data Store queries to improve system performance and reduce network usage. (P)

4. The Bidder should describe the DB / Data Store high availability mechanism and DATA integrity mechanisms used in the system. (Q)

5. Database / Data Store tools for tuning and management, including backup/restore and recovery procedures, shall be provided. (P)

6. All system's application data, parameters, configuration, statistics, maintenance & security events/logs and any other data needed for system operation, restoration or performance analysis shall be backed up. (P)

7. The Bidder should describe the provided backup and restore procedures. The required hardware & software for backup and restore process should be described as well (Q)




8. The backup shall not require system shutdown and shall not interfere with system operations (P).

6.7.5 Licenses

1. The Bidder should specify all software elements (OS, database, applications etc.) of the system, working stations and user terminals (If applicable) incorporated in the proposed solution that require licenses, in the following table: (P)

Table 6.3- Software Licenses

SW type (OS, DB App etc.)

SW vendor / revision

Number of licenses supplied

License expansion model

System / Application used for

1

2

2. After coordinating with IAA technical team the necessary licensing needed, The

Bidder shall supply all required licenses for the AMHS system and its elements (operational and test environment) as specified in this tender and guidelines for installation by IAA technical team.(P)




6.8 Information Technology Hardware

6.8.1 IAA’s General Requirements for Servers Infrastructure

1. Only First Tier recognized international manufactured COTS hardware shall be proposed for all AMHS components.(P)

2. IAA prefers the following platforms, in accordance with the OS: (Q)

a. for Linux: SUN, HP, IBM e Series

b. for MS: HP and IBM

3. The Bidder shall detail all IT hardware components of the system incorporated in the proposed solution, in the following table

Table 6.4- Hardware characteristics

HW type (Server, WP etc.)

HW vendor/ Model

CPU type and number

Memory type and size

Storage type and size

OS type and version

System/ Application used for

1

2

3

4. All hardware components installed in the server shall be certified by the server manufacture. (P)

6.8.2 Performance

1. The delivered system hardware at the inception of the project shall support 30% extra workstations than those initially provided. (P)(Q)

2. The CPU load occupancy of the server and workstations shall remain below 50%. The processing capacity of the servers shall not be affected by system expansion with 30% more workstations. (P)(Q)

6.8.3 Hardware requirements

1. The hardware should be modular and be ready for future upgrades such as: (Q)

a. Addition of processors (where possible),

b. Memory expansion (addition, not total replacement),

c. Addition of hard disks, addition of cards (free slots),

2. The hardware shall enable disconnection of elements (hot swap) for maintenance and other purposes without interrupting of normal system running. For example, Hot




Swap Disks, Power Supplies, Fans, etc. The Bidder should describe the servers’ configuration and hot swap abilities. (Q)

3. Network Interfaces

a. Every server / working positions shall have a dual 10/100/1000 Mbps Ethernet interfaces. (P)

b. The proposed servers should be equipped with one remote control interface (i.e., ILO for HP servers or similar for other vendors) for “Lights-out Management”. (Q)

c. The proposed servers should be equipped with additional interface for "keep-alive" signals between servers backing each other up. (Q)

6.8.4 Storage

1. The servers shall utilize their HD for storage for OS, applications, application data and logs. (P)

2. The usage of SAN (Storage Area Network) or External Storage will be an advantage (Q).

3. The servers should have separate disks for OS with RAID level 1. For the other needs additional disks with RAID level 5/6 is preferred. (Q)

4. For better performance hardware RAID controllers (not OS based) is preferred (Q)

5. The storage size shall be sufficient to keep all system data for at least 180 days. The bidder should specify the proposed storage size (Q)

6. The system should provide a notification before data override/deletion, to enable IAA copy the log file to a DVD/Tape. (Q)

7. The proposed storage system will be able to expand (by at least 200% of the initial storage) by adding disks/disk trays without operational shutdown. (P)

6.8.5 Working Positions & Peripherals Requirements

1. The Bidder should propose COTS software and hardware for the Working stations of the most advanced models and specifications. IAA prefers one of these Tier 1 vendors: IBM or HP. (Q)

a. The OS shall be preinstalled, as well as all applications needed to operate the system. (P)

b. The Working Positions shall have two Ethernet cards (10/100/1000 Mbit). (P)

2. System Displays

a. The system and application shall compatible with different screen sizes and screen resolution,




b. The system shall support 21''- 32" wide screens, non-glare, non-reflective high-resolution between (1024x768 and 1920x1080 or higher from Tier 1 vendor) for Telecom Center users (Q)

3. The Bidder shall propose a shared heavy duty “Color Network Printer” for all print activities of working positions (from tier 1 vendor). (P)




Chapter 7 - Scope of Work (SOW) and Bidder’s Details




7. The Project's Scope of Work (SOW)

7.1 Background and Highlights

7.1.1 Chapter Objectives

(a) This chapter describes the Project's Scope of Work (SOW) and provides requirements for the implementation project, including tasks, outputs, principles and project management methodology that the Supplier shall undertake during the Contract Period.

(b) The requirements in this chapter aim to minimize potential discrepancies of expectations between the IAA and the Bidder. These requirements should enable the Bidder to assess the scope and the depth of the response expected from it; however, IAA shall endeavor that the actual execution of the Project will be made as close as possible to the Bidder's best practices, standards, working procedures, etc.

(c) Section (b) above is subjected to IAA’s approval as stipulated in the Contract in Annex A – Approved Project Plan.

7.1.2 Overview of the Project's Objectives

(a) The IAA requests for Proposals for a complete integrative solution for

AMHS (Aeronautical Message Handling System) solution as a Turnkey Project with as many COTS components as possible.

(b) The Project’s Business Objectives and Goals are concisely described in Technical Appendix A – (The Technical Requirements), in Section 1.4.

(c) The AMHS System’s Implementation Concept and Project’s Schedule appear in Section 1.5.2 – System Implementation and Deployment, Section 1.7-12 – Project’s Schedule - of Technical Appendix




7.1.3 Overview of the Project's Implementation

7.1.3.1 Major Stages

(a) The Setup Project is comprised of two major stages:

i. Stage 1 – Basic-AFTN Stage – that should be completed no later than ARO + 9. Meeting the timeline at this stage is crucial. Following are Basic-AFTN Stage characteristics:

a. Basic-AFTN Stage will cater the same services as the current AFTN services for all its users.

b. Basic-AFTN Stage shall incorporate the minimal efforts that are necessary to meet the above mentioned goals. IAA welcomes any idea to facilitate and / or accelerate this stage. The Bidder is encouraged to raise ideas, however, the decision whether to adopt it in full or partially or not at all will be upon IAA’s sole discretion.

c. A temporary Communication Room that provides the same international and domestic connectivity capabilities as the current system will be established in parallel to the existing communication room.

d. The Transition process from the current AFTN system to the new AMHS / AFTN System at Basic-AFTN Stage may incorporate several sub-stages as needed in order to ensure a smooth and failure-free transition with minimal influence on the business continuity of the current system.

e. The System Final SAT shall be successfully concluded - after SAT Results submission, SAT Review, SAT Closure Path, etc. Meeting the timeline at this stage is crucial (P)

f. The Bidder shall consider various constraints and restrictions such as: Christian Holydays, Jewish Holidays, Peak Periods of Passengers Movement in TLV, General Shut down Vacations of the non-operational staff at IAA and other unexpected disruptions.

g. During the replacement of the Work Stations from the Current System to the New System, The Awarded Bidder shall cater Interim Period Service and Maintenance Services as stipulated in Chapter 8 (P).




h. Basic-AFTN Stage System Service will commence at the beginning of Basic-AFTN Stage Soak period as stipulated in Chapter 8.

ii. Stage 2 – AMHS Stage / The Complete System – Up to 3 months from Stage 1. The Complete System includes the completion of the Basic-AFTN system. For this stage meeting the timeline is less stringent than in Basic-AFTN Stage. In general, at the end of AMHS Stage the System shall be AMHS ready. Following are AMHS Stage Characteristics:

a. During AMHS Stage, the Awarded Bidder shall be able to implement options of the Basic-AFTN Stage System (such as: adding Client Workstations, or Management Workstations, etc.) if it will be requested to do so.

b. Towards the AMHS Stage Final Acceptance Tests all System’s Components that would have been operated as Basic-AFTN Stage Components will be upgraded to AMHS Stage System capabilities.

c. AMHS Stage System Service will commence at the beginning of AMHS Stage Soak period as stipulated in Chapter 8.

(b) The Supplier shall hold the Overall and Global Responsibility for the AMHS

solution at whole solely, even though IAA shall supply a few components of the solution such as: communication network, power supply, etc. Although the responsibility won’t be shared a few tasks will be done by IAA according to pre-defined accurate definitions by the Supplier. Bidder’s Tasks and Responsibilities and IAA’s Tasks are stipulated in Section 1.9.2 of Technical Appendix A.

(c) IAA requires a proven Out Of The Box ("OOTB") product/Solution. Only in

very special cases, where the classification of a requirement is a Technical mandatory requirement, and it is not included within the product’s OOTB capabilities (e.g. interfaces to existing IAA systems), then a specific development is required. In such a case, IAA may, at its sole and absolute discretion, withdraw from such a requirement and / or omit it from the acceptance tests scope.




7.1.3.2 Project 's Lifecycle Overview




7.1.4 Major Future Expansion Options

# Option Name Responsible Party

General description including supply volumes required

Expected Date of Exercise

Exercise Probability

1. Expansion of the System

1.1. DRP – Third Leg Bidder Implementing a third leg for a DRP purpose

TBD TBD

2. Services

2.1 Assistance with New AMHS Connection

Bidder Assistance with Connecting to a new Com Center via AMHS connection

TBD TBD

2.2. Training Course in Israel (travel cost included)

Bidder Periodic Training of the operators and/or the trainer of new and old operational functionality of the system

Yearly TBD

2.3. Training Course at the Bidder's Location

Bidder Yearly TBD

2.4. Additional Training Day

Bidder TBD TBD

2.5. Bidder consultancy Rate

Bidder TBD TBD

2.6. Bidder’s project manager Rate

Bidder TBD TBD

2.7. Bidder’s systems analyst Rate

Bidder TBD TBD

2.8. Bidder’s programmer Bidder TBD TBD

2.9. Bidder’s technician Bidder TBD TBD

2.10. Special service call Bidder TBD TBD

2.11. Per Diem Room and Board

Bidder TBD TBD

2.12. Air Travel Bidder TBD TBD

7.1.4.1 Option 1 – Expanding the system to DRP – Third Leg (O)

1. For this option, The Bidder shall propose a complete and integral future expansion of the AMHS System with DRP – Third Leg.




2. The Bidder should propose the Project as extension of the Ben Gurion solution.

3. The Bidder should assume that for the DRP – Third Leg the quantities as quoted in Chapter 9.

7.1.4.2 Additional Options

1. The Selected Bidder may propose additional options, beyond the abovementioned options.

2. IAA would be able to select suggested additional options (or part of them) them) according to ……in the …… phase.

3. Additional suggested options would not be part of The Bidder’s final score of the Technical Proposal.




7.2 The Bidder, Project Team & Organization –

Reference Model

7.2.1 Involved Parties (Including Subcontractors)

7.2.1.1 The Bidder's Details

1. The Bidder shall fill in the required information in the following table within the following sub-sections.

Party Company Contact Person

Phone, Fax & mail

1 Supplier / Integrator

Subcontractor 1

…

Subcontractor n

Local Support

Commercial representative

2. For each of the involved parties (The Bidder and Subcontractors / local support), the Bidder shall provide information according to the following form. The Bidder may add as many copies as needed for the following form. The Bidder shall provide information about all the involved parties and for each party in a separated table. If the Bidder has provided that information in Appendix C (the Bidder Statement) of the Invitation, a reference to the appropriate form is needed.

Details Required Information #

Registered office address 1.

Company’s registration number, registration date, country of registration

2.

Number of years under the same Corporate name 3.

Web Address 4.

Name of Owners (whether a company or an individual)

5.

Name of CEO and tenure in this position 6.

Names of directors 7.

Free text information such as: public or private company,

Description of Company 8.




Details Required Information #

branches etc.

Number of years of experience as a Prime Contractor in AMHS related projects:

9.

In Own Country

Internationally

Number of years of experience as a subcontractor in AMHS related projects:

10.

In Own Country

Internationally

20142013 2012 2011 2010Number of operational AMHS Clients: As a prime contractor?

11.

In Own Country

Internationally

20142013 2012 2011 2010Number of employees 12.

For each of the operational Systems as mentioned above in entry 9 as of year 2014, As a prime contractor, The Bidder is requested to attach a copy of the Site Acceptance Tests.

13.

7.2.1.2. Division of Roles between the Involved Parties

1. The Bidder shall describe the parties involved in the implementation of the AMHS project, and the division of Roles/Tasks.

7.2.1.3. Previous Cooperation between the Involved Parties

Involved parties Type and nature of joint activity

Customer Year Principal contractor

1st sub-contractor

…Local Support

Proposal to Tender

Pilot Operational system

Current Maint.

Other, specify:

7.2.1.4. Subcontractors Management

1. The Bidder shall describe any Subcontractors involved during the project's implementation and future options, as well as for the project's Warranty, Service and Maintenance stages.

2. The Bidder shall describe the subcontractors' experience concerning with the aforementioned activities. (Q)




3. The Bidder shall provide information as to the management methodology concerning subcontractors/suppliers. The description shall include quality control, risk analysis and a detailed description of the replacement strategy for the case where the subcontractor failed in the execution of the work according to the required standards. (Q)

7.2.1.5. Experience, Goodwill and Customers

1. The Bidder shall provide relevant information following the instructions and using the forms at paragraph Annex 7-A– Experience, Goodwill and Customers below. (Q)

2. The Bidder shall elaborate about procedures to verify customer’s satisfaction (such as surveys for examples) during the Project and afterwards during the Maintenance and Operational Term and Future Expansions. The Bidder shall provide its methodology, its forms and at least 2 recent forms (for each of the 3 activities that are mentioned above: the Project, the Maintenance and Operational Term and Future Expansions) that were filled by the Bidder's clients. (Q)

7.2.2. Project's Organization

7.2.2.1. Project Organization Structure

1. The Bidder shall introduce its proposed Project Organization Structure (Q)

7.2.2.2. Project Team Highlights

1. The Bidder shall refer to the following highlights while introducing the proposed key persons for IAA's project (see clauses: 7.2.3.2, 7.2.3.3, 7.2.3.4, etc.). (Q)

2. The Selected Bidder is required to provide a Project Team (PT) fully capable of managing, supervising and successfully executing the AMHS project – to provide a comprehensive, integrative and seamless solution as required by this Tender. The Bidder is required to present proven methodologies for the planning execution, monitoring and control of similar previous projects. The methodologies shall include all phases of the project lifecycle, such as starting with sites' surveys, update of requirement definitions, design, execution, through acceptance tests and assimilation. The Bidder is required to present its internal monitoring methodologies to ensure accomplishment of the plan's objectives (such as internal follow up meetings, internal review for the meaningful




milestones, other channels of communication with the participating parties, monitoring client's awareness and satisfaction, etc.) throughout the project's lifecycle. The Bidder shall present its methodologies and best practices for managing projects with remote international locations. (Q)

3. The PT shall include experts from different disciplines as required for such a project with proven ability to handle the challenges in the following domains: (Q)

a. Management of a multi-disciplinary project endeavor.

b. Assembling a pragmatic and applicable technological solution.

c. Coordinated teamwork with subcontractors from Israel (if there are such subcontractors) and abroad.

d. Interfacing with IAA external suppliers, equipment that shall be executed in a harsh environment - at an operational airport.

e. Providing warranty, service and maintenance support for the AMHS solution spanning over a long period of time.

4. The PT is expected to have thorough professional familiarity and experience with the main supply components in the project, such as: AMHS, Infrastructure design and execution and service and maintenance for a critical operational system requiring maximal availability. (Q)

5. The PT members shall be first-class, motivated and responsible professionals who are willing to engage in strenuous work, in possibly different time zones, maintain maximal availability and be capable of delivering the required tasks under tight schedules. They shall have full access to all relevant expertise and knowledge base of the Bidder's group. They shall also be capable of interacting smoothly and coordinating with IAA entities and suppliers. (Q)

6. IAA expects the Bidder to provide a formal authorization confirming that the PT members are trained, skilled, qualified for their role in the Project and kept constantly up to date with the best practices in their field of expertise, major suppliers and products, solutions applied in other organizations (AMHS Centers), as well as having high level acquaintances in their field of expertise, participate in relevant professional forums, etc. IAA expects to gain real added value from highly competent professionals who stand in the forefront of world technology. (Q)




7. The Bidder is required to have adequate operational backup capabilities to allow for an efficient response to possible overloads (e.g. quantities/locations) that are expected in such a project. (Q)

7.2.3. Bidder's Project Team

7.2.3.1. The Bidder's Proposed Project Team

1. All the details requested below shall be completed for all the team members involved in project, including subcontractors.

#

Worker’s N

ame

Role in

the Project

Profession

% Position Allotted to IAA Project

Expertise –No. of Projects

Seniority in the Field

Experience in the Field

Setting Up the System

Maintenance Stage

2. The Bidder shall append an organizational chart, which must include all personnel and lines of responsibilities of the IAA's Project.

3. During the Supplier's selection process, IAA shall approve all personnel proposed by the Bidder and have the right to interview key personnel and discuss changes if the Bidder's choice is deemed unsuitable. (Q)

4. The following requirements for destined Key Persons in the projects depicts IAA’s understanding of a suitable staffing for such a project; however, if the Bidder's common / best practice is different, the Bidder should not restrict itself to the following key persons and may offer its best staffing. (Q)

7.2.3.2. Details on the Project Executive

1. The Bidder shall appoint to the AMHS Project an Executive who will be the project sponsor. The Executive will ensure the project's success and will be authorized to make decisions and commitments on behalf of the Bidder Executive Management. The Executive will be also an escalation contact for any major issues. The Executive will be in direct contact with the Project Manager and with the Bidder’s top management. (Q)

2. The Bidder’s AMHS Project Executive shall be able to communicate fluently in the English language (written and oral) (P).




3. The Bidder shall provide a relevant CV of the Project Executive– this shall include at a minimum: (Q)

a. Personal details (name, contact details).

b. Formal education, training and qualifications.

c. Position in the Company.

d. Relevant experience as a project manager / project executive of similar projects.

e. Two references from the past 5 years while acting in similar capacity (preferred if applicable)

f. Availability.

7.2.3.3. Details on the AMHS Project Manager

1. The Bidder shall appoint a suitably qualified and experienced Project Manager for the duration of this project hereinafter referred to as the Bidder’s AMHS Project Manager. (Q)

2. The Bidder’s AMHS Project Manager shall be assigned fully and solely to the IAA’s ATS Project.

3. The Bidder’s AMHS Project Manager shall be able to communicate fluently in the English language (written and oral) (P).

4. The Bidder’s AMHS Project Manager is expected to be in Israel as needed during the duration of the project, at least once a month or as per the project stages criticality and steering committee meetings. (Q)

5. The Bidder shall provide a relevant CV of the destined Bidder’s AMHS Project Manager – this shall include at a minimum: (Q)

a. Personal details (name, contact details).

b. Formal education, training and qualifications.

c. Relevant experience in Project Managing of AMHS related projects.

d. Two references from the past 5 years.

e. Availability.

f. Compliance with clause 7.2.2.1 – Project Team Highlights.

6. The IAA shall reserve the right to interview the Bidder’s AMHS Project Manager. This interview will take place in person at IAA premises.

7. If the Bidder’s AMHS Project Manager is replaced by the Bidder during the setting up period of the Complete System, a notice period of 30 days must be given to the IAA, which in turn reserves the right to interview and




approve the replacement. The replacement must spend at least 15 days in Israel with the incumbent Bidder’s AMHS Project Manager to accomplish a full handover.

8. IAA reserves the right to request the replacement the Bidder’s AMHS Project Manager at its discretion with a notice period of 30 days. The IAA shall reserve the right to interview and approve the new Bidder’s AMHS Project Manager. The replacement must spend 15 days in Israel with the incumbent Bidder’s AMHS Project Manager to accomplish a full handover.

7.2.3.4. Details of the Senior Technical Manager

1. The Bidder shall appoint a suitably qualified and experienced Senior Technical Manager for at least the duration of the Set-Up of Complete System project, hereinafter referred to as the project AMHS Senior Technical Manager. (Q)

2. The AMHS Senior Technical Manager is expected to be in Israel as much as needed during the duration of the aforementioned project, in particular during the RRD and Design, Installation and Commissioning, Integration and Tests phases of the project. (Q)

3. The AMHS Senior Technical Manager shall be able to converse fluently in the English language.

4. The Senior Technical Manager shall at all times be under the direction of the Bidder's Technical Executive Director (or CTO).

5. The Bidder shall provide a relevant CV of the AMHS Senior Technical Manager – this shall include at a minimum: (Q)

f. Personal details (name, contact details).

g. Formal education, training and qualifications.

h. Relevant experience in Project Managing of AMHS projects which include a complete integrative solutions.

i. Two references from the past 5 years.

6. The Bidder shall provide a relevant CV of the Chief Technology Officer – this shall include at a minimum: (Q)

j. Personal details (name, contact details).

k. Formal education, training and qualifications.

l. Relevant experience in project managing of similar AMHS projects or IT Implementation projects.




7. The IAA shall reserve the right to interview the AMHS Senior Technical Manager.

8. If the IAA’s AMHS Senior Technical Manager is replaced during the project term, a notice period of 30 days must be given to the IAA, which reserves the right to interview the replacement.

7.2.3.5. Details of the Installation Team Manager

1. The Bidder shall appoint a suitably qualified and experienced field engineer to manage IAA’s installations during the Set Up of the Complete System Project. (Q)

2. The Installations and Technicians Team Manager shall be able to converse fluently in the English Language.

3. The Installations and Technicians Team Manager is expected to be in Israel as needed during the relevant Stages.

4. The Bidder shall provide a relevant CV of the Installations and Technicians Team Manager – this shall include at a minimum: (Q)

m. Personal details (name, contact details).

n. Formal education, training and qualifications.

o. Relevant experience in managing AMHS solution Installations.

p. Two references from the past 5 years.

5. The IAA shall reserve the right to interview the Installations and Technicians Team Manager.




7.3. Project's Lifecycle – System Implementation Process

7.3.1. Introduction

1. Section 7.3 intends to provide information about the project's major stages, timetable, major activities and deliverables.

2. The project life cycle in this chapter is presented as the minimal scope of requirements. The Bidder is entitled and encouraged to propose enhancements and/or slight amendments based on the Bidder's best practice, as well as to present examples of deliverables similar to those requested during the various stages of the Project to depict its abilities and execution practices (Q)

3. The above mentioned shall not derogate from the full and complete responsibility of the Bidder for the performance of the Project in compliance with the System Requirements as stipulated in chapters 1-9 and compliance with the provisions of the Contract and completed within the defined timetable.

7.3.2. Setting Up the Complete System / Project Plan – Overview

1. Refer to Clause (c) - Complete System – Implementation major mile stones.

2. The following table summarizes in more details the major stages and milestones as well as expected time table that IAA requires for the Complete System Implementation.

3. The Bidder shall insert its planned timeframe (number of months from ARO) wherever this was not specified by IAA. (Q)

4. The Bidder is requested to distinguish between a formal Payment Milestone – in which the Bidder should comply with IAA’s requirements (such as the HLD for both stages) – and Informal Stages – which stands for expectations’ coordination solely.




Stage / Milestone

#

Stage / Sub-Stage [Section number]

Due Date for Finalizing The Stage / Sub-Stage (ARO +# Months)

Comments

0. Signing the Contract ARO

Receipt of Order. A payment milestone

1. Kick Off TBD By the Bidder

A Draft Site Survey Plan, Draft PEP and Draft RRD are expected 5 working days before the Kickoff Meeting.

1.1. Project Execution Plan (PEP) 1.2. Sites Survey 1.3. Revised Requirement Definition (RRD) [ 7.3.5.4]

2. System Design Review TBD By the Bidder

The Bidder shall submit all the documents that will be reviewed (see 2.1 – 2.6 below) at least 5 business days before the Review. A payment milestone

2.1. High Level Design for both Basic-AFTN Stage and AMHS Stage [ 7.3.5.6]

2.2. Architecture [ 7.3.5.5] 2.3. Basic-AFTN Stage - Detailed Design [ 7.3.5.7] 2.4. Basic-AFTN Stage – Site Engineering Report. 2.5. Basic-AFTN Stage – FAT & SAT Plan and Procedures 2.6. Presenting the System Maintenance Program SMP

3. Setting Up Basic-AFTN Stage System 3.1. Manufacturing / Purchasing / Development /

Integration [ 7.3.5.8]

3.2. FAT [ 7.3.5.9] TBD By the Bidder

3.3. Formal Review: IRR (Installation Readiness Review): the Supplier Accepts IAA’s Supplies.

TBD By the Bidder

3.4. Delivering the System Components to Israel, Installation, Commissioning and Training [ 7.3.5.10]

3.5. Setting Up the Temporary Communication Room, Installing Main System servers and Communication Network at the Temporary Room. In Addition, individual testing verifying the operation of each application at the same level (such as: functionality, performance, etc.) as the current system

3.6. Sites' Installation, Commissioning and Partial Acceptance

May last for a few weeks. Interim Period Warranty, Service and Maintenance Starts.




Stage / Milestone

#



Comments

3.7. System's Final SAT Commencement Not Later than ARO+6 Months

3.8. System's Final SAT Completion [7.3.5.13] Not Later than ARO+8 Months

Overall System Acceptance Formal Review: SAT. A payment milestone

3.9. Commencement of the Soak Period and Activation of the System as Fully Operational

Not Later than ARO+9 Months

3.10. Soak Test Completion [ 7.3.5.14]

Not Later than ARO+12 Months

Ends with issuing a Final Certificate of Acceptance (COF) Basic-AFTN Stage by IAA A payment milestone

4. Service and maintenance Period for Basic-AFTN Stage [ 7.3.5.15]

4.1. Interim Service and Maintenance Period for Basic-AFTN Stage starts [ 7.3.5.12]

Starts at the Commencement of the Sections SAT Tests

4.2. Interim Service and Maintenance Period ends At the Soak Test Completion (see entry 3.8 above in this table). The Bidder should note that Payment for the full Service and Maintenance for Basic-AFTN Stage System starts at Soak Commencement).

Starting AMHS Stage 5. Setting Up AMHS Stage System

5.1. Kickoff As per Basic-AFTN Stage 5.2. AMHS Stage – Detailed Design and final BOQ As Per Basic-AFTN Stage

5.3. Manufacturing / Purchasing / Development /

Integration [ 7.3.5.8]

5.4. FAT [ 7.3.5.9] 5.5. Formal Review: IRR (Installation Readiness Review):

the Supplier Accepts IAA’s Supplies. TBD By the Bidder

5.6. Delivering the System Components to Israel, Installation, Commissioning and Training [ 7.3.5.10]

5.7. Transition of the Temporary Communication Room to




Stage / Milestone

#



Comments

the Permanent Core Room without service interruption. . In Addition, individual testing verifying the proper operation of each application and Component.

5.8. Sites’ Installation, Commissioning and Partial Acceptance of AMHS Stage, in parallel to the operation of Basic-AFTN Stage.

May last for a few weeks. Interim Period for Service and Maintenance.

5.9. System's Final SAT Completion for AMHS Stage [7.3.5.13]

Overall System Acceptance Formal Review: SAT

5.10. Soak Test Commencement of AMHS stage = Certification of the AMHS system based on Doc20 and Activation of the Complete System as Fully Operational [ 7.3.5.14]

5.11. Soak Test Completion of AMHS Stage Not Later than ARO+12 Months

Ends with issuing a Final Acceptance Certificate by IAA A payment milestone

6. Service and maintenance Period for AMHS Stage [ 7.3.5.15]

In case IAA won’t select the Lease track

6.1. Interim Service and Maintenance Period start [ 7.3.5.12]

Starts at the Commencement of the Sections SAT Tests as described in 5.7.1

6.2. Service and Maintenance Period of AMHS Stage start Starts at the End of the SOAK Period for AMHS Stage.

7.3.3. Setting up Future Options

1. For each options listed in the corresponding clauses - in chapter 9, the Bidder shall describe a tentative Project Plan and timetable for implementation (according the example above at section 7.3.2 Setting Up the Complete System / Project Plan – Overview).

The suggested format is the following table:




# Stage / Sub-Stage Due Date for Finalizing The Stage / Sub-Stage (ARO + M)

Comments / details

1 2 .. … … …

2. Each option and proceeding in this respect shall be implemented in the

manner stipulated in the provisions regarding "Variations" in the Contract. However, the prices stipulated for each option shall include all managerial tasks and statement of work necessary to implement the option.

3. For option 1, Each shall be considered as a Project in itself.

4. IAA shall be entitled to activate each option any time during the Contract Period.

5. The Bidder shall stipulate for each option all the relevant details required for the implementation of each option as stipulated at 7.1.4.1 above.

6. For the avoidance of doubt, it is hereby clarified that for the performance of each Option by the Bidder, the Bidder shall be entitled only to the sum stipulated by it for the relevant Option in its Price Proposal.

7. The Bidder’s proposal shall refer to all the above. (Q)

7.3.4. Reviews

7.3.4.1. Formal Reviews

1. This chapter specifies the formal reviews that shall be executed throughout the project. The schedule for the reviews shall be set in the project's Gantt chart as a single milestone or a series of milestones (e.g. the SAT, Sites and Production Readiness Reviews) as needed.

2. All the Reviews will be held in Israel in Ben Gurion Airport unless IAA approved in writing another location.

3. The Bidder shall list and describe any additional recommended reviews as per its best practice.

4. In addition, the Bidder and IAA can initiate technical design reviews (DR) or managerial reviews (PMR) when and if needed, in order to attend unexpected or special issues that might arise throughout the project. The following is valid for each stage.




# Name Estimated Schedule

Responsibility

1 High Level Design Review (PDR) The Bidder

2 Installation Readiness Review (IAA’s Supplies Readiness Review (per each site))

The Bidder

3 SAT Review The Bidder

4 Soak Review The Bidder

7.3.4.2. Review Procedure

1. All the formal reviews shall be registered, as aforesaid, as a single milestone or a series of milestones in the Project Management Plan including the necessary precedent activities in the Gantt chart. All the technical and managerial reviews that are to be established during the project shall also be updated in the project plan.

2. Five (5) business days prior to the review, unless otherwise agreed upon between the parties, the Bidder shall submit to IAA all the documentation accompanying the review and the basis for their approval.

3. After the review, the Bidder shall prepare and publish a document titled "<topic> Review Summary" (‘topic’ refers to each of the formal reviews listed in the table above), and present it for the approval of IAA. The summary shall include updates to the accompanying documentation of the review.

4. In case the review is associated with a milestone, its existence does not constitute automatic approval of the milestone. Only after the review has ended successfully and has been approved by IAA, the milestone will be considered approved. IAA will approve the review, if the conditions for it are matured, within 5 working days after its completion.

7.3.4.3. Readiness Review Procedure

1. The Bidder shall plan and create a comprehensive checklist, for each of the readiness review activities and milestones that must be accomplished to ensure the timely readiness of the relevant milestone.

2. This checklist shall include the list of the Bidder and IAA’s prerequisite tasks / actions, whose responsibility, due date, progress status and Red/Yellow/Green (RYG) indicator for quick status visibility and tracking purposes. The Bidder shall send the checklists for the review and approval of IAA.

3. The Review procedure of the Readiness activity shall be according to the Review Procedure detailed in the previous clause.




4. The Bidder is requested to describe in its response how it is planning to meet all the requirements above (1, 2 and 3) if he will be the selected Bidder (Q).

7.3.5. Major Sub- Stages – Activities and Deliverables Overview

7.3.5.1. General

1. The following list of major sub-stages shall not be considered to be exhaustive; some of the sub-stages are not mentioned at all; however, the Bidder shall accept the following milestones, responsibilities and elaborate in an equivalent manner all the proposed sub-stages. (Q)

2. The Bidder shall describe the following:

a. The Bidder shall describe the involvement of the Bid Manager and the Bid team in Setting-Up the Complete System. IAA relates high importance to the Bid Manager's involvement at least until completion and approval of the RRD stage. (Q)

b. The Bidder shall describe the proposed Executive Project Manager, The Proposed Project Manager, the Proposed Technical Manager and other key staff proposed (upon Bidder's discretion) in preparing and approving the Proposal. (Q)

c. The handover / overlapping between the Bid Manager and the AMHS / AFTN Project Manager. (Q)

7.3.5.2. IAA's Approval for Each Stage

1. The Bidder shall accept that each stage is concluded only upon IAA's Approval of completion. For example the revised Requirement Definition stage is concluded by IAA's approval of the RRD Summary document.

2. The Bidder shall accept that IAA's Approval, for each stage as described below, is a threshold condition for proceeding to next stage and/or for a payment milestone, in compliance with Section 11 and 20 in the Contract.




7.3.5.3. Lineup

Milestones Deliverables Responsibility

1 On-Site Kickoff Meeting (a) Kick off Presentation High Level Project Plan Project Steering Committee Defining the Review process

The Bidder

2 Project Work Plan Review (PEPR)

Detailed Project Execution Plan.+ Baseline Freeze

The Bidder

PEPR – Summary document The Bidder

3 IAA's approval to Project Execution Plan

PEP Approval document + Baseline Freeze

IAA

(a) On-Site Kick-off Meeting would be held in Israel in order to define and finalize

technical and administrative issues of the project. The visit shall last as many days as requires to be able to include the Official and Final Site Survey according to the Supplier's methodology. The Bidder shall refer to Section 12.2 of the Contract for further details relating to the Official and Final Site Survey.

(b) The Sight Engineering Report (SER) should incorporate the following activities and information:

a. Finalizing all System’s Components that should reside in IAA premises. b. The Supplier should well define each component required supplies by IAA

such as: Space, Power Supply, and Communication Network, for all required activities such as: locating, installation, commissioning, operating, maintenance, etc.

c. IAA will decide the components exact locations. d. During the Site Survey the Supplier shall be acquainted with the existing and

planned conditions. e. Shortly after the Site Survey, the Supplier is expected to send IAA a draft

with all needed preparation for locating, installing, commissioning, operating and maintaining each component. That should include information such as:

i. Components’ Requirements. ii. Existing Conditions.

iii. Required Site Preparations. iv. Sharing the Preparations’ roles among the Supplier and IAA

including the desired time table. v. High level design of the connection / integration between the

Supplier’s supplies and IAA supplies, including demarcation points and acceptance tests by the supplier to IAA’s supplies.




vi. Site Preparations should incorporates themes such as: removal of existing equipment, space, power supply, communication network, access control, air condition, furniture, demarcation points, etc.

vii. IAA will study the report and will comment on it to the Supplier. viii. The Supplier shall amend its report until IAA’s approval.

f. During the Supplier’s Selection Process IAA will provide the Bidders a list of Supplies that are available for the System / Project. IAA prefers that the Bidders will adapt their solution to IAA’s constraints; however, if the Bidder needs extra’s it should write it in its proposal. Meeting IAA constraints may contribute to facilitate IAA’s preparation, which might be expressed in savings of time and money. Hence, the closer the Bidder will be to IAA’s constraints, the higher potential for quality grade that it will receive.

g. Timetable for providing the SER and its approval is crucial to IAA in order to meet its desired due dates.

h. The Bidder is requested to elaborate in its response how it is about to meet IAA’s challenge as depicted above (Q).

7.3.5.4. Revised Requirements Definition (RRD)

# Activities Deliverables Responsibility

1 Revised Requirement Definition (a) Requirements' Freezing.

Revised Requirement Definition document

The Bidder

2 System Requirements Review RRD – Summary document The Bidder

3 IAA's approval of the RRD Summary document

RRD Approval document IAA

(a) The RRD Document shall be derived from the IAA's Technical Reference Requirements, the Selected Bidder’s Proposal, the various clarifications that were submitted by the Selected Bidder during the Bidder’s Selection Process and necessary updates to the aforementioned documents that may have been created due to the long period that has elapsed since originally writing these documents until their implementation.




(b) Following is a ”Blocks Diagram” that illustrated the aforementioned text:

Figure 1 - Overview of the RRD Stage




(c) Following is an example (from another Tender) for a single requirement during the RRD stage:

(d) For avoidance of a doubt, IAA explicitly declares that the RRD stage shall neither influence nor change either the final cost or the timetable in any way. The meetings are intended merely to "fine-tune" the requirements within the basic scope of the project that shall serve the Contract and Project implementation.

7.3.5.5. Architecture / High Level Design for Both Stages


1 Defining System Logical Architecture

Defining System Modules and Functionality

Defining System's Physical Configuration

Defining System Sizing

System Architecture Document The Bidder

2 Analyzing the environment in which The System shall be installed (see note (a) below)

Site Engineering Report - Required Infrastructure for the System's installation, operation and maintenance

The Bidder





3 Formation of System Interfaces Specification

System Interfaces Specification's document.

The Bidder

4 Specification of 3rd parties products to be integrated in The System

3rd Party Products – Specification for Purchase.

The Bidder

5 Formation of Administrative Management Concept

A document, referring to various issues, such as: monitoring functionality, alert levels, special site specific principles, HMI, etc.

The Bidder

6 Formation of a Conceptual Test Plan (see clause 7.3.7)

Conceptual Test Plan doc. (STP) The Bidder

8 Formation of a Conceptual Quality Plan (see clause 7.4.6)

Conceptual Quality Plan doc. (QAP)

The Bidder

9 Risk Identification and Analysis Risk Analysis and Mitigation Plan Document

The Bidder

10 Updating the Project's Work plan Updated Project's Work plan approved by IAA

The Bidder

11 System Architecture Review (SAR)

SAR– Summary document The Bidder

12 IAA's approval to SAR SAR Approval document IAA

a. The Required infrastructure (table entry #2 above) shall refer, inter alia, to power supply requirements, communication network, floating floor, survivability requirements, air conditioning, floor space, height, access control, recommended furniture both for operation and storage, lighting, separation of areas, windows, etc. For more details see 7.3.4.3 – b (SER).

7.3.5.6. High Level Design (for each stage separately)


1 Formation of a configuration for each Working Positions for the phase

Working Positions' Configuration document

The Bidder

2 System Interfaces High Level Specification

System Interfaces High Level Specification's document

The Bidder

3 Design of HMI principles and interaction flow

HMI Principles document The Bidder

4 Design of IAA’s specific Requirements - High Level Specification

IAA Specific Requirements - High Level Specification Document

The Bidder





5 Defining System Tests Description of all the System tests (STD)

The Bidder

6 Formation of a Preliminary Installation Plan

Preliminary Installation Plan document

The Bidder

7 Formation of a Preliminary Training and Assimilation Plan

Preliminary Training and Assimilation Plan document

The Bidder

8 High Level Design Review (PDR)

PDR– Summing Up document The Bidder

9 IAA's approval to PDR PDR Approval document

IAA

7.3.5.7. Detailed Design (for each stage separately)

In this phase, IAA would not need to approve some of the deliverables of this stage. IAA would merely approve receipt of the deliverables, but not their content. All deliverables that do not need to be approved by IAA are marked – Not a formal deliverable. For the avoidance of doubt, it is hereby clarified that the abovementioned shall not derogate from the full and complete responsibility of the Selected Bidder for the performance of the Project in compliance with all of the Functional Requirements and any other and/ or additional requirement as stipulated in the Contract.


1. Detailed Specification for each Working Position for the phase

Detailed Specification for each Working Positions document – Not a formal deliverable

The Bidder

2. Detailed Design of the System Data Model (especially for new developed items such as IAA’s Specific Requirements)

Detailed Design of the System Data Model document – Not a formal deliverable

The Bidder

3. System Interfaces Detailed Specification

System Interfaces Detailed Specification's document – Not a formal deliverable

The Bidder

4. Detailed Design of The System HMI

Detailed Design of The System HMI document

The Bidder

5. Defining System Tests Scenarios

Test Cases Scenarios document (TCS)

The Bidder

6. Preparing a Validation Matrix ("VRTM") [see 7.3.7.2 below]

VM document for IAA's approval.

The Bidder





7. Detailed Design of an Installation Plan

Detailed Design of an Installation Plan document

The Bidder

8. Detailed Design of Training and Assimilation Plan

Detailed Design of Training and Assimilation Plan document

The Bidder

9. Detailed Design Review (DDR) CDR Summary document The Bidder

Note: IAA reserves the right to review and comment the CDR document, addressing The Bidder's attention to potential design issues.

7.3.5.8. Manufacture / Purchase / Development / Integration - Not a

formal Stage


1 Manufacture / Develop / Purchase of all the phases components (including interfaces)

The Bidder

2 Unit Test to each of the aforementioned System Components (IAA is entitled to review the deliverables upon its sole discretion)

Unit Test Summary document – Not a formal deliverable

The Bidder

3 Integration of all the System components (including interfaces)

The Bidder

4 Integration Test for the phase (IAA is entitled to review the deliverables upon its sole discretion)

Unit Test Summary document – Not a formal deliverable

The Bidder

5 FAT environment / site Preparation FAT site ready for use The Bidder

6 Training Courses Adaptation Training Materials The Bidder

7 Sanity Test for the Stage Sanity Test Summary document

The Bidder

8 Bidder’s approval to the Stage readiness for FAT

A Stage ready for FAT The Bidder

7.3.5.9. FAT - Not a formal Stage


1 FAT document preparation FAT document The Bidder

2 FAT document approval FAT document approval IAA

3 Basic training to IAA's FAT's witnessing group in case they attend the FAT

The Bidder

4 FAT for the version (including The Bidder





1 FAT document preparation FAT document The Bidder

2 FAT document approval FAT document approval IAA interfaces)

5 FAT Review FAT Results – Summary document The Bidder

6 IAA Approval of FAT Review Approval of FAT Review document

IAA

7 Formal version ready for shipping to IAA

The Bidder

7.3.5.10. Delivering the System Components to Israel, Installation,

Commissioning and Training

The Bidder shall define, in the same manner as the tables above, all activities such as: Installation, Commissioning, Training and deliverables, such as a progress report, updates of installation drawing based on actual installation ("As-Made" drawings), Local configuration (e.g. IP of network component, local MHS configuration etc.).

An important activity at this step is testing and approving IAA’s supplies according to the agreed method as stipulated in the approved SER.

It is mandatory to utilized and integrate some of the current equipment of the AMHS system with the AMHS for the transition period and the first period of system operation.

The Bidder shall advice about recommended data migration services and data population support within its basic proposal (Q).

This stage will be concluded with IAA’s approval to the IRR (Installation Readiness Review).

7.3.5.11. Setting Up the Temporary Communication Room

The Bidder shall define all activities for installing the main and backup system servers, Management Servers, communication network and Gateways to all the current systems international and domestic nodes, integrating with IAA LAN, in a Temporary Room assigned by IAA.

As part of the acceptance of the Temporary Communication Room, the Bidder shall perform, for each Stage, online and individual tests with all international and domestic nodes with full testing of each of the AMHS’ End Stations and other modules (at the Temporary Room or near to it without interrupting the operational system, either current AFTN operation when preparing for Basic-




AFTN Stage, or the AFTN System of Basic-AFTN Stage when preparing for AMHS Stage), in order to ensure proper and reliable operation of the Message Handling services, before commencing the SAT.

AMHS Stage also includes the replacement of the Basic-AFTN Stage Main and Backup Systems in the permanent Communication Rooms which were used for the current AFTN system. This shall be commenced after IAA approval for final termination of the current AFTN main System.

AMHS Stage also includes the final replacement of the AMHS Stage Main and Backup Systems in the permanent Communication Rooms which were used for the Basic-AFTN Stage AMHS System. This shall be commenced after IAA approval for commencing the Soak test for AMHS Stage.


1 Up-to-date Setting up the temporary Communication Room Plan document preparation

Plan for Setting Up the Communication Room Tests Plan and Procedures

The Bidder

2 Setting Up and Tests Documents approval

Approval of the aforementioned Plans

IAA

3 Setting the Communication Room and the Test Environment

The Bidder

4 Conducting the Tests The Bidder

5 Coordinating with all international and domestic nodes for individual testing

The Bidder


Approval of each international and domestic node's test

IAA

7 Temporary Communication Room Tests Review

Temporary Communication Room Tests Results – Summary document

The Bidder

8 IAA Approval of Temporary Communication Room Tests Review

Approval of Temporary Communication Room Tests Review document

IAA

9 Replacement the Main and Backup Systems at the permanent Communication Room

The Bidder

10 Conducting the Tests for permanent Communication

The Bidder





Rooms


Approval of the aforementioned Plans

IAA

12 Formal version ready for Overall Sections’ Installation

The Bidder

7.3.5.12. Sites (Partial) Acceptance

The Bidder shall define all activities for commissioning the Sites Partial Acceptance Tests on parts of the operational End Stations.

The Bidder must plan carefully this activity, with the coordination and approval of IAA, since it has a great influence on the business continuity of MHS services.

The Sites' Acceptance tests shall be plan according to the above constraints and only after complete acceptance of the AFTN International connections.

Each Site shall be able to return back to previous AFTN operation mode within minutes.

In AMHS Stage, the plan shall include failure scenarios and returning back (Fallback) to Basic-AFTN Stage version.

Once a partial Site acceptance is approved the Bidder shall commence the interim maintenance period according to the SLA (Chapter 8).

The following table depicts major activities for each Site acceptance.


1 Up-to-date Setting up the various sections Plan document preparation

Plan for Setting Up the Sections. Sites' Tests Plan and Procedures.

The Bidder


Approval of the aforementioned Plans.

IAA

3 Setting Up plan to Fall back in case of failure

Approved fall back plan and actions in failure scenarios

The Bidder

4 Setting the Sites The Bidder

5 Conducting the Tests The Bidder

6 Sites Tests Review Sections Tests Results – Summary document

The Bidder

7 IAA Approval of Sites Review Approval of Sites Tests Review document

IAA





8 Formal version ready for Overall System’s Final SAT

The Bidder

7.3.5.13. System's Final SAT

In Stage A, the final SAT shall confirm the new AMHS system can replace the old AMHS system without disturbing the System’s services. In Stage B it should include the IAA’s specific needs module(s) and all the Contract’s requirements that have not been tested yet.


1 SAT document preparation SAT document The Bidder

2 SAT document approval SAT document approval IAA

3 SAT Readiness Review Version Document Description (VDD) for the SAT.

The Bidder

SAT Readiness Review - Summary document

The Bidder

4 All Training Courses See section 0 for further details At IAA sole discretion some training shifts may be done after the SAT.

The Bidder

5 SAT for the formal System Version

The Bidder

6 SAT report preparation SAT report The Bidder

7 SAT Review SAT Results – Summary document. The Bidder

8 IAA Approval of SAT Results Approval of SAT Results document IAA

9 Formal Version ready for Soak Test The Bidder

7.3.5.14. Soak Test

1. During this stage, IAA will study and review both the System Performance and the Management Application(s) suitability to IAA needs.

(a) The Supplier's specialist shall accompany this stage at IAA facilities in Israel during the SOAK Period for at least two weeks with optional extension of two more weeks. During this period the Supplier's specialists shall perform All Maintenance procedures with the IAA relevant involved bodies.

(b) During this stage, status meeting shall be held twice a month at IAA facility in order to report and verify various relevant issues.

(c) IAA aims to cover a wide spectrum of the MHS services and scenarios. (d) At the end of this stage, based on the success of the soak period, the

system shall be announced ready for Operational Use.




(e) The Bidder shall prepare a Soak Readiness Review (SORR) checklist that will contain all pre-requisite tasks of both the Bidder and IAA responsibilities. The SORR Checklist shall be coordinated and approved by IAA.

(f) The SORR process shall follow the process described in section 7.3.4. (g) A document containing a list of anomalies / mal-functions and follow-up

on their repair shall be kept by the Bidder. IAA users or the Bidder will be able to open entries in this table. This document will be reviewed periodically (by meetings, conference call, and special visit by Bidder's engineers – all according to the severity of the issues being addressed).

(h) System adaptation issues shall be listed and fixed by the Bidder during the second half of the SOAK period. The timing of the System adaptation should enable IAA a sufficient time to evaluate it.

(i) Repairing anomalies / mal-functions that were found before or during the SOAK period should be corrected during that period and are a prime condition for a successful completion of the SOAK stage, and with it the completion of the AMHS Project.

(j) The Bidder shall pay attention to the activity in entry #6 in the table below. The Soak incorporates 3 one month periods. Hopefully, both parties will be able to execute it sequentially, however, if the fixes won’t suffice IAA and / or the System will not be available for a significant period and / or the services by the System will be unacceptable the Soak process will be halt and it will resume upon resolving the issues that caused the halt.

7.3.5.14.1. A Possible Procedure for Anomalies reporting by IAA and Anomalies

Resolution by the Awarded Bidder (Q)

The Bidder shall introduce its proposed method to handle anomalies during the Soak. The Bidder should note that IAA refers a very high importance to the Soak Period, since it was proved to minimize / bridge the gaps between the written requirement and the day to day needs to operate a the Message handling system in the Israel. (Q) The following procedure description is for expectations' coordination:

(a) IAA will use a spreadsheet to report about anomalies. (b) The spreadsheet shall be managed by the Awarded Bidder. (c) The spreadsheet shall have 2 basic portions:

i. One that shall be filled by IAA. ii. Another one that shall be filled by the Awarded Bidder.




(d) IAA's portion shall incorporate all kinds of information that shall provide the Awarded Bidder sufficient information to analyze the anomaly, to look into the system logs, to select a solution path, to implement the solution and to test its effectiveness in order that IAA will be able to close the anomaly.

(e) IAA's portion shall include information such as:

# Information Item Description 1. Anomaly ID Unique identifier to each anomaly. 2. Severity 1 – Does not prevent SOAK continuing.

2 – Urgent; may prevent SOAK continuing. 3. Anomaly Status Open or Closed 4. Date Reported by

IAA

5. Contact Person to discuss the anomaly

6. Anomaly Type Such as: International Communication Line, Interface …

7. Time UTC 8. AMHS System

Components Involved

Such as: Server, Splitter, …

9. Description of the anomaly

Free Text

10. Additional Information as needed

Such as referring to photograph and / or a document etc.

11. Possible Relevant Environmental Circumstances

Such as Power Outage, Air-conditioning Outage, IAA's Communication Network disruptions etc.

12. Others (Q) Upon the Bidder's discretion (f) The Awarded Bidder's portion shall include information such as:

# Information Item Description 1. The Awarded

Bidder Anomaly Label

According to its acquaintance with the system's internal components.

2. The Awarded Bidder Action Plan

For the various activities such as: data gathering, analyzing the data, formation of a conceptual solution …

3. The Awarded Bidder Requests from IAA

Such as: access to the Test or the Production System, special inputs from interfacing systems, etc.

4. Expected Next At that date IAA expects a status report about




# Information Item Description Update to the Action Plan

the anomaly.

5. Others (Q) Upon the Bidder's discretion.

(g) The Awarded Bidder's responsibilities are as follows: i. Review the daily reports submitted from the IAA. The Awarded

Bidder will group and evaluate the anomalies. ii. Will report to the IAA within 3-5 business days the next steps for

evaluation. This is to allow The Awarded Bidder to evaluate any emerging patterns of system performance. This communication will be performed via emails and conference calls as necessary.




7.3.5.14.2. Table of Relevant Activities, Deliverables and Responsibilities


1 Soak Readiness Review (SORR) checklist document preparation

Soak Readiness Review (SORR) checklist document

The Bidder

2 SORR document approval SORR document IAA

3 Trial run of the system Periodical system approval and/or punch list of problems

IAA

4 Status meeting in Israel with the Supplier’s specialists onsite

Status meeting – Summary document (including a list of those problems that must be fixed + schedule)

The Bidder & IAA

5 Fix problems Fixed problems report Open problems report

The Bidder

6 Reviewing the Fixed problems and open problems reports

Soak test continuity approval IAA

7 Soak Period completion meeting Completion meeting – Summary document

The Bidder

8 Completion of soak Period Completion of soak test approval - issuing a Final Acceptance Certificate

IAA

7.3.5.15. Go Live Period - System is ready for Operational Use


1 SLA period commencement The Bidder

7.3.6. Project Plan

7.3.6.1. Principles and Guidelines

1. The Project work plan shall refer to IAA's requirements as stipulated in clauses 7.3.2 and in clause 7.3.5 מעל.

2. The project work plan shall include all the stages / sub-stages of the project as mentioned in clause 7.3.2. The plan shall be built in such a way that clarifies for each milestone the activities that are prerequisites to the full completion thereof.(Q)

3. The project work plan shall include all the formal reviews of the project and also the reviews that will be defined during the project, as mentioned in the Proposal.




7.3.6.2. Work Plan for Setting up the Complete System

1. Within the Bidder’s integrated project plan, the Bidder shall provide the following:

a. A project plan detailing the tasks, sub-tasks, dependencies, resources and timeframes, deliverables, etc. for each stage.

b. The Bidder shall explicitly specify all the tasks that are within IAA’s “court” for each activity, as well as the timeframe it allocated to each of IAA’s tasks.

c. For avoidance of a doubt, IAA states that the Bidder would not assume that IAA would supply any equipment for the project’s purposes, other than those that are explicitly declared in the tender documents.

2. The Bidder shall gather all the above-mentioned IAA’s tasks into one Appendix - "IAA's Activity/Tasks" that shall be submitted as part of the Proposal. This appendix shall contain a complete list of all IAA's tasks

a. This Appendix shall be valid only after a written approval by IAA. IAA's approval shall be an integral part of the Technical Specification approval as stipulated in Section 6.5 of the Contract.

b. This Appendix shall be the sole source for any of IAA's tasks within the Project. Any task and /or activity and /or work and / or service and / or a Component etc., that are not mentioned in this Appendix, and are required for the successful completion of the Project, shall be deemed as The Selected Supplier's obligation whatsoever.

c. For each task, the Bidder shall elaborate as follows:

# The Task

Reference within the Bid

Relevant Stage of the Project

Due date for delivery

Reference to a sample (if applicable)

1

2

..

d. For avoidance of a doubt, IAA declares, that a task within the

Bid that is associated with IAA but is not included in this appendix, shall not oblige the IAA.




e. Each of IAA’s tasks will be inspected by the Selected Bidder and will be approved / commented in writing. The inspection / approval shall be done prior to the installation of the relevant Systems’ components.

f. The number of tasks and their impact on IAA's obligations shall have significant impact on the technical evaluation of the Bidder's response. (Q)

3. A Gantt chart of the project shall be submitted along with the Bidder’s Proposal, as an MS-Project file and in Excel file. IAA encourages the Bidder to use its own templates for the Gantt Charts. IAA described the Project Major Stages through the timeline / phases of the Project; however the Bidder may use its standard template with the required adaptations. (Q) Following is an example for illustration purposes solely:

a. AMHS Gantt (Partial Sample): Level 1 and 2

b. ATS Gantt / Tests (Partial Sample): Level 3




c. AMHS Gantt / Installation (Partial Sample): Level 3

4. Any delay in the execution of any activity or milestone shall be announced in writing to IAA.

5. The re-scheduling of a delayed activity/milestone shall be approved by IAA; otherwise the original schedule of the activity/milestone shall remain valid.

6. Every new revision of the plan approved by IAA shall be set as a new baseline for tracking and reporting purposes. The Bidder shall keep the history of all the baseline plans and not override them.

7.3.6.3. Work Plan for implementing Option 1 – DRP – Third Leg

The Bidder shall follow the instructions as in clause 7.3.6.2

7.3.7. Tests

1. The Bidder shall introduce its proposed test methodology, test plan, test activities and deliverables throughout the whole lifecycle of the Project including the EUR AMHS Manual Appendix Tests as in the table of clause 5.2.1. (Q).

2. The Test Program shall refer to IAA's requirement below (P).




7.3.7.1. General

1. The test program stands to prove that the AMHS system delivered by the Bidder is fully compliant with the Bidder’s proposal and IAA Requirements.

2. Tests shall refer to:

b. Temporary / Final Communication Room (Successful Communication Room Acceptance).

c. Sites' (partial) Acceptance.

d. Overall System Acceptance (Successful SAT).

e. Overall Service Acceptance (SOAK Completion).

3. The Subsystems / Components Acceptance and the overall System Acceptance tests are the sole responsibility of the Selected Bidder's.

4. The final system acceptance shall be based upon the successful execution of functionality and performance tests. If the System fails to meet (for example) the expected performance, it shall be the Bidder's obligation to correct and/or to add components and/or to enhance the configuration etc. to meet the required functionality and performance.

5. The Overall Service Acceptance / the Soak Test would be led by IAA; however the Selected Bidder shall accompany this phase.

6. Regarding the Overall System Acceptance, some parameters, particularly those concerning system reliability, availability, and continuity of service, shall need to be tested over an extended period of time. This may impose constraints on the initial operational use of the system until adequate statistical evidence has been obtained to provide the necessary degree of confidence.

7. Subsystems / Components Acceptance tests shall include (for both stages where applicable):

f. MHS

g. IAA Specific Requirements

h. Other, upon the Bidder's discretion.

8. System Acceptance tests shall include:

a. MHS / Capabilities.

b. Working position HMI and functions for each of the system roles

c. Management and Monitoring functionality (including maintenance procedures, reports, logs, information security etc.)

d. System operation modes (redundant, non-redundant, test)

e. Servers and applications redundancy




f. Network redundancy

g. Interfaces (e.g. resilience, data integrity etc.)

h. System general tests (e.g. capacity, dependency, performance etc.)

7.3.7.2. Verification Requirements Table Matrix

1. The purpose of the Verification Requirements Table Matrix ("VRTM") is to define for each RRD requirement its validation (testing / proving) method, and the relevant phase(s) in the Program in which it is going to be conducted. Composing a VRTM is part of the Program CDR.

2. The Bidder shall submit for IAA's approval a final VRTM well before the beginning of the Acceptance tests, and before submission of the Test Plan documents.

3. Each and every requirement in the RRD document should occupy a line in the VRTM table with complete data to enable IAA to review it. In the reviewing process IAA should be able to easily trace for each requirement when it is going to be tested and the exact testing procedure / step designed to prove it. (In case the VRTM is submitted before final test plan documents are completed, IAA will verify the general validation method, and only later the actual test procedures when submitted to IAA).

4. The following are considered to be the most important fields for the above-mentioned tractability approval:

Requirement ID

Validation Method

Project stage (e.g. SAT, Sub-SAT, etc.)

Procedure document name

Section Test Case Name / step

testing, inspection, demonstration, analysis, etc.

These 3 fields are the ID of the testing procedure / step

The combination <Procedure document name, Section, Test Case Name/step> defines the exact procedure/step(s) designed to prove the specific requirement.

5. Verification Method is how the requirement is going to be tested / proved / demonstrated. To mention a few:

a. Product Qualification Tests

b. Test during FAT, Sub-SAT, SAT, SOAK

c. Laboratories tests

d. Compliance certificates with standards (such as FCC for example)




e. Winning Bidder's declaration (to be minimized)

f. Written statement by a 3rd party vendor

g. Inspection / demonstration during training

h. Mathematical / Theoretical analysis

i. Real Field Measurements

j. Other

6. It should be noted that IAA has to approve the System Requirements Validation as proposed by the Bidder. This may be done in two stages: First IAA reviews and approves the VRTM: that all the RRD requirements are addressed (completeness), the method of verification (i.e. testing, inspection, demonstration, analysis, etc.) and at what stage(s) of the project this validation shall be done. The second stage is to review and approve the actual Test Plan documents which inter alia detail the exact test procedures or other validation procedures.

7. Following is a “Block Diagram” illustrating an Overview of the VRTM:

7.3.7.3. IAA Expectation from a FAT / SAT / Sub SAT document

1. The Bidder shall provide IAA with a FAT / SAT document that shall cover, at least, the following subjects (the following requirements intend




to enlarge the requirements in other Chapters, such as Chapter 5 rather than narrowing them):

a. Test Environment: Hardware, Software, Other Test Equipment, Pre AT (Acceptance Tests) conditions, Test data and data generation tools, participants, Precautions, etc.

b. Safety Precautions

c. Test Forms: That shall incorporate, inter-alia the test procedures, the steps in them, the expected results for each procedure / step.

d. Test Work Plan: Formatted Acceptance Test (AT) Documents which shall specify at least the following:

i. What is going to be tested, when and under which conditions?

ii. Who will participate in each test

iii. Timetable for results submission, presenting and discussing the results with IAA, result approval by IAA, correcting issues by the supplier.

iv. Retesting and Regression’s tests.

7.3.7.4. Factory Acceptance Test (FAT)

1. The purpose of the FAT is to demonstrate that all items of the intended AMHS are correctly manufactured, or developed, and meet their individual requirements.

2. The required FAT shall be performed and documented before shipment to site.

3. The Bidder shall present to IAA in the FAT Test Plan document the intended test, and define for each of the tests:

a. Test purpose – description of the system feature or requirement to be tested.

b. Test Equipment –

i. Description of any test equipment and conditions needed to perform the test.

ii. If proprietary test equipment is used, IAA would like The Bidder to introduce it to IAA in order that IAA will gain confidence in this test tool.

iii. For non-proprietary test equipment, IAA would like the Bidder to attach the laboratory certificates that verify that




the test equipment is valid at the time of conducting the test.

c. Test Procedure - description of test method, including analysis of test data.

4. IAA reserves the right to attend and witness the FAT execution.

5. Should problems materialize during the FAT or should the FAT results be deemed unsatisfactory in any way by IAA, the problems shall be corrected after (not during) the test and the status shall be solely defined by IAA.

6. The System Supplier shall take full economic responsibility for any required retesting program. If during the test, additional tests become necessary, IAA has the right to request their execution.

7.3.7.5. Site Acceptance Test (SAT)

1. The SAT shall prove that all System/Subsystem requirements at their site specific installation and location are met.

2. The Bidder shall prepare a SAT Readiness Review (SARR) checklist containing all SAT pre-requisite tasks with clearly defined division of roles between the Bidder and IAA. The SARR Checklist shall be coordinated and approved by IAA.

3. The SARR Review process shall follow the process described in section 7.3.4.

4. The SAT shall be carried out in IAA's facilities in accordance with SAT Specification.

5. The SAT shall make use of both simulations and real data recordings as input, if so required.

6. The Bidder shall provide IAA with the SAT documentation for approval prior to SAT execution.

7. IAA representative(s) shall witness the SAT.

8. As the SAT shall include a number of live trials, IAA is prepared to provide for the environment for such trials and operational/technical staff to perform specified actions.

9. Before starting the SAT, all non-conformances and reservations recorded in the FAT report shall be removed.

10. The SAT schedule shall be specified in the project work plan.

11. The Bidder shall provide the SAT report as scheduled in the project work plan.




12. Results of each single test shall be mutually verified; however the PASS / FAIL evaluation shall be approved solely by IAA.

13. Should problems materialize during the SAT or should the SAT results be deemed unsatisfactory in any major way by IAA, the problems shall be corrected after (not during) the test and the status shall be solely defined by IAA.

14. The Bidder shall take full economic responsibility for any required retesting programs. If during the test, additional tests become necessary, IAA has the right to request their execution.

7.3.7.6. SAT Closure

1. The Supplier shall fill for all failed test and / or for each anomaly occurred and/or for each known bug / deficiency at SAT commencement the table below:

2. The Correction Path Table:

# VRTM Identifier

Problem / Issue Description

Reason / Theory

Proposed Corrective Action

Estimated Contribution to SAT Results

Verification Method

Verification Due Date

Reference to the Test Case

Correction Plan Activities

Comments

3. A Waiver / Deviation Request shall incorporate the following information as a minimum:

Req. # Contract

Paragraph Requirement Event

Procedure Document

Test Case Name

Product Test Report

7.3.7.7. System Overall Acceptance Tests, Minimal Scope - Highlights

1. The following list of tests elaborates on some requested tests mentioned at 7.3.7.1, and shall enlarge the Selected Bidder's test obligations rather than reduce them.

2. The following test types and areas shall be included in the SAT plan proposed by the Bidder.




7.3.7.7.1. General Tests

1. Start-up Time

2. Switch Over Time

3. Maximum Working Positions capacity

4. Response time in various system tasks

5. Administration capabilities

6. Archive and data backup

7. Processing Delay

8. Stress Tests - including high loading, failure scenarios, wrong inputs, non-valid values for system configurable items, etc.

7.3.7.7.2. Human – Machine Interface Tests

1. Special attention shall be made to testing HMI features that are not part of the generic product, and were developed/ configured / adopted per IAA's requirements.

7.3.7.7.2.1. General

1. HMI parameters & performance.

2. Multiple working position tests (e.g. various authorizations, etc.).

3. WP functionality.

4. Operational Data Management WP functionality.

5. …

7.3.7.7.2.2. Maintenance working management positions

1. Please refer to the Chapter 6

2. System components status and maintenance info display and reports

3. System performance degradation alerts and information display

4. System’s components configuration and management tools

5. System’s Events and Audible alerts management

6. Users and roles management

7.3.7.7.3. Interfaces to Existing Airport Systems Tests

1. Per the requirements in Chapter 5.

7.3.7.7.4. System Availability Tests

1. Server redundancy tests




2. Network redundancy tests

3. Power failure and cold start-up

4. Work positions failure

5. The Bidder is encouraged to detail about other tests based on the proposed architecture

7.3.8. Training

7.3.8.1. General

1. Training shall accompany, as an integral part of the project plan, each product, module, sub-system or system that shall be delivered to the IAA.

2. All training shall be performed either at IAA Premises in Israel or at the Bidder's premises, according to IAA sole discretion.

3. All the required courses shall be of the "Train the Trainer" type.

4. Practical training shall take place in class rooms which shall be equipped with operational AMHS / AFTN end stations.

5. The Bidder shall describe whether the class room will be part of the operational AMHS / AFTN system or a Standalone system with the same capabilities for the training.

6. Both configurations shall not affect the operational system and disrupt its performance and availability.

7. All training shall include a theoretical and a practical part.

8. The practical part shall include a real life system for the operational use.

9. The Bidder shall conduct a competency based training program to IAA's Operational staff in accordance with the Project Plan at schedule. (Q)

10. The Bidder's trainers shall have formal training qualification and appropriate experience.

11. The Bidder shall issue a certificate of competency to each trainee that successfully completes the training program.

12. The training shall include both training for the Basic-AFTN Stage and AMHS stage.

7.3.8.2. Training Material

1. The Bidder shall provide course materials (manuals, drawings, presentations, handouts, etc.) for each of the trainees. These materials shall cover all aspects of the IAA system.

2. In addition, all training materials shall be supplied to IAA in soft copies (CD).




7.3.8.3. Type of Courses

1. There are three categories of training courses:

a. End Users training: System Operational use for all the MHS / users.

b. System Operational Managers training: That should incorporate the operational management capabilities.

c. System Technical Managers training: That should incorporate the technical management capabilities.

2. The Supplier shall obligate to be able to provide certification / training course for the system during the life time of the system. (Q)

3. The AMHS Supplier shall provide the following training courses:

# Course Name # Participants

# of Cycles

Type of Course

Location

1. End Users 6 - 10 1 Train the Trainer

Israel / Bidder's Location

2. Operational Administrators

6 - 10 1 Train the Trainer


3. System Technical Management

6 - 10 1 Train the Trainer


7.3.8.4. Expected Response

1. For each training course included in the Proposal, the following details shall be included: (Q)

a. Course name.

b. Course syllabus

c. Course teacher name, profession and experience.

d. Course prerequisite.

e. Course objectives, including the skills to be taught as well as how the course participants will be examined on all aspects covered.

f. Course level, prerequisites and intended audience.

g. Course duration and schedule, including detailed timetable for each day.

h. Course materials to be handed out to each one of the participants.




i. Recommended / maximum number of participants (included in the Proposal).

7.3.9. Documentation

7.3.9.1. Details of documentation

1. The Bidder is required to provide the necessary documentation for the safe operation of The AMHS / AFTN.

2. The Bidder shall undertake to revise the documentation with every upgrade of The AMHS / AFTN and/or peripheral hardware.

3. The documentation shall be tracked with version control mechanism.

4. The documentation shall be open to inspection by the IAA at any time.

7.3.9.2. Specific requirements

1. Configuration documentation of the AMHS / AFTN system.

2. Operational manuals

3. Bill of quantities

4. Site operating procedures, including change management, homologation processes

5. Health and safety policy manuals

6. Operating and maintenance manuals

7. Service Level Agreement (SLA) & Service Delivery Plan (SDP)

8. ICD for data and / or services exchange with external information systems.

7.3.9.3. End User Manuals

1. Complete guides to the safe use of the AMHS / AFTN system end devices and peripherals for End-Users

2. Quick Reference Guides

3. Abbreviated version of the manuals for End-Users to include troubleshooting of peripherals

4. The Bidder shall list all other documentation, which will be provided as part of The Service.

7.3.9.4. Quantities

Note: The documentation shall be provided in the English Language. Manuals marked (b) & (c) shall be provided in quantities of 1000 (one thousand) copies.




A soft copy either on CD-ROM or another removable device shall also be provided to allow IAA to make additional copies for End-Users.

7.3.9.5. Documentation List – Concentrated

1. The following table incorporates all requested documents as appear through the Tender Documents. The list is introduced solely for tracking convenience of all the involved parties.

2. The Documentation List:

Requirements Documents

System Application Documents

Test Documents

Project Management Documents

Operations and Maintenance Documents

Revised Requirement Definition (RRD)

System Architecture

Conceptual Test Plan

Program Management Plan

Operational User’s Manuals

Verification Requirements Table Matrix (VRTM)

Site Engineering Report

FAT Procedure and Plan

QA Plan and other documents

Technicians User’s Manual

System Interfaces Specifications

Installation Plan FAT Report Risk Management Plan and other documents

Version Description Document

HMI Specifications

Inspection of the Installed Base

Sub-SAT Procedures and Plan

Monthly reports

Interface Control Document(s) [ICD(s)] to the AMHS / AFTN sub-systems

Sub-SAT Report

Steering Committee Agenda and Report

Reviews Agenda and Report

7.3.9.6. Other Documentation

1. The Bidder shall list all other documentation, which will be provided as part of the System. (Q)

7.3.9.7. Documentation Format (P)

1. The Project's documents will be produced with MS Office (2010 version of higher) tools (such as: MS Word, MS Excel, PowerPoint, Visio, etc.).

2. The Bidder shall submit PDF copies in addition to the Office documents, if IAA asks for it.




3. All diagrams will be submitted in Visio or in AutoCAD format, or both, as set by the IAA.

4. Gantt charts shall be submitted in all the following formats: MS Project, MS Excel and PDF.

7.3.10. Involvement of the Bidder in the CFE activities

1. Following is a description regarding the Involvement of the Bidder in Accompanying, Guiding and Controlling of other IAA's Contractors / Interfacing Systems' contact persons

2. The Bidder shall support the IAA Infrastructure (as defined in Section 1.1 of the Contract) setup executed either by IAA and / or by other IAA contractors, as follows:

# Stage Description of involvement

a. Requirements definition

Provide the requirements definition document to the design and/or executing entity in the station.

Work meetings for clarification of the requirements definition (one or two meetings).

b. Assistance in design

Telephone response to questions. Work meetings.

c. Reviewing the detailed plan

Reviewing the detailed plan. Passing the comments document. A work meeting aimed at clarification of comments Reviewing the amended version of the detailed plan.

d. Purchasing, execution, installations

Telephone response to questions. One or two on-site visits at the start of and during the

works.

e. Acceptance tests Full involvement in the tests.

f. Approval of the infrastructures

Full and final approval of the infrastructures, verifying full compliance and adequacy for the intended AMHS System.

7.3.11. Installation Requirements

1. The Bidder shall describe in details his compliance with the requirements in Sections 7.3.11.1, 7.3.11.2, 7.3.11.3 below. (Q)

7.3.11.1. General Characteristics of the required services

1. Variability Among Deployment Sites a. In planning, execution and installation of all the relevant equipment

and supporting infrastructure (hereinafter the Element), the Bidder




shall take into account possible variations between the different positioning sites, including such constraints as: positioning space constraints, sources of electricity and data feed, temperatures and ventilation, induction, service access, requirements dictated by other equipment installed in the area, textures and structures of ceilings / walls / other supporting infrastructures, method of mounting (wall mount, ceiling mount, station mount etc.), maximal accessibility for service personnel, minimal disturbance to traffic in proximity of the Element, prevention of direct lighting and other reflections and so forth.

b. For avoidance of any doubt, it is clarified hereby that no extra payments whatsoever shall be paid to the selected Bidder due to the aforementioned variability among deployment sites.

2. Planning and Construction Law The Bidder must operate according to the Planning and Construction Law, Israeli Standard 5435 and other official regulations.

3. Safety The Bidder shall be aware of the existing hazards during the execution of works on the airside and in the proximity of airplanes and other vehicles and operate according to IAA's safety regulations.

4. Sub-Project a. Each physical site in which the services and the goods specified in

the Technical Appendixes shall be required – shall be characterized as a separate sub-project, including: capacity of work, time schedules etc.

b. The Bidder shall adjust to the required nature of work in IAA and supply optimal response to such needs as:

i. Simultaneous execution of a number of sub-projects.

ii. Significantly reduced time-to-operation from raising a need to a fully operational Element.

iii. Compliance with the actual target schedules as required in the Project.

iv. Around the clock work and/or working during hours in which the airport does not provide customer services and according to safety regulations.

5. Sub-Constructions a. The Bidder shall offer sub-constructions for each display, pricing of

the sub-constructions shall include all required components as well as the works entailed in the required planning, manufacturing, installation, inspection, and so forth.




b. The Bidder shall offer a single price for all variants of the sub-constructions of a specific display device. That is, a single price for each sub-construction for a display device, whether it includes a wall mount, ceiling mount or installation within furniture and so forth.

c. The price shall take into account all the requirements specified in the Technical Appendixes. If any preparations will be required either in the building or the Users’ console for the installation of the mounting brackets and the relevant display device, it will be done by IAA as CFE. The Bidder shall specify it in the IAA CFE table.

6. Execution Schedule a. The Bidder shall work during hours that do not collide / conflict

with services for customers and/or movement of airplanes and/or other works.

b. If the need arises, IAA at its sole, absolute discretion may order the Bidder to work on Saturdays, Sundays, holidays, etc. (excluding Day of Atonement).If there is a specific day on which the Bidder team cannot work, it shall inform IAA in writing at least two months ahead of that day.

7.3.11.2. Installation responsibilities

1. The Bidder shall carry out the installation of the Element in accordance with its procedures as submitted to IAA for review.

2. The Bidder shall submit drawings to IAA for approval of any temporary works, major equipment, etc. that it requires on site in the execution of the Contract's Services.

3. During the installation, the Bidder shall coordinate its works with other Subcontractors working in the same and adjoining areas, so as to ensure that no delays are caused to work of others.

4. The Supplier shall review with IAA the installation sequence schedule prior to starting the installation.

5. All mounting elements/brackets, either mounted on the wall or hanged from the ceiling, shall be produced at a workshop prior to delivery to the site.

6. The mounting method to any building's element shall be approved, in advance, by the building's constructor.

7. The selected Bidder shall verify the leveling of all elements in the horizontal plan and in the vertical plan.

8. Upon completion of each task, the delivered equipment and working areas shall be clean and in a working state and/or ready for immediate use.

9. The delivered equipment shall be protected against any damage until entering into operation.

10. Throughout the installation period, the Bidder shall ensure that an appropriate number of full time site supervisors are present at the site to ensure proper installation of the System.




11. The installation work shall be executed in cooperation with the IAA. 12. All works shall be installed strictly in accordance with approved

drawings, specifications and procedures. 13. The Bidder shall provide and install all necessary equipment in connection

with the Element in order to ensure the correct and proper functionality. This includes cabling, cable trays, supports, mountings, interface equipment with networks or other systems, etc.

14. These associated deliveries or works shall be included in the Contract, unless explicitly stated otherwise.

15. The Bidder shall inform IAA about the power consumption of all hardware parts to be installed in order to allow IAA to provide either standard mains voltage or guaranteed power using on-line UPSs.

16. The System Supplier shall be responsible for the ICD specification and integration.

7.3.11.3. Installation Priorities and Considerations

1. The System Supplier, in cooperation with IAA and IAA’s designated authorized representatives, shall investigate in detail and define solutions on operational, functional or technical problems that may arise due to the installation and operation of the equipment.

2. Whenever it is possible, the Bidder shall involve IAA personnel in installation and preparation works.




7.4. Project Lifecycle – Reference Managerial Process

7.4.1. Introduction

1. This Section specifies the control and reporting tools and also additional rules that shall serve as a basis for the management concepts to be implemented throughout the execution of the project.

2. The Bidder may attach its own procedures for the Managerial Process. (Q)

7.4.2. Managerial Process Objectives

1. The management of the project shall be based upon the following managerial elements:

2. Forums

a. Steering Committee

b. Project Directorate (PD)

c. Technical Board

3. Processes

a. Project Management reviews (PMR)

b. Quality Reviews

c. Formal Reports

d. Risk Management

e. Quality Management

f. Test Management

4. The Bidder shall present in details his proposed managerial process, which will be effective in bringing the AMHS Project to completion, successfully, on time and on budget. (Q)

7.4.3. Forums & Meetings

7.4.3.1. General

1. After each meeting / forum the Bidder’s AMHS Project Manager shall be responsible to deliver the minutes, including any relevant written materials, in an official document that shall become formal once it is approved by IAA.

2. It is preferable that a meeting minutes draft is prepared during the meeting by the Bidder's leader of the meeting, and is reviewed and agreed between both parties during, or at the end of the meeting. The draft shall include




the issues that were discussed, agreements, resolutions, action items, risk and mitigation thereof.

7.4.3.2. Steering Committee

1. The steering committee is a decision making forum who:

a. Receives and approves a consolidated status report prepared by the project management team

b. Outlines strategic directions

c. Resolves high-priority and escalated issues

d. Directs and prioritizes activities at the operational and tactical levels

2. The steering committee is a joint IAA and Bidder’s Executive Level Forum that is authorized to make decisions as described above. The committee shall be convened and chaired by IAA’s Executive or anyone on his behalf, and shall consists of:

a. IAA's management representatives and relevant stakeholders

b. Bidder’s Executive Manager

c. IAA’s Project Manager

d. Bidder’s Project Manager

e. Bidder’s Senior Technical Manager

3. The participation in the Steering Committee is mandatory. Any waiver shall be coordinated and given with the prior consent of the Chairperson up to 5 days before the planned date of the Steering Committee. The Bidder’s executive manager shall be responsible to nominate an appropriate replacement and advise the Steering Committee forum in case of absence.

4. It shall be the Bidder’s AMHS Project Manager’s responsibility to prepare an agenda and presentation documents (Microsoft Office format) prior to the Steering Committee in coordination with the IAA’s Project Manager, and distribute these files not later than 48-72 hours prior to the meeting.

5. Additional participants can be invited to the Steering Committee with the prior consent of the chairperson.

6. The committee shall convene every 3 months in Israel or earlier upon a specific need - on a schedule agreed with the Selected Bidder.

7.4.3.2.1. Minutes of the Steering Committee Meetings

1. The minutes of meeting shall be prepared by the Bidder's Project Manager and approved by the IAA’s Project Manager prior to their distribution.

2. The Bidder's Project Manager shall prepare and publish after IAA approval, up to 5 days after each meeting, a Word document titled "AMHS Steering Committee – Meeting Minutes <date>".




3. The Minutes of Meeting shall include the following items: a. Meeting Owner b. Invitees c. Participants d. Unattended Invitees e. Agenda – a predefined agenda shall be concluded between the

Bidder's Project Manager and the IAA’s Project Manager upon the project line-up period

f. Meeting Decisions g. Action Items - including the responsible person and the due date

for each item. These action items shall be tracked until closure and reported on the subsequent Steering Committee.

h. Attachments – including the meeting status review report and any other relevant materials.

7.4.3.3. Project Directorate (PD)

1. The mission of the PD is to enable effective coordination between all the involved parties in the project both from IAA and among the Bidder's team and subcontractors and also to enable control over the progress of the project.

2. The PD forum shall include: a. Chairperson – the Bidder’s AMHS Project Manager b. Bidder’s participants - Bidder’s AMHS Senior Technical

Manager and any other relevant team member(s) determined by the AMHS Project Manager.

c. IAA’s participants - IAA’s Project Manager and additional representatives on behalf of IAA determined by IAA’s IAA Telecommunication Manager and Project Manager.

3. It will be possible, in coordination with IAA’s Project Manager, subject to suitable security clearance, to invite additional participants to meetings of the directorate.

4. The PD shall convene regularly on a weekly or a bi-weekly basis by conference call, and every 6 weeks by a meeting at IAA. The responsibility for the invitation of the PD is of the Bidder's AMHS Project Manager.

7.4.3.3.1. Minutes of the Project Directorate Meetings and / or Conference Calls

1. The minutes of the PD Meetings shall be prepared by the Bidder's AMHS Project Manager and approved by the IAA’s Project Manager prior to distribution.

2. The Bidder’s AMHS Project Manager shall prepare a detailed report with the main management and technical subjects of the project, and submit it to the PD 48-72 hours prior to the meeting, so the forum can review it before the meeting.




3. Immediately after each meeting, the Bidder's AMHS Project Manager shall prepare and publish, a Word document titled "AMHS Project Directorate – Meeting Minutes <date>".

4. Each summary of the meetings shall include at least the following subjects:

a. Major comments made by the IAA’s Project manager b. Major comments made by the Bidder’s Project Manager c. Meeting Decisions d. Work Plan Highlights for the near future e. Main risks and concluded mitigation plan f. New tasks or Action Items (including the responsible person and

due date for each item)

7.4.3.4. Technical Board

1. The technical board goal is to discuss and address imminent technical issues, and escalate to the Project Directorate any unresolved issues.

2. A technical board shall be founded for the project to include: a. Chairperson – Bidder’s Senior Technical Manager b. Bidder’s Participants – relevant team members determined by the

Bidder’s Senior Technical Manager. c. IAA’s participants - relevant technical experts determined by

IAA’s IAA Telecommunication Manager and Project Manager. d. Optional participants - IAA’s Project Manager, Bidder’s AMHS

Project Manager 3. Additional participants may be invited to the technical board meetings in

coordination and with the prior consent of the IAA’s Project Manager. 4. The technical board shall convene every 6 weeks in a meeting at IAA, and

by conference call on a weekly basis or as necessary. The technical forum shall be scheduled prior to the weekly PD forum meeting.

5. The initiative for a technical board meeting can be triggered by both IAA and the Bidder, including the IAA’s Project Manager, and the Bidder’s AMHS Project Manager or Senior Technical Manager. The responsibility for the invitation of the forum shall be that of the Bidder’s Senior Technical Manager.

7.4.3.4.1. Minutes of the Project's Technical Board Meetings

1. The minutes of these meetings shall be prepared by the Bidder’s Senior Technical Manager and approved by the IAA Technical Manager prior to their distribution.

2. The Bidder's Senior Technical Manager shall prepare and publish, immediately after each meeting, a Word document titled "AMHS Technical Board – Meeting Minutes <date>".

3. A summary of the meeting shall include at least the following subjects: a. Previous meeting’s Action Items status




b. Made Decisions c. List of newly opened issues and their status d. Issue Highlights of the Work Plan for the near future e. Identified risks and concluded mitigation plan f. New tasks or Action Items (including responsible person and due

date for each item)

7.4.4. Reports

7.4.4.1. General

1. The Bidder is welcome to propose and introduce its reports that have been successful in past projects. (Q)

7.4.4.2. Monthly Progress Report of the Project

1. By no later than the 5th of each month, the Bidder’s AMHS Project Manager shall prepare and publish, with reference to the previous month, a Word document titled: "AMHS Monthly Progress Report <- mmm-yyyy>" and submit it for review and approval of the IAA’s Project Manager.

2. The report shall include at least the following clauses: a. Executive Summary containing the status of the project in general, a

concise report in view of the progress time axis of the project, a report on the main events during the previous month and details of the main issues that require attention.

b. References to the main up-to-date Managerial Documents of the project, with emphasis on an up-to-date Project Plan (Gantt), with clear marking of any change from previous version, or deviation of actual vs. plan, Customer (IAA) tasks, action Items status

c. Project risks and their mitigation plan, with emphasis on newly observed risks.

d. Details of the main activities for the next month.

e. Staffing status, including but not limited to changes made and planned.

f. Procurement status of third party products.

g. Development status in view of subjects and components.

h. Status of formal deliverables.

i. Outstanding issues and recommended action plan.




7.4.4.3. Steering Committee Status Report

1. The Bidder’s AMHS Project Manager shall be responsible to prepare in coordination and approval of the IAA’s Project Manager a Word document titled: "AMHS Steering Committee status report”.

2. The Bidder’s AMHS Project Manager shall distribute the report no later than 48-72 hours before the scheduled steering committee meeting.

3. The report shall include at least the following topics: (Q) a. Goals (from previous meeting) status b. Major and/or significant achievements accomplished during the

reporting period c. Major Milestones Status – Actual vs. Plan d. Action Items Status (from previous Steering Committee) e. Outstanding Risks along with suggested Mitigation Plan to be

approved f. Outstanding Open Issues along with suggested decision to be

made g. Production Readiness Status – Actual vs. Plan (when it becomes

relevant) h. Main Change Request Status i. Next Steps and/or Goals for the next period

7.4.5. Deliverable Management

7.4.5.1. General

1. The components / items that will be delivered within the project are defined in Chapter 9 - BOQ to this technical appendix.

7.4.5.2. Method of Management

1. The various documents to be prepared within the project (including those for analysis, design, testing, documentation, status reports etc.) shall be written according to the standards defined in the Proposal. In special cases when required, the Bidder can request to write a certain document according to another standard that shall be presented to IAA for approval.

2. The table of contents and the template of each document included in the list of the products of the project shall be presented to IAA, to the extent possible, prior to the start of the work upon it and no later than 10 working days before the time of its submission.

3. Submission of any formal document, including status reports, formal products, formal addressing etc., shall be considered as having been carried out if and only if this document was delivered in one, or more




"hard copy" (paper) and "soft copy" (CD) to IAA as agreed, and the IAA’s Project Manager has confirmed their receipt.

7.4.6. Quality Assurance

1. The Bidder shall describe in its response how it complies with the requirements in this section and in Annex 1-E(Q)

7.4.6.1. General

1. Throughout the project, the Bidder shall take all measures in order to assure that the supplied system and all the other products, including documents, conform to the requirements detailed in the agreement and are of high quality, according to the standards detailed in the documents of the agreement.

2. The Bidder shall implement a "quality assurance program" within the project framework according to industry standards and the Bidder’s own QA procedures and everywhere required as customary in the relevant field internationally and based on "best practice" principles.

7.4.6.2. Organization and Responsibility

1. The Supplier shall assume sole responsibility for all issues of quality assurance in the project, including implementation of the quality assurance program of the project.

2. The Supplier shall appoint a quality assurance manager who shall be responsible for the quality assurance processes that shall be applied in the project.

3. In addition, one member of the project team shall be nominated as a quality assurance monitor and shall serve as the quality assurance manager representative in the project team.

7.4.6.3. Quality Assurance Plan

1. The Bidder shall prepare a quality assurance plan for the project, which shall function as a tool for tracking and controlling quality assurance activities that shall be carried out throughout the project.

2. The supplier shall make its best effort so that the quality assurance plan shall include and address at least the following subjects:

a. Definition of quality assurance assignments and outputs in each phase of the project's lifecycle.

b. Definition of the procedures and the standards by which the system shall be developed.




c. Definition of the quality metrics (technical and managerial) that shall allow for tracking the quality of the product and the progress of the project.

d. Definition of the way in which data shall be collected as regards to the quality metrics that were defined.

e. Definition of contents and times to perform the project's internal quality audits.

f. Follow-up of essential issues such as: risk management and the test plan.

7.4.6.4. Quality Audits

1. During the project, the supplier shall execute internal quality audits in order to assure conformance to the quality requirements and plan.

2. At least one internal quality audit shall be made before each formal milestone. The quality audits shall be indicated in the Gantt chart.

3. Following each quality audit, a report that summarizes the audit shall be published.

7.4.7. Risk Management

1. The Bidder shall describe in its response how it complies with the requirements in this section (Q)

7.4.7.1. General

1. "Risk management" is intended to help in locating weak links, risk factors and potential failures that may cause significant delays in schedules, cost overruns and the contents downgrade of the project.

2. Throughout the project, a "Risk management" process shall be realized under the full responsibility of the Bidder and according to the specifications, meanings and contents detailed in this chapter.

3. Risk management shall include at least activities of: identification, assessment, mitigation plan and performance tracking and repeat measurement.

4. The Bidder’s AMHS Project Manager and IAA’s Project Manager shall agree on all issues that require further clarification concerning the methodology by which the risk management is to be realized.




7.4.7.2. Risk Management Methodology

1. The process of the risk management, as mentioned above, shall be based mainly on a designated "risks forum" that shall be established to execute the mission.

2. The risks forum shall include at least the following roles: the AMHS Project Manager, the system engineer, the development manager, the tests manager, IAA’s Project Manager and IAA QA Manager.

3. The Bidder’s AMHS Project Manager shall head the risk forum.

4. The risk forum shall convene each month in arrangement between the AMHS Project Manager and IAA’s Project Manager.

5. Meeting minutes shall be written under the responsibility of the Bidder's project manager.

6. The Bidder shall be responsible for maintaining a chart of detailed risks that shall be updated continuously and on a timely manner that shall ensure the risks mitigation or elimination. The structure of the chart shall be as detailed in clause 7.4.7.3 below. The up-to-date chart shall be prepared and published, each month, within 2 working days from day of the risk forum meeting.

7. The project risks and the mitigation plan shall be presented to the project steering committee by the Bidder’s project manager.

7.4.7.3. Structure of the Risk Chart

1. The Risk chart shall include the following fields:

a. Risk Identification factors – risk identification number, type, description, initiator, identification date.

b. Risk analysis factors – impacted areas/key success factors, risk materialized date (the date in which the risk become real if not addressed or mitigated), Severity, Probability, risk rank(*)

c. Risk Mitigation Plan – risk owner, mitigation plan, planned due date (for mitigation), revised and actual due dates, and status report.




Annex 7-A – Experience, Goodwill and Customers

1. The information provided by the Bidder in response to this section (Annex 7-A) shall have significant impact on the quality evaluation of the Bidder's Proposal.

c. An advantage in quality evaluation will be given to:

a. Operational provability (The more the offered AMHS is in operational use, in as many AMHS centers, longer duration in use, etc.).

b. Quantities supplied of the same or equivalent Systems such as offered in the Bidder's Proposal.

c. Compliance with the related functional, performance and maintenance requirements listed within this RFP.

2. Relevant Projects Completed (Q)

a. The Bidder shall provide information about both AMHS projects completed by the Bidder (as a prime contractor), where the system had been fully accepted by the client over the past five years (2010, 2011, 2012, 2013 and 2014) in the following table format.

b. In particular, The Bidder shall describe in detail one site, with similar characteristics and complexities to those required for the AMHS System in Israel, thus demonstrating the Bidder’s ability to deliver a complete solution as required under this Tender's Document.

c. The Bidder shall fully describe in details a case study of a complete Project in operation, most similar to the AMHS, including but not limited to: the architecture, BOM, challenges, solutions, deployment time, example documents of FAT and SAT (also of the COTS components), lessons learnt, etc.

d. The Bidder should emphasize and detail any difference in capabilities/technologies/bugs fixes between the future AMHS Version and the described project. Also, if there are any major changes, the Bidder shall explain how these are intended to be tested.

# Subject Remarks 1 Name of customer 2 Current Operational

status

3 Contact person details Information concerning the references shall include at least the following information: name of contact person, function, term of acquaintance,




# Subject Remarks nature of acquaintance, contact details (phone, fax, email) and a written document that shall be signed by the contact person expressing that he/she is aware that IAA may contact him/her for this purpose.

4 Type of contract Main Contractor, Subcontractor (if so, to whom)

5 AMHS solution project major milestones

Project's Starting Date, Project's Acceptance's Date, System Handover Date

6 Description of the MHS

10 System limitations and constraints

11 Interfaces

Certification / Acceptance

Please provide information such as: System certification date, who certified the system, how long it took, Division of roles among the supplier, the client and certifying body, content of examined elements, whether it was necessary to certify the ATCO's as well, whether it was necessary to certify the technical staff as well, etc. The Bidder may attach the relevant certificates to its Proposal.

Reference Letters The information concerning the references shall include the following at least: name of the company, name of reference, function, term of acquaintance, nature of acquaintance, contact details (phone, fax, email) and a written document that shall be signed by the reference expressing that he/she is aware that IAA may contact him/her for this purpose.

*Additional pages may be added for more than one project.




3. Experience: Geographical Spread (Q)

a. The Bidder shall provide information about all countries in which works similar to the AMHS projects have been undertaken, in the last five years (2010-2014):

Country Details

1

2

… … …




Chapter 8 - Warranty, Service and Maintenance




8. Warranty, Service and Maintenance

8.1 Introduction

1. This chapter defines the Bidder's requirements during the Pre warranty, Warranty and the Service and Maintenance period. The Warranty and the Service and Maintenance requirements with the Awarded Bidder technical proposal will be integrated in the final contract with the awarded bidder.

2. Following are:

i. Principles of the warranty, Service and Maintenance – Section 8.2.

ii. Implementation Concept – System's Components Section 8.3

iii. Scope of System's Components – Section 8.4.

iv. Scope of Services – Section 8.5.

v. The Procedures of each Service – Section 8.6.

vi. SLA – Section 8.7.

8.1.1 SMP Section 8.5.2 Guidelines for the Bidder

1. The following guidelines are supplemental to "Chapter 0 - Proposal Guidelines", which shall be fully complied here as well.

2. The detailed structure stands for a fair comparison purposes among the Bidders.

3. The Bidder shall describe its well proven relevant services and experience using the following guidelines.

4. The requirements contained in Chapter 8 are somewhat different from the requirements in other chapters. Chapter 8 deals mainly with the definition of "The Maintenance Service", (as defined in 8.2 in this Chapter), required by IAA and the requirements are of an imperative type. As such, the Awarded Bidder (or The Supplier) must fully comply with the requirements of "The Maintenance Service" and consider them as part of the definition of "The Maintenance Service".

5. The terms "The Bidder"', "The Supplier", “The Selected Bidder” or the "Awarded Bidder" in this chapter are commutative and shall be applied according to the context. Also, the terms "The Maintenance Service" and "The Service" are synonyms and shall be applied according to the context.

6. The Maintenance Service shall be applied during the Pre-operational and the Operational Period of the System (Maintenance Period) as defined in 8.2.




7. In order to avoid ambiguity and to assure that the Bidder fully understands the required "Maintenance Service" the Bidder is required to describe in detail how it intends to provide "The Maintenance Service" as defined in this chapter.

8. Moreover, the Bidder may choose a sub-contractor for the provision of some of the maintenance services or other services required by IAA. However, in such a case, the Bidder must assure that such a sub-contractor shall provide the services solely and not by another sub-contractor. In addition, the Bidder shall demonstrate the selected/appointed sub-contractor ability and capacity to provide the services.

9. As indicated in the Contract, the Bidder may employ a sub-contractor for the Maintenance Service only under the approval of IAA.

8.1.2 Definitions

The following definition should be strictly maintained; however, the Bidder may add other definitions upon his sole discretion. In any event, the Bidder's definitions should not derogate from IAA's definitions whatsoever.

# Term / Abbreviation Meaning

1. Corrective Maintenance

Continuous monitoring and responding to level-1/2/3 malfunctions, while following the SLA requirements. For example, HW Corrective Maintenance - replacing the faulty electronic part (see replace / repair method). For example, SW Corrective Maintenance –halts, one or more of the commissioned system.

2. Preventive Maintenance

Daily, weekly, monthly, quarterly, yearly routine maintenance, such as:

HW – Periodical HW system components inspection SW – System LOG check, system LOG cleaning, disk

space maintaining, other OS tasks required.

3. Replace / Repair Method

The faulty Component shall be sent to the laboratories of the manufacturer \ agreed service body in a Repair or Replace Method and returned as soon as possible (maximum 30 days excluding shipping and customs clearance), to the stock of spare parts after repair and quality checks. For any replaced / repaired Component, the Warranty Period shall resume from the date on which such part was accepted back into the spare parts inventory.

4. Malfunction The System, or its component, or the service it delivers, behaves abnormally in accordance with its specification as defined in the Tender documents. The severity of a malfunction is derived from its impact on The System's availability, functionality, services and capabilities.





5. Critical Malfunction A malfunction of any component that creates an outage in the AMHS System causing significant delay and / or non-delivery and / or loss of messages to / from the interfacing systems and /or networks Following are some examples for Critical Malfunctions:

The AMHS does not receive / send messages to one of the connected networks (CIDIN, AFTN, X.400)

Primary and backup servers are down. AMHS does not send information to AIS/AIM and/or

EFS/AODB (CHOCS) and/or ATIS/VOLMET systems. AMHS (UAT module) does not allow connection of

terminal users.

6. Serious Malfunction A malfunction in any component that does not cause an immediate disruption or outage in the AMHS System, but harms system’s performance, functionality or might lead to a Critical Malfunction. Serious Malfunction shall have a reasonable workaround approved by the user Following are some examples for Serious Malfunctions, including loss of redundancy issues (backup/coverage is available), performance degradation, limited system management etc.:

Single redundant Server/application is down Single redundant Communication element is down Degradation in system performance that does not affect

normal operations. Management and Monitoring incapability Loss of non-critical External interface

7. Moderate Malfunction A malfunction in a component that does not cause an immediate disruption or outage of that component. Following are some examples for Moderate Malfunctions:

Single redundant Disk drive is down One Maintenance Display Terminal is down Fault condition or discrepancy within any of system's

components, with respect to the relevant technical specification, which is not a critical or serious fault and allows AMHS system to function normally.

8. Recurring Malfunction

Malfunction that reoccurs at intervals of up to two weeks and is caused by the same event. After three such malfunctions, the malfunction shall be defined as a recurring malfunction. Handling of a Recurring Malfunction shall be at one level higher than the same malfunction, caused for the same reason.

9. The Project As defined in the Contract.

10. The System As defined in the Contract.





11. Maintenance Maintenance means all actions taken to rectify a Defect or to retain material in, or restore material to a specified condition, or to restore material to serviceability. Maintenance includes inspection, condition monitoring, servicing, repair, overhaul, testing, calibration, rebuilding, reclamation, upgrades, modification, recovery, classification and the salvage of technical equipment.

12. Pre-Warranty

Starting after the SAT IAA will conduct Level 1 and Level 2 support. The bidders engineer will be onsite for up to 4 weeks to supervise. This includes the 2 weeks provided in the Base Project plus a 2 week extension purchased as an option by IAA.

13. Warranty Period As defined in the Contract.

14. Service and Maintenance Period

As defined in the Contract.

15. IAA Business Hours 07:00 till 19:00 Sunday through Thursday (local time).

16. 1st Level Support or Level 1 (in this Chapter)

Basic fault handling, which is performed by IAA's technical team. Essentially management of system operation and performance. Includes diagnosis, reconfiguration, configuration of site spares per instructions, and the use of the Maintenance Display Terminal. Involves non-intervention type activities apart from system configuration (e.g. through the Maintenance Display Terminal).

17. 2nd Level Support or Level 2 (in this Chapter)

Fault resolution and replacement of faulty equipment on site with spares, while sending out the faulty equipment for repair to AMHS supplier. (Performed by IAA's technical team). Aimed at restoring a site or system to full functionality. Including preventative and corrective maintenance; system restoration, fault clearance (module replacement) and testing and validation.

18. 3rd level Support or Level 3 (in this Chapter)

Fault resolution by the Manufacturer’s laboratory or its representative overseas experts (The AMHS supplier). Component level repair or replacement. Including, on-line support and remote assistance from AMHS supplier support center. All functional issues are considered 3rd level support and are the responsibility of the awarded Bidder.

19. COTS Commercial Of The Shelf





20. 3rd Party Software or Hardware COTS

Satisfies all the following conditions: It is available to the market. It has an established history of use by different

customers. It is a product of a reputable, well established company. It is maintained by the vendor.

21. VPN Connection Broadband Internet connection provided by IAA (). This connection will be physically enabled ad-hoc by IAA's help desk, upon the Supplier’s request and in accordance to IAA System Security Policy.

22. SLA Service Level Agreement as stipulated in section 8.7

23. IAA Technical Team The IAA technical team is consist of the following experts:

Lead users – high level of knowledge in the system functionality and integrated monitoring capabilities

System Engineers – overseeing the system hardware and operating system

Network Engineers – overseeing the LAN and WAN infrastructure

ISDN Engineers – overseeing the P2P CIDIN and AFTN connectivity.




8.2 Service and Maintenance Principles

8.2.1 General

1. Service Life – The proposed AMHS shall be appropriate for a service life of at least 15 years. (P)

2. The Bidder should comply with ICAO requirements for AMHS application for the duration of the system life cycle. (P)

3. The AMHS system is an operationally mission critical system, requiring simple and automated monitor and control capabilities, with very high levels of availability and tolerance to partial failures. The bidder shall describe the features in the proposed system that insure operational availability, provides full view of system health and initiates alerts once necessary (P)(Q)

4. As a critical system, the AMHS requires the highest availability – 24*7. The response times for dealing with malfunction are derived from their severity definitions (Critical, Serious and Moderate). (P)

5. As A Critical system, IAA expects the Awarded Bidder to take end to end responsibility for IAA AMHS system (including all modules and interfaces) operation, availability as described throughout this document. The Awarded Bidder should provide IAA with a technical workaround solution (approved by IAA) to allow operation of the AMHS when a critical fault does not allow normal operation. (P)

6. To guarantee 24*7 operation AMHS system, the awarded Bidder shall build the following support and maintenance structure:

a. IAA technical team on site, will provide L1-L2 local support for the Awarded Bidder for the system and shall manage, maintain and operate the HW and infrastructure. The Awarded Bidder shall be responsible for training and certifying IAA technical team for the AMHS system. IAA team shall operate the system according to the Awarded Bidder maintenance guidelines, diagnostics, and analysis of the fault. (P)

b. The awarded Bidder shall remotely support IAA team and the system (Via VPN connection that will be supplied by IAA) with any technical / administrative / management issue when IAA team requires assistance from the Awarded Bidder. (P)

c. The Awarded Bidder shall provide and maintain throughout the contract life a detailed technical documentation pertaining to the installation, maintenance and troubleshooting related to the AMHS system. Updated documents shall be provided to IAA at least once every quarter or sooner if an update is deemed necessary. (P)




d. The Bidder shall describe in detail how it intends to manage the Remote Expert Support Desk and how it will interact with the On-site Maintenance Team in BGN and the Technical Management system (part of the AMHS Management System). (Q)

e. Network connection of Remote Expert Support Desk to the IAA's system shall only be under the approval of IAA, otherwise, the connection shall be disconnected. (P)

f. IAA's database, as a whole or in parts, shall not be sent abroad to the Remote Expert Support Desk or to any other party without the explicit approval of IAA.

g. The Bidder shall have to cooperate with the following parties and with the approval of the IAA SPOC:

i. IAA General Help Desk

ii. Network Help Desk

iii. External Interfacing Systems service representative

iv. Others, as needed.

v. The Bidder shall describe how it intends to manage the interaction with parties

at BGN Airport. (Q)

h. The awarded bidder shall maintain and supply 24*7 technical support center expertly familiar with IAA system and its implementation. The Awarded Bidder shall provide periodic fault reports as described in this document. (P)

i. The Awarded Bidder shall provide support level 3 and above to rectify all faults in the AMHS system. (P)

j. It should be clearly stated, that despite the maintenance role of IAA technical team, the complete – back to back – responsibility of the system availability is of the awarded Bidder. IAA technical team is available to serve and assist with the onsite tasks based and according to the Awarded Bidder instructions. (P)

k. All maintenance activities, such as configuration, fix installation, new software version installation, to name a few and which can be performed remotely, shall be executed by the Awarded Bidder representative. Upon the Awarded Bidder request and based on the available necessary technical training and skills, a member of the IAA technical team may execute the necessary task with the remote monitoring and support of Awarded Bidder support staff. (P)

l. From time to time, problem may occur in the supporting infrastructure which is not under the Awarded Bidder responsibility and scope of service. For example, a problem with the system external connections infrastructure provided by the local communication provider. In such cases, the Awarded Bidder is required to cooperate with the repair efforts to ensure that the system is not the source of the




problem and once the problem with the infrastructure is resolved, conduct the necessary system tests and procedures to ensure that the system capabilities are fully restored. (P)

7. Warranty Periods expectations:

a. : IAA expects the same requirements and responsibility from the Awarded Bidder for IAA AMHS system during the Pre Warranty, warranty and maintenance periods. During the Pre Warranty period, the Awarded Bidder is expected to have technical team onsite (P).

b. During Warranty and Maintenance period, the Awarded Bidder is not expected to provide and maintain or offer IAA with a dedicated team onsite. The Awarded Bidder is expected to train IAA technical team, provide remote support and analysis (With onsite assistance from IAA team) and attend the site only in special cases as described in this document. (Q)

8. Non critical /Urgent maintenance procedures shall be implemented during IAA regular working hours. Critical and operational disruption Faults will be handled 24*7 until resolved as described in this document. (P) (Q)

9. Corrective Maintenance:

a. Hardware (HW): For standard hardware, corrective maintenance shall be performed by the local vendor of the hardware. For non-standard hardware corrective maintenance shall be performed by replacing a malfunctioning component with a functional component from a stock of spare parts held in a proper storage (including periodical fitness checks) at IAA sites. (P)

b. Software (SW): Corrective maintenance shall be performed by reconfigurations, bug fixes, software upgrades (application and OS) anomalies’ resolution or any other activity which preserve the full functionality, availability and resilience of the system. (P)




8.3 Implementation Concept

1. The AFTN / AMHS shall be implemented in two operational stages; Stage 1 and Stage 2 as defined in Chapter 7 - SOW.

2. Two periods of operation (and maintenance) for each Stage are defined:

a. Pre-Operational Period (Interim Period) – This period is commencing from the first time any Operational End Station is connected to the new System (either in Stage 1 or Stage 2), and passed the Partial Acceptance Tests as defined in Chapter 7. The Pre-operational Period is concluded after conducting a full system operational test-run to check stability and performance (SOAK Test). During this period the Supplier shall fine tune the System and prepare the System for continuous operational mode as described in Chapter 7 section 7.3.5. The Awarded Bidder's engineers shall be present onsite for supervision and support. The Pre-Operational Period formally ends after the issuance of the Final Acceptance Certificate for the AFTN / AMHS System, either the Basic-AFTN System at Stage 1 or the Complete System (AMHS) at Stage 2.

b. Operational Period – The period that shall commence as of the issuance of the Final Acceptance Certificate for the AFTN / AMHS System and shall continue as long as the System serves IAA (the Maintenance Period). The Supplier shall assure the proper operation of the AFTN / AMHS System for the period specified in the contract.

3. During the two periods mentioned above, the AFTN / AMHS requires the highest availability - 24/7. The Supplier shall provide the Fault Repair Times for rectifying malfunctions and the required availability of The System as stipulated in section 8.7 below (the SLA) and other relevant Sections in this chapter.

4. It is required that as part of the DR Milestone deliveries, prior to the beginning of The Maintenance Service, the Supplier shall provide a detailed documentation regarding the content of the AFTN / AMHS System, its sub-systems and components, detailed system configuration, technical specifications, technical drawings, Bill Of Material (BOM), manufacturer's maintenance instructions, supply of spare parts, supply of consumable material (if and as needed.), maintenance work facilities, maintenance tools and equipment and other pre-conditions that will enable the Awarded Bidder to perform the required maintenance services and additional related supporting services and procedures as described herein.

5. The Bidder shall maintain and update the documentation once a year or upon system upgrades and major updates (the earliest) throughout the life cycle of the AFTN / AMHS System as part of The Maintenance Service.

6. The Bidder shall describe in detail the mechanism it intends to use for the maintenance of the abovementioned documentation. (Q)




8.4 Scope – System's Components

1. The Awarded Bidder shall bear total and overall responsibility for the proper function of all of the System's Components (Primary, Backup & Test environments) throughout the life cycle of the system, including among others Hardware, Software, COTS components, Communication components, Cables, Various Accessories, Licenses, Documentation items, Training Materials, , , etc. All according to the details that appear in Chapter 9 -“BOQ”.

2. The Awarded Bidder shall bear co-responsibility, with 3rd party vendors, for the proper function of all of The System's components, such as: Interfaces, Connections to IAA's communications network(s), connection to power supplies, etc.

3. The bidder should give a full description of how he intends to fulfill the requirements in clauses 1 and 2 above. (Q)

8.4.1 Spare Parts

1. The Awarded Bidder shall describe the spare parts inventory recommended to keep onsite in order to replace faulty parts quickly and efficiently while maintaining minimum downtime. IAA perceives as critical nonstandard and/or preconfigured system components as key for this inventory.

2. The spare parts shall be in the IAA's possession (at IAA's premises) starting from day one of the running production system (after SAT successful accomplishment and approval).

3. The Awarded Bidder shall plan for the appropriate amount of relevant consumable spares following the characteristic of the various malfunction severities specified in this chapter. (P) (Q)

4. IAA will maintain suitable warehouse for the spare parts at its own expenses. IAA will consider the Bidder's specifications for housing the spare parts.

5. The Bidder should, in its response to the Tender, provide detailed requirements for the aforementioned warehouse and provide detailed instructions for the storage environment. The Bidder's requirements should be subject to IAA approval. (P) Q)

6. The Bidder shall provide a full and detailed list without prices within the BOQ – Chapter 9 of the Technical Requirements Chapters (The same detailed list with pricing shall be included separately within the pricing offer – appendix D of the Tender Documents - Price Proposal Form. (P) (Q)

7. The BOQ list shall include the delivered spare parts and special tools needed on site for preventive and corrective maintenance to achieve the required availability values. (P) (Q)




8. The inventory level shall comply with the required SLA detailed hereinafter in this document. Particularly, the inventory level shall meet the SLA requirements for critical and serious malfunctions of the system (see aforementioned definitions list). (P) (Q)

9. The Bidder shall specify how the correctness of spare parts is validated (Q)

10. The above specified list should contain the following information:

a. Full list of all hardware items that are deemed Site Spares per the BOQ.

b. Full list of software items.

c. Consumables.

d. Every item shall be associated with its containing sub-system, or system.

e. Indication if elements are required on site for preventive or corrective maintenance.

11. The Awarded Bidder shall be able to continue to supply non-standard spare parts for the whole system for at least 15 years (for the warranty period and as long as the maintenance agreement exists) from system commissioning. In case any of spare part is no longer available in the market, an equivalent spare part shall be provided. Spare Parts and Test Equipment pricing are per the contract.

8.4.2 The Maintenance Working Position

1. The system shall have dedicated working positions and/or modules for control and monitoring functions that allow technical maintenance personnel to monitor the status of the equipment, displaying full view of system health, information and control of its functions, lines and networks and interfacing systems. See Chapters 5 and 6 for further details.

8.4.3 COTS and 3rd Party Components

1. The Bidder should provide IAA with a detailed list of COTS and 3rd party components, including: detailed component description, vendor and cost. (P)(Q)

2. The COTS and 3rd party HW and SW components should satisfy all the following conditions: (P)(Q)

a. Available on the market.

b. Have not been announced: "end-of-sell" and / or “end-of-support" and / or "end of life". Furthermore, to avoid any doubt, at the project onset, the Awarded Bidder shall review the system COTS components and make the necessary adjustments to ensure that the system is equipped with the latest HW and SW versions that are supported by the Bidder. It would be the vendor




responsibility to make compatibility adaptations to the system to ensure proper operations.

c. Established history of use by different customers.

d. Product of a reputable, well established Manufacturer.

e. Maintained by the vendor.

3. For Software solely:

a. The vendor possesses the source code.

b. The vendor shall list all open source components used in the system

8.4.4 Test Equipment (if required)

1. The supplied Test Equipment shall have a calibration certificate, issued by an accredited certification body.

2. The supplied Test Equipment should be available in the open market and shall have proper local support and local representative including vendor's certified maintenance laboratory in Israel. (Q)

3. The Bidder shall provide a full and detailed list without prices within the BOQ – chapter 9 of the Technical Requirements Chapters (same detailed list with pricing shall be included separately with the pricing offer – appendix D of the Tender Documents - Price Proposal Form. (P) (Q)

4. The above specified list shall contain the following information: (P) (Q)

a. Type of equipment (e.g. power meter, AFTN/AMHS message simulator etc.)

b. Relevant technical specification of the equipment (e.g. measurement range)




8.5 Scope – Services

1. The Bidder shall provide all the services presented below during the Maintenance Period defined in the Contract and its appendices for the entire System Life Cycle.

8.5.1 The Core Service - Definition

The required Core Service is to keep the AFTN / AMHS System in full

Operational Mode and to maintain the AFTN / AMHS System according to

the Service Level Agreement (SLA) defined in this document for the

defined System Life Cycle.

8.5.2 The Core Service – Breakdown to Related Services

1. In order to provide the core service in accordance to the required SLA, related supporting services and procedures must be included in the overall service. These services and procedures are described below.

2. It is emphasized that the Core Service mentioned in section 8.5.1 above and the breakdown services and procedures mentioned in this section 8.5.2 hereafter, section 8.6 and any additional services and procedures that the Bidder may propose and are approved by IAA, all together and each by itself, are part of a package called "The Maintenance Service".

3. The Bidder shall provide "The Maintenance Service" as a whole.

4. The additional services shall include at least the followings, (the Bidder may propose additional services and procedures):

a. AFTN / AMHS Platform Operation – The Bidder shall activate and operate the AFTN / AMHS Platform. The AFTN / AMHS Platform shall operate in the following modes of operations, so as to ensure System performance as described later in this chapter:

i. Redundant Mode / Online Operation – Normal Mode of operation.

ii. Non-Redundant Mode: For Corrective Maintenance, Preventive Maintenance, and Upgrading purposes, under the approval of IAA. It may apply when the backup system is down or serves other purposes and the main System operates in Non-Redundant mode.

iii. Offline – Total shutdown of the System, either scheduled shutdown (after IAA approval only) or in Recovery Mode where the System is down and actions are in place to bring the System online.

b. AFTN / AMHS Configuration Management – The Supplier shall manage the configuration of the AFTN / AMHS Platform. Configuration management includes, but not limited to, the management of the following issues:




i. System Components and Inventory – inventory management of the

various components (HW&SW) of the System, including among others

Hardware, Software, application versions, COTS components,

Communication components, Cables, Various Accessories, Licensees,

Certifications, Documentation items, Training Materials, Furniture,

Mounting Brackets, etc.

ii. System Topology – management of the topology of the AFTN /

AMHS, both logical topology (i.e. relationships and logical

connections between components of the System and interfaces to

external systems), and physical topology (i.e. physical location of the

components of the System and Communication Network depicted on

schematic layout of the airport and external sites).

iii. Versions Management –The version of a System consists of the

versions of all its components and the System Topology as mentioned

above. Whenever a change is made to the System (see clauses (c) and

(d) below), a new system version is created. IAA requires an

intermediate version management that will enable managing major

changes, especially software updates, so as to enables a fallback to the

previous version in case of the malfunction in the new version.

iv. The Bidder may add other Configuration Management items upon its

sole discretion and shall describe the mechanism and procedures to

manage the System's configuration, and shall describe in detail how it

intends to manage the versions of the System components (SW&HW)

and the Version of System as a whole. (Q)

c. AFTN / AMHS Change Management – The Bidder shall manage all the changes in the System. Change Management includes:

i. Planning, installing, testing, executing and reporting changes in the

components of the AFTN / AMHS due to maintenance activities as

described below (see clause (d) below).

ii. Approved Changes, including Options, which were implemented

according to the Variation Order Procedure, or the Change Procedure,

as described in the Contract, i.e. changes that were paid by IAA and




implemented in the System by the Supplier shall be managed and

maintained as part of "The Maintenance Service".

iii. Other Changes implemented by the Supplier as part of the Corrective

Service, where the Supplier is bearing all costs for the changes, shall

also be managed and maintained as part of "The Maintenance Service".

iv. All Changes shall incorporate the Variation Order Procedure or the

Change Procedure, under the approval of IAA, in order to ensure

proper integration and management of the Changes in the AFTN /

AMHS System.

d. Maintenance Actions: maintenance actions include the following; the Bidder may add other actions upon its sole discretion:

i. Faults and Malfunctions Corrective Actions – Faults and

malfunctions must be corrected sometimes by replacing components.

HW malfunctioning components are replaced by spare parts, SW

malfunctions might demand version updates, patches, bypasses and

bugs fixes. All these Corrective actions are part of the Maintenance

Service, and shall be managed by the Configuration or Change

management.

ii. System and Database Administration – as part of keeping the System

at best performance and proper operation, the Awarded Bidder is

required as part of "The Maintenance Service" to manage the operating

system and other basic software as well as the database, archive, back-

up procedures, configure users' profiles, and all other administrative

tasks as described in Chapter 6.

iii. End Stations Updates – In order to keep the System in compliance

with the Procedures Of Operation at IAA, the Bidder is required as part

of "The Maintenance Service" to update screen menus of WS, End

Station and Peripheral Configurations, etc. The Bidder shall assist the

IAA Managers to execute these updates as needed by IAA.

iv. Outdated Components Replacement – Occasionally, old outdated

components must be replaced, whether because they are not

functioning properly, it is too costly to repair them or they are no

longer supported by the manufacturer / vendor. The certified




replacement component shall have at least the same performance and

capabilities as the outdated component. The Bidder shall update all its

SW and HW components as part of "The Maintenance Service". In

addition, IAA may request the Bidder to replace certain components

and End Stations, anytime during the contract time, according to the

prices listed in the Price Proposal and the contract, even though the

device is still functioning.

v. Upgrades / Updates - During the Maintenance Period and as part of

"The Maintenance Service", an on-going process of keeping the

systems' components (SW, HW and / or Firmware) up to date, shall be

maintained. This shall be applied when standards, operating systems,

licensing, certifications, etc., which are applicable to AFTN / AMHS

System, are updated or require renewal, in order to keep the system

running in full capacity, high performance and operational mode.

vi. Connected AFTN / AMHS Centers Updates - If during the

Maintenance Period, any of the aforementioned connected centers or a

new connected center updated will update its center, The Bidder shall

integrate the application, and make the configuration changes as part of

"The Maintenance Service". The same applies when a connected center

terminates its activities with IAA.

vii. IAA's CFE Updates - an on-going process of keeping up to date with

new versions of IAA's CFE (such as IAA network equipment, or any

certified 3rd Party application provided by IAA, etc.), the Bidder shall

implement these updates in the AFTN / AMHS System, during the

Maintenance Period and as part of "The Maintenance Service".

viii. The Bidder may add other Maintenance Actions to part of the

Maintenance Service upon its sole discretion. (Q)

e. ICAO and WMO Updates: During the life of the Warrantee & the Maintenance Service the Awarded Bidder will be responsible to keep the system up to date with any ICAO or WMO recommended changes. The Awarded Bidder will present a plan to IAA for implementation of the published changes in the system. IAA may elect to skip recommended changes by ICAO and/or WMO. The Awarded Bidder shall be ready to




implement the changes in the system, prior to the announced operational dates published by the relevant regulatory body. These changes shall be provided to IAA at no additional cost and as part of the maintenance service plan.

f. Miscellaneous Services:

The Bidder shall describe in detail how it intends to provide the following

miscellaneous services:

i. Providing Advisory Services for problem resolution as well as

decision making by IAA in issues which are relevant to the AFTN /

AMHS.

ii. Training and Qualification of IAA's staff, in order to certify them to

operate AFTN / AMHS servers, communication equipment,

workstations etc.

iii. Repair faulty or damaged Components of the System not covered

in the SLA. In such cases, (e.g. a user broke a display monitor by

mistake) the Bidder is entitled to charge IAA additional payment for

the time and materials which were necessary to repair of the damage.

The extra payment will be in accordance to the prices and tariffs that

are stipulated in the contract and the updated Price Proposal attached to

it. Repairing should be done only after IAA approval of the repair cost.

After repairing, the Supplier shall be responsible to continue

maintaining the replaced components according to the SLA.

iv. Priority of Maintenance Activities - IAA at its sole discretion will be

able to dictate the level of severity based on the SLA. I.e. IAA may

dictate that a specific failure will be treated as Critical Failure or

Regular failure, etc. Perform Services beyond the scope of the SLA -

This extra service will be in accordance to IAA's written demand. The

Bidder is entitled to charge IAA additional payment for time and

materials to such service. The price will be in accordance to the prices

and tariffs as stipulated in the Contract and the updated Price Proposal

attached to it.

v. The miscellaneous services required by IAA as mentioned in sections

(c), (d) and (e) above will not disrupt other components of The




Maintenance Service, and in no way shall impact the SLA of the AFTN

/ AMHS.

vi. IAA has the Right, according to the Contract, to purchase from a Third

Party an equivalent standard HW/SW component, material or service

available in the market and the Bidder will execute the service using

this material/component/service in the System.

vii. Calibrate End Stations and Peripherals – As an ongoing operation

of tools and devices that required periodic calibration, such as various

types of electronic measurements equipment, the Supplier shall do so

according to Israeli Low as part of the Maintenance Service.

g. AFTN / AMHS System Maintenance Plan (SMP):

i. The Bidder shall prepare long and short term System Maintenance

Plans.

ii. The Bidder shall prepare long term Maintenance Plan once a year.

iii. The Bidder shall prepare a short term Maintenance Plan for two

periods: monthly and weekly.

iv. The Bidder shall present a long term Maintenance plan as part of the

proposal. The SMP will, eventually, be part of the system

documentations. (P)(Q)

v. The SMP shall include:

a) Planned and Preventive Maintenance – Planned and preventive

maintenance actions are known in advance and thus can be

planned precisely.

b) Fault Repairs and Corrective Maintenance – Faults and

malfunctions are non-deterministic and of a stochastic nature.

Thus, the corrective maintenance plan will include statistical

estimations of expected fault repairs.

c) Material Planning - The plan will include the quantities of spare

parts / components, LRU's, and consumables required in the time

span of the specific plan (yearly, quarterly, monthly, weekly,

daily), as well as stock levels to assure material availability




whenever needed. The consumable material planning will include

statistical estimations of expected consumption, as well as

appropriate stock levels. The Bidder shall describe in detail how it

prepares the plan for material consumption.

d) Manpower Planning – The plan will include the skills required in

order to provide "The Maintenance Service", number of

professionals needed for each skill, the training required for

devolving and updating the professional manpower, vacations, and

other expected absence. IAA requires that all professional

manpower shall be qualified by the Bidder's training center and

shall possess official certificate from an authorized technical

institute.

e) Maintenance facilities and infrastructure planning – The plan

shall include any enhancements needed in the maintenance

facilities and infrastructure, such as maintenance tools,

maintenance working position, test stations, etc. In light of the

tight constraints imposed on IAA regarding floor area, rooms and

assets, such required enhancements need to be discussed with IAA

(see CFE in chapter 9).

h. Processes and Working Procedures: The Bidder shall manage (i.e. plan, execute, monitor) the processes described in section 8.6.




8.6 Procedures

1. The Bidder shall describe in detail to the following processes and procedures described in this section.

2. The Bidder shall propose a technical management system which will assist the maintenance team to achieve the required level of SLA. (Q)

8.6.1 AFTN / AMHS Help Desk

1. The Awarded Bidder shall maintain a professionally staffed 24/7 help desk in order to comply with the SLA for the AFTN/AMHS system (P)

2. The Awarded Bidder shall provide IAA a web based trouble reporting system for the purpose of opening, tracking and monitoring system problems (Tickets). The system will issue an automated reference number for new ticket reported for simple communication with the selected vendor maintenance staff. (P)

3. The Bidder shall describe in detail the AFTN / AMHS Help Desk's capabilities in the following activities: (Q)

a. Managing the trouble ticket forms (Q)

b. Managing Alerts and Events from the AFTN / AMHS System and the various

devices, interfaces and equipment which report their status to the Management

Systems.

c. Register all events in the corrective process, including opening/closing the

malfunction, diagnosing the malfunction, assigning a technician, resolving the

problem, etc. (Q)

d. Automatic escalation of the malfunction to the relevant authorities when the

SLA is not met. (Q)

e. Display the Situation Awareness Picture (SAP) of the system topology (logical

and physical), for example: with color coded status: Green – Operate in full

service, Grey – not allocated, Red – Fault, Yellow – partial Fault, Orange- In

service, Blue- Maintenance mode. (Q)

f. Provide statistics on historical events and information of problems, statuses,

event and alerts, required for analysis and future maintenance planning. (Q)

8.6.2 Fault Severity Classification




1. The malfunction severity will be determined upon opening a malfunction call in accordance with the Definitions in section 8.1.2.

2. The malfunction severity can be updated by the AFTN / AMHS Support Team with the approval of IAA, in succeeding steps in the maintenance process, e.g. after diagnostics, upon bypassing, etc.

8.6.3 Diagnostics and Repair Planning

1. The Bidder shall describe how the AFTN / AMHS Support Team analyzes the malfunction, diagnose the malfunction and propose the maintenance activities to be undertaken. (Q)

2. The Bidder shall provide the AFTN / AMHS Support Team with software tools that will enable (whenever possible) remote diagnostics, locate the malfunctioning component, identify the malfunction, and prioritize the maintenance activities. The Bidder shall describe these tools in detail. (Q)

3. The Bidder shall provide the AFTN / AMHS Support Team with software tools that will enable (whenever possible) planning the corrective actions; e.g. providing a predefined checklist of corrective actions, tools and equipment, technical drawings, spare parts, LRU's, SW updates / patches / fixes for frequent malfunctions. The Bidder shall describe these tools in detail. (Q)

8.6.4 Malfunction Repair / Corrective Maintenance

1. The Bidder shall repair, as soon as possible, any malfunction and/or fault and/or breakdown that are discovered in the supplied system. That includes software reinstallation and reconfiguration if needed (for example, after hardware replacement). Such a repair shall be applied subject to the requirements of system availability and SLA.

8.6.5 Planned / Preventive Maintenance

1. The Bidder shall perform a Preventative Maintenance schedule based on manufacturer's minimum guidelines and subject to the requirements of system availability and SLA.

2. As part of the Preventive Maintenance the Bidder shall define a Routine Daily Check which shall include at least the activities mentioned in 8.5.2 – g, v, a.

3. The Bidder shall give a full description of how it intends to fulfill the requirements above. (Q)




4. Any Preventive and Maintenance plan is subject to IAA approval. Special care must be taken when planning maintenance tasks to make sure that they will not disrupt the operational mode of an End Station. IAA can change/modify the maintenance dates according to operational reasons; however, this shall not reduce any of the Bidder's responsibilities to comply with the required SLA.

5. The Awarded Bidder shall comply with IAA Business hours for scheduled maintenance, support and repair activities. Urgent tasks shall be carried out around the clock. (P)

8.6.6 Maintenance Reporting and Documentation

1. The Bidder shall perform maintenance reporting and documentation as an integral part of the maintenance activities.

2. Maintenance reporting and documentations shall include the following:

a. Maintenance Reports (Q)

b. Configuration Management Reports (Q)

c. Monthly SLA Reports (P,Q)

8.6.6.1 Maintenance Report

1. The maintenance reports, both for corrective and preventive maintenance, will provide a reliable audit trail for every malfunction and shall include at least the following details:

a. Date and time of when the malfunction was reported.

b. Malfunction opening details, including: unique malfunction identification

(automatically allocated by the AFTN / AMHS Help Desk information system),

date and time, malfunction description, malfunction severity, Maintenance Level

required.

c. Malfunction diagnostic details, including: date and time, description, planned

maintenance activities, tools and equipment, technical drawings, spare parts,

LRU's, SW updates / patches / fixes.

d. Malfunction maintenance execution, including: date and time, actual,

identification of technician, maintenance activities, replaced parts, LRU's, SW

updates / patches / fixes.

e. Escalation details, including: date and time, reason of escalation, level of

escalation, informed authorities.




2. The details of a malfunction will be entered into the system in online mode and will be an integral part of the working procedure. The Bidder must assure that all malfunctions that were dealt during a working shift will be updated in the System by the end of the shift.

3. Report outputs can be obtained in online mode at any time, either by the Maintenance Team or by IAA's Mangers via a dedicated WS.

4. The maintenance reports shall enable to provide statistics on past events and information required for analysis and future planning.

5. The maintenance report shall enable to provide calculations of the actual service level provided to the System. This report shall serve as the SLA report with the actual Maintenance Service Level that was achieved during the requested period of time. (P,Q)

6. The maintenance report shall enable to provide monitoring, supervision, control, and coordination.

7. Some reports shall be defined as automatic scheduled reports. (Q)

8. The proposed reports must cover all sections detailed in this SLA, including but not limited to:

a. The Service Availability

b. Total AFTN / AMHS availability

c. End Users WS Availability by type

d. Communication Equipment Availability

e. Peripherals

f. Fault repair times, fault severity

g. Recurring Faults

h. Transaction times

i. AMHS Support Team service times

j. Preventative Maintenance Report and Schedule

9. All reports submitted as part of this section are required to be in the English language.

10. The SLA report shall be provided by the Supplier in the beginning of each month.

11. The Bidder shall provide examples of its standard reports presenting fulfillment of the SLA and the requirements above. (Q)

12. If the Bidder does not have standard reports to meet any of the above requirements, the Bidder shall customize reports so as to meet the requirements. The Bidder shall describe the customization needed in its standard reports. (Q)




8.6.6.2 Configuration Management Report

1. As part of the Change Management described in 8.5.2 - 3 The Bidder shall document any change in the configuration and or versions of the System.

2. The Bidder shall have an updated documentation of the active system configuration upon completing the maintenance activity.

3. The Bidder shall present to IAA the system configuration documentation upon request.

4. The Bidder shall provide examples of its standard reports for the configuration management. (Q)

8.6.7 Service Level Escalation

1. When the SLA is not fulfilled for a specific malfunction, an escalation process will be put into effect.

2. The escalation will be done at two levels:

a. At the first level of escalation, the IAA SPOC and the Bidder's team manager will

be notified of the delay, so as to enable them to intervene in the maintenance

process and make a joint effort to resolve the problem.

b. At the second level escalation the higher level on management, both IAA's and

the Bidder's will be notified of the delay, so as to enable them to intervene in the

maintenance process and make a joint effort to resolve the problem.

3. First and second level escalation notification will be automatically issued by the AFTN / AMHS Help Desk information system to the relevant managers via e-mail and/or via SMS.

4. The Bidder shall perform the escalation process as an integral part of the maintenance process.

5. For any system critical malfunction which is not being resolved remotely in accordance with the SLA time frame, the selected vendor shall be obligated to send qualified technician to IAA site to closely manage the situation until final resolution. All costs associated with the onsite presence (travel and per-diem) are to be assumed by the Awarded Bidder. (P)

8.6.8 Monitoring, Supervising, Control and Coordination

1. The Awarded Bidder shall appoint a single point of contact representative with adequate qualifications and experience, who will be responsible to monitor, supervise,




control and coordinate the provision of all services in accordance to the SLA and performance defined in this chapter.

2. Replacement of the representative will be done with proper notification to IAA SPOC.

3. The IAA representative will continuously examine the maintenance services provided by the Bidder.

4. The IAA representative can, at any time, request reports and documentation from the Bidder regarding the Bidder's service as described in this chapter.

5. The IAA representative can, on its own discretion, write and deliver to the Bidder a report which may include recommendations on how to improve these services.

6. Bidder's maintenance and service activities, that require coordination, will be accomplished with the aid of the IAA representative.




8.7 Service Level Agreement (SLA)

8.7.1 Required Availability and Service Level Parameters

# The Service Critical Malfunction Serious Malfunction

Moderate

Malfunction

1. A Call Time frame IAA message must be answered by Human. The message might be followed by voice mail, email, SMS or any other mean as agreed.

A message to the Awarded Bidder's service representative at Awarded Bidder's call center (24/7/365)

A message to the Awarded Bidder's service representative at Awarded Bidder's call center (24/7/365)

A message to the Awarded Bidder's service representative at Awarded Bidder's call center or via email.

2. Maximum Return Call Response Time

Up to 15 minutes Up to two hours during standard working hours of the Awarded Bidders or immediately on the beginning of the next IAA business day.

The following IAA business day from the receipt of the message

3. Fault Repair Time (Level-1/2 by IAA)

Continuous work until the fault is fully repaired. Effort will be made to repair the fault, or to find a workaround, which has to be approved by IAA, within 4 hours from declaration of the fault. After 4 hours, the escalation notice will be produced.

Continuous work during standard working hours. If IAA team is required on site, then during IAA Business hours

According to what is agreed with IAA representative and not later than the end of the following quarter

4. The Service work Timeframe

Throughout the year 24/7

During IAA working hours throughout the year except Saturdays and Jewish holydays

During IAA working hours throughout the year except Saturdays and Jewish holydays

5. Total Overall Availability / Unavailability Target

No longer than 10 hours per year and not more than 2events exceeding 4 hours

No longer than 60 hours per year and not more than 6events exceeding 8hours each

--




8.7.2 Highlights

1. The Bidder shall cooperate with all parties involved in the maintenance activity of the overall system, even when it is not clear whether the activity is in the direct responsibility of the Bidder.

2. IAA holds the right to prioritize the maintenance activities at its sole discretion.

3. IAA holds the right to order from the Bidder maintenance activities which are beyond the agreed SLA. Such maintenance calls will be paid by IAA according to the Contract.

4. IAA has the sole right to stipulate the severity of a malfunction as critical even though it might be considered to be of a regular severity. This shall apply also for cases not covered by the SLA. In order not to misuse these rights, IAA will be limited to execute such a stipulation, free of charge, up to 20 times a year and without any derogation from the required SLA.

8.7.3 Fulfillment of required SLA and availability

1. In case that the Awarded Bidder will come to the conclusion that the malfunction cannot be repaired within 4 hours as mentioned in the SLA table above, The Awarded Bidder shall escalate the treatment to senior professional representative, which will arrive (within 72 hours) onsite with all required spare parts for restoring the system to its normal operation. The technical team will remain on site till the restoration of the faulty equipment.

2. The Bidder shall clearly state that it is capable of providing the required SLA and availability as described above. (P,Q)

3. The Bidder shall describe how it intends to fulfill the required SLA and availability. (Q)

4. The Bidder shall present references of AFTN / AMHS Centers where it provided similar SLA and availability. (Q) This shall include:

a. Name of AFTN / AMHS Center

b. Years of implementation (from year – to year)

c. Name of contact

d. Title of the Contact.

e. Relevancy of the Contact Person to the System.

f. Contac's telephone number




g. Contact's e-mail

8.7.4 Alternative maintenance model

1. The Bidder may propose an alternate Maintenance Model based on its experience that may either meet or improve the SLA and/or availability, in comparison to those specified in this Chapter, at a lower maintenance price.

2. The Bidder shall elaborate its improved Maintenance Model in the Price Proposal Appendix D. This alternate model is not evaluated in the total price proposal of the RFP.

3. The Bidder shall describe in detail the improvements derived from its alternate model and shall include the parameters, values and tables that explain the model. (O,Q)

4. To avoid any doubt, the IAA's maintenance model, specified in this Chapter shall remain the model to be referred by the Bidder in its Price Proposal for the evaluation process.

5. The Bidder shall present references of AFTN / AMHS Centers where similar Maintenance model and similar SLA and availability were implemented. This shall include: (O,Q)

a. Name of the AFTN / AMHS Center

b. The Maintenance Model and SLA

c. Years of implementation (from year – to year)

d. Name of contact

e. Title of the Contact.

f. Relevancy of the Contact Person to the System.

g. Contac's telephone number

h. Contact's e-mail




8.7.5 SLA Monthly Report Sample

1. Header

IAA <<Airport Authority>>, Monthly Report <<mm/yyyy>>

2. Inventory

Number of each type of components # Component Quantity 1 Main System 2 Backup System 3 Test System 4 Admin Work Stations 5 Technical Work Stations 6 End User Work Stations 7 … 8 …

3. Infrastructure Availability

Availability of IAA scope of supplies (electricity, network).

# Component Quantity Remarks 1 Days per month 2 Operational minutes per day 3 Total Available Minutes 4 Monthly Downtime in Minutes 5 Total IAA’s Supplies Availability 6 …

4. Components Faults

# Component Total Remarks 1 PC (Regular) 2 3 4 5 6 7 8 Total No. Of faults

5. Target for Fault Repair Times

a. 95% of Critical Faults will be resolved within XX min. b. 85% of Moderate Faults will be resolved within YY min.




6. Actual Fault Repair Times

Total Number of Critical Faults: ____. ____% Of Faults were solved within SLA time. # Number of Faults Solved Within 1 XXX 30 Minutes 2 YYY 60 Minutes 3 ZZZ 90 Minutes 4 WWW 120 5 TTT >120

7. Components Availability

Component’s availability will be measured out of Total IAA’s Supplies Availability.

# Component Score Remarks 1 Average Main System Availability 2 Average WS Availability 3 Average Management System Availability 4 Average Technical Management System

Availability

5 6 7 8 …




8.8 Failure Scenarios Handling Description

1. The Bidder is kindly requested to describe the flow and the processes of resolving a few failure scenarios as following:

a. Hardware failure within the system.

b. Software failure within the system.

c. Wrong configuration of the system's parameters.

d. Critical failure within the system.

e. Concurrent failures within the system.

f. Failure in an external interfacing system.

g. Failure in communication lines of Bezeq.

h. Failure within IAA's CFE (such as the communication network).

2. The Bidder shall propose a visit of the Bidder's expert(s) to Israel in order to verify:

i. System's Sanity. The Bidder will introduce what will be tested, what the expected results will be and how does it prove the System's sanity (O, Q).

ii. System functioning at least at the same level as it functioned while passing the System and the Service acceptance tests (O, Q).

The aforementioned services shall be included in the Bidder's Price proposal.




Chapter 9 - Bill Of Quantities (BOQ)




9. Bill of Quantities (BOQ)

9.1 General

9.1.1 Guidelines and instructions for the Bidder

The Bidder shall describe the exact content of its proposed system to IAA in accordance with the following directions.

5. This Chapter – Chapter 9 – and Appendix D of the Tender Documents – The Price Proposal – are tightly coupled. The Bidder shall read carefully both documents instructions, guidelines etc. before it starts to fill-in their tables.

6. The Bidder shall stipulate the BOQ of the Components and all other parameters which reflect the Bidder's single solution, all as required for the completion of the Project in accordance with the provisions of the Contract and the System Requirements.

7. Without derogating from the provisions of Sections 6 מעל, the Bidder is required to refer any and all component and/or any other items within the BOQ and to fulfill and/or complete and/or provide any and all of the Sections herein and in compliance to their provisions.

8. The format of the response shall correspond exactly to the structure of the clause; some of the tables' entries are filled in with values for illustration purposes solely; The Bidder shall fill-in each component exactly according to the following directions.

9. The Bidder is required to propose a configuration that should comply with the functionality, the performance, the required expansion ability of the solution, etc., as appears in the Technical Appendices. For that purpose, the Bidder may add rows to the tables as required by its proposed solution.

10. The Bidder should submit a solution based on hardware and software complying with the above-mentioned requirements.

11. The Bidder should refer in its Bid and the Technical Proposal to a single solution for the completion of the Project / Option in compliance with the Technical Requirements. In this respect the Bidder's response to this chapter (and to the Price Proposal) shall include all component, sub-components, tasks, materials, labor, services etc. in order to achieve its single solution.




12. However, the system would be tested upon functionality and performance. If the System would fail to meet (for example) its expected performance, it would be the Bidders obligation to correct and/or to add components and/or to enhance the configuration etc. without any additional costs.

13. For avoidance of a doubt, IAA explicitly declares, that it would not make any additional payment whatsoever for modifications (should any be required) in the following configuration due to the reasons mentioned above.

14. Further Clarifications for Components / Items

a. The Bidder might be requested to clarify a few issues referring to its proposal.

b. Such clarifications intended to remove misunderstandings and clarify various matters in order to place the proposal on a uniform and comparable common denominator.

c. For some items in the BOQ’s tables, the Bidder might be required to submit further breakdown. The breakdown should include subdivision of the original item to sub-components (or tasks or material or labor). Each item in the sub-division should be priced separately (at the cost's forms document).

d. IAA may use that breakdown information for purchasing sub-items that are components of an item.

e. The Bidder should provide a breakdown for every item.

15. The Bidder shall meticulously complete all the data required in each and every table below.

16. For each item/component below The Bidder must include a reference to a detailed description of its exact and unique configuration as proposed to IAA.

17. For each of the aforementioned components, The Bidder shall provide the following information: manufacturer, model, detailed specification of the exact configuration proposed to IAA at the basic offer, launching date of the proposed version, target date of next version, major new features of the next version, and additional information as per the Bidder's preferences.

18. The following tables refer the Bidder occasionally to Sections in the Technical Requirements documents where the Bidder may find information about the requested component. The references are merely




highlights. Under no circumstances should the Bidder interpret these Sections as the full scope of requirements for the relevant component.

19. Tables of Spare Parts and Test Equipment are mentioned later on within the "System Related Components" of Setting up the Complete System, for example in Section 9.2.4 below. The Bidder shall be aware that Spare Parts and Test Equipment are not an integral part of the Setting Up Project of the Complete System. The Spare Parts and Test Equipment prices shall be specified in the Bidder's response to Section 6 in Appendix D, of the Price Proposal Forms while prices of Setting Up the Basic System shall be specified in the Bidder's response to Section 1-4 in Appendix D, of the Price Proposal Forms.

9.1.2 Quantities and Expandability - Reminder

Note: All supplied elements (hardware, software) shall comply with the general guidelines detailed in the chapter 6 prolog as follows:

General Guidelines and Requirements (see chapter 6.1.1 sub-6)

The hardware, software and other technological infrastructures shall enable easy and straightforward expansion of at least 30% for all the physical elements of the system, without any need for any financial investment (over and above the purchase and integration of the elements), and without the need to replace existing system elements (hardware or software).

9.1.3 The BOQ Tables

a. The BOQ incorporates the following tables: 1. Table 9-1: BOQ Table's Structure 2. Table 9-2: Description of BOQ Table's Structure 3. Table 9-3: Main System Components and Services 4. Table 9-4: Services during the Service and Maintenance Period 5. Tables 9-5 - 9-9: Production AMHS Central System - Detailed

Breakdown of System's Components – [Stage 1] 6. Table 9-10: Production AMHS Central System – AMHS System

Certification – [Stage 2] 7. Table 9-11: Spare Parts and Test Equipment 8. Table 9-12: Documents 9. Table 9-13: Training Courses 10. Table 9-14: Option 1 - DRP Center / 3rd Leg

b. Each component in these tables can be purchased separately as an option

during the system's life span.




c. Each component in these tables shall include the proper license and or registration.

d. The sum of the total costs of each component in the tables shall be equal or less than the cost of the total system as a whole.

9.1.4 The Tables Structure

a. The following tables' structure incorporates the following columns:

Table 9-1: BOQ Table's Structure




b. Following comments to each column's content:

Table 9-2: Description of BOQ Table's Structure




9.2 Setting Up the System

1. All tables in clause 9.2.3 and 9.2.4 below refer to the table in clause 9.2.1 is a sample of a מתחת For example the table in clause 9.2.3.1) .מתחתpossible breakdown of entry 1.1 in the table – Scope of setting up the System in clause 9.2.1 מתחת) .

2. The table in clause 9.2.1 מתחת is for information solely. The Bidder shall not respond to that table; however, if the Bidder's table in its response to Section 10.3.2 of Appendix D includes more rows than this table, the Bidder shall add them here and shall provide their break down accordingly.

3. The Bidder shall fill-in each required entry in all tables, in clauses 9.2.3 .מעל exactly according to the guidelines in clause 9.1.1 ,מתחת

9.2.1 Scope of Setting up the Complete System

# Component RFP

Technical Reference

The Proposed

ComponentUnit Quantity IAA Comments

Bidder Comments

1 Systems / Modules / Core Application

1.1 Production AMHS/AFTN Central System - Stage 1

Chapter 2, 3, 4, 5, 6

Complete 1

1.2 Production AMHS/AFTN Central System - Stage 2

Chapter 5 (5.2)

1.3 AMHS/AFTN Testing and Integration System

Chapter 2, 3, 4, 5, 6

Complete

1

Including:

Bidder's Communication Network

Main Technical Management System

Backup Technical Management System

System Operational Management System

1.n Other

2 Work Stations




# Component RFP

Technical Reference

The Proposed


Bidder Comments

2.1 Application Administrator Working Position

Chapter 3, 4, 6

Workstation2

2.2 Operator Working Position

Chapter 3, 4, 6

Workstation6

2.3 UAT Working Position

Chapter 3, 4, 6

Workstation40

2.4 Any License/Site License

2.n Other

3 Networks Connectivity and Gateway capabilities

3.1 AFTN Network Interface

Chapter 5

Complete 1

Full capability to have one or more AFTN network interface

3.2 CIDIN Network Interface

Chapter 5 Complete 1 Full capability to have one or more CIDIN network interface

3.3 AMHS Network Interface

Chapter 5

Complete 1

Full capability to have one or more AMHS network interface

3.4 PENS Network Interface

Chapter 5

Complete 1

Full capability to have one or more PENS network interface

3.5 WMO Network Interface

Chapter 5

Complete 1

Full capability to have one or more WMO network interface

3.n Other

4 Interfaces

4.1 AIS (Current) Interface

Chapter 5 Complete 1

4.2 AIM (Future) Interface


4.3 AODB / CHOCS Interface


4.4 EFS/IODS Interface Chapter 5 Complete 1

4.5 ASMGCS Interface Chapter 5 Complete 1

4.6 EWAM Interface Chapter 5 Complete 1

4.7 VOLMET/ATIS Interface


4.8 TelePC Interface Chapter 5 Complete 1




# Component RFP

Technical Reference

The Proposed


Bidder Comments

4.9 UAT Interface Chapter 5 Complete 1 Will allow connection to the 40 remote working stations

4.10 Management Interface Chapter 5 Complete 1

4.11 Meteorology (IMS) Interface


4.n Other

5 Services The Services, including any service that is needed to supply IAA a complete turnkey solution, whether it is mentioned explicitly or not at the relevant clauses in the technical appendixes. Items already proposed above, should not be included in the services listed below.

5.1 Project Management Chapter 7, 8

Complete 1

5.2 Installation and Integration

Chapter 7

Complete 1

Clause 9.2.3.1 bellow Clause 9.2.3.2 bellow

5.3 System Tests Chapter 3, 4, 5, 6

Complete 1

Clause 9.2.4 bellow

5.4 Documentation Chapter 7

Complete 1

Clause 9.2.4.1 bellow

5.5 Training Chapter 7

Complete 1

Clause 9.2.4.2 bellow

5.6 Additional Project Activities and / or Deliverables by the Bidder

5.7 Service and Maintenance during the interim period

Chapter 8

Complete 1 Clause 9.2.2

5.8 Service and Maintenance during the warranty period

Chapter 8

2 Years 1 Clause 9.2.2

5.9 Service and Maintenance after the warranty period

Chapter 8

Years 10 Clause 9.2.2

5.n Other

Table 9-3: Main System Components and Services

Remarks:

The column "Comments and References" - The clause(s) that are mentioned in this column shall not be considered to be exhaustive.




9.2.2 Services during the Service and Maintenance Period

After the Warranty Period, during the Service and Maintenance Period, the bidder shall provide the required services to maintain the system and to support the IAA staff as described in chapter 8 sections 8.4.4 and 8.4.5.(P)

1. IAA's technical team will perform the Level-1 and Level-2 support and maintenance, augmented as needed by the bidder's remote support center and access via a VPN remote access to the system to address problems. During this period the bidder shall perform all needed software and hardware upgrades. For these services the bidder will be entitled to an annual fixed price payment.(P)

2. The repair of faulty units shall be at the bidder's laboratories on a Time and Material basis. The bidder will be paid for the actual work hours spent to repair of the faulty unit. For the materials IAA will be charged as per the current spare part price list, less 10%. (P)

3. During the Service and Maintenance period, in case there is a need for a technical expert to attend the site in Israel, the bidder shall plan for a typical visit for 5 working days. In case an extension of such visit is required , an additional payment will be made accordingly.(P)

# Component RFP

Technical Reference

The Proposed

ComponentUnit Quantity

IAA Comments

Bidder Comments

1 Service and Maintenance period

1.1 Annual payment for remote support via remote VPN access and SW&HW update and upgrades

See 9.2.2-1above

Complete 1

See 19.2 at contract

1.2 Repair of faulty units – hourly rate

See 9.2.2-2 above

Working Hours

1

1.3 5 days maintenance visit in Israel not including travel and accommodation expenses

See 9.2.2-3 above

Complete 1 See 18.3.3 at contract

1.4 Additional working day in Israel

See 9.2.2-3 above

Working day

1

1.n Other

Table 9-4: Services during the Service and Maintenance Period




9.2.3 System Related Components

Detailed BOQ and Setting-Up the Complete System – System Related Components.

9.2.3.1 Production AMHS Central System – Stage 1

The following is an example of a breakdown of entry 1.1 from the table 9-3 at clause 9.2.1. In each table The Bidder shall specify all the relevant components that would be delivered to IAA.

9.2.3.1.1 Software Modules / Subsystems / Core Application – Directly Supplied by the

Supplier

# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1 COTS Modules

1.1 AMHS Application


1.1.1 AFTN Module

1.1.2 AMHS Module

1.1.3 Routing Management Module

1.1.4 Converting Management Module

1.1.5 Queue Management Module

1.1.6 Connection Management Module

1.1.7 User Management Module

1.1.n Other

1.2 UAT Application Chapter 3 Complete1

Can support at least 40

connections

1.2.1 Form Management Module

1.2.2 Addresses Management Module

1.2.n Other




# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1.n Other

2 Dedicated Applications for IAA Specific Requirements

2.n Other

Table 9-5: Production AMHS Central System - Software Modules / Subsystems / Core Application

9.2.3.1.2 Hardware Components – Directly provided by the selected Bidder

# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1 Main AMHS Central System

1.1 Primary Server Site

Chapter 2, 6

Complete 1

This will include details of all related hardware for this site (like Routers, Storage, Information Security systems, etc.).

1.2 Secondary Server Site

Chapter 2, 6

Complete 1

This will include details of all related hardware for this site (like Routers, Storage, Information Security systems, etc.).

1.n Other

n Other

n.n Other

Table 9-6: Production AMHS Central System - Hardware Components




9.2.3.1.3 3rd Party COTS Software Products

# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1 DB

2 Server's Operation System

3 Client's Operation System

4 Information Security System

n Other

Table 9-7: Production AMHS Central System - 3rd Party COTS Software Products

9.2.3.1.4 3rd Party COTS Hardware Products

# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1 Servers

2 Work Stations

3 Peripherals

n Other

Table 9-8: Production AMHS Central System - 3rd Party COTS Hardware Products

9.2.3.1.5 Customer Furnished Equipment (CFE)

Involvement of the Bidder in Accompanying, Guiding, Controlling and Approving of the CFE and other supplies by IAA, such as: interfacing system is stipulated in clause 7.3.11.

# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1 IT & Computer rooms

1.1 Cables (such as: communication, power, etc.)

1.2 Jumpers

1.3 Patch Panels

1.4 Sub-construction kits




# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1.5 Internal LAN Switches

1.6 Converters

1.7 Electrical supply including UPS

1.n Other

Table 9-9: Production AMHS Central System - CFE

9.2.3.2 Production AMHS Central System – Stage 2

The following is an example of a breakdown of entry 1.1 from the table 9-3 at clause 9.2.1. The Bidder shall specify all the relevant elements that would be delivered to IAA

# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1 AMHS Conformance Tests Documentation

5..2

Complete 1

2 AMHS Interoperability Tests Documentation

5..2

Complete 1

3 Pre-Operational Tests Documentation

5..2 Complete 1

n

9-10: Production AMHS Central System – AMHS System Certification

9.2.3.3 AMHS Testing and Integration System

The Bidder shall provide the same breakdown as in clause 9.2.3.1 מעל including a connection to the Production System.




9.2.4 Spare Parts and Test Equipment

Spare parts according to clause 8.4.1 and test equipment according to clause 8.4.4 and chapter 5

# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1 Spare Parts

1.1

1.2

1.n

2 Test Equipment

2.1

2.2

2.n

Table 9-11: Spare Parts and Test Equipment

9.2.4.1 Documentation

See clause 7.3.9.

At this table The Bidder shall include and specify all necessary documents that would be delivered to IAA. In the table below there are some examples of such documents:

# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1 Project's Life Cycle Documents

Complete 1

2 System's Documentation

Complete 1

3 User Manuals Complete 1

4 Training Materials Complete 1

n Other

Table 9-12: Documents

9.2.4.2 Training Courses

See clause 7.3.8.

At this table The Bidder shall include and specify all possible training that it can offer to IAA at Bidder's Facility and at IAA site (Israel). In the table below there are some examples of such training:




# Component RFP

Technical Reference

The Proposed


IAA Comments

Bidder Comments

1 AMHS Operator Expert (Trainer) –

Complete 1

2 AMHS Operator – Training Course

Complete 1

3 AMHS UAT Expert (Trainer)

Complete 1

4 AMHS Technical Expert

Complete 1

n Other

Table 9-13: Training Courses




9.3 Option 1 – DRP – Third Leg

9.3.1 General

As part of the IAA DRP, a third leg will be needed for the AMHS system. The Bidder shall refer to Section 7.1.3 of Chapter 7 of the Technical Requirements.

9.3.2 Scope of Option 1

# Component RFP

Technical Reference

The Proposed


Bidder Comments

1 Systems / Modules / Core Application

1.1 DRP Main AMHS/AFTN System

Chapter 2, 3, 4, 5, 6

Complete 1

1.n Other

2 Work Stations AS IN TABLE 9-3

3 Networks Connectivity and Gateway capabilities AS IN TABLE 9-3

4 Interfaces AS IN TABLE 9-3

5 Services AS IN TABLE 9-3

Table 9-14: Option 1 – DRP

9.3.3 System Related Components

Detailed BOQ of Setting-Up the Complete System – System Related Components

The Bidder shall provide the same breakdown as in clause 9.2.3 מעל.

9.3.4 Labor Related Components

Detailed BOQ of Setting-Up the Complete System – Labor Related Components

The Bidder shall provide the same breakdown as in clause 9.1.1.




Annex 1-A - Terms & Abbreviations




Annex 1-A – Terms & Abbreviations

Abbreviation Definition

ACC Area Control Center ACL Access Control List ADEP/ADES Aerodrome of Departure/DestinationADEXP ATS Data Exchange PresentationADMIN Administrator AFSG Aeronautical Fixed Service Group [ICAO]AFTN Aeronautical Fixed Telecommunication NetworkAIC Aeronautical Information CircularAIMS Airport Information Management SystemAIS Aeronautical Information ServicesAIM Aeronautical Information Management AMC ATS Management Center / Aeronautical Messaging CenterAmd. Amendment AMHS Air Traffic Service Message Handling SystemAODB Airport Operation DatabaseAOR Area Of ResponsibilityARO After Receipt of OrderAPI Application Program InterfaceA-SMGCS Advanced Surface Movement Guidance and Control SystemATC Air Traffic Control/ControllerATCC Air Traffic Control CenterATCO Air Traffic Control OperatorATFCM Air Traffic Flow and Capacity Management [CFMU]ATIS Automatic Terminal Information ServicesATM Air Traffic ManagementATN Aeronautical Telecommunication NetworkATP Acceptance Tests Procedures / PlanATR Acceptance Tests ReportATS Air Traffic Services ATSC Air Traffic Services CentreBGN Ben-Gurion International AirportBidder As defined at the Invitation to Bid document clause 4.1.BITE Built-In Test EquipmentBOQ Bill of Quantities C/S Call Sign CAA Civil Aviation AdministrationCAAS Common AMHS Addressing SchemeCAT Category CDM Collaborative Decision MakingCDR Critical Design ReviewCFE Customer Furnished EquipmentCFMU Central Flow Management UnitCIDIN Common ICAO Data Interchange NetworkCMP Configuration Management PlanCNS Communication, Navigation, SurveillanceCOC Certificate of Compliance





COTS Commercial Off The ShelfCMM Control, Management and MonitoringCRT Choice Reaction TimeCS Community SpecificationsCSV Comma-separated valuesCTOT Calculated Take-Off TimeCV Curriculum Vitae / RésuméCVFR Controlled Visual Flight RulesCWBS Contract Work Breakdown StructureDB Database / Data base DCE Data Communications EquipmentDDR Detailed Design ReviewDMAN Departure Management (system)DOB Date of Birth DOF Date of Flight DRP Disaster Recovery PlanDSR Deliverables Supply ReviewDTE Data Terminal EquipmentEAD European AIS DatabaseECG URD European Communications Gateway User Requirements Document ED EUROCAE DocumentED or Ed Edition EFS Electronic Flight Strip System

An Electronic Flight Strip System ("Frequentis Smart Strips System"). EGIS EUROCONTROL Guidelines for Implementation SupportEHS Environmental, Occupational Health and SafetyEMI Electromagnetic InterferenceEMR Electromagnetic RadiationEOBT Estimated Off Block TimeETA/ETD Estimated Time of Arrival/DepartureEU European Union EUR Europe or European EUROCAE European Organization for Civil Aviation EquipmentEUROCONTROL European Organization for the Safety of Air Navigation

EWAM Eilat Wide Area MultilaterationFAT Factory Acceptance TestFDE-ICD Flight Data Exchange protocol FDM Flight Data Message FIR Flight Information RegionFIS Flight Information ServiceFMTP Flight Message Transfer ProtocolFPL Flight Plan Message (ICAO format)FS Flight Strip GFE Government Furnished Equipment GPS Global Positioning SystemGUI Graphical User InterfaceHDLC High-level Data Link Control procedureHLD High Level Design





HMI Human-Machine InterfaceHTML Hypertext Markup LanguageHTTPS Hyper Text Transfer Protocol over Secure Socket Layer (SSL) HW Hardware I/O Input / Output IAA Israel Airports AuthorityICAO International Civil Aviation OrganizationICD Interface Control DocumentIFR Instrument Flight RulesIHLD Interface High Level DesignILS Instrument Landing SystemIODS Integrated Operational Data System

Integrated Operation Data System supplied by Frequentis. IP Internet Protocol IRD Interoperability Requirements DocumentIRS Interface Requirements SpecificationsIRR Installation Readiness ReviewISO International Standards OrganizationKt KnotsLAN Local Area Network LAPB Link Access Protocol, BalancedLCC Life Cycle Cost LDAP Lightweight Directory Access Protocol LRU Line Replaceable UnitMET Meteorology / MeteorologicalMETAR Aerodrome routine meteorological report (in meteorological code form) MHz Megahertz MIB Management Information Base (SNMP)MIL Military MIMO Multiple-input and multiple-output.MLAT Multilateration MMT Mean Maintenance TimeMOPs or MOPS Minimum Operational Performance SpecificationMS Microsoft MSSR Mono-pulse SSR MTBCF Mean Time Between Critical FailureMTBF Mean Time Between FailureMTTR Meantime To Repair NAV/ NavAids Navigation Aids NM Nautical Mile NOTAM Notices to Airmen NTP Network Time ProtocolOCR Operational Concept ReviewOLDI On Line Data InterchangeOOTB Out Of The Box OPS Operational or/and OperationsOPMET Operational Meteorological (information)OS Operating System





PD Project Directorate PDF Portable Data FormatPDR Preliminary Design ReviewPENS Pan European Network ServicePEPR Project Execution Plan ReviewPM Project Manager / Preventative MaintenancePMP Project Management PlanPMR Project Management ReviewPMI Project Management Institute, inc.PRFPL Permanent Repetitive Flight Plan [CFMU]PVC Permanent Virtual Circuit QA Quality Assurance QAP Quality Assurance PlanQNH Atmospheric pressure at Nautical HeightRAD Risk Analysis DocumentRAS Resource Allocation System (Parking Position Management) RDBMS Relational database management systemRMA Reliability, Maintainability, and AvailabilityRMP Risk Management PlanRPL Repetitive flight PlanRRD Revised Requirement DefinitionRWY Runway SAN Storage Area NetworkSAR System Architecture ReviewSARPs Standards and Recommended PracticesSAT Site Acceptance TestSDP System Development Plan / Service Delivery Plan / Surveillance Data Processing

SER Sight Engineering ReportSES Single European SkySESAR Single European Sky ATM Research ProgramSFF Small Form Factor SID Standard Instrument DepartureSITA Air communication & information company/networkSLA Service Level AgreementSNMP Simple Network Management ProtocolSOAP Simple Object Access ProtocolSORR Soak Readiness ReviewSOW Scope Of Work SP Service pack SPI Special Purpose Indicator [SSR]SPOC Single Point Of ContactSRR System Requirements ReviewSRS System/Software Requirements SpecificationsSSR Secondary Surveillance RadarSTD System/Software Test DescriptionSVC Switched Virtual Circuit SW Software





T.O. Take-Off TCP Transmission Control ProtocolTCP/IP Transmission Control Protocol Internet ProtocolTCS Test Case Scenario TLV Tel Aviv TMA Terminal Maneuvering AreaTRACON Terminal Radar Approach ControlTRR Test Readiness ReviewTT Project's Technical TeamTWR TowerTWY Taxiway UA User Agent UAT User Agent TerminalUTC Universal Time CoordinatedVFR Visual Flight Rules VHF Very High FrequencyVIS Visibility condition VLAN Virtual LAN VM Validation/Verification MatrixVMC Visual Meteorological ConditionsVOLMET Meteorological Information to Aircraft in FlightVOR VHF Omni-directional RangeVPN Virtual Private NetworkVRTM Verification Requirements Table MatrixWAN Wide Area Network WIMP windows, icons, menus, and pointersWGS-84 World Geodetic Survey (1984)WMO World Meteorological OrganizationWP Working Position WS Workstation X.25 Interface definition between DTE and DCE for synchronous operation on public data

networks X.400 Common name for set of standards specifying the Message Handling System (MHS).




Annex 1-B - Applicable Standards




Annex 1-B – Applicable Standards

1. ICAO Doc 9880, Manual on Detailed Technical Specifications for the Aeronautical

Telecommunication Network (ATN) using ISO/OSI Standards and Protocols, 1st

Edition, 2010

2. ICAO DOC 005 EUR CIDIN Manual, 6th Edition, 2011

3. ICAO Annex 10, Volume I, Volume II, 6th Edition October 2001.

4. ICAO Annex 10, Aeronautical Communications, Volumes III, 2nd Edition

5. Type B Service Reference Manual, January 2000

6. ISO/IEC 8473 Protocol for providing the Connectionless-mode Network Service.

7. ISO/IEC 8073 Connection-oriented transport protocol specification.

8. ISO 8602 protocol for providing the Connectionless-mode Transport Service.

9. CCITT Recommendation X.400 (1999), Message handling system and service

overview.

10. CCITT Recommendation X.402 (1999), Message handling systems: Overall

architecture.

11. CCITT Recommendation X.411 (1999), Message handling systems: Message transfer

system: Abstract service definition and procedures.

12. CCITT Recommendation X.413 (1999), Message handling systems: Message store:

Abstract-service definition.

13. CCITT Recommendation X.420 (1999), Message handling systems: Interpersonal

messaging system.

14. ISO/IEC 9594-1:1993 / ITU-T X.500 (1993) Information technology — Open Systems

Interconnection — The Directory: Overview of concepts, models and services.

15. X.501 ISO/IEC 9594-2 The Directory: Models ISO/IEC 9594-2

16. X.511 ISO/IEC 9594-3 The Directory: Abstract service definition

17. X.518 ISO/IEC 9594-4 The Directory: Procedures for distributed operation

18. X.519 ISO/IEC 9594-5 The Directory: Protocol specifications

19. X.520 ISO/IEC 9594-6 The Directory: Selected attribute types

20. X.521 ISO/IEC 9594-7 The Directory: Selected object classes

21. X.509 ISO/IEC 9594-8 The Directory: Public-key and attribute certificate frameworks

22. X.525 ISO/IEC 9594-9 The Directory: Replication




23. X.530 ISO/IEC 9594-10 The Directory: Use of systems management for administration

of the Directory

24. EUROCONTROL SPECIFICATION on the Air Traffic Services Message Handling

System (AMHS), 2nd Edition

25. ICAO - EUR AMHS Manual (EUR DOC 020), Latest Edition

26. ICAO - ATS Messaging Management Manual (EUR DOC 021), Latest Edition

27. ICAO - AFS Security Guidelines (EUR DOC 022), Latest Edition

28. ICAO - AMHS COM Centre Training Guidelines (EUR DOC 026), Latest Edition

29. ICAO - IP Infrastructure Test Guidelines for EUR AMHS (EUR DOC 027), Latest

Edition

30. CCITT X.25 Recommendations (1984, 1988)




Annex 1-C – Technologies at IAA




Annex 1-C – Technologies at IAA

1. General

1.1. General Characteristics

The purpose of this Annex is to define and present the technological standards and

the existing implemented technologies at the IAA, in the perspective of hardware,

communication systems, personal computers, peripherals, software and information

security.

After winning the tender, the vendor is responsible for the coordination of a

preliminary meeting with the relevant technological and communication teams at

the IAA. This in order to ensure that the integration of the proposed system by the

vendor, or the proposed component are compatible with the standards in use at that

point by the IAA, as well as being compatible with its technological environment.

The summary of the technological requirements for this system as found in the

technological form, table 5, Is the table of technological requirements for the

system..

1.2. Current Situation

The computer and communication layout in the IAA are characterized by an

extremely heterogenic environment that includes diversified applications, computers

from varied manufacturers, multiple operating systems, diversified communication

protocols, and extensive and diversified passive infrastructures and network arrays.

The accepted upgrade cycle, mainly for operating systems (servers and

workstations), hardware (servers and workstations) networks and principal

applications (e.g., Biz Talk) takes place approximately every three to four years.

1.3. Systems Classification Policy

The IAA contains both operational and administrative systems:

Systems defined as “Administrative” by the IAA, will have to comply with

the following policy:

o Data: 100% data protection for the last 24 hours

o Applications: Allowed downtime interval of up to 24 hours.




Systems defined as “Operational” by the IAA, will have to comply with the

following policy:

o Data: 100% data protection on all operational data with no corruption.

Maximum allowed data loss of the last 5 minutes.

o Applications: Full System Availability, 24 hours 7days a week.

Operational systems are required to support a multi-site configuration based on

installations in two different computer rooms with a hot backup between them.

This system will be defined as an <Operational \ Administrative> System.

2. Working Environment

2.1. General Characteristics of the Existing Working Environment at the

IAA:

Workstation based on Windows 7 OS.

Around 300 Wintel based servers running Windows 2003 / 2008 / 2008R2 /

2012 R2 OS's.

2 IBM-iSeries computers installed at the BG Airport site.

Central storage systems: Two IBM DS-8800 units At the BG Airport site

with dual backup of each other, installed in both central computer rooms to

which most the servers connect, in either a single server configuration or

cluster configurations.

Local and wide area communication network based on Ethernet / TCP-IP

composing a large number of logical networks (VLANs) at the central site

and WAN and LAN networks at the remote sites.

At the BG Airport there is a Nortel/Avaya switchboard system. Includes

auxiliary system interfaces such as voice mail, call recording, queue

management systems, etc. At other IAA sites there are Tadiran switchboards

(PBX).

2.2. Environmental Infrastructure

The system is required to integrate into the IAA system infrastructure. The computer

rooms (Air Side site & Land Side) sites, are located in Terminal 3; Operational




systems and some of the administrative systems are duplicated at both sites for

increased availability. In addition, there are three (3) switchboards rooms at remote

sites, in addition to central and regional communications rooms that providing high

survivability.

2.3. Applications Types at the IAA

2.3.1. Diversified applications - These include traditional ADP and

information systems applications such as: Financial, HR management,

logistical, etc.

2.3.2. Real time applications - Real time data collection systems using

sensors and indicators, e.g. Meteorological data collection system, A

flight timetable display system, Noise monitoring system, etc.

2.3.3. Simulation systems - These systems are used for planning seasonal

flight schedules and resources allocation planning including labor and

equipment, according to the differing requirements at the airport. In

addition, these systems are used for planning passenger flow procedures

in the halls and at new border terminals.

2.3.4. Voice applications - Voice response applications providing service to

the public on various issues: Flight schedules, Parking, Pre-Flight

booking, etc. In addition, there are advanced queue management

applications, etc.

2.3.5. Geographical systems - Geographical information systems (GIS) used

as a geographic database for differing uses such as: Fire control and

detection system, Noise monitoring and residential complains, etc.

2.3.6. WEB applications – Internal and External web based systems, accessed

using a user based browser; Intranet systems, Internet and Extranet

based systems.

2.4. Main Hardware

2.4.1. The main hardware standards are as follows:

IBM-AS/400 computers - I-740 Power 7 model




IBM and HP WINTEL servers

The server replacement cycle is approximately3 to 4 years

UNIX computers – SUN and HP based servers.

Linux computers IBM and HP based servers

Central storage systems (two IBM DS 8800units in hot back-up):

Workstations from varying vendors:

o Approximately 2000 work stations.

o SFF case.

The computer replacement cycle is approximately 3 to 4 years

Telephony and related systems using different types of phones both

smart and analog.

2.4.2. Peripherals

2.4.2.1 Monitors from various vendors, with the following

specifications:

o 19” LCD - workstations - regular users

o 22” LCD - system managers.

2.4.2.2 Printers - Varying brands

o Personal B/W Laser printers

o Departmental B/W Laser printers

o Departmental Color Laser printers

o Color Plotter

2.4.2.3 Industrial scanners – Different brands

2.4.3. Infrastructure Software

2.4.3.1 Microsoft Office 2010 (or later) including all components

2.4.3.2 Internet Explorer 9 (or later).

2.4.3.3 Bossanova Secure 8.08

2.4.3.4 Microsoft IIS 8.5 (or later).




2.5. Data Storage and Backup

The IAA data storage in is centrally implemented using the following main

platforms:

2.5.1. iSeries Servers

Two I-740 Power 7 servers divided into LPAR (BG Airport).

2.5.2. DS System

DS8800 based hardware. The system utilizes two physical units

configured in full redundancy. The access/interface to the system is

implemented thru a SAN (Storage Area Network) based on an IBM/HP

Brocade optical switche, with 8GB network ports.

2.5.3. VNX System

Security based networks - EMC VNX 5300 System.

2.5.4. Central Backup Application

Central backup applications by IBM, based on TSM 6.2 in the central

network, VEEM Backup & Replication 7R2 in the secured networks and

Eilat site.

2.5.5. Virtual tape library

Tape Library System Storage TS7650G ProtecTIER Deduplication

Gateway by IBM based on two physical units installed in the two

computer rooms at BG airport. Integrated in the IAA solution by

allowing backup to disks that are represented as a collection of virtual

tapes to the backup server (see below). The server performs the backup

procedure and the central backup application works in combination with

the virtual tape library.

2.5.6. Central Backup Library

A central backup library, IBM Model 3584, that is used to replicate the

virtual tape library information. The physical tapes are then transported

off site to an external site.

2.6. Operating Systems

2.6.1. Microsoft:




1) Workstations: MS Windows 7 (or later above)

2) Servers:

a. Windows 2012 R2 Server Standard Edition (or later) for a

single server.

b. Windows 2012 R2 Server Enterprise Edition, (or later) for

server in a cluster configuration.

2.6.2. iSeries:

Release V7R1MO (or later)

2.6.3. UNIX:

SUN SOLARIS 10 ( or later ), LINUX, HP-UX.

2.7. Database (DBMS )

2.7.1. Microsoft Environment

MS- SQL 2012 Standard\Enterprise editions (or later)

2.7.2. AS/400 Environment

IBM-DBI5 (DB400) V7R1M0 (or later)

2.8. Development and Maintenance Tools

2.8.1. Microsoft Environment:

C#, VB.Net for client/server systems – dotNet 3.5 or later.

Intranet / Internet / Extranet systems - ASP.Net for– dotNet

3.5 or later.

Visual Studio 2008 (or later)

Team Foundation server 2013.

Microsoft Office SharePoint Server 2010 for implementing

portals, training material and document repository.

Microsoft SharePoint Designer 2010




2.8.2. AS/400 Environment:

RPG LE.

2.9. Command and Control Tools

2.9.1. HP OVO 9.1 on UNIX Systems (or later )

2.9.2. Microsoft SCCM 2007 system Note: The system is expected to be

replaced by SCCM 2012 During 2014

2.9.3. Microsoft SCOM 2012 system (or later)

2.10. Data Communication Environment

General

The data communication infrastructure of the IAA consists of a local

area network (LAN) deployed at the BG Airport (Terminals 1 and 3 and

supporting areas), and a wide area network (WAN) deployed at the

remote sites (border terminals, inland airports and air traffic control

units).

The communication infrastructure is currently managed by the

communication team of the Information and Computer Division, The

team handles all the communication aspects of the IAA.

2.10.1. Communication Network at BG Airport

The communication network backbone consists of four Cisco Nexus

c7009 switches. Two are installed in the Airside linked using a VPC

topology with a 20 Giga to two additional based in the Land side also

linked using a 20 Giga VPC.

The Core switches are divided into two VDC (Virtual Device Context):

1. VDC Data center environment for server networks.

2. VDC Core environment for Ben Gurion campus network users.

The Link between the VDCs uses a L3 communication setup with

bandwidths of 20 Giga.

The compounds are linked using 40 Giga links based on L2

communication in VDC-DC, and a bandwidth of 40 Giga for L2\L3

communications in VDC–Core.




In addition, there are two core switches the eastern support compounds

based on Cisco 6509. These are linked to the core switches of Terminal

3 at a rate of 20G (Dual 10 Giga connections). Two additional core

switches installed in the western support area based on Cisco 3750X

units, linked to the core switches of Terminal 3 at a rate of 2G (Dual 1

Giga links).

The edge switches installed in Terminal 3 and the Support Areas are

Cisco 6509 and Cisco 3560/3550 (about 120 switches) linked to the

network backbone by two Giga interfaces. One link for each backbone

switch in the same area, with a total bandwidth on an end switch of 2

Gbps. Edge switches are used to link all the systems and users (spread at

the range of the regional communication room) using copper wiring.

The communication network in Terminal 3 serves as the base

information backbone for all the information systems of the IAA, and in

addition servers a large number of external entities (franchisees), located

in Terminal 3 (airlines, retailers, government offices, etc.).

The local communication network uses several routing and survivability

protocols such as: OSPF, Spanning Tree, HSRP, and others.

2.10.2. The Wide Network

The wide area network (WAN) is deployed at 13 peripheral sites

countrywide; each site contains a local area network (LAN) linked to the

BG Airport by two Bezeq communication links , a 6 M SDH type line,

and an additional 6 M IPVPN line.

The main routers that connect the wide area communication network are

based on the Cisco 7200.

The routers installed at remote sites are based on the Cisco 1800.

The wide area communication network uses routing and survivability

protocols such as BGP4 and GLBP.

2.10.3. Monitoring Communication infrastructure

Command and Control on the communication systems is performed using

several control systems:




HP-OpenView NNM - NNM 7.53 running on HP Sun Solaris. This system

monitors all the communication components by polling the objects and

changes their representation on the network map.

Reception of SNMP Traps from the communication equipment, Status

changes according to the event and displaying all the messages on the

Alarm Categories window.

As a rule, the NNM system is used as a MOM for the entire

communication's C2 layout and all the messages from the sampled systems

converge into it.

In addition to the local and the wide area networks, the C2 system also

monitors the low voltage systems (gateways control, CCTV, and AC) as

well as the telephony system. The system includes dedicated maps for every

system to which various system managers (some of whom do not belong to

the personnel of the Information and Computer Division) are granted access

to the central C2 system to observe the systems that they manage.

Cisco Works 4 – This system is used for C&C over Cisco based

communication equipment. This system enables the reception of additional

data that is not received from the overall control system (OpenView).

This system includes most of the existing modules (e.g. RME, LMS, DFM,

RWAN, and ACL Manager). Using these modules it is possible to manage

the Cisco components at the highest level and to receive as much

information as possible regarding the status of the communication network.

2.11. Communication Systems

2.11.1. The telephony layout at BG Airport is based on Nortel/Avaya

switchboards deployed at three central sites, and which constitute a

single logic network, so that there is a single numbering plan,

homogeneous characteristics and a common back-up and survivability

layout, with a link to the public network (PSTN and cellular providers).

The switchboards are based on the Meridian C with about 4500 active

extensions.




The switchboards work with auxiliary systems such as Symposium, Call

Pilot, OT, Mind based call recording.

The link between the switchboards is based on PRI over an SDH ring.

The end point telephones are Nortel Taurus (3904/3), as well as different

normal (analog) telephones.

At BG Airport, there are seven call centers currently based on the

switchboard and Symposium.

Following are the main components:

Nortel switchboards version 7.5/7.6

Nortel Symposium version CCT-6.

Nortel Call Pilot version 6.

Aspire SFDA component which enables real time reports and

serves as an interface to an external database.

The other IAA sites use various Tadiran switchboard (PBX). models.

The telephony systems (including the Symposium system and the switchboard) are

maintained and managed by a Network Operator (Network Termination Point-

"Neser"), presently Netvision, and by its sub-contractors such as Mind and Aspire.

2.11.2. Wireless Internet Network

There is a wireless network in operation at the BG Airport, Eilat

Airport, Taba Terminal, Sde Dov Airport and Haifa Airport in order to

allow Internet access for the public which is supplied by the 013

Netvision.

The wireless networks consist of Aironet 1100, 1200 access points

deployed in public locations in the above-mentioned airports and

terminals.

The wireless network at Terminal 3 is managed by a Cisco WELSE

wireless management system.

2.11.3. Link to the Internet Network

The connectivity to the Internet is done using two point-to-point lines to

Internet providers, Golden Lines and Netvision. Linking routers operate




the BGP4 routing protocol. The IAA has an independent AS Number

distributed by both Internet providers for the sake of survivability.

2.11.4. IVR - Interactive Voice Response

The IVR has several modules flights arrival and departure, passenger

information, work schedule, suppliers, etc. based on the Nortel (MPS-

500). The system is fully redundant, including the communication to the

public network (PSTN).

2.11.5. Passive Infrastructures

The passive infrastructure at BG Airport is based on optical cabling and

metal binding.

In Terminal 3 there is a uniform infrastructure for the end points.

Furthermore, uniform infrastructure is being deployed in stages to other

areas of the campus.

All passive infrastructures at the BG airport, with a few exceptions, are

owned by the IAA.

The BG Airport Campus is connected to all the regional communication

rooms, which enable the delivery of infrastructure to all the campus.

At other sites, there is a passive infrastructure, based on at least one

central communications room and, optical cabling and metal binding.

At new or upgraded sites, the desire is to deploy a uniform infrastructure

for end points.

2.12. Additional Technologies

Inter system integration - EAI compliance to Microsoft BizTalk 2010 (or

later), which implements communications between various systems in the

IAA as well as systems external to the IAA, by using services and sending

one, or two way messages between source and target systems.

Citrix XenApp 6.5 – For the purpose of accessing information systems at the BG Airport from remote sites and for users that are outside the organization

A secure access system for organization users and suppliers based on

digital certificates and OTP mechanisms.




Cyber Ark System - virtual "safes" for internal and external use for

transferring information up to the classification level of "Confidential".

Virtual Servers Infrastructure – based on VMware Vsphere 5.1.

Email Infrastructure – Microsoft Exchange 2010

Load Balancing Mechanism – based on the Cisco Ace, for load balancing

in the IAA server farms.

Fax Server – MESSAGE Manager Server software

o NAS – Netapp Data ONTAP Release 8.1.2P1 (N6040G) – serves as a gateway for the central storage system, as described above.

2.13. Extranet Environment

IAA Internet web site environment:

o Content servers based on Microsoft CMS platform

o Microsoft SQL 2005 servers

Note: The IAA Internet site is expected to migrate to hosting services during

2014. The current site will be removed.

Extranet service environment:

o Microsoft IIS servers version 6 (or later)

o Microsoft SQL servers 2008 (or later)

3. Information Security

IAA defines the information and applications security issue, as both substantial and

mandatory in every case in which a computer based system is connected to the IAA

network, regardless the location of the connection or its configuration.

IAA requires that all vendors who win tenders which contain a need for information

security aspects, to comply with the following criteria and all the definitions of

information security as defined, according to the instructions that will be issued by the

Information and Computer Division and the persons in charge of information security

at IAA.




In case the response require changes in which the costs differ from those defined in

the agreement signed with the vendor, these issues will then be discussed and

finalized separately with the vendor. In addition, the vendor should understand that it

may be required to meet classification standards for its employees who may have

connection to classified computer systems. If so required, it is the vendor's sole

responsibility to provide its employees with the required classification before they

will be be granted access to the systems.

Operating System – The vendor is to comply with all standards accepted in the field

for systems security in regards to versions, revisions and information security updates,

as is required, according to the IAA's decision which will be made from time to time.

It is the vendor’s sole responsibility to carry out any update as requested by IAA if the

IAA considers the update necessary.

Protocols – The vendor is required to verify they use only standard communication

protocols for any type of connectivity between systems, for example: when executing

FTP activity it is mandatory to use formats defined for FTP in the appropriate RFI.

Any use of protocols or communication ports different from internationally known

and approved standard will require the approval of the person in charge of the

information security at the IAA. The IAA does not undertake to approve any protocol

that is not standard or that IAA considers harmful or risky for the existing systems.

Anti Virus – The supplier/vendor must ensure that the supplied/suggested/offered

system contains an Anti-virus / Anti-Spam /Protection mechanism which includes a

mechanism to block the use of external hard drives (DOK's, Disk, USB's etc.). This

parameter is an obligatory parameter. It is the suppliers duty to define an update

mechanism for these systems as well as a management tool for configuring and

overseeing the operation of these tools.

Note: A vendor requested by the IAA to support IAA's systems from his corporate

offices, will be granted authorization based on the submission of an appropriate

request to the person in charge of the information security at IAA. Approval of such

communication requests will be based upon the actual need.




It should be noted that the IAA does not undertake to approve any remote access to

the system, therefore only requests complying with the conditions of the IAA, will be

inspected.

4. IPV6

The IAA operates in accordance with international standards in connection with

communication protocols, umongst them, the support of IP protocols IPV4 and IPV6.

In accordance with this, when it becomes apparent that IPV6 is becoming a de-facto

standard in the world, the IAA will begin a slow integration of this protocol into its

systems, it's communication equipment and all connectivity necessary to support this

protocol.




Annex 1-D - IAA's Quality Assurance Guide Lines




Annex 1-D – IAA's Quality Assurance Guide Lines 1. General

Software quality assurance refers to the activities required for assuring the quality of computer software, as part

of the project management processes, and the system development and maintenance processes.

These activities refer, inter alia, to the following fields: quality assurance, documentation, testing and

information security.

This Annex sets out the quality assurance activities required for the Project. These activities will be

summarized and prescribed in the quality assurance plan submitted by the provider and revised along the

progression of the Project (see below for more details).

2. Involved Parties

Provider's quality assurance, testing and information security representatives for the Project:

The provider shall appoint a person from the Project team as the Quality Assurance Officer and as the

contact person with the manager of the testing center of CIS (Computer and Information Services) / the

Israeli Airports Authority in this field.

The provider shall appoint a person from the Project team as the Testing Officer and as the contact person

with the manager of the testing center of CIS / Israeli Airports Authority in this field.

The provider shall appoint a person from the Project team as the Information Security Officer and as the

contact person with the manager of the testing center of CIS / Israeli Airports Authority in this field.

A single member of the Project team may fill more than one of the above positions.

3. Quality Assurance

3.1. Quality Assurance Activities

The provider's quality assurance activities shall include, inter alia, the following:

Reviews throughout the project. The provider shall send a summary of each review to the Israeli Airports

Authority on a regular basis, in accordance with the work plan.

Progress tracking – status report at a frequency set out and prescribed in the project management plan (see

Section 3.2 below).

Risk management – see Section 4.5.10 of the Technical Specification.

Quality gates – activities and criteria for passing from stage to stage in the life cycle.

The quality assurance and testing activities shall be prescribed by the provider in the project management and

quality assurance plan, as specified in Section 3.2 herein and shall be defined in the project's work plan.




3.2. Deliverables of the Quality Assurance Activities

The provider shall present the following quality deliverables:

a. The project management and quality assurance plan, including inter alia:

1) Definition of the life cycle according to which the project shall be managed

2) Methodology

3) Main milestones

4) Organizational structure of the provider's project team, including the quality assurance personal

involved in the project on behalf of the provider

5) Persons involved on behalf of the Israeli Airports Authority

6) The method of the control implemented by the provider

7) Status discussions and periodic discussions

8) Status report and progress report

9) Definition of work teams and steering teams

10) Specification of the provider's work interfaces with the Israeli Airports Authority, including the

quality assurance interfaces

11) The method of managing changes during the development

12) Launch methodology

13) Project deliverables table

14) Reviews (specification of all the planned reviews, their purpose, involved parties, schedule and

the deliverables of each review)

15) Quality gates

16) The definition of the testing procedures

17) Terms, acronyms and glossary

18) Required documentation, as specified in Section 4 below

19) Binding provisions and procedures

b. Detailed work plan

c. Risk management plan

d. Documentation of development deliverables as specified in detail below

4. Documentation

The documentation shall be in Hebrew. The submission of documentation in any other language shall be

subject to the written approval of the project manager on behalf of the Israeli Airports Authority.

The documents shall be submitted in Microsoft Office Word format in the current version used by the

Israeli Airports Authority at the time of submission. The submission of documents in other formats (such

as PDF) shall be subject to the written approval of the project manager on behalf of the Israeli Airports

Authority.

The documents shall be submitted to the Israeli Airports Authority via magnetic media, and printed in a




number of copies to be determined by the Israeli Airports Authority.

Current copies of the deliverables shall be submitted to the Israeli Airports Authority on a regular basis as

agreed between the provider and the Israeli Airports Authority as well as upon request.

The provider shall submit the following documentation to the Israeli Airports Authority:

a) The development deliverables, including:

Full and detailed technical documentation, hardware and software, for the products comprising

the solution, including information security and command and control products

The system requirement specification documents, including a table defining and illustrating the

connection between the system requirements, and the specification clauses (traceability matrix)

System (logical and physical) architecture document

Change requests

The testing documents [System Test Plan – STP, System Test Directive – STD, System Test

Review – STR]

A reference table defining and illustrating the connection between the system requirements, and

the specification clauses (traceability matrix)

Source code of software and interfaces developed for the Israeli Airports Authority as well as

documentation of this code. It is hereby clarified that the provider is responsible for

documenting the code in the body of the code, in accordance with the documentation rules

applicable to the software tool with which the code is written. The provider shall present to the

Israeli Airports Authority the documented code for approval.

Documentation of the systems developed for the Israeli Airports Authority – documents, code,

etc.

Detailed "system file" including screenshots developed by the provider for the Israeli Airports

Authority

System installation documents and setup program

The training and implementation plans

User manuals for each of the systems provided as part of the solution and a general user manual

including all the adjustments and changes made.

Operational Guide for the use of IAA Helpdesk (MESSER) according to a template that shall be

provided by the Israeli Airports Authority prior to the detailed software requirement

specification stage

Operation and documentation manuals for the system administrators and support staff

b) The project management deliverables shall include:

Discussion summaries

Review summaries

References to purchased licenses




5. Tests

5.1. General

Testing shall be carried out at three levels:

o Development level – at the provider's premises

o Testing level – at the provider's premises and at the Israeli Airports Authority site

o Production level – at the Israeli Airports Authority site

The provider is responsible for all the testing, at the three abovementioned levels, as defined and

approved in the System Test Plan.

The provider shall provide the Israeli Airports Authority with the System Test Plan, System Test

Directive and System Test Review documents on a regular basis and in accordance with the work plan.

The Israeli Airports Authority reserves the right to be involved and present in the testing processes, both

at the provider's premises and at the Israeli Airports Authority site.

The Israeli Airports Authority reserves the right to change and/or add additional tests on its behalf, both

at the provider's premises and at the Israeli Airports Authority site. If needed, the Israeli Airports

Authority is entitled to employ an external professional on its behalf for this purpose.

The professionals and application expert on behalf of the Israeli Airports Authority will be integrated as

required for the correct and continuous performance of the tests. The extent of the support and the

professionals involved on behalf of the Israeli Airports Authority will be agreed upon with the provider

and prescribed in the approved System Test Plan.

5.2. Administration of System Tests

The tests shall be conducted after obtaining the final approval from the Israeli Airports Authority.

The certificate of delivery – shall be given to the provider for the final configuration of the system,

at the production level, after the completion of the tests and the approval of the Israeli Airports

Authority.

5.3. Tests Required from the Provider

Secure code control [the secure code control requirements are specified in Section 5.4 below]

Unit test at module level (screen, file, etc.)

Sanity test – required in every round of tests

Functional tests (menus, data correctness, GUI, etc.) and process tests

User friendliness test

Performance tests (response times)

Integration and interface tests

Reports and data correctness




Failure and recovery tests

Load tests (if required and defined in the technical document), using a designated tool simulating a

high amount of users such as Load Runner, Web Load, etc.. The tool, the maximum amount of users

and other parameters shall be determined and specified in the System Test Plan.

Integrative test run

The extent, depth and type of tests required from the provider shall be agreed upon, approved and

prescribed in the System Test Plan.

5.4. Special Tests

5.4.1. Security Information Requirements Compliance Tests

1. The final approval of the system configuration, as presented by the provider at the detailed

software requirement specification stage, is subject to the approval of the person assigned to

information security on behalf of CIS / the Israeli Airports Authority.

2. As part of the acceptance tests conducted at the Israeli Airports Authority site, the compliance

with the information security requirements, as defined in the Technical Requirements, shall also

be tested.

3. Compliance with the information security requirements shall be tested by and under the

responsibility of the information security team of CIS / the Israeli Airports Authority. As needed,

the Israeli Airports Authority may employ external expert consultants.

4. All the information security requirements compliance tests shall be kept by and under the

responsibility of the information security team of CIS / the Israeli Airports Authority.

5. Operating the system at the production level is subject to the approval of the person assigned to

information security on behalf of CIS / the Israeli Airports Authority for:

a) Compliance with all the information security requirements, as defined in the Technical

Requirements;

b) Implementation of secure code control, if required.

6. The approval of the person assigned to information security on behalf of CIS / the Israeli

Airports Authority for compliance with the abovementioned requirements constitutes one of the

conditions for the approval of the system delivery certificate – Annex 1-C.

5.4.2. Secure Code Control

The provider shall conduct secure code tests by an external expert code control consultant with

experience of over 3 years in this field in at least 3 different organizations. It is hereby clarified that

the secure code control processes shall be based on a recognized secure code standard such as CERT,

designated ISO standards for the relevant programming language and for object-oriented

programming and procedural programming at the generic levels.




The person assigned to information security on behalf of CIS / the Israeli Airports Authority is

entitled at his or her discretion to demand the secure code control to be carried out according to the

nature of the system (for instance: system classified critical by the Israel National Information

Security Authority, system containing data pertaining to the Security Division, system containing

private data, administrational system, system containing public information, etc.).

As part of the secure code control process, the following subjects, inter alia, shall be tested: absence

of malicious code, protection against unauthorized external access [intrusion prevention], secure

development at both the code level and at the application level.

5.4.3. Secure Code Control Method

The control process shall be carried out by an expert code control consultant.

The provider is obligated to correct at its expense any deficiency found during the test.

Upon the completion of the test, the consultant shall submit a written certificate to the Israeli

Airports Authority attesting that the system has successfully passed the secure code control and

that all deficiencies found have been corrected.

The Israeli Airports Authority reserves the right to carry out additional control tests performed

by Israeli Airports Authority or external personnel.

At the discretion of the person assigned to information security on behalf of CIS / the Israeli

Airports Authority, the system shall undergo a controlled penetration test prior to its launch, by a

CIS / Israeli Airports Authority consultant and at the expense of the Israeli Airports Authority.

5.5. System Test Plan

The provider shall submit to the Israeli Airports Authority for its approval the System Test Plan,

including the extent, depth and types of tests required from the provider. Exclusion of any test from

the test list defined in Section 5.3 above shall be subject to a written reasoned application from the

provider and its written approval by the Israeli Airports Authority.

If there are additional tests relevant to the system, the provider and the Israeli Airports Authority are

entitled to add them to the list of Section 5.3 above.

5.6. System Test Directive

The provider shall submit the System Test Directive documents to the Israeli Airports Authority for

its approval.

The Israeli Airports Authority reserves the right to add additional System Test Directive documents

to be implemented by the provider.




5.7. System Test Review

The provider shall submit to the Israeli Airports Authority for its approval the System Test Reviews

of each round of tests. Disapproval of the System Rest Reviews shall obligate the provider to repeat

the round of tests until satisfactory results are obtained. A repeat round of tests shall not influence

the provider's obligation to comply with the work plan.

The System Test Reviews, having been approved by the Israeli Airports Authority, shall be returned

to the provider in order to make the required corrections, as prescribed in the Contract.