АСУТП на молочном заводе и я: 2004 — настоящее время

В статье рассматривается история развития автоматизированных систем управления
технологическими процессами (АСУТП) на молочном заводе с 2004 года по
настоящее время со стороны непосредственного участника. Описывается опыт ^[1]
разработки собственных решений (собственной SCADA-системы) и сотрудничества с
ведущими поставщиками автоматизации. Статья предназначена для специалистов в
области промышленной автоматизации и систем управления.

Введение

АСУТП — основа современной промышленной автоматизации и инфраструктуры
управления. SCADA-система (Supervisory Control and Data Acquisition) является
частью, которая обеспечивает интерфейс между операторами и оборудованием, а
также сбор и анализ данных в реальном времени. Обычно это программный пакет,
предназначенный для обеспечения работы системы и/или разработки таких систем, —
сухое определение, которое заставляет вспоминать ^[2] предмет ТАУ (теория
автоматического управления) и ПИД-регулятор. Ничего интересного — одни формулы.
Такие мысли мне тоже приходили в голову в момент распределения после завершения
учебы в университете. Так получилось, что на последнем курсе устроился работать
в классическую IT-контору, но не остался там надолго и пошёл пробовать себя на
завод — в тогда ещё молодой отдел АСУТП. Что из этого вышло, далее попытаюсь
рассказать в этой статье.

История развития АСУТП

Для понимания, что такое АСУТП на предприятии, важно рассмотреть эволюцию ^[3]
технологий, архитектур и практик, которые формировали эти системы на протяжении
десятилетий.

До 1960-х управление промышленными процессами выполнялось вручную. Первые
телеметрические решения 1950-х годов дали возможность удалённого сбора данных,
но не полноценного управления. В 1960-х появились первые мейнфрейм-системы АСУТП
с централизованной архитектурой, проприетарными протоколами и релейной логикой ^[4],
что позволило сократить трудозатраты и повысить безопасность.

Далее системы развивались через три основных этапа:

• Распределённые решения (1970–1980-е). Мини-ЭВМ, LAN и повышенная надёжность.

• Сетевые решения (1990–2000-е). Переход к открытым стандартам (Ethernet, TCP/IP, Modbus, DNP3, OPC) и клиент-серверная архитектура.

• Современное поколение (2010-е). Интеграция IoT, облачных платформ и аналитики.

Можно выделить следующие ключевые вехи: переход от последовательной связи к
Ethernet и беспроводным сетям, появление PLC и промышленных ПК, а также развитие
протоколов Modbus, DNP3, IEC 60870-5-104, MQTT и OPC. Эти технологии обеспечили
масштабируемость, совместимость и возможность интеграции с корпоративными
системами.

Из приведённых ранее исторических сведений можно видеть, что автоматизация в
промышленности немного (или сильно?) отставала от IT в целом. Почему? Все мы
пользуемся мобильными телефонами — когда последний раз он работал «не так», как
надо, «зависал»? Ничего страшного — перезагрузка решает данную проблему. Если
нет — идём в магазин и покупаем новый. Главное то, что новый телефон имеет
больший экран, громче звучит, да и вообще, красиво выглядит — новый цвет, нет
царапин на экране… На производстве всё по-другому — завод работает 24 часа 7 дней в неделю 365 дней в году. Надёжность, надёжность и ещё раз надёжность —
вот что здесь важно. Особенно в пищевом производстве — продукт как живое
существо, не будет ждать, пока система загружается. Скорость управления —
реакция ^[5] на действия оператора (и не только) — также очень важна. Если что-то
идёт не так (авария и т.п.), система должна как можно быстрее перейти в
безопасное состояние. Скорость — критический параметр, скорость — это про
системы управления. После таких слов может показаться, что пытаться использовать
что-то современное для разработки — это гиблое дело и ничего хорошего из этого
не выйдет, особенно для небольшой команды из нескольких человек. Но не всё так
страшно, как кажется. Далее рассмотрим, что и как происходило во время моей
работы на заводе.

Работа в (или с) АСУТП на молочном заводе: 2004 — настоящее время

История молочного завода берёт своё начало с 1976 года: с момента ввода в
эксплуатацию Брестского молочного комбината (фасад здания в то время выглядел
так — рисунок выше).

