WYKONAWCY. Łódź, dnia r. ZDiT.DZ

Transkrypt

1 Łódź, dnia r. ZDiT.DZ WYKONAWCY Dotyczy: postępowania o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego na: Rozbudowa i modernizacja trasy tramwaju w relacji Wschód Zachód (Retkinia Olechów) wraz z systemem zasilania oraz systemem obszarowego sterowania ruchem odcinki 1,2,4,5,6,7,8 (Nr sprawy ZDiT.DZ ) Na podstawie art. 38 ust. 1, ustawy z dnia 29 stycznia 2004r. Prawo zamówień publicznych (Dz. U. z 2013r. poz. 907 z późn. zm.), dalej zwaną Ustawą Pzp do Zamawiającego zostały wniesione pytania Wykonawców, na które Zamawiający udziela odpowiedzi. ZESTAW 1 Pytanie: w związku w wątpliwościami dotyczącymi włączenia do systemu pojazdów transportu publicznego, prosilibyśmy o odpowiedź na następujące pytanie: W związku z koniecznością wyceny prac instalacyjnych w pojazdach transportu publicznego, prosimy o informacje, czy do systemu SZTP, w ramach wskazywanych 450 pojazdów, włączone zostaną autobusy MPK, będące w okresie gwarancji, w szczególności 45 autobusów marki Solaris U12, U18 (z dostaw 2011 rok) oraz 50 autobusów marki Mercedes Connecto i Connecto G (z dostaw 2013 roku). Zamawiający wyjaśnia, iż po stronie Wykonawcy nie ma obowiązku realizacji usługi gwarancji dla pojazdów MPK będących w okresie gwarancji. Po stronie Wykonawcy jest przeprowadzenie realizacji zgodnie z OPZ. Wykonawca nie ponosi odpowiedzialności za realizację usługi gwarancji tych pojazdów. Zamawiający wyjaśnia, iż w zależności od przyjętej technologii oferowanej przez Wykonawcę do realizacji i niezbędnej do zainstalowania jej w autobusach MPK, w celu realizacji określonych funkcjonalności ZSZR, po stronie Wykonawcy jest wymóg przeprowadzenia wdrożenia w autobusach z zachowaniem zasad sztuki inżynieryjnej i instalacyjnej w tym bezpieczeństwa i higieny prac, nie powodując przy tym uszkodzenia samych autobusów. Po stronie Wykonawcy jest udzielenie gwarancji na wdrożone w autobusach rozwiązania. 1

2 Zamawiający wyjaśnia, iż wszelkie prace związane z opracowaniem dokumentacji projektowej związanej z powyższym zakresem technologicznym oraz przeprowadzenie wdrożenia są po stronie Wykonawcy i będą zatwierdzane i koordynowane przy udziale Zamawiającego oraz przy uzgodnieniu tych prac z MPK. ZESTAW 2 Pytanie 1: Tom VI punkt Zarzadzanie infrastruktura drogową, ppkt.8 ma brzmienie System musi umożliwiać bieżącą aktualizację zdarzeń drogowych w trybie transakcyjnym, w których transakcja jest procedurą, zarządzaną przez standardowe mechanizmy bazy danych. Zmiany wprowadzone w ramach długiej transakcji nie będą widoczne dla innych użytkowników do czasu zatwierdzenia zmian. Powyższy punkt przy dosłownej interpretacji niesie za sobą konsekwencje znacznego obniżenia wydajności systemu lub braku możliwości implementacji wymagania. Analizując zapisy w trybie transakcyjnym, w których transakcja jest procedurą, zarządzaną przez standardowe mechanizmy bazy musimy przyjąć, iż chodzi o transakcyjne mechanizmy bazodanowe wspierane przez większość dostępnych na rynku systemów DB takich jak Oracle, SQL Server,DB2 itp. Rozpoczęcie transakcji bazodanowej blokuje dane, dla kolejnego użytkownika, co w konsekwencji uniemożliwia odczytanie zablokowanych rekordów. Tym samym możemy dojść do sytuacji w której system zawiesza działanie, w momencie rozpoczęcia transakcji przez operatora. System ma być wykonany jako serwis WWW, a w tej architekturze stosuje się podejście pól połączeniowych (stałej liczby połączeń dla wszystkich użytkowników). Połączenia bazodanowe, nie są związane z konkretnym użytkownikiem i nie ma możliwości sterowania długotrwającymi transakcjami. W systemie WWW brakuje stałego połączenia pomiędzy przeglądarką a serwerem aplikacji, w dodatku wzbudzanie komunikacji jest jednostronne (od strony przeglądarki). Brakuje tutaj koniecznego dla transakcji bazodanowych stałości połączenia pomiędzy klientem a serwerem. Transakcje bazodanowe wykorzystywane są dla zapewnienia integralności zapisu danych, dla długich transakcji stosuje się rozwiązania oparte na wzorcach projektowych nie związanych z konkretnym rozwiązaniem bazodanowym. Proponujemy aby zmodyfikować zapis na taki który nie wskazuje na standardowe mechanizmy bazodanowe. Tzn. transakcyjność oczywiście musi być zachowana, ale opierająca się na rozwiązaniu innym niż transakcyjność bazy danych. Zamawiający dopuszcza rozwiązanie określone przez Wykonawcę, przy zachowaniu maksymalnej optymalizacji wprowadzania i odczytu danych w celu spełnienia wymaganych funkcjonalności oraz wyjaśnia, iż należy uwzględnić standardowe mechanizmy bazodanowe w realizacji. 2

