Промышленные АСУ ТП в РФ: риски, проблемы и решения. Взгляд промышленных компаний

Главным риском является потенциальная невозможность обеспечивать технологические процессы, угроза остановки производства по причине недоступности/ трудностей с поставками элементной базы, запчастей, лицензий по ПО, обновлений, технической поддержки. 

Большинство участников опроса отмечает проблемы с железом, элементной базой. 

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

“(Есть) трудности с выбором программного и хардварного обеспечения для тех систем, которые мы собирались менять. Мы ранее планировали сделать это с помощью Сименс и Schneider. Но сейчас выбора практически нет. У российских ПЛК нет необходимых нам вещей”.

Помимо недоступности элементной базы и запчастей, респондентами был выделен такой риск, как длительные сроки поставки, что создает серьезные проблемы при выходе из строя оборудования и необходимости оперативного ремонта. Следствием длительных сроков поставки является “значительный простой технологического оборудования при замене старых систем”.
“Когда мы модернизируем или обновляем какой-то участок, мы заранее закладываем более длительные сроки поставки. Но если что-то выходит из строя в операционной деятельности, то там длительная поставка играет критическую роль”.

Риском является и прекращение гарантийного обслуживания оборудования западными вендорами. 

К существенным рискам опрошенные относят зависимость от проприетарных решений вендоров —  “vendor lock”, невозможность безболезненного перехода на решения других вендоров из-за  проприетарных протоколов, в частности — Profibus. Наличие разнородных проприетарных систем создает трудности для их интеграции.
“Первое — это vendor lock: зависимость от одного проприетарного (решения) вендора, когда запчасти другого вендора практически напрямую относятся на производителя”.

Риском являются ограниченные производственные возможности российских вендоров. Они физически не могут удовлетворить объем спроса. В результате возникает дефицит предложения и начинается конкуренция между заказчиками.

Другой проблемой является ограниченный модельный ряд ПЛК отечественных вендоров. Также участники отметили их технологическое отставание.

Если отечественные решения и присутствуют на рынке, то есть проблема с их апробацией.  
“Нет апробации применения российских решений. Можно нарваться на сырые решения”.

Были отмечены риски, связанные с низким уровнем информационной безопасности в АСУ ТП.
“(Риском является) отсутствие встроенных средств информационной безопасности в классических решениях. Иначе необходимы два разных решения: АСУ ТП и наложенные средства инфобеза”.

В области ПО были отмечены риски, связанные с невозможностью параллельного импорта лицензионного ПО, получения новых лицензий, официальной поддержки от вендоров. Непредоставление патчей создает угрозу информационной безопасности.
“Для того, чтобы контролировать риски, очень важно иметь своевременное обновление ПО. Это риск в поддержке критической инфраструктуры”.

Дефицит кадров и компетенций является еще одним риском. Дефицит подготовленных кадров приводит к конкуренции за них как между предприятиями, так и между предприятиями и вендорами.

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

К регуляторным рискам участники отнесли “дефициты в формулировках регулирования”.
“В различных отраслях существует различное регулирование, понятийный аппарат не синхронизирован. Например, определение ПАК различается в определениях Минцирфы, Минэнерго,  ФСТЭК”.

Также регуляторный риск создается дефицитом нормативной базы.

Участники отметили, что для митигации рисков,  связанных с поставками аппаратной части, ЗИПов и комплектующих, они прибегают к параллельному импорту. Но это является только временным решением проблемы.

“Это пластырь, но не решение проблемы. Сейчас вопрос решен по ЗИПам, по обеспечению текущих систем, строительства новых объектов. Но это не касается истории с новой АСУ ТП”.

Решение проблем по компонентной базе относится к прерогативе вендоров и государства.

“Мы скорее принимаем этот риск. Мы не можем поучаствовать а увеличении производственных мощностей по производству железа”.

“Митигация риска по компонентной базе — это прерогатива вендоров”.

При этом респонденты отмечают, что на данный момент острой проблемы с компонентной базой и ЗИПами нет, поскольку заранее были созданы складские запасы.

“В принципе, у нас складские запасы созданы. В течение десяти лет мы себя достаточно уверенно чувствуем”.

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

