Zamawiający: Port Lotniczy Łódź im.władysława Reymonta Sp. z o.o.

Załącznik Nr 7 do SIWZ Nazwa nadana przez zamawiającego Program funkcjonalno-użytkowy Terminala T3 Międzynarodowego Portu Lotniczego im.w. Reymonta w Łodzi w zakresie sytemu transportu i kontroli bagażu rejestrowanego, sytemu kontroli bezpieczeństwa bagażu rejestrowanego, systemu odpraw biletowo bagażowych i systemu kontroli odpraw pasażerskich, sytemu informacji lotniskowej Adres 94-328 Łódź ul.gen. St. Maczka 35 Przedmiot główny 51000000-9 usługi instalowania z wyłączeniem oprogramowania komputerowego 45000000-7 roboty budowlane 30000000-9 maszyny biurowe i liczące, sprzęt i materiały z wyjątkiem mebli i pakietów oprogramowania 30200000-1 urządzenia komputerowe 72000000-5 usługi informatyczne, konsultacyjne, opracowanie oprogramowania, internetowe i wsparcia 71000000-8 usługi architektoniczne, budowlane, inżynieryjne i kontrolne Przedmiot dodatkowy 51511000-7 usługi instalowania urządzeń wyciągowych i transportowych z wyjątkiem wind i podnośników. 45234200-8 systemy transportu liniowego 45213333-6 roboty instalacyjne związane z punktami odpraw na lotniskach 45223000-6 roboty budowlane w zakresie konstrukcji 45223210-1 roboty konstrukcyjne z wykorzystaniem stali 30177000-0 automatyczne systemy etykietowania 31625200-5 dźwiękowa i wizualna aparatura sygnalizacyjna 45234200-8 systemy i serwery informacyjne 45311000-0 roboty w zakresie okablowania oraz instalacji elektrycznych 72212900-8 usługi opracowania oprogramowania i systemy komputerowe. 71320000-7 usługi inżynieryjne w zakresie projektowania 71321000-4 usługi inżynierii projektowej dla mechanicznych i elektrycznych instalacji budowlanych 71327000-6 usługi projektowania konstrukcji nośnych Zamawiający: Port Lotniczy Łódź im.władysława Reymonta Sp. z o.o. 94-328 Łódź ul.gen. St. Maczka 35 Osoby opracowujące program funkcjonalno użytkowy: Krzysztof Olszowski Jarosław Tomsia 31

Spis zawartości: 1. 1.1 1.1.1 1.1.2 1.1.3 Część opisowa Opis ogólny przedmiotu zamówienia Zakres robót budowlanych Aktualne uwarunkowania wykonania przedmiotu zamówienia Ogólne właściwości funkcjonalno- użytkowe 2. Szczegółowe właściwości funkcjonalno- użytkowe-opis wymagań zamawiającego System transportu i kontroli bagażu rejestrowanego System kontroli bezpieczeństwa bagażu rejestrowanego, System odpraw biletowo- bagażowych i system kontroli odpraw pasażerskich System informacji lotniskowej Cześć informacyjna Kopia projektu wykonawczego (PDF) Kopia pozwolenia na budowę Założenia technologiczne dla systemów odpraw pasażerów oraz kontroli i transportu bagażu zmiany projektu wykonawczego (PDF) Dane techniczne sprzętu używanego w sortowni. 2.1 2.2 2.3 2.4 3. 3.1 3.2 3.3 3.4. 1.Część opisowa 1.1. Opis ogólny przedmiotu zamówienia Przedmiotem zamówienia jest zaprojektowanie i wykonanie instalacji oraz dostawa systemów : transportu i kontroli bagażu rejestrowanego, kontroli bezpieczeństwa bagażu rejestrowanego, odpraw biletowo bagażowych i kontroli odpraw pasażerskich informacji lotniskowej, w budynku Terminala T3 realizowanym na podstawie projektu budowlanego opracowanego przez mgr.inż.ach. Leszka Szostaka Systemy muszą spełniać wymagania DOC.30ECAC Aneks Nr 1 ( Appendix 1) W ramach zamówienia wymagane jest wykonanie dokumentacji powykonawczej. Dokumentacja ta wykonana musi być w formie graficznej papierowej ( hard copy ) i elektronicznej ( formaty nie edytowalne) w 5 egzemplarzach. 1.1.1 Zakres robót budowlanych W zakres robót budowlanych wchodzi wykonanie wszelkich : a) -fundamentów -konstrukcji wsporczych -podwieszeń -pomostów i schodów oraz barier 32

-odbojnic niezbędnych do wykonania ww. systemów oraz związane z tym prace wykończeniowe w tym malarskie, oznakowania organizacji ruchu i bhp niezbędne dla prawidłowej eksploatacji. b) -instalacji zasilających urządzenia od dedykowanych rozdzielnic NN lub gniazd elektrycznych wraz z szafami sterowniczymi -instalacji nisko prądowych dla tych systemów służących sterowaniu i przesyłania danych 1.1.2 Aktualne uwarunkowania wykonania przedmiotu zamówienia Budowa terminala T3 realizowana jest obecnie przez generalnego Wykonawcę tj.: Konsorcjum 1. HOCHTIEF Polska sp. z o.o. ul. Elbląska 14, 01-737 Warszawa 2. WARBUD S.A. Al. Jerozolimskie 162 A, 02-342 Warszawa 3. HOCHTIEF Construction AG Opernplatz 2, 45128 Essen Niemcy Wymagany termin zakończenia robót : 1 czerwiec 2011 1.1.3. Ogólne właściwości funkcjonalno- użytkowe I. System BHS Urządzenia i systemy zaprojektowane i wykonane dla Terminala T 3 powinny zapewnić obsługę 1.5-3.0 mln pasażerów w roku. Powierzchnia Terminala T3-24 676,79 m2, kubatura 125 509 m3 System odlotów System odpraw - wysepka z 14 stanowiskami odpraw, każde dwutaśmowe, z wagą, - 1 stanowisko bagażu ponad wymiarowego, - 1 taśmociąg zbierający, - 1 taśmociąg przesyłający bagaż do sortowni, - 2 żaluzje bezpieczeństwa. System skriningowy - czujnik detekcji wysokości bagażu przed urządzeniem skrinirigowym, - taśmociągi zasilające - urządzenia skriningowe, - integracja urządzeń skriningowych z systemem transportu bagażu, - sortowanie bagażu podejrzanego do manualnej kontroli, - taśmociąg wprowadzający sprawdzony bagaż do systemu. Sortowanie na zrzuty - automatyczny czytnik nalepek, 33

