Центр компетенций
АСУ ТП будущего: новая модель в России
Почему тема АСУ ТП снова стала актуальной? Чем сегодня ограничивается роль старой модели АСУ ТП? И почему эксперты отрасли всё чаще смотрят в сторону новой архитектуры, в основе которой виртуальный ПЛК? Рассказывает владелец продукта «Виртуальный контроллер» Айсорс Ян Сухих.
АСУ ТП будущего: новая модель в России
Почему тема АСУ ТП снова стала актуальной? Чем сегодня ограничивается роль старой модели АСУ ТП? И почему эксперты отрасли всё чаще смотрят в сторону новой архитектуры, в основе которой виртуальный ПЛК? Рассказывает владелец продукта «Виртуальный контроллер» Айсорс Ян Сухих.
За последние 30–40 лет базовая архитектура классической АСУ ТП изменилась не так сильно
Если проанализировать, как развивались системы крупнейших вендоров АСУ ТП – Rockwell, Siemens, Schneider Electric, Yokogawa и других, то кардинальных изменений за последние десятилетия в них нет. Менялись полевые шины, увеличивалась скорость, появлялось больше драйверов, росла мощность процессоров, увеличивался функционал, но это эволюционные и очень поступательные изменения. Рывков, как в ИТ, в АСУ ТП не было.
Происходило это по разным причинам. Среди них – критичность процессов, большая ответственность, нежелание и страх быстрых изменений в отрасли. Жили по принципу: работает – не трогай. Если функционала было достаточно, в системы старались не вносить изменения. Второй фактор – обслуживающий персонал: люди привыкают работать с одной системой и в дальнейшем им тяжело осваивать новый функционал, переходить на новые продукты. Другими словами, промышленная автоматизация – это достаточно консервативная отрасль. С одной стороны, это стабильность, с другой – застой, сегодня он сильно чувствуется.
Консерватизм в отрасли: Россия и Запад
На Западе новые технологии внедрялись охотнее – не так быстро, как в ИТ, но заказчики на Западе всегда были готовы к пилотам и внедрению на производствах. Причина – гонка за эффективностью: сегодня ты не используешь технологию – завтра её может внедрить конкурент.
В России при переговорах клиенты часто просят показать примеры внедрения на аналогичных установках. Однако, как правило, это невозможно: зачастую установки уникальны для российского рынка, а сама компания-интегратор работает только в России. В мире ситуация проще. Но в целом, консервативность в отрасли присутствует глобально.
Лидерство западных производителей
В своё время советская школа не выдержала конкуренции. Рынок заняли западные вендоры, которые продают и реализуют проекты в мировом масштабе – конкурировать с ними невозможно, так как у них доступ к глобальному рынку.
Кто-то из российских игроков находил ниши при государственных монополиях. У них получались специализированные решения. Они уступали западным, но были неплохими для своих задач. Перспективный путь здесь очевиден: если мыслить о стратегическом развитии продукта, его нужно выводить на мировой рынок.
Исторически сила классической АСУ ТП – в стабильности и надёжности
Проверенные и налаженные технологии меняются медленно. Они выполняют базовые функции, поэтому главный вопрос всегда в достаточности этих функций для производства и бизнеса. Например, лампочка: её можно включить или выключить простым устройством за 500 рублей, а можно поставить контроллер в резервированном исполнении за 5 млн рублей. Разницы для функции не будет – она продолжит выполняться, но бюджеты отличаются колоссально. Сейчас вопрос в том, что конкуренция внутри производственного сегмента нарастает глобально. Компании теперь борются за экономию денежных средств, повышение производительности – всё это достигается за счёт внедрения цифровых средств и автоматизации.
Ограничения старой модели
Они наступают при недостаточности возможностей ПАК. Здесь несколько моментов. Первое – задачи. Если они растут, например, уже нужно не просто управление, а аналитика – посчитать наработку на отказ, провести предиктивную аналитику на уровне установки – в этом случае классической АСУ ТП недостаточно. Она прекрасно выполняет заданную логику, будет работать десятилетиями, и это будет стабильно и надёжно. Но как только нужно расширить функционал, классические АСУ ТП ограничивают эту возможность. Другими словами, потребности в развитии стимулируют переход на АСУ ТП с новой архитектурой, чтобы не остаться за бортом.
Переход на АСУ ТП с новой архитектурой – это необходимость?
Самая большая проблема: если заказчику ничего не нужно. В этом случае продать даже самую совершенную модель по хорошей цене просто невозможно. Даже полезные продукты продать можно только тогда, когда заказчик осознаёт потребность в них.
Доказательство того, что новая технология даёт эффект – это сложная работа, мы её тоже делаем. На моей практике, формирование спроса в отрасли на новые технологии занимает примерно от 4-х лет – с примерами, чтобы в неё поверили. Всё начинается с большой и сложной просветительской работы.
Главный сдвиг: от устройства к платформе
Чтобы было понятнее, почему мы переходим к платформе, расскажу, что такое софт ПЛК и виртуальный ПЛК. Традиционно АСУ ТП – это почти всегда ПАК: есть «железо», на нём – софт, всё определённым образом сконфигурировано. Софт предварительно сконфигурирован вендором, всё чётко определено. С одной стороны, это удобно: есть ограниченный функционал, понятная инструкция и инженер работает по ней.
С виртуальными контроллерами, всё не так просто.
Когда мы смотрим на виртуальные ПЛК, ситуация сильно меняется. Мы «отвязываемся» от «железа» конкретного производителя. То есть у нас есть произвольное «железо», на нём нам нужно добиться такого же детерминированного поведения, как на ПАКах вендоров. Это требует гораздо большего количества настроек. Нужно разработать инструменты, которые позволяют пользователю, не погружаясь в глубины настроек операционной системы, удобно всё сконфигурировать и мониторить. Это большая и серьёзная работа. Когда мы переходим на «Виртуальный контроллер», нужно понимать, что это переход на полноценную новую экосистему. Она может развиваться эволюционно, сначала это средства конфигурирования, мониторинга, потом уже – средства разворачивания. В этом уже сближение с ИТ-миром. Эти технологии давно отработаны и применяются достаточно успешно, но требуют адаптации под специфику АСУ ТП.
Как родилась идея создания такой новой платформы?
Ко мне осознание такой возможности пришло в 2018 году. Я работал в R&D крупной международной компании, мы с коллегами обсуждали, что через 10 лет классические контроллеры будут активно заменяться. Уже в то время мы все понимали: нет больших различий между виртуальным и классическим решениями, как это было 20-30 лет назад.
Классическое «железо» развивается быстро, может работать десятилетиями. Явных преимуществ у классических контроллеров нет, за редким исключением. К исключениям можно отнести, например, специализированное применение – управление приводами, когда нужно координировать большое количество осей, или системы противоаварийной защиты.
Сегодня у обычных контроллеров нет никаких ограничений к их переводу на ИТ-шное «железо».
Виртуальный ПЛК и софт ПЛК в новой логике
Термин софт ПЛК появился давно. Он есть у многих вендоров, но, как правило, это эмулятор. Его можно запустить, загрузить на него программы, но он работает без детерминизма, то есть просто показывает, как действуют программы. Виртуальный – именно софт ПЛК, работает как классический контроллер, то есть детерминированно, надёжно и не привязан к «железу». Это больше платформа.
Простая замена ПЛК на промышленный ПК ещё не революция
Когда мы меняем центральный процессор (ЦПУ) классического контроллера на виртуальный ПЛК, ценность для заказчика не всегда очевидна. Здесь мы снова возвращаемся к вопросу задач. Если нужно просто управление, ценность объяснить проблематично: и то, и то делает свою работу.
Есть преимущества в части гибкости: при использовании классических контроллеров может быть сложно обеспечить поставки «железа», а промышленные ПК производят много где – как не блокируй поставки, ручеек всегда пойдёт. Ещё – это важно для производителя оборудования – можно подобрать оптимальный промышленный ПК под свои задачи по цене и функционалу.
Это может быть дешевле, чем использовать классические ПЛК.
Но основная ценность виртуального ПЛК в возможности сочетания разных функций в одном устройстве. Реализовали логику управления, далее можно добавить аналитику, сложную математику – например, для измерения количества и качества нефти, добавить локальную визуализацию.
Резюме: потребитель и заказчик должны понимать, что они хотят и зачем это делают. Как обоснование перехода на новую модель чаще всего заказчики выбирают снижение себестоимости или расширение функционала.
Детерминизм без специализированного «железа»
Наш проект с «Виртуальным контроллером» начался с того, что мы проверили, можно ли на классической операционной системе Linux (с Real Time патчем) добиться детерминированного поведения. Это была основа основ. Потому что использование специализированных операционных систем реального времени опять же увеличивает себестоимость конечного изделия, а в условиях дефицита разработчиков на рынке для не самых популярных операционных систем проект вышел бы ещё дороже. По сути разработчиков таких было почти не найти.
Мы провели много испытаний и доказали, что для архитектуры x86 в АСУ ТП время цикла от 1 миллисекунды – это абсолютно достижимая величина. На классической Linux с патчем реального времени мы получали его без проблем. Более того, мы получали даже десятки микросекунд в цикле, то есть с большим запасом! Так мы убедились: детерминизм возможен, просто есть нюансы в конфигурации и по работе с сетью. При этом всё решается путём настроек. Для некоторых техпроцессов можно взять обычную серверную Linux, запустить на ней «Виртуальный контроллер», и он будет выполнять работу в достаточном для них режиме. Если нужно гарантированное время до уровня миллисекунд, нужно произвести определённые настройки.
Виртуализация и real-time: границы возможного
Многие инженеры интуитивно не доверяют виртуализации в контуре управления. Действительно, сейчас к модели много недоверия и вопросов, и это понятно. Мы не доверяем тому, чего не знаем или не знаем достаточно хорошо. Что такое сегодняшняя виртуализация? Сейчас почти во всех системах есть поддержка аппаратной виртуализации. По сути, 99% всех задач выполняются на голом «железе», а гипервизор обеспечивает разделение этих ресурсов. Сейчас, когда запускаем машину на x86 и у нас нет эмуляции «железа» (то есть мы запускаем виртуальную машину с той же архитектурой, что и хост), результаты близки тем, когда запускаем нагрузку на голом «железе». Если всё правильно настроить, одну миллисекунду можно получить в виртуальных средах – для 99% АСУ ТП этого более чем достаточно.
Конечно, в целом это сложная тема, пока не все заказчики понимают, как всё работает. Из «коробки» такие системы, как правило, не работают, с другой стороны, мы проводили испытания с одним из партнёров – там на стандартных настройках гипервизора и мощном «железе» удавалось получить время цикла порядка нескольких миллисекунд, причём стабильно. Так что мощность системы может иногда компенсировать тонкость настройки. Для большинства процессов достаточно десятков или сотен миллисекунд, это значит, что такие ПАКи можно запускать в поле.
Требования к времени цикла в разных отраслях
Всё зависит от техпроцессов. Есть быстрые техпроцессы, их много в металлургии и машиностроении. Есть медленные – это нефтехимия и нефтепереработка. Для медленных процессов достаточно сотни миллисекунд: в больших системах – основные требования не к быстродействию, а к надёжности. В быстрых процессах свои специализированные задачи. Чаще всего это дискретные производства, здесь нужны единицы или десятки миллисекунд.
OT — это не просто ИТ
Интеграция ИТ- и ОТ-сред наблюдается. Как только мы примем, что ОТ-нагрузки могут работать на тех же серверах, на которых выполняется ИТ-нагрузка, останется только обеспечить безопасность функционирования сегмента и надёжные каналы связи до модулей ввода-вывода, которые работают с датчиками.
Какие есть проблемы и ограничения? Это доверие: нужно всё обкатывать и показывать, что это работает. Этот процесс небыстрый. Дальше – про преимущества. Для чего это нужно делать? Основная экономия не на оборудовании, а на стоимости владения системой. Если её посчитать на горизонте 3-5 лет, она уже существенно оптимизируется. За счёт чего? Общие закупки – покупаем «железо» у тех же поставщиков, у которых есть хорошие скидки и уже есть штат, который знает, как это оборудование обслуживать. Если внедряем практики «инфраструктура как код» (IaC), можем быстро расширять систему, масштабировать её. В случае проблем моментально восстанавливать её. Таким образом, мы унифицируем инфраструктуру, снижаем количество аппаратных и упрощаем топологию сети.
Такая унификация дальше даёт безопасность. Есть так называемый подход security through obscurity. Безопасность через неизвестность или неявность. Такой подход де-факто применяется ко всем «закрытым» сегментам АСУ ТП, говорим, что там всё безопасно, надёжные политики межсетевого экранирования, воздушные зазоры, диоды данных, но по факту мы не знаем, нет ли там незащищённой «лазейки» в корпоративный сегмент или Интернет. Если АСУ ТП – это сегмент в корпоративной сети, к нему автоматически можно применить все политики и инструменты, которые приняты в корпорации (конечно, с адаптацией под специфику АСУ ТП). Это позволяет добиться прозрачности и наблюдаемости сегмента, что при должном подходе только повышает итоговую защищённость.
Особая тема – это строительство отдельных демилитаризованных зон (ДМЗ) между АСУ ТП и корпоративной сетью. Интеграция есть везде – это опять же про ценность. После интеграции с корпоративными системами все поняли, что эту интеграцию нужно надёжно защитить. Строительства ДМЗ требует больших бюджетов, и на «возрастном» производстве это сложно сделать и физически. Сначала нужен аудит, потом грамотное планирование сетевой связанности, необходимо везде построить ДМЗ на российском железе и ПО. Это дорого. Когда всё в едином ЦОДе и разделено на логические сегменты, проще контролировать систему и управлять ею. В совокупности это даёт эффект, который может перекрыть стоимость АСУ ТП.
Дополнительный бонус – внедрение инструментов цифровизации становится фактически безграничным, потому что у нас всё в едином сегменте. За счёт настроек мы меняем топологию сети, можем обеспечить связность любых сегментов – это всё удобно. Будет ли это просто ИТ или нет? Никто не снимал ответственность с сегмента, так как простои и аварии стоят недёшево. Безусловно, со временем этот сегмент будет в зоне ответственности ИТ, но со своей командой, которая будет отвечать за политики, SLA и прочие вещи.
Читайте продолжение
Если проанализировать, как развивались системы крупнейших вендоров АСУ ТП – Rockwell, Siemens, Schneider Electric, Yokogawa и других, то кардинальных изменений за последние десятилетия в них нет. Менялись полевые шины, увеличивалась скорость, появлялось больше драйверов, росла мощность процессоров, увеличивался функционал, но это эволюционные и очень поступательные изменения. Рывков, как в ИТ, в АСУ ТП не было.
Происходило это по разным причинам. Среди них – критичность процессов, большая ответственность, нежелание и страх быстрых изменений в отрасли. Жили по принципу: работает – не трогай. Если функционала было достаточно, в системы старались не вносить изменения. Второй фактор – обслуживающий персонал: люди привыкают работать с одной системой и в дальнейшем им тяжело осваивать новый функционал, переходить на новые продукты. Другими словами, промышленная автоматизация – это достаточно консервативная отрасль. С одной стороны, это стабильность, с другой – застой, сегодня он сильно чувствуется.
Консерватизм в отрасли: Россия и Запад
На Западе новые технологии внедрялись охотнее – не так быстро, как в ИТ, но заказчики на Западе всегда были готовы к пилотам и внедрению на производствах. Причина – гонка за эффективностью: сегодня ты не используешь технологию – завтра её может внедрить конкурент.
В России при переговорах клиенты часто просят показать примеры внедрения на аналогичных установках. Однако, как правило, это невозможно: зачастую установки уникальны для российского рынка, а сама компания-интегратор работает только в России. В мире ситуация проще. Но в целом, консервативность в отрасли присутствует глобально.
Лидерство западных производителей
В своё время советская школа не выдержала конкуренции. Рынок заняли западные вендоры, которые продают и реализуют проекты в мировом масштабе – конкурировать с ними невозможно, так как у них доступ к глобальному рынку.
Кто-то из российских игроков находил ниши при государственных монополиях. У них получались специализированные решения. Они уступали западным, но были неплохими для своих задач. Перспективный путь здесь очевиден: если мыслить о стратегическом развитии продукта, его нужно выводить на мировой рынок.
Исторически сила классической АСУ ТП – в стабильности и надёжности
Проверенные и налаженные технологии меняются медленно. Они выполняют базовые функции, поэтому главный вопрос всегда в достаточности этих функций для производства и бизнеса. Например, лампочка: её можно включить или выключить простым устройством за 500 рублей, а можно поставить контроллер в резервированном исполнении за 5 млн рублей. Разницы для функции не будет – она продолжит выполняться, но бюджеты отличаются колоссально. Сейчас вопрос в том, что конкуренция внутри производственного сегмента нарастает глобально. Компании теперь борются за экономию денежных средств, повышение производительности – всё это достигается за счёт внедрения цифровых средств и автоматизации.
Ограничения старой модели
Они наступают при недостаточности возможностей ПАК. Здесь несколько моментов. Первое – задачи. Если они растут, например, уже нужно не просто управление, а аналитика – посчитать наработку на отказ, провести предиктивную аналитику на уровне установки – в этом случае классической АСУ ТП недостаточно. Она прекрасно выполняет заданную логику, будет работать десятилетиями, и это будет стабильно и надёжно. Но как только нужно расширить функционал, классические АСУ ТП ограничивают эту возможность. Другими словами, потребности в развитии стимулируют переход на АСУ ТП с новой архитектурой, чтобы не остаться за бортом.
Переход на АСУ ТП с новой архитектурой – это необходимость?
Самая большая проблема: если заказчику ничего не нужно. В этом случае продать даже самую совершенную модель по хорошей цене просто невозможно. Даже полезные продукты продать можно только тогда, когда заказчик осознаёт потребность в них.
Доказательство того, что новая технология даёт эффект – это сложная работа, мы её тоже делаем. На моей практике, формирование спроса в отрасли на новые технологии занимает примерно от 4-х лет – с примерами, чтобы в неё поверили. Всё начинается с большой и сложной просветительской работы.
Главный сдвиг: от устройства к платформе
Чтобы было понятнее, почему мы переходим к платформе, расскажу, что такое софт ПЛК и виртуальный ПЛК. Традиционно АСУ ТП – это почти всегда ПАК: есть «железо», на нём – софт, всё определённым образом сконфигурировано. Софт предварительно сконфигурирован вендором, всё чётко определено. С одной стороны, это удобно: есть ограниченный функционал, понятная инструкция и инженер работает по ней.
С виртуальными контроллерами, всё не так просто.
Когда мы смотрим на виртуальные ПЛК, ситуация сильно меняется. Мы «отвязываемся» от «железа» конкретного производителя. То есть у нас есть произвольное «железо», на нём нам нужно добиться такого же детерминированного поведения, как на ПАКах вендоров. Это требует гораздо большего количества настроек. Нужно разработать инструменты, которые позволяют пользователю, не погружаясь в глубины настроек операционной системы, удобно всё сконфигурировать и мониторить. Это большая и серьёзная работа. Когда мы переходим на «Виртуальный контроллер», нужно понимать, что это переход на полноценную новую экосистему. Она может развиваться эволюционно, сначала это средства конфигурирования, мониторинга, потом уже – средства разворачивания. В этом уже сближение с ИТ-миром. Эти технологии давно отработаны и применяются достаточно успешно, но требуют адаптации под специфику АСУ ТП.
Как родилась идея создания такой новой платформы?
Ко мне осознание такой возможности пришло в 2018 году. Я работал в R&D крупной международной компании, мы с коллегами обсуждали, что через 10 лет классические контроллеры будут активно заменяться. Уже в то время мы все понимали: нет больших различий между виртуальным и классическим решениями, как это было 20-30 лет назад.
Классическое «железо» развивается быстро, может работать десятилетиями. Явных преимуществ у классических контроллеров нет, за редким исключением. К исключениям можно отнести, например, специализированное применение – управление приводами, когда нужно координировать большое количество осей, или системы противоаварийной защиты.
Сегодня у обычных контроллеров нет никаких ограничений к их переводу на ИТ-шное «железо».
Виртуальный ПЛК и софт ПЛК в новой логике
Термин софт ПЛК появился давно. Он есть у многих вендоров, но, как правило, это эмулятор. Его можно запустить, загрузить на него программы, но он работает без детерминизма, то есть просто показывает, как действуют программы. Виртуальный – именно софт ПЛК, работает как классический контроллер, то есть детерминированно, надёжно и не привязан к «железу». Это больше платформа.
Простая замена ПЛК на промышленный ПК ещё не революция
Когда мы меняем центральный процессор (ЦПУ) классического контроллера на виртуальный ПЛК, ценность для заказчика не всегда очевидна. Здесь мы снова возвращаемся к вопросу задач. Если нужно просто управление, ценность объяснить проблематично: и то, и то делает свою работу.
Есть преимущества в части гибкости: при использовании классических контроллеров может быть сложно обеспечить поставки «железа», а промышленные ПК производят много где – как не блокируй поставки, ручеек всегда пойдёт. Ещё – это важно для производителя оборудования – можно подобрать оптимальный промышленный ПК под свои задачи по цене и функционалу.
Это может быть дешевле, чем использовать классические ПЛК.
Но основная ценность виртуального ПЛК в возможности сочетания разных функций в одном устройстве. Реализовали логику управления, далее можно добавить аналитику, сложную математику – например, для измерения количества и качества нефти, добавить локальную визуализацию.
Резюме: потребитель и заказчик должны понимать, что они хотят и зачем это делают. Как обоснование перехода на новую модель чаще всего заказчики выбирают снижение себестоимости или расширение функционала.
Детерминизм без специализированного «железа»
Наш проект с «Виртуальным контроллером» начался с того, что мы проверили, можно ли на классической операционной системе Linux (с Real Time патчем) добиться детерминированного поведения. Это была основа основ. Потому что использование специализированных операционных систем реального времени опять же увеличивает себестоимость конечного изделия, а в условиях дефицита разработчиков на рынке для не самых популярных операционных систем проект вышел бы ещё дороже. По сути разработчиков таких было почти не найти.
Мы провели много испытаний и доказали, что для архитектуры x86 в АСУ ТП время цикла от 1 миллисекунды – это абсолютно достижимая величина. На классической Linux с патчем реального времени мы получали его без проблем. Более того, мы получали даже десятки микросекунд в цикле, то есть с большим запасом! Так мы убедились: детерминизм возможен, просто есть нюансы в конфигурации и по работе с сетью. При этом всё решается путём настроек. Для некоторых техпроцессов можно взять обычную серверную Linux, запустить на ней «Виртуальный контроллер», и он будет выполнять работу в достаточном для них режиме. Если нужно гарантированное время до уровня миллисекунд, нужно произвести определённые настройки.
Виртуализация и real-time: границы возможного
Многие инженеры интуитивно не доверяют виртуализации в контуре управления. Действительно, сейчас к модели много недоверия и вопросов, и это понятно. Мы не доверяем тому, чего не знаем или не знаем достаточно хорошо. Что такое сегодняшняя виртуализация? Сейчас почти во всех системах есть поддержка аппаратной виртуализации. По сути, 99% всех задач выполняются на голом «железе», а гипервизор обеспечивает разделение этих ресурсов. Сейчас, когда запускаем машину на x86 и у нас нет эмуляции «железа» (то есть мы запускаем виртуальную машину с той же архитектурой, что и хост), результаты близки тем, когда запускаем нагрузку на голом «железе». Если всё правильно настроить, одну миллисекунду можно получить в виртуальных средах – для 99% АСУ ТП этого более чем достаточно.
Конечно, в целом это сложная тема, пока не все заказчики понимают, как всё работает. Из «коробки» такие системы, как правило, не работают, с другой стороны, мы проводили испытания с одним из партнёров – там на стандартных настройках гипервизора и мощном «железе» удавалось получить время цикла порядка нескольких миллисекунд, причём стабильно. Так что мощность системы может иногда компенсировать тонкость настройки. Для большинства процессов достаточно десятков или сотен миллисекунд, это значит, что такие ПАКи можно запускать в поле.
Требования к времени цикла в разных отраслях
Всё зависит от техпроцессов. Есть быстрые техпроцессы, их много в металлургии и машиностроении. Есть медленные – это нефтехимия и нефтепереработка. Для медленных процессов достаточно сотни миллисекунд: в больших системах – основные требования не к быстродействию, а к надёжности. В быстрых процессах свои специализированные задачи. Чаще всего это дискретные производства, здесь нужны единицы или десятки миллисекунд.
OT — это не просто ИТ
Интеграция ИТ- и ОТ-сред наблюдается. Как только мы примем, что ОТ-нагрузки могут работать на тех же серверах, на которых выполняется ИТ-нагрузка, останется только обеспечить безопасность функционирования сегмента и надёжные каналы связи до модулей ввода-вывода, которые работают с датчиками.
Какие есть проблемы и ограничения? Это доверие: нужно всё обкатывать и показывать, что это работает. Этот процесс небыстрый. Дальше – про преимущества. Для чего это нужно делать? Основная экономия не на оборудовании, а на стоимости владения системой. Если её посчитать на горизонте 3-5 лет, она уже существенно оптимизируется. За счёт чего? Общие закупки – покупаем «железо» у тех же поставщиков, у которых есть хорошие скидки и уже есть штат, который знает, как это оборудование обслуживать. Если внедряем практики «инфраструктура как код» (IaC), можем быстро расширять систему, масштабировать её. В случае проблем моментально восстанавливать её. Таким образом, мы унифицируем инфраструктуру, снижаем количество аппаратных и упрощаем топологию сети.
Такая унификация дальше даёт безопасность. Есть так называемый подход security through obscurity. Безопасность через неизвестность или неявность. Такой подход де-факто применяется ко всем «закрытым» сегментам АСУ ТП, говорим, что там всё безопасно, надёжные политики межсетевого экранирования, воздушные зазоры, диоды данных, но по факту мы не знаем, нет ли там незащищённой «лазейки» в корпоративный сегмент или Интернет. Если АСУ ТП – это сегмент в корпоративной сети, к нему автоматически можно применить все политики и инструменты, которые приняты в корпорации (конечно, с адаптацией под специфику АСУ ТП). Это позволяет добиться прозрачности и наблюдаемости сегмента, что при должном подходе только повышает итоговую защищённость.
Особая тема – это строительство отдельных демилитаризованных зон (ДМЗ) между АСУ ТП и корпоративной сетью. Интеграция есть везде – это опять же про ценность. После интеграции с корпоративными системами все поняли, что эту интеграцию нужно надёжно защитить. Строительства ДМЗ требует больших бюджетов, и на «возрастном» производстве это сложно сделать и физически. Сначала нужен аудит, потом грамотное планирование сетевой связанности, необходимо везде построить ДМЗ на российском железе и ПО. Это дорого. Когда всё в едином ЦОДе и разделено на логические сегменты, проще контролировать систему и управлять ею. В совокупности это даёт эффект, который может перекрыть стоимость АСУ ТП.
Дополнительный бонус – внедрение инструментов цифровизации становится фактически безграничным, потому что у нас всё в едином сегменте. За счёт настроек мы меняем топологию сети, можем обеспечить связность любых сегментов – это всё удобно. Будет ли это просто ИТ или нет? Никто не снимал ответственность с сегмента, так как простои и аварии стоят недёшево. Безусловно, со временем этот сегмент будет в зоне ответственности ИТ, но со своей командой, которая будет отвечать за политики, SLA и прочие вещи.
Читайте продолжение