Но подходы к стратегии импортозамещения у компаний разные. Ряд компаний уже подготовился к такому переходу.

“У нас есть каталоги решений для критичных схем, реестры ОВП (основных видов продукции) — по ним ведется апробация российской продукции. Мы наполнили наши каталоги более, чем на 90% российскими решениями. Наша внутренняя готовность позволяет более, чем на 90% укомплектовать новые строящиеся объекты российскими решениями”. 

“На всех уровнях нашей компании мы приняли решение о том. что применяем только российские технологии”.

Другие участники придерживаются более сдержанной стратегии импортозамещения.

“У нас стратегия не кардинальная. Мы не рассматриваем стратегию полностью перейти на отечественных производителей: Мы проводим осторожную политику в области импортозамещения”.

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

“Наверное, в этом году у нас появятся пилотные внедрения. Сейчас мы создаем испытательную лабораторию. Планируем эти решения тестировать”.

“Мы идем в сторону перехода на одну из российских платформ. У нас открыт пилотный проект. С июня 2023 мы начинаем  испытания этого оборудования на производстве”.

“Мы сейчас строим технопарк, закупили стенды с российскими ПЛК. Тестируем их, щупаем их руками и готовим персонал, который занимается эксплуатацией”.

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

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

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

“Мы рассчитываем на то, что они (российские вендоры) будут быстро перестраивать архитектуру своих решений, чтобы менять компонентную базу”. 

“Необходима унификация и минимизация типов процессорного оборудования”.

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

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

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

Главное, что должна помочь сделать открытая платформа АСУ ТП, — “отвязать” софтовые решения от хардварной части, помочь избежать зависимости от вендоров как иностранных, так и отечественных.

“Сделать софтверную часть вендоронезависимой от железа. Это позволит создать потенциал для универсализации типов железа”.

“Типизация железа, унификация технических требований как к софтверной. так и к хардварной части”.

Независимость от решений одного вендора тем более важна, учитывая, что отечественные вендоры имеют ограниченные ресурсные и производственные возможности. Для решения задач замещения комплексных решений западных вендоров “большой тройки” необходимо объединять отечественные (и не только) решения в комплексные системы.  

“(Необходимо) сделать экосистему,  которая позволит из решений различных вендоров сделать эффективную систему”.

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

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

“Именно таким решением мы видим набор стандартов OPAS и решения на открытой платформе промышленной автоматизации”.

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

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

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

“В долгосрочной перспективе мы получим комплексные решения с хорошей конкурентной ценой”.

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

“Для заказчиков мы получаем митигацию рисков инноваций”.

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

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

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

“Главная польза в том, что мы обратили внимание на российских производителей. И своими действиями мы побудим их делать более правильный продукт, который мы будем больше покупать и таким образом развивать отрасль”.

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

“Есть риск, что наши производители останутся на том же технологическом уровне, что и сейчас. На рынке мало конкуренции, их ничего не заставляет двигаться вперед. Двигаться вперед их могут заставить некие согласованные решения, принятые потребителями — промышленными предприятиями”.

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

“Результат деятельности РГ — форматы взаимодействия: кто и каким образом это будет делать”.

“Не только стандарты, эти бумаги можно по-разному называть. Это и спецификации, и регламенты, правильные слова мы найдем позже”. 

“Глобально, РГ должна заниматься разработкой и формализаций требований к виртуальной кроссплатформенной софтверной среде исполнения, разработкой и формализацией требований к системам инжиниринга и проектирования систем управления, разработкой и формализацией требований к архитектурным и дизайнерским решениям систем управления”.

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

“Нужны конечные технические решения с фактом применения их в отрасли”

“Разработка openPLC, SCADA”.

“Данная платформа может стать хорошей основой для создания комплекса LIMS и интеграции его в АСУ ТП”.

Задачей видится не только выработка единых стандартов и требований, но и создание системы сертификации решений по этим требованиям. 

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

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

Как и в стандартах OPAS, в эту область часть респондентов включают ряд функций, которые ранее выносились за пределы АСУ ТП. По их мнению, область охвата включает не только 0, 1 и 2 уровни по классификации ANSI. Но и стык 2 и 3 уровня. С уровнем MES необходимо интегрироваться на уровне единых информационных моделей. 

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

