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

Взаимодействие между задачами и разделение ресурсов

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

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

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

Планировщики Nucleus SE

Как указано выше, Nucleus SE предлагает на выбор один из четырех типов планировщиков. Как и большинство аспектов конфигурации Nucleus SE, этот выбор определяется записью в nuse_config.h, параметр NUSE_SCHEDULER_TYPE должен быть установлен соответствующим образом, как показано в этом фрагменте из конфигурационного файла:

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

Планировщик Run to Completion

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

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

Код — это просто бесконечный цикл, который по очереди вызывает каждую задачу. Массив NUSE_Task_Start_Address[] содержит указатели на внешнюю функцию каждой задачи. Макрос PF0 — это простое преобразование void указателя в указатель на void функцию без параметров. Он предназначен для обеспечения удобочитаемости кода.
Условная компиляция используется для включения поддержки дополнительных функций: NUSE_SUSPEND_ENABLE определяет, могут ли задачи быть приостановлены; NUSE_SCHEDULE_COUNT_SUPPORT определяет, требуется ли значение счетчика каждый раз, когда запланирована задача. Более подробную информацию об этом можно найти в следующей статье.

Планировщик Round Robin

Если требуется чуть больше гибкости, чем предоставляется планировщиком RTC, подойдет планировщик RR. Он позволяет задаче передать управление или приостановиться, а затем продолжить с той же точки. Дополнительные накладные расходы, помимо сложности кода и непортируемости, заключаются в том, что для каждой задачи требуется собственный стек.
Код планировщика состоит из двух частей. Компонент запуска выглядит следующим образом:

Если включена поддержка начального состояния задачи (с помощью параметра NUSE_INITIAL_TASK_STATE_SUPPORT, см. «Параметры» в следующей статье), планирование начинается с первой готовой задачи; в противном случае используется задача с индексом 0. Контекст этой задачи затем загружается с помощью NUSE_Context_Load(). Дополнительные сведения о сохранении и восстановлении контекста см. в разделе «Сохранение контекста» в следующей статье.

Вторая часть планировщика — это компонент «перепланирования»:

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

Код выбирает для запуска задачу со следующим индексом и помещает значение в NUSE_Task_Next, принимая во внимание, включена ли приостановка задач или нет. Макрос NUSE_CONTEXT_SWAP() затем используется для вызова переключения контекста с использованием программного прерывания

Дополнительные сведения о сохранении и восстановлении контекста см. в разделе «Сохранение контекста» в следующей статье.

Планировщик Priority

Планировщик Priority в Nucleus SE, как и другие варианты, предназначен для обеспечения требуемой функциональности, будучи достаточно простым. В результате, каждая задача имеет уникальный приоритет, невозможно иметь несколько задач с одним уровнем приоритета. Приоритет определяется индексом задачи, где 0 — это уровень наивысшего приоритета. Индекс задачи определяется ее местом в массиве NUSE_Task_Start_Address[]. В следующей статье будет дана более подробная информация о настройке задач.

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

Нет условного кода, который мог бы отключить приостановку задач, так как эта возможность является обязательной для планировщика приоритетов; любая альтернатива была бы нелогичной. Функция NUSE_Reschedule() принимает параметр, который «подсказывает», какая задача может быть запланирована следующей — new_task. Это значение устанавливается, когда вызывается перепланирование, потому что активизируется другая задача. Индекс этой задачи передается как параметр. Затем планировщик может определить, следует ли выполнять переключение контекста, сравнивая значение new_task с индексом текущей задачи (NUSE_Task_Active). Если перепланирование является результатом приостановки задачи, параметр будет установлен в NUSE_NO_TASK, и планировщик будет искать задачу с самым высоким приоритетом.

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

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

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).

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

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

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

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

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

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

ОСРВ 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).
Отдельный с стек прерываний.
Анализ стека во время выполнения.
Оптимизированная обработка прерываний таймера.

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

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

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

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

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

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

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

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

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

Возможно, вам также будет интересно

«Театрально-техническая корпорация» (ТТК, Санкт-Петербург) является одним из лидеров на российском рынке оборудования для сценических комплексов, а также в сфере услуг по их проектированию, монтажу и обслуживанию. Компания оснастила более 3000 объектов культуры в стране и за рубежом. И уже более 10 лет ТТК использует решения компании Schneider Electric для управления сценическим оборудованием.

Компания «ФИОРД» (официальный дистрибьютор CompuLab в России) объявляет о начале приема заявок на поставку fit-PC3. fit-PC3 – ультракомпактный ПК на базе многоядерных «процессоров ускоренной обработки» APU AMD серии G продолжает традиции других устройств в линейке fit-PC «самых маленьких ПК в мире».

В начале апреля в немецком Штутгарте компания Emerson проводила свою Users Exchange Conference для региона EMEA.
О масштабе и репутации компании свидетельствует уже то, что это, по сути, «монобрендовое» мероприятие собрало около 1200 участников. Программа конференции включала промышленный форум, то есть доклады сотрудников подразделений Emerson из разных стран и заказчиков, делившихся своим оп…

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

Рис. 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 — политика не определена и зависит от системы; может вести себя по-разному в разных реализациях.

Принцип работы операционной системы реального времени

Существуют различные типы основных функций ОСРВ:

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

Планировщик на основе приоритетов

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

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

Готов к запуску (Ready to Run). Говорят, что готовность к запуску наступает тогда, когда у процесса есть все ресурсы для запуска, но он не должен находиться в рабочем состоянии.

Запущен (Running). Если задача выполняется, то говорят, что она запущена.

Заблокирован (Blocked). В этом состоянии, если у процесса недостаточно ресурсов для запуска, он переводится в заблокированное состояние.

Процедура прерывания системного тактирования

Для выполнения чувствительной ко времени операции ОСРВ предоставит определенное системное тактирование. Если, например, такт 1 мс, то вы должны выполнить задачу за 50 мс. Обычно за этим следует API, который говорит: «Через 50 мс разбудите меня». Следовательно, задача будет в спящем режиме, пока ОСРВ не проснется. Тем не менее, пробуждение не гарантирует, что оно будет работать точно в это время, это зависит от приоритета, и если в данный момент работает более высокий приоритет, то данная задача будет отложена.

Детерминированное поведение

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

Службы ОСРВ

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

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

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

Планирование

В типовых проектах задача имеет три состояния:

Выполняется (выполняется на ЦП);
Готов (готов к исполнению);
Заблокирован (ожидание события, например ввод-вывод).

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

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

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

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

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

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

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

Алгоритмы

Некоторые часто используемые алгоритмы планирования RTOS:

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

Настройка приложения 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[]

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

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

Поддержка подсистемы реального времени (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.