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

Операционные системы реального времени (ОСРВ)

Операционные системы реального времени ОСРВ ( Real Time Operating Systems — RTOS ) относятся к программным средствам и предназна­чены для обслуживания цифровых систем в тех случаях , когда:

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

● система способна выполнять несколько задач одновременно. Типичная муль­тизадачная операционная система выделяет каждой задаче (программе) оди­наковый интервал времени, создавая у пользователя впечатление, что все программы выполняются одновременно.

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

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

Принцип работы ОСРВ

При поступлении запроса производится проверка на входные данные для решения задачи. При их наличии задача начинает вы­полняться.

ЕСЛИ необходимые входные данные отсутствуют, то ОСРВ переходит к следующей задаче (при наличии запроса на ее выполнение). Для получения входных данных и запуска соответствующей задачи используются прерывания.

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

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

Системные ресурсы (дисковые накопители, таймеры, устройства ввода–выво­да и др.) обычно доступны только для определенных задач. Это позволяет орга­низовать очередь запросов к ресурсам таким образом, чтобы предотвратить од­новременный доступ к одному ресурсу нескольким задачам.

Требования к ОСРВ

Современные ОС PB должны удовлетворять следующим требованиям:

● малое время отклика (получение результата);

● реализация многозадачного режима с гибким механизмом приоритетов;

● малый объем памяти (достаточный для размещения в резидентной памяти прикладной системы);

● наличие сервисных функций и средств поддержки для разработки приклад­ных программ и ряд других.

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

Типы ОСРВ

Можно выделить два типа ОСРВ:

● системы жесткого реального времени, которые занимают небольшой объем памяти и имеют минимальные время отклика, но обладают весьма ограничен­ными сервисными средствами.

Они реализуются по модульному принципу, что позволяет использовать только те средства, которые необходимы в дан­ном приложении.

В результате для конкретного применения достигается существенное сокращение объема необходимой памяти и времени отклика;

● системы мягкого реального времени, которые требуют большего объема па­мяти, имеют более длительное время отклика, но зато удовлетворяют широ­кому спектру требований пользователя по режиму обслуживания задач, уров­ню предоставляемого сервиса. Средства интерфейса систем мягкого реаль­ного времени позволяют использовать высокоэффективные отладчики или интегрированные среды разработки.

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

Этот вид систем рассмотрим на при­мере системы OS–9 фирмы Microwave Systems . В качестве инструментально­го компьютера OS –9 использует IBM – PC , работающие в среде Windows , или рабо­чие станции Sun, HP, IBM RS /6000 с операционными системами типа UNIX . Характерные особенности OS –9:

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

● гибкость структуры, обеспечивающая реконфигурацию системы и расширение ее функциональных возможностей. Функциональные компоненты OS–9:

● ядро реального времени ( OS –9 kernel );

● общие средства ввода/вывода ( I / O man );

● файловые менеджеры;

● средства разработки программ.

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

Рассмотрим Перечисленные выше функциональные компоненты.

Ядро реального времени

Система содержит два вида ядер:

● ядро Atomic , реализующее минимальное количество сервисных функций (ди­станционную загрузку, связь с локальной сетью, управление ведомыми микро­контроллерами). Ядро применяется в системах, встраиваемых в различную аппаратуру, имеет малый объем (24 Кбайт) и обеспечивает минимальное вре­мя отклика (3 мкс при тактовой частоте 25 МГц);

● ядро Standard , обеспечивающее выполнение широкого набора функций сер­виса и разработки прикладных программ, для реализации которых требуется больший объем памяти (до 512К байт ПЗУ и 38К байт ОЗУ).

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

Система OS –9 предоставляет пользователю возможность выбора ядра в зави­симости от функционального назначения системы. Общие средства ввода/вывода.

Физический интерфейс OS –9 с разно­образными внешними устройствами обеспечивается большим набором драйве­ров, созданных как фирмой Microwave Systems , так и многочисленными разработ­чиками аппаратуры, использующей эту операционную систему для конкретных приложений. Файловые менеджеры.

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

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

● сетевые и коммуникационные менеджеры, обеспечивающие работу OS –9 с различными сетями и обмен данными по каналам связи с наиболее распро­страненными стандартами протоколов обмена;

● менеджеры графического интерфейса и работы с мультимедиа–приложениями. Средства разработки программ.

В составе OS –9 имеется пакет про­грамм (BSP) для поддержки плат развития, который обеспечивает совместную работу OS–9 с целым рядом SBC (Single Board Computer — одноплатный компью­тер).

Совместное использование BSP и OS–9 позволяет сконфигурировать целе­вую систему для конкретного приложения.

Система OS–9 содержит средства поддержки программирования: компилято­ры Ultra C/C++, текстовый редактор ЕМ ACS , три вида (в том числе символьных) отладчиков, набор утилит для организации контроля и сборки программных продуктов.

Помимо этого имеется большой набор (совместимых с OS –9) средств поддержки программирования, которые разработаны другими фирмами. Интегрированная среда разработки FasTra к.

Среда FasTrak постав­ляется совместно с OS–9 и предоставляет пользователю наиболее полный комп­лект средств программирования и отладки. Часть программных средств FasTrak инсталлируется на инструментальном компьютере, а часть — на целевой системе пользователя.

Среда FasTrak интегрирует все средства, необходимые для под­держки проектирования/отладки целевых систем. Версия среды FasTrak для ра­боты на инструментальном компьютере IBM – PC содержит:

