Tags: aktualizacja koncepcji i terminologii

Stopniowo aktualizujemy koncepcję i terminologię stosowaną w Tags, rozwiązaniu GPS-Trace do śledzenia zasobów. Aktualizacja wprowadza bardziej przejrzystą strukturę pracy z bramkami, czujnikami i fizycznymi zasobami.

Dostęp do Tags jest zarządzany przez zarejestrowanych użytkowników GPS-Trace Console.

Wcześniej Tags opierał się na dwóch głównych encjach: bramkach i zasobach. W praktyce ten model nie zawsze odzwierciedlał to, jak użytkownicy pracują z fizycznymi obiektami.
Na przykład latarnia BLE (Bluetooth Low Energy) przymocowana do narzędzia i samo narzędzie to nie to samo. Latarnię można przenieść, wymienić lub użyć ponownie, podczas gdy narzędzie pozostaje oddzielnym zasobem z własną historią.

Aby ta logika była bardziej zrozumiała, Tags będzie teraz korzystać z trzech kluczowych encji:

1. Bramka
2. Czujnik
3. Zasób

Bramka

Bramka to urządzenie, które zbiera dane i wysyła je do platformy.

W większości przypadków jest to lokalizator GPS, który może odbierać dane z:

• tagów i latarni BLE;
• czujników przewodowych podłączonych do bramki;
• własnych parametrów bramki.

Bramka pozostaje technicznym punktem wejścia, przez który dane są wysyłane do Tags.

Bramki mogą działać inaczej w zależności od zastosowanej technologii:

• W technologii Mobile lokalizator GPS działa jako mobilna bramka. Zbiera dane z pobliskich czujników BLE i wysyła je do platformy GPS-Trace wraz z własnymi współrzędnymi GPS.
• W technologii Mesh bramki są częścią stacjonarnej infrastruktury składającej się z bramek i Anker.

Czujnik

Czujnik to źródło danych, które można powiązać z zasobem.

Czujnikiem może być:

• tag lub latarnia BLE;
• czujnik przewodowy podłączony do bramki;
• parametr bramki, np. poziom paliwa, temperatura lub stan zapłonu;
• kilka parametrów bramki zgrupowanych w jedną encję.

W zaktualizowanym modelu wiele encji, które wcześniej nazywano zasobami, będzie teraz nazywanych czujnikami.

Na przykład:

• tag BLE przymocowany do szpitalnego defibrylatora to czujnik;
• parametr temperatury otrzymywany z bramki może zostać utworzony jako osobny czujnik;
• grupa parametrów bramki wybrana przez użytkownika również może zostać utworzona jako czujnik.

Zasób

Zasób to fizyczny obiekt, który ma wartość dla użytkownika i musi być śledzony.

Zasobem może być:

• kontener;
• przyczepa;
• narzędzie;
• element wyposażenia;
• ładunek;
• bagaż;
• inny fizyczny obiekt.

Czujnik może być powiązany z zasobem, aby dostarczać dane o jego lokalizacji, stanie lub wybranych parametrach.

Istotną zmianą jest to, że zasób może istnieć bez powiązanego czujnika. Oznacza to, że użytkownicy mogą tworzyć zasoby z wyprzedzeniem i łączyć je z czujnikami później, gdy fizyczny obiekt będzie gotowy do użycia.

Na przykład firma może utworzyć wpisy dla 100 kontenerów, zanim zostaną do nich przymocowane tagi BLE. Później, gdy kontenery będą przygotowane, użytkownik może powiązać każdy kontener z właściwym czujnikiem.

Dlaczego model się zmienia

Głównym celem tej aktualizacji jest oddzielenie fizycznych obiektów od źródeł danych używanych do ich śledzenia.

Wcześniej zasób często oznaczał „tag przymocowany do obiektu”. Jednak w wielu rzeczywistych scenariuszach tag i obiekt pełnią różne role.

Na przykład w szpitalu:

• nosze to zasoby;
• tagi BLE przymocowane do noszy to czujniki;
• urządzenia, które zbierają dane z tagów BLE to bramki.

Jeśli jedne nosze zostaną wycofane z użycia, tag BLE można odczepić i przymocować do innych noszy. W zaktualizowanym modelu użytkownik nie musi odtwarzać wszystkiego od początku. Może odłączyć czujnik od jednego zasobu i podłączyć go do innego.

Pomaga to zachować historię powiązaną z fizycznym zasobem, a nie tylko z tagiem. Użytkownicy mogą widzieć dokładniejszy zapis dla każdego zasobu, nawet jeśli powiązany czujnik zmienia się w czasie.

To podejście jest przydatne, gdy:

• czujniki są ponownie wykorzystywane dla różnych zasobów;
• zasoby są tworzone z wyprzedzeniem i łączone z czujnikami później;
• niektóre zasoby tymczasowo nie są używane;
• czujnik jest wymieniany, ale historia zasobu musi pozostać powiązana z fizycznym obiektem;
• użytkownicy muszą prowadzić oddzielne ewidencje dla obiektów fizycznych i urządzeń technicznych.

Dodatkowe przykłady

Przykład 1: Narzędzia na wynajem

Firma wynajmująca pracuje z wiertarkami, generatorami i innymi narzędziami.

• Każde narzędzie jest zasobem.
• Tag BLE przymocowany do narzędzia jest czujnikiem.
• Lokalizator zainstalowany w pojeździe serwisowym lub w obszarze magazynowym może działać jako bramka.

