SYSTEM BILET METROPOLITALNY

Wielkość: px
Rozpocząć pokaz od strony:

Download "SYSTEM BILET METROPOLITALNY"

Transkrypt

1 ZAŁOŻENIA DO OPISU PRZEDMIOTU ZAMÓWIENIA SYSTEM BILET METROPOLITALNY DLA BYDGOSKO TORUŃSKIEGO OBSZARU METROPOLITALNEGO

2 Spis treści Spis treści Wstęp Główne założenia i wymagania dla Systemu Bilet Metropolitalny Organizatorzy transportu objęci integracją taryfową Systemy transportowe, które muszą funkcjonować w SBM Model oferty taryfowej Definicje Architektura logiczna systemu Bazy Danych Bazy urządzeń i pojazdów Zarządzanie biletami Zarządzane strefami Mapa Karty elektroniczne charakterystyka i funkcjonalność Zarządzanie kartami Kalendarz Przystanki Programowanie kasowników w pojazdach komunikacji miejskiej Programowanie terminala konduktorskiego Raporty Kontrola biletów Serwis Internetowy Aplikacja isbm dla urządzeń mobilnych Generator danych dla systemów obcych Administracja systemem

3 Struktura systemu SBM Administracja systemem rozliczeń Wyposażenie techniczne oraz funkcjonalność urządzeń Analiza przemieszczeń podróżnych Serwis, utrzymanie systemu i świadczenie gwarancji Wstępny wykaz punktów lokalizacyjnych do posadowienia stacjonarnych automatów biletowych Wykaz dostarczanego i instalowanego wyposażenia oraz oprogramowania wraz z wykazem wyposażenia do niezbędnego dostosowania w ramach wdrażanego systemu Streszczenie Spis rysunków Spis tabel

4 1. Wstęp. Przedmiotem niniejszego opracowania jest projekt systemu biletu metropolitalnego dla Bydgosko- Toruńskiego Obszaru Metropolitalnego. Integracja polegać ma na wprowadzeniu oferty taryfowej umożliwiającej podróżowanie na całym obszarze B-TOM w ramach jednolitych zasad taryfowych i z wykorzystaniem wspólnego biletu. Ma to na celu zwiększenie atrakcyjności systemu transportowego funkcjonującego na obszarze B-TOM poprzez: uproszczenie (poprzez zintegrowanie) systemu taryfowego, zwiększenie potoków pasażerskich w transporcie zbiorowym jako alternatywy dla zatłoczenia komunikacyjnego, optymalizację kosztów utrzymania systemu taryfowego poprzez jego ujednolicenie i nie dublowanie w różnych systemach transportowych, optymalizację kosztów funkcjonowania transportu poprzez wykorzystanie wszystkich dostępnych środków i systemów transportowych (także komercyjnych) do zaspokajania potrzeb przewozowych. Zadanie to jest bardzo złożone gdyż jego rozwiązanie musi uwzględniać szereg uwarunkowań, z których najważniejsze to: funkcjonowania na obszarze B-TOM wielu organizatorów transportu, funkcjonowanie na obszarze B-TOM wielu operatorów i przewoźników realizujących przewozy w ramach różnych zasad (umowy przewozowe z wykorzystaniem własnego taboru, umowy przewozowe z wykorzystaniem taboru zamawiającego, powierzenie usługi podmiotowi wewnętrznemu, możliwość powołanie spółki celowej, usługa komercyjna z honorowaniem taryfy B-TOM, itd.) obowiązywanie na obszarze B-TOM obok taryfy zintegrowanej także niezależnych systemów taryfowych, funkcjonowanie porozumień międzygminnych, finansowanie transportu z wielu źródeł, rozdział wpływów z biletów do poszczególnych jednostek finansujących transport, dystrybucję biletów, rozszerzenie Biletu Metropolitalnego do Karty Metropolitalnej, jak i Karty Miejskiej, możliwość współpracy z systemem BKM (Bydgoska Karta Miejska) zagadnienia techniczne. Powyższe zagadnienia sugerują, że przyjęte rozwiązania projektowe muszą być na tyle funkcjonalne i otwarte aby umożliwiały funkcjonowanie systemu niezależnie od zmian w strukturach organizacyjnych odpowiedzialnych za funkcjonowanie transportu na obszarze B-TOM. Muszą być niezależne od liczby i charakteru jednostek będących członkami związku czy stronami porozumień (Marszałek, Prezydenci, Starostowie i Wójtowie). Muszą uwzględniać możliwość dystrybucji biletów na całym obszarze B-TOM i kwestie rozliczeniowe w sposób systemowy. Takie podejście nie wyklucza oczywiście możliwości prowadzenia niektórych działań, np. polityki rozliczeniowej, w sposób 4

5 uproszczony, tzn. na zasadzie porozumienia się, tym niemniej system powinien dostarczyć kompletu danych aby rozliczanie się pomiędzy członkami związku czy stronami porozumienia mogło być oparte o rzeczywiście wygenerowane wpływy z biletów przez poszczególne systemy transportowe, na których obowiązywać będzie wspólna taryfa. 5

6 2. Główne założenia i wymagania dla Systemu Bilet Metropolitalny Niniejsze założenia są zgodnie z założeniami opracowanymi przez Partnerów projektu Obszar objęty integracją taryfową. System Bilet Metropolitalny obejmować będzie Komunikację Zbiorową Miast Bydgoszcz i Toruń oraz połączenia kolejowe między tymi miastami realizowane na liniach kolejowych nr 18, 131 oraz 353. Docelowo system musi umożliwiać integrację Komunikacji Zbiorowej na całym obszarze B- TOM, który obejmuje dwa powiaty, pięć miast, dziewiętnaście gmin, z możliwością późniejszego rozszerzenia na obszar całego województwa kujawsko-pomorskiego. Szczegółowe zestawienie wraz z liczbą ludności - Tabela 1, Tabela 2. Tabela 1 Wykaz gmin wraz z liczbą ludności objętych integracją taryfową. Liczba ludności ogółem miasto Wieś pow. gęst. zalud. pow. gęst. zalud. pow. ogółem miasto Wieś Miasto Bydgoszcz Miasto Toruń Gmina m w. Koronowo Gmina w. Białe Błota Gmina w. Dąbrowa Chełmińska Gmina w. Dobrcz Gmina w. Nowa Wieś Wielka Gmina w. Osielsko Gmina w. Sicienko Gmina m w. Solec Kujawski Gmina m. Chełmża Gmina w. Chełmża Gmina w. Czernikowo Gmina w. Lubicz Gmina w. Łubianka Gmina w. Łysomice Gmina w. Obrowo Gmina w. Wielka Nieszawka Gmina w. Zławieś Wielka ,42% 20,58 Powierzchnię podano w km 2, gęstość zaludnienia w osobach/km 2 gęst. zalud. Tabela 2 Gęstość zaludnienia obszaru objętego integracją taryfową. Gęstość zaludnienia Obszar Liczba ludności [osób/km 2 ] [km 2 ] [%] [osób] [%] B-TOM Miasto ,90 % ,42 % Wieś ,10 % ,58% 6

7 2.3. Organizatorzy transportu objęci integracją taryfową. Na obszarze B-TOM funkcjonuje 22 organizatorów transportu. Istnieje jednak wiele konfiguracji zawierania porozumień umożliwiających rozszerzenie kompetencji poszczególnych podmiotów w zakresie organizacji transportu. Zawarcie porozumienia przez wójtów umożliwia im organizowanie linii autobusowych funkcjonujących na obszarze więcej niż jednego powiatu. Rozwiązanie kwestii integracji taryfowej możliwe jest z kolei poprzez stworzenie związku taryfowego lub innej formy porozumienia. SBM musi być zatem nieczuły na struktury organizacyjne funkcjonujące na obszarze B-TOM oraz na ich zmiany. Wdrożenie projektu wymaga ustalenia administratora systemu oraz sposobu finansowania jego pracy. SBM musi natomiast funkcjonować niezależnie od funkcjonujących struktur organizacyjnych. Konstrukcja systemu musi być też taka, że wszyscy organizatorzy transportu funkcjonują i organizują transport wg swoich kompetencji niezależnie natomiast są objęci integracją taryfową. Takie założenie powoduje, że system będzie funkcjonować prawidłowo także przy zmniejszonej liczbie organizatorów na skutek zawarcia porozumień międzygminnych aż do stworzenia jednego organizatora transportu dla całego obszaru B-TOM Systemy transportowe, które muszą funkcjonować w SBM. Podstawowe systemy transportowe, które muszą zostać objęte SBM w momencie uruchomienia systemu, to: System komunikacji kolejowej realizowanej przez marszałka, system komunikacji miejskiej w Bydgoszczy, system komunikacji miejskiej w Toruniu, systemy komunikacji międzygminnej, dla których organizatorami transportu (PTZ) są odpowiednio Bydgoszcz i Toruń, 2.5. Model oferty taryfowej. Rozwiązania projektowe opierają się na założeniu, że oferta taryfowa kształtowana będzie w sposób dowolny. Istnieć będzie niczym nieograniczona możliwość kreowania oferty taryfowej w pełnym spektrum możliwości, tj. od biletów obowiązujących bez żadnych ograniczeń na całym obszarze B-TOM do biletu obowiązującego na dowolnym fragmencie pojedynczej linii w wybranym obszarze B-TOM, w dowolnie określonym przedziale czasowym. Ponadto będzie istnieć możliwość wprowadzenia jednolitych biletów jednorazowych dla całego obszaru B-TOM jak też możliwość utrzymania indywidualnych biletów w poszczególnym obszarach, na przykład w Bydgoszczy i Toruniu niezależnie od wprowadzonych biletów integracyjnych. 7

8 3. Definicje. W niniejszym rozdziale wyjaśniono wyłącznie definicje, które bez wyjaśnień mogłyby budzić wątpliwości co do ich ścisłego znaczenia. Nie wyjaśniano terminów powszechnie stosowanych w zagadnieniach publicznego transportu zbiorowego. System Bilet Metropolitalny (SBM) całość rozwiązań systemowych (informatycznych, infrastrukturalnych, usługowych, itd.) mających na celu obsługę elektronicznych kart bezstykowych oraz biletów papierowych zarówno w zakresie publicznego transportu zbiorowego jak i usług dodatkowych, jak również umożliwiających pozyskiwanie wszelkich danych, umożliwiających prowadzenie rozliczeń, kontrolę, windykację, itd. Bilet Metropolitalny rozwiązanie elektroniczne (karta) i bilet papierowy oraz zakres usług i rozwiązań związanych wyłącznie z korzystaniem ze środków publicznego transportu zbiorowego. Karta Metropolitalna rozwiązanie elektroniczne (karta) oraz zakres usług i rozwiązań związanych z korzystaniem ze środków publicznego transportu zbiorowego i z usług dodatkowych (program rabatowy, wstęp do instytucji kultury, itp.). Welcome Card rozwiązanie elektroniczne (karta) i zakres usług oraz rozwiązań związanych z korzystaniem ze środków publicznego transportu zbiorowego i zdefiniowanego pakietu usług (opcjonalnie do wybor u) jako pakiet płatny z góry. E-bilet okresowy elektroniczny zapis na karcie zbliżeniowej oraz w bazie danych systemu uprawniający zgodnie z obowiązującymi taryfami opłat do korzystania z publicznego transportu zbiorowego organizowanego przez Zamawiającego na terenie działania SBM E portmonetka funkcjonalność pozwalająca na przechowywanie informacji o punktach przejazdowych przypisanych do indywidualnego konta rozliczeniowego. Punkt przejazdowy jednostka rozliczeniowa pozwalająca na bezgotówkowe nabywanie uprawnień do przejazdów środkami publicznego transportu publicznego. Promocja rabat naliczany do wartości biletu, wprowadzany przez Administratora. Główny Administrator właściciel systemu SBM (Zamawiający) lub inny podmiot wyłoniony w odrębnym postępowaniu, posiadający nieograniczony dostęp do pełnej obsługi wszystkich funkcjonalności. Administrator niższego poziomu osoba/y otrzymująca/y uprawnienia dostępu do wybranych funkcjonalności SBM od głównego Administratora. Punkt Obsługi Klienta (POK) miejsce obsługiwane przez Użytkownika gdzie możliwe jest: złożenie wniosku o wydanie karty, odbiór karty, doładowanie karty, sprzedaż biletów papierowych, uzyskanie informacji. Użytkownik każda osoba lub podmiot mającą dostęp do systemu, ale nie mająca uprawnień do edycji lub modyfikacji jakichkolwiek treści. Partner Gmina Miasta Toruń, Miasto Bydgoszcz, Województwo Kujawsko - Pomorskie występujący wspólnie jako Zamawiający. 8

9 Pasażer uczestnik ruchu przemieszczający się transportem publicznym wykonujący jedną jazdę w określonej jednostce czasu, podstawowa jednostka do wymiarowania potoku ruchu pasażerów na linii komunikacyjnej lub sieci transportowej. Osoba uczestnik ruchu przemieszczający się transportem publicznym, wykonujący jedną lub więcej jazd w określonej jednostce czasu, określa liczbę ludności w obszarze/strefie korzystających z transportu publicznego. Jazda (przejazd) przemieszczanie się pasażera z wykorzystaniem jednego środka transportu pomiędzy określonymi początkiem (źródłem) i końcem (celem) podróży. Podróż - przemieszczanie się osoby z wykorzystaniem jednego lub więcej przejazdów środkami transportu pomiędzy określonymi początkiem (źródłem) i końcem (celem) podróży, dla potrzeb analiz przyjęte zostanie, że podróż jest to przemieszczanie się osoby przy wykorzystaniu więcej niż jednego środka transportu publicznego przy określonej granicznej wartości czasu na przesiadkę (maksymalny czas na przesiadkę). Długość jazdy (przejazdu) [km, min., przystanki] odległość między przystankiem komunikacyjnym, na którym dany pasażer wsiadł do środka transportu a przystankiem komunikacyjnym, na którym wysiadł z środka transportu, parametr określony jednostką czasu, długości lub liczbą przystanków. Długość podróży [km, min., przystanki], odległość między przystankiem komunikacyjnym, na którym dany pasażer wsiadł do pierwszego środka transportu a przystankiem komunikacyjnym, na którym wysiadł z ostatniego środka transportu, uwzględnia czas na przesiadkę i długość dojścia między przystankami, parametr określony jednostką czasu, długości lub liczbą przystanków. Praca przewozowa [pasażerokilometrów/dobę, pasażerogodzin/dobę] miara potoku ruchu wyznaczona iloczynem natężenia ruchu i czynnika kosztowego określonego potoku ruchu wykonana w jednostce czasu właściwej dla zastosowanej miary natężenia ruchu. Kolejność (lub brygada) jest to szereg kursów, przeznaczonych do wykonania na danej linii jednym pojazdem, w skali jednego dnia. Zadanie przewozowe jest to połączenie kilku kolejności, na poszczególnych liniach, obsługiwanych przez jeden pojazd w skali dnia. Podział zadań przewozowych w transporcie publicznym udział poszczególnych środków transportu publicznego (kolej, tramwaj, autobus) w przewozach pasażerskich w odniesieniu do obszaru np. metropolitalnego lub wyznaczonych stref [%, pojazdokilometrów, pasażerogodzin, pasażerokilometrów]. Wskaźnik komfortu wskaźnik ten określa ile razy jazda środkiem komunikacji zbiorowej jest bardziej uciążliwa w stosunku do warunków uznanych za akceptowalne: zajęte wszystkie miejsca siedzące, a zapełnienie miejsc stojących wynosi 2,5 pas/m 2 powierzchni pojazdu przeznaczonej do stania (dla takiego przypadku wskaźnik komfortu wynosi w k =1). Klasy (poziomy) komfortu podróży zdefiniowane w zależności od wskaźnika komfortu, wyróżniamy 6 klas komfortu podróży od A do F. Przystanek komunikacyjny miejsce przeznaczone do wsiadania lub wysiadania pasażerów jednej lub kilku linii komunikacyjnych (również w odniesieniu do różnych środków transportu). Węzeł komunikacyjny zespół przystanków komunikacyjnych w obszarze dworca, skrzyżowania, pętli, węzła drogowego lub zintegrowanego węzła przesiadkowego. 9

10 Linia komunikacyjna połączenie komunikacyjne na sieci dróg publicznych, liniach kolejowych i innych szynowych. Trasy komunikacyjne sieci transportowe (drogowe, uliczne, kolejowe i inne szynowe, wodne), po których funkcjonują linie komunikacyjne. Względne napełnienie środka transportu publicznego liczba osób (pasażerów) znajdujących się w danym środku transportu publicznego pomiędzy dwoma sąsiednimi przystankami komunikacyjnymi odniesiona do zdolności przewozowej (pojemności nominalnej)[%, wartość dziesiętna]. Zdolność przewozowa pojemność nominalna pojazdu, wielkość przyjmowana na podstawie danych technicznych pojazdu podawanych przez producenta [pas/pojazd]. Potok pasażerski (natężenie ruchu pasażerów) liczba pasażerów przemieszczających się środkami transportu publicznego między dwoma sąsiednimi przystankami komunikacyjnymi na danej linii, grupie linii lub w przekroju korytarza transportowego (ulicy, drogi) odniesiona do jednostki czasu [pas/h, pas/dobę]. Grupa społeczna podział mieszkańców (użytkowników transportu publicznego) na grupy o różnym przedziale wiekowym (struktura wiekowa społeczeństwa), przyjęto 6 grup wiekowych. USP grupa społeczna składająca się z uczniów szkół podstawowych. USG grupa społeczna składająca się z uczniów szkół gimnazjalnych. USS grupa społeczna składająca się z uczniów szkół średnich. ST grupa społeczna składająca się z studentów. P grupa społeczna składająca się z osób dorosłych nie będących członkami grupy ST, USS i E. E grupa społeczna składająca się z emerytów. VISUM oprogramowanie służące do wykonywania symulacji rozkładów strumieni ruchu dla sieci dróg i układów linii transportu publicznego. Wymagania minimalne ilekroć w projekcie mówi się o wymaganiach minimalnych, rozumie się przez to, że opisane w niniejszym projekcie rozwiązanie musi spełniać wszystkie opisane dla danego rozwiązania wymagania, ale też oznacza, że wykonawca projektu może rozwinąć dane rozwiązanie o dodatkowe funkcjonalności. Przykładowe rozwiązanie ilekroć w projekcie mówi się o przykładowym rozwiązaniu, rozumie się przez to, że rozwiązanie zaproponowane przez wykonawcę projektu może być inne lub podobne pod względem ideowym jednakże musi spełniać ściśle wszystkie funkcjonalności, założenia i wymagania opisane w rozwiązaniu opisanym w projekcie. 10

11 4. Architektura logiczna systemu System powinien być zbudowany w architekturze wielowarstwowej w oparciu o relacyjną bazę danych i język SQL oraz serwer aplikacji. Dostęp do danych zawartych w systemie zrealizować należy w oparciu o technologię WWW a także aplety Java uruchamiane w rożnych trybach lub równoważne, co umożliwi pracę z systemem przy pomocy aktualnych wersji powszechnie używanych przeglądarek internetowych System powinien zapewniać możliwość pracy wielostanowiskowej z wykorzystaniem jednolitego i spójnego środowiska aplikacyjnego System musi posiadać pełną synchronizację przetwarzanych danych przez wydzielone serwery umożliwiającą przejęcie pełnej funkcjonalności systemu przez jeden z nich System musi posiadać interfejs w języku polskim oraz załączony plik pomocy zawierający tematyczną instrukcje obsługi aplikacji także w języku polskim. Zamawiający dopuszcza sytuację, w której specjalizowane oprogramowanie (np. zarządzanie urządzeniami w pojazdach itd.), dostępne wyłącznie dla administratorów lub realizujące bardzo wyspecjalizowane funkcje, będzie realizowane przy użyciu architektury dwuwarstwowej z klasycznym interfejsem Windows, Linux lub równoważnym Zamawiający oczekuje zainstalowania bazy danych zebranych z pojazdów oraz systemu raportowo-analitycznego na odrębnych maszynach wirtualnych. System powinien być skalowalny, tzn. posiadać możliwość rozbudowy ilościowej (np. w zakresie danych słownikowych) i funkcjonalnej systemu Zamawiający wymaga aby architektura logiczna systemu oparta była o integracyjną szynę danych i usług (ESB) z wydzielonym, opisanym rejestrem usług. Komunikacja między modułami systemu może odbywać się tylko i wyłącznie w oparciu i ESB. Zakres wymiany danych oraz rejestry zostaną opisane przez Wykonawcę i przedstawione do akceptacji Zamawiającemu. Opracowana szyna ESB nie może ograniczać żadnych funkcjonalności opisanych w niniejszym dokumencie System powinien umożliwiać wykonanie przez odpowiedniego administratora lub programistę w prosty sposób modyfikacji, a w szczególności dodanie do systemu nowych danych słownikowych, zmiany konfiguracji. Modyfikacje te mają być realizowane bez koniecznego udziału serwisu, firm trzecich itp. Wykonawca dostarczy pełną dokumentację techniczną i użytkową dla administratora w formie papierowej i elektronicznej Komunikacja urządzeń z Systemem Biletu Metropolitalnego będzie odbywała się przez sieć bezprzewodową APN lub w przypadku dostępnej infrastruktury poprzez sieć przewodową WLAN W ramach dostarczonych licencji Wykonawca zapewni, w okresie wsparcia, dostęp do aktualizacji dla: a) systemu użytkowego, b) oprogramowania bazodanowego, c) oprogramowania systemowego, d) oprogramowania wirtualizującego. 11

12 Zakres aktualizacji ma obejmować m.in. poprawki, service-packs, łaty, itp. Nie jest wymagane prawo do aktualizacji bazy danych i systemu operacyjnego do nowszych wersji w przypadku użycia platform o zamkniętym kodzie źródłowym. Strony internetowe wykonane w ramach projektu mają spełniać minimalne wymagania: Strony powinny być przystosowane do wyświetlania w rozdzielczościach co najmniej 1024x768 (lub z automatycznym dostosowaniem do rozdzielczości ekranu) Dostarczony system ma umożliwiać wymianę danych z systemami przeznaczonymi do obsługi komunikacji miejskiej, systemami finansowo księgowymi, systemami ITS będącymi w posiadaniu Zamawiającego. Zamawiający oczekuje dostarczenia systemu wspierającego synchroniczną jak również asynchroniczną wymianę danych w formie komunikatów XML. Wymiana komunikatów XML opierać się będzie o usługi zgodne z WebService. Dostarczony system musi posiadać możliwość podłączenia się bezpośrednio do bazy danych innych systemów za pośrednictwem interfejsu ODBC lub JDBC. Dostarczony system musi być oparty o standard ESB lub równoważny w celu zapewnienia możliwości jego rozbudowy bez udziału firmy dostarczającej to rozwiązanie System powinien umożliwić wymianę danych dla każdego odbicia biletu w kasowniku za pośrednictwem kart zbliżeniowych. Dane dla karty zbliżeniowej: numer boczny autobusu, data, czas (z dokładnością do 1 sekundy), numer karty, typ biletu, check-in/check-out (w przypadku wdrożenia) System powinien umożliwić wymianę danych dla każdej usługi wykonanej za pośrednictwem Systemu Biletu Metropolitalnego. Dane dla każdej transakcji: unikalny numer transakcji, numer karty, typ biletu, typ usługi, liczba biletów, data początkowa ważności biletu, data końcowa ważności biletu, data transakcji, czas transakcji (z dokładnością do 1 sekundy), urządzenie przy pomocy, którego zarejestrowano sprzedaż, użytkownik systemu rejestrujący sprzedaż, cena/wartość System powinien gwarantować autonomiczność w zakresie wdrażania określonych przez Zamawiającego funkcjonalności na wybranym obszarze działania SBM Wykonawca udziela Zamawiającemu licencji bezterminowej każdemu z partnerów na oprogramowanie użytkowe Systemu Biletu Metropolitalnego w zakresie oprogramowania głównego - na serwerze centralnym oraz oprogramowania pozostałych urządzeń wchodzących w skład Systemu. W ramach udzielonej licencji na oprogramowanie Zamawiający ma prawo w szczególności do: a) użytkowania oprogramowania na dowolnej liczbie stanowisk i w dowolnych lokalizacjach, przez dowolną liczbę użytkowników, w tym podmioty współpracujące z Zamawiającym w ramach SBM. Przez użytkowanie oprogramowania rozumie się uruchamianie, wyświetlanie, uzyskiwanie dostępu, drukowanie, wprowadzanie własnych danych, dokonywanie eksportu danych z programu i publiczne odtwarzanie, b) wprowadzania do pamięci komputera oraz utrwalania na nośnikach komputerowych, c) dowolnego dysponowania raportami i wydrukami generowanymi przez oprogramowanie, zarówno w wersji elektronicznej, jak i papierowej, d) tworzenia kopii bezpieczeństwa na nośnikach komputerowych. 12

13 4.14. Wykonawca po zakończeniu wdrożenia nie będzie żądał od Zamawiającego żadnych dodatkowych opłat licencyjnych, wdrożeniowych itp. Licencja na oprogramowanie użytkowe do obsługi całego systemu centralnego będącego przedmiotem zamówienia nie może wprowadzać ograniczeń w stosunku do: a) liczby użytkowników, b) przeniesienia oprogramowani na inny sprzęt, c) liczby obsługującego ją sprzętu, d) liczby uruchomień, e) zakresu czasu w jakim będzie użytkowana Wraz z udzieleniem licencji, Wykonawca dostarczy Zamawiającemu, w formie elektronicznej, instrukcję obsługi oprogramowania użytkowego systemu z podziałem na poszczególne stanowiska utworzone w Systemie. W celu zapewnienia prawidłowej obsługi urządzeń wchodzących w skład Systemu, Zamawiający wymaga także, aby instrukcje stanowiskowe zostały dostarczone również w formie wydruku w ilości odpowiadającej liczbie stanowisk funkcjonujących w Systemie. Wykonawca dostarczy Zamawiającemu co najmniej 5 licencji dostępowych na oprogramowanie systemowe TS CALL (dostępy do serwerów w ramach usługi terminalowej) oraz co najmniej 10 licencji dostępowych dla użytkowników CALL Przykładową architekturę Systemu pokazano na rysunku Rysunek 1. 13

14 STREFA UŻYTKOWNIKA STREFA UŻYTKOWNIKA STREFA OBSŁUGI UŻYTKOWNIKA STREFA OBSŁUGI UŻYTKOWNIKA STREFA ADMINISTRATORA STREFA ADMINISTRATORA BAZA DANYCH DLA CAŁEGO SYSTEMU SERVICE DESK INFORMACJA PRZESTRZENNA Sieć wewnętrzna POWIĄZANIE Z SYSTEMAMI ZEWNĘTRZNYMI OPROGRAMOWANIE SYSTEMU WRAZ Z APLIKACJAMI PORTAL INTERNETOWY I USŁUGI GSM INTERFEJS DO EXCEL BUSMAN SYSTEMY ITS VISUM SYSTEMY FINANSOWO - KSIĘGOWE WINDYKACJA APLIKACJE ZARZĄDZANIE BILETAMI ZARZĄDZANIE STREFAMI MAPA KALENDARZ PRZYSTANKI PROGRAMOWANIE KASOWNIKÓW ANALIZA PRZEMIESZCZEŃ RAPORTY KONTROLA BILETÓW ZARZĄDZANIA KARTAMI FIREWALL - STREFA 1 APLIKACJA DLA USŁUG GSM PORTAL INTERNETOWY DLA KLIENTA Sieć wewnętrzna APLIKACJA DLA ZEWNĘTRZNYCH PUNKTÓW OBSŁUGI UŻYTKOWNIKÓW APLIKACJA DLA POK FIREWALL - STREFA 2 Obsługa transmisji danych GSM APN Sieć zewnętrzna WAN Rysunek 1 Przykładowa architektura systemu. 14

15 5. Bazy Danych Przedstawione w niniejszym rozdziale wymagania stanowią wymagania minimum a przedstawione rozwiązania projektowe mogą być zrealizowane w inny sposób przy zachowaniu wszystkich opisanych tu funkcjonalności System musi umożliwiać przechowywanie wszelkich zebranych, wykorzystywanych w systemie danych. Okres przechowywania poszczególnych grup danych ma być definiowalny przez Administratora Pozyskiwanie przez system SBM danych o rozkładach jazdy musi się odbywać w sposób automatyczny (import danych). System musi automatycznie pozyskiwać dane z systemów służących do budowy rozkładów jazdy, używanych przez Zamawiającego i podmioty z nim współpracujące w ramach SBM Baza danych linie komunikacyjne w Bazach Danych muszą znajdować się wszelkie informacje dotyczące wszystkich linii, systemów i podsystemów transportowych obsługiwanych w ramach SBM, w szczególności: a) wykaz systemów transportowych, b) funkcjonujące w ramach danego systemu transportowego podsystemy (różni przewoźnicy działający w ramach jednego systemu transportowego, linie nocne, podmiejskie, międzygminne, gminne, itd.), c) wszystkie cechy charakterystyczne danego systemu transportowego w systemie musi istnieć możliwość wprowadzenia dowolnej liczby danych i informacji o danej linii, musi istnieć system identyfikacji linii komunikacyjnych o takich samych numerach (na przykład linia tramwajowa nr 1 w Bydgoszczy i linia tramwajowa nr 1 w Toruniu), musi istnieć rozwiązanie, które na podstawie wprowadzenia przez obsługę pojazdu numeru linii w komputerze pojazdowym w sposób jednoznaczny zidentyfikuje linię w Systemie. Oznacza to, że po wprowadzeniu przez obsługę pojazdu w komputerze pojazdowym linii nr 1 w Toruniu, System musi (na podstawie innych zdefiniowanych parametrów, np. numerów identyfikacyjnych komputera pojazdowego obsługującego SBM) wiedzieć, że jest to linia nr 1 w Toruniu a nie w innym mieście, musi istnieć możliwość dowolnego grupowania linii oraz możliwość nadawania nazw grupom. Na przykład grupa Komunikacja Miejska Bydgoszcz, Komunikacja Miejska Toruń, Komunikacja nocna, itd. Celem tej funkcjonalności jest umożliwienie przypisywania poszczególnym rodzajom biletów zakresów obszarowych ich obowiązywania, musi istnieć możliwość grupowania podsystemów w grupy (na przykład zgrupowanie podsystemów linii miejskich obsługiwanych przez różnych przewoźników w jedną grupę Komunikacja Miejska, zgrupowanie linii nocnych funkcjonujących w różnych miastach w grupę linie nocne, itd.), musi istnieć rozwiązanie, które, w przypadku przemieszczenia pojazdu pomiędzy systemami lub podsystemami, pozwoli na przeprogramowanie urządzeń 15

16 pojazdowych tak aby urządzenia pojazdowe mogły w sposób prawidłowy identyfikować bilety, 5.5. Baza danych bilety w systemie musi istnieć baza danych o wszystkich biletach, które obowiązywały od momentu uruchomienia systemu, obowiązują oraz te, które zostały zdefiniowane w systemie i są planowane do wdrożenia, szczegółowy opis wymagań dla bazy danych o biletach opisano w rozdziale Zarządzanie biletami Baza danych usługi dodatkowe w systemie musi istnieć baza danych o wszystkich usługach dodatkowych świadczonych w ramach Karty Metropolitalnej i Welcome Card, w bazie danych o usługach dodatkowych musi istnieć możliwość wprowadzania co najmniej następujących danych: dane teleadresowe usługodawcy, wykaz dokumentów na podstawie których realizowana jest współpraca z Administratorem systemu, raporty o poziomie ilościowym i finansowym świadczonych usług, wykaz urządzeń znajdujących się u usługodawcy, historia wszystkich zmian (zakres usługi, ceny, rabaty, itd. ) wprowadzonych w trakcie realizowania usługi, baza danych o usługach dodatkowych musi spełniać także wymagania opisane w innych rozdziałach tego dokumentu Baza danych Karty w systemie musi istnieć baza danych o wszystkich kartach funkcjonujących w ramach Systemu Bilet Metropolitalny, wydanych zarówno w ramach Biletu Metropolitalnego, Karty Metropolitalnej, Welcome Card, szczegółowy opis wymagań dla bazy danych o kartach opisano w rozdziale Zarządzanie kartami Baza danych Finanse w systemie musi istnieć baza danych o wszystkich przepływach finansowych realizowanych w systemie, w systemie muszą być gromadzone w szczególności następujące dane: a) dane o operacjach wykonanych we wszystkich punktach obsługowych, b) dane o operacjach wykonanych w urządzeniach w pojazdach, c) dane o operacjach wykonanych w biletomatach stacjonarnych i mobilnych, d) dane o operacjach wykonanych we wszystkich punktach usługowych w ramach Karty Metropolitalnej i Welcome Card, 16

17 e) dane o operacjach realizowanych w serwisie internetowym i komórkowym, f) dane generowane niezależnie przez Administratora systemu W bazie danych muszą być przechowywane wszystkie raporty i zestawienia finansowe opisane w tym dokumencie i inne ustalone na etapie wdrożenia SBM W bazie danych muszą być przechowywane wszystkie informacje o przepływach pieniężnych pomiędzy partnerami SBM oraz usługodawcami i Administratorem systemu Baza danych Dane osobowe w systemie musi istnieć baza danych osobowych wszystkich użytkowników systemu, baza danych musi być tak skonstruowana aby spełniała wszystkie wymagania prawne związane z pozyskiwaniem, udostępnieniem, wykorzystaniem i ochroną danych osobowych Dane zgromadzone w systemie pozostają własnością Zamawiającego i nie będą udostępniane podmiotom trzecim bez zgody Zamawiającego Minimalny zakres danych pasażera gromadzonych i przetwarzanych w bazie obejmuje: a) Imię i nazwisko, b) Adres zamieszkania, c) Adres do korespondencji (jeśli jest inny niż adres zamieszkania), d) Numer PESEL, e) Adres poczty elektronicznej, f) Numer telefonu (stacjonarny i/lub mobilny) g) Rodzaj przysługujących ulg wraz z okresem ważności. Brak wpisu daty końca ważności ulgi do bazy danych systemu skutkuje tym, iż uprawnienie to upływa wraz z terminem ważności karty Baza danych Administracja systemem w systemie musi istnieć baza danych zawierająca wykaz osób mających dostęp do systemu na każdym poziomie dostępności wraz z danymi kontaktowymi, zakresem dostępu i uprawnień, okresem dostępu, itd., szczegółowy opis wymagań dla bazy danych o administracji systemem opisano w rozdziale Administracja systemem Baza danych przystanki. 17

18 w systemie musi istnieć baza danych o przystankach zawierająca listę wszystkich przystanków funkcjonujących w systemie, baza danych musi funkcjonować według zasad opisanych w rozdziale Przystanki. 6. Bazy urządzeń i pojazdów W bazie danych urządzeń będą przechowywane informacje o wszelkich urządzeniach funkcjonujących w systemie (komputery pojazdowe, kasowniki, konsole kierowców, stacje bazowe, biletomaty stacjonarne, biletomaty mobilne,, terminale sprzedaży, terminale kontrolerskie, terminale konduktorskie, kioski informacyjne, stanowiska dyspozytorskie, itd.) W bazie urządzeń musi istnieć możliwość przypisywania numerów ewidencyjnych poszczególnym urządzeniom W bazie danych musi istnieć możliwość przypisania lokalizacji poszczególnych urządzeń (zarówno stacjonarnych jak i mobilnych), 6.4. Moduł baza urządzeń musi być powiązany z pozostałymi bazami danych systemu w taki sposób aby istniała możliwość jednoznacznego przypisania urządzeń do poszczególnych systemów transportowych. Ma to na celu rozróżnianie linii o tych samych numerach funkcjonujących w ramach różnych systemów transportowych (na przykład linia nr 1 w Toruniu i linia nr 1 w Bydgoszczy), 6.5. Dopuszcza się wykorzystanie bazy urządzeń do rozwiązania problemu dublowania numerów linii komunikacyjnych objętych systemem Musi istnieć możliwość przypisywania poszczególnym urządzeniom informacji w postaci tekstu i liczb w dowolnej liczbie kolumn. Musi istnieć możliwość dodawania i usuwania kolumn Musi istnieć możliwość przypisywania i kojarzenia wszystkich urządzeń działających w systemie z flotą pojazdów. Musi zatem istnieć możliwość przypisania każdego urządzenia do danego pojazdu Musi istnieć baza pojazdów, do której wprowadzone zostaną wszystkie pojazdy objęte systemem i wyposażone w infrastrukturę techniczną z nim związaną Musi istnieć możliwość zdalnej diagnostyki prawidłowości funkcjonowania poszczególnych urządzeń W przypadku stwierdzenia przez system nieprawidłowości działania któregokolwiek z urządzeń, fakt ten musi być natychmiast wyświetlony na ekranie monitora dyspozytora (także w module Mapa) oraz zarchiwizowany w systemie O nieprawidłowości działania któregokolwiek z urządzeń pojazdowych musi też być niezwłocznie (automatycznie) poinformowana obsługa pojazdu. 18

19 6.12. Baza danych o urządzeniach musi być powiązana z pozostałymi bazami danych systemu w taki sposób aby była możliwość z poziomu bazy danych o urządzeniach generowania raportów o ich pracy (wykonanych operacjach) w strukturze czasowej Musi istnieć narzędzie zawierające procedury postępowania w przypadku awarii urządzenia lub urządzeń. Szczegółowe informacje zawarto w rozdziale Serwis i utrzymanie systemu. 7. Zarządzanie biletami W systemie musi istnieć narzędzie do budowy oferty taryfowej Musi istnieć możliwość tworzenie i utrzymywanie oferty biletowej poprzez wprowadzanie do systemu i usuwanie z systemu poszczególnych rodzajów biletów Musi istnieć możliwość definiowania czasowego i obszarowego zakresu obowiązywania poszczególnych biletów Musi istnieć możliwość modyfikacji zakresu obowiązywania (czasowego i obszarowego) każdego biletu, zarówno przed jak i w trakcie jego obowiązywania Musi istnieć możliwość prowadzenia archiwum oferty taryfowej Musi istnieć możliwość wprowadzenia do ofert dowolnego rodzaju i dowolnej liczby biletów Musi istnieć możliwość określenia następującego zakresu obowiązywania biletów: w zakresie obszarowym: od pojedynczego odcinka trasy pojedynczej linii komunikacyjnej (bilety strefowe) do wszystkich linii włączonych do systemu bez ograniczeń, Oznacza to, że musi istnieć możliwość włączenia do systemu pojedynczego biletu obowiązującego na pojedynczej linii na wybranym odcinku trasy (może tu zostać wykorzystany na przykład system pozycjonowania pojazdów lub baza danych odcinków międzyprzystankowych), poprzez bilet obowiązujący na tylko jednej linii, dalej na kilku liniach, aż do biletu obowiązującego na wszystkich liniach na całym obszarze metropolitalnym w zakresie czasowym: od dowolnie krótkiego czasu obowiązywania biletu do bezterminowej ważności biletu. Oznacza to, że musi istnieć możliwość włączenia do systemu biletu obowiązującego w dowolnie krótkim czasie (definiowanym przez Administratora Systemu), poprzez bilet godzinny, dobowy, kilkudobowy, miesięczny, kwartalny, półroczny, roczny, nieograniczony czasowo, itd Musi istnieć możliwość dodawania i usuwania biletów Musi istnieć możliwość nadawania nazwy poszczególnym biletom. 19

20 7.10. Musi istnieć możliwość przypisania poszczególnym biletom zakresu obowiązywania. Przypisanie zakresu obowiązywania musi się odbywać przy wykorzystaniu bazy danych o liniach komunikacyjnych (linie, grupy, podgrupy) Musi istnieć możliwość przypisania danemu biletowi dowolnej liczby grup (zakresów obowiązywania), na przykład w przypadku utworzenie obszarowego biletu nocnego musi istnieć możliwość przypisania mu zakresu: linie nocne w Bydgoszczy, linie nocne w Toruniu, linie kolejowe Toruń Bydgoszcz Musi istnieć możliwość określania zakres obowiązywania danego biletu w co najmniej następujących zakresach: a) poprzez przypisanie linii, b) poprzez przypisanie grupy linii, c) poprzez przypisanie systemu i/lub podsystemu transportowego, d) poprzez określenie granicznych dat jego ważności, e) poprzez określenie rodzajów dni w datach granicznych (powszedni, sobota, niedziela, święta, inne zdefiniowane w kalendarzu), f) poprzez określenie rodzajów dni jego ważności w zakresie dat granicznych, g) poprzez określenie podokresów jego ważności w zakresie dat granicznych, h) poprzez określenie godzin obowiązywania Musi istnieć możliwość ograniczenia czasowego obowiązywania biletu, czyli oprócz przypisywania obszarowego zakresu obowiązywania musi istnieć możliwość czasowego zakresu obowiązywania. Oznacza to, że w przypadku utworzenia biletu obowiązującego w określonych godzinach, na przykład: w międzyszczycie (zachęcenie osób starszych do podróżowania poza szczytem) musi istnieć możliwość przypisania mu linii na których ma obowiązywać ale tylko w godzinach międzyszczytowych Przypisanie ważności biletu w określonych okresach czasowych musi działać wg następujących zasad: a) bezterminowa ważność biletu. Wybór tej opcji powoduje, że bilet jest ważny bez ograniczeń czasowych, b) określenie dat granicznych, a w nich dni, godzin i minut Wybór tej opcji powoduje, że bilet jest ważny w określonych ramach czasowych. Musi istnieć możliwość wyboru co najmniej dwunastu okresów czasowych o określonych datach granicznych, c) wybór opcji określonych w punktach a) i b) musi działać na zasadzie wzajemnego wykluczania, d) Wybór określonych rodzajów dni (pn pt, soboty, niedziele, święta, inne), e) W systemie musi istnieć możliwość przypisania dat początku i końca ważności biletu w momencie pierwszego użycia karty w kasowniku, w przypadku zakupionych biletów, którym w momencie zakupu nie zdefiniowano dat początku i końca jego obowiązywania. Dotyczy to biletów zakupionych z określoną ilością dni obowiązywania, dla których nie zdefiniowano w momencie zakupu dat początku i końca ważności biletu. System musi w momencie pierwszego skasowania/użycia karty przypisać w pamięci karty datę początku i końca ważności biletu. Informacje te muszą być zapisane także w bazie systemu centralnego SBM. 20

21 7.15. W przypadku pokrycia się przedziałów czasowych system musi poinformować o tym Administratora, który podejmie decyzję o akceptacji lub nie pokrycia się przedziałów czasowych. W przypadku akceptacji system musi w okresie pokrywającym się przyjąć sumę pokrycia czasowego. Sytuacje takie przedstawiono w przykładach 4 i 5 - Rysunek 5, Rysunek 6. Funkcjonalność ta ma ułatwić pracę Administratora głównie w przypadku wprowadzania czasowych zmian w zakresie obowiązywania biletu Musi istnieć możliwość wprowadzania zmian w zakresie obowiązywania poszczególnych biletów w okresie ich obowiązywania. Oznacza to, że jeśli Administrator w dniu 20 stycznia podejmie decyzję, że bilet obowiązujący od 1 do 31 stycznia, będzie ważny do 10 lutego, może wprowadzić taką zmianę do systemu (w tym do urządzeń pojazdowych i czytników kontrolnych) a pasażerowie nie muszą w związku z tym wykonywać żadnych dodatkowych czynności związanych z kartą zbliżeniową Musi istnieć edytowalny i definiowalny kalendarz będący podstawą do ustalania czasowej ważności biletów Musi w systemie istnieć narzędzie do przyznawania na daną kartę punktów lojalnościowych, w następujących przypadkach: za stosowanie systemu CICO, za przejazd daną linią/trasą, za przejazd o danej porze dnia/tygodnia/roku, inne ściśle powiązane z funkcjonalnością karty SBM, Musi istnieć możliwość definiowania liczby przyznanych punktów lojalnościowych, uzależniona od stopnia wykorzystania wyżej wymienionych przypadków, np. 10 punktów za 5 odbić check-out Musi istnieć systemowa możliwość pozyskania danych o stopniu wykorzystania w/w funkcjonalności, tj. liczba odbić na danej karcie, liczba przejazdów daną trasą, itd. wg wyżej wymienionych kryteriów Musi istnieć archiwum oferty taryfowej w archiwum muszą być gromadzone automatycznie wszelkie informacje o poszczególnych biletach, gromadzone dane muszą obejmować co najmniej: dane identyfikujące bilet, datę wprowadzenia i wycofania biletu, czasowy i obszarowy zakres obowiązywania, cenę, w archiwum musi zostać odnotowana każda zmiana dotycząca danego biletu Musi istnieć możliwość obszarowego definiowania biletów Definiowanie obszarowe musi się odbywać co najmniej w następujących konfiguracjach: bilet ważny na dowolnie wybranych fragmentach pojedynczych linii Oznacza to, że musi istnieć możliwość zdefiniowania biletu, który będzie ważny na dowolnej liczbie fragmentów pojedynczej linii lub dowolnej liczbie fragmentów dowolnej liczby odrębnych linii, bilet ważny na dowolnie wybranych fragmentach pojedynczej trasy lub tras, czyli ważny na wybranych liniach poruszających się tym fragmentem trasy lub 21

22 fragmentami odrębnych tras (trasa rozumiana jako ciąg komunikacyjny po którym przebiegają linie komunikacyjne) Oznacza to, że musi istnieć możliwość zdefiniowania biletu, który będzie ważny na dowolnej liczbie fragmentów pojedynczej trasy lub dowolnej liczbie fragmentów dowolnej liczby odrębnych tras, bilet ważny na dowolnie wybranej pojedynczej linii, bilet ważny na dowolnie wybranej grupie linii, Musi istnieć narzędzie do tworzenia dowolnej liczby grup linii. Musi istnieć możliwość dodawania i definiowania grup. Grupowanie linii ma na celu łatwiejsze przypisywanie obszarowego obowiązywania biletu. Musi istnieć możliwość łączenia grup linii w grupy. I tak: największą grupą linii będzie sieć metropolitalna, w skład której będą wschodzić wszystkie linie funkcjonujące na obszarze metropolitalnym i objęte wspólnym systemem sprzedaży. Innymi grupami mogą być: Komunikacja miejska Bydgoszcz i Komunikacja miejska Toruń, w skład których wchodzić mogą mniejsze grupy, na przykład: komunikacja dzienna, komunikacja nocna, komunikacja podmiejska, itd bilet ważny w wybranej strefie i w dowolnej liczbie wybranych stref, Jako strefę rozumie się obszar, na przykład śródmieście, w którym obowiązywać będzie dany bilet. Sposób definiowania stref został opisany w rozdziale Zarządzanie Strefami. Narzędzie to ma na celu umożliwić wprowadzenie do oferty taryfowej biletów strefowych, co jest między innymi istotne w przypadku funkcjonowania komunikacji międzygminnej (podmiejskiej), gdzie bilet wykupiony na obszar tylko jednej strefy traci ważność po przekroczeniu granicy miasta. Musi istnieć możliwość definiowania dowolnej liczby stref, przy czym strefy mogą się pokrywać częściowo lub całkowicie oraz strefy mogą znajdować się całkowicie wewnątrz innych stref. Musi istnieć możliwość zdefiniowania pojedynczej strefy jako dowolnej liczby odrębnych obszarów system musi umożliwiać zaimplementowanie danych o biletach we wszystkich urządzeniach pojazdowych tak aby w sposób jednoznaczny istniała możliwość weryfikacji biletu użytego przez pasażera, 7.24 Definiowanie czasu ważności wszystkich rodzaje biletów, o których mowa w niniejszym rozdziale musi być także możliwa na zasadzie od pierwszej walidacji. Oznacza to, że musi być możliwość zdefiniowania dowolnego rodzaju biletu pod względem obszarowego obowiązywania i dowolnego czasu obowiązywania, np. 0,5h, 1h, 1 dzień, 5 dni, 30 dni, itd. lecz ważność biletu i okres jego obowiązywania się rozpoczyna się od momentu pierwszej walidacji W systemie musi istnieć możliwość zdefiniowania biletu wieloprzejazdowego za dowolnie określaną kwotę. Ustalanie kwoty musi być możliwa przez Administratora systemu lub przez użytkownika, przy czym ustalanie wartości biletu wieloprzejazdowego przez użytkownika będzie możliwe tylko wówczas, gdy Administrator udostępni tę opcję Administrator może stworzyć w systemie dowolną liczbę biletów wieloprzejazdowy o dowolnie określonych wartościach, np. bilet za 10zł, 20zł, 50zł, 100zł, 150zł, 200zł, 500zł. Wartości mogą być dowolnie definiowane. 22

23 Administrator może stworzyć bilet wieloprzejazdowy o dowolnej wartości, którą określać będzie użytkownik. Oznacza to, że musi istnieć w systemie zakup przez pasażera biletu wieloprzejazdowego o wartości wybranej przez niego, np. 158,35zł W przypadku korzystania z biletu wieloprzejazdowego system musi automatycznie optymalizować koszt przejazdu w oparciu o istniejącą ofertę taryfowo biletową. Bilansowanie wartości przejazdów następować będzie po okresie zdefiniowanym przez Administratora, np. raz na dobę, raz na tydzień, raz na miesiąc, co trzy dni, itd. Na przykład: w ofercie istnieją następujące bilety jednorazowe: Jednoprzejazdowy w strefie miejskiej za 3,00zł, Jednoprzejazdowy w strefie miejskiej + podmiejskiej za 4,50zł, Piętnastominutowy za 2,00zł, Pięcioprzystankowy za 2,00z. bilet dobowy za 12,00zł. W przypadku gdy pasażer wykonał łącznie pięć przejazdów trwających dłużej niż 15 min każdy, czyli jednostkowo za 3,00zł każdy (łącznie za 15,00zł) system na koniec dnia tj. o godz: 00:00 zbilansuje koszt przejazdów i naliczy ich wartość jako wartość biletu dobowego za 12,00zł. W przypadku gdy pasażer wykonał pięć przejazdów ale cztery z nich były krótsze niż piętnaście minut, wówczas system na koniec dnia tj. o godz: 00:00 zbilansuje koszt przejazdów i naliczy ich wartość jako wartość 11,00zł (3zł+2zł+2zł+2zł+2zł) gdyż bilet dobowy byłby droższy. W przypadku natomiast gdyby pierwszy z w/w przejazdów odbyłby się w strefie miejskiej + podmiejskiej jednostkowa wartość przejazdów wyniosłaby by 12,50zł (4,50zł+2zł+2zł+2zł+2zł). Wówczas system zaliczyłby te przejazdy jako bilet dobowy za 12,00zł. Reasumują mechanizm optymalizacji kosztów przejazdów musi się odbywać na zasadzie, że system analizując wykonane przejazdy w zdefiniowanej przez Administratora jednostce czasu (np. jedna doba) analizuje wszystkie bilety na które te przejazdy mogłyby się odbyć i wybiera najtańszy z nich W zakresie biletów wieloprzejazdowych system oparty będzie na zasadzie check in/check out. W przypadku gdy pasażer nie dokona odbicia karty przy wyjściu zostanie obciążony jak za przejazd do końca trasy danej linii Administrator systemu musi mieć możliwość definiowania grupy biletów które mają podlegać analizie przez system podczas optymalizacji przejazdów. Na przykład Administrator musi mieć możliwość przypisania do grupy biletów jednoprzejazdowych, czasowych i odcinkowych oraz biletu dobowego. Może mieć natomiast możliwość włączenia do tej grupy biletu pięciodobowego i określenia jako okres bilansowania pięć dni (dób). Przy czym w takim przypadku określenie doby początkowej dla danego pasażera ma miejsce w momencie pierwszej walidacji od momentu zakupu 7.28 W systemie musi istnieć możliwość definiowania biletów czasowych i odcinkowych ważnych od momentu walidacji Przykłady czasowego definiowania biletów podano na rysunkach - Rysunek 2, Rysunek 3, Rysunek 4, Rysunek 5, Rysunek Musi istnieć narzędzie o nazwie Archiwum oferty taryfowej. 23

24 w Archiwum oferty taryfowej muszą być przechowywane wszystkie bilety, które obowiązywały w systemie, schemat działania narzędzia (wymagania minimum) przedstawiono na rysunku - Rysunek W narzędziu Archiwum oferty taryfowej musi istnieć możliwość generowania, podglądu i wydruku statystyk. Statystyki musza zawierać co najmniej następujące informacje: liczba i wartość sprzedanych biletów z podziałem na okresy czasowe, przy czym użytkownik musi mieć możliwość definiowania co najmniej następujących okresów: dzień, tydzień, miesiąc, rok Ponadto statystyki, o których mowa wyżej muszą zawierać zestawienie linii komunikacyjnych na których zostały wykorzystane z podaniem liczby walidacji, z podziałem na okresy czasowe, przy czym użytkownik musi mieć możliwość definiowania co najmniej następujących okresów: dzień, tydzień, miesiąc, rok. 24

25 Przykład 1 Początkowa Końcowa Bilet x bez ograniczeń czasowych Daty skrajne Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. Daty skrajne Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. Daty skrajne Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. dodaj daty skrajne Opis przykładu 1. Bilet jest ważny bez żadnych ograniczeń czasowych. Rysunek 2 Definiowanie czasowego obowiązywania biletu przykład 1. Przykład 2 Początkowa Końcowa Bilet bez ograniczeń czasowych x Daty skrajne 01-sty sty-10 Wszystkie Pn Wt Śr Cz Pt So Nd x bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. Daty skrajne Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. Daty skrajne Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. dodaj daty skrajne Opis przykładu 2. Bilet jest ważny od 1 stycznia do 31 stycznia bez żadnych ograniczeń godzinowych. Rysunek 3 Definiowanie czasowego obowiązywania biletu przykład 2. 25

26 Przykład 3 Początkowa Końcowa Bilet bez ograniczeń czasowych x Daty skrajne 01-sty sty-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x 00:00 06:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 09:00 13:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 16:00 23:59 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x Daty skrajne 01-lut lut-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x bez ogr. x bez ogr. x Daty skrajne 20-lut lut-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. 00:00 00:00 x 05:00 23:00 00:00 00:00 x 05:00 23:00 00:00 00:00 x 05:00 23:00 00:00 00:00 00:00 00:00 dodaj daty skrajne Opis przykładu. Bilet ważny jest od 1 stycznia do 31 stycznia we wszystkie dni tygodnia w godzinach od 00:00 do 06:00, od 9:00 do 13:00 oraz od 16:00 do 23:59. Bilet ten jest ważny też od 1 lutego do 10 lutego ale tylko w soboty i niedziele bez ograniczeń godzinowych. Bilet ten jest ważny też od 20 lutego do 28 lutego w poniedziałki, środy i piątki od 5:00 do 23:00. Rysunek 4 Definiowanie czasowego obowiązywania biletu przykład 3. 26

27 Przykład 4 Początkowa Końcowa Bilet bez ograniczeń czasowych x Daty skrajne 01-sty sty-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x 00:00 06:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 09:00 13:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 16:00 23:59 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x Daty skrajne 20-sty lut-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x bez ogr. x bez ogr. dodaj daty skrajne Początkowa Końcowa Bilet bez ograniczeń czasowych x Daty skrajne 01-sty sty-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x 00:00 06:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 09:00 13:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 16:00 23:59 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x Daty skrajne 20-sty sty-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x bez ogr. x bez ogr. 00:00 00:00 x 00:00 06:00 x 00:00 06:00 x 00:00 06:00 x 00:00 06:00 x 00:00 06:00 00:00 00:00 00:00 00:00 00:00 00:00 x 09:00 13:00 x 09:00 13:00 x 09:00 13:00 x 09:00 13:00 x 09:00 13:00 00:00 00:00 00:00 00:00 00:00 00:00 x 16:00 23:59 x 16:00 23:59 x 16:00 23:59 x 16:00 23:59 x 16:00 23:59 00:00 00:00 00:00 00:00 x Daty skrajne 01-lut lut-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x bez ogr. x bez ogr. dodaj daty skrajne Opis przykładu 4. Bilet jest ważny od 1 do 31 stycznia we wszystkie dni tygodnia w określonych godzinach, ponadto administrator wprowadził (od razu lub później) możliwość korzystania na ten bilet od 20 stycznia do 28 lutego w soboty i niedziele bez ograniczeń godzinowych. W okresie od 20 do 31 stycznia nastąpiło pokrycie okresów ważności o różnych parametrach obowiązywania. W tej sytuacji system pyta Administratora o okceptację takiego stanu rzeczy. Jeśli administrator zaakceptuje daty system musi w okresie pokrywającym się przyjąć sumę pokrycia czasowego z obu okresów. Urządzenia pojazdowe muszą zatem honorować bilet wg schematu przedstawionego w drugiej części przykładu. Rysunek 5 Definiowanie czasowego obowiązywania biletu przykład 4. 27

28 Przykład 5 Początkowa Końcowa Bilet bez ograniczeń czasowych x Daty skrajne 01-sty sty-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x 00:00 06:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 09:00 13:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 16:00 23:59 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x Daty skrajne 15-sty sty-10 Wszystkie Pn Wt Śr Cz Pt So Nd x bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. dodaj daty skrajne Bilet bez ograniczeń czasowych x Daty skrajne 01-sty sty-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x 00:00 06:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 09:00 13:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 16:00 23:59 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x Daty skrajne 15-sty sty-10 Wszystkie Pn Wt Śr Cz Pt So Nd x bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x Daty skrajne 18-sty sty-10 Wszystkie Pn Wt Śr Cz Pt So Nd bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. bez ogr. x 00:00 06:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 09:00 13:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 x 16:00 23:59 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 00:00 dodaj daty skrajne Opis przykładu 5. Bilet jest ważny od 1 do 31 stycznia we wszystkie dni tygodnia w określonych godzinach, ponadto administrator wprowadził (od razu lub później) możliwość korzystania z tego biletu w okresie od 15 do 17 stycznia we wszystkie dni tygodnia bez ograniczeń. W okresie tym nastąpiło pokrycie okresów system musi zatem od 15 do 17 stycznia przyjąć sumę pokrycia czasowego. Bilet będzie zatem ważny wg schematu przedstawionego w drugiej części przykładu. Rysunek 6 Definiowanie czasowego obowiązywania biletu przykład 5. 28

29 Rysunek 7 Wymagania minimum dla modułu Archiwum oferty taryfowej. 29

30 8. Zarządzane strefami W systemie musi istnieć narzędzie do definiowania stref obowiązywania poszczególnych biletów Musi istnieć możliwość przypisania danemu biletowi jednej lub więcej stref, w których będzie on obowiązywał Przypisanie strefy lub stref musi być możliwe niezależnie od przypisania biletu dla dowolnie wybranego fragmentu jednej lub więcej linii, fragmentu trasy lub tras, dowolnie wybranej linii czy grupy linii Definiowanie danej strefy musi być możliwe według konfiguracji określonych na rysunkach: Rysunek 8, Rysunek 9, Rysunek 10, Rysunek 11, Rysunek 12, Rysunek 13. Strefa 1 Rysunek 8 Konfiguracja pojedynczej strefy. 30

31 Strefa 1 Strefa 1 Rysunek 9 Konfiguracja pojedynczej strefy zlokalizowanej w dwóch odrębnych obszarach. Strefa 1 obszar wyłączony ze Strefy 1 Rysunek 10 Konfiguracja pojedynczej strefy z wyłączeniem obszaru wewnątrz. 31

32 Strefa 2 Strefa 1 Rysunek 11 Konfiguracja dwóch niezależnych stref położonych w dwóch niezależnych obszarach. Strefa 2 Strefa 1 Rysunek 12 Konfiguracja dwóch niezależnych stref położonych w obszarach częściowo się pokrywających. 32

33 Strefa 2 Strefa 1 Rysunek 13 Konfiguracja dwóch niezależnych stref zlokalizowanych jedna wewnątrz drugiej Musi istnieć narzędzie do definiowania stref z wykorzystaniem mapy System, po zdefiniowaniu strefy z wykorzystaniem mapy, musi automatycznie przypisać linie (lub ich fragmenty jeśli w strefie znajduje się tylko fragment lub fragmenty linii) oraz odcinki międzyprzystankowe znajdujące się w zdefiniowanej strefie Definiowanie stref nie może być ograniczone granicami administracyjnymi poszczególnym miejscowości. Oznacza to, że Strefa 1 definiowana jak na rysunku - Rysunek 8, może znajdować się częściowo w Bydgoszczy jak i w Toruniu. 9. Mapa W systemie musi istnieć moduł Mapa Mapa musi prezentować minimum następujące elementy: a) przedstawiony w skali plan sytuacyjny Województwa Kujawsko-Pomorskiego b) linie komunikacyjne objęte SBM, c) lokalizacje wszystkich przystanków i węzłów, z możliwością grupowania przystanków w węzły. d) strefy obowiązywania biletów, przy czym funkcjonalność ta musi być powiązana z modułem Strefy, e) musi istnieć możliwość wyłączania i włączania poszczególnych elementów (warstw) mapy (przystanki, linie, strefy, itd.), f) lokalizacje pojazdów z uszkodzonymi kasownikami, lokalizacja uszkodzonych kasowników będzie odbywać się w następujący sposób: w przypadku stwierdzenia przez komputer pojazdowy uszkodzenia kasownika lub braku komunikacji z kasownikiem komputer pojazdowy wyśle komunikat do modułu Mapa. Na mapie zostanie wyświetlony pojazd (na podstawie pozycji GPS), który ma uszkodzony kasownik wraz z podaniem numeru linii i brygady, informacji towarzyszyć będzie sygnał 33

34 dźwiękowy, komunikat zniknie z ekranu po akceptacji dyspozytora i zostanie zarchiwizowany, g) w analogiczny sposób jak dla kasowników funkcjonować musi identyfikacja uszkodzeń pozostałych elementów systemu (konsole kierowców, stacje bazowe, biletomaty stacjonarne, biletomaty mobilne, terminale sprzedaży, terminale kontrolerskie, terminale konduktorskie,, kioski informacyjne, stanowiska dyspozytorskie, itd.), h) mapa musi prezentować siatkę ulic i dróg, linie komunikacyjne włączone do systemu oraz podstawowe obiekty topograficzne, węzły komunikacyjne Elementy mapy muszą być edytowalne wg następujących zasad: a) przystanki będą umieszczane na mapie na podstawie współrzędnych GPS, b) współrzędne GPS będą wprowadzane w module Mapa poprzez powiązanie z modułem Przystanki, wszelkie zmiany dokonane z poziomu mapy, dotyczące lokalizacji przystanków muszą być automatycznie zmienione w module Przystanki. Także wszelkie zmiany dokonane w module przystanki muszą mieć swoje odzwierciedlenie na mapie. Na przykład zmiana współrzędnych geograficznych GPS musi spowodować zmianę lokalizacji przystanku na mapie bez utraty powiązania z przebiegiem trasy. c) po wprowadzeniu współrzędnych GPS w module Przystanki będą automatycznie generowane na mapie, d) definiowanie przystanków i wprowadzanie zmian w ich opisie i współrzędnych GPS tak jak w module Przystanki musi być możliwe z poziomu Mapy ale też z poziomu modułu Przystanki. e) musi istnieć możliwość nadpisywania danych w oparciu o numer przystanku przy każdorazowym imporcie danych, f) musi istnieć możliwość modyfikacji przebiegu linii, przy czym przebieg linii i przystanki muszą być ze sobą ściśle powiązane, g) system musi uwzględniać występowanie wielu wariantów przebiegu jednej linii oraz funkcjonowanie różnych przystanków w zależności od wariantów, h) system musi umożliwiać natychmiastowe wyświetlenie na mapie komunikatów alarmowych (nieprawidłowe działanie urządzeń) generowanych automatycznie przez system, i) system musi mieć możliwość natychmiastowego wyświetlania na mapie komunikatów alarmowych wysyłanych przez obsługę pojazdu za pomocą komputera pojazdowego (konsoli kierowcy), j) mapa musi być edytowalna, oznacza to, że użytkownik musi mieć możliwość modyfikacji przebiegu trasy, lokalizacji przystanków, lokalizacji biletomatów, kiosków informacyjnych itd., z poziomu mapy. Modyfikacja wszelkich elementów z poziomu mapy musi mieć swoje odzwierciedlenie w bazach danych, k) musi istnieć możliwość wyświetlenia na mapie wraz z sygnałem dźwiękowym informacji wysłanej przez kontrolera w sytuacji alarmowej (napad, wypadek, awaria, przestępstwo), 34

35 l) definiowanie elementów w module mapa musi być powiązane ze wszystkimi modułami systemu, oznacza to, że zmiana współrzędnych geograficznych przystanków (GPS) w module mapa musi spowodować zmianę tych danych także w module przystanki. Zmiana współrzędnych GPS w module przystanki musi z kolei wymusić położenie przystanku na mapie oraz wprowadzone zmiany muszą być widoczne podczas edycji przystanku w module Mapa Mapa musi funkcjonować w taki sposób aby podczas jej edycji czy obsługi była cały czas widoczna i aktywna. Wszelkie narzędzia do jej obsługi musza się zatem znajdować w odpowiednich belkach lub panelach narzędziowych Musi istnieć warstwa w module Mapa dedykowana pasażerom, widoczna z poziomu serwisu internetowego dla użytkownika. Szczegółowy opis znajduje się w rozdziale Serwis internetowy. 10. Karty elektroniczne charakterystyka i funkcjonalność Założenia ogólne. a) Karta pełni funkcję identyfikatora użytkownika. Umożliwia wykonywanie czynności, do do których został mu przyznany dostęp. Założenia technologiczne systemu muszą umożliwiać zapisanie bezpośrednio na karcie danych, które nie mogą istnieć w oderwaniu od nośnika fizycznego. b) Wykonawca dostarczy, uruchomi i zapewni funkcjonowanie w Systemie Biletu Metropolitalnego elektronicznych kart zbliżeniowych (Contactless Credit Card) z wbudowanym mikroprocesorem, pamięcią oraz anteną, spełniających wymagania i parametry techniczne opisane w tym dokumencie. c) Wdrożony przez Wykonawcę system musi, umożliwiać funkcjonowanie Elektronicznych Legitymacji Studenckich (w Bydgoszczy i Toruniu) oraz funkcjonujących w Bydgoszczy nośników elektronicznych biletów okresowych pn. Bydgoska Kart Miejska w zakresie kodowania i odczytu Elektronicznych biletów okresowych w ramach taryfy biletu metropolitalnego. Wyżej wymienione nośniki spełniają standard kart Mifare Classic 1K. d) Wdrożony system musi umożliwiać przyszłe wykorzystanie karty SBM jako Karty miejskiej w Toruniu i w Bydgoszczy Charakterystyka techniczna kart. Standard podstawowy kart: MIFARE PLUS X (wersja expert) standard zgodny z normą ISO/IEC14443 typ A lub typ B, Parametry podstawowe a) karta musi spełniać standard warunków certyfikatu MIFARE (wymagane jest załączenie przez wykonawcę certyfikatu Mifare wystawionego przez Mifare Certification Institute - Arsenal Research, Faradaygasse 3, 1030 Wiedeń, Austria), 35

36 b) karta musi zawierać pamięci ROM (dla systemu operacyjnego), EEPROM (dla danych, kodów, aplikacji na karcie), RAM pamięć operacyjna wykorzystywana w trakcie używania karty, c) pamięć karty 4 KB, technologia wykonania CMOS EEPROM, pamięć podzielona na 32 sektory po 4 bloki (16B) i 8 sektorów po 16 bloków (16B), liczba cykli zapisu: minimum 200 tys. razy, liczba cykli odczytu jest nielimitowana, okres przechowywania danych do 10 lat, Wsparcie dla kontrolowanego dostępu do pamięci przy użyciu odpowiednich kluczy dostępowych, d) format nośnika karty ID-1 (zgodnie z międzynarodowym standardem ISO/IEC 7810), e) karta wykonana na bazie układu scalonego MF1MOA2S50 (32 sektory pamięci) lub równoważnego, f) numeracja kart musi być zgodna z systemem numeracji według normy PN-EN ISO/IEC dla przeznaczenia wynikającego z niniejszego opracowania, g) karta laminowana wielowarstwowo, etapowo (dla otrzymania minimalnej grubości i wysokiej jakości) z tworzywa sztucznego PVC nie zawierającego szkodliwych składników chemicznych, przyjazna dla środowiska zgodnie z ustawą z dnia r. Prawo ochrony środowiska (DZ. U. z 2006r. nr 129, poz. 902 z późn. zm.) oraz ustawą z dnia r. o odpadach (Dz. U. z 2007r. nr 39, poz. 251 z późn. zm.), h) zasilanie kart indukcyjne przez czytnik, karta bez własnego zasilania, i) karty mają być zadrukowane technologią offsetową, drukiem czterokolorowym, zgodnie z uzgodnionymi wzorami graficznymi, nadruki na karcie oraz ich rozmieszczenie, powinny być zgodne właściwymi normami dotyczącymi kart (np.: PN- ISO/IEC 7810, PN-ISO/IEC 7812, PN-EN ISO/IEC 7816), j) wbudowany generator liczb losowych zgodny z AIS Sposób zabezpieczenia kart. a) cecha bezpieczeństwa - 7 bajtowy unikatowy numer seryjny UID (unikalny identyfikator), zgodność z wymogami oraz zabezpieczeniami wynikającymi z normy ISO/IEC14443, b) możliwość dostępu do bezpiecznych i oddzielonych zaporami aplikacji przy użyciu protokołów typ A lub typ B, c) dane transmisji pomiędzy terminalem a kartą muszą być zabezpieczone algorytmem AES lub nowszym (zaimplementowany mechanizm kryptograficzny), przy założeniu że są obsługiwane przez zainstalowane w systemie czytniki kart, d) mechanizmy zabezpieczeń na ataki programowe typu SPA, DPA, EMA, DFA, automatyczna korekcja i detekcja błędów, e) wykonawca zapewnia wykonania niepowtarzalnej mapy karty, f) karta w sposób jawny ma być oznaczona numerem będącym wynikiem konwersji numeru odczytanym z pamięci układu scalonego w procesie drukowania. Numer 36

37 umieszczony ma być laserowo, z wykluczeniem próby jego zdrapania, podrobienia, starcia itp., g) karta zawierać ma 16 bitowy licznik zabezpieczony sprzętowo oraz posługiwać się protokołem bezpieczeństwa zgodnym z CRC, h) układ scalony mikrokontrolera powinien spełniać poziom bezpieczeństwa Common Criteria EAL 4+ lub wyższy, Posiadanie unikalnego niezmiennego i niemodyfikowalnego numeru programowanego (przypisanego) trwale przez producenta układu scalonego, i) musi istnieć możliwość wyłączania programowanych funkcji zapisu dla kart wycofywanych z obiegu. Blokada kart przy próbie użycia Sposób komunikacji. a) komunikacja drogą radiową o częstotliwości fal radiowych MHz, b) interfejs bezstykowy zgodny z normą ISO/IEC typ A lub typ B, c) komunikacja między kartą i czytnikiem odbywająca się drogą radiową musi być szyfrowana, d) szybkość komunikacji 106 kbit/s, e) czas realizacji transakcji poniżej 150ms, f) protokół komunikacyjny stosowany dla kart inteligentnych T=0 lub T=1, g) zasięg operacyjny w zakresie do 10cm zgodny z normą ISO/IEC 14443, h) warstwa fizyczna wymiany danych pomiędzy terminalem a kartą zgodna z normą dla kart bezstykowych ISO/IEC i) Wysokość procentowa tzw. zwrotów z pola (FRR) kart zbliżeniowych nie może przekraczać 2% Wytrzymałość kart. a) trwałość ogólna kart w warunkach normalnej eksploatacji minimum 10 lat, b) trwałość mechaniczna musi być zgodna z normą ISO bez utraty funkcjonalności i walorów estetycznych, c) trwałość chemiczna musi być zgodna z normą ISO 10373, d) trwałość temperaturowa musi być zgodna z normą ISO (w zakresie temperatur - C do C nie występuje utrata funkcjonalności i walorów estetycznych), e) maksymalna względna wilgotność środowiska pracy karty 90% Wzory graficzne kart. a) wzory graficzne dla kart zostaną opracowane przez wykonawcę zadania w uzgodnieniu z Zamawiającym. Wykonawca przedstawi co najmniej trzy projekty graficzne. W projektach graficznych należy uwzględnić cechy charakterystyczne dla obszaru metropolitalnego i dwóch miast gniazdowych obszaru (Bydgoszcz, Toruń) oraz umieścić: herb województwa kujawsko pomorskiego, logo Bydgoszczy oraz logo Torunia oraz logo Projektu, b) wzory graficzne zostaną udostępnione w terminie do 60 dni od dnia zawarcia umowy. 37

38 10.3. Wymagania funkcjonalne dla oprogramowania i kart zbliżeniowych karty działające w Systemie Biletu Metropolitalnego muszą posiadać trzy funkcje: Biletu Metropolitalnego (BM), Karty Metropolitalnej (KM) i tzw. Welcome Card (WC). System SBM musi umożliwiać zakodowanie biletu komunikacji publicznej dla wszystkich w/w funkcji. Dla projektowanego Biletu Metropolitalnego należy przewidzieć możliwość kodowania dowolnych typów biletów okresowych (sześć kontraktów) oraz dowolnych biletów jednorazowych komunikacji publicznej, które będą odliczane w następujący sposób: licznik zostanie pomniejszony o ilość skasowanych biletów z konta po zbliżeniu karty do kasownika zlokalizowanego w środku transportu. Bilet Metropolitalny nie będzie umożliwiał opłacania innych usług. Dla projektowanej Kart Metropolitalnej należy przewidzieć możliwość kodowania dowolnych typów biletów okresowych komunikacji publicznej (E-bilet okresowy) oraz biletów jednorazowych ( E-bilet jednorazowy), które będą odliczane po zbliżeniu karty do kasownika.. Karta Metropolitalna będzie rozwinięciem usługi Biletu Metropolitalnego o różnego rodzaju usługi np. wstęp na basen, do teatru lub innych instytucji kultury. Welcome Card będzie kartą dedykowaną (specjalną) dla różnego rodzaju usług i wydarzeń wraz z przypisaniem funkcji biletu komunikacji publicznej, określonego zakresem i okresem ważności pod konkretny typ karty Welcome Card, karty działające w Systemie Biletu Metropolitalnego muszą posiadać funkcje E-bilet oraz E-portmonetka. Karty specjalne działające w Systemie Biletu Metropolitalnego (Welcome Card) nie będą posiadały funkcji E-portmonetki, Karty wykonane z materiałów trwałych (PCV) będą zapewniały funkcjonowanie usług na poziomie Biletu Metropolitalnego, Karty Metropolitalnej, jak i Welcome Card, podstawowym działaniem Systemu Biletu Metropolitalnego oraz Karty Metropolitalnej będą operacje wykonywane za pomocą kart bezkontaktowych, a) dostarczone karty zbliżeniowe (inteligentne) muszą być zgodne z otwartym standardem (otwarta platforma) zawierającym inteligentny system operacyjny MULTOS (Hitachi) lub równoważnym pod kątem funkcjonalnym, system ten musi umożliwiać bezpieczne przechowywanie danych, realizację komunikacji pomiędzy kartą a terminalem, zarządzanie systemem plików oraz musi posiadać dodatkowe funkcje dla wykonywania algorytmów kryptograficznych, jak również wymiany danych pomiędzy aplikacjami, system musi być zgody z wytycznymi projektowymi dla systemów operacyjnych kart zawartymi w normie nr ISO/IEC , b) system operacyjny karty zbliżeniowej musi zapewnić możliwość umieszczenia na karcie mikroprocesorowej wielu aplikacji, wśród których wymienić należy identyfikację cyfrową (PKI zgodną z PKCS#15), usługi transportu, usługi inne, systemy lojalnościowe itp., c) system operacyjny karty zbliżeniowej musi umożliwiać dodawanie kolejnych aplikacji przez wydawcę karty, również w trakcie ich funkcjonowania, dotyczy to również firm opracowujących produkty opracowywane w różnych językach programowania na zlecenie wydawcy karty, d) system informatyczny obsługujący karty zbliżeniowe musi obsługiwać karty różnych producentów, oraz karty posiadające różne systemy operacyjne, 38

39 e) system informatyczny obsługujący karty zbliżeniowe musi zapewnić centralne zarządzanie kartami, aplikacjami dla kart, aplikacjami na karcie, umożliwiać ich dodawanie (ładowanie) i usuwanie na kartach (aktualizacja kart), f) system informatyczny obsługujący karty musi umożliwiać aktualizację kart w punktach obsługi klienta, w czytnikach kart (kasowniki w pojazdach komunikacji publicznej, czytniki kontrolerów), w biletomatach, poprzez usługi GSM (SMS) oraz serwis strony internetowej (Web service), g) wykonawca musi dostarczyć wraz z inteligentnymi kartami zbliżeniowymi oprogramowanie typu middleware do integracji z systemem operacyjnym i zapewnienia korzystania z funkcji kryptograficznych z wykorzystaniem karty elektronicznej, oprogramowanie typu middleware musi zapewnić integrację z systemem Windows i Linux, komunikacja z kartą zgodna z PKCS#11, Aplikacje dla Systemu Biletu Metropolitalnego i Karty Metropolitalnej System Biletu Metropolitalnego i Karty Metropolitalnej musi zawierać aplikacje umożliwiające realizację następujących funkcji oraz ich programowanie na kartach: a) Aplikacja nr 1 cyfrowego identyfikatora zapewniająca bezpieczne przechowywanie danych użytkownika karty, b) Aplikacja nr 2 E-portmonetka zapewniająca transakcje bezstykowe dotyczące aktywowania biletów jednorazowych, które przechowywane będą w systemie centralnym, c) Aplikacja nr 3 E-bilet okresowy, zapewniająca przechowywanie informacji w zakresie usług związanych z transportem publicznym, w tym rodzaj biletu wraz z okresem ważności oraz obszarem obowiązywania, d) Aplikacja nr 4 Lojalnościowa, zapewniająca przechowywanie informacji w zakresie usług związanych z imprezami kulturalnymi oraz sportowymi, wstęp do muzeum, na basen itp. e) Aplikacja nr 5 SPP, zapewniająca przechowywanie informacji w zakresie usług związanych ze Strefą Płatnego Parkowania, systemem Park & Ride, wypożyczalniami rowerów itp., f) Aplikacja nr 6 Specjalna, zapewniająca przechowywanie informacji w zakresie usług specjalnych np. Welcome card Aplikacje wgrywane są na karty w zależności od potrzeb użytkownika. Na karcie umieszcza się aplikacje wyłącznie te, z których będzie korzystał użytkownik (deklaracja użytkownika) Przykładowe rozwiązanie dla Biletu Metropolitalnego, Karty Metropolitalnej i Welcome Card przedstawiono na rysunku - Rysunek

40 SYSTEM BILETU METROPOLITALNEGO KARTA METROPOLITALNA BILET METROPOLITALNY WELCOME CARD KARTA MIFARE PLUS X KARTA MIFARE ULTRA LIGHT KARTA MIFARE PLUS X KARTA MIFARE PLUS X KARTA MIFARE PLUS X Transport publiczny, bilety okresowe Transport publiczny - bilety jednorazowe Transport publiczny, bilety jednorazowe, n-przejazdowe, weekendowe Transport publiczny, bilety okresowe Transport publiczny - bilety jednorazowe Usługi - opłaty jednorazowe Transport publiczny - bilety jednorazowe Usługi - opłaty jednorazowe Różnego rodzaju usługi, grupy usług Bilet okresowy na Transport Publiczny o okresie ważności dostosowanym do danej usługi lub grup usług TYPY KART karta spersonalizowana karta niespersonalizowana karta spersonalizowana karta niespersonalizowana Welcome Card elektroniczna legitmacja studencka elektroniczna legitmacja studencka FUNKCJE KART e-bilet, e-portmonetka e-bilet e-bilet, e-portmonetka e-bilet, e-portmonetka e-bilet Rysunek 14 Funkcjonalności kart wydawanych w ramach Systemu Biletu Metropolitalnego 40

41 11. Zarządzanie kartami Założenia ogólne Oprogramowanie wprowadzone dla Systemu Biletu Metropolitalnego w ramach Bydgosko Toruńskiego Obszaru Metropolitalnego musi posiadać moduł umożliwiający zarządzanie elektronicznymi kartami funkcjonującymi w ramach systemu Charakterystykę i parametry kart funkcjonujących w systemie określono w rozdziale Karty elektroniczne charakterystyka i funkcjonalność Oprogramowanie musi umożliwiać zarządzanie kartami na poziomie ich użytkowania, od momentu dostarczenia przez producenta do momentu wycofania z obiegu, oraz na poziomie archiwalnym archiwizacja kart wycofanych z użytkowania Przedstawione w niniejszym rozdziale wymagania stanowią wymagania minimum a przedstawione rozwiązania projektowe mogą być zrealizowane w inny sposób przy zachowaniu wszystkich funkcjonalności Wykonawca musi dostarczyć oprogramowanie najwyższej jakości, spełniające wymogi normy ISO/IEC :2001 (Analiza Modelu Jakości Produktów Programowych) Ewidencja kart Moduł zarządzania kartami musi umożliwiać pełną ewidencję wydanych kart Ewidencji podlegają karty będące w użytkowaniu, karty archiwalne wycofane z użytkowania oraz karty zablokowane z tytułu różnego rodzaju nadużyć Funkcjonalności modułu zarządzania kartami Moduł zarządzania kartami musi zawierać następujące funkcjonalności (aplikacje) - Rysunek 15: a) Aplikacja Karta spersonalizowana, b) Aplikacja Karta niespersonalizowana, c) Aplikacja Welcome Card, d) Aplikacja Legitymacja studencka (ELS), e) Aplikacja Obsługa internetowa użytkownika, f) Aplikacja Wyszukiwania, Ewidencja kart, g) Aplikacja Zarządzanie kontami i kartami użytkowników, h) Aplikacja Doładowanie karty, i) Aplikacja Sprzedaż biletu okresowego dla transportu publicznego, j) Aplikacja Zarządzanie usługami, k) Aplikacja Blokowanie karty/odblokowanie karty, l) Aplikacja Reklamacje, m) Aplikacja Generowanie wykazu operacji karty, n) Aplikacja Wydawanie duplikatów kart, o) Aplikacja Statystyka. 41

42 Związane z wydaniem karty Związane z obsługą kart Związane z zarządzaniem kartami i usługami Moduł ZARZĄDZANIA KARTĄ I BILETEM METROPOLITALNYM FUNKCJONALNOŚCI MODUŁU (APLIKACJE) WYDANIE KARTY SPERSONALIZOWANEJ DOŁADOWANIE KARTY ZARZĄDZANIE KONTAMI I KARTAMI UŻYTKOWNIKÓW WYDANIE KARTY NIESPERSONALIZOWANEJ WELCOME CARD LEGITYMACJA STYDENCKA E-STUDENT SPRZEDAŻ BILETÓW OKRESOWYCH DUPLIKAT KARTY BLOKOWANIE/ODBLOKOWANIE KARTY ZARZĄDZANIE USŁUGAMI WYSZUKIWANIE, EWIDENCJA KART GENEROWANIE WYKAZU OPERACJI REKLAMACJE OBSŁUGA INTERNETOWA UŻYTKOWNIKA STATYSTYKA Rysunek 15 Funkcjonalności modułu Zarządzanie kartami Moduł zarządzania kartami musi umożliwiać wydawanie i zarządzaniem trzema typami kart: a) Karta spersonalizowana, b) Karta niespersonalizowana, c) Welcom card Moduł zarządzania kartami musi umożliwiać obsługę następujących typów kart: a) Legitymacja studencka (ELS). b) Bydgoska Karta Miejska (BKM) Aplikacja KARTA SPERSONALIZOWANA funkcjonalność aplikacji Nabycie przez użytkownika karty spersonalizowanej możliwe jest wyłącznie w punktach obsługi klienta POK i musi zostać poprzedzone złożeniem odpowiedniego wniosku (zawierającego dane osobowe, zgodę na przetwarzanie danych osobowych, oraz zgodę na przetwarzanie danych o użyciu karty i wykonywanych operacjach). Odpowiedni wzór wniosku zostanie przygotowany przez wykonawcę i uzgodniony ostatecznie z zamawiającym Wnioski można składać osobiście w punktach obsługi klienta POK lub poprzez portal internetowy dedykowany specjalnie dla usług związanych z Systemem Biletu Metropolitalnego. Rejestracja użytkownika odbywa się na podstawie ważnego dowodu tożsamości. W przypadku osób niepełnoletnich rejestracja odbywa się na podstawie dowodu tożsamości opiekuna oraz legitymacji uczniowskiej. Weryfikacji danych dokonuje pracownik obsługujący POK. Aplikacja karty spersonalizowanej musi umożliwiać dołączenie do utworzonego konta użytkownika karty spersonalizowanej zdjęcia użytkownika. Zdjęcie użytkownika może być pozyskane na wiele sposobów: a) zdjęcie dostarcza użytkownik, wówczas możliwe musi być zeskanowanie zdjęcia i dołączenia go do konta użytkownika, 42

43 b) zdjęcie wykonywane jest na miejscu przez pracownika POK i dołączane jest do konta użytkownika Zdjęcie zostanie przypisane do konta użytkownika oraz zostanie umieszczone (wydrukowane) na karcie użytkownika. Użytkownik jest zobowiązany do podpisania wniosku. Aplikacja musi umożliwiać dodanie do systemu (bazy danych) danych użytkownika, zeskanowanego wniosku oraz zdjęcia i przypisanie ich do nadanego konta użytkownika. Kartę spersonalizowaną będzie można odebrać osobiście lub przez pełnomocnika (na podstawie wystawionego pełnomocnictwa) we wskazanym przez użytkownika punkcie POK, i ustalonym przez wykonawcę terminie, po podpisaniu stosownej umowy. Aplikacja umożliwi dodanie do konta użytkownika umowy określającej zasady użytkowania karty. Wzór umowy zostanie przygotowany przez wykonawcę i uzgodniony z zamawiającym. Użytkownik potwierdza odbiór karty W przypadku złożenia, przez użytkownika, wniosku za pomocą strony internetowej, informacją zwrotną (na adres poczty elektronicznej użytkownika, lub telefon komórkowy - sms) zostanie wskazany termin oraz potwierdzone zostanie miejsce podpisania wniosku. Złożenie wniosku drogą internetową musi umożliwiać użytkownikowi dołączenie zdjęcia. W trakcie spotkania pracownik POK przy pomocy aplikacji dotyczącej obsługi wniosków składanych poprzez portal internetowy, wydrukuje wniosek i dokona weryfikacji danych osobowych. Podpisany wniosek zostanie zeskanowany i umieszczony w bazie danych. Kartę spersonalizowaną będzie można odebrać osobiście lub przez pełnomocnika (na podstawie wystawionego pełnomocnictwa) we wskazanym przez użytkownika punkcie POK, i ustalonym przez wykonawcę terminie, po podpisaniu stosownej umowy W procesie wydawania karty spersonalizowanej tworzone jest indywidualne konto użytkownika kart. Użytkownik otrzymuje dostęp do indywidualnego konta poprzez dedykowaną stronę internetową, stworzoną przez wykonawcę. Na etapie wykonywania aplikacji ustalony zostanie zakres informacji dostępny dla użytkowników internetowych. Internetowy profil użytkownika umożliwia zarządzanie własnym kontem, do którego przypisana jest karta lub kilka kart (w przypadku zarządzania kartami rodzinnymi lub firmowymi), w zakresie doładowywania, sprawdzania posiadanych środków, generowania wykazów operacji, terminów ważności karty itp W ramach Systemu Biletu Metropolitalnego wydawane będą karty posiadające następujące funkcje: a) e-bilet, b) e-portmonetka, c) e-bilet i e-portmonetka Aplikacja KARTA NIESPERSONALIZOWANA funkcjonalność aplikacji Aplikacja karty niespersonalizowanej musi umożliwiać wydanie karty bez konieczności pozyskania danych osobowych. Niniejsza aplikacja, pracująca w ramach Systemu Biletu Metropolitalnego pozwoli na wydawanie kart wyłącznie o funkcji e- portmonetka. W momencie wydawania karty użytkownik określi zakres niezbędnych usług, z których będzie korzystał. 43

44 Karta niespersonalizowana jest ważna do 10 lat od momentu wydania lub na okres zadeklarowany w momencie zakupu karty. Doładowanie karty niespersonalizowane możliwe będzie w punktach sieci sprzedaży wyposażonych w moduły do pobierania opłat i doładowywania kart/biletów W punkcie obsługi klienta POK zostanie wydana karta, na której zostaną zdefiniowane dostępne usługi dla użytkownika (deklarowane w momencie wydawania karty). Wydanie karty niespersonalizowanej będzie wiązało się z pobraniem od użytkownika kaucji o wartości określonej w regulaminie SBM, który zostanie opracowany w trakcie wdrażania projektu Portal internetowy oraz automaty wyposażone w moduły do doładowania kart muszą umożliwiać użytkownikowi kontrolę stanu środków/usług na karcie W punktach obsługi klienta POK musi być dostępna odpowiednia liczba kart niespersonalizowanych przygotowanych wcześniej. Karty niespersonalizowane mogą funkcjonować również w oparciu o konta użytkowników. Karty te mogą funkcjonować w oparciu o wszystkie typy kont użytkowników (indywidualne, rodzinne, firmowe). Wówczas konieczne jest podanie niezbędnych danych do utworzenia konta. Dane te figurują wyłącznie w systemie, nie ma konieczności zapisywania ich na nośniku. Karta niespersonalizowana może być dołączona do istniejącego już konta Aplikacja WELCOME CARD funkcjonalność aplikacji Aplikacja karty Welcome Card, dedykowanej dla turystów i gości obszaru metropolitalnego, musi umożliwiać definiowanie konfiguracji różnego rodzaju usług wraz z określeniem ścisłych parametrów ich obowiązywania (termin ważności, oraz miejsc upoważniających do skorzystania). Definiowanie tych usług możliwe jest na poziomie zarządzającego (administratora) Przewidywane jest łączenie usług transportu publicznego z usługami o charakterze kulturalnym, sportowym itp. Przykładowe konfiguracje usług pokazano na rysunku - Rysunek Aplikacja musi umożliwiać tworzenie kart o charakterze regionalnym (metropolitalnym) oraz wyłącznie dla miast (Toruń, Bydgoszcz) Karty te wydawane będą jako niespersonalizowane i spersonalizowane Wprowadzenie danych osobowych na kartę będzie realizowane jedynie w przypadku, gdy wymóg taki będzie wynikał z przepisów szczegółowych dotyczących np. imprez sportowych Nabycie karty musi być możliwe w punktach obsługi klienta, na lotnisku, na dworcach kolejowych oraz w punktach informacji turystycznej (oferty przygotowane wcześniej np. dla danej imprezy sportowej, kulturalnej) Serwis internetowy musi zawierać wszelkie informacje odnośnie oferty w zakresie Welcome Card, jak również prezentować na podkładzie mapowy miejsca, gdzie można dokonać jej zakupu. 44

45 Włączenie danej usługi w zakres funkcjonowania Welcome Card wiąże się z nabyciem przez punkt usług czytnika kart elektronicznych umożliwiającego odczytanie danych z karty bezstykowej W serwisie internetowym muszą być widoczne informacje o wszystkich usługach dostępnych dla Welcome Card i odniesione do lokalizacji na mapie Musi istnieć możliwość zamówienia danego typu kart Welcome Card poprzez serwis internetowy dedykowany dla SBM, rezerwacja internetowa karty. TYP KARTY DOSTĘPNE USŁUGI OPIS WELCOME CARD SPORT dedykowana dla zawodów sportowych kilkudniowych IMPREZA SPORTOWA USŁUGI TRANSPORTU PUBLICZNEGO Usługi podstawowe dla oferowanej karty WSTĘPY DO MUZEÓW KONCERTY TEATR Usługi dodatkowe, doładowywane do karty opcjonalnie na życzenie użytkownika.. Inne usługi WELCOME CARD KONCERT dedykowana dla imprezy typu koncert KONCERT USŁUGI TRANSPORTU PUBLICZNEGO Usługi podstawowe dla oferowanej karty.. Inne usługi WELCOME CARD WEEKEND dedykowana dla turystów i gości USŁUGI TRANSPORTU PUBLICZNEGO WSTĘPY DO MUZEÓW Definiowana lista muzeów, możliwość wyboru kilku w ofercie REGION WELCOME CARD dedykowana dla turystów i gości TEATR KONCERTY Wieczór w teatrze, koncert w Operze lub Filharmonii REGION FAMILY WELCOME CARD dedykowana dla rodzin KAWIARNIA/RESTAURACJA/PUB Zniżki na usługi w punktach gastronomi.. Inne usługi Rysunek 16 Przykładowe konfiguracje dla Welome Card Aplikacja LEGITYMACJA STUDENCKA (ELS) funkcjonalność aplikacji Aplikacja elektronicznej legitymacji studenckiej ELS musi umożliwiać doładowanie elektronicznej legitymacji studenckiej wydawanej przez uczelnie wyższe. Rozpoczęcie procesu doładowywania elektronicznych legitymacji studenckich może nastąpić jedynie na podstawie umowy między daną uczelnią wyższą a instytucją zarządzającą systemem biletu metropolitalnego na terenie bydgosko toruńskiego obszaru metropolitalnego. Projekt takiej umowy przygotuje wykonawca. Umowa musi 45

46 zobowiązywać uczelnię wyższą do natychmiastowego przekazania informacji o skreśleniu osoby z listy studentów. Elektroniczna legitymacja studencka musi być dokumentem zgodnym z rozporządzeniem Ministra Nauki i Szkolnictwa Wyższego z dnia 2 listopada 2006r. w sprawie dokumentacji przebiegu studiów (Dz. U Nr 224, poz. 1634) Wszelkie parametry kart muszą być zgodne z załącznikiem nr 3 do w/w rozporządzenia. Bazą Legitymacji studenckiej e-student musi być karta bezstykowa Zakres usług dostępnych dla elektronicznych legitymacji studenckich będzie uzależniony od typu zastosowanej karty oraz jej możliwości funkcjonalnych Podstawową usługą dedykowaną dla kart ELS jest usługa transportu publicznego (kodowanie biletów okresowych) Kodowanie elektronicznych legitymacji studenckich będzie odbywało się w punktach obsługi klienta według procedury określonej dla kodowania kart spersonalizowanych. Kodowanie kart ELS usługami w ramach SBM będzie możliwe dopiero po odblokowaniu karty przez jej wydawcę (uczelnia wyższa). W ramach niniejszej aplikacji będzie automatycznie tworzone konto użytkownika karty ELS Aplikacja OBSŁUGA INTERNETOWA UŻYTKOWNIKA funkcjonalność aplikacji Aplikacja obsługa internetowa użytkownika będzie służyła obsłudze indywidualnych kont użytkowników funkcjonujących w ramach projektu systemu biletu metropolitalnego na obszarze bydgosko toruńskiego obszaru metropolitalnego. Aplikacja musi umożliwiać: a) tworzenie profilu użytkownika do indywidualnego, rodzinnego i firmowego konta użytkownika, dla obsługi posiadanych kart, b) pozyskiwaniu informacji o dostępnych kartach, w tym stanie konta, okresach ważności, danych osobowych, wgląd w historię operacji, itp. c) doładowanie kart przez Internet, d) zakup biletów przez Internet, e) zakup biletów przez telefon komórkowy, f) składanie różnego rodzaju wniosków do POK (wydanie karty, zmiany danych osobowych, zablokowaniu karty itp.) Aplikacja musi być dostępna również na urządzenia mobilne takie jak telefony komórkowe, smartfony i palmtopy oraz musi zapewniać łatwy dostęp dla osób niedowidzących i niewidomych (usługa głosowa) Utworzenie profilu użytkownika (pierwsze logowanie) w portalu internetowym (wykonywane przez użytkownika) powinno odbywać się na podstawie numeru konta użytkownika (nadanego w POK) oraz podania hasła (imię i nazwisko użytkownika). Dalsze użytkowanie konta musi umożliwić logowanie do konta na podstawie numeru konta użytkownika oraz wymyślonego przez użytkownika hasła (co najmniej 10 znaków - litery i cyfry). Użytkownik po zalogowaniu do konta użytkownika musi mieć możliwość przeglądania informacji w zakresie dostępnych kart, składania wniosków itp Aplikacja ZARZĄDZANIE KONTAMI I KARTAMI UŻYTKOWNIKÓW. 46

47 Realizowanie usługi związanej z wydaniem danego typu karty wiąże się automatyczne z utworzeniem konta użytkownika. Konto użytkownika będzie utworzone przez pracownika POK na etapie tworzenia karty Przewiduje się wprowadzenie, w formularzu umowy dotyczącej użytkowania karty spersonalizowanej, niespersonalizowane, elektronicznej legitymacji studenckiej, zapisów dotyczących utworzenia konta i wynikających z tego tytułu uprawnień Konto użytkownika przeznaczone jest do obsługi jednej lub wielu kart. System musi umożliwiać przypisywanie kilku kart do jednego konta. System nie może umożliwiać funkcjonowania jednej karty na więcej niż jednym koncie W przypadku rejestrowania karty użytkownika niepełnoletniego, wydana karta zostanie przypisana do konta wskazanego przez opiekuna. System musi umożliwiać utworzenie trzech rodzajów kont: a) indywidualne, b) rodzinne, c) firmowe Konta wymienione w punktach b) i c) są nazywane kontami grupowymi. Konta indywidualne przeznaczone są dla obsługi jednej karty. Konta rodzinne i firmowe muszą umożliwiać dołączenie wielu kart użytkowników. Aplikacja musi umożliwiać, na wniosek użytkownika, przejście z konta indywidualnego na konto rodzinne i odwrotnie. Konto firmowe dedykowane jest wyłącznie dla firm i instytucji. Karty przypisane do kont użytkowanych indywidualnie i rodzinnie mogą być kartami spersonalizowanymi, niespersonalizowanymi, elektroniczną legitymacją studencką (ELS) oraz Bydgoską Kartą Miejską z funkcjonalnością e-bilet. Karty przypisane do kont firmowych mogą być kartami spersonalizowanymi lub niespersonalizowanymi. Konta użytkowników nie obejmują rejestrowania kart typu Welcome Card Aplikacja musi umożliwić przeszukiwanie (filtrowanie) kont użytkowników według następujących parametrów dotyczących kont oraz kart: a) typ konta, b) numer konta, c) właściciel konta, d) numer karty, e) typ karty, f) dane użytkownika karty, g) status karty W systemie musi istnieć możliwość wyświetlenia danych liczbowych odnośnie liczby funkcjonujących kont z podziałem na typ konta, liczby funkcjonujących kart z podziałem na typy kart. Numeracja kont użytkowników powinna zawierać liczbę o co najmniej 7 znakach. Możliwe jest wprowadzenie zakresu numerów dla poszczególnych typów kont. Na przykład: a) Od numeru do numeru konta indywidualne, b) Od numeru do numeru konta rodzinne, c) Od numeru do numeru konta firmowe. 47

48 Przykładowe rozwiązanie aplikacji przedstawiono na rysunku - Rysunek Punkt obsługi klienta musi być wyposażony w czytnik, który umożliwi odczytanie kart i przekazanie informacji do aplikacji zarządzanie kontami i kartami użytkowników. Aplikacja pokaże, do którego konta przypisana jest dana karta Aplikacja musi prezentować wszelkie informacje odnośnie funkcjonujących kart wraz z podaniem ich status, na przykład: a) użytkowana (karta użytkowana zgodnie z jej przeznaczeniem), b) nie użytkowana (w przypadku wykorzystania usług zdefiniowanych na karcie i przekroczenia określonego w regulaminie kolejnego terminu doładowania np. kwartał dla biletów okresowych), c) zablokowana (karta zablokowana z tytułu nadużyć lub z powodu zagubienia - zgłoszenie użytkownika, lub karta dostarczona do POK przez znalazcę), d) wycofana z użytkowania (karta wycofana z użytkowania wprowadzona jest do rejestru archiwalnego kart) Aplikacja musi automatycznie zmieniać status karty z użytkowana (po przekroczeniu określonego w regulaminie terminu doładowania) na nie użytkowana. Aplikacja musi umożliwiać również sytuację odwrotną tzn. w przypadku doładowania karty po długim okresie jej nie użytkowania, zapewnia automatyczne przejście w status użytkowana Aplikacja musi prezentować historię statusu karty Aplikacja musi umożliwiać aktualizację danych osobowych użytkowników. Aktualizacja danych osobowych dotyczy kart spersonalizowanych i elektronicznych legitymacji studenckich ELS. W każdym przypadku aktualizacji danych będzie można dokonać w dowolnym punkcie POK. W przypadku aktualizacji danych wydrukowanych bezpośrednio na karcie będzie wiązało się toz wymianą karty. W przypadku aktualizacji pozostałych danych musi istnieć możliwość zmiany danych w pamięci karty bez wymiany karty, aktualizacja wykonana na miejscu w POK. Zmiana danych osobowych może odbyć się po uprzednim złożeniu wniosku w POK. Wniosek może być złożony osobiście lub przez pełnomocnika. 48

49 APLIKACJA TYP KONTA NUMER KONTA WŁAŚCICIEL KONTA KARTY PRZYPISANE DO KONTA TYP KARTY DANE UŻYKOWNIKA KONTA UŻYTKOWNIKÓW INDYWIDUALNE konto nr JAN NOWAK karta nr SPERSONALIZOWANA JAN NOWAK, dane użytkownika. RODZINNE konto nr FIRMOWE konto nr JAN KOWALSKI karta nr SPERSONALIZOWANA konto nr konto nr karta nr karta nr E-STUDENT NIESPERSONALIZOWANA JAN KOWALSKI, dane użytkownika..... konto nr konto nr konto nr URZĄD MIASTA BYDGOSZCZY GMINA MIASTA TORUŃ KUJAWSKO-POMORSKI URZĄD MARSZAŁKOWSKI karta nr karta nr karta nr NIESPERSONALIZOWANA NIESPERSONALIZOWANA NIESPERSONALIZOWANA NIESPERSONALIZOWANA URZĄD MIASTA BYDGOSZCZY WYDZIAŁ MIENIA I GEODEZJI STATUS KARTY ZABLOKOWANA URZĄD MIASTA BYDGOSZCZY WYDZIAŁ Rysunek 17 Aplikacja Konta użytkowników przykładowe rozwiązanie. 49

50 Aplikacja BLOKOWANIE/ODBLOKOWANIE KARTY Aplikacja musi umożliwiać blokowanie i odblokowywanie kart. Blokowanie kart może nastąpić z uwagi na: a) wykrycie przez administratora systemu nadużyć przez użytkownika karty lub osobę, która pozyskała kartę w sposób nielegalny; przez nadużycie należy rozumieć użytkowanie karty w sposób niezgodny z regulaminem użytkowania kart, b) zgłoszenie zagubienia karty przez jej użytkownika, możliwe jest zablokowanie karty w punkcie POK lub przez konto użytkownika, na podstawie oświadczenia użytkownika (przygotowanie wzoru oświadczenia jest po stronie wykonawcy) oraz przedstawienia dowodu tożsamości w przypadku zgłoszenia dokonanego w POK, c) dostarczenia karty przez znalazcę do punktu POK; karta zostaje zablokowana z jednoczesnym powiadomieniem jej użytkownika przez konto użytkownika oraz wysłanie listu poleconego za potwierdzeniem odbioru Blokowanie, na wniosek użytkowników, kart niespersonalizowanych i Welcome Card może nastąpić jedynie w punkcie POK po uprzednim okazaniu dowodu zakupu karty Blokowanie elektronicznej legitymacji studenckiej (ELS) dotyczy wyłącznie usług realizowanych w ramach systemu biletu metropolitalnego dla bydgosko toruńskiego obszaru metropolitalnego. Całkowita blokada karty możliwa jest jedynie przez uczelnię wyższą, która wydała kartę W przypadku zablokowania karty przez administratora systemu z tytułu nadużyć, automatycznie blokowane jest konto użytkownika karty oraz wysyłane jest powiadomienie do użytkownika w formie listu poleconego za potwierdzeniem odbioru (na adres wskazany we wniosku). W przypadku nadużyć dla karty ELS powiadamiane są również władze uczelni. System musi zawierać gotowe wnioski i powiadomienia służące niniejszej aplikacji. Wykonawca przygotuje i przedstawi do uzgodnienia zamawiającemu wzory wniosków i powiadomień Odblokowanie karty może nastąpić jedynie w punkcie POK po wcześniejszym złożeniu wniosku. Wykonawca przedstawi do uzgodnienia zamawiającemu listę procedur w zakresie odblokowywania kart. Sposoby postępowania (procedury) będą uzależnione od przyczyny zablokowania kart. Procedury te, zawarte bezpośrednio w systemie, będą w sposób automatyczny (step by step) określały czynności, jakie musi wykonać operator w punkcie POK Aplikacja GENEROWANIE WYKAZU OPERACJI NA KARCIE Aplikacja musi umożliwiać odczyt operacji wykonywanych na kartach. Odczyt operacji wykonanych na kartach możliwy będzie w POK, za pośrednictwem operatora, lub poprzez stronę internetową (bezpośrednio przez użytkownika) logując się do konta użytkownika Operator, w punkcie POK, po przedstawieniu przez użytkownika karty wraz z dowodem osobistym musi mieć możliwość odczytania operacji na karcie Aplikacja musi umożliwiać stworzenie raportu dotyczącego wszelkich operacji wykonywanych na karcie. Aplikacja musi umożliwiać różny sposób prezentowania 50

51 danych. Na przykład: prezentowanie listy kolejno następujących po sobie operacji w zadanym okresie czasowym (lub okresach), wybór operacji w zakresie rodzaju usługi (transport publiczny, basen, itp.) w zadanym okresie czasowym itp Aplikacja musi umożliwić zapis stworzonego raportu jako dokumentu elektronicznego nie wymagającego podpisu oraz jego natychmiastowy wydruk. Należy przyjąć format pliku pdf. W stworzonym raporcie muszą być prezentowane dane dotyczące karty i jej właściciela Przykład zawartości niniejszej aplikacji oraz raportu przedstawiono na rysunkach - Rysunek 18, Rysunek 19. RAPORT OPERACJI NA KARCIE NR STR 1 MIEJSCE SPORZĄDZENIA RAPORTU OSOBA SPORZĄDZAJĄCA RAPORT DATA SPORZĄDZENIA RAPORTU NR RAPORTU DANE UŻYTKOWNIKA DANE UŻYTKOWANEJ KARTY WYKAZ OPERACJI OKRES RAPORTOWANIA NR DATA OPERACJI GODZINA OPERACJI KOSZT OPERACJI OPIS OPERACJI ,6 ZŁ zakup biletu jednorazowego, linia nr ZŁ zakup biletu jednorazowego BiT City ,6 ZŁ zakup biletu jednorazowego BiT City ZŁ zakup biletu jednorazowego, linia nr wejście usługa, basen 1 wejście.. BILANS ŚRODKÓW TRANSPORT PUBLICZNY STAN KONTA 12 ZŁ TERMIN WAŻNOŚCI USŁUGI - BASEN STAN KONTA 5 wejść TERMIN WAŻNOŚCI Rysunek 18 Aplikacja Generowanie wykazu operacji przykładowe rozwiązanie raportu. 51

52 STWORZENIE RAPORTU WYDRUK RAPORTU AUTOMATYCZNY ODCZYT DANYCH KARTY PO ODCZYTANIU PRZEZ CZYTNIK KART W POK OKREŚLENIE TERMINU RAPORTU TERMIN RAPORTOWANIA POCZĄTEK KONIEC WYBÓR ZAKRESU USŁUG DO RAPORTU nr karty DANE UŻYTKOWNIKA I UŻYTKOWANEJ KARTY wybór na podstwie dat zawartych w kalendarzu bieżący tydzień bieżący miesiąc miesiąc kwartał rok wszystkie operacje transport publiczny basen muzea Park & Ride. PLIK DRUKARKA nr karty nr konta login nazwa/numer użytkownika SERWIS INTERNETOWY Rysunek 19 Aplikacja Generowanie wykazu operacji przykładowe rozwiązanie. 52

53 Aplikacja REKLAMACJE Aplikacja Reklamacje musi umożliwiać przyjmowanie reklamacji zarówno w transporcie publicznym, jak i dla wszelkich usług dostępnych w ramach systemu Aplikacja musi umożliwiać przyjmowanie reklamacji poprzez serwis internetowy oraz bezpośrednio w punktach obsługi klienta POK Zgłoszenie reklamacji jest każdorazowo ewidencjonowane poprzez założenie karty reklamacji. Reklamacja będzie przypisana do konta użytkownika oraz do danej karty Aplikacja musi umożliwiać dołączenie zeskanowanego wniosku reklamacyjnego lub bezpośrednie dołączenie wniosku przesłanego za pośrednictwem strony internetowej. Zgłoszenie reklamacji za pośrednictwem strony internetowej musi umożliwiać wstępne zdefiniowanie przez użytkownika typu reklamacji Typy reklamacji zostaną ustalone przez wykonawcę systemu. Każdy typ reklamacji musi posiadać określoną procedurę usuwania błędów i usterek Aplikacja musi umożliwiać ewidencję reklamacji oraz pozyskiwanie informacji o etapie ich rozpatrywania. Funkcja ta musi być dostępna w serwisie internetowym dla użytkowników kont W celu ułatwienia zarządzania procesem reklamacji wykonawca zobowiązany jest do usystematyzowania zgłoszeń reklamacyjnych oraz wdrożenia automatycznego skierowywania zgłoszeń do odpowiedniej komórki zespołu zarządzającego systemem Aplikacja WYDAWANIE DUPLIKATÓW KART Wydanie duplikatu karty obywa się na podstawie wniosku złożonego bezpośrednio w POK lub poprzez serwis internetowy Wykonawca przygotuje i przedstawi do zatwierdzenia zamawiającemu odpowiedni wzór wniosku Wydanie karty możliwe jest wyłącznie w POK System musi uniemożliwiać wydanie duplikatu karty zablokowanej z tytułu nadużyć System musi zapewniać powiązanie danych osobowych z zablokowanymi kartami. Operator wpisując do systemu dane osobowe użytkownika (imię i nazwisko, numer PESEL) ubiegającego się o duplikat karty musi otrzymać z systemu informację o wszystkich kartach będących w dyspozycji użytkownika oraz o ich statusie. W przypadku stwierdzenia blokady karty z tytułu różnego rodzaju nadużyć muszą istnieć procedury określające sposób postępowania w zakresie odblokowywania kart (patrz aplikacja Blokowanie/Odblokowanie karty). W przypadku braku stwierdzenia przez operatora wcześniejszej blokady karty operator wydaje kopię karty z nowym numerem identyfikacyjnym. Kartę duplikowaną blokuje w systemie i archiwizuje. System musi umożliwiać wydanie pełnego duplikatu karty wraz z wszelkimi usługami, które zostały wcześniej zakupione i o ile nie utraciły ważności Duplikaty kart: niespersonalizowanej, Welcome Card mogą zostać wydane jedynie w przypadku okazania przez użytkownika dowodu tożsamości wraz z dowodem zakupu karty. 53

54 W przypadku zagubienia elektronicznej legitymacji studenckiej e-student, duplikat karty wydaje uczelnia wyższa lub podmiot działający w jej imieniu. W tym przypadku musi istnieć możliwość przywrócenia usług zakodowanych wcześniej na kartę e- student. System musi umożliwiać przypisanie opłaconych wcześniej usług na ELS w punkcie POK, o ile nie utraciły ważności Wydanie duplikatu karty oraz odtworzenie zakodowanych wcześniej usług wiąże się z dodatkowymi opłatami manipulacyjnymi, które zostaną ustalone na etapie tworzenia systemu Aplikacja DOŁADOWANIE KARTY Aplikacja doładowanie karty musi umożliwiać doładowanie karty określoną przez użytkownika ilością punktów przejazdowych. Graniczna wartość doładowania (minimalna oraz maksymalna) zostanie określona odgórnie (przez zarządzającego) na etapie konfigurowania systemu System musi umożliwiać zarządzającemu dowolne konfigurowanie wartości doładowań na przykład: 10 punktów, 15 punktów, 50 punktów, itp do wartości granicznej Doładowanie karty musi być możliwe w punktach POK, w stacjonarnych automatach umożliwiających doładowanie kart oraz poprzez serwis internetowy System musi uniemożliwiać doładowanie kart zablokowanych Doładowanie karty będzie możliwe po wcześniejszej wpłacie przez użytkownika określonej kwoty na konto SBM. W przypadku doładowania konta przez Internet, aktualizacja stanu karty możliwa będzie w urządzeniach posiadających funkcję pobierania opłat np. kasownik w autobusie, automat do doładowania kart, lub bezpośrednio w POK. W tym przypadku nie przewiduje się wprowadzenia aktualizacji stanu konta przez czytnik kontrolera. Automaty do doładowywania kart muszą posiadać funkcję pobierania opłat. Automaty muszą umożliwiać pobieranie opłat gotówkowych oraz z elektronicznych kart bankowych Aplikacja SPRZEDAŻ BILETU OKRESOWEGO DLA TRANSPORTU PUBLICZNEGO Aplikacja sprzedaży biletu okresowego dla transportu publicznego musi umożliwiać zakodowanie na karcie biletu okresowego, wybranego spośród zdefiniowanych wcześniej przez zarządzającego systemem Bilet okresowy można doładować w punktach POK, w stacjonarnych automatach umożliwiających doładowanie kart oraz poprzez serwis internetowy System musi uniemożliwiać doładowanie kart zablokowanych Doładowanie karty biletem okresowym będzie możliwe po wcześniejszej wpłacie przez użytkownika określonej kwoty na konto SBM. W przypadku zakupu biletu okresowego przez Internet, aktualizacja stanu karty możliwa będzie w urządzeniach posiadających funkcję opłat kodowania biletów okresowych np., biletomat stacjonarny lub mobilny, czytnik kontrolera, lub bezpośrednio w POK. 54

55 W przypadku doładowania karty biletem okresowym n-dniowym (np. 30-dniowy) przez Internet, wykonawca zaproponuje okres z jakim wyprzedzeniem należy dokonać zakupu biletu by był on widoczny w systemie (np. 24 h) Aplikacja ZARZĄDZANIE USŁUGAMI Aplikacja zarządzanie usługami musi umożliwiać dodawanie różnego rodzaju usług, konfigurowanie ich wszelkich parametrów oraz wzajemnych powiązań wraz z przypisywaniem do konkretnych typów kart Aplikacja musi umożliwiać wprowadzenie następujących rodzajów usług: a) sport, b) imprezy kulturalne, c) zwiedzanie, d) parkowanie, e) wypożyczalnie, f) gastronomia, g) handel, h) imprezy sportowe, i) inne Każdy rodzaj usługi zostanie podzielony na różnego rodzaju typy usług np.: sport (basen, fitness, itp.), imprezy kulturalne (filharmonia, opera, teatr, itp.), zwiedzanie (muzea, wystawy, itp.) Aplikacja musi umożliwiać korekty i zmiany parametrów usług, okresowe zablokowanie i wycofywanie. Dla każdej usługi musi istnieć możliwość utworzenia karty usługi wraz z niepowtarzalnym numerem identyfikacyjnym i możliwością przypisania zeskanowanej umowy pomiędzy dostawcą usługi a zarządzającym SBM Przykładowe rozwiązanie aplikacji dla zarządzania usługami przedstawiono na rysunku - Rysunek 20. Na rysunku przedstawiono również przykładowy wzór karty usług. Dostępne usługi muszą być widoczne w systemie dla urządzeń doładowujących karty. Użytkownik wybiera zakres usług, które chce przypisać do użytkowanej karty Karty funkcjonujące w ramach SBM muszą być honorowane na dwa sposoby: a) płatność, b) udzielanie zniżki (rabat) Każda jednostka, która zostanie włączona do systemu wyposażona zostanie w terminal zbliżeniowy. Komunikacja terminala z serwerem systemu musi być możliwa na dwa sposoby: a) Internet, b) sieć GSM W systemie a za jego pośrednictwem w terminalu zostanie zdefiniowany rodzaj usługi oraz sposób honorowania karty (płatność, rabat) Działanie modułu w przypadku płatności: 55

56 a) posiadacz karty, chcąc skorzystać z usługi (np. muzeum) dokonuje płatności za pośrednictwem terminala, na tej podstawie otrzymuje bilet (prawo wstępu, usługę, itd.), b) opłata zostaje pobrana z karty (e-portmonetki), c) operacja zostaje zapisana w systemie, d) na podstawie danych w systemie następuje rozliczenie między Administratorem SBM a usługodawcą, e) wysokość opłaty za usługę jest definiowana w systemie a za jego pośrednictwem w terminalu. Musi istnieć możliwość, dla pojedynczej usługi, zdefiniowania co najmniej dziesięciu wysokości opłat. Oznacza to, że dla jednej usługi (np. koncert) można określić dziesięć różnych rodzajów biletów (wysokości opłat). Wybór rodzaju biletu musi być możliwe bezpośrednio przed zbliżeniem karty poprzez naciśnięcie jednego przycisku z klawiatury. Naciśnięcie przycisku z klawiatury spowoduje pojawienie się na ekranie terminala tekstu z informacją o wysokości opłaty i rodzaju biletu (np. 25,00zł - zniżka studencka, 50,00 bilet normalny, itd.), f) terminal musi mieć możliwość pobrania opłaty za dowolną liczbę biletów za pomocą pojedynczego zbliżenia. Oznacza to, że jeśli posiadacz karty zechce kupić trzy bilety normalne i cztery ulgowe, musi istnieć możliwość wprowadzenia takiej opcji w terminalu a następnie dokonanie płatności za pomocą pojedynczego zbliżenia, g) musi istnieć możliwość zaprogramowania w systemie a za jego pośrednictwem w terminalu okresu, w którym za daną usługę można płacić kartą, h) rozliczenie z usługodawcą następować będzie wg zasad określonych odrębną umową, która określać będzie podział wpływów między administratorem systemu a usługodawcą, i) jeśli strony (administrator systemu i usługodawca) ustaliły, że posiadacz karty otrzymuje jednocześnie rabat, uwzględnia się to w cenach biletów wprowadzonych do systemu i za jego pośrednictwem do terminala, j) w systemie musi istnieć możliwość bieżącego śledzenia płatności dokonanych za pomocą poszczególnych terminali, podglądu danych z dowolnego okresu, oraz generowania raportów, k) raport musi zawierać co najmniej (wzór raportu przedstawiono na rysunku - Rysunek 23): nazwę usługodawcy, dane terminala, wykaz dokonanych płatności z uwzględnieniem ich wysokości, daty i godziny dokonania płatności, podsumowanie poszczególnych rodzajów biletów i podsumowanie całkowite Wzór raportu z uwzględnieniem rabatów pokazano na rysunku - Rysunek Działanie modułu w przypadku udzielania rabatu (ulgi): a) posiadacz karty, chcąc z korzystać z usługi (np. muzeum) dokonuje zbliżenia karty do terminala (zaewidencjonowanie rabatu), na tej podstawie otrzymuje bilet (prawo wstępu, usługę, itd.), za który wnosi opłatę w inny sposób (nie Kartą Metropolitalną) z uwzględnieniem rabatu, b) operacja zostaje zapisana w systemie, c) na podstawie danych w systemie następuje rozliczenie między Administratorem systemu a usługodawcą, d) wysokość opłat i rabatów za usługę jest definiowana w systemie a za jego pośrednictwem w terminalu. Musi istnieć możliwość, dla pojedynczej usługi, zdefiniowania co najmniej dziesięciu wysokości rabatów. Oznacza to, że dla jednej usługi (np. koncert) można określić dziesięć różnych rodzajów biletów i przypisanych 56

57 im rabatów. Wybór rodzaju biletu i rabatu musi być możliwy bezpośrednio przed zbliżeniem karty poprzez naciśnięcie jednego przycisku z klawiatury. Naciśnięcie przycisku z klawiatury spowoduje pojawienie się na ekranie terminala tekstu z informacją o wysokości udzielanego rabatu i rodzaju przysługującego biletu, e) terminal musi mieć możliwość pobrania dowolnej liczby rabatów za pomocą pojedynczego zbliżenia. Oznacza to, że jeśli posiadacz karty zechce kupić trzy bilety normalne i cztery ulgowe, musi istnieć możliwość wprowadzenia takiej opcji w terminalu a następnie odnotowanie wysokości udzielonych rabatów za pomocą pojedynczego zbliżenia, f) musi istnieć możliwość zaprogramowania w systemie a za jego pośrednictwem w terminalu okresu, w którym za daną usługę można otrzymywać rabat płacąc kartą, g) rozliczenie z usługodawcą następować będzie wg zasad określonych odrębną umową, h) w systemie musi istnieć możliwość bieżącego śledzenia udzielanych rabatów przez poszczególne terminale, podglądu danych z dowolnego okresu, oraz generowania raportów, i) wzór raportu udzielonych rabatów (gdy na podstawie Karty Metropolitalnej można tylko uzyskać rabat) pokazano na rysunku - Rysunek Współpraca terminala systemu z urządzeniami (terminalami, kasami) usługodawcy musi być możliwa na następujące sposoby (zarówno w zakresie płatności jak i otrzymania rabatu): a) płatność za pośrednictwem terminalu systemu (terminal systemu nie ma połączenia z terminalem usługodawcy), bilet wydaje terminal usługodawcy, b) płatność za pośrednictwem terminalu usługodawcy (terminal systemu ma połączenie z jednym terminalem usługodawcy) zbliżenie karty następuje w terminalu systemu, c) płatność za pośrednictwem terminalu usługodawcy (terminal systemu ma połączenie z jednym terminalem usługodawcy) zbliżenie karty następuje w terminalu usługodawcy, d) płatność za pośrednictwem wielu terminali usługodawcy (terminal systemu ma połączenie z każdym terminalem usługodawcy) zbliżenie karty następuje w terminalu usługodawcy. 57

58 ZARZĄDZANIE USŁUGAMI RODZAJE USŁUG ZADANIE TYPY USŁUG KARTA USŁUG numer kolejny usługi, przypisanie umowy zawartej z partnerem Definiowanie/zmiana parametrów usług Wycofywawnie/blokowanie usług Lista dostępnych usług Sport Imprezy kulturalne Zwiedzanie Sport Imprezy kulturalne Zwiedzanie Parkowanie Wypożyczalnie Gastronomia Handel Definiowanie usług i ich parametrów Zmiana parametrów zdefiniowanych usług Baseny Fitness Golf. Baseny Fitness Golf TYP USŁUGI Nazwa usługi Lokalizacja Przeznaczenie Powiązanie Użytkownicy Ulgi Termin dostępnosci Parametry BASENY Basen przy Szkole Podstawowej nr ul. Duracza 20, Bydgoszcz Wybór typu karty Wybór innych usług Wybór użytkowników określenie ulgi start end koszt 100 zł bez dodatkowych kosztów w powiązaniu z typami kart liczba 12 wejść muzea teatr.. typ karty Karta niespersonalizowana Karta spersonalizowana Karta e-student Karta Welcome Card możliwe przypisanie kilku opcji Parkowanie Wypożyczalnie Gastronomia Handel Imprezy sportowe Katalog usług Baseny Fitness Golf.. Filharmonia Teatr Imprezy sportowe. Baseny dostępne w ofercie Basen przy ul. Gałczyńskiego w Bydgoszczy Basen przy ul. Bydgoskiej w Toruniu Basen przy ul. Toruńskiej w Solcu Kujawskim... status usługi aktywna aktywna zablokowana usługa wycofana Basen przy Szkole Podstawowej nr Astoria Basen przy Zespole Szkół nr określenie terminu dostępności określenie terminu wycofania bez ograniczeń studenci emeryci Welcome Card Sport Region Familly Welcome Card możliwe przypisanie kilku opcji typ karty Welcom card Welcome Card Sport Welcome Card Koncert Welcome Card Weekend Region Welcome Card Region Familly Welcome Card możliwe przypisanie kilku opcji lista dostępnych usług Opera.. Muzea dostępne w ofercie status usługi określenie terminu dostępności Muzea Muzeum im. Wyczółkowskiego w Bydgoszczy aktywna Wystawy Muzeum DAG w Bydgoszczy zablokowana Muzeum Okręgowe w Toruniu usługa wycofana do odwołania.. Rysunek 20 Aplikacja Zarządzanie usługami przykładowe rozwiązanie. 58

59 EWIDENCJA I WYSZUKIWANIE KART TYP KARTY STATUS KARTY Ewidencja kart Spersonalizowane Wszystkie Wyszukiwanie kart Niespersonalizowane Użytkowane Wszystkie Kalendarz Elektroniczna legitymacja studencka ELS Nieużytkowane Wydane w zdefiniowanym okresie Wydane w danym roku PODAJ DANE OSOBOWE Welcome Card Wycofane Wydane w danym kwartale RAPORT Wszystkie Zablokowane Wydane w danym miesiącu raport ogólny nr Nazwisko i imię Wyszukaj TYP KARTY WELCOM CARD Welcome Card Sport ` Wszystkie Statystyka wydanych kart typ karty status kart liczba Spersonalizowane Użytkowane Numer PESEL Numer karty lista kart będąca w posiadaniu wskazanej osoby Welcome Card Koncert Welcome Card Weekend Użytkowane Nieużytkowane wydane bieżący miesiąc PODGLĄD WYBRANEJ KARTY Welcome Card Region Wycofane Wszystkie Kalendarz Wszystkie Zablokowane Zablokowane w zdefiniowanym okresie Zablokowane w danym roku Zablokowane w danym kwartale Zablokowane w danym miesiącu RAPORT raport ogólny nr Statystyka wydanych kart typ karty status kart liczba Welcome Card Sport Zablokowane 2 wydane bieżący miesiąc Rysunek 21 Aplikacja Ewidencja i wyszukiwanie kart przykładowe rozwiązanie. 59

60 Aplikacja EWIDENCJA I WYSZUKIWANIE KART Aplikacja Ewidencja i wyszukiwanie kart musi umożliwiać odczytanie danych z bazy danych i przedstawienie raportu - ewidencji kart w podziale na różne kategorie np. typy oraz status wydanych kart Aplikacja musi umożliwiać wyszukiwanie danej karty oraz grupy kart wrazz podawaniem danych statystycznych w określonych wcześniej grupach Aplikacja musi umożliwiać wyszukiwanie określonej karty na podstawie danych osobowych, numeru PESEL lub numeru karty Aplikacja musi umożliwiać prezentowanie informacji dla wyszukanej karty. Przykładowe rozwiązanie aplikacji przedstawiono na rysunku - Rysunek Aplikacja STATYSTYKA Aplikacja musi umożliwiać tworzenie statystyki w zakresie sprzedaży wszystkich usług (transport publiczny i inne) dla wybranego okresu (statystyka sprzedaży usług) Musi być możliwość tworzenia raportów sprzedaży usług (transport publiczny) w zestawieniu ogólnym oraz szczegółowym. Przykładowe rozwiązanie aplikacji przedstawiono na rysunkach - Rysunek 22, Rysunek 23, Rysunek 24, Rysunek

61 STATYSTYKA TYP USŁUGI OBSZAR OBOWIĄZYWANIA TRANSPORT PUBLICZNY BIT CITY USŁUGI BIT CITY + BYDGOSZCZ + TORUŃ BIT CITY + BYDGOSZCZ TYP BILETU BILET BIT CITY + TORUŃ BILETY OKRESOWE PARAMETR WYSZUKIWANIA BYDGOSZCZ BILETY N-PRZEJAZDOWE Bydgoszcz, bilet 30-dniowy, cała sieć Wszystkie Kalendarz Bydgoszcz, bilet 90-dniowy, cała sieć Sprzedane w zdefiniowanym okresie BYDGOSZCZ + GMINY OŚCIENNE BILETY JEDNORAZOWE Bydgoszcz, bilet 90-dniowy, cała sieć Sprzedane w bieżącym roku TORUŃ TORUŃ + GMINY OŚCIENNE WSZYSTKIE BILETY PRZYPISANE DO KART SPECJALNYCH WELCOM CARD WSZYSTKIE PARAMETR WYSZUKIWANIA Sprzedane w bieżącym kwartale Wszystkie Raport ogólny nr Transport publiczny Sprzedane w bieżącym miesiącu Bydgoszcz 0001 Bilet okresowy Statystyka usług zakupionych na kartach okres analizy bieżący miesiąc bilet liczba wartość jednostkowa [zł] suma [zł] bilet, 30-dniowy, cała sieć RODZAJ USŁUGI Wszystkie Kalendarz WSZYSTKIE Sprzedane w zdefiniowanym okresie Sprzedane w bieżącym roku SPORT Sprzedane w bieżącym kwartale IMPREZY KULTURALNE Sprzedane w bieżącym miesiącu RAPORT SPRZEDAŻY ZWIEDZANIE RODZAJ USŁUGI SPORT NAZWA BASENU PARAMETR WYSZUKIWANIA WSZYSTKIE Basen, przy ul. Gałczyńskiego w Bydgoszczy Wszystkie Kalendarz PARKOWANIE BASENY Basen, przy ul. Bydgoskiej w Toruniu Sprzedane w zdefiniowanym okresie WYPOŻYCZALNIE FITNESS Basen, przy ul. Toruńskiej w Solcu Kujawskim Sprzedane w bieżącym roku GOLF.. Sprzedane w bieżącym kwartale GASTRONOMIA.. WSZYSTKIE Sprzedane w bieżącym miesiącu HANDEL IMPREZY SPORTOWE.. Raport ogólny 0001 okres analizy bilet nr Zakupionych wejść jednorazowych Rzeczywistych wejść jednorazowych USŁUGI BASEN Bydgoszcz Gałczyńskiego w Bydgoszczy Statystyka usług zakupionych na kartach bieżący miesiąc wartość liczba jednostkowa [zł] suma [zł] Rysunek 22 Aplikacja Statystyka przykładowe rozwiązanie. 61

62 RAPORT Planetarium im. Władysława Dziewulskiego ul. Franciszkańska Toruń Raport nr 001 terminal: TOR-001 okres raportowania: L.p. Data Godzina Nr płatności Rodzaj biletu Wysokość opłaty Rabat Nr karty : normalny 9,00 zł 0,00 zł : ulgowy 7,00 zł 0,00 zł : normalny 9,00 zł 0,00 zł : normalny 9,00 zł 0,00 zł : ulgowy 7,00 zł 0,00 zł : ulgowy 7,00 zł 0,00 zł : ulgowy 7,00 zł 0,00 zł : łączony 13,00 zł 0,00 zł : normalny 9,00 zł 0,00 zł : ulgowy 7,00 zł 0,00 zł : normalny 9,00 zł 0,00 zł : normalny 9,00 zł 0,00 zł : seans 8,00 zł 0,00 zł : grupowy 35,00 zł 0,00 zł : grupowy 35,00 zł 0,00 zł : ulgowy 7,00 zł 0,00 zł Zestawienie zbiorcze Rodzaj biletu Liczba Liczba Wartość Wartość Cena biletu biletów płatności wpływów rabatów normalny ,00 zł 1 665,00 zł 0,00 zł ulgowy ,00 zł 784,00 zł 0,00 zł łączony ,00 zł 585,00 zł 0,00 zł seans ,00 zł 288,00 zł 0,00 zł grupowy ,00 zł 1 645,00 zł 0,00 zł ,00 zł 0,00 zł Rysunek 23 Przykładowy raport szczegółowy dla usługodawcy w ramach Karty Metropolitalnej opcja opłaty. 62

63 RAPORT Planetarium im. Władysława Dziewulskiego ul. Franciszkańska Toruń Raport nr 001 terminal: TOR-001 okres raportowania: L.p. Data Godzina Nr płatności Rodzaj biletu Wysokość opłaty Rabat Nr karty : normalny 7,50 zł 1,50 zł : ulgowy 6,00 zł 1,00 zł : normalny 7,50 zł 1,50 zł : normalny 7,50 zł 1,50 zł : ulgowy 6,00 zł 1,00 zł : ulgowy 6,00 zł 1,00 zł : ulgowy 6,00 zł 1,00 zł : łączony 10,50 zł 2,50 zł : normalny 7,50 zł 1,50 zł : ulgowy 6,00 zł 1,00 zł : normalny 7,50 zł 1,50 zł : normalny 7,50 zł 1,50 zł : seans 8,00 zł 0,00 zł : grupowy 31,00 zł 4,00 zł : grupowy 31,00 zł 4,00 zł : ulgowy 6,00 zł 1,00 zł Zestawienie zbiorcze Rodzaj biletu Liczba Liczba Wartość Wartość Cena biletu biletów płatności wpływów rabatów normalny ,50 zł 1 387,50 zł 277,50 zł ulgowy ,00 zł 672,00 zł 112,00 zł łączony ,50 zł 472,50 zł 112,50 zł seans ,00 zł 288,00 zł 0,00 zł grupowy ,00 zł 1 457,00 zł 188,00 zł ,00 zł 690,00 zł Rysunek 24 Przykładowy raport szczegółowy dla usługodawcy w ramach Karty Metropolitalnej opcja opłaty i rabaty. 63

64 RAPORT Planetarium im. Władysława Dziewulskiego ul. Franciszkańska Toruń Raport nr 001 terminal: TOR-001 okres raportowania: L.p. Data Godzina Nr płatności Rodzaj biletu Wartość Udzielony biletu rabat Nr karty : normalny 9,00 zł 1,50 zł : ulgowy 7,00 zł 1,00 zł : normalny 9,00 zł 1,50 zł : normalny 9,00 zł 1,50 zł : ulgowy 7,00 zł 1,00 zł : ulgowy 7,00 zł 1,00 zł : ulgowy 7,00 zł 1,00 zł : łączony 13,00 zł 2,50 zł : normalny 9,00 zł 1,50 zł : ulgowy 7,00 zł 1,00 zł : normalny 9,00 zł 1,50 zł : normalny 9,00 zł 1,50 zł : seans 8,00 zł 0,00 zł : grupowy 35,00 zł 4,00 zł : grupowy 35,00 zł 4,00 zł : ulgowy 7,00 zł 1,00 zł Zestawienie zbiorcze Rodzaj biletu Liczba Liczba Wartość Wpływ bez Wartość biletów płatności biletów rabatów rabatów normalny ,00 zł 1 665,00 zł 277,50 zł ulgowy ,00 zł 784,00 zł 112,00 zł łączony ,00 zł 585,00 zł 112,50 zł seans ,00 zł 288,00 zł 0,00 zł grupowy ,00 zł 1 645,00 zł 188,00 zł ,00 zł 690,00 zł Rysunek 25 Przykładowy raport szczegółowy dla usługodawcy w ramach Karty Metropolitalnej opcja rabaty. 12. Kalendarz W systemie musi istnieć moduł Kalendarz do definiowania poszczególnych dni, tj.: a) Powszednie, soboty, niedziele (automatycznie) b) Inne (definiowane przez Administratora), rozumie się przez to, że musi istnieć w module Kalendarz możliwość zdefiniowania przez Administratora dowolnego rodzaju dni (bez ograniczeń czasowych) i zapisanie ich w systemie. Przykład działania: Administrator stwierdził, że chce wprowadzić bilet w specjalnej cenie dla studentów ważny w Juwenalia, które odbywają się w dniach 1, 2 i 7 maja 2015r. Musi zatem być możliwość tworzenia grupy dni, nadanie im nazwy (w tym przypadku Juwenalia) i określenie w Kalendarzu dat (w tym przypadku 1,2 i 7 maja 64

65 2015.) Przy czym musi istnieć możliwość przypisania do grupy dowolnej liczby dni bez względu na to czy następują po sobie czy nie. W analogiczny sposób musi istnieć możliwość definiowania kolejnych grup dni, przy czym liczba grup dni może być dowolna. Każdy dzień może należeć do dowolnej liczby grup, to znaczy, że dany dzień może być zdefiniowany w kalendarzu zarówno jako święto, juwenalia, dzień niemiarodajny, itd. Liczba grup, do których przypisany jest dzień musi być dowolna. c) dni niemiarodajnych, Dni niemiarodajne to dni, z których dane nie będą brane do analiz statystycznych Kalendarz musi być powiązany z modułem przeznaczonym do analiz statystycznych i raportów celem wyeliminowania z analiz statystycznych wyników z dni niemiarodajnych. Użytkownik musi mieć jednak możliwość uwzględnienia w analizach statystycznych i raportach dni niemiarodajnych o ile uzna to za zasadne Kalendarz musi być powiązany ze wszystkimi modułami systemu. System musi działać tak, że nie ma potrzeby definiowania rodzajów dni w kalendarzu kilkakrotnie, raz zdefiniowana grupa dni musi być dostępna we wszystkich modułach systemu. 13. Przystanki W systemie musi istnieć moduł Przystanki Moduł ten zawierać będzie bazę danych o wszystkich przystankach objętych systemem Zasięg terytorialny przystanków włączonych do systemu musi być co najmniej taki jak obszar Bydgosko Toruńskiego Obszaru Metropolitalnego. Musi zatem istnieć możliwość komunikacji bezprzewodowej z każdego przystanku objętego systemem Definicję przystanku przedstawiono w rozdziale Definicje, wyjaśnia się dodatkowo, że jako przystanek rozumie się każdy pojedynczy słupek, stanowisko na węźle komunikacyjnym, odrębny przystanek w obszarze tego samego skrzyżowania, itd W bazie danych musi istnieć możliwość wprowadzenia co najmniej następujących danych: a) ID przystanku, b) Numer ewidencyjny przystanku (niepowtarzalny) c) nazwa przystanku, d) współrzędne geograficzne GPS (X,Y), e) numer węzła, f) nazwa węzła, g) numer grupy, h) nazwa grupy, i) dowolny inny opis W bazie danych musi istnieć możliwość wprowadzania dowolnej liczby dodatkowych kolumn z danymi. 65

66 13.7. Musi istnieć możliwość przeszukiwania i sortowania bazy danych wg dowolnych atrybutów, Musi istnieć możliwość generowania bazy danych co najmniej w formatach PDF, XLS, XML, Musi istnieć możliwość wprowadzania współrzędnych geograficznych przystanków przez użytkownika systemu Musi istnieć możliwość importowania danych o przystankach z zewnętrznych systemów, wówczas procedura działania będzie następująca: a) elementem kojarzącym przystanki będzie unikalny numer ewidencyjny przystanku, b) numer ewidencyjny przystanku nadawany jest przez administratora systemu i będzie zgodny z numerem ewidencyjnym obowiązującym w bazie, z której importowane będą dane, c) w celu prawidłowego działania systemu wymaga się aby numery ewidencyjne na całym obszarze objętym systemem były niepowtarzalne, oznacza to, że organizatorzy transportu, których linie komunikacyjne objęte będą systemem muszą wypracować wspólny system numerowania przystanków. Obecnie funkcjonujący system numeracji przystanków w Bydgoszczy polega na podziale miasta na 16 rejonów. Numer rejonu określony jest w pierwszych dwóch cyfrach numeru ewidencyjnego przystanku, pozostałe trzy cyfry to numer przystanku w danym rejonie. Na przykład numer oznacza przystanek numer 12 w rejonie numer 3. Dla prawidłowego działania systemu wymaga się, np. aby numery rejonów zostały rozdzielone pomiędzy operatorów systemu, nr rejony Bydgoszcz, rejony Toruń, itd. lub obecnie funkcjonujące numery zostały rozszerzone przez dodanie dwucyfrowych identyfikatorów różnych dla Bydgoszczy, Torunia oraz przewozów kolejowych, a w dalszym etapie dla kolejnych organizatorów transportu. d) musi istnieć możliwość przeprowadzenia importu danych w taki sposób aby projektowany system mógł zastąpić, lub nie (opcjonalnie) współrzędne geograficzne wprowadzone w systemie, z którego dane są importowane na współrzędne geograficzne wprowadzone w projektowanym systemie. Rozwiązanie to jest konieczne z tego względu, że systemy zewnętrzne (lokalne) często posiadają współrzędne geograficzne lokalne a nie GPS. Wówczas istnieje konieczność ich zamiany. Proponowany proces zamiany danych przedstawiono na rysunkach - Rysunek 26, Rysunek Musi istnieć narzędzie do grupowania przystanków, oznacza to, że w systemie musi istnieć narzędzie rozróżniające pojedynczy przystanek, pętlę i węzeł. Musi istnieć możliwość grupowania przystanków w obrębie pętli i węzłów, nadawanie nazw pętlom i węzłom. Zwraca się przy tym uwagę, że pojedynczy przystanek może należeć zarówno do pętli jak i do węzła jednocześnie, przy czym pętla może być także elementem węzła. Narzędzie to musi być ściśle powiązane z modułem Analiza przejazdów. Wymaga się bowiem aby analizy przemieszczeń pasażerów wykonywane były nie tylko w oparciu o pojedyncze przystanki ale też o grupy czyli pętle, węzły i zdefiniowane grupy 66

67 przystanków. Do celów analitycznych musi także istnieć możliwość tworzenia tzw. Rejonów. Musi zatem istnieć możliwość zdefiniowania rejonu i przypisania mu dowolnej liczby wybranych przystanków. Analiza przemieszczeń realizowana wg zasad określonych w rozdziale Analiza przemieszczeń musi być wykonywana także w oparciu o opisane tu rejony. W bazie danych musi istnieć możliwość wprowadzania dowolnej liczby dodatkowych kolumn z danymi Musi istnieć możliwość prowadzenia selekcji ze względu na dowolny atrybut w bazie danych Moduł Przystanki musi być ściśle powiązany z modułami Strefy, Analiza przejazdów i Mapa. Wszelkie zmiany wprowadzane w tym module muszą skutkować zmianami w pozostałych modułach i odwrotnie. x,y-dane lokalne w systemie zewnętrznym X,Y-prawidłowe dane GPS w systemie projektowanym SYSTEM PROJEKTOWANY Przystanek X Y X Y X Y X Y X Y X Y X Y SYSTEM ZEWNĘTRZNY Przystanek Przystanek x y X Y x y import z zamianą danych X Y x y X Y x y X Y x y X Y x y X Y x y X Y Rysunek 26 Import bazy danych o przystankach z zamianą współrzędnych GPS. 67

68 x,y-dane lokalne w systemie zewnętrznym (prawidłowe - GPS) X,Y-dane w systemie projektowanym SYSTEM PROJEKTOWANY Przystanek X Y X Y X Y X Y X Y X Y X Y SYSTEM ZEWNĘTRZNY Przystanek Przystanek x y x y x y import bez zamiany danych x y x y x y x y x y x y x y x y x y x y x y Rysunek 27 Import bazy danych o przystankach bez zamiany współrzędnych GPS. 14. Programowanie kasowników w pojazdach komunikacji miejskiej W systemie musi istnieć możliwość automatycznego programowania kasowników Kod kasownika określa wyłącznie administrator i tylko on ma możliwość jego modyfikacji. Modyfikacja kodu kasownika musi być możliwa do przeprowadzenia zdalnie ze stanowiska administratora systemu, w dowolnej liczbie kasowników lub we wszystkich jednocześnie Modyfikacja kodu kasownika musi być możliwa do zaprogramowania z wyprzedzeniem, np. jeśli kody mają się zmienić 1 stycznia 2016 r. o godz. 00:00, to musi być możliwe wprowadzenie tych zmian w dowolnym terminie, np. 20 grudnia 2015 r., wówczas zmiana kodu kasowników nastąpi automatycznie w zdefiniowanym wcześniej terminie Przypisanie kasowników do zadania przewozowego musi być możliwe na następujące sposoby: a) przez obsługę pojazdu za pośrednictwem komputera pojazdowego, b) zdalnie przez dyspozytora ze stanowiska dyspozytorskiego znajdującego się w Centrali Ruchu, c) poprzez stację bazową. 68

69 14.5. Przypisanie kasowników do zadania przewozowego przez obsługę pojazdu odbywać się będzie w następujący sposób: a) obsługa pojazdu na konsoli kierowcy wybiera numer linii i numer brygady po czym zatwierdza wprowadzone dane, b) kasowniki muszą zostać zaprogramowane wyłącznie na podstawie wprowadzonych danych (numer linii i brygady) bez konieczności wprowadzania przez obsługę pojazdu innych danych, zatem rozróżnienie przez system czy jest to linia nr 1 w Bydgoszczy czy linia nr 1 w Toruniu musi nastąpić systemowo Przypisanie kasowników do zadania przewozowego poprzez stację bazową (na zajezdniach) odbywać się będzie w następujący sposób: a) przypisanie zadania przewozowego dla danego wozu następuje przed wyjazdem pojazdu z zajezdni, b) czynności związane z przypisaniem zadania przewozowego do wozu wykonuje dyspozytor za pomocą narzędzia Dyspozytor, c) komputer pojazdowy przed wjazdem na trasę komunikuje się ze stacją bazową i pobiera dane o zadaniu przewozowym Przypisanie kasowników do zadania przewozowego przez Centralę Ruchu Operatorów odbywać się będzie w następujący sposób: a) pracownik centrali ruchu za pomocą narzędzia Dyspozytor przypisuje lub nadpisuje zdalnie zadanie przewozowe, b) przypisanie lub nadpisanie zadania przewozowego może nastąpić w każdej chwili Zasady działania narzędzia Dyspozytor. a) narzędzie jest dostępne w systemie i widoczne w sposób bezpośredni na stanowisku dyspozytora jak i na stanowisku centrali ruchu, b) przypisanie zadania przez obsługę pojazdu, dyspozytora czy pracownika centrali ruchu powoduje zmianę w bazie i jest widoczne zarówno na pulpicie kierowcy, na stanowisku dyspozytora jak i na stanowisku centrali ruchu, c) wprowadzenie zmiany ze stanowiska centrali ruchu powoduje komunikat (łącznie z sygnałem dźwiękowym) na stanowisku dyspozytora jak i na panelu kierowcy, podobnie wprowadzenie zmiany przez obsługę pojazdu czy dyspozytora powoduje pojawienie się komunikatu (wraz z sygnałem dźwiękowym) w dwóch pozostałych miejscach. d) Musi istnieć narzędzie służące do domyślnego ustawiania sposobu przypisywania zadania przewozowego jak też do blokowania sposobów. Oznacza to, że w przypadku wyboru przez danego przewoźnika czy operatora opcji przypisywania zadania przewozowego przez obsługę pojazdu musi istnieć możliwość całkowitego zablokowania lub ograniczenia pozostałych opcji Komputer pojazdowy z przypisanym zadaniem przewozowym musi w tym zakresie ściśle współpracować z pozostałymi urządzeniami systemu. 69

70 15. Programowanie terminala konduktorskiego Programowanie terminala musi być możliwe przez obsługę pojazdu poprzez przypisanie Zadania przewozowego Programowanie przez obsługę pojazdu odbywać się będzie w następujący sposób: Obsługa pojazdu na terminalu wybiera numer pociągu i czas odjazdu ze stacji początkowej po czym zatwierdza wprowadzone dane, Terminal musi zostać zaprogramowany wyłącznie na podstawie wprowadzonych danych (numer pociągu i czasu odjazdu) bez konieczności wprowadzania przez obsługę pojazdu innych danych, zatem rozróżnienie przez system czy jest to przejazd z Bydgoszczy do Torunia czy z Torunia do Bydgoszczy powinno następować automatycznie Terminal konduktorski z przypisanym zadaniem przewozowym musi w tym zakresie ściśle współpracować z pozostałymi urządzeniami systemu. 16. Raporty System musi mieć specjalny moduł do generowania raportów z wykorzystania jak i ze sprzedaży biletów Raporty muszą być generowane dla określonego interwału czasowego, przy czym musi istnieć możliwość wygenerowania każdego raportu dla co najmniej pięciu interwałów czasowych Definiowanie interwałów czasowych musi się odbywać według następujących zasad: a) dla każdego okresu użytkownik wybiera datę i godzinę początkową oraz datę i godzinę końcową, b) dla każdego okresu użytkownik wybiera długość interwału, c) musi istnieć możliwość wyboru co najmniej następujących interwałów: 15min; 0,5h; 1h; 4h; 6h; 12h; dzień; tydzień; miesiąc; kwartał; pół roku; rok; cały wybrany okres (od daty i godziny początkowej do daty i godziny końcowej, bez podziału na podokresy), d) interwał musi być oddzielnie definiowalny dla każdego z pięciu okresów, e) dla każdego z okresów musi istnieć możliwość definiowania innego interwału Musi istnieć możliwość generowania co najmniej następujących raportów dotyczących wykorzystania biletów na sieci transportowej objętej systemem: a) liczba i rodzaj biletów wykorzystanych na poszczególnych liniach (wzór Raport 1) - Rysunek 28, Rysunek 30, Rysunek 31, b) liczba i rodzaj biletów wykorzystanych w poszczególnych strefach (wg zasad jak raport dla poszczególnych linii), c) liczba i rodzaj biletów wykorzystanych w dowolnej grupie linii lub systemie transportowym. Oznacza to, że musi istnieć możliwość wygenerowania raportu dla dowolnych kilku linii łącznie, dowolnej grupy linii zdefiniowanej w bazie danych, na 70

71 której obowiązuje dany rodzaj biletu. Na przykład dla zdefiniowanej grupy Komunikacja miejska Toruń musi istnieć możliwość wygenerowania raportu o wykorzystanych w tej grupie wszystkich obowiązujących biletach (wzór Raport 2) - Rysunek 29, d) każdy opisany wyżej raport musi mieć możliwość zdefiniowania interwału czasowego (od do) przy czym musi istnieć możliwość zdefiniowania co najmniej pięciu interwałów dla pojedynczego raportu, e) musi istnieć możliwość wygenerowania raportu dla dowolnego rodzaju biletu (wzór Raport 5, 6 i 7) - Rysunek 32, Rysunek 33, Rysunek 34, f) musi istnieć możliwość wygenerowania raportu dla dowolnej grupy biletów, wówczas system musi automatycznie sumować liczbę biletów w poszczególnych okresach i interwałach wykorzystanych na wszystkich liniach, g) w przypadku generowania raportów dla poszczególnych biletów, system domyślnie przygotowuje raport dla wszystkich linii, na których przedmiotowy bilet (bilety) był wykorzystywany, administrator musi mieć jednak możliwość zawężenia zakresu raportu do wybranych linii, h) wszystkie raporty muszą mieć formę rozwiniętą jak i zwiniętą (wzór Raport 6, wzór Raportu 7) - Rysunek 33, Rysunek 34, Musi istnieć możliwość generowania raportu poprzez korzystanie z wpisów w bazie danych o liniach komunikacyjnych. Oznacza to, że administrator musi mieć możliwość wyboru dowolnych jednej lub kilku linii dla których wygenerowany zostanie raport. Funkcjonalność ta musi być spełniona dla wszystkich raportów opisanych w niniejszym ustępie W przypadku wyboru kilku linii system musi automatycznie sumować liczbę wykorzystanych biletów Moduł musi mieć możliwość generowania raportów w następujące sposoby: a) generowane w systemie z możliwością archiwizowania (opcjonalnie), b) generowanie co najmniej w formacie xls. oraz PDF W module musi istnieć narzędzie do archiwizowania raportów z możliwością ich przeglądania co najmniej wg parametrów: data, rodzaj biletu, system transportowy, linia. 71

72 Rysunek 28 Raport z walidacji biletów dla pojedynczej linii w interwale jednodniowym. 72

73 Rysunek 29 Raport z walidacji biletów dla grupy linii w interwale jednodniowym. 73

74 Rysunek 30 Raport z walidacji biletów dla pojedynczej linii w interwale godzinnym. 74

75 Rysunek 31 Raport z walidacji biletów dla pojedynczej linii w dwóch okresach w interwale godzinnym. 75

76 Rysunek 32 Raport z walidacji pojedynczego biletu w interwale jednodniowym. 76

77 Rysunek 33 Raport z walidacji pojedynczego biletu w interwale jednodniowym wersja raportu rozwinięta. 77

78 Rysunek 34 Raport z walidacji pojedynczego biletu w interwale jednodniowym wersja raportu zwinięta Dodatkowe wymagania dla generatora raportów ze sprzedaży biletów: a) musi istnieć możliwość wygenerowania raportu ze sprzedaży dla każdego rodzaju biletu, wybranej grupy biletów, wszystkich biletów, b) musi istnieć możliwość wygenerowania raportu w formie rozwiniętej i zwiniętej, c) w przypadku wyboru formy zwiniętej raport zawierać będzie sumaryczną liczbę i wartość sprzedanych biletów w zdefiniowanym interwale (interwałach) czasowych, d) musi istnieć możliwość wygenerowania raportu ze sprzedaży dla pojedynczego punktu sprzedaży, dowolnej grupy punktów sprzedaży lub wszystkich miejsc sprzedaży. e) w przypadku wyboru formy rozwiniętej raport musi zawierać co najmniej następujące informacje: liczbę i wartość sprzedanych biletów z podziałem na dni, liczbę i wartość sprzedanych biletów z podziałem na miejsca sprzedaży. 17. Kontrola biletów Kontroler musi mieć możliwość wysłania komunikatów alarmowych (awaria, kradzież, przestępstwo, napad, itp.), wyemitowany sygnał musi dotrzeć do dyspozytora Wysyłanie sygnału alarmowego musi być możliwe w sposób prosty i natychmiastowy Wysyłanie komunikatów alarmowych do dyspozytora odbywać się będzie za pośrednictwem komputera pojazdowego, komunikacja terminala kontrolera z komputerem pojazdowym odbywać się będzie poprzez komunikację Wi-Fi Identyfikacja linii komunikacyjnej w komunikacji miejskiej w Bydgoszczy i w Toruniu, na której odbywać się będzie kontrola musi być możliwa w dwojaki sposób: 78

79 a) poprzez wprowadzenie numeru linii i numeru bocznego pojazdu z klawiatury terminala kontrolera lub poprzez zeskanowanie w pojeździe kodu QR zawierającego powyższe informacje b) poprzez komunikację wi-fi z komputerem pojazdowym za pośrednictwem kasownika biletowego, w przypadku pobierania danych terminal kontrolera musi także pobrać, oprócz numeru linii, także numer brygady i numer boczny pojazdu, Identyfikacja linii komunikacyjnej w komunikacji kolejowej na trasie Bydgoszczy Toruń lub Toruń - Bydgoszczy odbywać się będzie poprzez przypisanie do terminala konduktorskiego zadania przewozowego (rozdział 15) Komunikacja terminala kontrolera / terminala konduktorskiego z komputerem pojazdowym musi być realizowana w taki sposób aby była możliwość skontrolowania wszystkich rodzajów biletów w tym biletów strefowych, obowiązujących na wybranych odcinkach Terminal kontrolera / terminal konduktorski musi mieć możliwość rejestracji co najmniej następujących danych: a) data i godzina rozpoczęcia kontroli, b) numer linii, strefy, odcinka itd., c) dane pojazdu (numer boczny, numer rejestracyjny lub inny numer jednoznacznie identyfikujący pojazd), musi być możliwość wprowadzenia tych danych do komputera pojazdowego na etapie montażu komputera pojazdowego w pojeździe. Z racji, że dany komputer pojazdowy jest na stałe przypisany do pojazdu (autobusu, tramwaju, pociągu), nie ma konieczności wprowadzania danych identyfikacyjnych o pojeździe wielokrotnie, komputer pojazdowy musi zatem do momentu zmiany tych danych zapamiętywać je i każdorazowo przesyłać do terminala kontrolera, d) rodzaj i numer kontrolowanego biletu, e) ważność biletu, f) nazwy przystanków (niepowtarzalne numery identyfikacyjne), między którymi odbyto kontrolę lub odcinek międzyprzystankowy, g) w przypadku zastosowania rozwiązania gdzie opis kontroli odbywać się będzie przy pomocy odcinka międzyprzystankowego, system musi automatycznie tworzyć bazę takich odcinków na podstawie danych w bazie danych, bez konieczności wykonywania dodatkowych czynności przez kontrolerów i administratora systemu, h) terminal kontrolera musi mieć możliwość archiwizacji danych pochodzących z każdej sesji kontrolnej, i) musi istnieć możliwość przesyłu danych z terminala kontrolera do serwera systemu po zakończeniu kontroli, informacje o kontroli będą przechowywane w terminalu kontrolera co najmniej do czasu ich przesłania do serwera systemu, j) jeśli dane nie zostały przesłane do serwera systemu kontroler nie może mieć możliwości ich samodzielnego usunięcia, k) musi istnieć systemowa opcja uniemożliwiająca kontrolerom samodzielne usuwanie wyników kontroli z terminala, bez względu na to czy dane zostały przesłane do 79

80 serwera systemu czy też nie, opcja ta musi być możliwa do zastosowania względem wszystkich lub tylko wybranych terminali, l) terminal kontrolera musi mieć możliwość kontroli wszystkich rodzajów biletów obowiązujących w systemie, bez względu na czas i obszar ich obowiązywania, m) terminal kontrolera musi mieć możliwość wprowadzenia danych kontrolera (co najmniej numer służbowy kontrolera), wszystkie numery służbowe kontrolerów na obszarze działanie SBM muszą być niepowtarzalne, analogicznie jak w przypadku numerów przystanków, n) przeprowadzenie kontroli bez wprowadzenia numeru służbowego kontrolera nie może być możliwe, o) oprócz numerów służbowych kontrolerów musi być możliwość wprowadzenia numerów serwisowych, wprowadzenie numerów serwisowych musi umożliwiać przeprowadzenie wszystkich czynności kontrolerskich oraz dodatkowo czynności serwisowych i technicznych, p) numery serwisowe będą przypisane pracownikom zajmującym się testowaniem, zarządzaniem, i programowaniem systemu, musi zatem istnieć możliwość definiowania co najmniej czterech rodzajów pracy terminala kontrolera: typowe prace kontrolera, osoby testujące system bez ograniczania możliwości przesyłu danych z kontroli, kasowania danych z kontroli, itd., osoby odpowiedzialne za administrowanie systemem dostęp do wszystkich funkcji bez możliwości wprowadzania zmian w oprogramowaniu związanych z czynnościami serwisowymi, naprawczymi, informatycznymi, osoby odpowiedzialne za serwis techniczny pełen dostęp (dane z kontroli przeprowadzonych przez serwis nie mają skutków windykacyjnych), System musi mieć możliwość generowania raportów o pracy kontrolerów (osób kontrolujących) i terminali kontrolerów (urządzeń), musi zatem istnieć możliwość wygenerowania raportu z pracy danego kontrolera bez względu na to iloma urządzeniami się posługiwał (system musi zatem skojarzyć dane z pracy wielu urządzeń), ale musi być też możliwość wygenerowania raportu o pracy każdego terminala kontrolera (bez względu na to ilu kontrolerów się nim posługiwało system musi zatem skojarzyć pracę wielu kontrolerów) Raporty muszą zawierać wszystkie dane o kontroli zapisane przez terminal kontrolera i przesłane do systemu Musi istnieć możliwość wyboru dowolnie długiego okresu czasowego dla poszczególnych raportów Musi istnieć możliwość pozycjonowania terminala kontrolera poprzez pozycjonowanie pojazdu, w którym został zalogowany. Ponadto musi istnieć możliwość podglądu lokalizacji terminala na mapie Musi istnieć możliwość komunikacji głosowej (GSM) z dyspozytorem Zewnętrze urządzenia kontrolerskie stosowane u przewoźników kolejowych nie muszą spełniać rygorów opisanych w pkt oraz 16.4 b-c. 80

81 18. Serwis Internetowy System musi być wyposażony w serwis internetowy Serwis internetowy zostanie osadzony na platformie, która stanie się własnością zamawiającego Musi istnieć uproszczona graficznie wersja mobilna serwisu internetowego Serwis internetowy musi być dostępny w co najmniej czterech językach: polskim, angielskim, rosyjskim i niemieckim, przy czym nie jednocześnie ale na zasadzie wyboru Serwis internetowy musi mieć możliwość importu danych z systemów do budowy rozkładów jazdy używanych co najmniej przez Zamawiającego Podstawowe wymagane funkcje serwisu internetowego to (patrz także rozdział Zarządzanie kartami): a) funkcja informacyjna, b) komunikaty, c) wyszukiwarka połączeń, d) możliwość doładowania kart, e) możliwość zakładania, przeglądania i konfigurowania spersonalizowanego konta, f) możliwość odsyłania do innych serwisów i stron internetowych, g) oferta taryfowo-biletowa, h) dział mapa Minimalne wymagania dla funkcji informacyjnej: a) informacje kontaktowe dotyczące partnerów projektu, b) dział z mapami i schematami, c) dział z informacjami taryfowymi, d) dział z rozkładami jazdy (linki) Minimalne wymagania dla funkcji komunikaty: a) w dziale komunikaty administrator musi mieć możliwość zamieszczania, usuwania i modyfikowania komunikatów, b) administrator musi mieć możliwość zamieszczania dowolnej liczby komunikatów, c) musi istnieć możliwość umieszczania załączników w formatach, co najmniej: PDF, JPG, PNG, XLS, DOC, d) musi istnieć narzędzie do predefiniowania komunikatów w zakresie daty początkowej i końcowej emisji Minimalne wymagania dla funkcji wyszukiwarka połączeń: a) wyszukiwarka połączeń musi mieć funkcję wyszukiwania połączeń między dowolnymi przystankami działającymi w systemie z wykorzystaniem wszystkich środków transportu działających w systemie, b) musi istnieć możliwość wyszukiwania połączeń według następujących atrybutów: przystanek początkowy, przystanek końcowy, adres początkowy, adres końcowy, obiekt początkowy, 81

82 obiekt końcowy, data, godzina, przyjazd z przystanku lub odjazd z przystanku, definiowanie parametrów przesiadkowych (liczba, czas przesiadek). c) wybór przystanków musi odbywać się na zasadzie rozwijalnego menu, przy czy obok nazwy przystanku musi, w nawiasie, znajdować się nazwa miejscowości, w którym się on znajduje oraz, za pomocą symbolu, rodzaj środka transportu (autobus, tramwaj, pociąg), d) wyszukiwarka musi wskazywać miejsca przesiadkowe, e) administrator systemu musi mieć narzędzie do kojarzenia adresów i obiektów z przystankami, przy czym musi istnieć możliwość skojarzenia z danym adresem lub obiektem dowolnej liczby przystanków. Narzędzie to ma na celu umożliwienie użytkownikom wyszukiwania połączeń według adresów i obiektów. f) w przypadku wyboru przez użytkownika opcji wyboru po adresie lub obiekcie wyszukiwarka musi uwzględnić wszystkie skojarzone z nimi przystanki, przeanalizować możliwe połączenia i wybrać optymalne co do zadanych parametrów, g) użytkownik musi mieć możliwość definiowania liczby akceptowalnych przesiadek i czasu na przesiadkę, h) domyślną liczbę akceptowalnych przesiadek i domyślny czas na przesiadkę ustala Administrator, i) użytkownik musi mieć możliwość definiowania maksymalnej drogi przejścia w przypadku przesiadki, j) domyślną maksymalną drogę przejścia w przypadku przesiadki ustala Administrator. k) dopuszczalne jest wykorzystanie istniejących rozwiązań, które spełniają wymagania minimalne, Minimalne wymagania dla funkcjonalności doładowanie kart: a) w serwisie internetowym musi istnieć możliwość doładowania karty zarówno przez zalogowanego jak i niezalogowanego użytkownika, b) musi istnieć możliwość stworzenia spersonalizowanego, szyfrowanego konta, w którym użytkownik po zalogowaniu może co najmniej przeglądać historię zakupionych biletów, doładowań, aktualizować dane osobowe, składać reklamacje, itd. c) możliwość sprawdzenia ważności biletu bez konieczności logowania, Minimalne wymagania dla funkcjonalności zakładanie i konfigurowanie konta: w serwisie internetowym musi istnieć możliwość zarejestrowania konta użytkownika wg niżej wymienionych kategorii: konto indywidualne, konto grupowe (firmowe, rodzinne itp.) dane niezbędne do zarejestrowania konta użytkownika: adres , 82

83 dane grupy (nazwa oraz dane adresowe dla konta grupowego), dane personalne (dla konta indywidualnego), inne dane niezbędne dla poprawności działania systemu, hasło oraz potwierdzenie hasła, pytanie pomocnicze dla procesu odzyskiwania hasła konta indywidualne musi udostępniać co najmniej następujące funkcjonalności: rejestracja kart imiennych będących w posiadaniu użytkownika (numer karty), nadawanie nazw rejestrowanych kart SBM, przeglądanie historii transakcji, przeglądanie historii wybranej karty, edytować dane, zakup E-biletów okresowych, doładowanie E-portmonetki, składanie wniosków, usuwanie konta użytkownika konta grupowe musi udostępniać co najmniej następujące funkcjonalności: rejestracja kart będących w posiadaniu członków rejestrowanej grupy (numer karty), nadawanie nazw rejestrowanych kart SBM, przeglądanie historii transakcji, przeglądanie historii wybranej karty lub grupy kart, edytować dane konta, zakup E-biletów okresowych dla pojedynczej karty lub wybranej grupy kart, doładowanie E-portmonetki dla pojedynczej karty lub wybranej grupy kart, składanie wniosków, Usuwanie konta użytkownika Minimalne wymagania dla funkcjonalności oferta taryfowo-biletowa i mapa: a) Oferta taryfowo-biletowa wraz z opisem (cena, odwołanie do regulaminu, itp.) oraz możliwością graficznego i opisowego prezentowania zakresu obowiązywania każdego z biletów, b) Musi istnieć możliwość prezentowania kompleksowej sieci sprzedaży, wraz z możliwością nałożenia filtrów ograniczających ofertę według typów punktów sprzedaży (biletomaty, punkty sprzedaży, itp.) c) Poszczególne punkty sprzedaży muszą posiadać odpowiedni opis, czyli adres, nr telefonu, godziny otwarcia, możliwości płatności oraz lokalizacja danego punktu na mapie. d) Mapa w serwisie powinna być ściśle związana z modułem Mapa z warstwą dla użytkownika, Administrator systemu musi mieć możliwość zamieszczania i modyfikowania treści serwisu internetowego w pełnym zakresie (dla wszystkich funkcjonalności) Przez stronę internetową musi istnieć możliwość składania wniosków o wydanie dowolnego rodzaju kart. Projekt graficzny serwisu internetowego, sposób obsługi oraz interfejs dostępny dla użytkownika muszą zostać zaakceptowany przez Zamawiającego, 83

84 19. Aplikacja isbm dla urządzeń mobilnych 19.1 Wykonawca winien opracować isbm dla co najmniej 3 systemów operacyjnych: Android, Windows Mobile, ios oraz urządzeń mobilnych obsługujących aplikacje Java Aplikacja musi być wykonana w sposób zgodny z aktualną na dzień odbioru aplikacji dostępną, od co najmniej 3 miesięcy wersją mobilnego systemu operacyjnego. Aplikacja musi być także kompatybilna z poprzedzającą aktualną wersją mobilnego systemu operacyjnego Aplikacja mobilna winna być opracowana na urządzenia mobilne z rozróżnieniem na urządzenie typu smartphone i tablet. Oznacza to, że aplikację należy zaprojektować do poprawnego wyświetlania na różnej wielkości ekranach aplikacje dedykowane. Nie dopuszcza się rozwiązania, w którym aplikacja isbm na urządzeniach typu tablet jest aplikacją o rozdzielczości dedykowanej dla urządzeń typu smartphone, lub aplikacja jest skalowana Zamawiający określa, jako wymóg opracowywanych aplikacji, że aplikacje muszą być aplikacjami natywnymi Wykonawca zobowiązany będzie przekazać Zamawiającemu kody źródłowe wraz z wszystkimi elementami użytymi do tworzenia aplikacji - dla aplikacji mobilnych zaakceptowanych przez Zamawiającego i przekazanych do dystrybucji przez Wykonawcę. Wraz z przekazanym kodem źródłowym aplikacji mobilnych Wykonawca zobowiązany będzie dostarczyć kompletny opis kodu źródłowego w języku polskim i angielskim Wykonawca w okresie zarządzania i administrowania systemem SBM wprowadzał będzie konieczne do prawidłowego działania modyfikacje aplikacji mobilnych w tym aktualizację aplikacji do nowych wersji systemów operacyjnych, a także w razie takiej konieczności, w ramach odrębnych zleceń Zamawiającego - do wprowadzania modyfikacji aplikacji wykraczających poza modyfikacje, których wykonanie będzie koniecznością wynikającą z aktualizacji systemów operacyjnych, systemów zabezpieczeń czy też w wyniku zidentyfikowanych błędów w działaniu aplikacji. Mając na uwadze powyższe przy każdorazowej zmianie kodu źródłowego aplikacji, Wykonawca zobowiązany będzie wprowadzić odpowiednie modyfikacje w dokumentacji technicznej i dostarczyć nową wersję dokumentacji technicznej Zamawiającemu wraz z nowym kodem źródłowym aplikacji (wraz z wszystkimi wymaganymi plikami źródłowymi). Wykonawca zobowiązany będzie do archiwizacji wszystkich wersji aplikacji mobilnych i ich kodów źródłowych i przekazywania archiwów Zamawiającemu W przypadku, kiedy, Wykonawca do opracowania aplikacji mobilnej użyje komercyjnych komponentów, których zgodnie z ich licencją i prawami autorskimi nie będzie mógł przekazać Zamawiającemu (licencjobiorcą będzie Wykonawca), Wykonawca zobowiązany będzie do zawarcia takich informacji w dokumentacji technicznej aplikacji mobilnych z wskazaniem, co najmniej nazwy oprogramowania, wersji oprogramowania i nazwy producenta Wykonawca zobowiązany będzie do opracowania umowy na korzystanie z aplikacji isbm przez użytkowników końcowych, oraz do opracowania metodyki dostarczania umowy użytkownikom i jej odbioru. Procesy te będą w gestii Wykonawcy. Aplikacja musi być w pełni obsługiwana za pomocą ekranów dotykowych wykorzystując właściwości mobilnych systemów operacyjnych w zakresie sposobu korzystania z ekranu dotykowego, w tym indywidualnych dla mobilnych systemów zachowań użytkownika w ramach posługiwania się ekranem dotykowym i wynikających z tych zachowań reakcji aplikacji Wykonawca, w zakresie aplikacji mobilnych - isbm zobowiązany będzie przez cały okres administrowania systemem między innymi do: 84

85 Analizy cyklicznej tj., co najmniej raz w miesiącu, funkcjonowania aplikacji mobilnych (wraz z miesięcznym raportem), Analizy cyklicznej tj., co najmniej raz w miesiącu, bezpieczeństwa aplikacji mobilnych (wraz z miesięcznym raportem), Analizy cyklicznej tj., co najmniej raz w miesiącu, popytu na aplikacje (wraz z miesięcznym raportem), Aktualizacji aplikacji ze względów bezpieczeństwa na skutek wykrytych nieprawidłowości w mobilnych systemach operacyjnych (luki bezpieczeństwa w systemach), Aktualizacji aplikacji w związku z nową wersją systemu operacyjnego (nie wcześniej niż dwa miesiące po dacie dostępności nowej wersji systemu i nie później niż 4 miesiące po dacie dostępności nowej wersji systemu), Modyfikacji aplikacji w związku z ujawnionymi przez Zamawiającego nieprawidłowościami w działaniu/funkcjonowaniu aplikacji, Modyfikacji aplikacji w związku ze zgłaszanymi przez użytkowników nieprawidłowościami, które zostaną potwierdzone przez Zamawiającego, Wprowadzania korekt w aplikacji w związku z wykrytymi przez niezależnych ekspertów błędami skutkującymi zagrożeniem w bezpieczeństwie danych i aplikacji w urządzeniach mobilnych, a także do prowadzenia wszystkich innych działań związanych z poprawnym funkcjonowaniem aplikacji mobilnych w systemie SBM Rozbudowa aplikacji o funkcjonalność, która nie została wskazana w dokumentacji technicznej wykonywana będzie w ramach odrębnych porozumień i umów Funkcjonalność aplikacji musi umożliwić prawidłowe funkcjonowanie użytkownika w systemie SBM aplikacje mobilne muszą udostępniać wszystkie usługi świadczone w ramach SBM Do usług świadczonych w ramach SBM realizowanych poprzez aplikację mobilną należą między innymi; Zakup usług związanych z publicznym transportem zbiorowym (kołowym i kolejowym) oferowanych przez partnerów projektu. W realizowanym przez Wykonawcę zakresie, system oferował będzie usługi związane z przejazdami wielokrotnymi, Obsługa usług związanych z publicznym transportem zbiorowym oferowanych przez partnerów projektu w zakresie przejazdów jednorazowych, Inne usługi dostępne w SBM, świadczone przez podmioty zewnętrzne przystępujące do uczestnictwa w systemie SBM, Planowanie podróży z uwzględnieniem dostępnych w systemie SBM danych, Informacja dotycząca czasu oczekiwania na środek transportu, rozkładu jazdy, planowanych i nieplanowanych zmian w rozkładach jazdy Wykonawca musi tak opracować aplikacje mobilne, aby Operator SBM mógł w każdym momencie odłączyć i ponownie włączyć określoną aplikację mobilną lub aplikacje mobilne od/do systemu blokowanie dostępu do systemu SBM. Funkcjonalność ta musi być wyodrębniona i udostępniona na poziomie aplikacji systemu. Operator systemu musi posiadać możliwość identyfikować aplikacje, które z przyczyn niezależnych od Operatora muszą zostać odłączone od systemu. Opisana powyżej funkcjonalność musi umożliwić Zamawiającemu i Wykonawcy (w okresie, kiedy Wykonawca pełnił będzie rolę Operatora) natychmiastowe odłączenie od systemu określonej aplikacji (jej zablokowanie) co w konsekwencji musi uniemożliwić korzystanie z aplikacji która została odłączona od systemu. Należy także przewidzieć w tej funkcjonalności opcję zdalnego usuwania aplikacji z urządzenia System SBM musi umożliwić użytkownikowi, w przypadku utraty urządzenia, na którym zainstalowano aplikację isbm wyłączenie aplikacji. 85

86 Wykonawca zobowiązany będzie opracować komplet procedur w tym zakresie uwzględniając np. wysłanie wiadomości SMS o określonej treści na określony nr, wykonanie połączenia i wydanie automatycznej dyspozycji itp. Wyżej wskazane funkcje systemu będą używane w przypadku, kiedy Użytkownik zgłosi kradzież, zaginiecie lub inny przypadek dotyczący urządzenia mobilnego skutkujący koniecznością blokady/usunięcia aplikacji z takiego urządzenia Pozyskiwanie isbm Wykonawca zobowiązany będzie do opracowania wdrożenia i uruchomienia w tym do doprowadzenia do dostępności aplikacji mobilnych w skojarzonych z mobilnymi systemami operacyjnymi metodami dystrybucji aplikacji Aplikacja musi być dostępna do pobrania bezpłatnie Wszystkie konta zakładane przez Wykonawcę w celu zapewnienia dostępności aplikacji, jej aktualizacji, modyfikacji i dalszej rozbudowy muszą być tworzone w imieniu Zamawiającego i Zamawiający musi być wskazanym dystrybutorem aplikacji (zamawiający musi posiadać dostęp do tych kont) Zamawiający nie wyklucza, że w przyszłości aplikacja isbm będzie dostępna, jako aplikacja płatna, lub, że aplikacja będzie darmowa, ale wybrane jej funkcje wymagały będą aktualizacji aplikacji do wersji płatnej. Wobec powyższego aplikację należy zaprojektować i wykonać uwzględniając konieczność zapewnienia Zamawiającemu możliwości wprowadzenia opłaty za aplikację lub możliwości blokowania dostępu do określonych funkcji aplikacji i udostępniania tych funkcji po dokonaniu opłaty (dotyczy funkcji/ funkcjonalności dostępnych w aplikacjach mobilnych) Aplikacje winny być dostępne do pobrania i zainstalowania na urządzeniach mobilnych. Dostęp do aplikacji musi odbywać się poprzez autoryzację użytkownika SBM. Konto użytkownika SBM zakładane będzie na dedykowanym, opracowanym przez Wykonawcę w ramach projektu SBM portalu internetowym Użytkownik winien posiadać ten sam login i hasło do aplikacji mobilnej, co do swojego konta na portalu SBM lub, jeżeli Wykonawca wskaże za konieczne, loginy i hasła mogą być różne. W aplikacji nie może być możliwości zmiany loginu lub hasła dla konta użytkownika, taka możliwość musi być dostępna tylko w portalu Aplikacja po pobraniu, -bez zalogowania- winna udostępniać materiał demonstracyjny w formie animowanej lub innej zaproponowanej przez Wykonawcę i zaakceptowanej przez Zamawiającego, prezentujący możliwości i funkcjonalność aplikacji dla zalogowanych użytkowników SBM oraz inne wskazane usługi dostępne dla użytkowników bez autoryzacji aplikacji w systemie SBM Aplikacja winna umożliwić (właściwa funkcja w aplikacji) otwarcie okna przeglądarki na urządzeniu mobilnym, na którym jest zainstalowana, z portalem SBM (wersją portalu dostosowaną do urządzenia, na którym jest wywoływany dedykowana wersja dla urządzeń mobilnych) Autoryzacja aplikacji isbm. Przykładowe rozwiązanie dotyczące funkcjonowania użytkownika w systemie; Użytkownik zarejestrowany oczekujący na autoryzację. Użytkownik taki posiadał będzie login i hasło funkcjonujące w systemie, próba logowania potwierdzi to w urządzeniu odpowiednim komunikatem. Po dokonaniu autoryzacji w systemie przez Operatora, aplikacja winna poinformować o tym użytkownika (powiadomienia push) lub użytkownik powinien otrzymać wiadomość /sms z informacją o autoryzacji Użytkownik zarejestrowany i autoryzowany. Użytkownik taki posiadał będzie login i hasło w systemie, zalogowanie do aplikacji uruchomi jej funkcjonalność w tym do aplikacji przesłane zostaną informacje o usługach dostępnych (wykupionych) dla użytkownika. UWAGA: Wykonawca może zaproponować inny sposób autoryzacji użytkowników w systemie. W takim przypadku proponowany przez Wykonawcę sposób winien być 86

87 przedstawiony Zamawiającemu na etapie prowadzonej przez Zamawiającego oceny dokumentacji technicznej. Wykonawca zobowiązany będzie do udokumentowania, że proponowany sposób jest zgodny z obowiązującymi przepisami prawa, bezpieczny i funkcjonalny Użytkowanie aplikacji isbm. Aplikacja mobilna winna funkcjonować w pełni, po autoryzacji za pomocą loginu i hasła użytkownika. Dostęp do wybranych funkcji aplikacji winien być uwarunkowany posiadaniem aktywnej usługi dostępu do sieci Internet za pośrednictwem usług świadczonych przez operatorów komórkowych oraz za pomocą sieci bezprzewodowych. 20. Generator danych dla systemów obcych System musi być wyposażony w specjalny moduł do generowania danych dla systemów zewnętrznych Generator musi pracować w oparciu o szynę ESB Moduł musi umożliwiać generowanie danych co najmniej w formatach: xls, xml i csv Moduł musi umożliwiać generowanie danych w sposób automatyczny w określonych przez administratora systemu interwałach czasowych Moduł musi być wyposażony w narzędzie do definiowania interwałów czasowych dla każdego pakietu generowanych danych Moduł musi umożliwiać generowanie co najmniej pakiety danych dotyczące: Rozkładów jazdy, Oferty taryfowo biletowej, Bazy przystanków, Odczytanych przez operatora zewnętrznego biletów, Rozliczeń biletów Pakiet danych o rozkładach jazdy musi zawierać co najmniej: Identyfikator operatora, Numer linii komunikacyjnej, Wariant trasy, Niepowtarzalny identyfikator przystanku, Kolejny numer przystanku na trasie, Godzina odjazdu, Numer kursu (nr pociągu) Pakiet danych dotyczący oferty taryfowo-biletowej musi zawierać co najmniej: Identyfikator taryfy (biletu), Nazwę biletu, Symbol biletu (nazwę skróconą), Cenę brutto biletu Pakiet z bazą przystanków musi zawierać co najmniej: Identyfikator przystanku (kod techniczny), 87

88 Identyfikator operatora, Kod pomocniczy (handlowy) Nazwę węzła komunikacyjnego, Współrzędne GPS Pakiet danych o odczytanych przez operatora biletach musi zawierać co najmniej: Identyfikator operatora, Identyfikator urządzenia odczytującego, Identyfikator taryfy (biletu), Identyfikator przystanku, Czas kontroli, Identyfikator kontroli biletów Pakiet danych dotyczący rozliczeń biletów musi zawierać co najmniej: Identyfikator operatora, Identyfikator biletu, Cenę biletu (cena sprzedaży brutto), Ilość odczytów (skasowań), Udział % w przychodach Wygenerowane pakiety muszą być zapisane na zabezpieczonym serwerze plików i udostępnione do pobrania 24h/dobę przez 7 dni w tygodniu dla upoważnionych operatorów systemów zewnętrznych, którzy importują te dane do swoich systemów Wymaga się aby, niezależnie od wyszczególnionych wcześniej pakietów danych, generowane dane miały taki zakres aby urządzenia (czytniki konduktorskie) działające w systemach obcych mogły, w momencie odczytu karty, zidentyfikować każdy obowiązujący w systemie rodzaj biletu tak jak to przewidziano dla czytników kontrolerskich dedykowanych systemowi SBM. 21. Administracja systemem System musi mieć specjalny moduł do administrowania W celu umożliwienia wielopoziomowego zarządzania systemem, oraz z racji, że system obejmować będzie wielu organizatorów i operatorów (wiele systemów transportowych) działanie systemu musi być oparte na: a) aplikacji webowej lub, b) na zasadzie udostępniania nieograniczonej liczby licencji instalowanych w dowolnych lokalizacjach Sposobem komunikowania się stanowisk systemu z serwerem jest ogólnodostępna sieć publiczna a komunikacja jest szyfrowana kluczem o sile nie mniejszej niż 256 bitów Wykonawca systemu zobowiązany jest do zapewnienia komunikacji między komponentami systemu, bez względu na ich lokalizację i cel przesyłu danych z wykorzystaniem w pierwszej kolejności sieci informatycznych będących w gestii Zamawiającego. W przypadku braku łączności z siecią Zamawiającego, system ma wykorzystywać łączność GSM (z możliwością rozbudowy do LTE). Czas niezbędny do 88

89 przełączenia się między sieciami przesyłu danych nie może zakłócać ciągłości pracy SBM w zakresie wszystkich jego funkcjonalności Wszystkie urządzenia funkcjonujące w oparciu o GSM (z możliwością rozbudowy do LTE) funkcjonują w wydzielonym APN terminowanych w zależności od lokalizacji w Bydgoszczy lub w Toruniu Urządzenia kontrolerskie (terminale kontrolerów) komunikują się z komputerem pojazdowym z wykorzystaniem zabezpieczonej sieci wi-fi System musi mieć możliwość wielowarstwowego nadawania uprawnień i dostępów do poszczególnych modułów. Oznacza to, że musi istnieć poziom Głównego Administratora, który posiada nieograniczony dostęp do wszystkich funkcjonalności systemu (zarówno do edycji jak i do odczytu). Główny Administrator przekazuje kody dostępu do wybranych funkcjonalności Administratorowi A, Administratorowi B, itd. Administrator A ustala z kolei dostępy dla w podległej mu podgrupie. Administratorzy A, B, C N to Administratorzy II Poziomu. Wyjaśnienie: Ustalono Głównego Administratora. Ma on nieograniczony dostęp do wszystkich funkcjonalności systemu. Ustalono także Administratora A, który stanowi nadzór nad systemem na poziomie Bydgoszczy, Administratora B, który stanowi nadzór nad systemem na poziomie Torunia oraz Administratora C, który stanowi nadzór nad systemem w zakresie zarządzania przewozami kolejowymi i autobusowymi funkcjonującymi w zakresie kompetencji Marszałka Województwa. Ustalono także że struktura organizacyjna w Toruniu musi mieć dostęp do odczytu dla wybranych modułów (funkcjonalności), na przykład Mapa, Strefy, Bazy Danych, Raporty, itd. Główny Administrator przekazuje Administratorowi B kody dostępu dla tych modułów (funkcjonalności) jest to drugi poziom dostępu, po czym Administrator B ustala kody dostępu dla tych funkcjonalności w swojej strukturze organizacyjnej jest to III poziom dostępu. Kody dostępu dla poszczególnych poziomów muszą być różne pomimo, że dotyczą tej samej funkcjonalności. Oznacza to, że kod dostępu przekazany Administratorowi B przez Administratora A dla funkcjonalności Mapa musi być inny jak kod dostępu dla funkcjonalności Mapa przekazany przez Administratora B podległemu mu pracownikowi Musi istnieć możliwość ustalania dowolnej liczby Administratorów A, B, C N Musi istnieć możliwość pozbawienia przez poszczególnych Administratorów na każdym poziomie nadanych wcześniej dostępów Musi istnieć specjalne narządzie, za pomocą którego zarówno Główny Administrator jak też Administratorzy II Poziomu będą mogli w sposób przejrzysty nadawać poszczególne uprawnienia Musi istnieć specjalne narzędzie, za pomocą którego będzie można sprawdzić, kto (personalnie i pod względem lokalizacji stanowiska) ma dostęp do poszczególnych modułów (funkcjonalności) System musi umożliwiać wykonywanie zadań Głównemu Administratorowi oraz Administratorom A, B, C N. Podstawowe zadania Administratorów to: a) Zadania Głównego Administratora: fizyczne wprowadzanie zmian we wszystkich modułach, w których wprowadzanie zmian jest możliwe, 89

90 nadawanie uprawnień dla II i ewentualnie III Poziomu Dostępu. b) Zadania Administratora A, B, C N: fizyczne wprowadzanie zmian w modułach, w których wprowadzanie zmian jest konieczne na II Poziomie Dostępu. nadawanie uprawnień dla III Poziomu Dostępu Główny Administrator jak też Administrator II Poziomu nie może być kojarzony z danym stanowiskiem komputerowym. Dostęp do systemu dzięki aplikacji webowej musi być możliwy po zalogowaniu z dowolnego komputera Musi istnieć Serwisowy Poziom Dostępu do systemu. Dostęp ten musi umożliwić informatyczną diagnostykę i utrzymanie systemu bez możliwości wprowadzania zmian w modułach nie związanych z techniczną stroną funkcjonowania systemu, w szczególności w modułach, w których następuje kształtowanie oferty taryfowej, definiowanie czasowego i obszarowego funkcjonowania biletów, modułów rozliczeniowych, itd System zarządzania kartami, biletami i strefami został tak opracowany aby możliwe było tworzenie dowolnej oferty taryfowej bez ograniczeń czasowych i obszarowych, oznacza to, że możliwe jest w systemie wprowadzenie biletu na jedną linię o stałej cenie. Bilet ten będzie obowiązywać na jednej wybranej linii bez względu czy linia ta funkcjonuje w Bydgoszczy, Toruniu czy innym miejscu. Możliwe jest natomiast też wprowadzenie w systemie biletu o określonej cenie, na jedną linię i przypisanie mu obszarowego obowiązywania tylko linie w Bydgoszczy, oraz biletu o innej cenie, na jedną linię i przypisanie mu obszarowego obowiązywania tylko linie w Toruniu. Musi zatem istnieć taki sposób administrowania systemem aby opisane tu możliwości istniały. Schemat wymaganego sposobu administrowania przedstawiono na rysunku - Rysunek

91 Możliwości ustalania taryf Przykłady biletów Implementacja taryf do systemu przez Administratora Możliwość 1 Wspólne ustalenie przez Partnerów oferty taryfowej dla: - biletów obowiązujących na całym obszarze, - biletów obowiązujących w podsystemach (taka sama cena) bilet obowiązujący na całym obszarze metropolitalnym zł bilet obowiązujący na jednej linii (niezależnie gdzie funkcjonuje) - 60 zł Administrator implementuje wszystkie bilety do systemu bez względu na to czy są wspólnym produktem dla całego obszaru metropolitalnego czy też zostały ustalone indywidualnie przez członków związku Toruń Bydgoszcz Możliwość 2 Wspólne ustalenie przez Partnerów oferty taryfowej dla: - biletów obowiązujących na całym obszarze, - biletów obowiązujących w podsystemach (różne ceny) bilet obowiązujący na całym obszarze metropolitalnym zł bilet obowiązujący na jednej linii w Bydgoszczy - 65 zł Toruń Bydgoszcz bilet obowiązujący na jednej linii w Toruniu - 55 zł Możliwość 3 Wspólne ustalenie przez Partnerów oferty taryfowej dla: - biletów obowiązujących na całym obszarze, Niezależne ustalenie przez Partnerów oferty taryfowej dla: - biletów obowiązujących w podsystemach (różne ceny) bilet obowiązujący na całym obszarze metropolitalnym zł bilet obowiązujący na jednej linii w Bydgoszczy - 65 zł bilet obowiązujący na jednej linii w Toruniu - 55 zł Toruń Bydgoszcz Rysunek 35 Sposoby definiowania oferty taryfowej. 91

92 Struktura systemu SBM Rysunek 36 Struktura Systemu Biletu Metropolitalnego Struktura organizacyjna systemu SBM w siedzibie Partnera w Bydgoszczy. W skład Systemu wchodzą: a) Centrum Obsługi Systemu w siedzibie Partnera w Bydgoszczy, zawierające: Serwer z zainstalowanym oprogramowaniem centralnym do obsługi systemu oraz serwer bezpieczeństwa z identycznym oprogramowaniem, 4 stanowiska nadzoru, 6 stanowisk obsługi klienta (COK w siedzibie Partnera, POK oraz w pozostałych obiektach administrowanych przez ZDMiKP w Bydgoszczy ) 14 stanowisk personalizacji kart, b) System sprzedaży biletów obejmujący: 80 Terminali sprzedaży w Punktach Sprzedaży zlokalizowanych na terenie miasta i ew. gmin ościennych, przeznaczonych do sprzedaży E-biletów doładowań E- portmonetkii, w tym co najmniej 6 terminali sprzedaży zlokalizowanych w punktach sprzedaży biletów administrowanych przez Partnera, 50 automatów biletowych stacjonarnych do sprzedaży E-biletów okresowych, biletów w formie tradycyjnej oraz sprzedaży doładowań E-portmonetki 368 mobilnych automatów biletowych do sprzedaży biletów jednorazowych w formie tradycyjnej, kasowania dodatkowych biletów z E-portmonetki oraz kodowania biletów okresowych zakupionych w sklepie Internetowym, Aplikacja mobilna do zakupu biletów, Sklep internetowy. c) System kontroli biletów obejmujący 70 czytników kontrolerskich wraz ze stacjami dokującymi oraz niezbędnym oprogramowaniem do realizacji funkcji kontrolnej oraz kodowania biletów na kartach. 92

93 Ponadto w skład Systemu wchodzą: zbiór kart pracowniczych o kontrolerskich przeznaczonych do logowania się do czytników kontrolerskich upoważnionych przez Zamawiającego pracowników, o serwisowych przeznaczonych do logowania się przez upoważnionych przez Zamawiającego pracowników do serwisowanych urządzeń (automatów biletowych stacjonarnych i mobilnych, czytników kontrolerskich, terminali sprzedaży itd.) zbiór kart pasażerskich. LOKALNE CENTRUM OBSŁUGI SYSTEMU W BYDGOSZCZY Centrum Obsługi Systemu (COS) rozmieszczone będzie w wydzielonych pomieszczeniach w obiektach administrowanych przez Partnera w Bydgoszczy. Pomieszczenia, w których będą znajdować się stanowiska nadzoru, obsługi klientów, przetwarzania danych i personalizacji kart oraz terminale sprzedaży zostaną odpowiednio dostosowane przez wykonawcę systemu na etapie jego wdrożenia. Stanowiska COS pracować będą w sieci komputerowej LAN. Podstawowe zadania: gromadzenie i przetwarzanie danych; personalizacja kart elektronicznych; import i eksport danych z/do urządzeń składowych systemu zlokalizowanych w pojazdach publicznego transportu zbiorowego, punktach sprzedaży, punktach akceptacji usług dodatkowych, a także na przystankach komunikacji publicznej i in. Rysunek 37 Struktura Systemu SBM w obiektach administrowanych przez Partnera w Bydgoszczy 93

94 22. Administracja systemem rozliczeń. Wszystkie rozwiązania systemowe w zakresie informatycznym, funkcjonalnym i technicznym muszą być dostosowane do każdego opisanego w niniejszym rozdziale Modelu administrowania systemem. Funkcjonowanie zwartego systemu taryfowo biletowego jakkolwiek pozwala na funkcjonowanie niezależnych cen biletów w poszczególnych obszarach objętych systemem, wymusza konieczność funkcjonowania jednolitego systemu zarządzania modelem rozliczeniowym. Wynika to z faktu, że poszczególne rodzaje biletów wykorzystywane będą w środkach transportu finansowanych przez różnych organizatorów. Na przykład bilet ważny w całym systemie (na całym obszarze B-TOM) ważny będzie w środkach transportu finansowanych przez organizatora transportu w Bydgoszczy, Torunia jak też organizatora przewozów kolejowych. Wpływy zatem z takiego biletu należą się po części każdemu z tych organizatorów. Opisany w niniejszym dokumencie system umożliwia takie działanie, jednakże w celu wyartykułowania tego zagadnienia uznano za zasadne je tu opisać. MODEL 1 (Rysunek 38) Organizacja usług przewozowych pozostaje po stronie poszczególnych partnerów współdziałających w systemie SBM. Usługi przewozowe na terenie miasta Bydgoszczy organizuje i finansuje bezpośrednio właściwy organizator dla miasta Bydgoszczy (obecnie Zarząd Dróg Miejskich i Komunikacji Publicznej w Bydgoszczy), usługi przewozowe na terenie miasta Torunia organizuje i finansuje bezpośrednio właściwy organizator dla miasta Torunia (obecnie Wydział Gospodarki Komunalnej Urzędu Miasta Torunia), usługi przewozowe kolejowe organizuje i finansuje właściwy organizator dla Województwa Kujawsko Pomorskiego (obecnie Urząd Marszałkowski z siedzibą w Toruniu). Analogicznie w przypadku pojawienia się lub wyrażenia woli współdziałania kolejni organizatorzy transportu (na przykład w Solcu Kujawskim lub dowolnej gminie leżącej w obszarze B-TOM). Partnerzy wyznaczają Administratora systemu, którego zadaniem będzie zarządzanie systemem taryfowo biletowym oraz prowadzenie rozliczeń wpływów z biletów. Partnerzy związku współfinansują działalność Administratora w zakresie jego działalności na rzecz partnerów. Działalność ta obejmuje w szczególności: implementowanie do systemu oferty taryfowej ustalonej przez Partnerów, dystrybucję i kontrolę biletów, zarządzanie biletami (kartami), windykację, zarządzanie systemem SBM pod względem administracyjnym, funkcjonalnym i technicznym, pozyskiwanie wpływów z biletów, rozliczanie wpływów z biletów pomiędzy Partnerami, pozyskiwanie wszelkich danych o biletach, przemieszczeniach i przejazdach. Należy tu zaznaczyć, że do zadań Administratora nie należy kreowanie oferty taryfowej a jedynie zarządzanie nią. Kreowanie oferty taryfowej leży po stronie Partnerów. Powinno być poprzedzone analizą ruchową. Przebiegać powinno w trybie wzajemnych porozumień usankcjonowanych uchwałami właściwych rad. 94

95 Po pozyskaniu wpływów z biletów Administrator za pomocą opracowanych i zatwierdzonych przez Partnerów algorytmów obliczeniowych 1 dokonuje podziału wpływów z biletów pomiędzy Partnerów. Należy tu zaznaczyć, że Partnerzy mają stały dostęp do poszczególnych modułów systemu i nie ma technicznych przeciwwskazań aby na bieżąco śledzili i analizowali poziom wpływów i liczbę walidacji poszczególnych biletów. Partnerzy mogą także bez ograniczeń uczestniczyć w analizie podziału wpływów z biletów. Przyjęte rozwiązania projektowe są takie, że Administrator w zakresie podziału wpływów jest tylko wykonawcą woli Partnerów a nie decydentem. Model 1 nie skutkuje koniecznością wprowadzenia istotnych zmian w strukturach odpowiedzialnych za organizację transportu na obszarze B-TOM. Wymusza jedynie konieczność powołania Administratora, którym de facto może być jeden z funkcjonujących w obszarze B-TOM organizatorów (oczywiście z uwzględnieniem zwiększenia zakresu osobowego i finansowego). MODEL 2 (Rysunek 39) Model ten jest rozwinięciem modelu 1. Mamy tu do czynienia z sytuacją gdzie jeden (kilku lub wszyscy) z Partnerów ma zawarte porozumienia międzygminne z gminami ościennymi. Taka sytuacja ma obecnie miejsce w Bydgoszczy gdzie Miasto Bydgoszcz ma zawarte porozumienia międzygminne z gminą Białe Błota i Dąbrowa Chełmińska oraz w Toruniu gdzie Miasto Toruń ma zawarte porozumienie międzygminne z gminą Lubicz. Wówczas, w tym przypadku Organizator 1 wraz z gminami ościennymi, traktowany jest jako jeden Partner w SBM. Wynika to stąd, że w wyniku zawartych porozumień międzygminnych przejął on rolę organizatora transportu na terenie gmin sąsiednich. Prowadzi on zatem w imieniu własnym i gmin, z którymi ma zawarte porozumienia, rozliczenia finansowe i uzgodnienia w ramach uczestnictwa w SBM, natomiast rozliczenie z gminami ościennymi prowadzi we własnym zakresie. Model 1 nie skutkuje koniecznością wprowadzenia istotnych zmian w strukturach odpowiedzialnych za organizację transportu na obszarze B-TOM. Wymusza jedynie konieczność powołania Administratora, którym de facto może być jeden z funkcjonujących w obszarze B-TOM organizatorów (oczywiście z uwzględnieniem zwiększenia zakresu osobowego i finansowego). MODEL 3 (Rysunek 40) Model ten przewiduje przejęcie przez Administratora także roli Organizatora transportu na obszarze B-TOM. Rola Partnerów sprowadza się zatem do kreowania oferty taryfowej, przy czym Administrator Organizator powinien być dostarczycielem danych wejściowych do analiz nad taryfami. Środki na finansowanie usług przewozowych jak też na działalność Administratora Organizatora Partnerzy przekazują bezpośrednio Administratorowi Organizatorowi, ten z kolei przekazuje Partnerom wpływy z biletów. Algorytmy obliczeniowe są w tym modelu podobne jak w modelach 1 i 2. Także zasady współuczestnictwa Partnerów w podziale wpływów są podobne lub tożsame jak w modelach 1 i 2. Model 3 skutkuje koniecznością całkowitej reorganizacji struktur odpowiedzialnych za organizację transportu na całym obszarze B-TOM. 1 Budowa algorytmów obliczeniowych nie jest przedmiotem niniejszego opracowania stąd też nie zostały one tu przedstawione. 95

96 MODEL 1 Organizator 1, 2 i 3 finansowanie działalności Administratora Administrator systemu Dystrybucja biletów Wpływy z biletów Linia 11 Linia 11, 12, 13, 21, 22, 23, 31, 32, 33 bilety Ustalenie oferty taryfowej Moduł rozliczeniowy rozdział wpływów z biletów Linia 31, 32, 33 itd. Organizator 1 (Bydgoszcz) Organizator 2 Organizator 3 finansowanie (Urząd finansowanie (Toruń) finansowanie usług przewozowych Marszałkowski) usług przewozowych usług przewozowych Linia 11 Linia 21 Linia 31 Linia 12 Linia 22 Linia 32 Linia 13 Linia 23 Linia 33 Rysunek 38 Zarządzanie systemem rozliczeń Model 1. 96

97 MODEL 2 Organizator 1 zawarł porozumienia z gminami ościennymi i w ich imieniu organizuje transport Organizator 1 prowadzi indywidualnie rozliczenia z gminami ościennymi uwzględniając koszty związane z funkcjonowaniem SBM Organizator 1, 2 i 3 finansowanie działalności Administratora Ustalenie oferty taryfowej Administrator systemu Dystrybucja biletów Wpływy z biletów Moduł rozliczeniowy rozdział wpływów z biletów Linia 11 Linia 11, 12, 13, 21, 22, 23, 31, 32, 33 Linia 31, 32, 33 itd. bilety Gminy ościenne Organizator 1 (Bydgoszcz) Moduł rozliczeniowy Organizator 2 Organizator 3 finansowanie (Urząd finansowanie (Toruń) finansowanie usług przewozowych Marszałkowski) usług przewozowych usług przewozowych Linia 11 Linia 21 Linia 31 Linia 12 Linia 22 Linia 32 Linia 13 Linia 23 Linia 33 Rysunek 39 Zarządzanie systemem rozliczeń Model 2. 97

98 MODEL 3 Bydgoszcz podział wpływów z biletów środki na finansowanie usług przewozowych i działalność Administratora - Organizatora Administrator systemu - Organizator transportu Dystrybucja biletów Wpływy z biletów Linia 11 Linia 11, 12, 13, 21, 22, 23, 31, 32, 33 bilety Ustalenie oferty taryfowej Moduł rozliczeniowy Linia 31, 32, 33 itd. Urząd Marszałkowski finansowanie usług przewozowych Toruń Linia 11 Linia 21 Linia 31 Linia 12 Linia 22 Linia 32 Linia 13 Linia 23 Linia 33 Rysunek 40 Zarządzanie systemem rozliczeń Model 3. 98

99 23. Wyposażenie techniczne oraz funkcjonalność urządzeń. W niniejszym rozdziale opisano podstawowe wymagania w zakresie funkcjonalności poszczególnych urządzeń systemu oraz ich parametry techniczne. Są to wymagania minimum Konsola kierowcy (motorniczego). Wymagania funkcjonalne: a) konsola kierowcy (motorniczego) musi być wyposażona w wyświetlacz i klawiaturę alfanumeryczną, b) programowanie kasowników z klawiatury alfanumerycznej, c) definiowanie zadania przewozowego z klawiatury alfanumerycznej, d) informacja czy kasowniki są zaprogramowane czy nie emitowana będzie w następujący lub analogiczny sposób: kasowniki niezaprogramowane kasowniki zaprogramowane e) domyślnie na wyświetlaczu emitowana jest informacja o numerze linii oraz sprawności kasowników, f) sprawność kasowników emitowana jest w następujący lub analogiczny sposób: wszystkie kasowniki sprawne kasownik 2 niesprawny kasownik 2 i 5 niesprawny g) informacja o braku komunikacji z którymkolwiek z kasowników emitowana będzie w następujący lub analogiczny sposób: brak komunikacji h) informacja o braku sprawności kasownika będzie wysyłana do dyspozytora w Centrali Ruchu, emitowana na mapie i archiwizowana w systemie. i) konsola kierowy musi informować obsługę pojazdu także o nieprawidłowości działania innych urządzeń technicznych związanych z systemem, a w które pojazd jest wyposażony, j) emitowanie na wyświetlaczu komunikatów od dyspozytora Komputer pokładowy. a) umożliwienie programowania kasowników i automatów biletowych za pośrednictwem konsoli kierowcy, oznacza to, że komputer pojazdowy musi mieć takie możliwości aby po wyborze przez kierowcę (motorniczego) numeru linii i brygady kasowniki zostały jednoznacznie zaprogramowane, 99

100 b) pozycjonowanie pojazdów (GPS), c) przesył danych (GSM), d) identyfikowanie przystanków i sterowanie kasownikami w taki sposób aby identyfikowały one strefy obowiązywania poszczególnych biletów, e) gromadzenie danych o przejazdach (check in, check out), f) gromadzenie danych o skasowanych biletach, g) komunikacja z bileterkami, h) komunikowanie się z Centralą Ruchu (GSM) i stacją bazową Terminal kontrolera (czytnik kontrolera). a) czytnik kontrolera musi pracować jako terminal mobilny, wyposażony w klawiaturę alfanumeryczną i kolorowym wyświetlaczem dotykowym, b) czytnik kart pracujących w systemie SBM, c) komunikacja Wi-Fi (wyposażenie w kartę sieciową), d) możliwość pozycjonowania (GPS), e) możliwość wyposażenia w telefon komórkowy (GSM), f) rejestracja wszystkich przeprowadzonych kontroli, g) wyłapywanie kart zastrzeżonych, h) muszą istnieć trzy poziomy dostępu do czytnika kontrolera: Kasownik. poziom I dostęp czytnika do bazy danych, poziom II dostęp czytnika do funkcji kontroli biletów, poziom III dostęp do modułów serwisowych. a) czytnik wszystkich kart funkcjonujących w systemie, b) możliwość kasowania biletów papierowych jednorazowych poprzez odbicie kodu kasowania na bilecie, c) opcjonalnie działanie w trybie check-in lub check-in / check-out (CICO), d) sprawdzanie zawartości E-portmonetki, e) komunikacja z systemem za pośrednictwem komputera pojazdowego, f) gromadzenie danych o wszystkich operacjach wykonanych przez kasownik, g) sprawdzanie ważności biletów funkcjonujących w systemie, h) automatyczna weryfikacja kart (identyfikacja kart zastrzeżonych). Kasownik musi być wyposażony w ekran dotykowy umożliwiający dokonywanie czynności takich jak: wybór ilości biletów jednorazowych do skasowania, sprawdzenie stanu E-portmonetki, sprawdzenie ważności biletów okresowych. Podczas użycia karty kasownik winien w pierwszej kolejności dokonać odczytu e-biletu. W sytuacji gdy na karcie nie ma zakodowanego elektronicznego biletu okresowego lub jest on nieważny kasownik winien odczytać stan E-portmonetki. Jeżeli w E-portmonetce znajdują się bilety do skasowania to na ekranie kasownika winny pojawić się komunikaty i przyciski umożliwiające skasowanie odpowiedniej ilości biletów. Pełny zakres tych funkcjonalności musi być możliwy do zdefiniowania przez Administratora. Dane techniczne: 100

101 a) Procesor: min. 450 MHz, b) Pamięć RAM: 128 MB (z możliwością rozbudowy do 512 MB), c) Pamięć FLASH: min. 256 MB (z możliwością rozbudowy do 32 GB), d) Slot kart SD do rozszerzenia pamięci FLASH, e) 1 port RS232, f) 1 port RS485, g) 1 port Ethernet 10/100, h) 1 port USB 2.0, i) 2 x we/wy cyfrowe, j) Wyświetlacz graficzny o rozdzielczości 320x240 pc, 16M kolorów, ekran dotykowy, zabezpieczony szkłem hartowanym min. 4 mm (lub inne równoważne zabezpieczenie), z kontrolą jasności, k) Czytnik kart bezstykowych współpracujący z kartami SBM, l) 2 gniazda dla modułów SAM, m) Głośnik, n) Zasilanie z instalacji elektrycznej pojazdu Automat biletowy stacjonarny Opis ogólny Automaty biletowe muszą realizować sprzedaż biletów jednorazowych w formie papierowej ze wzorami ustalonymi z Zamawiającym na etapie uruchomienia urządzeń oraz elektroniczne bilety okresowe kodowane na kartach funkcjonujących w systemie SBM. Automaty biletowe muszą pozwalać na korzystanie z funkcji informacyjnych oraz planowania podróży. Automaty biletowe muszą gromadzić i przekazywać do systemu centralnego wszystkie dane sprzedażowe. Automaty biletowe muszą możliwość automatyczne diagnozowanie stanu technicznego. Automaty biletowe muszą umożliwiać zdalną aktualizację taryf biletowych. Automaty biletowe muszą być dostosowane do pracy w odkrytej przestrzeni. Automatu biletowego muszą spełniać wymagania norm bezpieczeństwa dla urządzeń tego typu. Budowa Wszelkie krawędzie zewnętrzne obudowy muszą być tak ukształtowane, aby nie stanowiły zagrożenia dla pasażerów i nie powodowały niebezpieczeństwa uszkodzenia odzieży lub zranienia. Konstrukcja wewnętrzna automatów biletowych winna być również pozbawiona ostrych krawędzi. Obudowa musi być wykonana ze stali nierdzewnej o grubości minimum 2 mm, malowana proszkowo w kolorach uzgodnionych z Zamawiającym. Drzwi muszą być wykonane ze stali nierdzewnej o grubości minimum 2 mm, malowane proszkowo w kolorach uzgodnionych z Zamawiającym, zamykane na centralny zamek z minimum 3 punktami ryglowania. 101

102 Automaty biletowe muszą być wyposażone w kolorowy ekran dotykowy LCD o rozmiarze minimum 15, zabezpieczony dodatkowo przed uszkodzeniem płytą z poliwęglanu, bezpiecznego szkła lub innego tworzywa o grubości min. 4 mm. Każdy z automatów biletowych musi być wyposażony w dwie drukarki termiczne z funkcją druku grafik oraz kodów kreskowych z automatycznym nożem do odcinania biletów. Każdy z automatów biletowych musi być wyposażony w kieszeń zwrotu reszty/biletu, podświetlany po zakończeniu transakcji. Podświetlanie musi być aktywne przez czas wydawania biletu/ów, potwierdzenia zakupu oraz reszty. Każdy z automatów biletowych musi być wyposażone w czytnik kart bezstykowych pozbawiony szczeliny. Odczyt kart następuje poprzez zbliżenie do oznaczonego pola na automacie biletowym. Czytnik kart bezstykowych musi być wyposażony w min. 2 gniazda do instalowania modułów kryptograficznych SAM. Każdy z automatów biletowych musi być wyposażony w kasetę na bilon wykonaną ze stali nierdzewnej z odrębnym zamkiem o pojemności minimum 4dm 3 oraz w kasetę na banknoty o pojemności minimum 500 sztuk z dostępem zabezpieczonym zamkiem. Konstrukcja automatów biletowych musi być odporna na akty wandalizmu. Automaty biletowe muszą być połączone są z systemem centralnym SBM poprzez przewodową sieci transmisji danych oraz mieć możliwość połączenia bezprzewodowego w ramach sieci GSM (GSM lub nowsze) w przypadku braku połączenia w ramach sieci przewodowej transmisji danych. Warunki eksploatacyjne Automaty biletowe muszą spełniać klasę ochrony minimum IP 54. Automaty biletowe będą zasilane z sieci o napięciu zasilania 230V. Automaty biletowe muszą być wyposażone w ogrzewanie i wentylację, uruchamiane automatycznie czujnikiem, zapewniające pracę automatu w zakresie temperatur od -25 o C do +50 o C. Automaty biletowe muszą być dostosowane do pracy w warunkach względnej wilgotności otoczenia max 95%. W przypadku zaniku napięcia zasilającego automat biletowy musi zakończyć ostatnią transakcję, zapisać wszystkie niezbędne dane i automatycznie się wyłączy, wysyłając uprzednio odpowiedni alert do systemu centralnego. Automaty biletowe muszą być wyposażone w zegar o dokładności +/- 1min. na 24h, zsynchronizowany z serwera centralnego systemu SBM. Funkcjonalność urządzenia - automaty biletowe muszą realizować trzy podstawowe funkcjonalności: Automat biletowy sprzedaż biletów, doładowań e-portmonetki, usług dodatkowych, Informator (rozkłady jazdy), Wyszukiwanie połączeń (planowanie podróży). Obsługa automatu musi odbywać się za pomocą ekranu dotykowego. Ekran startowy musi umożliwiać wybór jednej z ww. funkcjonalności. Automat biletowy (Biletomat) 102

103 Musi istnieć możliwość wyboru na ekranie dotykowym wszelkiego rodzaju ulg, będących w ofercie przewoźnika. Musi istnieć możliwość sprzedaży kilku biletów w tej samej taryfie podczas jednej transakcji. Musi istnieć możliwość rezygnacji z transakcji w dowolnym momencie przed jej zatwierdzeniem. Biletomaty muszą posiadać funkcję wyświetlania kwoty pozostałej do zapłaty. Obsługa sprzedaży biletów musi odbywać się w minimum 3 językach: polski, niemiecki, angielski. Przy konieczności zakupu biletów za odliczoną gotówkę, w przypadku braku monet do wydawania reszty automat musi sygnalizować odpowiedni komunikat na wyświetlaczu. Biletomaty muszą obsługiwać płatności kartami z chipem, zbliżeniowo oraz z paskiem magnetycznym oraz umożliwiać potwierdzenie transakcji PINem na pinpadzie. Biletomaty muszą być przystosowane do użytkowania jako informatory (rozkład jazdy, informacja miejska, turystyczna) lub skorzystanie z aplikacji planowania przejazdu. Funkcje oprogramowania Oprogramowanie musi być tak przygotowane, aby obsługa biletomatu była intuicyjna. Na każdym kolejnym ekranie pasażer dokonuje tylko jednego wyboru. Wielkość pamięci wewnętrznej musi być tak dobrana, aby w biletomacie można było przechowywać co najmniej 2 moduły cenowe lub inne taryfy. Biletomaty muszą mieć możliwość automatycznego przełączania taryfy we wskazanym dniu na taryfę kolejną, zaprogramowaną przed dniem wejścia jej w życie. Oprogramowanie musi być tak zaprojektowane, aby podczas jednej transakcji umożliwić wybór kilku biletów tego samego rodzaju (w tej samej taryfie). Musi istnieć możliwość rejestracji stanów awaryjnych, identyfikacji osoby dokonującej obsługi oraz wszelkich ingerencji w automat tj. otwarcie drzwi, wyjęcie oraz wymiana kasety końcowej na monety i banknoty, wyjęcie oraz uzupełnienie monet w zasobnikach do wydawania reszty. Pełne zarządzanie automatem biletowym musi być może zarówno poprzez lokalny interfejs komunikacyjny jak również zdalnie poprzez aplikację zarządzającą. Oprogramowanie musi umożliwiać drukowanie raportów: Realizacja płatności stanie monet w zasobnikach do wydawania reszty i w kasecie końcowej, z wykonanych uzupełnień zasobników do wydawania reszty, dotyczących stanów awaryjnych, dotyczących sprzedaży biletów. Biletomaty muszą posiadać możliwość regulowania płatności przy pomocy karty metropolitalnej na bezstykowej karcie elektronicznej zgodnej ze standardami ISO 14443, Mifare Protocol. Czytnik musi obsługiwać karty w standardzie Mifare Plus. Biletomaty muszą posiadać możliwość regulowania płatności przy pomocy kart płatniczych włącznie z bezstykowymi kartami z mikropłatnościami, z wykorzystaniem wbudowanego czytnika manualnego oraz klawiatury PIN. Biletomaty muszą obsługiwać transakcje realizowane przy pomocy bilonu i banknotów. 103

104 Biletomaty muszą mieć możliwość przyjmowania minimum 6 nominałów monet w walucie polski złoty: 10 gr, 20 gr, 50 gr, 1 zł, 2 zł, 5 zł. Biletomaty muszą mieć możliwość przyjmowania 5 nominałów banknotów w walucie polski złoty, z możliwością zablokowania wybranych nominałów. Musi istnieć możliwość anulowania transakcji w dowolnym momencie przed jej zatwierdzeniem. Po anulowaniu transakcji następuje zwrot fizycznie tych samych monet. Automaty muszą być wyposażone w zasobniki do wykonywania reszty w 5 nominałach monet (10gr, 50 gr, 1 zł, 2 zł, 5zł) i posiadać funkcję samo-uzupełnienia. Zapas każdego z nominałów musi wynosić min 200 monet co zapewnia wyeliminowanie potrzeby uzupełniania magazynów przez serwis. Biletomaty muszą mieć możliwość wyposażenia w dodatkowe zasobniki do wydawania reszty w 3 zdefiniowanych nominałach bez funkcji samo-uzupełniania o pojemności 300 sztuk każdy. Biletomaty w wersji stacjonarnej muszą posiadać opcjonalnie możliwość wydawania reszty w jednym, zadeklarowanym, nominale banknotów. Banknoty do wydawania reszty pochodzić będą z zasobnika uzupełnianego automatycznie podczas transakcji z wykorzystaniem tego nominału. Elektroniczny czytnik monet musi mieć możliwość zmiany akceptowalnych nominałów oraz regulację jego czułości. Czytnik monet oraz banknotów muszą posiadajć możliwość przeprogramowania w celu akceptowania waluty EURO, bez konieczności ich wymiany, a także rozpoznawanie obu walut jednocześnie z możliwością programowego wyłączenia bądź włączenia obsługi danej waluty. Wlot monet winien być otwierany dopiero w momencie zatwierdzenia transakcji. W pozostałych przypadkach wlot winien być zamknięty uniemożliwiając włożenie obcych przedmiotów i wlanie cieczy. Zamawiający musi mieć możliwość zdefiniowania maksymalnej wartości pojedynczej transakcji. Musi istnieć możliwość zdefiniowania dynamicznego ograniczenia nominałów akceptowanego banknotu w zależności od wartości danej transakcji. Nominały akceptowane przez biletomat w danej transakcji są wskazywane podróżnemu na wyświetlaczu w sposób graficzny. Wydruki Biletomaty muszą posiadają możliwość drukowania różnych typów zdefiniowanych wcześniej biletów (Normalny, Ulgowy, Godzinny, Dobowy itp.) oraz raportów. Szczegółowe zdefiniowanie typów biletów jakie mają być drukowane w biletomacie zostanie określone na etapie uruchamiania urządzeń. Szerokość wydruków od 50 do 82,5 mm (długość minimalna 33mm) Papier termiczny o gramaturze g/m 2. Drukarka wewnętrzna drukuje bilety według wzoru ustalonego z Zamawiającym. Kod 2D (QR) drukowany na bilecie może zawierać dowolną zawartość. Ponadto informacje w nim zawarte będą kodowane specjalnym algorytmem i będą umożliwiały identyfikację biletu w systemie sprzedany np. przez kontrolera. 104

105 Wielkość rolki jest dobrana tak, aby była możliwość wydruku co najmniej 5000 biletów (w zależności od długości biletu) bez konieczności wymiany rolki przy gramaturze papieru 100 g/m 2. Gilza rolki minimum 25 mm. W przypadku braku papieru na jednej rolce, następuje przełączenie na drugi mechanizm drukujący. W przypadku całkowitego braku papieru biletomat wyświetlać będzie na ekranie komunikat Sprzedaż biletów chwilowo nieczynna. informacja o wyczerpaniu rolek/rolki jest wysłana do serwera. Opcjonalnie drugi mechanizm drukujący może służyć do wydruku potwierdzeń płatności kartą i wtedy wydruk biletów jest realizowany tylko z jednej drukarki. Obsługa serwisowa automatów Identyfikacja serwisantów odbywa się poprzez ich zalogowanie się do automatu przy pomocy kodu PIN oraz specjalnej karty bezstykowej. Wszystkie komunikaty menu serwisowego są podawane w języku polskim. Zabezpieczenia Przed otwarciem drzwi automatu pracownik serwisu, kasjer lub kontroler muszą się zalogować w systemie poprzez zbliżenie karty bezstykowej zgodnej ze standardami ISO i podanie PIN-kodu. Dostęp kaset na bilon i banknoty oraz modułów do wydawania reszty musi być zabezpieczony dodatkowymi zamkami. Moduł pamięci musi posiadać zabezpieczenia tak, aby zapewnić bezpieczeństwo wszystkich danych konfiguracyjnych, danych o obsłudze sprzętu, wyjęciu kaset informacji o dokonanych transakcjach od ostatniego zrzutu danych w razie całkowitego zaniku zasilania zewnętrznego. Biletomaty muszą posiadać zamki mechaniczne z możliwością wielokrotnego przeprogramowania, zapewniające dowolną zmianę pasujących do nich kluczy używanych przez obsługę. Przeprogramowanie musi odbywać się wyłącznie mechanicznie z wykorzystaniem klucza programującego. Biletomaty muszą być wyposażone w system alarmu akustycznego, załączający się w przypadku nieuprawnionego otwarcia drzwi (110dB). Informator Funkcja informatora jest funkcją programową. Realizowana jest poprzez wywołanie lokalnej strony internetowej zainstalowanej w pamięci urządzenia, dostosowanej do wymogów wykorzystania panelu dotykowego. Dane wyświetlane na stronie mogą być aktualizowane zdalnie w formie interfejsów SOAP oraz pobierania plików FTP lub lokalnie przy użyciu nośników typu pendrive. Wyszukiwarka połączeń Wyszukiwarka połączeń jest kolejną dodatkową funkcją urządzenia. Planuje się wykorzystanie silnika portalu systemu BKM i zgromadzonych tam danych do realizacji procesu wyszukiwania. Wyszukiwanie winno odbywać się poprzez określenie miejsca (ulicy) celu podróży poprzez wpisanie przy pomocy klawiatury alfanumerycznej na ekranie panelu dotykowego. Następnie system pobierając dane z systemu centralnego winien wyświetlać optymalne trasy dojazdu, 105

106 włącznie z koniecznymi przesiadkami oraz wyświetla dodatkowe informacje dla użytkownika jak np. czasy podróży. Po wyborze optymalnej dla użytkownika trasy przejazdu. System zdalnego zarządzania i monitoringu systemu Zdalne zarządzanie urządzeniami jest podstawą do szybkiej realizacji ewentualnego serwisu oraz zmian taryf i parametrów pracy urządzenia. System informatyczny musi być zbudowany w architekturze klient serwer. Warstwa serwerowa składa się z bazy danych oraz aplikacji - interfejsów do urządzeń. W skład systemu winny wejść dodatkowo aplikacje zarządzającomonitorujące przeznaczone do pracy z osobami nadzorującymi pracę urządzeń. Transmisja danych z urządzeń automaty biletowe muszą współpracować z serwerem zarządzającym w następującym zakresie: Synchronizacja czasu i daty, Przesyłanie na bieżąco następujących danych eksploatacyjnych automatu: sprawny/niesprawny, aktywny/nieaktywny tryb sprzedaży, brak papieru na drukarce nr., stan zapasu monet do wydawania reszty, brak monet do wydawania reszty w magazynie., stan zapełnienia skarbca monetowego, stan zapełnienia skarbca banknotowego, statystyka sprzedaży, informacja o otwarciu drzwi, wersja zaimplementowanej taryfy, brak zdefiniowanej taryfy, dane osoby serwisującej. Przesłania rekordów sprzedaży biletów, Reakcji na żądania ze strony serwera (np. zablokowanie sprzedaży) Automaty biletowe muszą posiadać możliwość przenoszenia i przesyłania danych eksploatacyjnych oraz danych dotyczących sprzedaży biletów za pośrednictwem łączności zdalnej lub za pośrednictwem urządzeń pamięci masowej USB. W przypadku łączności zdalnej przewiduje się aktualizacje w formie interfejsów SOAP oraz pobierania plików FTP. Aplikacja serwisowa Dostarczane kioski informacyjne współpracują z aplikacją serwisową, zarządzającą automatami biletowymi w zakresie co najmniej: Odbieranie alarmów i danych eksploatacyjnych: Brak papieru na drukarce nr., Brak monet do wydawania reszty w magazynie.., Pełny skarbiec, Brak zasilania sieciowego, Brak zdefiniowanej taryfy, Dane osoby serwisującej (nr ID) 106

107 Informacja o otwarciu drzwi. Dane osobowe serwisującej są przesłane natychmiast po zalogowaniu. Informacja o otwarciu drzwi jest przekazana natychmiast po otwarciu drzwi. Informacja o zablokowaniu sprzedaży Automat biletowy mobilny Opis ogólny Automaty biletowe muszą realizować sprzedaż biletów jednorazowych w formie papierowej ze wzorami ustalonymi z Zamawiającym na etapie uruchomienia urządzeń oraz kodować na kartach SBM elektroniczne bilety okresowe zakupione w sklepie on-line. Automaty biletowe muszą gromadzić i przekazywać do systemu centralnego wszystkie dane sprzedażowe. Automaty biletowe muszą umożliwiać automatyczne diagnozowanie stanu technicznego. Automaty biletowe muszą umożliwiać zdalną aktualizację taryf biletowych. Automaty biletowe muszą być dostosowane do pracy wewnątrz pojazdów komunikacji miejskiej. Automatu biletowego muszą spełniać wymagania norm bezpieczeństwa dla urządzeń tego typu. Budowa Wszelkie krawędzie zewnętrzne obudowy muszą być tak ukształtowane, aby nie stanowiły zagrożenia dla pasażerów i nie powodowały niebezpieczeństwa uszkodzenia odzieży lub zranienia. Konstrukcja wewnętrzna automatów biletowych winna być również pozbawiona ostrych krawędzi. Obudowa musi być wykonana ze stali nierdzewnej o grubości minimum 2 mm, malowana proszkowo w kolorach uzgodnionych z Zamawiającym. Drzwi muszą być wykonane ze stali nierdzewnej o grubości minimum 2 mm, malowane proszkowo w kolorach uzgodnionych z Zamawiającym, zamykane na centralny zamek z minimum 3 punktami ryglowania. Automaty biletowe muszą być wyposażone w kolorowy ekran dotykowy LCD o rozmiarze minimum 12, zabezpieczony dodatkowo przed uszkodzeniem. Każdy z automatów biletowych musi być wyposażony w dwie drukarki termiczne z funkcją druku grafik oraz kodów kreskowych z automatycznym nożem do odcinania biletów. Każdy z automatów biletowych musi być wyposażone w czytnik kart bezstykowych pozbawiony szczeliny. Odczyt kart SBM następuje poprzez zbliżenie do oznaczonego pola na automacie biletowym. Czytnik kart bezstykowych musi być wyposażony w min. 2 gniazda do instalowania modułów kryptograficznych SAM. Każdy z automatów biletowych musi być wyposażony w czytnik kart płatniczych do obsługi płatności zbliżeniowych. Konstrukcja automatów biletowych musi być odporna na akty wandalizmu. Automaty biletowe muszą być połączone są z systemem centralnym SBM poprzez bezprzewodową sieci transmisji w ramach sieci GSM z możliwością rozbudowy do LTE. 107

108 Warunki eksploatacyjne Automaty biletowe muszą spełniać klasę ochrony minimum IP 54. Automaty biletowe będą zasilane z sieci pojazdu (autobus/tramwaj). Automaty biletowe muszą być dostosowane do pracy w warunkach względnej wilgotności otoczenia max 95%. W przypadku zaniku napięcia zasilającego automat biletowy musi zakończyć ostatnią transakcję, zapisać wszystkie niezbędne dane i automatycznie się wyłączy, wysyłając uprzednio odpowiedni alert do systemu centralnego. Automaty biletowe muszą być wyposażone w zegar o dokładności +/- 1min. na 24h, zsynchronizowany z serwera centralnego systemu SBM. Funkcjonalność Musi istnieć możliwość wyboru na ekranie dotykowym wszelkiego rodzaju ulg, będących w ofercie przewoźnika. Musi istnieć możliwość sprzedaży kilku biletów papierowych w tej samej taryfie podczas jednej transakcji. Musi istnieć możliwość kodowania na kartach systemu SBM elektronicznych biletów okresowych zakupionych w sklepie internetowym. Musi istnieć możliwość aktywacji dodatkowych biletów jednorazowych z wykorzystaniem E- portmonetki. Musi istnieć możliwość rezygnacji z transakcji w dowolnym momencie przed jej zatwierdzeniem. Biletomaty muszą posiadać funkcję wyświetlania kwoty do zapłaty. Obsługa sprzedaży biletów musi odbywać się w minimum 4 językach: polski, niemiecki, angielski i rosyjski. Biletomaty muszą obsługiwać płatności kartami zbliżeniowo. Funkcje oprogramowania Oprogramowanie musi być tak przygotowane, aby obsługa biletomatu była intuicyjna. Na każdym kolejnym ekranie pasażer dokonuje tylko jednego wyboru. Wielkość pamięci wewnętrznej musi być tak dobrana, aby w biletomacie można było przechowywać co najmniej 2 moduły cenowe lub inne taryfy. Biletomaty muszą mieć możliwość automatycznego przełączania taryfy we wskazanym dniu na taryfę kolejną, zaprogramowaną przed dniem wejścia jej w życie. Oprogramowanie musi być tak zaprojektowane, aby podczas jednej transakcji umożliwić wybór kilku biletów tego samego rodzaju (w tej samej taryfie). Musi istnieć możliwość rejestracji stanów awaryjnych, identyfikacji osoby dokonującej obsługi oraz wszelkich ingerencji w automat np. otwarcie drzwi. Pełne zarządzanie automatem biletowym musi być możliwe zarówno poprzez lokalny interfejs komunikacyjny jak również zdalnie poprzez aplikację zarządzającą. Oprogramowanie musi umożliwiać drukowanie raportów: dotyczących stanów awaryjnych, dotyczących sprzedaży biletów. 108

109 Realizacja płatności Biletomaty muszą posiadać możliwość regulowania płatności przy pomocy karty metropolitalnej na bezstykowej karcie elektronicznej zgodnej ze standardami ISO 14443, Mifare Protocol. Czytnik musi obsługiwać karty w standardzie Mifare Plus. Biletomaty muszą posiadać możliwość regulowania płatności bezstykowymi kartami z mikropłatnościami. Musi istnieć możliwość anulowania transakcji w dowolnym momencie przed jej zatwierdzeniem. Zamawiający musi mieć możliwość zdefiniowania maksymalnej wartości pojedynczej transakcji. Wydruki Biletomaty muszą posiadają możliwość drukowania różnych typów zdefiniowanych wcześniej biletów (Normalny, Ulgowy, Godzinny, Dobowy itp.) oraz raportów. Szczegółowe zdefiniowanie typów biletów jakie mają być drukowane w biletomacie zostanie określone na etapie uruchamiania urządzeń. Szerokość wydruków od 50 do 82,5 mm (długość minimalna 33mm) Papier termiczny o gramaturze g/m 2. Drukarka wewnętrzna drukuje bilety według wzoru ustalonego z Zamawiającym. Kod 2D (QR) drukowany na bilecie może zawierać dowolną zawartość. Ponadto informacje w nim zawarte będą kodowane specjalnym algorytmem i będą umożliwiały identyfikację biletu w systemie sprzedany np. przez kontrolera. Wielkość rolki jest dobrana tak, aby była możliwość wydruku co najmniej 5000 biletów (w zależności od długości biletu) bez konieczności wymiany rolki przy gramaturze papieru 100 g/m 2. Gilza rolki minimum 25 mm. W przypadku braku papieru na jednej rolce, następuje przełączenie na drugi mechanizm drukujący. W przypadku całkowitego braku papieru biletomat wyświetlać będzie na ekranie komunikat Sprzedaż biletów chwilowo nieczynna. informacja o wyczerpaniu rolek/rolki jest wysłana do serwera. Opcjonalnie drugi mechanizm drukujący może służyć do wydruku potwierdzeń płatności kartą i wtedy wydruk biletów jest realizowany tylko z jednej drukarki. Obsługa serwisowa automatów Identyfikacja serwisantów odbywa się poprzez ich zalogowanie się do automatu przy pomocy kodu PIN oraz specjalnej karty bezstykowej. Wszystkie komunikaty menu serwisowego muszą być podawane w języku polskim. Zabezpieczenia Przed otwarciem drzwi automatu pracownik serwisu, musi się zalogować w systemie poprzez zbliżenie pracowniczej karty bezstykowej systemu SBM i podanie PIN-kodu. Moduł pamięci musi posiadać zabezpieczenia tak, aby zapewnić bezpieczeństwo wszystkich danych konfiguracyjnych, danych o obsłudze sprzętu, wyjęciu kaset informacji o dokonanych transakcjach od ostatniego zrzutu danych w razie całkowitego zaniku zasilania zewnętrznego. 109

110 Biletomaty muszą posiadać zamki mechaniczne z możliwością wielokrotnego przeprogramowania, zapewniające dowolną zmianę pasujących do nich kluczy używanych przez obsługę. Przeprogramowanie musi odbywać się wyłącznie mechanicznie z wykorzystaniem klucza programującego. Biletomaty muszą być wyposażone w system alarmu akustycznego, załączający się w przypadku nieuprawnionego otwarcia drzwi (110dB) Terminal punktu sprzedaży elektronicznych biletów okresowych (E-bilet) i zakupu punktów przejazdowych (E-portmonetka) - (Terminal PSB) Terminal PSB to urządzenie przeznaczone do instalowania w Punktach Sprzedaży Biletów. Terminal PSB musi spełniać następujące wymagania funkcjonalne: a) Sprzedaż biletów przewidzianych w taryfie SBM. b) Doładowania e-portmonetki. c) Zdalną możliwość aktualizacji parametrów aplikacji (np. cen biletów z taryfy itp.). d) Personalizację wydruków potwierdzeń operacji w karcie (unikalny numer terminala, nazwa punktu, adres punktu). e) Możliwość zdalnej aktualizacji wersji aplikacji. f) Możliwość blokady działania aplikacji do momentu użycia np. kodu PIN sprzedawcy lub karty sprzedawcy. g) Umożliwiać łączność z Systemem Centralnym bezpośrednio poprzez GSM z możliwością rozbudowy do LTE, lub za pośrednictwem WiFi. h) Urządzenie musi działać autonomicznie i nie wymagać podłączenia do komputera PC. Dane techniczne, które musi spełnić terminal PSB: a) Sposób komunikacji: siec ethernet, GSM/GPRS (z możliwością rozbudowy do LTE), b) Procesor: min. 450 MHz, 32 bit, c) Pamięć: min. 64 MB z możliwością rozbudowy, d) Gniazdo do obsługi kart pamięci: do 32GB, e) Wyświetlacz: min pixele (8 linii x 21 znaków), f) Czytnik kart zbliżeniowych obsługiwanych w systemie SBM, g) Klawiatura: 3 x 4, numeryczna, podświetlana, 12 klawiszy funkcyjnych, h) Porty komunikacyjne: 1 x Ethernet, 1 x RS-232, i) Drukarka: termiczna, min. 18 linii na sekundę, j) Modem do obsługi komunikacji poprzez sieć GSM, k) Zasilanie: z sieci 220/230V, l) Obsługa papieru termicznego o szerokości mm Terminal punktu akceptacji usług dodatkowych Terminal PSB to urządzenie przeznaczone do instalowania w Punktach akceptacji usług dodatkowych. Terminal PSB musi spełniać następujące wymagania funkcjonalne: 110

111 a) Potwierdzanie wykorzystania uprawnień do ulg / zniżek z pakietu usług dodatkowych. b) Zdalną możliwość aktualizacji parametrów aplikacji. c) Personalizację wydruków potwierdzeń operacji w karcie (unikalny numer terminala, nazwa punktu, adres punktu). d) Możliwość zdalnej aktualizacji wersji aplikacji. e) Możliwość blokady działania aplikacji do momentu użycia np. kodu PIN sprzedawcy lub karty sprzedawcy. f) Umożliwiać łączność z Systemem Centralnym bezpośrednio poprzez GSM z możliwością rozbudowy do LTE, lub za pośrednictwem WiFi. g) Urządzenie musi działać autonomicznie i nie wymagać podłączenia do komputera PC. Dane techniczne, które musi spełnić terminal punktu akceptacji usług dodatkowych: a) Sposób komunikacji: sieć wi-fi, GSM/GPRS (z możliwością rozbudowy do LTE), b) Procesor: min. 450 MHz, 32 bit, c) Pamięć: min. 64 MB z możliwością rozbudowy, d) Gniazdo do obsługi kart pamięci: do 32GB, e) Wyświetlacz: min pixele (8 linii x 21 znaków), f) Czytnik kart zbliżeniowych obsługiwanych w systemie SBM, g) Klawiatura: 3 x 4, numeryczna, podświetlana, 12 klawiszy funkcyjnych, h) Porty komunikacyjne: 1 x Ethernet, 1 x RS-232, i) Drukarka: termiczna, min. 18 linii na sekundę, j) Modem do obsługi komunikacji poprzez sieć GSM, k) Zasilanie: z sieci 220/230V, l) Obsługa papieru termicznego o szerokości mm Stanowisko przetwarzania danych i personalizacji kart przykładowe rozwiązanie a) Wykonawca dostarczy, wyposaży i skonfiguruje stanowiska niezbędne do przetwarzania danych w systemie oraz personalizacji kart b) Dostarczony sprzęt musi być fabrycznie nowy. c) Zamawiający zapewni przyłącze internetowe dla każdego stanowiska. d) Stanowiska zostaną zlokalizowane w miejscach wskazanych przez Zamawiającego. e) Każde z dostarczonych stanowisk do personalizacji kart musi być wyposażone w: 2 monitory LED o przekątnej ekranu nie mniejszej niż 21 Klawiaturę na USB, Mysz na USB, Zasilacz, Głośniki, Urządzenie wielofunkcyjne (skaner, xero, drukarka) przeznaczone do pracy biurowej. Stacja robocza o parametrach nie mniejszych niż: o Procesor czterordzeniowy o Częstotliwość procesora: 3,00GHz o Częstotliwość szyny: 1333MHz o Pojemność pamięci cache: 12MB o Dysk twardy: 1TB o Typ zainstalowanego dysku SATA II 111

112 o Pojemność zainstalowanej pamięci: 4GB o Rodzaj zainstalowanej pamięci: DDR3 o Częstotliwość szyny pamięci: 1600MHz o Karta graficzna: z wbudowaną pamięciom 1GB o Karta dźwiękowa: zintegrowana o Karta sieciowa zintegrowana o Typ zintegrowanej karty sieciowej: 10/100/1000 Mbit/s o Port szeregowy COM (serial) - minimum 1 o Porty USB - minimum 4 o Porty HDMI - minimum 1 o Napęd: Nagrywarka CD/DVD o Obudowa o Płyta główna o Oprogramowanie Windows V7, lub nowsze wraz z licencją. o Oprogramowanie biurowe Microsoft Office 2012 wraz z licencją. Drukarka do zadruku kart wraz z funkcją personalizacji elektronicznej (lub rozwiązanie równoważne). Ponadto Wykonawca zapewni materiały eksploatacyjne przez cały okres trwałości projektu Stanowisko obsługi klienta przykładowe rozwiązanie a) Wykonawca dostarczy, wyposaży i skonfiguruje wyposażenie oraz oprogramowanie stanowisk, poprzez które realizowana będzie bieżąca obsługa klienta i związane z tym przetwarzanie danych w systemie. b) Dostarczony sprzęt musi być fabrycznie nowy. c) Zamawiający zapewni przyłącze internetowe dla każdego stanowiska. d) Stanowiska zostaną zlokalizowane w miejscach wskazanych przez Zamawiającego. e) Każde z dostarczonych stanowisk do personalizacji kart musi być wyposażone w: Monitor LED o przekątnej ekranu nie mniejszej niż 21 Klawiaturę na USB, Mysz na USB, Zasilacz, Głośniki, Urządzenie wielofunkcyjne (skaner, xero, drukarka) przeznaczone do pracy biurowej. Stacja robocza o parametrach nie mniejszych niż: o Procesor czterordzeniowy o Częstotliwość procesora: 3,00GHz o Częstotliwość szyny: 1333MHz o Pojemność pamięci cache: 12MB o Dysk twardy: 1TB o Typ zainstalowanego dysku SATA II o Pojemność zainstalowanej pamięci: 4GB o Rodzaj zainstalowanej pamięci: DDR3 o Częstotliwość szyny pamięci: 1600MHz o Karta graficzna: z wbudowaną pamięciom 1GB o Karta dźwiękowa: zintegrowana o Karta sieciowa zintegrowana o Typ zintegrowanej karty sieciowej: 10/100/1000 Mbit/s o Port szeregowy COM (serial) - minimum 1 o Porty USB - minimum 4 o Porty HDMI - minimum 1 o Napęd: Nagrywarka CD/DVD 112

113 o Obudowa o Płyta główna o Oprogramowanie Windows V7, lub nowsze wraz z licencją. o Oprogramowanie biurowe Microsoft Office 2012 wraz z licencją. o Oprogramowanie antywirusowe: licencja na okres trwałości projektu. Urządzenie do personalizacji graficznej i elektronicznej kart funkcjonujących w systemie wraz z zapewnieniem materiałów eksploatacyjnych przez cały okres trwałości projektu.. Cyfrowy aparat fotograficzny, spełniający wymagania: o zoom optyczny: min. 10, o zasilanie: akumulatorki (min. 2 komplety), typ dowolny wraz z ładowarką (jeżeli jest wymagana), o rozdzielczość matrycy: min. 10,0 miliona pikseli, o optyczna stabilizacja obrazu, o wyświetlacz LCD o przekątnej min. 3,5, o pamięć aparatu z możliwością rozbudowy. Karty powiększające pojemność pamięci aparatu o pojemności 16 GB (3 szt. / aparat) Stanowisko nadzoru Przykładowe rozwiązanie a) Wykonawca dostarczy, wyposaży i skonfiguruje wyposażenie oraz oprogramowanie stanowisk, poprzez które realizowane będą zadania dotyczące nadzoru funkcjonowania systemu. b) Dostarczony sprzęt musi być fabrycznie nowy. c) Zamawiający zapewni przyłącze internetowe dla każdego stanowiska. d) Stanowiska zostaną zlokalizowane w miejscach wskazanych przez Zamawiającego. e) Każde z dostarczonych stanowisk do personalizacji kart musi być wyposażone w: 2 monitory LED o przekątnej ekranu nie mniejszej niż 21 Klawiaturę na USB, Mysz na USB, Zasilacz, Głośniki, Urządzenie wielofunkcyjne (skaner, xero, drukarka) przeznaczone do pracy biurowej. Stacja robocza o parametrach nie mniejszych niż: o Procesor czterordzeniowy o Częstotliwość procesora: 3,00GHz o Częstotliwość szyny: 1333MHz o Pojemność pamięci cache: 12MB o Dysk twardy: 1TB o Typ zainstalowanego dysku SATA II o Pojemność zainstalowanej pamięci: 4GB o Rodzaj zainstalowanej pamięci: DDR3 o Częstotliwość szyny pamięci: 1600MHz o Karta graficzna: z wbudowaną pamięciom 1GB o Karta dźwiękowa: zintegrowana o Karta sieciowa zintegrowana o Typ zintegrowanej karty sieciowej: 10/100/1000 Mbit/s o Port szeregowy COM (serial) - minimum 1 o Porty USB - minimum 4 o Porty HDMI - minimum 1 o Napęd: Nagrywarka CD/DVD 113

114 o Obudowa o Płyta główna o Oprogramowanie Windows V7, lub nowsze wraz z licencją. o Oprogramowanie biurowe Microsoft Office 2012 wraz z licencją. o Przenośne urządzenie typu Smartfon z funkcją telefonu komórkowego (GSM) wraz z abonamentem na cały okres trwałości projektu. o Oprogramowanie najnowszej wersji pakietu graficznego Corel w polskiej wersji językowej wraz z licencją. o Dodatkowy ekran (4 połączone, bezramkowe monitory ścienne, każdy co najmniej 24 cale) do podglądu sytuacji na mapie. o Oprogramowanie antywirusowe: licencja na okres trwałości projektu Wielofunkcyjne urządzenie o dużej wydajności z funkcją: Drukowanie w kolorze, Skanowanie, Kopiowanie, Faks. Urządzenie umożliwiające druk w formacie maks. A3 przy obciążeniu 1100 str./dzień. Wykonawca zapewni materiały eksploatacyjne przez cały okres trwałości projektu Pojazd samochodowy o podwyższonym zawieszeniu do nadzoru nad realizacją wdrożenia i funkcjonowania systemu. Wymagania ogólne dotyczące pojazdów dla nadzoru technicznego: Pojazd samochodowy musi być fabrycznie nowy (dopuszczalny przebieg dostarczonego pojazdu max. 150 km, pojazd nie może być w dniu jego dostarczenia starszy niż 7 miesięcy od daty produkcji), pojazd musi być sprawny technicznie i gotowy do użytkowania, Pojazd dla nadzoru technicznego muszą posiadać autoryzowany serwis gwarancyjny na terenie Polski, Pojazd dla nadzoru technicznego musi być zakupiony w sieci dilerskiej producenta pojazdów lub autoryzowanym przez producenta pojazdów salonie sprzedaży na terenie Unii Europejskiej, Pojazd musi być przekazany w użytkowanie Zamawiającego dla nadzoru realizacji i funkcjonowania systemu nie później niż w przeciągu maksymalnie 120 dni kalendarzowych od dnia podpisania Umowy. Pojazd musi umożliwiać i mieć zagwarantowane przez Wykonawcę Systemu wykonanie limitu przejazdów określonego na poziomie min km/miesiąc (2500 tysiąca kilometrów miesięcznie) dla pojazdu przez cały okres realizacji Systemu. Całkowite koszty związane z eksploatacją pojazdów (paliwo, serwis, bieżące utrzymanie) przez cały okres realizacji Systemu pokrywa Wykonawca Systemu w ramach Umowy. Zamawiający wymaga aby dla dostarczonego pojazdu był zapewniony i umożliwiony bezgotówkowy zakup paliwa (uzupełnienia paliwa) w min. 2 punktach dystrybucji paliw na terenie miasta Bydgoszczy należących do jednej sieci dystrybucji paliw. Zamawiający wymaga aby dla dostarczonego pojazdu była zapewniona i umożliwiona bezgotówkowa obsługa serwisowa w pełnym zakresie (m.in. w zakresie napraw, przeglądów technicznych, zmiany ogumienia, naprawy ogumienia, napraw blacharsko-lakierniczych) w min. 1 punkcie serwisowym. Dostarczony pojazd musi być zarejestrowany i zatankowany, umożliwiając jego natychmiastową eksploatację od momentu przekazania Zamawiającemu. Pojazdy samochodowy musi posiadać przez cały okres ich eksploatacji przez Zamawiającego obowiązkowe ubezpieczenie Odpowiedzialności Cywilnej (OC), 114

115 ubezpieczenie AUTO CASCO (AC) oraz ubezpieczenie Następstw Nieszczęśliwych Wypadków (NNW) dla kierowcy i pasażerów pojazdu, całkowite koszty ubezpieczenia pojazdów w okresie realizacji Systemu pokrywa Wykonawca Systemu. Ubezpieczenie pojazdów jest po stronie Wykonawcy i winno być realizowane w zakresie przedstawiania Polis Zamawiającemu zgodnie z zasadami dotyczącymi innych ubezpieczeń podczas realizacji Systemu opisanych w Umowie. Uwaga: Ubezpieczenie dotyczące możliwości uzyskania odszkodowania w przypadku kradzieży pojazdu, jego uszkodzenia lub dewastacji przez osoby postronne nie może być ograniczone do konkretnego miejsca postoju lub garażowania pojazdu oraz wskazywać w jakikolwiek sposób garażowania pojazdu lub postoju pojazdu na dozorowanym miejscu postojowym. Koszty przeglądów gwarancyjnych oraz okresowych pojazdu użytkowanego przez Zamawiającego pokrywa Wykonawca Systemu Wykonawca winien zapewnić również utrzymanie czystości pojazdu użytkowanego przez Zamawiającego poprzez możliwość bezgotówkowego utrzymania czystości pojazdów nadzoru technicznego (np. wykupienie karnetu, limitu usług, usługi przedpłaconej) w jednym z serwisów czyszczących pojazdy na terenie miasta Bydgoszczy z następującą minimalną częstotliwością tych usług: o mycie i pielęgnacją nadwozia min. 1 raz w tygodniu, o czyszczenie wnętrza min. 1 raz w miesiącu, o mycie podwozia min. 2 razy w roku, w tym zawsze min. 1 raz po okresie zimowym przez cały okres realizacji Systemu (użytkowania pojazdów przez Zamawiającego). W przypadku wystąpienia awarii pojazdu (awarii technicznej lub będącej wynikiem zdarzenia drogowego) uniemożliwiającej jego dalszą normalną eksploatację przez nadzór techniczny Zamawiającego w okresie następnych 5 dni kalendarzowych Wykonawca Systemu niezwłocznie przekaże pojazd do serwisu i dostarczy Zamawiającemu pojazd zastępczy o parametrach technicznych zbliżonych do pojazdu dostarczonego pierwotnie. Wymagania techniczne podstawowe dotyczące pojazd typ pojazdu: pojazd samochodowy o podwyższonym zawieszeniu spełniający wymagane parametry techniczno funkcjonalne określone poniżej nadwozie pięciodrzwiowe, napęd pojazdu na przednią oś pojazdu, rodzaj paliwa: benzyna bezołowiowa lub olej napędowy, skrzynia biegów: manualna maksymalna moc silnika: o benzynowego: nie mniej niż 120 KM (koni mechanicznych), o diesla: nie mniej niż 140 KM (koni mechanicznych) pojemność silnika powinna się zawierać w przedziale: od 1800 cm 3 do 2500 cm 3, przyspieszenie pojazdu od km/h nie więcej niż: 12,0 [s], obręcze kół wykonane ze stopów metali lekkich (np. aluminium lub stopów innych metali lekkich o podobnych właściwościach), pojazd wyposażony w kpl. 4 szt. opon letnich (jako wyposażenie fabryczne). Zamawiajacy nie dopuszcza wyposażenia pojazdu w ogumienie wielosezonowe tzw. all seasons podczas użytkowania pojazdów przez Zamawiającego, hamulce kół przednich: tarczowe, wspomagany układ kierowniczy, klimatyzacja automatyczna min. jednostrefowa dopuszczalna liczba osób podróżujących łącznie w pojeździe min. 5, 115

116 sterowane elektrycznie lusterka boczne, centralny zamek sterowany zdalnie za pomocą kluczyka lub karty uruchamiającej pojazd, min. poduszki powietrzne przednie dla kierowcy i pasażera, min. poduszki boczne przednie, kurtyny powietrzne boczne dla I i II rzędu siedzeń (osobne lub wspólne), napinacze pasów bezpieczeństwa, pojemność bagażnika przy siedzeniach rozłożonych (tj. pozycja foteli normalna, umożliwiająca podróżowanie równocześnie w pojeździe 5 osób) mierzona do dolnej linii okien w tylnej części pojazdu: min. 370 litrów zbiornik paliwa o pojemności: minimum 45 L (litry), wymiary zewnętrzne (według danych katalogowych podawanych przez producentów pojazdów): o całkowita długość pojazdu (według specyfikacji fabrycznej zawartej w ogólnodostępnych katalogach i broszurach pojazdu) zawarta pomiędzy wartościami: 4000 mm 4755 mm, o rozstaw osi pojazdu zawarty pomiędzy wartościami: 2600 mm 2750 mm, o rozstaw kół na osi przedniej i tylnej pojazdu zawarty pomiędzy wartościami: 1520 mm 1650 mm, o prześwit pojazdu (wartość katalogowa) zawarty pomiędzy wartościami: 175 mm 250 mm, dodatkowe gniazdo zasilania 12 V w przedziale bagażowym pojazdu (może być gniazdo zamontowane dodatkowo poza wyposażeniem fabrycznym), instalacja radiowa z systemem RDS obsługiwana w podstawowym zakresie z koła kierownicy (w min. zakresie sterowania poziomem głośności), kierownica z wbudowanymi przyciskami lub innymi manipulatorami umożliwiającymi sterowanie radiem (w min. zakresie sterowania poziomem głośności ) bez odrywania rąk kierowcy od koła kierownicy podczas jazdy (bez żadnych dodatkowych elementów sterowania radiem montowanych na kole kierownicy lub obudowie kolumny kierownicy nie stanowiących fabrycznego wyposażenia pojazdu typu np. joystick), min. system ABS (system zapobiegający blokowaniu kół podczas hamowania), przednie światła przeciwmgielne, czujniki parkowania min. z tyłu pojazdu lub inny system alternatywny zapewniający bezpieczne cofanie pojazdem (np. kamera cofania), elektrycznie sterowane szyby: minimum przednie, pojazd musi być wyposażony w przyciemniane szyby w tylnej części przedziału pasażerskiego tj. tylne szyby boczne oraz szybę tylną centralną (przyciemnienie szyb materiałami posiadającymi atest i dopuszczenie do stosowania w pojazdach użytkowanych na terenie dróg publicznych kraju Zamawiającego może być wykonane poza miejscem produkcji pojazdu tylko wtedy gdy pojazd nie posiadał takiej opcji w żadnej dostępnej wersji fabrycznej jako opcja wyposażenia (standardowego lub dodatkowego), w innym przypadku tj. kiedy taka opcja wyposażenia była dostępna fabrycznie należy oprzeć się zawsze w realizacji wymogu na wyposażeniu seryjnym lub opcjonalnym producenta pojazdu), regulowane położenie kolumny kierownicy, pojazd wyposażony w relingi dachowe umożliwiające montaż bagażnika dachowego wraz z kpl. (2 szt.) belek poprzecznych bagażnika dachowego wykonanymi ze stopów metali lekkich zamontowanymi do fabrycznych relingów dachowych pojazdu, lakier metalizowany w kolorze: grafitowym, szarym, brązowym lub innym kolorze bardzo do tych kolorów zbliżonym. tapicerka siedzeń oraz wnętrza pojazdu ciemna, np. szara, grafitowa (tj. nie biała i nie beżowa), 116

117 Wymagane dodatkowe wyposażenie: Ogumienie zimowe, tj. kpl. 4 szt. opon zimowych wraz z felgami ze stopu metali lekkich. Ogumienie zimowe musi być dostępne zawsze w okresie: od 15 października do 15 kwietnia przez cały czas realizacji Systemu, wraz z montażem, wyważeniem i przechowywaniem zmienianych opon letnich (ogumienia letniego) w serwisie ogumienia). Koszty zmiany ogumienia, wyważenia i przechowywania ponosi Wykonawca Systemu. Instalacja samochodowa do obsługi telefonu GSM w technologii Bluetooth umożliwiającej prowadzenie rozmowy przez kierowcę podczas kierowania pojazdem. Instalacja powinna być zainstalowana w pojeździe samochodowym w sposób umożliwiający wykorzystanie do jej częściowej obsługi (w zakresie odsłuchu) głośników samochodowych zainstalowanych fabrycznie w pojeździe. Autoalarm z dodatkowym zabezpieczeniem przed uruchomieniem pojazdu Przenośny komputer o parametrach (minimalnych) [Bydgoszcz: 3 szt.]: Przekątna ekranu: 17.3 cali o Nominalna rozdzielczość: 1920x1080 pikseli o Typ ekranu: matowy Procesor o Ilość rdzeni: 4 o Taktowanie procesowa: 3GHz o Pamięć podręczna (Cashe): 6MB Wielkość pamięci RAM: 6GB Typ paięci RAM: DDR3 (1600 MHz) Dyski: o magnetyczny: 500GB o SSD: 128 GB Karta graficzna z własną pamięcią: 1GB Nagrywarka DVD, Karta dźwiękowa: zintegrowana Czytnik kart pamięci: SD/SDXC/MMC Komunikacja: o WiFi IEEE b/g/n o LAN 1Gbps o Bluetooth USB 3.0: 3 szt. USB 2.0: 1 szt. System operacyjny: o Windows 8.1 Pakiet biurowy Ms Office 2012 (Word, Excel, PowerPoint, Acces) w polskiej wersji językowej. Oprogramowanie antywirusowe: licencja na okres trwałości projektu. 117

118 24. Analiza przemieszczeń podróżnych Założenia wstępne Oprogramowanie przygotowane dla Systemu Biletu Metropolitalnego musi posiadać moduł odpowiedzialny za prowadzenie analiz przemieszczania pasażerów w środkach transportu publicznego (autobus, tramwaj, kolej) System musi umożliwiać prowadzenie analiz związanych z przemieszczaniem pasażerów w oparciu o zasadę check in check out. Idea niniejszego systemu została przedstawiona na rysunku - Rysunek W przypadku wyłączenia opcji check out system musi umożliwiać dokonywanie analiz uproszczonych wyłącznie w oparciu o opcję check in Zastosowanie elektronicznej metody pomiarów ruchu potoków pasażerskich musi pozwalać na bieżące prowadzenie analiz wszelkich wskaźników dla transportu publicznego Pomiary potoków pasażerskich będą wykonywane w celu usprawnienia i dostosowywania oferty przewozowej do rzeczywistych potoków pasażerskich oraz w celu dokonywania rozliczeń pomiędzy poszczególnymi stronami uczestniczącymi w projekcie Systemu Biletu Metropolitalnego W ramach wprowadzonego systemu check in check out będą funkcjonowały wszystkie bilety kodowane na kartach zbliżeniowych oraz bilety jednorazowe, które zostaną zakupione w automatach biletowych lub w punktach obsługi pasażerów Przedstawione w niniejszym rozdziale wymagania stanowią wymagania minimum a przedstawione rozwiązania projektowe mogą być zrealizowane w inny sposób przy zachowaniu wszystkich funkcjonalności Wykonawca musi dostarczyć oprogramowanie najwyższej jakości, spełniające wymogi normy ISO/IEC :2001 (Analiza Modelu Jakości Produktów Programowych) Funkcjonalności modułu Analiz Przemieszczeń Pasażerów. Moduł Analiz Przemieszczeń Pasażerów musi zawierać następujące funkcjonalności (aplikacje): a) Aplikacja Analiza ruchu pasażerskiego na przystankach, b) Aplikacja Analiza ruchu pasażerskiego na liniach komunikacyjnych transportu publicznego, c) Aplikacja Analiza ruchu pasażerskiego w przekroju trasy komunikacyjnej, d) Aplikacja Analiza jazd, podróży i systemu przesiadkowego, e) Aplikacja Analiza parametrów sieciowych w przewozach pasażerskich, f) Aplikacja Analiza udziału grup społecznych w przewozach pasażerskich, g) Aplikacja Analiza napełnienia pojazdów i komfortu podróży, h) Aplikacja Analiza przemieszczeń pasażerów, i) Aplikacja Tendencje zmian parametrów sieciowych w przewozach pasażerskich, j) Aplikacja Mapa dla modułu Analizy przemieszczeń pasażerów, k) Aplikacja Export danych do programu VISUM. 118

119 24.3. Aplikacja ANALIZA RUCHU PASAŻERSKIEGO NA PRZYSTANKACH funkcjonalność aplikacji Aplikacja analiza ruchu pasażerskiego na przystankach musi dostarczać pełnej informacji w zakresie ruchu pasażerów na przystankach komunikacyjnych transportu publicznego. Informacje dotyczące ruchu pasażerskiego będą obejmowały następujące dane: 119

120 PRZYSTANEK NR 2 PRZYSTANEK NR 3 PRZYSTANEK NR 4 PRZYSTANEK NR 5 PRZYSTANEK NR 6 WEJŚCIE WYJŚCIE ŚRODEK TRANSPORTU TRAMWAJ, AUTOBUS, KOLEJ CHECK IN CHECK OUT TRAMWAJ, AUTOBUS, KOLEJ PASAŻER ZBLIŻA KARTĘ DO KASOWNIKA (CZYTNIKA) PASAŻER ZBLIŻA KARTĘ DO KASOWNIKA (CZYTNIKA) PASAŻER OCZEKUJE NA PRZYJAZD ŚRODKA TRANSPORTU PASAŻER WYCHODZI Z ŚRODKA TRANSPORTU PUBLICZNEGO Rysunek 41 Filozofia systemu Check In Check out. 120

121 a) liczba pasażerów wsiadających w odniesieniu do wybranej linii komunikacyjnej, grup linii komunikacyjnych lub do wszystkich linii korzystających z danego przystanku komunikacyjnego, b) liczba pasażerów wysiadających (w przypadku funkcjonowania systemu z opcją check out ) w odniesieniu do wybranej linii komunikacyjnej, grup linii komunikacyjnych lub do wszystkich linii korzystających z danego przystanku komunikacyjnego, c) sumaryczny ruch pasażerski na każdym przystanku komunikacyjnym transportu publicznego (w przypadku funkcjonowania systemu z opcją check out ) w odniesieniu do wybranej linii komunikacyjnej, grup linii komunikacyjnych lub do wszystkich linii korzystających z danego przystanku, d) liczba pasażerów przesiadających się pomiędzy liniami komunikacyjnymi (możliwość wybrania dwóch linii komunikacyjnych lub wielu linii komunikacyjnych) zatrzymującymi się na danym przystanku określenie granicznego maksymalnego czasu na przesiadkę Dane te będą tworzone w zakresie wybranego okresu czasu (godzinowego i dobowego). Okres ten będzie możliwy do zdefiniowania przy pomocy stworzonego przez wykonawcę kalendarza. Aplikacja musi posiadać funkcję kalendarza i zegara umożliwiające określenie czasu analizy. Szczegóły dotyczące stworzenia funkcji kalendarza zawarto w rozdziale opisującym moduł Kalendarz Aplikacja musi umożliwiać prowadzenie analiz dla utworzonych obszarów, miast, gmin oraz stref - zdefiniowanych na etapie tworzenia oferty taryfowej Musi istnieć możliwość wykonania pełnej analizy danych ruchu pasażerów na przystankach komunikacyjnych transportu publicznego w wybranych obszarach lub dla całego obszaru. W tym celu należy stworzyć narzędzie pozwalające eksportować dane do arkusza kalkulacyjnego Excel oraz zapis danych do pliku w formacie pdf. Analizy te będą wykonywane poza tworzonym systemem przy dowolnym podziale linii i przystanków komunikacyjnych transportu publicznego (podział godzinowy i dobowy) Musi istnieć narzędzie umożliwiające szczegółową analizę danych o pasażerach na wybranych przystankach komunikacyjnych transportu publicznego lub w odniesieniu do wybranych linii komunikacyjnych transportu publicznego. Wybór danego przystanku transportu publicznego może być dokonywany na podstawie: a) bezpośredniego wskazania numeru i nazwy przystanku (możliwe jednoczesne wskazanie kilku przystanków np. dla przebiegu danej linii transportu publicznego), b) pośredniego wskazania numeru i nazwy przystanku poprzez wskazanie w pierwszej kolejności nazwy ulicy i kierunku (możliwe jednoczesne wskazanie kilku przystanków np. dla przebiegu danej linii transportu publicznego), c) wyboru węzła komunikacyjnego, d) wyboru konkretnej linii komunikacji transportu publicznego Aplikacja musi umożliwić tworzenie analiz dla wybranej dowolnej grupy przystanków oraz przystanków przypisanych do danego węzła komunikacyjnego. 121

122 Aplikacja musi umożliwiać tworzenie raportów oraz wykresów. Wykresy będą tworzone wyłącznie w odniesieniu do analiz szczegółowych. Analiza przeprowadzona dla wybranych linii transportu publicznego musi odbywać się dla doby, jak również dla wybranej godziny/godzin w dobie Musi istnieć możliwość analizy danych dla poszczególnych kursów Musi istnieć możliwość wydruku raportów oraz wykresów i exportu danych do programu Excel, jak również zapis danych do plików w formacie pdf Przykładowe rozwiązanie funkcjonalne aplikacji przedstawiono na rysunku - Rysunek Dane o przystankach dla modułu przemieszczeń pasażerów muszą być również dostępne z poziomu modułu Mapa. 122

123 w przypadku analizy wybranej linii transportu publicznego liczba pasażerów [pas/dobę] liczba pasażerów [pas/h] w przypadku analizy wybranej linii transportu publicznego liczba pasażerów [pas/dobę] Analiza ruch pasażerskiego na przystankach miasto/gmina/strefa Bydgoszcz Toruń Gmina Solec Kujawski Gmina Koronowo.. Strefa 1 Strefa 2.. Cały system transportowy RAPORT DATA ANALIZY BYDGOSZCZ Akademicka-Kaliskiego kier. Centrum wszystkie linie na przystanku liczba wsiadających suma liczba wysiadających suma sumaryczny ruch podróżnych suma liczba przesiadek raport wykres lokalizacja przystanku/wybór numeru linii transportu publicznego pełna analiza pasażerska nazwa ulicy numer przystanku wybór z listy suma export danych do Excela zapis danych do pliku pdf RAPORT DATA ANALIZY RAPORT DATA ANALIZY BYDGOSZCZ BYDGOSZCZ Akademicka-Kaliskiego kier. Centrum linia autobusowa nr Akademicka-Kaliskiego kier. Centrum bez podziału na linie suma suma wybór kierunku lista przystanków liczba wysiadających kolejna godzina analizy liczba wysiadających kolejna godzina analizy suma lub/i suma Korfantego-Prejsa kier. Fordon kolejna godzina analizy lub/i liczba wsiadających sumaryczny ruch podróżnych 002 Szubińska-Piękna kier. Centrum suma suma 003 Andersa-Kaliskiego kier. Centrum wybór linii transportu publicznego Gdańska-Chodkiewicza kier.lpkiw liczba przesiadek kolejna godzina analizy liczba przesiadek kolejna godzina analizy. pasażerowie wszystkie linia autobusowa nr linie transportu publicznego wszyscy linia autobusowa nr suma suma wsiadający wybór z listy wysiadający 001 Akademicka-Kaliskiego kier. Centrum linia autobusowa nr 94 linia tramwajowa nr 1 sumaryczny ruch podróżnych.. linia tramwajowa nr 2 liczba przesiadek linia kolejowa BiT City linia autobusowa nr 52 kolejna godzina analizy kolejna godzina analizy kolejna godzina analizy zapis danych do pliku pdf export danych do Excela wybór z listy Akademicka Al. Kaliskiego Al. Mickiewicza Al. Piłsudskiego.. okres raportowania wybór dowolnego dnia z kalendarza wybór dowolnych dni z kalendarza wybór dowolnych godzin z dowolnego dnia/dni wartości średnie wartości maksymalne Dane o przystankach muszą być również dostępne z aplikacji Mapa dla modułu przemieszczeń pasażerów raport wykres WYBRANIE OKRESU ANALIZY kier. Centrum kier. przeciwny Akademicka - Igrzyskowa kier. Centrum Akademicka - Kaliskiego kier. Centrum. Liczba pasażerów na przystanku Akademicka-Kaliskiego kier. Centrum, wszystkie linie na przystanku, rok , miesiąc - luty, dzień - czwartki liczba pasażerów ogółem liczba wsiadajacych liczba wysiadających liczba przesiadek kolejna godzina analizy zapis danych do pliku pdf liczba wsiadających sumaryczny ruch podróżnych lub/i kolejna godzina analizy kolejna godzina analizy Liczba pasażerów na przystankach linii autobusowej nr 70 kier. Centrum, liczba pasażerów ogółem liczba wsiadajacych liczba wysiadających kolejny przystanek na trasie linii transportu publicznego zapis danych do pliku pdf Liczba pasażerów na przystankach linii autobusowej nr 70 kier. Centrum, liczba pasażerów ogółem liczba przesiadek kolejna godzina analizy kolejna godzina analizy kolejny przystanek na trasie linii transportu publicznego zapis danych do pliku pdf Rysunek 42 Aplikacja Analiza ruchu pasażerskiego na przystankach przykładowe rozwiązanie. 123

124 24.4. Aplikacja ANALIZA RUCHU PASAŻERSKIEGO NA LINIACH KOMUNIKACYJNYCH TRANSPORTU PUBLICZNEGO funkcjonalność aplikacji Aplikacja analiza ruchu pasażerskiego na liniach komunikacyjnych transportu publicznego musi dostarczać pełnej informacji w zakresie ruchu pasażerów na poszczególnych liniach komunikacyjnych oraz zbiorcze zestawienie danych (export danych do pliku Excela i zapis danych w formacie pliku pdf) dla linii autobusowych, linii tramwajowych, linii kolejowej BiT City i dla wszystkich linii razem Aplikacja musi posiadać funkcję kalendarza i zegara umożliwiające określenie czasu analizy Aplikacja będzie analizowała dane pozyskane w ramach systemu check in check out. W przypadku wyłączenia niniejszej funkcjonalności systemu aplikacja nie będzie aktywna Informacje dotyczące ruchu pasażerskiego będą obejmowały następujące dane: a) sumaryczna liczba pasażerów w odniesieniu do wybranej linii komunikacyjnej z podziałem na poszczególne odcinki międzyprzystankowe (analiza dobowa wszystkie kursy), b) sumaryczna liczba pasażerów w odniesieniu do wybranej linii komunikacyjnej z podziałem na poszczególne odcinki międzyprzystankowe (analiza dobowa bez podziału na poszczególne kursy), c) sumaryczna liczba pasażerów w odniesieniu do wybranej linii komunikacyjnej z podziałem na poszczególne odcinki międzyprzystankowe (analiza godzinowa wszystkie kursy), d) sumaryczna liczba pasażerów w odniesieniu do wybranej linii komunikacyjnej z podziałem na poszczególne odcinki międzyprzystankowe (analiza godzinowa bez podziału na poszczególne kursy) Aplikacja musi umożliwiać export danych (raportów) do formatu Excela oraz zapis danych do pliku w formacie pdf Aplikacja musi umożliwiać tworzenie wykresów na podstawie przeprowadzonych analiz i ich zapis w formacie plików pdf Przykładowe rozwiązanie funkcjonalne aplikacji przedstawiono na rysunku - Rysunek Dane o liniach komunikacyjnych dla modułu przemieszczeń pasażerów muszą być również dostępne z poziomu modułu Mapa. 124

125 liczba pasażerów [pas/h liczba pasażerów [pas/dobę] Analiza ruch pasażerskiego na liniach komunikacyjnych transportu publicznego Dane o liniach komunikacyjnych muszą być również dostępne z aplikacji Mapa dla modułu przemieszczeń pasażerów miasto/gmina/strefa Bydgoszcz Toruń Gmina Solec Kujawski Gmina Koronowo.. Strefa 1 Strefa 2.. Cały system transportowy Wybór linii transportu publicznego pełna analiza wszystkich linii pełna analiza linii kolejowych pełna analiza linii tramwajowych pełna analiza linii autobusowych linia tramwajowa nr 1 linia tramwajowa nr 2. Raport godzinowy n-kursów RAPORT DATA ANALIZY BYDGOSZCZ linia tramwajowa nr 2 kier. przeciwny Liczba pasażerów [pas/h] analiza w godz.15:00-16:00 2 kolejny numer przystanku suma 307 Typ transferu danych Export danych do Excela Export danych do pliku pdf kierunek centrum przeciwny Rodzaj analizy Analiza dobowa Analiza godzinowa Rodzaj analizy Analiza dobowa Analiza godzinowa Wybór dnia i godzin analizy :00 Wybór dnia i godzin analizy 15:00 17:00 16:00 22:00 16:00 Liczba pasażerów na linii tramwajowej nr 1, kier. Przeciwny, , godz. 15:00-16:00 RAPORT DATA ANALIZY BYDGOSZCZ linia tramwajowa nr 2 kier. przeciwny Liczba pasażerów [pas/dobę] analiza dobowa 2 kolejny numer przystanku Raport Wykres Export danych do pliku pdf Export danych do Excela Raport Wykres Export danych do pliku pdf Export danych do Excela Raport dobowy n-kursów suma Raport dobowy poszczególne kursy RAPORT DATA ANALIZY BYDGOSZCZ linia tramwajowa nr 2 kier. przeciwny Raport godzinowy poszczególne kursy 10 Liczba pasażerów [pas/kurs] analiza dobowa 2 kolejny numer przystanku RAPORT DATA ANALIZY 9 liczba pasażerów [pas/h] 04:50 05: :10 suma BYDGOSZCZ linia tramwajowa nr 2 kier. przeciwny Liczba pasażerów [pas/kurs] analiza w godz.15:00-16:00 2 kolejny numer przystanku :05 15:15 15:30 15:45 16:00 suma kolejny przystanek na trasie linii transportu publicznego Wykres godzinowy n-kursów Liczba pasażerów na linii tramwajowej nr 1, kier. Przeciwny, liczba pasażerów [pas/dobę] kolejny przystanek na trasie linii transportu publicznego Rysunek 43 Aplikacja Analiza ruchu pasażerskiego na liniach komunikacyjnych transportu publicznego przykładowe rozwiązanie. 125

126 24.5. Aplikacja ANALIZA RUCHU PASAŻERSKIEGO W WYBRANYM PRZEKROJU TRASY KOMUNIKACYJNEJ funkcjonalność aplikacji Aplikacja analiza ruchu pasażerskiego w wybranym przekroju trasy komunikacyjnej musi dostarczać pełnej informacji w zakresie ruchu pasażerów w przekroju trasy komunikacyjnej oraz zbiorcze zestawienie danych dla sieci transportowej danego obszaru (export danych do pliku Excela i zapis danych w formacie pliku pdf) z podziałem na poszczególne linie komunikacyjnej autobusowe, tramwajowe, kolejowe BiT City i dla wszystkich linii razem Aplikacja musi posiadać funkcję kalendarza i zegara umożliwiające określenie czasu analizy. Aplikacja będzie analizowała dane pozyskane w ramach systemu check in check out. W przypadku wyłączenia niniejszej funkcjonalności systemu aplikacja nie będzie aktywna Informacje dotyczące ruchu pasażerskiego będą obejmowały następujące dane: a) sumaryczna liczba pasażerów w odniesieniu do wybranego przekroju trasy komunikacyjnej z podziałem na poszczególne linie komunikacyjne (analiza dobowa), b) sumaryczna liczba pasażerów w odniesieniu do wybranego przekroju trasy komunikacyjnej bez podziału na poszczególne linie komunikacyjne (analiza dobowa), c) sumaryczna liczba pasażerów w odniesieniu do wybranego przekroju trasy komunikacyjnej z podziałem na poszczególne linie komunikacyjne (analiza godzinowa), d) sumaryczna liczba pasażerów w odniesieniu do wybranego przekroju trasy komunikacyjnej bez podziału na poszczególne linie komunikacyjne (analiza godzinowa) Aplikacja musi umożliwiać export danych (raportów) do formatu Excela oraz zapis danych do pliku w formacie pdf. Aplikacja musi umożliwiać tworzenie wykresów na podstawie przeprowadzonych analiz i ich zapis w formacie plików pdf Przykładowe rozwiązanie funkcjonalne aplikacji przedstawiono na rysunku - Rysunek

127 liczba pasażerów [pas/dobę liczba pasażerów [pas/dobę Analiza ruch pasażerskiego w wybranych przekrojach tras komunikacyjnych Dane o przekrojach tras komunikacyjnych muszą być również dostępne z aplikacji Mapa dla modułu przemieszczeń pasażerów miasto/gmina/strefa Bydgoszcz Toruń Wybór linii transportu publicznego pełna analiza wszystkich przekrojów linie transportu publicznego w przekroju trasy komunikacyjnej Typ transferu danych Export danych do Excela Export danych do pliku pdf Rodzaj analizy Analiza dobowa Analiza godzinowa Wybór dnia i godzin analizy :00 16: Liczba pasażerów na ul. AKADEMICKIEJ (Kaliskiego - Igrzyskowa), linie nr 70, 94, data: linia nr 94 linia nr 70 Gmina Solec Kujawski Gmina Koronowo.. Strefa 1 Strefa 2.. Cały system transportowy wybór ulicy z listy Akademicka Al. Kaliskiego Al. Mickiewicza Al. Piłsudskiego.. kierunek centrum przeciwny dwa kierunki wybór przekroju ulicy z listy 17 Rejewskiego - Romanowskiej 18 Romanowskiej - Kaliskiego 19 Kaliskiego - Igrzyskowa 20 Igrzyskowa - Andersa RAPORT DATA ANALIZY BYDGOSZCZ AKADEMICKA (KALISKIEGO - IGRZYSKOWA) linia 70 kier. przeciwny Liczba pasażeró [pas/dobę] analiza dobowa 2 kolejna doba linia 94 Liczba pasażeró [pas/dobę] analiza dobowa średnia 32 kier. przeciwny kolejna doba 5 średnia ROZDZIEL NA LINIE TRANSPORTU PUBLICZNEGO Raport Wykres RAPORT DATA ANALIZY BYDGOSZCZ AKADEMICKA (KALISKIEGO - IGRZYSKOWA) linie kier. przeciwny Liczba pasażeró [pas/dobę] analiza dobowa 2 kolejna doba średnia kolejna doba średnia 45 Rodzaj analizy Wybór dnia i godzin analizy Export danych do pliku pdf Raport Export danych do pliku pdf Export danych do Excela Analiza dobowa Analiza godzinowa :00 20: Export danych do Excela Raport Wykres 17:00 22:00 Export danych do pliku pdf Export danych do Excela Liczba pasażerów na ul. AKADEMICKIEJ (Kaliskiego - Igrzyskowa), linie nr 70, 94, data: liczba pasażerów [pas/dobę] linia autobusowa nr 70 WYNIKI W POSTACI MACIERZY X[DOBA], Y[GODZINA] linia autobusowa nr 94 WYNIKI W POSTACI MACIERZY X[DOBA], Y[GODZINA] RAPORT DATA ANALIZY BYDGOSZCZ AKADEMICKA (KALISKIEGO - IGRZYSKOWA) linia 70 kier. przeciwny Liczba pasażeró [pas/h] analiza godzinowa 15:00 kolejna godzina 15:00 16:00 17:00 18:00 19:00 średnia linia 94 kier. przeciwny Liczba pasażeró [pas/h] analiza godzinowa 5 2 kolejna godzina 15:00 16:00 17:00 18:00 19:00 średnia Wykres należy utworzyć wg scheamtu jak dla analiz dobowych ROZDZIEL NA LINIE TRANSPORTU PUBLICZNEGO średnia kolejna doba RAPORT DATA ANALIZY BYDGOSZCZ AKADEMICKA (KALISKIEGO - IGRZYSKOWA) linie kier. przeciwny Liczba pasażeró [pas/h] analiza godzinowa 2 kolejna godzina 15:00 16:00 17:00 18:00 19:00 średnia Rysunek 44 Aplikacja Analiza ruchu pasażerskiego w wybranych przekrojach tras komunikacyjnych przykładowe rozwiązanie. 127

128 24.6. Aplikacja ANALIZA JAZD, PODRÓŻY I SYSTEMU PRZESIADKOWEGO funkcjonalność aplikacji Aplikacja analiza jazd, podróży i systemu przesiadkowego musi dostarczać pełnej informacji w zakresie jazd, podróży i systemu przesiadkowego oraz zbiorcze zestawienie danych dla sieci transportowej danego obszaru (export danych do pliku Excela i zapis danych w formacie pliku pdf) z podziałem na poszczególne linie komunikacyjnej autobusowe, tramwajowe, kolejowe BiT City i dla wszystkich linii razem Aplikacja musi posiadać funkcję kalendarza i zegara umożliwiające określenie czasu analizy. Aplikacja będzie analizowała dane pozyskane w ramach systemu check in check out. W przypadku wyłączenia niniejszej funkcjonalności systemu aplikacja nie będzie aktywna Aplikacja będzie dokonywała analiz w dwóch blokach: a) analiza jazd, b) analiza podróży, c) analiza przesiadek Funkcjonalność analiza jazd będzie umożliwiał przeprowadzenie obliczeń dla wybranej/wybranych linii komunikacyjnych w uprzednio wybranym obszarze (miasto, gmina, cały system transportowy) lub strefie. System będzie dokonywał obliczeń dotyczących przejazdów oraz ich prezentacji w formie raportu oraz wykresów Funkcjonalność musi umożliwiać export danych do pliku w formacie pdf oraz do programu Excel. Obliczenia będą obejmowały: a) liczba jazd (w odniesieniu do wybranego okresu godzina, doba), b) średnia długość jazdy (w odniesieniu do wybranego okresu godzina, doba) w zależności od przyjętych jednostek długości [km/jazdę], czasu [min/jazdę], sieć [przystanków komunikacyjnych/jazdę] Funkcjonalność analiza podróży będzie umożliwiała przeprowadzenie obliczeń dla wybranego obszaru (miasto, gmina, cały system transportowy) lub strefy System będzie dokonywał obliczeń po uprzednim wprowadzeniu parametrów wyjściowych (określonych przez operatora). Zakres parametrów koniecznych do wprowadzenia pokazano na rysunku - Rysunek

129 Parametry wstępne (obliczeniowe) 1 A określ maksymalny czas na przesiadkę przystanek komunikacyjny środek transportu czas przesiadki [min] autobus/tramwaj autobus/tramwaj autobus/tramwaj kolej kolej autobus/tramwaj kolej kolej B węzeł komunikacyjny środek transportu czas przesiadki [min] autobus autobus autobus tramwaj tramwaj autobus tramwaj tramwaj kolej autobus autobus kolej kolej tramwaj tramwaj kolej kolej kolej 2 A B C D E 3 określ typ podróży podróże wyłącznie w granicach obszaru/strefy podróże rozpoczęte poza obszarem i zakończone w obszarze/strefie podróże rozpoczęte w obszarze i zakończone poza obszarem/strefą podróże tranzytowe przez obszar/strefę wszystkie podróże związane z obszarem/strefą okres analizy data rozpoczęcia analizy data zakończenia analizy godzina rozpoczęcia analizy 00:00 godzina zakończenia analizy 00:00 Rysunek 45 Określenie parametrów wstępnych dla analizy podróży i systemu przesiadkowego Parametry wstępne obejmują trzy bloki główne: a) określenie maksymalnego czasu na przesiadkę w zależności od miejsca przesiadki oraz środka transportu, b) określenie typu podróży w zależności od miejsca rozpoczęcia i zakończenia podróży, c) określenia okresu analizy Funkcjonalność analiza podróży musi dokonywać obliczeń następujących wielkości: a) liczba podróży [podróży/h], [podróży/dobę], b) liczba jazd [jazd/h], [jazd/dobę], c) liczba przesiadek [przesiadek/h], [przesiadek/dobę], d) wskaźnik określający liczbę jazd na podróż [jazd/podróż], e) wskaźnik określający liczbę przesiadek na podróż [przesiadek/podróż], f) średni czas na przesiadkę [min/przesiadkę], g) średnia długość podróży [km/podróż], [min/podróż], [przystanków/podróż], h) średnia długość jazdy [km/jazdę], [min/jazdę], [przystanków/jazdę], i) pasażerogodziny i pasażerokilometry w dobie Funkcjonalność analiza systemu przesiadkowego musi umożliwiać określenie różnych parametrów dotyczących czasu przesiadek pomiędzy różnymi środkami transportu w podziale na lokalizację: a) przystanek komunikacyjny, b) węzeł komunikacyjny Aplikacja musi umożliwiać określenie następujących wielkości: a) liczba przesiadek w analizowanym okresie czasu (miesiąc), b) średnia liczba przesiadek na dobę [przesiadek/dobę], c) odchylenie standardowe z średniej liczby przesiadek [przesiadek/dobę], d) kwantyl 95% z liczby przesiadek w dobie, 129

130 e) średni czas przesiadki [min], f) maksymalny czas przesiadki [min], g) minimalny czas przesiadki [min], h) odchylenie standardowe z czasów przesiadki [min], i) kwantyl 95% czasu przesiadki [min] Aplikacja musi umożliwiać wstępne zdefiniowanie, do procedury obliczeniowej, maksymalnego czasu na przesiadkę w miejscu przystanku komunikacyjnego i węzła komunikacyjnego Aplikacja musi umożliwiać export danych (raportów) do formatu Excela oraz zapis danych do pliku w formacie pdf Aplikacja musi umożliwiać tworzenie wykresów na podstawie przeprowadzonych analiz i ich zapis w formacie plików pdf Przykładowe rozwiązanie funkcjonalne aplikacji przedstawiono na rysunkach - Rysunek 46, Rysunek

131 Średnia długość jazdy [przystanków/jazdę] wzór prezentowania danych Średnia długość jazdy [km/jazdę] Liczba podróży [podróży/h] jazdy [liczba jazd/dobę] Analiza jazd, podróży i systemu przesiadkowego cz. 1 Dane o jazdach, podróżach i przesiadkach muszą być również dostępne z aplikacji Mapa dla modułu przemieszczeń pasażerów miasto/gmina/strefa Bydgoszcz Toruń Gmina Solec Kujawski Gmina Koronowo.. Strefa 1 Strefa 2.. Cały system transportowy Parametry wstępne (obliczeniowe) Typ analizy Analiza jazd Analiza podróży Analiza przesiadek wg opisu w cz. 2 1 A określ maksymalny czas na przesiadkę przystanek komunikacyjny środek transportu czas przesiadki [min] autobus/tramwaj autobus/tramwaj autobus/tramwaj kolej kolej autobus/tramwaj kolej kolej B węzeł komunikacyjny środek transportu czas przesiadki [min] autobus autobus autobus tramwaj tramwaj autobus tramwaj tramwaj kolej autobus autobus kolej kolej tramwaj tramwaj kolej kolej kolej 2 określ typ podróży A podróże wyłącznie w granicach obszaru/strefy B podróże rozpoczęte poza obszarem i zakończone w obszarze/strefie C podróże rozpoczęte w obszarze i zakończone poza obszarem/strefą D podróże tranzytowe przez obszar/strefę E wszystkie podróże związane z obszarem/strefą 3 okres analizy data rozpoczęcia analizy data zakończenia analizy godzina rozpoczęcia analizy 00:00 godzina zakończenia analizy 00:00 Wybór linii transportu publicznego pełna analiza wszystkich linii pełna analiza linii kolejowych pełna analiza linii tramwajowych pełna analiza linii autobusowych linia tramwajowa nr 1 linia tramwajowa nr 2. linia autobusowa nr 51 linia autobusowa nr 52.. Raport RAPORT DATA ANALIZY BYDGOSZCZ linia tramwajowa nr 2 kier. przeciwny Jazd [liczba jazd/h] analiza godzinowa 13:00 kolejna godzina średnia długość jazd w godzinie [km/jazdę] dowolny wybór okresu czasu z 13:00 14:00 15:00 16:00 17:00 średnia dokładnością do 1 [min] Prezentacja danych Wykres Export danych do pliku pdf Export danych do Excela Powrót do parametrów wstępnych 2,2 Typ transferu danych Export danych do Excela Export danych do pliku pdf kierunek centrum przeciwny dwa kierunki 2,5 1,9 Seria wykresów według wybranych parametrów Export danych według wybranych parametrów 2,3 Rodzaj analizy Analiza dobowa Analiza godzinowa 1,3 Rodzaj analizy Analiza dobowa Analiza godzinowa 2,0 tworzenie wykresów jak dla doby Wybór dnia i godzin analizy : :00 Wybór dnia i godzin analizy :00 18:00 22:00 16:00 RAPORT str BYDGOSZCZ linia tramwajowa nr 2 Jazdy [liczba jazd/dobę] średnia długość jazd w dobie [km/jazdę] średnia długość jazd w dobie [min/jazdę] średnia długość jazd w dobie [przystanków/jazdę] DATA ANALIZY RAPORT str DATA ANALIZY BYDGOSZCZ kier. przeciwny linia tramwajowa nr 2 kier. przeciwny ,5 1,4 1,3 2 1,7 1,9 2,1 1,3 1,5 1,8 2,3 2,1 0, średnia ,5 1,4 1,3 2 1,7 1,9 2,1 1,3 1,5 1, Raport Wykres Export danych do pliku pdf Export danych do Excela Raport Wykres Export danych do pliku pdf Export danych do Excela Liczba podróży w Bydgoszczy (wszystkie podróże związane z obszarem) od do wartość średnia 0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 kolejna godzina zapis do pliku pdf analiza dobowa 2 kolejna doba 55 1,7 26,0 7, ,5 2 1,5 Liczba jazd pasażerogodziny pasażerokilometry 32,1 28,4 24,0 16,5 12,5 17,3 36,3 67,5 47,6 58,5 110,0 16,5 13,2 32,3 32,5 67,5 50,4 74,1 118,0 Średnia długość jazdy [km/jazdę] 93,5 85,5 138,6 85,8 27,6 18,4 25,7 24,2 78,2 91,2 140,7 85,8 analiza dobowa 37,4 26,6 114,0 81,0 20,9 20,3 99,0 2 kolejna doba 19,5 20,3 16,9 12,3 104,4 Liczba jazd dla linii tramwajowej nr 1, kier. przeciwny, data: zapis do pliku pdf 103,5 92,4 średnia kolejna doba 23,1 89,0 Liczba jazd [jazd/dobę] Średnia długość jazdy dla linii tramwajowej nr 1, kier. przeciwny, data: ,3 Średnia długość jazdy [km/jazdę] RAPORT str DATA ANALIZY RAPORT str DATA ANALIZY Typ analizy wszystkie podróże związane z obszarem/strefą BYDGOSZCZ BYDGOSZCZ Typ analizy wszystkie podróże związane z obszarem/strefą PODRÓŻE [podróży/h, podróży/dobę] pdf Excel Wykres ŚREDNIA DŁUGOŚĆ PODRÓŻY [km/podróż] pdf Excel Wykres data godzina doba data godzina doba 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23: średnia data średnia data średnia data średnia średnia średnia średnia JAZDY [jazd/h, jazd/dobę] pdf Excel Wykres ŚREDNIA DŁUGOŚĆ JAZDY [km/jazdę] pdf Excel Wykres godzina godzina doba data doba 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 PRZESIADKI [przesiadek/h, przesiadek/dobę] pdf Excel Wykres ŚREDNIA DŁUGOŚĆ PODRÓŻY [liczba przystanków/podróż] pdf Excel Wykres godzina doba data godzina doba 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23: WSKAŹNIK pdf Excel Wykres ŚREDNIA DŁUGOŚĆ JAZDY [liczba przystanków/jazdę] pdf Excel Wykres godzina doba data godzina doba 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 JAZD/PODRÓŻ pdf Excel Wykres PRZESIADEK/PODRÓŻ ŚREDNI CZAS PRZESIADKI [min/przesiadkę] pdf Excel Wykres pdf Excel Wykres średnia średnia średnia data średnia data średnia ŚREDNIA DŁUGOŚĆ PODRÓŻY [min/podróż] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 ŚREDNIA DŁUGOŚĆ JAZDY [min/jazdę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 pdf pdf Excel Excel Wykres Wykres doba doba 1 0, Średnia długość jazdy [przystanków/jazdę] zapis do pliku pdf kolejna doba zapis do pliku pdf Średnia długość jazdy dla linii tramwajowej nr 1, kier. przeciwny, data: kolejna doba Średnia długość jazdy [przystanków/jazdę] Rysunek 46 Aplikacja Analiza jazd, podróży i systemu przesiadkowego (część 1) przykładowe rozwiązanie. 131

132 Analiza jazd, podróży i systemu przesiadkowego cz.2 miasto/gmina/strefa Typ analizy Parametry wstępne (obliczeniowe) 1 zakres analizy Bydgoszcz A przystanek komunikacyjny TAK NIE Analiza jazd środek transportu Toruń autobus/tramwaj autobus/tramwaj TAK NIE wg opisu w cz. 1 autobus/tramwaj kolej TAK NIE Gmina Solec Kujawski kolej autobus/tramwaj TAK NIE kolej kolej TAK NIE Analiza podróży Gmina Koronowo B węzeł komunikacyjny TAK NIE środek transportu.. wg opisu w cz. 1 autobus autobus TAK NIE autobus tramwaj TAK NIE Strefa 1 tramwaj autobus TAK NIE Analiza przesiadek tramwaj tramwaj TAK NIE Strefa 2 kolej autobus TAK NIE autobus kolej TAK NIE.. kolej tramwaj TAK NIE tramwaj kolej TAK NIE Cały system kolej kolej TAK NIE transportowy 2 określ typ podróży A podróże wyłącznie w granicach obszaru/strefy B podróże rozpoczęte poza obszarem i zakończone w obszarze/strefie C podróże rozpoczęte w obszarze i zakończone poza obszarem/strefą D podróże tranzytowe przez obszar/strefę E wszystkie podróże związane z obszarem/strefą 3 okres analizy data rozpoczęcia analizy data zakończenia analizy godzina rozpoczęcia analizy 00:00 godzina zakończenia analizy 00:00 4 wstępne określenie maksymalnego czasu przesiadki [min] przystanek komunikacyjny 15 węzeł komunikacyjny 45 zakres analizy A środek transportu autobus/tramwaj autobus/tramwaj autobus/tramwaj kolej kolej autobus/tramwaj kolej kolej B środek transportu autobus autobus autobus tramwaj tramwaj autobus tramwaj tramwaj kolej autobus autobus kolej kolej tramwaj tramwaj kolej kolej kolej całkowita liczba przesiadek Przesiadki [liczba] średnia liczba przesiadek w dobie odchylenie standardowe kwantyl 95% przystanek komunikacyjny węzeł komunikacyjny średnia podróże wyłącznie w granicach obszaru/strefy wartość minimalna : Czas przesiadki [min] wartość maksymalna odchylenie standardowe Export danych do pliku pdf Powrót do parametrów wstępnych Export danych do Excela Należy wprowadzić maksymalny czas na przesiadkę z dokładnością do 1 minuty Wyniki obliczeń kwantyl 95% Rysunek 47 Aplikacja Analiza jazd, podróży i systemu przesiadkowego (część 2) przykładowe rozwiązanie. 132

133 24.7. Aplikacja ANALIZA PARAMETRÓW SIECIOWYCH W PRZEWOZACH PASAŻERSKICH funkcjonalność aplikacji Aplikacja analiza parametrów sieciowych w przewozach pasażerskich musi dostarczać następujących danych powiązanych z wybranym obszarem: a) liczba podróży [podróży/h, podróży/dobę, podróży/rok], b) liczba przesiadek [przesiadek/h, przesiadek/dobę, przesiadek/rok], c) liczba osób [osób/h, osób/dobę, osób/rok], d) liczba pasażerów [pasażerów/h, pasażerów/dobę, pasażerów/rok], e) pasażerogodziny/dobę, pasażerogodziny/rok, f) pasażerokilometry/dobę, pasażerokilometry/rok Powyższe wielkości będą obliczane podczas analizy dotyczącej wszystkich linii w wybranym obszarze. W przypadku analiz dotyczących wybranej linii komunikacyjnej możliwa będzie analiza uproszczona obejmująca następujące wielkości: a) liczba pasażerów [pasażerów/h, pasażerów/dobę, liczba pasażerów/rok], b) pasażerogodziny/dobę, pasażerogodziny/rok, c) pasażerokilometry/dobę, pasażerokilometry/rok Przystępując do kompleksowej analizy transportowej konieczne będzie określenie warunków wstępnych/brzegowych. Warunki te będą obejmowały następujące dane: a) zakres analizy dotyczy wybrania do analizy miejsc przesiadek (przystanek komunikacyjny, węzeł komunikacyjny) oraz rodzaju środków transportu, b) określenie typu podróży dotyczy miejsca rozpoczęcia i zakończenia podróży, c) wybrania okresu analizy, d) wstępnego przyjęcia maksymalnego czasu na przesiadkę (przystanek i węzeł komunikacyjny), e) określenia rodzaju analizy (raport, wykres, raport i wykres) Przygotowane powyżej dane muszą umożliwić uruchomienie procedury obliczeniowej, która określi szczegółowe wartości dla przesiadek między różnymi środkami transportu w zależności od lokalizacji przesiadki. W przypadku braku akceptacji obliczonych wyników musi istnieć możliwość skorygowania danych dotyczących wstępnego przyjęcia maksymalnego czasu na przesiadkę. W przypadku akceptacji tych wartości nastąpi przejście do szczegółowej prezentacji wyników obliczeń które zostaną przedstawione w formie raportu lub/i wykresów Musi istnieć możliwość zapisania otrzymanych wyników w formacie pliku pdf oraz musi istnieć możliwość zapisu danych do plików w formacie obsługiwanym przez program Excel Musi istnieć możliwość odczytania zapisanych wcześniej plików i wprowadzenia korekt lub wykorzystania w innych analizach np. w aplikacji określającej tendencje zmian na sieci transportu publicznego Przystępując do uproszczonej analizy transportowej dotyczącej wybranej linii komunikacyjnej konieczne będzie określenie warunków wstępnych/brzegowych. Warunki te będą obejmowały następujące dane: a) określenie typu podróży dotyczy miejsca rozpoczęcia i zakończenia podróży, b) wybrania okresu analizy, 133

134 c) określenia rodzaju analizy (raport, wykres, raport i wykres) Przygotowane powyżej dane muszą umożliwić uruchomienie procedury obliczeniowej, która przedstawi szczegółowe wyniki obliczeń w formie raportu lub/i wykresów Musi istnieć możliwość zapisania otrzymanych wyników w formacie pliku pdf oraz musi istnieć możliwość zapisu danych do plików w formacie obsługiwanym przez program Excel Musi istnieć możliwość odczytania zapisanych wcześniej plików i wprowadzenia korekt lub wykorzystania w innych analizach np. w aplikacji określającej tendencje zmian na sieci transportu publicznego Przykładowe rozwiązanie funkcjonalne aplikacji przedstawiono na rysunkach - Rysunek 48, Rysunek

135 Analiza parametrów sieciowych cz.1 Miasto/gmina/strefa Typ analizy Wybór linii transportu publicznego Parametry wstępne (obliczeniowe) Wyniki obliczeń Bydgoszcz Toruń Gmina Solec Kujawski Gmina Koronowo.. Strefa 1 Strefa 2.. Cały system transportowy Liczba podróży Liczba przesiadek Liczba osób Liczba pasażerów (jazd) Pasażerogodziny Pasażerokilometry UWAGA: Możliwość wybrania jednocześnie wielu opcji, dla opcji: liczba podróży, liczba przesiadek, liczba osób dostępna tylko pełna analiza pełna analiza wszystkich linii pełna analiza linii kolejowych pełna analiza linii tramwajowych pełna analiza linii autobusowych linia tramwajowa nr 1 linia tramwajowa nr 2. linia autobusowa nr 20 linia autobusowa nr A zakres analizy przystanek komunikacyjny TAK NIE środek transportu autobus/tramwaj autobus/tramwaj TAK NIE autobus/tramwaj kolej TAK NIE kolej autobus/tramwaj TAK NIE kolej kolej TAK NIE B węzeł komunikacyjny TAK NIE środek transportu autobus autobus TAK NIE autobus tramwaj TAK NIE tramwaj autobus TAK NIE tramwaj tramwaj TAK NIE kolej autobus TAK NIE autobus kolej TAK NIE kolej tramwaj TAK NIE tramwaj kolej TAK NIE kolej kolej TAK NIE 2 określ typ podróży A podróże wyłącznie w granicach obszaru/strefy B podróże rozpoczęte poza obszarem i zakończone w obszarze/strefie C podróże rozpoczęte w obszarze i zakończone poza obszarem/strefą D podróże tranzytowe przez obszar/strefę E wszystkie podróże związane z obszarem/strefą 3 okres analizy data rozpoczęcia analizy data zakończenia analizy godzina rozpoczęcia analizy 00:00 godzina zakończenia analizy 00:00 4 wstępne określenie maksymalnego czasu przesiadki [min] przystanek komunikacyjny 15 zakres analizy Przesiadki liczba przesiadek A przystanek komunikacyjny środek transportu autobus/tramwaj autobus/tramwaj autobus/tramwaj kolej kolej autobus/tramwaj kolej kolej B węzeł komunikacyjny środek transportu autobus autobus autobus tramwaj tramwaj autobus tramwaj tramwaj kolej autobus autobus kolej kolej tramwaj tramwaj kolej kolej kolej Export danych do pliku Powrót do parametrów wstępnych pdf Czas przesiadki [min] średnia podróże wyłącznie w granicach obszaru/strefy Należy wprowadzić maksymalny czas na przesiadkę z dokładnością do 1 minuty kwantyl 95% Export danych do Excel patrz. cz.2 Parametry wstępne (obliczeniowe) węzeł komunikacyjny 45 Podróże [podróży/dobę] Export danych do pliku pdf 1 określ typ podróży 5 A B C D E 2 podróże wyłącznie w granicach obszaru/strefy podróże rozpoczęte poza obszarem i zakończone w obszarze/strefie podróże rozpoczęte w obszarze i zakończone poza obszarem/strefą podróże tranzytowe przez obszar/strefę wszystkie podróże związane z obszarem/strefą okres analizy data rozpoczęcia analizy data zakończenia analizy godzina rozpoczęcia analizy 00:00 godzina zakończenia analizy 00:00 rodzaj analizy raport wykresy [rozkład godzinowy] wykresy [rozkład dobowy] wykresy [rozkład godzinowy] raport i wykresy [rozkład godzinowy] rodzaj analizy raport wykresy [rozkład dobowy] raport i wykresy [rozkład dobowy] RAPORT str DATA ANALIZY Typ analizy wszystkie podróże związane z obszarem/strefą TORUŃ, linia autobusowa nr LICZBA PASAŻERÓW/JAZD [pasażerów/h, pasażerów/dobę] godzina data doba 3 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23: raport i wykresy [rozkład godzinowy] LICZBA PODRÓŻY, TORUŃ ( : ) linia autobusowa nr kolejna doba raport i wykresy [rozkład dobowy] data data data data Export danych do pliku pdf ŚREDNIA DŁUGOŚĆ JAZDY [km/jazdę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 ŚREDNIA DŁUGOŚĆ JAZDY [min/jazdę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 PASAŻEROGODZINY [h, dobę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 PASAŻEROKILOMETRY [h, dobę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 Export danych do Excel doba doba doba doba Rysunek 48 Aplikacja Analiza parametrów sieciowych (część 1) przykładowe rozwiązanie. 135

136 0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 Analiza parametrów sieciowych cz.2 patrz. cz. 1 RAPORT str DATA ANALIZY TORUŃ Typ analizy wszystkie podróże związane z obszarem/strefą PODRÓŻE [podróży/h, podróży/dobę] data godzina doba 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23: data data data data data data data data data Export danych do pliku pdf ŚREDNIA DŁUGOŚĆ PODRÓŻY [km/podróż] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 ŚREDNIA DŁUGOŚĆ PODRÓŻY [min/podróż] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 LICZBA PRZESIADEK [przesiadek/h, przesiadek/dobę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 LICZBA OSÓB [osób/h, osób/dobę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 LICZBA PASAŻERÓW/JAZD [pasażerów/h, pasażerów/dobę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 ŚREDNIA DŁUGOŚĆ JAZDY [km/jazdę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 ŚREDNIA DŁUGOŚĆ JAZDY [min/jazdę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 PASAŻEROGODZINY [h, dobę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 PASAŻEROKILOMETRY [h, dobę] godzina 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 Export danych do Excel doba doba doba doba doba doba doba doba doba LICZBA PODRÓŻY, TORUŃ ( : ) Podróże [podróży/h] kolejna godzina doby Export danych do pliku pdf Rysunek 49 Aplikacja Analiza parametrów sieciowych (część 2) przykładowe rozwiązanie. 136

137 24.8. Aplikacja ANALIZA UDZIAŁU GRUP SPOŁECZNYCH W PRZEWOZACH PASAŻERSKICH funkcjonalność aplikacji Aplikacja analiza udziału grup społecznych w przewozach pasażerskich musi dostarczać następujących danych w zakresie udziału poszczególnych grup społecznych dla następujących wielkości: a) liczba podróży [podróży/dobę, podróży/rok], b) liczba przesiadek [przesiadek/dobę, przesiadek/rok], c) liczba osób [osób/dobę, osób/rok], d) liczba pasażerów [pasażerów/dobę, pasażerów/rok], e) pasażerogodziny/dobę, pasażerogodziny/rok f) pasażerokilometry/dobę, pasażerokilometry/rok Powyższe wielkości będą obliczane podczas analizy dotyczącej wszystkich linii w wybranym obszarze. Niniejsze będzie następowało w oparciu o procedurę zawartą w aplikacji dotyczącej analiz parametrów sieciowych w przewozach pasażerskich lub na podstawie wykonanej wcześniej analizy i zapisanej w postaci pliku umożliwiającego dalszą analizę wynikająca z przedmiotowego rozdziału W przypadku analiz dotyczących wybranej linii komunikacyjnej możliwa będzie analiza uproszczona obejmująca następujące wielkości: a) liczba pasażerów [pasażerów/dobę, pasażerów/rok], b) pasażerogodziny/dobę, pasażerogodziny/rok c) średnia długość jazdy [km/jazdę, min/jazdę], d) pasażerokilometry/dobę, pasażerokilometrów/rok Powyższe wielkości będą obliczane podczas analizy dotyczącej wybranej linii w wybranym obszarze. Niniejsze będzie następowało w oparciu o procedurę zawartą w aplikacji dotyczącej analiz parametrów sieciowych w przewozach pasażerskich lub na podstawie wykonanej wcześniej analizy i zapisanej w postaci pliku umożliwiającego dalszą analizę wynikająca z przedmiotowego rozdziału Musi istnieć możliwość zapisania otrzymanych wyników w formacie pliku pdf oraz musi istnieć możliwość zapisu danych do plików w formacie obsługiwanym przez program Excel Musi istnieć możliwość odczytania zapisanych wcześniej plików i wprowadzenia korekt lub wykorzystania w innych analizach np. w aplikacji określającej tendencje zmian na sieci transportu publicznego Musi istnieć możliwość prezentacji wyników w postaci wykresów Przykładowe rozwiązanie funkcjonalne aplikacji przedstawiono na rysunku - Rysunek

138 Analiza udział grup społecznych w przewozach pasażerskich Miasto/gmina/strefa Bydgoszcz Toruń Gmina Solec Kujawski Gmina Koronowo Wybór linii transportu publicznego pełna analiza wszystkich linii pełna analiza linii kolejowych pełna analiza linii tramwajowych Wybór sposobu przeprowadzenia analizy pobierz analizę wykonaną wcześniej na etapie analizy sieciowej nowa analiza wg procedury rys. 7 i 8 RAPORT str DATA ANALIZY BYDGOSZCZ Typ analizy wszystkie podróże związane z obszarem/strefą 1 3 UDZIAŁ GRUP SPOŁECZNYCH W PRZEWOZACH PASAŻERSKICH PODRÓŻE [podróży/dobę] data OGÓŁEM USP USG USS ST P E ŚREDNIA DŁUGOŚĆ PODRÓŻY [km/podróż] data OGÓŁEM USP USG USS ST P E.. Strefa 1 Strefa 2 pełna analiza linii autobusowych linia tramwajowa nr ŚREDNIA DŁUGOŚĆ PODRÓŻY [min/podróż] data OGÓŁEM USP USG USS ST P E.. Cały system transportowy linia tramwajowa nr LICZBA PRZESIADEK [przesiadek/dobę]. data OGÓŁEM USP USG USS ST P E linia autobusowa nr 20 pobierz analizę wykonaną wcześniej na etapie analizy sieciowej LICZBA OSÓB [osób/dobę] linia autobusowa nr 21.. nowa analiza wg procedury rys. 7 i 8 data OGÓŁEM USP USG USS ST P LICZBA PASAŻERÓW/JAZD [pasażerów/dobę] E data OGÓŁEM USP USG USS ST P E RAPORT str DATA ANALIZY wszystkie podróże związane z Typ analizy BYDGOSZCZ, linia autobusowa nr obszarem/strefą LICZBA PASAŻERÓW/JAZD [pasażerów/dobę] data OGÓŁEM USP USG USS ST P E data OGÓŁEM USP USG ŚREDNIA DŁUGOŚĆ JAZDY [km/jazdę] USS ST P E ŚREDNIA DŁUGOŚĆ JAZDY [km/jazdę] ŚREDNIA DŁUGOŚĆ JAZDY [min/jazdę] data OGÓŁEM USP USG USS ST P E data OGÓŁEM USP USG USS ST P E ŚREDNIA DŁUGOŚĆ JAZDY [min/jazdę] PASAŻEROGODZINY [dobę] data OGÓŁEM USP USG USS ST P E data OGÓŁEM USP USG USS ST P E PASAŻEROGODZINY [dobę] data OGÓŁEM USP USG USS ST P E data PASAŻEROKILOMETRY [dobę] OGÓŁEM USP USG USS ST P E PASAŻEROKILOMETRY [dobę] data OGÓŁEM USP USG USS ST P E Export danych do pliku pdf Export danych do Excel Przedstaw dane na wykresach Export danych do pliku pdf Export danych do Excel Przedstaw dane na wykresach Rysunek 50 Aplikacja Analiza udziału grup społecznych w przewozach pasażerskich przykładowe rozwiązanie. 138

139 24.9. Aplikacja ANALIZA NAPEŁNIENIA I KOMFORTU PODRÓŻY funkcjonalność aplikacji Aplikacja analiza napełnienia i komfortu podróży będzie dokonywała analizy poszczególnych linii komunikacyjnych transportu publicznego w wybranym wcześniej obszarze/strefie. Stworzone zostaną trzy typy analiz: napełnienie, komfort podróży, statystyka komfort podróży. W ramach niniejszych typów analiz aplikacja musi dokonywać obliczeń następujących parametrów: a) napełnienie pojazdów q, b) wskaźnik komfortu k, c) poziom komfortu Napełnienie pojazdów (wozów) będzie wyznaczane dla wybranej linii komunikacyjnej transportu publicznego w odniesieniu do każdego kursu i wszystkich punktów międzyprzystankowych Napełnienie będzie wyznaczane na podstawie liczby pasażerów oraz zdolności przewozowej (pojemność nominalna) Wartości pojemności nominalnej pojazdów muszą być automatycznie pobierane z bazy danych o infrastrukturze technicznej (przypisanie komputera pokładowego do danego pojazdu) Wskaźnik komfortu k będzie obliczany na podstawie napełnienia pojazdów q wg następującego wzoru: k = 0,56 + 1,6q 2, Poziom komfortu będzie wyznaczany w zależności od wartości wskaźnika komfortu. Zakres wskaźnika komfortu dla poszczególnych klas poziomu komfortu pokazano w tabeli - Tabela 3 Poziomy komfortu.. Tabela 3 Poziomy komfortu. Poziom komfortu A B C D E F Wskaźnik komfortu 0,6 k 0,7 k<0,8 0,8 k<1,0 1,0 k<1,4 1,4 k<2,2 2,2 k<4, Aplikacja musi umożliwiać tworzenie raportów oraz wykresów wraz z zapisem wytworzonych danych do plików w formacie pdf i formacie programu Excel Aplikacja musi umożliwiać porównywanie danych w utworzonych wcześnie plikach Przykładowe rozwiązanie funkcjonalne aplikacji przedstawiono na rysunkach - Rysunek 51, Rysunek

140 aaa bbb ccc ddd eee fff ggg hhh iiii jjjj kkkk lllll mmm nnn ooo ppp rrrr ssss wskaźnik komfortu procent kursów procent kursów Analiza napełnienia i komfortu podróży w pojazdach cz.1 Miasto/gmina/strefa Wybór linii transportu publicznego Typ analizy OKREŚLENIE TERMINU ANALIZY Bydgoszcz Toruń Gmina Solec Kujawski Gmina Koronowo.. Strefa 1 Strefa 2.. Cały system transportowy Analiza jednego pliku Poziom komfortu A B C D E F Analiza kilku plików B C D E F suma RAPORT NR Linia tramwajowa nr 1 Linia tramwajowa nr 1 linia kolejowa BiT City linia tramwajowa nr 1 linia tramwajowa nr 2. linia autobusowa nr 20 linia autobusowa nr 21.. RAPORT NR Liczba kursów Procent kursów , , , , , , WTOREK 19 13,2 14 9,7 10 6,9 4 2,8 0 0,0 suma ,0 Zapis danych w pliku pdf Poziom komfortu A Liczba kursów Procent kursów 97 67,4 Export danych do Excela 37,5 23,6 19,4 11,8 4,9 Analiza jednego pliku Analiza kilku plików Napełnienie Komfort podróży Statystyka - komfort podróży Zapis wykresu w pliku pdf Zapis danych w pliku pdf Export danych do Excela Zapis wykresu w pliku pdf 2, ,0 100,0 80,0 70,0 60,0 50,0 40,0 30,0 20,0 10,0 0,0 80,0 70,0 60,0 50,0 40,0 30,0 20,0 10,0 0,0 67,4 67,4 37, Wybierz dobę do analizy Otwórz plik z analizą komfortu podróży Lista dostępnych plików kom_bydg_t1_001 kom_bydg_t1_002 kom_bydg_t1_003 Możliwość wyboru kilku plików Poziom komfortu, Bydgoszcz, linia tramwajowa nr WTOREK 13,2 9,7 A B C D E F 6,9 poziomy komfortu Poziom komfortu, Bydgoszcz, linia tramwajowa nr 1 23,6 13,2 19,4 9,7 11,8 6,9 4,9 2,8 A B C D E F poziomy komfortu Wybierz dobę do analizy Wybierz dobę do analizy Otwórz plik z analizą napełnienia 2, Lista dostępnych plików nap_bydg_t1_001 nap_bydg_t1_002 nap_bydg_t1_003 Możliwość wyboru kilku plików 2,8 0,0 0,0 RAPORT NR cz. 1 NAPEŁNIENIE WOZU WTOREK patrz cz. 2 Nazwa przystanku Kolejny kurs 04:30 04:45 05:00 05: :30 22:45 23:00 23:15 aaa 0,12 0,13 0,13 0,14 0,09 0,09 0,07 0,01 bbb 0,15 0,16 0,16 0,17 0,12 0,12 0,1 0,02 ccc 0,24 0,26 0,27 0,29 0,19 0,19 0,15 0,03 ddd 0,23 0,25 0,26 0,28 0,18 0,18 0,14 0,03 eee 0,34 0,37 0,38 0,41 0,27 0,26 0,21 0,04 fff 0,37 0,4 0,41 0,45 0,29 0,28 0,22 0,04 ggg 0,67 0,72 0,74 0,81 0,52 0,51 0,41 0,08 hhh 0,65 0,7 0,72 0,78 0,51 0,5 0,4 0,08 iiii 0,78 0,84 0,87 0,95 0,61 0,6 0,48 0,1 jjjj 0,54 0,58 0,6 0,65 0,42 0,41 0,33 0,07 kkkk 0,52 0,56 0,58 0,63 0,41 0,4 0,32 0,06 lllll 0,34 0,37 0,38 0,41 0,27 0,26 0,21 0,04 mmm 0,24 0,26 0,27 0,29 0,19 0,19 0,15 0,03 nnn 0,19 0,21 0,22 0,24 0,15 0,15 0,12 0,02 ooo 0,16 0,17 0,18 0,2 0,12 0,12 0,1 0,02 ppp 0,12 0,13 0,13 0,14 0,09 0,09 0,07 0,01 rrrr 0,1 0,11 0,11 0,12 0,08 0,08 0,06 0,01 ssss 0,02 0,02 0,02 0,02 0,02 0,02 0,02 0 RAPORT NR cz. 2 WSKAŹNIK KOMFORTU WTOREK Nazwa przystanku Kolejny kurs 04:30 04:45 05:00 05: :30 22:45 23:00 23:15 aaa 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 bbb 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 ccc 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 ddd 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 eee 0,7 0,7 0,7 0,7 0,6 0,6 0,6 0,6 fff 0,7 0,7 0,7 0,8 0,6 0,6 0,6 0,6 ggg 1,1 1,3 1,3 1,5 0,9 0,9 0,7 0,6 hhh 1,1 1,2 1,3 1,4 0,9 0,8 0,7 0,6 iiii 1,4 1,6 1, ,8 0,6 jjjj 0, ,1 0,7 0,7 0,7 0,6 kkkk 0,9 0,9 1 1,1 0,7 0,7 0,7 0,6 lllll 0,7 0,7 0,7 0,7 0,6 0,6 0,6 0,6 mmm 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 nnn 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 ooo 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 ppp 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 rrrr 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 ssss 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 Export danych do pliku pdf Export danych do pliku (format pliku systemu) Export danych do formatu plik Excel Utwórz wykres 1,8 1,6 1,4 1,2 1 0,8 0,6 0,4 0,2 0 Zapis wykresu w pliku pdf Wskaźniki komfortu, Bydgoszcz, linia tramwajowa nr 1, porównanie kursów 4:30, 5:00 nazwa kolejnego przystanku kurs 4:30 kurs 5:00 Rysunek 51 Aplikacja Analiza napełnienia i komfortu w pojazdach (część 1) przykładowe rozwiązanie. 140

141 Analiza napełnienia i komfortu podróży w pojazdach cz. 2 patrz cz. 1 RAPORT NR cz. 1 ANALIZA NAPEŁNIENIA - liczba pasażerów WTOREK Nazwa przystanku aaa bbb ccc ddd eee fff ggg hhh iiii jjjj kkkk Kolejny kurs 04:30 04:45 05:00 05: :30 22:45 23:00 23: lllll mmm nnn ooo ppp rrrr ssss RAPORT NR cz. 2 ANALIZA NAPEŁNIENIA - zdolność przewozowa (pojemność nominalna) WTOREK Nazwa przystanku Kolejny kurs 04:30 04:45 05:00 05: :30 22:45 23:00 23:15 aaa bbb ccc ddd eee fff ggg hhh iiii jjjj kkkk lllll mmm nnn ooo ppp rrrr ssss RAPORT NR cz. 3 NAPEŁNIENIE WOZU WTOREK Nazwa przystanku Kolejny kurs 04:30 04:45 05:00 05: :30 22:45 23:00 23:15 aaa 0,12 0,13 0,13 0,14 0,09 0,09 0,07 0,01 bbb 0,15 0,16 0,16 0,17 0,12 0,12 0,1 0,02 ccc 0,24 0,26 0,27 0,29 0,19 0,19 0,15 0,03 ddd 0,23 0,25 0,26 0,28 0,18 0,18 0,14 0,03 eee 0,34 0,37 0,38 0,41 0,27 0,26 0,21 0,04 fff 0,37 0,4 0,41 0,45 0,29 0,28 0,22 0,04 ggg 0,67 0,72 0,74 0,81 0,52 0,51 0,41 0,08 hhh 0,65 0,7 0,72 0,78 0,51 0,5 0,4 0,08 iiii 0,78 0,84 0,87 0,95 0,61 0,6 0,48 0,1 jjjj 0,54 0,58 0,6 0,65 0,42 0,41 0,33 0,07 kkkk 0,52 0,56 0,58 0,63 0,41 0,4 0,32 0,06 lllll 0,34 0,37 0,38 0,41 0,27 0,26 0,21 0,04 mmm 0,24 0,26 0,27 0,29 0,19 0,19 0,15 0,03 nnn 0,19 0,21 0,22 0,24 0,15 0,15 0,12 0,02 ooo 0,16 0,17 0,18 0,2 0,12 0,12 0,1 0,02 ppp 0,12 0,13 0,13 0,14 0,09 0,09 0,07 0,01 rrrr 0,1 0,11 0,11 0,12 0,08 0,08 0,06 0,01 ssss 0,02 0,02 0,02 0,02 0,02 0,02 0,02 0 Export danych do pliku pdf Export danych do pliku (format pliku systemu) Export danych do formatu plik Excel Rysunek 52 Aplikacja Analiza napełnienia i komfortu w pojazdach (część 2) przykładowe rozwiązanie Aplikacja ANALIZA PRZEMIESZCZEŃ PASAŻERÓW funkcjonalność aplikacji Aplikacja analiza przemieszczeń pasażerów musi dostarczać informacji o przemieszczeniach pasażerów pomiędzy określonymi przystankami i rejonami komunikacyjnymi, obszarami i strefami komunikacyjnymi Aplikacja będzie dokonywała analiz wyłącznie dla okresu jednej doby Aplikacja, przed rozpoczęciem analizy, musi umożliwiać zdefiniowanie granicznych maksymalnych wartości czasu na przesiadkę między różnymi środkami transportu. Szczegóły takiej analizy zawarto w aplikacji Analiza jazd, podróży i systemu przesiadkowego Aplikacja podczas prowadzonych obliczeń przemieszczeń pasażerów pomiędzy przystankami, rejonami, obszarami i strefami komunikacyjnymi musi uwzględniać pełen łańcuch podróży (przemieszczanie pasażerów między początkiem a końcem podróży), przy określonej granicznej wartości czasu na przesiadkę Aplikacja musi umożliwiać tworzenie rejonów komunikacyjnych, obszarów i stref komunikacyjnych za pośrednictwem aplikacji mapa. Wówczas to przystanki komunikacyjne znajdujące się w wyznaczonym na mapie terenie zostaną do niego przypisane automatycznie. 141

142 Aplikacja musi umożliwiać tworzenie rejonów komunikacyjnych, obszarów i stref komunikacyjnych poprzez ręczny wybór przystanków komunikacyjnych (grupa przystanków) i węzłów komunikacyjnych (grupa węzłów) z listy przystanków komunikacyjnych i listy węzłów komunikacyjnych Aplikacja musi umożliwiać tworzenie wielu rejonów komunikacyjnych, obszarów i stref komunikacyjnych, nadawanie im niepowtarzalnych nazw oraz pozwalać na ich archiwizację Aplikacja musi umożliwiać tworzenie (definiowanie) modeli przemieszczeń oraz pozwalać na ich archiwizację. Umożliwi to powtarzalną analizę wg określonych parametrów. Przed przystąpieniem do analizy musi istnieć możliwość wyboru odpowiedniego modelu przemieszczeń. Modele przemieszczeń muszą pozwalać na analizę przemieszczeń pasażerów pomiędzy dowolnymi przystankami, węzłami, rejonami, obszarami i strefami komunikacyjnymi. Rejony, obszary i strefy komunikacyjne muszą być możliwe do określenia przy pomocy mapy oraz poprzez bezpośredni wybór przystanków i węzłów komunikacyjnych. Wybór będzie dokonywany z utworzonej listy przystanków i węzłów komunikacyjnych. Przykładowe modele przemieszczeń: a) Model przystanki komunikacyjne analiza przemieszczeń pomiędzy wszystkimi przystankami, b) Model węzły komunikacyjne analiza przemieszczeń pomiędzy wszystkimi węzłami komunikacyjnymi, c) Model rejony komunikacyjne analiza przemieszczeń pomiędzy wszystkimi rejonami komunikacyjnymi, d) Model Śródmieście Bydgoszczy (Torunia) analiza przemieszczeń między śródmieściem miasta a pozostałą częścią miasta, e) Model BiT City analiza przemieszczeń między przystankami komunikacyjnymi linii kolejowej BiT City a pozostałymi rejonami komunikacyjnymi (ruch generowany i absorbowany przez przystanki kolejowe linii BiT City) Aplikacja musi umożliwiać tworzenie macierzy przemieszczeń pomiędzy wszystkimi przystankami w Bydgosko Toruńskim Obszarze Metropolitalnym. Wyniki będą prezentowane w postaci macierzy. Przykład macierzy pokazano na rysunku - Rysunek 53. RAPORT nr ANALIZA PRZEMIESZCZEŃ - liczba pasażerów/dobę przemieszczenia pomiędzy wszystkimi przystankami komunikacyjnymi koniec podróży początek podróży 001_B 002_B 345_T 001_B 002_B.. 345_T suma podróży w obu kierunkach między dwoma przystankami Rysunek 53 Macierz przemieszczeń przykładowe rozwiązanie Aplikacja musi umożliwiać tworzenie macierzy przemieszczeń pomiędzy wybranymi rejonami, obszarami i strefami komunikacyjnymi. Wyniki będą prezentowane w postaci macierzy oraz więźby ruchu. Macierz będzie utworzona jak w przypadku przemieszczeń między poszczególnymi przystankami. Więźba ruchu zostanie utworzona na mapie. Natężenie ruchu pasażerskiego między poszczególnymi rejonami, obszarami, strefami komunikacyjnymi będzie prezentowane odpowiednią grubością i kolorem linii. Grubość i kolor linii będą dostosowane do wielkości potoku ruchu. Linie wyznaczające potoki przemieszczeń między poszczególnymi rejonami, obszarami i strefami komunikacyjnymi będą opisane wartością potoku ruchu podróżnych. Przykład więźby ruchu pokazano na rysunku - Rysunek

143 Rysunek 54 Więźba ruchu przykładowe rozwiązanie Aplikacja musi umożliwiać tworzenie macierzy przemieszczeń wg określonego modelu przemieszczeń. Wyniki będą prezentowane w postaci macierzy oraz więźby ruchu. Macierz i więźba ruchu będą utworzone jak w przypadku przemieszczeń pomiędzy rejonami, obszarami i strefami komunikacyjnymi Aplikacja musi umożliwiać zapis utworzonych macierzy i więźby ruchu do plików. Przewidywany jest export danych do plików w formacie xls oraz pdf (macierz), oraz w formacie pdf (więźba ruchu) Aplikacja TENDENCJE ZMIAN PARAMETRÓW SIECIOWYCH W PRZEWOZACH PASAŻERSKICH funkcjonalność aplikacji Aplikacja tendencje zmian parametrów sieciowych w przewozach pasażerskich musi umożliwiać porównanie wybranych wartości parametrów sieciowych w poszczególnych latach. Analizy będą dotyczyły porównania wartości średnio-dobowych i rocznych Aplikacja musi poddawać analizie następujące parametry sieciowe: a) średnia liczba podróży [podróży/dobę], b) liczba podróży na rok, c) średnia liczba przesiadek [przesiadek/dobę], d) liczba przesiadek na rok, e) średnia liczba osób [osób/dobę], f) liczba osób na rok, g) średnia liczba pasażerów [pasażerów/dobę], h) liczba pasażerów na rok, i) średnia liczba pasażerogodziny/dobę, j) liczba pasażerogodziny/rok, k) średnia liczba pasażerokilometrów/dobę, l) liczba pasażerokilometrów/rok W przypadku analiz dotyczących wybranej linii komunikacyjnej możliwa będzie analiza z wyłączeniem czterech pierwszych parametrów Przykładowe rozwiązanie funkcjonalne aplikacji przedstawiono na rysunku - Rysunek

144 Tendencje zmian parametrów sieciowych w przewozach pasażerskich Miasto/gmina/strefa Wybór linii transportu publicznego Bydgoszcz pełna analiza wszystkich linii Typ analizy Liczba podróży Toruń pełna analiza linii kolejowych Gmina Solec Kujawski Liczba przesiadek Gmina Koronowo pełna analiza linii tramwajowych.. Liczba osób pełna analiza linii autobusowych Strefa 1 Strefa 2 linia tramwajowa nr 1 Liczba pasażerów (jazd).. linia tramwajowa nr 2 Cały system transportowy Pasażerogodziny. Pasażerokilometry linia autobusowa nr 20 linia autobusowa nr 21 Wyniki obliczeń Parametry wstępne (obliczeniowe) zakres analizy przystanek komunikacyjny TAK NIE środek transportu TAK NIE autobus/tramwaj autobus/tramwaj TAK NIE autobus/tramwaj kolej TAK NIE kolej autobus/tramwaj TAK NIE kolej kolej węzeł komunikacyjny TAK NIE B środek transportu TAK NIE autobus autobus TAK NIE autobus tramwaj TAK NIE tramwaj autobus TAK NIE tramwaj tramwaj TAK NIE kolej autobus TAK NIE autobus kolej TAK NIE kolej tramwaj TAK NIE tramwaj kolej TAK NIE kolej kolej określ typ podróży 2 podróże wyłącznie w granicach obszaru/strefy A podróże rozpoczęte poza obszarem i zakończone w obszarze/strefie B podróże rozpoczęte w obszarze i zakończone poza obszarem/strefą C podróże tranzytowe przez obszar/strefę D wszystkie podróże związane z obszarem/strefą E okres analizy wstępne określenie maksymalnego czasu przesiadki [min] 4 Przesiadki 1 A UWAGA: Możliwość wybrania jednocześnie jednej lub wielu opcji przystanek komunikacyjny 15 węzeł komunikacyjny 45 zakres analizy Średnia liczba podróży na dobę, TORUŃ, średnia kwantyl 95% podróże wyłącznie w granicach obszaru/strefy przystanek komunikacyjny środek transportu autobus/tramwaj autobus/tramwaj autobus/tramwaj kolej kolej autobus/tramwaj kolej kolej węzeł komunikacyjny B środek transportu autobus autobus autobus tramwaj tramwaj autobus tramwaj tramwaj kolej autobus autobus kolej kolej tramwaj tramwaj kolej kolej kolej Export danych do pliku Powrót do parametrów wstępnych pdf A Export danych do Excel Należy wprowadzić maksymalny czas na przesiadkę z dokładnością do 1 minuty.. Liczba podróży na rok, TORUŃ, liczba przesiadek Czas przesiadki [min] RAPORT str DATA ANALIZY TORUŃ wszystkie podróże związane z obszarem/strefą Typ analizy PODRÓŻE podróży/rok 2 y = -7607,3x x + 1E+07 R2 = 0, podróży/dobę y = -50,464x2 + 52,243x R2 = 0, Lata Średnia liczba podróży Zmiana rok/rok na dobę lata lata Zapis wykresu do pliku pdf Zmiana rok/rok , , , , , , , Liczba podróży na rok Export danych do pliku pdf Utwórz wykresy -2,20 Export danych do Excel Zapis wykresu do pliku pdf Rysunek 55 Aplikacja Tendencje zmian parametrów sieciowych w przewozach pasażerskich przykładowe rozwiązanie. 144

145 24.12 Aplikacja MAPA DLA MODUŁU ANALIZ PRZEMIESZCZEŃ PASAŻERÓW funkcjonalność aplikacji Aplikacja mapa dla modułu analiz przemieszczeń pasażerów musi umożliwiać bezpośrednie przejście z poziomu mapy do analiz szczegółowych, po wcześniejszym wskazaniu określonego elementu infrastruktury lub transportu, dla którego ma zostać przeprowadzona analiza Aktywne elementy mapy muszą stanowić: a) przystanki komunikacyjne przejście do aplikacji analiza ruchu pasażerskiego na przystankach, b) linie komunikacyjne przejście do aplikacji analiza ruchu pasażerskiego na liniach komunikacyjnych transportu publicznego, c) trasy komunikacyjne przejście do aplikacji analiza ruchu pasażerskiego w wybranym przekroju trasy komunikacyjnej, d) rejony komunikacyjne przejście do aplikacji analiza przemieszczeń pasażerów Wykonawca jest zobowiązany do dostarczenia mapy, na której będą wprowadzone wszystkie elementy infrastrukturalne dotyczące w/w elementów podlegających analizie Aplikacja mapa dla modułu analiz przemieszczeń pasażerów musi umożliwiać wprowadzanie niniejszych elementów (aktualizacja informacji o sieci komunikacyjnej transportu publicznego). Podkładem graficznym mapy musi być mapa topograficzna obszaru metropolitalnego z naniesioną siecią dróg, ulic i linii kolejowych oraz ważniejszych informacji topograficznych (stawy, jeziora, lasy itp.) Aplikacja mapa musi być zaprojektowana w architekturze wielowarstwowej umożliwiającej w przyszłości rozszerzenie o dodawanie nowych funkcjonalności. Rozwiązanie to musi zapewniać pełną skalowalność Przykładowe rozwiązanie funkcjonalne aplikacji przedstawiono na rysunku - Rysunek

146 analiza przystanku komunikacyjnego analiza linii komunikacyjnej Kolej_007 Bydg_A85 Bydg_A82 analiza linii komunikacyjnej analiza linii komunikacyjnej analiza przystanku komunikacyjnego Osielsko_035 Bydg_A88 analiza linii komunikacyjnej analiza transportu publicznego w przekroju drogi analiza transportu publicznego w przekroju drogi analiza przemieszczeń pasażerów Osielsko_rk_02 Legenda przystanek komunikacyjny (AUTOBUS, TRAMWAJ) przystanek komunikacyjny (KOLEJ) Moduł Mapa dla analiz przemieszczeń pasażerów linia komunikcyjna (KOLEJ) linia komunikcyjna (AUTOBUS, TRAMWAJ) rejon komunikacyjny Bydg_A82 Osielsko_035 Osielsko_rk_02 podświetlony numer linii komunikacyjnej podświetlony numer przystanku komunikacyjnego podświetlony numer rejonu komunikacyjnego analiza linii komunikacyjnej dostępna analiza komunikacyjna Rysunek 56 Aplikacja Mapa dla Modułu Analiz przemieszczeń pasażerów przykładowe rozwiązanie. 146

147 24.13 Aplikacja EXPORT DANYCH DO PROGRAMU VISUM funkcjonalność aplikacji Aplikacja export danych do programu VISUM musi umożliwiać przygotowanie pliku w formacie programu Excel z danymi zawierającymi następujące informacje: a) dobowy ruch (rozkład godzinowy) potoków pasażerski na odcinkach międzyprzystankowych (z uwzględnieniem kierunków ruchu) z podziałem na poszczególne linie komunikacyjne transportu publicznego, b) dobowy ruch (rozkład godzinowy) pasażerów wsiadających i wysiadających na poszczególnych przystankach komunikacyjnych transportu publicznego z podziałem na poszczególne linie komunikacyjne Aplikacja musi umożliwiać tworzenie plików z w/w danymi z podziałem dla dowolnie określonych obszarów/stref np. miasta Torunia Aplikacja musi umożliwiać automatyczne opracowanie danych zbiorczych na podstawie analizy wybranego okresu jednej doby lub kilku dni (możliwość wybrania z kalendarza dowolnych dni do analizy np. czwartki). W przypadku wybrania do analizy kilku dni, utworzone dane, przedstawione w postaci macierzy danych, muszą podawać wartości średnie (ruch godzinowy) obliczone z danych dla poszczególnych dni poddanych analizie. 25 Serwis, utrzymanie systemu i świadczenie gwarancji W ramach realizacji zadania Wykonawca Systemu Biletu Metropolitalnego udzieli gwarancji na dostarczone oprogramowanie na okres 5 lat. Okres ten jest liczony od daty podpisania ostatniego protokołu odbioru (odbiór bez uwag). W ramach gwarancji Wykonawca zapewni także serwis gwarancyjny. Wszelkie koszty gwarancji wraz z serwisem gwarancyjnym muszą być włączone do ceny ofertowej W ramach serwisu gwarancyjnego oprogramowania Wykonawca: wykona na miejscu u Zamawiającego przeglądy gwarancyjne oprogramowania i baz danych w liczbie minimum dwa przeglądy na rok. Przeglądy gwarancyjne obejmą: kontrolę integralności i spójności baz danych, doprowadzenie do integralnych i spójnych baz danych, poprawę, kontrolę, konfiguracji i poprawności działania oprogramowania, uwzględni łącznie 160 godz. pracy specjalistów na żądanie Zamawiającego z wyłączeniem konsultacji telefonicznych, konsultacji w siedzibie Zamawiającego zmierzających do rozwiązania problemu lub rozwiązujących problem. Po otrzymaniu zgłoszenia i przeprowadzeniu wstępnej analizy problemu, Wykonawca oszacuje liczbę godzin pracy specjalistów, potrzebną do rozwiązania problemu. Zamawiający na tej podstawie podejmie decyzję o zleceniu. Podstawą do rozliczenia będzie protokół zrealizowania zlecenia, który dostarczy Wykonawca w ramach odbioru pracy. Ponadto Zamawiający przewiduje możliwość pracy specjalisty w swojej siedzibie w czasie, w którym niezbędny będzie bieżący kontakt specjalisty z Zamawiającym, 147

148 usunie awarie programowe, usunie błędy baz danych (w tym brak spójności i integralności danych, itp.) nie polegające na błędnej obsłudze, będzie informował Zamawiającego o dostępnych aktualizacjach/poprawkach oprogramowania, sterowników, bibliotek (system informatyczny, system operacyjny serwerów, modułów transmisji, macierzy dyskowych, serwerów, routerów, urządzeń sieciowych, baz danych, kasowników, sterowników kasowników, innych elementów istotnych dla bezpieczeństwa i właściwego funkcjonowania systemu), sprawdzenie dostępności aktualizacji/poprawki będzie się odbywać przed każdym przeglądem systemu. Zamawiający wymaga jednak, aby Wykonawca sprawdził, czy dana aktualizacja/poprawka nie wpływa negatywnie na działanie systemu. Aktualizacje, poprawki oprogramowania, sterowników, bibliotek muszą być zaktualizowane jeśli system będzie wymagał takowych do poprawnej pracy, zapewni prawidłowe (nieograniczone czasowo i funkcjonalnie) działanie systemu, w godzinach roboczych zapewni telefoniczne wsparcie techniczne umożliwiające zgłaszanie awarii oprogramowania, a także zaproponuje procedurę zgłaszania awarii krytycznych poza godzinami roboczymi, zapewni telefoniczne konsultacje merytoryczne przy rozwiązywaniu problemów z oprogramowaniem w godzinach roboczych, Zamawiający wyraża zgodę na uzupełnienie systemu o urządzenia i oprogramowanie konieczne do ustanowienia zdalnego dostępu na potrzeby serwisu oprogramowania przez Wykonawcę. Koszty związane z ustanowieniem zdalnego dostępu muszą zostać uwzględnione w cenie oferty dotyczy to tej części urządzeń i oprogramowania, które zostaną zainstalowane u Zamawiającego. Wymagania techniczne dotyczące zdalnego dostępu na potrzeby serwisu oprogramowania: połączenie za pomocą VPN, ograniczenie liczby adresów IP z jakich może być nawiązane połączenie zdalne, możliwość ograniczenia czasowego nawiązywania połączeń zdalnych oraz blokowania zdalnego dostępu przez Zamawiającego Czas naprawy od zgłoszenia awarii programowej (w godzinach) podano w tabeli - Błąd! Nie można odnaleźć źródła odwołania.: (w tabeli podane są czasy naprawy w godzinach roboczych / poza godzinami roboczymi). 148

149 Tabela 4 Czas naprawy awarii systemu. Typ systemu Awaria krytyczna Awaria niekrytyczna Usterka System informatyczny (awarie oprogramowania użytkowego) Środowisko systemu operacyjnego i bazodanowe 8/24 24/72 7dni 8/24 24/72 7dni Pozostałe systemy 72/72 96/96 14 dni pozostałe systemy dotyczą innych, nie wymienionych w tabeli systemów, dostarczonych przez Wykonawcę w ramach projektu 25.4 Do programowych awarii gwarancyjnych Zamawiający zalicza: a) wszelkie awarie w funkcjonowaniu oprogramowania, b) błędy baz danych (w tym brak spójności i integralności danych, itp.) niezawinione przez użytkowników systemu (tzn. nie powstałe na wskutek błędnego wprowadzania danych i złej obsługi systemu) system musi być zaprojektowany tak, aby był odporny na wprowadzanie, c) niewłaściwych danych, nieumiejętną obsługę itp. na poziomie aplikacji Czas reakcji na zgłoszenie awarii odnosi się do oprogramowania użytkowego dostarczonego przez Wykonawcę w ramach niniejszego postępowania, dla którego Wykonawca posiada możliwość prawną i techniczną ingerencji w kod źródłowy Przez naprawę dla awarii programowej Zamawiający rozumie: a) naprawę wadliwego oprogramowania, b) rekonfigurację wadliwych ustawień, c) naprawę baz danych, d) naprawę zawartości baz danych (w tym brak spójności i integralności danych, itp.) Czas na usunięcie awarii liczy się od momentu powiadomienia Wykonawcy w formie pisemnej (dopuszcza się także faksem, em wraz z potwierdzeniem telefonicznym otrzymania). Powiadomienie może także nastąpić poprzez telefoniczne przekazanie informacji na wskazany przez Wykonawcę numer telefonu komórkowego lub wysłanie na ten numer wiadomości SMS W okresie gwarancyjnym Wykonawca zapewni Zamawiającemu 800 h pracy programistów do wykorzystania na zmiany w dostarczonym oprogramowaniu wykraczające poza zakres niniejszego Opisu przedmiotu zamówienia Wykonawca musi w okresie 5 lat gwarancji zapewnić Zamawiającemu wsparcie dla zgłoszeń serwisowych w formie systemu Helpdesk umożliwiającego zgłaszanie awarii za pośrednictwem interfejsu WWW. System Helpdesk powinien ponadto umożliwiać Zamawiającemu generowanie statystyk napraw. Wykonawca utworzy w ramach tego 149

150 systemu kompletną bazę danych urządzeń dostarczonych do Zamawiającego w ramach tego zamówienia. System ma być dostępny dla poszczególnych użytkowników po zalogowaniu System musi wspierać również zarządzanie zmianami (tzw. Change Management) Wykonawca systemu dostosuje istniejącą u Zamawiającego infrastrukturę funkcjonującego systemu Bydgoskiej Karty Miejskiej do działania w systemie SBM Wyposażenie techniczne objęte dostosowaniem w ramach systemu SBM: Automaty biletowe firmy Scheidt & Bachmann (10 szt.) będące własnością ZDMiKP w Bydgoszczy posiadające parametry techniczno-funkcjonalne: Obudowa wandaloodporna wykonana z wysokiej jakości stali, dodatkowe wzmocnienia w częściach szczególnie narażonych na włamania i wandalizm. Cała konstrukcja jest wykonana w taki sposób, aby zminimalizować ilość widocznych łączeń, spawów itp. Krawędzie zewnętrzne obudowy są tak ukształtowane aby nie powodowały niebezpieczeństwa uszkodzenia odzieży lub zranienia. Krawędzie 150

PROPOZYCJA NOWEGO SYSTEMU BILETOWEGO 2014. Poznań, 9.05.2013

PROPOZYCJA NOWEGO SYSTEMU BILETOWEGO 2014. Poznań, 9.05.2013 PROPOZYCJA NOWEGO SYSTEMU BILETOWEGO 2014 Poznań, 9.05.2013 Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego w ramach Wielkopolskiego Regionalnego Programu Operacyjnego

Bardziej szczegółowo

TARYFA MAJ 2014. Poznań, 25.11.2013

TARYFA MAJ 2014. Poznań, 25.11.2013 TARYFA MAJ 2014 Poznań, 25.11.2013 Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego w ramach Wielkopolskiego Regionalnego Programu Operacyjnego na lata 2007-2013

Bardziej szczegółowo

Projekt systemu zintegrowanej. zbiorowego w LGOM. www.interregiorail.eu info@interregiorail.eu

Projekt systemu zintegrowanej. zbiorowego w LGOM. www.interregiorail.eu info@interregiorail.eu Projekt systemu zintegrowanej taryfy biletowej dla transportu zbiorowego w LGOM This project is implemented through the CENTRAL EUROPE Programme co-financed by the ERDF 15.09.2011 1 Rodzaje taryf: Jednolita

Bardziej szczegółowo

Metoda ustalania wskaźników w rozliczeniach z tytułu wzajemnego honorowania biletów. mgr inż. Szymon Klemba Warszawa, 5.02.2013 r.

Metoda ustalania wskaźników w rozliczeniach z tytułu wzajemnego honorowania biletów. mgr inż. Szymon Klemba Warszawa, 5.02.2013 r. Metoda ustalania wskaźników w rozliczeniach z tytułu wzajemnego honorowania biletów mgr inż. Szymon Klemba Warszawa, 5.02.2013 r. SPIS TREŚCI 1 Tło badań 2 Problem 3 Metoda rozwiązania 4 Zastosowanie metody

Bardziej szczegółowo

REGULAMIN. sprzedaży biletów elektronicznych jednorazowych i okresowych MZK Sp. z o.o. w Opolu za pomocą telefonu komórkowego

REGULAMIN. sprzedaży biletów elektronicznych jednorazowych i okresowych MZK Sp. z o.o. w Opolu za pomocą telefonu komórkowego REGULAMIN sprzedaży biletów elektronicznych jednorazowych i okresowych MZK Sp. z o.o. w Opolu za pomocą telefonu komórkowego Użyte w niniejszym Regulaminie definicje oznaczają: 1. System System sprzedaży

Bardziej szczegółowo

PEKA UŁATWIA ŻYCIE W MIEŚCIE. 14 dni do wejścia w życie nowej taryfy biletowej

PEKA UŁATWIA ŻYCIE W MIEŚCIE. 14 dni do wejścia w życie nowej taryfy biletowej PEKA UŁATWIA ŻYCIE W MIEŚCIE 14 dni do wejścia w życie nowej taryfy biletowej Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego w ramach Wielkopolskiego Regionalnego

Bardziej szczegółowo

Opis przedmiotu zamówienia Część 2 zamówienia

Opis przedmiotu zamówienia Część 2 zamówienia I. Część 2 zamówienia składa się z dwóch Zadań. II. ZADANIE 1. 1. Przedmiotem Zadania 1. jest: 1) przeprowadzenie przez Wykonawcę badań napełnienia pojazdów (wielkości popytu na usługi transportu publicznego)

Bardziej szczegółowo

System satelitarnego pozycjonowania i nadzoru pojazdów, maszyn i urządzeń

System satelitarnego pozycjonowania i nadzoru pojazdów, maszyn i urządzeń System satelitarnego pozycjonowania i nadzoru pojazdów, maszyn i urządzeń www.autosoftware.com.pl w w w. d i g i t r a c k. p l System pozycjonowania pojazdów i urządzeń występujący pod nazwą handlową

Bardziej szczegółowo

Załącznik Nr 2 do Druku NR 1. ZAŁĄCZNIK Nr 1 do Umowy

Załącznik Nr 2 do Druku NR 1. ZAŁĄCZNIK Nr 1 do Umowy Załącznik Nr 2 do Druku NR 1 ZAŁĄCZNIK Nr 1 do Umowy Na wykonanie Zintegrowany system transportu publicznego w obszarze aglomeracji krakowskiej. Opracowanie zostanie wykonane w ramach realizacji projektu

Bardziej szczegółowo

Regulamin. 1 Zakres stosowania. 2 Definicje zawarte w Regulaminie

Regulamin. 1 Zakres stosowania. 2 Definicje zawarte w Regulaminie Regulamin Regulamin KUP BILET ON LINE Przedsiębiorstwa Komunikacji Samochodowej w Elblągu Spółka z ograniczoną odpowiedzialnością (dalej zwana PKS Elbląg lub Przewoźnikiem). Przedsiębiorstwo Komunikacji

Bardziej szczegółowo

TECHNOLOGIE JUTRA DZISIAJ NOWOCZESNE ZARZĄDZANIE MAJĄTKIEM

TECHNOLOGIE JUTRA DZISIAJ NOWOCZESNE ZARZĄDZANIE MAJĄTKIEM TECHNOLOGIE JUTRA DZISIAJ NOWOCZESNE ZARZĄDZANIE MAJĄTKIEM PODSTAWA PRAWNA Każda instytucja publiczna oraz przedsiębiorstwa zobowiązane są do prowadzenia ewidencji majątku oraz jego okresowej inwentaryzacji.

Bardziej szczegółowo

Integracja komunikacji miejskiej na. obszarze działania Metropolitalnego Związku Komunikacyjnego Zatoki Gdańskiej

Integracja komunikacji miejskiej na. obszarze działania Metropolitalnego Związku Komunikacyjnego Zatoki Gdańskiej Integracja komunikacji miejskiej na obszarze działania Metropolitalnego Związku Komunikacyjnego Zatoki Gdańskiej Kamil Bujak Metropolitalny Związek Komunikacyjny Zatoki Gdańskiej Bydgoszcz, 21-22 września

Bardziej szczegółowo

WYKONANIE OPROGRAMOWANIA DEDYKOWANEGO

WYKONANIE OPROGRAMOWANIA DEDYKOWANEGO Zapytanie ofertowe nr 1/2014 Wrocław, dn. 29.01.2014 Lemitor Ochrona Środowiska Sp. z o. o. ul. Jana Długosza 40, 51-162 Wrocław tel. recepcja: 713252590, fax: 713727902 e-mail: biuro@lemitor.com.pl NIP:

Bardziej szczegółowo

Bydgoszcz, dnia 16 kwietnia 2014 r. Poz. 1341

Bydgoszcz, dnia 16 kwietnia 2014 r. Poz. 1341 DZIENNIK URZĘDOWY WOJEWÓDZTWA KUJAWSKO-POMORSKIEGO Bydgoszcz, dnia 16 kwietnia 2014 r. Poz. 1341 POROZUMIENIE MIĘDZYGMINNE zawarte w Bydgoszczy w dniu 15 kwietnia 2014 r. pomiędzy: 1. Miastem Bydgoszczą

Bardziej szczegółowo

Wysokości opłat i ceny biletów za przejazdy lokalnym transportem zbiorowym

Wysokości opłat i ceny biletów za przejazdy lokalnym transportem zbiorowym Wysokości opłat i ceny biletów za przejazdy lokalnym transportem zbiorowym Tabela 1. Opłaty za przejazdy przy użyciu tportmonetki na karcie PEKA. Lp. Liczba przejechanych przystanków podczas jednej podróży

Bardziej szczegółowo

Organizacja transportu publicznego

Organizacja transportu publicznego Organizacja transportu publicznego Jędrzej Gadziński Instytut Geografii Społeczno-Ekonomicznej i Gospodarki Przestrzennej UAM w Poznaniu Projekt częściowo finansowany przez Unię Europejską w ramach Programu

Bardziej szczegółowo

Lp. Parametry Wymagane Warunek Opisać 1 Serwer 1.1 Producent oprogramowania Podać 1.2 Kraj pochodzenia Podać 1.3. Wymóg.

Lp. Parametry Wymagane Warunek Opisać 1 Serwer 1.1 Producent oprogramowania Podać 1.2 Kraj pochodzenia Podać 1.3. Wymóg. Lp. Parametry Wymagane Warunek Opisać 1 Serwer 1.1 Producent oprogramowania Podać 1.2 Kraj pochodzenia Podać 1.3 Licencja bezterminowa na jeden serwer fizyczny 2 System operacyjny serwera 2.1 System operacyjny

Bardziej szczegółowo

WYKAZ NOWYCH OFERT WAŻNYCH OD DNIA 01.03.2014r.

WYKAZ NOWYCH OFERT WAŻNYCH OD DNIA 01.03.2014r. WYKAZ NOWYCH OFERT WAŻNYCH OD DNIA 01.03.2014r. Karta Senior-SKM (Kod zniżki 48 30%, Kod zniżki 55 50% 1. Uprawnieni Osoby, które ukończyły 65 lat i nabyły kartę Senior SKM. 2. Zakres ważności 1) karta

Bardziej szczegółowo

Poprawa systemu transportu publicznego poprzez zakup nowoczesnego taboru wraz z niezbędną infrastrukturą przez Komunikację Miejską Płock Sp. z o.o.

Poprawa systemu transportu publicznego poprzez zakup nowoczesnego taboru wraz z niezbędną infrastrukturą przez Komunikację Miejską Płock Sp. z o.o. Poprawa systemu transportu publicznego poprzez zakup nowoczesnego taboru wraz z niezbędną infrastrukturą przez Komunikację Miejską Płock Sp. z o.o. Zadanie 1 Zakup 15 sztuk nowych, nowoczesnych autobusów

Bardziej szczegółowo

UCHWAŁA NR XLVII/1003/13 RADY MIASTA BYDGOSZCZY. z dnia 30 października 2013 r.

UCHWAŁA NR XLVII/1003/13 RADY MIASTA BYDGOSZCZY. z dnia 30 października 2013 r. UCHWAŁA NR XLVII/1003/13 RADY MIASTA BYDGOSZCZY z dnia 30 października 2013 r. w sprawie ustalenia przepisów taryfowych w publicznym transporcie zbiorowym w Bydgoszczy Na podstawie art. 8 ust. 1 ustawy

Bardziej szczegółowo

Komputerowy system elektronicznego dzienniczka ucznia e-dziennik

Komputerowy system elektronicznego dzienniczka ucznia e-dziennik Komputerowy system elektronicznego dzienniczka ucznia e-dziennik Komputerowy system elektronicznego dzienniczka ucznia e-dziennik jest serwisem internetowym przeznaczonym dla szkół podstawowych, gimnazjalnych

Bardziej szczegółowo

System PEKA Podstawowe informacje

System PEKA Podstawowe informacje Znak sprawy:ztm.kzp.3410-13/14 Załącznik nr 5d do SIWZ System PEKA Podstawowe informacje Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego w ramach Wielkopolskiego

Bardziej szczegółowo

Funkcje standardowej wersji programu WAGMASTER (obsługa wag samochodowych)

Funkcje standardowej wersji programu WAGMASTER (obsługa wag samochodowych) Funkcje standardowej wersji programu WAGMASTER (obsługa wag samochodowych) Program WAGMASTER w standardowej konfiguracji, współpracuje z bazą danych MS Access. Ma również możliwość współpracy bazami danych

Bardziej szczegółowo

Kraków, dnia 7 kwietnia 2015 r. Poz. 2030 UCHWAŁA NR VI/51/2015 RADY GMINY BUKOWINA TATRZAŃSKA. z dnia 26 marca 2015 roku

Kraków, dnia 7 kwietnia 2015 r. Poz. 2030 UCHWAŁA NR VI/51/2015 RADY GMINY BUKOWINA TATRZAŃSKA. z dnia 26 marca 2015 roku DZIENNIK URZĘDOWY WOJEWÓDZTWA MAŁOPOLSKIEGO Kraków, dnia 7 kwietnia 2015 r. Poz. 2030 UCHWAŁA NR VI/51/2015 RADY GMINY BUKOWINA TATRZAŃSKA z dnia 26 marca 2015 roku w sprawie określenia przystanków komunikacyjnych

Bardziej szczegółowo

OPIS PRZEDMIOTU ZAMÓWIENIA. Przedmiotem zamówienia jest : dzierżawa systemu do lokalizacji i monitorowania pojazdów.

OPIS PRZEDMIOTU ZAMÓWIENIA. Przedmiotem zamówienia jest : dzierżawa systemu do lokalizacji i monitorowania pojazdów. OPIS PRZEDMIOTU ZAMÓWIENIA Przedmiotem zamówienia jest : dzierżawa systemu do lokalizacji i monitorowania pojazdów. 38200-4 Globalne systemy nawigacji i pozycjonowania (GPS lub równorzędne), 7230000- Usługi

Bardziej szczegółowo

Dodatek do Taryfy przewozowej PKP SKM (TP-SKM)

Dodatek do Taryfy przewozowej PKP SKM (TP-SKM) Dodatek do Taryfy przewozowej PKP SKM (TP-SKM) zawierający zasady odprawy i tabele opłat stosowanych przy przejazdach na podstawie biletów metropolitalnych emitowanych przez Metropolitalny Związek Komunikacyjny

Bardziej szczegółowo

Integracja taryfowa w aglomeracji warszawskiej z punktu widzenia organizatora przewozów. Leszek Ruta, Dyrektor ZTM

Integracja taryfowa w aglomeracji warszawskiej z punktu widzenia organizatora przewozów. Leszek Ruta, Dyrektor ZTM Integracja taryfowa w aglomeracji warszawskiej z punktu widzenia organizatora przewozów Leszek Ruta, Dyrektor ZTM Warszawski system transportu zbiorowego w pigułce Podstawowe informacje o ZTM 2 Struktura

Bardziej szczegółowo

KOMUNIKAT PRASOWY ZARZĄDU TRANSPORTU MIEJSKIEGO W POZNANIU

KOMUNIKAT PRASOWY ZARZĄDU TRANSPORTU MIEJSKIEGO W POZNANIU KOMUNIKAT PRASOWY ZARZĄDU TRANSPORTU MIEJSKIEGO W POZNANIU Integracja komunikacji gminy Suchy Las i Poznania od 28 stycznia 2013 (linie nr 67, 88, 901, 902, 904, 905, 907, 911) Poznań, dnia 09.01.2013

Bardziej szczegółowo

ZAMAWIAJĄCY. CONCEPTO Sp. z o.o.

ZAMAWIAJĄCY. CONCEPTO Sp. z o.o. Grodzisk Wielkopolski, dnia 11.02.2013r. ZAMAWIAJĄCY z siedzibą w Grodzisku Wielkopolskim (62-065) przy ul. Szerokiej 10 realizując zamówienie w ramach projektu dofinansowanego z Programu Operacyjnego

Bardziej szczegółowo

Systemy Smart City w ZTM Lublin

Systemy Smart City w ZTM Lublin Systemy Smart City w ZTM Lublin Plan prezentacji 1. Dane gromadzone przez ZTM 2. Systemy zarządzane przez ZTM 3. Obszary wyróżniania się ZTM w kraju 4. Infrastruktura służąca systemom smart city 5. Dane,

Bardziej szczegółowo

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA Projekt współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Opolskiego na lata 2007-2013 inwestujemy w

Bardziej szczegółowo

Rozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ

Rozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ Załącznik nr 2 do umowy nr 11/DI/PN/2013 PROCEDURA UTRZYMANIA I ROZWOJU APLIKACJI CENTRALNEJ Rozdział 1. WPROWADZENIE Celem niniejszego dokumentu jest sprecyzowanie procedury zarządzania realizacją umowy

Bardziej szczegółowo

Specyfikacja techniczna GoBiz Virtual Office - systemu dostępu do zasobów wirtualnego biura przez Internet

Specyfikacja techniczna GoBiz Virtual Office - systemu dostępu do zasobów wirtualnego biura przez Internet Specyfikacja techniczna GoBiz Virtual Office - systemu dostępu do zasobów wirtualnego biura przez Internet Spis treści 1. Opis przedmiotu zamówienia... 1 1.1. Definicje... 1 2. Główny cel systemu... 2

Bardziej szczegółowo

GoBiz System platforma współpracy marektingowej

GoBiz System platforma współpracy marektingowej GoBiz System platforma współpracy marektingowej Spis treści 1. Opis przedmiotu zamówienia... 1 1.1. Definicje... 1 2. Główny cel platformy... 2 3. Główni odbiorcy systemu... 2 4. Przedmiot zamówienia...

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH

PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH Załącznik nr 2 do umowy nr 37/DI/PN/2013 PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH Rozdział 1. WPROWADZENIE Celem niniejszego dokumentu jest sprecyzowanie procedury zarządzania

Bardziej szczegółowo

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA BL-VI.272.94.2012 zał. nr 2 do siwz SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA I. PRZEDMIOT ZAMÓWIENIA OBEJMUJE: 1. Dostawę, instalację i uruchomienie Systemu do zarządzania projektami dla Programu Ochrony

Bardziej szczegółowo

TARYFA PRZEWOZOWA za usługi przewozowe środkami lokalnego transportu zbiorowego w m.st. Warszawie nadzorowanego przez Zarząd Transportu Miejskiego

TARYFA PRZEWOZOWA za usługi przewozowe środkami lokalnego transportu zbiorowego w m.st. Warszawie nadzorowanego przez Zarząd Transportu Miejskiego Załącznik nr 3 do Uchwały Nr.../.../2011 Rady m.st. Warszawy z dnia... 2011 r. w sprawie opłat za usługi przewozowe środkami lokalnego transportu zbiorowego w m.st. Warszawie TARYFA PRZEWOZOWA za usługi

Bardziej szczegółowo

SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42

SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42 SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH info@prointegra.com.pl tel: +48 (032) 730 00 42 1. WPROWADZENIE... 3 2. KORZYŚCI BIZNESOWE... 4 3. OPIS FUNKCJONALNY VILM... 4 KLUCZOWE FUNKCJE

Bardziej szczegółowo

Bydgoszcz, lutego 2015 r. WIR.IV.431.4.2014. Pan Piotr Całbecki Marszałek Województwa Kujawsko-Pomorskiego Pl. Teatralny 2 87-100 Toruń

Bydgoszcz, lutego 2015 r. WIR.IV.431.4.2014. Pan Piotr Całbecki Marszałek Województwa Kujawsko-Pomorskiego Pl. Teatralny 2 87-100 Toruń WOJEWODA KUJAWSKO-POMORSKI WIR.IV.431.4.2014 Bydgoszcz, lutego 2015 r. Pan Piotr Całbecki Marszałek Województwa Kujawsko-Pomorskiego Pl. Teatralny 2 87-100 Toruń WYSTĄPIENIE POKONTROLNE Na podstawie art.

Bardziej szczegółowo

X-CONTROL -FUNKCJONALNOŚCI

X-CONTROL -FUNKCJONALNOŚCI X-CONTROL -FUNKCJONALNOŚCI X-CONTROL FUNKCJONALNOŚCI* *Funkcjonalności zostały omówione w kolejności logicznej. Kolejność na pulpicie; patrz widok powyżej, została zaplanowana dla wygody użytkownika. 1.

Bardziej szczegółowo

Organizacja transportu publicznego w Metropolii Zatoki Gdańskiej stan istniejący i kierunki rozwoju

Organizacja transportu publicznego w Metropolii Zatoki Gdańskiej stan istniejący i kierunki rozwoju Organizacja transportu publicznego w Metropolii Zatoki Gdańskiej stan istniejący i kierunki rozwoju Hubert Kołodziejski Metropolitalny Związek Komunikacyjny Zatoki Gdańskiej Olgierd Wyszomirski Uniwersytet

Bardziej szczegółowo

POROZUMIENIE MIĘDZYGMINNE

POROZUMIENIE MIĘDZYGMINNE POROZUMIENIE MIĘDZYGMINNE w dniu 31 grudnia 2008r. w Warszawie Miasto Stołeczne Warszawa, z siedzibą w Warszawie, pl. Bankowy 3/5, zwane dalej Miastem reprezentowane przez: Pana Leszka Rutę - p.o. Dyrektora

Bardziej szczegółowo

POZNAŃSKA ELEKTRONICZNA KARTA AGLOMERACYJNA korzyści dla pasażerów, mieszkańców, miasta. Poznań, 9.05.2013

POZNAŃSKA ELEKTRONICZNA KARTA AGLOMERACYJNA korzyści dla pasażerów, mieszkańców, miasta. Poznań, 9.05.2013 POZNAŃSKA ELEKTRONICZNA KARTA AGLOMERACYJNA korzyści dla pasażerów, mieszkańców, miasta Poznań, 9.05.2013 Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego w

Bardziej szczegółowo

Zamawiający dysponuje szerokim spektrum rozwiązań infrastrukturalnych. Wykonawca uzyska dostęp do infrastruktury w niezbędnym zakresie.

Zamawiający dysponuje szerokim spektrum rozwiązań infrastrukturalnych. Wykonawca uzyska dostęp do infrastruktury w niezbędnym zakresie. Prosimy o precyzyjne wyjaśnienie, co Zamawiający rozumie pod pojęciem bezterminowej i pełnej licencji, wraz z prawem do dysponowania dokumentacją i wprowadzaniem zmian? Na jakich polach eksploatacji ma

Bardziej szczegółowo

Gdańsk, 16 kwietnia 2015 r.

Gdańsk, 16 kwietnia 2015 r. Wdrożenie systemu biletu elektronicznego jako narzędzia integracji taryfowo-biletowej transportu publicznego na Obszarze Metropolitalnym Trójmiasta umożliwiającego wprowadzenie wspólnego biletu Założenia

Bardziej szczegółowo

Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach

Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach OPIS WYMGŃ FUNKCJONLNO-TECHNICZNYCH dla zamówienia: Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach 2015-2016 Przedmiot zamówienia Przedmiotem zamówienia jest usługa

Bardziej szczegółowo

Instrukcje instalacji pakietu IBM SPSS Data Access Pack dla systemu Windows

Instrukcje instalacji pakietu IBM SPSS Data Access Pack dla systemu Windows Instrukcje instalacji pakietu IBM SPSS Data Access Pack dla systemu Windows Spis treści Rozdział 1. Przegląd......... 1 Wstęp................. 1 Wdrażanie technologii Data Access........ 1 Źródła danych

Bardziej szczegółowo

LBY 4110-003-01/2014 R/14/004 WYSTĄPIENIE POKONTROLNE

LBY 4110-003-01/2014 R/14/004 WYSTĄPIENIE POKONTROLNE LBY 4110-003-01/2014 R/14/004 WYSTĄPIENIE POKONTROLNE I. Dane identyfikacyjne kontroli Numer i tytuł kontroli Jednostka przeprowadzająca kontrolę Kontroler Jednostka kontrolowana R/14/004 Korzystanie

Bardziej szczegółowo

Najnowsze trendy w systemach pobierania opłat w transporcie publicznym

Najnowsze trendy w systemach pobierania opłat w transporcie publicznym Najnowsze trendy w systemach pobierania opłat w transporcie publicznym Zbigniew Rusak Waldemar Rokicki Nośniki biletów stosowane w Polsce bilety papierowe bilety z paskiem magnetycznym karty elektroniczne

Bardziej szczegółowo

Karty katalogowe 2012 PZI TARAN

Karty katalogowe 2012 PZI TARAN MUNICOM.premium Karty katalogowe 2012 PZI TARAN MUNICOM.premium by PZI TARAN System MUNICOM.premium jest zintegrowanym pakietem oprogramowania do wspomagania zarządzania przedsiębiorstwem Autorem systemu

Bardziej szczegółowo

System kontroli kosztów oraz dostępu do urządzeń

System kontroli kosztów oraz dostępu do urządzeń System kontroli kosztów oraz dostępu do urządzeń Jest to wielomodułowy system, komponowany według potrzeb oraz wymagań Klienta dający możliwość kontroli wykonywanych zadań, w tym monitorowanie kosztów

Bardziej szczegółowo

Inteligentne Systemy Transportowe

Inteligentne Systemy Transportowe w Bydgoszczy dr inż. Jacek Chmielewski inż. Damian Iwanowicz Katedra Budownictwa Drogowego Wydział Budownictwa i Inżynierii Środowiska Uniwersytet Technologiczno-Przyrodniczy im. Jana i Jędrzeja Śniadeckich

Bardziej szczegółowo

Deduplikacja danych. Zarządzanie jakością danych podstawowych

Deduplikacja danych. Zarządzanie jakością danych podstawowych Deduplikacja danych Zarządzanie jakością danych podstawowych normalizacja i standaryzacja adresów standaryzacja i walidacja identyfikatorów podstawowa standaryzacja nazw firm deduplikacja danych Deduplication

Bardziej szczegółowo

SKRÓCONY OPIS systemu lojalnościowego

SKRÓCONY OPIS systemu lojalnościowego SKRÓCONY OPIS systemu lojalnościowego na podstawie wersji 2.0 PRODUCENT: Basic-Soft Ostrów Wlkp. AKTUALNA WERSJA: Kontrahent GT wersja 2.0 Zabrania się powielania, publikowania i rozpowszechniania bez

Bardziej szczegółowo

Currenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3

Currenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3 Currenda EPO Instrukcja Konfiguracji Wersja dokumentu: 1.3 Currenda EPO Instrukcja Konfiguracji - wersja dokumentu 1.3-19.08.2014 Spis treści 1 Wstęp... 4 1.1 Cel dokumentu... 4 1.2 Powiązane dokumenty...

Bardziej szczegółowo

Zapytanie ofertowe nr 01/12/2013

Zapytanie ofertowe nr 01/12/2013 nr 01/12/2013 Zakup i wdrożenie systemu B2B a także integracja wszystkich elementów systemu B2B oraz szkolenie specjalistyczne Warszawa, 20.11.2013 Działanie POIG 8.2 Veriti sp. z o.o. ul. Koszycka 8 01-446

Bardziej szczegółowo

POLITYKA BEZPIECZEŃSTWA w zakresie ochrony danych osobowych w ramach serwisu zgloszenia24.pl

POLITYKA BEZPIECZEŃSTWA w zakresie ochrony danych osobowych w ramach serwisu zgloszenia24.pl POLITYKA BEZPIECZEŃSTWA w zakresie ochrony danych osobowych w ramach serwisu zgloszenia24.pl SPIS TREŚCI I. POSTANOWIENIA OGÓLNE... 2 II. DEFINICJA BEZPIECZEŃSTWA INFORMACJI... 2 III. ZAKRES STOSOWANIA...

Bardziej szczegółowo

System Kontroli Dostępu. Zarządzanie kontrolą dostępu do budynków biurowych i zakładów produkcyjnych

System Kontroli Dostępu. Zarządzanie kontrolą dostępu do budynków biurowych i zakładów produkcyjnych System Kontroli Dostępu Zarządzanie kontrolą dostępu do budynków biurowych i zakładów produkcyjnych 1 Czym jest System Kontroli Dostępu? System Kontroli Dostępu (SKD) to rozwiązanie przeznaczone do zarządzania

Bardziej szczegółowo

aplikacja akcyzattor

aplikacja akcyzattor Wdrożenie systemu służącego do prowadzenia ewidencji energii elektrycznej w formie elektronicznej dla potrzeb rozliczeń podatku akcyzowego aplikacja akcyzattor Klient: KGHM Polska Miedź S.A. Klient KGHM

Bardziej szczegółowo

Zasady Wykorzystywania Plików Cookies

Zasady Wykorzystywania Plików Cookies Zasady Wykorzystywania Plików Cookies Definicje i objaśnienia używanych pojęć Ilekroć w niniejszym zbiorze Zasad wykorzystywania plików Cookies pojawia się któreś z poniższych określeń, należy rozumieć

Bardziej szczegółowo

OPIS FUNKCJONALNY PLATFORMY B2B

OPIS FUNKCJONALNY PLATFORMY B2B OPIS FUNKCJONALNY PLATFORMY B2B Moduły funkcjonalne składające się na platformę B2B 1. Moduł Zarządzanie strukturami i użytkownikami przedsiębiorstwa Moduł pomoże w zbudowaniu wirtualnych podmiotów gospodarczych,

Bardziej szczegółowo

Nowe funkcje w programie SYMFONIA Środki Trwałe Forte w wersji 2009.a

Nowe funkcje w programie SYMFONIA Środki Trwałe Forte w wersji 2009.a SYMFONIA Środki Trwałe Forte Strona 1 z 1 Nowe funkcje w programie SYMFONIA Środki Trwałe Forte w wersji 2009.a Inwentaryzacja według miejsc użytkowania Umożliwiono inwentaryzację środków trwałych według

Bardziej szczegółowo

SEO.341-4/06 Gryfino, dnia 27 czerwca 2006r.

SEO.341-4/06 Gryfino, dnia 27 czerwca 2006r. projekt e-gryfino I wdrożenie rozwiązań społeczeństwa informacyjnego w Gminie GRYFINO Projekt współfinansowany przez Unię Europejską w ramach Zintegrowanego Programu Operacyjnego Rozwoju Regionalnego działanie

Bardziej szczegółowo

UMOWA nr ZG/.. zawarta w dniu.. 2011 r. w Rzeszowie pomiędzy:

UMOWA nr ZG/.. zawarta w dniu.. 2011 r. w Rzeszowie pomiędzy: UMOWA nr ZG/.. zawarta w dniu.. 2011 r. w Rzeszowie pomiędzy: Związkiem Gmin Podkarpacka Komunikacja Samochodowa 35-959 Rzeszów Aleja Wyzwolenia 6, pok.26 NIP 517 02 83 749 Regon 180411226 wpisanym do

Bardziej szczegółowo

PRZEWOZY AUTOBUSOWE GRYF SP. Z O.O. SP. K. Z A S A D Y T A R Y F O W E

PRZEWOZY AUTOBUSOWE GRYF SP. Z O.O. SP. K. Z A S A D Y T A R Y F O W E PRZEWOZY AUTOBUSOWE GRYF SP. Z O.O. SP. K. Z A S A D Y T A R Y F O W E przewozu osób i rzeczy w komunikacji autobusowej realizowanej przez Przewozy Autobusowe GRYF TEKST UJEDNOLICONY ŻUKOWO 2013 Rozdział

Bardziej szczegółowo

UCHWAŁA NR XVI/301/2011 RADY MIASTA STOŁECZNEGO WARSZAWY z dnia 26 maja 2011 r.

UCHWAŁA NR XVI/301/2011 RADY MIASTA STOŁECZNEGO WARSZAWY z dnia 26 maja 2011 r. UCHWAŁA NR XVI/301/2011 RADY MIASTA STOŁECZNEGO WARSZAWY z dnia 26 maja 2011 r. zmieniająca uchwałę w sprawie opłat za usługi przewozowe środkami lokalnego transportu zbiorowego w m.st. Warszawie, zmiany

Bardziej szczegółowo

Karty katalogowe 2012 PZI TARAN

Karty katalogowe 2012 PZI TARAN MUNICOM.premium Karty katalogowe 2012 PZI TARAN MUNICOM.premium by PZI TARAN System MUNICOM.premium jest zintegrowanym pakietem oprogramowania do wspomagania zarządzania przedsiębiorstwem Autorem systemu

Bardziej szczegółowo

PROCEDURA WERYFIKACJI I OCENY DEKLAROWANYCH FUNKCJONALNOŚCI OPROGRAMOWANIA OFEROWANEGO PRZEZ WYKONAWCĘ NA ETAPIE OCENY OFERTY

PROCEDURA WERYFIKACJI I OCENY DEKLAROWANYCH FUNKCJONALNOŚCI OPROGRAMOWANIA OFEROWANEGO PRZEZ WYKONAWCĘ NA ETAPIE OCENY OFERTY Załącznik nr 10 do SIWZ znak EZP/5511/2013 PROCEDURA WERYFIKACJI I OCENY DEKLAROWANYCH FUNKCJONALNOŚCI OPROGRAMOWANIA OFEROWANEGO PRZEZ WYKONAWCĘ NA ETAPIE OCENY OFERTY 1. Zamawiający przeprowadzi procedurę

Bardziej szczegółowo

BSX PRINTER INSTRUKCJA UŻYTKOWNIKA. Autor: Karol Wierzchołowski 30 marca 2015

BSX PRINTER INSTRUKCJA UŻYTKOWNIKA. Autor: Karol Wierzchołowski 30 marca 2015 ! BSX PRINTER INSTRUKCJA UŻYTKOWNIKA Autor: Karol Wierzchołowski 30 marca 2015 SPIS TREŚCI WSTĘP... 3 INTERFEJS PROGRAMU... 5 KONFIGURACJA PROGRAMU... 6 DRUKOWANIE PARAGONÓW I FAKTUR... 8 REJESTRACJA PROGRAMU...

Bardziej szczegółowo

DOTACJE NA INNOWACJE INWESTUJEMY W WASZĄ PRZYSZŁOŚĆ

DOTACJE NA INNOWACJE INWESTUJEMY W WASZĄ PRZYSZŁOŚĆ Mrągowo, dn. 21.01.2014 r Szanowni Państwo! Firma AdamS H. Pędzich z siedzibą w Mrągowie ul. Giżycka 5, producent okien i drzwi, na potrzeby realizacji projektu Wdrożenie systemu do zarządzania produkcją

Bardziej szczegółowo

WYJAŚNIENIA NR 2 TREŚCI SIWZ

WYJAŚNIENIA NR 2 TREŚCI SIWZ CPI-ZZP-2244-40-495/13 Warszawa, dnia 24 stycznia 2013 roku Wykonawcy, którzy pobrali SIWZ w postępowaniu nr 40-CPI-ZZP-2244/12 Działając na podstawie art. 38 ust. 1a, ust. 2 i ust. 4 w zw. z art. 12a

Bardziej szczegółowo

Wzrost zadań Zarządu Transportu Miejskiego w Poznaniu w zakresie Publicznego Transportu Zbiorowego STYCZEŃ 2015

Wzrost zadań Zarządu Transportu Miejskiego w Poznaniu w zakresie Publicznego Transportu Zbiorowego STYCZEŃ 2015 Wzrost zadań Zarządu Transportu Miejskiego w Poznaniu w zakresie Publicznego Transportu Zbiorowego STYCZEŃ 2015 Zarząd Transportu Miejskiego w Poznaniu działa w zakresie Publicznego Transportu Zbiorowego

Bardziej szczegółowo

THE ISSUE Głos Regionów

THE ISSUE Głos Regionów THE ISSUE Głos Regionów Finansowanie stacji Veturilo ze środków prywatnych Rower publiczny cieszy się w Warszawie olbrzymim zainteresowaniem. Powiększająca się liczba użytkowników i ilość wypożyczeń zachęcają

Bardziej szczegółowo

Zestaw pytao pozwalających na przygotowanie oferty wdrożenia Systemu Zarządzania Nieruchomościami

Zestaw pytao pozwalających na przygotowanie oferty wdrożenia Systemu Zarządzania Nieruchomościami Zestaw pytao pozwalających na przygotowanie oferty wdrożenia Systemu Zarządzania Nieruchomościami Spis treści 1. Hosting aplikacji... 3 Bezpieczeostwo fizyczne... 3 Wymagania techniczne aplikacji... 3

Bardziej szczegółowo

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU Projekt Rozwój elektronicznej administracji w samorządach województwa mazowieckiego wspomagającej niwelowanie dwudzielności potencjału województwa ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO

Bardziej szczegółowo

SYSTEM WSMS ZARZĄDZANIE STANDARDEM STACJI ROBOCZYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42

SYSTEM WSMS ZARZĄDZANIE STANDARDEM STACJI ROBOCZYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42 SYSTEM WSMS ZARZĄDZANIE STANDARDEM STACJI ROBOCZYCH info@prointegra.com.pl tel: +48 (032) 730 00 42 1. WPROWADZENIE... 3 2. KORZYŚCI BIZNESOWE... 4 3. OPIS FUNKCJONALNY WSMS... 4 WSMS AUDIT... 6 WSMS SM...

Bardziej szczegółowo

Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r.

Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r. Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r. Stworzenie platformy internetowej na potrzeby projektu. 1 Wykonanie portalu internetowego na potrzeby e-usługi, obejmującego

Bardziej szczegółowo

Kolej metropolitalna BiT City

Kolej metropolitalna BiT City Zintegrowany system transportu publicznego w aglomeracji bydgosko-toru toruńskiej Kolej metropolitalna BiT City Urząd Marszałkowski Województwa Kujawsko-Pomorskiego Zintegrowany Program Rozwoju Transportu

Bardziej szczegółowo

Problemy z jakimi spotykają się nowi przewoźnicy kolejowi

Problemy z jakimi spotykają się nowi przewoźnicy kolejowi Problemy z jakimi spotykają się nowi przewoźnicy kolejowi Problemy, z jakimi spotykają się nowi przewoźnicy kolejowi Pierwsze kroki przewoźnika przed rozpoczęciem działalności przewozowej: Uzyskanie licencji

Bardziej szczegółowo

Załącznik do umowy nr..

Załącznik do umowy nr.. Załącznik do umowy nr.. z dnia I Opis przedmiotu zamówienia specyfikacja techniczna: 1. System mobilny: Aplikacja przeznaczona dla telefonów z systemem Android, wersja 4.0 wzwyż i napisana w języku natywnym

Bardziej szczegółowo

EasyNet system zarządzania dostępem do sieci internet

EasyNet system zarządzania dostępem do sieci internet EasyNet system zarządzania dostępem do sieci internet System zarządzania dostępem do sieci Internet przeznaczony jest dla firm, administratorów którzy komercyjnie zajmują się organizowaniem dostępu do

Bardziej szczegółowo

OFERTA OPIEKI INFORMATYCZNEJ DLA FIRM

OFERTA OPIEKI INFORMATYCZNEJ DLA FIRM OFERTA OPIEKI INFORMATYCZNEJ DLA FIRM Wychodząc naprzeciw oczekiwaniom naszych klientów, oraz w trosce o najwyższą jakość świadczonych usług firma Neteris przygotowała program opieki informatycznej skierowany

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r.

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r. ZAPYTANIE OFERTOWE Wrocław, dnia 23.03.2015 r. W związku z realizacją przez Nova Telecom spółka z ograniczoną odpowiedzialnością, projektu pn.: Wdrożenie zintegrowanego systemu klasy B2B, umożliwiającego

Bardziej szczegółowo

Opis przedmiotu zamówienia. Uwaga: O ile nie zaznaczono inaczej, wszelkie warunki należy rozumieć jako minimalne.

Opis przedmiotu zamówienia. Uwaga: O ile nie zaznaczono inaczej, wszelkie warunki należy rozumieć jako minimalne. Załącznik nr 1 do SIWZ Opis przedmiotu zamówienia Uwaga: O ile nie zaznaczono inaczej, wszelkie warunki należy rozumieć jako minimalne. Wykonawca świadczy usługi telefonii komórkowej w oparciu o sieć obejmującą

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. nr 1/UE/2014. z dnia 7.01.2014 r. w związku z realizacją projektu pn.

ZAPYTANIE OFERTOWE. nr 1/UE/2014. z dnia 7.01.2014 r. w związku z realizacją projektu pn. Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Rozwoju Regionalnego ZAPYTANIE OFERTOWE nr /UE/204 z dnia 7.0.204 r. w związku z realizacją projektu pn. Wdrożenie

Bardziej szczegółowo

System Doładowania e-karty przez Internet (SDK) Podręcznik użytkownika

System Doładowania e-karty przez Internet (SDK) Podręcznik użytkownika System Doładowania e-karty przez Internet (SDK) Podręcznik użytkownika Strona 1 z 9 1 Portal użytkowników. Portal SDK to system umożliwiający użytkownikom tarnowskiej karty miejskiej uzyskanie informacji

Bardziej szczegółowo

Projekty współfinansowane ze środków europejskich. LUBLIN, luty 2012 r.

Projekty współfinansowane ze środków europejskich. LUBLIN, luty 2012 r. Projekty współfinansowane ze środków europejskich LUBLIN, luty 2012 r. Linie komunikacji miejskiej w Lublinie Linie trolejbusowe: 10 linii, w tym: 8 regularnych linii trolejbusowych 1 linia zjazdowa 1

Bardziej szczegółowo

Załącznik Nr 1 do SIWZ

Załącznik Nr 1 do SIWZ GMINA KAMIEŃ POMORSKI STARY RYNEK 1 72-400 KAMIEŃ POMORSKI Załącznik Nr 1 do SIWZ FORMULARZ OFERTOWY Nawiązując do postępowania w trybie przetarg nieograniczony na: Dostawa oprogramowania firma:... (nazwa

Bardziej szczegółowo

I N S T R U K C J A. zakupu biletów przez telefon komórkowy w systemie SkyCash oraz ich kontroli 1. ŚCIĄGNIĘCIE APLIKACJI

I N S T R U K C J A. zakupu biletów przez telefon komórkowy w systemie SkyCash oraz ich kontroli 1. ŚCIĄGNIĘCIE APLIKACJI I N S T R U K C J A zakupu biletów przez telefon komórkowy w systemie SkyCash oraz ich kontroli 1 2 3 4 5 ŚCIĄGNIĘCIE APLIKACJI- REJESTRACJA - DOŁADOWANIE KONTA - ZAKUP BILETU - KONTROLA BILETU 1. ŚCIĄGNIĘCIE

Bardziej szczegółowo

Projekt unijny. Wsparcie obsługi i bezpieczeństwa pasażerów MZK Jastrzębie innowacyjnymi systemami informatycznymi

Projekt unijny. Wsparcie obsługi i bezpieczeństwa pasażerów MZK Jastrzębie innowacyjnymi systemami informatycznymi PROJEKT UNIJNY Program Operacyjny: Infrastruktura i Środowisko na lata 2007-2013, Priorytet VIII: Bezpieczeństwo transportu i krajowe sieci transportowe, Działanie 8.3 Rozwój inteligentnych systemów transportowych.

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. Ul. Sikorskiego 28 44-120 Pyskowice NIP 6480001415 REGON 008135290. Oferty pisemne prosimy kierować na adres: Hybryd Sp. z o.o.

ZAPYTANIE OFERTOWE. Ul. Sikorskiego 28 44-120 Pyskowice NIP 6480001415 REGON 008135290. Oferty pisemne prosimy kierować na adres: Hybryd Sp. z o.o. ZAPYTANIE OFERTOWE Pyskowice, dn. 28.04.2014r. Szanowni Państwo, Zwracamy się do Państwa z zaproszeniem do złożenia ofert na ujęte w niniejszym zapytaniu ofertowym zakupy w związku z realizowanym w ramach

Bardziej szczegółowo

OP-IV.272.49.2015.LK Załącznik nr 1 do SIWZ. Opis przedmiotu zamówienia

OP-IV.272.49.2015.LK Załącznik nr 1 do SIWZ. Opis przedmiotu zamówienia Załącznik nr 1 do Opis przedmiotu zamówienia Uwaga: O ile nie zaznaczono inaczej, wszelkie warunki należy rozumieć jako minimalne. 1. Przedmiotem zamówienia jest świadczenie usług telekomunikacyjnych telefonii

Bardziej szczegółowo

SONDAŻ CENOWY. 2) pobieranie na rzecz Zamawiającego opłat dodatkowych i przewozowych za przejazd

SONDAŻ CENOWY. 2) pobieranie na rzecz Zamawiającego opłat dodatkowych i przewozowych za przejazd SONDAŻ CENOWY Zapraszam Państwa do złożenia oferty celem udzielenia zamówienia, do którego zgodnie z art. 4 pkt 8 ustawy z dnia 29 stycznia 2004r. Prawo zamówień publicznych (Dz. U. z 2010r. Nr 113, poz.

Bardziej szczegółowo

Rozliczenia ekonomiczno-finansowe pomiędzy organizatorami komunikacji miejskiej. Prof. dr hab. Olgierd Wyszomirski

Rozliczenia ekonomiczno-finansowe pomiędzy organizatorami komunikacji miejskiej. Prof. dr hab. Olgierd Wyszomirski Rozliczenia ekonomiczno-finansowe pomiędzy organizatorami komunikacji miejskiej Prof. dr hab. Olgierd Wyszomirski Rozliczenia ekonomiczno-finansowe pomiędzy organizatorami komunikacji miejskiej w świetle

Bardziej szczegółowo

Załącznik 1. Platforma komunikacyjna powinna posiadać następującą funkcjonalność:

Załącznik 1. Platforma komunikacyjna powinna posiadać następującą funkcjonalność: Załącznik 1 Wytyczne dotyczące funkcjonalności platformy komunikacyjnej umożliwiającej wymianę danych o wspólnych beneficjentach powiatowych urzędów pracy, jednostek organizacyjnych pomocy społecznej i

Bardziej szczegółowo

SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA

SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA Załącznik nr 2 SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA Dostawa oraz wdrożenie usług katalogowych Active Directory wraz z zakupem licencji oprogramowania oraz modernizacją serwera na potrzeby ww usługi

Bardziej szczegółowo

System informacji prawnej w wersji internetowej

System informacji prawnej w wersji internetowej Załącznik Nr 1 do SIWZ Nr spr. 27/ZP/CBA/2007 OKREŚLENIE PRZEDMIOTU ZAMÓWIENIA OBJĘTEGO UMOWĄ RAMOWĄ System informacji prawnej w wersji internetowej Przedmiotem zamówienia jest dostawa systemu informacji

Bardziej szczegółowo

Zintegrowane rozwiązania systemowe dla komunikacji publicznej

Zintegrowane rozwiązania systemowe dla komunikacji publicznej Zintegrowane rozwiązania systemowe dla komunikacji publicznej Bydgoszcz, październik 2014 Podejście systemowe Bogaty asortyment urządzeń Integracja podsystemów Wygoda korzystania Podejście systemowe Platforma

Bardziej szczegółowo