Ми поступово оновлюємо концепцію та термінологію, що використовуються в Tags — рішенні GPS-Trace для відстеження асетів. Оновлення вводить зрозумілішу структуру роботи зі шлюзами, сенсорами та фізичними асетами.
Доступ до Tags керується через зареєстрованих користувачів GPS-Trace Console .
Раніше Tags базувався на двох основних сутностях: шлюзах і асетах. На практиці ця модель не завжди відображала те, як користувачі працюють із фізичними об’єктами.
Наприклад, BLE (Bluetooth Low Energy) маячок, прикріплений до інструмента, і сам інструмент — це не одне й те саме. Маячок можна перемістити, замінити або повторно використати, тоді як інструмент залишається окремим асетом із власною історією.
Щоб зробити цю логіку зрозумілішою, у Tags тепер використовуватимуться три ключові сутності:
- Шлюз
- Сенсор
- Асет
Шлюз
Шлюз — це пристрій, який збирає дані та надсилає їх на платформу.
У більшості випадків це GPS-трекер, який може отримувати дані з:
- BLE-міток і маячків;
- дротових сенсорів, підключених до шлюзу;
- власних параметрів шлюзу.
Шлюз залишається технічною точкою входу, через яку дані надсилаються в Tags.
Шлюзи можуть працювати по-різному залежно від технології, що використовується:
- За технології мобільної GPS-трекер виступає мобільним шлюзом. Він збирає дані з BLE-сенсорів поблизу та надсилає ці дані на платформу GPS-Trace разом зі своїми GPS-координатами.
- За технології Mesh шлюзи є частиною стаціонарної інфраструктури, що складається зі шлюзів і анкерів.
Сенсор
Сенсор — це джерело даних, яке можна прив’язати до асета.
Сенсором може бути:
- BLE-мітка або маячок;
- дротовий сенсор, підключений до шлюзу;
- параметр шлюзу, наприклад рівень палива, температура або стан запалювання;
- кілька параметрів шлюзу, згрупованих в одну сутність.
В оновленій моделі багато сутностей, які раніше називалися асетами, тепер називатимуться сенсорами.
Наприклад:
- BLE-мітка, прикріплена до лікарняного дефібрилятора, — це сенсор;
- параметр температури, отриманий зі шлюзу, можна створити як окремий сенсор;
- групу параметрів шлюзу, вибраних користувачем, також можна створити як сенсор.
Асет
Асет — це фізичний об’єкт, який має цінність для користувача та який потрібно відстежувати.
Асетом може бути:
- контейнер;
- причіп;
- інструмент;
- обладнання;
- вантаж;
- багаж;
- інший фізичний об’єкт.
Сенсор можна прив’язати до асета, щоб отримувати дані про його місцезнаходження, стан або вибрані параметри.
Важлива зміна полягає в тому, що асет може існувати без прив’язаного сенсора. Це означає, що користувачі можуть заздалегідь створювати асети та прив’язувати їх до сенсорів пізніше, коли фізичний об’єкт буде готовий до використання.
Наприклад, компанія може створити записи для 100 контейнерів до того, як до них буде прикріплено BLE-мітки. Пізніше, коли контейнери будуть підготовлені, користувач зможе прив’язати кожен контейнер до відповідного сенсора.
Чому модель змінюється
Головна мета цього оновлення — відокремити фізичні об’єкти від джерел даних, які використовуються для їх відстеження.
Раніше асет часто означав «мітку, прикріплену до об’єкта». Однак у багатьох реальних сценаріях мітка й об’єкт мають різні ролі.
Наприклад, у лікарні:
- каталки — це асети;
- BLE-мітки, прикріплені до каталок, — це сенсори;
- пристрої, що збирають дані з BLE-міток, — це шлюзи.
Якщо одну каталку виводять з експлуатації, BLE-мітку можна зняти та прикріпити до іншої каталки. В оновленій моделі користувачу не потрібно створювати все з нуля. Він може відв’язати сенсор від одного асета та прив’язати його до іншого.
Це допомагає зберігати історію, прив’язану до фізичного асета, а не лише до мітки. Користувачі бачать точніший запис для кожного асета, навіть якщо прив’язаний сенсор змінюється з часом.
Такий підхід корисний, коли:
- сенсори повторно використовуються для різних асетів;
- асети створюються заздалегідь і прив’язуються до сенсорів пізніше;
- деякі асети тимчасово не використовуються;
- сенсор замінюється, але історія асета має залишатися прив’язаною до фізичного об’єкта;
- користувачам потрібно вести окремий облік фізичних об’єктів і технічних пристроїв.
Додаткові приклади
Приклад 1: Орендні інструменти
Орендна компанія працює з дрилями, генераторами та іншими інструментами.
- Кожен інструмент — це асет.
- BLE-мітка, прикріплена до інструмента, — це сенсор.
- Трекер, встановлений у сервісному транспорті або на складі, може працювати як шлюз.
Компанія може створити записи асетів для нових інструментів до призначення їм BLE-міток. Коли інструменти будуть готові до використання, сенсори можна прив’язати до відповідних асетів.
Приклад 2: Контейнери та вантаж
Логістична компанія відстежує контейнери та вантаж.
- Контейнер — це асет.
- BLE-мітка або маячок, прикріплені до контейнера, — це сенсор.
- Трекер, встановлений у транспортному засобі або на об’єкті, — це шлюз.
Якщо BLE-мітку знімають з одного контейнера й прикріплюють до іншого, користувачу потрібно лише оновити зв’язок між сенсором і асетом.
Приклад 3: Параметри шлюзу як сенсори
Користувачу можуть бути потрібні звіти на основі даних, отриманих безпосередньо зі шлюзу, наприклад:
- рівень палива;
- температура;
- мотогодини;
- інший вибраний параметр.
У цьому випадку користувач може створити сенсор на основі одного або кількох параметрів шлюзу. Цей сенсор потім можна використовувати для історії та звітів.
Оновлення інтерфейсу
Через оновлену термінологію та логіку інтерфейс Tags також поступово змінюватиметься.
Нові та оновлені елементи інтерфейсу буде запроваджено для:
- керування шлюзами, сенсорами та асетами;
- прив’язування та відв’язування сенсорів і асетів;
- перегляду історії та звітів по сенсорах/асетах;
Історія, звіти та відстеження в реальному часі
В оновленій концепції історія, звіти та функції, пов’язані з відстеженням, будуть доступні для сенсорів і асетів.
Зокрема:
- історія переміщень;
- звіти;
- події, пов’язані з відстежуваними об’єктами;
- зміни статусу на основі прив’язаних сенсорів.
У майбутніх оновленнях Tags також буде розширено додатковими інструментами відстеження для сенсорів і асетів, такими як поїздки, сповіщення на основі параметрів та інші функції, що допомагають користувачам відстежувати переміщення, статус і події.
Шлюзи залишаться технічними сутностями, які використовуються переважно для збору та передачі даних. Якщо користувачу потрібно відстежувати сам шлюз, отримувати історію, звіти чи інші функції відстеження, він може створити сенсор на основі потрібних параметрів шлюзу. Після цього цей сенсор можна використовувати в Tags так само, як і інші сенсори.
Це відокремлює білінг за збір даних від білінгу за функції, пов’язані з відстеженням. Шлюзи залишаються недорогими, коли їх використовують лише для збору та передачі даних, тоді як розширені функції відстеження оплачуються лише тоді, коли користувач вирішує створити сенсор на основі параметрів шлюзу.
Зміни в ціноутворенні
Ціноутворення також буде узгоджено з оновленою термінологією.
Білінг базуватиметься на двох сутностях:
- шлюзах;
- сенсорах.
Плати за асети не буде.
На практиці логіка білінгу залишається близькою до поточної моделі. Головна зміна — сутності тепер матимуть точніші назви.
Ціна шлюзу залишається незмінною:
- 1 шлюз — 0.1 EUR за шлюз / на місяць.
Ціна сенсора також залишається незмінною:
- 1 сенсор — від 0.1 EUR до 0.5 EUR за сенсор на місяць, залежно від вибраного плану
Сенсор — це сутність, яку раніше часто називали асетом.
Ця модель дозволяє користувачам керувати фізичними об’єктами окремо від пристроїв і джерел даних, що використовуються для їх відстеження, без зміни базового підходу до ціноутворення.
Оновлені ліміти
Ліміти для одного акаунта Tags також буде оновлено.
Максимальні ліміти будуть такими:
- 500 шлюзів
- 500 сенсорів
Щоб інтерфейс залишався зручним, а застосунок — стабільним для сценаріїв відстеження в реальному часі, для шлюзів і сенсорів потрібні чіткі ліміти на рівні акаунта.
Водночас асети тепер відокремлено від сенсорів. Це означає, що користувачі можуть створювати записи асетів для фізичних об’єктів незалежно від кількості шлюзів і сенсорів, які використовуються для збору даних.
Якщо користувачу потрібно працювати з більшою кількістю шлюзів або сенсорів, він може використовувати кілька акаунтів Tags і швидко перемикатися між ними.
Коли розпочнуться зміни
Глобальні оновлення розпочнуться 10 червня 2026 року.
З початку процесу оновлення інформація про нову термінологію, ліміти, інтерфейс і функціональність Tags поступово оновлюватиметься в ресурсах GPS-Trace протягом приблизно двох тижнів.
Оновлена модель Tags спростить опис реальних процесів відстеження асетів, керування зв’язками між фізичними об’єктами та сенсорами, а також допоможе зберігати історію, прив’язану до асетів, які мають цінність для користувачів.