AGBControl - система контролю транспорту на підприємстві

AGBTablo - інтерактивне табло

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

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

Логістика на елеваторах

Єдина країна

AGBControl - система контролю транспорту на підприємстві

AGBControl - система контролю транспорту на підприємстві


AGBControl призначенняПризначення

Комплекс програм AGBControl допомагає відстежувати переміщення транспорту на підприємстві (елеватор, нафтобаза, ЗД станція, ...) згідно заданих траєкторій руху (логістичних правил) та відслідковувати порушення технологічного процесу на контрольних точках (КПП, Місце реєстрації, Вагова, Пункт завантаження/вивантаження, Лабораторія, Зона Очікування, ...).

AGBControl сутністьВідеоматеріали:


AGBControl сутністьЗміст:

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

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

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

  18. Download

  19. Future

  20. Changelog

AGBControl сутністьСутність

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AGBControl перше знайомствоПерше знайомство

Перед використанням програми необхідно описати контроллери з якими буде взаємодіяти AGB сервер. Сервер підтримує два типи контроллерів: NetPing та VKModule. Кожен контроллер керується власним драйвером, тому задача обробки даних від нового типу контроллера значно спрощується бо інтеграція відбувається без втручання в логіку роботи серверу.

Контроллери

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

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

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

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

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

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

Товаро-транспортні накладні з даними первинних документів, відмітками про правильність виконання технологічного процесу, повідомленнями про порушення доступні для перегляду на закладці ТТН програми AGB клієнт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автоматичне оновлення програм відбувається в фоновому режимі. Архіви для оновлення зкачуються з сайту. Перевірка нових версій програм відбувається кожні 24 години від моменту запуску програми agbserver. Оновленню підлягають наступні програми:

  • agbserver
  • agbclient
  • agbtablo
  • ucr
  • MobiCard

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

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

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

Файл .bashrc

startx

Файл .xinitrc

cd agbtablo
./agbtablorpi &
xterm -geometry 0x0+0+0

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

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

AGBTablo, AGBControlAGBTablo

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)

AGBControl, UCR -Універсальний контроллер для RaspberryUCR -Універсальний контроллер для 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 Необхідно виконати команду:

# ln -s /usr/lib/libc.so.6 /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, які зведені до варіанту, представленого в таблиці:

Таблиця станів
N Час останнього нуля
last_zero_clockseconds
Масив останніх подій на карткозчитувачі
параметр: array_card_ttn_id
Остання спроба зважування
параметр: last_eventweighing_ttn_id
Існування документу зважування isbe_docweighing Результат
1 NOT EXISTS ANY ANY ANY ERR
2 last_zero_clockseconds > 0 NOT EXISTS ANY ANY ERR
3 last_zero_clockseconds > 0 array_card_ttn_id is null ANY ANY ERR
4 last_zero_clockseconds > 0 array_card_ttn_id = ttn_id NOT EXISTS NOT EXISTS OK
5 last_zero_clockseconds > 0 array_card_ttn_id = ttn_id last_eventweighing_ttn_id = ttn_id NOT EXISTS OK
6 last_zero_clockseconds > 0 array_card_ttn_id = ttn_id last_eventweighing_ttn_id != ttn_id ANY ERR
7 last_zero_clockseconds > 0 існує( квантор існування) array_card_ttn_id != ttn_id ANY ANY ERR
Де:
NOT EXISTS - не існує
ANY - будь який
ERR - стан не відповідає вимогам, автоматичне зважування не виконується
ttn_id - ідентифікатор поточної накладної
OK - стан прийнятний, виконується автоматичне зважування

Для використання алгоритму перевірки попереднього з'їзду з платформи в налаштуваннях каналу 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. До великої кількості вишуканих методів зловживань, додається ще один.
  6. Покрокова інструкція зламу алгоритму:
    • навмисно збивається вага будь-яким зі способів на час autozero_time. Відбувається автоматичне обнулення вагів.
    • об'єкт зважування поміщається на платформу за час, менший autozero_time.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

AGBControl - FakeReaderАвторизація на контрольних точках через 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 та прив'язати іх до єдиного існуючого апаратного карткозчитувача.

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


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

Безконтактна, безкарткова авторизація здійснюється за допомогою додатку 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.

MobiCard - мобільний додатокМобільний додаток 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AGBControl ЧергиЧерги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примітка:

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


Політика конфеденційності

Ця політика стосуються всіх програм які входять до складу програмного комплексу AGBControl. Запуск програм означає що ви ознайомлені та приймаєте дану політику.

  1. Програми самовільно нікуди не передають ніяких даних. Програма agbserver при запуску, та раз на добу після запуску, отримує та перевіряє дозвіл на запуск та подальше функціонування з сервера аутентифікаціі з самопідписаним сертифікатом, розміщеного в інтернет.
  2. Всі паролі зберігаються в зашифрованому вигляді та невідомі розробнику.
  3. Ця Політика може змінюватись без будь-якого попередження користувачів програм.

