ИИ в разработке АСУ ТП: человеческий фактор, презумпция недоверия и смешанная критичность

Термин «смешанная критичность» довольно узкий и предполагает знание стандартов, поэтому сначала скажем немного об использовании ИИ в ответственных применениях в целом.
Мы — разработчики программного обеспечения, поэтому рассказываем о применении ИИ-технологий в средах и средствах разработки АСУ ТП.

Во-первых, в комнате слон, которого, как принято, не замечают. Замечают успехи ИИ, а они распространяются на все области, включая такую консервативную, как АСУ ТП.
Про слона — потом. А о применении технологий ИИ в АСУ ТП уже рапортуют во многих направлениях:
• разработка кода на языках стандарта МЭК 61131-3;
• отладка и документирование;
• разработка драйверов полевых протоколов и карт регистров;
• проектирование и тестирование.

Не пускают ИИ (пока?) только в ПАЗ — противоаварийную автоматическую защиту. Во всех остальных случаях говорится о том, что человек, конечно, должен оставаться последней инстанцией в принятии решений и создании функций. Его оставляют ответственным и арбитром.

Обычно при внедрении новых технологий первой в бой вступает служба информационной безопасности, но нас сейчас интересует безопасность функциональная.
Умные дяди предлагают читать стандарты и понимать разницу между МЭК 61508 (функциональная безопасность) и МЭК 62443 (информационная безопасность промышленных систем), а самые умные приводят ещё МЭК 61511 для непрерывных производств. Но это сложно, долго и скучно. Поэтому в нашем контексте ограничимся тремя тезисами:
• Абсолютной безопасности (нулевого риска) не существует. Даже «по ГОСТу с тройным запасом». Цель функциональной безопасности — снизить риск аварии до уровня, который мы считаем приемлемым.
• Поэтому ключевая задача — предотвращать опасные отказы либо безопасно ими управлять.
• В программном обеспечении нужно бороться с двумя типами рисков: ошибками проектирования, когда алгоритм задуман неправильно, и ошибками реализации, когда задумано верно, но сделано криво.
Всё это раньше называлось «человеческий фактор». С ним боролись регламенты, ГОСТы, сертификация, управление жизненным циклом ПО. А потом пришёл ИИ.

В разработку приходят большие языковые модели (LLM), ИИ-агенты, машинное обучение и дополненный контекст (RAG). Кажется, что человеческий фактор заменяется автоматизацией, а ГОСТы просто сломаны.
Заострим проблему: а ушёл ли человеческий фактор? Раньше проблема жизненного цикла ПО была связана, например, с удержанием в штате конкретного специалиста, который проектировал и кодировал. Он мог ошибиться, но он владел этим кодом. Теперь ситуация иная: код генерирует агент, а специалист изначально не владеет этим кодом — он лишь формулировал задание на естественном языке.

Способен ли обычный инженер вообще контролировать работу ИИ-агента? Вспомним знаменитый закон Артура Кларка: любая достаточно развитая технология неотличима от волшебства. Психология работает против нас: чем умнее становятся модели и безошибочнее агенты, тем выше доверие к их результатам — хотя в них принципиально заложены вероятность ошибки, недетерминированность и деградация.

Когнитивная капитуляция — склонность человека перестать проверять результат работы ИИ, потому что результат выглядит убедительно: код работает, тесты проходят.

Ирония в том, что ИИ по определению — это имитация когнитивной деятельности человека. Чему же удивляться, если ОТ-инженеры будут использовать ИИ по прямому назначению — для имитации собственной деятельности (ИТ уже использует)? Лень ведь двигатель прогресса.

Поэтому можно утверждать, что развитие ИИ-технологий в разработке не устраняет человеческий фактор за счёт алгоритмизации, а кратно его увеличивает. Это и есть наш слон в комнате.

