System Specifications for WAM and ADS-B Surveillance Web viewMandatory requirements use the word ......

System specifications Traffic Complexity Assessment Tool in Sofia ACC

SECTION XIVTECHNICAL REQUIREMENTS (SYSTEM

SPECIFICATIONS)

System Specifications

TRAFFIC COMPLEXITY ASSESSMENT TOOL IN SOFIA ACC

1/81


TABLE OF CONTENTS

1 GENERAL.........................................................................................................................71.1 BACKGROUND INFORMATION....................................................................................7

1.2 DOCUMENT STRUCTURE...............................................................................................7

1.3 REQUIREMENT TYPES AND COMPLIANCE..............................................................8

1.4 DEFINITIONS AND ABBREVIATIONS..........................................................................91.4.1 Definitions........................................................................................................................................91.4.2 Abbreviations..................................................................................................................................13

1.5 REFERENCES....................................................................................................................15

2 OPERATIONAL AND TECHNICAL ENVIRONMENT.............................................172.1 OPERATIONAL ENVIRONMENT.................................................................................17

2.1.1 Sofia Flight Information Region and major aerodromes................................................................172.1.2 Airspace Delegations......................................................................................................................192.1.3 Sectorisation....................................................................................................................................192.1.4 Sector Monitoring Values...............................................................................................................212.1.5 Airways and Free Route Airspace..................................................................................................212.1.6 Military Activity. Segregated, Prohibited and Danger Areas. FUA Concept.................................242.1.7 Weather...........................................................................................................................................272.1.8 Traffic.............................................................................................................................................272.1.9 Workload and Complexity..............................................................................................................28

2.2 TECHNICAL ENVIRONMENT......................................................................................282.2.1 Operative System............................................................................................................................282.2.2 Test System.....................................................................................................................................302.2.3 Equipment Locations......................................................................................................................30

3 TECHNICAL SPECIFICATIONS.................................................................................313.1 GENERAL...........................................................................................................................31

3.2 SYSTEM MAINTAINABILITY, RELIABILITY AND AVAILABILITY..................313.2.1 Technical Monitoring and Control.................................................................................................313.2.2 SNMP Monitoring Functions (Local & Remote)...........................................................................313.2.3 SNMP Control Functions................................................................................................................323.2.4 Security...........................................................................................................................................323.2.5 Data Logging..................................................................................................................................323.2.6 Availability, Reliability and Maintainability..................................................................................32

3.2.6.1 Continuity..............................................................................................................................323.2.6.2 Mean Time Between Critical Failures (MTBCF).................................................................333.2.6.3 Mean Time To Repair (MTTR)............................................................................................333.2.6.4 Availability............................................................................................................................333.2.6.5 Redundancy...........................................................................................................................33

3.3 SYSTEM DESIGNN...........................................................................................................333.3.1 Software Design..............................................................................................................................333.3.2 Hardware Design............................................................................................................................34

3.4 INPUT DATA PROCESSING...........................................................................................34

3.5 AIR SITUATION PREDICTION.....................................................................................35

3.6 TRAFFIC COUNTS, WORKLOAD AND COMPLEXITY..........................................36

3.7 HMI......................................................................................................................................38

2/81


3.7.1 Radar View.....................................................................................................................................383.7.2 Timeline View................................................................................................................................393.7.3 Flow View.......................................................................................................................................393.7.4 Airspace View.................................................................................................................................403.7.5 Scenario View.................................................................................................................................403.7.6 Meteorological View......................................................................................................................403.7.7 Integrated View...............................................................................................................................413.7.8 Background map.............................................................................................................................413.7.9 Flight Lists......................................................................................................................................413.7.10 Other HMI requirements............................................................................................................42

3.8 ARCHIVE AND REPLAY.................................................................................................42

3.9 SECTOR CONFIGURATIONS AND OPENING SCHEME........................................43

3.10 WHAT - IF...........................................................................................................................44

3.11 ATFCM................................................................................................................................44

3.12 COLLABORATIVE DECISION MAKING....................................................................45

3.13 USER ACCESS...................................................................................................................46

3.14 PERFORMANCE...............................................................................................................46

3.15 HUMAN RESOURCE MANAGEMENT.........................................................................47

3.16 PRINTING...........................................................................................................................47

3.17 EXPANSION AND MODULARITY................................................................................47

3.18 USER MANUAL.................................................................................................................47

3.19 ENVIRONMENTAL CONDITIONS...............................................................................483.19.1 Storage.......................................................................................................................................483.19.2 Transport....................................................................................................................................483.19.3 Equipment room use..................................................................................................................48

4 PROJECT REQUIREMENTS.......................................................................................494.1 GENERAL...........................................................................................................................49

4.1.1 Critical Success Factors..................................................................................................................494.1.2 Scope of Work................................................................................................................................494.1.3 Contractor Responsibilities.............................................................................................................494.1.4 BULATSA Operations...................................................................................................................504.1.5 Project Timings...............................................................................................................................514.1.6 Single Contractor............................................................................................................................514.1.7 Precedence of Documents...............................................................................................................51

4.2 PROJECT MANAGEMENT.............................................................................................514.2.1 Project Management Experience....................................................................................................514.2.2 Project Planning..............................................................................................................................51

4.2.2.1 Project Management Plan (PMP)..........................................................................................524.2.2.2 Contract Master Schedule (CMS).........................................................................................52

4.2.3 Project Monitoring and Control......................................................................................................534.2.3.1 Progress Status Reports (PSR)..............................................................................................534.2.3.2 Progress Meetings.................................................................................................................54

4.2.4 Risk Management...........................................................................................................................544.2.5 System Design................................................................................................................................55

4.2.5.1 Interface Management...........................................................................................................554.2.5.2 System Design Review..........................................................................................................55

4.2.6 Software Management....................................................................................................................564.2.7 Technical Documentation and Engineering Drawings...................................................................564.2.8 Specialty Engineering.....................................................................................................................56

3/81


4.2.8.1 Reliability, Maintainability and Availability Analysis.........................................................564.2.8.2 RMA Plan..............................................................................................................................564.2.8.3 Safety.....................................................................................................................................564.2.8.4 Software Safety.....................................................................................................................57

4.3 SYSTEM INSTALLATION..............................................................................................584.3.1 General............................................................................................................................................584.3.2 Use of BULATSA Personnel..........................................................................................................584.3.3 Installation Management Plan........................................................................................................584.3.4 Installation Responsibilities............................................................................................................59

4.4 INTEGRATED LOGISTIC SUPPORT...........................................................................604.4.1 Introduction.....................................................................................................................................604.4.2 BULATSA Support Concept..........................................................................................................60

4.4.2.1 General..................................................................................................................................604.4.2.2 Hardware Support Concept...................................................................................................604.4.2.3 Software Support Concept....................................................................................................61

4.4.3 ILS Plan..........................................................................................................................................614.4.4 Support System Implementation.....................................................................................................61

4.4.4.1 Spares....................................................................................................................................614.4.4.2 Technical Documentation.....................................................................................................624.4.4.3 Support and Test Equipment.................................................................................................63

4.4.5 Support Services.............................................................................................................................64

4.5 TRAINING..........................................................................................................................654.5.1 General............................................................................................................................................654.5.2 Training Plan...................................................................................................................................654.5.3 Maintenance Training.....................................................................................................................664.5.4 Operational Training.......................................................................................................................67

4.6 CONFIGURATION MANAGEMENT............................................................................674.6.1 Overview.........................................................................................................................................674.6.2 Configuration Management Plan....................................................................................................674.6.3 Configuration Identification...........................................................................................................684.6.4 Software Configuration Management.............................................................................................68

4.7 VERIFICATION.................................................................................................................684.7.1 Verification Management...............................................................................................................68

4.7.1.1 General..................................................................................................................................684.7.1.2 Verification Management Plan..............................................................................................694.7.1.3 Verification Cross Reference Matrix (VCRM).....................................................................694.7.1.4 Test Readiness Reviews........................................................................................................694.7.1.5 BULATSA Involvement in Acceptance Verification...........................................................694.7.1.6 Failure Reporting and Analysis.............................................................................................694.7.1.7 Regression Testing................................................................................................................70

4.7.2 Acceptance Verification.................................................................................................................704.7.2.1 General..................................................................................................................................704.7.2.2 Acceptance Test Plans, Procedures and Reports...................................................................70

4.7.3 Operational Evaluation...................................................................................................................71

4.8 QUALITY MANAGEMENT PROGRAM.......................................................................714.8.1 Contractor Quality Responsibilities................................................................................................714.8.2 Quality Plan....................................................................................................................................72

5 APPENDIX A – SYSTEM REQUIREMENTS COMPLIANCE MATRIX.................73

6 APPENDIX B – CONTRACT DELIVERABLES REQUIREMENTS LIST...............87

4/81


1 GENERAL

1.1 BACKGROUND INFORMATION

In 2014 the European Commission has adopted Regulation EU No 716/2014 for the implementation of a Pilot Common Project – a first set of six ATM functions deemed ready for large scale coordinated deployment. The implementation of the tCAT system aims to address the regulatory requirements for the Network Collaborative Management function and more specifically the “Automated Support for Traffic Complexity Assessment” sub-function.

The first steps towards the introduction of a local complexity management function in Sofia ACC were made at the end of 2014 when a feasibility study was carried out. As at the time the scope of the future system was not fully clear, the study is centred around the workload measurement and configuration optimiser features and did not address functionalities related to traffic management or any collaborative functions. The actual project start was in the beginning of 2016 when an Operational Concept Document was prepared, describing a high level vision of the future system and it serves as a basis for the development of this system specification.

The present document contains the system and project requirements defined for the development and installation of a traffic complexity and capacity management system in Sofia ACC, referred to hereinafter as the tCAT (Traffic Complexity Assessment Tool) system. Sometimes there may not be one-to-one direct relationship between this system specification and the operational concept document. Some of the system services, initially envisioned, have been intentionally omitted from the specification due to low maturity or because it was perceived they would unacceptably elevate project risks.

1.2 DOCUMENT STRUCTURE

Chapter 1 of this document provides information required to understand the goal of the tCAT Project. Definitions, abbreviations and referenced documents, essential to proper understanding of this document are also provided in this chapter.

Chapter 2 provides short description of the Operational and Technical environments.

Chapter 3 contains general design requirements for tCAT system and minimum performance specification.

Chapter 4 contains the Project requirements for a successful completion of the tCAT project, including: responsibilities of both Contractor and BULATSA, Project and Risk Management, System engineering including the System design and Software Management, delivery and installation of the systems, logistic support, training activities and the Configuration, Verification and Quality Management.

Appendix A contains a compliancy matrix of the technical and the project requirements.

Appendix B contains the Contract Deliverables Requirements List (CDRL).

5/81


1.3 REQUIREMENT TYPES AND COMPLIANCE

Standard terminology is used to indicate the status of technical requirements.

Mandatory requirements use the word “shall”.

Recommended requirements use the word “should”.

The word “will” is reserved for BULATSA’s intentions.

Where the requirement applies to the documentation, i.e. it states how the Contractor is to respond, it follows the form: “The Contractor shall/should/”.

Where the requirement applies after the award of the contract, i.e. it states what must be delivered or produced or it defines how the contract must be performed or managed, it follows the form: “The Contractor shall/should/may ...”.

Compliance with the requirements in the system specifications by the Contractor is required as a means of assuring that the equipment will satisfactorily perform its intended functions under all conditions normally encountered in the Air Traffic Control operations.

Appendix A contains a list of the requirements, including their type and the level of compliance.

The type of requirement can be:

Mandatory - indicates a mandated criterion; i.e. compliance with the particular procedure or specification is mandatory and no alternative may be applied. Mandatory are requirements that are associated with the safety of the system or represent major functional requirements. The phrase “Shall” is used in the mandatory requirements; or

Recommended - indicate that the compliance with the requirement is recommended, but not mandatory. The phrases ‘Should’ (and phrases such as ‘It is recommended that...’, etc.) are used in the Scored requirements.

The contractor shall include a statement of compliance for every requirement in this specification in the respective compliance matrix. The contractor shall also include a description of how he proposes to meet every requirement as well as a reference as to where in the technical proposal this description can be found.

1.4 DEFINITIONS AND ABBREVIATIONS

1.4.1 Definitions

Acceptance means acceptance of the Supplies in accordance with the Contract.

Air situation is a term denoting aircraft position and intentions together with the state of the operational environment at a particular moment in time.

Approved Design Documentation means the Design Documentation, amended and approved by BULATSA.

6/81


Availability - The probability that a system is able to perform its intended function at the initiation of the intended operation. It is quantified as the proportion of time the system is actually available to the time the system is planned to be available. Periods of planned maintenance are discounted from Availability figures.

Assurance Level (AL) - A measure of software assurance of ground based systems used for Communication, Navigation and Surveillance in an Air Traffic Management context (CNS/ATM).

Note: Assurance Level is defined in ED-109 and are numbered AL1 to AL6 with AL1 being the most stringent.

Calibration means the adjustment and fine tuning of input system parameters in order to achieve best possible system performance in a particular environment.

Complexity is a characteristic of ATC operations that describes the level of mutual interactions and interdependencies between the numerous elements of the operational environment and more specifically, those inter-relations that influence controller workload.

Complexity factor means an event, a condition or particular circumstance that influences the complexity of ATC operations.

Configuration Item means an aggregation of hardware/software, or any of its discrete proportions which satisfies an end item use function and is designated for configuration management.

Continuity - The ability of a system or an item to perform its required function without unscheduled interruption throughout the duration of the intended operation, assuming the system is available when the procedure is initiated.

Design Documentation means all drawings, specifications, data and other information, samples and models describing the design of the System, Support and Test Equipment and System Support Facility.

Effective Date means the date on which the Contract takes effect.

Functional Baseline means documentation describing a System’s functional characteristics and the verification required to demonstrate the achievement of those specified functional characteristics.

Milestone means an event or series of events for which the Contractor is responsible to be achieved to the satisfaction of the Project Manager.

Non-Routine Workload means workload related to tasks that require analysis, planning and decision making before being executed. Example – conflict resolution. Non-routine workload tasks are closely intertwined with the concept of complexity.

Operational environment is the combination of technological, procedural, structural or natural elements that constitute the environment within which ATC operations take place.

Operational Lifetime means the period of 10 years following Acceptance of the System.

Operational Software means the software installed on an operational System and is more particularly described in the Technical Specifications.

Plans and Documents means the plans and documents described in chapter 4 of this document (Project Requirements) to be provided in accordance with and at the times and manner specified in this System Specifications (including in particular in accordance with the

7/81


requirements of the Contract Deliverables Requirements List), but excludes Design Documentation, Approved Design Documentation and Technical Documentation.

Product Baseline A product baseline exists for each Configuration Item and is described by the Approved Design Documentation applicable to the Configuration Item.

Progress Meeting means the meeting detailed at paragraph 4.2.3.2 of this document.

Opening scheme means the sequence and duration in which different sector configurations are applied in an airspace

Routine Workload means workload stemming from tasks that are accomplished routinely, as a direct response to an event or condition and require little or no advance planning. These tasks are executed by air traffic controllers with a high level of automatism. (Example: aircraft identification, transfer on next frequency, squawk change). Routine workload is normally not linked to sources of complexity, however it reduces the time available to handle non-routine workload tasks and therefore indirectly affects complexity management.

Safety Assessment Approval means approval of a Safety Assessment Document by the Safety Assessment Approval Authority.

Safety Assessment Approval Authority means the Civil Aviation Safety Administration or BULATSA, as the case requires.

Safety Plan means the plan to be prepared jointly by the Contractor and BULATSA (and specified in paragraph 4.2.8.3 of this document) describing the documentation required and the process to be followed to enable Safety Assessment Approval.

Sector overload is a situation in which there is a high probability that unacceptably high workload may occur in specific ATC sector

Sector underload is a situation in which there is a significant underuse of controllers cognitive resources

Spares and Consumables means the spares and consumables provided to BULATSA - during the Initial Support Period and described as such in the Spares and Consumables List.

Software Assurance Level (SWAL) - A measure of assurance intended to apply to software components that are part of an Air Navigation System (ANS), focusing only on the ‘ground’ segment of ANS and provides a reference against which stakeholders can assess their own practices for software specification, design, development, operation, maintenance, evolution and decommissioning.

Note: Assurance Level is defined in ED-153 and are numbered SWAL1 to SWAL4 with SWAL1 being the most stringent.

