ОС РВ QNX . Поддержка СРВ ОС Linux .

Рассмотрим инструментальные средства разработки прило­ жений. ОС QNХ, как отмечалось, широко используется для встраиваемых систем. Пакет Ет bedded Kit позволяет разместить ОС QNХ и приложения пользователя в ПЗУ (Flash или RОМ) раз­рабатываемого промышленного контроллера. Пакет поддержи­вает различные аппаратные платформы (Intel, Осtagon, Ziatech и др.), архивацию данных или файлов в памяти, а также встраивае­мые файловые системы, которые обслуживают вызовы ввода-вы­вода стандарта РОSIX.

Многие приложения используют для отображения контроли­руемого технологического процесса в реальном времени графи­ческий интерфейс. Средством разработки графического интер­фейса для ОС QNХ является, например, пакет Р h о t оп Developers Тоо lkit . Пакет представляет собой встраиваемую графическую оболочку с поддержкой 2D- и ЗD-графики, а также с возможнос­тью запуска графических приложений, написанных для X Windows System. Пакет создает компактный код для встраиваемых прило­жений реального времени.

Пакет Photon Developers Тооlkit содержит:

• библиотеку графических примитивов;

• набор графических стандартных компонентов;

• средства интерактивного проектирования графических прило­жений РhАВ (Рhoton Аррlication Вuilder), обеспечивающие со­здание и редактирование сложных графических объектов из на­бора стандартных, а также вновь созданных компонентов.

Для создания Интернет-приложений в среде ОС QNХ имеет­ся пакет Voyager SDK (Software Development Kit), который содер­жит все инструменты, необходимые для разработки специализи­рованного Web-браузера. Браузер Voyager обеспечивает пользова­телю удаленный доступ к промышленному контроллеру.

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

Linux является 32-разрядной многозадачной и многопользо­вательской UNIX-подобной операционной системой, имеющей следующие основные свойства:

•соответствие стандарту РОS IX, что позволяет переносить разработанное для классических UNIX-систем программное обеспе­чение на Linux-системы; •модульный принцип организации, что является безусловным преимуществом перед так называемыми «монопольными» (рrо-prietary) UNIX-системами;

• расширяемость и масштабируемость системы, что делает ее пригодной для использования как в простых промышленных контроллерах на базе i386ЕХ-микропроцессора, так и в много­процессорных системах;

• предоставление всех возможностей, доступных через вычисли­тельную сеть, поскольку Linuх поддерживает работу с локаль­ными промышленными сетями (например, Еthernet и Рrofibus) и обеспечивает доступ к удаленным УВК через сеть Интернет; сетевые технологии в Ушах соответствуют концепции «клиент-сервер», реализуемой на основе протоколов ТСР/IР;

• возможность работы на большинстве известных 32-разрядных процессорных платформ: Intel,IВМ, Мotorola и др. Перенос си­стемы на другую платформу требует адаптации небольшой аппаратно-зависимой части исходного кода ядра (это в основном драйверы устройств и загрузчики ядра). Доступность исходного кода операционной системы дает возможность ее оптимальной настройки в конкретных случаях.

Усеченный вариант Linuх занимает 2 Мбайта на жестком дис­ке и хорошо подходит для компактных встроенных приложений (обычно потребность таких приложений в ресурсах оперативной памяти — от 2 до 8 Мбайт).

Для поддержки режима реального времени в среде Linuх раз­работаны специальные расширения KURT и UTIМЕ, а также RTLinuх.

Программный пакет К UR Т является системой «мягкого» ре­ального времени, имеет два режима работы — нормальный и ре­ального времени, оформлен в виде системного модуля Linuх RTMod, который является планировщиком реального времени. Планирование процессов реального времени может осуществ­ляться по событиям или по таймеру.

При переключении в режим реального времени все обычные процессы в системе приостанавливаются до завершения процес­са реального времени. Планировщик RTMod выделяет каждому процессу реального времени интервал (квант) времени, равный 10 мc.

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

Расширение RTLinux реализовано в виде небольшого ядра, поддерживающего режим «жесткого» реального времени, под уп­равлением которого работает Linuх [33]. Фактически ядро Linux становится ожидающей задачей в системе реального времени, которая выполняется только тогда, когда в очереди нет задач ре­ального времени. Процессы, выполняемые в среде Linux, не мо­гут при этом блокировать аппаратные прерывания и запрещать свою выгрузку из памяти.

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

Ядро реального времени в 1лпих является непрерываемым, но поскольку его программы очень малы, нет причин для больших задержек в обслуживании. Тестирование ядра на аппаратной платформе Рentium показало, что интервал задержки плани­рования задач не превышает 20 мкс.

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

Продвижением Linux в промышленные системы управления заняты более 100 компаний. Расширение RTLinux применимо для многих задач реального времени; ОС Linux может быть ис­пользована в качестве программной платформы для УВК СМ1820М.

1. 3 Функциональные требования к ОСРВ

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

Многозадачность подразумевает параллельное выполнение нескольких действий, однако практическая реализация парал­лельной работы упирается в проблему совместного использова­ния ресурсов вычислительной системы. И главным ресурсом, распределение которого между несколькими задачами называ­ется диспетчеризацией ( scheduling ), является процессор. Поэтому в однопроцессорной системе по-настоящему параллельное вы­полнение нескольких задач невозможно. Существует достаточно большое количество различных методов диспетчеризации, и основные среди них будут рассмотрены далее.

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

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

Поток может находиться в одном из следующих состояний:

1. Активный поток — это тот поток, который в данный мо­мент выполняется системой.

2. Поток в состоянии готовности — поток, который может выполняться и ждет своей очереди.

3. Блокированный поток — поток, который не может вы­полняться по некоторым причинам (например, ожида­ние события или освобождения нужного ресурса).

Далее рассматриваются функциональные требования, предъяв­ляемые на данном этапе к ОС, применяющимся в СРВ.

 

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

2. "Жесткие" и "мягкие" системы реального времени

 

В зависимости от отношения к опозданиям системы реального времени делятся на "жесткие" (hard) и "мягкие" (soft).

В жесткой системе:

· опоздания не допускаются ни при каких обстоятельствах;

· в случае опоздания результаты обработки уже никому не нужны;

· опоздание считается катастрофическим сбоем;

· стоимость опоздания бесконечно велика.

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

В мягкой системе реального времени:

· повышается стоимость опоздания;

· допускается низкая производительность в случае опоздания.

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

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

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

Нити и приоритеты

В Windows NT имеются два класса приоритетов: класс реального времени и динамический класс. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, тогда как приоритет процессов динамического класса может меняться диспетчером. Процесс имеет базовый уровень приоритета. Нить в процессе может иметь приоритет в диапазоне плюс/минус 2 около базового уровня или один из двух крайних уровней класса (16 или 31 для реального времени). Например, нить в процессе с базовым уровнем 24 может иметь приоритет 16, 22 - 26, 31. Очевидно, что гарантировать предсказуемость системы можно только при использовании процессов первого класса.

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

В ОС РВ вызовы системы синхронизации (семафоры или критические секции) должны уметь управлять наследованием приоритетов. В Windows NT это невозможно, поэтому требование 4 не удовлетворяется.

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

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

 

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: