THE REQUIREMENTS & SPECIFICATIONS For Riga Tower Surveillance Improvement Project

Transcription

1 THE REQUIREMENTS & SPECIFICATIONS For Riga Tower Surveillance Improvement Project Identification Number LGS 2014/90 December 2014 Prepared by SJSC Latvijas gaisa satiksme International Airport Riga, LV-1053, Latvia

2 1. INTRODUCTION LGS IN BRIEF CURRENT SITUATION AND LIMITATIONS OVERVIEW SCOPE OF WORK ORGANISATION OF THE DOCUMENT SYSTEM REQUIREMENTS GENERAL REQUIREMENTS FUNCTIONAL REQUIREMENTS SYSTEM COMPOSITION SYSTEM ARCHITECTURE REQUIREMENTS TO THE SYSTEM INTERFACE REQUIREMENTS TO THE CENTRAL PROCESSING SYSTEM REQUIREMENTS TO THE SURVEILLANCE SENSORS INTEGRATION WITH OTHER SYSTEMS TOWER OPERATIONS CONCEPT RIGA TOWER BRIEF DESCRIPTION CONCEPT OF OPERATION WITH THE NEW SYSTEM TECHNICAL REQUIREMENTS SYSTEM SPECIFICATION SPARES INSTALLATION AND CONSTRUCTION ELECTRICAL DESIGN EQUIPMENT COOLING ELECTROMAGNETIC INTERFERENCE EARTHING OBLIGATIONS RELATED TO CIVIL WORKS, INSTALLATION AND COMMISIONNING TENDER ORGANIZATION REQUIREMENTS TO THE BIDDERS FAMILIARIZATION VISIT DOCUMENTATION INTRODUCTION GENERAL REQUIREMENTS PROVISION OF DOCUMENTATION QUALITY AND SAFETY ASSURANCE GENERAL REQUIREMENTS QUALITY CONTROL AND VERIFICATION TRAINING INTRODUCTION GENERAL TRAINING DOCUMENTATION TRAINING FACILITIES AND EQUIPMENT TRAINING OF TECHNICAL PERSONNEL TRAINING AIMS OF THE COURSE FOR TECHNICAL PERSONNEL RTSI RFP v14 Page 2 of 54

3 8.7 TRAINING OF OPERATIONAL PERSONNEL TRAINING AIMS OF THE COURSE FOR OPERATIONAL PERSONNEL PROPOSAL FROM THE SUPPLIER STATEMENT OF COMPLIANCE GENERAL STATEMENT TABLE FORMAT PROJECT MANAGEMENT INTRODUCTION CONTRACTOR S REPRESENTATIVE SUPPLIER S PROJECT ORGANIZATION PROJECT MANAGEMENT PLANS PROGRESS MEETINGS CUSTOMER S PROJECT ORGANIZATION HARDWARE AND SOFTWARE REQUIREMENTS GENERAL SOFTWARE REQUIREMENTS HARDWARE REQUIREMENTS RTSI RFP v14 Page 3 of 54

4 1. INTRODUCTION 1.1 LGS in Brief The State Joint-Stock Company Latvijas gaisa satiksme (LGS) is the state owned national air navigation service provider, operating in the field of civil aviation. LGS is subject to the Ministry of Transport of the Republic of Latvia and is under regulatory supervision of Latvian Civil Aviation Agency The main goal of LGS is to provide safe and optimal air navigation services in Latvian airspace, namely Riga Flight Information Region (FIR) The air navigation services are provided in accordance with ICAO and EUROCONTROL standards and recommended practices. The operational differences are published in Latvian AIP Operating in the market economy LGS is customer-oriented and provides users with equal quality services in line with international standards The main revenue source for LGS is the air navigation charges collected for the services. LGS is one of the largest taxpayers in Latvia and is not financed from the State budget 1.2 Current Situation and Limitations Riga airport limitations Riga Airport is a Mid-Size airport with average traffic about 250 movements daily. It has a relatively simple layout and configuration. Fig. 1. Riga Airport layout Riga airport is growing and currently surveillance from LGS tower is not sufficient. Although LGS has A-SMGCS system Level 2 in operation from 2006, there are the following limitations: Poor visual control in bad weather conditions and night time (binocular control). RTSI RFP v14 Page 4 of 54

