Лекции по дисциплине системы реального времени тема аппаратнопрограммные средства и комплексы реального времени
 Скачать 1.67 Mb.
|
|
ТЕМА 4. ОСОБЕННОСТИ ПРОГРАММИРОВАНИЯ СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ Лекция 4.1. Методы программирования в реальном времени. 1. Последовательное программирование и программирование задач реального времени 2. Среда программирования. 3. Структура программы реального времени. 4. Параллельное программирование, мультипрограммирование и мно- гозадачность. 1. Последовательное программирование и программирование задач реального времени Программа представляет собой описание объектов - констант и пере- менных - и операций, совершаемых над ними. Таким образом, программа - это чистая информация. Ее можно записать на какой-либо носитель, напри- мер на бумагу или на дискету. Программы можно создавать и анализировать на нескольких уровнях абстракции (детализации) с помощью соответствующих приемов формально- го описания переменных и операций, выполняемых на каждом уровне. На самом нижнем уровне используются непосредственное описание - для каж- дой переменной указывается ее размер и адрес в памяти. На более высоких уровнях переменные имеют абстрактные имена, а операции сгруппированы в функции или процедуры. Программист, работающий на высоком уровне аб- стракции, не должен думать о том, по каким реальным адресам памяти хра- нятся переменные, и о машинных командах, генерируемых компилятором. Последовательное программирование (sequential programming) является наиболее распространенным способом написания программ. Понятие "последовательное" подразумевает, что операторы программы выполняются в известной последовательности один за другим. Целью последовательной программы является преобразование входных данных, заданных в определенной форме, в выходные данные, имеющие другую форму, в соответствии с некоторым алгоритмом - методом решения (рис. 1). Рисунок 1. - Обработка данных последовательной программой Таким образом, последовательная программа работает как фильтр для исходных данных. Ее результат и характеристики полностью определяются входными данными и алгоритмом их обработки, при этом временные показа- тели играют, как правило, второстепенную роль. На результат не влияют ни инструментальные (язык программирования), ни аппаратные (быстродейст- вие ЦП) средства: от первых зависят усилия и время, затраченные на разра- 124 ботку и характеристики исполняемого кода, а от вторых - скорость выполне- ния программы, но в любом случае выходные данные будут одинаковыми. Программирование в реальном времени (real-time programming) от- личается от последовательного программирования - разработчик программы должен постоянно иметь в виду среду, в которой работает программа, будь то контроллер микроволновой печи или устройство управления манипулятором робота. В системах реального времени внешние сигналы, как правило, требуют немедленной реакции процессора. В сущности, одной из наиболее важных особенностей систем реального времени является время реакции на входные сигналы, которое должно удовлетворять заданным ограничениям. Специальные требования к программированию в реальном времени, в частности необходимость быстро реагировать на внешние запросы, нельзя адекватно реализовать с помощью обычных приемов последовательного про- граммирования. Насильственное последовательное расположение блоков программы, которые должны выполняться параллельно, приводит к неесте- ственной запутанности результирующего кода и вынуждает связывать между собой функции, которые, по сути, являются самостоятельными. В большин- стве случаев применение обычных приемов последовательного программирования не позволяет построить систему реального времени. В таких системах независимые программные модули или задачи должны быть активными одновременно, то есть работать параллельно, при этом каждая задача выполняет свои специфические функции. Такая техника известна под названием параллельного программирования (concurrent programming). В названии делается упор на взаимодействие между отдельными программными модулями. Параллельное исполнение может осуществляться на одной или нескольких ЭВМ, связанных распределенной сетью. Программирование в реальном времени представляет собой раздел мультипрограммирования, который посвящен не только разработке взаимо- связанных параллельных процессов, но и временным характеристикам сис- темы, взаимодействующей с внешним миром. Между программами реального времени и обычными последователь- ными программами, с четко определенными входом и выходом, имеются су- щественные различия. Перечислим отличия программ реального времени от последовательных программ: 1. Логика исполнения программы определяется внешними событиями. 2. Программа работает не только с данными, но и с сигналами, посту- пающими из внешнего мира, например, от датчиков. 3. Логика развития программы может явно зависеть от времени. 4. Жесткие временные ограничения. Невозможность вычислить результат за определенное время может оказаться такой же ошибкой, как и неверный результат ("правильный ответ, полученный поздно - это неверный ответ"). 5. Результат выполнения программы зависит от общего состояния сис- темы, и его нельзя предсказать заранее. 125 6. Программа, как правило, работает в многозадачном режиме. Соот- ветственно, необходимы процедуры синхронизации и обмена данными меж- ду процессами. 7. Исполнение программы не заканчивается по исчерпании входных данных - она всегда ждет поступления новых данных. Важность фактора времени не следует понимать как требование высо- кой скорости исполнения программы. Скорость исполнения программы ре- ального времени должна быть достаточной для того, чтобы в рамках уста- новленных ограничений реагировать на входные данные и сигналы и выраба- тывать соответствующие выходные величины. "Медленная" система реаль- ного времени может великолепно управлять медленным процессом. Поэтому скорость исполнения программ реального времени необходимо рассматри- вать относительно управляемого процесса или необходимой скорости. Ти- пичные приложения автоматизации производственных процессов требуют гарантированное время ответа порядка 1 мс, а в отдельных случаях - порядка 0.1 мс. При программировании в реальном времени особенно важными явля- ется эффективность и время реакции программ. Соответственно, разработка программ тесно связана с параметрами операционной системы, а в распреде- ленных системах - и локальной сети. Особенности программирования в реальном времени требуют специ- альной техники и методов, не использующихся при последовательном про- граммировании, которые относятся к влиянию на исполнение программы внешней среды и временных параметров. Наиболее важными из них являют- ся перехват прерываний, обработка исключительных (нештатных) ситуаций и непосредственное использование функций операционной системы (вызовы ядра из прикладной программы, минуя стандартные средства). Помимо этого при программировании в реальном времени используются методика мульти- программирования и модель "клиент-сервер", поскольку отдельный процесс или поток обычно выполняют только некоторую самостоятельную часть всей задачи. 2. Среда программирования Рассмотрим среду, в которой исполняются программы. Среда выпол- нения может варьироваться от мини-, персональных и одноплатных микрокомпьютеров и локальных шин, связанных с окружающей средой через аппаратные интерфейсы, до распределенных систем "клиент-сервер" с централизованными базами данных и доступом к системе высокопроизводительных графических рабочих станций. В комплексной системе управления промышленными и технологическими процессами может одновременно использоваться все перечисленное оборудование. Разнообразие аппаратной среды отражается и в программном обеспе- чении, которое включает в себя как программы, записанные в ПЗУ, так и комплексные операционные системы, обеспечивающие разработку и испол- нение программ. В больших системах создание и исполнение программ осу- ществляются на одной и той же ЭВМ, а в некоторых случаях даже в одно время. Небольшие системы могут не иметь средств разработки, и программы 126 для них должны создаваться на более мощных ЭВМ с последующей загруз- кой в исполняющую систему. То же касается и микропрограмм, "зашитых" в ПЗУ оборудования производителем (firmware), - они разрабатываются на ЭВМ, отличной от той, на которой исполняются. Первой задачей программиста является ознакомление с программной средой и доступными инструментальными средствами. Проблемы, с которы- ми приходится сталкиваться, начинаются, например, с типа представления данных в аппаратуре и программах, поскольку в одних системах применяется прямой, а в других - инверсный порядок хранения бит или байт в слове (младшие байты хранятся в старших адресах). Таких тонкостей очень много, и опытный программист знает, как отделить общую структуру данных и код от технических деталей реализации в конкретной аппаратной среде. Важно как можно раньше выяснить функции, обеспечиваемые имею- щейся средой, и возможные альтернативы. Например, микропроцессор Mo- torola 68000 имеет в своем наборе команд инструкцию test_and_set, и поэто- му связь между задачами может осуществляться через общие области памя- ти. Операционная система VAX/VMS поддерживает почтовые ящики, и син- хронизировать процессы можно с помощью механизма передачи сообщений. В UNIX и других операционных системах связь между процессами наиболее удобно осуществлять через каналы. При разработке программ для среды UNIX следует стремиться, с одной стороны, максимально эффективно использовать ее особенности, например стандартную обработку входных и выходных данных, а с другой - обеспечить переносимость между разными версиями UNIX. Из-за того, что многозадачные системы и системы реального времени разрабатываются коллективами программистов, необходимо с самого начала добиваться ясности, какие методы и приемы используются. Структурирование аппаратных и программных ресурсов, то есть при- своение адресов на шине и приоритетов прерываний для интерфейсных уст- ройств, имеет важное значение. Неправильный порядок распределения ре- сурсов может привести к тупиковым ситуациям. Определение аппаратных адресов и относительных приоритетов прерываний не зависит от разрабаты- ваемой программы. Поэтому оно должно быть произведено на ранней стадии и зафиксировано в техническом задании. Его не следует откладывать до мо- мента непосредственного кодирования, так как в этом случае неизбежны конфликты между программными модулями и возникает риск тупиковых си- туаций. Правильным практическим решением является использование в про- грамме только логических имен для физического оборудования и его пара- метров и таблиц соответствия между ними и реальными физическими уст- ройствами. При этом изменение адреса шины или приоритета устройства требует не модификации, а в худшем случае только новой компиляции про- граммы. Разумно также использовать структурированное и организационно оформленное соглашение о наименовании системных ресурсов и программ- 127 ных переменных. То же относится и к наименованию и определению адресов удаленных устройств в распределенных системах. Программы следует строить по принципам, применяемым в операци- онных системах, - на основе модульной и многоуровневой структуры, поскольку это существенно упрощает разработку сложных систем. Должна быть определена спецификация отдельных модулей, начиная с интерфейсов между аппаратными и программными компонентами системы. К основной информации об интерфейсах относится и структура сообщений, которыми будут обмениваться программные модули. Это не означает, что изменения в определении интерфейсов не могут вводиться после начала разработки про- граммы. Но чем позже они вносятся, тем больше затрат потребует изменение кода, тестирование и т. д. С другой стороны, следует быть готовым к тому, что некоторые изменения спецификаций все равно будут происходить в про- цессе разработки программы, поскольку продвижение в работе позволяет лучше увидеть проблему. Следует принимать во внимание эффективность реализации функций операционной системы. Нельзя считать, что способ, которым в операционной системе реализованы те или иные услуги, дан раз и навсегда. Для проверки того, насколько хорошо удовлетворяются временные ограничения, желатель- но провести оценку, например с помощью эталонных тестовых программ. Если результаты тестов неприемлемы, то одним из решений может быть раз- работка программ, замещающих соответствующие стандартные модули опе- рационной системы. Такое решение требует очень осторожного и дифферен- цированного подхода, в частности замещение может выполняться не всегда, а только для определенных процессов. 3. Структура программы реального времени Разработка программы реального времени начинается с анализа и опи- сания задачи. Функции системы делятся на простые части, с каждой из кото- рых связывается программный модуль. Например, задачи для управления движением манипулятора робота можно организовать следующим образом: – считать с диска описание траекторий; – рассчитать следующее положение манипулятора (опорное значение); – считать с помощью датчиков текущее положение; – вычислить необходимый сигнал управления; – выполнить управляющее действие; – проверить, что опорное значение и текущее положение совпадают в пределах заданной точности; – получить данные от оператора; – остановить робота в случае нештатной ситуации (например, сигнал прерывания от аварийной кнопки). Принципиальной особенностью программ реального времени является постоянная готовность и отсутствие условий нормального, а не аварийного завершения. Если программа не исполняется и не обрабатывает 128 данные, она остается в режиме ожидания прерывания/события или истечения некоторого интервала времени. Программы реального времени - это последовательный код, исполняющийся в бесконечном цикле. В каком-то месте программы есть оператор, приостанавливающий ис- полнение до наступления внешнего события или истечения интервала време- ни. Обычно программа структурируется таким образом, что оператор end никогда не достигается while true do (*бесконечный цикл*) begin (*процедура обработки*) wait event at #2,28 (*внешнее прерывание*) (*код обработки*) … end; (*процедура обработки*) end. (*выход из программы; никогда не достигается*) При разработке каждого программного модуля должны быть четко выделены области, в которых происходит обращение к защищенным ресурсам, - критические секции. Вход и выход из этих областей координируется каким-либо методом синхронизации или межпрограммных коммуникаций, например с помощью семафоров. В общем случае, если процесс находится в критической секции, можно считать, что данные, с которыми он работает, не изменяются каким-либо другим процессом. Прерывание исполнения процесса не должно оказывать влияния на защищенные ресурсы. Это снижает риск системных ошибок. Аналогичные предосторожности необходимо соблюдать и для потоков, порождаемых как дочерние процессы главного процесса. Разные потоки могут использовать общие переменные породившего их процесса, и поэтому программист должен решить, защищать эти переменные или нет. Для гарантии живучести программы нештатные ситуации, которые могут блокировать или аварийно завершить процесс, должны своевременно распознаваться и исправляться - если это возможно - в рамках самой про- граммы. В системах реального времени различные процессы могут обращаться к общим подпрограммам. При простейшем решении эти подпрограммы свя- зываются с соответствующими модулями после компиляции. При этом в па- мяти хранится несколько копий одной подпрограммы. При другом подходе в память загружается лишь одна копия подпро- граммы, но доступ к ней возможен из разных программ. Такие подпрограм- мы должны быть повторно входимыми - реентерабельными (reentrant), то есть допускать многократные вызовы и приостановку исполнения, которые не влияют друг на друга. Эти программы должны использовать только реги- стры процессора или память вызывающих процессов, то есть не иметь ло- кальных переменных. В результате реентерабельный модуль, разделяемый несколькими процессами, можно прервать в любое время и продолжить с другой точки программы, поскольку он работает со стеком вызвавшего его процесса. Таким образом, реентерабельная процедура может оказаться одно- временно в контексте нескольких различных процессов. Эффективность исполнения является одним из наиболее важных пара- метров систем реального времени. Процессы должны выполняться быстро, и 129 часто приходится искать компромисс между ясностью и структурированностью программы и ее быстродействием. Жизненный опыт показывает, что если для достижения цели нужно чем-то пожертвовать, что обычно и делается. Не всегда возникает противоречие между структурностью и эффективностью, но если первое должно быть принесено в жертву второму, необходимо полностью документировать все принятые решения, иначе существенно осложняется дальнейшее сопровождение программы. 4. Параллельное программирование, мультипрограммирование и мно- гозадачность Программирование в реальном времени требует одновременного ис- полнения нескольких процессов или задач на одной ЭВМ. Эти процессы ис- пользуют совместно ресурсы системы, но более или менее независимы друг от друга. Мультипрограммирование (multiprogramming) или многозадачность (multitasking) есть способ одновременного исполнения нескольких процес- сов. Такого эффекта можно добиться как для одного, так и для нескольких процессоров: процессы исполняются либо на одном, либо на нескольких свя- занных между собой процессорах. В действительности многие современные вычислительные системы состоят из нескольких процессоров, связанных ме- жду собой либо сетью передачи данных, либо общей шиной. Для записи параллельных процессов можно использовать следующую нотацию cobegin х := 1; х := 2; х := 3; coend; write (x); Исполнение команд между ключевыми словами cobegin и coend про- исходит параллельно (рис. 2). Пара операторных скобок cobegin-coend приводит к генерации потоков в рамках многозадачной системы. Оператор cobe-gin не накладывает условий на относительный порядок исполнения отдельных процессов, а оператор coend достигается только тогда, когда все процессы внутри блока завершены. Если бы исполнение было последовательным, то окончательное значение переменной х было бы равно 3. Для параллельных процессов конечный результат однозначно предсказать нельзя; задачи выполняются, по крайней мере, с внешней точки зрения, в случайной последовательности. Поэтому окончательное значение х в приведенном примере может быть как 1, так и 2 или 3. |