При разработке драйверов GPIO для нашей операционной системы реального времени "Нейтрино" исторически имеется одна неприятность — отсутствие общего дизайна для таких драйверов. Причин для этого несколько: они считались и считаются тривиальными, разрабатывают их разные организации и разработчики. Из-за этого каждый инженер нередко писал реализацию «под себя»: кто-то в виде сервиса, кто-то даже в виде статической библиотеки. Такой подход, хоть и кажется удобным на первых этапах, со временем приводит к фрагментации кода, усложнению поддержки и невозможности систематизировать накопленный опыт. Чтобы избежать этих проблем в будущем мы решили перейти на унифицированную подсистему управления GPIO устройствами и выработать подход, который будет считаться best practices в нашей ОС.
Разработка графических интерфейсов с использованием facefull для нативных приложений под ОС Нейтрино
У наших заказчиков нередко появляется потребность в использовании различного рода графических интерфейсов для вывода графиков, таблиц, различных показателей и метрик их ФПО, а также элементов управления.
С помощью библиотеки facefull можно создавать современные графические пользовательские интерфейсы с использованием технологий HTML, CSS и JS как для веб, так и для нативных приложений. Библиотека содержит более 30 различных визуальных компонентов с огромными возможностями кастомизации. Все компоненты адаптивные и отлично подходят для использования с разными разрешениями экрана, а также с тачскринами.
Библиотека обладает исчерпывающей документацией, а ее исходный код доступен в публичном репозитории.
В случае с нативными приложениями, в качестве рендера интерфейса выступает системный веб-движок, в случае Нейтрино — это WebKit. В Нейтрино имеется поддержка Qt5, поэтому самый простой способ отображения такого интерфейса — использование компонента QWebView
. Недавно мы рассказывали о нашем инструменте мониторинга аномальной активности, пользовательский интерфейс графического приложения разработан с использованием facefull
.
12 + 8 шагов к мониторингу аномальной активности в ОС Нейтрино
Активности в операционной системе могут быть самыми разнообразными. Это может быть запуск нового процесса или потока, обращение к файловой системе, выделение памяти и многое другое.
Могут возникнуть ситуации, когда (вследствие действий злоумышленника и\или программной\аппаратной ошибки) эта активность становится аномальной, то есть поведение системы начинает отличаться от ожидаемого. Запуск неизвестного процесса на этапе эксплуатации изделия, потребление процессом необычно большого количества памяти, установка сетевых соединений, которых не должно быть в системе — всё это примеры аномальной активности, возможно требующие внимания со стороны пользователя или разработчика.
Подробнее о мониторинге написано в одной из наших статей — Мониторинг аномальной активности в операционной системе «Нейтрино».
В этой статье мы рассмотрим пример практического использования монитора аномалий в ОС Нейтрино.
Подсистема управления общими блоками SoC для ЗОСРВ «Нейтрино»
Современнные Системы-на-Кристалле (SoC) содержат в себе десятки различных контроллеров, вариативность которых меняется в зависимости от поколения или ревизии чипов того или иного производителя. Особо выделяются контроллеры системного тактирования (Clock) и сброса (Reset), объем функциональности которых охватывает все оставшиеся контроллеры более узкого назначения.
В этой статье мы расскажем о новой разработанной подсистеме управления такими блоками в контексте операционной системы реального времени "Нейтрино". Затронем небольшую предысторию её создания, общую архитектуру с примерами кода и пример использования.
Разработка HID-драйвера: шаг за шагом
Предлагаем погрузиться в мир Human Interface Device (HID) в контексте операционной системы реального времени «Нейтрино». В статье мы расскажем про архитектуру HID и коснемся практических аспектов создания драйверов для устройств ввода.
Кроме того, затронем вопросы системной разработки и изучения драйверного API для встраиваемых систем реального времени. Расскажем, почему создание драйверов для взаимодействия с HID-устройствами является достаточно важным, но, при этом, достаточно простым процессом.
Jenkins: оптимизируя динамический пайплайн → распределённая сборка компонентов ОС
В процессе улучшения подходов к менеджменту зависимостей компонентов нашей Операционной Системы появилась необходимость перейти от монолитной статической сборочной системы на основе CI/CD инструментов к динамическому распределённому подходу с порождением сотен и тысяч автономных задач. Как выяснилось в процессе, это не самый радужный сценарий использования систем автоматизации, но вполне достижимый.
В результате был спроектирован и внедрён динамический сборочный конвейер на базе Jenkins, масштабируемый как горизонтально, так и вертикально. В статье расскажем как он устроен, решение каких проблем потребовало адресной оптимизации по скорости выполнения, и какие подводные камни повсплывали.
Также частично раскроем информацию о том, как мы выполняем распределённую сборку дистрибутивов.
Ожидается много текста и примеров кода.
Машинное обучение и встраиваемые системы. Демонстрация возможностей
Одним из преимуществ технологий машинного обучения является их способность к обучению и адаптации на основе новых данных, что позволяет решать задачи распознавания образов, обработки естественного языка и поиска закономерностей и аномалий. Традиционно, собранные данные обрабатываются на серверах, однако для ряда задач целесообразнее (а иногда необходимо) использовать другой подход, называемый граничным машинным обучением (edge machine learning).
В этой статье мы расскажем о практическом применении нашего фреймворка машинного обучения для встраиваемых систем на примере демонстрационного стенда, который мы показывали на форуме “Армия-2023”.
Как мы переводили проект на CMake

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

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

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

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

