Призначення

Відеоматеріали:

• Огляд нововведень версії 8.0.0

Зміст:

1. Сутність
2. Структурна схема
3. Перше знайомство
4. Контрольні точки
5. Авторизація на контрольних точках
   1. Авторизація на контрольних точках через розпізнавання державного номеру авто
   2. Авторизація на контрольних точках через FakeReader
   3. Безконтактна, безкарткова авторизація на контрольних точках
6. Тривожні події
7. Черги
8. Миттєві повідомлення
9. Мої документи
10. Комунікація з обліковою системою підприємства
11. Контроль ваги НЕТТО
12. Відеоспостереження
13. Трафік
14. AGBTablo - інтерактивне табло
15. UCR - універсальний контроллер для Rasbperry
16. Мобільний додаток MobiCard

---

17. Політика конфеденційності
18. Рекомендації що до використання
19. Умови використання

---

20. Обладнання

---

21. Download

---

22. Future

---

23. Changelog

Сутність

• Реєстрація
• КПП (контрольно-пропускний пункт)
• Лабораторія
• Вагова
• Пункт розвантаження/завантаження
• Зона очікування

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

• Карткозчитувачі
• Різноманітні сенсори (оптопари, кінцеві вимикачі, ...)
• Виконуючі механізми
• Вагопроцесори
• Відеокамери

Певна послідовність проходження контрольних точок формує правило. Сукупність та черговість контрольних точок називається логістичним правилом. Кількість логістичних правил на підприємстві залежить від варіацій проходжень по контрольних точках їх кількості та типу. AGBControl відслідковує послідовність проходження контрольних точок згідно логістичного правила.

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

Система відеоспостереження - це тільки перший крок до виявлення порушень. Зазвичай, порушення виявляються постфактум, а отримання інформації з відеоархівів, зв'язаної з даним порушенням, займає не мало часу. AGBControl спрощує дане завдання, чітко зв'язуючи фото та відеоархів з моментом виникнення порушення.

AGBControl фіксує наступні порушення:

• Помилка отримання зображеннь по відеокамерах на контрольних точках
• Відсутній документ Лабораторного аналізу
• Накладна створена без Авторизації через Картку
• Картка авторизації вже в використанні
• Номер Авто не розпізнано
• Порушення при зчитуванні Картки
• Картку заблоковано
• Порушення по Датчиках
• Номер Причепа не розпізнано
• Порушення при авторизації
• Тільки перше зважування Брутто
• Відсутній документ зважування Брутто
• Тільки перше зважування Тари
• Відсутній документ зважування Тари
• Стрибок ваги Тари
• Порушення послідовності проходження контрольних точок
• Порушено строк перебування на контрольній точці
• Порушено строк перебування після контрольної точки
• Відслідклвування різного роду коментарів вільного характеру по товаро-транспортній накладній
• Відслідковування повідомлень вільного характеру від облікової системи підприємства, як порушення чи просте повідомлення
• Події по втраті та відновленню мережевого з'єднання з обладнанням
• Події при залипанні бінарних сенсорів по будь-якому з двох станів
• Несанкціонований проїзд через вагову
• Контроль з'їзду з вагової платформи

Структурна схема

Структурна схема

Основним елементом програмного комплексу AGBControl є AGB сервер.

AGB сервер, взаємодіючи з сенсорами (контроль периметру, вагопроцесор, карткозчитувач, ...), отримує та зберігає інформацію про стан технологічного процесу, та доповнює ці дані фото і відео даними отриманими від відеореєстраторів(систем відеонагляду).

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

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

Контроллери

Та створити контрольні точки на яких необхідно відслідковувати правильність технологічного процесу.

Контрольні точки

До кожної контрольної точки необхідно прив'язати обладнання(відеокамери, сенсори, виконуючі механізми ...) встановлені в даному місці.

Відеокамери, сенсори, виконуючі пристрої

Логістичні правила

Список товаро-транспортних накладних

Логістична мультисхема

• Схема №-1: Автомобіль пройшов зважування тари, номер причепа розпізнано з помилкою, знаходиться на шляху до зважування брутто.
• Схема №-2: Автомобіль порушив логістичне правило - приїхав не на ту точку зважування, номер авто та причепа не розпізнавався по причині помилки отримання зображення з відеокамер.
• Схема №-3: Автомобіль успішно пройшов логістичне правило, порушень технологічного процесу не виявлено, недавно виїхав за межі підприємства.
• Схема №-4: Автомобіль пройшов пункт реєстрації, рухається до вагової, розпізнавання номеру не відбувалось бо розпізнавання виконується на ваговій.

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

Правильність постановки на ваги

Події на сенсорах

• Порушення по сенсорам (близько 40 різнотипних порушень)
• Події по створенню документів реєстрації, лабораторного аналізу, зважування
• Події редагування документів реєстрації та лабораторного аналізу
• Зміна логістичного правила
• Зміна типу зважування
• Примусове закриття накладної
• Заміна ID картки
• Зміна пункту вивантаження/завантаження
• Зміна прийнятності лабораторного аналізу
• Зміна тари

Кожен користувач може індивідуально для себе налаштувати формат повідомлень для отримання тільки певних типів повідомлень. А також обмежити повідомлення від певних контрольних точкок, отримуючи тільки повідомлення в межах свого спостереження.

Інтерактивні спливаючі повідомлення

