Usługa utrzymania infrastruktury serwerowej i sieciowej, a także asysty technicznej, bieżącej konserwacji i rozwoju systemów i oprogramowań wykorzystywanych przez Urząd Miejski w Białymstoku. - polska-białystok: usługi w zakresie konserwacji i napraw oprogramowania

Zamiast: 

Informacja o częściach postępowania, Część nr 2

5) Informacje dodatkowe na temat części zamówienia:

1. Przedmiotem jest świadczenie przez Wykonawcę na rzecz Zamawiającego usługi asysty technicznej, bieżącej konserwacji i rozbudowy systemu informatycznego dynamicznej informacji pasażerskiej zwanego dalej „Systemem”. Zamawiający dopuszcza także zamiennie, dostawę przez Wykonawcę bezterminowej i nielimitowanej stanowiskowo licencji na korzystanie z systemu dynamicznej informacji pasażerskiej i jego instalację na serwerach Zamawiającego. System powinien być kompatybilny z dotychczasowym i tożsamy co do funkcjonalności, na który będzie świadczona przez Wykonawcę usługa asysty technicznej, konserwacji i rozbudowy dostarczonego systemu. Czas na uruchomienie dostarczonego systemu wynosi 4 tygodnie od daty podpisania umowy. Na funkcjonalność obecnie wykorzystywanego systemu składają się następujące moduły:

1.1. Dotychczasowe moduły:

1.1.1. Moduł obsługi systemu za pośrednictwem przeglądarki www

1.1.2. Moduł komunikatora – możliwość wysyłania komunikatów tekstowych na terminal kierowcy danego nr bocznego pojazdu, możliwość wysyłania komunikatów do wszystkich pojazdów lub aktualnych pojazdów na linii,

1.1.3. Moduł alarmu antynapadowego – w momencie wciśnięcia przez kierowcę na terminalu kierowcy przycisku „!” na ekranie dyspozytora powinien pojawić się ekran z aktualną pozycją GPS pojazdu w którym dokonano takiego wciśnięcia,

1.1.4. Moduł importu danych rozkładowych z bazy MsSQL BusMan100CB,

1.1.5. Moduł eksportu danych rozkładowych i stref taryfowych do zajezdniowego systemu FareOn (pliki .ini i .txt wg specyfikacji systemu FareOn firmy Mikroelektronika).,

1.1.6. Moduł zarządzania liniami – możliwość mapowania nazwy linii z nazwy alfanumerycznej na linię numeryczną, możliwość dodawania i przypisania przewoźnika, możliwość oznakowania tzw. linii balonowej (tzw. agrafki – przy spełnieniu kilku warunków niektóre kolejne kursy na linii mogą być w aplikacji scalane w jeden), możliwość wyłączenia linii z prognozowania przybycia,

1.1.7. Moduł zarządzania przystankami – edycja i zarządzanie pozycjami GPS przystanków (WGS84), możliwość dodawania przystanku agrafkowego, określanie indywidualnego promienia strefy GPS, przypisywanie przystankowi cech takich jak punkt kontroli, przystanek wirtualny,

1.1.8. Moduł zarządzania bazą odcinków międzyprzystankowych – możliwość tworzenia stref taryfowych, Przypisywanie nr strefy da danego odcinka międzyprzystankowego przypisanego do danej linii na podstawie schematu koralikowego, tworzenie kształtu odcinka międzyprzystankowego na podstawie mechanizmu „drag and drop”,

1.1.9. Moduł zarzadzania bazą pojazdów – możliwość zarządzania aktualnym stanem pojazdów, przypisywanie nr bocznego, opisu pojazdu, aktualnie wykorzystywanych cech (krótki, długi, niska podłoga, standard/ponad standard), nazwy operatora, daty produkcji,

1.1.10. Moduł dyspozytora – raport dyspozytora w podziale na spółki na dany dzień. Zadaniem dyspozytora jest przypisanie do zaplanowanych zadań właściwego nr bocznego pojazdu. Możliwość definiowania podmian na podstawie wyboru właściwego wariantu i wskazania przystanku podmiany,

