rodzaj: WYROK
data dokumentu: 2012-11-19
rok: 2012

Powiązane tematy:

• tryb postępowania - negocjacje z ogłoszeniem
• zamówienia sektorowe

sygnatury akt.:

KIO 2401/12

Komisja 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.
39
6.1.10.4.
Obiekt
6.1.10.4.1. Notatka wskazuje jeden lub więcej obiektów.
6.1.10.4.2. Lista obiektów definiowana jest przez administratora oddzielnie dla
każdego dziennika-serwera, ale dyspozytor musi mieć możliwość wpisania obiektu
spoza listy.
6.1.10.4.3. W dyspozytorni ogólnopolskiej obiektami są: tłocznie, zespoły zaporowo
upustowe, pomiarownie.
6.1.10.4.4. Dla dyspozytorni tłoczni obiektami będą: turbokompresory, podsystemy.
6.1.10.4.5. Z okien dziennika dyspozytorskiego ma dać otworzyć się ekran
prezentujący stan obiektu, oraz archiwum dziennika z notatkami tego obiektu (na str.
43).
6.1.10.5.
Czas rozpoczęcia i zakończenia:
6.1.10.5.1. Pole zawiera datę i czas z dokładnością do minuty.
6.1.10.5.2. Domyślnie czas zakończenia jest równy czasowi rozpoczęcia - co
oznacza brak daty zakończenia.
6.1.10.5.3. Domyślnie data rozpoczęcia wskazuje czas rozpoczęcia wprowadzania
notatki.
6.1.10.5.4. Dla notatek korygujących wartość domyślna jest kopiowana z notatki
korygowanej.
6.1.10.5.5. W okresie pomiędzy datą rozpoczęcia i zakończenia, notatka ma być
wyróżniona pulsowaniem.
6.1.10.6.
Czas przydatności.
6.1.10.6.1. Czas przydatności wskazuje, kiedy notatka ma zostać usunięta z listy
notatek bieżących (na str. 40). Domyślnie wskazuje czas + 36 godzin od chwili
rozpoczęcia edycji notatki.
6.1.10.6.2. Dla notatki korygującej wartość domyślna jest kopiowana z notatki
korygowanej i ewentualnie uzupełniana do 36 godzin od chwili obecnej.

6.1.10.6.3. Użytkownik
nie
powinien
być
powiadamiany
o
konieczności
przeczytania notatek, których termin przydatności upłynął, nawet jeżeli ich nie
przeczytał (np. podczas urlopu).
6.1.10.7.
Wskazanie na dokument zewnętrzny.
Jest to ścieżka dostępu do pliku (z ewentualnymi parametrami uruchomienia, jeżeli
plik jest programem), który ma zostać otwarty (uruchomiony). Najczęściej będą to
ewidencje (np. prac gazoniebezpiecznych), harmonogramy prac, instrukcje
postępowania, jak również programy do uruchomienia.
6.1.10.8.
Notatka korygująca.
6.1.10.8.1. Oprogramowanie powinno uniemożliwiać wymazanie jakiejkolwiek
wprowadzonej informacji.
6.1.10.8.2. W celu umożliwienia skorygowania błędu, do każdej notatki może
zostać utworzona jedna lub więcej notatek korygujących.
6.1.10.8.3. Notatka korygująca również może zostać ponownie skorygowana.
6.1.10.8.4. Notatka korygująca nie musi oznaczać błędu - pierwsza notatka może
zostać wprowadzona np. jako pozwolenie wejścia na obiekt, pierwsza korekta może
być zgłoszeniem wejścia na obiekt, a następna zgłoszeniem zakończenia prac i
wyjścia z obiektu.
6.1.10.8.5. Każda notatka musi mieć możliwość stworzenia wielu notatek
korygujących, co oznacza, że więcej niż jedna notatka korygująca może wskazywać
tą samą notatkę korygowaną. Będzie to stosowane np. w celu rozdzielenia notatek.
6.1.10.8.6. W oknie notatki należy zapewnić możliwość poruszania się pomiędzy
notatkami korygującymi i skorygowanymi.
6.1.10.8.7. Jeżeli do wyboru jest tylko jedna notatka korygująca, to jej wybór ma
nastąpić automatycznie.
6.1.10.8.8. Należy zapewnić budowanie właściwych powiązań korekcyjnych w
przypadku notatek przesyłanych pomiędzy dziennikami/dyspozytorniami. W
szczególności należy uwzględnić, że:
6.1.10.8.8.1. Notatka która była wcześniej wysłana do innego dziennika, może
zostać skorygowana lokalnie (1), a następnie ponownie skorygowana lecz z
wysłaniem (3).
6.1.10.8.8.2. Notatka odebrana, podobnie jak każda notatka, może zostać
skorygowania lokalnie (2), z możliwością przesłania do innych dzienników (4).

6.1.10.8.8.3. Przy korygowaniu notatki odebranej, ma ona być domyślnie przesłana
do pierwotnego dziennika.
6.1.10.8.9. Po korektach w przedstawionym poniżej diagramie, na liście notatek
bieżących powinny być notatki wyróżnione podwójną linią (w A:odebrana korekta 4;
w B: korekta 4 i korekta 2). Przedstawiono diagram./…/
6.1.10.9.
Formularze/szablony notatek.
6.1.10.9.1. Aplikacja ma umożliwiać definiowanie przez administratora formularzy
(szablonów) do wprowadzania notatek. Użytkownik będzie jedynie wypełniał w nim
pola, których początkowa zawartość powinna być pobierana z parametrów
uruchomienia, oraz uruchomionych w tle programów (np. do pobierania wartości z
archiwum, list z rejestrów prac,..).
6.1.10.9.2. Pola w formularzach mają być dostępne pola co najmniej typu:
6.1.10.9.2.1. edycja tekstu,
6.1.10.9.2.2. edycja liczby,
6.1.10.9.2.3. lista,
6.1.10.9.2.4. lista rozwijalna,
6.1.10.9.2.5. lista rozwijalna z edycją.
6.1.10.9.3. Musi istnieć możliwość załadowania nowej listy wartości po dokonaniu
wyboru na innej liście, np. lista firm i lista pracowników tej firmy.
6.1.10.9.4. Ma być możliwość wyliczania zawartości pola na podstawie zawartości
innych pól, obliczenie to ma następować automatycznie podczas edycji pól
źródłowych. Przykładem takich pól może być pole sumy lub przeliczenia na inną
jednostkę miary.
6.1.10.9.5. Wykonawca dostarczy wszystkie narzędzia/programy do tworzenia
szablonów.
6.1.11.
Lista notatek bieżących
6.1.11.1.
Domyślne
okno
aplikacji,
które
powinno
być
uruchamiane
automatycznie po zalogowaniu się użytkownika, powinno wyświetlać listę notatek
bieżących, tj. takich, która data przydatności jeszcze nie upłynęła i do której nie
stworzono notatki korygującej. Dla przykładów zilustrowanych na str. 39, na liście
notatek bieżących powinny pojawić się notatki 3 i 3A, a dla diagramu na str. 40 w
dyspozytorni A powinna być widoczna odebrana korekta 4, a w dyspozytorni B
korekta 2 i 4.

6.1.11.2.
Notatki nieprzeczytane przez użytkownika (na stanowisku może być
kilku użytkowników) powinny zostać wyróżnione pulsowaniem od momentu:
uruchomienia dla wszystkich notatek dla których chwila obecna znajduje się
pomiędzy czasem rozpoczęcia
i
zakończenia, wprowadzenia przez innego użytkownika lub odebrania z innej
dyspozytorni, nadejścia czasu rozpoczęcia, nadejścia czasu zakończenia.
6.1.11.3.
Pulsowanie ma zaniknąć po wybraniu notatki.
6.1.11.4.
Użytkownik ma mieć możliwość wybrania, które atrybuty (kolumny)
maja być wyświetlane.
6.1.11.5.
Notatka, która została oznaczona do wysłania, a nie została
potwierdzona przez któregokolwiek dyspozytora (adresata) powinna być wyróżniona
symbolem graficznym. Podobnie notatka, która nie została przesłana do
któregokolwiek adresata (poniżej).
6.1.11.6.
Pobieranie informacji do wyświetlenia musi odbywać się w tle i nie
może powodować np. chwilowego czyszczenia ekranu, zmiany wybranych
elementów, położenia i wielkości okna programu.
6.1.12.
Potwierdzenia notatek.
W oknie wyświetlania notatki dostępny ma być przycisk potwierdzenia przeczytania,
oraz dostępna ma być lista potwierdzeń. Lista potwierdzeń powinna zawierać:
6.1.12.1.
czas potwierdzenia,
6.1.12.2.
identyfikator (imię nazwisko) użytkownika,
6.1.12.3.
adresata (gdy notatka była adresowana do więcej niż jednego).
6.1.13.
Wykres Gantta.
Zawartość okna notatek bieżących ma być również prezentowana w formie wykresu
Gantta. W wierszach mają być prezentowane kolejne obiekty, natomiast na osi
poziomej mają być odwzorowane czasy rozpoczęcia i zakończenia.
6.1.14.
Syntezer mowy.
Po odebraniu notatki z innej dyspozytorni, powinien zostać uruchomiony program do
syntezy mowy, który odczyta wskazane atrybuty notatki.
6.1.15.
Zakładki z dodatkowymi ewidencjami.
Z dziennika dyspozytorskiego powinny być dostępne dodatkowe ewidencje.
6.1.16.
Wydane polecenia Tabela ma posiadać kolumny:
Data, Godzina, wydający polecenie, treść polecenia, mechanik, elektryk.
6.1.17.
Parametry tłoczni

Tabela powinna ma posiadać kolumny: godzina, temperatura otoczenia, wilgotność,
ciśnienie (wlot), ciśnienie(wylot), temperatura (wlot), temperatura(wylot), sumaryczny
strumień gazu przez agregaty, sumaryczny strumień przez tłocznię, prędkość wiatru.
6.1.17.1.
Uwagi o przebiegu zmiany Tabela ma posiadać kolumny:
data zdarzenia, godzina, uwaga o przebiegu zmiany, rodzaj węzła.
Kolumny uwaga o przebiegu zmiany, rodzaj węzła mają być listami rozwijalnymi.
6.1.17.2. Informacja o pracy TUCO Tabela ma zawierać kolumny: data i godzina
wpisu, stan każdego TUCO, P. każdego TUCO, Kolumny TUCO maja być listami
rozwijalnymi.
6.1.17.3.
Starty i godziny
6.1.17.3.1. Tabela ma być automatycznie uzupełniana danymi z systemu (wartości
chwilowe jedną minutę po pełnej godzinie).
6.1.17.3.2. Tabela ma zawierać kolumny: godzina, liczba startów każdego TUCO,
godziny normalne każdego TUCO,
godziny ekwiwalentne każdego TUCO.
6.1.17.4.
Moce turbin
6.1.17.4.1. Tabela ma być automatycznie uzupełniana danymi z systemu (wartości
chwilowe jedną minutę po pełnej godzinie).
6.1.17.4.2. Tabela ma zawierać kolumny: godzina, moc na wale każdego TUCO,
moc dostępna dla każdego TUCO, moc termodynamiczna dla każdego TUCO.
6.1.17.5.
Obroty TUCO
6.1.17.5.1. Tabela ma być automatycznie uzupełniana danymi z systemu (wartości
chwilowe jedną minutę po pełnej godzinie).
6.1.17.5.2. Tabela ma zawierać kolumny: Godzina, obroty sprężarki każdego
TUCO, obroty turbiny gazowej każdego TUCO, poziom oleju w zbiorniku każdego
TUCO.
6.1.18.
Archiwum notatek
Okno służy do wyświetlania notatek w chronologicznej kolejności wprowadzania.
6.1.18.1.
Okno nie może blokować się podczas pobierania notatek z serwera, tj.
ostatnio wprowadzone notatki mają być wyświetlane w ciągu 2 sekund.
6.1.18.2.
Starsze notatki mają być wczytywane w tle, gdyż serwer musi być
przygotowany na przechowywanie kilkuset tysięcy notatek.
6.1.18.3.
W oknie notatek ma być dostępne filtrowanie po wybranych lub
wszystkich atrybutach notatki.

6.1.18.4.
Należy zapewnić także raport, prezentujący wszystkie powiązane ze
sobą notatki korygujące i korygowane. Uwzględniający możliwość rozdzielenia korekt
zilustrowane na stronie na str. 39.
6.1.19.
Raport zmiany
Raport zbierający informacje z wielu notatek, dotyczących przebiegu zmiany, według
szablonu pt. Dziennik dyspozytorski.
Szablon nieznacznie różni się na każdej tłoczni gazu (np. ilość turbokompresorów).
6.1.20.
Parametry uruchomienia.
6.1.20.1.
Poprzez podanie parametrów uruchomienia, aplikacja powinna
umożliwiać:
6.1.20.1.1. wyświetlenie notatki o podanym identyfikatorze,
6.1.20.1.2. otwarcie dialogu do wprowadzania notatki z wartościami atrybutów
podanymi jako parametry uruchomienia.
6.1.20.1.3. otwarcie szablonu do wprowadzania notatki z wartościami pól podanymi
jako parametry uruchomienia.
6.1.20.1.4. wyświetlenie okna archiwum z zadanymi filtrami,
6.1.20.1.5. import notatek z pliku CSV.
6.1.20.2.
Wywoływanie z parametrami będzie wykonywane co najmniej z okna
ekranów procesowych opisanych.
6.1.20.3.
W oknie notatki oraz z listy notatek powinna istnieć możliwość
uruchamiania programów zdefiniowanych przez administratora.
6.1.20.4.
Należy zapewnić możliwość podawania jako parametry uruchomienia
zmiennych środowiskowych, w których mają być umieszczone wartości atrybutów
wybranej notatki.
6.1.20.5.
Zawartość dziennika powinna dać się eksportować do pliku tekstowego.
6.1.21.
Serwer równoległy.
6.1.21.1.
Dla każdego serwera dziennika dyspozytorskiego ma być możliwość
zdefiniowanie serwera równoległego, z którym serwer będzie synchronizował notatki
(również lokalne). Notatka wprowadzona na jeden serwer, powinna bezzwłocznie
skopiowana na drugi serwer, oraz odwrotnie.
6.1.21.2.
W przypadku braku komunikacji pomiędzy serwerami, po jej
przywróceniu ma nastąpić wzajemne uzupełnienie notatek.
6.1.21.3.
Para takich serwerów będzie stała w Warszawie (Dyspozytornia
Ogólnopolska) i Ciechanowie (Rezerwowa Dyspozytornia Ogólnopolska).

