Вход |  Регистрация
 
 
Время электроники Среда, 21 ноября
 
 

Это интересно!

Ранее

Антенны – важный элемент радиостанций. От теории к практике

Данная статья рассчитана на тех, кто интересуется организацией радиосетей технологической и гражданской радиосвязи и занимается их техническим обслуживанием, в особенности на радиомехаников и радиолюбителей, не имеющих практического опыта в области антенной техники. В статье в упрощенном виде рассмотрены некоторые вопросы теории, имеющие наиболее важное прикладное значение и касающиеся особенностей антенн указанных ниже диапазонов, которые в различных источниках излагаются по-разному, что на практике может создать некоторые проблемы. Также приводятся практические рекомендации по выбору, обслуживанию и ремонту антенно-фидерных устройств радиостанций КВ и УКВ диапазонов, работающих в интервале частот 26…29,7 и 33…174 МГц соответственно.

Инь и Янь в вопросах согласования каналов передачи. Часть 1*

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

Как с помощью PoE-технологии обеспечить надежную работу IP-телефона

Технология РоЕ разработана для сравнительно крупного рынка информационных технологий, включая IP-телефоны, IP-камеры и точки беспроводного доступа. IP-телефон, использующий стандарт Voice over IP (VoIP), должен работать как обычный телефон — снабжаться питанием через кабель данных и не отключаться при перебоях электроэнергии. Эти возможности очень привлекательны и в тех областях промышленности и автоматизации зданий, где неудобно или дорого подавать на устройства высокое напряжение, либо желательно обеспечить резервное питание всей автоматизированной системы из одного источника. В статье кратко излагаются основные сведения, касающиеся реализации сети РоЕ.

 

15 мая

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

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





Вы можете скачать эту статью в формате pdf здесь.

