Najnowsze artykuły
Technologie RFID i EPC | PeerTrack: Platforma do identyfikacji i śledzenia obiektów
4473
post-template-default,single,single-post,postid-4473,single-format-standard,ajax_fade,page_not_loaded,smooth_scroll,,qode-theme-ver-1.4.1,wpb-js-composer js-comp-ver-4.3.4,vc_responsive

PeerTrack: Platforma do identyfikacji i śledzenia obiektów

PeerTrack: Platforma do identyfikacji i śledzenia obiektów

12:19 25 Luty w Inne

STRESZCZENIE

Możliwość identyfikacji i śledzenia poszczególnych towarów, w szczególności na szeroką skalę i poprzez rozproszone sieci, stanowi klucz do realizacji wielu ważnych aplikacji dla biznesu, takich jak: zarządzanie łańcuchem dostaw, śledzenie zasobów czy wykrywanie fałszerstw. Niestety, umożliwianie identyfikowalności poprzez niezależne organizacje wciąż stanowi znaczne wyzwanie w radzeniu sobie z ogromnym wolumenem danych i suwerennością uczestników. W artykule opisano PeerTrack, skalowaną platformę do skutecznej i efektywnej identyfikacji i śledzenia obiektów w szerokiej skali identyfikowalności sieci. Z nowatorskim modelem danych, bazującym na indeksie DHT i rozproszonym procesorze zapytań, PeerTrack dostarcza środowisko, w którym aplikacje do identyfikowalności mogą udzielać danych wśród niezależnych organizacji, wykorzystując model komunikacji peer-to-peer. W artykule zaprezentowano motywy, projekt systemu, wdrożenie oraz dowody koncepcji systemu (z ang. proof-of-concept) platformy PeerTrack.

1. WSTĘP

Identyfikowalność związana jest ze zdolnością aplikacji do identyfikowania i śledzenia stanu (np. lokalizacji) obiektu, obejmując wykrywanie informacji o jego obecnym i przeszłym stanie, jak również szacowaniu informacji stanie przyszłym. Identyfikowalność jest istotna dla szerokiego zakresu zastosowań biznesowych, takich jak: kontrola produkcji, logistyka i dystrybucja, wycofanie wadliwego produktu czy zwalczanie obrotu towarami podrabianymi [6].

Ostatnie postępy w dziedzinie czujników oraz technologii RFiD (Radio-frequency identification) sprawiły, że automatyczną identyfikację i śledzenie ruchu można zastosować na dużą skalę (np. zarządzanie łańcuchem dostaw na terenie całego kraju). Powstająca technika, której zamierzeniem jest identyfikowalność na szeroką skalę, to tak zwana „Networked RFiD” [5,6]. Jej podstawowym założeniem jest upłynnienie systemu danych w sieci, gdzie znaczniki RFiD zawierające jednoznaczny identyfikator oraz inne dane odnoszące się do obiektów, są przechowywane i udostępniane przez Internet. Dzięki „Networked RFiD” aplikacje umożliwiające śledzenie analizują automatycznie zarejestrowane zdarzenia identyfikacyjne, co pozwala wykryć aktualną lokalizację poszczególnych pozycji. Mogą także pobrać informacje historyczne, takie jak poprzednia lokalizacja, czas transportu pomiędzy lokalizacjami czy czas spędzony w magazynie.