“Часть классических MES-овских функций затаскивается вниз. Это революция. Лет 30 кластеры ИТ и ОТ развивались независимо друг от друга. Сейчас происходит диффузия ИТ и ОТ кластеров. Нас теперь интересуют не только ОТ, но и ИТ”.  

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

“Мы говорим об АСУ ТП, потому что область MES достаточно гибкая, там больше решений, есть собственные системы MES. Там доступны все современные технологии программирования, баз данных и др. Это открытая история”.

“В предметную область ОАСУ ТП входят только:

• КИП, различные исполнительные механизмы; 
• ПЛК;
• SCADA”.

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

“Главное — сделать унифицированные интерфейсы с MES. Нет смысла рассматривать еще и MES-системы, иначе мы можем погрязнуть”.

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

“Между заказчиками существует более-менее одинаковое видение АСУ ТП. Но нет ни одного стандарта, который бы его описывал. За исключением ГОСТа МЭК 161031, который написан довольно спорно”.

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

Одним из участников было высказано мнений, что АСУ ТП в целом на предприятиях находится в “серой” правовой зоне. Чтобы это исправить, необходимо разработать и принять федеральный закон по АСУ ТП.  

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

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

“Первый приоритет — это софтверный драйвер, который имел бы модульную структуру и мог быть быть имплементирован в системы разработки от российских производителей… Драйвер ProfiNET нужен уже сейчас, чтобы дать его нашим производителям, и они бы смогли делать поставку систем”.

“(Не хватает) стандартов по протоколам — по совместимости оборудования. Главный стандарт — стандарт протоколов  связи”.

“(Не хватает) промышленных протоколов передачи данных”.

“(Необходимо) разработать единый протокол для связи контроллера и верхнего уровня, который бы, в том числе, удовлетворял требованиям информационной безопасности.  Сейчас есть стандарт OPC UA, но немногие производители реализуют его в своих контроллерах, и реализации не всегда удачные”.

Не хватает и более высокоуровневых стандартов  по архитектуре.

“В России отсутствуют стандарты на архитектуру, такие как TOGAF. Мне кажется, есть смысл создавать такой же консорциум по стандартам архитектуры”.

“Архитектуры систем и решений промышленной автоматизации”.

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

“(Необходим) стандарт по платформе — среде разработке”.

“Нет никаких решений ни по аппаратной, ни по программной части для реального времени, для работы в детерминированных сетях”.

“В первую очередь, не хватает механизмов — стандарт плюс оценка соответствия — в области безопасности”.

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

Мнения по поводу перспектив виртуализации в АСУ ТП и виртуального ПЛК, в частности, разделились.

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

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

“Такой формат реализации АСУ ТП в перспективе более дешев, чем построение традиционной инфраструктуры. Не нужно будет иметь десять аппаратных. Нужен будет один ЦОД с универсальными серверами. И  вопросы резервирования, обслуживания и поддержки такой инфраструктуры становятся в разы проще”.

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

В настоящий момент все ПЛК — программные, софтверные, есть ОС, есть рантайм-система, которая выполняется”.

“(Виртуальный ПЛК) заменит хардварный, есть уже публикации, где классический подход к контроллерам заменяется на виртуализированный. Сейчас технология обмена данными настолько быстрая — есть действующие промышленные протоколы, которые позволяют реализовывать требования, в том числе по прокату”.

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

“Вопрос техногенных рисков технически решается. Пусть первоначально мы будем перезакладываться на построение надежных каналов связи, многократное дублирование серверов. По мере отработки технологии объем резервов будет сокращаться”. 

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

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

“Это позволит создавать проект для цифрового моделирования, отладки алгоритмов, тренажерной подготовки”.

“Программный ПЛК в виде виртуальной машины, которую можно разместить в ЦОДах, — это голубая мечта. За этим будущее. Будет класс задач, который можно сделать с виртуальным ПЛК, будет — который с хардварным ПЛК”.