3 Pytanie 2: Tom VI, punkt 2.1. Zakres zadania posiada m.in. wymaganie: Warstwa ta ma zostać opracowana z myślą o integracji podsystemów dla pozyskiwania danych pochodzących z różnych źródeł, realizacji analiz strategicznych, redystrybucji danych między rozwiązaniami Podsystem ów, posiadać specjalistyczne algorytmu ukierunkowane bezpośrednio na zarzadzanie ruchem w mieście, jak np. algorytmy wektorowe, układy logiczne, wyboru trybów czasu, rozwiązania oparte na sprawdzonych modelach matematycznych i procedury umożliwiające monitorowanie i wpływanie na pracę Powyższy fragment jest sformułowany na zbyt ogólnym poziomie i uniemożliwia oszacowanie kosztów rozwiązania. Punkt jest fragmentem opisu systemu nadrzędnego jednak wydaje się iż dotyczy algorytmiki sterowania ruchem i tym samym jego miejsce jest w podsystemie sterownia ruchem. Niestety z przedstawionego opisu nie można zrozumieć jakich funkcji dotyczy, oraz jak ma być wykorzystywany. Proponujemy aby usunąć ten zapis z SIWZ. Zamawiający wyjaśnia, iż przedmiotowy wymóg nie dotyczy systemu GIS. Po stronie Wykonawcy jest zaprojektowanie rozwiązań i ich wdrożenie w zakresie zapewniającym współdziałanie podsystemów zgodnie z określonymi funkcjonalnościami. Zamawiający nie ogranicza możliwości zaoferowania profesjonalnych rozwiązań przez Wykonawcę. I. Infrastruktura ZESTAW 3 Na podstawie odpowiedzi udzielonych przez Państwa w piśmie ZDiT.DZ z dnia r. dotyczącego postępowania o udzielenie zamówienia publicznego "ROZBUDOWA I MODERNIZACJA TRASY TRAMWAJU W RELACJI WSCHÓD - ZACHÓD (RETKINIA - OLECHÓW) WRAZ Z SYSTEMEM ZASILANIA ORAZ SYSTEMU OBSZAROWEGO STEROWANIA RUCHEM" część "Program funkcjonalno użytkowy załącznik OSSR" i w efekcie odstąpienie od części wymagań opisanych w w/w załączniku prosimy o ustosunkowanie się do poniższych zarzutów. Zamawiający precyzyjnie definiuje wymagania dotyczące sprzętu serwerowego, co w efekcie wg najlepszej wiedzy Wykonawcy, ogranicza konkurencję dopuszczając rozwiązanie sprzętowe tylko jednego producenta spełniające łącznie wszystkie wymagania stawiane przez Zamawiającego, co jest niezgodne z zasadą zachowania uczciwej konkurencji oraz równego traktowania wykonawców określoną w art. 7 ust. 1 ustawy Prawo zamówień publicznych. Zamawiający precyzyjnie definiuje rodzaje sprzętu serwerowego i stacji roboczych, równocześnie oczekując dostarczenia już gotowego rozwiązania Systemu Obszarowego Zarządzania Ruchem, które nie muszą być wykorzystywane w oferowanym kompletnym Systemie. Pozostaje to w jawnej sprzeczności z odpowiedziami udzielonymi przez Państwa w piśmie nr ZDiT.DZ z dn r. 3

