RISC-V в энергетике: каким системам можно доверять

RISC-V в энергетике: каким системам можно доверять

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

Меня зовут Латышов Кирилл, и я являюсь руководителем лаборатории РБПО в центре НТИ МЭИ. На данный момент центр НТИ МЭИ представляет собой подразделение Московского энергетического института, которое занимается непосредственно разработкой программно-аппаратных комплексов.

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


01:39
А каким образом сегодняшнее мероприятие относится к вашей работе?

В рамках нашей работы достаточно большое количество активностей связано с разработкой программно-аппаратных комплексов и достаточно большое внимание на сегодняшний день уделяется именно доверенным программным аппаратным комплексам. И в силу того, что ранее в электроэнергетике практически все было построено, ну и в целом не только в энергетике, наверное, возьму шире в промышленности, либо на x86-й архитектуре, либо на архитектурах ARM, зачастую, причем ARM v7, как показывает практика. Сейчас в силу достаточно большого количества внешних факторов необходим переход на новые аппаратные платформы.

В частности, некоторые производители выбирают ARM версии v8, а некоторые — RISC-V. В частности, вот мы пошли по пути на данный момент исследования применимости и той и той платформы для задач построения доверенных паков. И во многом из-за этого нам интересен RISC-V.


02:46
Тема доверенности сейчас и правда актуальна. Но хотелось бы понять на примерах, какими свойствами должны обладать доверенные системы. Можно ли существующий стек технологий сделать доверенным?

Ну, согласен, тема дискуссионная, такая достаточно горячая, я бы сказал. Если идти с формальной точки зрения, то это, если вот прям просто, то это программное обеспечение в реестре Минцифры железа, в реестре Минпромторга. И если у нас программный аппаратный комплекс выполняет функции безопасности те или иные, то необходимы эти функции сертифицировать в соответствующих органах. То есть это ФСТЭК России и ФСБ России. То есть как бы мы видим вот в этом векторе также.


03:34 
Я так понимаю, вы свою программную часть каким-то образом разрабатываете так, чтобы она стала доверенной. Что вы для этого делаете?

Отчасти именно с точки зрения программного обеспечения. Сейчас очень таким важным, скажем так, ядром вокруг которого формируется наша разработка как раз таки является и внедрение процессов безопасной разработки. То есть это как из запада было SSDLC, в России это вот РБПО.

В частности ориентируемся как раз таки на стандарты, которые выпускает ФСТЭК России, там 56, 939, который в прошлом году был обновлен. Ну и также у нас в отрасли появляются постепенно требования, как в электроэнергетике, так и в других отраслях. Мы все чаще можем видеть, что конечные заказчики ожидают от нас программного обеспечения, которое не имеет уязвимостей. И зачастую это проверки с точки зрения статического анализа, то есть проверка кода на отсутствие уязвимостей без его компиляции. Также это отсутствие известных уязвимостей в коде, то есть, например, использование композиционного анализа, контроль цепочки поставки, то есть всех зависимых компонентов, не только конкретного зависимого модуля какого-то, который мы используем, но и всех зависимых компонентов, которые этот модуль тянет за собой. Ну и, соответственно, динамические виды тестирования, такие как фазинг, например.

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


05:17
Это то, что касается программного обеспечения. А что с аппаратной частью? В вашем институте что-то делается в этом направлении?

С точки зрения аппаратного обеспечения, по крайней мере, именно в нашем центре работ, к сожалению, не ведется. Работы, насколько я знаю, в смежных институтах, в рамках ВУЗа ведутся какие-то, но, однако, на данный момент они пока не связаны с RISC-V. Там лишь зарождается эта работа, по моей информации.

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

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


06:53
Влияет ли на эту доверенность выбор именно архитектуры RISC-V? Или это просто расчет на полностью контролируемое развитие технологии на территории нашей страны?

Однозначно распространенность в стране не может обеспечить, скажем так, доверенность и безопасность. Это однозначно упростит данный процесс. Но и в целом, что позволяет RISC-V как архитектура?

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

Достаточно часто в нашей отрасли мы сталкиваемся с задачей, когда нам необходимо реализовать доверенную загрузку в виде Secure Boot, либо чуть реже Encrypted Boot. Но на сегодняшний день у нас попросту как для ARMa, так и для RISC-V отсутствует целостная выстроенная экосистема с точки зрения ПО именно для построения доверенной загрузки.


08:20 
Мы уже немного касались отраслевого применения. Можете Вы что-то рассказать о прикладном применении этих паков? Где это может использоваться?

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

Скажем так, можно провести параллель между цифровыми подстанциями и концепцией открытой АСУ ТП как раз таки с точки зрения стандартов в энергетике. Это началось чуть раньше с введением стандартов МЭК-61850 и сейчас достаточно активно набирает обороты. Как раз таки данные программно-аппаратные комплексы, которые мы исследуем, мы исследовали с точки зрения применимости для задач открытой АСУ ТП и вот для задач цифровой подстанции.

Именно с точки зрения цифровой подстанции, если рассматривать, то это в первую очередь терминалы релейной защиты автоматики.


09:59
Если брать, например, создание открытой АСУ ТП, то это будет связка программного и аппаратного обеспечения от независимых производителей. Как добиться их совместной корректной работы?

На мой взгляд, как раз таки RISC-V с этой точки зрения достаточно хорош во многом за счет профилей. То есть существование профилей на данный момент позволяет многим разработчикам осознавать примерный состав аппаратуры, который будет использоваться и, отталкиваясь от этого, подстраивать разрабатываемое программное обеспечение под конкретные задачи.


10:39
Хорошо. А что с точки зрения операционных систем? Что у нас сейчас есть из операционных систем, совместимых с RISC-V?

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

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

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

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


12:12 
Вы же тогда столкнетесь с проблемой сопровождения операционной системы на всем протяжении жизненного цикла. Ну и сертификация, конечно.

 На данный момент мы находимся на исследовательском пути. И вот для решения существующей задачи о применимости именно RISC-V для наших задач нас пока что это устраивает. Однако мы понимаем о существовании данной проблемы.

Мы понимаем о том, что далеко не каждый вендор РЗА или АСУ ТП будет готов собирать, во-первых, это все под задачи свои, даже для каких-то прототипов. С этой точки зрения есть концепция, похожая на Buildroot и на Yocto. Но, опять же, все рецепты, используемые для данных сборочных систем, они расположены где-то на западных, зачастую, серверах.

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

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

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

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


14:22
Говоря о производителе, вы имеете в виду вендоры-производители аппаратуры или всего комплекса?

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

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


15:07
Но тут, наверное, есть проблема с другой стороны. Все-таки 25 лет – это большой срок. Это же не значит, что в течение этого времени ваше изделие будет изменяться. Скорее всего, появятся новые поколения изделий, которые будут целиком, либо частично замещать предыдущие.

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

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

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


16:37 
Каким образом ваше учебное заведение, МЭИ, участвует в популяризации RISC-V?

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

Могу сказать, что на данный момент работы именно с аппаратурой, построенной на базе RISC-V, у нас на кафедре ведутся достаточно активно. У нас активно включаются ребята, начиная курса с третьего. И на данный момент у нас даже несколько магистров ведут свои магистрские работы по разработке того или иного программного обеспечения под одноплатные компьютеры на базе RISC-V.


17:46
Какие планы уже удалось воплотить, и что планируете сделать в краткосрочной перспективе?

На данный момент, как я и говорил, были проведены исследования с точки зрения операционных систем. Мы разрабатываем сборки под различные одноплатные компьютеры на базе RISC-V, портируем ряд программного обеспечения под нужды электроэнергетики. И в ближайшей перспективе планируем реализовать концепцию виртуальных ПЛК на базе RISC-V в рамках реализации концепции и архитектуры открытой СУТП.


18:27
Это будет уже законченное изделие или речь идет пока о демо-образце?
  
Скорее это будет прототип. Пока что мы находимся в исследовательской фазе определения того, возможно ли реализация данных подходов. Кроме того, прорабатываем на данный момент вопросы реализации криптографической защиты протоколов передачи данных в рамках цифровой подстанции.

На данный момент у нас в стране в целом это не особо распространено. Но сегодня на нашей кафедре и в нашем центре существуют прототипы как на базе x86 архитектуры для протоколов МЭК-61850 MMS и GUS прототипы, так и сейчас ведется работа на базе RISC-V, что по моему мнению является достаточно перспективным и вполне применимым в нашей отрасли.


© СТА-ПРЕСС, 2025