Операционная система реального времени

Скорость выполнения ThreadX

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

Ниже приведены типичные характеристики производительности ОСРВ Azure ThreadX.

  • Быстрая загрузка: ОСРВ Azure ThreadX загружается менее чем за 120 циклов.

  • Возможность отключения базовой проверки на ошибки: базовую проверку на ошибки ОСРВ Azure ThreadX можно пропустить во время компиляции. Это может быть удобно, когда код приложения проверен и больше не требует проверки на наличие ошибок для каждого параметра. Проверку на ошибки можно пропустить на уровне компилируемого модуля, а не всей системы.

  • Структура picokernel: службы не размещаются на разных уровнях, что устраняет ненужные временные затраты при вызове функций.

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

  • Оптимизированная обработка API:

    Служба ОСРВ Azure ThreadX Время работы службы в микросекундах*
    Приостановка потока 0,6
    Возобновление потока 0,6
    Отправка в очередь 0,3
    Получение в очередь 0,3
    Получение семафора 0,2
    Задание семафора 0,2
    Переключение контекста 0,4
    Реагирование на прерывание 0,0–0,6

    *Показатели производительности приведены для типового процессора с частотой 200 МГц.

Виды многозадачности

Смешанная многозадачность

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

Допустим, задача А всегда исполняется в течение 700 мкс, после чего передаёт управление планировщику при помощи функции Yield(). Планировщик поставит на исполнение задачу Б. Но через 300 мкс придёт прерывание от таймера, и планировщик передаст управление следующей задаче В. Так как передача управления происходит последовательно, задача Б окажется вечно ущемлённой. Ей всегда будет отдаваться неполноценный квант времени, а остаток от кванта задачи А

Принудительное переключение задачи не влияет на этот таймер. Допустим, задача А всегда исполняется в течение 700 мкс, после чего передаёт управление планировщику при помощи функции Yield(). Планировщик поставит на исполнение задачу Б. Но через 300 мкс придёт прерывание от таймера, и планировщик передаст управление следующей задаче В. Так как передача управления происходит последовательно, задача Б окажется вечно ущемлённой. Ей всегда будет отдаваться неполноценный квант времени, а остаток от кванта задачи А.

Архитектуры ОСРВ

В своем развитии ОСРВ строились на основе следующих архитектур:

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

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

Защита памяти с помощью модулей ОСРВ Azure ThreadX

Дополнительный продукт, называемый модулями ОСРВ Azure ThreadX, позволяет объединить один или несколько потоков приложения в модуль, который можно динамически загружать и запускать (или выполнять на месте) на целевом оборудовании.

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

Модули также используют диапазон адресов, отдельный от ОСРВ Azure ThreadX. Это позволяет ОСРВ Azure ThreadX применять защиту памяти (посредством MPU или MMU) для модуля, которая не позволяет непреднамеренному обращению извне модуля повредить какой-либо другой программный компонент.

Поддержка подсистемы реального времени (RTSS)

Подсистема реального времени RTSS обеспечивает исполнение большинства функций и управление ресурсами расширений реального времени. С точки зрения реализации RTSS выглядит как драйвер Windows и выполняется в режиме ядра. Это позволяет достаточно простым способом устроить взаимодействие между процессами реального времени и процессами Windows. Подсистема RTSS обеспечивает исполнение функций RTAPI и содержит планировщик нитей реального времени со 128-ю фиксированными приоритетами. В ней также содержится менеджер объектов, предоставляющий унифицированные механизмы использования системных ресурсов. По сравнению с набором объектов Windows добавлены таймеры и обработчики прерываний. Интерфейс RTAPI является расширением Win32 и содержит прежде всего набор функций, необходимых для управления устройствами. Он реализован в двух видах: как подмножество подсистемы реального времени (RTSS) и как динамическая библиотека (DLL), которая может вызываться из Win32-приложений. Интерфейс RTAPI содержит следующие группы функций:

  • управление процессами и нитями: Win32-совместимый интерфейс для управления, создания, изменения приоритетов, профилирования и завершения нитей реального времени;
  • управление объектами RTSS: возможности унифицированного управления объектами RTSS (создание, закрытие, доступ). Объектами RTSS являются таймеры, обработчики прерываний и исключительных ситуаций (startup, shutdown, blue screen), нити, процессы, семафоры, мьютексы, разделяемая память, почтовые ящики, консольный и файловый ввод/вывод, регистры;
  • взаимодействие между процессами: использование семафоров, мьютексов (mutex) и разделяемой памяти как для взаимодействия нитей реального времени между собой, так и процессов реального времени с процессами WIN32;
  • управление памятью: позволяет фиксировать приложения в памяти, запрещая их выгрузку в файл подкачки;
  • доступ к физической памяти: приложение пользователя получает возможность доступа к данным по физическим адресам памяти;
  • управление прерываниями: содержит функции, позволяющие назначать и запрещать обработчики прерываний, разрешать и запрещать прерывания;
  • часы и таймеры: содержит функции управления часами и таймерами (создание, удаление, отмена, инициализация таймеров, назначение обработчиков прерываний);
  • управление вводом/выводом: имеется два способа управления устройствами ввода/вывода. Во-первых, приложения пользователя получают возможность непосредственного доступа к адресам портов ввода/вывода, что позволяет программировать работу устройств напрямую. Кроме того, внешнее устройство может управляться специальными (легко разрабатываемыми) драйверами, для работы с которыми RTAPI предоставляет специальный интерфейс.