Jednak umożliwianie identyfikowalności jest problemem wielowarstwowym[9]. Globalne sieci o szerokiej skali posiadają zdolność do tworzenia bezprecedensowej ilości danych związanych z poszczególnymi obiektami. Istotne wyzwanie skupia się na efektywności zarządzania i udostępniania tych danych w aplikacjach umożliwiających śledzenie. Oczywistym rozwiązaniem jest publikowanie wszystkich zebranych danych w obrębie każdej organizacji do centralnego magazynu danych. Niestety, takie podejście ma kilka wad. Po pierwsze, ruchy obiektu i związane z nim dane są cennymi informacjami biznesowymi, które firmy bardzo niechętnie umieszczają w wspólnym, centralnym magazynie. Po drugie, takie podeście ma bardzo ograniczoną skalowalność i nie jest możliwe do stosowania na szeroką skalę, gdzie ilość zgromadzonych danych może być ogromna [1,2,6,8]. Architektura systemu do zbierania danych, ich przetwarzania i udostępniania musi być skalowana w celu radzenia sobie z danymi zebranymi z sieciowych systemów. Dane muszą być starannie zaprojektowane, aby móc je efektywnie przetwarzać i przechowywać. Aby umożliwić użytkownikom biznesowym tworzenie użytecznych decyzji i analizę w sposób terminowy, rożne rodzaje kwerend identyfikowalności, jak również usługi powiadomienia sterowania zdarzeniami muszą być sprawnie obsługiwane.

Biorąc pod uwagę powyższe problemy, stworzono PeerTrack, platformę do efektywnej identyfikacji i śledzenia obiektów w szerokiej skali identyfikowalności sieci. PeerTrack oferuje czystą architekturę P2P do przetwarzania danych i kwerend. W szczególności opracowano nowatorski model danych dla identyfikowalności sieci, który eliminuje zależności danych pomiędzy organizacjami. Istotne kwerendy identyfikowania i śledzenia zostały wdrożone jako wbudowane funkcje, międzyczasie zapewniona jest elastyczność rozwijania kwerend dodatkowych. W następnej części artykułu przedstawiony zostanie przegląd projektu, wdrożenia platformy oraz szkic proponowanej demonstracji [10].

2. PRZEGLĄD SYSTEMU

PeerTrack (patrz rysunek 1) wykorzystuje rozproszoną tablicę wartości funkcji mieszającej (DHT) infrastruktury Chord [7] do zarządzania partnerami i nadawanymi komunikatami. Każda organizacja jest postrzegana równy partner w sieci. W obrębie partnera, aplikacje mogą uzyskać dostęp do danych lokalnych, jak również zdalne dane innych parterów używając mechanizmu śledzenia (tracking engine) za pośrednictwem Internetu. Mechanizm śledzenia zawiera w sobie model identyfikowalności danych, urządzenie podziałowe oraz rozdzielony procesor kwerendy. Programiści mogą wdrażać różne rodzaje aplikacji identyfikowalności z wykorzystaniem standardowych interfejsów API zbudowanych w na podstawie tych modułów. W celu wpierania usług sterowania zdarzeniami (np. powiadomieniami) została opracowana zasada mechanizmu działania. Monitoruje ona zdarzenia w kolejce, co jest publiczne dla innych modułów. Narzędzie wizualne, tj. edytor zasad (rule editor), umożliwia prostą definicję zasad.

2

Rys. 1 Architektura PeerTrack

PeerTrack wykorzystuje ogólny model danych dla obiektów poruszających się w sieci na dużą skalę, a mianowicie „Model dla Poruszających się Obiektów w Dyskretnej Przestrzeni” (MOODS). Dyskretna przestrzeń odnosi się do skończonego zbioru węzłów (node) oraz reprezentuje wszystkie organizacje w sieci. MOODS eliminuje zależności danych pomiędzy organizacjami przechowując informacje o ruchu obiektów w węzłach, do których obiekt został przetransportowany. W szczególności PeerTrack wprowadza informacje o ścieżce obiektu (IOP), która zawiera właściwości umożliwiające podanie informacji o przychodzących i odchodzących obiektach. Dzięki IOP każdy węzeł utrzymuje części ścieżki poruszających się obiektów i wykorzystuje te informacje w celu przyspieszenia kwerend P2P w sieci.

