Только что закончили достаточно длительную работу (заняла в целом от постановки задачи до реализации 3 месяца) установки российской системы АСУТП типа "Овен" на 2 наши вакуумных печи.
С этой неприятной ситуацией я столкнулся в сентябре 2025 года, когда в процессе технического перевооружения некоего объекта гражданской промышленности, название и местоположение которого никому неинтересны, пытался подружить Каскад-Цифра 3.18 (он же WinCC OA) с древним контроллером Schneider. Этот ПЛК оставался единственным, не подлежащим замене, и порядка полутора тысяч сигналов с него необходимо было перетащить в новую SCADA. SCADA, к слову, крутится на ПК под управлением Astra Linux, то есть - под дебианом.
Было принято решение организовать обмен по протоколу Modbus TCP, в процессе пришлось столкнуться с некоторыми затруднениями. О них ниже.
В этой статье я хочу поделиться своим видением того, каким должен быть удобный и информативный интерфейс SCADA системы.
Все иллюстрации в статье – это скриншоты, сделанные с разработанной мной SCADA системы, которая уже несколько лет работает на объектах заказчиков. Это не фантазии на тему как должно быть и не картинки из презентации.
При разработке я опирался на известную книгу «The High Performance HMI Handbook» (Hollifield, Oliver, Nimmo, Habibi), а также подсматривал интерфейс у Citect SCADA.
Когда речь заходит про умные заводы, «тёмные производства», цифровых двойников, промышленный интернет вещей и в целом будущее, многие настолько воодушевляются, что упускают из фокуса важные вещи. А именно – общую логику построения систем автоматизации заводов. Об этом и не только рассказывает руководитель направления «Цифровая промышленность» в СберМобайле Олег Плотников. Основы, описанные в ISA-95 или ГОСТ Р МЭК 62264-1-2014, всегда звучат в рассказах, презентациях или описаниях. Авторы используют такие термины, как SCADA, PLC, IIoT-платформа или MES. Но вот правила работы и уровни промышленной автоматизации часто трактуют неверно. И очень зря. Уровни автоматизации при неудачном смешивании могут вызвать немало проблем. Потому всегда нужно держать в голове пирамиду АСУ ТП/АСУП, о которой мы сегодня и поговорим. Добро пожаловать в основы цифрового завода.
В 2022 году к нашей дружной команде (я и Дмитрий @DIIV) обратился знакомый и предложил разработать систему для автоматического управления климатом овощехранилищ. Это был очень сложный период, компании уходили с Российского рынка, начались проблемы с покупкой и обслуживанием иностранных систем.
До этого у нас был опыт разработки подобных систем и устройств, который пришёлся как раз на начало пандемии COVID, что привело к проблемам с покупкой электронных компонентов.
Исходя из этого, нами было принято решение разработать собственную SCADA систему и все необходимые устройства для интеграции датчиков и управления оборудованием, чтобы иметь практически полную независимость. Учитывая опыт COVID, при проектировании устройств было решено использовать широко распространённые электронные компоненты, которые легко можно заменить на аналоги, сделать систему простой, недорогой и надёжной.
В этой статье описан наш опыт выявления причин ошибки в расчете положения подъемного сосуда в шахтном стволе по сигналам с инкрементальных энкодеров, который может быть полезен другим разработчикам, наладчикам и инженерам АСУТП, работающим не только с подъемным оборудованием, но и с любым другим, где малые приращения используются для расчета больших величин.
Начнем с небольшого погружения в предметную область. Наша организация специализируется на наладке шахтных подъемных установок, это, выражаясь совсем простым языком, «как лифт, только для шахты». Принцип действия подъемной установки, в целом, как у лифта — привод вращает барабан, на который наматывается канат, на который подвешен подъемный сосуд — бадья, клеть или скип, в зависимости от производственной задачи — проходка ствола или тоннеля, добыча полезных ископаемых или подъем/спуск людей. Основная часть подъемной установки — подъемная машина, это барабан с редуктором и приводом (их может быть два), тормозная система, а также системы управления, контроля и защиты.
На одной из таких подъемных машин, которую мы ввели в эксплуатацию и обслуживаем, положение подъемного сосуда для большей надежности контролируется одновременно двумя устройствами — САУ (Система автоматизированного управления) и АЗКД (Аппарат защиты и контроля движения). Для этого с каждого из двух датчиков углового положения вала — инкрементальных энкодеров, установленных на левом и правом редукторе (машина двухприводная), сигнал дублируется на счетные модули двух ПЛК (программируемых логических контроллеров), в САУ и в АЗКД, соответствующего канала, левого или правого. То есть, и в САУ, и в АЗКД установлено по два отдельных ПЛК, контролирующих так называемые левый и правый канал управления, относящиеся, соответственно, к левому и правому приводам подъемной машины, всего четыре ПЛК, из которых два ПЛК левого канала и в САУ, и в АЗКД получают данные с энкодера левого привода, а два ПЛК правого канала, соответственно, с правого.
Корпоративные стандарты АСУ ТП часто считают бюрократией: «ещё один документ, ещё больше рамок для инженеров».
На деле отсутствие стандарта — это настоящий «зоопарк»: разные ПЛК, разные библиотеки, разные теги, разные подходы к диагностике. Проекты плывут по срокам, простои растут, цифровизация упирается в хаос данных, а зависимость от «того самого инженера» становится критической.
Nestlé, Bosch, GM и другие уже давно инвестируют в стандарты — не ради моды, а потому что это реальные деньги:
В статье разбираю механизмы, которые превращают стандарт из бумаги в работающий актив: библиотеки блоков, генераторы кода, копирование сигналов, контроль версий.
Давайте представим, что нам нужно построить сложный объект — скажем, самолет, поезд или вообще атомную электростанцию. Строить «наобум» невероятно дорого и рискованно. Гораздо разумнее выполнить предварительные расчеты и скорректировать слабые места. Есть разные виды расчетов, ну например расчет прочности конструкции, расчет стомости сорружения или эксплуатации, расчет последствий аварии (для АЭС). Расчеты бывают статические например расчет фундамента, расчет толщщины стены, или просто расчет нагрузки на балку. И динамические - расчет некоторого процесса разворащивающегося во времени например: расчет процесса нагрева котла в доме, расчет процесса разгона авиационного двигателя, расчет процесс поддержания давления в кабине самоелета при изменении высоты. В динамических расчетах сложных объектах, как правило необходмо учитывать работу автоматической системы управления (АСУ), поскольку система управления влияет на процесс.
Если мы говоримт об АСУ ТП (Автоматической Системе Управления Технологическими Процессами), то само название как бы намекает на наличие некоторого процесса во времени, а значит тут есть место для динамического рассчета. Вот здесь-то на сцену и выходит "Среда динамического моделирования технических систем SimInTech."
Хотите узнать, как поведёт себя котельная установка, двигатель, система вентиляции и тд? Вместо того, чтобы собирать макет и проводить натурные испытания (иногда практически невозможные), мы используем SimInTech. SimInTech — это программное обеспечение, в котором можно создать математическую модель объекта и провести все испытания на компьютере, без риска и лишних затрат. Это позволяет найти ошибки и оптимизировать конструкцию объекта и отладить систему управления ещё до начала реального производства.
Многие предприятия до сих пор эксплуатируют системы автоматизации зданий (BMS) на базе оборудования Johnson Controls предыдущих поколений. Часто возникает задача модернизации или расширения системы.
Цель данной работы — исследовать механизм обмена данными протокола N2Bus по интерфейсу RS-485 и проверить возможность подключения современных устройств Modbus RTU непосредственно в ту же физическую шину, где "живут" контроллеры Johnson Controls.
Важно: Все приведённые данные использованы исключительно для целей локальной интеграции. Материал предназначен для образовательных и исследовательских целей в контексте интеграции в системы автоматизации зданий.
В мае 2025 года на Хабре вышел рейтинг российских SCADA-систем. Его можно приветствовать как первый опыт систематизации рынка, однако он обладал существенными недостатками – в него почему-то не попали ведущие российские SCADA и наоборот, были включены малоизвестные новички. Так например, рейтинг 2025 года проигнорировал старейшие российские SCADA КРУГ, TRACE MODE а первое место отдано КАСКАДУ, на тот момент исключенному из реестра отечественного ПО в 2025.
Поэтому представляю рейтинг российских SCADA 2026, представляющий 5 основных SCADA-систем.
Цифровую трансформацию на заводах всё чаще начинают с MES, аналитики и BI. На слайдах всё выглядит логично: данные собираются, алгоритмы работают, решения принимаются автоматически.
Но в реальности такие проекты либо не стартуют, либо застревают на пилотах, либо теряют половину функциональности уже по ходу внедрения.
Проблема почти никогда не в платформах и не в подрядчиках.
Проблема в том, что нижний инженерный слой живёт своей жизнью: код PLC написан «как получилось», данные есть, но их невозможно использовать, а любая интеграция превращается в раскопки.
В результате проекты дорожают, сроки плывут, инженеры эксплуатации перегружены, а вместо использования существующих данных ставятся новые датчики и шкафы.
Почему так происходит, при чём здесь Greenfield и Brownfield, когда стандарт начинает приносить реальные деньги — в проектах и в ремонтах — и почему начинать стандартизацию нужно именно с PLC-кода, а не с BI, — разбираем на практике.
Влияние информационной безопасности на производственные процессы часто недооценивается. Даже корректно сформулированные требования могут привести к росту времени реакции, усложнению поддержки и увеличению стоимости эксплуатации, если внедрять их без учёта особенностей АСУ ТП.
Эта статья предлагает системный взгляд на взаимодействие ИБ с инженерами: какие решения помогают, какие — создают дополнительные риски, и как выстроить баланс, который реально повышает устойчивость производства, а не снижает её.
Эта тема поднимается довольно часто при общении с заказчиками, поэтому решил свои мысли развернуть в статью.
В каждой крупной компании есть своя невидимая конституция — документ, который решает, как работает каждый датчик, какой цвет у кнопки «Пуск» и как должен называться тег в контроллере.
Эти внутренние стандарты автоматизации редко показывают публике, но именно они превращают сотни заводов в один живой организм, где каждая линия, каждая установка подчиняется общей инженерной логике.
Там, где другие строят с нуля, Nestlé просто открывает шаблон. Где кто-то ищет «как сделать», Iberdrola просто следует собственному кодексу автоматики.
И чем сложнее технологии, тем ценнее становится не оборудование — а порядок.
Протокол OPC является наиболее универсальным, так как поддерживает все популярные типы данных и механизмы обмена информации, поэтому многие SCADA системы в принципе не поддерживают никаких дополнительных протоколов, помимо OPC, и подключение к другим протоколам осуществляют посредством сторонних OPC серверов. В DevelSCADA же работа с наиболее популярными протоколами ведется напрямую, а OPC используется для работы с протоколами, поддержка которых еще не реализована в ядре.
В DevelSCADA используется версия протокола OPC UA, так как он на данный момент является наиболее популярным и кросплатформенным. Так же протокол OPC UA имеет множество механизмов по защите соединения, что может быть актуальным при работе по незащищенном каналам связи (к примеру через сеть интернет).
Система DevelSCADA, как и любая SCADA система, в первую очередь предназначена для взаимодействия с каким либо физическим оборудованием. Для этого система поддерживает набор популярных протоколов связи с различными устройствами автоматики. В DevelSCADA, для удобства работы, реализован механизм «Устройств», который позволяет без необходимости обращаться к низкоуровневым данным протокола, посредством графического интерфейса, настраивать связь с устройством и формировать список переменных, обмен значениями которых необходим в процессе работы с этим устройством.
Система DevelSCADA поддерживает широкий спектр возможностей по расширению функционала с помощью скриптов, однако эти возможности все равно ограничены средствами, предоставляемыми самой SCADA системой, заложенной в нее разработчиками системы. При этом не редко есть необходимость расширить данный функционал, и зачастую для этого единственный вариант - просить разработчиков его реализовать внутри SCADA системы. Чаще всего такие запросы просто игнорируются, либо сильно растягиваются по срокам.
DevelSCADA изначально была спроектирована как дружественная к разработчику система, и она позволяет самостоятельно расширять свой функционал. Для этого в системе предусмотрен механизм «Приложений», позволяющий без каких либо ограничений добавлять необходимый функционал в ядро системы.
Данный механизм может быть полезен, к примеру, для интеграции DevelSCADA с какими-то сторонними системами или сервисами, имеющими специфичные интерфейсы взаимодействия, не предусмотренные в базовой поставке SCADA системы, а так же с устройствами, имеющие специфичные, свои собственные протоколы.
Для расширения базового функционала среды разработки DevelSCADA, система поддерживает возможность использования скриптов. Основным языком для разработки скриптов является JavaScript. Скрипты, в свою очередь поддерживают весь функционал языка JavaScript, дополняя его функциями работы с системой DevelSCADA.
Система поддерживает работу с двумя видами скриптов - скрипты интерфейса и скрипты ПЛК. Оба типа скриптов имеют идентичные интерфейсы для взаимодействия с системой, но при этом имеют разное предназначение.
Сегодня, говоря о беспроводных датчиках Интернета вещей (IoT), мы представляем себе компактные устройства, идеально подходящие для небольших помещений и ограниченных пространств. Однако, перенося такие датчики в реальную производственную среду — будь то заводские цеха, строительные площадки или удалённые объекты инфраструктуры — возникают совершенно новые требования, которые зачастую кардинально меняют концепцию продукта. "Беспроводному" датчику приходится эволюционировать и обзавестись… проводами. Как это происходит и почему — разберёмся в этой статье.
Представлен резонансный регулятор, метод его анализа в непрерывной области и реализации в виде цифрового фильтра методом согласования нулей и полюсов. Показано стремление в установившемся режиме по заданной частоте амплитуды и фазы к управляющему сигналу. Отмечены особенности фильтра в виде бесконечной добротности, для дискретной системы ограничиваемой лишь разрядностью вычислителя.
