ZAŁĄCZNIK NR 1

Opis przedmiotu zamówienia na dostawę i wdrożenie Systemu biletu elektronicznego i

dynamicznej informacji pasażerskiej, w ramach projektów „Czysta komunikacja

publiczna – zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz

modernizacja infrastruktury towarzyszącej transportowi publicznemu - etap I” oraz

„Bezpieczny transport w Opolu”

1

Spis treści

I. Podstawowe definicje...............................................................................................3II. Wymagania dla Systemu.........................................................................................6II.1. Wymagania ogólne.............................................................................................10II.2. Wymagania stawiane Wykonawcy......................................................................12II.3. Łączność pomiędzy elementami Systemu..........................................................12II.4. Wymiana danych pomiędzy elementami Systemu, Systemami Dziedzinowymi i Systemami Zajedniowymi...............................................................14II.5. Urządzenia do wymiany danych na terenie zajezdni..........................................16II.6. System Centralny...............................................................................................17II.7. Monitorowanie Systemu, zgłaszanie i raportowanie Awarii.................................18II.8. Zasoby Zamawiającego......................................................................................20II.9. Zarządzanie użytkownikami...............................................................................25III. Oprogramowanie do projektowania rozkładów jazdy (Oprogramowanie RJ).27III.1. Wymagania dla Oprogramowania RJ..................................................................27IV. Funkcjonalności i wymagania techniczne dla Podsystemu biletu elektronicznego (Podsystem e-bilet).........................................................................32IV.1. Ogólny opis........................................................................................................32IV.2. Funkcjonalności i wymagania dla Podsystemu e-bilet.......................................33IV.3. Główne funkcje realizowane przez Podsystem e-bilet.......................................33IV.4. Raportowanie....................................................................................................35IV.5. Funkcjonalności związane z zarządzaniem, obsługą i monitorowaniem Biletomatów stacjonarnych i mobilnych oraz Urządzeń zamontowanych w autobusach................................................................................................................36IV.6. Wyposażenie autobusów...................................................................................56IV.7. Punkty Obsługi Klienta (POK) i Punkty Obsługi Sprzedaży (POS).......................67IV.8. Terminal sprzedażowy do użytku w Punktach Obsługi Sprzedaży (POS).

71IV.9. Doładowywanie Kart e-bilet i zapis Kontraktów okresowych przez Internet – POP............................................................................................................73IV.10. Kontrola biletów (czytniki kontrolerskie).........................................................79V. Podsystem dynamicznej informacji pasażerskiej (Podsystem DIP) w czasie rzeczywistym i zarządzania ruchem obejmujący geolokalizację autobusów..............83V.1. Elementy Podsystemu DIP..................................................................................83V.2. Opis funkcjonalności i działania Oprogramowania..............................................83V.3. Tablice DIP..........................................................................................................89VI. Stanowiska do obsługi Systemu.........................................................................101VI.1. Informacje ogólne............................................................................................101VI.2. Wykaz Stanowisk do obsługi Systemu i Urządzeń...........................................102VI.3. Licencje...........................................................................................................103Załącznik nr 1 do OPZ. Obowiązująca taryfa...........................................................106Załącznik nr 2 do OPZ. Lista autobusów z wyposażeniem.......................................108Załącznik nr 3 do OPZ. Parametry techniczne poszczególnych Stanowisk do obsługi Systemu......................................................................................................117Załącznik nr 4 do OPZ. Wymagania techniczne wobec Serwerowni........................129

2

Załącznik nr 5 do OPZ. Przewidywany harmonogram wymiany autobusów............142Załącznik nr 6 do OPZ. Etapy wykonywania prac....................................................143Załącznik nr 7 do OPZ. Dokumentacja projektowa i powykonawcza.......................144

I. Podstawowe definicje

1. System – zintegrowany zespół Oprogramowania oraz Infrastruktury technicznej, w tym Urządzeń, szczegółowo opisany w OPZ, na który składają się w szczególności:1) System Centralny, umożliwiający obsługę informatyczną Systemu, 2) Podsystem biletu elektronicznego (zwany dalej Podsystem e-bilet) w

komunikacji miejskiej obejmujący również Internetowy Portal Obsługi Pasażerów (POP),

3) Podsystem dynamicznej informacji pasażerskiej (Podsystem DIP) w czasie rzeczywistym zawierający również Moduły geolokalizacji autobusów, dyspozytorski oraz zarządzania ruchem,

4) Oprogramowanie do projektowania rozkładów jazdy (Oprogramowanie RJ/Podsystem RJ),

5) Stanowiska do obsługi Systemu.2. System Centralny – urządzenia wraz z Oprogramowaniem Serwerowni,

przeznaczone do obsługi całego Systemu, w skład którego wchodzą serwery: aplikacji, baz danych, serwer uwierzytelniania kart, serwer WWW. Serwery są rozumiane jako sprzęt i Oprogramowanie.

3. Podsystem e-bilet obejmuje funkcjonalności sprzedaży biletów tradycyjnych i biletów elektronicznych. Stanowi część Systemu Centralnego obejmującą Oprogramowanie do obsługi założonych funkcjonalności kart e-biletu oraz odpowiednie Oprogramowanie i wyposażenie dla Punktów Obsługi Sprzedaży (POS) i Punktów Obsługi Klienta (POK). Sieć sprzedaży tworzyć będą stacjonarne i mobilne automaty biletowe, tradycyjne POS wyposażone w terminale sprzedażowe, punkty personalizacji i sprzedaży biletów POK, POP obejmujący sklep WWW w wersji standardowej i mobilnej. Autobusy będą wyposażone w dwufunkcyjne kasowniki do obsługi biletów w formie elektronicznej i papierowej (tradycyjnej) oraz Biletomaty. Urządzenia te będą zarządzane przez sterownik e-biletu, połączone w sieć w każdym autobusie tworzyć będą Moduły Pokładowe Systemu. Podsystem e-bilet obejmować będzie również Moduł kontroli biletów i odpowiednie urządzenia do kontroli biletów.

4. Podsystem Dynamicznej Informacji Pasażerskiej (Podsystem DIP), będzie udostępniać funkcjonalności prezentacji dynamicznej informacji pasażerskiej na elektronicznych Tablicach DIP oraz w formie wirtualnego monitora dostępnego w POP. Ponadto, będzie zawierał funkcję alarmu (tzw. panic button) i funkcje dyspozytorskie - będzie prezentował poszerzone informacje o ruchu autobusów na mapie i w formie raportów dla zarządzania flotą autobusów. Będzie on wyposażony w odpowiednie Oprogramowanie do prognozowania czasów przyjazdu autobusów na przystanki.

3

5. Podsystem RJ (Oprogramowanie RJ) – służyć będzie do projektowania i optymalizacji rozkładów jazdy szczegółowo opisane w Rozdziale III OPZ. Podsystem RJ może nie stanowić integralnej części Systemu Centralnego, jednak będzie współpracował z Systemem Centralnym, zapewniając z nim stałą (online) i automatyczną wymianę danych (w tym eksport-import danych).

6. Internetowy Portal Obsługi Pasażerów (POP) – w wersji standardowej i mobilnej, jest elementem Podsystemu e-bilet. POP wraz z sklepem WWW będzie zintegrowany z Systemem Centralnym i będzie udostępniać następujące funkcjonalności:a) obsługę wniosków o wydanie karty e-bilet,b) zakładanie i obsługę indywidualnych kont pasażerów,c) sprawdzanie stanu konta lub karty e-bilet wraz z historią transakcji, d) sprzedaż biletów okresowych w formie elektronicznej i Doładowań e-

portmonetki,e) informację o lokalizacji i zakresie obsługi poszczególnych POK i POS,f) dynamiczną informację pasażerską (wirtualny monitor), g) rozkłady jazdy i wyszukiwarkę połączeń.Dodatkowo POP będzie pełnił funkcję informacyjną dla całego Systemu (taryfy, regulaminy, ogłoszenia, instrukcje dotyczące korzystania z Systemu).

7. Operator – MZK Sp. z o.o. w Opolu pełniący rolę operatora publicznego transportu zbiorowego świadczącego usługi przewozowe w zakresie lokalnego transportu zbiorowego na terenie miasta Opola oraz gmin ościennych, z którymi Miasto Opole zawarło stosowne porozumienie (Aglomeracja Opolska).

8. Zamawiający – Urząd Miasta Opola, który pełni rolę Organizatora publicznego transportu zbiorowego na terenie miasta Opola.

9. Doładowanie – zasilenie Elektronicznej Portmonetki (e-portmonetka) na karcie e-biletu w środki umożliwiające dokonywanie zakupu biletów elektronicznych.

10. Kontrakt okresowy – bilet okresowy w postaci elektronicznej.11. Punkt Obsługi Klienta (POK) – element sieci sprzedaży biletów, punkt

kasowy prowadzony przez Operatora wykonujący również usługi personalizacji kart e-biletu.

12. Punkt Obsługi Sprzedaży (POS) – zewnętrzne punkty sprzedaży biletów, Doładowań kart e-biletu oraz Kontraktów okresowych.

13. Urządzenie doładowujące (UD) – sprzęt wykorzystywany w POS do sprzedaży Doładowań kart e-biletu oraz Kontraktów okresowych.

14. Autokomputer – Urządzenie sterujące Systemami Pokładowymi Autobusu. 15. Sterownik e-bilet – Urządzenie pokładowe sterujące pracą Modułów

Pokładowych Systemu. 16. Biletomat mobilny (automat biletowy) – Urządzenie montowane w

autobusach umożliwiające pasażerom zakup Biletów Papierowych zgodnie z taryfą opłat i komunikujące się z Systemem Centralnym.

4

17. Kasownik – Urządzenie umożliwiające pasażerom wnoszenie opłat za przejazd przy wykorzystaniu e-portmonetki oraz Biletów Papierowych, wgrywanie Kontraktów okresowych oraz sprawdzanie statusu biletu elektronicznego.

18. Biletomat stacjonarny (stacjonarny automat biletowy) – Urządzenie instalowane na przystanku komunikacji miejskiej lub w innym miejscu wskazanym przez Zamawiającego. Urządzenie techniczne umożliwiające pasażerom m.in. samodzielny zakup Biletów Papierowych, Kontraktów okresowych oraz Doładowań e-portmonetki, wgrywanie Kontraktów okresowych, a także sprawdzanie statusu Kart e-bilet.

19. Karta e-biletu – karta elektroniczna MIFARE DESFire w standardzie ISO/IEC 14443 typ A i B opisana w pkt. IV.5.3 lub równoważnym.

20. Elektroniczna Portmonetka (e-portmonetka) – środki finansowe zapisywane na Karcie e-bilet pod postacią punktów (gdzie np. 1 punkt = 1 zł, a 0,01 punktu = 1 gr) przeznaczone na zakup biletów elektronicznych (np. jednorazowych / czasowych) w Systemie.

21. Bilety Papierowe – bilety jednorazowe w postaci papierowej, drukowane z Biletomatów oraz dystrybuowane przez sieć sprzedaży, zgodne z taryfą opłat.

22. Tablica DIP – tablica dynamicznej informacji pasażerskiej.23. Serwerownia – centralny punkt Systemu, miejsce zainstalowania i

uruchomienia Systemu Centralnego, jak i wszystkich serwerów, Urządzeń stanowiących centralny punkt sieci szkieletowej i rozległej Systemu, Urządzeń backupu oraz Oprogramowania i innych urządzeń stanowiących System Centralny.

24. OPZ – niniejszy dokument pn. Opis przedmiotu zamówienia na dostawę i uruchomienie Systemu biletu elektronicznego i dynamicznej informacji pasażerskiej, w ramach projektów „Czysta komunikacja publiczna – zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz modernizacja infrastruktury towarzyszącej transportowi publicznemu - etap I” oraz „Bezpieczny transport w Opolu”, wraz z załącznikami.

25. Oprogramowanie Dedykowane – Oprogramowanie stworzone przez Wykonawcę (lub jego podwykonawców) i dostarczone specjalnie na potrzeby realizacji umowy, dostosowane do wymagań Zamawiającego opisanych w OPZ i w załącznikach do umowy .

26. Oprogramowanie Standardowe – Oprogramowanie osób trzecich, do których Wykonawca jest uprawniony udzielić licencji na warunkach określonych w umowie np.: systemy operacyjne, silniki baz danych, sterowniki, serwery WWW, serwery aplikacyjne itp.

27. Sieć GSM – pakietowa łączność z siecią komórkową realizowana m.in w technologiach GSM/GPRS/UMTS/LTE lub nowszych, dobranych w zależności od wymagań dotyczących przepływności i jakości połączenia dla konkretnych rozwiązań.

28. Moduł – element Podsystemu realizujący określoną część funkcjonalności Podsystemu.

29. Lokalizacja Zdalna – POK, POS, siedziba Operatora, siedziba Zamawiającego.

5

30. Moduł Pokładowy Systemu – dostarczone i zainstalowane w autobusach w ramach niniejszego zamówienia elementy Systemu stanowiące wyposażanie pokładowe autobusu takie jak: Kasowniki, Biletomaty mobilne, Sterowniki e-biletu oraz inne Urządzenia i wyposażenie, połączone ze sobą na pokładzie autobusu siecią informatyczną tworzącą spójny system, komunikujące się z Systemem Centralnym online za pomocą sieci GSM lub Wi-Fi.

31. System Pokładowy Autobusu – elektroniczne systemy pasażerskie autobusu i wspomagające pracę kierowcy, takie jak: informacja pasażerska, monitoring, tablice kierunkowe, Autokomputer, urządzenia: GPS, GSM, Wi-Fi, itp., stanowiące wyposażenie autobusu, dostarczone poza niniejszym zamówieniem, którego centralnym elementem jest Autokomputer autobusu.

32. Systemy Zajezdniowe – systemy pracujące u Operatora współpracujące z Systemami Pokładowymi Autobusu wymienione w punkcie II.8.2. OPZ.

33. Systemy Dziedzinowe – systemy użytkowane u Operatora m.in. Finanse-Księgowość, Kadry-Płace, Windykacja, Stacja Paliw, Gospodarka Magazynowa, portal www.mzkopole.pl (wraz z wyszukiwarką połączeń).

6

II. Wymagania dla Systemu

Wdrażany System ma na celu podniesienie jakości życia mieszkańców Opola oraz Aglomeracji Opolskiej poprzez wprowadzenie nowoczesnego nośnika biletów komunikacji zbiorowej, jakim jest bilet elektroniczny, nowoczesnego Systemu zarządzania flotą autobusów opartego o geolokalizację oraz Podsystemu DIP w czasie rzeczywistym. W ujęciu całościowym system elektronicznej obsługi pasażera będzie się składał z:

1) Systemu Centralnego wraz z Oprogramowaniem umożliwiającym jego obsługę informatyczną,

2) 50 000 Kart e-bilet, 3) sieci sprzedaży, którą tworzyć będą Biletomaty stacjonarne i mobilne,

tradycyjne punkty sprzedaży wyposażone w terminale sprzedażowe (POS) oraz 3 POK, sklep WWW (POP) w wersji standardowej oraz mobilnej,

4) Kasowników (dwusystemowych), które umożliwiają skasowanie Biletów papierowych, jak i zapisanych na Karcie e-bilet wraz z niezbędnymi urządzeniami pokładowymi (Moduły Pokładowe Systemu),

5) Podsystemu e-bilet obejmującego również Moduł kontroli biletów, 6) Podsystemu DIP,7) Podsystemu RJ.

System CentralnyW ramach projektu zakupiony zostanie system informatyczny przeznaczony do obsługi całego wdrażanego Systemu, zwany dalej Systemem Centralnym. System Centralny powinien być rozwiązaniem modularnym (lub składającym się ze zintegrowanych ze sobą podsystemów), pozwalającym na obsługę funkcjonalności oczekiwanych w projekcie. Dodatkowo powinien być rozwiązaniem skalowalnym pozwalającym na jego rozbudowę w zależności zapotrzebowania w dowolnym momencie trwania projektu, działającym co najmniej w układzie „Klient-Serwer”. Pod względem funkcjonalnym System Centralny będzie umożliwiał między innymi:

1) prowadzenie sprzedaży Biletów Papierowych oraz biletów zapisanych na Karcie e-bilet (biletów jednorazowych w formie np. elektronicznej portmonetki oraz Kontraktów okresowych),

2) pełną obsługę pasażerów, w tym: a) przyjmowanie wniosków i wydawanie Kart e-bilet, b) personalizację graficzną i elektroniczną nośników elektronicznych – Kart

e-bilet,c) rejestrację wszystkich operacji związanych z obiegiem karty w systemie

(tworzenie, blokowanie, odblokowanie, wydawanie duplikatów, zakup biletów),

7

d) obsługę reklamacji,3) zarządzanie i nadzór nad siecią sprzedaży składającą się z:

a) 10 Biletomatów stacjonarnych,b) 95 Biletomatów mobilnych,c) 30 punktów sprzedaży (POS), d) 3 punktów obsługi klienta (POK)e) sklepu WWW (POP) w wersji standardowej oraz mobilnej.

4) zarządzanie i nadzór nad siecią Kasowników zainstalowanych w autobusach,

5) zarządzanie stroną WWW Operatora (mzkopole.pl wraz z wyszukiwarką),6) gromadzenie danych sprzedażowych z każdego kanału sprzedaży, w celu

rozliczania i raportowania sprzedaży,

7) prowadzenie, nadzór oraz rozliczenie kontroli biletów za pomocą czytników kontrolerskich,

8) obsługę Podsystemu DIP (systemu do zarządzania i prezentacji informacji pasażerskiej, w tym predykcji czasu przyjazdu na podstawie informacji o lokalizacji pochodzących z autobusów, gromadzenie danych),

9) System Centralny zostanie wyposażony w API umożliwiające bieżące udostępnianie informacji o lokalizacji autobusów zewnętrznym systemom dynamicznej informacji pasażerskich (np. kiedyPrzyjedzie.pl, jakdojade.pl), w zakresie co najmniej: informacji o aktualnym położeniu poszczególnych pojazdów (ze wskazaniem konkretnych numerów bocznych) oraz numeru aktualnie wykonywanego przez pojazd zadania przewozowego.

Podsystem e-biletW projekcie przyjęto, iż Podsystem e-bilet zostanie oparty o karty elektroniczne w standardzie MIFARE Desfire (zwane dalej Kartą e-bilet) w liczbie 50 tys. sztuk. W Podsystemie e-bilet będą funkcjonowały Karty e-bilet imienne i na okaziciela. Każda Karta e-bilet będzie aktywowana elektronicznie w Systemie. Karty e-bilet imienne będą personalizowane elektronicznie, jak i graficznie poprzez nadruk imienia i nazwiska pasażera oraz jego zdjęcia. Pierwsza Karta e-bilet będzie wydawana pasażerowi bezpłatnie. Kolejne Karty e-bilet, w tym duplikaty wydawane będą odpłatnie. Karty e-bilet stanowić będą nośnik biletu elektronicznego: Kontraktu okresowego (miesięczne, dekadowe, trzymiesięczne, półroczne) i e-portmonetki. Biletomaty stacjonarne i mobilneW ramach wdrożenia projektu zakupionych zostanie 10 sztuk Biletomatów stacjonarnych. Zostaną one zainstalowane w lokalizacjach o największym natężeniu potoków pasażerskich, gdzie często mógłby występować brak możliwości zakupu biletu w jednym Biletomacie mobilnym zainstalowanym w autobusie przez wszystkich wsiadających pasażerów. W celu zapewnienia pełnej dostępności do biletów, w ramach Systemu, nabytych zostanie również 95 sztuk Biletomatów mobilnych, które zostaną zainstalowane we wszystkich

8

pojazdach MZK Sp. z o. o. w Opolu, po jednym Urządzeniu w każdym autobusie. Od strony funkcjonalnej obydwa typy Urządzeń zapewnią możliwość zakupu Biletów Papierowych, jak i na nośnikach elektronicznych, w tym kodowanie biletów zakupionych w sklepie WWW. Biletomaty stacjonarne i mobilne będą wyposażone w wandaloodporną obudowę, odporną na korozję i czynniki atmosferyczne, ekran dotykowy, min. 1 drukarkę termiczną oraz moduł transmisji danych zapewniający możliwość nadzoru przez System Centralny nad ich funkcjonowaniem. Zarządzanie Biletomatami stacjonarnymi i mobilnymi, będzie odbywać się zdalnie poprzez System Centralny umożliwiający nadzór oraz realizację serwisu Urządzeń i utrzymania Oprogramowania. Biletomaty stacjonarne zapewnią możliwość obsługi płatności za pomocą bilonu i banknotów z funkcją wydawania reszty oraz za pomocą płatniczych kart stykowych i zbliżeniowych, z możliwością wprowadzania kodu PIN. W Biletomatach mobilnych dostępna będzie wyłącznie funkcja płatności bezgotówkowej.

Moduły Pokładowe SystemuW celu zapewnienia możliwości walidacji zakupionych biletów w formie elektronicznej we wszystkich autobusach wchodzących w skład Taboru zostaną zainstalowane niezbędne Moduły Pokładowe Systemu. W skład Modułów Pokładowych Systemu wejdą, oprócz wyżej wymienionych Biletomatów mobilnych, Kasowniki wraz ze Sterownikiem e-bilet, jeśli System będzie tego wymagał i nie będzie możliwe wykorzystanie obecnie zainstalowanych Autokomputerów. Pod względem funkcjonalnym kasowniki będą umożliwiały:

1) kasowanie biletów w formie papierowej,2) kasowanie biletów w formie elektronicznej,3) sprawdzanie stanu Karty e-bilet i zgromadzonych na karcie środków, 4) zakodowanie biletów zakupionych w sklepie WWW.

Urządzenia będą podłączone do Systemu Centralnego za pomocą Sterownika e-bilet lub Autokomputera. Wymiana danych odbywać się będzie za pomocą modułu transmisji danych GSM i Wi-Fi na zajezdni. System Centralny zapewni nadzór oraz realizację serwisu Urządzeń i utrzymania Oprogramowania. Urządzenia Doładowujące (UD)Tradycyjne punkty sprzedaży (POS), takie jak kioski czy saloniki prasowe zostaną wyposażone w Urządzenia Doładowujące (UD). W ramach projektu zostanie zakupionych 30 sztuk takich urządzeń. UD jest ergonomicznym urządzeniem przeznaczonym do sprzedaży biletów w formie elektronicznej oraz ich kodowania na karcie e-bilet, wyposażonym w drukarkę termiczną. Oprogramowanie UD musi pozwalać na

9

bezpieczną sprzedaż biletów oraz raportowanie sprzedaży. UD wyposażony jest w ekran oraz przyciski funkcyjne pozwalające na jego sprawną obsługę. Transmisję danych zapewnia moduł transmisji danych. UD będą zarządzane zdalnie poprzez System Centralny umożliwiający nadzór oraz realizację serwisu Urządzeń i utrzymania Oprogramowania. Sklep WWW (POP)W ramach projektu zostanie uruchomiony dedykowany do obsługi Systemu Portal Obsługi Pasażera (POP). Strona wraz z sklepem WWW będzie zintegrowana z Systemem Centralnym i będzie udostępniać następującą funkcjonalność:

1) obsługę wniosków o wydanie Karty e-bilet,2) zakładanie i obsługę indywidualnych kont pasażerów,3) sprawdzanie stanu konta/ Karty e-bilet wraz z historią transakcji, 4) sprzedaż biletów w formie elektronicznej, w tym Doładowanie e-

portmonetki5) lokalizację poszczególnych punktów sprzedaży (POK i POS),6) dynamiczną informację pasażerską.

Dodatkowo strona WWW będzie pełniła funkcję informacyjną dla całego Systemu (taryfy, regulaminy ogłoszenia).Moduł kontroli biletów (czytniki kontrolerskie)W ramach realizacji Zadania zostanie zakupionych 15 szt. urządzeń do kontroli biletów, zwanych dalej czytnikami kontrolerskimi. Czytniki kontrolerskie to przenośnie urządzenia wielofunkcyjne odporne na wstrząsy, upadek z wysokości oraz warunki atmosferyczne. Obsługę zapewnia ekran dotykowy i klawisze funkcyjne. Wyposażone są w moduł transmisji danych, moduł lokalizacji GPS, skaner kodów 2D oraz Oprogramowanie pozwalające na realizację co najmniej:

1) kontroli biletów w formie elektronicznej (obsługa białych i/lub czarnych list),

2) kontroli biletów z kodem 2D (aplikacje mobilne oraz bilety w formie papierowej),

3) kodowanie biletów elektronicznych zakupionych w sklepie WWW na Karcie e-bilet,

4) zbieranie danych o zrealizowanych kontrolach.Urządzenia będą zarządzane zdalnie poprzez System Centralny umożliwiający nadzór oraz realizację serwisu urządzeń i utrzymania Oprogramowania. Wraz z czytnikami zostaną dostarczone również 2 stanowiska do obsługi kontrolerów. Stanowiska będą podłączone do Systemu Centralnego i będą umożliwiały realizację następujących funkcji:

1) zbieranie danych o zrealizowanych kontrolach; 2) przekazywanie danych o zmianach taryfowych oraz innych informacji, np. o

zablokowanych Kartach e-bilet;3) rozliczenia pracy poszczególnych kontrolerów.

Stanowiska zostaną zamontowane w biurach MZK Sp. z o. o. w Opolu. Tablice dynamicznej informacji pasażerskiej (Tablice DIP)

10

W ramach projektu zostaną zakupione 44 sztuki Tablic DIP stanowiących element Systemu. Tablice DIP te zostaną zamontowane na przystankach w miejscach o największym natężeniu potoków pasażerskich, na wysokości minimum 2,7 m od powierzchni chodnika. Tablice DIP muszą być modułowe, wykonane w technologii LED, wandaloodporne, odporne na korozję i czynniki atmosferyczne.

1) Tablice DIP będą współpracowały z Podsystemem DIP. Główne funkcjonalności Tablic DIP to:

2) Tablice DIP dwustronne w komplecie z dedykowanymi słupami (całość ocynkowana i trwale zabezpieczona przed korozją),

3) 6 wierszy + 1 wiersz (dolny) na komunikaty specjalne, 4) statyczne pole opisowe w górnej części Tablicy DIP, zawierające informacje

o nazwie przystanku, logo miasta i programu unijnego i nagłówki kolumn (nazwa przystanku i nagłówki kolumn podświetlone w technologii LED),

5) wyświetlane prognozy powinny być rozmieszczone na ekranie Tablicy DIP w trzech kolumnach (kolumna z oznaczeniem linii, kolumna z oznaczeniem kierunku, kolumna z czasem pozostałym do odjazdu),

6) dodatkową informacją wyświetlaną na Tablicy DIP powinien być aktualny czas (zegar elektroniczny),

7) zintegrowane z modułem przewidywania czasów przyjazdu autobusów aktualnie wykorzystywanym w mieście Opolu,

8) wyposażone w moduł transmisji danych,9) Tablice DIP wyposażone w kamerę kolorową, która obserwuje i rejestruje

wszystkie działania przed Tablicą DIP (z obu stron), a materiał (audio + video) z podglądu jest rejestrowany na dysku twardym danej Tablicy DIP i archiwizowany przez minimum 10 dni,

10) Tablice DIP wyposażone w syntezator mowy dla niepełnosprawnych, umożliwiający po naciśnięciu przycisku znajdującego się na słupie, odczytanie wszystkich wyświetlanych prognoz odjazdów autobusów.

Pod względem oprogramowania Tablice DIP są elementem Podsystemu DIP i mają być dostarczone wraz z nim, zawierającym również funkcjonalności: przewidywania czasu przyjazdu na podstawie informacji o lokalizacji pochodzących z systemów autobusów, gromadzenia danych i raportowania oraz generowania syntetycznego i analitycznego informacji dotyczących czasów kursowania autobusów, średnich czasów przejazdów, obsługi przystanków, punktualności wraz z odpowiednim modułem dyspozytorskim wspierającym pracę dyspozytora, nadzór nad punktualnością i realizacją obsługi systemu komunikacyjnego, wyposażonym w alarmy istotnych zdarzeń w systemie komunikacyjnym. System ten powinien być łatwy w obsłudze i zostać zintegrowany (współpracować automatycznie wymieniać dane) z Oprogramowaniem do budowy rozkładów jazdy oraz Systemami Pokładowymi Autobusów. Oprogramowanie do optymalizacji rozkładów jazdy (Oprogramowanie RJ/Podsystem RJ)Oprogramowanie RJ musi umożliwiać eksport do innych podsystemów w otwartych formatach danych. Funkcjonalność Oprogramowania RJ będzie

11

obejmować projektowanie linii, synchronizowanie odjazdów, łączenie zadań w brygady, analizy eksploatacyjne, drukowanie rozkładów na przystanki, w tym umożliwiać będzie projektowanie rozkładów jazdy, co najmniej poprzez:

1) tworzenie schematów sieci - mapy,2) tworzenie rozkładów w trybie automatycznym oraz ręcznym (dla

wszystkich typów dni, możliwość łączenia linii - kursów w brygady, synchronizacja kursów),

3) generowanie danych o liniach (długości linii, długości tras, brygadach, kursach, wozokilometrach, wozogodzinach, w podziale na gminy, ilości zatrzymań w podziale na zarządców dróg, itp.),

4) generowanie danych do: planowania i rozliczania pracy kierowców, strony internetowej mzkopole.pl, dla Autokomputerów i Podsystemu e-bilet, internetowych portali informacji pasażerskiej, m.in. kiedyprzyjedzie.pl, jakdojadę.pl, wyszukiwarki internetowej, Google Maps, itp.,

5) raportowanie, wydruki, zestawienia (rozkłady dla kierowców, rozkłady na przystanki, rozkłady tabelaryczne, rozkłady tabelaryczne dla uzyskania zaświadczeń (UM Opole), zatrzymania na przystankach dla właściwych zarządców dróg (opłaty MZD, ZDW) itp.

System będzie wykorzystywany wspólnie przez Zamawiającego i Operatora.II.1. Wymagania ogólne.1) System musi być nowoczesnym systemem informatycznym, tzn.

zintegrowanym, dającym możliwości rozbudowy, niezawodnym, bezpiecznym. System musi spełniać wszystkie wymagania obowiązującej ustawy o ochronie danych osobowych, a zatem musi zapewniać poufność, integralność, rozliczalność, autentyczność i niezawodność.

2) Oprogramowanie musi pozwalać na poprawne funkcjonowanie i zarządzanie Systemem.

3) System musi mieć modułową strukturę w celu łatwej jego rozbudowy o kolejne funkcje nie objęte niniejszym zamówieniem.

4) Dostarczony System musi umożliwić tworzenie raportów przez użytkownika Systemu zgodnie z formatami i zakresem danych opisanych dalej i uzgodnionym przez Strony w trakcie wdrożenia Systemu.

5) System we wszystkich jego elementach musi być polskojęzyczny.6) Dostarczone Urządzenia i Oprogramowanie muszą być dopuszczone do obrotu

towarowego w UE i muszą być fabrycznie nowe, tj. wyprodukowane do 6 miesięcy od daty podpisania umowy i nieużywane.

7) Wykonawca musi przedłożyć Zamawiającemu odpowiednie certyfikaty (oznaczenie CE dla urządzeń oraz/lub zgodność PN oraz/lub aprobata techniczna dla materiałów zastosowanych do wykonania zadania). Wykonawca musi przedłożyć deklarację zgodności z obowiązującymi normami bezpieczeństwa zgodnie z obowiązującymi przepisami na dostarczony sprzęt komputerowy, a także dla pozostałych urządzeń. Wszelkiego rodzaju certyfikaty, aprobaty techniczne, deklaracje zgodności dotyczące

12

poszczególnych elementów Systemu należy przedłożyć Zamawiającemu w trakcie wykonania zamówienia i dołączyć jako załącznik do właściwego protokołu odbioru.

8) Przy dostawie sprzętu komputerowego z systemem operacyjnym Wykonawca musi złożyć oświadczenie o kompatybilności tego sprzętu z dostarczonym Systemem.

9) Wszelkie Oprogramowanie Standardowe Wykonawca zobowiązuje się dostarczyć Zamawiającemu w oryginalnych opakowaniach producenta, z dołączoną licencją, nośnikami i pełną dokumentacją.

10) Wykonawca zobowiązuje się zapewnić, że licencje Oprogramowania dostarczone w ramach realizacji niniejszej umowy przez Wykonawcę, obejmować będą zakres uprawnień określony w § 7 umowy. Opłaty związane z niezbędnym serwisem, utrzymaniem, aktualizacją lub obsługą takiego Oprogramowania w okresie obowiązywania umowy obciążają Wykonawcę i zostały uwzględnione w cenie oferty.

11) Wykonawca zobowiązany jest do nieodpłatnego udzielania wyjaśnień odnośnie budowy oraz zasad funkcjonowania Systemu w zakresie niezbędnym do wykonywania przez Zamawiającego uprawnień z udzielonej licencji.

12) Instrukcje obsługi oraz karty gwarancyjne do wszystkich urządzeń dostarczonych w ramach umowy Wykonawca przekaże Zamawiającemu wraz z dostawą. Dokumenty winny być sporządzone w języku polskim.

13) Wykonawca zdeponuje kody źródłowe Oprogramowania Systemu zgodnie z warunkami określonymi w Załączniku nr 7 do OPZ Dokumentacja projektowa i powykonawcza.

14) Wszystkie parametry Systemu podane w dalszych rozdziałach OPZ są minimalnymi niezbędnymi do spełnienia wymogów Specyfikacji Istotnych Warunków Zamówienia (SIWZ), za wyjątkiem tych, gdzie zostało to podane inaczej w opisach szczegółowych.

15) W ramach realizacji zmówienia wymagane jest wykonanie wszystkich czynności oraz dostarczenie wszelkich Urządzeń i innych elementów Systemu zapewniających prawidłowe i zgodne z wymaganiami Zamawiającego działanie dostarczonego Systemu, nawet jeśli nie zostało to wyspecyfikowane w ofercie.

16) Przed wdrożeniem Systemu wymagane jest przygotowanie projektu Systemu. Projekt Systemu, projekty interfejsów użytkowników podlegają zatwierdzeniu, tj. będą przedkładane do zatwierdzenia przez Zamawiającego.

17) Każde Urządzenie dostarczane w ramach niniejszego zadania musi posiadać stosowne oznakowanie właściwego programu unijnego (treść i rozmiar do uzgodnienia z Zamawiającym).

II.2. Wymagania stawiane Wykonawcy.1) Wykonawca jest odpowiedzialny za jakość, zgodność z warunkami

technicznymi i jakościowymi opisanymi dla przedmiotu zamówienia, dla dostarczonego w ramach realizacji umowy Oprogramowania i Urządzeń.

2) Wymagana jest należyta staranność przy realizacji zobowiązań umowy.

13

3) Ustalenia i decyzje dotyczące wykonania zamówienia uzgadniane będą przez Zamawiającego z ustanowionym przedstawicielem Wykonawcy.

4) Wykonawca zobowiązany jest do sporządzenia Harmonogramu i procedur postępowania przy wdrażaniu dostarczonego Systemu oraz wskazania osób - przedstawicieli Wykonawcy, telefonów kontaktowych, numerów fax oraz innych ustaleń niezbędnych dla sprawnego i terminowego wykonania zamówienia.

5) Wykonawca ponosi pełną odpowiedzialność za wszelkie szkody powstałe podczas wykonywania przedmiotu zamówienia.

6) Wykonawca w ofercie zobowiązany jest uwzględnić wszelkie koszty związane z dostawą wszystkich niezbędnych urządzeń do miejsca instalacji, montażu, pełnym uruchomieniem Systemu, szkoleniem użytkowników Systemu Po stronie Wykonawcy leży uzyskanie wszelkich wymaganych zezwoleń, pozwoleń na budowę i wszelkiej związanej z nimi dokumentacji.

7) Zamawiający bezwzględnie wymaga, aby do momentu ostatecznego uruchomienia dostarczonego Systemu, działały wszystkie obecnie zamontowane Urządzenia. Wyklucza się sytuację, w której na potrzeby realizacji prac przez Wykonawcę konieczna będzie obsługa linii komunikacyjnych autobusami bez działających urządzeń lub wystąpi brak obecnej funkcjonalności innych urządzeń (z wyjątkiem wcześniej uzgodnionych przez Strony), trwałym lub czasowym zatrzymaniem albo ograniczeniem funkcjonalności obecnego Systemu (z wyjątkiem uzgodnionych wcześniej sytuacji).

8) Wykonawca zobowiązany jest do przeszkolenia pracowników wskazanych przez Zamawiającego w ramach obsługi Systemu oraz Urządzeń z nim powiązanych.

II.3. Łączność pomiędzy elementami Systemu.II.3.1. Informacje ogólne.Łączność pomiędzy każdym z elementów Systemu jest podstawowym warunkiem funkcjonowania całości Systemu i Wykonawca musi zadbać przede wszystkim o:1) zapewnienie bezpiecznej komunikacji pomiędzy Systemem Centralnym, a

Urządzeniami wykorzystującymi łączność w sieci komórkowej montowanymi w: a) autobusach, b) Tablicach DIP, c) w Biletomatach stacjonarnych,d) POS,e) POK;

2) zapewnienie bezpiecznej komunikacji pomiędzy Systemem Centralnym, a siecią Zamawiającego i Operatora;

3) zapewnienie bezpiecznego dostępu do właściwych danych przez stronę internetową POP dla klientów – pasażerów Operatora.

Szczegółowe wymagania techniczne i funkcjonalne Urządzeń łączności podane są w odnośnych rozdziałach niniejszego dokumentu.

14

II.3.2. Łącza do Internetu.1) Operator zapewni stałe łącza do sieci Internet dla siedziby Operatora i POK, w

których pracować będą Urządzenia lub Stanowiska do obsługi Systemu.2) Zamawiający zapewni stałe łączą do sieci Internet dla siedziby Zamawiającego.3) Serwerownia dla Systemu Centralnego zostanie zlokalizowana w siedzibie

wskazanej przez Operatora , który zapewni stałe łącze o przepustowości minimum 50 Mb/s.

4) Pozostałe Lokalizacje Zdalne i Urządzenia będą korzystać z sieci GSM.5) Operator pokryje koszty związane z dostępem do Internetu i podpisze

niezbędne umowyz dostawcami.

II.3.3. Łączność przez sieć GSM.1) Wymiana danych w trybie online pomiędzy Systemem Centralnym, a

elementami Systemu z dostępem mobilnym, ze względu na bezpieczeństwo danych musi się odbywać w prywatnym APN (Access Point Name – nazwa punktu dostępowego), w sieci GSM w technologii zapewniającej sprawną wymianę danych w Systemie, zgodnie z wymaganiami Zamawiającego w sieci dowolnego operatora telekomunikacyjnego działającego na terenie Polski.

2) Nazwa prywatnego APN powinna zostać ustalona z Operatorem.3) Numery kart SIM pracujące w zdefiniowanym APN powinny mieć statyczne

adresy IP z zakresu obsługiwanego przez APN. 4) Możliwość podłączenia się do prywatnego APN z dowolnego typu łącza za

pomocą oprogramowania OPENVPN i zestawienie połączenia site-2-site na routerze brzegowym w Serwerowni.

5) Serwer RADIUS kart SIM powinien zostać zlokalizowany po stronie operatora GSM.

6) Karty SIM dla Tablic DIP, autobusów, elementów Podsystemu e-Bilet zapewnia Operator poprzez podpisanie stosownej umowy z operatorem GSM. Koszty transmisji pokrywa Operator.

7) Do oferty Wykonawca załączy szacowaną wielkość transmisji danych w skali miesiąca, jak i jej koszty bazując na opłatach za przesył danych od min. jednego operatora sieci, który posiada nadajniki na terenie obsługiwanym przez MZK Sp. z o.o..

II.3.4. Łączność Wi-Fi.1) Wykonawca wybuduje sieć bezprzewodową na zajezdni w technologii

dostosowanej do ukształtowania terenu, zapewniającą pokrycie zasięgiem obszaru całej zajezdni autobusowej. Dla Zajezdni należy przewidzieć min. 2 szt. Access Point (AP – punkt dostępu) z systemem anten pozwalających na właściwe dwukierunkowe transmisje danych pomiędzy autobusami, a AP.

15

2) W ramach budowy sieci na terenie zajezdni Wykonawca dostarczy urządzenie UTM (Unified Threat Management – wielofunkcyjne zapory sieciowej ze strefą DMZ, funkcjami ochrony IPS i funkcjami antywirusa), które będzie miało za zadanie zabezpieczać wewnętrzną sieć informatyczną Operatora, w ramach które pracować będą AP.

3) AP podłączone będą do sieci Operatora i urządzeń UTM filtrujących ruch w sieci.

4) Ilość jednoczesnych połączeń dwustronnych autobus - AP, nie może być mniejsza niż 50, przy czym AP musi zapewniać pełną wymianę danych w trakcie codziennego postoju wszystkich autobusów.

5) System musi rejestrować wymianę plików z autobusów uwzględniając datę i czas.

II.3.5. Zasilanie.Operator zapewni przyłącza zasilania 230V/50Hz w zajezdni do wykorzystania przez Wykonawcę do podłączenia Urządzeń.

II.4. Wymiana danych pomiędzy elementami Systemu, Systemami Dziedzinowymi i Systemami Zajedniowymi.1) Zamawiający wymaga, aby zakres wymiany danych pomiędzy Systemem, a

Systemami Zajezdniowymi oraz Systemami Dziedzinowymi Operatora dotyczył wszystkich danych niezbędnych do prawidłowego funkcjonowania tych systemów.

2) Dane dostępne/zawarte w Systemach Dziedzinowych, niezbędne do prawidłowego funkcjonowania Systemu powinny zostać przeniesione automatycznie do Systemu (inicjalny import danych).

3) Zamawiający nie dopuszcza sytuacji, gdzie dane wymagające przekazania pomiędzy Systemem a Systemem Dziedzinowym, Systemem Zajezdniowym i/lub pomiędzy podsystemami, Modułami lub funkcjonalnościami były wprowadzane ręcznie przez operatora/użytkownika Systemu. Wymiana danych musi być automatyczna lub zautomatyzowana, określona harmonogramami lub w wymaganych przypadkach uruchamiana przez operatora z poziomu interfejsu użytkownika oraz odbywać się w okresach czasu gwarantujących aktualność danych wszystkich elementów Systemu niezbędnych do poprawnego funkcjonowania Systemu, Systemów Dziedzinowych i Systemów Zajezdniowych (w przypadku integracji).

4) Wymiana danych, o których mowa w pkt. 3, musi być objęta weryfikacją poprawności wykonania i procedurami naprawczymi.

5) Jeśli Zamawiający nie wymienił w OPZ wszystkich niezbędnych wymian danych, a są one niezbędne do prawidłowego działania Systemu, to Wykonawca ma obowiązek ich zrealizowania.

16

6) Zamawiający wymaga wewnętrznej integracji Podsystemów i Modułów uwzględniającej zasadę, że dane w Systemie powinny być wprowadzane raz, a wymiana danych pomiędzy Podsystemami i Modułami musi się odbywać automatycznie, bez konieczności ingerencji użytkownika Systemu, w zakresie wszystkich danych potrzebnych Podsystemom i Modułom, Modułom Pokładowym Systemu, Urządzeniom, itd.

7) Zamawiający wymaga ciągłej wymiany danych pomiędzy Systemem, a Systemami Dziedzinowymi tj. wykorzystanie przez System danych z Systemów Dziedzinowych Operatora oraz zwrotne przesyłanie danych z Systemu do Systemów Dziedzinowych Operatora w zakresie wszystkich niezbędnych danych, tak aby nie było konieczne ręczne wprowadzanie danych do Sytemu lub ich przenoszenie do Systemów Dziedzinowych, w sposób zapewniający spójność danych w tych Systemach.

8) Zamawiający wymaga wymiany danych online pomiędzy Modułami Pokładowymi Systemu, Urządzeniami, Lokalizacjami Zdalnymi, a w przypadku utraty łączności z Systemem Centralnym zastosowania mechanizmów pracy offline i synchronizacji danych.

9) Wymiana danych niewymagających natychmiastowego przesłania pomiędzy Systemem, a autobusami oraz synchronizacja danych przesyłanych online musi być także zapewniona przez sieć Wi-Fi w obrębie zajezdni. Wykonawca zapewni odpowiednie mechanizmy synchronizacji danych.

10) System Centralny zostanie wyposażony w API (interfejs programistyczny aplikacji) umożliwiający bieżące udostępnianie informacji o lokalizacji autobusów zewnętrznym systemom ITS i/lub systemom informacji pasażerskich (np. kiedyPrzyjedzie.pl, jakdojade.pl), w zakresie niezbędnym do ich funkcjonowania, co najmniej:

a) informacji o aktualnym położeniu poszczególnych autobusów (ze wskazaniem konkretnych numerów bocznych),

b) numer aktualnie wykonywanego przez autobus zadania przewozowego.11) W autobusach przeznaczonych do wyposażenia w ramach umowy w

Moduły Pokładowe Systemu – w których Systemy Pokładowe Autobusu wyposażone są w Autokomputer – Zamawiający zaleca zintegrować Moduły Pokładowe Systemu z Systemami Pokładowymi Autobusów. Integracja będzie polegała na zapewnieniu sterowania oraz komunikacji z Systemem Centralnym przez jedno urządzenie sterujące tj. Autokomputer za pomocą jednej karty SIM, wykorzystując urządzenie GPS autobusu, zapewniając w szczególności:a) wyłącznie jeden punkt obsługi dla kierowcy (np. logowanie, blokowanie

kasowników) dla Modułów Pokładowych Systemu oraz Systemów Pokładowych Autobusu, którym jest Autokomputer;

b) zapewnienie jednego punktu wymiany danych w autobusie: Moduł Pokładowy Systemu oraz System Pokładowy Autobusu każdego z autobusów powinny korzystać z jednego wspólnego routera brzegowego;

17

c) wymianę danych pomiędzy Systemem Centralnym, a autobusem: online poprzez sieć GSM (APN) poza zajezdnią, realizowaną z wykorzystaniem jednej karty SIM i danych z jednego urządzenia GPS. Oba ww. urządzenia mają być zarządzane przez Autokomputer, w zakresie danych niezbędnych do pełnego i właściwego funkcjonowania Systemów Pokładowych Autobusu, Modułów Pokładowych Systemu oraz Systemu Centralnego, a także wszystkich Podsystemów. Projektowane rozwiązanie musi gwarantować, w szczególności zapewnienie aktualności danych zarówno po stronie autobusu jak i Systemu;

d) przesyłanie danych za pomocą jednego routera w autobusie, na terenie zajezdni poprzez sieć Wi-Fi, automatyczne przekazywanie danych z Systemów Pokładowych Autobusów i Modułów Pokładowych Systemu do Systemów Zajezdniowych (w tym systemu PDA) oraz do Systemu Centralnego;

e) automatyczne programowanie za pomocą jednego routera w autobusie, dla Systemów Pokładowych Autobusów i Modułów Pokładowych Systemu przy wykorzystaniu modułu transmisji danych Wi-Fi (na terenie zajezdni) na podstawie danych z Podsystemów (w szczególności Podsystemu RJ i Podsystemu e-bilet);

f) nadzór online (monitorowanie) przez System nad poprawnością działania oraz nad aktualnością danych i Oprogramowania dla Modułów Pokładowych Systemu, Autobusowych Systemów Pokładowych, realizowany poprzez jedną kartę SIM w autobusie pod kontrolą Autokomputera;

g) dostęp online (poprzez sieć GSM - APN) do danych niezbędnych dla funkcjonowania Podsystemu DIP, w szczególności o położeniu autobusu, jego danych eksploatacyjnych (udostępnianych przez Autokomputer), jak i w zakresie bezpieczeństwa (przycisk antynapadowy, wgląd do kamer monitoringu pokładowego autobusu, dla wszystkich pojazdów wyposażonych w system monitoringu);

12) W przypadku braku realizacji integracji pomiędzy Systemami Zajezdniowymi a Systemem, Zamawiający nie dopuszcza sytuacji ograniczenia lub zakłócenia możliwości: a) programowania Pokładowych Systemów Autobusowych,b) pobierania danych eksploatacyjnych, z wszystkich autobusów

wyposażonych w Autokomputer i ich raportowania w zakresie funkcjonalnym (np. do programu PDA).

Ograniczenie lub zakłócenie rozumiane jest w szczególności jako:a) zmniejszenie liczby funkcjonalności realizowanych przez Systemy

Zajezdniowe, b) istotny wzrost wymaganej pracochłonności np. przez konieczność

wykonywania procedur w sposób nieautomatyczny tj. ręcznie przy udziale użytkownika Systemu,

18

c) brak przesyłania do Oprogramowania wymaganych danych we właściwym czasie,

d) brak możliwości obsługi w ww. zakresie części autobusów, które nastąpiło w wyniku uruchomienia Systemu.

Dlatego w ww. przypadkach Wykonawca zapewni wykonywanie funkcji Systemów Zajezdniowych, wymienionych w pkt II.8.2 OPZ (tabela SYSTEMY ZAJEZDNIOWE), w inny sposób np. poprzez dostarczenie oprogramowania o równoważnej funkcjonalności i zbliżonym stopniu wymaganej pracochłonności dla personelu Operatora oraz zagwarantuje ergonomiczną i komfortową obsługę Pokładowych Systemów Autobusowych, a także raportowania danych eksploatacyjnych autobusów. Wykonawca musi również zagwarantować stałe przesyłanie do Systemu niezbędnych danych, w szczególności w zakresie danych eksploatacyjnych autobusów i ich lokalizacji. Wykonawca musi zapewnić w szczególności funkcjonalności automatycznego przesyłania danych niezbędnych do właściwego funkcjonowania Pokładowych Systemów Autobusów, Podsystemu DIP, Podsystemu RJ, Podsystemu e-bilet, w tym Modułów Pokładowych Systemu oraz pozyskiwania danych eksploatacyjnych z wszystkich autobusów wyposażonych w Autokomputer, jak i ich raportowaniew zakresie funkcjonalnym (np. do programu PDA).

II.5. Urządzenia do wymiany danych na terenie zajezdni.1) Tabor Operatora usytuowany jest na terenie 1 zajezdni. 2) Do zadań Wykonawcy należeć będzie dostawa, instalacja i konfiguracja 1

kompletu urządzeń na zajezdni służących do bezprzewodowej komunikacji Wi-Fi i wymiany danych pomiędzy autobusami, a Systemem Centralnym.

3) Operator zapewni na zajezdni stałe łącze w celu transmisji danych pomiędzy Systemem Centralnym, a zajezdnią.

4) Wymagane stanowiska lub elementy infrastruktury zajezdni przeznaczonej do komunikacji z Systemem Centralnym zostaną zlokalizowane w zajezdni Operatora i Operator zapewni łącze do Internet o przepustowości minimum 20Mb/s.

5) Zamawiający zaleca, aby Wykonawca dokonał wizji lokalnej w celu zapoznania się z zakresem prac i warunkami ich wykonania.

II.6. System Centralny.W ramach zamówienia dostarczony zostanie System Centralny przeznaczony do obsługi całego wdrażanego Systemu. Powinien być on rozwiązaniem modularnym lub składającym się ze zintegrowanych ze sobą podsystemów. Dodatkowo, powinien być rozwiązaniem skalowalnym pozwalającym na jego rozbudowę w zależności od zapotrzebowania w dowolnym momencie trwania projektu działającym w układzie „Klient-Serwer” lub architekturze trójwarstwowej.II.6.1. Wymagania techniczne wobec Serwerowni.

19

Szczegółowy opis wymagań znajduje się w załączniku nr 4 do OPZ Wymagania techniczne wobec Serwerowni.II.6.2. Tworzenie i dostęp do raportów.II.6.2.1. System Centralny musi pozwalać na generowanie raportów na bieżąco, na żądanie użytkownika i mogą być przez niego zapisywane w Systemie, w formacie umożliwiającym późniejszą modyfikację definicji raportu, a także eksportowane do formatów, co najmniej xml, .xlsx, .docx. Raporty są od razu zapisywane do plików bądź przesyłane do innych Modułów do wykorzystania, przesłania do odbiorców, itp. Raporty mogą być wykonywane wg harmonogramu (ustawianego w dyspozytorze zadań). Sposób ich wykorzystania powinien być również programowalny.II.6.2.2. System Centralny musi posiadać mechanizmy wzbogacające sposób prezentacji wyników analiz:

1) prezentacje danych wstępnie zagregowanych na różnych poziomach szczegółowości, niosących w sobie informacje decyzyjne,

2) przestawne tabele prezentujące przekrój przez wielowymiarową strukturę danych, powiązane z nimi dwu- i trójwymiarowe wykresy,

3) dobieranie sposobu prezentacji danych w trakcie tworzenia analizy oraz możliwość późniejszego ustawienia zmian sposobu prezentacji przez użytkownika (w tym ustawienie domyślnego sposobu prezentacji dla określonej analizy),

4) analizy porównawcze.II.6.2.3. Użytkownik winien uzyskać możliwość tworzenia i modyfikacji szablonów raportów, o ile posiada dostęp z właściwymi uprawnieniami do odpowiednich danych. Szablon ma zawierać zestaw danych, które mają być prezentowane oraz sposób prezentacji, natomiast wybrane dane (np. czas, zakres linii, autobusów lub przystanków w przypadku monitorowania autobusów) są uzupełniane/wybierane kiedy z szablonu tworzony jest konkretny raport. W module Systemu Centralnego jest ogólny zestaw szablonów uzupełniany i modyfikowany przez administratora Modułu, ponadto każdy użytkownik może tworzyć własne szablony i dzielić je z innymi. Raporty można zapisać i porównywać.II.6.2.4. Ponadto, należy zapewnić powiązanie danych o sprzedaży z danymi o kliencie komunikacji miejskiej. Dane o kliencie muszą być pozbawione cech identyfikowalności konkretnego pasażera. Zestawienia te mają mieć charakter statystyczny. Pozwoli to na gromadzenie informacji o zapotrzebowaniu na określony rodzaj produktu lub usługi i budowanie charakterystyk tego zapotrzebowania. Profile zachowań klientów służą Zamawiającemu do badania zapotrzebowania na określony typ e-biletów na danej trasie poszczególnych grup klientów. Możliwe jest też badanie wpływu zmiany ceny na należności

20

poszczególnych grup klientów (np. poprzez odpowiedni szablon, prezentujący liczebność wybranych grup klientów i umożliwiający wpisanie dowolnego parametru ceny).Do realizacji wymienionych funkcjonalności konieczne jest osobne umożliwienie użytkownikowi zdefiniowania i zapisania grupy klientów (przez podanie wartości parametrów dotyczących zakupywanych usług, prawa do ulgi), do późniejszego wykorzystania w szablonach i raportach. System wykorzystując opisane wyżej narzędzia musi również wspomagać tworzenie raportów sprzedaży biletów autobusowych z podziałem na rodzaj biletu, miejsce sprzedaży oraz czas zakupu. W momencie wdrożenia Systemu winny być dostępne szablony do tworzenia następujących raportów prezentujących:1) ranking kanałów i punktów sprzedaży (POK i POS), typu e-biletu wg ilości lub

wartości sprzedanych/doładowanych Kart e-bilet oraz czasu (np. godziny największej/najmniejszej sprzedaży),

2) średnią sprzedaż na godzinę, dzień, miesiąc z podziałem na typ e-biletu, miejsce, punkt sprzedaży,

3) procentowy udział poszczególnych typów e-biletów w ogólnej sprzedaży na godzinę, dzień w miesiącu o minimalnej/maksymalnej sprzedaży z podziałem na miejsca, punkty.

II.7. Monitorowanie Systemu, zgłaszanie i raportowanie Awarii.II.7. 1. Monitorowanie Systemu, zgłaszanie Awarii.Wykonawca zapewni funkcjonalność zgłaszania i zarzadzania Awariami oraz monitorowania Systemu obejmujący:1. Możliwość dodawania wszystkich Urządzeń i Oprogramowań funkcjonujących w

Systemie, w tym Systemów Pokładowych Autobusów i Systemów Zajezdniowych, a także Tablic DIP. Zgłoszenie Awarii powinno polegać na wybraniu (odfiltrowaniu) z listy grupy Urządzeń np. aby zgłosić niedziałającą tablicę LED w pojeździe należy wybrać grupę AUTOBUSY -> NR BOCZNY AUTOBUSU -> GRUPĘ TABLIC -> WŁAŚCIWĄ TABLICĘ i opisać problem. Powinna istnieć możliwość rozbudowy listy, jej modyfikacji a także dodawania dodatkowych poziomów i grup urządzeń. Do każdej grupy urządzeń jest możliwość przypisania uprzednio zdefiniowanego użytkownika będącego przedstawicielem gwaranta/serwisanta. Każde zgłoszenie jest rejestrowane z możliwością zmiany jego statusów i mailowym powiadomieniem każdej zmiany statusu.

2. Funkcjonalność i odpowiednie stanowiska zarządzania Awariami od etapu zgłoszenia, poprzez realizację i potwierdzenie usunięcia awarii.

3. Możliwość analizy i raportowania wszystkich danych o Awariach.4. Automatyczne wykrywanie i raportowanie długotrwałych absencji Urządzeń i

Tablic DIP.

21

5. Bieżącą kontrolę stanu urządzeń i informowania o Awariach. Monitorowanie stanu ma być realizowane m.in. dla Urządzeń w pojeździe, Tablic DIP. Poprzez monitorowanie stanu Urządzeń Zamawiający rozumie automatyczną – wg zadanego harmonogramu – kontrolę funkcjonowania Urządzenia (np. za pomocą protokołu ICMP), a także wysyłanie przez same Urządzenie informacji o awariach.

6. Automatyczne powiadamianie o Awariach (poprzez mail, komunikat na ekranie).

7. Wykonawca zapewni wybrane przez siebie narzędzie usprawniające komunikację online pomiędzy nim, a Zamawiającym - wyznaczonymi pracownikami (Bug tracker). Narzędzie to powinno umożliwiać obsługę zgłoszeń zleceń z odpowiednimi konfigurowalnymi statusami oraz co najmniej dodawanie komentarzy i załączników i funkcje generowania statystyk oraz filtrowania, wyszukiwania zgłoszeń.

II.7.2 Raporty dotyczące Awarii i dostępności Systemu.1. Raport o Awariach, które wystąpiły w danym miesiącu wraz z informacją o

ich klasyfikacji, terminie usunięcia oraz wskazaniem, czy i o ile zostały przekroczone czasy ich usunięcia;

2. Raport o dostępności poszczególnych elementów Systemu, który przedstawia osiągnięte Parametry Dostępności oraz wskazuje na ewentualny poziom ich nieosiągnięcia. Zgodnie z poniższymi wzorami:

a) Parametr dostępności Biletomatów stacjonarnych i mobilnych, Kasowników, Czytników Kontrolerskich oraz Urządzeń Doładowujących (UD) określa się zgodnie z wzorem oddzielnie dla każdego rodzaju Urządzeń:

PD= (1 – (CA/CD))* 100%

PD – Parametr DostępnościCA – łączny czas napraw Awarii Krytycznych i Niekrytycznych wszystkich Urządzeń danego rodzaju (odpowiednio Biletomatów stacjonarnych i mobilnych, Kasowników, Czytników Kontrolerskich, Urządzeń Doładowujących (UD), Tablic Dynamicznej Informacji Pasażerskiej)CD – łączny czas dostępności Urządzeń danego typu liczony jako iloczyn liczby Urządzeń oraz liczby dni w danym miesiącu oraz 24

b) Parametr dostępności w zakresie dostępności strony internetowej POP, Oprogramowania RJ, Podsystemu DIP, określa się zgodnie z wzorem oddzielnie dla każdego z elementów podsystemu (systemu informatycznego, strony internetowej):

PD= (1 – (CA/CD))* 100%

PD – Parametr DostępnościCA – łączny czas napraw Awarii Krytycznych oraz Awarii Niekrytycznych danego elementu Systemu

22

(odpowiednio Podsystemu e-Bilet, Podsystemu RJ, Podsystemu DIP, Systemu Centralnego)CD – łączny czas dostępności danego elementu Systemu liczony jako iloczyn liczby dni w danym miesiącu oraz 24

3. Raport wydajności Systemu Centralnego: oparty na podstawie danych zbieranych na serwerze logów. Wszystkie parametry określone w: Załączniku 4 do OPZ Wymagania techniczne wobec Serwerowni. Wymagania dotyczące wydajności infrastruktury serwerowej powinny być raportowane z częstotliwością próbkowania nie większą niż co 10 minut.

II.8. Zasoby Zamawiającego.II.8.1. Tabor Operatora składa się z autobusów wymienionych wraz z wyposażeniem w Załączniku nr 2 do OPZ. Zawiera on również specyfikację pierwszej transzy autobusów, których dostarczenie jest planowane w 2018 r. Moduły Pokładowe Systemu zostaną zainstalowane w 95 autobusach Operatora. Część dostarczonych i zainstalowanych w autobusach Modułów Pokładowych Systemu wymagać będzie przeniesienia do kolejno dostarczanych, nie więcej niż 33 fabrycznie nowych autobusów Zamawiającego, w terminie do dnia 30 listopada 2019 r. Przeniesienie części Urządzeń odbywać się będzie zgodnie z harmonogramem ustalonym przez Zamawiającego, w porozumieniu z Wykonawcą (Załącznik nr 5 Planowane wymiany autobusów). Wykonawca musi wziąć pod uwagę, pod względem skalowalności Systemu, że docelowa wielkość Taboru może osiągnąć nawet 116 autobusów.

II.8.2. Operator użytkuje Systemy Zajezdniowe wymienione w poniższej tabeli, które służą do zbierania, raportowania i automatycznej wymiany danych, w szczególności z oprogramowaniem do tworzenia rozkładów jazdy (AGC BusMan) oraz do programowania Systemów Pokładowych Autobusów. Zamawiający zaleca, aby systemy (programy) wymienione w poniższej tabeli zostały zintegrowane z Systemem Centralnym w ramach umowy. W przypadku braku integracji Wykonawca musi zapewnić, możliwość automatycznego wykonywania funkcji wymienionych poniżej Systemów Zajezdniowych w inny, automatyczny sposób (np. przy użyciu innego dostarczonego oprogramowania), w szczególności możliwość:

1) programowania Pokładowych Systemów Autobusowych wszystkich autobusów Operatora,

2) pozyskiwania danych eksploatacyjnych ze wszystkich autobusów wyposażonych

23

w Autokomputer oraz ich raportowanie o zakresie funkcjonalnym (jak np. do systemu PDA),

3) zapewnienia przesyłania do Systemu niezbędnych danych z Modułów Pokładowych Systemu i danych eksploatacyjnych z autobusów.

SYSTEMY ZAJEZDNIO

WE / PROGRAM

FUNKCJA PROGRAMU DANE PROGRAMU KIERUNEK WYMIANY DANYCH

Pakiet PIXEL 3

przygotowywanie danych dla obsługi komputerów pokładowych;

zarządzanie informacjami przedstawianymi za pomocą urządzeń firmy PIXEL;

tworzenie nowych lub modyfikowanie istniejących danych;

definiowanie struktury Bazy Danych Komunikacyjnych jako spisu linii i kierunków wraz z przystankami;

edytowanie treści, czyli napisów i obrazów wyświetlanych na tablicach w autobusie;

kompilację danych do plików przesyłanych do urządzeń w autobusie;

przesyłanie skompilowanej bazy do urządzeń w autobusie.

napisy i rysunki w formie tworzonych cegiełek przesyłane na tablice pikselowe, tablice LED oraz tablice diodowe instalowane w autobusach komunikacji publicznej;

treść kierunku, przystanku, linii, przystanku na żądanie, blokady kasowników, przystanku końcowego, zegara, strony z imieninami

informacje dźwiękowe emitowane przez urządzenia zapowiadające w formacie MP3;

dane zdefiniowane dla autobusu: limit przyspieszenia określany w m/s2 , limit hamowania określany w m/s2, domyślna prędkość maksymalna, strefa wyjazdowa według GPS, maksymalny czas postoju z włączonym silnikiem, język danych, format nazwy publicznej przystanku;

dane dla kierowcy: format numeru brygady i kursu, styl numerowania kierunków, funkcja automatycznej zmiany kierunków, data ważności rozkładu jazdy, określany czas do rozpoczęcia kursu, funkcja podpowiadania kierunków (Autoplaner), zestawy użytkownika określające zestawy

urządzeń zamontowanych w danym autobusie, funkcja edycji parametrów odcinka trasy

określana w m lub km, edycja typów kursów i pór dnia, edycja kalendarza, edycja trasy przejazdu;

dane przygotowane w Pakiecie PIXEL 3 dotyczą edycji i tworzenia: rozkładów jazdy, zapowiedzi głosowych, tablic kierunkowych, lokalizacji GPS przystanków, danych kierowców;

dane do komputera pokładowego przygotowywane są, a następnie wysyłane za pomocą serwera Data Access Server;

dane które trafiają do komputera pokładowego zapewniają:

automatyczne sterowanie (bez ingerencji kierowcy) tablic kierunkowych na podstawie pozycji GPS, w tym również automatyczną zmianę nazwy kierunku jazdy na przystankach końcowych, automatyczną zmianę numeru linii i nazwy kierunku jazdy w przypadku służb ze zmianą linii, a także informowanie o kierunku i pozostałym czasie do odjazdu z pętli autobusowej na tablicy kierunkowej przedniej,

automatyczne sterowanie (bez ingerencji kierowcy) systemem automatycznej informacji pasażerskiej umożliwiający głosowe zapowiadanie kolejnych przystanków oraz innych informacji i komunikatów (będących wyraźnie słyszalnych dla pasażerów), na podstawie lokalizacji GPS, w oparciu o wyznaczone współrzędne geograficzne lokalizacji przystanków, pochodzące z komputera centralnego (wspólnego dla wszystkich autobusów objętych zamówieniem), posiadający automatyczną

Za pośrednictwem serwera Data Access Server dane są zarówno wysyłane do komputerów pokładowych, jak również automatycznie pobierają dane i zapisują rejestry z Autokomputerów.

24

regulację poziomu głośności zapowiedzi w zależności od pory dnia, zarządzany z komputera pokładowego. System synchronicznie emituje informację wizualną na wewnętrznej tablicy informacji pasażerskiej. System automatycznie (tj. bez ingerencji kierowcy – poprzez wykorzystanie danych z zainstalowanego w autobusie Modułu systemu GPS) emituje wewnątrz autobusu komunikaty o przebiegu trasy w sposób cykliczny - podczas całego przebiegu trasy,

podgląd wybranych treści na wyświetlaczu w formie graficznej, tj. nr linii i nazwa kierunku;

bieżący monitoring wykonywanego kursu, realizowany poprzez wyświetlane komunikaty tekstowe, określające w czasie rzeczywistym: aktualny czas, punktualność w formie odchyłek czasowych (przyspieszeń i opóźnień – alarmy dźwiękowe) oraz konieczność rozpoczęcia kursu na przystanku początkowym (sygnalizowanie dźwiękowe),

informacje sygnalizujące kierowcy nieprawidłowe parametry eksploatacji autobusu: przekroczenie prędkości, gwałtowne przyspieszenie, gwałtowne hamowania, przekroczenie obrotów, postój przy włączonym silniku,

rejestracje stanów krytycznych poprzedzać powinien sygnał dźwiękowy (posiadający regulację umożliwiającą stopniowanie jego natężenia) ostrzegający o zbliżaniu się do stanu rejestrowanego przekroczenia, a w momencie naruszenia pojawić powinien się dodatkowy sygnał świetlny i dźwiękowy na wyświetlaczu widocznym dla kierowcy. W przypadku zdarzeń przekroczenia progów gwałtownych hamowań oraz nadmiernych przyspieszeń rejestracja i sygnalizacja świetlna powinna następować w momencie naruszenia. Wartości tych parametrów powinny być możliwe do wygodnego zdefiniowaniaw oprogramowaniu i przekazywane do autobusów. Wyświetlanie tych informacji na dodatkowym ekranie, który powinien być umieszczony tak, aby kierowca mógł śledzić komunikaty obserwując deskę rozdzielczą.

PDA – Analizator Danych PIXEL

przeglądanie, wizualizacja i analizowanie zaimportowanych danych pochodzących z autobusów oraz ich dalszy eksport, tworzenie i dalszy eksport zdefiniowanych raportów

dane eksploatacyjne pobierane z szyny CAN: przekroczenia prędkości, gwałtowne hamowania i przyspieszania, czas pracy systemu agregatu ogrzewania, włączenie/wyłączenie silnika, włączenie/wyłączenie oświetlenia wewnętrznego, użycie przyklęku, użycie przycisku „Stop”, użycie przycisku „inwalida”, otwarcie drzwi, jazda na biegu neutralnym, przekroczenie obrotów silnika, postój na biegu jałowym, otwarcie klapy głównego zbiornika paliwa, otwarcie klapy silnika, otwarcie klapy wlewu zbiornika Webasto, stan paliwa w zbiorniku, paliwo zużyte dla włączonego silnika (odczytywane

na podstawie danych z wtryskiwaczy), paliwo zużyte na kierunku (odczytywane na

podstawie danych z wtryskiwaczy),

paliwo zużyte przez kierowcę (odczytywane na podstawie danych z wtryskiwaczy przekroczenie temperatury oleju w skrzyni biegów,

przekroczenie temperatury cieczy chłodzącej w silniku,

przekroczenie zadanego progu ciśnienia w ogumieniu,

przekroczenie zadanego progu temperatury w

rejestrowanie z szyny CAN lub analogowo danych eksploatacyjnych, które następnie przekazywane są do komputera pokładowego;

import danych źródłowych z bazy danych rejestrów komputera pokładowego za pomocą serwera Data Access Server przez pakiety importujące na komputer pełniący rolę serwera PDA.

25

ogumieniu czas przybycia na przystanek, logowanie kierowców, droga przejechana przez kierowcę.

Zdefiniowane przez MZK Sp. z o.o. raporty odnoszące się do parametrów technicznych uzyskanych z szyny CAN autobusów mające na celu analizę pracy autobusów i kierowców, raporty zarówno analityczne, jak i syntetyczne, które mają odniesienie do m.in. wartości progowych uzyskiwanych zdarzeń, wartości średnich, czasów trwania, ilości wystąpień danych zdarzeń. Są to następujące raporty:

o raport eksploatacji,o karta pracy autobusu,o ranking kierowców – raport syntetyczny dający

możliwość porównania techniki jazdy kierowców wg zdefiniowanych parametrów,

o przekroczenia obrotów silnika,o przekroczenia prędkości,o przyspieszenia i hamowania,o poziom paliwa,o zużycie paliwa,o czas jazdy – raport syntetyczny i analityczny,o odjazdy z przystanków,o otwarcia klap paliwa,o realizacja kierunku.

DataAccessServer

usługa serwera FTP; pośredniczenie pomiędzy system przygotowania danych (Pakiet PIXEL 3) oraz analizowania i prezentacji zarejestrowanych danych (PDA), a sterownikami i komputerami pokładowymi; monitorowanie dostarczenia nowych plików danych na serwer FTP lub przez interfejs WWW i umieszczenie ich w katalogu archiwum; przekazywanie plików danych do odpowiednich katalogów, z których Autokomputery pobierają dane rejestracja plików danych w bazie danych, w celu przechowywania historii ładowań danych i kontrolowania danych posiadanych przez autobusy.

wgrywanie do Autokomputerów: rozkładów jazdy, zapowiedzi głosowych, tablic kierunkowych, lokalizacji GPS przystanków, danych kierowców;

lista typów autobusów; lista obsługiwanych autobusów przez serwer; lista ładowanych danych; lista logowań autobusów; dane z autobusów wykorzystywane przez PDA.

1. Import danych z programu Pakiet PIXEL 3.

2. Import oraz eksport pomiędzy DAS, a Autokomputerami Asterix zamontowanych w autobusach. Wymiana danych przy pomocy Wi-Fi (antena zamontowana na stacji bazowej oraz w autobusie).

3. Eksport danych do serwera PDA.

PixelBusmanImport

Narzędzie, które umożliwia pobieranie rozkładów jazdy tworzonych w oprogramowaniu AGC Busman i zapisujące je do bazy przejściowej. Wynikowa baza następnie wykorzystana jest w programie Pakiet Pixel 3, do wprowadzenia rozkładów jazdy.

Wygenerowany plik bazodanowy zawierający szczegółowy rozkład jazdy (czasy, nazwy przystanków, kursy, numery brygad, listę typów dni).

1. AGC Busman (utworzenie pliku bazowego).

2. PIXEL Busman Import (importowanie pliku bazowego utworzonego w AGC Busman, a następnie wygenerowanie pliku bazodanowego).

3. Pakiet PIXEL 3 (edycja pliku bazodanowego z PIXEL Busman Import, a następnie utworzenie pliku z danymi – rozkłady jazdy wraz z plikami zapowiedzi).

4. Data Access

26

Server (pobranie pliku z programu Pakiet PIXEL 3 oraz wysłanie go na serwer FTP).

5. Pobranie pliku przez Autokomputer Asterix.

II.8.3. Operator użytkuje Systemy Dziedzinowe wymienione w poniższej tabeli, które są niezbędne do funkcjonowania Operatora i zasilania systemów Zamawiającego. Zamawiający wymaga danych w ramach umowy, aby systemy wymienione w poniższej tabeli w sposób automatyczny wymieniały dane z Systemem, w zakresie wszystkich niezbędnych danych i wymaganych okresach czasu, zarówno dla Systemu, jak i Systemów Dziedzinowych, tak aby System i Systemy Dziedzinowe mogły sprawnie, prawidłowo pracować na spójnych danych, zgodnie z wymogiem Zamawiającego, że dane do Systemu muszą być wprowadzane raz.

Systemy Dziedzino

we / Program

Funkcje programu Dane programu Kierunek wymiany danych

SystemEGCfirmy

SYSTEmEG Sp. z o.o.

Zbieranie danych o wystawionych opłatach dodatkowych;

Zarządzanie systemem ratalnym opłat dodatkowych;

Wprowadzania zapłat i rozliczanie opłat dodatkowych;

Wystawianie i zarządzenie wezwaniami do zapłaty;

Analiza i raportowanie;Eksport danych do systemów

zewnętrznych.

Dane osobowe pasażera; Dane dotyczące mandatów (tj. data, miejsce wystawienia; nr mandatu; ID kontrolera, dane pojazdu, linii; itp.); Dane dotyczące prowadzonych systemów ratalnych (wysokość rat, okresy wpłat, itp.); Dane dotyczące wpłat pasażerów za opłaty dodatkowe (data wpłaty, miejsce; dane wpłacającego; numer mandatu); Dane rozliczeniowe (kwoty miesięcznych obrotów).

Informacje o wystawionych mandatach wprowadzane są do programu windykacyjnego;

Dane o zapłatach są wprowadzane z systemu VeritumXL (moduł raportów kasowych i bankowych);

Dane rozliczeniowo – księgowe wprowadzane są do systemu VeritumXL (moduł finansowo – księgowy).

Stacja Paliw Zbieranie informacji o wykonanych tankowaniach;

Przechowywanie stanów magazynowych paliwa w zbiornikach;

Obsługa dostaw paliwa; Eksport danych do systemów

zewnętrznych; Raportowanie.

Dane identyfikacyjne kierowców (imię, nazwisko, ID); Dane identyfikacyjne pojazdów (numer boczny, numer rejestracyjny, marka); Dokumenty rozchodowe dla zbiorników paliwa (pojazd, kierowca,

Dokumenty rozchodowe przenoszone są do programu VeritumXL (moduł magazynowy);

Dane o pojazdach i kierowcach przenoszone są z programu VeritumXL (moduł transport i finansowo - księgowy)

27

data, nr zbiornika, ilość); Dokumenty przychodowe dla zbiorników paliwa (dostawca, data, ilość)

VeritumXLfirmy

System-1 sp. z o.o.

Moduł sprzedażowy – odpowiedzialny za wszelkie operacje związane z obsługą sprzedaży;

Moduł magazynowy – odpowiedzialny ze wszelkie operacja związane z obsługą magazynów w tym dokumentów powiązanych ze sprzedażą;

Moduł raportów kasowych i bankowych – odpowiedzialny za dokumenty obrotowe i rozrachunkowe gotówkowe i bezgotówkowe wewnętrzne i zewnętrzne;

Uproszczony moduł transportu – odpowiedzialny za utrzymanie listy pojazdów firmowych;

Moduł ogólny – odpowiedzialny m.in. za obsługę danych ogólnych wykorzystywanych w innych modułach, np. kontrahentów, lokalizacji, działów, itp.;

Moduł kadrowo – płacowy – odpowiedzialny za prowadzenie grafików i rozliczanie pracowników;

Moduł finansowo – księgowy – pełna funkcjonalność księgowa w tym rozrachunki powiązana z resztą modułów poprzez dekrety.

Dokumenty magazynowe (data, magazyn, ilość, wartość, towaru, pojazd, pracownik, itp.); Dokumenty sprzedażowe (data, rejestr, ilość, wartość, towar/usługa, pracownik, itp.); Dokumenty rozliczeniowe kierowców (data, ilość biletów, typ biletów, wartość sprzedaży, kierowca); Dane osobowe kontrahentów; Dane osobowe pasażerów; Dane osobowe pracowników (w tym kierowców); Dane dotyczące czasu pracy kierowców (kierowca, data, czas pracy, nieobecności).

Dokumenty magazynowe dotyczące tankowań przenoszone są do programu rozliczeniowego pracę kierowców i autobusów - Karty Drogowe;

Dokumenty dotyczące sprzedaży i obsługi magazynowej powiązanej ze sprzedażą przenoszone są do programu VeritumXL moduł finansowo – księgowy;

Dokumenty z programu rozliczeniowego (sprzedaż) kierowców (Karty drogowe) przenoszone są do programu VeritumXL moduł sprzedaży;

Dokumenty z programu rozliczeniowego czas pracy kierowców (Karty drogowe) przenoszone są do programu VeritumXL moduł kadrowo – płacowy.

II.8.4. Operator użytkuje Systemy Dziedzinowe wymienione w poniższej tabeli, które są niezbędne do funkcjonowania Operatora i zasilania systemów Zamawiającego, a których funkcjonalności Wykonawca zastąpi przez funkcjonalności Systemu, poprzez zapewnienie odpowiedniej wymiany danych w ramach Systemu oraz z Systemami Dziedzinowymi i Systemami Zajezdniowymi zgodnie z wymaganiami OPZ opisanymi w pkt 2 Rozdziału II.4 Wymiana danych pomiędzy elementami Systemu.

Systemy Dziedzino

we / Program

Funkcje programu Dane programu Kierunek wymiany danych

KF3000 firmy R&G PLUS Sp.

z o.o.

Rozliczane kas fiskalnych w autobusach;

Raportowanie sprzedaży z kas fiskalnych w autobusach z podziałem na autobus, kierowcę, grupę biletów, rodzaj

Dane dotyczące kierowców (ID, imię, nazwisko);

Dane dotyczące biletów (nazwa, cena);

Dane dotyczące pojazdów i kas (ID,

Dane dotyczące kierowców przenoszone są z programu VeritumXL (moduł kadrowo – płacowy);

Dane dotyczące sprzedaży przenoszone są do programu Depozyt.

28

biletów. lokalizacja, data); Dane dotyczące

sprzedaży (ID kasy, pojazd, typ biletów, ilość wartość, kierowca).

Depozyt firmy MARCOM

Marek Hetmański

Rozliczanie kierowców (gotówka) ze sprzedaży biletów;

Naliczanie premii za sprzedaż biletów.

Dane kierowcy (ID, imię, nazwisko);

Dane dotyczące sprzedaży ilościowo-wartościowej dla danego kierowcy (ID, data, wartość, typ biletów, ilość);

Dane dotyczące wpłat gotówkowych przez kierowców (ID, data, wartość);

Dane dotyczące nadwyżek/niedoborów;

Dane dotyczące naliczonych premii.

Dane dotyczące sprzedaży przenoszone do programu VeritumXL (moduł sprzedażowy);

Dane dotyczące premii przenoszone są do programu VeritumXL (moduł kadrowo-płacowy).

Busman v100.0991 firmy AGC

Consulting Sp. z o.o.

Planowanie rozkładów jazdy.

Dane o pojazdach (typ, ilość, itp.);

Dane o brygadach z podziałem na typy dni (numer, godziny pracy);

Dane o rozkładach jazdy (typ dnia, kursy, brygady, godziny, warianty, dopiski).

Dane o brygadach przenoszone są do programu Busgraf;

Dane rozkładowe przenoszone są do serwisów Internetowych i aplikacji zewnętrznych (www.mzkopole.pl/rozklad, www.mzkopole.pl/rozklady, www.jakdojade.pl, system „Kiedy przyjedzie?”).

Busgraf firmy AGC

Consulting Sp. z o.o.

Planowanie czasu pracy kierowców

Dane o brygadach w danym dniu (numer brygady, typ dnia, godziny);

Dane o kierowcach (ID, imię, nazwisko);

Grafik czasu pracy kierowców (ID, dzień, godziny pracy, linia, pojazd).

Dane o brygadach przenoszone są z programu Busman;

Dane o kierowcach przenoszone są z programu VeritumXL (moduł kadrowo – płacowy);

Dane o zaplanowanych grafikach przenoszone są do programu Eksploatacja.

Eksploatacja firmy

MARCOM Marek

Hetmański

Rozliczanie czasu pracy kierowców;

Rozliczenia czasu pracy i paliwa pojazdów;

Naliczanie premii za jazdę ekonomiczną dla kierowców.

Dane dotyczące pojazdów (ID, numer boczny);

Dane dotyczące kierowców (ID, imię nazwisko);

Dane dotyczące czasu pracy pojazdów z podziałem na linie (ID, daty, godziny, linia, km, zużycie paliwa, stan licznika);

Dane dotyczące czasu pracy kierowców z podziałem na pojazdy (ID, pojazd, daty, godziny);

Dane dotyczące premii za oszczędność paliwa (kierowca, wartość, okres).

Dane dotyczące pojazdów przenoszone są z Systemu VeritumXL (moduł transport);

Dane dotyczące kierowców przenoszone są z programu VeritumXL (moduł kadrowo-płacowy);

Dane dotyczące premii przenoszone są do programu VeritumXL (moduł kadrowo-płacowy);

Dane dotyczące tankować przenoszone są z programu VeritumXL (moduł magazynowy);

Dane dotyczące czasu pracy pojazdów i kierowców wprowadzane są z kart drogowych.

Trzeźwość firmy

MARCOM Marek

Hetmański

Losowanie kierowców do kontroli trzeźwości i zbieranie danych o jej wynikach.

Dane o kierowcach (ID, imię, nazwisko);

Dane o grafikach kierowców (ID, dzień, czas pracy).

Dane o kierowcach i ich czasie pracy pobierane są z programu Eksploatacja.

29

II.9. Zarządzanie użytkownikami.System wyposażony będzie w funkcjonalność do zarządzania użytkownikami w spójny, intuicyjny i ergonomiczny sposób, która umożliwi m.in.:1) przypisywanie każdemu użytkownikowi z osobna jego grup (np. Operator,

Organizator, wykonawca etc.) i ról: Administrator, Dyspozytor, stanowisko rozliczeniowe, Organizator, itp.;

2) edytowanie przypisanych użytkownikowi ról i funkcji; 3) przypisywanie rolom praw do wykonywania określonych czynności;4) określenie poziomu dostępu i prawa zapisu do poszczególnych baz danych i

funkcjonalności Systemu Centralnego dla różnych grup użytkowników, np. grupy Dyspozytorów, a także tej posiadającej pełny zakres (grupa Administratorów). Administrator będzie miał możliwość tworzenia dowolnych grup i przypisywania im wybranych funkcji (ról) i uprawnień;

5) zmianę haseł zarówno przez administratora, jak i samego użytkownika.

Wymagane jest aby dostęp do wszystkich funkcjonalności Systemu przyznanych użytkownikowi wymagało jednego konta Systemu, w szczególności dla podsystemów wchodzących w skład Systemu Centralnego

30

III. Oprogramowanie do projektowania rozkładów jazdy (Oprogramowanie RJ).

Operator transportu publicznego w imieniu Zamawiającego wykonuje zadania związane z układaniem rozkładów jazdy i projektowaniem linii komunikacyjnych i dysponuje 1 licencją programu do tworzenia rozkładów jazdy i zarządzania komunikacją miejską firmy AGC BusMan w wersji 100.0991. Wykonawca dostarczy Oprogramowanie RJ w wersji umożliwiającej pracę (projektowanie rozkładów jazdy) przez Operatora i Zamawiającego. Sposób licencjonowania opisany jest w pkt VI.3. Licencje.Dostarczone Oprogramowanie RJ jazdy umożliwiać będzie eksport danych do innych Systemów wdrożonych aktualnie u Operatora oraz Systemów wdrażanych w ramach niniejszej umowy, w otwartych formatach danych. Wykonawca przeniesie dane rozkładowe z istniejącej bazy danych programu AGC BusMan do nowej, dostarczonej w ramach zamówienia.

III.1. Wymagania dla Oprogramowania RJ.Oprogramowanie RJ powinno umożliwiać: 1) projektowanie rozkładów jazdy w trybie automatycznym i ręcznym w oparciu o

mapę z podkładem topograficznym, bazę danych o odległościach międzyprzystankowych i czasach przejazdu,

2) projektowanie linii komunikacyjnych dla jednej grupy linii lub grupy kilku linii, możliwość łączenia kursów jednej i więcej linii w brygady,

3) generowanie danych o brygadach, danych eksploatacyjnych grupy linii, danych na stronę internetową, wyszukiwarki połączeń, Podsystemu DIP, tablic kierunkowych i systemu zapowiedzi głosowych,

4) wydruki rozkładów jazdy na tabliczki przystankowe, rozkładów dla kierowców – tzw. „kursówek”, rozkładów jazdy jako załączników do zaświadczeń i zezwoleń na wykonywanie regularnego przewozu osób, edytowanie danych do programów Excel, Word.

5) wspomaganie planowanie harmonogramów i rozliczanie czasu pracy oraz autobusów,

6) eksport/import danych zewnętrznych, generowanie raportów i wydruków.

Oprogramowanie RJ nie jest integralną częścią Systemu Centralnego. Zamawiający wymaga, by Oprogramowanie RJ było z nim zintegrowane, zapewniając z nim stałą łączność (eksport-import danych).III.1.1. Mapa, mapa z podkładem topograficznym.

Mapa (będąca częścią Oprogramowania RJ) powinna umożliwiać tworzenie nowych odcinków sieci, połączeń, przejazdów, nowych wariantów linii, wstawianie nowych przystanków, dzielenia przystanków na słupki lewe i prawe, nadawanie cech przystankom i słupkom, generowanie odległości międzyprzystankowych.

31

III.1.2. Czasy przejazdów.

Program powinien umożliwiać automatyczne ustawianie czasów przejazdów dla wybranych odcinków tras projektowanych linii w oparciu o wcześniej zdefiniowane odległości i czasy międzyprzystankowe dla dowolnych pór dnia i dni tygodnia, z możliwością zastosowania wyjątku dla wybranej linii. Powinien również umożliwić kopiowanie czasów i wyjątków z jednego odcinka do drugiego.

III.1.3. Kalendarz.

Kalendarz powinien umożliwiać przypisanie zestawów czasów przejazdów (np. w dni robocze, robocze wakacyjne, soboty, niedziele i inne), typów odjazdów (codzienne, robocze, robocze szkolne, sobotnie, niedzielne i inne), modeli brygad do właściwych rodzajów dni. III.1.4. Projektowanie rozkładów jazdy.Projektowanie rozkładów jazdy powinno odbywać się w trybie automatycznym lub ręcznym poprzez odpowiedni wybór trasy i jej wariantów (w tym przejazdów technicznych). Wpisywanie zaś godzin odjazdów kursów danej linii powinno odbywać się na rozkładzie graficznym z opcją edytowania (kopiowania) i przesuwania kursów, lub w osobnych oknach również z możliwością kopiowania z jednego typu dnia do drugiego.Zaprojektowane wcześniej kursy muszą być połączone w brygady wraz z postojami pomiędzy kursami i przejazdami technicznymi tworząc rozkłady dla poszczególnych zadań. Oprogramowanie RJ musi również umożliwiać zamianę kursów pomiędzy brygadami danej linii, jak również kursami innych linii.Wygenerowane rozkłady muszą być przypisane do właściwych modeli brygad (zadań dla kierowców), typu taboru i rodzajów dni na tabliczki przystankowe.III.1.5. Planowanie harmonogramów i rozliczanie czasu pracy kierowców.Na podstawie wygenerowanych rozkładów jazdy Oprogramowanie RJ powinno umożliwiać tworzenie harmonogramów pracy kierowców w trybie automatycznym i ręcznym w podziale na harmonogramy dzienne, miesięczne, kwartalne, itd.Możliwość tworzenia w harmonogramach grup kierowców i przypisywanie zadań w zależności od systemów czasu pracy (równoważnego, przerywanego czasu pracy, mieszanego), rodzaju taboru i innych wskazanych przez Zamawiającego lub Operatora. Ponadto, umożliwiać bieżącą ich optymalizację, bieżące wprowadzanie danych (zmiany w rozkładach dla zadania, absencje kierowców – urlop, chorobowe itp.)Musi istnieć możliwość autouzupełniania danych na podstawie poprzednich miesięcy z uwzględnieniem odpowiednich przesunięć w typach dni.Harmonogramy te muszą uwzględniać obowiązujące przepisy (ustawa o czasie pracy kierowców) w zakresie czasu pracy, okresów prowadzenia przerw i odpoczynków. Na podstawie harmonogramów pracy musi być możliwość ich rozliczenia, tj. uzupełnienia danych

32

w module rozliczenia czasu pracy kierowców na podstawie rzeczywistych danych. Uzupełnienie następuje na dwa sposoby:1) automatycznie z Systemu Centralnego (dane z Autokomputerów o logowaniach

kierowców i prowadzonej „kursówce”),

2) ręcznie na podstawie kart drogowych,Dane te powinny być następnie wyeksportowane do systemu kadrowo-płacowego u Operatora.

III.1.6. Rozliczanie kilometrów i paliwa samochodów.1) Dane eksploatacyjne linii z Modułu planowania powinny zostań przeniesione do

Modułu rozliczania. Następnie dane planowane powinny zostać uzupełnione o:a) autobusy kursujące w danym dniu – automatycznie na podstawie danych z

Systemu Centralnego,b) kilometry, z podziałem na autobusy – automatycznie na podstawie danych z

Systemu Centralnego,c) zużycie paliwa z podziałem na autobusy – automatycznie na podstawie

danych ze stacji paliw.2) Na każdym etapie powinna być możliwość ręcznej korekty danych na

podstawie kart drogowych. Dane powinny być uzupełniane w sposób ciągły dla każdego dnia. Powinna być możliwość dowiązania tych danych do informacji o kierowcy dla danego autobusu i danego dnia oraz do danej „kursówki” i linii.

III.1.7. Statystyki.Oprogramowanie RJ powinno umożliwić generowanie danych takich jak:1) szczegółowe dane o liniach i brygadach w podziale na rodzaje dni, 2) szczegółowe dane o liniach i brygadach w podziale na gminy i Operatorów,3) szczegółowe dane eksploatacyjne grupy linii w podziale na rodzaje dni,4) szczegółowe dane eksploatacyjne grupy linii w podziale na gminy i

Operatorów, 5) ewidencję słupków i przystanków wraz z ich cechami w podziale na gminy,6) ewidencję zatrzymań na przystankach w podziale na gminy,7) ewidencję zatrzymań na przystankach w podziale na właściwych zarządców

dróg,8) ewidencję odjazdów z wybranego słupka,9) ewidencję wyjazdów i zjazdów,

10) plany wozokilometrów w podziale na gminy i Operatorów (dzień, tydzień, miesiąc, rok),

11) plany czasu pracy kierowców,12) plany urlopów kierowców w podziale na dzień, miesiąc, rok, 13) ewidencję czasu pracy kierowców,14) ewidencję urlopów, zwolnień lekarskich, godzin pracy, godzin nadliczbowych, 15) ewidencję planowanych i rzeczywistych kilometrów z podziałem na autobus,

kierowcę, kursówkę, linię,16) ewidencję zużycia paliwa z podziałem na autobus, kierowcę, kursówkę, linię.

33

III.1.8. Wydruki.Dla potrzeb Zamawiającego lub Operatora niezbędne są wydruki:1) tabliczek przystankowych w formatach i opisach wskazanych przez

Zamawiającego lub Operatora, 2) rozkładów dla zadania („kursówek”), w formatach i opisach wskazanych przez

Zamawiającego lub Operatora, 3) rozkładów tabelarycznych dla potrzeb Zamawiającego lub Operatora,4) rozkładów tabelarycznych, jako załączników do zaświadczeń na wykonywanie

publicznego, transportu drogowego, zezwoleń na wykonywanie przewozów regularnych specjalnych,

5) schematu z przebiegiem linii, kilku linii, sieci,6) harmonogramów miesięcznych dla kierowców,7) harmonogramów dziennych dla kierowców,8) harmonogramów indywidulanych dla kierowców z uwzględnieniem czasu

pracy, okresów prowadzenia, przerwy i odpoczynków, innych czynności,9) planów wozokilometrów,

10) planów czasu pracy kierowców,11) planów urlopów,12) ewidencji czasu pracy w podziale: kierowca, wszyscy kierowcy, 13) ewidencji urlopów, zwolnień lekarskich, godzin pracy, godzin nadliczbowych

godzin pracy, godzin nadliczbowych, 14) inne wskazane przez Zamawiającego lub Operatora oraz eksport danych w

formacie xlsx i docx.

III.1.9. Współpraca z innymi Systemami.Oprogramowanie RJ musi współpracować z Systemami:1) Podsystem DIP,2) Podsystemem e-bilet (w szczególności z Modułem POP, Modułami Pokładowymi

Systemu),3) Systemami Pokładowymi Autobusów (w szczególności sterowania tablicami

kierunkowymi, zapowiedzi głosowych),4) Systemami Dziedzinowymi (w szczególności Kadrowo – Płacowego, strony

internetowej mzkopole.pl i wyszukiwarki połączeń),5) portalami informacji pasażerskiej kiedyprzyjedzie.pl, JakDojade.pl.

III.1.10. Wymagania techniczne.III.1.10.1. Ogólny schemat działania.Oprogramowanie RJ powinno posiadać jedną centralną bazę oraz bazy robocze nie związane z bazą centralną. Musi on umożliwić synchronizację danych z istniejącymi systemami Zamawiającego oraz z nowym Systemem będącym przedmiotem niniejszego zamówienia. Dostęp do bazy centralnej powinien być ściśle kontrolowany.

III.1.10.2. Wymagania dla bazy centralnej.1) możliwość automatycznego przekazywania danych (m.in. o liniach, kursach,

brygadach, taborze, opisach wariantów), bez ingerencji użytkownika lub

34

administratora, do zewnętrznych systemów, w tym:a) portali informacji pasażerskiej WWW w tym: kiedyprzyjedzie.pl, jakdojade.pl, b) Pakiet Pixel 3 (zalecane),c) istniejących rozkładów jazdy na stronie WWW Operatora (mzkopole.pl wraz z

wyszukiwarką),d) Podsystemu DIP, Modułu dyspozytorskiego i geolokalizacyjnego,e) Podsystemu e-bilet, w szczególności nowego serwera www (POP)

obsługującego rozkłady jazdy oraz wyszukiwarkę połączeń,f) Autokomputerów i Modułów Pokładowych Autobusów.

2) publikowanie wszystkich danych wykonanych na bazach roboczych przez autoryzowanych użytkowników w trybie „tylko do odczytu”.

3) możliwość ustalania i modyfikacji czasów obowiązywania danych.4) podglądanie historii wersji i logów publikacji danych.5) możliwość generowania i tworzenia własnych raportów z linii komend oraz

interfejsu graficznego w składni SQL.

6) możliwość eksportu danych do formatów xlsx, pdf, docx.7) możliwość autoryzacji poprzez struktury Active Directory (AD – usługa

katalogowa) oraz przez mechanizm wbudowany. Zamawiający dopuszcza, aby Oprogramowanie opisane w punktach III.1.5. i III.1.6 było osobnym Oprogramowaniem, przy zastrzeżeniu, że musi ściśle współpracować z Oprogramowaniem RJ oraz spełniać pozostałe opisane wymogi.

III.1.10.3. Wymagania dla bazy roboczej.Baza robocza powinna mieć możliwość:1) eksportu danych bez ingerencji administratora lub użytkownika do bazy

centralnej przez uprawnionych użytkowników,2) przechowywania kilku niezależnych wersji danych (baz) oraz importowania ich

pomiędzy sobą,3) generowania i tworzenia własnych raportów za pomocą wbudowanego

mechanizmu,4) eksportu danych do formatów xlsx, pdf, docx,5) pracy w programie bez uprawnień administratora,6) łatwego przenoszenia bazy na inną lokalizację lub komputer.

III.1.10.4. Przeniesienie danych.Wykonawca przeniesie dane z istniejącej bazy danych programu AGC BusMan do dostarczonej i zweryfikuje poprawność wprowadzonych danych.

35

36

IV. Funkcjonalności i wymagania techniczne dla Podsystemu biletu elektronicznego (Podsystem e-bilet).

IV.1. Ogólny opis. IV.1.1. Podsystem e-bilet pod względem funkcjonalnym będzie umożliwiał.1) sprzedaż Kontraktów okresowych i Doładowań e-portmonetki:

a) zakodowanych na Kartach e-bilet personalizowanych lub na okaziciela, dystrybuowanych w punktach kasowych Operatora (POK),

b) zewnętrznych POS, c) Biletomatach stacjonarnych,d) przez stronę internetową www POP,e) Biletów Papierowych sprzedawanych na dotychczasowych zasadach w POK

Operatora oraz w Biletomatach stacjonarnych i mobilnych;

2) pełną obsługę pasażerów, w tym: a) przyjmowanie wniosków i wydawanie Kart e-bilet, b) personalizację graficzną i elektroniczną nośników elektronicznych – Kart e-

bilet,c) rejestrację wszystkich operacji związanych z obiegiem Karty e-bilet w

Podsystemie e-bilet (personalizacja, wydawanie Kart e-bilet, blokowanie, odblokowanie, wydawanie duplikatów, Doładowania Karty e-bilet, zakup biletów),

d) obsługę reklamacji, zwrotów, wymian biletów, korekty sprzedaży, itp.;3) zarządzanie i nadzór nad siecią sprzedaży składającą się z:

a) 10 Biletomatów stacjonarnych z możliwością rozbudowy do min. 30,b) 95 Biletomatów mobilnych z możliwością rozbudowy do 130,c) 30 punktów sprzedaży POS z możliwością rozbudowy do 60, d) 4 POK biletów z możliwością rozbudowy do 10,e) sklepu POP w wersji standardowej oraz mobilnej;

4) zarządzanie i nadzór nad siecią kasowników w autobusach;5) zarządzanie stroną WWW (POP);6) gromadzenie danych sprzedażowych z każdego kanału sprzedaży w celu

rozliczania i raportowania sprzedaży;

7) prowadzenie, nadzór oraz rozliczenie kontroli biletów za pomocą urządzeń kontrolerskich, w tym umożliwić drukowanie wezwań do zapłaty, elektroniczne wymianę danych o opłatach dodatkowych i umożliwić przyjmowanie opłat za pomocą kart kredytowych (lub innych nośników np. telefony);

8) weryfikację zgodności sprawdzonych w trakcie kontroli Kontraktów okresowych i Doładowań e-portmonetki, z zapisanymi w Systemie Centralnym danymi. Jeżeli Kontrakt okresowy lub Doładowanie e-portmonetki nie jest widoczne w Systemie

37

Centralnym po 24 godzinach, Karta e-biletu z wykrytą niezgodnością powinna być automatycznie blokowana. W przypadku kart spersonalizowanych, użytkownik powinien być powiadamiany o zablokowaniu Karty e-bilet poprzez mail podany przy rejestracji lub sms;

9) generowanie raportów,10) Wykonawca zaimportuje dane z aktualnie używanego systemu sprzedaży

Operatora (Veritum XL) do Podsystemu e-bilet. Zakres importowanych danych obejmie:a) kartotekę kontrahentów,b) kartotekę pasażerów,c) historyczne transakcje pasażerów.

IV.2. Funkcjonalności i wymagania dla Podsystemu e-bilet.IV.2.1. Wymagania ogólne.IV.2.1.1. Ochrona danych osobowych. Wszystkie dostarczane elementy Podsystemu e-bilet, w tym Oprogramowanie oraz Urządzenia, biorące udział w przetwarzaniu danych osobowych, zgodnie z ustawą z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (t.j. Dz.U. z 2016 r., poz. 922) muszą spełniać wymogi rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. (t.j. Dz.U. z 2004 r., Nr 100, poz. 1024) w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych.IV.2.1.2. Elementy Podsystemu e-bilet.Podsystem e-bilet jest kompleksowym rozwiązaniem informatycznym na potrzeby Zamawiającego, pełniącym szereg funkcji w zakresie obsługi przejazdów pasażerskich i obsługi płatności za usługi komunikacji miejskiej organizowanej przez Miasto Opole.Podsystem e-bilet składa się z części centralnej, będącej częścią Systemu Centralnego, zlokalizowanej w Serwerowni wspólnej z innymi Systemami instalowanymi w ramach zadania oraz ze specjalizowanych pracujących w terenie:1) POK,2) POS,3) Biletomatów stacjonarnych, 4) systemów zamontowanych w autobusach, w tym: Kasowników,

Autokomputerów, Sterowników e-biletu i Biletomatów mobilnych,

5) obsługi Kart e-biletu stanowiących nośnik biletu komunikacji miejskiej,6) kontroli biletów.IV.2.2. Moduły funkcjonalne Podsystemu e-bilet.

38

Podsystem składa się z następujących umownych lub rozdzielnych Modułów funkcjonalnych, odpowiedzialnych za poszczególne zadania (dopuszcza się inna architekturę Systemu niż wymieniona poniżej, o ile wszystkie wymagane funkcjonalności będą przez System realizowane):a) administrowanie,b) transmisja danych,c) przetwarzanie danych,d) dystrybucja i personalizacja Kart e-bilet,e) obsługa sprzedaży obejmująca POK, POS, sieć Biletomatów stacjonarnych i

mobilnych,f) analiza i raportowanie,g) obsługa kontrolerów,h) Doładowywanie e-portmonetki oraz zakup Kontraktu okresowego przez POP. IV.3. Główne funkcje realizowane przez Podsystem e-bilet.1) Obsługa procesu personalizacji Karty e-bilet.2) Wydawanie Karty e-bilet imiennej oraz na okaziciela.3) Możliwość stosowania biletów o różnych ulgach oraz biletów bezpłatnych.4) Możliwość tworzenia modyfikowalnej listy blokowania Kart e-bilet.5) Możliwość odtworzenia historii Karty e-bilet i wystawiania jej duplikatu.6) Możliwość predefiniowania taryf domyślnych dla różnych typów Kart e-bilet.7) Możliwość realizacji funkcji dokupywanych biletów – również w innej taryfie,

niż domyślna.8) Konfiguracja Karty e-bilet imiennej, jako domyślnej ulgowej lub normalnej.

Zakup innego biletu niż domyślny wymaga uprzedniego wybrania na ekranie kasownika odpowiedniej pozycji. Sposób potwierdzenia przez pasażera uprawnienia do ulgi będzie ustalone w regulaminie.

9) Zapis na Karcie e-bilet Kontraktów okresowych (sprzedaż i fakturowanie).10) Wydawanie Kart e-bilet na okaziciela z pobraniem kaucji.11) Obsługa reklamacji klientów i zgłoszenia utraconych imiennych Kart e-

biletu.12) Zastrzeganie utraconych imiennych Kart e-biletu.13) Zastrzeganie utraconych Kart e-bilet na okaziciela, pod warunkiem

okazania dowodu wpłaty kaucji zawierającego numer Karty e-bilet.14) Wymiana danych z POS, POK, Biletomatami stacjonarnymi i mobilnymi,

POP, czytnikami kontrolerskimi, Systemami Pokładowymi Autobusów.15) Zarządzanie Biletomatami stacjonarnymi i mobilnymi.16) Gromadzenie danych przesyłanych z urządzeń sterujących pracą Modułów

Pokładowych Systemu, POK, POS, POP, Biletomatów stacjonarnych i mobilnych, czytników kontrolerskich.

17) Gromadzenie i przetwarzanie danych ze wszystkich kanałów sprzedaży biletów.

18) Analiza i wielowymiarowe raportowanie.19) Współpraca z przenośnymi urządzeniami do kontroli Karty e-biletu,

rejestracja i przekazanie informacji do systemu windykacji EGC – użytkowany przez Operatora.

39

20) Ewidencja danych Podsystemu e-bilet: obsługa ładowania Kart e-bilet, obsługa rodzajów ulg, okresów ważności biletów okresowych.

21) Nadawanie i obsługa uprawnień kasjerów, kontrolerów, kierowców i administratorów.

22) Transmisja i rejestracja danych do i ze stacjonarnych oraz mobilnych Biletomatów.

23) Rejestracja danych do i z przenośnych urządzeń do kontroli Kart e-bilet.24) Prowadzenie rozliczeń z podmiotami realizującymi obsługę sprzedaży

biletów (POS).25) Ochrona i szyfrowanie danych.26) Archiwizowanie danych.27) Obsługa kas biletowych Operatora (POK) w zakresie sprzedaży wszystkich

rodzajów biletów, w tym Biletów Papierowych sprzedawanych na dotychczasowych zasadach w punktach kasowych Operatora (POK) z uwzględnieniem rozliczeń finansowych (raporty kasowe) oraz gospodarki magazynowej biletów jednorazowych, łącznie z obsługą kas fiskalnych.

28) Umożliwienie importu i eksportu danych z i do innych programów (Wykonawca powinien określić, jakie dane są niezbędne do prawidłowego importowania i eksportowania oraz w jakim formacie mają one być przesłane), w tym: a) programu do projektowania i optymalizacji rozkładów jazdy,b) systemu finansowo-księgowego Veritum w MZK Sp. z o.o.,c) systemu EGC (o opłatach dodatkowych do wykorzystywanego w MZK Sp. z

o.o. oraz importu danych niezbędnych do prowadzenia kontroli i wystawiania opłat dodatkowych, wymagane jest zasilenie wstępne takimi danymi Systemu Centralnego).

29) Posiadać strukturę danych przygotowaną na przyjmowanie danych trybu offline z różnych urządzeń z zachowaniem prawidłowej numeracji.

30) Zapewniać odpowiedni poziom bezpieczeństwa w zakresie pracy w Systemie i dostępu do danych w tym: a) wprowadzanie i dostęp do danych powinno być udostępnione tylko

autoryzowanym użytkownikom;b) wprowadzanie i dostęp do danych powinno być możliwe przez kilku

użytkowników jednocześnie;c) zakres działania użytkownika określany przez administratora;d) wszystkie transakcje sprzedażowe i statystyczne (wymiana punktów na

bilet) powinny być identyfikowane w Podsystemie e-bilet na poziomie (tym samym przesyłane z urządzeń zewnętrznych):i. urządzenia dokonującego transakcji,ii. danych transakcji,iii. czasu dokonanej transakcji,iv. Karty e-biletu (jeżeli są dostępne),v. kontrahenta (jeżeli są dostępne),vi. autobusu (jeżeli są dostępne),vii. linii (jeżeli są dostępne),viii. kursu (jeżeli są dostępne),

40

ix. przystanku (jeżeli są dostępne),x. lokalizacji GPS (jeżeli są dostępne).

IV.4. Raportowanie.Zamawiający na etapie realizacji oczekuje możliwości generowania następujących raportów:IV.4.1. Rozliczające dla indywidualnego użytkownika Karty e-biletu:1) data, godzina, kwota i opis transakcji,2) saldo początkowe i końcowe,3) System Centralny musi generować miesięczne zestawienie przeprowadzonych

operacji w zadanym okresie czasu.IV.4.2. Ogólne:1) statystyczne z przeprowadzonych transakcji,2) rozliczające dla danych jednostek (POK, POS, POP, Biletomat),3) sprzedanych i używanych Kart e-bilet,4) zastrzeżonych Kart e-bilet,5) liczby pozostałych Kart e-bilet do wydania,6) ilości sprzedanych usług (z podziałem na bilety jednorazowe i okresowe),7) dane z kontroli biletów,8) klientów,9) generowanie raportów o transakcjach, biletach na konkretnym przystanku,

linii, w autobusie i kursie, w rozbiciu dziennym (pora dnia), tygodniowym, miesięcznym, rocznym,

10) generowanie danych o dokładnej liczbie pasażerów wsiadających na poszczególnych przystankach w podziale na rodzaje biletów,

11) generowanie danych o liczbie pasażerów przewiezionych w oparciu o bilety normalne, ulgowe, bezpłatne,

12) generowanie danych o błędach w Podsystemie e-bilet, z podaniem informacji o lokalizacji i rodzaju błędu,

13) generowanie danych o niezgodnościach zapisów na Kartach e-bilet, z zapisami w Systemie Centralnym ujawnionych podczas kontroli biletów. Wystąpienie takich niezgodności powinno być sygnalizowane komunikatem, a Karta e-bilet dodawana do listy blokowanych.

IV.4.3. Powyższe raporty mają być generowane z możliwością podziału na:1) rodzaje opłat,2) punkty sprzedaży (POK, POS),3) kanały sprzedaży (POK, POS, POP, Biletomaty stacjonarne, Biletomaty mobilne,

sprzedaż przez zewnętrzne aplikacje mobilne),4) wskazane okresy czasowe.IV.4.4. Generowanie raportów: dostarczony System Centralny ma umożliwić tworzenie nowych raportów (funkcja generatora raportów). Zamawiający zastrzega sobie

41

możliwość pełnej obsługi generatora raportów według własnego uznania i zapotrzebowania, bez konieczności udziału osób lub firm trzecich.IV.4.5. Zatwierdzanie raportów: sposób akceptowania raportów potwierdzających i generowanie odpowiednich formatów Wykonawca ustali z Zamawiającym na etapie realizacji.IV.4.6. Zawartość i format raportów: Zawartość i ostateczny format raportów Wykonawca ustali z Zamawiającym na etapie realizacji.IV.4.7. System Centralny będzie prezentować wszystkie dane za pomocą jednorodnego interfejsu, dając zaawansowanemu użytkownikowi dodatkową możliwość posłużenia się zapytaniem SQL do tworzenia szablonów, analiz raportów.IV.4.8. Zamawiający oczekuje, aby raporty, analizy, zestawienia, itp. obiekty, powstające w wyniku analizy danych prezentowane były w formacie umożliwiającym ich przeniesienie do aplikacji Microsoft Office, a w szczególności do programu Microsoft Excel. Wykonawca zapewni również możliwość programowego eksportu uzyskanych zestawień do plików w formacie rtf, xls, xml, html, pdf.

IV.5. Funkcjonalności związane z zarządzaniem, obsługą i monitorowaniem Biletomatów stacjonarnych i mobilnych oraz Urządzeń zamontowanych w autobusach.IV.5.1. Funkcjonalności związane z zarządzaniem, obsługą i monitorowaniem Biletomatów stacjonarnych i mobilnych. Oprogramowanie Biletomatów stacjonarnych i mobilnych powinno umożliwiać:1) definiowanie maski i tła ekranów informacyjnych;2) definiowanie parametrów pracy wyświetlacza;3) przejmowanie z pamięci Biletomatu danych o przeprowadzonych

transakcjach, rozliczeniach środków płatniczych (wpłaconych i wydanych), dostępu do Biletomatu stacjonarnego i mobilnego służb serwisowych oraz danych o stanie technicznym podstawowych podzespołów Biletomatu stacjonarnego i mobilnego;

4) tworzenie taryfy biletowej oraz definiowanie formy graficznej sprzedawanych biletów;

5) tworzenie dowolnych statystyk sprzedaży w wybranych terminach, w rozbiciu na rodzaje sprzedanych biletów, wielkość ilościową i wartościową sprzedaży w poszczególnych Biletomatach stacjonarnych i mobilnych;

6) prowadzenie statystyki sprzedaży w wybranych terminach, w rozbiciu na rodzaje sprzedanych biletów, wielkość ilościową i wartościową sprzedaży w poszczególnych Biletomatach stacjonarnych i mobilnych;

42

7) zdalne monitorowanie pracy wszystkich Biletomatów stacjonarnych i mobilnych (dostęp do wszystkich Urządzeń pracujących oraz możliwość równoległego zarządzania pracującymi Biletomatami stacjonarnymi i mobilnymi):a) podgląd stanu wybranego Biletomatu stacjonarnego i mobilnego:

konfiguracji stanu podzespołów, ilości monet i banknotów w zasobnikach, informacji o niedługim przekroczeniu wartości progowych (określenie minimalnej ilości monet, banknotów, papieru w Biletomacie stacjonarnym i mobilnym),

b) odbieranie sygnałów alarmowych zgłaszanych przez Biletomaty stacjonarne i mobilne,

c) otrzymywanie na bieżąco wszystkich informacji o każdej transakcji, w celu rozpatrywania ewentualnych reklamacji.

8) zdalne zarządzanie Biletomatem stacjonarnym i mobilnym (tzn. zmiany konfiguracji Biletomatu stacjonarnego i mobilnego, wgrywanie aktualizacji Oprogramowania, wykonywanie funkcji testujących, blokowanie Biletomatu stacjonarnego i mobilnego, restart Biletomatu stacjonarnego i mobilnego, możliwość zmiany interfejsu dla użytkownika, synchronizacja daty i godziny, zmiana czasu na letni lub zimowy), możliwość sterowania Biletomatami stacjonarnymi i mobilnymi za pomocą poleceń grupowych lub pojedynczych.

9) aktualizacje Oprogramowania powinny być dostarczone w postaci „instalacyjnej”. Aktualizacje znajdującego się w Biletomacie stacjonarnym i mobilnym będzie można dokonywać zarówno bezpośrednio w Biletomacie stacjonarnym i mobilnym, jak i od strony centrali.

10) format danych generowanych przez Biletomat zostanie ustalony z Zamawiającym.

11) Oprogramowanie musi umożliwiać dwustronne przesyłanie danych z Biletomatu stacjonarnego i mobilnego przy wykorzystaniu:a) pendrive za pośrednictwem złącza USB min. 2.0 lub karty pamięci, przy

czym w przypadku karty można używać jedynie kart w standardzie SD lub microSD;

b) sieci GSM modemu zabudowanego w Biletomacie stacjonarnym lub mobilnym w autobusie.

12) musi istnieć możliwość wysyłania powiadomień w postaci SMS-ów na wybrany nr telefonu komórkowego, o usterkach Biletomatu stacjonarnego i mobilnego oraz dostęp do podglądu stanu Urządzeń.

IV.5.2. Funkcjonalności związane z zarządzaniem, obsługą i monitorowaniem Modułów Pokładowych Systemów.Oprogramowanie Modułów Pokładowych Systemów powinno umożliwiać: 1) przejmowanie z pamięci Modułów Pokładowych Systemu danych o

przeprowadzonych transakcjach, informacji o dostępie służb serwisowych oraz danych o stanie technicznym Biletomatu mobilnego;

43

2) zdalne monitorowanie pracy Autokomputerów (zalecane), Sterowników e-biletu i Kasowników;

3) możliwość zdalnego zarządzania Modułami Pokładowymi Systemu (tzn. zmiany konfiguracji, wgrywanie aktualizacji, wykonywanie funkcji testujących, blokowanie urządzeń pokładowych e-biletu, możliwość zmiany interfejsu dla użytkownika, synchronizacja daty i godziny, zmiana czasu na letni lub zimowy);

4) możliwość sterowania Modułami Pokładowymi Systemu za pomocą poleceń grupowych lub pojedynczych, pobieranie i przetwarzanie elektronicznych rozkładów jazdy z Oprogramowania RJ (bezpośrednio lub poprzez interfejs programowy Systemu Centralnego), na żądanie – w dowolnym momencie oraz w sposób automatyczny – zgodnie z zadanym harmonogramem, pobierania i aktualizacji „białych” i „czarnych” list Kart e-biletu;

5) odbieranie sygnałów alarmowych zgłaszanych przez Urządzenia;6) otrzymywanie na bieżąco wszystkich informacji o każdej transakcji w celu

rozpatrywania ewentualnych reklamacji;7) aktualizacje powinny być dostarczone w postaci „instalacyjnej”. Aktualizacje

Oprogramowania w Urządzeniach będzie można dokonywać zarówno bezpośrednio, jak i od strony centrali;

8) Oprogramowanie musi umożliwiać dwustronne przesyłanie danych z Urządzeń w autobusach przy wykorzystaniu:a) modemu pracującego w sieci GSM,b) Wi-Fi na zajezdni autobusowej.

IV.5.3. Karta e-biletu.Podsystem e-bilet zostanie oparty o karty elektroniczne w standardzie MIFARE DESFire w liczbie 50 tys. sztuk., przy czym zastosowane Karty e-bilet nie mogą ograniczać Zamawiającego w zakresie dostępu do systemu plików Karty e-bilet i muszą być dostępne na wolnym rynku.W Podsystemie e-bilet będą funkcjonowały Karty e-bilet imienne i na okaziciela. Każda Karta e-bilet będzie aktywowana elektronicznie w Systemie Centralnym. Karty e-bilet imienne będą personalizowane elektronicznie, jak i graficznie poprzez nadruk imienia i nazwiska pasażera oraz jego zdjęcie. Karty e-bilet stanowić będą nośnik biletu elektronicznego: Kontraktu okresowego i e-portmonetki. IV.5.3.1. Założenia ogólne.Karta e-bilet będzie pełnić funkcje bezkontaktowego elektronicznego biletu komunikacji miejskiej – jednorazowego i Kontraktu okresowego, imiennego lub na okaziciela i będzie posiadać możliwość wnoszenia opłat za przejazdy w systemie „check in - check out” (wejście – wyjście). Zamawiający wymaga przeniesienia praw do kluczy zapisu na karcie oraz „mapy karty”, którą Wykonawca przekaże Zamawiającemu na etapie wdrożenia w pełną pełnym zakresie tj. wszystkie kody dostępu do pamięci i aplikacji Karty e-bilet, a także dokumentacje interfejsu Karty e-bilet i czytnika

44

wraz ze sterownikami. Zamawiający wymaga również przekazania algorytmów wyznaczania dywersyfikacji kluczy oraz Oprogramowania do generowania i wymiany kluczy.Zamawiający zakłada, że od momentu uruchomienia Podsystemu e-bilet za pomocą Karty e-biletu będzie obsługiwana cała taryfa biletowa przedstawiona Wykonawcy w trakcie wdrożenia. Na karcie imiennej e-biletu będzie można zarejestrować przysługujące pasażerom ulgi i zwolnienia. Sposoby i zakres realizacji tych uprawnień na karcie e-bilet Wykonawca ustali z Zamawiającym.IV.5.3.2. Usługi na karcie e-bilet.1. Kontrakty okresowe:

a) wydzielona aplikacja na karcie e-bilet do zapisania na karcie imiennej lub na okaziciela informacji o wykupieniu określonego Kontraktu okresowego;

b) płatność jednorazowa przy zakupie biletu;c) pierwszy dzień ważności biletu okresowego określa klient w maksymalnym

przedziale czasu (X dni – do ustalenia w trakcie wdrożenia);

d) na Karcie e-biletu będzie możliwe zapisanie dwóch kontaktów okresowych o następujących po sobie okresach ważności lub pokrywających się okresach ważności, ale na różne strefy taryfowe z uwzględnieniem taryf opłat obowiązujących w gminach, w których transport zbiorowy jest organizowany przez Miasto Opole, jak również zakresu ulg obowiązujących na terenie poszczególnych gmin (w tym ulgi 100%);

e) zapisane Kontrakty okresowe mogą, w danym momencie, być tylko jednego typu: normalne lub ulgowe,

f) wyłącznie imienna Karta e-bilet będzie zawierała zapisane uprawnienia do ulg lub zwolnień.

2. Bilety jednorazowe i wielokrotnego przejazdu lub czasowe (e-portmonetka):a) wydzielona aplikacja na karcie imiennej lub na okaziciela;b) płatność na zasadzie zakupienia „z góry” określonej liczby punktów na

przejazdy;c) należność za przejazd na danej linii i kierunku pobierana jest w wysokości

odpowiadającej biletowi jednorazowemu według obowiązującej taryfy i stref taryfowych występujących na kierunku jazdy i według cennika od-powiadającego podróży do przystanku końcowego;

d) Wykonawca oprogramuje Podsystem e-bilet pod kątem zapewnienia możliwości pobierania opłat wg kryterium liczby przejechanych przystanków lub kilometrów lub czasu przejazdu (ważnych określoną liczbę minut od skasowania);

e) Podsystem e-bilet powinien rozpoznać, czy posiadany aktywny bilet obowiązuje w strefie taryfowej, w której podróż została rozpoczęta i zasygnalizować ewentualną niezgodność;

f) jeżeli pasażer podróżuje na linii mającej trasę w dwóch strefach i posiada bilet ważny na strefę rozpoczęcia podróży, Podsystem e-bilet winien poinformować pasażera o możliwości przekroczenia granicy stref taryfowych

45

i ewentualnej nieważności biletu w następnej strefie. Odpowiedni komunikat w połączeniu z sygnałem dźwiękowym powinien zostać wyświetlony na monitorze kasownika w momencie kasowania biletu;

g) w przypadku, gdy część trasy planowanej podróży przypada na strefę nie objętą Kontraktem okresowym, pasażer powinien mieć możliwość dokupienia właściwego biletu jednorazowego z e-portmonetki w chwili rozpoczęcia podróży;

h) Podsystem e-bilet zapewni możliwość pobierania opłat wg tzw. taryfy dynamicznej. Pasażer posiadający aplikację z e-portmonetką taryfy dynamicznej będzie obciążany po transakcji, w której zakup w ciągu doby n i więcej biletów jednorazowych (np. 4) nie spowoduje obciążenia Karty e-bilet klienta kwotą n*2,6 – np. 10,40 zł, a obciąży ceną biletu dobowego – np. 9 zł. Patrząc dalej – skasowanie w ciągu miesiąca 10 i więcej biletów dobowych nie obciąży Karty e-bilet klienta kwotą 90 zł (lub więcej zł) tylko kwotą np. 88 zł, jak za bilet miesięczny.

IV.5.3.3. Szata graficzna Karty e-bilet.1) Strona A: do personalizacji.2) Strona B: nazwa, adres i stron internetowych Zamawiającego i Operatora kod

kreskowy i QR, oznakowanie projektu dofinansowanego ze środków UE.Zamawiający dostarczy Wykonawcy projekt graficzny stron A i B po podpisaniu

umowy.Na stronie A projekt będzie zawierał miejsce na:a) zdjęcie formatu maks. 30 mm x 30 mm,b) imiona, nazwisko,c) dane dodatkowe,d) numer Karty e-bilet.Zamawiający przewiduje, co najmniej po 2 szablony dla strony A.

IV.5.3.4. Nadruki na Kartach e-bilet.1) Rozdzielczość drukowania: min. 300 dpi.2) Technika drukowania grafiki przygotowanej wcześniej: offset.3) Trwałe zabezpieczenie przed ścieraniem (wykonanie nadruku na Karcie e-bilet

w sposób wykluczający utratę zapisanej informacji w czasie użytkowania Karty e-bilet zgodnie z jej przeznaczeniem).

4) 3 kolory podstawowe + czarny, umożliwiające uzyskanie skali barwnej.5) Nadruk personalizacyjny będzie realizowany w kolorze.6) Nadruk na stronie A ma być przystosowany do personalizacji Karty e-bilet na

drukarce termotransferowej w siedzibie Operatora oraz POK.IV.5.3.5. Format nadruku numeru Karty e-bilet:1) Zawsze 17 cyfr.2) Obowiązuje zasada uzupełniania cyfr nieznaczącymi zerami (z przodu) do

osiągnięcia 17 cyfr.3) Karty e-bilet będą drukowane jednostronnie przez Wykonawcę.4) Wzory graficzne muszą być drukowane z rozdzielczością co najmniej 300 dpi.

46

5) Nadruki muszą być trwale zabezpieczone przed ścieraniem wg normy ISO 7816 i 7810.

6) W przypadku stwierdzenia przez Zamawiającego niezgodności numeru graficznego Karty e-bilet z numerem elektronicznym Karta e-bilet uznana zostanie za wadliwą.

IV.5.3.6. Minimalne wymagania techniczne dotyczące Karty e-bilet .Karty e-bilet zgodne ze standardami opisanymi w normie ISO/IEC 14443 typ A i B. 1) Charakterystyka fizyczna:

a) Karta e-bilet musi być wykonana z tworzywa sztucznego nie zawierającego szkodliwych składników chemicznych i  być przyjazna dla środowiska;

b) Wykonawca musi zagwarantować wysoką jakość połączeń elektrycznych pomiędzy anteną, a układem elektronicznym, w całym okresie eksploatacji Karty e-bilet;

c) antena wykonana z drutu miedzianego izolowanego, zgodnego z normami: IEC 60317-20, IEC 60317-4 oraz NEMA: MW 79, MW2 i  MW 75, wtopiona w rdzeń Karty e-biletu. Nie dopuszcza się innych technologii wykonania anteny;

d) wymiary zgodne z normami ISO 7816-7810, jak karty płatnicze ID-1 (85,8 x 54 x 0,76mm).

2) Parametry wytrzymałościowe:a) wytrzymałość: mechaniczna, temperaturowa (w zakresie od -20ºC do +

50ºC) bez utraty funkcjonalności i  walorów estetycznych oraz wytrzymałość chemiczna muszą spełniać co najmniej standardy opisane w normie ISO 10373,

b) trwałość całkowita 10 lat w warunkach normalnej eksploatacji,c) wilgotność względna środowiska pracy Karty e-bilet do 90 %,

3) Charakterystyka techniczna: wysokość procentowa tak zwanych "zwrotów z pola" (FRR) Kart e-bilet zbliżeniowych nie może przekraczać 0,70 %.

4) Zabezpieczenia:a) Karty e-bilet muszą zawierać skuteczne zabezpieczenia zgodne z normą

ISO/IEC 14443 typ A I B;b) szyfrowanie informacji na karcie musi wykorzystywać co najmniej algorytm

DES, 3DES lub AES,c) Karta e-bilet powinna posiadać wbudowany generator liczb losowych,d) każda Karta e-bilet musi zawierać unikalny i  niezmienny numer zapisany na

7 bajtach, programowany trwale przez producenta układu pamięciowego,e) Karta e-bilet muszą umożliwiać wzajemną autoidentyfikację z czytnikiem

działającym zgodnie z normą ISO/IEC 7816-4,f) musi istnieć możliwość wyłączania programowanych funkcji zapisu dla Kart

e-bilet wycofywanych z obiegu. Rozwiązanie zapewnione przez Wykonawcę uniemożliwi powtórne wprowadzenie takich Kart e-bilet do obiegu bez konieczności ich fizycznego niszczenia,

g) Karta e-bilet musi posiadać certyfikat CC EAL4+.5) Pamięć:

47

a) technologia: CMOS EEPROM,b) organizacja pamięci: system plików,c) wieloaplikacyjność: co najmniej 28 aplikacji, MAD3,d) pojemność Kart e-bilet imiennych i  na okaziciela: co najmniej 4kB,e) ilość cykli zapisu: minimum 200.000 (wg specyfikowanego przez producenta

zakresu warunków pracy),f) ilość cykli odczytu: nielimitowana,g) okres przechowywania danych: 10 lat.

6) Komunikacja:Komunikacja między Kartą e-bilet, a czytnikiem odbywa się drogą radiową:a) częstotliwość nośna: 13,56 MHz,b) interfejs bezkontaktowy musi spełniać warunki normy ISO/IEC 14443 typ A i

B, c) szybkość komunikacji: minimum 106 kbit/s,d) czas realizacji operacji: mniej niż. 100 ms,e) protokół komunikacyjny: half duplex,f) zasięg operacyjny: do 10 cm,g) pełna antykolizja (zabezpieczenie przed jednoczesnym odczytem kilku Kart

e-bilet).7) Zasilanie: Karta e-bilet zasilana jest indukcyjnie przez czytnik. Karta e-bilet nie

posiada własnego źródła zasilania.IV.5.3.7 Uwagi dodatkowe.1. Struktura Karty e-bilet powinna być zaprojektowana w sposób umożliwiający

w każdej chwili rozszerzenie jej funkcjonalności o dodatkowe usługi.2. Wykonawca dostarczy Oprogramowanie do generowania, wgrywania i

podmiany kluczy do aplikacji, a także dostarczy dokumentację odnośnie struktury danych zapisanych na karcie w trakcie personalizacji i kodowania biletów. Właścicielem kluczy do kodowania jest Zamawiający.

3. Zawartość informacyjna Karty e-bilet. Na Karcie e-bilet zapisywane będą: 1) Kontrakty okresowe wg pozycji taryfowej i rodzaju (normalny, ulgowy z

rozróżnieniem ulgi w poszczególnych strefach/gminach) zgodnie z obowiązującym systemem taryfowym oraz datą ważności biletu,

2) e-portmonetka, w której znajdą się punkty przeznaczone na zakup biletów jednorazowych.

W przyszłości przewiduje się możliwość wprowadzenia systemu „check in - check out”. Szczegółowa struktura zapisów zostanie uzgodniona przed wdrożeniem.IV.5.3.7.4. Użytkowanie Karty e-bilet.1) Rozróżnia się następujące tryby użytkowania Karty e-bilet:

a) Karta e-bilet na okaziciela:- Kontrakt okresowy na okaziciela i/lub e-portmonetka.

b) Karta e-bilet imienna:- Kontrakty okresowe i/lub e-portmonetka, ze zdefiniowanymi uprawnieniami

do ulg.

48

2) Sposób i skutki personalizacji:a) W pamięci Karty e-bilet oraz w bazie danych Systemu Centralnego zapisane

są dane klienta oraz terminowe lub bezterminowe uprawnienia do zniżek, rodzaj przysługującej zniżki.

b) Wydruk na Karcie e-bilet: zdjęcia i dane identyfikujące osobę (bez numeru PESEL).

3) Procedura personalizacji (na podstawie złożonego zweryfikowanego wniosku i zweryfikowanych uprawnień):a) klient w wyznaczonych punktach personalizacji składa wniosek o wydanie

Karty e-bilet imiennej;b) klient podaje dane do zapisania/wydruku na Karcie e-bilet;c) podaje dane do zarejestrowania w Systemie Centralnym;d) klient składa zdjęcie do dokonania nadruku na Karcie e-bilet;e) w przypadku braku zdjęcia, pracownik punktu personalizacji wykonuje na

poczekaniu zdjęcie klienta (twarz) do nadruku na Karcie e-bilet;f) personalizacja zostaje wykonana w terminie późniejszym lub na poczekaniu,

zgodnie z zapisami regulaminu;g) po przedłożeniu stosownych dokumentów i stwierdzeniu uprawnienia do

zniżki, na Karcie e-bilet imiennej oraz w Systemie Centralnym zostaje zapisana informacja o zniżce i terminie jej obowiązywania. Podsystem e-bilet powinien umożliwiać wielokrotną aktualizację danych o uprawnieniach do zniżek na Karcie e-bilet.

4) Podsystem e-bilet ma umożliwiać wprowadzenie opłat za usługi związane z obsługą Karty e-bilet (np. opłata manipulacyjna za zmianę danych Klienta).

5) Zastrzeganie Karty e-bilet jest realizowane przez Internet lub osobiście w POK.6) Zamawiający przejmuje odpowiedzialność za zastrzeżoną Kartę e-bilet po

upływie 24 godzin od momentu złożenia dyspozycji przez klienta.7) Przez zastrzeżenie Karty e-bilet rozumie się zablokowanie obsługi takiej Karty

e-bilet przez Podsystem e-bilet i przeniesienie jej do bazy zastrzeżonych Kart e-bilet. Zastrzeżenie Karty e-bilet wiąże się z utratą jej ważności po upływie 24 godzin od jej zastrzeżenia. Informacja o zastrzeżeniu Karty e-bilet musi być rozpropagowana w Podsystemie e-bilet.

8) Karta e-bilet rejestrowana w Podsystemie e-bilet i znajdująca się na liście zastrzeżonych Kart e-bilet zostaje przez Podsystem e-bilet zablokowana i staje się Kartą e-bilet nieaktywną.

9) Właścicielem Kart e-bilet pozostaje Zamawiający.10) Klient otrzymując pierwszą Kartę e-bilet imienną nie wnosi żadnych opłat.

Opcjonalnie bierze się pod uwagę zakup na Kartę e-bilet dowolnego biletu okresowego imiennego. Nie jest to ani opłata za wydanie Karty e-bilet ani kaucja za wydaną Kartę e-bilet.

11) Klient pobierający kolejną Kartę e-bilet imienną (w miejsce zagubionej, zniszczonej) wpłaca kaucję. Podsystem e-bilet musi być tak oprogramowany, aby wymuszać konieczność wpłaty kaucji w przypadku, gdy klient wnioskuje o wydanie nowej Karty e-bilet. Podsystem e-bilet będzie obsługiwał wpłaty i wypłaty kaucji (przy zwrocie Karty e-bilet).

49

12) Zwrot Karty e-bilet imiennej może nastąpić w dowolnym momencie. Należy zapewnić możliwość wypłacania środków z e-portmonetki i części wartości biletu okresowego zgodnie z regulaminem e-biletu.

13) W przypadku pobrania Karty e-bilet na okaziciela klient wpłaca kaucję. Klient otrzyma dowód wpłaty kaucji. Podsystem e-bilet powinien uwzględniać generowanie takiego dowodu. W przypadku zniszczenia Karty e-bilet przez klienta lub jej zgubienia albo kradzieży kaucja nie będzie zwracana. Kaucja nie może zostać wykorzystana na dokonanie płatności Kartą e-bilet z e-portmonetki.

14) Zwrot Karty e-bilet na okaziciela może nastąpić w dowolnym czasie.15) Po zwróceniu Karty e-bilet na okaziciela przez klienta i okazaniu dowodu

wpłaty kaucji Klientowi zostanie zwrócona kwota stanowiąca równowartość wpłaconej kaucji. Może być zwrócona kwota wpłacona na bilety okresowe i punkty w e-portmonetce zapisane na karcie na okaziciela. Zasady zostaną określone w regulaminie biletu elektronicznego.

16) Faktury za zrealizowane usługi wystawiają odpowiednie jednostki (POK) na życzenie klienta.

17) Personalizacja Kart e-bilet prowadzona będzie przez Operatora. Karty e-bilet do personalizacji Wykonawca dostarczy jednorazowo.

18) Wykonawca przed dostawą Kart e-bilet zadrukuje je wg uzgodnionych z Zamawiającym szablonów graficznych.

19) Podsystem e-bilet musi być tak zaprogramowany, aby istniała możliwość zablokowania lub zastrzeżenia danej Karty e-bilet imiennej i na okaziciela w Podsystemie e-biletu (wg numeru Karty e-bilet i wg użytkownika). Rejestracji i ewentualnego wycofania Karty e-bilet z obiegu dokonuje administrator Systemu Centralnego lub uprawniony operator Systemu.

20) Wykonawca przygotuje procedury dystrybucji Kart e-bilet (przechowywania, zamawiania nowych, rozprowadzania do punktów sprzedaży).

21) Wykonawca zrealizuje zabezpieczenia Kart e-bilet. Karta obca oraz Karta e-bilet niewprowadzona do Podsystemu e-bilet, nie może być użyta w Podsystemie e-bilet. Próba użycia takiej Karty e-bilet powinna być w Systemie Centralnym odnotowana.

22) Zabezpieczenia Karty e-bilet powinny uwzględniać m.in. zastosowanie szyfrowanych kanałów transmisji. Przez szyfrowanie rozumie się tu takie ich przekształcenie podczas zapisu do bazy danych, które uniemożliwi odczyt przez osoby nie posiadające odpowiedniego klucza. Zakres chronionych danych wynika z ustawy o ochronie danych osobowych z dnia 29 sierpnia 1997 r. (t.j. Dz.U. 2016 poz. 922) oraz ustawy o ochronie informacji niejawnych z dnia 5 sierpnia 2010 r. (t.j. Dz.U.2017 poz. 1167.)

23) W ramach wstępnego zaprogramowania Karty e-bilet należy wydrukować na karcie unikalny numer identyfikacyjny (UID) Karty e-bilet.

24) Wstępne zaprogramowanie Kart e-bilet ma umożliwić zarejestrowanie kart jako dopuszczonych do obiegu i ich aktywowanie w momencie sprzedaży.

25) Wykonawca opisze procedury wyjaśniające i weryfikujące na wypadek stwierdzenia niezgodności danych zapisanych na Karcie e-bilet z danymi zapisanymi w bazie Systemu Centralnego w trakcie realizacji projektu.

50

26) Forma merytoryczna i graficzna wszelkich papierowych potwierdzeń z operacji (dowodów płatności) wykonanych na Karcie e-bilet będzie możliwa do edycji w Systemie Centralnym.

27) Zamawiający wymaga, aby System Centralny zachowywał całą historię transakcji, natomiast na karcie e-bilet mają być zapisane informacje o aktualnych transakcjach (wykupionych usługach).

28) Korzystanie z biletu okresowego może polegać na:a) zapisaniu na Karcie e-bilet informacji o zakupie biletu,b) zapisaniu na Karcie e-bilet terminu ważności biletu,c) uznaniu prawa klienta do zakupu biletu okresowego w cenie promocyjnej,d) sprawdzeniu prawa klienta do zakupu biletu okresowego z ulgą,e) kontroli ważności biletów okresowych przez kontrolera w pojeździe.

29) System Centralny powinien umożliwiać zarządzanie magazynem Kart e-bilet. Zarządzanie powinno dzielić się na:a) import Kart e-bilet do głównej bazy danych – wpisywanie wszystkich

fizycznych Kart e-bilet do bazy danych Systemu Centralnego,b) przypisywanie Kart e-bilet do lokalizacji – przypisywanie poszczególnych

Kart e-bilet do lokalizacji (POK), do których zostały one wysłane (np. w celu odbioru Karty e-bilet imiennej),

c) sprawdzanie stanu Kart e-bilet w lokalizacjach – weryfikacja stanu Kart e-bilet przypisanych do danej lokalizacji.

IV.5.4. Biletomaty stacjonarne.IV.5.4.1. W ramach wdrożenia zakupionych zostanie 10 szt. Biletomatów stacjonarnych, w ramach projektu pn. „Czysta komunikacja publiczna – zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz modernizacja infrastruktury towarzyszącej transportowi publicznemu – etap I”. Zostaną one zainstalowane w lokalizacjach o największym natężeniu potoków pasażerskich, gdzie często mógłby występować brak możliwości zakupu biletu w jednym Biletomacie mobilnym zainstalowanym w autobusie przez wszystkich wsiadających pasażerów. Automaty stacjonarne zapewnią możliwość obsługi płatności za pomocą bilonu i banknotów z funkcją wydawania reszty oraz za pomocą płatniczych kart stykowych i zbliżeniowych, z możliwością wprowadzania kodu PIN. Wykonawca odpowiada za uzyskanie odpowiednich uzgodnień i zezwoleń, prawidłowe posadowienie i zabezpieczenie Biletomatów, wykonanie przyłączy energii elektrycznej według projektów posiadanych przez Zamawiającego i uruchomienie Biletomatów.

IV.5.4.2. Podstawowe funkcje Biletomatu stacjonarnego.1) Sprzedaż biletów jednorazowych, czasowych i Kontraktów okresowych wg

obowiązującej taryfy przewozowej oraz zgodnie ze wzorami i zasadami zatwierdzonymi przez Zamawiającego.

51

2) Doładowywanie elektronicznych Kontraktów okresowych, przy wykorzystaniu bezstykowej Karty e-bilet.

3) Obsługa e-portmonetki.4) Informacja pasażerska za pośrednictwem ekranu o układzie linii

komunikacyjnych, objazdach, zamknięciach, obowiązujących taryfach i rozkładzie jazdy z wybranego przystanku; serwis informacyjny będzie prezentowany w postaci plików HTML udostępnianych przez serwer Zamawiającego w postaci dostosowanej do wyświetlania na ekranie Biletomatu stacjonarnego (wielkość 1024pxx768px) oraz do nawigacji za pomocą panelu dotykowego. Funkcjonalność może być wyłączana.

5) Automatyczna diagnoza stanu technicznego Biletomatu z funkcją przesyłania telegramów do centrum obsługi zadedykowanej sieci GSM.

6) Możliwość samodzielnej zmiany przez Zamawiającego wysokości taryf, szaty graficznej sprzedawanych biletów oraz informacji pasażerskiej wyświetlanej na ekranie.

7) Umożliwia obsługę płatności kartami płatniczymi i kredytowymi, czytnik karty płatniczej wraz z niezależną klawiaturą numeryczną umożliwiającą wprowadzenie kodu PIN, spełniający wymagania polskich przepisów dotyczących operacji za pomocą kart płatniczych.

8) Umożliwia obsługę bezkontaktowych kart płatniczych. 9) Umożliwia płatności za pomocą bilonu i banknotów z funkcją wydawania

reszty.10) Umożliwia zapisywanie na karcie biletów zakupionych w sklepie WWW (POP).

IV.5.4.3. Ogólne wymagania techniczne.1) Biletomaty muszą być fabrycznie nowe i jednego typu.2) Konstrukcja Biletomatu powinna spełniać normy bezpieczeństwa CE

obowiązujące w Polsce.3) Biletomat musi mieć własne zabudowane ogrzewanie i wentylację,

uruchamiane czujnikiem, zapewniające prawidłową pracę urządzenia w temperaturach z zakresu -20°C do + 55°C.

4) W przypadku przekroczenia parametrów pracy, mogących spowodować uszkodzenie podzespołów, Biletomat musi się automatycznie wyłączyć.

5) Biletomat powinien gwarantować poprawną pracę do wilgotności powietrza minimum 95%.

6) Biletomat winien być zabezpieczony przed zewnętrznymi zakłóceniami elektromagnetycznymi.

IV.5.4.4. Obudowa Biletomatu stacjonarnego.1) Biletomat musi być przystosowany do montażu na zewnątrz, odporny na

wpływ czynników zewnętrznych.2) Obudowa metalowa zabezpieczona mechanicznie przed skutkami aktów

wandalizmu, wykonana ze stali nierdzewnej o grubości min. 2 mm, malowana

52

proszkowo w kolorze uzgodnionym z Zamawiającym.

3) Biletomat winien być przymocowany do podłoża w sposób uniemożliwiający jego przesunięcie i demontaż przez osoby niepowołane, przy jednoczesnym zachowaniu łatwości wymiany Biletomatu przez służby serwisowe.

4) Wymiary zewnętrzne nie mogą przekraczać następujących wielkości:a) wysokość - 2.100 mm,b) szerokość - 1.100mm,c) głębokość - 700 mm.

5) Masa Biletomatu nie powinna przekraczać 400 kg.6) Wszelkie krawędzie zewnętrzne obudowy muszą być tak ukształtowane, aby

nie powodowały niebezpieczeństwa uszkodzenia odzieży lub zranienia (min. promień zaokrąglenia narożników obudowy powinien wynosić 5 mm), także krawędzie wewnątrz Biletomatu nie mogą powodować niebezpieczeństwa zranienia się przez osoby obsługujące Biletomat;

7) Biletomat musi być wyposażony w oświetlenie załączane zmierzchowo lub przez Moduł sterujący na podstawie zaprogramowanych danych przez Zamawiającego;

8) Operacje wyboru i zakupu biletu winny się odbywać za pośrednictwem kolorowego ekranu dotykowego:

a) rozmiar (przekątna ekranu): - min. 15",b) jasność: - min. 300 cd/m2 ,c) kontrast: - min. 500:1,d) rozdzielczość: - min. 1024 x 768 dpi w 16-to bitowym

trybie kolorów.9) Ekran musi być zabezpieczony dodatkową przeciwodblaskową szybą klasy

przynajmniej P2 chroniącą przed uszkodzeniem; ekran powinien być odporny na warunki atmosferyczne i pogodowe oraz zapewniać dobrą widoczność przy bezpośrednim nasłonecznieniu. Ponadto, musi być odporny na próby uszkodzenia uderzeniami twardymi przedmiotami i na zarysowania.

10) Osłona rynienki odbioru biletu winna być wykonana z bezpiecznego materiału, odpornego na uszkodzenia.

11) W przypadku wlania do rynienki odbioru biletu cieczy, powinna ona spłynąć w dół nie powodując żadnych uszkodzeń Biletomatu.

12) Wszystkie otwory wrzutowe i wyrzutowe muszą być zabezpieczone przed działaniem naturalnych czynników zewnętrznych, jak i przed próbami celowego zniszczenia. Próba celowego zapchania jednego z otworów musi kończyć się unieruchomieniem Biletomatu stacjonarnego (zablokowanie pozostałych otworów i wyświetlenie komunikatu ostrzegawczego) oraz powiadomienie serwisu.

13) Otwory wrzutowe muszą być dodatkowo zabezpieczone przed niekontrolowanym wypadaniem wrzucanych i wyrzucanych przedmiotów (pieniędzy, kart) np. pod wpływem wiatru. Wskazane mechanizmy zamykania otworów wrzutowych i wyrzutowych powinny zostać zamknięte, gdy są one

53

nieużywane celem ograniczenia przedostawania się zanieczyszczeń do wnętrza Biletomatu.

14) Biletomat stacjonarny powinien być wyposażony w monitoring wizyjny, umożliwiający weryfikację operacji wykonywanych przez klienta (np. pobranie gotówki, wyjęcie z czytnika karty bankomatowej, itp.) Zapisy monitoringu powinny być dostępne przez minimum 15 dni i dostęp do nich powinien być możliwy lokalnie (USB) oraz zdalnie przez sieć GSM.

15) Obudowa powinna być tak skonstruowana, aby w każdej chwili można było zdemontować następujące elementy:a) czytnik banknotów,b) czytnik karty płatniczej,c) czytnik karty bezstykowej,

a w ich miejsce założyć maskownice bez konieczności dokonywania dodatkowych wierceń otworów lub innych czynności ingerujących w konstrukcje obudowy. Maskownice muszą być tak zaprojektowane, aby niemożliwe było ich zniszczenie w wyniku aktów wandalizmu.

IV.5.4.5. Interfejs użytkownika Biletomatu stacjonarnego.1) Biletomat stacjonarny powinien umożliwić zaprogramowanie co najmniej 128

różnych rodzajów biletów.2) Wybór biletu okresowego musi się odbywać poprzez podanie okresu jego

obowiązywania.3) Podczas transakcji, Bilety Papierowe muszą być wybierane według klucza:

a) rodzaj biletu;b) liczba biletów.

4) Interfejs powinien być intuicyjny, wspierający szybką sprzedaż biletów. Struktura menu i interfejs powinna być przedstawiona Zamawiającemu w formie projektu, który będzie podlegał akceptacji Zamawiającego.

5) Wielkość pamięci wewnętrznej Biletomatu stacjonarnego musi być tak dobrana, aby w Biletomacie stacjonarnym można było przechowywać co najmniej 2 komplety taryf.

6) Biletomat stacjonarny musi mieć możliwość automatycznego przełączenia taryfy we wskazanym dniu na taryfę kolejną, zaprogramowaną przed dniem wejścia w jej życie.

7) Oprogramowanie musi być tak zaprojektowane, aby umożliwić podczas jednej transakcji wybór kilku Biletów Papierowych różnego rodzaju. Liczba kupowanych biletów powinna zawierać się w przedziale od 1 do 20, bez żadnego ograniczenia co do ich rodzaju. Zamawiający ma prawo definiować liczbę maksymalnie kupowanych biletów podczas jednej transakcji.

8) Po wybraniu największej dopuszczalnej liczby biletów podczas jednej transakcji możliwość wybrania kolejnych biletów zostaje zablokowana.

9) Wybór opcji odbywać się będzie przy pomocy panelu dotykowego ekranu, zabezpieczonego dodatkowo warstwą szyby klasy przynajmniej P2, która do minimum ogranicza możliwość uszkodzenia samego ekranu i panelu dotykowego.

54

10) Oprogramowanie musi umożliwiać wycofanie się z realizacji transakcji w każdym momencie przed zakończeniem płatności.

11) Oprogramowanie podczas wykonywania transakcji zakupu, musi pokazywać przy pomocy jakich nominałów może być zrealizowana transakcja oraz określać jakiej wartości monety lub banknoty winny być wrzucone, aby transakcję zakończyć. Zamawiający musi mieć możliwość definiowania nominałów do zakupu biletów o określonej wartości.

12) Przy przerwie w obsłudze trwającej od 15 do 20 sekund Biletomat stacjonarny przerywa aktualną transakcję, zwraca wpłaconą kwotę i powraca do ekranu głównego. Zamawiający musi mieć możliwość definiowania maksymalnego czasu przerwy w obsłudze.

13) Oprogramowanie Biletomatu musi umożliwić wejście w opcje informacyjną pozwalającą na sprawdzenie przebiegu poszczególnych linii, ostatnich informacji o zamknięciach i zmianie tras oraz sprawdzeniu rozkładu jazdy wybranej linii z wybranego przystanku w układzie takim, jaki jest na stronie www Zamawiającego. Praca w trybie informacyjnym musi być ograniczona czasowo. Maksymalny czas sesji informacyjnej musi być programowany przez Zamawiającego. Wejście w tryb informacyjny nie może być realizowane w momencie dokonywania transakcji zakupu biletu.

14) W czasie kiedy Biletomat stacjonarny nie jest używany, ekran powinien pokazywać wygaszacz ekranu w celu ochrony ekranu przed wypaleniem.

15) W przypadku braku monet do wydawania reszty, Biletomat stacjonarny musi w górnej linii ekranu wyświetlać komunikat: “Zapłata wyłącznie odliczoną gotówką lub kartą płatniczą”.

16) W przypadku zablokowania Biletomatu stacjonarnego lub braku papieru Biletomat stacjonarny musi w górnej linii ekranu wyświetlać komunikat: „Biletomat chwilowo nieczynny”.

17) Oprogramowanie w Systemie Centralnym musi umożliwiać dowolne projektowanie tła i masek poszczególnych ekranów.

18) Oprogramowanie w Systemie Centralnym ma być tak zaprojektowane, aby Zamawiający mógł przygotować maski poszczególnych ekranów w co najmniej 4 językach (polski, angielski, niemiecki, ukraiński). Wprowadzenie poszczególnych języków lub zamiana wcześniej zaprogramowanych musi być możliwa do realizowana samodzielnie przez Zamawiającego.

IV.5.4.6. Obsługa płatności przez Biletomat stacjonarny.1) Biletomat stacjonarny musi obsługiwać transakcje realizowane zarówno przy

pomocy bilonu, jak i banknotów. Biletomat stacjonarny musi być przystosowany do realizacji transakcji przy pomocy kart płatniczych i kredytowych. Nie dopuszcza się jednak transakcji mieszanych gotówkowych i bezgotówkowych.

2) Biletomat stacjonarny musi obsługiwać wszystkie popularne systemy kart płatniczych i kredytowych, zarówno mowa o kartach stykowych (karty z

55

chipem i karty z paskiem magnetycznym), jak i bezkontaktowych (w tym opartych o technologię NFC).

3) Biletomat stacjonarny musi przyjmować monety w 6 nominałach: 10 gr, 20 gr, 50 gr, 1 zł, 2 zł, 5 zł. Musi istnieć możliwość programowego włączenia lub wyłączenia obsługi dowolnego typu monet. Dodatkowo wydawać resztę w min. 5 nominałach.

4) Wrzutnik monet musi być automatycznie otwierany w momencie wyboru funkcji: zakup biletu. W pozostałych przypadkach wrzutnik musi być zamknięty uniemożliwiając włożenie obcych przedmiotów lub wlanie cieczy.

5) Biletomat stacjonarny musi być wyposażony w czytnik monet, umożliwiający odczyt parametrów przyjmowanych monet i ich akceptację lub odrzucenie. Czytnik musi sprawdzać co najmniej 4 różnych parametrów wrzucanych monet.

6) Biletomat stacjonarny musi być wyposażony w moduły wydawania reszty w ilości minimum 5 sztuk o pojemności min. 50 szt. monet każdy - z możliwością automatycznego uzupełnienia stanu monet podczas transakcji lub przez pracownika serwisowego; (magazyny wymiany reszty powinny być uniwersalne, magazyny muszą być zamienne, puste można zamieniać między sobą miejscami i dowolnie wymieniać w przypadku awarii.

7) Dodatkowo Biletomat stacjonarny musi być wyposażony w co najmniej 3 hoppery (zasobnik na monety) o pojemności co najmniej 1000 monet każdy na dowolnie definiowany rodzaj monet. Musi istnieć możliwość napełniania pojemników (w razie konieczności przy Biletomacie stacjonarnym lub w osobnym urządzeniu dostarczonym wraz z Biletomatami stacjonarnymi).

8) W przypadku braku monet do wydawania reszty, Biletomat stacjonarny musi mieć możliwość sprzedaży biletów za odliczoną gotówkę, informując o tym pasażera na ekranie.

9) W przypadku braku monet do wydawania reszty, Biletomat stacjonarny w ciągu 90 sekund wysyła informacje do Systemu Centralnego.

10) W momencie wyrzutu reszty do rynienki, rynienka musi być podświetlona przez okres od 5 do 20 sekund.

11) Bilon przyjmowany podczas transakcji jest kierowany do modułu wydawania reszty, po jego zapełnieniu podawany jest do samozamykającej się kasety końcowej wykonanej ze stali o pojemności min. 5 litrów. Kaseta musi być wyposażona w 2 niezależne zamki: jeden do zamknięcia kasety, drugi do zaryglowania jej w miejscu przeznaczenia. Kaseta powinna posiadać elektroniczny układ rozpoznawania zawierający w sobie niepowtarzalny nr identyfikacyjny kasety, zgodny z numerem zapisanym na tabliczce znamionowej kasety, brak możliwości powtórnego założenia tej samej kasety podczas wymiany kaset, kaseta wyciągana musi zostać zastąpiona inną.

12) W przypadku napełnienia kasety końcowej na monety w 75%, Biletomat stacjonarny w ciągu 90 sekund wysyła informacje do Systemu Centralnego.

56

13) W przypadku całkowitego zapełnienia kasety końcowej na monety, Biletomat stacjonarny musi w ciągu 90 sekund wysłać informacje o tym fakcie do centrum obsługi i automatycznie wyłączyć możliwość zakupu biletu za który klient zamierza zapłacić bilonem. Na ekranie powinien pojawić się komunikat: ”Zapłata wyłącznie kartą płatniczą”.

14) Kaseta końcowa na monety musi zamykać się samoczynnie podczas jej wyjmowania z Biletomatu stacjonarnego. Dostęp do monet zgromadzonych w kasecie musi być możliwy po otwarciu zamka bezpieczeństwa.

15) Czytnik banknotów musi rozróżniać co najmniej 5 nominałów w walucie polskiej (10 zł, 20 zł, 50 zł, 100 zł, 200 zł). Musi istnieć możliwość programowego włączenia lub wyłączenia obsługi dowolnego typu banknotów.

16) Czytnik banknotów musi być wyposażony w kasetę pośrednią na co najmniej 15 banknotów i kasetę końcową na co najmniej 600 banknotów.

17) Banknoty przyjmowane podczas transakcji kierowane są do kasety końcowej.

18) W przypadku napełnienia kasety końcowej na banknoty w 80%, Biletomat stacjonarny w ciągu 90 sekund wysyła informacje do centrum obsługi. W przypadku osiągnięcia przez kasetę końcową na banknoty maksymalnej wartości, Biletomat stacjonarny pracuje dalej przyjmując tylko monety i informując o tym fakcie pasażera przez umieszczenie odpowiedniej wskazówki na ekranie.

19) W przypadku całkowitego zapełnienia kasety końcowej na banknoty, Biletomat stacjonarny musi w ciągu 60 sekund wysłać informacje o tym fakcie do centrum obsługi i zablokować możliwość zakupu za pomocą banknotów oraz wyświetlić na ekranie Biletomatu stacjonarnego komunikat: „Zapłata wyłącznie bilonem lub kartą płatniczą”.

20) Napełnienie monet w trybie serwisowym musi się odbywać poprzez:a) wrzut monet poprzez czytnik monet;b) wymianę hoppera lub jego napełnienie w Biletomacie stacjonarnym;

21) Każdorazowe uzupełnienie monet każdą z metod musi być potwierdzone odpowiednim dokumentem wpłaty, drukowanym przez Biletomat stacjonarny.

22) Przy wymianie kasety końcowej na monety lub kasety końcowej na banknoty każdorazowo musi być drukowany dowód wymiany z odpowiednimi wartościami.

23) W przypadku anulowania transakcji Biletomat stacjonarny musi zwrócić fizycznie te same monety, które zostały przyjęte bezpośrednio przed anulowaniem ostatniej transakcji (zgodnie z zasadą “last in - first out” – ostatnie przyszło, pierwsze wyszło).

24) Biletomat powinien mieć możliwość wprowadzenia fiskalizacji transakcji.

IV.5.4.7. Urządzenie drukujące w Biletomacie stacjonarnym.1) Urządzenie drukujące w postaci minimum 2 niezależnych drukarek

termicznych wyposażonych we własny kontroler z podajnikiem papieru oraz

57

automatyczny nóż obcinający; możliwość wydruku grafiki. Musi istnieć możliwość dowolnego konfigurowania drukarek w czasie pracy Biletomatów stacjonarnych. Jedna drukarka służyć będzie jedynie do drukowania biletów, natomiast druga do drukowania potwierdzeń i raportów.

2) Biletomat stacjonarny będzie drukował bilety o wymiarach:a) szerokość drukowanego biletu powinna wynosić 35 mm (1mm tolerancji).b) drukarki muszą mieć możliwość korzystania z papieru o gramaturze od 80 do

150 g/m2.3) Parametry pracy drukarki muszą być tak dobrane, aby czas wydruku od

momentu zatwierdzenia transakcji do momentu wyrzutu biletu do rynienki nie był dłuższy niż 10 sekund. Rynienka podczas wydawania biletu musi być podświetlona przez okres od 5 do 20 sekund. Czas podświetlenia powinien być programowany przez Zamawiającego.

4) Wielkość każdej rolki musi być tak dobrana aby była możliwość wydruku co najmniej 5 000 biletów bez konieczności wymiany rolki przy gramaturze papieru 100 g/m2.

5) W przypadku braku papieru na jednej z rolek, Biletomat stacjonarny w ciągu 90 sekund wysyła informację do centrum obsługi;

6) W przypadku braku papieru w drukarkach służących do wydruku potwierdzeń, Biletomat stacjonarny przed zrealizowaniem transakcji Doładowania e-portmonetki lub zakupu Kontraktu okresowego musi wyświetlić informację, że nie jest w stanie wydrukować potwierdzenia transakcji i dać możliwość realizacji transakcji lub wycofania się z niej klientowi.

7) W przypadku braku papieru w drukarkach służących do wydruku biletów, Biletomat stacjonarny powinien niezwłocznie (maksymalnie po 10 sekundach), w górnej linii ekranu wyświetlać komunikat: „Biletomat chwilowo nieczynny”.

8) Papier zabezpieczony  co najmniej na dwa wybrane (w terminie późniejszym) sposoby, tj.: hologram w formie paska przebiegającego wzdłuż taśmy na nieaktywnej stronie papieru, włókna świecące w świetle UV, gilosz, zastosowanie farby UV lub farby sekretnej, mikrodruk. Papier zabezpieczony dostarcza Zamawiający.

IV.5.4.8. Doładowanie e-portmonetki, zakup i sprawdzenie Kontraktu okresowego w Biletomacie stacjonarnym.1) Biletomat stacjonarny musi być wyposażony w czytnik do obsługi kart

bezkontaktowych spełniających wymagania opisane w pkt. IV.5.3. Karta e-biletu.

2) Czytnik musi być wyposażony w kieszeń służącą do przytrzymywania Kart e-bilet.

3) Czytnik wyposażony w min. 4 kieszenie na karty SAM.4) Czytnik obsługujący wizualną sygnalizację operacji odczytu i zapisu danych

na Kartach e-bilet. 5) Biletomat stacjonarny musi zapisywać (kodować) Kontrakty okresowe, w

formie elektronicznej zgodne z obowiązującą taryfą.6) Biletomat stacjonarny musi Doładowywać e-portmonetkę.

58

7) Kupujący musi mieć możliwość dowolnego wyboru biletu okresowego, z zastrzeżeniem, że na Karty e-bilet imienne mogą być ładowane jedynie bilety imienne, na Karty e-bilet na okaziciela jedynie bilety na okaziciela.

8) Biletomat stacjonarny w momencie przyłożenia Karty e-bilet lub innych nośników dopuszczonych do użytkowania w Podsystemie e-bilet musi wyświetlać zawartości Karty tj. zakupionych biletów lub Kontraktów oraz automatycznie przejść do ekranów dedykowanych dla sprzedaży biletów okresowych.

9) Kupujący określa datę rozpoczęcia ważności biletu, natomiast data zakończenia ważności biletu ustalana jest automatycznie na bazie rodzaju wybranego biletu.

10) Zapis transakcji na karcie e-bilet może nastąpić po przyjęciu zapłaty za wybrany bilet.

11) Biletomat stacjonarny musi kodować na karcie e-bilet bilety zakupione przez stronę WWW (POP).

12) W przypadku kodowania biletów zakupionych przez stronę WWW klient wybiera na ekranie dotykowym opcję „Kodowanie biletów WWW” oraz zbliża Kartę e-bilet do czytnika. Biletomat stacjonarny odczytuje numer Karty e-bilet i za pomocą modułu komunikacyjnego łączy się z Systemem Centralnym w celu sprawdzenia, czy dla danego numeru Karty e-bilet został zakupiony i opłacony bilet:a) w momencie pozytywnej weryfikacji automat zapisuje Kontrakt na Karcie e-

bilet i informuje klienta o pozytywnym zakodowaniu biletu w postaci odpowiedniego komunikatu.

b) w przypadku braku biletu w Systemie Centralnym Biletomat stacjonarny informuje o tym fakcie klienta w postaci odpowiedniego komunikatu.

13) Biletomat stacjonarny musi mieć możliwość wydrukowania potwierdzenia transakcji z numerem Karty e-biletu, na jaki zostało dokonane naładowanie, rodzajem wybranego biletu, terminem ważności biletu, numerem Biletomatu, dokładną datą wydania biletu oraz ceną biletu.

14) W pamięci Biletomatu stacjonarny musi być przechowywana lista Kart e-biletu zastrzeżonych tak, aby niemożliwe było Doładowanie e-portmonetki i zakup Kontraktu okresowego na Karcie e-bilet. Lista ta musi być uzupełniana online przez sieć GSM, nie rzadziej niż co 1 godzinę oraz na zajezdni przez sieć Wi-Fi .

15) Biletomat stacjonarny musi umożliwić sprawdzenie okresu ważności i rodzaju elektronicznego biletu okresowego naładowanego na Karcie e-bilet.

IV.5.4.9. Zasilanie Biletomatu stacjonarnego.1) Zasilanie Biletomatu stacjonarnego z sieci 230V prądu zmiennego 50 Hz z

podtrzymaniem pracy za pomocą baterii akumulatorów w razie braku napięcia. Pobór mocy nie wyższy niż 200 W, w standardowym trybie pracy lub 1000 W przy włączonym ogrzewaniu.

2) W przypadku zaniku napięcia zasilającego Biletomat stacjonarny musi zakończyć ostatnią transakcję, zapisać wszystkie niezbędne dane i

59

automatycznie się wyłączyć. W przypadku pracy w trybie informacyjnym, także automatycznie się wyłączyć.

3) W przypadku zaniku napięcia zasilającego Biletomat stacjonarny w ciągu 90 sekund wysyła informacje za pomocą sieci GSM do Systemu Centralnego.

4) Wszystkie Biletomaty stacjonarne powinny zostać wyposażone w zabezpieczenia różnicowo prądowe i przeciwprzepięciowe nie gorsze niż wyłącznik B16A/0,03/2 1-f różnicowo-prądowy oraz ochronnik przepięć BY1-B/1 B+C 65kA na szynie TH.

5) Biletomaty stacjonarne muszą być odporne na wszystkie zakłócenia wywoływane przez biegnące w pobliżu linie elektryczne.

IV.5.4.10. Zabezpieczenia Biletomatu stacjonarnego.1) Biletomat stacjonarny powinien posiadać klasę ochrony minimum IP53, przy

czym dla wlotu monet i banknotów oraz rynienki wylotowej min. IP33.

2) Biletomat stacjonarny musi być zabezpieczony alarmem akustycznym i świetlnym w przypadku próby otwarcia pokryw przeglądowych przez osoby niepowołane lub wprowadzenia niewłaściwego PIN-u, w przypadku otwarcia pokrywy przez pracownika serwisowego.

3) Otwarcie pokrywy w celach obsługowo-naprawczych powinno być poprzedzone identyfikacją pracownika serwisu przy pomocy karty serwisowej.

4) Po otwarciu pokrywy przez pracownika serwisu, musi on zalogować się w Systemie poprzez podanie kodu PIN.

5) Otwarcie pokrywy bez wcześniejszego zalogowania się przy pomocy elektronicznej karty serwisowej lub nie podanie kodu PIN, w ciągu 15 sekund spowoduje uruchomienie alarmu.

6) Zabezpieczenie przed dostępem do wnętrza minimum 3 (trzema) mechanizmami zabezpieczającymi dostęp w tym 2 (dwoma) zamkami patentowymi wraz z zabezpieczeniem drzwi (klapy) alarmem i możliwością wykorzystania zainstalowanego modemu GSM do zdalnego powiadomienia. Drzwi frontowe automatu powinny posiadać min. 4 punktowe ryglowanie.

7) Biletomat stacjonarny powinien być wyposażony w modem GSM, który przeznaczony będzie do transmisji danych, o których mowa w specyfikacji.

8) Obudowa powinna być tak skonstruowana, aby dojście do określonych elementów Biletomatu stacjonarnego można było zhierarchizować tzn. że pracownik serwisowy zbierający dane lub wgrywając nowy program nie może mieć dojścia do modułów wydawania reszty, zasobników z monetami, a pracownik zbierający gotówkę lub uzupełniający monety nie może mieć dojścia do urządzeń sterujących. Zamawiający ma prawo nadać w sposób dowolny uprawnienia poszczególnym grupom pracowników obsługi; Każde zdarzenie otwarcia pokrywy przeglądowej musi być rejestrowane i wysyłane do Systemu Centralnego. Wielopoziomowość uprawnień realizowana będzie z pomocą identyfikatorów użytkowników i kodów PIN.

60

9) Kasety z monetami, moduły do wydawania reszty, hoppery i kaseta z banknotami muszą być zabezpieczone dodatkowym zamkiem patentowym (każdy zamek inny rodzaj klucza) - każdy Biletomat stacjonarny musi posiadać taki sam zestaw kluczy.

10) W przypadku otwarcia pokryw przeglądowych zarówno przez osoby niepowołane jak i osoby uprawnione, Biletomat stacjonarny w ciągu 10 sekund wysyła informacje do Systemu Centralnego.

11) Moduł pamięci musi posiadać niezależne zasilanie tak, aby zabezpieczyć wszystkie dane konfiguracyjne, dane o obsłudze sprzętu, wyjęciu kaset i informacje o dokonanych transakcjach od ostatniego zrzutu danych w razie całkowitego zaniku zasilania zewnętrznego.

12) Biletomat stacjonarny winien rejestrować dane o dokonanych transakcjach i stanie poszczególnych komponentów. Dane te przechowywane będą w:a) pamięci wewnętrznej Biletomatu stacjonarnego,b) Systemie Centralnym (wysyłane na bieżąco po każdej transakcji).Pozwoli to na odpowiednie zabezpieczenie danych przed ich utratą. Dodatkowo, w przypadku braku połączenia z Systemem Centralnym Biletomat stacjonarny powinien nadal umożliwić funkcjonalność dostępną w trybie offline, w tym:c) sprzedaż Doładowań,d) sprzedaż biletów jednorazowych i okresowych,e) serwis pasażerski.Po przywróceniu połączenia dane zapisane w trybie offline powinny zostać automatycznie wysłane do Systemu Centralnego. Powinien być możliwy do zdefiniowania limit kwotowy operacji wykonywanych w trybie offline.

13) Biletomat stacjonarny musi być wyposażony w czujnik ruchu wraz z Oprogramowaniem pozwalającym na stopniowe „usypianie” Biletomatu stacjonarnego podczas jego nieaktywności zmniejszając pobór mocy Biletomatu stacjonarnego. Zastosowany czujnik ma „rozpoznawać” i nie reagować na osoby przechodzące koło Biletomatu stacjonarnego, a aktywować wyłączone moduły dopiero po podejściu (parametr konfigurowalny) pasażera do Biletomatu stacjonarnego.

IV.5.4.11. Oprogramowanie Biletomatu stacjonarnego.1) Obsługa Biletomatu stacjonarnego i wszelka wymiana danych musi być

realizowana za pośrednictwem sieci GSM, a w razie awarii przy pomocy nośników fizycznych.

2) Bazą do obsługi sieci Biletomatów stacjonarnych powinien być System Centralny.

3) Interaktywne prowadzenie sprzedaży oraz realizacja pozostałych usług powinna być realizowana przy pomocy wyświetlanych na ekranie aktywnych pól wyboru. Obsługa sprzedaży oraz informacja w min. 4 językach (polski, angielski, niemiecki, ukraiński).

4) Oprogramowanie powinno umożliwiać zapisanie aktualnej konfiguracji Biletomatu stacjonarnego

61

i umożliwiać jej odtworzenie. Posługiwanie się Oprogramowaniem powinno być bezpieczne dla Biletomatu stacjonarnego, tzn. nie powodować jego awarii.

5) Do przenoszenia danych (danych finansowych i pozostałych danych), w razie braku połączenia GSM musi istnieć możliwość zastosowania nośników w postaci karty pamięci lub nośnika wykorzystującego złącze USB (np. pendrive) działających w ogólnodostępnym systemie plików.

6) System operacyjny, pamięć i Oprogramowanie zainstalowane w Biletomacie stacjonarnym muszą zapewniać możliwość zapamiętania całej zawartości serwisu (mowa tu o serwisie informacyjnym) bez konieczności korzystania z zewnętrznego połączenia w trybie on-line, w trakcie udzielania informacji.

7) Aktualizacja serwisu będzie odbywać się zarówno w trybie wymiany danych przy zastosowaniu nośników fizycznych (patrz powyżej), jak i przy pomocy sieci GSM.

8) Zamawiający będzie aktualizował treści serwisu we własnym zakresie z dowolną częstotliwością.

9) Rejestracja i sporządzanie raportów wszystkich transakcji, rozliczenie (wpłaconych i wydanych) środków płatniczych, rejestracja dostępu służb serwisowych, rejestracja stanu technicznego Biletomatu stacjonarnego powinna być dostępna (lub przekazywanie tych danych) drogą radiową za pomocą sieci GSM oraz nośników wymienionych powyżej.

10) Format danych generowanych przez Biletomat stacjonarny (szczegółowe rozliczenie transakcji) zgodny z formatem wymaganym przez Zamawiającego lub dostarczenie Oprogramowania do konwersji danych z Biletomatu do formatu jaki wymaga Zamawiający.

11) Zabezpieczenie danych konfiguracyjnych i informacji o dokonanych transakcjach w razie całkowitego zaniku zasilania zewnętrznego.

12) Biletomat musi być wyposażony w niekasowalny rejestr wszystkich zdarzeń (obsługa biletów, kart, wydawanie i przyjmowanie gotówki). Wszelkie zrzuty danych będą powodowały przeniesienie zrzucanych danych do wewnętrznego archiwum dyskowego niedostępnego z poziomu pracowników standardowej obsługi eksploatacyjnej.

13) Polski interfejs użytkownika Oprogramowania do obsługi i serwisowania Biletomatu stacjonarnego.

14) Oprogramowanie powinno posiadać intuicyjny interfejs, charakteryzować się łatwością i prostotą obsługi.

15) Oprogramowanie musi umożliwiać wejście w tryb czuwania Biletomatu po zakończeniu ostatniej transakcji, przy zdefiniowanej przerwie w jego pracy trwającej określony czas (np. 30 sekund). W/w Oprogramowanie musi być konfigurowalne w zakresie wyboru poszczególnych modułów Biletomatu jakie mają być przełączone w tryb czuwania i w jakiej kolejności oraz ustawień (odległość, itp.) związanych z aktywizacją Biletomatu.

IV.5.4.12. Funkcje serwisowe Biletomatu stacjonarnego.

62

1) W pamięci urządzenia muszą być przechowywane wszystkie rozliczenia oraz wszystkie logowania obsługi serwisowej do Biletomatu stacjonarnego (min. okres przechowywania danych to 12 miesięcy).

2) Biletomat stacjonarny musi mieć możliwość zapisu w pamięci dodatkowej (pośredniej) min. 200 ostatnich rozliczeń pracy.

3) Powinna być możliwość podglądu i wydruku aktualnego stanu kaset końcowych, modułów wymiany i wydawania monet, sprzedaży, itp.

4) W funkcji serwisowej musi istnieć możliwość uzupełnienia stanu monet służących do wydawania reszty. Funkcja ta musi być zakończona wydrukiem pokwitowania.

5) Musi być zapewniona możliwość wyrzucenia wszystkich monet z pojemników do wydawania reszty do kasety końcowej.

6) Funkcje serwisowe powinny być dostępne dopiero po zalogowaniu się i identyfikacji użytkownika w Biletomacie stacjonarnym. Wielopoziomowość uprawnień realizowana będzie z pomocą identyfikatorów użytkowników i kodów PIN.

7) Biletomat stacjonarny powinien zapisywać dane (ID serwisanta oraz data i godzina) każdorazowego zameldowania się serwisanta i rejestrować wszystkie jego czynności.

8) Biletomat stacjonarny powinien posiadać rozbudowany zestaw funkcji diagnostyczno-serwisowych: automatyczne uaktualnianie (update) Oprogramowania sterującego pracą Biletomatu stacjonarnego, automatyczne uaktualnianie zmian taryfowych; ekspozycja oraz wydruk i zapis na nośniku stanu Biletomatu stacjonarnego i przebiegu pracy; pokazanie historii rozliczeń; historii transakcji, wydruki testowe, wymiana kaset i funkcje rozliczeniowe, funkcje testowe dla wszystkich komponentów, wydruki kontrolne; funkcje serwisowego napełniania magazynów wymiany monet.

9) Obsługa serwisowa będzie wykonywana przez pracowników wyłonionego podwykonawcy w zakresie wynikającym z przydzielonych uprawnień.

10) Biletomat stacjonarny powinien posiadać oświetlenie wnętrza oraz wewnętrzne gniazdo wtykowe 230VAC/50Hz dla potrzeb prac serwisowych. Wewnątrz Biletomatu stacjonarnego powinien znajdować się rozkładany blat na klawiaturę i narzędzia.

11) W trakcie prac serwisowych powinna istnieć możliwość odchylenia do wewnątrz ekranu Biletomatu stacjonarnego. Konieczność wprowadzenia zmian (obsługa Biletomatu stacjonarnego) w Oprogramowaniu i konfiguracji Biletomatu stacjonarnego wykonywana za pomocą aplikacji serwisowej.

12) Po wejściu obsługi w tryb pracy serwisowej, serwisant może sprawdzić status poszczególnych podzespołów uzyskując określoną informację na ekranie Biletomatu stacjonarnego;

13) Wymiana danych odbywać się będzie za pośrednictwem wewnętrznej aplikacji serwisowej lub klawiatury dołączanej. W drugim przypadku wewnątrz Biletomatu stacjonarnego musi być wygospodarowane miejsce, umożliwiające jej postawienie lub podczepienie.

63

14) W trybie serwisowym możliwe jest sprawdzenie stanów magazynków na monety, hopperów i kasety na banknoty.

64

Tabela 1. Lokalizacja Biletomatów stacjonarnych.

Lokalizacje dla Biletomatów stacjonarnych

L.p.

Nazwa przystanku autobusowego Kierunek Numery działek* Arkusz mapy

Obręb

1. Opole, 1 Maja – Dworzec Główny, 02 ul. Reymonta 58/2, 65, 66/1 49 Opole2. Opole, Ozimska - Dubois, 04 ul. Plebiscytowa 46, 76 (OUW) 48 Opole

3. Opole, Plac Kopernika - Pętla, 01 ul. Sienkiewicza 101/2, 10079, 76/8

4244 Opole

4. Opole, Sosnkowskiego – Politechnika, 19 ul. Okulickiego 14/4, 9/19, 8/3, 7/3, 74/1, 9/20, 9/18 17 Opole

5.

Opole, Prószkowska – Politechnika, 07 (dawna nazwa: „Opole, Prószkowska - Kościół, 07”)UWAGA!W tej lokalizacji został już wykonany przepust kablowy dla zasilania Biletomatu i Tablicy DIP(w ramach budowy ronda w 2016 roku).

Centrum 25/8, 25/13 (OUW) 39 Szczepanowice

6. Opole, Książąt Opolskich - Rondo, 06 ul. Nysy Łużyckiej 6/11, 6/12 42 Opole7. Opole, Sosnkowskiego – Wiejska, 04 ul. Horoszkiewicza 1317/42, 1317/43, 1337/1 22 Gosławice8. Opole, Dambonia - Pętla, 02 Centrum 89/11, 89/10 34 Szczepanowice

9.

Opole, Niemodlińska – Koszyka, 03UWAGA!W tej lokalizacji zostanie (lub został już) wykonany przepust kablowy dla zasilania Biletomatu i Tablicy DIP(w ramach przebudowy ulicy Niemodlińskiej w 2017 roku).

Centrum1448/35,8/10 (OUW)

2638 Półwieś Szczepanowice

10. Opole, Piastowska, 03 ul. Spychalskiego 38, 12/6, 11/20, 12/4, 11/29, 8, 11/19, 11/17 43 Opole

65

* - wśród wymienionych numerów działek znajdują się działki, na których zainstalowane zostaną przedmiotowe Biletomaty oraz działki, przez które przebiegać będą wewnętrzne linie zasilające (WLZ) dla zasilania tych urządzeń. Numery działek dla każdej lokalizacji odpowiadają numerom wymienionym w Zgłoszeniach Budowy Obiektów (zgłoszenia do Urzędu Miasta Opola oraz do Urzędu Wojewódzkiego). Zgłoszenia do Urzędu Wojewódzkiego oznaczono (OUW).

66

IV.5.4.13. Prace projektowe, roboty budowlano-montażowe i elektryczne.Wykonawca zobowiązany jest do wykonania następujących prac: 1) Opracowanie harmonogramu robót w uzgodnieniu z Zamawiającym. 2) Aktualizację map dla celów projektowych w zakresie niezbędnym do realizacji

inwestycji. 3) Opracowanie niezbędnej dokumentacji projektowej, uwzględniającej warunki

przyłączenia do sieci energetycznej, a także uzyskanie akceptacji Zamawiającego w/w dokumentacji. Zamawiający posiada dokumentację projektową przyłączy energii elektrycznej.

4) Uzyskanie niezbędnych dla realizacji inwestycji uzgodnień i pozwoleń. 5) Wykonanie przyłączy energii elektrycznej.

UWAGA! W 4 lokalizacjach (na przystankach o nazwach: „Opole, Niemodlińska - Koszyka, 03”, „Opole, Niemodlińska - Koszyka, 04”, „Opole, Niemodlińska - Szkoła, 07”, „Opole, Prószkowska - Politechnika, 07”) w ramach prowadzonych wcześniej prac inwestycyjnych („Budowa ronda na skrzyżowaniu ulic Prószkowskiej, Krapkowickiej i Chmielowickiej w 2016 roku” oraz „Przebudowa ulicy Niemodlińskiej w 2017 roku”) zostały wykonane (lub wkrótce zostaną wykonane) przepusty kablowe (rury osłonowe) dla zasilania Biletomatów i/lub Tablic DIP, które planowane są do montażu na danym przystanku.

6) Dostawę i montaż Biletomatów stacjonarnych wraz z przyłączeniem ich do sieci energetycznej oraz doprowadzeniem do pełniej sprawności funkcjonalnej.

7) Opracowanie geodezyjnej inwentaryzacji powykonawczej. 8) Opracowanie technicznej dokumentacji powykonawczej.

IV.6. Wyposażenie autobusówIV.6.1. Wykonawca w ramach budowy Systemu wyposaży autobusy w Moduły Pokładowe Systemu, na które składają się następujące urządzenia.1) Router z modułem GSM i Wi-Fi, antenami zewnętrznymi i okablowaniem – 95

szt.2) Komplet pozostałych urządzeń peryferyjnych z okablowaniem

współpracujących z Autokomputerem, Sterownikiem e-biletu, Kasownikami, Biletomatem mobilnym, routerem, itp. potrzebnych do obsługi Systemu zapewniających w pełni funkcjonalne działanie – 95 szt.

3) Sterownik e-biletu – 95 szt.4) Kasownik dwufunkcyjny – 310 szt.5) Biletomat mobilny – 95 szt.IV.6.1.1. Moduł Pokładowy Autobusu.Moduł Pokładowy Autobusu składać się będzie z 1 szt. routera z modułem GSM i Wi-Fi, antenami zewnętrznymi i okablowaniem, 1 szt. Biletomatu mobilnego, 1 szt. Sterownika e-biletu, 4 szt. Kasowników w autobusie MEGA 18 m i 3 szt. Kasowników w pozostałych pojazdach oraz kompletu urządzeń peryferyjnych z okablowaniem. Zamawiający dopuszcza wykorzystanie Systemów Pokładowych

67

Autobusu do transmisji danych, o ile ich parametry zapewnią właściwą wydajność i dostępność Systemu i Modułów Pokładowych Systemu (dotyczy to wyłącznie pojazdów docelowo wykorzystywanych przez Operatora) i w takim przypadku dostarczenie odpowiednio mniejszej ilości routerów z modułem GSM i Wi-Fi, antenami zewnętrznymi i okablowaniem, o liczbę wykorzystanych urządzeń transmisyjnych Systemów Pokładowych Autobusu.

IV.6.1.2. Moduły Pokładowe Systemu.Moduły Pokładowe Systemu zostaną zainstalowane w 95 autobusach Operatora. Wykonawca, zobowiązuje się do przeniesienia części dostarczonych i zainstalowanych w autobusach Modułów Pokładowych Systemu oraz ich zainstalowania i wdrożenia w Systemie w kolejno dostarczanych nie więcej niż 33 fabrycznie nowych autobusów Zamawiającego, w terminie do dnia 30 listopada 2019 r. Przeniesienie części Urządzeń odbywać się będzie zgodnie z harmonogramem ustalonym przez Zamawiającego w porozumieniu z Wykonawcą (Załącznik nr 5 do OPZ planowane wymiany autobusów). Lista autobusów wraz z wyposażeniem stanowi Załącznik Nr 2 do OPZ.

IV.6.2. Parametry, konstrukcja i instalacja Urządzeń.1) routery z modułami GSM i Wi-Fi, switche i inne urządzenia zastosowane przy

budowie Systemu muszą być urządzeniami dedykowanymi do pracy w warunkach panujących w autobusie podczas realizacji zadań przewozowych.

2) Wykonawca dostarczy wszystkie niezbędne do jego działania elementy tj.: anteny, przewody, zasilacze i inne materiały instalacyjne.

3) Wszystkie elementy muszą być fabrycznie nowe i przeznaczone do pracy w środkach transportu publicznego.

4) Aktywne karty SIM dla autobusów zapewnia Operator poprzez podpisanie stosownej umowy z operatorem GSM. Koszty transmisji do i z autobusów pokrywa Operator.

5) Wszystkie elementy Systemu pokładowego autobusu wymienione w OPZ i dostarczone przez Wykonawcę muszą być połączone ze sobą magistralą właściwą do środowiska pracy siecią LAN (Ethernet) lub poprzez port szeregowy RS-485. Wymagane jest, by zastosowane rozwiązanie w zakresie wymiany danych pomiędzy urządzeniami pokładowymi gwarantowało bezpieczny, pewny i niezakłócony przepływ informacji pomiędzy urządzeniami pokładowymi w Taborze Zamawiającego.

IV.6.3. Wymagania techniczne i funkcjonalne dla Urządzeń w autobusach.IV.6.3.1. Sterownik e-biletu.

68

Zainstalowane urządzenie sterujące Podsystemu e-bilet musi realizować funkcje w zakresie zarządzania na poziomie lokalnym, w myśl zdecentralizowanej struktury Systemu.Zalecana jest integracja programowa z użytkowanym przez Operatora Autokomputerem. W eksploatowanych autobusach (41 szt.) znajdują się Autokomputery. Zamawiający preferuje jeden punkt obsługi dla kierowcy (Autokomputer) oraz wymianę danych pomiędzy Pokładowym Systemem Autobusu i Modułem Pokładowym Systemu, tak aby do wymiany danych i funkcjonowania Systemów pokładowych autobusu wystarczała jedna karta SIM i jedno urządzenie GPS obsługiwane przez Autokomputer. Wymiana danych z Systemem Centralnym odbywać się będzie poprzez sieć GSM (APN), natomiast zasadniczy zrzut danych przy wykorzystaniu modułu transmisji danych Wi-Fi na zajezdni. System Centralny zapewni nadzór nad poprawnością działania oraz aktualnością danych i Oprogramowania urządzeń, a ponadto dostęp online do danych o położeniu autobusu, danych eksploatacyjnych autobusów jak i w zakresie bezpieczeństwa (przycisk antynapadowy, wgląd do kamer monitoringu).

IV.6.3.1.1. Parametry, konstrukcja, instalacja i ergonomia Sterownika e-biletu. 1) Sterownik e-biletu ma być zamontowany w kabinie kierowcy. Wymaga się

jednorodnej konstrukcji z ekranem i klawiaturą dotykową o przekątnej min 7” (interfejsem kierowcy). Rozdzielczość minimum 800 na 600 punktów.

2) Wymagany jest ekran dotykowy typu pojemnościowego lub IR, odpowiednio zabezpieczony min. 3 milimetrową szybą wandaloodporną.

3) Fabrycznie nowy, dedykowany do pracy w warunkach panujących w autobusie podczas realizacji zadań przewozowych.

4) Komunikacja z elementami peryferyjnymi poprzez sieć Ethernet.5) Powinien pracować bezawaryjnie w zakresie temperatur od -20 do +50 stopni

Celsjusza.6) Wymagany otwarty system operacyjny.7) Znamionowe napięcie zasilania: 24V; Zakres napięcia zasilania 24V +/- 30 %.

IV.6.3.1.2. Funkcjonalność Sterownika e-biletu.Sterownik e-biletu powinien:1) umożliwiać pracę w trybie autonomicznym dla autobusów, gdzie brak jest

Autokomputera, a taka sytuacja może mieć miejsce w okresie przejściowym (przed dostawą ostatniej transzy autobusów) oraz w trybie integracji z Autokomputerem;

2) w przypadku braku łączności Sterownika e-biletu z serwerem, odchyłka autobusu względem realizowanego teoretycznego rozkładu jazdy powinna być

69

obliczana przez sam Sterownik e-bilet – praca w trybie autonomicznym. Odchyłka powinna być obliczana na podstawie porównania aktualnych informacji o czasie, przebytej drodze i współrzędnych GPS z danymi rozkładowymi zapisanymi w pamięci. Opisane podejście umożliwia kontrolę punktualności po stronie kierowcy bez względu na stan łączności z autobusem;

3) być bezobsługowy; 4) umożliwiać diagnostykę urządzeń pokładowych współpracujących z

Podsystemem e-bilet i zapisywać w raporcie występujące stany awaryjne;

5) w sposób czytelny informować kierowcę autobusu o nieprawidłowościach w działaniu urządzeń pokładowych e-biletu na wyświetlaczu LCD i poprzez sygnał dźwiękowy;

6) sterować pracą urządzeń pokładowych: kasowników dwufunkcyjnych, Biletomatów mobilnych;

7) za jego pośrednictwem synchronizować wewnętrzne zegary wszystkich pozostałych urządzeń Systemów Pokładowych Autobusów, z zewnętrznym wzorcem czasu z wskazanego przez Zamawiającego serwera NTP lub Autokomputera. Wymagane jest utrzymanie jednolitego czasu we wszystkich Urządzeniach;

8) rejestrować dane o pozycji autobusu (współrzędne geograficzne) na podstawie odczytu z odbiornika GPS. Dokładność odczytu pozycji nie gorsza niż 10 metrów;

9) automatycznie rozpoznawać pozycję, zmiany przystanków, strefy taryf, itp.;10) zapewniać, że dostęp do ustawień Sterownika e-biletu może posiadać tylko

i wyłącznie pracownik mający odpowiednie uprawnienia dzięki którym dokona autoryzacji w Systemie;

11) przekazywać on-line dane o awariach do i z serwera, za pośrednictwem routera z modułami GSM i Wi-Fi. Gromadzić i przekazywać danych o operacjach dokonywanych przez kierowcę lub inne upoważnione osoby (zmiany konfiguracyjne, wszystkie operacje wykonywane w kasownikach, wszystkie zdarzenia serwisowe -logi, itp.). Powyższe dane w pełnej treści mają być przekazywane do Systemu Centralnego po zjeździe autobusu do zajezdni z wykorzystaniem systemu łączności lokalnej (Wi-Fi);

12) umożliwiać przekazywanie za pomocą routera z modułami GSM i Wi-Fi danych o liczbie pasażerów i rodzaju skasowanych biletów, transakcji, odczycie GPS z datą i czasem dokonania odczytu, itp.;

13) odbierać dane z plikami konfiguracyjnymi, pobierać i przetwarzać elektroniczne rozkłady jazdy z Oprogramowania do projektowania rozkładów jazdy (bezpośrednio lub poprzez interfejs programowy Systemu Centralnego, na żądanie – w dowolnym momencie oraz w sposób automatyczny – zgodnie z zadanym harmonogramem;

14) przechowywać w pamięci, minimum aktualny rozkład jazdy na wszystkie typy dni i jeśli występuje także przynajmniej jeden rozkład przyszły. Ponadto, System Centralny musi umożliwiać zdalne sprawdzenie aktualności rozkładu

70

jazdy, a w przypadku wykrycia sytuacji braku jego aktualności umożliwić wysłanie aktualnego rozkładu jazdy do Sterownika e- biletu w dowolnym momencie;

15) zapisywać numery Kart e-bilet zastrzeżonych w pamięci lokalnej Urządzenia (Sterownika e-biletu lub kasownika autobusowego). Zapis tych informacji następuje online w sposób scentralizowany (bez konieczności dokonywania wpisów osobno w każdym urządzeniu, czarne i białe listy itp.);

IV.6.3.2. Kasowniki do autobusów komunikacji miejskiej. Kasownik, poza kasowaniem Biletów Papierowych, jest urządzeniem z wbudowanym czytnikiem zbliżeniowym kart bezkontaktowych zgodnych z ISO/IEC 14443 typ A i B umożliwiającym współpracę z kartami MIFARE DESFire m.in. przez „kasowanie” biletów z e-portmonetki oraz sprawdzanie ważności biletu okresowego. Oprogramowanie kasownika posiadać musi graficzny interfejs użytkownika i umożliwiać Oprogramowanie m.in. w językach: polskim, angielskim, niemieckim lub ukraińskim.

IV.6.3.2.1. Opis wymagań, jakie musi spełnić Kasownik dwufunkcyjny (Kasownik biletów elektronicznych i Biletów Papierowych).1. Kasownik dwufunkcyjny powinien:

1) współpracować ze Sterownikiem e-biletu; 2) być urządzeniem dedykowanym do pracy w środkach transportu

publicznego;3) być urządzeniem mogącym dokonywać zapisu i odczytu kart zbliżeniowych

zgodnych z normą ISO/IEC 14443 typ A i B. Kasownik ma umożliwić odczyt, zapis i przetwarzanie danych dotyczących biletów zapisanych na karcie bezkontaktowej, czytnik kart bezkontaktowych akceptować musi karty z numerem unikatowym zapisanym na ID 7 bajtowym;

4) posiadać otwarty system operacyjny;5) realizować pełną wymianę potrzebnych informacji, w tym z „białą” i

„czarną” listą Kart e-bilet;6) posiadać wytrzymałość nie mniejsza niż IP=20, zgodnie z normą PN-EN

60529:2003; 7) posiadać wbudowany, podświetlany kolorowy wyświetlacz dotykowy LCD o

przekątnej min. 7” i rozdzielczości min. 800 na 480 pikseli, na którym wyświetlane będą informacje dla pasażera o ilości punktów zapisanych na karcie bezkontaktowej (w e-portmonetce) oraz o terminie ważności biletu okresowego, po dotknięciu odpowiedniego wirtualnego przycisku na wyświetlaczu. Ze względu na środowisko pracy kasownika i pożądaną odporność na uszkodzenie Zamawiający wymaga zastosowania ekranu LCD zabezpieczonego min. 3 milimetrową szybą hartowaną;

71

8) weryfikować rodzaj biletu zapisanego na karcie bezkontaktowej w odniesieniu do zadania, które w danym momencie wykonuje autobus. Jeżeli na Karcie e-bilet nie ma Kontraktu okresowego spełniającego kryteria, to kasownik musi sprawdzić, czy na Karcie e-bilet znajduje się odpowiednia ilość punktów niezbędnych do pobrania jednorazowej opłaty za przejazd i dokonać ich pobrania. W innym przypadku musi sygnalizować brak prawa do przejazdu (brak właściwego Kontraktu okresowego lub brak wystarczającej liczby punktów);

9) umożliwiać informowanie pasażera o czasie i bieżącej dacie oraz blokadzie kasownika, poprzez przedstawienie informacji na wyświetlaczu LCD,

10) posiadać wyświetlacz LCD z informacją dla pasażera, który musi być podświetlany w technologii LED,

11) być wyposażony w dotykową klawiaturę wirtualną na ekranie LCD dostępną dla pasażera od frontu kasownika, dla wyboru taryfy kasowania oraz do sprawdzenia ważności Kontraktu okresowego na Karcie e-bilet. Wszystkie programowane przyciski muszą być zdefiniowane na ekranie dotykowym;

12) generować podczas operacji kasowania sygnały akustyczne i opcjonalnie uzgodnione z Zamawiającym zapowiedzi głosowe, odpowiednie do statusu kasowania min. potwierdzające, negujące. Wymagany wbudowany głośnik o mocy min. 2W;

13) generować sygnał świetlny i dźwiękowy podczas operacji z użyciem zablokowanej Karty e-bilet lub znajdującej się na „czarnej liście”. Sposób sygnalizacji zostanie uzgodniony z Zamawiającym w trakcie wdrożenia;

14) umożliwiać informowanie posiadacza Karty e-bilet o stanie konta, po dotknięciu odpowiedniego przycisku wirtualnego na wyświetlaczu LCD;

15) obsługiwać minimum 3 sloty do kart SAM,16) odczytywać karty bezkontaktowe z odległości, w zakresie od 1 do 10 cm, 17) posiadać zaimplementowane mechanizmy obsługi bezstykowego biletu

elektronicznego na zasadzie e-portmonetki, 18) umożliwiać pobranie jednorazowej opłaty za przejazd środkami transportu

zbiorowego z karty bezkontaktowej, w dowolnej ilości (np. za osobę towarzyszącą, za psa, za bagaż) z zapisem i rozróżnieniem w Podsystemie e-bilet wejścia i wyjścia pasażera do i z autobusu;

19) rejestrować przejazd na podstawie biletu okresowego lub na kartę bezkontaktową z taryfą bezpłatną, z zapisem i rozróżnieniem w Podsystemie e-bilet wejścia i wyjścia pasażera do i z autobusu;

20) rejestrować i bezzwłocznie przekazywać do pamięci urządzenia sterującego dane związane z transakcjami, w tym co najmniej: numer Karty e-bilet, datę i godzinę transakcji;

72

21) mieć możliwość przyjęcia polecenia zablokowania lub odblokowania kasownika przez kierowcę z Autokomputera lub Sterownika e-bilet, poprzez kartę kontrolera biletowego (po zbliżeniu do kasownika karty kontrolera z odpowiednimi uprawnieniami) oraz z Systemu Centralnego (np. polecenie wydane z czytnika kontrolerskiego). W obu przypadkach blokowane lub odblokowywane powinny być od razu wszystkie kasowniki w autobusie. Kasownik musi rejestrować i przekazywać do pamięci urządzenia sterującego informację o blokadach;

22) umożliwiać odblokowanie Kasowników i Biletomatów w pojeździe automatycznie, po zdefiniowanym czasie od chwili zablokowania;

23) umożliwiać zwrot pobranej opłaty jednorazowej za przejazd przy wyjściu; opcja – w przypadku wdrożenia Systemu check in – check-out,

24) zapisać na Karcie e-biletu informację o transakcji kasowania w taki sposób, aby umożliwiać identyfikację poprawności rejestracji lub kasowania Karty e-bilet w pojeździe na danym kursie, w czytniku kontrolera w sposób automatyczny;

25) pobierać wszystkie konieczne dane do realizacji swojego zakresu funkcjonalności i e-biletu ze Sterownika e-biletu,

26) umożliwiać zapisanie na Karcie e-biletu punktów e-portmonetki bądź Kontraktu okresowego zakupionego przez Internet,

27) umożliwiać Doładowywanie Karty e-biletu. Karta e-biletu zostanie rozpoznana i zostaną na niej zapisane Kontrakty okresowe i Doładowania e-portmonetki, które zostaną wykupione przez pasażera na stronie internetowej POP. Informacje o Kontraktach okresowych i Doładowaniach muszą być przekazane do Autokomputerów i Sterowników e-biletu przed wyjechaniem autobusów na trasę. Informacje o Kontraktach okresowych i Doładowaniach będą również przekazywane on-line do autobusów znajdujących się na trasie;

28) mieć obudowę malowaną proszkowo, w kolorze uzgodnionym z Zamawiającym;

29) umożliwiać montaż do rur stelaża o średnicach od 32 do 38 mm,30) zapewniać sposób montażu kasownika gwarantujący możliwość szybkiej

wymiany kasownika w przypadku awarii. Wspornik kasownika musi być wykonany z metalu, a krawędzie muszą być zaokrąglone promieniem min. 5 mm;

31) posiadać ochronę przeciw przepięciom elektrycznym;32) posiadać interfejsy komunikacyjne min.: RS- 485 i LAN/Ethernet 10/100

Mbit/s;33) podjąć obsługę Kart e-bilet lub realizować kasowanie biletów dopiero po

aktywacji przez Sterownik e-biletu.

2. Kasownik dwufunkcyjny w zakresie obsługi Biletów Papierowych powinien spełniać następujące wymagania: 1) umożliwiać wydruk co najmniej 16 znaków (wszystkie litery i cyfry

polskiego alfabetu, znaki specjalne). Wszystkie znaki do nadruku muszą być przekazywane ze Sterownika e-biletu;

73

2) wysokość drukowanych znaków – min. 3 mm; 3) posiadać możliwość konfiguracji znaków i nazw własnych Operatora linii,

drukowanych na Biletach Papierowych;4) posiadać sygnalizację diodową optyczną poprawności skasowania i

umożliwiać informowanie pasażera o fakcie zablokowania kasownika z użyciem diody LED w kolorze czerwonym;

5) umożliwiać trwałe znakowanie mechaniczne (punktowe zniszczenie materiału biletu – minimum przekłucie);

6) posiadać wlot do wprowadzania biletów o szerokości 37 mm; 7) posiadać taśmę barwiącą montowaną wewnątrz kasownika w sposób

umożliwiający łatwą jej wymianę;8) pracować bezawaryjnie w zakresie temperatur od -20 do +50oC;9) posiadać układ podgrzewania, który powinien działać autonomicznie,

gwarantując czytelność skasowania Biletu Papierowego;10) umożliwiać informowanie pasażera o fakcie zablokowania kasownika, z

użyciem komunikatu na wyświetlaczu LCD;11) umożliwiać bezzwłoczne raportowanie ilości skasowanych biletów do

urządzenia sterującego, z podziałem na przystanki;

12) być wyposażony w obudowę wandaloodporną, która powinna być wyposażona w zamek śrubowy.

3. Kasowanie e-biletu.1) Po zbliżeniu Karty e-biletu do kasownika Karta e-biletu jest weryfikowana. 2) W przypadku, gdy Karta e-biletu znajduje się na liście Kart e-bilet

zastrzeżonych (tzw. czarna lista Kart e-bilet), kasownik wyświetla stosowną informację i na stałe nanosi informacje na Karcie e-bilet, że jest ona zablokowana.

3) Przy pozytywnej weryfikacji Karty e-bilet pobierany jest bilet zgodny z wyborem pasażera. Pomyślne zakończenie operacji potwierdzane jest sygnałem dźwiękowym. Niepomyślne zakończenie operacji spowodowane np. zablokowaniem Karty e-biletu lub brakiem biletów na Karcie e-bilet zostanie zasygnalizowane sygnałem dźwiękowym oraz stosownym komunikatem na wyświetlaczu.

4) Ponowne pobranie opłaty z Karty e-bilet jest możliwe po upływie określonego czasu (parametr regulowany, zostanie uzgodniony z Zamawiającym na etapie wdrożenia).

5) Przy drugim kasowaniu należy nacisnąć specjalnie do tego przeznaczony przycisk wirtualny na ekranie dotykowym kasownika.

6) Oprogramowanie kasownika winno być przystosowane do wprowadzenia uzgodnionych biletów i taryf będących w obecnej i przyszłej ofercie zamawiającego.

7) W stanie czuwania kasownik powinien wyświetlać aktualną datę oraz czas. Szata graficzna wyglądu ekranu zostanie uzgodnienia z Zamawiającym na etapie wdrożenia.

8) Kasownik może być zablokowany w dowolnym momencie przez Autokomputer.

74

9) Brak komunikacji kasownika ze Sterownikiem e-biletu lub jego awaria powoduje, że kasownik nie realizuje żadnych operacji na Kartach e-bilet. Przy braku komunikacji ze Sterownikiem e-biletu kasownik powinien wyświetlić „awaria”, zarejestrować czas trwania awarii. Sterownik e-biletu powinien, jeśli wykryje taką sytuację powiadomić odpowiednie stanowisko obsługi Systemu i kierowcę.

10) Kasownik pozwala na skasowanie dodatkowych biletów.11) Kasownik powinien pozwalać, za pośrednictwem wirtualnego przycisku na

ekranie LCD, na sprawdzenie zawartości e-portmonetki oraz ważności Kontraktu okresowego.

12) Powinna być możliwość rejestracji Kontraktów okresowych przy wejściu i wyjściu z autobusu oraz biletów z e-portmonetki przy wejściu i wyjściu z autobusu. Opcja wymogu rejestracji Kontraktów okresowych jest programowalna i możliwa do włączenia i wyłączenia.

13) Kasownik umożliwia rejestrację na Karcie e-biletu Kontraktów okresowych zgodnie z obowiązującą taryfą przewozową. Kasownik musi posiadać funkcję sprawdzenia stanu Karty e-biletu i weryfikacji zapisanych na karcie biletów – informacje mają być wyświetlane na ekranie kasownika.

14) Kasownik umożliwia skasowanie Biletów Papierowych przez umieszczenie na nich nadruku zawierającego informacje o organizatorze transportu, numerze bocznym autobusu, dacie i czasie skasowania biletu lub innych danych ustalonych z Zamawiającym. Format nadruku: umożliwiające drukowanie minimum 16 znaków według kodu stosowanego u Operatora, tj. nnn__ddmmrr_GGMM, gdzie nnn- numer wozu; __ - dwie spacje; ddmmrr- data w kolejności: dzień, miesiąc, rok; _ - pojedyncza spacja; GGMM- godzina, minuta.

IV.6.3.2.2.Podstawowe wymagania techniczne Kasownika dwufunkcyjnego.1. Kasownik powinien posiadać:

1) obudowę wykonaną z trwałego i odpornego na zniszczenia materiału, w kolorze uzgodnionym z Zamawiającym, w stopniu ochronności IP=20 zgodnie z normą PN-EN 60529:2003;

2) zegar czasu rzeczywistego (z podtrzymaniem bateryjnym);3) wbudowany czytnik kart bezkontaktowych zgodnych z ISO/IEC 14443 typ A

i B;4) informację dźwiękową;5) zasilanie 24V +/- 30 % ( tj. od 16,8 – 36 V), prąd stały;6) temperatura pracy: od -20ºC do 50ºC; 7) temperatura w stanie pasywnym: od -30ºC do 65ºC;8) wilgotność względna otoczenia: w zakresie od 10% do 95%;

75

9) maksymalne wymiary kasownika:a) szerokość: 190 mm,b) wysokość: 380 mm;

10) sposób i miejsce montażu uzgodnione z Zamawiającym;11) brak ostrych krawędzi mogących spowodować skaleczenie podróżnego

lub uszkodzenie odzieży. Wszelkie krawędzie powinny być zaokrąglone.;12) łatwą obsługę (ze szczególnym uwzględnieniem osób starszych).

Wszystkie piktogramy, napisy na przyciskach oraz wyświetlaczu LCD, a także opisy, nadruki, naklejki powinny być czytelne, duże, jednoznacznie interpretowalne. Wszystkie napisy na kasowniku oraz komunikaty wyświetlane na ekranie kasownika muszą być w języku polskim, angielskim, niemieckim, ukraińskim).

IV.6.3.3. Biletomat mobilny.Każdy autobus musi być wyposażony w Biletomat mobilny dedykowany do sprzedaży Biletów Papierowych i Kontraktów okresowych opłacanych kartą płatniczą.

IV.6.3.3.1. Dane ogólne Biletomatu mobilnego.Biletomat mobilny powinien:1) mieć obudowę z blachy stalowej, pomalowanej proszkowo na kolor

uzgodniony z Zamawiającym; 2) mieć drzwi ryglowane minimum w trzech punktach (góra, dół, pośrodku); 3) mieć mocowanie na stelażu ze stalowych rur nośnych o przekroju minimum 35

mm, mocowane minimum w trzech punktach (podłoga, burta lub poręcz oraz sufit); możliwość szybkiego demontażu Biletomatu i wymiany na inny;

4) mieć wnękę odbiorczą wydrukowanego biletu podświetloną w trakcie realizacji transakcji;

5) posiadać 15 kompletów kluczy pasujących do wszystkich Biletomatów mobilnych (dostawa kluczy w osobnym, zabezpieczonym pojemniku lub zaplombowanej kopercie, możliwość otwierania Biletomatów mobilnych jednym kluczem);

6) mieć instrukcję obsługi, eksploatacji oraz konserwacji Biletomatów mobilnych języku polskim;

7) mieć możliwość współpracy ze Sterownikiem e-biletu po łączu RS485, Ethernet;

8) posiadać podzespoły i aplikacje uczestniczące w płatnościach bezgotówkowych posiadać muszą odpowiednie certyfikaty akceptowane przez organizacje płatnicze na terenie Polski (minimum qVSDC i TIP Contactless);

9) umożliwiać sprzedaż Biletów Papierowych;10) pozwalać na komunikację z Systemem Centralnym poprzez interfejs

transmisyjny autobusu;11) umożliwiać współpracę z kartami bezstykowymi w standardzie MIFARE

DESFire;

76

12) pozwalać na współpracę z dedykowanym zdalnym serwerem zarządzającym poprawnością pracy oraz statystykami sprzedaży wszystkich zainstalowanych Biletomatów mobilnych;

13) posiadać system alarmowy załączający się w przypadku włamań, kradzieży (działający również w przypadku braku zasilania);

14) umożliwiać Doładowywanie Karty e-biletu. Karta e-bilet zostanie rozpoznana i zostaną na niej zapisane Kontrakty okresowe i Doładowania e-portmonetki, które zostaną wykupione przez pasażera na stronie internetowej POP. Informacje o Kontraktach okresowych i Doładowaniach muszą być przekazane do Autokomputerów i Sterowników e-biletu przed wyjechaniem autobusów na trasę. Informacje o Kontraktach okresowych i Doładowaniach będą również przekazywane on-line do autobusów znajdujących się na trasie.

IV.6.3.3.2. Warunki eksploatacyjne Biletomatu mobilnego.Biletomat mobilny powinien posiadać:1) klasę ochrony minimum IP 54,2) temperaturę pracy w zakresie: od - 20oC do + 50oC3) wilgotność względną otoczenia: max. 95 %;4) wbudowany układ regulacji temperatury wewnątrz Biletomatu;5) zabezpieczenia przed zewnętrznymi zakłóceniami elektromagnetycznymi;6) odporność na wstrząsy i uderzenia;7) czas od włączenia zasilania w autobusie do możliwości obsługi Biletomatu

przez pasażera nie dłuższy niż 5 minut.

IV.6.3.3.3. Zasilanie Biletomatu mobilnego.1) z instalacji pokładowej autobusu: 24 VDC ( +/- 30%);2) zasilanie awaryjne wbudowanym akumulatorem umożliwiającym w przypadku

braku zasilania z autobusu zakończenie ostatniej transakcji i zapisanie wszystkich niezbędnych danych oraz automatyczne wyłączenie się;

3) zastosowany musi być układ stabilizacji zasilania zapewniający bezawaryjną pracę w przypadku chwilowych zakłóceń z sieci autobusu.

IV.6.3.3.4. Obsługa Biletomatu mobilnego przez pasażera.Biletomat mobilny powinien być wyposażony w:1) ekran LCD, kolorowy, z przekątną min. 10’’, rozdzielczość min. VGA,

zabezpieczony przeźroczystą płytą z tworzywa sztucznego lub szkła odpornego na zarysowanie oraz zniszczenie;

2) nakładkę dotykową w technologii IR reagującą na dotyk dowolnym przedmiotem;

3) ekran startowy z wszystkimi niezbędnymi dla pasażera informacjami dotyczącymi obowiązującej taryfy biletowej i obsługi Biletomatu mobilnego;

77

4) menu hierarchiczne – możliwość wyświetlania dodatkowych informacji i reklam;

5) optyczne potwierdzenie opcji wyboru na monitorze LCD;6) menu programowalne w czterech językach (polskim, angielskim, niemieckim,

ukraińskim); 7) możliwość rezygnacji z transakcji w dowolnym momencie;8) wyświetlanie kwoty do zapłaty; 9) możliwość sprzedaży kilku biletów w jednej transakcji, także w różnych

taryfach i ulgach.

IV.6.3.3.5. Płatności.Biletomat mobilny powinien być przygotowany do:1) obsługi płatności bezgotówkowych kartami płatniczymi, kredytowymi;2) obsługi kart zbliżeniowych;3) fiskalizacji transakcji (możliwość dodania odpowiedniego Modułu).

IV.6.3.3.6. Wydruk biletów i raportów.Biletomat mobilny powinien umożliwiać:1) drukowanie różnych typów zdefiniowanych wcześniej biletów (Normalny,

Ulgowy, Godzinny, Pozamiejski itp.) oraz raportów;2) szczegółowe zdefiniowanie typów biletów, jakie mają być drukowane w

Biletomacie mobilnym zostanie określone na etapie uruchamiania Urządzeń; 3) drukowanie biletu o wymiarach:

a) szerokość drukowanego biletu powinna wynosić 35 mm (+/- 1mm),b) na papierze termicznym o gramaturze 80 – 150 g/m2;

4) drukowanie biletów przez drukarkę wewnętrzną według wzoru ustalonego z Zamawiającym;

5) drukowanie na bilecie kodu 2D (QR); 6) umieszczenie następujących informacji w kodzie 2D (QR):

a) data zakupu biletu,b) czas zakupu biletu,c) rodzaj biletu,d) kolejny numer seryjny biletu (zawarty w nim identyfikator urządzenia i nr

kolejny sprzedanego biletu);7) wielkość rolki jest dobrana tak, aby była możliwość wydruku co najmniej 3000

biletów (w zależności od długości biletu) bez konieczności wymiany rolki przy gramaturze papieru 100 g/m2. Gilza rolki minimum 25 mm;

8) w przypadku braku papieru Biletomat mobilny wyświetli na ekranie komunikat uzgodniony z Zamawiającym;

9) papier zabezpieczony  co najmniej na dwa wybrane i uzgodnione z Zamawiającym sposoby, tj.: hologram w formie paska przebiegającego wzdłuż

78

taśmy na nieaktywnej stronie papieru, włókna świecące w świetle UV, gilosz, zastosowanie farby UV lub farby sekretnej, mikrodruk. Zabezpieczony papier do drukowania biletów zapewnia Zamawiający;

10) wysłanie do serwera informacji o wyczerpaniu rolki papieru w drukarce;11) wydruk potwierdzeń płatności kartą płatniczą, kredytową, zbliżeniową.

Wtedy wydruk biletów jest realizowany tylko z jednej drukarki;12) nadruk:

a) ceny,b) serii,c) typu biletu (normalny, ulgowy),d) rodzaju biletu ( jednorazowy, pozamiejski, dobowy, 5-cio dobowy),e) kodu 2D.

IV.6.3.3.7. Funkcje Oprogramowania Biletomatu mobilnego.Biletomat mobilny powinien umożliwiać:1) programowanie grupowe i pojedyncze wszystkich urządzeń z Systemu

Centralnego;2) rejestrację otwarcia drzwi i wszystkich czynności serwisowych, jakie zostały w

nim wykonane;3) rejestrację, sygnalizację stanów awaryjnych i ostrzegawczych m.in.:

a) zerwanego papieru,b) braku papieru,c) kończącej się rolki papieru,d) próby włamania,e) uszkodzenia Biletomatu mobilnego, f) braku możliwości autoryzacji transakcji;

4) zapisywanie danych dotyczących sprzedaży i jego funkcjonowania na karcie pamięci, pendrive lub w notebooku w trakcie czynności serwisowych;

5) w przypadku problemów z łącznością, przesłanie danych za pośrednictwem Wi-Fi na zajezdni oraz odczytu z pamięci Biletomatów mobilnych danych przeniesionych za pośrednictwem karty pamięci, pendrive’a (ogólnodostępny system plików);

6) rejestrować dane o dokonanych transakcjach i stanie poszczególnych komponentów. Dane te przechowywane będą w:a) pamięci wewnętrznej Biletomatu mobilnego,b) Systemie Centralnym (wysyłane na bieżąco po każdej transakcji),co ma pozwolić na odpowiednie zabezpieczenie danych przed ich utratą. Dodatkowo, w przypadku awarii połączenia Biletomat mobilny powinien nadal umożliwić w trybie offline sprzedaż biletów jednorazowych. Po przywróceniu połączenia dane z trybu offline powinny zostać automatycznie wysłane do Systemu Centralnego;

7) definiowanie maski i tła ekranów informacyjnych;8) umieszczanie dodatkowych informacji graficznych na całym ekranie

urządzenia lub jego części odbywać się musi centralnie z poziomu

79

Oprogramowania zarządzającego, a ich aktualizacja na urządzeniach odbywa się siecią GSM lub Wi-Fi w sposób automatyczny;

9) funkcjonowanie informacji graficznych, w formie wygaszacza ekranu znikającego zaraz po dotknięciu ekranu;

10) stosowanie formatów dla grafik umieszczanych na ekranach urządzeń .jpg, .png, .avi;

11) tworzenie wielopoziomowego menu na ekranie Biletomatu;12) intuicyjną obsługę przez pasażera; 13) takie dobranie wielkości pamięci wewnętrznej, aby w Biletomacie

mobilnym można było przechowywać co najmniej 2 moduły cenowe lub inne taryfy;

14) automatyczne przełączanie taryfy we wskazanym dniu na taryfę kolejną, zaprogramowaną przed dniem wejścia jej w życie;

15) takie projektowanie Oprogramowania, aby podczas jednej transakcji umożliwić wybór kilku biletów różnego rodzaju (w różnej taryfie);

16) konfigurację sprzedaży biletów nieskasowanych i skasowanych, bilety nieskasowane są funkcją domyślną;

17) Oprogramowaniu zarządzającemu dostęp z poziomu przeglądarki internetowej na licencji bezpłatnej bez wyłączenia do zastosowań komercyjnych;

18) drukowanie raportów min. dotyczących:a) stanów awaryjnych,b) sprzedaży biletów z podziałem na nominały, okresy.

IV.6.3.3.8. Obsługa serwisowa Biletomatu mobilnego.Biletomat mobilny powinien umożliwiać:1) rejestrację stanów awaryjnych, identyfikację osoby dokonującej obsługi oraz

wszelkich ingerencji w Biletomat mobilny;

2) programowanie odpowiednich uprawnień dla osób zajmujących się obsługą Biletomatów mobilnych;

3) logowanie osoby obsługującej: przy użyciu kodu PIN i karty (poziom dostępu ustalany indywidualnie dla każdego z obsługujących).

IV.7. Punkty Obsługi Klienta (POK) i Punkty Obsługi Sprzedaży (POS).IV.7.1. Sieć sprzedaży biletów obok Biletomatów stacjonarnych i mobilnych obejmuje:1) POK – stanowiska personalizacji i sprzedaży biletów (w kasach Operatora).2) POS w kioskach i salonikach prasowych (30 szt.).

IV.7.2. Punkt Obsługi Klienta (POK).

80

POK jest to miejsce obsługi pasażerów, które umożliwia pełną obsługę klienta w zakresie: przyjmowania wniosków o wydanie imiennej Karty e-bilet, personalizację i wydawanie Kart e-bilet, sprzedaż Kart e-bilet na okaziciela, sprzedaż wszystkich rodzajów biletów występujących w Systemie (w tym Biletów Papierowych) i Doładowanie e-portmonetki .Każdy POK będzie wyposażony w wysokowydajną drukarkę spersonalizowanych Kart e-bilet wydawanych w oparciu o wnioski pasażerów złożone przez Internet lub w punktach personalizacji (mogą być wydane na bieżąco). Karty e-biletu zamówione przez POP będą przekazywane do POK wskazanego przez pasażera, jako miejsce odbioru Karty e-biletu.

IV.7.2.1. Funkcjonalności realizowane w POK (Kasy MZK Sp. z o.o. w Opolu).1) Wykonawca przedstawi propozycję interfejsu kasjera w punkcie POK do

uzgodnienia z Zamawiającym.

2) Szczegółowy zakres funkcjonalności może być uzupełniony bądź zmodyfikowany w trakcie wdrożenia, w wyniku uzgodnień pomiędzy Zamawiającym a Wykonawcą.

3) System powinien zapewnić obsługę sprzedaży biletów zgodnie z obowiązującą taryfą, zapewniając wsparcie pracy kasjerów w POK prowadzonych przez Operatora w zakresie: a) sprzedaży biletów zgodnych z asortymentem (magazyn dla biletów

jednorazowych, usługa dla biletów okresowych),b) przyjmowania wniosków o wydanie Karty e-bilet, c) personalizacji i wydawania Kart e-bilet,d) wydawania Kart e-bilet na okaziciela (za kaucją),e) sprzedaży imiennych Kart e-bilet wydawanych w miejsce utraconych,f) Doładowania e-portmonetki i sprzedaży wszystkich biletów zgodnie z

taryfą,g) zwrotu pieniędzy, wycofywania Doładowań i anulowania Kontraktów

okresowych,h) wystawiania dokumentów sprzedaży (faktury, korekty, noty księgowe),i) dopisywania nowych kontrahentów,j) dopisywania nowych pasażerów,k) dokonywania wpłat KP oraz wypłat KW (opłat manipulacyjnych,

dodatkowych, należności za fakturę),l) sporządzania dokumentów obrotu magazynowego,m) obsługi reklamacji.

IV.7.2.2. Podstawowe funkcjonalności Oprogramowania stosowanego w POK.IV.7.2.2.1. Panel personalizacji.1) Personalizacja na miejscu:

81

a) przyjęcie wniosku o wydanie imiennej Karty e-bilet i wpisanie danych do Systemu Centralnego,

b) wykonanie skanu zdjęcia dostarczonego przez pasażera lub wykonanie zdjęcia na miejscu,

c) potwierdzenie danych osobowych i uprawnień do zniżek (jeżeli dotyczy),d) wydruk imiennej Karty e-bilet.

2) Wydanie Karty e-bilet spersonalizowanej w oparciu o wniosek złożony przez Internet. Osoba składająca wniosek przez Internet otrzymuje na wskazany adres mailowy potwierdzenie weryfikacji wniosku, a po wyprodukowaniu imiennej Karty e-bilet System Centralny automatycznie informuje klienta, że Karta e-bilet jest gotowa do odbioru w wybranym przez klienta POK.

3) Obsługiwanie wniosków reklamacyjnych, o dokonanie korekty danych osobowych, wniosków o zablokowanie Karty e-bilet, w tym, złożonych przez Internet.

IV.7.2.2.2. Panel szybkiej sprzedaży umożliwia.1) Wpisanie danych kasjera, punktu sprzedaży (POS, POK).2) Wybór kontrahenta (np. numer z Systemu Centralnego, nazwisko, NIP).3) Dopisanie nowego kontrahenta (dane do faktury).4) Dopisanie nowego pasażera (dane do personalizacji Karty e-biletu).5) Dopisanie nowych pozycji (sprzedaż, aktualizacja ważności biletu).6) Podgląd okna historii sprzedaży.7) Zmianę rodzaju biletu, linii lub początkowej daty ważności. 8) Dopisanie wielu biletów dla jednego kontrahenta (w jednej operacji

sprzedaży). 9) Wybór typu dokumentu oraz formy płatności (możliwość dopisania uwag dla

dokumentu np. numery bloczków). W panelu można zdefiniować kilka płatności dla danej sprzedaży (po wpisaniu pierwszej formy i kwoty, druga kwota jest podpowiadana automatycznie na podstawie tego ile pozostało).

10) Wydanie jednej faktury do wszystkich pozycji z transakcji.11) Każde Doładowanie e-portmonetki lub zapis Kontraktu okresowego na

Karcie e-bilet jest zapisywane w rejestrach sprzedaży, raportach kasowych, obrocie magazynowym.

12) Wystawianie różnych typów dokumentów sprzedaży zdefiniowanych w Systemie Centralnym.

13) W panelu szybkiej sprzedaży powinny istnieć dwa automatyczne rejestry kasowe dla kasjera – jeden gotówkowy, drugi dla operacji kartami płatniczymi.

14) W przypadku częściowej lub całkowitej zapłaty kartą płatniczą informacja o kwocie transakcji powinna być przekazywana bezpośrednio na terminal płatniczy.

IV.7.2.2.3. Funkcjonalność – Wykaz biletów.W wykazie biletów zapisywane są wszystkie transakcje realizowane w POK. Pozwala to na szybkie znalezienie pozycji do:

82

1) Wystawienia i wydruku dokumentu sprzedaży np. faktury, po wcześniejszym zatwierdzeniu w panelu szybkiej sprzedaży. Wystawienia faktur do paragonów wykonuje się najczęściej z „wykazu biletów”, wykaz ten zawiera wszystkie dane o sprzedaży, bilecie, pasażerze i kontrahencie.

2) Wystawienia duplikatu dokumentu sprzedaży.3) Wykonania zwrotu lub korekty sprzedaży:

a) korekta sprzedaży biletów jednorazowych powinna być realizowana automatycznie, w formie gotowych formularzy wymagających jedynie wpisania wartości po korekcie.

b) korekta sprzedaży Kontraktów okresowych powinna uwzględniać funkcje: zwrotu biletu w całości, częściowego i naliczania dodatkowych opłat procentowych lub wartościowych. Szczegóły rozwiązań zostaną ustalone w trakcie wdrożenia na etapie projektu Systemu.

4) Sprawdzenia szczegółowych danych o dokonanej transakcji.

IV.7.2.2.4. Funkcjonalność – Raporty kasowe.1) W raporcie gotówkowym zapisywane są wszystkie transakcje z panelu szybkiej

sprzedaży oraz wystawiane i zapisywane dokumenty dotyczące innych płatności tj.: a) przyjmowanie wpłat KP (opłaty manipulacyjne, dodatkowe, należności za

faktury, inne);b) dokonywanie wypłat KW (zwroty lub korekty sprzedaży, wpłaty do banku).

2) W raporcie kasowym są dwa okna, w których dokonuje się wyboru kontrahenta. Istnieją tzw. „stali” kontrahenci i kontrahenci jednorazowi (np. dokonujący wpłat za opłatę dodatkową). Dostępne jest również specjalne pole „operacja” - do wyboru z definiowalnej listy typów KP.

IV.7.2.2.5. Funkcjonalność – Rejestry sprzedaży.1) Rejestr paragonów (sprzedaż na paragony, faktury do paragonów).2) Rejestr faktur (sprzedaż bez paragonu na faktury, innych zdefiniowanych

dokumentów).3) Rejestr korekt. W rejestrach tych zapisywane są transakcje zatwierdzone w Panelu szybkiej sprzedaży.

IV.7.2.2.6. Funkcjonalność – Obrót magazynowy.1) Kontrakty okresowe i Doładowania e-portmonetki są usługami, a bilety

jednorazowe - towarami magazynowymi.2) W magazynie centralnym bilety przechowywane są jako bloczki o wartości

druku.

83

W momencie przekazania takiego bloczku do kasy nabiera on wartości sprzedaży. Oprócz przeliczenia ilości (1 bloczek = 100 biletów) następuje również przeliczenie wartościowe. Przeliczenie następuje po aktualnych cenach sprzedaży brutto. Magazyn musi być w stanie przetworzyć taką operację prawidłowo oraz zaraportować odpowiednio do systemu Veritum działającego u Operatora.

3) W przypadku operacji magazynowych również musi być definiowalny dodatkowy typ operacji (np. RW – rozchód biletów wspomniany wyżej, PZB – przychód biletów itp.).

4) Magazyny muszą być ściśle powiązane z punktem sprzedaży (osobą, która pracuje na wybranych rejestrach kasowych i sprzedażowych).

5) Do każdego dokumentu sprzedaży zawierającego pozycje magazynowe tworzy się automatycznie dokument WZ. Również do raportu kasowego danego kasjera zapisywana jest wartość transakcji gotówkowej.

6) Obrót magazynowy, oprócz biletów jednorazowych, musi również umożliwić dystrybucję Kart e-biletu.

IV.7.2.2.7. Kartoteka kontrahentów.1) Dopisywanie i modyfikowanie kontrahentów,2) Kartoteka kontrahentów wspólna dla całego systemu sprzedaży biletów

(Podsystem e-bilet).

IV.7.2.2.8. Kartoteka pasażerów.1) Dopisywanie i modyfikowanie danych o pasażerach (powiązanych z Kartą e-

bilet)2) Kartoteka pasażerów wspólna dla całego systemu sprzedaży biletów

(Podsystem e-bilet).

IV.7.2.2.9. Raporty zakończenia pracy.Przy zakończeniu sprzedaży dziennej w POK Podsystem e-bilet umożliwi wygenerowanie raportów obejmujących podział sprzedaży na: faktury i paragony, bilety okresowe i jednorazowe, inną sprzedaż (np. wtórniki), typy płatności, korekty, raporty kasowe z rozbiciem na typy operacji, zestawienia obrotów magazynowych. IV.7.2.2.10. Lokalizacje POK.POK zostaną rozlokowane na terenie miasta Opola.Każdy POK musi być wyposażony w następujący sprzęt:1) Komputer typ 1,2) Aparat fotograficzny typ 1,3) Drukarka typ 1,4) Drukarka typ 3,5) Czytnik typ 1.

84

Szczegółowa konfiguracja w wybranych lokalizacjach zostanie uzgodniona z Wykonawcą na etapie wdrożenia. Ilość oraz parametry techniczne dostarczanego sprzętu zostały opisane w Załączniku nr 3 do OPZ Parametry techniczne poszczególnych Stanowisk do obsługi Systemu oraz w rozdziale VI OPZ.

IV.8. Terminal sprzedażowy do użytku w Punktach Obsługi Sprzedaży (POS).1. Wykonawca dostarczy 30 terminali sprzedaży (Urządzeń Doładowujących Kartę

e-biletu, zwany dalej UD), które zostaną uruchomione w lokalizacjach wskazanych przez Zamawiającego.

2. Użytkownik UD nie może mieć dostępu do innej funkcjonalności niż te, związane z systemem sprzedaży.

3. Zamawiający oczekuje instalacji terminali UD we wskazanych przez Zamawiającego punktach zlokalizowanych na terenie funkcjonowania Zamawiającego, uruchomienia w Systemie Centralnym e-bilet oraz przeszkolenia personelu w każdym miejscu instalacji terminalu UD.

4. Wymagania funkcjonalne terminali Urządzeń Doładowujących i zainstalowanego na nich Oprogramowania: 1) UD przeznaczone jest do realizacji zadań związanych zapisywaniem na

Kartach e-bilet Kontraktów okresowych, Doładowywaniem e-portmonetki na Kartach e-biletu.

2) Rodzaje Kontraktów okresowych muszą być zgodne z określonymi przez System Centralny.

3) Operacja zapisu na Karcie e-bilet może być realizowana na dwa sposoby: a) bezpośredni – poprzez wprowadzenie rodzaju Kontraktu okresowego

i wciśnięcie przycisku bezpośredniej funkcji zapisu, b) pośredni – poprzez wybranie przycisku funkcji zapisu, a następnie

przyłożenie Karty e-biletu do czytnika, aby terminal UD wskazał zapisane na nim rodzaje biletów, a dalej dostępne opcje poszczególnych Kontraktów okresowych lub Doładowań.

5. Po pomyślnym przeprowadzeniu operacji zapisu na Karcie e-biletu, UD powinno w sposób automatyczny wydrukować potwierdzenie tej operacji zawierające: numer Karty e-bilet, rodzaj zapisanego Kontraktu okresowego lub Doładowania e-portmonetki, wartość, numer terminalu UD, operatora oraz datę i godzinę operacji.

6. UD musi przechowywać listę Kart e-bilet zastrzeżonych oraz tzw. czarną listę Kart e-bilet przeznaczonych do zablokowania. Listy te uaktualniane są przez System Centralny online.

7. UD musi sygnalizować użytkownikowi UD sytuację próby zapisu na Karcie e-biletu zastrzeżonej lub nieważnej.

85

8. UD musi zablokować Kartę e-bilet, która znajduje się na tzw. czarnej liście Kart e-bilet do zablokowania.

9. UD musi posiadać opcję anulowania dokonanego Doładowania e-portmonetki i zakupionego Kontraktu okresowego. Anulowanie może być zrealizowane tylko w przypadku jego realizacji przez ten sam terminal UD, na którym zrealizowano operację lub w punktach POK. Anulowanie może nastąpić w ciągu określonego przedziału czasowego, nie później niż do końca ważności Kontraktu okresowego lub Doładowania. Operacja anulowania musi zostać potwierdzona stosownym wydrukiem, zawierającym wszystkie szczegóły tej operacji.

10. Wszystkie operacje zapisu na Kartach e-biletu lub anulowania Kontraktu okresowego, Doładowania Kart e-biletu, rozpoznania próby użycia Kart e-bilet zastrzeżonych, zablokowania Kart e-biletu muszą zostać zapisane w pamięci terminalu UD i przekazane do Systemu Centralnego (online).

11. Terminal UD musi posiadać funkcję, która umożliwia weryfikację stanu Karty e-biletu.

12. Wszystkie operacje wykonywane na Karcie e-biletu muszą być na niej zapisywane przez terminal UD.

13. UD winien rejestrować dane o dokonanych transakcjach i stanie poszczególnych komponentów. Dane te przechowywane będą w:1) pamięci wewnętrznej UD,2) Systemie Centralnym (wysyłane na bieżąco po każdej transakcji).Pozwoli to na odpowiednie zabezpieczenie danych przed ich utratą. Dodatkowo, w przypadku awarii łącza UD powinien nadal umożliwić funkcjonalność dostępną w trybie offline, w tym sprzedaż:3) Doładowań e-portmonetki,4) Kontraktów okresowych.Po przywróceniu połączenia dane z trybu offline powinny zostać automatycznie wysłane do Systemu Centralnego.

14. Musi istnieć możliwość zablokowania i odblokowania terminala UD z poziomu Systemu Centralnego. System Centralny musi umożliwiać konfigurowanie alarmów dla administratora Systemu Centralnego, w przypadku pojawienia się podejrzanych transakcji (wgrania kilku wysokich Kontraktów okresowych przez punkt sprzedaży, przekroczenie zobowiązania punktu ponad ustalony limit (np. 10 tys. zł), kilkukrotna próba wgrania Kontraktu na Karcie e-bilet zastrzeżonej, etc.). System Centralny w takich wypadkach powinien blokować POS do czasu weryfikacji przez administratora.

15. Komunikacja UD z Systemem Centralnym musi być zabezpieczona przed włamaniami pochodzącymi z Internetu zgodnie ze standardami przemysłowymi.

16. Zaszyfrowana transmisja odbywa się z wykorzystaniem łącza minimum GSM poprzez APN Operatora.

86

17. Dla wszystkich POS może być ustanowiony limit sprzedaży- parametr konfigurowalny. Ponadto, powinien być możliwy do skonfigurowania limit sprzedaży offline.

IV.8.5. Parametry techniczne terminala UD. 1. Na kompletne stanowisko terminala UD składają się:

1) tablet spełniający minimalne wymagania opisane w zał. 3 (komputer typ 4). 2) drukarka termiczna spełniająca minimalne wymagania opisane w zał. 3

(drukarka typ 4). 3) czytnik kart elektronicznych e-biletu spełniający minimalne wymagania

opisane w zał. 3 (czytnik typ 2).

2. Zamawiający dopuszcza również zastosowanie POS w formie jednolitego urządzenia łączącego opisane funkcje UD.

IV.8.5.4. Oprogramowanie terminala UD.

Oprogramowanie terminala UD zapewniające spełnienie wymagań funkcjonalnych określonych w punkcie IV.9. OPZ zrealizowane powinno być z wykorzystaniem funkcji ekranu dotykowego. Oprogramowanie to powinno zostać dostarczone w formie umożliwiającej jego samodzielną instalację przez Zamawiającego na innych tabletach tego samego typu. Licencja na Oprogramowanie powinna przewidywać jego bezterminowe użytkowanie na dowolnej ilości terminali UD. Terminal UD powinien współpracować z kartą działającą w Systemie e-biletu Zamawiającego zgodne z ISO/IEC 14443 typ A i B, typu MIFARE DESFire, o pojemności min. 4kB.

IV.9. Doładowywanie Kart e-bilet i zapis Kontraktów okresowych przez Internet – POP. W ramach dostawy Oprogramowania Podsystemu e-bilet Wykonawca dostarczy i uruchomi na dostarczonej infrastrukturze serwis internetowy – POP dla użytkowników Kart e-biletu realizujący następujące funkcje:IV.9.1. Ogólnodostępny serwis internetowy POP.1) Działanie serwisu internetowego POP będzie wspierało i odciążało pracę POK.2) POP będzie zawierał informację pasażerską prezentującą prognozę

rzeczywistych odjazdów autobusów.3) POP będzie zawierał aktualnie używany moduł rozkładów jazdy i wyszukiwarki

połączeń znajdujących się obecnie na stronie Operatora. Wykonawca powinien przenieść wskazane moduły do nowego serwisu POP.

87

4) Adres domeny www ustalony zostanie z Zamawiającym na etapie realizacji Systemu. Koszty rezerwacji, zakupu i utrzymania adresu www w trakcie trwania umowy leży po stronie Wykonawcy.

5) W przypadku serwisu informacji pasażerskiej, adres prezentujący prognozę odjazdów dla danego przystanku powinien być budowany wg zasady: stała część adresu (np. nazwa domeny) + „bus_stop_no” + nr systemowy przystanku.

6) W zakresie informacyjnym strona www POP zawierała będzie informacje związane z działaniem Podsystemu e-biletu, w tym o:a) strefach;b) taryfach;c) procedurach wymaganych przy personalizacji Kart e-bilet i otrzymaniu Kart

e-bilet na okaziciela;d) funkcjach dostępnych przez Internet, w POK i w POS;e) zasadzie działania kasowników i Biletomatów (instrukcji postępowania w

przypadku zapisu na Karcie e-bilet Doładowania i pozostałych funkcji kasownika/Biletomatu, w formie animowanej prezentacji);

f) lokalizacji POK i POS (poprzez wyświetlenie punktów na mapie np. Google Maps).

7) W zakresie przyjmowania wniosków POP musi posiadać następujące funkcjonalności:a) możliwość zamówienia przez użytkownika imiennej Karty e-bilet.

Użytkownik powinien mieć możliwość zarejestrowania nowego konta (przypisanego do adresu e-mail), podania danych osobowych, PESEL, wgrania zdjęcia i zamówienia Karty e-bilet;

b) zapewniać bezpieczeństwo danych osobowych, żądać od użytkownika wyrażenia odpowiednich zgód na przetwarzanie danych osobowych przez administratora POP;

c) po przesłaniu odpowiednio wypełnionego wniosku pasażerowie mają otrzymywać pocztą elektroniczną automatycznie wygenerowaną wiadomość w celu potwierdzenia autentyczności konta e-mail. W przypadku nie potwierdzenia adresu e-mail wniosek ma być kasowany automatycznie po 24 godzinach (parametr definiowalny);

d) po potwierdzeniu adresu e-mail przez Klienta, wniosek ma trafiać do Podsystemu e-bilet, gdzie Zamawiający będzie miał możliwość łatwej zautomatyzowanej selekcji i weryfikacji wniosków oraz ich obsługi.

e) użytkownicy (z odpowiednimi uprawnieniami) Podsystemu e-bilet mają mieć możliwość: o odrzucenia wniosku, o zatwierdzenia wniosku, o przesłania do pasażera wiadomości e-mail;

f) po wydrukowaniu Karty e-bilet aplikacja ma wygenerować i przesłać wiadomości e-mail do pasażerów o możliwości stawienia się w wybranej lokalizacji w celu odbioru gotowej Karty e-bilet.

8) W zakresie informacji pasażerskiej należy uruchomić publiczny responsywny serwis WWW, będący elementem POP: a) przedstawiający rzeczywistą prognozę odjazdów autobusów ze wszystkich

przystanków obsługiwanych przez Operatora. Wybranie prognozy rzeczywistych odjazdów dla właściwego przystanku w serwisie www powinno umożliwiać wyświetlanie odjazdów w zakresie najbliższych 60

88

minut (parametr). Informacja powinna być ułożona rosnąco poczynając od najbliższych odjazdów. W przypadku kiedy autobus nie ma łączności GSM, kurs autobusu prezentowany w serwisie www powinien być wyświetlany w formacie HH:MM;

b) serwis WWW poza prognozą odjazdu powinien opcjonalnie umożliwiać wyświetlanie nr bocznego autobusu realizującego odjazd i jego cech w formie ikon takich jak niska podłoga, klimatyzacja, autobus przystosowany do przewozu rowerów;

c) informacja o realnym czasie przyjazdu autobusu danej linii na wybranym przystanku powinna być realizowana z dokładnością do jednej minuty;

d) Zamawiający na etapie realizacji serwisu WWW musi mieć możliwość ustalenia czcionki i szaty graficznej informacji;

e) wyszukiwanie przystanku w serwisie powinno być możliwe po jego numerze, nazwie przystanku, ulicy, linii i kierunku jazdy (autopodpowiadanie);

f) serwis WWW powinien móc umożliwiać (w widoku szczegółowym) poza nr linii, kierunkiem jazdy i informacji za ile minut będzie autobus, także wyświetlanie aktualnego opóźnienia, godziny teoretycznej odjazdu, nr bocznego autobusu i jego charakterystycznych cech np. niska podłoga, klimatyzacja, autobus przystosowany do przewozu rowerów;

g) serwis WWW powinien oferować publiczne udostępnianie widgetu (komponentu – jest to kod JavaScript, HTML5 i CSS), którego konfiguracja (wpisanie w kodzie nr inw. przystanku) i wklejenie do kodu HTML innej strony spowoduje automatyczne wyświetlanie rozkładu jazdy zadeklarowanego przystanku;

h) jedną z funkcjonalności serwisu WWW powinna być tzw. mapa ruchu na której naniesione zostaną trasy linii autobusowych z przypisaniem gradacji kolorów zależnej od prędkości autobusów w danym zakresie czasu;

i) serwis WWW powinien oferować także otwarty interfejs w formacie JSON wraz z pełną dokumentacją, udostępniający wskazanym przez Zamawiającego podmiotom, publicznie pozycje GPS autobusów i informację o aktualnym wykonywaniu zadań. Dane do interfejsu powinny być przekazywane natychmiastowo (bez jakiegokolwiek opóźnienia). Interfejs powinien dzielić dane na relacyjne części (zasoby).

IV.9.2 Serwis użytkowników Podsystemu e-Bilet.Podsystem e-bilet umożliwi pasażerowi zalogowanie się (poprzez podanie adresu e-mail i hasła) na swoje konto osobiste oraz pozwoli uzyskać szczegółowe informacje lub zrealizować operacje dotyczące konta: 1) historii logowania użytkownika do portalu WWW (POP);2) historii transakcji związanych z kontem i Kartami e-bilet przypisanymi do

konta;3) zakupu Kontraktów okresowych i Doładowania e-portmonetki w pełnym

zakresie obowiązującej taryfy poprzez dokonanie płatności przy użyciu bankowej płatności internetowej (we współpracy ze wskazanym przez

89

Zamawiającego operatora płatności elektronicznych) lub płatności kartą płatniczą. Nie zapłacone transakcje powinny ulec automatycznemu anulowaniu po określonym czasie (parametr definiowalny);

4) w przypadku posiadaczy biletów okresowych, w zdefiniowanym terminie, np. trzy dni przed zakończeniem terminu ważności, wysyłać e-mail do klienta z przypomnieniem;

5) możliwość zmiany hasła;6) możliwość wglądu do danych personalnych zgromadzonych w Podsystemie e-

bilet;7) możliwość składania wniosków rozpatrywanych przez pracowników

Zamawiającego, zakres obsługiwanych wniosków to co najmniej:a) wnioski reklamacyjne,b) wnioski o dokonanie korekty danych osobowych,c) wnioski o zablokowanie Karty e-bilet,d) wnioski o wydanie lub przypisanie nowej Karty e-bilet do konta.

Szata graficzna tych funkcjonalności, jak i ich zakres zostanie uzgodniona z Zamawiającym w trakcie realizacji Zamówienia.

IV.9.3. Wymagania funkcjonalne dotyczące obsługi kont, Kart e-bilet i wniosków oraz powiązania ich z Podsystemem e-bilet.Ze względu na ujednolicenie przetwarzanych danych oraz uproszczenie przejścia z Systemu użytkowanego przez Operatora do nowego Systemu wymaga się następujących funkcjonalności:1. Obsługa kont.

1) Konta powinny być jednoznaczne powiązane z kontrahentem w Podsystemie e-bilet.

2) Kontrahent jest posiadaczem konta. Może nim być osoba fizyczna lub prawna.

3) Konta uznaje się za zweryfikowane w momencie odbioru pierwszej Karty e-bilet i potwierdzenia danych przez kontrahenta (zatwierdza to pracownik Zamawiającego).

4) Konto nie jest jednoznaczne z pasażerem.5) Do jednego konta może być przypisane wiele Kart e-bilet (np. rodzic może

zarządzać kartami dzieci, firma może zarządzać Kartami e-bilet pracowników).

6) Konto może Doładować e-portmonetkę lub zapisywać Kontrakt okresowy na dowolnej Karcie e-bilet do niego przypisanej.

2. Obsługa Kart e-bilet.1) Dane Karty e-bilet są jednoznaczne z danymi pasażera;2) Pasażer może jednocześnie być kontrahentem;3) Karta e-bilet może być przypisana tylko do jednego konta;4) nie jest wymagane posiadanie konta dla posiadania Karty e-bilet.

3. Obsługa wniosków.

90

1) wszystkie wnioski składane z kont niezweryfikowanych wymagają potwierdzenia adresu e-mail. W przypadku braku potwierdzenia w ciągu 24 godzin (parametr definiowalny) wniosek jest kasowany i nie trafia do Podsystemu e-bilet;

2) wniosek o założenie nowego konta powinien być obsługiwany w następujący sposób:a) dane wpisane na wniosku są weryfikowane z danymi pasażera i

kontrahenta w Podsystemie e-bilet.

b) w przypadku identycznych danych następuje stałe powiązanie z kontrahentem (w przypadku znalezienia powiązania z pasażerem, dane są przepisywane do kontrahenta).

c) w przypadku rozbieżności pracownik Zamawiającego kontaktuje się z kontrahentem i poprawia dane oraz wiąże je z istniejącymi w Podsystemie e-bilet lub dopisuje nowego kontrahenta;

3) musi istnieć możliwość założenia konta na podstawie istniejącej Karty e-bilet. Opcja ta jest dostępna tylko dla Kart e-bilet nie przypisanych do żadnego konta. Dane są sprawdzane z danymi pasażera i przypisywane do konta (lub pracownik POK wprowadza nowe dane kontrahenta). Konto takie uznaje się za zweryfikowane;

4) wniosek o założenie nowej Karty e-bilet powinien być obsługiwany w następujący sposób w przypadku:a) składania wniosku z istniejącego konta powinna być możliwość szybkiego

przeniesienia danych konta na wniosek.b) składania wniosku z części ogólnodostępnej serwisu lub konta

niezweryfikowanego, obowiązują zasady tożsame jak w przypadku wniosku o założenie konta z tą różnicą, że dane są „dowiązywane” do pasażera i kopiowane do kontrahenta;

5) wnioski o zablokowanie Karty e-bilet z kont zweryfikowanych powinny być realizowany automatycznie;

6) wnioski o przypisanie istniejącej Karty e-bilet do konta wymagają stawiennictwa osobistego właściciela konta razem z Kartą e-bilet w punkcie POK.

IV.9.4. Oprogramowanie CMS do zarządzania treścią strony.Strona internetowa musi:

1) być wykonana w oparciu o Content Management System (system zarządzania treścią strony internetowej) stosowany i wykorzystywany obecnie przynajmniej w 5 instytucjach w Polsce lub na świecie;

2) zapewniać zgodność ze standardem WCAG (Web Content Accessibility Guidelines) 2.0;

3) Bazować na technologii rozwijanej i wspieranej przez niezależnych twórców kodu jądra Systemu CMS;

4) zapewniać poprawne wyświetlanie i modyfikowanie treści wprowadzanych przez operatorów;

5) CMS musi zapisywać logi działania, przeglądania jak również czynności administracyjnych;

91

6) umożliwiać dodawanie, wyświetlanie i modyfikację stron informacyjnych z zawartością tekstu formatowanego i grafiki;

7) zapewniać obsługę wpisywanych treści z datą początkową i datą końcową oraz z automatycznym przeniesieniem do archiwum po przekroczeniu daty końcowej (nie ma trwałego usuwania treści);

8) zapewniać obsługę galerii mediów (zdjęcia, filmy, nagrania) z miniaturami z najnowszej galerii na stronie głównej wyświetlanych po wybraniu opcji galerii;

9) posiadać wyszukiwarkę treści w obrębie wybranej opcji;10) obsługiwać elementy Java Script, Flash, popularne formaty graficzne (jpg, png,

gif, bmp). Powinna umożliwiać odtwarzanie filmów (flv) i dźwięku (mp3),11) poprawnie pracować pod większością współczesnych przeglądarek

internetowych, w szczególności Firefox , EDGE , Safari , Chrome;12) posiadać ułatwienia dla pracy wielojęzycznej. Przewiduje się cztery wersje

językowe – polską, angielską, ukraińską i niemiecką;13) umożliwiać samodzielne zarządzanie treścią, wyglądem, zakresem i

funkcjonalnością menu – CMS;

14) zapewniać maksymalne bezpieczeństwo i ochronę danych zawartych w serwisie;

15) zapisywać do historii zdarzeń dostępnej dla użytkownika wszelkie zalogowania, zmiany treści, itp.;

16) udostępniać statystyki odwiedzin do wyboru w skali dnia (z podziałem na godziny), miesiąca (z podziałem na dni), roku (z podziałem na miesiące). Statystyki winny zawierać informacje o unikalnych (i nie unikalnych – do wyboru) adresach IP odwiedzających, porze dnia, oglądanej stronie, czasie trwania sesji. Dostęp do niej ma być możliwy po zalogowaniu się (autoryzacji) i pozytywnej weryfikacji uprawnień. Przy przeglądaniu ma być możliwy wydruk poszczególnych stron statystyk. Forma graficzna do uzgodnienia z Zamawiającym. Statystyki powinny również dotyczyć sklepu WWW, w tym statystykach wykonywanych operacji.

IV.9.5. Warunki techniczne w zakresie bezpieczeństwa serwisu POP.POP ze względów bezpieczeństwa powinien być wydzielony w DMZ (Demilitarized Zone – strefa ograniczonego zaufania). Pomiędzy DMZ, a resztą sieci usytuowana powinna zostać zapora sieciowa definiująca zestaw reguł chroniących lokalną sieć komputerową przed nieuprawnionym dostępem.1. Konfiguracja serwera:

1) w celu zapewnienia odpowiedniego poziomu bezpieczeństwa na serwerze WWW zainstalowany będzie certyfikat SSL o długości kluczy asymetrycznych w certyfikatach co najmniej 1024 bity;

2) uwierzytelnienie serwera aplikacji przy użyciu certyfikatu wydanego przez główny urząd certyfikacji, którego klucz publiczny domyślnie znajduje się w przeglądarkach Edge, Firefox; długość kluczy asymetrycznych w certyfikatach co najmniej 1024 bity;

3) przy konfiguracji serwera należy zablokować możliwość zdalnego odczytania przez osoby nieuprawnione rodzaju, wersji i informacji konfiguracyjnych

92

serwera http(s), wartości zmiennych środowiskowych, rodzaju i wersji Systemu operacyjnego na serwerze aplikacji;

4) dostarczenie certyfikatu SSL leży po stronie Wykonawcy.2. Dane klientów będą przesyłane metodą POST przy użyciu protokołu SSL przy

użyciu realnej długości klucza co najmniej 112 bitów. Dane przesyłane do Pasażerów będą musiały wcześniej przejść odpowiedni proces walidacji (np. przy przesyłaniu ich na serwer).

3. W celu zwiększenia poziomu zabezpieczeń hasła klientów do logowania nie będą przechowywane w bazie danych w postaci jawnej. Przechowywany będzie tylko skrót hasła połączonego ze stałą, utworzoną losowo wartością (tzw. salt) wygenerowaną losowo dla danej instancji serwisu. Do obliczenia skrótu będzie użyta funkcja skrótu SHA-2 (SHA-512).

IV.9.6. Wymagania funkcjonalne.1) Wszelkie funkcjonalności i wygląd poszczególnych części POP powinien być w

formie projektu przedstawiony Zamawiającemu do akceptacji.2) Strona WWW ma zawierać dwie strefy: publiczną i administracyjną z

ograniczonym dostępem uzależnioną od uprawnień. Strefa administracyjna ma służyć zarządzaniu całością w zależności od posiadanych uprawnień. Dla zamawiającego oprócz zarządzania treścią, wyglądem i działaniem mają być dostępne mechanizmy zarządzania użytkownikami i uprawnieniami.

3) Dostęp ma być na poziomie poszczególnych funkcjonalności, mających swoje odzwierciedlenie w głównym menu strony (uprawnienia do głównej opcji menu dotyczyć mają również podporządkowanego podmenu). Każda opcja głównego menu wymaga odrębnych uprawnień do zarządzania (zmiana treści, wyglądu).

4) Napisy, komunikaty powinny mieć definiowalną formę wyświetlania (czcionka, wielkość, kolor, zachowanie – proste animacje). Sekcja ta ma również umożliwić okazjonalne publikowanie definiowalnych treści – np. komunikaty – sekcja komunikatów na stronie głównej.

5) Wiadomości wyświetlane w formie listy ze skróconym opisem (temat, data publikacji, autor, obrazek, skrót).

6) Listy z definiowalną ilością wyświetlenia poszczególnych pozycji na stronie i możliwością stronicowania.

7) Zarządzanie treścią (CMS) ma umożliwić między innymi ustalenie czasu publikacji dokumentu (od kiedy, do kiedy), wybranie opcjonalnie wyświetlenia dodatkowych informacji takich jak np. autor.

8) Każdy wpis w bazie danych podlega moderacji przez zarządzającego stroną. Publikacja publiczna wpisanych treści ma być możliwa wyłącznie po akceptacji osoby z odpowiednimi uprawnieniami – Moderatora. Dokąd publikacja nie uzyska przyzwolenia Moderatora to treść nie będzie publikowana.

9) Samo wpisywanie treści ma być łatwe przy użyciu minimalnej ilości niezbędnych opcji, przycisków i wypełnianych pól, powinno być możliwe dodawanie treści z użyciem bezpośrednio kodu html, php, js i css.

93

10) Formularz kontaktowy powinien zawierać listę wielokrotnego wyboru (ustalaną z poziomu CMS, treść wyświetlaną, adresy poczty elektronicznej), wyboru adresatów, tematu i treść. Po wpisaniu treści i naciśnięciu odpowiedniego przycisku program – na podstawie adresu mailowego – umieszczonego poza stroną, np. w bazie danych, ma wysłać wpisaną wiadomość wybranym adresatom.

11) Optymalizacja SEO stron. Optymalizacja musi zostać wykonana zgodnie z bieżącą wiedzą techniczną na dzień oddawania strony do użytku. Optymalizacja nie musi zawierać wpisów w katalogach stron internetowych.

12) Strona internetowa POP musi być zintegrowana z Systemem Centralnym i zapewnić automatyczną wymianę danych z Systemem Centralnym w tym: z Podsystemem e-biletu, zarządzania Taborem autobusów, informacji pasażerskiej on-line, Oprogramowaniem RJ i programu finansowo-księgowego Operatora w zakresie niezbędnym do realizacji wszystkich funkcjonalności.

IV.10. Kontrola biletów (czytniki kontrolerskie).1. W ramach realizacji zadania zostanie dostarczonych 15 szt. urządzeń do

kontroli biletów, zwanych dalej czytnikami kontrolerskimi. Czytniki kontrolerskie to przenośnie urządzenia wielofunkcyjne odporne na wstrząsy, upadek z wysokości oraz warunki atmosferyczne. Obsługę zapewnia ekran dotykowy i klawisze funkcyjne. Wyposażone są w moduł transmisji danych, moduł lokalizacji GPS, skaner kodów 2D, terminal płatniczy oraz Oprogramowanie pozwalające na realizację co najmniej:1) kontroli biletów w formie elektronicznej, 2) kontroli biletów z kodem 2D (aplikacje mobilne oraz Bilety Papierowe),3) zbieranie danych o zrealizowanych kontrolach oraz elektroniczne ich

przekazywanie,4) płatność kartą kredytową, debetową lub zbliżeniową,5) wydruk blankietu opłaty dodatkowej,6) elektroniczne przekazywanie danych o opłatach dodatkowych,7) kodowanie biletów elektronicznych zakupionych w sklepie WWW na Karcie

e-bilet.2. Urządzenia będą zarządzane zdalnie poprzez System Centralny umożliwiający

nadzór oraz realizację diagnostyki, serwisu urządzeń i utrzymania Oprogramowania (w tym aktualizacja).

3. Wraz z czytnikami zostaną dostarczone również stanowiska do obsługi kontrolerów. Stanowiska będą podłączone do Systemu Centralnego i będą umożliwiały w szczególności realizację następujących funkcji:1) konfigurowanie kart kontrolerskich i zarządzanie kartami,2) zarządzanie pracą kontrolerów,3) zbieranie danych o zrealizowanych kontrolach; 4) przekazywanie danych o zmianach taryfowych oraz innych informacji, np. o

zablokowanych Kartach e-bilet;5) rozliczenia pracy poszczególnych kontrolerów (w tym analiza geograficzna

na podstawie danych z GPS),6) eksport danych o opłatach dodatkowych do systemu windykacji.

94

Stanowiska zostaną zamontowane w biurach Operatora. Komunikacja dwustronna z czytnikami kontrolerów za pomocą stacji dokującej, komunikującej się z komputerem bazowym za pomocą LAN lub USB umożliwiając ich konfigurowanie, zarządzanie nimi.Ilość i parametry techniczne stanowisk zostały podane w Załączniku nr 3 do OPZ Parametry techniczne poszczególnych stanowisk oraz w rozdziale VI OPZ Stanowiska do obsługi Systemu. Szczegółowa konfiguracja stanowisk zostanie uzgodniona z Wykonawcą na etapie wdrożenia.

4. Czytniki kontrolerów. Terminal przenośny do kontroli biletów jest przewidziany do kontroli Kontraktów okresowych i jednorazowych zapisanych na Karcie e-bilet, Biletów Papierowych z kodem 2D oraz do bezgotówkowej zapłaty należności wynikających z opłat dodatkowych.

IV.10.4.1. Wymagania funkcjonalne.

1) Logowanie kontrolera (po włączeniu czytnika), za pomocą swojej karty kontrolera.

2) Możliwość zablokowania wszystkich kasowników i Biletomatu w pojeździe (w tym przy użyciu karty kontrolera oraz sieci GSM).

3) Pobieranie danych o Kartach e-bilet aktywnych w Podsystemie e-bilet, Kart e-bilet zastrzeżonych oraz innych niezbędnych informacji, odbywać się będzie przez GSM, oraz za pośrednictwem stacji dokującej stanowiska obsługi kontrolerów.

4) Pobieranie danych z systemu autobusowego (nr linii, kurs, numer boczny autobusu, przystanek) np. przez kartę kontrolera lub bezpośrednio z systemu autobusowego. W czytniku zostają zapisane: data, czas rozpoczęcia kontroli, numer linii, kierunek, nr boczny autobusu, miejsce (przystanek) kontroli, lokalizacja z GPS.

5) Kontrola Karty e-bilet pasażera poprzez zbliżane jej do pola odczytowego czytnika.

6) Wystawianie opłaty dodatkowej z urządzenia kontrolerskiego. Jeżeli są dostępne w Systemie Centralnym, dane do wypełnienia formularza powinny być z niego pobrane.

7) Przekazywanie danych o kontrolach i opłatach dodatkowych do Systemu Centralnego on-line oraz przez stanowiska obsługi kontrolerów. Wykonawca uzgodni z Zamawiającym procedurę wystawiania oraz przesyłania opłat dodatkowych do Systemu Centralnego przy pomocy czytnika kontrolerskiego,

8) Pobranie z Karty e-bilet pasażera danych do wystawienia opłaty dodatkowej. Jeżeli pasażer nie posiada przy sobie Karty e-bilet, lecz jego dane osobowe są w Systemie Centralnym, czytnik powinien móc po skomunikowaniu się z Systemem Centralnym pobrać dane do wystawienia opłaty dodatkowej,

9) Czytnik pozwalać będzie na ręczne wprowadzenie danych przez kontrolera,10) Czytnik pozwalać będzie na dokonanie płatności kartą płatniczą, kredytową

i zbliżeniową. Kwota do zapłaty jest automatycznie przekazywana do zintegrowanego modułu kart płatniczych,

11) Czytnik powinien mieć skonfigurowany fizyczny lub wirtualny „panic button” (przycisk antynapadowy) do przekazania sygnału o zagrożeniu,

95

12) Czytnik ma generować następujące komunikaty i sygnały:a) informację o ważności, nieważności, zastrzeżeniu Karty e-bilet,b) informację o ważności posiadanego biletu okresowego, realizowanej linii,c) sygnalizację dźwiękową w przypadku wykrycia braku zawarcia umowy

przewozu na Karcie e-bilet (tj. ważnego biletu),13) W przypadku braku zapisanego Kontraktu okresowego na Karcie e-bilet,

powinna być możliwość sprawdzenia w Systemie Centralnym czy odpowiedni Kontrakt okresowy znajduje się na koncie pasażera (procedura na żądanie pasażera) oraz zapisanie Kontraktu okresowego na Karcie e-bilet. Powinno to być wykonywane przez skonfigurowane polecenie uruchamiane ze zdefiniowanego przycisku na ekranie dotykowym.

IV.10.4.2. Przekazanie danych z czytnika kontrolerskiego.

Czytniki kontrolerów komunikują się z Systemem Centralnym poprzez sieć GSM, sieć bezprzewodową Wi-Fi oraz stanowiska obsługi kontrolerów Zamawiającego. Wymagane jest szyfrowanie połączeń. Poprzez komunikację czytników kontrolerskich Zamawiający rozumie dwustronny przesył wszelkich informacji potrzebnych do działania czytników i całego Podsystemu e-bilet. Wykonawca dostarczy dwie stacje dokujące dla czytnika kontrolerskiego, które będą wykorzystywane w szczególności do:1) wgrywania nowego Oprogramowania do czytnika,2) wgrywania nowego Oprogramowania czytnika systemowego/układowego

(firmware),3) resetowania i wgrywania ustawień do czytnika,4) odczytywania i wgrywania danych do i z czytnika,5) diagnozowania czytnika.IV.10.5. Wymagania techniczne dla czytnika kontrolerskiego.1) Czytniki muszą być dostarczone z etui na pasku naramiennym (dopuszcza się

pasek na nadgarstek w przypadku gdy urządzenie jest lżejsze niż 500g i przystosowane do trzymania w dłoni).

2) Maksymalna waga urządzenia gotowego do pracy nie może przekroczyć 0,8kg, a z dodatkowym wyposażeniem typu zasilacz, etui, akumulator zapasowy nie może przekroczyć 1,5kg.

3) Interfejs Smart Card – ISO/ICE 14443 Type A (MIFARE®), ISO14443 Type B. 4) Wbudowany odbiornik GPS.5) Obsługa kart SD i SDHC.6) Urządzenie musi być odporne na upadek z wysokości do 1,5 m oraz wykonane

zgodnie z normą minimum IP54.7) Musi posiadać skaner kodów 2D.8) Urządzenie swoimi wymiarami musi umożliwiać kontrolerom swobodną pracę.9) Czytnik musi umożliwiać bezkontaktowy, zbliżeniowy odczyt Kart e-bilet.10) Czytnik musi umożliwiać kontrolę ważności biletu.11) Uruchamianie czytnika powinno odbywać się za pomocą karty

identyfikacyjnej (pracownicza karta kontrolera).12) Zapis operacji powinien następować w pamięci czytnika.

96

13) Pojemność pamięci czytnika musi wystarczać na min. 2 dni pracy (16 godzin kontroli).

14) Po wczytaniu danych do komputera bazowego, dane w czytniku muszą być kasowane.

15) Bateria zasilająca musi wystarczać na min. 2 dni pracy (16 godzin ciągłej pracy) przy temperaturach pracy od -20C do +50 C.

16) Drukarka 2” do wydruku dokumentu opłaty dodatkowej, zintegrowana w obudowie czytnika kontrolerskiego.

17) Modem GSM ze slotem na kartę SIM.18) Minimum jedno gniazdo na karty dostępowe SAM.19) Możliwość wymiany informacji z komputerem poprzez bezpośrednia złącze

umieszczone w czytniku lub stacji dokującej, jak również poprzez sieć Wi-Fi.

20) Urządzenie komunikując się poprzez sieć GSM ma mieć możliwość zsynchronizowania niezbędnych danych z Systemem Centralnym (np. czarnej listy biletów zastrzeżonych) i weryfikacji Kontraktów okresowych zapisanych na Kartach e-bilet.

21) Ładowanie akumulatora odbywać się powinno poprzez zasilacz lub stację dokującą i osiągnąć poziom pełnego naładowania w czasie nie dłuższym niż 5 godziny. Wymaga się wyposażenia czytnika w dodatkowy akumulator wraz z ładowarką do tej baterii.

22) Konfiguracja czytnika musi odbywać się poprzez kabel lub stację dokującą (za pośrednictwem komputera stanowiska do obsługi kontrolerów).

23) Zakres temperatur otoczenia pracy czytnika: od -20C do +50C. Między odczytami urządzenie może być przechowywane w temperaturze poniżej zera i nie może to uniemożliwiać dokonywania odczytów zaraz po wejściu do autobusu w temperaturach dodatnich (odporność na kondensację wilgoci w czytniku).

24) Podświetlany kolorowy wyświetlacz LCD minimum 3,5” obsługujący rozdzielczość: minimum VGA 480 x 640 punktów, pozwalający wyświetlać znaki w czytelny sposób.

25) Wyposażony minimum w 42 klawiszową klawiaturę QWERTY z podświetleniem.

26) Wyposażony w zintegrowany czytnik kart płatniczych, który musi obsługiwać wszystkie popularne Systemy kart płatniczych i kredytowych, zarówno kart stykowych (karty z chipem i karty z paskiem magnetycznym), jak i bezkontaktowych. Czytnik musi posiadać odpowiednie certyfikaty akceptowane przez organizacje płatnicze na terenie Polski (minimum qVSDC i TIP Contactless).

27) Wyposażony w PIN pad.

IV.10.6. Karta kontrolera.

97

Karta kontrolera jest rodzajem Karty e-bilet o charakterystyce identycznej z Kartami e-bilet – nośnikami biletu elektronicznego. Służy do:1) identyfikacji kontrolera,2) blokowania systemów biletowych w autobusach w celu kontroli biletów,3) przenoszenia danych z systemu autobusowego do czytnika kontrolerskiego.

98

V. Podsystem dynamicznej informacji pasażerskiej (Podsystem DIP) w czasie rzeczywistym i zarządzania ruchem obejmujący geolokalizację autobusów.

V.1. Elementy Podsystemu DIP.Podsystem DIP w czasie rzeczywistym i zarządzania ruchem obejmujący geolokalizację autobusów składa się z:1) Modułu informacji pasażerskiej, 2) Modułu dyspozytorskiego, lokalizacji autobusów i bezpieczeństwa.Zamawiający w ramach przedmiotu zamówienia oczekuje dostawy, instalacji i konfiguracji Oprogramowania i urządzeń przedstawionych poniżej:1) Oprogramowanie w ramach Systemu Centralnego (dostawa, instalacja i

konfiguracja).2) Tablice DIP (dostawa, instalacja i konfiguracja) – 40 szt. w ramach projektu

„Czysta komunikacja publiczna – zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz modernizacja infrastruktury towarzyszącej transportowi publicznemu – etap I” i 4 szt. w ramach projektu „Bezpieczny transport w Opolu”.

V.2. Opis funkcjonalności i działania Oprogramowania.V.2.1. Zarządzanie liniami.1) mapowanie nazwy linii, z nazwy alfanumerycznej na linię numeryczną;2) dodawanie i przypisanie Operatora do linii lub poszczególnych brygad na linii; 3) oznakowanie tzw. linii balonowej (tzw. agrafki – przy spełnieniu kilku

określonych warunków – niektóre kolejne kursy na linii mogą być scalane w jeden);

4) wyłączenie wybranych linii lub brygad z rzeczywistego prognozowania odjazdów autobusów z przystanków.

V.2.2.Zarządzanie przystankami.1) edycję i zarządzanie pozycjami GPS przystanków (w formacie WGS84);2) dodanie przystanku agrafkowego, określanie indywidualnego promienia strefy

GPS; 3) przypisywanie przystankowi cech takich jak punkt kontroli, przystanek

wirtualny, zajezdnia, na żądanie, etc.;4) dowolne grupowanie przystanków i przypisywanie im komunikatów

wyświetlanych po wybraniu przystanku wchodzącego w skład grupy.

V.2.3. Zarządzanie bazą odcinków międzyprzystankowych.1) tworzenie kształtów odcinków międzyprzystankowych z wykorzystaniem

funkcji autoroutingu (automatyczne wyznaczanie trasy przejazdu), a także

99

metody „drag and drop” (przeciągnij i upuść). Użytkownik może zbudować osobiście cały kształt trasy na zasadzie tworzenia „drag and drop", dodatkowo naniesienie na trasie punktu pośredniego i uruchomienie funkcji autoroutingu automatycznie proponuje użytkownikowi kształt poprowadzony ulicami i przechodzący przez uprzednio naniesiony punkt pośredni;

2) przypisywanie numeru strefy taryfowej do danego odcinka międzyprzystankowego na danej linii – dany odcinek dla każdej linii przebiegającej przez niego może mieć inny numer strefy taryfowej.

V.2.4. Zarzadzanie bazą autobusów.1) zarządzanie aktualnym stanem autobusów; 2) przypisywanie numeru bocznego, opisu autobusu, aktualnie wykorzystywanych

cech (krótki, długi, niska podłoga, standard/ponad standard), nazwy Operatora, daty produkcji i inne cechy ustalone na etapie realizacji Systemu);

3) weryfikację zgodności brygad planowanych z realizowanymi, z powiadamianiem dyspozytora o niezgodnościach.

V.2.5. Komunikator.1) wysyłanie komunikatów tekstowych na terminal kierowcy danego numeru

bocznego autobusu; 2) wysyłanie komunikatów do wszystkich autobusów, aktualnych autobusów

będących na danej linii lub będących w danym obszarze.

V.2.6. Przycisk antynapadowy.1) Wykonawca skonfiguruje na Autokomputerze lub Sterowniku e-biletu przycisk

antynapadowy. Lokalizacja przycisku musi być uzgodniona z Zamawiającym. Wciśnięcie przez kierowcę przycisku przypisanego funkcji antynapadowej (tzw. panic button) powinno spowodować pojawienie się na monitorze wyznaczonego stanowiska obsługi systemu ekranu mapy z wycentrowaną aktualną pozycją GPS autobusu, w którym dokonano takiego wciśnięcia i powiadomieniem dźwiękowym. Równocześnie powinna zostać uruchomiona transmisja danych z systemu monitoringu autobusu (video i audio);

2) rejestracja zdarzeń wciśnięcia przycisku alarmu antynapadowego w bazie – zapisywanie do bazy numeru bocznego, godziny i daty zdarzenia;

3) powinno być możliwe zapisanie w bazie przez dyspozytora dodatkowych informacji o alarmie (np. wezwanie policji, omyłkowe uruchomienie alarmu).

V.2.7. Objazdy.Możliwość tworzenia i zarządzania szybkimi objazdami.

100

V.2.8. Synoptyczny schemat linii.1) podgląd autobusów na synoptycznym schemacie linii (tzw. koraliki),

uwzględniającym wszystkie kierunki i warianty występujące na linii; 2) na koralikach poza naniesionym odcinkami międzyprzystankowymi

wyświetlany jest autobusz informacją o numerze bocznym, aktualnym opóźnieniu, brygadzie;

3) informacje o autobusach powinny być zróżnicowane kolorystyczne w zależności od wielkości odchyłki względem rozkładu teoretycznego (opóźnienie/przyspieszenie);

4) możliwość przełączania pomiędzy naniesieniem przystanków na osi w odstępach proporcjonalnych do odległości międzyprzystankowych pomiędzy danymi przystankami lub odległościach równych;

5) prezentacja przemieszczania lokalizacji autobusów na koralikach powinna być płynna i nanoszona adekwatnie do wartości procentowego pokonania odcinka;

6) kliknięcie na dany autobus przypisany do zadania na linii powinno powodować wyróżnienie pozostałej do pokonania trasy wraz z informacją dot. prognozy przybycia na kolejne przystanki trasy;

7) kliknięcie na danym przystanku powinno pokazywać informację o możliwych przesiadkach i rozkładach jazdy.

V.2.9. Wirtualny monitor.1) wybór dowolnego przystanku i podgląd prognozy odjazdów wraz z ich

jednoczesną prezentacją na mapie autobusów zbliżających się do wybranego przystanku. Informacja o odchyłce względem teoretycznego rozkładu jazdy, numerze bocznym autobusu, godzinie teoretycznej odjazdu;

2) Moduł interfejsu API (interfejs programowania aplikacji) (JSON) do wymiany danych pozycji GPS w czasie rzeczywistym dla zewnętrznych podmiotów współpracujących z Organizatorem lub Operatorem – zbiór kilku relacyjnych zasobów JSON udostępniających dane dot. prognozy odjazdu, listy linii i kierunków, przystanków przypisanych do kierunków, przystanków, ulic, przystanków przypisanych do ulic.

V.2.10. Zgłaszanie Awarii.1) możliwość dodawania wszystkich urządzeń i Oprogramowań funkcjonujących w

sferze komunikacji miejskiej, w tym Systemów Pokładowych Autobusów i Systemów Zajezdniowych, a także Tablic DIP. Zgłoszenie Awarii powinno polegać na wybraniu (odfiltrowaniu) z listy grupy urządzeń np. aby zgłosić niedziałającą tablicę LED w pojeździe należy wybrać grupę AUTOBUSY -> NUMER BOCZNY AUTOBUSU -> GRUPĘ TABLIC -> WŁAŚCIWĄ TABLICĘ i opisać problem;

2) powinna istnieć możliwość rozbudowy listy, jej modyfikacji a także dodawania dodatkowych poziomów i grup urządzeń. Do każdej grupy urządzeń jest możliwość przypisania uprzednio zdefiniowanego użytkownika będącego

101

przedstawicielem gwaranta/serwisanta. Każde zgłoszenie jest rejestrowane z możliwością zmiany jego statusów i mailowym powiadomieniem każdej zmiany statusu.

V.2.11. Import danych.1) import danych rozkładowych z programu do tworzenia rozkładów jazdy lub z

innych źródeł dostosowanych specjalnie na potrzeby Systemu oraz przetworzenie tych rozkładów do postaci wymaganej przez Podsystem DIP;

2) pobieranie danych o bieżących pozycjach GPS z autobusów z częstotliwością maksimum 5 sekund;

3) możliwość sumowania dwóch różnych równoległych źródeł sygnału GPS z tego samego autobusu;

4) synchronizacja czasu wszystkich elementów Systemu z serwera NTP.

V.2.12. Eksport danych.1) możliwość przekazania strumienia danych o bieżącej pozycji GPS autobusów

na wskazany port i adres IP;

2) interfejs API (JSON) do wymiany danych pozycji GPS w czasie rzeczywistym dla zewnętrznych podmiotów współpracujących z Organizatorem lub Operatorem – zbiór kilku relacyjnych zasobów JSON;

3) dostępne na zewnątrz API (format JSON) dot. możliwości pobierania bieżących danych o położeniu i taryfie dla danego autobusu. Na zapytanie do Systemu Centralnego, którego parametrem jest nr boczny autobusu i ew. pozycja GPS urządzenia, w przypadku autobusu będącego online (działające GSM i GPS) System Centralny powinien zwrócić w postaci zasobu JSON informację dot. cech danego autobusu i bieżących parametrów obsługiwanego przez autobus kursu. Powinny to być m.in takie informacje jak: typ autobusu, nazwa Operatora, nr obsługiwanej linii, numer brygady, flaga czy autobus jest online, czas ostatniego wysłania pozycji GPS, pozycja GPS autobusu, listę kolejnych przystanków na kursie wraz z informacją o odległości między przystankami i informacją o strefach taryfowych dla kolejnych przystankach, poprzedni i następny przystanek. W przypadku kiedy autobus jest offline zasób zwraca teoretyczną informację, gdzie autobus być powinien.

V.2.13. Funkcjonalność Tablic DIP.1) zarządzanie Tablicami DIP i wyświetlanymi na nich komunikatami; 2) konfigurację i grupowanie Tablic DIP;3) wysyłanie komunikatów tekstowych i graficznych na Tablice DIP;4) podgląd rzeczywistych treści wyświetlanych na poszczególnych Tablicach DIP,

z regulowaną manualnie częstotliwością odświeżania w zakresie 1-10 sekund;

102

5) dodawanie dodatkowych zapowiedzi dźwiękowych niedotyczących odjazdów wraz z przypisaniem im grupy Tablic DIP, harmonogramu i częstotliwości emisji bez konieczności wciskania przycisku wyzwalającego zapowiedzi;

6) automatyczną wymianę i aktualizację plików zapowiedzi dźwiękowych dot. numeru linii i nazwy przystanku końcowego (nazwy kierunku) do Tablic DIP;

7) wszystkie przypisane do linii, przystanków, pliki dźwiękowe możliwe do odsłuchania z poziomu Systemu Centralnego;

8) nadzór nad pracą Tablic DIP.

V.2.14. Funkcjonalność centralnych priorytetów dla transportu publicznego.1) odpowiedzialna jest za prognozowanie przybycia autobusów na

skrzyżowaniach, na podstawie danych z Systemu Centralnego oraz danych pozyskanych z zewnętrznego systemu sterowania ruchem (ITS), nadawanie centralnych priorytetów autobusom i ich przekazywanie do zewnętrznego systemu sterowania ruchem ITS;

2) definiowanie skrzyżowań, relacji na nich, pobieranie danych niezbędnych do nadania priorytetów autobusom, przetworzenie ich, w tym prognozę przybycia autobusów do skrzyżowania oraz przesłanie w postaci właściwych telegramów do sterowników świateł przy udziale systemu sterowania ruchem;

3) wymiana danych z zewnętrznym systemem ITS (wysyłanie i odbiór) z możliwością uwzględnienia sytuacji drogowej w prognozach przyjazdów i odjazdów autobusów do i z przystanków.

V.2.15. Zarządzanie użytkownikami.1) przypisywanie każdemu użytkownikowi z osobna jego grup (np. Operator,

Organizator, wykonawca etc.) i ról: Administrator, Dyspozytor, stanowisko rozliczeniowe, Organizator, itp.;

2) edytowanie przypisanych użytkownikowi ról i funkcji; 3) przypisywanie rolom praw do wykonywania określonych czynności;4) określenie poziomu dostępu i prawa zapisu do poszczególnych baz danych i

funkcjonalności Systemu Centralnego dla różnych grup użytkowników, w tym grupy Dyspozytorów, a także tej posiadającej pełny zakres (grupa Administratorów). Administrator będzie miał możliwość tworzenia dowolnych grup i przypisywania im wybranych funkcji (ról) i uprawnień;

5) zmianę haseł zarówno przez administratora, jak i samego użytkownika.

V.2.16. Prognozowanie czasów przejazdu.1) algorytm prognozujący przybycie autobusów na przystanek powinien

uwzględniać opóźnienie na kursach poprzedzających odjazd danego autobusu;2) prognozowanie przybycia autobusów powinno odbywać się na poziomie

centralnym w Systemie Centralnym tj. pozycje GPS wysyłane z autobusów powinny służyć do pomiaru czasu przejazdu danych ciągów komunikacyjnych, dzięki czemu Podsystem DIP urealnia wyświetlane wyniki;

103

3) w przypadku uruchomienia zewnętrznego systemu ITS, Podsystem DIP musi uwzględniać aktualną sytuację drogową, w predykcji czasu przybycia autobusów;

4) niedopuszczalne jest budowanie mechanizmu prognozowania przybycia autobusów według zasady, że każdy autobus jednocześnie z pozycją GPS wysyła aktualną odchyłkę od rozkładu jazdy obliczaną w Autokomputerze, a System Centralny tylko sortuje otrzymane wyniki, przeprowadzając wyłącznie operacje dodawania lub odejmowania otrzymanej odchyłki od rozkładu jazdy;

5) dostęp do pliku konfiguracyjnego algorytmu prognozującego, w celu ręcznej zmiany zakresu historycznego przedziału czasu dla którego następuje estymacja;

6) zastosowanie w Podsystemie DIP minimum dwóch udokumentowanych algorytmów prognozujących przybycie autobusów np. wielomianowego – możliwość codziennego przełączania przez Zamawiającego;

7) w przypadku kiedy autobus nie ma łączności GSM, kurs autobusu prezentowany jest na Tablicach DIP i w serwisie POP, w formacie HH:MM;

8) możliwość sprawdzania jakości prognozy przyjazdu autobusu na przystanek. W celu dokonania sprawdzenia predykcji należy dokonać wyboru daty, przystanku, godziny odjazdu dla danej linii, a następnie można sprawdzić jak kształtowała się prognoza odjazdu autobusu w przedziale najbliższych 30 minut poprzedzających odjazd z rozdzielczością równą okresowi wysyłania telegramów z autobusu (min. co 10 sekund);

9) możliwość weryfikacji jakości predykcji w oparciu o statystykę tj. porównanie faktycznych czasów przyjazdu z prognozami – syntetycznie i analitycznie (tj. od informacji ogólniej – dla całego Systemu, do szczegółowej, w tym na poziomie przystanku).

V.2.17. Funkcjonalność analizy punktualności.Możliwość rozliczania przewoźnika, tworzenia kar umownych, cenników, realizacja wykonywanych zadań, usprawiedliwienia, wykluczenia.

V.2.18. Funkcjonalność dyspozytorska.1) tworzenie raportu dyspozytora dla wybranego Operatora na dany dzień; 2) możliwość definiowania w czasie rzeczywistym podmian bieżących i

przyszłych na podstawie wyboru właściwego kursu i wskazania przystanku podmiany;

3) możliwość importu danych z pliku CSV;4) podgląd na mapie pozycji autobusu z naniesioną trasą realizowanego kursu i

informacją o jego realizacji w tym odchyłce od rozkładu jazdy, prędkości chwilowej, linii i wariancie trasy;

5) podgląd historyczny pozycji autobusów – od dnia i godziny, do dnia i godziny;6) zamawiający wymaga, aby okno podglądu historycznego autobusów zawierało

następujące dane: brygada, linia, przystanek, czas rozkładowy oraz rzeczywisty, a także punktualność – różnica wynikająca z wyżej opisanych czasów;

104

7) możliwość podglądu historycznego przedstawiającego w sposób graficzny rzeczywistą trasę przejazdu danego autobusu;

8) zamawiający wymaga, aby podgląd autobusów na mapie informował w sposób wizualny (odpowiednia zmiana koloru autobusu) oraz dźwiękowy o przyspieszeniach i opóźnieniach autobusów według zdefiniowanych uprzednio wartościach progowych;

9) podgląd na mapie pozycji autobusów wraz z informacją o nazwie autobusu, numerze brygady, linii, kierunku, punktualności do których zostanie zastosowana opcja filtrowania;

10) możliwość autobusów w zależności od odchyłki od rozkładu jazdy, linii, brygady, położenia na mapie;

11) możliwość podglądu wybranego autobusu na mapie poprzez wyeksponowanie go na tle innych autobusów znajdujących się na mapie;

12) możliwość podglądu na mapie przystanków, z opcją ich filtrowania w zależności od linii;

13) wykrywanie i informowanie o obecności autobusów w uprzednio zdefiniowanych w Podsystemie DIP obszarach (poligonach) miasta, ulic, zajezdni;

14) wykorzystanie w Podsystemie DIP bezpłatnego podkładu Open Street Map (OSM) i zastosowanie nowoczesnej biblioteki OpenLayers3 do prezentacji punktów POI i innych elementów mapy;

15) Zamawiający wymaga informowania w sposób wizualny oraz dźwiękowy o niezgodności w trasie przejazdu autobusu względem zdefiniowanej trasy linii;

16) wykrywanie i informowanie o niewykonywanych (zawieszonych) kursach w sposób graficzny.

V.2.19. Funkcjonalność analizy i diagnostyki.1) analiza i raportowanie wszystkich danych dostarczonych z autobusu;2) automatyczne wykrywanie i raportowanie (w postaci komunikatów, maili)

długotrwałych absencji urządzeń peryferyjnych w autobusach i tablic informacyjnych;

3) bieżącą kontrolę stanu Urządzeń i informowania o problemach, Awariach. Monitorowanie stanu ma być realizowane m.in. dla urządzeń w pojeździe, Tablic DIP. Poprzez monitorowanie stanu urządzeń Zamawiający rozumie automatyczną – wg zadanego harmonogramu – kontrolę funkcjonowania urządzenia (np. za pomocą protokołu ICMP) a także wysyłanie przez same urządzenie informacji o Awariach (w miarę możliwości funkcjonalnej i sprzętowej);

4) powiadamianie administratorów, wyznaczonych użytkowników i Wykonawcy Systemu o problemach, awariach (poprzez mail, komunikat na ekranie);

5) analiza czasów międzyprzystankowych dla wybranych linii oraz typów dnia.

V.3. Tablice DIP.1. W ramach projektu „Czysta komunikacja publiczna – zwiększenie mobilności

mieszkańców Aglomeracji Opolskiej oraz modernizacja infrastruktury towarzyszącej transportowi publicznemu – etap I” zostanie zakupionych 40

105

sztuk Tablic DIP oraz kolejne i 4 szt. w ramach projektu „Bezpieczny transport w Opolu”. Razem 44 szt. Tablic DIP będą stanowić główny element Podsystemu DIP.Tablice DIP zostaną zamontowane na przystankach, w miejscach o największym natężeniu potoków pasażerskich, zgodnie z posiadaną przez Zamawiającego dokumentacją projektową na wykonanie przyłączy energetycznych dla tych urządzeń. Tablice DIP zostaną zamontowane na konstrukcji wsporczej na wysokości minimum 2,7 m od powierzchni chodnika. Tablice DIP muszą zostać wykonane w technologii LED, być wandaloodporne, odporne na korozję i czynniki atmosferyczne.

2. Wykonawca dostarczy, zainstaluje i dokona konfiguracji elektronicznych Tablic DIP w określonych przez Zamawiającego lokalizacjach. Wymiana informacji i integracja pomiędzy Tablicami DIP, a Systemem Centralnym leżą po stronie Wykonawcy. W pierwszym etapie wdrożenia Zamawiający wymaga, aby Tablice DIP współpracowały z obecnie istniejącym systemem „kiedy przyjedzie.pl”, prezentując informacje dostarczane przez ten system. Po wyposażeniu floty autobusów w niezbędne urządzenia, Tablice DIP będą wyświetlać dane z Podsystemu DIP. Koszty transmisji danych do/z Tablic DIP pokrywa Zamawiający.

3. Główne założenia dotyczące funkcjonalności Tablic DIP:Tablice DIP powinny być wyposażone w:1) dwustronny wyświetlacz LED, w komplecie z dedykowanymi słupami (całość

ocynkowana i trwale zabezpieczona przed korozją);

2) wyświetlacz LED na 6 wierszy + 1 wiersz (na dole wyświetlacza) na komunikaty specjalne;

3) statyczne pole opisowe, w górnej części Tablicy DIP, zawierające informacje o nazwie przystanku, logo miasta i programu unijnego oraz nagłówki kolumn;

4) Moduł transmisji danych;5) kamerę kolorową, która obserwuje i rejestruje wszystkie działania przed

Tablicą DIP (z obu stron),6) syntezator mowy dla niepełnosprawnych7) zegar elektroniczny.

Wyświetlane na Tablicach DIP prognozy czasu przyjazdu autobusów powinny być rozmieszczone na wyświetlaczu Tablicy DIP w trzech kolumnach (kolumna z oznaczeniem numeru linii, kolumna z oznaczeniem kierunku jazdy, kolumna z czasem pozostałym do odjazdu);4. Zestawienie ilościowe Tablic DIP.

Wykonawca jest zobowiązany w ramach umowy dostarczyć 44 siedmiowierszowych Tablic DIP, wykonanych w technologii LED.

106

5. Lokalizacja Tablic DIP.

1) Lokalizację Tablic DIP zakupionych w ramach projektu „Czysta komunikacja publiczna – zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz modernizacja infrastruktury towarzyszącej transportowi publicznemu - etap I” przedstawia poniższa tabela.

Tabela 2. Lokalizacja Tablic DIP

Lokalizacje dla Tablic DIP w ramach projektu „Czysta komunikacja publiczna – zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz modernizacja infrastruktury towarzyszącej transportowi publicznemu - etap I”

L.p. Nazwa przystanku autobusowego Kierunek Numery działek* Arkusz mapy Obręb

1. Opole, 1 Maja – Dworzec Główny, 01 ul. Piastowska 58/1 49 Opole

2. Opole, 1 Maja – Dworzec Główny, 02 ul. Reymonta 58/2, 65, 66/1 49 Opole

3. Opole, 1 Maja – Katowicka, 05 Dworzec Główny 25 53 Opole

4. Opole, 1 Maja – Szkoła, 15 Dworzec Główny 127/1

7455 Opole

5. Opole, Chabrów – Szkoła, 08 ul. Luboszycka 543/17 12 Zakrzów

6. Opole, Chabrów, 04 ul. Luboszycka 540, 535/35, 1354 11 Zakrzów

7. Opole, Cmentarz – Pętla, 02 Centrum 29/19 29 Półwieś

8. Opole, Dambonia – Pętla, 02 Centrum 89/11, 89/10 34 Szczepanowice

9. Opole, Kołłątaja – Damrota – Dworzec Główny, 03 ul. 1 Maja 38/11, 38/20, 40 49 Opole

10. Opole, Książąt Opolskich – Rondo, 05 Centrum 2/16, 2/19 42 Opole

107

Lokalizacje dla Tablic DIP w ramach projektu „Czysta komunikacja publiczna – zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz modernizacja infrastruktury towarzyszącej transportowi publicznemu - etap I”

L.p. Nazwa przystanku autobusowego Kierunek Numery działek* Arkusz mapy Obręb

11. Opole, Książąt Opolskich – Rondo, 06 Nysy Łużyckiej 6/11, 6/12 42 Opole

12.

Opole, Niemodlińska – Koszyka, 03UWAGA!W tej lokalizacji zostanie (lub został już) wykonany przepust kablowy dla zasilania Biletomatu i Tablicy DIP (w ramach przebudowy ul. Niemodlińskiej w 2017 roku).

Centrum1448/35,8/10 (OUW)

2638 Półwieś Szczepanowice

13.

Opole, Niemodlińska – Koszyka, 04UWAGA!W tej lokalizacji zostanie (lub został już) wykonany przepust kablowy dla zasilania Tablicy DIP(w ramach przebudowy ul. Niemodlińskiej w 2017 roku).

Chmielowice144,141, 138 (OUW)8/35

2638 Półwieś Szczepanowice

14.

Opole, Niemodlińska – Szkoła, 07UWAGA!W tej lokalizacji zostanie (lub został już) wykonany przepust kablowy dla zasilania Tablicy DIP(w ramach przebudowy ul. Niemodlińskiej w 2017 r.).

Centrum 20/4, 20/8 (OUW) 35 Szczepanowice

15. Opole, Nysy Łużyckiej – Rondo, 03 ul. Wrocławska 1/3 (OUW) 42 Opole

16. Opole, Nysy Łużyckiej – Rondo, 04 ul. Oleska 6/1 (OUW)

6/11, 6/12 42 Opole

108

Lokalizacje dla Tablic DIP w ramach projektu „Czysta komunikacja publiczna – zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz modernizacja infrastruktury towarzyszącej transportowi publicznemu - etap I”

L.p. Nazwa przystanku autobusowego Kierunek Numery działek* Arkusz mapy Obręb

17. Opole, Okulickiego, 01 ul. Oleska 35/13, 35/14, 35/18, 36/2 17 Opole

18. Opole, Ozimska – Dubois, 03 Centrum 25/17,

46 (OUW) 48 Opole

19. Opole, Ozimska – Dubois, 04 ul. Plebiscytowa 46, 76 (OUW) 48 Opole

20. Opole, Ozimska – Katowicka, 07 Centrum 40/4,

41/1 (OUW) 47 Opole

21. Opole, Ozimska – Katowicka, 08 ul. Częstochowska 40/4,

48/2 (OUW) 47 Opole

22. Opole, Ozimska – Malinka, 23 Centrum 23 (OUW)

115/25 (OUW)571

OpoleKol. Gosławicka

23. Opole, Ozimska – Plebiscytowa, 11 Centrum 47,

38/2 (OUW) 46 Opole

24. Opole, Ozimska – Plebiscytowa, 12 ul. Częstochowska 1/4, 1/5 (OUW) 55 Opole

25. Opole, Piastowska, 03 ul. Spychalskiego 38, 12/6, 11/20, 12/4, 11/29, 8,

11/19, 11/17 43 Opole

26. Opole, Piastowska, 04 Dworzec Główny 38, 12/6, 11/20, 12/4, 11/29, 8,

11/19, 11/17 43 Opole

109

Lokalizacje dla Tablic DIP w ramach projektu „Czysta komunikacja publiczna – zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz modernizacja infrastruktury towarzyszącej transportowi publicznemu - etap I”

L.p. Nazwa przystanku autobusowego Kierunek Numery działek* Arkusz mapy Obręb

27. Opole, Plac Jana Kazimierza, 01 ul. Wrocławska 129/6, 129/7 (OUW) 41 Opole

28. Opole, Plac Jana Kazimierza, 02 ul. Koszyka 18/2 (OUW)

4/4, 6/3 (OUW)4125 Opole

29. Opole, Plac Kopernika – Kamienna, 02 ul. Ozimska 129/15, 130/2 44 Opole

30. Opole, Plac Kopernika – Pętla, 01 ul. Sienkiewicza 101/2, 100

79, 76/84244 Opole

31.

Opole, Prószkowska – Politechnika, 07(dawna nazwa „Opole, Prószkowska - Kościół, 07”)UWAGA!W tej lokalizacji został już wykonany przepust kablowy dla zasilania Biletomatu i Tablicy DIP(w ramach budowy ronda w 2016 roku).

Centrum 25/8, 25/13 (OUW) 39 Szczepanowice

32. Opole, Reymonta, 05 ul. Ozimska 11/7 (OUW) 53 Opole

33. Opole, Sienkiewicza, 01 Pl. Kopernika 24/25

8/24442 Opole

34. Opole, Sosnkowskiego – Fieldorfa, 23 ul. Okulickiego 72, 2/6

41723 Opole Gosławice

35 Opole, Sosnkowskiego – Małopolska, 08 ul. Horoszkiewicza 1341, 1336/2, 1337/1 22 Gosławice

110

Lokalizacje dla Tablic DIP w ramach projektu „Czysta komunikacja publiczna – zwiększenie mobilności mieszkańców Aglomeracji Opolskiej oraz modernizacja infrastruktury towarzyszącej transportowi publicznemu - etap I”

L.p. Nazwa przystanku autobusowego Kierunek Numery działek* Arkusz mapy Obręb

.

36. Opole, Sosnkowskiego – Politechnika, 19 ul. Okulickiego 14/4, 9/19, 8/3, 7/3, 74/1, 9/20, 9/18 17 Opole

37. Opole, Sosnkowskiego – Wiejska, 04 ul. Horoszkiewicza 1317/42, 1317/43, 1337/1 22 Gosławice

38. Opole, Spychalskiego, 01 Centrum 47/10, 97/9 41 Opole

39. Opole, Spychalskiego, 02 Zaodrze 47/10, 97/9 41 Opole

40. Opole, Witosa – Szpital , 07 ul. Ozimska 422/3 2 Kolonia Gosławicka

* - wśród wymienionych numerów działek znajdują się działki, na których zainstalowane zostaną przedmiotowe Tablice DIP oraz działki, przez które przebiegać będą wewnętrzne linie zasilające (WLZ) dla zasilania tych urządzeń. Numery działek dla każdej lokalizacji odpowiadają numerom wymienionym w Zgłoszeniach Budowy Obiektów (zgłoszenia do Urzędu Miasta Opola oraz do Urzędu Wojewódzkiego). Zgłoszenia do Urzędu Wojewódzkiego oznaczono (OUW).

2) Lokalizację Tablic DIP zakupionych w ramach projektu „Bezpieczny transport w Opolu” przedstawia poniższa tabela.Tabela 2a. Lokalizacja Tablic DIP

111

Lokalizacje dla Tablic DIP w ramach projektu „Bezpieczny transport w Opolu”

L.p. Nazwa przystanku autobusowego Kierunek Numery działek* Arkusz mapy Obręb

1. Opole, Budowlanych – Kępska, 19 ul. Nysy Łużyckiej 709 13 Zakrzów

2. Opole, Budowlanych – Prudnicka, 11 ul. Nysy Łużyckiej 1025 15 Zakrzów

3. Opole, Marka z Jemielnicy – Aleja Przyjaźni, 12 Centrum 2 76 Nowa Wieś Królewska

4. Opole, Walecki, 02 Centrum 37 76 Nowa Wieś Królewska

112

6. Projektowanie i montaż konstrukcji wsporczej i Tablic DIP.Wykonawca zobowiązany jest do wykonania następujących prac: 1) Opracowania koncepcji architektoniczno-konstrukcyjnej konstrukcji wsporczej

wyświetlacza LED (wraz z obudową wyświetlacza), a także uzyskanie akceptacji Zamawiającego dla opracowanej koncepcji architektoniczno-konstrukcyjnej.

2) Opracowania harmonogramu robót, w uzgodnieniu z Zamawiającym. 3) Aktualizacji map dla celów projektowych, w zakresie niezbędnym do realizacji

inwestycji. 4) Opracowania niezbędnej dokumentacji projektowej, uwzględniającej warunki

przyłączenia do sieci energetycznej, a także uzyskania akceptacji Zamawiającego dla w/w dokumentacji. Zamawiający posiada dokumentację projektową przyłączy energii elektrycznej.

5) Uzyskania niezbędnych dla realizacji inwestycji uzgodnień i pozwoleń. 6) Wykonania przyłączy energii elektrycznej, dostawę i montaż konstrukcji

wsporczych wyświetlaczy LED (w skład konstrukcji wchodzi obudowa wyświetlacza LED). UWAGA! W 4 lokalizacjach (na przystankach o nazwach: „Opole, Niemodlińska - Koszyka, 03”, „Opole, Niemodlińska - Koszyka, 04”, „Opole, Niemodlińska - Szkoła, 07”, „Opole, Prószkowska - Politechnika, 07”) w ramach prowadzonych wcześniej prac inwestycyjnych („Budowa ronda na skrzyżowaniu ulic Prószkowskiej, Krapkowickiej i Chmielowickiej w 2016 roku” oraz „Przebudowa ulicy Niemodlińskiej w 2017 roku”) zostały wykonane (lub wkrótce zostaną wykonane) przepusty kablowe (rury osłonowe) dla zasilania Biletomatów i/lub Tablic DIP, które planowane są do montażu na danym przystanku.

7) Wykonania, dostawy i montażu Tablic DIP wraz z przyłączeniem ich do sieci energetycznej oraz doprowadzeniem do pełniej sprawności funkcjonalnej.

8) Opracowania geodezyjnej inwentaryzacji powykonawczej. 9) Opracowania technicznej dokumentacji powykonawczej. 10) Przywrócenia terenu budowy do stanu pierwotnego.

7. Wymagania techniczne i funkcjonalne dotyczące Tablic DIP.

7.1. Parametry techniczne, konstrukcyjne, instalacja Tablic DIP.1) Fabrycznie nowe 7 wierszowe Tablice DIP.2) Dostarczone Tablice DIP muszą być dwustronne (wszystkie informacje oraz

wyświetlane dane muszą być identyczne po obu stronach Tablicy DIP).3) Dostarczone Tablice DIP muszą być wykonane w technologii LED SMD z

użyciem diod wysokiej jasności (jasność pojedynczej diody to min. 600 mcd), koloru bursztynowego (amber – długość emitowanej fali w zakresie 590-610 nm).

4) Jasność matrycy LED Tablicy DIP minimum 6000 cd/m2.5) Żywotność diod – czas pracy diod LED przy nie większym niż 50% ubytku

jasności i przy prądzie nominalnym powinien wynosić minimum 85 000 godzin.

113

6) Diody Tablicy muszą charakteryzować się szerokim kątem widzenia min. 110° w poziomie i 110° w pionie. Odchylenie od pionu obudowy Tablicy DIP w kierunku chodnika - od 5 do 8 stopni”.

7) Raster diod od 5 do 7 mm.8) Matryca LED wyświetlająca komunikaty musi posiadać maksymalnie

rozdzielczość 190 pikseli w poziomie i 70 pikseli w pionie.

9) W zależności od lokalizacji szerokość Tablic DIP może się różnić (wynika to z różnych szerokości chodników).

10) Wysokość pojedynczego znaku minimum 48 mm (duża litera), lecz nie mniej niż 8 pikseli (np. litera A).

11) Prawidłowa praca w przedziale temperatur od -25°C do +60°C, w warunkach pełnego nasłonecznienia.

12) Tablice DIP muszą posiadać oznakowanie CE i być z nim zgodne, do oferty należy złożyć wraz z dokumentami deklaracje zgodności dla każdego rodzaju Tablicy DIP.

13) Powierzchnia czołowa Tablic DIP musi być zabezpieczona przed parowaniem i szronieniem.

14) Tablice DIP muszą być wyposażone w czujnik natężenia światła zewnętrznego, który automatycznie dobiera jasność świecenia w zależności od występujących warunków pogodowych i pory dnia, Tablice DIP powinny posiadać czujniki dla każdej ze stron. Zadaniem czujnika natężenia światła zewnętrznego zainstalowanego w Tablicy DIP jest pomiar natężenia światła otoczenia i przesyłanie informacji do układów regulujących jasnością świecenia samej Tablicy DIP. Bez względu na występujące warunki pogodowe i porę dnia Tablica DIP powinna prezentować informację w sposób przejrzysty i czytelny. Czujnik natężenia światła zewnętrznego zainstalowanego w Tablicy DIP nie powinien działać przy krótkotrwałych i przypadkowych zmianach natężenia światła takich jak np. światło przejeżdżających samochodów.

15) Szyby w obudowach Tablic DIP mogą być minimalnie przyciemnione i pokryte zewnętrzną powłoką antyrefleksyjną (w celu wyeliminowania efektu odbijania promieni słonecznych od szyby obudowy) i wandaloodporne.

16) Zamawiający nie dopuszcza rozwiązania w postaci osobnych rzędów paneli dla każdego wiersza tekstu.

17) Tablice DIP muszą być wyposażone w Moduł komunikacyjny GSM. Koszt transmisji danych po uzgodnieniu i zastosowaniu modemu GSM, będzie po stronie Zamawiającego.

18) Zegar elektroniczny powinien być wyświetlany w górnym prawym rogu Tablicy DIP, w formacie HH:MM. Cyfry w zegarze powinny być pogrubione i większe od znaków na Tablicach DIP. Czas na wyświetlaczu powinien być synchronizowany Systemem Centralnym.

19) Tablice DIP muszą być umieszczone w nierdzewnych obudowach, komponenty elektroniczne muszą być zabezpieczone przed skutkami opadów atmosferycznych, wilgoci, zbieraniem się pary wodnej wewnątrz i zapylenia o

114

stopniu ochrony IP65, na co wykonawca przedstawi dokument z badań potwierdzających w/w parametr ochrony.

20) Tablice DIP będą montowane na nowych słupach dostarczonych wraz z fundamentem i zamontowanych przez Wykonawcę.

21) Dolna krawędź Tablicy DIP, musi znajdować się na wysokości minimum 2,7 m nad chodnikiem. W każdym przypadku musi być zachowany odstęp bezpieczeństwa względem krawędzi zatoki autobusowej, jak również względem pasów ruchu, itd. Wykonawca dobierze i zaproponuje Zamawiającemu rozmiary Tablic DIP dla każdej lokalizacji, uwzględniając możliwości terenowe i posiadaną przez Zamawiającego dokumentację na wykonanie przyłączy energetycznych.

22) Wykonawca dostarczy Zamawiającemu, po podpisaniu umowy, projekt montażu Tablic DIP w wybranych lokalizacjach do akceptacji przez Zamawiającego.

23) Słupy do montażu Tablic DIP muszą być zabezpieczone przed korozją i pomalowane zgodnie z kolorystyką palety RAL. Kolorystyka obudowy Tablicy DIP oraz słupów ustalona zostanie z Zamawiającym w trakcie realizacji Systemu.

24) Mocowanie Tablic DIP do słupa musi posiadać zabezpieczenia utrudniające ich kradzież.

25) Wszystkie przewody doprowadzone do Tablic DIP muszą być zabezpieczone przed uszkodzeniem, wyciągnięciem, przecięciem, kradzieżą.

26) Wszystkie kable muszą być schowane wewnątrz struktur wsporczych tak, aby były niewidoczne i nie miały do nich dostępu osoby niepowołane.

27) Odległość od górnej krawędzi matrycy do górnej krawędzi Tablicy DIP nie może przekroczyć 300mm.

28) Wymiary zewnętrzne Tablicy DIP nie mogą przekroczyć: szerokość 1400 mm, wysokość 800 mm. Na podstawie posiadanej dokumentacji dla przyłączy energii elektrycznej Wykonawca określi szczegółowe parametry Tablic DIP dla poszczególnych lokalizacji.

29) Każda Tablica DIP musi zawierać następujące informacje: informację o 6 lub 7 najbliższych odjazdach, logo miasta i programu UE finansującego projekt, a w lewym górnym rogu ekranu umieszczone na obudowie Tablicy DIP, wyśrodkowaną nazwę przystanku, umieszczoną na obudowie Tablicy DIP, napisane i podświetlone na obudowie Tablicy DIP bezpośrednio nad matrycą LED nagłówki kolumn: „Linia” (wyśrodkowane), ,,Kierunek" (wyśrodkowane), ,,Odjazd za" (wyśrodkowane). Pola opisowe muszą być podświetlone elementami wykonanymi w technologii LED. Kolor tła, typ czcionki i wysokość pól opisowych do uzgodnienia z Zamawiającym na etapie wdrożenia. Nazwa przystanku (umieszczona na obudowie Tablicy DIP) musi być wykonana w taki sposób, aby w przyszłości była możliwość dokonania jej zmiany (samodzielnie przez Zamawiającego), bez konieczności demontażu Tablicy DIP.

115

30) Tablice DIP muszą być wyposażone w Moduł zapowiedzi głosowych w formacie MP3 lub WAV, informujący osoby niewidome o godzinie przybycia autobusu lub o czasie (w minutach) jakie zostały do przybycia autobusu, numerze linii i kierunku jazdy, poczynając chronologicznie od autobusów, które przyjadą najwcześniej. Komunikaty powinny być wyemitowane po wciśnięciu dedykowanego, wandaloodpornego przycisku zamontowanego w konstrukcji wsporczej Tablicy DIP. Wciśnięcie przycisku powinno uruchamiać zapowiedź głosową treści informacji o odjazdach prezentowanych na Tablicy DIP. Ponowne wciśniecie wyłącza emisje. Musi istnieć możliwość programowej regulacji głośności emitowanych informacji.

31) Tablice DIP będą wyposażone w kamerę kolorową, która obserwuje i rejestruje wszystkie działania przed Tablicą DIP (z obu stron), a materiał (audio i video, z możliwością wyłączenia trybu audio) z podglądu jest rejestrowany na trwałym nośniku danych (np. dysku twardym) w danej Tablicy DIP i archiwizowany przez minimum 10 dni. Rozdzielczość kamer min. 1280x720. Zapis w cyfrowym rejestratorze wizji i fonii wyposażonym w dysk wymienny zapisujący obraz z prędkością min. 20 klatek na sekundę w rozdzielczości min 640x480. Rejestrator musi posiadać zabezpieczenie przed ingerencją osób trzecich w jego działanie oraz zabezpieczenie przed dostępem do zarejestrowanych materiałów np. poprzez hasło. Tryb nagrywania: ciągły, przez kasowanie najstarszych plików. Przekazywanie plików monitoringu nie może być związane z ograniczeniami licencyjnymi. Ściąganie danych z Tablic DIP powinno być realizowane poprzez wyjście USB 3.0 umieszczone na konstrukcji wsporczej Tablicy DIP w miejscu zabezpieczonym przed osobami niepowołanymi. Kamera powinna mieć tryb nocny, automatycznie uruchamiany po zapadnięciu zmroku.

32) Wszystkie Tablice DIP muszą posiadać zamek specjalizowany, być zabezpieczone przed atakami wandalizmu oraz posiadać urządzenia do sygnalizowania Operatorowi np. nieautoryzowane otworzenie Tablicy DIP.

33) Pracownicy serwisu muszą mieć łatwy dostęp do poszczególnych elementów Tablic DIP i ich wszystkich podzespołów elektronicznych. Wymagane jest zastosowane bezpiecznego otwierania wszystkich zamków do Tablic DIP za pomocą jednego specjalizowanego klucza.

34) Wszystkie Tablice DIP powinny zostać wyposażone w zabezpieczenia różnicowo prądowe i przeciwprzepięciowe nie gorsze niż wyłącznik B16A/0,03/2 1-f różnicowo-prądowy oraz ochronnik przepięć BY1-B/1 B+C 65kA na szynie TH.

35) Tablica DIP musi być odporna na wszystkie zakłócenia wywoływane przez biegnące w pobliżu linie elektryczne.

36) Tablice DIP muszą być wyposażone w urządzenie do komunikacji za pośrednictwem sieci GSM. Aktywne karty SIM dla Tablic DIP zapewnia Zamawiający. Koszty transmisji do/z Tablic DIP w trakcie trwania gwarancji pokrywa Zamawiający. Tablica DIP będzie komunikować się z serwerem przez połączenie GSM. Tablica DIP musi obsługiwać wymianę danych z serwerem

116

zapewniającą spełnienie wszystkich wymagań stawianych Tablicy DIP i Podsystemowi DIP.

37) Wykonawca zrealizuje wszystkie niezbędne prace związane z zamontowaniem i uruchomieniem Podsystemu DIP, w tym m.in., związane z wykonaniem fundamentów, prowadzeniem okablowania energetycznego, montażem Tablic DIP. Zabezpieczenie przyłącza energetycznego/punktu zasilania 230V 50Hz i zgody właścicieli terenu – po stronie Wykonawcy. Wykonawca jest zobowiązany do ujęcia w ofercie i wykonania prac budowlanych i doprowadzenia do każdej z Tablic DIP instalacji elektrycznej zgodnie z projektem budowlanym przygotowanym przez Zamawiającego.

38) W przypadku zaniku napięcia zasilania, po jego przywróceniu będzie zapewniony automatyczny start Tablicy DIP.

7.2. Funkcjonalność Tablic DIP.1) Informacje prezentowane na Tablicach DIP dotyczyć będą najbliższych 90

minut (parametr definiowalny dla każdej Tablicy DIP). W sytuacji, gdy liczba danych o potwierdzonych, a także teoretycznych odjazdach będzie mniejsza od liczby wierszy na Tablicy DIP, pozostałe wiersze pozostają puste lub wyświetlana powinna być informacja dot. teoretycznych odjazdów linii. Dopuszcza się modyfikację przez Wykonawcę powyższego scenariusza po uzgodnieniu z Zamawiającym.

2) Informacje wyświetlane na Tablicach DIP muszą być w czcionce proporcjonalnej lub innej gwarantującej dobrą czytelność napisów.

3) Układ informacji wyświetlanych na Tablicach DIP (we wszystkich liniach prezentujących informacje o odjazdach) winny wyświetlać w każdym wierszu minimum 30 znaków oraz przerwy pomiędzy numerem linii, kierunkiem kursu oraz czasem odjazdu zgodnie z następującym układem: a) oznaczenie numeru linii: 3 znaki alfanumeryczne oraz 2 diody odstępu z

wyrównaniem do prawego marginesu. b) kierunek kursu: co najmniej 20 znaków alfanumerycznych oraz 2 diody

odstępu z wyrównaniem do lewego marginesu.

c) czas do odjazdu: 5 znaków alfanumerycznych z wyrównaniem do prawego marginesu, w przypadku czasu rozkładowego w układzie „HH:MM” (np. 08:59), w przypadku wyświetlania czasu rzeczywistego „MMmin” (np. 08min).

4) W przypadku, gdy komunikat o odjazdach tj. kierunek kursu autobusu będzie dłuższy niż ilość znaków w dedykowanej linii to Tablice DIP będą przewijały (skrolowały) poziomo komunikat celem ukazania całej jego treści.

5) Informacje o odjazdach na Tablicach DIP muszą być posortowane narastająco wg czasu pozostałego do odjazdu.

6) Każdy wiersz wyświetlanej informacji musi być oddzielony od kolejnego wiersza minimum o jedną diodę.

117

7) Szerokość znaku nie mniej niż 5 pikseli, przy czym należy pamiętać, że znaki nie mogą się łączyć, zlewać, musza być zachowane proporcję oddzielające każdą literę, cyfrę, minimum jedna dioda.

8) Wysokość pojedynczego znaku minimum 48 mm (duża litera), lecz nie mniej niż 8 pikseli (np. litera A).

9) Zastosowana czcionka powinna być proporcjonalna do parametrów znaku.10) W przypadku braku danych o rzeczywistym czasie odjazdu danego

autobusu Tablica DIP powinna wyświetlić informację rozkładową. Rozkład jazdy musi być dostępny dla Tablic DIP niezależnie od połączenia z serwerem. Za wyświetlanie i przetwarzanie rozkładów w pamięci odpowiedzialny ma być komputer przemysłowy.

11) Na jedną minutę przed rzeczywistym, czyli potwierdzonym przez Podsystem DIP, odjazdem autobusu z przystanku wiersz z informacją o odjeździe powinien być wyróżniony np. zacząć pulsować.

12) Po odjeździe autobusu z przystanku godzina jego odjazdu musi zostać usunięta z Tablicy DIP, a prezentowany na Tablicy DIP rozkład musi ulec przesunięciu o jeden wiersz do góry. W pustym wierszu musi zostać wyświetlona godzina odjazdu następnego autobusu.

13) Zapewniona zostanie możliwość wyświetlania na Tablicach DIP tekstów składających się z dowolnej sekwencji liter, w tym dużych lub małych oraz polskich znaków diakrytycznych. Dodatkowo Podsystem DIP umożliwi wyświetlanie symboli zdefiniowanych przez Zamawiającego w trakcie wdrożenia.

14) Tablice DIP zapewnią wyświetlanie komunikatów tekstowych przewijanych poziomo w kierunku od prawej krawędzi matrycy do lewej. Komunikaty specjalne mają pojawiać się w dolnym wierszu Tablicy DIP. W przypadku, gdy komunikat będzie dłuższy niż ilość znaków w dedykowanej linii to Tablica DIP będzie przewijała (skrolowała) poziomo komunikat w ostatniej linii, celem ukazania całej jego treści. Przy braku takich komunikatów linia ta (w zależności od konfiguracji) ma mieć możliwość pokazywania informacji o odjeździe kolejnego autobusu.

15) Moduł zapowiedzi głosowych zainstalowany w Tablicach DIP powinien emitować informację wg następującego schematu: Zawsze na początku informacja o aktualnej godzinie: "jest godzina HH:MM". W przypadku potwierdzonego odjazdu autobusu (czas rzeczywisty): Linia <numer linii>, kierunek <nazwa kierunku>, odjazd za <wartość> minut/minuty. W przypadku niepotwierdzonego (wg rozkładu jazdy) odjazdu autobusu: Linia numer <numer linii>, kierunek <nazwa kierunku>, odjazd o godzinie <godzina odjazdu>. Każda zapowiedź powinna być oddzielona uzgodnionym sygnałem dźwiękowym np. ,,ding”. Informacja dźwiękowa emitowana z Tablic DIP nie powinna odbiegać od treści odjazdów prezentowanych na samych Tablicach DIP z wyłączeniem dodatkowych komunikatów tekstowych i graficznych. Wszystkie pliki zapowiedzi dźwiękowych powinny być synchronizowane i automatycznie przesyłane z Systemu Centralnego.

118

Przykład wyświetlanej informacji dla Tablicy DIP przedstawia rysunek nr 1. Rysunek 1. Przykładowa symulacja Tablicy DIP

LOGO Nazwa przystanku godzina

LINIA KIERUNEK ODJAZD59 KIERUNEK 1 3 min54 KIERUNEK 2 12:0565 KIERUNEK 3 12:2759 KIERUNEK 4 12:308 KIERUNEK 5 12:3265 KIERUNEK 6 12:34

119

VI. Stanowiska do obsługi Systemu.

VI.1. Informacje ogólne.1. W ramach zamówienia Wykonawca powinien dostarczyć, zainstalować i

skonfigurować opisane poniżej stanowiska do obsługi Systemu.2. Stanowiska umieszczone w siedzibie Zamawiającego powinny mieć możliwość

komunikacji się z Systemem Centralnym poprzez IPSec, VPN lub SSL VPN.

3. Stanowiska umieszczone w siedzibie Operatora będą komunikowały się poprzez sieć LAN Operatora i połączenie site-2-site VPN z Systemem Centralnym. Zamawiający dostarczy jedno urządzenie UTM do realizacji tej komunikacji (UTM typ 1).

4. Dostęp pracowników do stanowisk i określonych kompetencjami funkcji powinien być był możliwy po zalogowaniu się w systemie operacyjnym, a następnie autoryzacji danej osoby, do której przez administratora Systemu będą przypisane odpowiednie uprawnienia.

5. Stanowiska do obsługi Systemu w siedzibie Operatora, Zamawiającego, punktach POK będą pracować w ramach usług katalogowych dostępnych w danej lokalizacji (w tym usługi AAA, klient DHCP i DNS, klient NTP, ustawienia Systemu i użytkownika, itp.).

6. Stanowiska do obsługi Systemu w POS będą pracować w ramach usług katalogowych dostępnych w Systemie Centralnym (w tym usługi AAA, klient DHCP i DNS, klient NTP, ustawienia Systemu i użytkownika, itp.).

7. Wszystkie stanowiska muszą posiadać podwójne zabezpieczenie przed osobami niepowołanymi – oddzielne: login i hasło do systemu operacyjnego oraz do Systemu Centralnego, zgodne z wymogami dotyczącymi ochrony danych osobowych i polityki bezpieczeństwa Operatora, przy czym musi istnieć możliwość autentykacji w aplikacji przy wykorzystaniu mechanizmów SSO (Single Sign On).

8. Operator zapewni oprogramowanie antywirusowe „Eset Endpoint Antivirus” dla stacji roboczych, stanowisk POK i POS.W przypadku zastosowania systemów operacyjnych niezgodnych z w/w oprogramowaniem, Wykonawca dostarczy inne Oprogramowanie równoważne z posiadanym przez Operatora. W szczególności spełniające poniższe wymagania:

1) usuwanie wirusów, makro–wirusów, robaków internetowych oraz koni trojańskich (oraz wirusów i robaków z plików skompresowanych oraz samorozpakowujących się) lub kasowanie zainfekowanych plików;

120

2) zapewnienie stałej ochrony wszystkich zapisywanych, odczytywanych, a także uruchamianych plików przez mechanizm skanujący pracujący w tle wraz z metodą heurystyczną wyszukiwania wirusów (na życzenie); pliki te mogą być skanowane: a) na dyskach twardych,b) w boot sektorach,c) na zewnętrznych nośnikach pamięci (np. podłączonych przez port USB);

3) możliwość samodzielnego pobierania aktualizacji z Internetu;4) możliwość aktualizowania oprogramowania i baz antywirusowych z

lokalnych serwerów Operatora, bez dostępu do Internetu;5) scentralizowaną obsługę wirusów polegającą na przekazywaniu

nieodwracalnie zainfekowanych plików do bezpiecznego miejsca w postaci centralnej kwarantanny na centralnym serwerze, w celu przeprowadzenia dalszych badań;

6) wbudowaną w oprogramowanie funkcję do wysyłania podejrzanych lub zainfekowanych nowymi wirusami plików do producenta w celu uzyskania szczepionek;

7) wyszukiwanie i usuwanie wirusów w plikach skompresowanych (także zagnieżdżonych wewnątrz innych plików skompresowanych) w szczególności z plikach typu ZIP, GNU, LZH/LHA, BinHex, HTTP, ARJ, RAR, MIME/UU, TAR, kontenery CAB,UUE, Rich Text Format, ArcManager, MS-TNEF;

8) pełną polską wersję językową oprogramowania.9. Wszystkie aplikacje zainstalowane na stanowiskach do obsługi Systemu w

siedzibie Zamawiającego, Operatora, punktach POS i POK powinny pracować bez uprawnień konta administratora systemu operacyjnego.

10. Wszystkie aplikacje zainstalowane na stanowiskach w siedzibie Zamawiającego, Operatora, punktach POS i POK powinny pracować w architekturze wielowarstwowej minimalizując ilość ruchu w sieci pomiędzy stanowiskiem, a Systemem Centralnym.

VI.2. Wykaz Stanowisk do obsługi Systemu i Urządzeń.1. Zamawiający wymaga dostarczenia, konfiguracji i podłączenia następującej

ilości komputerów i akcesoriów w siedzibie Operatora, POK do obsługi Systemu: 1) Komputer typ 1: 16 szt.;2) Komputer typ 2: 2 szt.;3) Komputer typ 3: 1 szt.;4) Monitor typ 1: 17 szt.;5) Monitor typ 2: 1 szt.;6) Drukarka typ 1: 9 szt.;7) Drukarka typ 2: 1 szt.;8) Drukarka typ 3: 4 szt.;9) Czytnik typ 1: 8 szt.;10) UPS typ 1: 17 szt.;11) UPS typ 2: 1 szt.;

121

12) Aparat fotograficzny typ 1: 4 szt.2. Zamawiający wymaga konfiguracji następującej liczby istniejących

komputerów do obsługi Systemu w siedzibie Operatora: 12 szt.3. Zamawiający wymaga dostarczenia, konfiguracji i podłączenia następującej

ilości komputerów i akcesoriów w siedzibie Zamawiającego do obsługi Systemu:1) Komputer typ 1: 1 szt.;2) Monitor typ 1: 1 szt.;3) Monitor typ 2: 1 szt.;4) UPS typ 2: 1 szt.;5) Drukarka typ 1: 1 szt.

4. Zamawiający wymaga konfiguracji następującej liczby istniejących komputerów do obsługi Systemu w siedzibie Zamawiającego: 5 szt.

5. Zamawiający wymaga dostarczenia, konfiguracji i podłączenia następującej ilości komputerów, urządzeń i akcesoriów w punktach POS:1) Komputer typ 4: 30 szt.;2) Czytnik typ 2: 30 szt.;3) Drukarka typ 4: 30 szt.;

Szczegółowe informacje dotyczące miejsca instalacji i zakresu dostępu do Systemu zostaną ustalone z Wykonawcą na poziomie Projektu Systemu.

VI.3. Licencje.Zamawiający wymaga aby licencje dostarczone na korzystanie z Systemu nie ograniczały jego funkcjonalności oraz dostępu do poszczególnych elementów. Administrator na poziomie danego Oprogramowania będzie przydzielał uprawnienia.Preferowane jest zastosowanie licencji nieograniczonych ilościowo na całą firmę/instytucję Zamawiającego i Operatora.W takim przypadku należy przewidzieć 2 licencje:

1) dla Zamawiającego,2) dla Operatora.

W przypadku gdy uzyskanie licencji nieograniczonych ilościowo jest niemożliwe, Zamawiający preferuje licencje na sesję (tj. jednocześnie pracujących użytkowników), w przypadku licencjonowania Oprogramowania Dedykowanego, a ich gdy uzyskanie jest niemożliwe, Zamawiający wymaga aby poniższe warunki licencjonowania (tam gdzie są wymagane przez producenta Oprogramowania) były spełnione:1. Podsystemy/Moduły powiązane (np. Moduł dyspozytorski próbujący uzyskać

dostęp do modułu zawierającego rozkłady jazdy, itp.):1) musi być zapewniony stały dostęp dla każdego Podsystemu/Modułu,2) możliwość rozszerzania licencji o 1, w każdej chwili,3) licencja nie powiązana na stałe z fizycznym urządzeniem, na którym działa

powiązany system/moduł (możliwość przenoszenia licencji w dowolnej chwili);

122

2. dostęp do sprzętu (POSów, Biletomatów, Autokomputerów, czytników kontrolerskich, kasowników, itp. – w ilości, które zostały podane we wcześniejszych punktach dokumentu):1) musi być zapewniony stały dostęp dla każdego używanego urządzenia,2) możliwość rozszerzania licencji o 1 w każdej chwili,3) licencja nie powiązana na stałe z fizycznym urządzeniem (możliwość

przenoszenia licencji w dowolnej chwili),

4) preferowany sposób licencjonowania – na urządzenie;3. licencjonowanie portalu WWW (POP) – licencja nieograniczona dla wszystkich

użytkowników.4. licencje dostępowe dla użytkowników Oprogramowania e-bilet:

1) możliwość rozszerzania licencji o 1 w każdej chwili,2) licencja nie powiązana na stałe z fizycznym urządzeniem ani użytkownikiem

(możliwość przenoszenia licencji w dowolnej chwili),3) w przypadku licencjonowania na urządzenie lub użytkownika minimalna

ilość licencji powinna wynieść:a) u Operatora: 23,b) u Zamawiającego: 6.

4) W przypadku zastosowania licencjonowania „na aktywną sesję” wymaga się aby dopuszczalna ilość sesji nie była mniejsza niż 80% ilości użytkowników.

5. Licencje dostępowe dla użytkowników Oprogramowania Podsystemu DIP:1) możliwość rozszerzania licencji o 1 w każdej chwili,2) licencja nie powiązana na stałe z fizycznym urządzeniem ani użytkownikiem

(możliwość przenoszenia licencji w dowolnej chwili),3) W przypadku licencjonowania na urządzenie lub użytkownika minimalna

ilość licencji powinna wynieść:c) u Operatora: 18,d) u Zamawiającego: 6,

4) w przypadku zastosowania licencjonowania „na aktywną sesję” Zamawiający wymaga, aby dopuszczalna ilość sesji nie była mniejsza niż 80% liczby użytkowników;

6. licencje dostępowe dla użytkowników Oprogramowania do projektowania rozkładów jazdy (w przypadku jednego Oprogramowania do całości):1) możliwość rozszerzania licencji o 1 w każdej chwili,2) licencja nie powiązana na stałe z fizycznym urządzeniem ani użytkownikiem

(możliwość przenoszenia licencji w dowolnej chwili),3) w przypadku licencjonowania na urządzenie lub użytkownika minimalna

ilość licencji powinna wynieść:a) u Operatora: 9,b) u Zamawiającego: 2,

4) W przypadku zastosowania licencjonowania „na aktywną sesję” wymaga się aby dopuszczalna ilość sesji nie była mniejsza niż 80% ilości użytkowników;

7. Licencje dostępowe dla użytkowników Oprogramowania do projektowania rozkładów jazdy (w przypadku osobnych programów):

123

1) możliwość rozszerzania licencji o 1 w każdej chwili,2) licencja nie powiązana na stałe z fizycznym urządzeniem ani użytkownikiem

(możliwość przenoszenia licencji w dowolnej chwili),3) W przypadku licencjonowania na urządzenie lub użytkownika minimalna

ilość licencji powinna wynieść:Projektowanie rozkładów:a) u Operatora: 5,b) u Zamawiającego: 2.Planowanie i rozliczanie czasu pracy kierowców:c) u Operatora: 4,d) u Zamawiającego: 1,Rozliczanie kilometrów i paliwa samochodów:e) u Operatora: 4,f) u Zamawiającego: 1.

4) W przypadku zastosowania licencjonowania „na aktywną sesję” wymaga się aby dopuszczalna ilość sesji nie była mniejsza niż 80% ilości użytkowników;

8. Wszystkie licencje nie mogą być ograniczone czasowo.9. Wykonawca może zaproponować za zgodą Zamawiającego inny sposób

licencjonowania, w tym licencjonowanie mieszane, przy założeniu, że podany wyżej dostęp zostanie zachowany, a zaproponowany sposób licencjonowania będzie umożliwiał dowolne przenoszenie licencji pomiędzy komputerami i użytkownikami i w maksymalnym stopniu będzie oparty „na aktywną sesję” dla Oprogramowania Dedykowanego.

124

Załącznik nr 1 do OPZ. Obowiązująca taryfa.

125

Załącznik nr 2 do OPZ. Lista autobusów z wyposażeniem.

L.p.

Nr bocz-

ny

Marka,

model

Autokom-

puter/Sterownik

Elektroni-czne tablice kierunk

owe

Tablice

klapkowe

Tablice informacyjne wewnętrzne

Urządzenia

informacji

dźwiękowej

Monitoring

wizyjny

Urządzenia do

komunikacji i

lokalizacji

Urządzenia

diagnosty-czne

Kasowniki bileto

we

Gwarancja

1. 101

JELCZ

L090 M

PIXELSTR 1-

1

PIXEL(przód-

TD 16x112)

KRG-4

2. 140

JELCZ

120 MM/2

R&GSRG-

3000P

R&G przód, bok, tył

PIXEL TML 16-

120KRG-6

3. 141

JELCZ

120 MM/2

PIXELSTR 1-

1

PIXEL przód, bok, tył

PIXEL TML 16-

120KRG-6

4. 142

JELCZ

120 MM/2

PIXELSTR 1-

1

PIXEL przód, bok, tył

PIXEL TML 16-

120KRG-6

5. 143

JELCZ

120 MM/2

R&G SRG-

3000P

R&G przód, bok, tył

PIXEL TML 16-

120KRG-6

6. 144

JELCZ

120 MM/2

R&GSRG-

3000P

R&G przód, bok, tył

PIXEL TML 16-

120KRG-6

7. 145

JELCZ

120 MM/2

PIXELSTR 1-

1

PIXEL przód, bok, tył

PIXEL TML 16-

120KRG-6

8. 146

JELCZ

120 MM/2

R&GSRG-

3000P

R&G przód, bok, tył

PIXEL TML 16-

120KRG-6

9. 147

JELCZ

120 MM/2

PIXELSTR 1-

1

PIXEL przód, bok, tył

PIXEL TML 16-

120KRG-6

10.

148

JELCZ

120 MM/2

PIXELSTR 1-

1

PIXEL przód, bok, tył

PIXEL TML 16-

120KRG-6

11.

149

JELCZ

120 MM/2

PIXELSTR 1-

1

PIXEL przód, bok, tył

PIXEL TML 16-

120KRG-6

12.

150

JELCZ

120 MM/2

PIXELSTR 1-

1

PIXEL przód, bok, tył

PIXEL TML 16-

120KRG-6

13.

205

MAN NL 222

R&GSRG-

3000P

R&G przód, bok, tył

R&G ETL

416120KRG-6

14.

206

MAN NL 222

R&GSRG-

3000P

R&G przód, bok, tył

R&G ETL

416120KRG-6

15.

207

MAN NL 222

PIXELSTR 1-

2

R&G przód, bok, tył

R&G ETL

416120KRG-6

16.

208

MAN NL 222

PIXELSTR 1-

2

PIXEL(przód-

TD 16x112-16, bok-

R&G ETL

416120

KRG-6

126

TD 16x84-10, tył- 12x21-

14)

17.

209

MAN NL 222

R&GSRG-

3000P

R&G przód, bok, tył

R&G ETL

416120KRG-6

18.

210

MAN NL 222

PIXELSTR 1-

2

PIXEL(przód-

TD 16x112-16, bok-

TD 16x84-10, tył- 12x21-

14)

R&G ETL

416120KRG-6

19.

211

MAN NL 222

R&GSRG-

3000P

R&G przód, bok, tył

R&G ETL

416120KRG-6

20.

212

MAN NL 223

R&GSRG-

3000P

R&G przód, bok, tył

R&G ETL

416120KRG-6

21.

214

JELCZ

121 I

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112,

bok-PDL16x8

4-10, tył-

PDL16x21-10)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

cyfrowy PIXELDV-

MEGA + 5 kamer

Radiomo-demPIXEL

PX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

22.

215

JELCZ

121 I

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112,

bok-PDL16x8

4-10, tył-

PDL16x21-10)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

cyfrowy PIXELDV-

MEGA + 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

23.

216

JELCZ

121 I

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112,

bok-PDL16x8

4-10, tył-

PDL16x21-10)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

cyfrowy PIXELDV-

MEGA + 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

24.

217

JELCZ

121 I

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112,

bok-PDL16x8

4-10, tył-

PDL16x21-10)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

cyfrowy PIXELDV-

MEGA + 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

25.

218

JELCZ

121 I

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112,

bok-PDL16x8

4-10,

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

cyfrowy PIXELDV-

MEGA + 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

127

tył-PDL16x2

1-10)

26.

220

JELCZ

121 I

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112,

bok-PDL16x8

4-10, tył-

PDL16x21-10)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

cyfrowy PIXELDV-

MEGA + 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

27.

221

JELCZ

121 I

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112,

bok-PDL16x8

4-10, tył-

PDL16x21-10)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

cyfrowy PIXELDV-

MEGA + 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

28.

301

JELCZ

M081MB

PIXELSTR 1-

1

PIXEL(przód-

TD 16x84-10, bok-

TD 16x84-

10)

PIXEL tył KRG-6

29.

302

JELCZ

M081MB

PIXELSTR 1-

2

PIXEL przód, bok, tył

KRG-6

30.

304

JELCZ

M081MB

PIXELSTR 1-

2

PIXEL przód, bok, tył

KRG-6

31.

250

MAN NL 202

PIXELSTR 1-

2

PIXEL(przód-

TD 16x112,

bok-PDL16x8

4-10, tył-

PDL16x21-10)

PIXEL NJ24C

OT

32.

253

MAN NL 202

R&GSRG-

3000P

BROSE

przód, bok, tył

KRG-6

33.

255

MAN NL 202

PIXELSTR 1-

2

PIXEL(przód-

TD 16x112,

bok-PDL16x8

4-10, tył-

PDL16x21-10)

PIXEL TML 16-

120KRG-4

34.

256

MAN NL 202

PIXELSTR 1-

2

PIXEL(przód-

TD 16x112-16, bok-

TD 16x84-10, tył- 12x21-

14)

PIXEL NJ24C

OT

128

35.

257

MAN NL 202

R&GSRG-

3000P

R&G przód, bok, tył

KRG-6

36.

258

MAN NL 202

R&GSRG-

3000P

R&G przód, bok, tył

KRG-6

37.

259

MAN NL 202

R&GSRG-

3000P

R&G przód, bok, tył

KRG-6

38.

261

MAN NL 263

PIXELSTR 1-

2

PIXEL(przód-

TD 16x112,

bok-PDL16x8

4-10, tył-

PDL16x21-10)

KRG-6

39.

262

MAN NL 263

PIXELSTR 1-

2

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL TML 16-

120

PIXEL NJ24C

OT

40.

263

MAN LION'

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL TML 16-

120

zapowiedź

wew.,wzmacn

iacz PWA-4

Radiomodem

PIXELPX-RM4,GPS SP-AGD2

PIXEL NJ24C

OT

41.

264

MAN LION'

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL TML 16-

120

zapowiedź

wew.,wzmacn

iacz PWA-4

Radiomodem

PIXELPX-RM4,GPS SP-AGD2

PIXEL NJ24C

OT

42.

265

MAN LION'

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL TML 16-

120

zapowiedź

wew.,wzmacn

iacz PWA-4

Radiomodem

PIXELPX-RM4,GPS SP-AGD2

PIXEL NJ24C

OT

43.

266

MAN LION'

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL TML 16-

120

zapowiedź

wew.,wzmacn

iacz PWA-4

Radiomodem

PIXELPX-RM4,GPS SP-AGD2

PIXEL NJ24C

OT

44.

267

MAN LION'

PIXELAutok

PIXEL(przód-

PIXEL TML 16-

zapowiedź

Radiomodem

PIXEL NJ24C

129

S CITY

omputer

Asterix

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

120wew.,

wzmacniacz

PWA-4

PIXELPX-RM4,GPS SP-AGD2

OT

45.

268

MAN NL 263

KPP-2/ICU-4000

MOBITEC

przód, bok, tył

PIXEL NJ24C

OT

46.

450

MAN NG 272

PIXELSTR 1-

2

PIXEL przód, bok, tył

KRG-4

47.

451

MAN NG 272

PIXELSTR 1-

2

PIXEL przód, bok, tył

KRG-4

48.

452

MAN NG 272

R&GSRG-

3000P

BROSE

przód, bok, tył

KRG-6

49.

453

MAN NG 272

R&GSRG-

3000P

BROSE

przód, bok, tył

KRG-6

50.

454

MAN NG 272

PIXELSTR 1-

2

PIXEL(Przód –

DOT-LED PDL 16x112,

bok DOT-

LED PDL 16x84, tył PL

12x21)

KRG-6

51.

455

MAN NG 272

R&GSRG-

3000P

BROSE

przód, bok, tył

KRG-6

52.

456

MAN NG 272

R&GSRG-

3000P

BROSE

przód, bok, tył

KRG-6

53.

457

MAN NG 312

PIXELSTR 1-

2

PIXEL(Przód –

DOT-LED PDL 16x112,bok PL 16x84, tył PL

12x21)

KRG-6

54.

458

MAN NG 312

R&GSRG-

3000P

BROSE

przód, bok, tył

KRG-6

55.

459

MAN NG 312

R&GSRG-

3000P

BROSE

przód, bok, tył

KRG-6

56.

460

MAN NG 312

PIXELSTR 1-

2

PIXEL(przód-

TD

PIXEL NJ24C

OT

130

16x112, bok-

PDL16x84-10, tył-

PDL16x21-10)

57.

461

MAN LION'

S CITY

G

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

2 x PIXEL

TML 16-120

zapowiedź

wew.,wzmacn

iacz PWA-4

Radiomodem

PIXELPX-RM4,GPS SP-AGD2

PIXEL NJ24C

OT

58.

501

SCANIA

OMNICITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD II 16x112, bok- TD II16x84, tył- TD II 12x21)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 4 kamery

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

59.

502

SCANIA

OMNICITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD II 16x112, bok- TD II16x84, tył- TD II 12x21)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 4 kamery

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

60.

503

SCANIA

OMNICITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD II 16x112, bok- TD II16x84, tył- TD II 12x21)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 4 kamery

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

61.

504

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

FLIP DOT

16x112-16, bok-

FLIP DOT

16x84-10, tył-

FLIP DOT

16x28-10)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

62.

505

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112-16, bok-

TD 16x84-10, tył- 12x21-

14)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

63.

506

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112-16, bok-

TD 16x84-10, tył- 12x21-

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

131

14)

64.

507

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112-16, bok-

TD 16x84-10, tył- 12x21-

14)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

65.

508

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112-16, bok-

TD 16x84-10, tył- 12x21-

14)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

66.

509

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112-16, bok-

TD 16x84-10, tył- 12x21-

14)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

67.

510

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112-16, bok-

TD 16x84-10, tył- 12x21-

14)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

68.

511

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112-16, bok-

TD 16x84-10, tył- 12x21-

14)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

69.

512

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

TD 16x112-16, bok-

TD 16x84-10, tył- 12x21-

14)

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

70.

513

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

FLIP DOT

16x112-16, bok-

FLIP DOT

16x84-10, tył-

FLIP DOT

16x28-

PIXEL TML 16-

120

zapowiedź wew.

oraz zew.,

wzmacniacz WAP

rejestrator

analogowy X200

+ 5 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

PIXEL NJ24C

OT

132

10)

71.

514

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

72.

515

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

73.

516

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

74.

517

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

75.

518

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

76.

519

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

77.

520

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

78.

521

MAN LION’

S

PIXELAutokomput

PIXEL(przód-

XTD

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz

rejestrator

cyfrowy

Radiomodem

PIXEL

Wyświetlacz

stanów

PIXEL NJ24C

OT

133

CITYer

Asterix

16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

zew.,wzmacn

iacz PWA-3

PIXELDV-

MEGA + 6 kamer

PX-RM4,GPS SP-AGZ2

alarmowych

PIXEL WSAPA

79.

522

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

80.

523

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

81.

524

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

82.

525

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

83.

526

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

84.

527

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

85.

528

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

134

10, tył- 16x28-

10)

86.

529

MAN LION’

S CITY

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL1 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

87.

430

MAN LION’

S CITY LA26

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL2 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

88.

431

MAN LION’

S CITY LA26

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL2 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

89.

432

MAN LION’

S CITY LA26

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL2 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

22.09.201

8

90.

433

MAN LION’

S CITY LA26

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL2 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

22.09.201

8

91.

434

MAN LION’

S CITY LA26

PIXELAutokomput

er Asteri

x

PIXEL(przód-

XTD 16x112-15, bok-

XTD 16x84-10, tył- 16x28-

10)

PIXEL2 x LCD XID 220

zapowiedź wew.

oraz zew.,

wzmacniacz

PWA-3

rejestrator

cyfrowy PIXELDV-

MEGA + 6 kamer

Radiomodem

PIXELPX-RM4,GPS SP-AGZ2

Wyświetlacz

stanów alarmow

ychPIXEL

WSAPA

PIXEL NJ24C

OT

22.09.201

8

92.

435

MANNL 313

STR 1-1

LAWO

GORBA

przód, bok, bok, tył

PIXEL NJ24C

OT

93.

436

MANNL 313

STR 1-1

GORBA

GORBA

przód, bok, bok,

PIXEL NJ24C

OT

135

tył

94.

437

MANNL 313

STR 1-1

GORBA

GORBA

przód, bok, bok, tył

PIXEL NJ24C

OT

Ponadto dostarczonych zostanie w 2018 roku 28 sztuk autobusów, które zgodnie z tabelą wymiany autobusów zastąpią część wykorzystywanych obecnie autobusów.

L.p.

Liczba szt.

Marka,

model

Autokom-

puter/Sterownik

Elektroni-czne tablice kierunk

owe

Tablice

klapkowe

Tablice informa

cyjne wewnęt

rzne

Urządzenia

informacji

dźwiękowej

Monitoring

wizyjny

Urządzenia do

komunikacji i

lokalizacji

Urządze-nia diagnosty-czne

Kasowniki bileto

we

Gwara-

ncja

1. 13MAN Lion’s CityA37

PIXELAutoko

m-puter XC-6

PIXELPrzednia

XTD 16x112

ETH,boczna

XTD 16x84 ETH, tylna XTD

16x28 ETH

PIXEL1 x LCD XID 231

PIXEL Moduł XC-6

Audio, wzmacniacz

akustyczny

PWA-4

Rejestrator

mobilny IP PVRS

w zabudo

wie pasywnej + 7 kamer

Radiomodem RM-6 z

GSM, Moduł Komunikacyjny XC-6 RS-CAN,

Antena GPS z

odbiornikiem,

Antena GSM i

antena Wi-Fi do RM-6

Router: Producent Mikrotik

Oprogramowanie

Router OS Level 4, 1x

port GE, Modem 3G/4G,

Moduł Wi-Fi

03.2021

2. 15

MAN Lion’s City

GA23

PIXELAutoko

m-puter XC-6

PIXELPrzednia

XTD 16x112

ETH,boczna

XTD 16x84 ETH, tylna XTD

16x28 ETH

PIXEL2 x LCD XID 231

PIXEL Moduł XC-6

Audio, wzmacniacz

akustyczny

PWA-4

Rejestrator

mobilny IP PVRS

w zabudo

wie pasywnej + 10 kamer

Radiomodem RM-6 z

GSM, Moduł Komunikacyjny XC-6 RS-CAN,

Antena GPS z

odbiornikiem,

Antena GSM i

antena Wi-Fi do RM-6

Router: Producent Mikrotik

Oprogramowanie

Router OS Level 4, 1x

port GE, Modem 3G/4G,

Moduł Wi-Fi

03.2021

136

Dodatkowo zostanie do 2019 roku zakupione zostaną 33 sztuki (30 maxi 12m + 3 midi 10m) autobusów, które zgodnie z tabelą wymiany autobusów zastąpią część wykorzystywanych obecnie autobusów. Modele, marki i wyposażenie autobusów będzie znane po przeprowadzeniu przetargów.

137

Załącznik nr 3 do OPZ. Parametry techniczne poszczególnych Stanowisk do obsługi Systemu.

1. Komputer typ 1 desktop. Poniżej przedstawiono minimalne parametry techniczne komputera typ 1.1.1. Typ: komputer stacjonarny. 1.2. Zastosowanie: komputer będzie wykorzystywany dla potrzeb aplikacji

biurowych, aplikacji edukacyjnych, aplikacji obliczeniowych, aplikacji graficznych, dostępu do Internetu oraz poczty elektronicznej.

1.3. Procesor: TDP maximum: 65 W; Ilość rdzeni: 4, Ilość wątków: 4; Turbo; Pamięć cache: 6MB; procesor nie starszy niż I kwartał 2015 roku; osiągający wynik w teście PassMark CPU Mark minimum 6630 punktów. W ofercie wymagane jest podanie modelu oraz producenta procesora. Do oferty należy dołączyć wydruk ze strony: http://www.cpubenchmark.net/cpu_list.php potwierdzający spełnienie wymogów SIWZ.

1.4. Pamięć operacyjna: co najmniej 8 GB (2x4GB co najmniej 1600MHz lub 1x8GB), możliwość rozbudowy pamięci RAM do minimum 32 GB, co najmniej 4 gniazda DIMM.

1.5. Parametry pamięci masowej: SSD SATA minimum 250 GB. 1.6. Grafika: zintegrowana z minimum dwoma wyjściami cyfrowymi dla

monitorów LCD. Zamawiający dopuszcza także zastosowanie karty niezintegrowanej z płytą główną.

1.7. Wyposażenie multimedialne: karta dźwiękowa zintegrowana z płytą główną; wbudowany głośnik.

1.8. Obudowa: typu Tower/MicroTower. Obudowa musi umożliwiać serwisowanie komputera bez użycia narzędzi oraz dawać możliwość instalacji drugiego dysku twardego.

1.9. Zgodność z Systemami operacyjnymi i standardami: oferowany model komputera musi posiadać certyfikat Microsoft, potwierdzający poprawną współpracę z Systemem operacyjnym Windows 7/8.1/10 (załączyć wydruk ze strony Microsoft WHCL).

1.10. BIOS: możliwość odczytania z BIOS: - Wersji BIOS1) modelu procesora, prędkości procesora, 2) informacji o ilości pamięci RAM wraz z informacją o jej prędkości,3) informacji o dysku twardym: model, pojemność,4) informacji o napędzie optycznym: model.

1.11. Wymagania dodatkowe: 1. wbudowane porty i złącza:

1) porty wideo: min. 1 szt VGA i 1 szt Display Port/HDMI, 2) min. 6xUSB wyprowadzonych na zewnątrz obudowy:

a) 2 porty USB z przodu obudowy USB 3.0,b) 4 portów USB z tyłu obudowy w tym min 2 szt USB 3.0,

3) port sieciowy RJ-45, 4) porty audio: wyjście słuchawek i wejście mikrofonowe – zarówno z przodu

jak i z tyłu obudowy,5) serial port (RS-232),

138

6) 2 szt. PS/2.2. Wymagana ilość i rozmieszczenie (na zewnątrz obudowy komputera) portów

USB nie może być osiągnięte w wyniku stosowania konwerterów, przejściówek itp.

3. Karta sieciowa 10/100/1000 (dopuszczalna zintegrowana).4. Klawiatura USB w układzie polski programisty. Wymagane jest aby wysokość

klawiatury z włożoną w czytnik kartą smart 85x54 mm nie przekraczała 6 cm.

5. Mysz optyczna lub laserowa USB z min dwoma klawiszami oraz rolką (scroll).6. Nagrywarka SATA DVD +/-RW zlokalizowana w zewnętrznej półce 5,25" lub

zatoce slim na napęd optyczny.7. Podkładka pod mysz optyczną.

1.12. System operacyjny1) W ofercie wymagane jest podanie producenta, pełnej nazwy, wersji

zainstalowanego systemu operacyjnego oraz nazwy i wersji licencji systemu operacyjnego.

2) system operacyjny klasy PC musi spełniać poniższe wymagania poprzez wbudowane mechanizmy, bez użycia dodatkowych aplikacji.

3) Możliwość dokonywania aktualizacji i poprawek systemu przez Internet z możliwością wyboru instalowanych poprawek.

4) Możliwość dokonywania uaktualnień sterowników urządzeń przez Internet – witrynę producenta systemu.

5) Darmowe aktualizacje w ramach wersji systemu operacyjnego przez Internet (niezbędne aktualizacje, poprawki, biuletyny bezpieczeństwa muszą być dostarczane bez dodatkowych opłat) – wymagane podanie nazwy strony serwera WWW.

6) System musi umożliwiać pracę w domenie.7) Wsparcie dodatkowe dla zainstalowanego systemu operacyjnego co

najmniej do 1 stycznia 2020r. Wymagane jest aby dostarczona licencja systemu operacyjnego dopuszczała instalację nowszego Systemu operacyjnego producenta, którego wsparcie dodatkowe wygasa nie wcześniej niż 1 stycznia 2025 r.

8) Internetowa aktualizacja zapewniona w języku polskim.9) Wbudowana zapora internetowa (firewall) dla ochrony połączeń

internetowych; zintegrowana z systemem konsola do zarządzania ustawieniami zapory i regułami IP v4 i v6.

10) Zlokalizowane w języku polskim, co najmniej następujące elementy: menu, odtwarzacz multimediów, pomoc, komunikaty systemowe.

11) Wsparcie dla większości powszechnie używanych urządzeń peryferyjnych (drukarek, urządzeń sieciowych, standardów USB, Plug&Play, Wi-Fi).

12) Funkcjonalność automatycznej zmiany domyślnej drukarki w zależności od sieci, do której podłączony jest komputer.

13) Interfejs użytkownika działający w trybie graficznym z elementami 3D, zintegrowana z interfejsem użytkownika interaktywna część pulpitu służącą do uruchamiania aplikacji, które użytkownik może dowolnie wymieniać i pobrać ze strony producenta.

139

14) Możliwość zdalnej automatycznej instalacji, konfiguracji, administrowania oraz aktualizowania systemu.

15) Zabezpieczony hasłem hierarchiczny dostęp do systemu, konta i profile użytkowników zarządzane zdalnie; praca systemu w trybie ochrony kont użytkowników.

16) Zintegrowany z systemem Moduł wyszukiwania informacji (plików różnego typu) dostępny z kilku poziomów: poziom menu, poziom otwartego okna systemu operacyjnego. System wyszukiwania oparty na konfigurowalnym przez użytkownika module indeksacji zasobów lokalnych.

17) Zintegrowane z systemem operacyjnym narzędzia zwalczające złośliwe oprogramowanie; aktualizacje dostępne u producenta nieodpłatnie bez ograniczeń czasowych.

18) Zintegrowany z systemem operacyjnym Moduł synchronizacji komputera z urządzeniami zewnętrznymi.

19) Wbudowany system pomocy w języku polskim.20) Możliwość przystosowania stanowiska dla osób niepełnosprawnych (np.

słabo widzących).21) Zarządzanie stacją roboczą poprzez polityki rozumiane jako zestaw reguł

definiujących lub ograniczających funkcjonalność systemu lub aplikacji.22) Wdrażanie IPSEC oparte na politykach – wdrażanie IPSEC oparte na

zestawach reguł definiujących ustawienia zarządzanych w sposób centralny.23) Automatyczne występowanie i używanie (wystawianie) certyfikatów PKI

X.509.24) Wsparcie dla logowania przy pomocy smartcard.25) Rozbudowane polityki bezpieczeństwa – polityki dla systemu operacyjnego i

dla wskazanych aplikacji.26) Posiadanie narzędzi służących do administracji, do wykonywania kopii

zapasowych polityk i ich odtwarzania oraz generowania raportów z ustawień polityk.

27) Wsparcie dla Sun Java i .NET Framework 1.1 i 2.0 i 3.0, 4.0, 5.0 – możliwość uruchomienia aplikacji działających we wskazanych środowiskach.

28) Wsparcie dla JScript i VBScript – możliwość uruchamiania interpretera poleceń.

29) Zdalna pomoc i współdzielenie aplikacji – możliwość zdalnego przejęcia sesji zalogowanego użytkownika celem rozwiązania problemu z komputerem.

30) Rozwiązanie służące do automatycznego zbudowania obrazu systemu wraz z aplikacjami. Obraz systemu służyć ma do automatycznego upowszechnienia systemu operacyjnego inicjowanego i wykonywanego w całości poprzez sieć komputerową.

31) Rozwiązanie umożliwiające wdrożenie nowego obrazu poprzez zdalną instalację.

32) Graficzne środowisko instalacji i konfiguracji.33) Transakcyjny system plików pozwalający na stosowanie przydziałów (ang.

quota) na dysku dla użytkowników oraz zapewniający większą niezawodność i pozwalający tworzyć kopie zapasowe.

140

34) Zarządzanie kontami użytkowników sieci oraz urządzeniami sieciowymi tj. drukarki, modemy, woluminy dyskowe, usługi katalogowe.

35) Oprogramowanie dla tworzenia kopii zapasowych (backup); automatyczne wykonywanie kopii plików z możliwością automatycznego przywrócenia wersji wcześniejszej.

36) Możliwość przywracania plików systemowych.37) System operacyjny musi posiadać funkcjonalność pozwalającą na

identyfikację sieci komputerowych, do których jest podłączony, zapamiętywanie ustawień i przypisywanie do kategorii bezpieczeństwa (z predefiniowanymi odpowiednio do kategorii ustawieniami zapory sieciowej, udostępniania plików itp.).

38) System musi posiadać możliwość blokowania lub dopuszczania dowolnych urządzeń peryferyjnych za pomocą polityk grupowych (np. przy użyciu numerów identyfikacyjnych sprzętu).

1.13. Pakiet biurowy1) Pakiet biurowy w polskiej wersji językowej umożliwiający pracę grupową na

dokumentach stworzonych w MS Office, w wersji co najmniej 2013, w pełni obsługujący wszystkie istniejące dokumenty Zamawiającego (utworzone przy pomocy Microsoft Word, Excel, PowerPoint w wersjach 2003, 2007, 2010 i 2013 z zapewnieniem niezawodnej konwersji wszystkich elementów i atrybutów dokumentu), bez utraty jakichkolwiek ich parametrów i cech użytkowych (korespondencja seryjna, wielokolumnowe arkusze kalkulacyjne zawierające makra i formularze, itp.), zawierający procesor tekstu, arkusz kalkulacyjny, program do tworzenia prezentacji oraz aplikację służącą do obsługi poczty elektronicznej i organizacji czasu, z licencją wieczystą (przypisana do jednego urządzenia nazywanego licencjonowanym urządzeniem) pozwalającą na:a) dodatkową instalację jednej kopii pakietu na urządzeniu przenośnym

przeznaczoną do użytku przez jednego głównego użytkownika licencjonowanego urządzenia,

b) instalację pakietu z jednakowym kluczem licencyjnym dla wszystkich licencjonowanych urządzeń,

c) instalację wcześniejszych wersji oprogramowania i korzystania z nich na licencjonowanym urządzeniu,

d) zmianę licencjonowanego urządzenia na inne w dowolnym momencie (licencja nie jest przypisane na stałe do jedynego, konkretnego urządzenia).

2) Wymaga się, aby wersja instalacyjna pakietu została dostarczona na nośniku zewnętrznym lub w postaci pliku do pobrania z Internetu z autoryzowanej witryny (plik obrazu lub wersja instalacyjna), niewymagana jest instalacja pakietu na komputerze. Wymagana jest licencja grupowa pakietu w opcji komercyjnej w liczbie sztuk równej sumie zamawianych komputerów. W ofercie wymagane jest podanie pełnej nazwy, wersji lub symbolu pakietu biurowego oraz producenta pakietu.

141

2. Komputer typ 2 laptop.Poniżej przedstawiono minimalne parametry techniczne komputera typ 2.2.1. Komputer przenośny.2.2. Zastosowanie: komputer będzie wykorzystywany dla potrzeb aplikacji

biurowych, aplikacji edukacyjnych, aplikacji obliczeniowych, aplikacji graficznych, dostępu do Internetu oraz poczty elektronicznej.

2.3. Procesor: TDP maximum: 65 W; Ilość rdzeni: 4, Ilość wątków: 4; Turbo; Pamięć cache: 6MB; Procesor nie starszy niż I kwartał 2015 roku; Osiągający wynik w teście PassMark CPU Mark minimum 6630 punktów. W ofercie wymagane jest podanie modelu oraz producenta procesora. Do oferty należy dołączyć wydruk ze strony: http://www.cpubenchmark.net/cpu_list.php potwierdzający spełnienie wymogów SIWZ.

2.4. Pamięć operacyjna:1) co najmniej 8 GB,2) parametry pamięci masowej: SSD minimum 500 GB.

2.5. Grafika: zintegrowana.2.6. Wyposażenie multimedialne: Karta dźwiękowa zintegrowana z płytą główną;

wbudowany głośnik.2.7. BIOS: możliwość odczytania z BIOS:

1) wersji BIOS2) modelu procesora, prędkości procesora, 3) informacji o ilości pamięci RAM wraz z informacją o jej prędkości,4) informacji o dysku twardym: model, pojemność,5) informacji o napędzie optycznym: model.

2.8.Ekran:1) ekran wyposażony w matrycę 15.6" z powłoką antyodblaskową,

kątem widzenia do 178°.2) rozdzielczość 1920 x 1080.

2.9. Zasilanie:1) w komplecie zasilacz,2) czas pracy na baterii min. 4 godz.

2.10. Wymagania dodatkowe1) wbudowane porty i złącza:

a) Port HDMI,b) 2 x 3.0 USB, 2 x 2.0 USB,c) porty audio: wyjście słuchawek i wejście mikrofonowe, d) Komunikacja: Bluetooth, LAN (RJ-45),Wi-Fi;

2) Karta sieciowa 10/100/1000 (dopuszczalna zintegrowana);3) Klawiatura podświetlana, zawiera klawiaturę numeryczną;4) Mysz optyczna lub laserowa bezprzewodowa;5) Torba na laptopa;6) Napęd optyczny – nagrywarka DVD;7) Podkładka pod mysz optyczną.

2.11. Oprogramowanie: jak w komputerze 1.

3. Komputer typ 3 desktop.Poniżej przedstawiono minimalne parametry techniczne komputera typ 3.

142

3.1. Typ: komputer stacjonarny. 3.2. Zastosowanie: komputer będzie wykorzystywany dla potrzeb aplikacji

biurowych, aplikacji edukacyjnych, aplikacji obliczeniowych, aplikacji graficznych, dostępu do Internetu oraz poczty elektronicznej.

3.3. Procesor: TDP maximum: 65 W; Ilość rdzeni: 4, Ilość wątków: 4; Turbo; Pamięć cache: 6MB; Procesor nie starszy niż I kwartał 2015 roku; Osiągający wynik w teście PassMark CPU Mark minimum 6630 punktów. W ofercie wymagane jest podanie modelu oraz producenta procesora. Do oferty należy dołączyć wydruk ze strony: http://www.cpubenchmark.net/cpu_list.php potwierdzający spełnienie wymogów SIWZ.

3.4. Pamięć operacyjna: co najmniej 8 GB (2x4GB co najmniej 1600MHz lub 1x8GB), możliwość rozbudowy pamięci RAM do minimum 32 GB, co najmniej 4 gniazda DIMM.

3.5. Parametry pamięci masowej: SSD SATA minimum 250 GB. 3.6. Grafika: pozwalająca na podłączenie minimum 3 urządzeń monitorów

korzystających z wejść cyfrowych w układzie rozszerzającym pulpit użytkownika.

3.7. Wyposażenie multimedialne: karta dźwiękowa zintegrowana z płytą główną, wbudowany głośnik.

3.8. Obudowa: typu Tower/MicroTower. Obudowa musi umożliwiać serwisowanie komputera bez użycia narzędzi oraz dawać możliwość instalacji drugiego dysku twardego.

3.9. Zgodność z systemami operacyjnymi i standardami: Oferowany model komputera musi posiadać certyfikat Microsoft, potwierdzający poprawną współpracę z systemem operacyjnym Windows 7/8.1/10 (załączyć wydruk ze strony Microsoft WHCL).

3.10. BIOS: możliwość odczytania z BIOS: 1) wersji BIOS,2) modelu procesora, prędkości procesora, 3) informacji o ilości pamięci RAM wraz z informacją o jej prędkości,4) informacji o dysku twardym: model, pojemność,5) informacji o napędzie optycznym: model.

3.11. Wymagania dodatkowe1) Wbudowane porty i złącza: porty wideo: min. 1 szt. VGA i 1 szt. Display

Port/HDMI, min. 6xUSB wyprowadzonych na zewnątrz obudowy: a) 2 porty USB z przodu obudowy USB 3.0,b) 4 portów USB z tyłu obudowy w tym min 2 szt. USB 3.0, c) port sieciowy RJ-45, d) porty audio: wyjście słuchawek i wejście mikrofonowe – zarówno z

przodu jak i z tyłu obudowy,e) serial port (RS-232),f) 2 szt. PS/2;

2) Wymagana ilość i rozmieszczenie (na zewnątrz obudowy komputera) portów USB nie może być osiągnięta w wyniku stosowania konwerterów, przejściówek itp.

3) Karta sieciowa 10/100/1000 (dopuszczalna zintegrowana).

143

4) Klawiatura USB w układzie polski programisty. Wymagane jest aby wysokość klawiatury z włożoną w czytnik kartą smart 85x54 mm nie przekraczała 6 cm.

5) Mysz optyczna lub laserowa USB z min dwoma klawiszami oraz rolką (scroll).

6) Nagrywarka SATA DVD +/-RW zlokalizowana w zewnętrznej półce 5,25" lub zatoce slim na napęd optyczny.

7) Podkładka pod mysz optyczną.3.12. Oprogramowanie: jak w komputer typ 1.

4. Komputer typ 4 Tablet.4.1. Minimalne wymagania:

1) Procesor 64bit o wydajności obliczeniowej wg PassMark – CPU Mark nie mniejszej niż 2492, architektura x86.

2) Pamięć operacyjna: 4GB.3) Dysk SSD: 128GB. 4) Modem WWAN: 3G.5) Standard WLAN: g/n.6) Bluetooth: 4.0.7) Złącza: pełnowymiarowe USB 3.0, mikro-USB, mini HDMI, audio combo

jack. 8) Typy odczytywanych kart pamięci: microSD, microSDHC.9) Ekran dotykowy: tak.10) Przekątna ekranu 10,8” o rozdzielczości co najmniej 1920x1080,

technologia IPS. 11) Czas pracy na baterii: min. 480min. 12) Układ szyfrowania: TPM.13) Dla zapewnienia pełnej zgodności funkcjonowania wszystkich

elementów funkcjonującego Systemu oraz dla zapewnienia wymogów określonych przez szczegółowy opis działania oferowanych systemów przedstawiony przez wykonawcę projektu wymagany jest system operacyjny zgodnie z opisem w załączniku 2.

14) Certyfikat CE: tak.15) Złącze stacji dokującej: tak. 16) Wymienna bateria: tak.

4.2. Stacja dokująca do tabletu określonego powyżej spełniająca minimalne wymagania.

1) Ten sam producent dla tabletu i stacji dokującej.2) Złącze dokujące do tabletu.3) Złącza zewnętrzne:

a) HDMI - 1 szt., b) DisplayPort - 1 szt., c) wyjście audio - 1 szt., d) USB 3.0 - 3 szt., e) RJ-45 - 1 szt., złącze zasilania - 1 szt.

4) Certyfikat CE: tak.

144

5. Monitor typ 1.Poniżej przedstawiono minimalne parametry techniczne monitora typ 1.5.1Typ wyświetlacza: LCD TFT.5.2. Wielkość wyświetlacza: minimum 23 cale.5.3. Proporcje wymiarów matrycy: 16:9 lub 16:10.5.4. Plamka: max. 0,282 mm.5.5. Kąt widzenia: min. 170° w poziomie, 160° w pionie.5.6. Kontrast: min. 1000:1.5.7. Jasność: min. 250 nitów.5.8. Czas reakcji matrycy: max. 5 ms.5.9. Rozdzielczość: 080.5.10. Głośniki: wbudowane 2 x 1W.5.11. Pobór mocy (typ.): maksymalnie 40W.5.12. Złącza:

1) D-Sub,2) DVI, 3) HDMI.

5.13. Konstrukcja: regulacja kąta obrotu, regulacja wysokości, regulacja kąta pochylenia.5.14. Normy: Energy Star, TCO (potwierdzenia załączyć do oferty).5.15. Gwarancja: gwarancja na uszkodzone piksele wg normy ISO 13406-2.

6. Monitor typ 2.Niżej przedstawiono minimalne parametry monitora typ 2.6.1. Przeznaczenie: do prezentacji lokalizacji autobusów.6.2. Przekątna ekranu: minimum 42 cale.6.3. Format obrazu: 16:9.6.4. Kąt widzenia: min. 176° w poziomie, 176° w pionie.6.5. Porty:

1) gniazdo HDMI (ilość): 4 szt.,2) możliwość podłączenia komputera PC,3) gniazdo D-Sub 15pin (ilość): 1 szt.,4) gniazdo SCART (Euro złącze) (ilość): 1 szt.,5) gniazdo USB (ilość): 2 szt.,

6.6. Rozdzielczość: minimum 1920x1080.6.7. Dodatkowe funkcje

1) pilot,2) możliwość zawieszenia na ścianie.

6.8. Pobór mocy (typ.): maksymalnie 50W.6.9. Gwarancja: 3 lata.

7. Zasilacz UPS typ 1.Poniżej przedstawiono minimalne parametry zasilacza UPS typ 1.Zasilacze awaryjne - parametry minimalne:

1) Typ obudowy: desktop;2) Moc pozorna: 325 VA;

145

3) Moc rzeczywista: 210 Wat;4) Maks. czas przełączenia na baterię: 8 ms; 5) Liczba, typ gniazd wyj. z podtrzymaniem zasilania: 3 x IEC320 C13 (10A); 6) Liczba, typ gniazd wyj. z ochroną antyprzepięciową: 1 x IEC320 C13 (10A); 7) Typ gniazda wejściowego: IEC320 C14 (10A); 8) Czas podtrzymania dla obciążenia 100%: minimum 5 min; 9) Czas podtrzymania przy obciążeniu 50%: minimum 20 min; 10) Zakres napięcia wejściowego w trybie podstawowym: 196-280 V; 11) Zmienny zakres napięcia wejściowego: 160-300 V; 12) Zimny start: Tak; 13) Port zabezpieczający linie danych: brak; 14) Diody sygnalizacyjne: konieczna wymiana baterii, praca z baterii,

praca z sieci zasilającej, przeciążenia UPSa; 15) Alarmy dźwiękowe: praca z baterii, przeciążenie UPSa, znaczne

wyczerpanie baterii;Złącze USB do komunikacji z komputerem. Dedykowane Oprogramowanie do monitorowania stanu UPS’a z możliwością wyłączenia komputera na podstawie zadanych parametrów (np. ilość czasu pozostała do podtrzymania). Możliwość zmiany parametrów UPS’a dotyczących wykrywania zakłóceń w sieci energetycznej oraz kompensaty napięć.

8. Zasilacz UPS typ 2.Poniżej przedstawiono minimalne parametry zasilacza UPS typ 1.Parametry minimalne:

1) Moc pozorna: min. 700 VA; 2) Moc rzeczywista: min. 405 Wat; 3) Architektura UPSa: off-line (standby); 4) Maks. czas przełączenia na baterię: max. 8 ms;5) Liczba i rodzaj gniazdek z utrzymaniem zasilania: 4 x PL (10A); 6) Liczba, typ gniazd wyj. z ochroną antyprzepięciową: 4 x PL (10A); 7) Typ gniazda wejściowego: kabel z wtykiem PL (10A);8) Czas podtrzymania dla obciążenia 100%: min. 3,5 min; 9) Czas podtrzymania przy obciążeniu 50%: min. 12,6 min; 10) Zakres napięcia wejściowego w trybie podstawowym: 180-266 V; 11) Zimny start: tak;12) Porty komunikacji: USB;13) Port zabezpieczający linie danych: RJ45 - linia modemowa/faxowa,

DSL, 10/100BaseTX;14) Diody sygnalizacyjne: • praca z sieci zasilającej, • praca z baterii; 15) Alarmy dźwiękowe:

a) praca z baterii, b) znaczne wyczerpanie baterii, c) przeciążenie UPSa;

16) Typ obudowy: desktop; 17) Wymiary maksymalne:

a) szerokość: 230 mm b) wysokość: 90 mm

146

c) głębokość: 320 mm; 18) Certyfikat CE: tak.

9. Drukarka typ 1.Niżej przedstawiono minimalne parametry drukarki typ 1.9.1. Technologia druku: druk laserowy.9.2. Druk w kolorze: NIE.9.3. Prędkość druku: ponad 30 stron na minutę w czerni.9.4. Pamięć minimum: .9.5. Jakość druku w czerni: do 1200 dpi.9.6. Druk dwustronny automatyczny: TAK.9.7. Automatyczny dwustronny podajnik dokumentów do skanera: TAK.9.8. Skaner kolorowy: TAK.9.9Skanowanie po sieci: Skanowanie na udostępniony zasób sieciowy, FTP, e-

mail.9.9. Obsługiwane formaty nośników papieru:

3) A4, 4) A5, 5) B5 (JIS),6) koperty (B5, C5, DL).

9.10. Podajnik: dwa podajniki na papier formatu A4, z czego jeden na 250 arkuszy.9.11. Komunikacja

1) 1 x USB 2.0, 2) karta sieciowa (LAN): 10/100.

9.12. Wyposażenie: kabel USB 2.0. 9.13. Dodatkowe tonery: oprócz kompletu startowego tonerów dwa dodatkowe

oryginalne komplety.

10. Drukarka typ 2 – urządzenie wielofunkcyjne.Niżej przedstawiono minimalne parametry drukarki typ 2.10.1. Technologia druku: druk laserowy.10.2. Druk w czerni i kolorze: TAK.10.3. Prędkość druku: ponad 30 stron na minutę w czerni.10.4. Pamięć minimum: .10.5. Jakość druku w czerni: do 1200 dpi.10.6. Druk dwustronny automatyczny: TAK.10.7. Automatyczny dwustronny podajnik dokumentów do skanera: TAK.10.8. Skaner kolorowy: TAK.10.9 Skanowanie po sieci: skanowanie na udostępniony zasób sieciowy, FTP, e-

mail.10.10. Obsługiwane formaty nośników papieru dla skanera (w tym podajnika automatycznego) i drukarki

1) A4,2) A5,3) B5 (JIS),

147

4) koperty (B5, C5, DL).10.11. Podajnik: trzy podajnik na papier formatu A3 z czego dwa na 250 arkuszy.10.12. Komunikacja

1) x USB 2.0, 2) karta sieciowa (LAN): 10/100.

10.13. Wyposażenie: kabel USB 2.0. 10.14. Dodatkowe tonery: oprócz kompletu startowego tonerów dwa dodatkowe oryginalne komplety.

11. Drukarka typ 3 – termiczna.Minimalne wymagania techniczne dla termicznej drukarki kart:

1) Praca w sieci – obsługa dwóch kasjerów.2) Drukarka musi umożliwiać zadruk kart w kolorze dla różnych systemów

operacyjnych.3) Prędkość druku min: 150 kart/godzinę w kolorze (CMYK), do 1000

kart/godzinę dla druku monochromatycznego.4) Rozdzielczość min 300 dpi.5) Ładowanie Kart e-bilet: przez automatyczną tackę lub ręcznie (zbiorczy i

ręczny podajnik Kart e-bilet).

6) Drukarki dostarczone przez Wykonawcę do wykonywania personalizacji muszą zapewniać zabezpieczenie wykonywanych kolorowych nadruków przed ścieraniem.

7) Nadruk zdjęcia (maks. 30x30 mm) w czasie poniżej 30s.8) Wykonawca zapewni materiały eksploatacyjne do drukarki Kart e-bilet

pozwalające na zadrukowanie przynajmniej 50 000 Kart e-bilet.

12. Drukarka typ 4. Drukarka termiczna.Minimalne wymagania:

1) Metoda druku: bezpośredni termiczny druk liniowy.2) Rozdzielczość: 203 dpi, 8 punktów / mm. 3) Szybkość druku: min. 125 mm/s.4) Szerokość papieru: 58mm lub 80mm.5) Średnica rolki: 83 mm maksimum.6) Interfejs: USB.7) Emulacja: Star, ECS/ POS. 8) Drivery: Windows (zapewniający współpracę z oferowanym tabletem

określonym w punkcie 3.1). 9) Kody paskowe: wszystkie podstawowe oraz PDF47 i Maxicode. 10) Czas międzyawaryjny MCBF: 60 milionów linii. 11) Głowica drukująca: 100 km. 12) Automatyczny ucinacz: 1 milion ucięć. 13) Maksymalne wymiary (szerokość x głębokość x wysokość):

a) 160 mm x 245 mm x 152 mm,b) Waga: max. 1.75 kg.

14) Temperatura pracy: 5 stopni C - 45 stopni C. 15) Temperatura składowania: -20 stopni C - 60 stopni C.

148

16) Zasilacz: wewnętrzny. 17) Certyfikat CE: tak.

13. Czytnik typ 1.Minimalne wymagania techniczne dla czytnika art:

1) Czytnik: ISO 14442 typ A i B. 2) Złącze USB.3) Moduł kart SAM.

14. Czytnik typ 2.Czytnik Kart e-biletu spełniający minimalne wymagania:

1) Interfejs: współpracować ma z tabletem przez łącze USB zlokalizowane w stacji dokującej.

2) Zabezpieczenia: urządzenie musi posiadać wbudowane sprzętowe i programowe zabezpieczenia uniemożliwiające modyfikację zawartości Kart e-biletu przez niepowołane osoby.

3) Czytnik musi realizować funkcję zapisu na zastosowanych w projekcie Kartach e-biletu Kontraktów okresowych i Doładowań e-portmonetki.

4) Czytnik musi posiadać możliwość aktywowania go za pomocą kart matrycowych dostępnych u Zamawiającego (dostarczonych przez podmiot realizujący projekt).

15. Aparat fotograficzny typ 1.1) Aparat fotograficzny klasy kompakt, z lampą błyskową bez wymiennej

optyki2) Minimalna rozdzielczość zdjęcia: 1920 x 1080 pikseli.3) Pamięć wbudowana lub karta pamięci SD, SDHC, SDXC o wielkości min. 4

GB.4) Matryca wykonana w technologii CMOS5) Rozmiar matrycy: 1/ 2,3 cala6) Minimalna ilość megapikseli – 12 Mpix7) Stabilizacja optyczna obrazu8) Zoom optyczny min. 4x9) Wielkość ekranu min. 2,7 cala10) Złącza:

a) AV – 1 szt. b) HDMI lub mini HDMI lub micro HDMI – 1 szt. c) USB 2.0 lub mini USB lub micro USB – 1 szt.

11) Zasilanie: akumulator

Do każdego aparatu fotograficznego typ 1 Wykonawca musi dołączyć pasujący do niego statyw trójnożny do aparatu, posiadający regulację wysokości oraz możliwość płynnej regulacji wysokości kolumny środkowej, a także gumowe stopki na każdej z nóg statywu. Ponadto statyw musi gwarantować stabilność oraz wytrzymałość zamontowanego aparatu fotograficznego

16. UTM typ 1.

149

1) wyposażenie w interfejsy m.in. 4 x Gigabit Ethernet 10/100/1000 oraz port zarządzający,

2) system zabezpieczeń musi realizować zadania UTM (Unified Threat Management), wykonując kontrolę na poziomie sieci oraz aplikacji w oparciu o technologię dogłębnej analizy pakietów w warstwie aplikacji (w tzw. warstwie 7 modelu OSI),

3) posiadanie centralnej konsoli zarządzania (poprzez CLI, aplikację lub interfejs graficzny www), z której odbywa się całość konfiguracji (m.in. adresacja i routing IP) i zabezpieczeń (m.in. obiekty, polityka bezpieczeństwa firewall i VPN),

4) przepustowość Firewall – 100 Mbps,5) przepustowość IPSec VPN – 100 Mbps,6) ilość tuneli Gateway-to-Gateway IPSec VPN – 10,7) ilość jednoczesnych sesji SSL VPN Users – 25,8) ilość tuneli Client-to-Gateway IPSec VPN – 25,9) przepustowość SSL-VPN – 20 Mbps,10) sonda IPS,11) kontrola aplikacji sieciowych i możliwość ich blokady,12) zapobieganie włamaniom i ochrona sieci web: aktualizacja sygnatur dot.

najnowszych zagrożeń, zapobieganie popularnym atakom (cross-site scripting, SQL injection),

13) zarządzanie pasmem, priorytetyzacja ruchu,14) równoważenie obciążenia serwera oraz łącza,15) wsparcie dla szyfrowania VPN: IPsec VPN, SSL VPN, L2TP VPN, GRE,16) wsparcie dla technologii: dynamic IPsec tunnel switchover,17) ochrona przed różnymi typami ataków DDOS, np.: SYN flood i UDP flood,18) wsparcie dla różnych metod uwierzytelniania użytkowników: lokalnie,

RADIUS, AD, CA, LDAP,19) zarządzanie polisami bezpieczeństwa,20) możliwość wykonania raportów opartych o użytkownika, aplikację,

zawartość, czas, ruch, zagrożenia, adres URL,21) routing: statyczne tras IPv4, polisy routingu, RIP, OSPF,22) wsparcie dla różnych trybów pracy (transparent, routing, hybrid), tryby

wysokiej wydajności (active/active oraz active/standby),23) zarządzanie urządzeniami poprzez wbudowany intefejs www (funkcje

konserwacji, konfiguracji, rozwiązywanie problemów, a także tworzenie raportów dla dziennika zdarzeń).

150

Załącznik nr 4 do OPZ. Wymagania techniczne wobec Serwerowni.1. Wyposażenie Serwerowni (dostawa, instalacja i konfiguracja).

Warunki ogólne.1) Dostarczany sprzęt ma być fabrycznie nowy. Zamawiający wymaga, by

dostarczone urządzenia były nowe (tzn. wyprodukowane nie dawniej, niż na 6 miesięcy przed ich dostarczeniem) oraz by nie były używane (przy czym Zamawiający dopuszcza, by urządzenia były rozpakowane i uruchomione przed ich dostarczeniem wyłącznie przez Wykonawcę i wyłącznie w celu weryfikacji działania urządzenia lub jego konfiguracji, przy czym jest zobowiązany do poinformowania Zamawiającego o zamiarze rozpakowania sprzętu, a Zamawiający ma prawo inspekcji sprzętu przed jego rozpakowaniem), wraz ze sprzętem dostarczyć należy poświadczenie producenta potwierdzające datę produkcji urządzeń dla newralgicznych elementów Systemu.

2) Dostarczone elementy sprzętu serwerowego powinny być ze sobą kompatybilne (wymagane potwierdzenie producentów sprzętu, np. na listach HCL). Całość dostarczonego sprzętu musi być ze sobą połączona oraz skonfigurowana zgodnie z wymaganiami Zamawiającego oraz zgodnie z zaleceniami producentów Urządzeń oraz Oprogramowania.

3) Dostarczane licencje na Oprogramowanie serwerowe mają być proporcjonalne w stosunku do parametrów poszczególnych serwerów (maszyn) fizycznych.

4) Dostarczenie wymaganej ilości licencji dostępowych (tzw. CAL) dla urządzeń i klientów końcowych zgodnych z polityką licencjonowania producenta systemów (w przypadku, gdy jest to stosowne).

5) Dostarczenie licencji nieograniczonej dla użytkowników korzystających ze strony www.

2. Zakup, dostarczenie, instalacja oraz konfiguracja i wdrożenie następujących elementów sprzętu komputerowego.1) sprzęt serwerowy,2) sprzęt sieciowy.W ofercie należy uwzględnić okablowanie niezbędne do podłączenia wszystkich oferowanych urządzeń, w szczególności komplet okablowania pomiędzy switchami (wliczając w to wkładki SFP), switchami FC, zasilaczami, serwerami, do przyłączania macierzy (redundancja).Dostarczony sprzęt musi współpracować z siecią energetyczną o parametrach: 230 V, 50 Hz.

2.1 Dostarczenie wyposażenia dla szafy sieciowej.1) Redundantne zasilacze awaryjne UPS o mocy odpowiedniej dla

podtrzymania dostarczanego sprzętu przez min. 20 minut. W przypadku, gdy stan naładowania baterii spadnie poniżej 25%, powinien zostać wysłany sygnał do fizycznych serwerów skutkujący ich automatycznym wyłączeniem (dodatkowo wysłanie informacji do systemu monitoringu).

151

2) Konsola KVM profesjonalne rozwiązanie do zarządzania serwerami – Modularny KVM LCD, wyposażony w niezależnie wysuwana klawiaturę z touchpadem oraz 19” aktywną matrycę LCD o szerokich kątach widzenia, przystosowany do montażu w szafie typu RACK.

Szafa RACK 42U w standardzie 19” z odpowiednim chłodzeniem będzie dostępna w miejscu instalacji Serwerowni.

2.2 Zakup, instalacja i konfiguracja serwerów fizycznych o minimalnej konfiguracji.

2.2.1. Minimum 2 serwery z zainstalowanym systemem wirtualizacji, przystosowane do montażu w szafie RACK 19”, minimalna konfiguracja poniżej:

1) w dwa procesory ośmiordzeniowe,2) 96 GB pamięci RAM, 8 wolnych slotów,3) 2 dyski twarde pojemności 300 GB typu Hot Swap, SAS, 10000 obr./min.

pracujące w RAID 1,4) dwa redundantne zasilacze,5) dwie karty FC 8Gb/s,6) redundantne na poziomie sprzętowym karty sieciowe 1 GbE minimum 2-

portowe,7) zestaw redundantnych wentylatorów typu hot-plug,8) możliwość zdalnego zarządzania (konsoli) z dostępem do klawiatury i

myszy za pomocą graficznego interfejsu webowego, pozwalające na: włączenie, wyłączenie i restart serwera, podgląd logów sprzętowych serwera i karty, przejęcie pełnej konsoli tekstowej serwera niezależnie od jego stanu (także podczas startu), montowanie wirtualnych napędów CD/DVD/ISO, karta zdalnego zarządzania w formie rozwiązania sprzętowego działającej niezależne od zainstalowanego na serwerze systemu operacyjnego, w przypadku konieczności dodatkowe licencjonowania ww. możliwości – wymagane dostarczenie licencji wraz z serwerem.

UWAGA:Serwery z zainstalowanym systemem wirtualizacji powinny zostać wyposażone w odpowiednią ilość niezbędnych zasobów tak, aby przejąć utrzymanie maszyn wirtualnych (niezbędnych dla poprawnego działania Systemu) w przypadku awarii jednego z serwerów.

2.2.2.Serwer zarządzający – serwer zapewniający możliwość wirtualizacji, przystosowany do montażu w szafie RACK 19”, minimalna konfiguracja poniżej:

1) w jeden procesor szesnastordzeniowy, 2) 16 GB pamięci RAM, minimum 8 wolnych slotów,3) 2 dyski twarde pojemności 300 GB typu Hot Swap, SAS, 10 000 obr./min.

pracujące w RAID 1,4) dwa redundantne zasilacze,

152

5) jedną kartę FC 8Gb/s,6) zestaw redundantnych wentylatorów typu hot-plug,7) karta sieciowa 1 GbE minimum 2-portowa,8) możliwość zdalnego zarządzania (konsoli) z dostępem do klawiatury i

myszy za pomocą graficznego interfejsu webowego, pozwalające na: włączenie, wyłączenie i restart serwera, podgląd logów sprzętowych serwera i karty, przejęcie pełnej konsoli tekstowej serwera niezależnie od jego stanu (także podczas startu), montowanie wirtualnych napędów CD/DVD/ISO, karta zdalnego zarządzania w formie rozwiązania sprzętowego działającej niezależne od zainstalowanego na serwerze systemu operacyjnego, w przypadku konieczności dodatkowe licencjonowania ww. możliwości – wymagane dostarczenie licencji wraz z serwerem.

2.2.3. Serwer backupu – serwer zapewniający możliwość wirtualizacji, przystosowany do montażu w szafie RACK 19”, minimalna konfiguracja poniżej:

1) w jeden procesor szesnastordzeniowy, 2) 32 GB pamięci RAM, minimum 8 wolnych slotów,3) sprzętowy kontroler dysków realizujący: możliwość instalacji minimum 8

dysków twardych, system operacyjny – dwa dyski w RAID 1, dane – pozostałe dyski w RAID 5/6, dodatkowo jeden dysk należy skonfigurować jako Hot-Spare,

4) 8 dysków twardych pojemności 600 GB typu Hot Swap, SAS, 10 000 obr./min.,

5) dwa redundantne zasilacze, 6) jedną kartę FC 8Gb/s,7) oraz zestaw redundantnych wentylatorów typu hot-plug,8) karta sieciowa 1 GbE minimum 2-portowa,9) możliwość zdalnego zarządzania (konsoli) z dostępem do klawiatury i

myszy za pomocą graficznego interfejsu webowego, pozwalające na: włączenie, wyłączenie i restart serwera, podgląd logów sprzętowych serwera i karty, przejęcie pełnej konsoli tekstowej serwera niezależnie od jego stanu (także podczas startu), montowanie wirtualnych napędów CD/DVD/ISO, karta zdalnego zarządzania w formie rozwiązania sprzętowego działającej niezależne od zainstalowanego na serwerze systemu operacyjnego, w przypadku konieczności dodatkowe licencjonowania ww. możliwości – wymagane dostarczenie licencji wraz z serwerem,

10) napęd taśmowy LTO 5 wraz z zestawem 13 taśm oraz taśmą czyszczącą,11) Oprogramowanie do archiwizacji danych, opisane w punkcie 3.2.5.

Zamawiający dopuszcza możliwość rozbudowy serwera backupu o dodatkową półkę dyskową lub zewnętrzny zasób dyskowy (macierz lub NAS) niezależny od produkcyjnej macierzy dyskowej opisanej w punkcie 2.3. Zamawiający dopuszcza możliwość dostarczenia zewnętrznego napędu taśmowego LTO 5.

153

2.2.4. Dla każdego typu dostarczonych dysków twardych dla serwerów fizycznych należy dostarczyć po trzy dyski zapasowe. Parametry tych dysków powinny być zgodne z parametrami dysków w serwerach fizycznych. Celem zunifikowania projektowanej infrastruktury sprzętowej, wymagane jest, aby dostarczane serwery pochodziły od jednego producenta.

2.3 Zakup i konfiguracja macierzy dyskowej przewidzianej do montażu w szafie RACK 19” o minimalnej konfiguracji.1) wyposażona w co najmniej 12 dysków twardych o pojemności nie mniejszej

niż 450 GB i prędkości obrotowej 10k RPM z możliwością wykorzystania dysków SAS, FC oraz SATA,

2) interfejsy zewnętrzne Ethernet 10/100/1000,3) przynajmniej 2 porty FC 8/4/2/1 Gbps,.4) dwa redundantne zasilacze, 5) zestaw redundantnych wentylatorów,6) możliwość rozbudowy o dodatkową półkę dyskową,7) obsługa RAID1, RAID10, RAID5, RAID6 realizowane sprzętowo za pomocą

dedykowanego układu, z możliwością dowolnej ich kombinacji w obrębie oferowanej macierzy,

8) możliwość definiowania dysków SPARE lub odpowiedniej zapasowej przestrzeni dyskowej,

9) wymiana elementów Systemu w trybie „Hot-Swap”, a w szczególności takich, jak: kontroler(y), zasilacz(e), wentylatory, dyski,

10) 2 redundantne kontrolery macierzowe pracujące w trybie active/active dla pojedynczego wolumenu dyskowego (LUN),

11) przełączanie kanałów I/O w wypadku awarii ścieżki: Wsparcie dla automatycznego przełączania kanału IO w wypadku awarii ścieżki dostępu serwerów do macierzy w oparciu o rozwiązania oferowane przez producentów zaproponowanych systemów. Wsparcie powinno być dostępne w ramach oferowanych licencji,

12) współpraca z serwerami pracującymi pod kontrolą Systemów Windows Server 2012 R2/2016, Linux RedHat i SuSE, VMware.

UWAGA:W celu zapewnienia odpowiedniej wydajności oraz pojemności przestrzeni dyskowej dla realizacji celów Systemu, podana pojemność przestrzeni dyskowej oraz parametry techniczne macierzy mogą ulec zmianie po uzyskaniu zgody Zamawiającego.UWAGA:Szczegółowa konfiguracja sprzętowa serwerów, macierzy i biblioteki, w tym zasoby ich pamięci wewnętrznych, ma być zaproponowana przez Wykonawcę na etapie projektowym i musi uwzględniać wymagania dotyczące dostępności, jak i

154

wydajności Systemu i może różnić się od wartości podanych powyżej pod warunkiem, iż wartości minimalne będą zrealizowane.Ponadto propozycja Wykonawcy w w/w zakresie musi uwzględniać potrzeby i specyfikację funkcjonalności backupu i archiwizacji.Przestrzeń dyskowa powinna być tak dobrana (zarówno dla macierzy, serwera backupu, serwera www), aby spełnić poniższe wymagania przez okres min. 5 lat:

1) Dane dotyczące sprzedaży będą przechowywane na macierzy, a ich kopia będzie wykonywana nie rzadziej niż co 3 godziny na serwer backupu.

2) Dane dotyczące komunikacji (Podsystem DIP, rozkłady jazdy, itp.) będą przechowywane na macierzy, a ich kopia będzie wykonywana nie rzadziej niż co 3 godziny na serwer backupu.

3) Obrazy systemów wirtualnych będą przechowywane na macierzy, a ich kopia będzie wykonywana nie rzadziej niż co 1 tydzień na serwer backupu.

4) Dane dotyczące logów będą przechowywane na serwerze logów, a ich kopia będzie wykonywana nie rzadziej niż co 24 godziny na serwer backupu.

5) Wymagane dane dotyczące informacji prezentowanych przez serwer www będą przechowywane na serwerze www, a ich kopia będzie możliwa do odtworzenia z serwerów centralnych w każdej chwili.

6) Dane na serwerze backupu powinny być dostępne przynajmniej przez 1 miesiąc.

2.4 Zakup, instalacja i konfiguracja przełączników oraz zapory sieciowej o minimalnej konfiguracji.

2.4.1. Na potrzeby komunikacji pomiędzy serwerami, a macierzą i biblioteką taśmową, należy dostarczyć dwa przełączniki Fibre Channel z możliwością pracy portów FC z prędkościami 8, 4, 2, 1 Gb/s z funkcją autonegocjacji prędkości, wyposażone w min. 8 portów z możliwością rozbudowy/zalicencjonowania przynajmniej do 16 portów, przeznaczone do montażu w szafie RACK 19”. Sieć SAN powinna zostać skonfigurowana tak, aby zapewnić pracę redundantną dla wszystkich podłączonych urządzeń. Możliwe zarządzanie poprzez CLI lub interfejs graficzny.

2.4.2. Na potrzeby realizacji połączeń lokalnych wewnątrz infrastruktury Operatora, należy dostarczyć i skonfigurować dwa zarządzalne przełączniki sieciowe warstwy 3-ciej połączone w stos (stack), wyposażone w co najmniej:1) Urządzenie o stałej konfiguracji montowane w szafie RACK 19” o wysokości

1U.;2) Przełącznik posiadający 48 portów Ethernet 10/100/1000 BaseT.3) Przełącznik posiadający min. 2 porty SFP+.4) Przełącznik musi posiadać co najmniej 256 MB pamięci DRAM oraz 64 MB

pamięci Flash.5) Urządzenie musi posiadać możliwość tworzenia stosu o przepustowości co

najmniej 64 Gbps w stosie.

6) Przełącznik musi posiadać wydajność przełączania w warstwie 2. przynajmniej 95 Mbps dla 64 bajtowych pakietów.

7) Wielkość ramki jumbo w Ethernet: 9612 B.

155

8) Przełącznik musi zapewniać obsługę minimum 12.000 adresów MAC.9) Przełącznik musi zapewniać obsługę minimum 4.000 tras w tablicy routingu.

10) Przełącznik musi zapewniać obsługę minimum 4.000 sieci VLAN.11) Przełącznik ma mieć możliwość montażu dwóch wymienialnych zasilaczy

pracujących redundantnie. Oferowany przełącznik musi być wyposażony w minimum dwa redundantne zasilacze.

12) Przełącznik musi zapewniać przełączanie w warstwie drugiej L2 i trzeciej L3.13) Autonegocjacja portów: autonegocjacja prędkości, duplex-u oraz połączenia

(MDI/MDIX).14) Przełącznik musi umożliwiać przełączanie w warstwie trzeciej oraz

definiowanie routingu opartego na protokole RIP v1, RIP v2 oraz na routingu statycznym.

15) Przełącznik musi posiadać możliwość rozbudowy, po zakupie dodatkowej licencji, do funkcjonalności PBR (ang. Policy Based Routing).

16) Przełącznik musi obsługiwać następujące mechanizmy związane z zapewnieniem ciągłości pracy sieci:a) IEEE 802.1s Rapid Spanning Tree;b) IEEE 802.1w Multi-Instance Spanning Tree;c) możliwość grupowania portów zgodnie ze specyfikacją IEEE 802.3ad

(LACP).17) Przełącznik musi obsługiwać mechanizmy związane z zapewnieniem jakości

usług w sieci (QoS).18) Urządzenie musi obsługiwać następujące mechanizmy związane z

zapewnieniem bezpieczeństwa sieci:a) wiele poziomów dostępu administracyjnego poprzez konsolę;b) autoryzacja użytkowników/portów oparta na IEEE 802.1x oraz EAP;c) możliwość uzyskania dostępu do urządzenia przez SNMP v3 i SSH v2;d) funkcjonalność prywatnej sieci VLAN, czyli możliwość blokowania ruchu

pomiędzy portami w obrębie jednej sieci VLAN (tzw. porty izolowane) z pozostawieniem możliwości komunikacji z portem nadrzędnym;

e) kontrola dostępu do portu oparta na adresie MAC;f) podsłuchiwanie (ang. snooping) DHCP;g) dynamiczna inspekcja ARP (DAI).

19) Przełącznik musi umożliwiać lokalną obserwację ruchu na określonym porcie, polegającą na kopiowaniu pojawiających się na nim ramek i przesyłaniu ich do urządzenia monitorującego przyłączonego do innego portu.

20) Przełącznik musi mieć możliwość synchronizacji zegara czasu za pomocą protokołu NTP.

21) Przełącznik powinien posiadać możliwość połączenia z innymi przełącznikami tego samego typu w stos zapewniający możliwość zarządzania za pomocą pojedynczego adresu IP.

22) Urządzenie musi umożliwiać zarządzania poprzez interfejs CLI (konsolę).23) Plik konfiguracyjny urządzenia (w szczególności plik konfiguracji parametrów

routingu) powinien być możliwy do edycji w trybie offline. Tzn. konieczna jest możliwość przeglądania i zmian konfiguracji w pliku tekstowym na

156

dowolnym urządzeniu klasy PC. Po zapisaniu konfiguracji w pamięci nieulotnej musi być możliwe uruchomienie urządzenia z nową konfiguracją. W pamięci nieulotnej musi być możliwość przechowywania przynajmniej 4 plików konfiguracyjnych. Zmiany aktywnej konfiguracji muszą być widoczne natychmiastowo – nie dopuszcza się częściowych restartów urządzenia po ich dokonaniu.

24) W zakresie zarządzania urządzeniem powinna istnieć możliwość:a) pobrania z i wczytania do urządzenia konfiguracji przez protokół FTP lub

TFTP,b) zdalnego wczytania Oprogramowania do urządzenia przez protokół FTP

lub TFTP.25) Urządzenie ma zapewniać obsługę rejestracji Logging Syslog.26) Standardy:

a) IEEE 802.1w RSTP,b) IEEE 802.3ad LACP,c) IEEE 802.1ae MAC Security,d) IEEE 802.3af Authenticated Key Agreement for MACSec,e) IEEE 802.3x pełen dupleks dla portów 10BASE-T, 100BASE-TX i

1000BASE-T,f) IEEE 802.1D Spanning Tree Protocol,g) IEEE 802.1p CoS Prioritization,h) IEEE 802.1Q VLAN,i) IEEE 802.3 10BASE-T,j) IEEE 802.3u 100BASE-TX,k) IEEE 802.3ab 1000BASE-T,l) IEEE 802.3z 1000BASE-X,m) SNMPv1,n) SNMPv2c,o) SNMPv3,p) RMON I (Remote Network Monitoring),q) RMON II.

27) Przełączniki powinny zostać skonfigurowane tak, aby zapewnić pracę redundantną dla wszystkich podłączonych w sieci urządzeń.

2.4.3. System ma być podłączony do sieci Internet za pomocą urządzeń zapewniających bezpieczeństwo komunikacji polegające na filtrowaniu ruchu sieciowego odbywającego się za pomocą różnych protokołów sieciowych poprzez sprawdzanie rodzaju protokołów, pochodzenia pakietówi akceptowanie pożądanych (firewall). W związku z tym Wykonawca dostarczy dwa urządzenia typu UTM pracujące redundantnie w klastrze, przeznaczone do montażu w szafie RACK 19”, spełniające poniższe kryteria minimalne takie jak:

1) wyposażenie w interfejsy m.in. 4 x Gigabit Ethernet 10/100/1000 oraz port zarządzający,

2) system zabezpieczeń musi realizować zadania UTM (Unified Threat Management), wykonując kontrolę na poziomie sieci oraz aplikacji w oparciu o technologię dogłębnej analizy pakietów w warstwie aplikacji (w tzw. warstwie 7 modelu OSI),

157

3) posiadanie centralnej konsoli zarządzania (poprzez CLI, aplikację lub interfejs graficzny www), z której odbywa się całość konfiguracji (m.in. adresacja i routing IP) i zabezpieczeń (m.in. obiekty, polityka bezpieczeństwa firewall i VPN),

4) przepustowość Firewall - 100 Mbps,5) przepustowość IPSec VPN – 100 Mbps,6) ilość tuneli Gateway-to-Gateway IPSec VPN – 25,7) ilość jednoczesnych sesji SSL VPN Users – 25,8) ilość tuneli Client-to-Gateway IPSec VPN – 300,9) przepustowość SSL-VPN – 20 Mbps,

10) sonda IPS,11) kontrola aplikacji sieciowych i możliwość ich blokady,12) zapobieganie włamaniom i ochrona sieci web: aktualizacja sygnatur dot.

najnowszych zagrożeń, zapobieganie popularnym atakom (cross-site scripting, SQL injection),

13) zarządzanie pasmem, priorytetyzacja ruchu,14) równoważenie obciążenia serwera oraz łącza,15) wsparcie dla szyfrowania VPN: IPsec VPN, SSL VPN, L2TP VPN, GRE,16) wsparcie dla technologii: dynamic IPsec tunnel switchover,17) ochrona przed różnymi typami ataków DDOS, np.: SYN flood i UDP flood,18) wsparcie dla różnych metod uwierzytelniania użytkowników: lokalnie,

RADIUS, AD, CA, LDAP,19) zarządzanie polisami bezpieczeństwa,20) możliwość wykonania raportów opartych o użytkownika, aplikację,

zawartość, czas, ruch, zagrożenia, adres URL,21) routing: statyczne tras IPv4, polisy routingu, RIP, OSPF,22) wsparcie dla różnych trybów pracy (transparent, routing, hybrid), tryby

wysokiej wydajności (active/active oraz active/standby),23) zarządzanie urządzeniami poprzez wbudowany interfejs www (funkcje

konserwacji, konfiguracji, rozwiązywanie problemów, a także tworzenie raportów dla dziennika zdarzeń).

3. Oprogramowanie systemowe i zarządzające.3.1Opis systemów dla aplikacji dziedzinowych.

1) Zamawiający oczekuje instalacji na serwerze aplikacyjnym pracującym w klastrze systemów operacyjnych, które będą zwirtualizowane. Systemy operacyjne powinny być wykorzystane funkcjonalnie w następujący sposób:a) system operacyjny 1: Aplikacja Systemu Dynamicznej Informacji

Pasażerskiej.b) system operacyjny 2: Aplikacja Biletomatów mobilnych i stacjonarnych.c) system operacyjny 3: Aplikacja Systemu biletu elektronicznego.d) system operacyjny 4: Usługi publiczne (na serwerze www w strefie DMZ).e) system operacyjny 5: Środowisko testowe dot. Podsystemu e-bilet.Wykonawca w trakcie wdrożenie na etapie projektu Systemu może zaproponować inne rozwiązanie, w pełni spełniające warunki OPZ.

2) W przypadku serwera bazodanowego także pracującego w klastrze, minimalna ilość zainstalowanych systemów operacyjnych powinna wynieść

158

3-4 szt. Systemy będą zwirtualizowane. Systemy operacyjne powinny być wykorzystane funkcjonalnie w następujący sposób:a) system operacyjny 1: Zarządzanie bazą Podsystemu DIP, zarządzanie

Oprogramowaniem Biletomatów stacjonarnych i mobilnych, pozostałe usługi związane z transportem.

b) system operacyjny 2: Zarządzanie bazą Podsystemu e-bilet (zarówno produkcja i środowisko testowe), pozostałe usługi związane ze sprzedażą.

c) system operacyjny 3: Zarządzanie bazą systemu usług publicznych (dla serwera www).

Wykonawca w trakcie wdrożenie na etapie projektu Systemu może zaproponować inne rozwiązanie, w pełni spełniające warunki OPZ.

3) Wymagania dot. zapewnienia niezawodności pracy systemów i dostarczanych usług:a) Zamawiający dopuszcza przerwę w działaniu systemów aplikacji (w

przypadku awarii) na czas wymagany na uruchomienie zwirtualizowanych systemów redundantnych;

b) w przypadku systemów bazodanowych, Zamawiający wymaga, aby w razie awarii maszyny fizycznej, żadne dane nie uległy utraceniu. Dopuszczalne jest zastosowania klastrów w trybie Active – Passive.

4) Systemy zwirtualizowane powinny być skonfigurowane w taki sposób, żeby zapewnić rozłożoną dystrybucję wykorzystania zasobów serwerów fizycznych w trybie normalnego działania, np. jeden fizyczny serwer będzie obsługiwał systemy aplikacji, a drugi systemy bazodanowe.

5) Serwer www powinien być tak skonfigurowany, aby potencjalnie niepożądane działania (nadmierne obciążenie zasobów, ataki DDOS, itp.) nie powodowały zakłóceń w działaniu Systemu Centralnego. Zamawiający wymaga, aby posiadał on własną bazę danych dla usług dostępnych na serwerze komunikującą się z bazą centralną, na której powinny być dostępne w czasie rzeczywistym przynajmniej poniższe informacje:a) profile osób korzystających ze sklepu Internetowego (w tym historia

transakcji),b) zakup biletów, dane przekazywane do Systemu Centralnego,c) dane lokalizacyjne autobusów / informacje o opóźnieniach / lokalizacja na

mapie.Serwer aplikacji z usługami publicznymi w strefie DMZ będzie korzystał z oddzielnego serwera bazy danych (podniesienie poziomu bezpieczeństwa).

UWAGA:Wykonawca może zaproponować inne rozwiązanie, gwarantujące bezpieczeństwo Systemu, względem serwera www , w pełni spełniające warunki OPZ.Konfiguracja systemów powinna umożliwić integrację z istniejącym środowiskiem Operatora. W szczególności pozwalając na wdrożenie mechanizmów SSO (Single sign-on) dla użytkowników końcowych korzystających z Systemu Centralnego.

159

3.2Opis Oprogramowania serwerowego.Dostarczone licencje muszą uprawniać do bezterminowego, nieograniczonego czasowo korzystania z oprogramowania.System operacyjny zainstalowany na każdym z serwerów (fizycznym lub wirtualnym) musi być kompatybilny z zainstalowanym na nim Oprogramowaniem (musi umożliwiać wykorzystanie wszystkich jego funkcji).W celu konfiguracji środowiska serwerowego należy dostarczyć, zainstalować oraz skonfigurować następujące elementy:3.2.1Oprogramowanie wirtualizacyjne posiadające co najmniej poniższe

funkcjonalności:1) Systemy wirtualizacji zostaną zainstalowane na serwerach fizycznych

(wskazanych w punkcie 2.2). Zarządzanie tymi systemami będzie odbywać się z serwera zarządzającego (wirtualnego lub fizycznego) z zainstalowanym systemem operacyjnym i Oprogramowaniem zarządzającym, zgodnym z wymaganiami producenta Systemu wirtualizacji.

2) Warstwa wirtualizacji musi być zainstalowana bezpośrednio na sprzęcie fizycznym bez dodatkowych pośredniczących systemów operacyjnych.

3) Rozwiązanie musi zapewnić możliwość obsługi wielu instancji systemów operacyjnych (zwirtualizowanych) na jednym serwerze fizycznym.

4) Polityka licencjonowania musi umożliwiać przenoszenie licencji na oprogramowanie do wirtualizacji pomiędzy serwerami różnych producentów z zachowaniem wsparcia technicznego i zmianą wersji Oprogramowania na niższą (downgrade). Licencjonowanie nie może odbywać się w trybie OEM.

5) Rozwiązanie musi wspierać przynajmniej następujące systemy operacyjne: Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2016, RHEL 6, RHEL 7.

6) Rozwiązanie powinno posiadać centralną konsolę graficzną do zarządzania maszynami wirtualnymi i do konfigurowania innych funkcjonalności.

7) Rozwiązanie musi zapewnić możliwość bieżącego monitorowania wykorzystania zasobów fizycznych infrastruktury wirtualnej (np. wykorzystanie procesorów, pamięci RAM, wykorzystanie przestrzeni na dyskach/wolumenach) oraz przechowywać i wyświetlać dane historyczne.

8) Oprogramowanie do wirtualizacji oraz Oprogramowanie zarządzające musi posiadać możliwość integracji z usługami katalogowymi Microsoft Active Directory.

9) Zapewniać możliwość przenoszenia maszyn wirtualnych w czasie ich pracy pomiędzy serwerami fizycznymi oraz danych maszyn wirtualnych pomiędzy wolumenami dyskowymi bez konieczności wyłączania maszyn wirtualnych.

10) Rozwiązanie powinno posiadać możliwość określenia limitów wykorzystania przydzielonych zasobów.

11) Umożliwia tworzenie/przywracanie kopii stanu maszyny, m.in. na potrzeby tworzenia kopii zapasowych bez przerywania ich pracy.

12) Musi posiadać mechanizm wysokiej dostępności, aby w przypadku awarii lub niedostępności serwera fizycznego wybrane przez administratora i

160

uruchomione na nim wirtualne maszyny zostały uruchomione na innych serwerach z zainstalowanym Oprogramowaniem wirtualizacyjnym.

13) System musi posiadać funkcjonalność wirtualnego przełącznika (virtual switch) umożliwiającego tworzenie sieci wirtualnej w obszarze hosta i pozwalającego połączyć maszyny wirtualne w obszarze jednego hosta, a także na zewnątrz sieci fizycznej.

14) Pojedynczy wirtualny przełącznik musi posiadać możliwość przyłączania do niego dwóch i więcej fizycznych kart sieciowych, aby zapewnić bezpieczeństwo połączenia ethernetowego w razie awarii karty sieciowej.

15) Wirtualne przełączniki musza obsługiwać wirtualne sieci lokalne (VLAN).16) Możliwość zarządzania i administrowania infrastrukturą wirtualną z poziomu

powłoki wiersza poleceń.17) Obsługuje pamięć masową podłączaną przez FC (Fibre Channel).

3.2.2 Wykonawca utworzy następujące maszyny wirtualne oraz zainstaluje na nich odpowiednie systemy operacyjne:

3.2.2.1 Maszyna wirtualna z usługami katalogowymi, serwerem dns oraz dhcp z zainstalowanym systemem operacyjnym.

3.2.2.2 Maszyny wirtualne służące jako serwery aplikacji dziedzinowych.3.2.2.3 Maszyny wirtualne z zainstalowanym silnikiem baz danych.Maszyny opisane w punktach 3.2.2.1 – 3.2.2.3 muszą posiadać zainstalowany system operacyjny spełniający poniższe wymagania:

1) Usługi katalogowe pozwalające na zarządzanie zasobami w sieci (użytkownicy, komputery, drukarki, udziały sieciowe).

2) Serwer DNS i serwer DHCP.3) Zarządzanie uwierzytelnianiem.4) Zawierające zintegrowany z Systemem interfejs graficzny do zarządzania

użytkownikami.5) Kompatybilność z systemem wirtualizacji i Oprogramowaniem backupu.6) Możliwość utworzenia relacji zaufania struktur katalogowych z istnieją siecią

Operatora.7) Możliwość wdrożenia SSO (Single Sign On) do aplikacji i usług będących

zainstalowanych na systemach dla pracowników łączących się z sieci Operatora.

8) Możliwość aktualizacji bez dostępu do Internetu z serwera aktualizacji dostępnego w siedzibie Operatora.

9) Możliwość pracy w aplikacjach poprzez bezpieczne protokoły zdalnego pulpitu dla użytkowników nie administracyjnych (po wykupieniu odpowiedniej licencji), nie wymagający Oprogramowania innych producentów, zintegrowany z usługami katalogowymi, w tym:a) Przekazywanie do serwera urządzeń wejściowych (klawiatura, mysz, itp.).b) Przekazywanie podłączonych wewnętrznych i zewnętrznych pamięci

masowych.c) Przekazywanie podłączonych drukarek, w tym drukarek fiskalnych.

161

d) Przekazywanie innych urządzeń podłączonych za pomocą portów USB i RS232.

3.2.2.4 Maszyna wirtualna służąca jako serwer zarządzający (w przypadku, gdy serwer zarządzający nie będzie serwerem fizycznym).

3.2.2.5 Maszyna wirtualna na potrzeby monitorowania oraz serwera logów z zainstalowanym systemem operacyjnym spełniającym poniższe wymagania:1) Zainstalowane Oprogramowanie do monitoringu opisane w punkcie 3.2.6;2) Zainstalowane Oprogramowanie do zbierania oraz przetwarzania logów z

infrastruktury serwerowej – z wszystkich niezbędnych systemów oraz wykorzystywanych urządzeń;

3) Autoryzacja i autentykacja użytkowników korzystających z systemu monitoringu i logów;

UWAGA:Wykonawca może zaproponować inne rozwiązanie w zakresie doboru rodzaju oraz funkcji maszyn wirtualnych pod warunkiem, że będzie ono realizowało wymagania Zamawiającego zawarte OPZ w pełnym zakresie.3.2.3 Oprogramowanie bazodanowe (platforma bazodanowa) typu klient-serwer

– Oprogramowanie posiadające co najmniej poniższe funkcjonalności:1) zainstalowane na serwerach baz danych;2) obsługa wielu użytkowników jednocześnie;3) posiadanie wsparcie dla wirtualizacji;4) obsługa niezbędnych mechanizmów bezpieczeństwa, autoryzacji czy

autentykacji;5) obsługa języka w standardzie SQL;6) transakcyjność;7) instancyjność;8) skalowalność;9) uruchamianie silnika bazy danych na serwerze jako usługa;

10) posiada narzędzia i funkcjonalności Business Intelligence;11) umożliwia definiowanie wyzwalaczy;12) posiada narzędzia do harmonogramowania zadań;13) posiada narzędzia do obsługi usług integracji danych;14) wsparcie dla mechanizmów replikacji oraz wysokiej dostępności;15) możliwość pracy w klastrze w układzie Active – Passive;

3.2.4 Oprogramowanie na potrzeby serwera aplikacyjnego, które musi zapewniać:

1) zainstalowane na serwerach aplikacyjnych;2) możliwość komunikacji z klientami z wykorzystaniem protokołów

HTTP/HTTPS;3) możliwość dostarczania dokumentów HTML oraz wszelkich dodatkowe

materiałów, które mogą być zawarte w dokumencie, takie jak obrazy, arkusze stylów i skryptów;

4) możliwość serwowania klientom za pośrednictwem przeglądarek internetowych aplikacji stworzonych w językach z rodziny PHP lub ASP lub innych skryptowych.

162

3.2.5 Oprogramowanie do backupu i archiwizacji danych zawierające odpowiednie licencje, które musi umożliwiać:1) na serwerze backupu zostanie zainstalowany system operacyjny (zgodny z

wymaganiami producenta Oprogramowania backupu), na którym zostanie zainstalowane Oprogramowanie do backupu;

2) tworzenie kopii zapasowych przyrostowych, różnicowych i całościowych;3) zarządzanie kopiami zapasowymi za pośrednictwem pojedynczej konsoli;4) obsługę backupu po sieci LAN oraz SAN;5) automatyzację procesu wykonywania kopii zapasowych zgodnie z

zaplanowanym harmonogramem (kalendarzem);6) wykonywanie kopii otwartych plików dla platformy Windows, Linux;7) definiowanie różnych strategii wykonywania kopii zapasowych dla

poszczególnych obiektów podlegających backupowi;8) możliwość zapisu danych przynajmniej na następujących zasobach: zasobie

dyskowym, napędzie taśmowym;9) wsparcie dla deduplikacji;

10) możliwość wykonania kopii zapasowej całej maszyny wirtualnej, wybranych zasobów (pliki, aplikacje) działające w maszynie wirtualnej;

11) możliwość odzysku pojedynczych plików bezpośrednio z kopii całej maszyny wirtualnej, bez konieczności odtwarzania całej maszyny wirtualnej;

12) bezpośrednia możliwość backupu i odzysku baz danych dla zaproponowanego silnika bazy danych;

13) zapis tych samych danych (kopii zapasowej) na zasób dyskowy i napęd taśmowy (lub inne media);

14) kompatybilność z zaproponowanym sprzętem oraz z zaproponowanymi systemami wirtualizacji, systemami operacyjnymi oraz z resztą zaproponowanego Oprogramowania.

3.2.6 Oprogramowanie zapewniające monitoring działania infrastruktury (zainstalowane na serwerze monitoringu):1) cała infrastruktura sprzętowa ma być objęta monitoringiem umożliwiającym

wykrycie potencjalnych miejsc awarii i problemów. Dopuszczone jest stosowanie różnych narzędzi dedykowanych do obsługi różnych elementów infrastrukturalnych, jednak nie więcej niż jedno narzędzie do jednego rodzaju elementów infrastrukturalnych;

2) narzędzia monitorujące mają umożliwiać obserwację linii trendów zachowania się poszczególnych komponentów wchodzących w skład Systemu;

3) narzędzia monitorujące mają umożliwiać monitorowanie i zarządzenie urządzeniami za pomocą protokołów SNMP (w tym w wersji 3);

4) narzędzia monitorujące mają umożliwiać analizę danych i generowanie raportów za pomocą interfejsów CLI i GUI;

5) narzędzia monitorujące mają mieć możliwość wysyłania komunikatów mailowych i/lub SMS w przypadku przekroczenia ustalonych progów alarmowych. Wykonawca zapewni odpowiednie Oprogramowanie i sprzęt do komunikacji poprzez sieć komórkową. Zamawiający zapewni usługę oraz kartę SIM z dostępem do sieci komórkowej

163

6) narzędzia monitorujące oraz same urządzenia sieciowe i serwery powinny zapisywać wybrane informacje i zdarzenia na serwerze logów będącym maszyną wirtualną.

3.2.7Oprogramowanie antywirusowe:Operator zapewni oprogramowanie antywirusowe „Eset Endpoint Antivirus” dla serwerów. W przypadku zastosowania systemów operacyjnych niezgodnych z w/w oprogramowaniem, Wykonawca dostarczy inne Oprogramowanie równoważne z posiadanym przez Operatora,w szczególności spełniające poniższe wymagania:1) usuwanie wirusów, makro–wirusów, robaków internetowych oraz koni

trojańskich (oraz wirusówi robaków z plików skompresowanych oraz samorozpakowujących się) lub kasowanie zainfekowanych plików;

2) zapewnienie stałej ochrony wszystkich zapisywanych, odczytywanych, a także uruchamianych plików przez mechanizm skanujący pracujący w tle wraz z metodą heurystyczną wyszukiwania wirusów (na życzenie); pliki te mogą być skanowane: a) na dyskach twardych,b) w boot sektorach,c) na zewnętrznych nośnikach pamięci (np. podłączonych przez port USB);

3) możliwość samodzielnego pobierania aktualizacji z Internetu;4) możliwość aktualizowania Oprogramowania i baz antywirusowych z

lokalnych serwerów Operatora, bez dostępu do Internetu;5) scentralizowaną obsługę wirusów polegającą na przekazywaniu

nieodwracalnie zainfekowanych plików do bezpiecznego miejsca w postaci centralnej kwarantanny na centralnym serwerze, w celu przeprowadzenia dalszych badań;

6) wbudowana w Oprogramowanie funkcja do wysyłania podejrzanych lub zainfekowanych nowymi wirusami plików do producenta w celu uzyskania szczepionek;

7) wyszukiwanie i usuwanie wirusów w plikach skompresowanych (także zagnieżdżonych wewnątrz innych plików skompresowanych) w szczególności z plikach typu ZIP, GNU, LZH/LHA, BinHex, HTTP, ARJ, RAR, MIME/UU, TAR, kontenery CAB,UUE, Rich Text Format, ArcManager, MS-TNEF;

8) pełna polska wersja językowa Oprogramowania.

4. Wymagania dotyczące wydajności infrastruktury serwerowej.4.1Maksymalny procent zajętości macierzy dyskowej oraz serwera backupu,

przechowujących zarówno wszystkie bazy danych i backupy systemów operacyjnych w trakcie trwania gwarancji: 70% dostępnej pojemności. W sytuacji kiedy okaże się, że w tracie trwania gwarancji dane przetrzymywane na fizycznych serwerach i macierzach przekraczają rozmiar 70% dostępnej pojemności, Wykonawca w celu zmniejszenia zajętości macierzy ma obowiązek jej rozbudowy

164

o dodatkowe nowe dyski lub wymianę dotychczasowych dysków na nowe. Koszt rozbudowy macierzy pokryje Wykonawca.

4.2Sumaryczne obciążenie procesora/procesorów serwera aplikacyjnego i bazodanowego w przeciągu kolejnych wybranych 12 godzin nie może być większe niż 50%. 

5. Wymagania dotyczące wydajności Oprogramowania (połączona ze sprzętem).

5.1Dla Podsystemu DIP.1) maksymalny czas przetworzenia pojedynczej ramki o pozycji GPS autobusu

od momentu jej odebrania do przetworzenia przez System Centralny i zapisania w bazie danych: 1 sekunda;

2) maksymalna liczba ramek o pozycjach GPS autobusów obsługiwana przez System w ciągu jednej sekundy: 200.

5.2Dla Podsystemu e-bilet.1) maksymalny czas na wyświetlenie wyników historii zakupowej wybranej

Karty e-bilet w bazie zawierającej do 50 000 kart: 2 sekundy;2) maksymalny czas na wyświetlenie wyników historii przejazdów dla danej

Karty z ostatnich 3 miesięcy w bazie zawierającej 98.550.000 rekordów (obliczone na podstawie: 90 autobusów x 3 lata (1095 dni) x 20 kursów dziennie x 50 pasażerów na kursie): 30 sekund;

3) obsługa sprzedaży poprzez Biletomaty mobilne i stacjonarne oraz punkty sprzedaży na poziomie 500.000 transakcji/mc w czasie nie dłuższym niż 2 sekundy na transakcję.

5.3Dla serwisu usług publicznych.1) obsługa zapytań do serwera www na poziomie 30.000 sesji na dzień, czas

generowania strony nie dłuższy niż 2 sekundy (w tym realizacji zakupu w sklepie online);

2) maksymalny czas na prezentowanie rozkładu z wybranego przystanku dla wybranych linii: 1 sekunda;

3) odświeżanie informacji o lokalizacji autobusów na mapie: maksymalnie co 10 sekund.

Zamawiający zastrzega możliwość przeprowadzenia testów wydajnościowych dot. Oprogramowania. Na potrzeby testów Wykonawca powinien przygotować dane  wejściowe i bazy danych w oczekiwanej przez Zamawiającego wielkości.

W sytuacji kiedy na podstawie testów wydajnościowych lub obserwacji Zamawiającego w trakcie eksploatacji Systemu okaże się, że minimalne parametry serwerów, Oprogramowania i pozostałych elementów infrastruktury

165

serwerowej są niewystarczające względem zapisów wydajnościowych dostarczanego przez Wykonawcę Oprogramowania, Wykonawca powinien na swój koszt rozbudować wyposażenie Serwerowni zarówno pod kątem urządzeń i Oprogramowania tak aby spełniało określone przez Zamawiającego zapisy dot. wydajności Systemu.

166

Załącznik nr 5 do OPZ. Przewidywany harmonogram wymiany autobusów.

MARKA/TYP2018 2018 2019

PP K Z P

W1K Z P

W2K Z P

W3

MAN NL 202 7 5 2 2 0 0MAN NG 272 (PRZEG.) 7 7 0 0 0

JELCZ 120 MM/211

11 0 0 0

MAN NG 312 (PRZEG.) 4 4 0 0 0JELCZ L090 M 1 1 1 0 0JELCZ M081MB (MIDI) 3 3 3 0 0MAN NL 222 7 7 7 0 0MAN NL 223 1 1 1 0 0MAN NL 263 2 2 1 1 1 0MAN NL 313 1 1 0 0 0JELCZ 121 I 7 7 7 7 0MAN LION’S CITY G 1 1 1 1 0SCANIA OMNICITY 3 3 3 3

MAN LION’S CITY31 31 31 31

MAN LION’S CITY L 5 5 5 5MAN A 26 3 3 3 0 0AUTOBUS MIDI 0 0 3 3 3

AUTOBUS MAXI 12m 013 13

20 33

10 43

AUTOBUSY MEGA 18m 0

15 15 15 15

RAZEM94

28

28 94

18

23 99 9

10

100

Oznaczenia:PP – stan początkowy,PWn – stan po kolejnych wymianach autobusów,K – kasacje/wycofanie autobusów,Z – wprowadzenie nowego autobusów (zakup).

Rok 2018- Dostawa 13 autobusów MAXI oraz 15 autobusów MEGA planowana jest w I/II

kwartale 2018 roku.- Autobus MAN NL 313 zostanie wycofany w I półroczu 2018 roku. - 11 autobusów przegubowych (MAN NG 272 - 7 szt., MAN NG 312 - 4 szt.)

planowane jest wycofanie do końca marca 2018 roku. - 16 autobusów MAXI (MAN NL 202 - 5 szt., JELCZ MM/2 - 11 szt. ) planowane

jest wycofanie do końca marca 2018 roku.- Dostawa 3 autobusów MIDI oraz 20 autobusów MAXI 12m planowana jest w

sierpniu 2018 roku.

167

- 17 autobusów MAXI, 3 autobusy MEGA (MAN A26) oraz 3 autobusy MIDI (JELCZ 081MB) planowane jest wycofanie do końca września 2018 roku.

Rok 2019- Dostawa 10 autobusów MAXI 12m planowana jest w styczniu 2019 roku. 3

autobusy MAXI 12m oraz 1 autobus MEGA planowane jest wycofanie do końca lutego 2019 r.

UWAGA: Wszystkie wymiany należy traktować jako planowane. Ze względu na brak możliwości przewidywania czasu trwania procedur przetargowych, terminy te mogą ulec zmianie. Zakładane jest jednak wykonanie wszystkich wymian autobusów do końca roku 2019.

Załącznik nr 6 do OPZ. Etapy wykonywania prac.

Lp. Zakres

Maksymalny termin liczony w dniach od podpisania

umowy1 Zawarcie umowy -2 Projekt Systemu 603 Uruchomienie Podsystemu RJ. 904 Dostawa, montaż i uruchomienie Tablic DIP w oparciu o

system kiedyprzyjedzie.pl (nie wymaga projektu całego Systemu).

100

5 Dostarczenie i uruchomienie rozwiązania serwerowego dla Systemu Centralnego

120

6 Uruchomienie Podsystemu e-bilet. 1807 Uruchomienie Podsystemu DIP. 2408 Uruchomienie końcowe Systemu. 270

1. Montaż będzie się odbywał w zajezdni MZK Sp. z o.o. oraz w miejscu produkcji nowych autobusów dostarczanych w ramach odrębnej umowy. Lista obecnie użytkowanych autobusów została przedstawiona w załączniku nr 2 do OPZ Lista autobusów z wyposażeniem, natomiast harmonogram planowanych wymian autobusów przedstawiono w załączniku nr 5 do OPZ. Przewidywany harmonogram wymiany autobusów.

2. Zamawiający wymaga, aby montaż urządzeń w autobusach odbywała się w jak największym możliwym stopniu w miejscu produkcji nowych autobusów.

3. Przedstawiony w załączniku nr 5 do OPZ harmonogram wymiany autobusów może ulec zmianie, ze względu na specyfikę zakupów prowadzonych w ramach postępowań publicznych w oparciu o ustawę Prawo zamówień publicznych. Ryzyko zmian Wykonawca musi zawrzeć w ramach umowy.

4. Część Modułów Pokładowych Systemu może wymagać pierwotnie zamontowaniu w autobusach aktualnie użytkowanych, a następnie być przenoszona do autobusów nowych. Wykonawca musi przewidzieć i zaplanować takie sytuacje na podstawie załączników nr 2 i nr 5 do OPZ.

5. Wykonawca przygotuje szczegółowy harmonogram wdrażania Systemu w ramach projektu Systemu. Może on zaproponować inne etapowanie prac lub

168

nawet podzielić projektowanie Systemu na podetapy np. związane z poszczególnymi podsystemami. Zmiana etapowania wymagać będzie zgody Zamawiającego. Wykonawca musi jednak zachować najistotniejsze terminy wykonania Systemu:1) projekt Systemu etapu musi być oddany do 60 dni od podpisania umowy;2) w terminie do 100 dni muszą zostać zainstalowane Tablice DIP w oparciu o

system kiedyprzyjedzie.pl;3) Wykonawca powinien dążyć skrócenia terminu wdrażania Systemu.

Załącznik nr 7 do OPZ. Dokumentacja projektowa i powykonawcza.

1. Dokumentacja projektowa1.1. W ciągu 30 dni po podpisaniu umowy, przed przystąpieniem do prac,

Wykonawca powinien dostarczyć do akceptacji Zamawiającego pierwszą wersję pełnego projektu Systemu, który będzie pokazywał funkcjonowanie Systemu i jego elementów, w tym pełny schemat organizacyjny projektu, z uwzględnieniem postanowień umowy, w tym Załącznika nr 3 do umowy. Projekt będzie zawierał konfigurację Systemu, przypisanie funkcjonalności i ról/uprawnień do pracowników, przepływy danych jak opisane poniżej, propozycje odbiorowych testów funkcjonalnych, akceptacyjnych, wydajnościowych i bezpieczeństwa, w szczególności:1) opis ogólny – ogólne czynniki wpływające na Oprogramowanie i jego

wymagania, tło wymagań,2) interfejsy użytkownika – wszystkie interfejsy udostępnione użytkownikom

końcowym w połączniu z funkcjonalnością w sposób szczegółowy,

3) interfejsy Systemu – kształt Systemu oraz komponenty wchodzące w jego skład. W sposób szczegółowy muszą być opisane protokoły autorskie tj. nie będące protokołami standardowymi/otwartymi, w tym zmodyfikowane protokoły standardowe/otwarte:a) interfejsy sprzętowe – praca Oprogramowania z konkretnym

Urządzeniem,b) interfejsy programowe – opis dodatkowych interfejsów zewnętrznych, z

których Oprogramowanie musi korzystać,c) interfejsy komunikacyjne – interfejsy i protokoły z jakich muszą

korzystać poszczególne elementy Oprogramowania i/lub Urządzeń do komunikowania się między sobą,

4) struktury danych i diagramy przepływu danych,5) ograniczenia pamięci – ile pamięci, zwłaszcza RAM, będą potrzebować

poszczególne elementy Systemu,6) opis definiujący poziom umiejętności użytkowników przy wykorzystywaniu

poszczególnych części programu, funkcje Oprogramowania wykonywane automatycznie oraz do jakich czynności wymagana będzie interwencja użytkownika,

169

7) funkcje produktu – definiuje podstawowe funkcje produktu, czyli co Oprogramowanie powinno zapewniać użytkownikowi,

8) charakterystyki użytkowników - krótki opis typowych użytkowników Systemu,

9) ograniczenia – krótki opis ograniczeń narzuconych na Oprogramowanie,10) założenia i zależności – opis założeń, jakie przyjmuje się wdrażając

Oprogramowanie oraz wynikających z nich jego zależności od innych systemów,

11) podzbiory wymagań – grupy funkcjonalne,12) opis wymagań – szczegółowy opis wymagań systemowych, w stopniu

pozwalającym przetestować funkcjonalności,13) funkcjonalność – szczegółowo opisane poszczególne funkcjonalności

Systemu.

1.2. Dokumentację projektową konstrukcji wsporczych Tablic DIP i ich posadowienia oraz posadowienia Biletomatów stacjonarnych należy przygotować zgodnie z wymaganiami opisanymi w OPZ pkt. V.3.6. Projektowanie i montaż konstrukcji wsporczej i Tablic DIP.Wykonawca odpowiada za uzyskanie odpowiednich uzgodnień i zezwoleń, prawidłowe posadowienie i zabezpieczenie Biletomatów stacjonarnych, wykonanie przyłączy energii elektrycznej według projektów posiadanych przez Zamawiającego i uruchomienie Biletomatów. Wykonawca opracuje geodezyjną inwentaryzację powykonawczą oraz techniczną dokumentację powykonawczą.

2. Dokumentacja powykonawczaPo zakończeniu każdego Etapu określonego w Harmonogramie, w terminie 30 dni od jego zakończenia, Wykonawca zobowiązany jest do dostarczenia dokumentacji powykonawczej, zgodnie z terminem wskazanym w Harmonogramie, który ma to uwzględniać. Przez dokumentację Systemu należy rozumieć wszystkie materiały pisemne dostarczone Zamawiającemu przez Wykonawcę, niezbędne do dokonania oceny poprawności działania Systemu oraz jego prawidłowego utrzymania i użytkowania (w tym możliwość podłączania do Systemu nowych urządzeń np. kasowniki, urządzenia kontrolerskie, Biletomaty, itp. odpowiadające działającym w Systemie) oraz do szkolenia użytkowników.

2.1. Wymagania ogólneZamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji umowy charakteryzowały się wysoką jakością, tj. by posiadały:1) czytelny i logiczny podział dokumentu na rozdziały, podrozdziały i sekcje,2) spójną strukturę i formę tekstu poszczególnych dokumentów oraz

fragmentów tego samego dokumentu,3) kompletność opisu rozumianą jako pełne, bez wyraźnych braków

przedstawienie rozpatrywanego zagadnienia,4) zgodność (brak logicznych sprzeczności) informacji zawartych w

pojedynczym dokumencie oraz we wszystkich przekazanych dokumentach,

5) w przypadku wprowadzania zmian w Systemie w trakcie jego użytkowania w okresie gwarancyjnym, Wykonawca wprowadzi odpowiednie zmiany w dokumentacji powykonawczej. Poprawki powinny być wprowadzane w postaci tekstu jednolitego z wykazem zmian.

170

2.2. Zakres dokumentacji powykonawczejDokumentacja powykonawcza powinna być dostarczona w 3 kompletach, w postaci wydruku oraz w postaci cyfrowej (np. na nośniku CD lub DVD) w formacie ogólnodostępnym (np. PDF). Dokumentacja powinna zostać dostarczona w języku polskim. W skład dokumentacji powykonawczej powinny wejść co najmniej następujące elementy:1) specyfikacja techniczna dostarczonych elementów Systemu,2) projekt powykonawczy Systemu, będący rozszerzeniem lub aktualizacją

projektu Systemu, o stopniu szczegółowości co najmniej takim, jak w projekcie Systemu, zawierający uzgodnione w trakcie wdrożenia modyfikacje i korekty,

3) dokumentacja użytkownika,4) opis procedur eksploatacyjnych,5) opis procedur serwisowych i wykaz materiałów eksploatacyjnych,6) protokoły testów odbioru,7) dokumentacja szkoleniowa,8) dokumentacja powykonawcza dotycząca przyłączy energii elektrycznej,

konstrukcji i posadowienia Tablic DIP i Biletomatów stacjonarnych zgodnie z wymaganiami OPZ w pkt.V.3.6. Projektowanie i montaż konstrukcji wsporczej i Tablic DIP.

Dokumentacja powinna być aktualizowana przez Wykonawcę przez cały okres eksploatacji Systemu przez Zamawiającego. Aktualizacja dokumentacji powinna zawierać wszelkie zmiany Systemu i być dostarczana nie rzadziej niż raz na kwartał.

3. Specyfikacja technicznaSpecyfikacja techniczna dostarczonych elementów Systemu w ramach realizacji danego Etapu wdrożenia zawiera (jeżeli dotyczy):

1) zestawienie danych inwentarzowych Urządzeń (rodzaje i numery seryjne urządzeń, cechy charakterystyczne, np.: ilość i rodzaj pamięci w urządzeniu);

2) wykaz Oprogramowania wraz z rodzajem, ilością i warunkami licencjonowania (rodzaje i numery seryjne Modułów, licencji, wersje Oprogramowania);

3) konfiguracje urządzeń sieciowych;4) konfiguracje Modułów Pokładowych Systemów, w tym protokołów

komunikacyjnych zewnętrznych i pomiędzy poszczególnymi Modułami Pokładowymi Systemu;

5) konfiguracje systemów i podsystemów,6) konfiguracje Podsystemu e-biletu oraz mapę aplikacji karty e-bilet.

Wykonawca przekaże Zamawiającemu mapę karty – rozumianą jako strukturę logiczną aplikacji i sektorów na Karcie e-biletu (wraz z wszelkimi kodami, kluczami dostępu, kodem źródłowym aplikacji stosowanych na Karcie e-biletu, z wszelkimi poziomami zabezpieczeń),. Wykonawca opracuje i przekaże Zamawiającemu procedury zabezpieczające Kartę e-biletu, w tym programowania komponentów mających wpływ na bezpieczeństwo Systemu (np. kart SAM) i Urządzeń stosowanych do programowania i odczytywania Karty e-biletu (np. UD w POS). Założenia Systemu w zakresie zastosowanych Kart e-biletu nie mogą ograniczać Zamawiającego, tj. Zamawiający musi mieć możliwość zakupu

171

Kart e-bilet na wolnym rynku, samodzielnego ich zaprogramowania i włączenia do Systemu,

7) opis użytych bibliotek (funkcji, parametrów),8) opis techniczny zastosowanych protokołów komunikacji,9) rysunki schematyczne instalacji okablowania oraz ich schematy

elektryczne.

4. Kody źródłowe.4.1. Wykonawca zdeponuje kody źródłowe dostarczonego dla całego

Oprogramowania Dedykowanego (tj. nie obejmują Oprogramowania Standardowego) Systemu, w ustalonej z Zamawiającym instytucji na warunkach określonych poniżej. Kody źródłowe muszą być kompletne, udokumentowane w sposób pozwalający specjalistom z dziedziny informatyki i inżynierii Oprogramowania na ich zrozumienie i modyfikację bez utrudnień oraz gotowe do utworzenia Oprogramowania wynikowego w pełni funkcjonalnego.

4.2. Wykonawca pisemnie udokumentuje Zamawiającemu fakt zdeponowania kodów źródłowych na warunkach określonych w niniejszym Załączniku i przekaże Zamawiającemu dokument uprawniający Zamawiającego do uzyskania dostępu do kodów w okolicznościach przewidzianych w pkt. 4.7.

4.3.Okres zdeponowania kodów źródłowych:1) początek złożenia depozytu: nie później niż 30 dni od dnia podpisania

Protokołu Odbioru Zadania, 2) koniec depozytu: zakończenie okresu gwarancji Systemu.

4.4.Koszt zdeponowania kodów źródłowych i ich aktualizacji pokrywa Wykonawca w ramach wynagrodzenia, o którym mowa w § 6 ust. 1 umowy. Wykonawcy nie przysługuje odrębne wynagrodzenie za depozyt i aktualizację kodów źródłowych. 

4.5.Przez cały okres gwarancji Wykonawca zobowiązany jest do aktualizacji kodów źródłowych. Aktualizacja będzie wykonywana w następujących terminach: 1) w ciągu maksymalnie 30 dni po każdej funkcjonalnej zmianie

Oprogramowania lub przy korekcie błędów, 2) minimum raz na 3 miesiące, w przypadku innych zmian.

4.6.Zamawiający ma prawo uzyskania dostępu do kodów źródłowych wyłącznie w przypadkach: 1) ogłoszenia likwidacji lub upadłości Wykonawcy, 2) zaniechania wykonywania przez Wykonawcę serwisowania, usuwania

awarii i usterek lub utrzymania Systemu, 3) odmowy wykonania Usług Rozwoju zgłoszonych w Zapotrzebowaniu przez

Zamawiającego i zgodnych z przeznaczeniem Systemu,

4) odmowy wykonania integracji Systemu z innymi systemami Zamawiającego lub Operatora,

5) braku dostosowywania Systemu do wymogów prawa, 6) odmowy wykonywania usług serwisu w kolejnych okresach użytkowania

Systemu przez Zamawiającego,

172

7) odstąpienia Zamawiającego od umowy z przyczyn leżących po stronie Wykonawcy,

8) żądania zawyżonych, nieuzasadnionych faktycznymi kosztami i nierynkowych opłat za wykonywanie usług serwisowania, usuwania awarii i usterek, modyfikacji, rozwoju, dostosowywania do wymogów prawa Systemu.

4.7.Kody źródłowe wydane zostaną Zamawiającemu na jego wniosek zawierający oświadczenie o zaistnieniu przesłanki wskazanej w pkt. 4.7. 

4.8.Wycofanie depozytu przed upływem okresu, na jaki został ustanowiony może nastąpić na zgodny wniosek Wykonawcy i Zamawiającego, z zastrzeżeniem pkt. 4.7. 

4.9.Zamawiający po uzyskaniu dostępu do kodów źródłowych ma prawo do rozbudowy, modyfikacji, usuwania wad, dostosowania do powszechnie obowiązującego prawa oraz może je przekazywać osobom trzecim lub podmiotom trzecim na ww. potrzeby. Wykonawcy nie przysługuje odrębne wynagrodzenie z tego tytułu. 

5. Dokumentacja użytkownika Dokument powinien w przystępny sposób pokazywać, jak użytkownik ma posłużyć się aplikacjami, aby obsłużyć wszystkie procesy, jakie System może realizować. Dokumentacja powinna uwzględniać specyfikę Systemu, w tym, podział na podstawowe grupy funkcjonalności (m.in. e-bilet, informacja pasażerska i zarządzanie flotą pojazdów, projektowanie rozkładów jazdy). W szczególności dokumentacja powinna zawierać część analityczno-projektową przeznaczoną dla administratorów i programistów. Minimalna zawartość dokumentacji dla użytkownika powinna obejmować:1) instrukcję rozpoczęcia, zawieszania i zakończenia pracy w Systemie, z

uwzględnieniem specyfiki Systemu i jego podstawowych funkcjonalności: e-biletu i informacji pasażerskiej oraz zarzadzania flotą pojazdów,

2) instrukcje stanowiskowe administratora,3) instrukcje użytkownika dla wszystkich stanowisk (tak skonstruowane, by

nowy pracownik mógł samodzielnie nauczyć się sprawnej obsługi Systemu),4) szczegółowy opis funkcjonalności Systemu,5) dokładny opis raportów generowanych w Systemie. Opis powinien zawierać

informacje dotyczące parametryzacji, filtrowania i innych elementów personalizacyjnych dostępnych dla użytkownika oraz proces eksportowania raportów do narzędzi zewnętrznych,

6) opis komunikatów błędu wraz z podaniem rozwiązań,7) przedstawienie systemu pomocy.

6. Opis procedur eksploatacyjnych i instrukcje obsługi.Procedury eksploatacyjne muszą zawierać co najmniej: 1) nazwę procedury, 2) rodzaj procedury, 3) datę utworzenia i zatwierdzenia oraz numer wersji procedury, 4) cel i zakres procedury, 5) warunki uruchomienia procedury i oczekiwany rezultat jej wykonania, 6) dane osób, które opracowały sprawdziły, zaakceptowały i zatwierdziły

procedurę,

173

7) działania, które należy wykonać jedno po drugim, aby osiągnąć postawiony cel, w tym informacje o osobie (zgodnie z zaproponowanymi rolami), która powinna wykonać dane czynności.

Ponadto Wykonawca powinien przygotować szczegółowy opis m.in. następujących procedur: 1) zarządzania uprawnieniami do systemów zarządzania i urządzeń sieciowych, 2) wykonywania kopii zapasowych konfiguracji urządzeń sieciowych i

systemów zarządzania, 3) odtwarzania konfiguracji urządzeń sieciowych i systemów zarządzania po

awarii, 4) postępowania w sytuacjach awaryjnych,5) postępowania w sytuacjach naruszenia bezpieczeństwa systemów

zarządzania i urządzeń sieciowych, 6) bieżącej eksploatacji Systemu.

7. Opis procedur awaryjnychWykonawca przygotuje (w trakcie realizacji Zadania) procedury działania na okoliczność awarii Systemu i Urządzeń, a w szczególności:

7.1. Systemu informatycznego, w tym:1) serwerów Systemu,2) transmisji danych na potrzeby Karty e-biletu,3) Urządzeń w autobusach,4) pozostałych Urządzeń do obsługi Karty e-biletu,5) transmisji danych na potrzeby POK i POS,6) transmisji danych Podsystemu DIP.

7.2. Procedury awaryjne muszą zostać zaakceptowane przez Zamawiającego.

7.3. Opracowane procedury mają być zaimplementowane w systemie informatycznym, z możliwością ich konfiguracji, a także harmonogramu ich wykonania. System ma posiadać Moduł wielotorowego powiadamiania o Awariach (komunikaty na ekranach, maile, SMS).

7.4. Procedury awaryjne mają obejmować m.in.:1) komu zgłosić Awarię,2) postępowanie w okresie oczekiwania na reakcję serwisu,3) osoby kontaktowe, koordynatorów dla danego typu Awarii,4) ewentualne rekonfiguracje sprzętu, systemu w celu zapewnienia

właściwego dalszego działania Systemu.

8. Procedury serwisowe i wykaz materiałów eksploatacyjnychProcedury serwisowe muszą zawierać wszystkie elementy procedur eksploatacyjnych oraz dodatkowo co najmniej:1) częstotliwość dokonywania przeglądów,2) zakres przeglądów serwisowych,3) listę materiałów eksploatacyjnych koniecznych do wymiany w trakcie

eksploatacji Systemu. Wykaz ten nie jest równoznaczny z podjęciem się przez Wykonawcę jakichkolwiek dodatkowych obowiązków, np. dostawy tych elementów czy wykonywania usług, za wyjątkiem tych elementów, które są w sposób jawny częścią oferty. Wskazywane materiały eksploatacyjne muszą być typowe, powszechnie dostępne i nie mogą być dostarczane wyłącznie przez Wykonawcę.

174

9. Testy Systemu i protokoły testów.Protokoły testów odbioru, w tym testów funkcjonalnych, akceptacyjnych, wydajnościowych i bezpieczeństwa muszą potwierdzać spełnienie wszystkich warunków i założeń określonych w specyfikacji technicznej, a ponadto ich wyniki powinny być zgodne z oczekiwanymi oraz zgodne z najlepszymi praktykami projektowania i konfiguracji systemów informatycznych wspomagających zarządzanie.

9.1. Procedury testowania oraz procedury odbioru ilościowego i jakościowego obejmują: 1) testy akceptujące instalację Urządzeń i Oprogramowania. Po przyjęciu

ilościowym Urządzeń i Oprogramowania Wykonawca sprawdzi w obecności przedstawicieli Zamawiającego poprawność pracy Urządzeń i Oprogramowania,

2) testy akceptacyjne Urządzeń i Oprogramowania zostaną przeprowadzone w celu: a) sprawdzenia zgodności dostarczonych Urządzeń i Oprogramowania z

ofertą Wykonawcy, b) sprawdzenia czy Urządzenia i Oprogramowanie spełniają wymagania

określone przez Zamawiającego w specyfikacji wymagań,c) sprawdzenie wydajności i stabilności systemu pod dużym obciążeniem, d) sporządzenia protokołu odbioru ilościowego i jakościowego,

3) testy powdrożeniowe obejmujące sprawdzenie poprawności działania wdrożonego środowiska Oprogramowania i sprzętu (m.in. testy awarii urządzeń, testy bezpieczeństwa),

4) testy fizyczne, w minimalnym zakresie przeprowadzenia:a) przełączanie się klastrów wirtualnych systemów,b) przełączanie się klastrów baz danych,c) przełączanie się wszystkich redundantnych połączeń sieciowych,d) przełączanie się zasilaczy awaryjnych w Serwerowni,e) jakość i wydajność połączeń w obrębie wszystkich urządzeń Serwerowni,f) wydajność obliczeniowa fizycznych serwerów Systemu w obrębie

Serwerowni,g) wydajność obliczeniowa wirtualnych systemów oraz baz danych w obrębie

Serwerowni,5) testy logiczne, w minimalnym zakresie przeprowadzenia:

a) poprawność komunikacji pomiędzy Systemem Centralnym, a wybranymi elementami Systemu, w tym:o Tablicami DIP,o Autokomputerami i Sterownikami Podsystemu e-bilet,o Biletomatami stacjonarnymi i mobilnymi,o komputerami,o urządzeniami kontrolerskimi,

b) poprawność wykonywanych operacji dostępnych dla poszczególnych kanałów Podsystemu e-bilet (online i offline – jeżeli dostępne), w tym:o POK,o POS,o portal WWW (POP),o Biletomatami stacjonarnymi i mobilnymi,

c) poprawność działania algorytmów predykcji czasu dla Podsystemu DIP,

175

d) poprawność eksportu/importu danych do i z Systemów Dziedzinowych, w tym:o Systemu Finansowo-Księgowego Operatora,o Stacji Paliw,o serwera www (w tym wyszukiwarki, Podsystemu DIP, panelu klienta),o programu windykacyjnego.

Propozycje testów Wykonawca przedstawi po zaakceptowaniu przez Zamawiającego projektu Systemu. Zamawiający może zmodyfikować propozycję Wykonawcy. Zamawiający zastrzega sobie prawo do przeprowadzenia własnych testów lub powtórzenia procedur dostarczonych przez Wykonawcę.

9.2. Protokół testów odbioru musi zawierać:1) identyfikator raportu, datę sporządzenia, rodzaj i przedmiot testów,2) dane osób, które opracowały, sprawdziły, zaakceptowały i zatwierdziły

daną procedurę oraz osób biorących udział w testach i odpowiadających za zgodność działań z procedurą,

3) wykaz testowanych Urządzeń lub modułów Oprogramowania wraz z numerami seryjnymi,

4) opis wykonanej procedury testowania,5) uzyskane wyniki testów (np. wydajności i stabilności Systemu pod dużym

obciążeniem, zgodności dostarczonych Urządzeń i Oprogramowania z ofertą Wykonawcy),

6) ewentualne protokoły odbioru ilościowego i jakościowego Urządzeń i Oprogramowania.

10. Dokumentacja szkoleniowa zawiera:1) instrukcje stanowiskowe administratora,2) instrukcje użytkownika dla wszystkich stanowisk,3) listę przeprowadzonych szkoleń (nazwa, czas i miejsce szkolenia),4) wykaz osób uczestniczących w każdym szkoleniu,5) oceny z testów otrzymane przez poszczególne osoby uczestniczące w

szkoleniu,6) wykaz osób, które uzyskały certyfikat z uprawnieniami do obsługi Systemu.

11. Dokumentacja dotycząca danych osobowychInformacje dotyczące przetwarzanych danych osobowych powinny zostać zebrane w osobnym dokumencie poświęconemu temu zagadnieniu.Dokument powinien zawierać elementy odnoszące się do przetwarzania, w tym przechowywania danych osobowych (tzw. zwykłych bądź wrażliwych) przy założeniu, że zastosowano środki bezpieczeństwa na poziomie wysokim, określonym zgodnie z definicją określoną w Rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz. U. Nr 100, poz. 1024 z późn. zm.), zwanym dalej Rozporządzeniem.W przypadku przetwarzania w Systemie danych osobowych wymagane jest opisanie następujących elementów określonych w Rozporządzeniu, a w szczególności:

11.1. Infrastruktura – wykaz lokalizacji tworzących obszar, w których przetwarzane są dane osobowe (wykaz budynków, pomieszczeń lokalizacji serwerów i stacji roboczych). Wykorzystywane Urządzenia powinny zostać

176

opisane jako: nazwa systemu wraz z nazwą serwera, adresem IP, wskazaniem systemu operacyjnego, Oprogramowania.

11.2. Zakres przechowywania danych osobowych – wykaz zbiorów danych osobowych wraz ze wskazaniem programów zastosowanych do przetwarzania tych danych.

11.3. Struktura zbiorów danych i ich powiązania – opis struktury zbiorów danych wraz ze schematem wskazującym zawartość poszczególnych pól informacyjnych i powiązania między nimi. Minimalny zakres powinien zawierać:1) schemat bazy danych,2) nazwy tabel,3) nazwy pól,4) właściwości pól,5) opisane klucze główne i/lub obce.

11.4. Przepływ danych – logiczna interpretacja danych, jak również sposób przepływu danych pomiędzy poszczególnymi systemami i/lub podsystemami (wraz z dołączeniem diagramu przepływu danych).

11.5. Opis dostarczonych rozwiązań technicznych oraz organizacyjnych zapewniających poufność, integralność i rozliczalność przetwarzanych danych z uwzględnieniem:

1) opis źródła wprowadzenia danych - opis zawierający implementację realizacji przez system automatycznego zapisywania zatwierdzonych w Systemie danych (wraz ze wskazaniem miejsca przechowywania informacji w Systemie), w tym:a) datę pierwszego wprowadzenia danych do Systemu oraz kolejnych dat ich

modyfikacji,b) identyfikator użytkownika wprowadzającego oraz modyfikującego dane,c) informacje audytowe zawierające historię poszczególnych wartości

zmodyfikowanych z jednoznacznym przypisaniem ich do identyfikatora użytkownika przeprowadzającego modyfikacje w Systemie,

d) podanie źródła danych, jeżeli przetwarzane dane nie zostały pozyskane od osoby, której dotyczą,

e) informacji o odbiorcach, w rozumieniu art. 7 pkt 6 z dnia 29 sierpnia 1997 r. ustawy o ochronie danych osobowych, którym dane osobowe zostały udostępnione, dacie i zakresie tego udostępnienia,

f) informacji dotyczącej sprzeciwu przetwarzania danych osobowych przez osobę której dane te dotyczą,

g) opis zawierający dostęp do funkcjonalności umożliwiającej sporządzenie raportu i jego wydruk w zakresie powyższych informacji;

2) opisu zawierającego mechanizm logowania do Systemu i przechowywania historii logowań do Systemu zawierający wskazanie miejsca przechowywania informacji dotyczących:a) datę próby logowania do Systemu razem z informacją o udanym lub nie

procesie logowania przez użytkownika,b) identyfikatora użytkownika,c) adresu IP urządzenia, z którego nastąpiło zalogowanie lub próba

logowania,

177

d) opisu zawierającego dostęp do funkcjonalności umożliwiającej sporządzenie raportu i jego wydruku w zakresie powyższych informacji;

3) wykazu uprawnień – ról, profili dających dostęp do danych osobowych lub wrażliwych z wyszczególnieniem praw dostępowych do danych (odczyt, zapis, modyfikacja), opis zawierający dostęp do funkcjonalności umożliwiającej sporządzenie raportu i jego wydruk na poziomie poszczególnych użytkowników;

4) zapisu potwierdzającego implementację w Systemie automatycznego mechanizmu wymuszającego zmianę hasła użytkownika co 30 dni;

5) opisu zawierającego dostęp do funkcjonalności umożliwiającej sporządzenie raportu i jego wydruk w zakresie informacji wskazanych w podpunktach a, b oraz c (w przypadku podpunktu c umożliwiający wygenerowanie raportu na poziomie poszczególnych użytkowników).

11.6. Opis zastosowanych metod i środków uwierzytelniania.

11.7. Opis elementów programowych i sprzętowych zabezpieczający system informatyczny przed działaniem szkodliwego oprogramowania oraz oprogramowania, którego celem jest uzyskanie nieuprawnionego dostępu do Systemu.

11.8. Opis zabezpieczeń chroniących przed utratą danych spowodowaną awarią zasilania lub zakłóceniami w sieci zasilającej.

11.9. Opis zawierający wyszczególnienie realizacji pozostałych wymogów odnoszących się do środków technicznych i organizacyjnych określonych w Załączniku do Rozporządzenia dla poziomu bezpieczeństwa zdefiniowanym na poziomie wysokim.

11.10. Dokument powinien zawierać odwołania do instrukcji użytkownika oraz procedur eksploatacyjnych zwierających informacje o:1) procedurze i instrukcji rozpoczęcia, zawieszania i zamykania pracy w

Systemie,2) procedurze tworzenia kopii zapasowych zbiorów danych oraz

programów i narzędzi programowych służących do ich przetwarzania,3) sposobie, miejscu i okresie przechowywania nośników informacji

zawierających dane osobowe oraz kopie zapasowe określone w podpunkcie b),

4) procedurze wykonywania przeglądów i konserwacji systemów oraz nośników informacji służących do przetwarzania danych osobowych.

12. Wymagania dodatkoweZamawiający ma w szczególności prawo:1) udostępnić dokumentację wymienioną pkt. 2. Dokumentacja powykonawcza,

w sieci wewnętrznej Zamawiającego, na stanowiskach związanych z użytkowaniem Systemu,

2) utrwalić lub zwielokrotnić dokumentację wymienioną w pkt. 2 Dokumentacja powykonawcza, w dowolnej technice (m.in. drukarskiej, reprograficznej, zapisu magnetycznego, cyfrowej) dla własnych potrzeb w celach związanych z umową,

178

3) udostępnić dokumentację, wymienioną w pkt. 2. Dokumentacja powykonawcza innym podmiotom, w zakresie niezbędnym dla prawidłowego przebiegu postępowań o udzielenie zamówienia publicznego, a także w przypadku konieczności zapewnienia integracji Systemu z innymi systemami informatycznymi,

4) Wykonawca zezwala Zamawiającemu na wykonywanie wszelkich praw zależnych do dokumentacji wymienionej w pkt. 2. Dokumentacja powykonawcza oraz na wprowadzanie w niej zmian koniecznych ze względów technicznych.

179