- taśmociąg z urządzenia skriningowego, - taśmociąg sortera. Sorter pionowy (Vertisorter) i zrzuty - automatyczny czytnik kodów - 6 diverterów, - 6 zrzutów, - system kontrolny sortera. Bagaż ponad wymiarowy obsługiwany będzie oddzielnie, poza systemem transportu bagażu. System jego obsługi składał się będzie ze stanowiska check-in wyposażonego w wagę, taśmociągu transportującego, urządzenia skriningowego i taśmociągu rolkowego. Przyloty - 3 Taśmociągi rozładowcze, - 3 taśmociągi przed urządzeniami skaningowymi, - 3 taśmociągi po urządzeniach skriningowych kontroli celnej, umożliwiające zdjęcie/dołożenie bagażu, - 3 linie taśmociągów, transportujące bagaż do karuzeli, - 1 karuzela typu O, nachylone, na 2 rzędy bagaży, - 2 karuzela typu O poziome - 3 żaluzje bezpieczeństwa oraz 3 kurtyny. System kontrolny - komputer sortujący, - system PLC, - szafa sterownicza, - system SCADA, - sieć do połączenia systemu SCADA z komputerem sortującym - okablowanie, - szafa sterownicza systemu przylotów. System bezpieczeństwa bagażu rejestrowanego muszą zapewnić pełną kontrolę bagażu w tym wykrywalność materiałów radioaktywnych i wybuchowych. System powinien być wielopoziomowy i tak: Poziom I - urządzenie EDS pracujące w trybie automatycznym. W przypadku braku zagrożenia prześwietlany bagaż przechodzi na taśmociąg prowadzący do sortera. Poziom II stacje robocze połączone są z urządzeniami poziomu I poprzez sieć i pracują w układzie macierzowym, który nie wiąże danego urządzenia EDS na stałe ze wskazana stacja roboczą, ale zapewnia transmisje kolejnego w czasie obrazu bagażu o statusie niepewny na pierwsza wolna stacje roboczą.( wymagana decyzja operatora) Poziom III urządzenie EDS pracuje w trybie detekcji nieautomatycznej ( z operatorem i stacja roboczą).konfiguracja systemu powinna zapewnić operatorowi III poziomu czas 15-30 sekund na podjecie decyzji o zwolnieniu bagażu,skierowania go do dalszej kontroli lub wezwaniu pirotechnika. Poziom IV oddzielna cześć taśmociągu lub stołu w pomieszczeniu przeznaczonym do przywołania pasażera i dokonania kontroli w jego obecności. Powinna być zapewniona możliwość transmisji obrazu sprawdzanego bagażu z poziomu II lub III. Poziom V stanowisko dla bagażu zagrożonego powinno być wyposażone w urządzenie przeznaczone do neutralizacji bagażu zagrożonego( ewakuacji 34

II. System odpraw biletowo bagażowych i System kontroli odpraw pasażerskich (DCS) Opis ogólny systemu DCS - rozbudowa systemu funkcjonującego w Terminalu nr 2 System kontroli odlotu samolotu musi spełniać warunki informatycznego systemu automatycznej obsługi odpraw rejsów przewoźników lotniczych, który będzie łączył w czasie rzeczywistym linie lotnicze oraz agentów handlingowych z siecią transportu lotniczego. Jego zadaniem będzie zautomatyzowanie pracy agenta obsługi naziemnej w trakcie przygotowania operacji lotniczej przed odlotem samolotu. System musi mieć możliwość współpracy z systemem transportu i kontroli bagażu oraz z systemem informacji lotniczej FIS. Wdrożenie lokalnego systemu odpraw w Porcie Lotniczym Łódź odbywać się będzie na: czternastu stanowiskach odpraw biletowo - bagażowych, siedmiu bramkach (gate), trzech stanowiskach nadzoru, jednym stanowisku w bagażowni; jednym stanowisku szkoleniowo - treningowym Dostawca systemu zapewni: szkolenia dla załogi Portu Lotniczego Łódź; procedury awaryjne w razie awarii łączy, systemu; możliwość łatwej rozbudowy systemu w przypadku modernizacji lotniska; przeprowadzenie wszystkich niezbędnych konsultacji i ustaleń celem uruchomienia systemu trening personelu w zakresie obsługi sytemu na w pełni wyposażonym stanowisku szkoleniowym Założenia użytkowe: System zapewni zaawansowaną komunikację w poniższych obszarach. odprawa pasażerska odprawa bagażowa obsługa statków powietrznych (planowanie załadunku i wyważanie) BRS łączenie bagażu z pasażerem tabela przylotów i odlotów obejmująca dane na bieżący dzień i cztery następne dni archiwalne dane za 2 ostatnie dni odprawa przez Internet wsparcie dla biletów elektronicznych 35

Architektura systemu: Generowanie automatycznie PNL/ADL/SAL wczytywanych automatycznie z dostępnej listy pasażerów z systemów rezerwacyjnych Szybka odprawa ( check-in) poprzez graficzny interfejs użytkownika (GUI) Obsługa biletów typu ETIX Obsługa danych API W pełni integralny system z procedurą ICA dokument 30 (Reconciliation Procedure) W pełni integralny system wyważenia samolotów z automatycznym planowaniem załadunku oraz dystrybucji. Link do systemów wysyłania depesz ruchowych i systemu poszukiwania bagażu zagubionego Automatyczna aktualizacja rezerwacji, programu często latających pasażerów Funkcjonalność systemu: Przygotowanie rejsu Automatyczna obsługa PNL wraz z jej edycją Rozwiązanie dla rejsów typu CODE SHARE lub CHANGE OF GAUGE Web check-in, Mobile Check-in Electronic Ticket Check-in Poodlotowa kontrola sytemu rezerwacji przewoźnika (przesyła automatyczny danych API) Statystyki Check-in: Odprawa prezentacja w formacie Windows W pełni automatyczna odprawa oraz druk kart pokładowych i zawieszek bagażowych Odprawa pasażerów z biletem elektronicznym. Odprawa poprzez Internet lub telefon komórkowy Prosta odprawa lub odprawa w jednym systemie IATCI (Inter Airline Through-check-in) : Druk kart pokładowych w standardzie IATA Możliwość druku voucher ów Możliwość wprowadzenia danych API dla pasażera Możliwość wprowadzenia jump seat Możliwość wprowadzenia API dla załogi Zgodność z aktualnymi regulacjami odprawy pasażerów. Gate Boarding Control: Akceptacja pasażerów z tzw. listy oczekujących wraz z możliwością zmiany klasy w górę lub dół. Automatyczny odczyt kart pokładowych we współpracy z BGR czytnik kart z bar code. Rekoncyliacja bagażu oraz planowanie załadunku: Automatyczny rejestr numeracji zawieszek bagażowych w trakcie wydruku Czytnik kodów typ BAR w przypadku pasażerów transferowych Spełnienie wymogów IATA anex 17 ( ochrona bagażu) 36

Wysłanie wiadomości w standardzie IATA jak: BSM,BTM,BPM w komunikacji z sortownią. Druk etykiet kontenerowych Automatyczny lub ręczny druk etykiet kontenerowych Definiowanie typów kontenerów do załadunku według ( klasy, destynacji, itp.) Automatyczna alokacja bagażu w kontenerze Automatyczne planowanie załadunku Planowanie ilości bagażu do załadunku w poszczególnych klasach Kalkulacja wymaganych kontenerów wymaganych dla poczty lub bagażu (funkcja klasy) i pasażerów transferowych. Kalkulacja masy cargo w sekcji cargo Automatyczna dystrybucja załadunku Wstępne planowanie ustawień wyważenia Automatyczna dystrybucja załadunku dla każdego typu samolotu Wyszukiwanie najkorzystniejszego TRIM-u Planowanie załadunku na całej drodze przelotu Obserwacja restrykcji załadunku w celu uniknięcia przeciążenia. Load Sheet: Dokument wyważenia zgodny z normami IATA Tymczasowy dokument załadunku Dokument zgodny z modelem ACARS NOTOC (Notice to captain or restricted articles) Jako dodatkową funkcjonalność- wagi samolotu mogą być podawane w funkcjach Web Check-in: Maksymalnie 4 kroki przy dokonywaniu odprawy przez Internet 1. Identyfikacja wyboru przez pasażera biletu lub E-PNR oraz numer lotu: 2. Odprawa: użytkownik wybiera pasażerów i rejsy na które chce się odprawić. Potwierdzenie: użytkownik może wyświetlić mapę pokładu, dokonać zmiany miejsca i zmienić jego numer FQTV,potwierdzić dane wejściowe (API) 4. Drukowanie kart pokładowych-karta pokładowa będzie generowana w formie PDF z możliwością wysyłki na adres e-mail pasażera. Po odlotowa kontrola rejsu: System musi umożliwiać automatyczne wysłanie depesz końcowych do systemu rezerwacji przewoźnika: Passenger Final Sales (PFS), Frequent Traveller List (FTL),Passenger Reconcile List (PRL),Electronic Ticket List (ETL) System musi automatycznie wysyłać wiadomości operacyjne : LDM, MVT, CPM, PTM, SOM 37

III. System informacji lotniskowej ( z wykorzystaniem Avia-Vox) A. Opis ogólny systemu informacji wizualnej dla pasażerów FIDS 1. Zaprojektowaniu systemu informacji lotniskowej FIDS wraz z: zapewnieniem jego integracji z systemem FIS zapewnieniem możliwości wykorzystania istniejącego systemu AviaVox funkcjonującego aktualnie w Terminalu Pasażerskim nr2, umożliwieniem wykorzystania systemu nagłośnieniowego (zaprojektowanego w oddzielnym zadaniu na potrzeby DSO). 2. Dostawie i wdrożeniu systemu wizualnej informacji podróżnych FIDS (Flight Information Display System) stanowiącego integralną część systemu informacji lotniskowej lub będącego osobnym systemem pobierającym informację z systemu FIS. 3. Dostawie i uruchomieniu urządzeń wykorzystywanych przez instalowany system wraz z oprogramowaniem na 2 stanowiskach operatorskich i jednym mobilnym stanowisku nadzoru. System musi być wyposażony w min.: a) Stacje robocze wraz z konfiguracją b) Sterowniki monitorów LCD c) Serwery AVX do systemu Avia-Vox 4. Przeniesieniu aktualnie funkcjonującego w Terminalu nr 2 do nowego Terminala nr 3 i rozbudowie oraz zintegrowanie systemu Avia-Vox z systemem informacji lotniskowej. Przez rozbudowę systemu Avia-Vox rozumie się: a. dodanie dodatkowego serwera zabezpieczającego ciągłość działania systemu, b. poszerzenie biblioteki komunikatów o komunikaty dla 3 nowych przewoźników (łącznie ok. 20 nowych komunikatów), c. implementacja modułu umożliwiającego współpracę z systemem DSO i nadawanie 1 komunikatu ewakuacyjnego, d. umożliwienie nadawania komunikatów ze zróżnicowaniem na strefy (5-6 stref), e. umożliwienie zmiany głośności komunikatów w poszczególnych strefach 7. Zapewnieniu zamawiającemu: - szkolenia dla załogi Portu Lotniczego Łódź - procedur awaryjnych w razie awarii łączy systemu - możliwości łatwej rozbudowy systemu w przypadku modernizacji lotniska - przeprowadzenia wszystkich niezbędnych konsultacji i ustaleń celem uruchomienia systemu - zastosowania zasilania gwarantowanego UPS Założenia użytkowe do systemu FIDS 1. Przez FIDS rozumie się system prezentujący dane dotyczące operacji lotniskowych. Zadaniem systemu jest automatyczna i ręczna wizualizacja przetwarzanych informacji dla pasażerów oraz pracowników portu. 38

1.1 Baza danych System FIDS ma być oparty na bazie danych systemu FIS. Centralna baza danych zapewni możliwość tworzenia, zapisywania i usuwania danych z zastosowaniem zaprogramowanych własnych procesów selekcji. W systemie muszą znajdować się co najmniej dwa serwery (główny i zapasowy). Baza danych znajdująca się na serwerze zapasowym musi być zsynchronizowana z bazą znajdującą się na serwerze głównym. W przypadku awarii serwera głównego musi nastąpić automatyczne przełączenie systemu na serwer zapasowy w sposób niezauważalny dla stacji klienckich. Serwery muszą posiadać własne zasilanie awaryjne. 2. System wizualnej informacji podróżnych FIDS w połączeniu z systemem informacji lotniskowej FIS umożliwi spełnienie następującej funkcjonalności: 2.1 Umożliwi prezentację, m.in. w: sali ogólnodostępnej (hal główny, restauracje, check-in, parking pod terminalem ), W strefie dozorowanej, zastrzeżonej i krytycznych częściach strefy zastrzeżonej (bagażownia, sortownia bagażu, wieża, strefa przylotów, strefa odlotów, punkty kontroli bezpieczeństwa, pomieszczenia dla pracowników), na dowolnym dostępnym typie wyświetlacza następujących typów informacji: a) dane o lotach aktualizowane na bieżąco w czasie rzeczywistym, zapewniając minimum: rozkład przyloty (czas przylotu/odlotu, logo/nazwa przewoźnika, miasto skąd/dokąd przylatuje/odlatuje samolot, oczekiwany czas przylotu/odlotu, numer rejsu, inne uwagi) rozkład odloty (jw.), bieżące przyloty, bieżące odloty, rozkład i bieżące przyloty i odloty razem lub w sposób naprzemienny na jednym monitorze, odprawy (check-in), boarding gate, bagaże, zestawienie bieżących gate-ów, inne informacje techniczne. b) dane o charakterze multimedialnym (loga, zdjęcia, filmy, informacje dla podróżnych, komunikaty pogodowe zarówno lokalne jak i dla miejsc docelowych lotów, komunikaty specjalne, instrukcje bezpieczeństwa, wygaszacze ekranu, reklamy, RSS, TV, internet), 2.2 Zapewni, że sposób prezentacji informacji będzie w pełni konfigurowalny (np. umożliwiający prezentację danych o kilku lotach naprzemiennie lub w tabeli) i umożliwi pełną jej zarządzalność np. wyglądu danych (kolory, czcionki, rozmieszczenie informacji), 2.3 Pozwoli na dowolne wykorzystanie monitorów podłączonych do systemu w zakresie wszelkich możliwych informacji i danych zarządzanych przez system 39