Скрыть/показать html версию статьи
background image
ТЕОРИЯ
И
ПР
АК
ТИК
А
105
электронные компоненты №5 2008
Среди разработчиков «железа» иной раз можно встретить едва не мистиче-
скую убежденность в том, что достаточно выбрать подходящую операцион-
ную систему реального времени и все вопросы решатся сами собой. Подобная
уверенность скорее объясняется ошибочной точкой зрения, нежели реальным
положением дел. В статье очень кратко рассмотрены некоторые проблемы,
встречающиеся при использовании систем реального времени. Статья осно-
вана на работе [2] и содержит ряд сокращений и дополнений
ОПЕРАЦИОННЫЕ СИСТЕМЫ
РЕАЛЬНОГО ВРЕМЕНИ
Игорь Алексеев, технический консультант, ИД «Электроника»
введенИе
Существует довольно много опреде-
лений понятия «операционная систе-
ма реального времени» (ОСРВ). На наш
взгляд, наиболее удачно следующее:
правильность функционирования ОСРВ
зависит не только от логической кор-
ректности вычислений, но и от времени,
за которое эти вычисления производят-
ся. То есть для событий, происходящих
в такой системе, то, когда эти события
происходят, так же важно, как логиче-
ская корректность самих событий [1].
Одно из главных отличий ОСРВ от опе-
рационных систем общего назначения
(ОСОН) заключается в методах планирова-
ния выполнения задач. Реальное время —
понятие относительное. Например,
задержки ОСРВ в системе управления
движением современного автомобиля не
должны превышать долей миллисекунд,
еще более критичны требования в авиа-
ции, а, допустим, в инерционных систе-
мах термостатирования задержки могут
составить много большую величину. Таким
образом, принадлежность ОС к ОСРВ
определяется не только быстродействи-
ем, но и рядом других факторов, которые
рассмотрены ниже.
оперАцИонные сИстемы
реАльного временИ
ОСРВ подразделяют на жесткие и
мягкие. В жестких ОСРВ гарантирова-
но выполнение определенной после-
довательности действий в заданное
время. Нарушение времени выполне-
ния приводит к отказу. Соответственно
заданная последовательность действий
имеет приоритет перед другими зада-
чами и может вытеснять их. Например,
в автомобильных системах управления
задача стабилизации движения авто-
мобиля имеет явный приоритет перед
задачей индикации наружной темпера-
туры, и должна быть выполнена в стро-
го заданное время, иначе автомобиль
может потерять управление. Как уже
отмечалось: реальное время — поня-
тие относительное и в инерционных
системах управления (например, термо-
статирование больших объемов) время
выполнения «жесткой» задачи может
составить несколько секунд. Однако на
практике считается, что время выпол-
нения приоритетной задачи в жесткой
ОСРВ все же должно быть ограничено
и не превышать нескольких десятков,
максимум сотен микросекунд.
Мягкая ОСРВ не гарантирует строго-
го выполнения определенной задачи в
заданное время, но и превышения време-
ни обработки не приводит к отказу. В этом
и заключается отличие жесткой ОСРВ от
мягкой — в первом случае опоздание не
допустимо никогда, так как означает отказ,
во втором — недопустимо, как правило, и
не ведет к фатальному отказу.
В сказанном кроется и основное
отличие ОСРВ от ОС общего назначения
(ОСОН). В ОСОН планировщик обычно
использует «справедливую» политику рас-
пределения потоков и процессов. Такой
подход позволяет достигать высокой
общей производительности, но при этом
более высокоприоритетные, критические
ко времени выполнения потоки не имеют
приоритета при выполнении, а это недопу-
стимо для ОСРВ, где приоритетная задача
должна быть выполнена в заданное время.
ОСОН даже может понизить приоритет,
первоначально назначенный высоко-
приоритетному потоку и, наоборот, повы-
сить приоритет остальных потоков. Как
следствие, высокоприоритетный процесс
может быть вытеснен потоками с меньшим
приоритетом. Кроме того, большинство
ОСОН имеют неограниченные задержки
распределения: чем больше потоков рабо-
тает в системе, тем больше времени требу-
ется ОС общего назначения для того, чтобы
запланировать поток на выполнение.
ОСРВ — многозадачные системы, они
распределяют между задачами ресур-
сы процессора. Задачи делятся на про-
цессы и потоки. Первые — загружаемый
программный модуль, обычно имеющий
памяти независимые области для кода и
данных. В потоках могут использоваться
общие участки кода и данных в одном
программном модуле [1]. ОСРВ состоит из
ядра и ОС. Обычно нельзя провести чет-
кую границу между ними. Для понимания
дальнейшего материала необходимо при-
вести основные термины и определения.
– Синхронизация — упорядочение
выполнения задач, например, при досту-
пе к общему ресурсу, или при необхо-
димости соблюсти последовательность
выполнения задач во времени, или в
привязке к внешнему событию.
– Ресурс — аппаратный или про-
граммный модуль, использование кото-
рого в каждый момент времени воз-
можно только одной задачей. Например,
порт процессора или область памяти.
– Семафор — используется для син-
хронизации задач.
– Зависание (Deadlock) — возника-
ет при неправильной синхронизации,
задачи не могут поделить ресурс.
– Инверсия приоритетов — низко-
приоритетная задача забирает ресурс у
высокоприоритетной.
Ядро осрв, реАлИзующее
плАнИровАнИе с вытесненИем
зАдАч
Ядро — центральный элемент ОС
обеспечивает набор базовых сервисов
для остальных частей ОС. В ОСРВ задачи
выполняются в порядке приоритетности.
Если высокоприоритетный поток готов к
работе, то он может за короткий и огра-
ниченный по времени интервал завладеть
процессором, оттеснив любой менее при-
оритетный поток. Высокоприоритетный
поток может работать, не прерываясь до
тех пор, пока задача не будет заверше-
на — так называемое основанное на при-
оритетах вытесняемое планирование.
Конечно, существует временное окно,
в котором вытеснение невозможно, но в
хорошо спроектированных ОСРВ подоб-
ные интервалы чрезвычайно коротки.
Как правило, в ОСРВ устанавливается
максимальная длительность интервала,
в течение которого вытеснение запре-
щено и прерывания замаскированы: это
дает разработчику возможность учесть
background image
106
ТЕОРИЯ
И
ПР
АК
ТИК
А
www. elcp.ru
самые худшие случаи. В некоторых ОСОН
используется метод вытесняемого плани-
рования, но интервалы в течение которых
вытеснение заблокировано значительно
больше, чем аналогичные интервалы в
типичных ОСРВ. Более того, ОСОН не
учитывают условия, которые могут при-
внести неограниченные задержки, такие
как потеря информации о приоритетах.
Бывают случаи, когда менее приоритет-
ный поток блокирует доступ к ЦПУ потока
с более высоким приоритетом — инвер-
сия приоритетов [2]. При этом возможны
сбои или даже отказы в работе системы. К
сожалению, инверсия приоритетов зача-
стую остается незамеченной при проекти-
ровании системы. Инверсия приоритетов
происходит когда две задачи, имеющие
разные приоритеты, совместно исполь-
зуют ресурс, но более высокоприори-
тетный поток не может получить доступ
к совместному ресурсу, используемому
менее приоритетной задачей.
Рассмотрим пример. Задача 1 имеет
больший приоритет, но должна ожидать
пока выполнится задача 2 и освободит,
требуемый для задачи 1 ресурс. Такая
ситуация называется блокировкой: зада-
ча 1 ожидает когда задача 2 освободит
общий ресурс, или задача 1 запрашивает
сервис, который в данный момент исполь-
зуется задачей 2. Общее время, в течение
которого задача 1 находится в ожидании,
может варьироваться от минимального
значения, до некоторой максимальной
величины. Этот интервал называют фак-
тором блокировки. Допустим, что в этот
момент готова к выполнению задача 3,
более приоритетная, нежели задача 2
и не имеющая с ней общих ресурсов. В
этом случае задача 3 вытеснит задачу 2,
тем самым, увеличив фактор блокиров-
ки. Фактически несколько задач могут
вытеснить, таким образом, Задачу 2, при-
водя к так называемому эффекту цепной
блокировки. В таких условиях Задача 2
может быть вытеснена на неопределен-
ный период времени, приводя к неогра-
ниченной инверсии приоритета и таких
образом вынуждая Задачу 1 превышать
свои временные ограничения [1].
Для предотвращения такой ситуации
существует ряд механизмов — насле-
дование приоритета и эмуляция макси-
мума приоритета. Остановимся на при-
мере наследования приоритетов. Если в
приведенном выше примере присвоить
задаче 2 приоритет задачи 1, то задача 3
не сможет вытеснить задачу 2 и фактор
блокировки не увеличится.
рАзбИенИе плАнИровщИков
нА чАстИ длЯ гАрАнтИровАнИЯ
доступностИ цпу
ОСРВ используют основанную на
приоритетах модель вытесняемой плани-
ровки — задача с большим приорите-
том может вытеснить задачу с меньшим
приоритетом и получить доступ к ресур-
су процессора. Простой с виду принцип
способен породить проблему: задача с
более высоким приоритетом может вовсе
не отдать ресурс (процессорное время,
например) менее приоритетной задаче.
Например, пусть у вас есть два процесса,
процесс А и процесс Б, где процесс А
имеет незначительно более высокий
приоритет нежели, чем процесс Б. Если
выполняется процесс А (особенно если
А работает в цикле) или он стал жертвой
DoS-атаки (Denial of Serviсe — воздействие,
вызывающее отказ в обслуживании), то он
будет блокировать процесс Б и любые
другие процессы имеющие более низкий
приоритет. Проще говоря, планирование,
основанное на приоритетах, не гарантиру-
ет, что процессы с меньшим приоритетом
получат доступ к общему ресурсу.
Решить эту проблему помогает плани-
ровщик с фиксированным разбиением. В
этом случае разработчик можно разделить
задачи на группы, или разделы, и назначить
определенный процент времени ЦПУ каж-
дому разделу. При таком подходе ни одна
задача в любом разделе не сможет зани-
мать больше времени ЦПУ, чем статически
определенный и фиксированный процент.
Поскольку алгоритм планирования
является фиксированным, каждый из раз-
делов не может использовать циклы ЦПУ,
назначенные остальным разделам, даже
если те разделы совсем не используют
выделяемого им времени. Этот подход при-
водит к неэкономному расходу циклов ЦПУ
и не дает разделам эффективно отрабаты-
вать критические запросы. Посему систем-
ные разработчики должны использовать
более дорогие процессоры, мириться с
Рис. 1. Адаптивное разбиение
background image
ТЕОРИЯ
И
ПР
АК
ТИК
А
107
электронные компоненты №5 2008
более медленной системой, или ограничивать часть функциональ-
ности, которую в принципе система могла бы поддерживать.
АдАптИвное рАзбИенИе
В отличие от статического разбиения — адаптивное раз-
биение использует стандартный, основанный на приоритетах,
алгоритм планирования в том случае если система работает с
неполной загрузкой ЦПУ, или не находится под воздействием
атаки. В результате, потоки в одном разделе могут получать
доступ к запасным циклам ЦПУ, неиспользуемым потоками в
других разделах. Такой подход является наилучшим в обоих
случаях: он дает возможность гарантированного доступа к
ресурсу ЦПУ в случае если система выходит за рамки исполь-
зования процессорных циклов (для максимальной защищен-
ности и гарантированности доступности служб), и он может
распределить свободные циклы ЦПУ когда последние появля-
ются (см. рис. 1). Адаптивное разбиение ограничивает возмож-
ность захвата ресурсов ЦПУ высокоприоритетными задачами
фиксированным процентом, до тех пор пока в системе не
появятся неиспользуемые циклы ЦПУ. Например, задача А и D
могут работать только во временные интервалы назначенные
для Раздела 3, поскольку задачи Е и F не требуют полного
использования выделенных им процессорных циклов. [2].
рАсшИренИе осрв
Тем не менее, есть плюсы и в использовании ОСОН — под-
держка широко используемого программного интерфейса и, в
случае свободно распространяемого ПО, открытые исходных тек-
стов. Поэтому производители ОСРВ стремятся дополнить ОСРВ
возможностями ОСОН. Например, в ОСРВ, реализованной на базе
микроядра, гораздо проще настроить ОС под конкретные нужды.
В микроядерной ОСРВ только небольшое ядро базовых служб
(например, таймеры, планировщик) расположены внутри само-
го ядра. Все другие компоненты — драйверы, файловые систе-
мы, протокольные стеки, приложения — работают вне ядра, как
отдельные, защищенные в памяти процессы. В результате, раз-
работка пользовательских драйверов и других, специфичных для
приложения, расширений ОС не требует специализированных
средств отладки ядра. В принципе, как программы пользователь-
ского пространства, такие расширения становится так же просто
разрабатывать, как и стандартные приложения, поскольку они
могут быть отлажены с помощью стандартных средств и способов.
Такого рода архитектура позволяет изолировать и
исправить сбой, произошедший на более высоком уровне.
Фактически, программный сторожевой таймер может выпол-
нять мониторинг подобного рода событий и перезапускать
соответствующие сервисы динамически, без перезагрузки
всей системы в целом. Эти плюсы не легко достижимы: неза-
планированная перезагрузка системы — самое опасное, что
может произойти с ОСРВ! Даже запланированная переза-
грузка, необходимая для включения программных обновле-
ний прерывает работу, хотя и контролируемым способом.
Гарантия того, что максимально допустимые задержки всегда
будут выдержаны — использование ОС доступной всегда,
даже при сбоях программ или обновления сервисов.
стрАтегИческое решенИе
Выбор подходящей ОСРВ может быть довольно сложной
задачей. Базовая архитектура ОСРВ является важным критери-
ем, но таковыми же являются и остальные факторы. А именно:
– Гибкий контроль алгоритмов планирования — поддер-
живает ли ОСРВ набор из нескольких алгоритмов планирова-
ния (FIFO, циклический, случайный и т.д.)? Можно ли назначать
эти алгоритмы для каждого потока в отдельности, или же
только один и тот же алгоритм для всех потоков?
– Гарантированная доступность ЦПУ — поддерживает
ли ОСРВ разделяемое планирование, которое обеспечивает
гарантированный процент времени доступа к ЦПУ любой
задачи, независимо от приоритета? Такие гарантии упрощают
процесс интегрирования подсистем от нескольких команд
разработчиков или производителей.
– Графические пользовательские интерфейсы — исполь-
зует ли ОСРВ базовые графические библиотеки, или же она
предоставляет расширенные возможности работы с графикой?
– Средства удаленной диагностики — поскольку простой
системы недопустим для многих встраиваемых систем, про-
изводители ОСРВ должны обеспечивать потребителей сред-
ствами диагностики, способными работать без прерывания
сервиса, который предоставляет на данный момент система.
– Открытая платформа разработки — предлагает ли
производитель ОСРВ среду разработки основанную на базе
открытой платформы?
– Возможности интернет — поддерживает ли ОСРВ совре-
менный набор из интегрированных протокольных стеков,
встроенный web-браузер?
– Стандартное API — привязывает ли ОСРВ ваше прило-
жение к частному API или же поддерживает стандартное API,
что существенно упрощает задачу переноса приложения (его
интегрирования) в другие ОС. Предоставляет ли ОС полно-
ценную поддержку API, или же она поддерживает только
набор определенных интерфейсов?
– Наборы примеров программного обеспечения — обе-
спечивает ли производитель ОСРВ хорошо документирован-
ными исходными текстами и различными отладочными набо-
рами, чтобы помочь сконфигурировать ОСРВ? Предлагаются
ли наборы по разработке драйверов, включая исходный код?
Литература
1. Сергей Сорокин, Системы реального времени//СТА, 1997 г.
2. Paul N. Leroux and Jeff Schaffer, Exactly When Do You Need Real
Time?// www.embedded.com/columns/technicalinsights/193001454?_
requestid=174301.
Оцените материал:

Автор: Игорь Алексеев, технический консультант, ИД «Электроника»



Комментарии

0 / 0
0 / 0

Прокомментировать





 

Горячие темы

 
 




Rambler's Top100
Руководителям  |  Разработчикам  |  Производителям  |  Снабженцам
© 2007 - 2018 Издательский дом Электроника
Использование любых бесплатных материалов разрешено, при условии наличия ссылки на сайт «Время электроники».
Создание сайтаFractalla Design | Сделано на CMS DJEM ®
Контакты