Indeksator jest kluczem do pozyskania IOP. Indeksuje obserwowany obiekt i jego ostatnią lokalizację (tj. ostatni węzeł, gdzie obiekt był obserwowany) w deterministycznym węźle, zwanym gateway node. Gateway node jest określona wyłącznie przed ID obiektu, dzięki determinizmowi HDT. Gdy obiekt jest obserwowany przez nowy węzeł Nd, węzeł wysyła ID obiektu do swojej gateway node za pośrednictwem indeksowania. Indeksator w gateway node wykorzystuje tę informację, aby aktualizować swój indeks i wysyła wiadomość zwrotną do Nd, powiadamiając skąd pochodzi obiekt (tj. Nd). Międzyczasie indeksowanie wysyła również wiadomość do Nd informując węzeł, że obiekt doszedł do Nd. W rezultacie, IOP jest ustalona. Aby zmniejszyć odgórne indeksowanie dla obiektów o duże objętości, można ulepszyć indeksowanie algorytmu poprzez pogrupowanie obiektów zgodnie z prefiksami ich zakodowanych IDs. Aby określić optymalną długość prefiksów do grupowania, należy starannie dobrać w odniesieniu do obu skalowalność i równoważenie obciążenia. Szczegółowy model indeksowania można znaleźć w [10].

Podstawową zasadą projektowania procesora kwerend jest przetwarzanie kwerendy miejscowo do rozbudowania w miarę możliwości, a w razie potrzeby poprawienia przy użyciu miejscowo dostępnych informacji, przed przekazaniem go do odpowiednich organizacji zdalnych. Ze względu na wprowadzenie IOP w MOODS, nie można wysłać kwerendy do wszystkich węzłów w sieci. Zamiast tego, kwerenda jest przetwarzana według IOP. W rezultacie wydajność przetwarzania kwerend może być znacznie ulepszona. Aby odpowiedzieć na kwerendę śledzenia, czyli znaleźć aktualną lokalizację obiektu, procesor kwerend kontaktuje się z gateway node dla obiektu za pomocą Chord.  Śledzenie kwerend, czyli znalezienie rodowodu obiektu, może być udzielone przez pierwsze śledzenie obiektu (t. znalezienie bieżącej lokalizacji), a następnie po prostu identyfikację pochodzenia listy za pomocą informacji IOP.

3. WDROŻENIE

Platforma PeerTrack zapewnia środowisko do wspierania rozwoju aplikacji umożliwiających śledzenie na szeroką skalę rozproszonych obiektów. Oferuje ona dwa interfejsy dla projektantów aplikacji, tj. interfejs kwerend (query interface) oraz interfejs zasad (rule interface), w postaci Java API. Interfejs kwerend przyjmuje kwerendy i przeprowadza je miejscowo i/lub zdalnie na inne węzły. Interfejs zasad może być użyty do określenia reguł biznesowych dla usług sterowanych zdarzeniami (np. alarmy związane z brakiem materiału na składzie). Te dwa interfejsy zbudowane są na bazie głównych modułów platformy PeerTrack, a mianowicie mechanizmu śledzenia (cracking engine) oraz mechanizmu reguł (rule engine). Otwarty kod źródłowy projektu Java OpenChord[1] został przyjęty jako wdrożenie Chord. [7] Wspiera on przechowywanie wszystkich serializacji obiektów Java w obrębie DHT.

Filter zdarzeń został wdrożony, by filtrować i oczyścić strumień danych zebranych z różnych źródeł danych, np.: czytniki RFiD i czytniki kodów kresowych.

Indeksator jest niewidoczny dla projektantów aplikacji. Wdraża on indeksowanie grupy oraz algorytm nabycia IOP opisany w części 2. Indeksator odczytuje dane z procesora strumieniowego okresowo. Przedmioty obserwowane w cyklu są klasyfikowane w grupy według prefiksów i ich zakodowanych IDs. W tym celu użyta została funkcja kodująca SHA-1 dla utrzymania jednorodności. Długość prefiksu ustala się przez funkcję log2 S + log2 log2 S, gdzie S to rozmiar sieci, reprezentowanych przez ilość węzłów w obrębie sieci. Przeprowadzone eksperymenty pokazują, że funkcja może zagwarantować zarówno skalowalność jak i dobre równoważenie obciążenia.

