Журнал змін

Продуктові віхи екосистеми V.A.D. IIoT, реліз за релізом — нові модулі платформи, інтеграції, мови та робота над надійністю.

v3.2.0 У розробці

Моніторинг, ролі та нові способи підключення

Три паралельні гілки: сервіс моніторингу з єдиним реєстром детекторів і спільною таблицею подій, модель авторизації на об’єктах-політиках та розширення способів підключити пристрій або регіон — режим проксіювання і регіональний пакет відповідності.

  1. Нове

    Єдиний реєстр детекторів і спільна таблиця подій моніторингу

    Проблемні події надходять із різних джерел: демон збору, модуль укладання, регламентні перевірки, AI-аналіз. Сервіс зводить їх до двох сутностей — довідника детекторів, який каже, що вважається проблемою та до якого сервісу й групи відповідальності вона належить, і однієї таблиці подій, куди пишуть усі джерела. Дашборди, фільтри та звіти читають її напряму, тож рахунок проблем усюди однаковий.

    Докладніше
  2. Надійність

    Маркери проблемних сеансів на етапі укладання

    Сеанс оцінюється в момент запису до бази. Правила задані порогами: вихід на зв’язок раніше розкладу більш ніж на 15 хвилин, падіння напруги телеметричної батареї понад 0,1 В відносно попереднього сеансу, метрологічної — понад 0,05 В, аномальна тривалість з’єднання. Сеанс отримує маркер, а добова зведення збирається з маркерів, а не переобчисленням архіву — вартість перевірки не зростає разом із парком.

  3. Безпека

    Правила доступу на об’єктах-політиках

    Модель доступу побудована на об’єктах-політиках: по класу на ресурс, звичайні методи замість предметної мови. Роль описується набором іменованих повноважень із прапорцями активності та «увімкнено за замовчуванням», тож склад прав налаштовується під розгортання без випуску збірки. Політика лишається звичайним об’єктом і покривається юніт-тестами, а не наскрізним сценарієм через веб.

    Докладніше
  4. Інтеграції

    Перенесення контролерів і подань API у простір імен v3

    Публічний контракт отримує власний простір імен: контролери та подання переносяться у v3, а v1 лишається замороженим як сумісна точка входу. Ламкі зміни робляться лише в новому просторі, тож розвиток API не потребує узгодження з кожним інтегратором. Відповіді локалізуються — довідники й текстові описи повертаються мовою користувача, від якого прийшов запит.

    Докладніше
  5. Інтеграції

    Третій режим роботи з приладом — проксіювання

    Прилад працює з двома серверами: один ведучий, другий резервний. Третій режим додає проксіювання — служба збору приймає з’єднання і передає дані далі, лишаючись прозорою для приладу. Це закриває майданчики без прямого маршруту до платформи. Режим відображається і на боці сервера збору, і в інтерфейсі, тож під час розбору зв’язку видно, яким шляхом прийшли дані.

    Докладніше
  6. Швидкодія

    Кеш останнього сеансу та моделі приладу в таблиці телеметрії

    Останній сеанс зв’язку та посилання на модель приладу обліку кешуються поруч із записом телеметрії — напруга батареї, код стану сеансу, одиниці вимірювання. Списки й фільтри по всьому парку обслуговує один запит замість звернення до архіву на кожен екран, тож час відгуку не залежить від глибини історії. Кеш оновлюється під час укладання, тому його відставання обмежене сеансом зв’язку, а не періодом регламентного перерахунку.

  7. Нове

    MENA Compliance Pack

    Вимоги країн регіону розходяться, але перетинаються в ядрі: правила для IoT, кібербезпека, захист персональних даних, обмеження на хмарне розміщення, промислова експлуатація. Пакет фіксує спільне ядро й виносить розбіжності в додатки по країнах, а конфігурація розгортання посилається на потрібний додаток. Документ відповідає на питання застосовності ще до початку пілота — його адресовано замовникам, локальним партнерам, системним інтеграторам і державним організаціям.

v3.1.0 Стабільний (актуальний)

Достовірність і читабельність даних приладу