5 Lack of visual control of certain Aprons because of new buildings, hangars (blind spots) Lack of A-SMGCS system control for certain Apron areas Those limitations are not very critical and it is still possible to provide the efficient and safe service; however LGS foresees potential problems in near future both because of traffic grow, and because of Airport reconstruction, hence LGS would like to improve the situation Project Overview The new project was started in 2013 and is planned for 3-5 years depending on results of the first Stages. The project consists of several independent stages: Stage I Blind Spot Monitoring (mandatory) Stage II Smart Binocular (mandatory) Stage III Improvement of A-SMGCS surveillance (optional) Stage IV simple monitoring of the dedicated area at the airport (optional) LGS will take a decision about the further development and continuation of the project (up till Stage V - full remote Tower Control/ Contingency Tower) based on the results of the stages mentioned above It is planned to combine Stage I and Stage II into one Project, which will be called Riga Tower Surveillance Improvement Project (RTSI) Stage III is briefly specified and should be proposed by Bidder as an Option Stage IV is briefly specified and should be proposed by Bidder as an Option. Under certain circumstances Stage IV might be chosen together with Stage I and/or Stage II. RTSI RFP v14 Page 5 of 54

6 1.3 Overview This document provides operational, functional, technical and other specifications for implementation of Riga Tower Surveillance Improvement Project (RTSI) for LGS It is the intention of Latvijas gaisa satiksme (LGS) that the system procured will provide the maximum benefit/cost ratio with the minimum risk of timescale overrun. As such, the procured system is expected to comprise a large proportion of existing capabilities, but with a degree of development and tailoring where required to meet the requirements of LGS. The organization and content of this document, and the instructions to Supplier detailed below, are designed to facilitate the evaluation of these factors Mandatory capabilities are denoted with the term shall Desired capabilities are denoted with the term should and shall be reflected in the proposal as an option with separate price and delivery conditions The wording shall have the capability means that the Bidder shall confirm the availability of such a feature/function in the system, but it should not be implemented or might be proposed as an option with separate price and delivery conditions Suppliers are encouraged to propose COTS systems that provide all the mandatory capabilities and as many desired capabilities that are available with a minimum amount of development. RTSI RFP v14 Page 6 of 54

7 1.4 Scope of Work The Supplier shall: Deliver hardware Deliver software Perform installation of hardware and software Perform installaton of infrastructure and surveillance sensors at LGS and Airport Riga including all the civil works Perform System adaptation to LGS environment Perform System integration with Indra Navia A-SMGCS system (if necessary) Deliver documentation Provide factory training (for each stage) Perform factory acceptance testing (for each stage) Provide onsite training (for each stage) Perform site acceptance testing (for each stage) Provide the set of the documents required for Certification (DSU, source data for Safety Case, etc.) in Latvian CAA Provide warranty Provide after-sales service 1.5 Organisation of the Document Chapter 1 provides an introduction including information about the document structure and reference documents Chapter 2 provides the Functional Requirements of the RTSI Project Chapter 3 describes the Requirements of LGS Tower Operations Chapter 4 describes the Technical Requirements of the RTSI Project Chapter 5 describes the Tender Organization Chapter 6 describes the Documentation Chapter 7 describes the Quality and Safety Assurance Chapter 8 describes the Training Chapter 9 describes the Statement of Compliance Chapter 10 describes the Project Management Chapter 11 describes the Hardware and Software Requirements. RTSI RFP v14 Page 7 of 54

8 2. SYSTEM REQUIREMENTS 2.1 General Requirements This document describes the configuration, performance, and functionality of the System for Tower Surveillance Improvement (RTSI) to be delivered during the Project This section also describes the functionality required at end user application and not how this functionality is to be achieved technically, or the parameters within which the system will operate The system shall be operationally proven, have a high availability, shall be fully reconfigurable, and represent state of the art technology. It is anticipated that the majority of equipment supplied shall be commercial off the shelf, and that a minimal amount of customization will be necessary to achieve the required functionalities Clarity, integrity and correctness of the data: the system shall guarantee the clarity, integrity and correctness of the data it manages and shall ensure the centralized management of such data The system shall assign the role for each user. The role shall be configurable with the set of the parameters/permissions for each user The system shall enable traceability and data logging of all operations that are effected (both by the regular user and by the system administrators). Users can access the system through a personal system profile User Role. This renders shall limit access to information and functions that the user is not entitled to The system shall be user-friendly and easily navigable, in other words the user shall be aided in identifying information presented The system shall allow for available functions to be activated over time according to the needs of the Customer, as well as allowing for an extension of its capabilities according to the number of users and work peaks The system shall be easy configurable by the set of parameters. The configuration process shall be documented with high details. RTSI RFP v14 Page 8 of 54

