От управления, ориентированного на ПЛК, к автоматизации, определяемой программным обеспечением
Промышленная автоматизация выходит за рамки традиционной модели, основанной на выделенных ПЛК, микроконтроллерах и машинах с фиксированными функциями. Современные системы всё чаще объединяют управление на базе ПЛК с высокопроизводительными MPU и SoC для работы с HMI, машинным зрением, периферийной аналитикой, подключением, цифровыми двойниками и рабочими нагрузками ИИ.
Эта эволюция не делает традиционные архитектуры управления устаревшими. Вместо этого она формирует многоуровневую архитектуру, в которой ПЛК могут по-прежнему выполнять детерминированное управление на уровне полевых устройств, а вычислительные платформы с более высокой производительностью - надзорные, аналитические функции, визуализацию и функции ИИ.
С инженерной точки зрения важно не просто добавить вычислительную мощность. Настоящая задача заключается в том, чтобы гарантировать: дополнительные рабочие нагрузки не смогут поставить под угрозу временные характеристики, доступность или целостность уже действующих функций управления.
Physical AI создаёт новую задачу для автоматизации
Внедрение Physical AI усложняет архитектуру системы, поскольку информация, генерируемая ИИ, может влиять на физическое оборудование и эксплуатационные решения.
Модель ИИ может выявить нештатное состояние машины, обнаружить визуальную аномалию, поддержать прогнозный контроль или выявить состояние, связанное с оператором. Однако результат ИИ-вывода является лишь одной частью полной цепочки автоматизации.
Система по-прежнему должна получать информацию от датчиков, выполнять модель ИИ, проверять рабочий контекст, применять заранее заданные политики управления и передавать полученное состояние соответствующему приложению или оператору.
Поэтому, на мой взгляд, промышленный ИИ следует рассматривать как рабочую нагрузку для поддержки принятия решений или контролируемого реагирования, а не как изолированный интеллектуальный уровень. Окружающая платформа автоматизации определяет, можно ли обрабатывать информацию ИИ и действовать на её основе в пределах требуемых временных и безопасностных ограничений.
Рабочие нагрузки с разной критичностью требуют настоящей изоляции
Современные многоядерные процессоры позволяют объединить функции, для которых ранее требовались отдельные аппаратные платформы. Одна вычислительная система теперь может одновременно размещать управление в режиме жёсткого реального времени, службы HMI, сетевые функции, диагностику, журналирование событий, машинное зрение, аналитику и выполнение ИИ-вывода.
Эти рабочие нагрузки имеют разные требования.
Задача управления в режиме жёсткого реального времени может иметь строгий крайний срок выполнения. HMI может допускать иные временные характеристики, тогда как процесс выполнения ИИ-вывода может требовать значительных ресурсов ЦП. Сетевые службы также создают внешние каналы связи, которые не должны иметь неограниченного доступа к критически важным ресурсам.
Следовательно, простое размещение нескольких приложений на многоядерном процессоре автоматически не создаёт отказоустойчивую архитектуру.
Операционная среда должна предоставлять механизмы для временного разделения, защиты памяти, контроля ресурсов и изоляции сбоев.
Консолидация аппаратных средств не равна отказоустойчивости
Консолидация аппаратных средств может сократить количество вычислительных платформ, упростить подключение и повысить степень интеграции. Однако она также создаёт потенциальную единую точку отказа.
Если не связанные между собой рабочие нагрузки используют один и тот же процессор и операционную среду, неисправный драйвер, неконтролируемо выполняющееся приложение, ошибка памяти или скомпрометированная служба могут повлиять на другие функции, если программная архитектура не устанавливает соответствующие границы.
Это один из важнейших аспектов модернизации устаревших систем автоматизации.
Целью должно быть не просто размещение большего числа функций на меньшем количестве процессоров. Цель состоит в консолидации рабочих нагрузок без создания неприемлемых зависимостей между ними.
Операционная система становится уровнем обеспечения требований
В программно-определяемой архитектуре автоматизации операционная система больше не является лишь платформой, на которой выполняются приложения.
Она определяет, как планируются процессы, как защищается память, как осуществляется доступ к аппаратным ресурсам и как отдельные службы взаимодействуют друг с другом. Эти механизмы напрямую влияют на способность системы продолжать работу при отказе отдельного компонента.
Поэтому отказоустойчивая архитектура должна обеспечивать изоляцию отказавшей службы и, если это допускается проектом системы, восстановление этой службы без перезапуска приложений, не связанных с ней.
Этот подход особенно актуален для промышленных систем, где полная перезагрузка системы может прервать управление, визуализацию, связь или производственные операции.
Почему микроядерная архитектура важна
Обычная монолитная операционная система, как правило, размещает множество служб, драйверов, файловых систем и сетевых компонентов в среде ядра с высокими привилегиями.
Микроядерная архитектура использует другой архитектурный подход. В ядре сохраняется меньший набор фундаментальных функций, а многие драйверы, стеки протоколов, файловые системы и системные службы выполняются как отдельные процессы в защищённых адресных пространствах.
Для промышленной автоматизации эта архитектура может обеспечить несколько полезных свойств:
- Изоляция сбоев: неисправный драйвер или служба могут быть изолированы от процессов, не связанных с ними.
- Контролируемое восстановление: Отдельные сервисы можно перезапускать без обязательной перезагрузки всей системы.
- Сокращение привилегированного кода: Меньшему числу компонентов требуется работать с наивысшими системными привилегиями.
- Изоляция памяти: Защищенные адресные пространства помогают предотвратить прямое вмешательство одного приложения в работу другого.
- Поддержка смешанной критичности: Задачи управления в реальном времени могут сосуществовать с HMI, сетевыми, аналитическими рабочими нагрузками и рабочими нагрузками ИИ.
- Обслуживание на протяжении жизненного цикла: Модульные сервисы могут упростить обслуживание и обновление компонентов.
Микроядро не устраняет дефекты программного обеспечения или уязвимости кибербезопасности. Его ценность заключается в создании архитектурных границ, способных ограничить последствия отдельных сбоев или компрометаций.
Детерминированность в реальном времени остается фундаментальным требованием
Модернизация промышленности не должна позволять требованиям ИИ и высокопроизводительных вычислений затмевать требования к детерминированному управлению.
Для приложений управления вопрос заключается не только в доступной вычислительной мощности. Система также должна обеспечивать предсказуемое планирование и ограниченные характеристики времени отклика для функций с заданными требованиями к временным параметрам.
Это особенно важно, когда рабочие нагрузки ИИ или аналитики потребляют значительные вычислительные ресурсы.
По моей оценке, практическая архитектура представляет собой не «замену управления с помощью ИИ», а скорее детерминированное управление, функционирующее параллельно с интеллектом более высокого уровня в рамках контролируемых границ ресурсов.
Кибербезопасность должна охватывать весь жизненный цикл продукта
Техническая изоляция - лишь одна из составляющих киберустойчивости.
Производителям промышленного оборудования также необходимы процессы идентификации компонентов программного обеспечения, мониторинга уязвимостей, проверки обновлений, контроля поставки программного обеспечения и обслуживания продуктов на протяжении всего срока их эксплуатации.
Серия стандартов ISA/IEC 62443 предоставляет ориентированную на жизненный цикл структуру, особенно актуальную для промышленных систем автоматизации и управления. Другие стандарты, включая ISO/SAE 21434, демонстрируют, как структурированное управление рисками кибербезопасности может охватывать этапы от разработки до эксплуатации, обслуживания и вывода из эксплуатации.
Европейский закон о киберустойчивости также повышает значимость управления кибербезопасностью на протяжении жизненного цикла продуктов, подпадающих под его действие.
Для производителей промышленного оборудования это означает, что кибербезопасность нельзя обоснованно рассматривать как деятельность по сертификации на заключительном этапе. Состав программного обеспечения, реагирование на уязвимости, механизмы обновления, управление поставщиками и обслуживание продукта необходимо учитывать в ходе разработки системы.
Архитектура безопасности должна поддерживать восстановление, а не только предотвращение
В традиционных обсуждениях кибербезопасности часто основное внимание уделяется предотвращению несанкционированного доступа. Промышленная устойчивость требует более широкого взгляда.
Скомпрометированный или неисправный компонент всё же может появиться, несмотря на превентивные меры контроля. Поэтому архитектура должна ограничивать способность такого компонента влиять на критически важные функции и обеспечивать предусмотренный путь восстановления.
Это формирует три взаимодополняющие инженерные цели:
- Предотвращать несанкционированное или непреднамеренное поведение.
- Локализовать сбои и скомпрометированные компоненты.
- Восстанавливать затронутые сервисы, сохраняя работу незатронутых операций.
Для промышленной автоматизации такое сочетание практичнее, чем полагаться только на предотвращение.
QNX как базовая платформа реального времени
QNX предоставляет архитектуру операционной системы на базе микроядра реального времени, предназначенную для систем, в которых важны предсказуемость выполнения, изоляция процессов и контролируемый доступ к ресурсам.
В архитектуре промышленной автоматизации QNX может предоставлять базовую среду выполнения для приложений, драйверов, стеков протоколов и файловых систем, работающих в защищённых адресных пространствах. Планирование на основе приоритетов может поддерживать рабочие нагрузки с различными требованиями ко времени выполнения.
Эта архитектура может дополнять управление на базе ПЛК, а не заменять его.
Практическая система может сохранять ПЛК для устоявшегося управления на полевом уровне, одновременно используя вычислительные платформы на базе MPU или SoC с операционной системой реального времени для HMI, машинного зрения, подключения, аналитики, супервизорных функций и рабочих нагрузок, связанных с ИИ.
Практическая архитектура модернизации промышленности
Таким образом, современную промышленную систему можно рассматривать как несколько взаимодействующих уровней:
- Полевой уровень: Датчики, исполнительные механизмы, приводы и другое физическое оборудование.
- Уровень управления: ПЛК и контроллеры, выполняющие детерминированную автоматизацию.
- Вычислительный уровень: Платформы MPU/SoC, обеспечивающие дополнительную вычислительную мощность.
- Уровень интеллектуальных функций: Машинное зрение, аналитика, выводы ИИ и другие вычислительные нагрузки.
- Уровень супервизорного управления: HMI, диагностика, управление событиями и операционные приложения.
- Уровень подключения: Промышленные сети и внешние коммуникационные сервисы.
- Базовый программный уровень: Операционная система реального времени, изоляция, планирование, управление ресурсами и механизмы восстановления.
Ключевое инженерное требование заключается в определении границ между этими уровнями, а не в рассмотрении всей вычислительной среды как единого недифференцированного пространства приложений.
Модернизация должна сохранять существующие инвестиции в системы управления
Промышленное оборудование часто сохраняет работоспособность на протяжении многих лет. Замена проверенного управления на базе ПЛК только потому, что стали доступны новые вычислительные возможности, не всегда оправдана с технической или экономической точки зрения.
Более практичная стратегия модернизации заключается в сохранении проверенных функций управления при добавлении вычислительных ресурсов вокруг них.
Платформы на базе MPU и SoC могут обеспечить вычислительную мощность, необходимую для современных HMI, ИИ, аналитики, визуализации и подключения, в то время как существующие ПЛК продолжают выполнять детерминированное управление.
Такой подход позволяет производителям внедрять новые возможности без неоправданного нарушения работы существующих архитектур управления.
Мой инженерный взгляд: отказоустойчивость начинается с архитектуры
Самый важный вывод этого перехода заключается в том, что отказоустойчивость нельзя добавить после того, как система уже была консолидирована.
Когда управление, сети, HMI, аналитика и ИИ используют общие вычислительные ресурсы, механизмы изоляции и восстановления должны быть заложены в исходную архитектуру.
Мощный процессор сам по себе не создаёт отказоустойчивую систему автоматизации. Аналогично, модель ИИ не делает систему автоматизации интеллектуальной, если окружающая платформа не может получать данные, выполнять модель, проверять её результаты, обеспечивать соблюдение заранее заданных политик и реагировать в пределах требуемых эксплуатационных ограничений.
Таким образом, следующее поколение промышленной автоматизации будет зависеть не только от более высокой вычислительной производительности, но и от того, насколько эффективно программная архитектура управляет взаимодействием между рабочими нагрузками.
Заключение
Промышленная автоматизация переходит к архитектуре, в которой ПЛК, высокопроизводительные процессоры, ИИ, средства подключения и программно-определяемые функции всё чаще работают совместно.
Это создаёт значительные возможности для модернизации, но также вводит новые зависимости и режимы отказа.
Отказоустойчивая архитектура должна сочетать детерминированное выполнение, изоляцию процессов, защиту памяти, контролируемый доступ к ресурсам, локализацию отказов, управление жизненным циклом кибербезопасности и определённые механизмы восстановления.
Операционные системы реального времени на базе микроядер, такие как QNX, представляют собой один из архитектурных подходов к этим требованиям. Используемые вместе с существующими технологиями ПЛК и контроллеров, такие платформы могут обеспечить программную основу, необходимую для интеграции современных вычислительных нагрузок при сохранении чётких границ критически важных функций автоматизации.