● текстовый редактор, располагающий средствами перекодировки клавиатуры, что позволяет вести редактирование в удобном для пользователя формате;

● компиляторы Ultra C/C++;

● отладчики, обеспечивающие два режима отладки: пользовательский — для создания прикладных программ, и системный — для обслуживания прерыва­ний, системных вызовов и обращения к ядру реального времени;

● средства интерфейса с логическими анализаторами фирмы.

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

Фирма Microware Systems поставляет ряд системных пакетов, ориентирован­ных на различные сферы приложения:

● Wireless OS –9 — для разработки устройств беспроводной связи: сотовых те­лефонов, пейджеров, портативных цифровых ассистентов ( PDA );

● Internet OS –9 — для разработки устройств с доступом к сети Internet ;

● Digital Audio / Video Interactive Decoder ( DAVID ) OS –9 — для разработки распре­деленных систем цифрового интерактивного телевидения.

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

Особенности этого вида систем рассмотрим на примере системы VxWorks фирмы WindRiver Systems , предназна­ченной для работы с семействами микропроцессоров многих производителей.

Система VxWorks инсталлируется на отлаживаемой целевой системе и работает совместно с интегрированной средой разработки Tornado , функционирующей на инструментальном компьютере. В качестве инструментального компьютера исполь­зуются IBM – PC , работающие в среде Windows , или рабочие станции SUN, HP и др.

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

Все остальные функции — управление памятью, вводом/выводом, сетевым обменом и другие, реализуются дополнительными модулями. Для поддержки графических приложе­ний VxWorks располагает графическим интерфейсом VX–Windows.

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

В состав VxWorks входят также различные средства поддержки разнообраз­ных сетевых протоколов.

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

Анализатор WindView работает аналогично логическому анализатору, отображая на экране временные диаграммы переключения задач, записи в очередь сообщений и другие процессы. Монитор данных Stethoscope позволяет анализировать динамическое изменение пользовательских и систем­ных переменных, включая в себя также профилировщик процедур. В составе VxWorks имеется:

● пакет программ для поддержки плат развития;

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

Для комплексной отладки целевых систем VxWorks обеспечивает интерфейс со схемными эмуляторами и эмуляторами ПЗУ. Интегрированная среда разработки Tornado . В состав Tornado вхо­дит система VxWorks 5.

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

Открытая архитектура среды Tomado позволяет пользовате­лю подключать собственные специализированные инструментальные средства и расширять возможности стандартных средств.

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

Источник: http://pue8.ru/protsessory/699-operatsionnye-sistemy-realnogo-vremeni-osrv.html

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

Отличительные черты ОСРВ от ОС общего назначения

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

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

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

Если ОС общего назначения обычно воспринимается пользователями (не разработчиками) как уже готовый набор приложений, то операционная система реального времени служит только инструментом для создания конкретного аппаратно-программного комплекса реального времени.

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

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

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

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

Системы жёсткого и мягкого реального времени

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

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

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

Примеры систем жесткого реального времени – бортовые системы управления, системы аварийной защиты, регистраторы аварийных событий.  

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

Если система не успела обработать очередной принятый пакет, это приведет к таймауту на передающей стороне и повторной посылке (в зависимости от протокола, конечно). Данные при этом не теряются, но производительность сети снижается.

Основное отличие между системами жесткого и мягкого реального времени можно выразить так: система жесткого реального времени никогда не опоздает с реакцией на событие, система мягкого реального времени – не должна опаздывать с реакцией на событие

Ядро операционной системы

Ядро́ — центральная часть операционной системы (ОС), обеспечивающая приложениям координированный доступ к ресурсам компьютера,  память, внешнее аппаратное обеспечение, внешнее устройство ввода и вывода информации, переводя команды языка приложений на язык двоичных кодов, которые понимает компьютер.

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

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

Монолитное ядро

Монолитное ядро предоставляет богатый набор абстракций оборудования. Все части монолитного ядра работают в одном адресном пространстве.

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

Монолитное ядро — старейший способ организации операционных систем. Примером систем с монолитным ядром является большинство UNIX-систем.

Достоинства: Скорость работы, упрощённая разработка модулей.

Недостатки: Поскольку всё ядро работает в одном адресном пространстве, сбой в одном из компонентов может нарушить работоспособность всей системы.

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

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

Все процедуры работают в привилегированном режиме.

Микроядро

Микроядро предоставляет только элементарные функции управления процессами и минимальный набор абстракций для работы с оборудованием. Большая часть работы осуществляется с помощью специальных пользовательских процессов, называемых сервисами. Решающим критерием «микроядерности» является размещение всех или почти всех драйверов и модулей в сервисных процессах.

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

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

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

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

Недостатки: Передача данных между процессами требует накладных расходов.

Среда исполнения