9 2.2 Functional Requirements Stage I The new video surveillance system shall be implemented as the result of this stage. This system shall be able to perform the following: Hi-Res video camera(s) shall be placed on Riga Aerodrome with the purpose to cover the area with obstructed view from Tower RTSI System shall be able to operate independently of the time of the day and weather conditions RTSI System shall be able to display targets on the ground and trace the movable targets selected by controllers RTSI System should be able to identify targets on the ground and trace the movable identified targets selected by controllers RTSI System shall be able to display targets tracked/identified on the ground in the automatic mode. This feature should be toggleable ( switch on / switch off individual target or all the targets simultaneously) RTSI System shall be able to inform the controllers about the start of the moving of any target within the predefined monitored area(s) This monitored area(s) shall be preconfigured an this feature should be toggleable ( switch on / switch off for each predefined area individually) RTSI System shall be operated by Tower Controllers (3 positions) RTSI System shall have a certain level of redundancy Data delivered by the RTSI System shall be presented in Tower Cab on the Hi-Res monitor(s) Data shall be recorded and stored for pre-defined period of time with the possibility to re-play. Fig. 2. Blind Spot Area 1 for monitoring from LGS Control Tower RTSI RFP v14 Page 9 of 54

10 2.2.2 Stage II The new video surveillance system shall be implemented as the result of this stage. This system shall be able to perform the following: Hi-Res video camera(s) shall be placed on top of LGS Control Tower Tower controller shall be able to use the Camera(s) for surveillance of the situation at Riga aerodrome independently of time of the day and weather conditions Camera(s) shall support Pan, Tilt and Zoom. Control shall be performed by Tower Controllers (3 positions) RTSI System shall be able to track the targets selected by controllers and follow its movement as in the air as on the ground within aerodrome territory RTSI System shall have the capability of tracking targets using video processing analysis RTSI System should offer a redundant camera configuration with automatic fail-over to redundant cameras in case of primary camera failure Information from camera(s) shall be presented in Tower Cab on the Hi- Res video panel(s) / monitor(s) Information shall be recorded and stored for pre-defined period of time with the possibility to re-play Camera(s) should have screenshot and quick video recording functions, stored for pre-defined short time (for example for last 24 hours) and easily reachable by Tower personnel. Fig. 3. Smart Binocular at LGS Tower System should be able to get track s data from A-SMGCS system Track data should be used for target identification and association Track data should be displayed on video. RTSI RFP v14 Page 10 of 54

11 2.2.3 Stage III (optional) Blind Spot monitoring system developed and implemented during the previous Stages shall be integrated with A-SMGCS system with the goal to: Use blind spot monitoring system as an additional sensor(s) for A- SMGCS system Provide tracking data output using industry standards (i.e. ASTERIX) and fuse this data with A-SMGCS system data Provide tracking data presentation for Tower Controllers Implement additional functionality for more efficient use of the System Stage IV (optional) Extra Sensor(s) shall be added to Blind Spot monitoring system developed and implemented during the Stage I & II with the goal to: Use blind spot monitoring system as an monitoring system for dedicated area. This area is presented on Figure 4 (yellow circle). Fig. 4. Dedicated area at Riga Airport No extra functionality except surveillance is required Surveillance information shall be transferred to the separate monitor in the office at LGS premises Data shall be recorded and stored for pre-defined period of time with the possibility to re-play. RTSI RFP v14 Page 11 of 54

12 2.3 System Composition The RTSI shall be delivered, installed and implemented on TURN-KEY basis The RTSI shall be delivered fully equipped (including racks, interfaces, software capacity, power supply, sensors, sensors mount, cable infrastructure, network equipment, servers, workstations, display equipment, etc.) in order to fully meet the requirements stated in this document The Central Equipment shall be installed in the Equipment Rooms of the LGS ATS Centre Building The RTSI itself and necessary Peripheral Equipment shall be installed in the locations defined by LGS together with RTSI system Supplier The RTSI shall consist of: Central RTSI Server module, which shall have the reliable redundant configuration; RTSI Application Module(s), which shall be installed and used as separate end user software applications RTSI Display System, which shall be installed on LGS Tower and used for data presentation RTSI Sensors, which shall be installed at LGS and Riga airport according to design specification approved on the earlier stages of the project RTSI Network Infrastructure, which shall be installed at LGS and Riga airport and connect RTSI sensors with RTSI system Network between the central system and sensors shall be based on fiber-optical technology If sensors are installed at LGS premises Network between the central system and sensors should be based on wireless technology if sensors are installed at Riga airport, but fiber-optical solution might be offered as an option RTSI Integration Module, which shall provide the interaction between sensors and other LGS systems RTSI shall have a Technical Monitoring & Control (TMC) module which monitors: the health, status and performance of cameras, display components, processing components the health, status and performance of software components (display, processing, archiving). RTSI RFP v14 Page 12 of 54