На закладці "Активні Схеми" для кожної схеми проїзду, відображаються фотографії по всіх камерах розміщених на контрольній точці, створені в момент прибуття транспорту на контрольну точку. Фотографії зникнуть, коли траспорт покине контрольну точку, та буде знаходитись на маршруті десь між контрольними точками.

Медіавікно на закладці "Активні Схеми"

Якщо аналізу фото недостатньо для оцінки валідності ситуації, з фотографії можна перейти на перегляд поточного відео в режимі реального часу.

Медіавікно на Схемі

• agbserver
• agbclient
• agbtablo
• ucr
• MobiCard

Програми agbclient, agbtablo, ucr, MobiCard оновлюються, при необхідності, в момент відновлення з'єднання з agbserver'ом.

Для оновлення agbtablo, необхідна одна умова - продовження роботи X-сервера після припинення роботи agbtablo. Це можна реалізувати наступним чином:

1. Запускати raspberry в cli режимі
2. Після автологіна, запускати X-сервер

Файл .bashrc

Файл .xinitrc

Шаблон прав користувачів

Контрольні точки

Контрольна точка (далі по змісту КТ) - атомарний(неподільний) елемент логістичного правила з власними відмінними характеристиками. Контрольна точка служить для поділу технологічного процесу проходження транспорту на підприємстві згідно однотипності та унікальності операцій.

AGBControl обробляє наступні типи контрольних точок:

• Реєстрація
• КПП (Контрольно-Пропускний Пункт)
• Лабораторія
• Вагова
• Вивантаження
• Завантаження
• Зона очікування

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

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

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

Контрольні точки на яких створюються документи - Реєстрація, Лабораторія, Вагова можуть не містити жодного додаткового обладнання.

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

Кількість КТ в системі AGBControl не обмежена. Кількість позицій однотипних КТ в Логістичному правилі обмежена, та залежить від типу контрольної точки. В одній позиції логістичного правила дозволено використовувати будь-яку кількість однотипних контрольних точок.

Далі, в табличній формі, представлені правила та рекомендації використання контрольних точок в логістичних правилах:

Поведінка на контрольних точках.

Опис поведінки на контрольних точках стосується варіанту коли на КТ використовується рекомендоване обладнання.

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

КТ "Реєстрація"

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

КТ "КПП"

При прикладанні картки до карткозчитувача створюється фотографія, шлагбаум автоматично відкриється, при перетині оптопар(індукційної петлі) шлагбаум автоматично закриється. Якщо проїзд не буде зафіксовано сенсорами, шлагбаум закриється але буде дозвлено повторне прикладання картки для здійснення проїзду. Якщо система налаштована на використання службової картки для підтвердження операції проїзду, шлагбаум відкриється тільки після прикладання службової картки. На AGBTablo відображається задана логістична схема та рекомендації щодо подальшого слідування по маршруту.

КТ "Лабораторія"

При прикладанні картки до карткозчитувача створюється фотографія, на робочому місці лаборанта з'явиться вікно реєстрації документу лабораторного аналізу, по створенню документу відбувається фотофіксація. Якщо на контрольній точці задана обробка черги, на LED-табло буде відбуватись візуалізація в циклічному порядку заданої кількості перших елементів черги. Інформація на табло може включати точку вивантаження. Послідовність авто в черзі може змінюватись. На AGBTablo відображається задана логістична схема та рекомендації щодо подальшого слідування по маршруту.

КТ "Вагова"

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

КТ "Вивантаженя/Завантаження"

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

КТ "Зона очікування"

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

Тут описана стандартна поведінка. Додатковими налаштуваннями дана поведінка може бути суттєво змінена.

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

Авторизація на контрольних точках

Авторизація - це процес з'ясування відповідності між ідентифікаторами(ID картка, державний номер авто, і таке інше) та існуючим активним документом або документом що готовиться.

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

Карткова авторизація.

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

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

Карткова авторизація реалізується:

• Через стандартні зчитувачі ID карт
• Через зчитування ID картки програмою мобільного зчитувача MobiCard для Android

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

Авторизація через створення документу.

На контрольних точках, на яких відбувається створення документів - Реєстрація, Лабораторія наявність карткозчитувача не обов'язкова, але за для пришвидшення процесу проходження транспорту - бажана.

Безкарткова авторизація.

Авторизація через автоматичне розпізнавання державного номеру авто, дає змогу пришвидшити проходження логістичного правила, та скоротити час перебування транспорту на об'єкті.

Аторизація через FakeReader дає змогу запустити кілька послідовних процесів авторизації властивих контрольним точкам (зважитись на Ваговій, вивантажитись на Вивантаженні, ...) на фізично розташованому в одному місці обладнанні яке належить різним контрольним точкам. Посуті, - об'єднати різнотипні контрольні точки в одну.

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

Авторизація на контрольних точках через розпізнавання державного номеру авто

Авторизація за даним методом відбувається наступним чином:

1. По зпрацюванню сенсора-авторизатора активується процес отримання фотографій
2. По фотографії відбувається розпізнавання державного номеру авто
3. Отримавши розпізнані номери, AGB формує:
   a) подію розпізнавання для подальшого аналізу
   б) подію по карткозчитувачу для виконання алгоритмів покладених на дану контрольну точку

Авторизація по розпізнаванню доступна на всіх контрольних точках за виключенням "Реєстрації".

Налаштування