Давайте попробуем в этой токсичной ситуации сохранить принципы функциональной безопасности при разработке АСУ ТП. Итак, у нас презумпция недоверия ко всему, к чему прикасался ИИ. С недоверенными узлами мы работать умеем — через:
• внедрение функций безопасности;
• сегментирование. Делим систему на зоны с разным уровнем доверия — как на режимном объекте: есть «чистая зона», есть буфер, есть периметр. В терминах МЭК 62443 это зоны и каналы (zones and conduits), а с точки зрения функциональной безопасности — функции с разным уровнем полноты безопасности (Safety Integrity Level, SIL): от SIL 3 до функций без SIL;
• детальное регламентирование жизненного цикла: кто, что, когда и как делает; кто имеет право менять код; кто проверяет; кто подписывает.

Подробнее о подходе «никому не доверяй» в промышленных системах — в нашей статье о Zero Trust.

Перейдём к практике и покажем, как подключить команду ML-разработчиков к работе в контурах АСУ ТП.

Представьте конкретную задачу: мы хотим, чтобы ML-модель оптимизировала режим работы установки на НПЗ. Модель постоянно обучается на потоках данных, её экономический эффект неоспорим, но она недетерминирована, и в неё по определению заложена возможность ошибок и деградации.

Можно ещё повысить ставки и дать ИТ-команде полную свободу: использовать любые параметры работающих технологических процессов и проверять гипотезы в реальном времени.

Мы построим архитектуру на базе открытых стандартов. И не потому, что многие закрытые решения сегодня недоступны, а потому, что в открытых стандартах заложены нужные нам функции, которые мы постараемся использовать по максимуму.

Представьте, что мы проектируем распределённую систему управления как единый проект в стандарте МЭК 61499.
Её «сердце» — ПЛК с детерминированным управлением, расположенные в технологической сети передачи данных (ТСПД) — защищённом сегменте, куда нет доступа извне.

А рядом, в демилитаризованной зоне (ДМЗ) — буфере между технологической сетью и ИТ-разработкой — работает виртуальный контроллер (vPLC). На нём крутятся ML-модели: предиктивная аналитика, оптимизация режимов, рекомендации по управлению. Этот виртуальный контроллер не имеет SIL — и не должен (на схеме он обозначен как non-SIL). В качестве среды исполнения функциональных блоков в ДМЗ можно использовать, например, нашу открытую платформу OpenFB.

Связь между ресурсами внутри этого единого проекта осуществляется по протоколу OPC UA.

Смешанная критичность (mixed criticality) — ситуация, когда в одной системе работают функции с разным уровнем полноты безопасности (SIL).

Согласно МЭК 61508, наша архитектура подпадает именно под этот случай. Если функции с разным SILобъединены и их независимость не доказана, всё ПО придётся разрабатывать по требованиям наивысшего SIL— иначе для системы в целом можно будет подтвердить лишь наименьший уровень. Доказать независимость — значит показать строгую пространственную и временную изоляцию функций.

Мы сейчас формально ничего доказывать не будем, просто постараемся проследить.

Прежде всего, OPC UA хорошо поддерживает надёжное зонирование. Коммуникацию через межсетевой экран между ДМЗ и ТСПД можно настроить строго в одном направлении (так называемый Data Diode — информационный диод) или так, чтобы она инициировалась исключительно снизу вверх — от доверенного сегмента к недоверенному.

Если vPLC передаёт управляющие команды, способные повлиять на безопасность процесса, ПЛК с SIL должен иметь возможность проигнорировать данные из ДМЗ и безопасно продолжить работу автономно. Логика ПАЗ должна содержать жёсткие граничные проверки, которые современные стандарты классифицируют как функции безопасности.
Чтобы обнаруживать потерю пакетов, задержки и искажение данных и при необходимости переводить процесс в безопасное состояние, поверх обычного OPC UA можно развернуть профиль OPC UA Safety (OPC 10000-15). Он работает по принципу «чёрного канала», поэтому требования предъявляются не к сети, а к конечным устройствам: понадобятся контроллеры и программный стек с поддержкой этого профиля.

Перейдём на уровень среды разработки (IDE), например Eclipse 4diac или ForgeLogic, где создаётся наш проект. В ней уже встроены логические барьеры через архитектурное понятие «ресурса». Функциональные блоки с разным уровнем SIL привязываются к изолированным ресурсам, а их взаимодействие происходит исключительно через стандартизованные сервисные интерфейсные блоки (Service Interface Function Blocks, SIFB).