13 HP L1945w auto input RTSI shall have video recording functionality with configurable size, framerate and level of compression of archived video data RTSI shall have an video playback tool such that it aggregates all video archives located on separate processing and display equipment RTSI shall have an event review tool which allows users to review any logged data based on date, time, event type and event ID The event tool shall support video confirmation of event RTSI shall support installation of cameras on existing infrastructure such as masts, roof-tops, and sides of buildings RTSI shall support the replacement of individual cameras without impacting the functionality of other cameras RTSI shall support the installation of cameras in multiple locations RTSI shall support being run on commercially available hardware (Commercial of the Shelf; COTS): Cameras; Camera mounting equipment; Display equipment (personal workstations & monitors); Processing equipment (servers); Network equipment; 2.4 System Architecture The Supplier shall demonstrate the Architecture of the system, which shall have the elements presented on the Drawing below L1945W HP L1945w auto input L1945W HP L1945w auto input L1945W HP L1945w auto input L1945W HP L1945w auto input L1945W HP L1945w auto input Pan and Tilt Camera Tower Display System Fixed Camera Central Processing System Recording & playback Fig. 5. System Architecture Technical Monitoring & control RTSI RFP v14 Page 13 of 54

14 2.4.2 The Supplier shall prove the fulfilment of the requirements in case if the proposed System s architecture differs from the presented above RTSI shall have a redundant architecture comprised of the following redundant components: Redundant processing components with hot-standby, where no loss of data occurs during the failure of another processing component; Redundant display components; Redundant logical software components; Redundant camera sensors should be proposed like an option; RTSI shall support hot-standby redundancy such that in the event of failure of any logical software component or camera no information is lost to the user or database logs, and no intervention by the user shall be necessary to activate the redundant backup component RTSI shall have a redundant database which shall store system configuration and event logging information. 2.5 Requirements to the System Interface The system shall support full customization of HMI Layout,Size and Colour The system HMI shall support video windows, map windows, information windows, camera control windows The system shall support any configuration, type and number of monitors, video panels, projectors System HMI shall be configured to fit single or multiple monitors arrangements including: HMI display across a single monitor, video panel, projector; HMI display across multiple monitors, video panels, projectors (placed linearly or disperserly) System shall support displays of any size or resolution All the System Interface (including menus, windows, web-applications) shall be in English or Latvian All the System messages, logfiles, configuration parameters shall be in English or Latvian System reports shall be in English or/and Latvian All the other information presented by the System and not listed above shall be in English or/and Latvian System shall support Unicode, i.e. data stored in the system shall be in English, Latvian or any other language supported by Unicode. RTSI RFP v14 Page 14 of 54

15 2.6 Requirements to the Central Processing System The system shall support unlimited number of cameras,installed in multiple locations System shall incorporate Motion JPEG (MJPEG) video decoding or similar video decoding technology Video frame rate shall be at least 25 frames per second or more System shall support graphical processing of in a 3D environment System shall support OpenGL and OpenCV graphical processing System shall support the calibration of every cameras type used System shall provide video image denoising functionality System shall provide video image lens un distortion correction based on user settings System shall support alignment, manipulation and post-processing of multiple video panels (monitors) in order to produce a seamless panoramic image System shall provide video image color correction between video panels System shall provide configurable alpha-blending between video panels System shall incorporate video panel manipulations including: Video panel resizing; Video panel aspect ratio resizing; Video panel 3-axis rotation (X, Y, Z); Video panel bending; Video panel roll System shall allow for digital zooming and panning of video window, video panels and entire panoramic video image System shall support configuration multiple 3D video windows, allowing for viewing and manipulation of multiple panoramic views System shall have the number of pre-configured presets defining the particular setting of PTZ cameras. System shall warn the user (by presenting the preset information for example) when the specific pre-set position is reached System shall have configurable, static graphical overlays on video, including user configured transparency of overlays Static graphical overlays shall support pre-defined alerts and statuses as generated by the System System shall support customizable dynamic graphical target information overlay on video (like object labels). Those overlays shall be able: To follow specific targets; To present the live data from other systems connected to the System; To activate the other system functions System shall support video panel inlays one video window or panel can be displayed within another video window. RTSI RFP v14 Page 15 of 54

16 System shall be able to crop cameras resolution within system HMI or/and modify the camera resolution. 2.7 Requirements to the Surveillance Sensors System shall support any IP video cameras or/and analogue video cameras(via IP video encoder); System shall support regular and infrared (IR) video cameras System shall support fixed and pan-tilt-zoom cameras Any type of cameras shall be equipped with wipers (if option is a part of camera specification) and System shall be able to activate\de-activate those wipers via System HMI Cameras shall be operable in all weather conditions within the air temperature range from -40C to +50C RTSI System shall support cameras resolutions within the range between 320 x 120 pixels to 4096 x 2304 pixels For fixed cameras RTSI System shall provide: User presets for setting camera focus; User presets for setting camera exposure; User presets for toggling between manual focus and auto-focus Control of camera focus and iris For PTZ cameras RTSI System shall provide: Manual PTZ camera controls with overlay on displays; Manual PTZ camera controls via standard USB device like trackball or joystick; Ability to toggle between automatic and manual focus, automatic and manual iris (via System HMI or special buttons); Ability to adjust manual focus and manual iris (via System HMI or special buttons); Configuration of different PTZ presets including a combination of Pan, Tilt, Zoom and Focus (via System HMI or special buttons) Ability to toggle between pre-defined set of POIs (pre-defined places on aerodrome for quick one-button access) It shall be possible to use PTZ presets with the help of System HMI,Touch Input Devices/Displays, Keyboard, Trackball, Joystick, configurable elements (polygons) overlaying on video It shall exist a mechanism of sharing PTZ cameras information between several users. RTSI RFP v14 Page 16 of 54

