Начнём с железа
Работал я как-то на одном заводе, где лепили всякую электронику, не шибко сложную, и иногда подпадавшую под определение «Интернет вещей». По большей части, всякие датчики для охранных систем: датчики дыма, шума, проникновения, огня и всякое другое. Ассортимент изделий был широчайший, партии иногда были меньше 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, который бежит на станции, к которой физически подключены наши устройства. Agent писался на Python, поэтому работает без проблем на Windows, Linux, и спокойно можно допилить для использования и на RaspberryPi и подобных ему устройствах. Программка в высшей степени нетребовательна к ресурсам, и очень стабильна. Agent постоянно связан через Websocket с сервером (back end), и все настройки портов и их параметры получает оттуда, как при инициализации, так и при обновлениях. У Agent'а есть свой GUI для настроек и мониторинга в случае чего (может, связь оборвалась, может, лицензия просроченная).
Далее. Server (он же back end) поднимается из докера (а потому элементарно запускается не только в amazon или Google Cloud, но и на любой не особо мощной машинке в локальной сети с Linux на борту). Написан на Django в связке с Redis (для поддержки websocket'ов). Он хранит все настройки, и обеспечивает связь между пользовательским GUI (просто страница, написанная на ReactJS) и через Agent — с нашими девайсами. Связь двусторонняя, полностью асинхронная. Все настройки хранятся в Postgres и Mongo.
Ну, и, пожалуй, самая главная часть системы — сам клиент (попросту, страничка в браузере, для пущей динамичности писаная на ReactJS).
Да, визуальный дизайн далёк от совершенства, но это дело поправимое.
Что ж, на этом можно закруглиться, добавлю лишь пару слов о состоянии проекта и о демо.
- Это довольно-таки ранняя альфа, призванная, скорее, продемонстрировать потенциальные удобства и проверить уровень интереса.
- Поиграть с демо — сюда
Для входа в систему
username: operator_0
password: 123456789
Выбираем QA_Test и любой station (это просто попытка симуляции структуры предприятия — порты подключаются к станциям, те делятся на отделы, и у каждой конторы своя структура)
В принципе, если будет интерес, добавлю поддержку https, и сделаю сборки Agent`а под разные платформы, а так же допилю все остальные фичи.
Буду рад любым отзывам и пожеланиям. Критика приветствуется!
