Система реального времени

Особенности ядра

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

Четкой границы между ядром (KERNEL) и операционной системой нет. Различают их, как правило, по набору функциональных возможностей. Ядра предоставляют пользователю такие базовые функции, как планирование синхронизация задач, межзадачная коммуникация, управление памятью и т. д. Операционные системы в дополнение к этому имеют файловую систему, сетевую поддержку, интерфейс с оператором и другие средства высокого уровня.

Важной частью любой ОСРВ является планировщик задач, чья функция — определить, какая из задач должна выполняться в системе в каждый конкретный момент времени. К основным методам планирования обычно относят: циклический алгоритм (в стиле round robin), разделение времени с равнодоступностью (time sharing with fairness), кооперативную многозадачность

Наиболее часто используемый в ОСРВ принцип планирования — приоритетная многозадачность с вытеснением. Основная идея состоит в том, что высокоприоритетная задача, как только для нее появляется работа, немедленно прерывает (вытесняет) низкоприоритетную. Однако диапазон систем реального времени весьма широк, начиная от полностью статических систем, где все задачи и их приоритеты заранее определены, до динамических систем, где набор выполняемых задач, их приоритеты и даже алгоритмы планирования могут меняться в процессе функционирования. Существуют, например, системы, где каждая отдельная задача может участвовать в любом из трех алгоритмов планирования или их комбинации (вытеснение, разделение времени, кооперативность). Кроме того, приоритеты тоже можно назначать по-разному. В общем случае алгоритмы планирования должны соответствовать критериям оптимальности функционирования системы. Однако, если для систем жесткого реального времени такой критерий очевиден , то для систем мягкого реального времени это может быть, например, минимальное максимальное запаздывание или средневзвешенная своевременность завершения операций. В зависимости от критериев оптимальности могут применяться алгоритмы планирования задач, отличные от рассмотренных. Например, может оказаться, что планировщик должен анализировать момент выдачи критичных по времени управляющих воздействий и запускать на выполнение ту задачу, которая отвечает за ближайшее из них (алгоритм earliest deadline first, EDF).

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

• Функции, выполняемые различными задачами, связаны друг с другом. Например, если одна задача подготавливает исходные данные для другой, то последняя не выполняется до тех пор, пока не получит от первой задачи соответствующего сообщения. Одна из вариаций в этом случае — это когда задача при определенных условиях порождает одну или несколько новых задач.
• Необходимо упорядочить доступ нескольких задач к разделяемому ресурсу.
• Необходима синхронизация задачи с внешними событиями. Как правило, для этого используется механизм прерываний.
• Необходима синхронизация задачи по времени. Диапазон различных вариантов в этом случае достаточно широк, от привязки момента выдачи какого-либо воздействия к точному астрономическому времени до простой задержки выполнения задачи на определенный интервал времени. Для решения этих вопросов в конечном счете используются специальные аппаратные средства, называемые таймером.

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

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

• Временное блокирование прерываний
• Двоичные семафоры
• Посылка сигналов.

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

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

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

ОСРВ-системы (рынок России)

• В Российской Федерации практически отсутствуют отечественные коммерчески доступные или свободно распространяемые операционные системы, предназначенные для применения в ответственных встраиваемых вычислительных системах.
• Имеющиеся решения, как правило, являются проприетарными продуктами компаний, применяющимися либо в рамках одного предприятия (ЭОС, RealMK‒32), либо в рамках одной архитектуры (ОС РВ Багет 2.0/3.0/4.0, функционирующие на процессорных модулях разработки НИИСИ РАН (семейство Комдив))
• Решения, изначально создаваемые для широкого применения, в основном, находятся в состоянии разработки в рамках ОКР или НИР (JetOS, МОСОП/Стрикс).

• Ввиду отсутствия доступных отечественных ОСРВ, до известных событий, в изделиях ВВСТ широко использовались импортные ОСРВ, а после введения санкций потребовалось искать пути по выходу из сложившейся ситуации.
• Яркий пример – СВД ЗОСРВ Нейтрино и «Нейтрино-Э» (ООО «СВД Встраиваемые системы»), являющиеся «клоном» ОСРВ «QNX Neutrino» канадской разработки.
• Отсутствует подтверждение того, что данные ОСРВ могут использоваться без ограничений и компания QSS не имеет права запретить их использование, в том числе по причине санкционной политики.
• Отечественный инструментарий для разработки прикладных программ для ОС «Нейтрино-Э» отсутствует. Разработка (за исключением компилятора, поставляемого АО «МЦСТ») и отладка ПО должны осуществляться с использованием комплекса QNX Momentics. Данный инструментарий является исключительной собственностью канадской компании QSS, поставляется в закрытом виде (без исходных кодов).
• Заявки ООО «СВД Встраиваемые системы» на включение ОСРВ «Нейтрино» в реестр отечественного ПО дважды были отклонены (приказы Министерства цифрового развития, связи и массовых коммуникаций №664 от 30.11.2018г. и №167 от 14.04.2019г.).

• ОСРВ БагрОС-4000
• ОСРВ МАКС — АстроСофт
• МЦСТ: Эльбрус, операционная система реального времени (ОСРВ Эльбрус) — МЦСТ
• СВД ЗОСРВ Нейтрино — SWD Software (СВД Встраиваемые системы)
• ПКК Миландр (ОСРВ МАКС)
• ОС РВ Багет — Федеральный научный центр Научно-исследовательский институт системных исследований РАН (ФНЦ НИИСИ РАН)

Сравнение основных ОСРВ

• Вопрос импортозамещения ключевого компонента ПО встраиваемых систем нельзя считать решенным.
• Большинство предприятий промышленности не имеют возможности разрабатывать ОСРВ, либо подобная разработка не является для них
• целесообразной.
• Требуется формирование линейки защищенных операционных систем, доступных для использования «сторонними» разработчиками и соответствующих действующим нормативным ограничениям и актуальным вызовам времени:
  • Сверхлегкая ОСРВ для микроконтроллеров и радиационно-стойких ЦП (класса FreeRTOS, ОКР «Миниатюра»)
  • Легковесная ОСРВ без защиты памяти (класса Багет 2.0)
  • Полнофункциональная ОСРВ с разделением ресурсов (класса Багет 3.0/4.0, БагрОС-4000)

Прикладные системы

Маршрутизаторы

• DogOS
• от Cisco
• IOS от Cisco
• Cisco PIX от Cisco
• freesco — бесплатная и свободная замена коммерческим роутерам (в частности, от Cisco), поддерживающая до 10 Ethernet/ARCnet/Token Ring/Arlan-сетевых карт и до 10 модемов.
• Huawei VRP от Huawei
• IOS XR от Cisco на основе QNX
• JUNOS от Juniper Networks
• LinkBuilder от 3Com
• MikroTik RouterOS от MikroTik
• RapidOS от Riverstone Networks
• ScreenOS от Juniper Networks
• SeOS от Ericsson
• SROS от Alcatel-Lucent
• ZyNOS от ZyXEL

Для микроконтроллеров, встраиваемые и ОС реального времени

• AMX OS KADAK
• Contiki (поддерживается Atmel AVR)
• eCos
• FreeRTOS
• Integrity
• ITRON
• LynxOS
• Montavista Linux
• Nucleus
• QNX
• OS-9 — от Microware
• OS-9000 — от Microware
• OSA — для микроконтроллеров PIC (Microchip) и AVR (Atmel)
• OSE от ENEA
• OSEK
• RDOS
• RTEMS — первоначальная разработка велась по заказу МО США, сейчас свободная (GPL-like лицензия).
• RTOS
• ThreadX
• TRON OS разработчик — Ken Sakamura
• uC/OS-II для микроконтроллеров
• uOS разработчик — Сергей Вакуленко
• scmRTOS — для микроконтроллеров
• μClinux
• VxWorks
• Snake OS
• Salvo — для микроконтроллеров

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

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

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

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

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

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

Авторские/внутренние, не-UNIX и другие