Расширение RTX поддерживает как однопроцессорные, так и многопроцессорные конфигурации для Windows NT, 2000 и XP. Исполнительная версия RTX, которая поддерживает работу многопроцессорных систем, обеспечивает все возможности однопроцессорной версии плюс возможности многопроцессорных систем, совместимых с архитектурой Intel MPS, что позволяет значительно повысить производительность приложений. Мультипроцессорная версия RTX реализует модель «выделенного процессора», в которой RTSS выполняется только на одном процессоре, в то время как на других процессорах выполняются стандартные приложения Windows.

Философия дизайна

RTOS — это операционная система, в которой время, необходимое для обработки входного стимула, меньше времени, прошедшего до следующего входного стимула того же типа.

Самые распространенные конструкции:

  • Событийный — переключает задачи только тогда, когда требуется обслуживание более приоритетного события; называется преимущественный приоритет, или приоритетное планирование.
  • Разделение времени — переключает задачи на обычное синхронизированное прерывание и на события; называется по-круговой.

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

Рано Проекты ЦП требовалось много циклов для переключения задач, в течение которых ЦП не мог делать ничего полезного. Например, с частотой 20 МГц процессора (типично для конца 1980-х годов) время переключения задач составляет примерно 20 микросекунд. Напротив, 100 МГц РУКА Процессор (с 2008 г.) переключается менее чем за 3 микросекунды. Поскольку переключение занимало очень много времени, ранние операционные системы пытались минимизировать потери процессорного времени, избегая ненужного переключения задач.

Усовершенствованные технологии

ОСРВ Azure ThreadX примечательна тем, что в ней используется планирование с использованием порога вытеснения. Это уникальная функция ОСРВ Azure ThreadX, которая была предметом обширных научных исследований. Дополнительные сведения см. в статье Scheduling Fixed-Priority Tasks with Preemption Threshold (Планирование задач с фиксированным приоритетом с использованием порога вытеснения), написанной Юнь Ванем (Yun Wang) из университета Конкордия и Манасом Саксеной (Manas Saksena) из Питтсбургского университета.

Ниже приведены основные возможности ОСРВ Azure ThreadX.

  • Полные и исчерпывающие средства многозадачности:
  • Планирование с вытеснением на основе приоритета.
  • Гибкость приоритетов — до 1024 уровней приоритета.
  • Координированное планирование.
  • Порог вытеснения — уникальная особенность ОСРВ Azure ThreadX, которая помогает сократить число переключений контекста и гарантировать работу по расписанию (согласно научным исследованиям).
  • Защита памяти с помощью модулей ОСРВ Azure ThreadX.
  • Полностью детерминированные операции.
  • Трассировка событий — запись n последних событий системы или приложения.
  • Цепочки событий позволяют зарегистрировать функцию обратного вызова уведомления, зависящую от приложения, для каждого объекта связи или синхронизации ОСРВ Azure ThreadX.
  • Модули ОСРВ Azure ThreadX с необязательной защитой памяти.
  • Метрики производительности времени выполнения:
    • число возобновлений потоков;
    • число приостановок потоков;
    • число запрашиваемых вытеснений потоков;
    • число асинхронных прерываний с вытеснением потоков;
    • число инверсий приоритета потоков;
    • число освобождений потоков.
  • Набор профилей выполнения (EPK).
  • Отдельный с стек прерываний.
  • Анализ стека во время выполнения.
  • Оптимизированная обработка прерываний таймера.