17 2.8 Integration with other Systems The RTSI system shall support integration with the following Airport and ATC Systems: Surveillance Systems Those systems shall be taken into account: Automated Air Traffic Control System (ATC); Advanced Surface Movement Guidance and Control System (A- SMGCS); Multilateration (MLAT) surveillance systems; Surface Movement Radar (SMR); Secondary Surveillance Radar (SSR); Broadcast (ADS-B) surveillance systems The system shall have the capability of activating PTZ-Auto Tracking based on target selection The RTSI system shall have the capability of displaying target info on video, corresponding to moving targets within the video The RTSI system shall have the capability of showing intelligent video thumbnails of targets. It should be possible to integrate video thumbnails into external systems In one of the structured formats (like XML format for example) Flight Data Processing System (FDPS) The RTSI system shall have the capability of activating PTZ-Auto Tracking based on flight plan selection The RTSI system shall have the capability of displaying flight plan data on video, corresponding to moving targets within the video The RTSI system shall have the capability of manipulation of flight plan data within in the HMI (including flight plan data shown on video) The RTSI system shall have the capability of showing intelligent video thumbnails of targets. It should be possible to integrate video thumbnails into external systems In one of the structured formats (like XML format for example) Airfield Ground Lighting control systems (AGL) The RTSI system shall have the capability to display status and health information from the AGL system The RTSI system shall have the capability to allow for inputs into the AGL system, such as activation and de-activation of lighting The RTSI system shall be compatible with ingesting and displaying the following industry Standard protocols for surveillance information: ASTERIX CAT010; ASTERIX CAT011; ASTERIX CAT062; ASTERIX CAT081. RTSI RFP v14 Page 17 of 54

18 3. TOWER OPERATIONS CONCEPT 3.1 Riga Tower Brief Description Riga Tower operates on a 24/7 principle, serving roughly 250 movements a day, with about 90 per cent of IFR traffic and up to 10 per cent of VFR flights Airport Riga has 1 runway (18-36) and one main taxiway F, 5 taxiways and 1 rapid exit taxiway connecting runway and main taxiway F on an eastern part of the airfield. On a western part there is one loop taxiway connected to runway with 6 taxiways, engine run-up place and parking places for military or some heavy types of aircraft Riga ATC Tower has 2 operational position Riga Tower and Riga Ground. There is also Riga Tower Supervisor position which is spare operational position for TWR or GND if any malfunctions occurred Riga TWR Supervisor position has similar equipment and functionality as TWR working position (including GND working position functionality) There is also Riga Clearance Delivery position, which is not yet in operational use. Fig. 6. Riga Tower Riga TWR and Riga GND (and TWR Supervisor) positions are equipped with 2 main ATC systems: RTSI RFP v14 Page 18 of 54

19 SiATM ATRACC system on 2 displays, providing air traffic (LCD) and supplementary information (touchscreen) like FPLs, arrival and departure lists, maps, etc. 2 touchscreens concept to be described here Indra Navia A-SMGCS system on 1 touchable display, providing ground traffic (aircraft and vehicles) There are 4 overhead displays representing for both TWR and GND (and TWR Supervisor) operational positions: Airfield lighting system serviceability status presented on an airfield layout; smartami display presenting OPMET and aeronautical data; MIDAS IV meteorological system presenting real-time weather data; Essential information display presenting information selected by TWR Supervisor There is the set of other equipment, hardware and software, which is required for performing the essential operations. RTSI RFP v14 Page 19 of 54

