Канал Открытые системы автоматизации 🕘 история названий (1)

Опрос: «Потребность в импорте/экспорте PLCopenXML» Коллеги из IEK GROUP приглашают принять участие в опросе: "Мы развиваем импорт и экспорт в формате PLCopenXML зная, что это технологически обоснованный выбор. В MasterSCADA 4D есть встроенная возможность импортировать файлы в формате PLCOpen XML, подробнее здесь 👉 https://support.mps-soft.ru/Help-web/index.html?-plcopenxml.html Почему это важно: ✅экономия времени ✅снижение рисков ✅гибкость архитектуры Стандарт PLCopenXML играет важную роль для инициативы «Открытая АСУТП», помогая реализовать её основную цель: создать открытую экосистему промышленной автоматизации в России. Благодаря этому организации могут свободно менять поставщиков оборудования и ПО, оперативно заменять компоненты промышленной автоматизации и формировать оптимальные конфигурации из доступных решений. PLCopenXML позволяет реализовать переносимость прикладного программного обеспечения между ПЛК различных вендоров. Кроме того, PLCopenXML ускоряет разработку отечественных решений и способствует формированию единой экосистемы: даёт возможность использовать готовые библиотеки функциональных блоков, повторно применять код при переходе на новые платформы, создавать открытые репозитории типовых алгоритмов управления и проектов. В итоге внедрение PLCopenXML помогает «Открытой АСУТП» строить масштабируемые, гибкие и надёжные системы автоматизации, конкурентоспособные на глобальном рынке. Помогите нам стать лучше! Чтобы сделать инструменты обмена максимально удобными для инженеров АСУ ТП и руководителей проектов, нам необходимо понять ваши реальные рабочие задачи. Мы хотим развивать функции импорта и экспорта с учетом ваших потребностей. Пройдите короткий опрос (займет менее 5 минут): https://forms.yandex.ru/cloud/6a2fd521eb6146aa2e25383b/ Ваш голос повлияет на дальнейшую разработку наших продуктов. Спасибо за вклад в развитие открытых стандартов в отечественной автоматизации!"

Ильяс Киреев, Positive Technologies: Финансовая модель технологического суверенитета ТЭК и экономика киберустойчивости Цифровая трансформация российского топливно-энергетического комплекса (ТЭК) сталкивается с серьезными финансовыми барьерами, включая высокие процентные ставки и ограниченные бюджеты. В ответ на эти вызовы лидер кибербезопасности Positive Technologies разработал и представил рынку новую финансовую модель, получившую название «триангуляция финансирования». При ее создании авторы проанализировали и адаптировали под российские экономические реалии международный опыт реализации сложных ESG-проектов других стран. Главными драйверами изменений в России выступают сегодня требования регулятора по переходу на отечественные доверенные программно-аппаратные комплексы (ПАК), включающие российское железо, общесистемный, прикладной индустриальный софт и встроенную кибербезопасность. Суть новой финансовой модели заключается в преодолении текущих законодательных ограничений, которые не позволяют крупному бизнесу суммировать меры поддержки. Она предполагает объединение в рамках одного сквозного контракта механизмов специального инвестиционного контракта (СПИК 3.0), федеральных и региональных инвестиционных налоговых вычетов, а также инструментов ускоренной амортизации. Рабочая группа уже заручилась поддержкой некоторых отечественных вендоров и вступила в переговоры с ведущими банками и государством. Механизм кредитной линии выглядит следующим образом: рыночная стоимость кредита снижается за счет взносов из маржи самих производителей ПО и оборудования, благодаря чему предприятия ТЭК получают столь необходимое выгодное кредитное плечо для возобновления проектов цифровой трансформации. Кредит структурируется между участниками СПИК 3.0. Главным же условием и критерием эффективности внедрения таких доверенных ПАК со стороны государства и вендоров Ильяс назвал обязательный вывод критических процессов предприятий на кибериспытания для подтверждения их реальной киберустойчивости. Статья по итогам сессии на ЦИПРе 2026

