Решил написать свой первый настоящий пост на Пикабу. Даже не представлял, как получается написать такие объёмные тексты. Но тут товарищ прислал одну статейку про новых программистов и реальную автоматизацию на заводах))) И тут вспышка 📸, ничего не помню и выходит текст из памяти!) Добро пожаловать под кат!)
Приходит как-то молодой IT-специалист со свежим стеком из Docker’ов, микросервисов и К8s на завод. В цеху сверкают панели управления, гудят моторы, а он пытается подключиться к этому промышленному добру. И, внезапно (нет), оказывается, что привычный IT-стек здесь не работает — у заводчан свои протоколы, свои легенды и свои правила. Годами. Десятилетиями. Из уст в уста, от конунга к сыну и т. д. и т. п. Айтишник достаёт ноутбук, спрашивает, какая тут точка доступа, а в ответ — тишина. Только матёрый усатый автоматчик (спец по работе с автоматизированными системами на заводах) медленно поднимает глаза, откашливается и с лёгкой тоской в голосе говорит: — Тут, сынок, Modbus по RS-485. Без TLS. Без DHCP. И если что, мы это на Delphi писали, в 2004-м. И это ещё повезло, что на Delphi в 2004-м :) А могло быть написанно в другой стране (году этак в 1990-м) на паскале или фортране. Так и живут некоторые заводы, где вместо YAML — скрипты на паскале, вместо DevOps — старая добрая флешка с патчами, а вместо облачных масштабируемых серверов — шкаф с вентиляцией (в лучшем случае) и приклеенным на скотч листом: «Работает — не трожь!»
Шёл 2011 год. У меня на первом заводе, где тогда работал, была 3-зонная методическая печь по нагреву металла, автоматизирована какими-то ПЛК (я тогда ещё слова такого не знал), программа была написана на Pascal. Помню, приехал программист делать доработки. Мы, молодые КИПовцы, специально остались, задержались (нас мастер уговорил, мол, посмотрите, учитесь). Он строки переписывает, меняет какие-то цифры (теперь уже знаю, что это были коэффициенты ПИД), и оно оживает (горелки переходят в другой режим работы) и начинает работать по-другому. Скада, если её можно так назвать (им же нарисована в каком-то редакторе), меняет форму, изменяет значения. Но🫣 тут же ниже на этом шкафу стоит 3 переключателя на 3 положения с фиксацией (вроде бы кулачковых) и ещё 3 обычных 3-позиционных без фиксации. Первые изменяют источник задания на газовые заслонки (1 — ПЛК, 2 — ручное управление, 3 — ещё одно🙂). Программист заканчивает настройку, говорит: «У вас будет всё хорошо». Уходит. Нашему мастеру категорически не понравилось, как работает регулирование. И как только программист уходит, переводит эти кулачковые переклички в то самое 3е положение. И горелками начинает управлять что? Правильно! Старые добрые КСП3 с круговыми диаграммами, которые мы меняли каждые 24 часа))) Говорит, так будет лучше, и уходит, говоря: «Собирайтесь домой». Мы ещё задерживаемся минут на 10 в этом помещении. Всё это время с нами был «печник», который следит за режимом работы печи. Тот, что был на смене, тут же, как наш мастер вышел, переводит кулачковые переключатели в какое положение?) Правильно! В ручное!)😂 И говорит: «Так будет надёжнее!) 😁».
Вот тебе и стеки и TLS и DHCP и 485. А подача 220 на МЭО импульсами надёжнее для конечного пользователя)) ☝️ Но это ещё не всё. Печники, когда лень идти в помещение с этим щитом управления, просто подходят к МЭО и что? Тоже правильно! Просто крутят его с помощью маховика))) Вот тебе и автоматизация)))💡 МЭО было примерно как на фото) Ну и схематически печь)
Open Platform Communications United Architecture (OPC UA) – это стандарт обмена данными, используемый в промышленной автоматизации и связи. OPC UA – это независимый стандарт, не связанный с конкретной системой или производителем, он осуществляет связь посредством связи компьютер-машина или связи машина-машина. Предлагаем статью инженера Энтони Кинг Хо, опубликованную в журнале Control Automation, посвященную истории, структуре и применении протокола OPC UA.
История создания OPC UA
В 1994 году группа поставщиков программного и аппаратного обеспечения в секторе промышленной автоматизации и других инженерных дисциплинах сформировала то, что сейчас известно, как OPC Foundation.
OPC Foundation поставила себе целью разработать единую спецификацию клиент/сервер, которая позволила бы любому поставщику разрабатывать программное обеспечение и приложения, способные обмениваться данными быстрым и надежным способом. И в то же время устранить проприетарные схемы, из-за которых эти поставщики дублировали свои усилия по разработке.
В результате сообщество OPC Foundation разработало первую спецификацию для OPC DA, Data Access Specification 1.0a. Она была выпущена вскоре после этого, в начале 1996 года. Стандарт Data Access Specification определяет, как должны быть построены интерфейсы клиентского и серверного приложений. Используя эту спецификацию, поставщики могли быстро разрабатывать клиентское/серверное программное обеспечение.
Как работает OPC UA?
Однако, поскольку OPC DA в значительной степени опирается на Windows Distributed Component Object Model (DCOM), многие поставщики признают, что OPC DA не является по-настоящему открытым стандартом, плохо ведет себя в отключенном состоянии, плохо работает с брандмауэрами и работает только в Windows.
Чтобы преодолеть недостатки OPC DA, OPC Foundation разработал OPC UA, который значительно отличался от своего предшественника. Цель состояла в том, чтобы отойти от использования Windows DCOM в основном для лучшего удовлетворения меняющихся потребностей промышленной автоматизации.
Первая спецификация OPC UA была опубликована в 2006 году, а последняя версия, 1.04, была выпущена в ноябре 2017 года, добавив инфраструктуру связи публикации/подписки и новые политики безопасности.
Некоторые из улучшений, которые были введены в OPC UA, включают:
Открытость – доступен для использования и внедрения любым пользователем по лицензии GPL 2.0;
Кроссплатформенность – не привязан к одной операционной системе или языку программирования;
Повышенная безопасность протокола – предоставляет пользователям доступ к аутентификации, авторизации, целостности и конфиденциальности;
Введение метода, который представляет вызов функции объекта – метод вызывается (вызывается) и возвращается после завершения функции, независимо от того, была ли она успешной или нет;
Интеграция информационной модели в IEC 62541 – эта спецификация является основой инфраструктуры, необходимой поставщикам для интеграции своей информации и моделирования своих сложных данных в пространстве имен OPC UA. Она использует преимущества богатой сервис-ориентированной архитектуры OPC UA.
Структура OPC UA (IEC 62541)
Расширения полей, указанные в инициативе Field Level Communication (FLC), основаны на структуре OPC UA (IEC 62541). Эта структура предоставляет поставщикам независимую платформу, которая обеспечивает безопасный и надежный обмен информацией.
Архитектура системы OPC UA FLC
Структура OPC UA поддерживает службы и протоколы клиент/сервер, а также модели и протоколы публикации/подписки (PubSub). OPC UA может работать на выделенных клиент/серверных отношениях. В сценарии PubSub сервер отправляет (публикует) данные в сеть, а клиент (подписавшийся) получает данные.
Важно отметить, что в спецификации OPC UA аутентификация, подписание и шифрование данных в значительной степени подчеркиваются как для моделей клиент/сервер, так и для моделей PubSub.
Роль OPC UA в промышленной автоматизации
Помимо того, что OPC UA является протоколом связи между машинами для промышленной автоматизации, он также является идеальным кандидатом для соединения машин и бизнес-сетей. OPC UA не только передает информацию о машинах, такую как заданные значения, измеренные значения и параметры процесса, но также определяет и описывает данные. Это делается с помощью сопоставлений в спецификации OPC UA.
С информационной моделью OPC UA новые процессы между ПЛК и любым более высоким уровнем, ориентированным на бизнес-ориентированный уровень программного обеспечения, могут быть установлены очень эффективно.
OPC UA в системе автоматизации
В промышленном процессе заданные значения и управляющие переменные можно легко и централизованно поддерживать, а также контролировать как часть основных данных материалов. Даже информацию, специфичную для заказа клиента, можно напрямую обменивать с ПЛК вместо копирования данных на разных уровнях программного обеспечения.
Кроме того, предоставление данных об измерениях и процессах в качестве улучшения бизнес-документов для комплексной аналитики также является простой задачей, поскольку подключение стандартизировано.
С появлением Industry 4.0 разделение уровней и подход «сверху вниз» к потоку информации начали смешиваться, что означает, что в интеллектуальной сети каждое устройство или служба могут автономно инициировать связь с другими службами.
PLCopen (ассоциация производителей контроллеров на основе IEC 61131-3) сотрудничала с OPC Foundation для определения соответствующих функциональных блоков клиента OPC UA. Она создала способ для PLC обмениваться сложными структурами данных по горизонтали с другими контроллерами или по вертикали через сервер OPC UA в системе управления производством (MES) или планирования ресурсов предприятия (ERP) для получения новых производственных заказов или записи данных в облако. Эти усилия позволили производственной линии работать автономно в сочетании с интегрированной безопасностью OPC UA.
Отрасли по всему миру внедрили вертикальную интеграцию с использованием OPC UA. Каждый компонент в промышленном процессе, такой как контроллер, датчик, робот, камера и измерительное устройство, служит независимым машинным блоком, каждый из которых одновременно служит сервером OPC UA и клиентом OPC UA.
Следовательно, каждый машинный блок может использовать методы, события или точки данных OPC UA, которые публикуют его режимы, атрибуты и функциональные возможности и предлагают себя в качестве услуги.
Industry 4.0 и OPC UA
Как упоминалось ранее, с Industry 4.0 и промышленным Интернетом вещей (IIoT) информация может свободно передаваться между различными устройствами в интеллектуальной сети. Это создало серьезную проблему для безопасного и стандартизированного обмена данными и информацией.
В 2015 году модель эталонной архитектуры для Industry 4.0 (RAMI 4.0) рекомендовала только стандарт IEC 62541 OPC UA для реализации уровня связи. В результате любой продукт, рекламируемый как «с поддержкой Industry 4.0», должен поддерживать OPC UA – интегрированный или через шлюз.
В модели клиент/сервер обычно используются TCP и HTTPS. В модели PubSub используются UDP, AMQP и MQTT.
Схема работы OPC UA
Стоит отметить, что OPC UA также реализован в чипах, небольших устройствах и датчиках. Помимо использования на производстве, приложения OPC UA уже развернуты в других областях, например, в коммерческом кухонном оборудовании, таком как фритюрницы, духовки, кофемашины и посудомоечные машины.
Планы развития OPC UA
Транзакции
С ростом популярности OPC UA во многих отраслях OPC UA является хорошим кандидатом для настройки. Простые задачи настройки можно решить с помощью методов, для более сложных процессов потребуются транзакции.
Метаданные в облаке
Когда данные публикуются в облачных приложениях, таких как Amazon Web Services (AWS) и Google Cloud, данные обычно не включают метаинформацию в адресном пространстве сервера. Метаданные помогут решить эту проблему в будущем.
Cloud Relay
Возможность облачной ретрансляции позволяет устанавливать связь между различными приложениями OPC UA, даже если и сервер, и клиент находятся за отдельными брандмауэрами.
Детерминированная связь
В текущем и прошлых поколениях связи связь не является детерминированной. С 5G, 5-м поколением беспроводных систем, она обеспечит лучшую производительность и детерминированность. Она будет похожа на Time Sensitive Networking (TSN), сопоставление модели PubSub с протоколом 5G сделает OPC UA более детерминированным.
Дополнительные сопоставления протоколов для детерминированной связи
В дополнение к 5G сопоставления с WiFi 6/7 могут сделать протокол детерминированным для беспроводных и мобильных промышленных приложений. Кроме того, сопоставление с сетевыми технологиями уровня 3 с поддержкой QoS (качество обслуживания) должно обеспечить детерминированную связь OPC UA, бесшовно маршрутизируемую по проводным и беспроводным сегментам сети.
Точно предсказать развитие OPC UA предсказать трудно, но похоже у данного протокола коммуникации есть большой потенциал.
Материал подготовлен Московским заводом тепловой автоматики (МЗТА)
Продолжаем рассказ Михаила Непомнина – в прошлом начальника КБ автоматизации ЭПО «Сигнал» о предшественниках программируемых логических контроллерах (ПЛК). Сегодня коснемся АРМов – автоматизированных рабочих мест и периферии, предназначенных для автоматизированной поверки датчиков.
Если присмотреться, то наше устройство можно назвать прибором АСУ ТП. Почему мы так не сделали? Дело новое, поэтому выбрали название АРМ, которое показалось нам очень звучным. Что касается конкретики, то мы использовали АРМы для поверки датчиков давления и температуры. Мы начали ставить образцовые приборы по давлению на каждый коллектор, а датчики температуры на каждую камеру тепла-холода. На нижеприведенной структурной схеме они не показаны, дабы ее не перегружать.
Структурная схема АРМ
Пояснения: Для индуктивных датчиков ставился специализированный блок питания. Потенциометрические же датчики запитывались от источника питания ГН09-01 из состава АРМ. На схеме он не указан, чтобы не перегружать схему и не показывать, что вольтметр питается от 220В переменного тока, а ГН 09-01 подключается к питающему напряжению через сетевой фильтр для борьбы с помехами. Не показан и выносной пульт, который дублировал кнопку на клавиатуре, которая запускала отсчет показаний коллектора. Ведь у нас не строго техническая документация, а рассказ о первом применении контроллеров на нашем предприятии больше 35 лет назад.
Еще опишем коллекторы. Это оснастка, с помощью которой давление подавалось сразу на 16 датчиков одного типа или 18 датчиков другого типа. А потом по очереди переключая ручной коммутатор выход датчика переключался на вход цифрового вольтметра.
В случае АРМа плата коммутации был автоматической и управлялась контроллером. В автомате плата связи с вольтметром первоначально программировала вольтметр на нужный режим работы и предел измерений, а также начинала замер показаний конкретного датчика сигналом «Пуск». Делалось это все под управлением контроллера.
Ход работы АРМа
Мы провели подготовительные операции, то есть прикрутили коллектор к цеховой магистрали давления, жгутом подключили датчики к АРМу включая питание датчиков и прогрели в течении 15 мин оборудование. Теперь мы отсчитываем нулевую точку давления. Нулевая точка – это когда давления нет (или оно атмосферное). Но лезть в дебри разницы между абсолютным и избыточным давлением нам не стоит. Тема статьи не об этом.
Я вспоминаю, как у меня один специалист по продажам просил объяснить разницу между избыточным и абсолютным давлением. Попробовал объяснить. Но сколько я ни бился, он ничего так и не понял. Наверное, я плохо объяснял.
Итак, ход работы:
Датчики в этом АРМе шифровались условными номерами. В следующих вариантах АРМа мы осуществляли ввод уже заводских номеров датчиков. Не забывайте. Это всего лишь 80 годы прошлого века. Точки с бракованными показаниями датчиков выделялись жирным шрифтом. Вот пример протокола проверки:
Таблица протокола поверки
Бракованный – датчик № 6 на нулевой точке прямого хода и датчик №2 на точке 60 кгс/м2. Брак погрешности отмечен в протоколе, но вариация в норме. Там показания жирным шрифтом нет. Вот как работает АРМ вкратце. Можно было назвать установку АСУ ТП, но мы постеснялись без автоматической подачи давления и автоматической записи заводских номеров. А когда сделали – про название АСУ ТП забыли. Так у нас на предприятии такое оборудование собственной разработки называют до сих пор АРМ.
Преимущество АРМа перед ручной поверкой
Сокращение количества персонала.
Уменьшение влияния человеческого фактора.
Объективный контроль.
Пункты 2 и 3 можно было бы объединить, но я их специально разделил. Человеческий фактор будем считать за случайные ошибки человека, а объективный контроль будет подразумевать намеренное действие персонала, стремящееся выдать некондиционный прибор за кондиционный.
Персонал, он конечно тоже не из дураков состоит. Заведомо бракованный прибор он проталкивать как годный не будет. Себе дороже в конце выйдет. А вот прибор почти бракованный (90% допуска) выдать за вполне годный (70 – 80 % допуска) – это рабочие умели. Или на потоке проверяли эту точку по давлению или подавали меньшее давление, а сообщали товарищу, который записывал данные в протокол заведомо большее значение. Магия цифр, так сказать. Или ловкость рук. Опытный работник знал много таких бандитских приемов, как из почти брака сделать якобы идеальный датчик.
Ниже АРМ, похожий на наш. Только более элегантный. У наших АРМов каркас был собран из серьезного стального уголка. Наверное, чтобы выдерживать ядерный взрыв. Ну это не программисты, а конструкторы из самого ОМА (отдел механизации и автоматизации) постарались.
Аналог нашего АРМ, только без принтера
Наш АРМ, вернее, наши АРМы, поскольку их было у одного центрального процессора несколько. По нескольку штук на морозе, тепле и при нормальных условиях. Мороз, тепло и нормальные условия – это климатические условия, в которых проверялись датчики.
Мороз и тепло обеспечивались большими климатическими камерами. Нормальные условия обеспечивались цеховым климат-контролем. Четверть площади цеха было отведено под вентиляционное и холодильное оборудование, которое и держало температуру зимой и летом на уровне 18 °C. Летом в цех заходить было приятно. На улице жара, а в цехе приятная и комфортная атмосфера. Даже первую минуту холодно казалось. Но потом отпускало.
А когда я еще работал в цехе регулировщиком РЭА, надо было оставаться в 3-ю смену термоциклировать приборы. Так в 3 часа ночи приходилось верхнюю одежду одевать. Включался этот самый климат-контроль и холодный воздух стал продувать весь цех. Температура не более 10 градусов и сильный сквозняк. Лучше в шубе и шапки переждать подготовку климата в цехе к рабочему дню. Вот такие случаи случались со мной, когда я работал в цехе.
А в конце статьи мне вспоминается принтер. Хороший принтер, хорошо работал. Жаль эти принтеры скоро заменили капиталистические Эпсоны. Этой страны уже нет. Я имею в виду ГДР. А принтеры Роботрон до сих пор вспоминают. Всех форматов. От А4 до А1 или А0. Уж не помню, как самый большой размер назывался.
Печатающее устройство Robotron CM 6329.02 M
У нас большие Роботроны в ИВЦ стояли, какие-то отчеты печатали. А работники ИВЦ воображали перед нами, что они самые умные из программистов. Не нам работникам ОМА чета. Хотя это было не так. Мы знали больше ИВЦ-шниц.
Вот на такой оптимистической ноте позвольте закончить свой рассказ про первый АРМ или АСУ ТП на нашем предприятии.
А в самом конце приведу копию отчета проверки потенциометрических датчиков. У него индивидуальная характеристика. Поэтому вместо графы «Погрешность» есть графа «Размах». Это разница между максимальной и минимальной величиной показаний датчиков.
Протокол поверки датчиков
Но конверсия прекратила деятельность КБ. Нас в нем из 12 человек осталось 2. И вместо автоматизации специальных датчиков давления, мы разработали АРМ, дожидаясь гражданской продукции – бытовых счетчиков газа.
Предшественники ПЛК – К1-20, МС2102
Предлагаем также ознакомиться с предыдущей статьей Михаила Непомнина: "Предшественники ПЛК – К1-20, МС2102 – история создания первых отечественных АРМов".
---
Материал подготовлен в партнерстве с Московским заводом тепловой автоматики.
Бывают задачи, когда нужно последовательно подвигать механизм вверх-вниз или влево-вправо (Например механизм протруски в прессе). Или движения тележки.
В LD программе есть научное название такой схемы - называется мультивибратор.
Реализация для ПЛК Delta.
Ставим два таймера, один с замкнутым выходом, другой с разомкнутым. Данный пример отображает работу гидравлического механизма с двумя катушками Y21 и Y22.
В параметре D2001 выставляете необходимую задержку времени. Этот же параметр можно вывести на панель оператора, любую, где есть драйвер этого ПЛК.
- ПЛК останется основной платформой автоматизации, обеспечивая реализацию главной цели – надежное управление и контроль полевых устройств в сложных условиях эксплуатации.
- Основные компоненты ПЛК, такие как процессор, память и другие будут совершенствоваться – будет происходить уменьшение размеров, энергопотребления и стоимости, с одновременным увеличением производительности.
- Тенденция к миниатюризации останется, но будет не так ярко выражена, поскольку размеры устройств в большей степени определяют параметры физической подводки модулей ввода-вывода ПЛК.
- Вместе с тем традиционный проводной ввод-вывод хоть и по-прежнему будет необходим, однако управление полевыми устройствами в ряде случаев перекладывается на цифровые сети.
- Граница между ПЛК и ПАК (программируемыми контроллерами автоматизации) будет размыта, но для потребителей это не будет иметь значения, поскольку им важен функционал, а не название.
- Классическая релейная (лестничная) логика сохранится в будущем, несмотря на стремление к переходу на открытые системы, протоколы и современные языки программирования.
- Пользователям по-прежнему будут нужны платформы автоматизации от проверенных промышленных разработчиков, но с поддержкой любого языка программирования. Программисты зачастую предпочитают писать код на языках, основанных на ИТ, таких как C++ или Python.
- Как в области аппаратного, так и программного обеспечения заметен переход от проприетарных к более открытым решениям АСУ ТП.
- Некоторые конечные пользователи заинтересованы в применении оборудования Raspberry Pi и Arduino для проектов автоматизации и обработки данных.
- Современные модификации форм-факторов теперь позволяют Ethernet-устройствам подходить и для промышленных сред.
- Протоколы OPC UA и MQTT будут активно применяться для связи устройств в сфере Промышленного интернета вещей.
- Робототехника станет точкой роста рынка автоматизации.
- Наиболее совершенные ПЛК будут запускать в реальном времени алгоритмы искусственного интеллекта и машинного обучения.
- Генеративный искусственный интеллект в ближайшее время будет всё чаще применяться для создания кода и среды разработки ПЛК.
Для включения и выключения часто используется этот полезный логический элемент RS-триггер. На нем можно собирать сложные цепочки регуляторов с различной логикой.
Сейчас я стал редко его применять, так как код в основном пишу на ST. Зачастую этот элемент там не нужен. А для языка программирование CFC и FBD самое то.
RS-триггер
У этого элемента сброс является приоритетом. Одним словом, если он срабатывает, то другие сигналы не работают.
Технология программируемых логических контроллеров совершенно точно достигла зрелости – ей уже 60 лет. В связи с чем возникает вопрос: станут ли нынешние ПЛК «пенсионерами» и сойдут ли их будущие версии в могилу? Такое предположение кажется уместным, учитывая быстрое, а порой экспоненциальное развитие компьютерного оборудования, программного обеспечения, искусственного интеллекта, облачных сервисов и средств связи. Благодаря этим достижениям информационные технологии постепенно проникли в ранее изолированную сферу операционных технологий.
В свете этих событий приводим статью Джеффа Пейна, опубликованную в журнале Control Engineering о будущем контроллеров и приложений промышленной автоматизации на фоне происходящей в последние десятилетия эволюции ПЛК.
Оставаться верным своему делу
Основная задача ПЛК остается той же, что и всегда: обеспечение надежного управления и мониторинга физических полевых устройств даже в сложных условиях эксплуатации. Это было достигнуто благодаря использованию специализированных процессоров, операционных систем и сред программирования, встроенных в защищенные платформы. Тем не менее, эффект масштаба продолжает стимулировать внедрение основных потребительских и коммерческих технологий в ПЛК везде, где это осуществимо. Принцип «меньше, быстрее, лучше» сохранился и будет оставаться верным, но в основном в отношении более быстрых и лучших аспектов, поскольку тенденция к дальнейшей миниатюризации за последнее десятилетие выровнялась.
Многие преимущества развития электронных компонентов, процессоров и твердотельной памяти – снижение стоимости, уменьшение размера, минимизация энергопотребления и увеличение возможностей – уже реализованы в ПЛК и другой промышленной электронике. Однако несмотря на то, что незначительные улучшения в размерах, стоимости и производительности будут происходить и впредь, реальный прогресс будет заключаться в возможностях. На данный момент размер платформы в значительной степени ограничен необходимостью физической проводки для взаимодействия с модулями ввода-вывода ПЛК. Традиционный проводной ввод-вывод по-прежнему необходим, но во многих случаях связь с полевыми устройствами смещается в цифровые сети и распределяется удаленно с использованием таких технологий, как IO-Link и беспроводная связь.
Многоядерные процессоры, встроенные в конструкции ПЛК, теперь позволяют дополнять детерминированное управление обширными дополнительными вычислительными и коммуникационными функциями. На протяжении более 20 лет термин «программируемый контроллер автоматизации» (programmable automation controller – PAC) широко использовался для описания промышленного контроллера с более широкими возможностями, чем классический ПЛК.
Хотя поначалу ПАК (PAC) мог показаться отдельным продуктом по сравнению с ПЛК, время показало, что инженеры по автоматизации меньше озабочены названием и номенклатурой и гораздо больше интересуются производительностью и доступными функциями. В дальнейшем пользователи будут готовы рассматривать практически любой тип аппаратной части или операционной системы в качестве платформы автоматизации, которая может продолжать называться ПЛК, хотя на самом деле это будет нечто большее, если она сможет обеспечить управление в реальном режиме времени, обеспечивая при этом расширенные вычислительные возможности.
Сочетание гибкости и логики
Хотя системы на базе Windows доминируют в мире потребительских и коммерческих компьютеров и занимают видное место в сфере промышленной визуализации, это не относится к управлению в реальном времени. Платформы ПЛК/ПАК обычно работают под управлением специализированной операционной системы, хотя существуют некоторые варианты на базе Linux. В самых общих чертах пользователи должны сбалансировать свое стремление к открытости, которая обеспечивает большую гибкость и низкую стоимость продукта, с требованием надежности промышленного уровня, которое исторически обеспечивалось только проприетарными системами. Эти запатентованные системы также обеспечивают высокую степень кибербезопасности, хотя в первую очередь за счет некоторой неизвестности хакерам.
В течение многих лет наблюдалась тенденция или, по крайней мере, большой интерес к более открытым промышленным системам, как с точки зрения аппаратных платформ, так и с точки зрения языков программирования. Некоторые конечные пользователи применяют стандартное оборудование Raspberry Pi и Arduino для реализации проектов автоматизации и обработки данных. Другие избегали подобных экспериментов с продуктами потребительского уровня из-за опасений по поводу надежности. Но теперь несколько версий этих платформ превратились в устройства промышленного уровня (Рис. 1). Пользователи предъявляют большой спрос на возможность сочетания современной платформы программирования с проверенными промышленными устройствами ввода-вывода.
Рис. 1. Теперь, когда современные процессорные платформы с открытым исходным кодом доступны в форм-факторах промышленного уровня у конечных пользователей появилась возможность интеграции традиционных методов автоматизации с более современными языками, осно
При таком разнообразии аппаратных средств следующим препятствием на пути к открытости стала гомогенизация среды программирования. В классических ПЛК использовалось программное обеспечение, разработанное конкретным поставщиком, которое было трудно перенести на другие бренды. Стандарт IEC 61131-3 представил упорядоченные языки программирования ПЛК и типы данных, но реализации, специфичные для конкретного поставщика, по-прежнему препятствовали переносу кода между брендами. В конечном счете интегрированная среда разработки (integrated development environment – IDE) CODESYS предложила более согласованный способ создания кода с использованием стандартных языков для его кроссплатформенного развертывания на промышленных контроллерах.
Однако ни одна из этих инициатив не учитывала тот факт, что программисты, поступающие на работу, часто предпочитали писать код на более современных языках, основанных на ИТ, таких как C++ или Python.
Несмотря на все эти усилия, направленные на открытость и современные языки программирования, можно с уверенностью сказать, что классическая релейная (лестничная) логика сохранится в обозримом будущем. Релейная логика имеет обширную базу инсталляций и остается простой методологией кодирования, предпочитаемой многими электриками, техническими специалистами АСУ ТП и даже разработчиками. Ее графический стиль позволяет выполнять основные функции поиска и устранения неисправностей, а также выполнять типичные функции промышленной автоматизации, а широкое распространение дает дополнительные преимущества.
Сегодня большинство аппаратных платформ поддерживают релейную логику – как собственную, так и реализованную через другие IDE, например, CODESYS, а многие из них также допускают другие методы кодирования, которые можно комбинировать по мере необходимости. Различные языки программирования имеют свои сильные и слабые стороны для конкретных задач, а большинству пользователей нравится разрабатывать собственный вариант лучшего инструмента для решения проблемы, балансируя при между гибкостью и сложностью. Дополнительным бонусом для пользователей является то, что выход за пределы проприетарных языков позволяет им создавать библиотеку кода, которую можно развернуть на любом типе целевого оборудования, сводя к минимуму доработку.
Главным моментом сегодня и в будущем является то, что пользователям нужны платформы автоматизации, предлагаемые и поддерживаемые проверенными и опытными промышленными поставщиками, с возможностью поддержки любого типа предпочтительного языка программирования.
Коммуникации
Некоторые из достижений промышленной автоматизации в последнее время связаны с улучшением коммуникаций, что привело к полной взаимосвязи всех систем предприятия. Как и в случае с аппаратным обеспечением и программированием контроллеров, здесь наблюдается переход от проприетарных реализаций к более открытым предложениям.
Традиционные промышленные шины, такие как DeviceNet давно предлагаются пользователям в виде проверенных и надежных устройств. Но сейчас преобладают проводные и даже беспроводные варианты Ethernet, при этом доступны несколько ведущих протоколов промышленной связи. Улучшения физического форм-фактора, в том числе во влагозащитном корпусе со стандартными разъемами и питанием по PoE, теперь позволяют Ethernet-устройствам подходить и для промышленных сред.
Некоторые протоколы, такие как EtherNet/IP, PROFINET и Modbus-TCP, связаны с марками и моделями конечных устройств, тогда как другие оптимизированы для типов задач автоматизации (например, EtherCAT для управления движением). Хотя EtherCAT не нов, включение этого протокола в более функциональные ПЛК теперь означает, что приложения управления движением низкой и средней сложности могут быть интегрированы в платформу автоматизации без необходимости использования отдельных контроллеров движения.
Ethernet-APL – это среда, оптимизированная для операционных технологий (OT), которая упрощает развертывание проводного Ethernet на полевых устройствах. IO-Link развивается как оптимизированная полевая шина для базовых дискретных устройств автоматизации с соответствующими коммуникационными возможностями и интеллектом.
Соединение ОТ с ИТ для безопасного включения приложений Промышленного интернета вещей (IIoT) и передачи данных для поддержки удаленной визуализации и аналитики требует другого класса протоколов связи. OPC UA и MQTT доминируют в этой роли. Хотя некоторые из их возможностей частично совпадают, для обоих протоколов существуют оптимальные варианты применения, и пользователи могут реализовать их одновременно. Другие вспомогательные инструменты, такие как Node-RED, стали предпочтительными в качестве графического метода обработки и передачи данных в облако для использования другими приложениями.
От датчика до контроллера, от локального сервера, до облачных ресурсов и браузера – что все это означает? В «старые времена» контроллеры меньшего размера имели ограниченный набор функций, поэтому для достижения полной возможности подключения требовались более крупные устройства или несколько уровней интеграции. Сегодня и в будущем пользователи захотят, чтобы эти опции были доступны даже на самых простых и недорогих платформах автоматизации (Рис. 2).
Рис. 2. Сегодня даже недорогая платформа автоматизации ПЛК оснащена расширенными логическими возможностями, управлением движением, проводным/беспроводным подключением, протоколами связи ИТ/ОТ и многим другим
Роль интегрированной робототехники
На протяжении многих лет робототехника в основном существовала как специализированная разновидность автоматизации, требующая индивидуальной интеграции в вышестоящие и последующие системы. Ситуация меняется по мере того, как робототехника в целом и коллаборативные роботы (коботы) в частности, похоже, станут одной из крупнейших областей роста во всей промышленной автоматизации в течение следующих 5–10 лет (Рис. 3). Что касается сопутствующих разработок, системы машинного зрения значительно продвинулись за последнее десятилетие, и многие из них стали совместимы с роботами, что позволяет легко интегрировать их во множество приложений.
Рис. 3. Робототехника представляет собой быстрорастущую область промышленного дизайна – спрос на функциональные платформы автоматизации и связанные с ними сенсорные технологии будут расти, поскольку пользователи стремятся повсеместно интегрировать робототе
Современные платформы автоматизации должны быть готовы идти в ногу со временем, предоставляя необходимую вычислительную мощность, инструкции по программированию и технологии плавной интеграции с робототехникой и машинным зрением. Современный ПЛК с такими возможностями, размещенный рядом с робототехникой в качестве платформы автоматизации будет обладать явным преимуществом.
Роль искусственного интеллекта в будущем ПЛК
Ни одна перспективная статья о промышленной автоматизации, написанная в 2024 году, не может упустить из виду потенциальное влияние искусственного интеллекта (AI) и машинного обучения (ML) для анализа ситуации и реагирования на нее режиме реального времени. Однако с этой темой связано много шума, поскольку в настоящее время в качестве платформы автоматизации программируемые логические контроллеры для этой задачи подходят не идеально. Хотя в будущем некоторые продвинутые версии ПЛК смогут запускать в реальном времени алгоритмы AI/ML.
Вместо этого ПЛК имеют хорошие возможности выступить в качестве полевого интерфейса для ресурсов искусственного интеллекта и машинного обучения более высокого уровня, предоставляя пользователям оперативные, всеобъемлющие и связанные с конкретной обстановкой данные.
С другой стороны, генеративный искусственный интеллект (Gen-AI) в ближайшие годы будет играть более важную роль в ПЛК с точки зрения создания кода. Среды разработки с интегрированными инструментами поддержки искусственного интеллекта могут помочь пользователям, возможно, даже специалистам начального уровня, разрабатывать логику автоматизации на основе библиотек и проверенного кода. ИИ, используемый в качестве инструмента разработки, может помочь ускорить разработку, повысить надежность кода и свести к минимуму ненужный и рутинный труд.
Будущий ПЛК – это часть платформы автоматизации
В течение следующего десятилетия программируемые логические контроллеры, какими мы их знаем, определенно не прекратят свое существование, даже если их будут называть ПАК, периферийными контроллерами, платформами автоматизации или чем-то еще. Но и не будет единой технологии контроллера, которая могла бы выполнять все функции во всех ценовых категориях.
Вместо этого ПЛК будут продолжать развиваться в зависимости от доступных технологий и потребностей пользователей, как они делали это на протяжении последних пяти десятилетий. Приоритетом будет обеспечение контроля в реальном времени и надежного мониторинга, но они добавят еще более совершенные функции программирования и подключения для улучшения пользовательского опыта и скорости реализации проектов.
Итак, ПЛК в ближайшее время не исчезнут, а новые технологии, подкрепленные требованиями пользователей, помогут им эволюционировать в качестве базовой платформы автоматизации.
Материал подготовлен Московским заводом тепловой автоматики (МЗТА)
Ввиду кризиса в последнее время и постоянной нехватки финансов, люди ищут альтернативные и бюджетные решения для автоматизации «Умных домов», теплиц, гаражей и т.п. А что делать тем, кто очень хорошо один язык программирования, а на дополнительное изучение просто не хватает времени? Ну, например я! Я знаю CoDeSyS достаточно хорошо. Не супер-профи, но хорошо. Тогда CoDeSyS Raspberry PI — это идеальное сочетание бюджетности и удобства программирования. Почему? Давайте рассмотрим…
Всем привет уважаемые коллеги, читатели и гости моего блога. На связи автор технического блога — Гридин Семён.
Меня зовут Raspberry PI
Raspberry PI — маленький одноплатный компьютер, выполняющий такие же основные функции, как и настольный ПК. Основная операционная система Это Linux и все её производные. Хотя можно установить абсолютно любую ОС под ваши определённые узкие задачи.
Весь список ОС вы можете увидеть на официальном сайте «Малины». Как вы видите основная система — это Raspbian. В будущем мы с вами будем опираться конкретно на неё.
Разработана эта плата в мае 2011 года. Её большим преимуществом является цена и многофункциональность. На данный момент последняя модель Raspberry PI 3 model B.
Да, и конечно самое важное — технические характеристики.
Процессор Broadcom 2837 quad-core ARM Cortex-A53 64bit (1,2GHz)
Оперативная память 1Gb
Видеовыход HDMI
А/V выход А/V выход 3.5мм jack 4 pin
USB порты USB 2.0 х 4
Сеть WiFi 802.11n, 10/100Mb RJ45 Ethernet Bluetooth
Bluetooth 4.1, Bluetooth Low Energy
Слот для карты памяти Micro SD
GPIO 40
Характеристики достаточно мощные, в отличие от старых моделей. Радует наличие 4-х портов USB и Bluetooth.
В последнее время на форумах и в интернете я всё чаще и чаще замечаю комментарии по поводу того, что на этом устройстве нельзя собрать «серьёзный проджект». Это игрушка для детей и т.д. Я считаю, что это не правда. Это инструмент.
В умелых и правильных руках можно творить воистину полезные и фантастические вещи. Ребят, это очень мощный инструмент, с интересными функциями. Просто в основном видеоблогеры выкладывают материалы про переделанные ретро-приставки и автоматы. Или проекты, которые просто на «поиграться». А как вы считаете?
Как установить ОС — в общих чертах…
Как прошивать любую операционную систему?? В интернете море информации по поводу установки. Всё расписано по шагам.
Я тогда не буду повторяться. Можете изучить вот этот материал. Или посмотрите 5-минутное видео о подключении малины:
Я думаю, здесь будет всё понятно. Если будут вопросы, пишите в комментах, я с удовольствием пообщаюсь.
Raspberry PI + CoDeSyS 3.5
Я кстати говоря давно искал решение вопроса — Где можно использовать CoDeSyS, кроме ПЛК? Так как большинство ПЛК различных производителей — это достаточно дорогие устройство. Для бытовой и домашней автоматизации такой вариант не подходит. Ещё и модули ввода вывода дорогие, если потребуется.
А языки программирования стандарта МЭК очень удобны и понятны. И крутую визуализацию можно накидать. Крутые инструменты!!!
Для того чтобы эта связка заработала у вас, что следует приобрести:
Сам одноплатный компьютер Raspberry PI
Сенсорную панель к нему или монитор
И сам RunTime CoDeSyS 3.5
RunTime — это некая операционная система с предустановленной средой разработки. В данном случае мы можем сразу же программировать на маленьком компьютере. В этом и заключается удобство. Рантайм CoDeSyS стоит примерно 50 евро, находится он в магазине CoDeSyS Store.
Обращаю ваше ВНИМАНИЕ!!! Единственный недостаток всей системы в том, что используется WEB-визуализация. Так что придётся открывать через браузер. На видеоролике Курта Брауна очень хорошо описывается процесс установки среды разработки на компьютер. Правда там используются модули расширения WAGO.
Но можно прикрутить любой, лишь бы поддерживал MODBUS TCP/IP. Если вы поставите преобразователь UART = RS-485, то сможете работать с MODBUS RTU.
Для «Умного» дома и теплиц шикарная вещь! Спасибо за внимание! Подписывайтесь на новости блога… Пишите письма!!!
