Алексей Фролов

Алексей Фролов, руководитель группы программистов ООО «ВАИС-Техника».
В 2008 году окончил факультет аэромеханики и летательной техники МФТИ по специальности прикладные математика и физика. В 2006 году начал работать инженером-программистом ФГУП «Пилотажно-исследовательский центр», участвовал в разработке программного обеспечения индикации для интегрированной модульной авионики (ИМА), с 2013 года инженер-программист ООО «ВАИС-Техника». Занимается разработкой отечественной операционной системы реального времени, с 2015 года руководитель группы программистов по указанной тематике.

---

Использование многоядерности в операционных системах реального времени со статическим расписанием

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

---

• Скачать презентацию

---

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

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

Этот подход используется в ARINC 653 - стандарте программного интерфейса для прикладного ПО уровня пользователя, который регламентирует временное разделение и разделение по памяти для доступа к ресурсам платформы. В рамках ARINC 653 компоненты ПО отделенные друг от друга по времени и памяти называются разделами. Введено также понятие псевдораздела, который обладает всеми особенностями пользовательского раздела с точки зрения существования в отдельном адресном пространстве и выделенном времени, однако при этом может использовать функции не только интерфейса APEX, но и системные сервисы (например, для получения доступа и работы с регистрами устройств).

Система реального времени построенная на стандарте ARINC 653 предполагает роли системного интегратора и разработчика разделов ПО. Разработчик ПО должен получить ресурсы в то время и в том объеме, которые согласованы с системным интегратором, а системный интегратор, со своей стороны, имеет возможность контролировать распределение ресурсов. ARINC 653 декларирует полное отсутствие влияния одних разделов на другие если они не связаны никакими каналами, так как в одном модуле могут быть расположены компоненты ПО с разной критичностью и отказ одних компонентов не должен приводить к отказу не связанных компонентов ПО, и тем более к отказу всей системы.

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

В случае многоядерного процессора должна быть выбрана стратегия распределения временного ресурса процессора:

• Любой раздел может быть запущен только на единственном ядре процессора в любой точке системного расписания. В этом случае никакой раздел не может получить более 100% производительности одного ядра процессора. Однако, очевидно, появляется некоторое влияние между не связанными между собой разделами, которые исполняются одновременно на разных ядрах.
• Запуск любого раздела с использованием всех ядер. Таким образом никакие два раздела не работают одновременно на процессоре и не могут повлиять через кэш/память на временные характеристики исполнения. По сравнению с первым подходом это влечет перерасход ресурсов на задачи с низкой степенью параллельности, а также стандарт ARINC 653 не предполагает возможности одновременной работы процессов раздела, что требует использования дополнительных инструментов синхронизации (не нужных в этом месте по стандарту).
• Можно также использовать более гибкий подход и предоставить интегратору возможность запуска разделов на разных ядрах процессора а также возможность выделения разделу нескольких процессорных ядер.
• Если отклонения от стандарта в пользовательских ARINC 653 недопустимы, то можно использовать для конфигурации диспетчерского расписания только одно ядро для пользовательских разделов, а на остальных ядрах запускать псевдоразделы для работы с устройствами.

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

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