Открытая АСУ ТП. Второе интервью об открытой АСУ ТП

Различия между IT и АСУ ТП

Моя работа в течение нескольких лет была связана с внедрением в промышленной компании систем класса СУУ ТП. СУУ ТП (APC) - это системы, которые находятся на границе между АСУ ТП и MES-системами, между IT и OT.

Опыт внедрения таких систем навёл меня на вопросы: почему в промышленности нижний уровень систем управления такой закрытый и ограниченный по функциональности, гибкости и дружелюбности к пользователю? Ведь IT-системы за последние 10-15 лет ушли далеко вперед в этих аспектах, они, на мой взгляд, более доступны рядовому пользователю и в меньшей степени требуют обладания специфическими техническими знаниями и навыками. Так, например, языки программирования всё больше приближаются к человеку, становятся всё более интуитивно понятными, всё более простыми для интерпретации обычным человеком.

В АСУ ТП такой тренд почти не заметен. На мой взгляд, причина этому - та бизнес-логика, которую выбрали для себя основные поставщики решений АСУ ТП. Они выбрали путь проприетарных, вертикально интегрированных, закрытых для внесения изменений систем.

Каждый из производителей создал свою собственную среду разработки, свою среду исполнения программ, свой способ “привязывания” программной части к аппаратной, свои протоколы, шины передачи данных и т.п.

Эта закрытость сильно отличает АСУ ТП от мира IT. В IT мы видим тренд на сквозную стандартизацию, упрощение способов и подходов к программированию - все для вовлечения максимально возможного числа специалистов в программирование с минимальным пороговым входом по компетенциям.

В АСУ ТП круг специалистов, которые умеют работать с определенными системи, достаточно узкий. Это специализированная “каста” проектировщиков, программистов, разработчиков и инженеров АСУ ТП.

Концепция ОАСУ ТП

Концепция, предлагаемая стандартом OPAS, на которую опирается Рабочая группа по открытой АСУ ТП, предполагает перенос принципов IT на уровень АСУ ТП. Она исключает необходимость специфического проприетарного языка для обмена информацией между разными компонентами системы - нужен один неуникальный протокол на одной неуникальной шине. Нет жесткой привязки программных средств к аппаратным. Среда исполнения должна быть переносима между решениями разных поставщиков оборудования и ПО.

Эффекты от открытой АСУ ТП

Такие подходы, по экспертной оценке, позволили бы на этапе строительства новых систем и модернизации экономить от 50% до 70% от стоимости на внедрение и владение системами АСУ ТП.

Во-первых, это привело бы к снижению цен на решения за счет усиления конкуренции на рынке между многими поставщиками. Вместо десяти поставщиков больших вертикально интегрированных решений появились бы сотни поставщиков небольших взаимозаменяемых компонентов этих решений.

Во-вторых, на этапе эксплуатации этих систем можно было бы сэкономить при необходимости их расширения и модернизации за счет возможности применения компонент решений от различных поставщиков и переносимости конфигураций, написанных ранее и не требующих повторного написания под “новое” программно-аппаратное обеспечение, предложенное конкретным поставщиком.

Проникновение принципов IT на уровень управления производством - это будущее, которое, на мой взгляд, неизбежно.

Открытая АСУ ТП и риски

Во всем важен принцип разумности. Действительно, в отраслях, которые являются основными потребителями решений АСУ ТП, есть опасные производства, связанные с техногенными рисками. Специально для категорирования подобных объектов создана методика категорирования по УПБ (SIL). Есть разные категории контуров управления по степени риска, опасности. По статистике одной из международных организаций, а также по статистике, которую приводили коллеги из “Газпром нефти”, к высоко ответственным на заводах нефтехимии и химии относятся порядка 10-20% контуров управления. Если добавить еще процессы средней значимости, то это 50 - 55% в совокупности. Встает вопрос, зачем необходимо покупать специфические дорогие проприетарные решения управления для 100% контуров? Для контуров, которые не относятся к высоким и средним категориям УПБ, можно использовать более дешевые и более гибкие системы. Такие системы в меньшей степени вендорозависимые и подверженные санкционным рискам.

Сейчас, когда есть сложности с поставкой решений мировых вендоров и их обслуживанием, необходимо переходить на что-то иное. Зачем переходить на то, что уже было, с точки зрения логики? Можно перевести 50% контуров на обслуживание с помощью более дешевых и более гибких IT решений.

Внедрение систем OPAS дает на горизонте 15-20 лет по снижению стоимости TCO на уровне 70-75% и существенно меняют конфигурацию рисков для потребителей этих решений.

Темпы развития IT, риски отставания

Темпы развития IT ускоряются, технологический стек в этой области за последние пару десятков лет, на мой взгляд, сменился минимум трижды. Далее смена технологического стека будет происходить все чаще. Если мы будем продолжать использовать закрытые проприетарные архитектуры решений, то, если сейчас наши решения морально и технологически устаревают за десять лет, то через десять лет они будут устаревать за три года.

Ускорение IT и смены технологических стеков - это один из факторов, который заставляет нас менять подход к архитектуре. Иначе системы просто не будут успевать окупаться до момента, когда их нужно будет менять на новые.

Виртуализация и кластеризация

В АСУ ТП слабо используется потенциал кластеризации и виртуализации. Эти технологии могут помочь сделать системы АСУ ТП более надежными и эффективными. Есть, конечно, альтернативный подход - чем больше компонентов мы добавляем в систему, тем менее надежной она становится. При этом в IT, в целом, виртуализация и кластеризация используется в не менее ответственных процессах, например - в финансовых системах.

Уверен, что эти две технологии неизбежно проникнут в рынок АСУ ТП. Уже сегодня такие “классические” вендоры АСУ ТП, как Siemens, используют эти принципы. Например 1500-ый контроллер Siemens внутри виртуализирован, там используется виртуальная машина. Вендоры также боятся сегодня зависимости от производителей чипов, это тоже риски, их риски. Даже “гранды” автоматизации сегодня идут по пути диверсификации рисков через виртуализацию ПО.

Открытость и опенсорс

Это дискуссионный вопрос. Правильно было бы вспомнить о том, как развивался LInux. Была запущена разработка ядра системы на открытом коде. Цель открытости была в том, чтобы разделить трудозатраты на создание продуктов.

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

Открытость кода на этапе создания ядра важна, но в дальнейшем должны появляться закрытые “форки”. Должен быть кто-то, кто отвечает за эти решения на стороне разработчиков. Для нас как для потребителей важно, чтобы эти продукты были переносимы между разными аппаратными платформами, разными операционными системами. А открытость кода не очень важна, на мой экспертный взгляд.

Открытая АСУ ТП и дискретные производства

У каждой отрасли, каждого производства есть свои болевые точки в области АСУ ТП. В химии, нефтехимии, в основном, используются РСУ, где больше программной составляющей. У металлургов вычисления сильно разбросаны по “полю”, вычислительные модули размещены максимально близко к объектам управления. Там нет такой большой программной обвязки. При этом, и у химиков, и у металлургов есть общая боль - ранее привычные решения больше не поставляются и не поддерживаются. Открытая архитектура АСУ ТП покрывает весь спектр болей и проблем. Неспецифичность и общность протокола передачи данных, шины, переносимость среды исполнения между разными программно-аппаратными платформами - все это, как мне кажется, актуально для всех.