Program funkcjonalno-użytkowy (zaÅÄ cznik nr 7 do SIWZ - Biuletyn ...
Program funkcjonalno-użytkowy (zaÅÄ cznik nr 7 do SIWZ - Biuletyn ... Program funkcjonalno-użytkowy (zaÅÄ cznik nr 7 do SIWZ - Biuletyn ...
• 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, • 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 48
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, • 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 49
- Page 1 and 2: Załącznik Nr 7 do SIWZ Nazwa nada
- Page 3 and 4: pozostałych urządzeń i systemów
- Page 5 and 6: System bezpieczeństwa bagaŜu reje
- Page 7 and 8: • Odprawa poprzez Internet lub te
- Page 9 and 10: 5. Zapewnieniu zamawiającemu: - sz
- Page 11 and 12: danego komunikatu w danej linii zmi
- Page 13 and 14: serwisów pozwalających na zbudowa
- Page 15: przypisywaniem do wykonywania okre
- Page 19 and 20: Moduł operacyjny powinien posiada
- Page 21 and 22: 2. Szczegółowe właściwości fun
- Page 23 and 24: ostami zrzut, gdzie zostanie przy u
- Page 25 and 26: Współpraca z urządzeniami rentge
- Page 27 and 28: 2.2.System kontroli bezpieczeństwa
- Page 29 and 30: program treningowo-szkoleniowy uŜy
- Page 31 and 32: WYMOGI DLA URZĄDZEŃ DO KONTROLI B
- Page 33 and 34: 6. MoŜliwość pracy ciągłej urz
- Page 35 and 36: 3. Punkt kontroli bagaŜu ponadwymi
- Page 37 and 38: wszystkich podłączonych punktów
- Page 39 and 40: 29. Sieciową stację monitorująca
- Page 41 and 42: 38. Automatyczną archiwizację obr
- Page 43 and 44: 17. Monitor Minimum LCD 17” rozdz
- Page 45 and 46: − Detektory muszą być pozbawion
- Page 47 and 48: − Uzyskane obrazy nie mogą ujawn
- Page 49 and 50: 2.3. System odpraw biletowo - baga
- Page 51 and 52: (konieczne w przypadku niektórych
- Page 53 and 54: zarządzanie, diagnostykę i przewi
- Page 55 and 56: konfiguracja: zarządzanie przez pr
- Page 57 and 58: • Potwierdzenie kompatybilności
- Page 59 and 60: A. System FIDS wymagania szczegół
- Page 61 and 62: Przekątna ekranu, 19 cali o rozdzi
- Page 63 and 64: • Oprogramowanie ma zapewniać mo
- Page 65: • WLAN 802.11 a/b/g • Modem GDM
• Datę oraz czas odlotu,<br />
• Datę oraz czas odloty ze stacji wylotu,<br />
• Datę oraz czas przylotu <strong>do</strong> stacji <strong>do</strong>celowej,<br />
i mieć moŜliwość:<br />
• wyboru czasu lokalnego lub czasu UTC w maskach słuŜących <strong>do</strong> wprowadzania<br />
danych o rozkładzie rejsów,<br />
• tworzenia maski rejsu rekurencyjnego pozwalająca na wybór dni tygodnia operowania<br />
danego rejsu,<br />
• przekazania informacji o bookingu czyli planowanej liczbie pasaŜerów, informacji o<br />
numerze Gate, informacji o pozycji postojowej dla statku powietrznego.<br />
• Wizualizacji rotacji statków powietrznych na płycie lotniska w sposób graficzny za<br />
pomocą linii łączących rotujące statki powietrzne na płycie lotniska.<br />
• Wydruku danych bieŜącego wi<strong>do</strong>ku,<br />
• Publikacji email danych bieŜącego wi<strong>do</strong>ku,<br />
• Eksportu danych <strong>do</strong> schowka bieŜącego wi<strong>do</strong>ku,<br />
• Przygotowania wzorca tygodniowego operowania rejsu.<br />
Ponadto moduł powinien wykrywać moŜliwe konflikty z numerami rejsów juŜ<br />
wprowadzonymi <strong>do</strong> systemu operujących w tych samych dniach co nowe rejsy lub<br />
mieszczące się w określonym odstępie czasowym. Wszystkie tabele powinny być<br />
konfigurowalne pozwalając na wybór kolejności kolumn, sortowanie po wielu kolumnach,<br />
filtrowanie zawartości. Powinna istnieć takŜe moŜliwość publikacji danych bezpośrednio z<br />
modułu planowania rozkładu rejsów w postaci wia<strong>do</strong>mości e-mail z załączonym <strong>do</strong>kumentem<br />
prezentującym dane o rozkładzie rejsów <strong>do</strong> wybranej, konfigurowalnej listy odbiorców.<br />
Integracja z systemem przesyłającym wia<strong>do</strong>mości typu B<br />
Rozwiązanie powinno być zintegrowane ze śro<strong>do</strong>wiskiem przesyłającym wia<strong>do</strong>mości<br />
typu B pozwalając na automatyczny, ciągły import danych zawartych w depeszach róŜnego<br />
typu. Depesze przychodzące oraz wychodzące powinny być wiązane z rejsem <strong>do</strong>danym w<br />
module planowania rozkładu oraz zdeko<strong>do</strong>wane, które będą wykorzystane w innych<br />
częściach systemu. Wymagana jest z<strong>do</strong>lność zapisywania oraz interpretowania depesz typu:<br />
MVT, LDM, SLS, ASM, CPM. System ma zapewnić szybki i łatwy <strong>do</strong>stęp <strong>do</strong> kolekcji<br />
depesz kaŜdego typu w osobnym module, wraz z moŜliwością wydruku listy oraz filtracji po<br />
wybranych kolumnach takich jak: numer rejsu, kod opóźnienia, przewoźnik, czas odebrania<br />
depeszy itp. Na etapie wdroŜenia naleŜy zapewnić integracje z systemami operatora np.<br />
SITA, ARINC<br />
Moduł powinien posiadać tabele:<br />
• Kontener główny, będący zbiorem wszystkich wia<strong>do</strong>mości wysłanych na określone<br />
adresy odbiorców, gdzie lista adresów powinna być konfigurowalna na serwerze<br />
48
Change language