Программируемые-логические контроллеры (ПЛК) присутствуют практически во всех промышленных системах и производствах не зависимо от масштаба предприятия. Но, с одной стороны:
- Поскольку конечные пользователи пользуются преимуществами более мощных ПЛК, они также должны учитывать и безопасность.
- Увеличив общую вычислительную мощность ПЛК, поставщики контроллеров также предоставили место для дополнительных возможностей.
- Повышение вычислительной мощности позволило создать сложный ПЛК, который может синхронизировать сервоприводы или управлять сложными контурами процессов при одновременной передаче данных и поддержке человека-машинных интерфейсов (ЧМИ или на английском HMI).
Любой, кто служил в армии или работал в большой компании понимает концепцию иерархии — она определяет, кто главный, порядок подчинения и то, как каждый человек вписывается в эту структуру. Некоторые люди находят безопасность в прозрачной структуре и жесткой иерархии, в то время как амбициозные люди могут чувствовать себя подавленными. Подобные ситуации применяются и в промышленной автоматизации. Иерархическая структура определяет, какой тип оборудования куда направляется и какие действия должны выполняться на каждом уровне. Этот подход подробно объясняется в эталонной архитектуре Purdue Enterprise (рисунок ниже).
Он помещает технологические и полевые устройства внизу, управляющее оборудование в середину и системы корпоративных информационных технологий (ИТ) вверху. Операционная технология (OT) с ее ПЛК обычно существует на базовом уровне управления, где они взаимодействуют с полевыми устройствами, выполняют контуры управления и управляют движением. Когда есть необходимость отправить данные в систему более высокого уровня, они должны быть переданы вверх по цепочке команд, переходя от уровня к уровню.
В этой структуре есть два основных недостатка:
- Это требует больших усилий разработчика и накладных расходов на вычислительные ресурсы с несколькими протоколами связи.
- Он не признает и не использует растущие возможности контроллеров сегодняшнего поколения.
Классические архитектуры промышленной автоматизации отражают концепции и ограничения оборудования 1990-х годов. Программируемые логические контроллеры той эпохи были менее мощными и поэтому должны были быть специализированными и ориентированными на выполнение определенных функций высокоскоростного управления. Системы более высокого уровня требовались для обеспечения более совершенных возможностей обработки данных. Но перемещение данных между нижним и верхним уровнями потребовало значительных усилий.
Пользователи генерировали настраиваемые конфигурации кода для выбора, упорядочивания и управления данными. Часто было задействовано множество деталей и программ: ПЛК, шлюзы, ПК, пакеты программного обеспечения, конфигурация сети и вспомогательный код. Даже когда возможность подключения данных могла быть исправлена, это часто происходило в ущерб безопасности. Традиционно в ПЛК было мало (если вообще было) положений о кибербезопасности, особенно для систем, подключенных к сети интернет.
Изменения и улучшения
За последние несколько десятилетий в промышленном пространстве многое изменилось. Одна проблема заключается в том, что накладные расходы остаются проблемой. Заводы хотят более плоские и менее сложные системы управления процессами и машинами. Концепция наличия такого количества уровней специализированного оборудования расточительна, но ее можно оптимизировать с помощью более универсальных контроллеров, способных выполнять несколько дублирующих ролей. Старые ПЛК не могли справиться с требованиями высокой скорости, будучи отвлеченными другими функциями управления данными.
Повышение вычислительной мощности (рисунок ниже) означает, что современные ПЛК теперь могут синхронизировать сервоприводы или управлять сложными контурами процессов при передаче данных и поддержке человеко-машинного интерфейса (HMI). Сложный ПЛК может охватывать более одного уровня.
Во-вторых, как только что было отмечено, программируемые логические контроллеры (ПЛК) прошли долгий эволюционный путь, но внедрение всех улучшений у разных производителей неодинаково. Некоторые компании решили, что традиционные структуры безопасны, и предпочли не выходить за рамки этих ограничений, даже несмотря на то, что ограниченные возможности связи затрудняют интеграцию с вышестоящим и последующим оборудованием. Синхронизация по-прежнему возможна, но она сложна в реализации и требует дополнительных накладных расходов.
Реализуя технологические усовершенствования и увеличивая общую вычислительную мощность своих ПЛК для выполнения основных функций с гораздо меньшими затратами, некоторые поставщики предоставили место для дополнительных возможностей. Например, за счет включения более длинного списка вариантов протокола связи, ПЛК может подключаться к промежуточным сетевым уровням и уменьшать сложность взаимодействия с другими устройствами, расположенными на предприятии. Даже относительно простой ПЛК может работать в среде, где преобладает оборудование от другого производителя. Кроме того, он может взаимодействовать с ИТ-ориентированными активами с помощью прикладного программного интерфейса репрезентативной передачи состояния (REST API) или безопасного транспорта телеметрии с очередями сообщений (MQTT / S) по проводным или беспроводным сетям. Это далеко от старых ПЛК, которые «общаются» только по MODBUS.
Эта возможность может быть расширена еще больше благодаря подключению интернет вещей (IoT) непосредственно к облаку. Даже небольшой или средний контроллер может быть сертифицирован для подключения к платформе Microsoft Azure. Сертификация гарантирует пользователям, что устройство протестировано для работы с инфраструктурой Azure, и предоставляет четкую документацию о том, как подключиться. Azure предлагает множество возможностей промышленных интернета вещей (IIoT), чтобы помочь пользователям визуализировать и оптимизировать свои операции, в том числе:
- Cosmos DB для хранения данных
- Power Apps для простого создания решений практически без написания кода (low-code)
- Веб и мобильная визуализация
- Машинное обучение и аналитика для построения передовых моделей прогнозирования
Рассмотрим такую ситуацию: ПЛК должен передавать данные в корпоративную сеть для расширенной обработки. Используя традиционный подход, он перемещает данные по цепочке через все уровни, возможно, конвертируя их в другой протокол раз или два, и в конечном итоге достигает места назначения. Альтернативой является сертифицированный Azure для ПЛК, способный взаимодействовать с центром Azure IoT без шлюза: прямое соединение, менее сложное и с гораздо меньшими накладными расходами.
Применение стандартов
Некоторые из наиболее популярных последовательных протоколов и протоколов Ethernet для целей OT включают ASCII, Modbus RTU, K-Seq, Modbus TCP и EtherNet / IP. С другой стороны, ИТ-системы используют такие протоколы, как SNTP DNS, MQTT, SMTP, SSL и веб-службы. ПЛК, объединяющий эти возможности вместе, становится мостом от ОТ к ИТ, создавая множество способов подключения нового и устаревшего заводского оборудования к сегодняшним корпоративным системам.
Когда все элементы интеграции данных встроены и изначально находятся в ПЛК, настройка выполняется намного быстрее. ИТ-пользователи обычно предпочитают решения с открытым исходным кодом, потому что они уже знакомы с этим подходом, а не специализированные среды, характерные для промышленных продуктов.
Когда эти технологии доступны, пользователи могут выбирать из ряда вариантов в зависимости от требований процесса (рисунок ниже).
Они могут:
- Хранить данные в ПЛК и пересылать их в другие системы с помощью FTP.
- Представлять информацию в виде веб-страниц, размещенных на внутреннем веб-сервере.
- Предоставление данных внешним клиентам с помощью REST API.
- Передача данных в другие системы с помощью MQTT через TLS.
Последний из этих вариантов (MQTT) стал популярным стандартом для обмена данными между ПЛК и облаком. ПЛК в полевых условиях инициирует «разговоры» как исходящие сообщения с централизованным брокером, который может находиться локально, но чаще всего находится в облаке. Это обеспечивает двустороннюю связь, избегая проблем с брандмауэром и ИТ-управлением, которые могут возникнуть при многих типах входящей связи.
Коммуникации MQTT отзывчивы, но в то же время могут противостоять сбоям сети и связи, которые обычно встречаются на периферии. ПЛК, использующий MQTT, идеально подходит для передачи данных на платформу IIoT, расположенную в службе облачных вычислений, такой как Microsoft Azure. Пользователи могут получать доступ к данным с помощью корпоративных или мобильных клиентов, или они могут создавать другие приложения для использования данных, полученных из ПЛК по протоколу MQTT.
Безопасность и гибкость
К сожалению, улучшенное соединение с ПЛК ведет к большим рискам кибербезопасности. Следовательно, новые ПЛК должны включать встроенные функции безопасности, такие как:
- По умолчанию контроллер закрыт для запросов из внешнего мира (внешних сетей).
- Встроенное хранилище учетных данных для имени пользователя и пароля, управляемое персоналом ОТ.
- Белый список IP-адресов для контроля внешних клиентов, которым разрешено связываться с ПЛК.
- По возможности защищайте связь через TLS.
По мере того, как конечные пользователи пользуются преимуществами более мощных ПЛК, они должны убедиться, что эти возможности безопасности доступны и правильно настроены.
Вчерашние контроллеры и другие продукты для промышленной автоматизации были в значительной степени неспособны выполнять сложные вычислительные задачи, которые пользователи хотят и в которых нуждаются сегодня, потому что они были специализированными и ограниченными с точки зрения обработки данных. Вычислительная мощность, заложенная в сегодняшние цифровые устройства OT, обеспечивает более широкие возможности для поддержки IoT и аналитических усилий на уровне предприятия и в облаке. Объединение проверенных технологий на основе OT с тщательно скоординированными коммуникациями, удобными для ИТ, и безопасностью приводит к эффективному сочетанию в ПЛК многих функций, о которых ранее приходилось только мечтать. Современные программируемые логические контроллеры могут подключаться напрямую к облаку, что упрощает преодоление традиционных ограничений.
