Привет, Хабр! Это Сергей Банников, эксперт К2тех по цифровому производству. Знаете эту классическую фразу от бизнеса: «Там простенькая задача, нужно сделать пару элементарных интеграций»? Обычно именно после этих слов начинается самый суровый инженерный хардкор.

Хочу поделиться одной такой историей, как элементарная маркировка паллет превратилась в технологический квест с блуждающими COM‑портами под Astra Linux, переписыванием экранной клавиатуры с нуля и пробросом туннелей сквозь матрешку из виртуальных машин. 

Завязка: «там простенькая задача, две формочки»

Всё началось с того, что коллега между делом предложил оценить задачу для одного завода, который занимается фасовкой сыпучих кормов. Производство мы увидели не целиком, только четыре упаковочные линии, часть из которых еще строилась. Смысл проекта был простой: при расширении производства люди перестали успевать вручную маркировать продукцию. Заводу требовалась автоматизация, которую мы должны были обеспечить.

Нужно было сканировать штрих‑код товара на конвейере, печатать упаковочный лист и наклеивать его принтером‑аппликатором. Мы прикинули: пара экранных форм, пара интеграций с 1С, никаких сложных отчётов — всё просто, компактно и дешево. Набросали оценку и приступили к работе. 

Мешки‑анархисты, неполные паллеты и смена всей архитектуры

Первоначальная идея выглядела красиво: едет товар по конвейеру, стационарный сканер считывает штрих‑код, принтер‑аппликатор наклеивает этикетку. С коробками так и работает — штрих‑код на боку, всегда в одном месте, всегда читаемый. Но в нашем случае на двух из четырёх линий ехали мягкие мешки, и здесь нас ждал первый сюрприз.

Заказчик фасует корма для разных брендов, и упаковку ему привозят клиенты. На мешке штрих‑код может быть снизу, может быть сверху, а может не быть вообще — это не зона ответственности завода. Его задача: насыпать корм по весу. Где именно на мешке нанесена маркировка — это история партнёра. Соответственно, сканировать сами мешки в движении нереально. А чуть дальше по конвейеру все четыре линии сходятся в одном месте перед финальной обмоткой стрейч‑худом, и там уже вообще невозможно понять, что именно едет.

Решение пришло быстро: идентифицировать не каждый мешок, а сразу всю паллету по номеру производственной линии. Мы решили клеить штрих‑код с номером линии на поддон — система понимает, с какого конвейера пришла партия, а из 1С получает всю нужную информацию об этой линии: что производится, с каким весом, какие реквизиты идут на этикетку.

Параллельно выяснился ещё один нюанс. Роботы‑упаковщики умеют собирать полные паллеты. Если коробок на линии ровно кратное число — всё хорошо. Но если партия заканчивается раньше, последняя паллета остается неполной, и робот просто останавливается: своё дело сделал, но количество коробок знает только он. Её вручную выкатывают на отдельный участок. Для ввода фактического количества нужно отдельное рабочее место оператора. Плюс ещё один нюанс производства: замотчик иногда ошибается — коробка упала, паллета ушла в брак. Камера уже успела считать её в очередь, а значит, оператор должен вручную ее оттуда удалить. Итого: один АРМ для ввода количества на неполных паллетах, один контрольный АРМ у замотчика — это уже совсем не «две формочки».

Планшет без клавиатуры, ОС без Windows и кастомный UI для суровых условий

Когда дело дошло до автоматизированных рабочих мест, мы даже не рассматривали классические ПК с мышкой и клавиатурой. Офисный подход на заводе не живет: там пыль, постоянная вибрация, а люди работают в плотных перчатках. Обычный ноут в таких условиях отправится в утиль через неделю. Поэтому мы пошли по проверенному пути: посмотрели на парк оборудования заказчика и подобрали суровые промышленные безвентиляторные моноблоки с тачскрином. Железо неубиваемое, как раз для цеха.

С операционкой всё тоже было понятно на старте. Добыть сейчас промышленную Windows‑панель — тот еще квест, поэтому мы изначально закладывали в архитектуру Astra Linux. Само решение у нас кроссплатформенное, так что драйвер сканера под Linux мы спокойно написали и обкатали заранее, обошлось без пожаров и героических спасений.

А вот с интерфейсом решили заморочиться дополнительно, когда потестили его на реальном железе. Дело в том, что штатная экранная клавиатура «Астры» при вызове радостно перекрывала половину рабочего окна. В теории работать можно, но на практике оператору нужно просто вбить количество коробок на неполной паллете — и всё. Заставлять человека на конвейере каждый раз целиться в мелкие системные кнопки было бы издевательством.