1.1.11. Moduł podglądu online – podgląd pojazdów na mapie z możliwością podglądu historii (od dnia, godziny do dnia i godziny)

1.1.12. Moduł koralików – podgląd pojazdów na synoptycznym schemacie linii

(tzw. koraliki) uwzględniającym wszystkie kierunki i warianty występujące na linii. Na koralikach poza naniesionym odcinkami międzyprzystankowymi powinien wyświetlać się pojazd z informacją o nr bocznym, aktualnym opóźnieniu, brygadzie,

1.1.13. Moduł wewnętrznego wirtualnego monitora – podgląd na mapie i prognoza pojazdów zbliżających się do przystanków,

1.1.14. Moduł zgłaszania awarii – możliwość zgłaszania awarii dot. systemu biletu elektronicznego (wybór pojazdu, wybór tematu, możliwość dodawania kolejnych tematów)

1.1.15. Moduł zarządzania użytkownikami – możliwość zarządzania użytkownikami

i przypisywania im grupy (np. spółki) i ról: Administrator, Dyspozytor Organizator. Każda rola ma możliwość edytowania przypisanym im funkcji. Możliwość przypisywania rolom praw do wykonywania określonych czynności,

1.1.16. Moduł przekazujący strumień danych – możliwość przekierowywania pozycji GPS na wskazany port i port IP,

1.1.17. Moduł analizy punktualności – możliwość rozliczania przewoźnika, tworzenia kar umownych, cenników, realizacja wykonywanych zadań, usprawiedliwienia, wykluczenia,

1.1.18. Moduł zarządzania tablicami – możliwość zarządzania tablicami

i komunikatami na przystankach. Możliwość konfiguracji i grupowania tablic. Możliwość wysyłania komunikatów tekstowych i graficznych na panele,

1.1.19. Moduł zmiany haseł,

1.1.20. Moduł publicznego serwisu Wirtualnego Monitora dostępny pod adresem www.przystanki.bialystok.pl – serwis przedstawia prognozę odjazdów

z przystanków i pozwala wyszukiwać przystanek po jego nr, nazwie, nr linii

i kierunku i nazwie ulicy,

1.1.21. Moduł interfejsu API (JSON) do wymiany danych pozycji GPS w czasie rzeczywistym dla zewnętrznych podmiotów – zbiór kilku relacyjnych zasobów JSON

1.1.22. Moduł interfejsu API (JSON i UDP) dla systemu sterowania ruchem PTP firmy Siemens,

1.1.23. Moduł pobierania danych z pojazdów (pozycje GPS z pojazdów co 10 sek., wciśnięcie przycisku alarmowego i komunikaty na terminal kierowcy)

1.1.24. Aplikacja panelowa – oprogramowanie zainstalowane na tablicach LED/LCD obsługujące wymianę danych z systemem centralnym i prezentowanie prognozy przybycia na tablicach LED/LCD włączając w to zapowiedzi dźwiękowe. Tablice pracują pod kontrolą systemu Windows XP Professional.

1.1.25. Moduł synchronizacji czasu – synchronizacja wszystkich elementów systemu

z serwera NTP

1.2. Nowe moduły – w ramach rozwoju i rozbudowy systemu Wykonawca powinien

w ciągu 2 miesięcy od daty podpisania umowy rozbudować system o następujące funkcjonalności:

1.2.1. Moduł rejestracja zdarzeń wciśnięcia przycisku alarmu antynapadowego

w bazie –zapisywanie do bazy nr bocznego, godziny i daty zdarzenia,

1.2.2. Rozbudowany moduł dot. funkcjonalności zgłaszania awarii o wszystkie urządzenia i oprogramowanie funkcjonujące w sferze komunikacji miejskiej

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

