Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
_МУ_АСУиП.doc
Скачиваний:
2
Добавлен:
01.03.2025
Размер:
3 Мб
Скачать
☆

Требования к языкам рв

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

  1. Описание параллельных процессов;

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

  3. Синхронизация процессов;

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

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

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

  7. Обработка прерываний;

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

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

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

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

Структура программ срв

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

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

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

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

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

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