В нашей ОС появилась новая фича, позволяющая разработчикам и тестировщикам производить анализ в рамках методик безопасной разработки. Новый механизм позволяет реализовывать как разнообразные сценарии тестирования 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. Предупреждаю - в статье будет много букв про документацию.
