ZZP ZAŁĄCZNIK nr 11

Transkrypt

1 ZAŁĄCZNIK nr 11 SZCZEGÓŁOWY OPIS WYMAGAŃ DOTYCZĄCYCH WYPOSAŻENIA POJAZDÓW, POJEMNIKÓW, WORKÓW ORAZ REJESTRACJI ZDARZEŃ I WYMIANY INFORMACJI I. DEFINICJE: Moduł Kontrolujący Systemu Identyfikacji (MKSI) oprogramowanie Zamawiającego służące do zarządzania danymi pozyskiwanymi z systemów monitoringu Wykonawcy, opartych o system nawigacji GPS, system radiowej identyfikacji pojemników i kontenerów, system ważenia i system rejestratorów kodów kreskowych (dalej jako Systemy Identyfikacji ), umieszczonych na pojazdach używanych przez Wykonawcę do realizacji przedmiotu zamówienia. System Operatora oprogramowanie Wykonawcy służące do gromadzenia i analizy danych otrzymywanych automatycznie z pojazdów Wykonawcy, takich jak położenie i stan pojazdu, z systemu RFID, z systemu wagowego, z czytników kodów kreskowych, z terminali pokładowych itp. MGO należy przez to rozumieć miejsca gromadzenia odpadów komunalnych (w tym zbieranych w sposób selektywny), w których umieszczone zostały pojemniki oraz kontenery na odpady oraz przy których pozostawiane będą odpady problemowe. Dane o MGO - należy przez to rozumieć: - adresy poszczególnych MGO, - unikalne identyfikatory klientów (właścicieli nieruchomości których pojemniki lub kontenery znajdują się w MGO)), - kody transponderów RFID zamontowanych na pojemnikach, - częstotliwości odbioru odpadów, - ilości, pojemności i przeznaczenie pojemników znajdujących się w MGO, - współrzędne geograficzne każdego zinwentaryzowanego pojemnika/kontenera. RFID system radiowej identyfikacji pojemników i kontenerów. System ten poprzez zainstalowane na nich transpondery oraz terminal/komputer pokładowy pojazdów Wykonawcy i MKSI umożliwia identyfikację nieruchomości i właściciela pojemnika i kontenera przypisanego do danej nieruchomości oraz rodzaj wytwarzanych odpadów na tej nieruchomości. System zapewnia identyfikację pojemników i kontenerów za pomocą anten RFID umieszczonych na pojazdach - każdy zainstalowany na zasypie/mechanizmie wywrotu pojemnika/kontenera jest automatycznie identyfikowany przez rejestrację identyfikatora (transpondera) zamontowanego na pojemniku/kontenerze. Transponder (chip, znacznik RFID) - elektroniczne urządzenie bezprzewodowej transmisji sygnałów, pozwalające operatorom MKSI na monitorowanie pracy Wykonawcy, śledzenie obiegu pojemników i kontenerów, oraz ich zawartości, a także ułatwiające rozliczenia za usługi Wykonawcy. Słowniki Referencyjne - uporządkowane nazewnictwo miejscowości, ulic i prefiksów w oparciu o słownik referencyjny Teryt i Geopoz-u, zdefiniowane słownictwa typów pojemników i kontenerów na odpady zmieszane i segregowane oraz częstotliwości odbiorów odpadów, a także nazewnictwa typów odpadów, które powinny być używane przez Wykonawcę w komunikowaniu się i raportowaniu do Zamawiającego. ZM GOAP

2 II. CZĘŚĆ SZCZEGÓŁOWA 1. Wyposażenie pojazdów: 1.1. System monitoringu bazujący na GPS Wykonawca wyposaży wszystkie pojazdy w elektroniczny system monitoringu bazujący na GPS rejestrujący przebieg tras punkty nie rzadziej niż co 100m i 30 sekund Dane rejestrowane przez pozostałe urządzenia wchodzące w skład Systemu Identyfikacji muszą być w pełni zintegrowane z systemem monitoringu GPS Przesył danych z urządzeń, o których mowa w pkt powyżej musi być jednoczesny z przesyłem danych z systemu monitoringu GPS. Wszystkie zarejestrowane zdarzenia (załadunek, wyładunek, identyfikacja, ważenie, rejestracja i inne) muszą być rozszerzone o dokładną datę i czas [zgodny z uniwersalnym czasem koordynowanym UTC(PL)] oraz współrzędne geograficzne zdarzeń wyznaczone na podstawie systemu GPS Czujnik załadowania/wyładowania odpadów Wykonawca wyposaży wszystkie pojazdy bezpylne w czujniki: Czujnik pozwalający określić lokalizację pojazdu podczas uruchamiania zasypu Czujnik pozwalający określić lokalizację pojazdu podczas otwierania odwłoka w czasie opróżniania śmieciarki z odpadów System identyfikacji pojemników w technologii RFID oraz system identyfikacji worków Wykonawca wyposaży wszystkie pojazdy bezpylne w system identyfikacji RFID pojemników oraz system identyfikacji worków. System musi spełniać warunki: System musi zapewniać identyfikację pojemników za pomocą anten RFID - każdy zainstalowany na zasypie/mechanizmie wywrotu pojemnik powinien być automatycznie identyfikowany przez rejestrację kodu Transpondera zamontowanego na pojemniku System radiowej identyfikacji pojemników musi pracować w oparciu o identyfikatory pracujące na częstotliwości 134,2 khz System musi umożliwiać identyfikację wszystkich pojemników, zarówno plastikowych jak i metalowych System musi umożliwiać ręczną rejestrację kodów kreskowych z załadowanych worków Wykonawca wyposaży wszystkie pojazdy bezpylne w terminale/komputery pokładowe systemu identyfikacji RFID, umożliwiające: Wybranie MGO, na którym realizowana jest usługa Przypisanie komunikatu (notatki) do konkretnego zidentyfikowanego pojemnika oraz MGO W przypadku pojazdu bezpylnego, automatyczne ostrzeganie pracowników Wykonawcy, gdy na zasypie został zainstalowany ZM GOAP

