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

• 1 слайд

  ГБПОУ РМ СТЭиЭТ имени А.И.Полежаева
  
  Дисциплина:
  операционные системы.
  
  Операционные системы реального времени
  

• 2 слайд

  Содержание
  Введение…………………………………………………
  Операционные системы реального времени…………
  Типы ОСРВ………………………………………………
  Структура ОСРВ………………………………………..
  Процессы, потоки, задачи………………………………
  Память……………………………………………………
  Прерывания………………………………………………
  Часы и таймеры…………………………………………
  Краткие хар-ки распространённых ОСРВ
  VxWorks……………………………………………..
  QNX Neutrino RTOS…………………………………
  RTEMS……………………………………………….
  LynxOS………………………………………………
  Windows CE…………………………………………
  Заключение……………………………………………..
  Библиографический список……………………………
  
  

• 3 слайд

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

• 4 слайд

  Операционная система реального времени — это тип операционной системы. Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени. Операционные системы реального времени (ОСРВ) предназначены для обеспечения интерфейса к ресурсам критических по времени систем реального времени. Основной задачей в таких системах является своевременность выполнения обработки данных.
  Мартин Тиммерман (директор компании «Real-Time Consult и Real-Time User’s Support International (RTUSI)», обеспечивающей аппаратно-программную поддержку и занимающейся разработкой проектов систем реального времени) сформулировал следующие необходимые требования для ОСРВ:
  •операционная система должна быть многозадачной и допускающей вытеснение;
  •операционная система должна обладать понятием приоритета для потоков;
  •операционная система должна поддерживать предсказуемые механизмы синхронизации;
  •операционная система должна обеспечивать механизм наследования приоритетов;
  •поведение операционной системы должно быть известным и предсказуемым (задержки обработки прерываний, задержки переключения задач, задержки драйверов и т.д.).
  Это значит, что во всех сценариях рабочей нагрузки системы должно быть определено максимальное время отклика.
  
  
  
  Операционные системы реального времени
  

• 5 слайд

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

• 6 слайд

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

• 7 слайд

  Концепция многозадачности (псевдопараллелизм) является существенной для системы реального времени с одним процессором, приложения которой должны быть способны обрабатывать многочисленные внешние события, происходящие практически одновременно.
  
  Концепция процесса, пришедшая из мира UNIX, плохо реализуется в многозадачной системе, поскольку процесс имеет тяжелый контекст. Возникает понятие потока (thread), который понимается как подпроцесс, или легковесный процесс (light-weight process). Потоки существуют в одном контексте процесса, поэтому переключение между потоками происходит очень быстро, а вопросы безопасности не принимаются во внимание. Потоки являются легковесными, потому что их регистровый контекст меньше, т.е. их управляющие блоки намного компактнее. Уменьшаются накладные расходы, вызванные сохранением и восстановлением управляющих блоков прерываемых потоков. Объем управляющих блоков зависит от конфигурации памяти. Если потоки выполняются в разных адресных пространствах, система должна поддерживать отображение памяти для каждого набора потоков.
  
  Итак, в системах реального времени процесс распадается на задачи или потоки. В любом случае каждый процесс рассматривается как приложение. Между этими приложениями не должно быть слишком много взаимодействий, и в большинстве случаев они имеют различную природу – жесткого реального времени, мягкого реального времени, не реального времени.
  
  Процессы, потоки, задачи
  

• 8 слайд

  Как уже упоминалось выше, задержка на переключение контекста потока напрямую зависит от конфигурации памяти, т.е. от модели защиты памяти. В ОСРВ наиболее распространенны четыре модели защиты памяти:
  Модель без защиты – системное и пользовательское адресные пространства не защищены друг от друга, используется два сегмента памяти: для кода и для данных, при этом от системы не требуется никакого управления памятью, не требуется MMU (memory management unit – специальное аппаратное устройство для поддержки управления виртуальной памятью);
  Модель защиты система/пользователь – системное адресное пространство защищено от адресного пространства пользователя, системные и пользовательские процессы выполняются в общем виртуальном адресном пространстве, при этом требуется MMU.
  Модель защиты пользователь/пользователь – к модели система/пользователь добавляется защита между пользовательскими процессами, требуется MMU. Как и в предыдущей модели, используется механизм страничной защиты.
  Модель защиты виртуальной памяти – каждый процесс выполняется в своей собственной виртуальной памяти, требуется MMU. У каждого процесса имеются свои собственные сегменты и, следовательно, своя таблица описателей.
  Фундаментальное требование к памяти в системе реального времени заключается в том, что время доступа к ней должно быть ограничено (или, другими словами, предсказуемо).
  Память
  

• 9 слайд

  При описании управления прерываниями обычно различают две процедуры, а именно:
  программа обработки прерывания (ISR – interrupt servicing routine) – программа низкого уровня в ядре с ограниченными системными вызовами,
  поток обработки прерывания (IST – interrupt servicing thread) – поток уровня приложения, который управляет прерыванием, с доступом ко всем системным вызовам.
  Обычно ISR реализуются производителем аппаратуры, а драйверы устройств выполняют управление прерываниями с помощью IST. Потоки обработки прерываний действуют как любые другие потоки и используют ту же самую систему приоритетов. Это означает, что проектировщик системы может придать IST более низкий приоритет, чем приоритет потока приложения.
  
  Прерывания
  

