Wytworzenie i utrzymanie systemu informacji pasażerskiej – Warszawa

Zamawiający wyjaśnia, że dokumentacja postępowania nie zawiera odrębnej, gotowej specyfikacji jednego interfejsu dla systemów sterowania Tablicami. Wykonawca cSIP ma w ramach Projektu Systemu zaprojektować i w pełni udokumentować interfejsy i protokoły komunikacyjne, wykorzystując wymagane w OPZ otwarte standardy i formaty. Dokumentacja ma obejmować zasady wymiany informacji, metody komunikacji i struktury danych. Po uzgodnieniu dokumentacji z Zamawiającym interfejs cSIP będzie stanowił wymagania integracyjne dla dostawców Tablic. Dla otwartych protokołów wymagana jest otwarta, bezpłatna i bezterminowa dostępność dokumentacji. Nie wymaga to zmiany obecnych wymagań cSIP.

Zamawiający wyjaśnia, że dostawa, instalacja i uruchomienie Wyświetlaczy/Tablic nie są przedmiotem tego postępowania. Testy akceptacyjne cSIP mają weryfikować System, jego funkcje oraz interfejsy integracyjne. OPZ wymaga od Wykonawcy przygotowania środowiska testowego, zestawu danych testowych i testów integracji, a jednocześnie zakazuje wykonywania testów na środowisku produkcyjnym. Dokumentacja postępowania nie przewiduje obowiązku Zamawiającego dostarczenia referencyjnych urządzeń e-ink, dlatego Wykonawca nie powinien uzależniać odbioru Systemu od ich udostępnienia. Zgodność z przyszłymi Tablicami e-ink będzie weryfikowana przede wszystkim przez zgodność z uzgodnionym i udokumentowanym interfejsem cSIP.

Zamawiający wyjaśnia, że OPZ nie wskazuje odrębnego symulatora Tablicy lub Wyświetlacza jako produktu ani elementu odbiorowego. Wymagana jest natomiast symulacja działania Modułu predykcji, w tym możliwość sprawdzania prognoz przy włączaniu i wyłączaniu źródeł danych, oraz zapewnienie testowalności funkcji Systemu i podglądu projektowanych Widoków. Jeżeli Wykonawca wykorzysta emulator, mock lub symulator urządzenia do własnych testów integracyjnych, będzie to narzędzie realizacyjne Wykonawcy, a nie dodatkowy przedmiot dostawy dla Zamawiającego.

Zamawiający wyjaśnia, że na etapie przyjęcia zgłoszenia klasyfikacja wynika ze skutku: brak synchronizacji danych na co najmniej 10 Tablicach spełnia definicję Usterki Krytycznej. Następnie w ramach diagnostyki ustalana jest przyczyna i zakres odpowiedzialności. Wykonawca cSIP odpowiada za elementy Systemu i interfejsy pozostające w jego zakresie. Nie przejmuje odpowiedzialności za naprawę fizycznej Tablicy, łącza LTE ani zewnętrznego systemu sterowania, jeżeli elementy te nie są dostarczane i utrzymywane w ramach niniejszego zamówienia. W takim przypadku Wykonawca cSIP odpowiada za niezwłoczną diagnostykę, dostarczenie logów i informacji pozwalających wskazać źródło problemu, utrzymanie lub odtworzenie poprawnego działania po stronie cSIP oraz współpracę z podmiotem odpowiedzialnym za element zewnętrzny. Trzygodzinny czas usunięcia Usterki Krytycznej dotyczy usunięcia przyczyny pozostającej w zakresie Wykonawcy cSIP.