Настройка приложения Nucleus SE

nuse_config.hnuse_config.c

Настройка nuse_config.h

#definenuse_config.hСчётчики объектовNUSE_SEMAPHORE_NUMBERNUSE_SIGNAL_SUPPORTRUEАктиваторы функций API NUSE_PIPE_JAMTRUEВыбор планировщика и его настройкиNUSE_SCHEDULER_TYPENUSE_RUN_TO_COMPLETION_SCHEDULERNUSE_TIME_SLICE_SCHEDULERNUSE_ROUND_ROBIN_SCHEDULERNUSE_PRIORITY_SCHEDULERNUSE_TIME_SLICE_TICKSNUSE_SCHEDULE_COUNT_SUPPORTTRUEFALSENUSE_SUSPEND_ENABLENUSE_SUSPEND_ENABLETRUEДругие параметрыTRUEFALSENUSE_API_PARAMETER_CHECKINGNUSE_INITIAL_TASK_STATE_SUPPORTNUSE_READYNUSE_PURE_SUSPENDNUSE_READYNUSE_SYSTEM_TIME_SUPPORTNUSE_INCLUDE_EVERYTHING

Настройка nuse_config.c

nuse_config.hnuse_config.cnuse_config.cДанные задачNUSE_Task_Start_Address[]NUSE_Idle_Task()ADDRNUSE_Task_Stack_Base[]NUSE_Task_Stack_Size[]NUSE_INITIAL_TASK_STATE_SUPPORTNUSE_Task_Initial_State[]NUSE_READY или NUSE_PURE_SUSPENDДанные пулов разделовU8NUSE_Partition_Pool_Data_Address[]NUSE_Partition_Pool_Partition_Number[]NUSE_Partition_Message_Size[]Данные очередейADDRNUSE_Queue_Data[]NUSE_Queue_Size[]Данные каналов передачи данныхU8NUSE_Pipe_Data[]NUSE_Pipe_Size[]NUSE_Pipe_Message_Size[]Данные семафоровNUSE_Semaphore_Initial_Value[]Данные таймеров приложенияNUSE_Timer_Initial_Time[]NUSE_Timer_Reschedule_Time[]NUSE_TIMER_EXPIRATION_ROUTINE_SUPPORTTRUENUSE_Timer_Expiration_Routine_Address[]NUSE_Timer_Expiration_Routine_Parameter[]

Виды ОС РВ

Динамические свойства программ реального времени принято характеризовать тремя определениями: программы «жесткого» (hard), «мягкого» (soft) и интерактивного («условного») реального времени.

Жесткое реальное время. Предусматривает наличие гарантированного времени отклика системы на конкретное событие, например, аппаратное прерывание, выдачу команды управления и т.п. Абсолютная величина времени отклика большого значения не имеет. Так, если необходимо, чтобы программа отработала некоторую команду за 1 миллисекунду, но она справляется с этим заданием лишь в 95% случаев, а в 5% не укладывается в норматив, такую систему нельзя охарактеризовать как работающую в жестком реальном времени. Если же команду нужно отработать в течение часа, что и происходит в 100% случаев – налицо жесткое реальное время.

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

Мягкое реальное время. В этом случае ожидающееся время отклика
системы является величиной скорее индикативной, нежели директивной. Конечно, предполагается что в большинстве случаев (процентов 80 — 90) отклик уложится в заданные пределы. Однако и остальные варианты – в том числе полное отсутствие реакции системы – не должны приводить к плачевным результатам. Обычно считается, что если временной норматив превышен на один порядок, то это еще терпимо .

Интерактивное реальное время. Является скорее психологической, нежели технической характеристикой. Определяет время, в течение которого оператор – человек – способен спокойно, без нервозности, ожидать реакции системы на данные им указания. В качестве примера можно привести весьма популярные сегодня игры из категории «стратегии реального времени» (real-time strategy, см. например квазар на основе Warhammer).

В системах реального времени необходимо введение некоторого директивного срока (в англоязычной литературе – deadline), до истечения которого задача должна обязательно (для систем мягкого реального времени – желательно) выполниться. Этот директивный срок используется планировщиком задач как для назначения приоритета задачи при ее запуске, так и при выборе задачи на выполнение.

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

Больше, чем ПЛК

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

