Начнём с железа
Работал я как-то на одном заводе, где лепили всякую электронику, не шибко сложную, и иногда подпадавшую под определение «Интернет вещей». По большей части, всякие датчики для охранных систем: датчики дыма, шума, проникновения, огня и всякое другое. Ассортимент изделий был широчайший, партии иногда были меньше 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`а под разные платформы, а так же допилю все остальные фичи.
Буду рад любым отзывам и пожеланиям. Критика приветствуется!
Комментарии (29)
safari2012
15.02.2019 18:29Честно говоря, из статьи не совсем понятно, какую именно проблему решал автор. Что не так с многочисленными usb-uart девайсами, которые на али стоят меньше 100р./штуку и которые можно прицепить хоть сотню к одному ПК?
Если точки мониторинга/управления разбросаны на большие расстояния, можно использовать решение типа TCP2UART bridge + tibbo.
AllexIn
15.02.2019 23:13Та хоспади, NodeMCU и всего делов. TCP/IP поддерживает, WiFi есть, UART есть, стоит три копейки, программируется скриптами за пол часа.
efi Автор
15.02.2019 23:50+1Может, я выразился несколько смазанно.
Типичная ситуация: к одному компу, ассоциированному (физически и логически) с конкретным Test Fixture, присоединены несколько устр-в (в т.ч. и тестируемое устр-во, DUT — device under test). Скажем, одно из вспомогательных устройств — просто генератор RF. Шлём ему команду «излучи чего-то там на 835 МГц». Он отвечает «ОК». При этом я хочу одновременно видеть реакцию моего DUT, что он действительно принял этот сигнал. И желательно, чтобы мне не приходилось каждый раз определять, на каком порту сидит мой генератор, а на каком — DUT. Система должна сама об этом позаботиться. И автоматически загрузить список команд для каждого типа устройства. И желательно, чтобы всё это интегрировалось в общую систему тестирования, интерфейс которой оформлен через Web. Ну, и там ещё всякие мелочи.
Просто честно: удобство и эргономика в производстве очень часто имеет свой денежный эквивалент. Удобный стул для пайщицы или качественный монитор для программера — это не роскошь, а средство увеличения эффективности труда. Где-то подобными соображениями я и руководствовалсяlolikandr
16.02.2019 10:02А можете рассказать, каким образом определяется тип устройства и номер среди однотипных? Мне кажется это не тривиальным, особенно если учесть свойство Windows по разному нумеровать новые COM порты.
efi Автор
16.02.2019 10:20Если честно, на всех подобных устройствах был распаян, если я не ошибаюсь, cp2102 USB UART adapter, и в него можно было с помощью фирменной утилитки прошить имя устройства (любую произвольную строку). Я в меньшей степени электронщик, я больше программированием занимаюсь. Так вот, под python есть библиотечка infini что-то там, позволяет читать registry в windows, оттуда и сопоставляем имя порта (скажем, COM13), и название устройства (например, PowerSupply1). А в Linux и того проще, там в б-ке pyserial есть метод get_usb_description. И это было супер удобно
Serge78rus
16.02.2019 11:49С Linux все еще проще: т.к. каждый cp2102 имеет свой уникальный серийный номер, то с помощью правил в /etc/udev/rules.d Вы можете ему присвоить любое удобное Вам имя в системе. Это имя будет жестко привязано к конкретному устройству по его серийному номеру вне зависимости от порядка подключения и тд. Кстати, если верить документации silabs, Device Serial Number Вы можете перепрошить так же, как и Product Description String.
efi Автор
16.02.2019 20:03Верно, и именно этим я воспользовался для того, чтобы автоматически загрузить в интерфейс список предопределённых команд, и связать это устройство с его индивидуальным блоком в интерфейсе. К тому же, у каждого пользователя могут быть свои предпочтения в списке команд, и этим легко управлять — при логине загружается список команд именно того устройства, которое пользователь определил.
Так же легко потом делать шейринг таким спискам.
Там есть возможность записи последовательностей команд (наподобие записи макросов, как были в Visual Studio или в Selenium IDE), их прогонки и пр.
Одним из преимуществ подобной системы (именно для производства) в том, что в неё можно добавить любые фичи «на месте», особенно если они требуются для комнадной работы: скажем, пересылать новичку списки команд в зазипованном файле по мейлу, которые ему потом надо будет импортировать в тот же Docklight или подобные утилиты — не совсем удобно.
Я там планировал добавить возможность логирования всего трафика, бегущего через порты, для последующего анализа. Опять же, в условиях производства, где работают тысячи устройств одновременно, можно начинать обрабатывать подобные массивы данных для поиска всяких проблем. Но и для рядового пользователя/инженера/тестера это просто удобный инструмент для отладки COM-порта на самом «низком» уровне
IgorPie
15.02.2019 23:09+3Слишком сложно. Ну, или я не понял задачу.
Железо вроде moxa запросто туннелирует rs232/422/485 в ethernet.
Если надо буферизовать, можно хоть на raspberry.
efi Автор
15.02.2019 23:52Всё верно, но нам была необходима именно удобная для не-специалиста, не-разработчика, система, с простым и удобным интерфейсом. Вы правы, она несколько громоздка, но глядя назад, я очень хорошо понимаю, что лишнего в ней нет.
haaji
16.02.2019 01:59+1я правильно понимаю, что postgres, mongo db и redis живут в сервисе, у которого 0 rps и пара сущностей в модельках?)
efi Автор
16.02.2019 02:10Правильно :) Ведь это всего-лишь демо.
Правда, моделей пока что ок. 20-ти, и, опять же, был бы рад идеям (ну, или назовём это feature-request).
Кстати, попользуйтесь, может, увидите в этом некое удобство, заодно и сможете подкинуть пару идей ;)
Опять же, будет интерес у публики — допилю, доведу до ума хотя бы внешний вид
ittakir
16.02.2019 08:46Вместо Raspberry Pi pf за такие же деньги можно купить б.у. ноутбук. Но это будет полноценное устройство с клавиатурой, экраном, неумирающим от частой записи HDD и любой полноценной ОС. Да, вместо 2Вт он будет потреблять 10-15, но часто это не критично.
efi Автор
16.02.2019 10:12В подобной конфигурации ноутбук неудобен и громоздок. Нет нужды в клавиатуре и экране. Там нужен просто несложный компьютер, к которому через USB подключаются все наши устройства, а через сеть с этим компом можно ими управлять. Raspberry там был бы идеален, но начальник побаивался переводить всю инфраструктуру на Linux
Serge78rus
16.02.2019 11:59А чего именно в Linux так побаивается Ваш начальник?
ntfs1984
16.02.2019 16:07+1Когда я был начальником, пусть и не большим, меня в Линуксе побаивало одно — незаменяемость ответственного специалиста.
Я не рискнул переводить инфраструктуру на Линуксы потому что понимал что если текущий специалист уйдет, то шансы найти нового который поймет что наворотил предыдущий — либо очень малы либо очень дороги.
Техническому специалисту с техническим складом ума, весьма трудно понять неспециалиста с нетехническим складом ума. Сейчас мы с вами в рассуждениях можем исходить из наших собственных знаний о предмете на данный момент времени, общий смысл которых будет — «ничего сложного», но когда человек (начальник) — неспециалист, для него это все выглядит как кабина автомобиля, и если Windows напоминает кабину автомобиля с рулем и тремя педалями и если он даже не водил раньше, то наверняка видел в фильмах и за день разберется, а вот Linux для него — самолетный штурвал с кучей рычагов и кнопок где без четких знаний и пониманий делать нечего.
efi Автор
16.02.2019 19:46Как и на любом производстве, особенно если речь идёт о сравнительно небольшой компании, всегда очень остро стоит проблема непрерывности процесса. Т.е., взять тройку ребят и посадить их за долгосрочную разработку — это значит, их надо отрвать от сиюминутных насущных проблем производства (повторюсьм завод не очень большой, ресурсы несколько ограничены, людей взять неоткуда). Кстати, переход на Python, а не, скажем, LabView, позволил подготовиться к движению в любом направлении (Python-аппликации во многих случаях очень легко переводятся с одной платформы на другую).
Скажем, одной из таких проблем была необходимость гарантировать рабочие драйвера для всего зоопарка устройств, с которыми работали. Проблемы легаси, отсутствие унификации многих схем и процессов создавали серьёзные препятствия для быстрой и безболезненной миграции с одной схемы на другую
ntfs1984
16.02.2019 15:49У Raspberry преимуществ намного больше чем у ноутбука.
— Размеры-компактность-удобство монтирования;
— Потребляемая мощность;
— 5-ти вольтовое питание, к тому же USB-совместимое, позволяющее питать ее от любого адаптера, включая зарядки от мобильников, блоки питания ATX, а это упрощает централизованное резервное питание без стопки преобразователей (кому интересно — могу рассказать подробнее). 19.5в это non vagina non reda cogorta;
— GPIO, на которые можно подвесить разные интересные штучки, например ресет по отсутствию сигнала от ватчдога;
— Включение сразу при подаче питания (в БИОС десктопов такая фича есть пусть и криво реализованная, в БИОС ноутбуков нету).
И таки нет, потребление 10-15 ватт вместо 2 чаще всего критично, как по нагреву (например если девайсу судьба работать в электрическом боксе), так и по нюансам питания как я говорил выше. Чтобы выдать эти ватты нужно либо повышать сечение проводника, либо увеличивать напряжение, что в конечном итоге находит себя в нестандартном питании 19.5 в. Ну а чем нестандартнее и сложнее система — тем больше понадобится времени для восстановления в случае вылета какого-нибудь компонента.ittakir
16.02.2019 17:30+1-Raspberry это headless режим. Да, можно подключить экран, но это совсем другие размеры и деньги. И все равно нет ни мыши ни клавиатуры.
-На ноутбук я могу поставить Windows и просто скопировать туда тонну готовых программ. Например, для настройки одного устройства я написал конфигуратор на Qt под Windows. Даже не представляю, насколько будет трудно собрать его под Raspberry.
Понятно, что для какого нибудь законченного устройства, например, вендинговый автомат, то лучше использовать Raspberry или MiniITX плату. Но если вы хотите сделать систему домашнего видеонаблюдения, то сойдет и ноутбук, закинутый в кладовку.
eugenk
16.02.2019 17:59Прошу прощения, а зачем к Raspberry вообще что-то подключать? Она прекрасно видится через вайфай. Никаких проводов. Просто сидите за своим компом и рулите ей. Чем не вариант?
ntfs1984
16.02.2019 20:01Ну тут уж либо шашечки либо ехать. К Малине кстати можно подключать мониторы, начиная от обычных, заканчивая специализированными под Малинку (у меня есть такой) или даже автомобильный телевизор за 20 баксов.
Тут финт в том, что клавиатура и мышка вам понадобятся на этапе настройки (а это 0.5% времени жизни девайся), но в случае с ноутбуком их не получится отключить.
Кстати в системе именно домашнего видеонаблюдения, ноутбук это сплошное зло, это я вам по своему опыту могу сказать. Избыточен. Некомпактен. Не экономичен. Не включается при возобновлении подачи питания. И не долговечен если 24\7. Но к этому приходишь потом, когда за две недели отдыха в какой-нибудь Турции не можешь подключиться к домашней системе потому что «ололо мы обновились, теперь у вас новый Windows, нажмите F1 для продолжения загрузки» и здесь вопрос не в отключении апдейтов, а в том что система себя ведет непредсказуемо с разной степенью фатальности. Хотя это скорее вопрос Windows vs Linux.ittakir
16.02.2019 22:50Включение при подаче питания можно сделать щелкая контакты кнопки с помощью ардуины. Возможно даже сработает большой электролит параллельно кнопке.
Обычно сервера для наблюдения, хостинга и т.п. делаются под Linux Server, там проблемы с обновлениями нет.
Откуда взялось «не долговечен если 24\7»? У меня ноут годами работает как роутер и сервер. Только пыль иногда продуваю, потому что в комнате пыли много.
eugenk
16.02.2019 17:54Прошу прощения, возможно не догоняю, но мне не совсем понятно, с чем вообще была связана проблема послать и принять что-то по UART? С СОМ-портами работать весьма просто, что с виртуальными через мост usb-uart, что с реальными на древних компах. Зачем Вам потребовалась какая-то специальная программа типа Docklight, как-то осталось не очень понятным. Я сам сейчас делаю похожий проект. Нужно испытывать различную электронику при высоких температурах (желательно 160 градусов, но хорошо если будет работать и при 130). Контроллер управляет бытовой электрической печкой (купил в Ашане), устанавливает напряжение питания испытуемого устройства от 2 до 5 вольт, с измерением тока потребления и защитой, подаёт два испытательных аналоговых сигнала и вяжется с устройством по uart. Сделал всё на одном esp32 DevKit v.1 плюс небольшой кучке рассыпухи (тиристоры, операционники и т.п.). Рулится всё тоже через веб-страничку. На компе запускается небольшой серверок написанный на яве (я питон не очень люблю) через него работает страничка в броузере плюс он же вяжется с esp32 по вайфаю. Дико удобно. Печка может стоять в любом месте лаборатории не загромождая стол.
efi Автор
16.02.2019 19:40Да, конечно, я не спорю, что для отдельного разработчика вполне сойдёт и терминал — кому что удобнее. Но когда речь идёт о производственной линии, возникает необходимость в удобной графической оболочке, с централизованным и унифицированным доступом и возможностью заточить любую функцию под цех/линию/компанию. Особенно, в случае, если часто возникает необходимость в частом ручном повторении рутинных операций, которые так и «напрашиваются» на автоматизацию.
efi Автор
16.02.2019 20:16Многие недоумевают, почему и зачем это делалось. Повторюсь, кроме желания поиграться и покодить, подобная система особенно удобна в производственных условиях, где часто возникают неполадки и необходимо вручную пощупать устройства. Довольно расточительно тратить время на повторяющиеся операции, типа сопоставления имён устройств и соотв. им системных портов. Или ручных загрузок файлов со списками команд для каждого устройства. Если речь идёт об одном компьютере, который стоит у вас на столе, к которому подключены максимум с десяток таких устройств, и ты легко держишь в уме их всех, то да — моя система лишь даёт небольшие преимущества при удалённой работе и возможности запускать Agent хоть на Raspberry, хоть на Windows. Но когда речь заходит о сотне-другой подобных тестовых стендов (стенд — имеется в виду Test Fixture и его индивидуальном компьютере), а на каждом стенде по 5-10 устройств, то при всём желании, запомнить все порты и ассоциированные с ними устройства с их спецификой — это уже слишком. Вот я и строю нечто, что позволит минимизировать подобные неэффективности и даст возможность вносить изменения любому пользователю системы на свой вкус
lingvo
Опишите лучше, как вы Test Fixture делаете и тесты к ним. Про вспомогательное оборудование тоже интересно почитать.
efi Автор
С радостью.
Сами коробки на заводе не делались — они заказывались у сторонних производителей (тот же Ingun).
Вспомогательное оборудование — речь обо всяких программируемых источниках питания (небольшие одноплатные устр-ва с переходником usb-uart), платы с реле (switchboard), всякие штуковины для работы с радиосигналами (анализаторы спектра, снифферы и пр.) Все устр-ва, как я писал, имели стандартный интерфейс — COM-port, и было решено писать весь софт на Python. Удобства более чем очевидны, для понимания работы самих устройств знать не надо было практически ничего, был список команд, которые каждое устр-во понимает, через pyserial отправлялась команда, параллельно вычитывалась реакция устр-ва.
Далее ход тестов, составленный отделом разработки, реализовывался всё на том же Python, а интерфейс к самой коробке был реализован как небольшой web-server, у которого был GUI для оператора, и API для центральной системы, которая все эти тесты гоняла. В итоге получалась очень гибкая, удобная и легко масштабируемая система. Но, как я и сказал, для ручной отладки и оперативного исправления всяких неисправностей очень не хватало подобного COM-port монитора.
lingvo
Почему не взяли Labview — это же стандартая среда для данного применения?
efi Автор
Чрезмерно дорогое решение, если не ошибаюсь, не кросс-платформенное, и, боюсь, никак его не интегрировать с какой-нибудь Web-системой
lingvo
ИМХО тогда у вас что-то не то с тестовой системой. То ли она легаси — т. е вы поддерживаете много старых стендов, то ли что-то непонятное. Слишком сложно получается и все на UART. Как-то я не понимаю нобходимость Веб-сервера, если задача тестового стенда — оператор нажал на кнопку старт — провести тестирование — создать протокол. Все вроде.