Special Use Area is a common term that may denote a danger, restricted, prohibited, temporary segregated or temporary restricted area.

Supplies means the System, the Deliverables and any other supplies or services that the Contractor is required to provide or Install under the Contract in relation to or in connection with the System or Deliverables but excludes Support Services.

Support Concept means the BULATSA support concept detailed at paragraph 4.4.2 of this document.

8/81


System means Traffic Complexity Assessment Tool that the Contractor is required to supply, deliver and install under this Contract. For the avoidance of doubt, the term System does not include the System Support Facility.

System Reviews means an event at which the progress of the technical effort (including that of engineering and integrated logistics support) is assessed relative to the relevant plans and technical and contractual requirements.

Technical Documentation means the technical documents, know-how and information reduced to material form produced or acquired by the Contractor or subcontractors in relation to the Supplies, Installation, Training and Support Services and includes all data, manuals, handbooks, designs, standards, plans, drawings, calculations, software, software design data, software updates and other items describing or providing information relating to the Support Services and the Supplies or their operations or Maintenance and includes the documentation more particularly described in this System Specifications, but excludes the Plans and Documents, Design Documentation and Approved Design Documentation.

Traffic flow means a collection of flights logically grouped together by a common attribute (e.g. same destination, same point en-route etc.)

Transition means the activities undertaken by the Contractor, subcontractor and BULATSA to transition the Supplies that have been produced under the Contract from the project oriented, development environment to an operating and support environment, leading to Acceptance of the Systems and commencement of the Support Services.

Validation - The determination that the requirements for a product are sufficiently correct and complete.

Verification means confirmation by examination, analysis or test and provision of objective evidence that specified requirements to which a product or service, or aggregation of products and services, is built, coded, assembled and provided have been fulfilled; and “Verify” has a corresponding meaning.

Version Description Document means the primary configuration control document used to track and control versions of software to be released to the operational environment. It is a summary of the features and contents for the software build. It identifies and describes the version of the software CI being delivered to BULATSA, including all changes to the software CI since the last VDD was issued.

Workload means the overall effort that needs to be exercised by an air traffic controller in order to fulfil required traffic management tasks. Within the context of this specification workload is considered equivalent to task load.

9/81


1.4.2 Abbreviations

5LNC Five Letter Name CodeA/C AircraftACC Area Control CenterADS-B Automatic Dependent Surveillance - BroadcastAGDL Air-Ground Data-LinkAIP Aeronautical Information PublicationAMHS ATS Message Handling SystemANS Air Navigation ServicesARTAS ATM Surveillance Tracker and ServerATCO Air Traffic ControllerATFCM Air Traffic Flow and Capacity ManagementATM Air Traffic ManagementATOT Actual Take Off TimeATP Acceptance Test PlanATProcs Acceptance Test ProceduresATR Acceptance Test ResultsATS Air Traffic ServicesAUP Airspace Use PlanBADA Base of Aircraft DataCAA Civil Aviation AuthorityCB CumulonimbusCDRL Contract Data Requirements ListCI Configuration ItemCMP Configuration Management PlanCMS Contract Master ScheduleCNS Communication Navigation SurveillanceCOTS Commercial Off the ShelfCPR Correlated Position ReportCSCI Computer Software Configuration ItemCTA Controlled AreaCTR Controlled Traffic RegionCTZ Control ZoneDB DatabaseDF Danube FABDFL Division Flight LevelDGCAA Directorate General Civil Aviation AuthorityEC European CommissionEFD ETFMS Flight Data MessageEMC Electromagnetic compatibilityEOBT Estimated Off Block TimeETOT Estimated Take Off TimeETSI European Telecommunications Standards Institute

10/81


FAB Functional Airspace BlockFAT Factory Acceptance TestsFDP Flight Data ProcessingFDPS Flight Data Processing SystemFHA Functional Hazard AssessmentFIR Flight Information RegionFL Flight LevelFLCHG Flight Level ChangeFPL Flight PlanFRA Free Route AirspaceFS Family SectorsFUA Flexible Use of AirspaceGW GatewayHDD Hard Disk DriveHMI Human Machine InterfaceHRM Human Resource ManagementICD Interface Control DocumentIFR Instrument Flight RulesILSP Integrated Logistic Support PlanLARA Local and Sub Regional Airspace Management Support SystemLCC Life Cycle CostLDAP Lightweight Directory Access ProtocolLoA Letter of AgreementLRU Line Replaceable UnitLVD Low Voltage DirectiveMET MeteorologicalMLT MultilaterationMTBCF Mean Time Between Critical FailuresMTO MeteorologicalMTTR Mean Time To RepairNM Network ManagerNMOC Network Manager Operations CenterNOTAM Notices to AirmanODS Operative Display SystemOLDI On-line Data InterchangeOS Opening SchemeOTMV Occupancy Traffic Monitoring ValuesPLB PlaybackPMP Project Management PlanPSR Progress Status ReportPSSA Preliminary System Safety AssessmentRAID Redundant Array of Independent DisksREC RecordingRMA Reliability Maintainability Availability

11/81


SAT Site Acceptance TestsSCL Spares and Consumables ListSDDS Surveillance Data Distribution SystemSDPD Surveillance Data Processing and Distribution SNMP Simple Network Management ProtocolSSA System Safety AssessmentSUA Special Use AreaSWAL Software Assurance LevelstCAT Traffic Complexity Assessment ToolTDL Technical Documentation ListTDS Test and Development SystemTMA Terminal AreaTMC Technical Monitoring and ControlTMCS Technical Monitoring and Control SystemTSA Temporary Segregated AreaUSB Universal Serial BusUUP Updated Airspace Use PlanVCRM Verification Cross Reference MatrixVMP Verification Management PlanWAFC World Area Forecast CenterWAM Wide Area MultilaterationWPROC Wind ProcessingXML Extended Markup Language

1.5 REFERENCES

REF1 BULATSA Aeronautical Information Publication (AIP) of the Republic of Bulgaria, Sep 2016

REF2 RFC 1157, A simple network management protocolREF3 RFC 1213, Version 2 of management information base (MIB-2) for network

management of TCP/IP-based internetsREF4 EUROCAE ED-109 / DO-278B, Guidelines for Communication, Navigation,

Surveillance and Air Traffic Control (CNS/ATM) Systems Software Integrity Assurance, March 2002

REF5 EUROCAE ED-153, Guidelines for Ans Software Safety AssuranceREF6 ETSI EN 300 019-1-3, Equipment Engineering (EE); Environmental

conditions and environmental tests for telecommunications equipment, Part 1-3: Classification of environmental conditions Stationary use at weatherprotected locations

REF7 URB/USD/MSG_INTF, Flight Progress Messages DocumentREF8 EUROCONTROL- SPEC-0106, EUROCONTROL Specification for On-Line

Data Interchange (OLDI)REF9 ICAO Annex 3, Meteorological Service for International Air Navigation

12/81


REF10 DCMAC/HS/DEL/08-015, LARA Local and Regional Airspace Management Supporting System Conceptual Description

REF11 RFC 768, User Datagram ProtocolREF12 RFC 791, Internet ProtocolREF13 RFC 793, Transmission Control ProtocolREF14 EUROCONTROL EEC Base of Aircraft Data (BADA) Aircraft Performance

Modelling ReportREF15 RFC4511, Lightweight Directory Access Protocol (LDAP): The ProtocolREF16 EC REGULATION No 482/2008 of 30 May 2008 establishing a software

safety assurance system to be implemented by air navigation service providers and amending Annex II to Regulation (EC) No 2096/2005

REF17 EC REGULATION No 552/2004 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 10 March 2004 on the interoperability of the European Air Traffic Management network (the interoperability Regulation)

REF18 SUR.ET1.ST05.2000-STD-09-01, EUROCONTROL Standard Document for Surveillance Data Exchange Part 9: Category 062 SDPS Track Messages

REF19 EC REGULATION No 552/2004 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 10 March 2004 on the interoperability of the European Air Traffic Management network (the interoperability Regulation)

REF20 COMMISSION IMPLEMENTING REGULATION (EU) No 716/2014 of 27 June 2014 on the establishment of the Pilot Common Project supporting the implementation of the European Air Traffic Management Master Plan

REF21 Traffic Complexity Assessment Tool in Sofia ACC. Operational Concept Document, version 1.0, BULATSA, 2016

REF22 Factors of Complexity in Sofia ACC report, version 1.0, BULATSA, 2016REF23 Cooperative Traffic Management Short Term ATFCM Measures Operational

Concept, Eurocontrol, Edition 1.0, 2015

13/81


2 OPERATIONAL AND TECHNICAL ENVIRONMENT

2.1 OPERATIONAL ENVIRONMENT

The information provided in this section is for illustrative purposes only and it may change since the time this document is prepared. For most recent data on the operational environment in Sofia FIR, AIP Republic of Bulgaria or other official sources shall be consulted.

2.1.1 Sofia Flight Information Region and major aerodromes

The airspace of Sofia FIR includes:

a) the airspace over the sovereign territory of Republic of Bulgaria and territorial watersb) The airspace over the Black Sea, which is delegated to Republic of Bulgaria in accordance with a Regional Air Navigation Agreement

There are five international airports in Sofia FIR – Sofia (LBSF), Varna (LBWN), Bourgas (LBBG), Plovdiv (LBPD) and Gorna Oryahovitsa (LBGO).

Sofia airport is the largest airport in Bulgaria. It serves the capital city and is active all year round. The airport generates 150-170 traffic movements on a busy day.

Varna and Bourgas airports serve the resorts along the Black Sea coast. They are active only during the busy summer season between May and October. Bourgas airport is preferred by operators and generates up to 220 traffic movements on a busy day, while Varna airport normally remains below 100 movements.

Plovdiv and Gorna Oryahovitsa airports have very small amount of daily IFR movements (less than 10).

There are three TMAs within Sofia FIR for LBSF, LBBG and LBWN airports.

A map of Sofia FIR, TMAs and CTRs is shown on the map below:

14/81


Figure 1. Sofia FIR, TMAs and CTRs

The airspace of Sofia FIR is class C airspace above flight level 105 and within the airspace of TMAs and CTRs. The airspace below FL 105, outside TMAs and CTRs, is class G airspace1.

1 Certain exception may apply – see AIP Republic of Bulgaria for details.

15/81


2.1.2 Airspace Delegations

Figure 2.Cross-border sectors in DANUBE FAB

In order to optimize usage of airspace and improve flight efficiency within the airspace of DANUBE FAB, Bulgaria and Romania initiated a cross-border sectorisation project. This includes the delegation of airspace from Bucharest to Sofia and vice versa.

Presently there are two airspace delegations along the northern border of Sofia FIR: DF Sector 1 – airspace within Bucharest FIR, which is delegated for ATS provision to

Sofia ACC DF Sector 2 – airspace within Sofia FIR, which is delegated to Bucharest ACC.

The two delegations are shown as shaded areas on Figure 2. All airspace delegations are in the upper airspace only.

2.1.3 Sectorisation

ATS sectors in Sofia ACC are organized within two sector families (FS) – family sectors Sofia and family sectors Varna as shown on Figure 3. Each sector family requires specific ATCO licensing, but cross-training and double licensing is increasingly common. Sector families opening scheme plans are managed separately, each having its own predefined sector configurations set. Staff is also rostered separately for the two families, but it is often dynamically moved from one family sectors to another, depending on operational need and provided that double licensing permits.

16/81

DF Sector 1

DF Sector 2


Figure 3. Family sector organization in Sofia ACC

Lateral boundaries of elementary ATS sectors are shown on Figure 4. In addition, sectors can be further split vertically, using one or more division flight levels (DFL). All division flight levels from 315 to 395 are used as DFLs. Middle layered sectors are extensively used in Sofia ACC and DFLs are dynamically changed throughout the day in order to best respond to prevailing operational conditions.

Figure 4. Boundary of elementary ATS Sectors

Sofia ACC also employs dynamic virtual volumes – sectors that never exist on its own, but are dynamically attached to one of the adjacent sectors in order to modify “on-the-fly” the sector shape in accordance with traffic flows. The sectors currently used as virtual are SE, SF and VC.

17/81

FS SofiaFS Varna


2.1.4 Sector Monitoring Values

Main method to monitor sector load are the Occupancy Traffic Monitoring Values (OTMVs). For each sector there are four values declared:

Peak – this is maximum sector occupancy that cannot be normally exceeded. The value is specific for each sector.

Sustained – This is the sector occupancy that can be exceeded, but only for a limited amount of time, determined by the high lapse and high occurrence values. The value is specific for each sector.

High lapse - a 20 min sliding time interval within which the number of high occurrences are counted.

High occurrence – the maximum acceptable number of occupancy counts above the sustained value that happen within a high lapse interval. The value used in Sofia ACC is the same for all sectors – 13.

BULATSA used the hourly entry rates in the past, but these are not declared on a sector-by- sector basis anymore. However, entry rates are monitored in order to avoid excessively high entry rates and communication channel overloads that sometimes cannot be avoided by using OTMVs only. The maximum entry rate is currently set to 50 aircraft/hour, but it is considered to be increased to 60 aircraft an hour.

Figure 5. Usage of OTMVs in Sofia ACC

2.1.5 Airways and Free Route Airspace

The airways in the airspace of Sofia CTA make network of significant complexity. Besides the permanent routes there are a lot of conditional routes category 1, 2 and 3 which are managed in daily AUP. An alternative route network is present over the High Seas and is activated by

18/81


NOTAM whenever there is a military exercise within the danger areas located east of Varna Airport (D312/313/314).

The differences in the route network definition in the upper and lower airspace are minimal, and the U and L prefixes have been removed from route identifiers. With certain exceptions, all airways in Sofia FIR are unidirectional and entry and exit interfaces are dualised.Sofia ACC operates a night free route airspace (FRA) within the time period 23:00-05:00 UTC (22:00-04:00 UTC during summer). During that period the route network is retained, but its use is not mandatory. During the FRA operating hours aircraft operators may plan a user defined trajectories from FRA entry to FRA exit points with the optional use of one or more intermediate points. FRA is currently available above FL 245 only. FRA will be gradually expanded to H24 operations and the lower limit extended to FL 105. Cross border FRA operations to/from adjacent FIR are also planned. Full FRA H24 is expected before end of year 2019.

19/81


Figure 6 Airways in the upper airspace

20/81


2.1.6 Military Activity. Segregated, Prohibited and Danger Areas. FUA Concept

For the most part training activity of Bulgarian air force remains contained within the limits of TSA and TRAs. Their activation is planned and advance information is distributed through daily airspace use plan and updated airspace use plan (AUP/UUP). Bulgarian air force is active mostly in the areas in the lower airspace. In the upper airspace TSA1 is most frequently activated. TSA2 and 2A are only rarely activated as they block major traffic flows.

Non-aviation military activities take place in the published danger areas. These areas rarely affect civil traffic flows. Advance information for these is distributed through the AUP/UUP with the exception of a small number of non-plannable areas, which are activated by NOTAM.

Anti-cloud shooting danger areas are located in the north-western part and in the southern-central part of Sofia FIR (danger areas with ID from D10 to D19). The activation of these areas is not planned due to the transient character of the CB weather phenomena. These are activated at tactical level in response to existing or expected CB activity and the airspace must be immediately cleared of traffic by air traffic controllers. Traffic planning their route through an active danger area must be vectored around.

Most of the prohibited and restricted areas remain below the lower limit of controlled airspace. However, there are two that need to be mentioned – prohibited area P1 and restricted area R1 which are centered around the Kozlodui nuclear power plant.

Bulgaria applies the Flexible Use of Airspace Concept. Daily airspace use plan is prepared by Sofia Airspace Management Cell (Pre-tactical level). On the day of operations, the actual activation and deactivation of areas is done by the Civil Military Tactical Coordination Unit.A map of all areas within the lower and upper airspace is provided on Figure 7 and Figure 8.

21/81


Figure 7. Danger, Restricted, Prohibited, TSA and TRAs in the lower airspace

22/81


Figure 8 Danger areas and TSAs in the upper airspace

23/81


2.1.7 WeatherEn-route operations are significantly affected by convective weather phenomena during the summer months (May- September). Both frontal and air-mass thunderstorms are common and depending on location and intensity may significantly increase workload and reduce capacity. Strong winds and clear air turbulence are additional factors that need to be considered when modelling complexity. Weather at airports does not affect en-route operations except on very rare occasion when holding at higher altitudes is required.

2.1.8 Traffic