20 pip pip pip pip pip input auto 1 2 input auto 1 2 input auto 1 2 input auto 1 2 input auto 1 2 pip input auto Concept of Operation with the new System It is foreseen to use the combined like VideoWall solution to provide operations with all the Tower Systems The video presentation Solution might be changed, if Bidder has the own system architecture and configuration, but it shall correspond to the concept described in this Chapter The Solution shall include the possibility to divide freely the common monitor space between different Applications It shall be possible to configure the position and size of each window, which will be distributed between different Applications Each Application should be presented from the separate workstation or it should be possible to run several Applications from one workstation The brief concept of Application Layout is presented on Figure 7. Binocular frame from PTZ Camera VIDEO OVERLAY: Panoramic Video from Static Cameras L2335 hp 2335 hp 2335 hp 2335 hp 2335 hp 2335 hp 2335 L2335 Tower Information System Nr1 L2335 Tower Information System Nr2 L2335 Binocular Window L2335 L2335 Tower Information System Nr3 Tower Information System NrX Fig. 7. Brief Concept of Application Layout Preliminary the whole space of all the monitors shall be divided horizontally into two parts: Upper part with Video and Lower part with other Applications and smart Binocular window (in the middle) Video shall be presented in panoramic mode and cover the like from Tower view (200 degree) including the Blind Spot area defined by the Customer Video shall be proportionally distributed and aligned across the whole Upper Part of the VideoWall Obstacles and Obstructions, which cause the blind spot, should be transparent from the Tower Controller s view to allow to see and monitor the movement of targets in the blind spot area It should be possible to use the smart Binocular functionality, which should be presented as a video frame in the Upper part of the videowall and duplicated as a video window in the Lower part of the videowall (as shown on Figure 7). The reference frame shall represent the portion of the panoramic view that the PTZ is showing. A floating video window (PTZ) should be possible to float on the Panoramic view smart Binocular frame should be movable to the left or to the right over the panoramic video picture received from Static Cameras It should be possible to zoom-in or zoom-out the image in the smart binocular frame. RTSI RFP v14 Page 20 of 54

21 pip pip pip pip pip input auto 1 2 input auto 1 2 input auto 1 2 input auto 1 2 input auto 1 2 pip input auto Smart Binocular frame should change its size depending on zoom level. The size of this frame should become smaller in case of zoom-in, or larger in case of zoom-out with the purpose to reflect the scale and size of the zoomed area as it shown on Figure 8. L2335 hp 2335 hp 2335 hp 2335 hp 2335 hp 2335 hp 2335 L2335 Tower Information System Nr1 L2335 Tower Information System Nr2 L2335 L2335 L2335 Tower Information System Nr3 Tower Information System NrX Fig. 8. smart Binocular frame Image from the smart Binocular frame should be duplicated on the smart Binocular Window in the lower part of the videowall.the size of the smart Binocular window is fixed, but the scale of the image should be changed depending on zoom-in or zoom-out level It should be possible to use infrared feature of PTZ camera and display the infrared image in the smart Binocular frame and window Switch between normal and infrared image shall be done either automatically (for example depending on the time of the day) or manually by Controller via system HMI In case if tracking function is activated, smart Binocular frame should track the target using the selected zoom level and smart Binocular frame should automatically move to the left or to the right while tracking the target. smart Binocular window should show the tracking target with selected scale level In case if tracking function is activated, smart Binocular function shall be blocked by user, who initiated this tracking. Other user, if he needs to use binocular, shall unblock binocular first Tracking function shall be activated, locked and unlocked by touch input device, keyboard, mouse or trackball RTSI System should allow to switch on or off the labels of the targets RTSI System should allow to switch on or off the preconfigured penetration areas (either blind spot or regular), where any type of penetration will cause an alert to Tower Controller It should also be possible to define such penetration areas manually by the special tool dynamically during operation Labels should be used as for the quick target s identification as for further automatic tracking of the selected target In case of any of videowall monitors failure panoramic image shall have the capability to be collapsed and displayed on the remaining display(s). RTSI RFP v14 Page 21 of 54

22 pip pip pip pip input auto 1 2 input auto 1 2 input auto 1 2 input auto 1 2 pip hp 2335 input auto 1 2 pip input auto 1 2 L2335 hp 2335 hp 2335 hp 2335 hp 2335 hp 2335 L2335 Tower Information System Nr1 L2335 Tower Information System Nr2 L2335 L2335 Tower Information System NrX Tower Information System L2335 Nr3 Fig. 9. System behavior in case of monitor failure The Applications, displayed in the Lower part of the videowall, in case of any of videowall elements/monitors failure, should have the capability to be collapsed, resized, re-aligned and displayed on the remaining display(s) It should exist the possibility, in case If Application, displayed on failed videowall display, occupies the most part of the display, it might be presented on separate monitor (different from videowall displays) smart Binocular function should continue work as it is defined, even in case of any of videowall elements/monitors failure The failure of the RTSI system shall not prevent the display of Applications in the Lower part of the videowall. RTSI RFP v14 Page 22 of 54