• 10 слайд

   
  В ОСРВ используются различные службы времени. Операционная система отслеживает текущее время, в определенное время запускает задачи и потоки и приостанавливает их на определенные интервалы. В службах времени ОСРВ используются часы реального времени. Обычно используются высокоточные аппаратные часы. Для отсчета временных интервалов на основе часов реального времени создаются таймеры.
  Для каждого процесса и потока определяются часы процессорного времени. На базе этих часов создаются таймеры, которые измеряют перерасход времени процессом или потоком, позволяя динамически выявлять программные ошибки или ошибки вычисления максимально возможного времени выполнения.
  В высоконадежных, критичных ко времени системах важно выявление ситуаций, при которых задача превышает максимально возможное время своего выполнения, т.к. при этом работа системы может выйти за рамки допустимого времени отклика. Часы времени выполнения позволяют выявить возникновение перерасхода времени и активизировать соответствующие действия по обработке ошибок.
  Большинство ОСРВ оперируют относительным временем. Что-то происходит “до” и “после” некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм (ticker), т.к. там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа “ждать одну секунду”, то нужен тактовый генератор и/или таймер.
  Синхронизация в ОСРВ осуществляется с помощью механизма блокирования (или ожидания) до наступления некоторого события. Абсолютное время не используется.
  Реализации в ОСРВ других концептуальных абстракций подобны их реализациям в традиционных ОС.
  
  Часы и таймеры
  

• 11 слайд

  Операционные системы реального времени семейства VxWorks корпорации «WindRiver Systems» предназначены для разработки программного обеспечения (ПО) встраиваемых компьютеров, работающих в системах жесткого реального времени.
  Операционная система VxWorks имеет архитектуру клиент-сервер и построена в соответствии с технологией микроядра, т.е. на самом нижнем непрерываемом уровне ядра (WIND Microkernel) обрабатываются только планирование задач и управление их взаимодействием/синхронизацией. Вся остальная функциональность операционного ядра – управление памятью, вводом/выводом и пр. – обеспечивается на более высоком уровне и реализуется через процессы. Это обеспечивает быстродействие и детерминированность ядра, а также масштабируемость системы.
  VxWorks может быть скомпонована как для небольших встраиваемых систем с жесткими ограничениями для памяти, так и для сложных систем с развитой функциональностью.
  Хотя система VxWorks является конфигурируемой, т.е. отдельные модули можно загружать статически или динамически, нельзя сказать, что в ней используется подход, основанный на компонентах. Все модули построены над базовым ядром и спроектированы таким образом, что не могут использоваться в других средах.
  
  VxWorks
  

• 12 слайд

  Операционная система QNX Neutrino Real-time Operating System (RTOS) корпорации «QNX Software Systems» является микроядерной операционной системой, которая обеспечивает многозадачный режим с приоритетами.
  QNX Neutrino RTOS имеет клиент-серверную архитектуру. В среде QNX Neutrino каждый драйвер, приложение, протокол и файловая система выполняются вне ядра, в защищенном адресном пространстве. В случае сбоя любого компонента он может автоматически перезапуститься без влияния на другие компоненты или ядро. Хотя система QNX является конфигурируемой, т.е. отдельные модули можно загружать статически или динамически, нельзя сказать, что она использует подход, основанный на компонентах. Все модули полагаются на базовое ядро и спроектированы таким образом, что не могут использоваться в других средах.
  QNX Neutrino RTOS состоит из ядра, планировщика процессов (process manager) и расширенных сервисов на уровне пользователя. Как истинная микроядерная операционная система, QNX Neutrino RTOS реализует в ядре ОС только наиболее фундаментальные сервисы, такие как передача сообщений, сигналы, таймеры, планирование потоков, объекты синхронизации. Все другие сервисы ОС, драйверы и приложения выполняются как отдельные процессы, которые взаимодействуют через синхронную передачу сообщений.
  QNX Neutrino RTOS имеет малые времена обработки прерываний, быстрое переключение контекстов. Инверсия приоритетов преодолевается с помощью распределенного наследования приоритетов. Упрощенное моделирование активностей реального времени проводится через синхронную передачу сообщений. Вложенные прерывания и фиксированная верхняя граница времени обработки прерывания гарантируют, что высокоприоритетные прерывания обрабатываются быстро с предсказуемым временем.
  QNX Neutrino RTOS
  