Сразу же приведу картинку, как завод выглядит сейчас (вдруг кто-то не дочитает
до конца) — это уже 2025 год.

Я не буду описывать, какие системы были на заводе в то время — скажу одно: они
были хорошими представителями своего времени. И, самое главное, качество
продукции определялось (и определяется в настоящее время) людьми, которые эти
системы эксплуатировали. Для примера вот система управления пастеризатором. Она
обеспечивала базовый уровень автоматизации, включая сбор данных с датчиков и
управление некоторыми технологическими операциями.

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

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

Всеобщий спад перестроечных 90-х не мог не отразиться на работе комбината. Выход
из кризиса был делом не одного года. В то время на предприятии было принято
решение разрабатывать своими силами платформу системы, которая в дальнейшем
позволяла бы реализовать не только промышленные проекты АСУТП, но и решать
бухгалтерские, складские и другие задачи. Такой подход был обусловлен
несколькими факторами. Во-первых, на тот момент на рынке не было готовых
решений, которые полностью соответствовали бы потребностям ^[6] предприятия.
Во-вторых, разработка собственной системы позволяла более гибко адаптироваться к
изменениям в производственных процессах и требованиям бизнеса. В-третьих, это
было экономически выгодно, учитывая затраты на лицензирование и поддержку
сторонних решений. Кроме того, наличие собственной платформы позволяло
реализовать более тесную интеграцию с существующими системами и процессами на
предприятии, что было критически важно для обеспечения эффективного управления
производством.

Для разработки системной части был выбран язык C++, а для визуализации и
разработки — Delphi, так как уже имелся опыт успешной разработки на данной
платформе.

В качестве контроллера был выбран ICP DAS ICPCON I-7188 ^[7]
— это открытый контроллер, который поддерживал разработку на языке С/C++ и
имел широкие возможности для интеграции. В качестве операционной системы он
использовал DOS-подобную MiniOS7, которая обеспечивала стабильную работу
в промышленных условиях и имела высокие характеристики быстродействия (например,
время загрузки контроллера не превышало 1 секунду).

В качестве платформы для модулей ввода-вывода была выбрана WAGO I/O System 750 ^[8]
— эта платформа поддерживала (и поддерживает в настоящий момент) широкий спектр
интерфейсов и протоколов, что позволяло легко интегрировать её с различными
датчиками и исполнительными механизмами на предприят��и. Она также обеспечивала
надёжную работу в условиях промышленной среды и имела высокую степень защиты от
помех и вибраций.

В качестве контроллера для модулей ввода-вывода был выбран WAGO 750-315,
который обеспечивал высокую производительность и поддерживал широкий спектр
интерфейсов для подключения различных устройств.

В качестве протокола обмена данными между контроллером и модулями ввода-вывода
использовался Modbus RTU. Для подключения к контроллеру использовался
интерфейс RS-485, который обеспечивал высокую скорость передачи данных и
устойчивость к помехам в условиях промышленной среды на большом расстоянии.

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

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

Что запомнилось в то время? Для обновления управляющей программы (или описания
устройств) приходилось физически идти в цех, доставать контроллер из шкафа,
нести его в кабинет, подключаться к нему на своём рабочем месте и записывать
программу — а потом всё в обратном порядке: занести обратно в цех и подключить.
На всё это уходило очень много времени. Тогда и появилось выражение проверить
«на столе» — запустить управляющую программу прямо на рабочем месте и убедиться,
что она успешно выполняется. К сожалению, это не всегда означало, что программа
будет работать корректно «в цеху». Имеющиеся средства отладки были очень
ограничены — многое нужно было проверять вручную. Была также особенность с
портами: поскольку количество COM-портов контроллера было ограничено,
существовала специальная отладочная версия программы, где один из портов
отводился для подключения к компьютеру и через него осуществлялся ввод/вывод. В
рабочей же версии этот порт использовался для связи с модулями ввода/вывода.

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