1.2.3. Moduł wymiany danych API (JSON) dot. bieżących danych o położeniu i taryfie dla danego pojazdu. Zapytanie do systemu centralnego, którego parametrem jest nr boczny pojazdu i ew. pozycja GPS urządzenia, powinno w przypadku pojazdu będącego onlinie (działające GSM i GPS) zwracać w postacie zasobu JSON informację dot. cech danego pojazdu i bieżących parametrów obsługiwanego przez pojazdu kursu takich jak: typ pojazdu, nazwa operatora, nr obsługiwanej linii, nr brygady, flaga czy pojazd jest online, czas ostatniego wysłania pozycji GPS, pozycja GPS pojazdu, listę kolejnych przystanków na kursie wraz z informacją o odległości między przystankami i informacją

o strefach taryfowych dla kolejnych przystanków, poprzedni i następny przystanek. W przypadku kiedy pojazd jest offline zasób powinien zwracać teoretyczną informację gdzie pojazd być powinien. Lista parametrów udostępnianych przez system może ulec zmianie. Ponadto każde zapytanie o nr boczny pojazdu powinno być logowane z datą i godziną takiego zapytania

a także nr urządzenia z którego wysłane zostało zapytanie.

1.2.4. Rozbudowany moduł koralików – naniesienie przystanków na osi w odstępach proporcjonalnych do odległości międzyprzystankowych pomiędzy danymi przystankami. Dzięki zastosowaniu proporcjonalnego naniesienia przystanków, prezentacja przemieszczania lokalizacji pojazdów na koralikach powinna być płynna i nanoszona adekwatnie od wartości procentowego pokonania odcinka. Ponadto kliknięcie na dany pojazd powinno umożliwiać wyróżnienie pozostałej do pokonania trasy wraz z informacją dot. prognozy przybycia na kolejne przystanki trasy. Wskazanie na danym przystanku powinno pokazywać informację o możliwych przesiadkach i rozkładach jazdy.

1.2.5. Rozbudowany moduł dot. tworzenia kształtów odcinka międzyprzystankowego – system powinien oferować możliwość tworzenia kształtu odcinków międzyprzystankowych z wykorzystaniem funkcji autoroutingu. Użytkownik może zbudować osobiście cały kształt trasy na zasadzie tworzenia „drag and drop”, dodatkowo naniesienie na trasie punktu pośredniego i uruchomienie funkcji autoroutingu powinno automatycznie spowodować zaproponowanie użytkownikowi kształtu poprowadzonego ulicami

i przechodzącego przez uprzednio naniesiony punkt pośredni.

1.2.6. Moduł wykrywania pojazdów w uprzednio zdefiniowanych strefach. Wykrywanie i informowanie o obecności pojazdów w uprzednio zdefiniowanych w systemie obszarach (poligonach) miasta, ulic, zajezdni etc. Możliwość dodawania na trasie przejazdu linii punktów wirtualnych (krytyczne punkty na trasie jak skrzyżowanie, włączenie się do ruchu) w celu przesłaniu do systemu informacji o pozycji pojazdu pomiędzy przystankami na danej trasie,

1.2.7. Rozbudowany moduł dot. algorytmu prognozującego przybycie pojazdów. Nowy algorytm powinien umożliwiać uwzględnienia opóźnienia na kursie poprzednim na prognozę przybycia dla kursów następnych.

1.2.8. Moduł sprawdzający jakość predykcji – zamawiający powinien mieć dostęp do modułu w którym wybierze datę, właściwy przystanek, godzinę odjazdu dla danej linii i sprawdzi jak kształtowała się prognoza odjazdu autobusu

w przedziale najbliższych 30 minut poprzedzających odjazd z rozdzielczością równą okresowi wysyłania telegramów z pojazdu (min. co 10 sek.) Na podstawie gwałtownych zmian estymacji w opisanej funkcjonalności, Zamawiający może domagać się bezpłatnej modyfikacji algorytmów odpowiedzialnych za estymację.

1.2.9. Rozbudowany moduł publicznego serwisu Wirtualnego Monitora www.przystanki.bialystok.pl – serwis powinien umożliwiać poza prognozą wyświetlanie nr bocznego pojazdu realizującego odjazd i jego cech w formie ikon takich jak niska podłoga, klimatyzacja, pojazd przystosowany do przewozu rowerów etc.