6.1.22.
Import notatek
W ramach dostawy wykonawca jest zobowiązany do przeniesienie notatek z
obecnych dzienników dyspozytorskich. W warszawie w dzienniku dyspozytorskim
jest ok. 100000 notatek, które będą przekazane w pliku CSV.
Opis zawarty w tabeli w ofercie Odwołującego:
Obecna wersja produkcyjna systemu SCADA SYNDIS posiada wymagane
funkcjonalności rozproszone na wielu modułach systemowych, w tym także na
modułach wykorzystujących technologię WWW, np. SYNDIS OMS, SYNDIS
ENERGIA.
W
związku
z
zastrzeżeniem
Zamawiającego,
związanym
z
niedopuszczeniem do wykonania funkcjonalności Dziennika dyspozytorskiego w
technologii WWW, wszystkie wymagane funkcjonalności zostaną zaimplementowane
do nowego modułu aplikacji dziennika operatorskiego, który zostanie zainstalowany
na serwerach aplikacji dodatkowych.
Jako syntezator mowy zostanie zintegrowany z Dzielnikiem dyspozytorskim moduł
aplikacji IVONA.
Serwer aplikacja Dziennika dyspozytorskiego będzie umożliwiał pracę równoległą z
drugim dziennikiem - zgodnie z wymaganiami para takich serwerów będzie stała w
Warszawie (Dyspozytornia Ogólnopolska) i Ciechanowie (Rezerwowa Dyspozytornia
Ogólnopolska).
W ramach realizacji zadania notatki z istniejących dzienników dyspozytorskich
zostaną przeniesione do nowej stworzonej aplikacji Dziennika dyspozytorskiego.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana przy użyciu systemu SYNDIS -
strona 5 oferty, który jest wysokiej klasy narzędziem służącym do wizualnej
prezentacji stanu nadzorowanych obiektów oraz realizacji sterowania tych obiektów -
strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą na stronie 7 dokumentu
„Skrypt edytorski - Informacja o systemie SYNDIS RV” system SYNDIS RV jest
uniwersalnym narzędziem do tworzenia aplikacji przeznaczonych zarówno dla
potrzeb wspomagania ruchu, służb zabezpieczeń, jak również dla wspomagania
eksploatacji. Modułowa struktura sprzętowo-programowa umożliwia jego adaptację
do różnych warunków i potrzeb. Wszystkie moduły mogą pracować razem lub
samodzielnie, wykorzystując w każdym przypadku wspólną bazę danych o
elementach systemu energetycznego (lub innego), integrującą ich działanie.

Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne narzędzie,
umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak również
dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników.
Odwołujący poinformował także, że oprogramowanie SYNDIS zostanie rozbudowane
do wymagań Zamawiającego bez odstępstw.
Poinformował również, że wymaganie zostanie zrealizowane w zakresie takim, jak
postawiono.
Podano także dodatkowe informacje, jakiego typu oprogramowanie zostanie użyte w
celu realizacji wymagania.
Ponadto w załączonej do oferty dokumentacji systemu SYNDIS opisano możliwości i
sposób działania standardowych funkcji przedmiotowej funkcjonalności.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zarzut braku dokumentacji opisującej jest bezpodstawny, ponieważ Zamawiający
żądał jedynie podręczników użytkownika modułów standardowych proponowanych
aplikacji. Przedmiotowa funkcjonalność nie stanowi standardowego modułu i nie jest
oparta o standardowe moduły, więc oferta nie zawiera podręcznika dla tego zakresu.
Zarzut, iż Oferent nie uwiarygodnił poprzez przedstawienie studium wykonalności
realizacji wymagań w postaci oczekiwanej przez Zamawiającego, jest bezpodstawny,
ponieważ studium wykonalności nie było wymagane w ofercie wstępnej.
Uwaga Zamawiającego dotycząca wersji WEB jest bezprzedmiotowa, ponieważ
Odwołujący jednoznacznie stwierdziła, że funkcjonalności dostępne w systemie
SYNDIS w technologii WWW zostaną zaimplementowane do nowego modułu.
22.
Zastrzeżenie:
Oferent nie przedstawił sposobu realizacji wymagań w tym zakresie. Dostarczona
dokumentacja systemu nie odnosi się w żaden sposób do oprogramowania SIMONE,
w tym nie opisuje sposobu integracji systemu SYNDIS z tym oprogramowaniem.
Wymaganie od 6.2.1. do 6.2.6.:
6.2.1. Dostawca dokona uaktualnienia istniejącego oprogramowania SIMONE firmy
LIWACOM do najnowszej wersji znajdującej się na rynku na dzień wdrożenia
oprogramowania.
6.2.2. Oprogramowanie będzie zainstalowane w dwóch lokalizacjach: Dyspozytorni
Głównej EuRoPol GAZ w Warszawie ( dwa stanowiska ) i Dyspozytorni Rezerwowej -

Tłocznia Gazu Ciechanów (jedno stanowisko ). Będzie ono dostępne na oddzielnych
stanowiskach roboczych jemu dedykowanych.
6.2.3. Program do symulacji
Program przeznaczony jest do modelowania pracy gazociągu tranzytowego w
stanach nie¬ustalonych w trybie on-line, oraz w stanach ustalonych i nieustalonych w
trybie off-line, a także jako program do planowania ruchu na SGT.
Wymagania funkcjonalne:
6.2.3.1.
Model matematyczny wykorzystywany do symulacji powinien zawierać
równania transportu masy, pędu i energii oraz równanie stanu, uwzględniające
współczynnik ściśliwości obliczany wg metody SGERG 88.
6.2.3.2.
Współczynnik oporu hydraulicznego powinien być obliczany na
podstawie liczby Reynoldsa (w całym zakresie przepływów laminarnych i burzliwych )
oraz szorstkości ścianki rurociągu.
6.2.3.3.
Metoda rozwiązywania równań powinna gwarantować stabilność dla
wszelkich rodzajów obciążeń.
6.2.3.4.
Oprogramowanie powinno umożliwiać symulację współbieżną w czasie
rzeczywistym, w stanach nieustalonych.
6.2.3.5.
Rezultaty modelowania ( trajektorie ciśnień, strumieni, temperatur )
powinny być wizualizowane na monitorze stanowiska SIMONE, w postaci tabel i
wykresów na których pokazane są wyniki obliczeń i pomiarów.
6.2.3.6.
Należy zapewnić wydruk wykresów i tabel oraz schematów
modelowanych układów.
6.2.3.7.
Oprogramowanie do rekonstrukcji stanu musi zapewnić rekonstrukcję z
dokładnością:
6.2.3.7.1.
przy braku ciśnienia z dowolnego jednego punktu pomiarowego:
0,02MPa
6.2.3.7.2.
przy braku temperatury z jednego punktu pomiarowego: 0.50C
6.2.3.7.3.
przy braku ciśnienia z całego odcinka pomiędzy tłoczniami: 0,05MPa
6.2.3.7.4.
przy braku temperatury z całego odcinka pomiarowego: 0,80C
6.2.3.7.5.
wykrywać nieprawidłowe wskazania ciśnienia, w przypadku odchyłki
większej niż 0,04MPa.
6.2.3.7.6.
przy braku wartości strumienia w punktach wyjścia, dopuszczalna
różnica pomiędzy wynikiem symulacji a wartością rzeczywistą nie może przekroczyć
0,5% maksymalnej przepustowością punktu.

6.2.3.8.
W celu sprawdzenia dokładności, do symulatora zostaną wprowadzone
dane archiwalne, a wyniki obliczeń symulatora porównane a z danymi archiwalnymi.
6.2.3.9.
Analiza stanów nieustalonych dla prognozy 24 h ma zapewnić
prognozę ciśnień z dokładnością nie gorszą niż 0,05MPa.
6.2.3.10.
Oprogramowanie powinno umożliwiać symulację off-line stanów
ustalonych i nieustalonych. W tym trybie program pobiera dane o elementach
systemu z Bazy Danych Archiwalnych. Obciążenia lub krzywe obciążeń w przypadku
stanów nieustalonych. Warunki brzegowe i początkowe oraz czasy włączania lub
wyłączania elementów systemu wprowadzane są ręcznie.
6.2.3.11.
Należy zapewnić możliwość zapisania krzywych obciążeń w węzłach
sieci w bazie danych i ponownego ich wykorzystania.
6.2.3.12.
Oprogramowanie powinno umożliwiać symulację z wykorzystaniem
prognozy (tzw. Look ahead). W tym trybie program generuje prognozę poborów gazu
z horyzontem określonym przez użytkownika. Rezultaty modelowania winny być
wizualizowane na monitorze stanowiska SIMONE w postaci tabel i wykresów.
6.2.3.13.
Należy zapewnić możliwość wydruku rezultatów prognozy.
6.2.3.14.
Kryterium prawidłowego działania programu będzie porównanie
otrzymanych wyników przeprowadzonej symulacji z rzeczywistym przepływem z
okresu doby. Dopuszczalna różnica pomiędzy wynikiem symulacji a wartością
rzeczywistą nie może przekroczyć 0,5% maksymalnej przepustowością punktu.
6.2.3.15.
Oprogramowanie umożliwiające obliczanie akumulacji gazu w
gazociągu z podziałem na odcinki pomiędzy tłoczniami gazu jak również w całym
gazociągu. Wartość akumulacji oraz jej zmiana powinna być obliczana i
prezentowana w procesach symulacji współbieżnej i prognozy (Look ahead).
Program powinien umożliwiać obliczanie przyrostu objętości gazu w gazociągu przy
określonych przez operatora warunkach brzegowych.
6.2.3.16.
Oprogramowanie umożliwi wizualizację polskiego odcinka SGT wraz z
całą armaturą na nim zainstalowaną jak również stany elementów nierurowych.
6.2.3.17.
Dla wszystkich turbokompresorów będzie wykonana aproksymacja
charakterystyk agregatów danych w formie graficznej w układzie; przepływ -
ciśnienie, przepływ - stopień sprężu, uwzględniające:
ograniczenie
od
linii
pompażu, ograniczenie od linii minimalnych obrotów, ograniczenie od linii
maksymalnych obrotów,

Parametry: współczynnik sprężu, temperatury gazu na ssaniu,temperatury gazu na
tłoczeniu,
temperatury gazu za chłodnicami, obroty, moc termodynamiczna, moc dyspozycyjna,
zużycie gazu paliwowego, temperatura spalin.
6.2.4. Program powinien umożliwiać wybór przez operatora jednostek miary masy,
objętości, energii, składu gazu, temperatury i ciśnienia oraz wybór warunków
odniesienia (00C, 200C).
6.2.5. Oprogramowanie do optymalizacji.
6.2.5.1.
Oprogramowanie do optymalizacji ma służyć jako narzędzie do
znajdowania najbardziej korzystnych parametrów pracy SGT w warunkach
stacjonarnych i niestacjonarnych, (oprogramowanie działające w trybie of-line).
6.2.5.2.
Poprzez wykonanie zadania optymalizacji uważa się określenie tłoczni
gazu które powinny pracować w celu wypełnienia zadania transportowego, ilości
agregatów turbosprężających oraz wartości nastaw ciśnień.
6.2.5.3.
Jako kryterium optymalizacji należy przyjąć minimalizację pracujących
tłoczni gazu jak również turbin w nich pracujących z możliwie zbliżonymi wartościami
obciążeń, oraz zużycie gazu paliwowego dla turbin.
6.2.5.4.
Kryterium optymalizacji powinno być wybierane opcjonalnie przez
użytkownika.
6.2.6. Usługi związane z dostawą:
Usługi związane z dostawą obejmują:
6.2.6.1.
Zainstalowanie oprogramowania i konfigurowanie interfejsów do
pobierania danych bieżących i archiwalnych ze SCADA,
6.2.6.2.
Pobieranie danych o nominacjach z oprogramowania do zarządzania
kontraktami,
6.2.6.3.
Dostarczone oprogramowanie wersji polskojęzycznej,
6.2.6.4.
Dostawca wykona strojenie modelu matematycznego do warunków
rzeczywistych, uwzględniających:
6.2.6.4.1.
Elementy nierurowe systemu takie jak: turbokompresory, główne
zawory regulacyjne tłoczni, chłodnice gazu.
6.2.6.4.2.
Charakterystyki turbokompresorów i zaworów regulacyjnych oraz model
chłodnic. Dokumenty te dostarczy Zleceniodawca w formie papierowej lub
elektronicznej w formacie PDF. ( Zabrania się kopiowania lub udostępniania osobom
trzecim powyższych dokumentów).

6.2.6.4.3.
Oprogramowanie
będzie
uwzględniało
czynniki
środowiska
zewnętrznego takie jak: temperatura otoczenia i wilgotność, jak również ograniczenie
pracy maszyn wynikające z temperatury spalin.
6.2.6.5.
Wykonawca zapewni integrację z aplikacją główną minimum w
zakresie:
prezentacji na ekranach sys. SCADA wybranych danych z rekonstrukcji stanu,

wyliczenia akumulacji gazu, symulowanych trendów dla ciśnień i przepływów
w wybranych punktach geograficznych. Wybór parametrów zostanie dokonany na
etapie projektowania ekranów sys. SCADA SGT,
6.2.6.6.
Pięciodniowe szkolenie dla sześciu pracowników w ośrodku
autoryzowanym przez LIVACOM,
6.2.6.7.
Serwis oprogramowania w okresie gwarancyjnym i pogwarancyjnym.
6.2.6.8.
W zakresie komunikacji z programem należy zapewnić:
6.2.6.8.1.
wielookienkowość, przy możliwości przesuwania, zmiany wymiarów,
przenoszenia do ikony, przywracania, zamykania, ukrywania,
6.2.6.8.2.
menu rozwijalne i zwijalne,
6.2.6.8.3.
możliwość podziału na „n” logicznych ekranów,
6.2.6.8.4.
paski przewijania, zooming wraz z selekcją informacji graficznej i
alfanumerycznej odpowiednio do skali.
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA dokona uaktualnienia istniejącego oprogramowania SIMONE firmy
LIWACOM do najnowszej wersji znajdującej się na rynku na dzień wdrożenia
oprogramowania. Oprogramowanie będzie zainstalowane w dwóch lokalizacjach:
Dyspozytorni Głównej EuRoPol GAZ w Warszawie (dwa stanowiska) i Dyspozytorni
Rezerwowej - Tłocznia Gazu Ciechanów (jedno stanowisko). Będzie ono dostępne
na oddzielnych stanowiskach roboczych jemu dedykowanych.
Oprogramowanie
zostanie
dopasowane
do
wymaganych
funkcjonalności
Zamawiającego.
W ramach realizacji zadania MIKRONIKA zapewni:
Zainstalowanie oprogramowania i konfigurowanie interfejsów do pobierania danych
bieżących i archiwalnych ze SCADA SYNDIS,
Pobieranie danych o nominacjach z oprogramowania do zarządzania kontraktami,
Dostarczenie oprogramowanie wersji polskojęzycznej,

Wykonanie strojenia modelu matematycznego do warunków rzeczywistych,
uwzględniających: Elementy nierurowe systemu takie jak: turbokompresory, główne
zawory regulacyjne tłoczni, chłodnice gazu.
Charakterystyki turbokompresorów i
zaworów regulacyjnych oraz model chłodnic na podstawie dostarczonych przez
Zamawiającego dokumentów.
Czynniki środowiska zewnętrznego takie jak:
temperatura otoczenia i wilgotność, jak również ograniczenie pracy maszyn
wynikające z temperatury spalin.
MIKRONIKA zapewni integrację z aplikacją główną systemu SCADA SYNDIS
minimum w zakresie:
Prezentacji na ekranach systemu SCADA SYNDIS wybranych danych z rekonstrukcji
stanu.
Wyliczenia akumulacji gazu symulowanych trendów dla ciśnień i przepływów w
wybranych punktach geograficznych.
Wybór parametrów zostanie dokonany na etapie projektowania ekranów systemu
SCADA SGT,
MIKRONIKA zapewni pięciodniowe szkolenie dla sześciu pracowników w ośrodku
autoryzowanym przez LIVACOM oraz serwis oprogramowania w okresie
gwarancyjnym i pogwarancyjnym.
W zakresie komunikacji z programem MIKRONIKA zapewni:
Wielookienkowość, przy możliwości przesuwania, zmiany wymiarów, przenoszenia
do ikony, przywracania, zamykania, ukrywania.
Menu rozwijalne i zwijalne.
Możliwość podziału na „n” logicznych ekranów.
Paski przewijania, zooming wraz z selekcją informacji graficznej i alfanumerycznej
odpowiednio do skali.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Zarzuty Zamawiającego są bezpodstawne.
Przedstawiony w tabeli krótki opis zawiera istotne informacje dotyczące integracji, np.
minimalny zakres integracji z aplikacją główną systemu SYNDIS, zakres prezentacji
danych z systemu SIMONE w systemie SYNDIS, sposób osadzenia programu
SIMONE w środowisku systemu SCADA itp.
Dostarczona dokumentacja systemu nie odnosi się w żaden sposób do
oprogramowania SIMONE, ponieważ nie jest to funkcjonalność standardowa, a tylko
w zakresie takich funkcjonalności Zamawiający wyraził wolę otrzymania