SEA воспользовалась ОСРВ RTX (компании Citrix г. Волтхем (Waltham), Массачусетс), установленной на промышленном компьютере Simatic Microbox 420. ОСРВ предоставляет гораздо больше возможностей, чем это кажется на первый взгляд. „Они смотрят на компьютер и считают, что это ПЛК…, не понимая, что ОСРВ — это гораздо больше, чем ПЛК»,-говорит Кацзор.

Одна из ключевых возможностей — это возможность и средства коммуникации. Поль Чен (Paul Chen), менеджер по линии продуктов VxWorks в компании-производителе ОСРВ Wind River Systems (г.Аламеда, Калифорния) отмечает, что взаимодействие с внешним миром — это необходимое требование для современной операционной системы реального времени. Система должна поддерживать такие общепринятые интерфейсы как USB, Ethernet и беспроводную связь. Пользователям также требуется внедрение таких стандартов как Internet нового поколения (IPv6), различные варианты беспроводного протокола 802.х MIPv4 и MIPv6 для мобильных приложений и средства обеспечения безопасности: IPsec и HTTPS.

Требования производителям ОСРВ диктуют пользователи. „Если операционная система реального времени не будет обладать нужной функциональностью, пользователям придется дописывать нужные компоненты самим»,-говорит Чен.

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

То же самое можно сказать и о вопросах безопасности и защиты информации. Они возникают в аэрокосмических, промышленных и медицинских приложениях, которые регулируются стандартами, начинающимися 3-х буквенными аббревиатурами: FAA DO-178B, IEC 61508 и FDA 510(k).

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

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

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

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

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

Планирование задач

Работа планировщика

Большинство ОСРВ выполняет планирование задач, руководствуясь следующей схемой. Каждой задаче в приложении ставится в соответствие некоторый приоритет. Чем больше приоритет, тем выше должна быть реактивность задачи. Высокая реактивность достигается путём реализации подхода приоритетного вытесняющего планирования (preemptive priority scheduling), суть которого заключается в том, что планировщику разрешается останавливать выполнение любой задачи в произвольный момент времени, если установлено, что другая задача должна быть запущена незамедлительно.

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

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

Каждый раз, когда планировщик задач получает сигнал о наступлении некоторого внешнего события (триггер), причина которого может быть как аппаратная, так и программная, он действует по следующему алгоритму:

Определяет, должна ли текущая выполняемая задача продолжать работать.
Устанавливает, какая задача должна запускаться следующей.
Сохраняет контекст остановленной задачи (чтобы она потом возобновила работу с места остановки).
Устанавливает контекст для следующей задачи.
Запускает эту задачу.

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

Выполнение задачи

В обычных ОСРВ задача может находиться в трёх возможных состояниях:

  • задача выполняется;
  • задача готова к выполнению;
  • задача заблокирована.

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

Основная функция администратора ОСРВ заключается в составлении такого планировщика задач.

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

Алгоритмы планирования

В настоящее время для решения задачи эффективного планирования в ОСРВ наиболее интенсивно развиваются два подхода:

  • статические алгоритмы планирования (RMS, Rate Monotonic Scheduling) — используют приоритетное вытесняющее планирование, приоритет присваивается каждой задаче до того, как она начала выполняться, преимущество отдаётся задачам с самыми короткими периодами выполнения;
  • динамические алгоритмы планирования (EDF, Earliest Deadline First Scheduling) — приоритет задачам присваивается динамически, причём предпочтение отдаётся задачам с наиболее ранним предельным временем начала (завершения) выполнения.

При больших загрузках системы EDF более эффективен, нежели RMS.

Выделение памяти

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

Во-первых, скорости выделения памяти. Стандартная схема выделения памяти предусматривает сканирование списка неопределённой длины для нахождения свободной области памяти заданного размера, а это неприемлемо, так как в ОСРВ выделение памяти должно происходить за фиксированное время.

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

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

Также этот алгоритм отлично функционирует и в настольных системах, особенно тогда, когда во время обработки участка памяти одним ядром следующий участок памяти обрабатывается другим ядром. Такие оптимизированные для настольных систем ОСРВ, как Unison Operating System или DSPnano RTOS, предоставляют указанную возможность.

Основные требования к ОС РВ