Не будем углубляться в принципы разделения ресурсов. Достаточно сказать, что этот открытый стандарт позволяет применять формальные методы при проектировании распределённых систем управления, где взаимодействуют недетерминированные ML-модели из ДМЗ и жёсткая логика в ТСПД. Математическая верификация существенно сокращает объём классического тестирования и делает доказательство безопасности строже.

Головная боль интеграторов — не только надёжность распределённых систем, но и сложность их администрирования и развития.

Здесь стандарт МЭК 61499 тоже играет решающую роль: он создаёт единое онтологическое пространство. Сложнейший ML-алгоритм из мира ИТ и классический ПИД-регулятор из мира инженеров выглядят в системе одинаково — как функциональные блоки со стандартизованными интерфейсами. Это резко снижает когнитивную нагрузку на инженеров при проектировании.

При этом мы полностью соблюдаем изоляцию среды разработки. ИИ-агенты и ИТ-разработчики строго ограничены в правах: у них нет физической возможности изменить логику в контроллерах SIL 3. Но и дата-сайентисты, и инженеры АСУ ТП комфортно работают в единой системе контроля версий проектов.

Например, весь код, созданный ИИ, можно маркировать. В ИТ такая маркировка уже становится проблемой: растёт доля кода, который нельзя использовать в ответственных системах. Для ОТ, в том числе на значимых объектах критической информационной инфраструктуры (ЗОКИИ), это приемлемо, когда функции разнесены: помеченный код работает только в ДМЗ и не попадает в контур SIL.

Первое. ИИ в промышленной автоматизации — не будущее, а настоящее. Он уже здесь и будет только мощнее. Вопрос не в том, пускать ли его, а в том, как пускать безопасно.

Второе. Человеческий фактор никуда не денется: слон пришёл и не уйдёт. Он оказался полностью готов к новой автоматизации. Наша задача — строить архитектуру, которая учитывает не только ошибки человека, но и ошибки человека, слепо доверяющего ИИ.

Третье. Решения существуют, и для них есть открытые стандарты: МЭК 61508, МЭК 61499, OPC UA.

Бояться неправильного использования ИИ нужно. Но будем бояться правильно.

Проектируете АСУ ТП с ML-компонентами или хотите внедрить ИИ в разработку, не жертвуя функциональной безопасностью? Обсудим вашу архитектуру — команда ЦПР РТСофт разрабатывает ПО для промышленной автоматизации на открытых стандартах.

Можно ли использовать ИИ в АСУ ТП?
Да, но не напрямую в контурах безопасности. ИИ уже помогает писать код на языках МЭК 61131-3, документировать проекты, разрабатывать драйверы и тестировать. Разработки с помощью ИИ и ML-модели размещают в отдельной зоне (ДМЗ), последнее слово остаётся за детерминированной логикой ПЛК и ПАЗ.

Что такое смешанная критичность по МЭК 61508?
Это ситуация, когда в одной системе объединены функции с разным уровнем полноты безопасности (SIL). Если не доказана их пространственная и временная изоляция, всё ПО нужно разрабатывать по требованиям наивысшего SIL.

Можно ли применять ИИ в системах ПАЗ?
Сегодня — нет. Логика противоаварийной защиты должна быть детерминированной и верифицируемой, а ML-модели недетерминированы и подвержены деградации. ИИ может давать рекомендации, но ПАЗ обязана их проверять и при необходимости игнорировать.

Как изолировать недоверенные алгоритмы от контроллеров с SIL?
Разместить их на виртуальном контроллере в ДМЗ, связать с технологической сетью через OPC UA с односторонней передачей данных или с инициированием соединения только из доверенного сегмента, а в ПЛК и ПАЗ предусмотреть граничные проверки всех уставок, приходящих из ДМЗ.

Зачем МЭК 61499 при внедрении ИИ в АСУ ТП?
Стандарт позволяет описать распределённую систему как единый проект, разнести функции с разным SIL по изолированным ресурсам, применять формальные методы контроля изоляции и представить ML-алгоритмы и классические регуляторы одинаково — как функциональные блоки со стандартными интерфейсами.