Дані від пристрою розбираються за специфікацією протоколу: бітові маски розкладаються побітово, коди виводяться в шістнадцятковому вигляді, описи в архівах будуються від стану обладнання. Накопичений архів перераховано за тією ж логікою.

  1. Надійність

    Побітовий розбір масок стану в журналах подій і аварій

    Поля стану подій і аварій у протоколі Type-M — 16-бітні маски: біт 1 — низький заряд АКБ, біт 2 — низький рівень сигналу GSM, біт 15 (32768) — старт приладу. Розбір іде побітово й звіряється з порогами прошивки: подія низького заряду зводиться нижче 11,7 В, знімається вище 12,0 В, гістерезис 300 мВ. Описи в журналі будуються з розшифрованих бітів, накопичений архів перераховано за тією ж логікою — 7 872 записи оновлено, 112 924 додано.

  2. Покращено

    Переписані підписи вкладок і описи подій в архівах приладу

    Тексти у вкладках архівів написані від стану обладнання, а не від полів пакета: опис каже, що сталося з приладом. Підписи вкладок не повторюють назву розділу, а стовпець стану названо «Прапорці» — за змістом вмісту. Значення виводяться моноширинним шрифтом, тож ширина стовпця не залежить від довжини значення.

    Докладніше
  3. Покращено

    Виведення кодів аварій і подій у шістнадцятковому вигляді

    Коди аварій і подій виводяться у шістнадцятковому вигляді: 0x8000, 0x0001, 0x0000 — із провідними нулями до чотирьох розрядів. Моноширинний шрифт вибудовує розряди вертикально між рядками, тож зведений біт видно одразу й звіряється зі специфікацією протоколу без переведення з десяткової.

  4. Покращено

    Стан таблиць: розмір сторінки, розмірності, коди повторів

    Таблиці даних тримають стан між переходами: обраний розмір сторінки зберігається. Розмірність винесена із заголовка стовпця до самого значення — заголовок лишається коротким, а одиниця видна там, де число. Лічильник повторів показує і кількість спроб, і код причини, тож якість каналу читається просто з таблиці.

  5. Швидкодія

    Профілювання черги укладання в сервері фонових задач

    Фоновий конвеєр укладання профільовано поетапно й перебалансовано між воркерами. Показання потрапляють в архів одразу після сеансу зв’язку, а черга тримає темп зі зростанням парку — задачі розбираються швидше, ніж наповнюються, і запас пропускної здатності видно в лозі укладання.

    Докладніше
v3.0.0 Стабільний

Промислова експлуатація

Перший промисловий реліз третього покоління: оператор веде на ньому діючий парк обліку цілком — збір, зберігання, вебінтерфейс, API та аналітика. Зверху працює Операційний центр, а параметри сеансів переведено в спільне архівне сховище.

  1. Нове

    Версія 3.0: перший промисловий контур

    Третє покоління виходить із пререлізу: промисловий оператор веде на ньому діючий парк обліку. Демон збору, сховище, вебінтерфейс, публічний API та аналітика працюють в одному контурі. Перехідний період з паралельною експлуатацією двох поколінь завершено.

    Докладніше
  2. Нове

    Операційний центр (OHM)

    Потік сирих тривог перетворюється на керовані операційні проблеми. Детектори та канони зводять повторювані події в одну проблему, кореляція підтягує до неї докази, оцінка здоров’я активу ранжує парк за ризиком, пріоритети та SLA задають строк реакції, робоча черга утримує роботу до закриття. Окремо розбираються масові інциденти — коли одна відмова породжує сотні тривог. Шар AI пропонує наступний крок за накопиченою історією схожих випадків.

    Докладніше
  3. Покращено

    Зберігання й відображення рівня GSM-сигналу в єдиній шкалі dBm

    Рівень GSM-сигналу зберігається в єдиній шкалі dBm незалежно від того, у чому його віддає протокол пристрою — у відсотках, в умовних одиницях чи вже в dBm. Перетворення винесено в драйвери укладання і виконується на вході, а не під час відображення, тож значення однакове в інтерфейсі, в API та у звітах. Накопичені дані переведено в ту саму шкалу, і тренд покриття читається по всій історії парку.

  4. Надійність

    Конвертація історичних сеансів зв’язку в схему v3

    Історія сеансів зв’язку переводиться в схему третього покоління командами міграції. Перенесення йде поетапно: власні канали сеансів приладу, потім спільні канали блока телеметрії, потім приведення до схеми параметрів. Команди запускаються на кожному сервері окремо й працюють частинами, тож збір даних триває, а графіки та звіти охоплюють усю історію приладу.

  5. Швидкодія

    Параметри сеансів зв’язку винесено в спільну архівну таблицю

    Заголовки сеансів лишаються у своїй таблиці, а параметри сеансу пишуться в спільну архівну таблицю — туди ж, куди йдуть показання. Склад параметрів оголошує протокол: у Type-M один набір каналів, у Type-J інший, у MQTT третій. Новий тип пристрою заводиться записами в довідник каналів, без міграції схеми бази даних.

    Докладніше