(oznacza to, że każdy wyświetlacz z osobna lub w grupach mogą wyświetlać każde dowolne informacje), 2.4 Umożliwi strefowe wyświetlanie informacji tekstowych i multimedialnych (będą wyświetlane na całości ekranu, jego dowolnej części np. w postaci przewijanego paska, lub na dowolnie połączonych wyświetlaczach w tzw. ściany wizyjne grupujące pojedyncze ekrany w jeden logiczny wyświetlacz), 2.5 Pozwoli, aby dobór informacji multimedialnej mógł się odbywać automatycznie na podstawie kontekstu (context sensitive information), który tworzy informacja dotycząca konkretnej operacji lotniczej (informacja o miejscu przeznaczenia, pogoda, informacja turystyczna, reklamy). Informacje muszą być prezentowane zgodnie z przepisami ICAO. 2.6 Zapewni, że informacje będą zmieniać się dynamicznie i inteligentnie (np. w przypadku zmiany gate u informacja pojawia się automatycznie tylko w odpowiednich miejscach by dotrzeć do konkretnej grupy pasażerów), 2.7 Pozwoli na wyświetlanie informacji w wielu językach na różnych wyświetlaczach. 2.8 Umożliwi personelowi na stanowiskach dodawanie/edycję komunikatów na bieżąco. check-inów i w gate ach 2.9 Pozwoli na kierowanie stosownych informacji do personelu, a w razie problemów do centrum dowodzenia i administratora. 2.10 Pozwoli na aktualizowanie informacji na wszystkich wyświetlaczach w czasie nie dłuższym niż 1 sekunda od momentu przesłania jej do systemu 2.11 Umożliwi przesyłanie danych na stronę internetową portu oraz tworzenie własnych stron internetowych w formacie HTML a także wysyłanie wiadomości w formacie XML. 3. FIDS będzie współpracował z innymi systemami zewnętrznymi nie będącymi częścią składową niniejszego systemu. System powinien posiadać możliwość rozbudowy o: 3.1 Interactive Voice Response (IVR) Interaktywny system informacji głosowej pozwala na informowanie pasażerów drogą telefoniczną. Pasażer wybierając numer a dalej odpowiednie rozszerzenia może uzyskać informację na temat wybranego lotu: godziny odlotu, przylotu, opóźnienia, statusu itp. 3.2 Internet, Intranet, urządzenia mobilne Informacja o lotach może być przekazana na stronę internetową portu. Informacja dla obsługi i pracowników może być przekazywana po sieci wewnętrznej lub TCP-IP. Dotyczy to również zadań związanych z utrzymaniem i obsługą samego systemu. 3.3 System bezpieczeństwa i ewakuacji 40