4 Dotyczy: Program funkcjonalno użytkowy załącznik OSSR pkt Zamawiający precyzyjnie definiuje wymagania dotyczące obudowy blade, co w efekcie wg najlepszej wiedzy Wykonawcy ogranicza możliwość dostarczenia rozwiązania sprzętowego tylko do jednego producenta, spełniającego łącznie wszystkie wymagania stawiane przez Zamawiającego, co jest niezgodne z zasadą zachowania uczciwej konkurencji oraz równego traktowania wykonawców określoną w art. 7 ust. 1 ustawy Prawo zamówień publicznych. Wobec powyższego wnosimy o modyfikację lub rezygnację z wymagań, opisanych w poniższych pytaniach: Pytanie 1: Czy Zamawiający dopuści obudowę o wysokości 10U i głębokości 32" oraz tym samym umieszczenia do 6 obudów w szafie rack? Jeśli nie, to prosimy o podanie argumentacji dla ograniczenia wymiarów obudowy blade do podanych przez Państwa, jeśli Wykonawca nie przewiduje dostarczenia takiej ilości obudów do realizacji Systemu. Zamawiający udzielił odpowiedzi w dniu r. (zestaw 7 pytanie 3). Pytanie 2: Czy Zamawiający zrezygnuje z wymagania możliwości umieszczenia serwerów z procesorami RISC w obudowie blade, jeśli wykonawca nie będzie dostarczał takiego rodzaju serwerów? Jeśli nie, to prosimy o podanie jakie serwery z procesorami RISC Zamawiający będzie umieszczał w dostarczanej obudowie blade oraz opisanie ich funkcji w celu poprawnego opisania w Dokumentacji. Zamawiający udzielił odpowiedzi w dniu r. (zestaw 7 pytanie 5). Pytanie 3: Czy Zamawiający zgodzi się na rezygnację z napędu DVD-ROM umieszczonego na przednim panelu jeśli dostarczone rozwiązanie umożliwia użycie wirtualnego napędy DVD-ROM dostępnego ze stacji administratora? Jeśli nie, to prosimy o potwierdzenie, że Zamawiający wymaga prowadzenia prac przy serwerach jedynie z pomieszczenia serwerowni z pominięciem zdalnego dostępu administracyjnego (który to jest wymagany poprzez dostarczenie modułu zdalnej administracji). Zamawiający udzielił odpowiedzi w dniu r. (zestaw 7 pytanie 2). Pytanie 4: Czy Zamawiający dopuści serwery z mniejszą ilością gniazd DIMM, jeśli ta ilość umożliwi rozszerzenie pamięci do wymaganych 192GB? Jeśli nie, prosimy o uzasadnienie wymagania dokładnie takiej ilości gniazd DIMM. 4

5 Wymaganie 8 wolnych gniazd nie jest wymaganiem ograniczającym konkurencję- każdy z czołowych producentów oferuje serwery średniej klasy wyposażone w 12 do 24 gniazd pamięci. Pytanie 5: Czy Zamawiający zrezygnuje z wymagania zainstalowania minimum dwóch dysków w serwerze, jeśli serwer będzie uruchamiany z dysków logicznych udostępnianych z macierzy poprzez sieć SAN? Nie, dyski są wymagane. Pytanie 6: Czy Zamawiający zrezygnuje z wymagania dostarczenia serwerów kasetowych z wbudowanymi hot-swapowymi redundantnymi zasilaczami oraz wentylatorami, jeśli sama obudowa kasetowa zapewnia realizację obu tych funkcji? Nie, Zamawiający podtrzymuje ww. wymaganie. Pytanie 7: Czy Zamawiający zrezygnuje z wymagania złącza USB zintegrowanego z płytą główną serwerów? Jeśli nie, prosimy o podanie funkcjonalności, która ma być zrealizowana w oparciu o to złącze. Zapisy PFU w tym zakresie nie są obowiązujące. Dokumentem nadrzędnym jest opracowanie VIII.5.5, w którym nie ma takiego wymagania Nie było stawiane wymaganie integracji złącza USB z płytą główną. Wymaga się, żeby serwer posiadał przynajmniej jedno złącze USB- wymaganie to jest podtrzymane. Pytanie 8: Czy Zamawiający zrezygnuje z dostarczenia oprogramowania zarządzającego obsługującego również obecnie posiadane przez Zamawiającego serwery i stacje robocze nie będące przedmiotem zamówienia? Jeśli nie, to prosimy o podanie dokładnej listy zawierającej ilości i modele sprzętu, jakie powinny być obsługiwane przez w/w oprogramowanie. Zapisy PFU w tym zakresie nie są obowiązujące. Dokumentem nadrzędnym jest opracowanie VIII.5.5, w którym nie ma takiego wymagania. Dotyczy: Program funkcjonalno użytkowy załącznik OSSR pkt