In 2015 BULATSA managed 774 710 traffic movements. Approximately 10% of all traffic is generated by local airports and the rest are overflights. The main traffic flows are:

Traffic to/from Turkey Traffic to/from Middle East Traffic to/from Far East Traffic to/from Greece/Cyprus/Israel Traffic to/from North Africa Traffic to/from local airports Other traffic

The relative contribution of each traffic flow is shown on Figure 1Figure 9

Turkey45%

Middle East19%

Far East6%

Greece/Cyprus, Israel20%

North Africa2%

Local airport5%

Others3%

Traffic Flows in Sofia FIR(July 2016)

Figure 9 Relative contribution of traffic flows in Sofia FIR

A distribution of traffic flow density within Sofia FIR is shown on Figure 10. It is representative for typical busy summer traffic. However, it has to be noted that traffic patterns

24/81


and density change significantly throughout the year and many of the flows are virtually nonexistent during the winter months.

Figure 10 Traffic flow density in Sofia FIR

Traffic patterns in Sofia FIRs are also often considerably affected by a number of regional political crisis situations and may change dramatically with little or no advance notice. This poses additional requirement on any future complexity management system and built-in models which will need to be agile enough to adapt to these changes promptly.

2.1.9 Workload and Complexity

Controller workload and traffic complexity are function of flow patterns and also change significantly with season or regional political events. Many of the factors that impact complexity during summer do not exist or are significantly less pronounced in winter months (e.g. convective weather, traffic in evolution). A more detailed description of the complexity factors affecting Sofia ACC en-route operations is provided in REF22.

2.2 TECHNICAL ENVIRONMENT

2.2.1 Operative System

The tCAT system, ATM system and its SDPD subsystem currently into operation into BULATSA are shown on the next figure:

25/81


Figure 11: Functional diagram of tCAT system as a part of the BULATSA ATM System

Description of the tCAT Interfaces:

Upper wind information – required to correctly calculate aircraft 4D position and provide input to workload model calculations

SUA activation and plans – required to correctly model airspace constraints and feed required data into workload model computations

OS plan – this information is exported to the local HRM tool in order to enable correct distribution of personnel on sectors. Information on OS plan is also exporter to the NM systems in order to provide transparency of local operations.

EFD messages – information received by NM systems in order to enable correct 4D profile calculation by the tCAT system.

Workload metrics – exported to NM systems in order to enable transparency of local situation and ease coordination at network level.

Flow measure coordination – Any planned flow measures need to be coordinated with other regional actors with the intermediation of NM in order to assess and mitigate any potential negative network effects of local flow measures. Information on flow measures could also be distributed to local actors in order to enable their timely and proper application.

MTO radar information – this information is fed into the workload model in order to assess workload impact of convective weather phenomena. This also includes information from related forecast model.

Radar plots, tracks and position reports – needed to correctly model 4d flight trajectory

26/81


2.2.2 Test System

BULATSA has a test environment called Test and Development System (TDS). It duplicates the operational environment as much as possible. The TDS allows the testing of new system settings, software upgrades, performance trials, etc. without disturbing the operational services.

Figure 12 Functional diagram of test tCAT system as a part of the BULATSA TDS ATM System

The tCAT system shall support BULATSA’s TDS (Test and Development System) by the provision of additional test equipment. The test tCAT system shall be replica of the main system but in the single hardware configuration (central processing unit and working position).

2.2.3 Equipment Locations

The system’s central processing equipment and the maintenance display/unit of the Traffic Complexity Assessment Tool shall be installed inside the Technical Hall of the Common National Air Traffic Control Centre (CNATCC) where the required facilities (e.g. redundant power supply, environment conditioning, etc.) are available. Each central processing unit of the tool shall be connected to SDDS, FDPS, LARA and HRM systems.

The working positions of the Traffic Complexity Assessment Tool will be located inside the Operational Hall of the Common National Air Traffic Control Centre (CNATCC) and will be connected to central processing equipment. The system will be connected to printer.

The contractor has to be aware that the possibilities of installing equipment on some locations may be limited.

27/81


3 TECHNICAL SPECIFICATIONS

3.1 GENERAL

TCAT.GEN.1 The system shall take into account the full operational environment of Sofia ACC, as described in AIP Republic of Bulgaria [REF1]

TCAT.GEN.2 The system shall take into account the operational environment of adjacent ACCs to the extent needed to assess externally induced complexity factors

TCAT.GEN.3 The system shall provide complexity measurement and management services for en-route sectors in Sofia ACC [REF1].

TCAT.GEN.4 The system shall be able to operate in FRA environment, including cross-border FRA environment

TCAT.GEN.5 The system shall be able to support the family sector organization in Sofia ACC.

TCAT.GEN.6 The system shall be able to operate automatically the switch between different AIRAC environment datasets without interruption or degradation of services.

TCAT.GEN.7 All necessary initial system calibration, including calibration of complexity model and the aircraft model to the operational environment of Sofia ACC, shall be executed by the Contractor.

TCAT.GEN.8 Workload and complexity model, aircraft performance model or any other operational model built into the system, shall be open for parametrisation by BULATSA staff in order to allow the continuous adjustment and fine-tuning of model behaviour to the constantly changing operational environment of Sofia ACC.

TCAT.GEN.9 The system shall provide necessary interfaces for environment datasets import and definition.

TCAT.GEN.10 Calibration and verification activities of operational models built into the system (complexity/workload model, aircraft performance model or other) shall take into account the busy summer traffic period (15 May – 30 September).

3.2 SYSTEM MAINTAINABILITY, RELIABILITY AND AVAILABILITY

3.2.1 Technical Monitoring and Control

TCAT.RAM.01 The system shall be provided with Technical Monitoring and Control Function.

TCAT.RAM.02 Status Monitoring and control functions shall be available on the local HMI.

TCAT.RAM.03 System configuration should be based on a HMI (Human-Machine Interface) that provides functions for reading, modifying and storing system settings.

TCAT.RAM.04 The system should provide interface monitoring functions.

28/81


3.2.2 SNMP Monitoring Functions (Local & Remote)

TCAT.RAM.05 The system shall handle the SNMP protocol [REF2] and shall be compliant with MIB-II [REF3].

TCAT.RAM.06 The state of the following functions should be made available for monitoring to the SNMP interface:

a. Status Reporting;b. Buffer Overflows;c. Processor Overloads;d. Communications Overload;e. Communications Loss;f. Time Synchronization;g. End to End System Test;h. System version (software, firmware and/or hardware).

TCAT.RAM.07 The system should be able to forward state information based on SNMP. All state information shall be forwarded on request (polling) and when thresholds are exceeded or events occur (traps).

3.2.3 SNMP Control Functions

TCAT.RAM.08 It shall be possible to command the system from the SNMP interface via multiple channels.

TCAT.RAM.09 It should be possible to modify all configurable system parameters via the control and monitoring interface.

TCAT.RAM.10 It should be possible to save and restore all configurable parameters of the system to and from external electronic media, such as: USB stick, external hard drive, CD/DVD media, etc.

TCAT.RAM.11 The settings of all configuration parameters should be preserved during power interruption or restart of the system.

TCAT.RAM.12 The system should accept control commands from a remote location.

3.2.4 Security

TCAT.RAM.13 The system shall permit a change of the system configuration to be commanded by authorized users only.

3.2.5 Data Logging

TCAT.RAM.14 The TMC shall have the capability to log: user access activity, all warnings and changes of state and the control instructions with provided timestamp, administrator actions and diagnostic logs.

TCAT.RAM.15 The TMC shall include the functionality to save log files to an external electronic media, such as: USB stick, external hard drive, CD/DVD media, etc.

3.2.6 Availability, Reliability and Maintainability

3.2.6.1 Continuity

TCAT.RAM.16 The system shall perform their required functions without unscheduled interruption.

29/81


TCAT.RAM.17 The system shall automatically recover from power interruptions.

3.2.6.2 Mean Time Between Critical Failures (MTBCF)

TCAT.RAM.18 The MTBCF of the system shall be less than once per 500 operating hours (2*10-3 1/h).h – Operating hour

3.2.6.3 Mean Time To Repair (MTTR)

TCAT.RAM.19 The MTTR of the system hardware should be less than 30 minutes for any single repair action including the time necessary for fault localizing, repair, testing and resumption of normal operation.

3.2.6.4 Availability

TCAT.RAM.20 The Availability, excluding agreed maintenance periods, shall not be less than 99.95%.

Availability = MTBCF/(MTBCF + MTTR)MTBF: Mean Time Between FailureMTTR: Mean Time To Repair

3.2.6.5 Redundancy

TCAT.RAM.21 The system shall be redundant, operating in a master/standby configuration.

TCAT.RAM.22 Switching from master to slave processor should take place within 60 seconds.

3.3 SYSTEM DESIGNN

3.3.1 Software Design

TCAT.SWD.01 The system shall be built on top of an existing commercial off-the-shelf (COTS) operating system.

TCAT.SWD.02 The system architecture shall be client-server.TCAT.SWD.03 The client shall be able to receive and present asynchronous

notifications from the server.TCAT.SWD.04 Software design shall follow the guidelines for the assurance of

software contained in ED-109 [REF4].TCAT.SWD.05 The Assurance Level shall be at least AL4 as defined in ED-109

[REF4].

Note: ED-109 [REF4] provides a clear set of software development guidelines for equipment suppliers and hence is used for this document’s requirements. ED-153 [REF5], Guidelines For ANS Software Safety Assurance is aimed at ANSPs and is therefore not used for a formal requirement in this document. To assist understanding of the equivalence of these standards, ED-109 [REF4] AL4 corresponds to SWAL3 in ED-153 [REF5].

30/81


3.3.2 Hardware Design

TCAT.HWD.01 All system's hardware components shall be COTS hardware.TCAT.HWD.02 The system shall comply with the following national regulations

or respectively EU regulatory standards:a. Ordinance on the essential requirements and conformity assessment of

electrical equipment designed for use within certain voltage limits (approved by Government with Decree No 47 on 15 March 2016, promulgated in State Gazette (SG) issue 23, 25 March 2016, entering into force on 20 April 2016, amended, issue 32, 22 April 2016, entering into force on 13 June 2016) or Directive 2006/95/EC of the European Parliament and of the Council of 12 December 2006 on the harmonisation of the laws of Member States relating to electrical equipment designed for use within certain voltage limits;

b. Directive on the essential requirements and conformity assessment relating to electromagnetic compatibility (approved by Government with Decree No 47 on 15 March 2016, promulgated in SG issue 23, 25 March 2016, entering into force on 20 April 2016, amended, issue 32, 22 April 2016, entering into force on 13 June 2016) or Directive 2004/108/EC of the European Parliament and of the Council of 15 December 2004 on the approximation of the laws of the Member States relating to electromagnetic compatibility and repealing Directive 89/336/EEC ;

Note: Directive 2006/95/EC lays down the requirements covering all health and safety risks of electrical equipment operating within certain voltage ranges. It replaces previous Directive 73/23/EEC.Directive covers the safety of electric products operating under more than 50 volts and ensures that only safe electrical equipment is placed on the market.

Note: Directive 2004/108/EC lays down requirements in order to preventing electrical and electronic equipment from generating or being affected by electromagnetic disturbances. It replaces Directive 89/336/EECThere is a protection requirement so that the electromagnetic disturbance generated does not exceed a certain level in order to ensure that radio and telecommunications equipment or other equipment can operate as intended.

TCAT.HWD.03 The system should be CE marked to demonstrate compliance with EU directives for product safety.

TCAT.HWD.04 The processing units should support connection to a redundant 230 V, 50 Hz power connection.

TCAT.HWD.05 The processing units installed in the equipment room shall be capable of use at temperature controlled locations, under the conditions defined within ETSI EN 300 019 1-3 Class 3.1 [REF6].

TCAT.HWD.06 The number of working position delivered and installed shall be 4 (3 installed in the operational room and one installed in the equipment room).

31/81


3.4 INPUT DATA PROCESSING

TCAT.INP.01 The system shall process NM Flight Progress Messages (EFD)TCAT.INP.02 The system shall process data from local Flight Data Processing

SystemTCAT.INP.03 The System should process flight information received via OLDI

messages [REF8].TCAT.INP.04 The system shall process input meteorological radar data, wind

information and other required meteorological data and forecasts. Data formats shall be RAINBOW 5, GRIB/GRIB2 and standard aeronautical formats described in ICAO Annex 3 [REF9].

TCAT.INP.05 The system shall process input operational environment data in a predefined format.

TCAT.INP.06 The system shall process data for procedures and restrictions in a predefined format

TCAT.INP.07 The system shall process data from Local and sub-Regional Airspace (LARA) management support system [REF10].

TCAT.INP.08 The system shall be able to connect to NMOC B2B and retrieve relevant operational information

TCAT.INP.09 The system shall provide data to a local Human Resource Management tool

TCAT.INP.10 The system shall provide a number of physical interfaces for exchange of data with other systems (FDP, MET, etc.)

TCAT.INP.11 The system shall provide a warning and alarm subsystem in case of missing data flows

TCAT.INP.12 The system's processing facilities shall be interfaced with a redundant LAN providing connectivity, access and openness.

TCAT.INP.13 The system shall use redundant Gigabit Ethernet 1000BASE-T LAN.

TCAT.INP.14 The system shall support IPv4 and IPv6 and be able to communicate over these protocols.

TCAT.INP.15 The system shall be able to receive all incoming information using UDP unicast, UDP multicast and TCP/IP protocols [REF11, REF12 and REF13].

TCAT.INP.16 The system shall be able to transmit all outgoing information using UDP unicast, UDP multicast and TCP/IP protocols [REF11, REF12 and REF13].

TCAT.INP.17 The system shall be able to handle alternative data paths.TCAT.INP.18 In case of loss of data source the system shall select automatically

an alternative data source.TCAT.INP.19 The system shall be able to receive messages in ADEXP (Edition

3.1 or newer) format (necessary for EFD).TCAT.INP.20 The system should be able to process CPR (Correlated Position

Report) messages.TCAT.INP.21 The system should be able to process system track messages

encoded in ASTERIX Category 62 [REF18].

32/81


3.5 AIR SITUATION PREDICTION

TCAT.ASP.01 The system shall build a picture of future air situation for each minute ( or smaller interval) within the look-ahead time window

TCAT.ASP.02 The look-ahead time window for the future air situation prediction shall be no-less than 4 hours

TCAT.ASP.03 The look-ahead time window for the future air situation prediction should be 8 hours or greater

TCAT.ASP.04 Predicted 4D position for each aircraft shall be consistent with the performance of the respective aircraft type

TCAT.ASP.05 The system shall support Base of Aircraft Data (BADA) as a source of aircraft performance models [REF14].

TCAT.ASP.06 Predicted activation of Special use areas and route activation/deactivation shall be consistent with the airspace use plan and other information obtained from LARA [REF10].

TCAT.ASP.07 Predicted 4D position for a flight shall be based on NM Flight Progress messages and data from local FDPS.

TCAT.ASP.07A Additional data sources (e.g. OLDI and/or others) should be included, provided that data integrity is ensured.

TCAT.ASP.08 The system shall automatically select the best available data source for predicting the 4D position of each flight.

TCAT.ASP.09 The air situation prediction shall take into account wind information and forecast.

TCAT.ASP.10 The Air Situation Prediction shall be updated:a. Cyclicallyb. On manual request

TCAT.ASP.11 The system should display warnings when prediction of future air situation is unreliable in accordance with a set of pre-defined reliability criteria.

TCAT.ASP.12 The air situation prediction shall take into account local procedures and local short term ATFCM measures.

TCAT.ASP.13 The system should support BADA Family 3 [REF14] and BADA Family 4.

3.6 TRAFFIC COUNTS, WORKLOAD AND COMPLEXITY

TCAT.WKL.01 The system shall calculate and display 60-minute entry rates for the whole look-ahead time window based on the latest air situation prediction. Method of calculation shall be consistent with the one used by NMOC.

TCAT.WKL.02 The system shall calculate and display 20-minute entry rates for the whole look-ahead time window based on the latest air situation prediction. Method of calculation shall be consistent with the one used by NMOC

33/81


TCAT.WKL.03 The system shall calculate and display occupancy counts for the whole look-ahead time window based on the latest air situation prediction. Method of calculation shall be consistent with the one used by NMOC.

TCAT.WKL.04 The system shall calculate and display complexity/workload metrics for the whole look-ahead time window based on the latest air situation prediction.