Игорь Ведёхин: Хардверный фундамент НППА и создание испытательных полигонов Игорь Ведёхин, генеральный директор Группы Rubytech, принял участие в сессии Минпромторга «Создание Национальной платформы промышленной автоматизации (НППА). От распределенных стендов к промышленной экосистеме». Свое выступление он посвятил теме полигона как единой площадке для валидации ИТ-продуктов и решений. Спикер отметил, что в рамках участия в рабочей группе по созданию НППА Группа Rubytech представляет свои инфраструктурные решения (например, программно-аппаратные комплексы Скала^р), добивается слаженной работы софтверного и хардверного слоя, предоставляя основу для всего прикладного слоя программного обеспечения. Компания предлагает внедрить в промышленной сфере подход к тестированию технологических решений, который уже доказал свою эффективность в финансовом секторе, уточнил Ведёхин. Ранее при координации Банка России был создан индустриальный полигон ИЦК «Финансы». На площадке протестировали технологический стек для банковских организаций — систему проверили под реальными нагрузками и в рамках разнообразных сценариев. К тестированию привлекали самих заказчиков, а результаты были публичными. Теперь компания предлагает применить тот же подход в промышленности. «Создание такого полноценного большого полигона для тестирования — это актуальная и необходимая история, чтобы реально дать потребителям ощущение того, что они покупают не кота в мешке, а проверенные решения, надёжные, достойные того, чтобы быть имплементированными в реальный продуктивный контур», — отметил эксперт. Подобная инициатива, по оценке эксперта, позволит заказчикам быть увереннее в приобретаемых решениях. Статья по итогам сессии на ЦИПРе 2026

Антон Думин: демократизация ИТ-инструментов в промышленной автоматизации и концепция доверенной витрины для промышленных заказчиков ИТ-директор «Газпром нефти» Антон Думин на конференции ЦИПР 2026 напомнил, что работа по развитию открытых стандартов в компании стартовала еще в 2019 году. За прошедшие годы их цели претерпели серьезную трансформацию. Если на первом этапе ключевой задачей виделся уход от проприетарных систем и получение возможности собирать сложные инструменты управления (АСУ ТП, РСУ, СУУТП) из совместимых российских компонентов «как из кубиков LEGO», то сегодня «Газпром нефть» рассматривает компоненты национальной платформы как способ тотальной демократизации технологий. По сути, происходит спуск классических ИТ-инструментов на уровень промышленной автоматизации и технологических сетей передачи данных. Антон подчеркнул, что этот шаг открывает масштабные перспективы: появление открытых стандартов позволяет перенести новые технологии непосредственно на уровень АСУ ТП. Это необходимо для решения задач сложной многокритериальной оптимизации технологических режимов и оркестрации взаимодействия оборудования на основе моделей, минуя жесткие и ограниченные классические алгоритмы Статья по итогам сессии на ЦИПРе 2026