Требования, предъявляемые к среде исполнения систем реального времени, следующие:

  • небольшая память системы – для возможности ее встраивания;
  •  система должна быть полностью резидентна в памяти, чтобы избежать замещения страниц памяти или подкачки;
  •  система должна быть многозадачной – для обеспечения максимально эффективного использования всех ресурсов системы;
  •  ядро с приоритетом на обслуживание прерывания. Приоритет на прерывание означает, что готовый к запуску процесс, обладающий некоторым приоритетом, обязательно имеет преимущество в очереди по отношению к процессу с более низким приоритетом, быстро заменяет последний и поступает на выполнение. Ядро заканчивает любую сервисную работу, как только поступает задача с высшим приоритетом. Это гарантирует предсказуемость системы;
  •  диспетчер с приоритетом – дает возможность разработчику прикладной программы присвоить каждому загрузочному модулю приоритет, неподвластный системе. Присвоение приоритетов используется для определения очередности запуска программ, готовых к исполнению. Альтернативным такому типу диспетчеризации является диспетчеризация типа “карусель”, при которой каждой готовой к продолжению программе дается равный шанс запуска. При использовании этого метода нет контроля за тем, какая программа и когда будет выполняться. В среде реального времени это недопустимо. Диспетчеризация, в основу которой положен принцип присвоения приоритета, и наличие ядра с приоритетом на прерывание позволяют разработчику прикладной программы полностью контролировать систему. Если наступает событие с высшим приоритетом, система прекращает обработку задачи с низшим приоритетом и отвечает на вновь поступивший запрос.

  Сочетание описанных выше свойств создает мощную и эффективную среду исполнения в реальном времени.

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

Ядро управляет аппаратными средствами целевого компьютера: центральным процессором, памятью и устройствами ввода/вывода; контролирует работу всех других систем и программных средств прикладного характера. В системе реального времени диспетчер занимает место между аппаратными средствами целевого компьютера и прикладным программным обеспечением.

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

Ядро может обеспечивать сервис различных типов:

  • Межзадачный обмен. Часто необходимо обеспечить передачу данных между программами внутри одной и той же системы Кроме того, во многих приложениях возникает необходимость взаимодействия с другими системами через сеть. Внутренняя связь может быть осуществлена через систему передачи сообщений. Внешнюю связь можно организовать либо через датаграмму (наилучший способ доставки), либо по линиям связи (гарантированная доставка). Выбор того или иного способа зависит от протокола связи.
  • Разделение данных. В прикладных программах, работающих в реальном времени, наиболее длительным является сбор данных. Данные часто необходимы для работы других программ или нужны системе для выполнения каких-либо своих функций. Во многих системах предусмотрен доступ к общим разделам памяти. Широко распространена организация очереди данных. Применяется много типов очередей, каждый из которых обладает собственными достоинствами.
  • Обработка запросов внешних устройств. Каждая прикладная программа в реальном времени связана с внешним устройством определенного типа. Ядро должно обеспечивать службы ввода/вывода, позволяющие прикладным программам осуществлять чтение с этих устройств и запись на них. Для приложений реального времени обычным является наличие специфического для данного приложения внешнего устройства. Ядро должно предоставлять сервис, облегчающий работу с драйверами устройств. Например, давать возможность записи на языках высокого уровня – таких, как Си или Паскаль.
  • Обработка особых ситуаций. Особая ситуация представляет собой событие, возникающее во время выполнения программы. Она может быть синхронной, если ее возникновение предсказуемо, как, например, деление на нуль. А может быть и асинхронной, если возникает непредсказуемо, как, например, падение напряжения. Предоставление возможности обрабатывать события такого типа позволяет прикладным программам реального времени быстро и предсказуемо отвечать на внутренние и внешние события. Существуют два метода обработки особых ситуаций – использование значений состояния для обнаружения ошибочных условий и использование обработчика особых ситуаций для прерывания ошибочных условий и их корректировки.

 Обзор архитектур ОСРВ 

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

Основным преимуществом монолитной архитектуры является ее относительная быстрота работы по сравнению с другими архитектурами. 

Недостатки монолитной архитектуры. 

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

2. Ядро не может быть прервано пользовательской задачей. Это может приводить к тому, что высокоприоритетная задача может не получить управления из-за работы низкоприоритетной.  

3. Негибкость и сложность развития: изменение части ядра системы требует его полной перекомпиляции.

Рисунок 1. Архитектура монолитной ОС

В задачах автоматизации широкое распространение в качестве ОСРВ получили уровневые ОС (рисунок 2).Примером такой ОС является хорошо известная система MS-DOS.

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

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

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

  Рисунок 2. Архитектура уровневой ОС

Одной из наиболее эффективных архитектур для построения операционных систем реального времени считается архитектура клиент – сервер. Общая схема ОС работающей по этой технологии представлена на рисунке 3.

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

Такая архитектура дает массу плюсов с точки зрения требований к ОСРВ и встраиваемым системам. Среди этих преимуществ можно отметить:

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

2. Такая система лучше масштабируется, поскольку ненужные сервисы могут быть исключены из системы без ущерба к ее работоспособности.

3. Повышается отказоустойчивость системы, т.к. «зависший» сервис может быть перезапущен без

перезагрузки системы.

              Рисунок 3. Построение ОС с использованием архитектуры клиент-сервер

К сожалению на сегодняшний день не так много ОС реализуется по принципу клиент-сервер. Среди известных ОСРВ реализующих архитектуру микроядра можно отметить OS9 и QNX. 

Список использованной литературы:

1) http://ru.wikipedia.org/wiki/Операционная_система_реального_времени

2) http://www.asutp.ru/?p=600591

3) http://www.mka.ru/?p=40774

4) http://www.4stud.info/rtos/lecture1.html

5)http://www.ozon.ru/context/detail/id/3092042/

Источник: http://omoled.ru/publications/view/20

Нужна ли вам операционная система реального времени?

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

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

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

В большинстве случаев, добавление задачи с более низким приоритетом не влияет на скорость реакции системы по отношению к высокоприоритетным задачам.

   В настоящее время ARM- и Cortex- базируемые микроконтроллеры доступны примерно по той же цене, что и 8-, или 16-битные микроконтроллеры.

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

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