TCAT.WKL.05 The system shall enable easy comparison between calculated traffic counts and predicted workload/complexity against appropriate thresholds (60/20 minute declared capacity, OTMVs, qualitative or quantitative worklad/complexity thresholds)

TCAT.WKL.06 The system shall calculate workload and complexity metrics based on a predefined workload/complexity model

TCAT.WKL.07 As a minimum the workload and complexity model shall automatically detect and take into account the following factors of complexity (REF22):

Vertical Evolution Conflicts Integration FLCHG Configuration transitions Exit constraints SUA activation Convective weather Externally induced factors of complexity

TCAT.WKL.08 The workload and complexity model should take into account the following additional factors of complexity (REF22):

Traffic bunching (shall be automatically detected) Traffic heterogeneity (shall be automatically detected) Air policing Major military exercises ATM system changes Non-routine flights Turbulence Winds aloft (shall be automatically detected) Controller training System failures

TCAT.WKL.09 The workload and complexity model and the method for its calibration shall be proposed by the Contractor

TCAT.WKL.10 The Contractor shall further enhance the complexity/workload model in order to ensure optimal model performance in the operational environment of Sofia ACC, taking into account local specifics and needs.

TCAT.WKL.11 Workload and complexity model shall take into account both routine and non-routine workload tasks.

TCAT.WKL.12 It should be possible to manually isolate (remove) any particular complexity factors from the workload and complexity model calculations

TCAT.WKL.13 It should be possible to change the influence of each complexity factor on the final workload and complexity metrics

34/81


TCAT.WKL.14 The system shall be able to calculate and display traffic counts and workload and complexity metrics per sector and per time interval for all sectors, for each sector configuration and for any moment within the look-ahead time window

TCAT.WKL.15 The system should be able to calculate and display customized traffic counts and workload/complexity metric for sectors, based on all traffic passing through a sector, but including or excluding one or more particular traffic flows

TCAT.WKL.16 The system shall generate appropriate warning on the event of sector overload or underload

TCAT.WKL.17 The system should be able to calculate and display the contribution of each individual flight to overall sector workload/complexity together with the related contributing workload and complexity factors at any moment within the look-ahead time window

TCAT.WKL.18 For each sector, the system should be able to calculate and display the contribution of individual complexity factors to overall sector complexity at any point within the look-ahead time window, together with a corresponding flight list

TCAT.WKL.19 The complexity model shall take into account both planner and executive controllers workload.

TCAT.WKL.20 The complexity model shall take into account the effect of local procedures, RAD rules, airspace reservations, weather and local short term ATFCM measures

TCAT.WKL.21 It should be possible to configure the workload and complexity model separately for each sector group/sector family.

TCAT.WKL.22 The system should be able to calculate and display predicted accumulated delay

TCAT.WKL.23 The system should have the ability to accommodate and operate with additional static complexity factors

TCAT.WKL.24 It should be possible to toggle on and off static complexity factors separately for each sector.

Note: A static complexity factor is a factor whose presence in the ATM environment is not dynamically detected by the system, but is manually toggled on/off by an operator. When toggled on or off the overall workload in a sector is changed by a fixed predefined value. An example application of static complexity factor is the presence of “Due Regard” traffic in a sector over the High Seas. Such presence cannot be automatically detected, but it can be indicated to the system by toggling on a static “Due Regard” factor for the respective sector which will increase workload/complexity metrics by a fixed value or percentage (e.g. 5%).

3.7 HMI

TCAT.HMI.1 It shall be possible to interact with the system using a keyboard and a mouse. This does not preclude the use of other complementary means to interact with the system (e.g. touchscreens).

TCAT.HMI.2 The system shall provide a graphical Human Machine Interface.

3.7.1 Radar ViewTCAT.HMI.3The system should provide a predicted radar view.

35/81


TCAT.HMI.4The radar view window should display, for a selected sector and moment in time from the look-ahead time window, the sector boundaries, the predicted position of aircraft within the sector, together with one minute speed vectors and radar labels

TCAT.HMI.5 As a minimum, radar labels should contain A/C callsigns, FL/altitude,speed, aircraft type and an indication for vertical evolution (climb or descend).

TCAT.HMI.6 For each aircraft within the radar view it should be possible to hide and display the trajectory from the current flight plan

TCAT.HMI.7 It should be possible to highlight traffic conflicts in radar view.TCAT.HMI.8 It should be possible to update the radar view window by directly selecting

the requested sector and moment in time from a sector timeline view.TCAT.HMI.9 It should be possible to continuously update the radar view window by

directly selecting from a sector timeline view. ( movie –like replay of predicted situation).

3.7.2 Timeline View

TCAT.HMI.10 The system shall provide a timeline views for workload and complexity metrics and traffic counts for each sector together with relevant threshold values (the sector timeline view)

TCAT.HMI.11 Sector timeline view shall provide a clear indication of the period in which the particular sector is planned and/or proposed to be open.

TCAT.HMI.12 The system shall provide a timeline views of opening scheme plan and proposed OS optimization solutions (The OS timeline view) together with the current state of relevant configurable constraints.

TCAT.HMI.13 The Opening scheme plan and sectors timeline views shall be provided separately for each sector family.

TCAT.HMI.14 It shall be possible to obtain additional details for a particular moment in time by directly selecting from the OS timeline view or sector timeline views.

TCAT.HMI.15 The OS timeline view shall provide on request additional details on the participating sectors and other context information.

TCAT.HMI.16 Sector timeline views shall provide additional details in the form of detailed flight lists and other context information.

TCAT.HMI.17 Sector and OS scheme timeline views shall be complemented with indication of current or planned application of ATFCM measures

TCAT.HMI.18 The length of the timeline view shall be configurable so as to be possible to focus on a period shorter that the maximum look-ahead time window.

TCAT.HMI.19 Timeline views shall provide a clear graphical indication of current and selected time.

TCAT.HMI.20 Timeline views should allow to display a minimum of 1 hour (online configurable to a smaller value) of past data together with current and predicted data.

TCAT.HMI.21 It should be possible to obtain from the timeline view on request additional details in the form of relative contributions of each complexity factor to overall sector complexity, flight lists, together with relative contribution to complexity of each particular flight.

TCAT.HMI.22 The system shall provide a timeline view for SUA activation plan.

36/81


3.7.3 Flow ViewTCAT.HMI.23 The system should provide a traffic flow viewTCAT.HMI.24 Traffic flow view should display a cumulative picture of a selection of

traffic flows TCAT.HMI.25 It should be possible to present the traffic flow view in both 2D format and

3D formatTCAT.HMI.26 It should be possible to present individual flows in different user selected

colors.TCAT.HMI.27 Flow view should provide a graphical and numerical indication of flow

intensityTCAT.HMI.28 Flow view should provide a graphical indication of flow direction of

movementTCAT.HMI.29 It should be possible to obtain a graphical indication of flows and portions

of flows that represent traffic in evolutionTCAT.HMI.30 It should be possible to store a selected flow view in a flow view

repository.TCAT.HMI.31 It should be possible to display and hide the following flow view attributes:

traffic counts, points and navaids, aerodromes of departure and destination, flight levels)TCAT.HMI.32 It should be possible to quickly and easily restore a predefined flow view

from the flow view repository.

3.7.4 Airspace ViewTCAT.HMI.33 The system shall provide an airspace viewTCAT.HMI.34 The airspace view shall comprise the following elements:

FIR boundaries CTA boundaries TMA and CTZ boundaries Family Sector boundaries Selected sectors Navaids and their IDs navigation points and their 5LNC Air routes Major aerodromes Active and non-active special use areas

TCAT.HMI.35 It shall be possible to dynamically display and hide different elements from the airspace view

TCAT.HMI.36 It should be possible to display and hide labels for each visible element, containing element ID, lower and upper limits, type of navaid, as applicable.

TCAT.HMI.37 It shall be possible to present the airspace view in both 2D and 3D format.TCAT.HMI.38 It shall be possible to present different airspace view elements in different

user selected colors.

37/81


3.7.5 Scenario ViewTCAT.HMI.39 The system should provide a scenario viewTCAT.HMI.40 |Scenario view should display ATFM scenarios, their ID, type, status and a

verbal description.

3.7.6 Meteorological ViewTCAT.HMI.41 The system should provide a meteorological viewTCAT.HMI.42 Meteorological view should display current and predicted meteorological

informationTCAT.HMI.43 Meteorological information should include as a minimum wind

information, convective weather information, turbulence and icing information, as well as indication of weather at airports.

TCAT.HMI.44 It should be possible to dynamically display and hide different elements from the meteorological view

3.7.7 Integrated ViewTCAT.HMI.45 The system should provide an integrated graphical view of:

traffic counts and workload/complexity metrics opening scheme plan relevant warnings a radar view airspace view traffic flow view scenario view meteorological view additional elements needed to accurately assess current and future air traffic

situation and to enable related decision-making.TCAT.HMI.46 The integrated view should be configurable, allowing to flexibly display or

hide different elements and sub-elements.

3.7.8 Background mapTCAT.HMI.47 All views (except timeline views and scenario view) shall be presented on a

background map, having the possibility to display and hide the following elements: Prominent geographical features State boundaries Shorelines Territorial water boundaries FIR and CTA boundaries

3.7.9 Flight ListsTCAT.HMI.48 The system shall provide detailed flight lists

38/81


TCAT.HMI.49 It shall be possible to generate detailed flight lists from the context of sector timeline views and traffic flows

TCAT.HMI.50 As a minimum detailed flight lists shall contain the following information for each flight: Entry time, callsign, aircraft type, departure aerodrome, destination aerodrome, registration, flight rules, Requested flight level, Related scenarios, Entry Flight level, exit fight level, traffic type, EOBT, entry point, exit point, relative contribution to sector complexity, ETOT/ATOT

TCAT.HMI.51 Flight lists shall be configurable allowing to display or hide different elements

TCAT.HMI.52 It shall be possible to sort flight lists on any flight list element.

3.7.10 Other HMI requirementsTCAT.HMI.53 It shall be possible to rotate all 2D and 3D viewsTCAT.HMI.54 It shall be possible to tilt all 3D viewsTCAT.HMI.55 The system shall be able to permanently present as a warning which critical

selectable features are toggled on/off.TCAT.HMI.56 The system shall be capable, via appropriate input HMI to edit ‘static’

environment data related to the complexity assessments (e.g. LoAs, airspace changes, procedure changes).

TCAT.HMI.57 The system shall provide the necessary input HMI for defining the ‘What-if’ environment.

TCAT.HMI.58 The HMI shall provide a clear alpha-numeric indication of current UTC date and time.

TCAT.HMI.59 The system should support multiple monitors and to presents different views on different monitors

TCAT.HMI.60 All system’s views should support scaling, resizing and dragging.

3.8 ARCHIVE AND REPLAY

TCAT.ARC.1 The system shall archive all input data received by the system.TCAT.ARC.2 It shall be possible to fully restore and reproduce past system state based on

archived data from a particular past point in time.TCAT.ARC.3 The system should have the possibility to operate entirely based on archive

data allowing the user to interact with the system as if in real operations.TCAT.ARC.4 The system shall provide a clear permanent warning when archived data is

displayedTCAT.ARC.5 It shall be possible to reproduce a particular past situation starting from a

user-selected moment it time.TCAT.ARC.6 It should be possible to reproduce the archived data at normal speed and a

speed faster than normal (fast-forward)TCAT.ARC.7 It should be possible to pause and then resume an archive replay

39/81


TCAT.ARC.8 It should be possible to apply a what-if scenario on archive data in order to assess different hypothetical approaches to past situations.

TCAT.ARC.9 The time period for back-up of archived data shall be configurable and the maximum period shall be at least 365 days

TCAT.ARC.10 Data archiving shall be performed on HDD system with functionality „fault tolerance n-1“(for example RAID)

TCAT.ARC.11 The system shall offer backup of the archived data onto removable media, preferably USB disks or memory sticks

TCAT.ARC.12 The system shall offer off-line backup of the archived data via LAN interface

3.9 SECTOR CONFIGURATIONS AND OPENING SCHEME

TCAT.OS.1 The system shall take into account the Sector Configuration currently is use.TCAT.OS.2 The system shall be able to manage sector configurations, containing multiple

laterally and vertically split sectors, including middle layered sectorsTCAT.OS.3 The system shall be able to manage a flexible division flight level between

vertically split sectorsTCAT.OS.4 The system shall continuously calculate and propose optimum sector

configurations and opening scheme from a list of pre-defined configurations taking into account as a minimum the following constraints:

A defined minimum configuration opening duration (configurable off-line and on-line)

The number of open sectors is minimized The total sum of sector working hours is minimised Workload between sectors is as balanced as possible Sector workload and complexity thresholds are not exceeded or, when

not possible, excess is minimized Transitions between configurations are non-traumatic List of configurations manually excluded from optimisation

TCAT.OS.5 The opening scheme optimization algorithm shall be capable of being parameterized in order to avoid generating excessively frequent changes in proposed optimization solutions in response to minor changes of input data.

TCAT.OS.6 It should be possible to manually exclude ( and include) online one or more particular constraints from the optimization process.

TCAT.OS.7 The system shall allow the creation and modification of an Opening Scheme Plan for each sector family as well as the display of predicted workload/complexity indicators for the sectors before such opening scheme plan is implemented.

TCAT.OS.8 The system shall provide warnings in case the Opening Scheme Plan leads to overload in any of the sectors, clearly indicating the affected sectors and time periods

TCAT.OS.9 The system shall provide warnings in case the Opening Scheme Plan leads to a significant sector underload (inefficient usage of human resource), clearly indicating the affected sectors and time periods

40/81


TCAT.OS.10 In case an overload or underload is detected in the Opening Scheme Plan, the system shall propose a more optimal solution.

TCAT.OS.11 The system should clearly indicate which constraints are better (worse) satisfied by a proposed optimized solution.

TCAT.OS.12 The system shall be able to parse Sector Configurations stored in XML format.

TCAT.OS.13 The system should be able to detect conflicts or inconsistency in the Sector Configurations and provide advisories accordingly.

TCAT.OS.14 The system shall allow modification of pre-defined configuration.TCAT.OS.15 The system shall allow to be added a new configuration to the list of pre-

defined configurations.TCAT.OS.16 The system shall allow to be removed a configuration from the list of pre-

defined configurations.TCAT.OS.17 The system shall allow to be defined/removed/updated sector volumes.

3.10 WHAT - IF

TCAT.WIF.1 The system shall support two types of environments: “current” environment and a “what-if” environment

TCAT.WIF.2 Current environment shall be a permanent one and displayed at all working positions

TCAT.WIF.3 What-if environment shall be a temporary one and local to the working position

TCAT.WIF.4 It shall be possible to create a what-if environment by: Copying all information from the Current Environment Copying all information from another what-if environment

TCAT.WIF.5 It shall be possible to modify the what-if environment without affecting the current environment.

TCAT.WIF.6 It shall be possible to implement a what-if environment as the current environment

TCAT.WIF.7 What-if environments shall enable the comparative assessment of multiple parallel solutions

TCAT.WIF.8 It shall be possible to assess and compare what-if environments at least in the context of traffic counts, workload and complexity, configurations and opening scheme, ATFCM scenarios or a combination thereof.

TCAT.WIF.9 A what-if environment shall allow the assessment of a future hypothetical sectorisation plan

TCAT.WIF.10 A what-if environment shall allow the assessment of the effects of a future hypothetical trajectory modification (an ATFCM measure) for individual flights or flows

TCAT.WIF.11 It should be possible to create a what-if environments based on archived data at any particular past point in time

TCAT.WIF.12 The system should support store/load of what-if configurations in XML files.

41/81


TCAT.WIF.13 The what if environments should be continuously updated in accordance with new information from the current environment.

3.11 ATFCM

TCAT.ATFM.1 The system shall allow the assessment, implementation and monitoring of the effects of trajectory modification for individual flights and traffic flows (ATFCM scenarios) on workload and complexity metrics, traffic counts and optimal opening scheme.

TCAT.ATFM.2 As a minimum it should be possible to describe traffic flows using logical combinations (AND/OR/NOT) of the following attributes:

Departure aerodrome destination aerodrome sectors sector groups navigation points and navaids adjacent FIRs routes aircraft types departure time interval arrival time interval Time-over-point time interval time intervals to enter a specific sectors or FIR time interval to exit a specific sectors or FIR minimum and maximum FL airline time spent within a airspace ATFCM scenario

TCAT.ATFM.3 As a minimum, the following trajectory modifications shall be supported(REF23):