3 pojemnik, który nie powinien być opróżniany podczas danej trasówki. Ponadto system powinien sygnalizować operatorowi, czy Transponder załadowanego pojemnika został odczytany przez anteny na pojeździe Wykonawca wyposaży wszystkie pojazdy odbierające kontenery oraz pojemniki do selektywnej zbiórki w następujące urządzenia: Urządzenie umożliwiające ręczną rejestrację kodów Transponderów z pojemników i kontenerów Terminale/komputery pokładowe systemu identyfikacji RFID umożliwiające wybranie MGO, na którym realizowana jest usługa Wykonawca wyposaży wszystkie pojazdy odbierające worki w następujące urządzenia: Urządzenie umożliwiające ręczną rejestrację kodów kreskowych z worków Terminale/komputery pokładowe systemu identyfikacji RFID umożliwiające wybranie MGO, na którym realizowana jest usługa Rejestracja notatek w urządzeniach zainstalowanych w pojazdach Systemy Identyfikacji zainstalowane we wszystkich pojazdach muszą umożliwiać rejestrację notatek zdefiniowanych przez Zamawiającego oraz notatek o dowolnej treści wprowadzonych przez członka załogi pojazdu natychmiast po wystąpieniu/wykryciu danego zdarzenia. Przykładowa lista notatek: a. wszystkie pojazdy: Nazwa notatki Unikalny identyfikator Awaria pojazdu 1 Wyładunek odpadów z pojazdu 2 Pojemnik/kontener uszkodzony 3 Uniemożliwiony dojazd do MGO 4 Niewłaściwy odpad w pojemniku/kontenerze/worku kartka OSTRZEŻENIE Brak pojemnika/kontenera 6 Brak/uszkodzony Transponder 7 Niezgodny pojemnik 8 Przesyp 9 5 b. załadunki w przypadku braku rejestracji zdarzenia z czujnika załadunku m.in. załadunek odpadów wielkogabarytowych, kontenerów itp. Nazwa notatki Unikalny identyfikator ZM GOAP

