Российское ПО обычно определяют по нескольким формальным признакам: отечественный разработчик, включение в реестр Российского ПО и поддержка российских операционных систем. Однако за интерфейсом SCADA находится целая цепочка технологий — среда исполнения, библиотеки, драйверы, СУБД, система отчётности и инструменты разработки. Часть этих компонентов может иметь иностранное происхождение и не контролироваться разработчиком самой системы.
Означает ли это, что такую SCADA нельзя считать российской? Не обязательно: полностью изолированных программных экосистем практически не существует. Поэтому важнее определить, сможет ли разработчик самостоятельно собирать, исправлять и развивать систему, если доступ к иностранным компонентам или поддержке их поставщиков будет ограничен.
Что находится внутри SCADA
SCADA редко является одним самодостаточным приложением. Даже если она поставляется в виде единого дистрибутива, внутри обычно работают сервер реального времени, архив, подсистема аварийной сигнализации, сервер связи с оборудованием, клиентские приложения, редактор проекта и система отчётности.
Упрощённо программную архитектуру SCADA можно представить следующим образом:
Операционная система (Windows, Linux или обе платформы. Поддержка Linux может быть нативной либо обеспечиваться через фреймворк совместимости)
Среда исполнения (например, .NET или Java, без которой приложения не запускаются)
Ядро SCADA (обработка тегов, логика, события, тревоги, архивирование и резервирование)
Коммуникационный уровень (собственные драйверы Modbus, MQTT и других протоколов, OPC DA, OPC UA)
Хранение данных (встроенный собственный архив либо внешняя СУБД, например PostgreSQL или Microsoft SQL Server)
Визуализация (десктопный клиент, веб интерфейс или оба варианта)
Сервер алармов (система генерирования сообщений о событиях, предупреждения и рассылка)
Отчётность (собственный генератор либо отдельный программный компонент)
Средства разработки (компилятор, SDK и библиотеки, необходимые для выпуска новых версий)
Иностранное происхождение одного из этих компонентов ещё не делает всю SCADA иностранной. Российский продукт может использовать PostgreSQL, Nginx или открытую реализацию.NET. Если компонент можно автономно устанавливать, обновлять и при необходимости заменять, такая зависимость остаётся контролируемой.
Проблема возникает, когда без внешнего компонента невозможно запустить систему, подключиться к оборудованию, сформировать отчёт или выпустить исправление. Например, работа Windows приложения в Linux через Wine означает не прямую поддержку Linux, а использование дополнительного слоя совместимости. Это может влиять на работу OPC компонентов, графики, печати и других функций.
Некоторые SCADA официально указывает работу в Linux через Wine и перечисляет связанные с этим ограничения. Другие используют .NET Runtime, а для веб приложения — IIS в Windows, Apache или Nginx в Linux. Но в обоих случаях важен не перечень технологий, а способность разработчика контролировать их применение.
Практически все зависимости можно разделить на три категории:
Некритические: компонент можно исключить без потери основных функций.
Заменяемые: компонент необходим, но существует проверенная альтернатива.
Критические: без компонента система не работает, а его замена требует изменения архитектуры или исходного кода.
Таким образом, оценивать следует роль иностранных компонентов. Если разработчик контролирует ядро, исходный код и сборку продукта, а внешние компоненты можно сопровождать или заменить, использование зарубежных технологий не лишает SCADA российского происхождения. Если же ключевые функции зависят от закрытой платформы, которую разработчик не может изменить, технологическую независимость такого продукта следует оценивать отдельно.
Иностранный компонент — ещё не иностранная SCADA
Наличие иностранных компонентов не делает всю SCADA иностранной. Современные продукты используют сторонние библиотеки, среды исполнения, веб серверы и СУБД. Разрабатывать каждый такой элемент самостоятельно обычно нецелесообразно. Важнее не происхождение компонента, а степень контроля над ним. Например, Nginx и PostgreSQL созданы за пределами России, но имеют открытый исходный код. Их можно автономно устанавливать, хранить в собственной инфраструктуре и при необходимости заменять.
Модели технологической зависимости
Использование .NET или Java требует отдельной оценки. Следует учитывать конкретную реализацию, условия распространения, возможность автономной установки и привязку SCADA к определённой версии среды. Само упоминание .NET в системных требованиях ещё не говорит о критической зависимости.
Серьёзный риск возникает, если закрытый иностранный компонент отвечает за основную функцию: связь с оборудованием, архивирование, отчётность, лицензирование или выпуск обновлений. Если разработчик не может исправить или заменить такой компонент, он контролирует не весь жизненный цикл продукта.
Таким образом, возможны три модели:
• российская SCADA с контролируемыми открытыми компонентами;
• российская SCADA, зависящая от внешней программной платформы;
• локализованный иностранный продукт, ядро которого контролирует другой разработчик.
Формально поставщиком во всех случаях может быть российская компания, однако степень технологической независимости этих решений будет различаться.
Как оценить технологическую зависимость SCADA
С поддержкой Linux есть важный нюанс. Одни SCADA имеют отдельную версию, собранную непосредственно для этой операционной системы. Другие остаются Windows приложениями и запускаются в Linux через Wine. Для пользователя результат может выглядеть одинаково, но устройство и набор зависимостей у этих решений различаются.
SCADA с поддержкой работы в Linux через Wine нередко заявляют о возможных ограничения при использовании OPC DA и печати отчётов. Это не ставит под сомнение происхождение самой SCADA, но означает, что её работа в Linux зависит от дополнительного слоя совместимости.
Так же следует рассматривать .NET, Java, внешние СУБД, OPC серверы и системы отчётности. Значение имеет не только происхождение компонента, но и возможность разработчика управлять им или заменить его.
По степени контроля, я разделил зависимости на четыре уровня:
Контролируемая — компонент доступен для автономной установки, имеет открытый код или может сопровождаться разработчиком.
Заменяемая — компонент необходим, но существует проверенная альтернатива, переход на которую не требует изменения всей системы.
Платформенная — работа SCADA связана с конкретной средой исполнения, операционной системой или слоем совместимости.
Критическая — без внешнего компонента невозможно запустить систему, подключиться к оборудованию или выпустить обновление, а самостоятельно заменить его разработчик не может.
Сравнение технологических зависимостей российских SCADA
Для оценки технологической независимости сравним несколько российских SCADA по открытым данным производителей. Сравнение основано исключительно на архитектурных особенностях, влияющих на независимость продукта: поддержке Linux, необходимости использования дополнительных компонентов, прозрачности технической документации и степени контроля разработчика над ключевыми технологиями.
Сравнение технологический зависимостей российских SCADA-систем (по открытым данным производителей):
SCADA | Нативная поддержкаLinux | Запуск приложений через фреймворки: Wine и .NET Framework | Основные технологические зависимости (по данным производителя) | Прозрачность архитектуры | Уровень технологической независимости |
SCADA 1 | Да | Автономная установка под каждую OC | Независимая | Средняя | Независимая |
SCADA 2 | Нет | .NET Framework | NET Runtime; Nginx (Linux), IIS (Windows); | Высокая (открытый исходный код) | Зависимая (запуск через .NET Framework) |
SCADA 3 | Нет | Wine | Wine | Высокая | Зависимая (запуск через Wine) |
SCADA 4 | Нет | .NET Framework | .NET Nginx | Средняя | Зависимая (запуск через .NET Framework) |
SCADA 5 | Частично | Wine/.Net для EventLogViewer | Apache, Wine/.Net | Средняя | Контролируемая (частичный запуск через Wine/.Net) |
SCADA 6 | Нет | Wine | Wine | Высокая | Зависимая (Wine Framework) |
Примечание. Информация получена из открытой технической документации производителей на дату подготовки таблицы. Оценка отражает характер технологической зависимости и степень прозрачности архитектуры, но не является оценкой функциональных возможностей, качества продукта или его соответствия требованиям конкретного проекта.
Сравнение показывает, что большинство современных российских SCADA пока еще не поддерживают нативную работу под российские Linux. Основные различия сегодня связаны не столько с происхождением отдельных компонентов, сколько с архитектурой продукта и количеством обязательных внешних зависимостей.
При выборе SCADA рекомендуется учитывать не только наличие продукта в Реестре российского ПО, но и то, насколько разработчик контролирует критически важные элементы собственной платформы и способен сопровождать их независимо от внешних поставщиков.
Итог
Технологически независимой можно считать SCADA, жизненный цикл которой полностью контролирует её разработчик. Он должен иметь возможность самостоятельно собирать и обновлять продукт, устранять уязвимости, сопровождать ключевые компоненты и при необходимости заменять их без полной переработки системы.
Иностранные библиотеки, среды исполнения или СУБД не исключают российское происхождение SCADA, если их использование остаётся управляемым, а запись в реестре подтверждает соответствие установленным требованиям. Однако реальную степень независимости показывает способность разработчика поддерживать и развивать систему без участия иностранных поставщиков.