1.2.10. Moduł sumowania kilku równoległych źródeł sygnału GPS z pojazdów.

W przypadku pojawienia się kolejnego równoległego źródła sygnału GPS

z pojazdów, Wykonawca powinien bezpłatnie w ramach umowy zintegrować źródło ze swoim systemem.

2. Usługi o których mowa będą prowadzone w zakresie:

2.1. usuwania błędów krytycznych tj. błędów uniemożliwiających Zamawiającemu korzystanie z funkcji Systemu niezbędnych do bieżącej pracy, w ciągu ……… (wartość zadeklarowana w formularzu ofertowym przez Wykonawcę ale nie dłużej niż 26h) godzin od momentu zgłoszenia, pod warunkiem spełnienia zapisu określonego w § 3 ust. 2,

2.2. usuwania błędów niekrytycznych w ciągu 3 dni roboczych od momentu zgłoszenia, bądź w ciągu 7 dni roboczych od momentu zgłoszenia, w przypadku konieczności wykonania prac w siedzibie Zamawiającego,

2.3. doprowadzenia do odzyskania spójności bazy danych w przypadku wykrycia błędów w funkcjonowaniu systemu, o których mowa powyżej,

2.4. pomocy i doradztwa w zakresie użytkowania Systemu,

2.5. aktualizacji Systemu wynikających ze zmiany przepisów prawnych w terminie:

2.5.1. do dnia poprzedzającego dzień wejścia w życie przepisu dla którego ogłoszono vacatio legis;

2.5.2. do 14 dni od dnia właściwej promulgacji przepisu wchodzącego w życie z pominięciem okresu vacatio legis.

2.6. otrzymywania kolejnych wersji Systemu,

2.7. dostarczania raportów zmian w dokumentacji użytkowej i administratora Systemu, wynikających z aktualizacji Systemu,

2.8. ponownej instalacji Systemu w terminie 3 dni od daty zlecenia, w przypadku jeśli nie będzie wykonalne usunięcie błędów uniemożliwiających działanie Systemu,

2.9. dostarczanie Zamawiającemu aktualnego opisu struktury zbioru danych wskazującego zawartość poszczególnych pól informacyjnych i powiązania między nimi.

3. W przypadku zmian obejmujących kluczową część oprogramowania termin ustala się

w drodze negocjacji pomiędzy Wykonawcą i Zamawiającym.

IV.3.4) Termin składania ofert lub wniosków o dopuszczenie do udziału w postępowaniu:

31.5.2016 (8:45)

IV.3.8) Warunki otwarcia ofert:

31.5.2016 (9:00)

Powinno być: 

Informacja o częściach postępowania, Część nr 2

5) Informacje dodatkowe na temat części zamówienia:

1. Przedmiotem jest świadczenie przez Wykonawcę na rzecz Zamawiającego usługi asysty technicznej, bieżącej konserwacji i rozbudowy systemu informatycznego dynamicznej informacji pasażerskiej zwanego dalej „Systemem”. Zamawiający dopuszcza także zamiennie, dostawę przez Wykonawcę bezterminowej i nielimitowanej stanowiskowo licencji na korzystanie z systemu dynamicznej informacji pasażerskiej i jego instalację na serwerach Zamawiającego. System powinien być kompatybilny z dotychczasowym i tożsamy co do funkcjonalności, na który będzie świadczona przez Wykonawcę usługa asysty technicznej, konserwacji i rozbudowy dostarczonego systemu. Czas na uruchomienie dostarczonego systemu wynosi 4 tygodnie od daty podpisania umowy. Na funkcjonalność obecnie wykorzystywanego systemu składają się następujące moduły:

1.1. Dotychczasowe moduły:

1.1.1. Moduł obsługi systemu za pośrednictwem przeglądarki www

1.1.2. Moduł komunikatora – możliwość wysyłania komunikatów tekstowych na terminal kierowcy danego nr bocznego pojazdu, możliwość wysyłania komunikatów do wszystkich pojazdów lub aktualnych pojazdów na linii,