Procesor zapytań akceptuje kwerendy zarówno warstwy aplikacji jak i warstwy DHT (przepisane z innych węzłów). Klasa Dyspozytor została wdrożona do złapania odpowiadającego zarejestrowanemu procesorowi wystąpienia dla kwerendy przychodzącej. Wszystkie kwerendy i ich procesory wystąpień są wdrożone jako wtyczki (plug-ins). Przykładowo, dla kwerendy śledzenia TrackQuery, która lokuje obiekt, TrackQuery Processor jest wdrożona. Obie klasy są zarejestrowane w procesorze kwerend za pośrednictwem rejestru (Query q, Procesor p), interfejs w czasie wykonania, Kwerenda i Procesor są klasy Java dla wszystkich kwerend i procesorów. Mechanizm ten zapewnia dużą elastyczność i sprawia, że możliwa jest dynamiczna aktualizacja systemu bez restartu. Wdrożone zostało kilka ważnych kwerend dotyczących możliwości śledzenia. Specjalną implementacją jest klasa RewritableQuery, co stanowi kwerendy, które muszą być przepisane do wykonania w innych węzłach za pomocą interfejsu DHT. Identyfikacja i śledzenie Kwerend są podklasą RewritableQuery. Obiektami kwerendy są wszystkie możliwe do serializacji dla bezproblemowej integracji z OpenChord.

Mechanizm zasad jest zbudowany na bazie JBoss Drools2, który zawiera trzy główne moduły, tj. Drools Guvnor, Drools Fusion, Drools Expert. Do zbudowania zasady mechanizmu użyto Drools Fusion oraz Drools Expert. Drools Guvnor służy jako baza wiedzy dla przechowywania i organizowania kontekstów biznesowych i definiowania zasad. Mechanizm zasad monitoruje kolejkę zdarzenia, która odbiera zdarzenia z innych modułów PeerTrack i wyzwala odpowiednie działania, jeżeli spełnione są odpowiednie warunki. Rule Editor (rysunek 2) jest opracowany do zapewnienia graficznego interfejsu dla efektywnego definiowania i edytowania zasad biznesowych. Zawiera również bazę wiedzy, która pomaga użytkownikom, którzy nie posiadają specjalistycznej wiedzy w celu określenia reguł biznesowych z półstrukturalnego języka naturalnego. Edytor wspomaga semantyczne specyfikacje zasad i automatycznie przekłada wizualne przedstawienie zasad na określony język reguł (w tym przypadku Drools Rule Language).

Rys.2 Zrzut ekranu Edytora zasad

Rys.2 Zrzut ekranu Edytora zasad

4. OPIS PRZYPADKU

Opracowano kilka wniosków dotyczących możliwości śledzenia na bazie platformy PeerTrack, w tym mobilnego zarządzania aktywami i zarządzania łańcuchem dostaw. W artykule uwagę skupiono na prezentacji systemu zarządzania aktywami mobilnymi. System ten został wdrożony w International Linen Service PTY LTD. (ILS), firmie dostarczającej komplety pościeli dla ponad 200 klientów (np. hotele, szpitale i domy opieki) w Południowej Australii. Każdy klient ma jedno lub więcej miejsc dostawy (węzłów). W tym systemie wózki (obiekty) są wielokrotnego użytku pojemnikami na pościel i są połączone tagami RFID. Są one transportowane między węzłami i mogą być wykryte przez czytniki RFiD, kiedy dotrą na miejsce dostawy. Zamówienie jest po porostu agregacją kilku wózków dla tego samego klienta. System zarządzania aktywami mobilnymi opracowany na podstawie platformy PeerTrack oferuje usługi zautomatyzowanej identyfikacji i śledzenia z możliwością monitorowania i kontrolowania operacji logistycznych w czasie rzeczywistym w ponad 300 różnych miejscach.