Этот проект стал важным этапом в развитии АСУТП на предприятии и послужил
толчком для дальнейшей автоматизации других процессов. При этом необходимо
отметить, что процесс перехода на новый проект был достаточно сложным, так как
требовал не только технической реализации, но и изменения организационных
процессов и обучения ^[9] персонала. Однако успешная реализация этого проекта
позволила значительно улучшить процесс сортировки входного молока. Переход
осуществлялся без остановки производства буквально за одну ночь, что было важным
условием для обеспечения непрерывности работы предприятия. Для реализации этого
проекта была собрана команда добровольцев из числа сотрудников имеющегося на то
время отдела ИВЦ (информационно-вычислительный центр). Именно после этого
проекта из них и был сформирован отдел АСУТП, что отражало его новую
специализацию и направление деятельности.

В этом проекте я поработал над разработкой и внедрением модуля управления
распределительной гребёнкой клапанов. Этот модуль обеспечивал автоматическое
управление потоком молока при приёмке. До его появления оператор вручную
открывал нужные клапаны — медленно и с риском ошибки ^[10]. Теперь достаточно было
указать источник и приёмник, а модуль сам разбирался, какую последовательность
клапанов нужно открыть. Реализация оказалась относительно простой и прошла без
серьёзных проблем, так что в производство модуль был введён быстро. Однако
впоследствии, при модернизации и усложнении, проявились некоторые недоработки,
которые позже привели к полной его переработке. Из этого был усвоен главный
урок: усложняя систему, нужно параллельно переходить на более современные
аппаратные и программные платформы, которые лучше поддерживают разработку.

Также параллельно разрабатывался проект по автоматизации процесса мойки
оборудования без разборки (CIP — Clean In Place). Реализация данного проекта
позволяла самостоятельно (в пределах предприятия) решать проблему мойки
различного оборудования без покупки дорогостоящих сторонних (обычно зарубежных)
решений. В рамках этого проекта была разработана система управления, которая
обеспечивала автоматическое управление процессом мойки, включая контроль
температуры, давления и расхода моющих средств. При этом осуществлялась
интеграция с существующими системами управления (через передачу дополнительных
физических сигналов), что позволяло эффективно использовать ресурсы предприятия
и обеспечивать высокое качество мойки оборудования. Шкафы управления и модули
мойки собирались и монтировались своими силами, что привело к значительному
снижению затрат на реализацию проекта и интеграцию с существующими системами.

Разработка проектов активно продолжалась. Уже с 2006 года для контроля версий
стала использоваться система Subversion, что позволило упростить командную
разработку всё более усложняющихся проектов. Также в качестве редактора
исходного кода стал использоваться Visual Studio, а компиляция проекта
осуществлялась средствами Turbo C++ — была написана небольшая утилита для
данной цели.

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

В 2008-м году была представлена линейка µPAC-7186EXD — было увеличено
быстродействие, добавлена поддержка Ethernet. Переход с COM-портов на
Ethernet позволил решить проблемы удалённой поддержки — теперь не надо было
физически носить контроллеры для обновления. В то время также активно
присоединялись обанкроченные заводы без автоматизации. Таким образом решалась
проблема поддержки проектов, которые находились территориально не на главном
заводе, а на филиале — удалённый доступ позволял это делать без необходимости
командировки. Новые проекты стали разрабатываться на новой платформе, а старые
проекты постепенно обновлялись.

В связи с развитием технологий и появлением новых возможностей для
автоматизации, в 2014 году было принято решение о переходе на новую аппаратную
платформу — контроллер WAGO PFC200. Он обеспечивал более высокую
производительность, поддержку современных протоколов связи и более широкие
возможности для взаимодействия с различными устройствами и системами на
предприятии. Данный контроллер поддерживал разработку на языке С/C++, в
качестве операционной системы использовался Linux. Для разработки проектов
на новой платформе использовалась среда разработки NetBeans. Переход на
новую платформу позволил значительно расширить функциональность АСУТП и
обеспечить более эффективное управление производственными процессами. К тому
времени уже был осуществлён переход от RS-485 к Ethernet — от Modbus RTU к Modbus TCP, что позволило значительно упростить развёртывание и
обслуживание систем управления. Параллельно с этим начался проект по глубокой
интеграции САПР EPLAN и разработки на новой платформе, что позволило
автоматизировать процесс создания и обновления электрических схем и
документации, а также обеспечить более тесную интеграцию между проектированием и
реализацией систем управления. Об этом проекте более подробно будет рассказано
ниже.

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

