-
ул. Малая Семёновская, д. 11А, с.6
-
+7 499 840 50 60
-
info@machunit.com
Как правило, микроконтроллеры (МК) не имеют операционной системы. Раньше большинство встраиваемых систем работало на микроконтроллерах, которые постоянно выполняли одну и ту же программу, не требуя человеческого вмешательства. Несмотря на это, граница между микроконтроллерами и процессорами достаточно размыта. МК имеют линии портов ввода/ вывода общего назначения (GPIO), часто подключающиеся к одному или нескольким датчикам и устройствам, которые активируются в соответствии с написанной пользователем программой для микроконтроллера.
Поскольку стоимость вычислительных операций резко снизилась, а производительность их, наоборот, выросла, многие встраиваемые устройства стали оснащаться высокопроизводительными процессорами с разнообразной периферией и функционалом. Чем больше задач и вычислений задействовано, тем в большей степени нужна операционная система для упрощения организации и общей координации работы встраиваемого устройства.
Основная задача ОС заключается в распределении ресурсов системы между приложениями, зависящими от этих ресурсов. Операционные системы содержат некоторые важные элементы, такие как планировщик процессов, задачи, управление памятью, и, собственно, систему: интерфейс, многозадачность файловых систем и синхронизацию, обработку прерываний, таймеры и часы, коммуникации между задачами, ввод-вывод и управление памятью.
Рис. 1. Пример встроенной системы реального времени
Операционная система реального времени (RTOS) – ОС для устройств и систем, которым необходима быстрая реакция на внешние изменения (рис. 1). К примеру, в случае отказоустойчивого программного обеспечения RTOS должна не допускать выполнения процесса с более низким приоритетом при запуске задачи с более высоким приоритетом. Например, LIDAR и процесс обработки видеоизображений, используемые автономными системами для безаварийной работы беспилотных автотранспортных средств, требуют значительных вычислительных мощностей. Любая сложная система с функцией обеспечения безопасности жизнедеятельности должна иметь RTOS, чтобы процессор смог быстро принимать решения. RTOS не надо использовать, когда в ней нет крайней необходимости, но без нее не обойтись, если в системе есть хотя бы один процесс, который следует прервать, чтобы была возможность реагировать на задачи с более высоким приоритетом. Традиционные МК не запускают одновременно несколько потоков и не имеют сложной системы прерываний. Когда-то благодаря таким МК встраиваемые системы широко распространились, поскольку их было достаточно для решения простых задач, а стоимость высокопроизводительных решений была велика.
Современные встраиваемые системы включают в себя решения на микроконтроллерах для простой обработки данных в одном цикле и высокопроизводительные и нагруженные процессорные системы, которые способны обеспечивать быстрое выполнение любых требуемых задач. Широко распространилось отказоустойчивое программное обеспечение: программируемый логический контроллер (ПЛК) оснащается таким ПО уже на этапе производства. В то же время аппаратные средства обеспечения отказоустойчивости по-прежнему применяются в ответственных процессах или системах, например, в аппаратах для лечения раковых заболеваний, в оборудовании АЭС и в системах жизнеобеспечения.
Когда необходимо использовать RTOS?
RTOS необходима, когда при наличии нескольких процессов и устройств время выполнения процессов важнее, чем средняя производительность. Иными словами, RTOS необходима, когда стоит задача запуска нескольких процессов в определенное время. Она гарантирует тайминг выполнения требуемых задач, имеет меньшую задержку, может точно определить, выполнена ли задача, и дает возможность выполнять как срочные, так и некритичные по времени задачи.
RTOS эффективно использует прерывания, основанные на приоритете в расписании. В отличие от ОС общего назначения, она обеспечит выполнение задач в срок, вне зависимости от складывающегося сценария.
Отличительная особенность RTOS - в том, что она должна быть многопоточной, работать на опережение и обеспечивать приоритетность потока. RTOS включает систему наследования по приоритету, предсказуемо поддерживает синхронизацию потоков и имеет механизм предотвращения инверсии приоритетов. Инверсия приоритетов – это ситуация, при которой менее значимая задача использует ресурсы более важной задачи, откладывая ее решение. Кроме того, одним из основных свойств RTOS является предсказуемость задержки при обработке прерывания.
Разработчики RTOS должны детально информировать пользователей об уровнях системных прерываний, системных вызовах и таймингах. Им необходимо знать максимальное время, в течение которого ОС и драйверы маскируют прерывания. Задержка прерывания, то есть время между его возникновением и запуском инициируемой прерыванием задачи, должна быть предсказуема и соответствовать требованиям приложения. В качестве примеров RTOS можно привести VxWorks, QNX, Win CE, pSOS, Nucleus® RTOS, FreeRTOS™, Zephyr™ Project.
На что обратить внимание при выборе RTOS:
- Какими возможностями в режиме реального времени обладает система? Заложено ли в ней применение мягкой или жесткой обработки прерывания, и какие имеются сервисы планирования?
- Поддерживает ли целевой процессор необходимую RTOS? Применялась ли она для таких задач ранее?
- Насколько велик объем, который RTOS занимает в памяти? Для устройств IoT требуется, чтобы система занимала небольшие объемы памяти, поэтому лучше использовать Zephyr или, возможно, FreeRTOS. То, как вы настроите RTOS, также повлияет на объем, который будет занимать система в памяти устройства, поскольку объем памяти зависит от служб, которые используются приложением.
- Каковы задержки обработки прерываний?
- Как долго происходит переключение контекстов? (Задержка переключения контекста – это время, необходимое для записи состояния процесса или потока и его последующего запуска с момента остановки. В такой ситуации несколько процессов смогут использовать один процессор).
- Какие интерфейсы требуются для решения задачи, и возможна ли их работа с выбранной RTOS?
- Возможны ли отладка и настройка RTOS с выбранным процессором, присутствуют ли необходимые для приложения драйверы?
- Какие средства разработки и отладки совместимы с RTOS?
- Какова стоимость RTOS, доступность исходных кодов? В случае открытого исходного кода следует уточнить совместимость лицензий и проверить стабильность работы ядра.
- Доступность и качество технической документации или форум поддержки разработчиков.
- Какова репутация поставщика RTOS?
- Может ли конкурирующая компания приобрести RTOS (а затем отказаться от ее поддержки)?
- Насколько гибок алгоритм планирования? Например, алгоритмы FIFO, циклический алгоритм (round Robin), монотонный, спорадический и так далее.
- Есть ли возможность удаленной диагностики?
- Какая RTOS необходима: жесткая или мягкая?
Системы жесткого и мягкого реального времени
Система жесткого реального времени гарантирует, что задачи будут выполнены в пределах установленного дедлайна – предельного времени завершения задачи. Такая система обычно требуется, когда возможна гибель людей, если сроки обработки (дедлайна) не соблюдаются. Пример жесткого реального времени - система останова АЭС или система управления полетом.
Мягкая система реального времени более щадящая; сроки важны, но только в средневзвешенном смысле. Примером мягкой системы реального времени является система сбора данных. Firm RTOS- нечто среднее между мягкой и жесткой. Эта система, в основном, работает как мягкая, но также может иметь несколько жестких дедлайнов.
Заметим, что жесткий и мягкий режимы реального времени не обязательно связаны с абсолютным значением времени.