6 Pytanie 9: Czy można traktować systemy klasy Unix jako równoważne systemowi Linux w wersjach komercyjnych? Zapisy PFU w tym zakresie nie są obowiązujące. Dokumentem nadrzędnym jest opracowanie VIII.5.5, w którym nie wymienia się przykładowych nazw produktów. Pytanie 10: Czy dostarczenie oprogramowania umożliwiającego bezpieczny dostęp jest obligatoryjne, jeśli zaproponowane rozwiązanie będzie wykorzystywać wydzielone sieci prywatne lub połączenia VPN? Należy dostarczyć takie rozwiązanie (sprzętowe lub programowe i sprzętowe) aby zapewnić bezpieczeństwo sieci, pamiętając o puntach styku z sieciami zewnętrznymi, którymi są np. stanowiska wyniesione. Dotyczy: Program funkcjonalno użytkowy załącznik OSSR pkt. 2.3 i 2.4 Pytanie 11: Czy Zamawiający wymaga dostarczenia Stacji roboczych Rack oraz urządzeń RAD jeśli dostarczane rozwiązanie informatyczne nie zostało zaprojektowane i nie wykorzystuje tego typu rozwiązań? Czy należy dostosować dostarczane oprogramowanie do pracy w tego typu środowisku? Tak. Należy pamiętać, że na stacjach roboczych może być również uruchamiane oprogramowanie typu CAD czy narzędzia do projektowania lub symulacji. II. Sieć Dotyczy: Dokumentacja projektowa Koncepcja sieci transmisji danych dla obszarowego systemu sterowania ruchem w Łodzi TOM VIII.5.3 SIEĆ TELEINFORMATYCZNA Pytanie 12: Analizując wymagania dotyczące sprzętu aktywnego sieci komputerowej można zauważyć, że Zamawiający wymaga funkcjonalności urządzeń, które nie będą wykorzystywane, a które znacznie ograniczają możliwość doboru urządzeń spośród dostępnych na rynku. W związku z powyższym zwracamy się z prośbą o usunięcie następujących wymagań na urządzenia aktywne typu I oraz II: Intermediate System-to-Intermediate System (IS-IS) Border Gateway Protocol (BGP) v4 oraz wszystkich innych zapisów odnoszących się do wymagań protokołów BGP oraz IS-IS w dostarczanych urządzeniach aktywnych typ I oraz II. 6

