Независимость от вендоров как основа безопасности

Проприетарные ИТ-системы используются во многих отраслях, несмотря на то, что ставят конечных пользователей в зависимость от конкретного производителя. Рассмотрим, что можно сделать в нынешних условиях для положительных изменений.

В настоящее время многие компании в разных отраслях столкнулись с так называемой проблемой "вендор локов", или зависимости от проприетарных (нестандартизованных) решений конкретных фирм. Как это выглядит? Например, вы не можете поменять контроллер одной фирмы локальной сети устройств на контроллеры других брендов из-за того, что оконечные устройства и контроллер связаны нестандартным, проприетарным протоколом. Или не можете подключить этот контроллер в шину данных, так как для подключения нужен конвертер с его протокола на стандартные. В обоих описанных случаях мы сталкиваемся с желанием некоторых фирм заработать на продаже как можно большего ассортимента программ и аппаратной части. И да, нестандартные разъемы кабелей одного очень известного бренда смартфонов тоже относятся к этому.

Я изложу свое видение, с упором на промышленную автоматизацию как отрасль, наиболее зависимую от вендоров.

Предыстория

На рынке систем промышленной автоматизации с самого начала и до наших дней фактически не была законодательно или хотя бы на уровне отраслевых норм закреплена стандартизованная архитектура программно-аппаратных комплексов всех уровней и протоколов обмена данными. Каждый крупный вендор систем промышленной автоматизации стремился создать свою экосистему на всех уровнях, защищая ее от проникновения решений других фирм методом использования закрытых протоколов обмена данными, закрытых сред разработки прикладного программного обеспечения (ППО) и т.д. Цель проста и понятна – заработать максимум денег на продаже всего программно-аппаратного комплекса.

Плюсы такого подхода

Как ни странно, но они есть.

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

Во-вторых, это заранее продуманная совместимость всех уровней системы. Программируемый логистический контроллер (ПЛК) будет точно исполнять прикладное ПО, написанное в среде разработки. Локальная система управления будет хорошо совместима с распределенной. Хранилище данных уровня MES без проблем заберет данные с уровня распределенных систем управления и т.д.

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

Минусы проприетарных систем

Их куда больше, чем плюсов.

Во-первых, это "зависимость" от вендора. Если вышел из строя какой-то узел системы, то менять надо именно на узел этого производителя. А если производитель обанкротился, перестал поставлять в страну, перестал выпускать эту линейку оборудования?

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

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

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

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

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

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

В-восьмых, необходимость переписывания прикладного ПО при переходе на решения других вендоров. Хорошо, если у вас есть описания работы технологического режима оборудования. А если нет и его, то вам придется проводить еще и реверс-инжиниринг технологического процесса.

Что делать?

После анализа плюсов и минусов проприетарных систем первый логичный вопрос: как от них избавиться?

Борьба с "вендор-локами" началась давно. Во многих странах и отраслях были созданы ассоциации, разрабатывающие открытые стандарты.

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

Но не ради одной только открытости пишутся новые стандарты промышленной автоматизации.

В рамках проектов цифровизации в последние годы во многих крупных компаниях активно внедряются такие "надстройки" над базовой автоматизацией, как APC (Advanced Process Control), МПА (модульная процедурная автоматизация), RTO (Real-Time Optimization). Все они образуют контур СУУТП (система усовершенствованного управления технологическим процессом).

Сейчас рекомендуется выносить работу подобных систем как можно ближе к месту получения и потребления данных, реализуя концепцию Edge (граничных вычислений). Это позволяет повысить скорость работы систем и значительно снизить нагрузки на сети передачи данных.

Стандартная архитектура АСУТП, реализованная в проектах базовой автоматизации, не была рассчитана на такой набор инструментов. В ней нет необходимых инфраструктуры, стека DevOps, платформы управления Edge-уровнем, мер обеспечения информационной безопасности.

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

Как делать?

Я считаю, что начать стоит с написания функционально-технических требований (ФТТ) к целевому стеку систем АСУТП + СУУТП + MES + ERP, которые вы видите у себя в компании. ФТТ лягут в основу проработки целевой архитектуры нового ИТ + АСУТП ландшафта предприятия. В рамках разработки архитектуры обязательно составить модель угроз и на ее основе заложить все меры обеспечения информационной безопасности. Ключевой посыл: уровень информационной безопасности (ИБ) в новой системе должен быть даже лучше, чем в существующих.

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

После разработки целевой архитектуры следует пройти стандартный путь создания цифрового продукта. Те сервисы, которые имеются на рынке и отвечают ФТТ системы, можно взять как есть. Сервисы, которых нет, придется разработать самим. Доля готовых решений на рынке также определяется тем, как мы составили целевую архитектуру.

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

Заключение

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

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

Такая картина уже давно наблюдается, например, в телекоммуникациях, когда нет проблемы поменять коммутатор одного производителя на другой. Коммутаторы всех вендоров работают с любыми маршрутизаторами и т.д. Пора и в АСУТП прийти к такому состоянию.

Опубликовано в журнале "Системы безопасности" № 1/2024

Все статьи журнала "Системы безопасности"
доступны для скачивания в iMag >>

Фото: ru.freepik.com