ЖУРНАЛ СТА 3/2011

(Автор не случайно вводит дополни- тельную классификацию реального времени на условное и гарантирован- ное. Дело в том, что похожее по смыслу устоявшееся разделение реального вре- мени на жёсткое и мягкое на самом деле относится к свойствам самих ОС, а не к требованиям конечной задачи. Например, задача, требующая в рамках приведённой автором классификации реального времени условного, может быть реализована с применением ОС как жёсткого, так и мягкого реального времени, а то и без ОС вообще. Таким образом, в нарушении принципа «бритвы Оккама» автора обвинить нельзя. – Прим. пер .) Обеспечение гарантированного ре- ального времени – узкоспециализиро- ванная и нетривиальная задача, и в ряде приложений это требование можно смягчить до реального времени условного. Самый простой пример – воспроизведение звука. Чтобы кор- ректно воспроизводить звук при ши- роко распространённой частоте кван- тования 44,1 кГц, приложению не- обходимо передавать оборудованию 32 бита данных каждые 22,7 мкс. По- скольку все остальные сервисы ОС мо- гут иметь невытесняемые сегменты кода, выполняющиеся более чем 22,7 мкс, задержка может превысить необходимую величину; чтобы этого не произошло, применяется аппарат- ная буферизация, благодаря которой задержки, вносимые вытеснением, сглаживаются. Использование 32-раз- рядного буфера на 4096 элементов смягчает требование приложения к времени реакции системы до необхо- димости заполнения буфера ориенти- ровочно раз в 100 мс. П РИМЕРЫ ПРИЛОЖЕНИЙ ГАРАНТИРОВАННОГО РЕАЛЬНОГО ВРЕМЕНИ Для многих приложений характерны жёсткие требования к реальному вре- мени, которые не могут быть сведены к реальному времени условному. При- ведём примеры областей, в которых приложения часто требуют гарантиро- ванного реального времени. ● Авиация, космонавтика и ВПК. Современные аэрокосмические и военные приложения включают в себя авионику нового поколения, пункты управления, системы нави- гации и захвата/сопровождения це- ли, управления оружием и т.п. Уст- ройства, предназначенные для ис- пользования в оборонных систе- мах, гражданской авиации и космо- навтике, предъявляют одни из са- мых жёстких требований к ПО и требуют применения надёжной, вы- сокопроизводительной и «коммуни- кабельной» (в оригинале “connec- ted”. – Прим. пер .) операционной системы. ● АСУ ТП, приборостроение и робото- техника. Промышленные приложе- ния требуют одновременно высокой надёжности, предсказуемости и про- изводительности. Промышленное производство, энергетика, транс- порт – все эти отрасли по определе- нию предъявляют к приложениям повышенные требования по функ- циональной безопасности, посколь- ку отказы могут стоить миллионы долларов, а то и человеческих жиз- ней. Будь разрабатываемое устрой- ство хоть манипулятором сборочно- го конвейера, хоть удалённо управ- ляемым колёсным роботом, требова- ния к предсказуемости и производи- тельности ПО будут одинаково жёст- кими. ● Телекоммуникации. Современные приложения передачи данных и голоса предъявляют одновременно широкий спектр требований услов- ного и гарантированного реального времени наряду с требованиями высокой пропускной способности. Потоковая передача голоса и дру- гих медиаданных требует качества обслуживания, которое выходит за пределы возможностей ОС общего назначения. Высокая плотность се- тевого трафика также может вы- звать перегрузку стеков протоко- лов, поставляемых в составе уни- версальных ОС. Типичный пример такой задачи – это маршрутизация, требующая управления потоками из тысяч IP-пакетов в реальном времени. ● Мобильная связь. Реальное время – одно из ключевых требований к со- временным мобильным телефонам на базе одноядерных процессоров. Применение одноядерных процессо- ров позволяет производителям мо- бильных телефонов снизить себе- стоимость; однако это одновременно требует реализации на одном и том же ядре и основного протокола связи с его жёсткими требованиями детер- минизма, и пользовательских прило- жений реального времени, включая потоковое мультимедиа. П РЕДСКАЗУЕМОСТЬ РЕАКЦИИ : ТРЕБОВАНИЯ И СПОСОБЫ ИЗМЕРЕНИЯ У всех описанных в предыдущем раз- деле приложений есть одна общая черта – необходимость в чётко регла- ментированных (на уровне единиц микросекунд) временах реакции на прерывание и перепланирования за- дач. Рассмотрим эти параметры под- робнее. Время реакции на прерывание Время отклика системы часто изме- ряется как время её реакции на преры- вание. Время реакции на прерывание складывается из длительности всех действий ядра ОС по инициированию его обработки, включая сохранение контекста задач, определение источни- ка прерывания и передачу управления соответствующему обработчику. В действительности время реакции на прерывание является сильно аппарат- но-зависимым и определяется быстро- действием оборудования; с программ- ной стороны можно управлять только временем выполнения подпрограммы обработки прерывания (Interrupt Ser- vice Routine – ISR). Однако в большин- стве приложений реального времени, перед тем как система сможет выпол- нить какие-то действия по факту воз- никновения прерывания, сначала дол- жен быть поставлен на выполнение некий процесс, задача или поток. Вре- мя выполнения этой операции склады- вается из так называемых времени пере- планирования и времени переключения контекста. Время перепланирования и время переключения контекста Время переключения контекста – это время, требуемое для передачи управ- ления от одной задачи другой. Пере- ключению контекста предшествует перепланирование, то есть принятие планировщиком ОС решения, какой задаче необходимо предоставить про- цессор; время перепланирования – это время, за которое планировщик данное решение принимает. (ОС VxWorks и Wind River Linux используют вытес- няющий планировщик, поэтому реше- ние о планировании задачи принима- ется на основании её приоритета, уста- новленной дисциплины планирования и состояния соответствующих средств синхронизации. Например, задача вы- сокого приоритета может быть забло- ОБ ЗОР / П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ 15 СТА 3/2011 www.cta.ru © СТА-ПРЕСС