Багрос 4000 руководство программиста

БагрОС-4000
– современная операционная система
реального времени, разработанная ПАО
«Компания «Сухой».

БагрОС-4000
поддерживает процессорные архитектуры
Эльбрус, MIPS64 (в том числе
Мультикор), PowerPC, ARMv7,
Intel x86 и
обеспечивает функционирование
многомодульных вычислительных систем
[ CITATION ТЕХ20 l 1049 ].

В феврале
2019-го года данная операционная система
получила сертификат по требованиям
защиты информации, позволяющий
обрабатывать информацию, имеющую уровень
секретности «совершенно секретно»

На данный
момент система успешно применяется в
самолёте Су-57 и готова к применению в
разрабатываемых и модернизируемых
летательных аппаратах.

    1. БагрОс-4000 как операционная система реального времени

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

ОС может
относиться к классу ОС РВ, если её
эффективность зависит не только от
заложенных алгоритмов, корректности
вычислений и т.п., но и от того, успевают
ли все необходимые алгоритмы выполняться
в установленных интервалах времени.
Также её быстродействие должно быть
сопоставимо скорости течения процессов,
с которыми система работает, т.е. ОС не
только успевает за указанный интервал
времени подготовить корректный результат
расчётов, но и делает это «ритмично» [CITATION ДАБ19 l 1049 ].

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

Из
основных областей применения подобных
систем можно выделить военную и
космическую области (различные
встраиваемые системы и носимые
устройства), промышленность
(автоматизированные системы контроля
и управления) и различные товары широкого
потребления (различные «умные»
устройства).

Все ОС
РВ условно делятся на 2 типа – системы
«жёсткого» и «мягкого» реального времени
[CITATION ИББ06 l 1049 ].

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

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

Обычно
в системах «жёсткого» реального времени
время реакции на событии гораздо меньше,
чем регулярный интервал между событиями.
За всю историю развития вычислительной
техники эти интервалы множество раз
пересматривались. Когда-то интервал в
100 миллисекунд был нормой, сейчас же
нормой считаются единицы микросекунд
и даже наносекунды в некоторых случаях.

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

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

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

Исходя
из того, что основная область применения
БагрОС-4000 — авионика, её принадлежность
к классу ОС РВ вполне оправданна. Причём
именно к типу «жёсткого» реального
времени. Актуальность данных с бортовых
приборов самолёта имеет огромное
значение, следовательно «ритмичность»
работы системы и синхронизированность
с различными датчиками и устройствами
управления имеет ключевое значение для
этой ОС.

Завершена сертификация ОСРВ «БагрОС-4000» по требованиям защиты информации в 8 Управлении ГШ ВС РФ.

Завершена сертификация ОСРВ «БагрОС-4000» по требованиям защиты информации в 8 Управлении ГШ ВС РФ.

Завершена сертификация ОСРВ «БагрОС-4000» по требованиям защиты информации в 8 Управлении ГШ ВС РФ. ОС РВ «БагрОС-4000» может использоваться для обработки информации, содержащей сведения, составляющие государственную тайну и имеющие степень секретности «совершенно секретно».

ОСРВ «БагрОС-4000» успешно применяется в самолете Су-57 и готова к применению в составе авионики перспективных и модернизируемых летательных аппаратов.

ОСРВ «БагрОС-4000» позволяет импортозаместить такие известные зарубежные ОСРВ, как VxWorks и Integrity (США), QNX (Канада) и PikeOS (Германия).

Среди возможностей ОСРВ следует отметить:

  • Поддержку многоядерных процессорных архитектур Эльбрус, MIPS64, PowerPC, ARMv7, Intel x86;
  • Поддержку стандартов ARINC 653 и POSIX;
  • Развитой инструментарий для разработки прикладных программ.

Более детальная информация об ОС РВ «БагрОС-4000»

Техническое описание.

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

«БагрОС-4000» поддерживает процессорные архитектуры Эльбрус, MIPS64 (в том числе Мультикор), PowerPC, ARMv7, Intel x86 и обеспечивает функционирование многомодульных (многопроцессорных и многоядерных) вычислительных систем.

Завершена сертификация ОС РВ «БагрОС-4000» по требованиям защиты информации в 8 Управлении ГШ ВС РФ. ОС РВ «БагрОС-4000» может использоваться для обработки информации, содержащей сведения, составляющие государственную тайну и имеющие степень секретности «совершенно секретно».

В «БагрОС-4000» реализованы следующие основные принципы:

  • Мобильность (возможность работы на различных аппаратных платформах);
  • Использование стандартов (спецификация ARINC 653 и стандарт POSIX);
  • Инкапсуляция (разбиение системы на слабо взаимодействующие части);
  • Гибкие средства планирования, включающие как периодические вычисления, так и использование приоритетов;
  • Развитые средства диагностики и обработки ошибок, а также восстановления работоспособности после сбоев;
  • Управляемость (управляемое распределение вычислительных ресурсов, в частности, средствами конфигурирования).

ОС РВ «БагрОС-4000» реализует интерфейс прикладного ПО в соответствии со стандартом ARINC 653 и стандартом POSIX. Взаимодействие ARINC-процессов между собой и с POSIX-процессами осуществляется с помощью каналов, соответствующих спецификации ARINC 653. POSIX-процессы могут взаимодействовать между собой с помощью широкого набора средств, предусмотренных стандартом POSIX (семафоры, очереди сообщений и др.).

ОС РВ «БагрОС-4000» обеспечивает одновременное выполнение нескольких процессов разными ядрами процессора. Нежелательное взаимодействие различных процессов исключается путем использования виртуальной адресации и статического распределения памяти между процессами и операционной системой.

Выполнение ARINC-процессов определяется расписанием (расписаниями). Расписание определяет основной период, который разбивается на временные окна. В каждом окне на данном ядре может выполняться не более одного ARINC-процесса. «БагрОС-4000» предоставляет средства, позволяющие контролировать время выполнения прикладных и системных процессов с тем, чтобы одно приложение не могло использовать время, выделенное другим приложениям.