1.1.3. Moduł alarmu antynapadowego – w momencie wciśnięcia przez kierowcę na terminalu kierowcy przycisku „!” na ekranie dyspozytora powinien pojawić się ekran z aktualną pozycją GPS pojazdu w którym dokonano takiego wciśnięcia,

1.1.4. Moduł importu danych rozkładowych z bazy MsSQL BusMan100CB,

1.1.5. Moduł eksportu danych rozkładowych i stref taryfowych do zajezdniowego systemu FareOn (pliki .ini i .txt wg specyfikacji systemu FareOn firmy Mikroelektronika).,

1.1.6. Moduł zarządzania liniami – możliwość mapowania nazwy linii z nazwy alfanumerycznej na linię numeryczną, możliwość dodawania i przypisania przewoźnika, możliwość oznakowania tzw. linii balonowej (tzw. agrafki – przy spełnieniu kilku warunków niektóre kolejne kursy na linii mogą być w aplikacji scalane w jeden), możliwość wyłączenia linii z prognozowania przybycia,

1.1.7. Moduł zarządzania przystankami – edycja i zarządzanie pozycjami GPS przystanków (WGS84), możliwość dodawania przystanku agrafkowego, określanie indywidualnego promienia strefy GPS, przypisywanie przystankowi cech takich jak punkt kontroli, przystanek wirtualny,

1.1.8. Moduł zarządzania bazą odcinków międzyprzystankowych – możliwość tworzenia stref taryfowych, Przypisywanie nr strefy da danego odcinka międzyprzystankowego przypisanego do danej linii na podstawie schematu koralikowego, tworzenie kształtu odcinka międzyprzystankowego na podstawie mechanizmu „drag and drop”,

1.1.9. Moduł zarzadzania bazą pojazdów – możliwość zarządzania aktualnym stanem pojazdów, przypisywanie nr bocznego, opisu pojazdu, aktualnie wykorzystywanych cech (krótki, długi, niska podłoga, standard/ponad standard), nazwy operatora, daty produkcji,

1.1.10. Moduł dyspozytora – raport dyspozytora w podziale na spółki na dany dzień. Zadaniem dyspozytora jest przypisanie do zaplanowanych zadań właściwego nr bocznego pojazdu. Możliwość definiowania podmian na podstawie wyboru właściwego wariantu i wskazania przystanku podmiany,

1.1.11. Moduł podglądu online – podgląd pojazdów na mapie z możliwością podglądu historii (od dnia, godziny do dnia i godziny)

1.1.12. Moduł koralików – podgląd pojazdów na synoptycznym schemacie linii

(tzw. koraliki) uwzględniającym wszystkie kierunki i warianty występujące na linii. Na koralikach poza naniesionym odcinkami międzyprzystankowymi powinien wyświetlać się pojazd z informacją o nr bocznym, aktualnym opóźnieniu, brygadzie,

1.1.13. Moduł wewnętrznego wirtualnego monitora – podgląd na mapie i prognoza pojazdów zbliżających się do przystanków,

1.1.14. Moduł zgłaszania awarii – możliwość zgłaszania awarii dot. systemu biletu elektronicznego (wybór pojazdu, wybór tematu, możliwość dodawania kolejnych tematów)

1.1.15. Moduł zarządzania użytkownikami – możliwość zarządzania użytkownikami

i przypisywania im grupy (np. spółki) i ról: Administrator, Dyspozytor Organizator. Każda rola ma możliwość edytowania przypisanym im funkcji. Możliwość przypisywania rolom praw do wykonywania określonych czynności,

1.1.16. Moduł przekazujący strumień danych – możliwość przekierowywania pozycji GPS na wskazany port i port IP,

1.1.17. Moduł analizy punktualności – możliwość rozliczania przewoźnika, tworzenia kar umownych, cenników, realizacja wykonywanych zadań, usprawiedliwienia, wykluczenia,

1.1.18. Moduł zarządzania tablicami – możliwość zarządzania tablicami

i komunikatami na przystankach. Możliwość konfiguracji i grupowania tablic. Możliwość wysyłania komunikatów tekstowych i graficznych na panele,

