Базовые понятия программного обеспечения реального времени

⇐ ПредыдущаяСтр 4 из 18Следующая ⇒

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

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

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

Любая ОС обязана обеспечить полный цикл жизни ПО: создание текста программы, ее компиляция, компоновка, отладка, исполнение, сопровождение. Задачи реального времени предъявляют требования к ОС, в которой реализовано ПО реального времени. Эти требования изложены в стандарте POSIX 1003.4 рабочего комитета IEEE. При решении задачи в СРВ выделяют 4 класса системной программной среды в соответствии с классами СРВ. Среда разработки и среда исполнения в СРВ могут быть разделены, а требования, предъявляемые к ним, весьма различны.

Требования, предъявляемые к среде исполнения СРВ:

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

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

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

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

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

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

Ядро может обеспечивать сервис пяти типов:

· Синхронизация ресурсов. Метод синхронизации требует ограничить доступ к общим ресурсам (данным и внешним устройствам).

· Межзадачный обмен.

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

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

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

Рис.1.8. Стандартные прикладные интерфейсы

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

На рис. 1.8 приведены интерфейсы и стандарты для приложений РВ.

Стоимость проекта любой СРВ определяется стоимостью ПО. Поэтому все больше внимания уделяется среде разработки программ. Более совершенные методы и средства разработки, отладки и поддержки прикладных программ позволяют их разработчикам производить более качественный программный продукт за меньшее время. Для разработки прикладных программ необходимы определенные средства: редакторы, компиляторы, компоновщики и отладчики. Символьные отладчики позволяют разработчику отлаживать исполняемую систему. Для проектирования и анализа СРВ существуют специальные методы, такие, как расширения Ward-Mellor к структурированному дизайну Иордана. Доступны и программные продукты, реализующие этот метод: DEC-дизайн (DEC) и TEAMWORK (Cadre).

Таблица 1.1

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

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

Мультипрограммирование в системах реального времени. В СРВ мультипрограммная смесь представляет набор разработанных предсказуемых программ. Выбор конкретной программы производится по прерываниям от объекта или в соответствии с планом.

Таблица 1.2

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

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

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

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

– описание параллельных процессов;

– переключение процессов на основе динамических приоритетов;

– синхронизация процессов;

– обмен данными между процессами;

– функции, связанные с часами и таймерами, абсолютное и относительное время ожидания;

– прямой доступ к внешним аппаратным портам;

– обработка прерываний;

– обработка исключений.

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

Программное обеспечение СРВ состоит из двух частей: системное и функциональное программное обеспечение. Системное программное обеспечение выполняется на низкоуровневых языках, близких к машинному. Для функционального программного обеспечения СРВ в методологию и CASE-средство Real включается поведенческая модель, позволяющая проектировать алгоритмы в стиле расширенных конечных автоматов (STD и SDL). При этом следует учитывать, что не существует наилучшего языка программирования в РВ, поскольку для каждого приложения и программно-аппаратной платформы необходимо подбирать свои средства (инструменты), учитывая квалификацию и предпочтения разработчиков.

Некоторые компании разрабатывали специальные языки для поддержки своих собственных аппаратных средств. Они не претендуют на универсальность и ориентированы на конкретные компьютеры и их интерфейсы. Обычно подобные языки базируются на существующих (FORTRAN, BASIC) с расширениями, включающими функции РВ, о чем свидетельствует их название типа «Process Basic» или «Real-Time Fortran». Некоторые языки не поддерживают программирование в РВ в строгом смысле, но они легко расширяются (С++). Гибкий механизм генерации обеспечит автоматическое преобразование алгоритмов в программу на целевом языке программирования.

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

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

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

Pascal и Modula 2. Эти языки предполагают, что программист постоянно остается в ограниченной среде, предоставленной программой, что совсем не соответствует реальной практике. Гибкость использования этих языков существенно выше, если программы для специальных приложений (обработчики прерываний, драйверы и др.) написаны на языке Assembler. Оба языка поддерживают подключение внешних модулей на Assembler, Pascal и Modula 2 являются хорошим средством для разработки встроенных систем, но не подходят для сложных приложений в распределенных компьютерных системах.

Асинхронный обмен данными

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

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

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

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

Маскируемые прерывания вызываются переходом в высокий уровень сигнала на входе INTR (Interrupt Request) при установленном флаге разрешения (IF=1). В этом случае процессор сохраняет в стеке регистр флагов, сбрасывает флаг IF и вырабатывает два следующих друг за другом (back to back) цикла подтверждения прерывания, в которых генерируются управляющие сигналы INTA# (Interrupt Acknowledge). Высокий уровень сигнала INTR должен сохраняться по крайней мере до подтверждения прерывания. Первый цикл подтверждения холостой, по второму импульсу внешний контроллер прерываний передает по шине номер вектора, обслуживающего данный тип аппаратного прерывания. Прерывание с полученным номером вектора выполняется процессором так же, как и программное. Обработка текущего прерывания может быть в свою очередь прервана немаскируемым прерыванием, а если обработчик установит флаг IF, то и другим маскируемым аппаратным прерыванием.

Немаскируемые прерывания выполняются независимо от состояния флага IF по сигналу NMI (Non Mascable Interrupt). Высокий уровень на этом входе вызовет прерывание с типом (вектором) 2, которое выполняется так же, как и маскируемое. Его обработка не может прерываться под действием сигнала на входе NMI до выполнения команды IRET. Обработка маскируемых прерываний может прерываться для обработки других прерываний, а не маскируемых не может.

⇐ Предыдущая 1 2 345 6 7 8 9 10 Следующая ⇒