dokumentacji. Opis sposobu integracji systemu SYNDIS z najnowszą wersją systemu
LIN/ACOM dostępną w momencie wdrażania będzie mógł być, co oczywiste,
zaprojektowany i przedstawiony dopiero w momencie wdrażania systemu.
Odwołujący nie ma wpływu na rozwiązania zastosowane w programie SIMONE,
wskazanym do zastosowania przez Zamawiającego, w wersji, która ma być
przedmiotem dostawy, wobec czego nie może na etapie oferty wstępnej podawać
wiążących informacji co do szczegółów związanych z realizacją tej funkcjonalności,
będących następstwem nieznanych obecnie właściwości wersji programu SIMONE,
którą można by nawet uznać obecnie za jeszcze nieistniejącą.
Dodatkowo w opisie realizacji dla punktów 5.1.10-5.1.12 SIWZ Odwołujący zawarł
informacje
o możliwych mechanizmach współpracy systemu SYNDIS z systemami/aplikacjami
zewnętrznymi.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
23.
Zastrzeżenie:
Oferent nie przedstawił sposobu realizacji wymagań w zakresie funkcjonalnym.
Dostarczona dokumentacja nie opisuje oprogramowania w zakresie funkcjonalności
„Rozliczanie kontraktów”.
Wymaganie od 6.3.1. do 6.3.8.:
Zadaniem oprogramowania jest przyjmowanie planu (nominacje, renominacje ilości
gazu do przesłania), dynamiczny sygnalizować jego realizacji, oraz przygotowanie
danych do rozliczeń z ilości i jakości przetransportowanego gazu.
6.3.1. Ponieważ pomiary oraz wprowadzane wartości odnoszą się do różnych
warunków pomiarowych (w szczególności temperatury przy określaniu ilości gazu)
Wykonawca musi zapewnić przeliczanie tych pomiarów pomiędzy: warunkami
roboczymi, normalnymi (0°C; 101,325kPa), kontraktowymi (20°C; 101,325kPa),