1. В довіднику Контрольних точок створити канал сенсора типу "авторизатор"
2. В довіднику Контроллерів створити карткозчитувач типу "Авторизатор по розпізнаванню"
3. В довіднику Контрольних точок створити канал карткозчитувача типу "авторизатор по розпізнаванню". До каналу обов'язкова прив'язка:
   а) хоча б однієї камери, по фотографії якої буде відбуватись розпізнавання номеру авто
   б) хоча б одного датчика типу "авторизатор", по якому перехід з нормального стану буде запускати процес розпізнавання номеру авто

Рекомендації

1. Камери, які беруть участь в розпізнаванні, необхідно розміщувати так, щоб при зпрацюванні сенсора-авторизатора ракурс фотографій був прийнятний для розпізнавання як номеру авто, так і номеру причепа. (Є можливість деталізувати область фотографії з якої номер буде вважатись розпізнаним - даний функціонал в розробці)
2. Для забезпечення проїзду без зупинки на контрольних точках які блокують проїзд(КПП), необхідно встановлювати сенсор-авторизатор на достатній відстані від блокуючого елементу(шлагбауму).
3. На двонаправлених контрольних точках сенсор-авторизатор необхідно встановлювати з обох боків проїзду. Для захисту від повторного зпрацювання другого сенсора необхідно використовувати допоміжні апаратні пристрої. (Програмна реалізація в розробці)
4. На Ваговій при роздільному зважуванні авто та причепа - система авторизації по розпізнаванню державного номеру не ефективна, бажано використовувати інші методи авторизації.
5. На всіх контрольних точках де використовується авторизація по розпізнаванню державного номеру авто, як допоміжний спосіб авторизації при неможливості розпізнавань, необхідно використовувати будь-які інші методи авторизації.

Авторизація на контрольних точках через FakeReader

FakeReader - це віртуальний карткозчитувач, він дає змогу запустити кілька послідовних процесів авторизації властивих конкретним контрольним точкам (зважитись на Ваговій, вивантажитись на Вивантаженні, ...) на фізично розташованому в одному місці обладнанні яке належить різним контрольним точкам. Посуті, - об'єднати різнотипні контрольні точки в одну. Загалом, FakeReader дозволяє організувати автоматичний прийом/відвантаження продукції при розташуванні обладнання в одному місці, але послідовно пройти та проконтролювати всі процеси, властиві окремим контрольним точкам - Реєстрація, КПП, Лабораторія, Вагова, Вивантаження/Завантаження. Це мінімізує кількість обладнання яке використовується для контролю логістичних процесів(Наприклад, достатньо одного картчозчитувача), дає змогу більш гнучко пристосуватись до існуючих технологічних процесів на підприємстві та використовувати AGBControl на "малих" об'єктах.

Принцип дії

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

• Створення будь-якого документу на будь-якій контрольній точці;
• Спрацювання карткозчитувача на будь-якій контрольній точці;
• Спрацювання сенсора на будь-якій контрольній точці.

Налаштування

1. В довіднику контроллерів, створюємо зчитувач типу FakeReader по одному для кожної необхідної контрольної точки
2. В довіднику обладнання, прив'язуємо канал FakeReader'а до необхідних контрольних точок
3. Назначаємо події, при яких відбуватиметься спрацювання FakeReader зчитувача
4. При використанні одного AGBTablo для контрольних точок з FakeReader'ом - назначаємо контрольні точки для табло

Приклад 1

Нехай, маємо об'єкт автоматизації на якому всі процеси, які підлягають контролю, відбувається в одному місці.

1. Для прибувшого на місце транспорту, нам необхідно зареєструвати накладну: - Створюємо контрольну точку "Реєстрація" та виконуємо реєстрацію накладної на АРМ реєстратора.
2. Після реєстрації, нам необхідно взяти проби та зафіксувати параметри лабораторного аналізу: - Створюємо контрольну точку Лабораторія та прив'язуємо до неї апаратний карткозчитувач по події на якому на віддаленому робочому місці оператора лабораторії з'явиться вікно для реєстрації параметрів лабораторного аналізу.
3. Після створення лабораторного аналізу нам необхідно відбрутуватись: - Створюємо КТ "Вагова" та прив'язуємо до неї FakeReader який спрацьовує при створенні лабораторного налалізу. На логістичній схемі, після створення лабораторного аналізу, транспорт переміститься на КТ "Вагова", та почнеться процес автоматичного зважування брутто який закінчиться створенням документу зважування брутто.
4. Після створення документу зважування брутто нам необхідно вивантажитись: - Створюємо КТ "Вивантаження" та прив'язуємо до неї FakeReader який спрацьовує при створенню документу зважування БРУТТО. На логістичній схемі, після прикладання картки, транспорт переміститься за КТ "Вивантаження", водію необхідно розвантажити транспорт.
5. Після розвантаження нам необхідно відтаруватись: - КТ "Вагова" вже створена, FakeReader до неї прив'язаний. Задаємо додаткову дію спрацювання FakeReader'а при спрацювані дятчика, який контролює завершення процесу розвантаження. На логістичній схемі транспорт переміститься на КТ "Вагова", та почнеться процес автоматичного зважування тари який закінчиться створенням документу зважування тари.
6. Після створення документу зважування тари нам необхідно покинути територію: - Створюємо КТ "КПП" та прив'язуємо до неї FakeReader який спрацьовує при створенні документу зважування тари. На логістичній схемі, після створення документу, транспорт переміститься на КТ "КПП", шлагбаум відкриється та після спрацювання оптопар, накладна закриється.