1.1.19. Moduł zmiany haseł,

1.1.20. Moduł publicznego serwisu Wirtualnego Monitora dostępny pod adresem www.przystanki.bialystok.pl – serwis przedstawia prognozę odjazdów

z przystanków i pozwala wyszukiwać przystanek po jego nr, nazwie, nr linii i kierunku i nazwie ulicy,

1.1.21. Moduł interfejsu API (JSON) do wymiany danych pozycji GPS w czasie rzeczywistym dla zewnętrznych podmiotów – zbiór kilku relacyjnych zasobów JSON

1.1.22. Moduł interfejsu API (JSON i UDP) dla systemu sterowania ruchem PTP firmy Siemens,

1.1.23. Moduł pobierania danych z pojazdów (pozycje GPS z pojazdów co 10 sek., wciśnięcie przycisku alarmowego i komunikaty na terminal kierowcy)

1.1.24. Aplikacja panelowa – oprogramowanie zainstalowane na tablicach LED/LCD obsługujące wymianę danych z systemem centralnym i prezentowanie prognozy przybycia na tablicach LED/LCD włączając w to zapowiedzi dźwiękowe. Tablice pracują pod kontrolą systemu Windows XP Professional.

1.1.25. Moduł synchronizacji czasu – synchronizacja wszystkich elementów systemu

z serwera NTP

1.2. Nowe moduły – w ramach rozwoju i rozbudowy systemu Wykonawca powinien

w ciągu 2 miesięcy od daty podpisania umowy rozbudować system o następujące funkcjonalności:

1.2.1. Moduł rejestracja zdarzeń wciśnięcia przycisku alarmu antynapadowego

w bazie –zapisywanie do bazy nr bocznego, godziny i daty zdarzenia,

1.2.2. Rozbudowany moduł dot. funkcjonalności zgłaszania awarii o wszystkie urządzenia i oprogramowanie funkcjonujące w sferze komunikacji miejskiej

w tym systemy autobusowe i zajezdniowe a także tablice przystankowe. Zgłoszenie awarii/problemu powinno polegać na wybraniu (odfiltrowaniu) z listy grupy urządzeń np. aby zgłosić niedziałającą tablicę LED w pojeździe należy wybrać grupę Pojazdy -> Nr boczny pojazdu -> Grupę tablic -> Właściwą tablicę i opisać problem. Powinna istnieć możliwość rozbudowy listy, jej modyfikacji a także dodawania dodatkowych poziomów i grup urządzeń. Do każdej grupy urządzeń powinna być możliwość przypisania uprzednio zdefiniowanego użytkownika będącego przedstawicielem gwaranta/serwisanta. Każde zgłoszenie powinno być rejestrowane z możliwością zmiany jego statusów i mailowym powiadomieniem każdej zmiany statusu.

1.2.3. Moduł wymiany danych API (JSON) dot. bieżących danych o położeniu i taryfie dla danego pojazdu. Zapytanie do systemu centralnego, którego parametrem jest nr boczny pojazdu i ew. pozycja GPS urządzenia, powinno w przypadku pojazdu będącego onlinie (działające GSM i GPS) zwracać w postacie zasobu JSON informację dot. cech danego pojazdu i bieżących parametrów obsługiwanego przez pojazdu kursu takich jak: typ pojazdu, nazwa operatora, nr obsługiwanej linii, nr brygady, flaga czy pojazd jest online, czas ostatniego wysłania pozycji GPS, pozycja GPS pojazdu, listę kolejnych przystanków na kursie wraz z informacją o odległości między przystankami i informacją o strefach taryfowych dla kolejnych przystanków, poprzedni i następny przystanek. W przypadku kiedy pojazd jest offline zasób powinien zwracać teoretyczną informację gdzie pojazd być powinien. Lista parametrów udostępnianych przez system może ulec zmianie. Ponadto każde zapytanie o nr boczny pojazdu powinno być logowane z datą i godziną takiego zapytania a także nr urządzenia z którego wysłane zostało zapytanie.