7 Zamawiający wyjaśnia, iż określił wymagania dla realizacji kompleksowego systemu transmisji danych dla OSZR w tym Systemu Sterowania, wprowadził do OPZ wraz z załącznikami opisy, koncepcje w tym topologie sieci. Po stronie Wykonawcy jest opracowanie kompleksowych rozwiązań w zakresie projektowym oraz wdrożenie systemu transmisji dla całego OSZR przy zastosowaniu takich urządzeń, które zapewnią istotne dla elementów systemu ITS: bezpieczeństwo, jakość, stabilność i efektywność transmisji danych. Zamawiający kierując się zasadą zachowania uczciwej konkurencji, dopuszcza zatem urządzenia, które będą wspierały co najmniej dwa protokoły routingu z rodziny IGP lub rozwiązania zapewniające takie wymagania. Prośbę swoją motywujemy poniższymi faktami: Protokół routingu BGP stosowany jest głównie w sieciach posiadających więcej niż jeden styk z siecią Internet. Z dokumentów dostarczonych przez Zamawiającego wynika, że urządzenia podłączone do wymaganych urządzeń aktywnych nie będą podłączone w żaden sposób do sieci Internet. Zamawiający nie może wykluczyć sytuacji, że zostaną zaprojektowane oraz zaoferowane implementacje w ramach OSZR, w ramach których nastąpią wymagane podłączenia z siecią Internet, w związku z tym Zamawiający wymaga, takiego rozwiązania aby urządzenia były przygotowane do tego typu podłączenia. IS-IS jest protokołem routingu stosowanym raczej w sieciach operatorskich, sieć ITS taką nie jest. Protokoły: OSPF oraz IS-IS są protokołami IGP i służą do propagacji prefiksów wewnętrznych w obrębie domeny autonomicznej użytkownika. Zamawiający, zgonie z zasadą zachowania uczciwej konkurencji, dopuszcza urządzenia, które będą propagowały prefiksy za pomocą protokołu IGP innego niż OSPF. Zamawiający w dokumencie Koncepcja Sieci Transmisji Danych OSSR specyfikując wymagania dotyczące urządzeń aktywnych typ I oraz typ II opisuje również sposób w jaki ma odbywać się komunikacja w sieci ITS, w pkt. 2.6 Protokoły dynamicznego routingu w sieci: W sieci zakłada się, że uruchomiony będzie protokół OSPF, który zapewni poprawną propagację prefiksów z sieci dostępowych oraz sieci Centrum Zarządzania Siecią pomiędzy wszystkimi urządzeniami aktywnymi oraz w pkt. 4 Zakończenie: Uruchomienie protokołu dynamicznego routingu OSPF zarówno w części szkieletowej jak i dostępowej umożliwia poprawną propagację prefiksów IP w całej sieci 7

8 Jednocześnie w żadnym innym miejscu Zamawiający nie wspomina o potrzebie zastosowania protokołów IS-IS lub BGP. Nasuwa się więc wniosek, że Zamawiający wymaga funkcjonalności, której nie będzie wykorzystywał, a została wpisana do dokumentacji jedynie w celu ograniczenia konkurencji. W OPZ opisana jest koncepcja sieci, dla pokazania wymagań, jakie w rozumieniu Zamawiającego projektowana sieć ma spełniać. Tym samym Zamawiający kierując się zasadą zachowania uczciwej konkurencji, nie wyklucza zastosowania innego protokołu routingu IGP niż OSPF. Ponad to prosimy o usunięcie wymagań na dostarczane urządzenia aktywne typ I oraz II opisanych w punkcie 2.1 Urządzenia aktywne: Łatwy do użycia, bezpieczny interfejs zarządzania urządzeniem, bazujący na technologii WEB Wymaganie to jest nadmiarowe ponieważ urządzenia będą posiadały bezpieczny interfejs do zarządzania za pomocą protokołu SSH, natomiast zarządzanie oparte o interfejs graficzny będzie realizowane za pomocą systemu zarządzania. Wymaganie to dotyczy urządzeń, dla których system zarządzania nie będzie udostępniał łatwego do użycia oraz bezpiecznego interfejsu zarządzania urządzeniem. Zamawiający dopuszcza tym samym urządzenia z wbudowanym interfejsem do zarządzania bazującym na technologii WEB dla uniknięcia ograniczania konkurencji. Wsparcie protokołu GVRP. Koncepcja systemu zakłada iż sieć będzie oparta o routing,w związku z tym dystrybucja informacji o VLAN-ach w sieci, za którą odpowiedzialny jest protokół GVRP jest niepotrzebna. Zamawiający wycofuje się z wymogu wspierania przez urządzenia protokołu GVRP. Wsparcie protokołu RIP. W koncepcji wykorzystany zostanie protokół OSFP co powoduje, iż protokół RIP jest nie potrzebny. Protokół RIP jest protokołem IGP i służy do propagacji prefiksów wewnętrznych w obrębie domeny autonomicznej użytkownika. Zamawiający, zgonie z zasadą zachowania uczciwej konkurencji, dopuszcza zatem urządzenia, które będą propagowały prefiksy za pomocą co najmniej dwóch protokołów IGP. 8

9 W/w wyjaśnienia Zamawiający zamieszcza ponadto na stronie internetowej p.o. Z-CY DYREKTORA ds. Transportu i Inżynierii ZARZĄDU DRÓG I TRANSPORTU Grzegorz Misiorny Sprawę prowadzi: Ewa Fiktus Inspektor w Wydziale Zamówień Publicznych tel. 42/