Решил написать свой первый настоящий пост на Пикабу. Даже не представлял, как получается написать такие объёмные тексты. Но тут товарищ прислал одну статейку про новых программистов и реальную автоматизацию на заводах))) И тут вспышка 📸, ничего не помню и выходит текст из памяти!) Добро пожаловать под кат!)
Приходит как-то молодой 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 на МЭО импульсами надёжнее для конечного пользователя)) ☝️ Но это ещё не всё. Печники, когда лень идти в помещение с этим щитом управления, просто подходят к МЭО и что? Тоже правильно! Просто крутят его с помощью маховика))) Вот тебе и автоматизация)))💡 МЭО было примерно как на фото) Ну и схематически печь)
Бывают задачи, когда нужно последовательно подвигать механизм вверх-вниз или влево-вправо (Например механизм протруски в прессе). Или движения тележки.
В 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.
Для «Умного» дома и теплиц шикарная вещь! Спасибо за внимание! Подписывайтесь на новости блога… Пишите письма!!!
Протоколы связи являются важной частью ПО автоматизации. В настоящее время даже простые датчики имеют встроенные коммуникационные порты для обмена данными, не говоря уже о ПЛК. В этой связи стоит рассмотреть два старейших, но до сих пор широко используемых протокола связи – Modbus и Profibus. Оба звучат одинаково, но имеют свои особенности. В чем между ними разница? Отвечает на этот вопрос статья на портале InstrumentationTools.
Что такое Modbus?
Modbus – это протокол связи, разработанный компанией Schneider Electric, ранее известной как Modicon. Вот почему он называется Modbus. Modbus передает данные по последовательной линии, в которой используются аппаратные интерфейсы, такие как RS-232, Ethernet и RS-485.
Последовательная линия связи означает, что одновременно передается и принимается только один бит. Не допускается одновременная передача нескольких битов. Таким образом, последовательная связь немного медленнее параллельной.
Modbus имеет два формата – RTU и ASCII. RTU используется в двоичном формате, тогда как ASCII использует в текстовый формат ASCII. Modbus – это открытый протокол, то есть любой поставщик может использовать его, встроив в соответствующее программное обеспечение.
Modbus работает в формате ведущий-ведомый. Это означает, что есть одно ведущее устройство, которое запрашивает данные от других ведомых устройств. Подчиненные устройства отвечают и обмениваются данными с ведущим.
В стандартной сети Modbus может быть максимум 247 подчиненных устройств. Бит отправляется и принимается в виде напряжения. Нулевой бит означает +5 В, а единичный бит означает -5 В. Modbus идентифицируется по таким данным, как адреса регистров катушек, код функции, идентификатор устройства и тип чтения/записи.
Кроме того, одной из основных функций, связанных с данными Modbus, является CRC (cyclic redundancy code – циклический избыточный код). Два байта добавляются в конце каждого сообщения Modbus для обнаружения ошибок.
Что такое Profibus?
Profibus означает Process (Pro) Field (Fi) Bus и был разработан Siemens. Profibus можно назвать расширением протокола Modbus, и он более продвинут. Profibus существует в двух модификациях: Profibus DP (Decentralized Peripherals – децентрализованная периферия) для автоматизации машин и Profibus PA (Process Automation – автоматизация процессов) для автоматизации процессов. В них встроены дополнительные функции в соответствии с требованиями приложения. Это позволяет программистам использовать протоколы в соответствии с их задачами. Но, в отличие от Modbus, который работает на трех разных аппаратных уровнях, этот протокол работает только в RS-485.
Единственное, что отличает Profibus – это режим с несколькими мастерами, в то время как Modbus позволяет использовать только одного мастера. Это возможно за счет дополнительного протокола Token Ring в нем. Каждый мастер проходит последовательность запуска при холодном или теплом старте.
Подчиненные устройства ждут, пока мастер запросит данные, и если они не получат ни одного запроса в течение определенного периода времени, он перейдет в спящий режим. В этом случае мастеру необходимо снова пройти этап запуска и инициировать связь. Это означает, что все ведущие и ведомые устройства доступны в сети для корректной связи. Однако режим с несколькими ведущими устройствами доступен только в системе Profibus PA.
Разница между Modbus и Profibus
Modbus – это открытый протокол, тогда как Profibus таковым не является, т.е. никто не может его свободно использовать.
Modbus разработан компанией Schneider Electric, а Profibus – компанией Siemens.
Двумя вариантами Modbus являются Modbus RTU и Modbus ASCII, тогда как двумя вариантами Profibus являются Profibus DP и Profibus PA.
Profibus обеспечивает более скоростную связь, чем Modbus.
Modbus может работать на разных аппаратных уровнях, таких как RS-232, RS-485 и Ethernet, тогда как Profibus может работать только на уровне RS-485.
У Modbus может быть только один Мастер, тогда как у Profibus может быть несколько Мастеров.
С точки зрения программирования Modbus намного проще в использовании, чем Profibus.
Profibus более эффективен и надежен для использования в сложных сетях связи, чем Modbus.
Profibus имеет больше возможностей для диагностики и устранения неисправностей, чем Modbus.
Сравнение Modbus и Profibus
Материал подготовлен Московским заводом тепловой автоматики
Управление технологическими процессами производится в весьма широком круге областей, типичными из которых являются: сборка автомобилей, переработка нефти, выработка электроэнергии, а также техпроцессы в пищевой, фармакологической, химической, металлургической, электротехнической промышленности и многих других. Рассмотрим несколько видов техпроцессов и применяемые в них методы автоматизации.
Классификация технологических процессов
Непрерывный технологический процесс – это такой процесс, при котором сырье поступает в начало системы, а готовый продукт соответственно получается в конце, при этом производственный процесс протекает непрерывно. Для таких процессов характерно измерение конечной продукции объемами: тонны, литры, кубометры и т.д. Типичные отрасли, использующие непрерывный техпроцесс это: металлургия, химическая промышленность, нефтепереработка. Но возможно и исключение, когда продукция измеряется в штуках, но сам процесс непрерывный, например, конвейерная сборка двигателей (рисунок 1).
Рис. 1. Непрерывный технологический процесс
Детали монтируются последовательно на конвейере на блок цилиндров, который переходит через ряд станций. Сборка и регулировка осуществляются как автоматизированным, так и ручным способом.
Периодический или Batch-процесс – это такой процесс пакетной обработки, в котором отсутствует поток материала, переходящего от одного участка процесса к другому. Вместо этого определенное количество каждого компонента, получаемых из входных ресурсов, поступает в виде партии в соответствии с рецептурой, а затем над партией выполняются некоторые операция для производства конечного продукта. Примеры продукции, производимой с использованием периодического процесса: продукты питания, напитки, фармацевтика, краски, удобрения и т.п.
На рисунке 2 показан пример периодического процесса. Три ингредиента смешиваются вместе, нагреваются и затем поступают в хранилище готовой продукции. Состав и характеристики каждой партии могут меняться в зависимости от текущего рецепта.
Рис. 2. Периодический или batch-процесс
Дискретный процесс – это процесс, характеризующийся раздельным изготовлением единицы продукции. При таком производственном процессе в результате ряда операций получается полезный продукт на выходе, а сами процессы не являются непрерывными. По своей природе каждый процесс может быть запущен или остановлен индивидуально, либо может выполняться с различной производительностью. Дискретные производственные системы обычно имеют дело с цифровыми входами программируемых логических контроллеров (ПЛК), которые приводят в действие моторы и роботизированные устройства. Деталь обычно представляет собой отдельную заготовку, которая должна обрабатываться индивидуально. Типовые отрасли, использующие дискретный процесс – это выпуск автомобилей или любой другой техники, упаковка и т.д. В таких процессах может использоваться универсальное технологическое оборудование, позволяющее выполнять на одном рабочем месте нескольких видов операций.
Зачастую на предприятии все типы технологических процессов используются одновременно на разных этапах производства (рис. 3)
Рис. 3. Пример применения трех типов технологических процессов в производстве
Управление технологическими процессами
Конфигурации систем управления техпроцессом. Выделяют локальные, централизованные, распределенные системы управления и системы управления процессами. Каждая система использует ПЛК, которые удовлетворяют ряду характеристик по типу и количеству обрабатываемых сигналов, быстродействию и по требованиям эксплуатации.
Локальное (индивидуальное) управление – используется для управления одной машиной или технологической установкой. Этот тип управления обычно не требует связи с другими контроллерами.
На рисунке 4 показано локальное приложение для управления процессом обрезки заготовки по длине. Оператор вводит длину подачи и количество отрезаемых заготовок через интерфейсную панель управления, а затем нажимает кнопку «Пуск» с тем, чтобы запустить процесс. Далее конкретная установка работает независимо от наличия других установок на производстве.
Рис. 4. Локальное управление
Централизованное управление – используется в тех случаях, когда несколько машин или процессов управляются одним центральным контроллером. Схема управления использует единую комплексную систему управления множеством разнообразных производственных процессов и операций, например, транспортировка, визуальный контроль, взвешивание, сортировка и т.д., как показано на рисунке 5.
Рис. 5. Централизованное управление
Основные характеристики централизованного управления можно резюмировать следующим образом:
Каждый отдельный этап производственного процесса обрабатывается контроллером центральной системы управления.
Никакой обмен статусом контроллера или данными с другими контроллерами не осуществляется.
Если главный контроллер выходит из строя, весь процесс останавливается.
Обычно в централизованных системах используется централизованная SCADA для обеспечения работы в реальном времени систем сбора, обработки, отображения и архивирования информации об объекте управления.
Распределенная система управления – РСУ (или Distributed Control System DCS) – это сетевая система, включающая в себя два или более ПЛК, взаимодействующих друг с другом для выполнения всех задач управления непрерывным технологическим процессом, как показано на рисунке 6.
Рис. 6. Распределенная система управления – РСУ
Каждый программируемый логический контроллер управляет различными процессами локально, и все ПЛК постоянно обмениваются информацией по каналу связи и сообщают о состоянии процесса. Основные характеристики распределенной системы управления можно описать следующим образом:
Распределенное управление позволяет разделять технологические задачи между несколькими контроллерами.
Каждый ПЛК управляет соответствующей машиной или процессом и для синхронизации задач имеет доступ ко всем данным других ПЛК.
Высокоскоростная связь между компьютерами осуществляется с помощью витой пары проводов CAT-5 или -6, одиночных коаксиальных кабелей, волоконной оптики или сети Ethernet.
Распределенное управление значительно сокращает количество проводов в полевых условиях и повышает производительность, поскольку позволяет разместить ПЛК и ввод-вывод близко к контролируемому процессу машины.
В зависимости от технологического процесса один сбой ПЛК не обязательно приведет к остановке всего процесса (а в идеале и не должен).
DCS контролируется главным компьютером, который может выполнять функции мониторинга/наблюдения, а также формирование отчетов и хранение архивных данных.
Главная особенность РСУ (DCS) – любой ценой не дать незапланированно остановить непрерывный процесс, в связи с чем к ним предъявляются высокие требования по масштабируемости и отказоустойчивости. Они имеют высокую степень интеграции аппаратных средств и программного обеспечения (что подразумевает использование контроллеров и ПО визуализации одного производителя), и предоставляют инструменты, облегчающие процесс разработки систем управления с минимальным влиянием человеческого фактора (обычно до 90% кода контроллеров генерируется из базы данных сигналов и типовых алгоритмов, свойственных данному технологическому процессу). Это сильно отличает их от классических применения ПЛК + SCADA.
Система управления процессами (Process Control System – PCS) или комбинированная распределенно-централизованная система управления – это самый современный тип управления технологическими процессами, возникший благодаря развитию высокоскоростных сетей, используемых в быстро протекающих процессах и недорогой памяти. Данное управление представляет собой объединение принципов РСУ с использованием нескольких современных высокопроизводительных ПЛК, которые стали называть Контроллерами Процесса или Контроллерами Автоматизации (PC/PAC – ПАК) любого производителя и централизованной системой управления ими на общем SCADA-сервере. И если в DCS программа управления может быть разделена между несколькими контроллерами, то в централизованных PCS контроллеры выступают в роли удаленного ввода-вывода с локальными алгоритмами. При этом управляющая программа выполняется или прямо на сервере (что реже) или в общем контроллере верхнего уровня, которая агрегирует информацию с контроллеров нижестоящих уровней и распределяет задания для них. Пример такой системы приведен на рисунке 7.
Рис. 7. Система управления процессами
Сейчас подобные системы еще не нашли отклика в сферах непрерывных техпроцессов, где классически применяют РСУ, но уже активно применяется на предприятиях со смешанными процессами (см. пример на рисунке 3), так как подходят под них наилучшим образом.
Выводы:
Существует несколько видов технологических процессов с разной алгоритмической сложностью и требованиями по взаимодействию с другими системами.
ПО автоматизации должно подстраиваться под различные виды техпроцессов и реализовывать систему управления с учетом экономической целесообразности.
В настоящее время наблюдается рост популярности высокопроизводительных систем управления процессами (PCS), которые фактически становятся универсальными решениями для всех типов техпроцессов.