🇷🇺 Василий Шпак: «От Национальной платформы промышленной автоматизации — к Национальной платформе промышленных данных» Заместитель министра промышленности и торговли РФ Василий Шпак на конференции ЦИПР 2026 задал вектор дальнейшего развития инициативе по созданию НППА для российской промышленности. Начиная доклад, он констатировал, что за прошедший год рабочая группа проделала большую работу и совершила качественный переход от обсуждения разрозненных инициатив к проектированию полноценной Национальной платформы промышленной автоматизации (НППА). Шпак особо подчеркнул, что тот факт, что Председатель Правительства на пленарной сессии упоминает Открытую АСУ ТП как свершившийся факт, доказывает зрелость движения. Стратегическая позиция Минпромторга как регулятора заключается в следующем: Россия должна создавать собственную, устремленную в будущее открытую архитектуру, а не заниматься простым копированием или воспроизведением старых зарубежных систем. Прямо в ходе выступления Василий Шпак провозгласил лозунг следующего технологического цикла развития инициативы: «От Национальной платформы промышленной автоматизации – к Национальной платформе промышленных данных». Шпак пояснил логику этого перехода: сама по себе автоматизация – это лишь инструмент, позволяющий собирать информацию. Главная же ценность нового этапа лежит в плоскости работы с данными, на базе которых будут обучаться модели искусственного интеллекта, способные приносить бизнесу прямую экономическую выгоду, сокращать издержки и повышать эффективность. Отдельно Василий Шпак остановился на кадровом дефиците, отметив, что решения на открытой архитектуре на рынке уже появляются, а людей, способных их эксплуатировать, критически не хватает. Он призвал тиражировать лучшие образовательные практики, упомянув совместную магистерскую программу «Газпром нефти» и профильных вузов. В финале своего выступления Василий Шпак перешел к конкретным организационным шагам и озвучил два поручения: Закрепить персональную ответственность компаний за разработку приоритетных необходимых стандартов открытой АСУ ТП как со стороны потребителей, так и со стороны производителей программно-аппаратных комплексов. Разработать и согласовать Открытый меморандум между участниками рабочей группы – ключевыми заказчиками решений промышленной автоматизации. Документ должен юридически закрепить готовность сторон пилотировать и апробировать модули и компоненты Открытой АСУ ТП на своих реальных производственных объектах. Данный меморандум планируется официально подписать на Координационном совете по промышленности.

Итоги сессии по Открытой АСУ ТП на ЦИПР 2026 Опубликована (не прошло и месяца) статья по итогам дискуссии конференции ЦИПР 2026, посвященной Национальной платформе промышленной автоматизации (НППА). В обсуждении участвовали Минпромторг, крупные заказчики («Газпром нефть», «Транснефть», «ЕвроХим», «Северсталь», «Уралхим») и разработчики. Главные тезисы и решения: Планы на 2026 год: Рабочая группа должна показать первую итерацию доверенного репозитория, витрины программных продуктов и концепцию системы добровольной сертификации. Поручения Минпромторга: Ведомство поручило закрепить персональную ответственность компаний за разработку стандартов и подготовить Открытый меморандум заказчиков о готовности тестировать модули Открытой АСУ ТП. Запросы бизнеса: Производственникам нужны не абстрактные технологии, а полигоны для тестирования («чтобы не покупать кота в мешке»), понятные механизмы снижения рисков и государственные стимулы (налоговые вычеты, льготные кредиты).

Как экономия памяти в ПЛК породила современную софтверную автоматизацию По материалу Beyond the hardware tree: structured tags and AOIs redefine PLC programming Иногда полезно оглянуться назад, чтобы заметить тектонические сдвиги в архитектуре промышленных программ, которые сегодня воспринимаются как должное. Статья Рика Райса наглядно показывает, через какую эволюцию прошла логика управления и как код постепенно забирал приоритет у аппаратной части. 🧱Эпоха «тупых» блоков данных В период ранних полевых шин (DeviceNet, Profibus, старый Remote I/O) обмен данными с удаленным шасси или частотным преобразователем строился на передаче фиксированных пакетов памяти — жестких массивов слов (INT). Даже если удаленная корзина ввода-вывода была заполнена лишь на четверть, контроллер непрерывно гонял туда-обратно весь блок. Частотник управлялся строго по схеме: слово команд, слово частоты, слово статуса, слово обратной связи. Память ПЛК тратилась в огромных объемах просто на поддержание этих плоских массивов, что жестко ограничивало емкость и гибкость всей системы. Шаг первый: Рождение UDT и изоляция от адресов Переход к структурированным тегам (User-Defined Tags) во многом случился из-за дефицита памяти, но в корне изменил подход к проектированию. Возможность упаковать в одну 🖨структуру разнородные типы данных (Boolean, INT, REAL) оторвала логику от физических адресов регистров. Следом появились профили устройств — Add-on Profiles (AOP). Раньше, чтобы изменить рампу разгона на приводе или вытащить специфическую диагностику, инженеру приходилось либо запускать отдельное ПО от вендора, либо настраивать параметры вручную с лицевой панели устройства. Профили интегрировали эти данные напрямую в аппаратное дерево проекта контроллера. Шаг второй: Программа выходит за рамки «железного дерева» Главный посыл автора вынесен в заголовок: программирование ПЛК окончательно вышло «за рамки аппаратного дерева». Благодаря параметризируемым инструкциям (AOI) код перестал быть придатком конкретных клеммников и модулей. Современный подход позволяет создавать универсальные, автономные алгоритмы (например, комплексное управление конвейерной линией со встроенной логикой фильтрации датчиков и режимами энергосбережения), которые привязываются к физике процесса исключительно через входные и выходные параметры. Автоматизация прошла путь от обслуживания конкретных плат расширения к полноценной программной инженерии (Software Engineering), где софт живет по собственным архитектурным правилам, независимым от физической топологии распределенного ввода-вывода.