Level Cap – temporary restriction on maximum and/or minimum FL

Re-Route – lateral modification of flight trajectories Minimum departure interval – a time interval for flights

departing specific aerodrome Specific take-off time constraint (not before, not after) for an

aircraft Target time – a specific time for an aircraft over point or

airspace volume entry timeTCAT.ATFM.4 It should be possible to store traffic flow definitions for future reference or

reuseTCAT.ATFM.5 The system shall allow to create and manage a repository of predefined

ATFCM scenarios for future reference and reuse

42/81


TCAT.ATFM.6 The system shall allow the quick assessment of the cumulative effects of a predefined set of local ATFCM scenarios, selectable from a list.

TCAT.ATFM.7 The system should provide a warning when an applied ATFCM scenario is inefficiently applied. An ATFCM scenario is considered to be applied inefficiently when:

It generates excessive workload in any sector; or Does not lead to an unacceptable increase of workload in any sector if

removed.TCAT.ATFM.8 It should be possible to analyse the relative contribution of each predefined

traffic flow to sector traffic counts and workload/complexity (a flow breakdown analysis)

3.12 COLLABORATIVE DECISION MAKING

TCAT.CDM.1 The tool should provide functions for Short Term ATFCM measure coordination as well as support for CDM processes at network level, based on the protocol and requirements as defined by the Network Manager, if these are available at the Effective date of the Contract.

3.13 USER ACCESS

TCAT.UA.1 Operators shall access the system through personal user accounts protected with passwords.

TCAT.UA.2 The system shall provide a user account management function allowing the creation of new user accounts and modification of existing accounts.

TCAT.UA.3 Four levels of personal user accounts shall be available: Administrator, Technical, Operational, Viewer

TCAT.UA.4 Administrator level user shall have unlimited rights to access and manage system parameters

TCAT.UA.5 Operational level user shall have access to all system functions, except: User account management Functions intended to be used by technical staff for system performance

monitoring and maintenance.TCAT.UA.6 Technical level user shall have access to all system functions except:

User account management Functions that may introduce changes to the current operational environment

TCAT.UA.7 Viewer level user shall have all the access rights of an Operational level user, except the possibility to introduce changes in current environment.

TCAT.UA.8 A lock mechanism shall prevent simultaneous logging of more than one Administrator level user.

TCAT.UA.9 A lock mechanism shall prevent simultaneous logging of more than one technical level user

43/81


TCAT.UA.10 A lock mechanism shall prevent simultaneous logging of more than one operational level user

TCAT.UA.11 The system shall allow the simultaneous logging of more than one viewer level user.

TCAT.UA.12 The system working positions shall automatically logout users after pre-defined period of inactivity.

TCAT.UA.13 The system shall use LDAP protocol [REF15] for centralized user roles storage.

3.14 PERFORMANCE

TCAT.PER.1 The maximum time for prediction recalculation after a manual trigger shall be 60 s

TCAT.PER.2 The maximum time for prediction recalculation between automatic updates shall be 60 s

TCAT.PER.3 Maximum response time for manual HMI input shall be 0.5 s.TCAT.PER.4 Minimum number of additional static complexity factors should be 10.TCAT.PER.5 The minimum number of predefined local ATFCM scenarios shall be 30TCAT.PER.6 The system shall support a minimum of 15 working positionsTCAT.PER.7 The minimum number of flights simultaneously managed by the system shall be

5000.TCAT.PER.8 The minimum number of possible pre-defined sector configurations shall be

2500.

3.15 HUMAN RESOURCE MANAGEMENT

TCAT.HR.01 The system shall be able to connect and provide Opening Scheme plan and what-if plans to a local HR management tool.

3.16 PRINTING

TCAT.PRT.1 The system shall be connected to a printer.TCAT.PRT.2 It shall be possible to print a selected view.TCAT.PRT.3 It shall be possible to easily print multiple selected timeline viewsTCAT.PRT.4 It shall be possible to make and print a screen capture of any screen areaTCAT.PRT.5 Each print shall contain a clear indication of the date and time the print was madeTCAT.PRT.6 Each prints shall contain a clear indication of the date and time period for which the information presented on the print is valid.TCAT.PRT.7 It shall be possible to print to a .pdf file.

44/81


3.17 EXPANSION AND MODULARITY

TCAT.EXP.1 The system shall be easily expandable in order to accommodate new data sources without the need for architectural modification.TCAT.EXP.2 The system shall be modular allowing the easy replacement of complexity calculation component without need for architectural modificationTCAT.EXP.3 The system shall easily accommodate new traffic counts and complexity metrics without the need for architectural modification. TCAT.EXP.4 The system shall be able to easily accommodate new sector families without need for architectural modifications

3.18 USER MANUAL

TCAT.DOC.1 The Contractor shall provide a user manual fully describing system features, functions, modes of operations, using text and graphics in order to enable a full understanding of the system.

TCAT.DOC.2 The user manual shall be provided in English.

3.19 ENVIRONMENTAL CONDITIONS

3.19.1 Storage

REQ-ENV-01 Traffic Complexity Assessment Tool equipment, including packaging, shall be capable of storage at weather-protected, partially temperature controlled locations, under the conditions defined within ETSI EN 300 019 1-1 Class 1.1.

3.19.2 Transport

REQ-ENV-02 It is recommended that the system is capable of transportation under the conditions defined within ETSI EN 300 019 1-2 Class 2.3.

3.19.3 Equipment room use

REQ-ENV-03 The Traffic Complexity Assessment Tool central processing (Operational and Test) shall be installed in 19" racks at one location in the equipment room at BULATSA premises.

REQ-ENV-04 The working positions of Traffic Complexity Assessment Tool (Operational) shall be installed in the operational room at BULATSA premises.

REQ-ENV-05 The central processing units shall support connection to a redundant 230 V, 50 Hz power connection.

45/81


4 PROJECT REQUIREMENTS

4.1 GENERAL

4.1.1 Critical Success Factors

BULATSA sees the following as the critical success factors to this project:

The design of a Traffic Complexity Assessment Tool shall satisfy the Technical Requirements provided in chapter 3 of this document.

The installation shall be done in a manner that minimises disruption to air navigation services without compromising safety.

Operation of the Traffic Complexity Assessment Tool should not interfere with, but must enhance other ANS functions.

The Traffic Complexity Assessment Tool provides sufficient support to relevant staff in order to enable efficient operational decision making.

BULATSA shall be capable to support the installed System in accordance with the proposed Support Concept detailed at paragraph 4.4.2 of this document.

The Delivery of the Traffic Complexity Assessment Tool that meets the functional requirements shall be done at the lowest possible life cycle cost.

4.1.2 External Project Dependencies

The tCAT system consumes data from multiple information sources. Some of these data sources are not presently available and their availability is dependent on other related projects.

BULATSA will ensure the coordinated development of all related works, however there is a natural risk that some of these projects run late and do not deliver the required input on time.

The external dependencies of the tCAT project are as follows:

1) Export of trajectory data from FDPS is presently not available and it is subject to a separate contract with ATM System providers. Requirements directly affected are:

- TCAT.INP.02

- TCAT.INP.10

- TCAT.ASP.07

2) The HRM system is presently under development and the interfaces are not defined at the time of preparation of this document. Requirements directly affected are:

- TCAT.INP.02

- TCAT.INP.09

- TCAT.HR.01

46/81


3) The convective weather forecast model is under development. It is expected to become operational at the end of 2017. Requirements directly affected are:

- TCAT.INP.02

- TCAT.INP.04

- TCAT.WKL.07

- TCAT.HMI.42

- TCAT.HMI.43

If the risks above are realised the affected requirements should be verified, as far as reasoanably practicable, using simulated data.

4.1.3 Scope of Work

The project scope is to:

a. design, manufacture, deliver, install, calibrate and verify the System that comply with this System Specifications;

b. Manufacture, deliver, install, verify the Deliverables that comply with the Project requirements;

c. provide the Support Services during the Warranty Period (see paragraph 4.4.5 of this document).

The Traffic Complexity Assessment Tool equipment shall be installed at the BULATSA premises (equipment and operational room) using the existing support infrastructure, to the extent possible, which comprise:

a. equipment room;

b. power sub-systems; and

c. air-conditioning sub-systems.

4.1.4 Contractor Responsibilities

REQ-PRJ-GEN-01 The Contractor shall be responsible for designing, supplying and installing fully functional Traffic Complexity Assessment Tool, that:

a. is suitable in all respects for operation and maintenance by BULATSA for the purpose of providing a civil Air Navigation Service;

b. meets the requirements of the System Specifications; and

c. ensures that the project is completed within the required project timings.

d. Meets the requirement of applicable international standards and regulations

REQ-PRJ-GEN-02 Contractor’s responsibilities shall include:

a. project management;

47/81


b. undertaking Acceptance verification in accordance with the Verification Management Plan (VMP), including, unless otherwise agreed by BULATSA, provision of test equipment required to perform Acceptance verification;

c. designing and providing plans and documentation for specific physical interfaces;

d. designing and providing all System electrical and electronic interfaces as defined in Interface Control Documents (ICD) to be delivered and approved in accordance with the Contract Data Requirements List (CDRL) and the Contract;

e. Installing, calibrating and integrating the system in the operational and technical environment of Sofia ACC in order to enable safe and efficient system operation.

f. training BULATSA technical and operational staff to operate and maintain the Traffic Complexity Assessment Tool;

g. supervising BULATSA staff in the supplementary installation tasks;

h. developing, delivering and updating as required any plans, report or documentation specified in the CDRL at Appendix B and in accordance with the Contract;

i. conducting logistics engineering activities in accordance with the Integrated Logistic Support Plan (ILSP); and

j. providing the Support Services during the Support Period to ensure the Availability requirements of the System (as defined in the Technical Specifications TCAT.RAM.20]) are met when BULATSA operates and maintains the System to the manufacturer’s recommended procedures and standards.

4.1.5 BULATSA Operations

BULATSA will:

a. maintain operational services for the period of the installation specified in the Project Management Plan (PMP);

b. conduct maintenance in accordance with the Support Concept (see paragraph 4.4.2 of this document) to the manufacturer’s recommended procedures and standards as defined in the manufacturer’s provided handbooks and procedures using the delivered spares, consumables and tools;

c. undertake decommissioning action of any equipment that is required to be turned off or removed in order to permit installation or commissioning of the Traffic Complexity Assessment Tool to proceed; and

d. support the Contractor in the installation and calibration tasks of the Traffic Complexity Assessment Tool;

e. be responsible for providing the required data communication links within the Traffic Complexity Assessment Tool.

4.1.6 Project Timings

REQ-PRJ-GEN-03 The Contractor shall deliver and install the Supplies in accordance with the Contract Master Schedule (CMS).

48/81


4.1.7 Single Contractor

BULATSA intends to award a single contract for the implementation of the Traffic Complexity Assessment Tool as detailed in this document.

4.1.8 Precedence of Documents

REQ-PRJ-GEN-04 In the event of conflict or ambiguity between the requirements or recommendations of specifications, standards or references then the documents shall have precedence in the following order:

a. this System Specifications;

b. the Bulgarian Standards;

c. the EC Community Specifications

d. the International Standards; and

e. references as listed in this System Specifications.

4.2 PROJECT MANAGEMENT

4.2.1 Project Management Experience

BULATSA is seeking to appoint a Contractor with experience in the development of air traffic complexity management systems.

The Contractor will be required to design, deliver and support Traffic Complexity Assessment Tool promptly, diligently and in a professional manner, in accordance with the practices and high professional standards used in well managed operations in performing services similar to the services required in relation to this System Specifications.

4.2.2 Project Planning

A key to the success of this project is the development of a suite of project planning documentation.

REQ-PRJ-PM-01 The Contractor shall prepare and update throughout the term of the Contract the planning documentation detailed in this document.

REQ-PRJ-PM-02 The Contractor shall produce, deliver and update planning documentation in accordance with the CDRL and the Contract.

BULATSA will review, approve or not approve, accept or reject documents submitted by the Contractor.

4.2.2.1 Project Management Plan (PMP)

REQ-PRJ-PM-03 Contractor shall produce and maintain a Project Management Plan (PMP);

REQ-PRJ-PM-04 The Contractor shall manage the project in accordance with the PMP.

49/81


The PMP is to provide an overview of the different project processes and how they fit together to form a totally integrated management system for the project. The PMP is the primary management plan for the Contract.

REQ-PRJ-PM-05 The Contractor shall use the PMP, including or supplemented by subordinate plans, to provide direction and guidance to the Contractor’s management team responsible for conduct of the work.

BULATSA will use the PMP to:

a. gain visibility into the Contractor’s planning;

b. understand and evaluate the Contractor’s approach to managing the project; and

c. provide input into BULATSA’s planning.

REQ-PRJ-PM-06 The Contractor shall document in the PMP, and update as required, the responsibilities and accountabilities for Key Staff Positions.

REQ-PRJ-PM-07 At a minimum the PMP shall:

a. give a brief overview of the System being developed and its purpose, clearly stating the operational capability that the System is delivering;

b. outline the scope of work undertaken for this project, including the scope undertaken by the Contractor and approved subcontractors;

c. identify the key functions of the System;

d. identify major subsystems;

e. describe the objectives related to success of the overall project. Project objectives may be related to capability, cost, quality, schedule, risk, and other outcomes as appropriate;

f. detail the Contractor’s project management organisation;

g. detail all subordinate plans being utilised throughout the project; and

h. identify major interfaces between organisations.

4.2.2.2 Contract Master Schedule (CMS)

REQ-PRJ-PM-08 The Contractor shall deliver/provide and install the System in accordance with the Contract Master Schedule (CMS).

REQ-PRJ-PM-09 The CMS shall graphically depict the Contractor’s planned sequence of activities, Milestones and decision points to enable the objectives of the Contract to be met.

REQ-PRJ-PM-10 The Contractor shall develop a CMS using a scheduling software package such as Microsoft Project or a suitable alternative

REQ-PRJ-PM-11 The Contractor shall use the CMS, including or supplemented by subordinate schedules, to:

a. plan the activities and sequencing of those activities to achieve the requirements of the Contract; and

b. provide schedule direction and status to the management team responsible for conduct of the work.

50/81


BULATSA will use the CMS to:

a. gain visibility into the Contractor’s planning;

b. understand and evaluate the Contractor’s approach to meeting the requirements of the Contract;

c. assist with monitoring the progress of the Contractor in meeting the requirements of the Contract; and

d. as a source of input to planning performed by BULATSA.

REQ-PRJ-PM-12 At a minimum the CMS shall identify:

a. all activities (including Contractor’s, subcontractor’s and BULATSA ’s activities) and their estimated durations;

b. all linkages to other schedules required as part of this document;

c. all Milestones, including Key Milestones;

d. the relationships and dependencies between activities and Milestones to be accomplished by or for the Contractor in the performance of its obligations under the Contract;

e. earliest and latest start and finish dates for all activities and Milestones;

f. any critical paths; and

g. float available on all activities and Milestones.

4.2.3 Project Monitoring and Control

4.2.3.1 Progress Status Reports (PSR)

REQ-PRJ-PM-13 The Contractor shall prepare and deliver PSRs in accordance with the CDRL and the Contract.

REQ-PRJ-PM-14 The PSR shall be the Contractor’s principal statement and explanation of the status of the project at the end of each reporting period.

REQ-PRJ-PM-15 The Contractor shall use the PSR to inform BULATSA and to provide regular updates on:

a. progress;

b. planned activities.

c. project issues and risks

BULATSA will use the PSR:

a. to assist with monitoring the performance of the Contractor under the Contract; and

b. as one of the documents that forms the historical record of contractual performance.

REQ-PRJ-PM-16 Progress Status Reports shall contain, at a minimum, the following information:

51/81


a. a summary of significant work activities or issues (including those undertaken by subcontractors) being undertaken or requiring to be addressed in the current reporting period;

b. a summary of significant work activities or issues expected to be undertaken or requiring to be addressed in the next reporting period;

c. a summary of progress against the Contract Master Schedule (CMS); and

d. a summary of the current status of all Contract deliverables;

e. project risks and status

4.2.3.2 Progress Meetings

REQ-PRJ-PM-17 The Contractor shall conduct and administer progress meetings in conjunction with BULATSA, at intervals no greater than 3 months, at times and venues to be agreed with the BULATSA Project Manager.

Progress meetings could be combined with System Reviews where possible.

REQ-PRJ-PM-18 Unless otherwise agreed by BULATSA, the Contractor shall be responsible for:

a. the provision of facilities, materials and services that are reasonably required to conduct the Progress Meeting; and

b. the preparation and delivery of all Progress Meeting agendas and meeting minutes in accordance with the CDRL.

4.2.4 Risk Management

REQ-PRJ-PM-19 The Contractor shall implement a risk management program for the project in accordance with the RMP.

REQ-PRJ-PM-20 The RMP shall outline the Contractor's procedures for identifying, capturing, analysing, assessing, prioritising, monitoring and reviewing project risks and detail the responses required to handle those risks

REQ-PRJ-PM-21 The Contractor shall use the RMP to define the organisational elements and procedures that it will apply to the management of risk throughout the Contract period.

REQ-PRJ-PM-22 The RMP at a minimum shall include detail of:

a. the risk management organisation to be applied to the project, including clear definitions of responsibilities for the project management, the systems engineering and the ILS aspects of risk management; procedures for identifying and capturing risks;

b. procedures for analysing risk;

c. procedures for monitoring and reviewing risks; and

d. the Contractor’s process for integrating the risk management activities into project planning and control.

52/81


4.2.5 System Design

4.2.5.1 Interface Management

REQ-PRJ-ENG-01 The Contractor shall be responsible for the identification, definition, development, management, installation, set to work and testing of all internal and external interfaces.

Note: The Contractor shall specify the required parameters of the communication links within the system.

REQ-PRJ-ENG-02 The Contractor shall design and provide all System electrical and electronic interfaces as defined in the Interface Control Document (ICD). The ICD shall be delivered and approved in accordance with the Contract Data Requirements List (CDRL) and the Contract.

BULATSA will provide assistance to the Contractor in performing this activity.

4.2.5.2 System Design Review

REQ-PRJ-ENG-03 At the completion of the design phase, the Contractor shall hold the SDR.

REQ-PRJ-ENG-04 The Contractor shall present to BULATSA for approval the following minimum set of requirements:

a. a detailed System Specification;

b. human machine interface configuration for the operational working positions;

c. human machine interface configuration for the Technical Control and Monitoring System;

d. project plans;

e. risks;

f. an updated Contract Master Schedule;

g. interface designs, including software interfaces;

h. acceptance verification plans and procedures.

i. updated versions of generic FHA and PSSA (if available);

j. updated installation and calibration plans;

k. Technical Documentation and engineering drawings.

4.2.6 Software Management

In order for BULATSA to prepare safety related documentation for the Bulgarian Civil Aviation Authority (CAA), there must be relevant information on software development plans, procedures and processes for each software-based system that contribute to the tools used for the separation and control of aircraft.

REQ-PRJ-ENG-05 The Contractor shall present evidence for all software activities, corresponding to various SWALs of used software.

53/81


4.2.7 Technical Documentation and Engineering Drawings

REQ-PRJ-ENG-06 The Contractor shall deliver the Specifications and Design Documentation defined by the Technical Documentation List in accordance with the approved CMS.

REQ-PRJ-ENG-07 The Technical Documentation List (TDL) shall identify all of the Technical Documentation and engineering drawings to be provided to meet the Contract requirements.

REQ-PRJ-ENG-08 The TDL shall include, as a minimum:

a. a description of each document to be provided;

b. the format (hard and/or soft copy);

c. the revision status;

d. the quantities for delivery; and

e. the related system, sub system or LRUs.

4.2.8 Specialty Engineering

4.2.8.1 Reliability, Maintainability and Availability Analysis

REQ-PRJ-ENG-09 The Contractor shall undertake an RMA analysis of the System in accordance with the RMA Plan.

4.2.8.2 RMA Plan

REQ-PRJ-ENG-10 The RMA Plan should describe:

a. methodology, techniques and processes used to conduct the RMA analysis;

b. source of reliability data and method of estimation against each item for which data is provided;

c. assumptions, System architecture information, reliability and maintainability block diagrams down to LRU level, and other supporting information (e.g. Spares Procurement Time, etc) to demonstrate compliance with the specified RMA requirements.

4.2.8.3 Safety

The introduction of any system with significant impact on ATM safety into service requires the submission of Safety Case to the DG CAA (Directorate General Civil Aviation Administration) for acceptance. BULATSA will subcontract safety activities on the tCAT project.

REQ-PRJ-ENG-11 The Contractor shall assist BULATSA and any third party safety contractor in producing the Safety case for the Traffic Complexity Assessment Tool. This shall include supporting with expertise, documentation and any other required input for the preparation of a FHA, PSSA and SSA of the supplied system as well as to provide all reasonable assistance to enable BULATSA to achieve Certification of the System by DG CAA.

54/81


REQ-PRJ-ENG-12 The Contractor shall ensure the presence of staff with appropriate expertise on FHA, PSSA and SSA sessions. A maximum of 6 sessions are expected with a duration of 2 working days each.

Safety meetings will be held in Sofia at BULATSA Headquarters

REQ-PRJ-ENG-13 The Contractor shall provide a Fault Modes Effects Analysis (FMEA) to assess the safety impact of equipment failure and degraded modes of operation. The fault modes analysis should cover conceivable faults or eventualities affecting system performance, including the possibility of human errors, common mode failures, simultaneous occurrences of more than one fault, and external eventualities which cause or result in the loss of, or affect the integrity of, external data, services, security, power supply, or environmental conditions. The results of the FMEA will be required to be delivered in a FMEA Report in accordance with the CDRL and reviewed at the System Review.

REQ-PRJ-ENG-14 The Contractor shall present a Safety Plan for its safety activities planned with the corresponding schedule; and a methodology used for the safety assessment and developing the Safety Assessment Documents.

REQ-PRJ-ENG-15 During the installation and pre-commissioning phase, the Contractor shall assist BULATSA to validate the hazard assessment and to develop safety related operational, engineering and/or management procedures to mitigate or control the identified risks.

4.2.8.4 Software Safety

REQ-PRJ-ENG-16 The Contractor shall produce evidence and arguments that demonstrate the following:

a. the software safety requirements correctly state what is required by the software, in order to meet safety objectives and requirements;

b. traceability is addressed in respect of all software safety requirements;

c. the software implementation contains no functions which adversely affect safety;

d. the software satisfies its requirements with a level of confidence which is consistent with the criticality of the software;

e. assurances are provided confirming that the general safety requirements set out in points (a) to (d) are satisfied, and the arguments that demonstrate the required assurances are at all times derived from:

a known executable version of the software;

a known range of configuration data;

a known set of software products and descriptions, including specifications, that have been used in the production of that version.

REQ-PRJ-ENG-17 The Contractor shall allocate software assurance levels to all operational software in compliance with the requirements set out in EC Regulation 482/2008 Annex I;

REQ-PRJ-ENG-18 The contractor shall include assurances of [REF16]:

55/81


a. software safety requirements validity in compliance with the requirements set out in EC Regulation 482/2008 Annex II, Part A;

b. software verification in compliance with the requirements set out in EC Regulation 482/2008 Annex II, Part B;

c. software configuration management in compliance with the level of confidence as the relevant software assurance level, whenever the requirements set out in EC Regulation 482/2008 Annex II, Part C; are defined.

d. software safety requirements traceability in compliance with the requirements set out in EC Regulation 482/2008 Annex II, Part D;

The Contractor shall guarantee that assurances corresponding to each software assurance level give sufficient confidence that the software can be operated tolerably safely.

4.3 SYSTEM INSTALLATION

4.3.1 General

Installation of the Traffic Complexity Assessment Tool, set to work and initial testing at Site will require careful planning and coordination with BULATSA and other stakeholders.

BULATSA will coordinate all installation work, in consultation with Contractor.

4.3.2 Use of BULATSA Personnel

BULATSA personnel will be used for all installation tasks that could cause change to existing operational ATC systems or disrupt the normal operation of the ATM system(s) in compliance with Bulgarian CAA requirements.

BULATSA will make available its own staff to participate in the installation and site Acceptance activities, under the supervision of the Contractor.

BULATSA will make available own staff with appropriate competences to participate in any activities related to the calibration of the workload and complexity models or other parameterisation of the system that require extensive knowledge of local environment.

4.3.3 Installation Management Plan

REQ-PRJ-INST-01 The Contractor shall manage the installation program in accordance with the Installation Management Plan (IMP).

The Installation Management Plan describes the Contractor’s proposed plans, resources, schedules and procedures for undertaking the installation of the agreed design solution.

The IMP should be used by the Contractor to provide guidance to the installation team.

REQ-PRJ-INST-02 The IMP at a minimum should:

a. describe how the Contractor will manage the installation of the agreed System design;

b. describe how the Contractor will approach the parameterisation of the system to the local environment

56/81


c. identify installation Milestones and the sequence of significant activities/tasks that the Contractor will undertake during installation of the System;

d. detail the delivery, installation, calibration and testing schedule in the form of a summary GANTT chart;

e. describe the intended installation and calibration procedures and work practices that will be used by the Contractor;

f. describe the Contractor’s installation team structure and the interface with BULATSA personnel; and

g. detail the scope of work of installation and calibration activities to be performed by BULATSA.

h. Detail any BULATSA’s resources anticipated to be used during the installation and the calibration of the system.

4.3.4 Installation Responsibilities

REQ-PRJ-INST-03 Unless otherwise explicitly agreed, the Contractor shall provide all methods, tools and equipment required for installing, calibrating and verifying the System.

BULATSA will be able to provide local simulator facilities for a limited period of time, if this is required for fine-tuning the behaviour of any models integrated into the system.

REQ-PRJ-INST-04 The Contractor shall supply any additional items required to install the System at Site, including but not limited to: cable, cable support kits, cable ties, labels, earthing and lighting protection elements.

REQ-PRJ-INST-05 The Contractor shall comply with all security and access arrangements required by BULATSA and the respective authorities. All Contractor personnel involved in the installation program shall be able to obtain the appropriate security certification

The Installation Site Management

BULATSA will provide the Contractor with access to BULATSA facilities for installation and testing, subject to personnel complying with security requirements (see paragraph 4.3.4 of this document).

BULATSA will provide staff to accompany Contractor personnel at BULATSA facilities.

The Contractor will be required to ensure that any radio communications or other devices, tools and equipment used by personnel installing the Supplies do not interfere with any other BULATSA systems in any way.

4.4 INTEGRATED LOGISTIC SUPPORT

4.4.1 Introduction

REQ-PRJ-ILS-01 The Contractor shall propose an Integrated Logistics Support program that meets the following objectives:

a. long term supportability;

57/81


b. minimisation of Life Cycle Cost (LCC).

REQ-PRJ-ILS-02 The Contractor shall:

a. provide a logistics package that includes documentation, tools, spares, training and other related items to allow BULATSA to safely support and maintain the Traffic Complexity Assessment Tool in accordance with the Support Concept (see paragraph 4.4.2 of this document);

b. manage and implement the logistics program in accordance with the Integrated Logistics Support Plan (ILSP); and

c. provide the Support Services (see paragraph 4.4.5 of this document) during the Support Period to ensure the System meets the Performance and Availability requirements when operated and maintained by BULATSA in accordance with the manufacturer’s recommended procedures and standards.

4.4.2 BULATSA Support Concept

4.4.2.1 General

The Support Concept comprises hardware maintenance as defined in the Hardware Support Concept and software maintenance as defined in the Software Support Concept.

4.4.2.2 Hardware Support Concept

4.4.2.2.1 Overview

System level maintenance (Level 1) tasks will be performed on a 24 hour basis by BULATSA technical staff using the Technical monitoring and control system (TMCS) facilities provided with the System.

Corrective and preventative maintenance (Level 2) tasks will be performed by BULATSA staff located at BULATSA premises when necessary to respond to fault situations.

LRU repair (Level 3) will be performed by the Contractor unless proven that repair by BULATSA is more cost effective.

4.4.2.2.2 System Level Maintenance (Level 1)

BULATSA staff, after completion of training, should be able to reconfigure the System using the TMCS facilities provided with the Traffic Complexity Assessment Tool to overcome element failure by equipment substitution where the System does not perform this task automatically.

In the event of an LRU failure, system level technical staff should be capable of isolating the fault to LRU level to a high degree of certainty and then carry out the LRU exchange or perform other necessary repairs.

4.4.2.2.3 Preventative Maintenance (Level 2)

Preventative Maintenance involves performing system alignments and tuning to ensure that equipment operating conditions and parameters are maintained within bounds of documented as normal and periodic update of the system Database DB. Preventative Maintenance also involves housekeeping tasks such as cleaning of air filters, management of system log files, etc.

58/81


The System should operate with a minimum need for preventative maintenance, particularly where this would cause an interruption to service.

4.4.2.2.4 Corrective Maintenance (Level 2)

Corrective maintenance involves isolation of a fault to LRU level (if not automatic) or component replacement for those elements of the Traffic Complexity Assessment Tool not suitable for repair by LRU substitution. Corrective Maintenance also includes system reconfigurations, installation and testing of new software and data and testing of the System after.

4.4.2.3 Software Support Concept

The Software Support Concept comprises the following tasks to be performed by BULATSA:

a. Configuration Management for the software, firmware and data, which includes verification of the configuration status (version) of all new software, firmware and data before releasing for operational use;

b. Testing of a new release of software and data.

4.4.3 ILS Plan

REQ-PRJ-ILS-03 The Integrated Logistics Support Plan (ILSP) shall describe the Contractor’s program for covering the ILS requirements of the Contract, including:

a. the major activities to be undertaken, when, and by whom (including subcontractors);

b. the proposed interfaces between BULATSA and the Contractor;

c. the expectations of the Contractor with respect to BULATSA; and

d. the provision of any training to BULATSA personnel, including details of proposed courses and proposed timeframes for those courses.

4.4.4 Support System Implementation

4.4.4.1 Spares

REQ-PRJ-ILS-04 The Contractor shall provide Spares and Consumables in accordance with the Spares and Consumables List (SCL). The proposed quantity of spares shall meet the availability requirements in the most cost effective manner, taking into consideration the long lead time and provide sufficient quantities of Spares and Consumables during the Support Period.

4.4.4.2 Technical Documentation

REQ-PRJ-ILS-05 Contractor shall provide a complete set of documentation for the System, including System manuals, operator handbooks and procedures to allow:

a. BULATSA technical staff to support and maintain the System to meet the availability requirements; and

59/81


b. BULATSA operational staff to operate the System and provide an operational ATS and ATFCM service.

REQ-PRJ-ILS-06 As a minimum the technical documentation shall cover:

a. System restoration - via reconfiguration using the TMCS or other means;

b. Design Documentation that include: overall System architecture drawings, diagrams and a descriptive overview of each sub-system and function provided by the System;

c. corrective maintenance;

d. preventative maintenance; and

e. software maintenance tasks.

REQ-PRJ-ILS-07 The documentation to support corrective maintenance shall, at a minimum, include:

a. System specifications;

b. Commercial Off the Shelf (COTS) equipment manuals and handbooks;

c. maintenance procedures;

d. quick reference guides;

e. user manuals;

f. operator manuals;

g. test and verification procedures;

h. installation manuals/procedures;

i. schematic diagrams, drawings, cable schedules and part lists;

j. circuit diagrams (where applicable); and

k. software and data release checklist and procedures.

REQ-PRJ-ILS-08 The documentation to support preventative maintenance shall, at a minimum, include:

a. performance inspections schedule;

b. performance inspections checklist and procedures;

c. maintenance procedures;

d. quick reference guides;

e. installation manuals/procedures;

f. schematic diagrams, drawings, cable schedules and part lists; and

g. circuit diagrams (where applicable).

REQ-PRJ-ILS-09 The documentation to support the software maintenance tasks shall, at a minimum, include:

a. system specifications;

b. COTS software manuals and user guides;

60/81


c. software user manuals;

d. software installation manuals;

e. software procedures and checklists;

f. software specifications and design documents (where applicable); and

g. software configuration management documents.

REQ-PRJ-ILS-10 The Contractor shall provide a complete set of Operational documentation for the System, including operator handbooks and procedures to allow BULATSA staff to operate the System. The documentation shall fully describe the system features, function, modes of operation, using text and graphics in order to enable a full understanding of the system.

REQ-PRJ-ILS-11 The Contractor shall deliver the Technical Documentation defined by the TDL in accordance with the approved CMS.

REQ-PRJ-ILS-12 The Contractor shall deliver the following quantities of Technical Documentation:

one set of Technical Documentation (hardcopy) of the equipment provided to the Technical staff;