Zamawiający wyjaśnia, że dla regularnego raportowania telemetrii OPZ określa wartość domyślną: nie rzadziej niż raz na dobę (24 h), z możliwością ustawienia krótszych interwałów - np. godzinowych - globalnie lub dla wybranej Tablicy. Częstotliwość może być różnicowana zależnie od rodzaju danych. Niezależnie od raportowania cyklicznego wymagany jest tryb zdarzeniowy: przy istotnych zdarzeniach lub anomaliach system ma niezwłocznie przyjmować dane telemetryczne. Wymóg ciągłego monitoringu nie oznacza więc jednej, stałej częstotliwości dla każdego parametru. Dla parametrów mogących wskazywać awarię mechanizm wspierający szybkie wykrycie i obsługę SLA jest transmisja zdarzeniowa oraz możliwość ustawienia krótszego interwału raportowania.

Zamawiający potwierdza - na poziomie cSIP dane telemetryczne mają być ujednolicone. OPZ wymaga, aby format danych, np. schematy JSON, obejmował pełen zakres wymaganych parametrów i był spójny dla wszystkich urządzeń, a interfejsy były otwarte i w pełni udokumentowane. Gotowy schemat nie został załączony do dokumentacji postępowania. Jego szczegółową postać definiuje Wykonawca cSIP w Projekcie Systemu i dokumentacji interfejsów, a następnie stosuje jako wspólny kontrakt integracyjny. Dostawcy Tablic będą mapować dane swoich urządzeń do tego schematu. Takie ujednolicenie ma zapewnić porównywalność centralnie liczonych wskaźników, w tym ghosting score, liczby odświeżeń i MTBF sterownika.

Zmawiający wyjaśnia, że obowiązuje definicja słownikowa z rozdziału 2 OPZ. „Ekran

Zamawiający wyjaśnia, że OPZ nie określa liczbowego, dobowego limitu pełnych odświeżeń Wyświetlacza. Wymaga natomiast rejestrowania liczby odświeżeń pełnych i częściowych oraz monitorowania „nadmiernej liczby pełnych odświeżeń/na dzień

Zamawiający wyjaśnia, że OPZ określa sposób działania rozwiązania w całym łańcuchu przetwarzania i przekazywania danych, ale nie narzuca fizycznego umiejscowienia silnika Text2Speech. cSIP ma zapewnić treść do odczytu, konfigurację funkcji oraz interfejs umożliwiającej jej obsługę. Wyświetlacz ma współpracować z dedykowanym przyciskiem fizycznym i odczytywać komunikat przekazany przez System. Ponieważ dostawa Tablic, ich wyposażenia i przycisków fizycznych nie jest przedmiotem tego postępowania, warstwa sprzętowa przycisku i lokalna obsługa urządzenia pozostają po stronie dostawcy Tablicy/systemu sterowania. Sam silnik TTS może zostać zrealizowany po stronie oprogramowania Tablicy albo jako usługa współpracująca z cSIP, o ile rozwiązanie spełnia wszystkie wymagania funkcjonalne, w tym brak ograniczeń licencyjnych dla wymaganej funkcji. Nie wprowadza się dodatkowego wymagania co do lokalizacji silnika.

Zmawiający wyjaśnia, że OPZ narzuca wykorzystanie MQTT/JSON i wymagania interoperacyjności, ale nie określa gotowej struktury topików MQTT ani kompletnego schematu komunikatu JSON. Szczegóły te definiuje Wykonawca cSIP w Projekcie Systemu oraz dokumentacji protokołów i API, z wykorzystaniem wymaganych standardów. Projekt techniczny, opis protokołów komunikacyjnych i dokumentacja integracji są produktami etapu projektowego. W konsekwencji struktura topików, schematy komunikatów, zasady wersjonowania i przykłady wiadomości powinny zostać uzgodnione z Zamawiającym przed rozpoczęciem właściwych integracji w Etapie 3. Nie jest to nowe wymaganie, lecz uszczegółowienie dokumentacji wymaganej w OPZ.