W sytuacji zagrożenia system może automatycznie wyświetlać komunikaty o ewakuacji, wskazywać jej kierunek poprzez interfejs z systemem DSO 3.4 Wiadomości SMS System ten pozwala na automatyczne wysyłanie SMSów do pasażerów oraz obsługi na podstawie otrzymywanych danych w czasie rzeczywistym Tablice i monitory dostarcza i montuje Generalny Wykonawca tj. konsorcjum firm Warbud-Hochtieff. Proponowane urządzenia to: MONITORY NEC MultiSync LCD4215 2 TECHNICAL SPECIFICATIONS Panel Technology S-IPS TFT Active Screen Area (W x H) [mm] 930.25 x 523.01 Screen Size [inch/cm] 42 / 106.7 Pixel Pitch [mm] 0.681 x 0.681 Viewing Angle [ ] 178 horizontal / 178 vertical (typ. at contrast ratio 10:1) Screen Aspect Ratio 16:9 Contrast Ratio (typ.) 800:1 Brightness (typ.) [cd/m²] 500 Response Time (typ.) [ms] 9 (grey-to-grey) Colours [Mio.] 16.77 Horizontal Frequency [khz] 31.5-91.1 (analog and digital) Vertical Frequency [Hz] 50.0-85.0 Optimum Resolution 1360 x 768 at 60 Hz Native Resolution 1366 x 768 at 60 Hz Supported Resolutions 1920 x 1080; 1600 x 1200; 1440 x 1050; 1280 x 1024; 1024 x 768; 832 x 624; 800 x 600; 720 x 400; 640 x 480 Video Input Analog: RGBHV (BNC); Analog: Composite (BNC + RCA); Analog: Component (BNC); Analog: 1 x S-Video; Analog: 1 x D-sub 15 pin; Digital: 1 x DVI (with HDMI) Video Output Analog: 1 x D-sub 15 pin; Analog: Composite (BNC) Audio Input 2 x Cinch (RCA); 1 x Head-jack 3.5 mm Audio Output 2 x amplified speaker signal; 1 x Cinch (RCA) Plug & Play VESA DDC2B Safety and Ergonomics CE; ERP; TÜV GS; C-tick; FCC Class B; UL/C-UL or CSA; CCC; PSB; VCCI; RoHS Power Consumption on Mode [W] 190 Power Management VESA DPMS Power Supply 100-120 V/220-240 V; 3.0 A/1.2 A; internal power supply Ambient Temperature (operating) [ C] Operation Temperature: +5 to +40 Landscape +5 to +35 Portrait Ambient Humidity (operating) [%] 20 to 80 VESA Mounting [mm] 400 x 200 (FDMI); 12 holes / 100 mm spacing Dimensions (W x H x D) [mm] Without stand: 1022.9 x 613.5 x 133 41

Bezel Width [mm] 44.2 (left and right); 43.3 (top and bottom) Benefits NaViSet and NaViSet Administrator compatible; Overheating protection, with 2 fans as back up; protective glass ready; Temperature Sensor; temperature sensors readable via OSD Supported TV Standards (no tuner) SECAM; PAL; NTSC Video Modes (no tuner) 480i; 480p; 576i; 576p; 2 x720p (50 and 60 Hz); 2 x 1080i (50 and 60 Hz); 2 x 1080p (50 and 60 Hz) Audio Functions Optional Speakers (7 W + 7 W) Remote Control RS-232C (9-pin D-sub) Input and Output; D-sub 15 and DVI-D (DDC/CI); Remote Control IR Colour Versions Black Front Bezel, Black Back Cabinet Wall Mounts Optional: W32-70L Shipping Content Display; Power Cable; Signal Cable VGA - VGA; Remote Control (IR); CD-ROM (User Guides/Manuals) Stand Optional Warranty 3 years warranty incl. backlight All hardware and software names are brand names and/or registered trademarks of the respective manufacturers. All rights reserved. All specifications are subject to change without notice. 03/10 TABLICE - Producent: P.P.H. ELTIN S.C. Al. Piastów 41 71-065 Szczecin - Wymiary zewnętrzne ~200cm x 150 cm, - Wysokość znaku 6cm ( 8diod LED ), - Zbudowana z 8 wierszy oraz zegara ( synchronizacja z centralnego zegara ), - Umożliwiającą wyświetlenie w każdym wierszu : czas odlotu ( 5 znaków ), kierunek ( 10 znaków ), numer lotu ( 6 znaków ), uwagi ( ~ 15 znaków ), - Sterowanie z karty sieciowej (Ethernet), - Komputer PC o parametrach : min Core2 Duo E4600 2,4GHz, 2Gb RAM, dysk 500Gb, DVD DL, karta graficzna z pamięcią GT 512MB HDTV & DVI, karta sieciowa, system operacyjny, monitor LCD 19". - Wygląd zewnętrzny zgodny ze standardem Terminal II, 42

B. Ogólny opis systemu FIS System informacji lotniczej FIS musi być oparty na centralnej bazie danych i mieć możliwość gromadzenia, przetwarzania i publikacji informacji związanych z ruchem lotniczym na lotnisku. System musi być wyposażony w moduły operacyjne do wykorzystania przez służby obsługi naziemnej. System musi umożliwiać współpracę z systemami informacji wizualnej FIDS i głosowej DOS (w tym alarmowej), oraz z systemem transportu i kontroli bagażu i systemem DCS. Przesył informacji do współpracujących systemów musi odbywać się automatycznie wg. harmonogramu z centralnej bazy danych i/lub na podstawie wiadomości z systemów zewnętrznych. Dostawca systemu zapewni: - szkolenie dla personelu Portu Lotniczego - procedury awaryjne w przypadku awarii - możliwość łatwej rozbudowy systemu - przeprowadzenie niezbędnych konsultacji celem uruchomienia systemu Założenia funkcjonalne: System musi być zgodny z standardami IATA System powinien być dostępny w dwóch językach: polskim i angielskim. Wszystkie funkcjonalności systemu muszą być spełnione na dzień składania ofert Serwer powinien gromadzić dane w dowolnej bazie danych zgodnej ze standardami ODBC oraz umożliwiać równoczesną pracę wielu użytkowników na tych samych zbiorach danych w sposób asynchroniczny/zdarzeniowy. Zapis danych pochodzących z innych źródeł niż interfejs użytkownika w aplikacji klienta powinien odbywać się za pośrednictwem konfigurowalnych serwisów pozwalających na zbudowanie rozproszonej struktury kolektorów danych. Do systemów dostarczających dane zewnętrzne powinien należeć system przesyłający wiadomości typu B ( np. Sita Sitatex, Arinc Avinet), Informacje rozgłaszane do/z systemów zintegrowanych z systemem powinny być rozsyłane automatycznie przez serwer w sposób asynchroniczny/zdarzeniowy. Gromadzone dane wprowadzone z poziomu interfejsu użytkownika lub za pośrednictwem kolektorów danych powinny być automatycznie publikowane do wszystkich połączonych klientów oraz serwisów w sposób asynchroniczny 43