1.2.4. Rozbudowany moduł koralików – naniesienie przystanków na osi w odstępach proporcjonalnych do odległości międzyprzystankowych pomiędzy danymi przystankami. Dzięki zastosowaniu proporcjonalnego naniesienia przystanków, prezentacja przemieszczania lokalizacji pojazdów na koralikach powinna być płynna i nanoszona adekwatnie od wartości procentowego pokonania odcinka. Ponadto kliknięcie na dany pojazd powinno umożliwiać wyróżnienie pozostałej do pokonania trasy wraz z informacją dot. prognozy przybycia na kolejne przystanki trasy. Wskazanie na danym przystanku powinno pokazywać informację o możliwych przesiadkach i rozkładach jazdy.

1.2.5. Rozbudowany moduł dot. tworzenia kształtów odcinka międzyprzystankowego – system powinien oferować możliwość tworzenia kształtu odcinków międzyprzystankowych z wykorzystaniem funkcji autoroutingu. Użytkownik może zbudować osobiście cały kształt trasy na zasadzie tworzenia „drag and drop”, dodatkowo naniesienie na trasie punktu pośredniego i uruchomienie funkcji autoroutingu powinno automatycznie spowodować zaproponowanie użytkownikowi kształtu poprowadzonego ulicami i przechodzącego przez uprzednio naniesiony punkt pośredni.

1.2.6. Moduł wykrywania pojazdów w uprzednio zdefiniowanych strefach. Wykrywanie i informowanie o obecności pojazdów w uprzednio zdefiniowanych w systemie obszarach (poligonach) miasta, ulic, zajezdni etc. Możliwość dodawania na trasie przejazdu linii punktów wirtualnych (krytyczne punkty na trasie jak skrzyżowanie, włączenie się do ruchu) w celu przesłaniu do systemu informacji o pozycji pojazdu pomiędzy przystankami na danej trasie,

1.2.7. Rozbudowany moduł dot. algorytmu prognozującego przybycie pojazdów. Nowy algorytm powinien umożliwiać uwzględnienia opóźnienia na kursie poprzednim na prognozę przybycia dla kursów następnych.

1.2.8. Moduł sprawdzający jakość predykcji – zamawiający powinien mieć dostęp do modułu w którym wybierze datę, właściwy przystanek, godzinę odjazdu dla danej linii i sprawdzi jak kształtowała się prognoza odjazdu autobusu

w przedziale najbliższych 30 minut poprzedzających odjazd z rozdzielczością równą okresowi wysyłania telegramów z pojazdu (min. co 10 sek.) Na podstawie gwałtownych zmian estymacji w opisanej funkcjonalności, Zamawiający może domagać się bezpłatnej modyfikacji algorytmów odpowiedzialnych za estymację.

1.2.9. Rozbudowany moduł publicznego serwisu Wirtualnego Monitora www.przystanki.bialystok.pl – serwis powinien umożliwiać poza prognozą wyświetlanie nr bocznego pojazdu realizującego odjazd i jego cech w formie ikon takich jak niska podłoga, klimatyzacja, pojazd przystosowany do przewozu rowerów etc.

1.2.10. Moduł sumowania kilku równoległych źródeł sygnału GPS z pojazdów.

W przypadku pojawienia się kolejnego równoległego źródła sygnału GPS z pojazdów, Wykonawca powinien bezpłatnie w ramach umowy zintegrować źródło ze swoim systemem,

1.2.11. Możliwość zaprezentowania na mapie liczby odjazdów z przystanków na liniach kursujących poza granice Białegostoku dla danego typu dnia a także dla wybranego przedziału godzin. Wyniki powinny być zaprezentowane w podziale na minimum 7 zakresów wartości. Do każdego zakresu można przypisać oddzielną dedykowaną ikonę. Otrzymane wyniki można wygenerować do pliku .KML