ОС РВ «БагрОС-4000» имеет развитые средства обработки ошибочных ситуаций, а также содержит средства восстановления работы приложений при сбоях. «БагрОС-4000» имеет средства обработки следующих ошибок:

  • Сбои и отказы аппаратуры;
  • Исключительные ситуации (недопустимый адрес команды, неверные аргументы функций ОС РВ, деление на 0 и т. п.);
  • Переполнение стека памяти;
  • Ошибки, выявленные прикладной программой (недопустимые данные, превышение допустимого интервала времени и т. п.).

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

В состав ОСРВ «БагрОС-4000» входит библиотека для поддержки системы отладки и мониторинга. С помощью данной системы можно отслеживать значения переменных (глобальных/локальных) в конкретных точках отлаживаемого ПО

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

Прикладному программисту предоставляется удобная среда отладки с графическим интерфейсом на базе среды Eclipse функционирующая на Host-компьютере и соединенного с БЦВМ. В ОС РВ «БагрОС-4000» реализован ряд сервисных функций, вызов которых доступен как с консоли, так и из контекста ARINC и POSIX процессов, обеспечивающих получение информации об объектах операционной системы:

  • Информации о процессе;
  • Сведений о состоянии потока управления;
  • Время выполнения прикладных и системных процессов;
  • Статистики по использованию окон;
  • Информации об использовании памяти;
  • Информации о расписаниях и окнах;
  • Информации о портах с очередью сообщений и без и т.п.

Разработка прикладных программ, работающих под управлением БагрОС-4000, предполагает наличие двух ЭВМ, одна из которых выполняет функции инструментальной ЭВМ, а другая — целевого вычислителя. На инструментальной ЭВМ устанавливается операционная система Linux (дистрибутив, базирующийся на rpm или deb пакетах) и пакет кросс-разработки, который обеспечивает разработку модулей прикладных программ, их компиляцию, выполняет создание загружаемого образа с включением в него ОС и файлов прикладных программ.

Детальная информация по вопросу установки и эксплуатации представлена в документе «Руководство программиста».

За дополнительной информации о вопросам лицензирования и использования ОС РВ «БагрОС-4000» обращайтесь

по e-mail: vistomin@okb.sukhoi.org 
или по телефону +7(495)941-76-13

БагрОС 4000 Приобрести

Онлайн компилятор e2k Онлайн компилятор e2k

Вы можете изучать предупреждения, ошибки и ассемблерный код, выдаваемые компилятором, а также просматривать результат выполнения скомпилированной программы для архитектуры Эльбрус(E2K). Поддерживаются языки, C++, Fortran, Rust.

Доступ к серверам Эльбрус

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

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

Идея создания информационно-управляющей системы (ИУС) для современных самолётов в ОКБ Сухого изначально родилась в исследованиях по проекту истребителя пятого поколения. Однако первой она реализовалась на многофункциональном истребителе Су‑35. Благодаря этой системе новая машина с одним пилотом продемонстрировала свои преимущества в Сирии, совершая более десяти боевых вылетов ежедневно.

Работы над новым истребителем Су‑35/35С были развернуты в ОКБ Сухого в 2005 году, когда перед предприятием встала задача обеспечить вывод на рынок перспективного боевого комплекса поколения 4++, способного на качественно новом уровне ответить на выросшие запросы отечественных ВВС и инозаказчиков. «Новая многофункциональная машина с одним пилотом нуждалась в принципиально новом по архитектуре комплексе бортового оборудования. Необходимо было ядро, или, если хотите, стержень, как для авионики, так и для всех самолётных систем», — вспоминает Игорь Дёмин, директор программы — главный конструктор самолёта Су‑35/35С.

Идея ИУС пришла из параллельно проводившихся в ОКБ Сухого обликовых исследований по проекту истребителя пятого поколения — перспективного авиационного комплекса фронтовой авиации (ПАК ФА Т-50), получившего в дальнейшем индекс Су-57. Сформулированный и обоснованный принцип построения интегрированного комплекса бортового оборудования (КБО) на базе информационно-управляющей системы, обеспечивающей широкий спектр задач управления самолётными системами и вооружением, решением руководителей предприятия и темы Су‑35 был принят и положен в основу работ по КБО Су‑35. Этот шаг стал важнейшим залогом технического совершенства боевого самолёта. Так на планере самолёта поколения 4++, по сути, стал реализовываться борт нового, пятого поколения.

Читайте также: Су-35С — тяжёлый многофункциональный истребитель

Дополнительным вызовом для предприятия стала необходимость создания практически с нуля всей инфраструктуры разработки ИУС, подбор и обучение кадров, создание стандартов проектирования, стендово-испытательной базы и, наконец, освоение серийного производства ИУС. Все эти задачи были успешно решены. К настоящему времени более 70 серийных комплектов ИУС прошли испытания и получили лётную годность на стенде главного конструктора ИУС в компании «Сухой».

«Сформированное в компании “Сухой” направление бортового программного обеспечения позволило предприятию встать вровень с такими признанными зарубежными лидерами, как Airbus и Lockheed Martin, которые имеют развитые подразделения программирования авионики, выполняющие эти работы самостоятельно в ответственных проектах. Выигрыш тут очевиден — сроки, стоимость разработки, уровень качества, да и просто техническое совершенство центрального бортового компьютера находится под прямым контролем производителя финального продукта», — говорит Александр Баранов, директор проектов ИУС.

Ключевым элементом реализованной в КБО Су‑35 архитектуры является отказ от традиционного построения комплекса авионики боевого самолёта как набора автономных каналов информации и управления, замыкающихся на лётчика. Эти автономные каналы, со своими собственными датчиками, вычислителями и средствами отображения информации, требовали постоянного присутствия человека в контуре решения задачи.

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

С появлением ИУС необходимость во многих автономных контроллёрах — например, в системе кондиционирования воздуха, или в системе управления оружием — просто отпала. Их функции перешли к программному обеспечению (ПО) ИУС. На место тяжёлым приборам пришёл невидимый программный код. Основными соразработчиками компании «Сухой» по созданию программного обеспечения ИУС стали:

  • Научно-исследовательский институт приборостроения им. В. В. Тихомирова — в части задач управления радиолокационным комплексом и боевого применения (руководитель работ Владимир Клещёв);
  • Государственный научно-исследовательский институт авиационных систем — с передовыми алгоритмами управления авиационными средствами поражения (руководитель работ Татьяна Кузнецова);
  • Раменское приборостроительное конструкторское бюро (РПКБ) — с задачами управления вооружением и пилотажно-навигационным оборудованием.

Всю системную «математику», обмен данными по мультиплексным каналам, управление и контроль общесамолётного оборудования взяли на себя вновь созданные структурные подразделения ОКБ Сухого, объединённые в научно-технический центр (НТЦ) ИУС.

Совместными усилиями впервые в России была разработана и внедрена технология создания сложного ПО бортового вычислителя несколькими предприятиями. Сам же вычислитель ИУС — первая в отечественной практике многопроцессорная бортовая цифровая вычислительная машина «Багет‑53–31М» — был спроектирован в РПКБ под руководством заместителя генерального конструктора Михаила Гущеварова на основе модулей и операционной системы реального времени разработки Федерального научного центра Научно-исследовательского института системных исследований Российской академии наук.

«Идея разработки ИУС собственными силами приживалась в ОКБ Сухого непросто, — вспоминает Виктор Поляков, много лет работавший заместителем генерального директора по КБО. — Многие не понимали, зачем нужно отказываться от привычного построения КБО, знакомой терминологии, многим было некомфортно от одной мысли, что придётся брать на себя ответственность за вопросы, традиционно относившиеся к компетенции смежников».

Предприятия-смежники также были не в восторге от того, что им придётся подстраиваться под непривычные стандарты и работать под глубоким контролем головного исполнителя по ИУС — ОКБ Сухого. Не добавляло очков новой команде ИУС в ОКБ Сухого и то, что средний возраст сотрудников не дотягивал до 30 лет. Практический опыт специалистов был тоже весьма разноплановым — от разработки и успешной сертификации системы «Электронный бортинженер» самолёта Ил‑96Т до программирования на фирме Thales в Париже систем управления воздушным движением для Скандинавии и Праги.

Решительная поддержка молодого коллектива со стороны первых лиц предприятия, главных конструкторов тем Т‑50 и Су‑35/35С Александра Давиденко и Игоря Дёмина, руководителей конструкторского бюро Александра Григоренко и Евгения Савельевских — способствовала преодолению многочисленных проблем и формированию за сравнительно небольшой срок боеспособного и амбициозного коллектива единомышленников.

Лауреаты премии Правительства РФ 2017 года (слева направо) Константин Максаков, Игорь Дёмин, Виктор Поляков, Дмитрий Грибов, Александр Баранов и Сергей Гусев

«Любопытно, что в случае с ИУС не было классического для новаторских проектов расхождения “отцов” и “детей”. Ветераны предприятия, такие как работавший ещё с Павлом Осиповичем Сухим заместитель генерального конструктора Юрий Ильич Шенфинкель, сочувствовали и поддерживали нас. И напротив, некоторые молодые сотрудники, уже успешно освоившие подход “за все отвечает смежник”, были настроены скептически, даже иногда противодействовали», — говорит Дмитрий Грибов, директор — главный конструктор ИУС.

«Первое время доводилось слышать ехидные фразы вроде “малыши в розовых штанишках” или “эти новые русские из НТЦ”, как нас за глаза называли за привычку ходить на работу в костюмах, — вспоминает Александр Баранов. — Но с началом стендовых отработок ИУС это отношение быстро стало меняться в сторону уважительного сотрудничества, а потом и вовсе привело к широкому признанию и принятию идеи интегрированного КБО с ИУС. Те, кто поначалу иронично именовал ядро КБО “ведром”, сами стали предлагать всё новые и новые идеи по реализации в программном обеспечение ИУС функций контроля и управления для своих систем».

Точка невозврата была пройдена, и начался трудный, тяжёлый, но продуктивный этап отладки и испытаний ИУС, на котором уже всё КБ трудилось как одна сплоченная команда.

С перебазированием самолёта Су‑35 в Государственный лётно-испытательный центр им. В. П. Чкалова к отработкам подключились специалисты военно-воздушных сил. Им также пришлось многое поменять в привычных подходах к испытаниям военной техники. Так, начальник отдела ИУС научно-исследовательского испытательного управления воинской части 15650 Олег Шабанов стал автором оригинальной методики проверки отказобезопасности системы, существенно способствовавшей поиску и реализации оптимальных методов обеспечения надёжной работы ИУС.

С началом антитеррористической операции практически сразу стало заметным отличие Су‑35. «Более десяти боевых вылетов ежедневно — такого темпа не видели даже опытные и заслуженные командиры наших ВВС», — отмечает Игорь Дёмин. Объяснение здесь простое — реализация в ИУС развитых алгоритмов контроля и предполётной подготовки самолёта в совокупности с удобными средствами отображения информации позволили существенно ускорить процесс подготовки к вылету и ввода полётного задания. А мощные обзорно-прицельные системы в сочетании с возможностями ИУС по комплексной обработке данных и автоматическому управлению обеспечили высокую точность поражения целей.

Лётные испытания Су‑35 с ИУС, продолжавшиеся не один год, позволили довести до очень высокого уровня боевые и эксплуатационные характеристики самолёта и системы. На всех этапах эту ответственную работу возглавляли главный конструктор Су‑35/35С Игорь Дёмин и его «правая рука» — заместитель главного конструктора по КБО Константин Максаков. Последний не только вёл повседневный «разбор» полётов и руководил оперативной доработкой версии ПО ИУС и аппаратуры блоков, но и отвечал, как начальник «идеологического» отдела КБ Сухого, за интеллект ИУС — перспективные алгоритмы боевого применения.

«Было всё — и ночные работы на стендах в поисках решения проблем, и непрерывная отработка версий ПО ИУС в режиме “без выходных и праздников”, отработки в заснеженном Комсомольске, волнение при перелётах первых построенных самолётов через всю страну на испытания в Ахтубинск, — вспоминает Константин Максаков. — Но всё это меркнет по сравнению с тем чувством, которое мы все испытали, когда по итогам первых же боевых работ самолёта зафиксировали очень высокие точности попаданий в цель. Такого не было ни на одном из прошлых проектов».

Специфическим, но очень важным элементом комплексного внедрения идеологии построения КБО с ИУС стало признание ПО составной частью системы. В отношении неё применимы все правила разработки по ГОСТ РВ 15.203. Поэтому его стоимость стало возможным включить в цену готового изделия. Удалось не только обосновать и согласовать с военным представительством стоимость функционального программного обеспечения в каждом комплекте ИУС‑35, но и в целом доказать высокий экономический эффект от создания этого высокоинтеллектуального продукта. Случай для отечественного авиастроения ранее невиданный — исторически ПО всегда считалось чем-то материально неоформленным, традиционно оценивались и поставлялись только блоки и приборы.

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

«Возникшее в ОКБ Сухого направление разработки информационно-управляющих систем перешагнуло границы знаменитого предприятия и военной области», — говорит Виктор Поляков, в качестве заместителя генерального директора по КБО стоявший у истоков создания ИУС. Вновь приобретённая самолётостроительной фирмой компетенция оказалась очень востребованной и при выполнении гражданских проектов. Мало известен тот факт, что ПО авионики пассажирского самолёта Sukhoi Superjet 100 по контракту с французской корпорацией Thales делали те же самые ребята, которые трудились над созданием ПО ИУС самолётов Су‑35 и Су-57. И это не случайно — в самом начале проекта Су‑35 было решено разрабатывать ПО по международным стандартам. Отечественный ГОСТ Р 51904–2001 — прямой аналог международного RTCA DO‑178B — был впервые применён в полном объёме именно при создании ИУС‑35.

Читайте также: Помогать лётчикам ПАК ФА будет система на базе отечественных многоядерных микропроцессоров

«Сегодня можно констатировать, что за прошедшие 15 лет на “Сухом” сложилась передовая школа бортового программирования. При словах “Sukhoi software” многие зарубежные участники международных конференций и симпозиумов по авионике уважительно кивают головой, — говорит Сергей Гусев, первый заместитель начальника НТЦ ИУС, начинавший свою карьеру на “Сухом” в 2004 году выпускником МАИ. — Очень важно понимать, что общий высокий уровень технологической культуры является, наряду с практическим опытом, залогом высокого качества бортового ПО, объёмы которого на современном самолёте измеряются миллионами строк кода».

«С момента организации в 2012 году компании “ОАК — Центр комплексирования” мы активно используем опыт специалистов фирмы Сухого, полученный на проектах ИУС Су‑35/35С, Т‑50 и SSJ‑100. В результате нашей компанией успешно разработан большой объём ПО авионики для новейшего лайнера МС‑21, и продолжается наращивание функциональных возможностей комплексаики в рамках идущих полным ходом испытаний самолёта», — говорит Виктор Поляков, являющийся ныне генеральным директором компании «ОАК — Центр комплексирования».

Впервые реализованная на Су‑35 идея ИУС к настоящему времени стала признанной основой при проектировании современного КБО летательного аппарата различного назначения. ИУС заняла центральное место в структуре авионики Су-57, модернизируемых «стратегов» Ту‑160, Ту‑22М3, закладывается в архитектуру КБО перспективных вертолётов и ударных беспилотных летательных аппаратов.

К основным преимуществам интегрированного КБО можно отнести:

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

Но инженерная мысль не останавливается. «Мы уже отчетливо видим контуры “постИУСовской” архитектуры КБО, — говорит Дмитрий Грибов. — Новые возможности электроники, волоконноптических линий связи, наша новая операционная система реального времени “Багрос‑4000” позволяют говорить о наступлении эры сетевого борта, где привычные контуры бортовых систем, включая ИУС, будут размыты и появится единая, высоконадёжная, масштабируемая, распределённая вычислительная платформа. В этой связи интересно наблюдать, как подзабытые темы “а зачем нам всё это нужно” и “всё и так хорошо”, звучавшие в момент зарождения идеи интегрированного КБО с ИУС, вновь появляются в рассуждениях некоторых руководителей и специалистов. Но это нормально. Главное, что у большинства суховцев присутствует желание сделать что-то принципиально новое, прорывное.

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

По материалам журнала ОАК «Горизонты», №4 (16), 2017 г.

Загрузка…

Время на прочтение
12 мин

Количество просмотров 15K


Не буду повторяться в тысячный раз, что такое отечественное производство микропроцессоров, почему «Эльбрус», а не «Байкал» и т.д. Об этом были написаны уже километры текста. Речь пойдет о другом – почему так трудно перейти на «Эльбрус» и в чем заключаются эти сложности. Ну, помимо стоимости…

Итак, всех заинтересованных импортозамещением – прошу под кат.

Сделаю лишь одну ремарку – архитектура процессоров «Эльбрус» — это не MIPS, не ARM и тем более не x64. Это архитектура VLIW.
Процессор разработан у нас, в России. В этом его преимущество, он является полностью доверенным, в нем нет закладок (а если и есть, то их секреты находятся у нас). Ахиллесова пята чипа – отсутствие софта. Об этом и пойдет речь.

Про закладки в процессорах архитектуры x86 можно почитать тут.

0. От автора

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

Проработав вопрос импортозамещения для конкретной «компании», а вернее – ФГУП, в котором я проработал почти 10 лет, и написав цикл статей по данному вопросу под общим названием «Импортозамещение на практике», со мной связалась компания НТП «КриптоСофт», после чего я засел за изучение их «QP ОС» примерно на месяц (приходилось совмещать с работой), результатом чего явилась вот эта статья.

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

Я был приятно удивлен, когда пришел в «ВТиСС». Мне предоставили контакты с «МЦСТ», пару ПАК «Эльбрус» (серверы и АРМы) для опытов и не стали ограничивать во времени.

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

1. Операционные системы

Кросс-компилятор

МЦСТ разработала свой кросс-компилятор, который позволяет в среде х64 портировать ПО на архитектуру «Эльбрус». Кросс-компилятор выдают по официальному запросу после подписания NDA с производителем и приобретения ПАК «Эльбрус». (Нативный компилятор входит практически во все ОС, работающие на архитектуре «Эльбрус» в нативном режиме).