od razu po otrzymaniu i przetworzeniu informacji przez serwer o ile są uprawnieni do otrzymywania danego typu informacji. System musi posiadać bazę słownikową typów statków powietrznych operujących w lotnictwie cywilnym składającą się z danych: Kod IATA, KOD ICAO, Nazwa typu statku powietrznego, konfigurację pokładu, dane nt. frachtu, max pojemność zbiorników paliwa, max masę do startu (MTOW), zasięg, prędkość przelotową, sylwetki i wymiary samolotów. System musi posiadać bazę słownikową rejestracji składającą się z danych: Rejestracja statku powietrznego, Typ statku powietrznego, Linia lotnicza. System musi posiadać bazę słownikową linii lotniczych składającą się z danych: Kod IATA, Kod ICAO, Nazwa linii lotniczej, Kraj, Informacja czy linia jest typu lowcost. System musi posiadać bazę słownikową portów lotniczych składającą się z danych: Kod IATA, Kod ICAO, Nazwa portu, kraj, Informacja czy port jest w strefie Schengen czy nie. Rozwiązanie powinno składać się z modułów umożliwiających: 1. Układanie, edycję, podgląd oraz publikacja rozkładu rejsów, 2. Podgląd depesz MVT, LDM, PSM, PTM, SLS itp., 3. Automatyczne wiązanie depeszy przychodzącej oraz wychodzącej z odpowiadającym mu rejsem wprowadzonym do rozkładu rejsów, 4. Interpretacja depesz polegająca na wydzieleniu pól z depeszy o specyficznym znaczeniu oraz prezentacja tych informacji na interfejsie użytkownika, 5. Edycję i rozszerzanie bazy danych takich jak: baza portów lotniczych, baza statków powietrznych, baza linii lotniczych wraz z oznaczeniami IATA oraz ICAO, 6. Zarządzenie użytkownikami systemu oraz ich uprawnieniami pozwalającymi na profilowanie uprawnień do poszczególnych modułów systemu takich jak: dostęp, podgląd, edycja, dodawanie nowych danych oraz ich usuwanie, 44

7. Dostęp do danych operacyjnych pozwalających na szybki dostęp do informacji takich jak: nadchodzące rejsy przylotowe oraz odlotowe, opóźnienia, liczba pasażerów odczytana z widomości MVT lub LDM, liczba pasażerów z bookingu, godzina przylotu, godzina wylotu, 8. Prezentacja danych czasowych w postaci wykresów Gantta ułatwiających interpretację danych czasowych oraz w postaci tabeli, 9. Możliwość szybkiej filtracji danych prezentowanych w systemie po wybranych filtrach czasowych, numerów rejsów, kodów opóźnień oraz innych filtrów, 10. Możliwość wydruku danych prezentowanych w dowolnym module systemu wraz z możliwością ich eksportu 11. Możliwość planowania stanowisk postojowych dla statków powietrznych, 12. Możliwość generowania raportów oraz statystyk takich jak: a. Liczba rejsów wraz z podziałem na ich typy (regularny, czarterowy, cargo, specjalny) w określonym przedziale czasu z możliwością filtracji po: rejsach przylotowych, odlotowych, liniach lotniczych, destynacjach, typach statków powietrznych, terminalach, itp., b. Statystyki opóźnień wraz z możliwością filtracji po: rejsach przylotowych, odlotowych, liniach lotniczych, destynacjach, typach statków powietrznych, terminalach, itp., c. Statystyki liczby podróżnych wraz z możliwością filtracji po: rejsach przylotowych, odlotowych, liniach lotniczych, destynacjach, typach statków powietrznych, terminalach, touroperatorach, itp., 13. Możliwość zarządzania zasobami ludzkimi oraz sprzętowymi (w aspekcie operacyjnym portu lotniczego) w module planowania z automatycznym przypisywaniem do wykonywania określonych czynności lub funkcji zgodnie z uprawnieniami, szkoleniami lub przeznaczeniem przy określonym rejsie, 14. Możliwość wystawienia noty handlingowej będącej potwierdzeniem wykonania usług, 15. Możliwość konfigurowania listy usług wykonywanych dla danego przewoźnika oraz typu statku powietrznego 16. Możliwość wystawiania dokumentu Service rendered, 17. Możliwość pracy w środowisku wielomonitorowym pozwalając na pracę z wieloma modułami umieszczonymi na różnych ekranach. 45

18. System musi być zgodny z polskim prawodawstwem a w szczególności z obowiązującymi przepisami prawa pracy na dzień odbioru systemu 19. System musi umożliwić dostęp do danych służbom zaangażowanym w obsługę naziemną 20. System musi mieć możliwość dostępu do danych na pokładzie statku powietrznego jak i w obrębie terminala pasażerskiego 21. System musi mieć możliwość współpracy z posiadanym systemem do fakturowania Symfonia Handel Forte. 22. System powinien mieć możliwość integracji z systemem łączności cyfrowej TETRA. Planowanie rozkładu rejsów Od modułu planowania rejsów wymaga się możliwości wprowadzania do siatki rozkładu rejsów zarówno cyklicznych jak i pojedynczych. Rejs powinien być powiązany z informacjami takimi jak: Typ rejsu regularny, charterowy, specjalny, cargo itp., Numer rejsu przylotowy oraz odlotowy z automatyczną weryfikacją poprawności linii lotniczej, Typ statku powietrznego zgodnie z kodami IATA lub ICAO, Rejestracja statku powietrznego, Trasę przelotu (z, przez, baza, przez, do) zgodnie z oznaczeniami IATA lub ICAO, Dodatkowe informacje o rejsie z postaci pola tekstowego, Informacja o przylocie lub odlocie na pusto (ferry-in, ferry-out), Datę oraz czas przylotu, Datę oraz czas odlotu, Datę oraz czas odloty ze stacji wylotu, Datę oraz czas przylotu do stacji docelowej, i mieć możliwość: wyboru czasu lokalnego lub czasu UTC w maskach służących do wprowadzania danych o rozkładzie rejsów, tworzenia maski rejsu rekurencyjnego pozwalająca na wybór dni tygodnia operowania danego rejsu, 46