В 2017 году получилось принять участие в программе «The Early Adopter Program» от ведущего производителя аппаратных устройств для автомат��зации
Phoenix Contact.

После официального представления платформы
PLCnext ^[11] в 2018 году, было принято решение
о переходе на эту платформу для разработки новых проектов практически сразу без
дополнительных задержек. В качестве контроллера был выбран AXC F 2152 ^[12]
а в качестве платформы для модулей ввода-вывода была выбрана Axioline F I/O System. Данная платформа использовала операционную систему Linux и
поддерживала разработку на языке C++.

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

Данный протокол позволяет подключать к контроллеру сложные устройства, например,
такие, как интеллектуальные датчики, которые могут передавать не только данные о
состоянии, но и диагностическую информацию, что позволяет более эффективно
управлять производственными процессами и обеспечивать высокое качество
продукции. Также при подключении исполнительных механизмов, например, таких, как
клапаны, поддержка IO-Link позволяет не только управлять ими, но и получать
информацию об их состоянии, что позволяет своевременно выявлять и устранять
возможные проблемы в работе оборудования. Одними из первых устройств, которые
были подключены с поддержкой IO-Link, стали интеллектуальные клапаны от
компании Alfa Laval. При использовании протокола IO-Link в проектах
используются типовые модули ввода/вывода. Далее были интегрированы пневмоострова
с поддержкой IO-Link — это позволило значительно упростить управление
пневматическими устройствами, уменьшить габариты шкафов управления и
соответственно итоговую стоимость проектов.

В 2021 году Phoenix Contact представил новую линейку модулей ввода-вывода
Axioline Smart Elements. Ключевой особенностью этих модулей являлся новый
дизайн очень компактного форм-фактора, который позволял значительно экономить
пространство в шкафах управления. Эти модули поддерживали широкий спектр
интерфейсов и протоколов.

Также в 2019 году разработка проектов была перенесена на GitHub, что
позволило улучшить управление версиями и обеспечить более эффективное
сотрудничество между разработчиками. В настоящее время проекты разрабатываются с
использованием современных инструментов для управления версиями, таких как Git,
что позволяет эффективно отслеживать изменения в коде и обеспечивать высокое
качество проектов.

Основные открытые проекты:
ptusa_main ^[13] — главная
управляющая программа и
EasyEPLANner ^[14] — модуль для
EPLAN для упрощения работы с проектами для использования инженерами по
автоматизации.

Модуль EasyEPLANner позволяет инженерам по автоматизации, которые не
являются профессиональными программистами, легко создавать проекты в EPLAN и
интегрировать их с существующими системами на предприятии. Этот модуль
обеспечивает описание в виде, которое основывается на международном стандарте
ISA‑88 ^[15]. Он определяет модели и терминологию для
описания производственных процессов и систем управления, что позволяет создавать
проекты, которые легко поддерживать и расширять. Они описываются в виде набора
базовых объектов, которые могут быть легко связаны между собой для создания
сложных систем. Это позволяет инженерам по автоматизации быстро разрабатывать и
легко вносить изменения при необходимости, что обеспечивает конкурентное
преимущество в возможности безостановочного запуска новых проектов. Работа над
ним началась в 2014 году — он вобрал лучшие наработки и подходы. Изначально, в
первых проектах, уже было разделение — инженер по автоматизации в Excel
описывал операции (например, где какие клапаны открываются/закрываются и т.п.),
потом это переносилось в управляющую программу (на уровне С++ кода). Это
было не очень удобно — было много версий управляющей программы, которые
отличались только данным описанием устройств. Далее это описание было выделено в
отдельный внешний файл, который создавался в отдельном редакторе и потом
записывался в контроллер. Управляющая программа стала типовой. Описание
изначально было в бинарном виде, потом была текстовая версия, далее стал
использоваться Lua и описание стало скриптом на данном языке. Формат
описания также постоянно дорабатывался и усложнялся — сейчас есть богатый
базовый набор типовых классов, описывающих основные элементы проекта — ёмкости
(танки), агрегаты (узлы перемешивания, нагрева, …), операции технологического
процесса (наполнение, выдача, …), исполнительные механизмы (клапаны, насосы,
…) и датчики (температуры, давления, …). Инженер по автоматизации может
очень быстро разработать проект, который раньше требовал гораздо больше времени.

