Промышленное программирование *

Открытая АСУТП хороша тем, что её можно и нужно адаптировать под себя. Но что делать, когда встроенного функционала не хватает? Когда вам нужна уникальная логика, алгоритм или расчёт?

Ответ — создавать свои функциональные блоки. Именно этот шаг превращает вашу АСУТП из «коробочного» решения в по-настоящему гибкую систему, заточенную под ваши процессы. В этой статье, продолжая наш цикл о построении открытой АСУТП, мы на практике подробно разберём один из двух основных вариантов разработки пользовательских функциональных блоков.

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

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

Эти внутренние стандарты автоматизации редко показывают публике, но именно они превращают сотни заводов в один живой организм, где каждая линия, каждая установка подчиняется общей инженерной логике.

Там, где другие строят с нуля, Nestlé просто открывает шаблон. Где кто-то ищет «как сделать», Iberdrola просто следует собственному кодексу автоматики.

И чем сложнее технологии, тем ценнее становится не оборудование — а порядок.

Митапы про микросервисы, хайп вокруг новых фреймворков, кеш и перекрашенные кнопки — привычная рутина современного айтишника…

Но мы-то знаем: есть и другое IT. Там пишут код, от которого зависят тонны синтетических материалов или выплавленной стали, скорость производственной линии и бесперебойная работа энергосети. Это мир Heavy Digital. И он становится всё больше.

Мы захотели выяснить, почему всё больше IT-специалистов осознанно выбрали работу на заводах и в промышленных гигантах. Что за мотивы ими движут, какие задачи вызывают настоящий драйв и чувство сопричастности к чему-то большому? Мы собрали эти и другие вопросы и приглашаем всех причастных к IT в промышленности ответить на них в ветке «Я эксперт в Heavy Digital».

А ещё мы хотим узнать мнение тех, кто слышал о Heavy Digital и только стоит на пороге выбора. Чтобы понять ваши ожидания и страхи, мы создали ветку опроса «Я пока не в Heavy Digital».

Спойлер: в конце ветки для экспертов у вас будет возможность рассказать о самом запоминающемся профессиональном вызове. Авторы 10 лучших историй смогут получить ачивку «Герой Heavy Digital» в своем профиле на Хабре.

Готовы? Тогда выбирайте свою ветку — и вперёд!

Статья начинает цикл материалов по разработке электроприводов, подходов и технических нюансов, которые используются при их проектировании. Охватим большую часть силовой электроники для электропривода, промышленные сети (PROFINET, EtherCAT, CC-Link, EtherNet/IP (CIP) и др.), энкодеры (абсолютные: Hiperface DSL, SSI, BISS и др., а также инкрементные). Датчиковое и бездатчиковое векторное ориентированное управление  (sensored/sensorless FOC - EKF/MRAS/SMO/HFI), рассмотрим электродвигатели PMSM (СДПМ), ACIM (асинхронный ЭД), BLDC (бесколлекторный двигатель постоянного тока) и другие их виды. 

С 11 по 22 ноября 2025 года в Российском новом университете пройдут тренинги предпринимательских компетенций. Мероприятие организовано Московским физико-техническим институтом совместно с Российским новым университетом в рамках федерального проекта «Платформа университетского технологического предпринимательства».

У нас есть легковые машины, грузовые машины, битумовозы, спецтехника и много чего ещё интересного. Всё это управляется через диспетчерскую, и там были некоторые костыли, обусловленные системой учёта. Например, нельзя было отправить пескоразбрасыватель, мобильную систему пылеподавления либо грузовик навалочной погрузки куда-то по сложному маршруту. Или чтобы они отработали не полную смену, потому что всё квантовалось сменами.

Копились и другие проблемы.

Например, пользователи стали продвинутыми и жаловались на дружелюбность интерфейса. На самом деле тяжело представить в одном предложении слова «дружелюбность интерфейса» и нашу старую систему заявок на транспорт.

Всё это работало только под IE/Edge, не поддерживало Хромиум, конфликтовало с требованиями ИБ.

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

Мы давно задумывались о рефакторинге или миграции, суть споров сводилась к самопису или «коробке».

Мы всё проанализировали и решили, что надо взять готовую «коробку», которую потом нужно будет допилить процентов этак на 10.

В итоге оказалось, что сначала мы допилили процентов на 20, а потом от исходной «коробочной» версии осталось процентов 10, и вся разработка переехала к нам внутрь.

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