Opracowano także wizualne narzędzie monitorowania, które zostało rozmieszczone w miejscu każdego klienta wraz z usługami sieci P2P. Rysunek 3 przedstawia zrzut ekranu narzędzia wizualizacji wdrożonej w ILS. Aplikacja została użyta w wersji demo, aby pokazać korzyści płynące z zastosowania platformy PeerTrack.

Identyfikacja i śledzenie. Śledzenie wózka może być zainicjowane za pomocą panelu “Order/Object Search Tool”. Po tym, użytkownik wprowadza identyfikator wózka i klika przycisk „Śledź wózek”, narzędzie do wizualizacji tworzy TraceTrolleyQuery, która jest podklasą TraceQuery, i wysyła je do platformy PeerTrack. PeerTrack śledzi go do oryginalnej lokalizacji wózka podążając za IOP zawartym w każdym węźle wzdłuż jego ścieżki ruchu. Wynik wyszukiwania jest pokazany jako podświetlone linie na mapie inicjatora zapytania.

Podobnie do śledzenia wózka, TrackTrolleyQuery jest przesyłane do odpowiedniego gateway node, za pośrednictwem podstawowej strukturalnej nakładki. Gateway node, który utrzymuje swoją ostatnią lokalizację, wysyła spowrotem identyfikator węzła bieżącej lokalizacji podlegającej zapytaniu. Wynik jest pokazany w kwerendzie inicjatora jako Bańka Informacyjna (rysunek 3.).

Z tą strukturą, identyfikowanie i śledzenie może zostać wykonanie z minimalną liczbą połączeń sieciowych. Podczas wdrożenia, w celu dalszego redukowania kosztów sieci buforuje się adres IP klientów, w związku z czym w większości przypadków podstawowy koszt routingu P2P jest eliminowany.

Monitorowanie zapasów. Procesor zapytań oferuje udogodnienia dla twórców programu do wdrożania rożnego rodzaju zapytań i zarejestrowania ich w systemie. Aby zrealizować monitorowanie zapasów w czasie prawie rzeczywistym, wdrażana jest klasa InventoryQuery (która jest podklasą RewritableQuery) i jej procesor InventoryQueryProcessor. Poprzedni definiuje parametry kwerendy zawierając węzły w celu monitorowania i odświeżania przerw. Gdy kwerenda jest wydawana do procesora zapytań InventoryQueryProcessor jest inicjowany przez przetwarzanie zapytań. Dokładniej, InventoryQueryProcessor okresowo wysyła InventoryQueryObiect poprzez OpenChord do monitorowanego węzła.

 Po kliknięciu ikony węzeł, menu kontekstowe wysuwa się z możliwością rozpoczęcia monitorowania węzła. Wyświetlany jest spis w pobliżu węzła (np. liczba „50”, „100”) i odświeżany co pewien przedział czasu.

Monitorowanie w czasie rzeczywistym. Użytkownicy mogą definiować różne rodzaje zasad w platformie PeerTrack oraz dostawać powiadomienie, gdy nastąpi interesujące ich zdarzenie. Zasady dla skutecznych i błędnych dostaw zostały stworzone w The Rule Editor (rysunek 2). Gdy udana zasada dostawy zostanie uruchomiona, czyli wózek jest dostarczany do właściwego miejsca docelowego, „Real-timeOrder/Object Status Monitoring” (obszar na rysunku numer 3) jest aktualizowany najnowszymi informacjami. W tym samym czasie mapa „Global Delivery Network” jest aktualizowana pokazując ikonę na miejscu przeznaczenia dostawy.

Realizowane jest to poprzez indeksator i mechanizm zasad. Jako część procesu nabywania IOP, indeksator zostanie powiadomiony przez gateway node, po tym jak obiekt dotrze do innego węzła. To powiadomienie, jako wydarzenie, jest również wysyłane do kolejki zdarzeń, która jest monitorowana przez mechanizm zasad. W aplikacji wdrożony został także “Internal Workflow Monitoring”, podsystem, który monitoruje wewnętrzne ruchy wózka.

