Хабрахабр

[Из песочницы] Удалённое управление UART’ом через Web

Начнём с железа

image Работал я как-то на одном заводе, где лепили всякую электронику, не шибко сложную, и иногда подпадавшую под определение «Интернет вещей». По большей части, всякие датчики для охранных систем: датчики дыма, шума, проникновения, огня и всякое другое. Ассортимент изделий был широчайший, партии иногда были меньше 500 штук, и едва ли не под каждое изделие приходилось делать отдельный Test Fixture — по сути, просто жестяная коробка, в которую изделие на тестах ставилось, прижималось крышкой, и снизу контактные иглы прижимались к контактным точкам на печатной плате, как-то так:
Таким образом можно было физически общаться с устройством. Протокол связи у нас был довольно обычный в индустрии — RS232 (COM-port, разновидность UART). В коробку ставились так же всякие несложные контролируемые устройства для тестирования конечного продукта. Все эти вспомогательные контрольно-измерительные устр-ва управлялись тем же способом. Вся конструкция была весьма хлипкая, и разного рода неполадки были частью каждодневной рутины.

Но тестировать надо было постоянно, и если где-то начинали «сыпаться» тесты — одному из инженеров приходилось топать на линию, и начинать проверять всё вручную. Спектр неполадок был весьма широк — плохие контакты, перепутали полярность при монтаже, проблемы с тестируемым изделием, с контрольно-измерительными устройствами, с контактными иглами, с кодом теста… да мало ли с чем!

И вот тут-то мы и приближаемся к сути дела. Первым делом, запускался Docklight — неплохая утилита для «общения» через COM-порты, но имевшая море ограничений.

Чем меня не устраивал Docklight?

Что ж, поехали.

  • Первая проблема — Docklight бежит только под Windows. А значит, об установке «нервного центра» в виде RaspberryPi, к которому подключались бы все устройства, или чего-то подобного, можно было забыть. Приходилось ставить NUC — самое дешёвое решение в данной ситуации. Тяжёлое, довольно крупное, и не самое дешёвое. Кстати, когда эти Test Fixtures с места на место таскали, NUC'и бились весьма и весьма (хотя и признаю, что конструкция у них вполне себе крепкая).
  • Второе — удалённый доступ мог осуществляться только через Desktop sharing — тормознуто даже через локальную сеть, а уж через Инет так и вовсе хромало.
  • Третье — у каждого устр-ва был свой набор команд, и Docklight мог загрузить файл со списком команд. Если же, скажем, надо было поделиться с кем-то в отделе подобным списком — то либо слать мейл с файлом, либо… слать линк на файл в расшаренной папке! Естественно, каждая установка Docklight требовала подобных файлов локально, и всё это приходилось проделывать десятки (если не сотни раз) вручную — для каждого NUC каждый инженер тащил свои любимые и удобные списки команд. А на дворе 2019, позволю себе напомнить…
  • Четвёртое — Docklight не позволяет автоматически связывать COM-порт с именем устройства: скажем, Windows при подключении Power Supply будет общаться с девайсом через COM12. Если вы хотите вручную «подёргать за ниточки», то в Docklight вам надо открыть COM12. Откуда можно узнать, что речь идёт именно о Power Supply, а не, скажем, о SwitchBoard? Ну, можно каждый раз заглядывать в device manager, и стараться не забывать, какое устройство с каким портом связано. При этом, никто не гарантирует, что если вы элементарно выдернете устройство, а потом снова воткнёте его, то прежний порт сохранится за этим устройством. Короче, каждый раз надо делать это вручную. И поверьте, к концу дня голова шла кругом от этого.
  • Пятое — для каждого порта нужен был отдельный экземпляр программки, и, естественно, все операции приходилось проделывать для каждого устройства индивидуально, и, хоть Docklight и поддерживает написание скриптов, взаимодействие между отдельными экземплярами не существует.

    Никакой интеграции ни с каким другим продуктом не предусматривалось. Далее. Первым делом, надо подключиться к устройствам, и посмотреть, не сдохли ли они вообще. Вроде бы, мелочь, а вот вам ситуация, когда это доводило до белого каления: тест упал, и надо разобраться, из-за чего. Проклятье! Идём в device manager, смотрим, на каком порте сидит наше устройство, открываем Docklight, инициируем связь с нашим портом… Ошибка. Эксклюзив, понимаешь. Забыл остановить сервис, который установлен на NUC, и держит все порты. Снова запускаем тест, снова падает… Ах, ты ж, блин, забыл закрыть Docklight и перезапустить сервис. Ладно, тормозим сервис, открываем порт, грузим файл с командами девайса, шлём команды, получаем (или не получаем) ответы, решаем проблему. Но это на ближайших пару часов, пока снова что-то не заглючит. Всё, вроде, ошибок нет. И поверьте, решать подобные проблемы приходилось чаще, чем того хотелось бы.

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

Что ж, решился я сделать нечто своё, но исправив (или улучшив) ситуацию с описанными проблемами.
Получилось нечто вроде Zabbix, но с заточкой под конкретную ситуацию.

Итак, в чём отличие?

Пожалуй, имеет смысл начать с общего описания архитектуры, а потом вдаваться в детали.

Схема выглядит так:

Agent писался на Python, поэтому работает без проблем на Windows, Linux, и спокойно можно допилить для использования и на RaspberryPi и подобных ему устройствах. Имеем Agent, который бежит на станции, к которой физически подключены наши устройства. Agent постоянно связан через Websocket с сервером (back end), и все настройки портов и их параметры получает оттуда, как при инициализации, так и при обновлениях. Программка в высшей степени нетребовательна к ресурсам, и очень стабильна. У Agent'а есть свой GUI для настроек и мониторинга в случае чего (может, связь оборвалась, может, лицензия просроченная).

Server (он же back end) поднимается из докера (а потому элементарно запускается не только в amazon или Google Cloud, но и на любой не особо мощной машинке в локальной сети с Linux на борту). Далее. Он хранит все настройки, и обеспечивает связь между пользовательским GUI (просто страница, написанная на ReactJS) и через Agent — с нашими девайсами. Написан на Django в связке с Redis (для поддержки websocket'ов). Все настройки хранятся в Postgres и Mongo. Связь двусторонняя, полностью асинхронная.

Ну, и, пожалуй, самая главная часть системы — сам клиент (попросту, страничка в браузере, для пущей динамичности писаная на ReactJS).

Да, визуальный дизайн далёк от совершенства, но это дело поправимое.

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

  1. Это довольно-таки ранняя альфа, призванная, скорее, продемонстрировать потенциальные удобства и проверить уровень интереса.
  2. Поиграть с демо — сюда
    Для входа в систему
    username: operator_0
    password: 123456789
    Выбираем QA_Test и любой station (это просто попытка симуляции структуры предприятия — порты подключаются к станциям, те делятся на отделы, и у каждой конторы своя структура)

В принципе, если будет интерес, добавлю поддержку https, и сделаю сборки Agent`а под разные платформы, а так же допилю все остальные фичи.

Критика приветствуется! Буду рад любым отзывам и пожеланиям.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть