На 13-й конференции OS Day 2026, прошедшей 4–5 июня, одной из ключевых тем стали встраиваемые системы. В этой области особенно остро стоит вопрос импортозамещения, поскольку значительная часть таких решений используется в сфере критической информационной инфраструктуры (КИИ).
- 1. Введение
- 2. Специфика сегмента
- 3. Состояние импортозамещения
- 4. Вызовы, проблемы и пути их решения
- 5. Выводы
Введение
Впервые за всю историю форума OS Day организаторы сделали акцент на встраиваемых системах.
Согласно определению, встраиваемая система — это микропроцессорный модуль, предназначенный для мониторинга и управления объектами без прямого участия человека. Такие системы могут иметь неограниченное число пользователей, но с ограниченным набором функций, без доступа к данным и с серьёзными ограничениями по взаимодействию с людьми.
Этот сегмент является значимой частью рынка и охватывает широкий спектр отраслей, включая бортовые системы автомобилей и другой самоходной техники на автомобильных или тракторных шасси, морские и речные суда, пилотируемые и беспилотные летательные аппараты, космическую технику, устройства самообслуживания (банкоматы, терминалы, постаматы, вендинговые автоматы), а также сложное медицинское оборудование. Всё больше моделей бытовой техники также включает интеллектуальные модули. Сюда же относится широкий спектр систем интеллектуальных зданий разного назначения, включая «умный дом», а также производственные, общественные и офисные пространства.
При этом крупнейшим сегментом остаются автоматизированные системы управления технологическими процессами (АСУ ТП). Участники панельной дискуссии «Технологический суверенитет промышленного производства: встраиваемые устройства» на OS Day 2026 (рис. 1), в которой приняли участие представители вендоров, интеграторов и заказчиков, пришли к выводу, что наиболее близкая к реальности оценка объёма российского рынка АСУ ТП за 2025 год составляет около 600 млрд рублей.
Речь идёт только о стоимости оборудования и программного обеспечения, без учёта сопутствующих услуг и сервисов. Для сравнения: это почти вдвое больше, чем весь российский рынок информационной безопасности за тот же период по оценке Центра стратегических разработок.
Рисунок 1. Участники дискуссии
Развитие отечественной индустрии встраиваемых систем стало в России, без преувеличения, вопросом национальной безопасности. Нельзя сказать, что разработчики таких систем полностью отсутствовали, однако многие из них работали в узких нишах. Например, разработчики бортовых систем для авиации и космоса часто действовали в рамках отдельных конструкторских бюро и обслуживали исключительно продукцию своих организаций. Значительную долю рынка занимали и продолжают занимать кэптивные структуры крупных холдингов, таких как «Росатом» и РЖД, которые являются крупнейшими вендорами АСУ ТП в России.
Однако, как отмечали участники дискуссии, многим компаниям пришлось выходить на рынок встраиваемых систем, не имея достаточного опыта. В результате им пришлось осваивать те сегменты, в которых они ранее не работали.
Специфика сегмента
Встраиваемые системы разрабатываются под конкретные задачи, часто в составе более крупных комплексов. При их создании приоритетны надёжность, эффективность и предсказуемость поведения, а не универсальность и широкий набор функций.
Аппаратная часть таких систем нередко имеет ограниченную вычислительную мощность и ресурсы. Например, при их разработке долгое время использовались процессоры V20 и V30 компании NEC, созданные ещё в 1980-е годы. Несмотря на то что они были сняты с производства в 2022 году, оборудование на их базе до сих пор находится в эксплуатации.
В этом нет ничего удивительного: оборудование, в котором применяются встраиваемые системы, рассчитано на длительный срок службы. Промышленные установки, суда, самолёты, вертолёты и железнодорожная техника эксплуатируются десятилетиями. Хрестоматийные примеры — самолёты DC-3 и Ан-2, которые используются десятки лет (более 90 и почти 80 лет соответственно) и до сих пор не имеют полноценной замены. Всё это время соответствующие системы должны поддерживаться.
К таким решениям предъявляются жёсткие требования по отказоустойчивости и непрерывности работы. Любой простой означает прямые убытки, поэтому остановки допускаются только в строго определённые технологические окна для обслуживания и регламентных работ.
Во многих случаях требуется гарантированное время реакции системы. Такие решения востребованы в энергетике, химической и нефтехимической промышленности, а также в системах управления беспилотными аппаратами и роботами. Системы реального времени делятся на два класса: жёсткого реального времени, где нарушение временных ограничений недопустимо, и мягкого, где возможны небольшие отклонения. Они применяются и в ИТ- и сетевом оборудовании, что позволило решить ряд давних технических проблем. При этом соблюдение требований реального времени зависит как от программной, так и от аппаратной части.
С другой стороны, во встраиваемых системах широко используются нестандартные и проприетарные решения, прежде всего протоколы обмена данными. В современных системах их постепенно заменяют стандартными, однако этот процесс замедляется ростом числа кибератак. Кроме того, специалистов, хорошо разбирающихся в специфике таких протоколов, немного, что также создаёт риски.
Многие математические модели также не стандартизированы и часто являются собственностью разработчиков. Это создаёт сложности для заказчиков, которым приходится использовать решения разных вендоров. При этом сочетания специализаций могут быть весьма необычными.
Например, решения Siemens стали стандартом одновременно для промышленности стройматериалов, металлургии, разделения изотопов, а также производства пива и безалкогольных напитков. Не случайно в рамках атаки Stuxnet, нацеленной на ядерную программу Ирана, пострадали предприятия по производству пива, стекла и цемента в разных странах, а не только в Иране.
Как отмечал ведущий научный сотрудник ИСП РАН, заведующий лабораторией обратной инженерии бинарного кода Вартан Падарян, после ухода зарубежных вендоров в 2022 году при эксплуатации встраиваемых систем часто приходилось прибегать к сложным методам реверс-инжиниринга.
По словам руководителя направления «Разработка перспективных систем управления» «Северстали» Евгения Ионенко, в компании используются решения восьми производителей, и это типичная ситуация для отрасли. Руководитель проекта Инженерного производственного центра компании «Нефтегазавтоматика» Анатолий Чернов привёл примеры, когда в одной организации используется продукция 12 вендоров, и это не предел.
С другой стороны, требования к вычислительной мощности для встраиваемых систем, как правило, невысоки. С пропускной способностью сетей ситуация сложнее, однако для большинства задач достаточно возможностей стандартного GSM, который до сих пор используется в большом количестве устройств.
Поэтому планы операторов в ряде стран по отключению поддержки этого устаревшего стандарта вызвали серьёзную обеспокоенность у эксплуатантов такого оборудования, поскольку ставят перед ними сложную и затратную задачу модернизации.
Состояние импортозамещения
Ещё до 2022 года, как отметил Вартан Падарян, на российском рынке существовали отечественные решения, хотя число разработчиков было ограниченным.
Значительную их часть составляли и продолжают составлять кэптивные компании. Задолго до 2022 года и даже до первой волны санкций 2014 года сильные внутренние разработчики АСУ ТП работали внутри РЖД и «Росатома», которые были и остаются крупнейшими поставщиками на российском рынке. Их решения используются не только внутри холдингов, но и в других отраслях. Практически все разработчики российских операционных систем с первых версий выпускали адаптированные для промышленности редакции с поддержкой реального времени.
Существуют и профильные подразделения внутри крупнейших конструкторских бюро, занимающихся авиационной, бронетанковой, ракетной и космической техникой. Они разрабатывают бортовые системы, однако из-за специфики этих сегментов такие структуры остаются закрытыми, а их решения не предназначены для использования вне продукции соответствующих компаний.
При этом есть примеры независимых разработок. В частности, операционная система реального времени JetOS, созданная совместно ИСП РАН, ГосНИИАС и ИПМ им. М. В. Келдыша, применяется в новых моделях отечественных гражданских самолётов. Также была представлена версия ОС «Аврора» для бортовых систем автомобилей.
После 2022 года на фоне ухода зарубежных поставщиков на рынок начали выходить новые игроки из смежных сегментов. Например, компания «ОВЕН Цифровые решения» ранее работала в области систем интеллектуальных зданий и «умного дома». Такие решения во многом схожи с промышленными, но изначально рассчитаны на менее жёсткие условия эксплуатации. Кроме того, их разработчики часто не были готовы к соблюдению отраслевых и регуляторных требований, которые к тому же продолжали ужесточаться, включая требования к локализации аппаратных и программных компонентов.
Одновременно активизировалась внутренняя разработка у компаний — потенциальных эксплуатантов АСУ ТП. По данным Центра компетенций по импортозамещению, озвученным на конференции ЦИПР-2026, АСУ ТП наряду с ERP-системами стали одним из самых востребованных направлений разработки в индустриальных центрах компетенций (ИЦК), созданных в 2022 году. Уже появились практические результаты, адаптированные под конкретные отрасли.
Инициатива по созданию рабочей группы ОАСУ ТП появилась в 2024 году в рамках ИЦК «Металлургия» и была поддержана Минпромторгом. В дальнейшем к ней присоединились предприятия других отраслей, включая горнодобывающую (АЛРОСА), химическую («Уралхим», «Башкирская содовая компания», «ФосАгро», «КуйбышевАзот»), нефтегазовую (ЛУКОЙЛ), нефтехимическую (СИБУР) и телекоммуникации («Ростелеком»).
В рамках группы ОАСУ ТП были разработаны несколько моделей промышленных контроллеров на российской элементной базе. Они пока не закрывают все сценарии, но уже позволяют частично заменить решения Siemens, Schneider Electric и Rockwell Automation. В частности, на Череповецком металлургическом комбинате «Северстали» в феврале успешно прошло пилотное внедрение комплексного решения на базе архитектуры OpenPLC (рис. 2).
Рисунок 2. Архитектура комплексного решения, внедренного на Череповецком металлургическом комбинате
Вызовы, проблемы и пути их решения
Как отметили участники дискуссии, в 2022 году, после ухода зарубежных вендоров, контролировавших значительную часть рынка, перед отечественными разработчиками встраиваемых систем встал комплекс задач, которые пришлось решать в сжатые сроки. При этом многие из этих проблем остаются актуальными до сих пор.
Среди ключевых были выделены:
- разнородные требования заказчиков;
- вопросы доверия и безопасности;
- постоянный рост требований регуляторов;
- нехватка кадров;
- необходимость ускоренного развития, на которое у зарубежных компаний ушли десятки лет.
Ситуацию осложняло то, что разработку встраиваемых систем во многих случаях осваивали команды без профильного опыта. Кроме того, компаниям приходилось выходить в новые для себя сегменты рынка.
В схожем положении в 2022 году оказались и российские разработчики средств сетевой безопасности: им пришлось в сжатые сроки выводить на рынок решения для крупных заказчиков, тогда как ранее они в основном работали с малым и средним бизнесом.
Разнородность требований заказчиков
Потребности разных заказчиков существенно различаются, нередко — кардинально. Для одних работа в режиме реального времени не критична, для других это ключевой параметр. Причём требования к скорости реакции даже в рамках одной отрасли могут отличаться на несколько порядков. Например, для обычных транспортных средств жёсткие требования реального времени не обязательны, тогда как для беспилотных систем они критичны.
Общим для всех применений остаются крайне жёсткие требования к непрерывности работы. Обслуживание возможно только в рамках технологических окон, которых может быть всего несколько в год.
Как отмечал в блоге на Habr технический директор компании «КЕДР Solutions» Андрей Соловьёв, ситуацию часто осложняет то, что заказчики испытывают трудности с формированием технических заданий. Разработчикам приходится активно участвовать в этом процессе. При этом важно учитывать, что ряд аспектов для заказчика очевиден, а для разработчика — нет.
Таких примеров немало. Например, ряд пищевых производств, где используются высококонцентрированные спиртовые растворы, относятся к пожароопасным. В их числе могут быть предприятия, которые на первый взгляд не ассоциируются с повышенным риском, — кондитерские или мясоперерабатывающие. При этом сертификация по пожаро- и взрывозащищённости — длительный и сложный процесс.
Шире, чем принято считать, востребована защита от ионизирующего излучения. Его источники используются, например, в дефектоскопах, которые широко применяются при контроле качества металлических изделий — арматуры, рельсов, элементов корпусов самолётов и вертолётов.
Как отметил Евгений Ионенко, нарушение требований реального времени может привести к выпуску брака, простоям и значительным убыткам. В ряде случаев последствия могут быть более серьёзными — вплоть до техногенных катастроф. Например, по одной из версий, утечка опасного химиката на предприятии Union Carbide в индийском Бхопале произошла из-за отказа противоаварийной автоматики. В результате бхопальской катастрофы, по минимальным оценкам, погибли около 5 тыс. человек, пострадали около 50 тыс.
Особо жёсткие требования установлены для медицинского оборудования, поскольку оно напрямую связано с жизнью и здоровьем людей. Кроме того, такие системы часто работают в специфических условиях, например при высоком уровне магнитных полей или ионизирующего излучения.
Существенно различаются и объёмы передаваемых данных. В одних случаях это могут быть единицы байт — например, при мониторинге транспорта или сельхозтехники, где допустима доставка данных с задержкой в часы. В других — сотни килобайт при управлении сложными технологическими установками, где требуется реакция в строго заданное время. Это особенно критично для опасных производств или систем, где авария может привести к значительному ущербу. Соответственно, в одних сценариях достаточно устойчивой сотовой или спутниковой связи, в других требуется оптоволоконная инфраструктура.
В итоге, как подчеркнули участники дискуссии, универсального решения, подходящего для всех сценариев, не существует. Поэтому существующее отечественное оборудование применимо не на всех объектах — в ряде случаев оно просто не соответствует предъявляемым требованиям.
Безопасность, доверие и регуляторные требования
Рост количества инцидентов, связанных с атаками на системы АСУ ТП, является глобальной проблемой. За последние восемь лет их число, по данным мониторинга InfoWatch, увеличилось в 25 раз (рис. 3).
При этом в России с 2022 года рост числа атак существенно опережает среднемировые показатели. По данным InfoWatch, за два года в мире он составил 17 %, тогда как в России — более чем в 2,5 раза.
Рисунок 3. Количество инцидентов, связанных с атаками на системы АСУ ТП
В ответ на рост числа атак регуляторы в разных странах усиливают требования к безопасности промышленных систем. В России этим занимается ФСТЭК в рамках регулирования защиты критической информационной инфраструктуры (КИИ). Отдельно выделяются значимые объекты КИИ (ЗОКИИ).
Установлены сроки перехода на отечественное оборудование и программное обеспечение, причём для многих компаний они достаточно жёсткие. При этом регулятор предусмотрел возможность их переноса: с базовой даты 1 января 2028 года — на три или даже восемь лет. Однако для этого необходимо выполнение ряда условий, что доступно не всем организациям.
Программное обеспечение, используемое на таких объектах, подлежит сертификации. В последнее время допускается сертификация процессов безопасной разработки (РБПО), однако это сложная задача. По практическому опыту, выстраивание таких процессов занимает не менее года. При этом данный подход позволяет снизить риски, связанные с безопасностью цепочек поставок, в том числе при использовании ПО с открытым кодом. Однако и с проприетарным кодом, включая разработанный внутри компании, ситуация часто оказывается сложнее, чем предполагается.
Как отмечали участники дискуссии, на рынке фактически отсутствуют доверенные инструменты для анализа кода встраиваемых систем. Применение стандартных сканеров, используемых для тиражного ПО, зачастую оказывается неэффективным, особенно для систем реального времени.
В результате, как отметил Евгений Ионенко, кибербезопасность в этой области остаётся «чёрной дырой». Это относится как к зарубежным решениям, внутренняя архитектура которых закрыта, так и ко многим отечественным. При этом значительная часть российских продуктов создаётся на базе зарубежных чипов, чаще всего китайских, например Rockchip.
Что касается программного обеспечения, по данным, приведённым руководителем отдела адаптивных промышленных технологий «Лаборатории Касперского» Денисом Бахаевым, в двух третях российских программно-аппаратных комплексов используются компоненты с открытым исходным кодом — как на уровне системного, так и прикладного ПО. При этом этот показатель всё же ниже среднерыночного.
Ситуацию с защитой цепочек поставок осложняет то, что многие разработчики, в том числе кэптивные, используют ванильные версии ОС на базе Linux с открытым кодом, чаще всего Debian. Однако, как отметил Вартан Падарян, российские разработчики операционных систем используют компоненты, прошедшие аудит в Консорциуме безопасности Linux, тогда как за безопасность кода в ванильных версиях Linux, по большому счёту, никто не отвечает. Это создаёт риски атак на цепочки поставок и эксплуатации уязвимостей, которых в Linux выявляется немало, при этом их устранение не всегда происходит оперативно.
При этом, как подчеркнул Евгений Ионенко, дальновидные разработчики — как кэптивные, так и работающие на открытом рынке — всё чаще выбирают российские решения. Это связано с требованиями регуляторов и перспективой перехода к доверенным программно-аппаратным комплексам (ПАК), в которых все компоненты, как программные, так и аппаратные, должны быть произведены в странах ЕАЭС.
Однако, по его словам, серьёзной проблемой остаётся недостаток доверия со стороны заказчиков к российским разработчикам. Поэтому многие промышленные компании не спешат отказываться от зарубежных решений.
В то же время существуют и объективные причины. Как уже отмечалось, многие математические модели, используемые в зарубежных системах, являются ноу-хау вендоров. Их реверс-инжиниринг — сложный и длительный процесс. По словам Евгения Ионенко, на воспроизведение одной из таких моделей в модуле управления прокатным станом Siemens ушло более четырёх лет, и это не единичный случай. В ряде случаев решить аналогичную задачу не удаётся вовсе.
С другой стороны, как отметил директор компании «ОВЕН.Цифровые решения» Андрей Горский, рынок требует недорогих решений. Поэтому продукты на массовых чипах и ванильных версиях ОС от сообщества продолжают пользоваться спросом. При этом доверенные и сертифицированные решения неизбежно оказываются значительно дороже.
По его словам, регуляторные требования в этой сфере усиливаются, и не все разработчики успевают к ним адаптироваться. Особенно это касается компаний, которые после 2022 года вышли в новые для себя сегменты встраиваемых и промышленных систем. В таких случаях часто используются наложенные средства защиты от ИБ-вендоров, что, по словам Горского, поддерживается ФСТЭК России и, как минимум, не вызывает возражений у заказчиков.
Вместе с тем, как отметил Анатолий Чернов, сфера АСУ ТП всегда была зарегулирована, хотя ранее значительная часть требований формировалась самими компаниями и не всегда была согласована между собой. В этом контексте появление государственного регулирования можно рассматривать как позитивный фактор, поскольку оно задаёт единые ориентиры. По его словам, его компания всегда использовала российскую элементную базу и не применяла ванильные системы с открытым кодом.
Что касается сертификации, то, по оценке представителя «Лаборатории Касперского», наибольшие сложности обычно связаны с аппаратной частью ПАК. В целом процедуры сертификации остаются наиболее сложной и дорогостоящей частью разработки. При этом с программным обеспечением ситуация упростилась после появления стандарта РБПО в 2024 году, который аккумулировал значительную часть лучших практик.
Как добавил директор по продуктам (ПАК) компании «Открытая мобильная платформа» Кирилл Валюнин, ему не известны случаи использования ванильных систем с открытым кодом в реальных ПАК. Такое ПО плохо совместимо с требованиями к надёжности и гарантийным обязательствам. При этом он отметил, что «Открытая мобильная платформа» не работает в сегменте АСУ ТП, а сосредоточена на бортовых системах для автомобилей (рис. 4), где регуляторные требования менее жёсткие.
Рисунок 4. Бортовая система с ОС «Аврора Авто»
Кадровый дефицит
Как отметили участники дискуссии, кадровый дефицит в сегменте разработки встраиваемых систем ощущается особенно остро. Помимо компетенций разработчика, требуются знания технологических процессов с учётом отраслевой и производственной специфики, которая может существенно различаться даже в пределах одной индустрии.
Анатолий Чернов указал, что наиболее остро не хватает специалистов по сертификации. Ситуацию осложняет то, что таких специалистов не готовят в вузах, и компаниям приходится развивать их внутри. При этом работа требует сочетания технических и юридических знаний. Дополнительную сложность создаёт постоянное изменение регуляторных требований, которые необходимо не только отслеживать, но и глубоко понимать.
В целом требования к техническим специалистам в этой области высоки: необходимо сочетание компетенций в ИТ и в конкретных отраслях, для которых разрабатываются решения. Сказывается и специфика сегмента, где используются не самые современные системы, часто воспринимаемые как устаревшие. При этом навыки оптимизации ПО под ограниченные ресурсы во многом утрачены.
Кирилл Валюнин отметил, что привлекать выпускников становится сложнее из-за низкого уровня стартовых зарплат. В результате компании вынуждены конкурировать с курьерскими службами и сектором общественного питания, где доходы на старте выше, несмотря на то что в самой индустрии ресурсы есть.
При этом использование искусственного интеллекта (ИИ) в данной сфере вызывает серьёзные вопросы. Многие известные представители ИТ-индустрии, включая создателя Linux Линуса Торвальдса, указывают на недостаточное качество кода, генерируемого ИИ. Как подчеркнул директор департамента сопровождения продаж и консалтинга «Ред Софт» Сергей Пашала, применительно к ПО для встраиваемых систем генеративный ИИ чаще создаёт дополнительные риски, связанные с ошибками и уязвимостями, чем решает задачи.
Что касается производственных специалистов, требования к ним также остаются высокими. Такие кадры зачастую уникальны. По оценкам, число специалистов с глубокими знаниями отдельных проприетарных протоколов, используемых, например, в энергетике, может исчисляться единицами на всю страну. При этом значительная часть таких экспертов — специалисты старшего возраста, постепенно покидающие профессию.
Как отметил ведущий программист, руководитель проекта «Базальт СПО» Андрей Савченко, одним из возможных решений является объединение усилий разработчиков на принципах открытой разработки. Частично эту задачу решает межотраслевая рабочая группа «Открытая АСУ ТП» (ОАСУ ТП), в которую уже входит около шести десятков компаний, и число участников продолжает расти. На конференции о присоединении к группе сообщил директор по развитию НТЦ ИТ РОСА Вячеслав Кадомский.
Участники дискуссии также сошлись во мнении, что именно открытая модель разработки может помочь в решении ключевых задач, стоящих перед разработчиками и эксплуатантами встраиваемых систем.
Необходимость быстрой эволюции для участников рынка
Как подчеркнул Вартан Падарян, основной вызов для российских разработчиков заключается в необходимости в сжатые сроки пройти путь, на который у зарубежных вендоров, многие из которых существуют более 100 лет, ушли десятилетия. По его оценке, ситуацию осложняет то, что отдельные этапы этой эволюции невозможно пропустить.
Ещё одним вызовом он назвал ограниченность российского рынка. Та же проблема характерна и для других сегментов, включая NGFW, почтовые серверы и ряд других решений. Количество потенциальных заказчиков невелико, при этом разработка АСУ ТП, как и NGFW, требует значительных времени и ресурсов.
По мнению участников дискуссии, одним из способов преодоления этих ограничений может стать развитие открытой модели разработки, в частности в рамках рабочей группы «Открытая АСУ ТП» (ОАСУ ТП). Как отметил Вячеслав Кадомский, такой подход позволяет переиспользовать уже созданные компоненты вместо их повторной разработки.
Как подчеркнул Андрей Савченко, ключевым условием является достижение высокого уровня модульности и взаимозаменяемости. В идеале необходим единый репозиторий пакетов, что упростит работу разработчиков. При этом такие пакеты должны проходить строгий аудит на наличие ошибок и уязвимостей, чтобы снизить риски атак, связанных с цепочками поставок и эксплуатацией известных уязвимостей.
В то же время, по словам Анатолия Чернова, наличие такого репозитория само по себе не решает задачу обеспечения безопасности кода, особенно с учётом различий аппаратных архитектур. Однако он согласился, что подобный подход помогает снизить зависимость от конкретных поставщиков (vendor lock-in), чего стремятся избежать заказчики.
Денис Бахаев также указал на необходимость формирования полноценных экосистем, что требует кооперации производителей аппаратной базы, системного и прикладного ПО. Пока же эти группы в основном развиваются независимо друг от друга, и взаимодействие между ними остаётся ограниченным.
Отдельной проблемой остаётся накопление и передача отраслевой экспертизы. Её необходимо системно аккумулировать и распространять между участниками рынка и профильных объединений. Без решения этой задачи в разумные сроки обеспечить рынок отечественными промышленными решениями будет затруднительно.
Выводы
Разработчики встраиваемых систем в 2022 году столкнулись с необходимостью в сжатые сроки пройти путь, на который у ведущих международных производителей ушли десятилетия. При этом вендорам, пришедшим из других сегментов рынка, пришлось адаптировать свои продукты под специфику таких систем в процессе работы.
Несмотря на то что отдельные этапы этой эволюции невозможно пропустить, отечественные разработчики, по-видимому, нашли способы ускорить развитие. Они связаны с активным использованием открытой разработки и экосистемных подходов, что при этом не противоречит принципам безопасной разработки.