Выбор осрв

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

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

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

Высокоприоритетные / низкоприоритетные

    Основная проблема в системах реального времени – это время, требуемое для отклика на  прерывание и запуска пользовательского кода (задачи), чтобы обработать прерывание.

Системы, не использующие ОСРВ, известны как высокоприоритетные/низкоприоритетные (foreground/background) и работают, как показано на рис.1.

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

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

рисунок 1

МНОГОЗАДАЧНОСТЬ

   Многозадачность (multitasking) – это процесс планирования и переключения процессора между несколькими задачами, делящими между собой процессор.

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

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

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

Эту процедуру выполняет так называемый  переключатель контекста или переключатель задач. Текущая вершина стека для каждой задачи наряду с другой информацией хранится в структуре данных, называемой блоком управления задачей (Task Control Block), который управляется ОСРВ.

ПЛАНИРОВАНИЕ

    Порядок, в котором выполняются задачи, определяется планировщиком (scheduler) или диспетчером (dispatcher). Существует два типа планировщиков: кооперативный (non pre-emptive) и вытесняющий (pre-emptive).

   В кооперативном планировщике задачи взаимодействуют (кооперируются) друг с другом чтобы получить контроль над процессором: когда задача освобождает процессор, ядро выполняет код следующей, наиболее важной, готовой к запуску задачи. Асинхронные события всё ещё обслуживаются обработчиками прерываний, которые могут сделать высокоприоритетную задачу готовой к выполнению, но обработчик прерываний всегда возвращается к прерванной задаче. Новая задача с более высоким приоритетом получит доступ к процессору только тогда, когда текущая задача добровольно освободит процессор, как показано на рисунке 2.   Когда в вытесняющем планировщике, показанном на рисунке 3, событие, или обработчик прерываний делает задачу с более высоким приоритетом готовой к выполнению, текущая задача немедленно приостанавливается и доступ к процессору получает задача с более высоким приоритетом. Большинство систем реального времени используют вытесняющие планировщики, потому что они реагируют быстрее, нежели кооперативные ядра.

рисунок 3

РЕСУРСЫ

   Очевидная выгода от использования ОСРВ в том, что она сокращает время выхода на рынок (time to market), поскольку упрощает разработку, не потребляя при этом  большого количества ресурсов процессора.

uC/OS-II от Micrium, например, использует только от 6 до 24 КВ памяти программ и от 1 до 8 КВ памяти данных на ARM- устройствах.

На небольших 8- или 16-битных платформах затраты ещё меньше – только от 4 до 16 КВ памяти программ.

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

Коммерческие преимущества осрв

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

   Коммерческая ОСРВ используется в сотнях, если не тысячах проектов, и базируется на испытанном коде, дающем уверенность в ее работоспособности.  uC/OS-II от Micrium имеет сертификат FAA/FDA/IEC, что позволяет использовать ее в авиационной электронике, медицине и других типах приложений, требовательных к безопасности.

Даже если устройство не нуждается в надежности ОСРВ, сертифицированных для авиационной электроники, всё таки приятно знать, что ОСРВ прошла расширенное тестирование. uC/OS-II также в высшей степени мобильна и может работать на более чем 45 различных процессорах. Код приложения может быть легко перенесён (портирован) с 8-битной на 32-битную архитектуру и даже на DSP.

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

   Большинство сервисов, которые могут потребоваться приложению, уже интегрированы в ОСРВ. Среди них: – Управление временем (time management) – временные задержки и таймеры – Управление задачами (task management) – создание, удаление, приостановка, возобновление – Взаимоисключения – Передача сообщений – Передача сигналов

   Преимущества использования ОСРВ подчеркиваются доступностью полного портфолио компонентов встроенного программного обеспечения (ПО), а также промежуточного ПО, включая стек TCP/IP, стек USB, стек CANbus,  UART, файловые системы и графический интерфейс пользователя. Конечно, некоторые компоненты могут потребовать большего быстродействия, чем то, которым располагают low-end процессоры.

    Два направления в индустрии коммерческих ОСРВ делают начало работы с ними еще проще. Многие ОСРВ, включая uC/OS-II теперь продаются на основе, не требующей авторских выплат, что гораздо выгоднее, чем использование ОСРВ, которые требуют непрерывной уплаты роялти. Зачастую, ОСРВ входит, в случае приобретения лицензии, во многие стартовые наборы (MCU starter kits).

ЗАКЛЮЧЕНИЕ

   ОСРВ – бесценный инструмент, упрощающий разработку большинства встраиваемых приложений – реального времени, или нет – и позволяющий добавление новых функций, не требуя больших изменений в ПО. Учитывая небольшие системные издержки, использование ОСРВ в настоящее время оправдано во многих малых 8- и 16-битных встраиваемых системах, а также в системах с 32-х битными или более мощными процессорами.

Источник: http://chipenable.ru/index.php/item/61

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

Источник: https://megapredmet.ru/1-66668.html