1.2.12. Możliwość prezentowania na mapie liczby kursów na przystankach dla wszystkich linii a także z podziałem na poszczególne linie. Wyniki powinny być możliwe do zaprezentowania dla danego typu dnia a także dla wybranego przedziału godzin. Wyniki powinny być zaprezentowane w podziale na minimum 14 zakresów wartości. Do każdego zakresu można przypisać oddzielną dedykowaną ikonę. Otrzymane wyniki można wygenerować plik .KML

1.2.13. Wymiana i aktualizacja plików zapowiedzi dźwiękowych dot. nr linii i nazwy przystanku końcowego (nazwy kierunku) do tablic powinna być odbywać się z poziomu systemu centralnego. Wszystkie przypisane do linii, przystanków, pliki dźwiękowe powinny być możliwe także do odsłuchania z poziomu systemu centralnego,

1.2.14. System centralny powinien oferować podgląd rzeczywistych treści wyświetlanych na poszczególnych tablicach z regulowaną manualnie częstotliwością odświeżania w zakresie 1-10 sek.,

1.2.15. Możliwość dodawania w systemie centralnym dodatkowych zapowiedzi dźwiękowych niedotyczących odjazdów wraz z przypisaniem im grupy tablic, harmonogramu i częstotliwości emisji bez konieczności wciskania przycisku wyzwalającego zapowiedzi.

1.2.16. Możliwość podglądu na mapie pozycji pojazdu z naniesioną trasą realizowanego kursu.

1.2.17. Zamawiający powinien mieć bieżący dostęp do pliku konfiguracyjnego algorytmu prognozującego w celu ręcznej zmiany zakresu historycznego przedziału czasu dla którego następuje estymacja.

2. Usługi o których mowa w § 1 ust. 1 będą prowadzone w zakresie:

2.1. usuwania błędów krytycznych tj. błędów uniemożliwiających Zamawiającemu korzystanie z funkcji Systemu niezbędnych do bieżącej pracy, w ciągu ……… (wartość zadeklarowana w formularzu ofertowym przez Wykonawcę ale nie dłużej niż 26h) godzin od momentu zgłoszenia, pod warunkiem spełnienia zapisu określonego w § 3 ust. 2,

2.2. usuwania błędów niekrytycznych w ciągu 3 dni roboczych od momentu zgłoszenia, bądź w ciągu 7 dni roboczych od momentu zgłoszenia, w przypadku konieczności wykonania prac w siedzibie Zamawiającego,

2.3. doprowadzenia do odzyskania spójności bazy danych w przypadku wykrycia błędów w funkcjonowaniu systemu, o których mowa powyżej,

2.4. pomocy i doradztwa w zakresie użytkowania Systemu,

2.5. aktualizacji Systemu wynikających ze zmiany przepisów prawnych w terminie:

2.5.1. do dnia poprzedzającego dzień wejścia w życie przepisu dla którego ogłoszono vacatio legis;

2.5.2. do 14 dni od dnia właściwej promulgacji przepisu wchodzącego w życie z pominięciem okresu vacatio legis.

2.6. otrzymywania kolejnych wersji Systemu,

2.7. dostarczania raportów zmian w dokumentacji użytkowej i administratora Systemu, wynikających z aktualizacji Systemu,

2.8. ponownej instalacji Systemu w terminie 3 dni od daty zlecenia, w przypadku jeśli nie będzie wykonalne usunięcie błędów uniemożliwiających działanie Systemu,

2.9. dostarczanie Zamawiającemu aktualnego opisu struktury zbioru danych wskazującego zawartość poszczególnych pól informacyjnych i powiązania między nimi.

3. W przypadku zmian obejmujących kluczową część oprogramowania termin ustala się w drodze negocjacji pomiędzy Wykonawcą i Zamawiającym.

IV.3.4) Termin składania ofert lub wniosków o dopuszczenie do udziału w postępowaniu:

2.6.2016 (8:45)

IV.3.8) Warunki otwarcia ofert:

2.6.2016 (9:00)

Inne dodatkowe informacje

Informacje do poprawienia lub dodania w odpowiedniej dokumentacji przetargowej.

Więcej informacji w odpowiedniej dokumentacji przetargowej.

Dyrektywa 2004/18/WE