Густав Олссон, Джангуидо Пиани - Цифровые системы автоматизации и управления (1087169), страница 109
Текст из файла (страница 109)
В комп- лексной системс управления промышленными и технологическими процессами ма- кет одновременно использоваться все перечисленное оборудование (раздел 9,6). Разнообразие аппаратной среды отражается н в программном обеспечении, кото- Рое включает в себя как программы, записанные в ПЗУ, так и комплексные операци- онные системы, обеспечивающие разработку и исполнение программ. В больших си- стемах создание и исполнение программ осуществляются на одной и той же ЭВМ, з в некоторых случаях даже в одно время.
Небольшис системы могут не иметь средств разработки, и программы для них должны создаваться на более мощных ЗИМ с последующей загрузкой в исполняющую систему. То же касается и микро- пРограмм, "зашитых" в ПЗУ оборудования производителем (/(гтк1аге), — они разра- батываются на ЭВМ, отличной от той, на которой исполняются. Первой залачей программиста является ознакомление с программной средой и юступными инструментальными средствами.
Проблемы, с которыми приходится 'талкиваться, начинаются, например, с типа представления данных в аппаратуре и эрограммах, поскольку в одних системах применяется прямой, а в других — инверс- ный порядок хранения бит или байт в слове (младшие байты хранятся по старшим '"ресам). Таких тонкостей очень много, и опытный программист знает, как отделить 1дую структуру данных и код от технических деталей реализации в конкретной эапаратной среде.
Важно как можно раньше выяснить функции, обеспечиваемые имеющейся сре- 40Й, и ° и возможные альтернативы. Например, микропроцессор Магога!а 68000 имеет в свОем ем наборе команд инструкцию сеэ1 апс( зес, и поэтому связь между задачами ма- кет ос Подле "сушествляться через общие области памяти. Операционная система 11АХ/Ъ'МЯ держивает почтовые ящики, и синхронизировать процессы можно с помошью "ехани, иск ""зма передачи сообщений.
В ()МХ и других операционных системах связь эрог а ду процессами наиболее удобно осуществлять через каналы. При разработке рамь1 лля среды ()Х1Х следует стремиться, с одной стороны, максимально эф'ктивн вцхо, шно использовать ее осооенности, например стандартную обраоотку входных и д 1ь1х данных, а с другой — обеспечить переносимость (ро1таэ111гу) между разныиэ ' рсиями ()ы(Х Из-з ~ аютс„ .. за того что многозадачные системы и системы реального времени разрабатыся коллективами программистов, необходимо с самого начала добиваться ясно"",к какие методы и приемы используются.
1п б методы пРогРаммирования в реальном времени 445 эие функций операционной системы (вызовы ядра из приклалной програ, м, я стандартные средства). Помимо этого при программировании в реальном времеви используются методика мультипрограммирования и модель "клиент-сервер", поскольку отдельный процесс или поток обычно выполняют только некоторую амостоятельную часть всей задачи. 10.6 Методы пРогРаммирования в реальном времени Глава 10. Программирование систем реального врем~„ ни 447 Структурирование аппаратных и программных ресурсов, т.
е. присвоение адре на шине и приоритетов прерываний для интерфейсных устройств, имеет чрезвь,„ай но важное значение. Как упоминалось выше, неправильный порядок распределе„„„ ресурсов может привести к тупиковым ситуациям. Определение аппаратных адрес в и относительных приоритетов прерываний не зависит от разрабатываемой прогр мы.
Поэтому оно должно быть произведено на ранней стадии и зафиксировано в те ническом задании. Его не следует откладывать до момента непосредственного коди. рования, так как в этом случае неизбежны конфликты между программными модулями и возникает риск тупиковых ситуаций. Правильным практическим решением является использование в программе толь. ко логических имен для физического оборудования и его параметров и таблиц соот.
ветствия между ними и реальными физическими устройствами, При этом изменение адреса шины или приоритета устройства требует не модификации, а в худшем случае только новой компиляции программы. Разумно также использовать структуриро- ванное и организационно оформленное соглашение о наименовании системных ре- сурсов и программных переменных. То же о«носится и к наименованию и опрелеле- нию адресов удаленных устройств в распределенных системах.
Программы следует строить по принципам, применяемым в операционных систе- мах, — на основе модульной и многоуровневой структуры, поскольку это существенно упрощает разработку сложных систем. Должна быть определена спецификация от- дельных модулей, начиная с интерфейсов между аппаратными и программными ком- понентами системы. К основной информации об интерфейсах относится и структура сообщений, которыми будут обмениваться программные модули. Это не означает, что изменения в определении интерфейсов нс могут вводиться после начала разработки программы. Но чем позже они вносятся, тем больше затрат потребует изменение кода, тестирование и т.
д. С другой стороны, следует быть готовым к тому, что некоторые изменения спецификаций все равно будут происходить в процессе разработки про граммы, поскольку продвижение в работе позволяет лучше увидеть п)юблему. Следует принимать во внимание эффективность реализации функций операци. онной системы. Нельзя считать, что способ, которым в операционной системе реала зованы те или иныс услуги, дан раз и навсегда, — для проверки того, насколько хоро шо удовлетворяются временные ограничения, желательно провести опен . енку, например с помощью эталонных тестовых программ (Ьепслтаг«д).
Если результа™ тестов неприемлемы, то одним из решений может быть разработка программ, за , м, заме- шаюших соответствующие стандартные модули операционной системы. Такое Р е еше- ние требует очень осторожного и дифференцированного подхода, в частности сти заме Шение может выполняться не всегда, а только для определенных процессов. 10.6.3. Структура программы реального времени Разработка программы реального времени начинается с анализа и описан ия задачи. Функции системы де.лятся на простые части, с каждой из которых связ ываетсп программный модуль.
Например, задачи для управления движением манипулятора робота (Р' ' зз. дел 2.2.3) можно организовать следующим образом: — считать с диска описание траектории; — оассчнтать следующее положение манипулятора (опорное значение); — считать с помощью датчиков текущее положение; — вычислить необходимый сигнал управления. — выполнить управляющее действие; — проверить, что опорное значение и текундес положение совпадают в пределах заданной точности; — получить данные от оператора; - остановить робота в случае нештатной ситуации (например сигнал прерывания от аварийной кнопки).
Другой пример приведен в разделе 2.Е Пресс для производства пластмассовых пзделий контролируется двумя программами, управляемыми по прерыванию, П ию, ри «изливе стало ясно, что решение, основанное на применении только одной програмвы неприемлемо Принципиальной особенностью программ реального времени является постоянная ютовность и отсутствие условий нормального, а не аварийного завершения. Если программа не исполняется и не обрабатывает данные, она остается в режиме ожидания прерывания«события или истечения некоторого интервала времени. Программы рсапьного времени — это последовательный код, исполняюшийся в бесконечном цикле В каком-то месте программы есть оператор, приостанавливаюший исполнение до наступления внешнего события или истечения интервала времени.
Обычно программа пдрукгурируется таким образом, что оператор епй никогда не достигается дчЫе Дгце до (' бесконечный цикл *) Ьец(п (* процедура обработки *) ч а11 ечепг а1 ««2,28 (* внешнее прерывание *) (' код обработки *) епд(;(' процедура обработки ') епд(. (* выход из программы; никогда не достигается ') Пои аз анот р р работке кажлого программного модуля должны быть четко выделены обддсти, в кото ь торых происходит обращение к защищенным ресурсам, — критические секции. Вхо ив ход и выход из этих областей координируется каким-либо методом синхро- В днзации или ме и и межпрограммных коммуникаций, например с помощью семафоров.
общем сл чае, есл учае, если процесс находится в критической секции, можно считать, что данные, ското ыми орыми он работает, не изменяются каким-либо другим процессом. ПреДь!ванне исполнения п ия процесса не должно оказывать влияния на зашишеннгпе ресурц Этос снижает риск системных ошибок. Релосторожности неооходимо соблюдать и для потоков, порождаАналогичные п е 'Р процессы главного процесса. Разные потоки могут использовать ых как дочеоние п о« Шие переменные по о породившего их пропесса, и поэтому программист должен реять, за и ш шать зти переменные или нет. Рова Для гарантии жив ч вучести программы нештатные ситуации, которые могут блоки- вать или аваоийно пав Р о завершить процесс, должны своевременно распознаваться н ис— озможно — Р ах самой программы.
Этому посвящен слеавляться — если это возм - в амках ющий раздел. стемах реального времени раз«'н"ные процессы м б В си пдп о программам, При простейшем решении эти подпрограммы связываются с соот- 449 Глава 10. Программирование систем реального вр мепи ветствующими модулями после компиляции. При этом в памяти хранится неся „ илько копий одной подпрограммы. При другом подходе в память загружается лишь одна копия подпрограммы ы,по доступ к ней возможен из разных программ. Такие полпрограммы должны быть ть пп. вторно входимыми — реентерабельными (геепггапг), т.