Для работы на платформе «Эльбрус»

была разработана своя ОС

портирован дистрибутив Linux, названный ОС «Эльбрус», его можно скачать и потрогать тут (для архитектуры x64, для архитектуры «Эльбрус» ОС скачать можно только после подписания NDA). Позже была портирована ОС Debian «Jessie» — версия 8.11, с последними на момент написания статьи Security Updates. ОС называется «Эльбрус-Д». Это было сделано самим производителем процессоров – МЦСТ. После этого ядро ОС было отдано в РусБИТех и БазАльт, и на основе этого ядра были созданы Astra Linux 8.1 и Альт для архитектуры «Эльбрус». 23.12.2019 было объявлено о портировании на архитектуру «Эльбрус» ОС «Лотос», но о ней нет никаких данных, все закрыто и засекречено, и мне ее потрогать пока не удалось.

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

Да, МЦСТ предусмотрело бинарную трансляцию, которая позволяет запустить на «Эльбрусах» даже Windows, но это ведет к уменьшению производительности примерно на 30%, так что рассматривать этот механизм не вижу смысла. Зачем на доверенном железе разворачивать не доверенную платформу?

Оговорюсь о том, что последнее поколение процессоров «Эльбрус» — 8СВ вполне себе производительно (в тестах использовался процессор «Эльбрус 8С1). Ну… Давайте сформулирую чуть иначе: «Производительности процессора «Эльбрус» последнего поколения более чем достаточно, если на нем запускать ПО в нативном режиме».

Таким образом, мы имеем четыре ОС, которые можно установить на «Эльбрус». И у всех этих ОС, кроме Альт 9, одна версия ядра – 4.9.0 (скорее всего ОС «Лотос» так же построена на базе того же самого ядра, портированного усилиями МЦСТ). У Альт 9 же версия ядра 4.9.170, релиз состоялся 22.10.19г, что говорит нам о том, что люди работают, развивают свою платформу, за что честь им и хвала.

Про ОС Эльбрус

На самом деле ОСей – пять, так как «ОС Эльбрус» существует в 2х ипостасях – собственно, «ОС Эльбрус» и «ОС Эльбрус-Д», первая поставляется как часть ПАК’а, а вторая проходит сертификацию. Возможно, в дальнейшем, после сертификации, поставляться будет так же и ОС «ЭльбрусД», но это не точно.

ОГОВОРКА: ОСи реального времени
Есть еще 2 ОС реального времени, которые могут быть развернуты на платформе «Эльбрус», а именно: ЗОСРВ «Нейтрино-Э» и ОС РВ «БагрОС-4000». Но ОСРВ – это немного другая ниша, там свои правила и свои законы, в эту стороны мы углубляться пока не будем.

ВАЖНО – ОС «Эльбрус», которая поставляется в комплекте ПАК «Эльбрус», была портирована для того, чтобы «просто быть». Если голая ОС никому не нужна, то сервер или АРМ без ОС еще менее интересует потенциальных покупателей. ОС «Эльбрус-Д» — портированный Debian «Jessie» 8.11, продукт, который в настоящий момент проходит сертификацию, и будет доступен к покупке. Но путать эти ОС не стоит.

2. Инфраструктурное ПО

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

По порядку.

В связи с тем, что производители ПО с открытым исходным кодом не имеют возможности самостоятельно собирать свои пакеты на архитектуре процессоров «Эльбрус» да им это и не нужно, этим приходится заниматься производителям ОС. Брать исходные коды и пытаться скомпилировать их на платформе «Эльбрус»… Но легко и быстро это получается далеко не всегда. Связано это с тем, что та же C++ на платформе представлена пока лишь 16 версией, java – 1.8.0 (причем Java есть только в ОСсях от МЦСТ) и так со всеми средствами разработки. То есть все средства разработки, как и окружение в целом, – устаревшие.

Инфраструктурное ПО в составе ОСей позволяет на базовом уровне поднять необходимые сервисы, как-то: DNS, DHCP, SQL DB, SMB, FTP и прочее. Там даже есть Zabbix и Squid. Версии ПО у всех 3х производителей разнятся (что там у «Лотос» я не знаю, но что-то подсказывает, что состав их ПО не сильно отличается от всех остальных ОСей).

Списки пакетов ПО для Альт 9 есть в свободном доступе, кому интересно, вот ссылка. Альт имеет самые свежие версии ПО среди всех представленных ОС.

У Astra Linux есть отдельная статья в Wiki, посвященная их сборке для «Эльбрус». Статья эта не менялась… да, собственно, никогда она не менялась. В ней собрана информация о всех пакетах ПО, которые есть в сборке и репозитории.

Более того, бюллетени безопасности, которые с завидной регулярностью выходят для Astra 1.6, можно сказать, что «не выходят» для Astra 8.1. Был лишь один патч в декабре 2019го. При этом Роман Мылицын, директор по продукту ГК Astra Linux (если верить TAdvisor), в октябре говорил о том, что они «постараются по максимуму привести к последнему апдейту для 1.6»

И в итоге они в конце декабря выкатили обновление в виде Бюллетеней Безопасности, в котором действительно подтянули версии пакетов близко к последнему обновлению Astra Linux SE. Тут другая проблема – Astra SE – это сильно устаревший Debian с ограниченным набором пакетов ПО (так как подлежит сертификации). А также не стоит ждать новых версий Firefox и Thunderbird пока нет java крайних версий, а крайних java-версий пока не предвидится. Почему – можно прочесть тут. Собственно, из этой же статьи очевидно, что портированием java озадачились лишь МЦСТ. А вот на Astra и Альт java нет вообще, не говоря уже о крайних версиях.

У ОС «Эльбрус-Д» ситуация с ПО чуточку лучше, чем у Astra. Совсем чуточку. Списка пакетов для ОС «Эльбрус-Д» в открытом доступе, к сожалению, нет. С другой стороны, у ОС «Эльбрус-Д» нет PHP 7, есть только 5 версия, а у Альт и Astra – есть. Также Zabbix версии 2.4, тогда как у Альт и Astra – 3.4. Словом, что-то посвежее у одних разработчиков, что-то – у других, но версии ПО обычно разнятся несильно.