Огромный объём документации по функционалу библиотек Qt уже включён в состав дистрибутива Qt Creator. Таким образом, при работе над кодом не нужно переключаться между IDE и веб-браузером чтобы найти интересующую информацию. Очень удобно!
Но как быть, если хочется иметь свою справку на свой продукт, и чтобы её было также удобно использовать в работе в Qt Creator, наряду со стандартной справкой Qt? Чтобы можно было переходить из редактора кода непосредственно на страницы интересующих нас функций/типов/классов или же каких-то статей?
В данной статье пошагово разберём алгоритм составления и интеграции справки в Qt Creator, а также поделимся собственным опытом.
Эволюция графической подсистемы в отечественной ОС «Нейтрино»

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

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

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

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

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

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

Распространение технологий промышленного интернета вещей, беспилотных транспортных средств и других кибер-физических систем, влияющих на безопасность людей, делает всё более актуальным соответствие программируемых электронных устройств требованиям международных стандартов в области функциональной безопасности, в частности IEC 61508 и ISO 26262.
У разработчиков аппаратных средств и программного обеспечения возникает множество практических вопросов, для ответа на которые требуется дать некое комплексное понимание, что позволит быстро уловить принципы решения множества частных вопросов и задач, казалось бы, маленьких, но являющихся важной частью мозаики.
Для глубокого понимания сути разработки и сертификации программно-аппаратных систем ответственного назначения, необходимо знать «трех китов» функциональной безопасности:
- Культура безопасности (Safety Cultute)
- Менеджмент функциональной безопасности (Functional Safety Management, FSM);
- Доказательство безопасности (Safety Case).
В этой статье речь пойдет о о первом из них, Safety Culture. Точнее, о характерных признаках разных типов культуры безопасности и об особенностях культуры безопасности для компаний-разработчиков электрических, электронных и программных компонентов систем безопасности.
Особенности применения языков программирования С и С++ при разработке ПО, связанного с функциональной безопасностью

Крис Хоббс (Chris Hobbs) в своей фундаментальной работе «Embedded Software Development for Safety-Critical Systems» [1] приводит распространенное среди программистов мнение о том, что накладывать ограничения на языки программирования, это как заказывать Пикассо создание картины, при этом запрещать ему использовать желтый цвет. Тем не менее, сложно представить себе предприятие, которое серьезно занимается разработкой программного обеспечения для систем ответственного назначения, у которого в писанных или неписанных стандартах не было бы указаний о том, какой язык программирования применять и, мало того, как его применять.
Данная статья посвящена подходу, который определен в стандарте IEC 61508 и который состоит в применении для разработки ответственного программного обеспечения безопасных подмножеств языков программирования С и С++.
Информация
- Сайт
- www.kpda.ru
- Дата регистрации
- Дата основания
- Численность
- 51–100 человек
- Местоположение
- Россия
- Представитель
- Игорь Дерябин