• A2 — ОС, созданная в рамках проекта «Oberon — операционная система и компилятор» (Оберон (операционная система))
• AROS (AROS Research Operating System), свободная портируемая (в том числе для процессорной линейки x86) операционная система, идейный потомок AmigaOS
• AtheOS
• Chrome OS
• CP/M (Control Program/Monitor)
  • CP/M-80 (CP/M для Intel 8080/8085 и Zilog Z80 от Digital Research))
  • CP/M-86 (CP/M для Intel 8088/86 от Digital Research)
  • MP/M-80 (многопрограммная версия CP/M-80 от Digital Research)
  • MP/M-86 (многопрограммная версия CP/M-86 от Digital Research)
  • МикроДОС (создана в СССР на основе CP/M 2.2)
• UCSD P-System (портативная среда программирования/операционная система/виртуальная машина, разработана студентами университетов Калифорнии в Сан-Диего; управляется профессором Ken Bowles, написана на языке Паскаль)
• FLEX9 — от TSC для Motorola 6809, наследница FLEX, работавшей на Motorola 6800.
• JavaOS — основным компонентом является Java VM.
• SSB-DOS — от TSC для Smoke Signal Broadcasting, разновидность FLEX.
• DESQView многозадачная надстройка над MS-DOS для запуска MS-DOS приложений в режиме вытесняющей многозадачности с API кооперативной многозадачности, 1985 год. Текстовый интерфейс. Последняя версия 2.70.
• DV/X — развитие DESQView, заимствовавшее интерфейс и протокол X Window System.
• GEOS
• NewOS open source
• Оберон (операционная система), разработана ETH-Zurich (Никлаусом Виртом и другими) для рабочих станций Ceres и Chameleon. См. также Оберон (язык программирования).
• osFree — open-source-вариант OS/2.
• TripOS, 1978
• VisiOn (первый графический пользовательский интерфейс для PC, коммерческого успеха не имел.)
• VME от International Computers Limited (ICL)
• MorphOS (на микроядре Quark, с поддержкой API AmigaOS 3.1)
• NetWare (от Novell)
• Pick (лицензирована и переименована)
• Primos от Prime Computer (иногда пишется PR1MOS или PR1ME)
• OSD/XC от Fujitsu-Siemens (BS2000 портирована для эмуляции на Sun платформы SPARC)
• OS-IV от Fujitsu (базируется на ранней MVS от IBM)
• MSP от Fujitsu (наследник OS-IV)
• Haiku — свободный клон BeOS
• SkyOS — коммерческая ОС для PC.
• Syllable (развивается на базе AtheOS)
• TinyOS
• TSX-32 многозадачная 32-битная операционная система для DOS-приложений, частично заимствовавшая идеи OS/2, DESQView и операционных систем фирмы DEC. ~1993 год. Отличалась самой быстрой реализацией файловой системы FAT16 из известных.
• eyeOS

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

Достоинства и недостатки RTEMS

Достоинства

В качестве достоинств RTEMS необходимо отметить следующие.

• Это операционная система жесткого реального времени, надежность которой подтверждается опытом длительного использования в аппаратуре специального назначения (ракетных системах и других ответственных сферах применения).
• Данная ОСРВ является бесплатной и поставляется в исходных кодах.
• ОСРВ RTEMS позволяет легко применять разработанные приложения на разных платформах. Имеется большое количество BSP и поддерживаемых процессорных ядер, поставляемых в комплекте. Используя этот опыт, разработчик может создавать собственные BSP и портировать ОС на другие процессоре ядра, не поддерживаемые RTEMS.
• RTEMS это мультипроцессорная ОС, на базе которой можно создавать разветвленные системы контроля и управления, устойчивые к различного рода воздействиям.
• Модульная структура ядра RTEMS позволяет в широких пределах варьировать размер и возможности этой ОСРВ в зависимости от конкретной области применения.
• Поддержка стандартного стека сетевых протоколов TCP/IP обеспечивает возможность широкого применения RTEMS в сетевых приложениях.
• Соответствие международным стандартам, поддержка стандартных методов синхронизации между задачами, наличие пользовательского API и свободно распространяемых средств разработки и отладки, реализованных на базе проекта GNU, позволяют пользователю создавать на базе RTEMS эффективные системы управления с минимальными затратами.
• Малое время загрузки/реанимации приложения в случае аварии/отключения питания (менее 1c) обеспечивает быстрое восстановление работоспособности систем, использующих RTEMS.

