Современнные Системы-на-Кристалле (SoC) содержат в себе десятки различных контроллеров, вариативность которых меняется в зависимости от поколения или ревизии чипов того или иного производителя. Особо выделяются контроллеры системного тактирования (Clock) и сброса (Reset), объем функциональности которых охватывает все оставшиеся контроллеры более узкого назначения.

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

Предлагаем погрузиться в мир Human Interface Device (HID) в контексте операционной системы реального времени «Нейтрино». В статье мы расскажем про архитектуру HID и коснемся практических аспектов создания драйверов для устройств ввода.

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

В процессе улучшения подходов к менеджменту зависимостей компонентов нашей Операционной Системы появилась необходимость перейти от монолитной статической сборочной системы на основе CI/CD инструментов к динамическому распределённому подходу с порождением сотен и тысяч автономных задач. Как выяснилось в процессе, это не самый радужный сценарий использования систем автоматизации, но вполне достижимый.

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

Также частично раскроем информацию о том, как мы выполняем распределённую сборку дистрибутивов.

Ожидается много текста и примеров кода.

Одним из преимуществ технологий машинного обучения является их способность к обучению и адаптации на основе новых данных, что позволяет решать задачи распознавания образов, обработки естественного языка и поиска закономерностей и аномалий. Традиционно, собранные данные обрабатываются на серверах, однако для ряда задач целесообразнее (а иногда необходимо) использовать другой подход, называемый граничным машинным обучением (edge machine learning).

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

В статье мы расскажем о том, как переводили проект с рекурсивной сборочной подсистемы ЗОСРВ "Нейтрино", представляющей собой набор расширений инструмента GNU Make на сборочную систему CMake: с какими нюансами нам пришлось столкнуться, какие преимущества мы получили в результате перевода и как это повлияло на нашу команду разработчиков.

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

Для реализации этой автоматизации мы используем несколько Jenkins Declarative Pipeline'ов и обширный набор инструментов, о которых рассказывается в статье.

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

При использовании нашей операционной системы пользователи регулярно обращают внимание на то, что процесс её загрузки от передачи управления ядру, до начала выполнения прикладного кода, не всегда прозрачный. В результате анализа обращений мы пришли к выводу, что необходимо внедрить штатный механизм информирования и профилирования процесса загрузки системы (boot sequence). Основной особенностью внедренного решения является его децентрализованность, поскольку ОС является микроядерной и все привычные системные сервисы реализованы вне ядра. Технология прикладного профилирования (тот же gprof) в данном случае не самый подходящий инструмент.

Огромный объём документации по функционалу библиотек Qt уже включён в состав дистрибутива Qt Creator. Таким образом, при работе над кодом не нужно переключаться между IDE и веб-браузером чтобы найти интересующую информацию. Очень удобно!

Но как быть, если хочется иметь свою справку на свой продукт, и чтобы её было также удобно использовать в работе в Qt Creator, наряду со стандартной справкой Qt? Чтобы можно было переходить из редактора кода непосредственно на страницы интересующих нас функций/типов/классов или же каких-то статей?

В данной статье пошагово разберём алгоритм составления и интеграции справки в Qt Creator, а также поделимся собственным опытом.

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

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

Многие расширения (модули) Python поставляются в виде платформонезависимого байт-кода и могут быть использованы в системах с любой архитектурой. Однако, в некоторых случаях расширения поставляются в виде Py-исходников лишь частично. Например, часть внутренних функций может быть реализована на Си и для обеспечения работоспособности всего расширения потребуется их предкомпиляция для каждой требуемой архитектуры. В контексте ОС «Нейтрино» перечень последних достаточно широк.

В статье рассмотрим общий подход к портированию Python-расширений в нашу ОС. Для примера возьмем NumPy, чей жизненный путь проходит следующие стадии: нативный Pyhton код →трансляция в Си (Cython) → компиляция → запаковка результатов с wrapper-ами для Python.

Основной областью применения ЗОСРВ «Нейтрино» являются встраиваемые системы для обработки данных и управления оборудованием в реальном времени без участия оператора. Однако Нейтрино обладает и развитыми графическими возможностями, что позволяет строить на ее основе разнообразные бортовые индикаторы, мобильные устройства и многодисплейные АРМы операторов. В подобных устройствах зачастую необходимо решать задачи, связанные с обработкой и визуализацией цифровой картографической информации (ЦКИ), такие как навигация, анализ и моделирование обстановки и схожие с ними задачи. В этой статье мы расскажем об архитектуре и возможностях нашего картографического пакета, принципах использования и проинформируем о планах его развития.

Активности в операционной системе могут быть самыми разнообразными. Это может быть и запуск нового процесса или потока, и обращение к файловой системе, и выделение памяти, и многое другое. Могут возникнуть ситуации, когда (вследствие действий злоумышленника и\или программной\аппаратной ошибки) эта активность становится аномальной, то есть поведение системы начинает отличаться от ожидаемого. Запуск неизвестного процесса на этапе эксплуатации изделия, потребление процессом необычно большого количества памяти, установка сетевых соединений, которых быть не должно в системе - всё это примеры аномальной активности, возможно требующие внимания со стороны пользователя или разработчика.

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

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

Если для вашего софта или девайса потребовалось получить сертификат по функциональной безопасности (ФБ), а вы ещё не знаете, что это такое и в какую сторону «копать», то эта статья как раз для вас. Постановка задачи может содержать такие слова как «требования по SIL», «сертификат по МЭК 61508» и прочие в зависимости от степени удалённости от темы конкретного человека. Также есть много стандартов-«родственников»: IEC 61511, ISO 26262 и прочих, коих не счесть, сертификация по которым требуется заказчику – суть их примерно одна т.к. они так или иначе основаны на методологии ГОСТ Р МЭК 61508. Предупреждаю - в статье будет много букв про документацию.

• Культура безопасности (Safety Cultute)
• Менеджмент функциональной безопасности (Functional Safety Management, FSM);
• Доказательство безопасности (Safety Case).