przekazania informacji o bookingu czyli planowanej liczbie pasażerów, informacji o numerze Gate, informacji o pozycji postojowej dla statku powietrznego. Wizualizacji rotacji statków powietrznych na płycie lotniska w sposób graficzny za pomocą linii łączących rotujące statki powietrzne na płycie lotniska. Wydruku danych bieżącego widoku, Publikacji email danych bieżącego widoku, Eksportu danych do schowka bieżącego widoku, Przygotowania wzorca tygodniowego operowania rejsu. Ponadto moduł powinien wykrywać możliwe konflikty z numerami rejsów już wprowadzonymi do systemu operujących w tych samych dniach co nowe rejsy lub mieszczące się w określonym odstępie czasowym. Wszystkie tabele powinny być konfigurowalne pozwalając na wybór kolejności kolumn, sortowanie po wielu kolumnach, filtrowanie zawartości. Powinna istnieć także możliwość publikacji danych bezpośrednio z modułu planowania rozkładu rejsów w postaci wiadomości e-mail z załączonym dokumentem prezentującym dane o rozkładzie rejsów do wybranej, konfigurowalnej listy odbiorców. Integracja z systemem przesyłającym wiadomości typu B Rozwiązanie powinno być zintegrowane ze środowiskiem przesyłającym wiadomości typu B pozwalając na automatyczny, ciągły import danych zawartych w depeszach różnego typu. Depesze przychodzące oraz wychodzące powinny być wiązane z rejsem dodanym w module planowania rozkładu oraz zdekodowane, które będą wykorzystane w innych częściach systemu. Wymagana jest zdolność zapisywania oraz interpretowania depesz typu: MVT, LDM, SLS, ASM, CPM. System ma zapewnić szybki i łatwy dostęp do kolekcji depesz każdego typu w osobnym module, wraz z możliwością wydruku listy oraz filtracji po wybranych kolumnach takich jak: numer rejsu, kod opóźnienia, przewoźnik, czas odebrania depeszy itp. Na etapie wdrożenia należy zapewnić integracje z systemami operatora np. SITA, ARINC Moduł powinien posiadać tabele: Kontener główny, będący zbiorem wszystkich wiadomości wysłanych na określone adresy odbiorców, gdzie lista adresów powinna być konfigurowalna na serwerze odbierającym dane, zapisującym je w bazie AODB, oraz rozsyłającym nowe wiadomości do zalogowanych użytkowników posiadających prawa do odczytu tych wiadomości, Kontener z wiadomościami MVT, będący zbiorem wszystkich wiadomości ruchowych, Kontener z wiadomościami LDM, będący zbiorem wszystkich wiadomości Load Messeges, Kontener z wiadomościami SLS, będący zbiorem wszystkich wiadomości SLS, 47

Kontener z wiadomościami ASM, będący zbiorem wszystkich wiadomości ASM, Kontener z wiadomościami CMP, będący zbiorem wszystkich wiadomości SMP. Każda z tabel powinna być tabelą pozwalającą na dowolne ułożenie kolejności kolumn, sortowanie po wielu kolumnach oraz filtrowanie danych w wielu kolumnach, pozwalając na tworzenie złożonych filtrów. Postać tabelaryczna kontenera głównego wiadomości powinna zawierać takie dane jak: Czas odebrania lub wysłania wiadomości, Zawartość oryginalnej wiadomości, Linia lotnicza, Priorytet wiadomości, Adres nadawcy, Lista adresów odbiorców, Temat wiadomości, Typ wiadomości (MVT, LDM, PSM, PTM, SLS i inne), Informacja czy jest to wiadomość przychodząca czy wychodząca. Dane, które powinny być interpretowane z depesz MVT to: Numer rejsu, Dzień operowania, Rejestracja statku powietrznego, Oznaczenie IATA portu wysyłającego informację, Czasy: touchdown, chocks on block, off-block, take off, estimated time of arrival, estimated time of departure, next information, oznacznie IATA portu do którego skierowana jest wiadomość, Dodatkowe informacje, Kody opóźnień, Liczba pasażerów. Dane, które powinny być interpretowane z depesz LDM to: Numer rejsu, Dzień operowania, Rejestracja statku powietrznego, Wersja statku powietrznego, Załoga, Oznaczenie IATA portu do którego skierowana jest wiadomość, Liczba pasażerów z wydzieleniem liczby infantów, Liczba pasażerów na klasę, informacje o załadunku, Moduł operacyjny Część operacyjna systemu powinna zawierać informacje o nadchodzących rejsach przylotowych oraz odlotowych, prezentowanych w postaci wykresu Gantta oraz tabeli w określonym przedziale czasowym do przodu lub w wybranym z kalendarza dniu lub okresie czasu. Dane przylotowe oraz wylotowe powinny być prezentowane na osobnych tabelach i wykresach Gantta. Postać tabelaryczna operacji przylotowych powinna zawierać takie dane jak: Numer rejsu, Data oraz czas przylotu, Czas ATA, Czas ETA, Trasa przelotu, Typ statku powietrznego, Rejestracja statku powietrznego, Numer pozycji postojowej statku powietrznego na płycie lotniska, Numer radiotelefonu, telefonu, Imię i nazwisko Ramp Agenta, Kody opóźnień zaimportowane z depesz MVT, Liczba pasażerów pobrana z depesz LDM, Cargo pobrana z depesz LDM, Załoga pobrana z depesz LDM, Mail pobrana z depesz LDM, Pole dodatkowych informacji tekstowych. Postać tabelaryczna operacji przylotowych powinna dawać możliwość: Dowolnego ułożenia kolejności kolumn, Sortowania po jednej lub wielu kolumnach, Włączanie lub wyłącznie widoku wybranej kolumny, 48