Мартин Тиммерман (директор компании-разработчика встраиваимых систем Dedicated Systems Experts) сформулировал следующие необходимые требования для ОС РВ:

  • ОС должна быть многозадачной и допускающей вытеснение (preemptable),
  • ОС должна обладать понятием приоритета для потоков,
  • ОС должна поддерживать предсказуемые механизмы синхронизации,
  • ОС должна обеспечивать механизм наследования приоритетов,
  • поведение ОС должно быть известным и предсказуемым (задержки обработки прерываний, задержки переключения задач, задержки драйверов и т.д.); это значит, что во всех сценариях рабочей нагрузки системы должно быть определено максимальное время отклика.

Объем памяти ThreadX

ОСРВ Azure ThreadX требуется очень мало ресурсов — всего 2 КБ для области хранения команд и 1 КБ ОЗУ. В основном это обусловлено одноуровневой архитектурой picokernel и автоматическим масштабированием. Автоматическое масштабирование означает, что во время компоновки в окончательный образ добавляются только службы (и поддерживающая инфраструктура), используемые приложением.

Ниже приведены типичные размеры для ОСРВ Azure ThreadX.

Служба ОСРВ Azure ThreadX Типичный размер в байтах
Основные службы (обязательные) 2 000
Службы очередей 900
Службы флагов событий 900
Службы семафоров 450
Службы мьютексов 1200
Службы блоков памяти 550
Службы управления байтами памяти 900

Планировщик с учетом приоритетности процессов

Рис. 3 Классификация планировщиков.

  • Rate-Monotonic Scheduling — алгоритм со статическим приоритетом класса планирования. Статические приоритеты назначаются в соответствии с продолжительностью цикла задачи, вследствие чего более короткие циклы имеют более высокий приоритет исполнения. В худшем случае КПД загрузки центрального процессора ограничен следующей величиной.

    При числе процессов n, стремящемся к бесконечности ряд будет сходиться к ln2 ≈ 0.693147.

  • Earliest-deadline-first (EDF) Scheduling динамически назначает приоритеты в соответствии с крайним сроком. Чем раньше крайний срок, тем выше приоритет и чем позже крайний срок, тем ниже приоритет. В отличие от RMS, планировщик EDF не требует, чтобы процессы были периодическими и постоянно запрашивали одно и то же количество процессорного времени на пакет. Единственное требование состоит в том, чтобы процесс объявлял свой крайний срок планировщику, когда он готов к запуску.
    Рис. 4 Планировщик EDF.
    На рисунке видим общий принцип работы планировщика. На точке 4 был замещён T1 и его место занял T2 так как его крайний срок наступал раньше, чем у T2. После отработки T3 планировщик вернулся к T1, который завершился на отметке 23.
  • POSIX real-time-scheduling. Стандарт POSIX.4 определяет три политики планирования. Каждый процесс имеет атрибут планирования, который может быть выставлен в одну из трех вариантов политики.

    • SCHED_FIFO — политика упреждающего планирования с постоянным приоритетом, при которой процессы с одинаковым приоритетом обрабатываются в порядке «первым пришел — первым обслужен» (FIFO). Данная политика может иметь не менее 32 уровней приоритета.
    • SCHED_RR — политика аналогична SCHED_FIFO, но использует метод временного среза (циклический перебор) для планирования процессов с одинаковыми приоритетами. Он также имеет 32 уровня приоритета.
    • SCHED_OTHER — политика не определена и зависит от системы; может вести себя по-разному в разных реализациях.

Нормативное регулирование в части ПО

  • Требованиями Федерального закона №188-ФЗ от 29.06.2015г. и постановления Правительства РФ №1236 от 16.11.2015г. установлен запрет на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд, а на Минкомсвязи России возложено ведение единого реестра российских программ для ЭВМ.
  • Экспертным советом по программному обеспечению при Минкомсвязи принято решение об отказе во включении в реестр ПО и недопущении использования программного обеспечения, базирующегося на программных продуктах иностранного происхождения (Протокол №467пр от 12.11.18г.).
  • Состоявшееся 05.03.2019г. заседание НТС ВПК РФ отметило, что применение ПО, происходящего из иностранных государств, в особо ответственных системах и комплексах, в том числе в образцах ВиВТ, противоречит действующим законам, и рекомендовало МО РФ ужесточить контроль с целью недопущения применения ПО, основанного на зарубежном программном коде.

Похожие записи:

Выбор импульсных зарядных устройств для автомобильного аккумулятора Как подключить бра с выключателем шнурком, цепочкой Гофрированная труба для вытяжки и ее преимущества Оптоволоконные линии связи: неограниченные возможности Default ThumbnailКакой дифавтомат поставить? Default ThumbnailРекани анжело люстры