На прошедшей конференции RTECC 2011 (Феникс, США) была выдвинута идея, что операционные системы реального (ОСРВ) вскоре будут невостребованными, поскольку их может заменить Linux.

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

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

В подобных случаях лучше использовать несимметричную модель, когда на каждом ядре запускается собственная ОС. Есть смешанные системы, когда несколько ядер работают симметрично, а на отдельных запущена ОСРВ или идет работа без ОС (т.н. «bare metal code» — «голое железо»).

Сейчас появилась еще одна альтернатива: использовать одну ОС Linux, а функционирование каждого ядра настраивать отдельно. Здесь возникают два варианта: Linux используется как ОСРВ, либо запускается Bare-Metal Engine MontaVista для поддержки «bare-metal» приложений.

С одной стороны, Linux может заменить полноценную ОСРВ. Однако он не может обеспечить работу в режиме жесткого реального времени. Например, его нельзя применять на станциях связи LTE, когда в течение определенного времени должно быть обработано заданное количество пакетов, иначе произойдет потеря звонков. Даже если удалось произвести тонкую настройку Linux, с каждым обновлением системы придется производить перенастройку.

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

Когда Linux будет доработана, она без труда сможет вытеснить другие ОСРВ.

Комментарии экспертов

Денис Михаевич, руководитель направления, AXONIM Devices

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

RTLinux — операционная система жёсткого реального времени:

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

KURT – расширение так называемого «мягкого» реального времени. Да, действительно иногда удобно в любой момент включить реалтайм и заморозить все задачи, а затем выключить и дать работать в нормальном режиме используя сервисы предоставляемые ОС(файловая система, драйвера интерфейсов и т.д.). Такая ситуация хороша только при работе с мультимедиа и при выполнении небольших кусков кода, что и подтверждают создатели сего расширения.

У остальных систем и расширений ситуация также не лучше.

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

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

Дмитрий Горох, инженер отдела исследований новых технологий компании Promwad

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

ОСРВ принято разделять на операционные системы жёсткого реального времени и операционные системы мягкого реального времени. Первые гарантируют детерминированное время отклика и обработки внешнего события (обычно — прерывание от периферии), произошедшего в недетерминированный момент времени. Вторые же позволяют лишь гарантировать, что пользовательская программа получит заданное количество процессорного времени за заданный промежуток реального времени (например, 10 мс процессорного времени в срок не позднее 100 мс).

Linux, как и многие другие ОС общего применения, относится к последнему типу ОСРВ. И даже перенос потока реального времени в ядро, и повышение приоритета до максимального полностью не решают проблему, так как планировщик потоков ядра Linux не поддерживает вытесняющую многозадачность в полной мере (несмотря на наличие многочисленных RT патчей, в том числе CONFIG_PREEMPT_RT). Существует давний способ всё-таки осуществить быструю и детерминированную обработку событий в Linux: реализовать планировщик RT потоков в виде микроядра специализированной ОСРВ. При этом ядро Linux запускается как RT поток на данной ОСРВ с минимальным приоритетом и отключённой возможностью блокировать прерывания (любые критические секции внутри ядра Linux не блокируют ОСРВ). По такому пути пошли проекты RTLinux, RTAI, Xenomai и другие. Данная архитектура не уступает по производительности, скорости реакции и детерминированности RT потоков обычным ОСРВ. Из недостатков следует отметить сложность реализации SMP и необходимость существенного изменения ядра Linux для возможности работы как Low Priority RT Task под управлением ОСРВ. К счастью, в ядре Linux уже существует весьма похожая технология, предназначенная для запуска Linux поверх гипервизора: KVM. При этом RT задачи запускаются на одном уровне с гипервизором (или даже поверх него) и не прерываются любой активностью от Linux ядра. Гипервизор содержит в себе легковесный настраиваемый планировщик потоков с поддержкой вытесняющей многозадачности и SMP на мультипроцессорных системах и маршрутизатор прерываний от аппаратуры. Данный подход хоть и обладает несколько бОльшими накладными расходами, тем не менее, позволяет добиться вполне приемлемых скорости реакции на прерывания и времени на переключение потоков. Подобную технологию совмещения Linux и ОСРВ использовали в фирме MontaVista в своём продукте Linux Carrier Grade Edition (Bare Metal Engine). И, хотя продукт проприетарный, ожидается появление свободных аналогов, поскольку все ключевые технологии присутствуют в открытом виде.

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

Думаю, что, по крайней мере, по этим причинам ОСРВ ещё долго будут оставаться востребованными.