Wyrok KIO 2401/12

Sygn. akt: KIO 2401/12 WYROK z dnia 19 listopada 2012 r. Krajowa Izba Odwoławcza - w składzie: Przewodniczący: Andrzej Niwicki Członkowie: Anna Packo Małgorzata Rakowska Protokolant: Agata Dziuban po rozpoznaniu na rozprawie w dniu 15 listopada 2012 r. w Warszawie odwołania wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 2 listopada 2012 r. przez wykonawcę Badawczo-Rozwojowa Spółdzielnia Pracy Mikroprocesorowych Systemów Automatyki "MIKRONIKA", 60 – 001 Poznań, ul. Wykopy 2/4 w postępowaniu prowadzonym przez System Gazociągów Tranzytowych EuRoPol GAZ S.A., 00 – 342 Warszawa, ul. Topiel 12 przy udziale wykonawców wspólnie ubiegających się o udzielenie zamówienia Konsorcjum: PSI Produkty i Systemy Informatyczne Sp. z o.o., PSI Aktiengesellschaft für Produkte und Systeme der Informationstechnologie, 61 – 896 Poznań, ul. Towarowa 35zgłaszającego swoje przystąpienie do postępowania odwoławczego po stronie zamawiającego. orzeka: 1. oddala odwołanie. 2. kosztami postępowania obciąża wykonawcę - Badawczo-Rozwojowa Spółdzielnia Pracy Mikroprocesorowych Systemów Automatyki "MIKRONIKA" w Poznaniu i: 2.1. zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych, zero groszy) uiszczoną przez wykonawcę Badawczo-Rozwojowa Spółdzielnia Pracy Mikroprocesorowych Systemów Automatyki "MIKRONIKA" w Poznaniu tytułem wpisu od odwołania, 2.2 zasądza od Badawczo-Rozwojowej Spółdzielni Pracy Mikroprocesorowych Systemów Automatyki "MIKRONIKA" w Poznaniu na rzecz Systemu Gazociągów Tranzytowych EuRoPol GAZ S.A. w Warszawie kwotę 3.600 zł (trzy tysiące sześćset) tytułem wynagrodzenia pełnomocnika strony. Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. - Prawo zamówień publicznych ( Dz. U. z 2010 r. 113, poz. 759 ze zm.) na niniejszy wyrok - w terminie 7 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie. Przewodniczący: ……………………. .…………………… ……………………. Sygn. akt: KIO 2401/12 Uzasadnienie System Gazociągów Tranzytowych EuRoPol GAZ S.A. z siedzibą w Warszawie (dalej: zamawiający) prowadzi w trybie negocjacji z ogłoszeniem postępowanie w sprawie sektorowego zamówienia publicznego na „Modernizację systemu SCADA SGT”. Ogłoszenie o postępowaniu zostało opublikowane 5 czerwca 2012 r., a pismami z dnia 31 maja 2012 r. na podstawie art. 40 ust. 5a ustawy Prawo zamówień publicznych (dalej: PZP lub ustawa pzp) poinformowano o wszczęciu postępowania 3 wykonawców tj. ABB Sp. z o.o. w Warszawie, CEGELEC Sp. z o.o. w Warszawie i PSI Sp. z o.o. w Poznaniu. Wnioski o dopuszczenie do udziału w postępowaniu złożyło 5 wykonawców: Konsorcjum: ABB Sp. z o.o. w Warszawie i ABB Inc. w Calgary (Konsorcjum ABB), Konsorcjum: EGELEC Sp. z o.o. w Warszawie i CEGELEC Deutschland GmbH we Frankfurcie nad Menem (Konsorcjum CEGELEC), Konsorcjum: PSI Produkty i Systemy Informatyczne Sp. z o.o. w Poznaniu i PSI AKtiengesellschaft fur Produkte und Systeme der Informationstechnologie w Berlinie (Konsorcjum PSI), Konsorcjum: CONTROL PROCESS S.A. w Krakowie, STALBUD Tarnów Sp. z o.o. w Bogumiłowicach i CONTROL PROCESS IT Sp. z o.o. w Bogumiłowicach (Konsorcjum CONTROLL PROCESS) oraz Badawczo-Rozwojowa Spółdzielnia Pracy Mikroprocesorowych Systemów Automatyki „MIKRONIKA” w Poznaniu. Dnia 20 lipca 2012 r. Zamawiający poinformował o pozytywnej oceny spełniania przez Konsorcjum PSI oraz Badawczo-Rozwojową Spółdzielnię Pracy Mikroprocesorowych Systemów Automatyki „MIKRONIKA” w Poznaniu warunków udziału w postępowaniu. Pozostali wykonawcy zostali wykluczeni z postępowania. Wskazani wyżej wykonawcy zaproszeni zostali do złożenia ofert wstępnych, a 14 sierpnia 2012 r. Zamawiający przekazał obu wykonawcom wstępną specyfikację istotnych warunków zamówienia (dalej: SIWZ lub siwz). Do 3 września 2012 r. wykonawcy złożyli oferty wstępne. Pismem z dnia 21.09.2012 r. Zamawiający zwrócił się do Badawczo-Rozwojowej Spółdzielni Pracy Mikroprocesorowych Systemów Automatyki „MIKRONIKA” w Poznaniu o udzielenie pisemnych wyjaśnień dotyczących wybranych punktów oferty wstępnej. Dnia 27.09.2012 r. wykonawca złożył wyjaśnienia. Zamawiający nie zwracał się o udzielenie wyjaśnień do drugiego wykonawcy. 22 października 2012 r. Zamawiający powiadomił o odrzuceniu oferty wstępnej Badawczo-Rozwojowej Spółdzielni Pracy Mikroprocesorowych Systemów Automatyki „MIKRONIKA” w Poznaniu z powodu „niezgodności treści oferty z treścią specyfikacji istotnych warunków zamówienia.” Tego samego dnia zaproszono Konsorcjum PSI - do negocjacji. Odrzucając ofertę wstępną Zamawiający powołał pkt 9.5. SIWZ, zgodnie z którym „W ofercie wstępnej Wykonawca powinien ustosunkować się do postanowień części I (ogólnej) umowy oraz zakresu i warunków wykonania robót określonych w części II (specyfikacja dostaw i usług) umowy, które będą przedmiotem negocjacji. Informacje dotyczące części II powinny być przedstawione w formie tabelarycznej z podaniem w kolejnych wierszach, co najmniej: poszczególnych punktów wymagań, potwierdzenie spełnienia danego punktu (TAK/NIE), krótki opis sposobu realizacji danego wymagania, ewentualne uwagi.” Zamawiający podał, że „przy analizie oceny spełnienia wymagań przez Wykonawcę brano pod uwagę treść oferty zamieszczoną w tabeli. W przypadku wątpliwości lub braku informacji w tym zakresie uwzględniano również opis realizacji wymagania umieszczony w innych materiałach dostarczonych przez Wykonawcę.” W wyniku przeprowadzonej analizy Zamawiający stwierdził, iż oferta wstępna Zamawiającego nie jest zgodna z treścią SIWZ w 62 punktach przy czym wszystkie zastrzeżenia dotyczyły „opisu sposobu realizacji wymagań.” Wykonawca, którego oferta została odrzucona (dalej: odwołujący) zakwestionował czynności odrzucenia w dniu 22 października 2012 r. złożonej przez niego oferty wstępnej w odwołaniu złożonym do Prezesa Krajowej Izby Odwoławczej dnia 2 listopada 2012 roku. Odwołujący zarzucił zamawiającemu naruszenie: 1) art. 89 ust. 1 pkt 2 PZP w zw. z art. 57 ust. 2 PZP polegające na odrzuceniu oferty wstępnej Odwołującego jako niezgodnej z treścią SIWZ, 2) 87 ust. 1 PZP poprzez wybiórcze wezwanie do złożenia wyjaśnień przy zaniechaniu wezwania, mimo tożsamości zastrzeżeń, do złożenia wyjaśnień w zakresie pozostałych wymagań, skutkujące odrzuceniem oferty Odwołującego; 3) art. 7 ust. 1 PZP polegające na: - tym, że sposób realizacji wymagań, którego niewystarczający w ocenie Zamawiającego opis stanowił przyczynę odrzucenia oferty wstępnej Odwołującego, będzie przedmiotem negocjacji z zaproszonym wykonawcą, - niedozwolonej interpretacji treści SIWZ na etapie oceny ofert wstępnych, w oparciu o dokonanie oceny oferty wstępnej w sposób dowolny, nie mających podstaw w SIWZ, na podstawie nie określonych w SIWZ wymagań w zakresie sposobu realizacji poszczególnych cząstkowych części zamówienia, które to części będą przedmiotem negocjacji, a sposób realizacji zostanie ostatecznie określony dopiero na etapie realizacji umowy na podstawie analiz i projektów, tj. czynności wykonywanych w uzgodnieniu z zamawiającym i wchodzących w skład przedmiotu zamówienia, - odmiennej ocenie oferty Odwołującego od oceny zaproszonego do negocjacji wykonawcy pomimo, że została ona sporządzona w analogiczny sposób i zawierała podobny zakres informacji zawarty w krótkich opisach realizacji poszczególnego wymagania i pozostałych elementach oferty wstępnej. Odwołujący wniósł o nakazanie Zamawiającemu unieważnienia czynności odrzucenia oferty wstępnej i powtórzenia czynności oceny ofert wstępnych, z uwzględnieniem złożonej przez niego oferty wstępnej, w celu zakwalifikowania do kolejnego etapu postępowania - zaproszenia do negocjacji, z ewentualnym poprzedzeniem tej czynności wezwaniem do złożenia wyjaśnień. Uzasadniając zarzuty i żądania odwołujący wskazał, co następuje. Odwołujący wskazał na specyfikę niniejszego postępowanie prowadzonego w trybie negocjacji z ogłoszeniem. Odwołujący przypomina, że w tym trybie negocjacji wyróżnione zostały 4 etapy: Pierwszy - kwalifikacja podmiotów, prowadzony na podstawie ogłoszenia o zamówieniu, Drugi - ocena ofert wstępnych złożonych na zaproszenie zamawiającego przez zakwalifikowanych wykonawców; Trzeci, w którym zamawiający negocjuje z wykonawcami (którzy złożyli oferty niepodlegające odrzuceniu) w zakresie opisu przedmiotu zamówienia oraz warunków umowy, przy czym na podstawie negocjacji zamawiający może zmienić zapisy SIWZ w zakresie doprecyzowania i uszczegółowienia przedmiotu zamówienia oraz Czwarty etap - wybór najkorzystniejszej oferty. Wobec powyższego, interpretacja SIWZ wydanej wraz z zaproszeniem do składania ofert wstępnych, musi uwzględniać jej charakter oraz cel, jakiemu ona służy na konkretnym etapie postępowania prowadzonego w trybie negocjacji z ogłoszeniem. Na tym etapie SIWZ nie precyzuje przedmiotu zamówienia, a jedynie dokonuje identyfikacji w podstawowym zakresie. Zamawiający podał w pkt 9.5. SIWZ , że wymagania z części I i II umowy będą stanowiły przedmiot negocjacji. śądał od Wykonawców na etapie ofert wstępnych jedynie ustosunkowania się (w formie tabelarycznej) do przedstawionych wymagań, dopuszczając również niespełnianie poszczególnych wymagań („potwierdzenie spełnienia danego punktu: TAK/NIE”). Zamawiający nie wskazał jednocześnie, iż na etapie wstępnej oferty spełnienie jakiegokolwiek wymagania było obligatoryjne, skutkiem czego jego niespełnienie spowoduje odrzucenie oferty wstępnej. Wymóg taki przewidziany został dopiero na etapie oferty ostatecznej, co potwierdza treść pkt. 9.6. SIWZ (zgodnie z którym „Oferta ostateczna powinna zawierać w szczególności oświadczenie Wykonawcy, że zobowiązuje się do wykonania przedmiotu zamówienia określonego w SIWZ zgodnie z treścią niniejszej SIWZ i na warunkach określonych we Wzorze Umowy stanowiącym Załącznik nr 1 do siwz, pod rygorem odrzucenia oferty.”). Odwołujący potwierdził w złożonej ofercie wstępnej (w szczególności poprzez wpisanie słowa „TAK” dla każdej poszczególnej pozycji wymagań), iż spełni wszystkie wymagania wynikające z SIWZ. Zamawiający nie określił w SIWZ żadnych wymogów w zakresie przygotowania „krótkiego opisu sposobu realizacji danego wymagania”, w szczególności nie zawarł w SIWZ instrukcji przygotowania opisu, nie podał stopnia szczegółowości tego opisu ani rodzaju zawartych tam informacji bądź ich zakresu. Nie wymagał również dołączenia dokumentacji potwierdzającej spełnienie wszystkich wymagań. Wobec braku instrukcji lub wskazówek dotyczących przygotowania krótkiego opisu, Odwołujący sporządził go zatem w taki sposób, jaki uznał za właściwy. Wskazał na postanowienia SIWZ: „Wykonawca, w terminie 6 tygodni od dnia zawarcia Umowy, przygotuje i uzgodni z Zamawiającym, dokument: ’’Analiza Wymagań Zamawiającego", w którym opisane zostaną założenia dotyczące wymaganej funkcjonalności systemu, realizowanych w nim usług oraz powiązań systemu z systemami zewnętrznymi, urządzeniami. „Analiza Wymagań Zamawiającego” musi zawierać co najmniej: 12.2.1. Analizę wymagań funkcjonalnych systemu. 12.2.2. Analizę wymagań sprzętowych. 12.2.3. Opis szczegółowego podziału funkcjonalności (procesów) w odniesieniu do poszczególnych urządzeń (serwerów). 12.2.4. Analizę powiązania oferowanego systemu SCADA, z istniejącymi i wykorzystywanymi systemami Zamawiającego (lokalne sieci komputerowe LAN, sieci rozległe WAN, układy automatyki tłoczni, układy automatyki pomiarowni głównych i potrzeb własnych, układy sterowania obiektami liniowymi ZZU, OZZU, ZP i ZPT), 12.2.5. Analizę założeń/wytycznych Zamawiającego w celu opracowania polityki bezpieczeństwa dla całego Systemu oraz jego poszczególnych elementów. transmisyjnymi i sieciowymi wykorzystywanymi w SGT Zamawiającego. Na podstawie SIWZ i uwzględnieniu uwag Zamawiającego do dokumentu „Analiza Wymagań Zamawiającego” Wykonawca, w terminie 10 tygodni od dnia zawarcia Umowy, wykona Projekt.” „Punkt 16.3 Zamawiający przewiduje ponadto możliwość dokonania zmian postanowień zawartej umowy: 16.3.3 w zakresie zmiany producenta/typu/modelu/numeru katalogowego części/materiału/sprzętu/ oprogramowania, jeżeli nie spowoduje to zmiany przedmiotu umowy lub pogorszenia funkcjonalności pierwotnie oferowanego rozwiązania, na części/materiały/sprzęt/oprogramowanie ekwiwalentne z uwagi na zmianę producenta/symbolu danej części/materiału/sprzętu/oprogramowanla, wycofanie z produkcji danej części/materiału/sprzętu/oprogramowania / zastąpienie ich nowszym substytutem lub inną częścią/ materiałem/sprzętem/oprogramowaniem o funkcjonalności nie gorszej niż pierwotnie planowano;” Odwołujący wskazał na treść odpowiedzi na pytania wykonawców. Zamawiający dla uzasadnienia swoich zarzutów przedstawił listę z wykazem swoich zastrzeżeń dla każdej z kwestionowanych pozycji tabeli „Ustosunkowanie się do zakresu i warunków wykonania robót określonych w części II (specyfikacja dostaw i usług)” znajdującej się w ofercie Odwołującego, opisując niezgodność oferty z SIWZ w poszczególnych punktach z podaniem następującego uzasadnienia dla poszczególnych pozycji: 1. Brak opisu realizacji wymagania; 2. Opis wynikający z oferty wstępnej na Modernizację Systemu SCADA SGT nie wyjaśnia sposobu opracowania polityki bezpieczeństwa i związanych z nią wymagań Zamawiającego; 3. Opis wynikający z oferty wstępnej na Modernizację Systemu SCADA SGT nie wyjaśnia sposobu implementacji wymagania; 4. Wymaganie nie zostało opisane w dokumentacji systemu, a Wykonawca nie opisał w tabeli sposobu osiągnięcia rezultatu zgodnego z wymaganiem Zamawiającego; 5. Brak funkcji log In; 6. Wynika ze Skryptu Operatora, system Syndis RV, dokumentacja szkoleniowa i pisma nr MI/DM/AN/1977/2012 z dnia 27.09.2012, brak precyzyjnego opisu, nie wszystkie warunki spełnione; 7. Z opisu w tabeli wynika deklaracja przygotowania API w przyszłości, obecnie wymagane API nie istnieje; 8. Brak informacji w dokumentacji systemu oraz opisu sposobu realizacji wymagania; 9. Aplikacja w kształcie wymaganym przez Zamawiającego nie istnieje, Oferent deklaruje gotowość opracowania i zaimplementowania takiej aplikacji. Deklaracja Oferenta o posiadaniu funkcjonalności rozproszonych po różnych modułach nie jest możliwa do weryfikacji z uwagi na fakt niedostarczenia dokumentacji części modułów, jak SYNDIS OMS i SYNDIS ENERGIA. Ponadto nie przedstawiono w ofercie jakie funkcjonalności wymagane przez Zamawiającego, w jakim miejscu zostały opisane. Część funkcjonalności funkcjonuje wg deklaracji Oferenta w wersji WEB, nieakceptowanej przez Zamawiającego. Oferent nie uwiarygodnił poprzez przedstawienie studium wykonalności realizacji wymagań w postaci oczekiwanej przez Zamawiającego; 10. Oferent nie przedstawił sposobu realizacji wymagań w tym zakresie. Dostarczona dokumentacja systemu nie odnosi się w żaden sposób do oprogramowania SIMONE, w tym nie opisuje sposobu integracji systemu SYNDIS z tym oprogramowaniem; 11. Oferent nie przedstawił sposobu realizacji wymagań w zakresie funkcjonalnym. Dostarczona dokumentacja nie opisuje oprogramowania w zakresie funkcjonalności „Rozliczanie kontraktów”; 12. Brak listy autoryzowanych punktów serwisowych; 13. Brak propozycji urządzeń spełniających min. wymagania SIWZ; 14. Brak opisu propozycji/sposobu realizacji wymagań SIWZ; 15. Oferent nie uzasadnił z czego wynika możliwość spełnienia wymagań dotyczących przetwarzania, tym samym nie opisał sposobu realizacji wymagania. Dokumentacja systemu nie odnosi się do tego zagadnienia; 16. W ofercie wstępnej na modernizację systemu SCADA SGT p. 1.13 oferent potwierdza brak możliwości realizacji w pełni tego wymagania; 17. Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu, m.in. [Skrypt Operatora, System SYNDIS RV, Dokumentacja szkoleniowa], [Skrypt Administratora, Podstawy i obsługa systemu, Dokumentacja szkoleniowa] nie daje kompletnej i precyzyjnej odpowiedzi; 18. Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności; 19. Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie przedstawia kompletnej i precyzyjnej informacji nt funkcjonalności umożliwiającej spełnienie wymagań Zamawiającego. Powyższe zastrzeżenia Zamawiającego odnoszą się do punktów części II Umowy w zakresie następujących wymagań: pkt 3. Wymagania ogólne (wymagania spełniane przez implementację z oprogramowania) pkt 4. Architektura systemu SCADA dla SGT (wymaganie spełniane przez odpowiednie powiązanie elementów sprzętu i oprogramowania pomiędzy sobą) pkt 5. Wymagania funkcjonalne (wymagania spełniane przez implementację oprogramowania) pkt 6. Aplikacje dodatkowe (wymagania spełniane przez implementację oprogramowania) pkt 8. Wymagania sprzętowe(wymagania spełniane przez dostawę odpowiedniego sprzętu sprzętu) pkt 9. Wymagania wydajnościowe i wymiarowe (wymagania spełniane przez implementację oprogramowania i sprzęt) pkt 11. Interfejsy zewnętrzne (wymagania spełniane przez oprogramowanie i komputery odpowiedzialne za komunikację). Zamawiający w swojej ocenie nie bierze pod uwagę następujących informacji zawartych w odrzuconej ofercie wstępnej: 1. Zapisów w zakresie wymagań dotyczących wymagań będących bezpośrednim efektem działania oprogramowania i jego właściwości, użytej architektury i specjalizowanego sprzętu do realizacji interfejsów telemechaniki, w szczególności fragmentu tekstu oferty wstępnej: „Proponujemy wykonanie systemu SCADA SGT w oparciu o rodzinę produktów SO-5 produkcji Mi kronika składającej się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO-55. Proponowana architektura nowego systemu SCADA SGT przedstawiona została na Rysunku 1 i jest zgodna z propozycją Zamawiającego zawartą w rozdziale 4 Specyfikacji Technicznej Dostaw i Usług (Część II Umowy).” 2. Zapisów w załączonej dokumentacji SKRYPT EDYTORSKI - INFORMACJE O SYSTEMIE SYNDIS RV „System SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. ” Z informacji tych wynika, że każde wymaganie realizowane poprzez oprogramowanie, jeśli nie wskazano inaczej, będzie realizowanie poprzez odpowiednie zastosowanie systemu SYNDIS. Dla przypadków, w których oprócz działań konfiguracyjnych, parametryzacyjnych i edycyjnych konieczna jest rozbudowa systemu SYNDIS lub stworzenie nowej aplikacji, wskazano takie działania. Dla wszelkich wymagań związanych z oprogramowaniem Odwołujący opisał w ofercie wstępnej sposób realizacji wymagań. Przedstawiono architekturę systemu zgodną z wymaganiami W zakresie wymagań związanych ze sprzętem: a. dla elementów nie wymagających zasadniczego wyboru dopiero w fazie projektowej podano typ urządzenia i producenta; b. dla elementów, których dobór wymaga dodatkowych danych oprócz podanych w wstępnym SIWZ lub przeprowadzenia analiz i sporządzenia projektu, czynności, które stanowią element zamówienia, wskazano jedynie przewidywanego producenta. Do urządzeń takich należy miedzy innymi UPS dla którego Zamawiający podał moc minimalną. Moc wymagana urządzenia będąca podstawą doboru typu, może być dopiero ustalona na etapie projektu po zbilansowaniu wszystkich potrzeb w tym zakresie. Spełnienie wymagań minimalnych nie jest wystarczające co zauważył Zamawiający dopisując warunek przy wymaganiach na urządzenia, że „Za skalowanie i dobór urządzeń odpowiada Wykonawca". Dla wszelkich wymagań sprzętowych Odwołujący opisał sposób realizacji wymagań. W zakresie wymagań wydajnościowych w pkt od 9.5.1 do 9.5.8 oferty wstępnej Odwołujący podał istotne informacje dotyczące sposobu realizacji wymagań w zakresie wydajności tj.: a. wskazał, że system SCADA zostanie zrealizowany za pośrednictwem dedykowanych elementów do realizacji takich rozwiązań. Zastosowany będzie systemu SYNDIS i sterowniki komunikacyjne S055. Systemy i urządzenia dedykowane ze swojej natury zapewniają najlepszą możliwą wydajność; b. zaproponowano optymalną architekturę systemu pozwalająca na uzyskanie wymaganych wskaźników; c. podano typy i producenta, przewidywanego do użycia sprzętu odpowiadającego za szybkość aplikacji; Więcej informacji w zakresie wydajności nie można było podać, ponieważ Zamawiający nie podał kluczowych informacji dla uściślenia oferty wstępnej, tj. liczby użytkowników logujących się bezpośrednio do systemu SCADA (odpowiedź na pytanie 23 w piśmie z 28.08.2012 r.) deklarując omówienie tych kwestii podczas negocjacji. Odwołujący mógł jedynie podać te dane, które wskazał w ofercie. Bardziej szczegółowy opis sposobu zrealizowania wymagań w odniesieniu do wydajności i doboru parametrów sprzętu uzależniony jest od obciążenia głównych systemu przez użytkowników systemu SCADA. Dla wszelkich wymagań związanych z wydajnością Odwołujący opisał sposób realizacji wymagań. W odniesieniu do wymagań dotyczących bezpieczeństwa (punkty 4.2 do 4.2.12) Odwołujący podał w ofercie wstępnej istotne informacje związane z realizacją wymagań w zakresie realizacji bezpieczeństwa. Spełnienie opisu realizacji wymogu należy analizować zgodnie z zakresem zamówienia i odpowiedzią na pytanie 4 z 28.08.2012 r., w której Zamawiający nie podał kluczowej informacji dotyczącej swojej polityki bezpieczeństwa. Mając na uwadze opis przedmiotu zamówienia oraz treść odpowiedzi, iż „polityka ma być opracowana w trakcie realizacji zamówienia” nie sposób opisać szczegółów tej polityki w ofercie wstępnej. Kompleksowa oceny oferty wstępnej Odwołującego, uwzględniająca wszystkie elementy oferty wstępnej oraz wszystkie postanowienia SIWZ łącznie, w powiązaniu ze sobą, pozwala stwierdzić, iż Odwołujący opisał w ofercie wstępnej sposób realizacji wymagań dla wszelkich, poszczególnych wymagań podanych w SIWZ. Zamawiający pismem z 21.09.2012 r. wezwał Odwołującego do złożenia wyjaśnień dotyczących treści złożonej oferty wstępnej w zakresie opisu sposobu realizacji części wymagań (19 pkt), a po otrzymaniu wyjaśnień, odrzucił ofertę wstępną podnosząc tożsame zastrzeżenia w stosunku do innych wymagań (62 pkt), w stosunku do których nie wystąpił o udzielenie wyjaśnień. Takie wybiórcze działanie Zamawiającego narusza art. 87 ust. 1 PZP. Skoro istnieje możliwość negocjacji tych kwestii, których niewystarczający w ocenie Zamawiającego opis stanowił przyczynę odrzucenia oferty wstępnej, przy jednoczesnej akceptacji zawierającej analogiczny zakres informacji treści oferty wstępnej zaproszonego do negocjacji wykonawcy, to sytuacja taka stanowi naruszenie zasady uczciwej konkurencji i równego traktowania wykonawców. Zamawiający przyjęty sposób sporządzenia krótkiej informacji o sposobie realizacji poszczególnego wymagania w wielu punktach akceptuje i nie podnosi zastrzeżeń co do braku krótkiego opisu, jego precyzyjności, pełności itp., w innych zaś punktach analogicznie co do metod opisanych uznaje je, za niespełniające wymagań SIWZ. Odnosząc się do poszczególnych zarzutów podanych w piśmie Zamawiającego na uzasadnienie j niezgodności oferty wstępnej z (wstępną) SIWZ, Odwołujący wskazał, co następuje: 1. Zastrzeżenie: Brak opisu realizacji wymagania. Wymaganie 3.2.: System budowany będzie jako rozproszony w oparciu o istniejący system łączności Zamawiającego. Budowany system ma zapewniać: Prezentację danych bieżących i archiwalnych na ekranach procesowych obrazujących graficznie obiekty gazociągu oraz na zestawieniach tabelarycznych. Opis zawarty w tabeli w ofercie Odwołującego: Zgodnie z wymaganiami Zamawiającego. Oferowany system SCADA SYNDIS będzie umożliwiał prezentację danych bieżących i archiwalnych na ekranach procesowych obrazujących graficznie obiekty gazociągu oraz na zestawieniach tabelarycznych. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane. W Załączniku nr 1 do oferty przedstawiono także rozproszoną architekturę systemu - na rysunkach i w opisie - opartą o system łączności Zamawiającego, ponadto w załączonej do oferty dokumentacji pokazano i opisano sposób prezentacji danych bieżących i archiwalnych w standardowy sposób. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 2. Zastrzeżenie: Brak opisu realizacji wymagania. Wymaganie 3.3.: System budowany będzie jako rozproszony w oparciu o istniejący system łączności Zamawiającego. Budowany system ma zapewniać: Przetwarzanie i archiwizacja wszystkich danych bieżących zdefiniowanych w modelu danych. Opis zawarty w tabeli w ofercie Odwołującego: Zgodnie z wymaganiami Zamawiającego. Proponowany przez MIKRONIKĘ system SCADA SYNDIS przetwarza i archiwizuje wszystkie dane bieżące zdefiniowane w modelu danych. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. W Załączniku nr 1 do oferty przedstawiono także rozproszoną architekturę systemu - na rysunkach i w opisie - opartą o system łączności Zamawiającego, ponadto w załączonej do oferty dokumentacji pokazano i opisano sposób archiwizacji danych bieżących i archiwalnych w standardowy sposób. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 3. Zastrzeżenie: Brak opisu realizacji wymagania. Wymaganie 3.4.: System budowany będzie jako rozproszony w oparciu o istniejący system łączności Zamawiającego. Budowany system ma zapewniać: Zdalne sterowanie procesami technologicznymi. Opis zawarty w tabeli w ofercie Odwołującego: Zgodnie z wymaganiami Zamawiającego. Oferowany system SYNDIS umożliwia zdalne sterowanie procesami technologicznymi. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. W Załączniku nr 1 do oferty przedstawiono także rozproszoną architekturę systemu - na rysunkach i w opisie, opartą o system łączności Zamawiającego, ponadto w załączonej do oferty dokumentacji pokazano i opisano sposób sterowania procesami technologicznymi w standardowy sposób. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 4. Zastrzeżenie: Brak opisu realizacji wymagania. Wymaganie 3.6.: System budowany będzie jako rozproszony w oparciu o istniejący system łączności Zamawiającego. Budowany system ma zapewniać: Wymianę danych z systemami zewnętrznymi, w szczególności z systemami głównych pomiarowni gazu, systemami pomiarowni potrzeb własnych, systemami automatyki tłoczni gazu SCS (w tym przekazywanie poleceń z systemu SCADA do systemu automatyki tłoczni), lokalnymi systemami automatyki w obiektach typu ZZU, OZZU, ZP i ZPT). Opis zawarty w tabeli w ofercie Odwołującego: Zgodnie z wymaganiami Zamawiającego. System SCADA SYNDIS będzie prowadził wymianę danych z systemami zewnętrznymi, w szczególności z systemami głównych pomiarowni gazu, systemami pomiarowni potrzeb własnych, systemami automatyki tłoczni gazu SCS (w tym przekazywanie poleceń z systemu SCADA do systemu automatyki tłoczni), lokalnymi systemami automatyki w obiektach typu ZZU, OZZU, ZP i ZPT). Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. W Załączniku nr 1 do oferty w rozdziale „Architektura systemu” wskazano sposób rozwiązania wymiany danych z systemami zewnętrznymi, wskazano rodzaj sprzętu użyty do tego, a w załączonej do oferty dokumentacji systemu SYNDIS przedstawiono standardowe mechanizmy programowe służące do wymamiany danych. Bardziej szczegółowe opisy realizacji wymiany danych zawarto w opisach sposobów realizacji wymagań dla punktów rozdziału 11 „Interfejsy zewnętrzne” SIWZ oraz punktów 5.1.10-5.1.12 SIWZ. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 5. Zastrzeżenie: Brak opisu realizacji wymagania. Wymaganie 3.15.: System budowany będzie jako rozproszony w oparciu o istniejący system łączności Zamawiającego. Budowany system ma zapewniać: Udostępnianie i zarządzanie udostępnionymi danymi historycznymi do systemów/aplikacji zewnętrznych takich jak system ERP, systemy administrowane w innych firmach. Dane mogą być udostępniane z opóźnieniem nie większym niż 5 minut od momentu się ich pojawienia. Opis zawarty w tabeli w ofercie Odwołującego: Zgodnie z wymaganiami Zamawiającego. Dostarczony przez Ml KRONIKĘ system SCADA będzie udostępniał i zarządzał udostępnionymi danymi historycznymi do systemów/aplikacji zewnętrznych, takich jak system ERP, systemy administrowane w innych firmach; dane będą udostępniane z opóźnieniem nie większym niż 5 minut od momentu ich pojawienia się. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. W Załączniku nr 1 do oferty w rozdziale „Architektura systemu” wskazano sposób rozwiązania wymiany danych z systemami zewnętrznymi, ponadto w załączonej do oferty dokumentacji opisano sposób udostępniania danych historycznych do systemów i aplikacji zewnętrznych i zarządzania nimi w standardowy sposób. Przedstawiona architektura systemu, wskazująca na rozwiązania sprzętowo- programowe, w tym rodzaj zastosowanego sprzętu, gwarantuje uzyskanie wymaganej funkcjonalności. Dodatkowo w opisie realizacji dla punktów 5.1.10-5.1.12 SIWZ Odwołujący zawarł informacje o możliwych mechanizmach współpracy systemu SYNDIS z systemami/aplikacjami zewnętrznymi oraz bazodanowymi. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony 6. Zastrzeżenie: Opis wynikający z oferty wstępnej na Modernizację Systemu SCADA SGT nie wyjaśnia sposobu opracowania polityki bezpieczeństwa i związanych z nią wymagań Zamawiającego. Wymaganie 4.2.. 4.2.1.. 4.2.2.. 4.2.3.. 4.2.4.. 4.2.5.. 4.2.6.. 4.2.7., 4.2.8.. 4.2.9.. 4.2.10.. 4.2.11.. 4.2.12.. 4.3.7.. 4.3.8.. 4.3.11.. 4.10 oraz od 4.10.1. do 4.10.5.. 4.12.. 4.14.1.: 4.2. Wykonawca ma za zadanie opracować całościową politykę bezpieczeństwa dla Systemu SCADA wraz z procedurami postępowania w przypadku pojawienia się typowych uszkodzeń lub stanów awaryjnych np.: awarii dysku, zasilacza, zawieszenia aplikacji, zaniku łączności itp. Główne zadania związane z bezpieczeństwem systemu SCADA to: 4.2.1. Zapewnienie ciągłej, pełnej funkcjonalności systemu pozwalającej na monitorowanie i sterowanie gazociągiem przez służby dyspozytorskie. 4.2.2. Zapewnienie bezpieczeństwa i integralności danych bieżących i archiwalnych. 4.2.3. Ochrona systemu przed nieautoryzowanym dostępem. 4.2.4. Udostępnianie danych o stanie gazociągu dla firm biorących udział w transporcie gazu oraz innych jednostek organizacyjnych EuRoPol GAZ. 4.2.5. Kolekcjonowanie danych do bilansowania przesyłu. 4.2.6. Scentralizowana autoryzacja użytkowników za pomocą haseł z możliwością wprowadzania czasowych ograniczeń i wymuszania zmian haseł. 4.2.7. Sygnalizację otwarcia drzwi szaf z podzespołami systemu SCADA. 4.2.8. Zabezpieczenie punktów styku z sieciami (systemami) zewnętrznymi. Zastosowanie programów (np. antywirusowych) do ochrony systemu informatycznego. 4.2.9. Zapewnienie serwisu i wsparcia technicznego wraz za pośrednictwem Internetu na potrzeby obsługi zdalnej. Łącze zapewnia Zamawiający. 4.2.10. Zapewnienie narzędzi do robienia kopi bezpieczeństwa z nośnikami które można przechowywać w sejfie. 4.2.11. Wszystkie elementy systemu, które przed wyłączaniem zasilania muszą być wprowadzone w specjalny tryb chroniący podzespoły lub dane, mają mieć opracowaną automatyczną procedurę wprowadzania urządzenia w powyższy tryb ze stanu pracy. Uruchomienie (lub dezaktywacja) tej sekwencji ma być możliwa zdalnie przez administratora systemu oraz urządzenia UPS w razie problemów z zasilaniem. 4.2.12. Wykonawca będzie śledził zmiany w oprogramowaniu firm trzecich zastosowanego w projekcie i dostarczał poprawki na płytach CD/DVD wraz z instrukcją użycia po uprzednim przetestowaniu ich wpływu na działanie systemu we własnym systemie testowym. 4.3.7. Zapewniać synchronizację danych w obydwu centrach. 4.3.8. Synchronizacja ma być przeprowadzana na bieżąco albo cyklicznie nie rzadziej niż raz na 1 minutę. 4.3.11. Przełączenie z Podsystemu Głównego na Podsystem Zapasowy powinno następować ręcznie z podsystemu Zapasowego 4.10 Stanowisko do testów i wdrożeń służyć będzie do przygotowywania i testowania zmian wprowadzanych do bazy opisu modelu i parametrów systemu SCADA. W skład stanowiska mają wchodzić wszystkie niezbędne elementy systemu konieczne do przeprowadzenia całe-go procesu wprowadzania zmian związanych z dołączaniem nowych obiektów do systemu SCADA, a w szczególności: 4.10.1. Kreowania nowego typu obiektu 4.10.2. Dodawania nowego obiektu (PLC, system zewnętrzny) 4.10.3. Dodawania nowych zmiennych 4.10.4. Tworzenia nowych i modyfikacji istniejących algorytmów przetwarzania sygnałów 4.10.5. Tworzenia nowych symboli graficznych i całych ekranów dla wizualizacji 4.12. Dane archiwalne, chwilowe historyczne, ekrany procesowe, wykresy i raporty mają być dostępne dla użytkowników zewnętrznych poprzez aplikację Klient zainstalowaną na komputerach tych użytkowników. Aplikacja ta nie może mieć bezpośredniego kontaktu z systemem SCADA. Dane dla powyższej aplikacji mają być dostarczane poprzez Serwery Komunikacyjne. 4.14.1. Aplikacje dodatkowe (Dziennik dyspozytorski, Simone) opisane w rozdziale 6 mają być zainstalowane na Serwerach Aplikacji Dodatkowych. Dostęp do tych aplikacji ma być możliwy zarówno z sieci SCADA jak i Sieci Biurowej EuRoPol GAZ. Opis zawarty w tabeli w ofercie Odwołującego: Opis sposobu realizacji wymagania znajduje się w Załączniku nr 1 do OFERTY WSTĘPNEJ, (w rubryce „uwagi”: Szczegółowe aspekty architektury systemu zostaną omówione na etapie negocjacji). Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. W Załączniku nr 1 do oferty przedstawiono także rozproszoną architekturę systemu - na rysunkach i w opisie, zapewniającą realizację wymaganej funkcjonalności. W odniesieniu do bezpieczeństwa w zakresie punktów od 4.2 do 4.2.12, 4.3.7., 4.3.8., 4.3.11.,4.10 oraz od 4.10.1. do 4.10.5., 4.12., 4.14.1 Odwołujący podał w ofercie wstępnej istotne informacje związane z realizacją polityki bezpieczeństwa: a. w opisie architektury systemu odnośnie środków sprzętowych i rozwiązań układowych w postaci opisowej i rysunkowej; b. w załączonych dokumentacjach systemu SYNDIS w zakresie standardowych mechanizmów programowych. Zgodnie z opisem przedmiotu zamówienia i odpowiedzią Zamawiającego na pytanie nr 4 w piśmie z 28 sierpnia 2012 r., iż „polityka ma być opracowana w trakcie realizacji zamówienia”, nie sposób przedstawić jej szczegóły w ofercie wstępnej. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zastrzeżenie: pusta komórka Wymaganie 5.1.15.: Ze względu na to, że zdalny dostęp do systemu może być realizowany za pośrednictwem łącz o małej przepustowości (modem), funkcjonalności z p. 5.1.14 nie mogą być realizowane w postaci pulpitu zdalnego. Opis zawarty w tabeli w ofercie Odwołującego: 5.1 - Architektura oparta o otwarty i modułowy system SYNDIS produkcji MIKRONIKI. Oferowane narzędzia umożliwiają pracę po łączach o niskiej przepustowości. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował również, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. W Załączniku nr 1 do oferty przedstawiono także rozproszoną architekturę systemu - na rysunkach i w opisie, zapewniającą realizację wymaganej funkcjonalności. Wskazano jednoznacznie, że zdalny dostęp jest możliwy z poziomu systemu SYNDIS, a to oznacza możliwość niestosowania zdalnego pulpitu, które to rozwiązanie jest rozwiązaniem oferowanym przez system operacyjny, a nie aplikacje. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 8. Zastrzeżenie: Wymaganie nie zostało opisane w dokumentacji systemu, a Wykonawca nie opisał w tabeli sposobu osiągnięcia rezultatu zgodnego z wymaganiem Zamawiającego. Wymaganie 5.2.1.7. oraz od 5.2.2.4. do 5.2.2.6.: 5.2.1.7. System uprawnień powinien być spójny, t.j. jeśli użytkownik nie ma prawa do wyświetlenia zmiennej, to również nie może użyć danej zmiennej na wykresie, raporcie czy aplikacji zewnętrznej. 5.2.2.4. Jeśli na ekranie procesowym występuje zmienna, do której dany użytkownik nie ma praw dostępu, jej wartość nie może być wyświetlona. Powinna być zastąpiona specjalnym symbolem. 5.2.2.5. Jeśli raport zawiera zmienną, do której dany użytkownik nie ma praw dostępu, jej wartość nie może być wyświetlona. Powinna być zastąpiona specjalnym ciągiem np. „*****”. 5.2.2.6. Jeśli wykres zawiera zmienną, do której dany użytkownik nie ma praw dostępu, jej przebieg nie może być wyświetlony. W takiej sytuacji powinien pojawić się komunikat np. przy opisie osi lub w legendzie. Opis zawarty w tabeli w ofercie Odwołującego: 5.2 - System uprawnień zostanie oparty o moduł uprawnień systemu SCADA SYNDIS, który zostanie sparametryzowany do wymagań Zamawiającego. Uwaga: Można rozważyć możliwość połączenia systemu uprawnień do SCADA SYNDIS z systemem kontroli i dostępu stosowanym w EuRoPol GAZ. Zgodnie z wymaganiami Zamawiającego; realizacja poprzez system uprawnień SCADA SYNDIS. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Opis sposobu osiągnięcia rezultatu nie był wymagany w zakresie oferty wstępnej. W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV" system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Wskazano jednoznacznie, że funkcjonalność zostanie zrealizowana z poziomu modułu uprawnień systemu SYNDIS. Ponadto w załączonej do oferty dokumentacji systemu SYNDIS opisano możliwości i sposób działania standardowych funkcji modułu uprawnień. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 9. Zastrzeżenie: Wymaganie nie zostało opisane w dokumentacji systemu, a Wykonawca nie opisał w tabeli sposobu osiągnięcia rezultatu zgodnego z wymaganiem Zamawiającego. Wymaganie 5.2.3., 5.2.4.: 5.2.3. Wykresy. 5.2.3.1. System powinien umożliwiać nadanie osobnych uprawnień do wyświetlania wykresów i osobnych do tworzenia szablonów wykresów. 5.2.3.2. Użytkownik powinien mieć prawo do tworzenia publicznych i prywatnych szablonów wykresów. Szablon prywatny może być modyfikowany tylko przez użytkownika, który go stworzył. 5.2.4. Raporty. 5.2.4.1. System powinien umożliwiać nadanie osobnych uprawnień do wyświetlania raportów i osobnych do tworzenia szablonów raportów. 5.2.4.2. Użytkownik powinien mieć prawo do tworzenia publicznych i prywatnych szablonów raportów. Szablon prywatny może być modyfikowany tylko przez użytkownika, który go stworzył. Opis zawarty w tabeli w ofercie Odwołującego: 5.2 - System uprawnień zostanie oparty o moduł uprawnień systemu SCADA SYNDIS, który zostanie sparametryzowany do wymagań Zamawiającego. Uwaga: Można rozważyć możliwość połączenia systemu uprawnień do SCADA SYNDIS z systemem kontroli i dostępu stosowanym w EuRoPol GAZ. 5.2.3.1. 5.2.3.2. 5.2.4.1. 5.2.4.2.: Zgodnie z wymaganiami Zamawiającego; realizacja poprzez system uprawnień SCADA SYNDIS. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Opis sposobu osiągnięcia rezultatu nie był wymagany w zakresie oferty wstępnej. W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Wskazano jednoznacznie, że funkcjonalność zostanie zrealizowana z poziomu modułu uprawnień systemu SYNDIS. Ponadto w załączonej do oferty dokumentacji systemu SYNDIS opisano możliwości i sposób działania standardowych funkcji modułu uprawnień, a także sposób realizacji szablonów (zestawów). Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 10. Zastrzeżenie: Wymaganie nie zostało opisane w dokumentacji systemu, a Wykonawca nie opisał w tabeli sposobu osiągnięcia rezultatu zgodnego z wymaganiem Zamawiającego. Wymaganie: od 5.4.1.8. do 5.4.1.11: 5.4.1. Należy przewidzieć następujący minimalny zestaw rodzajów zmiennych występujących w systemie SCADA: 5.4.1.8. Zmienne licznikowe zliczające zdarzenia 5.4.1.9. Zmienne licznikowe zliczające czasy trwania określonych stanów zmiennych 5.4.1.10. Zmienne sygnalizacyjne. Zmienna sygnalizacyjna jest to zmienna dyskretna, której stany zależą od kombinacji statusów innej zmiennej. 5.4.1.11. Zmienne tekstowe. Zmienne te służą do przechowywania do przechowywania informacji w postaci tekstu np. komunikatów otrzymanych protokołem SNMP. Opis zawarty w tabeli w ofercie Odwołującego: 5.4 - System przetwarzania zmiennych zostanie oparty o system przetwarzania funkcjonujący w oferowanym systemie SCADA SYNDIS. System przetwarzania zostanie sparametryzowany i rozbudowany do wymagań Zamawiającego bez odstępstw. Zgodnie z wymaganiami Zamawiającego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Opis sposobu osiągnięcia rezultatu nie był wymagany w zakresie oferty wstępnej. W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że oprogramowanie SYNDIS zostanie rozbudowane do wymagań Zamawiającego bez odstępstw. Poinformował również, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Wskazano jednoznacznie, że funkcjonalność zostanie zrealizowana przez system przetwarzania systemu SYNDIS. Ponadto w załączonej do oferty dokumentacji systemu SYNDIS opisano sposób działania standardowych zmiennych. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 11. Zastrzeżenie: Brak funkcji log In. Wymaganie 5.4.6.5.: Dla zmiennej obliczanej powinna być możliwość przyporządkowania procedury obliczeniowej która: Może wykorzystać oprócz podstawowych operacji matematycznych również funkcje: logarytm naturalny, logarytm dziesiętny, funkcję potęgową (również o współczynniku ułamkowym), funkcje wykładniczą, funkcje trygonometryczne, funkcje dzielenia modulo, zaokrąglania, obliczania reszty z dzielenia) Opis zawarty w tabeli w ofercie Odwołującego: 5.4 - System przetwarzania zmiennych zostanie oparty o system przetwarzania funkcjonujący w oferowanym systemie SCADA SYNDIS. System przetwarzania zostanie sparametryzowany i rozbudowany do wymagań Zamawiającego bez odstępstw; Zgodnie z wymaganiami Zamawiającego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że oprogramowanie SYNDIS zostanie rozbudowane do wymagań Zamawiającego bez odstępstw. Poinformował również, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Wskazano jednoznacznie, że funkcjonalność zostanie zrealizowana przez system przetwarzania systemu SYNDIS. Ponadto w załączonej do oferty dokumentacji systemu SYNDIS opisano sposób działania standardowych funkcji. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 12. Zastrzeżenie: Wymaganie nie zostało opisane w dokumentacji systemu, a Wykonawca nie opisał w tabeli sposobu osiągnięcia rezultatu zgodnego z wymaganiem Zamawiającego. Wymaganie 5.4.9.: Powinna być możliwość określenia maksymalnego okresu czasu od ostatniej zmiany wartości zmiennej. Przekroczenie tego czasu powodować będzie zapisanie aktualnej wartości zmiennej do bazy danych. Opis zawarty w tabeli w ofercie Odwołującego: 5.4 - System przetwarzania zmiennych zostanie oparty o system przetwarzania funkcjonujący w oferowanym systemie SCADA SYNDIS. System przetwarzania zostanie sparametryzowany i rozbudowany do wymagań Zamawiającego bez odstępstw. Zgodnie z wymaganiami Zamawiającego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Opis sposobu osiągnięcia rezultatu nie był wymagany w zakresie oferty wstępnej. W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że oprogramowanie SYNDIS zostanie rozbudowane do wymagań Zamawiającego bez odstępstw. Poinformował również, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Wskazano jednoznacznie, że funkcjonalność zostanie zrealizowana przez system przetwarzania systemu SYNDIS. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 13. Zastrzeżenie: Wynika ze Skryptu Operatora, system SYNDIS RV, dokumentacja szkoleniowa i pisma firmy Mikronika nr MI/DM/AN/1977/2012 z dnia 27.09.2012, brak precyzyjnego opisu, nie wszystkie warunki spełnione. Wymaganie 5.4.10.: Dla każdej zmiennej w czasie działania systemu powinna być możliwość ustawienia: 5.4.10.1. Blokady przetwarzania 5.4.10.2. Blokady kontroli przekroczenia granic 5.4.10.3. Blokady alarmowania 5.4.10.4. Blokady zapisu do listy alarmów 5.4.10.5. Blokady zapisu do rejestru zdarzeń 5.4.10.6. Blokady przyjmowania wartości zastępczej 5.4.10.7. Wartości (stanu) ręcznie lub jako wynik działania procedury 5.4.10.8. Notatki Opis zawarty w tabeli w ofercie Odwołującego: 5.4 - System przetwarzania zmiennych zostanie oparty o system przetwarzania funkcjonujący w oferowanym systemie SCADA SYNDIS. System przetwarzania zostanie sparametryzowany i rozbudowany do wymagań Zamawiającego bez odstępstw. Zgodnie z wymaganiami Zamawiającego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Zarzut bezpodstawny; opis precyzyjny nie był wymagany w zakresie oferty wstępnej. W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że oprogramowanie SYNDIS zostanie rozbudowane do wymagań Zamawiającego bez odstępstw. Poinformował również, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Wskazano jednoznacznie, że funkcjonalność zostanie zrealizowana przez system przetwarzania systemu SYNDIS. Dodatkowo w wyjaśnieniach odpowiedziano wyczerpująco na zadane w tym zakresie pytanie. Pytanie: W punkcie 5.4.10 „Dla każdej zmiennej w czasie działania systemu powinna być możliwość ustawienia: 5.4.10.1 Blokady przetwarzania 5.4.10.2 Blokady kontroli przekroczenia granic 5.4.10.3 Blokady alarmowania 5.4.10.4 Blokady zapisu do listy alarmów 5.4.10.5 Blokady zapisu do rejestru zdarzeń 5.4.10.6 Blokady przyjmowania wartości zastępczej 5.4.10.7 Wartości (stanu) ręcznie lub jako wynik działania procedury 5.4.10.8 Notatki” Prosimy o wskazanie, w którym miejscu dostarczonej oferty znajduje się opis realizacji powyższej funkcjonalności. Wyjaśnienia Odwołującego przesłane Zamawiającemu: Opis realizacji tej funkcjonalności został zawarty w punkcie 5.4 tabeli wraz z jego podpunktami oraz przykłady realizacji niektórych (standardowych) funkcjonalności zawarto także w dokumentacji standardowej „System SYNDIS RV - Skrypt Operatora”:, pkt. 3.3. Zmiana atrybutów obiektów. Podane w ofercie wstępnej informacje oraz udzielona Zamawiającemu odpowiedź łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności. Zamawiający nie podniósł zarzutu braku opisu sposobu realizacji, wobec czego postawiony wymóg należy uznać za spełniony. Odwołujący zadeklarował spełnienie każdej funkcjonalności, wobec czego uwaga Zamawiającego, że „nie wszystkie warunki spełnione” nie ma pokrycia w złożonej ofercie wstępnej. Zarzut braku w skrypcie jest bezprzedmiotowy. Zamawiający nie wymagał precyzyjnych opisów - wymagał krótkich opisów, z natury nie mogących być precyzyjnymi. Zamawiający nie wymagał dostarczenia dokumentacji opisującej szczegółowo wszystkie funkcje, w dodatku w sposób zapewniający potwierdzenie spełnienia wszystkich wymagań. Zamawiający żądał przedstawienia dokumentacji standardowych funkcji systemu. Taką dokumentację otrzymał. Dokumentacja ta nie zawiera opisu wszystkich żądanych funkcji, co wynika z jej istoty. Oczekiwania Zamawiającego odnośnie do tej dokumentacji przekraczają uprawnione żądania, w związku z czym nie można uznać zarzutu za zasadny. 14. Zastrzeżenie: Wymaganie nie zostało opisane w dokumentacji systemu, a Wykonawca nie opisał w tabeli sposobu osiągnięcia rezultatu zgodnego z wymaganiem Zamawiającego. Wymaganie 5.4.11: Dla ustawień opisanych w punkcie 5.4.10 powinna być możliwość określenia terminu (data i godzina) ważności dla każdego z wprowadzonych ustawień osobno. Po upływie tego terminu ustawienie będzie automatycznie anulowane z wygenerowaniem zdarzenia. Opis zawarty w tabeli w ofercie Odwołującego: 5.4 - System przetwarzania zmiennych zostanie oparty o system przetwarzania funkcjonujący w oferowanym systemie SCADA SYNDIS. System przetwarzania zostanie sparametryzowany i rozbudowany do wymagań Zamawiającego bez odstępstw. Zgodnie z wymaganiami Zamawiającego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Opis sposobu osiągnięcia rezultatu nie był wymagany w zakresie oferty wstępnej. W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że oprogramowanie SYNDIS zostanie rozbudowane do wymagań Zamawiającego bez odstępstw. Poinformował również, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Wskazano jednoznacznie, że funkcjonalność zostanie zrealizowana przez system przetwarzania systemu SYNDIS. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 15. Zastrzeżenie: Wymaganie nie zostało opisane w dokumentacji systemu, a Wykonawca nie opisał w tabeli sposobu osiągnięcia rezultatu zgodnego z wymaganiem Zamawiającego. Wymaganie 5.4.12. 5.4.14.. 5.8.11.. 5.8.12.: 5.4.12. Status zmiennej powinien zawierać co najmniej następujące informacje: 5.4.12.1. Błąd pozyskania (wartość niedostępna lub poza zakresem fizycznym) 5.4.12.2. Przekroczenie granicy (każdej osobno) 5.4.12.3. Przekroczenie gradientu (każdego osobno) 5.4.12.4. Aktywna blokada (każda osobno) 5.4.12.5. Przyjęcie wartości początkowej 5.4.12.6. Przyjęcie wartości wprowadzonej ręcznie (lub jako wynik działania procedury) 5.4.12.7. Pojawienie się błędu przetwarzania 5.4.12.8. Aktywnym alarmie 5.4.12.9. Konieczności potwierdzenia alarmu (niezależnie od tego czy alarm jest aktywny czy 5.4.12.10. Poleceniu w trakcie wykonywania 5.4.12.11. Błędzie wykonania polecenia lub ustawienia wartości zadanej 5.4.14. Dla sygnałów dyskretnych należy zapewnić możliwość przeprowadzenia następujących operacji na zawartości datagramów otrzymywanych z zewnętrznych urządzeń lub systemów: 5.4.14.1. Używania masek bitowych dla odfiltrowania informacji 5.4.14.2. „Sklejania” nieciągłych obszarów danych 5.4.14.3. Używania przesunięć bitowych 5.4.15. Dodawanie, usuwanie i konfiguracja zmiennych powinna następować z użyciem oprogramowania narzędziowego z interfejsem. 5.8.11.Okna do potwierdzenia rozkazu powinno się zamykać automatycznie po skonfigurowanym przez administratora czasie braku aktywności użytkownika. 5.8.12. Opóźnienie w przekazania polecenia do sterownika od jego potwierdzenia nie może być dłuższy niż 1 sekunda. Opis zawarty w tabeli w ofercie Odwołującego: 5.4 - System przetwarzania zmiennych zostanie oparty o system przetwarzania funkcjonujący w oferowanym systemie SCADA SYNDIS. System przetwarzania zostanie sparametryzowany i rozbudowany do wymagań Zamawiającego bez odstępstw. 5.8 - Zgodnie z wymaganiami Zamawiającego. Interfejs systemu SCADA SYNDIS jest w pełni graficzny, wykorzystuje do wizualizacji grafikę wektorową z możliwościami decluteringu, panningu, zoomowania itp., umożliwia wykorzystywanie grafik rastrowych, animacji oraz strumieni video. Zgodnie z wymaganiami Zamawiającego. Ustosunkowanie sie Odwołującego do zastrzeżenia Zamawiającego: Opis sposobu osiągnięcia rezultatu nie był wymagany w zakresie oferty wstępnej. W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że oprogramowanie SYNDIS zostanie rozbudowane do wymagań Zamawiającego bez odstępstw. Poinformował również, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Wskazano jednoznacznie, że funkcjonalność zostanie zrealizowana w systemie SYNDIS oraz poprzez proponowaną architekturę systemu opartą o przedstawione urządzenia - Załącznik nr 1 do oferty. W załączonej do oferty dokumentacji opisano sposób realizacji funkcjonalności przedmiotowych punktów, dostępny standardowymi mechanizmami. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności. 16. Zastrzeżenie: Wymaganie nie zostało opisane w dokumentacji systemu, a Wykonawca nie opisał w tabeli sposobu osiągnięcia rezultatu zgodnego z wymaganiem Zamawiającego. Wymaganie 5.16.1.. 5.16.2.. 5.16.3.. 5.16.4.. 5.16.6.. 5.16.7.. 5.16.9.. 5.16.10., 5.16.11.. 5.16.12.: 5.16.1. Przy wybieraniu danych do raportu powinna być możliwość: 5.16.1.1. Użycia filtrów opartych o wszystkie parametry zmiennych lub ich fragmenty 5.16.1.2. Użycia znaków wieloznacznych (?, *,A) 5.16.1.3. Użycia zakresów dla wybieranych danych np. [1 - 7] 5.16.1.4. Użycia okresu czasu za jaki dane maja być wyświetlone. 5.16.2. Z lewej strony tabeli maja być znaczniki czasu (w czasie lokalnym wynikającym ze strefy czasowej ustawionej w systemie operacyjnym). 5.16.3. Raster czasu musi umożliwiać wyświetlanie wartości co najmniej co: sekundę, minutę, godzinę, dzień, tydzień, miesiąc, rok. 5.16.4. Dla rastra czasu dłuższego niż godzina, mają być dostępne warianty: 5.16.4.1. ze stałą godziną lokalną (np. 8:00, niezależnie od pory roku), 5.16.4.2. ze stałą godziną względem GMT (np. 8:00 zimą, 9:00 latem). 5.16.6. Do raportu ma być możliwość dodania nagłówka i stopki strony, oraz nagłówka dla pierwszej strony i stopki dla ostatniej strony. 5.16.7. Do raportu powinno się dać wkleić nagłówek oraz stopkę sporządzoną w innym programie. 5.16.9. Wydrukować w układzie wielostronicowym albo przeskalowanym do 1 strony. 5.16.10. System powinien udostępniać „kreatora raportów” na wzór kreatora programu „MS Office Access”. 5.16.11. Możliwość stworzenia i zapisania do ponownego użycia szablonu raportu. 5.16.12. Automatyczna budowa raportu dla zmiennej, zmiennych procesowych wklejonych z ekranu procesowego. Opis zawarty w tabeli w ofercie Odwołującego: 5.76 -Zgodnie z wymaganiami Zamawiającego. Realizacja za pomocą standardowego modułu raporty systemu SCADA SYNDIS. (w rubryce „uwagi” w pkt. 5.16.: Moduł „Raporty” do konfiguracji raportu i prezentacji wykorzystuje technologie WEB. Oprócz korzystania z modułu „Raporty” system umożliwia wyświetlanie prostych zestawień danych w formie tabelarycznej. Dodatkowo system SYNDIS posiada możliwość bezpośredniego eksportu danych do stworzonych raportów w arkuszu EXCELa). Zgodnie z wymaganiami Zamawiającego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Opis sposobu osiągnięcia rezultatu nie był wymagany w zakresie oferty wstępnej. W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że istnieje możliwość realizacji wymagania poprzez zastosowanie arkusza EXCEL. Ponadto w załączonej do oferty dokumentacji opisano sposób realizacji funkcjonalności przedmiotowych punktów, oferowany standardowo. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności. Wymaganie nie zostało opisane w dokumentacji systemu, a Wykonawca nie opisał w tabeli sposobu osiągnięcia rezultatu zgodnego z wymaganiem Zamawiającego. Wymaganie 5.18.9.. 5.18.10., 5.18.11.. 5.18.13.. 5.20.4.. 5.20.8. 5.20.9.: Funkcja drukowania ma pozwalać na: 5.18.9. Dodawanie stopki i nagłówka do strony wydruku 5.18.10. Dodawanie numerowania stron wydruku 5.18.11. Prowadzić plik „log” wydruków 5.18.13. Skalowanie wydruku: 5.18.13.1. Aby zmieść całość materiału na jednej stronie 5.18.13.2. Skalowanie materiału w % 5.18.13.3. Zmianę orientacji wydruku (pionowa, pozioma) 5.18.13.4. Wydruk kilku stron na jednej stronie Wykonawca udostępni funkcjonalności lub oprogramowanie narzędziowe wykorzystywane do kreowania nowych ekranów, symboli oraz ich parametryzacji. Narzędzia te powinny posiadać następujące funkcje: 5.20.4. Obiekty powinny posiadać możliwość zagnieżdżania (obiekty w obiektach). 5.20.8. Możliwość określenia „punktów przywracania”, do których można powrócić cofając zmiany. 5.20.9. Możliwość swobodnego konfigurowania interfejsu użytkownika, w szczególności definiowania zawartości menu wywołujących programy, zawartości poszczególnych ekranów, itp. Opis zawarty w tabeli w ofercie Odwołującego: 5.18 - Zgodnie z wymaganiami Zamawiającego. Realizacja za pomocą standardowego modułu drukowania systemu SCADA SYNDIS. 5.20 - Zgodnie z wymaganiami Zamawiającego. Funkcjonalność jest realizowana poprzez przejście systemu w tryb edycyjny, w którym w menu systemu pojawiają się dodatkowe opcje związane z kreowaniem ekranów. Parametryzacji dokonuje się poprzez moduł konfiguracyjny systemu SCADA SYNDIS MShell. Edycja istniejących i nowych symboli dokonywana jest poprzez moduł edytora elementów - symbole edytowane są w formie grafiki wektorowej. Zgodnie z wymaganiami Zamawiającego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Opis sposobu osiągnięcia rezultatu nie był wymagany w zakresie oferty wstępnej. W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Wskazano jednoznacznie, że funkcjonalność zostanie zrealizowana w systemie SYNDIS. Dla punktu 5.20 podano dodatkowe wyjaśnienie. Ponadto w załączonej do oferty dokumentacji opisano sposób realizacji funkcjonalności przedmiotowych punktów, oferowany standardowo. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności. 18. Zastrzeżenie: Z opisu tabeli wynika deklaracja przygotowania API w przyszłości, obecnie wymagane API nie istnieje. Wymaganie 5.22.: Serwery i stacje robocze mają posiadać interfejs dla programów użytkownika (API), który powinien umożliwiać co najmniej: wyliczanie pomiarów/sygnałów, odczyt wartości i atrybutów wartości bieżących, odczyt wartości archiwalnych, wprowadzanie wartości bieżących, oczekiwanie/informowanie o zmianie wartości bieżącej. - API SCADA nie może uniemożliwiać jednoczesnego korzystania z API systemu operacyjnego (np. dostępu do systemu plików, sieci TCP/IP, tworzenia wątków, procesów, itd.). Opis zawarty w tabeli w ofercie Odwołującego: Zgodnie z wymaganiami Zamawiającego na etapie uzgodnień zostanie ustalona forma interfejsu ze wskazaniem, z jakimi programami użytkownika ma być zintegrowany. Użytkownikowi zostanie udostępniony odpowiedni API systemu SCADA SYNDIS, nie blokujący możliwości korzystania z API systemu operacyjnego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Zamawiający interpretuje (błędnie) treść zapisu, zamiast przyjąć do wiadomości to, co jest zawarte w opisie. Wbrew sugestiom Zamawiającego, z opisu nie wynika, że brak obecnie interfejsu API. W opisie zawarto informację, że zostanie ustalona forma i szczegóły przeznaczenia, co pozwoli udostępnić odpowiedni interfejs dla określonego programu. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, 19. Zastrzeżenie: Brak informacji w dokumentacji systemu oraz opisu sposobu realizacji wymagania. Wymaganie 5.23.4.. 5.23.5.. 5.23.6.. 5.23.7.. 5.23.8.: 5.23.4. W bazie danych przechowywane są następujące rodzaje danych: 5.23.4.1. pierwotne dane pomiarowe i sygnalizacje, przekazywane przez system telemetrii oraz układy automatyki lokalnej tłoczni i stacji pomiaru gazu, 5.23.4.2. informacje wprowadzane lub skorygowane ręcznie przez dyspozytora, 5.23.4.3. przetworzone dane pomiarowe (np. wartości średnie), 5.23.4.4. dane stanowiące wynik działania procedur wewnętrznych lub programów aplikacyjnych. 5.23.5. Okres przechowywania gromadzonych danych minimum 10 lat. 5.23.6. Ilość zgromadzonych danych nie może w sposób istotny wpływać na szybkość generowania wykresów i raportów. 5.23.7. Ilość przechowywanych danych nie może mieć wpływu na szybkość kolekcjonowania danych. 5.23.8. Aplikacja musi zapewniać automatyczny eksport danych starszych niż wymagany okres przechowywania oraz możliwość ich importu na wypadek potrzeby korzystania z tych danych w celach analizy. Opis zawarty w tabeli w ofercie Odwołującego: 5.23 Baza danych czasu rzeczywistego zostanie zrealizowana w oparciu o oprogramowanie c-tree wykorzystywane obecnie przez system SCADA SYNDIS do tworzenia bazy danych czasu rzeczywistego. Zgodnie z wymaganiami Zamawiającego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Poinformowała także, że oprogramowanie SYNDIS zostanie rozbudowane do wymagań Zamawiającego bez odstępstw. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Podana została także informacja, jakiego typu oprogramowanie zostanie użyte do rozbudowy systemu. Ponadto w załączonych dokumentacjach systemu SYNDIS znajdują się informacje o standardowej funkcjonalności w przedmiotowym zakresie. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, 20. Zastrzeżenie: Brak informacji w dokumentacji systemu oraz opisu sposobu realizacji wymagania. Wymaganie 5.23.9.: 5.23.9. RTDB powinna być wyposażona w narzędzie do przeglądania danych oraz interfejs API dla celów programistycznych. Opis zawarty w tabeli w ofercie Odwołującego: Zgodnie z wymaganiami Zamawiającego. (w rubryce „uwagi”: Do celów programistycznych użytkownikowi zostanie udostępniony odpowiedni API systemu SCADA SYNDIS, analogiczny do pkt. 5.22). Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący w ofercie wstępnej poinformował, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono oraz podał informacje dodatkowe poprzez odniesienie do punktu 5.22. W punkcie głównym 5.23 podana została także informacja, jakie oprogramowanie zastanie użyte do realizacji wymagania. 21. Zastrzeżenie: plikacja w kształcie wymaganym przez Zamawiającego nie istnieje, Oferent deklaruje gotowość opracowania i zaimplementowania takiej aplikacji. Deklaracja Oferenta o posiadaniu funkcjonalności rozproszonych po różnych modułach nie jest możliwa do weryfikacji z uwagi na fakt niedostarczenia dokumentacji części modułów, jak SYNDIS OMS i SYNDIS ENERGIA. Ponadto nie przedstawiono w ofercie jakie funkcjonalności wymagane przez Zamawiającego, w jakim miejscu zostały opisane. Część funkcjonalności funkcjonuje wg deklaracji Oferenta w wersji WEB, nieakceptowanej przez Zamawiającego. Oferent nie uwiarygodnił poprzez przedstawienie studium wykonalności realizacji wymagań w postaci oczekiwanej przez Zamawiającego. Wymaganie od 6.1.1. do 6.1.22.: Zadaniem aplikacji jest dokumentowanie informacji, decyzji, poleceń wydanych albo otrzymanych przez dyspozytora itp. Ma służyć ułatwieniu przekazania ich pomiędzy dyspozytorami na kolejnych zmianach, oraz przypominaniu o zaplanowanych działaniach. 6.1.1. W każdej dyspozytorni (5 tłoczni oraz Warszawa) ma działać oddzielny dziennik. Specyficzna pod tym względem jest jedynie dyspozytornia w tłoczni Ciechanów, która pełni również funkcję rezerwowej dyspozytorni ogólnopolskiej. - ma w niej działać zarówno dziennik tłoczni, jak i dziennik dyspozytorni głównej. 6.1.2. Użytkownicy będą uruchamiać aplikację jednocześnie na wielu stanowiskach. 6.1.3. Użytkownicy danego dziennika widzą te same notatki, ale musi być możliwość przypisania im różnych praw dostępu (odczyt bieżących, odczyt archiwalnych, wpisywanie, korygowanie). 6.1.4. Notatki pomiędzy serwerem a aplikacją użytkownika, oraz pomiędzy serwerami, powinny być przesyłane bezzwłocznie. 6.1.5. Proces przesyłania powinien być inicjowany zdarzeniem, a nie odbywać się co jakiś czas. 6.1.6. Aplikacja dziennika dyspozytorskiego nie może być oparta o system poczty elektronicznej, ani wykonana w technologii WWW. 6.1.7. Wpisy do dziennika dyspozytorskiego można wykonywać tylko ze stacji roboczych systemu SCADA SGT. Dla użytkowników pracujących w sieci biurowej lub sieciach zewnętrznych udostępniany jest jedynie podgląd wpisów w dzienniku. 6.1.8. Notatka 6.1.8.1. Każda wprowadzona do dziennika informacja nazywana jest notatką i zawiera takie atrybuty jak: 6.1.8.1.1. kategoria, 6.1.8.1.2. temat 6.1.8.1.3. obiekt 6.1.8.1.4. adresat 6.1.8.1.5. wskazanie na dokument zewnętrzny 6.1.8.1.6. data i godzina rozpoczęcia 6.1.8.1.7. data i godzina zakończenia 6.1.8.1.8. data przydatności 6.1.8.1.9. identyfikator notatki korygowanej 6.1.8.1.10. treść. 6.1.9. Ponadto każda notatka powinna zostać automatycznie opatrzona: datą i godzina zapisania, identyfikatorem (numerem) notatki, identyfikatorem wprowadzającego. 6.1.10. Kategoria 6.1.10.1. Lista kategorii ma być definiowana przez administratora serwera. Przykładowe kategorie to: informacja, awaria, polecenie, pozwolenie na pracę, prace na obiekcie, zakończenie pracy. 6.1.10.2. W celu szybkiego rozróżniania kategorii, każdej kategorii ma być przypisany kolor, który ma być wyróżniany przy wyświetlaniu notatek. 6.1.10.3. Adresowanie notatek. 6.1.10.3.1. Pole adresata może być puste, co oznacza notatkę lokalną (dostępną wyłącznie w danej dyspozytorni), lub wskazywać jedną lub kilka dyspozytorni, do której powinna być przesłana bezzwłocznie. 6.1.10.3.2. Adresatem jest dyspozytornia, jako dziennik/stanowisko pracy, a nie osoba na nim pracująca. 6.1.10.3.3. Notatki odebrane z innego dziennika muszą wskazywać oprócz identyfikatora wprowadzającego, nazwę dziennika(dyspozytorni) z której została wysłana. Uwagi dotyczące przesyłania notatek korygowanych i korygujących opisano na str. 6.1.10.4. Obiekt 6.1.10.4.1. Notatka wskazuje jeden lub więcej obiektów. 6.1.10.4.2. Lista obiektów definiowana jest przez administratora oddzielnie dla każdego dziennika-serwera, ale dyspozytor musi mieć możliwość wpisania obiektu spoza listy. 6.1.10.4.3. W dyspozytorni ogólnopolskiej obiektami są: tłocznie, zespoły zaporowo upustowe, pomiarownie. 6.1.10.4.4. Dla dyspozytorni tłoczni obiektami będą: turbokompresory, podsystemy. 6.1.10.4.5. Z okien dziennika dyspozytorskiego ma dać otworzyć się ekran prezentujący stan obiektu, oraz archiwum dziennika z notatkami tego obiektu (na str. 43). 6.1.10.5. Czas rozpoczęcia i zakończenia: 6.1.10.5.1. Pole zawiera datę i czas z dokładnością do minuty. 6.1.10.5.2. Domyślnie czas zakończenia jest równy czasowi rozpoczęcia - co oznacza brak daty zakończenia. 6.1.10.5.3. Domyślnie data rozpoczęcia wskazuje czas rozpoczęcia wprowadzania notatki. 6.1.10.5.4. Dla notatek korygujących wartość domyślna jest kopiowana z notatki korygowanej. 6.1.10.5.5. W okresie pomiędzy datą rozpoczęcia i zakończenia, notatka ma być wyróżniona pulsowaniem. 6.1.10.6. Czas przydatności. 6.1.10.6.1. Czas przydatności wskazuje, kiedy notatka ma zostać usunięta z listy notatek bieżących (na str. 40). Domyślnie wskazuje czas + 36 godzin od chwili rozpoczęcia edycji notatki. 6.1.10.6.2. Dla notatki korygującej wartość domyślna jest kopiowana z notatki korygowanej i ewentualnie uzupełniana do 36 godzin od chwili obecnej. 6.1.10.6.3. Użytkownik nie powinien być powiadamiany o konieczności przeczytania notatek, których termin przydatności upłynął, nawet jeżeli ich nie przeczytał (np. podczas urlopu). 6.1.10.7. Wskazanie na dokument zewnętrzny. Jest to ścieżka dostępu do pliku (z ewentualnymi parametrami uruchomienia, jeżeli plik jest programem), który ma zostać otwarty (uruchomiony). Najczęściej będą to ewidencje (np. prac gazoniebezpiecznych), harmonogramy prac, instrukcje postępowania, jak również programy do uruchomienia. 6.1.10.8. Notatka korygująca. 6.1.10.8.1. Oprogramowanie powinno uniemożliwiać wymazanie jakiejkolwiek wprowadzonej informacji. 6.1.10.8.2. W celu umożliwienia skorygowania błędu, do każdej notatki może zostać utworzona jedna lub więcej notatek korygujących. 6.1.10.8.3. Notatka korygująca również może zostać ponownie skorygowana. 6.1.10.8.4. Notatka korygująca nie musi oznaczać błędu - pierwsza notatka może zostać wprowadzona np. jako pozwolenie wejścia na obiekt, pierwsza korekta może być zgłoszeniem wejścia na obiekt, a następna zgłoszeniem zakończenia prac i wyjścia z obiektu. 6.1.10.8.5. Każda notatka musi mieć możliwość stworzenia wielu notatek korygujących, co oznacza, że więcej niż jedna notatka korygująca może wskazywać tą samą notatkę korygowaną. Będzie to stosowane np. w celu rozdzielenia notatek. 6.1.10.8.6. W oknie notatki należy zapewnić możliwość poruszania się pomiędzy notatkami korygującymi i skorygowanymi. 6.1.10.8.7. Jeżeli do wyboru jest tylko jedna notatka korygująca, to jej wybór ma nastąpić automatycznie. 6.1.10.8.8. Należy zapewnić budowanie właściwych powiązań korekcyjnych w przypadku notatek przesyłanych pomiędzy dziennikami/dyspozytorniami. W szczególności należy uwzględnić, że: 6.1.10.8.8.1. Notatka która była wcześniej wysłana do innego dziennika, może zostać skorygowana lokalnie (1), a następnie ponownie skorygowana lecz z wysłaniem (3). 6.1.10.8.8.2. Notatka odebrana, podobnie jak każda notatka, może zostać skorygowania lokalnie (2), z możliwością przesłania do innych dzienników (4). 6.1.10.8.8.3. Przy korygowaniu notatki odebranej, ma ona być domyślnie przesłana do pierwotnego dziennika. 6.1.10.8.9. Po korektach w przedstawionym poniżej diagramie, na liście notatek bieżących powinny być notatki wyróżnione podwójną linią (w A:odebrana korekta 4; w B: korekta 4 i korekta 2). Przedstawiono diagram./…/ 6.1.10.9. Formularze/szablony notatek. 6.1.10.9.1. Aplikacja ma umożliwiać definiowanie przez administratora formularzy (szablonów) do wprowadzania notatek. Użytkownik będzie jedynie wypełniał w nim pola, których początkowa zawartość powinna być pobierana z parametrów uruchomienia, oraz uruchomionych w tle programów (np. do pobierania wartości z archiwum, list z rejestrów prac,..). 6.1.10.9.2. Pola w formularzach mają być dostępne pola co najmniej typu: 6.1.10.9.2.1. edycja tekstu, 6.1.10.9.2.2. edycja liczby, 6.1.10.9.2.3. lista, 6.1.10.9.2.4. lista rozwijalna, 6.1.10.9.2.5. lista rozwijalna z edycją. 6.1.10.9.3. Musi istnieć możliwość załadowania nowej listy wartości po dokonaniu wyboru na innej liście, np. lista firm i lista pracowników tej firmy. 6.1.10.9.4. Ma być możliwość wyliczania zawartości pola na podstawie zawartości innych pól, obliczenie to ma następować automatycznie podczas edycji pól źródłowych. Przykładem takich pól może być pole sumy lub przeliczenia na inną jednostkę miary. 6.1.10.9.5. Wykonawca dostarczy wszystkie narzędzia/programy do tworzenia szablonów. 6.1.11. Lista notatek bieżących 6.1.11.1. Domyślne okno aplikacji, które powinno być uruchamiane automatycznie po zalogowaniu się użytkownika, powinno wyświetlać listę notatek bieżących, tj. takich, która data przydatności jeszcze nie upłynęła i do której nie stworzono notatki korygującej. Dla przykładów zilustrowanych na str. 39, na liście notatek bieżących powinny pojawić się notatki 3 i 3A, a dla diagramu na str. 40 w dyspozytorni A powinna być widoczna odebrana korekta 4, a w dyspozytorni B korekta 2 i 4. 6.1.11.2. Notatki nieprzeczytane przez użytkownika (na stanowisku może być kilku użytkowników) powinny zostać wyróżnione pulsowaniem od momentu: uruchomienia dla wszystkich notatek dla których chwila obecna znajduje się pomiędzy czasem rozpoczęcia i zakończenia, wprowadzenia przez innego użytkownika lub odebrania z innej dyspozytorni, nadejścia czasu rozpoczęcia, nadejścia czasu zakończenia. 6.1.11.3. Pulsowanie ma zaniknąć po wybraniu notatki. 6.1.11.4. Użytkownik ma mieć możliwość wybrania, które atrybuty (kolumny) maja być wyświetlane. 6.1.11.5. Notatka, która została oznaczona do wysłania, a nie została potwierdzona przez któregokolwiek dyspozytora (adresata) powinna być wyróżniona symbolem graficznym. Podobnie notatka, która nie została przesłana do któregokolwiek adresata (poniżej). 6.1.11.6. Pobieranie informacji do wyświetlenia musi odbywać się w tle i nie może powodować np. chwilowego czyszczenia ekranu, zmiany wybranych elementów, położenia i wielkości okna programu. 6.1.12. Potwierdzenia notatek. W oknie wyświetlania notatki dostępny ma być przycisk potwierdzenia przeczytania, oraz dostępna ma być lista potwierdzeń. Lista potwierdzeń powinna zawierać: 6.1.12.1. czas potwierdzenia, 6.1.12.2. identyfikator (imię nazwisko) użytkownika, 6.1.12.3. adresata (gdy notatka była adresowana do więcej niż jednego). 6.1.13. Wykres Gantta. Zawartość okna notatek bieżących ma być również prezentowana w formie wykresu Gantta. W wierszach mają być prezentowane kolejne obiekty, natomiast na osi poziomej mają być odwzorowane czasy rozpoczęcia i zakończenia. 6.1.14. Syntezer mowy. Po odebraniu notatki z innej dyspozytorni, powinien zostać uruchomiony program do syntezy mowy, który odczyta wskazane atrybuty notatki. 6.1.15. Zakładki z dodatkowymi ewidencjami. Z dziennika dyspozytorskiego powinny być dostępne dodatkowe ewidencje. 6.1.16. Wydane polecenia Tabela ma posiadać kolumny: Data, Godzina, wydający polecenie, treść polecenia, mechanik, elektryk. 6.1.17. Parametry tłoczni Tabela powinna ma posiadać kolumny: godzina, temperatura otoczenia, wilgotność, ciśnienie (wlot), ciśnienie(wylot), temperatura (wlot), temperatura(wylot), sumaryczny strumień gazu przez agregaty, sumaryczny strumień przez tłocznię, prędkość wiatru. 6.1.17.1. Uwagi o przebiegu zmiany Tabela ma posiadać kolumny: data zdarzenia, godzina, uwaga o przebiegu zmiany, rodzaj węzła. Kolumny uwaga o przebiegu zmiany, rodzaj węzła mają być listami rozwijalnymi. 6.1.17.2. Informacja o pracy TUCO Tabela ma zawierać kolumny: data i godzina wpisu, stan każdego TUCO, P. każdego TUCO, Kolumny TUCO maja być listami rozwijalnymi. 6.1.17.3. Starty i godziny 6.1.17.3.1. Tabela ma być automatycznie uzupełniana danymi z systemu (wartości chwilowe jedną minutę po pełnej godzinie). 6.1.17.3.2. Tabela ma zawierać kolumny: godzina, liczba startów każdego TUCO, godziny normalne każdego TUCO, godziny ekwiwalentne każdego TUCO. 6.1.17.4. Moce turbin 6.1.17.4.1. Tabela ma być automatycznie uzupełniana danymi z systemu (wartości chwilowe jedną minutę po pełnej godzinie). 6.1.17.4.2. Tabela ma zawierać kolumny: godzina, moc na wale każdego TUCO, moc dostępna dla każdego TUCO, moc termodynamiczna dla każdego TUCO. 6.1.17.5. Obroty TUCO 6.1.17.5.1. Tabela ma być automatycznie uzupełniana danymi z systemu (wartości chwilowe jedną minutę po pełnej godzinie). 6.1.17.5.2. Tabela ma zawierać kolumny: Godzina, obroty sprężarki każdego TUCO, obroty turbiny gazowej każdego TUCO, poziom oleju w zbiorniku każdego TUCO. 6.1.18. Archiwum notatek Okno służy do wyświetlania notatek w chronologicznej kolejności wprowadzania. 6.1.18.1. Okno nie może blokować się podczas pobierania notatek z serwera, tj. ostatnio wprowadzone notatki mają być wyświetlane w ciągu 2 sekund. 6.1.18.2. Starsze notatki mają być wczytywane w tle, gdyż serwer musi być przygotowany na przechowywanie kilkuset tysięcy notatek. 6.1.18.3. W oknie notatek ma być dostępne filtrowanie po wybranych lub wszystkich atrybutach notatki. 6.1.18.4. Należy zapewnić także raport, prezentujący wszystkie powiązane ze sobą notatki korygujące i korygowane. Uwzględniający możliwość rozdzielenia korekt zilustrowane na stronie na str. 39. 6.1.19. Raport zmiany Raport zbierający informacje z wielu notatek, dotyczących przebiegu zmiany, według szablonu pt. Dziennik dyspozytorski. Szablon nieznacznie różni się na każdej tłoczni gazu (np. ilość turbokompresorów). 6.1.20. Parametry uruchomienia. 6.1.20.1. Poprzez podanie parametrów uruchomienia, aplikacja powinna umożliwiać: 6.1.20.1.1. wyświetlenie notatki o podanym identyfikatorze, 6.1.20.1.2. otwarcie dialogu do wprowadzania notatki z wartościami atrybutów podanymi jako parametry uruchomienia. 6.1.20.1.3. otwarcie szablonu do wprowadzania notatki z wartościami pól podanymi jako parametry uruchomienia. 6.1.20.1.4. wyświetlenie okna archiwum z zadanymi filtrami, 6.1.20.1.5. import notatek z pliku CSV. 6.1.20.2. Wywoływanie z parametrami będzie wykonywane co najmniej z okna ekranów procesowych opisanych. 6.1.20.3. W oknie notatki oraz z listy notatek powinna istnieć możliwość uruchamiania programów zdefiniowanych przez administratora. 6.1.20.4. Należy zapewnić możliwość podawania jako parametry uruchomienia zmiennych środowiskowych, w których mają być umieszczone wartości atrybutów wybranej notatki. 6.1.20.5. Zawartość dziennika powinna dać się eksportować do pliku tekstowego. 6.1.21. Serwer równoległy. 6.1.21.1. Dla każdego serwera dziennika dyspozytorskiego ma być możliwość zdefiniowanie serwera równoległego, z którym serwer będzie synchronizował notatki (również lokalne). Notatka wprowadzona na jeden serwer, powinna bezzwłocznie skopiowana na drugi serwer, oraz odwrotnie. 6.1.21.2. W przypadku braku komunikacji pomiędzy serwerami, po jej przywróceniu ma nastąpić wzajemne uzupełnienie notatek. 6.1.21.3. Para takich serwerów będzie stała w Warszawie (Dyspozytornia Ogólnopolska) i Ciechanowie (Rezerwowa Dyspozytornia Ogólnopolska). 6.1.22. Import notatek W ramach dostawy wykonawca jest zobowiązany do przeniesienie notatek z obecnych dzienników dyspozytorskich. W warszawie w dzienniku dyspozytorskim jest ok. 100000 notatek, które będą przekazane w pliku CSV. Opis zawarty w tabeli w ofercie Odwołującego: Obecna wersja produkcyjna systemu SCADA SYNDIS posiada wymagane funkcjonalności rozproszone na wielu modułach systemowych, w tym także na modułach wykorzystujących technologię WWW, np. SYNDIS OMS, SYNDIS ENERGIA. W związku z zastrzeżeniem Zamawiającego, związanym z niedopuszczeniem do wykonania funkcjonalności Dziennika dyspozytorskiego w technologii WWW, wszystkie wymagane funkcjonalności zostaną zaimplementowane do nowego modułu aplikacji dziennika operatorskiego, który zostanie zainstalowany na serwerach aplikacji dodatkowych. Jako syntezator mowy zostanie zintegrowany z Dzielnikiem dyspozytorskim moduł aplikacji IVONA. Serwer aplikacja Dziennika dyspozytorskiego będzie umożliwiał pracę równoległą z drugim dziennikiem - zgodnie z wymaganiami para takich serwerów będzie stała w Warszawie (Dyspozytornia Ogólnopolska) i Ciechanowie (Rezerwowa Dyspozytornia Ogólnopolska). W ramach realizacji zadania notatki z istniejących dzienników dyspozytorskich zostaną przeniesione do nowej stworzonej aplikacji Dziennika dyspozytorskiego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że oprogramowanie SYNDIS zostanie rozbudowane do wymagań Zamawiającego bez odstępstw. Poinformował również, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Podano także dodatkowe informacje, jakiego typu oprogramowanie zostanie użyte w celu realizacji wymagania. Ponadto w załączonej do oferty dokumentacji systemu SYNDIS opisano możliwości i sposób działania standardowych funkcji przedmiotowej funkcjonalności. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zarzut braku dokumentacji opisującej jest bezpodstawny, ponieważ Zamawiający żądał jedynie podręczników użytkownika modułów standardowych proponowanych aplikacji. Przedmiotowa funkcjonalność nie stanowi standardowego modułu i nie jest oparta o standardowe moduły, więc oferta nie zawiera podręcznika dla tego zakresu. Zarzut, iż Oferent nie uwiarygodnił poprzez przedstawienie studium wykonalności realizacji wymagań w postaci oczekiwanej przez Zamawiającego, jest bezpodstawny, ponieważ studium wykonalności nie było wymagane w ofercie wstępnej. Uwaga Zamawiającego dotycząca wersji WEB jest bezprzedmiotowa, ponieważ Odwołujący jednoznacznie stwierdziła, że funkcjonalności dostępne w systemie SYNDIS w technologii WWW zostaną zaimplementowane do nowego modułu. 22. Zastrzeżenie: Oferent nie przedstawił sposobu realizacji wymagań w tym zakresie. Dostarczona dokumentacja systemu nie odnosi się w żaden sposób do oprogramowania SIMONE, w tym nie opisuje sposobu integracji systemu SYNDIS z tym oprogramowaniem. Wymaganie od 6.2.1. do 6.2.6.: 6.2.1. Dostawca dokona uaktualnienia istniejącego oprogramowania SIMONE firmy LIWACOM do najnowszej wersji znajdującej się na rynku na dzień wdrożenia oprogramowania. 6.2.2. Oprogramowanie będzie zainstalowane w dwóch lokalizacjach: Dyspozytorni Głównej EuRoPol GAZ w Warszawie ( dwa stanowiska ) i Dyspozytorni Rezerwowej - Tłocznia Gazu Ciechanów (jedno stanowisko ). Będzie ono dostępne na oddzielnych stanowiskach roboczych jemu dedykowanych. 6.2.3. Program do symulacji Program przeznaczony jest do modelowania pracy gazociągu tranzytowego w stanach nie¬ustalonych w trybie on-line, oraz w stanach ustalonych i nieustalonych w trybie off-line, a także jako program do planowania ruchu na SGT. Wymagania funkcjonalne: 6.2.3.1. Model matematyczny wykorzystywany do symulacji powinien zawierać równania transportu masy, pędu i energii oraz równanie stanu, uwzględniające współczynnik ściśliwości obliczany wg metody SGERG 88. 6.2.3.2. Współczynnik oporu hydraulicznego powinien być obliczany na podstawie liczby Reynoldsa (w całym zakresie przepływów laminarnych i burzliwych ) oraz szorstkości ścianki rurociągu. 6.2.3.3. Metoda rozwiązywania równań powinna gwarantować stabilność dla wszelkich rodzajów obciążeń. 6.2.3.4. Oprogramowanie powinno umożliwiać symulację współbieżną w czasie rzeczywistym, w stanach nieustalonych. 6.2.3.5. Rezultaty modelowania ( trajektorie ciśnień, strumieni, temperatur ) powinny być wizualizowane na monitorze stanowiska SIMONE, w postaci tabel i wykresów na których pokazane są wyniki obliczeń i pomiarów. 6.2.3.6. Należy zapewnić wydruk wykresów i tabel oraz schematów modelowanych układów. 6.2.3.7. Oprogramowanie do rekonstrukcji stanu musi zapewnić rekonstrukcję z dokładnością: 6.2.3.7.1. przy braku ciśnienia z dowolnego jednego punktu pomiarowego: 0,02MPa 6.2.3.7.2. przy braku temperatury z jednego punktu pomiarowego: 0.50C 6.2.3.7.3. przy braku ciśnienia z całego odcinka pomiędzy tłoczniami: 0,05MPa 6.2.3.7.4. przy braku temperatury z całego odcinka pomiarowego: 0,80C 6.2.3.7.5. wykrywać nieprawidłowe wskazania ciśnienia, w przypadku odchyłki większej niż 0,04MPa. 6.2.3.7.6. przy braku wartości strumienia w punktach wyjścia, dopuszczalna różnica pomiędzy wynikiem symulacji a wartością rzeczywistą nie może przekroczyć 0,5% maksymalnej przepustowością punktu. 6.2.3.8. W celu sprawdzenia dokładności, do symulatora zostaną wprowadzone dane archiwalne, a wyniki obliczeń symulatora porównane a z danymi archiwalnymi. 6.2.3.9. Analiza stanów nieustalonych dla prognozy 24 h ma zapewnić prognozę ciśnień z dokładnością nie gorszą niż 0,05MPa. 6.2.3.10. Oprogramowanie powinno umożliwiać symulację off-line stanów ustalonych i nieustalonych. W tym trybie program pobiera dane o elementach systemu z Bazy Danych Archiwalnych. Obciążenia lub krzywe obciążeń w przypadku stanów nieustalonych. Warunki brzegowe i początkowe oraz czasy włączania lub wyłączania elementów systemu wprowadzane są ręcznie. 6.2.3.11. Należy zapewnić możliwość zapisania krzywych obciążeń w węzłach sieci w bazie danych i ponownego ich wykorzystania. 6.2.3.12. Oprogramowanie powinno umożliwiać symulację z wykorzystaniem prognozy (tzw. Look ahead). W tym trybie program generuje prognozę poborów gazu z horyzontem określonym przez użytkownika. Rezultaty modelowania winny być wizualizowane na monitorze stanowiska SIMONE w postaci tabel i wykresów. 6.2.3.13. Należy zapewnić możliwość wydruku rezultatów prognozy. 6.2.3.14. Kryterium prawidłowego działania programu będzie porównanie otrzymanych wyników przeprowadzonej symulacji z rzeczywistym przepływem z okresu doby. Dopuszczalna różnica pomiędzy wynikiem symulacji a wartością rzeczywistą nie może przekroczyć 0,5% maksymalnej przepustowością punktu. 6.2.3.15. Oprogramowanie umożliwiające obliczanie akumulacji gazu w gazociągu z podziałem na odcinki pomiędzy tłoczniami gazu jak również w całym gazociągu. Wartość akumulacji oraz jej zmiana powinna być obliczana i prezentowana w procesach symulacji współbieżnej i prognozy (Look ahead). Program powinien umożliwiać obliczanie przyrostu objętości gazu w gazociągu przy określonych przez operatora warunkach brzegowych. 6.2.3.16. Oprogramowanie umożliwi wizualizację polskiego odcinka SGT wraz z całą armaturą na nim zainstalowaną jak również stany elementów nierurowych. 6.2.3.17. Dla wszystkich turbokompresorów będzie wykonana aproksymacja charakterystyk agregatów danych w formie graficznej w układzie; przepływ - ciśnienie, przepływ - stopień sprężu, uwzględniające: ograniczenie od linii pompażu, ograniczenie od linii minimalnych obrotów, ograniczenie od linii maksymalnych obrotów, Parametry: współczynnik sprężu, temperatury gazu na ssaniu,temperatury gazu na tłoczeniu, temperatury gazu za chłodnicami, obroty, moc termodynamiczna, moc dyspozycyjna, zużycie gazu paliwowego, temperatura spalin. 6.2.4. Program powinien umożliwiać wybór przez operatora jednostek miary masy, objętości, energii, składu gazu, temperatury i ciśnienia oraz wybór warunków odniesienia (00C, 200C). 6.2.5. Oprogramowanie do optymalizacji. 6.2.5.1. Oprogramowanie do optymalizacji ma służyć jako narzędzie do znajdowania najbardziej korzystnych parametrów pracy SGT w warunkach stacjonarnych i niestacjonarnych, (oprogramowanie działające w trybie of-line). 6.2.5.2. Poprzez wykonanie zadania optymalizacji uważa się określenie tłoczni gazu które powinny pracować w celu wypełnienia zadania transportowego, ilości agregatów turbosprężających oraz wartości nastaw ciśnień. 6.2.5.3. Jako kryterium optymalizacji należy przyjąć minimalizację pracujących tłoczni gazu jak również turbin w nich pracujących z możliwie zbliżonymi wartościami obciążeń, oraz zużycie gazu paliwowego dla turbin. 6.2.5.4. Kryterium optymalizacji powinno być wybierane opcjonalnie przez użytkownika. 6.2.6. Usługi związane z dostawą: Usługi związane z dostawą obejmują: 6.2.6.1. Zainstalowanie oprogramowania i konfigurowanie interfejsów do pobierania danych bieżących i archiwalnych ze SCADA, 6.2.6.2. Pobieranie danych o nominacjach z oprogramowania do zarządzania kontraktami, 6.2.6.3. Dostarczone oprogramowanie wersji polskojęzycznej, 6.2.6.4. Dostawca wykona strojenie modelu matematycznego do warunków rzeczywistych, uwzględniających: 6.2.6.4.1. Elementy nierurowe systemu takie jak: turbokompresory, główne zawory regulacyjne tłoczni, chłodnice gazu. 6.2.6.4.2. Charakterystyki turbokompresorów i zaworów regulacyjnych oraz model chłodnic. Dokumenty te dostarczy Zleceniodawca w formie papierowej lub elektronicznej w formacie PDF. ( Zabrania się kopiowania lub udostępniania osobom trzecim powyższych dokumentów). 6.2.6.4.3. Oprogramowanie będzie uwzględniało czynniki środowiska zewnętrznego takie jak: temperatura otoczenia i wilgotność, jak również ograniczenie pracy maszyn wynikające z temperatury spalin. 6.2.6.5. Wykonawca zapewni integrację z aplikacją główną minimum w zakresie: prezentacji na ekranach sys. SCADA wybranych danych z rekonstrukcji stanu, wyliczenia akumulacji gazu, symulowanych trendów dla ciśnień i przepływów w wybranych punktach geograficznych. Wybór parametrów zostanie dokonany na etapie projektowania ekranów sys. SCADA SGT, 6.2.6.6. Pięciodniowe szkolenie dla sześciu pracowników w ośrodku autoryzowanym przez LIVACOM, 6.2.6.7. Serwis oprogramowania w okresie gwarancyjnym i pogwarancyjnym. 6.2.6.8. W zakresie komunikacji z programem należy zapewnić: 6.2.6.8.1. wielookienkowość, przy możliwości przesuwania, zmiany wymiarów, przenoszenia do ikony, przywracania, zamykania, ukrywania, 6.2.6.8.2. menu rozwijalne i zwijalne, 6.2.6.8.3. możliwość podziału na „n” logicznych ekranów, 6.2.6.8.4. paski przewijania, zooming wraz z selekcją informacji graficznej i alfanumerycznej odpowiednio do skali. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA dokona uaktualnienia istniejącego oprogramowania SIMONE firmy LIWACOM do najnowszej wersji znajdującej się na rynku na dzień wdrożenia oprogramowania. Oprogramowanie będzie zainstalowane w dwóch lokalizacjach: Dyspozytorni Głównej EuRoPol GAZ w Warszawie (dwa stanowiska) i Dyspozytorni Rezerwowej - Tłocznia Gazu Ciechanów (jedno stanowisko). Będzie ono dostępne na oddzielnych stanowiskach roboczych jemu dedykowanych. Oprogramowanie zostanie dopasowane do wymaganych funkcjonalności Zamawiającego. W ramach realizacji zadania MIKRONIKA zapewni: Zainstalowanie oprogramowania i konfigurowanie interfejsów do pobierania danych bieżących i archiwalnych ze SCADA SYNDIS, Pobieranie danych o nominacjach z oprogramowania do zarządzania kontraktami, Dostarczenie oprogramowanie wersji polskojęzycznej, Wykonanie strojenia modelu matematycznego do warunków rzeczywistych, uwzględniających: Elementy nierurowe systemu takie jak: turbokompresory, główne zawory regulacyjne tłoczni, chłodnice gazu. Charakterystyki turbokompresorów i zaworów regulacyjnych oraz model chłodnic na podstawie dostarczonych przez Zamawiającego dokumentów. Czynniki środowiska zewnętrznego takie jak: temperatura otoczenia i wilgotność, jak również ograniczenie pracy maszyn wynikające z temperatury spalin. MIKRONIKA zapewni integrację z aplikacją główną systemu SCADA SYNDIS minimum w zakresie: Prezentacji na ekranach systemu SCADA SYNDIS wybranych danych z rekonstrukcji stanu. Wyliczenia akumulacji gazu symulowanych trendów dla ciśnień i przepływów w wybranych punktach geograficznych. Wybór parametrów zostanie dokonany na etapie projektowania ekranów systemu SCADA SGT, MIKRONIKA zapewni pięciodniowe szkolenie dla sześciu pracowników w ośrodku autoryzowanym przez LIVACOM oraz serwis oprogramowania w okresie gwarancyjnym i pogwarancyjnym. W zakresie komunikacji z programem MIKRONIKA zapewni: Wielookienkowość, przy możliwości przesuwania, zmiany wymiarów, przenoszenia do ikony, przywracania, zamykania, ukrywania. Menu rozwijalne i zwijalne. Możliwość podziału na „n” logicznych ekranów. Paski przewijania, zooming wraz z selekcją informacji graficznej i alfanumerycznej odpowiednio do skali. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Zarzuty Zamawiającego są bezpodstawne. Przedstawiony w tabeli krótki opis zawiera istotne informacje dotyczące integracji, np. minimalny zakres integracji z aplikacją główną systemu SYNDIS, zakres prezentacji danych z systemu SIMONE w systemie SYNDIS, sposób osadzenia programu SIMONE w środowisku systemu SCADA itp. Dostarczona dokumentacja systemu nie odnosi się w żaden sposób do oprogramowania SIMONE, ponieważ nie jest to funkcjonalność standardowa, a tylko w zakresie takich funkcjonalności Zamawiający wyraził wolę otrzymania dokumentacji. Opis sposobu integracji systemu SYNDIS z najnowszą wersją systemu LIN/ACOM dostępną w momencie wdrażania będzie mógł być, co oczywiste, zaprojektowany i przedstawiony dopiero w momencie wdrażania systemu. Odwołujący nie ma wpływu na rozwiązania zastosowane w programie SIMONE, wskazanym do zastosowania przez Zamawiającego, w wersji, która ma być przedmiotem dostawy, wobec czego nie może na etapie oferty wstępnej podawać wiążących informacji co do szczegółów związanych z realizacją tej funkcjonalności, będących następstwem nieznanych obecnie właściwości wersji programu SIMONE, którą można by nawet uznać obecnie za jeszcze nieistniejącą. Dodatkowo w opisie realizacji dla punktów 5.1.10-5.1.12 SIWZ Odwołujący zawarł informacje o możliwych mechanizmach współpracy systemu SYNDIS z systemami/aplikacjami zewnętrznymi. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 23. Zastrzeżenie: Oferent nie przedstawił sposobu realizacji wymagań w zakresie funkcjonalnym. Dostarczona dokumentacja nie opisuje oprogramowania w zakresie funkcjonalności „Rozliczanie kontraktów”. Wymaganie od 6.3.1. do 6.3.8.: Zadaniem oprogramowania jest przyjmowanie planu (nominacje, renominacje ilości gazu do przesłania), dynamiczny sygnalizować jego realizacji, oraz przygotowanie danych do rozliczeń z ilości i jakości przetransportowanego gazu. 6.3.1. Ponieważ pomiary oraz wprowadzane wartości odnoszą się do różnych warunków pomiarowych (w szczególności temperatury przy określaniu ilości gazu) Wykonawca musi zapewnić przeliczanie tych pomiarów pomiędzy: warunkami roboczymi, normalnymi (0°C; 101,325kPa), kontraktowymi (20°C; 101,325kPa), ilością energii (kWh) uwzględniając ciepło spalania podane przez użytkownika lub z archiwum (dla tego samego czasu). 6.3.2. W przypadku braku danych o strumieniu energii przeliczenie należy wykonać w oparciu aktualny strumień objętości i ciepło spalania 0/25 zgodnie ze wzorem: Qe=Qb(Hs[kW] QE - strumień energii [kW], Qb - strumień objętości w warunkach OoC i 0,101325MPa [m3/h] Hs - ciepło spalania dla warunków spalania 25°C dla warunków objętości 0°C i 0,101325MPa [kWh/m3]. 6.3.3. Oprogramowanie musi uwzględniać, że doba rozliczeniowa nie pokrywa się z dobą kalendarzową i obecnie rozpoczyna się i kończy o godzinie 8:00 czasu letniego i zimowego. 6.3.4. Jednak oprogramowanie ma umożliwiać ustawienia innej godziny rozliczeniowej, oraz ustawienia jej względem czasu uniwersalnego (bez przesunięcia na czas letni). 6.3.5. Wyłącznie uprawnieni użytkownicy (oraz grupy użytkowników) mają mieć prawo: wprowadzania nominacji i denominacji, odczytu danych rozliczeniowych, tworzenia i modyfikacji protokołów zdawczo odbiorczych. 6.3.6. Z okien programów, użytkownik ma mieć możliwość: 6.3.6.1. otwarcia ekranu procesowego odpowiedniej pomiarowni, 6.3.6.2. otwarcia wykresu (zawierającego w szczególności krzywe nominacji, realizacji 1 rozliczenia), 6.3.6.3. eksportu danych do plików CSV i RTF 6.3.6.4. kopiowania do/z arkusza kalkulacyjnego, 6.3.6.5. drukowania. 6.3.7. Nominacje i renominacje 6.3.7.1. Zadaniem tej części aplikacji będzie przyjmowanie zaplanowanych ilości gazu do transportu (nominacji). Codziennie, przed rozpoczęciem doby rozliczeniowej otrzymywane są ilości gazu do przesłania (nominacje). Ilości gazu podawane są w odniesieniu do warunków kontraktowych. 6.3.7.2. Oprogramowanie ma być również przygotowane na możliwość wprowadzania nominacji godzinowych. 6.3.7.3. Nominacje mogą ulec zmianie w trakcie doby rozliczeniowej (renominacje). 6.3.7.4. Oprogramowanie ma umożliwiać pobierania danych o nominacjach/renominacjach z systemów zewnętrznych za pośrednictwem oprogramowania dostarczonego przez Wykonawcę. 6.3.7.5. Oprogramowanie ma umożliwiać wprowadzanie ręcznie nominacji, wprowadzania korekt w trakcie doby rozliczeniowej i po jej zakończeniu. 6.3.7.6. Wykonawca zaproponuje rozwiązania pozwalające na identyfikowanie nadawcy, kontrolę integralności danych przesyłanych w postaci plików. 6.3.7.7. Oprogramowania musi obsługiwać pobieranie, wysyłanie i zatwierdzanie nominacji w następujących formatach: Edigas (Edig@s Message Implementation Guidelines) txt, XML. 6.3.7.8. Monitorowanie realizacji planu 6.3.7.9. Zadaniem oprogramowania jest podpowiadanie dyspozytorom (operatorowi) takich nastaw urządzeń, aby ilości przesłanego gazu były jak najbliższe planom (nominacjom, renominacjom). Ekrany prezentujące informacje do monitorowania realizacji planów transportu gazu muszą być dostępne na stacjach roboczych sys. SCADA SGT. 6.3.7.10. Urządzenia pomiarowe zainstalowane w pomiarowniach najczęściej mierzą ilości gazu w odniesieniu do warunków normalnych, oraz przeliczają ja na ilość energii. Oprogramowanie musi uwzględnić, że w dniach, kiedy następuje zmiana pomiędzy czasem letnim i zimowym, doba rozliczeniowa trwa odpowiednio 23 lub 25 godzin (w odróżnieniu od 24 godzin w pozostałe dni roku). Nominacje podawane są na dzień, ale urządzenia pomiarowe mierzą w jednostkach na godzinę. 6.3.8. Protokół zdawczo odbiorczy. 6.3.8.1. Oprogramowanie ma umożliwiać przygotowanie protokołów zdawczo- odbiorczych, w których wartości domyślne pobierane są z archiwum fizycznych pomiarów. 6.3.8.2. Wartości mogą zostać zmienione przez użytkownika: np. z uwagi na ilości gazu naliczonego w czasie kalibracji urządzeń, ustalenia z kontrahentami, w szczególności ustalenia ilości gazu w przypadku braku fizycznego pomiaru lub niedotrzymania parametrów jakościowych, itp. 6.3.8.3. System ma umożliwiać ustalenie, kto i kiedy dokonał zmian wartości rozliczeniowych. 6.3.8.4. Raporty wyższego poziomu mają pobierać wartości z zatwierdzonych protokołów niższego poziomu (np. miesięczne z dobowych, roczne z miesięcznych). 6.3.8.5. System powinien umożliwiać porównywanie wartości rozliczeniowych, nominacji i fizycznie zmierzonych, w szczególności wyliczać ich różnicę. 6.3.8.6. Wszystkie wydrukowane protokoły mają być zachowywane w postaci pliku, a oprogramowanie ma umożliwiać podgląd wcześniejszej wersji protokołu. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA wykona i wdroży aplikację serwera oprogramowanie Rozliczania kontraktów zgodnie z wymaganiami i wytycznymi Zamawiającego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, 24. Zastrzeżenie: Oferent nie przedstawił sposobu realizacji wymagań w zakresie funkcjonalnym. Dostarczona dokumentacja nie opisuje oprogramowania w zakresie funkcjonalności „Rozliczanie kontraktów”. Wymaganie od 6.4.1. do 6.4.16.: 6.4.1. Oprogramowanie ma obliczać ilość gazu w poszczególnych odcinkach gazociągu. Wyniki mają być dostępne podobnie jak inne pomiary, również jako wykresy. 6.4.2. akumulacja powinna być wyznaczana na podstawie średniego ciśnienia w gazociągu pomiędzy ZZU, średniej temperatury, wyznaczonego współczynnika ściśliwości i objętości geometrycznej odcinka; 6.4.3. wyliczenie ciśnienia średniego powinno odbywać się w oparciu o algorytm wyznaczania średniego ciśnienia gazu dla gazociągów wysokociśnieniowych 6.4.4. wyliczanie średniej temperatury - średnia arytmetyczna 6.4.5. wyznaczanie współczynnika ściśliwości w oparciu o algorytm SGERG i AGA - NX19MOD (opcjonalny wybór przez użytkownika) na podstawie ciśnienia średniego, temperatury średniej i aktualnego składu gazu. 6.4.6. Zgodnie z załączonymi wzorami akumulacja powinna być obliczana opcjonalnie dla: - dla odcinków między ZZU potem powinna być zsumowana na odcinkach pomiędzy tłoczniami, a następnie dla całego gazociągu. - dla odcinków między tłoczniami potem powinna być zsumowana dla całe-go gazociągu. Wybór opcji dokonywany jest z poziomu stacji roboczej przez użytkownika. 6.4.7. System powinien zapewnić prezentacje danych źródłowych do wyliczeń i możliwość wprowadzania ręcznie korekt. 6.4.8. Wyliczenia powinny być prezentowane w formie graficznej i archiwizowane w systemie. 6.4.9. Akumulacja powinna być obliczana on-line, 6.4.10. Zmiany akumulacji powinny być określane za okresy: 5 min, godzina, doba, - miesiąc. 6.4.11. Wyniki obliczeń akumulacji i jej zmian powinny być prezentowane w postaci graficznej i tabelarycznej i archiwizowane co: 5 min, godzina, doba, miesiąc. 6.4.12. Wyniki obliczeń akumulacji oraz przyrosty być zapisywane w bazach danych. 6.4.13. Powinna być opcja wyboru uwzględniania odcinków dla przejść gazociągu pod rzekami dwoma nitkami - wybór do obliczeń jednej lub dwóch nitek dla każdego przejścia oddzielnie. 6.4.14. Algorytm powinien uwzględniać odcinek gazociągu od granicy polsko- niemieckiej do Mallnow. 6.4.15. Oprogramowanie powinno zapewniać wyznaczanie prędkości przepływu gazu w poszczególnych odcinkach. 6.4.16. Akumulacja w gazociągu powinna być wyliczana zgodnie ze wzorami(…) Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA wykona i wdroży aplikację oprogramowanie Wyznaczania akumulacji gazu zgodnie z wymaganiami i wytycznymi Zamawiającego. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony 25. Zastrzeżenie: Brak listy autoryzowanych punktów serwisowych Wymaganie 8.1.14: Dostawca zobowiązany jest dostarczyć listę autoryzowanych punktów serwisowych na terenie Polski, które świadczą serwis pogwarancyjny. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA zapewni listę autoryzowanych punktów serwisowych na terenie Polski, które świadczą serwis pogwarancyjny dostarczonego sprzętu. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Zamawiający nie żądał listy autoryzowanych punktów serwisowych Dostawcy (zwrócić należy uwagę, że nie: Wykonawcy, Producenta - tylko Dostawcy) w ofercie wstępnej, a jedynie potwierdzenia zrealizowania tej funkcjonalności i sposobu jej realizacji. Odwołujący opisał, że zrealizuje to wymaganie poprzez samodzielne dostarczenie listy Zamawiającemu. Informacja ta stanowi krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Na marginesie należy dodać, że na etapie oferty wstępnej, kiedy nie określa się szczegółowo numerów katalogowych sprzętu, nie ma możliwości określenia punktów serwisowych, ponieważ punkty serwisowe świadczą usługi w zakresie konkretnych wyrobów dostarczanych z konkretnego zakładu przez konkretnego dostawcę, dlatego ich podanie jest możliwe dopiero po ustaleniu w projekcie konkretnych numerów katalogowych i ustaleniu dostawcy. 26. Zastrzeżenie: Brak propozycji urządzeń spełniających min. wymagania SIWZ. Wymaganie 8.2.: UPS-y AC, spełniające poniższe założenia należy zainstalować w obiektach: Szamotuły, Włocławek, Ciechanów, Zambrów, Kondratki. Instalacja UPS musi obejmować swoim zakresem dystrybucję zasilania. Opis zawarty w tabeli w ofercie Odwołującego: W ramach zamówienia MIKRONIKA dostarczy i zainstaluje UPS-y firmy EATON o odpowiednich parametrach technicznych w obiektach Szamotuły, Włocławek, Ciechanów, Zambrów, Kondratki. Instalacja UPS będzie obejmować swoim zakresem dystrybucję zasilania. Wszystkie UPS’y będą wymieniać dane z systemem SCADA po protokole SNMP v3. Oferowany system SCADA SYNDIS zapewnia rejestrację i wyświetlanie na zbudowanych maskach ekranowych takich parametrów pracy urządzenia UPS jak stan sieci po stronie pierwotnej i wtórnej, obciążenie, stan naładowania i temperatura baterii oraz alarmy wewnętrzne z urządzenia. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Dla urządzeń, których dobór wymaga przeprowadzenia analiz i projektu, czyli czynności, które stanowią element zamówienia, wskazano jedynie przewidywanego producenta. Do urządzeń takich należy UPS, dla którego Zamawiający podał moc minimalną. Moc wymagana urządzenia, będąca podstawą doboru typu, może być określona dopiero na etapie projektu, po zbilansowaniu wszystkich potrzeb w tym zakresie. Ustalenie mocy maksymalnej jest warunkiem ustalenia typu zastosowanego urządzenia, dla zapewnienia gwarantowanego czasu zasilania, który został również określony jako parametr minimalny. Odwołujący w ramach krótkiego opisu realizacji funkcjonalności tego punktu wskazał, że dostarczy i zainstaluje UPS-y firmy EATON o odpowiednich parametrach technicznych w obiektach Szamotuły, Włocławek, Ciechanów, Zambrów, Kondratki. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, 27. Zastrzeżenie: Brak propozycji urządzeń spełniających min. wymagania SIWZ. Wymaganie 8.2.1.. 8.2.2.. 8.2.3.. 8.2.4.. 8.2.5.. 8.2.6.. 8.2.7., 8.2.8.. 8.2.9.. 8.2.10., 8.2.11.. 8.2.12.. 8.2.13.. 8.2.14.. 8.2.14.1.. 8.2.14.9.. 8.2.15.: 8.2.1. Zasilanie 3 fazowe z wyjściem 1 fazowym, pozwalające na pracę urządzenia bez użycia baterii przy zaniku jednej z faz napięcia zasilającego 8.2.2. Minimalna moc 10 KW 8.2.3. Obudowa do instalacji w szafie rakowej w raz z szafą w standardzie 19” 8.2.4. Baterie zainstalowane na stojakach zewnętrznych 8.2.5. Galwaniczna izolacja wejścia - wyjścia 8.2.6. Budowa modułowa z możliwością wymiany uszkodzonego modułu mocy bez przerwy napięcia gwarantowanego na wyjściu urządzenia 8.2.7. Zastosowanie w pełni redundantnej architektury n+1 z podwójną konwersją (true on-line) 8.2.8. Sprawność minimum 90% 8.2.9. Dopuszczalna temperatura pomieszczenia pracy w zakresie od 0 - 40°C 8.2.10. Dopuszczalna temperatura pomieszczenia pracy w zakresie od 0 - 40°C 8.2.11. Współczynnik THDI poniżej 5% 8.2.12. Tolerancja napięcia wejściowego: minimum -20% - +15% przy 100% obciążeniu urządzenia 8.2.13. Możliwość rozbudowy w dostarczonej obudowie w przypadku wzrostu zapotrzebowania na moc gwarantowaną 8.2.14. Moduł komunikacji z UPS, z wyświetlaczem pozwalający na: 8.2.14.1. Kontrolę aktualnego stanu pracy urządzenia 8.2.14.2. Pomiar i prezentacje wejściowych i wyjściowych prądów, napięć , mocy i czasu pracy - przy pracy z baterii. 8.2.14.3. Możliwość doinstalowania dodatkowej ładowarki baterii pozwalającej na szybsze doładowanie baterii. 8.2.14.4. Stały nadzór nad stanem urządzenia i baterii. 8.2.14.5. Możliwość przeprowadzenia testu funkcjonalnego baterii akumulatorów. 8.2.14.6. By-pass automatyczny oraz ręczny, zewnętrzny. 8.2.14.7. Moduł do nadzoru SNMP v3 8.2.14.8. Możliwość wymiany baterii „na gorąco”- bez konieczności wyłączenia urządzenia i odbiorów. 8.2.14.9. Wyjście napięcia gwarantowanego na odbiory poprzez zabudowaną w szafie rozdzielnice odbiorową wraz z zabezpieczeniami przepięciowymi i przeciążeniowymi poszczególnych odbiorów 8.2.15. Czas podtrzymania z baterii przy pełnym obciążeniu 30 minut Wszystkie UPS’y powinny wymieniać dane z systemem SCADA po protokole SNMP v3. SCADA musi rejestrować i wyświetlać na zbudowanych maskach ekranowych takie parametry pracy UPS’a jak: stan sieci po stronie pierwotnej i wtórnej, obciążenie, stan naładowania i temperatura baterii oraz alarmy wewnętrzne z urządzenia. Opis zawarty w tabeli w ofercie Odwołującego: W ramach realizacji zamówienia Zamawiającemu zostaną dostarczone urządzenia firmy EATON o parametrach co najmniej spełniających wymagania Zamawiającego. Dokładna Specyfikacja zostanie podana w ofercie ostatecznej, będącej wynikiem ustaleń negocjacyjnych. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Dla urządzeń, których dobór wymaga przeprowadzenia analiz i projektu, czyli czynności, które stanowią element zamówienia, wskazano jedynie przewidywanego producenta. Do urządzeń takich należy UPS, dla którego Zamawiający podał moc minimalną. Moc wymagana urządzenia, będąca podstawą doboru typu, może być określona dopiero na etapie projektu, po zbilansowaniu wszystkich potrzeb w tym zakresie. Ustalenie mocy maksymalnej jest warunkiem ustalenia typu zastosowanego urządzenia, dla zapewnienia gwarantowanego czasu zasilania, który został również określony jako parametr minimalny. Odwołujący w ramach krótkiego opisu realizacji funkcjonalności tego punktu wskazał, że dostarczy i zainstaluje UPS-y firmy EATON o odpowiednich parametrach technicznych. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. 28. Zastrzeżenie: Brak opisu propozycji/sposobu realizacji wymagań SIWZ. Wymaganie od 8.3.1. do 8.3.22.: 8.3.1. Każdy z serwerów musi być wyposażony w nie mniej niż 2 procesory 64- bitowe sześciordzeniowe 8.3.2. Procesory każdego z serwerów aplikacji muszą zapewniać w sumie wydajność dającą wynik Baseline co najmniej na poziomie 250 punktów, według standardowego testu SPECfp_rate2006 (www.spec.org) 8.3.3. Co najmniej 96GB pamięci operacyjnej RAM dla każdego z serwerów o parametrach minimum DDR3 1333MHz 8.3.4. Każdy z serwerów musi być wyposażony w minimum 4 x 300 GB dyski twarde SAS, napęd DVD typu +/- RW 8.3.5. Karta grafiki wysokiej rozdzielczości min. 1600 x 1200 8.3.6. Min. 2 redundantne zasilacze z funkcjonalnością Hot Swap 8.3.7. Wentylatory z funkcjonalnością Hot Swap 8.3.8. Każdy serwer musi być wyposażony w co najmniej 2 porty 10 Gb Ethernet, co najmniej 2 porty 1 Gigabit Ethernet, 8.3.9. Każdy serwer musi być wyposażony w kartę zdalnego zarządzania 8.3.10. Każdy z serwerów musi być połączony do elementów sieciowych za pomocą łączy o zagregowanej przepustowości całkowitej wynoszącej minimum 40 Gb/s realizowanej w technologii Infiniband 1xDual-Port QDR lub 5 x FC 8 Gb/s i zapewniających pełną redundancję, 8.3.11. Dodanie lub odjęcie serwera do platformy sprzętowej aplikacji nie może powodować przestoju w pracy aplikacji, 8.3.12. Serwery muszą pracować pod kontrolą systemu operacyjnego Linux lub UNIX certyfikowanego przez producenta oprogramowania aplikacyjnego, 8.3.13. Min. 6 gniazd PCI Express 8.3.14. Min. 4 porty USB 8.3.15. Kontrolery dysków lokalnych w serwerach muszą wspierać redundancję na poziomie co najmniej RAID 1,5,6,10,-za dobór typu RAID odpowiada Wykonawca 8.3.16. Port szeregowy (niezależny od portu zarządzania) 8.3.17. Poziom głośności zgodnie z normą IS09296 8.3.18. Montaż w szafie 19” na szynach teleskopowych (pełne wysunięcie) z organizatorem kabli 8.3.19. Pamięć RAM należy przewidzieć z zapasem 100% w stosunku do normalnej zajętości pamięci zdefiniowanej w parametrach wydajnościowych i zmierzonych w trakcie testu wydajnościowego. 8.3.20. Zajętość pamięci dyskowej w chwili przekazania systemu do eksploatacji i pełnym zdefiniowaniu modelu sieci powinna wynosić 25% całkowitej pojemności dysków. 8.3.21. Średnie obciążenie normalne procesorów zdefiniowane w parametrach wydajnościowych i zmierzone w trakcie testu wydajnościowego nie może przekraczać 25% 8.3.22. Za skalowanie i dobór urządzeń odpowiada Wykonawca. Opis zawarty w tabeli w ofercie Odwołującego: W ramach realizacji zamówienia Zamawiającemu zostaną dostarczone serwery aplikacji głównej HP DL380p Gen8 o parametrach co najmniej spełniających wymagania Zamawiającego. Dokładna specyfikacja zostanie podana w ofercie ostatecznej, będącej wynikiem ustaleń negocjacyjnych. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych urządzeń. Dane te wyczerpują postawione w ofercie wstępnej wymagania krótkiego opisu. Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po określeniu przez Zamawiającego liczby użytkowników systemu, co zgodnie z udzieloną odpowiedzią nastąpi w fazie negocjacji. Podane przez Zamawiającego dane minimalne mogą być niewystarczające do realizacji zadania, a odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży po stronie Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie wstępnej dokonać nie może, a Zamawiający - bez narażania się na zarzut naruszenia przepisów - nie może żądać. w punkcie 8.2 Zamawiający jako brak dyskwalifikujący ofertę wskazał brak podania typu urządzenia, natomiast w punkcie o takim samym charakterze, w którym typ podano, brakiem dyskwalifikującym jest rzekomy brak innego opisu. 29. Zastrzeżenie: Brak opisu propozycji/sposobu realizacji wymagań SIWZ. Wymaganie od 8.4.: Serwery baz danych archiwalnych (2 redundantne serwery w Dyspozytorni Ogólnopolskiej, 2 redundantne serwery w Dyspozytorni Rezerwowej) powinny spełniać następujące minimalne wymagania: Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA dostarczy, zainstaluje i skonfiguruje nie mniej niż po 2 redundantne serwery baz danych archiwalnych HP DL380p Gen8 o odpowiednich parametrach technicznych w Dyspozytorni Ogólnopolskiej i w Dyspozytorni Rezerwowej. Bliższe dane w rozdziale „Ogólny opis architektury systemu”. Ostateczna propozycja dotycząca serwerów baz danych archiwalnych HP DL380p Gen8 zostanie podana w ofercie ostatecznej, będącej wynikiem ustaleń negocjacyjnych. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych urządzeń. Dane te wyczerpują postawione w ofercie wstępnej wymagania krótkiego opisu. Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po określeniu przez Zamawiającego liczby użytkowników systemu, co zgodnie z udzieloną odpowiedzią nastąpi w fazie negocjacji. Podane przez Zamawiającego dane minimalne mogą być niewystarczające do realizacji zadania, a odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży po stronie Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie wstępnej dokonać nie może, a Zamawiający - bez narażania się na zarzut naruszenia przepisów - nie może żądać. 30. Zastrzeżenie: Brak opisu propozycji/sposobu realizacji wymagań SIWZ. Wymaganie od 8.4.1. do 8.4.22.: 8.4.1. Każdy z serwerów musi być wyposażony w nie mniej niż 2 procesory 64- bitowe sześciordzeniowe 8.4.2. Procesory każdego z serwerów aplikacji muszą zapewniać w sumie wydajność dającą wynik Baseline co najmniej na poziomie 250 punktów, według standardowego testu SPECfp_rate2006 (www.spec.org) 8.4.3. Co najmniej 96GB pamięci operacyjnej RAM dla każdego z serwerów o parametrach minimum DDR3 1333MHz 8.4.4. Każdy z serwerów musi być wyposażony w minimum 4 x 300 GB dyski twarde SAS, napęd DVD typu +/- RW 8.4.5. Karta grafiki wysokiej rozdzielczości min. 1600 x 1200 8.4.6. Min. 2 redundantne zasilacze z funkcjonalnością Hot Swap 8.4.7. Wentylatory z funkcjonalnością Hot Swap 8.4.8. Każdy serwer musi być wyposażony w co najmniej 2 porty 10 Gb Ethernet, co najmniej 2 porty 1 Gigabit Ethernet, 8.4.9. Każdy serwer musi być wyposażony w kartę zdalnego zarządzania 8.4.10. Każdy z serwerów musi być połączony do elementów sieciowych za pomocą łączy o zagregowanej przepustowości całkowitej wynoszącej minimum 40 Gb/s realizowanej w technologii Infiniband 1xDual-Port QDR lub 5 x FC 8 Gb/s i zapewniających pełną redundancję, 8.4.11. Dodanie lub odjęcie serwera do platformy sprzętowej aplikacji nie może powodować przestoju w pracy aplikacji, 8.4.12. Serwery muszą pracować pod kontrolą systemu operacyjnego Linux lub UNIX certyfikowanego przez producenta oprogramowania aplikacyjnego, 8.4.13. Min. 6 gniazd PCI Express 8.4.14. Min. 4 porty USB 8.4.15. Kontrolery dysków lokalnych w serwerach muszą wspierać redundancję na poziomie co najmniej RAID 1,5,6,10,-za dobór typu RAID odpowiada Wykonawca 8.4.16. Port szeregowy (niezależny od portu zarządzania) 8.4.17. Poziom głośności zgodnie z normą IS09296 8.4.18. Montaż w szafie 19” na szynach teleskopowych (pełne wysunięcie) z organizatorem kabli 8.4.19. Pamięć RAM należy przewidzieć z zapasem 100% w stosunku do normalnej zajętości pamięci zdefiniowanej w parametrach wydajnościowych i zmierzonych w trakcie testu wydajnościowego. 8.4.20. Średnie obciążenie normalne procesorów zdefiniowane w parametrach wydajnościowych i zmierzone w trakcie testu wydajnościowego nie może przekraczać 25% 8.4.21. Obciążenie interfejsów sieciowych zdefiniowane w parametrach wydajnościowych i zmierzone w trakcie testu wydajnościowego nie może przekraczać 25% Opis zawarty w tabeli w ofercie Odwołującego: W ramach realizacji zamówienia Zamawiającemu zostaną dostarczone serwery baz danych archiwalnych HP DL380p Gen8 o parametrach co najmniej spełniających wymagania Zamawiającego. Dokładna specyfikacja zostanie podana w ofercie ostatecznej, będącej wynikiem ustaleń negocjacyjnych. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych urządzeń. Dane te wyczerpują postawione w ofercie wstępnej wymagania krótkiego opisu. Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po określeniu przez Zamawiającego ilości użytkowników systemu, co zgodnie z udzieloną odpowiedzią nastąpi w fazie negocjacji. Podane przez Zamawiającego dane minimalne mogą być niewystarczające do realizacji zadania, a odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży po stronie Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie wstępnej dokonać nie może, a Zamawiający - bez narażania się na zarzut naruszenia przepisów - nie może żądać. należy wskazać, że w punkcie 8.2 Zamawiający jako brak dyskwalifikujący ofertę wskazał brak podania typu urządzenia, natomiast w punkcie o takim samym charakterze, w którym typ podano, brakiem dyskwalifikującym jest rzekomy brak innego opisu. Takie stanowisko Zamawiającego pozwala postawić zarzut naruszenia przepisów PZP. 31. Zastrzeżenie: Brak opisu propozycji/sposobu realizacji wymagań SIWZ. Wymaganie 8.4.22.: Za skalowanie i dobór urządzeń odpowiada Wykonawca. Opis zawarty w tabeli w ofercie Odwołującego: Za skalowanie i dobór urządzeń odpowiada MIKRONIKA. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący w sposób jednoznaczny opisał realizację wymagania oświadczając, że Odwołujący jest odpowiedzialny za skalowanie i dobór urządzeń poprzez realizację projektu technicznego i dokumentacji systemu, których elementami są m. in. analiza wymagań Zamawiającego, projekty techniczne dla poszczególnych węzłów systemu czy dokumentacje konfiguracji urządzeń - patrz pkt 12.1 tabeli oferty. W treści oferty wstępnej, tam gdzie było to możliwe na obecnym etapie, Odwołujący zaproponował producenta oraz typ urządzenia. Należy uznać, że wyczerpuje to postawione w SIWZ wymaganie podania krótkiego opisu dla tego punktu, wobec czego postawiony wymóg należy uznać za spełniony. 32. Zastrzeżenie: Brak opisu propozycji/sposobu realizacji wymagań SIWZ. Wymaganie 8.5.: wymienione wymagania od 8.5.1 do 8.5.18 (patrz następny punkt) Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA dostarczy, zainstaluje i skonfiguruje Serwery Aplikacji Dodatkowych HP DL380p Gen8. Bliższe dane w rozdziale „Ogólny opis architektury systemu”. Ostateczna propozycja dotycząca Serwerów Aplikacji Dodatkowych HP DL380p Gen8 zostanie podana w ofercie ostatecznej, będącej wynikiem ustaleń negocjacyjnych. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych urządzeń. 33. Zastrzeżenie: Brak opisu propozycji/sposobu realizacji wymagań SIWZ. Wymaganie od 8.5.1. do 8.5.17.: 8.5.1. Komputer wieloprocesorowy (płyta główna z możliwością zainstalowania min. dwóch czterordzeniowych procesorów). 8.5.2. Architektura 64 bitowa 8.5.3. Dysk twardy (możliwość zainstalowania dysków SCSI, SATA lub SAS typu hot-swap) - dyski w konfiguracji co najmniej RAID 1, po uszkodzeniu dysku i jego wymianie dyski w macierzy odbudowują się max. 2 h 8.5.4. Dedykowany sprzętowy kontroler dyskowy RAID zapewniający funkcjonalność zabezpieczenia na poziomach: RAID 1, 5, 10 - za dobór typu RAID odpowiada Wykonawca 8.5.5. Napęd DVD typu +/- RW 8.5.6. Karta grafiki wysokiej rozdzielczości min. 1600 x 1200 8.5.7. Min. 2 redundantne wentylatory z funkcjonalnością Hot Swap 8.5.8. Min. 4 porty Gbit Ethernet RJ45 8.5.9. Dodatkowy dedykowany port Ethernet 10/100 sieci zarządzającej (dedykowany moduł zarządzający umożliwiający zdalny restart serwera i pełne zarządzanie włącznie z przejęciem konsoli tekstowej) 8.5.10. Min. 6 gniazd PCI Express 8.5.11. Min. 4 porty USB 8.5.12. Port szeregowy (niezależny od portu zarządzania) 8.5.13. Poziom głośności zgodnie z normą IS09296 8.5.14. Montaż w szafie 19” na szynach teleskopowych (pełne wysunięcie) z organizatorem kabli 8.5.15. Pamięć RAM należy przewidzieć z zapasem 100% w stosunku do normalnej zajętości pamięci zdefiniowanej w parametrach wydajnościowych i zmierzonych w trakcie testu wydajnościowego. 8.5.16. Zajętość pamięci dyskowej w chwili przekazania systemu do eksploatacji i pełnym zdefiniowaniu modelu sieci powinna wynosić 25% całkowitej pojemności dysków. 8.5.17. Średnie obciążenie normalne procesorów zdefiniowane w parametrach wydajnościowych i zmierzone w trakcie testu wydajnościowego nie może przekraczać 25% Opis zawarty w tabeli w ofercie Odwołującego: W ramach realizacji zamówienia Zamawiającemu zostaną dostarczone Serwery Aplikacji Dodatkowych HP DL380p Gen8 o parametrach co najmniej spełniających wymagania Zamawiającego. Dokładna specyfikacja zostanie podana w ofercie ostatecznej, będącej wynikiem ustaleń negocjacyjnych. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych urządzeń. Dane te wyczerpują postawione w SIWZ wymaganie podania krótkiego opisu. Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po określeniu przez Zamawiającego liczby użytkowników systemu, co zgodnie z udzieloną przez Zamawiającego odpowiedzią nastąpi w fazie negocjacji. Podane przez Zamawiającego dane minimalne mogą być niewystarczające do realizacji zadania, a odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży po stronie Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie wstępnej dokonać nie może, a Zamawiający - bez narażania się na zarzut naruszenia przepisów - nie może żądać. Na marginesie należy wskazać, że w punkcie 8.2 Zamawiający jako brak dyskwalifikujący ofertę wskazał brak podania typu urządzenia, natomiast w punkcie o takim samym charakterze, w którym typ podano, brakiem dyskwalifikującym jest rzekomy brak innego opisu. 34. Zastrzeżenie: Brak opisu propozycji/sposobu realizacji wymagań SIWZ. Wymaganie 8.5.18.: Za skalowanie i dobór urządzeń odpowiada Wykonawca. Opis zawarty w tabeli w ofercie Odwołującego: Za skalowanie i dobór urządzeń odpowiada MIKRONIKA. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący w sposób jednoznaczny opisał realizację wymagania oświadczając, że Odwołujący jest odpowiedzialny za skalowanie i dobór urządzeń poprzez realizację projektu technicznego i dokumentacji systemu, których elementami są m. in. analiza wymagań Zamawiającego, projekty techniczne dla poszczególnych węzłów systemu czy dokumentacje konfiguracji urządzeń - patrz pkt 12.1 tabeli oferty. W treści oferty wstępnej, tam gdzie było to możliwe na obecnym etapie, Odwołujący zaproponował producenta oraz typ urządzenia. Należy uznać, że wyczerpuje to postawione w SIWZ wymaganie podania krótkiego opisu dla tego punktu, wobec czego postawiony wymóg należy uznać za spełniony. 35. Zastrzeżenie: Brak propozycji urządzeń spełniających min. wymagania SIWZ. Wymaganie 8.10.: Serwery komunikacyjne będą służyły do wymiany danych pomiędzy systemem SCADA a systemami zewnętrznymi. Serwer powinien spełniać następujące minimalne wymagania. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA dostarczy, zainstaluje i skonfiguruje serwery komunikacyjne typu HP DL380p Gen8, przeznaczone do wymiany danych pomiędzy systemem SCADA a systemami zewnętrznymi. Bliższe dane w rozdziale „Ogólny opis architektury systemu”. Ostateczna propozycja dotycząca serwerów komunikacyjnych HP DL380p Gen8 zostanie podana w ofercie ostatecznej, będącej wynikiem ustaleń negocjacyjnych. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych urządzeń. Dane te wyczerpują postawione w SIWZ wymaganie podania krótkiego opisu. Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po określeniu przez Zamawiającego liczby użytkowników systemu, co zgodnie z udzieloną przez Zamawiającego odpowiedzią nastąpi w fazie negocjacji. Podane przez Zamawiającego dane minimalne mogą być niewystarczające do realizacji zadania, a odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży po stronie Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie wstępnej dokonać nie może, a Zamawiający - bez narażania się na zarzut naruszenia przepisów - nie może żądać. Na marginesie należy wskazać, że w punkcie 8.2 Zamawiający jako brak dyskwalifikujący ofertę wskazał brak podania typu urządzenia, natomiast w punkcie o takim samym charakterze, w którym typ podano, brakiem dyskwalifikującym jest rzekomy brak innego opisu. 36. Zastrzeżenie: Brak propozycji urządzeń spełniających min. wymagania SIWZ. Wymaganie od 8.10.1. do 8.10.19.: 8.10.1. Komputer wieloprocesorowy (płyta główna z możliwością zainstalowania min. dwóch dwu lub czterordzeniowych procesorów). 8.10.2. Architektura 64 bitowa 8.10.3. Dysk twardy (możliwość zainstalowania dysków SCSI, SATA lub SAS typu hot-swap) - dyski w konfiguracji co najmniej RAID 1, po uszkodzeniu dysku i jego wymianie dyski w macierzy odbudowują się max. 2 h 8.10.4. Dedykowany sprzętowy kontroler dyskowy RAID zapewniający funkcjonalność zabezpieczenia na poziomach: RAID 1, 5, 10 - za dobór typu RAID odpowiada Wykonawca 8.10.5. Napęd DVD typu +/- RW 8.10.6. Karta grafiki rozdzielczości min. 1600 x 1200 8.10.7. Min. 2 redundantne zasilacze z funkcjonalnością Hot Swap 8.10.8. Min. 2 redundantne wentylatory z funkcjonalnością Hot Swap 8.10.9. Min. 4 porty Gbit Ethernet RJ45, dodatkowy dedykowany port Ethernet 10/100 sieci zarządzającej (dedykowany moduł zarządzający umożliwiający zdalny restart serwera i pełne zarządzanie włącznie z przejęciem konsoli tekstowej) 8.10.10. Min. 6 gniazd PCI Express 8.10.11. Min. 4 porty USB 8.10.12. Port szeregowy 8.10.13. Poziom głośności zgodnie z normą IS09296 8.10.14. Montaż w szafie 19” na szynach teleskopowych (pełne wysunięcie) z organizatorem kabli 8.10.15. Pamięć RAM należy przewidzieć z zapasem 100% w stosunku do normalnej zajętości 8.10.16. Pamięci zdefiniowanej w parametrach wydajnościowych i zmierzonych w trakcie testu wydajnościowego. 8.10.17. Zajętość pamięci dyskowej w chwili przekazania systemu do eksploatacji i pełnym 8.10.18. Zdefiniowaniu modelu sieci powinna wynosić 25% całkowitej pojemności dysków. 8.10.19. Średnie obciążenie normalne procesorów zdefiniowane w parametrach wydajnościowych i zmierzone w trakcie testu wydajnościowego nie może przekraczać 25% Opis zawarty w tabeli w ofercie Odwołującego: W ramach realizacji zamówienia Zamawiającemu zostaną dostarczone serwery komunikacyjne HP DL380p Gen8 o parametrach co najmniej spełniających wymagania Zamawiającego. Dokładna specyfikacja zostanie podana w ofercie ostatecznej, będącej wynikiem ustaleń negocjacyjnych. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych urządzeń. Dane te wyczerpują postawione w SIWZ wymaganie podania krótkiego opisu. Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po określeniu przez Zamawiającego liczby użytkowników systemu, co zgodnie z udzieloną przez Zamawiającego odpowiedzią nastąpi w fazie negocjacji. Podane przez Zamawiającego dane minimalne mogą być niewystarczające do realizacji zadania, a odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży po stronie Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie wstępnej dokonać nie może, a Zamawiający - bez narażania się na zarzut naruszenia przepisów - nie może żądać. Na marginesie należy wskazać, że w punkcie 8.2 Zamawiający jako brak dyskwalifikujący ofertę wskazał brak podania typu urządzenia, natomiast w punkcie o takim samym charakterze, w którym typ podano, brakiem dyskwalifikującym jest rzekomy brak innego opisu. 37. Zastrzeżenie: Brak propozycji urządzeń spełniających min. wymagania SIWZ. Wymaganie 8.10.20.: Za skalowanie i dobór urządzeń odpowiada Wykonawca. Opis zawarty w tabeli w ofercie Odwołującego: Za skalowanie i dobór urządzeń odpowiada MIKRONIKA. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Odwołujący w sposób jednoznaczny opisał realizację wymagania oświadczając, że to Odwołujący jest odpowiedzialny za skalowanie i dobór urządzeń poprzez realizację projektu technicznego i dokumentacji systemu, których elementami są m. in. analiza wymagań Zamawiającego, projekty techniczne dla poszczególnych węzłów systemu czy dokumentacje konfiguracji urządzeń - patrz pkt 12.1 tabeli oferty. W treści oferty wstępnej, tam gdzie było to możliwe na obecnym etapie, Odwołujący zaproponował producenta oraz typ urządzenia. Należy uznać, że wyczerpuje to postawiony w SIWZ wymóg podania krótkiego opisu dla tego punktu, wobec czego postawiony wymóg należy uznać za spełniony. 38. Zastrzeżenie: Oferent nie uzasadnił z czego wynika możliwość spełnienia wymagań dotyczących przetwarzania, tym samym nie opisał sposobu realizacji wymagania. Dokumentacja systemu nie odnosi się do tego zagadnienia. Wymaganie od 9.5.1. do 9.5.8.: 9.5.1. Czas pomiędzy zmianą wartości a jej zarejestrowaniem w bazie danych czasu rzeczywistego: <1s 9.5.2. Czas pomiędzy zarejestrowaniem wartości w bazie danych czasu rzeczywistego a wyświetleniem jej na ekranie <0.1 s 9.5.3. Czas pomiędzy zarejestrowaniem wartości w bazie danych czasu rzeczywistego a wyświetleniem jej w linii zdarzeń, liście alarmów lub zdarzeń (lub jednocześnie we wszystkich trzech miejscach) <0.1 s 9.5.4. Czas pomiędzy wydaniem polecenia przez operatora a rozpoczęciem realizacji polecenia <1s 9.5.5. Czas pomiędzy wydaniem polecenia przez operatora a zarejestrowaniem tego faktu w bazie danych czasu rzeczywistego oraz liście zdarzeń <0.1 s 9.5.6.Czas pomiędzy wydaniem przez operatora polecenia ustawienia wartości zadanej a zarejestrowaniem tego faktu w bazie danych czasu rzeczywistego i w liście zdarzeń <0.1 s 9.5.7. Czas pomiędzy wydaniem przez operatora polecenia ustawienia wartości zadanej a ustawieniem jej w urządzeniu realizującym zadanie <1s 9.5.8. Czas pomiędzy zarejestrowaniem zmiany wartości zmiennej w bazie danych czasu rzeczywistego a zarejestrowaniem tej zmiany w bazie danych archiwalnych <5s. Opis zawarty w tabeli w ofercie Odwołującego: Oferowany system SCADA SYNDIS zapewni następujące czasy przetwarzania: Czas pomiędzy zmianą wartości a jej zarejestrowaniem w bazie danych czasu rzeczywistego: <1 s; Czas pomiędzy zarejestrowaniem wartości w bazie danych czasu rzeczywistego a wyświetleniem jej na ekranie <0.1 s; Czas pomiędzy zarejestrowaniem wartości w bazie danych czasu rzeczywistego a wyświetleniem jej w linii zdarzeń, liście alarmów lub zdarzeń (lub jednocześnie we wszystkich trzech miejscach) <0.1 s; Czas między wydaniem polecenia przez operatora a rozpoczęciem realizacji polecenia <1 s; Czas pomiędzy wydaniem polecenia przez operatora a zarejestrowaniem tego faktu w bazie danych czasu rzeczywistego oraz liście zdarzeń <0.1 s; Czas pomiędzy wydaniem przez operatora polecenia ustawienia wartości zadanej a zarejestrowaniem tego faktu w bazie danych czasu rzeczywistego i w liście zdarzeń <0.1 s; Czas pomiędzy wydaniem przez operatora polecenia ustawienia wartości zadanej a ustawieniem jej w urządzeniu realizującym zadanie <1s; Czas pomiędzy zarejestrowaniem zmiany wartości zmiennej w bazie danych czasu rzeczywistego a zarejestrowaniem tej zmiany w bazie danych archiwalnych <5s. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie wymagań wydajnościowych określonych w punktach od 9.5.1 do 9.5.8 specyfikacji w ofercie podano istotne informacje dotyczące sposobu realizacji funkcjonalności, mające wpływ na wydajność systemu, tj.: a. wskazano, że system SCADA zostanie zrealizowany za pośrednictwem dedykowanego do takich rozwiązań systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb. Systemy tej klasy ze swojej natury zapewniają spełnienie postawionych wymagań, które są typowe dla takich systemów; b. przedstawiono architekturę systemu pozwalającą na uzyskanie wymaganych wskaźników; c. podano typy przewidywanego do użycia sprzętu, odpowiadającego za szybkość aplikacji. Informacje powyższe łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Więcej informacji nie można było podać, ponieważ Zamawiający nie podał kluczowych informacji, tj. liczby użytkowników deklarując omówienie tych kwestii podczas negocjacji, Dopiero po choćby przybliżonym podaniu liczby użytkowników możliwe będzie podanie większej ilości szczegółów odpowiednich rozwiązań. 39. Zastrzeżenie: W ofercie wstępnej na modernizację systemu SACAD SGT p.1.13 oferent potwierdza brak możliwości realizacji w pełni tego wymagania. Wymaganie 11.1.1.1.: Przy projektowaniu i realizacji interfejsów Wykonawca musi zapewnić możliwość pobierania danych do starego systemu SCADA na dotychczasowych zasadach do czasu dokonania odbioru technicznego nowego systemu SCADA. Opis zawarty w tabeli w ofercie Odwołującego: Przy projektowaniu i realizacji interfejsów MIKRONIKA zapewni możliwość pobierania danych do starego systemu SCADA na dotychczasowych zasadach do czasu dokonania odbioru technicznego dostarczonego systemu SCADA SYNDIS. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: Stwierdzenie, że oferent Mikronika potwierdza brak możliwości realizacji w pełni tego wymagania pozostaje w sprzeczności z treścią złożonej przez Odwołującego oferty wstępnej. W tabeli w pozycji punkt 1.13 Odwołujący wpisał „TAK”, co oznacza, że potwierdza, że funkcjonalność zostanie zrealizowana. W punkcie „Uwagi” nie podano żadnego zastrzeżenia w tym zakresie. 40. Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu, m.in. [Skrypt Operatora, System SYNDIS RV, Dokumentacja szkoleniowa], [Skrypt Administratora, Podstawy i obsługa systemu, Dokumentacja szkoleniowa] nie daje kompletnej i precyzyjnej odpowiedzi.. Wymaganie 11.1.1.7.: 11.1.1.7. Mechanizmy opisane poniższych punktach muszą posiadać co najmniej na-stępujące właściwości: 11.1.1.7.1. Możliwość konfiguracji okresu automatycznego uzupełniania danych (dla danych archiwalnych). 11.1.1.7.2. Możliwość konfiguracji zakresu pobieranych danych. 11.1.1.7.3. Możliwość konfiguracji wielu adresów skąd pobierane są dane. 11.1.1.7.4. Możliwość pobierania danych z wielu rozłącznych obszarów danych. 11.1.1.7.5. Możliwość przejęcia stempla czasowego dla danych, które są nim opatrzone w źródle. 11.1.1.7.6. Dla połączeń ma być prowadzony ciągły nadzór na poprawnością działania łącza niezależnie od tego czy jest aktualnie wykorzystywane (łą-cze podstawowe) czy nie (łącze zapasowe). 11.1.1.7.7. Awaria łącza ma być wykrywana nie później niż 5s od momentu uszkodzenia dla łącza podstawowego i nie później niż 30 s dla łącza zapasowego. 11.1.1.7.8. W wypadku wykrycia awarii łącza podstawowego przełączenie na łącze zapasowe ma nastąpić automatycznie. 11.1.1.7.9. Przełączenie na łącze zapasowe ma nastąpić nie później niż 2s od momentu wykrycia awarii. Opis zawarty w tabeli w ofercie Odwołującego: Wszystkie interfejsy zewnętrzne opracowane i zrealizowane przez MIKRONIKĘ będą się cechować między innymi: Możliwością konfiguracji okresu automatycznego uzupełniania danych (dla danych archiwalnych); •Możliwością konfiguracji zakresu pobieranych danych; •Możliwością konfiguracji wielu adresów, skąd pobierane są dane; •Możliwością pobierania danych z wielu rozłącznych obszarów danych; •Możliwością przejęcia stempla czasowego dla danych, które są nim opatrzone w źródle; •Połączenia będą w sposób ciągły nadzorowane pod kątem poprawności działania łącza, niezależnie od tego, czy jest aktualnie wykorzystywane (łącze podstawowe) czy nie (łącze zapasowe); •Awaria łącza będzie wykrywana nie później niż 5s od momentu uszkodzenia dla łącza podstawowego i nie później niż 30 s dla łącza zapasowego; •W wypadku wykrycia awarii łącza podstawowego przełączenie na łącze zapasowe będzie następowało automatycznie; •Przełączenie na łącze zapasowe nastąpi nie później niż 2s od momentu wykrycia awarii. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO- 55 - strona 5 oferty, Poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Dodatkowe informacje podano na rysunkach iw opisie architektury systemu w rozdziale 1.13 Organizacja zbierania i wystawiania danych. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ. 41 Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności. Wymaganie 11.1.2: 11.1.2. Interfejs do Pomiarowni Kondratki i SSRP Włocławek. 11.1.2.1. Uruchomić pobieranie danych bieżących za pomocą protokołów opisanych w załączniku nr 1. 11.1.2.2. Uruchomić pobieranie zamrożonych stanów liczników za pomocą protokołu opisanego w załączniku nr 1. Zrealizowany mechanizm ma posiadać funkcje automatycznego uzupełnienia brakujących stanów liczników co najmniej 62 dni wstecz. 11.1.2.3. Uruchomienie pobierania danych bieżących i archiwalnych za pomocą protokołu Gazmodem-2. Protokół ten będzie pracować w oparciu o łącze Ethernet/TCP/lP. 11.1.2.4. Interfejs GazModem-2 ma być wyposażony w mechanizm automatycznego uzupełniania brakujących danych minimum 62 dni wstecz. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA opracuje i zrealizuje Interfejs do Pomiarowni Kondratki i SSRP Włocławek. Realizacja będzie między innymi obejmować: • uruchomienie pobierania danych bieżących za pomocą wymaganych protokołów. • uruchomienie pobierania zamrożonych stanów liczników za pomocą wymaganego protokołu. Zrealizowany mechanizm będzie posiadać funkcje automatycznego uzupełnienia brakujących stanów liczników co najmniej 62 dni wstecz. • uruchomienie pobierania danych bieżących i archiwalnych za pomocą protokołu Gazmodem- 2. Protokół ten będzie pracować w oparciu o łącze Ethernet/TCP/lP. Wyposażenie Interfejsu GazModem-2 w mechanizm automatycznego uzupełniania brakujących danych minimum 62 dni wstecz. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO- 55 - strona 5 oferty. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w rozdziale 1.13 Organizacja zbierania i wystawiania danych. Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z protokołem opisanym przez Zamawiającego we wskazanym Załączniku. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ. Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a brakuje informacji precyzyjnej. Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie studium nie było wymagane. 42. Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności. Wymaganie 11.1.3: 11.1.3. Interfejs do Systemów Automatyki Tłoczni (SCS). 11.1.3.1. Uruchomić pobieranie danych bieżących za pomocą protokołów opisanych w załączniku nr 2. 11.1.3.2. Zrealizować algorytmy sterowania opisane w załączniku nr 2. 11.1.3.3. Algorytmy powinny być zrealizowane w języku wysokiego poziomu. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA opracuje i zrealizuje Interfejs do Systemów Automatyki Tłoczni (SCS). Realizacja będzie między innymi obejmować: • Uruchomienie pobierania danych bieżących za pomocą wymaganych protokołów. • Zrealizowanie wymaganych algorytmów sterowania w języku wysokiego poziomu. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO- 55 - strona 5 oferty. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Dodatkowe informacje podano w na rysunkach i w opisie architektury systemu w rozdziale 1.13 Organizacja zbierania i wystawiania danych. Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z protokołem opisanym przez Zamawiającego we wskazanym Załączniku. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a brakuje informacji precyzyjnej. Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie studium nie było wymagane. 43. Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności. Wymaganie 11.1.4: 11.1.4. Interfejs do Sterowników Turbokompresorów (UCS). 11.1.4.1. Uruchomić pobieranie danych bieżących za pomocą protokołu opisanego w załączniku nr 3. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA opracuje i zrealizuje Interfejs do Sterowników Turbokompresorów (UCS). Realizacja będzie między innymi obejmować uruchomienie pobierania danych bieżących za pomocą wymaganego protokołu. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO- 55 - strona 5 oferty. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w rozdziale 1.13 Organizacja zbierania i wystawiania danych. Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z protokołem opisanym przez Zamawiającego we wskazanym Załączniku. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ. Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a brakuje informacji precyzyjnej. Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie studium nie było wymagane. 44. Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności. Wymaganie 11.1.5: 11.1.5. Interfejs do systemu diagnostyki turbokompresorów CCC. 11.1.5.1. Uruchomić udostępnianie danych dla systemów diagnostyki turbokompresorów w tłoczniach Kondratki i Włocławek. Udostępniane dane pochodzić będą ze sterowników SCS i U CS tłoczni. 11.1.5.2. Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego systemu SCADA. Przełączenie na udostępnianie z nowego systemu SCADA nastąpi po odbiorze technicznym interfejsu. 11.1.5.3. Udostępnianie danych odbywać się będzie z serwera komunikacyjnego wewnętrznego. 11.1.5.4. W przypadku awarii serwera komunikacyjnego, przełączenie na serwer zapasowy ma być wykonywane ręcznie. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA opracuje i zrealizuje Interfejs do Pomiarowni Kondratki i SSRP Włocławek. Realizacja będzie między innymi obejmować: • uruchomienie pobierania danych bieżących za pomocą wymaganych protokołów. • uruchomienie pobierania zamrożonych stanów liczników za pomocą wymaganego protokołu. Zrealizowany mechanizm będzie posiadać funkcje automatycznego uzupełnienia brakujących stanów liczników co najmniej 62 dni wstecz. • uruchomienie pobierania danych bieżących i archiwalnych za pomocą protokołu Gazmodem- 2. Protokół ten będzie pracować w oparciu o łącze Ethernet/TCP/lP. MIKRONIKA opracuje i zrealizuje interfejs do systemu diagnostyki turbokompresorów CCC. Realizacja będzie między innymi obejmować następujące zagadnienia: • Uruchomienie udostępniania danych dla systemów diagnostyki turbokompresorów w tłoczniach Kondratki i Włocławek. Udostępniane dane pobierane będą ze sterowników SCS i UCS tłoczni. • Do momentu odbioru technicznego interfejsu dane pobierane będą ze starego systemu SCADA. Przełączenie na udostępnianie z nowozainstalowanego systemu SYNDIS nastąpi po odbiorze technicznym interfejsu. • Udostępnianie danych odbywać się będzie z serwera komunikacyjnego wewnętrznego. W przypadku awarii serwera komunikacyjnego, przełączenie na serwer zapasowy będzie wykonywane ręcznie. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO- 55 - strona 5 oferty. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Dodatkowe informacje podano w na rysunkach i w opisie architektury systemu w rozdziale 1.13 Organizacja zbierania i wystawiania danych. Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z protokołem opisanym przez Zamawiającego w wskazanym Załączniku. Informacja te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ. Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a brakuje informacji precyzyjnej. Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie studium nie było wymagane. 45. Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności. Wymaganie 11.1.6: 11.1.6. Interfejs do Systemu Ochrony Środowiska. Uruchomić pobieranie danych bieżących za pomocą protokołu opisanego w za- łączniku nr 5.. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA zaprojektuje, zrealizuje i uruchomi Interfejs do Systemu Ochrony Środowiska za pomocą wymaganego protokołu. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO- 55 - strona 5 oferty. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w rozdziale 1.13 Organizacja zbierania i wystawiania danych. Odwołujący opisał w ofercie, że zaprojektuje, zrealizuje i uruchomi interfejs do obiektu zgodnie z protokołem opisanym przez Zamawiającego we wskazanym Załączniku. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ. Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a brakuje informacji precyzyjnej. Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie studium nie było wymagane. 46. Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności. Wymaganie 11.1.7: 11.1.7. Interfejs do Pomiarowni Potrzeb Własnych (PPW). 11.1.7.1. Uruchomić wymianę danych bieżących za pomocą protokołów opisanych w załączniku nr 6. 11.1.7.2. Uruchomić pobieranie zamrożonych stanów liczników za pomocą protokołu opisanego w załączniku nr 6. Zrealizowany mechanizm ma posiadać funkcje automatycznego uzupełnienia brakujących stanów liczników co najmniej 62 dni wstecz. 11.1.7.3. Uruchomienie pobierania danych bieżących i archiwalnych za pomocą protokołu Gazmodem-2. Protokół ten będzie pracować w oparciu o łącze Ether- net/TCP/IP. 11.1.7.4. Interfejs GazModem-2 ma być wyposażony w mechanizm automatycznego uzupełniania brakujących danych minimum 62 dni wstecz. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA opracuje i zrealizuje Interfejs do Pomiarowni Potrzeb Własnych (PPW). Realizacja będzie między innymi obejmować: • Uruchomienie wymiany danych bieżących za pomocą wymaganych protokołów. • Uruchomienie pobierania zamrożonych stanów liczników za pomocą wymaganego protokołu. Zrealizowany mechanizm będzie posiadać funkcje automatycznego uzupełnienia brakujących stanów liczników co najmniej 62 dni wstecz. • Uruchomienie pobierania danych bieżących i archiwalnych za pomocą protokołu Gazmodem-2. Protokół ten będzie pracować w oparciu o łącze Ethernet/TCP/lP. Wyposażenie Interfejsu GazModem-2 w mechanizm automatycznego uzupełniania brakujących danych minimum 62 dni wstecz. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO- 55 - strona 5 oferty. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w rozdziale 1.13 Organizacja zbierania i wystawiania danych. Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z protokołem opisanym przez Zamawiającego we wskazanym Załączniku. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ. Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a brakuje informacji precyzyjnej. Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie studium nie było wymagane. 47. Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności. Wymaganie 11.1.8: 11.1.8. Interfejs do obiektów liniowych typu ZZU, OZZU, ZPT, ZP. Uruchomić pobieranie danych bieżących za pomocą protokołu opisanego w za- łączniku nr 7. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA opracuje i zrealizuje Interfejs do obiektów liniowych typu ZZU, OZZU, ZPT, ZP. Pobieranie danych bieżących będzie uruchomione za pomocą wymaganego protokołu. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO- 55 - strona 5 oferty. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w rozdziale 1.13 Organizacja zbierania i wystawiania danych. Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z protokołem opisanym przez Zamawiającego we wskazanym Załączniku. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ. Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a brakuje informacji precyzyjnej. Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie studium nie było wymagane. 48. Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności. Wymaganie 11.1.9: 11.1.9. Interfejs do WRG Gustorzyn. 11.1.9.1. Uruchomić pobieranie danych bieżących za pomocą protokołów opisanych w załączniku nr 8. 11.1.9.2. Uruchomić udostępnianie danych dla WRG Gustorzyn zgodnie z opisem zawartym w załączniku nr 8. 11.1.9.3. Udostępnianie danych odbywać się będzie z serwera komunikacyjnego zewnętrznego. 11.1.9.4. W przypadku awarii serwera komunikacyjnego, przełączenie na serwer zapasowy ma być wykonywane ręcznie. 11.1.9.5. Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego systemu SCADA. Przełączenie na udostępnianie z nowego systemu SCADA nastąpi po odbiorze technicznym interfejsu. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA zaprojektuje i uruchomi Interfejs do WRG Gustorzyn. Realizacja będzie między innymi obejmować: • Uruchomienie pobierania danych bieżących za pomocą wymaganych protokołów. • Uruchomienie udostępniania danych dla WRG Gustorzyn zgodnie z wymaganiami. • Udostępnianie danych odbywać się będzie z serwera komunikacyjnego zewnętrznego. • W przypadku awarii serwera komunikacyjnego, przełączenie na serwer zapasowy będzie wykonywane ręcznie. Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego systemu SCADA. Przełączenie na udostępnianie z nowozainstalowanego systemu SYNDIS nastąpi po odbiorze technicznym interfejsu. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO- 55 - strona 5 oferty. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Dodatkowe informacje podano na rysunkach iw opisie architektury systemu w rozdziale 1.13 Organizacja zbierania i wystawiania danych. Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z protokołem opisanym przez Zamawiającego we wskazanym Załączniku Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ. Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a brakuje informacji precyzyjnej. Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie studium nie było wymagane. 49. Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności. Wymaganie 11.1.10: 11.1.10. Interfejs do Mallnow. 11.1.10.1. Uruchomić pobieranie danych bieżących za pomocą protokołów opisanych w załączniku nr 9. 11.1.10.2. Uruchomić udostępnianie danych dla Mallnow zgodnie z opisem zawartym w załączniku nr 9. 11.1.10.3. Udostępnianie danych odbywać się będzie z serwera komunikacyjnego zewnętrznego. 11.1.10.4. W przypadku awarii serwera komunikacyjnego, przełączenie na serwer zapasowy ma być wykonywane ręcznie. 11.1.10.5. Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego systemu SCADA. Przełączenie na udostępnianie z nowego systemu SCADA nastąpi po odbiorze technicznym interfejsu. Opis zawarty w tabeli w ofercie Odwołującego: MIKRONIKA zaprojektuje i uruchomi Interfejs do Mallnow. Realizacja będzie między innymi obejmować: • Uruchomienie pobierania danych bieżących za pomocą wymaganych protokołów. • Uruchomienie udostępniania danych dla Mallnow zgodnie z wymaganiami. • Udostępnianie danych odbywać się będzie z serwera komunikacyjnego zewnętrznego. • W przypadku awarii serwera komunikacyjnego, przełączenie na serwer zapasowy będzie wykonywane ręcznie. Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego systemu SCADA. Przełączenie na udostępnianie z nowozainstalowanego systemu SYNDIS nastąpi po odbiorze technicznym interfejsu. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego: W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz sterowników/koncentratorów serii SO- 55 - strona 5 oferty. Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak postawiono. Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA. Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w rozdziale 1.13 Organizacja zbierania i wystawiania danych. Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z protokołem opisanym przez Zamawiającego we wskazanym Załączniku. Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony. Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ. Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a brakuje informacji precyzyjnej. Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie studium nie było wymagane. 50. Zastrzeżenie: Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania. Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem sposobu realizacji ani studium wykonalności. Wymaganie 11.1.11: 11.1.11. Interfejs do GazExport Berlin 11.1.11.1. Uruchomić udostępnianie danych dla GazExport zgodnie z opisem zawartym w załączniku nr 10. 11.1.11.2. Udostępnianie danych odbywać się będzie z serwera komunikacyjnego zewnętrznego. 11.1.11.3. W przypadku awarii serwera komunikacyjnego, przełączenie na serwer zapasowy ma być wykonywane ręcznie. 11.1.11.4. Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego systemu SCADA. Przełączenie na udostępnianie z nowego systemu SCADA nastąpi po odbiorze technicznym interfejsu. Opis zawarty w tabeli w ofercie Odwołującego: M4KRQ