one master set of all Technical Documentation (hardcopy) provided to the Project Manager; and

one master set of all Technical Documentation (softcopy) provided to the Project Manager.

REQ-PRJ-ILS-13 The Contractor shall ensure that all Technical Documentation is in English, accurate, grammatically correct, technically correct and suitable for use.

4.4.4.3 Support and Test Equipment

REQ-PRJ-ILS-14 The Contractor shall provide all specialised support and test equipment that will reasonably be required by BULATSA personnel to:

install and support the System;

isolate faults to LRU level;

support and maintain the System in accordance with the Support Concept; and

meet the availability requirements.

4.4.5 Support Services during the Warranty Period

REQ-PRJ-ILS-15 During the Warranty Period, the Contractor shall be responsible for:

a. ensuring that the performance of the System (down to LRU level) meets the reliability and maintainability figures derived from the availability requirements in the RMA Plan;

b. ensuring all logistic items (e.g. handbooks, manuals, procedures, spares, etc.) delivered are accurate and adequate for BULATSA staff to maintain the System in accordance with the Support Concept to achieve the availability requirements; and

61/81


c. rectifying all software and System defects in a timely manner consistent with the availability requirements.

REQ-PRJ-ILS-16 During the Warranty Period the Contractor shall provide Hardware Support Services and Software Support Services.

REQ-PRJ-ILS-17 During the warranty period the Hardware Support Services shall include:

a. ensuring all items (equipment, spares, tools, documentation, test equipment) provided are sufficient to ensure the availability requirements are covered at all times;

b. ensuring the Turn Around Times for all LRUs returned to be repaired/replaced (Level 3 Maintenance) are met to ensure the availability requirements are covered at all times;

c. providing updates to documentation (manuals, handbooks, drawings, etc.) to accurately reflect the configuration of any items that have been subject to rework/redesign;

d. providing technical assistance via phone and e-mail on an as required basis.

REQ-PRJ-ILS-18 During the warranty period the Software Support Services shall include:

a. providing new releases of software and firmware to rectify defects in a timely manner to ensure the availability requirements are met at all times;

b. providing configuration management documentation (e.g. a Version Description Document) to accurately describe the changes for new releases of software and firmware and the testing conducted to rectify software problems. All the changes shall meet the requirements of EC regulation 482 and EUROCAE ED109 (par. 4.7.7.1 CNS/ATM change control process);

c. providing updates to documentation (manuals, handbooks, etc) to accurately reflect the configuration of any items that have been subject to rework/redesign;

d. providing detailed documentation of the proposed changes in each update and their possible impact;

e. providing technical assistance via phone and e-mail on as required basis.

REQ-PRJ-ILS-19 During the warranty period the contractor should continuously collect record and analyse data from other installation sites about accidents, incidents or other operational events that may have impact on safety of operations and reveal:

system deficiencies;

documentation inaccuracies;

equipment misuse;

training insufficiencies;

software and hardware defects; and

other shortcomings.

62/81


Such data should be provided without delay to BULATSA together with any relevant recommendations on how to prevent potentially negative impact on BULATSA operations.

4.5 TRAINING

4.5.1 General

REQ-PRJ-TRN-01 The Contractor shall conduct a competency based Training to BULATSA technical and operational staff in accordance with the Training Plan. Trainings shall be conducted at BULATSA’s premises, except for Preliminary training, which shall be carried out at Contractor’s premises.

REQ-PRJ-TRN-02 The Training for technical staff shall be consistent with the Support Concept (see paragraph 4.4.2 of this document).

REQ-PRJ-TRN-03 The Contractor shall issue a training certificate to each student that successfully completes the training program.

REQ-PRJ-TRN-04 The Contractor shall provide sufficient instructor training material (lesson plans, presentations, etc.) to BULATSA operational and technical staff.

4.5.2 Training Plan

REQ-PRJ-TRN-05 The Training Plan shall address, at a minimum:

a. the provision of draft training materials including lesson plans, syllabi, durations, training module descriptions for review and approval by BULATSA;

b. the duration of the training sessions (Note: training sessions should not exceed 6 hours per day); and

c. the class size per training session:

The Contractor should use the Training Plan to define, manage and monitor the training activities under the Contract and ensure that those parties (including subcontractors) who are undertaking activities related to training understand their respective responsibilities, the processes to be used and the time frames involved.

BULATSA will use the Training Plan to understand and evaluate the Contractor’s approach to meeting the requirements of the Contract for training and to identify and understand BULATSA involvement in the Contractor’s activities related to training.

4.5.3 Maintenance Training

REQ-PRJ-TRN-06 The Contractor shall propose the following levels of training in accordance with the proposed Support Concept (see paragraph 4.4.2 of this document), as follows:

a. Maintenance Training, for staff that will undertake Level 1 and 2 Maintenance on the data processing equipment in the centre as described at paragraphs 4.4.2.2.3 and 4.4.2.2.4 of this document.

63/81


Note: The Level 2 Maintenance Training shall also include:

Software maintenance Training for the creation, maintenance, testing, configuration control and distribution of new software. The course should also cover the use of any tools provided; and

System level training is required to enable BULATSA maintenance staff to be able to monitor and analyse System performance and anomalies. The course should include use of any special tools and Site setup and configuration that is not part of normal maintenance.

The estimated quantity of BULATSA staff requiring Maintenance Training is detailed in the following table:

Table 1: Maintenance Training

Training Total for Training Max attend per Course

Level 1/2 Traffic Complexity Assessment Tool Data Processing

21 7

Technical Training Objectives

BULATSA training objectives for maintenance staff is to have its technical staff competent to such extent, as to be able to install and maintain the System.

REQ-PRJ-TRN-07 Training shall ensure that Technical staff:

a. understand the System and the major segments and sub-systems;

b. understand the data flows, relationships and the dependencies between the System and the interfaces;

c. understand the Support Concept (see paragraph 4.4.2 of this document) and maintenance tasks to be performed by BULATSA;

d. understand how performance monitoring and optimisation is performed;

e. understand how to use the maintenance, test and realignment procedures;

f. understand the software functionality and are capable of performing effective isolation of software from hardware faults;

g. are capable of performing fault diagnosis and correction by using the maintenance tools; and

h. are capable of performing all corrective and preventative maintenance tasks necessary to maintain the System to meet the Ao requirements.

BULATSA training objectives for software support staff is at a minimum to ensure that the staff can effectively support the System in accordance with the Software Support Concept.

4.5.4 Operational Training

REQ-PRJ-TRN-08 The Contractor shall propose training for BULATSA operational staff.

64/81


REQ-PRJ-TRN-09 Training for operational staff shall enable BULATSA operational personnel as a minimum to:

a) understand the complexity management conceptb) understand the system and the major segments and subsystemsc) understand any modelling concepts that are integrated into the systemd) Become familiarized with all system functions needed to execute their

operational dutiese) understand system limitations and any inherent constraints

The estimated quantity of operational staff requiring training is maximum 21 persons with a maximum of 7 attendees per course.

REQ-PRJ-TRN-10 The Contractor shall propose extended training for a limited number of operational staff in order to enable them:

Understand in detail the logic, operation, parameters and interaction of workload and complexity models, aircraft models or any other models of the operational environment built into the system.

Change the parameters of the models in order to fine-tune system behaviour to the constantly changing operational environment in Sofia ACC

The estimated maximum quantity of operational staff requiring extended training is 7 persons.

4.5.5 Preliminary Training

REQ-PRJ-TRN-11 The Contractor shall propose preliminary training (before FAT) for BULATSA staff in order to enable participation of BULATSA staff in FAT.

REQ-PRJ-TRN-12 Preliminary training shall be offered for both operational and technical staff and shall be consistent with the requirements of 4.5.3 and 4.5.4.

The estimated maximum number of BULATSA staff for preliminary training is 8 persons (4 persons from operational staff and 4 persons from technical staff)

4.6 CONFIGURATION MANAGEMENT

4.6.1 Overview

REQ-PRJ-CFG-01 The Contractor shall manage the configuration of the Traffic Complexity Assessment Tool for the period from the Effective Date until Acceptance of the System in accordance with the Configuration Management Plan.

4.6.2 Configuration Management Plan

REQ-PRJ-CFG-02 The Contractor shall provide project wide management and coordination of all Contractor and subcontractor configuration management activities.

REQ-PRJ-CFG-03 The Configuration Management Plan (CMP) shall define the Contractor’s policy, procedures and responsibilities for configuration management during the conduct of the Contract

REQ-PRJ-CFG-04 The CMP should:

65/81


a. describe the configuration management organisation and processes for the Contract;

b. identify and detail the integration of configuration management functions with other Contract activities; and

c. detail BULATSA involvement and responsibilities in the Contractor’s CM process.

4.6.3 Configuration Identification

REQ-PRJ-CFG-05 The Contractor shall identify all Configuration Items (CIs) and in particular hardware and software CSCIs.

4.6.4 Software Configuration Management

REQ-PRJ-CFG-06 The Software Configuration Management process includes the activities of configuration identification, change control, baseline establishment, and archiving of the software product, including the related software life cycle data and should generate evidence of the following activities:

a. Configuration items are identified;

b. Baselines and traceability are established;

c. Problem reporting, change control, change review, and configuration status accounting are established;

d. Archive, retrieval, and release are established;

e. Software load control is established; and

f. Software life cycle environment control is established.

4.7 VERIFICATION

4.7.1 Verification Management

4.7.1.1 General

REQ-PRJ-VRF-01 BULATSA shall require the Contractor to establish and maintain a progressive verification of the various System elements throughout the development, integration and delivery process in accordance with the Verification Management Plan.

REQ-PRJ-VRF-02 BULATSA shall require the Contractor to ensure and declare, by means of the EC declaration of conformity or suitability for use that he has applied the provisions laid down in the essential requirements and in the relevant implementing rules for interoperability. Contractor shall prepare a draft Declarations of conformity or suitability for use of constituents of Traffic Complexity Assessment Tool according to the Regulation /EC/ 552 /2004 – Annex III [REF19].

4.7.1.2 Verification Management Plan

The Verification Management Plan (VMP) shall document the verification program to be implemented by the Contractor.

66/81


The VMP will be used by BULATSA to assess the adequacy and to monitor the progress of the Contractor’s verification program, and to identify BULATSA involvement in the program.

REQ-PRJ-VRF-03 The VMP should, at a minimum, include:

a. an outline of the Contractor’s strategy, methodology and processes used in its verification program;

b. the sequence/phases of its verification activities for the System; and

c. the Contractor and BULATSA resources (e.g. human, machines) anticipated being required at the various stages of the verification program.

REQ-PRJ-VRF-04 The VMP shall refer to the Verification Cross-Reference Matrix (VCRM) for each requirement of each System, identifying the method and stage of the verification program at which compliance will be verified.

4.7.1.3 Verification Cross Reference Matrix (VCRM)

REQ-PRJ-VRF-05 The Contractor shall develop, deliver and update a Verification Cross Reference Matrix which captures the detail of the verification criteria and status of the verification activities for each requirement in the Technical Specifications, in accordance with the CDRL and the Contract.

4.7.1.4 Test Readiness Reviews

REQ-PRJ-VRF-06 Prior to the commencement of any Acceptance Test (FAT or SAT), the Contractor shall complete a TRR, in conjunction with BULATSA and in accordance with the VMP, which:

a. confirms the completeness of the test procedures;

b. assures the relevant System element is ready for testing; and

c. assures that the Contractor and BULATSA is prepared for formal testing.

4.7.1.5 BULATSA Involvement in Acceptance Verification

The Contractor will be required to invite BULATSA to attend formal Acceptance verification activities, providing notice no later than one month before the commencement of the verification activity.

The cost of BULATSA personnel attending Acceptance verification activities will be borne by BULATSA.

4.7.1.6 Failure Reporting and Analysis

REQ-PRJ-VRF-07 For all verification failures that occur during Acceptance of the System, the Contractor shall provide BULATSA with:

a. failure data;

b. corrective actions; and

c. the scope of additional verification activities.

67/81


4.7.1.7 Regression Testing

REQ-PRJ-VRF-08 If changes are made to the System configuration after starting Acceptance verification activities, the Contractor shall perform a regression analysis and shall repeat those tests which results are shown by regression analysis to have been potentially affected by the configuration changes.

4.7.2 Acceptance Verification

4.7.2.1 General

REQ-PRJ-VRF-09 The Contractor shall verify that the delivered System comply with this System Specifications.

REQ-PRJ-VRF-10 The Contractor shall validate the environment and all equipment used for Acceptance verification in accordance with the approved Acceptance Test Plan (ATP).

4.7.2.2 Acceptance Test Plans, Procedures and Reports

REQ-PRJ-VRF-11 The Acceptance verification program shall include:

a. Test Readiness Reviews for each Acceptance Test;

b. Factory Acceptance Tests (FAT); and

c. Site Acceptance Tests (SAT) at BULATSA premises.

REQ-PRJ-VRF-12 To ensure that verification is conducted in accordance with the VMP the Contractor shall develop, deliver and update the following, in accordance with the CDRL and the Contract:

a. System Acceptance Test Plans;

b. System Acceptance Test Procedures; and

c. System Acceptance Test Reports.

An Acceptance Test Plan describes the organisation, schedule, responsibility, procedures and other details that are necessary for the conduct of a set of Acceptance Test Procedures for specific segments or phases of the overall test program.

REQ-PRJ-VRF-13 The ATP shall define procedures to be adopted when a test result indicates the test has failed, provide traceability of any investigation or technical follow-up, corrective actions, and retest, to maintain the integrity of the final results and reports.

The ATP should list those ATProcs and ATRs that are generated by the ATP.

REQ-PRJ-VRF-14 The ATP shall reference the VCRM that provides traceability of each System Specifications requirement to test item and test procedures that will verify and validate satisfactory compliance.

REQ-PRJ-VRF-15 Acceptance Test Procedures shall include the following:

a. Scope of the test, including a test method, which provides a general description of the test activity;

b. System configuration and initial conditions for test, including any preparatory requirements or other pre-test activities;

68/81


c. Test equipment, documentation, venue and personnel required for the conduct of the test; and

d. Step by step procedures for the performance of the test in sufficient detail to identify every action necessary for the conduct of the test.

REQ-PRJ-VRF-16 Acceptance Test Reports shall be used to document the results of the System test activity.

REQ-PRJ-VRF-17 The ATR should identify the equipment or System that was tested and briefly describe the tests conducted making reference to applicable documents, including ATPs and ATProcs, as required. The ATR should discuss the test results obtained and document the results of the test.

4.7.3 Operational Evaluation

On completion of the all site acceptance activities, the system will be subjected to an in-depth Operational Evaluation.

The Operation Evaluation will be organised by the BULATSA at its own expense.

Should the Operational evaluation show serious deficiencies in the system performance, these will be brought to the notice of Contractor.

REQ-PRJ-VRF-18 In the event that the analysis of the deficiencies shows that the deficiency is due to incorrect functioning and/or non-compliance with specification requirements of the Contractor equipment furnished, Contractor shall carry out the necessary remedial works to correct these deficiencies as part of the support services during the warranty period.

4.8 QUALITY MANAGEMENT PROGRAM

4.8.1 Contractor Quality Responsibilities

REQ-PRJ-QUAL-01 The Contractor shall have a quality system that has been certified as compliant with ISO 9001-2001/2008 Quality Management System or international equivalent.

REQ-PRJ-QUAL-02 The Contractor shall maintain and apply the quality system to the production, including design and development, as applicable, of the Supplies in accordance with the Quality Plan.

REQ-PRJ-QUAL-03 The Contractor shall inform BULATSA of any changes to the certification status of the Contractor.

REQ-PRJ-QUAL-04 The Contractor shall ensure that all work performed by subcontractor(s) if any, meets the requirements of the quality system to be applied by the Contractor.

69/81


4.8.2 Quality Plan

REQ-PRJ-QUAL-05 The Quality Plan should describe how the Contractor’s quality management system will be applied to fulfil the specific requirements of the Contract and should describe or provide reference to a list of procedures to be used. The Quality Plan should also describe the Contractor’s audit and review activities to be performed during the Contract.

70/81


5 APPENDIX A – SYSTEM REQUIREMENTS COMPLIANCE MATRIX

Nr. Type Compliance NoteTCAT.GEN.1 MandatoryTCAT.GEN.2 MandatoryTCAT.GEN.3 MandatoryTCAT.GEN.4 MandatoryTCAT.GEN.5 MandatoryTCAT.GEN.6 MandatoryTCAT.GEN.7 MandatoryTCAT.GEN.8 MandatoryTCAT.GEN.9 Mandatory