Приклад 2

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

Для реалізації такого алгоритму роботи нам необхідно:

1. Встановити апаратний карткозчитувач на реєстрації
2. Для всіх інших контрольних точок створити зчитувачі типу FakeReader та прив'язати іх до єдиного існуючого апаратного карткозчитувача.

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

Безконтактна, безкарткова авторизація на контрольних точках

Безконтактна, безкарткова авторизація здійснюється за допомогою додатку MobiCard який використовується в режимі додатку для водія.

Безконтактна, базкарткова авторизація дозволяє:

1. Значно пришвидшити процес проходження логістичного правила за рахунок відсутності потреби покидати кабіну авто для здійснення процесу авторизації шляхом прикладання RFID-картки до карткозчитувача;
2. Повністю виключити порушення, пов'язані з авторизацією на контрольних точках які відсутні в поточному логістичному правилі, або порушення послідовності проходження контрольних точок;
3. Керувати потребою у відмові в авторизації на поточній контрольній точці якщо на об'єкті автоматизації фізичне розташування контрольної точки потребує авторизації на ній після кількох неавторизованих переміщень.
4. Зменшити загальну вартість обладнання шляхом економії на придбанні карткозчитувачів та тачскрін дисплеїв для AGBTablo;

Налаштування

1. В довіднику контроллерів, створюємо зчитувач типу "Безконтактний, безкартковий авторизатор"
2. В довіднику обладнання, прив'язуємо канал контроллера до необхідної контрольної точки
3. При наявності на контрольній точці Raspberry, налаштувати Bluetooth raspberry на режим BLE Transmittion. Для цього, наприклад, виконати такі команди:
   
   sudo hciconfig hci0 noscan
   sudo hciconfig hci0 leadv 3
   
   При відстуності raspberry на контрольній точці, в якості передавача BLE сигналу можна використати будь-який пристрій який може періодично передавати сигнал, наприклад iBeacon.

Тривожні події

Розглянемо деякі тривожні повідомлення, які, можливо, потребують додаткових пояснень.

Тривожні події по втраті та відновленню мережевого з'єднання з обладнанням

По всіх контроллерах, в налаштуваннях яких зведений чекер "Мережеві події", буде відбуватись фіксація розриву (close socket) та відновлення (open socket) мережевого з'єднання. Це не моніторинг мережевих пристроїв по snmp, icmp чи інщим способом, це контроль стану структури даних операційної системи (сокета) на предмет закритий/відкритий.
   UCR додатково відслідковує всі контроллери які підключені безпосередньо до нього, та формує ці події для кожного з них.

Тривожні події при залипанні бінарних сенсорів по будь-якому з двох станів

Залипання - термін, який не зовсім розкриває суть явища яке контролюється бо, зазвичай, він асоціюється з якимись механічними неполадками пристрою. Ні - зовсім не так. Справність сенсору можна підтвердити тільки після проведення відповідних тестів. В нашому контексті даний термін означає знаходження бінарного(з двома станами) сенсора в тому чи іншому стані більше заданого інтервалу часу. Тому, з інтерпретацією причин винекнення даних подій треба бути обережним. Дана подія означає тільки те, що описано вище: перевищення часу знаходження сенсора в певному стані і нічого більше.

Параметри відслідковування залипання та інтервал часу для кожного зі станів задаються в атрибутах каналу контроллера.

Межі використання даного функціоналу досить широкі, якщо виключити втручання в роботу сенсорів. Наведу кілька прикладів:

1. Контроль обходу периметра охоронником. Раз на годину, охоронник повинен виконати обхід за певним маршрутом. Якщо, за 60 хвилин не було перетину оптопар, встановлених у відповідних місцях, - це може означати що обхід не виконано.
2. Контроль затримки на пропускному пункті. На КПП в певному місці встановлюється індукційний датчик. Певне незмінне значення цього сенсора на протязі певного інтервалу часу, може свідчити про затримку пропуску авто через КПП.

Черги

Черга - це властивість контрольної точки. Черги призначені для організації керованого, послідовного слідування транспорту по маршруту методом можливого впливу на поведінку на наступній(пост-черга) контрольній точці. Черга створюється атоматично, або оператором. Послідовність елементів в черзі може змінюватись оператором. Попадання/видалення елементів(під елементом розуміється ТТН) в/із черги відбувається по стандартним правилам відповідно до типу контрольної точки, або(поведінка задається при конфігурації контрольної точки) по подіях створення будь-якого документу, спрацюванню будь-якого сенсора на будь-якій контрольній точці. Видалення елементу з черги, також може відбуватись через заданий проміжок часу після занесення його в чергу. Інші механізми впливу на поведінку транспорту за допомогою черг відсутні.

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

Черга на КТ "Лабораторія"

      Стандартна поведінка черги:

Елемент заноситься в кінець черги при створенні Лабораторного аналізу. Елемент видаляється з черги при авторизації на будь-якій іншій контрольній точці.

      Задана адміністратором поведінка черги при конфігурації контрольної точки:

Елемент заноситься в кінець черги по події створення будь-якого документу, спрацюванню будь-якого сенсора на будь-якій контрольній точці. Елемент видаляється з черги по події створення будь-якого документу, спрацюванню будь-якого сенсора на будь-якій контрольній точці та/або через заданий проміжок часу після попадання елементу в чергу.

      Візуалізація черги на LED табло:

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

1. Державний номер авто
2. прийнятність лабораторного аналізу
3. номер точки вивантаження