v3.0.0-rc.1 RC

Датчики тиску й температури: повний тракт

Новий клас пристроїв доведено від протоколу до картки в інтерфейсі: драйвер, модель даних, укладання архівів, довідники типів датчика, одиниці вимірювання. Разом із ним — зв’язки в моделі даних, від яких залежать звіти, фільтри та права доступу.

  1. Нове

    Датчики тиску й температури: драйвер, модель, архіви, картка

    Новий клас пристроїв підтримано на всьому тракті. У демоні збору — драйвер протоколу: пакет ідентифікації автономного блока, поточні значення, архіви, конфігурація. У застосунку — модель даних і укладання: поточний тиск і температура, архівні зрізи, параметри сеансу зв’язку, знімок конфігурації. У вебі — власна картка приладу зі складом полів під датчик.

    Докладніше
  2. Покращено

    Довідник типів датчика і конфігураційні коефіцієнти сенсора

    Тип датчика береться з довідника діапазонів — абсолютний тиск 0…160 кПа, 0…400 кПа, 0…600 кПа, 0…1,0 МПа, 0…1,6 МПа, 0…2,5 МПа й далі за специфікацією, — пов’язаного з моделлю обладнання за третьою нормальною формою. Драйвер укладання визначає тип під час ідентифікації приладу, тож діапазон і одиниці відомі системі, а не лише монтажникові. Вкладка параметрів показує калібрувальні коефіцієнти встановленого сенсора.

    Докладніше
  3. Покращено

    Обрані одиниці вимірювання в усіх поданнях значення

    Обрана одиниця вимірювання застосовується на рівні подання й діє в усіх видах значення — плитка поточного тиску, графік, журнал даних, журнал аварій. Сюди ж належить перерахунок абсолютного тиску в надлишковий: він вмикається прапорцем і діє лише для датчиків з абсолютним вимірюванням. Точність виводиться за датчиком — температура з одним знаком після коми, міліметри ртутного стовпа без дробової частини.

  4. Надійність

    Перевірка повноти архіву конфігурації перед записом у базу

    Зв’язок із приладом може обірватися на середині вивантаження, тому архів конфігурації перевіряється на повноту й цілісність перед записом у базу. Знімок, зібраний не до кінця, не заступає наявний. Поруч із показаннями укладається архів подій. Тож навіть по перерваному сеансу зв’язку лишається слід для розбору.

  5. Покращено

    Фільтр за датою та експорт на вкладці журналу переданих даних

    Журнал переданих даних отримує ту саму панель інструментів, що й решта архівних вкладок. На ній — фільтр за періодом і експорт файлом. Вибірку за потрібний інтервал можна віддати суміжникам просто з інтерфейсу, без звернення до бази.

    Докладніше
  6. Покращено

    Плитки дашборда як точки переходу до обладнання

    Плитки та елементи віджетів дашборда працюють як точки переходу. З обраного вузла, статусу чи лічильника відкривається відповідний вузол обліку або прилад. Дашборд слугує входом у зміну, а не лише зведенням по ній.

    Докладніше
  7. Надійність

    Синхронізація положення запірного пристрою з кінцевими датчиками

    Положення «закрито» і «відкрито» однозначно фіксуються кінцевими датчиками привода. Інтерфейс показує саме те положення, яке ними підтверджене, і залишає керування активним. Стан узгоджується після першого ввімкнення, ручного повороту та сервісних робіт — оператор бачить фактичне положення в полі.