23 4. TECHNICAL REQUIREMENTS 4.1 System Specification Technology The design shall be based upon the application and adaptation of proven modern technology and architecture (hardware and software) with the objective of optimizing overall system performance and lifetime, minimizing technical risks and meeting the safety requirements of the user It is imperative that all hardware, software and firmware that is to be utilized shall be totally proven in an operational environment that has similar, if not more stringent requirements than those stated within this Specification In particular, the design of the system shall be such that failure of units shall never cause a complete outage of the total system. Only gradual degradation of performance is allowed Any data processor in the proposed configuration shall have sufficient spare capacity for subsequent extensions or modifications i.e. spare memory capacity, spare I/O facilities and reserve in processing time (duty cycle). This spare capacity shall be in the order of 40 % The application software shall preferably be developed under a standard operating system. Use should be made of a high level language. The software should be written in accordance with the principles of structured programming in order to allow for efficient software maintenance. Only well-proven software which is already used in a similar system shall be offered. References should be state Software The system software architecture shall be such that system functions are assigned in four areas: Operating system software Applications software System configuration and environment data System maintenance software The system shall be such, that new versions of all software types can be loaded and tested without detriment to the operational service The Operating System software shall provide the capability for real-time execution, file management, command procedures and various utilities The Operating System to be utilized may be of an industry standard type, and in any event, shall be totally proven in a similar environment The application software shall include software that is unique to a specific function Unique application software shall be based on proven technology. RTSI RFP v14 Page 23 of 54

24 The system configuration data shall consist of all details of variables and configuration parameters of the system The system shall provide the operator with tool for display, input, back-up and restore/loading of all system variables and configuration parameters The system shall provide the operator with windows-like interface The system maintenance software shall be available when the system requires reports on diagnostics, testing etc. This software shall run in background and shall have no detrimental effect on any system processing The system maintenance software shall provide self-diagnostic capabilities, with the ability to detect failures, localization of defective module and with operator intervention isolate any defective modules and take out of service any defective part or unit The system maintenance software shall include facilities for activity and event logging. It shall be possible to extract this information from the system in a suitable industry standard format, for off line statistical analysis, without in any way effecting the operational service The software design shall be functionally and operationally modular to: Facilitate system expansion, modification and configuration control; Facilitate fault detection, diagnosis, containment, recovery and fault tolerance; Facilitate changes to the lowest practical level without large scale program reassembles; Allow all configuration data to be held in a separate data file Other requirements about the RTSI system software will be found in chapter Hardware and Software Requirements Modularity The system design and construction shall be highly modular in order to accommodate user site variations, change of Operational requirements and to limit possible failure to sub-assemblies Faults in one unit shall thus never influence the proper Operation of other units. The Interfaces between the central equipment and the working positions should be based on standard interfaces Time Synchronization The time synchronization shall be made by means of standard network time protocol (NTP), connecting to the existing or internal timeserver within LAN The time synchronization shall be performed on regular basis, e.g. hourly. The frequency of time synchronizations should be a subject of system configuration. RTSI RFP v14 Page 24 of 54

25 4.1.5 Other Requirements As a general rule, so called "Off the Shelf" equipment are preferred. Therefore no precise technical requirements for such equipment are implied herein If any custom-made components are used, their functions shall be broadly outlined The equipment shall be, as far as possible, so constructed that, similar part, spares and replaceable units are interchangeable and easily fitted General provisions regarding construction are given below, however, as stated before, in case of so called "Off The Shelf" equipment, the Supplier shall just show the compliance/non-compliance between the equipment and requirement; the Supplier is not required to modify his "Off The Shelf" solutions according to these requirements The Supplier shall describe and define all related standards and rules, which his equipment design, solutions and production methods are based on Construction of the system equipment shall employ standardization of cabinets, modular packaging, parts, materials, processes and workmanship Installation and design shall be performed in such a way that a failure in one unit will not disturb the function of units on the same or higher level Initial approval respect to the technical design and conditions will be given by LGS after the Supplier has: Shown an example of already existing equipment and provided with all necessary explanations concerning its design and operation; or Supplied with a full description of the design, presentation, and access facilities and a provisional list of the components, which will be used Visits should be made to the Supplier's premises during the production period. The aim of these visits is to monitor the general advancement of the equipment production and can in no way be considered as a substitute for a "factory inspection" before shipment of goods. Any observations formulated by LGS will be notified to the Supplier who will take them into account for the production of the equipment Files containing all such observations shall be kept by the Supplier to help to form a technical record to be used during the factory inspection and during provisional and final acceptance. RTSI RFP v14 Page 25 of 54

26 4.2 SPARES Initial Spares Initial spare parts shall be recommended by the Supplier and shall be sufficient for maintaining all hardware items for a two-year period, excluding the warranty period The spare parts should be for all delivered systems and equipment including test and ancillary equipment Sparing Level The recommended sparing level shall be based upon the Supplier s reliability data for the system being provided and reflect the reliability expected in the Customer s operational environment The Supplier shall provide these reliability data as part of the response to this RFP Spares List The recommended spares list shall be fully itemized and individually priced and shall be included as part of the documentation Customer reserves the right to choose the any combination of spares provided by the Supplier Guarantees The Supplier shall guarantee the availability of all spare parts and modules for the equipment offered for a period of at least 7 years. 4.3 Installation and Construction General Installation of hardware and software shall be performed at LGS premises at Riga International Airport Installation of the sensors shall be performed at installation site(s) defined by Customer and Supplier Installation, setting up and commissioning of all equipment, including interfacing and interconnection of all units/subsystems and supply of all the necessary cables shall be the responsibility of the Supplier Site Preparation and Installation shall take into account the existing environment and technical features LGS has available. RTSI RFP v14 Page 26 of 54