🧱 Иллюзия открытости: Что такое Gated Ecosystem и почему маркетплейсы ПЛК — это не OPA По мотивам материала Bill Lydon, Automation.com Когда мы говорим об открытой АСУ ТП, обычно представляется полярный мир: с одной стороны — тотально закрытые проприетарные DCS (РСУ), с другой — Linux, Codesys и чистый open-source. Но прямо сейчас на рынке ПЛК побеждает третья, модель — Gated Ecosystem (Охраняемая или управляемая экосистема). Крупные вендоры ПЛК давно поняли, что воевать с открытыми стандартами бессмысленно. Они охотно внедрили Ethernet/IP, MQTT, OPC UA и перевели контроллеры на Linux-ядра. Но вместо реальной открытости они создали аналог Apple App Store в промышленном масштабе. В чем суть концепции Gated Ecosystem? Вендор пускает сторонних разработчиков софта и модулей ввода-вывода в свою экосистему только после жесткого коммерческого аудита, лицензирования и выплаты роялти. Для конечного заказчика это выглядит как победа прогресса: в каталоге («маркетплейсе») автоматизатора появляются сотни готовых плагинов, библиотек и приложений от сторонних стартапов. Где здесь подвох для концепции Открытой АСУ ТП? Такая модель полностью блокирует две главные цели открытых систем: Multivendor code portability (Переносимость кода): Вы по-прежнему не можете безболезненно перенести написанный софт и логику на контроллер другого производителя. Вы привязаны к среде разработки и рантайму конкретного вендора. Hardware interchangeability (Взаимозаменяемость железа): Вы не можете «на горячую» заменить вышедший из строя контроллер аналогом от конкурента, даже если они оба работают на условном Linux. ⛓️ Современные «открытые» линейки контроллеров от мейджоров рынка — это не шаг к Open Process Automation. Это классическая «золотая клетка». Вендоры лишь упаковали старый проприетарный lock-in в красивую обертку из ИТ-терминов, сохранив полный контроль над маржой и привязкой клиента к платформе. Настоящая открытость начнется только там, где софт полностью отвязан от железа (hardware-independent), а не там, где к ПЛК можно подключить сторонний датчик по MQTT.