Черга на КТ "Зона очікування"

      Стандартна поведінка черги:

З елементів, які знаходяться на даній контрольній точці, оператор створює пост-чергу за допомогою, призначеного для цього, інструментарію програми agbclient. Елемент може попадати(задається при конфігурації контрольної точки) в кінець черги автоматично по події авторизації на даній контрольній точці. Послідовність елементів в черзі оператор може змінювати. Час перебування на контрольній точці обчислюється від моменту авторизації до моменту занесення елементу в чергу. Видалення елементу з черги відбувається при авторизації на будь-якій іншій контрольній точці, якщо задано, через інтервал часу від моменту занесення в чергу, в залежності від того, що наступить раніше.

      Візуалізація черги на LED табло:

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

1. Державний номер авто
2. Мнемонім "GO"

Примітка:

На контрольних точках може бути безліч LED-табло, призначених для відображення інформації черги в той чи інший спосіб. Параметри кількості візуальних елементів черги, та пряма чи зворотня(інверсна) послідовність візуалізації - задаються для кожного LED-табло індивідуально. Інверсія послідовності візуалізації черги на табло не змінює послідовність елементів черги, а впливає тільки на спосіб візуалізації. Led-табло - це спосіб візуалізації черги, до черги як структури даних, табло не має ніякого відношення.

Налаштування:

Параметри формування черги задаються в атрибутах контрольної точки. При наданні доступу користувачеві на керування чергою, при наступному вході в програму, з'явиться кнопка управління чергами в головному меню.

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

Миттєві повідомлення

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

Миттєві повідомлення - це обєкт з коротким часом життя який може задаватись при конфігурації обладнання(LED-табло). Вони тісно пов'язані з табло, існують тільки в момент створення, та ніде не зберігаються. Повідомлення ніяким чином не пов'язані між собою. Поняття "стерти" повідомлення(для повідомлень без часу життя) не існує. Для AGB його вже немає як тільки воно було створене та відправлене на табло. Стерти повідомлення - це передача нового повідомлення з відсутньою візуальною інформацією, або при використанні параметру "час життя" - повідомлення стирається з табло автоматично через вказаний проміжок часу.

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

Стандартні дані, які відображаються на табло відповідають стандартному тексту відповідної контрольної точки.

Миттєві повідомлення на LED-табло

Мої документи

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

• Організація
• Контрагент
• Перевізник
• Замовник
• Відправник
• Водій

Даний функціонал можна використовувати наприклад, для нагляду за своїм транспортом певним перевізником.

Хоча, в загальному, встановивши певні права доступу для "користувача-перевізника", можна також завчасно створювати та редагувати документи.

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

Комунікація з обліковою системою підприємства

Облікова система підприємства може взаємодіяти з AGB отримуючи певні дані, та передаючи певні дані частково впливаючи на технологічний процес. Взаємодія відбувається по TCP, HTTP, HTTPS протоколах пакетами в json форматі.

AGB асинхронно, тобто одразу після виникнення події (без потреби в запиті), передає дані спрацювання сенсорів, подій розпізнавання, створення документів і таке інше ...

AGB повертає певні дані за запитом облікової системи. В основному це інформація довідників які представлені в AGB - камери, контрольні точки, сенсори, логістичні правила і таке інше ...

Облікова система може частково керувати технологічним процесом AGB. Керування полягає в перехопленні подій карткозчитувача, виконання певних, відкладених в часі операцій в обліковій системі підприємства (Наприклад: додаткова перевірка інформації лабораторного аналізу) та повернення перехопленої події до AGB, або відхилення її.

Детально процес взаємодії облікової системи підприємства з AGB описаний в

Протокол обміну з обліковою системою підприємства (PDF)

Контроль ваги НЕТТО

Контроль ваги НЕТТО відбувається виключно для операцій відвантаження продукції та призначений для відпуску кількості продукції заданої в накладній в полі "Контроль ваги НЕТТО". Документ зважування БРУТТО(друге зважування), буде створений тільки тоді, коли вага нетто при зважуванні буде відповідати вазі, вказаній в накладній.

Відеоспостереження

Ліва панель закладки "Відеоспостереження" містить список камер до яких надано доступ конкретному користувачеві для ведення відеоспостереження. Права панель - робоче поле, на якому розміщуються відповідні зображення з відеокамер в режимі реального часу.

Для перегляду доступне тільке online відео. Тому задача даного функціоналу - оперативно надати зображення з потрібних камер при з'ясуванні причин порушення яке відбувається в даний час.

Відеоспостереження

Трафік

Закладка "Трафік" містить поточну інфрормацію по місцезнаходженню транспорту на об'єкті. Доступні три види діаграм:

Діаграма "Поточне розміщення транспорту"

Діаграма містить кількість транспорту яке розміщене на території підприємства в розрізі контрольних точок. Ліва частина діаграми показує кількість транспорту розміщеного безпосередньо НА певній контрольній точці, права - ПІСЛЯ контрольної точки.

На діаграмі:

• Загальна кількість транспорту на підприємстві - 14. З них 1 на контрольній точці, 13 - після контрольної точки
• На КТ "Розвантаження 2" - 1
• Після КТ "Реєстрація" - 2
• Після КТ "КПП 3 Виїзд" - 1
• Після КТ "Лабораторія" - 5
• Після КТ "Вагова 1" - 2
• Після КТ "Вагова 2" - 3