v3.0.0-beta.1 Beta

Зовнішнє приймання та перебудова ядра даних

Платформа пройшла зовнішнє приймальне тестування: сценарії проходили сторонні фахівці, їхні зауваження розібрано до кандидата в реліз. Паралельно розв’язано ядро даних — споживача можуть обслуговувати кілька ресурсопостачальних компаній, а модуль телеметрії описується незалежно від IMEI.

  1. Нове

    Перебудова ядра даних: споживач і канал телеметрії

    Ядро даних перезібрано під задачі третього покоління: споживача можуть обслуговувати кілька ресурсопостачальних компаній, а модуль телеметрії описується незалежно від IMEI. Обидві розв’язки зроблено на рівні схеми, ще до того, як на неї спирається решта функціоналу. Так третє покоління дістає власну модель даних, розраховану на зміну постачальника і на кілька енергоресурсів в одного споживача.

    Докладніше
  2. Інтеграції

    Модуль телеметрії: тип каналу та ідентифікатор

    Модуль телеметрії описується двома полями: тип каналу — GSM, Ethernet, MQTT, концентратор, LoRaWAN — та ідентифікатор відповідного виду: IMEI, IP, MAC, client_id, DevEUI. Під розширену модель адаптовано контролери, звіти, вивантаження, сервіси та API. Новий транспорт додається значенням довідника — в одному місці схеми.

    Докладніше
  3. Надійність

    Хвиля зовнішнього приймального тестування платформи

    Платформа пройшла зовнішнє приймальне тестування на демостенді: сценарії проходили не розробники, а зовнішні фахівці. Зауваження до майстра створення об’єкта, форм, фасетних фільтрів, розкладів і локалізації сповіщень розібрано й закрито до кандидата в реліз. Зовнішнє приймання вбудоване в цикл як обов’язковий етап перед випуском.

  4. Покращено

    Редагування інтервалів роботи блока керування приводом

    Інтервали роботи блока керування приводом редагуються з інтерфейсу. Час привідкриття задається в межах 1–30 с, пауза стабілізації тиску — 30–600 с, час повного ходу — за специфікацією привода. Значення приймаються в секундах з одним знаком після коми й перевіряються за діапазонами, тож одиниця та точність у формі збігаються з паспортом обладнання.

    Докладніше
  5. Покращено

    Відкріплення приладу від вузла обліку без втрати історії

    Прилад відкріплюється від вузла обліку й лишається в системі зі своїми даними. Заміна, переміщення та повернення з ремонту оформлюються як облікові події. Історія вузла обліку та історія приладу завдяки цьому залишаються неперервними й роздільними.

    Докладніше
  6. Безпека

    Статичний аналіз безпеки кодової бази

    Вихідний код проходить статичний аналіз на типові вразливості вебзастосунку. Кожне спрацювання розбирається вручну: аналізатор не бачить контексту, тож частину відсіюють як хибну, решту закривають до релізу. Прогін вбудовано в релізну процедуру, і він повторюється на кожній збірці.

    Докладніше
  7. Мови

    Платформа та пристрої 13 мовами

    Документація платформи v3, лінійка IIoT-пристроїв і весь інтерфейс порталу виходять 13 мовами. Арабську та перську підключено з письмом справа наліво: дзеркалиться вся розкладка, а не лише напрямок тексту. Сторінка, що ще стоїть у черзі на переклад, рендериться англійською на локалізованій URL-адресі й позначається noindex, тож перемикання мови завжди веде на наявну сторінку.

    Докладніше
  8. Інтеграції

    Автореєстрація третього покоління для всієї підтримуваної лінійки

    Автореєстрація третього покоління охоплює всю підтримувану лінійку, зокрема запірну арматуру, керовану по MQTT. Прилад, увімкнений на об’єкті, сам створює вузол обліку й одразу доступний для читання та керування. Ідентифікатор береться з пакета пристрою, тож монтаж обходиться без ручного введення на боці платформи.

    Докладніше
v3.0.0-alpha.3 Alpha

Стек V3 у промисловому контурі