🌐 IT vs OT: Спор о границах и причем здесь Открытая АСУ ТП В экспертном сообществе разгорелась интересная заочная дискуссия. Статья на РБК утверждает: «Управление производством нельзя строить как ИТ-инфраструктуру», а слепое сближение IT (информационных технологий) и OT (технологических процессов/АСУ ТП) — это опасный путь. В то же время многие спикеры на дискуссии по открытой АСУ ТП на ЦИПР-2026 продвигали идею Открытой АСУ ТП, где конвергенция IT и OT — это уже свершившийся факт и драйвер эффективности. Кто же прав и где истина? 📌 В чем прав автор статьи на РБК? Автор справедливо указывает на фундаментальную разницу в ДНК двух систем: Приоритеты: Для ИТ главное — гибкость, скорость обновлений и масштабируемость. Для АСУ ТП — железная стабильность, предсказуемость и непрерывность. Цена ошибки: Падение корпоративной почты или CRM — это простой бизнеса. Сбой на уровне АСУ ТП — это потенциальная техногенная катастрофа, порча оборудования и угроза жизням. Архитектура: Идея «накатить быстрое обновление в пятницу вечером» в цеху не работает. Граница безопасности (в т.ч. кибербезопасности) между КСП (корпоративным сегментом) и ТП (технологическим) должна быть железобетонной. ❌ Что не так с аргументами автора? Главная ошибка автора — восприятие ИТ как чего-то застывшего в 2010-х годах. Он спорит со сближением IT и OT так, будто «сближение» означает простое подключение ПЛК (контроллеров) к офисному Wi-Fi. Но современное ИТ — это давно не просто «сервер в дата-центре»: ИТ научилось в отказоустойчивость. Современные ИТ-архитектуры (микросервисы, контейнеризация, Edge Computing) как раз созданы для распределенной работы с высочайшим уровнем надежности. Изоляция тормозит бизнес. Если полностью законсервировать OT в «башне из слоновой кости», предприятие теряет данные для предиктивной аналитики, ИИ, сквозного планирования и цифровых двойников. А без этого выиграть в конкурентной борьбе сегодня невозможно. 🤝 Как это соотносится с Открытой АСУ ТП? Концепция Открытой АСУ ТП, которую продвигает рабочая группа во главе Минпромторгом и крупнейшими промышленниками, — это и есть компромисс в этом споре. Открытая АСУ ТП не предлагает «строить производство как ИТ-инфраструктуру». Она предлагает взять лучшие ИТ-подходы и адаптировать их под жесткие требования OT: Уход от вендор-лока. Вместо закрытых монолитных систем (как ушедшие Siemens или Honeywell) внедряется модульный подход. ИТ-инструменты на службе OT. Перенос вычислений на уровень Edge (граничные вычисления), использование открытых ИТ-протоколов, виртуализация и контейнеризация, но внутри защищенного периметра автоматизации. Сохранение жестких требований к Real-Time. Открытая архитектура не отменяет детерминированность (работу в реальном времени) нижнего уровня управления. Конвергенция IT и OT — это не поглощение одного другим. Это эволюция, где OT берет от IT гибкость и открытые стандарты, но сохраняет свою главную ценность — безопасность и надежность.

Встречайте новый релиз MasterCAD – 1.7.0 В MasterCAD 1.7.0 добавлен новый функциональный блок – автоматизированный расчёт лицензий программного обеспечения MasterSCADA 4D и OPC-серверов. 💡Это решение закрывает потребность проектировщиков и интеграторов в точном определении комплектации ПО на этапе технического проектирования, исключая ручные ошибки и избыточные затраты. Для расчёта необходимо добавить подсистему верхнего уровня и сконфигурировать в ней установку типа «Сервер». При расчёте учитывается количество точек ввода-вывода, требуемые протоколы обмена данными, опции резервирования и другие параметры системы.   На выходе формируется спецификация оборудования и лицензий. Документ можно использовать в проектной документации – для согласования с заказчиком и прохождения экспертизы, как бюджетную оценку решения – для предварительного расчёта стоимости лицензий и подачи коммерческого предложения.   MasterCAD 1.7.0 – это первый шаг к полной автоматизации подбора программного обеспечения для систем диспетчеризации и АСУ ТП.   Функционал доступен всем пользователям MasterCAD. MasterCAD 1.7.0 превращает подбор лицензий из рутинной ручной задачи в автоматизированный процесс, состав лицензий соответствует техническим требованиям проекта и оформлен по государственным стандартам – без лишних затрат и времени на пересогласование.   Подробнее о новом функционале расскажем на нашем вебинаре 🗓 3 июня в 10.00 (МСК)   Пройдите ❓опрос❓ и мы включим дополнительные темы в рассказ и демонстрацию.   Присоединяйтесь 👉 https://my.mts-link.ru/j/iek/MasterCAD_1_7_0!     #документация #проектирование #АСУТП #IEK_DIGITAL #MasterCAD