С 2022 года началось внедрение современного протокола OPC UA ^[16]. Данный
протокол является в настоящее время стандартом для обмена данными между
системами автоматизации и обеспечивает высокий уровень безопасности и
надёжности. В настоящее время данный протокол используется для обеспечения
передачи данных от контроллеров к серверу SCADA-системы. Интеграция основывается
на открытом проекте open62541 ^[17]
(официальный сайт: open62541.org ^[18]).

Активно внедряются технологии искусственного интеллекта ^[19] и машинного обучения для
оптимизации производственных процессов, предиктивного обслуживания и улучшения
качества продукции. Изучается возможность их использования непосредственно на
контроллерах, что позволит создавать более интеллектуальные и автономные системы
управления. Платформа AXC F ML 1000 от Phoenix Contact поддерживает
возможности ИИ и машинного обучения, что открывает новые возможности для
оптимизации производственных процессов и повышения эффективности предприятия в
целом.

Описание применяемого подхода к разработке на примере управляющей программы

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

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

На рисунке выше показан алгоритм работы (в Drakon ^[20]
diagram language) управляющей программы. С одной стороны, он довольно прост и
понятен, с другой стороны, он обеспечивает высокую гибкость и расширяемость, что
позволяет легко адаптировать его к различным требованиям и условиям работы.
Программа работает в цикле, который выполняется с определённой периодичностью
(например, каждые 100 мс). Время цикла зависит от конкретного проекта и
используемого оборудования. Программа должна работать в режиме реального времени
24 часа в сутки, 7 дней в неделю, 365 дней в году, что требует очень высокой
надёжности. При этом должен быть обеспечен механизм для непрерывного обновления
и улучшения программы, что позволяет адаптироваться к изменяющимся требованиям и
условиям работы предприятия.

Используемые современные технологии и инструменты

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

• C++

  • Стандарт C++17, в текущем (2026) году планируется переход на C++20

  • Основная среда разработки — Visual Studio Community 2026

  • Универсальная легковесная среда разработки — Visual Studio Code

• Lua ^[21]

  • Версия 5.1, в текущем (2026) году планируется переход на Lua 5.5

  • Различные модули из сообщества lunarmodules ^[22]

• Технологии платформы GitHub ^[23]

  • GitHub Actions

  • GitHub Copilot

• CMake ^[24]

  • Modern CMake (4.0+)

  • CMakePresets.json

• Модули, используемые как git-submodules

  • tolua++, zlib, open62541, subhook, googletest, google-benchmark, fmt, cxxopts

• Сервисы

  • app.codecov.io ^[25], sonarcloud.io ^[26], codacy.com ^[27]

Для сборки и тестирования используется современный CMake с поддержкой
CMakePresets.json для воспроизводимых конфигураций и интеграции в CI.

Lua — лёгкий встраиваемый язык скриптов — используется для описания
конфигурации проектов, выполнения пользовательских сценариев и т.д.

Краткое описание используемых модулей:

• tolua++ ^[28] — генератор связывания C/C++ → Lua ^[21] — автоматически создаёт обёртки API для вызова из скриптов.

• zlib ^[29] — библиотека сжатия данных — используется для упаковки/распаковки сериализованных сообщений и логов.

• open62541 ^[17] — открытая реализация стека OPC UA — обеспечивает безопасный обмен данными между контроллерами и SCADA.

• subhook ^[30] — простая библиотека для перехвата функций — применяется в тестах и инструментах для мониторинга вызовов.

• googletest ^[31] — фреймворк модульного тестирования.

• google-benchmark ^[32] — библиотека для написания бенчмарков и измерения производительности.

• fmt ^[33] — современная библиотека форматирования строк — безопасная и быстрая альтернатива printf/ostringstream.

• cxxopts ^[34] — лёгкий парсер аргументов командной строки для C++.

Активно используются облачные сервисы качества кода и метрик:
Codecov ^[25] (покрытие тестов) и
SonarQube ^[26], Codacy ^[27]
(статический анализ).

Заключение

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