TCAT.GEN.10 MandatoryTCAT.RAM.01 MandatoryTCAT.RAM.02 MandatoryTCAT.RAM.03 RecommendedTCAT.RAM.04 RecommendedTCAT.RAM.05 MandatoryTCAT.RAM.06 RecommendedTCAT.RAM.07 RecommendedTCAT.RAM.08 MandatoryTCAT.RAM.09 RecommendedTCAT.RAM.10 RecommendedTCAT.RAM.11 RecommendedTCAT.RAM.12 RecommendedTCAT.RAM.13 MandatoryTCAT.RAM.14 MandatoryTCAT.RAM.15 MandatoryTCAT.RAM.16 MandatoryTCAT.RAM.17 MandatoryTCAT.RAM.18 MandatoryTCAT.RAM.19 RecommendedTCAT.RAM.20 MandatoryTCAT.RAM.21 MandatoryTCAT.RAM.22 RecommendedTCAT.SWD.01 MandatoryTCAT.SWD.02 MandatoryTCAT.SWD.03 MandatoryTCAT.SWD.04 MandatoryTCAT.SWD.05 MandatoryTCAT.HWD.01 MandatoryTCAT.HWD.02 MandatoryTCAT.HWD.03 RecommendedTCAT.HWD.04 RecommendedTCAT.HWD.05 MandatoryTCAT.HWD.06 MandatoryTCAT.INP.01 MandatoryTCAT.INP.02 MandatoryTCAT.INP.03 Recommended

71/81


Nr. Type Compliance NoteTCAT.INP.04 MandatoryTCAT.INP.05 MandatoryTCAT.INP.06 MandatoryTCAT.INP.07 MandatoryTCAT.INP.08 MandatoryTCAT.INP.09 MandatoryTCAT.INP.10 MandatoryTCAT.INP.11 MandatoryTCAT.INP.12 MandatoryTCAT.INP.13 MandatoryTCAT.INP.14 MandatoryTCAT.INP.15 MandatoryTCAT.INP.16 MandatoryTCAT.INP.17 MandatoryTCAT.INP.18 MandatoryTCAT.INP.19 MandatoryTCAT.INP.20 RecommendedTCAT.INP.21 RecommendedTCAT.ASP.01 MandatoryTCAT.ASP.02 MandatoryTCAT.ASP.03 RecommendedTCAT.ASP.04 MandatoryTCAT.ASP.05 MandatoryTCAT.ASP.06 MandatoryTCAT.ASP.07 Mandatory

TCAT.ASP.07А RecommendedTCAT.ASP.08 MandatoryTCAT.ASP.09 MandatoryTCAT.ASP.10 MandatoryTCAT.ASP.11 RecommendedTCAT.ASP.12 MandatoryTCAT.ASP.13 RecommendedTCAT.WKL.01 MandatoryTCAT.WKL.02 MandatoryTCAT.WKL.03 MandatoryTCAT.WKL.04 MandatoryTCAT.WKL.05 MandatoryTCAT.WKL.06 MandatoryTCAT.WKL.07 MandatoryTCAT.WKL.08 Recommended

TCAT.WKL.09 Mandatory

TCAT.WKL.10 MandatoryTCAT.WKL.11 MandatoryTCAT.WKL.12 RecommendedTCAT.WKL.13 RecommendedTCAT.WKL.14 MandatoryTCAT.WKL.15 RecommendedTCAT.WKL.16 MandatoryTCAT.WKL.17 Recommended

72/81


Nr. Type Compliance NoteTCAT.WKL.18 RecommendedTCAT.WKL.19 MandatoryTCAT.WKL.20 MandatoryTCAT.WKL.21 RecommendedTCAT.WKL.22 RecommendedTCAT.WKL.23 RecommendedTCAT.WKL.24 RecommendedTCAT.HMI.1 MandatoryTCAT.HMI.2 MandatoryTCAT.HMI.3 RecommendedTCAT.HMI.4 RecommendedTCAT.HMI.5 RecommendedTCAT.HMI.6 RecommendedTCAT.HMI.7 RecommendedTCAT.HMI.8 RecommendedTCAT.HMI.9 Recommended

TCAT.HMI.10 MandatoryTCAT.HMI.11 MandatoryTCAT.HMI.12 MandatoryTCAT.HMI.13 MandatoryTCAT.HMI.14 MandatoryTCAT.HMI.15 MandatoryTCAT.HMI.16 MandatoryTCAT.HMI.17 MandatoryTCAT.HMI.18 MandatoryTCAT.HMI.19 MandatoryTCAT.HMI.20 RecommendedTCAT.HMI.21 RecommendedTCAT.HMI.22 MandatoryTCAT.HMI.23 RecommendedTCAT.HMI.24 RecommendedTCAT.HMI.25 RecommendedTCAT.HMI.26 RecommendedTCAT.HMI.27 RecommendedTCAT.HMI.28 RecommendedTCAT.HMI.29 RecommendedTCAT.HMI.30 RecommendedTCAT.HMI.31 RecommendedTCAT.HMI.32 RecommendedTCAT.HMI.33 MandatoryTCAT.HMI.34 MandatoryTCAT.HMI.35 MandatoryTCAT.HMI.36 RecommendedTCAT.HMI.37 MandatoryTCAT.HMI.38 MandatoryTCAT.HMI.39 RecommendedTCAT.HMI.40 RecommendedTCAT.HMI.41 RecommendedTCAT.HMI.42 RecommendedTCAT.HMI.43 Recommended

73/81


Nr. Type Compliance NoteTCAT.HMI.44 RecommendedTCAT.HMI.45 RecommendedTCAT.HMI.46 RecommendedTCAT.HMI.47 MandatoryTCAT.HMI.48 MandatoryTCAT.HMI.49 MandatoryTCAT.HMI.50 MandatoryTCAT.HMI.51 MandatoryTCAT.HMI.52 MandatoryTCAT.HMI.53 MandatoryTCAT.HMI.54 MandatoryTCAT.HMI.55 MandatoryTCAT.HMI.56 MandatoryTCAT.HMI.57 MandatoryTCAT.HMI.58 MandatoryTCAT.HMI.59 RecommendedTCAT.HMI.60 RecommendedTCAT.ARC.1 MandatoryTCAT.ARC.2 MandatoryTCAT.ARC.3 RecommendedTCAT.ARC.4 MandatoryTCAT.ARC.5 MandatoryTCAT.ARC.6 RecommendedTCAT.ARC.7 RecommendedTCAT.ARC.8 RecommendedTCAT.ARC.9 Mandatory

TCAT.ARC.10 MandatoryTCAT.ARC.11 MandatoryTCAT.ARC.12 Mandatory

TCAT.OS.1 MandatoryTCAT.OS.2 MandatoryTCAT.OS.3 MandatoryTCAT.OS.4 MandatoryTCAT.OS.5 MandatoryTCAT.OS.6 RecommendedTCAT.OS.7 MandatoryTCAT.OS.8 MandatoryTCAT.OS.9 Mandatory

TCAT.OS.10 MandatoryTCAT.OS.11 RecommendedTCAT.OS.12 MandatoryTCAT.OS.13 RecommendedTCAT.OS.14 MandatoryTCAT.OS.15 MandatoryTCAT.OS.16 MandatoryTCAT.OS.17 MandatoryTCAT.WIF.1 MandatoryTCAT.WIF.2 MandatoryTCAT.WIF.3 MandatoryTCAT.WIF.4 Mandatory

74/81


Nr. Type Compliance NoteTCAT.WIF.5 MandatoryTCAT.WIF.6 MandatoryTCAT.WIF.7 MandatoryTCAT.WIF.8 MandatoryTCAT.WIF.9 Mandatory

TCAT.WIF.10 MandatoryTCAT.WIF.11 RecommendedTCAT.WIF.12 RecommendedTCAT.WIF.13 RecommendedTCAT.ATFM.1 MandatoryTCAT.ATFM.2 RecommendedTCAT.ATFM.3 MandatoryTCAT.ATFM.4 RecommendedTCAT.ATFM.5 MandatoryTCAT.ATFM.6 MandatoryTCAT.ATFM.7 RecommendedTCAT.ATFM.8 RecommendedTCAT.CDM.1 RecommendedTCAT.UA.1 MandatoryTCAT.UA.2 MandatoryTCAT.UA.3 MandatoryTCAT.UA.4 MandatoryTCAT.UA.5 MandatoryTCAT.UA.6 MandatoryTCAT.UA.7 MandatoryTCAT.UA.8 MandatoryTCAT.UA.9 MandatoryTCAT.UA.10 MandatoryTCAT.UA.11 MandatoryTCAT.UA.12 MandatoryTCAT.UA.13 MandatoryTCAT.PER.1 MandatoryTCAT.PER.2 MandatoryTCAT.PER.3 MandatoryTCAT.PER.4 RecommendedTCAT.PER.5 MandatoryTCAT.PER.6 MandatoryTCAT.PER.7 MandatoryTCAT.PER.8 MandatoryTCAT.HR.01 MandatoryTCAT.PRT.1 MandatoryTCAT.PRT.2 MandatoryTCAT.PRT.3 MandatoryTCAT.PRT.4 MandatoryTCAT.PRT.5 MandatoryTCAT.PRT.6 MandatoryTCAT.PRT.7 MandatoryTCAT.EXP.1 MandatoryTCAT.EXP.2 MandatoryTCAT.EXP.3 Mandatory

75/81


Nr. Type Compliance NoteTCAT.EXP.4 MandatoryTCAT.DOC.1 MandatoryTCAT.DOC.2 MandatoryREQ-ENV-01 MandatoryREQ-ENV-02 RecommendedREQ-ENV-03 MandatoryREQ-ENV-04 MandatoryREQ-ENV-05 Mandatory

REQ-PRJ-GEN-01 Mandatory




REQ-PRJ-PM-01 MandatoryREQ-PRJ-PM-02 MandatoryREQ-PRJ-PM-03 MandatoryREQ-PRJ-PM-04 MandatoryREQ-PRJ-PM-05 MandatoryREQ-PRJ-PM-06 MandatoryREQ-PRJ-PM-07 MandatoryREQ-PRJ-PM-08 MandatoryREQ-PRJ-PM-09 MandatoryREQ-PRJ-PM-10 MandatoryREQ-PRJ-PM-11 MandatoryREQ-PRJ-PM-12 MandatoryREQ-PRJ-PM-13 MandatoryREQ-PRJ-PM-14 MandatoryREQ-PRJ-PM-15 MandatoryREQ-PRJ-PM-16 MandatoryREQ-PRJ-PM-17 MandatoryREQ-PRJ-PM-18 MandatoryREQ-PRJ-PM-19 MandatoryREQ-PRJ-PM-20 MandatoryREQ-PRJ-PM-21 MandatoryREQ-PRJ-PM-22 MandatoryREQ-PRJ-ENG-

01 Mandatory

REQ-PRJ-ENG-02 Mandatory





76/81


Nr. Type Compliance NoteREQ-PRJ-ENG-

07 Mandatory



REQ-PRJ-ENG-10 Recommended









REQ-PRJ-INST-01 Mandatory

REQ-PRJ-INST-02 Recommended




REQ-PRJ-ILS-01 MandatoryREQ-PRJ-ILS-02 MandatoryREQ-PRJ-ILS-03 MandatoryREQ-PRJ-ILS-04 MandatoryREQ-PRJ-ILS-05 MandatoryREQ-PRJ-ILS-06 MandatoryREQ-PRJ-ILS-07 MandatoryREQ-PRJ-ILS-08 MandatoryREQ-PRJ-ILS-09 MandatoryREQ-PRJ-ILS-10 MandatoryREQ-PRJ-ILS-11 MandatoryREQ-PRJ-ILS-12 MandatoryREQ-PRJ-ILS-13 MandatoryREQ-PRJ-ILS-14 MandatoryREQ-PRJ-ILS-15 MandatoryREQ-PRJ-ILS-16 MandatoryREQ-PRJ-ILS-17 Mandatory

77/81


Nr. Type Compliance NoteREQ-PRJ-ILS-18 MandatoryREQ-PRJ-ILS-19 RecommendedREQ-PRJ-TRN-

01 Mandatory

REQ-PRJ-TRN-02 Mandatory











REQ-PRJ-CFG-01 Mandatory



REQ-PRJ-CFG-04 Recommended


REQ-PRJ-CFG-06 Recommended

REQ-PRJ-VRF-01 Mandatory


REQ-PRJ-VRF-03 Recommended




REQ-PRJ-VRF- Mandatory

78/81


Nr. Type Compliance Note07












REQ-PRJ-QUAL-01 Mandatory




REQ-PRJ-QUAL-05 Recommended

79/81


6 APPENDIX B – CONTRACT DELIVERABLES REQUIREMENTS LIST

Nr Data Item Title Ref Delivery

ScheduleDelivery Location

BULATSA Action

Required

Maintenance by

ContractorComments

1Project

Management Plan (PMP)

4.2.2.1

ED Project Office

Review & Approval

Update as required

Draft provided as part of the

Contractor dossier

2 Contract Master Schedule (CMS)

4.2.2.2

ED Project Office

Review & Approval

Update as required


Contractor dossier

3 Progress Status Report (PSR)

4.2.3.1

Monthly Project Office

Review & Approval

Update as required

First delivery at ED + 2 month

4 Progress Meeting Agenda

4.2.3.2

5 Working Days before

Meeting

Project Office

Review & Approval

Update as required

5Progress

Meeting Minutes (MoM)

4.2.3.2

End Meeting Date + 5

Working Days

Project Office

Review & Approval

Update as required

6Risk

Management Plan (RMP)

4.2.4 ED Project Office

Review & Approval

Update as required


Contractor dossier

8Interface Control

Documents (ICD)

4.2.5.1

SDR Project Office

Review & Approval

Update as required

9 System Design Review (SDR)

4.2.5.2

ED + 2 Month Project Office

Review & Approval n/a

10Technical

Documentation List (TDL)

4.2.7 ED + 2 Months

Project Office

Review & Approval

Update as required

11Specifications

and Design Documentation

4.2.75 Working

Days before start

Installation

Project Office

Review & Approval

Update as required

12 Engineering Drawings 4.2.7


start Installation

Project Office

Review & Approval

Update as required

13 RMA Plan 4.2.8.2

SDR Project Office

Review & Approval

Update as required

14Fault Modes

Effects Analysis (FMEA)

4.2.8.3

SDR Project Office

Review & Approval

Update as required

15 Safety Plan4.2.8.

3ED Project

OfficeReview & Approval

Update as required


Contractor dossier

16Installation

Management Plan (IMP)

4.3.35 Working

Days before start

Installation

Project Office

Review & Approval

Update as required

17

Integrated Logistics

Support Plan (ILSP)

4.4.1 End of SAT Project Office

Review & Approval

Update as required

18Spares and

Consumables List (SCL)

4.4.4.1

ED Project Office

Review & Approval

Update as required


Contractor dossier

80/81


19 Technical Documentation

4.4.4.2


SAT

Project Office

Review & Approval

Update as required Complete set

20 Operational documentation

4.4.4.2


FAT

Project Office

Review & Approval

Update as required Complete set

21 Training Plan 4.5.2 ED Project Office

Review &Approval

Update as required


Contractor dossier

22Configuration Management

Plan4.6.2


SAT

Project Office

Review & Approval

Update as required

23Verification Management Plan (VMP)

4.7.1.2

1 Month before FAT

Project Office

Review & Approval

Update as required

24Verification

Cross Reference Matrix (VCRM)

4.7.1.3

1 Month before FAT

Project Office

Review & Approval

Update as required

25 Test Readiness Reviews (TRR)

4.7.1.4


FAT and SAT

Project Office

Review & Approval n/a

26 Acceptance Test Plan (ATP)

4.7.2.2

1 Month before FAT

Project Office

Review & Approval

Update as required

27Acceptance Test

Procedures (ATProcs)

4.7.2.2

1 Month before FAT Factory Review

&ApprovalUpdate as required

28 Acceptance Test Reports (ATR)

4.7.2.2

Test Completion +

5 Working Days

Project Office

Review & Approval

Update as required

29 Quality Plan 4.8.2 ED Project Office

Review & Approval

Update as required


Contractor dossier

81/81

Date post:	31-Jan-2018
Category:	Documents
Upload:	vuquynh
View:	214 times
Download:	1 times