Недостатки

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

• RTEMS не поддерживает динамическую загрузку приложений и модулей, поэтому сферой её применения являются встроенные системы, в которых не предполагается частая модификация программного обеспечения. ОСРВ RTEMS обеспечивает достаточно слабую поддержку файловых систем, что ограничивает область ее возможного применения в сфере систем централизованного сбора и хранения данных стандартными высокоуровневыми средствами. На настоящий момент RTEMS поддерживает только файловые системы IMFS и TFTP, что явно недостаточно. Поэтому для создания на базе RTEMS файл-серверов требуется разработка специального протокола. Понимая эту проблему, разработчики RTEMS ведут активную работу по реализации систем поддержки широко используемых файловых систем (в первую очередь сетевых).
• В RTEMS фактически отсутствуют резиденты средства отладки. Имеются только стандартные функции rtems_panic и printf, которые позволяют выводить отладочную информацию на терминал в процессе работы системы. Следует, однако, отметить, что наличие мощных средств кросс-разработки делает этот недостаток не очень существенным.

Ключевые особенности ЗОСРВ «Нейтрино» КПДА.10964-01

Архитектура на основе микроядра

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

Предсказуемость и производительность жесткого реального времени

• Вытесняющий планировщик с выбором дисциплины диспетчеризации
• Распределенное наследование приоритетов
• Защита от инверсии приоритетов

Технология адаптивного квотирования ресурсов

• Гарантированное выделение системных ресурсов для создания отказоустойчивых систем
• Упрощение системной интеграции и диагностики

Поддержка мультипроцессорности

• Комплексная поддержка многоядерных процессоров
• Выбор между динамическим назначением процессора для выполнения потоков и привязкой потоков к конкретным процессорам/процессорным ядрам

Расширенная графика

• Многослойная и многомониторная графика
• Поддержка OpenGL и OpenVG
• Сетевая оконная система
• Расширяемая поддержка мультимедиа
• Технологии Qt, GTK, Photon

Монитор Ключевых Процессов

• Отслеживание работоспособности для ранней диагностики отказов
• Интеллектуальное восстановление сбойных компонентов
• Механизм автоматического восстановления логических соединений
• Механизм контрольных точек для восстановления контекста приложения

Файловые системы

• ОЗУ-резидентные
• Программируемые и непрограммируемые ПЗУ
• Дисковые PowerSafe, QNX4, HFS/HFS+, Ext2, NTFS, FAT, UDF, ISO9660
• Сетевые (NFS, CIFS)

Сетевые технологии

• Полноценный стек NetBSD (IPv4, IPSec, IPv6, межсетевой экран PF)
• Berkeley Socket API, системный интерфейс
• Berkeley для переноса сетевых драйверов и фильтров
• Прозрачно-распределенная сеть Qnet

Диагностическая версия микроядра

• Анализ производительности и оптимизация всей системы в целом
• Быстрое выявление ошибок синхронизации и скрытых дефектов

Широкие возможности управления аппаратурой

• Выбор аппаратной архитектуры целевых систем (ARM, MIPS, PowerPC, x86, Эльбрус, КОМДИВ, Мультикор)
• Технология быстрой активации устройств
• Технология быстрого старта
• Поддержка управления питанием

Высокая эффективность разработки

• Интерфейс прикладного программирования IEEE POSIX
• Профессиональные инструменты разработки, отладки и анализа
• Инструментальная поддержка верификации
• Визуальный построитель графических ЧМИ
• Интеграция с популярными системами управления исходными текстами (SVN, GIT и др.)
• Прозрачные распределенные вычисления
• Прозрачный доступ к удаленным ресурсам
• Простота реализации отказоустойчивых кластеров

Дополнительные продукты для ЗОСРВ «Нейтрино»