Рекомендації що до використання

Ці рекомендації стосуються програм які входять до складу програмного комплексу AGBControl. Запуск програм означає що ви приймаєте та виконуєте дані рекомендації.

  1. Рекомендації є невід'ємною частиною "Умов використання"
  2. Система AGBControl повинна експлуатуватсь в режимі, який унеможливить негативний вплив на технологічні процеси, або такий вплив є прийнятним. На об'єкті, де експлуатується AGBControl, повинні бути прийняті додаткові необхідні та достатні адміністративні, організаційні, технічні, програмні та інші заходи, які забезпечать повне функціонування технологічного процесу при неможливості експлуатації AGBControl.
  3. Оновлення апаратного забезпечення (відеокарти, мережевих карт, і таке інше), будь-якої складової системного програмного забезпечення, операційної системи на якій встановлено програму agbserver, методу запуску програми agbserver може призвести до зміни ключа дозволу на запуск AGB сервера. Рекомендується узгоджувати такі дії з розробником для оперативної видачі нового ключа запуску. Без узгодження, термін видачі ключа не визначений.
  4. Розміщувати базу даних сервера на високошвидкісних SSD дисках.
  5. Не використовувати програми без автоматичного оновлення версій.
  6. Ці Рекомендації можуть змінюватись без будь-якого попередження користувачів програм.

Умови використання

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

  1. Програми пропонуються до використання по принципу "AS IS"(як є). Програми безкоштовні та доступні для завантаження з сайту розробника. Дозвіл на запуск програм надає розробник методом видачі строкового ключа дозволу. Використання програм без надання дозволу розробником заборонено. Ви користуєтесь чи не користуєтесь програмами за власним бажанням.
  2. Строк використання програм обмежений кінцевою датою підписки. Перша дата закінчення підписки визначається з моменту видачі строкового ключа дозволу та діє до 28 числа першого повного місяця від дати видачі ключа. Надалі, підписка може подовжуватись до 28 числа наступного місяця.
  3. При не виконанні "Рекомендацій що до використання" адекватність роботи закладеного функціоналу відсутня.
  4. Розробник не гарантує абсолютну безперебійність або безпомилковість роботи програм. Але докладає всі розумні зусилля і заходи з метою недопущення цього.
  5. Розробник не несе ніякої відповідальності за прямий або непрямий збиток, побічно або безпосередньо нанесений кому-небудь при використанні, відмові від використання або неможливості використання програм.
  6. Ці Умови можуть змінюватись без будь-якого попередження користувачів програм.

Обладнання

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

Download ver 8.0.0

AGBControl server для Windows 64AGB сервер (Windows x86_64)
AGBControl client для Windows 64AGB client (Windows x86_64)
AGBTabloAGBTablo (Raspberry Pi)

Future

  1. Мобільний додаток водія (≈ 4 місяці) - функції:
    • авторизатор
    • табло
    • поточна Схема проїзду
    • створення накладної по шаблону. Заявка на заїзд
    • прийом повідомлень з agbclient
  • Динамічні закладки в списку ТТН. Посуті, на закладках які інтерактивно створює користувач, отримуємо список ТТН з різними колонками, пошуковими запитами і таке інше
  • Текстове Медіавікно яке динамічно відображає на Схемі останні події по ТТН
  • Розкриття дерева в списку ТТН яке показує список подій, порушень, і таке інше. Можливо і Схему, можливо і ТТН в вигляді документу
  • Історія зміни накладної
  • Відеопрогравач на базі бібліотеки vlc
  • Контроль перебування транспорту на Контрольних точках через задання геозон
  • Карта-Схема. Проекція, згідно географічних координат контрольних точок, логістичної схеми на географічну карту з GPS позиціонуванням транспорту
  • Закладка Трафік. Сукупне відображення на Схемі кількості транспорту на об'єкті
  • Відеоспостереження за рухомим об'єктом. Позиціонування ракурсу PTZ,Zoom камер на конкретне авто по його географічних координатах. Позиціонування виконується при потребі, при порушенні, тощо.
  • AGBClient для андроід планшетів
  ChangeLog
GPSMWL - GPS моніторинг для соціальних проектів
GPSMTA - GPS трекер / GPS моніторинг для Android
GPSMC - GPS моніторинг для ПК
GPSM - програмно-апаратний комплекс GPS моніторингу
MapTour - GPS навігація для Туристів
MapSurfing - перегляд географічних карт
DGraf - візуалізація графів
ViCer - домашня система видеоспостереження
FPS - безкоштовна система GPS моніторингу
AGBControl - система контролю транспорту на підприємстві
Jeans - Фінансово-складський облік
Cerber - Фінансовий облік ігорного залу
Visimap - Візуальна карта
BIB - Картотека книг
2DO - Облік робочого часу
Виписка - склад
Розрахунок зарплати
Krp - візуализатор зв'язаних структур
Xboat - проектувальник маломірних суден
XSQLite - visualisator DB SQLite
Текстовий редактор XEdJ
Copyright ©