Вместо этого наш фронтендер довольно быстро собрал кастомную цифровую панель. Сделали ее по принципу банкомата: огромные кнопки, только цифры и ничего лишнего. Заодно вынесли на видное место кнопку полноэкранного режима, потому что искать аналог F11 на тачскрине без физической клавиатуры — та еще боль. В итоге у человека перед глазами ровно одна функция, а шанс промахнуться мимо нужной кнопки практически сведен к нулю.

Блуждающий COM‑порт, альбом с секретными кодами и динамический поиск устройства

Промышленный USB‑сканер, который читал штрих‑коды на ручном АРМе, тоже был с небольшим сюрпризом. По умолчанию он работал в режиме виртуальной клавиатуры, нам‑то надо было читать его программой. Поэтому надо было переключить его в режим последовательного порта. Но на нем не оказалось никаких кнопок для этого! Оказалось, что переключение осуществляется считыванием специального системного конфигурационного штрих‑кода. Открытый вопрос — что будет, если кто‑то покажет такой код сканеру, введенному в эксплуатацию…

Итак, USB‑сканер наконец, заработал в режиме эмуляции последовательного порта. В Windows это не проблема: при первом подключении система даёт ему, скажем, COM8 — и при любом последующем переподключении адрес сохраняется. Можно жестко прописать порт в конфиге и спать спокойно.

Под Linux картина другая. Подключил — получил COM10. Выдернул, воткнул — COM12. Ещё раз — COM5. Адрес каждый раз новый, и система о нём никак не предупреждает, а на заводе выдернуть кабель может кто и когда угодно. Поэтому мы дописали алгоритм динамического сканирования: при каждом старте и при каждом разрыве связи программа обходит все доступные порты и ищет нужное устройство по его Vendor ID и Product ID. Без этого она рисковала принять за сканер что угодно, вплоть до чьей‑нибудь мышки, воткнутой рядом, и начать радостно читать из неё «штрих‑коды».

Матрешка из виртуальных машин и туннель через три слоя

Принтер‑аппликатор — это не просто принтер. У него есть механическая «лапа», которая берет напечатанную этикетку и физически переносит её на паллету. Координаты, усилие, тайминги срабатывания — всё это нужно было отладить заранее, чтобы не ставить эксперименты на живом конвейере заказчика.

К счастью, вендор предоставил официальный эмулятор — виртуальную машину в VirtualBox, которая полностью имитирует логику пульта и аппаратуры, принимая те же команды, что и реальное железо. Оставалось только интегрировать наш код с этой средой. Специфика заключалась в том, что эмулятор сам по себе установлен на виртуальной машине — получается эдакая матрёшка, и наружу его сетевые порты не смотрели.

Настройка сложного проброса трафика сквозь такую «матрёшку» из виртуальных машин — задача больше инфраструктурная, чем девелоперская. Поэтому мы не стали изобретать велосипед, а подключили наших сетевых инженеров: они быстро прорубили стабильный туннель, не нарушив связность тестового контура. В итоге in‑house тестирование прошло штатно. Мы прогнали полный цикл печати, отладили передачу всех реквизитов и приехали к заказчику с уже проверенным решением. На месте оставалось только подключиться к реальному железу и откалибровать физику движения лапы.

Релизы за десять минут прямо в цех

Когда система встала на боевые рельсы, поднялся вопрос поддержки. Традиционный подход на производстве — это обновления с флешки, пересылка архивов по почте или долгая ручная установка через VPN. Всё это плодит задержки, человеческие ошибки и командировки по малейшему поводу.

Мы решили перенести классические IT‑практики CI/CD в промышленный контур. Поскольку для заказчика на этом участке критически важна скорость реакции, нам согласовали доступ, и мы дотянули наш GitLab‑конвейер прямо до серверов завода. Настроили прозрачный пайплайн: ведущий разработчик пушит код в релизную ветку→ он проходит статический анализ в SonarQube → собираются артефакты под Windows и Astra Linux → выполняются тесты → автоматика раскатывает релиз на сервере в цеху. Весь цикл занимает около десяти минут.

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

Вот такой путь от «двух формочек» до многослойной системы с кастомным UI, динамической идентификацией сканера, матрешкой из виртуальных машин и CI/CD‑пайплайном прямо в производственный цех.

А вы сталкивались с подобными «простыми задачами», которые оборачивались чередой сюрпризов? Расскажите в комментариях.