• Комплект разработчика для ЗОСРВ «Нейтрино»
• Комплект разработчика для ЗОСРВ «Нейтрино-Э»

Документация

• Руководство администратора
• Регламент технического сопровождения

Свободные

Unix-подобные

• BSD (Berkeley Software Distribution, реализация Unix для DEC VAX) и её вариации: 386BSD, DesktopBSD, DragonFly BSD, FreeBSD, MidnightBSD, NetBSD, OpenBSD, PC-BSD, TrianceOS, TrueBSD,
• GNU/Hurd (ОС, реализованная как набор серверов, работающих на микроядре Mach): Hurd/L4 (ОС, реализованная как набор серверов, работающих на микроядре L4)
• Linux: Linux (наиболее популярное свободное Unix-подобное ядро), Cosmoe (основана на ядре Linux и использует много кода AtheOS, подобна BeOS), Объединённое ядро Linux, Ubuntu, Debian.
• OpenSolaris (проект по открытию кодов Solaris): AuroraUX, BeleniX, Jaris, MilaX, marTux, Nexenta OS, NexentaStor, OpenIndiana, OpenSolaris for System z, OSUNIX, Polaris, SchilliX, StormOS.
• Plan 9 (распределённая ОС, разработана Bell Labs): Plan B (распределённая ОС, произошедшая от Plan 9), Off++ (распределённая ОС, произошедшая от Plan 9), Inferno (ОС на основе виртуальной машины, произошла от Plan 9)
• SSS-PC (разработана в Токийском Университете)
• Minix (учебная ОС от Эндрю Таненбаума)
• Android (Мобильная ОС от , имеет большое количество форков; Список десктопных форков): Android-x86 (Неофициальный порт Android под платформу x86), Remix OS (ОС для персональных компьютеров и ноутбуков на базе Android) , Phoenix OS (Форк Remix OS), PrimeOS (Другой форк Remix OS) — полный список можно увидеть .

не-Unix-подобные

• ReactOS — это современная, свободная и открытая операционная система, основанная на лучших[источник не указан 90 дней] принципах архитектуры Windows NT (такие продукты компании Microsoft, как Windows XP, Windows 7, Windows Server 2012 построены на архитектуре Windows NT). Система была разработана с нуля, и таким образом не основана на Linux и не имеет ничего общего с архитектурой UNIX.
• FreeDOS
• Haiku

Применение систем реального времени

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

Примеры

Примеры систем, работающих в режиме реального времени:

• АСУ ТП химического реактора;
• бортовая система управления космического аппарата;
• АСНИ в области ядерной физики;
• система обработки аудио- и видеопотоков при трансляции в прямом эфире;
• интерактивная компьютерная игра.

Архитектура

Cтруктура ОСРВ эволюционировала от монолитной к многослойной структуре ОС и далее к архитектуре клиент-сервер:

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

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

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

Литература

• Jean J. Labrosse, et al. Chapter 8. DSP in Embedded Systems // Embedded Software. — Newnes, 2007. — 792 p. — ISBN 978-0-7506-8583-2.
• Jack Ganssle and Michael Barr. Embedded systems dictionary. — CMP Books, 2003. — 293 p. — ISBN 1-57820-120-92.
• Dimosthenis Kyriazis, Theodora Varvarigou, Kleopatra Konstanteli. Achieving Real-Time in Distributed Computing. — IGI Global, 2011. — 452 p. — ISBN 978-1-60960-827-9.
• Rajib Mall. Real-Time Systems: Theory and Practice. — IGI Global, 2006. — 242 p. — ISBN 9788131700693.
• Phillip A. Laplante, Seppo J. Ovaska. Real-Time Systems Design and Analysis: Tools for the Practitioner. — John Wiley & Sons, 2011. — 560 p. — ISBN 978-0-470-76864-8.
• Стивен Баррет, Даниэль Пак. Встраиваемые системы. Проектирование приложений на микроконтроллерах семейства 68НС12 / НСS12 с применением языка С. — ДМК-Пресс, 2014. — 640 p. — ISBN 978-5-457-38723-2.

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

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

Основная статья: Диспетчер операционной системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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