Но все это капля в море. Например, если вы захотите поднять почтовый сервер на «Эльбрусах», у вас есть только Exim4 в связке с Dovecot (на всех ОС). Можно и их использовать, конечно… но на дворе 2020-й год. Хотелось бы Zimbra как минимум. Но Zimbra – система многомодульная, часть модулей на java, а java есть только у МЦСТ. Словом, тут все сложно и бесперспективно. Почти.

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

3. Прикладное ПО

А вот тут самое интересное. Во всех 3-х ОС есть самый базовый набор типа старого LibreOffice 5.2.7 (у Альт9 версия 5.4.3), Gimp, Firefox оооооочень старый (52.х), Thunderbird, тоже старенький (52.х), VLC. Ну, собственно, на этом практически все. При этом не существует плагинов для того же Firefox, никто не заморачивался их портированием.

То есть на всем этом можно развернуть некое базовое «рабочее место», которое не требует «современных» технологий типа 1С или календаря в почтовом клиенте. Не более.

Проблема все та же: отсутствие актуальных версий средств разработки, окружения, библиотек и т.д. Ну невозможно портировать ПО, требующее C++ последних версий, на систему с поддержкой C++ 17.

Вариантов решения проблемы с ПО, как инфраструктурного, так и прикладного, ровно 2. Дорогой и очень дорогой. Очень дорогой предполагает наличие огромного штата разработчиков, которые будут подгонять существующее ПО под реалии ПАК «Эльбрус». Дорогой предполагает подгонку ПАК «Эльбрус» под современные реалии (поддержание актуальных версий средств разработки, библиотек и окружения в целом), что даст возможность собирать пакеты ПО из исходников под его архитектурой в автоматическом режиме (как это сделано с пакетами для архитектур х64 и ARM, например, у большинства Linux систем).

Логика подсказывает 2-й путь решения. Он и быстрее, и просто правильнее. Можно было бы даже примерно прикинуть, когда наступит светлое будущее. Но правильный ответ на мой вопрос – никогда.

4. Перспективы развития ПАК «Эльбрус»

Почему никогда не наступит момент, когда можно будет взять исходники ПО и собрать его на архитектуре «Эльбрус» просто выполнив make? Потому что:

  1. Вычислительные комплексы на базе процессоров «Эльбрус» доступны к покупке только для юридических лиц. Оно и понятно. И враг не купит, и обывателю не нужен малопроизводительный по современным меркам ПК без поддержки виртуализации за 300+ килорублей.
  2. Вытекает из «1» — ВК не купят коммерческие предприятия, им это просто не выгодно, так что «Эльбрусы» поставляются только в госучреждения и коммерческие предприятия с долей госкапитала (типа РЖД) с подачи сверху. А для таких предприятий важно наличие сертификатов на все, что только можно – будь то бумаги от ФСТЭК, МО, ФСБ, неважно.
  3. Вытекает из «2»: сертификация – процесс долгий и дорогой, делается с расчетом на несколько лет. Сертифицировал ОС и все, что в нее входит – и работает оно там себе без изменений. А внес изменение – все, потерял сертификацию. Контрольные суммы не сошлись – потерял сертификацию. То есть даже если просто повысить версию пакета ПО – нужно либо заново сертифицировать всю ОС с репозиторием, либо через хитрую лазейку запихивать это как «бюллетень безопасности». Тут исключение составляет только ПО сторонних производителей, которое имеет сертификат, подтверждающий совместимость с ОС. Например, МойОфис на Astra 1.6 можно установить без потери сертификации.
  4. Вытекает из «3»: да, можно сертифицировать отдельно ОС и отдельно каждый пакет ПО, потом можно будет повысить версию пакета, сертифицировать этот пакет отдельно от ПАК и обновить – сертификация сохранится, но это оооооооочень дорого и очень долго. Дешевле сертифицировать ОС совместно со всеми имеющимися пакетами и ничего не трогать. Через 5 лет повторить.

Таким образом «подгонять окружение под требования современного софта» никто не будет, никому это не интересно – не окупится, да и просто бесполезно, ведь новые версии ПО добавлять в сертифицированную ОС дорого и долго. Будут делать наоборот. И экономически это будет оправдано. Да, это будет опять базовый софт, только-только перекрывающий необходимый и минимальный набор ПО для работы, но это будет востребовано там, где нужно. И все.

Подробнее про сертификацию

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

  • компания, которая хочет сертифицировать свою сборку ОС, отдает комиссии свой дистрибутив (платит деньги за процесс исследований и оформляет тонну макулатуры)
  • комиссия рассматривает все заявленные характеристики – в том числе и соответствие классам защищенности, соответствие требованиям МО/ФСТЭК/ФСБ, если таковые заявлялись «производителем» ОС, и проч. и проч. и проч.
  • выносится вердикт о соответствии или несоответствии ОС заявленным характеристикам и требованиям сертификации ФСТЭК, МО или ФСБ

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

5. Проприетарное ПО

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

Тут вопрос лишь в том, что для начала работ по портированию ПО разработчик должен увидеть перспективы, а они на данный момент наблюдаются только в направлении госструктур, госорганов и компаний с госкапиталом. Коммерция не будет покупать ПАК за сумасшедшие (по сравнению с теми же Intel или AMD) деньги и страдать от отсутствия софта. Вставлять палки себе же в колеса просто невыгодно.

Так как проблема устаревшего Firefox очевидна, нами было принято решение попробовать портировать другой браузер. Лучше всего – отечественный, лучше всего на движке Blink. Ну не «Амиго» же портировать, право слово (да, я знаю, что он тоже на Blink’е, аццтаньте). И мы пошли на хитрость – кто может решить проблему с java, как не один из «крутых» разработчиков софта в РФ? Мы связывались с Яндексом. Ответ был примерно следующим:

«Яндекс раздает свой браузер бесплатно, и зарабатывают они по большей степени на рекламе, а не на продажах. И для того, чтобы Яндекс взялся за портирование своего браузера на платформу «Эльбрус», нужно гарантировать, что это будет востребовано, что объем установок на следующий год будет хотя бы тысяч 100, и что браузер сможет спокойно обновляться.»