Filtrowania po dowolnej kolumnie, Eksport danych do schowka bieżącego widoku. Rozróżniania graficznego rejsów o różnym statusie: -Status nieokreślony, dla rejsów o nieznanych danych ETA, ATA, DL, CANCEL, -Status rejsu opóźnionego w przypadku gdy różnica między czasem ATA a ETA jest większa niż określona wartość konfigurowana w ustawieniach programu, -Status rejsu na prostej, -Status rejsu odwołanego, -Status rejsu wylądował Wyświetlania podsumowania z liczby operacji przewoźników w postaci tabeli zawierającej: -Nazwę linii lotniczej wraz z kodem IATA, -Liczba wszystkich operacji, -Liczba operacja dla każdego typu rejsu (regularny, charter, cargo, special, symulowany). wraz z numerem rejestracyjnym statku powietrznego, kodem opóźnienia, liczbą pasażerów. Informacje te powinny zostać pobrane z wiadomości typu B. Dodatkowo celem ułatwienia interpretacji ekranu powinno nastąpić rozróżnienie graficzne rejsów o statusie nieznanym, opóźnione, odwołane, wylądowały, wystartowały. Każdemu rejsowi z poziomu ekranu operacyjnego powinno dać się przypisać status wylądował, wystartował, na prostej lub odwołany. Nadanie statusu wylądował powinno skutkować wyświetleniem dodatkowej informacji zawierającej numer rejsu oraz czas jego lądowania lub startu. Wszystkie dane dodatkowe związane z rejsem jak: numery stanowisk postojowych, numery otwartych stanowisk check-in, numery otwartych gate ów, lista osób przypisanych do obsługi rejsu, lista sprzętu przypisanego do obsługi rejsu, lista depesz lotniczych każdego interpretowanego typu, powinna być dostępna w osobnym oknie wraz z możliwością edycji i dokonywania zmian. Ponadto w module tym powinna istnieć możliwość przeglądu operacyjnych danych historycznych wraz z możliwością filtracji po: numerach rejsów, liniach lotniczych, kodach opóźnień, destynacjach. Moduł operacyjny powinien posiadać możliwość wydruku raportów o spodziewanych operacjach, raportu dziennego z zachowaniem danych o rotacji statków na płycie, raportu z bookingu. Wszystkie ustawienia widoku powinny być zapamiętywane i odtwarzane przy ponownym uruchomieniu platformy. Moduł operacyjny powinien posiadać dwa przełączalne tryby pracy pozwalając na podgląd i edycję danych historycznych oraz podgląd i edycję danych z operacji spodziewanych w najbliższym czasie z konfigurowalnym odcinkiem czasu za który dane zostaną zaprezentowane. Moduł danych słownikowych Moduł ten powinien pozwalać na tworzenie własnych baz typów statków powietrznych, statków powietrznych, linii lotniczych, portów lotniczych. Wszystkie dane wprowadzone w moduł słownikowy powinny opierać się o standard oznaczeń IATA oraz ICAO. 49

Zarządzanie personelem operacyjnym Moduł ten powinien spełniać następujące kryteria : ograniczenia związane z prawem pracy obowiązującym, np. zapewnienie odpowiednich przerw szczególnie po zmianach nocnych, minimalna i maksymalna dopuszczalna liczba godzin pracy na jednej zmianie. zapewnienie właściwej liczby osób obsługi, zgodnie z umowami podpisanymi z liniami lotniczymi. zapewnienie odpowiedniej liczby osób z kadry kierowniczej, przebywających na lotnisku. Zbierać dane razem ze wszystkimi wymaganiami i ograniczeniami. Każdej grupie lub, jeśli to jest wymagane, pojedynczemu pracownikowi, powinien umożliwić przypisanie : a) rodzaje i liczbę zmian w miesiącu lub w tygodniu, b) maksymalną/minimalną liczbę godzin pracy na miesiąc c) typ zatrudnienia System powinien umożliwić każdej grupie przypisanie poszczególnych rejsów lub całych linii lotniczych. Każdy pracownik może należeć do kilku grup, ze względu na odpowiednie szkolenia. Optymalizować harmonogram czasu pracy, tak aby był korzystny zarówno dla pracodawcy, jak i dla pracownika, uwzględniając jego preferencje, jak np.: a) możliwość ustalenia dni wolnych, lub zmian w pewne dni, b) możliwość tych samych godzin pracy z wybranymi osobami. Wspomóc ręczne planowanie, pozwalając osobie planującej lub poszczególnym kierownikom na dokonywanie korekt. Automatycznie sygnalizować naruszenie ograniczeń oraz pozwolić na podmianę godzin przyjść i przydziałów dwóch pracowników o tych samych kwalifikacjach. Przygotować plan, który może zostać wydrukowany i przekazany każdemu pracownikowi. Moduł rampy Moduł rampy powinien pozwalać na tworzenie dokumentów GHN będących potwierdzeniem wykonania usług zgodnie z umową, oraz zawierać mechanizmy pozwalające na automatyczne importowanie listy usług z bazy umów handlingowych. Lista serwisów powinna być konfigurowalna i pozwalać na dowolną zmianę każdej z usług. Na podstawie listy usług system powinien umożliwiać tworzenie dowolnej umowy handlingowej powiązanej z linią lotniczą oraz typem statku powietrznego. Moduł ten powinien być tak skonstruowany by pozwalał na: Zarządzanie wszystkimi dokumentami przez osobę odpowiedzialną za weryfikację poprawności wykonania usług, Przypisywanie osób odpowiedzialnych za wykonanie usług przy operacji wylotowej lub przylotowej, 50