Firma może utworzyć wpisy zasobów dla nowych narzędzi, zanim przypisze do nich tagi BLE. Gdy narzędzia będą przygotowane do użycia, czujniki można powiązać z właściwymi zasobami.

Przykład 2: Kontenery i ładunek

Firma logistyczna śledzi kontenery i ładunek.

• Kontener jest zasobem.
• Tag lub latarnia BLE przymocowana do kontenera jest czujnikiem.
• Lokalizator zainstalowany w pojeździe lub w obiekcie może być bramką.

Jeśli tag BLE zostanie odczepiony od jednego kontenera i przymocowany do innego, użytkownik musi jedynie zaktualizować powiązanie między czujnikiem a zasobem.

Przykład 3: Parametry bramki jako czujniki

Użytkownik może potrzebować raportów opartych na danych otrzymywanych bezpośrednio z bramki, na przykład:

• poziom paliwa;
• temperatura;
• motogodziny;
• inny wybrany parametr.

W takim przypadku użytkownik może utworzyć czujnik na podstawie jednego lub kilku parametrów bramki. Taki czujnik można następnie wykorzystywać do historii i raportów.

Aktualizacje interfejsu

Ze względu na zaktualizowaną terminologię i logikę, interfejs Tags również będzie stopniowo się zmieniał.

Nowe i zaktualizowane elementy interfejsu zostaną wprowadzone dla:

• zarządzania bramkami, czujnikami i zasobami;
• łączenia i rozłączania czujników oraz zasobów;
• przeglądania historii i raportów czujników/zasobów;

Historia, raporty i śledzenie w czasie rzeczywistym

W zaktualizowanej koncepcji funkcje związane z historią, raportami i śledzeniem będą dostępne dla czujników i zasobów.

Obejmuje to:

• historię przemieszczania;
• raporty;
• zdarzenia związane ze śledzonymi obiektami;
• zmiany statusu na podstawie powiązanych czujników.

W kolejnych aktualizacjach Tags zostanie również rozszerzony o dodatkowe narzędzia śledzenia dla czujników i zasobów, takie jak podróże, powiadomienia oparte na parametrach oraz inne funkcje, które pomagają użytkownikom śledzić ruch, status i zdarzenia.

Bramki pozostaną encjami technicznymi używanymi głównie do zbierania i przesyłania danych. Jeśli użytkownik musi śledzić samą bramkę, uzyskać historię, raporty lub inne funkcje śledzenia, może utworzyć czujnik na podstawie wymaganych parametrów bramki. Następnie taki czujnik może być używany w Tags w taki sam sposób jak inne czujniki.

Oddziela to rozliczanie za zbieranie danych od rozliczania za funkcje związane ze śledzeniem. Bramki pozostają niedrogie, gdy są używane wyłącznie do zbierania i przesyłania danych, natomiast zaawansowane funkcje śledzenia są rozliczane tylko wtedy, gdy użytkownik zdecyduje się utworzyć czujnik na podstawie parametrów bramki.

Zmiany cen

Cennik zostanie również dostosowany do zaktualizowanej terminologii.

Rozliczanie będzie oparte na dwóch encjach:

• bramkach;
• czujnikach.

Zasoby nie będą płatne.

W praktyce logika rozliczeń pozostaje zbliżona do obecnego modelu. Główną zmianą jest to, że encje będą teraz nazwane bardziej precyzyjnie.

Cena bramki pozostaje bez zmian:

• 1 bramka — 0.1 EUR za bramkę / miesięcznie.

Cena czujnika również pozostaje bez zmian:

• 1 czujnik — od 0.1 EUR do 0.5 EUR za czujnik miesięcznie, w zależności od wybranego planu

Czujnik to encja, która wcześniej często była określana jako zasób.

Ten model pozwala użytkownikom zarządzać fizycznymi obiektami niezależnie od urządzeń i źródeł danych używanych do ich śledzenia, bez zmiany podstawowego podejścia cenowego.

Zaktualizowane limity

Limity dla jednego konta Tags również zostaną zaktualizowane.

Maksymalne limity będą następujące:

• 500 bramek
• 500 czujników

Aby interfejs pozostał wygodny, a aplikacja stabilna w scenariuszach śledzenia w czasie rzeczywistym, bramki i czujniki wymagają jasnych limitów na poziomie konta.

Jednocześnie zasoby są teraz oddzielone od czujników. Oznacza to, że użytkownicy mogą tworzyć wpisy zasobów dla fizycznych obiektów niezależnie od liczby bramek i czujników używanych do zbierania danych.

Jeśli użytkownik musi pracować z większą liczbą bramek lub czujników, może używać wielu kont Tags i szybko przełączać się między nimi.

Kiedy zmiany się rozpoczną

Globalne aktualizacje rozpoczną się 10 czerwca 2026.

Od startu procesu aktualizacji informacje o nowej terminologii, limitach, interfejsie i funkcjonalności Tags będą stopniowo aktualizowane w zasobach GPS-Trace w ciągu około dwóch tygodni.

Zaktualizowany model Tags ułatwi opisywanie rzeczywistych procesów śledzenia zasobów, zarządzanie powiązaniami między obiektami fizycznymi a czujnikami oraz utrzymywanie historii powiązanej z zasobami, które są ważne dla użytkowników.