И это логично и правильно с точки зрения бизнеса. Смысл вкладывать в разработку деньги, которые ты не сможешь вернуть? К слову, ответ от разработчиков «Спутник Браузер» был таким же. Не слово в слово, но общий посыл – да. Несмотря на то, что «Спутник» свой браузер корпоративным клиентам продает (у них там свои плюшки есть). И с такими же ответами мы сталкиваемся практически во всех сферах. Ну не будет бизнес делать то, что ему не выгодно. Это удел государства – тратить деньги на то, что не принесет прибыли, там приоритеты другие.

А вот ГОСТовая криптография и антивирусы (как это ни смехотворно – вирусы не просто под Linux, но под засекреченную архитектуру) будут востребованы в госучреждениях и госорганах. Потому и подсуетились Kaspersky, Dr.Web и КриптоПро.

Периодически так же появляются публикации о том, что тот или иной продукт поддерживает архитектуру «Эльбрус». Например:

  • Технологии распознавания Smart Engines поддерживают архитектуру Эльбрус – новость аж от 2016 года
  • RAIDIX еще в 2017 году портировали свое ПО на «Эльбрус»
  • ПОРТИРОВАНИЕ и МИГРАЦИЯ ПО от УНИПРО
  • СХД Яхонт на базе «Эльбрусов»
  • СХД AERODISK на отечественных процессорах Эльбрус 8С
  • На процессорах «Эльбрус» появилась первая система для инженерных расчетов
  • Запуск на Эльбрусе платформы для нейросетей PuzzleLib
  • SCADA для ОС Эльбрус

Но все это – капля в море. Для того, чтобы перекрыть потребности, нужно портировать целые классы ПО – ERP, CAD, CAM, PLM и т.д. и т.п.

6. Заключение

На деле самой перспективной ОС в плане пакетов софта на настоящий момент выглядит Альт 9 — они хотя бы что-то делают. Astra незначительно подтянули версии, но по большому счету это все устаревшее и неактуальное, малофункциональное в прикладном плане ПО. Что происходит за закрытыми дверьми МЦСТ вообще неизвестно. Вернее, известно, что они допиливают свой компилятор, повышают версию C++ для своей платформы, библиотеки для его работы, окружение и т.д. Но доработки в сторону инфраструктурного и прикладного ПО скорее всего не ведутся, так как они в процессе сертификации своей ОС «Эльбрус-Д», которую «выпустили и тут же засекретили». А Альт – коммерция, у них репутация, они работают (не только и не столько с МинОбороны, которым в первую очередь важна защищенность, мандатный контроль доступа и т.д.). Не по ОКРам, а на продажу, не в госучреждения (хотя и туда тоже. Они выпускают и сертифицированные сборки, куда же без этого).

Но результат все равно далек от желаемого. Очень далек.

Таким образом, ПАК «Эльбрус» можно использовать там, где необходима и критична защита от «врага», или есть «самописный» или «специальный» софт, который можно портировать на ПАК теми средствами, которые уже есть. В остальных случаях его использование попросту нецелесообразно и потребует колоссальных нервов и усилий.

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

Мы же работаем над тем, чтобы все эти пылящиеся АРМы и серверы были пущены в дело, по крупицам собирая и агрегируя информацию, находя варианты решения тех или иных задач. Трудно, долго, но упорно, а главное — результативно.

  • РТИ впервые продемонстрировало программно-аппаратную экосистему, предназначенную для компьютеров «Эльбрус»
  • АО «НПК «ВТиСС» на XVI форуме межрегионального сотрудничества России и Казахстана
  • В ВТиСС создан демонстрационный стенд для перспективных исследований ПО

По поводу последнего оговорюсь – мы не просто предлагаем тестировать или демонстрировать работу отечественного ПО на разных архитектурах, мы предлагаем нашим партнерам возможность портирования своего ПО на архитектуру «Эльбрус» на нашем оборудовании (после подписания NDA, разумеется :) ).

7. P.S.: Немного Head Hunting’a

Компания «ВТиСС» рассматривает варианты принятия в штат разработчиков, программистов, как в рамках работ по «Эльбрусам», так и в «более привычных» направлениях. У нас есть интересные проекты, нетривиальные задачи и вызовы. Ну и вот это вот все, как принято писать в рекламе самих себя.

А если простыми словами – компания будет рада рассмотреть кандидатуры программистов и разработчиков с разными компетенциями (в основном требуются C++ программисты, правда, но руководство на моей памяти не отказывалось от принятия в штат перспективных разработчиков). Если кто-то заинтересовался – высылайте резюме! =)

Оставляя данные на сайте, Вы соглашаетесь с Политикой конфиденциальности и защиты информации.

Защита данных

Администрация сайта aviationunion.ru (далее Сайт) не может передать или раскрыть информацию, предоставленную пользователем (далее Пользователь) при регистрации и использовании функций сайта третьим лицам, кроме случаев, описанных законодательством страны, на территории которой пользователь ведет свою деятельность.

Получение персональной информации

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

Использование персональной информации

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

Коммуникация

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

Ссылки

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

Безопасность

Сайт обеспечивает безопасность учетной записи Пользователя от несанкционированного доступа.

Уведомления об изменениях

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

Завершена сертификация ОСРВ «БагрОС-4000» по требованиям защиты информации в 8 Управлении ГШ ВС РФ. ОС РВ «БагрОС-4000» может использоваться для обработки информации, содержащей сведения, составляющие государственную тайну и имеющие степень секретности «совершенно секретно».

ОСРВ «БагрОС-4000» успешно применяется в самолете Су-57 и готова к применению в составе авионики перспективных и модернизируемых летательных аппаратов.

ОСРВ «БагрОС-4000» позволяет импортозаместить такие известные зарубежные ОСРВ, как VxWorks и Integrity (США), QNX (Канада) и PikeOS (Германия).

