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 niedo

[... tekst skrócony ...]