Оценка статьи:
1 звезда2 звезды3 звезды4 звезды5 звезд (нет голосов)
Загрузка...
Поделиться с друзьями:
Ссылка на основную публикацию
Похожие публикации
Adblock
detector
",css:{backgroundColor:"#000",opacity:.6}},container:{block:void 0,tpl:"
"},wrap:void 0,body:void 0,errors:{tpl:"
",autoclose_delay:2e3,ajax_unsuccessful_load:"Error"},openEffect:{type:"fade",speed:400},closeEffect:{type:"fade",speed:400},beforeOpen:n.noop,afterOpen:n.noop,beforeClose:n.noop,afterClose:n.noop,afterLoading:n.noop,afterLoadingOnShow:n.noop,errorLoading:n.noop},o=0,p=n([]),h={isEventOut:function(a,b){var c=!0;return n(a).each(function(){n(b.target).get(0)==n(this).get(0)&&(c=!1),0==n(b.target).closest("HTML",n(this).get(0)).length&&(c=!1)}),c}},q={getParentEl:function(a){var b=n(a);return b.data("arcticmodal")?b:(b=n(a).closest(".arcticmodal-container").data("arcticmodalParentEl"),!!b&&b)},transition:function(a,b,c,d){switch(d=null==d?n.noop:d,c.type){case"fade":"show"==b?a.fadeIn(c.speed,d):a.fadeOut(c.speed,d);break;case"none":"show"==b?a.show():a.hide(),d();}},prepare_body:function(a,b){n(".arcticmodal-close",a.body).unbind("click.arcticmodal").bind("click.arcticmodal",function(){return b.arcticmodal("close"),!1})},init_el:function(d,a){var b=d.data("arcticmodal");if(!b){if(b=a,o++,b.modalID=o,b.overlay.block=n(b.overlay.tpl),b.overlay.block.css(b.overlay.css),b.container.block=n(b.container.tpl),b.body=n(".arcticmodal-container_i2",b.container.block),a.clone?b.body.html(d.clone(!0)):(d.before("
"),b.body.html(d)),q.prepare_body(b,d),b.closeOnOverlayClick&&b.overlay.block.add(b.container.block).click(function(a){h.isEventOut(n(">*",b.body),a)&&d.arcticmodal("close")}),b.container.block.data("arcticmodalParentEl",d),d.data("arcticmodal",b),p=n.merge(p,d),n.proxy(e.show,d)(),"html"==b.type)return d;if(null!=b.ajax.beforeSend){var c=b.ajax.beforeSend;delete b.ajax.beforeSend}if(null!=b.ajax.success){var f=b.ajax.success;delete b.ajax.success}if(null!=b.ajax.error){var g=b.ajax.error;delete b.ajax.error}var j=n.extend(!0,{url:b.url,beforeSend:function(){null==c?b.body.html("
"):c(b,d)},success:function(c){d.trigger("afterLoading"),b.afterLoading(b,d,c),null==f?b.body.html(c):f(b,d,c),q.prepare_body(b,d),d.trigger("afterLoadingOnShow"),b.afterLoadingOnShow(b,d,c)},error:function(){d.trigger("errorLoading"),b.errorLoading(b,d),null==g?(b.body.html(b.errors.tpl),n(".arcticmodal-error",b.body).html(b.errors.ajax_unsuccessful_load),n(".arcticmodal-close",b.body).click(function(){return d.arcticmodal("close"),!1}),b.errors.autoclose_delay&&setTimeout(function(){d.arcticmodal("close")},b.errors.autoclose_delay)):g(b,d)}},b.ajax);b.ajax_request=n.ajax(j),d.data("arcticmodal",b)}},init:function(b){if(b=n.extend(!0,{},a,b),!n.isFunction(this))return this.each(function(){q.init_el(n(this),n.extend(!0,{},b))});if(null==b)return void n.error("jquery.arcticmodal: Uncorrect parameters");if(""==b.type)return void n.error("jquery.arcticmodal: Don't set parameter \"type\"");switch(b.type){case"html":if(""==b.content)return void n.error("jquery.arcticmodal: Don't set parameter \"content\"");var e=b.content;return b.content="",q.init_el(n(e),b);case"ajax":return""==b.url?void n.error("jquery.arcticmodal: Don't set parameter \"url\""):q.init_el(n("
"),b);}}},e={show:function(){var a=q.getParentEl(this);if(!1===a)return void n.error("jquery.arcticmodal: Uncorrect call");var b=a.data("arcticmodal");if(b.overlay.block.hide(),b.container.block.hide(),n("BODY").append(b.overlay.block),n("BODY").append(b.container.block),b.beforeOpen(b,a),a.trigger("beforeOpen"),"hidden"!=b.wrap.css("overflow")){b.wrap.data("arcticmodalOverflow",b.wrap.css("overflow"));var c=b.wrap.outerWidth(!0);b.wrap.css("overflow","hidden");var d=b.wrap.outerWidth(!0);d!=c&&b.wrap.css("marginRight",d-c+"px")}return p.not(a).each(function(){var a=n(this).data("arcticmodal");a.overlay.block.hide()}),q.transition(b.overlay.block,"show",1*")),b.overlay.block.remove(),b.container.block.remove(),a.data("arcticmodal",null),n(".arcticmodal-container").length||(b.wrap.data("arcticmodalOverflow")&&b.wrap.css("overflow",b.wrap.data("arcticmodalOverflow")),b.wrap.css("marginRight",0))}),"ajax"==b.type&&b.ajax_request.abort(),p=p.not(a))})},setDefault:function(b){n.extend(!0,a,b)}};n(function(){a.wrap=n(document.all&&!document.querySelector?"html":"body")}),n(document).bind("keyup.arcticmodal",function(d){var a=p.last();if(a.length){var b=a.data("arcticmodal");b.closeOnEsc&&27===d.keyCode&&a.arcticmodal("close")}}),n.arcticmodal=n.fn.arcticmodal=function(a){return e[a]?e[a].apply(this,Array.prototype.slice.call(arguments,1)):"object"!=typeof a&&a?void n.error("jquery.arcticmodal: Method "+a+" does not exist"):q.init.apply(this,arguments)}}(jQuery)}var debugMode="undefined"!=typeof debugFlatPM&&debugFlatPM,duplicateMode="undefined"!=typeof duplicateFlatPM&&duplicateFlatPM,countMode="undefined"!=typeof countFlatPM&&countFlatPM;document["wri"+"te"]=function(a){let b=document.createElement("div");jQuery(document.currentScript).after(b),flatPM_setHTML(b,a),jQuery(b).contents().unwrap()};function flatPM_sticky(c,d,e=0){function f(){if(null==a){let b=getComputedStyle(g,""),c="";for(let a=0;a=b.top-h?b.top-h{const d=c.split("=");return d[0]===a?decodeURIComponent(d[1]):b},""),c=""==b?void 0:b;return c}function flatPM_testCookie(){let a="test_56445";try{return localStorage.setItem(a,a),localStorage.removeItem(a),!0}catch(a){return!1}}function flatPM_grep(a,b,c){return jQuery.grep(a,(a,d)=>c?d==b:0==(d+1)%b)}function flatPM_random(a,b){return Math.floor(Math.random()*(b-a+1))+a}
");let k=document.querySelector(".flat_pm_modal[data-id-modal=\""+a.ID+"\"]");if(-1===d.indexOf("go"+"oglesyndication")?flatPM_setHTML(k,d):jQuery(k).html(b+d),"px"==a.how.popup.px_s)e.bind(h,()=>{e.scrollTop()>a.how.popup.after&&(e.unbind(h),f.unbind(i),j())}),void 0!==a.how.popup.close_window&&"true"==a.how.popup.close_window&&f.bind(i,()=>{e.unbind(h),f.unbind(i),j()});else{let b=setTimeout(()=>{f.unbind(i),j()},1e3*a.how.popup.after);void 0!==a.how.popup.close_window&&"true"==a.how.popup.close_window&&f.bind(i,()=>{clearTimeout(b),f.unbind(i),j()})}f.on("click",".flat_pm_modal .flat_pm_crs",()=>{jQuery.arcticmodal("close")})}if(void 0!==a.how.outgoing){let b,c="0"==a.how.outgoing.indent?"":" style=\"bottom:"+a.how.outgoing.indent+"px\"",e="true"==a.how.outgoing.cross?"":"",f=jQuery(window),g="scroll.out"+a.ID,h=void 0===flatPM_getCookie("flat_out_"+a.ID+"_mb")||"false"!=flatPM_getCookie("flat_out_"+a.ID+"_mb"),i=document.createElement("div"),j=jQuery("body"),k=()=>{void 0!==a.how.outgoing.cookie&&"false"==a.how.outgoing.cookie&&h&&(jQuery(".flat_pm_out[data-id-out=\""+a.ID+"\"]").addClass("show"),j.on("click",".flat_pm_out[data-id-out=\""+a.ID+"\"] .flat_pm_crs",function(){flatPM_setCookie("flat_out_"+a.ID+"_mb",!1)})),(void 0===a.how.outgoing.cookie||"false"!=a.how.outgoing.cookie)&&jQuery(".flat_pm_out[data-id-out=\""+a.ID+"\"]").addClass("show")};switch(a.how.outgoing.whence){case"1":b="top";break;case"2":b="bottom";break;case"3":b="left";break;case"4":b="right";}jQuery("body > *").eq(0).before("
"+e+"
");let m=document.querySelector(".flat_pm_out[data-id-out=\""+a.ID+"\"]");-1===d.indexOf("go"+"oglesyndication")?flatPM_setHTML(m,d):jQuery(m).html(e+d),"px"==a.how.outgoing.px_s?f.bind(g,()=>{f.scrollTop()>a.how.outgoing.after&&(f.unbind(g),k())}):setTimeout(()=>{k()},1e3*a.how.outgoing.after),j.on("click",".flat_pm_out .flat_pm_crs",function(){jQuery(this).parent().removeClass("show").addClass("closed")})}countMode&&(flat_count["block_"+a.ID]={},flat_count["block_"+a.ID].count=1,flat_count["block_"+a.ID].click=0,flat_count["block_"+a.ID].id=a.ID)}catch(a){console.warn(a)}}function flatPM_start(){let a=flat_pm_arr.length;if(0==a)return flat_pm_arr=[],void jQuery(".flat_pm_start, .flat_pm_end").remove();flat_body=flat_body||jQuery("body"),!flat_counter&&countMode&&(flat_counter=!0,flat_body.on("click","[data-flat-id]",function(){let a=jQuery(this),b=a.attr("data-flat-id");flat_count["block_"+b].click++}),flat_body.on("mouseenter","[data-flat-id] iframe",function(){let a=jQuery(this),b=a.closest("[data-flat-id]").attr("data-flat-id");flat_iframe=b}).on("mouseleave","[data-flat-id] iframe",function(){flat_iframe=-1}),jQuery(window).on("beforeunload",()=>{jQuery.isEmptyObject(flat_count)||jQuery.ajax({async:!1,type:"POST",url:ajaxUrlFlatPM,dataType:"json",data:{action:"flat_pm_ajax",data_me:{method:"flat_pm_block_counter",arr:flat_count}}})}).on("blur",()=>{-1!=flat_iframe&&flat_count["block_"+flat_iframe].click++})),flat_userVars.init();for(let b=0;bflat_userVars.textlen||void 0!==a.chapter_sub&&a.chapter_subflat_userVars.titlelen||void 0!==a.title_sub&&a.title_subc&&cc&&c>d&&(b=flatPM_addDays(b,-1)),b>e||cd||c-1!=flat_userVars.referer.indexOf(a))||void 0!==a.referer.referer_disabled&&-1!=a.referer.referer_disabled.findIndex(a=>-1!=flat_userVars.referer.indexOf(a)))&&(c=!0),c||void 0===a.browser||(void 0===a.browser.browser_enabled||-1!=a.browser.browser_enabled.indexOf(flat_userVars.browser))&&(void 0===a.browser.browser_disabled||-1==a.browser.browser_disabled.indexOf(flat_userVars.browser)))){if(c&&void 0!==a.browser&&void 0!==a.browser.browser_enabled&&-1!=a.browser.browser_enabled.indexOf(flat_userVars.browser)&&(c=!1),!c&&(void 0!==a.geo||void 0!==a.role)&&(""==flat_userVars.ccode||""==flat_userVars.country||""==flat_userVars.city||""==flat_userVars.role)){flat_pm_then.push(a),flatPM_setWrap(a),flat_body.hasClass("flat_pm_block_geo_role")||(flat_body.addClass("flat_pm_block_geo_role"),flatPM_ajax("flat_pm_block_geo_role")),c=!0}c||(flatPM_setWrap(a),flatPM_next(a))}}}let b=jQuery(".flatPM_sticky");b.each(function(){let a=jQuery(this),b=a.data("height")||350,c=a.data("top");a.wrap("
");let d=a.parent()[0];flatPM_sticky(this,d,c)}),debugMode||countMode||jQuery("[data-flat-id]:not([data-id-out]):not([data-id-modal])").contents().unwrap(),flat_pm_arr=[],jQuery(".flat_pm_start, .flat_pm_end").remove()}


Обратная связь

ПОЗНАВАТЕЛЬНОЕ

Сила воли ведет к действию, а позитивные действия формируют позитивное отношение

Как определить диапазон голоса – ваш вокал

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

Целительная привычка

Как самому избавиться от обидчивости

Противоречивые взгляды на качества, присущие мужчинам

Тренинг уверенности в себе

Вкуснейший “Салат из свеклы с чесноком”

Натюрморт и его изобразительные возможности

Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д.

Как научиться брать на себя ответственность

Зачем нужны границы в отношениях с детьми?

Световозвращающие элементы на детской одежде

Как победить свой возраст? Восемь уникальных способов, которые помогут достичь долголетия

Как слышать голос Бога

Классификация ожирения по ИМТ (ВОЗ)

Глава 3. Завет мужчины с женщиной

Оси и плоскости тела человека – Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.

Отёска стен и прирубка косяков – Когда на доме не достаёт окон и дверей, красивое высокое крыльцо ещё только в воображении, приходится подниматься с улицы в дом по трапу.

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

Быстродействие ПЛК (компьютера) влияет на величину динамической погрешности системы автоматизации и запас ее устойчивости при наличии обратной связи.

Для улучшения этих характеристик используют быстродействующие модули ввода-вывода и компьютер (ПЛК) с высокопроизводительным процессором.

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

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

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

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

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

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

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

Базовыми требованиями для обеспечения режима реального времени являются следующие:

1) высокоприоритетные задачи всегда должны выполняться в первую очередь;

2) должна быть исключена инверсия приоритетов;

3) процессы и потоки, время выполнения которых нельзя планировать, никогда не должны полностью занимать ресурсы системы.