Демон збору та сховище третього покоління розгорнуто в першого промислового замовника, вони прийняли живі показання. Публічний API перевірено на новій моделі даних, відкрито портал документації.

  1. Нове

    AI Analytics: 22 звіти з відкритою методологією та формулами

    Модуль AI-аналітики: 22 звіти по окремих вузлах і по всьому парку — баланси, аномалії тиску, прогноз ресурсу батарей, пошук обходів обліку, атлас несправностей. Методологію та формули кожного звіту опубліковано: видно, на яких полях і припущеннях побудовано висновок, і його можна перерахувати вручну. Тому звіт придатний для розбору із замовником і для долучення до регламентної документації.

    Докладніше
  2. Нове

    Ілюстрований посібник користувача на реальних знімках у двох темах

    Покроковий посібник із роботи з платформою на реальних знімках інтерфейсу — у світлій і темній темах. Обидві серії зняті з одного й того самого стану даних, тому кроки збігаються між темами. Дані на скриншотах знеособлені, тож посібник передається назовні без окремого погодження.

    Докладніше
  3. Нове

    IIoT Платформа v3: архітектура, масштабування та відповідність директивам ЄС

    Мажорний реліз документації: архітектуру, масштабування та відповідність директивам ЄС описано під третє покоління. Версія 3 стала актуальною — на неї ведуть кореневі редиректи. Друге покоління лишається доступним за прямими посиланнями та через перемикач версій.

    Докладніше
  4. Швидкодія

    Реєстр вузлів обліку: таблиця, каскадні фільтри, збережені вибірки

    Реєстр вузлів обліку розрахований на парк у тисячі записів: таблиця з пагінацією та панеллю дій, каскадні фасетні фільтри й збережені користувацькі фільтри. Вибір значення в одному фасеті перераховує допустимі значення в решті, тож порожніх вибірок не лишається. Сторінка вузла зібрана з двох панелей із вкладками й картками.

    Докладніше
  5. Покращено

    Єдиний портал документації платформи, API та IIoT-пристроїв

    Документацію платформи, API та IIoT-пристроїв зведено в один портал: статична збірка, спільний глосарій і AI-асистент по вмісту. Повнотекстовий пошук працює на боці клієнта, без зовнішнього сервісу й ключів. Кожна сторінка віддається і у вигляді вихідного markdown — для тих, хто читає її не очима, а інструментом.

  6. Нове

    Публічний REST API: вузли обліку, архіви показань і сеанси зв’язку

    Платформа надає публічний REST API до вузлів обліку та їхніх характеристик, архівів показань, подій і повідомлень приладів, сеансів зв’язку та довідників. Опис побудовано за ендпоінтами: метод, параметри, формат відповіді, коди помилок. Інтегратор збирає всю інтеграцію просто зі сторінки, без супроводу з нашого боку.

    Докладніше
  7. Інтеграції

    Перевірка публічного API на моделі даних V3

    Кожен ендпоінт публічного API перевірено на моделі даних третього покоління — по одному. Розташування та контракт лишаються там, де їх очікує інтегратор, тож наявні інтеграції працюють без правок. Відповідь архіву конфігурації несе консолідовані метрологічні параметри — мінімальну та максимальну витрату, дату повірки, серійний номер, — які інакше довелося б збирати кількома запитами.

    Докладніше
  8. Нове

    Драйвер протоколу датчиків тиску й температури в демоні збору

    Демон збору отримує драйвер нового протоколу: пакет ідентифікації автономного блока, поточні значення тиску й температури, архіви та знімок конфігурації. Його розміщено поруч з обробкою запірної арматури в тому самому сімействі протоколів, і він перевикористовує розбір сеансової частини. За місяць на цьому фундаменті стоїть модуль цілком — від моделі даних до картки приладу.

    Докладніше
  9. Покращено

    AI-звіти на кожному рівні ієрархії компаній

    Вбудовування звітів прописано на всіх рівнях дерева компаній: головна організація, філія та підрозділ відкривають кожен свій набір аналітичних звітів. Кожен вузол звітує у власному обсязі, на якій би глибині дерева він не стояв. Вбудований блок не має власного заголовка — назва розділу вже є в навігації.

    Докладніше
  10. Надійність

    Зміщення часового поясу в логах демонів збору

    Демони збору працюють у різних країнах і часових поясах, тому в кожен рядок лога додано явне зміщення — формат вигляду 2026-05-27 14:43:43 +03:00. Записи з різних майданчиків шикуються в одну шкалу, щойно їх покласти поруч. Під час розбору інциденту порядок подій по всьому парку відновлюється однозначно.

    Докладніше
  11. Інтеграції

    Стек MQTT-засувки на сервері збору V3

    Стек керованої по MQTT запірної арматури працює на сервері збору третього покоління: обмін, доставка команд, укладання даних і модуль авторегістрації, адаптований під алгоритм V3. Засувка, під’єднана на об’єкті, реєструється сама: створює вузол обліку й одразу приймає команди. Один сервер тримає в такий спосіб увесь парк приводів поряд із приладами обліку.

    Докладніше
  12. Нове

    Повний стек збору й зберігання V3 у першого промислового замовника

    Демон збору та система збору й зберігання даних третього покоління розгорнуті повним комплектом у першого промислового замовника і приймають живі показання. Із цього моменту розробка йде на реальному потоці: архіви, довідники й обсяги відповідають промисловій експлуатації. Аналітика перевіряється на справжніх польових даних, а не на тестовому зліпку.

    Докладніше