“Что касается ПЛК, то в ближайшей и среднесрочной перспективе мы его сможем виртуализировать, но далеко не для всех объектов. Сначала это может быть решено для менее значимых объектов, но опыт показывает, что таких объектов — 80%. Поле для экспериментов, тестирования широкое”.

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

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

“У нас есть ряд опасений. Во-первых, в концепции есть ряд моментов, которые друг другу противоречат. Не нравится идея применения пула софтверных ПЛК  в виде виртуальных машин. Это не снизит импортозависимость. поскольку Россия сама не выпускает технику требуемой производительности”.

“Мы все заводим на единую централизованную систему. Если она падает, то мы теряем все производство”.

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

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

И сторонники и противники виртуализации сходятся в том, что актуальной задачей является отделение железа от софта, создание общего стандарта софтверного ПЛК.

“Если речь идет о единых стандартах, то это применимо”.

“Разделение аппаратной среды контроллера и программной среды контроллера — это то, что нам нужно”.

“Реализация некоего софтверного ПЛК, как сейчас стандарт Codesys, только российского — за это мы двумя руками”.

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

“Проприетарность решений, “вендор лок” отечественных решений — у них проприетарные системы, закрытые, элементы не взаимозаменяемые”.

“Проприетарные интерфейсы для своих эксклюзивных компонентов. Привязка к конкретному производителю оборудования и ПО”.

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

“Низкая гибкость. И раньше тоже нельзя было поставить на один агрегат Emerson и Honeywell”.

Ситуация, когда промышленные пользователи “привязаны” к комплексным вендорским решениям, привела к консерватизму в отрасли. 

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

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

“Сложность обучения персонала разным  системам”.

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

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

“Доступность документации и технической поддержки”.

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

“Высокая стоимость оборудования”.

“Длительная поставка ЗИП, сложности с поставкой оборудования в целом”.

“Сроки поставки”.

Что касается отечественного рынка решений АСУ ТП, то его состояние респонденты описали как “сырое”. 

“Сырой рынок”. 

“Сырые решения”.

“Неуверенность в отечественных производителях, в их ресурсах и возможностях, их стабильности”.

“Отсутствие отечественной элементной базы. Низкая надежность. Малые производственные мощности”.

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

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

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

“Отсутствие работающих инструментов стандартизации и поддержки соответствия”. 

“На уровне государственного регулирования отрасли промышленности не сбалансированы по требованиям к одной и той же области”. 

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

“Дефицит квалифицированного персонала — это проблема”.

“Есть проблема с разработчиками, их на рынке мало”.

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

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

Участниками был отмечен высокий потенциал российских ИТ-разработчиков. 

“Степень готовности очень высокая. У нас есть яркие примеры хороших продуктов — компьютерные игры, есть Яндекс”.

При этом респонденты указали и на ограничения, которые есть у отечественных вендоров: отсутствие собственной компонентной базы, недостаточные вложения в R&D, высокие цены и длинные сроки поставки. 

“Вендоры находятся в нашем менталитете. Большая часть вендоров не готова вкладываться в R&D, несмотря на профицит запроса сейчас”.

“Проблема — высокие цены и сроки поставки. Шесть месяцев — это только для своих”.

Закрытость, проприетарность отечественных решений также является существенным ограничением.

“Прософт, Инкомсистем, T-Soft, ИнСАТ, AdAstrA, НПФ «КРУГ», Атомик Софт, AdAstrA движутся в этом направлении, но процесс затруднен закрытостью спецификаций и нежеланием производителей ПТК открывать свои продукты”.

Одной из главных проблем является недостаточная зрелость и апробированность отечественных решений. Единственный способ решения этой проблемы — создание консолидированного заказа и реальный переход промышленных предприятий на отечественные решения.    

“Готовность есть, нельзя сказать, что рынок пустой. Решения есть, а степень их сырости зависит только от желания заказчиков их покупать”.

“С исполнительной, разработческой частью проблем нет. Самое важное — подготовить правильное ТЗ”.

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

“Мы не увидели полной замены всего нашего ряда автоматизации. Отечественные производители не предлагают полную альтернативу; производители, которые предлагают контроллеры, столкнулись с той же самой санкционной политикой, с трудностями поставок чипов, корпусов”.

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