Среди возможностей ОСРВ следует отметить:

  • Поддержку многоядерных процессорных архитектур Эльбрус, MIPS64, PowerPC, ARMv7, Intel x86;
  • Поддержку стандартов ARINC 653 и POSIX;
  • Развитой инструментарий для разработки прикладных программ.

Новость  
27 февраля 2019, 19:57:37
352


+ 0,07 / 5

Slav Rus

russia
Самара
61 год


Слушатель

Карма: +1,018.87
Регистрация: 25.01.2016
Сообщений: 9,177
Читатели: 15

Модератор раздела

Москва, 26 февраля. Завершена сертификация ОСРВ «БагрОС-4000» по требованиям защиты информации в 8 Управлении ГШ ВС РФ. ОС РВ «БагрОС-4000» может использоваться для обработки информации, содержащей сведения, составляющие государственную тайну и имеющие степень секретности «совершенно секретно».

ОСРВ «БагрОС-4000» успешно применяется в самолете Су-57 и готова к применению в составе авионики перспективных и модернизируемых летательных аппаратов.

ОСРВ «БагрОС-4000» позволяет импортозаместить такие известные зарубежные ОСРВ, как VxWorks и Integrity (США), QNX (Канада) и PikeOS (Германия).

Среди возможностей ОСРВ следует отметить:

  • Поддержку многоядерных процессорных архитектур Эльбрус, MIPS64, PowerPC, ARMv7, Intel x86;
  • Поддержку стандартов ARINC 653 и POSIX;
  • Развитой инструментарий для разработки прикладных программ.

Более детальная информация об ОС РВ «БагрОС-4000» приведена на странице: Техническое описание ОС РВ «БагрОС-4000»

https://www.sukhoi.o…ros-4.html

Мы смеялись в глаза врагу… Хоть нас было всего двадцать восемь

Делай, что должно, и будь что будет.


  • +0.07 / 5

adolfus

Технической информации по ссылке Техническое описание ОС РВ «БагрОС-4000» практически ноль. Как, впрочем, и по байкалам и прочим изделиям мцст по их ссылкам. Очень странная с точки зрения информативности подача этой ОС – абсолютно ничего относительно характеристик, что обычно приводятся в РТО других операционок. Есть мыло,

но что-то  мне подсказывает, что если я им напишу выслать мне эксплуатационную документацию, ответа не последует.

Отредактировано: adolfus — 27 февраля 2019 22:25:12


  • +0.01 / 2
  • Удалено

  • +0.01 / 1

Поверонов

…последует — в форме опера ФСБ с вопросом — «с какой целью интересуетесь…»


  • +0.03 / 2

adolfus

Не последует – это чисто коммерческий проект, как и все остальное, типа байкала и прочих эльбрусов.

Когда-то (в анчале 2000-х) у меня на фабрике купили макетную плату в pci разъем с виртексом и памятью от воронежского скан инвеста (так, кажется они назывались). hdl-проект, что пришел с ней, не соответствовал железу. Фактически там было только ядро из даташитов на плиску. Ни pci-контроллера, ни контроллера памяти не было.
Более чем полгода штурмовали их звонками и электрическими письмами, чтобы те дали проект, соответствующий плате, а также несколько примерных проектов железа и софта. Прислали контроллер памяти и pci-контроллер, который постоянно сбоил. Ни байта хоть какого-нибудь софта. Пришлось брать сетевой драйвер и на его основе писать драйвер для их платы. В конце концов купили у зайлинкса все модули, что должен был поставить это скан инвест – и pci и память. Это был первый и последний опыт работы с железячниками РФ.

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


  • -0.02 / 1

Если эта ОСРВ — оригинальная разработка.
А если клон чего-то с перебитыми копирайтами, аля МСВС (древний рэдхат какой-то) или Линтер-ВС 6.0 (Постгрес), то достаточно узнать клон чего именно.
Кстати — вспоминаем как раз про ОСРВУлыбающийся

Отредактировано: Быдлокодер — 01 марта 2019 09:05:21


  • -0.02 / 1

adolfus

Которая RSX-11? Так она ни разу не ОСРВ.


  • -0.02 / 1

TAU

Linux — далеко не ОС РВ.
А информации на сайте Сухих мало, но для понимания, о чем речь, достаточно. Для знающих. Ключевое слово ARINC 653.
Sapienti sat.


  • +0.08 / 5

TAU

1. Вам про Фому, вы — про Ерему. Ничего не попутали? Речь не об универсальной ОС вроде «ширпотреба».
Наверное, вас тогда обидели, и забыть никак не можете? Где ее устанавливают, прочли? Вот там и будет применяться, и в аналогичных сферах.
2. Ну, можно, конечно, запрет на использование иностранного ПО в военной технике считать принуждением. Но — вполне разумным. Безумным было бы делать по-другому. Кстати, я полагаю, вполне возможно применение и в гражданской авионике — и там уже конкуренция с VxWorks, думаю, будет по цене.
3. См. пункт 1 выше.


  • +0.08 / 5

adolfus

п.1) Цитируете не читая и ли читаете цитируемое не вникая? Выньте палец из носа.


  • -0.02 / 1

adolfus

Конкуренция с vxworks в гражданской авиации начнется тогда, когда сотрудники конторы, которая разрабатывает авионику, будут с новой осью на ты, как это имеет место с той, которую они используют на момент аноса. Прикиньте, что нужно сделать по административной и технической линиям, чтобы проанонсированной осью овладеть, и Ваше «я полагаю» сменится на «я сомневаюсь».
Но этого мало – нужно, чтобы производители авионического железа признали эту ось и обеспечили ее поддержку. Все это реальное время вместе с аринком никому не нужно, если система не выполняет основную функцию – обслуживать конкретные внешние устройства и управлять ими. Где гарантия, что эта новая ось увидит и обслужит по полной привод или датчик, который Вы используете или собираетесь использовать.


  • -0.01 / 2

TAU

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


  • +0.02 / 1

Понравилась статья? Поделить с друзьями:
  • Цефтриаксон инструкция по применению цена уколы детям дозировка
  • Мануал шкода рапид 2015
  • Ацц 600 мг в порошке инструкция по применению
  • Honor инструкция на русском для чайников
  • Мануалы по ремонту ваз 2112