Діаграма "Час на території"

Діаграма містить максимальне, мінімальне та середнє значення часу на протязі якого поточний транспорт знаходиться на території підприємства. Будь-яке суттєве відхилення від середнього значення в ту чи іншу сторону, може свідчити про проблеми при проходженні контрольних точок та потребує додаткового з'ясування причин.

На діаграммі:

• Максимальний час знаходження транспорту на території підприємства - 1 день 19:08:24
• Середній час - 12:38:09
• Мінімальний - 01:26:43

Діаграма "Переміщення транспорту за останні 24 години"

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

На діаграмі:

• Загальна кількість в'їздів - 120, виїздів - 118
• За останню годину в'їзду та виїзду транспорту не було
• За передостанню: заїхало - 3, виїхало - 2
• ...
• 23 години назад: заїхало - 5, виїхало - 6

Трафік

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

Список транспорту

AGBTablo

AGBTablo служить для оповіщення водія про стан операцій на контрольних точках та безпосередньої взаємодії з водієм. AGBTablo створюється на базі мікрокомп'ютера Raspberry Pi 4 та монітору. Якщо технологічний процес передбачає інтерактивну взаємодію з водієм, то необхідно використовувати монітор з тачскрін дисплеєм.

AGBTablo

Реєстрація AGBTablo в системі AGBControl:

1. Створити контроллер з типом контроллера табло: agbclient -> Довідники -> Контроллери
2. Прив'язати створене табло до певної Контрольної точки: agbclient -> Довідники -> Контрольні точки та пристрої

Інсталяція AGBTablo на Raspberry Pi:

1. Завантажити програму за посиланням наведеним на початку даної сторінки
2. Виконати дії подібні до інсталяції GPSMWL: Еллектронне публічне табло для GPS моніторингу публічного транспорту
3. Запустити програму agbtablorpisdl

Налаштування AGBTablo:

1. За необхідності, відредагувати текстовий файл agbtablo.cfg, розміщений в каталозі встановлення програми agbtablorpisdl, задавши ip-адресу вашого agb серверу (за замовчуванням: 192.168.1.10)

UCR -Універсальний контроллер для Raspberry

UCR призначений для взаємодії з кінцевим обладнанням (сенсори, виконуючі механізми, вагопроцесори) та підготовки і передачі інформації до AGB сервера. Також на UCR покладені задачі, які є специфічними для кінцевого обладнання та не залежать від логіки роботи AGB сервера.

UCR створений з метою уніфікації протоколу взаємодії обладнання та AGB сервера, та розвантаження AGB сервера.

Вагопроцесори:

UCR підтримує наступні типи вагопроцесорів:

1. Ваги ТВ12 серії (TW12)
2. Ваги XK3118T1
3. Ваги TWP25
4. Ваги WE2110
5. Ваги D39-WE
6. Keli D12
7. Keli D12
8. Ваги ВП2 (WP2)

Незалежно від того, з якою частотою вагопроцесори передають дані до UCR, UCR відправляє дані з частотою не більше 1 Гц. Стабільне нульове значення ваги передається раз на хвилину.

Налаштування:

1. Додати в довідник контроллерів новий контроллер, вказавши найменування, "ip адресу" UCR контроллера, "ip порт" UCR контроллера та вибравши з випадаючого списку "Тип пристрою" як "Універсальний Контроллер UCR"
2. Додати в довідник "Контрольних точок та пристроїв" канал контроллера до відповідної контрольної точки, вказавши "Найменування каналу контроллера", вибравши з випадаючого списку "Контроллер" доданий в попередньому пункті, вказавши "Канал контроллера" заданий в конфігураційному файлі ucr.cfg та означивши інші атрибути каналу контроллера які впливають на логіку роботи AGB сервера при обробці даних від каналу контроллера.

Запуск:

Проблем з запуском UCR на Raspberry не виявлено. Деякі версії можуть не знаходити libc бібліотеку. В такому випадку необхідно виконати soft link з натівної бібліотеки на файл, який необхідний для UCR. Наприклад:

При запуску UCR виявилось що неможливо знайти файл /lib/libc.so.6 . Який в поточній версії raspberry знаходиться в каталозі /usr/lib/libc.so.6 Необхідно виконати команду:

Файл конфігурації ucr.cfg:

При першому запуску ucr автоматично створює текстовий файл конфігурації ucr.cfg зі значеннями за замовчуванням та прикладами конфігурації кінцевого обладнання. Конфігурація ucr відбувається через редагування файлу ucr.cfg.

# Приклад Файлу конфігурації ucr.cfg

# порт UCR-контроллера по якому програми-клієнти отримують дані
tcpport 7363
# порт UCR-контроллера для прийому даних від обладнання яке працює в режимі клієнта
controllerport 9763
# ip адреса сервера для автоматичного оновлення версії програми
ipcheckversion 192.168.1.10

# ip:port контроллера який працює в режимі сервера
#192.168.1.10:9000 {
#  тип контроллера
#  type TW12
#  канал контроллера в просторі UCR. W - означає що даний контроллер є вагопроцесором
#  channel W1
#  команда обнулення вагів
#  tozero "S02R\r\n"
#}

#46.211.130.154 {
#  type WE2110
#  channel W2
#  network_type client
#  # команда обнулення вагів
#}

# modbus вагопроцесори
192.168.1.10:8088 {
  type modbus
  channel W1
  mb_type rtutcp
  mb_function_type D12
  mb_slave_address 1
}