Инверсией приоритетов называют ситуацию, когда поток с высоким приоритетом требует предоставления ресурса, который уже занят потоком с более низким приоритетом.

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

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

Для обеспечения режима реального времени в ОС могут быть реализованы следующие требования

1) поддержка динамических приоритетов,которые можно менять в процессе выполнения задачи, в многозадачном режиме с вытесняющим ядром (как для процессов, так и для потоков);

2) возможность наследования приоритетов;

3) возможность вытеснения задач ядром ОС;

4) ограниченная латентность прерываний (время, в течение которого прерывание запрещено – на время обработки критической секции кода);

5) выполнение сервисов ОС с приоритетом, который назначается клиентом сервиса.

В системах РВ обычно отсутствует виртуальная память, поскольку этот метод использует подкачку страниц с диска, время выполнения которой является непредсказуемым.

Наиболее распространенными в ПЛК и компьютерах для решения задач автоматизации являются операционные системы Windows CE, QNX Neutrino и OS-9.

QNX Neutrino

QNX Neutrino корпорации QNX Software Systems является операционной системой реального времени и обеспечивает многозадачный режим с приоритетами. Поддерживает микропроцессоры семейств ARM,StrongARM, xScale, x86, MIPS, PowerPC, SH-4, способна выполнять до 250 задач на одном узле.