Привет, Хабр! Одна из задач при управлении роботами-манипуляторами – расчет обратной кинематики. Данный вид кинематики позволяет вычислить углы наклона суставов робота (joints) таким образом, чтобы захват (grip) робота пришел в заданные трехмерные координаты с правильным углом наклона. Для многих роботов уже есть алгоритмы и формулы вычисления обратной кинематики, мы (команда Zebrains) столкнулись с отсутствием готового решения для робота xArm 2.0.

В статье мы подробно опишем с какими сложностями столкнулись при управлении данным роботом, как получили формулы для расчета двух видов кинематики для данного робота и поделимся кодом на C++. В проекте использовался ROS2, ноды которого были написаны на C++.

Сегодня сложно представить технологическую компанию, которая бы всерьёз занималась разработкой и не использовала инженерные расчёты. CFD-, FEA-, тепловые, а также одномерные (1D) симуляции давно стали повседневными инструментами.

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

И вот тут возникает парадокс: всё это богатство может храниться где угодно (на рабочем компьютере, на кластере, на каком-то внешнем жестком диске), но в целом никто толком не знает, где именно, в каком виде и насколько это вообще пригодно для повторного использования. На поиск информации может уходить больше трети рабочего времени расчетчика.

Если расчёты – это актив, то ими нужно активно управлять. Расскажу, как подойти к этому шаг за шагом.

В работе инженера по автоматизации нередко возникают задачи, выходящие за рамки типового программирования. Одной из таких является поиск и устранение неисправностей в сложных мехатронных системах, где не всегда очевидно, какой механизм или устройство работает некорректно. На помощь может прийти полезный инструмент - цифровой двойник.

Вы видели такие токарные автоматы? Это шестишпиндельный 1Б240-6 револьверного типа. Очень старый девайс, полностью механический, на концевиках и реле. Никаких тебе ЧПУ, лазеров и шаговых двигателей, только хардкор. Это просто потрясающая механическая симфония.

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

~2008 год: Один человек как-то в разговоре пожаловался мне на проблему, с которой он сталкивается много лет, но как победить не знает. Он рассказал мне на пальцах, что происходит. На тот момент я в глаза не видел такой станок, да и вообще был далек от металлообработки. Но, с его слов, примерно понял, как там все устроено и предложил решение. Решение было реализовано сначала на одном станке, а затем распространено на остальные и с тех пор о проблеме забыли.

Это просто история о том, как реверс-инжиниринг мне помог решить производственную задачу. Здесь не будет рекомендаций или фрагментов кода, это лишь рассказ из жизни о проблеме и решении.

2010 год: я работал на одном промышленном предприятии. За пару лет до моего прихода они закупили комплект автоматики у другого подобного предприятия. Как это часто бывает, сначала какая-то организация делает автоматику для решения своих задач, а затем, видя успешность своего решения, начинает продавать это решение себе подобным.

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

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

Происходило это не так что бы сказать осознанно — собирали совещание или звонили и предлагали дать рекомендации что делать и почему не получается достичь результата. Это очень нехорошая ситуация — там уже очень длительно работали команды и группы, сформированные приказом или как минимум распоряжением, много месяцев работали и зашли в тупик. При этом отказаться нельзя — дать рекомендации это распоряжение руководства, проигнорировать нельзя.

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

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

Протокол OPC является наиболее универсальным, так как поддерживает все популярные типы данных и механизмы обмена информации, поэтому многие SCADA системы в принципе не поддерживают никаких дополнительных протоколов, помимо OPC, и подключение к другим протоколам осуществляют посредством сторонних OPC серверов. В DevelSCADA же работа с наиболее популярными протоколами ведется напрямую, а OPC используется для работы с протоколами, поддержка которых еще не реализована в ядре.

В DevelSCADA используется версия протокола OPC UA, так как он на данный момент является наиболее популярным и кросплатформенным. Так же протокол OPC UA имеет множество механизмов по защите соединения, что может быть актуальным при работе по незащищенном каналам связи (к примеру через сеть интернет).