ilością energii (kWh) uwzględniając ciepło spalania podane przez użytkownika
lub z archiwum (dla tego samego czasu).
6.3.2. W przypadku braku danych o strumieniu energii przeliczenie należy wykonać
w oparciu aktualny strumień objętości i ciepło spalania 0/25 zgodnie ze wzorem:
Qe=Qb(Hs[kW]
QE - strumień energii [kW], Qb - strumień objętości w warunkach OoC i
0,101325MPa [m3/h]

Hs - ciepło spalania dla warunków spalania 25°C dla warunków objętości 0°C i
0,101325MPa [kWh/m3].
6.3.3. Oprogramowanie musi uwzględniać, że doba rozliczeniowa nie pokrywa się z
dobą kalendarzową i obecnie rozpoczyna się i kończy o godzinie 8:00 czasu letniego
i zimowego.
6.3.4. Jednak
oprogramowanie
ma
umożliwiać
ustawienia
innej
godziny
rozliczeniowej, oraz ustawienia jej względem czasu uniwersalnego (bez przesunięcia
na czas letni).
6.3.5. Wyłącznie uprawnieni użytkownicy (oraz grupy użytkowników) mają mieć
prawo: wprowadzania nominacji i denominacji, odczytu danych rozliczeniowych,
tworzenia i modyfikacji protokołów zdawczo odbiorczych.
6.3.6. Z okien programów, użytkownik ma mieć możliwość:
6.3.6.1.
otwarcia ekranu procesowego odpowiedniej pomiarowni,
6.3.6.2.
otwarcia wykresu (zawierającego w szczególności krzywe nominacji,
realizacji
1
rozliczenia),
6.3.6.3.
eksportu danych do plików CSV i RTF
6.3.6.4.
kopiowania do/z arkusza kalkulacyjnego,
6.3.6.5.
drukowania.
6.3.7. Nominacje i renominacje
6.3.7.1.
Zadaniem tej części aplikacji będzie przyjmowanie zaplanowanych
ilości gazu do transportu (nominacji). Codziennie, przed rozpoczęciem doby
rozliczeniowej otrzymywane są ilości gazu do przesłania (nominacje). Ilości gazu
podawane są w odniesieniu do warunków kontraktowych.
6.3.7.2.
Oprogramowanie ma być również przygotowane na możliwość
wprowadzania nominacji godzinowych.
6.3.7.3.
Nominacje mogą ulec zmianie w trakcie doby rozliczeniowej
(renominacje).
6.3.7.4.
Oprogramowanie
ma
umożliwiać
pobierania
danych
o
nominacjach/renominacjach
z
systemów
zewnętrznych
za
pośrednictwem
oprogramowania dostarczonego przez Wykonawcę.
6.3.7.5.
Oprogramowanie ma umożliwiać wprowadzanie ręcznie nominacji,
wprowadzania korekt w trakcie doby rozliczeniowej i po jej zakończeniu.

6.3.7.6.
Wykonawca zaproponuje rozwiązania pozwalające na identyfikowanie
nadawcy, kontrolę integralności danych przesyłanych w postaci plików.
6.3.7.7.
Oprogramowania
musi
obsługiwać
pobieranie,
wysyłanie
i
zatwierdzanie nominacji w następujących formatach: Edigas (Edig@s Message
Implementation Guidelines)
txt, XML.
6.3.7.8.
Monitorowanie realizacji planu
6.3.7.9.
Zadaniem
oprogramowania
jest
podpowiadanie
dyspozytorom
(operatorowi) takich nastaw urządzeń, aby ilości przesłanego gazu były jak najbliższe
planom (nominacjom, renominacjom). Ekrany prezentujące informacje do
monitorowania realizacji planów transportu gazu muszą być dostępne na stacjach
roboczych sys. SCADA SGT.
6.3.7.10.
Urządzenia pomiarowe zainstalowane w pomiarowniach najczęściej
mierzą ilości gazu w odniesieniu do warunków normalnych, oraz przeliczają ja na
ilość energii. Oprogramowanie musi uwzględnić, że w dniach, kiedy następuje
zmiana pomiędzy czasem letnim i zimowym, doba rozliczeniowa trwa odpowiednio
23 lub 25 godzin (w odróżnieniu od 24 godzin w pozostałe dni roku). Nominacje
podawane są na dzień, ale urządzenia pomiarowe mierzą w jednostkach na godzinę.
6.3.8. Protokół zdawczo odbiorczy.
6.3.8.1.
Oprogramowanie ma umożliwiać przygotowanie protokołów zdawczo-
odbiorczych, w których wartości domyślne pobierane są z archiwum fizycznych
pomiarów.
6.3.8.2.
Wartości mogą zostać zmienione przez użytkownika: np. z uwagi na
ilości gazu naliczonego w czasie kalibracji urządzeń, ustalenia z kontrahentami, w
szczególności ustalenia ilości gazu w przypadku braku fizycznego pomiaru lub
niedotrzymania parametrów jakościowych, itp.
6.3.8.3.
System ma umożliwiać ustalenie, kto i kiedy dokonał zmian wartości
rozliczeniowych.
6.3.8.4.
Raporty wyższego poziomu mają pobierać wartości z zatwierdzonych
protokołów niższego poziomu (np. miesięczne z dobowych, roczne z miesięcznych).
6.3.8.5.
System powinien umożliwiać porównywanie wartości rozliczeniowych,
nominacji i fizycznie zmierzonych, w szczególności wyliczać ich różnicę.
6.3.8.6.
Wszystkie wydrukowane protokoły mają być zachowywane w postaci
pliku, a oprogramowanie ma umożliwiać podgląd wcześniejszej wersji protokołu.

Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA wykona i wdroży aplikację serwera oprogramowanie Rozliczania
kontraktów zgodnie z wymaganiami i wytycznymi Zamawiającego.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana
przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem
służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji
sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą
na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV”
system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji
przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak
również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa
umożliwia jego adaptację do różnych warunków i potrzeb. Wszystkie moduły mogą
pracować razem lub samodzielnie, wykorzystując w każdym przypadku wspólną
bazę danych o elementach systemu energetycznego (lub innego), integrującą ich
działanie. Oprogramowanie to pozwala stworzyć bardzo elastyczne i wydajne
narzędzie, umożliwiające łatwe i szybkie rozbudowanie systemu o nowe funkcje, jak
również dopasowanie do konkretnych zindywidualizowanych potrzeb użytkowników.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja. Wskazał także, że producentem wydzielonej aplikacji będzie
MIKRONIKA.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, 24. Zastrzeżenie:
Oferent nie przedstawił sposobu realizacji wymagań w zakresie funkcjonalnym.
Dostarczona dokumentacja nie opisuje oprogramowania w zakresie funkcjonalności
„Rozliczanie kontraktów”.
Wymaganie od 6.4.1. do 6.4.16.:
6.4.1. Oprogramowanie ma obliczać ilość gazu w poszczególnych odcinkach
gazociągu. Wyniki mają być dostępne podobnie jak inne pomiary, również jako
wykresy.
6.4.2. akumulacja powinna być wyznaczana na podstawie średniego ciśnienia w
gazociągu pomiędzy ZZU, średniej temperatury, wyznaczonego współczynnika
ściśliwości i objętości geometrycznej odcinka;

6.4.3. wyliczenie ciśnienia średniego powinno odbywać się w oparciu o algorytm
wyznaczania średniego ciśnienia gazu dla gazociągów wysokociśnieniowych
6.4.4. wyliczanie średniej temperatury - średnia arytmetyczna
6.4.5. wyznaczanie współczynnika ściśliwości w oparciu o algorytm SGERG i AGA -
NX19MOD (opcjonalny wybór przez użytkownika) na podstawie ciśnienia średniego,
temperatury średniej i
aktualnego składu gazu.
6.4.6. Zgodnie z załączonymi wzorami akumulacja powinna być obliczana
opcjonalnie dla:
-
dla odcinków między ZZU potem powinna być zsumowana na odcinkach
pomiędzy tłoczniami, a następnie dla całego gazociągu.
-
dla odcinków między tłoczniami potem powinna być zsumowana dla całe-go
gazociągu.
Wybór opcji dokonywany jest z poziomu stacji roboczej przez użytkownika.
6.4.7. System powinien zapewnić prezentacje danych źródłowych do wyliczeń i
możliwość wprowadzania ręcznie korekt.
6.4.8. Wyliczenia powinny być prezentowane w formie graficznej i archiwizowane w
systemie.
6.4.9. Akumulacja powinna być obliczana on-line,
6.4.10.
Zmiany akumulacji powinny być określane za okresy: 5 min, godzina,
doba,
-
miesiąc.
6.4.11.
Wyniki obliczeń akumulacji i jej zmian powinny być prezentowane w
postaci graficznej
i
tabelarycznej i archiwizowane co: 5 min, godzina,
doba, miesiąc.
6.4.12.
Wyniki obliczeń akumulacji oraz przyrosty być zapisywane w bazach
danych.
6.4.13.
Powinna być opcja wyboru uwzględniania odcinków dla przejść
gazociągu pod rzekami dwoma nitkami - wybór do obliczeń jednej lub dwóch nitek
dla każdego przejścia oddzielnie.
6.4.14.
Algorytm powinien uwzględniać odcinek gazociągu od granicy polsko-
niemieckiej do Mallnow.
6.4.15.
Oprogramowanie
powinno
zapewniać
wyznaczanie
prędkości
przepływu gazu w poszczególnych odcinkach.

6.4.16.
Akumulacja w gazociągu powinna być wyliczana zgodnie ze
wzorami(…)
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA wykona i wdroży aplikację oprogramowanie Wyznaczania akumulacji
gazu zgodnie z wymaganiami i wytycznymi Zamawiającego.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący w ofercie wstępnej poinformował, że jego realizacja będzie wykonana
przy użyciu systemu SYNDIS - strona 5 oferty, który jest wysokiej klasy narzędziem
służącym do wizualnej prezentacji stanu nadzorowanych obiektów oraz realizacji
sterowania tych obiektów - strona 8 „Skrypt operatora”. Zgodnie z informacją zawartą
na stronie 7 dokumentu „Skrypt edytorski - Informacja o systemie SYNDIS RV”
system SYNDIS RV jest uniwersalnym narzędziem do tworzenia aplikacji
przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb zabezpieczeń, jak
również dla wspomagania eksploatacji. Modułowa struktura sprzętowo-programowa
umożliwia jego adaptację do różnych warunków
i
potrzeb. Wszystkie moduły mogą pracować razem lub samodzielnie,
wykorzystując w każdym przypadku wspólną bazę danych o elementach systemu
energetycznego (lub innego), integrującą ich działanie. Oprogramowanie to pozwala
stworzyć bardzo elastyczne i wydajne narzędzie, umożliwiające łatwe i szybkie
rozbudowanie systemu o nowe funkcje, jak również dopasowanie do konkretnych
zindywidualizowanych potrzeb użytkowników.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony
25.
Zastrzeżenie:
Brak listy autoryzowanych punktów serwisowych Wymaganie 8.1.14:
Dostawca zobowiązany jest dostarczyć listę autoryzowanych punktów serwisowych
na terenie Polski, które świadczą serwis pogwarancyjny.
Opis zawarty w tabeli w ofercie Odwołującego:

MIKRONIKA zapewni listę autoryzowanych punktów serwisowych na terenie Polski,
które świadczą serwis pogwarancyjny dostarczonego sprzętu.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Zamawiający nie żądał listy autoryzowanych punktów serwisowych Dostawcy
(zwrócić należy uwagę, że nie: Wykonawcy, Producenta - tylko Dostawcy) w ofercie
wstępnej, a jedynie potwierdzenia zrealizowania tej funkcjonalności i sposobu jej
realizacji. Odwołujący opisał, że zrealizuje to wymaganie poprzez samodzielne
dostarczenie listy Zamawiającemu.
Informacja ta stanowi krótki opis realizacji wymaganej funkcjonalności, wobec czego
postawiony wymóg należy uznać za spełniony.
Na marginesie należy dodać, że na etapie oferty wstępnej, kiedy nie określa się
szczegółowo numerów katalogowych sprzętu, nie ma możliwości określenia punktów
serwisowych, ponieważ punkty serwisowe świadczą usługi w zakresie konkretnych
wyrobów dostarczanych z konkretnego zakładu przez konkretnego dostawcę, dlatego
ich podanie jest możliwe dopiero po ustaleniu w projekcie konkretnych numerów
katalogowych i ustaleniu dostawcy.
26.
Zastrzeżenie:
Brak propozycji urządzeń spełniających min. wymagania SIWZ.
Wymaganie 8.2.:
UPS-y AC, spełniające poniższe założenia należy zainstalować w obiektach:
Szamotuły, Włocławek, Ciechanów, Zambrów, Kondratki. Instalacja UPS musi
obejmować swoim zakresem dystrybucję zasilania.
Opis zawarty w tabeli w ofercie Odwołującego:
W ramach zamówienia MIKRONIKA dostarczy i zainstaluje UPS-y firmy EATON
o
odpowiednich parametrach technicznych w obiektach Szamotuły, Włocławek,
Ciechanów, Zambrów, Kondratki. Instalacja UPS będzie obejmować swoim
zakresem dystrybucję zasilania.
Wszystkie UPS’y będą wymieniać dane z systemem SCADA po protokole SNMP v3.
Oferowany system SCADA SYNDIS zapewnia rejestrację i wyświetlanie na
zbudowanych maskach ekranowych takich parametrów pracy urządzenia UPS jak
stan sieci po stronie pierwotnej i wtórnej, obciążenie, stan naładowania i temperatura
baterii oraz alarmy wewnętrzne z urządzenia.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:

Dla urządzeń, których dobór wymaga przeprowadzenia analiz i projektu, czyli
czynności, które stanowią element zamówienia, wskazano jedynie przewidywanego
producenta. Do urządzeń takich należy UPS, dla którego Zamawiający podał moc
minimalną. Moc wymagana urządzenia, będąca podstawą doboru typu, może być
określona dopiero na etapie projektu, po zbilansowaniu wszystkich potrzeb w tym
zakresie.
Ustalenie
mocy
maksymalnej
jest
warunkiem
ustalenia
typu
zastosowanego urządzenia, dla zapewnienia gwarantowanego czasu zasilania, który
został również określony jako parametr minimalny.
Odwołujący w ramach krótkiego opisu realizacji funkcjonalności tego punktu wskazał,
że dostarczy i zainstaluje UPS-y firmy EATON o odpowiednich parametrach
technicznych w obiektach Szamotuły, Włocławek, Ciechanów, Zambrów, Kondratki.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, 27. Zastrzeżenie:
Brak propozycji urządzeń spełniających min. wymagania SIWZ.
Wymaganie 8.2.1.. 8.2.2.. 8.2.3.. 8.2.4.. 8.2.5.. 8.2.6.. 8.2.7., 8.2.8.. 8.2.9.. 8.2.10.,
8.2.11.. 8.2.12.. 8.2.13.. 8.2.14.. 8.2.14.1.. 8.2.14.9.. 8.2.15.:
8.2.1. Zasilanie 3 fazowe z wyjściem 1 fazowym, pozwalające na pracę urządzenia
bez użycia baterii przy zaniku jednej z faz napięcia zasilającego
8.2.2. Minimalna moc 10 KW
8.2.3. Obudowa do instalacji w szafie rakowej w raz z szafą w standardzie 19”
8.2.4. Baterie zainstalowane na stojakach zewnętrznych
8.2.5. Galwaniczna izolacja wejścia - wyjścia
8.2.6. Budowa modułowa z możliwością wymiany uszkodzonego modułu mocy bez
przerwy napięcia gwarantowanego na wyjściu urządzenia
8.2.7. Zastosowanie w pełni redundantnej architektury n+1 z podwójną konwersją
(true on-line)
8.2.8. Sprawność minimum 90%
8.2.9. Dopuszczalna temperatura pomieszczenia pracy w zakresie od 0 - 40°C
8.2.10.
Dopuszczalna temperatura pomieszczenia pracy w zakresie od 0 -
40°C
8.2.11.
Współczynnik THDI poniżej 5%
8.2.12.
Tolerancja napięcia wejściowego: minimum -20% - +15% przy 100%
obciążeniu urządzenia

8.2.13.
Możliwość rozbudowy w dostarczonej obudowie w przypadku wzrostu
zapotrzebowania na moc gwarantowaną
8.2.14.
Moduł komunikacji z UPS, z wyświetlaczem pozwalający na:
8.2.14.1.
Kontrolę aktualnego stanu pracy urządzenia
8.2.14.2.
Pomiar i prezentacje wejściowych i wyjściowych prądów, napięć , mocy
i czasu pracy - przy pracy z baterii.
8.2.14.3.
Możliwość doinstalowania dodatkowej ładowarki baterii pozwalającej na
szybsze doładowanie baterii.
8.2.14.4.
Stały nadzór nad stanem urządzenia i baterii.
8.2.14.5.
Możliwość przeprowadzenia testu funkcjonalnego baterii akumulatorów.
8.2.14.6.
By-pass automatyczny oraz ręczny, zewnętrzny.
8.2.14.7.
Moduł do nadzoru SNMP v3
8.2.14.8.
Możliwość wymiany baterii „na gorąco”- bez konieczności wyłączenia
urządzenia i odbiorów.
8.2.14.9.
Wyjście napięcia gwarantowanego na odbiory poprzez zabudowaną w
szafie rozdzielnice odbiorową wraz z zabezpieczeniami przepięciowymi i
przeciążeniowymi poszczególnych odbiorów
8.2.15.
Czas podtrzymania z baterii przy pełnym obciążeniu 30 minut
Wszystkie UPS’y powinny wymieniać dane z systemem SCADA po protokole SNMP
v3. SCADA musi rejestrować i wyświetlać na zbudowanych maskach ekranowych
takie parametry pracy UPS’a jak: stan sieci po stronie pierwotnej i wtórnej,
obciążenie, stan naładowania i temperatura baterii oraz alarmy wewnętrzne z
urządzenia.
Opis zawarty w tabeli w ofercie Odwołującego:
W ramach realizacji zamówienia Zamawiającemu zostaną dostarczone urządzenia
firmy EATON o parametrach co najmniej spełniających wymagania Zamawiającego.
Dokładna Specyfikacja zostanie podana w ofercie ostatecznej, będącej wynikiem
ustaleń negocjacyjnych.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Dla urządzeń, których dobór wymaga przeprowadzenia analiz i projektu, czyli
czynności, które stanowią element zamówienia, wskazano jedynie przewidywanego
producenta. Do urządzeń takich należy UPS, dla którego Zamawiający podał moc
minimalną. Moc wymagana urządzenia, będąca podstawą doboru typu, może być
określona dopiero na etapie projektu, po zbilansowaniu wszystkich potrzeb w tym

zakresie.
Ustalenie
mocy
maksymalnej
jest
warunkiem
ustalenia
typu
zastosowanego urządzenia, dla zapewnienia gwarantowanego czasu zasilania, który
został również określony jako parametr minimalny.
Odwołujący w ramach krótkiego opisu realizacji funkcjonalności tego punktu wskazał,
że dostarczy i zainstaluje UPS-y firmy EATON o odpowiednich parametrach
technicznych.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
28.
Zastrzeżenie:
Brak opisu propozycji/sposobu realizacji wymagań SIWZ.
Wymaganie od 8.3.1. do 8.3.22.:
8.3.1. Każdy z serwerów musi być wyposażony w nie mniej niż 2 procesory 64-
bitowe sześciordzeniowe
8.3.2. Procesory każdego z serwerów aplikacji muszą zapewniać w sumie wydajność
dającą wynik Baseline co najmniej na poziomie 250 punktów, według standardowego
testu SPECfp_rate2006 (www.spec.org)
8.3.3. Co najmniej 96GB pamięci operacyjnej RAM dla każdego z serwerów o
parametrach minimum DDR3 1333MHz
8.3.4. Każdy z serwerów musi być wyposażony w minimum 4 x 300 GB dyski twarde
SAS, napęd DVD typu +/- RW
8.3.5. Karta grafiki wysokiej rozdzielczości min. 1600 x 1200
8.3.6. Min. 2 redundantne zasilacze z funkcjonalnością Hot Swap
8.3.7. Wentylatory z funkcjonalnością Hot Swap
8.3.8. Każdy serwer musi być wyposażony w co najmniej 2 porty 10 Gb Ethernet, co
najmniej 2
porty 1 Gigabit Ethernet,
8.3.9. Każdy serwer musi być wyposażony w kartę zdalnego zarządzania
8.3.10.
Każdy z serwerów musi być połączony do elementów sieciowych za
pomocą łączy
o
zagregowanej przepustowości całkowitej wynoszącej minimum 40 Gb/s
realizowanej w technologii Infiniband 1xDual-Port QDR lub 5 x FC 8 Gb/s i
zapewniających pełną redundancję,
8.3.11.
Dodanie lub odjęcie serwera do platformy sprzętowej aplikacji nie może
powodować przestoju w pracy aplikacji,

8.3.12.
Serwery muszą pracować pod kontrolą systemu operacyjnego Linux lub
UNIX certyfikowanego przez producenta oprogramowania aplikacyjnego,
8.3.13.
Min. 6 gniazd PCI Express
8.3.14.
Min. 4 porty USB
8.3.15.
Kontrolery dysków lokalnych w serwerach muszą wspierać redundancję
na poziomie co najmniej RAID 1,5,6,10,-za dobór typu RAID odpowiada Wykonawca
8.3.16.
Port szeregowy (niezależny od portu zarządzania)
8.3.17.
Poziom głośności zgodnie z normą IS09296
8.3.18.
Montaż w szafie 19” na szynach teleskopowych (pełne wysunięcie) z
organizatorem kabli
8.3.19.
Pamięć RAM należy przewidzieć z zapasem 100% w stosunku do
normalnej zajętości pamięci zdefiniowanej w parametrach wydajnościowych i
zmierzonych w trakcie testu wydajnościowego.
8.3.20.
Zajętość pamięci dyskowej w chwili przekazania systemu do
eksploatacji i pełnym zdefiniowaniu modelu sieci powinna wynosić 25% całkowitej
pojemności dysków.
8.3.21.
Średnie obciążenie normalne procesorów zdefiniowane w parametrach
wydajnościowych i zmierzone w trakcie testu wydajnościowego nie może
przekraczać 25%
8.3.22.
Za skalowanie i dobór urządzeń odpowiada Wykonawca.
Opis zawarty w tabeli w ofercie Odwołującego:
W ramach realizacji zamówienia Zamawiającemu zostaną dostarczone serwery
aplikacji głównej HP DL380p Gen8 o parametrach co najmniej spełniających
wymagania Zamawiającego. Dokładna specyfikacja zostanie podana w ofercie
ostatecznej, będącej wynikiem ustaleń negocjacyjnych.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych
urządzeń. Dane te wyczerpują postawione w ofercie wstępnej wymagania krótkiego
opisu.
Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po
określeniu przez Zamawiającego liczby użytkowników systemu, co zgodnie z
udzieloną odpowiedzią nastąpi w fazie negocjacji. Podane przez Zamawiającego
dane
minimalne
mogą
być
niewystarczające
do
realizacji
zadania,
a
odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży po stronie

Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie wstępnej
dokonać nie może, a Zamawiający - bez narażania się na zarzut naruszenia
przepisów - nie może żądać.
w punkcie 8.2 Zamawiający jako brak dyskwalifikujący ofertę wskazał brak podania
typu urządzenia, natomiast w punkcie o takim samym charakterze, w którym typ
podano, brakiem dyskwalifikującym jest rzekomy brak innego opisu. 29.

Zastrzeżenie:
Brak opisu propozycji/sposobu realizacji wymagań SIWZ.
Wymaganie od 8.4.:
Serwery baz danych archiwalnych (2 redundantne serwery w Dyspozytorni
Ogólnopolskiej,
2
redundantne serwery w Dyspozytorni Rezerwowej) powinny spełniać
następujące minimalne wymagania:
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA dostarczy, zainstaluje i skonfiguruje nie mniej niż po 2 redundantne
serwery baz danych archiwalnych HP DL380p Gen8 o odpowiednich parametrach
technicznych w Dyspozytorni Ogólnopolskiej i w Dyspozytorni Rezerwowej. Bliższe
dane w rozdziale „Ogólny opis architektury systemu”. Ostateczna propozycja
dotycząca serwerów baz danych
archiwalnych HP DL380p Gen8 zostanie podana w ofercie ostatecznej, będącej
wynikiem ustaleń negocjacyjnych.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych
urządzeń. Dane te wyczerpują postawione w ofercie wstępnej wymagania krótkiego
opisu.
Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po
określeniu przez Zamawiającego liczby użytkowników systemu, co zgodnie z
udzieloną odpowiedzią nastąpi w fazie negocjacji. Podane przez Zamawiającego
dane
minimalne
mogą
być
niewystarczające
do
realizacji
zadania,
a
odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży po stronie
Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie wstępnej
dokonać nie może, a Zamawiający - bez narażania się na zarzut naruszenia
przepisów - nie może żądać.
30.
Zastrzeżenie:

Brak opisu propozycji/sposobu realizacji wymagań SIWZ.
Wymaganie od 8.4.1. do 8.4.22.:
8.4.1. Każdy z serwerów musi być wyposażony w nie mniej niż 2 procesory 64-
bitowe sześciordzeniowe
8.4.2. Procesory każdego z serwerów aplikacji muszą zapewniać w sumie wydajność
dającą wynik Baseline co najmniej na poziomie 250 punktów, według standardowego
testu SPECfp_rate2006 (www.spec.org)
8.4.3. Co najmniej 96GB pamięci operacyjnej RAM dla każdego z serwerów o
parametrach minimum DDR3 1333MHz
8.4.4. Każdy z serwerów musi być wyposażony w minimum 4 x 300 GB dyski twarde
SAS, napęd DVD typu +/- RW
8.4.5. Karta grafiki wysokiej rozdzielczości min. 1600 x 1200
8.4.6. Min. 2 redundantne zasilacze z funkcjonalnością Hot Swap
8.4.7. Wentylatory z funkcjonalnością Hot Swap
8.4.8. Każdy serwer musi być wyposażony w co najmniej 2 porty 10 Gb Ethernet, co
najmniej
2
porty 1 Gigabit Ethernet,
8.4.9. Każdy serwer musi być wyposażony w kartę zdalnego zarządzania
8.4.10.
Każdy z serwerów musi być połączony do elementów sieciowych za
pomocą łączy
o
zagregowanej przepustowości całkowitej wynoszącej minimum 40 Gb/s
realizowanej
w technologii Infiniband 1xDual-Port QDR lub 5 x FC 8 Gb/s i zapewniających pełną
redundancję,
8.4.11.
Dodanie lub odjęcie serwera do platformy sprzętowej aplikacji nie może
powodować przestoju w pracy aplikacji,
8.4.12.
Serwery muszą pracować pod kontrolą systemu operacyjnego Linux lub
UNIX certyfikowanego przez producenta oprogramowania aplikacyjnego,
8.4.13.
Min. 6 gniazd PCI Express
8.4.14.
Min. 4 porty USB
8.4.15.
Kontrolery dysków lokalnych w serwerach muszą wspierać redundancję
na poziomie co najmniej RAID 1,5,6,10,-za dobór typu RAID odpowiada Wykonawca
8.4.16.
Port szeregowy (niezależny od portu zarządzania)
8.4.17.
Poziom głośności zgodnie z normą IS09296

8.4.18.
Montaż w szafie 19” na szynach teleskopowych (pełne wysunięcie) z
organizatorem kabli
8.4.19.
Pamięć RAM należy przewidzieć z zapasem 100% w stosunku do
normalnej zajętości pamięci zdefiniowanej w parametrach wydajnościowych i
zmierzonych w trakcie testu wydajnościowego.
8.4.20.
Średnie obciążenie normalne procesorów zdefiniowane w parametrach
wydajnościowych i zmierzone w trakcie testu wydajnościowego nie może
przekraczać 25%
8.4.21.
Obciążenie interfejsów sieciowych zdefiniowane w parametrach
wydajnościowych
i
zmierzone w trakcie testu wydajnościowego nie może przekraczać 25%
Opis zawarty w tabeli w ofercie Odwołującego:
W ramach realizacji zamówienia Zamawiającemu zostaną dostarczone serwery baz
danych archiwalnych HP DL380p Gen8 o parametrach co najmniej spełniających
wymagania Zamawiającego. Dokładna specyfikacja zostanie podana w ofercie
ostatecznej, będącej wynikiem ustaleń negocjacyjnych.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych
urządzeń. Dane te wyczerpują postawione w ofercie wstępnej wymagania krótkiego
opisu.
Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po
określeniu przez Zamawiającego ilości użytkowników systemu, co zgodnie z
udzieloną odpowiedzią nastąpi w fazie negocjacji. Podane przez Zamawiającego
dane
minimalne
mogą
być
niewystarczające
do
realizacji
zadania,
a
odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży po stronie
Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie wstępnej
dokonać nie może, a Zamawiający - bez narażania się na zarzut naruszenia
przepisów - nie może żądać.
należy wskazać, że w punkcie 8.2 Zamawiający jako brak dyskwalifikujący ofertę
wskazał brak podania typu urządzenia, natomiast w punkcie o takim samym
charakterze, w którym typ podano, brakiem dyskwalifikującym jest rzekomy brak
innego opisu. Takie stanowisko Zamawiającego pozwala postawić zarzut naruszenia
przepisów PZP.
31.
Zastrzeżenie:

Brak opisu propozycji/sposobu realizacji wymagań SIWZ.
Wymaganie 8.4.22.:
Za skalowanie i dobór urządzeń odpowiada Wykonawca.
Opis zawarty w tabeli w ofercie Odwołującego:
Za skalowanie i dobór urządzeń odpowiada MIKRONIKA.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący w sposób jednoznaczny opisał realizację wymagania oświadczając, że
Odwołujący jest odpowiedzialny za skalowanie i dobór urządzeń poprzez realizację
projektu technicznego i
dokumentacji systemu, których elementami są m. in.
analiza wymagań Zamawiającego, projekty techniczne dla poszczególnych węzłów
systemu czy dokumentacje konfiguracji urządzeń - patrz pkt 12.1 tabeli oferty. W
treści oferty wstępnej, tam gdzie było to możliwe na obecnym etapie, Odwołujący
zaproponował producenta oraz typ urządzenia.
Należy uznać, że wyczerpuje to postawione w SIWZ wymaganie podania krótkiego
opisu dla tego punktu, wobec czego postawiony wymóg należy uznać za spełniony.
32.
Zastrzeżenie:
Brak opisu propozycji/sposobu realizacji wymagań SIWZ.
Wymaganie 8.5.:
wymienione wymagania od 8.5.1 do 8.5.18 (patrz następny punkt)
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA dostarczy, zainstaluje i skonfiguruje Serwery Aplikacji Dodatkowych HP
DL380p Gen8. Bliższe dane w rozdziale „Ogólny opis architektury systemu”.
Ostateczna propozycja dotycząca Serwerów Aplikacji Dodatkowych HP DL380p
Gen8 zostanie podana w ofercie ostatecznej, będącej wynikiem ustaleń
negocjacyjnych.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych
urządzeń.
33.
Zastrzeżenie:
Brak opisu propozycji/sposobu realizacji wymagań SIWZ.
Wymaganie od 8.5.1. do 8.5.17.:
8.5.1. Komputer wieloprocesorowy (płyta główna z możliwością zainstalowania min.
dwóch czterordzeniowych procesorów).
8.5.2. Architektura 64 bitowa

8.5.3. Dysk twardy (możliwość zainstalowania dysków SCSI, SATA lub SAS typu
hot-swap) - dyski w konfiguracji co najmniej RAID 1, po uszkodzeniu dysku i jego
wymianie dyski w macierzy odbudowują się max. 2 h
8.5.4. Dedykowany sprzętowy kontroler dyskowy RAID zapewniający funkcjonalność
zabezpieczenia na poziomach: RAID 1, 5, 10 - za dobór typu RAID odpowiada
Wykonawca
8.5.5. Napęd DVD typu +/- RW
8.5.6. Karta grafiki wysokiej rozdzielczości min. 1600 x 1200
8.5.7. Min. 2 redundantne wentylatory z funkcjonalnością Hot Swap
8.5.8. Min. 4 porty Gbit Ethernet RJ45
8.5.9. Dodatkowy
dedykowany
port
Ethernet
10/100
sieci
zarządzającej
(dedykowany moduł zarządzający umożliwiający zdalny restart serwera i pełne
zarządzanie włącznie z przejęciem konsoli tekstowej)
8.5.10.
Min. 6 gniazd PCI Express
8.5.11.
Min. 4 porty USB
8.5.12.
Port szeregowy (niezależny od portu zarządzania)
8.5.13.
Poziom głośności zgodnie z normą IS09296
8.5.14.
Montaż w szafie 19” na szynach teleskopowych (pełne wysunięcie) z
organizatorem kabli
8.5.15.
Pamięć RAM należy przewidzieć z zapasem 100% w stosunku do
normalnej zajętości pamięci zdefiniowanej w parametrach wydajnościowych i
zmierzonych w trakcie testu wydajnościowego.
8.5.16.
Zajętość pamięci dyskowej w chwili przekazania systemu do
eksploatacji i pełnym zdefiniowaniu modelu sieci powinna wynosić 25% całkowitej
pojemności dysków.
8.5.17.
Średnie obciążenie normalne procesorów zdefiniowane w parametrach
wydajnościowych i zmierzone w trakcie testu wydajnościowego nie może
przekraczać 25%
Opis zawarty w tabeli w ofercie Odwołującego:
W ramach realizacji zamówienia Zamawiającemu zostaną dostarczone Serwery
Aplikacji Dodatkowych HP DL380p Gen8 o parametrach co najmniej spełniających
wymagania Zamawiającego. Dokładna specyfikacja zostanie podana w ofercie
ostatecznej, będącej wynikiem ustaleń negocjacyjnych.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:

Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych
urządzeń. Dane te wyczerpują postawione w SIWZ wymaganie podania krótkiego
opisu.
Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po
określeniu przez Zamawiającego liczby użytkowników systemu, co zgodnie z
udzieloną przez Zamawiającego odpowiedzią nastąpi w fazie negocjacji. Podane
przez Zamawiającego dane minimalne mogą być niewystarczające do realizacji
zadania, a odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży
po stronie Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie
wstępnej dokonać nie może, a Zamawiający - bez narażania się na zarzut
naruszenia przepisów - nie może żądać.
Na marginesie należy wskazać, że w punkcie 8.2 Zamawiający jako brak
dyskwalifikujący ofertę wskazał brak podania typu urządzenia, natomiast w punkcie o
takim samym charakterze, w którym typ podano, brakiem dyskwalifikującym jest
rzekomy brak innego opisu.
34.
Zastrzeżenie:
Brak opisu propozycji/sposobu realizacji wymagań SIWZ.
Wymaganie 8.5.18.:
Za skalowanie i dobór urządzeń odpowiada Wykonawca.
Opis zawarty w tabeli w ofercie Odwołującego:
Za skalowanie i dobór urządzeń odpowiada MIKRONIKA.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący w sposób jednoznaczny opisał realizację wymagania oświadczając, że
Odwołujący jest odpowiedzialny za skalowanie i dobór urządzeń poprzez realizację
projektu technicznego i
dokumentacji systemu, których elementami są m. in.
analiza wymagań Zamawiającego, projekty techniczne dla poszczególnych węzłów
systemu czy dokumentacje konfiguracji urządzeń - patrz pkt 12.1 tabeli oferty.
W treści oferty wstępnej, tam gdzie było to możliwe na obecnym etapie, Odwołujący
zaproponował producenta oraz typ urządzenia.
Należy uznać, że wyczerpuje to postawione w SIWZ wymaganie podania krótkiego
opisu dla tego punktu, wobec czego postawiony wymóg należy uznać za spełniony.
35.
Zastrzeżenie:
Brak propozycji urządzeń spełniających min. wymagania SIWZ.
Wymaganie 8.10.:

Serwery komunikacyjne będą służyły do wymiany danych pomiędzy systemem
SCADA a systemami zewnętrznymi. Serwer powinien spełniać następujące
minimalne wymagania.
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA dostarczy, zainstaluje i skonfiguruje serwery komunikacyjne typu HP
DL380p Gen8, przeznaczone do wymiany danych pomiędzy systemem SCADA a
systemami zewnętrznymi. Bliższe dane w rozdziale „Ogólny opis architektury
systemu”. Ostateczna propozycja dotycząca serwerów komunikacyjnych HP DL380p
Gen8 zostanie podana w ofercie ostatecznej, będącej wynikiem ustaleń
negocjacyjnych.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych
urządzeń. Dane te wyczerpują postawione w SIWZ wymaganie podania krótkiego
opisu.
Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po
określeniu przez Zamawiającego liczby użytkowników systemu, co zgodnie z
udzieloną przez Zamawiającego odpowiedzią nastąpi w fazie negocjacji. Podane
przez Zamawiającego dane minimalne mogą być niewystarczające do realizacji
zadania, a odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży
po stronie Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie
wstępnej dokonać nie może, a Zamawiający - bez narażania się na zarzut
naruszenia przepisów - nie może żądać.
Na marginesie należy wskazać, że w punkcie 8.2 Zamawiający jako brak
dyskwalifikujący ofertę wskazał brak podania typu urządzenia, natomiast w punkcie o
takim samym charakterze, w którym typ podano, brakiem dyskwalifikującym jest
rzekomy brak innego opisu.
36.
Zastrzeżenie:
Brak propozycji urządzeń spełniających min. wymagania SIWZ.
Wymaganie od 8.10.1. do 8.10.19.:
8.10.1.
Komputer
wieloprocesorowy
(płyta
główna
z
możliwością
zainstalowania min. dwóch dwu lub czterordzeniowych procesorów).
8.10.2.
Architektura 64 bitowa

8.10.3.
Dysk twardy (możliwość zainstalowania dysków SCSI, SATA lub SAS
typu hot-swap) - dyski w konfiguracji co najmniej RAID 1, po uszkodzeniu dysku i
jego wymianie dyski w macierzy odbudowują się max. 2 h
8.10.4.
Dedykowany sprzętowy kontroler dyskowy RAID zapewniający
funkcjonalność zabezpieczenia na poziomach: RAID 1, 5, 10 - za dobór typu RAID
odpowiada Wykonawca
8.10.5.
Napęd DVD typu +/- RW
8.10.6.
Karta grafiki rozdzielczości min. 1600 x 1200
8.10.7.
Min. 2 redundantne zasilacze z funkcjonalnością Hot Swap
8.10.8.
Min. 2 redundantne wentylatory z funkcjonalnością Hot Swap
8.10.9.
Min. 4 porty Gbit Ethernet RJ45, dodatkowy dedykowany port Ethernet
10/100 sieci zarządzającej (dedykowany moduł zarządzający umożliwiający zdalny
restart serwera i pełne zarządzanie włącznie z przejęciem konsoli tekstowej)
8.10.10.
Min. 6 gniazd PCI Express
8.10.11.
Min. 4 porty USB
8.10.12.
Port szeregowy
8.10.13.
Poziom głośności zgodnie z normą IS09296
8.10.14.
Montaż w szafie 19” na szynach teleskopowych (pełne wysunięcie) z
organizatorem kabli
8.10.15.
Pamięć RAM należy przewidzieć z zapasem 100% w stosunku do
normalnej zajętości
8.10.16.
Pamięci zdefiniowanej w parametrach wydajnościowych i zmierzonych
w trakcie testu wydajnościowego.
8.10.17.
Zajętość pamięci dyskowej w chwili przekazania systemu do
eksploatacji i pełnym
8.10.18.
Zdefiniowaniu modelu sieci powinna wynosić 25% całkowitej
pojemności dysków.
8.10.19.
Średnie obciążenie normalne procesorów zdefiniowane w parametrach
wydajnościowych i zmierzone w trakcie testu wydajnościowego nie może
przekraczać 25%
Opis zawarty w tabeli w ofercie Odwołującego:
W ramach realizacji zamówienia Zamawiającemu zostaną dostarczone serwery
komunikacyjne HP DL380p Gen8 o parametrach co najmniej spełniających

wymagania Zamawiającego. Dokładna specyfikacja zostanie podana w ofercie
ostatecznej, będącej wynikiem ustaleń negocjacyjnych.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący podał w tabeli krótki opis wskazujący typ i producenta przewidywanych
urządzeń. Dane te wyczerpują postawione w SIWZ wymaganie podania krótkiego
opisu.
Bardziej szczegółowe podanie danych o serwerach będzie możliwe dopiero po
określeniu przez Zamawiającego liczby użytkowników systemu, co zgodnie z
udzieloną przez Zamawiającego odpowiedzią nastąpi w fazie negocjacji. Podane
przez Zamawiającego dane minimalne mogą być niewystarczające do realizacji
zadania, a odpowiedzialność za dobór i skalowanie urządzeń, zgodnie z SIWZ, leży
po stronie Wykonawcy, wobec czego Wykonawca szczegółowego doboru w ofercie
wstępnej dokonać nie może, a Zamawiający - bez narażania się na zarzut
naruszenia przepisów - nie może żądać.
Na marginesie należy wskazać, że w punkcie 8.2 Zamawiający jako brak
dyskwalifikujący ofertę wskazał brak podania typu urządzenia, natomiast w punkcie o
takim samym charakterze, w którym typ podano, brakiem dyskwalifikującym jest
rzekomy brak innego opisu.
37.
Zastrzeżenie:
Brak propozycji urządzeń spełniających min. wymagania SIWZ.
Wymaganie 8.10.20.:
Za skalowanie i dobór urządzeń odpowiada Wykonawca.
Opis zawarty w tabeli w ofercie Odwołującego:
Za skalowanie i dobór urządzeń odpowiada MIKRONIKA.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Odwołujący w sposób jednoznaczny opisał realizację wymagania oświadczając, że to
Odwołujący jest odpowiedzialny za skalowanie i dobór urządzeń poprzez realizację
projektu technicznego i dokumentacji systemu, których elementami są m. in. analiza
wymagań Zamawiającego, projekty techniczne dla poszczególnych węzłów systemu
czy dokumentacje konfiguracji urządzeń - patrz pkt 12.1 tabeli oferty.
W treści oferty wstępnej, tam gdzie było to możliwe na obecnym etapie, Odwołujący
zaproponował producenta oraz typ urządzenia.
Należy uznać, że wyczerpuje to postawiony w SIWZ wymóg podania krótkiego opisu
dla tego punktu, wobec czego postawiony wymóg należy uznać za spełniony.

38.
Zastrzeżenie:
Oferent nie uzasadnił z czego wynika możliwość spełnienia wymagań dotyczących
przetwarzania, tym samym nie opisał sposobu realizacji wymagania. Dokumentacja
systemu nie odnosi się do tego zagadnienia.
Wymaganie od 9.5.1. do 9.5.8.:
9.5.1. Czas pomiędzy zmianą wartości a jej zarejestrowaniem w bazie danych czasu
rzeczywistego: <1s
9.5.2. Czas pomiędzy zarejestrowaniem wartości w bazie danych czasu
rzeczywistego a wyświetleniem jej na ekranie <0.1 s
9.5.3. Czas pomiędzy zarejestrowaniem wartości w bazie danych czasu
rzeczywistego a wyświetleniem jej w linii zdarzeń, liście alarmów lub zdarzeń (lub
jednocześnie we wszystkich trzech miejscach) <0.1 s
9.5.4. Czas pomiędzy wydaniem polecenia przez operatora a rozpoczęciem
realizacji polecenia <1s
9.5.5. Czas pomiędzy wydaniem polecenia przez operatora a zarejestrowaniem tego
faktu w bazie danych czasu rzeczywistego oraz liście zdarzeń <0.1 s
9.5.6.Czas pomiędzy wydaniem przez operatora polecenia ustawienia wartości
zadanej a zarejestrowaniem tego faktu w bazie danych czasu rzeczywistego i w liście
zdarzeń <0.1 s
9.5.7. Czas pomiędzy wydaniem przez operatora polecenia ustawienia wartości
zadanej a ustawieniem jej w urządzeniu realizującym zadanie <1s
9.5.8. Czas pomiędzy zarejestrowaniem zmiany wartości zmiennej w bazie danych
czasu rzeczywistego a zarejestrowaniem tej zmiany w bazie danych archiwalnych
<5s.
Opis zawarty w tabeli w ofercie Odwołującego:
Oferowany system SCADA SYNDIS zapewni następujące czasy przetwarzania:
Czas pomiędzy zmianą wartości a jej zarejestrowaniem w bazie danych czasu
rzeczywistego: <1 s;
Czas pomiędzy zarejestrowaniem wartości w bazie danych czasu rzeczywistego a
wyświetleniem jej na ekranie <0.1 s;
Czas pomiędzy zarejestrowaniem wartości w bazie danych czasu rzeczywistego a
wyświetleniem jej w linii zdarzeń, liście alarmów lub zdarzeń (lub jednocześnie we
wszystkich trzech miejscach) <0.1 s;

Czas między wydaniem polecenia przez operatora a rozpoczęciem realizacji
polecenia <1 s;
Czas pomiędzy wydaniem polecenia przez operatora a zarejestrowaniem tego faktu
w bazie danych czasu rzeczywistego oraz liście zdarzeń <0.1 s;
Czas pomiędzy wydaniem przez operatora polecenia ustawienia wartości zadanej a
zarejestrowaniem tego faktu w bazie danych czasu rzeczywistego i w liście zdarzeń
<0.1 s;
Czas pomiędzy wydaniem przez operatora polecenia ustawienia wartości zadanej a
ustawieniem jej w urządzeniu realizującym zadanie <1s;
Czas pomiędzy zarejestrowaniem zmiany wartości zmiennej w bazie danych czasu
rzeczywistego a zarejestrowaniem tej zmiany w bazie danych archiwalnych <5s.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie wymagań wydajnościowych określonych w punktach od 9.5.1 do 9.5.8
specyfikacji w ofercie podano istotne informacje dotyczące sposobu realizacji
funkcjonalności, mające wpływ na wydajność systemu, tj.:
a. wskazano, że system SCADA zostanie zrealizowany za pośrednictwem
dedykowanego do takich rozwiązań systemu SYNDIS - strona 5 oferty, który jest
wysokiej klasy narzędziem służącym do wizualnej prezentacji stanu nadzorowanych
obiektów oraz realizacji sterowania tych obiektów - strona 8 „Skrypt operatora”.
Zgodnie z informacją zawartą na stronie 7dokumentu „Skrypt edytorski - Informacja o
systemie SYNDIS RV” system SYNDIS RV jest uniwersalnym narzędziem do
tworzenia aplikacji przeznaczonych zarówno dla potrzeb wspomagania ruchu, służb
zabezpieczeń, jak również dla wspomagania eksploatacji. Modułowa struktura
sprzętowo-programowa umożliwia jego adaptację do różnych warunków i potrzeb.
Systemy tej klasy ze swojej natury zapewniają spełnienie postawionych wymagań,
które są typowe dla takich systemów;
b. przedstawiono architekturę systemu pozwalającą na uzyskanie wymaganych
wskaźników;
c. podano typy przewidywanego do użycia sprzętu, odpowiadającego za szybkość
aplikacji.
Informacje powyższe łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Więcej informacji nie można było podać, ponieważ Zamawiający nie podał
kluczowych informacji, tj. liczby użytkowników deklarując omówienie tych kwestii

podczas negocjacji, Dopiero po choćby przybliżonym podaniu liczby użytkowników
możliwe będzie podanie większej ilości szczegółów odpowiednich rozwiązań.
39.
Zastrzeżenie:
W ofercie wstępnej na modernizację systemu SACAD SGT p.1.13 oferent potwierdza
brak możliwości realizacji w pełni tego wymagania.
Wymaganie 11.1.1.1.:
Przy projektowaniu i realizacji interfejsów Wykonawca musi zapewnić możliwość
pobierania danych do starego systemu SCADA na dotychczasowych zasadach do
czasu dokonania odbioru technicznego nowego systemu SCADA.
Opis zawarty w tabeli w ofercie Odwołującego:
Przy projektowaniu i realizacji interfejsów MIKRONIKA zapewni możliwość
pobierania danych do starego systemu SCADA na dotychczasowych zasadach do
czasu dokonania odbioru technicznego dostarczonego systemu SCADA SYNDIS.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
Stwierdzenie, że oferent Mikronika potwierdza brak możliwości realizacji w pełni tego
wymagania pozostaje w sprzeczności z treścią złożonej przez Odwołującego oferty
wstępnej. W tabeli w pozycji punkt 1.13 Odwołujący wpisał „TAK”, co oznacza, że
potwierdza, że funkcjonalność zostanie zrealizowana. W punkcie „Uwagi” nie podano
żadnego zastrzeżenia w tym zakresie.
40.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu, m.in. [Skrypt Operatora, System SYNDIS RV, Dokumentacja szkoleniowa],
[Skrypt Administratora, Podstawy i obsługa systemu, Dokumentacja szkoleniowa] nie
daje kompletnej i precyzyjnej odpowiedzi..
Wymaganie 11.1.1.7.:
11.1.1.7.
Mechanizmy opisane poniższych punktach muszą posiadać co najmniej
na-stępujące właściwości:
11.1.1.7.1. Możliwość konfiguracji okresu automatycznego uzupełniania danych
(dla danych archiwalnych).
11.1.1.7.2. Możliwość konfiguracji zakresu pobieranych danych.
11.1.1.7.3. Możliwość konfiguracji wielu adresów skąd pobierane są dane.
11.1.1.7.4. Możliwość pobierania danych z wielu rozłącznych obszarów danych.
11.1.1.7.5. Możliwość przejęcia stempla czasowego dla danych, które są nim
opatrzone w źródle.

11.1.1.7.6. Dla połączeń ma być prowadzony ciągły nadzór na poprawnością
działania łącza niezależnie od tego czy jest aktualnie wykorzystywane (łą-cze
podstawowe) czy nie (łącze zapasowe).
11.1.1.7.7. Awaria łącza ma być wykrywana nie później niż 5s od momentu
uszkodzenia dla łącza podstawowego i nie później niż 30 s dla łącza zapasowego.
11.1.1.7.8. W wypadku wykrycia awarii łącza podstawowego przełączenie na łącze
zapasowe ma nastąpić automatycznie.
11.1.1.7.9. Przełączenie na łącze zapasowe ma nastąpić nie później niż 2s od
momentu wykrycia awarii.
Opis zawarty w tabeli w ofercie Odwołującego:
Wszystkie interfejsy zewnętrzne opracowane i zrealizowane przez MIKRONIKĘ będą
się cechować między innymi:
Możliwością konfiguracji okresu automatycznego uzupełniania danych (dla danych
archiwalnych);
•Możliwością konfiguracji zakresu pobieranych danych;
•Możliwością konfiguracji wielu adresów, skąd pobierane są dane;
•Możliwością pobierania danych z wielu rozłącznych obszarów danych;
•Możliwością przejęcia stempla czasowego dla danych, które są nim opatrzone w
źródle;
•Połączenia będą w sposób ciągły nadzorowane pod kątem poprawności działania
łącza, niezależnie od tego, czy jest aktualnie wykorzystywane (łącze podstawowe)
czy nie (łącze zapasowe);
•Awaria łącza będzie wykrywana nie później niż 5s od momentu uszkodzenia dla
łącza podstawowego i nie później niż 30 s dla łącza zapasowego;
•W wypadku wykrycia awarii łącza podstawowego przełączenie na łącze zapasowe
będzie następowało automatycznie;
•Przełączenie na łącze zapasowe nastąpi nie później niż 2s od momentu wykrycia
awarii. Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty,
Poinformował także, że wymaganie zostanie zrealizowane w zakresie takim, jak
postawiono.

Dodatkowe informacje podano na rysunkach iw opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli,
rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie
posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie
wyraził w SIWZ.

41 Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.2:
11.1.2. Interfejs do Pomiarowni Kondratki i SSRP Włocławek.
11.1.2.1.
Uruchomić pobieranie danych bieżących za pomocą protokołów
opisanych w załączniku nr 1.
11.1.2.2.
Uruchomić pobieranie zamrożonych stanów liczników za pomocą
protokołu opisanego w załączniku nr 1. Zrealizowany mechanizm ma posiadać
funkcje automatycznego uzupełnienia brakujących stanów liczników co najmniej 62
dni wstecz.
11.1.2.3.
Uruchomienie pobierania danych bieżących i archiwalnych za pomocą
protokołu Gazmodem-2. Protokół ten będzie pracować w oparciu o łącze
Ethernet/TCP/lP.
11.1.2.4.
Interfejs
GazModem-2
ma
być
wyposażony
w
mechanizm
automatycznego uzupełniania brakujących danych minimum 62 dni wstecz.
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA opracuje i zrealizuje Interfejs do Pomiarowni Kondratki i SSRP
Włocławek. Realizacja będzie między innymi obejmować:
•
uruchomienie pobierania danych bieżących za pomocą wymaganych
protokołów.

•
uruchomienie pobierania zamrożonych stanów liczników za pomocą
wymaganego protokołu. Zrealizowany mechanizm będzie posiadać funkcje
automatycznego uzupełnienia
brakujących stanów liczników co najmniej 62 dni wstecz.
•
uruchomienie pobierania danych bieżących i archiwalnych za pomocą
protokołu Gazmodem- 2. Protokół ten będzie pracować w oparciu o łącze
Ethernet/TCP/lP.
Wyposażenie Interfejsu GazModem-2 w mechanizm automatycznego uzupełniania
brakujących danych minimum 62 dni wstecz.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.
Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda
kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja
mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.

Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
42.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.3:
11.1.3.
Interfejs do Systemów Automatyki Tłoczni (SCS).
11.1.3.1.
Uruchomić pobieranie danych bieżących za pomocą protokołów
opisanych w załączniku nr 2.
11.1.3.2.
Zrealizować algorytmy sterowania opisane w załączniku nr 2.
11.1.3.3.
Algorytmy powinny być zrealizowane w języku wysokiego poziomu.
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA opracuje i zrealizuje Interfejs do Systemów Automatyki Tłoczni (SCS).
Realizacja będzie między innymi obejmować:
•
Uruchomienie pobierania danych bieżących za pomocą wymaganych
protokołów.
•
Zrealizowanie wymaganych algorytmów sterowania w języku wysokiego
poziomu.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano w na rysunkach i w opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.
Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku.

Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
43.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.4:
11.1.4.
Interfejs do Sterowników Turbokompresorów (UCS).
11.1.4.1.
Uruchomić pobieranie danych bieżących za pomocą protokołu
opisanego w załączniku nr 3.
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA opracuje i zrealizuje Interfejs do Sterowników Turbokompresorów
(UCS). Realizacja będzie między innymi obejmować uruchomienie pobierania
danych bieżących za pomocą wymaganego protokołu.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w
rozdziale
1.13 Organizacja zbierania i wystawiania danych.

Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda
kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja
mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
44.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.5:
11.1.5.
Interfejs do systemu diagnostyki turbokompresorów CCC.
11.1.5.1.
Uruchomić
udostępnianie
danych
dla
systemów
diagnostyki
turbokompresorów w tłoczniach Kondratki i Włocławek. Udostępniane dane
pochodzić będą ze sterowników SCS i U CS tłoczni.
11.1.5.2.
Do momentu odbioru technicznego interfejsu dane udostępniane będą
ze starego systemu SCADA. Przełączenie na udostępnianie z nowego systemu
SCADA nastąpi po odbiorze technicznym interfejsu.
11.1.5.3.
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
wewnętrznego.
11.1.5.4.
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy ma być wykonywane ręcznie.
Opis zawarty w tabeli w ofercie Odwołującego:

MIKRONIKA opracuje i zrealizuje Interfejs do Pomiarowni Kondratki i SSRP
Włocławek. Realizacja będzie między innymi obejmować:
•
uruchomienie pobierania danych bieżących za pomocą wymaganych
protokołów.
•
uruchomienie pobierania zamrożonych stanów liczników za pomocą
wymaganego protokołu. Zrealizowany mechanizm będzie posiadać funkcje
automatycznego uzupełnienia brakujących stanów liczników co najmniej 62 dni
wstecz.
•
uruchomienie pobierania danych bieżących i archiwalnych za pomocą
protokołu Gazmodem- 2. Protokół ten będzie pracować w oparciu o łącze
Ethernet/TCP/lP.
MIKRONIKA opracuje i zrealizuje interfejs do systemu diagnostyki turbokompresorów
CCC. Realizacja będzie między innymi obejmować następujące zagadnienia:
•
Uruchomienie
udostępniania
danych
dla
systemów
diagnostyki
turbokompresorów w tłoczniach Kondratki i Włocławek. Udostępniane dane
pobierane będą ze sterowników SCS i UCS tłoczni.
•
Do momentu odbioru technicznego interfejsu dane pobierane będą ze starego
systemu SCADA. Przełączenie na udostępnianie z nowozainstalowanego systemu
SYNDIS nastąpi po odbiorze technicznym interfejsu.
•
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
wewnętrznego.
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer zapasowy
będzie wykonywane ręcznie.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.

Dodatkowe informacje podano w na rysunkach i w opisie architektury systemu w
rozdziale
1.13 Organizacja zbierania i wystawiania danych.
Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego w wskazanym Załączniku.
Informacja te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda
kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja
mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
45.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.6:
11.1.6.
Interfejs do Systemu Ochrony Środowiska.
Uruchomić pobieranie danych bieżących za pomocą protokołu opisanego w za-
łączniku nr 5.. Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA zaprojektuje, zrealizuje i uruchomi Interfejs do Systemu Ochrony
Środowiska za pomocą wymaganego protokołu.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.

Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.
Odwołujący opisał w ofercie, że zaprojektuje, zrealizuje i uruchomi interfejs do
obiektu zgodnie z protokołem opisanym przez Zamawiającego we wskazanym
Załączniku.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda
kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja
mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
46.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.7:
11.1.7.
Interfejs do Pomiarowni Potrzeb Własnych (PPW).
11.1.7.1.
Uruchomić wymianę danych bieżących za pomocą protokołów
opisanych w załączniku nr 6.
11.1.7.2.
Uruchomić pobieranie zamrożonych stanów liczników za pomocą
protokołu opisanego w załączniku nr 6. Zrealizowany mechanizm ma posiadać

funkcje automatycznego uzupełnienia brakujących stanów liczników co najmniej 62
dni wstecz.
11.1.7.3.
Uruchomienie pobierania danych bieżących i archiwalnych za pomocą
protokołu Gazmodem-2. Protokół ten będzie pracować w oparciu o łącze Ether-
net/TCP/IP.
11.1.7.4.
Interfejs
GazModem-2
ma
być
wyposażony
w
mechanizm
automatycznego uzupełniania brakujących danych minimum 62 dni wstecz.
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA opracuje i zrealizuje Interfejs do Pomiarowni Potrzeb Własnych (PPW).
Realizacja będzie między innymi obejmować:
•
Uruchomienie wymiany danych bieżących za pomocą wymaganych
protokołów.
•
Uruchomienie pobierania zamrożonych stanów liczników za pomocą
wymaganego protokołu. Zrealizowany mechanizm będzie posiadać funkcje
automatycznego uzupełnienia brakujących stanów liczników co najmniej 62 dni
wstecz.
•
Uruchomienie pobierania danych bieżących i archiwalnych za pomocą
protokołu Gazmodem-2. Protokół ten będzie pracować w oparciu o łącze
Ethernet/TCP/lP.
Wyposażenie Interfejsu GazModem-2 w mechanizm automatycznego uzupełniania
brakujących danych minimum 62 dni wstecz.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.

Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda
kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja
mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu
stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a
brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
47.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.8:
11.1.8.
Interfejs do obiektów liniowych typu ZZU, OZZU, ZPT, ZP.
Uruchomić pobieranie danych bieżących za pomocą protokołu opisanego w za-
łączniku nr 7. Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA opracuje i zrealizuje Interfejs do obiektów liniowych typu ZZU, OZZU,
ZPT, ZP. Pobieranie danych bieżących będzie uruchomione za pomocą
wymaganego protokołu.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.

Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.
Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa,
że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda kompletnej,
precyzyjnej informacji, której z istoty nie posiada krótka informacja mająca mieć
postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
48.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.9:
11.1.9.
Interfejs do WRG Gustorzyn.
11.1.9.1.
Uruchomić pobieranie danych bieżących za pomocą protokołów
opisanych w załączniku nr 8.
11.1.9.2.
Uruchomić udostępnianie danych dla WRG Gustorzyn zgodnie z
opisem zawartym w załączniku nr 8.

11.1.9.3.
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
zewnętrznego.
11.1.9.4.
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy ma być wykonywane ręcznie.
11.1.9.5.
Do momentu odbioru technicznego interfejsu dane udostępniane będą
ze starego systemu SCADA. Przełączenie na udostępnianie z nowego systemu
SCADA nastąpi po odbiorze technicznym interfejsu.
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA zaprojektuje i uruchomi Interfejs do WRG Gustorzyn. Realizacja będzie
między innymi obejmować:
•
Uruchomienie pobierania danych bieżących za pomocą wymaganych
protokołów.
•
Uruchomienie udostępniania danych dla WRG Gustorzyn zgodnie z
wymaganiami.
•
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
zewnętrznego.
•
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy będzie wykonywane ręcznie.
Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego
systemu SCADA. Przełączenie na udostępnianie z nowozainstalowanego systemu
SYNDIS nastąpi po odbiorze technicznym interfejsu.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano na rysunkach iw opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.

Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda
kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja
mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
49.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji

w przyszłości wymaganej funkcjonalności przez Oferenta nie jest poparta opisem
sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.10:
11.1.10.
Interfejs do Mallnow.
11.1.10.1.
Uruchomić pobieranie danych bieżących za pomocą protokołów
opisanych w załączniku nr 9.
11.1.10.2.
Uruchomić udostępnianie danych dla Mallnow zgodnie z opisem
zawartym w załączniku nr 9.
11.1.10.3.
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
zewnętrznego.
11.1.10.4.
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy ma być wykonywane ręcznie.

11.1.10.5.
Do momentu odbioru technicznego interfejsu dane udostępniane będą
ze starego systemu SCADA. Przełączenie na udostępnianie z nowego systemu
SCADA nastąpi po odbiorze technicznym interfejsu.
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA zaprojektuje i uruchomi Interfejs do Mallnow. Realizacja będzie między
innymi obejmować:
•
Uruchomienie pobierania danych bieżących za pomocą wymaganych
protokołów.
•
Uruchomienie udostępniania danych dla Mallnow zgodnie z wymaganiami.
•
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
zewnętrznego.
•
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy będzie wykonywane ręcznie.
Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego
systemu SCADA. Przełączenie na udostępnianie z nowozainstalowanego systemu
SYNDIS nastąpi po odbiorze technicznym interfejsu.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.

Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.
Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku.

Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda
kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja
mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
50.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.11:
11.1.11.
Interfejs do GazExport Berlin
11.1.11.1.
Uruchomić udostępnianie danych dla GazExport zgodnie z opisem
zawartym w załączniku nr 10.
11.1.11.2.
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
zewnętrznego.
11.1.11.3.
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy ma być wykonywane ręcznie.
11.1.11.4.
Do momentu odbioru technicznego interfejsu dane udostępniane będą
ze starego systemu SCADA. Przełączenie na udostępnianie z nowego systemu
SCADA nastąpi po odbiorze technicznym interfejsu.
Opis zawarty w tabeli w ofercie Odwołującego:
M4KRQ<M<I<KA GszlEięKKt Re-s&sacj-a {jędzae <^<-ę<dz.y
innymi obejmować:
•
Uruchomienie udostępniania danych dla GazExport zgodnie z wymaganiami.

•
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
zewnętrznego.
•
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy będzie wykonywane ręcznie.
Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego
systemu SCADA. Przełączenie na udostępnianie z nowozainstalowanego systemu
SYNDIS nastąpi po odbiorze technicznym interfejsu.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano na rysunkach iw opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.
Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda
kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja
mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu
stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka informacja, a
brakuje informacji precyzyjnej.

Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
51.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.12:
11.1.12.
Interfejs do Biełtransgaz.
11.1.12.1.
Uruchomić pobieranie danych bieżących za pomocą protokołów
opisanych w załączniku nr 11.
11.1.12.2.
Uruchomić udostępnianie danych dla Biełtransgaz zgodnie z opisem
zawartym w załączniku nr 11.
11.1.12.3.
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
zewnętrznego.
11.1.12.4.
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy ma być wykonywane ręcznie.
11.1.12.5.
Do momentu odbioru technicznego interfejsu dane udostępniane będą
ze starego systemu SCADA. Przełączenie na udostępnianie z nowego systemu
SCADA nastąpi po odbiorze technicznym interfejsu.
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA opracuje i zrealizuje Interfejs do Biełtransgaz. Realizacja będzie między
innymi obejmować:
•
Uruchomienie pobierania danych bieżących za pomocą wymaganych
protokołów.
•
Uruchomienie udostępniania danych dla Biełtransgaz zgodnie z wymaganiami.
•
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
zewnętrznego.
•
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy będzie wykonywane ręcznie.
Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego
systemu SCADA. Przełączenie na udostępnianie z nowozainstalowanego systemu
SYNDIS nastąpi po odbiorze technicznym interfejsu.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:

W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano na rysunkach i w opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.
Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda
kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja
mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
52.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.13:
11.1.13.
Interfejs do WRP Lwówek.

11.1.13.1.
Uruchomić wymianę danych bieżących za pomocą protokołów
opisanych w załączniku nr 12.
11.1.13.2.
Uruchomić pobieranie zamrożonych stanów liczników za pomocą
protokołu opisanego w załączniku nr 12. Zrealizowany mechanizm ma posiadać
funkcje automatycznego uzupełnienia brakujących stanów liczników co najmniej 62
dni wstecz.
11.1.13.3.
Uruchomienie pobierania danych bieżących i archiwalnych za pomocą
protokołu Gazmodem-2. Protokół ten będzie pracować w oparciu o łącze
Ethernet/TCP/lP.
11.1.13.4.
Interfejs
GazModem-2
ma
być
wyposażony
w
mechanizm
automatycznego uzupełniania brakujących danych minimum 62 dni wstecz
Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA opracuje i zrealizuje Interfejs do WRP Lwówek. Realizacja będzie
między innymi obejmować:
•
Uruchomienie wymiany danych bieżących za pomocą wymaganych
protokołów.
•
Uruchomienie pobierania zamrożonych stanów liczników za pomocą
wymaganego protokołu. Zrealizowany mechanizm będzie posiadać funkcje
automatycznego uzupełnienia brakujących stanów liczników co najmniej 62 dni
wstecz.
•
Uruchomienie pobierania danych bieżących i archiwalnych za pomocą
protokołu Gazmodem-2. Protokół ten będzie pracować w oparciu o łącze
Ethernet/TCP/lP.
Wyposażenie Interfejsu GazModem-2 w mechanizm automatycznego uzupełniania
brakujących danych minimum 62 dni wstecz.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.

Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano w na rysunkach i w opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.
Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego opisu sposobu
realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych Zamawiający w
sytuacji, gdy uważa, że informacje nie znajdują się w tabeli, rozszerza żądanie i żąda
kompletnej, precyzyjnej informacji, której z istoty nie posiada krótka informacja
mająca mieć postać wiersza w tabeli, której żądanie wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może
stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
53.
Zastrzeżenie:
Oferent nie opisał w tabeli sposobu realizacji wymagania, natomiast dokumentacja
systemu nie zawiera opisu funkcjonalności umożliwiającej realizację wymagania.
Zapowiedź realizacji w przyszłości wymaganej funkcjonalności przez Oferenta nie
jest poparta opisem sposobu realizacji ani studium wykonalności.
Wymaganie 11.1.14:
11.1.14.
Interfejs do KDG Gaz-System
11.1.14.1.
Uruchomić udostępnianie danych dla KDG zgodnie z opisem zawartym
w za-łączniku nr 13.
11.1.14.2.
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
wewnętrznego.
11.1.14.3.
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy ma być wykonywane ręcznie.
11.1.14.4.
Do momentu odbioru technicznego interfejsu dane udostępniane będą
ze starego systemu SCADA. Przełączenie na udostępnianie z nowego systemu
SCADA nastąpi po odbiorze technicznym interfejsu.

Opis zawarty w tabeli w ofercie Odwołującego:
MIKRONIKA zaprojektuje i uruchomi Interfejs do KDG Gaz-System. Realizacja
będzie między innymi obejmować:
•
Uruchomienie udostępnianie danych dla KDG zgodnie z wymaganiami.
•
Udostępnianie danych odbywać się będzie z serwera komunikacyjnego
wewnętrznego.
•
W przypadku awarii serwera komunikacyjnego, przełączenie na serwer
zapasowy będzie wykonywane ręcznie.
Do momentu odbioru technicznego interfejsu dane udostępniane będą ze starego
systemu SCADA. Przełączenie na udostępnianie z nowozainstalowanego systemu
SYNDIS nastąpi po odbiorze technicznym interfejsu.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika, składającą się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty.
Odwołujący poinformował także, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
Poinformował również, że wymagana funkcjonalność zostanie zrealizowana jako
wydzielona aplikacja.
Wskazał także, że producentem wydzielonej aplikacji będzie MIKRONIKA.
Dodatkowe informacje podano na rysunkach iw opisie architektury systemu w
rozdziale 1.13 Organizacja zbierania i wystawiania danych.
Odwołujący opisał w ofercie, że opracuje i zrealizuje interfejs do obiektu zgodnie z
protokołem opisanym przez Zamawiającego we wskazanym Załączniku.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności. Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego
opisu sposobu realizacji podanej funkcjonalności. Z przyczyn sobie tylko znanych
Zamawiający w sytuacji, gdy uważa, że informacje nie znajdują się w tabeli,
rozszerza żądanie i żąda kompletnej, precyzyjnej informacji, której z istoty nie
posiada krótka informacja mająca mieć postać wiersza w tabeli, której żądanie
wyraził w SIWZ.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności i nie może

stawiać zarzutu stanowiącego podstawę odrzucenia oferty, jeśli istnieje taka krótka
informacja, a brakuje informacji precyzyjnej.
Brak studium wykonalności również nie może być brany pod uwagę, ponieważ takie
studium nie było wymagane.
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.
Wymaganie 11.3.1:
Numer gniazda TCP, a także adres interfejsu IP na którym będą nasłuchiwane
połączenia maja być określane przez administratora.
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 punkcie nadrzędnym 11.3 Odwołujący określił, że realizacja strumieni TCP/IP
będzie realizowana poprzez dostarczony system SYNDIS.
Zamawiający określa w tym punkcie jedną z prac, jaką będzie wykonywał
Administrator systemu, polegającą na wytypowaniu gniazda TCP i adresu IP dla
danego interfejsu, na co Odwołujący odpowiedział „TAK” i określił, że będzie to

realizowane w systemie SYNDIS. W przedstawionej dokumentacji - Skryptach
Administratora opisano realizację standardowej obsługi takiej funkcjonalności.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
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.
Wymaganie 11.3.2:
Należy zapewnić możliwość nasłuchiwania na wielu portach jednocześnie. W
połączeniach TCP ma być przesyłany czas GMT/UTC, a znaki specjalne maja być
kodowane ciągami UTF-8.
Opis zawarty w tabeli w ofercie Odwołującego:
Będzie istniała możliwość nasłuchiwania na wielu portach jednocześnie. W
połączeniach TCP będzie przesyłany czas GMT/UTC, a znaki specjalne będą
kodowane ciągami UTF-8.
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 punkcie nadrzędnym 11.3 Odwołujący określił, że realizacja strumieni TCP/IP
będzie realizowana poprzez dostarczony system SYNDIS. Wskazał także, że
realizacja tej określonej funkcjonalności w połączeniu TCP będzie wykonana poprzez
przesyłanie czasu GMT/UTC, a znaki specjalne będą kodowane ciągami UTF-8.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
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.
Wymaganie 11.3.3:
Dane bieżące
Udostępnia strumień w formacie CSV. W kolejnych kolumnach mają być zawarte:
identyfikator pomiaru, wartość pomiaru, status pomiaru, stempel czasu, opis,
jednostka miary.
Dla wielostanów, zamiast jednostki miary ma być przesyłany opis bieżącego stanu w
formacie „numer_stanu=nazwa_stanu”.
Lista pomiarów do wysyłania ma być przechowywana w pliku CSV, którego nazwa
ma zawierać adres IP korespondenta. Połączenia z adresów IP dla których
odpowiedni plik nie został utworzony przez administratora, mają być odrzucane. Z
pliku tego serwer ma odczytywać: identyfikator pomiaru, opis oraz jednostkę miary.
W pierwszej fazie po nawiązaniu połączenia, serwer ma wysłać wartości wszystkich
pomiarów. W drugiej fazie ma oczekiwać na zmianę wysłanych wartości i wysyłać je
bezzwłocznie. W drugiej fazie kolumny opisu i jednostki miary mają być pomijane.
Tym samym połączeniem powinny być przyjmowane wartości bieżące z innych
systemów. Należy zapewnić możliwość dodania prefiksu oraz sufiksu do odbieranych
identyfikatorów pomiarów, zależnego od adresu IP korespondenta. Po zamknięciu
połączenia w systemowym rejestrze zdarzeń ma zostać zapisany: adres TCP/IP
korespondenta oraz przyczyna zakończenia połączenia, wartości odebrane tym po-
łączeniem mają uzyskać status błędu pozyskania.
Serwer musi mieć możliwość inicjowania połączenia do wybranych adresów IP, z
automatycznym odnawianiem zerwanych połączeń.
Wykonawca dostarczy program do wyświetlania danych odbieranych wyżej opisanym
strumieniem TCP.
Opis zawarty w tabeli w ofercie Odwołującego:

Dla danych bieżących MIKRONIKA zapewni udostępnienie strumienia danych w
formacie CSV. W kolejnych kolumnach będą zawarte: identyfikator pomiaru, wartość
pomiaru, status pomiaru, stempel czasu, opis, jednostka miary.
Dla wielostanów, zamiast jednostki miary będzie przesyłany opis bieżącego stanu w
formacie „numer_stanu=nazwa_stanu”.
Lista pomiarów do wysyłania będzie przechowywana w pliku CSV, którego nazwa
będzie zawierać adres IP korespondenta. Połączenia z adresów IP, dla których
odpowiedni plik nie został utworzony przez administratora, będą odrzucane. Z pliku
tego serwer będzie odczytywać: identyfikator pomiaru, opis oraz jednostkę miary.
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 punkcie nadrzędnym 11.3 Odwołujący określił, że realizacja strumieni TCP/IP
będzie realizowana poprzez dostarczony system SYNDIS. W opisie ofertowym
dokładnie opisał także sposób realizacji funkcjonalności, odpowiadający dokładnie
wymaganiom Zamawiającego.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności. Przy opisie realizacji interfejsów komunikacji, gdzie w wymaganiach
opisano
szczegółowo
konstrukcję
interfejsu,
nie
może
być
mowy
o

odstępstwach w sposobie realizacji, gdyż skutkowałoby to brakiem możliwości
wymiany danych pomiędzy urządzeniami/systemami.
57 Zastrzeżenie:
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.
Wymaganie 11.3.4:
Dane archiwalne
Odbierany strumień CSV zawierać będzie tylko jeden wiersz. W pierwszej kolumnie
będzie identyfikator. Serwer ma sprawdzić, czy żądany identyfikator znajduje się w
pliku opisanym
w rozdziale 11.3.3 wyżej. Pozostałe kolumny mają zostać zignorowane, a odebranie
następnego wiersza ma zerwać połączenie.
Odsyłany strumień CSV ma zawierać kolumny: stempel czasu, wartość, status.
Dane mają być wysyłane od wartości ostatnio zmierzonej do wartości najdawniejszej.
Po wysłaniu wszystkich danych połączenie ma zostać zamknięte. Odbiorca nie
potrzebujący wszystkich danych, będzie zrywał połączenie.
Jeżeli przesyłane wartości są wartościami średnimi, to stempel czasu ma wskazywać
koniec okresu, z którego obliczono średnią. To samo odnosi się do stempla czas dla
wartości przyrostu.
Po zamknięciu połączenia w systemowym rejestrze zdarzeń ma zostać zapisany:
adres TCP/IP korespondenta, identyfikator pomiaru, ostatni stempel czasu oraz
przyczynę zakończenia połączenia.
Wykonawca dostarczy program do wyświetlania lub zapisywania danych odbieranych
wyżej opisanym strumieniem TCP.
Opis zawarty w tabeli w ofercie Odwołującego:
Dla danych archiwalnych odbierany strumień CSV zawierać będzie tylko jeden
wiersz. W pierwszej kolumnie będzie identyfikator. Serwer będzie sprawdzał, czy
żądany identyfikator znajduje się w pliku opisanym w pkt. 11.3.3. Pozostałe kolumny
zostaną zignorowane, a odebranie następnego wiersza spowoduje zerwanie
połączenia.
Odsyłany strumień CSV będzie zawierać kolumny: stempel czasu, wartość, status.

Dane będą wysyłane od wartości ostatnio zmierzonej do wartości najdawniejszej. Po
wysłaniu wszystkich danych połączenie zostanie zamknięte. Odbiorca nie
potrzebujący wszystkich danych będzie zrywał połączenie.
Jeżeli przesyłane wartości są wartościami średnimi, to stempel czasu będzie
wskazywać koniec okresu, z którego obliczono średnią. To samo odnosi się do
stempla czasu dla wartości przyrostu.
Po zamknięciu połączenia w systemowym rejestrze zdarzeń zostanie zapisany:
adres TCP/IP korespondenta, identyfikator pomiaru, ostatni stempel czasu oraz
przyczyna zakończenia połączenia.
Wykonawca dostarczy program do wyświetlania lub zapisywania danych odbieranych
wyżej opisanym strumieniem TCP.
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 zostanie dostarczone oprogramowanie
dodatkowe. Poinformował również, że wymaganie zostanie zrealizowane w zakresie
takim, jak postawiono.
W punkcie nadrzędnym 11.3 Odwołujący określił, że realizacja strumieni TCP/IP
będzie realizowana poprzez dostarczony system SYNDIS. W opisie ofertowym

dokładnie opisał także sposób realizacji funkcjonalności, odpowiadający dokładnie
wymaganiom Zamawiającego.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
Należy przy tym zaznaczyć, że przy opisie realizacji interfejsów komunikacji, gdzie w
wymaganiach opisano szczegółowo konstrukcję interfejsu, nie może być mowy
o
odstępstwach w sposobie realizacji, gdyż skutkowałoby to brakiem możliwości
wymiany danych pomiędzy urządzeniami/systemami.
58.
Zastrzeżenie:
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.
Wymaganie 11.3.5:
Dane chwilowe
Odbierany strumień CSV zawierać będzie tylko jeden wiersz. W pierwszej kolumnie
będzie wskazany czas danych. Pozostałe kolumny należy zignorować, a odebranie
następnego wiersza ma zerwać połączenie.
Odsyłany strumień CSV ma zawierać kolumny: identyfikator pomiaru, wartość,
status, stempel czasu, następny stempel czasu.
Stempel czasu wskazuje od kiedy jest wskazana wartość, a następny stempel czasu
wskazuje do kiedy ta wartość nie uległa zmianie.
Lista identyfikatorów pomiarów ma zostać pobrana z pliku opisanego w rozdziale
11.3.3 wyżej.
Po zamknięci połączenia w systemowym rejestrze zdarzeń ma zostać zapisany:
adres TCP/IP korespondenta, żądany czas danych oraz przyczynę zakończenia
połączenia.
Opis zawarty w tabeli w ofercie Odwołującego:
Dla danych chwilowych odbierany strumień CSV zawierać będzie tylko jeden wiersz.
W pierwszej kolumnie będzie wskazany czas danych. Pozostałe kolumny zostaną
zignorowane, a odebranie następnego wiersza będzie skutkować zerwaniem
połączenia.
Odsyłany strumień CSV będzie zawierać kolumny: identyfikator pomiaru, wartość,
status, stempel czasu, następny stempel czasu.

Stempel czasu wskazuje od kiedy jest wskazana wartość, a następny stempel czasu
wskazuje do kiedy ta wartość nie uległa zmianie.
Lista identyfikatorów pomiarów będzie pobierana z pliku opisanego w punkcie 11.3.3.
Po zamknięciu połączenia w systemowym rejestrze zdarzeń zostanie zapisany:
adres TCP/IP korespondenta, żądany czas danych oraz przyczyna zakończenia
połączenia.
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 punkcie nadrzędnym 11.3 Odwołujący określił, że realizacja strumieni TCP/IP
będzie realizowana poprzez dostarczony system SYNDIS. W opisie ofertowym
dokładnie opisał także sposób realizacji funkcjonalności, odpowiadający dokładnie
wymaganiom Zamawiającego.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności.
Przy opisie realizacji interfejsów komunikacji, gdzie w wymaganiach opisano
szczegółowo konstrukcję interfejsu, nie może być mowy o odstępstwach
w
sposobie realizacji, gdyż skutkowałoby to brakiem możliwości wymiany danych
pomiędzy urządzeniami/systemami.

59.
Zastrzeżenie:
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.
Wymaganie 11.3.6:
11.3.6.
Binarnie dane bieżące
Udostępnia strumień opisany w rozdziale 11.3.3 Dane bieżące, lecz w formacie
binarnym (a nie CSV).
Przed wysłaniem wartości ma być przesłany rekord opisu pomiaru: numer pomiaru
(WORD 16 bitów), identyfikator pomiaru (char[]), opis pomiaru (charQ), jednostkę
miary (charQ). Pola char[] maja być zakończone znakiem NULL.
Każdy rekord danych ma mieć stały rozmiar: numer pomiaru (WORD 16 bitów),
wartość pomiaru (double 8 bajtów), stempel czasu (SYSTEMTIME), status pomiaru
(BYTE 8 bitów).
Opis zawarty w tabeli w ofercie Odwołującego:
Dla danych bieżących, oprócz strumienia danych w formacie CSV, dla danych
bieżących MIKRONIKA zapewni udostępnienie strumienia danych w formacie
binarnym, zgodnie z załączonym w SIWZ opisem.
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
1
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 punkcie nadrzędnym 11.3 Odwołujący określił, że realizacja strumieni TCP/IP
będzie realizowana poprzez dostarczony system SYNDIS. W opisie ofertowym
dokładnie opisał także sposób realizacji funkcjonalności, odpowiadający dokładnie
wymaganiom Zamawiającego.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności. 60. Zastrzeżenie:
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.
Wymaganie 11.3.7:
Binarnie wszystkie dane bieżące
Udostępnia strumień opisany w rozdziale 11.3.6, lecz udostępniający wszystkie
pomiary istniejące w systemie (bez sprawdzania zawartości pliku opisanego w
rozdziale 11.3.3).
Opis zawarty w tabeli w ofercie Odwołującego:
Dla danych bieżących wszystkich pomiarów istniejących w systemie MIKRONIKA
zapewni udostępnienie strumienia danych w formacie binarnym (bez sprawdzania
zawartości pliku opisanego w punkcie 11.3.6).
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 punkcie nadrzędnym 11.3 Odwołujący określił, że realizacja strumieni TCP/IP
będzie realizowana poprzez dostarczony system SYNDIS. W opisie ofertowym
dokładnie opisał także sposób realizacji funkcjonalności, odpowiadający dokładnie
wymaganiom Zamawiającego.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności, wobec czego postawiony wymóg należy uznać za spełniony.
61
Zastrzeżenie:
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.
Wymaganie 11.3.8:
Binarnie dane archiwalne.
Udostępnia strumień opisany w rozdziale 11.3.4 Dane archiwalne, lecz w formacie
binarnym (a nie CSV).
Opis zawarty w tabeli w ofercie Odwołującego:
Dla danych archiwalnych, oprócz strumienia danych w formacie CSV, MIKRONIKA
zapewni udostępnienie strumienia danych w formacie binarnym.
Ustosunkowanie się Odwołującego do zastrzeżenia Zamawiającego:
W zakresie opisu sposobu realizacji wymagania Odwołujący w ofercie wstępnej
poinformował, że jego realizacja będzie wykonana w oparciu o rodzinę produktów
SO-5 produkcji Mikronika składającej się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty. System SYNDIS 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 punkcie 11.3.4 został określony format danych archiwalnych, których interfejs
binarny, zgodnie z opisem sposobu realizacji z punktu 11.4, będzie zrealizowany
poprzez serwer komunikacyjny systemu SYNDIS, tak jak to określono w opisie
architektury systemu.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności. Zaznaczenia przy tym wymaga, że Zamawiający wymagał krótkiego
opisu sposobu realizacji podanej funkcjonalności.
Zamawiający w każdej sytuacji, niezależnie od umieszczenia informacji, miał prawo
żądać jedynie krótkiej informacji w zakresie określonej funkcjonalności.
62
Zastrzeżenie:
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.
Wymaganie 11.4:
Strumienie nazwane dla użytkowników biurowych
Zadaniem
serwera
będzie
udostępnianie
danych
przyszłym
aplikacjom
uruchamianym Przez użytkowników biurowych. Autoryzacja użytkowników ma
następować na serwerze. Nadawanie uprawnień do dostępu ma być możliwe
użytkownikom i grupom użytkowników active directory. Uprawnienia mają być
sprawdzane również na poziomie dostępu do poszczególnych sygnałów pomiarów,
archiwów.
Serwer ma zapewnić strumienie opisane w rozdziałach od 11.3.3do 11.3.8, lecz w
którym identyfikacja następuje na poziomie systemu operacyjnego Windows (na
podstawie SID, loginu, a nie adresu IP).

Ponadto ma zostać udostępniony strumień do odczytu danych bieżących, w którym
aplikacje klienckie będą mogły przesłać listę identyfikatorów, a w odpowiedzi serwer
wyśle ich aktualne wartości (wraz ze stemplem czasowym) oraz będzie
automatycznie przesyłał nowe wartości (podobnie jak na stronie 82).
Opis zawarty w tabeli w ofercie Odwołującego:
Serwer komunikacyjny będzie udostępniał dane przyszłym aplikacjom uruchamianym
przez użytkowników biurowych. Autoryzacja użytkowników będzie następować na
serwerze. Uprawnienia do dostępu będzie można nadać użytkownikom i grupom
użytkowników active directory. Uprawnienia będą sprawdzane również na poziomie
dostępu do poszczególnych sygnałów, pomiarów, archiwów.
Oferowany serwer komunikacyjny będzie zapewniał strumienie opisane w punktach
od 11.3.3 do 11.3.8 powyżej, w którym identyfikacja następuje na poziomie systemu
operacyjnego Windows (na podstawie SID, loginu, a nie adresu IP).
Zostanie również udostępniony strumień do odczytu danych bieżących, w którym
aplikacje klienckie będą mogły przesłać listę identyfikatorów, a w odpowiedzi serwer
wyśle ich aktualne wartości (wraz ze stemplem czasowym) oraz będzie
automatycznie przesyłał nowe wartoś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 w oparciu o rodzinę produktów
SO-5 produkcji Mikronika składającej się z oprogramowania SCADA SYNDIS oraz
sterowników/koncentratorów serii SO- 55 - strona 5 oferty. System SYNDIS 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 opisie architektury systemu Odwołujący wskazał sprzęt, na
jakim zostaną zbudowane serwery komunikacyjne oraz określił funkcjonalność
serwerów komunikacyjnych - zarówno wewnętrznych, jak i zewnętrznych. Realizacja
mechanizmów wymiany danych została przez Odwołującego opisana w punktach
11.3.3 - 11.3.8.
Informacje te łącznie stanowią co najmniej krótki opis realizacji wymaganej
funkcjonalności.
W podsumowaniu odwołujący stwierdził, że jego oferta wstępna jest w pełni zgodna
z SIWZ, a dokonując odrzucenia tejże oferty Zamawiający rażąco naruszył art. 89
ust. 1 pkt 2 PZP w zw. z art. 57 ust. 2 PZP, jak również art. 87 ust. 1 PZP oraz art. 7
ust. 1 PZP.

Zamawiający wniósł o oddalenie odwołania. Podtrzymał stanowisko co do
niezgodności treści oferty wstępnej z treścią siwz w pozycjach wskazanych w decyzji
o odrzuceniu oferty odwołującego. Stwierdził, że art. 87 ust. 1 ustawy pzp normuje
uprawnienie zamawiającego, a nie obowiązek zwracania się do wykonawcy o
złożenie wyjaśnień. Wskazał także na podgląd, iż przepis ten w postępowaniu o
udzielenie zamówienia publicznego w trybie negocjacji z głoszeniem nie ma w ogóle
zastosowania. Zamawiający stwierdził, że w siwz określił szereg wymogów w
stosunku do oferowanego przedmiotu zamówienia zobowiązujących wykonawcę do
przedstawienia oferowanych rozwiązań i opisania sposobu realizacji poszczególnych
wymagań. Stwierdził, że wielokrotne powołanie się w ofercie, że realizacja będzie
wykonana przy użyciu systemu SYNDIS ”który jest wysokiej klasy narzędziem..” nie
może być uznane za spełnienie wymogu siwz przedstawienia opisu sposobu
realizacji wymaganych funkcjonalności. Zdaniem zamawiającego opis zawarty w
ofercie wstępnej nie wyjaśnia także ani proponowanego sposobu opracowania
polityki bezpieczeństwa ani nie przedstawia sposobu spełnienia wymagań
zamawiającego w zakresie tej polityki. Na potwierdzenie swojego stanowiska
zamawiający złożył do akt sprawy opinię prywatną rzeczoznawców Polskiego
Towarzystwa Informatycznego.

Przystępujący do postępowania odwoławczego po stronie zamawiającego wniósł o
oddalenie odwołania podzielając w całości stanowisko zamawiającego.

Krajowa Izba Odwoławcza po rozpatrzeniu odwołania na rozprawie z udziałem stron i
uczestnika, uwzględniając dokumentację postępowania przedstawioną przez
zamawiającego, a w szczególności treść siwz oraz treść oferty wstępnej złożonej
przez odwołującego, zważyła, co następuje.

Zarzuty przedstawione przez odwołującego nie znajdują potwierdzenia w stanie
faktycznym sprawy i z tego powodu odwołanie zostało oddalone.

Odrzucenie oferty wstępnej złożonej przez odwołującego nastąpiło na podstawie
oceny dokonanej przez zamawiającego, że treść tej oferty nie odpowiada wymogom
określonym w 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.”
Istota sporu sprowadza się w niniejszej sprawie do pojęcia „opis sposobu realizacji
danego wymagania” ujętego w końcowej części zacytowanego postanowienia
specyfikacji.
Zdaniem odwołującego nie było możliwe odrzucenie oferty z powodu braku takich
opisów, gdyż z jednej strony opis sposobu realizacji danego wymagania będzie
przedmiotem negocjacji i znajdzie swój ostateczny wyraz w ofercie ostatecznej, z
drugiej strony zamawiający nie wskazał, w jaki sposób taki krótki opis sposobu
realizacji wymagania ma zostać sporządzony.
Analiza treści oferty wstępnej wskazuje, że istotnie w odniesieniu do wymagań
opisanych w części szczegółowej stanu faktycznego odwołujący w rubryce
„Spełnienie wymagania (tak/nie)” potwierdzał spełnienie wymagania wpisując słowo
„TAK”, a w kolejnej rubryce „Opis sposobu realizacji wymagania” użył wielokrotnie
sformułowania: „Zgodnie z wymaganiami Zamawiającego”. W ocenie składu

orzekającego taka informacja, jak wyżej zacytowana nie może być uznana za „krótki
opis sposobu realizacji wymagania”. W rzeczywistości opisu takiego brak, a zamiast
niego wykonawca zadeklarował jedynie zgodność proponowanych rozwiązań z
wymogami zamawiającego. Nie można się zgodzić z argumentacją odwołującego
jakoby odrzucenie oferty wstępnej nie było możliwe z uwagi na fakt, iż zamawiający
nie wskazał jednoznacznie, w jaki sposób należy sporządzić krótki opis realizacji
danego wymagania. Brak wymagań co do sposobu przedstawienia tego opisu
skutkuje tym, że dopuszczalne było sporządzenie opisu w jakiejkolwiek formie,
jednakże opis powinien był faktycznie potwierdzać sposób realizacji danego
wymagania. Uzasadnione jest założenie, że zamawiający zawierając w pkt 9.5
warunek przedstawienia krótkiego opisu realizacji danego wymagania zmierzał
właśnie do tego, czy produkt oferowany przez danego wykonawcę będzie spełniał
jego wymagania, a umieszczenie w ofercie krótkiego opisu miało wskazywać, czy
wykonawcy są w stanie wykonać przedmiot zamówienia nakreślony we wstępnej
specyfikacji istotnych warunków zamówienia. Wymagany opis służyć miał zatem
zamawiającemu do podjęcia decyzji co do dopuszczenia wykonawcy do dalszego
etapu postępowania, co przy złożoności przedmiotu zamówienia uzasadniało opisany
wymóg, jako podstawę weryfikacji produktu i zdolności wykonawcy do wykonania
ostatecznego przedmiotu zamówienia. Za oczywiście niewystarczające Izba uznaje
samo zadeklarowanie przez wykonawcę, że zaoferuje przedmiot zamówienia
zgodnie z oczekiwaniami zamawiającego. Tym bardziej taka deklaracja nie jest
opisem, nawet „krótkim”. W takim stanie rzeczy skład orzekający uznaje, że
zamawiający odrzucając ofertę wstępną złożoną przez odwołującego nie naruszył
art. 89 ust. 1 pkt 2 w związku z art. 57 ust. 2 ustawy pzp i zasadnie stwierdził, że
oferta wstępna w swej treści jest niezgodna z postanowieniami pkt 9.5 specyfikacji
istotnych warunków zamówienia.
Odnośnie zarzutu naruszenia art. 87 ust. 1 ustawy należy zauważyć, że rzeczywiście
w art. 57 ust. 2 ustawy pzp nie wymieniono przepisu art. 87 ust. 1. Natomiast nie
wyklucza to możliwości żądania przez zamawiającego od wykonawców także w
postępowaniu w trybie negocjacji, złożenia wyjaśnień. Warto zauważyć, że takie
postępowanie zasadza się właśnie na wzajemnym wyjaśnianiu.
W świetle powyższych ustaleń, orzeczono jak w sentencji.




O kosztach postępowania orzeczono na podstawie art. 192 ust. 9 i 10 ustawy Pzp oraz
§ 5 ust. 4 rozporządzenia Prezesa Rady Ministrów z dnia 15 marca 2010 r. w sprawie
wysokości wpisu od odwołania oraz rodzajów kosztów w postępowaniu odwoławczym i
sposobu ich rozliczania (tj.: Dz. U. z 2010 r., Nr 113, poz. 759 z późn. zm.), tj. stosownie do
wyniku postępowania, uwzględniając koszty wynagrodzenia pełnomocnika zamawiającego w
wysokości 3 600,00 zł na podstawie faktury złożonej do akt sprawy.

Przewodniczący: …………………………

…………………………

…………………………

Wcześniejsze orzeczenia:

• Sygn. akt KIO 263/15 z dnia 2015-12-23
• Sygn. akt KIO 245/15, KIO 305/15 z dnia 2015-03-04
• Sygn. akt KIO 270/15 z dnia 2015-03-03
• Sygn. akt KIO 273/15 z dnia 2015-02-27
• Sygn. akt KIO 267/15 z dnia 2015-02-27