UCR обробляє наступні синтаксичні конструкції задані в файлі конфігурації ucr.cfg:

• Роздільник рядків - символ нового рядка(0x0a)
• Роздільник слів - символ пробілу
• Блок - набір пар ключ-значення обрамлений парою символів {}
• Коментарі - рядки які починаються з символа #
• Рядки типу - ключ-значення
• Рядки типу - ключ-блок

Синтаксичні помилки в файлі ucr.cfg не обробляються. При існуванні помилок, поведінка ucr не визначена.

Рядки загального призначення типу - ключ-значення:

• tcpport 7363 - серверний порт UCR до якого приєднуються клієнтські програми, наприклад AGB сервер
• controllerport 9763 - серверний порт UCR до якого приєднуються контролери кінцевого обладнання які працюють в режимі клієнта. Не залежно від того, чи визначений хоча б один канал контроллера кінцевого обладнання яке працює в режимі клієнта, серверний порт завжди готовий до обслуговування мережевих запитів.
• ipcheckversion 192.168.1.10 - ip адреса сервера для автоматичного оновлення версії програми ucr. Оновлення відбувається по вже існуючому сокету ініційованого AGB сервер'ом.

Рядки типу - ключ-блок:

• 192.168.1.10:9000 {
  Рядки конфігурації кінцевого обладнання
  }
  - опис конфігурації кінцевого обладнання, яке працює в режимі сервера.
• 192.168.1.10 {
  Рядки конфігурації кінцевого обладнання
  }
  - опис конфігурації кінцевого обладнання, яке працює в режимі клієнта.

Рядки конфігурації кінцевого обладнання типу - ключ-значення:

• type TW12 - тип вагопроцесора. Доступні значення: TW12, TW25, XK3118T1, WE2110, D39-WE, або modbus - для роботи з вагопроцесорами які підтримують modbus протокол.
• channel W1 - канал UCR контроллера. Будь-яке унікальне, в межах одного ucr контроллера, найменування каналу контроллера. Для вагопроцесорів повинно починатись символом W.
• network_type client - тип мережевого з'єднання. Рядок обов'язковий тільки для клієнтського мережевого з'єднання.
• cmd-get "G01W\r\n" - команда, яка відправляється на вагопроцесор для отримання одного значення поточної ваги. Для modbus не задається.
• tozero "S02R\r\n" - команда, яка відправляється на вагопроцесор для обнулення ваги. Для modbus не задається.
• Команди формату autozero_* - Налаштування автоматичного обнулення вагів. Детально описані нижче в підрозділі Автоматичне обнулення вагів
• Команди формату mb_* - Налаштування роботи вагопроцесора який працює по modbus протоколу. Детально описані нижче в підрозділі Modbus

Команди cmd-get, tozero визначаються згідно документації вагопроцесора. Символи(один символ - один байт) команди можна задавати в вигляді ASCII коду, шістнадцяткового коду у вигляді \x0d, мнемонічного коду у вигляді \r.

Modbus

UCR може спілкуватись з вагопроцесорами які підтримують протокол modbus. Надсилаються тільки команди отримання та обнулення ваги. Обробляються modbus функції наступних вагопроцесорів:

• Keli D12

Параметри:

• type - необхідно вказати ключове слово - "modbus"
• channel - канал UCR контроллера
• mb_type - необхідно вказати ключове слово "rtutcp"
• mb_function_type - тип функцій вагопроцесора. Доступні значення: "D12".
• mb_slave_address - Адреса пристрою в просторі modbus.

Контроль з'їзду з платформи

Контроль з'їзду з платформи реалізований методом пошуку нульової ваги перед автоматичним зважуванням. Перевірці підлягяє існування попереднього з'їзду з платформи.

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

Для аналізу відповідності нульової ваги поставленій задачі аналізуються наступні параметри:

• Час останнього нуля на вагах (last_zero_clockseconds)
• Массив ідентифікаторів товаро-транспортних накладних, після last_zero_clockseconds, подій прикладання ID-картки (array_card_ttn_id)
• Ідентифікатор ТТН останньої спроби зважування після last_zero_clockseconds (last_eventweighing_ttn_id)
• Існування документу зважування після last_zero_clockseconds (isbe_docweighing)

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

Для використання алгоритму перевірки попереднього з'їзду з платформи в налаштуваннях каналу UCR контроллера для відповідного вагопроцесора необхідно:

• Включити автоприйом даних
• Включити використання алгоритму контролю з'їзду з платформи методом пошуку останньої нульової ваги

Автоматичне обнулення вагів

Дана функція доступна тільки для вагопроцесорів які мають команду обнулення вагів.

Автоматичне обнулення вагопроцесора відбувається якщо на протязі певного періоду часу кожне(∀ квантор загальності) значення ваги належить заданому інтервалу значень. Для додатніх і від'ємних значень ваги інтервал задається окремо.

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

• autozero_ison : Значення 1 - функція ввімкнена, інші значення - вимкнена
• autozero_time : Проміжок часу, заданий в секундах, на протязі якого значення вагопроцесора знаходиться в межах заданих інтервалом autozero_maxpos та autozero_minpos - для додатніх значень ваги, та autozero_maxneg і autozero_minneg - для від'ємних значень ваги.
  Значення за замовчуванням 5, дозволений інтевал 5-30.
• autozero_maxpos : Максимальне позитивне значення вагів, задане в кілограмах, за проміжок часу autozero_time.
  Значення за замовчуванням 300.
