Разработка IoT-устройств на заказ

Проектируем и внедряем собственные электронные устройства на базе однокристальных компьютеров для промышленного IoT и бизнес-IoT. Логика работы — свободная: под ваш процесс, протоколы и инфраструктуру, а не «коробка с чужой прошивкой».

Устройства уже работают на реальных объектах: сбор данных с датчиков, управление исполнительными механизмами, локальная обработка и передача в SCADA, MES, облако или наш ПАК «Х-Авто».

Что делаем

Разработка аппаратной части и прошивки под задачу предприятия
Свободная логика: сценарии, пороги, расписания, аварии, отчёты
Интеграция с весовыми, видеонаблюдением, СКУД и существующими АСУ
Пилот на объекте, серийное сопровождение и развитие функционала

Для каких задач

Типовые сценарии — от мониторинга инженерии до шлюзов и узлов, которых нет в каталоге готовых поставщиков.

Мониторинг инженерных систем и производственных параметров
Локальные контроллеры с автономной логикой при потере связи
Шлюзы между полевыми интерфейсами и верхним уровнем
Кастомные узлы, которых нет в каталоге готовых поставщиков

Сборка и контроль

Плата — не картинка из каталога. Мы собираем и проверяем узлы сами: пайка, монтаж, контроль под микроскопом, прошивка и обкатка до выезда на объект. Так меньше сюрпризов на пусконаладке и проще дорабатывать логику после пилота.

Примеры наших устройств

Фотографии самостоятельно разработанных и внедрённых плат и контроллеров:

Как начинаем проект

Фиксируем задачу, интерфейсы и условия эксплуатации
Предлагаем архитектуру и сроки пилота
Изготавливаем и обкатываем опытный образец на объекте
Масштабируем и сопровождаем

Про IIoT в целом

Устройство на однокристальнике — это нижний уровень. Имеет смысл, когда вокруг него есть контур: датчики, сеть, рабочие места и правила «что делать, если связь пропала». Ниже — как мы это собираем на предприятии, если интересно задержаться.

IIoT для нас — живая картина объекта, а не набор гаджетов. Полевые сигналы доходят до диспетчера, технолога и бухгалтерии в понятном виде: расход, простой, авария, кто проехал через весовую, что случилось в щитовой. Облако — по желанию заказчика; чаще данные остаются во внутреннем контуре.

Из чего складывается контур

Поле. Температура, уровень, ток, сухие контакты, счётчики, приводы. Там, где готового модуля нет — своя плата.
Локальная логика. Пороги, таймеры, блокировки, работа «в офлайне», чтобы линия не умерла из‑за обрыва Ethernet.
Связь. Ethernet, ВОЛС, RS-485, радиосегменты, шлюзы между протоколами.
Верх. SCADA, MES, 1С, ПАК «Х-Авто», видеоархив, отчёты руководителю смены.

Зачем это производству, а не «цифровой трансформации»

Меньше ручных обходов и «мне кажется, насос гудел иначе»
Предиктивное обслуживание: моточасы, пуски, аварии — до поломки, а не после акта
Связка события и камеры: инцидент на весовой или в цехе виден сразу
Повторяемость режимов и прослеживаемость партии
Пилот на одном участке с измеримым KPI, затем копирование на однотипные объекты

Типовые объекты

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

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

От одного датчика к системе

Один датчик температуры честно отвечает на один вопрос: «сколько градусов здесь и сейчас». Это полезно. Но это ещё не аналитика — это показание.

Когда точек измерения десятки и сотни, меняется сама природа данных. Появляется сравнение участков и смен, история вместо «сейчас», отклонения вместо «нормы на глаз», предупреждение вместо акта после аварии.

Один датчик

Факт: температура, уровень, ток. Диспетчер видит цифру. Решения всё ещё зависят от опыта смены.

десятки

Сеть точек

Контекст: где теплее, где растёт расход, какой насос «устал» раньше соседнего. Появляется картина процесса, а не точка на схеме.

сотни

Иной уровень

Аналитика, тренды, раннее предупреждение и прогнозирование: не «сломалось», а «сломается, если не вмешаться».

