Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
ПРЕДИСЛОВИЕ
Утаеттптое ретлетше поставленных XXVII съездовJ?IIC1C^задач автсь матизацип производственных процессов зависит от своевременного ^создания программного обеспечения разрабатываемых промышленностью автоматических систем на базе микро-ЭВМ. Значимость программного обеспечения в настоящее время определяется следующими факторами:
требованиями гибкости и простоты переналаживаемости автоматизированного производства при изменении объема или номенклатуры выпускаемой продукции, а также при изменении конфигурации оборудования;
архитектурой вычислительных управляющих устройств и терминального оборудования, используемых в составе систем управления автоматических производств, предполагающих обязательное наличие программных средств для объединения элементов оборудования в единую систему;
использованием микропроцессорной элементной базы, требующей разработки микропрограмм и программ для формирования необходимых функциональных характеристик;
.необходимостью адаптации средств автоматизированного производства к неопределенностям производственного процесса, связанным с начальным расположением обрабатываемой детали и погрешностями работы технологического оборудования.
Сложность современных систем программного обеспечения автоматических производств настолько велика, что его стоимость и трудоемкость создания превышают стоимость и трудоемкость разработки аппаратуры в несколько раз. Это вызывает необходимость рассматривать проблему создания программного обеспечения автоматических производств как крупную научно-техническую проблему, нуждающуюся в научно-методической и организационной поддержке.
Настоящий сборник подготовлен Рабочей группой по программному обеспечению роботов Научного совета АН СССР по проблеме «Робототехника и автоматизированное производство». Цель сборника —ознакомить широкий круг читателей с разработками в области программного обеспечения роботов. Статьи сборника написаны ведущими специалиста ми в этой области, принимающими непосредственное участие в создании робототехнических систем.
Сборник состоит из четырех частей^ посвященных проблемам разработки программного обеспечения роботов, описанию имеющихся реализаций системного . и прикладного программного обеспечения устройств управления, разработкам алгоритмов управления ро-
ботами. Статьи сборника охватывают широкий круг вопросов как практического, так и теоретического плана.
Представляют интерес стать% посвященные конкретным системам управления сварочными роботизированными комплексами, окрасочными роботами «Колер» и сборочным многооперационным роботом. В сборнике представлены также статьи, описывающие программное обеспечение мулымир0nleceоршях систем управления на базе микро-ЭВМ, программное обеспечение устройств контурного управления для промышленных роботов.
В ряде статей сборника отражен опыт эксплуатации специализированных операционных систем для управления и обучения роботов- Большое внимание уделено проблемам, возникающим в процессе организации и создания программного обеспечения роботизированных комплексов для полунатурного моделирования.
ПРОБЛЕМЫ РАЗРАБОТКИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ
УДК 621,8
НАУЧНЫЕ ПРОБЛЕМЫ
СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОТЕХНИЧЕСКИХ СИСТЕМ
И. М. Макаров, Д. Е. Охоцимский, А. К. Платонов
/^Отличительным признаком^юрШ'отещдчаских-систЕМ является принципиальная возможность применения их в широкой области произ- .водственных процессов и технологий. Такая возможность достигает- /ся путем введения в контур системы управления робота программ- i ных средств, обеспечивающих перенастройку на выполнение ро- \ботом работ различного характера. Это объясняет современную тенденцию создавать системы управления на базе универе альных, мш<ро-ЭВМ с соответствующими программными средствами. Трудозатраты и сроки разработки системы управления промышленного робота и последующего его внедрения па конкретном производстве увеличиваются в связи с необходимостью разработки программного обеспечения, стоимость изготовления которого в настояи^ее время соизмерима со стоимостью аппаратной части системы управления.
Функции программного обеспечения роботов, в общем виде весьма похожие на функции программного обеспечения вычислительных систем, заключаются в обеспечении согласованной работы подсистем робота, в реализации процессов программирования, отладки и редактирования программ работы, в организации доступа к информации в памяти системы и взаимодействия с сопряженным с роботом оборудованием, в формировании отклика на сигналы оператора, в слежении за правильностью работы оборудования и действий оператора. Сопутствующее программное обеспечение должно содержать языки и трансляторы для формирования самого программного обеспечения робота, средства тестирования и отладки.
Вместе с тем программирование роботов имеет существенные отличия от программирования вычислительных машин, связанные со значительно меньшей определенностью состояний внешней среды, самого робота и операционной обстановки. Рассмотрим эту проблему более подробно.
В цифровых вычислительных машинах неопределенности и погрешности физических процессов исключаются на аппаратурном уровне. Поэтому с точки зрения программиста сама цифровая вычислительная машина работает детерминированно. Внешняя неопределенность операционной обстановки сводится к неопределенности
моментов времени возникновения сигналов от присоединенного оборудования и поступления заказов на выполнение различных работ от программ решения задач в мультипрограммном режиме.
В робототехнических системах значительная часть погрешностей и неопределенностей физических процессов должна парироваться на уровне программного обеспечения. Неопределенность операционной обстановки усиливается дополнительной неопределенностью требуемого характера поведения робота (с точки зрения безопасности, отсутствия брака и т. п.) при априорно пезафиксированньтх отклонениях хода технологического процесса. Особенности программного обеспечения роботов связаны также с необходимостью ориентации не на квалификацию системного программиста, а на квалификацию специалиста-технолога, программирующего функционирование робота в цехе, и оператора, обслуживающего робот в составе производственного участка. Программные функции контроля за правильностью работы оборудования и действий оператора осложняются повышенными требованиями к надежности и, главное, безопасности функционирования робота.
Важным обстоятельством, оказывающим большое влияние на программное обеспечение pr 50Toв и сроки его разработки, является наблюдаемое противоречие между требованиями режима реального времени и стоимостью системы управления, приводящее к сравнительно большому разнообразию технических средств и архитектур управляющих вычислительных систем. Традиционно системы управления делятся на цикловые, позиционные и контурные; датчики информации —на аналоговые и дискретные разных типов; привод 一 на следящий и шаговый; кинематические схемы роботов 一 на ортогональные, цилиндрические, сферические и антропоморфные. В связи с этим существенное сокращение стоимости и сроков разработки программного обеспечения подобных роботов достижимо только путем придания ему свойства «транспортабельности» ~ возможности адаптации к системе управления робота другого типа без значительной переделки. При этом следует иметь в виду различие характеристик и ресурсов оборудования применяемых систем управления и роботов (разрядность и быстродействие преобразователей сигналов, быстродействие управляющей ЭВМ, объем ее памяти, наличие внешней памяти, арифметического и тригонометрического расширителя системы команд процессора, вид кинематической схемы робота и т. д.).
Имеется еще одно обстоятельство, отличающее от программного обеспечения вычислительных машин программное обеспечение роботов —его незамкнутость. В условиях современного производства робот представляет собой единицу оборудования в составе производственного участка или при более высоком уровне автоматизации ~ в составе гибкой производственной системы. Поэтому программное обеспечение робота должно в процессе работы взаимодействовать с другими программными системами: числового программного управления (ЧПУ) обслуживаемых станков; автоматизированной системы управления (АСУ) и системы автоматизированного
проектирования (САПР) технологических процессов (ТП) и АСУ производством. Соглашения о связях при подобном взаимодействии весьма разнородны, поэтому к системе управления робота предъявляются требования определенной гибкости интерфейса с внешними системами.
Перечисленные обстоятельства позволяют выделить проблему создания программного обеспечения роботов ввиду ее сложности и новизны в отдельное, научно-техническое направление в общей цепи проблем автоматизации производственных процессов. Техническое содержание этого направления связано с необходимостью разработки общего и специального программного обеспечения серийно выпускаемых промышленностью систем управления промышленных роботов и подготовки соответствующей документации. Эта задача требует тесного взаимодействия разработчиков программного обеспечения с разработчиками аппаратных систем устройств управления и механики роботов.
В обсуждаемой проблеме имеется глубокое научное содержание, связанное с необходимостью разработки алгоритмического обеспечения систем управления роботов и методических средств их создания. Эти задачи могут быть полностью решены только после создания оборудования робота и его системы управления. Для решения научных проблем до завершения разработки робота и его системы управления широко используются лабораторные макеты элементов оборудования робота и математические модели.
Рассмотрим более подробно научное содержание проблем создания программного и алгоритмического обеспечения роботов.
* ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ
Оптимизация программ. Вычислительно-логические возможности ЭВМ являются мощным инструментом в руках программиста. Однако именно богатство этих средств приводит к неоднозначности принимаемых решений и трудности выбора оптимального варианта. Поэтому написанная программа часто является отражением стиля и опыта программиста, а не результатом применения объективных методов синтеза оптимальных процедур работы ЭВМ.
Проблема оптимизации программ наиболее остро стоит в связи fc требованиями режима реального времени в программном обеспе-., I чении робототехнической системы. Иными словами, для робототех-""%、 ]нических систем важным критерием качества является быстродей- ] 11 ствие программных модулей, в том числе модулей операционной J 《системы.
С другой стороны, требования простоты системы управления робота и ее низкой стоимости приводят к ограниченным объемам оперативной и внешней памяти устройств управления роботов по сравнению с вычислительными системами. В связи с этим не менее остро стоит проблема оптимизации суммарного объема программного обеспечения робота и объема резидентных программ с учетом разделения на переменную и постоянную части.
Многокритериальный характер оптимизационной задачи порождает известные трудности ее решения и требует разработки специальных методов оптимизации [1, 2]. Эффективными отечественными средствами здесь являются оптимизирующий транслятор ФОРЕКС [3] и языки Астра [4] и МЭЛ [5].
Распределение или централизация функций? Все функции программного обеспечения (прием и передача сигналов, вычисления и выбор альтернатив) могут быть в наиболее общем виде описаны как процессы обработки информации, обладающие двумя характеристиками: временем исполнения и локализацией. При проектировании программного обеспечения имеется некоторая свобода варьирования состава процессов, их быстродействия и способов взаимодействия, дающая возмояшость оптимизации критериев качества программного обеспечения. Вместе с тем всегда можно выделить «нулевой) уровень описания проблемы управления роботом с учетом имеющейся конфигурации технических средств, на котором состав и структура процессов фиксированы. Это исходное описание процессов не содержит указания на способы организации их взаимодействия и синхронизации. На нулевом уровне описания нет также информации о распределении исходных процессов по процессорам многопроцессорной системы управления робота.
Исходная совокупность процессов управления, определяемая с помощью содержательного анализа задач управления и наличных аппаратных средств, должна быть дополнена служебными процессами, выполняющими административные операции для синхронизации и организации взаимодействия исходных процессов. Программ- ная реализация служебных процессов может быть оформлена в виде отдельной централизованной операционной системы или может быть распределена по программным модулям, реализующим исходные процессы. Локализация служебных процессов оказывает значительное влияние на эффективное быстродействие программного обеспечения, занимаемый им объем памяти и способы развития.
Централизация функций административных процессов, удобная с позиций структурной простоты организации процедур управления, снижает эффективное быстродействие системы управления и качество управления в режиме реального времени. С другой стороны, распределение функций операционной системы в системе проблемно-ориентированных программ приводит к увеличению необходимого объема памяти и сложности организации оптимального распределения работ в динамике функционирования системы управления. Поиск наилучше го соотношения централизации и распределения функций управления в системе процессов является актуальной научной проблемой, решение которой позволит получить максимальную эффективность управления для заданной архитектуры аппаратных средств.
В настоящее время накоплен значительный опыт эмпирических методов решения указанной проблемы. Созданы операционные системы программного обеспечения роботов с различной степенью децентрализации. Анализ интегральных характеристик накладных
расходов и затрат памяти в этих системах позволяет получить необходимые данные для построения формальных методов определения оптимальной степени децентрализации системы [6, 7].
Процесс или память? Из практики программирования хорошо известно, что уменьшение длины программы в памяти машины можно получить, используя более длительный процесс вычислений при сохранении характера требуемой функциональной обработки исходных данных. И наоборот, если требуется сократить время вычислений, то наилучший путь — замена процесса вычислений обращением к табличным данным, запасаемым в памяти машины. Таким образом, время исполнения данного функционального оператора связано с длиной исполняющей его программы обратной зависимостью, по крайней мере в некоторой части области определения этой функции.
Проблема выбора оптимального соотношения времени исполне- \ ния программы и объема занимаемой ею памяти при создании программного обеспечения роботов стоит особенно остро из-за малой мощности применяемых ЭВМ и большой вычислительной сложности решаемых задач (высокая требуемая относительная точность движения, большое число степеней подвижности робота, сложность его кинематической схемы, требования работы в режиме реального времени и т. п.). В связи с этим необходима разработка специализи^ рованных библиотек стандартных программ робототехники, приспособленных для эффективного решения задач кинематики и динамики роботов. При этом следует учитывать известные для этих роботов диапазоны изменения обобщенных координат, допустимые точности вычисления тригонометрических 巾унк用(й и возможность проведения предварительных вычислений в процессе обучения робота [8, 9].
Для решения этих проблем необходимо развитие инструменталь^ ных средств и методов, ориентированных на использование совре^ менной микропроцессорной элементной базы с учетом присущих ей характерных свойств и ограничений (влияние архитектуры спецпроцессора на время и точность исполнения операций, соотношение процесс—память на уровне микропрограммирования, наличие быстрых регистровых и сдвиговых операций трансформации чисел и т. п.). Следует отметить, что строгое формальное описание этих свойств и ограничений, позволяющее развивать аналитические и численные методы варьирования альтернатив при оптимизации программ, развито еще недостаточно. Разработка такого описания путем анализа особенностей современной элементной базы с точки зрения программиста является самостоятельной научной проблемой, имеющей важное значение для правильной постановки и решения задач оптимизации программ.
Как работать с памятью? Обращение к памяти ЭВМ в общем случае представляет собой не однократную машинную операцию, а многоуровневый процесс доступа к данным, реализуемый на ать паратном, микропрограммном и программном уровнях, причем последний может содержать уровни операционной системы, файловой системы н прикладных программ. При большом объеме данных
1
процессы доступа могут занимать большое время и рассмотренная выше проблема «процесс или память?» превращается в проблему «процесс вычислений или процесс обращения к памяти?», решение которой зависит от принятого способа организации работы с памятью ЭВМ [10]. Как известно, имеются два аспекта этой проблемы: доступ к данным (распределение памяти, «уборка мусора», выбор оптимальной функции адресации и т. п.) и организация обмена данными между программными модулями (формальные параметры, «common-блоки», data flow и т. и.).
Способы решения возникающих вопросов тесно связаны с особенностями средств, предоставляемых файловой системой, макрогенератором и трансляторами инструментальной системы программирования, видом внешней памяти устройства управления и возможностями организации баз и банков данных с абстрактными типами данных, реализации идей «отложенной трансляции» академика Л. П. Ершова и создания универсальных средств генерации версий программного обеспечения. Недостатки принятых способов организации работы с памятью, как правило, становятся очевидными только на поздней стадии создания программного обеспечения или позже — в процессе его развития. Изменение принятого способа организации работы с памятью означает коренную переработку всех программ. Поэтому формулирование научно обоснованных рекомендаций и соответствующих программных средств имеет большое значение.
Проблемы организации памяти важны и с точки зрения стандартизации программного обеспечения. Быстрое совершепствование и развитие вычислительной техники и средств программирования, так же как и возникновение новых производственных систем, делают несостоятельными попытки стандартизовать непосредственно структуру данных программного обеспечения производства. Для примера достаточно сравнить различающиеся структуры данных устройств ЧПУ для металлообработки, устройств управления роботов, роботизированных технологических участков, систем САПР- АСУ ТП и гибких производственных систем. Хотя все эти системы принципиально могут быть реализованы на однотипных ЭВМ с одним и тем же базовым программным обеспечением и структурой данных, этого не произошло ввиду их создания в разное время. И, безусловно, здесь крайне полезным явился бы стандарт, описывающий не саму структуру данных, а методы организации памяти и язык для определения используемой структуры данных.
Решение перечисленных проблем, видимо, следует искать на пути разработки средств генерации трансляторов и загрузчиков, позволяющих изменять способы работы с памятью без изменения текста программ [4].
； Язык или языки? Ответим сразу: языки и язык. Программное i обеспечение роботов представляет собою сложную многоуровневую систему средств, элементы которой отличаются как по областям применений роботов, так и по стадиям использования программ в процессе подготовки производства. Языковая поддержка этих
средств также является совокупностью непохожих наборов операций и структур данных, реализуемых в различных устройствах. Можно указать, например, на такие принципиально разные языки, как язык программирования робота с помощью пульта обучения, язык предварительного описания деталей и видов дабот, используемый для получения управляющих программ, язык генератора версий программного обеспечения, языки систем программирования инструментальных ЭВМ. Множество языков безусловно усложняет систему, однако отсутствие какого-либо из них усложняет ее эксплуатацию и развитие.
Важно отметить, что всякий язык программирования представляет собой совокупность типов данных, операторов и транслятора, причем от качества транслятора зависят в большой мере эксплуатационные характеристики системы программирования. При создании трансляторов для языков программирования мини- и микроЭВМ, используемых в робототехнике, необходимо обеспечить высокую скорость трансляции и надежность получаемых программ.
Обеспечение надежной трансляции в заводских условиях представляет серьезную проблему ввиду необходимости во многих слу- «ях использования лишь простейшего терминального оборудования— перфоленточных устройств ввода—вывода или же кассетного магнитофона малой емкости с последовательным доступом. При этом следует учитывать возмояшость сбоев или отказов терминального оборудования при его эксплуатации в неблагоприятных условиях.
Надежность трансляции может быть обеспечена путем придания программному обеспечению специальных свойств, позволяющих уменьшить его зависимость от качества и состава применяемого в процессе трансляции оборудования,— простоты обработки текстовых данных и функциональной избыточности.
Под простотой обработки текстовых данных мы подразумеваем минимизацию числа проходов транслятора, отказ от промежуточных обращений к внешней памяти, простоту редакции и сопряжения новых программных модулей с уже сутцествующими. Для этого необходима разработка наиболее рациональных с этой точки зрения принципов сочленения и распределения функций между средствами макрогенерации, трансляции, редакции и загрузки в системе программирования и операционной системе используемой ЭВМ. Сложность проблемы связана с необходимостью серьезной модификации операционной системы и других системных средств, поставляемых заводом — изготовителем ЭВМ.
Правильно организованная программно-аппаратная система по- зволпет отключать элементы оборудования в случае отказа, используя путем программной переконфигурации заложенную в систему фу^ кциональную избыточность. 9то требует развития средств проверки готовности оборудования и правильности работы программы, а также средств автоматического поиска способа исправления найденных неправильностей. Последняя проблема особенно сложна, Так как для ее решения необходимы методы синтаксического и,
И
главное, семантического анализа тяжести ошибки и методы принятия решения о способах ее исправления или локализации с минимальными затратами труда и времени. Весьма перспективным представляется создание интерактивных систем трансляции и загрузки программ.
Анализ проблемы и опыт разработки системного программного обеспечения робототехники говорят о необходимости использования специального базового языка программирования и транслятора с загрузчиком, позволяющих эффективно создавать трансляторы для языков программирования роботов, обладающие описанными выше свойствами. Наличие такого базового языка облегчает стандартизацию и унификацию программного обеспечения и, главное, резко снижает трудозатраты при создании программ обработки сигналов от оборудования робота и при распределении параллельных процессов по процессорам многомашинного комплекса. В настоящее время версия такого отечественного языка прошла опытную эксплуатацию ira машинах М-6000, СМ-2, СМ-4 и «Электропика-60» с их операционными системами [5]. Перспективы для использования в качестве базового языка робототехники имеют также язык «С» в операционной системе «UNIX» и язык Паскаль.一
Таким образом, для решения проблемы языковой поддержки программного обеспечения роботов необходима разработка:
проблемно-ориентированных языков программирования роботов' в виде совокупностей типов данных и операторов, адекватных содержанию технологических задач;
единого базового языка, обеспечивающего возможность создания эффективных и надежных трансляторов для прикладных языков с учетом особенностей оборудования на конкретном производстве.
Транспортабельность программного обеспечения. Решение упомя- nyTOii проблемы транспортабельности систем упирается в построение оптимальной архитектуры программного обеспечения (аналогично. архитектуре ЭВМ — особенностям ее устройства, влияющим на системное программное обеспечение, архитектура программного обеспечения — особенности системного программного обеспечения, влияющие на облик прикладных программ). Трудность задачи в отсутствии достаточного опыта создания систем управления роботов для различных видов производственных процессов и, как было отмечено выше, в значительной вариативности конфигураций известных систем. Роботы даже с одинаковым функциональным назначением могут различаться: по составу позиционных датчиков (кодовые, импульсные, потенциометрические), силомоментных (прово- лочные, полупроводниковые), фотометрических (фоторезисторы,' фотодиоды, видикон, прибор зарядовой связи), локационных (опти-: ческие, ультразвуковые) и т. п.; по виду привода (электропривод постоянного или переменного тока, шаговые двигатели, электрогид- ропривод, пневмопривод); по виду внешней памяти (перфолента,. кассетный магнитофон, магнитная лента на бобинах, магнитные диски) ;по числу процессоров (один—десять). Однако нет уверенности, "то этот список обладает необходимой полнотой и что приведенная
совокупность вариантов оборудования взаимно однозначно отображается на совокупность программных средств.
Если даже считать, что задачи транспортабельности программных систем полностью определены, остается неопределенность методов их решения. Необходима разработка языка и средств генерации версий программного обеспечения, облегчающих процесс переноса программных систем. Реализация таких средств возможна на базе библиотеки программных модулей,' соответствующих характеристикам используемого оборудования роботов. На этом пути методически важно правильно решить задачу декомпозиции программной системы на модули, с тем чтобы при измепепии конфигурации оборудования и вида работ существовала возможность получить требуемое программное обеспечение путем изменения состава вызываемых из библиотеки программных модулей.
Подобный способ реализации процесса переноса программных систем является наиболее подходящим для начальной стадии развития систем управления производственными процессами, так как он обеспечивает наибольшую простоту адаптации к непредусмотренным изменениям конфигурации оборудования. Именно по этой причине он используется в разрабатываемых программных системах, причем в некоторых из них предусмотрены специальные средства управления процессами, облегчающие перенос и адаптацию программ.
Важной проблемой является выбор правильного метода работы с библиотекой. С точки зрения скорости программирования наиболее простыми являются библиотеки стандартных программ в виде модулей загрузки, позволяющие статически (до начала работы про- г诡мм) или динамически (в процессе работы) загружать в память требуемые стандартные программы и передавать им управление по мере необходимости. Как показал опыт разработки алгоритмов управления движением робототехнических систем, накопленный в Институте прикладной математики им. М. В. Келдыша АН СССР, подобный метод весьма эффективен при отработке функциональной структуры и состава программного обеспечения робота, когда требо- вания экономии ресурсов используемой ЭВМ не являются определяющими.
На заключительной стадии создания программного обеспечения более рационально использование библиотеки макроопределений и средств макрогенерации, позволяющих экономить, ресурсы ЭВМ. В настоящее время опыт разработки подобной библиотеки накапливается на базе макросредств системы РАФОС. Анализ этого опыта позволит оценить эффективность существующих средств макропрограммирования и выработать рекомендации для разработки новых макрогенераторов. Однако уже и сегодня очевидны требования к подобной системе, связанные с необходимостью многократных выходов на машину в процессе макро генерации, трансляции и загрузки программ [И, 12].
Оптимальная степень доступности. Это свойство системных про- грамм тесно связано с решением проблем уменьшения накладных
расходов системного программного обеспечения и увеличением его консервативности. Недоступность модулей операционной системы для программиста, реализующего создание и использование совокупности прикладных программных модулей, не позволяет «подгонять» архитектуру программного обеспечения под конкретную структуру аппаратных средств и задач робота. С другой стороны, простота изменений модулей операционной системы порождает множественность несовместимых версий и реализаций с различными линиями развития.
Разработка каких-либо стандартов в этой области, регламентирующих творческую деятельность программиста, при создании конкретной робототехнической системы исключительно трудна. Тенденция развития в настоящее время — создание генератора операционных систем с их заданными свойствами и соглашениями о связях с драйверами оборудования и проблемно-ориентированными программными модулями. Входной язык такого генератора должен представлять возможность описания специализированных операционных систем с «усеченными» применительно к задачам робота функциями, заданными дисциплиной обработки запросов, методами синхронизации процессов, ограничениями резидентной памяти, требованиями реального времени и, как это обычно делается в существующих генераторах вычислительных операционных систем, конфигурацией оборудования. Подобный генератор может быть представлен в виде кросс-компилятора, объектными программами которого являются модули операционной системы в виде, приспособленном для программируемых постоянных запоминающих устройств (ППЗУ) и для внешней памяти, а также модули трансляторов системы программирования робота, взаимодействующие с операционной системой. Устройство компилятора при этом остается известным только системному программисту и не влияет на деятельность программи-. ста прикладного. Заметим, что в настоящее время устройство операционной системы, разрабатываемой системным программистом,. часто влияет на деятельность прикладного программиста. Это обстоятельство и является основной причиной попыток изменения уровня доступности системных программ.
Описанный подход к оптимальной организации доступа прикладного программиста к системным средствам исследовался в Институте прикладной математики им. М. В. Келдыша АН СССР в процессе создания транслятора базового языка МЭЛ [5].
АЛГОРИТМИЧЕСКОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ
Создание программного обеспечения роботов невозможно без разработки алгоритмов обработки информации и управления движением. Задачи создания алгоритмического обеспечения роботов связаны с необходимостью преодоления формализма системы управления, придания ей детерминированного характера функционирования, повышения уровня восприятия операционной обстановки и автоматизма управления и, наконец, с решением задач обучения роботов.
Ограниченность формальных систем. Она вытекает из фундаментальной теоремы Геделя и присуща также системам управления роботов. В силу этого обстоятельства к любому алгоритму функционирования робота можно подобрать контрпример, показывающий несостоятельность алгоритма. Задача, однако, заключается в том, чтобы согласовать уровень формализма робота с уровнем формализма выполняемых им видов работ, т. е. перевести все возможные контрпримеры в разряд на практике не встречающихся.
Задача преодоления ограниченности форлгализлта алгоритмического обеспечения, решаемая сегодня на интуитивном уровне, допускает формальную постановку и решение. Проблема заключается в синтезе языка описания операционной обстановки при выполнении работ различного вида и, главное, правил взаимодействия робота с внешней средой, обеспечивающих необходимое отображение практически значимой области операционных обстановок на фазовое пространсгво системы управления роботом. В этом случае все практически значимые состояния внешней среды будут формально различимы в системе управления роботом, а «контрпримеры» останутся вне заданной области возможных ситуаций.
При таком отображении важным обстоятельством является конечность пространства состояний системы управления робота, вытекающая из конечной разрешающей способности его датчиков и органов управления движением. В то же время пространство состояний самого робота хотя и является конечномерным (число степеней свободы робота ограничено), но в виду особенностей его конструкции (наличие люфта и зон нечувствительности) в общем случае конечным не является.
Правила взаимодействия робота с внешней средой, обеспечивающие перевод операционной обстановки в конечное фазовое пространство системы управления робота, адекватное его задачам, упрощаются, если использовать активное пространственное совмещение элементов конструкции робота с объектами внешней среды. Подобное направление синтеза аппаратно-алгоритмических правил взаимодействия робота с внешней средой плодотворно развивается в процессе разработки алгоритмического обеспечения сборочного робота (работа по удорам с применением податливости и специальной логической обработки информации от датчиков в степенях подвижности [13]).
Детерминизация работы. Прямое решение этой проблемы заключается в создании роботов, работающих с точностью выше уровня требуемой дискретности описания операционной обстановки, т. е. в придании роботу детерминизма на аппаратном уровне. Однако такой путь не всегда возможен ввиду недетерминированности реакции внешней среды на действия робота. В то же время использование логических возможностей управляющей ЭВМ позволяет в ряде случаев получить детерминированную систему алгоритмическим путем.
Парирование аппаратных неопределенностей алгоритмическим путем порождает проблему логической обработки неточных данных,
15
описываемых неопределенными множествами [14]. Подобная обработка, учитывающая специфику выполняемых роботом движений, заключается в реализации трех процессов: контроля правильности сигналов обратной связи, уточнения неопределенной ситуации и формирования реакции на ситуацию. Последняя функция специфична именно для робототехнической системы в отличие от вычислительных систем, в которых активное взаимодействие с внешней средой (системами ввода—вывода) существенно беднее.
Алгоритмическое обеспечение системы управления робота представляет собой многоуровневую систему алгоритмов обработки данных: технический уровень (драйверы устройств), предметный уровень (алгоритмы обработки сигналов датчиков и алгоритмы построения движений), процедурный уровень (алгоритмы мониторов систем), системный уровень (операционная система, программный контроллер), уровень обучения (языки и алгоритмы обучения .робота). Проблема алгоритмической детерминизации работы системы управления заключается, в частности, в определении места алгоритмов детерминизации в системе уровней. Локализация этих алгоритмов является наиболее желательной иа уровне драйверов. В этом случае вся остальная система управления робота с точки зрения прикладного программиста является цифровой системой со всеми вытекающими удобствами.
Реализация подобной системы приводит к необходимости разработки алгоритмов следящих цифровых систем для использования их в драйверах робота [15] и алгоритмов детектирования операционной обстановки путем программируемой логической фильтрации сигналов от датчиков информации [16]. Подчеркнем, что на уровне драйверов речь идет именно об алгоритмах детектирования ситуации, а не о процессах распознавания образов в классическом смысле,
Супервизорное управление. Повышение уровня автоматизма управления и восприятия операционной обстановки обеспечивает возможности создания супервизорных систем, в которых оператор управляет роботом, обращаясь к его системе знаний, т. е. на достаточно высоком уровне команд. Одной из важных проблем здесь является оптимальное распределение функций между человеком и роботом в рамках производственной системы. Необоснованная автоматизация функций планирования работы с учетом всех мыслимых производственных ситуаций удорожает робот и снижает экономическую эффективность его использования. Сохранение за человеком функции принятия решения о режимах работы, особенно в нештатных ситуациях, и придание системе управления средств суперви- зорного управления позволяют (как это показывает, в частности, опыт разработки шагающего аппарата [17]) существенно упростить алгоритмы управления. На зтом пути, однако, существуют два препятствия, преодоление которых требует тщательных предварительных исследований и отработки в процессе эксплуатации системы: необходимость декомпозиции возможной активности робота на систему независимых функциональных режимов, покрывающих всю
область возможных способов реакций на множестве возможных ситуаций, и требование обеспечить реакцию системы на команды оператора с минимальным временем отклика.
Первая проблема связана с противоречием между требованиями подробности алфавита функциональных команд и его укрупнения в супервизорном режиме (исходя из упрощения деятельности оператора) .Решение основывается на анализе задач управления движением и строгом соблюдении основного принципа программирования: «все независимое — раздельно, все зависимое 一 вместе». Имеющийся опыт создания супервизорных систем управления [18, 19] показывает, что лучше иметь избыточность функциональных средств, чем их связанность, которая может привести к выполнению' ненужных действий.
Вторая проблема возникает в связи с неопределенностью будущих команд оператора и их возможным «неудобством» для системы управления. В полностью автоматической системе активность робота разворачивается в зависимости от операционной обстановки по плану, сформированному заблаговременно и наилучшим образом соответствующим заданным целям движения. В супервизорноп системе оператор может выдать команду, несогласованную с текущим состоянием системы управления робота. Поэтому степень управляемости супервизорного робота в общем случае ниже автоматического 一 за внезапность команд приходится «платить». Уменьшение нежелательных последствий внезапных команд, как показал опыт создания системы супервизорного управления шагающей машиной, управляемой водителем [18], возможно тремя способами: разработкой алгоритмов управления движением, расширяющих область достижимости в каждой текущей точке фазового пространства состояний робота;
разработкой для оператора средств индикации текущей области достижимости или границ; области управляемости в пространстве управляющих команд;
разделением команды оператора на предварительную (задающую тенденцию управления) и исполнительную (формирующую движение в обозначенной предварительной командой области).
Режимы обучения. Эта группа проблем создания алгоритмического обеспечения роботов связана с режимами программирования их работы. Супервизорный режим был рассмотрен выше с точки зрения его внутреннего содержания. Внешняя сторона этого режима — интерфейс с человеком. Наиболее популярный способ супервизор- ного управления — использование управляющих рукояток [20]. Менее традиционным является использование алфавитно-цифровых или графических дисплеев, хотя в современных системах ЧПУ и гибких автоматизированных производств (ГАП) они находят довольно широкое применение даже в условиях цеха. В таких случаях необходима разработка специальных языков программирования работы и проблема заключается в обеспечении полноты и удобства использования принятого состава операторов и типов данных. В частности, язык описания плана сборочных операций двурукого
сборочного робота ориентирован на использование алфавитно-цифрового дисплея. Этот язык рассматривается в публикации [21]. Он обладает небольшим (около десяти) набором операторов и позволяет на естественном языке описывать три графа: план сборки, планы сборочных операций и планы проверки условий выполнения сборочных операций [22].
Специальный пульт обучения робота является обычным средством программирования его работы. Проблемы алгоритмического обеспечения робота связаны с сокращением времени обучения и повышением точности работы. Они очень похожи на проблемы ввода информации в ЭВМ с помощью светового пера и графического дисплея. Путь решения аналогичный — с помощью специальных команд ввода положения робота и алгоритмов интерполяции между введенными точками. Отличие робототехнических систем обучения от графических средств ввода информации заключается в наличии трех пространств: конфигурационного пространства робота, предметного пространства, связанного с обрабатываемой деталью и пространства запоминаемых при обучении показаний датчиков. При обучении снимаются показания датчиков, соответствующие задан- пому положению робота в его конфигурационном пространстве, в то время как интерполяция движения между точками обучения должна выполняться в предметном пространстве. Это порождает проблемы решения прямой и обратной кинематических задач в условиях дефицита времени. Опыт решения таких задач применительно к реализации робототехнической системы дуговой сварки показал возможность реализации процесса обучения в режиме реального времени.
Отдельной ал г оритмич еской проблемой является коррекция программы работы робота в связи с изменением начальной установки детали или изменения рабочих органов робота (износ, смещение и т. п.) * С этой целью в процессе обучения должны быть запрограммированы контрольные движения со специальными свойствами (фиксированное направление поиска детали, колебания, сканирование и т. п.). Алгоритмы установочной адаптации и предоперационной коррекции управляющих программ особенно важны в условиях ГАП. Главными проблемами в этом случае являются обеспечение надежности и быстродействия этих алгоритмов. Пример одного из алгоритмов установочной адаптации сварочных роботов приведен в публикации [23].
* * *
Рассмотренные проблемы создания программного, языкового и алгоритмического обеспечения роботов в настоящее время успешно решаются.
Создаются и используются для отработки алгоритмов и программ моделирующие аппаратно-программные комплексы, в том числе и комплексы для полунатурного моделирования.
Ведется также разработка ряда перспективных робототехнических систем и их программного обеспечения.
ЛИТЕРАТУРА
Рау О. И. Модель виртуальной машины как база оптимязации программ^- В КН.: Вопросы системного программирования. М.: Изд-во Ml у, 1»2
с. 75—89.
Соболь 玄.М.} Статников Р. Б. Выбор оптимальных параметров в задачах со многими критериями. М.: Наука, 1981. 110 с.
Штаркман В. С. Локальная оптимизация объектной программы в трансляторе ФОРЕКС: Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 149. М.; 1979. 28 с.
Михелев В. 泌.,Вершубский В. Ю. АСТРА: язык для записи алгоритмов системного программирования и трансляции： Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 16. М., 1974. 66 с.
5. Платонов А. Я., Лазутин Ю. М., Ярошевский В. С. Системное программное обеспечение задач робототехники,— В кн.: Тр. 2-й Междунар, конф, по искусственному интеллекту и информационно-управляющим системам роботов, окт. 1982. г. Смоленице, ЧССР. Братислава: НТК САЯ, 1982, с. 192—
2.
3.
4.
195.
Платонов А. К、, Боровик Г. ^., Дружчепко В. Е., Уиганов В. А., Никифоров В. В. Исследование структуры системы управления робота для дуговой сварки.— В кн.： Исследование робототехнических систем. М.: Наука, 1982, с. 51-65.
Пономарев В,也.,Домарацкий А. Я., Никифоров В. В. Система алгоритмических модулей управления роботами — АМУР-80： Препр. ЛНИВЦ АН СССР
№ 20. Л., 1981. 50 с/
8. Гримайло С. 〃., Кареашин А. Ю., Платонов А. К., Яшкичев И. В. Исследование кинематики и точностных характеристик промышленного робота Универсал-15: Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 38. М., 1982. 27 с.
Гримайло С. И. Система программирования и исполнения движения нипулятора, управляемого от ЭВМ: Препр. Ин-та прикл. математики М. В. Келдыша АН СССР № 104. М.. 1981. 28 с.
Илюшин А. И., Щенков И. Б. УПД-6: Использование средств управления данными в ФОРТРАНе. М.: Ин-т прикл. математики им. М. В. Келдыша
9.
10.
И.
12.
13.
14.
15.
16.
17.
18.
19.
ма- им.
АН СССР, 1976. 83 с.
Марченко Н. А., Михелев В. М, Использование микрогенераторов для управления проблемно-ориентированными пакетами программ: Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 97. М., 1977. 20 с.
Лазутин Ю. М.} Яшкичев И. В. Система программирования микро-ЭВМ «Электроника-60» на мини-ЭВМ М-6000: Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 58. М., 1982. 21 с.
Охоцимский 力.Е. Разработка очувствленных роботов.— В кн.: совещ. по робототехническим системам, Минск, 15—19 мая 1981 г.: Тез. докл. Минск: БЕЛНИИТИ, 1981, с. 17—18.
Нариньяни А. С. Неопределенные множества — новейший тип данных для представления знаний: Препр. ВЦ СО АН СССР № 232. Новосибирск, 1980.
II Всесоюз.
26 с.
Охоцимский Д Е、Платонов А. Я.. Кугушев Е. И., Павловский В. Е.г Яро- шевский В. С. Мини-ЭВМ в контуре управления шагающим аппаратом.— В кн.: Динамика управляемых систем. М.： Наука, 1979, с. 209——216.
Платонов А. ^, Карпов И. И. Синтез и моделирование па ЦВМ информационной системы шагающего аппарата; Препр. Ин-та прикл. математики нм. М. В. Келдыша АН СССР № 66. М,, 1974. 49 с.
Охоцимский Д. Е., Платонов Л. К., Кугушев Е. И., Ярошевский В. С. Система построения движения шагающего аппарата. Модель Т-3: Препр. Ин-та ирикл. математики им. М. В. Келдыша АН СССР № 7. М., 1977. 62 с. Охоцимский Д. Е., Платонов А. К., Кугушев Е. 〃.，Лазутин Ю. М., Ярошевский В. С. Проблемы построения и моделирования движения управляемого оператором шагающего аппарата: Препр, Ин-та прикл. математики им. М. В. Келдыша АН СССР № 125. М., 1974. 38 с.
Попов Е. П.} Максимов 4. 〃.‘ Ковальчук А. Я., Шишов В. 〃. Универсаль-
ный аналого-цифровой комплекс для исследования робототехнических систем.— В кн.: Исследование робототехнических систем. М.: Наука, 1982, с. 5—11.
Лобачев В. 〃., Ковальчук А. К” Кашаев Р. Ш. Система полуавтоматического управления очувствленным манипуляторем.— В кн.: Исследование робототехнических систем. М.: Наука. 1982, с. 12—16.
Охоцимский Д. Е., Платонов А. К., Камынин С. С., Гримайло С. И.} Карга- шин А. Ю” Кирильченко А. А., Кугушев Е. Я. Программные средства для планирования процесса автоматической сборки.——Наст. сб.
Охоцимский Д. Е., Платонов 4 К” Смольянов Ю. 〃.，Гримайло С. %, Камынин С. &, Кугушев Е. Я. Исследование многооперационной сборки с помощью экспериментальной робототехнической системы.——В кн.: Роботизация сборочных процессов. М.: Наука, 1985, с. 61一88.
Цыганков Ю. К. Один из подходов к трактовке искусственного интеллекта в системах управления сварочным роботом.— В кп.: Робототехнические системы в отраслях народного хозяйства： Тез. докл. II Всесоюз. совещ. по робототехническим системам, Минск, 15—19 мая 1981 г. Минск: БЕЛНИИТИ, 1981, с. 94-95.
УДК 621.8
ЯЗЫКОВЫЕ СРЕДСТВА
РАЗРАБОТОК ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 〈 ПРОМЫШЛЕННЫХ РОБОТОВ
А. Смирнов, В. В. Никифоров
Возможности внедрения промышленных роботов в значительной мере зависят от их совершенства — надежности, адаптируемости, широты диапазона реализуемых функций и т. п. Для обеспечения высокого уровня основных характеристик промышленного робота необходимо совершенствование всех его составляющих подсистем: механики, привода, комплекса измерительных средств (средств очувствления робота), устройства управления. Настоящая статья представляет собой обзор проблем совершенствования элементов программного обеспечения для устройств управления промышленных роботов.
Элементы программного обеспечения существенно различаются по характеру разработки и использования. Принято выделять:
функциональное программное обеспечение;
комплект управляющих программ;
тесты;
инструментальное программное обеспечение.
Функциональное программное обеспечение состоит из программных модулей и формируемых (компонуемых) на их основе вари-* антов (версии) систем. Конкретный вариант системы функционального программного обеспечения обеспечивает функционирование управляющих устройств и промышленного робота в целом в составе робототехнического комплекса определенной конфигурации (конкретные типы исполнительных механизмов робота, обслуживаемого технологического оборудования, определенный характер организации 20
технологического участка и всего роботизированного производства) .
Конкретная управляющая программа содержит информацию о требуемых действиях промышленного робота при работе с деталями конкретной конфигурации. Эта информация интерпретируется действующим вариантом функционального программного обеспечения в ходе выполнения технологической операции (в ходе исполнения управляющей программы); содержание управляющей программы должно обеспечивать требуемую последовательность движений рабочего органа робота и согласованные с последовательностью движений информационные обмены между устройствами управления и обслуживаемым технологическим оборудованием. В общем случае устройства управления и действующий вариант функционального программного обеспечения должны обеспечивать вмешательство человека-оператора в ход исполнения управляющей программы. Особенности синтаксической организации управляющей программы и семантики ее конструкций (особенности языка) в значительной мере характеризуют возможности варианта функционального программного обеспечения, устройства управления и робототехнического комплекса в целом.
Тестами называют программы, обеспечивающие проверку работоспособности и локализацию неисправностей узлов, блоков и подсистем устройств управления и всего робототехнического комплекса. Тесты могут быть либо самостоятельными программами, либо программами, работа которых должна поддерживаться функциональным программным обеспечением тестируемого устройства управления. В частности, особую разновидность тестового программного обеспечения составляют комплекты комплексных тестов, представленных в языке управляющих программ (комплекты тестовых управляющих программ).
Совокупность средств (аппаратных и программных), используемых для разработки программного обеспечения, принято называть инструментальными средствами (в частности, программные средства разработки программного обеспечения — отдельные программы, комплексы программ и программные системы 一 называют инструментальным программным обеспечением). В частном случае роль аппаратного инструментального средства может играть само управляющее устройство промышленного робота; в таком случае соответствующее инструментальное программное обеспечение называют резидентным. Если для разработки программного обеспечения конкретного типа управляющих устройств используются вычислительные устройства и системы другого типа (с принципиально отличной архитектурой), то соответствующее инструментальное программное обеспечение называют кросс-обеспечением.
Использование программного обеспечения любого из рассмотренных типов требует применения более или менее развитых языковых средств. Полная характеристика состава языковых средств используемого программного обеспечения в значительной мере определяет круг его возможностей. Поэтому для характеристики функциональ-
ных возможностей программного обеспечения оольшое значение имеет описание реализуемых им языков.
Важный класс языковых средств составляют диалоговые языки. Определение синтаксиса диалогового языка регламентирует состав возможностей (возможных форм) интерактивного процесса информационного взаимодействия (взаимодействия человека-оператора с управляющим устройством); определение семантики форм диалогового языка означает задание смысловых значений отдельных информационных посылок (и отдельных элементов этих посылок) в контексте предыстории интерактивного процесса.
Построение программного обеспечения развитых управляющих систем неизбежно связано с реализацией диалоговых языков различного уровня сложности. Наряду с этим многие элементы программного обеспечения реализуют более или менее развитые не- диалоговые (текстовые) языки. Конструкции текстовых языков представляют собой изображения структур, отношений, алгоритмов.
С точки зрения эксплуатации промышленных роботов важнейшими языками являются текстовый язык управляющих программ (язык представления) и диалоговый язык взаимодействия челцвека- оператора с роботом. С семантикой конструкций языка управляющих программ связаны такие функции промышленного робота, как интерполяция, учет значений корректирующих параметров, взаимодействие с управляемыми механизмами и технологическим оборудованием при автоматическом исполнении возложенных на промытп- ленный робот технологических операций (в режиме исполнения управляющей программы). Средства диалогового языка взаимодействия промышленного робота с человеком-оператором позволяют составлять и редактировать тексты управляющих программ, осу- ществлять непосредственное управление положением рабочего органа робота, давать команды размещения управляющей программы на внешних носителях (или ввод управляющей программы с внешних носителей) и т. п< ,
Состав основных функций, обеспечиваемых действующими и разрабатываемыми вариантами программного обеспечения для серийно выпускаемых в настоящее время устройств управления промышленными роботами, приведен в табл. 1.
Функция
Взаимодействие
с человеком-оператором
с управляемыми механизмами
с технологическим процессом
Ручное управление
Редактирование управляющих программ
Хранение управляющих программ и доступ к ним
Пополнение управляющих программ
Интерполяция
Учет значений корректирующих параметров
Особенности реализации
Использование универсальной клавиатуры, дисплеев, специальных пультов
Шаговый привод, следящий привод (по скорости и положению)
Ввод — вывод последовательности технологите- ских параметров и сигналов в ходе выполнения операторов последовательной управляющей программы
Кнопочное： обеспечение движения рабочего органа промышленного робота с постоянной скоростью вдоль (вокруг) выбранной оси Посимвольное, форматное
Хранение на перфоленте и кассетных магнитных лентах; ввод (вывод) с магнитной ленты (па магнитную ленту) в рамках специального режима работы устройства управления, (режима об- мена); ввод с перфоленты непосредственно в ходе исполнения
Покадровое, однократное, многократное, с автоматической настройкой на воспроизведение (ис- noJTHeinie) требуемой управляющей программы (выбирается из имеющегося в оперативном запоминающем устройстве комплекта)
Линейная, круговая (в избранных плоскостях)
Коррекция воспроизводимой траектории по данным, вводимым в устройство до латала исполнения управляющей программы
Измерение (уточнение значенйй) корректирующих параметров
В рамках специального режима автоматического измерения параметров положения заготовок с автоматической модификацией параметров коррекции управляющей программы
Для успешного функционирования робота в условиях вариативно^ среды необходима разработка и реализация языков представления управляющих программ, позволяющих выразить требования к характеру реакции устройств управления (в ходе исполнения управляющей программы) на информацию, поступающую от средств очувствления промышленного робота. Одним из перспективных подходов к решению этой задачи является использование принципов построения движения, связанных с понятием активной податливости. Введение в язык управляющих программ гибких общих форм вада-г ния текущих целей требует реализации развитых алгоритмов планирования процесса исполнения управляющих программ.
Одной из актуальных задач перспективных разработок программного обеспечения для промышленных роботов является расширение состава возможностей резидентного инструментального программного обеспечения, включающее:
разработку средств реализации принципиально новых эффективных методов обучения (формирования управляющих программ);
определение и реализацию универсальных принципов автомата- ческой настройки модулей функционального программного обеспечения на работу с конкретной конфигурацией технологического оборудования (привязка к технологии);
определение и реализацию универсальных принципов настройки программного обеспечения на работу с конкретным типом промышленного робота (принципов привязки к' кинематике и приводу).
Для повышения эффективности и расширения возможностей обучения промышленных роботов необходимы качественно новые аппаратные средства реализации диалога человека-оператора с управляющими устройствами. ,
С вопросами совер1пенствовапия методов обучения тесно связаны вопросы реализации ручного управления роботом. Возможности ручного управления в современных промышленных роботах настолько ограничены, что в большинстве случаев человек-оператор лишен возможности непосредственно управлять с пульта выполнением технологической операции. Для того чтобы такая возможность стала реальной в широком диапазоне производственных условий, необходимо создание м освоение качественно новых типов пультовых средств, новых принципов управления. И то и другое означает создание качественно нового класса диалоговых языковых средств, ориентированных на реализацию ручного управления очувствленными промышленными роботами.
К задачам ручного управления непосредственно примыкают задачи распшрения возможностей влияния человека-оператора на ход исполнения управляющих программ (супервизорное управление процессом их исполнения),
Создание достаточно универсального языка привязки к технологии является серьезной научно-технической проблемой, общей для устройств управления промышленных роботов и устройств управления для обрабатывающих станков. В части определения принципов привязки к роботу необходима разработка универсального языка спецификации кинематики, динамики и привода промышленных роботов и разработка трансляторов, преобразующих эти спецификации в эффективно работающие модули функционального программного обеспечения.
Большое значение для повышения эффективности разработок программного обеспечения для промышленных роботов имеет даль- нейшее развитие специализированных инструментальных комплек- сов. Следует подчеркнуть необходимость ориентации на постепенную эволюцию техники верификации разрабатываемого программного обеспечения от тестирования модулей и версий систем к доказательству корректности принимаемых алгоритмических решений и текстов программ. А это, в свою очередь, требует эволюции формальных и полуформальных языковых средств для представления общей организации алгоритмов и данных и детализации принятых общих решений.
Проблемы развитая программного обеспечения для промышленных роботов неразрывно связаны с созданием и усовершенствованием соответствующих языковых средств (табл. 2).
Многие из затронутых вопросов (например, создание инструментального обеспечения) являются общими вопросами развития технологии программирования. Часть специальных вопросов может решаться совместно для устройств управления промышленными роботами и устройств управления обрабатывающими станками (например, язык привязки, стенды испытания программного обеспечения систем реального времени, многие вопросы взаимодействия с человеком-оператором). Вместе с тем есть вопросы, сугубо специфические для промышленных роботов: принципы привязки программного обеспечения к требуемой кинематике робота, обучение,
Назначение языковых средствНазначение языковых средствПредставление управляющей программыПредставление управляющей программыРазработка общей структуры сигнальных связей между элементами и блоками программного обеспеченияРазработка алгоритмов функционирования блоков и систем программного обеспеченияРазработка общей структуры сигнальных связей между элементами и блоками программного обеспеченияРазработка алгоритмов функционирования блоков и систем программного обеспеченияИнформационный обмен между блоками системы программного обеспеченияУправление процессом формирования управляющей про- rpaiiMbi (например, в режиме обучения)Ручное управление промышленными роботами и робототехническими комплексамиОписание условий взаимодействия промышленных роботов с технологическим оборудованиемОписание особенностей конструкции и привода промышленных роботовВмешательство оператора в ход исполнения управляющей программыИнформационный обмен меж- "у управляющим устройством и внешним оборудованиемИнформационный обмен между блоками системы программного обеспеченияУправление процессом формирования управляющей про- rpaiiMbi (например, в режиме обучения)Ручное управление промышленными роботами и робототехническими комплексамиОписание условий взаимодействия промышленных роботов с технологическим оборудованиемОписание особенностей конструкции и привода промышленных роботовВмешательство оператора в ход исполнения управляющей программыИнформационный обмен меж- "у управляющим устройством и внешним оборудованием
Назначение языковых средств
Назначение языковых средств
Представление управляющей программы
Представление управляющей программы
Разработка общей структуры сигнальных связей между элементами и блоками программного обеспечения
Разработка алгоритмов функционирования блоков и систем программного обеспечения
Разработка общей структуры сигнальных связей между элементами и блоками программного обеспечения
Разработка алгоритмов функционирования блоков и систем программного обеспечения
Информационный обмен между блоками системы программного обеспечения
Управление процессом формирования управляющей про- rpaiiMbi (например, в режиме обучения)
Ручное управление промышленными роботами и робототехническими комплексами
Описание условий взаимодействия промышленных роботов с технологическим оборудованием
Описание особенностей конструкции и привода промышленных роботов
Вмешательство оператора в ход исполнения управляющей программы
Информационный обмен меж- "у управляющим устройством и внешним оборудованием
Информационный обмен между блоками системы программного обеспечения
Управление процессом формирования управляющей про- rpaiiMbi (например, в режиме обучения)
Ручное управление промышленными роботами и робототехническими комплексами
Описание условий взаимодействия промышленных роботов с технологическим оборудованием
Описание особенностей конструкции и привода промышленных роботов
Вмешательство оператора в ход исполнения управляющей программы
Информационный обмен меж- "у управляющим устройством и внешним оборудованием
Направление развития языковых средств данного назначения
С усложнением состава задач, возлагаемых на промышленные роботы, расширяется разнообразие и усложняется семантика конструкций языка
Схемы программ, графические изображения формального типа (например, сети Потри)
Средства представления алгоритмов и структур данных различных уровней и степени формализации — языки уровня ассемблера, формальные и полуформальные языки высокого уровня
Разработка унифицированной системы внутренних представлений — состава форматов структур данных, служащих для представления текущих состояний процессов
Создание эффективных диалоговых средств составления и редактирования
Разработка качественно новых диалоговых средств для взаимодействия оператора с про- мышлепными роботами, оснащенными развитыми средствами очувствления
Повышение уровня языка спецификаций технологических команд (языка привязки к технологии)
Создание формальных средств описания кинематики и динамики промышленных роботов, организации интерфейса с приводами промышленных роботов
Развитый диалог между устройством управления и человеком-оператором
Разработка унифицированных интерфейсов и протоколов обмена
активная податливость и т. н. Круг вопросов, которые необхоаиан〉 решать для продвижения в развитии программного обеспечения промышленных роботов, настолько широк, отдельные вопросы так сложны, что эффективное решение их возможно только при условии объединения значительных усилий различных коллективов, их ра- Циональной специализации и кооперирования.
УДК 621.8
КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ СИСТЕМЫ УПРАВЛЕНИЯ РОБОТОТЕХНИЧЕСКИМИ КОМПЛЕКСАМИ
А. Н. Домарацкий
Изучение и анализ предшествующего этапа развития программного обеспечения систем управления робототехническими комплексами (РТК) показывают, что преобладающим подходом к созданию программного обеспечения этих систем являлось функциональное программирование [1]. Существенным недостатком функционального программирования является отсутствие системного подхода к разработке программного обеспечения, что обусловливает несовместимость многих функциональных программ и в значительной мере затрудняет и тормозит широкое внедрение РТК в различных отраслях народного хозяйства.
Такое положение дел привело к тому, что возникла потребность в выработке определенной теоретической концепции создания программного обеспечения систем управления РТК, которая бы не только способствовала разработке целостных систем (а не обособленных функциональных программ), но и повышала бы строгость подхода к проектированию систем, содействовала бы созданию соответствующих средств отображения проектных решений, увеличивала бы повторяемость результатов и активность функции изобразительных средств в процессе эволюции проекта программного обеспечения и сопровождения готового программного продукта.
В настоящей работе предпринята попытка выработки такой концепции. Здесь не будет дано полной разработки соответствующей теории вплоть до получения завершающих формул и формализованного описания систем управления РТК. Мы постараемся лишь изложить на концептуальном уровне подход к разработке систем управления и их программного обеспечения. При изложении будем стараться придерживаться системного подхода.
Основой разрабатываемой концепции является то, что программное обеспечение управляющих систем представляет собой целостную систему, т. е. система программного обеспечения есть часть более крупного образования и представляет собой • совокупность взаимодействующих компонент , [2]. Отметим, что с увеличением размеров системы опа постепенно становится сложной, а затем и чрезвычайно сложной. Часто ф.ункциональные свойства систем невозможно выразить современными методами описаний. В таких условиях повышается роль моделирования, которое в настоящее время представляет собой одно из самых эффективных средств преодоления затруднений, связанных со сложностью систем. Модели помогают глубже понять общее назначение системы, общие особенности автоматизированного комплекса, в рамках которого система должна функционировать, особенности аппаратных средств, на которых сис-
тема может быть реализована, и т. п. Применение модели на этапе разработки программного обеспечения облегчает восприятие и осознание возможностей системы и способствует выработке совокупности правил построения программного обеспечения, которые можно было бы принять в качестве стандарта во всех ведущихся разработках программного обеспечения, и этим обеспечить высокую степень повторяемости результатов и совместимости создаваемых программных систем.
В разработке модели важную роль играет использование абстракции. Упрощенное описание системы, подробно освещающее лишь некоторые ее части, важные для понимания, по крайней мере, в данный момент, и вовсе не касающееся остальных, помогает связать разрозненные части системы одной идеей. Это позволяет представить сложную систему в целом, выявить ее глобальные связи, определить ее главные возможности и свойства, отвлекаясь от излишних подробностей и конкретной физической реализации. Иерархия абстракций дает возможность описать систему с любой степенью подробности.-.
Как отмечалось, основное свойство любой системы заключается\ в том, что она является составной частью более крупного образова- ния и сама состоит из совокупности компонент. При этом сущест- 1 вуют взаимосвязи элементов, включенных в состав системы, как между собой, так и с элементами, оставшимися за ее пределами. Совокупность элементов, оставшихся за пределами .системы, называют окружающей средой, в которую система погружена и в которой она функционирует. Окружающую среду абстрактно можно понимать как совокупность взаимодействующих процессов, а систему, погруженную в окружающую среду,— как один из этих процессов. В то же время любой процесс в этой абстракции можно рассматривать как совокупность более простых взаимодействующих процессов.
Попытаемся создать концептуальную модель систем управления РТК с использованием концепций абстрактных представлений, иерархических структур и модульных построений.
Представим концептуальную модель в виде абстрактного информационного объекта, погруженного в окружающую среду. Специфицируем функциональные свойства информационной структуры такого объекта и связанные с ними действия системы. При специ- фикации функциональных свойств информационной структуры абстрактного объекта будем исходить из того, что функциональные свойства любой системы проявляются через ее взаимодействие с окружающей средой, а для осуществления таких взаимодействий в системе должно существовать некоторое отображение этих свойств. Теперь в информационной структуре абстрактного объекта выделим ту ее часть, которая определяет, что именно может делать система, т. е. ее функциональные возможности. Эту часть объекта назовем функциональной и представим ее множеством функциональных процессов. Они определяют внешнюю деятельность системы через ее взаимодействие с окружающей средой. Придадим функцио-
нальным процессам возможность взаимодействовать со всеми процессами абстрактного информационного объекта и окружающей средой.
Оставшуюся часть информационной структуры объекта назовем базисной и представим ее множеством базисных процессов. Прямой функциональной нагрузки системы они не несут, т. е. результаты их работы в явном виде не присутствуют во внешних проявлениях системы. Множество базисных процессов наделим свойством взаимодействия лишь с функциональными процессами своего объекта. Функциональные свойства базисных процессов заключаются в организации требуемого взаимодействия системы с окружающей средой и обеспечивают соответствие функциональных процессов существующему уровню технологии технических средств, с использованием которых осуществляется физическая реализация системы, т. е. множество базисных процессов является базисом, на котором строится работа функциональных процессов.
Выделим условную границу абстрактного информационного объекта с окружающей средой. Через эту границу осуществляется обмен информацией о событиях в окружающей среде и системе (обмен информацией между множеством функциональных процессов системы и процессами окружающей среды). События, происшедшие в окружающей среде, сопровождаются (при необходимости) сообщениями, которые пересекают условную границу системы и предназначены для функциональных процессов системы. Они принимают эти сообщения и в соответствии с их содержанием либо изменяют состояние системы, либо реализуют ту или иную функцию системы, о чем в окружающую среду могут быть переданы ответные сообщения.
Обычно на условной границе между системой и окружающей средой определяют совокупности правил для осуществления обмена информацией, которые определяют содержание понятий интерфейсов системы [3]. ，
Специфицируя далее функциональные свойства информационной структуры абстрактного информационного объекта, во множестве функциональных процессов выделим подмножества, ориентированные на выполнение отличных друг от друга взаимодействий с окружающей средой и отражающие различные функциональные свойства объекта, т. е. установим, что каждое его функциональное свойство отображается своим подмножеством ф ункциональных процессов и проявляется через взаимодействие этого подмножества с окружающей средой. При этом разные по характеру взаимодействия с окружающей средой могут выполняться через различные интерфейсы. Условную границу абстрактного информационного объекта с окружающей средой разобьем на отдельные участки, на каждом из которых определим интерфейс для осуществления таких взаимодействип.
Разработанная модель (см. рисунок) создавалась ради облегчения возможности выработки общих принципов построения программного обеспечения систем управления РТК.
Для более полной ясности функций процессов, из которых согласно принятой модели состоит система, целесообразно осуществить их структурирование.
Заметим, что обоснованное структурирование предполагает наличие соответствующих критериев. Ограничимся лишь концептуальными «руководящими» принципами структурирования, так как выработка критериев не входит в задачу настоящего изложения.
Известно, что общим способом структурирования является иерархическое упорядочение [4]. Прежде чем приступить к структурированию процессов абстрактного информационного объекта, сформулируем основные «руководящие» принципы, из которых и будем исходить.
Главная задача, которую приходится решать при структурировании ради получения ясных представлений,— выбор ограниченной степени сложности выполняемых функций на иерархических уровнях. При этом следует исходить из того, что разрабатываемые системы программного обеспечения создаются для людей, т. е. эксплуатировать, поддерживать и сопровождать их будут люди. Поэтому важно, чтобы на каждом выделяемом уровне была ограничена семантическая нагрузка и было понятно и ясно, что же на нем происходит. Отсюда в качестве первого принципа отметим наличие ограниченной (легко понимаемой человеком) функциональной нагрузки на каждом выделенном иерархическом уровне.
Естественно, что выделение иерархических уровней следует производить так, чтобы изменения на одном из них не приводили к сравнимым изменениям на других уровнях или вовсе пе приводили ни к каким изменениям, т. е. так, чтобы иерархические уровни 6blлм функционально и информационно изолированными. Функциональная и информационная изолированность уровней иерархических систем обусловливает их высокую гибкость, так как обеспечивается исключительная простота внесения изменений и адаптации к кон-
Кретным применениям. Функциональную и информацйонйую йзолй ровапность иерархических уровней можно принять в качестве вто рого руководящего принципа структурирования.
Выделим в определенных на каждом иерархическом уровне функциональных возможностях небольшой набор общих функций, отражающих лишь суть выполняемых действий на этих уровнях и не связанных ни с формой проявления этих действий, ни с методами их реализации. Выделение на уровнях ограниченного набора функций с такими свойствами обеспечит высокую степень исиоль зования принятого структурного решения для реализации спетом управления во многих возможных применениях. Тогда в качесгве третьего принципа можно определить наличие на каждом иерархическом уровне ограниченного набора общих функций.
Наконец, при «настройке» концептуальной модели на конкретное применение могут возникнуть трудности, обусловленные на ли чиел! па каждом уровне рамок ограниченного набора общих функций. Чтобы избежать этих осложнений, необходимо предусмотреть возможность выбора из заранее подготовленных совокупностей функциональных возможностей на каждом иерархическом уровне. Такие совокупности должны быть ориентированы на обеспечение проявления конкретных функциональных свойств системы. В концептуальной модели они отображаются соответствующими подмножествами функциональных процессов. Набор общих функций, отражающих лишь суть выполняемых действий на иерархических уровнях, и совокупности функциональных возможностей, присущих каждому иерархическому уровню, образуют двумерную структуру функциональных процессов абстрактного информационного объекта. Совокупности возможностей обычно называют подмножествами функций. Возможность выбора подмножества функций на иерархических уровнях можно принять за четвертый руководящий принцип структурирования.
Таким образом, мы определили четыре основных «руководящих» принципа структурирования процессов абстрактного информационного объекта:
ограничение функциональной нагрузки на каждом иерархическом уровне；
обеспечение функциональной и информационной изолированности иерархических уровней;
выделение на иерархических уровнях ограниченного набора общих функций, отражающих лишь суть выполняемых действий;
обеспечение возможности выбора подмножества функций, присущих иерархическим уровням и отражающих конкретные функциональные свойства системы.
Перейдем теперь к структурированию функциональных процессов абстрактного информационного объекта. В качестве уровня основания иерархии множества функциональных процессов можно принять условную границу объекта с окружающей средой. На этой границе определяются интерфейсы системы. Общей фз^нкцией, выполняемой всеми системами на этом уровне, является обмен инфор
мацией с окружающей средой. Здесь не важны пи форма, ни способы формирования потоков информации в системах и из окружающей среды. Существенно только то, что именно на этом уровне информация пересекает условную границу системы с окружающей средой. Назовем этот уровень функциональных процессов уровнем интерфейсов системы.
Осмысленное взаимодействие любой системы с окружающей средой не может происходить само собой, а обязательно требует управления. Причем функции управления взаимодействием с окружающей средой (организация сеанса связи, управление приемом и передачей информации) являются общими для систем всех возможных применений. Поэтому целесообразно выделить выполнение этих функций как отдельный иерархический уровень. Существенно то, что на этом уровне необходимо лишь обеспечить управление обменом информацией, пересекающей уровень интерфейсов. Функциональная изоляция собственно обмена и управления обменом, выделение этих функций для выполнения на смежных иерархических уровнях позволяют обеспечить широкое разнообразие методов взаимодействия системы с окружающей средой и обеспечивает разработчику возможность иметь большую свободу выбора таких методов при «настройке» концептуальной модели на конкретное применение.
Характерное свойство системы — возможность функционирования в окружающей среде автономно. Поэтому в системе и в окружающей среде могут использоваться независимые способы формирования потоков информации для обмена. В этом случае синтаксис и семантика сообщений системы и окружающей среды могут быть различными. Для того чтобы взаимодействие между ними происходило на уровне взаимопонимания, необходимы средства, которые бы выполняли перевод сообщений из представлений окружающей среды (внешних представлений) во внутренние представления системы и наоборот. Обратим внимание на то, что согласование представлений при этом может выполняться лишь после того, как сообщение принято из окружающей среды или подготовлено для передачи. Функция согласования представлений является общей для системы, и целесообразно выделить выполнение этой функции как следующий после уровня управления приемом и передачей сообщений иерархический уровень (третий снизу). Здесь существенным является сам факт согласования внутренних и внешних представлений, а не конкретные синтаксис и семантика сообщений.
Во взаимодействии системы с окружающей средой на уровне взаимопонимания система дол?кпа реагировать на сообщения извне лишь после того, как они приняты и осуи^ествлено преобразование внешних представлений во внутренние. Для того чтобы выработать реакцию на внешние сообщения, необходимо, чтобы в системе выполнялись какие-либо действия. Заметим, что для подготовки сообщений во внешнюю среду в системе также обязательно выполнение некоторых действий. Поэтому в системе можно выделить функционально изолированный уровень, на котором выполняются действия,
характеризующие состояние системы и ее внешнее поведение. На этом уровне общим для всех систем является выполнение собственных действий, результат выполнения которых проявляется в изменении состояния системы или во внешнем поведении ее. Причем на этом уровне существенно то, что выполняются собственно действия системы, а не то, как они выполняются и какие они, т. е. общей функцией этого уровня является выполнение собственно действий системы. Назовем этот иерархический уровень (четвертый снизу) уровнем действий и состояний системы.
Наконец, любая система функционирует в окружающей среде не беспорядочно, а как-то координирует свои действия в зависимости от текущей ситуации. При этом система может планировать свое поведение в окружающей среде. Конечно, планирование поведения системы — это не простая работа и требует наличия в системе средств определенной сложности. Не во всякую техническую систему целесообразно включать такие средства, но элементы планирования присущи многим системам. Поэтому планирование поведения системы можно определить в качестве общей функции системы и выделить иерархический уровень (уровень планирования действий и состояний системы) для ее выполнения. 『
Подводя итог членению функциональных процессов по иерархии, отметим их пятиуровневую структуру. Естественно, что в некоторых практических системах старший иерархический уровень рассмотренной модели (уровень планирования действий и состояний системы) может быть вырожденным или отсутствовать совсем, а в высоко интеллектуальных системах может потребоваться введение и более высоких уровней.
Построенная концептуальная модель (см. рисунок) и принятая иерархия функциональных процессов обеспечивают эффективное использование модульного принципа при разработке программного обеспечения РТК и обусловливают возможность разработки такого программного обеспечения как целостной системы. Составляющие такую систему модули представляют собой структурные элементы (программы или данные), позволяющие строить систему, отвлекаясь от несущественных для конкретного этапа подробностей, использовать в новых разработках готовый (и, что особенно важно, апробированный и работоспособный) программный задел предшествующих работ.
В заключение отметим, что идеи, лежащие в основе изложенной концепции создания программного обеспечения системы управления РТК, заложены в разработанную в ЛИИАН систему алгоритмических модулей управления роботами АМУР-80 [5]. С использованием этой системы создано и npora.no испытание программное обеспечение системы управления сварочным роботом, которое осуществлялось совместными усилиями ЛИИАН, Института прикладной математики им. М. В. Келдыша АН СССР в кооперации с другими организациями. Испытания, проведенные в натурных, условиях, прошли успешно и показали, что использование разработанной методики способствовало созданию целостной системы программного
обеспечения, повысило строгость подхода к проектированию системы, обеспечило высокую повторяемость результатов при компоновке системы из различных программных модулей, упростило адаптацию системы к конкретному применению и обеспечило легкость взаимодействия разобщенных коллективов при разработке системы.
ЛИТЕРАТУРА
Хатвани 庭.,Янош Й. Программные изделия для систем проектирования и управления производством.— ТИИ9Р, 1980, т. 6& № 9, с. 13—17.
Управление, ипформадия, интеллект/Под ред. А, И. Берга и др. М.: Мысль, 1976. 383 с.1
Интерфейс для программируемых приборов в системах автоматизации эксперимеита/Н. И. Гореликов, А. Н. Домарацкий, С. Н. Домарацкий, В. А. Лнскпн, Н. В. Попепко, Л. С. Ситников. М: Наука, 1981. 264 с.
Лйнгер Р., Миллс X., Уитт Б. Теория и практика структурного программирования. М.: Мир, 1982. 406 с.
Пономарев В. М., Домарацкий А. Н., Никифоров В. В. Система алгоритми- ческих модулей управления роботом — АМУР-80： Препр. ЛНИВЦ АП СССР № 20. Л.，1981. 50 с.
УДК 681.32
СИСТЕМА ВЗАИМОДЕЙСТВИЯ ПАРАЛЛЕЛЬНЫХ ПРОЦЕССОВ В УПРАВЛЯЮЩИХ
МНОГОМАШИННЫХ КОМПЛЕКСАХ, ПОСТРОЕННЫХ НА БАЗЕ МИКРО ЭВМ
А. Н. Домарацкий, А. В. Каширин, Н. Д. Проскурина
В настоящее время актуальна задача распределенных систем управления. Проводятся интенсивные исследования в этом направлении (см., например, [1—3]). Однако существует ряд факторов, затрудняющих реализацию и использование распределенных систем управления. Такое положение вынуждает искать оригинальные решения при проектировании программного обеспечения для многомашинных систем управления, основываясь на идеях общего характера из предыдущих исследований и на имеющихся языковых возможностях. Полученные решения имеют конкретное выражение в виде совокупности понятий, функциональных моделей системы, модели структуры, организации программ и вычислительных процессов в соответствии с используемыми методами программирования и системой автоматизации проектирования программного обеспечения. Примером такого подхода является комплекс работ, проводимых под названием АМУР [4, 5].
В предлагаемой статье описывается логическая организация взаимодействия программных процессов в многомашинных управляющих комплексах на основе микро-ЭВМ «Электроника-60».
Как и для любой программной системы, качество описания и результаты проектирования непосредственно зависят от используемых средств отображения црютмармых рещеций [6, 7]. Средства отобра-
2 Заказ № 2403"
жения должны служить не столько иллюстрацией к тексту на естественном языке, сколько базой для построения абстрактных моделей разрабатываемой системы. Модели облегчают понимание как функ циональных, так и нефункциональных характеристик программной системы. При дальнейшем изложении будем стараться придержи ваться принципа, высказанного в статье [8], т. е. думать не о построении хорошей модели вычислительной системы, а о построении вычислительной системы, возможно более близкой к хорошей мо~ дели.
На используемом уровне абстракции достаточно понимания понятия программного процесса как последовательности действий логической машины над данными из доступной памяти. Будем использовать графическую систему обозначений, элементы которой (и отношения между ними) показаны на рис. 1. Вопросы анализа и сравнения используемой графической нотации в данной статье не рассматриваются. Информацию о других способах отображения программных средств можно получить из работ [6, 9].
Исходные требования к описываемым ниже программным средствам вытекают из анализа принципов организации взаимодействия программных процессов в одномашинной системе управления на микро-ЭВМ «Электроника-60». Их описание и пример реализации даются в работах [4, 5].
Базовая модель одномашинной системы управления изображена на рис. 2. Система управления представляет собой совокупность взаимодействующих последовательных прогрессов (функциональные процессы). Эта совокупность разбивается на программные и внешние процессы. Внешние процессы составляют окружающую среду для программных процессов и являются концептуальными понятиями, вводимыми для представления взаимного влияния состояний и событий объектов окружающей и программной среды. Не принимая во внимание детали реализации этого взаимного влияния, будем считать, что отдельные «действия» внешних процессов выполняются над данными в памяти вычислительной машины. Такое предположение позволяет использовать одинаковые понятия для программных и внешних процессов, что вводит однородность в концептуальное представление системы управления. Взаимодействие функциональных процессов осуществляется через общие элементы данных (структуры данных) и через использование общих подпрограмм, хранимых в памяти ЭВМ (рис. 3). Наряду с элементарными типами данных машинного языка (байты, слова) используются семафорные переменные, изменяемые с помощью операций UP и DOWN [10].
Семафорные переменные и операции над ними используются для синхронизации доступа к общим ресурсам параллельных процессов (совместные семафоры), а также для управления порядком их протекания (собственные семафоры) [4]. В случае отсутствия явного задания упорядоченности параллельных процессов используется механизм фиксированных приоритетов, реализованный также в рамках семафорных операций. Для упрощения примем, что внешние процессы могут выполнять только UP-операции над собствен-
рис. 1. Система графических обозначений, используемых при описании взаимодействия параллельных процессоврис. 1. Система графических обозначений, используемых при описании взаимодействия параллельных процессовРис. 2. Базовая модель одномашинной системы управленияРис. 2. Базовая модель одномашинной системы управлениярис. 3. Элементарные типы взаимодействий программных процессоврис. 3. Элементарные типы взаимодействий программных процессов
рис. 1. Система графических обозначений, используемых при описании взаимодействия параллельных процессов
рис. 1. Система графических обозначений, используемых при описании взаимодействия параллельных процессов
Рис. 2. Базовая модель одномашинной системы управления
Рис. 2. Базовая модель одномашинной системы управления
рис. 3. Элементарные типы взаимодействий программных процессов
рис. 3. Элементарные типы взаимодействий программных процессов
ными семафорами, т. е. внешние процессы не могут синхронизироваться через совместные семафоры.
Дадим краткую формулировку требований к программным средствам, реализующим взаимодействие функциональных процессов в многомашинном комплексе. Основное функциональное ограничение на средства взаимодействия процессов заключается в необходимости использования результатов программирования для одномашинной системы управления в многомашинном варианте без какой-либо модификации, вплоть до уровня объектных модулей. Топология связей отдельных ЭВМ многомашинного комплекса считается произвольной (функциональные возможности устройств связи ЭВМ определяются исходя из потребностей абстрактных моделей). Соответствие между отдельными функциональными процессами и ЭВМ комплекса, где
^йй могут протекать, устанавливается статически при компоновке системы. Ограничений на распределение множества функциональных процессов по отдельным ЭВМ не накладывается. Заметим, что вопросы выбора топологии комплекса и распределения процессов в данной статье не рассматриваются. Считается, что конкретная система управления может быть реализована множеством способов.
Описываемые средства взаимодействия процессов опираются на следующие проектные решения. Множество функциональных программных процессов (включая и общие данные) разбивается па подсистемы процессов. Между подсистемами процессов и ЭВМ комплекса устанавливается взаимное однозначное соответствие. Процессы одной подсистемы, «действия» которых выполняются над общими данными из второй подсистемы (внешние данные), естественным образом становятся внешними процессами ио отношению ко второй: подсистеме. Далее будем называть их внешними программными процессами в отличие от внешних процессов, соответствующих процессам окружающей среды. Будем считать, что в состав всех подсистем входят копии всех общих программ, к которым обращаются процессы подсистем, в то время как каждая общая структура данных хранится в памяти только одной ЭВМ. Основная функция средств взаимодействия процессов формулируется следующим о除а- зом: во время выполнения «действий» программного процесса выделить 《действия» над внешними данными и реализовать их так, как будто эта данные хранятся в памяти той же ЭВМ. Такие «действия» разбиваются иа два типа: семафорные операции над внешними семафорными переменными и адресные команды (двухадресные и одноадресные для ЭВМ «Электроника-60»), операнды которых являются внешними данными. Взаимодействие подсистем процессов рассматривается как объединение сигнального (семафорные операции) 五 информационного (адресные команды) взаимодействий.
Основу средств взаимодействия процессов составляет комплект подпрограмм, копии которого хранятся в памяти каждой ЭВМ комплекса. Попытка выполнить «действие» функционального процесса над внешними данными сопровождается неявной передачей управления средствам взаимодействия процессов, которые программно моделируют это «действие», используя аппаратные связи комплекса и собственные данные. Каждая копия программы средств взаимодействия процессов снабжается собственными данными, которые описывают пути доступа к внешним данным для соответствующей подсистемы функциональных процессов, а также информацию для выполнения «действий» внешних программных процессов и являются множеством дескрипторов, типы которых и отношение пути доступа между ними изображены на рис. 4 (для случая, когда ЭВМ комплекса связываются через общую цамять). Дескриптор процесса включает в себя информацию о состоянии процесса, значение его приоритета и указатели на дескрипторы внешних данных, необходимых для протекания процесса. Дескриптор внешней структуры данных содержит поля с информацией для его поиска при обработке неявного вызова средств взаимодействия процессов из функциональных процессов,
индивидуальный код этой структуры данных и указатель места се хранения. Местом хранения может быть либо локальная память рассматриваемой ЭВМ, либо память соседней ЭВМ (с которой имеется физическая связь, например, общая память). Структура и содержание дескрипторов соседних ЭВМ и сегментов общей памяти существенно зависят от реализации средств связи ЭВМ и несут информацию, необходимую для реализации абстракции внешних программных процессов. Разбиение описания аппаратных средств связи на два типа целесообразно для случая, когда сегмент общей памяти связывает более двух ЭВМ комплекса. Выполненное структурирование собственных дапных. средств взаимодействия процессов способствует локализации модификаций при изменениях в разбиении на подсистемы процессов, места хранения общих данных, топологии связей ЭВМ комплекса.
Модели взаимодействия двух подсистем процессов через общие данные изображены на рис. 5—7. В приведенных примерах используется такой уровень детализации «действий» процессов, при котором механизм вызова «действий» через аппаратную связь ЭВМ (внешние действия) не уточняется. Полагается, что перед выполнением внешнего «действия» средства взаимодействия процессов могут определить, как и в какой ЭВМ комплекса оно должно происходить, а во время выполнения внешнего «действия» — в какой ЭВМ протекает данный внешний программный процесс. Началу выполнения внешнего «действия» предшествует формирование параметров для него. Общим моментом для всех моделей является способ неявного вызова средств взаимодействия процессов из «действий» функциональных процессов над внешними данными. Вызов средств взаимодействия процессов сопровождается подготовкой (также неявной) параметров,1 необходимых для поиска соответствующих дескрипторов внешних данных (для микро-ЭВМ «Электро- ника-60» таким механизмом может быть прерывание при обращении к несуществующей памяти, если между элементами внешних данных и адресами незанятой области адресного пространства устанавливается взаимно однозначное соответствие).
Взаимодействие подсистем процессов основывается на возможностях СВП выполнять ряд типов внешних «действий». Для сигнального взаимодействия они показаны на рис. 5 и 6 (отметим, что нумерация потоков информации па рисунках совпадает с порядком их возникновения).
Для представления DOWN-операции над внешним семафором вводятся понятия «образа» и «оригинала» внешнего семафора. «Оригинал» семафора соответствует месту храпения действительного состояния семафорной переменной,- «образ» семафора — семафорной переменной, вводимой только для задержки функциональных процессов на время выполнения DOWN-операции над «оригиналом» внешнего семафора. Необходимость активации специального процесса СВП при выполнении DOWN-олерации над внешним семафором, связана с отмеченными выше особенностями реализации «действий» внешних процессов над семафорами.
Используются при неявном вызове из функциональных процессов
■^*о Аескрмптори процессов-「)
Глобальные имена данных СВП
Используются внешними программными < процессами
Дескрип юры внешних данных и данных:, требуемых внешним программным процессом
Дескрипторы сегментов общей памяти
Дескрипторы соседгшх ЭВМ
Рис. 4. Схема пути доступа к элементам данных средств взаимодействия процессов
EDO①Hodu doIUMdNJB4
rtao^«soo comEdgocc 9K К5эаф§|^р
sMtTBd ①口 o< NMOCI HHHBHITOLHq BJJOIIOdll 工。Au ，Em и tesyrt§H^<
KsfflHU^OH- OJBHTH ① н od① EBdEU ёхлдо&з&в
Рис. 5. Выполнение UP-операции над внешним семафором
1, 2 — индивидуальный код семафора; з — адрес семафора
Модель элементарною шага информационного взаимодействия изображена на рис. 7. Ограниченный объем статьи не позволяет детализировать отдельно «действия» моделирования адресной команды, поскольку их раскрытие связано с условиями ветвления алгоритма моделирования (зависимость от количества операндов, места их хранения). При их реализации используются два типа внешних «действий»: определение значения операнда и выполнение заданной машинной команды. Применяя первое действие, внешний програм-
^§ф
о Ойо ^Зд-Ж5доау^ нА е
(
< rk
моаофрп①j SSSSOKm 口H Mnpd ①uo,nmq£1_
раофЕЕВ。CCIfBHSJHdocc
SHtelE1s① mgoH ① wj ①
Е<1офЕИ1 ①。c*Md9o 大
раофЕЕ ①。CCEOIrBHHJHdo大 экEHnEdg口O.NOCT
loss-
rd工。①R
xlqHHE4zd
С
OJBHm ① ни HOdlBWEdEU ossffloassao©
ваофвигз。《EgEdg。》08dBВ 丨 9 $ -ваофвмз。
SNJKd①VBm O^OOE ^^ Bsupd① II0 ) 8ErnoiA① uL
(pdc^EwecamEdgoi eh EUJBnoduWM<d ①门
《EITBHMJHdo》oadHE — 寸-Edc^BNeo^FgEdoo》00§rt s HOM «SM^H.&rtsms«MS I gIE FBOdoalewgo кишпеннЕН sstfrta®a©lzfe^0Q ©ЯИ0ИН0ИЗМ .9 .она
Функциональный процессФункциональный процесс么пресная. Неявный команда (^ызов СВП么пресная. Неявный команда (^ызов СВП宜宜Следующая команда функционального процессаСледующая команда функционального процессаВыполнение команды^ (модификация элемента данных и определение значения слова состояния процессора)Выполнение команды^ (модификация элемента данных и определение значения слова состояния процессора)Формирование состояния функциональногопроцесса после выполнения адресной командыФормирование состояния функциональногопроцесса после выполнения адресной командыОпределение значения 、\ ^^модифицируемого операнда \\адресной командыJ(для двухадресной команды) уОпределение значения 、\ ^^модифицируемого операнда \\адресной командыJ(для двухадресной команды) уРис. 7. Модель выполнения адресной команды с операндами — внешними элементами данныхРис. 7. Модель выполнения адресной команды с операндами — внешними элементами данных
Функциональный процесс
Функциональный процесс
么пресная. Неявный команда (^ызов СВП
么пресная. Неявный команда (^ызов СВП
宜
宜
Следующая команда функционального процесса
Следующая команда функционального процесса
Выполнение команды^ (модификация элемента данных и определение значения слова состояния процессора)
Выполнение команды^ (модификация элемента данных и определение значения слова состояния процессора)
Формирование состояния функционального
процесса после выполнения адресной команды
Формирование состояния функционального
процесса после выполнения адресной команды
Определение значения 、\ ^^модифицируемого операнда \\
адресной командыJ
(для двухадресной команды) у
Определение значения 、\ ^^модифицируемого операнда \\
адресной командыJ
(для двухадресной команды) у
Рис. 7. Модель выполнения адресной команды с операндами — внешними элементами данных
Рис. 7. Модель выполнения адресной команды с операндами — внешними элементами данных
Дешифрация способов адресации операндов
I — код адресной команды (если команда двухадресная, то значение немодифицируемого операнда); 2 — состояние процессора； 3 ——состояние счетчика команд и регистров общего назначения
мный процесс получает значение элемента внешних данных по указателю пути доступа к нему. Результатом выполнения второго типа внешнего «действия» является выполнение машинной команды, задаваемой кодом операции, указателем пути доступа к элементу внешних данных — операнду команды, а для двухадресных команд — значением второго операнда. Значение состояния процессора непосредственно после выполнения внешнего «действия» такого типа используется для формирования состояния внешнего программного процесса при завершении моделирования адресной команды. Указатель пути доступа к элелгенту внешних данных включает в себя код внешней структуры данных, указатель положения элемента в структуре, способ адресации (косвенный или прямой), применяемой к элементу структуры.
В заключение отметим, что в статье приводятся модели взаимодействия фу нкци он альных процессов в многомашинной системе управления (являющейся расширением одномашинного варианта, описанного в работах [4, 5]), для чего вводится и используется специальная графическая нотация. Все программные модули средств взаимодействия процессов панисаны на языке Ассемблера микро- ЭВМ «Электронпка-60». Система средств взаимодействия процессов отлажена и успешно прошла этап тестирования.
ЛИТЕРАТУРА
Hansen Р. В. The Architecture of Concurrent Programs. New lersy： Prentic- Hall: Inc. Englewood, 1977. 317 p.
Язык программирования АДА. M.: Финансы и статистика, 1981. 189 с.
Hansen Р. В. Multiprocessor Architecture for Concurrent Programs.— Com- put. Architecture News, 1978, N 4, vol. 7, p. 4—32.
Пономарев В. М., Домарацкий А. Н., Никифоров В. В. Система алгоритмических модулей управления роботами — АМУР-80： Препр. ЛНИВЦ АН СССР № 20. Л, 1981. 50 с.
Домарацкий А. Я., Никифоров В. В. Программное обеспечение устройства контурного управления УКМ-772 для промышленных роботов.— Наст. сб.
Питерс Л. Дж. Методы отображения и компоновки программных средств.— ТИИЭР, 1980, т. 68, № 9, с. 55—66.'
Дейкстра 3. Дисциплина программирования. М.: Мир, 1978. 274 с.
Деннинг П. Дж. Как научиться: предсказывать.— ТИИЭР, 1980, т. 68, № 9, с. 74—80.
Зейв П. Определепке требований к программному обеспечению.— ТИИЭР, 1980, т. 68, № 9, с. 46-55. '
Дейкстра Э. Взаимодействие последовательных процессов.——В кн.: Языки программирования. М.: Мир, 1972, с. 9亠84.
УДК 681.32
МУЛЬТИПРОГРАММНЫЕ
И МУЛЬТИПРОЦЕССОРНЫЕ СИСТЕМЫ
УПРАВЛЕНИЯ РОБОТОВ
А. Ф. Верещагин, А. А. Дмитриев, Т. Н. Сизашева
Система управления современного адаптивного робота решает задачу целенаправленного взаимодействия ЭВМ и окружающей среды, включающей исполнительный механизм и приводы, сенсоры и терминалы, технологическое оборудование и человека-оператора. При этом в системе управления параллельно выполняется группа действий,» которые часто называют процессами. Если они связаны между собой сигналами, говорят об асинхронных процессах, если связаны со временем, то это синхронные процессы. Если время решения задачи не превышает времени исполнения объектом этого решения, то говорят о мультипрограммных системах реального времени. Именно их используют л ри управлении физическими объектами от ЭВМ.
У действительно адаптшшого робота цикл работы выполняется с допустимой задержкой относительно потока данных, поступающих и обрабатывающихся в ЭВМ. Если допустимая частота цикла работы определена, тогда проблема сводится к организации управления, аппаратного и программного обеспечения, соответствующих этой частоте.
В системах реального времени асинхронные процессы взаимодействуют между собой в форме связей данных «изготовитель—потребитель» или в форме синхронизации «ждать—вызывать». Эти процессы должны выполняться параллельно и независимо от того, сколько процесоров имеется в системе, хотя при наличии нескольких процессоров появляются дополнительные возможности аппаратным способом организовать синхронизацию задач и связь между ними.
Мультипрограммные системы. Функции мультипрограммной системы —обеспечение множества взаимодействующих в ЭВМ задач {71, Т2,..., Tjy}, разделяющих разнообразные ресурсы, включающие, кроме процессора, запоминающие устройства, регистры, флаги, подпрограммы ввода—вывода (В/В) и т. д. (рис. 1).
Рис. 1Рис. 1Рис. 2Рис. 2ПРЕРЫВАНИЯПРЕРЫВАНИЯи динамическое распределение ресурсов, являются обычными для опе- “полезнои динамическое распределение ресурсов, являются обычными для опе- “полезно
Рис. 1
Рис. 1
Рис. 2
Рис. 2
ПРЕРЫВАНИЯ
ПРЕРЫВАНИЯ
и динамическое распределение ресурсов, являются обычными для опе- “полезно
и динамическое распределение ресурсов, являются обычными для опе- “полезно
Потребности в мультипрограммировании не исчерпываются необходимостью обслуживания многих параллельных процессов. Существуют и другие преимущества, обусловленные четкой модульной структурой программного обеспечения (например, гибкость при модификации задач, возможность добавления новых задач, расширение системы для новых применений).
Такие функции мультипрограммирования, как одновременное обслуживание процессов с элементами координации и связи, разделение данных, приоритетное планирование
рационных систем мини-ЭВМ и больших систем. Особеннодля решения проблем управления роботами изучать операционныесистемы мини-ЭВМ из-за их широкого использования при автомати-зации технологических процессов различного назначения. Болеетого, некоторые микро-ЭВМ, такие, как «Электроника-60» и СМ-1800,могут непосредственно работать со штатными операционными си-стемами, реализующими все необходимые функции средствами об-щего типа. Требуемое для этого аппаратурное обеспечение (накопи-тели на магнитных дисках, расширенная оперативная память) может оказаться слишком дорогим и ненадежным в условиях массовогопромышленного применения. Вместе с тем возможности достаточноскромных аппаратных средств, содержащих микропроцессор (МП)с блоками постоянной и оперативной памяти (постоянные запоми-нающие устройства (ПЗУ) и оперативные запоминающие устройст-ва (ОЗУ) соответственно), интерфейсные платы ввода — вывода длясопряжения с объектом (рис. 2), в деле управления роботами далекоеще не исчерпаны, а способность таких средств надежно работатьв производственных условиях существенно выше. В этом случае все
программное обеспечение должно храниться в постоянных запоминающих устройствах и автоматически разворачиваться в рабочее состояние после включения питания. В частности, архитектура микро-ЭВМ «Электроника-60» и ее штатные комплектующие модули приспособлены для создания такой минимальной конфигурации си- бтемы управления.
Поэтому опыт существующих мультизадачных операционных систем общего назначения скорее всего является исходной точкой для разработки програмдшого обеспечения промышленных систем, основанных на микропроцессорах или микро-ЭВМ и ориёнтирован- ных на специализированное применение. Растущее разнообразие электронных средств, поставляемых промышленностью, все чаще позволяет смотреть на аппаратуру, операционную систему и входной язык системы управления как на единую архитектурную единицу, оптимизируемую с учетом задачи, для решения которой предназначена система.
В настоящее время все чаще появляются разработки так называемых «кремниевых» операционных систем реального времени, базирующихся в постоянных запоминающих устройствах и обеспечивающих простейшие, но достаточные для конкретного применения средства управления задачами и их взаимодействием. Объем ядра такой операционной системы в некоторых случаях не превосходит 100 байт. Создание специализированных операционных систем реального времени для обеспечения микропроцессоров и микро-ЭВМ, встраиваемых в системы управления роботов, представляет собой актуальную проблему, решение которой существенно упростит программирование робота для каждого нового применения.
В МВТУ им. Н. Э. Баумана ведется разработка и исследование принципов построения малых операционных систем реального времени для минимальной конфигурации аппаратных средств, реализуемых на микро-ЭВМ «Электроника-60». Исследования показали, что ядро (монитор) такой операционной системы, решающей задачу приоритетного обслуживания до 256 параллельных задач, занимает объем около 450 слов в памяти микро-ЭВМ.
Монитор выполняет диспетчерские функции в мультипрограммном обеспечении системы управления. Состав и структура монитора частично представлены на рис. 3. Отдельные более или менее автономные функции системы управления оформлены как параллельно выполняемые на одном процессоре задачи (процессы) Тъ...
взаимодействующие по принципу «поставщик—потребитель» через буферы данных Въ ...,В^ представляющие собой общие области памяти. Монитор реализует заранее заданную приоритетную дисциплину обслуживания, но в зависимости от прерываний (аппаратных или программных), поступающих для обработки в монитор от пульта управления, датчиков, таймера и аварийных сигналов, эта Дисциплина лтожет быть изменена.
Задача 71 поддерживает диалог с оператором, накапливая директивы и данные в буфере Bi в форме, доступной для последующего редактирования и исправления. Задача Т2 становится актив-
ной, как только информация в 笈，подготовлена для преобразования ее в план действий робота и траекторию исполнительного органа (в координатах рабочего пространства). Задача Т3 генерирует в реальном времени желаемые траектории исполнительных приводов манипулятора, выполняя обратное преобразование координат с контролем предприсанных скоростей и ускорений. Задача 7\ реализует контуры управления следящих систем приводов, получая информацию из буфера В&、обновляемого с высокой частотой (50 Гц) задачей 7\ которая опрашивает датчики положения и другие сенсоры. В результате в буфере 区& всегда имеется текущая информация о фактическом функционировании робота и другого технологичен ского оборудования. Эти данные критически оцениваются задачей Тв с отображением результатов оценки и рекомендаций на пульте оператора, а при ненормальном ходе процесса вырабатываются аварийные прерывания.
Построенная система открыта для включения других задач и организации других взаимодействий между задачами. В частности, задача генерации траекторий робота (Т3) должна в некоторых qjiy- чаях иметь своевременный доступ к информации, имеющейся в буфере В4, для корректировку траекторий, например, в зависимости от скорости движения конвейера или фактических результатов работы. Все программы в этой системе дол/кпы быть написаны на языке Ассемблера для достижения минимальных объемов используемой памяти. Однако в более мощных управляющих вычислительных системах, построенных на базе ЭВМ «Электроника-60» или СМ-3, -4 с использованием, например, дисковых накопителей, аналогичные вопросы построения мультипрограммной системы управления робота могут быть эффективно решены в рамках семейства операционных систем РА①ОС и ОСРВ, а также языков MODULA-2 и CASIC. Язык высокого уровня CASIC содержит специальные операторы для программирования аппаратуры КАМАК. В МВТУ им. Н. Э. Баумана ведутся опытные разработки по применению указанных языков и систем для управления адаптивными роботами новых поколений.
Мультипроцессорные системы. Уменьшение стоимости микропроцессоров делает все более привлекательными мультипроцессорные системы но сравнению с мини-ЭВМ эквивалентной производительности. Проектировщик все чаще рассматривает микропроцессор как относительно дешевый элемент, на котором можно реализовать с помощью программирования одну относительно самостоятельную функцию.
Первое очевидное решение в нашей задаче управления роботом 一 передача функции управления приводами отдельному микропроцессору. При этом может оказаться не слишком расточительным выделение каждому приводу персонального микропроцессора. Его задача — организовать качественное слежение за уставками, передаваемыми с центральной ЭВМ. Такая работа микропроцессора в качестве контроллера оправдывается тем, ”то путем перепрограммирования при одном и том же аппарату])пом решении можно 44
обеспечить различные характеристики управления для каждого конкретного привода.
Такие контроллеры могут быть использованы и сложными сенсорами (такими, как визуальные датчики или многокомпонентные сп- лометрическпе датчики) для управления режимами и предобработки измеряемых величин.
Изучение требуемых программно-аппаратных свойств мультипроцессорной конфигурации, состоящей из главной ЭВМ и ЭВМ- исполнителей, построенной на базе центральной микро-ЭВМ и микропроцессоров, позволит существенно повысить эффективность управления. Взаимодействие процессов в такой системе должно решаться программно-аппаратными средствами, причем упрощение одних средств, например аппаратных, усложняет программные средства, и наоборот. Лозтому требуются компромиссные решения.
Центральная операционная система и здесь должна оставаться мультипрограммной, однако системные накладные расходы снижаются, так как отдельные функции реализуются другими микропроцессорами. Эти функции могут потребовать оснащения микропроцессора устройствами ввода—вывода, дополнительной памятью и другими атрибутами, образующими микро-ЭВМ с программным обеспечением, не менее сложным, чем в центральной ЭВМ.
Минимальная мультипроцессорная конфигурация^ требующая изучения и актуальная для применения в робототехнике,— два взаимодействующих микропроцессора или соединение достаточно развитой микро-ЭВМ и микропроцессора. Более сложные многомашинные системы могут быть построены по апалогии. Аппаратурное сопряжение машин для целей исследования желательно выполнять без существенных ограничений в отношении взаимной подчиненности и свободы обмениваться данными и программами. В этом случае любую дисциплину подчинения и разделения функций можно реализовать программным путем.
С этой целью был построен двухпроцессорный управляющий комплекс на базе аппаратуры КАМАК, обеспечивающей большую гибкость и легкую перестраиваемость комплекса. В комплекс входит микро-ЭВМ сЭлектроника-60», укомплектованная процессором М2, доттолпительной памятью ПЗ объемом 16К слов, а так;ке интерфейс- пымп платами И7 (для сопряжения с дисплеем (ВТ-2002 или VT-340)) п И4 (для связи с накопителем на гибких магнитных лисках (ГМД)). Плата ИК объединяет ЭВМ с контроллером крейта (КК). В крейт входят стандартные модули КАМАК, которые могут быть необходимы системе, и микропроцессорный модуль на базе БИС КР580ИК80А, занимающий нормальную позицию в крейте (рис. 4).
Микропроцессорный модуль состоит из устройства связи (УС) с магистралью крейта и микропроцессорной системы, содержащей, кроме процессора, блоки оттеративной и постоянной памяти, а также интерфейс ввода—вывода. Обмен данными между ЭВМ и МП-моду- лем происходит через регистры записи ——чтеття. которые соедитте- пьт, с одной стороны, с тштнапн записи и чтопия магистрали, а с
Рис. 4
другой — с двунаправленной шиной данных модуля через устройство связи.
Обмен информацией между ЭВМ и МП-модулем может инициироваться как ЭВМ (путем установки запроса на прерывание модуля), так и самим модулем, который может выставить нужный LAM-запрос на магистраль крейта. Аппаратное сопряжение никак не ограничивает программиста при организации двустороннего обмена данными и программами.
Двухпроцессорный комплекс предназначен в основном для решения двух типовых задач: в одной микропроцессор работает на исполнительном уровне, непосредственно обслуживая приводные системы в контуре управления, а микро-ЭВМ решает тактические и стратегические вопросы； в другой микропроцессор получает от ЭВМ необработанные массивы данных, например, полученные с телекамеры, и возвращает вычисленные характеристики изображения, разгружая центральный процессор от рутинной работы. Очевидно, что обе задачи имеют непосредственное отношение к проектированию систем управления адаптивных роботов с развитой архитектурой.
Программное обеспечение микро-ЭВМ «Электроника-60» решается на базе языка CASTC в операционной системе РАФОС. При этом управление аппаратурой КАМАК ведется с помшцью директив языка без применения ассемблера. Язык CASIC ориентирован на программирование систем реального времени, позволяет описывать параллельные действия в простых и естественных терминах и работать с многими задачами в соответствии с системой приоритетов. Совместное использование языка программирования CASIC и 46
аппаратуры в стандарте КАМАК позволяет добиться гармоничного сочетания программных и аппаратных средств при создании как исследовательских комплексов, так и промышленных установок.
Программирование микропроцессорного модуля представляет собой более сложную задачу. При помощи кросс-средств в операционной системе РАФОС возможно подготовить программы и потом загрузить их в микропроцессор. Из-за сравнительно низкой производительности и малого объема оперативной памяти программы для микропроцессора должны быть как можно более эффективными.
Проводимые исследования при дальнейшем развитии позволят строить и программировать более сложные иерархические структуры систем управления, состоящие из многих процессоров, необходимые для управления робототехническими комплексами и полностью автоматизированными гибкими производствами.
УДК 681.32
ОРГАНИЗАЦИЯ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МНОГОПРОЦЕССОРНЫХ СИСТЕМ УПРАВЛЕНИЯ
И. П. Белякова
Актуальность проблем создания многопроцессорных систем управления растет по мере роста производительности микро-ЭВМ и микропроцессоров. Эффективность систем управления, отдельные функции которых распределены по процессорам, может быть велика по производительности как самих систем, так и разработки программного обеспечения. Наличие простых надежных методов разработки отдельных функциональных составляющих и последующей компоновки систем различного назначения существенно сократит срок внедрения программируемых систем управления.
При разработке систем управления наиболее трудоемко программное обеспечение. От его организации, состава, уровня зависит эффективность систем и дальнейшее их использование. Требования, предъявляемые к программному обеспечению многопроцессорных систем:
модульность структуры, позволяющей выполнять отдельные модули на взаимосвязанных, параллельно работающих процессорах;
возможность независимой разработки отдельных модулей с последующей компоновкой систем различного назначения;
наличие стандартного метода взаимодействия модулей отдельных процессоров;
наличие системных программ, обеспечивающих эксплуатацию системы управления;
максимальное использование стандартных средств для разработки программного и аппаратного обеспечения системы управления.
В соответствии с этими требованиями в ЛИИАН разрабатывает-
47
ся экспериментальная модульная распределенная система управления антропоморфным манипулятором. Аппаратная часть системы представляет собой локальную сеть процессорных модулей (ПМ) на основе микро-ЭВМ «Электроника-60» (рис. 1). Процессоры организованы в иерархическую структуру посредством специальных модулей связи. Управление системой во время ее разработки, отладки н эксплуатации осуществляет подсистема на основе специальной системной микро-ЭВМ с соответствующими периферийными устрой- ствами. Подключенная к системе мини-ЭВМ выполняет функг^и разработки программного обеспечения.
Программное обеспечение системы управления (ПОСУ) состоит из распределенной системы функциональных моделей системы управления (РСУ), распределенной обслуживающей системы (РОС) т поддерживающей эксплуатацию системы, и системы разработки программного обеспечения (СРПО) на основе стандартных операционных систем (рис. 2).
Распределенная система управления представляет собой систему иерархически организованных функциональных модулей, выполняющих единую задачу управления. Состав, функциональное назначение и связи отдельных модулей зависят от применения системы. В основу построения системы управления могут быть положены принципы, развитые для робототехнических комплексов [1, 2]. Модули разрабатываются как самостоятельные компоненты с использованием языков любого уровня. Взаимодействие модулей осуществляется с помощью специальной системы команд распределенной системы обслуживания, в частности ее подсистемы взаимодействия. Взаимодействие функциональных модулей с внешними устройствами также выполняется через распределенную систему обслуживания системой команд, аналогичной системе команд обращения к удаленным модулям процессоров.
Отладка отдельных составляющих может производиться в системе разработки программного обеспечения или на реальной системе управления средствами системы обслуживания. Специальная программа системы разработки программного обеспечения выполняет компоновку всей системы управления из отдельных модулей с составлением соответствующих таблиц связей и дескрипторов. Система загрузки загружает модули из библиотеки системы разработки программного обеспечения в отдельные процессорные модули. Таким образом, функциональное программное обеспечение системы управ- 48
Рис. 3
ления разрабатывается в основном стандартными средствами с использованием языков последовательного типа и обычными методами отладки. Параллельное взаимодействие модулей достигается за счет интерпретирующей системы взаимодействия с фиксированным набором команд. Система взаимодействия составляет самостоятельную распределенную систему, не связанную с языком программирования, и может быть выполнена как мощная диалоговая система межпроцессорного взаимодействия.
Система взаимодействия входит как подсистема в распределенную систему обслуживания, которая является резидентной системой любой системы управления. Модули распределенной системы обслуживания в одинаковом составе содержатся во всех процессор- ных модулях. Эта система обеспечивает эксплуатацию многопроцессорной системы управления:
загрузку и сохранение функционального обеспечения;
отладку системы в реальном времени с доступом к регистрам и ячейкам памяти;
запуск и остановку отдельных функциональных модулей;
диагностику ошибок системы；
взаимодействие с оператором;
взаимодействие между процессами и процессов с внешними устройствами.
Распределенная система обслуживания включает в себя две подсистемы: «Оператор» и «Взаимодействие». Система «Оператор» содержит библиотеку стандартных программ («Загрузчик», «Отладчик», программу ввода—вывода и т. д.) в каждом процессорном модуле, вызываемую к исполнению по командам с пульта оператора системой ЭВМ. В библиотеку могут быть включены и функциональные модули с возможностью вызова их по именам с пульта оператора. Кроме библиотеки, программа «Оператор» имеет программы обслуживания связи с пультом оператора, прием-декодирование команд и вызов к исполнению соответствующих программ, печать сообп^ений об ошибках.
Подсистема «Взаимодействие» также имеет библиотеку программ реализации команд взаимодействия. Эти программы обслуживают вызовы из функциональных программных модулей команд ЧТЕНИЕ, ЗАПИСЬ и ЧТЕНИЕ-ЗАПИСЬ данных из-в процессорные модули и внешние устройства. Система взаимодействия выполняет не только стандартный информационный обмен ме^гду
модулями и внешними устройствами, но и синхронизацию парал^ лельных процессов различных процессоров. Система поддерживает стратегию один процессор—один функциональный процесс. Система правил построения системы функциональных модулей обеспечивает функционирование системы без взаимных блокировок.
Так как система управления антропоморфным манипулятором имеет экспериментальпое исследовательское назначение, ее программное обеспечение подлежит частной модификации. Для систем специального назначения система разработки программного обеспечения может быть временно подключена через сеть вычислительных машин и после разработки программного обеспечения не использоваться с сохранением программ па собственном диске системной ЭВМ. Система разработки программного обеспечения является в основном стандартной операционной системой (рис. 3) и содержит, кроме обычных системных программ, позволяющих разрабатывать модульные системы, системную программу компоновки системы многопроцессорного управления. В процессе ее работы заполняются таблицы и адреса межпроцессорных связей.
Подпрограммы, обеспечивающие обращение к системе взаимодействия и подготовку структур данных, оформляются как стандартные библиотечные подпрограммы, компонуемые совместно с другими модулями функционального обеспечения. Компилятор языка высокого уровня требует незначительной модификации для включения команд системы взаимодействия.
При необходимости отладки системы в однопроцессорном варианте система разработки программного обеспечения должна иметь систему моделирования многопроцессора и внешних устройств с генерируемым составом процессоров, их связей и связей с внешними устройствами.
Для функционирования системы разработки программного обеспечения необходима связь с распределенной системой обслуживания и работа под управлением одного оператора. Кроме того, она должна быть программно совместима с базовой ЭВМ системы управления.
Рассмотренная организация программного обеспечения сетевых управляющих систем показывает структуру системы, занимающей промежуточное положение между слабо связанными сетевыми системами вычислительных машин [3] и тесно связанными структурами многопроцессоров, предназначенных как для разработки, так и для выполнения вычислительных задач [4]. Предложенный подход к структуре программного обеспечения систем управления позволяет разрабатывать их на основе стандартных микропроцессоров и микро-ЭВМ и стандартных операционных систем. Такие системы управления можно легко перестраивать, компоновать из готового программного обеспечения.
ЛИТЕРАТУРА
Никифоров В. В., Смирнов Я. А., Чиганов В. А. Унификация архитектуры и алгоритмической структуры средств управления промышленными роботами.— В кн.： Алгоритмические модели в автоматизации исследований. М.: Наука, 1980, с. 186—193.
Управление роботами от ЭВМ/Под ред. Е. И. Юревича. Л.: Энергия, 1980.
264 с.】 т
Wood D. A survey of the capabilities of 8 packet switching networks.— In: Proc. Symp. Comp. Networks: Trend and Appl. Gaithersburg, 1975, New York, 1975, p. 1—7.
Фуллер С. X” Устерхут Дж. К. Мультимикропроцессорные системы; Обзор и примеры практической реализации.一 ТИИЭР, 1978, т. 66, № 2, с. 135—150.
С РЕАЛИЗАЦИЯ
/ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ
УДК 621.865.8.004.14:621.757'
ПРОГРАММНЫЕ СРЕДСТВА ДЛЯ ПЛАНИРОВАНИЯ ПРОЦЕССА АВТОМАТИЧЕСКОЙ СБОРКИ
Д. Е. ОхоцимскиИ, А. К. Платонов, С. С. Камынин,
С. И. Гримайло, А. Ю. Каргашин, А. А. Кприльченко, Е. И. Кугушев
Одним из важных направлений автоматизации процесса производства в промышленности, прежде всего в отраслях машиностроения, является автоматизация сборочных операций. В решении этой проблемы большая роль выпадает на долю промышленных роботов, использование которых в комплексе с другим технологическим оборудованием позволяет резко сократить затраты ручного труда, часто тяжелого, монотонного и утомительного.
Включение вычислительно-управляющих средств, таких, как мини- или микро-ЭВМ, в контур управления движением сборочных комплексов сообщает им принципиально новые свойства. Становится возможным выполнять па одном сборочном комплексе большой цикл разнородных сборочных операций, производить сборку целых узлов изделий машиностроения.
Развитые программные средства открывают возможность быстрой переналадки сборочного комплекса на другое изделие, что обеспечивает высокую степень гибкости в использовании оборудования при изменении параметров или типа изготовляемой продукции. Свойственная электронным вычпслительно-управляющим системам способность выполнения логических операций и ветвления процесса управления дает возможность удобно и гибко сочетать технологические и контрольные операции, варьировать их в зависимости от складывающейся ситуации. Это позволяет повысить надежность сборочного процесса, обеспечить успешное протекание сборки при наличии некоторых неточностей позиционирования деталей, оптибок или помех, а также рациональную и безаварийную реакцию системы управления в ситуациях, когда продолжение сборки затруднено пни становится почему-либо невозможным.
В статье рассматриваются программные средства разработанной в Институте приклэдноп математики нм. М. В. Келдыша АН СССР автоматической сборочной системы, предназначенные для планиро-, вания процесса автоматической сборки [1—4].
Для задания и исполнения процесса сборки автоматическая сборочная система содержит ряд программных модулей. Часть из 52
них. предназначена для ввода в память управляющей ЭВМ данных, описывающих процесс сборки, пли для их редактирования. Другие модули обеспечивают управление движением манипуляторов н контроль показаний датчиков. Общение оператора-программиста с каждым из этих модулей происходит в интерактивном режиме при помощи операторского терминала (алфавитпо-цифрового дисплея). При этом система сама предлагает возможные альтернативные действия и запрашивает от оператора необходимую информацию. Такая организация планирования сборки является простой и общедоступной.
При отладочных прогонах сборочного процесса часто возникает необходимость внести исправления в те или иные данные, описы- вакУщие сборку. Если при этом использовать только один диалоговый режим работы с системой, то могут возникнуть затруднения в восстановлении смисла этих данных. Для более наглядного представления процесса сборки в Институте прикладной математики им. М. В. Келдыша АН СССР разрабатывался язык высокого уровня, позволяющий описать процесс сборки, заданный в диалоговом режи~ ме работы с системой, в текстовой форме. Ясно, что возможность представления процесса сборки па языке высокого уровня в свою очередь требует наличия возможности осуществлять планирование на этом языке, что может понадобиться, например, когда использование диалогового режима по каким-либо причинам оказывается затруднительным или вообще невозможным.
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
АВТОМАТИЗИРОВАННОЙ СБОРОЧНОЙ СИСТЕМЫ
Процесс сборки представляет собой последовательность специализированных движений манипуляторов сборочного робота — движений захвата, транспортных, поисковых, тестирующих и др. Система управления параллельно с исполнением каждого движения анализирует текущую ситуацию и при выполнении заданных условий организует окончание данного движения и переход к некоторому следующему [1].
Для того чтобы сборочный комплекс мог выполнить сборку в автоматическом режиме, предварительно планируется и отрабатывается процесс сборки и вводится соответствующая информация в управляющую ЭВМ [3].
Программные средства автоматизированной сборочной системы включают модули:
задания и редактирования плана сборки;
задания и редактирования планов сборочных операций;
задания и редактирования движений;
задания и редактирования планов >тсловип;
задания и редактирования коэффициентов следящей системы；
управления автоматической сборкой.
Модули 1—5 необходимы для планирования и отработки сборочного процесса. Планирование целесообразно организовать иерархи-
чески. Весь процесс разбивается па сборочные операции, каждая из которых состоит из последовательности движений. Движения могут задаваться в виде последовательности позиций манипулятора, вводимых в память ЭВМ. Установку в позицию можно осуществлять как вручную, так и с выносного пульта. Может быть задан позиционный или контурный способ движения. В последнем случае использовался прием формирования бегущей программной точки, получаемой путем интерполяции между выбранными опорными точками при заданном времени перемещения между ними. Задание параметров движения, их корректирование в процессе отладки выполняются в диалоговом режиме с пульта алфавитно-цифрового дисплея. При корректировании можно изменять значения параметров и осуществлять некоторые другие действия, в частности, добавление или изъятие промежуточных опорных точек. Каждое движение может отрабатываться независимо. Их объединение в сборочную операцию проводится в диалоговом режиме. Переход от движения к движению происходит на основе результатов выполнения планов контроля условий, приписанных движениям. В планах контроля условий может проверяться, например, факт достижения позиции с заданной точностью, истечение заданного интервала времени, наступление события, тот или иной результат тестирующего движения и др. По структуре сборочная операция представляет собой ориентированный граф, вершины которого отвечают движениям и соответствующим планам контроля условий, а ребра — переходам от движения к двин^ению. Отработанная сборочная операция заносится в память ЭВМ и используется по вызову. При формировании сборочной операции полезно использовать аппарат формальных параметров. В этом случае сборочная операция играет роль подпрограммы, параметры которой задаются перед исполнением. Такой прием удобен в случае, когда в процессе сборки встречаются однотипные операции, имеющие одинаковую структуру и состав, как, например, при скреплении деталей с помощью нескольких болтов и гаек.
Формирование сборочного процесса из сборочных операций реализуется в диалоговом режиме с использованием модуля 1. Сборочный процесс, как и отдельная операция, представляет по своей структуре ориептировапгЕый граф, вершины которого отвечают вызовам сборочных операций, а ребра — переходам от одной операции к другой.
Модуль 4 предназначен для формирования и редактирования планов проверки условий. При анализе состояния может происходить его оценка по совокупности ряда критериев. Структура процесса проверки ряда условий имеет вид ориентированного графа. Результат проверки предыдущего условия определяет выбор последующего. Планы проверки условий формируются автономно и играют роль подпрограмм, используемых как в составе операции, так и при объединении операций в сборочный процесс. Формирование и редактирование планов контроля условий выполняются также в диалоговом режиме. В дальнейшем планы контроля условий бу- 54
И
「 дем называть составными условиями или просто условиями, а условия, указанные в этих планах,— элементарными условиями.
Модуль 5 предназначен для задания и корректирования набора коэффициентов обратной связи цифровых следящих систем приводов манипуляторов. Наборы коэффициентов хранятся в специальных массивах и используются по мере необходимости. В процессе сборки может быть полезным изменение значений коэффициентов, например их увеличение для повышения точности позиционирования или их уменьшение для увеличения податливости* манипулятора.
Модуль 6 управляет движением сборочного комплекса в автоматическом режиме. Исполнение движения может быть задано для всего сборочного процесса целиком либо для отдельных его операций, движений или их элементов, что очень удобно при формировании сборочного процесса и его отладке.
В качестве основного объекта, применительно к которому разрабатывались программные комплексы, обеспечивающие формирование рабочих программ, был взят шестереночный масляный насос, состоящий из 17 деталей. Сборка насоса происходила в следующей последовательности. В нижнюю половину корпуса насоса вставлялись одна за другой две шестерни, накладывалась прокладка и надевалась верхняя часть корпуса. После этого осуществлялись кантовка и вставление четырех крепежных болтов со стороны нижней половины корпуса. Затем накладывалась фиксирующая крышка, препятствующая падению болтов при обратной кантовке, необходимой для навинчивания гаек с шайбами. После навинчивания гаек выполнялись третья кантовка и снятие фиксирующей крышки. На этом процесс сборки заканчивался.
Б дальнейшем разработанное программное обеспечение применялось при автоматической сборке картера двигателя внутреннего сгорания.
ЯЗЫК ОПИСАНИЯ СБОРОЧНОГО ПРОЦЕССА
Планы сборки, планы сборочных операций, планы контроля условий и другие объекты задаются в текстовом виде. Описание автоматической сборки разбито на несколько файлов: план сборки, планы сборочных операций, описание движений, описание типов движений [1], планы составных условий, описание элементарных условий.
Прежде чем описывать структуру языка, отметим несколько принятых в нем соглашений. Все операторы языка начинаются с Одного из следующих ключевых слов: ВЕР ——вершина плана; ПЕР — переход к другой вершине плана; ПАР — параметр;
1 ВЫП — выполнить; ВЫХ — выход. В пределах одной строки текста считается комментарием текст от символа 《；» до следующего символа 《；» или до конца строки. Объектами языка являются сборочные операции, составные и элементарные условия, их параметры, вершины планов, контуры движений, типы и способы движения [1] и т. д. Все объекты языка имеют текстовые имена,
которые задает программист. В отличие от ключевых слов имена объектов языка заключаются в круглые скобки. Обращение к объектам осуществляется по их именам. Каждый объект может иметь одно или несколько альтернативных имен, например полное имя и сокращенное. Обращаться к объекту можно по любому из алвтер， нативных имен.
^писание плана сборки. План автоматической сборки представляет собой ориентированный граф, в вершинах которого описаны вызовы сборочных операций и их параметры. Ребра графа соответствуют переходам от вершины к вершине (т. е. от операции к операции). Ребро, по которому осуществляется текущий переход, определяется по коду ответа, вырабатываемого при исполнении операции.
"В качестве примера приведем описание двух первых вершин плана сборки масляного насоса:
；СБОРКА МАСЛЯНОГО НАСОСА
ВЕР (НАЧАЛО)、
ВЫП (ЗАЖАТИЕ КРЫШКИ)
ПАР (КОНТУР) - (ЗАЖАТИЕ КРЫШКИ ЛР)
ПЕР НА (ВСТАВИТЬ БШ)
ВЕР (ВСТАВИТЬ БШ)
ВЫП (ВСТАВЛЕНИЕ ШЕСТЕРНИ)'
ПАР (КОН. ПОДВОД ПР К ш)= (ПОДВОД ПР К БШ)
ПАР (КОН. ПОДВОД Ш К ОТВ) = (ПОДВОД БШ К ОТВ)
ПАР (КОН. ПОИСК ПРИ ВСТАВЛЕНИИ 叫=(ВСТАВИТЬ БШ)
ПАР (КОН. ПОВТОРИ. ПОДВОД Ш К ОТВ) = (ПОДВОД БШ к отв ОТ ТОЧКИ 4)
ПАР (КОН. ОТВОД ПР ОТ Ш) = (ОТВОД ПР)
ПАР (ВЫДЕРЖКА ДЛЯ ПОДВОДА ПР К 1П)-1
ПАР (ВЫДЕРЖКА ДЛЯ ПОДВОДА Ш К ОТВ)=15
ПАР (FI20)=600
ПАР (FI30)=250
ПАР(ALF2)=88
ПАР (ALF3)—100
ПАР (ALF0)=1912
ПАР (ВЫДЕРЖКА ДЛЯ ОТВОДА ПР ОТ Ш) = 1
ПЕР НА (ВСТАВИТЬ МШ)
Поясним использованные сокращения: ПР — правая рука (один из манипуляторов); ЛР — левая рука (другой манипулятор) ; БШ — большая шестерня; МШ — малая шестерня; Ш — шестерня; ОТВ — отверстие; КОН ~ контур движения.
Первая вершина плана сборки называется НАЧАЛО. В ней вызывается операция ЗАЖАТИЕ КРЫШКИ. У этой операции один формальный параметр, который называется КОНТУР. Этому параметру приписывается фактическое значение — контур движения, который называется ЗАЖАТИЕ КРЫШКИ ЛР. После выполнения
I операции переход всегда осуществляется на вершину ВСТАВИТЬ г Вторая вершина плана сборки называется ВСТАВИТЬ БШ. I В ней выполняется операция вставления шестерни в отверстие I (имя операции — ВСТАВЛЕНИЕ ШЕСТЕРНИ). У этой операции j несколько формальных параметров — КОН. ПОДВОД ПР К Ш, I КОН. ПОДВОД Ш К ОТВ и т. д. Всем им приписываются факти- I ческие значения либо по именам объектов, либо числовые. После I выполнения операции переход всегда осуществляется на вершину с 『именем ВСТАВИТЬ МШ.
I Описание сборочных операций. Последовательность исполнения [；:движения робота при исполнении операции ^описывается в ее плане. План операции представляет собой ориентированный граф, каждой вершине которого соответствует исполнение Одного движения робота. Все движения исполняются параллельно с проверкой приписанных им составных условий. Окончание этой проверки вызывает завершение исполнения текущего движения. Код ответа, который вырабатывается в результате проверки условия, указывает, по какому ребру в плане операции произойдет переход от текущей вершины к следующей, и тем самым обусловливает запуск следующего движения.
Аналогично обычным программным процедурам каждая операция может иметь входные параметры, которые опеределяют характер ее исполнения. В заголовке описания плана операции указывается ее имя, затем идет описание параметров операции. В качестве параметров могут передаваться контуры движений, используемых в операции, и параметры ее составных условий.
В каждой вершине плана операции описывается контур движения, которое запускается при попадании в данную вершину, составное условие и его параметры. Этим объектам могут присваиваться постоянные значения или значения входных параметров операции. Помимо этого, в каждой вершине описывается способ движения — позиционный или контурный, тип движения — режим отслеживания по каждой степени подвижности робота [4] и тип начала — тип начала контура движения по каждой используемой в данном движении степени подвижности [1]. Считается, “то ио умолчанию способ движения — КОНТУРНЫЙ, тип движения — НЕ МЕНЯТЬ по всем степеням подвижности (т. е. такой же, какой был при исполнении предыдущего движения), тип начала — АБСОЛЮТНЫЙ по всем степеням подвижности, используемым в контуре движения (т. е. начальная точка движения такая, какая записана в таблицах, хра- няших контур движения).
В некоторых специальным образом описанных вершинах исполнение операции закапчивается и вырабатывается числовой код ответа операции (0, 1, 2,...), который описан в этой вершине. Все такие выходы могут быть поименованы.
Перечислим некоторые ключевые слова языка, которые употребляются для описания плана операции: ОПЕРАЦИЯ — заголовок операции; КОНДВ — контур движения; УСЛДВ — условие дви-
женин; ТИПДВ — тин движения; ТИПНАЧ — тип начала; СПДВ — способ движения.
Приведем пример операции вставления шестерни масляного насоса в отверстие его основания (в описании операции использова-. ны те же сокращения, ито и в плане сборки);
ОПЕРАЦИЯ (ВСТАВЛЕНИЕ ШЕСТЕРНИ)
ПАР (ПОДВОД ПР К Ш)
ПАР (КОН. ПОДВОД Ш К ОТВ)'
ПАР (КОН. ПОВТОРНЫЙ ПОДВОД Ш К ОТВ)
ПАР (КОН. ПОИСК ПРИ ВСТАВЛЕНИИ Ш)
ПАР (КОН. ОТВОД ПР ОТ Ш)
ПАР (ВЫДЕРЖКА ПО ВРЕМЕНИ ДЛЯ ПОДВОДА ПР К Ш)
ПАР (ВЫДЕРЖКА ДЛЯ ПОДВОДА Ш К ОТВ)
ПАР (FI20); ПАРАМЕТРЫ ДЛЯ
ПАР (FI30); ПРОВЕРКИ
ПАР (ALF2); ПОПАДАНИЯ Ш
ПАР (ALF3); В ОТВ
ПАР (ALF0);
ПАР (ВЫДЕРЖКА ДЛЯ ОТВОДА ПР ОТ Ш)
ВЕРШИНА 1
ВЕР (ПОДВОД ПР К Ш)
КОНДВ (КОН. ПОДВОД ПР К Ш)
УСЛДВ (КОНЕЦ ПР И ОЖИД)
ПАР (ВРЕМЯ ОЖИД)-(ВЫДЕРЖКА ДЛЯ ПОДВОДА ПР К Ш)
ПЕР НА (СХВАТИТЬ Ш)
ВЕРШИНА 2
ВЕР (СХВАТИТЬ Ш)
КОНДВ (СЖАТЬ СХВАТ ПР)
УСЛДВ (КОНЕЦ ПР И ОЖИД)
ПАР (ВРЕМЯ ОЖИД) =11
ПЕР НА (ПОДВОД П1 К ОТВ)
-ВЕРШИНА 3
ВЕР (ПОДВОД Ш К ОТВ)
КОНДВ (КОН. ПОДВОД Ш К ОТВ)
УСЛДВ (КОНЕЦ ПР И ОЖИД)
ПАР (ВРЕМЯ ОЖИД) - (ВЫДЕРЖКА ДЛЯ ПОДВОДА Ш К ОТВ)
ПЕР НА (ВСТАВЛЕНИЕ Ш)
ВЕРШИНА 4
ВЕР (ВСТАВЛЕНИЕ Ш)
КОНДВ (КОН. ПОИСК ПРИ ВСТАВЛЕНИИ Ш)
ТИПДВ (СИЛОВОЙ) ДЛЯ (3UP) (ПОИСК) ДЛЯ (4ПР), (5ПР)
ТИПНАЧ (НЕПРЕРЫВНЫЙ) ДЛЯ ВСЕХ СТЕПЕНЕЙ (АБСОЛЮТНЫЙ) ДЛЯ ЗПР
УСЛДВ (ТЕСТ ЛИНЕЙНОЙ КОМБИНАЦИИ СТЕПЕНЕЙ 2, ЗПР)
ПАР (ВРЕМЯ ТЕСТА) = 1000
ПАР (FI20) = (FI20)
ПАР (FI3O) = (FI3O)
ПАР (ALF2) - (ALF2)
ПАР (ALF3) = (ALF3)
ПАР (ALF0) = (ALF0)
ПЕР ЕСЛИ (ОСЬ ВСТАВЛЕНА) НА (РАЗЖАТЬ ПР)
ЕСЛИ (ОСЬ НЕ ВСТАВЛЕНА) НА (ПОВТОР ПОДВОД К ОТВ)
;ВЕРШИНА 5
ВЕР (ПОВТОР ПОДВОД К ОТВ)
СПДВ (ПОЗИЦИОННЫЙ)
КОНТДВ (КОН. ПОВТОРНЫЙ подвод Ш К ОТВ)
УСЛДВ (ОЖИДАНИЕ ПОПАДАНИЯ ПР В ОКРЕСТНОСТЬ)
、 ПАР (РАДИУС ОКРЕСТНОСТИ) =2
ПЕР НА (ВСТАВЛЕНИЕ Ш)
;ВЕРШИНА6
ВЕРШИНА (РАЗЖАТЬ ПР)*
КОНДВ (РАЗЖАТЬ СХВАТ ПР)
УСЛДВ (КОНЕЦ ДВ И ОЖИД)
ПАР (ВРЕМЯ ОЖИД ) = 1
ПЕР НА (ОТВОД ПР)
;ВЕРШИНА7
ВЕР (ОТВОД ПР)
ТИПНАЧ (НЕПРЕРЫВНЫЙ)ДЛЯ ВСЕХ СТЕПЕНЕЙ
КОНДВ (КОН. ОТВОД ПР ОТ Ш)
ПЕР НА (КОНЕЦ)
;ВЕРШИНА8
' ВЕР (КОНЕЦ) ВЫХ
，…КОНЕЦ
Поясним для примера описание первой вершины плана операции. Она называется ПОДВОД ПР К Ш. В ней запускается движение с контуром КОН. ПОДВОД ПР К Ш, который является параметром операции. Условие, которое проверяется одновременно с исполнением движения, называется КОНЕЦ ПР И ОЖИД. У него один параметр — ВРЕМЯ ОЖИД, которому присваивается значение формального параметра операции. ВЫДЕРЖКА ДЛЯ ПОДВОДА ПР К Ш. Переход от этой вершины всегда происходит на вершину СХВАТИТЬ Ш.
Файл описания типов. В этом файле описываются те имена, которые программист присваивает степеням подвижности робота, имена режимов, в которых может отслеживаться движение этих степеней подвижности, и т. п.
На нижнем уровне автоматической сборочной системы всем степеням подвижности робота присвоены постоянные номера от 1 до 16 [4]. Обращаться к степеням подвижности можно по этим номе-
рам или но именам, которые присваивает программист. Операторы присвоения выглядят следующим образом:
;ИМЕНА СТЕПЕНЕЙ ПОДВИЖНОСТИ
СТЕПЕНЬ 1 一 (ШР) ИЛИ (ПЛАТФОРМА ПР)
СТЕПЕНЬ 2 -(7UP) ИЛИ (СХВАТ ПР)
СТЕПЕНЬ 16 — (7ЛР) ИЛИ (СХВАТ ЛР)
СТЕПЕНЬ 9 一(ИНСТРУМЕНТ)
Здесь степень свободы 1 получила два имеип: 1ПР и ПЛАТФОРМА ПР (ПР — правая рука; ЛР — левая рука), степень 9 — имя ИНСТРУМЕНТ (электрический инструмент робота, например электрическая отвертка [1]).
Исполнение движения по каждой степени подвижности робота может осуществляться в одном из нескольких режимов отслеживания. Все режимы отслеживания имеют номера от 0 до 10. Так же, как и для номеров степеней подвижности, режимам движения мо- гут быть присвоены имена, удобные для работы. Операторы присвоения выглядят следующим образом:
;ГЕ7КИМЫ ОТСЛЕЖИВАНИЯ
РЕЖИМ 1 - (ОСНОВНОЙ)”
РЕЖИМ 2- (ЛИНЕЙНЫЙ ПОИСК) ИЛИ (ПОИСК)
РЕДКИМ 4一 (СИЛОВОЙ)
РЕЖИМ 0 — (НЕ МЕНЯТЬ)
РЕЖИМ 10- (ОТКЛЮЧЕН) ИЛИ (ДВИГ, ОТКЛЮЧЕН)
Здесь режим двюкения 1 получает имя ОСНОВНОЙ, режим 2 - два имени - ЛИНЕЙНЫЙ ПОИСК и ПОИСК и т. д.
При запуске исполнения нового движения программная траектория для каждой степени подвижности может начинаться одним из четырех способов (типов начал). Типы начала имеют номера от 0 до 3. Операторы присвоения имен выглядят следующим образом:
；ТИПЫ НАЧАЛ
ТИП 0 - (НЕПРЕРЫВНЫЙ) ИЛИ (ИЗ IFR) ТИП 1 一 (АБСОЛЮТНЫЙ) ИЛИ (ИЗ IQ) ТИП 2 — (ОТНОСИТЕЛЬНЫЙ) ИЛИ (ИЗ IP) ТИП 3 一 (УСЛОВНЫЙ) ПЛИ (ИЗ IFRCP)
Движение манипулятора определяется последовательностью программных точек, через которые он должен пройти. Эта последовательность называется контуром движения. Смысл информации, записанной в точках контура движения, зависит от toed, в каком режиме зтот контур будет исполняться [4]. Например, для степеней подвижности, отслеживаемых в основном режиме, в контуре хранится иоследовательность показана立 датчиков положения для ； программного движения каждой степени подвижности. Для режима . силового воздействия хранятся параметры, описывающие форму и период отслеживаемого усилия и т. п. В зависимости от типа ин- | формации для хранения точки контура движения используется раз- ； 60
ное количество ячеек, меняется также и формат хранения информации в этих ячейках.
Каждому типу представления точки контура присваивается имя, которое используется в файле описания контуров. Всего возможных типов представления три — одна ячейка на точку, две ячейки на точку и четыре байта на точку.
Операторы описания имен выглядят следующим образом:
;①ОРМАТ КОНТУРА
ФОРМАТ 1 — (ПОЗИЦИЯ) ИЛИ (1103) ИЛИ (КОЛЕБАНИЯ)
ФОРМАТ 2 - (МЯГКИЕ КОЛЕБАНИЯ)
ФОРМАТ 3 - (СИЛОВОЕ ВОЗДЕЙСТВИЕ) ИЛИ (СИЛА)
Каждый контур движения может быть исполнен двумя различными способами. В первом способе переход от отележивания очередной точки, указанной в контуре движения, к следующей осуществляется после выполнения плана контроля условия, приписанного зтому движению, если этот контроль выработал код ответа 0. В противном случае, либо если очередная точки — последняя в контуре, исполнение движения прерывается. Во втором способе движения отслеживается «бегущая» программная точка, формируем мая в результате линейной интерполяции между каждыми двумя соседними точками, указанными в контуре. Исполнение движения прерывается сразу же после выполнения плана условия. Способам движения присваивается имя с помощью следующих операторов:
;СПОСОБ ДВИЖЕНИЯ
СПОСОБ ОППОЗИЦИОННЫЙ СПОСОБ 1 - КОНТУРНЫЙ
Описание контуров движения. В автоматической сборочной системе предусмотрена возможность хранения двухсот контуров движения. Каждый контур характеризуется своим номером и типом. Тип контура указывает, какие степени подвижности используются в данном движении и каков формат информации для хранения точек контура.
В файле описания контуров движения хранятся имена, которые программист присваивает контурам движения, а также описания типов этих контуров. Приведем в качестве примера отрезок этого файла:
КОНТУР 199 (РАЗЖАТЬ СХВАТ ПР) ТИП (ПОЗИЦИЯ) ДЛЯ (СХВАТ ПР) КОНТУР 194 (ОТВОД ПР) ИЛИ (ПОДЪЕМ ПР) ТИП (ПОЗИЦИЯ) ДЛЯ (ШР), (2ПР), (ЗПР), (4ПР), (5ПР), 6ПР КОНТУР 42 (ТЕСТОВОЕ ДВИЖЕНИЕ) 1'ИП (ПОЗИЦИЯ) ДЛЯ (ЗПР), (СХВАТ ПР)
(СИЛА) ДЛЯ (4ПР)
В этом отрезке описано три контура движения с номерами 199, 194, 42. Контур 199 получил имя РАЗЖАТЬ СХВАТ ПР, контур
194 получил два имени — ОТВОД ПР и ПОДЪЕМ ПР. В контуре 199 задействована одна степень подвижности — СХВАТ ПР, используется формат хранения ПОЗИЦИЯ. В контуре 42 задейство^ вано три степени подвижности и используются два формата хранения информации — ПОЗИЦИЯ и СИЛА.
Описание элементарных условий. В ходе исполнения автоматической сборки для перехода от движения к движению необходимо контролировать наступление некоторых событий, например, истечение заданного интервала времени, попадание показаний указанных датчиков робота в заданную окрестность и т. п. Контроль за этими событиями осуществляется при помощи специальных программных модулей, входящих в состав модуля исполнения автоматической сборки. Эти модули называются элементарными условиями. Каждое элементарное условие имеет входные параметры, например, номер датчика, радиус окрестности, длину интервала времени и т. п. При обращении к элементарному условию выполняется однократная проверка события, которое оно контролирует, и формируется выходной параметр — код ответа, указывающий, в каком состоянии находится событие. Код ответа может принимать только целые значения (0, 1, 2,...). Каждому элементарному условию в автоматической сборочной системе присваивается номер. '
В файле описания элементарных условий описываются имена, которыми программист обозначает элементарные условия, их параметры и коды ответа. В качестве примера рассмотрим описание двух элементарных условий:
ЭЛЕМЕНТАРНОЕ УСЛОВИЕ 7 (ВЗВОД СЧЕТЧИКА ВРЕМЕНИ) ИЛИ ' (ВЗВОД Т)
ПАР (ЗАДЕРЖКА) ИЛИ (ИНТЕРВАЛ)
ВЫХОД О ВСЕГДА
ЭЛЕМЕНТАРНОЕ УСЛОВИЕ 9 (ОПРОС СЧЕТЧИКА ВРЕМЕНИ)
ИЛИ (ОПРОС Т)
ВЫХОД О (ВРЕМЯ ИСТЕКЛО) ИЛИ (КОНЕЦ ИНТЕРВАЛА)
ИЛИ (КОНЕЦ ЗАДЕРЖКИ)
ВЫХОД 1 (ВРЕМЯ НЕ ИСТЕКЛО)
Элементарное условие 7 получает два альтернативных имени — ВЗВОД СЧЕТЧИКА ВРЕМЕНИ и ВЗВОД Т. Оно имеет один параметр —ЗАДЕРЖКА (длина интервала времени). При выходе из него коду ответа всегда присваивается ноль.
Элементарное условие 8 — ОПРОС Т — параметров не имеет, но у пего два возможных выхода. Выход с кодом ноль получает несколько имен: ВРЕМЯ ИСТЕКЛО, КОНЕЦ ИНТЕРВАЛА, КОНЕЦ ЗАДЕРЖКИ. Выход с кодом ответа один получает одно имя — ВРЕМЯ НЕ ИСТЕКЛО.
Описание составных условий. В процессе исполнения автоматической сборки переход от одного движения сборочного робота к другому происходит после окончания проверки составных условий, которые планирует программист. План такой проверки (план конт-
роля условия) представляет собой ориентированный граф, в вершинах которого указываются элементарные условия, а каждому коду ответа элементарного условия соответствует ребро перехода от текущей вершины к следующей. В некоторых специальным образом описанных вершинах (конечных, или выходных) проверка составного условия заканчивается и вырабатывается код ответа составного условия —целое число (0, 1, 2,…),которое указано в этой вершине. У составного условия могут быть входные параметры, необходимые для настройки указанных в нем элементарных условий.
В файле описания составных условий указываются имена, которые программист присваивает условиям, их параметрам и выходам (кодам ответа), и программируются планы проверки составных условий.
Приведем пример плана контроля составного условия с именем ОЖИДАНИЕ ВРЕМЕНИ:
' УСЛОВИЕ (ОЖИДАНИЕ ВРЕМЕНИ) ИЛИ (ОЖ Т)
ПАР (ВРЕМЯ ОЖИДАНИЯ)
ВЕР (ЗАПУСК* ТАЙМЕРА)
ВЫП (ВЗВОД Т)
ПАР (ИНТЕРВАЛ) = (ВРЕМЯ ОЖИДАНИЯ)
ПЕР НА (ТЕСТ Т)
'ВЕР (ТЕСТ Т) ВЫП (ОПРОС Т) ПЕР ДЛЯ (ВРЕМЯ НЕ ИСТЕКЛО) НА (ТЕСТ Т) gДЛЯ (ВРЕМЯ ИСТЕКЛО) НА (КОНЕЦ)
I ,7 ВЕР (КОНЕЦ)
Fвых
План контроля условия содержит три вершины, имеющие имена ЗАПУСК ТАЙМЕРА, ТЕСТ Т и КОНЕЦ. У условия один входной параметр (ВРЕМЯ ОЖИДАНИЯ) и одна выходная вершина (КОНЕЦ). Поскольку выход один, то ему не присваивается имя. В вершине ЗАПУСК ТАЙМЕРА выполняется элементарное условие ВЗВОД Т с параметром, равным входному параметру условия. После этого происходит переход на вершину ТЕСТ Т, в которой выполняется проверка элементарного условия ОПРОС Т без параметров. У этого элементарного условия два возможных кода ответа. По коду ответа, названному ВРЕМЯ НЕ ИСТЕКЛО, происходит переход на вершину ТЕСТ Т? по коду ответа ВРЕМЯ ИСТЕКЛО — га вершину КОНЕЦ.
ЛИТЕРАТУРА
Охоцимский Д. Е., Платонов А. К., Смольянов Ю. П., Гримайло С. И., Камынин С. С., Кугушев Е. И. Исследование многооперационной сборки с помощью экспериментальной робототехнической системы — В кн,: Роботиза- * «ия сборочных процессов, М.: Наука, 1985, с. 61—87,
Смольянов Ю. 77., Вахлии В. В., Волков Л. А, Гримайло С. И., Донцов В. Е., Кугушев Е. 〃.， Соколов С. М. Лабораторный макет сборочного робота.-^ В кн.: Роботизация сборочных процессов. М.: Наука, 1985, с. 88—102.
Гримайло С. И. Программное обеспечение сборочного робота ——В кн.: Роботизация сборочных процессов. М.: Наука, 1985, с. 103—122.
Гримайло С. И., Кугушев Е. И., Ярошевский В. С. Цифровая следящая система для управления манипуляторами в процессе сборки: Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 98. М., 1982. 28 с.
УДК 621.8
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
УСТРОЙСТВА КОНТУРНОГО УПРАВЛЕНИЯ УКМ-772
ДЛЯ ПРОМЫШЛЕННЫХ РОБОТОВ
А. Н. ДомарацкиН, В. В. Никифоров
Одной из важнейших сфер применения промышленных роботов в современном производстве является автоматическая дуговая электросварка. Промышленностью освоен серийный выпуск элементов робототехнических кодшлексов для дуговой электросварки: ма- нииуляционпые роботы, поворотные столы для установки свариваемых изделий (манипуляторы изделия), сварочное технологическое оборудование с числовым управлением, устройства программного управления на микропроцессорах. При использовании микропроцессоров функциональные возможности в существенной мере определяются особенностями функционального программного обеспечения устройства числового программного уиравления. Апиаратные средства устройств числового программного управления определяют более или менее широкие рамки функциональных возможностей, реализуемых в конечном счете средствами функционального программного обеспече1гия.
В настоящей статье освещается опыт построения функционального программного обеспечения устройства коптурпого управления УКМ-772 промытпленным роботом для дуговой электросварки.
Устройство УКМ-772 построено на базе исиользования микро- ЭВМ «Электроника-60» (рис. 1). Интерфейсные блоки, обесиечива- юпше взаимодействие процессора «Электроника-60» с внешними устройствами, подключаются к общей шине «Электропики-60» либо неиосредствепно, либо через адаптер, согласующий общую шину «Электроники-60^ с общей шиной специального вида.
Устройство контурного управления роботом для дуговой электросварки должно обеспечивать сравнительно высокую точность движения рабочего органа по расчетной траектории (менее 1 мм), точность выдерживания требуемой ориентации (±5°) и контурной скорости (±5%). Эти факт°Ры существенно влияют на определение требований к алгоритмам, реализующим функции уиравления (в том числе к алгоритму регулирования).
Существенным фактором, влияющим на требования к производительности процессора устройства числового программного управ*
夕夕Рис. 1. Общая структурная схема логического устройства У КМ-7 72Рис. 1. Общая структурная схема логического устройства У КМ-7 721 — процессор «Электроника-60»; 2 — оперативное запоминающее устройство; 3 — адаптер, согласующий общую шину А с общей шиной В; 4 — постоянное запоминающее устройство; 5 — фотосчитыватель; 6 — плата В1 интерфейса с пультом оператора и фотосчитывателем; 7 — пульт оператора; 8 — плата специального интерфейса с пультом оператора； 9 ——пульт обучения; 10 — интерфейс с пультом обучения： 11 ~ таймер； 22 — цифроаналоговые преобразователи управления приводом робота; 23—ввод показаний кодовых датчиков робота; 14, 15 — соответственно ввод и вывод технологическик сигналов； 16 — контроллер накопителя на кассетной магнитной ленте; 77 — накопитель на кассетной магнитной ленте; 18 — плата 321 интерфейса с перфоратором; 79 — перфоратор ПЛ-1501 — процессор «Электроника-60»; 2 — оперативное запоминающее устройство; 3 — адаптер, согласующий общую шину А с общей шиной В; 4 — постоянное запоминающее устройство; 5 — фотосчитыватель; 6 — плата В1 интерфейса с пультом оператора и фотосчитывателем; 7 — пульт оператора; 8 — плата специального интерфейса с пультом оператора； 9 ——пульт обучения; 10 — интерфейс с пультом обучения： 11 ~ таймер； 22 — цифроаналоговые преобразователи управления приводом робота; 23—ввод показаний кодовых датчиков робота; 14, 15 — соответственно ввод и вывод технологическик сигналов； 16 — контроллер накопителя на кассетной магнитной ленте; 77 — накопитель на кассетной магнитной ленте; 18 — плата 321 интерфейса с перфоратором; 79 — перфоратор ПЛ-150
夕
夕
Рис. 1. Общая структурная схема логического устройства У КМ-7 72
Рис. 1. Общая структурная схема логического устройства У КМ-7 72
1 — процессор «Электроника-60»; 2 — оперативное запоминающее устройство; 3 — адаптер, согласующий общую шину А с общей шиной В; 4 — постоянное запоминающее устройство; 5 — фотосчитыватель; 6 — плата В1 интерфейса с пультом оператора и фотосчитывателем; 7 — пульт оператора; 8 — плата специального интерфейса с пультом оператора； 9 ——пульт обучения; 10 — интерфейс с пультом обучения： 11 ~ таймер； 22 — цифроаналоговые преобразователи управления приводом робота; 23—ввод показаний кодовых датчиков робота; 14, 15 — соответственно ввод и вывод технологическик сигналов； 16 — контроллер накопителя на кассетной магнитной ленте; 77 — накопитель на кассетной магнитной ленте; 18 — плата 321 интерфейса с перфоратором; 79 — перфоратор ПЛ-150
1 — процессор «Электроника-60»; 2 — оперативное запоминающее устройство; 3 — адаптер, согласующий общую шину А с общей шиной В; 4 — постоянное запоминающее устройство; 5 — фотосчитыватель; 6 — плата В1 интерфейса с пультом оператора и фотосчитывателем; 7 — пульт оператора; 8 — плата специального интерфейса с пультом оператора； 9 ——пульт обучения; 10 — интерфейс с пультом обучения： 11 ~ таймер； 22 — цифроаналоговые преобразователи управления приводом робота; 23—ввод показаний кодовых датчиков робота; 14, 15 — соответственно ввод и вывод технологическик сигналов； 16 — контроллер накопителя на кассетной магнитной ленте; 77 — накопитель на кассетной магнитной ленте; 18 — плата 321 интерфейса с перфоратором; 79 — перфоратор ПЛ-150
ления промышленного робота, является необходимость оперативного расчета траектории движения рабочего органа непосредственно в ходе воспроизведения программы управления роботом. Выполнение интерполяции в рамках режима воспроизведения программы управления с решением прямой и обратной задач о положении механизма (например, «Универсал-15») в реальном времени может потребовать использования процессоров с общей производительностью порядка нескольких миллионов операций в секунду. В случае применения устройства числового программного управления единственного процессора «Электроника-60» с производительностью 150 тыс. операций в секунду приходится прибегать к использованию промежуточной формы представления управляющей программы — рабочей форме управляющей программы, которая в отличие от исходной формы управляющей программы содержит не только узловые точки представляемой траектории движения, но и информацию о резуль-
татахтатахзаблаговремеяно выполненной задачи интерполяции. Преобразование исходной формы управляющей программы в рабочую форму должно в таком случае осуществляться в рамках специального режима работы системы (режим трансляции).
татах
татах
Число промежуточных точек расчетной траектории, координаты которых представлены в рабочей форме управляющей программы, может существенно превышать число узловых точек, представляемых ее исходной формой. Это число может быть так велико, что без принятия специальных мер объем внешней памяти, занимаемой рабочей формой упрарлятощей программы# окажется нецомерно
多 Заказ № 24腸
большим. Кроме того, ограниченная пропускная способность канала доступа к внешним устройствам может привести к тому, что воспроизведение такой рабочей формы управляющей программы (точнее, управляющей программы, представленной в виде такой нерациональ- но построенной рабочей форлш) в реальном времени окажется во- обще невозможным. Рациональное (существенно более компактное) построение рабочей формы управляющей программы возможно потому, что непосредственная запись значений координат всех промежуточных точек расчетной траектории обладает существенной из、 быточностыо. В реальных ситуациях за счет несложных преобразо- ваний «развернутой» (содержащей в явном виде значения координат всех промежуточных точек) записи траектории движения рабочего органа можно добиться сокращения объема памяти, требуемой для представления траектории в несколько раз (и даже в несколько десятков раз). При этом время обратного преобразования (в развер- нутую форму) будет существенно меньше времени трансляции соответствующей исходной формы (на два-три порядка).
Формирование и редактирование исходной формы управляющей программы (содержащей, помимо значений координат узловых то- аек, различную информацию об условиях движения, информацию о требуемом характере взаимодействия с технологическим оборудованием) осуществляется в режиме обучения. Семантика включаемых в исходную форму управляющей программы технологических команд задается специальными спецификациями, формируемыми на этапе адаптации системы к архитектурным особенностям конкретного технологического оборудования.
Для реализации перечисленных функций системы необходима разработка набора функциональных модулей, объединяемых в систему информационными (параметрическими и сигнальными) связями. Поскольку число таких модулей может быть достаточно велико, для успешного решения задач синтеза системы, анализа ее свойств, внесения необходимых модификаций необходимо при построении системы руководствоваться какими-то ясными общими принципами. В рассматриваемой системе модули группируются в две функционально-самостоятельные ветви (ветвь перемещений и ветвь взаимосвязей) и, кроме того, располагаются слоями, составляющими иерархические уровни системы (рис, 2).
Такое структурирование системы обусловлено общепринятыми принципами иерархического построения развитых управляющих систем и естественным объединением функционально родственных блоков в функциональные связи с идентичными критериями разделения на иерархические уровни. Связь ветвей в систему осухцествляется в первую очередь за счет общих для обеих ветвей модулей старшего иерархического уровня, а также за счет информационных и сигнальных связей между операционными модулями, принадлежащими различным ветвям.
Со стороны модулей низшего иерархического уровня к ветвям функциональных модулей примыкают контролируемые системой внешние процессы (связь с внешними процессами осуществляется
Рис. 2. Алгоритмическая структура варианта функционального программного обеспе- «гения устройства управления УКМ-772
2——диспетчер режимов; 2 ——дешифратор директив оператора； 3 ——транслятор； 4 ——интерпретатор управляющей программы; 5 ——интерпретатор технологических команд;
6 ——монитор экрана; 7 — диспетчер диалога； 8 ——редактор текста; 9 ——потактовый интерпретатор примитивной формы управляющей программы； 10—14——драйверы: техно* логический, пульта оператора, инженерного пульта, пульта обучения и привода соответственно; ?5 — технологическое оборудование; 76——78 — пульт оператора, инженера, обучения соответственно; 19 — таймер
工——модуль А обращается к процедуре В; II "-модуль А обращается к монитору В; III — модуль А устанавливает значение флага, модуль В реагирует на это значение в точках ветвления переходом на одну из альтернативных ветвей; IV — модуль А открывает семафор, модуль В приостанавливается до открытия семафора и/или закрывает его
через внешние регистры системы, а также через систему внешних прерываний).
Внешние процессы могут рассматриваться как отдельный (нулевой) иерархический уровень. Алгоритмы функционирования этих процессов определяются средствами, внешними по отношению к рассматриваемой управляющей системе.
Алгоритмы и временные параметры работы технологического (например, сварочного) оборудования определяются конструктивными особенностями этого оборудования и, возможно, особенностями текущей ситуации (температура окружающей среды, качество электрода и т. п.). Алгоритмы работы оператора (настройщика, инженера), взаимодействующего с системой через клавиатуру и средства индикации доступных ему пультов, зависят от целей, которые ставит перед собой оператор, особенностей состояния пульта и особенностей состояния самого оператора. Алгоритм и параметры работы мани
нунятора определяются конструкцией и состоянием привода, механики 圆 рабочего пространства.
Результаты реализации алгоритмов нулевого уровня доступны управляющей системе в виде данных, поступающих через внешние регистры и ио каналам внешних прерываний.
Первый иерархический уровень (низший уровень собственно функциональных блоков системы) составляют драйверы внешних устройств (процессов):
модули, реализующие алгоритмы регулирования (замыкают контур управления положением манипулятора);
модули индикации информации на табло пульта управления роботом;
модули ввода информации с клавиатуры пульта;
модули связи со сварочным оборудованием.
Драйвер привода активизируется но тактовым сигналам аппаратного таймера с частотой несколько десятков герц (эта частота вы* бирается в зависимости от требований точности реализации расчетной траектории движения рабочего органа, соотношения между объемом вычислений, требуемых для выполнения одного цикла работы алгоритма регулирования, и производительностью процессора, выделенного для реализации этих вычислений).
По окончании каждого цикла работы драйвер привода ах^тиви- рует модуль второго иерархического уровня (тактовый интерпретатор), который формирует значения параметров для реализации следующего цикла регулирования. 一
Драйвер технологических процессов отвечает за своевременный обмен информацией со сварочным оборудованием — обработку прерываний, формирование сигналов, ввод—вывод значений технологических признаков, формируемых на внешних (технологических) регистрах.
Драйверы пультов (оператора, настройщика, инженера) обеспечивают формирование последовательности сообщений, поступающих с пультов, а также вывод на индикационные табло сообщений, формируемых системой в ходе ее функционирования.
При выводе элементов сообщений драйверы пультов активизируются либо от интерфейсных блоков связи с пультами, либо по тактовым сигналам аппаратного таймера. По завершении ввода порции (строки) элементов сообщений оператора драйвер ввода пультовых сообщений активирует модуль второго иерархического уровня (диспетчер диалога).
При необходимости вывода информации на пульт соответствующий драйвер активизируется модулем старшего (второго) иерархического уровня (к этому моменту последовательность символов, составляющая строку выводимого сообщения, должна быть полностью сформирована в буферной структуре данных).
Второй иерархический уровень составляют модули иреобразова- 孝 ния представлений, переводящие вводимую информацию в форму 1 внутренних представлений, а выводимую ——в форму, иредписывае- j мую архитектурой аппаратных блоков устройства управления. 3
Циклы работы модулей второго иерархического уровня мепсе жестко привязаны к синхронизируюп],им сигналам, поступающим от внешних процессов (и от аппаратного таймера). Например, если для драйвера привода может требоваться жесткая привязка цикла его работы к моменту поступления тактового сигнала, то цикл работы тактового интерпретатора может быть выполнен в любое время на интервале между двумя тактовыми сигналами. Тактовый интерпретатор устанавливает расчетные значения параметров алгоритма регулирования в соответствии с предписаниями текущего оператора управляющей программы.
Диспетчер диалога выполняет синтаксический анализ введенной строки, формирует внутренние коды вводимых сообщений. При выводе сообщений диспетчер диалога формирует в буферной структуре данных требуемую строку.
Интериретагор технологических .команд обеспечивает реализацию операторов взаимодействия с технологическим оборудованием, встречающихся в управляющей программе. При этом используются соответствующие определения из массива спецификаций технологических команд.
Третий уровень составляют модули, алгоритмы которых отражают семантику основных используемых языковых форм. Так, интерпретатор управляющей программы преобразует ее текст в примитивную форму последовательности операторов модификации слов оперативного запоминающего устройства, формирования синхронизирующих сигналов и обращения к отдельным процедурам (например, процедуре интерпретации технологических команд).
Четвертый (старший) иерархический уровень содержит модули переключения режимов функционирования устройства.
При разработке программного- обеспечения устройства управления У КМ-72 широко применялась техника реализации модулей, подсистем (и вариантов системы в целом) в виде асинхронных программ, т. е. в виде совокупности вычислительных процессов, внутренне замкнутых по управлению (и взаимодействующих друг с другом за счет использования различных видов информационных связей). Такие процессы иногда называют потоками.
Взаимодействие потоков друг с другом (а также с программными модулями, «открытыми» ио управлению, например, с обычными процедурами) состоит в обмене сигналами о возникновении каких-то (ожидаемых) ситуаций (сигнальные информационные связи)圆 обмене информацией о значениях параметров ситуаций, обмене развернутыми сообщениями и информационными массивами (параметрические информационные связи).
Структура основных сигнальных связей, представляемых обращениями к процедурам и мониторам (мониторным процедурам), а также модификациями значений специальных сигнальных переменных —логических признаков (флагов) 圆 семафоров, отражена на рис. 2. Сигнальные связи типа флагов и процедур реализуются аппаратными средствами микропроцессора «Электроника-60».
Реализация сигнальных связей типа обращения к мониторам и
операций пад семафорами осуществляется за счет построения специальных программных средств. Один из возможных подходов к построению таких средств сводится к включению в состав системы специального привилегированного процесса (супервизора, диспетчера), контролирующего все сигнальные связи этих двух типов (централизованный контроль связей).
В программном обеспечении устройства управления УКМ-772 реализована идея децентрализованного построения системы (в смысле отсутствия какого-либо привилегированного процесса). Осуществление всех типов сигнальных взаимодействий в определенном смысле возлагается на сами взапмодепствуюпще модули (лри этом взаимодействующие модули могут обращаться к глобальным процедурам, выражающим алгоритмы программной реализации нужных сигнальных взаимодействий).
Разработка и испытания различных вариантов системы программного обеспечения устройства управления УКМ-772 показали, что изложенные вьиле принципы структурирования и реализации программного обеспечения для промышленных роботов достаточно рациональны и эффективны. Следование структурным принципам (и принципам реализации), учитывающим перспективу развитая программного обеспечения промышленных роботов, существенно расширяет возможности использования разработанных программных средств (в виде комплекта программных модулей и документов) в новых системах.
УДК 007.52
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТА СУР-25 ДЛЯ ДУГОВОЙ СВАРКИ
С. М. Григорович, В. И. Кавинов, А. Е. Клепов, К. В. Самвеляи, П. Ю. Юрии
Внедрение промышленных роботов в современное производство в качестве основы автоматизации и повышения производительности труда является актуальной задачей настоящего времени. Применение промышленных роботов уже перешагнуло границы использования их и а вспомогательных операциях технологических процессов, и задачей сегодняшнего дня стало использование роботов в качестве основного технологического оборудования в таких видах производства, как сборка, сварка, окраска и т. п. Одна из неотложных задач сварочного производства — разработка промышленного робота для дуговой сварки плавящимся электродом в среде защитных газов. Актуальность применения роботов именно в этом виде производства диктуется целым рядом причин, среди которых главными можно назвать следующие.
В современном производстве сварные соединения обеспечивают большую технологичность и прочность изделий. Это особенно спра-
ведливо для корпусных производств, когда сварка достигает 50— 70% общей трудоемкости изготовления изделий. Для таких производств автоматизация сварки дает большой экономический эффект. Кроме того, корпусное производство характеризуется, как правило, относительной мелкосерийностью и частой сменой типов свариваемых деталей, а следовательно, особое значение приобретают вопросы перепрограммирования и переналадки автоматизированного участка.
При изготовлении корпусов различных изделий швы, имеющие сложную пространственную конфигурацию, составляют 70—80% общей протяженности сварных соединений. Применение робота на подобных операциях возможно и целесообразно в силу того, что основное его назначение и состоит в перемещении, объектов (в данном случае сварочной горелки) по сложным пространственным траекториям. Для таких работ робот является, пожалуй, единственным средством автоматизации.
Существенно при автоматизации сварочного производства с помощью промышленных роботов то, что наряду с облегчением условий труда сварщика применение промьиплснных роботов способствует повышению качества сварных соединений. Это происходит благодаря тому, что робот обеспечивает большое постоянство параметров сварки для протяженных швов.
Отправной точкой проектирования программного обеспечения системы управления робота для дуговой сварки являются требования, обусловленные самим процессом дуговой сварки, основными из которых можно назвать следующие:
точность проведения горелки вдоль сварного шва в пределах ±1、мм;
необходимо обеспечить при перемещении манипулятора постоянство скорости горелки вдоль шва в пределах ±5%;
поддержание параметров дуги (напряжение и ток) на заданном уровне, изменение которого по программе возможно как для различных участков, так и в пределах одного участка шва;
надежное зажигание дуги и ее гашение на основе так называемой процедуры заварки кратера;
для заливки объемных швов обеспечение режима поперечного колебания горелки с изменяемыми частотой и амплитудой.
Анализ конкретных корпусных производств позволил определить первоочередные объекты автоматизации и ряд дополнительных требований к роботу.
Так как изделия, процесс изготовления которых подлежит автоматизации, имеют сложную пространственную конфигурацию сварных швов, применение универсального манипулятора является непременным условием автоматизации технологического процесса (в противовес сварочным автоматам).
Протяженность сварочного шва, заварка которого выполняется за один проход без гашения дуги, приблизительно 1,0——1,5 м. Общая протяженность швов на одном изделии составляет 10—12 м. Это требование определяет как параметры сварочного оборудования,
так и свойства системы управления (такие, как объем оперативной памяти, быстродействие и т. д.).
Точность установки изделия на сварочный пост, а также точ-. ность расположения повторяющихся швов на изделии лежат в пределах 士20 мм (без поворота), что противоречит требуемой точности перемещения горелки вдоль шва (±1 мм). Противоречие может быть снято только с помощью средств измерения истинного положения изделия и его элементов в процессе изготовления и соответствующей коррекции траекторий перемещения манипулятора.
Все эти требования и легли в основу проектирования аппаратных и программных средств промышленного робота СУР-25.
Определяющим моментом для построения программного обеспечения, его состава, архитектуры, функциональных возможностей его частей является вопрос о разделении функций между программными и аппаратными средствами, а решение его определяется современным состоянием вычислительной техники. Поэтому необходимо кратко рассмотреть состав и технические характеристики аппаратных средств промышленного робота СУР-25.
В качестве основного рабочего органа применен манипулятор модульной конструкции РПМ-25. Его грузоподъемность и манипуляционные возможности позволяют доставить горелку с необходимым оборудованием в произвольной ориентации в пределах рабочей зоны, обусловленной требованиями изготовляемой продукции. Для обеспечения требуемой точности позиционирования манипулятор снабжен 15-раз рядными кодовыми датчиками.
Для управления манипулятором разработан цифровой следящий привод, отрабатывающий уставку по положению с точностью двоичного разряда. Привод имеет два режима управления — позиционный и контурный, отличающиеся тем, что в контурном режиме по сигналу от управляющей ЭВМ отключаются формирователи характеристик разгона и торможения.
Сварочное оборудование обеспечивает управление от ЭВМ режимами сварки (тоном и напряжением), частотой и амплитудой механического колобателя горелки, а также вырабатывает ответные сигналы для ЭВМ, характеризующие работу сварочного оборудования.
Для управления промышленным роботом в рамках агрегатиро- ванных систем управления роботов и станков с числовым програм- j иным управлением была разработана система управления АС-2601 ■' (рис. 1).—；
В качестве управляющей ЭВМ использована микро-ЭВМ «Электро- 另 ника-60». К ее шине подключены устройства ввода/вывода, пульт j управления, оперативное запоминающее устройство (ОЗУ) с объ- ? емок 28К слов, таймер и модуль сопряжения с шиной СМ-3. Для | подключения всех периферийных устройств, обеспечивающих управ- ? ление оборудованием в системе, использован протокол обмена шины | СМ-3. Через модуль связи шин процессор Ml осуществляет управ- 1 ление шиной СМ-3. Для подключения системы приводов манипуля- ‘ тора и сварочного ^оборудования применяются как стандартные в агрегатированной системе модули ввода и вывода сигналов, так и
Рис. 1. Структура системы управления АС-2601
пециально разработанные модули управления движением степеней подвижности манипулятора.
В состав сварочного оборудования включен датчик касания. Его принцип действия заключается в том, что на электродную проволоку подается высоковольтное напряжение от специального источника, который выдает сигнал ЭВМ в момент возникновения слаботочной дуги. Координаты объекта при этом определяются по показаниям кодовых датчиков степеней подвижности манипулятора.
Как видно из приведенного состава аппаратных средств, в системе нет емкого внешнего накопителя. Поэтому для обеспечения выполнения требований к протяженности шва необходимо позаботиться о методе сжатия информации о траекториях движения манипулятора для ее размещения в оперативной памяти ЭВМ. Учитывая, что быстродействие микро-ЭВМ «Электроника-60» ограничено, был применен следующий подход обеспечения контурных движений манипулятора РПМ-25.
Непрерывное движение манипулятора вдоль заданной траектории обеспечивается выдачей уставок положения^ степеней подвижности с частотой, превышающей верхнюю границу полосы пропускания следящего привода (10—20 Гц). Расчет уставок в реальном времени осуществляется программой линейной интерполяции на основании последовательности координат опорных точек траектории (хранится в памяти ЭВМ в обобщенных координатах манипулятора —показания кодовых датчиков).
На основе этого представления определяются и остальные эле-
r」r」Рис. 2. Элементы траекторий движения сварочной горелкиРис. 2. Элементы траекторий движения сварочной горелкиП—эталонная траектория корневого шва; Т2 — траектория корневого шва； Т3 — тра~ ектория первого прохода; УТ—узловая точка; ОТ — опорная точка; БТ — базовая точка； ТП — точка подхода； ПТ — промежуточная точка; ТК — точка касания； ВК — вектор коррекции точки подхода； НИ — направление подходаП—эталонная траектория корневого шва; Т2 — траектория корневого шва； Т3 — тра~ ектория первого прохода; УТ—узловая точка; ОТ — опорная точка; БТ — базовая точка； ТП — точка подхода； ПТ — промежуточная точка; ТК — точка касания； ВК — вектор коррекции точки подхода； НИ — направление подхода
r」
r」
Рис. 2. Элементы траекторий движения сварочной горелки
Рис. 2. Элементы траекторий движения сварочной горелки
П—эталонная траектория корневого шва; Т2 — траектория корневого шва； Т3 — тра~ ектория первого прохода; УТ—узловая точка; ОТ — опорная точка; БТ — базовая точка； ТП — точка подхода； ПТ — промежуточная точка; ТК — точка касания； ВК — вектор коррекции точки подхода； НИ — направление подхода
П—эталонная траектория корневого шва; Т2 — траектория корневого шва； Т3 — тра~ ектория первого прохода; УТ—узловая точка; ОТ — опорная точка; БТ — базовая точка； ТП — точка подхода； ПТ — промежуточная точка; ТК — точка касания； ВК — вектор коррекции точки подхода； НИ — направление подхода
менты, необходимые для описания траекторий сварных швов (рис. 2).
Штриховой линией изображено положение узла при обучении, а сплошной — при выполнении сварки. Траектория корневого, шва представлена последовательностью опорных точек. Изображены также узловые точки, предназначенные для описания траекторий с помощью отрезков известных кривых (прямые, дуги окружности). Расчет истинных траекторий движения сварочной горелки осуществляется по имеющемуся эталонному представлению корневого шва и двум векторам — вектору смещения положения узла (ВС) и вектору смещения на проход при многопроходных швах (ВКП).
Показаны также траектории манипулятора при измерении положения узла. На основании запомненной информации, которая получена при обучении в виде координат точек касания электрода к трем плоскостям узла и координат точек касания этих же плоскостей при сварке, рассчитывается вектор смещения узла.
Таблица 1
Код
Наименование операции
Код
Наименование операции
MOVE LOOP
WELD FIRE
Перемещение в точку Перемещение по контуру
Заварка шва Зажигание дуги
GRATR MTOUCH
NPASS
PREPR
Заварка кратера Измерение положения узла
Заварка второго прохода
Подготовка сопла к сварке
j Значения параметров сварочного процесса и скорость движения 帚 вдоль шва привязаны в памяти ЭВМ к каждой опорной точке. Таким образом, технологу предоставляется возможность изменять режим сварки в зависимости от характера траектории или каких-либо других особенностей сварного шва.'
Следующий важный вопрос, решение которого существенно влияет на свойства программного обеспечения, — выбор языка представления действий робота. Основным, на наш взгляд, при решении этого вопроса является эффективность применения робота на производстве, простота эксплуатации робота, минимум дополнительных специальных знаний. Сродства языка должны быть понятны специалисту того производства, в котором применяется робот, соответствовать принятым там формам и методам описания технологического процесса.
В результате анализа технологии изготовления различных деталей были определены технологические операции и разработаны алгоритмы их выполнения. Список этих операций представлен в табл. 1.I
Состав операций обеспечивает быстрые транспортные перемещения сварочной горелки к различным участкам сварки, контурные перемещения вдоль заданной траектории с возможностью измерения в пределах различных участков скорости движения вдоль траектории и сварочных параметров. Для обеспечения гибкости робота и расширения класса решаемых им задач процессы зажигания дуги и заварки кратера выделены в отдельные операции, что позволяет «сшивать» несколько следующих друг за другом участков и осуществлять настройку процесса заварки кратера на конкретные условия окончания шва. Операции «Измерение положения узла» и «Заварка второго прохода» обеспечивают коррекцию исходной траектории движения сварочной горелки при смещении узла относительно положения при обучении и при реализации многопроходных швов. Автоматическая очистка и опрыскивание защитным покрытием сопла сварочной горелки предназначены для обеспечения длительной работы робота без вмешательства человека-оператора.
Любое задание на работу роботу при таком подходе будет пред-
Таблица 2
Наименование действия
Символ, вводимый оператором
Наименование действия
Символ, ВВОДИМЫЙ оператором
Ручное управление Формирование ТХЗ (обучение)
Сброс ТХЗ
Копирование ПО па п/л
Ввод ТХЗ с п/л
Вывод ТХЗ на п/л
Выполнение ТХЗ
Р Ф
С п т Зтг Ъп
Корректировка ТХЗ Исключение ТХЗ Распечатка ТХЗ Диагностика системы Контроль
Останов
М
У/г Лтг Д/г К/г
ставлять собой последовательность операций (их идентификаторов) с указанием конкретных параметров их выполнения (точек траек^ тории, параметров сварки и т. п.). Целесообразно такую последовательность операций с помощью специальных средств оформить в виде целостной структуры данных — технологического задания. Тогда программное обеспечение робота для дуговой сварки представляется ориентированным на работу с одним или несколькими технологическими заданиями, т. е. на их формирование, корректировку, ввод или вывод и их последовательное выполнение (операция за операцией).
Наконец, немаловажным вопросом является выбор формы общения человека-оператора с роботом. Развитие современных средств отображения информации позволяет организовать диалог между роботом и человеком-оператором таким образом, чтобы существенно сокращался поток информации от человека-оператора, а вводимая последовательность символов имела семантику автоматизируемого процесса. Для этого функционирование робота представлено в системе в виде совокупности действий робота, каждое из которых может быть выполнено по команде оператора. Действием управляет диалоговая программа, обеспечивающая выбор альтернативного варианта, где это возможно, простым ответом на вопрос системы.
Список действий робота СУР-25 приведен в табл. 2.
Функциональное назначение действий робота ясно из их названия. Среди них есть основные, обеспечивающие такие режимы работы робота, как обучение — формирование технологического задания (ТХЗ), выполнение и корректировку технологического задания, и сервисные, осуществляющие разнообразные вспомогательные режимы. Различные режимы выполнения технологического задания предписываются дополнительной информацией в соответствующей команде. Режим обучения обеспечивает в диалоге задание последовательности операций и необходимой для них информации при ручном управлении манипулятором. Фушсциопальная схема программного обеспечения представлена на рис. 3.
Включение питания устройства управления
рис. з. функциональная схема программного обеспечения робота СУР-25
После запуска системы блок инициализации осуществляет начальную установку всех необходимых массивов, спрашивает состояние внешних устройств и в диалоге с оператором настраивает изменяемые параметры системы. После завершения работы этого блока управление передается блоку обработки команд оператора. Распознав команду и подготовив необходимую информацию, этот блок осуществляет вызов модуля требуемого действия робота. В случае нормального завершения выполнения действия управление возвращается блоку обработки команд оператора.
Движение манипулятора и процесс горения дуги представляют собой динамические процессы, мгновенное изменение состояний которых невозможно. Это привело к необходимости разработки специального блока обработки аварийных ситуаций и специального механизма реализации прерывания выполнения технологического задания. Вход в блок обработки аварийных ситуаций может быть осуществлен как из блока обработки прерываний вычислительного прогресса, так и из модуля выполняемого действия при обнаружении ；непредвиденной ситуации. Этот блок осуществляет остановку сва- I рочного процесса и с соответствующим сообщениел! переход к блоку обработки команд оператора. Если возможно, после устранения неисправности оператор продолжает выполнение технологического задания.
При операхцтях, связанных с контурными движениями манипулятора, реализующий эту операцию программный модуль осущест- зпяет запуск параллельного процесса реализации движений. Синхронизация процесса планирования траектории движения манипулятора и процесса ее отработки в масштабе реального времени осуществляется с помохцью буфера уставок. Применением такого механизма достигается относительная независимость процесса планирования траектории движения манипулятора от времени ее реализации, с одной стороны, а с другой — обеспечивается возможность плавного разгона и торможения лганипулятора при ошибках в планировании или ошибках оператора при обучении.
Программное обеспечение робота для дуговой сварки СУР-25
может быть охарактеризовано следующим образом. Общий объем памяти, занилтаемый программным обеспечением, составляет 16К слов. Общее количество программных модулей составляет 120 модулей. Из них 70 модулей, относящиеся к системной части, обеспечивают функционирование робота на различных режимах, а 50 модулей, составляющих прикладное математическое обеспечение, выполняют кинематические расчеты при изменении положения узла, коррекции траекторий и т. д. Соотношение объемов памяти, занимаемых системной и прикладной частями, составляет примерно один к- одному. Средства, обеспечивающие диалоговый режим с человеком-оператором, составляют приблтгагйтельно 15% объема памяти системной части программного обеспечения. Объем адресуемой оперативной памяти, остающейся для размещения технологических заданий, составляет 12К слов. Это позволяет запомнить 760 кадров технологического задания, что составляет приблизительно 15 м мно- гопроходимых швов.
Проведенная разработка программного обеспечения робота СУР-25 позволяет сделать заключение о том, что система управления контурными движениями манипулятора антропоморфной кинематики, предназначенная для широкого класса сварочных работ с возможностью формирования и выполнения технологических заданий при развитом диалоге между роботом и человеком-оператором и оснащенная элементарными средствами адаптации к условиям рабочего пространства, представляется в известном смысле иредельной по сложности для аппаратных средств, использующих ЭВМ класса «Электроника-бО». Подобные системы, по~видимому, могут образовать самостоятельный класс в ряду систем управления нромышлеи- ных роботов и занимать ступень между позиционными системами управления и адаптивными системами управления, наделенными эффективными средствами описания и анализа рабочего пространства робота.
* * *
Представление траектории движения антропоморфного манипулятора в виде последовательности опорных точек с произвольным шагом, обусловленным требуемой точностью движения, и реализация движения манипулятора с помощью программы линейной интерполяции, работающей в режиме реального времени, позволяют, наиболее эффективно использовать ресурсы ЭВМ выбранного класса для реализации протяженных швов.
Описание цроцесса сварки с помощью технологического задания, состоящего из операций, специфических для сварочного производства, позволяет существенно облегчить работу оператора при обучении робота и сократить объем информации, вводимой олератором при этом.
Диалоговая форма общения между роботом и человеком-оператором, реализованная в программном обеспечении системы управления, помогает оператору в выборе требуемого от него действия и необходимой при этом информации.
УДК 007.52:62—52
СИСТЕМА УПРАВЛЕНИЯ
СВАРОЧНЫМ РОБОТИЗИРОВАННЫМ КОМПЛЕКСОМ С ИСПОЛЬЗОВАНИЕМ МИКРО ЭВМ
Ф. Н. Кисилевский, В. Т. Тертышный, Н. Р. Швыдкпп
Эффективность применения промышленных роботов в производстве, в частности при сварке, определяется их способностью к быстрой перенастройке на новое изделие, высоким качеством ведения технологического процесса при одновременном повышении производительности. Реализация этих качеств в значительной мере зависит от возможностей системы управления.
В Институте электросварки имени Е. О. Патона АН УССР разработана система управления робототехническим комплексом для дуговой сварки, позволяющая в полной мере использовать преимущества нового вида оборудования в сварочном ироизводетве. Система осуществляет управление комплексом оборудования, в который входят:，
манипулятор сварочного инструмента, имеющий пять степеней подвижности с электроприводами постоянного тока;
манипулятор изделия с двумя стеиенями подвижности, приводимыми в движение электроприводами постоянного тока;
комплект сварочного оборудования (источник .сварочного тока, механизм подачи присадочной проволоки, водоохлаждаемая горелка, газоаппаратура, механизм очистки и смазки горелки, механизм обрезки проволоки и т. и.)*
При разработке системы основное внимание было уделено решению следующих задач:
высокие качественные показатели управления (точность управления движением, адаптация к неточностям сборки и установки свариваемых изделий);
максимальная надежность функционирования комплекса;
простота обслуживания и эксплуатации комплекса;
возможность создания на базе основной модели гаммы модификаций как с расширенными функциональными возможностями, так и упрощенных.
Функциональная структура системы управления включает три иерархических уровня:
планирования и координации;
управления элементарными операциями в реальном масштабе времени;
сервоуправления исполнительными устройствами.
Первые два уровня реализованы программными средствами, а третий — аппаратно. В связи с недостаточно высокой производитель- ностью современных микро-ЭВМ в состав технических средств системы, реализующих программно выполняемые функции, включены две микро-ЭВМ «Электроника-60» с набором периферийных устройств.
В дальнейшем появление более производительных микропроцессоров позволит реализацию созданного программного обеспечения в однопроцессорной конфигурации системы. В настоящее времл использование одного процессора возможно при уменьшении набора функций системы управления.
Структурная схема системы приведена на рисунке.
Блок планирования и координации (БПК) включает, помимо микропроцессора и модулей запоминающих устройств (ОЗУ — оперативное и ППЗУ — программируемое постоянное), следующее периферийное оборудование： центральный нульт управления (ЦПУ); выносной пульт оператора (ПО); устройство внешней памяти; устройство параллельного обмена для связи с внешним технологическим оборудованием.
Обмен данными между микропроцессором и периферийными устройствами осуществляется с помощью общей шины.
Центральный пульт управления предназначен для обеспечения интерактивного взаимодействия оператора с комплексом во всех режимах работы, в том числе для перевода системы управления из одного режима работы в другой, для редактирования текстов программ технологических процессов, для тестирования и отладки системы управления при проведении технического обслуживания и регламентных работ. В состав центрального пульта управления входит универсальная клавиатура и дисплей.
Пульт оператора представляет собой переносной пульт с ограниченным набором органов управления (клавиш) и индикации, связанный с системой достаточно длинным кабелем. С помощью пульта оператора возможно «ручное» перемещение манипуляторов комплекса, формирование и редактирование программ технологического процесса.
В качестве устройства внешней памяти в системе управления
использован накопитель на гибких магнитных дисках (НГМД). Основное назначение устройства внешней памяти в системе — хранение библиотеки программ технологического процесса. Однако в сложных модификациях системы возможно хранить на магнитном носителе и часть системных программ, организовав оверлейный режим работы программного обеспечения.
Блок управления манипуляционной системой (БУМ) состоит из микропроцессора с набором модулей памяти. Связь между блоками ВПК и БУМ осуществляется через устройство параллельного обмена.
Модуль сервоуправления приводами манипулятора (МУСП) включает в себя узел обмена данными и синхронизации и набор однотипных узлов цифрового управления сервоприводом постоянного тока по числу звеньев манипуляционной системы (не более девяти). Связь между МУ СП и БУМ осуществляется с помощью общей шины.
При использовании в составе манипуляционной системы роботизированного комплекса манипулятора изделия с цикловым управлением в состав системы управления включается модуль циклового управления манипулятором изделия (МУМИ), который также связан с БУМ через общую шину.
Блок управления сварочным оборудованием (ЕУСО) представляет собой микронроцоссорный контроллер с набором периферийных модулей (цифроаналоговые и аналого-цифровые преобразователи, модули ввода и вывода дискретных сигналов) и предназначен для программного управления циклограммой процесса сварки и сварочным оборудованием (источником сварочного тока, приводом механизма подачи присадочной проволоки, механизмом зачистки и смазки горелки, электроклапаном подачи защитного газа). Связь между БУ СО и ВПК осуществляется по последовательному каналу передачи данных.
Широкий набор функций системы управления позволяет эффективно организовать управление технологическим процессом дуговой сварки.
При разработке системы управления особое внимание было уделено важнейшему этапу подготовки роботизированного комплекса к выполнению технологического процесса — составлению программы технологического процесса. Система управления обеспечивает возможность составления программы технологического процесса как в режиме ОБУЧЕНИЕ, так и в режиме ВНЕШНЕЕ ПРОГРАММИРОВАНИЕ. И в том и в другом случае она составляется на специально разработанном языке ROWEL.
При работе в режиме ОБУЧЕНИЕ средством взаимодействия оператора с системой является выносной пульт обучения — пульт оператора, по командам от которого система управления управляет перемещением манипуляционной системы и формирует элементы программы технологического процесса. Для облегчения работы оператора при ручном перемещении манипулятора предусмотрена возможность выбора желаемой системы координат перемещения. Помимо общепринятой системы координат звеньев манипулятора,
оператор может использовать опорную систему координат или локальную систему координат.
При работе в системе координат звеньев манипулятора каждая клавиша управления движением пульта обучения соответствует одному из звеньев (степени подвижности) манипуляционной системы.
При работе в опорной системе координат те же клавиши пульта обучения соответствуют осям опорной неподвижной декартовой системы координат, связанной с выбранной базовой точкой манипуляционной системы. При этом возможно как последовательное плоскопараллельное перемещение вдоль осей X, У, Z, так и изменение ориентации инструмента путем поворота вокруг проходящих через точку сварки вертикальной (движение А) или горизонтальной и перпендикулярной оси горелки (движение В) осей. Важно отметить, что система управления обеспечивает полную развязку между линейными и ориентирующими движениями, т. е. движения А и В выполняются с сохранением положения рабочей точки инструмента (точки сварки).
При работе в локальной системе координат клавиши пульта обучения инициируют движение относительно текущего положения сварочного инструмента: клавиши《Z》一вдоль оси сварочного инструмента (《к изделию» при направлении движения《+》и «от изделия» при направлении движения «—»); а клавиши 《X》и .«У» — перпендикулярно оси инструмента. Ориентирующие движения в локальной системе координат совпадают с аналогичными движениями в опорной системе координат.
Указанные способы ручного управления перемещением манииу- лятора наряду с возможностью выбора скорости («высокая», «низкая», «шаговая» с шагом 0,5 мм) позволяют оператору с минимальными затратами времени установить инструмент в любое требуемое положение.
Траектория перемещения сварочного инструмента записывается в программу технологического процесса в виде координат опорных точек типовых элементов — прямой, дуги окружности или замкнутой окружности. Это избавляет оператора от изнурительного процесса «обучения» робота всем промежуточным точкам траектории.
Данные о траектории фиксируются в программе технологического процесса в опорной системе координат и, таким образом, программа технологического процесса оказывается независимой от кинематической структуры манипулятора, на котором производилось обучение. Это позволяет реализовать воспроизведение программ на других комплексах независимо от кинематической структуры.
Эта же особенность системы управления позволяет формировать программы технологического процесса в режиме ВНЕШНЕЕ ПРОГРАММИРОВАНИЕ, т. е. в символьной форме с клавиатуры центрального пульта управления, используя в качестве основы чертеж изделия и технологическую картину. В языке ROWEL предусмотрены специальные операторы для задания технологических параметров —скорости сварки, тока, напряжения дуги, значений времен-
ных интервалов циклограммы процесса сварки, характеристик колебаний п т. п. Кроме того, программа технологического процесса может создаваться «комбинированным» способом: траектория перемещения —в режиме ОЕ》ЧЕНИЕ, а технологическая и управляющая информация — в режиме ВНЕШНЕЕ ПРОГРАММИРОВАНИЕ.
Комбинация указанных режимов подготовки программы технологического процесса, а также возможности, заложенные в языке ROWEL, позволяют значительно повысить производительность процесса программирования, используя механизм обращения к подпрограммам, библиотеку ранее сформированных программ техноло- гического процесса, возможность автоматической настройки программы технологического процесса по сигналам от внешних датчиков и т. д.
В процессе подготовки программы технологического процесса обязательным является этап ее отладки контроля и, при необходимости, коррекций. Система управления предусматривает набор средств, облегчающих оператору процесс интерактивной отладки программы. В любом месте возможна остановка выполнения, внесение корректив 一 замена координат опорных точек или вставка новых участков траектории, изменение технологических параметров (тока, напряжения, скорости сварки) — и немедленное воспроизведение скорректированного фрагмента, причем корректирование тех- нологических параметров, а также расстояния горелки от изделия (вылет электрода) можно осуществлять в процессе сварки при движущемся манипуляторе.
Если возникает необходимость в повторном воспроизведении не- которого участка программы, оператору достаточно в режиме ручного управления подвести инструмент к нужному участку траектории. Система управления самостоятельно найдет соответствующий фрагмент программы технологического процесса в памяти и затем по команде оператора начнет отработку.
На любом этапе подготовки программа может быть зафиксирована в библиотеке на гибком магнитном диске. Вызов и перезапись программ в библиотеку после очередного цикла отладки также можно осуществить в любой момент.
Сформированная^ и отлаженная программа использ5тется для управления технологическим процессом.
Для автоматизированного оборудования, работающего в условиях современного интенсивного производства, одним из основных качеств является надежность фракционирования, а в случае появления неисправности — предотвращение аварийной ситуации, локализация и быстрое устранение вышедших из строя узлов. При про- екти})овании системы управления был предусмотрен целый ряд мер, направленных па всестороннюю самодиагностику элементов и узлов системы на всех уровнях функционирования, что гарантирует предотвращение аварийных ситуаций. Эти меры предусматривают:
полный начальный контроль (тестирование) аппаратных средств системы управления (процессоров, запоминающих и периферийных устройств) при включении питания;
текущий контроль работы процессора и состояния системных программ при работе комплекса параллельно и независимо от выполнения основных функций;
непрерывный контроль правильности отработки заданной траектории перемещения манипуляционной системы;
блокировку управляемого оборудования при возникновении непредусмотренных ситуаций и передачу в этом случае управления оператору.
Как показывает отечественный и зарубежный опыт, эффективное использование робототехнических комплексов в сварочном производстве возможно только при наличии средств автоматической коррекции исходной программы технологического процесса в соответствии с реальными условиями, т. е. средств адаптации. В разработанной модели системы управления реализован алгоритм начальной или установочной адаптации, сущность которого состоит в корректировании траектории перемещения рабочего органа в соответствии с реальным положением сварного узла в рабочем пространстве манипулятора. Корректирование осуществляется путем комбинации преобразований параллельного переноса и поворота, причем параметры корректирующего оператора определяются в результате сравнения положения свариваемого изделия и изделия, по которому производилось программирование. Идентификация положения изделия выполняется при помощи процедуры «ощупывания» трех плоскостей изделия, которая программируется в процессе подготовки программы технологического процесса. Для этого в языке ROWEL предусмотрен ряд специальных операторов.
Идентификация выполняется автоматически для каждого очередного свариваемого изделия, причем в процессе обработки одного изделия процедура может повторяться для различных узлов. В результате компенсируется не только неточность установки изделия на сварочной позиции, ио и неточность сборки отдельных узлов.
Естественно, установочная адаптация не решает всех проблем, связанных с неопределенностью внешней среды робота. Поэтому структура системы и вычислительный ресурс микропроцессоров определялись с учетом возможности подключения более сложных сенсоров, в том числе автономно работающих сенсорных систем, и реализации алгоритмов текущей адаптации непосредственно в ходе технологического процесса. В частности, по этой причине в блоке управления сварочным оборудованием использован свободно программируемый контроллер, что позволяет в дальнейшем осуществлять технологическую адаптацию, т： е. изменение параметров режима в процессе сварки в соответствии с реальными условиями (значением зазора в стыке, реальными параметрами разделки кромок и т. п.).
Разработанная модель системы по замыслу должна быть базовой для создания гаммы модификаций. При этом переменными элементами исполнения могут быть как аппаратные узлы, так и модули системных программ. Возможные модификации системы представлены в таблице.
Модифицируемая характеристика
Вариант исполнении
Что изменяется в базовой модели
Привод звеньев манипулятора
Используемый датчик обратной связи по положению звена
Привод ПОСТОЯННОГО тока, шаговый привод, электрогидропрпвод инкрементный, абсолютный
МУСП
МУСП
Кинематическая схема м анипуляционной системы
прямоугольная, сферическая, цилиндрическая, антропоморфная
Программный модуль преобразования координат в системных программах блока БУМ
Количество управляемых сварочных робо- тов в составе комплекса
индивидуальное, групповое (до трех)
Количество блоков БУМ и БУСО, подключаемых к одному БПК
Организация библиотеки программ техно- логического процесса
локальное, централизованное
Замена устройства внешней памяти па блок передачи данных
Функциональные возможности
активная, пассивная.
Часть программных модулей ВПК вводится в со- став программного обсс- печения БУМ; исключаются ПО, ЦПУ; вводятся индикационная панель, блок передачи данных
Настройка на конкретные характеристики привода (дискретность, диапазон) осуществляется при генерации системы программного обеспечения. Таким же образом в состав программного обеспечения включается необходимый модуль преобразования координат, соответствующий кинематической схеме манипулятора. Выше подчеркивалось, что программа технологического процесса не зависит от кинематики манипуляционной системы, поэтому одна и та же программа технологического процесса может воспроизводиться и а различных робототехнических комплексах.
Термин «активная» в таблице означает вариант системы управления, на которой возможно создание и редактирование программы технологического процесса. «Пассивный» вариант системы управления позволяет только отрабатывать составленные на другом комплексе технологические программы. При этом за счет высвобождения ресурсов блока планирования и координации появляется возможность реализовать всю систему управления па одном микропроцессоре. Системное программное обеспечение этого процессора компонуется из модулей системного программного обеспечения блока управления манипуляционной системой и отдельных модулей системного программного обеспечения блока планирования и коор-
динацпи. Естественно, из состава системы управления исключаются средства формирования и редактирования программы технологического процесса, что значительно уменьшает стоимость системы управления.
* * *
На базе существующей модели системы возможно создание гаммы модификаций с более или менее широким набором функций.
Архитектура системы позволяет наращивание функций в направлении более гл5^бокой адаптации к неопределенности производственной среды.
Опытный образец системы управления демонстрировался в со- ставе советско-болгарского роботизированного комплекса на Плов- дивской ярмарке 1980 г. и награжден Золотой медалью ярмарки.
УДК 007.52
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ
ДЛЯ ДУГОВОЙ И ЭЛЕКТРОННО-ЛУЧЕВОЙ СВАРКИ С ПРЯМОУГОЛЬНОЙ СИСТЕМОЙ КООРДИНАТ И ДИСКРЕТНЫМ ПРИВОДОМ ДВИЖЕНИЯ
Ю. К. Цыганков
Робот для дуговой или электронно-лучевой сварки представляет собой сложный комплекс оборудования, в который входят механическая манипуляционная система сварочного инструмента (сварочная горелка или электронно-л5гчевая пушка), системы приводов / каждого движения манипуляционной системы, технологическое оборудование (источники сварочного тока, механизмы подачи свароч- •；： ной проволоки, аппаратура газозащиты и т. п.), система управле-: ния всем оборудованием и программное обеспечение. В состав “ оборудования могут входить и дрл^гие системы, расширяющие тех-' нологические возможности робота, например: система технического " зрения для выявления отклонений положения свариваемых соеди-: нений на изделии от заданных по чертежу или в процессе обуче- ' ния; загрузочные и транспортные устройства, автоматизирующие процессы установки свариваемого изделия на рабочую позицию и снятия сваренного изделия, транспортировку изделия до и после сварки. Один из вариантов технических средств робототехнического комплекса (РТК) показан на рис. 1.
Рассмотрим механическую манипуляционную систему сварочного робота с дискретным (шаговым) приводом, работающим в прямоугольной системе координат. В общем случае эта механическая система должна обеспечивать перемещение инструмента по произвольной криволинейной траектории в пространстве и ориентацию инструмента под заданным углом к линии сварки, Показано, что Для обеспечения такого движения манипулятор, работающий в пря-
Рис. 1. Структурная схема РТК для дуговой сварки
моутольной системе координат, должен иметь как минимум пять независимых движений: три по координатам 招弘 z и два угло- вых — ф и 7 (рис. 2) [1].
Следует отметить, что для перемещения по пространственной траектории (например, сварка двух цилиндрических поверхностей —велосипедные и мотоциклетные рамы) необходимо управлять сразу пятью движениями (перемещения инструмента и его ориентации) с соблюдением заданной скорости.
При установке датчика положения стыка может понадобиться шестая координата для ориентации датчика относительно линии сварки, т. е. необходимо осуществлять управление одновременно по шести координатам.
На рис. 2 показаны двигатели, приводящие в движение звенья координат и датчики исходных и граничных положений звеньев манипулятора. Отсутствуют датчики положений отдельных звеньев.
Система управления при отсутствии датчика положения стыка разомкнется. Для перемещения по заданной координате на двигатель выдается заданное количество импульсов, после отработки которых звено манипулятора перемещается в заданное положение. Погрешность определяется перемещением па один импульс. Начальное положение координат отсчитывается от датчика исходного (точного) положения. Датчики граничных перемещений являются аварийными и служат для сигнализации о выходе звена манипулятора из рабочей зоны.
Для упрощения задачи управления движением инструмента в манипуляторе применен механизм ориентации, который обеспечивает поворот сварочного инструмента вокруг точки сварки, т. е. при ориентации сварочного инструмента точка сварки остае ich пе-
Рис. 2. Схема размещения управляемых и информационных элементов на манипуляторе сварочного инструмента
Стрелки — направления перемещения звеньев； СИ —— сварочный инструмент (сварочная горелка); X, Y, Z ——двигатели, приводящие в движение по соответствующимкоордтг патам звенья манипулятора； Ф, Г ——двигатели ориентации сварочной горелки (поворота и наклона соответственно) ； 1 — ограничитель перемещений в отрицательном направлении по координате 冗；2 ——ограничитель перемещений в положительном направ лении по координате % и датчик точного отсчета; 3 — датчик грубого отсчета по координате х; 4 — ограничитель перемещений в отрицательном направлении по координате у; 5, 6 — датчики точного и грубого отсчета соответственно по координате у; 7 — ограничитель перемещений в положительном направлении по координате у; 8, 10 — огра- ничители перемещений соответственно в положительном и отрицательном направлениях по координате z; 9 — датчик точного отсчета по координате z; 11, 72 —— датчики и ограничители перемещений по координатам ориентации (по координатам Г и Ф соответственно) ;13 — подающий механизм сварочной проволоки
подвижной. Траектория точки сварки рассчитывается по трем координатам 冗,у, z, а ориентация но координатам ① и 丫 не изменяет положения точки сварки, т. е. они являются дополнительными, определяющими направление сварочного инструмента.
Управление сварочным оборудованием сводится к заданию установленных режимов работы и поэтому не представляет сложности, так как выполняется перед началом сварки, а в процессе сварки остается неизменным.
Таким образом, объект управления — сварочный робот с оборудованием, расширяющим его технологические возможности,— представляет собой сложную систему.
Микро-ЭВМ позволяют создавать системы управлеиия с разными функциональными возможностями, для работы с различными РТК путем настройки программного обеспечения или замены программных модулей практически без изменеиия состава технических средств системы управления [1—9].
Рис. 3. Структурная схема программных модулей снстемы управления РТК для дуговой сварки
При создании программного обеспечения РТК для дуговой сварки необходимо учитывать особенносте технологического процесса, технические характеристики используемого оборудования и предъявляемые к нему требования:
большое количество управляемых процессов, требующих обслуживания в моменты времени, которые нельзя предусмотреть заранее, т. е. асинхронных;
высокий темп обработки информации (особенно при наличии сенсорных устройств);
ограниченные ресурсы микро-ЭВМ;
модульный принцип построения РТК, т. е. состав входящего в РТК оборудования должен выбираться в зависимости от конкретных технических условий его применения;
обеспечение высокой надежности, так как сбой может привести к аварии.
В общем случае программное обеспечение РТК состоит из двух независимых подсистем (рис. 3):
программное обеспечение для реализации обучения робота;
программное обеспечение, выполняющее отработку готовых технологических программ сварки.
Программное обеспечение для подготовки технологических программ (программы сварки изделия) методом обучения в процессе их отработки не используется. Это обстоятельство позволяет разрабатывать программные модули для каждой из указанных подсистем независимо друг от друга.
От характеристик технологического процесса программные модули подсистемы обучения не зависят. При их создании должны учитываться возможности микро-ЭВМ и оборудования, используемого
в процессе обучения, а также необходимость обеспечения удобства работы оператора в процессе обучения.
Основное требование к системе обучения 一 сформировать технологическую программу сварки (массив кадров) с учетом ограничений, накладываемых ресурсами микро-ЭВМ и технологическим процессом.
Состав программных модулей подсистемы зависит от конкретных требований, связанных с удобством подготовки технологических программ и составом оборудования РТК.
Подсистема отработки готовых программ должна обеспечивать работу в реальном масштабе времени всего оборудования, входящего в РТК.
Основным звеном РТК является сварочный робот, который выполняет главную технологическую операцию — сварку.
Рассмотрим, как влияют конструктивные особенности робота (см. рис. 2) на состав программных модулей подсистемы выполнения технологической программы сварки. Робот функционирует в прямоугольной системе координат. Привод его движений — дискрет- ный (шаговый электродвигатель).
Ориентация сварочной горелки (наклон и вращение) развязана от основных движений (по осям X, У, Z), т. е, не изменяется положение точки сварки [1, 10].
Таким образом, использование робота с механизмом ориентации, не влияющим на положение точки сварки, позволяет решать зада- пу перемещения точки сварки по заданной траектории в системе координат 况，у, z с заданной скоростью, используя простые законы управления, и одновременно независимо управлять ориентацией сварочной горелки по координатам ср и у.
Это позволило отказаться от аппаратных интерполяторов, реализовать их программным путем и все необходимые расчеты траекто- рий и скоростей выполнять в процессе подготовки программы в подсистеме обучения. Такая предварительная подготовка обеспечивает высокую скорость обработки управляющей информации для дискретного привода программными модулями подсистемы отработки. Сочетание высокой скорости обработки управляющей информации для дискретного привода с возмояпюстью работы дискретного привода без обратной связи позволило осуществить прямое цифровое управление движениями робота от микро-ЭВМ в реальном масштабе времени.
На рис. 3 показан состав программных модулей для системы управления РТК, в который входит робот с дискретным приводом.
При создании п])ограммных модулей для РТК был разработан и проверен в соответствующем диапазоне скоростей программный модуль поддержания сварочпой скорости. Это позволило осуществлять управление дискретным приводом непосредственно через блок параллельного обмена микро-ЭВМ. Из-за ограниченного быстродействия микро-ЭВМ на маршевых скоростях он не обеспечивал поддержание заданной скорости и был заменен аппаратным таймером, который отличался от традиционного наличием блока разгона и 90
торможения дискретных (шаговых) двигателей. Скорость вращения дискретного двигателя задается частотой следования управляющих импульсов.
Рассмотрим основные характеристики системы управления, которые обеспечивают программные модули подсистемы отработки заданной программы на микро-ЭВМ «Электроника-60».
Частотное управление шаговым двигателем в диапазоне сварочных скоростей осуществляется изменепием частоты от 0 до 1000 Гц. В этом интервале частот возможна линейная интерполяция по пяти координатам (три движения для перемещения в рабочей зоне, два — для ориентации сварочного инструмента) и линейно-круговая в горизонтальной плоскости (по координатам х и у — круговая, .а по ф — линейная для ориентации сварочной горелки).
Ограничений на типы интерполяции программное обеспечение :не накладывает, и при необходимости может быть введен новый ；тип интерполяции путем добавления нового программного модуля.
Дискретный двигатель обеспечивает маршевые перемещения на 1астотах до 16 кГц, ио из-за ограниченного быстродействия микро- ЭВМ скорость перемещения сразу по трем координатам лежит в пределах до 4 кГц, а при движении только по одной координате — в пределах 12—14 кГц в зависимости от исполнепия конкретной микро-ЭВМ «Электроника-60». -
Прямое цифровое управление позволило суш;ествепно упростить аппаратную часть системы управления и свести ее в основном к регистрам данных и состояния (например, блока параллельного обмена и стандартного набора микро-ЭВМ «Электроника-60»), работающих на элементы согласования уровней с нагрузкой (коммутатор дискретного привода).
Объем памяти, необходимый для программных модулей, интерпретирующих отрабатываемый кадр, осуществляющих интерполя- цию и выдачу управляющих сигналов на дискретный привод, не превышает 1,5 К слов. С модулями реакции па аварийные ситуации и массивом кадров обилий объем программы отработки не превышает 4К слов.
К преимуществам применения дискретного привода можно отнести:
одновременность выдачи управляющей информации прямо в цифровой форме на все двигатели;
отсутствие программных модулой лреобразоиания информации для выдачи на цифроаналоговый преобразователь и приема с аналого-цифрового преобразователя с целью получения информации о скорости движения；
отсутствие программных модулей приема информации с датчиков положения координат и расчета рассогласования;
отсутствие погрешностей, вызванных преобразованиями информации из аналоговой формы в дискретную и наоборот;
существенное сокращение общего объема программных модулей;
возможность при увелтпении быстродействия микро~ЭВМ реализовать программным путем функхцти, которые в настоящее время
решаются схемным путем (замена схемного таймера для задания маршевых движений манипулятора программными модулями);
простота осуществления коррекции траектории по информации от сенсорных систем путем суммирования выдаваемых по координатам импульсов на данном шаге с поправкой.
В описанной системе управления сенсорная система не испытывалась. При ее наличии будет обеспечен контроль положения сварочного инструмента относительно изделия. Таким образом, система становится замкнутой.
К недостаткам такого технического решения можно отнести: невозможность реализации программным путем плавных движений при низких частотах управления (малых скоростях движения лшнипулятора);
затруднительность, а при больших скоростях невозможность реализации программным путем характеристик разгона и торможения;
отсутствие контроля положения рабочего органа в процессе отработки в разомкнутых системах, что требует дополнительных устройств для предотвращения аварийных ситуаций, связанных с отказами дискретного привода: установка датчиков наезда на препятствие, установка датчиков ограничения перемещения по всем движениям (это приводит к необходимости разработки программных модулей обработки информации с этих датчиков и принятия решений при аварийных ситуациях);
жесткие требования' к быстродействию микро-ЭВМ при прямом цифровом управлении дискретным приводом (например, при частоте выдачи импульсов па двигатель 16 кГц резерв времени для микро-ЭВМ составляет всего 62,5 мкс в сравнении с диапазоном 1—20 мс для систем с аппаратной развязкой; такое ограниченное время не позволяет использовать систему прерываний— реакция на прерывание в микро-ЭВМ <(Электроника-60» составляет порядка 200 мкс — при организации программного обеспечения модулей выдачи и увеличивает их количество, так как для больших скоростей приходится создавать специальные модули; в процессе работы таких модулей система не может реагировать ни на какие внешние события, кроме аварийных; при возникновении аварийного события во время отработки на большой скорости процесс движения заканчивается некорректно, т. е. система теряет сведения о местоположении рабочего инструмента и восстановить ее можно только при вмешательстве оператора);
необходимость упорядочения информации, определяющей задание программным модулям для минимизации времени ее анализа при отработке (другими словами, кадр для отработки должен учитывать скоростные возможности модуля отработки).
Из всех недостатков отсутствие реакции системы на все внешние события, не связанные с отработкой движения, кроме аварийных,—— самый существенный, так как при быстрых перемещениях время таких участков, на которых система не реагирует на другие запросы, зависит от пути перемещения и может составлять несколько секунд.
Рнс. 4. укрупненный алгоритм работы при обученииРнс. 4. укрупненный алгоритм работы при обучении
Рнс. 4. укрупненный алгоритм работы при обучении
Рнс. 4. укрупненный алгоритм работы при обучении
На рис. 4 и 5 изображены укрупненные алгоритмы подсистемы обучения и отработки соответственно.
Выдача воздействия на двигатели и запись новой информации об очередном шаге — асинхронные процессы. Расчет очередного шага интерполяции начинается сразу же после выдачи управляющей информации для реализации предыдущего шага. Для нормальной работы программных модулей интерполятора и модуля выдачи необходимо выполнение следующего условия:
Ринт〉％нд.
т. е.т. е.скорость расчета очередного шага должна быть больше ско-
т. е.
т. е.
Начало
Рис. 5. Укрупненный алгоритм работы при отработке задания
рости выдачи на двигатель (скорость выдачи на двигатель определяется таймером и лежит в диапазоне от 0 до 16 кГц).
Скорость работы интерполятора зависит от числа одновременно срабатываемых координат, при этом сохраняется зависимость
%>%+1,
где 左一количество одновременно отрабатываемых координат; 匕=tW12 кГц (для микро-ЭВМ «Электроника-60»).
После завершения отработки всех шагов заданного кадра программный модуль интерпретации кадров задания извлекает очередной кадр, расшифровывает его, настраивает и запускает один из модулей интерполяции. Далее процесс отработки повторяется, <
После обнаружения признака конца программы интерпретатор кадров задания передает управление на модуль организующей программы, который выходит на связь с пультом оператора.
При проектировании рассмотренного программного обеспечения ставились следующие задачи:
94
создать такой состав модуле立,которые могли бы реализовать простейшие системы, выполняющие только отработку готовых программ, а информацию о технологической программе получать по каналам связи от ЭВМ, управляющей участком или цехом (стои
мость таких простых систем существенно снижается и, как след
ствие, повышается их экономическая выгода, так как по возможностям выполнения готовых программ они не уступают системам с программными модулями обучения, редактирования и другими узлами, облегчающими настройку);
дать возможность превратить простую систему в более сложную за счет подключения дополнительных внешних устройств и новых программных модулей, обеспечивающих работу этих устройств;
создать предпосылки для замены аппаратной части системы управления программными модулями при использовании микро-ЭВМ с большими быстродействием и объемом памяти;
применять для подготовки технологических программ и редактирования ЭВМ верхнего уровня, не увеличивая состава программных модулей в самой системе управления;
использовать, для более сложных технологических процессов (например, электронно-лучевой сварки) двухмашинный вариант системы управления, который устраняет недостатки одномашинного варианта, связанного с «?кесткой привязкой» ЭВМ при отработке быстрых перемещений;
пол5тчить высокие характеристики надежности РТК за счет применения в манипуляторах линейного шагового привода, не имеющего вращающихся частей, редукторов и тому подобных механических соединений, не меняя архитектуры системы управления и состава программных модулей.
В перспективе, когда будут стандартные интерфейсы и стабилизируется состав технических средств РТК, для них можно будет создать отдельные программные модули, которые позволят генерировать систему с заданными свойствами [6].
ЛИТЕРАТУРА
Цыганков ТО. ^. Перспективы создания и внедрения сварочных роботов.— В кн.: Научные проблемы робототехники. М.: Паука, 1980, с. 30—35.
Олейник А. М, Цыганков Ю. Я. Робот для дуговой сварки в защитных га~ зах.——В кн.: Всесоюз. совет, по робототехническим системам, Владимир, окт. 1978 г.: Тез. докл. М.: Наука, 1979, с. 47—51.
Корости几ь Ю. М., Цыганков Ю. ^. Некоторые вопросы создании системы управления сварочными роботами.——В кн.: Всесоюз. советц. по р()6ототех~ ническим системам, Владимир, окт. 1978 г.: Тез. докл. М.: Наука, 1979, с. 52—57.
Цыганков Ю. Я. Одип из подходов к трактовке искусственного интеллекта в системах управления сварочным роботом.——В кп.: Робототехнические системы в отраслях народного хозяйства: Тез. докл. II Всесоюз. советц. по робототехническим системам, Минск, 15—19 мая 1981 г. Минск: БЕЛНИИТИ, 1981, с. 94—95.
Гребенюк Ю. П., Ледорезов В. М., Цыганков Ю. К. Многоуровневый подход к использованию датчиков для адаптации сварочных роботов.— В кн.： Робототехнические системы в отраслях народного хозяйства： Тез. докл.
II Всесогоз. совещ. по робототехническим системам, Минск, 15—19 мая 1981 г. Минск: БЕЛНИИТИ, 1981, с. 95.
Никифоров В. В. Алгоритмические средства построения системы управления роботами.——В кн.: Алгоритмические модели в автоматизации исследований. М.: Наука, 1980, с. 186—193.
Никифоров В. &, Смирнов Н. 4, Чиганов В. А. Унификация архитектуры и алгоритмической структуры средств управления промышленными роботами.——В кн.： Алгоритмические модели в автоматизации исследований. М.: Наука, 1980, с. 186—193.
Домарацкий А. Я., Кулаков Ф. М., Сурма С. В. Микропроцессорные систе- мы управления манипуляционными роботами на основе стандарта САМАС.— В кн.: Алгоритмические модели в автоматизации исследовании. М.: Наука, 1980, с. 156—163.
Чвертко А. И., Патон В. Е., Тимченко В. А. Оборудование для механизированной дуговой сварки(и наплавки. М.: Машиностроение, 1981. 264 с.
А.с.556016 (СССР). Устройство для пространственной ориентации сварочной головки/В. В. Васильев, Г. И. Закс, А. И. Олейник, Ю. К. Цыганков. Опубл, в Б. И., 1977, № 16. 39 с.
УДК 007.52
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
ПРОМЫШЛЕННОГО ОКРАСОЧНОГО РОБОТА «КОЛЕР»
А. П. Федосеев, В. И. Григорьев, С. А. Чевтаев, Л. В. Цуева
В последнее время существенно увеличились выпуск и использование промышленных роботов с программным управлением, позволяющих исключить применение ручного труда (особенно в тяжелых и вредных для человека условиях) [1].
Заметное место среди них занимают роботы для нанесения лакокрасочных покрытий с контурной системой управления. К роботам такого типа относится разработанный окрасочный робот «Колер».
В статье рассматриваются структура и состав программного обеспечения системы управления робота «Колер», алгоритмы основных программ и работа всего комплекса в целом.
Система управления (рис. 1) выполнена на базе модулей агре- гатированной системы и микро-ЭВМ «Электроника-60». На пульте системы управления расположены клавиатура, с помощью которой задаются режимы работы, и индикаторы состояния системы управления и робота.
В процессе обучения информация о положении звена манипулятора поступает с модуля текущей координаты (МТК) в ЭВМ и записывается в область оперативного запоминающего устройства (ОЗУ), если на модуле пассивных сигналов (МПС) есть задаваемый с пульта обучения сигнал ЗАПИСЬ РАЗРЕШЕНА. Аналогично обрабатываются функциональные команды ПОВОРОТ РАСПЫЛИТЕЛЯ и ВКЛЮЧЕНИЕ РАСПЫЛИТЕЛЯ, также задаваемые с пульта обучения. Модуль силовыхi реле (МСР) предназначен для включения внешнего оборудования, в частности, для включения- выключения гидростанццз (ГС) и дсцоднеция функциондльнвд
的
Рис, 1, Структурная схема системы управления робота «Колер»Рис, 1, Структурная схема системы управления робота «Колер»
Рис, 1, Структурная схема системы управления робота «Колер»
Рис, 1, Структурная схема системы управления робота «Колер»
команд. Информация о состоянии внешнего оборудования поступает на МПС и анализируется в ЭВМ.
В процессе воспроизведения в ЭВМ вырабатывается управляющее воздействие с целью обеспечения движения по контуру, заданному в процессе обучения. Управляющий цифровой сигнал преобразуется в аналоговый в модуле управления координатой (МУК), далее усиливается по мощности и напряжению в модуле сервоусилителя и подается на золотник, управляющий подачей масла в гидроцилиндр, который приводит в движение звено манипулятора.
Связь всех модулей осуществляется через ЭВМ. Логика работы определяется заложенным программным обеспечением.
Структура программного обеспечения определялась следующим: функциональными требованиями к системе управления;
элементной базой системы управления — управляющей ЭВМ и модулями агрегативной системы;口
наличием уже разработанных программных модулей.
Структура программного обеспечения системы управления робота «Колер» приведена на рис. 2. Программное обеспечение реализует работу робота в следующих режимах: обучение; воспроизведение; работа с перфолентой; тестовый; чтение и запись параметров; ручной.
В режиме обучения оператор формирует рабочую программу, представляющую собой совокупность значений координат, определяющих траекторию движения манипулятора и кодов функциональных команд, записанных в ОЗУ системы управления согласно определенному формату.
Режим воспроизведения, предназначенный для отработки рабочей программы, имеет три подрежима:
полная отработка рабочей программы с пуском с пульта управления;
отработка рабочей программы без выполнения функциональных команд с запуском с пульта управления;
полная отработка рабочей программы с запуском по сигналу от внешнего устройства (конвейера, выносного пульта и т. д.).
Режим работы с перфолентой служит для ввода и вывода перфоленты с рабочей программой и содержит два подрежима:
9797ввод перфоленты с рабочей программой в ОЗУ；
97
97
4 Заказ № 2408
мтк
ФСУ
БСК
НУ
гассыл ка
Ошибка
МПС
МСР
МУК
ГС
Перфоратор ,
Сервозо лотник
Область УП
Область П
I Пульт
I обучения
Тестовый
режим
Ручной
режим
Отработка
прерывания
BblXOR
ноль
Работа
с П
вывод
УП
Работа
с ПЛ
Чтение,
запись
П
режимов
работы с
таймером
Удаления
УП
с пульта
Обработка
заявки
□т пульта
СУ
ФН
включения
ГС
и выхода
в ноль
ФП во
чения
ГС
НУ
устройств
ППСС
Воспроиэ-
Обучение
ведение
Пульт управления
Настройка
Ввод/ \ I
Признаки
спроизведения или обу
ТаблицаБСК
! (Область I|предна- j I бора
Диспет чер
Таблица Диспетчера
Пульт управ ・ ЛРНИЯ
I/Управление
Индикация! 1
Датчик положения
Рис. 2. Структура программного обеспечения системы
вывод перфоленты с рабочей программой из ОЗУ.
Тестовый режим служит для выполнения различных тестов проверки правильности функционирования отдельных устройств и системы в целом при наладке, контроле в процессе профилактики, поиске причин возникновения ошибок в ходе выполнения программ, а также для автоматической настройки параметров цифровой следящей системы (ЦСС) робота.
В режиме чтения и записи параметров осуществляется работа с системными параметрами, определяющими характеристики системы. Этот режим подразделяется на три подрежима:
поиск параметра по номеру с индикацией значения на пульте управления;
запись нового значения параметра;
переход к чтению следующего по номеру параметра.
В ручном режиме могут быть выполнены следующие операции: начальная установка устройств;
включение или выключение гидростанции;
выход манипулятора в нулевую точку;
удаление рабочей программы из ОЗУ.
Работа всех устройств и исполнение команд осуществляются по сигналу ПРЕРЫВАНИЕ от пульта управления (по нажатию клавиши) и таймера. По сигналу ПРЕРЫВАНИЕ от таймера устройства обмениваются информацией — осуществляется чтение фактического положения звена манипулятора модуля текущей координаты и запись рассчитанного воздействия на модуль управления координатой. При помощи таймера, таким образом, осуществляется привязка 〔к реальному времени, необходимая в режимах обучения и воспроизведения.
Программа «Диспетчер» предназначена для организации работы программного обеспечения в зависимости от приоритетов поступающих заявок, сформированных по сигналу «прерывание»; программа является модулем и может входить в состав программного обеспечения любой агрегатированной системы с ЭВМ типа М-400, СМ-3 и -4, «Электроника-60». Рассматриваемый модуль не зависит от количества и состава внешних устройств. Для обеспечения функционирования диспетчера составляются специальные таблицы, с помощью которых выполняется привязка модуля к реальным внешним устрой^ ствам, порождающим прерывание, в данном случае — к пульту управления и к таймеру.
Программа «Диспетчер» выполняет следующие функции:
в соответствии с таблицей векторов прерываний заполняет вектора прерываний адресами программ обработки заявок;
проводит начальные установки;
анализирует приоритет заявки, сформированной программой обработки прерываний; если приоритет заявки выше текущего приоритета диспетчера, то заявка обрабатывается сразу, если ниже — записывается в очередь;
передает управление программам обработки заявок, адреса которых выбираются из таблицы;
после обработки заявки исключает ее из очереди и выполняет дальнейшую обработку находящихся в буфере заявок.
Для программного обеспечения робота «Колер» приоритет заявки от пульта управления выше приоритета заявки таймера, поэтому сначала обрабатывается заявка от пульта управления.
Правильность конструкции команды, задаваемой с пульта управления, анализирует программа «Блок синтаксического контроля пультовых команд». Она является модулем, независимым от конкретного языка пультовых команд системы управления. Если конструкция команды задана верно, то управление передается управляющим программам режимов, в противном случае индицируется ошибка «неправильная синтаксическая конструкция команды».
Наибольший интерес представляют алгоритмы работы программ режимов обучения (рис. 3) и воспроизведения (рис. 4).
Программы режима обучения служат для формирования рабочей программы в ОЗУ системы управления и для выполнения функцио- нальных команд в процессе обучения. В начальный момент происходит считывание выходного регистра данных пульта управления. Если на регистре имеется код конца рабочей программы, то он записывается до конечному ее адресу, запрещается обработка прерываний от таймера и происходит выход в программу «Диспетчер». В противном случае происходит чтение модуля пассивных сигналов и анализируется поступление функциональной команды. Если она не постудила, то происходит чтение модуля текущей координаты и запоминание значения положения звена. Далее анализируется признак записи в тело рабочей программы точки в абсолютных координатах или в приращениях, происходит собственно запись и выход в «Диспетчер». Если функциональная команда постудила, то определяется ее вид и она отрабатывается путем засылки единицы в соответствующий разряд модуля силовых реле. При разработке формата рабочей программы исходили из условия экономии памяти и было принято во внимание, что в режиме обучения оператор практически никогда не перемещает все координаты манипулятора одновременно. Следовательно, нет необходимости записывать нулевые или близкие к нулю приращения, а достаточно ввести признак отличного от нуля приращения до данной координате в ОЗУ. Использование этого формата дозволило сократить объем памяти, требующийся на запись рабочей программы, в два раза до сравнению с записью всех приращений. Наличие абсолютных координат вызвано необходимостью обеспечения надежности записи и считывания из ОЗУ траектории движения.
Программы режима воспроизведения предназначены для отработки рабочей программы. По прерыванию от таймера происходит чтение рабочей программы до текущему адресу. Если в процессе анализа выясняется, что считанная информация есть код конца программы, то запрещается обработка заявки от таймера и программа передает управление программе «Диспетчер». В противном случае определяется, является ли считанная информация кодом функ- цмональмом команды.
§SK«MMaoasoM «SSK«a nwwadjodu KRUdoJIrv G .OHd§SK«MMaoasoM «SSK«a nwwadjodu KRUdoJIrv G .OHd
§SK«MMaoasoM «SSK«a nwwadjodu KRUdoJIrv G .OHd
§SK«MMaoasoM «SSK«a nwwadjodu KRUdoJIrv G .OHd
Если считанная информация — код функциональной команды, то ее отработка выполняется аналогично отработке функциональной команды в режиме обучения. Если нет, то ио данным рабочей программы формируется управляющее воздействие согласно следующим формулам:
ип =
_ Uin= Vgn + 卩(Vgwi — Vg?J + aen 十?Ven, если Uln < 2023, — ,2023, если Uin^ 1023,
Уgn == Sn gn-L &n gn-1 ' Фп? V% ^3 En — ^n-l>
где Un ——управляющее воздействие, рассчитываемое после a~fo прерывания таймера; gn,(рп — заданное и фактическое значение положения координаты в момент тг-го прерывания таймера;卩—коэффициент компенсатора; а, у — коэффициент при пропорциональной и при дифференциальной составляющей регулятора соответственно.
Параметры корректирующих звеньев цифровой следящей систе- мы определяются при помощи программы автоматической настройки в тестовом режиме. После расчета значения управляющего воздействия выполняется запись его значения в соответствующий модуль управления координатой при очередном прерывании от таймера. Объем программного обеспечения составляет 6К слов.
ЛИТЕРАТУРА
Белянин П. Я. Промышленные роботы и их применение. М.: Машиностроение, 1983. 312 с.
УДК 007.52
СИСТЕМА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТИЗИРОВАННОГО
ТЕХНОЛОГИЧЕСКОГО КОМПЛЕКСА
В. А. Павлов
В настоящее время задача роботизации производства приобрела особую актуальность. Наибольшая эффективность от внедрения промышленных роботов достигается в тех случаях, когда они используются в составе роботизированных технологических комплексов (РТК). Таким РТК может быть технологическая линия, участок или цех, оснащенный автоматизированными технологическими агрегатами, в том числе промышленными роботами, и автоматизированной транспортно-складской системой.
Организован РТК может быть из автономно функционирующих единиц оборудования, т. е. каждый технологический агрегат управ- ляется от местного управляющего устройства. В этом случае в составе РТК отсутствует центральное управляющее устройство, выполняющее диспетчерские функции, а для обеспечения согласо-
Рис. 1. Структурная схема системы программного обеспечения автоматизированной системы управленияШтриховые линии — передача данных； сплошные — передача управления от модуля к модулюванной работы технологических агрегатов местные управляющие устройства обмениваются между собой необходимыми сигналами. При этом необходимость обеспечения жесткой временной синхронизации приводит к значительному увеличению периода наладки РТК и снижению надежности его работы.Другой вариант организации РТК предусматривает включение в его состав центральной управляющей ЭВМ, на которую возлагаются функции диспетчеризации работы оборудования и расчета сменно-суточных заданий для каждого технологического агрегаРис. 1. Структурная схема системы программного обеспечения автоматизированной системы управленияШтриховые линии — передача данных； сплошные — передача управления от модуля к модулюванной работы технологических агрегатов местные управляющие устройства обмениваются между собой необходимыми сигналами. При этом необходимость обеспечения жесткой временной синхронизации приводит к значительному увеличению периода наладки РТК и снижению надежности его работы.Другой вариант организации РТК предусматривает включение в его состав центральной управляющей ЭВМ, на которую возлагаются функции диспетчеризации работы оборудования и расчета сменно-суточных заданий для каждого технологического агрегата. В соответствии с этим программное обеспечение управляющей ЭВМ в системе программного обеспечения автоматизированной системы управления РТК состоит из двух основных подсистем планирования и оперативного управления. Они функционируют независимо друг от друга, что позволяет в случае необходимости использота. В соответствии с этим программное обеспечение управляющей ЭВМ в системе программного обеспечения автоматизированной системы управления РТК состоит из двух основных подсистем планирования и оперативного управления. Они функционируют независимо друг от друга, что позволяет в случае необходимости использо
Рис. 1. Структурная схема системы программного обеспечения автоматизированной системы управления
Штриховые линии — передача данных； сплошные — передача управления от модуля к модулю
ванной работы технологических агрегатов местные управляющие устройства обмениваются между собой необходимыми сигналами. При этом необходимость обеспечения жесткой временной синхронизации приводит к значительному увеличению периода наладки РТК и снижению надежности его работы.
Другой вариант организации РТК предусматривает включение в его состав центральной управляющей ЭВМ, на которую возлагаются функции диспетчеризации работы оборудования и расчета сменно-суточных заданий для каждого технологического агрега
Рис. 1. Структурная схема системы программного обеспечения автоматизированной системы управления
Штриховые линии — передача данных； сплошные — передача управления от модуля к модулю
ванной работы технологических агрегатов местные управляющие устройства обмениваются между собой необходимыми сигналами. При этом необходимость обеспечения жесткой временной синхронизации приводит к значительному увеличению периода наладки РТК и снижению надежности его работы.
Другой вариант организации РТК предусматривает включение в его состав центральной управляющей ЭВМ, на которую возлагаются функции диспетчеризации работы оборудования и расчета сменно-суточных заданий для каждого технологического агрега
та. В соответствии с этим программное обеспечение управляющей ЭВМ в системе программного обеспечения автоматизированной системы управления РТК состоит из двух основных подсистем планирования и оперативного управления. Они функционируют независимо друг от друга, что позволяет в случае необходимости использо
та. В соответствии с этим программное обеспечение управляющей ЭВМ в системе программного обеспечения автоматизированной системы управления РТК состоит из двух основных подсистем планирования и оперативного управления. Они функционируют независимо друг от друга, что позволяет в случае необходимости использо
вать только одну из них.
Разработанная система программного обеспечения автоматизированной системы управления РТК функционирует в рамках дисковых операционных систем реального времени управляющих ЭВМ АСВТ М-6000 и СМ-4. При этом программные модули, образующие подсистему управления, определены как диск-резидентные программы реального времени, а программные модули подсистемы планирования определены как фоновые диск-резидентные программы с меньшим приоритетом. Структурная схема системы программного обеспечения автоматизированной системы управления РТК приведена на рис. 1. •
Исходными данными для подсистемы планирования являются: сведения о технологических агрегатах, работающих в составе РТК в планируемом месяце; время выполнения f-й технологической операции на 2-м технологическом агрегате (для всех операций и всех агрегатов); время передачи контейнера с заготовками из автоматизированной транспортно-складской системы на f-й технологический агрегат; время переналадки iro технологического агрегата /-й на /r-ую технологическую операцию; месячный фонд времени работы
Z-ro технологического агрегата; график распределения месячного фонда времени по сменам; месячный план поставок участка. Все эти данные сгруппированы в четырех дисковых файлах: файл сведений об оборудовании РТК (PROV); файл технологической информации (ТЕХМ); файл нормативов времени (NORM); файл производственной программы (PROG).
Подсистема планирования (программа PLAN) ставится на выполнение оператором. РТК в конце каждого месяца. Программа обеспечивает распределение плана по доставкам на следующий месяц между технологическими агрегатами РТК и определение последовательности запуска деталей на каждом технологическом агрегате исходя из критерия оптимизации загрузки оборудования. При этом предполагается, что все технологические агрегаты работают независимо друг от друга, а связь между ними до обрабатываемым деталям в случае необходимости осуществляется через автоматизированную транспортно-складскую систему, т. е. заготовки на каждый технологический агрегат поступают через нее со склада, а продукт, полученный после обработки заготовки на данном агрегате, досылается обратно на склад.
В результате работы подсистемы планирования формируются стандарт-план работы РТК на планируемый месяц и сменно-суточные задания для всех технологических агрегатов РТК, выводимые на печать для оператора РТК и всех заинтересованных служб цеха. Сменно-суточные задания для всех технологических агрегатов записываются в файл TASK, хранящийся во внешней памяти на магнитных дисках и содержащий всю необходимую исходную информацию для работы подсистемы оперативного управления.
Подсистема оперативного управления состоит из программ управления технологическими агрегатами (число программ равно числу технологических агрегатов РТК) —TOOL1+TOOLN，программы управления автоматизированной транспортно-складской системы STORE, программы учета состояния склада — STATE и программы обработки сменно-суточного задания — PROCS. Для запуска этой подсистемы оператор РТК в начале каждой смены ставит на выполнение программу обработки сменно-суточного задания. Дальнейшая работа подсистемы осуществляется автоматически и в случае отсутствия сбойных ситуаций не требует вмешательства оператора.
Программа PROCS проверяет наличие на складе заготовок, комплектующих изделий, инструмента и пустой тары, необходимых для выполнения сменпо-суточного задания для каждого технологического агрегата, и ставит на выполнение соответствующую программу TOOLi. В процессе своей работы программа PROCS использует программу STATE, обеспечивающую формирование моделей материального и инструментального складов и работу с ними в соответствии с ведомостями поступления и отгрузки, которые вводятся в ЭВМ оператором РТК. По запросам от программ PROCS и STORE программа STATE осуществляет поиск в моделях складов запрошенных объектов и выдает в качестве ответа номер соответствующей ячейки склада.
Программы управления технологическими агрегатами TOOLi обеспечивают выполнение соответствующими технологическими агрегатами сменпо-с^^точных заданий. Для этого каждая программа TOOLi управляет (посредством обращений к программе STORE) своевременным подвозом к соответствующему технологическому агрегату пустой тары, заготовок и инструмента и передачей от технологического агрегата на склад готовых изделий, осуществляет выдачу из внешней памяти ЭВМ на агрегат технологической программы обрабатываемой детали, а также сигналов запуска этой технологической программы. Предполагается, что каждый технологический агрегат имеет свое местное управляющее устройство. При наличии у него своего блока памяти технологическая программа целиком переписывается из внешней памяти ЭВМ в этот блок. В противном случае из ЭВМ осуществляется покадровая выдача технологической программы (т. е. последовательная выдача команд управления) на приемный регистр местного управляющего устройства. В ЭВМ от технологического агрегата в первом случае поступает сигнал КО- НЕЦ ОПЕРАЦИИ, во втором 一 КОНЕЦ ОТРАБОТКИ КАДРА. Эти сигналы подаются в ЭВМ через систему прерываний и вызывают активизацию программы управления соответствующим технологическим агрегатом. Кроме того, от каждого работоспособного агрегата в ЭВМ поступает сигнал ГОТОВНОСТЬ. Пропадание его свидетельствует о выходе агрегата из строя, что позволяет ЭВМ вовремя среагировать на это событие.
Система программного обеспечения автоматизированпой системы управления РТК до требованию оператора РТК осуществляет распечатку сводок о выполнении сменно-суточного задания каждым технологическим агрегатом, сводки о выполнении плана поставок в целом до участку, сличительных ведомостей для материального и инструментального складов и других документов, необходимых для отчетности и контроля за работой РТК.
Как уже упоминалось, обе подсистемы системы программного обеспечения автоматизированной системы ^шравления РТК могут функционировать независимо друг от друга. Кроме того, для подсистемы управления разработан вариант с собственной операционной системой — алгоритмическая система управления роботами, названная «Барс». Она обеспечивает в ЭВМ режим разделения вре- мени, при котором в качестве пользователей ЭВМ выступают технологические агрегаты, промышленные роботы и человек-оператор. Система предусматривает, кроме выдачи технологических программ на технологические агрегаты, управление движением промышленных роботов, оснащенных датчиками очувствления. Она состоит из двух основных частей (рис. 2) — системного программного обеспечения и прикладного программного обеспечения. Системное программное обеспечение предназначено для организации вычислительных процессов в управляющей ЭВМ, а прикладное программное обеспечение 一 для реализации алгоритмов управления очувствленными роботами и технологическими агрегатами.
Системное программное обеспечение в свою очередь делится
Алгоритмическая система управления роботами
Рис. 2. Структура алгоритмической системы управления роботами «Варе»
на две части: «Диспетчер» и служебные программы. «Диспетчер» представляет собой совокупность программных модулей, отвечающих за управление функционированием системы. К служебным относятся программы, обеспечивающие контроль работоспособности системы, связь с библиотекой стандартных доддрбграмм и другие вспомогательные функции.
Прикладное программное обеспечение подразделяется на три группы программ в соответствии с тремя основными подсистемами промышленных роботов: программы управления исполнительными устройствами, программы обработки сенсорной информации и программы связи с человеком-оператором. Программы управления исполнительными устройствами обеспечивают расчет и выдачу управляющих воздействий на приводы роботов и выдачу технологических программ на агрегаты. Программы второй группы осуществляют обработку информации, поступающей с устройств очувствления роботов и технологических агрегатов. В настоящее время у роботов используются ультразвуковые, фотоэлектрические и тактильные датчики. В группу программ связи с оператором включены программы, обеспечивающие диалог оператора РТК с управляющей ЭВМ и транслятор с проблемно-ориентированного языка РОКОЛ, на котором осуществляется программирование действий роботов.
Все программные модули системы «Барс» можно разбить па информирующие и информируемые, т. е. на модули, являющиеся соответственно источником и приемником информации. Для обеспечения максимальной независимости модулей и обеспечения бесперебойной работы информируемых модулей обмен информацией между ними осуществляется не непосредственно, а через буферные массивы, организованные по циклическому принципу. Во время обработки информируемым модулем одной записи информирующий модуль в режиме разделения времени может заполнять буфер новыми записями. подготавливая тем самым данные для следующего цикла работы информируемого модуля. Такая организация информационной связи между программными модулями целесообразна при 友＜7?, где 厶 и 力2 ——время цикла работы информирующего п информируемого модуля.
Различные внешние факторы, такие, как ввод команды оператором РТК, срабатывание одного из датчиков очувствления, поступление сигнала от технологического агрегата и т. п., вызывают поступ-
ление сигнала прерывания в ЭВМ и инициируют выдачу заявок на активизацию определенных программных модулей системы. Так как одновременно могут быть поданы заявки на активизацию нескольких модулей, то для выбора наиболее важного из них в данный момент времени введена система приоритетов. Каждому модулю системы присвоен приоритет в соответствии с важностью выполняемой им функции и необходимостью быстрой реакции в ответ на заявку относительно активизации данного модуля. Используется система абсолютных приоритетов с дообслуживанием.
Для реализации процесса передачи управления модулям используются управляющие массивы: управляющие шкалы, управляющие слова и информационные поля модулей. Управляющие шкалы служат для фиксации модулей, претендующих на процессорное время. Каждому модулю соответствует определенный разряд в каждой из шкал (в соответствии с приоритетом). Если он находится в единичном состоянии, то модуль претендует на процессорное время (открыт) по этой шкале. Управление передается модулю, имеющему наивысший приоритет из числа модулей, открытых по всем шкалам, В системе «Барс» введено три шкалы: шкала заданий фиксирует наличие информации для работы модулей; шкала невыполненных заданий служит для организации работы с буферами ограниченной длины, т. е. для предотвращения случаев переполнения буферов; в шкалу выжиданий заносится информация об ожидании программными модулями системы данных, запрошенных у других модулей.
Управляющие слова содержат приоритетные номера модулей и адреса их информационных полей. Для ускорения поиска нужного отравляющего слова таблица этих слов организована до принципу прямого доступа. Ключом при обращении к ней служит приоритетный номер модуля, которому передается управление.
Наконец, в информационном поле модуля содержатся данные, необходимые для возобновления его функционирования после прерывания и для настройки модуля в начальное состояние.
Рассмотрим теперь кратко процесс программирования действии роботов. Проблемно-ориентированный язык РОКОЛ построен по типу языка ассемблера ЭВМ. Основные операторы языка РОКОЛ служат для описания логики программ функционирования роботов. Имеются основные операторы трех типов. Операторы первого типа являются «расширенными» машинными командами, позволяющими осуществлять арифметические и логические операции над массивами данных и ветвления внутри программы. Основные операторы второго типа реализуют выполнение элементарных действий робота (откры вание и закрывание с хвата, перемещение в пространстве в заданном направлении, перемещение между двумя заданными точками и т. п.). Основные операторы третьего типа обеспечивают взаимодействие системы с сенсорной подсистемой робота, с человеком-оператором и выдачу команд управления на технологические агрегаты.
В языке РОКОЛ имеются еще две группы специальных операторов (операторы редактирования и управляющие операторы), которые непосредственно не используются при написании программ функцио-
нирования роботов. Операторы редактирования позволяют вносить корректировки в программы функционирования роботов, хранящиеся в памяти ЭВМ, и управляют режимами трансляции вводимых программ. Управляющие операторы служат для задания режимов работы роботов и ЭВМ, а также для оперативного вмешательства оператора РТК в ход выполнения роботом заданной программы.
Основным смысловым элементом языка РОКОЛ является директива, представляющая собой последовательность основных операторов и задающая роботу выполнение определенного действия. Каждый основной оператор характеризуется параметрами, которые заносятся при вводе директивы в его информационное поле. В значительной степени занесение информации в информационное поле облегчает диалоговый режим программирования. Для удобства оператора вводится сокращенный диалоговый режим, позволяющий опытному оператору экономить время. При вводе в ЭВМ каждый оператор, входящий в директиву, автоматически помечается числовой меткой. Метки используются для ветвления программы в операциях перехода и при редактировании программ. Каждая директива, вводимая впервые в ЭВМ, помечается определенной последовательностью символов —именем. Все последующие вызовы данной директивы на исполнение осуществляются посредством этого имени. Кроме того, имя директивы представляет собой макрооператор, используя который, можно вставлять данную последовательность основных операторов в любое место других директив.
Введена возможность представления адресов в символьной форме и использования литералов для ввода констант. При вводе операторов языка РОКОЛ осуществляется автоматический контроль правильности формата вводимого оператора. В случае обнаружения ошибки печатается диагностическое сообщение и человеку-оператору предоставляется возможность повторить ввод. Аналогичный контроль осуществляется при поиске в директиве указанной метки и при поиске в библиотеке директивы с заданным именем. Кроме автоматического обнаружения ошибок, человек-оператор имеет возможность исправлять вводимые конструкции языка РОКОЛ с помощью символа аннулирования.
Система программного обеспечения автоматизированной системы управления РТК реализована на управляющих ЭВМ АСВТ М-6000 (или управляющих ЭВМ со сходной архитектурой АСВТ М-7000, СМ-2) и СМ-4. Программные модули написаны на языке ФОРТРАН и на языке Ассемблера. Подсистема оперативного управления, реализованная на микро-ЭВМ «Электроника-60», используется уже в течение нескольких лет для управления интегральным роботом ЛПИ-2М и другими очувствленными роботами,
q СИСТЕМНОЕ
О ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ
УДК 681.142.2
СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ЗАДАЧ РОБОТОТЕХНИКИ
А. К. Платонов, Ю. М. Лазутин, В. С. Ярошевский
В Институте прикладной математики им. М. В. Келдыша АН СССР разработано системное программное обеспечение инструментального вычислительного комплекса на базе мини-ЭВМ М-6000, используемого для создания и отработки алгоритмов управления различными робототехническими устройствами [ 1 ]. Комплекс позволяет готовить программы и для микро-ЭВМ «Электроника-60». В его состав входят мини-ЭВМ М-6000 и подключенные к ней каналами связи мини-ЭВМ М-7000 и микро-ЭВМ «Электроника-60» (рис. 1). Центральной машиной комплекса является М-6000. К ней подключены магнитные диски и лабораторные макеты робототехнических устройств. Когда ресурсов М-6000 не хватает, дополнительные вычислительные мощности предоставляет М-7000. Подсистема М-6000 — «Электроника-60» служит для подготовки и отладки программ для микро-ЭВМ « Электроника-60».
Специфика использования инструментального комплекса заключается в непрерывной модификации и отладке алгоритмов управления различными робототехническими устройствами и реализующих алгоритмы программ. В каждый момент времени на комплексе решается только одна задача. Это связано с тем, что управление в реальном масштабе времени робототехническими устройствами предъявляет довольно высокие требования к вычислительной машине и ресурсов данного комплекса недостаточно для организации мультипрограммирования. Недостаток вычислительных мощностей препятствует также созданию универсальных средств, облегчающих организацию работы программы в реальном масштабе времени. Для каждого макета робототехнического устройства, как правило, создается свой вариант таких средств, хорошо <<подогнанный» к данной задаче, и поэтому на этапе исполнения программы не тре» буются какие-либо универсальные системные услуги.
В процессе отладки этап подготовки программы и этап исполнения ее в реальном масштабе времени циклически сменяют друг друга. Типичный цикл отладки изображен на рис. 2. Стандартное системное программное обеспечения мини-ЭВМ М-6000 не приспособлено к такому режиму использования ЭВМ, что значительно снижало эффективность работы инструментального комплекса. В связи с этим возникла настоятельная потребность в разработке
НО
Рис. 1. Структурная схема инструментального вычислительного комплекса НМД — накопитель на магнитном диске
Рис. 2. Структурная схема типичного цикла отладки программы
Шириной стрелок показана относительная частота прохождения ветвей цикла
системного программного обеспечения, специально рассчитанного на режим отладки.
В качестве базы была использована стандартная дисковая операционная система М-6000. В ходе разработки были значительно улучшены уже имевшиеся в этой операционной системе средства (путем замены соответствующих программ) и создан ряд новых. В настоящее время в неизменном виде остались только трансляторы с ФОРТРАНА и с языка Ассемблера. Основной целью всех изменений и добавлений было сокращение времени, необходимого для преобразования алгоритма в отлаженную программу. Для достижения этого используются два метода:
увеличение числа проходов цикла отладки (от модификации текста программы до получения загрузочного модуля), выполняемых за то же астрономическое время, за счет увеличения быстродействия всех системных программ и упрощения интерфейса между ними и пользователем;
повышение качества каждого прохода путем предоставления более мощных гибких программных средств.
В объеме статьи невозможно подробно описать все системное программное обеспечение, функционирующее на инструментальном комплексе. Данная публикация носит обзорный характер. Рассмотрим те компоненты и те характеристики системного программного обеспечения, которые, как показала практика, являются ключевыми для эффективной отладки программ (язык программирования, сред-
ства для изменения программ, уровень диалога пользователя с ЭВМ, быстродействие всех средств системного программного обеспечения), а также основные характеристики созданной в Институте прикладной математики им. М. В. Келдыша АН СССР дисковой операционной системы для мини-ЭВМ М-6000 и систему программирования микро-ЭВМ «Электроника-60».
ДИСКОВАЯ ОПЕРАЦИОННАЯ СИСТЕМА ДЛЯ МИНИ-ЭВМ М-6000
Как было отмечено выше, разработка описываемого здесь системного программного обеспечения базировалась на стандартной дисковой операционной системе М-6000. В процессе разработки была полностью заменена судервизорная часть этой операционной системы и большинство обрабатывающих программ («Редактор», ^Компоновщик» и т. д.). Кроме того, были изменены некоторые принципы построения дисковой операционной системы. Была упрощена файловая система. Теперь все программы — и системные, и пользовательские —хранятся в одной и той же области диска. Какая-либо защита системных программ отсутствует, пользовательские программы имеют свободный доступ ко всему диску. Не используется аппарат защиты памяти ЭВМ М-6000, все программы работают в режиме супервизора. Это существенно упрощает написание программ, работающих с макетами робототехнических устройств. Операции ввода—вывода со стандартными внешними устройствами (операторский терминал, магнитный диск, перфолента, печатающее устройство) выполняются не до прерываниям, а по опросам готовности. Отказ от прерываний дозволил значительно упростить супервизор- ную часть операционной системы и сделал ее независимой от -тех операций с системой прерываний, которые выполняют пользовательские программы при работе с лабораторными макетами робототехнических устройств (облегчилось также написание таких программ).
Результатом всех этих доработок и изменений явилось создание новой дисковой операционной системы, существенно превосходящей до своим параметрам стандартную дисковую операционную систему М-6000 (рис. 3).
Отметим основные отличительные характеристики созданной
дос：
Компактность. Резидентная часть операционной системы занимает в памяти 2К слов. Резидентная программа выполняет операции ввода—вывода с основными устройствами — операторским терминалом и НМД ——и, кроме того, операции с файлами, а также организует загрузку нерезидентных частей дисковой операционной системы. Если услуги, предоставляемые нерезидентными частями системы, программе пользователя не нужны, она может занимать всю незанятую резидентной программой память.
Надежность хранения информации на диске. Эта характеристика имеет очень большое значение. Все остальные достоинства дисковой операционной системы теряют какой-либо смысл для пользователя,
если он слишком часто обнаруживает, что нужная ему информация потеряна. Исходя из опыта работы со стандартной дисковой операционной системой, разработчики описываемого системного программного обеспечения пришли к выводу, что основной целью должно быть надежное выявление появляющихся в случайные моменты времени одиночных сбоев. При этом не следует полностью доверять диагностическим возможностям аппаратуры, необходимо как можно йшре (но не
в ущерб производительности системы) применять программный
рационной системы миии-ЭВМ М-6000рационной системы миии-ЭВМ М-6000контроль. Поскольку стопро
рационной системы миии-ЭВМ М-6000
рационной системы миии-ЭВМ М-6000
центное выявление сбоев недостижимо, целесообразно таким образом организовать работу с магнитным диском, чтобы снизить вероятность возникновения сбоев.
Драйвер диска новой дисковой операционной системы программным образом контролирует правильность выборки цилиндра (в последний сектор каждого цилиндра записан его номер) и соблюдение некоторых временных соотношений, которые должны выполняться во время операций чтения-записи. Эти меры позволили существенно понизить вероятность того, что сбой аппаратуры пройдет неза
меченным.
Для уменьшения вероятности возникновения сбоев в описываемой дисковой операционной системе принята специальная дисциплина работы с файлами, отличающаяся тем, что перемещение на диске какого-либо файла происходит только при его модификации или по прямому указанию пользователя. Автоматическая операция «упаковка диска» отсутствует. Освобождающиеся (при удалении файлов или их модификаций) области специальным образом домечаются, соседние свободные области сливаются. Модифицированный файл всегда записывается в ближайшую по размерам свободную область диска. Если при э гом она занимается не полностью, остаток регистрируется в каталоге как новая свободная область. Поскольку файлы, хранящиеся на диске инструментального комплекса, имеют самые разнообразные размеры, такая организация работы с файлами не приводит к чрезмерному накоплению маленьких «дыр». Тем не менее возможны ситуации, когда свободное пространство есть, но необходимо завести файл, который ни в одну из «дыр» не влезает. Для таких случаев используется программа полуавтоматической упаковки диска. Эта программа переписывает файлы ио °ДНО~ му из конца области, занимаемой файловой системой, в начало: на перепись каждого файла запрашивается разрешение пользователя.
Наиболее ответственным элементом файловой системы является каталог. Перед каждым изменением каталога диска в рассматриваемой дисковой операционной системе выполняется копирование каталога в специально отведенную область диска (не в файл).
Совокупность этих мер позволила значительно повысить (по сравнению со стандартной дисковой операционной системой) надежность хранения информации на диске. В тех же случаях, когда файловая система все-таки повреждается, с помощью специальных программ удается, как правило, спасти самую ценную ипформа- п,ию — тексты программ.
Гибкая система ввода—вывода. Программа выполняет операции ввода-вывода с логическими устройствами, к которым специаль ной директивой «подключаются» реальные физические устройства. К одному логическому устройству можно подключить несколько физических, т. е. можно, например, выдавать данные параллельно па экран операторского терминала и на одно или несколько печатающих устройств. В качестве физического устройства может выступать произвольный текстовый файл. С такого псевдоустройства могут вводиться и команды оператора, и тексты программ. Драйвер псевдоустройства содержит также средства для условной обработки текста.
Директива, подключающая физические устройства к логическим, может быть введена в любой момент, а не только в тот, когда в памяти находится монитор команд оператора.
Высокая производительность. По этому параметру описываемая дисковая операционная система обладает существенно более высокими характеристиками, чем стандартная. Это обеспечивается высоким быстродействием всех системных программ и прежде всего резидентной программы. Быстродействие ее обусловлено тщательной организацией операций ввода—вывода и раи;иональным распределением функций между системными программами (как можно меньше перезагрузок программ на стандартных режимах работы). В результате этих мер время трансляции программ, написанных на языке Ассемблера или на ФОРТРАНе, в разработанной дисковой операционной системе уменьшилось примерно в полтора раза по сравнению со стандартной.
Простота модификаций. Все системные программы, в том числе и резидентная, хранятся на магнитном диске в виде обычных файлов с фиксированными именами. Поэтому любое изменение системных программ осуществляется так же, как и изменение программ пользователя,— редактирование текста, трансляция, компоновка.
ЯЗЫК ПРОГРАММИРОВАНИЯ
Язык Ассемблера и ФОРТРАН, трансляторы для которых имеются на мини-ЭВМ типа М-6000, не совсем подходят на роль языков программирования робототехнических задач, решаемых на инструментальном комплексе. Язык Ассемблера плох при отработке алгоритмов, поскольку из-за невысокого уровня языковых средств написание программы и ее модификации отнимает довольно много
времени, но позволяет добиться максимальной эффективности. На ФОРТРАНе трудно писать логические программы, так как он ориентирован на счетные задачи. Он не приспособлен к структурному программированию, поэтому затрудняются отладка и модификация программы. Кроме того, существующий транслятор выдает недостаточно эффективные программы. Тем не менее долгое время ФОРТРАН был основным языком программирования на инструментальном комплексе. На ФОРТРАНе писались как робототехнические, так и чисто системные программы (редактор текстов, например, практически полностью написан на ФОРТРАНе).
С течением времени в коллективе пользователей, работающих на инструментальном комплексе, сформировались определенные взгляды на те требования, которым должен отвечать язык программирования, предназначенный для решения робототехнических задач. Некоторое влияние на эти взгляды оказало знакомство с рядом новых языков, появившихся в последнее десятилетие： PASCAL, ADA, С, EDISON. Вкратце эти требования можно сформулировать следующим образом: язык программирования робототехнических задач должен быть удобен для записи алгоритмов робототехники (для которых характерна прежде всего сложная и разветвленная логика) и должен обеспечивать разумное и динамическое сочетание уровня языка и его эффективности. Реализовав и отладив алгоритм на языке высокого уровня, пользователь должен иметь возможность пожертвовать в каком-то узком месте программы уровнем языка и добиться максимальной эффективности, Наличие каких- либо средств для оптимизации результирующей программы не обязательно, однако транслятор должен быть тщательно «подогнан» к системе команд конкретной машины, особенно в части логических операций и операций манипулирования битами. Транслятор с языка должен быть достаточно быстродействующим (по крайней мере не уступать в этом отношении транслятору с ФОРТРАНа).
С учетом этих требований в Институте прикладной математики им. М. В. Келдыша АН СССР разработан язык программирования МЭЛ. Рассмотрим только самые общие его свойства. Язык МЭЛ — это ориентированный на структурное программирование язык высокого уровня, допускающий вставки на языке Ассемблера. Имеются два типа данных — простая переменная и массив. В них могут- храниться целые и вещественные числа, восьмеричные константы〉 буквенно-цифровые символы и адреса. Данные могут быть локальными в подпрограмме, локальными в модуле (группе подпрограмм), глобальными, базированными. Размещение базированных данных в памяти ЭВМ определяется значением базы ——какой-либо переменной или константы. Элементарными операциями языка являются арифметические и логические операции, сдвиги, операции с адресами (определение адреса переменной или элемента массива, косвенная адресация). Число исполнительных операторов минимально: присвоение, вызов подпрограммы, циклы, безусловная передача управления и условный оператор. Во всех языковых конструкциях любая переменная может быГь заменена произвольным
MD .SORT.
DCEM SORT ■
DCER SORTO
DC D
' SR SORT(A(1),N)
D=N
RU D=(D+1)/2 SORTO(A,N)
EP(冲)
EN
' SR SORTO(B(1),M)
DC 工，J,W
RU J=O 1=1
RU IF(B(I)> B(I+D)) W=E(工)В(工)=B(工+D) В(工+D)=W
1=1 + 1
EP(M<=M) EP(J#O) EN
ED
$
Рис. 4. Пример программы, написанной на языке МЭЛ
выражением. Основные преимущества языка МЭЛ заключаются в гибких средствах управления данными, в богатом наборе логических операций и операций манипулирования битами, в свободном употреблении выражений и в эффективных средствах управления последовательностью выполнения операций. В ассемблерных вставках могут использоваться объекты (переменные, метки), определенные в языковой части программы. Пример программы, написанной на языке МЭЛ, приведен на рис. 4.
Транслятор с языка МЭЛ реализован на М-6000 в двух версиях: одна версия готовит объектные модули для мини-ЭВМ М-6000, другая — для микро-ЭВМ «Электроника-60» (ассемблерная часть в каждой версии, естественно, своя). Сам транслятор также написан на языке МЭЛ.
Опыт эксплуатации языка МЭЛ показал, кто он лучше, чем ФОРТРАН, подходит для решения задач робототехники, а также задач системного программирования.
СРЕДСТВА ДЛЯ ИЗМЕНЕНИЯ ПРОГРАММ
Отличительным свойством программ, разрабатываемых и отлаживаемых на инструментальном комплексе, является их чрезвычайная изменчивость. Поэтому качество средств системного программного обеспечения, предназначенных для изменения программ, оказывает решающее влияние на эффективность работы -инструментального комплекса. В подавляющем большинстве случаев изменение программы осуществляется на уровне текста. В разработанном системном программном обеспечении имеются два средства для изменения текста программы — редактор текста и система условной обработки текста, встроенная в драйвер псевдоустройства (в роли которого, 116
как было отмечено выше, может выступать любой текстовый файл;.
Набор команд редактора текстов практически идентичен набору команд редактора текстов системы ДИМОН на ЭВМ БЭСМ-6 [2] и имеет следующие основные возможности:
нумерация строк с любым заданным положительным тагом, сохранение нумераций между сеансами редактирования (по желанию);
просмотр файла целиком и до частям (в заданном диапазоне номеров) ,удаление, включение, замена строк по номерам;
произвольный доступ к строкам (на последовательность номеров редактируемых строк не накладывается никаких ограничений);
поиск и распечатка строк, содержащих заданную цепочку символов (поиск до образцу);
поиск строк, содержащих заданную цепочку символов С1, и замена в этих строках С1 на другую заданную цепочку символов С2;
слияние файлов (включение в любое место редактируемого файла любой части любого символьного файла).
Программа «Редактор» работает в диалоговом режиме, команды исполняются немедленно. Результирующей версии файла можно присвоить новое имя, можно оставить старое, однако исходная версия файла всегда сохраняется в неизменном виде до конца редактирования (все изменения записываются в специально для них отведенную область). Имеются средства для использования возможностей операторского терминала по редактированию текста прямо на экране.
Система условной обработки текста управляется содержащимися в тексте командами условной «трансляции», которые выделяются и исполняются драйвером псевдоустройства. Имеются команды, аналогичные командам AIF, ANOP, AGO, SETC йакрогенератора. Значения параметров, фигурирующих в командах условной «трансляции», могут задаваться не только в команде SETC, ио и в команде дисковой операционной системы, объявляющей текстовый файл псевдоустройством и инициирующей ввод с него. Указывая в данной команде различные значения параметров, можно получать существенно отличающиеся версии программы. Однако получение этих версий должно быть заранее запрограммировано с помощью команд условной «трансляции». Средства условной трансляции применяются в основном для генерации различных версий системных программ. С помощью параметров задаются адреса внешних устройств, тип процессора, типы интерфейсных блоков и т. д. Поскольку драйвер дсевдоустройства никак не связан с каким-либо конкретным транслятором, условная обработка текста может использоваться для формирования программ па любом языке программирования.
УРОВЕНЬ ДИАЛОГА ПОЛЬЗОВАТЕЛЯ С ЭВМ
Уровень диалога пользователя с ЭВМ понимается здесь следующим образом: чем меньше команд доля?ен ввести пользователь в машину, чтобы получить требуемый результат, и чем проще и понятнее от-
веты системного программного обеспечения, тем выше уровень диалога. Команды разработанного системного программного обеспечения емки и лаконичны. В них нет излишней общности, они рассчитаны на наиболее часто встречающийся режим работы. Как правило, вся информация, необходимая какой-либо системной программе для работы, может быть задана непосредственно в команде, запускающей данную программу на исполнение (имя исходного файла, имя конечного файла и т. д.). Кроме того, весь диалог пользователя с системным программным обеспечением можно запрограммировать, поместив в текстовый файл все необходимые для диалога команды и объявив его псевдоустройством. В этом случае одной командой запускается деятельность любой сложности. Вмешательство пользователя требуется только в тех случаях, когда возникает какая-либо непредвиденная или конфликтная ситуация (нет требуемого файла или, наоборот, создаваемый файл уже есть и т. д.). В этих случаях программа, обнаружившая такую ситуацию, обращается за помощью к пользователю. Программирование диалога повышает и общую производительность системы, поскольку из диалога исключается человек — звено наименьшего быстродействия. Снижается также вероятность ошибки (неправильное задание имени файла и т. д.).
В настоящее время непременной компонентой системного программного обеспечения, претендующего на высокий уровень диалога пользователя с ЭВМ, является программное обеспечение машинной графики. В системное программное обеспечение инструментального комплекса входит программный комплекс ГРАФОР-М, ориентированный на построение графиков [3]. Рисуя график в заданной программистом прямоугольной области, программы комплекса автоматически масштабируют значения переменных, помечают заданные точки кривой специальными маркерами, проводят и размечают координатные оси> Изображение может также содержать различные геометрические фигуры, строки буквенно-цифровых символов. Существуют две версии комплекса: для графопостроителя и для графического дисплея СИГ ДА [4]. Последняя версия содержит средства для 'программирования диалоговых устройств — светового пера и клавиатуры дисплея.
БЫСТРОДЕЙСТВИЕ СИСТЕМНЫХ ПРОГРАММ
Быстродействие всех системных программ имеет очень большое значение для эффективности отладки программ пользователем, поскольку непосредственно влияет на продолжительность типичного цикла отладки и, следовательно, на число таких циклов,- выполняемых за то же астрономическое время. Кроме того, здесь есть и психологические аспекты. Если какое-либо удобное средство реализуется программой, выполняющейся слишком медленно, пользователь будет стараться применять его как можно реже. Поэтому при создании всех программ рассматриваемого системного программного обеспечения вопросам повышения быстродействия программ уделялось особое внимание. Как показывает практика, основным замедляю- 118
щим фактором в системных программах являются обмены с магнитным диском. На минимизацию числа обменов и были направлены основные усилия разработчиков. Например, программа «Компоновщик» (одна из самых медленных) значительную часть времени тратила на просмотр библиотеки стандартных подпрограмм. Введение специального каталога библиотеки позволило значительно сократить время работы программы «Компоновщик». Другим примером является сегментация программы — разбиение ее на поочередно загружаемые с диска сегменты. Такой прием дает существенную экономию оперативной памяти, однако может столь же существенно увеличить время выполнения программы. В тех случаях, когда оперативной памяти хватает (а она в настоящее время не самый дефицитный ресурс), желательно избегать сегментирования программы. Разработанный транслятор для языка МЭЛ состоит из одного сегмента. Более того, он однопроходный, т. е. просматривает исходный текст программы всего один раз (за счет более активного использования имеющейся оперативной памяти и некоторого увеличения пространства на диске, занимаемого объектным модулем). В результате трансляция программы на языке МЭЛ выполняется примерно в полтора раза быстрее, чем трансляция такой же по размерам программы па ФОРТРАН©. Это соотношение верно и для входящего в транслятор с МЭЛ транслятора с языка Ассемблера.
ПРОГРАММИРОВАНИЕ МИКРО-ЭВМ «ЭЛЕКТРОНИКА-60» ,
В описываемое системное программное обеспечение входят и средства программирования микро-ЭВМ «Электроника-60», которая отличается относительно небольшими габаритами и малой массой, что создает хорошие предпосылки для построения на основе этой ЭВМ систем управления различными робототехническими устройствами. Однако программирование микро-ЭВМ «Электропика-60» представляло собой непростую задачу. Трудности комплектации инструментальных комплексов на базе ЭВМ «Электропика-60» (отсутствие или нехватка устройств для работы с натурными объектами и устройств внешней памяти на магнитных дисках) вынуждают использовать для программирования ЭВМ «Электропика-60» инструментальные комплексы на базе других ЭВМ (например, СМ-3, -4). Вследствие ограниченности ресурсов ЭВМ «Электроника-60» программирование ведется, как правило, на языке Ассемблера. В Институте прикладной математики им. М. В. Келдыша АН СССР были созданы средства программирования микро-ЭВМ «Электроника-60», базирующиеся на ЭВМ типа М-6000 [5]. В их число входит программный эмулятор ЭВМ «Электропика-60» (позволяющий готовить программы для нее без ее участия), операционная система для двухмашинного комплекса мини-ЭВМ М-6000 — микро-ЭВМ «Электроника-60» и кросс-система программирования на базе языка МЭЛ.
Эмулятор моделирует архитектуру микро-ЭВМ «Электроника-60» в объеме, необходимом для функционирования основных программ
ггТранслятор с языкаТранслятор с языкаЭлектроника-60^Электроника-60^или "Компоновщик"или "Компоновщик"АссемблераАссемблераСупервизорЭВМ "Электроника-60"СупервизорЭВМ "Электроника-60"М-6000 IМ-6000 IИнтерпретатор ввода 一 выводаИнтерпретатор ввода 一 выводадосдосВидеотерминалВидеотерминалРис. 5. Структурная схема комплекса ЭВМ «Электроника-60»—М-6000Рис. 5. Структурная схема комплекса ЭВМ «Электроника-60»—М-6000перфоленточной операционной ей- стемы — транслятора с языка Ассемблера и «Компоновщика». Программная модель ЭВМ «Электро- ника-60» имеет 16К байт оперативной памяти и внешние устрой- ства: фотосчитыватель перфолен- TN，перфоратор и пишущую ма- шинку. Физически операции ввода-вывода выполняются на соответствующих внешних устройст- вах миии-ЭВМ М-6000. Перфолен- та может подменяться файлами на диске. В состав эмулятора входит ретранслятор, , позволяющий восстановить текст программы па языке Ассемблера. Потребность в
г
г
Транслятор с языка
Транслятор с языка
Электроника-60^
Электроника-60^
или "Компоновщик"
или "Компоновщик"
Ассемблера
Ассемблера
СупервизорЭВМ "Электроника-60"
СупервизорЭВМ "Электроника-60"
М-6000 I
М-6000 I
Интерпретатор ввода 一 вывода
Интерпретатор ввода 一 вывода
дос
дос
Видеотерминал
Видеотерминал
Рис. 5. Структурная схема комплекса ЭВМ «Электроника-60»—М-6000
Рис. 5. Структурная схема комплекса ЭВМ «Электроника-60»—М-6000
ретрансляции появляется в тех случаях, когда необходимо разобраться в устройстве программ, текст которых по той или иной причине отсутствует. Например, с помощью ретранслятора была реорганизована библиотека стандартных подпрограмм перфоленточной операционной системы.
При очевидных достоинствах (пользователь работает на достаточно комфортабельной ЭВМ М-6000, не нужна ЭВМ «Электрони- ка эмулятор обладает столь же очевидным недостатком' программная интерпретация на ЭВМ М-6000 системы команд ЭВМ «длектроника-60» приводит к значительному замедлению выполняе- мои в эмуляторе программы. Для того чтобы полностью проинтерпретировать одну команду ЭВМ «Электроника-60», в эмуляторе выполняется примерно сто команд ЭВМ М-6000. Поэтому для подготов- ки больших программ эмулятор мало пригоден. Подготовка больших программ для ЭВМ «Электроника-60» на ийструментальном комп- лек器 осуществлялась с помощью комплекса М-6000 - «Электропи- и с использованием кросс-системы на базе языка МЭЛ.
Операционная система двухмашинного комплекса (рис. 5) пред- ставляет собой модифицированную перфоленточную операционную систему ЭВМ «Электроника-60». Модификация состоит в том, что запросы на ввод-вывод от программы, находящейся в ЭВМ «Электроника-60», передаются в ЭВМ М-6000 по каналу связи интерпретируются там специальной программой и выполняются на внешних устройствах ЭВМ М-6000. Операции с перфолентой заменяются операциями с файлами. Загрузка программ в ЭВМ «Элект- роника-60» осуществляется по каналу связи из ЭВМ М-6000 Пользователь управляет работой системы через операторский терминал пол? п М-оООО и практически не замечает существования микро- ЗНМ «Электроника-60». По комфорту и производительности работа на двухмашинной системе примерно соответствует программирова- нню мини-ЭВМ М-6000 на языке Ассемблера в рамках дисковой one- рационной системы.
Однако, как было отмечено выше, язык Ассемблера неудобен для программирования робототехнических задач. В Институте прикладной математики им. М. В. Келдыша АН СССР создана кросссистема программирования ЭВМ «Электроника-60» на базе языка МЭЛ. На ЭВМ М-6000 имеется версия транслятора с этого языка, которая переводит программу, написанную на МЭЛ, в объектный модуль, содержащий команды ЭВМ «Электроника-60». Программа «Компоновщик» дисковой операционной системы ЭВМ М-6000 (специальный режим работы этой программы) обрабатывает совокупности таких объектных модулей и выдает загрузочный модуль программы, готовый к выполнению на микро-ЭВМ «Электропика-60». Его можно загрузить в нее по каналу связи или выдать на перфоленту.
Двухмашинная система обладает также еще одним важным достоинством: микро-ЭВМ «Электроника-60» имеет выход на устройства связи с натурными объектами, входящими в комплект миниЭВМ М-6000. Кроме того, ЭВМ М-6000 может моделировать для ЭВМ «Электроника-60» внешнюю среду.
* * *
Разработанное системное программное обеспечение широко используется в Институте прикладной математики им. М. В. Келдыша АН СССР при решении задач по созданию систем управления для мобильных роботов, сборочных роботов, роботов для дуговой сварки [6—9]. Практика показала, что созданное системное программное обеспечение хорошо обеспечивает режим отладки, характерный для задач робототехники, и позволяет значительно ускорить решение этих задач.
ЛИТЕРАТУРАт
Мямлин А. Н., Смольянов Ю. П., Силъвикский В. А., Федорин О. С., Донцов В. Е» Лазутин Ю. М., Павловский В. Е. Комплекс моделирования и макетирования робототехнических систем.— В кн.: Всесоюз. совещ. по робототехническим системам, Владимир, окт. 1978: Тез. докл. М.: Наука, 1979, с. 224-225.
Усов С. А. Диалоговый монитор ДИМОН. М.: Наука, 1979. 125 с.
Карпов И. Я., Лазутин Ю. М., Ярошевский В. С. ГРА①ОР-М: комплекс графических программ на ФОРТРАНе для ЭВМ М-6000; Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 138. М., 1980. 28 с.
Александров М. А., Лазутин Ю. М. Комплекс программ на ФОРТРАНе для работы с графическим дисплеем СИГДА на ЭВМ М-6000: Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 107. М., 1981. 22 с.
Лазутин Ю. М., Яшкичев Л. В. Система программирования микро-ЭВМ «Электроника-60» на мипи-АВМ М-6000: Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 58.1982. 21 с.
Охоцимский Д. Е, Платонов 4 ^., Кугушев Е. Я., Ярошевский В. С. Управление макетом шагающего аппарата при преодолении препятствий.——В кн.: Исследование робототехнических систем, М.: Наука, 1982, 66—71 с.
Гримайло С. И., Камынин С. С., Кугушев Е. Я. Программное обеспечение манипуляторов с очерствленными схватами: Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 104. М” 1981, 21 с.
Платонов А. Я., Кирильченко А. 4., Кугушев Е. И. Использование локаль-
ных ориентиров для определения положения мобильного робота.——В кн.: Проблемы машинного видения в робототехнике. М.: Ин-т прикл. математики им. М. В. Келдыша АН СССР, 1981, 36-47 с.
Охоцимский Д.艮，Платонов А. К., Смольянов Ю. П., Гримайло С. И., Камынин С. С., Кугушев Е. И. Исследование многооперационной сборки с помощью экспериментальной робототехнической системы.——В кн.: Роботизация сборочных процессов. М.： Наука, 1985, № 76, с. 61—88.
УДК 621.865.8.001.1
СПЕЦИАЛИЗИРОВАННАЯ ОПЕРАЦИОННАЯ СИСТЕМА: ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
ИССЛЕДОВАТЕЛЬСКОГО ИНСТРУМЕНТАЛЬНОГО РОБОТОТЕХНИЧЕСКОГО КОМПЛЕКСА
Ф. Верещагин, С. Л. Зенкевич, А. В. Назарова
Одной из основных тенденций в робототехнике, стимулирующих ее развитие, является увеличение сферы использования роботов, заключающееся, с одной стороны, в расширении круга задач, решаемых роботами, с другой ——в усложнении робототехнических систем, что выражается в оснащении их дополнительными внешними устройствами и соответствующим программным обеспечением. Формирование программ движения роботов превращается из относительно простой задачи в достаточно сложный многоступенчатый процесс, включающий в себя ряд этапов, осуществление которых на рабочем (промышленном) комплексе затруднительно. В этом случае целесообразным представляется использование многофункционального инструментального комплекса, оснащенного широким набором внешних устройств и развитым программным обеспечением и выполняющим следующие функции:
разработка и исследование методов управления поведением робота (движением и обработкой сенсорной информации);
формирование, отладка и тестирование программ движения робота;
генерация управляющих программ и данных для рабочего (промышленного) комплекса.
Рассмотрим программное обеспечение исследовательского инструментального робототехнического комплекса и а базе управляющей ЭВМ СМ-4 и антропоморфного электромеханического манипулятора УЭМ-2 (структурная схема комплекса приведена на рис. 1).
Структура операционной системы. При разработке общей структуры специализированной операционной системы использовалась аналогия с известными универсальными операционными системами. Она касается различных сторон, в частности, наличия языковых трансляторов, программ-редакторов, структурирования данных и т. д. Отличие в операционных системах состоит в том, что универсальные операционные системы обеспечивают пользователя возможностью манипулировать с данными, а основное назначение специа-
Рис. 1. Структурная схема исследовательского инструментального робототехнического комплекса
ЦП СМ-4 — центральный процессор
-мини-ЭВМ СМ-4;
ОЗУ — оперативное запоминающее устройство;
НМЛ — накопитель на магнитной ленте;
НГМД — накопитель на гибкоммагнитном диске;
НМД — накопитель на магнитном диске;
К НМЛ — кассетный накопитель на магнитной ленте;
УПО — устройство последовательного обмена
Рис. 2. Структурная схема специализированной операционной системы
лизированной операционной системы — манипулировать с объектами. Таким образом, поскольку специализированная операционная система совпадает с универсальной с точностью до объекта, с которым она работает, их структуры в общих чертах совпадают.
Операционная система (рис. 2) состоит из программ двух типов: управляющих и обрабатывающих. Управляющие программы обеспечивают функционирование системы в целом, обрабатывающие — работают под управлением управляющих программ и выполняют в основном преобразование данных.
К управляющим программам относятся:
управление заданиями (функции управления заданиями выполняет интерактивный монитор, обеспечивающий интерфейс между человеком-оператором и системой)；
управление данными (программы управления данными осуществляют операции ввода-вывода, каталогизации наборов данных, форматирования данных, т. е., вообще говоря, поддержания файловой структуры);
управление задачами (функции управления задачами выполняет супервизор, который обслуживает режим исполнения роботом рабочей программы движения； основная задача супервизора 一 поддер-
Рис. 3. Основные операции, выполняемые в процессе формирования рабочей программы н ее исполненияРис. 3. Основные операции, выполняемые в процессе формирования рабочей программы н ее исполненияwoiogod QWHUh•国 Fdl:'GmHghxgo ou -§^OEO ^«£S23O。Rd 啓0woiogod QWHUh•国 Fdl:'GmHghxgo ou -§^OEO ^«£S23O。Rd 啓0―►PROGRAM―►PROGRAMTRAINTRAIN—FDIT-*-RUN-►EXEC-* COPY—FDIT-*-RUN-►EXEC-* COPY-►ТЕМ-►ТЕМ— DIRECTORY— DELETE— RENAME-**HELP— DIRECTORY— DELETE— RENAME-**HELP
Рис. 3. Основные операции, выполняемые в процессе формирования рабочей программы н ее исполнения
Рис. 3. Основные операции, выполняемые в процессе формирования рабочей программы н ее исполнения
woiogod QWHUh•国 Fdl:'GmHghxgo ou -§^OEO ^«£S23O。Rd 啓0
woiogod QWHUh•国 Fdl:'GmHghxgo ou -§^OEO ^«£S23O。Rd 啓0
―►PROGRAM
―►PROGRAM
TRAIN
TRAIN
—FDIT
-*-RUN
-►EXEC
-* COPY
—FDIT
-*-RUN
-►EXEC
-* COPY
-►ТЕМ
-►ТЕМ
— DIRECTORY
— DELETE
— RENAME
-**HELP
— DIRECTORY
— DELETE
— RENAME
-**HELP
жание дисциплины мультизадачного выполнения рабочей программы) ;
управление объектом (программы управления объектом — это драйверы, обеспечивающие обмен данных между управляющей ЭВМ и манипулятором).
К обрабатывающим программам относятся следующие:
транслятор с проблемно-ориентированного языка (проблемно- ориентированный язык необходим для формирования программы функционирования манипулятора);
трансляторы с языков программирования (специализированная операционная система содержит трансляторы с ФОРТРАНа и макро-ассемблера, входящие в состав универсальной операционной системы, что дает пользователю возможность писать фрагменты управляющих программ на языке, наиболее подходящем для реализации алгоритма);
обслуживающие программы («Редактор», «Отладчик», «Загрузчик», «Библиотекарь» и т. д.);
программы пользователя (каждая из них реализует определенное движение или группу движений манипулятора; программы объединены в библиотеку и могут использоваться либо самостоятельно, либо как фрагмент формируемой пользователем задачи).
Управление заданием: команды монитора. Оператор общается с роботом, используя либо команды монитора, либо команды некоторой служебной программы, вызываемой с помощью команды монитора. Поэтому при разработке монитора в основу были положены следующие принципы:
команды монитора должны удовлетворять всем потребностям оператора по выполнению стоящей перед ним задачи;
работа с операционной системой не должна требовать квалификации программиста.
Проведенный анализ позволил выявить следующие операции, выполняемые человеком-оператором (рис. 3):
формирование и отладка программ движения робота в режиме запоминаемой программы и в режиме запоминаемых данных (режим обучения);
исполнение программы движения;
передача данных рабочему комплексу;
тестирование внешних устройств, идентификация их параметров;
сервис.
Решение этих задач нашло свое отражение в выборе команд монитора. Заметим, что везде ниже: подсказки и сообщения системы
I выделяются подчеркиванием; все имена, участвующие в оиисании команд монитора, являются обобщенными, т. е. могут содержать, кроме имени файла, еще и имя устройства.
Рассмотрим набор основных команд монитора специализированной операционной системы:
PROGRAM — формирование программы управления роботом на проблемно-ориентированном языке. Формат команды:
PRCl&KAM
IHPUT &mLE 二 <ИГ'1Я_ВХОДНС1Гй_ТЕКСТС1В1：1ГО_ФййЛй % ! < CPLF〉
E1TPUT 曰二总-FILE = < ИГ'1Я_ВЫХОДНС1ГО_ТЕКС.ТС1ВиГй_«НЙЛй匚团_F >
CiUTPUT RUN-FILE^ £ ИМЯ_ЗйДАЧИ > ! < CRLF >
诉TICiH =工旧 >「< 1Г1 > ! < EX > ! < CRLF >
Человеку-оператору предоставляется возможность воспользоваться следующими ключами:
DB — отладочный режим (программа исполняется покомандно);
IM — имитация движения манипулятора на экране графического дисплея в процессе исполнения;
ЕХ — немедленное исполнение сформированной задачи.
EDIT — создание новых текстовых файлов и редактирование уже существующих. Формат команды:
EDIT
INPUT SOS-FILE = < ИМЯ-ВХОДНОГО.ТЕКСТОВйГССФййЛА > ! < CRLF 〉
@」丁山丁 曰二広-FILE = < ИМЯ_ВЫХОДНОГО_ТЕК.СТОВйГС1_ФАЙЛн > ! < CRLF >
RUN 一 исполнение программы движения, подготовленной в режиме PROGRAM. Формат команды:
RUN
TRSK ЬШЕ = < ИГ'1Я_ЗйДАЧИ >
IMMEDIATE — режим интерпретатора команд человека-оператора. Этот режим, по существу, эквивалентен режиму, обеспечиваемому командой монитора PROGRAM с той лишь разницей, что операторы языка управления интерпретируются, а не компилируются. Формат команды:
IMMEBIATE
★SION = < ИМЯ-ОПЕРАТОРА >
PRRRMEfERS：
< СПИСОК-.ПАРАМЕТР08 >
TRAIN — формирование, отладка и редактирование программы движения в режиме запоминаемых данных (в режиме обучения). Формат команды:
TRAIN
INPUT DATA NAME = < ИМЯ_ВХОДНЫХ_ДАННЫ,Х > ! < CRLF >
OUTPUT DATA НАПЕ = < ИМЯ_ВЫХОДНЫХ_ДАННМХ ：> ! < CRLF >9
UEFaULT : PRMi = < ЧИСЛО > ! PRM2 ==〈 ЧИСЛО > ! .-- ! < CRLF
CpTI=IE ! SN ! < CRLF, >
Команда TRAIN является многофункциональной и позволяет:
формировать и редактировать программу движения в диалоговом режиме, не приводя в движение исполнительный механизм (ре- .жим off-line);
формировать и редактировать программу движения, используя задающие органы (режим on-line), которыми могут служить： рукоятка, задающий исполнительный механизм, пульт, клавиатура дисплея;
получать данные для использования на рабочем комплексе, выводя соответствующий файл, содержащий сформированную программу движения, на требуемое устройство (для чего достаточно указать это устройство в имени выходных данных). При реализации режима TRAIN был использован аппарат теории конечных автоматов, расширенный с целью учета первоначальной подстройки его параметров, которая осуществляется в процессе ввода умолчаний.
ЕХЕС — исполнение программы движения, сформированной в режиме TRAIN. Формат команды:
ЕХЕС：
ПАТй-NAME = < ИМЯ-ДАННЫХ >
OPTION йТ > ! < ST > ! < CRLF >
PCHNT = < НОМЕР-ПОЗИЦИИ >
Программа может выполняться в автоматическом или в пошаговом режимах (ключи АТ и ST соответственно), как с первой, так и с любой другой позиции (параметр <номер-позищти>).
Представленные основные команды монитора позволяют оператору решить большую часть задач, связанных с формированием и исполнением программ движения манипулятора. Кроме того, существует широкий класс сервисных команд, которые могут выполнять следующие функции:
тестировать каналы связи ЭВМ—манипулятор;
калибровать телевизионную камеру;
выполнять преобразование файлов.
Язык управления движением. Формирование рабочей программы может проводиться двумя способами: в режиме запоминания данных и в режиме запоминания команд. Последний способ более перспективен, поскольку позволяет не только осуществить движение по жесткой программе, но и подстроить его (и вообще выбрать поведение) в зависимости от показаний сенсорной системы.
Разработанный язык управления движением является языком
Группа операторовФормат оператораОписаниеЭлементарные операторы управ- ления движениемPQ (j,Ql,Q2,…，Q6)Перевод манипулятора в состояние, характеризуемое обобщенными координатами QI, Q2,...,Q6IPQ (i, A)Перевод манипулятора в состояние, характеризуемое вектором АОператоры пере- дачи управленияJMP (〈метка〉)IJMP «событие), <метка>)Безусловная передача управления на указанную меткуПередача управления на указанную метку в случае возникновения указанного событияАрифметические операторыQST (Q, T) SQ (n, S, Q)Решение прямой задачиРешение нелинейной обратной задачиМакрооператорыGLOS OPEN PNT (T)\Закрыть схватОткрыть схватПеревод манипулятора в состояние, характеризуемое матри- цой ТГруппа операторовФормат оператораОписаниеЭлементарные операторы управ- ления движениемPQ (j,Ql,Q2,…，Q6)Перевод манипулятора в состояние, характеризуемое обобщенными координатами QI, Q2,...,Q6IPQ (i, A)Перевод манипулятора в состояние, характеризуемое вектором АОператоры пере- дачи управленияJMP (〈метка〉)IJMP «событие), <метка>)Безусловная передача управления на указанную меткуПередача управления на указанную метку в случае возникновения указанного событияАрифметические операторыQST (Q, T) SQ (n, S, Q)Решение прямой задачиРешение нелинейной обратной задачиМакрооператорыGLOS OPEN PNT (T)\Закрыть схватОткрыть схватПеревод манипулятора в состояние, характеризуемое матри- цой ТТаблицаТаблицаf' низкого уровня (по сути дела, языком Ассемблер) и включает в 卜 себя следующие классы операторов:
Группа операторов
Формат оператора
Описание
Элементарные операторы управ- ления движением
PQ (j,Ql,Q2,…，Q6)
Перевод манипулятора в состояние, характеризуемое обобщенными координатами QI, Q2,...
,Q6
IPQ (i, A)
Перевод манипулятора в состояние, характеризуемое вектором А
Операторы пере- дачи управления
JMP (〈метка〉)
IJMP «событие), <метка>)
Безусловная передача управления на указанную метку
Передача управления на указанную метку в случае возникновения указанного события
Арифметические операторы
QST (Q, T) SQ (n, S, Q)
Решение прямой задачи
Решение нелинейной обратной задачи
Макрооператоры
GLOS OPEN PNT (T)
\
Закрыть схват
Открыть схват
Перевод манипулятора в состояние, характеризуемое матри- цой Т
Группа операторов
Формат оператора
Описание
Элементарные операторы управ- ления движением
PQ (j,Ql,Q2,…，Q6)
Перевод манипулятора в состояние, характеризуемое обобщенными координатами QI, Q2,...
,Q6
IPQ (i, A)
Перевод манипулятора в состояние, характеризуемое вектором А
Операторы пере- дачи управления
JMP (〈метка〉)
IJMP «событие), <метка>)
Безусловная передача управления на указанную метку
Передача управления на указанную метку в случае возникновения указанного события
Арифметические операторы
QST (Q, T) SQ (n, S, Q)
Решение прямой задачи
Решение нелинейной обратной задачи
Макрооператоры
GLOS OPEN PNT (T)
\
Закрыть схват
Открыть схват
Перевод манипулятора в состояние, характеризуемое матри- цой Т
Таблица
Таблица
элементарные операторы управления движением;
безусловные и условные операторы передачи управления; арифметические операторы；
макрооператоры.
В таблице приведены примеры некоторых из указанных опера- :торов и описан их способ действия. Мощным средством языка яв- f. ляются макросы, которые позволяют оператору сформировать любое $ сколь угодно сложное движение в виде последовательности элемен- Е тарных операторов.
Управление задачей. Процесс исполнения сформированной про- ：граммы движения (либб"亩 режиме запоминания данных — TRAIN, :либо в режиме запоминания команд — PROGRAM), вообще говоря, состоит из двух связанных процессов: вычисления требуемых управляющих сигналов на приводы исполнительного механизма, выполняемого ЭВМ, и отработки этих сигналов. Поскольку темпы протекания этих процессов различны, нельзя рассчитывать на то, что отработка приводами заданных сигналов управления закончится к моменту, когда ЭВМ подготовит их следующий набор. На самом деле, возможны две следующие ситуации: управляющие сигналы вычислены, а манипулятор не отработал предыдущую команду (рис. 4, а), и, наоборот, манипулятор находится в состоянии ожида- Vg£следующего управляющего сигнала (рис. 4, б).
7777777777777777777777777^\ 厂к 丿〃
Риг1™И^уПраВЛЯЮЩ11х С Пауза 夕 Выдача НДЛОВ/
彳 口7口2叮 управляющих сигналов Z
Е〃/〃/〃；〃〃〃〃〃〃〃〃％
ЭВМ
■Отработка, у■Отработка, уМанипуляторМанипуляторРис, 4. Синхронизация процессов вычисления управляющих сигналов и их отработкиРис, 4. Синхронизация процессов вычисления управляющих сигналов и их отработки
■Отработка, у
■Отработка, у
Манипулятор
Манипулятор
Рис, 4. Синхронизация процессов вычисления управляющих сигналов и их отработки
Рис, 4. Синхронизация процессов вычисления управляющих сигналов и их отработки
Рис. 5. Мультизадачный режим работы исполняющей программы
Для того чтобы в некоторой степени скомпенсировать этот нежелательный эффект, при реализации исполнения программы движения использован мультизадачный режим работы процессора (рис. 5). Процесс исполнения сформированного оператором задания содержит следующие задачи:、
вычисление точек позиционирования; интерполяция; вычисление и выдача управления.
Такое разбиение может быть оправдано тем, что:
каждая из перечисленных выше задач представляет самостоятельную вычислительную процедуру;
связь между задачами осуществляется только на уровне входных (выходных) данных.
Каждая из задач оформляется в виде отдельной программы, осуществляющей обмен данными с другими задачами. При этом сообщения, передаваемые одной задачей другой, встают в очередь (линейный список типа FIFO). Такой подход позволил существенно улучшить эффективность работы процессора, сведя к минимуму время ожидания.
* * *
Созданная операционная система предоставляет пользователю широкие возможности по управлению манипуляциоппьтм роботом. Практическая апробация работы системы в различных режимах
показала ее высокую работоспособность. Развитие программного обеспечения возможно при реализации аппарата генерации специа- лизированной операционной системы с целью ее подстройки к манипуляторам с различными кинематическими схемами и разнообразными системами очувствления.
УДК 007.52:001.1
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
СИСТЕМЫ УПРАВЛЕНИЯ СВАРОЧНЫМ РОБОТИЗИРОВАННЫМ КОМПЛЕКСОМ
Т. Тертышный
Применение мини- и микро-ЭВМ в системах управления роботизированными технологическими комплексами (РТК), в частности для дуговой сварки, выдвигает па первый план проблему создания программных средств, обеспечивающих эффективную работу комплекса. Говоря о работе комплекса, мы подразумеваем под атим не только автоматическое выполнение заданной программы технологического процесса, но и ее подготовку: составление, отладку, редактирование.
Включение в «круг обязанностей» системы управления этих вопросов вызвано ориентацией РТК на мелкосерийное производство, где «мобильность» — возможность быстрой перенастройки оборудования 一 является решающим фактором.
Если в реализации автоматического режима работы комплекса необходимость применения ЭВМ не всегда очевидна, то в сфере подготовки и отладки программы технологического процесса последний подход обладает решающими преимуществами. К этому следует добавить, что переход к РТК второго поколения и их дальнейшее развитие связано в первую очередь с повышением уровня алгоритмической организации системы управления, которое без использования ЭВМ, естественно, невозможно.
Построение программного обеспечения систем управления РТК имеет отличающих его от программных систем другого назначения ряд специфических черт: высокий темп обработки информации; большое количество асинхронных источников информации; ограниченные ресурсы микро-ЭВМ.
К тому же робототехника переживает сейчас период бурного развития, который сопровождается появлением новых идей, технических средств, привлечением все более сложного математического аппарата и т. д. Поэтому непременным качеством программного обеспечения РТК должна быть способность к перестройке, наращиванию, т. е. структурная и алгоритмическая гибкость.
В Институте электросварки им. Е. О. Патона АН УССР уже длительное время ведутся работы по использованию мини- и микро-
5 Заказ № 2408129
ЭВМ для управления РТК как для точечной, так и для дуговой сварки. Итогом этих работ явилось создание в рамках программы многостороннего сотрудничества «Интерробот» системы управления на базе микро-ЭВМ «Электроника-60» [1].
Двухуровневая структура технических средств системы позволила рационально распределить нагрузку между блоками системы в соответствии с иерархией алгоритмов переработки информации.
Один блок — блок управления манипуляторами — обеспечивает управление перемещением звеньев манипуляторов сварочного инструмента изделия.
Второй блок 一 блок планирования и координации — обеспечивает формирование команд перемещения для блока управления манипуляторами в соответствии с программой технологического процесса и с учетом действительного положения изделия, а также интерактивный режим работы системы при формировании, контроле и редактировании программы технологического процесса. Ядром каждого блока является микро-ЭВМ с соответствующим программным обеспечением.
Программное обеспечение блока планирования и координации — система РОДУС — имеет модульную структуру с тремя уровнями иерархии. Верхний уровень занимает операционная система управления роботом. Второй уровень иерархии составляют прикладные модули, реализующие заданный алгоритм управления РТК в зависимости от режима работы. Программа технологического процесса образует третий уровень иерархии. Программа технологического процесса реализована на проблемно-ориентированном языке ROWEL.
Операционная система управления роботом представляет собой мультипрограммную операционную систему реального времени, которая обеспечивает:
координированное управление прикладными модулями;
организацию обмена данными между прикладными модулями и внешними устройствами；
выполнение ряда вспомогательных стандартных функций (перекодировка, вычисления, распечатка сообщений об ошибках).
Процесс управления прикладным модулем состоит из запуска модуля, предоставления ему ресурсов системы по программным запросам, возвращения модулю управления после выполнения затребованной системной функции (т. е. функции, выполняемой средствами операционной системы управления роботом) или функции, выполняемой другим прикладным модулем.
Обслуживание прикладных модулей выполняется в соответствии с кодом приоритета PRIOR, который присваивается модулям при генерации системы. Код PRIOR больше О, по не превышает N — максимального количества прикладных модулей, в остальном все модули с точки зрения операционной системы управления роботом независимы и равноправны. Для модуля, занимающего в текущий момент процессор, все остальные прикладные модули независимо от приоритета являются ресурсами системы, которые можно использовать.
Граф изменения состояний приклад ных модулейГраф изменения состояний приклад ных модулейВ системе программного обеспечения, работающей под управлением операционной системы управления роботом, используется жесткое рао пределение памяти (адресного поля оперативного запоминающего устройства (ОЗУ)) между прикладными модулями. Каждый модуль занимает две секции в ОЗУ. Одна секция занимается собственно программой. Начальный адрес этой секции является адресом загрузки модуля. Вторая секция занимается рабочими полями модуля 一 стеком и рабочими ячейками. Адрес вершины стека и его размер фиксируются «Диспетчером» операционной системы управления робота, следящим за текущим положением стека во время обработки запросов модуля и прекращающим выполнение программы модуля в случае переполнения его стека.
Граф изменения состояний приклад ных модулей
Граф изменения состояний приклад ных модулей
Прикладные модули, которые по логике работы системы могут одновременно находиться в ОЗУ, занимают непересекающиеся области памяти.
В основе работы «Диспетчера» операционной системы управления роботом лежит граф перехода состояний прикладных модулей (см. рисунок). Прикладные модули (ПМ) в каждый момент времени могут находиться в одном из пяти состояний.
Модуль, который включен в состав системы, но не загружен в ОЗУ, находится в состоянии EXTERN. После загрузки в ОЗУ модуль переводится в исходное состояние INIT. Модуль может быть выведен из состояния INIT только по заявке другого прикладного модуля или по требованию «Диспетчера». В этом случае прикладной модуль переходит в состояние готовности к выполнению READY. Из состояния READY при благоприятной ситуации модуль переводится в состояние выполнения EXECUT и получает процессорное время и все свободные ресурсы системы.
Выход модуля из состояния EXECUT возможен при наступлении одной из четырех ситуаций:
модуль закончил выполнение своих функций и сообщил об этом операционной системе управления роботом запросом EXIT (в таком случае модуль переводится в состояние INIT);
модуль запросил один из ресурсов операционной системы управления роботом (передачу данных запросом INOUT, выдержку времени) и ожидает выполнения своей заявки (в этом случае модуль переводится в состояние ожидания)；
модуль запросил выполнение другого прикладного модуля, сообщив об этом операционной системе управления роботом запросом
REQUST (в этом случае модуль также переводится в состояние ожидания WAIT);
в результате прерывания от внешнего устройства процессорное время передано другому прикладному модулю (в этом случае ранее выполнявшийся модуль переводится в состояние прерывания INTRPT).
В состоянии WAIT модуль находится до тех пор, пока не будет удовлетворен его запрос (либо средствами операционной системы управления роботом, либо вызванным модулем). Затем прикладной модуль переводится в состояние INTRPT.
Для механизма приоритетного распределения процессорного времени состояния READY и INTRPT эквивалентны. Поэтому, как и из состояния READY, модуль из состояния INTRPT со временем будет переведен в состояние EXECUT и получит возможность продолжить работу.
Перевод прикладных модулей, находящихся в состоянии READY или INTRPT, в состояние EXECUT осуществляется в порядке приоритетов, т. е. при наличии конкуренции процессорное время предоставляет модулю, имеющему наименьший код PRIOR.
Взаимодействие между прикладными модулями и ресурсами системы осуществляется в операционной системе управления роботом посредством обработки трех групп программных запросов;
управления прикладными модулями;
управления вводом—выводом;
и а дополнительные услуги.
Для передачи запросов от прикладных модулей к операционной системе управления роботом используются инструкции внутренних прерываний.
В состав запросов управления прикладными модулями включены следующие запросы:
GET — загрузка прикладного модуля в оперативную память;
KILL — выгрузка прикладного модуля из системы;
REQUST — запуск прикладного модуля;
RUN — отложенный запуск прикладного модуля;
EXIT — окончание работы прикладного модуля;
- STOP — принудительное прекращение работы прикладного модуля;
WTTIME — временное прекращение работы прикладного модуля (выдержка времени);
WTRQEN — временное прекращение работы прикладного модуля до окончания работы другого, ранее инициированного прикладного модуля.
Для обращения к занятым ресурсам в операционной системе управления роботом используется схема «приостановка-активизация задачи». При этом, обнаружив, что затребованный ресурс занят, прикладной модуль формирует запрос выдержки времени WTTIME, в результате чего переходит в состояние WAIT. Получив управление по истечении заданного временного интервала, прикладной модуль повторяет запрос.
В состав системы РОДУС включены следующие прикладные модули:，
MONT — главный управляющий модуль;
REMCNT — модуль ручного управления и обучения；
EDIT — модуль редактирования программы технологического процесса;
PROG ——модуль формирования программы технологического процесса в режиме диалога с оператором через видеотерминал;
SYNCNT — модуль синтаксического контроля программы технологического процесса;
INTRPR 一 интерпретатор операторов языка ROWEL, составляющих программу технологического процесса;
CALCUL — интерпретатор проблемно-ориентированного языка CALROB для выполнения вычислительных операций над векторами и матрицами;
FLOPD — модуль ведения файловой структуры на устройстве внешней памяти на гибких магнитных дисках;
INITST — модуль инициализации и начального тестирования;
TESTEL — модуль текущего контроля системы управления.
Такой набор прикладных модулей позволяет эффективно реализовать как алгоритмы управления технологическим процессом в соответствии с заданной программой технологического процесса, так и формирование, контроль и организацию библиотеки программ технологического процесса. Кроме того, наличие в РОДУС модулей начального и текущего тестирования средств комплекса обеспечивает своевременное обнаружение неисправностей в системе и облегчает ее обслуживание.
Для повышения эффективности программных модулей, реализующих сложные вычислительные алгоритмы в процессе управления комплексом (в частности, алгоритмы установочной адаптации [2]) и при подготовке программы технологического процесса, в состав РОДУС включен интерпретатор CALCUL проблемно-ориентированного языка CALROB. Язык CALROB представляет собой развитие языка ДИЛСП, дополненного процедурами работы с векторами и матрицами, необходимыми для реализации геометрических преобразований в однородных координатах.
Для программирования технологического процесса в системе РОДУС разработан проблемно-ориентированный язык ROWEL.
Операторы языка делятся на три основные группы：
управления последовательностью выполнения программы технологического процесса;
задания элементарных операций;
адаптации к внешней среде.
Первая группа операторов типична для большинства классических языков программирования. В нее входят операторы переходов (условных и безусловных), операторы управления механизмом вызова программ, операторы-ограничители блоков, операторы-переключатели статуса выполнения программных блоков.
Вторая и третья группы специфичны для области применения
языка ROWEL — управления роботизированным технологическим комплексом. Во вторую группу входят операторы задания движения и операторы задания технологических параметров, необходимые для чисто программного управления без связи с внешней средой робота. Третья группа операторов определяет способность комплекса к адаптации к изменяющейся внешней среде. В эту группу входят операторы управления сбором информации от датчиков адаптации и ее обработки.
Язык ROWEL позволяет при задании идентичных участков технологического процесса использовать механизм вызова подпрограмм. Подпрограмма представляет собой описание одного из повторяющихся участков технологического процесса. При формировании подпрограммы задаются первая точка участка и два вектора, определяющих положение участка в пространстве.
Система РОДУС позволяет формировать и редактировать программы технологического процесса на языке ROWEL в двух режимах: ОБУЧЕНИЕ (ручной режим) и ПРОГРАММИРОВАНИЕ. В режиме ОБУЧЕНИЕ средством для задания операторов языка является пульт обучения. Каждому формируемому оператору языка соответствует определенная комбинация клавиш пульта обучения. Ограниченные возможности его вынуждают усекать используемый при этом набор операторов ROWEL. Полностью возможности языка могут быть реализованы только при формировании программы технологического процесса в режиме ПРОГРАММИРОВАНИЕ. Основная сложность при этом состоит в правильном задании аргументов перемещения. Поэтому оптимальным является сочетание режимов ОБУЧЕНИЕ и ПРОГРАММИРОВАНИЕ в процессе подготовки программы технологического процесса. В режиме ОБУЧЕНИЕ формируется траектория перемещения манипуляторов, а в режиме ПРОГРАММИРОВАНИЕ формируется логика выполнения программы технологического процесса и в основном задаются значения технологических параметров.
Программное обеспечение блока управления манипуляторами реализует алгоритм циклического обслуживания управляемых объектов, каковыми являются приводы отдельных звеньев. В каждом цикле выполняется интерполяция в декартовых координатах заданного отрезка траектории (прямолинейного или дугообразного) и преобразование приращений декартовых координат в криволинейные. Структурно программа преобразования координат выделена в отдельный модуль, что позволяет легко перестраивать программное обеспечение в соответствии с кинематикой используемых манипуляторов.
Разработанная система РОДУС является базовой для семейства аналогичных систем с различными функциональными возможностями:
РОДУС-И 一 система-исполнитель, предназначенная для РТК- исполнителей, не требующих редактирования программы технологического процесса (может быть использована одна микро-ЭВМ, поскольку из состава программных модулей исключены все модули,
реализующие подготовку программы технологического процесса; при этом программное обеспечение блока управления манипуляторами включается в РОДУС-И в статусе прикладного модуля);
РОДУС-Г — система группового управления, в которой один блок планирования и координации обслуживает несколько блоков управления манипуляторами (используется рентабельность прикладных модулей РОДУС);
РОДУС-А — система адаптивного управления, в которую дополнительно включен модуль обработки информации от сенсоров текущего положения стыка относительно инструмента.
Программные модули размещаются в постоянном запоминающем устройстве системы управления и занимают 16К двухбайтных ячеек памяти. Рабочие поля занимают 4К слов в оперативной памяти. Под программы технологического процесса выделено 8К слов оперативной памяти. Программное обеспечение реализовано на языке макро-ассемблера ЭВМ СМ-3 и может эксплуатироваться на микро- ЭВМ «Электроника-60», а также на мини-ЭВМ СМ-3 и -4.
ЛИТЕРАТУРА
Кисилевский Ф. Н., Тертышный В. Т., Швыдкий Я. Р. Система управления роботизированным комплексом с использованием микропроцессоров.— В кн.: Применение роботов и манипуляторов в сварке: Тр. конгр. РОБОТ-82. Брно, 1982, 11 с.
Тертышный В. Т. Метод установочной адаптации роботизированного комп- лекса для сварки.——В кн,: Робототехнические системы в отраслях народного хозяйства Тез. докл. II Всесоюз. совещ. по робототехническим системам, Минск, 15—19 мая 1981 г. Минск: БЕЛНИИТИ, 1981, с. 93—94.
УДК 007.52:62—52:001.1
ПРОБЛЕМНО-ОРИЕНТИРОВАННЫЙ ИНТЕРПРЕТАТОР ДЛЯ МИКРОПРОЦЕССОРНЫХ СИСТЕМ УПРАВЛЕНИЯ ДВИЖЕНИЕМ
В. Т. Тертышный, Л. II. Куца,
Реализация вычислительных алгоритмов в системах управления движением требует наличия в системе программного обеспечения компактного и быстродействующего инструмента для матричной и векторной арифметики. Использование языка Ассемблер позволяет получать эффективные программы, однако вызывает значительные затраты на создаиие системы. Применение языков высокого уровня требует включения в состав матобесиечепия соответствующих поддерживающих средств, что усложняет и удорожает систему управления. Широко распространенные интерпретирующие языки (БЭЙСИК, ДИАСП) не обладают необходимой производительностью.
В Институте электросварки им. Е. О. Патона разработан язык CALROB для реализации вычислительных алгоритмов в системе
управления перемещением многозвенных манипуляторов. Структура данных и набор операторов языка ориентированы на рептение задач аналитической геометрии в однородных координатах. В структуру данных наряду с традиционными 一 действительными и целыми числами — включены также четырехмерные вектора однородных координат и матрицы (размера 4X4) преобразования систем однородных координат. Тип данных задается неявно — первым символом имени переменной.
Программы на языке CALROB в процессе исполнения интерпре- тируются транслятором CALCUL, включенным в состав программного обеспечения системы. Обращение к этому транслятору осуществляется с помощью макровызова, после которого должен быть записан текст программы.
Каждый идентификатор в рабочем поле интерпретатора имеет жестко закрепленный за ним адрес. При написании программы необходимо следить за использованием имен переменных и распределением памяти между массивами и переменными. К любой ячейке в рабочем поле переменных программист может обратиться как к простой переменной, а также как к элементу одномерного или двумерного массива.,
Библиотека внутренних функций, реализуемых средствами языка, содержит 16 функций. Из них шесть работают с действительными числами, остальные служат для выполнения операций над векторами и матрицами однородных координат.
В состав операторов языка CALROB, из которых строятся исходные программы, входят девять операторов: оператор присвоения; операторы управления (условного и безусловного переходов, цикла); операторы размещения данных (загрузки в стек, выгрузки из стека, задания константы); операторы для отладки программ (вывода на терминал результатов вычислений, приостанова вычислений) .Обмен данными с основной программой, реализованной на языке Ассемблера, осуществляется через стек интерпретатора. Выгрузка переменных из стека осуществляется оператором OUF, загрузка результатов вычислений для передачи в исходную програм му выполняется оператором WS.
Текст программы па языке CALROB должен состоять из про граммных строк девяти типов, каждая из которых содержит оди?< оператор.
Программа сначала транслируется с помощью макрооператоров языка MACRO-11. Транслятор языка MACRO-11 формирует внутреннее представление текста программы на этапе генерации модуля.
На втором этапе это внутреннее представление исходной программы выполняется посредством интерпретации.
Основной вариант интерпретатора реализован на ЭВМ «Электроника-60». Расширенный вариант для удобства отладки — кросс-система на ЭВМ СМ：3 в среде ДОС-СМ.
Существует возможность работы в двух режимах: отладочном и основном. Отладочный режим предполагает обработку операторов отладки программ.
Проблемно-ориентированный язык CALROB использован для реализации вычислений в прикладных модулях программного обеспечения микропроцессорной системы управления роботизированным комплексом для дуговой сварки.
Объем памяти, занимаемый программой «Интерпретатор», 2,25К байт.
УДК 681.32,
СИСТЕМА ВЗАИМОДЕЙСТВИЯ ПРОГРАММНЫХ МОДУЛЕЙ ДЛЯ МНОГОПРОЦЕССОРНЫХ СИСТЕМ УПРАВЛЕНИЯ
И. П. Белякова, М. А. У тин、
ПОСТАНОВКА ЗАДАЧИ
Многопроцессорные системы управления предполагают взаимодействие программных составляющих различных процессоров для выполнения единой задачи управления. В распределенных системах типа локальных сетей процессоры связываются посредством аппаратных модулей, позволяющих передавать информацию от одного процессора к другому и выступающих в роли внешних устройств.
Для реализации программного взаимодействия подобных систем принципиально возможно использование: языков высокого уровня с параллельными конструкциями типа ADA [1], CPASCAL [2], MODULA [3], СР [4]; сетевых операционных систем типа DECNET; языка Ассемблера, позволяющего обращаться к регистрам внешних устройств. Из этих трех подходов языки высокого уровня наиболее предпочтительны, так как обеспечивают наибольшую производительность разработки программ и высокое качество документирования.
Однако большинство языков для разработки параллельных программ реализованы либо для однопроцессорных вариантов [2], либо для систем с общим адресным пространством [5], а реализация языков в сетевой архитектуре не выполнена, к тому же не для всех языков это будет эффективно. Сетевые системы имеют сложные стандартизованные протоколы связи, снижающие скорость обмена информацией, и поэтому обычно не используются для систем управления. Создание программы взаимодействия на языке Ассемблера не оправдано с точки зрения производительности, сложности повторного использования, сложности стыковки с программами, написанными на языке высокого уровня. В связи с этим была поставлена задача разработки стандартной системы взаимодействия, выполняемой в рамках распределенной операционной системы с помощью программ, поддерживающих передачу данных через модули связи с наибольшей эффективностью, и системы команд обращения из прикладных программ системы управления. Поставленная задача реша-
лась при следующих ограничениях па структуру программных и аппаратных средств:
система управления представляет собой локальную сеть процессоров, связанных с помощью модулей-буферов двустороннего обмена (без общего поля памяти), ограничений на топологию нет;
процессоры подключаются к шине другого процессора на правах внешнего устройства, т. е. имеют фиксированные адреса регистров состояний, данных и адреса векторов прерываний;
распределение программного обеспечения ио процессорам статическое, определяемое в момент компоноики системы и фиксируемое в момент загрузки;
каждому процессорному модулю соответствует единственный функциональный процесс — программный модуль системы управления.
ОПИСАНИЕ СИСТЕМЫ ВЗАИМОДЕЙСТВИЯ
Для разработки системы программного взаимодействия многих процессоров было предложено выделить два основных типа программных процессов, протекающих в системе управления. В первую очередь выделяются процессы, реализующие основной контур обратной связи и поддерживающие нормальное статическое функционирование системы управлепия. К этим процессам предъявляются жесткие требования по частотным свойствам, согласуемым с частотными характеристиками объекта управления. Назовем такие процессы несвободными в отличие от свободных, для которых допустимы длительная остановка и последующее продолжение.
Всем процессам разрешено взаимодействовать только посредством разделяемых структур данных, причем одну и ту же структуру данных используют только два процесса. Исключение составляют структуры данных, принадлежащие служебным процессам типа функций, процедур, подпрограмм. К разделяемым структурам данных относятся структуры типа массивов, модифицируемые одним процессом, а используемые другим, т. е. процессы связаны отношениями «производитель—потребитель».
Для разделяемых структур данных {XJ определены допустимые команды системы взаимодействия (см. таблицу). Никакие другие операторы языка Ассемблера или языков высокого уровня не допустимы при обращении к разделяемым переменным, что контролируется трансляторами или компиляторами.
Ддя каждой разделяемой структуры данных Х^ определяется явно в команде системы взаимодействия соответствующая копия — локальная структура данных аХ将 над которой разрешены все операции последовательного языка программирования.
Реализация команд системы взаимодействия обеспечивает взаимоисключающее чтение—запись структуры данных из одних процессов в другие с одновременной синхронизацией типа «рукопожатие» для свободных процессов. Для несвободных процессов не выполняется синхронизация, а осуществляется пересылка и прием данных как неделимая операция. При взаимодействии свободных
Таблица
Команда
Содержание
S. READ
X, аХ, N
Послать запрос на структуру данных X в модуль- источник, принять данные, скопировав их в локальный буфер аХ размера N
М. WRITE
X, аХ, N
Подготовить структуру данных X к использованию, скопировав из локального буфера аХ размера N; если запрос па структуру из модуля-приемника есть, послать по запрошенному адресу
S. WRITE
X, аХ, N
Послать запрос на разрешение переслать подготовленную структуру X в модуль-приемник, передать структуру данных при наличии разрешения
М. READ
X, аХ, ^
Принять структуру данных от модуля-источника, если есть запрос на передачу, скопировав структуру X в локальный буфер аХ размера N
$ WRRD
X, аХ, N
У, аУ, N
Послать запрос на разрешение передать блок параметров X процедуре-функции удаленного модуля, по разрешению передать блок параметров и запрос на чтение результата У; по готовности результата принять в локальный буфер аУ размера ”
М. RDWR
X, аХ, N У,аУЛ
Если есть запрос от модуля на передачу парамет- ров процедуры-функции, принять параметры в локальный буфер аХ от первого в очереди процессоров, подготовить результат У и послать по запрошенному адресу
Примечание: S. READ,..., М. RDWR — экстракоды команд； X — имя разделяемой переменной; аХ — имя буфера локальной памяти процесса; N — размер буфера
процессов они задерживаются всякий раз, когда новые данные либо не получены из другого модуля, либо еще не переданы. Для несвободных процессов осуществляется естественная фильтрация потоков данных, так как каждый процесс работает со своей постоянной скоростью и с той же скоростью он принимает и выдает данные вне зависимости от согласования скоростей работы взаимодействующих процессов.
Команды системы взаимодействия объединяются в пары М. READ - S. WRITE, М. WRITE - S. READ, S. RDWR- M. WRRD для каждой структуры данных X- Команды типа М выполняются в процессе-владельце структуры без запроса на взаимодействие с другим процессом. Команды типа S выполняются в процессе-слуге, который всегда посылает запрос в процесс-владелец па разрешение выполнить команду [4].
РЕАЛИЗАЦИЯ СИСТЕМЫ ВЗАИМОДЕЙСТВИЯ
Система взаимодействия реализована в виде двух составляющих программ. Основная системная программа INTERACTION, обслуживающая выполнение экстракодов команд системы взаимодейст-
вия, представляет собой резидентную системную программу каждого процессорного модуля. Интерфейсом между прикладной программой системы управления и программой INTERACTION служат структуры данных (таблицы, дескрипторы, буферы), расположенные в прикладной программе и формируемые системными программами средств разработки.
Прикладная программа каждого процессорного модуля оформляется в виде программного процесса, представленного указателем записи содержимого его регистров в определенной структуре данных [2, 6], называемой дескриптором процесса:
D1PRI Указатель записи регистров
Тип процесса (свободный, несвободный) Указатель фонового процесса
Разделяемые переменные представлены своими именами в таблице разделяемых переменных TABLCV процесса:
TABLCV Имя первой переменной
Дескриптор первой переменной
Имя второй переменной
Дескриптор второй переменной
Имя г-й переменной
Дескриптор i-й переменной Конец таблицы
Таблица TABLCV является основным интерфейсом между функ- циональным процессом и системной программой INTERACTION, имеет фиксированный адрес в системной памяти и содержит, кроме имен переменных, адреса их дескрипторов {DJ. Дескрипторы в свою очередь имеют всю информацию относительно переменных {XJ:
DtУказатель системного буфера переменной
Указатель дескриптора процесса
Указатель адреса процессорного модуля процесса, разделяющего структуру
Дескрипторы переменных, разделяемых несколькими процессами (для служебных процессов), отличаются от приведенных тем, что вместо указателя на адрес процессора имеют указатель на список адресов процессоров, запрашивающих доступ к структуре данных.
Для каждой переменной X? определен системный буфер СХ； для ее временного размещения и локальный аХг- для постоянного использования прикладной программой последовательных операторов. Системный буфер имеет следующую структуру:
WSiСлово состояния буфера
GXfПервое слово разделяемого массива
Последнее слово разделяемого массива Конец буфера
Слово состояния буфера WS? имеет отдельный бит, указывающий на наличие запроса на прием—передачу разделяемой структу- ры Хг, и бит, указывающий на состояние буфера «пуст—полон». Буфер считается пуст, если его структура скопирована либо в локальный буфер, либо в другой процессорный модуль, и полон, если копирования не было. Эти два бита являются определяющими для синхронизации процессов и выполнения команд системы взаимодействия. Свободные процессы задерживаются при исполнении команд READ, если буфер пуст, и при исполнении WRITE — если полон.
Программа INTERACTION содержит две основные ветви: программу декодирования и выполнения экстракодов TRAPDC и программу декодирования аппаратных прерываний INTERDC от модулей межпроцессорной связи. Эти две ветви пересекаются, используя общие подпрограммы передачи сообщений через модули связи. В целом обе ветви имеют три уровня подпрограмм: обеспечивающий интерфейс с программой пользователя (первый); выполняющий формирование сообщений и сборку сообщений (второй); осуществляющий передачу пакетов через модуль связи (третий). Все уровни взаимодействуют через передачу параметров и вызов процедур, что позволяет достаточно просто модифицировать любой из уровней программы. Выполнение любой ветви программы состоит максимум из двух фаз посылки—приема запроса и приема—передачи данных. Каждая из этих фаз выполняется как непрерываемая неделимая операция.
Система взаимодействия программных процессов за счет использования распределенного управления позволяет разгрузить один процессор от выполнения сложно синхронизируемых параллельных процессов, таких, как расчет траекторий управления, прием и обработка больших массивов информации датчиков, взаимодействие с оператором через пульт управления, высокоскоростное обслуживание основного контура управления. Распределение функций существенно упрощает компоновку системы управления, увеличивает гибкость, легкость перестройки, быстродействие, расширяет функциональные возможности.
ЛИТЕРАТУРА
Язык программирования АДА: Предварительное описание: Пер. с англ.—— М.: Финансы и статистика, 1981. 189 с.
Hansen Р. В. The Architecture of Concurrent Programmes. N. Y.: Prentice- Hall, 1977. 317 p.
Wirth TV. Modula: A Language for Modular Multiprogramming.— Software Practice and Exper., 1977, vol. 7, p. 3—35.
Mao T. W., Yen R. T. Communication Port: A Language Concept for Concurrent Programming.— IEEE Trans, on Software Eng. March, 1980, vol. SE-6, N 2, p. 194—204.
Buhr R. J. A. Concurrent High Level Language Models Applied to Multimi- croprocessor System Development. Operating Systems. N. Y.: North-Holland, 1978, p. 45—63.
Wirth M Desing and Implementation of Modula.— Software Practice and Exper., 1977, vol. 7, p. 67—84.
УДК 681.32
ОРГАНИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПОЛУНАТУРНОГО МОДЕЛИРОВАНИЯ РОБОТОВ
А. И. Казьмин, А. А. Менн, А. А. Петров
При создании современных робототехнических систем во многих случаях традиционные методы машинного моделирования оказываются недостаточно эффективными. Это вызвано целым рядом при- нин, к основным из которых можно отнести следующие:
трудность адекватного математического описания компонент робототехнических систем;
невозможность учета в моделях различных неидеальностей и малых параметров сенсоров и эффекторов роботов, а также трудность формального описания внешней среды;
большое машинное время реализации достаточно полных математических моделей; 4
сложность внесения изменений в программы при модификации моделей из-за большого числа взаимных связей отдельных блоков программных реализаций моделей;
необходимость совместного моделирования различных по частотному спектру непрерывных и дискретных процессов, а также логических и алгоритмических процедур, разнородных технических систем (от механических конструкций до бортовых ЭВМ).
Некоторые из перечисленных трудностей могут быть преодолены при использовании систем полунатурного моделирования, привлекающих в последние годы все большее внимание специалистов.
Моделирование принято называть полупатурным, если наряду с компонентами, реализуемыми на цифровых или аналоговых средствах вычислительной техники, в контуре моделирования используются и реальные (натурные) элементы моделируемой системы.
Одним из перспективных вычислительных средств для организации полунатурных моделирующих комплексов являются локальные сети ЭВМ [1, 2], представляющие собой объединение нескольких ЭВМ (в общем случае разнородных), от которых требуется возможность совместного решения единой задачи (в отличие от использования ЭВМ в глобальных сетях). В то же время локальные сети имеют принципиальные особенности по сравнению с многомашинными вычислительными комплексами, заключающиеся в наличии системной поддержки обмена информацией между любыми ЭВМ сети, а также специальных аппаратно-программных средств, обеспечивающих унифицированное расширение системы за счет подклю- чепия новых ЭВМ и реальной аппаратуры.
Эффективное полупатурное моделирование роботов возможно лишь при максимальном учете особенпостей как локальных сетей ЭВМ, так и робототехнических задач. Эти факторы обусловливают ряд специфических черт программного обеспечения, наиболее существенными из которых являются следующие:
единая система программирования, позволяющая использовать
Структурная схема комплекса полунатурного моделированйя
общий для всей сети язык и устраняющая трудоемкий этап согласования программ, выполняемых на разных ЭВМ;
специальные системные средства для организации параллельных вычислительных процессов;
системная поддержка контроля и диагностики ошибок при модификации программных модулей и структуры их взаимосвязей;
простота включения в контур моделирования сенсоров, эффекторов и другой реальной аппаратуры, замены одних элементов другими, а также замещения их машинными моделями;
интерактивный режим работы не только на стадии подготовки и отладки модели, но и непосредственно в процессе полунатурных экспериментов.
Попытка выполнения некоторых из перечисленных требований была предпринята при разработке программного обеспечения многомашинной гибридной вычислительной системы (ГВС) «Русалка» и создании на ее основе комплекса полунатурного моделирования роботов [2, 3] (см. рисунок).
Цифровая часть ГВС представляет собой расширяемую локаль- ную сеть иерархического типа, а аналоговая часть может рассматриваться как один из специализированных процессоров сети. На верхнем уровне сети используются ЭВМ Единой системы (ЕС), ра-
ботающая нон управлением одной из операционных систем, начиная с версии ОС-4.1 ЕС. На следующем уровне к сети подключаются ЭВМ типа СМ. Между ЭВМ второго уровня отсутствуют непосредственные интерфейсы, так как программы, выполняемые на этих ЭВМ, в большинстве случаев независимы друг от друга. Каналы связи для второго уровня реализованы программно и обмен информацией между ЭВМ этого уровня возможен только через ЭВМ ЕС. К ЭВМ второго уровня посредством системных магистралей могут подсоединяться микро-ЭВМ, специализированные вычислительные устройства и реальная аппаратура.
С целью проведения полунатурных исследований роботов ГВС 《Русалка» была сопряжена с электромеханическим манипулятором типа УЗМ-2 (шесть степеней подвижности, не считая схвата) [4], а также с телевизионной камерой и другими сенсорами. Система сопряжения обеспечивает двустороннюю связь эффекторов и сенсоров робота с вычислительной частью комплекса, контроль передаваемой информации, возможность подключения дополнительной реальной аппаратуры. Специально р аз раб от анньш пульт дистанционного управления позволяет исследователю, находящемуся вблизи рабочей зоны робота (в удалении от вычислительной системы), в ходе полупатурных экспериментов удобно взаимодействовать со всеми подсистемами, менять параметры и структуру исследуемых моделей и алгоритмов в различных режимах, оперативно наблюдая соответствующие изменения функционирования робота.
На машинах первого и второго уровней были использованы модифицированные в разной степени стандартные операционные системы ЕС и СМ ЭВМ. Выбор типа базовой операционной системы предопределялся распределением функций между ЭВМ. Для расчетов, требующих больших объемов памяти, применяется ЭВМ ЕС. Этот тип ЭВМ используется также для упрощающих аналитических преобразований математической модели робота [5]. Как уже отмечалось, на верхнем уровне применяется операционная система ОС ЕС, к которой, помимо пакетов прикладных программ моделирования, добавлен системный пакет, обеспечивающий согласование файловых структур ЕС и СМ ЭВМ. Важной доработкой ОС ЕС, позволившей повысить скорость взаимодействия ЭВМ ЕС и СМ, явилось развитие так называемого графического метода доступа и объединение его вместе с физическим в новый метод доступа [6].
Большей модификации подверглась использованная в качестве базовой на втором уровне операционная система реального времени ОС РВ на ЭВМ СМ-4 — многопользовательская операционная система, обеспечивающая интерактивный режим работы при подготовке программ [5]. Однако многопользовательский режим почти всегда приводит к очень существенному для управляющих ЭВМ недостатку —большому времени реакции на внешние прерывания и обращения к внешним устройствам, в том числе и к аналого-цифровым (АЦП) и цифроаналоговым преобразователям (ЦАП), что является совершенно недопустимым для робототехнических задач. Так, для ОС РВ время реакции на прерывание может достигать
5 10~3 с. Кроме того, значительные трудности при отладке программ реального времени вызывает непостоянство времени реах^ции на прерывание, которое варьируется в довольно широких пределах.
Чтобы уменьшить время реакции и обращения к внешним устройствам, обеспечить постоянное время реакции, к существующем режимам работы ОС РВ — супервизорному и пользовательскому 一 добавлен монопольный режим. В этом режиме все прерывания передаются специальной программе, минуя стандартные средства опе- рациошюИ системы. Прерывания, относящиеся к программе, работающей в реальном времени, передаются непосредственно ей. В монопольном режиме прерывания, поступающие от устройств, с которыми работают другие пользователи, запоминаются и при возврате в пользовательский режим передаются операционной системе для дальнейшей обработки.
Запоминание отложенных прерываний требует небольшой памяти, так как их число не может превышать количество аппаратных
источников.
Уменьшение длительности обращения к внешним устройствам достигается за счет подключения к программе реального времени на стадии компоновки модулей, берущих на себя в монопольном режиме роль драйверов. Вследствие того что в монопольном режиме в каждый момент времени может находиться только одна программа, удается значительно упростить и тем самым ускорить выполнение программ, взаимодействующих с такими устройствами, как АЦП и ЦАП, с которыми обычно могут работать несколько поль
зователей.
В программу пользователя на стадии компоновки добавляется ряд служебных модулей, чтобы любой участок программы мог быть 二 исполнен как в пользовательском, так и в монопольном режиме. Переключение с режима на режим происходит при выполнении спе- 'циальных команд, введенных в автокод в виде библиотечных макрооператоров. Одновременно с этим переключение может вьшолнять- ；ся и из программы, написанной на ФОРТРАНе, с помощью обращения к специальным подпрограммам. Как правило, имена и параметры макрооператоров и подпрограмм идентичны. Введены следующие основные операторы: RTON — включить монопольный режим; RTOFF — включить пользовательский режим; INRT — включить монопольный режим, запомнив предыдущий; INUSR — включить пользовательский режим, запомнив предыдущий; OUT — вер
нуться в ранее запомненный режим.
Пребывание в монопольном режиме не может продолжаться бесконечно долго. С каждым оператором RTON и INRT задается параметр, определяющий время, требуемое для монопольного режима. Этот параметр не должен превышать заданного значения. Чтобы предотвратить зацикливание системы, проводится контроль времени пребывания программы в монопольном режиме. Если затребованное время исчерпано, а оператор возврата в пользовательский режим еще не был выполнен, программа принудительно переводится в пользовательский режим и выдается диагностическое сообщение.
Оно появляется также и в том случае, если прерывание, заявленное как требующее обработки в реальном времени, поступило, когда программа находилась не в монопольном режиме.
В статье рассматриваются только базовые средства программирования локальной сети. Языки, специально ориентированные на решение робототехнических задач, представляют самостоятельную область исследования.
Основная особенность системы программирования состоит в ее двухуровневой структуре. В отдельные уровни выделены машиннозависимые и машинно-независимые языки. Машинно-независимый язык характеризуется тем, что написанная на нем программа (или компонента программы) может быть исполнена, вообще говоря, на любой ЭВМ сети. В то же время язык машинно-зависимой программы однозначно определяет тип ЭВМ, на которой может выполняться написанная на этом языке программа.
Система программирования построена таким образом, что трансляция всей многомашинной программы осуществляется на одной ЭВМ. Использование различных трансляторов с одного и того же языка (например, ФОРТРАНа), входящих в системы программирования разных ЭВМ (ЕС и СМ), оказалось неоправданным из-за довольно многочисленных различий в диалектах языка.
Если в решении задач используется ЭВМ ЕС, то трансляция и компоновка всей программы проводится на этой ЭВМ. Машинно-зависимые программы представляются совокупностью секций. Каждая секция может быть написана на языке Ассемблера ЭВМ либо ЕС, либо СМ. В состав любой секции могут входить специальные операторы взаимодействия между ЭВМ. Кроме того, в секции, предназначенные для выполнения на ЭВМ СМ, включаются операторы взаимодействия с аналоговой частью и реальной аппаратурой [7].
Единая многомашинная программа обрабатывается претранслятором, в состав которого входит кросс-ассемблер СМ ЭВМ. Он транслирует команды и операторы СМ ЭВМ в операторы порождения констант языка Ассемблера ЕС ЭВМ. Претранслятор вырабатывает листинг GM-программы. После претранслятора программа обрабатывается транслятором с языка Ассемблера ЕС ЭВМ, на выходе которого формируется объектный модуль ЕС ЭВМ и загрузочный модуль СМ ЭВМ. После сборки и загрузки многомашинной программы в память ЭВМ ЕС загруженная программа пересылает в ЭВМ СМ секции, предназначенные для выполнения на машине этого типа.
Машинно-зависимыми являются и программы на ФОРТРАНе. Их можно выполнять только на той машине, на которой выполняются трансляция и сборка программы. Единая программа облегчает организацию взаимодействия между ЭВМ, но в то же время задача контроля за изменениями, вносимыми в программы в процессе моделирования, не решается. В связи с этим в состав системы программирования введен машинно-независимый язык, названный языком компоновки CL [2]. Язык сборки выполняет две роли： используется как универсальный язык Ассемблера и задает структуру про-
граммы. Блоки программы, написанные на языке CL, могут транслироваться в машинные коды ЕС, а также СМ ЭВМ или команды взаимодействия с реальной аппаратурой в зависимости от той ЭВМ, на которой будет выполняться этот блок. То, что CL-программы структурированы по управлению и информационным связям, позволяет организовать строгий контроль изменяемых и вновь вносимых в программу блоков.
Программа на языке CL представляет собой совокупность взаимодействующих блоков. Каждый из них имеет заголовок следующего формата： <имя> BLOCK ((входные параметры)/(выходные параметры>) (параметры настройки). Списки входных и выходных параметров разделены, и запрещено использование одних и тех же имен в обоих списках одновременно. Каждое имя входного и выходного параметра может дополняться указанием его типа. Тип данных используется для контроля за согласованностью. связей входных и выходных данных различных блоков. Параметрами настройки можно задавать назначение блоков на ЭВМ, устанавливать адреса интерфейсных каналов ЭВМ, если соответствующий блок должен взаимодействовать с реальной аппаратурой (натурной частью), определять другие свойства блоков, которые могут изменяться при различных запусках программы.、
Тело блока может содержать вложенные блоки. Терминальные блоки представляют собой либо команды универсального ассемблера (такие блоки являются машинно-независимыми), либо секции одного из ассемблеров ЕС и СМ ЭВМ.
Таким образом, язык CL может задавать структуру и машиннозависимых программ. Именно поэтому он рассматривается как язык более высокого уровня, а транслятор с него выделяет машиннозависимые блоки и передает их на вход соответствующего транслятора.
Аналогично системе программирования ЕС ЭВМ построена си- ；стема программирования СМ ЭВМ. Для нее разработан транслятор 「、с языка РЕФАЛ. Это дает возможность ввести кросс-транслятор с I ассемблером в систему программирования СМ ЭВМ и использовать его (с небольшими модификациями) для получения загрузочных модулей для ЭВМ типа «Электроника-60».
Помимо системного программного обеспечения, были разработаны методика и прикладное программное обеспечение интерактивно- 工 го режима полунатурных экспериментов с машинной регистрацией, обработкой и наглядным представлением экспериментальных данных .и результатов моделирования. Например, при решении типичной 马 задачи определения параметров динамической модели манипулятора имеется возможность формировать требуемый закон изменения каж- ;дой степени подвижности н реальном времени и подавать обеспе- :чивающее его напряжение в качестве уставки на следящий привод : реального манипулятора. Фактические изменения степеней подвижности и соответствующие им управляющие напряжения, воздействующие непосредственно на электродвигатели приводов, оцифровываются и запоминаются л цифровой части вычислительной системы.
Далее эти управляющие напряжения можно многократно подавать в требуемом масштабе времени на динамическую модель манипулятора. На основании сравнения выходных сигналов модели и самого манипулятора при одинаковых входных сигналах выполняется настройка параметров модели, ведущая к уменьшению рассогласования. В процессе настройки может активно участвовать человек-оне- ратор, наблюдающий на многолучевом осциллографе ход всех исследуемых кривых. При желании можно легко повторить эксперимент Для того же самого или другого движения манипулятора, провести обработку данных, зарегистрировать требуемые сигналы и т. д.
В результате полунатурных экспериментов, проведенных па описанном моделирующем комплексе, был разработан ряд алгоритмов работы основных функциональных подсистем сенсорно-управляющей системы адаптивного робота, предназначепного для упорядочения неориентированных деталей. Эти алгоритмы, как правило, ориепти- рованы на аппаратно-программную реализацию, причем локальная сеть позволяет естественным образом исследовать вопросы рационального распределения функций между аппаратными и программными средствами. Отработанные в полунатурных экспериментах модели разрабатываемых подсистем могут служить непосредствен- ньтми прототипами специализированных гибридных устройств на базе микро-ЭВМ.
Разработанные алгоритмы ввода и анализа сенсорной (в первую очередь зрительной) информации позволяют в реальном времени выделять контуры объектов на силуэтных изображениях, осуществлять классификацию этих объектов в соответствии со списком, указанным при обучении, определять координаты их геометрических центров, а также ориентацию на плоскости [8]. Достоинствами этой системы являются также автоматический выбор порога квантования видеосигнала и существенная разгрузка цифрового процессора при выполнении операций, связанных с вводом и предварительной обработкой изображений.
Метод формирования движений манипуляционного робота в незнакомой среде, не требующий предварительного анализа вида и расположения препятствий, описан в публикациях [9—11]. Этот метод основан на построении пути обхода запретных зон в пространстве шарнирных углов и требует лишь локальной информации о наличии помехи движению в некоторой окрестности робота. В свободной зоне траектория движения строится как решение дифференциальных уравнений, минимизирующее рассогласование между заданным и текущим состояниями робота. При обнаружении препятствий правая часть этих уравнений видоизменяется так, чтобы обеспечить в соответствии с разработанными алгоритмами обход как выпуклых, так и невыпуклых запретных областей в сечениях пространства шарнирных углов без застревания в тупиках. Формирование специальной штрафной функции выполняется аналоговой частью вычислительной системы, а цифровая часть используется для управления логикой изменения правой части уравнений генератора движении по сигналам датчиков приближения к препятствиям.
Одновременно с изменениями шарнирных углов формируются и изменения их производных до требуемого порядку что облегчает отработку задаваемых движений эффекторами робота. При этом можно воспользоваться комбинированной системой управления [3, 40j, в которую включается динамическая модель, позволяющая в значительной мере учесть динамику манипулятора и приводов и использовать в контурах обратных связей сравнительно простые регуляторы, на которые возлагается лишь коррекция программного управления.
Многочисленные полунатурпые эксперименты ва рассмотренном моделирующем комплексе подтвердили перспективность использования локальных сетей для систем моделирования, эффективность созданных алгоритмов и большое удобство работы с системным и прикладным программным обеспечением при исследовании и построении систем управления роботов.
ЛИТЕРАТУРА'
I
Казьмин А.必.，Менн А. А., Пономарев Н. В., Лополитов В. Я. Автоматизация полунатурного моделирования на многомашинных комплексах.— Автоматика и телемеханика, 1982, № 7, с. 157—164.
Казьмин А. И., Менн А. 4, Пономарев Н, В. Программное обеспечение локальной сети ЭВМ, взаимодействующей с реальной аппаратурой.——В кн.: Применение гибридных вычислительных систем для моделирования и автоматизации научных исследований Под. ред. А. И. Казьмина. М., 1982, с 87—105. (Вопр. кибернетики НС по комплексной проблеме «Кибернетика»).
Коган Б.兄.,Петров А. А. Гибридные вычислительные системы и модели- 'рование роботов.— В кн.: Научные проблемы робототехники. М.: Наука, 1980, с. 34-47.产
Попов Е. П., Верещагин А. Ф., Зенкевич С. Л. Манипуляционные роботы: динамика и алгоритмы. М.: Наука, 1978, 400 с.
Манолов О. S., Пономарее Н. В., Ко2aH Я. С. Пакет программ для получения динамической модели, используемой в комбинированной системе управления манипуляционным роботом.— В кн.: Вычислительные процессы : в гибридных ЭВМ и комплексах: Препр. Ин-та электродинамики АН УССР :№ 231. Киев, 1980, с. 9—11.
Казьмин А.必.,Менн А. А. Система автоматизации программирования ГВС ;«Русалка» для полунатурного моделирования.— В кн.: Автоматизация программирования аналого-цифровых и микропроцессорных систем. М.： МДНТП, 1982, с. 30—36.
Дудкин М. В., Казьмин А. И., Менн А. А. Гибридный АССЕМБЛЕР. Гибридный диалоговый отладчик. Математическое обеспечение ГВС «Русалка». М.: Ин-т проблем управления, 1980. 63 с.
Кузьмин С. 4, Петров А. А. Алгоритмы классификации и определения параметров силуэтных изображений в системе технического зрения робота.™ В кн.: Проблемы машинного видения в робототехнике. М.: Ин-т прикл. математики им. М. В. Келдыша АН СССР, 1981, с. 140—151.
Тулепбаев В. Б. Формирование программных движений манипуляционного робота.——В кн.: Проблемы управления в технике, экономике, биологии. М.: Наука, 1981. с. 191—196.
Petrov А. 4, Sirota /. М. Control of a Robot-Manipulator with Obstacle Avoidance under little Information about the Environment: Prepr. of the 8th triennial World Gongr. of IFAG. Kyoto, 1981, vol. 14, p. 54—59.
Петров А. А. Комбинированное управление действиями манипуляционного робота в сложной среде.— PocitaCe a umela intelligencia (Comput. and Artificial Intelligence), 1982, vol. 1, N 1, p. 83—96.
УДК 621.865■''
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ СИСТЕМЫ ГРУППОВОГО УПРАВЛЕНИЯ ЦИКЛОВЫМИ РОБОТАМИ
3. Рахманкулов, Д. В. Сатаров
Системы управления современных роботов, как правило, разрабатьь ваются для управления одним, реже двумя роботами (например, СУ-202М). Система управления может быть создана по принципу жесткой логики или как устройство с хранимой в памяти программ мой. Первое направление, как показывают тенденции развитая, все более ориентируется на конкретное применение, второе — позволяет создавать устройства с большей универсальностью и гибкостью. При этом применение микропроцессорной техники способствует сни- ярению их стоимости. Быстродействие и производительность микропроцессоров и микро-ЭВМт которые быстро совершенствуются, становятся достаточными для осуществления управления группами роботов.
Такое построение системы имеет преимущества, когда роботы расположены вблизи друг от друга и технологический процесс требует их совместной работы. Задачи синхронизации и обмена данными при формировании команд управления проще решать в рамках одного устройства управления.
Вторым и особенно важным преимуществом такого построения системы управления является возможность формирования программного обеспечения, которое позволило бы при необходимости быстро изменять его параметры и перестраивать систему на работу с новой группой деталей или другими технологическими процессами 11].
Коррекция параметров может быть осуществлена обслуяшваю- щим персоналом участка с помощью видеотерминала, специального пульта, вводом с гибкого магнитного диска после подготовки информации на другой ЭВМ.
Структура аппаратной части. Система строится на базе микро- ЭВМ (например, СМ-1800) или микроконтроллера, использующих в качестве центрального процессорного элемента микропроцессо р КР580ИК80А и имеющих более 8K байт оперативной памяти.
Основными элементами одного из вариантов системы управления роботами (рис. 1) являются:
микро-ЭВМ СМ-1800 с видеотерминалом и внешним запоминающим устройством (ВЗУ) на гибких магнитных дисках；
иптсрфейс (радиальный, последовательный);
схема приемника-передатчика последовательного интерфейса, согласованная со схемой сильноточных тиристорных коммутаторов;
цикловые роботы.
Особенностью системы является то, что команды управления всеми роботами и ответные сигналы передаются по одной слаботочной
линии интерфейса, максимальная длина которой может составлять 500 м, а токи управления роботами формируются в схеме сильно- точных коммутаторов, которая располагается в непосредственной близости от роботов. Таким образом, микро-ЭВМ и ее периферийные устройства (ВЗУ, видеотерминал и др.) могут быть вынесены в отдельное помещение.
Общая оргаяизация программного обеспечения. Программа управления группой роботов достаточно сложна: в изменяющейся последовательности происходит генерация команд управления, анализируются ответные сигналы, на основании которых генерируются следующие управляющие команды.
В условиях производства необходимо предусмотреть возможность вмешательства оператора в случае сбоев, неполадок, ошибочных ситуаций в ходе работы системы. Еще лучше, если система будет сама правильно реагировать на некоторые непредвиденные ситуации.
Все эти процессы должны протекать в реальном масштабе времени, т. е. время также является параметром системы, что накладывает до по л нительные трудности на этапе создания и отладки программного обеспечения [2].
В связи с этим целесообразно создавать программное обеспечение системы на базе универсального монитора (или диспетчера) режима реального времени [3]. Общая структура программного обеспечения системы показана на рис. 2.
Такой способ создания программного обеспечения допускает большую автономность прикладных программных компонентов на этапе отладки. Разработчик может уделять меньше внимания взаимосвязям между модулями. И уже на последнем этапе отлаженные программы связываются в систему. Реализует механизм обслуживания программных модулей в системе монитор реального времени.
Системный монитор позволяет обслуживать программы в двух режимах: реального времени и разделения времени. В первом случае механизм обслуживания программ строится на основе фиксиро- ванпых приоритетов, которые присваиваются программам реального времени — модулям системы. В течение определенного периода времени обслуживается программа с наивысшим приоритетом, а затем монитор запрещает все прерывания и проверяет, не появились ли программы с более высоким приоритетом в очереди программ, ожидающих обслуживания. Продолжительность такого анализа составляет для данного монитора реального времени и микро-ЭВМ СМ-1800 от 0,2 до 1 мс, что вместе с выбранным квантом времени обслуживания программ определяет реакцию системы на поступающую информацию.
В режиме разделения времени, который включается только тогда, когда очередь программ, ожидающих обслуживания в реяшме реального времени, пуста, обслуживание осуществляется по принципу «первый пришел — первым обслужен».
Монитор реального времени. Монитор занимает приблизительно 1К байт оперативного запоминаютцего устройства (ОЗУ) для своих программ и еще приблизительно 1К байт для таблиц и данных.
ВЗУВЗУК роботамК роботамРис. 1. Структурная схема аппаратной части системы управления роботамиРис. 1. Структурная схема аппаратной части системы управления роботами
ВЗУ
ВЗУ
К роботам
К роботам
Рис. 1. Структурная схема аппаратной части системы управления роботами
Рис. 1. Структурная схема аппаратной части системы управления роботами
Программа изменения параметров системы
Программа формирования команд управления
Программа связи с роботами
Программа связи с ВЗУ
Монитор реального времени (диспетчер)
Программа связи с видеотерминалом
Программа формирования команд управления в ошибочных ситуациях
Рис. 2. Структура программного обеспечения системы управления роботами
Возможности монитора:
обслуживание программ реального времени в заданный момент времени;
обслуживание программ реального времени с заданной частотой;
реализация задержки до начала обслуживания программ реального времени;
немедленное начало обслуживания программы реального времени без задержки;
прерывание программ реального времени；
обнуление статуса прерывания программ реального времени;
изменение начального адреса программы реального времени; создание новой программы реального времени;
занесение программы реального времени в очередь программ режима разделения времени;
передача управления оператору программы, стоящему следующим после вызова монитора реального времени (продолжение обслуживания программы, которая вызвала монитор).
Программы взаимодействуют с монитором реального времени посредством специальных команд.
Каждая программа, которая работает под управлением монитора реального времени, имеет свое стандартное описание — дескриптор, куда заносятся основные параметры программы. Все дескрипторы имеют длину 32 байта и располагаются строго последовательно в ОЗУ микро-ЭВМ. Совокупность дескрипторов образует таблицу основных параметров программ.
Когда нужно, чтобы программа реального времени начала выполняться, она активизируется соответствующей системной командой и помещается в очередь в соответствии со своим приоритетом вме-
Таблица 1. Структура дескрипторов
Позиция
Номер байта
Содержимое
Позиция
Номер байта
Содержимое
Ml
М2
М3
г
Г М5
1
00
01
02
03
Бит 0
Бит 1
Бит 2
Бит 3
Бит 4
Бит 5
Бит 6
Бит 7
04
05
06
07
Адрес следующего дескриптора в очереди
Приоритет программы Статус регистра Программа обслуживается
Программа цреяедевре- менно снята с обслуживания
Определен период времени
Программа помещена в очередь режима-реального времени Обслуживание программы прерывалось Программа ожидает обслуживания Программа помещена в очередь режима разделения времени Используется статус регистра 2 Время до начала следующего обслуживания
Интервал времени между прекращением обслуживания программы и началом следующего обслуживания
Мб
М7
М8
М9
М10
МИ
М(2
М13
М14
М15
М19
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
31
Адрес входа в программу
Адрес входа в программу после прерывания
Число обслуживании программы
Общее время обслужи- ьанйя
Максимальный интервал времени обслуживания программы на одном шаге
Адрес первого байта 'текста программы Адрес последнего байта текста программы Статус регистра 2 Указатель стека
Дополнительные байты
сте с другими программами реального времени. По сути, очередь образуют дескрипторы программ. В первых двух байтах (позиция Ml) содержится указатель (адрес) на дескриптор следующей программы более низкого приоритета (табл. 1).
Выполнение программы может продолжаться до тех пор, пока она не остановится, обратившись к соответствующей системной команде останова, или не исчерпает отведенный ей лимит времени. Если такое произойдет, то предусмотрено обслуживание программ, исчерпавших свой лимит времени в режиме разделения времени, но выполнение их начнется только тогда, когда очередь программ реального времени опустеет.
Период обслуживания программы в режиме разделения времени
определяется позицией М10 дескриптора, но если и этот интерва. окажется недостаточным, то значения регистров сохраняются в сто ке, а указатель стека сохраняется в дескрипторе. Когда обслужи вание программ возобновляется, указатель стека извлекается из со ответствующих байтов дескриптора и значения регистров восстанавливаются.
Используя такой механизм обслуживания программ монитора реального времени, можно построить программное обеспечение для управления группой роботов.
Программа управления роботами в непредвиденных ситуациях, В ходе работы системы могут возникнуть ситуации, которые приводят к поломке оборудования, травмам обслуживающего персонала. Часть таких ситуаций можно предусмотреть заранее. Специальная программа управления системой в этих случаях инициализируется после анализа ответных сигналов либо происходит останов и система ожидает команды оператора о переходе в один из следующих подрежимов:
продолжение работы системы (управление возвращается в программу формирования команд для роботов, задержка учитывается)： запрещается внссепие новых деталей в систему, продолжени(^ обработки деталей, уже внесенных в обрабатывающую линию;
управление роботами передается оператору;
останов.
Система управления роботами для обслуживания гальванической линии* Гальваническая линия состоит из ваян, заполненных растворами. Сверху над ваннами проложены рельсовые пути, по которым движутся цикловые роботы. Детали, проходя технологический процесс, опускаются в свободные позиции соответствующих ванн и по истечении определенного интервала времени вынимаются и транспортируются дальше (одновременно в одной ванне может быть расположено несколько деталей).
В случае крупносерийного производства ванны заполняются растворами так, чтобы перемещение деталей происходило последовательно в яаправлепии от начала линии к ее концу. С учетом про- изводительпости роботов и необходимых задержек вычисляется минимальный допустимый интервал времени между загрузками дета- ле说，который и определяет пропускную способность линии.
В случае мелкосерийного производства и частой смепы выпускаемых деталей возникает необходимость перестройки хода технологического процесса. Часто менять содержимое ванн нерационально, а проще рассчитать новый путь прохождения у?ке заполненных ванн.
Команды управления роботами. Каждое управляющее слово имеет стандартный формат 2 байта. В управляющих словах используется смешанное кодирование команд:
(1 (2 (3 (4 (5 (6 (7 (8)
(9 (10 (И (12 (13 (14 (15 (16)
Коды команд управления представлены в табл 2
Таблица 2. Значение команд управления
ЗначениеЗначениеНомер бита
Значение
Значение
1-345-67-Х9-1314—161-345-67-Х9-1314—16Номер робота в системе счисления по основанию 2
1-3
4
5-6
7-Х
9-13
14—16
1-3
4
5-6
7-Х
9-13
14—16
Наличие 《1» означает движение по рельсовым путям к ванне с номером, который указан в позициях (9-13) и (14-16) 《10》一 опускание схвата в ванну 《01» - подъем схвата из ванны «10» 一 захват детали «01» - опускание детали
Номер ванны в системе счисления по основанию 2
Номер позиции в ванне в системе счисления по основанию 2
Серия команд управления для каждого из роботов передается по радиальному последовательному интерфейсу,z и после их выполнения устройство сопряжения выдает ответные сигйалы.
Сория команд содержит информацию об одиночных тактах движения для каждого из роботов. Если к микро-ЭВМ приходит сообщение, что команда не выполнена, либо сообщепие вообще от- сутствуст, то на экране видеотерминала высвечивается содержимое серии команд и управление передается программе управления в ошибочных ситуациях.
'ЛИТЕРАТУРА
『1. Макаров И. М., Рахманкулов В. 3. Групповое управление роботами-манипуляторами с распределенно-централизованной организацией обработки ин- :: формации.— В кн,: Микропроцессорные системы управления в робототех- 金 нике. М.: Наука, 1984, с. 35—45.
В 2. Мартин Дж. Программирование для вычислительных систем реального 厂 времени. М.: Наука, 1975. 359 с.
• 3. Шоу А. Логическое проектпроватше операционных систем. М.: Мир, 1981. 360'с.
7 АЛГОРИТМЫ
4 УПРАВЛЕНИЯ РОБОТАМИ
УДК 621.865.8.001.1
СИСТЕМА УПРАВЛЕНИЯ РОБОТОМ КАК КОНЕЧНЫЙ АВТОМАТ
Л. Зенкевич, А. В. Назарова
Обучение и последующее управление роботом представляет собой процесс, в течении которого человек-оператор формирует программу движения и выдает команду на ее исполнение, используя те или иные задающие устройства. В качестве такого задающего устройства может выступать либо обычный алфавитно-цифровой дисплей (в исследова- тельских или инструментальных робототехнических комплексах), либо функциональный пульт (в промышленных комплексах), снабженный набором кнопок, переключателей, а также некоторым индикаторным устройством. Кнопки пульта позволяют оператору вводить команды, переключатели — данные, а индикатор служит как для осуществления диалога оператор—робот в процессе обучения, так и для выдачи информации о прохождении исполнения сформированного задания. Возможная структурная схема такой робототехнической системы показана на рис. 1.
Команды, которые вводит человек-оператор, должны соответствовать определенным правилам, характеризующим входной язык обучения и управления, порожденный некоторой грамматикой G. Рассмотрим один из подходов к организации управления манипуляционным роботом на основе представления всей системы обучения и управления как конечного автомата.
Простая система управления. Прежде чем перейти к формализации грамматики входного языка, познакомимся в качестве иллюстрации с гипотетической системой позиционного управления роботом, включающей в себя, в частности, пульт, позволяющий вводить с помощью кнопок следующие команды: АВТОМАТ (а), ШАГ (ш), ОБУЧЕНИЕ (о), ВВОД (в), ЗАПОМНИТЬ (з), СТОП (с), (в скобках даны сокращения, используемые ниже). Пусть каждая точка позиционирования, в которую требуется перевести схват манипулятора, характеризуется набором чисел, однозначно определяющих конфигурацию манипулятора, а также скоростью перемещения охвата к этой точке. Будем этот набор данных называть кадром.
Работа системы с точки зрения пользователя заключается в следующем. Нажатие кнопки «ОБУЧЕНИЕ» переводит систему в режим обучения, в котором оператор может некоторым образом выставить требуемую конфигурацию манипулятора и, нажав кнопку《ЗАЛОМ-
ПИТЬ», записать текущее состояние исполнительного механизма в требуемом формате в кадр. Для окончательного формирования кадра вводится с помощью переключателей и кнопки «ВВОД» значение скорости. Кнохтки «АВТОМАТ» и «ШАГ» обеспечивают соответственно непрерывное и пошаговое исполнение сформированной программы движения. Кнопка «СТОП» аварийно прерывает работу системы.
Набор приведенных выше команд отражает потребности оператора, связанные с обучением и управлением манипуляционным роботом, в общих чертах совпадает с командами существующих в настоящее время пультовых систем управления.
Рис. 1. Структурная схема системы управления с функциональным пультом в качестве задающего устройстваРис. 1. Структурная схема системы управления с функциональным пультом в качестве задающего устройства
Рис. 1. Структурная схема системы управления с функциональным пультом в качестве задающего устройства
Рис. 1. Структурная схема системы управления с функциональным пультом в качестве задающего устройства
7={а, ш, о. в, з, с}N= {КОМАНДА, АВТОМАТ, ШАГ, ОБУЧЕНИЕ, СКОРОСТЬ}7={а, ш, о. в, з, с}N= {КОМАНДА, АВТОМАТ, ШАГ, ОБУЧЕНИЕ, СКОРОСТЬ}5= КОМАНДАР={КОМАН〃АКОМАНДАКОМАНДАКОМАНДААВТОМАТШАГ5= КОМАНДАР={КОМАН〃АКОМАНДАКОМАНДАКОМАНДААВТОМАТШАГ-а АВТОМАТ-m ШАГ-о ОБУЧЕНИЕ-с КОМАНДА-с КОМАНДА f m ШАГ-а АВТОМАТ-m ШАГ-о ОБУЧЕНИЕ-с КОМАНДА-с КОМАНДА f m ШАГ
7={а, ш, о. в, з, с}
N= {КОМАНДА, АВТОМАТ, ШАГ, ОБУЧЕНИЕ, СКОРОСТЬ}
7={а, ш, о. в, з, с}
N= {КОМАНДА, АВТОМАТ, ШАГ, ОБУЧЕНИЕ, СКОРОСТЬ}
5= КОМАНДАР={КОМАН〃АКОМАНДАКОМАНДАКОМАНДААВТОМАТШАГ
5= КОМАНДАР={КОМАН〃АКОМАНДАКОМАНДАКОМАНДААВТОМАТШАГ
-а АВТОМАТ
-m ШАГ
-о ОБУЧЕНИЕ
-с КОМАНДА
-с КОМАНДА f m ШАГ
-а АВТОМАТ
-m ШАГ
-о ОБУЧЕНИЕ
-с КОМАНДА
-с КОМАНДА f m ШАГ
Грамматика языка управления. Уже приведенный пример простой пультовой системы демонстрирует необходимость следования некоторым правилам при вводе оператором команд в процессе обучения и управления роботом, которые можно рассматривать как правила построения синтаксически верных конструкций входного языка системы управления E(G)，порожденного некоторой грамматикой G.
Напомним, что грамматикой G называется четверка (Т, N, В, Р), где Т — множество терминальных символов; N — множество нетерминальных символов; B^N — начальный нетерминальный символ; Р — множество правил подстановки (продукций) [1, 2]. Тогда порождаемым грамматикой языком E(G) называется множество цепочек терминальных символов, выводимых из 5 с помощью продукций Р.
Будем рассматривать каждую команду оператора (или соответствующую кнопку пульта управления) как терминальный символ из 7, а последовательность команд — как слово, порожденное грамматикой G. Тогда для рассмотренного выше примера системы управления грамматика входного языка будет иметь следующий вид:
ШАГ —а АВТОМАТ
ШАГ + с КОМАНДА
ОБУЧЕНИЕ -^з СКОРОСТЬ
ОБУЧЕНИЕ - с КОМАНДА
ОБУЧЕНИЕАВТОМАТ
СКОРОСТЬ -в ОБУЧЕНИЕ СКОРОСТЬКОМАНДА}.
■ Заметим, что наличие рекурсии в правилах подстановки для нетерминалов ШАГ и ОБУЧЕНИЕ позволяет легко осуществить циклически повторяемые операции, в данном случае — это пошаговое нснол- нение программы движения и запоминание параметров точек пози- цпонирования в режиме обучения.
Примером допускаемых грамматикой цепочек (или последовательностей вводимых оператором команд) являются, например, следующие: «ас» (автоматическое исполнение сформированной ранее программы движения); «шшша» (обход трех точек позиционирования в шаговом режиме и дальнейшее исполнение программы в автоматическом режиме); «озвзва» (формирование программы движения, состоящей из двух точек, и ее исполнение). На рис. 2 показана сеть переходов [3], графически иллюстрирующая правила подстановки Р, и представляющая собой ориентированный граф, узлы которого соответствуют нетерминальным символам, а дуги ——терминальным. На рис. 3 показаны деревья грамматического разбора слов, приведенных выше в качестве примеров допускаемых грамматикой последовательностей.
' Обратим теперь внимание на следующее обстоятельство. Не каждый язык, порожденный контекстно-свободной грамматикой, приемлем для систем управления, использующих функциональный пульт в качестве задающего устройства. Действительно, специфической особенностью рассматриваемых систем является невозможность возвратов по неуспеху, поскольку система должна адекватно реагировать на каждую введенную человеком-оператором команду (т. е. на появление соответствующего терминального символа), не дожи^ даясь ввода следующих команд. Например, грамматика, содержащая продукции вида
ЕВ
BfgD
С f hE,
где i, g, h^T — терминальные символы, а Л, В, С, О, Е — нетерминальные символы, не может служить порождающей грамматикой для языка системы управления с пультом в качестве задающего устройства (на рис. 4 показан фрагмент соответствующей сети переходов), поскольку на появление во входной последовательности символа (или команды) / система не может соответствующим образом отреагировать до тех пор, пока не появится следующий за i символ (в рассматриваемом случае это символы g или Д).
Для того чтобы грамматика могла порождать устраивающий нас язык, достаточно, чтобы все продукции удовлетворяли следующим двум условиям:
Рис. 2.Рис. 2. Граф переходовРис. 2.Рис. 2. Граф переходовссллЕЕконечного автомата для простой системы сконечного автомата для простой системы сРпс. 4.функциональнымРпс. 4.функциональнымпультом в качестве задающего устройствапультом в качестве задающего устройстваРис. 4. Пример грамматики, недопустимой в качестве задающего устройстваРис. 4. Пример грамматики, недопустимой в качестве задающего устройствадля языка системы управления с пультомдля языка системы управления с пультомааРис. 3. Грамматический разбор слов а — «ас»; б — «шшша» ； в — «озвзва»Рис. 3. Грамматический разбор слов а — «ас»; б — «шшша» ； в — «озвзва»66КОМАНДАКОМАНДА
Рис. 2.
Рис. 2. Граф переходов
Рис. 2.
Рис. 2. Граф переходов
с
с
л
л
Е
Е
конечного автомата для простой системы с
конечного автомата для простой системы с
Рпс. 4.
функциональным
Рпс. 4.
функциональным
пультом в качестве задающего устройства
пультом в качестве задающего устройства
Рис. 4. Пример грамматики, недопустимой в качестве задающего устройства
Рис. 4. Пример грамматики, недопустимой в качестве задающего устройства
для языка системы управления с пультом
для языка системы управления с пультом
а
а
Рис. 3. Грамматический разбор слов а — «ас»; б — «шшша» ； в — «озвзва»
Рис. 3. Грамматический разбор слов а — «ас»; б — «шшша» ； в — «озвзва»
6
6
КОМАНДА
КОМАНДА
ОБУЧЕНИЕ
Рис. 3
ОБУЧЕНИЕ
АВТОМАТ
альтернативные замены одного и того же символа должны начинаться с различных терминальных символов:
М)亠 2M 产 ，
правая часть каждой продукции должна начинаться терминалом: если М)г、ак то *7(6日7贝).
Такие грамматики называются 5-грамматиками [1]. Заметим, что рассмотренный выше в качестве примера язык управления порожден 5-грамматикой.
Система управления как конечный автомат. Проектирование алгоритмов, осуществляющих грамматический разбор входных последовательностей, представляет собой сложную задачу [1, 2], кроме того, сами программные модули, реализующие грамматический разбор, довольно громоздки, что делает практически невозможным их использование в условиях ограниченной памяти ЭВМ (алгоритмы грамматического разбора составляют основную компоненту трансляторов с языков программирования). Второе условие эквивалентно тому, что входной язык является регулярным (т. е. порожденным грамматикой, все продукции которой имеют вид ^-^^2)ит следовательно, может быть распознан конечным автоматом [1], реализация которого существенно проще, чем других распознавателей.
Конечный автомат К есть пятерка (5, So,久 Р,尸)，где 5 — конечное множество состояний автомата; S^S ——начальное состояние; Т — конечный входной алфавит; Р — отображение множества SX7 в S, определяющее правила перехода автомата из одного состояния в другое как функцию текущего состояния и входного символа; F^S — множество заключительных состояний автомата [3, 4].
Для того чтобы получить описание конечного автомата, распоз^ нающего регулярное множество, порожденное описанной выше грамматикой, необходимо выполнить следующие операции:
считать терминальное множество грамматики входным алфавитом автомата；
считать нетерминальное множество грамматики множеством состояний автомата, а начальный символ — начальным состоянием;
включить в число правил перехода автомата переход из состояния А в состояние В по входу 右 если грамматика содержит продукцию A—tB.
Тогда применительно к рассмотренной системе управления манипуляционным роботом атрибуты конечного автомата выглядят следующим образом:
S={KOMAHUA, АВТОМАТ, ШАГ, ОБУЧЕНИЕ, СКОРОСТЬ} &=КОМАНДА
Т={а, ш, о, в, з, с}*
Правила перехода Р можно представить в виде графа (он совпадает с графом, изображенным на рис. 2). Поскольку цепочки входных символов не имеют признака окончания, все состояния являются допустимыми, т. е. F=S.
Расширенный конечный автомат. Использование формализма аппарата конечных автоматов в том виде, в каком он здесь был сформулирован, для некоторых прикладных задач бывает неудобно. Действительно, рассмотрим такую ситуацию, когда один из параметров, характеризующих точку позиционирования, например скорость, остается неизменным для всех точек формируемого задания, хотя и может меняться от одного задания к другому. Тогда целесообразно определить этот параметр в самом начале процесса обучения, а не вводить его для каждой точки позиционирования отдельно. Такая система умолчаний бывает чрезвычайно удобна, особенно для систем, характеризующихся большим количеством параметров, описывающих точку позиционирования, ввод которых существенно увеличивает затраты времени на обучение, в то время как использование системы умолчаний значительно повышает эффективность процесса обучения. Непосредственное использование сформулированного выше подхода приводит к необходимости работы с языками, порожденными ^<онтекстно-зависид<Ь1м;И грамматиками. Действительно, некоторые j продукции, определяющие грамматику, в этом случае будут иметь следующий вид:
pysA^p^stB p^A-^p^tC, где s — сентенциональная форма.
Таким образом правила подстановки будут зависеть от того, какой терминальный символ （р】или р?） вводился на этапе формирования умолчаний.
Известно, что работа с контекстно-зависимыми грамматиками существенно затруднена. Воспользуемся тогда следующим подходом. Введем в описание конечного автомата вектор переключателей П= （ль л2,..., лп） с целочисленными компонентами. В этом случае формальное описание расширенного конечного автомата будет выглядеть следующие образом. Расширенным конечным автоматом К назовем шестерку 京=（S, S。，П, 7,尸，F）, где S — конечное множество состояний автомата; So^S начальное состояние; П — вектор переключателей с целочисленными компонентами; Т — конечный входной алфавит; Р — отображение множества SXIIXT в S;歹三SXII —мно- жество заключительньгх состояний автомата. Заметим, что одним из отличий такого конечного автомата от обычного является расширение области определения отображения Р.
Применим этот подход к рассмотренной системе управления с функциональным пультом в качестве задающего устройства. Пусть переключатель л принимает два значения:
（0, если скорость вводится явно,
” —[1, если скорость вводится ло умолчанию.
Тогда расширенный конечный автомат может быть описан еле- дующим образом:
S= {КОМАНДА, АВТОМАТ, ШАГ, ОБУЧЕНИЕ, СКОРОСТЬ}
H={jt}
50=КОМАНДА 7={а, пт, о, в, з, с] при графе переходов,
представленномпредставленномнанарационной системы, функционирующих оператор-робот.рационной системы, функционирующих оператор-робот.рис. 5.
представленном
представленном
на
на
рационной системы, функционирующих оператор-робот.
рационной системы, функционирующих оператор-робот.
Пример реализации. Изложенный подход был использован при ； разработке программно- 4： го обеспечения систе- -1 мы управления с пуль- 1 том в качестве задаю- : щего устройства, а так- же при реализации не- | которых модулей спе- | циализированной one- j в условиях развитого диалога |
В систему управления с функциональным пультом, реализованную на базе ЭВМ «Электроника-60», входили пульт обучения, со- , держащий 16 кнопок (т. е. оператор мог ввести 16 команд), три ； 10-позициоиных переключателя для ввода данных в диапазоне О— 999, а также индикационное устройство, позволяющее выводить строку из 16 символов. Эквивалентный конечный автомат мог находиться в 35 состояниях. Каждая точка позиционирования характеризо- валась шестью координатами и четырьмя параметрами, три из которых вводились с использованием системы умолчаний (предварительной настройки автомата).
Данные, характеризующие точку позиционирования и последовательность, в которой они проходятся манипулятором, разделены, ^fro обеспечивает более эффективное редактирование и отладку программы движения робота. Для записи информации о последовательности прохождения точек позиционирования разработан скобочный метод, суть которого сводится к следующему.
Пусть, например, манипулятор должен обойти следующую последовательность точек: Р2, РЗ, Р4, РЗ, Р4, РЗТ Р4, Р1. Тогда эквивалентная скобочная запись имеет следующий вид: Р2, (РЗ, Р4)3, Р1. Скобки ограничивают циклически повторяемую последовательность, при этом первое число после правой (закрываюпдей) скобки представляет собой лтисло повторов (0 — означает бесконечный цикл). Тогда, например, последовательность (Р5, ((РЗ, Р4)2, Р2,)2, Р1)0 будет обходиться исполнительным механизмом следующим образом: Р5, РЗ, Р4, РЗ, Р4, Р2, РЗ, Р4, РЗ, Р4, Р2, Р1,
Разработанный подход оказалось возможным применить и в более сложных системах. В частности, он был использован при реализации ряда модулей специализированной операционной системы инструментального робототехнического комплекса, связанных с режимом обучения. Единственным отличием от системы управления с функциональным пультом в качестве задающего устройства явилось
некоторое расширение понятия терминального символа, а именно; терминальным символом считалась лоследовательность символов, ограниченная разделителем и интерпретируемая как команда оператора. Заметим, что, вообще говоря, можно предоставить оператору возможность вводить и односимвольные команды, что обеспечило бы полное совпадение с системой управления с функциональным пуль^ том в качестве задающего устройства, однако в этом случае невоз- можно обеспечить хорошую мнемонику команд, что, но нашему убеждению, является чрезвычайно важным для обеспечения высокой эффективности работы оператора.
* * *
Примененный для проектирования программного обеспечения робототехнических систем подход, основанный на представлении системы управления робота как конечного автомата, позволяет:
получить хорошо структурированное программное обеспечение робототехнического комплекса;
обеспечить эффективную реализацию языка обучения и управления в системе с функциональным пультом в качестве задающего устройства;
эффективно и экономно (как с точки зрения быстродействия, так и с точки зрения занимаемой памяти) строить программное обеспечение.
Кроме того, при проектировании программного обеспечения можно воспользоваться результатами теории конечных автоматов, например, получить минимальную реализацию конечного автомата, отбрасывая недопустимые состояния и объединяя эквивалентные.
Полученные на основе теории конечных автоматов условия регулярности грамматики достаточны для того, чтобы порожденный ею язык мог быть языком пультового управления.
Используемый подход позволяет анализировать проектируемые языки обучения и управления роботов и реализовать их распознаватели.
ЛИТЕРАТУРА
Лъюис Ф., Розенкранц Д., Стирнз Р、Теоретические основы проектирования компиляторов. М.: Мир, 1979. 654 с.
Вайнгартен Ф. Трансляция языков программирования. М.: Мир, 1977. 190 с.
Хант Э. Искусственный интеллект. М.: Мир, 1978. 558 с.
Биркгоф Г., Барти Т. Современная прикладная алгебра. М,: Мир, 1976.
400 с.
УДК 007.52
СИНТЕЗ
ПРОГРАММНЫХ КОРРЕКТИРУЮЩИХ ЗВЕНЬЕВ ЦИФРОВОЙ СЛЕДЯЩЕЙ СИСТЕМЫ
ПРОМЫШЛЕННОГО ОКРАСОЧНОГО РОБОТА «КОЛЕР»
В. И. Григорьев, С. А. Чевтаей
Синтез программных корректирующих звеньев цифровой следящей системы промышленного окрасочного робота «Колер)> проводился после изготовления макетного образца робота. В ходе испытаний выяснилось, что использование в ЭВМ заранее намеченного простейшего закона пропорционального управления но отклонению не обеспечивает желаемой точности воспроизведения. Вследствие указанного обстоятельства вся цифровая следящая система, кроме ЭВМ, рассматривалась при синтезе корректирующих звеньев как неизменяемая часть системы.
Функциональная схема цифровой следящей системы одного звена робота показана на рис. 1. Управляющее воздействие, которое должно быть выработано в микро-ЭВМ «Электродика-60)> на основе хранящейся в памятм информации о траектории, заданной при обучении и считанной с модуля текущей координаты (МТК) информации о фактическом положении манипулятора, подается на модуль управления координатой (МУК). Чтение модуля текущей координаты и засылка управляющего воздействия на модуль управления координатой осуществляются по сигналу прерывания от таймера с периодичностью Т0.
Модуль управления координатой состоит из накопителя (реверсивного счетчика) с двумя входами — положительным (от ЭВМ) и -отрицательным (от датчика углового положения) —— и подсоедйттен- ного к его выходу 10-разрядного цифроаналогового преобразователя (ЦАП). Работа накопителя может быть описана следующими уравнениями:
0(方)=0/一(中e)一5),
0/=0二+((1)
при пГ0^К(п+1)Т0 (n==0, 1, 2,...).
Здесь о(力)—выходная величина накопителя в момент времени t; опи — составляющая выходной величины накопителя, соответствующая входу со стороны ЭВМ, в течение интервала времени nTQ^t< < (тг+1) Го； Un — управляющее воздействие, поданное из ЭВМ на модуль управления координатой по 〃-му прерыванию от таймера, т. е. в момент времени 力=тгТо；屮(力) ——фактическое пологкепие манипулятора в момент времени 力；Фо=Ф(О);力=0, п^О — соответствуют началу работы программы воспроизведения.
Выходное напряжение ЦАП усиливается по мощности сервоусилителем и подается на золотник, управляющий подачей масла от 164
гидростанции в гидроцилиндр, который приводит в движение звени
манипулятора.
Датчик углового положения — фотоэлектрического типа, Поразрядный. Однако принятая схема считывания использует его младший разряд для определения направления движения, вследствие чего число уровней отсчета (при движении в одном направлении) соответствует 10-разрядпому датчику, т. е. равно 1024. Тем не менее и качестве сдшш”ы измерения углового положения используется дискрета ll-разрядного датчика. Кроме того, датчики трех наиболее протя- л;онпых звеньев («руки»), в основном определяклцих пространствен
Рис, 1. функцнональная схема гофровой следящей системы одной координаты робота «Колер»
ное положение рабочего органа (распылителя), для уменьшения цены дискреты подсоединены к своим звеньям через редукторы с передаточным отноптением 1 :4. Таким образом, для указанных звеньев цена дискреты равна 360° : 4:2048=0,0439°, а для двух «кистевых» звеньев она равна 360°: 2048=0,1758°.
Синтез программных корректирующих звеньев, т. е. вывод формул, по которым должно рассчитываться в ЭВМ управляющее воздействие, был осуществлен на основе экспериментально определенных динамических характеристик объекта управления, под которым понималась вся внешняя по отношению к управляющей ЭВМ часть цифровой следящей системы (см. рис. 1). Были определены импульсные переходные характеристики объекта управления путем подачи в течение такта времени на модуль управления координатой импульса с амплитудой UQ и регистрации с модуля текущей координаты фактического положения звена манипулятора 屮符；импульсная характеристика для момента времени t^nTo определялась по формуле
(0 (пто)=力无(厶70),
где коэффициент усиления объекта управления
， k^^^—^oyiUo；
нормированная импульсная переходная характеристика
Импульсная характеристика объекта управления является одновременно в силу уравнения (1) переходной характеристикой той
Рис. 2. Импульсные переходные характеристики объекта управления ЦСС первой координаты робота «Колер» при рнзлнпноА амплитуде импульеа и。Рис. 2. Импульсные переходные характеристики объекта управления ЦСС первой координаты робота «Колер» при рнзлнпноА амплитуде импульеа и。7 — 土50； 2 — ±100; 3—±200; 4 — 土300; точки一расчетные значения по формуле (2) при 7，i = 0,77 с, 0,06 с7 — 土50； 2 — ±100; 3—±200; 4 — 土300; точки一расчетные значения по формуле (2) при 7，i = 0,77 с, 0,06 сРис. 3. Структурная схема линейной модели объекта управленияРис. 3. Структурная схема линейной модели объекта управления
Рис. 2. Импульсные переходные характеристики объекта управления ЦСС первой координаты робота «Колер» при рнзлнпноА амплитуде импульеа и。
Рис. 2. Импульсные переходные характеристики объекта управления ЦСС первой координаты робота «Колер» при рнзлнпноА амплитуде импульеа и。
7 — 土50； 2 — ±100; 3—±200; 4 — 土300; точки一расчетные значения по формуле (2) при 7，i = 0,77 с, 0,06 с
7 — 土50； 2 — ±100; 3—±200; 4 — 土300; точки一расчетные значения по формуле (2) при 7，i = 0,77 с, 0,06 с
Рис. 3. Структурная схема линейной модели объекта управления
Рис. 3. Структурная схема линейной модели объекта управления
непрерывной части объекта управления, вхоцом которой служи! выход канала цифрового интегратора сигнала от ЭВМ.
Экспериментально определенные коэффициенты усиления при средней и большей амплитуде импульса близки к единице, а при малых амплитудах — нелинейно зависят от UQ. Типичные нормированные импульсные характеристики первой х^оординаты робота показаны на рис. 2. Факт их различия при разной амплитуде импульса также свидетельствует о нелинейности реального объекта. Там же по казанах расчетные значения, соответствующие переходной характеристике апериодического звена второго порядка:
h^^i-Т,/ (Т.-Т^-е-^-^Т,/ (Т^ТгУе-^ (2) где 1\=0,77 с, Т2^0,06 с постоянные времени. Сопоставление расчетных значений с экспериментальными кривыми показывает, что непрерывная часть объекта управления в линейном приближении может быть описана апериодическим звеном второго порядка.
Тан虹м образом, объект управления можно представить в виде линейной модели (рис. 3), первое звено которой — цифровой интегратор [см. уравнение (1)] со входом только от ЭВМ, второе ——экстра- полятор нулевого поряцка или фиксатор [1, с. 64], третье — апериодическое звено второго порядка.
Найдем дискретную передаточную функцию объекта управления WQ(z):
Так как дискретная передаточная функция непрерывной части объекта управления с экстраполятором пулевого порядка может быть 166
представлена в видепредставлена в виде^„(2)= -^-'■Z —Z -^„(2)= -^-'■Z —Z -QiS + l)(72 + l)QiS + l)(72 + l)%2/(*_7\)%S 十，-%2/(*_7\)%S 十，-I 7W%)I ~7\S+<I 7W%)I ~7\S+<「— 17\ — T2 Z「— 17\ — T2 Z—■ d]—■ d]++厶厶卜卜T1 一 T2 Z — &2T1 一 T2 Z — &2•)=•)=
представлена в виде
представлена в виде
^„(2)= -^-
'■Z —
Z -
^„(2)= -^-
'■Z —
Z -
QiS + l)(72 + l)
QiS + l)(72 + l)
%2/(*_7\)%S 十，-
%2/(*_7\)%S 十，-
I 7W%)
I ~7\S+<
I 7W%)
I ~7\S+<
「— 17\ — T2 Z
「— 17\ — T2 Z
—■ d]
—■ d]
+
+
厶
厶
卜
卜
T1 一 T2 Z — &2
T1 一 T2 Z — &2
•)=
•)=
'(z — di) (z — 〃2)'
где d尸exp(—北/7\),d产ех£(—Т/Тг)、
〃=(%(1-%)—北(1一成))/(7\ -4),
7 T2 (，一。2)办 一 Tl (1 — %)各
то дискретная передаточная функция объекта управления есть
%(z) = "r=T%(z)=%(z) = "r=T%(z)=“Z (z + b)“Z (z + b)(Z — 1)(2 一 d]) (z —厶)(Z — 1)(2 一 d]) (z —厶)(3)(3)
%(z) = "r=T%(z)=
%(z) = "r=T%(z)=
“Z (z + b)
“Z (z + b)
(Z — 1)(2 一 d]) (z —厶)
(Z — 1)(2 一 d]) (z —厶)
(3)
(3)
Зададимся требованиями к качеству управления. Имея в виду практически необходимую точность движения в процессе окраски, а также то обстоятельство, что вследствие нелинейности реального объекта действительная точность будет несколько хуже расчетной при использовании линейной модели, примем для синтеза корректи- рующих звеньев следующие требования к качеству цифровой следящей системы:
максимальная ошибка Ema* при отслеживании гармонического
⑷⑷задающего воздействия вида [2, с. 31] g(M)=gL{ sin (①北典)
⑷
⑷
с амплитудой 4=500 дискрет и круговой частотой sWlc-i в установившемся ре?киме должна быть не более 4 дискрет (на конце «руки» манипулятора это соответствует максимальной ошибке 5 мм при максимальной скорости 610 мм/с);
запас устойчивости должен соответствовать показателю колебательности AfWl,5 [2, с. 40].
С целью достижения заказанных достаточно высоких требований зададимся структурой цифровой следящей системы комбинированного типа (рис. 4), включающей в себя корректирующее звено в разомкнутом контуре (WK(z)) и лоследовательпое коррек тирующее звено в замкнутом контуре W，(z). Задержка между задающим воздействием g и формированием ошибки en^gn-i—фп введена в связи с тем, что вследствие аппаратной реализации управляющее воздействие, вычисленное после n-vo прерывания таймера, засылается на модуль управ- ления координатой по (汽十 1)-му прерыванию, т. е. передаточные функции корректирующих звеньев отличаются от передаточных функций, соответствующих вычислительным формулам, задержкой
на такт:
忆(z) =WJ (z) 明(z) ^W^ (z) L.
Передаточная функция по ошибке цифровой следящей системы принятой структуры записывается, в виде
m — Е6 zr-%K(z)Wo(z)
Эту передаточную функцию можно представить также в виде произведения
❿ g(z)=CV(z)0J(z),
Хл^»СТРУКТУРНаЯ СХеМа ЦИфР0В0Й СлеД^ей системы одной координаты роботаХл^»СТРУКТУРНаЯ СХеМа ЦИфР0В0Й СлеД^ей системы одной координаты робота
Хл^»СТРУКТУРНаЯ СХеМа ЦИфР0В0Й СлеД^ей системы одной координаты робота
Хл^»СТРУКТУРНаЯ СХеМа ЦИфР0В0Й СлеД^ей системы одной координаты робота
передаточных функций по ошибке разомкнутого контура
(5)(5)(6) замкнутым кК(6) замкнутым кКO£(z)=zT—Wn(z)W°(z)
(5)
(5)
(6) замкнутым кК
(6) замкнутым кК
и замкнутого контура
① J(z)=l/(1+ 巾p(z)%°(z)),
а саму ошибку ЦСС в целом 一 как ошибку отработки туром
⑺⑺E^^^[^E^z) ошибки разомкнутого контура
⑺
⑺
EK(z)=dV(z)G(z).(8)
Рассчитаем вначале корректирующее звено в разомкнутом контуре, которое далее будем называть для краткости компенсатором.
Попытаемся определить его передаточную функцию из условия Фек(2)=0, т. е. из условия идеально точного воспроизведения задающего воздействия разомкнутым контуром (с задержкой по времени на одни такт):
(9)(Ю)(9)(Ю)W^{z) Wq(Z)= WrB (z) %г 次0 (z) = z]
(9)
(Ю)
(9)
(Ю)
Из уравнения (9) с учетом выражения (3) получим
U7 в —1— '(2 — 1) (г — %)(z — d^
к (丿—Wo【(z) 一飞z(*+S•
Передаточную функцию (10) можно реализовать наиболее просто с помощью следующей вычислительной формулы:'
,U： ¥ —入Ygn + k (Ygn+i — Ygn) + w (Ygh+i — 2Vgn + Vgn_x) — 6U匿，
(И)
где U^^ ——управляющее воздействие компенсатора, вычисляемое после п-то прерывания таймера; Vgn=gn~gn-i — первая обратная разность задающего воздействия, которая записывается в память системы управления при обучении [3];入=(1—乙一成+&&2)； 卩= = (1—國必)/。； v=did2/a.
На выполнение содержащихся в формуле (11) четырех умножений и шести сложений на микро-ЭВМ «Электроника-60» необходимо 8 мс, что при пяти управляемых звеньях выдвигает требование 70>40 мс. Помимо этого, понадобится время для реализации корректирующего звена в замкнутом контуре и на отработку технологических операций. Таким образом, реализация идеального компенсатора (10) связана предположительно с необходимостью выбора достаточно большого периода квантования по времени. Это весьма нежелательно для работы замкнутого контура, которая будет необходима, поскольку ввиду нелинейности реального объекта управления, неточности оценки его параметров и их изменения во времени рассматриваемый компенсатор не сможет обеспечить на практике нулевую ошибку.
Попробуем упростить компенсатор. Используем тот факт, что Т-^ТХ, Пренебрежем Т2. При 7\=0 имеем
@2=0, а=1—di, 6=0, Х=1, v=0,(12)
n=1/(1一乙)
и алгоритм (10) упрощается до вида
U— = Vgn + 卩(Yg 及十 1 — Vg)(13)
т. е. содержит всего одно умножение и два сложения. Это позволяет уменьшить затраты времени на реализацию компенсатора по сравнению с ранее рассмотренным вариантом в четыре раза.
Примем в качестве алгоритма вычисления управляющего воздействия компенсатора формулу (13), которой соответствует следующая передаточная функция компенсатора:
忆(z)==mz一1) (z一(p(-1)/科)/或(14)
Однако коэффициент ц выберем не по выражению (12), а из условия достижения наивысшего возможного порядка астатизма.
“ Найдем установившуюся ошибку работы только разомкнутого контура при различных задающих воздействиях. Подставляя выражения (3) и (14) в формулу (5), получим следующую передаточную функцию разомкнутого контура по ошибке:
① к (?) = (Z —山)(Z 一 %) 一 %(Z -(卩一1)/伊)(Z + 方).._
£ ( Lz(Z 二必)(Z — d2)*I J
Согласно формуле (8) и теореме о конечном значении [1, с. 42] установившееся значение ошибки разомкнутого контура будет равно
&8 = ?：{W4(IV(z)G(z)}.(16)
Таким образом, для достижения наивысшего порядка астатизма необходимо, чтобы числитель ФЕк(г) (см. выражение (14)) содержал наибольшую возможную степень (z—1), т. е. в данном случае имел бы множитель (z—I)?. Нетрудно убедиться, что при ц—ц*т где
"* =м：北(彳3彳,(储) имеют место следующие соотношения:
(z-或)(z-d2)一也*a(z-(也*-()/n*) (z+b) = (l-也*@) (z-I)*
① J(z) = (l-卩%)① J(z) = (l-卩%)(一)2z (z 一 由)(z — d2)(一)2z (z 一 由)(z — d2)
① J(z) = (l-卩%)
① J(z) = (l-卩%)
(一)2
z (z 一 由)(z — d2)
(一)2
z (z 一 由)(z — d2)
(18)(18)t172 (由一d2)2(2 - I)2
(18)
(18)
(T1 - ?2)2 (( - d1)((一厶)Z(3 —厶)(4-d?)"
Подстановка выражения. (18) в соотношение (16) показывает, чю при ступенчатом задающем воздействии (скачке по положению), т, е. при
Sn = 41 (孔),G (z) = 4z/(z —-1),
и линейном задающем воздействии (скачке по скорости), т. е. при
gn = АгТоп1 (/г), G (z) — АТ7。&；今2 5
установившаяся ошибка равна нулю, а при параболическом задающем воздействии (скачке по ускорению), т. а при
g注= 1/247()2胪(⑺，
G (z) = '12A2T022 (z 十 i)/(z — I)3,
установившаяся ошибка отлична от нуля и равна
% = 42T JTiT 2% = 42T JTiT 2小一金小一金(I — di) (I — ~2)(丁1 — Т2)(I — di) (I — ~2)(丁1 — Т2)
% = 42T JTiT 2
% = 42T JTiT 2
小一金
小一金
(I — di) (I — ~2)(丁1 — Т2)
(I — di) (I — ~2)(丁1 — Т2)
Таким образом, компенсатор с алгоритмом (13) и коэффициентом ц, определенным согласно формуле (17), даже без корректирующего звена в замкнутом контуре обеспечивает астатизм второго порядка цифровой следящей системы с объектом управления, описываемым уравнением (13).
Заметим, что при 7\/7\>4 и Т』Т*Л формула (17) для расчета коэффициента ц* с высокой степенью точности (погрешность менее
0,5%) может быть заменена простой приближенной формулой
И*=(Л+Т2)/Го+О,5.-
Займемся теперь расчетом последовательного корректирующего звена в замкнутом контуре, которое будем называть далее для краткости регулятором.
Из формулы (6) с учетом выражений (5), (7) и (17) имеем
% (z)巾 о ⑶ + 1 =① J(2)G (z)厶总(z)=-
7/2(由一d2)2(3 - 1)2 G(Z)
(^1-Т2)2((一 厶)(4•-d2)z (z - di) (z 一公)е (г),
Подставляя в это выражение
z=(l+队禽/2)/(1一口北/2)(19)
и обозначая
W^)-WA1^W^\
для дискретной частотной характеристики замкнутого контура цифровой следящей системы W(]K), которая при псевдочастоте ^<0,5/70 практически совпадает с круговой частотой (о, получим следующее соотношение:
w °")+1 = [(&一 爲，一:，(1 -办)]та2 *
x (我)中一加争)G (a) / 0 +加要拦含)X
*(1+加寻目)0+加令"(加)■
Возьмем модуль от обеих частей этого уравнения 血,учитывая, что в области низких частот
I 力(队)+141% (九)1,
а также тот факт, что при гармоническом задающем воздействии (4) У (九)| =4, а |^(Д)|=8та.* ——максимальной ошибке при его отработке, получим для модуля частотной характеристики замкнутого контура следующее условие типа запретной области:
尸阿？卜伍一胃；匕露i)，У ”/([，+
,(粤壮V)力%.(2。)
Далее синтез регулятора проводился частотным методом с использованием логарифмических амплитудных (£) и фазовых (р) частотных характеристик (рис. 5).
Объект управления имеет следующую дискретную частотную характеристику, определяемую путем подстановки выражения (19) в
171
Рис. 5. Логарифмические пользуемые при синтезе туреРис. 5. Логарифмические пользуемые при синтезе туреамплитудные L н последовательногоамплитудные L н последовательногофазовые 屮 частотные характеристики, ис- корректирующего звена в замкнутом кои-фазовые 屮 частотные характеристики, ис- корректирующего звена в замкнутом кои-Lhck, i|)hck — нескорректированная цифровая следящая система; Ln*, л^пд — характеристики с ПД-регулятором; Ен — с П-регулятором; I и II— запретные области для амплитудной и для фазовой характеристик соответственноLhck, i|)hck — нескорректированная цифровая следящая система; Ln*, л^пд — характеристики с ПД-регулятором; Ен — с П-регулятором; I и II— запретные области для амплитудной и для фазовой характеристик соответственно
Рис. 5. Логарифмические пользуемые при синтезе туре
Рис. 5. Логарифмические пользуемые при синтезе туре
амплитудные L н последовательного
амплитудные L н последовательного
фазовые 屮 частотные характеристики, ис- корректирующего звена в замкнутом кои-
фазовые 屮 частотные характеристики, ис- корректирующего звена в замкнутом кои-
Lhck, i|)hck — нескорректированная цифровая следящая система; Ln*, л^пд — характеристики с ПД-регулятором; Ен — с П-регулятором; I и II— запретные области для амплитудной и для фазовой характеристик соответственно
Lhck, i|)hck — нескорректированная цифровая следящая система; Ln*, л^пд — характеристики с ПД-регулятором; Ен — с П-регулятором; I и II— запретные области для амплитудной и для фазовой характеристик соответственно
формулу (3)：
Wo (/Z)=Wo (/Z)=(21)(21)
Wo (/Z)=
Wo (/Z)=
(21)
(21)
а частотная характеристика нескорректированной системы отличается от выражения (21) лишь дополнительным фазовым множителем (1—у^Г0/2) /(1+/ХТ0/2), порождаемым задержкой на один такт между опросом модуля текущей координаты и выдачей управления на модуль управления координатой.
Замкнутая система без регулятора (нескорректированная) неустойчива (ср. Енск и 屮нск)・
Использование регулятора пропорционально-дифференциального типа с алгоритмом
E7npn=aen+7(8n-en_1),.(22：
дискретной передаточной функцией
Kp(N)= ( (a+Y)z—,)/%2
и дискретной частотной характеристикой
wР 0入)=a(4 + 拉7о (+ +。方))(‘-'' _^")/(‘ + A
позволяет достичь заданных требований по точности и запасу устой- 172
чивости: при 7о=О,О5 с, а=0,11, у=5,73 ни амплитудная £口耳,ни фазовая характеристика ^пд не заходят в соответствующие запретные области, определяемые для логарифмической амплитудной характеристики формулой (19), а для логарифмической фазовой характеристики —показателем колебательности Л/=1,5 [2, с. 43].
Заметим, что использование регулятора пропорционального типа не позволяет одновременно выполнить оба условия (см. рис. 5) — при сс=О,О75, То=О,О5 (7=0) обеспечивается заданный запас устойчивости, однако требуемая точность не достигается (£ц заходит в запретную область).
Синте зиров а иные корректирующие звенья [см. выражения (13) и (22)] были реализованы в составе программного обеспечения системы управления робота «Колер» [3].
Качество работы ЦСС было подвергнуто экспериментальной проверке. Эксперименты показали, что при гармоническом задающем воздействии с 4=500 дискрет и о)СО,75 с-1 максимальная ошибка дейст- вите.чьпо меньше 4 дискрет. Однако при з>0,75 с-1 ошибка Зтах>4 максимальная ошибка растет с увеличением частоты и при(о=1 с~‘ достигает 7 дискрет. Это расхождение с расчетом не является неожиданным и объясняется игнорированием нелинейности реального объекта управления. Получение нелинейной модели объекта управления и использование ее для расчета цифровой* следящей системы должно быть предметом специального рассмотрения.
ЛИТЕРАТУРА
Федоров С. М., Литвинов А. П. Автоматические системы с цифровыми машинами. М.: Энергия, 1965. 235 с.
Бесекерский В. А. Динамический синтез систем автоматического регулирования. М.: Наука, 1970. 130 с.
Федосеев А. Я., Григорьев В. И., Чевтаев С. А., Цуева Л. В. Программное обеспечение промышленного окрасочного робота «Колер».— Наст. сб.
УДК 007.52:62—52:001.2
ИЕРАРХИЧЕСКАЯ ОРГАНИЗАЦИЯ
АЛГОРИТМОВ ПЕРЕРАБОТКИ ИНФОРМАЦИИ ПРИ УПРАВЛЕНИИ СВАРОЧНЫМИ РОБОТАМИ
В. Т. Тертышный
При анализе задач и синтезе алгоритмов управления промышленными роботами общепринятым является иерархический подход [1, 2], последовательное применение которого обеспечивает четкую структурную организацию технических и программных средств системы управления. Очевидно, что в рампах этого общего подхода необходима конкретизация функций отдельных уровней иерархии, соответствующая области применения робота.
Рассмотрим вопросы иерархической организации алгоритмов и синтеза на основе полученной алгоритмической структуры аппарат-
ных и программных средств систем управления сварочными роботами.
Все многообразие функций системы управления сварочными робо-金 тами логично разделать на две группы::
планирование технологического процесса;彳
выполнение технологического процесса.
Алгоритмы, реализующие планирование, образуют верхний уровень иерархии — уровень планирования, на котором решаются задачи, связанные с составлением, отладкой и редактированием программы .■ технологического процесса на соответствующем проблемно-ориенти- ; рованном языке. Средства решения этих задач имеют много сходного j с традиционными средствами программирования на алгоритмических j языках, организующими подготовку исходного текста программы, ее J синтаксический контроль, трансляцию, отладку и редактирование.
Существенным отличием является использование специфического метода программирования — обучения, при котором в качестве средства задания операторов программы используется функциональная клавиатура пульта обучения, а аргументами операторов служат текущие значения переменных, характеризующих состояние управляемого объекта (манипуляторов, сварочного оборудования и т. п.). Однако и в этом смысле можно иайти аналогии в цругих областях программирования, например в задачах машинной графики.
Исходная информация для алгоритмов уровней планирования может поступать как от оператора (технолога-программиста), так и от автоматических систем более высокого уровня — АСУ ТП, САПР и т. д. Результатом работы алгоритмов этого уровня является готовая к исполнению программа технологического процесса.
Алгоритмы, реализующие ее исполнение, образуют последующие уровни иерархии.
На уровне координации операторы программы технологического процесса интерпретир^^ются в инструкции управления — инструкции формирования элементарных отрезков траектории перемещения инструмента или изделия, инструкции изменения режима работы технологического оборудования и т. д.丿
Сформированные на уровне координации инструкции управления являются исходной информацией для алгоритмов уровня элементарных операций.
При этом полученные инструкции преобразуются в команды управления исполнительным оборудованием — сервоприводами манипуляторов и технологическим оборудованием. В отношении управления перемещением манипуляторов речь может идти об интерполяции элементарных отрезков и преобразовании координат. Очевидно, что интерполирование (линейное или круговое) должно осуществляться в общем случае в шестимерном пространстве вследствие налитая трех ориентирующих координат. До сих пор мы имели дело с описанием движения, никонм образом не привязанным к конструкции собственно манипуляторов (манипулятора инструмента и манипулятора (одного или более) изделия). Теперь же для формирования команд управления приводами отдельных звеньев манипулятора необходимо решить обратную задачу кинематического анализа — синтезировать закопы
управления отдельными звеньями манипуляторов, приводящие в результате к требуемому перемещению рабочего органа относительно изделия.
Что касается управления технологическим оборудованием, то здесь может идти речь об оптимизации технологических параметров.
Последний, наинизший, уровень иерархии — уровень сервоуправления составляют задачи управления приводом отдельных звеньев, совместное движение, которых обеспечивает заданное перемещение сварочного инструмента относительно изделия. Существенной особенностью решения задач зтого уровня в сварочном роботе является необходимость динамической коррекции траектории, что вызвано необходимостью контурного управления движением — перемещением рабочего органа по заданной траектории, а не в заданную точку. При этом целью управления приводом является не компенсация возникшей ошибки (если сварочный инструмент отклонился от стыка, то вернуть его обратно и «переварить» стык уже невозможно), а предотвращение ее распространения и уменьшение влияния на дальнейшее движение, т. е. предотвращение накопления возникающих в процессе перемещения ошибок.'
Описанная иерархия задач управления сварочным роботом может , быть наглядно представлена в виде структурной схемы (рис. 1). Для того чтобы такая схема могла служить исходным материалом для синтеза системы управления комплексом, в схеме необходимо отразить способы подключения системы сбора информации о состоянии комплекса (внутренние сенсоры) и его операционной среды (внешние сенсоры) и способы восприятия команд оператора. Совершенно очевидно, что обратной связью через датчики положения звеньев манипулятора следует охватить уровень сервоуправления. Команды оператора долж^ ны восприниматься на входе уровня планирования (операторы языка программы обработки изделия) и на входе уровня элементарных операций (команды ручного управления комплексом, которые могут потребоваться, в частности, при формировании программы технологического процесса методом обучения). Кроме того, необходим обратный информационный поток (внутренняя обратная связь в системе), по- зволяющий задачам верхних уровней при необходимости в любой момент получить информацию о текущем состоянии элементов комплекса (в частности, текущем положении рабочего органа). Для этого в состав уровня элементарных операций должны быть включены алгоритмы решения ^прямой» задачи кинематики. В результате получаем представленную на рис. 2 схему обработки информации. Конкретные варианты реализации любой системы неадаптивного управления роботом могут рассматриваться как частные случаи этой схемы, полученные исключением каких-либо блоков (или исключением отдельных алгоритмов из состава этих блоков).
Например, структура алгоритмов системы управления с использованием программы технологического процесса, записанной в терминах системы собственных координат манипулятора, может быть получена исключением блоков уровня координации и уровня элементарных операций, т. е. в такой системе практически реализуются только алгоритмы пижного уровня управления.
Уровень планирования J
(Программа、технологического процесса /(Программа、технологического процесса /「Уровень к；ор/нацин~'(Инструкции управления「Уровень к；ор/нацин~'(Инструкции управленияуровень элементарных операцийуровень элементарных операцийЭлементарные отрезки траектории движенияЭлементарные отрезки траектории движенияТехнологический режимТехнологический режимУровень планированияУровень планированияПрограмма технологическон? процессаПрограмма технологическон? процессауровень коороднацииуровень коороднацииОператорОператор
(Программа、
технологического процесса /
(Программа、
технологического процесса /
「Уровень к；ор/нацин~'
(Инструкции управления
「Уровень к；ор/нацин~'
(Инструкции управления
уровень элементарных операций
уровень элементарных операций
Элементарные отрезки траектории движения
Элементарные отрезки траектории движения
Технологический режим
Технологический режим
Уровень планирования
Уровень планирования
Программа технологическон? процесса
Программа технологическон? процесса
уровень коороднации
уровень коороднации
Оператор
Оператор
Команды управленияКоманды управленияУровень сервоуправленияУровень сервоуправления
Команды управления
Команды управления
Уровень сервоуправления
Уровень сервоуправления
Управление приводомУправление приводомСтабилизация технопо^] |гических параметровСигналы управленияСтабилизация технопо^] |гических параметровСигналы управления[ Уровень[ УровеньИсполнительные органыИсполнительные органыМанипуляционная системаМанипуляционная системаСварочное оборудованиеСварочное оборудованиеВнутренние сенсорыВнутренние сенсоры:ервоуп равпенин|—К Управляемое оборудойаипе:ервоуп равпенин|—К Управляемое оборудойаипеВнешние сенсора |<<—^Внешние сенсора |<<—^Изделие IИзделие I
Управление приводом
Управление приводом
Стабилизация технопо^] |гических параметров
Сигналы управления
Стабилизация технопо^] |гических параметров
Сигналы управления
[ Уровень
[ Уровень
Исполнительные органы
Исполнительные органы
Манипуляционная система
Манипуляционная система
Сварочное оборудование
Сварочное оборудование
Внутренние сенсоры
Внутренние сенсоры
:ервоуп равпенин|—
К Управляемое оборудойаипе
:ервоуп равпенин|—
К Управляемое оборудойаипе
Внешние сенсора |<<—^
Внешние сенсора |<<—^
Изделие I
Изделие I
Рис. 1. Иерархическая схема организации алгоритмов
Рис. 2. Информационные связи между алгоритмическими уровнями в адаптивной системе управления
Однаког как показывает опыт, при эксплуатации таких систем встречаются серьезные трудности, связанные в первую очередь с неудобством программирования в системе собственных координат манипуляторов.
Включение же в состав алгоритмической структуры дополнительных уровней влечет за собой сокращение объема памяти, занимаемой программой технологического процесса, повышение производительности робота в процессе программирования, «транспортабельность» программы технологического процесса, т. е. возможность воспроизводить одну и ту же программу в комплексах, использующих манипуляторы с различными кинематическими схемами. Более того, оказывается, что выигрыш в памяти, получаемый за счет сокращения объема программы технологического процесса, компенсирует затраты (аппаратурные в виде дополнительной памяти для храпения программ) на размещение дополнительных программ.
Теперь перейдем к адаптивным системам управления.
Применительно к сварочным роботам принято рассматривать два вида адаптации: установочную и текущую.
Алгоритм установочной адаптации включается в состав уровня координации. Этот алгоритм обрабатывает информацию от внешних сенсоров положения изделия в рабочей зоне и формирует оператор коррекции, который в процессе отработки очередного фрагмента программы технологического процесса остается неизменным. Таким образом, процесс обработки сенсорной информации и собственно адаптация (коррекция программы в соответствии с состоянием внешней среды) разделены во времени.
Текущая адаптация предусматривает оперативную коррекцию
программы работы комплекса в процессе обработки изделия. При этом могут изменяться как аргументы операторов программы технологического процесса, так и последовательность действий, зафиксированная в порядке следования операторов в программе. Решить вопрос, на каком уровне иерархии алгоритмов необходимо в этом случае замыкать обратную связь, можно, только конкретизировав степень детализации последовательности обработки, заложенную в языке программирования комплекса.
Имеющиеся на сегодняшний день языки, которые могут быть использованы в сварочном роботе, относятся к классу языков Ассемблера и предусматривают довольно детальное (практически на уровне типовых элементов траектории) описание поведения робота. В таком случае текущая адаптация может быть реализована путем формирования и обработки дополнительных (не присутствующих в программе технологического процесса) операторов. Действительно, предположим, что в программе технологического процесса задан оператор формирования прямолинейного отрезка сварного шва, а реальная траектория стыка непрямолинейна. В таком случае необходима аппроксимация реальной траектории стыка отрезками из имеющегося набора (если геометрическими элементами траектории являются не только прямые) и передача соответствующих операторов на обработку алгоритмами уровня координации. Это означает, что в рассмотренной нами иерархии необходимо ввести дополнительный уровень самопрограммирования, который выполняет функции «автоматического программиста», моделируя работу оператора в процессе составления программы технологического процесса. Исходной информацией для этого уровня должна слул^ить, с одной стороны, сенсорная информация, с друюй — информация о текущем состоянии манипулятора (выше мы уже обсуждали способ ее получения).
Алгоритмы уровня самообучения могут быть органически включены в состав уровня координации в том случае, если программа технологического процесса задается на уровне законченных технологических операций (например, «заварить стык от точки Л1 до точки Л2, движение осуществлять в направлении вектора В1»). При этом функции алгоритмов уровня координации будут следующими:
по данным от сенсоров найти начало стыка в окрестности точки Л1;
по данным от сенсоров найти реальное направление стыка в окрестности вектора В1;
периодически обрабатывая информацию от сенсоров, формировать команды построения элементарных отрезков траектории, обеспечивая аппроксимацию траектории стыка с требуемой точностью;
по данным от сенсоров найти конец стыка в окрестности точки 42 и сформировать соответствующую последовательность команд.
На этом можно было бы закончить рассмотрение структуры алгоритмов управления сварочным роботом. Однако для синтеза системы управления весьма желательно имёть более четкое представление о временной динамике решения пере численных задач, чтобы оценить необходимую производительность технических средств.
Не претендуя на всеобъемлющую полноту анализа, пспытярагся
рассмотреть зту задачу в первом приближении. Введем следующие обозначения:
37 — период выдачи сигналов управления исполнительными механизмами;
友 一 время решения задачи динамической коррекции траектории алгоритмами уровня сервоуправления;
G' — время решения задачи интерполяции алгоритмами уровня элементарных операций;
力2"—время решения обратной задачи кинематики алгоритмами уровня элементарных операций;
7\ — время отработки комплексом минимального ио длине элемента траектории (прямолинейного или дугообразного);
力J — время «распаковки» одного оператора языка задания программы технологического процесса алгоритмами уровня координации;
方з" — время решения задачи коррекции координат алгоритмами уровня координации;
tc — время предварительной обработки сенсорной информации системой сбора информации о состоянии внешней (операционной) среды;
方з'〃 ——время решения задачи адаптации на основе предварительно обработанной сенсорной информации алгоритмами уровня координации;
Та — период адаптивного управления.
Вкратце поясним смысл введенных параметров.
Время ii отражает затраты машинного времени при программном способе управления исполнительными механизмами. В случае аппаратного управления Л равно времени передачи кодов управляющих воздействий на соответствующие аппаратурные модули.
Время Тд характеризует требуемую производительность системы управления и определяется длиной минимального программируемого отрезка на уровне инструкций управления (исходная информация алгоритмов уровня элементарных операций) с заданной максимальной технологической скоростью перемещения сварочного инструмента и『)
Время 力с характеризует задержку передачи сенсорной информации в основные алгоритмы управления, связанные с необходимостью ее предварительной обработки (фильтрация шумов, согласование форматов и т. д.).
Бремя Та характеризует необходимую периодичность замыкаиия обратной связи в режиме текущей адаптации. Оно зависит от пространственного спектра функции случайных отклонений траектории стыка, требуемой точности совмещения траектории перемещения сварочного инструмента со стыком и скорости перемещения сварочного инструмента %.
Рассмотрим различные варианты режимов управления в порядке возрастания сложности, задаваясь в каждом случае целью сформулировать в количественном виде требования к производительности технических средств системы управления сварочным роботом.
Вариант 1. Неадаптивная система управления с использованием
программы технологического процесса, составленной в терминах системы собственных координат манипулятора. Для такой системы управления должно соблюдаться следующее соотношение между временными параметрами:
ЬТ“
При этом отметим, что
留=北.
В системе имеется только один массив, хранящий программу технологического процесса. Объем массива М пропорционален суммарной длине стыков обрабатываемого изделия. Поскольку обычно 67》厶，на основе такой системы легко построить систему группового управления, для которой должно соблюдаться следующее соотношение между временными параметрами: ■
67＞用力也.
Здесь к — количество одновременно управляемых манипуляторов; 厶I - дополнительные затраты машинного времени, связанные с организацией мультипрограммного режима. ■
Отметим, что время tM существенно возрастает, если не удается одновременно разместить программы технологического процесса для всех манипуляторов в оперативной памяти системы. При этом приходится организовывать оперативный обмен информацией с внешней памятью, что влечет за собой существенное снижение производительности системы.
Вариант 2. Неадаптпвная система управления с многоуровневой структурой алгоритмов обработки информации. В состав информационного обеспечения входят алгоритмы уровней планирования, координации, элементарных отрезков, сервоуправления, рассмотренные выше. Для такой системы должны обеспечиваться следующие соотношения между временными параметрами:
67＞力+"+方2"， (1)
兀"3‘ +兀(九+方2‘ +方2")/67+方М. (2)
В рассматриваемом варианте системы мы имеем дело с несколь- 1шми (по крайней мере тремя) одновременно отрабатываемыми алгоритмами. Поэтому необходимы определенные затраты времени работы процессоров на организацию такого мультипрограммного режима, которые могут быть выражены через дополнительный член 方м в правой части неравенства (2).
' Первое из указанных соотношений должно соблюдаться при лю- боп варианте структуры технических средств. Второе соотношение обязательно лишь в случае однопроцессорной структуры системы. Для двухпроцессорной системы, в которой один процессор реализует алгоритмы двух нижних уровней иерархии (при этом в состав внешних устройств включаются при необходимости и модули управления
приводом с соответств^^ющей коррекцией значения 方J, а второй процессор реализует алгоритмы более верхних уровней, соотношение (2) необходимо скорректировать:
T-^ts +Тэп1ЬТц+^.
Здесь п — пропускная способность канала передачи информации между процессорами; п — максимальный объем (максимальная длина) инструкции управления.
Очевидно, что аналогично предыдущему варианту неадаптивной системы можно реализовать групповое управление, добавив соответ- ствующее количество процессоров, отрабатывающих алгоритмы нижних уровней иерархии:
7\＞场(方3‘+北汽/67")+方М.1
Вариант 3. Система управления с установочной адаптацией. Этот вариант отличается от предыдущего включением в соотношение временных параметров члена 厶".Соответствующие выражения будут выглядеть следующим образом:
для однопроцессорной системы
北＞ 乂十方r+北色+m+J"57+％;
для двухпроцессорной системы
То＞1з +1зг+Т3n/bTy\+tM\
для системы группового управления
T^k^+t^+T.n/bTn)^.
Естественно, что соотношение (1) сохраняется и в этом варианте.
Вариант 4. Система управления с текущей адаптацией. Для такой системы важнейшим ограничением является необходимость обеспечить заданную периодичность замыкания обратной связи через средства сбора сенсорной информации. Здесь также возможен ряд конфигураций структуры технических средств.、
Для однопроцессорной системы, в которой единственный профессор обрабатывает все алгоритмы управления, а также выполняет предварительную обработку сенсорной информации, соотношения между временными параметрами имеют следующий вид:
北＞/У+&’+兀(友+学+『)/£7+九.
Для системы с дополнительным сенсорным прсдпроцессором получим
Та»,
T^tr^t^T^t^t^lbT^.
И, наконец, для системы, в которой алгоритмы управления реализуются двумя процессорами и, кроме того, имеется сенсорный 180
прсдпроцессор, ограничительные соотношения представляются в следующем виде:
T^t^+tZ+T^nlbT-q+t^
6T>L+U+%"・
* * *
Отметим, что полученные соотношения между временными параметрами позволяют в первом приближении оценить возможность построения системы управления с выбранной структурой, реализующей заданный метод управления (неадаптивное управление, управление с установочной адаптацией, управление с текущей адаптацией) .Проведенный анализ является довольно грубым, а полученные соотношения отражают необходимые, а не 'достаточные условия реализз^емости того или иного варианта системы управления сварочным роботом. Однако даже такой далекий от совершенства анализ позволяет сделать важные выводы относительно стратегии разработки подобного рода систем.
Во всех рассмотренных вариантах алгоритмических структур анализируются как минимум две структуры технических средств: однопроцессорная и мультипроцессорная (двух- или трех-). Таким образом, четко видны две стратегии развития систем:
наращивание функциональных возможностей системы путем постепенного включения в состав программного обеспечения единственного процессора всех новых программных модулей;
наращивание функциональных возможностей системы путем включения в структуру технических средств новых блоков (процессоров), реализующих дополнительные функции.
Первый путь должен в конце концов привести к тупиковой ситуации, когда производительность процессора ограничит дальнейший рост возможностей системы, причем попытка использовать с самого начала (для систем с простейшими возможностями) достаточно мощный процессор приведет к снижению эксплуатационно- экономических характеристик.
Второе же направление представляет наиболее экономичную стратегию развития возможностей системы управления, позволяя получать на каждом этапе оптимальное соотношение между возмож- ностями системы и включенными в ее состав аппаратными средетва- лги. Такой путь есть последовательное применение принципа модульности по отношению к рассматриваемому виду систем управления, а реальной технической предпосылкой к осуществлению является появление микропроцессоров невысокой стоимости и достаточной производительности. Способы оптимального распределения функций между процессорами должны опираться на рассмотренную иерархическую структуру алгоритмов обработки информации в процессе управления комплексом.
ЛИТЕРАТУРА
〃ок0б Е. П., Верещагин А. Ф., Зенкевич С. Л. Манипуляционные роботы： динамика и алгоритмы. М.: Наука, 1978. 400 с.
Управление роботами от ЭВМ/Под ред. Е. И. Юревича. Л.: Энергия, 1980. 264 с.
УДК 007.52’
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ СИСТЕМЫ ТЕХНИЧЕСКОГО ЗРЕНИЯ ПРОМЫШЛЕННОГО РОБОТА
К. Н. Ступин
Роботизация таких технологических операций, как контроль качества продукции, сортировка, автоматическая упаковка и в особенности сборка, предполагает наличие развитых сенсорных средств, способных в той или иной степени выполнять функции зрения. Применение систем технического зрения дает возможность выполнять сборочные операции, используя визуальную обратную связь, аналогичную той, которая имеет место при работе человека-сборщика.
Рассматриваемая в данной работе система технического зрения создана на базе микро-ЭВМ «Электроника-60», серийной телевизионной камеры «Взор» и пневматического манипулятора МП-8. Область применения системы технического зрения — сборочные операции, в процессе выполнения которых необходимо осуществлять захватывание произвольно расположенных в рабочем поле объектов, а также их идентификацию в рамках заранее определенного набора. Система технического зрения может также применяться как система контроля качества, автоматической сортировки и укладки. При создании системы технического зрения были сделаны следующие допущения:
рабочая зона системы технического зрения представляет собой плоскость；
ось телевизионной камеры перпендикулярна плоскости раболей зоны; ，丿
телевизионная камера удалена от плоскости рабочей зоны настолько, а объекты, с которыми работает система технического зрения, таковы, что при их смещении в пределах рабочей зоны двумерные образы объектов меняются несущественно с точки зрения решаемых задач;
объекты хорошо контрастируют с фоном, не перекрываются и не касаются один другого.
Система технического зрения работает в реальном масштабе времени, т. е. обработка видеоинформации не вносит задержки в действие манипулятора. Общая схема работы системы технического зрения при выполнении, например, автоматической сборки такова.
Перед началом работы проводится обучение системы технического зрения, если оно не было выполнено ранее. В процессе общения каж-
дый йз объектов, с которыми предстоит работать системе технического зрения, помещается в рабочее поле и предъявляется системе в 20 различных положениях. В результате система технического зрения формирует каталог эталонов рабочих объектов, т. е. тех объектов, которые она в состоянии идентифицировать.
Далее с помощью реперного объекта согласуются системы координат, связанные с телевизионной камерой и манипулятором. Для этого манипулятор помещает реперный объект в две заранее определенные точки рабочего поля, а система технического зрения определяет положение объекта. После описанных операций система технического зрения готова к работе.
При появлении объектов в рабочем поле система технического зрения вводит видеоинформацию о них, разделяет ее на части по принадлежности к каждому компактному образу и последовательно обрабатывает эти части. В результате обработки информации, относящейся к каждому образу, формируется точка в пространстве признаков, по которым осуществляется идентификация, отвечающая данному объекту. Кроме того, вычисляются данные о его положении и ориентации.
Идентификация объекта осуществляется по принципу «ближайшего соседа» с использованием сформированного на этапе обучения каталога эталонов. Если объект идентифицирован, то для него становится доступной информация о тех операциях, которые над ним надо проделать. В то же время система технического зрения располагает информацией, достаточной для захватывания объекта манипулятором, причем такие данные система получает до идентификации объекта.
Это обстоятельство позволяет распараллелить процессы манипулирования и идентификации. После получения данных о положении центра площади объекта система технического зрения вычисляет управляющие воздействия и выдает их в систему управления маш” иулятором. Пока манипулятор отрабатывает их, выводя схват над выбранным объектом, ЭВМ рассчитывает ориентацию объекта, после чего схват ориентируется нужным образом. Например, при использовании с хвата с параллельными губками необходимо брать удлиненные предметы так, чтобы губки схвата были параллельны той главной центральной оси инерции объекта, которой отвечает минимальный момент инерции.
После захватывания объекта система технического зрения выдает на манипулятор команду о перемещении объекта в зону сборки. Параллельно с отработкой этой команды система технического зрения идентифицирует объект и к моменту появления его в зоне сборки уже располагает всеми данными, необходимыми для дальнейшей работы с ним. Собственно сборкой должна заниматься специализированная система технического зрения, имеющая в своем составе одну или несколько телевизиоппых камер, оснащенных необходимой оптикой и другим вспомогательным оборудованием. Состав и структура такой специализированной системы технического зрения в зпачи- тельной мере определяется характером конкретной сборочной задачи.
Система технического зрения, рассматриваемая в данной статье, не является узкоспециализированной и рассчитана на выполнение операций, непосредственно предшествующих самой сборке.
Рассмотрим более подробно этапы обработки видеоинформации в системе технического зрения.
Ввод и предварительная обработка видеоинформации. В системе технического зрения уже на этапе ввода видеоинформации в ЭВМ значительно сокращается объем вводимых данных. Это делается как для уменьшения объема памяти, необходимой для хранения и обработки видеоинформации, так и для уменьшения времени обработки. В качестве основной характеристики плоского изображения используется его контур.
На этапе ввода и предварительной обработки проводятся определение и ввод в ЭВМ координат контурных точек изображения, которые могут быть получены при помощи горизонтальной развертки телевизионной камеры. Точки, лежащие на горизонтальных участках контура, вычисляются программными средствами.
Предварительная обработка и ввод информации в систему технического зрения осуществляются специализированным устройством — препроцессором. В целях повышения достоверности выходной информации в препроцессоре реализована следующая мажоритарная процедура обработки видеоинформации. Препроцессор принимает от телевизионной камеры три последовательные строки изображения, проводит дискретизацию аналогового сигнала с двумя уровнями по яркости (черный — белый) и числом элементов в строке, равным 192. Информация по каждой из трех вводимых строк помещается в свой буфер, содержащий 192 двоичных разряда. Далее, по принципу «два из трех» формируется результирующий буфер. Препроцессор анализирует содержимое этого буфера и определяет положение переходов от белого к черному и наоборот. Полученные таким образом координаты контурных точек помещаются в буфер вывода, откуда поступают в ЭВМ.
Описанная процедура обработки выполняется за время обратного хода развертки после <<третьей» строки, прямого и обратного ходов «четвертой» строки, которая в данном кадре пропускается. Обмен с ЭВМ начинается с момента заполнения буфера вывода. Чтобьт не терять каждую четвертую строку в кадре, вводятся подряд четыре кадра со сдвигом на одну строку. После перегруппировки в памяти ЭВМ формируется массив координат контурных точек, определимых с помощью горизонтальной развертки. Этот массив упорядочен по возрастанию координаты X (номер строки). Вся дальнейшая обработка видеоинформации осуществляется в ЭВМ.
Вычисление координат центра площади двумерного изображения. Координаты центра площади двумерного изображения объекта являются характеристиками положения объекта в рабочем поле и, кроме того, фигурируют в качестве параметров при вычислении всех признаков формы, используемых при идентификации.
В случае непрерывного контура положение центра площади относительно контура не зависит от ориентации объекта. Дискретиза- 184
ция контура делает положение центра площади чувствительным к изменению ориентации. Это особенно сильно проявляется, если в качестве центра берется не центр площади, а центр тяжести системы контурных точек. В этом случае при изменении ориентации объекта происходит «перетекание» контурных точек, что ведет к существенному изменению положения центра.
Чтобы избежать такого эффекта, при определении центра объекта, он рассматривается как тело, составленное из полос единичной ширины, координаты начал и концов которых определяются препроцессором. Под центром площади понимается центр тяжести двумерного изображения, рассматриваемого как однородный объект. Одновременно с вычислением координат центра площади определяется площадь объекта, которая является признаком формы и в дальнейшем используется при идентификации объекта. Координаты центра и площадь вычисляются по следующим формулам: -
N2ISI N2N2ISI N2寸,25 -也2A1)/况,寸,25 -也2A1)/况,(次,25 -次,2 戶 1)，(次,25 -次,2 戶 1)，
N2ISI N2
N2ISI N2
寸,25 -也2A1)/况,
寸,25 -也2A1)/况,
(次,25 -次,2 戶 1)，
(次,25 -次,2 戶 1)，
где 仇,j——декартова координата у-й контурной точки в f-й строке для системы, связанной с телевизионной камерой; Li——количество контурных точек в f-й строке изображения, деленное на два; N — количество строк в кадре.
Заметим, что как координаты центра, так и площадь, определенные рассмотренным способом, не являются полностью независимыми от ориентации объекта. Однако такая зависимость есть неизбежный результат дискретизации изображения, т. е, приближенной замены непрерывного контура дискретным, и не устраняется полностью. Уменьшение ошибки может быть достигнуто путем увеличения числа дискрет в двумерном изображении. Это же можно сказать о всех характеристиках объекта, порученных в результате обработки его двумерного дискретного изображения.
Вычисление признаков формы объекта. Для этого необходимо восстановление его полного контура, включая точки, лежащие на горизонтальных гранитхах. Алгоритм восстановления контура основан на последовательном сравнепии информации о соседних строках кадра. Для каждой из сравниваемых строк формируется массив, в котором содержится следующая информация о каждой контурной точке данной строки:
координата, отвечающая положению тоткег в строке (У);
признак, показывающий, к которой из двух строк (текущей млн предыдущей) принадлежит данная точка;
признак, показывающий, какой является точка в строке (четной или нечетной).
Проводится сортировка слиянием этих массивов по возрастанию координаты У. Далее, в процессе просмотра массива слияния определяются координаты дополнительных контурных точек. Эти точки появляются, если расстояние между нечетным и четным элементом массива слияния (разность координат У) оказывается больше или равно двум. Вторая координата (X) определяется с учетом признака четности. Одновременно с восстановлением полного контура проводится вычисление периметра. При этом используется признак принадлежности к текущей (предыдущей) строке.
Таким образом, после завершения восстановления контура оказываются вычисленными два из восьми используемых признаков формы —площадь и периметр. Остальные признаки вычисляются в результате обработки массива координат контурных точек полного контура. К этим признакам относятся:
SR — среднее арифметическое расстояний от контурных точек до центра площади;
^дн — разброс расстояния до центра относительно SR;
兄max, 7?min 一 соответственно максимальное и минимальное расстояние до центра;
/max, Лпа — соответственно максимальный и минимальный момент ине])ции относительно главных центральных осей инерции контура, рассматриваемого как совокупность материальных точек единичной массы.
Выбор именно таких признаков формы продиктован тем, что они мадо зависят от ориентации объекта и могут быть достаточно быстро вычислены по следующим формулам:
Sr = W RJm, Sar = £ (凡一Sr)?/%
W=1г—1
Emax = max ｛死｝, Emm = min ｛凡｝,
/e (Sx.x—2KSxx+KWn) / K+l),
/w,尸 “Sx,x+2KSx,y+Sy,v)/(K2+1), где'
凡= ((M — Xc)2+ (看一汽产产；'
mm
Sx,x=E (X- Xc 戶；％, Y = 2 (『一Yc)^
勿=1
Sx,y= g (Х, — Хс)(У「У。)；
K = (Sх,х — Sy,y — ((Sx,.x — Sy,"十 4S^, y)%)/2Sx,y；
m — количество точек в полном контуре.
Кроме признаков формы, вычисляется положение главной центральной оси инерции, момент относительно которой минимален. Это положение определяется утлом наклона оси инерции к оси X:
ALFA=aTCtg (—К,.
Вместе с координатами центра площади это дает системе технического зрения информацию, достаточную для захватывания объекта манипулятором.
Получаемый таким образом восьмикомпонентпый вектор признаков служит на этапе обучения для формирования «эталона» объекта. В качестве такого «эталона» берется среднее арифметическое векторов признаков, полученных при обучении данному объекту.
На этапе идентификации объекта, находящегося в рабочем поле системы технического зрения, вычисленный вектор признаков сравнивается со всеми «эталонами» из каталога рабочих объектов. Объект идентифицируется с тем «эталоном», расстояние до которого в пространстве признаков минимально.
Программное обеспечение системы технического зрения построено по модульному принципу и требует порядка 20К байт памяти ЭВМ. Время обработки видеоинформации от одиночного объекта составляет приблизительно 2 с.
УДК 658,612.011.56:681.3.06
О ГИБКОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В СИСТЕМАХ УПРАВЛЕНИЯ
ПРОИЗВОДСТВЕННЫМИ ОБЪЕКТАМИ
В. М. Гуревич, А. К. Григорян, В. Е. Вовнобой
Актуальной задачей сегодняшнего дня является обеспечение быстрого развития систем управления с высокими показателями надежности и качества. Решение этих проблем для различного вида оборудования (станков, производственных модулей, роботов, устройств подготовки управляющих программ, концентраторов информации и т. п.) возможно только при структурной и схемной однородности устройств управления, максимальной преемственности и унификации программного обеспечения, использовании проблемно-ориентированных языков потребителей и разработчиков систем. Структурная и функциональная перестраиваемость позволяет получать разные специализированные конфигурации систем управления на основе типового оборудования и базового программного обеспечения.
Рассмотрим подход к построению гибкого программного обеспечения.
Гибкость управления (подход «сверху»). Под гибкостью (歹) 6%ем понимать свойство системы (S) наилучшим образом (К) обеспечивать требуемые характеристики управления У = {少工,у2.... ...,у^} при их возможных отклонениях D = {di, d?, . . ., &n}・ Пусть величина fi (d) характеризует гибкость системы по управлению %. Тогда общую гибкость системы характеризует функция F (S) = 2〃办(或)при f = (1, TV), где м — вес отклонения d^
Пусть К ——это некоторые ограничения, при которых имеет смысл требуемая гибкость F. К ограничениям могут относиться такие по-
нятия, как критерии точности управление или ^остойчивости системы, критерии минимизации или ограничения ресурсов, критерии удобства эксплуатации и т. д. Если задано Y = Н (X), то задача построения гибкой системы управления сводится к нахождению такого функционала G (У, 0), что удовлетворяются критерии- К и F (S) = max.
Отклонения D могут касаться различных параметров управления. Выделим следующие случаи: параметризация входов (D = gi (X), где X ——входы системы); параметризация выходов (D = =g2 (У), где Y — выходы системы); пгграметризация функции, когда ° = g3 (女). От способа формализуемости и представления D зависит сложность G. В большинстве практических случаев D задается как векторный параметр с независимыми или слабозависимыми компонентами тапа списков, таблиц и т. д. Предельно сложный случай, когда D задан неявно и сильно взаимосвязан с Н. Тогда удобно для задания G (Я (X), D) использовать некоторую адекватную модель.
Выбором модели определяются языковые средства для описания G, а их реализация сводится к интерпретации G (女(X), 〃). Функция G и параметры отклонения D обеспечивают способность системы к адаптации. Определение методов реализации G ( Н (X), D) в программном обеспечении системы определяется ее архитектурой. Многоуровневая модульная организация позволяет декомпозировать J9 по слоям и модулям и упростить выбор G в каждом отдельном случае.
Гибкость црогр лп! (подход 《снизу》). Определим адаптируемость программы как свойство быть примененной для решения других мало отличающихся задач (алгоритмов). Элементарными изменениями в некотором языке назовем действия по изменению одной языковой единицы текста 11]. Очень часто класс близких алгоритмов формулируется именно в этих терминах. Конкретные элементарные изменения и их полнота зависят от языка. В статье [1] приведен пример множества элементарных изменений для языка булевых формул и показана их программная интерпретация.
Будем говорить, что алгоритмы 4Х, Л2, описанные на языке 方, отличаются друг от друга в 乃 точках или отклоняются на Л, если к элементарных изменений переводят их друг в друга. К элементарным изменениях относятся замена, удаление или вставка переменной, константы, метки, операции и т. д. Обозначим к = d (4工;Qt?),, а величину
rA = d (Л1, Ла)/тах£ (4。при i = 1, 2
назовем мерой близости Лх и Л2. Здесь L (AJ — длина текста (количество языковых элементов).
Пусть е ^ Е есть способ отображения & в программу Р (Л{) на языке » В частном случае 方 н 川 могут совпадать.
Определим меру близости двух программ как
гР = d (Р (Л г), Р (4))/ max L (Р (4») при i = 1,2.
Будем говорить, что е сохраняет близость, если с-окрестность
любого алгоритма Ai отображается в Ьс-окрестность реализующей ее программы Р (4)$ где b — сопеЦ т. е. справедливо утверждение
V^i, А}么也一,4)< 3гр (尸(4),尸(4力《be.
Пример отображения е, не сохраняющего близость^ т. е. сопоставляющего «близким» алгоритмам «далекие» программы* рассмотрен в статье [1],
Определим на {4} две операции параметризации: по данным и по управлению. Параметризация по данным подобна алгебраическому действию «вынесение за скобки» некоторых констант и переменных и заключается в их систематической замене параметрами. Она позволяет свести далекие алгоритмы к близким. Параметризация по управлению определяется следующим образом: в точках несоответствия двух алгоритмов 4T и Л2 вводится механизм распознавания параметра^ по которому выбирается соответствующий алгоритм.
Общие части 41 и Л2 объединяются, так как близость текстуальная. Будем считать адаптацией алгоритма Л3 его свойство альтернативного выбора вариантов и свяжем с ней некоторый механизм распознавания и выбора соответствующей альтернативы из {/厶 А^^ т. е. назовем А? адаптирующимся к /工 и Л2.
Рассмотрим следующие случаи:
Л1 совпадает с Л2 с точностью до констант или переменных (тогда механизм выбора определен только вначале для подстановки значений параметров, остальная часть алгоритмов совпадает);
』1 и Л211Различаются в п точках (механизм выбора определен во всех п точках);
Л1 и Л2 различаются везде (тогда механизм выбора определен вначале и 43 есть объединение двух алгоритмов).
В каждом из этих случаев основным критерием выбора структуры &з является выполнение неравенства
L (4) & 乙(4工)+ L (4).
Из определения и метода построения Следует^ что если 入 (4丄力 4) = % то
га (4“ Л3) = гА (厶2,』з) = с + const.
Если е — отображение, сохраняющее близость, то для соответствующих им программ справедливы выражения
* (p(49, ? (/工))=力(p (4】Р (4")=妇
< HPiA^^LiPlA^+PiA^
Если га (4it Л2) = 1г т. е. алгоритмы отличаются почти во всех точках, то механизм выбора в Л3 целесообразно вводить только вначале. В этом случае
L (4) = L ⑷)+ L (4).
Определим гибкость алгоритма 4& как
/ (4) = / (d (41, 4)) — —j-^jZ(40 + ndi»
где 孔—число точек параметризации; ^ (/力 А^ — отклонение алгоритмов в этих точках. Тогда / (Л3) — 1 при "=豆(Лъ Л2)= =L (Лх), a min / (Л3) = 0, когда Ni и Л2 совпадают. Это соответствует интуитивному понятию «гибкости». Приведенные понятая можно распространить на случай m алгоритмов 4工，Л2, . . ., Ат. Итак, для обеспечения адаптируемости алгоритма Л необходимо:
определить близкую окрестность А, в которой он будет адаптироваться, и выбрать отображение е: А Р ⑷，сохраняющее близость;
в точках возможных отклонений от Л программа Р (Л) должна быть параметризована по данным и по управлению с введением механизма выбора.
Приведенная модель адаптируемости программ задает некоторый способ довольно общего описания функции отклонения G н ее реализации в виде интерпретации параметризуемых данных.
Архитектура гибкого программного обеспечения. Под гибкостью системы программного обеспечения будем понимать ее способность легко адаптироваться к определенным или прогнозируемым изменениям внешней среды (объекта управления, аппаратуры, на которой программное обеспечение работает, связей в иерархической сетн управления и т. д.). Проявлениями гибкости программного обеспечения являются его свойства переносимости с одной аппаратуры на другую, наращиваемости, перестраиваемости, модификационной способности и т. д. Для улучшения этих характеристик архитектура программного обеспечения должна быть соответствующим образом спроектирована.
Существующая теория и практика создания сложных программных систем основаны на принципе многоуровневой архитектуры [2]. Каждый уровень состоит из одного или нескольких абстрактных машин-процессоров (/?» и объединяющего их управления. Любой процессор есть реализация некоторой абстрактной машины, которая выполняет отдельный алгоритм, состоящий из процедур для вышестоящих уровней. Важно отметить, что процессоры, выполняющие алгоритмы, не связаны с понятием аппаратуры или программного обеспечения. Пара (рп, /?» определяет новый процессор pn+i, Для которого pi является программой, a pri ——интерпретатором. При таком подходе процессор рг является основным структурным элементом этой архитектуры, обладающим механизмом настройки (адаптации) посредством программы р. Гибкость процессора* рг зависит от количества и длины интерпретируемых им программ и способа их фиксации. Пара процессор — программа определяет потенциальную гибкость процессора, а размещение программы р (фиксация) в динамически изменяемой среде позволяет максимально реализовать эту гибкость.
Каждому уровню архитектуры соответствует своя область понятий, свое множество процессоров и присущая этому уровню гибкость. Назовем эту гибкость горизонтальной (внутриуровневой). Чем ниже уровень, тем ближе он к аппаратуре и шире его возможности адаптации. С поднятием наверх уровни специализируются и проис-
ходит «утрата гибкости». Этому способствует также принцип «упрятывания» информации внутри модуля или уровня, когда для связи с вышестоящим уровнем доступно лишь «узкое» окно [2].
Гибкость, обусловленную переходами с уровня на уровень, назовем вертикальной (межуровневой) гибкостью.
При выборе гибкой архитектуры руководствуются необходимостью семантической нагрузки на каждом из уровней и разумным компромиссом между специализацией и универсальностью.
В зависимости от того, какая память доступна и какова стратегия ее использования, на конкретном уровне интерпретатора можно иметь либо постоянную, либо временную фиксацию программ интерпретатора. При временной фиксации программ реальная гибкость уровня возрастает и пользователю может представиться возможность модификации этого уровня. Если же программа интерпретатора фиксируется в постоянной памяти, то потенциальная гибкость слоя переходит в плоскость аппаратуры. “
Архитектура программного обеспечения для устройств числового программного управления — пример гибкой организации. Требуется создать гамму устройств числового программного управления с расширенной областью применения на максимально унифицированном аппаратно-программном обеспечении. Каждое устройство этого семейства должно обеспечивать способы модификации Для расширения или переконфигурации своих функциональных возможностей. Каждая неделимая аппаратная единица образует процессор нижнего, нулевого уровня. Первый уровень составляет операционная система ^устройств числового программного управления [3], являющаяся процессором, интерпретирующим логический уровень связи с аппаратурой. Процессоры, распределяющие аппаратные ресурсы и специализирующие устройства для обслуживания устройств числового ^программного управления, представляют уровни второй и третий/ Технологический процессор является четвертым уровнем и состоит из технологических программ и программ управления электроавтоматикой станков,, роботов и другого вспомогательного оборудования. Для адаптации этого уровня и всего устройства числового программного управления к технологии обработки, станкам, роботам и другому вспомогательному оборудованию пользователям предоставляются проблемно-ориентированные языки «Ярус-2» [4] (для электроавтоматики) и «Технолог» (для технологии). Посредством программирования на них пользователь может создавать технологические процессоры для своих объектов управления.
Пятый уровень образуют процессоры технологически ориентированных диалогов (язык «Диалог» [5]) для автоматизации проектирования технологических программ.
ЛИТЕРАТУРА
Григорян А. К .у Золотаревская М. Я. М о дификация логических алгоритмов и программ.— Автоматика и телемеханика, 1982, № 7, с. 198—212.
Мобильность программного обеспечения / Под ред. П. Брауна. М.: Мир, 1980. 257 с.
Вовнобой В, Е., Гуревич В. М., Григорян А. Я. Операционная система ЧПУ на базе «Электроника НЦ80-31».— Станки и инструмент, 1983, № 12, с. 11—12.
Воклер И. ^., Григорян А. К., Кузнецов О. 77., Марковский Л. В., Ши- пилина Л. Б. Проблемы разработки языков логического программирования и их реализация на микро-ЭВМ на примере языка Ярус-2.— Автоматика и телемеханика, 1985, № 6, с. 149—159.
Бронштейн Г. В., Городецкий М. С, Гуревич В, М, Программирование обработки на токарпых станках с ЧПУ в режиме диалога.™ Станки и инстру мент, 1984, № 4, с. 11—13.
УДК 007.52-621.86
РЕГУЛЯРНЫЙ АЛГОРИТМ
ПРОКЛАДКИ МАРШРУТА МОБИЛЬНОГО РОБОТА С ИСПОЛЬЗОВАНИЕМ ТОЛЬКО ЛОКАЛЬНОЙ ИНФОРМАЦИИ
А. А. Петров, И. М. Сирота
Большинство известных методов планирования движений роботов в"*среде со стационарными ^препятствиями основано на предположении, что либо среда априорно известна и представлена некоторой моделью, либо препятствия можно распознать в достаточно большой! окрестности робота с помощью систем технического зрения, дальномеров или других дистанционных датчиков. Однако не менее важен иной класс задач, когда робот способен перемещать- ся*только «вслепую», узнавая о возможности прохождения того или иного участка лишь в малой его окрестности. Например, мобильный робот обнаруживает участок со слишком слабым грунтом, только непосредственно приблизившись к нему; манипуляционный робот часто может получить лишь локальную информацию о приближении своих звеньев к препятствию от тактильных датчиков. Имеется очень мало публикаций, где рассматриваются для подобных случаев неэвристические (регулярные) методы обхода препятствий, т. е. такие, которые гарантировали бы нахождение пути в заданную цель, если он объективно существует, а в противном случае ——установление факта принципиальной недостижимости цели. Регулярные алгоритмы формирования движений роботов в совершенно неизвестной среде Тна основании только локальной информации |были ^предложены и развивались в работах [1—3]. Позднее простейший из этих алгоритмов был повторен в статье' [4]. Несколько иные подходы к решению этой задачи представлены в публикациях [5,6].
Рассмотрим новый регулярный метод обхода препятствий роботом «вслепую», который использует получаемую в процессе движения локальную информацию не только для гарантированного нахождения пути в цель (или установления факта ее недостижимости), но и^для построения модели среды с целью последующего формирова-
ния более рациональных траекторий, чем впервые прокладываемый маршрут. Для построения движений робота воспользуемся известным подходом (см. публикации [1—4, 7—10]), основанным на прокладке траектории изображающей точки, являющейся отображением робота в конфигурационном пространстве, которое, например, может быть пространством обобщенных координат манипуляционного робота или же пространством параметров, характеризующих положение и ориентацию мобильного робота. В конфигурационном простр нстве имеются запретные зоны, соответствующие недопустимым конфигурациям робота.
Следует подчеркнуть, что для поставленной задачи Движения робота «вслепую» в неизвестной среде геометрическую модель конфигурационного пространства нельзя получить априорно еще до начала движения (в отличие, скажем, от задач, решаемых в статьях| [8— 10]). Построение в процессе движения робота модели конфигурационного пространства будем осуществлять на основе неявно задаваемого графа. Рассмотрим случай двумерного конфигурационного пространства, хорошо иллюстрирующий многие практически важные задачи планирования маршрута мобильного робота. Предложенный метод позволяет прокладывать траекторию изображающей точки в области, содержащей заранее неизвестные запретные зоны произвольной формы, требуя в каждый текущий момент только сигнала о том, находится ли изображающая точка в свободном пространстве или на границе запретной зоны.
МОДЕЛЬ КОНФИГУРАЦИОННОГО ПРОСТРАНСТВА
Введем обозначения: 0 — конфигурационное пространство; E/U п
U ©, где/ = 1, м,— односвязные запретные зоны; S = 0 \ |J Sy — часть конфигурационного пространства, не занятая запретными зонами; Оу 5 — граница запретной зоны S；; S \ U — свобод- ное пространство. Будем предполагать, что все границы 行力 где 7 = 1, м, имеют конечную длину и что минимальное расстояние между любыми двумя запретными зонами больше некоторой положительной величины А. Пусть известны начальное положение изображающей точки 0Н S S и целевое положение 0П 0.
Так как область S связна, цель 8口三5 достижима для изображающей точки. В противном случае, когда 0Ц Е 2 〃 где 1《/《м, цель недостижима.
,Модель конфигурационного пространства в явном виде можно было бы описать следующим образом. Проведем из точки 0Ц все возможные касательные к выпуклым участкам границ запретных зон
(рис. 1, а). Точки касания обозначим через О,门 где 乃=2, К (。1 = 0Н), а ближайшую к ОА точку пересечения линии。衣9Ц с какой- либо границей о力 где 1 £ /《м, (если такая точка существует)—
вид конфигурационного аространства( б — граф G
иерез 以，Ясно, что О^С^ U 5. Поставим в соответствие точкам 9% °к и Си,『Де "==],《, вершины графа G, а все возможные направленные отрезки。卜，卜(если точки С\ не существуем, то бервтся отро~ 30к °卜屮：)值 участки границ, соединяющие каждую точку 以■三 о ■ с каждой точки & 2 о力 будут соответствовать дугам этого графа G (рис. 1, 6)，Вообще говоря, дугам можно приписать определенную стоимость. '
Теорема. Цель 6й достижима для изображающей точки тогда 汉 только тогда, когда на графе G существует путь из точки О± = =°" 6 точку 6Ц, Этот путь определяет траекторию изображо.ющей точки.
По построению графа G всякому пути из точки Ог в точку 0Ц на зтом графе соответствует траектория 厶 U S, соединяющая 0'1 с 3 и состоящая из отрезков ка.с&тбльных 0卜6\ CZ S и участков границ 以。V CZ о； CZ 5, где 1 V W《К. Если цель достижима для изображающей точки, то существует некоторая траектория 厶丁 U S, соединяющая точки 6Н и 0Ц. Посредством непрерывной деформации в S траектория 厶丁 всегда может быть преобразована в кривую, имеющую форму траектории L. Следовательно, на графе G существует путь ИЗ ТОЧКИ Oj В точку 0Ц.
Еспп же цель недостижима, то 9Ц Е 2 厶 л на графе G не1Удуг 0曲・ Так как 9口 一 изолированная вершина, то пути из Oj в 0" не существует. Теорема доказана.
В процессе движения робота взвешенный ориентированный граф G, задающий модель конфигурационного пространства, строится в неявном виде с помощью операторов порождения вершин, соответствующих перемещениям изображающей: точки. Обозначим через Р = {^i, Г2, . . ., Fm} набор операторов, позволяющий, начиная с вершины О】=9日，строить все последующие вершины графа G.
Конкретное содержание каждого оператора зависит от используемого метода поиска пути. Однако в любом случае набор Г содержит оператор Г5, который применяется к вершине О& и порождает вершину С卜 (или сразу 0й), определяя дугу О^С^ (или 。才В”)， Оператор Г, соответствует перемещению изображающей точки из 0k по липт 0卜9" до попадания на какую-либо границу 行力 где 1《 /《 ", или же до достижения цели.
Остальные операторы Г2, . 0 ., Гт из набора Г применяются к вершинам, соответствующим точкам 以 W о力 где 1《乃《夂 и 1《 《/《％ и порождают вершины Ov, где 1 V v《К (точки Ov 三 о；), определяя дуги, исходящие из С*. Каждый из этих операторов соответствует перемещению изображающей точки вдоль границы Оу до достижения очередной (например, в порядке удаленности от С\. вдоль границы) точки касания 0丫 W о^. Для обнаружения точек касания в процессе движения изображающей точки по границе о; можно контролировать угол а между направлением движения в текущей точке / W cf? и направлением отрезка %6口 (см. рис 1, а): в точках касания sin а = 0.
АЛГОРИТМ ПОСТРОЕНИЯ ПУТИ
Используя предложенную модель, можно строить различные алгоритмы поиска пути роботом «вслепую» с учетом конкретных особенностей решаемых задач. При синтезе алгоритма следует иметь в виду, что дуги графа G имеют стоимость, определяемую, например, длиной соответствующих отрезков траектории, энергозатратами робота на перемещение по ним, либо какими-то другими критериями, а эффективность реп1ения задачи в общем случае зависит не только от стоимости окончательно найденного маршрута (простого пути на графе G), но и от затрат на сам процесс поиска этого маршрута- В соответствии с атим можно рассмотреть следующие два класса задач:
Л — маршрут ищется для многократных прохождений, и затраты на поиск сразу достаточно эффективного пути оправданы, если стоимость результирующего маршрута будет снижена;
Б — затраты, допустимые в процессе поиска пути, су1цественн(? ограничены, а стоимость проложенного маршрута не столь важна (например, он будет использован лить однократно либо может быть улучшен впоследствии по мере обучения робота функпионированик^ в данной среде).
Для решения задач класса Л при использовании предложенной модели могут быть применены многие известные алгоритмы поиска гГуто на графах (например, алгоритм Л*), позволяющие по графу G строить рациональные или даже оптимальные (в классе траекторий, определяемом способом построения графа) маршруты изображающей точки.
При решен ив задач класса Б необходимо иметь в виду, что «еле пой» робот для получения довой локальной информации о среде должен фактически передвигаться в ней согласно перемещениям изо*
ражающей точки в соответствии с алгоритмом поиска пути на графе G. Ясно, что в случае физических движений робота сам процесс нахождения маршрута (в отличие от «мысленного» планирования движения робота в известной среде) требует ощутимых затрат, которые можно охарактеризовать стоимостью того пути s, который прошла изображающая точка в процессе поиска, т. е. суммой стоимостей построенных дуг графа.
В известных публикациях эта особенность практически никак не учитывается. Здесь предлагается метод, позволяющий принимать ее во внимание, для чего описанная модель конфигурационного пространства определенным образом модифицируется: если на участке границы о；, соответствующем дуге C^Ov, имеется точка выхода прямой 0*9" из запретной зоны W力 то вводится дополнительная вершина 0心 где 1 V а《К, и рассматривается содержащий ее граф G'三 G. Такая модификация позволяет строить такой маршрут s, который содержит не всю дугу C^OV, а только ее часть С^Оа. Кроме того, что очень важно, это дает возможность сформулировать признак для установления факта недостижимости цели без полного построения графа G'・
Предлагаемый алгоритм поиска пути на графе G' использует набор операторов Г = {Г1? Гл> Гп}. Операторы Гл и Гп определяют две дуги, исходящие из 8k при обходе границы соответственно по часовой стрелке и против нее либо до первой из встретившихся по пути точек: точки。打 где а = 0, или точки Оа выхода прямой 6\9口 из зоны 2/, либо до возврата изображающей точки в С^. В последнем случае на графе G' образуется петля, т. е. дуга начинается и кончается в вершине
Алгоритм содержит следующие основные этапы.
К вершине Ок применяется оператор Г1? в результате чего либо осуществляется переход в вершину 0П (т. е. достигается цель, тогда — конец программы), либо строится вершина &• Важно, что верпгину & не надо сравнивать с построенными ранее вершинами Си, где р, = 1,乃,так как при принятом представлении конфигурационного пространства в виде графа она никогда не совпадает ни с одной из них.
К вершине & сначала применяется один из пары операторов (Гл, Гп). При этом либо образуется петля (изображающая точка возвращается в С\), либо строится вершина Ov. В первом случае делается вывод, что цель недостижима — конец программы. Во втором случае, если О* совпадает с какой-либо из вершин。乩，построенных ранее, то — переход к этапу 3, если же О* = ft+i есть вн^вь построенная вершина, то — переход к этапу 1 (乃：=% + 1).
В установленном для каждого конкретного случая порядке, не оказывающем влияния на факт сходимости алгоритма, к тем из построенных вершин С\, к которым до сох пор был применен только один оператор (Гл или Гп), применяется оставшийся оператор этой пары (соответственно Гп или Гл), и этот процесс продолжается до тех пор, пока либо не будет построена новая вершина Ok+i (тот 196
да — переход к этапу 1 (к:—к + 1)), либо не будет удовлетворено условие 2 описываемого ниже признака недостижимости цели (тогда — конец программы).
Признак недостижимост и цели. Она недостижима при выполнении хотя бы одного из двух условий: 1) на графе G' образовалась петля; 2) ко всем вершинам Ск, начиная с некоторого номера М & к, были применены оба оператора Гл и Гл, и каждый раз оказывались построенными ранее найденные вершины 。乩 с номерами 卩〉М.
Сформулированный признак является необходимым и достаточным условием для установления факта принципиальной невозможности достичь цели. Доказательство этого строится следующим образом.
Если цель объективно недостижима, то на графе G' не будет дуг QB", т. е. вершина 0Ц не может быть построена. Покажем, что в этом случае имеет место признак недостижимости. Предположим противное. Тогда каждый раз этап 3 будет заканчиваться формированием новой вершины。〃+工. Действительно, если бы ко всем вершинам от Ск до О】 уже были применены оба оператора Гл и Гп, но каждый раз оказывалось бы, что построенная вершина совпадает с ранее найденной вершиной。乩，где 1 V 卩《乃，то был бы обнаружен признак недостижимости (по условию 2), что противоречит предположению. Ввиду конечности графа G' процесс построения новых вершин не может продолжаться бесконечно, следовательно^ при отсутствии пути в 0Ц обнаружение признака недостижимости неизбежно.
Достаточность условия 1 признака недостижимости вытекает из теоремы Жордана, так как если образовалась петля, то прямая пересекает границу оу только один раз (в точке &); 0^ ^ S, следовательно, 0Ц 三 2/, где 1 ^ / ^ п. Для доказательства достаточности условия 2 мысленно удалим из конфигурационного пространства те из запретных зон S；, на границах которых по алгоритму до обнаружения условия 2 не построены точки, соответствующие вершинам графа G'. Очевидно, что если в полученном таким образом новом конфигурационном пространстве, содержащем запретные зоны £九, где /工=1,孔1, цель недостижима, то она недостижима и в исходном конфигурационном пространстве. Справедливо утверждение: при выполнении условия 2 признака недостижимости всякая касательная, проведенная из 0ц к границе 仃九,где 1《/工《孔工,пересекает по крайней мере одну из запретных зон 2中 где 1 £ 卩《 孔工,на отрезке от 9耳 до точки касания. Довольно громоздкое доказательство этого утверждения опустим (укажем лишь, что в нем используется теорема Жордана). Из этого утверждения следует, что при выполнении условия 2 не существует отрезка。囲 U S, т. е. цель недостижима.
Завершая описание алгоритма, отметим, что посредством исключения циклов из построенного пути на графе G' можно регулярным образом найти простой путь, определяющий маршрут робота при последующих перемещениях между точками, соответствующими Он и 机 、
Доказательство сходимости алгоритма. В процессе отработки предложенного алгоритма могут встретиться два случая: либо уста-
1971977* Заказ № 2408
197
197
навливается признак недостижимости цели, либо он не обнаруживается. В первом случае устанавливается факт недостижимости данной цели, во втором — этап 2 может завершиться либо построением новой вершины。卜+工 и возвратом к этапу 1, либо переходом к этапу 3. Как было показано выше, в результате выполнения этапа 3 при этих условиях всегда будет построена такая вершина О厶+i, применение к которой оператора 1\ на этапе 1 приведет к переходу в вершину 0Ц, т. е. и в этом случае «зацикливания» алгоритма не произойдет. Сходимость доказана.
Заметим, что в доказательстве сходимости алгоритма никак не использовались ни порядок перебора на этапе 3 построенных ранее вершин См ни порядок применения операторов Гл и Гп, ни конкретный способ перевода изображающей точки из текущего положения в одну из ранее построенных вершин 以一все это можно варьировать при настройке алгоритма с учетом особенностей конкретных решаемых задач.
РЕЗУЛЬТАТЫ МОДЕЛИРОВАНИЯ
Работа представленного алгоритма в задачах планирования движений роботов в сложных незнакомых средах исследовалась с помощью машинного моделирования. Программная реализация алгоритма на языке ФОРТРАН-IV при использовании операционной системы RT-11 потребовала приблизительно ЮК байт оперативной памяти (для графов, содержащих не более 60 вершин). Была проведена большая серия машинных экспериментов, в которых моделировалась прокладка маршрута в цель для мобильного робота, снабженного датчиками, сигнализирующими только о факте контакта робота с препятствием (что свидетельствует о попадании изображающей точки на границу какой-то из запретных зон). Эта задача отличается достаточной наглядностью, поскольку она эквивалентна задаче поиска пути изображающей точки, помещенной в центр робота, в целевую точку в двумерном конфигурационном пространстве.
Один из модельных экспериментов иллюстрируется рис. 2, а, где указаны заданные оператором начальное и целевое положения центра робота, а штриховкой выделены препятствия в рабочей среде, форма и расположение которых произвольно задавались оператором на экране дисплея. Тонкая линия со стрелками демонстрирует путь, пройденный роботом при поиске цели, а утолщенная линия соответствует результирующему маршруту, построенному в расчете на дальнейшие многократные прохождения робота между заданными точками. Видно, что в данном примере использование формируемой в процессе движения модели априорно неизвестной среды согласно предложенному алгоритму позволило улучшить планируемое движение робота.
Поведение робота в ситуации другого типа показано на рис. 2, б. Оператор модифицировал условия эксперимента, добавив в рабочую среду еще одно препятствие — перемычку (штриховка в другую сторону). Большинство известных методов планирования
"ауало"ауалоНачало
"ауало
"ауало
Phg. 2. Примеры нахождения пути в цель мобильным роботом (а) и поведения робота при недостижимой цели (6)
маршрута в незнакомой среде, если и не привели бы к зацикливанию движения робота, то потребовали бы перебрать все потенциально возможные траектории, фактически просканировав все доступное пространство, прежде чем сделать обоснованный вывод, что в такой среде цели вообще достичь нельзя. Действуя в соответствии с предложенным алгоритмом, робот достаточно быстро установил факт принципиальной недостижимости цели (см. рис. 2, 6) и прекратил движение, послав соответствующее сообщение оператору. *
Результаты многочисленных экспериментов показали, что при решении достаточно сложных задач во всех случаях, когда задавалась достижимая цель, предложенный алгоритм обеспечивал успешное выполнение роботом задания; если же цель была объективно недостижима, робот оперативно устанавливал этот факт. Немаловажно также, что быстродействие программ, реализующих описанный подход, позволило проводить моделирование в реальном масштабе времени. .
* * *
Предложенный и теоретически обоснованный для двумерного конфигурационного пространствач регулярный метод обхода препятствий в априорно неизвестной среде обладает следующими достоинствами: гарантируется нахождение пути в цель, если она вообще может быть достигнута;
устанавливается факт недостижимости тех заданных целей, которых принципиально достичь нельзя, причем введенный признак недостижимости позволяет уменьшить затраты на обследование среды по сравнению с другими алгоритмами；
допускается работа с препятствиями произвольной форлты без их аппроксимации какими-либо простыми геометрическими элементами и не требуется предварительное построение запретных зон в конфигурационном пространстве (это стало возможным благодаря предложенной модели конфигурационного пространства в виде неявно задаваемого графа, который может наращиваться в процессе движения робота «вслепую» на основе только локальной информации о его контактах с препятствиями);
использование сформированной модели, сконцентрировавшей в себе приобретенные знания о среде, позволяет выделять на построенном графе путь, соответствующий рациональному маршруту робота, рассчитанному на последующие перемещения между заданными точками;
эффективно реализуется на ЭВМ и может быть адаптирован к конкретным особенностям решаемой задачи с помощью вариации ряда настраиваемых процедур.
ЛИТЕРАТУРА
Petrov A. A., Sirota I. М. Control of a Robot-Manipulator with obstacle avoidance under little information about the environment.— In: Proc, of IFAC Vlllth Congr., Kyoto (Japan), 1981. Kyoto, 1981, vol. 14, p. 54—59.
Петров А. А., Сирота И. M. Формирование движений манипуляционного робота при обходе препятствий в условиях ограниченной информации о среде.— Автоматика и телемеханика, 1983, № 4, с. 29—40.
Сирота И. М. Планирование движения автономного робота для транспортировки грузов в ГПС без маршрутопроводов.— В кн.: Состояние и развитие гибких производственных систем. М.: МЦНТИ; МНИИПУ, 1986, с. 275 — 285.
Lumelsky V. J. On Non-heuristic Motion Planning in Unknown Environment: Prepr. 1st IFAC Symp. Robot Contr. Barcelona (Spain), 1985, p. 257—262.
Кирильченко A. А., Карпов И, И.^ Платонов A. К. Метод подцелей в задаче выбора трассы мобильного робота в условиях неопределенности: Препр. Ин-та прикл. математики им. М. В. Келдыша АН СССР № 16. М., 1983. 27 с.
Ильин В. А., Ильина Т. Р., Кориков А. М. Вопросы теории алгоритмов управления движением роботов в условиях неполной информации о внешней среде.一 В кн.: Информационные и управляющие системы роботов. М.: Ин-т. прикл. математики им. М. В. Келдыша АН СССР; МГУ им. М. В. Ломоносова, 1982, с. 170—177.
Петров А. А., Перфильева И. М. Об управлении движениями роботов-манипуляторов с помощью ГВС. — В кн.: Тез. докл. VII Всесоюз. совещ. по пробл. управления. М.; Минск: Ин-т пробл. управления; Ин-т техн, кибернетики АН БССР, 1977, с. 294—297.
Lozano-Perez Т. Automatic Planning of Manipulator Transfer Movements.—
IEEE Trans. Syst,, Man and Cybern., 1981, vol. SMC-11, N 10, p. 681—698^"
Gouzenes L. Strategies for Solving Collision-Free Trajectories Problems for Mobile and Manipulator Robots.— Intern. J. Robot. Res., 1984, vol. 3, N 4, p. 51—65.
Малышев В. 4., Тимофеев Л. В. Алгоритмы построения программных движений манипулятора с учетом конструктивных ограничений и препятствий.—— Техн, кибернетика, 1978, № 6, с. 64—72.
УДК 621.865.8-5.С01.5
ПРОГРАММНО-АЛГОРИТМИЧЕСКОЕ ОБЕСПЕЧЕНИЕ ДЛЯ^АНАЛИЗА ИЗОБРАЖЕНИЙ
В СИСТЕМАХ ТЕХНИЧЕСКОГО上ЗРЕНИН
А. М・ Михайлов
Техническое зрение становится неотъемлемой частью адаптивных роботов и играет все большую роль по мере повышения степени ин- теллектности робототехнических систем. Быстро растет число промышленных применений систем технического зрения.
Для систем машинного зрения характерно то обстоятельство, что при их создании программно-алгоритмические и аппаратные вопросы необходимо решать в тесной взаимосвязи. Это обусловлено тем, что реализация алгоритмов машинного зрения требует крайне высокой производительности ЭВМ. Вместе с тем необходима ориентация на микропроцессорную технику, что определяется требованиями экономичности и возможностями широкого внедрения в промышленность.
Такие требования накладывают ограничения на класс алгоритмов, использование которых допустимо с точки зрения реализуемости.
Как показал анализ алгоритмов технического зрения с точки зрения реализуемости, многие теоретически хорошо проработанные подходы оказались неадекватными [1].
Некоторые замечания цо терминологии. Следует различать механическое переснятие в память изображения объекта и анализ этого изображения. В последнее время все чаще можно встретить термин «понимание изображения». В первом случае выходная информация имеет вид матрицы яркостей ｛卩乳切｝ при п, т = 1, N, где рпт — яркость точки матрицы с координатами (тг, zn); N X N — формат кадра. Во втором случае выходная информация системы зрения имеет вид некоторой модели наблюдаемого объекта или сцены. Таким образом, понимание изображения сводится к . построению и интерпретации модели сцены.
Термин «распознавание» часто используется в смысле, идентичном термину «классификация». При распознавании система выполняет классификацию, т. е. определяет типы объектов. Результатом анализа является модель структуры наблюдаемых объектов и (или) их взаимосвязи.
Типичные задачи, 'решаемые системами технического зрения. В целом задачи можно подразделить на дву- и трехмерные, предметные и структурные, статические и динамические [2].
Целью анализа изображений в двумерных предметных задачах обычно являются:、
выделение объектов на изображении;
распознавание типов объектов независимо от их угловой ориентации, положения на плоскости и в заданных пределах от масштаба;
определение плоскостных и угловых координат объектов.
В трехмерных предметных задачах основная дополнительная операция —это определение дальности до выделенных объектов.
Структурные задачи связаны с построением и анализом машинных моделей таких объектов, как чертежи, рисунки,изображения печатных плат, кристаллов интегральных схем и др.
Динамические задачи возникают при необходимости мониторинга объектов изображения в реальном масштабе времени.
Машинные модели. Используемые в качестве внутреннего машинного представления при анализе изображений модели можно подразделить на векторные (интегральные) и структурные [2].
Векторная модель — это вектор признаков, являющихся результатом некоторого линейного или нелинейного преобразования матрицы изображения.
В простейшем случае (метод эталонного сравнения) оператор преобразования имеет вид тривиальной единичной матрицы Е:
E ｛鳴｝ = ｛鳴｝，
где % — номер изображения, т. е. модель изображения — это матрица изображения, формат которой совпадает с форматом кадра. Очевидный недостаток такого подхода состоит в том, что требуется слишком много памяти из-за большой размерности каждого эталона (N 义 N точек). Тем не менее такой подход находит применение в задачах контроля качества, где зачастую требуется всего один эталон — контрольный образец. Другой недостаток этого метода — сложность обеспечения инвариантного распознавания при поворотах и сдвигах. Эталонный метод использует применение при необходимости детального контроля сложной структуры.
Операторное распознавание (линейное) в общем случае имеет следующий вид:
p爲覆=直，где = l，%
Здесь ｛p^m｝ — матрица i-го] изображения； ｛无Lj — fc-я матрица оператора; f(^ — fc-й признак i-го изображения; к ——номер признака.
К достоинствам операторного распознавания относятся: снижение размерности модели (К %N X TV);
возможность обеспечения инвариантности относительно геометрических преобразований при соответствующем выборе последовательности суммирования;
повышение надежности распознавания за счет осреднения при суммировании.
Недостатком подхода является сложность обнаружения малых дефектов объекта как следствие операции осреднения.厂、
Структурная модель представляет собой набор выделенных структурных элементов изображения объекта (например, множество узловых точек) и отношений между ними;
(能£〃，при 詳 / = I,
где J — число выделенных элементов объекта; L — некоторое отношение; di — 力-н узловая точка.
Структурные модели отличаются инвариантностью ко многим преобразованиям. Например, такие характеристики, как число контуров и их смежность, не изменяются при сдвигах, вращенияхf сжатиях и растяжениях.
Критерии интерпретации моделей. Выбор критерия зависит от типа используемой модели. Рассмотрим ряд критериев интерпретации векторных моделей.
Пусть #） при к — 1, К — вектор признаков г~го класса, где / ^ / — общее число распознаваемых классов.
Алгоритмы интерпретации могут быть основаны, в частности, на среднеквадратичном критерии к
仇一津）2 М min■
Л'=1
или критерии Чебышева‘
max IД.—梨 I — min,
где 九 при к — 1^ К — вектор признаков классифицируемого входного объекта.
Эти критерии используют аддитивную пространственную норму. Более эффективным критерием в отношении помехоустойчивости является мультипликативный критерий вида
к
max 1% 17（"伊［ + с）, I梨 1/（1 加 I）},
где константа с зависит от динамического диапазона признаков.
Результатом интерпретации векторных моделей является ответ на вопрос о типе каждого объекта. Интерпретация структурных моделей позволяет получать более детальную информацию, например о дефектах внутренней структуры. Более того, поскольку структурная модель — это некоторое геометрическое представление объекта, она позволяет воспроизвести его в идеализированной графической форме.
Типовые математические операции. В рассматриваемом алгоритмическом анализе изображений используются два класса математических операций. Первый класс составляют локальные операции и второй —— нелокальные.
В общем случае локальные операции можно представить в следующем виде:
Рпт = / {Р„+г, т+Р ПРИ （^ j）^W XW И П, где / — арифметическая или логическая функция, значение которой зависит от состояния всех элементов изображения локального окна; п, т ——координаты точки в матрице выходного изображения; W X W —— формат локального окна, значительно меньший формата кадра; N X N — формат кадра.
Последовательность точек изображения, проходимых центром локального окна, зависит от типа системы сканирования. Используются три вида сканирования: линейное, полярное и контурное.
Линейное сканирование ——это построчный просмотр кадра. При полярном сканировании локальное окно проходит по системе концентрических окружностей, центр которых расположен в заданной точке, например в центре тяжести анализируемого объекта. При контурном сканировании траектория адаптируется к форме анализируемого объекта, обходя по определенным правилам его контур.
Нелокальные операции выражаются в общем случае в виде
У = / {Рпт} при (тг, m)三 S,
где у —— результат линейного или нелинейного преобразования /;
S — множество точек, проходимых в процессе сканирования.
Рассмотрим несколько примеров локальных операций (формат окна W X W выбран равным 3 X 3):
сглаживающий фильтр:
」1, если pn+ii 扁=1 V (3) X 叫 расширяющий фильтр:
1, если 2 р研…〉2, О,-]；1, если 2 р研…〉2, О,-]；
1, если 2 р研…〉2, О,-]；
1, если 2 р研…〉2, О,-]；
оконтуривающий фильтр:
1；；если рпт = 1 и 2^< 2 Pz,m+j<8, О,
Варьируя логическую функцию локального окна форматом 3x3, можно получить 2512 различных типов препарирования бинарных изображений, поскольку общее число входных ситуаций филь-， тра равно 512. Фильтр про гр аммируетс я в общем виде:
СприООООООООО卩2приОООООО001卩3приОООООО010• • •♦ • ♦* ♦ •♦ ♦ •• • •P512приш111шСприООООООООО卩2приОООООО001卩3приОООООО010• • •♦ • ♦* ♦ •♦ ♦ •• • •P512приш111ш,где 凡三{0, 1} и i= 1, 512.,где 凡三{0, 1} и i= 1, 512.
С
при
ООО
ООО
ООО
卩2
при
ООО
ООО
001
卩3
при
ООО
ООО
010
• • •
♦ • ♦
* ♦ •
♦ ♦ •
• • •
P512
при
ш
111
ш
С
при
ООО
ООО
ООО
卩2
при
ООО
ООО
001
卩3
при
ООО
ООО
010
• • •
♦ • ♦
* ♦ •
♦ ♦ •
• • •
P512
при
ш
111
ш
,где 凡三{0, 1} и i= 1, 512.
,где 凡三{0, 1} и i= 1, 512.
В системе технического зрения, разработанной в составе комплекса ПИКОМ [21, рассматриваемый фильтр реализован аппаратно на базе микро-ЭВМ «Электроника-60» и выполняет одну операцию ире~「 парирования изображения за 20 мс. Операции фильтрации могут проводиться итеративно и сопровождаться при необходимости сменой логической фильтрующей функции.
Такая аппаратура позволяет создавать системы обработки изображений с обратной связью, в которой за такт времени в 20 мс：срав- ниваются по заданной логике входной кадр и кадр, поступивший по обратной связи (рис. 1):
△厶=(〃㊉/(△/n-i))mod 2，
где In ——изображение, поступившее в тг-ii момент времени; z*1 —— элемент задержки; A7n — рассогласование между изображениями; / — локальный фильтр;㊉ 一операция поточечного сложения кадров” по mod2 или по какой-либо другой логической функции.
Структура с обратной связью по изображению позволяет управлять динамикой изменения образов.
Рис. 1. Структурная схема обработки изображений с обратной связью
Рассматриваемый метод локальной фильтрации применяется длж обработки бинарных изображений. Непосредственное перенесение этого способа на случай многоградационных изображений невозможно, так как невозможно запрограммировать реакцию фильтра на все входные ситуации вследствие резкого увеличения их числа. Действительно, уже в случае 16 градаций яркости, когда для представления одной точки изображения требуется четыре двоичных разряда, число, входных ситуаций в рамке 3x3 составит 29Х4 ^ 64 млрд.
Однако если изменить понятие входной ситуации, то способ локальной фильтрации можно использовать и в случае многоградационных изображений. Для этого под входной ситуацией будем понимать не состояние девяти разрядов (%,月2, . . •, ц) локального окна W X W, где ij W {0,15}, а состояние перепадов яркости в цепочке' последовательно взятых соседних разрядов. Тогда входная ситуация описывается, например, в виде % = %, % * %, % 市 厶，％ = 点， у =加，方6 * %, % =»8・ При таком подходе общее число входных ситуаций равно 256. Опыт показывает, что с помощью так определенного фильтра с многоградационными изображениями могут быть эффективно выполнены те же основные операции, что и с бинарными, и в том числе оконтуривание.
Рассмотрим теперь контурное сканирование. Приведем пример* локальной операции, реализуемой в процессе контурного сканирования и используемой для создания структурных моделей изображений. В этой операции в качестве анализируемой локальной области используется окружность малого радиуса, центр которой движется по контуру анализируемого объекта.
В процедуре*
с (INT (п + R cos (2пк/N)) — сп (А),
£ (INT (иг + К sin (2滋/N)) = sm (А)
для каждой контурной точки с координатами (п, иг)三 С, где С —— множество всех контурных точек, просматриваются точки с (А), $ (к) локальной окружности, где к ~ О, М — 1.
Здесь R — радиус локальной окружности; М ——число дискретных точек локальной окружности.
С помощью соответствующего выбора логической функции / {“(%), §m (左)}, где к = О, М — 1, можно идентифицировать тип каждой контурной точки (лежащая на прямолинейном отрезке, угловая, ветвление и т. д.).
Этапы обработки изображений. В системах технического зрения можно выделить три этапа обработки: предварительная обработка, построение описаний, интерпретация описаний.
С точки зрения соотношения между объемами входной и выходной информации первый этап существенно отличается от второго. При предварительной обработке объем выходной информации равен объему входной: входная матрица изображения, содержащая ^2 точек, преобразуется в выходную матрицу, содержащую также N2 точек. Основными задачами предварительной обработки являются: подавление помех, сглаживание, оконтуривание, разделение объектов, выделение срединных линий объектов и т. д.
На втором этапе проводится существенное редуцирование объема информации. Основные задачи при построении описаний — вычисление векторных признаков и формирование структурных моделей. Объем информации, представляющей признаки и (или) модель объектов, намного меньше объема входной информации, что необходимо для обеспечения ее анализа на этапе интерпретации в реальном масштабе времени. Например, при анализе контурных точек с помощью локальной окружности получаем совокупность характерных структурных точек, число которых значительно меньше, чем №.
Примером алгоритма построения описаний и их интерпретации является следующая процедура формирования векторных признаков, которая обеспечивает их инвариантность относительно сдвигов и вращений распознаваемых объектов：
NT
^оРпф,^т^^еХР(~ i2^/N)\ 口 PH P = Pmin，Pmax， (今 где р — полярный радиус; ф — полярный угол; N — число дискретных полярных углов; pmin, Ртах —— минимальный и максимальный радиусы полярной системы сканирования, центр которой помещается в центр тяжести распознаваемого объекта. Пространственная инвариантность вектора признаков /р, где р = pmin, ртах, определяется тем, что амплитудные характеристики одномерных преобразований Фурье по окружностям не зависят от угловой ориентации распознавае- ■мого объекта. Используемое число концентрических окружностей 206
обусловливается сложностью внутренней структуры объекта и требованиями к помехоустойчивости распознавания. Информация, содержащаяся в фазовой характеристике преобразования, определя- ©т угловую ориентацию объекта.
Алгоритмические модули. Рассмотренная система анализа изображений реализуется с помощью комплекса алгоритмов, состоящего из следующих основных модулей:
ввода изображений и локальной фильтрации;
контурных описаний;
полярного распознавания;
интерпретации векторных моделей； управляющий модуль верхнего уровня.
Первый модуль реализует этап предварительной обработки. В процессе сканирования локального окна форматом W X W для каждой точки рпт матрицы входного изображения в локальной окрестности анализируются перепады яркости (в случае многоградационных изображений) или состояния разрядов (в случае бинарных). Значение яркости соответствующей точки рпт выходного изображения является функцией состояния локального окна. На входе и 五а выходе данного модуля информация имеет вид матриц изображений.
Модуль контурного описания осуществляет поиск очередного контура в кадре с помощью линейного сканирования и процедуру отслеживания контура очередного анализируемого объекта. В процессе прохождения контура проводится анализ локальной окружности каждой контурной точки, что^позволяет определить ее тип. На выходе данного модуля информация имеет вид массива последовательности координат и типов контурных точек. Кроме того, для контура каждого изолированного объекта вычисляются координаты его центра тяжести.
Модуль полярного сканирования реализует соотношение (1) и находит пространственно-инвариантный вектор признаков. При этом возможно движение центра полярного сканирования в непрерывном режиме построчно либо перемещение скачками в центр тяжести очередного распознаваемого объекта. Выходная информация модуля имеет вид последовательности векторов признаков.
Модуль интерпретации сравнивает вектора признаков в темпе их поступления с эталонными векторами, число которых равно числу распознаваемых классов. Сравнение осуществляется в соответствии ■с аддитивными и мультипликативными критериями. При интерпретации структурных модулей работа проводится с описаниями в виде наборов характерных точек и отношений между ними.
Управляющий модуль, являющийся программой на языке высокого уровня, координирует работу модулей нижнего уровня и ведет диалог с пользователем в процессе постановки задачи и обучения. В ходе анализа изображений данный модуль управляет последовательностью операций и параметрами функционирования модулей.
Прикладной пример. Для иллюстрации работы системы анализа изображений рассмотрим локализацию заданного объекта в некото-
Рнс. 2. Л окализация контактных площадок кристаллов интегральных схем
а — исходное изображение (большие белые пятна — локализуемые контактные площадки； остальные мелкие объекты — помехи); б — частично отфильтрованное;
рой структуре. Такая задача возникает, в частности, при анализе фрагментов кристаллов интегральных схем. На рис. 2, 〃 приведено исходное изображение, содержащее контактные площадки, форма ко- торнх близка к прямоугольной, и помехи, образованные бликами и напыленными проводниками.
Пусть, например, требуется локализовать угловую контактную площадку. При этом локализация должна быть выполнена инвариантно относительно поворотов и сдвигов. На этапе предварительной обработки изображения в результате адекватного подбора локал^ ных фильтрующих функций можно удалить все объекты, за исключением совокупности контактных площадок. Последовательность
Рис- 2 (окончание)
_ полностью ошлценное фильтрацией от помех; е — локализова1Ш<1я угловая контактная площадка
итераций локальной фильтрации показана на рис. 2, бг. Определение места каждой контактной плотцадки в общей структуре проводится с помощью модуля полярного распознавания.
Относительно центра тяжести каждой контактной площадки вычисляется преобразование (1). Максимальный радиус системы концентрических окружностей выбирается таким, чтобы покрыть общую структуру. При нахождении центра полярного сканирования в угловой контактной площадке критерий распознавания имеет максимальное значение. Для решения этой задачи возаюжны также п другие последовательности операций, в частности применение модуля контурных описаний.
* * *
Рассмотренный в работе подход к построению систем техническогс зрения позволяет создавать системы анализа изображений, решающие достаточно общие задачи, такие, как:
пр остр анственно-инв ари антное распознавание и локализация объектов;
распознавание структурных изображений и рельефов сцен;
управление динамикой изображений.
Однако работа системы в реальном масштабе времени может быть обеспечена только посредством специальной аппаратной реализации основных алгоритмических модулей.
ЛИТЕРАТУРА
Куа^е Ф. Взаимодействие робота с внешней средой. М.: Мир. 1985. 285 с.
Вычислительная техника в робототехнических системах и ГАП: Учеб, пособие для втузов/ В. 3. Рахманкулов, Ж. П. Ахрамеев, В. В. Герасимов, А. М. Михайлов, G. А. Переслени, Е. В. Наумов: Под ред. И. М. Макарова. М.: Высш, шк., 1986. 144 с. (Робототехника и гибкие автоматизирован- ные^ производства. В 9 кн.; Кн. 4).
УДК 681.32
МОДЕЛИРОВАНИЕ РОБОТИЗИРОВАННОГО
ОБОРУДОВАНИЯ В ЗАДАЧАХ
ОРГАНИЗАЦИОННО-ТЕХНОЛОГИЧЕСКОГО
УПРАВЛЕНИЯ ГИБКИМИ АВТОМАТИЗИРОВАННЫМИ
ПРОИЗВОДСТВАМИ
В. А. Исаченко, В. С. Шишкин, В. Я. Полыскалин
Состав и структура модели. Современное роботизированное технологическое оборудование (РТО) представляет собой сложную техническую систему, характеризуемую большим многообразием составляющих ее элементов. Если для описания системы выбрана совокупность наименований переменных /1, д, . . ., хп, то состояние этой системы в произвольный момент времени t определяется набором значений хх (才),g (%)，• •・,％ (力,где g &) — значение переменной g при % =彳，2, . . " в момент времени t.
(О(ОФормально структура модели РТО описывается набором
(О
(О
N - (Q, S, F, Мо),
где Q = {鱼,依，.…，go} — набор переходов; S = {s^ 码，•…，si?)— набор позиций; F ——связи между элементами 象 и s£ Мо —— начальная маркировка, сопоставляющая каждой позиции наличие и而 отсутствие объекта.
Модель технологического оборудования в виде Е~сетц
Кружок — позиция； жирная черта — переход; точка внутри кружка — маркер; д^ при г = ГД 0 и Х^ при ; = 1, 3——основные и вспомогательные переходы соответственно; 近■— имеется хотя бы одна партия деталей на обработку и (или) контроль; s21 $з и б& — S? и б% $4 — оборудование соответственно не занято, исправно, загружено; $8, s11( s17 — разрешающие позиции; s10 — оператор на месте; $12 — оборудование неисправно (профилактическое обслуживание по потребности)； sI3 и 514 — 6歧—оборудование не занято (соответственно обработанная партия деталей отправлена на склад и из-за поломки оборудования необработанная партия передана на другой станок)
В процессе эксплуатации оборудование переходит из одного состояния в другое. Модель переходов, или, говоря, другими словами, модель РТО в виде Е-сети [1] представлена на рисунке.
В качестве переменных целесообразно использовать булевы переменные, характеризующие состояние оборудования с позиций задач оперативного управления гибким автоматизированным производством (ГАП).
В общем случае комбинация из четырех булевых переменных позволяет идентифицировать 16 различных состояний РТО, однако физический смысл имеют лишь девять из них (см. таблицу).
Допустимые состояния РТО
№
Состояние оборудования
Идентификатор
Код J
Переход на рисунке
1.
Простой межоперационный
Zo
1000
X
2.
Загрузка
21
1101
Qi
3.
Наладка
Z2
1100
倣
4.
Готовность
G
1110
%
5.
Обработка
Z&
1111
9б
6.
Разгрузка дри аварийном или нормальном завершении работы
%
1001
仙，gio
7.
Техническое обслуживание плановое или по потребности
Ремонт в процессе
辐
0000
8.
наладки
Z7
0100
如
9.
обработки
2g
оно
98
Оборудование исправно и находится в состоянии «межоперационный простой» (力1 = 1;力2 =力3 =力4 = 0) с момента ввода в эксплуатацию, окончания обработки очередной партии деталей или окончания сложного ремонта (планового или внеочередного).
В состоянии << загрузи а» (勺=g = 1; / = 0； / = 1) РТО находится при поступлении с оперативного склада (или накопителя) очередной партии деталей или технологической оснастки, в состоянии «наладка» (勺=^ = 1；力3 = 4 = 0) — с момента поступления технологической оснастки, необходимой для обработки очередной партии деталей, до окончания этой операции.
В состояние «готовность» (/ = & = / = 1； 4 = 0) РТО переводится после окончания наладки, в состояние《разгрузка» (/ = 1; 力2 = 力3 = 0; £4 = 1) —— после передачи обработанной партии деталей и технологической оснастки на оперативный склад или накопитель.
Кроме шести основных состояний (см. № 1——6 в таблице), оборудование может находиться в состоянии ремонта. Причем здесь возможны следующие случаи (см. соответственно № 7—9 в таблице):
力1 =力2 =力3 =力4 = 0 (оборудование не выполняет никаких операций);.
"丄,人3 人4
N] — 0；/21；/40®
Состояние капитального ремонта оборудования не рассматривается в связи с большими межремонтными интервалами.
Для переходов ^ь ^2 и qQ реализуются соответственно следующие логические функции:•
Л 53 Л S3,
Л ($4 ㊉ sll)i
S9 /\ ($8 ㊉ S10)・
Каждому переходу ставится в соответствие математическое ожидание и дисперсия времени срабатывания.
Закон изменения состояния оборудования z» (方)можно записать в виде
Zi (方)=% + a (小一方)，
где tZi — ожидаемое время прерывания в состоянии z^ а = —1 — скорость изменения состояния оборудования; т> ——момент времени перехода оборудования из состояния z» в состояние 2；.
В процессе убывания величина z? «) достигает значения, равного нулю в момент времени 方* = % + т^, что означает, что совершается «мгновенный» скачок и оборудование переходит из состояния z^ в одно из разрешенных состояний 2；.
Взаимодействие элементов модели. Состояние модели в о6гце『 случае не остается постоянным и может изменяться по определенным 212
правилам, которые при заданной структуре сета определяют ее динамику. Изменение состояния сети означает перемещение объектов из одних позиций в другие вдоль дуг через соответствующие переходы. Правила перемещения объектов следующие.
Прежде всего объект может перемещаться только из входной позиции перехода в его выходную позицию. Для этого перемещения необходимо, чтобы соответствующий переход стал активным, что возможно лишь в том случае, когда в каждой из его входных позиций имеется хотя бы один объект. Исключение составляют переходы 01 и 02，активизация которых осуществляется в соответствии с логическими функциями
八(S11 ㊉ sj и S9 A(S8 Ф Sio).
Интервал, в течение которого длится фаза активности перехода, задается временем его срабатывания.
Процедура иреобразования (изменения состояния) выражает действие над атрибутами объекта (технологического оборудования), перемещающегося через переход. Таким образом, каждый объект, пересекающий переход, задерживается на время t и подвергается преобразованию.
Важной особенностью модели РТО является наличие в ней разрешающих позиций $8, §□ и $17, которые играют управляющую роль для тех переходов, с которыми они связаны, и позволяют организовать в модели условные ветвления и переключения при перемещении объекта：
Л — оборудование неисправно (поломки в процессе наладки),
S8S8В — отсутствует оператор,
S8
S8
С —оборудование налажено;
'』1——оборудование неисправно (поломка в процессе обработки),
В — отсутствует оператор,
0 — оборудование не налажено (требуется подналадка),
后一партия деталей обработана,
Л2——оборудование нвислравно (профилактическое обслуживание по потребности);
-』з— оборудование неислравно (плановое профилактическое обслуживание),
尸—оборудование не занято (обработанная партия деталей отправлена на склад).
Выбор пути перемещения (разрешающая процедура) объекта из позиций $7, $11 и $17 осуществляется в соответствии с выражением 7：器閣j
где Р(02)н —— координата нижней границы участка на отрезке (0, 1), характеризующего относительное время пребывания оборудования в состоянии дз г — реализация равномерно распределенной в интервале (0* 1) случайной величины; i = / 回)一множество номеров
переходов, связанных с позицией £,; (i + а) — номер перехода, ближайшего к переходу 生 и выходящему из одной и той же позиции Sj.
Расчет вероятности перемещения объекта из позиции Sj к переходу осуществляется по формуле
Р 例)~ Р%12 Pzi ПРИ »— / б/),
где Pz. — вероятность пребывания оборудования в состоянии «加 Для расчета вероятности пребывания оборудования в состоянии qt используется выражение
Pq = GJ7кпри方/三T用，
где ZQ.—— время пребывания оборудования в состоянии д^ в интервале планирования Т; 7\ ——режимный фонд времени работы оборудования в интервале планирования Т.
Процесс взаимодействия элементов модели можно представить следующим образом.
В начальный момент времени £° Е 7 (до запуска модели) в пози циях s2, S3, % — s7, & и Si。помещаются маркеры, обеспечивающие при исступлении объекта условия активизации для соответствующих переходов. Начальная маркировка отражает нахождение оборудования в состоянии межоперационного простоя.
При возбуждении генератора X внешним источником в позиции Si формируется маркер и запускается переход 夕厶 что соответствует выдаче локальной системой управления технологическим оборудованием сообщения о начале загрузки РТО:
.% = %, Тк, /),_
где ук — сообщение о состоянии оборудования в момент времени 看卜三 7； z^ ——код состояния оборудования в момент времени т&; / ——дополнительная информация, варьируемая в различных сообщениях и содержащая, например, номер станка, шифр детали, номер операции и т. п.
Дальнейшее функционирование модели осуществляется в соответствии со схемой, представленной на рисунке
Программное обеспечение модели. В режиме отображения модель РТО функционирует в рамках локальной вычислительной сети мини- и микро-ЭВМ. Основными компонентами этой сети являются: локальная система управления технологическим оборудованием: центральная ЭВМ;
автоматизированное рабочее место диспетчера；
модули связи локальной системы управления технологическим оборудованием и автоматизированным рабочим местом диспетчера с центральной ЭВМ
В качестве центральной ЭВМ используется ЭВМ СМ-4 с операционной системой ОС РВ и комплектом программ, необходимых дин обработки информации^ поступающей от система диагностики Р严 214
или от оператора локальной системы управления. В качестве внешней памяти для хранения этой информации используются накопители на магнитных дисках.
Для связи локальной системы управления и автоматизированного рабочего места диспетчера с ЭВМ СМ-4 используется модуль дальней связи, выполненный на аппаратуре в стандарте КАМАК.
Программное обеспечение модели оформлено в виде отдельного модуля, включающего в себя программы:
ввода оперативных директив и организации вычислительного процесса;
организации и ведения информационных массивов модели;
выдачи и отображения результатов моделирования.
Оператор локальной системы управления непосредственно взаимодействует с драйвером терминала или модулем интерфейса клавиатуры, рассчитанного на работу с дисплеем типа ВИДЕОТОН-340.
При работе с моделью оператором локальной системы управления используется набор директив.
При получении директивы программой ввода формируется запрос, который с помощью модуля дальней связи передается на центральную ЭВМ, о нем свидетельствует индикация передачи запроса на экране дисплея.
При поступлении запроса иа центральную ЭВМ программа организации вычислительного процесса анализирует содержание полученной директивы и обеспечивает выполнение всех необходимых преобразований, связанных с вычислениями и корректировкой массивов модели по их результатам. Для регистрации времени перехода оборудования из одного состояния в другое используется таймер.
Первоначальные исходные данные, требуемые для функционирования модели РТО, вводятся с терминала диспетчера или переписываются с помощью программы организации информационных массивов из базы данных системы организационно-техно логического управления ГАП.
Диспетчер непосредственно взаимодействует с драйвером терминала или модулем интерфейса клавиатуры.
При пост^ пленпп через модуль дальней связи запроса на центральную ЭВМ программа выдачи и отображения результатов моделирования анализирует содержание полученной директивы и обеспечивает выполнение всех преобразований, связанных с распечаткой результатов моделирования на алфавитно-цифровом печатающем устройстве или с отображением состояния оборудования на экране дисплея.
Для реализации режима имитации программное обеспечение модели включает в себя также датчики случайных чисел, равномерно распределенных в интервале (0, 1), и программу имитации моментов перехода оборудования из одного состояния в другое。
ЛИТЕРАТУРА
1. Костин А, £・ Принципы моделирования сложных дискретных систем: Учеб, пособие. М.: МИЭТ, 1983.
СРЕДСТВА ПРОГРАММИРОВАНИЯ
И МОДЕЛИРОВАНИЯ ДЛЯ РОБОТОВ
И ГИБКИХ ПРОИЗВОДСТВЕННЫХ СИСТЕМ
УДК 681.32
ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ГИБКИХ АВТОМАТИЗИРОВАННЫХ ПРОИЗВОДСТВ
М. В. Дудкин, Ао И. Казьмин, А. А. Ме^н, В. Н. Пополитов
Разработка гибких автоматизированных производств (ГАП) способствовала развитию нового класса управляющих систем на основе распределенных вычислительных комплексов. Область приложения распределенных систем управления постоянно расширяется, увеличиваются их функциональные возможности. В этих условиях проектирование распределенных систем управления для ГАП стало слояшой инженерной задачей, решение которой невозможно без создания инструмснтальных средств поддержки разработки.
Однако прежде чем рассматривать методы автоматизации проектирования программного обеспечения отметим некоторые особенности систем управления гибких производств [1].
Распределенная система управления. Технической базой систем управления ГАП служит, как правило, распределенный вычислительный комплекс, упрощенная структурная схема которого показана на рисунке. Как и в других публикациях о распределенных системах управления (см., например, [2, 31), будем абстрагироваться от физической реализации среды передачи, так как создаваемые инструментальные средства должны быть применимы при различных реализациях среды передачи.
Использование функциональной схемы распределенной системы управления имеет большое значение для проектирования инструментальных средств поддержки разработки. Функциональная схема определяет предполагаемое распределение задай между, вычислительными машинами распределенной системы управления и типы информационных связей между задачами. Функциональная схема распределенной системы управления, примененная в разработках ГАП [1]% показана на рисунке (функциональная схема не отражает структура соединений ЭВМ, поэтому структурная и функциональная схемы могут в общем случае не совпадать).
В функциональной схеме распределенной системы управления выделены три группы ЭВМ:
Передающая среда
I ЭВМЭВМ •・• ЭВМ
6
Структурная (а) и функциональная (б) схемы вычислительного комплекса распределенной си- стеты управления
первая условно названа контроллерами (ЭВМ-контроллеры управляют технологическим оборудованием; в качестве примера контроллеров сошлемся на ЭВМ, входящие в состав числового программного управления (ЧПУ) станков, или на ЭВМ, управляющие роботами);
вторая ——ЭВМ-координаторы (объединяют контроллеры в систему управления производственным модулем или группой модулей);
третья группа ЭВМ, выделенная на функциональной схеме,— ЭВМ, планирующие работу оборудования (функции этой группы мало изменяются при переходе на распределенное управление; как и в случае централизованных систем автоматического управления, планирующие ЭВМ решают задачи календарного и оперативного планирования, учета, ведения документации и т. д.).
Анализ функциональной схемы системы управления показывает, что при распределенном управлении появляется один существенно новый компонент ——ЭВМ-координаторы.
Введение ЭВМ-координаторов создает следующие преимущества: упрощается организация совместной работы нескольких контроллеров;
появляются дополнительные возможности развития системы управления за счет введения новых координаторов и контроллеров или модификации программного обеспечения уже работающих ЭВМ (при этом существенно, что модификация программного обеспечения имеет локальный характер)；
упрощаются программное обеспечение и технические средства контроллеров (появляется возможность использовать контроллеры, которые не имеют специальной ориентации на работу в составе гибкого автоматизированного производства);
с помощью координаторов можно повышать отказоустойчивость системы управления (резервируя функции координации одних и тех же контроллеров в нескольких ЭВМ, можно добиться высокой степени отказоустойчивости; в случае отказа одного координатора управлять группой контроллеров сможет другая ЭВМ-координатор, в которой зарезервировано соответствующее программное обеспечение).
8 Заказ № 2408217
Создание программного обеспечения расцределенной системы управления ГАП превращается, по сути, в разработку программного обеспечения ЭВМ-координаторов и подбор подходящего для данного применения обеспечения планирующих ЭВМ и ЭВМ-контроллеров. В соответствии со своим функциональным назначением ЭВМ-координаторы должны решать следующие задачи:
управление контроллерами (выдача заданий контроллерам и проверка результатов выполнения заданий, которые могут выдаваться различным контроллерам строго последовательно или последовательно-параллельно; последовательно-параллельный способ управления требует от координаторов наличия режима разделения времени, что усложняет их программное обеспечение, однако при этом способе может быть достигнуто ускорение технологического процесса за счет одновременной работы нескольких контроллеров);
обмен информацией с другими ЭВМ-координаторами (информационные связи, которые должны быть установлены между координаторами, в значительной степени зависят от особенностей конкретного производства; при изменении производственного процесса, как правило, возникает необходимость в изменении информационных связей; вследствие этого желательно иметь такие инструментальные средства, которые позволяют программировать связные функции и не затрагивают при этом функции управления контроллерами);
взаимодействие с ЭВМ-менеджерами (для большей независимости от типа ЭВМ, выполняющих функции менеджеров, желательно минимизировать число различных видов обмена между ЭВМ-координаторами и ЭВМ-менеджерами; необходимо учитывать также, что на различных предприятиях используется разная вычислительная техника, на которой решаются задачи оперативного и календарного планирования, а также другие задачи управления производством; сохранение этой техники, а главное, созданного за долгие годы программного обеспечения чрезвычайно важно; практика показывает, что мощным инструментальным средством, достаточным для организации взаимодействия между ЭВМ-менеджерами и координаторами, является удаленный файловый доступ).
Перечисленные задачи определяют набор инструментальных средств, требуемых для поддержки разработки системы управления ГАП, состоящий из операционной системы реального времени, необходимой для последовательно-параллельного управления контроллерами, языка и исполнительной системы для программирования информационных связей между координаторами [4], а также системы отладки взаимосвязанных программ, выполняющихся на одной или нескольких ЭВМ-координаторах. Механизмы удаленного файлового доступа уже подробно рассматривались в литературе (см., например, публикацию [5]), поэтому в статье эти механизмы не затрагиваются.
Операционная система ЭВМ-координатора. Обычно операционные системы не относят к числу инструментальных средств. В универсальных ЭВМ операционные системы создают вычислительную среду, в которой выполняются прикладные программы. Однако 戸
случае ЭВМ-координаторов создание постоянной вычислительной среды, по-видимому, нецелесообразно, поскольку для этих ЭВМ трудно выделить сколько-нибудь постоянный набор действий, эффективно используемый в широком классе приложений. Включение в операционную систему избыточных возможностей завышает требования к техническим характерзктикам ЭВМ-коордлнаторов. В то л<е время желательно применять в качестве координаторов микро- ЭВМ с небольшим объемом памяти: в этом случае можно включать в состав системы управления столько ЭВМ, сколько требует функциональная схема системы управления ГАП, не ограничивая их число из экономических соображений.
Применяемая обычно генерация отдельных версий операционной системы при большом числе координаторов требует значительного времени. Кроме того, наличие многих версий операционной системы затрудняет работу программистов.
Значительно более предпочтительно, чтобы подходящая конфигурация операционной системы синтезировалась автоматически на основе анализа потребностей программ, назначаемых к исполнению на некоторую ЭВМ-координатор. Автоматическая генерация операционной системы требует наличия в составе инструментальных средств набора операционных механизмов, из которых, как из конструктора, собирается операционная система для конкретной ЭВМ. Рассмотрим основные из предложенных механизмов.
Основу операционной системы составляет диспетчер процессов. Любая процедура пользователя может быть объявлена процессом, который диспетчер будет рассматривать как самостоятельную единицу исполнения. Все процессы должны быть объявлены статически, до начала исполнения каких-либо процедур» Для каждого процесса диспетчер формирует блок управления, в котором сохраняются данные, необходимые для запуска процесса и его работы. Одна и та же процедура может принадлежать двум и более процессам (в этом случае для каждого процесса формируется свой блок управления).
Процессам присваиваются приоритеты. В зависимости от количества разных приоритетов в состав операционной системы включается одна или несколько очередей, к каждой из которых прикрепляются процессы соответствующего приоритета. В моменты диспетчеризации вначале анализируется очередь наиболее высокого приоритета. И только если в этой очереди отсутствуют готовые к исполнению процессы, начинается анализ очередей более низкого приоритета. Очередность перехода в активное состояние двух процессов одина^ нового приоритета определяется моментами постановки их в очередь.
Если каким-нибудь процессам требуется для их работы знание абсолютного или относительного времени, то в состав операционной системы включается диспетчер времени, у которого имеется собственная очередь. Процесс может установить себя в очередь к этому диспетчеру. Для процесса, поставившего себя в очередь к диспетчеру времени, до истечения заказанного интервала времени будет закрыта возможность получить в свое распоряжение процессор.
Моментом, в который начнется диспетчеризация, управляют процессы, а не операционная система. Возможность управления началом диспетчеризации имеет ряд достоинств:
во-первых, исключается необходимость в дополнительных средствах синхронизации, так как любой процессорный интервал легко сделать неделимым;
во-вторых, уменьшаются накладные расходы на работу операционной системы, вследствие того что диспетчеризация без переключения процессов из состояния готовности в активное состояние может быть практически исключена.
Любой процесс может быть задействован в роли драйвера внешнего устройства. Процесс, являющийся драйвером, может затребовать генерацию дополнительной очереди, которая будет включена в состав операционной системы. В очереди, приданной драйверу, будут накапливаться заявки на обслуживание соответствующим внешним устройством.
Множество состояний процессов ограничено тремя элементами. Процесс может быть:
ждущим (если он задержан до наступления некоторого события);
готовым (если все события, ожидаемые процессом, уже свершились);
активным (если он получает в свое распоряжение процессор).
В свою очередь, событие может быть ожидаемым и свершившимся. Операционная система устанавливает взаимно однозначное соответствие между состоянием события и состоянием вычислительной среды операционной системы. Формируются специальные индикаторы, отображающие состояние среды в состояние события.
Имеется еще ряд вспомогательных компонентов операционной системы (оверлей, обработчик прерываний, инициатор, пересылающий содержимое постоянного запоминающего устройства, и др.), сконструированных традиционным образом.
Язык для организации информационных связей между координаторами. При создании языка преследовались следующие цели [4, 61:
обеспечить легкое описание (а при необходимости и изменение описания) информационных связей между координаторами;
сделать описание минимально зависимым от структурной схемы вычислительного комплекса и выполняемых координаторами функций;
обеспечить средствами языка и исполнительной системы синхронизацию при передаче данных.
Язык включает три основных понятия: порт, связь между портами и исключительная ситуация.
Порт — это структура данных и программа, управляющая заполнением и освобождением порта, а также отвечающая за взаимодействие с операционной системой.
С помощью языка порты взаимооднозначно связываются с процессами, а тем самым и с ЭВМ, на которые процессы назначены для
выполнения. Процессы не имеют других способов взаимодействовать друг с другом, кроме как пересылая сообщения через выделенные им порты. Связь через порты реализуется как для процессов на одном координаторе, так и на разных координаторах.
В языке имеются операторы, описывающие связи портов. Метод описания связей между портами продемонстрируем на следующем примере:
СВЯЗАТЬ Pl, Т1 => Р2. Т2, РЗ. ТЗ, (1) где Р1—РЗ — имена портов, а Т1—ТЗ — имена ЭВМ-координаторов, в которых эти порты размещены.
Допускается задание одновременных связей одного порта с несколькими другими, как в выражении (1), а также альтернативных связей. Одновременные связи определяют широковещательную передачу сообщений, а альтернативные — предусматривают возможность передачи информации в резервный порт при отказе ЭВМ, где размещалась основная копия порта.
Описание любого порта имеет несколько параметров, предназначенных для настройки его управляющей программы. Среди них отметим: размер порта, глубину буферизации, направленность (различаются порты, которые координатор может читать или заполнять), тип порта. По типу порты делятся на пять групп: синхронные пассивные и активные, асинхронные активные и пассивные, порты с внешним управлением.
Связь может устанавливаться только между активными и пассивными портами или портами с внешним управлением. Активный порт может инициировать передачу или чтение данных, а пассивный лишен такой возможности. Синхронный порт может задерживать операцию обмена с другим портом, в то время как асинхронный передает информацию независимо от того, занят или свободен взаимодействующий с ним порт. Порт с внешним управлением становится активным не после операции чтения или записи в него, а по специальной команде, которая может поступить, например, от операторов «исключительная ситуация». Такие операторы позволяют установить соответствие между ошибками, возможными при передаче данных, и процедурами их обработки.
В результате появляется возможность эффективно реагироват， на такие ошибочные ситуации, как превышение допустимого времени ожидания данных, их искажение и др.
Управляющие программы портов после трансляции исходной программы оформляются в виде процессов, что позволяет включать эти программы в число других программ координатора для формирования версии операционной системы и получения законченного программного обеспечения конкретной ЭВМ-координатора.
Система отладки программ координаторов распределенного вычислительного комплекса• Эта система должна предоставлять программисту возможность вести отладку на трех уровнях: отдельные последовательные процессы, взаимодействие процессов, межмашинные взаимодействия.
Отладка последовательных процессов может осуществляться тра диционными средствами, зависящими или независящими от языка программирования. Сложнее обстоит дело с отладкой взаимодействия процессов. ■
В каждый момент времени каждому процессу соответствует неко торое состояние. Это означает, что совокупность процессов может быть описана множеством пар процесс— со стояние (размерность множества равна количеству процессов в системе). Расширением множества состояний можно максимально конкретизировать описание хода взаимодействия процессов в распределенной системе.
Будем считать пару процесс——состояние (р—s) существующей, если процесс р имеет состояние s. Отсюда легко получаются понятия: «появление пары процесс——состояние», «отсутствие пары», «история пары процесс—состояние».
Введем понятие «индикатор отладки». Индикатор есть логическая величина, ассоциированная с парой процесс—состояние. Значение true индикатор отладки имеет, если существует пара процесс——состояние, ассоциированная с ним. Событие отладки есть функция индикаторов отладки, сконструированная по правилам, вводимым в каждом конкретном случае. Система отладки должна отслеживать значение индикаторов и проверять, какие события получили значение true. При наступлении заказанного программистом события отладки исполняется то отладочное действие, которое установлено для данного события. Простейшими из отладочных действий являются прерывание работы и выход в диалог с программистом, ведущим сеанс отладки.
Имеется возможность проводить условную трассировку событий отладки. Типы условий трассировки не фиксируются. В каждом конкретном случае программист может описать специфичные условия, которые, как и события отладки, конструируются из элементарных условий.
При отладке межмашинных взаимодействий процессов возникает одна специфичная проблема. Если использовать традиционные средства, программисту время от времени придется пересаживаться с пульта одной ЭВМ за пульт другой. Чтобы избежать этого, применяются средства, позволяющие работать с программой с единого пульта. В составе распределенного комплекса выделяется специальная «отладочная» ЭВМ, управляющая вычислительным процессом во всех взаимодействующих машинах. В каждой ЭВМ, имеющей отлаживаемые программы, размещается небольшая часть распределенного отладчика, отображающая состояние вычислительного процесса в состояние индикаторов отладки. Изменения в их состоянии передаются «отладочной» ЭВМ. При наступлении события начинают действовать специальные процедуры, которые могут привести к временному прекращению вычислительного процесса только в той ЭВМ, где наступило ожидаемое событие, или в произвольной группе связанных ЭВМ.
Система стимулирует определенную этапность при отладке программ ——от отдельной процедуры к взаимодействию программ на 222
одной или нескольких ЭВМ. Имеются специальные средства для итерационной работы, когда возможны возвраты на ранее пройденные этапы без перезагрузки программ в «отладочную» и «отлаживаемые» ЭВМ. Система включает ряд специфичных для распределенных вычислительных систем средств, позволяющих автоматизировать выявление тупиков и протокольных сбоев.
ЛИТЕРАТУРА
Распределенный вычислительный комплекс для управления технологиче' скими процессами (структура и программное обеспечение)/А. И. Казьмин * А. А. Менн, М. В. Дудкин, Н. В. Золотарев, Б. Д. Мандель, В. Н. Попо- литов, В, Г. Сперанский, А, В, Шерстюк, В, В. Шаталов: Препр. М.: Ин-т пробл. управления, 1984. 47 с.
Kramer /., Magee J., Sloman M., Lister A. CONIC: an integrated approach to distributed computer control systems.— IEEE Proc., 1983, p. 1 — 10.
May D. OCCAM.— Singplan Notes, 1983, vol. 18, N 4, p. 69—79.
Kazmin A. I., Menn A. A. Program adjustment techniques for distributed computer complexes: Prepr. 9th World Congr. Intern. Fed. Automat. Contr., Budapest (Hungary), 1984. Budapest: 1FAC. 1984, vol. 2, p. 149—153.
Introduction to DECNET (AA-1055A-TK). Mainard (Mass.): DEC, 1981. 79 p.
Менн А. А., Лакштас А. А. Технология подготовки программ для распределенных вычислительных сетей.— В кн.: Междунар, науч.-техн. конф. «Программное обеспечение ЭВМ», Калинин, 1984: Тез. докл. Секция 3. Калинин: НПО «Центрпрограммсистем», 1984, с. 87—89.
УДК 519.682
,ЯЗЫК
ДЛЯ РЕАЛИЗАЦИИ АЛГОРИТМОВ УПРАВЛЕНИЯ В РОБОТОТЕХНИКЕ
И. Е. Богомолов, Ю. М. Лазутин, В. С. Ярошевский
Основной областью применения ориентированного на структурное программирование языка высокого уровня МЭЛ является создание математического обеспечения задач робототехники и связанных с ними задач системного программирования, решаемых на мини- и микро-ЭВМ.
Язык создавался для разработки программ для двухбайтных ЭВМ. На уровень языка вынесены практически все операции, которые выполняют мини- и микромашиныт применяемые в управляющих системах роботов. Для достижения максимальной эффективности некоторые части программ могут быть написаны на языке Ассемблера.
Разработка программного обеспечения робототехнического комплекса, как и всякого реализуемого на ЭВМ крупного проекта, начинается с решения проблем: какие программные средства, какой язык программирования использовать для формирования алгоритмов управления. Выбор должен осуществляться с учетом требований и
особенностей проблемной области (робототехники). Желательно, чтобы язык был мощным, но не перегруженным редко используемыми конструкциями.
Алгоритмы управления робототехническими системами являются, по-видимому, одними из самых вариативных вследствие огромного количества разных типов систем управления, конструкций роботов, их сенсорных систем и используемого технологического оборудования. Это предъявляет повышенные требования к языку программирования. Основные из них можно сформулировать следующим образом:
ориентация на структурное программирование (программы должны быть понятны не только их разработчику);
мобильность, переносимость программ не только на разные версии операционной системы, но и на другие типы ЭВМ;
открытость языка (возможность его дальнейшего развития для создания специализированных языков робототехники: языка программирования сборки, сварки и т. д.);
широкий спектр логических операций;
мощный набор управляющих операторов (операторов передачи управления);
наличие средств организации структур данных;
возможность разделения генерируемого кода на изменяемую и неизменяемую части для последующего размещения управляющих программ роботов в постоянной памяти (ППЗУ/ПЗУ);
модульное программирование и жесткий контроль за числом и типом параметров;
допустимость вставок на языке Ассемблера в любом месте программы.
В языке МЭЛ в той или иной степени реализованы перечисленные требования. Он развивался на основе ФОРТРАНа. С точки зрения авторов язык ФОРТРАН обладает рядом недостатков, в частности: на каждой строке размещается только один оператор и недопустим комментарий (программа «разбухает» и теряется ее обозримость);
отсутствуют операторы структурного программирования (появляется множество лишних меток и сильно усложняется чтение программы);
нет доступа к внешним устройствам с языкового уровня (необходимы лишние подпрограммы и функции, написанные на языке Ассемблера).
Эти недостатки были учтены при разработке языка МЭЛ.
На первом этапе создания транслятора считалось, что развивать сложные типы и структуры данных нет необходимости и можно ограничиться только словньш типом (для мини-ЭВМ — два байта), которого достаточно для реализации простых программных комплексов. В первой версии языка существовало три типа программных модулей: головная программа (PR), подпрограмма (SR), функция (FN). Каждый объект языка имел свой оператор-описатель. Указывались все объекты, используемые в программе, в том числе и формальные параметры (как на ФОРТРАНе параметры-массивы). Имелся опера-
тор условного ветвлений С альтернативами. Из операторов цикла был реализован только RP. Допускались не все операции из современного набора. Кроме того, для упрощения транслятора (он в то время был написан на ФОРТРАНе) в арифметических выражениях отсутствовали приоритеты операций, значение выражения вычислялось слева направо. Для лаконичности программирования обозначения всех операторов языка сделаны двухбуквенными.
Опыт эксплуатацйи показал, что такой язык достаточно слаб и не защищает от ошибок пользователя. Несмотря на структурную конструкцию оператора передачи управления, программа содержала много меток. Вследствие этого получили развитие конструкции условной передачи управления и цикла. Добавились операторы: альтернативы (AF и CF) в конструкцию условного ветвления IF; заголовка цикла (RW и RU); альтернативных условий (АР, SP, ХР, СР) в цикле. Появилась возможность ввести условие в операторе закрытия цикла ЕР. Введение указанных операторов сильно структурировало программы и позволило практически полностью отказаться от использования меток. В то же время стала сказываться диспропорция развития языка: чрезмерное увеличение объема операторов-описателей DC по сравнению с исполнительной частью программ; слабое развитие арифметических выражений.
Для уменьшения объема операторов DC были введены модули (Ml) и ED), с помощью которых пользователь управляет областью действия описателей. Одновременно снизилась нагрузка на программу «Редактор внешних связей», так как многие идентификаторы из внешних по отношению к подпрограммам и функциям превратились во внутренние для объемлющего модуля. Благодаря этому уменьшился объем программ, улучшилась их обозримость. Программы, работающие с одним и тем же набором данных, сгруппировались.
В результате существенно улучшилась структура программных комплексов. Введение приоритетов в вычисления арифметических выражений и включение в язык операций, характерных для современных мини- и микро-ЭВМ, увеличило наглядность арифметических выражений и уменьшило число описок и ошибок в программах.
Опытная эксплуатация в течении года этой версии языка МЭЛ выявила следующее:
описание формальных параметров одновременно в операторах SR/FN и в DC излишне и приводит к ошибкам;
одного словного типа данных недостаточно; желательно введение в язык структур данных.
Фактически опытная эксплуатация показала, что исполнительные (управляющие) операторы хорошо проработаны и удовлетворительны по мощности, а средства представления структур и типов данных развиты слабо. Двойное описание формальных параметров было легко исключено. Введение же различных типов данных потребовало тщательного рассмотрения проблем их задания и преобразования. Определившись со способом описания (указывается в квадратных скобках [ ... ]), разработчики решили запретить подразумеваемое преобразование типов данных. Были введены следующие четыре
типа: БАЙТ, СЛОВО, ДВОЙНОЕ СЛОВО С ФИКСИРОВАННОЙ ТОЧКОЙ, ПЛАВАЮЩАЯ ТОЧКА. Одновременно определили ба- зированный способ доступа, что позволило организовывать сложные структуры данных. В языке МЭЛ считается, что все структуры статические. Формирование динамического изменения структур в настоящее время возложено на пользователя — эта возможность нс запрещена.
Дальнейшая эксплуатация языка привела к появлению типа данных АДРЕС [D] (порядковые числа), так как проверка условий для адресного типа выполняется на ЭВМ с системой команд семейства «Электроника-60» иначе, чем для словного типа. Кроме того, были введены операции логического сдвига через С-разряд.
Мы не касались описания реализации оператора безусловного перехода GO. Структуризация конструкций управления последовательностью действий позволила, как отмечалось, писать программы практически без меток. Поэтому на определенном этапе разработчики хотели вообще убрать из языка метки и оператор GO. Однако с расширением типов и классов формальных параметров появилась возможность передавать адреса меток в качестве параметров. Благодаря этому оператор GO стал использоваться как удобное средство обработки аварийных ситуаций: при обнаружении ошибки во вложенной подпрограмме/функции управление единообразно передается на соответствующий модуль, что повышает надежность, наглядность программы, способствует структуризации всего комплекса.
Последней появившейся в МЭЛ конструкцией являются операторы распараллеливания процессов: ВТ, СТ, ЕТ. Они являются специфичными для робототехнических систем и подразумевают разработку операционной системы непосредственно пользователем (либо связь с операционной системой реального времени, стандартно установленную на данной ЭВМ).
В системе программирования, поддерживающей язык МЭЛ, есть возможность разделения программ на постоянную (ПЗУ) и переменную (ОЗУ) части. Она задается командой управления работой транслятора и к языку непосредственного отношения не имеет. Следует отметить, однако, что эта возможность позволила освободить пользователя от большого объема работ по разнесению рабочих переменных и обрабатывающих их программ в разные части адресного пространства.
Параллельно с развитием языковых средств велась работа по созданию системы программирования, обеспечивающей максимальный контроль за соответствием фактических и формальных параметров-
Приводимое описание МЭЛ предназначено для программистов, знакомых с одним из языков высокого уровня мини- или микро-ЭВМ (например, PLM, Си, MODULA), и не содержит ограничений на конструкции и объекты языка, связанные с особенностями реализации транслятора для конкретной ЭВМ.
ЭЛЕМЕНТЫ ЯЗЫКА
Константы в языке МЭЛ могут быть следующих типов:
целые числа (последовательность десятичных цифр, перед которой может быть знак «+» или «—»);
восьмеричные числа без знака (отличаются буквой «В», записываемой после константы);
вещественные числа (обязательна точка, разделяющая целую и дробную части; возможен показатель степени после буквы《Е»; при использовании десятичных констант по модулю, меньших единицы, перед точкой обязательно ставится 0)；
одиночные символы имеют вид 1S$ (где $ означает любой задаваемый символ)；
текстовые константы записываются либо в виде 2Н $$ (где $$ — задаваемая пара любых символов), либо как цепочка символов в одинарных кавычках —，緜
адресные константы (значение, получаемое применением к переменной операции определения адреса).
Идентификатор — последовательность букв и цифр, начинающаяся с буквы, служащая для именования объектов программы. Некоторые двухбуквенные сочетания являются зарезервированными именами. Они обозначают операторы языка: AF, АР, ВТ, CF, СР, CS, СТ, DC, ED, EF, EN, EP, ES, ET, FN, GO, IF, LS, MD, RP, RD, PR, RT, RU, RW, SK, SR, SP, TR, WR, XP.
Для совместимости с ранними версиями языка запрещено использование всех идентификаторов, начинающихся с букв DC.
Область действия идентификатора (т. е. область, в которой он определен и его использование не вызывает диагностики об ошибке)— модуль. Модули могут быть вложенными. Область действия идентификатора, определенного в объемлющем модуле, распространяется на все вложенные модули.
Класс и способ доступа объектов, используемых в языке МЭЛ, сведены в табл. 1, где приняты следующие обозначения способов доступа:
Таблица 1
Класс
Символ оператора описателя
Разрешенные способы доступа
G
С
М
R
S
%
*
Переменная
по умолчанию
+
+ V
+ V
+
十
Программа (головная)
А
—
+
—
—
—
—
Подпрограмма
Е
—
十
+
—
—
+
Функция
N
—
+
+
—
—
十
Метка
L
一
—
十
—
一
+
Модуль
не описывается
—
—
—
G — внешний (указание транслятору оформить обращение к идентификатору как к внешнему, т. е. такому, память под который зарезервирована вне данного модуля);
С ——COMMON (идентификатор располагается в блоке общей памяти);
М — входной (указание транслятору зарезервировать требуемый объем памяти);
R ——внутренний (идентификатор видим (доступен) только в текущем модуле);
S ——стековый (место в ОЗУ не резервируется, во время выполнения модуля используется пространство стека);
% — регистровый (идентификатор именует физический регистр ЭВМ);
* — базированный (явное управление размещением идентификатора в памяти).
Символом V отмечены класс идентификаторов и способы доступа, для которых разрешено задание начального значения.
Тип идентификатора допустим для двух классов — переменные и функции. Предопределенные типы указаны в табл. 2.
Таблица 2
Тип идентификатора
Символ
Количество байт
Диапазон значений
Байтовый
В
1
от —128 до 127
Словный
W
2
от -32768 до 32767
С фиксированной точкой
I
4
зависит от ЭВМ
С плавающей точкой
F
4
»»»
Адресный
D
2
от 0 до 65535
Предусмотрено введение пользователем специализированных типов идентификаторов.
Переменные бывают простыми и массивами. Массив — последовательность простых переменных, характеризующихся номером начала и количеством элементов. Формат доступа к элементу массива — идентификатор, за которым в круглых скобках указывается номер элемента — арифметическое выражение.
Арифметическое выражение — последовательность операндов, соединенных знаками операций. Порядок вычислений определяется приоритетами операций и расстановкой скобок. Операнд ——константа, переменная, элемент массива, функция с фактическими параметрами, арифметическое выражение, арифметическое выражение в скобках.
Константное выражение — арифметическое выра/кение, все операнды которого константы.
Операции, реализованные в языке МЭЛ, сведены в табл. 3. В таблице приняты следующие обозначения: 1 — символ операции; 2 —— пример ее использования; 3 — приоритет операции (большему 228
Таблица 3
Содержание операции
1
2
3
4
5
6
Присвоение левому операнду значения
L = R
0
правого
Сложение по модулю 2
#
L#R
1
в
Логические операции
2
D
'ИЛИ'
V
LVR
w
л
L/\R
3
D
D
D
Сдвиг
ар ифметический
4
вправо
=>
L = > R
〉=
влево
< =
L < = H
4
I
w
I
=<
w
w
W
логический
В
в
В
вправо
>
L>R
4
w
в
w
влево
L<R
4
I
в
I
циклический
4
в
w
в
вправо
>
L> R
влево
<
L<R
4
Инверсия
—■
—R
5
нет
в
w
I
F
Сложение
+
L + R
5
R
В
Вычитание
L - R
5
w
I
F
1 1
D
D
D
D
W
Умножение
*
L*R
6
]в
Деление
/
L/R
6
W
Остаток от деления
L\R
6
Косвенная адресация
@
@R
7
нет
w w
Определение адреса
#R
8
нет
D D
D
D
D
значению числа соответствует больший приоритет); 4, 5 — тип ле- вого и правого операнда соответственно; 6 — тип результата.
Для операции присвоения левый операнд может быть переменной илу произвольным арифметическим выражением, в котором послед- не立 выполняемой операцией является косвенная адресация.
ОФОРМЛЕНИЕ ПРОГРАММЫ
Алгоритм на языке МЭЛ записывается как последовательность моду- лей, которые бывают описательными и исполняемыми.
Описательный модуль начинается оператором MD, заканчивается оператором ED и служит для ограничения области действия идентификаторов. Внутри описательного модуля можно поместить один или несколько любых других модулей.
Исполняемый модуль начинается одним из следующих операто- ров: PR (головная программа), SR (подпрограмма), FN (функция), а заканчивается оператором EN. Кроме ограничения области дей- ствня определенных в нем идентификаторов, исполняемый модуль описывает преобразование (обработку) данных, т. е. содержит испол- няемые операторы.
За оператором начала всякого модуля следует оператор DC, описывающий используемые идентификаторы.
исполняемыйисполняемыйPR, SR, FNDC X,…ИСПОЛНЯЕМЫЕENPR, SR, FNDC X,…ИСПОЛНЯЕМЫЕENВ общем виде структура модулей языка МЭЛ следующая:
исполняемый
исполняемый
PR, SR, FN
DC X,…
ИСПОЛНЯЕМЫЕ
EN
PR, SR, FN
DC X,…
ИСПОЛНЯЕМЫЕ
EN
ОПЕРАТОРЫ ОБЛАСТЬ ДЕЙСТВИЯ
.ИДЕНТИФИКАТОРОВ X,...
MDDC X,ВЛОЖЕННЫЙ модульDC Y,… ВЛОЖЕННЫЙ модульEDMDDC X,ВЛОЖЕННЫЙ модульDC Y,… ВЛОЖЕННЫЙ модульEDописательный
MD
DC X,
ВЛОЖЕННЫЙ модуль
DC Y,… ВЛОЖЕННЫЙ модуль
ED
MD
DC X,
ВЛОЖЕННЫЙ модуль
DC Y,… ВЛОЖЕННЫЙ модуль
ED
ОБЛАСТИ ДЕЙСТВИЯ
ИДЕНТИФИКАТОРОВ ИДЕНТИФИКАТОРОВ
Операторы программы записываются построчно с произвольным размещением. Никаких дополнительных символов для продолжения оператора на следующей строке не требуется. Разделителем являет- Ся 喟°6ел или группа пробелов. Комментарий начинается символом «;». Признаком окончания комментария является либо тот же символ либо конец строки. ” '
Пробелы не допустимы внутри констант (за исключепием тексто- вых, в которых пробелы несут смысловую нагрузку), идентификато- ров，многосимвольных операций, между идентификатором массива и открывающей скобкой указателя номера элемента, между идентификатором подпрограммы или функции и скобкой, открывающей спи- СОк параметров, между меткой и двоеточием, определяющим ее.
ОПЕРАТОРЫ ЯЗЫКА МЭЛ
Оператор-описатель DC имеет формат:
ПС[<КЛАСС><ТИП> (СПОСОБ ДОСТУПА>] (СПИСОК ЭЛЕМЕНТОЙ>
формат элементов списка:
ИДЕНТИФИКАТОР (<РАЗМЕРПОСТЬ>)/<ПАЧЛЛЬНЫЕ ЗНАЧЕНИЯ> /
Каждый идентифцк а тор из списка занимает участок памяти в соответствии с заданным классом, типом, размерностью и располагается в памяти последовательно за предыдущим идеи тифи к а то р ом. Начальный адрес списка определяется способом доступа.
В списке идентификаторов могут быть заданы, кроме текстового имени идентификатора, его размерность (для классов «переменные», «подпрограммы», «функции») и начальное значение (для класса «переменные»).
Размерность переменной означает, что описывается массив с указанным числом элементов. Если необходимо определить начальный элемент, отличный от единицы, то задается пара ——начальный и конечный элементы, разделенные двоеточием. Допустимы отрицательные номера элементов.
Размерность подпрограммы/функции — это число параметров при обращении к ней. В случае переменного числа параметров ставится символ $・
Начальное значение — последовательность константных выраже* ний (по количеству не превосходящая число простых переменных, зарезервированное описываемым идентификатором). Для повторяющихся значений допустима конструкция
N * <ЗНАЧЕНИЕ>
Здесь N — число повторений.
Для идентификаторов с базированным способом доступа после символа * требуется задание адреса. Возможны следующие способы его задания:
« ИДЕНТИФИКАТОР# ИДЕНТИФИКАТОРПЕРЕМЕННАЯ (КОНСТАНТНОЕ ВЫРАЖЕНИЕ)# ПЕРЕМЕННАЯ (КОНСТАНТНОЕ ВЫРАЖЕНИЕ)КОНСТАНТНОЕ ВЫРАЖЕНИЕ# КОНСТАНТНОЕ ВЫРАЖЕНИЕ« ИДЕНТИФИКАТОР# ИДЕНТИФИКАТОРПЕРЕМЕННАЯ (КОНСТАНТНОЕ ВЫРАЖЕНИЕ)# ПЕРЕМЕННАЯ (КОНСТАНТНОЕ ВЫРАЖЕНИЕ)КОНСТАНТНОЕ ВЫРАЖЕНИЕ# КОНСТАНТНОЕ ВЫРАЖЕНИЕАдрес описываемого идентификатора содержится ло адресу указан ого и ен тификатора совпадает с адресом указанного идентификатора содержится по адресу указанного элемента массива совладает с адресом указанного элемента массива совпадает с указанной константой содержится по указанному адресу
« ИДЕНТИФИКАТОР
# ИДЕНТИФИКАТОР
ПЕРЕМЕННАЯ (КОНСТАНТНОЕ ВЫРАЖЕНИЕ)
# ПЕРЕМЕННАЯ (КОНСТАНТ
НОЕ ВЫРАЖЕНИЕ)
КОНСТАНТНОЕ ВЫРАЖЕНИЕ
# КОНСТАНТНОЕ ВЫРАЖЕНИЕ
« ИДЕНТИФИКАТОР
# ИДЕНТИФИКАТОР
ПЕРЕМЕННАЯ (КОНСТАНТНОЕ ВЫРАЖЕНИЕ)
# ПЕРЕМЕННАЯ (КОНСТАНТ
НОЕ ВЫРАЖЕНИЕ)
КОНСТАНТНОЕ ВЫРАЖЕНИЕ
# КОНСТАНТНОЕ ВЫРАЖЕНИЕ
По умолчанию: если опущен символ типа, то он считается слов- ньш (W): если опущен символ класса идентификатор а, то идентификатор считается переменной; если опущен способ доступа, то он считается внутренним (R).
Заголовок описательного модуля следующий:
MD ИДЕНТИФИКАТОР
Заголовком исполнительного модуля может быть один из операторов:
PR ИДЕНТИФИКАТОР
SR ИДЕНТИФИКАТОР
FN[<TPin>] ИДЕНТИФИКАТОР
SR ИДЕНТИФИКАТОР (PAR1? PAR N)
FN[<THn>] ИДЕНТИФИКАТОР (PARI,…，PAR N)
Параметр PAR имеет формат:
[<КЛАСС><ТИП>] ИДЕНТИФИКАТОР (〈РАЗМЕРНОСТЬ〉)
Идентификаторы, перечисленные в списке формальных параметров исполнительного модуля, считаются описанными в данном модуле и не требуют дополнительного упоминания в операторе DC.
ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
Оператор присваивания имеет формат:
ПЕРЕМЕННАЯ = АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ или
ПЕРЕМЕННАЯ (АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ) = АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ
или
@ (АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ) -= АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ
По адресу, определенному в левойчасти равенства, заносится значение выражения, полученное в правой части равенства.
Операторы безусловного перехода бывают двух видов.
Оператор безусловного перехода на метку имеет формат:
GO ИДЕНТИФИКАТОР'
Метка-идентификатор должна быть либо описана в операторе DC и задана в программе среди исполнительных операторов следующим образом:
ИДЕНТИФИКАТОР:...
либо присутствовать среди формальных параметров подпрограммы функции.
Операторы пропуска образуют конструкцию, которая начинается с заголовка SK, может содержать одно или несколько продолжений CS и заканчивается оператором ES. Выполняемые передачи функционально могут быть описаны операторами:
SKGO LABEL
CSGO LABEL
ES LABEL: ...
Оператор условного перехода может быть записан в виде простого оператора IF, который имеет формат:
IF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ EF
Если условие истинно, то выполняются все исполняемые операто^ ры до оператора EF, иначе управление передается на первый исполняемый оператор, следующий за EF.
Условие — логическое выражение. Различают следующие условия:
простое — выражение вида
(АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ & АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ)
Здесь & — любая из операций отношения:《＜» (меньше),《〉》 (больше), «^» (равно),《#» (не равно),《V = » или « —＜；» (не больше), 《=〉》или «〉=» (не меньше);
пустое — пара из открывающей и закрывающей круглых скобок —— считается всегда истинным;
составное — дизъюнктивная нормальная форма простых условий. Составное условие вычисляется слева направо в соответствии с правилами алгебры логики. Условие истинно, если истинна последняя просмотренная конъюнктивная группа простых условий. В этом случае проверка истинности остальных условий, а значит и вычисления входящих в них выражений, не осуществляется.
Если операнд условия повторяется на том же месте в последующем простом условии, то можно использовать символ вместо повторения операнда.“
Конструкция составного IF служит для организации ветвлений по ряду условий и включает четыре оператора следующего формата:
IF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
AF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
CF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
EF
Количество и порядок операторов AF и CF произвольны. Составной IF можно описать с помощью уже введенных конструкций языка МЭЛ:
IF
УСЛОВИЕ
ИСПОЛНЯЕМЫЕ
ОПЕРАТОРЫ
IF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ GO END EF
AF
УСЛОВИЕ
ИСПОЛНЯЕМЫЕ
ОПЕРАТОРЫ
IF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ GO END EF
CF
EF
УСЛОВИЕ
ИСПОЛНЯЕМЫЕ
ОПЕРАТОРЫ
IF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ EF
END:
Условия операторов составного IF просматриваются последовательно. В случае истинности текущего условия (при IF, AF или CF) выполняются идущие следом операторы до очередного AF, CF или EF. Иначе проверка условий продолжается. После исполняемых операторов при IF, AF управление передается в конец конструкции на
оператор, следующий за EF. В случае CF — после исполняемых операторов продолжаются проверки условий составного IF,
Оператор цикла может начинаться тремя различными способами:
RU ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
RW УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
RP АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
Оператор RU ставит служебную метку, которая указывает начало цикла, после чего выполняется тело цикла.
Оператор RW ставит служебную метку начала цикла и проверяет условие. Если оно истинно, то выполняется тело цикла.
Оператор RP перед первым проходом тела цикла пересылает зна~ чение арифметического выражения в рабочую ячейку, являющуюся счетчиком цикла. Следует подчеркнуть, что програмлшсту этот счетчик цикла недоступен.
Тело цикла может разбиваться операторами АР, SP, СР, ХР. Их порядок и количество произвольны. Формат условий и порядок их проверки те же, что и в конструкции составного IF.
Функционально операторы цикла эквивалентны последователь^ ностям действий:
RU ОПЕРАТОРЫ
RP АРИФМЕТИЧЕСКОЕ ВЫ-
BEGIN: ОПЕРАТОРЫ
X = АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ
РАЖГ^НИЕ
RU
RW УСЛОВИЕ ОПЕРАТОРЫ
BEGIN: IF УСЛОВИЕ ОПЕРАТОРЫ GO END AF ( ) GO ALT1 EF
АР УСЛОВИЕ ОПЕРАТОРЫ
ALT/: IF УСЛОВИЕ ОПЕРАТОРЫ GO END
AF ( ) GO ALT/+ 1 EF
SP УСЛОВИЕ ОПЕРАТОРЫ
ALT/： IF УСЛОВИЕ
ОПЕРАТОРЫ GO BEGIN
AF( ) GO ALT/+1
EF
СР УСЛОВИЕ ОПЕРАТОРЫ
ALT/: IF УСЛОВИЕ ОПЕРАТОРЫ
AF( ) GO ALT/ + 1
EF
ХР УСЛОВИЕ ОПЕРАТОРЫ
ЕР
ALT/： IF УСЛОВИЕ
ОПЕРАТОРЫ GO EXIT
AF()GOALT/+1
EF
END:
ПРОВЕРКА РАБОЧЕЙ
ЯЧЕЙКИ X
ALT/:
EXIT;
ЕР УСЛОВИЕEND: IF《НЕ» УСЛОВИЕ GO EXIT EF
ПРОВЕРКА РАБОЧЕЙ
ЯЧЕЙКИ X
ALT/:
EXIT:
ПРОВЕРКА РАБОЧЕЙ ЯЧЕЙКИ X:
X = X 1F(X = 0) GO EXIT EF GO BEGIN
Работа с подпрограммами и функциями включает обращения к ним и возврат после их выполнения.
Вызов подпрограмм и функций имеет формат:
ИДЕНТИФИКАТОР (Р1, ..., PN)
Здесь ИДЕНТИФИКАТОР — название подпрограммы или функции; Р1, . . ., PN — список фактических параметров. Параметры могут отсутствовать. Допустимо применение арифметических выражений в качестве фактических параметров. Скобки при имени подпрограммы или функции обязательны даже при отсутствии фактических параметров, в этом случае надо писать
ИДЕНТИФИКАТОР ()
Вызов функции возможен только в арифметическом выражении.
Оператор возврата из подпрограмм и функций записывается в виде
RT— возврат из подпрограмм
RT АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ — возврат из функций
Перед оператором EF в подпрограммах оператор RT необязателен. В качестве значения функции в вызывающую программу передается значение арифметического выражения.
Операторы ввода—вывода ориентированы на работу с терминалом пользователя. Получение твердых копий обеспечивается средствами операционной системы.
Вывод осуществляется с помощью оператора WR, записываемого следующим образом:
WR (Ш U2 ... Uj) (ELI, EL2,…，ELN)
Во вторых скобках стоит список выводимых элементов, для каждого из которых в первых скобках указывается формат вывода U, с помощью которого можно задавать печать соответственно целого числа (I), восьмеричного числа (К), числа в формате с плавающей точкой (F), двух символов, хранящихся в слове (А), одного пробела (X), текста, расположенного между кавычками («. . .»).
Специальными символами указываются: перевод строки (/), включение подавления при выводе всех пробелов, кроме заданных в «. . .» или спецификацией X (——),отмена подавления пробелов (+).
Запятая и пробел игнорируются,
Перед символами I, К, А, X, / может стоять число, означающее коэффициент повторений данной спецификации.
Элементы списка могут иметь следующие форматы:
ИДЕНТИФИКАТОР
—вывод соответствующей переменной или всего массива;
ИДЕНТИФИКАТОР (АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ-1, АРИ①МЕТРИЧЕСКОЕ ВЫРАЖЕНИЕ-2)
——вывод элементов массива от элемента с номером, равным значению выражения-1, до элемента с номером, равным значению выражения-2.
Допустимы также конструкции вида
ИДЕНТИФИКАТОР (:АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ) и
ИДЕНТИФИКАТОР (АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ:)
эквивалентные соответственно конструкциям
ИДЕНТИФИКАТОР (1:АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ) и
ИДЕНТИФИКАТОР (АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ:^)
Здесь 7V ——размерность массива.
Формат вывода зациклен, т. е. если декодирован последний символ формата, а список вывода не исчерпан, то формат опять начинает декодироваться с первого символа.
Ввод осуществляется с помощью оператора RD, читающего информацию по свободному формату. Оператор записывается следующим образом:
RD(EL1, EL2, ..., ELN)
Здесь ELI, . . ., ELN ——список ввода, имеющий такую же форму, как и список вывода в операторе вывода.
Формат ввода определяется по набираемому на клавиатуре значению очередного элемента:
если первый символ «@», то вводится восьмеричное число;
если вводятся только цифры, то они интерпретируются как целое десятичное число;
если первым является символ двойные кавычки, то вводится текстовое значение до «закрывающего» такого же символа;
ввод символа / означает, что последующие символы будут набраны в новой строке.
Ввод каждого элемента списка заканчивается запятой или пробелом. Если введено меньше значений, чем требуется в списке ввода, то оставшиеся элементы не изменяются. Если пользователь наберет на клавиатуре две запятые подряд, то соответствующий элемент списка ввода сохранит свое значение,
ОПЕРАТОРЫ ПРОГРАММИРОВАНИЯ ПАРАЛЛЕЛЬНЫХ ПРОЦЕССОВ
ОПЕРАТОРЫОПЕРАТОРЫОПЕРАТОРЫОПЕРАТОРЫОператоры ВТ, СТ, ЕТ позволяют инициировать параллельное выполнение нескольких частей программы и имеют следующий формат：
ОПЕРАТОРЫ
ОПЕРАТОРЫ
ОПЕРАТОРЫ
ОПЕРАТОРЫ
ВТ ('ИМН ПРОЦЕССА-Г) ИСПОЛНЯЕМЫЕ СТ ('ИМЯ ПРОЦЕССА-%') ИСПОЛНЯЕМЫЕ
ЕТ
Имена процессов могут отсутствовать.Имена процессов могут отсутствовать.,Оператор ВТ отмечает точку ветвления в программе и указывает начало одного из процессов. Операторы СТ (их может быть несколько) разграничивают остальные параллельно исполняемые части программы. Операторы, стоящие за ЕТ, начнут выполняться только после того, как завершатся все инициированные процессы.
Имена процессов могут отсутствовать.
Имена процессов могут отсутствовать.
ДИРЕКТИВЫ УПРАВЛЕНИЯ РАБОТОЙ ТРАНСЛЯТОРА
Директива управления печатью листинга имеет вид:
LS RQ
На месте R может быть поставлено:
N — нет печати текста лсходной программы;
S — есть печать исходной программы;
； А ——печать исходной программы и печать расширений транслируемых j операторов на языке Ассемблера.
На месте Q может быть указано:
N ——нет печати дополнительной информации (дополнительная информация —— это перечень идентификаторов и признаков их использования);
S — печать дополвительной информации без адресов переменных, массивов и меток, без служебных имен, без неиспользуемых COMMON переменных;
С ——печать дополнительной информации без адресов, без служебных имен;
"А ——печать дополнительной информации с адресами (таблица распределения памяти).
Стандартным значением и для R, и для Q является S.
Директивы управления режимом трансляции:
TR, AS — следом за строкой, содержащей этот текст, располагаются предложения языка Ассемблера (автокодная вставка);
TR ML, TR MLG — строки, которыми заканчивается текст на языке Ас- ；семблера, если далее соответственно следует или не следует исполняемый опера- 昼 тор языка МЭЛ;
ТВ SF, TR SM — все подпрограммы, для которых не оговорено специально, транслируются с соглашением о связях соответственно языка ФОРТРАН или 扌 языка, МЭЛ;
TR ВО — произвести разделение программы на изменяемую и неизменяемую части.
РЕАЛИЗАЦИЯ
Транслятор с языка МЭЛ полностью написан на нем же, что облегчает адаптацию к новым ЭВМ. Транслятор функционирует в рамках дисковой операционной системы ЭВМ М-6000 (разработанной в Институте прикладной математики им. М. В. Келдыша АН СССР), или
операционной системы RSX-11/M на СМ-4, или RT-11 — на ЭВМ типа «Электроника-60». Для работы транслятора требуется объем памяти 28К слов.
Транслятор можно считать «полуторапроходным» (для некоторой оптимизации сохраняется очередь последних слов программы). При трансляции возникает проблема ссылок на объекты, адреса которых еще не определены. Генерация таких команд откладывается до конца модуля. К этому моменту все адреса правильно написанной программы уже известны и отложенные команды заносятся в файл объектного типа. В результате получается «рваный» объектный файл, содержащий сначала коды, помещаемые по адресам от 0 до некоторого N (адресация относительно начала модуля), а затем отдельные коды, помещаемые по специально указанным адресам (в пределах от 0 до N). «Редактор связей» ЭВМ М-6000, «Электроника-60», СМ-2 и -4 может обрабатывать файлы такого формата. Кроме того, созданы программы приведения «рваного» файла объектного типа к стандартному последовательному виду.
* * *
Опыт эксплуатации языка МЭЛ на мини- и микро-ЭВМ показал значительное его преимущество (особенно при разработке математического обеспечения задач робототехники и связанных с ними задач системного программирования) над традиционными языками программирования: по выразительным средствам, скорости отладки, эффективности получающихся программ. Очень удобно также использование одного и того же языка на машинах разной архитектуры. В условиях практического отсутствия устройств внешней памяти большого объема с прямым доступом для ЭВМ «Электроника-60» значительный эффект дает использование кросс-транслятора, позволяющего на М-6000, СМ-2, -4 готовить программы для ЭВМ «Элек- троника-60».
УДК 621.865.8-5.001.5
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ СИСТЕМЫ ГРАФИЧЕСКОГО ПРОГРАММИРОВАНИЯ РОБОТОВ АПРОГРАФ
В. 3・ Рахманкулов, С. А. Переелени, Ю. Е. Храмов
Развитие программного обеспечения робототехнических систем в серезне 1980-х годов характеризуется_возрастанием роли интеяа^ также независимого (oii~line) программирования II, 2].
Это обусловлено нео^ЗГодимостью сокращения трудоемкости ввода данных о пространственном положении объектов в программу управления роботов и повышения их точности и эффективности процесса
программирования за счет использования языков высокого уровня, средств моделирования робототехнических комплексов без привлечения реального оборудования, В экспериментальных системах за- дачно-ориентированпого программирования (например, ACRONYM, RAPT, TAf-GEO, PLACE [1,4]) к тому же предпринимаются попытки автоматического построения дишкеиня робота на основе методов искусственного интеллекта.
Независимое программирование роботов с использованием сложных геометрических моделей среды функционирования требует детального описания геометрии сцены с достаточно высокой точностью. Наиболее эффективным средством ввода геометрической информации о сцене является техническое зрение, и перспективные разработки ориентированы на использование технического зрения для построения или уточнения геолгетрической людели. Основная сложность при создании систем независимого программирования состоит в необходимости моделирования разнородных аспектов роботизируемого процесса ——геометрических, кинематических, динамических, сенсорных, координационных (при взаимодействии роботов с другими видами оборудования). В эксплуатируемых на сегодняшний день системах моделирование обеспечивается преимущественно с помощью специализированных модулей, ориентированных на конкретные типы роботов, что ставит пользователя в зависимость от разработчика программного обеспечения. Имеются два способа преодоления этого недостатка:
значительное повышение «интеллектуальности» системы, развитие задачно-ориентированного программирования типа систем SMGR [5], ARPAS, LM-GEO [3], ACRONYM;
предоставление пользователю эффективных средств для самостоятельного описания различных аспектов функционирования роботов на любом уровне детализации.
При современном состоянии методов искусственного интеллекта первое направление имеет главным образом теоретическое значение.
Одной из перспективных концепций второго направления является графическое программирование.
В соответствии с этой концепцией пользователь может выполнять все процедуры, связанные с моделированием среды функционирования робота, составлением и отладкой программы для конкретной технологической задачи, на уровне манипуляций с графическими образами, формируемыми средствами интерактивной машинной графики. Конечной целью является замена традиционных методов программирования роботов интерактивной работой с графическими образами в системе с высоким уровнем сервиса. Известно, что графические образы обрабатываются людьми более эффективно, чем алфавитно-цифровая информация, и в наиболее современных системах средства графического диалога становятся частью среды выполнения программ (система Symphony для ЭВМ IBM-PC, система Lisa) и языков программирования (таких, например, как Smalltalk [6]).
Рассмотрим построенную на основе графического подхода систему автоматизации программирования роботов АПРОГРАФ [7],
Рис. 1. Структура системы АПРОГРАФ
Программирование в этой системе осуществляется в три этапа: формирование графических образов, играющих роль геометрической модели объектов рабочего пространства или выполняющих функцию его разметки;
разработка программ на языке графического программирования, обеспечивающих моделирование функционирования робота при решении им технологической задачи и отображение этого процесса на экране графического дисплея;
синтез исполнительной программы на языке программирования системы управления роботом путем посттрансляции текста графической программы или ее выполнения в режиме генерации управляющих данных.
Программное обеспечение АПРОГРАФ построено по модульному принципу. Принята концепция расширяемого ядра: к системе могут быть подключены новые модули, обеспечивающие в данной реализации существенное увеличение базовых возможностей. Структура системы представлена на рис. 1. В ядро входят база графических данных, процессор графических инструкций. Обязательными являются также модули Графический редактор (формирующий графический образ) и Интерпретатор (предназначенный для работы с программами на языке графического программирования). Специально выделены дисплейно-зависимые модули, что позволяет легко адаптировать АПРОГРАФ к различным типам графических устройств. Интерфейс системы технического зрения используется при автоматизации создания графических образов, постпроцессор позволяет генерировать программы на языке программирования роботов.
Первые версии системы АПРОГРАФ разработаны на языке ФОРТРАН на ЭВМ Мусгоп, часть функций (в том числе и трехмерная гра- 240
фика) реализована на отечественной ЭВМ ДВК-2. Последующие реализации написаны на языке программирования «С», который машинно-независим, обладает возможностями реализации операций, обычно программируемых на языке Ассемблера: адресная арифметика, битовые операции, спецификация регистров и т. п. Язык «С» соот^ ветствует современным структурнылг требованиям, достаточно выразителен, создает коды, эффективные как с точки зрения экономии памяти, так и по быстродействию.
Организация графических данных. Описание графических обра- зов в системе имеет многоуровневую структуру.
На нижнем уровне находятся так называемые элементы, представляющие собой информацию о графических примитивах формируемого изображения.
В версии, предназначенной для работы с плоскими изображениями, все данные образуют так называемую контурную цепь ——линейный список элементов, каждый из которых соответствует узловой точке (вершине) контурного изображения. В качестве атрибутов выступают значения координат и тип связи с предыдущей вершиной в списке.
Для работы с крупными фрагментами контурной цепи как с единым целым введено понятие графического объекта, идентифицируе- мого уникальным именем и задаваемого индексами своих начальной и конечной точек в контурной цепи. Объекты имеют следующие атрибуты: ориентация, координаты первой вершины (начала) объекта, число вершин.
В системе АПРОГРАФ принято представление объемных изображений сеткой многоугольников, но допускается возможность введения и более сложных пространственных примитивов (цилиндр, сфера и т. и.). Атрибутами элемента, описывающего вершину сетки, являются координаты и тип связи с предыдущей вершиной. Однако в отличие от двумерного случая имеется несколько контурных цепей и вводится понятие грани. Она представляет собой совокупность связанных элементов, лежащих в одной плоскости, и может обладать атрибутами (цвет, прозрачность). Объектам в трехмерном варианте приписываются атрибуты: ориентация и координаты первой вершины. Имеется возможность создавать иерархически организованные группы объектов.
Описанная структура достаточно гибка и позволяет создавать на основе ядра реализации, обладающие требуемыми свойствами.
Графические инструкции. Множество инструкций, позволяющих изменять графические данные и образы, практически едино для всех модулей системы и образует так называемый процессор графических инструкций. Исполнение большинства инструкций состоит из двух фаз: изменение образа на графическом терминале и изменение данных. Предусмотрена возможность получения параметров инструкций в режиме диалога.
Приведем список базовых инструкций процессора, разделенных на группы по уровню используемых графических данных (в скобках указаны допустимые мнемонические имена инструкций):
инструкции работы с элементами:
создание графических примитивов (линии (SET-LINE, L), гочки (SET-POINT, Р), в двумерном варианте — дуги (SETARC, С), окружности (SET-RING, R)),
удаление примитивов (DELETE),
порождение примитива в результате действий с существующими (пересечение (CROSS) и соединение (CONNECT) элементов), интерактивная графическая идентификация элементов (FIND); инструкции работы с гранями:
создание грани (задание атрибутов и указание на начало списка элементов (FACE)),
образование нового элемента (ребра) в результате пересечения граней (EDGE);
инструкции работы с объектами:
создание объекта (что эквивалентно заданию атрибутов объекта и указанию на начало списка составляющих его элементов (OPEN-O)),
перемещение объектов в пространстве (на плоскости) (вращение (ROTATE), сдвиг по указанному направлению (DRIVE) или по указанному изменению координат первой вершины (MOVE)), удаление объекта (REMOVE),'
объединение двух объектов в один (AFFIX) и расщепление объекта на два (CUT),
копирование объекта (COPY),
масштабное преобразование объекта с заданными по каждой оси координат коэффициентами (SCALE),
получение атрибутов объекта (ориентация (DIR), координаты (XOF, YOF и ZOF) и число вершин (LEN)),
интерактивная идентификация объекта (MARK); инструкции работы с изображением как с единым целым:
задание преобразования координат графических объектов, хранимых в базе данных, в экранные (SCREEN),'
задание вида проекции (для трехмерных изображений) (PROJ), отражение на экране образов, описанных в базе данных без масштабных преобразований (PAINT),
• очистка экрана (RESTART).
При отсутствии требуемого параметра на фазе исполнения система генерирует соответствующий запрос. Предусмотрены запросы позиции, элемента, объекта, имени (идентификатора), а также целочисленных и действительных величин.
В конкретных реализациях список может быть дополнен или из- менен. В системе предусмотрен ввод координат позиции с помощью аппаратных средств графического ввода (экранный курсор, световое перо, планшет), а также указание с их помощью на элемент графического образа. Предусмотрены комгшды вывода изображения на графопостроитель.
«Графический редактор». Диалог пользователя с программой «Графический редактор» ведется, как правило, на уровне графических инструкций.
В системе АПРОГРАФ реализован гибкий подход к организации общения между человеком и ЭВМ ——пользователь сам может выбирать «стиль диалога», переходя по мере овладения средствами системы от диалога, инициируемого ЭВМ, к диалогу, инициируемому пользователем.
Любое действие в системе можно задать с помощью выборов в иерархической системе меню и/или заполнения так называемых бланков, представляющих основные виды машинно-инициируемого диалога. В то же время имеется возможность непосредственно задавать команды без запросов ЭВМ.
В качестве команд используются графические инструкции, процедуры загрузки и сохранения графических файлов, справочные и информационные действия.
Язык графического программирования. Прототипами используемого в системе АПРОГРАФ языка графического программирования GBASIC (graphic BASIC) послужили универсальные языки программирования Бейсик, откуда заимствована идеология загрузки и исполнения программ, и ФОРТРАН, синтаксические конструкции которого использованы в ряде команд языка GBASIC.
К традиционным средствам описания арифметических вычислений, организации условных и безусловных переходов, обращения к параметризуемым подпрограммам добавлена возможность использования графических инструкций системы АПРОГРАФ.
Программа на языке GBASIC состоит из строк длиной до 80 символов (по одной строке на каждую инструкцию языка или комментарий).“
В языке определены числовые данные: константы (целые или действительные), переменные (представляемые идентификатором длиной до восьми символов), а также построенные из таких данных арифметические выражения.
Кроме того, в языке GBASIC разрешено использование графической базы данных системы АПРОГРАФ, а имеющиеся в ней структуры (элементы, грани, объекты) называются данными графического типа.
В языке определены следующие операции:
графические (зтО те же операции, которые может выполнить процессор графических инструкций; операндами здесь могут быть графические и числовые данные; допустимо неполное задание операндов; в этом случае система генерирует соответствующие запросы);
запись и чтение графических данных из дисковых файлов (SAVE и LOAD);
задание значений переменных:“
присваивание переменной значения другой переменной,
константы, атрибута или значение встроенной функции (LET), связывание (освобождение) переменной с графическим объектом (ASSIGN),
уничтожение переменной (KILL);
передача управления и организация подпрограмм (начальная инструкция подпрограмм (SUBROUTINE), вызов подпрограммы
(GOSUB) и возврат (RETURN), безусловный переход (GOTO), переход по условию (GOIF), инструкция-метка (LABEL));
вывод числовых данных во внешние файлы, определяемые пользователем (PRINT), а также открытие (OPEN) и закрытие (CLOSE) файла;
вывод диагностической информации о графических объектах (DUMP);
директивы интерпретатора, управляющие исполнением программы:
выполнить программу, начиная с указанного оператора (RUN),
прервать выполнение программы (BREAK), продолжить выполнение программы (CONT).
Составление программы на языке графического программирования, ее отладка и выполнение с целью моделирования робототехнической системы или получения промежуточной программы для постпроцессора осуществляются с помощью модуля^Интерпретатор. В его функции входят:
подготовка текста графической программы на языке GBASIC, редактирование, а также связанные с этим операции с текстовыми файлами;'
интерпретация одиночных инструкций языка GBASIC; ■ выполнение произвольной части программы с возможностью его прерывания по требованию оператора.
А1одуль Интерпретатор может работать в одном из двух режимов: ввод директив или команд и выполнение программы. В первом осуществляется ввод с клавиатуры терминала текста директивы или команды, при этом директива немедленно выполняется, а команда' выполняется и/или включается в текст программы в зависимости от ответа оператора на соответствующий запрос. Во втором режиме команды последовательно выбираются из текста графической программы и выполняются. В любой момент выполнение программы может быть прервано оператором (при этом Интерпретатор переходит в режим ввода директив) и затем продолжено по директиве CONT.
Формирование графических образов с помощью системы технического зрения. Применение системы технического зрения при подготовке графических данных в системе АПРОГРАФ имеет своей целью упростить процедуру формирования графических образов, необходимых для программирования роботов, в случае, когда источником информации о форме и взаимном расположении объектов может (или должна) быть сама рабочая среда. Имеется два варианта использования системы технического зрения совместно с модулем Графический редактор для подготовки графических данных. В мониторном режиме формируемое системой технического зрения изображение выводится на экран графического дисплея в качестве фона, на котором пользователь создает контурные изображения требуемых объектов. Контурный режим использования системы технического зрения реализуется путем загрузки непосредственно в рабочий буфер «Графического редактора» описаний контуров областей сегмен- 244
①汪роЕакноГО изображения, приведенных к формату контурных цепей графических объектов модулем Интерфейс системы технического зрения.
Синтез траекторий движения робота. В качестве примера использования системы АПРОГРАФ рассмотрим разработанную систему синтеза траекторий движения сборочного робота, кинематическая схема которого представлена на рис. 2. Робот имеет шесть степеней свободы. Углы в шарнирах обозначены соответственно 017 • . ., 0fi.
На рис. 3 представлено контурное изображение этого робота, созданное в системе АПРОГРАФ.
Синтез траекторий онсуществляется поэтапно:
задание графической модели сборочного поля, робота, а также кинематики робота;
интерактивный синтез опорных точек траекторий;
построение траектории и вычисление координат подвижных сочленений робота;
визуализация движений робота.
Этапы 1, 2 и 4 реализуются средствами языка графического программирования GBASIC. Для построения траектории робота необходимо включить в систему модули, рещающие обратную задачу кинематики для моделируемого робота. В данной системе преобразование характеристик положения и движения захватного устройства в координаты шарниров робота основано на методе аналитического обращения матрицы Якоби [8].
Пусть S ——вектор состояния (положения) захватного устрой- ства, тогда состояние и скорость движения захватного устройства можно описать соответственно уравнениями %
S = f (01, • •9б),,/⑷
S = / (8) 0,理
где J(9) = ("fj") — матрица Якоби.
Рис. 3. Контурное изображение робота, созданное в системе АПРОГРАФ
Траектория разбивается на малые отрезки, осуществляется переход от дифференциалов к линейным приращениям, и полученная система разрешается относительно 厶仇.Сформированные данные передаются программе на языке GBASIC, которая визуализирует полученное решение для данного отрезка траектории.
Известно, что разработка программы для сборочного робота традиционным способом может иметь трудоемкость в несколько челове- ке-месяцев и требует высокой квалификации программиста. Использование графических моделей в системе АПРОГРАФ упрощает процесс разработки программ и резко снижает трудоемкость отладки за счет использования визуального контроля правильности каждого действия моделируемого робота.
ЛИТЕРАТУРА
Warnecke Н. /., Linder Н. Trends in Robotic Research in European Comuni ty.— In: Proc. 85 Intern. Conf. Adv. Robot. 9—10 sept. 1985, Tokyo (Japan). Tokyo, 1985, p. 7—13.
Логинов Л. И. Система автоматизации программирования сборочных промышленных роботов.— В кн.: Методы расчета гибких автоматизированных производств. М.: МИ①И, 1984, с. 363—399.
Mazer Е. LM-GEO, Geometric Programming of Assembly robots.— In: Advanced Software in robotics. Amsterdam: North-Holland, 1984, p. 214— ■ 221.
Якович H. Программные средства моделирования, упрощающие построение рабочих мест с роботами.— Электроника, 1983, т. 56, № 20, с. 48—53.
Pertin-Groceaz /. S. М. G. R.— A Geometric and Relational Modeller for Robotic Applications.— In: Proc. Intern. Gonf. Adv. Robot. 9—10 sept. 1985, Tokyo (Japan). Tokyo, 1985, p. 23—31.
BYTE, Special Issue on Smalltalk, 1981, vol. 6; N 8. 480 p.
Переслени С. A. ^ Рахманкулов В. 3. Система графического программирования для робототехнических комплексов.— В кн.: III Всесоюз. конф. «Роботы н робототехнические системы», Челябинск, 1983: Тез. докл. Челябинск: Челяб. политехи, ин-т, 1983, т. 2, с. 130—131.
Верещагин Л. Фм Минаев Л. Н. Принципы построения специализированных вычислителен для позиционного супервизорного управления манипуляционным роботом.— Изв. АН СССР. Техн, кибернетика, 1978, № 4, с. 56—65.
УДК 681.32
АЛГОРИТМИЧЕСКОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРОБЛЕМНО-ОРИЕНТИРОВАННОЙ ДИАЛОГОВОЙ СИСТЕМЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ ИНТЕГРИРОВАННЫХ ПРОИЗВОДСТВЕННЫХ КОМПЛЕКСОВ МЕХАНИЧЕСКОЙ ОБРАБОТКИ
В. Н. Войтов, С. П. Кузьмин, М. И. Ремизов, Т. В. Уханова
Проблемно-ориентированная диалоговая система имитационного моделирования интегрированных производственных комплексов (ИПК) предназначена для решения задач системного анализа и выбора параметров организационно-технологической структуры, исследования алгоритмов оперативно-календарного планирования и управления, а также других задач, возникающих на различных этапах исследования, проектирования, реорганизации, технологической подготовки и функционирования гибкого автоматизированного производства [1].
ФОРМАЛИЗАЦИЯ ФУНКЦИОНИРОВАНИЯ ИНК
(на примере ИПК механообработки)
Работу ИПК механообработки формально можно рассматривать как функционирование сложной иерархической системы массового обслуживания, или так называемой Q-схемы [2]. Пример графического изображения (?-схемы ИПК некоторой типовой структуры представлен на рис. 1.
Основными элементами Q-схем垃 являются потоки событий, потоки заявок на обслуживание и приборы обслуживания, состоящие из каналов обслуживания и накопителей.
Поток событий представляет собой последовательность событий, происходящих1 в некоторые, вообще говоря, случайные моменты времени. Кроме моментов наступления событий, каждое из них может характеризоваться набором признаков события (неоднородные события).
При моделировании ИПК в качестве основных событий целесо
образно выделить:
поступление в ИПК и выход из него транспортной партии деталей;
начало и окончание штабелирования транспортной партии деталей;.
начало и окончание транспортировки транспортной партии деталей;
начало и окончание обработки транспортной партии деталей на одной из групп основного оборудования;
поломка (отказ) штабелера, тележки (транспортного робота) или основного оборудования;
начало и окончание ремонта (восстановления) штабелера, тележки или основного оборудования;
начало и окончание наладки основного оборудования.'
С учетом приведенных событий в Q-схеме ИПК возможны следующие виды потоков событий:
поток поступлений транспортных партий деталей в ИПК;
поток окончаний штабелирования транспортных партий деталей;
поток окончаний обработки транспортных партий на оборудовании;
потоки отказов штабелера, тележки и основного оборудования;
потоки восстановления (окончания ремонта) штабелера, тележки и основного оборудования;
поток окончаний переналадки основного оборудования.
Потоки событий в 0-схеме ИПК порождают, в свою очередь, потоки заявок на обслуживание (на штабелирование, транспортировку, обработку, наладку основного оборудования и ремонт штабелера, тележки и основного оборудования).
Некоторые виды потоков событий являются в то же время потоками обслуженных заявок.
Обслуживание заявок в Q-схеме осуществляется каналами обслуживания пяти видов:
основным технологическим оборудованием;
транспортным оборудованием центрального склада (штабелером);
межоперационным транспортным оборудованием (транспортными роботами или тележкой);
наладчиками основного оборудования;
ремонтниками оборудования；
В рассматриваемой Q-схеме как модели ИПК некоторого уровня циркулируют три типа заявок на обслуживание:
собственно заявки-детали (транспортные партии);
заявки-запросы, сопровождающие обслуживание заявок-деталей; заявки-запросы от приборов (каналов) обслуживания.
В качестве заявок первого типа рассматриваются материальные потоки заготовок, полуфабрикатов и готовых деталей.
К заявкам второго типа относятся информационные запросы на:
штабелирование деталей в пределах центрального склада;
транспортировку деталей между центральным складом и промежуточными накопителями в соответствии с маршрутной технологией.
Рис. 1. Модель функционирования ИПК механообработки в виде Q-схемы
Ш Т О Н Р-каналы штабелера, тележки, основного оборудования, наладчиков и ре- мо^иков соответственно; Днш, ДнТ' Дн0, Днн> Днр 一 Диспетчеры накопителей соответствующих каналов обслуживания
% 9 Заказ № 2408
Заявками третьего типа являются информационные запросы на: восстановление штабелера, тележки и основного оборудования; наладку основного оборудования.
Потоки заявок на обслуживание в силу нерегулярности порождающих их событий, а также ограниченной пропускной способности каналов обслуживания приводят к образованию очередей заявок, для хранения которых используются накопители двух типов:
списки заявок-запросов на обслуживание тем или иным каналом;
списки заявоктдеталей, отображающие физические накопители транспортных партий.
Накопители первого типа имеются в следующих приборах обслуживания: штабелера, тележки, ремонтников и наладчиков.
Ко второму типу относятся накопители, соответствующие центральному складу и промежуточным накопителям реального ИПК.
Процесс функционирования Q-схемы ИПК состоит в диспетчировании заявок в накопителях и блокировке каналов и накопителей.
Диспетчиробание представляет собой процесс упорядочивания заявок при их поступлении в накопитель и (или) при выборе на обслуживание и осуществляется логическим диспетчером на основе определенных, заранее заданных алгоритмов (дисциплин обслуживания). Диспетчирование по алгоритмам, исп о ль зующим статические приоритеты, происходит сразу же при поступлении в накопитель очередной заявки на обслуживание. Диспетчирование по алгоритмам, использующим динамические приоритеты, осуществляется непосредственно перед началом обслуживания.
Блокировка каналов и накопителей соответствует реакции системы управления на различные ситуации, возникающие в ИПК, и возможна как на входе, так и на выходе.
Блокировка входа канала означает, что он не может принять заявку на обслуживание, и приводит к одновременной блокировке выхода соответствующего накопителя. На входе могут быть блокированы каналы штабелера, тележки и основного оборудования.
Блокировка выхода канала означает, что обслуженная им заявка по тем или иным причинам не может его покинуть, и приводит к одновременной блокировке его входа. На выходе могут быть блокированы каналы штабелера и тележки.
Блокировка входа накопителя означает невозможность поступления заявок вследствие его полной занятости. В Q-схеме ИПК блокированными на входе могу匸 быть накопители центрального склада и накопитель основного оборудования, т. е. те накопители, которым соответствуют накопители заявок-деталей.
В общем случае Q-схема ИПК многофазная, многоканальная, комбинированная (в том смысле, что включает как сквозные потоки заявок, так и потоки заявок, движущихся по обратным связям), с потоками неоднородных событий, с ограниченными и неограни ченными очередями, приоритетная и с ненадежными обслуживающими npn6opaMu；(c восстановлением).
С формальной точки зрения Q-схему различной сложности в：о6-
щем случае можно однозначно задать в виде
Q =〈叩，U, Я, Z,凡 4〉，”
где W ——множество потоков заявок на обслуживание; U ——множество потоков обслуживаний; Н ——множество собственных параметров структуры Q-схемы; R ——оператор сопряжения, отражающий взаимосвязь элементов структуры ^-схемы между собой (т. е. связи, по которым осуществляется прохождение заявок); Z ——множество возможных состояний собственных элементов ^-схемы; А —— оператор возможных алгоритмов поведения заявок в Q-схеме.
Множество W определяет режимы поступления заготовок в систему во времени и по количеству (партионность и периодичность запуска деталей в обработку), а множество U ——распределение продолжительностей процессов обслуживания (например, станко- емкости операций, временных затрат на наладку, ремонт, транспортировку и штабелирование).
Применительно к ИПК как объекту моделирования выбранного уровня рассмотрения параметры Q-схемы можно, в свою очередь, конкретизировать следующим образом:
Я =〈厶 к, N,刃〉，
Z -〈ZR ZN〉，
4 =〈3产,3/ 8\ 0* dR М〉，
где L ——количество фаз приборов обслуживания в Q-схеме; К —— вектор, определяющий количество каналов обслуживания по фазам； N ——вектор, определяющий количество накопителей по фазам; Е —— матрица, определяющая емкости накопителей в каждой фазе обслуживания; ZR, ZN ——множество возможных состояний соответственно каналов обслуживания (например, свободен, занят производительно или непроизводительно и т. д.) и накопителей (в смысле возможной заполненности); Bf, Bq, Bn ——правила (алгоритмы) блокировки соответственно каналов обслуживания на входе и выходе и накопителей (имеет смысл рассматривать блокировку только входа накопителей); DN^ DK ——диспетчирующие правила соответственно поступления заявок в накопители и выбора заявок из накопителей на обслуживание в канале; М ——множество возможных маршрутов прохождения заявок по фазам (приборам) обслуживания.
ФУНКЦИОНАЛЬНО-АЛГОРИТМИЧЕСКАЯ СТРУКТУРА ПРОБЛЕМНО-ОРИЕНТИРОВАННОЙ ДИАЛОГОВОЙ СИСТЕМЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ ИПК
Реализованная на базе системы имитационного моделирования на ФОРТРАНЕ (СИМФОР) [3] проблемно-ориентированная диалоговая система имитационного моделирования ИПК может функционировать под управлением операционной системы разделения функций
(РАФОС) на управляющих вычислительных комплексах типа СМ-4, «Электроника-100/25», СМ-1420, «Электроника-79»Т имеющих не менее 128К байт оперативной памяти.
Процесс создания требуемого варианта имитационной модели в проблемно-ориентированной диалоговой системе имитационного моделирования ИПК включает в себя генерацию в интерактивном режиме текстов СИМ.ФОР и специального проблемно-ориентпрован- ного программного обеспечения.
Укрупненная схема моделирующего алгоритма имитационной модели ИПК. механообработки приведена на рис. 2.
Функ1июналъная структура проблемно-ориентированной диалоговой системы имитационного моделирования ИПК включает три взаимодействующих между собой компонента:
пакет моделирующих программ;
программный генератор моделей;
информационная подсистема.
Пакет моделирующих программ представляет собой набор программных модулей, написанных на языке ФОРТРАН и реализующих различные функции, необходимые для моделирования ИПК как про изводственно-тел но логического объекта.
В состав пакета моделирующих программ входят как специальные модули, реализующие проблемную ориентацию системы имитационного моделирования, так и стандартные модули СИМФОР, обеспечивающие моделирование дискретных процессов (дискретный вариант СИМФОР).
Состав и структура специальных модулей пакета моделирующих программ определяются автоматизированно в диалоговом режиме с помощью программного генератора моделей.
При разработке пакета моделирующих программ использован модульный принцип, в соответствии с которым каждая подпрограмма обеспечивает выполнение основной (определяющей) функтщи и связанных с ней процедур.
В состав пакета моделирующих программ входят управляющие, функциональные и вспомогательные подпрограммы.
Управляющие подпрограммы, предназначенные для управления процессом моделирования, осуществляют взаимодействие специальных подпрограмм и подпрограмм СИМФОР и реализуют следующие возможности:
программное управление процессом моделирования на основе анализа и ведения модельного времени (STEXR);
интерактивный контроль за процессом моделирования (STSUP);
интерактивное вмешательство в процесс моделирования: просмотр состояния объектов, вывод накопленных статистик, изменение значений объектов и т. д. (STMIN);
распознавание модельных событий и вызов соответствующих подпрограмм, реализующих эти события (EVNTS);
интерактивная связь с оператором для решения вопроса о продолжении или окончании моделирования (USFTJN).
В состав функциональных подпрограмм входят только специальные модули пакета моделирующих программ, выполняющие функции: реализация событий:
поступление партии деталей в ИПК (ARRL),
окончание выполнения технологической операции над транспортной партией деталей на основном оборудовании (FPR€)C), окончание транспортировки передаточной партии деталей по
средством тележки (FRROC1),
окончание штабелирования передаточной партии деталей
(FPROC2),
окончание переналадки основного оборудования (FSETP),
выход транспортной партии готовых деталей из ИПК (OUTSM),
отказ основного оборудования (REFUS),
окончание восстановлен：1я основного оборудования (REVIV),
отказ тележки (REFUS1),
окончание восстановления тележки (REVIV1),
отказ штабелера (REFUS2),
окончание восстановления штабелера (REVIV2),
условное окончание моделирования и расчет необходимого количества наблюдений для получения статистически значимых результатов (SAMPL)；
реализация процессов, сопровождающих события:
загрузка оборудования и определение момента окончания обработки партии деталей или отказа основного оборудования (LDER2), загрузка тележки и определение момента окончания тран
спортировки партии деталей или отказа тележки (LDER4)；
загрузка штабелера и определение момента окончания штабелирования транспортной партии деталей или отказа штабелера (LDER5),
переналадка оборудования и определение момента окончания переналадки (SETUP),
считывание информации из файлов исходных данных или генерация маршрутной технологии для поступления в ИПК транспортных партий деталей (GNTEN),
генерация пооперационных трудоемкостей обработки партий деталей (GNOPT),
планирование наступления событий через заданный или вычисленный промежуток времени (DELAY);
расчет приоритетов заявок на обслуживание и диспетчирование загрузки обслуживающих средств:
расчет статического приоритета для выбора партии деталей из очереди на загрузку (PRIRS),
расчет динамического приоритета для выбора партии из очереди на загрузку (PRIRD),
выбор партии деталей из очереди на обработку в соответст
вии с заданным правилом диспетчирования (LDER1),
выбор партии деталей из очереди на транспортировку в соответствии с правилом диспетчирования загрузки транспортного устройства (LD ER3).
В состав вспомогательных подпрограмм входят как специальные модули, так и стандартные модули СИМФОР, осуществляющие следующие функции:
инициализация переменных и массивов модели;
сбор информации для статической обработки и построения графиков и гистограмм;
вывод результатов моделирования;
организация работы со списками (очередями) модели.
Кроме того, в состав вспомогательных подпрограмм входят служебные подпрограммы.
Подпрограммы инициализации выполняют:
вызов специальных подпрограмм инициализации (USINT);
диалоговую коррекцию значений параметров транспортно-накопительной системы (USI1);
считывание исходных данных из файлов оборудования и инициализацию рабочих массивов модели по оборудованию (USI2); диалоговое задание значений параметров переналадок и параметров входного потока деталей-заявок и потока их обслуживания, а также инициализацию массивов сбора статистик и вспомогателиных массивов и переменных (USI3);
инициализацию массивов и переменных СИМФОР до начала каждой реализации (STDAT);
восстановление начальных состояний постоянных объектов модели (RETIM);,
Подпрограммы сбора информации осуществляют:
сбор статистик по основному и транспортному оборудованию, величине незавершенного производства (TIMOD);
передачу данных по характеристикам прохождения заявок- деталей через систему для сбора статистик (FSTAT), в том числе стоимостных (FSTAT1);
сбор статистик по характеристикам прохождения заявок-деталей через систему (CCCOL) и по характеристикам использования основного и транспортного оборудования (CCTIM);
сбор статистик для построения гистограмм (CCHIS) и графиков (CCGPL).
Подпрограммы вывода результатов моделирования реализуют: вызов специальных подпрограмм вывода результатов (USOUT)； вывод исходной информации по оборудованию и номенклатуре обрабатываемых деталей (USO1) к исходных значений параметров имитационной модели (USO2);
формирование и передачу данных для сбора и вывода результатов в графической форме (USO3);
вывод результатов моделирования в графической и табличной форме (PRGPL).
Подпрограммы работы со списками (все они являются подпрограммами СИМФОР) выполняют:
копирование информации, характеризующей заявку, из списка в рабочий массив. (FCOPY);
занесение записи в указанный список (FILEM) и ее извлечение (RMOVE),f
Служебные специальные подпрограммы осуществляют： поиск для группы оборудования транспортной партии деталей, претендующей на обработку (NFRES);
создание на основе исходной планово-технологической информации гистограммы периодичности поступления передаточных партий в ИПК и вычисление среднего времени между поступлениями партий заготовок в ИПК (TRANS);
идентификацию деталей, поступающих в ИПК (HIST);
определение номера партии деталей и группы оборудования, на котором она прошла обработку (NATR);
расчет суммарного критерия затрат (OUTGRT).
Программный генератор моделей представляет собой программу, написанную на языке ПАГЕН и содержащую тексты специальных подпрограмм пакета моделирующих программ.
Программный генератор моделей является эффективным средством автоматизации процесса создания имитационных моделей, позволяющим в режиме диалога генерировать модели ИПК выбранной структуры для решения конкретных задач моделирования, полностью исключив при этом процесс программирования.
Кроме того, программный генератор моделей позволяет получать программные реализации имитационных моделей, эффективные с точки зрения быстродействия и допустимой размерности, что достигается за счет:
определения конфигурации модели, наиболее эффективной с точки зрения состава входящих в нее специальных подпрограмм пакета моделирующих программ;
генерации наиболее эффективных текстов подпрограмм с точки зрения состава входящих в них блоков (т. е. функционально или логически законченных частей текста подпрограммы в виде набора операторов на ФОРТРАН©);
наиболее эффективного использования оперативной памяти ЭВМ.
Функциональная схема программного генератора моделей представлена на рис. 3.
Информационная подсистема представляет собой программу, предназначенную для автономного от процесса моделирования создания и коррекции двух хранящихся в виде файлов прямого доступа исходных информационных массивов:
планово-технологической информации;
организационно-технологической структуры.
Каждая деталь из номенклатуры, обрабатываемой в ИПК, описывается в массиве планово-технологической информации следующими параметрами: наименованием, шифром, стоимостью заготовки (материала), размером и количеством партий запуска на плановом периоде, размером транспортной (передаточной) партии, количеством технологических операций, а по каждой операции ——номерами закрепленных за ней групп оборудования и наладок, а также трудоемкостью.
Каждая группа оборудования описывается в массиве организационно-технологической структуры следующими параметрами: на- 256 ■
Рис. 3. Функциональная] схема программного генератора} моделей проблемно-ориентированной диалоговой системы имитационного моделирования
именованием, шифром, средней длительностью безотказной работы и ремонта, расстоянием от центрального склада, количеством единиц в группе, номером группы обслуживающих транспортных средств, стоимостью часа работы, простоя и ремонта единицы оборудования, капитальными затратами на единицу оборудования (включая затраты на производственные площади).
Информационная подсистема построена по модульному принципу в соответствии с реализуемыми ею функциями. Диалоговый режим работы информационной системы на языке, доступном не имеющему специальной подготовки пользователю (технологу-проектировщику), позволяет создавать и корректировать различные варианты массивов планово-технологической информации и организационно-технологической структуры, отражающие возможные альтернативные решения по организационно-технологической структуре и оперативному управлению ИПК.
ЛИТЕРАТУРА
Войтов В.反.，Ремизов М. И., Уханова Т. В. Диалоговая система имита- [ционного моделирования процессов функционирования автоматизированных технологических комплексов.— В кн.: Математическое, информационное и программное обеспечение систем управления промышленных роботов и ГАП. М.: МДНТП, 1984, с. 54-59.
Советов Б. Я., Яковлев С. Л. Моделирование систем. М.: Высш. шк. 1985. 272 с.
Операционная система СМ ЭВМ РА①ОС: Справочник/Л. И. Валикова, Г. В. Вигдорчик, А. Ю. Воробьев, А. Л. Лунин. М.: Финансы и статистика, 1984. 207 с.、
УДК 510.682:621.868.8
СТАНДАРТИЗАЦИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ В РОБОТОТЕХНИКЕ
Н. Е. Богомолов, Ю. М・ Лазутин, В. С. Ярошевскии
Появление надежных и малогабаритных микропроцессорных наборов и микро-ЭВМ обеспечило их широкое применение в задачах управления робототехнических комплексов и гибких производственных систем. Современное производство требует, чтобы управляющие системы обеспечивали сложную логику поведения контролируемых объектов, их адаптивность. Таким образом, математическое программное обеспечение является одним из наиболее существенных компонентов всякого адаптивного робототехнического комплекса. Стоимость разработки программных средств составляет значительную часть общей стоимости создания такого комплекса. Наконец, для поддержания должного уровня эффективности функционирования робототехнического комплекса, его усовершенствования необходима регулярная работа по модификации программно-математического обеспечения.
Для эффективной модифицируемости программ, снижения стоимости их разработки желательны стандартизация используемых в робототехнических задачах языков программирования, опр©деление
Рнс. !• Классификация языков программирования роботов
предъявляемых к ним требований. Это позволит разработчику иро- граммно-математических средств более точно сформулировать стоящие перед ним проблемы, будет способствовать использованию уже разработанных программных модулей, их унификации.
В настоящее время утвержден стандарт по языкам программирования роботов [1], в котором учтены замечания, высказанные при обсуждении временных технических условий ГОСТ 26064-83 «Роботы промышленные. Устройства программного управления. Языки пр огр аммир об ани я и кодирования информации».
При разработке указанного стандарта авторы стремились не накладывать жестких ограничений на программные средства. Были поставлены задачи провести классификацию языков программирования, используемых в робототехнике, подытожить результаты, полученные в процессе эксплуатации существующего программного обеспечения роботов, сформулировать требования к этим языкам.
Классификация языков программирования роботов начинается с разделения их на два класса: инструментальные языки программирования и языки аналитического программирования (рис. 1). Инструментальный язык программирования предназначен для:
разработки и отладки алгоритмов;
создания сервисных и системных программ для устройств управления промышленного робота;
написания операционных систем реального времени;
трансляторов специализированных языков программирования.
Инструментальный язык реализуется на ЭВМ, которая может непосредственно не входить в состав устройства управления робота. Подготовленные программы переносятся на управляющую ЭВМ либо с помощью канала связи между машинами, либо через перфоленту, магнитный диск и т. д.
Языки аналитического программирования должны предоставлять средства описания функционирования промышленного робота и выполняемой им задачи. Разделение языков программирования роботов на два указанных класса носит достаточно условный характер: язык может удовлетворять требованиям, предъявляемым как к инструментальным языкам, так и к языкам аналитического программирования.
В качестве предпочтительных управляющих и инструментальных ЭВМ выбраны 16-разрядные мини- и микро-ЭВМ типа «Электроника-60», СМ-2,-4, М-6000. Этот выбор обусловлен тем, что: машины данного класса наиболее распространены и доступны; с помощью 16-разрядных слов могут быть организованы числен^ ные расчеты, точность которых достаточна в большинстве случаев для нужд робототехники;
16-разрядное слово хорошо соответствует разрядности датчиков, существующих в настоящее время и используемых для сбора информации о внешней среде;
архитектура с 16-разрядным словом позволяет реализовать алгоритмы в робототехнике без значительных потерь памяти: для задач такого типа характерна разветвленная логика передач управления, логическое программирование, при котором обычно используется только несколько битов слова. ,
Необходимо отметить, что предложенный ГОСТ не запрещает разрабатывать устройства управления на базе ЭВМ с иной архитектурой. На более мощной ЭВМ может быть установлена расширенная версия программно-математического обеспечения. При этом, однако, должна обеспечиваться преемственность версий. Выполнение указанных условий способствует достижению портативности программных продуктов.
Инструментальные языки делятся на четыре подкласса по двум независимым критериям.
Во многих задачах робототехники может быть выделен ряд относительно замкнутых подзадач, взаимодействующих между собой достаточно редко. Для эффективного программирования в подобных случаях необходимы специальные языковые средства записи параллельных программ. В связи с этим инструментальные языки программирования подразделяются на имеющие данные средства и не имеющие их.
Вторым критерием классификации является ориентированность языка на задачи робототехники.
В каждом из введенных четырех подклассов инструментальных языков выделяют три уровня:
язык Ассемблера,
макроязыки,
языки с собственным синтаксисом.
Уровень языка определяет производительность программирования на нем. Как показывают проводившиеся исследования, число операторов, отлаженных в день квалифицированным программистом, является величиной приблизительно постоянной независимо от уровня языка [2]. Объем же текста программы, необходимый для решения данной задачи, с переходом на язык высокого уровня уменьшается.
Языки, имеющие собственный синтаксис, подразделяются на три подуровня в соответствии с их реализацией, что отражает различие в скорости транслирования программ.
В подклассе инструментальных языков, имеющих средства записи параллельных программ, отметим следующее требование. Языки этого подкласса должны давать возможность пользователю управлять распределением процессов, выделенных в задаче, по процессорам управляющей сети машин (при использовании многомашинных управляющих комплексов).
Для достижения максимальной эффективности на «критических» участках разрабатываемых программ инструментальный язык должен предоставлять средства записи части текста программы на языке Ассемблера данной ЭВМТ что позволяет сохранить достоинства языков высокого уровня и обеспечить выполнение заданных требований к программе на критических участках по быстродействию, объему памяти и т. д. Кроме того, такие «автокодные вставки» дают возможность реализовывать функции, не предусмотренные в языке программирования, но реализуемые системой команд управляющей ЭВМ.
Стандарт предъявляет требования к инструментальным языкам программирования, хотя они и не обладают особенностями, присущими исключительно программному обеспечению систем управления промышленными роботами, а могут использоваться для решения более широкого спектра задач. Однако инструментальные языки являются теми средствами, которые подготавливают программно-операционную среду и от правильного выбора которых зависят и эффективность, и качество работы программиста. Поэтому в стандарте предъявляются требования к программным изделиям и документам, реализованным на таких языках программирования, как, например, ФОРТРАН.
При классификации языков аналитического программирования в соответствии с уровнями описания управляющей программы устройства программного управления промышленного робота выделяют:
нижний уровень — язык описания управляющей программы, на котором непосредственно программируют требуемые действия робота, перемещения его степеней подвижности, операции по сбору информации о внешней среде и собственно состоянии;
следующий уровень ——язык описания работы (движения промышленного робота и контрольные операции), на котором возможно введение «обобщенных» операций (под ними понимаются именованные совокупности действий), к которым можно обращаться по имени;
Рис. 2. Конфигурации средств программирования промышленного робота
наиболее высокий уровень ——язык описания технологической задачи, на котором задаются действия и операции, выполняемые над деталями по обработке, транспортировке и контролю.
Более подробно иерархия средств программирования промышленных роботов представлена на рис. 1.
Среди требований, выдвигаемых стандартом к языкам аналитического программирования, следует выделить обеспечение надежности. Данный класс языков представляет собой непросто совокупность средств для записи последовательности действий промышленного робота. Это программный комплекс, реализуемый в определенном аппаратном окружении, ориентированный на данное окружение и, как следствие, отражающий его специфику (рис. 2). Понятие надежности объектного модуля определяется его способностью диагностировать отказы оборудования и выход значений переменных за установленные пределы.
Классификация языков аналитического программирования, данная в стандарте, проведена по возрас^нию сложности, соответствует различным уровням подробности описания функционирования промышленного робота, общности и привязки к конкретному оборудованию. Каждому уровню сопоставляется определенный этап разработки управляющего программного комплекса. Таким образом, с реализацией языка аналитического программирования очередного уровня будет формализован и автоматизирован соответствующий этап разработки управляющей программы.
Стандарт требует использовать принципы модульного и структурного программирования, которые обеспечивают возможность разработки программного продукта коллективом программистов, легкую модификацию программ при сопровождении, надежное тестирование [31.
Остается открытым ряд важных вопросов, в частности:
отсутствие хороших критериев оценки эффективности транслятора, надежности получаемых программ;
в связи с тем, что разные версии трансляторов могут генерировать различный объем кода, не разработаны параметры измерения скорости трансляции;
не разработаны критерии оценки трудоемкости пр огр аммир ов а- ния на данном языке и сопровождения получаемых программ.
Эти вопросы, очевидно, возникают относительно не только язы- 262 *
кой программирования промышленных роботов^ но и любой другой группы языков.
Стандарт отражает этап в выработке согласованной системы терминов и определений, позволяющих взаимодействовать между собой различным группам разработчиков робототехнических систем, определять требования и задачи, стоящие перед программным обеспечением.
ЛИТЕРАТУРА
Промышленные роботы. Устройства программного управления. Языки программирования и кодирования информации. Основные положения: ГОСТ 26085-84.'
Шнейдерман Б. Психология программирования.: Пер. с англ. М.: Радио и связь, 1984. 303 с.
Лингер Р., Миллс X., Уитт Б. Теория и практика структурного программирования.: Пер. с англ. М.: Мир, 1982. 406 с.
ПРИЛОЖЕНИЕ
РЕКОМЕНДАЦИИ ДЛЯ РАЗРАБОТЧИКОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ И ГИБКИХ АВТОМАТИЗИРОВАННЫХ ПРОИЗВОДСТВ *
Рабочая группа по программному обеспечению Научного совета по проблеме «Робототехника и автоматизированное производство» при Отделении механики и процессов управления АН СССР выработала ряд рекомендаций в области программного обеспечения роботов и гибких производственных систем (ГПС). Для широкой аудитории представляют интерес материалы по проблемам надежности программно-аппаратных средств робототехнических комплексов (РТК) и ГПС, требования к архитектуре и составу оборудования устройств управления со стороны программного обеспечения и описания архитектуры программного обеспечения локальных сетей для ГПС.
Критерии и программно-аппаратные средства обеспечения надежности робототехнических систем, станков с ЧПУ и ГПС
Основные показатели надежности'~
В настоящее время основными критериями, характеризующими надежность оборудования, являются наработка на отказ и время восстановления работоспособности оборудования после сбоя или отказа. Практически, экспериментальное определение этих критериев (в особенности первого) возможно лишь в условиях установившегося процесса производства и эксплуатации оборудования, т. е. в течение довольно длительного времени.一
Желательно в качестве основного критерия надежности работы оборудования и программного обеспечения взять такой критерий, который можно определить на единичных образцах, поступающих в эксплуатацию из опытной серии.
Таким критерием для оборудования является относительное время (в процентах от общего времени эксплуатации рассматриваемого оборудования), требуемое для восстановления работоспособности оборудования после сбоя или отказа с учетом временных потерь из-за незавершенности (брака) работы в результате сбоя или отказа. Этот критерий точно соответствует снижению производительности из-за сбоев и отказов оборудования и учитывает вместе с тем наличие сервиса, сокращающего время восстановления отказавшего оборудования.
Однако возможны ситуации, когда надежность характеризуется этим критерием не однозначно. При достаточно большом времени испытаний он может
* Рекомендации были обсуждены на заседании Рабочей группы по программному обеспечению Научного совета по проблеме «Робототехника и автоматизированное производство» при Отделении механики и процессов управления АН СССР 27 ноября 1985 г. Материал подготовлен к печати Р. К. Казаковой.
нпет* одинаковое значение в случаях, когда одновременно велики время восстановления и наработка на отказ либо когда они одновременно малы. Поэтому для определения надежности желательно в качестве дополнительного выбрать шиег- рир5тющий критерий ——коэффициент готовности оборудования к использованию и определять этот коэффициент не экспериментально, а теоретически, исходя из математической модели, как это делается для систем с очень большим временем наработки на отказ.
Критерием надежности программного обеспечения является отношение количества неправильных 八ciicTBiiii оператора (т. е. ошибочных, выходящих за допустимые пределы, не соответствуюп],их требуемой последовательности и др.) и сбоев или отказов оборудования, не защищенных программным обеспечением (приводящих к нарушению штатного режима работы системы), к общему количеству возможных действии оператора и сигналов оборудования, обрабатываемых программным обеспечением.
Такой критерий может быть определен в процессе испытания каждого образца оборудования и программного обеспечения по соответствующим методикам.
В значении указанного критерия надежности не должиы учитываться ошибки, выявленные в программном обеспечении, если действия оператора правильны и оборудование исправно. Отсутствие таких ошибок является свидетельством правильности программного обеспечения, а не его надежности.
Основной причиной ненадежности функционировапия в комплексах программ являются невыявленные ошибки. В процессе отладки большая часть ошибок в программах обнаруживается и устраняется. Однако при любой отладке выявляются ошибки, но не доказывается их отсутствие. Построение полного набора тестов сложного программного комплекса практически невозможно. В результате после отладки всегда остается некоторое количество невыявленных ошибок.
Надежность аппаратуры определяется в основном надежностью компонентов и ошибками в конструкции, а надежность программного обеспечения — наличием программных защит и количеством необнаруженных ошибок. Причины отказов аппаратуры и программ аналогичны:
АппаратураПрограммное обеспечение
наличие логических ошибок в проекте или его несовершенство ошибки изготовлениянеправильное кодирование
внутренняя ненадежностьнесовершенство отладки
компонентов
временный износрост неопределенности программ
вследствие внесения изменений
Программно-аппаратные средства обеспечения надежности
Предлагается путем ввода дополнительных элементов в оборудование и дополнительных программных модулей в программном обеспечении достигнуть такого положения, при котором сбой или отказ оборудования парируется программой системы управления, а сбой системы управления или ошибка в программе —— средствами защиты оборудования. Такими дополнительными элементами оборудования могут быть средства обеспечения безопасности, формирователи сигналов готовности и программно, доступные средства переконфигурации системы или ее аварийного выключения. В качестве дополнительных модулей в программ] ое
обеспечение включаются блок диагностики оборудования, блок контроля правильности программы, средства защиты файлов и контроля диалога с оператором. Следует подчеркнуть, что без такой избыточности оборудования и программного обеспечения надежность РТК и ГПС не может быть обеспечена.
Наряду с использованием термина «надежность» целесообразно использовать термин «отказоустойчивость» для обозначения способности системы поддерживать выполнение возложенных на нее функций при выходе из строя части оборудования, обеспечивающего их реализацию. Термин «надежность» означает способность парировать внешние (по отношению к системе, устройству) нештатные события, «отказоустойчивость» ——поддержание функционирования всей системы при внутренних сбоях.
Гибкость по отказам в РТК и ГПС
Предлагается, чтобы гибкое программное обеспечение характеризовалось способностью продолжить работу системы при возникновении одиночного отказа из заранее заданного перечня и лишь двойной отказ мог бы потребовать останов, но не должен приводить к опасности для персонала или оборудования. Для реализации такого требования желательно максимально использовать функциональный способ резервирования о помощью программного обеспечения (путем перестройки структуры системы при отказах) вместо удорожающего систему «холодного» или «горячего» резервирования оборудования. Последнее следует допускать лишь в самих аппаратных средствах обеспечения надежности (блок безопасности и др.).
Предсказуемость поведения при n-кратных отказах должна считаться важнейшей характеристикой надежности программного обеспечения. Предсказуемость поведения зависит от пр едп о л о жений о надежности программных и аппаратных элементов, алгоритмов диагностики неисправностей и алгоритмов перестройки в случае обнаружения отказа. Только при определенных предположениях о характере ошибок можно требовать создания таких алгоритмов диагностики и (или) перестройки программного обеспечения.
Необходимые мероприятия
В качестве необходимых мероприятий для обеспечения надежности можно рекомендовать разработать:
систему мероприятий по организации экспертизы проектов РТК и ГПС и совместного проектирования программных и аппаратных средств； специальную элементную базу (в том числе датчики состояний);
ГОСТы и методики проведения испытаний с целью уточнения основных критериев надежности оборудования и программного обеспечения； математическую модель надежности ГПС, учитывающую надежность аппаратных, программных, механических и человеческих компонентов ГПС.
Требования
к разработчикам перспективных систем УЧПУ
Для разработки эффективного прикладного и базового программного обеспечения и реализации их последующего развития применительно к новым типам станков, роботов и технологических процессов разработчики УЧПУ и системного программного обеспечения должны предусмотреть наличие ряда функциональных возможностей, аппаратных средств и информационных материалов.
Требования к аппаратным средствам
Для надежной работы оборудования в программном обеспечении и в аппаратной защите системы от ошибок программ и оператора в УЧПУ должны содержаться средства, обеспечивающие:
программное отключение силового электропитания объекта уиравле- ния;
формирование сигналов готовности и/или неисправности оборудования;
подтверждение правильности работы программы и ЭВМ, дополненное средствами прекращения работы системы при отсутствии такого подтверждения;■
защиту памяти и процессоров от кратковременных выключений электропитания;
программный доступ к средствам защиты от несанкционированного обращения к памяти, процессорам и другим элементам оборудования системы.
Для облегчения отладки и развития программного обеспечения конструкция УЧПУ должна обеспечивать возможность:
подключения инструментальной ЭВМ с расширенным составом терминалов и внешней памятью на магнитных дисках (такая ЭВМ должна входить в комплект разрабатываемых средств УЧПУ);
аппаратного прерывания процессора при обращении к заданной группе ячеек памяти и/или при выполнении команд из заданной области памяти；
аппаратной поддержки трассирования работы программы;
использования переносного пульта для управления работой УЧПУ в процессе отладки технологического процесса.
Для расширения областей использования УЧПУ необходимо обеспечить возможность:
опроса аналоговых, импульсных, кодовых, фазовых и других типов датчиков (путем замены функциональных плат);
непосредственного управления (минуя следящий привод нижнего уровня) двигателями системы;
связи УЧПУ по последовательному и параллельному каналам с другими ЭВМ;
наращивания при. необходимости числа координат системы;
наращивания числа процессоров системы и комплексирования их в многомашинные и мультипроцессорные комплексы;
наращивания оперативной памяти и замены ее на ППЗУ после завершения отладки программного обеспечения системы;
накопления информации о суммарном времени работы УЧПУ с указанием числа включений, сбоев и времени работы в автоматическом режиме;
измерения интервалов времени с дискретностью порядка 1 мс (с помощью программно доступных часов и таймера).
Замечание. Аппаратные средства должны позволять осуществлять опрос конфигурации оборудования на системном уровне программного обеспечения.
Требования к операционной системе УЧПУ
Для снижения накладных расходов операционной системы (ОС) путем учета конкретных свойств оборудования при ер разработке необходимо предусмотреть возможность：
прямого обращения к внешним устройствам (минуя директивы ОС); изменения пользователем драйверов внешних устройств;
изменения пользователем метода синхронизации работы программных модулей системы;
доступа пользователя к сигналам неисправности оборудования на'уров- не ОС и ее внутренним регистрам и таблицам.
Для обеспечения эффективной разработки'прикладного и базового программного обеспечения в цеховых условиях в ОС должны быть обеспечены: реакция на сигналы неисправности оборудования;
сохранение файлов при частичном повреждении носителей информации;“
адаптация к неисправностям оборудования и носителей информации; телекоммуникационное управление УЧПУ;
удаленная загрузка и выгрузка содержимого ОЗУ;
запись и чтение файлов памяти УЧПУ;
удаленный запуск задач.-
Архитектура
и программное обеспечение локальных сетей для ГПС
При проектировании локальных сетей ЭВМ для ГПС целесообразно принять во внимание следующее.
Физический канал («среда передачи данных») влияет на программное обеспечение локальной сети через характеристики задержек в канале и надежности канала.
Для локальных сетей ГПС гарантируемое быстродействие канала с учетом программно-аппаратного обеспечения передачи данных должно составлять (бит/с):
для организации диалога с оператором1200
для организации режима DNC между удаленными ЭВМ и устройством управления технологическим оборудованием (1,2-н5.103) К
для связи ЭВМ в многомашинной распределенной системе управления(5十20)*103 к
Наиболее надежный алгоритм контроля правильности передачи данных определяется составом оборудования и соответствующим ему протоколом обмена. Перспективным для ГПС в пределах цеха является протокол IEEE 802. 4. Желательно иметь аппаратную реализацию не менее трех уровней этого протокола.
Архитектура сложно!т локальной сети ГПС должна предусматривать включение в ее состав специальных устройств или программ («шлюзов») для объединения разнотипных ЭВМ, имеющих различные протоколы обмена и возможность выделения подсетей со специализированным функциональным назначением.
В случае, если загрузка программами ЭВМ типа «Электроника-60» производится через одну (центральную) ЭВМ, оснащенную термпнальным оборудо- 268
ванием, возможно следующее архитектурное решение для связи ЭВМ: за жаемая ЭВМ подключается к загружающей в качестве внешнего устройства, а загружающая ЭВМ к загружаемой — через интерфейсный канал.
Там, где это необходимо, рекомендуется использовать дополнительные («буферные») процессоры для отделения функций передачи данных от комплекса аппаратно-программных средств, выполняющих прикладные процессы и для реализации программно-аппаратных средств согласования передачи данных между подсетями («мосты», «шлюзы»).
Топология и тип доступа к магистрали локальной сети ГПС могут быть следующими:
топология общей шины со случайным типом доступа (там, где нагрузка на шпну допустима с точки зрения времени задержки передачи данных);
топология шины или кольца с маркерным доступом в остальных случаях.
Первый вид более подходит для ранних этапов проектирования технологии для ГПС (системы со сквозным САПР), когда число абонентов точно не установлено, а время доступа к ним не является критическим. С точки зрения простоты программного обеспечения, эффективности и надежности обмена топология кольца предпочтительнее.
Для организации программного обеспечения локальной сети используются два подхода, которые должны дополнять друг друга:
процедурное описание сети с использованием таблиц адресов абонентов (удаленный вызов процедур);
разработка средств связывания программ в разных ЭВМ (создание языков описания локальной сети).
При этом обеспечиваются высокая эффективность программного обеспечения и простота технологии загрузки программ обмена, простота изменения и модификации программного обеспечения сети.
СОДЕРЖАНИЕ
Предисловие3
ПРОБЛЕМЫ РАЗРАБОТКИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ
Научные проблемы создания программного обеспечения робототехниче- _ ских систем 5
И. М. Макаров, Д. Е. Охоцимский, А. К. Платонов
Языковые средства разработок программного обеспечения промышлен- оп
Н. А. Смирнов, В. В. Никифоров
Концептуальная модель системы управления робототехническими комп- лексами 26
А. Н. Домарацкий
Система взаимодействия параллельных процессов в управляющих мно- гомашинных комплексах, построенных на базе микро-ЭВМ 33
А. Н. Домарацкий, А. В. Каширин, Н. Д, Проскурина
Мультипрограммные п мультипроцессорные системы управления робо- тов
А. Ф. Верещагин, А. А. Дмитриев, Т, Н. Сивашева
Организация программного обеспечения многопроцессорных систем уп- равления 47
И. П. Белякова
2 РЕАЛИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ
Программные средства для планирования процесса автоматической сборки 52
Д. Е. Охоцимский, А. К. Платонов, С. С. Камынин, С. И. Гримайло,
А. Ю. Каргашин. А. А. Кирильченко, Е. И. Кутушев
Программное обеспечение устройства контурного управления УКМ-772 для промышленных роботов 64
Н. Домарацкий, В. В. Никифоров
Программное обеспечение робота СУР-25 для дуговой сварки70
С. М. Григорович, В. И. Кавинов, А. Е. Клепов, К. В. Самвелян, И. Ю. Юрин
Система управления сварочным роботизированным комплексом с использованием микро-ЭВМ 79
Ф. Н. Кпсилевский, В. Т. Тертышный, Н. Р. Швыдкий
Программное обеспечение роботов для дуговой и электронно-лучевой сварки с прямоугольной системой координат и дискретным приводом движения 86
Ю. К. Цыганков
Программное обеспечение промышленного окрасочного робота «Колер» 96
А. П. Федосеев, В. И. Григорьев, С. А. Чевтаев, Л. В. Цуева
Система программного обеспечения роботизированного технологического комплекса 103
А. Павлов
3 СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ
Системное программное обеспечение задач робототехникп
К. Платонов, Ю. М. Лазутин, В. С. Ярошевский
Специализированная операционная система: программное обеспечение исследовательского инструментального робототехнического комплекса
Ф. Верещагин, С. Л. Зенкевич, А. В. Назарова
Программное обеспечение системы управления сварочным роботизированным комплексом
Т. Тертышпый
Проблемно-ориентированный интерпретатор для микропроцессорных систем управления движением
Т. Тертышный, Л. Н. Куца
Система взаимодействия программных модулей для многопроцессорных систем управления
И. II. Белякова, М. А. Утин
Организация программного обеспечения полунатурного моделирования роботов
И. Казьмин, А. А. Менн, А. А. Петров
Программное обеспечение системы группового управления цикловыми роботами
3. Рахманкулов, Д. В. Сатаров
4 АЛГОРИТМЫ УПРАВЛЕНИЯ РОБОТАМИ
Система управления роботом как конечный автомат 13b
Л. Зенкевич, А. В. Назарова
Синтез программных корректирующих звеньев цифровой следящей системы промышленного окрасочного робота <<Колер»164
И. Григорьев, С. А. Чевтаев
Иерархическая организация алгоритмов переработки информации при управлении сварочными роботами 173
Т. Тертышный
Программное обеспечение системы технического зрения промышленного робота 182
К. Н. Ступин
О гибкости программного обеспечения в системах управления производственными объектами 487
В. М. Гуревич, А. К. Григорян, В. Е. Вовнобой
Регулярный алгоритм прокладки маршрута мобильного робота с использованием только локальной информации 192
А. Петров, И. М. Сирота
Программн о - алгоритмическое обеспечение для анализа изображений в системах технического зрения 201
А. М. Михайлов
Моделирование роботизированного оборудования в задачах организационно-технологического управления гибкими автоматизированными производствами 210
В. А. Исаченко, В. С. Шишкин, В. Я. Полыскалин
5 СРЕДСТВА ПРОГРАММИРОВАНИЯ И МОДЕЛИРОВАНИЯ ДЛЯ РОБОТОВ И ГИБКИХ ПРОИЗВОДСТВЕННЫХ СИСТЕМ
Инструментальные средства разработки программного обеспечения гибких автоматизированных производств 216
М. В. Дудкин, А. И. Казьмин, А. А. Менн, В. Н. Пополитов
Язык для реализации алгоритмов управления в робототехнике . . . .223
Н. Е. Богомолов, 10. М. Лазутпн, В. С. Ярошевскин
Программное обеспечение системы графического программирования роботов АПРОГРАФ 238
3. Рахманкупов, С. А. Перес лени, 10. Е. Храмов
Алгоритмическое и программное обеспечение проблемно-ориентированной диалоговой системы имитационного моделирования интегрированных производственных комплексов механической обработки 247
В. Н. Войтов, С. П. Кузьмин, М. И. Ремизов, Т. В. Уханова
Стандартизация языков программирования в робототехнике258
Н. Е. Богомолов, Ю. М. Лазутин, В. С. Ярошевский
ПРИЛОЖЕНИЕ
Рекомендации для разработчиков программного обеспечения роботов и гибких автоматизированных производств 264
УДК 621.8
Макаров И. М., Охоцимский Д. Е., Платонов А. К. Научные проблемы создания программного обеспечения робототехнических систем,— В кн.: Программное обеспечение промышленных роботов М.: Наука, 1986.
Программирование роботов отличается от программирования вычислительных машин более слабой определенностью состояния внешней среды, робота и операционной обстановки. Это приводит к необходимости создания специальной системы программирования роботов, способной парировать неопределенности работы оборудования в режиме реального времени с сохранением возможности детерминированного обучения робота. В статье приводится анализ научных проблем, связанных с созданием систем программирования роботов.
Библиогр. 23 назв.
УДК 621.8
Смирнов Н. А., Никифоров В. В. Языковые средства разработок программного обеспечения промышленных роботов.一 В кнл Программное обеспечение промышленных роботов. М.: Наука, 1986.
Дан анализ текущего состояния работ по программному обеспечению для серийно выпускаемых промышленных роботов — приведен состав основных функций, реализуемых действующими и разрабатываемыми вариантами программного обеспечения, рассмотрен достигнутый уровень технологии программирования. Сформулированы требования к перспективным разработкам программного обеспечения для промышленных роботов, составу инструментальных средств и технологии разработки программного обеспечения.
Табл. 2.
УДК 621.8
Домарацкий А. Н. Концептуальная модель системы управления робототехническими комплексами.— в кн.: Программное обеспечение промышленных роботов. М.: Наука, 1986.
Анализ содержания задач управления робототехническими комплексами позволяет выделить функциональную и системную части программного обеспечения и построить концептуальную модель их взаимодействия. Построенная модель является конструктивным средством декомпозиции задач управления роботов и формирования требований к элементной базе робототехнических систем.
Ил. I. Виблиогр. 5 назв.
УДК 681.32
Домарацкий А. Н., Каширин А. В., Проскурина Н. Д. Система взаимодействия параллельных процессов в управляющих многомашинных комплексах, построенных на базе микро-ЭВМ.— В кн.: Программное обеспечение промышленных роботов. М.: Наука, 1986.
В статье описываются разработанные средства организации параллельной работы системы управления роботов, содержащей несколько процессоров. Обсуждаются методы синхронизации параллельных процессов, протекающих в разных процессорах, и проблемы организации обмена данными между ними.
Ил. 7. Библиогр. 10 назв.
УДК 681.32
Верещагин А. Ф., Дмитриев А. А., Сивашева Т. Н. Мультипрограммные и мультипроцессорные системы управления роботов.— В кн.： Программное обеспечение промышленных роботов. М.: Наука, 1986.
Обсуждается проблема создания специализированных операционных систем реального времени для обеспечения работы микропроцессорных систем управления роботов. Описывается экспериментальная система для ЭВМ «Электрони- ка-60», решающая задачу приоритетного обслуживания ло 256 параллельно работающих программ и занимающая 450 слов памяти. Рассматриваются также двухпроцессорный комплекс, предназначенный для управления робототехнической системой, и пути создания его системного программного обеспечения.
Ил. 4.
УДК 681.32.
Белякова И. П. Организация программного обеспечения многопроцессорных систем управления.— В кн.: Программное обеспечение промышленных роботов. М.: Наука, 1986.
Обсуждается проблема создания программного обеспечения многопроцессорных систем. Описываются требования, которым оно должно удовлетворять. Ана-
АКАДЕМИЯ НАУК СССР
НАУЧНЫЙ СОВЕТ ПО ПРОБЛЕМЕ
«РЭБОТОТЕХНИКА
и АВТОМАТИЗИРОВАННОЕ
ПРОИЗВОДСТВО»
РОБОТОТЕХНИКА
И ГИБКИЕ
ПРОИЗВОДСТВЕННЫЕ
СИСТЕМЫ
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРОМЫШЛЕННЫХ РОБОТОВ
Ответственный редактор доктор физико-математических Н&ук А. К. ПЛАТОНОВ
Составители:
кандидат Технических наук
Н. ДОМАРАЦКИЙ
кандидат физико-математических наук
Р. К. КАЗАКОВА
МОСКВА «НАУКА»
1986
Статьи сборника посвящены научным проблемам создания алгоритмического и программного обеспечения и описанию опыта разработки конкретных прикладных и системных программных комплексов для промышленных роботов и их устройств управления. В сборник включены статьи авторов из ведущих коллективов АН СССР, высшей школы и промышленности в области разработки программного обеспечения роботов.
Для специалистов в областиДля специалистов в областиробототехники и смежных отраслей.
Для специалистов в области
Для специалистов в области
Редакционная коллегия серии:И. М. МАКАРОВ член-корреспондент АН СССР, главный редакторД. Е. ОХОЦИМСКИЙ член-корреспондент АН СССР, зам. главного редактораЕ. П. ПОПОВ член-корреспондент АН СССР, зам. главного редактораП. Н. БЕЛЯНИН член-корреспондеят АН СССР А. А. ВОРОНОВ академикЕ. А. ДЕВЯНИН доктор физико-математических наук С. В. ЕМЕЛЬЯНОВ академикЮ. ИШЛИНСКИЙ академик , В. В. КЛЮЕВ доктор технических иаук Ю. Г. КОЗЫРЕВ кандидат технических наукРедакционная коллегия серии:И. М. МАКАРОВ член-корреспондент АН СССР, главный редакторД. Е. ОХОЦИМСКИЙ член-корреспондент АН СССР, зам. главного редактораЕ. П. ПОПОВ член-корреспондент АН СССР, зам. главного редактораП. Н. БЕЛЯНИН член-корреспондеят АН СССР А. А. ВОРОНОВ академикЕ. А. ДЕВЯНИН доктор физико-математических наук С. В. ЕМЕЛЬЯНОВ академикЮ. ИШЛИНСКИЙ академик , В. В. КЛЮЕВ доктор технических иаук Ю. Г. КОЗЫРЕВ кандидат технических наукС. КУЛЕШОВ доктор технических наук Н. А. ЛАКОТА доктор технических наук Л. В. ЛОБИКОВБ. Н. НАУМОВ академикК. ПЛАТОНОВ доктор физико-математических наук В. Н. ПОНОМАРЕВ доктор технических наук В. 3. РАХМАНКУЛОВ кандидат технических наук, ответственный секретарь Ю. М. СОЛОМЕНЦЕВ доктор технических наук К. В. ФРОЛОВ академикЯ. А. ШИФРИНС. ЯСТРЕБОВ доктор технических наукС. КУЛЕШОВ доктор технических наук Н. А. ЛАКОТА доктор технических наук Л. В. ЛОБИКОВБ. Н. НАУМОВ академикК. ПЛАТОНОВ доктор физико-математических наук В. Н. ПОНОМАРЕВ доктор технических наук В. 3. РАХМАНКУЛОВ кандидат технических наук, ответственный секретарь Ю. М. СОЛОМЕНЦЕВ доктор технических наук К. В. ФРОЛОВ академикЯ. А. ШИФРИНС. ЯСТРЕБОВ доктор технических наук
Редакционная коллегия серии:
И. М. МАКАРОВ член-корреспондент АН СССР, главный редактор
Д. Е. ОХОЦИМСКИЙ член-корреспондент АН СССР, зам. главного редактора
Е. П. ПОПОВ член-корреспондент АН СССР, зам. главного редактора
П. Н. БЕЛЯНИН член-корреспондеят АН СССР А. А. ВОРОНОВ академик
Е. А. ДЕВЯНИН доктор физико-математических наук С. В. ЕМЕЛЬЯНОВ академик
Ю. ИШЛИНСКИЙ академик , В. В. КЛЮЕВ доктор технических иаук Ю. Г. КОЗЫРЕВ кандидат технических наук
Редакционная коллегия серии:
И. М. МАКАРОВ член-корреспондент АН СССР, главный редактор
Д. Е. ОХОЦИМСКИЙ член-корреспондент АН СССР, зам. главного редактора
Е. П. ПОПОВ член-корреспондент АН СССР, зам. главного редактора
П. Н. БЕЛЯНИН член-корреспондеят АН СССР А. А. ВОРОНОВ академик
Е. А. ДЕВЯНИН доктор физико-математических наук С. В. ЕМЕЛЬЯНОВ академик
Ю. ИШЛИНСКИЙ академик , В. В. КЛЮЕВ доктор технических иаук Ю. Г. КОЗЫРЕВ кандидат технических наук
С. КУЛЕШОВ доктор технических наук Н. А. ЛАКОТА доктор технических наук Л. В. ЛОБИКОВ
Б. Н. НАУМОВ академик
К. ПЛАТОНОВ доктор физико-математических наук В. Н. ПОНОМАРЕВ доктор технических наук В. 3. РАХМАНКУЛОВ кандидат технических наук, ответственный секретарь Ю. М. СОЛОМЕНЦЕВ доктор технических наук К. В. ФРОЛОВ академик
Я. А. ШИФРИН
С. ЯСТРЕБОВ доктор технических наук
С. КУЛЕШОВ доктор технических наук Н. А. ЛАКОТА доктор технических наук Л. В. ЛОБИКОВ
Б. Н. НАУМОВ академик
К. ПЛАТОНОВ доктор физико-математических наук В. Н. ПОНОМАРЕВ доктор технических наук В. 3. РАХМАНКУЛОВ кандидат технических наук, ответственный секретарь Ю. М. СОЛОМЕНЦЕВ доктор технических наук К. В. ФРОЛОВ академик
Я. А. ШИФРИН
С. ЯСТРЕБОВ доктор технических наук
Рецензенты:
С. ГОРБАЧЕВ, В. А. САРЫЧЕВ
祁 7^0706-5 '
П1502000000-322 —--
—042(02)У6 122-86-111 1 ^^^д7р^^Из1ательство «Наука», 1986 г.