QNX относится к микроядерным ОС, т.е. реализует только базовые функции ядра – управление адресным пространством ОЗУ и виртуальной памяти, процессами и потоками, обеспечивает межпроцессорную коммуникацию. Состоит из ядра, планировщика процессов и сервисов.

Построена на основе сервисов – небольших задач, выполняющих основные функции ОС. Такая структура позволяет отключить любую ненужную функциональность, не изменяя ядро.

Каждый драйвер, приложение, протокол или файловая система выполняются вне ядра, в защищенном адресном пространстве.

Инверсия приоритетов преодолевается с помощью распределенного наследования приоритетов. Операционная система QNX нашла применение как на нижнем уровне АСУТП (ОС для контроллеров), так и на верхнем уровне (ОС для программного обеспечения SCADA).

OS-9

Операционная система OS-9 фирмы Microware System является многозадачной и многопользовательской, работает в режиме мягкого реального времени. Используется во встраиваемых приложениях на платформах ARM, StrongARM, MIPS, PowerPC, Hitachi SuperH, x86, Pentium, XScale, Motorola 68K.

OS-9 относится к классу Unix-подобных операционных систем реального времени и предлагает многие привычные элементы среды Unix.

Все функциональные компоненты OS-9, включая ядро, иерархические файловые менеджеры, систему ввода/вывода и средства разработки, реализованы в виде независимых модулей.

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