Zamawiający wyjaśnia, że zapisy te dotyczą różnych warstw i są ze sobą zgodne. Dla integracji Tablic obowiązuje model centralnej, wspólnej usługi zarządzającej treścią. cSIP poprzez dedykowany interfejs udostępnia konfigurację i aktualne dane, a Tablica okresowo sprawdza i pobiera dane zgodnie z parametrami określonymi w konfiguracji, w tym z częstotliwością odświeżania prognoz. Broker MQTT z pkt 5.1 służy do publikowania strumienia predykcji i może być wykorzystany w architekturze integracyjnej, ale nie znosi wymogu jednej wspólnej usługi zarządzającej ani centralnego sterowania konfiguracją Widoków. Dostawca Tablicy powinien integrować urządzenie z uzgodnionym interfejsem cSIP, a nie budować odrębne źródło treści.

Zamawiający wyjaśnia, że wymaganiem podstawowym dla dynamicznej informacji pasażerskiej pozostaje prezentowanie czasu pozostałego do odjazdu w minutach, zgodnie z OPZ. Bezwzględna godzina odjazdu nie jest wymagana w tym Widoku. Może zostać ona wykorzystana jako dodatkowy, konfigurowalny element Widoku wyłącznie wtedy, gdy zostanie przewidziana w konfiguracji zaakceptowanej przez Zamawiającego i nie zastąpi wymaganej wartości w minutach ani nie pogorszy czytelności prezentacji. Wykonawca nie powinien samodzielnie zmieniać standardowego zakresu Widoku dynamicznego.

Zamawiający wyjaśnia, że filtrowanie i włączanie/wyłączanie pól opcjonalnych powinno być realizowane centralnie w cSIP, zgodnie z konfiguracją Widoku i danej Tablicy. OPZ wskazuje przy tych polach możliwość ich opcjonalnego wyłączenia, a jednocześnie wymaga, aby układ Widoku i prezentowane informacje były sterowane centralnie - Tablica ma wiedzieć „co pokazać i jak

Zamawiający wyjaśnia, że OPZ nie określa jednej, z góry ustalonej częstotliwości wywołań ani odświeżania danych udostępnianych przez webAPI GTFS-RT/SIRI. Wymaga udostępniania aktualnych danych za pośrednictwem webAPI w trybie on-line. Dla danych predykcyjnych generowanych przez cSIP obowiązują częstotliwości aktualizacji opisane w pkt 5.1, w tym publikacja prognoz przez broker MQTT nie rzadziej niż raz na minutę; nie stanowi to jednak dodatkowej, osobnej częstotliwości wywołań webAPI.

Zamawiający wyjaśnia, że cSIP pozostaje punktem publikacji, a dane publikowane w GTFS-RT powinny być spójne z informacją dynamiczną wykorzystywaną przez System. Pkt 5.11.2 dopuszcza wykorzystanie danych z zewnętrznych systemów predykcji jako źródła wejściowego, ale nie oznacza dopuszczenia równoległego, niezależnego źródła informacji, który mógłby prezentować inne wartości niż cSIP. W przypadku integracji opisanej w pkt 7.1.1, gdzie informacja istniejącego systemu ma zostać zastąpiona przewidywanymi odjazdami pochodzącymi z cSIP, te same logicznie dane powinny zasilać prezentację na nośnikach oraz publikację GTFS-RT. Zewnętrzny system predykcji może być źródłem dla cSIP, jeżeli zostanie zintegrowany i znormalizowany, ale końcowa publikacja ma zachować jednolitość informacji.

Zamawiający wyjaśnia, że wzory ikon/piktogramów dostarcza Zamawiający. Wykonawca cSIP odpowiada natomiast za ich techniczne odwzorowanie w Systemie: utworzenie spójnego słownika identyfikatorów/znaczników, jego wersjonowanie w ramach interfejsu oraz utrzymanie powiązania identyfikatora z właściwym piktogramem. Zmiany merytoryczne w zestawie piktogramów i ich wzorach pozostają po stronie Zamawiającego, natomiast Wykonawca cSIP implementuje je w centralnym słowniku i dokumentacji interfejsu. Dostawcy Tablic korzystają z identyfikatorów zdefiniowanych w cSIP i nie powinni tworzyć własnych, niezgodnych słowników.