Мониторинг — знать состояние прямо сейчас
Диагностика — видеть, где процесс уходит от нормы
Предупреждение — ловить аномалию до простоя и брака
Прогноз — опираться на накопленную историю и повторяющиеся паттерны

Поэтому мы собираем не «ещё один термометр», а контур: полевые сигналы, логика на контроллере, связь и рабочие места. Чем плотнее сетка датчиков — тем раньше предприятие узнаёт о проблеме и тем дешевле обходится решение.

Подробнее по теме

Эволюция темы

Раньше полевую автоматику закрывали каталожными ПЛК и готовыми модулями ввода-вывода: это работало, пока процесс совпадал с чужой прошивкой. Рост IIoT и разнообразия периферии сделал заметнее разрыв: нестандартные датчики, локальная логика при обрыве связи, стыковка с весовой, СКУД и уже стоящей SCADA. Современный заказ часто требует устройства «под задачу» — аппаратная часть и свободная логика, а не коробка с чужим сценарием «из каталога».

Аналитика темы

Кастомный контроллер оправдан, когда стоимость подгонки процесса под чужую прошивку выше стоимости разработки узла — или когда каталог просто не закрывает протокол и среду. Риск кастома — вечный прототип без тиража; защита от него — пилот на одном контуре, измеримый KPI и повторное использование логики на однотипных объектах. Тогда устройство становится частью системы, а не разовым «железом на полку».

Расчёт эффективности

Оценочные ориентиры при выборе между «каталог + костыли» и «узел под процесс». Считаем на горизонте пилота + тиража N копий.

Сокращение штата интеграторов и сопровождения

Подгонка чужой прошивки часто держит интегратора на объекте неделями (и возвращает при каждом изменении сценария). Свой контроллер с зафиксированной логикой после пилота снижает «вечный консалтинг»: ориентир экономии 100–400 человеко-часов на запуске и 0,2–0,5 ставки сопровождения в год на парк однотипных узлов (условно 0,3–0,8 млн ₽/год при рыночной ставке интегратора).

Цена ошибок «почти подошло»

Сценарий так и не закрыт — простой или ручной режим месяцами
Обходные схемы (Excel, звонки, «временные» реле) — накопление скрытых потерь
Повторная закупка модулей «вдруг эта опция заработает» — выброшенный CAPEX

Оценочно год жизни с полурабочим каталожным узлом на ответственном контуре легко даёт 0,5–3+ млн ₽ потерь и переделок — больше стоимости пилота своей платы.

Время принятия решения (разработка и внедрение)

Каталог: недели ожидания ответа вендора «поддерживается ли ваш протокол». Свой контур: решение по сигналам и сценарию — на обследовании, прототип — на пилоте, тираж — без ожидания roadmap чужого продукта. Сжатие цикла «идея → поле» с кварталов до недель–пары месяцев на узком KPI.

Инвестиционная привлекательность

Точка перелома: когда N однотипных узлов делает удельную стоимость своей разработки ниже суммы каталог + костыли + простои. Типичный ROI-нарратив для собственника: payback 8–20 месяцев на пилоте с понятным KPI, далее маржа на копиях. Это капитализация ноу-хау процесса, а не зависимость от чужого каталога — см. общий контур на IIoT.

Когда каталожного контроллера недостаточно

Готовая «коробка» удобна, пока процесс совпадает с чужой прошивкой. На реальных объектах часто нужны нестандартные протоколы, локальная обработка при обрыве связи, стыковка с весовой, СКУД или уже стоящей SCADA — тогда проектируем плату и логику под задачу, а не подгоняем процесс под чужой каталог.

Как ведём разработку устройства

Фиксируем сигналы, сценарии, пороги аварий и требования к среде (пыль, температура, питание)
Собираем прототип и проверяем на одном контуре с измеримым KPI
Дорабатываем прошивку и механику под монтаж и обслуживание на объекте
Тиражируем на однотипные узлы без переписывания логики с нуля

Устройства уже работают в поле: сбор с датчиков, управление исполнительными механизмами, передача в SCADA, MES, облако или ПАК «Х-Авто». Общий контур IIoT описан на странице IIoT.

Обсудить задачу Страница IIoT