OS-9 обеспечивает выполнение всех основных функций операционных систем реального времени: управление прерываниями, межзадачный обмен информацией и синхронизация задач.

OC WINDOWS

Операционная система Windows знакома всем как настольная система. Но это, прежде всего, относится к платформам Windows 3.хх/95, в которых действительно отсутствует поддержка реального времени. Ситуация резко изменилась с появлением Windows NT.

Сама по себе Windows NT не является операционной системой реального времени в силу ряда ее особенностей. Система поддерживает аппаратные, а не программные прерывания, отсутствует приоритетная обработка отложенных процедур и др.

Но в конце ХХ века ряд фирм предприняли серьезные попытки превратить Windows NT в ОС жесткого реального времени. И эти попытки увенчались успехом. Компания VenturCom разработала модуль Real Time Extension (RTX) – подсистему реального времени (РВ) для Windows NT.

Эта подсистема имеет собственный планировщик со 128 приоритетами прерываний, который не зависит от NT. Максимальное время реакции на прерывание составляет 20-80 мкс вне зависимости от загрузки процессора. Теперь при каждом прерывании от таймера приоритет передается критичным по времени задачам.

А в оставшееся от их работы время могут выполняться «медленные» процессы: ввод/вывод, работа с диском, сетью, графическим интерфейсом и т. п.

Windows CE.NET

Многозадачная операционная система жесткого реального времени Windows CE.NET корпорации Microsoft поддерживает микропроцессоры с архитектурой ARM, StrongARM и xScale, MIPS, SH, X86-совместимые.

32-разрядная Windows CE была создана компанией Microsoft для малых компьютеров (калькуляторов), но в силу ряда достоинств стала претендовать на роль стандартной ОС реального времени.

К числу этих достоинств относятся:

1) открытость и простота стыковки с другими ОС семейства Windows;

2) время реакции порядка 500 мкс;

3) значительно меньшие по сравнению с другими ОС Windows требования к ресурсам памяти и возможность построения бездисковых систем.

4) допускает одновременное выполнение до 32 процессов;

5) имеет 256 уровней приоритетов;

6) поддерживает вытесняющую многозадачность;

7) обеспечивает карусельное исполнение цепочек с одинаковым приоритетом;

8) поддерживает вложенные прерывания;

9) имеет среднее время обработки прерывания 2,8 мкс, поддерживает вложенные прерывания;

10) обеспечивает время обработки потока прерываний (Interrupt Service Thread, IST), равное 17,9 мкс;

11) в минимальной конфигурации может быть установлена при объеме ОЗУ 200 Кб.

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

Windows CE .NET поддерживает Microsoft Visual Studio .NET и Microsoft eMbedded Visual C++ с языками программирования Visual C++, Visual C#, and Visual Basic .NET

А в 1999 году компанией Direct by Koyo ОС Windows CE была впервые установлена на платформу микроPLC.

Выбор операционной системы программно-технических средств верхнего уровня АСУТП определяется прикладной задачей (ОС общего пользования или ОСРВ).

Но наибольшую популярность и распространение получили различные варианты ОС Windows (Windows NT/2000).

Ими оснащены программно-технические средства верхнего уровня АСУТП, представленные персональными компьютерами (ПК) разной мощности и конфигурации – рабочие станции операторов/диспетчеров и специалистов, серверы баз данных (БД) и т. д.

Такая ситуация возникла в результате целого ряда причин и тенденций развития современных информационных и микропроцессорных технологий.

Вот несколько основных аргументов в пользу Windows:

– Windows имеет очень широкое распространение в мире, в том числе и в России, в связи с чем легко найти специалиста, который мог бы сопровождать системы на базе этой ОС;

– эта ОС имеет множество приложений, обеспечивающих решение различных задач обработки и представления информации;

– ОС Windows и Windows-приложения просты в освоении и обладают типовым интуитивно понятным интерфейсом;

– приложения, работающие под управлением Windows, поддерживают общедоступные стандарты обмена данными;

– системы на базе ОС Windows просты в эксплуатации и развитии, что делает их экономичными как с точки зрения поддержки, так и при поэтапном росте;

– Microsoft развивает информационные технологии (ИТ) для Windows высокими темпами, что позволяет компаниям, использующим эту платформу «идти в ногу со временем».

[1] Планирование выполнения задач — одна из ключевых концепций в многозадачности и многопроцессорности как в операционных системах общего назначения, так и в операционных системах реального времени. Планирование заключается в назначении приоритетов процессам в очереди с приоритетами. Программный код, выполняющий эту задачу, называется планировщиком