27 4.3.2 Supply of removable parts and mating connectors All equipment furnished by the Supplier shall be complete e.g. with an installed set of fuses, lamps, plug-in integrated circuits, plug-in relays, plug-in crystals, and all other parts which are used in the equipment and which are similarly designed for quick removal and replacement Where a cable connector is provided on a piece of equipment furnished under the contract, which will be connected to another piece of equipment not being furnished under the contract, the Supplier shall supply the mating connector for the equipment under contract When two or more pieces of equipment furnished under the contract require interconnection, the Supplier shall supply the necessary cables with mating connectors installed Installation The equipment shall be designed so that it can be easily installed, removed, and reinstalled with a minimum of special tools and without extensive disassembly Materials All materials should be antistatic and they shall not be dangerous for users Radioactive or poisonous vapor emitting materials, natural rubber, wood and wood products and flammable materials shall not be used Cabinets and racks The racks, cabinets, consoles and other furniture (if such exist) to be installed in one particular room are to be of comparable dimensions and appearance All inscriptions and information shall be in English or Latvian The cabinets shall be provided with doors. Cabinet s type and model should be agreed with LGS The Supplier shall list the number, size, weight, power consumption and heat load (dissipated power) of each type of cabinet Special requirements for equipment configuration shall be stated The relative configuration of different units e.g. power supplies, memories etc. within a cabinet shall be stated together with information about central cabling entrances. The equipment shall be designed to facilitate quick access to all units within the cabinets. The Supplier shall specify the necessary means for mounting of cabinets. RTSI RFP v14 Page 27 of 54

28 4.3.6 Labeling All labeling shall be unified. The Supplier shall determine the type of labeling system to be used LGS reserves the right to change this system. In that case labeling system shall be defined in co-operation with LGS and the Supplier Labeling shall be made for the following items: Cabling; Cabinets and consoles; Cable vaults and conduits; Equipment Labeling shall include equipment labels, cable labels and cable addresses and color marking of cable vaults and conduits according to their disturbance group All markings shall be made in a permanent way to a lasting wear that can be mounted reliably Labels shall be fixed regularly and flexibly. If the label is hidden then it shall be doubled or there shall be a pointer for it All labeling and corresponding documents shall be compatible. 4.4 Electrical Design Power Supply Units The System shall be able to be supplied by AC main 220 volt +/- 10%, 50 Hz +/- 2% The quantity of power supply units together with associated output voltage and maximum current shall be listed All power supplies shall have protection against both overcurrent and overvoltage in case of any occurring fault, e.g. short circuit of the voltage or short circuit in some component All the AC power plugs and sockets shall be Schuko ( CEE 7/4 ) The sufficient number of power switches shall be provided for the use of the equipment with one power adapter in the environment with 2 power inputs (like a one power switch for each cabinet/rack) Cable Identification Wires carrying given signals shall be easily identifiable. Covering of different colors may be used to identify wires carrying different types of signals, e.g. supply, input, output signals, etc., and modifications to wiring. All connectors shall be identified with labels or tags. RTSI RFP v14 Page 28 of 54

29 4.4.3 External wiring and cabling Wiring between units shall be brought together to form a relatively small number of uninterconnected multicore cables. These shall be identical. The cable connectors shall be capable of being connected and disconnected more than times without any precautions being necessary All cables shall have identification at both ends according to cabling doc All cables and/or wiring shall be provided with at least 10% spare routings, with a minimum of two. 4.5 Equipment Cooling In the equipment room it is preferred that the cooling is effected by convection A failure of the cooling system for up to 30 minutes shall not affect the performance of the equipment or shorter its expected life cycle. 4.6 Electromagnetic Interference The Supplier shall state the guaranteed maximum amount of external electromagnetic radiation on band GHz that does not cause harm for the equipment Any requirement for Faraday cage shall be stated in the Tender documents The equipment shall be designed in compliance with Standard EN of European Committee for Electrotechnical Standardization (CENELEC):"Limits and methods of measurement of radio interference characteristics of information technology equipment". 4.7 Earthing All equipment shall be connected to the PE for safety reasons. Only exception is equipment with double insulation, which must be indicated with a sign on the equipment Testing of potential free level in PE grounding shall be done during startup No loops in earthing circuits are allowed, but structure of circuits shall be of "tree" type. RTSI RFP v14 Page 29 of 54