Содержание к диссертации
Введение
1. Общая характеристика проблем отладки программного обеспечения АСУ ТП 8
1.1. Особенности проектирования ПО АСУ ТП 8
1.2. Анализ кроссовых систем автоматизации отладки ПО систем реального времени 10
1.3. Математическая модель АСУ ТП . 14
1.4. Общая характеристика кроссовой системы подготовки программ АСУ ТП 19
2. Проектирование иштатора АСУ ТП 24
2.1. Общие положения. Структура имитатора 24
2.2. Организация вычислительного процесса 31
2.3. Организация ввода-вывода 57
2.4. Взаимодействие программ имитатора 73
3. Лингвистическое обеспечение системы отладки 77
3.1. Общая характеристика языка описания внешней среды УВК 77
3.2. Описание информационных модулей. Каналы 78
3.3. Модуль конфигурации 87
3.4. Связь РВ- и ДП-программ 88
3.5. Имитационные модели технологического объекта управления 95
4. Реализация транслятора описания внешней среды УВК 100
4.1. Процессор семантического анализатора 100
4.2. Семантический процессор генерации выходных структур 108
4.3. Генерация сигналов в ДП-программах 117
5. Иллюстративный пример моделирования 123
5.1. Постановка задачи 123
5.2. Описание модели задачи СОИ 126
5.3. Моделирование задачи СОИ 129
Заключение , 132
Литература
- Анализ кроссовых систем автоматизации отладки ПО систем реального времени
- Организация вычислительного процесса
- Описание информационных модулей. Каналы
- Семантический процессор генерации выходных структур
Введение к работе
Создание систем автоматизированного проектирования программного обеспечения (ПО) вызвано насущной необходимостью повышения эффективности разработки систем реального времени. Все возрастающая сложность проектируемых систем управления,, с одной стороны, и повышение требований к срокам, стоимости и качеству разработки ПО, с другой стороны, неуклонно ведут к необходимости создания ПО АСУ на индустриальной основе.
Эффективным направлением для решения этой задачи является развитие кроссовых методов производства программ для АСУ, что позволяет проводить основные этапы подготовки ПО управляющего вычислительного комплекса на инструментальной ЭВМ организации-разработчика и снизить затраты.заключительных и наиболее трудоемких стадий внедрения ПО на объекте. Это качественное изменении в технологии проектирования ПО АСУ позволяет рассматривать разрабатываемый комплекс программ как продукт, производимый технологически отдельно от технических средств АСУ [4.IIJ . К этому продукту, как и к промышленному изделию, должны быть предъявлены требования по обеспечению надежности [9.IJ .„Известно, что отладка и испытание ПО систем реального времени составляют около Ъ0%, а с учетом сопровож-дения в эксплуатации до 80% і ['4.I3J общей стоимости его создания. Поэтому проверка работоспособности ПО на стадии разработки АСУ является крупной самостоятельной проблемой при создании сложных систем, в значительной степени определяющей осуществимость реализации системы в заданные сроки.
^ Применительно к АСУ технологическими процессами (АСУ ТП) решение этой сложной и вместе с тем актуальной проблемы состоит в том, что система отладки, входящая, в кроссовую систему автоматизированного проектирования ПО АСУ ТП, дожна позволять на инструментальной
ЭВМ с высокой степенью адекватности имитировать работу управляющего вычислительного комплекса (УВК) и сопряженного с ним технологического объекта управления (ТОУ)Л^
Разработчики кроссовых систем автоматизированного проектирования ПО АСУ ТПбюпользуютфазличные методы и средства для построения систем автоматической отладки7>выбор которых существенным образом отражается на эффективности отладки и, следовательно, на надежности проектируемого программного продукта^ В этом отношении пока нет устоявшихся решений.)Малоизученным остается также вопрос адекватного моделирования внешней среды синхронно с исполнением управляющих программ.
В диссертационной работе рассмотрен круг вопросов, связанных с выбором методов и средств построения кроссовой системы автоматизации отладки, позволяющей реализовать программные модели, соответствующие основным задачам проектирования АСУ ТП.^
диссертация состоит из 5-ти глав, списка литературы и приложений.
В первой главе дан сравнительный анализ методов и средств, положенных в основу построения систем отладки в известных кроссовых системах автоматизированного проектирования АСУ.^Предпочтение отдано методу использования высокого языкового уровня представления функционирования АСУ ТП, суть которого состоит в исполнении на инструметальной ЭВМ программ, совокупно представляющих.собой программный эквивалент модели УВК и сопряженного с ним ТОУ.Предложен способ реализации данного метода: от представления общей математической модели АСУ ТП и выработки требований к средствам построения системы отладки до реализации этих средств.
Во второй главе предложена и описана среда моделирования, в которой реализуется мультипрограммная обобщенная модель, эквивалентная исходной модели АСУ ТП. Дано описание языковых средств для
.-6-.
программирования алгоритмов управления и представления технических и операционных средств УВК.
В третьей и четвертой главах предложены и исследованы языковые средства для представления внешней среды УВК и их программная реализация.
В пятой главе приведены экспериментальные исследования на примере моделирования внешней среды в АСУ ТП "Химия",
В приложениях приведены формальные спецификации языков, некоторые результаты моделирования и материалы внедрения результатов исследований.
На защиту выносится следующее:
метод создания кроссовой системы автоматизации отдалки, заключающийся в формализации модели АСУ ТП соответствующими языковыми средствами и формулировании требований к программному и технологическому обеспечению системы отладки для обобщенной мультипрограммной модели АСУ ТП;
мультипрограммная модель операционной системы УВК с учетом интерфейсов с моделями функциональных программ УВК и.информационного представления технологического объекта управления;
разработка и реализация лингвистических средств описания технологического объекта управления, включающих возможность моделирования замкнутого контура управления.
Основные результаты исследований, проведенных автором на кафедре вычислительной техники Киевского политехнического института, опубликованы в 6 работах. Система кроссовой подготовки программ, система отладки которой рассмотрена в диссертации, передана в Гос ФАП в 1984 г. Результаты докладывались на П Всесоюзном совещании . "Автоматизация проектирования и конструирования (Ленинград, 1983 г.), на Всесозной конференции "индустриализации,проектирования математического обеспечения АСУ ТП" (Киев, 1983 г.),на Всесоюзной конференции "Повышение эффективности и качества разработки программ-
- 7 -ного обеспечения АСУ ТП на основе использования типовых решений и средств автоматизации программирования и отладки" (Киев, 1984 г.), на УІ Межреспубликанской школе-семинаре "Интерактивные системы" (Батуми, 1984 г.).
Анализ кроссовых систем автоматизации отладки ПО систем реального времени
В известных кроссовых системах автоматизации проектирования программного .обеспечения применяются различные способы построения систем.автоматизации отладки, что обуславливает различие их возмож ностей.
В системах ЯУЗА-6 [5.12] , ТЕМП [ 5.14] , СИНГЕРМ [б.і] , реали зованных на БЭСМ-6, в системе РУЗА, реализованной на ЕС ЭВМ, моделирование вычислительного процесса осуществляется на уровне интерпретации системы команд управляющей ЭВМ. Недостатком этого метода является то, что практически невозможно моделировать покомандное исполнение.функциональных программ в операционном окружении управляющей ЭВМ. Замедление выполнения на технологической ЭВМ тестируемых программ в режиме покомандной интерпретации получается от 100 до 5000 раз Г5.26J Из-за ограничения, которое метод покомандной интерпретации накладывает на возможность моделирования вычислительного процесса, динамическая комплексная отладка (с учетом реального масштаба времени), проводится с использованием управляющей ЭВМ (рис. I.I). Кроссовая система отладки в этих системах, таким образом , не обеспечивает полного цикла проверки ПО. Использование физической управляющей ЭВМ в качестве "рабочей модели" не соответствует принципам индустриального производства готового программного продукта кроссовыми методами, которые позволяют сокращать сроки разработки благодаря параллельному созданию комплекса технических средств (КТО АСУ ТП и программного обеспечения и которые дают возможность отладки и получения комплекса программ в условиях недоступности объектного УВК, что весьма актуально в связи с тенденцией широкого использования микропроцессорной техники в качестве УВК.
Для преодоления недостатка, свойственного методу.покомандной интерпретации, предложено несколько.методов, например, использование " открытых" подпрограмм.[б.17] , табличный метод определения значения функций [б.б] и др. "Открытые" подпрограммы обеспечивают значительное ускорение выполнения отлаживаемой программы, но их недостатками являются сложность отладки в терминах исходного языка и недостаточная детальность моделирования аппаратуры (увеличение детальности моделирования естественно уменьшает скорость выполнения),которая необходима в условиях параллельной работы ПО и аппара туры управляющей ЭВМ.
В системе СЕРП [5.19] используется метод отладки и тестирован ния моделей ПО управляющей ЭВМ комбинированным применением функционально эквивалентных модулей (ФЭМ) и модулей в языке управляющей ЭВМ [5.6 1 . ФЭМ получаются путем автоматической перетрансляции как модулей операционной системы объектной машины, так и уже отлаженных модулей ПО с языка Ассемблера управляющей ЭВМ в язык технологической ЭВМ. ФЭМ создают среду отладки для тестируемого модуля, который выполняется в режиме интерпретации. Применением ЗШ достигается значительное ускорение выполнения программы объектной ЭВМ по і сравнению с разными методами интерпретации.
К недостаткам системы отладки в СЕРП следует отнести недостатки, свойственные стратегии тестирования программы "снизу-вверх", принятой в СЕРП. Эта стратегия реализуема в иерархической системе при отсутствии взаимных связей. Из рис. 1.2. видно, что если между модулями В и С отсутствует связь или существует только связь АС, то все модули и, следовательно, вся программа могут быть отлажены. Для второго случая сначала должен подлежать отладке модуль В, а потом С.
При добавлении к ВС еще связи СВ модули В и С (и программа в целом)согласно стратегии снизу вверх невозможно отладить, т.к. средой отладки тестируемого модуля должны быть уже отлаженные модули. Следовательно, этот метод реализации программы создает ограничения на декомпозицию программы.
Представленная на рис 1.3. общая схема кроссовой отладки ПО АСУ ТП не содержит принципиальных ограничений для проведения полного цикла отладки, включая комплексную динамическую отладку.
.В основу разработки системы моделирования программ (СМП) [б.2, 12.1, 12.2] , представляющей кроссовую систему получения функционального ПО АСУ ТП, был положен метод воспроизведения вычислительного процесса с использованием высокого языкового уровня представления модели УВК на инструментальной ЭВМ.
Программы на языке описания алгоритмов и программы на языке описания внешней среды УВК транслируются в ПЛ-эквивалентные модули, совокупно образующие модельный уровень или среду моделирования на инструментальной ЭВМ. Возможность совместного исполнения программ на модельном уровне позволяет проводить комплексную динамическую отладку. Отлаженные программы с языка описания алгоритмов транслируются на Ассемблер управляющей ЭВМ. К недостаткам СМП, версия которой описана в [І2.2І, следует отнести отсутствие средств, позволяющих имитировать исполнение функциональных программ в мультипрограммной операционной среде управляющей ЭВМ, и невозможность адекватного представления внешней среды из-за слаборазвитости языка описания внешней среды, отсутствия модульности и т.п. Достоинством данного метода отладки является отсутствие ограничений, свойственных методу покомандной интерпретации.
Организация вычислительного процесса
Обмен данными со стандартными устройствами УВК«моделируется в имитаторе соответствующими операторами ввода-вывода языка ПЛ/І.
В ДОС АСПО пользователь на языке макрокоманд генерации операционных систем записывает требования к создаваемой конкретной операционной системе. Он указывает ее тип, описывает конфигурацию вычислительного комплекса и системы ввода-вывода, определяет необходимые модули супервизора и средства связи с оператором системы.
На модельном уровне программные и информационные средства ДОС АСПО моделирзгются с учетом генерации выбранной версии операционной системы. Генерация конфигурации ДОС АСПО отражается в-задании определенных констант, используемых с помощью макросредств ШГ/І% ШьІШ в различных постоянных модулях имитатора. Эти константы (как ПЛ/І-операторы присваивания) генерируются транслятором ГС - ПЛ/І.
Программа-супервизор моделирования #SUPER выполняет функции главного планировщика, обеспечивая интерфейс между пользователем (оператором) и обобщенной моделью АСУ ТП с помощью директив языка управления моделированием (ЯУМ) и команд оператора.
Технология генерации имитатора показана на рис.2.4. Написанные разработчиками постоянные модули имитатора транслируются в объектную библиотеку ПЛ-компилятором. При этом на этапе препроцессорной обработки предварительно полученные ПЛ-тексты на выходе транслятора ГС-Ш включаются по % INCLUDE в соответствующие исходные модули и затем транслируются. Загрузочный (исполняемый на ЭВМ) модуль - имитатор создается из объектных модулей с включением предварительно полученных модулей
В результате выполнения загрузочного модуля пользователь взаимодействует с моделью, вводя с помощью директив данные и команды элератора и получая промежуточные и конечные результаты моделирования (отладки).
Структура модуля ф TCP (в программном представлении) изображена на рис. 2.5. Модуль имеет две стандартные точки входа:# TCP -для начальных установок, $PRS- для основного входа в процессы (задачи). Модуль состоит из совокупности помеченных блоков btblN , являющихся ПЛ-эквивалентами РВ-процессов. Каждый блок состоит из совокупности помеченных групп ПЛ-операторов, где одна или несколько групп составляют эквивалент РВ-оператора. Переход к определенному процессу (блоку) происходит по номе ру задачи (внешняя переменнаяff J\l иК ) при выполнении переключате ля SQTQ шмстзк) после вхождения в . Переход на ис полнение определенного оператора в блоке производится по номеру метки-, задаваемой параметром Ігпо 11 і при выполнении локального пе реключателя , расположенного в начале каждого блока. Все данные о задаче находятся в блоке управления задачей (#ТСВ), структура которого изображена на рис. 2.6. Приоритет РТ представляет целое в диапазоне 0 32767, указываемое в заголовке процесса конструкцией pzio?iti/ ( целое ). По умолчанию РТ=99. Состояние программы кодируется следующим образом: 1 - выполнение, 2 - ожидание события, 3.- приостановка ( PAUSE), 4.- ожидание запуска по времени-, 5 - ожидание запуска из другой задачи или командой оператора. Ожидание события означает выполнение программой РВ-оператора і СО или waitm fc.?...»). Ожидание запуска по времени производится в тех случаях, если заголовок процесса содержит непустую характеристику запуска (либо эта информация передана оператором
Описание информационных модулей. Каналы
Как уже указывалось, специфика отладки программ УВК заключается в необходимости создания модели среды функционирования УВК в составе АСУ ТП, с помощью которой можно создавать соответствующий поток исходных данных, поступающих от объекта через УСО, и реагировать на управляющие сигналы, поступающие от УВК на объект в реальном (или модельном) времени. При этом можно считать, что РВ-прог-рамма определенным образом моделирует сам УВК.
Следует также учитывать, что в отличие от универсальных ЭВМ, в реальной АСУ ТП конфигурация технических и операционных средств должна быть оптимальной для реализации в общем случае фиксированного набора задач управления и, следовательно, в круг проблем отладки входит проверка соответствия имеющихся технических и операционных ресурсов УВК требованиям исполнения прикладных программ АСУ ТП. В условиях кроссовых средств подготовки ПО АСУ ТП это означает наличие в системе соответствующих описаний конфигураций технических и операционных средств УВК, УСО и объекта.
Ниже рассмотрен специальный проблемно-ориентированный язык ДП (динамическое Представление объекта), предназначенный для описания конфигурации технических средств связи УВК с объектом и информации, поступающей от объекта через УСО. В язык введены средства сопряжения с языком ПЛ/1, которые позволяют представлять произвольные алгоритмы имитационных моделей объектов. Ранняя версия аналогичного по целям, но качественно отличного языка ДП исследовалась в работе [б. 2].
Язык ДП имеет модульную структуру, где основными единицами независимой трансляции являются: - модуль связи; - модуль конфигурации; - кадр; - канальный модуль.
Модуль конфигурации составляется для конкретной конфигурации технических средств связи УВК с объектом (УСО) и содержит информацию об адресах подключения датчиков и исполнительных механизмов объекта и их характеристиках (диапазоны значений и т.п.).
Кадр является основной программной единицей и содержит описание информации, поступающей по каналам связи с объектом в виде произвольных функций времени. Аргументы этих функций могут поступать от оператора в сеансе совместного моделирования, а также от ПЛ-мо-дели объекта.
В связи с возможной громоздкостью описания объекта для больших АСУ ТП, отдельные группы каналов могут быть описаны отдельно в виде канального модуля. Если кадр считается главной программой, то канальные модули представляют собой подпрограммы, вызываемые кадром. Кадр и канальные модули являются информационными модулями с точки зрения задания информации по каналам.
Объединение модуля конфигурации, кадра и канального модуля производится модулем связи.
Описание кадра имеет следующую синтаксическую конструкцию (см. приложение 2): кадр : := snap масштаб заголовок ; список-каналов Кадр имеет заголовок, аналогичный процедуре, а также указанный масштаб изменения модельного времени (час, минута, секунда, десятки милисекунд). Если заголовок кадра содержит параметры (используемые в выражениях), то соответствующие фактические параметры задаются с помощью специальной директивы моделирования (см. п. 2.4). Пример: snap sec dPA(U,V,Z) ; М II V, Z - параметры моделирования Й/ # \ список каналов end
Вызов (т.е. подключение к кадру) канальных модулей произво дится конструкцией, названной макроканалом. Синтаксис канального модуля следующий: канальный-модуль : \-chanm заголовок -; список-каналов , Пример: еп(/ф ckanm dPb(Zl); список каналов « end # Таким образом, канальный модуль отличается от кадра только отсутствием масштаба, который сохраняется для него от вызывающего кадра. Описание кадра и канального модуля определяет список каналов обмена с УСО, по которым в РВ-программе предусмотрен обмен операторами obtain . zeceiveт send. В языке ДП задаются три вида каналов: - канал ввода, - канал вывода, - макроканал.
Семантический процессор генерации выходных структур
Выбор средств, обеспечивающих реализацию семантического процессора, структура которого показана на рис 4.4, в значительной степени определяется выходом, получаемым в результате трансляции ДП-программ.
В первой главе было отмечено, что на модельном уровне таким результатом является обобщенный ПЛ/1-эквивалентный модуль #/?0A/F (рис. 4.5). Функцию объединения порознь пртранслированных ДП-программ в выходной программе выполняет модуль связи. Одним из средств объединения является генерация препроцессорных утвержденнйХшСШ! в ПЛ/1-эквиваленте модуля связи.
Структура ПЛ/1-эквивалента модуля связи, представленного на языке ДП, показана на рис. 4.6. modilte [ISO j / модуль конфигурации «/ Dr/1 /Й модуль - кадр Й/ DPS /Й канальный модуль Й/ end # Выписывание выходного -текста при трансляции модуля связи осуществляется при обходе соответствующего поддерева программой МОдВ семантического процессора. Вначале генерируется текст, содуржащий описания переменных.(в частности системное вреш), входных точек, внутренних процедур. Затем генерируются операторы Жда с помощью которых при ШІ-компиляции подключаются генерируемые тексты из библиотеки (в данной реализации -ВІЙН), являющиеся результатом трансляции ДП-программ, в данном случае - модуля конфигурации изо, кадра ЭРА. , канального модуля
ПЛ-текст, получаемый в результате семантической обработки поддерева І модуль-конфигурации программой CON г , содержит: - входную точку wvr, к которой производится обращение из #SUPER ( см. п. 2.3) по директиве моделирования "установка конфигурации" для назначения элементам таблицы #ТС значений, заданных в описании модуля конфигурации; - описание таблицы сигналов #ТС, структура которой изображена на рис. 4.8; - последовательность операторов присваивания значений элементам таблицы # ТС.
Назначение элементов SiV.LN .АР ЛЪ MB М видно из описания модуля конфигурации (см. п. 3.3). Назначение других элементов следующее: ТР - тип сигнала ( О1 В - входной, Iі В - выходной ), ID - индекс в переключателе функций, по которым вычисляются значения сигналов ( 0 - индекс в переключателе в кадре, 0 -индекс переключается в канальном модуле, 0 - датчик не задействован) , CN - имя кадра или канального модуля, в котором находится сигнал, 1НС- индекс для переключателя для макроканала ( 0 - для кадра, 0 - для канального модуля). Следует отметить, что при ДП-трансляции модуля конфигурации
Семантическую обработку поддерева кадр выполняет программа Sfl/JP . При первом обходе поддерева ПЛ-текот содержит: - установку масштабного коэффициента #CFF- значения, соответ ствующего масштабу, заданному в кадре. Величина устанавливается в десятках милисекунд; - передачу управления программе Lnh для генерации проверки корректности кадра и присваивания значений таблицы сигналов #ТС; - обращение в канальному модулю (при трансляции макроканала) для проверки корректности.
При втором обходе дерева генерируется: - точка входа установки параметров кадра #8ЕТР , производимая по соответствующей директиве моделирования (см. п. 2.4); - точка основного входа кадра W ШАР , где параметрами при обращении к ней являются логический номер и точка подключения сигнала; - вычисление текущего относительного времени Иг TMV; - алгоритм выбора переключателя для вычисления значения сигнала. При значении индекса 1ND .для данного сигнала больше нуля осуществляется переход по индексу; при значении меньше нуля,происходит переход на метку, индекс которой равен значению IN О ; - вызов программы CNL для генерации переключателя (вызов программы ШСН для генерации алгоритма вычисления значения сиг
Похожие диссертации на Автоматизация отладки мультипрограммных систем реального времени