5. WNIOSKI

W artykule przedstawiony został PeerTrack, kompleksowa platforma do skutecznej i efektywnej identyfikacji i śledzenia obiektów na szeroką skalę i rozproszone sieci. PeerTrack opiera się na nowatorskim modelu danych, indeksowaniu opartym na DHT i rozproszonych procesorach kwerend. Platforma została zalegalizowana dzięki stworzeniu dużej liczby pomyślnych aplikacji umożliwiających śledzenie. Obecnie, platforma jest rozszerzana, aby wspierać także zapytania dotyczące przyszłego statusu obiektów. Zazwyczaj obejmuje to pokonanie problemów niepewności wprowadzonych przez aplikacje identyfikowalności używając technik statystycznych i probabilistycznych.

Rys. 3 Wizualizacja narzędzia

Rys. 3 Wizualizacja narzędzia

 

Artykuł powstał jako tłumaczenie artykułu anglojęzycznego:

Yanbo Wu, Quan Z. Sheng, Damith Ranasinghe and Lina Yao, „A Platform for Tracking and Tracing Objects inLarge-Scale Traceability Networks”, The University of Adelaide,  Australia , 2012 rok;

http://www.edbt.org/Proceedings/2012-Berlin/papers/edbt/a54-wu.pdf

Autor tłumaczenia na język polski : Monika Stempniak

 

LITERATURA

[1] R. Agrawal, A. Cheung, K. Kailing, and S. Schönauer. Towards Traceability Across Sovereign, Distributed RFID Databases. In Proc. of the 10th Intl. Database Engineering and Applications Symposium (IDEAS’06), Delhi, India, December 2006.
[2] M. J. Franklin, S. R. Jeffery, S. Krishnamurthy, F. Reiss, S. Rizvi, E. Wu, O. Cooper, A. Edakkunni, and W. Hong. Design Considerations for High Fan-in Systems: The HiFi Approach. In Proc. of the Second Biennial Conf. on Innovative Data Systems Research (CIDR’05), Asilomar, CA, USA, January 2005.
[3] S. R. Jeffery, G. Alonso, M. J. Franklin, W. Hong, and J. Widom. Declarative Support for Sensor Data Cleaning. In Proc. of the 4th Intl. Conf. on Pervasive Computing (Pervasive’06), Dublin, Ireland, May 2006.
[4] M. Jelasity and A. Montresor. Epidemic-Style Proactive Aggregation in Large Overlay Networks. In Proc. of the 24th Intl. Conf. on Distributed Computing Systems (ICDCS’04), Washington, DC, USA, 2004.
[5] G. Roussos, S. S. Duri, and C. W. Thompson. RFID Meets The Internet. IEEE Internet Computing, 13(1):11–13, 2009.
[6] Q. Z. Sheng, X. Li, and S. Zeadally. Enabling Next-Generation RFID Applications: Solutions and Challenges. IEEE Computer, 41(9):21–28, September 2008.
[7] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan. Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications. In Proc. of the 2001 Conf. on Applications, Technologies, Architectures, and Protocols for Computer Communications, New York, NY, USA, 2001.
[8] S. Wu, S. Jiang, B. C. Ooi, and K.-L. Tan. Distributed Online Aggregations. PVLDB, 2(1):443–454, 2009.
[9] Y. Wu, D. C. Ranasinghe, Q. Z. Sheng, S. Zeadally, and J. Yu. RFID Enabled Traceability Networks: a Survey. Distributed and Parallel Databases, 29(5-6):397–443.
[10] Y. Wu, Q. Z. Sheng, and D. Ranasinghe. Peer-to-Peer Objects Tracking in the Internet of Things. In Proceedings of the 40th International Conference on Parallel Processing (ICPP’11), Taipei, Taiwan, 2011.

[1] http://open-chord.sourceforge.net/