4 Załadunek odpadów Każda notatka zdefiniowana przez Zamawiającego musi mieć unikalny identyfikator w postaci dodatniej liczby naturalnej z zakresu W raportach, interfejsach integracyjnych czy innych środkach udostępniania danych zarejestrowana notatka musi zawierać informację o unikalnym identyfikatorze notatki, pojemniku znajdującym się na mechanizmie załadunkowym w czasie jej wprowadzania W przypadku, gdy pojemnik nie jest zidentyfikowany przez system RFID (uszkodzony Transponder albo pojemnik lub kontener niewyposażony w Transponder) terminal/komputer pokładowy musi umożliwić ręczne wybranie MGO, do którego będzie przypisana odpowiednia notatka Zamawiający zastrzega sobie możliwość zmiany treści i liczby notatek jakie mają być rejestrowane w trakcie realizacji zamówienia. Wykonawca wprowadzi zmiany w ciągu 14 dni od otrzymania takiej informacji od Zamawiającego Notatki zostaną zdefiniowane przez Zamawiającego przed rozpoczęciem świadczenia usługi przez Wykonawcę System ważenia pojemników Wykonawca wyposaży minimum jeden pojazd (typu śmieciarka) na każdy sektor, w którym zawrze umowę, w legalizowany system wagowy, który pozwoli na wykonanie ważenia pojemników w częstotliwościach, o których mowa w pkt System wagowy instalowany na urządzeniu zasypowym pojazdu bezpylnego ma być dostosowany do pojemników o objętości od 60 litrów do 1100 litrów. Ważenie pojemnika ma odbywać się w czasie procesu opróżniania pojemnika przez zasyp. System wagowy ma niezależnie wyznaczać (mierzyć) tarę pojemników dla każdego cyklu załadunku System musi rejestrować masę ważonych odpadów dla każdego z uruchomień zasypu. Zamawiający wymaga, aby masa odpadów z każdego pojemnika rejestrowana była indywidualnie, również w przypadku jeśli na urządzeniu wrzutowym zamontowany będzie system wagowy jednocześnie ważący 2 pojemniki System wagowy musi spełniać wymogi dyrektywy 2004/22/EG z dnia w sprawie przyrządów pomiarowych, które w Polsce zostały wprowadzone Rozporządzeniem Ministra Gospodarki z dnia (Dz.U. 2007R Nr 3. Poz.27 z późn. zm. i musi być akceptowany przez Główny Urząd Miar jako prawnie zalegalizowany przyrząd pomiarowy w Polsce. Wagi powinny posiadać świadectwa wzorcowania, oznaczone symbolami akredytacji (Świadectwo Wzorcowania na zgodność z Normą PN/EN ISO/IEC 17025:2005). Terminy powtórnych wzorcowań powinny być ustalane przez samego użytkownika przyrządu pomiarowego i być zapisywane w dokumentacji Wykonawcy. Jeżeli pomiary kontrolne dokonywane innym sprawdzonym przyrządem wykazują niedopuszczalny błąd wskazań, to sprawdzenie i konserwacja powinna być dokonana natychmiast. Obowiązkiem Wykonawcy jest zapewnienie, aby dane były wiarygodne i odpowiednio zabezpieczone Dokładność pomiaru systemu wagowego nie powinna być gorsza niż: ZM GOAP

5 Przy załadunku z wykorzystaniem mechanizmu grzebieniowego zabudowy wymaga się parametrów działka legalizacyjna i odczytowa e=d 2kg (nie większa niż), zakres max 200kg (nie mniejszy niż) Przy załadunku z wykorzystaniem ramion załadunkowych zabudowy wymaga się parametrów - działka legalizacyjna i odczytowa e=d 5kg (nie większa niż), zakres max 600kg (nie mniejszy niż) Dopuszcza się przełączanie działki legalizacyjnej i zakresu max następujące w sposób automatyczny, w zależności od sposobu wykorzystywania mechanizmu załadunkowego śmieciarki Dokładność pomiaru odnosi się do wyznaczania masy netto (balastu) będącej różnicą pomiaru masy brutto oraz tary Wykonawca w Harmonogramie zaplanuje i oznaczy dni, w których nastąpi ważenie pojemników przez pojazd wyposażony w system wagowy. Ważenie pojemników winno być realizowane nie rzadziej niż 2 ważenia w ciągu 3 miesięcy (8 razy w roku) dla każdego pojemnika. Zamawiający zastrzega sobie prawo wyznaczenia - w ramach limitu ważenia - MGO i daty wykonania ważenia z jednodniowym poinformowaniem Wykonawcy. 2. Wyposażenie centrali Wykonawcy 2.1. Wyposażenie Wykonawcy w System Operatora Wykonawca zobowiązany jest do posiadania Systemu Operatora oraz wdrożenia wymiany danych pomiędzy Systemem Operatora a systemem MKSI Zamawiającego Wykonawca zobowiązany jest do wykorzystywania dwóch sposobów wymiany danych: Protokołu HTTPS w trybie on-line, Elektronicznego nośnika danych w trybie off-line (pliki zapisane na elektronicznych nośnikach danych, np. płyta CD/DVD, karta pamięci) lub z załącznikiem skutecznie dostarczony do Zamawiającego Automatyzacja wymiany danych będzie podstawowym procesem wymiany danych między Zamawiającym a Wykonawcą Nieautomatyczny proces wymiany danych (wymagający działania Wykonawcy i Zamawiającego) stosowany będzie tylko w uzasadnionych przypadkach, kiedy w wyniku problemów technicznych lub zajścia siły wyższej nie będzie możliwości zastosowania procesu automatycznej wymiany danych. 3. Wymagania dotyczące danych jakie dostarczy Wykonawca do MKSI: 3.1. Wymagania dotyczące transmisji danych: Wszelkie rejestrowane dane i informacje powinny być na bieżąco (w trybie on-line) przekazywane do MKSI, z zastrzeżeniem punktów poniżej. Transfer danych ma się odbywać za pomocą interfejsu wymiany danych opartym o usługę internetową udostępnioną przez Wykonawcę i działającym w oparciu ZM GOAP

6 o żądania HTTP. Szczegółowy opis interfejsu wymiany danych został określony w pkt. III Załącznika Wykonawca rozpocznie dostarczanie wszystkich danych, których rejestracji wymaga Zamawiający, określonych w szczególności w punkcie do MKSI Zamawiającego nie później niż 16 tygodni od daty zawarcia Umowy Wykonawca zapewni Zamawiającemu pełną informację pozwalającą na pobieranie danych przez MKSI z usługi internetowej udostępnianej Zamawiającemu przez Wykonawcę, w szczególności wszelkie parametry połączenia. O ewentualnej zmianie parametrów połączenia Wykonawca jest zobowiązany powiadomić Zamawiającego z co najmniej 14 dniowym wyprzedzeniem W przypadku danych, gromadzonych za pomocą urządzeń, o których mowa w pkt oraz Zamawiający dopuszcza sytuację, że część danych o zarejestrowanych zdarzeniach jest dostępnych z opóźnieniem do 6 godzin od momentu ich zarejestrowania. Maksymalnie 6% danych rejestrowanych przez Systemy Identyfikacji w przeciągu danego dnia może być udostępniane przez Wykonawcę z takim opóźnieniem W przypadku danych gromadzonych za pomocą urządzeń do ręcznej rejestracji kodów kreskowych oraz ręcznej rejestracji kodów Transponderów Zamawiający dopuszcza sytuacje, że dane o zarejestrowanych zdarzeniach będą dostępne z opóźnieniem do 12 godzin od momentu ich zarejestrowania Wszelkie dane muszą być dostępne do pobrania przez MKSI Zamawiającego przez co najmniej 30 dni od momentu zarejestrowania W trakcie realizacji usługi odbioru odpadów Wykonawca zobowiązany jest do rejestrowania poprzez systemy GPS/RFID/WAGOWY/KODY KRESKOWE czasu i miejsca (MGO) odbioru odpadów. Zamawiający pod pojęciem czasu i miejsca (MGO) odbioru odpadów rozumie czas GPS, który jest niezależny od czasu systemowego urządzeń identyfikacji pojemników zainstalowanych na pojeździe Wykonawca nie ponosi odpowiedzialności za brak dostępu Zamawiającego do danych GPS, który jest spowodowany przyczynami leżącymi po stronie Zamawiającego, jak np. awaria urządzeń Zamawiającego, brak dostępu serwera Zamawiającego do sieci Internet. (na żądanie zamawiającego udokumentowane przez firmę serwisującą GPS) Odpowiedzialność za wybór usługodawcy GPS oraz prawidłowe funkcjonowanie systemu GPS ponosi Wykonawca. Awaria u usługodawcy GPS będzie traktowana jako zawiniona przez Wykonawcę Zamawiający będzie uwzględniał zajście siły wyższej (np. brak zasięgu lub awaria sieci GSM) o ile zostanie o tym powiadomiony innym kanałem komunikacji bez zbędnej zwłoki. Jednostkowe, epizodyczne awarie GPS obejmujące cały system usługodawcy GPS, w tym związane z zapewnieniem łączności satelitarnej, traktowane będą jak zajście siły wyższej, o ile usługodawca GPS jest firmą o uznanej renomie Zakres rejestrowanych danych System musi rejestrować w szczególności następujące zdarzenia: ZM GOAP

7 Typ zdarzenia Rejestrowane dane* Moment rejestracji Gdy pojazd jest w Maksymalna prędkość od poprzedniego ruchu nie rzadziej niż Punkty jazdy punktu jazdy, kierunek, dystans od co 200m lub co 60 poprzedniego punktu jazdy sekund Punkty postoju Załadunek pojemnika przez pojazd bezpylny Wyładunek pojazdu bezpylnego Załadunek / wyładunek kontenera Notatka z miejsca załadunku Załadunek odpadów problemowych Wyładunek odpadów Kod RFID pojemnika, typ pojemnika, typ odpadu, kod MGO, masa odpadów **, Kod RFID kontenera, typ kontenera, typ odpadu, kod MGO lub lokalizacji Kod RFID pojemnika***, typ pojemnika ***, typ odpadu ***, kod posesji***, identyfikator notatki, Treść notatki Typ odpadu, kod MGO, identyfikator notatki, Treść notatki Typ odpadu, kod MGO, identyfikator notatki, Treść notatki Gdy pojazd stoi, nie rzadziej niż co 5 minut Natychmiast po wystąpieniu zdarzenia Natychmiast po wystąpieniu zdarzenia Natychmiast po wystąpieniu zdarzenia Natychmiast po wystąpieniu zdarzenia Natychmiast po wystąpieniu zdarzenia Natychmiast po wystąpieniu zdarzenia problemowych Załadunek worka Kod kreskowy worka, typ worka, kod MGO Natychmiast po wystąpieniu zdarzenia * Wszystkie rejestrowane zdarzenia muszą posiadać identyfikator pojazdu, datę i czas oraz współrzędne geograficzne wyznaczone na podstawie systemu GPS. ** Jeśli pojazd wyposażony w system ważący. *** Jeśli pojazd wyposażony jest w system identyfikacji pojemników 3. Aktualizacja Danych o MGO i pojemnikach Wykonawca w ciągu 14 dni od podpisania umowy otrzyma od Zamawiającego w formie elektronicznej szacunkową, wstępną inwentaryzację MGO zawierającą Dane: adres MGO, ilość i pojemność pojemników/kontenerów w MGO, częstotliwość odbioru odpadów komunalnych z MGO oraz unikalne identyfikatory właścicieli, zarządców i najemców nieruchomości w sektorze Wykonawcy którzy złożyli Zamawiającemu Deklaracje o wysokości opłaty za gospodarowanie odpadami komunalnymi - z danymi ze złożonych przez nich deklaracji w zakresie usług odbioru odpadów (typ i ilość pojemników oraz częstotliwość odbioru odpadów) Wykonawca na podstawie Danych otrzymanych od Zamawiającego oraz własnych informacji terenowych dotyczących przedmiotu zamówienia: zaktualizuje Dane o MGO przypisze unikalne numery seryjne (kody) Transponderów do MGO ZM GOAP

8 sparuje każdy zamontowany na pojemniku/kontenerze Transponder z adresem nieruchomości, której przypisane jest dane MGO (sparowanie kodu nieruchomości z numerem seryjnym Transpondera) uzupełni Dane o nieruchomościach, na których powstają odpady, a które nie zostały ujęte w Danych otrzymanych od Zamawiającego i jeżeli nieruchomości mają swoje MGO wykona pełną inwentaryzację tych MGO. przekaże Zamawiającemu dane o nieruchomościach, na których powstają odpady, a które nie zostały ujęte w Danych otrzymanych od Zamawiającego i nie posiadają MGO Wykonawca wyniki inwentaryzacji prześle Zamawiającemu nie później niż w terminie 12 tygodni od dnia podpisania umowy w formacie XLS lub w innym formacie zaakceptowanym przez Zamawiającego Zamawiający zweryfikuje wyniki inwentaryzacji przeprowadzonej przez Wykonawcę i przekaże zweryfikowane dane Wykonawcy w terminie 14 dni od dnia otrzymania wyników aktualizacji od Wykonawcy Wykonawca w ciągu 14 dni od otrzymania wyników weryfikacji, wprowadzi do systemu Wykonawcy zweryfikowane przez Zamawiającego dane: adresy poszczególnych MGO, unikalne identyfikatory klientów (właścicieli, zarządców/najemców nieruchomości), kody Transponderów zamontowanych na pojemnikach i kontenerach, częstotliwości odbioru odpadów klientów z MGO, ilości, pojemności i przeznaczenie pojemników i kontenerów znajdujących się w MGO, współrzędne geograficzne każdego zinwentaryzowanego pojemnika/kontenera. Udostępnienie danych Zamawiającemu będzie polegało na wykonaniu poniższych czynności: udostępnienie powyższych danych przez funkcje WebServices opisane w pkt III Załącznika, przesłanie do Zamawiającego w formie elektronicznej danych w formacie XLS obsługiwanym przez MS Excel Wykonawca podczas trwania umowy na bieżąco aktualizuje w systemie Dane o MGO oraz dane o pojemnikach oraz kontenerach, oraz informuje Zamawiającego o nieruchomościach, na których powstają odpady, a które nie są zidentyfikowane przez Zamawiającego, w formie raportu dobowego, który Wykonawca przekaże w wersji elektronicznej. Dobowy raport powinien zawierać następujące informacje: adres nieruchomości, adres odpowiadającemu jej MGO (jeżeli takie istnieje), oraz kody Transponderów, liczbę, pojemność i przeznaczenie pojemnika lub kontenera jeżeli Wykonawca maił możliwości wykonania inwentaryzacji Niezależnie od obowiązków, o których mowa w pkt 3.5 w przypadku zmiany Danych o MGO, zmiany liczby i pojemności pojemników lub kontenerów, powstania nowego MGO lub zmiany częstotliwości odbioru, Wykonawca zobowiązany jest wprowadzić dane do systemu Wykonawcy niezwłocznie po otrzymaniu informacji (w formie elektronicznej) ZM GOAP

9 od Zamawiającego, jednak nie później niż w dniu przypadającym na odbiór odpadów z MGO, w którym znajduje się zgłoszony pojemnik lub kontener. 4. Oznakowanie pojemników i kontenerów Transponderami Wykonawca oznaczy wszystkie pojemniki oraz kontenery Transponderami nie później niż w terminie 12 tygodni od daty podpisania Umowy W przypadku, gdy w/w terminie pojemniki i kontenery nie zostaną oznakowane przez Wykonawcę z powodu braku możliwości dostępu do pojemnika lub kontenera albo jego braku, Wykonawca prześle Zamawiającemu raport z wykazem tych pojemników i kontenerów oraz podejmie działania zmierzające do oznaczenia pojemników najpóźniej w dniu przypadającym na odbiór odpadów z danego MGO, w którym pojemnik lub kontener jest dostępny dla Wykonawcy Brak możliwości dostępu do pojemnika lub kontenera, stwierdzenie jego braku lub innych zdarzeń powinno zostać stwierdzone przez załogę obsługującą pojazd poprzez wprowadzanie odpowiedniej notatki w terminalu zainstalowanym na pojeździe i zarejestrowanie zgodnie z tabelą z punktu załącznika nr 11 do SIWZ 4.4. Wykonawca jest zobowiązany na bieżąco bez odrębnego wezwania ze strony Zamawiającego - wymieniać zniszczone Transpondery oraz wyposażać w Transpondery te pojemniki lub kontenery, które takich Transponderów nie posiadają Wykonawca wymieni zniszczony Transponder na pojemniku albo kontenerze lub oznaczy nim pojemnik lub kontener w przypadku jego braku, niezwłocznie po otrzymaniu informacji od Zamawiającego, jednak nie później niż w dniu przypadającym na odbiór odpadów z MGO, w którym znajduje się zgłoszony pojemnik lub kontener. 5. Rejestracja danych i zdarzeń przez Systemy Identyfikacji 5.1. W trakcie realizacji usługi odbioru odpadów Wykonawca zobowiązany jest do rejestrowania poprzez Systemy Identyfikacji następujących danych: czasu i miejsca (MGO) odbioru odpadów, rodzaju odbieranych odpadów, czynności rejestrowanych poprzez systemy związane z odbiorem odpadów, rzeczywistego przebiegu trasy, czasu i miejsca zakończenia usługi (przekazania odpadów) W trakcie realizowania usługi odbierania odpadów Wykonawca jest zobowiązany rejestrować wszystkie zdarzenia uniemożliwiające realizację usług poprzez wprowadzanie zdefiniowanych w formie komunikatów (notatek) do pokładowego terminala/komputera systemu RFID - lub jeśli Zamawiający wyda taką dyspozycję również owo lub poprzez udostępniony Wykonawcy system wymiany informacji, raportów oraz komunikatów - w formie dobowego/miesięcznego raportu zdarzeń, odrębnie dla każdego z obsługiwanych sektorów W przypadku, gdy pojemnik lub kontener nie zostanie zidentyfikowany przez system RFID, Wykonawca sprawdza w systemie RFID (terminalu/komputerze pokładowym) czy pojemnik lub kontener jest zarejestrowany w systemie Wykonawcy. W takim wypadku ręcznie wprowadza odpowiednią notatkę (np. uszkodzony lub brak Transpondera, załadunek pojemnika) do systemu Wykonawcy i udostępnia Zamawiającemu ZM GOAP

10 5.4. Zamawiający w każdym momencie realizacji umowy może zażądać od Wykonawcy prowadzenia dodatkowej dokumentacji fotograficznej zdarzeń podlegających rejestracji poprzez system GPS/RFID/WAGA/KODY KRESKOWE. Zdjęcia w postaci cyfrowej muszą być wykonane w taki sposób, aby nie budząc wątpliwości pozwalały na skuteczne udokumentowanie zdarzeń i przypisanie ich do właściwego MGO oraz klienta. Zamawiający może wymagać od Wykonawcy przesyłania dokumentacji fotograficznej poprzez ustalony w SIWZ system wymiany informacji, raportów i dokumentów bez zbędnej zwłoki Wykonawca zobowiązany jest najpóźniej w 6 tygodniu od podpisania umowy - udostępnić interfejs wymiany danych swojego systemu operatorskiego wymiany danych zgodny ze specyfikacją zawartą w punkcie III. Szczegółowym opisie interfejsu wymiany danych. Wszystkie związane z tym koszty ponosi Wykonawca. 6. Ujednolicone Słowniki Referencyjne 6.1. Wykonawca w komunikowaniu się i raportowaniu do Zamawiającego musi używać Słowników Referencyjnych: nazw miejscowości, ulic i prefiksów, Słownika Referencyjnego typów pojemników i kontenerów na odpady zmieszane i segregowane, Słownika Referencyjnego częstotliwości odbiorów odpadów i Słownika Referencyjnego typów odpadów którymi posługuje się Zamawiający Słownik typów odpadów i Słownik typów pojemników zamieszczone są w punkcie III. Szczegółowym opisie interfejsu wymiany danych. ZM GOAP

11 III. SZCZEGÓŁOWY OPIS INTERFEJSU WYMIANY DANYCH STRON 25 III. SZCZEGÓŁOWY OPIS INTERFEJSU WYMIANY DANYCH ZM GOAP

12 Spis treści: 1 Wstęp Metody Logowanie Klucz sesyjny Funkcja: Login() Rozpoczęcie wymiany danych... Błąd! Nie zdefiniowano zakładki. 2.2 GetVehicleList GetVehicleById GetVehicleListLastState GetVehicleEvents GetContainersList GetScheduleList GetFuncModificationStatus LocationList CustomerList Opis typów danych Słowniki Słownik typów odpadów Słownik typów pojemników Słownik Notatek Słownik typów nieruchomości WSDL Uwagi ZM GOAP

13 1 Wstęp Celem wymiany danych jest przekazanie do MKSI Zamawiającego danych przetwarzanych w Systemie Operatora. Niniejsza specyfikacja określa wymagania Zamawiającego dla zakresu danych otrzymywanych od Wykonawcy dotyczących systemu gospodarowania odpadami komunalnymi oraz sposobu ich wymiany między systemami informatycznymi Wykonawcy i Zamawiającego. Funkcje nie określone w specyfikacji zostaną uzgodnione z Wykonawcą na etapie konfiguracji połączenia między systemami. Jako elementy wiążące należy rozumieć diagramy XSD znajdujące się przy opisie każdej funkcji oraz WSDL figurujący w rozdziale 5 poniższego dokumentu. 2 Metody 2.1 Logowanie Klucz sesyjny Celem zagwarantowania bezpieczeństwa na przesyłane przez System Operatorów dane, wprowadzono autoryzację polegającą na wpisaniu nazwy użytkownika oraz hasła wraz z numerem Rejonu. Po uzupełnieniu danych pod warunkiem ich poprawności, zwracany jest tzw. klucz sesyjny, który jest niezbędny do wywołania poszczególnych funkcji (poza Login). Dzięki niemu uzyskiwany jest dostęp do danych Systemu Operatora. W przypadku podania błędnego lub klucza który utracił ważność, wywoływana funkcja nie zwróci danych, lecz zasygnalizuje problem odpowiednim statusem. Klucz sesyjny ma swój okres ważności. W przypadku, gdy przez pewien określony czas nie będzie wywołana żadna funkcja przy jego użyciu, zostanie uznany za nieważny Funkcja: Login() Opis Funkcja zwraca klucz sesyjny wykorzystywany do komunikacji z webservices Operatora. Wejście Nazwa użytkownika, hasło oraz identyfikator Rejonu: User: string, Pass: string, CustomerNumber: Integer. Wyjście Klucz sesyjny jako ciąg znaków (string). wymianę danych od ustalenia momentu ostatniej zmiany danych w Systemie Operatora (w podziale na typy danych i dokumentów). Jeżeli data ostatniej zmiany danych jest późniejsza, niż data ostatniego pobrania danych, System MKSI pobiera nowe dane, wykorzystując stosowne funkcje. ZM GOAP

14 2.2 GetVehicleList Funkcja zwraca listę pojazdów używanych przez System Operatora. Wejście: - Klucz sesyjny służący do uwierzytelnienia. - ModifiedAfter: DateTime data i czas od którego system powinien pobrać zmiany danych. Nazwa funkcji: Opis: Wyjście: GetVechicleList Lista pojazdów. Lista pojazdów w postaci dokumentu XML <?xml version="1.0" encoding="utf-8"?> <result> <vehicle id="1"> <name>przykładowy pojazd</name> <plate-number>kr 12345</plate-number> <mark>fiat</mark> <model>panda</model> <production-date>2006</production-date> <kerb-weight>1250</kerb-weight> <side-number>...</side-number> <last-modification>...</last-modification> </vehicle> <vehicle id="2"> </vehicle> <vehicle id="n"> </vehicle> </result> Rys. 1 Struktura pliku XML zwracanego przez funkcję GetVehicleList() Tabela 1. Opis parametrów zwracanych przez wywołanie metody GetVehicleList. Parametr: Opis parametru: vehicle id name plate-number mark model production-date kerb-weight side-number last-modification Identyfikator pojazdu Nazwa Numer rejestracyjny Marka Model Data produkcji Masa własna Numer boczny Data i czas ostatniej modyfikacji rekordu ZM GOAP

15 Rys. 2 Diagram XSD dla metody GetVehicleList 2.3 GetVehicleById Funkcja zwraca parametry pojazdu o wskazanym identyfikatorze. Wejście: -Klucz sesyjny służący do uwierzytelnienia (SessionId) -IDPojazdu: (VevicleID) Nazwa funkcji: Opis: Wyjście: GetVehicleById Pobranie informacji tylko o jednym pojeździe. Opis pojazdu w postaci dokumentu XML <?xml version="1.0" encoding="utf-8"?> <result> <vehicle id="1"> <name>przykładowy pojazd</name> <registration-number>kr 12345</registration-number> <mark>fiat</mark> <model>panda</model> <production-date>2006</production-date> <kerb-weight>1250</kerb-weight> <side-number>...</side-number> <last-modification>...</last-modification> </vehicle> </result> Rys. 3 Struktura pliku XML zwracanego przez funkcję GetVehicleById() ZM GOAP

16 Tabela 2. Opis parametrów zwracanych przez wywołanie metody GetVehicleById Parametr: vehicle id name registration-number mark model production-date kerb-weight side-number last-modification Opis parametru: Identyfikator pojazdu Nazwa Numer rejestracyjny Marka Model Data produkcji Masa własna Numer boczny Data i czas ostatniej modyfikacji rekordu Rys. 4 Diagram XSD dla metody GetVehicleById 2.4 GetVehicleListLastState Funkcja zwraca informacje o bieżących pozycjach i stanach pojazdów. Opis: Wyjście: Informacje o bieżących pozycjach i stanu pojazdów w formie XML XML opisujący poszczególny aktualny stan wszystkich pojazdów ZM GOAP

17 Wejście: -Klucz sesyjny służący do uwierzytelnienia (SessionId) -ModifiedAfter: DateTime data i czas od którego pobrać dane <?xml version="1.0" encoding="utf-8"?> <result> <vehicle id="1"> <name>...</name> <datetime>...</datetime> <country>...</country> <latitude>...</latitude> <longitude>...</longitude> <state>...</state> <direction>...</direction> <velocity>...</velocity> <last-modification>...</last-modification> <last-continous-data-event-modtime> </last-continous-data-event-modtime> <last-continous-data-event-time> </last-continous-data-event-time> </vehicle-state> <vehicle-state id="2">... </vehicle-state> </result> Rys. 5 Struktura pliku XML zwracanego przez funkcję GetVehicleListLastState Tabela 3. Opis parametrów zwracanych przez wywołanie metody GetVehicleListLastState Parametr: name datetime country latitude longitude state direction velocity last-modification Opis parametru: Nazwa Data Kraj Latitude Longitude Stan- (jazda, postój)- ostatnie zarejestrowane zdarzenie Kierunek Prędkość Data i czas ostatniej modyfikacji rekordu Wskazuję datę i czas modyfikacji rekordu wskazanego przez pole Last-Continous-Data-Event-Time last-continous-dataevent-modtime last-continous-dataevent-time Wskazuje zarejestrowaną datę i czas wystąpienia ostatniego zdarzenia z ciągu zdarzeń które nie zostaną już zmodyfikowane. Oznacza to, że wszystkie zdarzenia zarejestrowane do tego czasu zostały już przesłane, nie występują już uzupełnienia i modyfikacje danych. Wszystkie dodane i zmodyfikowane w przyszłości rekordy będą miały datę i czas większy lub równy wskazanemu w tym polu ZM GOAP

18 Rys. 6 Diagram XSD dla metody GetVehicleListLastState 2.5 GetVehicleEvents Funkcja zwraca dane dotyczące pojazdu za zadany zakres czasu. Opis: Wyjście: Dane dla pojazdu za zadany zakres czasu. XML opisujący zdarzenia wykonane w zadanym przedziale czasu Wejście: - Klucz sesyjny służący do uwierzytelnienia (SessionId) - Identyfikator pojazdu (INT, VehicleId) - Data początkowa zakresu czasu (DateTime, DateTimeFrom) - Data końcowa zakresu czasu (DateTime, DateTimeTo) -ModifiedAfter: DateTime data i czas od którego pobrać dane ZM GOAP

19 <?xml version="1.0" encoding="utf-8"?> <result> <event> <event id= 1 > <vehicle-id>1</vehicle-id> <event-type-id>1</event-type-id> <gpscoordinates> <lat> </lat> <long> </lon> </gpscoordinates> <datetime> :40:53</datetime> <maxspeed> </maxspeed> <distance>0</distance> <direction>0</direction> <continer-id> </continer-id> <container-type-id></container-type-id> <waste-type-id> </waste-type-id> <location-id>98</location-id> <weight>100</weight> <notice>postój</notice> <notice-id>3</notice-id> <last-modification> :40:53</last-modification> </event> </events> </result> Rys. 7 Struktura pliku XML zwracanego przez funkcję GetVehicleEvents Tabela 4. Opis parametrów zwracanych przez wywołanie metody GetVehicleEvents Parametr: vehicle-id event-type-id DateTime gpscoordinates maxspeed distance direction RFID-code container-id container-type-id Opis parametru: Identyfikator pojazdu Identyfikator zdarzenia Data I czas ostatniego zdarzenia (Latitude, Longitude) Długość i szerokość geograficzna Prędkość maksymalna od poprzedniego zarejestrowanego punktu w km/h Dystans przebyty od ostatniego zdarzenia w metrach Kierunek jazdy (azymut) w stopniach. Kod RFID pojemnika Identyfikator pojemnika Identyfikator typu pojemnika ZM GOAP

20 waste-type-id Identyfikator typu odpadu location-id Identyfikator lokalizacji weight Masa zważona notice Notatka notice-id Identyfikator notatki Last-modification Data i czas ostatniej modyfikacji rekordu Tabela 5. Opis identyfikatorów zdarzeń zwracanych poprzez wywołanie metody GetVehicleEvents Event-Type-Id zdarzenie 1 jazda 2 postój 3 załadowanie odpadów (podniesienie wrzutnika) 4 załadowanie odpadów (podniesienie wrzutnika) połączone z ważeniem 5 wyładunek odpadów (otwarcie odwłoka) ZM GOAP

21 Rys. 8 Diagram XSD dla metody GetVehicleEvents 2.6 GetContainersList Funkcja zwraca listę pojemników w danej lokalizacji. Wejście: - Klucz sesyjny służący do uwierzytelnienia (SessionId) Opis: Wyjście: Dane o obsługiwanych pojemnikach XML opisujący pojemniki obsługiwane przez wykonawcę ZM GOAP

22 <?xml version="1.0" encoding="utf-8"?> <result> <containers> <container id= 1 > <rfid> </rfid> <container-type-id>1</container-type-id> <lon> </lon> <lat> </lat> <location-id>40</location-id> <customer-id>34</customer-id> <last-modification> :40:53</last-modification> </container> </containers> </result> Rys. 9 Struktura pliku XML zwracanego przez funkcję GetContainers list Tabela 6. Opis parametrów zwracanych przez wywołanie metody GetContainersList Parametr: RFID container id lon lat location-id customer-id Last-modification Opis parametru: Kod RFID pojemnika Identyfikator pojemnika Longitude latitude Identyfikator lokalizacji Identyfikator klienta Data i czas ostatniej modyfikacji rekordu ZM GOAP

23 Rys. 10 Diagram XSD dla metody GetContainersList 2.7 GetScheduleList Funkcja zwraca harmonogram objazdu tras przez pojazdy Wykonawcy. Wejście: Klucz sesyjny służący do uwierzytelnienia, zakres dat dla których należy pobrać harmonogramy Opis: Dane o harmonogramach w sektorze Wejście: DateFrom Date Data początkowa zakresu czasu DateTo Date Data końcowa zakresu czasu Wyjście: XML opisujący zaplanowane wywozy w zadanym przedziale czasu ZM GOAP

24 ZM GOAP

25 Rys. 12 Diagram XSD dla metody GetScheduleList 2.8 GetFuncModificationStatus Nazwa funkcji: Opis: Wyjście: GetFuncModificationStatus Pobranie informacji o ostatniej aktualizacji danych dostępnych przez interfejsy do integracji Lista funkcji ze statusem modyfikacji w postaci dokumentu XML ZM GOAP

26 <?xml version="1.0" encoding="utf-8"?> <result> <functions> <function> <name>getschedulelist</name> <last modification> :46:20</last modification> </function> <function> <name>getvehicleevents</name> <last modification> :46:20</last modification> </function> </functions> </result> Rys. 13 Struktura pliku XML zwracanego przez funkcję GetFuncModificationStatus Rys. 14 Diagram XSD dla metody GetFuncModificationStatus Tabela 8. Opis parametrów zwracanych przez wywołanie metody GetFuncModificationStatus Parametr: name Last modification Opis parametru: Identyfikator funkcji wykorzystywanej do integracji Identyfikator pojemnika ZM GOAP

27 2.9 LocationList Nazwa funkcji: Opis: LocationList Pobranie listy lokalizacji <?xml version="1.0" encoding="utf-8"?> <result> <location id="1"> <name> </name> <outno> </outno> <country> <country/> <city> </city> <street> </street> <postal> </postal> <lon> </lon> <lat> </lat> <last-modification> :12:38</last-modification> </location> <location id="2"> </location> </result> Rys. 15 Struktura pliku XML zwracanego przez funkcję LocationList Tabela 8. Opis parametrów zwracanych przez wywołanie metody LocationList Parametr: name outno country city postal lon lat Opis parametru: Nazwa lokalizacji Zewnętrzny identyfikator Kraj Miasto Kod pocztowy longitude latitude ZM GOAP

28 Rys. 16 Diagram XSD dla metody LocationList 2.10 CustomerList Nazwa funkcji: Opis: CustomerList Odczytanie listy klientów <?xml version="1.0" encoding="utf-8"?> <result> <customer id="..."> <name>...</name> <outid>...</outid> </customer> <customer id="..."> <estate-type-id> </estate-type-id > </result> Rys. 17 Struktura pliku XML zwracanego przez funkcję CustomerList Tabela 9. Opis parametrów zwracanych przez wywołanie metody CustomerList Parametr: name estate-type-id outid Opis parametru: Nazwa klienta Identyfikator typu nieruchomości Zewnętrzny identyfikator ZM GOAP

29 Rys. 18 Diagram XSD dla metody CustomerList 3 Opis typów danych Nazwa Typ Opis UniqueEventID Bigint Unikalny identyfikator zdarzenia dla każdego pojazdu. DateTime DateTime Czas z GPS określony z dokładnością do sekund GPSCoordinates Double,Double Współrzędne geograficzne (długoś, szerokość) z GPS podane w stopniach VehicleID Int Unikalny identyfikator pojazdu. EventTypeID TinyInt Identyfikator zdarzenia LastModification DateTime Czas ostatniej modyfikacji rekordu MaxSpeed Double Maksymalna prędkość od poprzedniego zdarzenia [km/h] Distance Int Dystans przebyty od ostatniego zdarzenia [m] Direction Int Kierunek jazdy określony przez GPS w stopniach [0-359] ContainerID BigInt Unikalny identyfikator pojemnika ContainerTypeID TinyInt WasteTypeID TinyInt LocationID BigInt Unikalny identyfikator posesji/lokalizacji/mgo Weight Double Masa odpadu [kg] NoticeID Tinyint Identyfikator zdefiniowanych notatek NoticeText VarChar[255] Treść notatki CustomerID BigInt Unikalny identyfikator właściciela posesji ZM GOAP

30 4 Słowniki 4.1 Słownik typów odpadów Słownik typu odpadów Identyfikator Nazwa Opis 1 ZM Odpady zmieszane 2 SE Odpady zbierane selektywnie 3 PAP Frakcja typu Papier 4 TWS Frakcja typu Tworzywa sztuczne 5 SZK Frakcja typu Szkło 6 ZIE Frakcja typu Odpady zielone 7 WSE Worki na odpady selektywne 8 WPAP Worki na frakcje typu papier 9 WTWS Worki na frakcje typu tworzywa sztuczne 10 WSZK Worki na frakcje typu szkło 11 WZIE Worki na frakcje typu odpady zielone 12 GAB Odpady wielkogabarytowe 4.2 Słownik typów pojemników Słownik typów pojemników Identyfikator Nazwa Opis 1 p011/p012 pojemnik 0,11, 0,12 m3 2 p024 pojemnik 0,24 m3 3 p036 pojemnik 0,36 m3 4 p1,1 pojemnik 1,1 m3 5 p2,5 pojemnik 2,5 m3 6 p5 pojemnik 5 m3 7 K4 kontener 4 m3 8 K5 kontener 5 m3 9 K6 kontener 6 m3 10 K7 kontener 7 m3 11 K8 kontener 8 m3 12 K10 kontener 10 m3 13 pp0,3 pojemnik podziemny 0,3 m3 14 pp0,8 pojemnik podziemny 0,8 m3 15 pp1,3 pojemnik podziemny 1,3 m3 16 pp3,0 pojemnik podziemny 3,0 m3 17 pp5,0 pojemnik podziemny 5,0 m3 ZM GOAP

31 4.3 Słownik Notatek Identyfikator Nazwa notatki Opis 1 Awaria pojazdu 2 Wyładunek odpadów z pojazdu 3 Pojemnik/kontener uszkodzony 4 Uniemożliwiony dojazd do MGO Niewłaściwy odpad w 5 pojemniku/kontenerze/worku 6 Brak pojemnika/kontenera 7 Brak/uszkodzony Transponder 8 Niezgodny pojemnik 9 Przesyp 1 Załadunek odpadów Zostawiona nalepka OSTRZEŻENIE 4.4 Słownik typów nieruchomości Identyfikator Nazwa Opis 1 N Nieruchomość niezamieszkała 2 Z Nieruchomość zamieszkała 5. WSDL <?xml version="1.0" encoding="utf-8" standalone="no"?> <definitions xmlns=" xmlns:xs=" xmlns:tns=" xmlns:soap=" xmlns:soapenc=" xmlns:mime=" xmlns:ns1="urn:uxmlremotable" xmlns:ns2="urn:" name="webserviceservice" targetnamespace=" <types> <xs:schema xmlns="urn:uxmlremotable" targetnamespace="urn:uxmlremotable"> <xs:complextype name="txmlremotable"> <xs:sequence> <xs:element name="status" type="xs:int"/> <xs:element name="xml" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:schema> </types> <message name="login0request"> <part name="user" type="xs:string"/> <part name="password" type="xs:string"/> <part name="customernumber" type="xs:int"/> <message name="login0response"> <part name="return" type="xs:string"/> <message name="getvehiclelist1request"> <part name="sessionid" type="xs:string"/> <part name="modifiedafter" type="xs:datetime"/> <message name="getvehiclelist1response"> <part name="return" type="ns1:txmlremotable"/> <message name="getvehiclebyid2request"> <part name="sessionid" type="xs:string"/> <part name="vehicleid" type="xs:int"/> <message name="getvehiclebyid2response"> <part name="return" type="ns1:txmlremotable"/> ZM GOAP

32 <message name="getvehiclelistlaststate3request"> <part name="sessionid" type="xs:string"/> <part name="modifiedafter" type="xs:datetime"/> <message name="getvehiclelistlaststate3response"> <part name="return" type="ns1:txmlremotable"/> <message name="getvehicleevents4request"> <part name="sessionid" type="xs:string"/> <part name="vehicleid" type="xs:int"/> <part name="modifiedafter" type="xs:datetime"/> <part name="datefrom" type="xs:datetime"/> <part name="dateto" type="xs:datetime"/> <message name="getvehicleevents4response"> <part name="return" type="ns1:txmlremotable"/> <message name="getvehicleeventsupdate4request"> <part name="sessionid" type="xs:string"/> <part name="vehicleid" type="xs:int"/> <part name="modifiedafter" type="xs:datetime"/> <message name="getvehicleeventsupdate4response"> <part name="return" type="ns1:txmlremotable"/> <message name="getcontainerslist5request"> <part name="sessionid" type="xs:string"/> <message name="getcontainerslist5response"> <part name="return" type="ns1:txmlremotable"/> <message name="getschedulelist6request"> <part name="sessionid" type="xs:string"/> <part name="datefrom" type="xs:date"/> <part name="dateto" type="xs:date"/> <message name="getschedulelist6response"> <part name="return" type="ns1:txmlremotable"/> <message name="getfuncmodificationstatus7request"> <part name="sessionid" type="xs:string"/> <message name="getfuncmodificationstatus7response"> <part name="return" type="ns1:txmlremotable"/> <message name="locationlist8request"> <part name="sessionid" type="xs:string"/> <part name="modifiedafter" type="xs:datetime"/> <message name="locationlist8response"> <part name="return" type="ns1:txmlremotable"/> <message name="customerlist9request"> <part name="sessionid" type="xs:string"/> <message name="customerlist9response"> <part name="return" type="ns1:txmlremotable"/> <porttype name="igoapwebservice"> <operation name="login"> <input message="tns:login0request"/> <output message="tns:login0response"/> <operation name="getvehiclelist"> <input message="tns:getvehiclelist1request"/> <output message="tns:getvehiclelist1response"/> <operation name="getvehiclebyid"> <input message="tns:getvehiclebyid2request"/> <output message="tns:getvehiclebyid2response"/> <operation name="getvehiclelistlaststate"> <input message="tns:getvehiclelistlaststate3request"/> <output message="tns:getvehiclelistlaststate3response"/> ZM GOAP

33 <operation name="getvehicleevents"> <input message="tns:getvehicleevents4request"/> <output message="tns:getvehicleevents4response"/> <operation name="getvehicleeventsupdate"> <input message="tns:getvehicleeventsupdate4request"/> <output message="tns:getvehicleeventsupdate4response"/> <operation name="getcontainerslist"> <input message="tns:getcontainerslist5request"/> <output message="tns:getcontainerslist5response"/> <operation name="getschedulelist"> <input message="tns:getschedulelist6request"/> <output message="tns:getschedulelist6response"/> <operation name="getfuncmodificationstatus"> <input message="tns:getfuncmodificationstatus7request"/> <output message="tns:getfuncmodificationstatus7response"/> <operation name="locationlist"> <input message="tns:locationlist8request"/> <output message="tns:locationlist8response"/> <operation name="customerlist"> <input message="tns:customerlist9request"/> <output message="tns:customerlist9response"/> </porttype> <binding name="igoapwebservicebinding" type="tns:igoapwebservice"> <soap:binding style="rpc" transport=" <operation name="login"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#login" style="rpc"/> <input> </input> <output> </output> <operation name="getvehiclelist"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#getvehiclelist" style="rpc"/> <input> </input> <output> </output> <operation name="getvehiclebyid"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#getvehiclebyid" style="rpc"/> <input> </input> <output> </output> <operation name="getvehiclelistlaststate"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#getvehiclelistlaststate" style="rpc"/> <input> </input> <output> </output> ZM GOAP

34 <operation name="getvehicleevents"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#getvehicleevents" style="rpc"/> <input> </input> <output> </output> <operation name="getvehicleeventsupdate"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#getvehicleeventsupdate" style="rpc"/> <input> </input> <output> </output> <operation name="getcontainerslist"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#getcontainerslist" style="rpc"/> <input> </input> <output> </output> <operation name="getschedulelist"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#getschedulelist" style="rpc"/> <input> </input> <output> </output> <operation name="getfuncmodificationstatus"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#getfuncmodificationstatus" style="rpc"/> <input> </input> <output> </output> <operation name="locationlist"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#locationlist" style="rpc"/> <input> </input> <output> </output> <operation name="customerlist"> <soap:operation soapaction="urn:goapwebserviceintf-igoapwebservice#customerlist" style="rpc"/> <input> </input> <output> ZM GOAP

35 </output> </binding> <service name="igoapwebserviceservice"> <port name="igoapwebserviceport" binding="tns:igoapwebservicebinding"> <soap:address location=" </port> </service></definitions> 6. Uwagi Zamawiający zastrzega sobie możliwość wprowadzania zmian w powyższej specyfikacji. Interfejs może być rozwijany, a załączony opis ma Wykonawcy służyć do oceny wykonalności integracji i jej wyceny. ZM GOAP