• 13 слайд

  RTEMS (Real-Time Executive for Multiprocessor Systems) – это некоммерческая операционная система реального времени для глубоко встраиваемых систем.
  Разработчик системы компания «OAR» (On-Line Applications Research Corporation, США). Система была создана по заказу министерства обороны США для использования в системах управления ракетными комплексами. Система разрабатывается для многопроцессорных систем на основе открытого исходного кода в противовес аналогичным системам с закрытым кодом. Система рассчитана на платформы MS-Windows и Unix (GNU/Linux, FreeBSD, Solaris, MacOS X).
  Ядро RTEMS обеспечивает базовую функциональность систем реального времени. В эти возможности входят
  •мультизадачная обработка;
  •работа в гомогенных и гетерогенных системах;
  •планирование, управляемое событиями, на основе приоритетов;
  •планирование с монотонной скоростью;
  •взаимодействие задач и синхронизация;
  •приоритетное наследование;
  •управление ответным прерыванием;
  •распределение динамической памяти;
  •конфигурирование системы для уполномоченных пользователей;
  •переносимость на многие целевые платформы.
  Привязка ОСРВ к аппаратуре производится с помощью специальной библиотеки подпрограмм BSP (board support package) и специализированных подпрограмм для различных архитектур.
  RTEMS не поддерживает динамическую загрузку приложений и модулей, поэтому сферой ее применения являются встраиваемые системы, в которых не предполагается частая модификация программного обеспечения.
  ОСРВ RTEMS обеспечивает достаточно слабую поддержку файловых систем, что ограничивает область ее возможного применения в сфере систем централизованного сбора и хранения данных стандартными высокоуровневыми средствами.
  
  RTEMS
  

• 14 слайд

  Операционная система LynxOS RTOS (LynuxWorks, Inc.) является операционной системой жесткого реального времени, которая предназначена для специализированной и телекоммуникационной аппаратуры. Эта ОС является полностью детерминированной и обладает POSIX-, UNIX- и Linux-совместимостью. Областями применения ОС LynxOS являются также сложные системы безопасности.
  Последняя выпущенная версия этого бренда ОС LynxOS-178 2.0 характеризуется производителем как коммерческая операционная система, обеспечивающая высокий уровень надежности и оперативности, необходимый для встраиваемых приложений с особыми требованиями к безопасности. В LynxOS-178 2.0 реализована поддержка интерфейса APEX (Application/EXecutive – интерфейс приложения/управляющей программы) спецификации ARINC-653. Это означает, что данная операционная система отвечает самым строгим требованиям к безопасности и надежности электронных систем для военной и гражданской авиации. Система LynxOS-178 2.0 полностью соответствует положениям уровня А спецификации DO-178B.
  ОСРВ LynxOS-178 2.0 соответствует требованиям стандартов POSIX и ARINC-653, а также DO-178B, что означает гарантию переносимости прикладного кода встраиваемых систем, многократного использования созданных программ, а также соответствие самым строгим нормативам операционных систем с повышенными требованиями к безопасности. Использование LynxOS-178 2.0 позволяет применять любые ранее сертифицированные программы и разработки.
  
  LynxOS
  

• 15 слайд

  ОСРВ Windows CE является модульной с небольшим ядром и необязательными модулями, которые выполняются как независимые процессы. Планирование в Windows CE осуществляется на основе приоритетов. Поддерживается защита ядра и процессов друг от друга. Кроме того, возможен режим работы, когда отсутствует защита между процессами и ядром. Следует отметить, что прерывания обрабатываются как потоки и имеют уровни приоритетов потоков. Windows CE поддерживает также нити (fiber), являющиеся потоками, которыми ядро не управляет. Каждая нить выполняется в контексте потока, который ее создал; их можно использовать для создания планировщика внутри потока. Такие нити используются в экзотических или унаследованных приложениях, но они непригодны в системах реального времени.
  Windows CE имеет ограничение на физическую память – 512MB. Microsoft ввел это ограничение для того, чтобы Windows CE могла выполняться на большом диапазоне встраиваемых процессоров без проблем совместимости, поскольку некоторые из этих процессоров способны управлять физической памятью в 512MB. Windows CE реализует страничное управление виртуальной памятью. Размер страницы зависит от платформы, но, по возможности, используется размер в 4KB. Есть возможность запретить страничную организацию, что важно для систем реального времени. В этом режиме модуль перед выполнением целиком загружается в память. Тогда страничная подкачка (paging) не повлияет на выполнение приложения.
  В отличие от других ОСРВ Windows CE поддерживает обобщенные функции ожидания для различных типов объектов (мьютексов, семафоров, событий, процессов и потоков). Преимущество таких функций состоит в том, что можно ожидать многие объекты сразу, пока один из них не подаст сигнал. Критические секции можно использовать только внутри одного процесса. Вычислительные семафоры и мьютексы могут быть использованы как внутри одного процесса, так и между процессами. В Windows CE используется наследование приоритетов, чтобы избежать проблемы инверсии приоритетов.
  
   
  
  Windows CE
  

• 16 слайд

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

• 17 слайд

  1. Бурдонов И.Б., Косачёв А.С., Пономаренко В.Н. Операционные системы реального времени. Препринт: Института системного программирования РАН. Иркутск, 2006.
  2. Олифер В.Г., Олифер Н.А. Сетевые операционные системы: Учебник для вузов. 2-е изд.- СПБ.: Питер, 2008. – 669 с.: ил.
  3. www.ru.wikipedia.org
  4. www.intuit.ru
  
  Библиографический список