• autozero_minpos : Мінімальне позитивне значення вагів, задане в кілограмах, за проміжок часу autozero_time.
  Значення за замовчуванням 0.
• autozero_maxneg : Максимальне негативне значення вагів, задане в кілограмах, за проміжок часу autozero_time.
  Значення за замовчуванням 0.
• autozero_minneg : Мінімальне негативне значення вагів, задане в кілограмах, за проміжок часу autozero_time.
  Значення за замовчуванням -300.

Ризики:

1. Обнулення вагів повинно відбуватись при стабілізації ваги. Вагопроцесор повинен мати функцію перевірки стабільності ваги перед обнуленням.
2. Велика ймовірність того, що за час передачі команди на вагопроцесор та час прийняття рішення вагопроцесором про обнулення, значення вагів не будуть відповідати значенню на момент прийняття рішення про необхідність обнулення.
3. Обнулення вагів повинно відбуватись при пустій платформі. Встановити це методом аналізу ваги неможливо.
4. "Плавання" точки відліку може свідчити про механічну несправність вагів, що неможливо виправити обнуленням ваги.
5. До великої кількості вишуканих методів зловживань, додається ще один.
Покрокова інструкція зламу алгоритму:
• навмисно збивається вага будь-яким зі способів на час autozero_time. Відбувається автоматичне обнулення вагів.
• об'єкт зважування поміщається на платформу за час, менший autozero_time.

Функція автоматичного обнулення вагів не рекомендується до використання!
Кожне автоматичне обнулення вагів фіксується системою як порушення і потребує детального аналізу фото та відеоархівів.

Мобільний додаток MobiCard

MobiCard - це програма, яка функціонує під управлінням ОС Android та може використовуватись в двох режимах:

1. Мобільний карткозчитувач
2. Мобільний додаток Водія

В обох режимах MobiCard підтримує функціонал AGBTablo, на яке виводиться різноманітна інформація для взаємодії з користувачем. MobiCard, в даному плані, нічим не відрізняється від AGBTablo.

Режим мобільного карткозчитувача:

В режимі мобільного карткозчитувача реалізуються функції зчитування RFID карт. В якості зчитувача ID Карт, можна використовувати, наприклад зчитувачі, які підключаються через usb роз'єм безпосередньо до Android-пристрою, та передають інформацію методом емуляції подій клавіатури.

Реєстрація мобільного зчитувача в системі AGBControl:

1. Створити контроллер типу "Мобільний зчитувач" з ідентифікатором, який візуалізує програма MobiCard при старті
2. Створити канал контроллера, та привязати його до потрібної контрольної точки
3. В мобільному додатку вказати порт AGB сервера. Стандартний TCP порт сервера 7356

Алгоритми та обробка даних мобільного зчитувача нічим не відрізняється від алгоритмів стаціонарного зчитувача.

MobiCard - мобільний карткозчитувач

Для тестування програми MobiCard в режимі мобільного карткозчитувача, використовувався пристрій RFID USB reader model ST07

RFID USB карткозчитувач

Режим мобільного додатку водія:

В режимі мобільного додатку водія, MobiCard виконує наступні функції:

• Безконтактна, безкарткова авторизація на контрольних точках

Реєстрація мобільного додатку водія в системі AGBControl:

1. Прив'язати унікальний ідентифікатор програми MobiCard, встановленої на пристрій для використання водієм, до відповідного елементу довідника Водіїв.
2. В мобільному додатку вказати порт AGB сервера. Стандартний TCP порт сервера 7356

Обладнання

На додаток до вагопроцесорів, які обробляє UCR комунікація з сенсорами, виконуючими механізмами, зчитувачами відбувається за допомогою контроллерів компанії VkModule.

Download ver 8.2.0

AGB сервер (Windows x86_64)

AGB client (Windows x86_64)

AGBTablo (Raspberry Pi)

UCR контроллер (Raspberry Pi)

MobiCard - мобільний карткозчитувач, мобільний додаток водія (Android)

Протокол обміну з обліковою системою підприємства (PDF)

Download ver 7.4.0

AGB сервер (Windows x86_64)

Future - план розвитку

• Мобільний додаток водія - функції:
  • авторизатор
  • табло
  • поточна Схема проїзду
  • створення накладної по шаблону. Заявка на заїзд
  • прийом повідомлень з agbclient
• Статистика - формування будь-яких статистичних матеріалів (графіки, схеми, діаграми, текстові документи) на основі, заданих користувачем, вхідних даних.
• Динамічні закладки в списку ТТН. Посуті, на закладках які інтерактивно створює користувач, отримуємо список ТТН з різними колонками, пошуковими запитами і таке інше
• Текстове Медіавікно яке динамічно відображає на Схемі останні події по ТТН
• Розкриття дерева в списку ТТН яке показує список подій, порушень, і таке інше. Можливо і Схему, можливо і ТТН в вигляді документу
• Історія зміни накладної
• Контроль перебування транспорту на Контрольних точках через задання геозон
• Карта-Схема. Проекція, згідно географічних координат контрольних точок, логістичної схеми на географічну карту з GPS позиціонуванням транспорту
• Відеоспостереження за рухомим об'єктом. Позиціонування ракурсу PTZ,Zoom камер на конкретне авто по його географічних координатах. Позиціонування виконується при потребі, при порушенні, тощо.
• AGBClient для андроід планшетів