Каждый, кто работает с AI, рано или поздно сталкивается с его ограничениями. Недавно я столкнулся с такой ситуацией: Perplexity успешно проанализировал сайт и собрал все ссылки, но отказался их обработать, сославшись на «превышение лимитов ресурсов». Что это за «лимиты» в облачной системе, обладающей, казалось бы, бесконечными мощностями? Этот, на первый взгляд, рядовой сбой стал отправной точкой для технического исследования: я решил заглянуть «под капот» AI-песочницы, чтобы понять, как она на самом деле устроена и почему знание ее архитектуры помогает работать с ней гораздо эффективнее

Если посмотреть на ведущие промышленные компании — от машиностроения до нефтегаза, — становится ясно: многие из них давно и плотно занимаются разработкой собственных, внутренних стандартов по АСУТП. Это не просто свод общих правил. Речь идет о детальных регламентах, которые покрывают все: от проектирования архитектуры и выбора ПО до конкретных требований к интерфейсам операторов, промышленной безопасности и дальнейшему сопровождению систем.

Главная особенность этих документов в том, что они — не сухая адаптация норм вроде ГОСТ или МЭК. Это, скорее, живые и практические руководства, которые инженеры компаний буквально «выстрадали» на собственном опыте. Они рождаются из реальных проектов, учебы на ошибках и направлены на решение конкретных задач, а не на соответствие абстрактным нормативам.

Что это дает на практике? Эффект от внедрения таких стандартов — вполне измерим. Это не просто «для галочки». Компании получают реальные результаты:

Я — типичный гуманитарий, который, однако, тесно взаимодействует с айтишниками, физиками, математиками, любит технологии и погружается в вопросы искусственного интеллекта. Особенно это приятно и удобно делать, когда ты работаешь в стенах крупнейшего университета и можешь легко задать вопросы коллегам. А, как известно, если человек в чём‑то глубоко разбирается, он способен объяснить предмет на пальцах. И вот занесли меня деловые вопросы на физический факультет, где проходил семинар по мемристорам. Сказать, что было страшно непонятно — не сказать ничего. Но рассказы коллег‑учёных о тонкостях и сложностях подбора химического состава компонентов просто заворожили — настолько это сложный, глубокий, профессиональный подход, сочетающий химию, физику, математику… Пользуясь случаем, я поговорила о мемристорах с к. ф‑м. н. Алексеем Михайловым, который как раз руководит научно‑исследовательской лабораторией «Лаборатория мемристорной наноэлектроники» ННГУ. Получился трогательный, умный и на редкость понятный монолог о философии мемристоров. Делюсь им с вами.

«Начнём с того, что эффект памяти, память — это, по сути, явление природы. Стоит сказать, что мемристоры — это фактически открытие в контексте нашего познания природы. Это открытие сделал Леон Чуа, очень известный американский учёный, инженер, исследователь. Он был известен задолго до того, как придумал мемристоры. Точнее, не придумал, а открыл, — он сам подчёркивает, что открыл мемристоры буквально как явление природы. В чём-то это можно сравнить с открытием электричества или рентгеновского излучения.

Система DevelSCADA, как и любая SCADA система, в первую очередь предназначена для взаимодействия с каким либо физическим оборудованием. Для этого система поддерживает набор популярных протоколов связи с различными устройствами автоматики. В DevelSCADA, для удобства работы, реализован механизм «Устройств», который позволяет без необходимости обращаться к низкоуровневым данным протокола, посредством графического интерфейса, настраивать связь с устройством и формировать список переменных, обмен значениями которых необходим в процессе работы с этим устройством.

Система DevelSCADA поддерживает широкий спектр возможностей по расширению функционала с помощью скриптов, однако эти возможности все равно ограничены средствами, предоставляемыми самой SCADA системой, заложенной в нее разработчиками системы. При этом не редко есть необходимость расширить данный функционал, и зачастую для этого единственный вариант - просить разработчиков его реализовать внутри SCADA системы. Чаще всего такие запросы просто игнорируются, либо сильно растягиваются по срокам.

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

Данный механизм может быть полезен, к примеру, для интеграции DevelSCADA с какими-то сторонними системами или сервисами, имеющими специфичные интерфейсы взаимодействия, не предусмотренные в базовой поставке SCADA системы, а так же с устройствами, имеющие специфичные, свои собственные протоколы.

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

Система поддерживает работу с двумя видами скриптов - скрипты интерфейса и скрипты ПЛК. Оба типа скриптов имеют идентичные интерфейсы для взаимодействия с системой, но при этом имеют разное предназначение.