Что такое программа реального времени?

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

Между программами реального времени и обычными последовательными про граммами с четко определенными входом и выходом имеются существенные различия. Некоторые проблемы, возникающие при использовании строго последователь­ной программы для управления параллельными по природе процессами, были описаны в разделе 2.1.

Ниже перечислены отличия программ реального времени от последовательных программ.

• Логика исполнения программы определяется внешними событиями.

• Программа работает не только с данными, но и с сигналами, поступающими из внешнего мира, например, от датчиков.

• Логика развития программы может явно зависеть от времени.

• Жесткие временные ограничения. Невозможность вычислить результат за опре­деленное время может оказаться такой же ошибкой, как и неверный результат ("правильный ответ, полученный поздно, — это неверный ответ").

• Результат выполнения программы зависит от общего состояния системы, и его нельзя предсказать заранее.

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

• Исполнение программы не заканчивается по исчерпании входных данных — она всегда ждет поступления новых данных.

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

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

10.6.2. Среда программирования

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

Разнообразие аппаратной среды отражается и в программном обеспечении, кото­рое включает в себя как программы, записанные в ПЗУ, так и комплексные операци­онные системы, обеспечивающие разработку и исполнение программ. В больших си­стемах создание и исполнение программ осуществляются на одной и той же ЭВМ, а в некоторых случаях даже в одно время. Небольшие системы могут не иметь средств разработки, и программы для них должны создаваться на более мощных ЭВМ с последующей загрузкой в исполняющую систему. То же касается и микро­программ, "зашитых" в ПЗУ оборудования производителем (firmware), — они разра­батываются на ЭВМ, отличной от той, на которой исполняются.

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

Важно как можно раньше выяснить функции, обеспечиваемые имеющейся средой, и возможные альтернативы. Например, микропроцессор Motorola 68000 имеет в своем наборе команд инструкцию testandset, и поэтому связь между задачами может осуществляться через общие области памяти. Операционная система VAX/VMS поддерживает почтовые ящики, и синхронизировать процессы можно с помощью механизма передачи сообщений. В UNIX и других операционных системах связь ДУ процессами наиболее удобно осуществлять через каналы. При разработке программ для среды UNIX следует стремиться, с одной стороны, максимально эффективно использовать ее особенности, например стандартную обработку входных и выходных данных, а с другой — обеспечить переносимость (portability) между разными версиями UNIX.

Из-за того что многозадачные системы и системы реального времени разрабатываются коллективами программистов, необходимо с самого начала добиваться ясности, какие методы и приемы используются.

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

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

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

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

10.6.3. Структура программы реального времени

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

Например, задачи для управления движением манипулятора робота (Р^а3' дел 2.2.3) можно организовать следующим образом:

- считать с диска описание траекторий;

- рассчитать следующее положение манипулятора (опорное значение);

- считать с помощью датчиков текущее положение;

- вычислить необходимый сигнал управления;

- выполнить управляющее действие;

- проверить, что опорное значение и текущее положение совпадают в пределах заданной точности;

- получить данные от оператора;

- остановить робота в случае нештатной ситуации (например сигнал прерывания от аварийной кнопки).

Другой пример приведен в разделе 2.1. Пресс для производства пластмассовых изделий контролируется двумя программами, управляемыми по прерыванию. При анализе стало ясно, что решение, основанное на применении только одной програм­мы, неприемлемо.

Принципиальной особенностью программ реального времени является постоянная готовность и отсутствие условий нормального, а не аварийного завершения. Если про­грамма не исполняется и не обрабатывает данные, она остается в режиме ожидания прерывания/события или истечения некоторого интервала времени. Программы ре­ального времени — это последовательный код, исполняющийся в бесконечном цикле. В каком-то месте программы есть оператор, приостанавливающий исполнение до на­ступления внешнего события или истечения интервала времени. Обычно программа структурируется таким образом, что оператор end никогда не достигается

while true do (* бесконечный цикл *) begin (* процедура обработки *)

wait event at #2,28 (* внешнее прерывание *)

(* код обработки *)

end; (* процедура обработки *) end. (* выход из программы; никогда не достигается *)

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

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

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

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

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

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