v3.0.0-alpha.2 Alpha

Телеметрія за межами GSM

До парку увійшли пристрої, якими платформа не лише читає, а й керує: запірна арматура по MQTT. Реєстр вузлів обліку перебудовано навколо статусів і геоданих, придатних для карти та виїзних бригад.

  1. Інтеграції

    Драйвер MQTT для керованої запірної арматури

    Перший клас пристроїв, які платформа не лише читає, а й якими керує. Драйвер закриває обмін по MQTT, доставку команд і укладання даних запірної арматури. Керувальний контур працює на тому самому стеку, що й обліковий, — окремої підсистеми під приводи не потрібно.

    Докладніше
  2. Покращено

    Єдиний формат геокоординат для всього парку

    Геокоординати парку зведено до єдиного формату: понад вісімсот вузлів обліку, з них 761 оброблено програмно і 48 вручну — там, де найменування потребували звіряння. За підсумками проведено ревізію основної таблиці: вузлів без координат — п’ять, три з них тестові. Реєстр придатний для карти, кластеризації та побудови маршрутів виїзних бригад.

  3. Покращено

    Чотири робочі статуси вузла обліку

    Вузол обліку має чотири робочі статуси: працює, відключений, новий, ремонт. Кожен із них відповідає конкретній дії оператора. Для дашборда статуси згруповано, тому зведення по парку читається без розкриття повного переліку.

    Докладніше
v3.0.0-alpha.1 Alpha

Оболонка нового інтерфейсу

Точка старту третього покоління: єдиний шаблон сторінки, робочий глобальний пошук, менеджер тем і дашборд на бойовій моделі даних. Локалізацію закладено в компоненти з першого дня, а не додано згодом.

  1. Мови

    Локалізація закладена в компоненти нової оболонки

    Локалізація лежить в основі нового інтерфейсу: кожен компонент оболонки приходить із винесеними рядками, а не з текстом у розмітці. Набір мов сервера задається змінними середовища під час розгортання — схема локалізації та перелік локалей. Тому інсталяція під інший ринок обходиться без перезбирання образу.

  2. Нове

    Дашборд на бойовій моделі даних

    Віджети дашборда під’єднано до бойової моделі даних: покриття парку, стан сеансів зв’язку, стани приладів на одному екрані. Це перша перевірка нової оболонки на реальних обсягах і реальній розрідженості даних. Розкладка та запити відпрацьовують на промисловому наборі, а не на фікстурах.

    Докладніше
  3. Нове

    Оболонка інтерфейсу: шаблон сторінки, панелі, менеджер тем

    Фронтенд зібрано на єдиному шаблоні сторінки: шапка й підвал, ліва та права панелі, менеджер тем зі світлим і темним оформленням. Глобальний пошук працює по об’єктах, обладнанні та споживачах із переходом до знайденого запису. Далі всі розділи третього покоління збираються з цього шаблону, що задає єдину поведінку навігації та станів.

    Докладніше