АКАДЕМИЯ НАУК СССР

НАУЧНЫЙ СОВЕТ ПО ПРОБЛЕМЕ

«РОБОТОТЕХНИКА

И АВТОМАТИЗИРОВАННОЕ

ПРОИЗВОДСТВО»

РОБОТОТЕХНИКА

И ГИБКИЕ

ПРОИЗВОДСТВЕННЫЕ

СИСТЕМЫ

ПРОГРАММНОЕ
ОБЕСПЕЧЕНИЕ
ПРОМЫШЛЕННЫХ
РОБОТОВ

Ответственный редактор
доктор физико-математических наук
А. К. ПЛАТОНОВ

Составители:

кандидат технических наук

А. Н. ДОМАРАЦКИЙ

кандидат физико-математических наук

Р. К. КАЗАКОВА

МОСКВА
«НАУКА»
1986
УДК GS4.fr

/7УГ

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

конкретных прикладных и системных программных комплексов для
промышленных роботов и их устройств управления. В сборник включе-
ны статьи авторов из ведущих коллективов АН СССР, высшей школы и
промышленности в области разработки программного обеспечения ро-
ботов.

Для специалистов в области робототехники и смежных отраслей.

Редакционная коллегия серии:

И. М. МАКАРОВ
член-корреспондент АН СССР,
главный редактор

Д. Е. ОХОЦИМСКИЙ
член-корреспондент АН СССР,
зам. главного редактора

Е. И. ПОПОВ
член-корреспондент АН СССР,
зам. главного редактора

П. Н. БЕЛЯНИН
член-корреспондент АН СССР

А. А. ВОРОНОВ
академик

Е. А. ДЕВЯНИН
доктор
физико-математических наук
С. В. ЕМЕЛЬЯНОВ
академик

А. Ю. ИШЛИНСКИЙ
академик ,

В. В. КЛЮЕВ
доктор технических иаук
Ю. Г. КОЗЫРЕВ
кандидат технических иаук

В. С. КУЛЕШОВ
доктор технических наук
Н. А. ЛАКОТА
доктор технических наук
Л. В. ЛОБИКОВ

Б. Н. НАУМОВ
академик

А. К. ПЛАТОНОВ
доктор
физико-математических наук
В. Н. ПОНОМАРЕВ
доктор технических наук
В. 3. РАХМАНКУЛОВ
кандидат технических наук,
ответственный секретарь
Ю. М. СОЛОМЕНЦЕВ
доктор технических наук
К. В. ФРОЛОВ
академик

Я. А. ШИФРИН

В. С. ЯСТРЕБОВ
доктор технических наук

Рецензенты:

В. С. ГОРБАЧЕВ, В. А. САРЫЧЕВ

НИ 740706-fr

1502000000-322
042(02)-86

- 122-86-Ш

"вентральная Гв?0Д<^4ательство *НаУка»>1986 г-
Лубк4«-ная Библиотеке

Мм» Н А. НЕКРАСОВА ,
ПРЕДИСЛОВИЕ

Успешное решетите поставленных XXVII съездомГтПСС за дач авто-
матизации производственных процессов зависит от своевременного
создания программного обеспечения разрабатываемых промышлен-
ностью автоматических систем на базе микро-ЭВМ. Значимость
программного обеспечения в настоящее время определяется сле-
дующими факторами:

требованиями гибкости и простоты переналаживаемости автома-
тизированного производства при изменении объема или номенкла-
туры выпускаемой продукции, а также при изменении конфигура-
ции оборудования;

архитектурой вычислительных управляющих устройств и тер-
минального оборудования, используемых в составе систем управле-
ния автоматических производств, предполагающих обязательное на-
личие программных средств для объединения элементов оборудова-
ния в единую систему;

использованием микропроцессорной элементной базы, требующей
разработки микропрограмм и программ для формирования необхо-
димых функциональных характеристик;

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

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

Настоящий сборник подготовлен Рабочей группой по программ-
ному обеспечению роботов Научного совета АН СССР по пробле-
ме «Робототехника и автоматизированное производство». Цель сбор-
ника — ознакомить широкий круг читателей с разработками в обла-
сти программного обеспечения роботов. Статьи сборника написаны
ведущими специалистами в этой области, принимающими непосред-
ственное участие в создании робототехнических систем.

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

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

В ряде статей сборника отражен опыт эксплуатации специали-
зированных операционных систем для управления и обучения робо-
тов. Большое внимание уделено проблемам, возникающим в процес-
се организации и создания программного обеспечения роботизиро-
ванных комплексов для полунатурного моделирования.
ПРОБЛЕМЫ РАЗРАБОТКИ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ

УДК 621.8

НАУЧНЫЕ ПРОБЛЕМЫ

СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
РОБОТОТЕХНИЧЕСКИХ СИСТЕМ

И. М. Макаров, Д. Е. Охоцимский, А. К. Платонов

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

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

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

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

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

Важным обстоятельством, оказывающим большое влияние на
программное обеспечение роботов и сроки его разработки, является
наблюдаемое противоречие между требованиями режима реального
времени и стоимостью системы управления, приводящее к сравни-
тельно большому разнообразию технических средств и архитектур
управляющих вычислительных систем. Традиционно системы управ-
ления делятся на цикловые, позиционные и контурные; датчики ин-
формации — на аналоговые и дискретные разных типов; привод —
на следящий и шаговый; кинематические схемы роботов — на орто-
гональные, цилиндрические, сферические и антропоморфные. В свя-
зи с этим существенное сокращение стоимости и сроков разработки
программного обеспечения подобных роботов достижимо только пу-
тем придания ему свойства «транспортабельности» — возможности
адаптации к системе управления робота другого типа без значи-
тельной переделки. При этом следует иметь в виду различие ха-
рактеристик и ресурсов оборудования применяемых систем управ-
ления и роботов (разрядность и быстродействие преобразователей
сигналов, быстродействие управляющей ЭВМ, объем ее памяти,
наличие внешней памяти, арифметического и тригонометрического
расширителя системы команд процессора, вид кинематической
схемы робота и т. д.).

Имеется еще одно обстоятельство, отличающее от программного
обеспечения вычислительных машин программное обеспечение ро-
ботов — его незамкнутость. В условиях современного производства
робот представляет собой единицу оборудования в составе произ-
водственного участка или при более высоком уровне автоматиза-
ции — в составе гибкой производственной системы. Поэтому про-
граммное обеспечение робота должно в процессе работы взаимодей-
ствовать с другими программными системами: числового программ-
ного управления (ЧПУ) обслуживаемых станков; автоматизиро-
ванной системы управления (АСУ) и системы автоматизированного
проектирования (САПР) технологических процессов (ТП) и АСУ
производством. Соглашения о связях при подобном взаимодействии
весьма разнородны, поэтому к системе управления робота предъяв-
ляются требования определенной гибкости интерфейса с внешними
системами.

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

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

Рассмотрим более подробно научное содержание проблем созда-
ния программного и алгоритмического обеспечения роботов.

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ

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

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

другой стороны, требования простоты системы управления
робота и ее низкой стоимости приводят к ограниченным объемам
оперативной и внешней памяти устройств управления роботов по
сравнению с вычислительными системами. В связи с этим не менее
остро стоит проблема оптимизации суммарного объема программно-
го обеспечения робота и объема резидентных программ с учетом
разделения на переменную и постоянную части.
Многокритериальный характер оптимизационной задачи порож-
дает известные трудности ее решения и требует разработки спе-
циальных методов оптимизации [1, 2]. Эффективными отечествен-
ными средствами здесь являются оптимизирующий транслятор
ФОРЕКС [3] и языки Астра [4] и МЭЛ [5].

Распределение или централизация функций? Все функции про-
граммного обеспечения (прием и передача сигналов, вычисления и
выбор альтернатив) могут быть в наиболее общем виде описаны
как процессы обработки информации, обладающие двумя характе-
ристиками: временем исполнения и локализацией. При проектиро-
вании программного обеспечения имеется некоторая свобода варьи-
рования состава процессов, их быстродействия и способов взаи-
модействия, дающая возможность оптимизации критериев качества
программного обеспечения. Вместе с тем всегда можно выделить
«нулевой» уровень описания проблемы управления роботом с учетом
имеющейся конфигурации технических средств, на котором состав
и структура процессов фиксированы. Это исходное описание про-
цессов не содержит указания на способы организации их взаимодей-
ствия и синхронизации. На нулевом уровне описания нет также
информации о распределении исходных процессов по процессорам
многопроцессорной системы управления робота.

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

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

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

расходов и затрат памяти в этих системах позволяет получить
необходимые данные для построения формальных методов опреде-
ления оптимальной степени децентрализации системы [6, 7].

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

Проблема выбора оптимального соотношения времени исполне- \
ния программы и объема занимаемой ею памяти при создании про- )
граммного обеспечения роботов стоит особенно остро из-за малой
мощности применяемых ЭВМ и большой вычислительной сложности
решаемых задач (высокая требуемая относительная точность дви-
жения, большое число степеней подвижности робота, сложность его
кинематической схемы, требования работы в режиме реального вре-
мени и т. п.). В связи с этим необходима разработка специализи-
рованных библиотек стандартных программ робототехники, приспо-
собленных для эффективного решения задач кинематики и динамики
роботов. При этом следует учитывать известные для этих роботов
диапазоны изменения обобщенных координат, допустимые точности
вычисления тригонометрических функций и возможность проведения
предварительных вычислений в процессе обучения робота [8, 9].

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

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

процессы доступа могут занимать большое время и рассмотренная
выше проблема «процесс или память?» превращается в проблему
«процесс вычислений или процесс обращения к памяти?», решение
которой зависит от принятого способа организации работы с па-
мятью ЭВМ [10]. Как известно, имеются два аспекта этой пробле-
мы: доступ к данным (распределение памяти, «уборка мусора»,
выбор оптимальной функции адресации и т. п.) и организация
обмена данными между программными модулями (формальные па-
раметры, «common-блоки», data flow и т. п.).

Способы решения возникающих вопросов тесно связаны с осо-
бенностями средств, предоставляемых файловой системой, макроге-
нератором и трансляторами инструментальной системы програм-
мирования, видом внешней памяти устройства управления и воз-
можностями организации баз и банков данных с абстрактными
типами данных, реализации идей «отложенной трансляции» акаде-
мика Л. П. Ершова и создания универсальных средств генерации
версий программного обеспечения. Недостатки принятых способов
организации работы с памятью, как правило, становятся очевид-
ными только на поздней стадии создания программного обеспече-
ния или позже —в процессе его развития. Изменение принятого
способа организации работы с памятью означает коренную перера-
ботку всех программ. Поэтому формулирование научно обоснован-
ных рекомендаций и соответствующих программных средств имеет
большое значение.

Проблемы организации памяти важны и с точки зрения стан-
дартизации программного обеспечения. Быстрое совершенствование
и развитие вычислительной техники и средств программирования,
так же как и возникновение новых производственных систем, дела-
ют несостоятельными попытки стандартизовать непосредственно
структуру данных программного обеспечения производства. Для
примера достаточно сравнить различающиеся структуры данных
устройств ЧПУ для металлообработки, устройств управления робо-
тов, роботизированных технологических участков, систем САПР-
АСУ ТП и гибких производственных систем. Хотя все эти системы
принципиально могут быть реализованы на однотипных ЭВМ с од-
ним и тем же базовым программным обеспечением и структурой
данных, этого не произошло ввиду их создания в разное время.
И, безусловно, здесь крайне полезным явился бы стандарт, описы-
вающий не саму структуру данных, а методы организации памяти
и язык для определения используемой структуры данных.

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

. Язык или языки? Ответим сразу: языки и язык. Программное
i обеспечение роботов представляет собою сложную многоуровневую
систему средств, элементы которой отличаются как по областям
применений роботов, так и по стадиям использования программ в
; процессе подготовки производства. Языковая поддержка этих

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

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

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

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

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

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

Анализ проблемы и опыт разработки системного программного
обеспечения робототехники говорят о необходимости использования
специального базового языка программирования и транслятора с
загрузчиком, позволяющих эффективно создавать трансляторы для
языков программирования роботов, обладающие описанными выше
свойствами. Наличие такого базового языка облегчает стандарти-
зацию и унификацию программного обеспечения и, главное, резко
снижает трудозатраты при создании программ обработки сигналов
от оборудования робота и при распределении параллельных процес-
сов по процессорам многомашинного комплекса. В настоящее время
версия такого отечественного языка прошла опытную эксплуатацию
ira машинах М-6000, СМ-2, СМ-4 и «Электропика-60» с их опера-
ционными системами [5]. Перспективы для использования в каче-
стве базового языка робототехники имеют также язык «С» в опера-
ционной системе «UNIX» и язык Паскаль.	.

Таким образом, для решения проблемы языковой поддержки
программного обеспечения роботов необходима разработка:

проблемно-ориентированных языков программирования роботов'
в виде совокупностей типов данных и операторов, адекватных со-
держанию технологических задач;

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

Транспортабельность программного обеспечения. Решение упомя-
нутой проблемы транспортабельности систем упирается в построе-
ние оптимальной архитектуры программного обеспечения (анало-
гично. архитектуре ЭВМ — особенностям ее устройства, влияющим
на системное программное обеспечение, архитектура программного
обеспечения — особенности системного программного обеспечения,
влияющие на облик прикладных программ). Трудность задачи в
отсутствии достаточного опыта создания систем управления робо-
тов для различных видов производственных процессов и, как было
отмечено выше, в значительной вариативности конфигураций изве-
стных систем. Роботы даже с одинаковым функциональным назна-
чением могут различаться: по составу позиционных датчиков (ко-
довые, импульсные, потенциометрические), силомоментных (прово-
лочные, полупроводниковые), фотометрических (фоторезисторы,
фотодиоды, видикон, прибор зарядовой связи), локационных (опти-
ческие, ультразвуковые) и т. п.; по виду привода (электропривод
постоянного или переменного тока, шаговые двигатели, электрогид-
ропривод, пневмопривод); по виду внешней памяти (перфолента, .
кассетный магнитофон, магнитная лента на бобинах, магнитные дис-
ки); по числу процессоров (один—десять). Однако нет уверенности,
что этот список обладает необходимой полнотой и что приведенная
совокупность вариантов оборудования взаимно однозначно отобра-
жается на совокупность программных средств.

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

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

Важной проблемой является выбор правильного метода работы
с библиотекой. С точки зрения скорости программирования наиболее
простыми являются библиотеки стандартных программ в виде мо-
дулей загрузки, позволяющие статически (до начала работы про-
гами) или динамически (в процессе работы) загружать в память
требуемые стандартные программы и передавать им управление по
мере необходимости. Как показал опыт разработки алгоритмов уп-
равления движением робототехнических систем, накопленный в Ин-
ституте прикладной математики им. М. В. Келдыша АН СССР,
подобный метод весьма эффективен при отработке функциональной
структуры и состава программного обеспечения робота, когда требо-
вания экономии ресурсов используемой ЭВМ не являются опреде-
ляющими.

На заключительной стадии создания программного обеспечения
более рационально использование библиотеки макроопределений и
средств макрогенерации, позволяющих экономить ресурсы ЭВМ.
В настоящее время опыт разработки подобной библиотеки накап-
ливается на базе макросредств системы РАФОС. Анализ этого опыта
позволит оценить эффективность существующих средств макропро-
граммирования и выработать рекомендации для разработки новых
макрогенераторов. Однако уже и сегодня очевидны требования к
подобной системе, связанные с необходимостью многократных вы-
ходов на машину в процессе макрогенерации, трансляции и загруз-
ки программ [11, 12].

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

Разработка каких-либо стандартов в этой области, регламенти-
рующих творческую деятельность программиста, при создании кон-
кретной робототехнической системы исключительно трудна. Тенден-
ция развития в настоящее время — создание генератора операцион-
ных систем с их заданными свойствами и соглашениями о связях
с драйверами оборудования и проблемно-ориентированными про-
граммными модулями. Входной язык такого генератора должен пред-
ставлять возможность описания специализированных операционных
систем с «усеченными» применительно к задачам робота функция-
ми, заданными дисциплиной обработки запросов, методами синхро-
низации процессов, ограничениями резидентной памяти, требования-
ми реального времени и, как это обычно делается в существующих
генераторах вычислительных операционных систем, конфигурацией
оборудования. Подобный генератор может быть представлен в виде
кросс-компилятора, объектными программами которого являются мо-
дули операционной системы в виде, приспособленном для про-
граммируемых постоянных запоминающих устройств (ППЗУ) и
для внешней памяти, а также модули трансляторов системы про-
граммирования робота, взаимодействующие с операционной систе-
мой. Устройство компилятора при этом остается известным только
системному программисту и не влияет на деятельность программи-
ста прикладного. Заметим, что в настоящее время устройство опе-
рационной системы, разрабатываемой системным программистом,
часто влияет на деятельность прикладного программиста. Это об-
стоятельство и является основной причиной попыток изменения
уровня доступности системных программ.

Описанный подход к оптимальной организации доступа приклад-
ного программиста к системным средствам исследовался в Инсти-
туте прикладной математики им. М. В. Келдыша АН СССР в про-
цессе создания транслятора базового языка МЭЛ [5].

АЛГОРИТМИЧЕСКОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ

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

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

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

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

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

Парирование аппаратных неопределенностей алгоритмическим
путем порождает проблему логической обработки неточных данных,
описываемых неопределенными множествами [14]. Подобная обра-
ботка, учитывающая специфику выполняемых роботом движений,
заключается в реализации трех процессов: контроля правильности
сигналов обратной связи, уточнения неопределенной ситуации и
формирования реакции на ситуацию. Последняя функция специ-
фична именно для робототехнической системы в отличие от вычис-
лительных систем, в которых активное взаимодействие с внешней
средой (системами ввода—вывода) существенно беднее.

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

Реализация подобной системы приводит к необходимости разра-
ботки алгоритмов следящих цифровых систем для использования их
в драйверах робота [15] и алгоритмов детектирования операцион-
ной обстановки путем программируемой логической фильтрации сиг-
налов от датчиков информации [16]. Подчеркнем, что на уровне
драйверов речь идет именно об алгоритмах детектирования ситуа-
ции, а не о процессах распознавания образов в классическом
смысле.

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

Первая проблема связана с противоречием между требованиями
подробности алфавита функциональных команд и его укрупнения в
супервизорном режиме (исходя из упрощения деятельности опера-
тора). Решение основывается на анализе задач управления движе-
нием и строгом соблюдении основного принципа программирования:
«все независимое — раздельно, все зависимое — вместе». Имеющий-
ся опыт создания супервизорных систем управления [18, 19] пока-
зывает, что лучше иметь избыточность функциональных средств,
чем их связанность, которая может привести к выполнению'ненуж-
ных действий.

Вторая проблема возникает в связи с неопределенностью буду-
щих команд оператора и их возможным «неудобством» для систе-
мы управления. В полностью автоматической системе активность
робота разворачивается в зависимости от операционной обстановки
по плану, сформированному заблаговременно и наилучшим образом
соответствующим заданным целям движения. В супервизорной
системе оператор может выдать команду, несогласованную с теку-
щим состоянием системы управления робота. Поэтому степень
управляемости супервизорного робота в общем случае ниже авто-
матического — за внезапность команд приходится «платить». Умень-
шение нежелательных последствий внезапных команд, как показал
опыт создания системы супервизорного управления шагающей ма-
шиной, управляемой водителем [18], возможно тремя способами:
разработкой алгоритмов управления движением, расширяющих
область достижимости в каждой текущей точке фазового простран-
ства состояний робота;

разработкой для оператора средств индикации текущей области
достижимости или границ области управляемости в пространстве
управляющих команд;

разделением команды оператора на предварительную (задающую
тенденцию управления) и исполнительную (формирующую движе-
ние в обозначенной предварительной командой области).

Режимы обучения. Эта группа проблем создания алгоритмическо-
го обеспечения роботов связана с режимами программирования их
работы. Супервизорный режим был рассмотрен выше с точки зре-
ния его внутреннего содержания. Внешняя сторона этого режима —
интерфейс с человеком. Наиболее популярный способ супервизор-
ного управления — использование управляющих рукояток [20]. Ме-
нее традиционным является использование алфавитно-цифровых
или графических дисплеев, хотя в современных системах ЧПУ и
гибких автоматизированных производств (ГАП) они находят до-
вольно широкое применение даже в условиях цеха. В таких случаях
необходима разработка специальных языков программирования ра-
боты и проблема заключается в обеспечении полноты и удобства
использования принятого состава операторов и типов данных.
В частности, язык описания плана сборочных операций двурукого
сборочного робота ориентирован на использование алфавитно-циф-
рового дисплея. Этот язык рассматривается в публикации [21]. Он
обладает небольшим (около десяти) набором операторов и позво-
ляет на естественном языке описывать три графа: план сборки, пла-
ны сборочных операций и планы проверки условий выполнения
сборочных операций [22].

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

Отдельной алгоритмической проблемой является коррекция про-
граммы работы робота в связи с изменением начальной установки
детали или изменения рабочих органов робота (износ, смещение
и т. п.). С этой целью в процессе обучения должны быть запро-
граммированы контрольные движения со специальными свойствами
(фиксированное направление поиска детали, колебания, сканирова-
ние и т. п.). Алгоритмы установочной адаптации и предоперацион-
ной коррекции управляющих программ особенно важны в условиях
ГАП. Главными проблемами в этом случае являются обеспечение
надежности и быстродействия этих алгоритмов. Пример одного из
алгоритмов установочной адаптации сварочных роботов приведен в
публикации [23].

* * *

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

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

Ведется также разработка ряда перспективных робототехниче-
ских систем и их программного обеспечения.
ЛИТЕРАТУРА

I.	Рау О. И. Модель виртуальной машины как база оптимизации программ.—
В кн.: Вопросы системного программирования. М.: Изд-во МГУ, 1978,
с. 75—89.

2.	Соболь И. М., Статников Р. Б. Выбор оптимальных параметров в задачах
со многими критериями. М.: Наука, 1981. 110 с.

3.	Штаркман В. С. Локальная оптимизация объектной программы в тран-
сляторе ФОРЕКС: Препр. Ин-та прикл. математики им. М. В. Келдыша
АН СССР А» 149. М., 1979. 28 с.

4.	Михелев В. М., Вершубский В. Ю. АСТРА: язык для записи алгоритмов
системного программирования и трансляции; Препр. Ин-та прикл. мате-
матики им. М. В. Келдыша АН СССР № 16. М., 1974. 66 с.

5.	Платонов А. К., Лазутин Ю. М., Ярошевский В. С. Системное программное
обеспечение задач робототехники,— В кн.: Тр. 2-й Междунар, конф, по
искусственному интеллекту и информационно-управляющим системам ро-
ботов, окт. 1982. г. Смоленице, ЧССР. Братислава: ИТК САН, 1982, с. 192—
195.

6.	Платонов А. К., Боровик Г. К., Дружченко В. Е., Чиганов В. А., Никифо-
ров В. В. Исследование структуры системы управления робота для дуго-
вой сварки.— В кн.: Исследование робототехнических систем. М.: Наука,
1982, с. 51-65.

7.	Пономарев В. М., Домарацкий А. И., Никифоров В. В. Система алгоритми-
ческих модулей управления роботами — АМУР-80: Препр. ЛНИВЦ АН СССР
№ 20. Л., 1981. 50 с.

8.	Гримайло С. И., Каргашин А. Ю., Платонов А. К., Яшкичев И. В. Исследо-
вание кинематики и точностных характеристик промышленного робота
Универсал-15: Препр. Ин-та прикл. математики им. М. В. Келдыша АП
СССР № 38. М„ 1982. 27 с.

9.	Гримайло С. И. Система программирования и исполнения движения ма-
нипулятора, управляемого от ЭВМ: Препр. Ин-та прикл, математики им.
М. В. Келдыша АН СССР № 104. М.. 1981. 28 с.

10.	Илюшин А. И., Щенков И. В. УПД-6: Использование средств управления
данными в ФОРТРАНе. М.: Ин-т прикл. математики им. М. В. Келдыша
АН СССР, 1976. 83 с.

11.	Марченко Н. А., Михеле в В. М. Использование микрогенераторов для уп-
равления проблемно-ориентированными пакетами программ: Препр. Ин-та
прякл. математики им. М. В. Келдыша АН СССР № 97. М., 1977. 20 с.

12.	Лазутин Ю. М., Яшкичев И. В. Система программирования микро-ЭВМ
«Электроника-60» на мини-ЭВМ М-6000: Препр. Ин-та прикл. математики
им. М. В. Келдыша АН СССР № 58. М., 1982. 21 с.

13.	Охоцимский Д. Е. Разработка очувствленных роботов.— В кн.: II Всесоюз.
совещ. по робототехническим системам, Минск, 15—19 мая 1981 г.: Тез.
докл. Минск: БЕЛНИИТИ, 1981, с. 17—18.

14.	Нариньяни А. С. Неопределенные множества — новейший тип данных для
представления знаний: Препр. ВЦ СО АН СССР № 232. Новосибирск, 1980.
26 с.

15.	Охоцимский Д. Е., Платонов А. К., Кугушев Е. И., Павловский В. Е., Яро-
шевский В. С. Мини-ЭВМ в контуре управления шагающим аппаратом.—
В кн.: Динамика управляемых систем. М.; Наука, 1979, с. 209—216.

16.	Платонов А. К., Карпов И. И. Синтез и моделирование на ЦВМ информа-
ционной системы шагающего аппарата: Препр. Ин-та прикл. математики
им. М. В. Келдыша АН СССР № 66. М., 1974. 49 с.

17.	Охоцимский Д. Е., Платонов А. К., Кугушев Е. И., Ярошевский В. С. Си-
стема построения движения шагающего аппарата. Модель Т-3: Препр.
Ин-та прикл. математики им. М. В. Келдыша АН СССР № 7. М., 1977. 62 с.

18.	Охоцимский Д. Е., Платонов А. К., Кугушев Е. И., Лазутин Ю. М., Яро-
шевский В. С. Проблемы построения и моделирования движения управляе-
мого оператором шагающего аппарата: Препр. Ин-та прикл. математики
им. М. В. Келдыша АН СССР № 125. М., 1974. 38 с.

19.	Попов Е. П., Максимов А. И., Ковальчук А. К., Шишов В. П. Универсаль-
ный аналого-цифровой комплекс для исследования робототехнических си-
стем.— В кн.: Исследование робототехнических систем. М.: Наука, 1982,
с. 5-11.

20.	Лобачев В. И., Ковальчук А. К., Кашаев Р. Ш. Система полуавтоматиче-
ского управления очувствленным манипулятором.— В кн.: Исследование
робототехнических систем. М.: Наука. 1982, с. 12—16.

21.	Охоцимский Д. Е., Платонов А. К., Камынин С. С., Тримайло С. И., Карги
шин А. Ю., Кирильченко А. А., Кугушев Е. И. Программные средства для
планирования процесса автоматической сборки.— Наст. сб.

22.	Охоцимский Д. Е., Платонов А. К., Смольянов Ю. П., Гримайло С. И., Ка-
мынин С. С., Кугушев Е. И. Исследование многооперационной сборки с
помощью экспериментальной робототехнической системы.— В кн.: Робо-
тизация сборочных процессов. М.: Наука, 1985, с. 61—88.

23.	Цыганков Ю. К. Один из подходов к трактовке искусственного интеллек-
та в системах управления сварочным роботом.— В кн.: Робототехнические
системы в отраслях народного хозяйства: Тез. докл. II Всесоюз. совещ. по
робототехническим системам, Минск, 15—19 мая 1981 г. Минск: БЕЛНИИТИ,
1981, с. 94-95.

УДК 621.8

ЯЗЫКОВЫЕ СРЕДСТВА

РАЗРАБОТОК ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ПРОМЫШЛЕННЫХ РОБОТОВ

Н. А. Смирнов, В. В. Никифоров

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

Элементы программного обеспечения существенно различаются
по характеру разработки и использования. Принято выделять:
функциональное программное обеспечение;

комплект управляющих программ;

тесты;

инструментальное программное обеспечение.

Функциональное программное обеспечение состоит из програм-,
мных модулей и формируемых (компонуемых) на их основе вари-'
антов (версий) систем. Конкретный вариант системы функциональ-
ного программного обеспечения обеспечивает функционирование
управляющих устройств и промышленного робота в целом в составе
робототехнического комплекса определенной конфигурации (кон-
кретные типы исполнительных механизмов робота, обслуживаемого
технологического оборудования, определенный характер организации
технологического участка и всего роботизированного производ-
ства) .

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

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

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

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

Важный класс языковых средств составляют диалоговые языки.
Определение синтаксиса диалогового языка регламентирует состав
возможностей (возможных форм) интерактивного процесса инфор-
мационного взаимодействия (взаимодействия человека-оператора с
управляющим устройством); определение семантики форм диалого-
вого языка означает задание смысловых значении отдельных инфор-
мационных посылок (и отдельных элементов этих посылок) в кон-
тексте предыстории интерактивного процесса.

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

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

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

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

Одной из актуальных задач перспективных разработок программ-
ного обеспечения для промышленных роботов является расширение
состава возможностей резидентного инструментального программно-
го обеспечения, включающее:
Функция	Особенности реализации
Взаимодействие  с человеком-оператором	Использование универсальной клавиатуры, дис- плеев, специальных пультов
с управляемыми меха- низмами  с технологическим про- цессом	Шаговый привод, следящий привод (по скорости и положению)  Ввод — вывод последовательности технологиче- ских параметров и сигналов в ходе выполнения операторов последовательной управляющей про- граммы
Ручное управление	Кнопочное: обеспечение движения рабочего ор- гана промышленного робота с постоянной ско- ростью вдоль (вокруг) выбранной оси
Редактирование управляю- щих программ  Хранение управляющих программ и доступ к ним	Посимвольное, форматное  Хранение на перфоленте и кассетных магнитных лентах; ввод (вывод) с магнитной ленты (на магнитную ленту) в рамках специального режи- ма работы устройства управления , (режима об- мена) ; ввод с перфоленты непосредственно в ходе исполнения
Исполнение управляющих программ	Покадровое, однократное, многократное, с авто- матической настройкой на воспроизведение (ис- полнение) требуемой управляющей программы
•	(выбирается из имеющегося в оперативном запо- минающем устройстве комплекта)
Интерполяция  Учет значений корректи- рующих параметров	Линейная, круговая (в избранных плоскостях)  Коррекция воспроизводимой траектории по дан- ным, вводимым в устройство до начала исполне- ния управляющей программы
Измерение (уточнение значений) корректирующих параметров	В рамках специального режима автоматического измерения параметров положения заготовок с автоматической модификацией параметров кор- рекции управляющей программы

разработку средств реализации принципиально новых эффектив-
ных методов обучения (формирования управляющих программ);

определение и реализацию универсальных принципов автомати-
ческой настройки модулей функционального программного обеспече-
ния на работу с конкретной конфигурацией технологического
оборудования (привязка к технологии);

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

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

К задачам ручного управления непосредственно примыкают за-
дачи расширения возможностей влияния человека-оператора на ход
исполнения управляющих программ (супервизорное управление
процессом их исполнения).

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

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

Проблемы развития программного обеспечения для промышлен-
ных роботов неразрывно связаны с созданием и усовершенствова-
нием соответствующих языковых средств (табл. 2).

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

Представление управляющей
программы

Разработка общей структуры
сигнальных связей между эле-
ментами и блоками програм-
много обеспечения

Разработка алгоритмов функ-
ционирования блоков и систем
программного обеспечения

Информационный обмен меж-
ду блоками системы програм-
много обеспечения

Управление процессом форми-
рования управляющей про-
граммы (например, в режиме
обучения)

Ручное управление промыш-
ленными роботами и робото-
техническими комплексами

Описание условий взаимодей-
ствия промышленных роботов
с технологическим оборудова-
нием

Описание особенностей конст-
рукции и привода промыш-
ленных роботов

Вмешательство оператора в ход
исполнения управляющей про-
граммы

Информационный обмен меж-
ду управляющим устройством
и внешним оборудованием

Направление развития языковых средств
данного назначения

С усложнением состава задач, возлагаемых
на промышленные роботы, расширяется раз-
нообразие и усложняется семантика конст-
рукций языка

Схемы программ, графические изображения
формального типа (например, сети Потри)

Средства представления алгоритмов и струк-
тур данных различных уровней и степени
формализации — языки уровня ассемблера,
формальные и полуформальные языки высо-
кого уровня

Разработка унифицированной системы внут-
ренних представлений — состава форматов
структур данных, служащих для представле-
ния текущих состояний процессов

Создание эффективных диалоговых средств
составления и редактирования

Разработка качественно новых диалоговых
средств для взаимодействия оператора с про-
мышленными роботами, оснащенными раз-
витыми средствами очувствления

Повышение уровня языка спецификаций тех-
нологических команд (языка привязки к тех-
нологии)

Создание формальных средств описания ки-
нематики и динамики промышленных робо-
тов, организации интерфейса с приводами
промышленных роботов

Развитый диалог между устройством управ-
ления и человеком-оператором

Разработка унифицированных интерфейсов
и протоколов обмена

активная податливость и т. н. Круг вопросов, которые необходимо
решать для продвижения в развитии программного обеспечения
промышленных роботов, настолько широк, отдельные вопросы так
сложны, что эффективное решение их возможно только при условии
объединения значительных усилий различных коллективов, их ра-
циональной специализации и кооперирования.
УДК 621.8

КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ СИСТЕМЫ
УПРАВЛЕНИЯ РОБОТОТЕХНИЧЕСКИМИ
КОМПЛЕКСАМИ

А. Н. Домарацкий

Изучение и анализ предшествующего этапа развития программного
обеспечения систем управления робототехническими комплексами
(РТК) показывают, что преобладающим подходом к созданию про-
граммного обеспечения этих систем являлось функциональное про-
граммирование [1]. Существенным недостатком функционального
программирования является отсутствие системного подхода к раз-
работке программного обеспечения, что обусловливает несовмести-
мость многих функциональных программ и в значительной мере за-
трудняет и тормозит широкое внедрение РТК в различных отрас-
лях народного хозяйства.

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

В настоящей работе предпринята попытка выработки такой кон-
цепции. Здесь не будет дано полной разработки соответствующей
теории вплоть до получения завершающих формул и формализо-
ванного описания систем управления РТК. Мы постараемся лишь
изложить на концептуальном уровне подход к разработке систем
управления и их программного обеспечения. При изложении будем
стараться придерживаться системного подхода.

Основой разрабатываемой концепции является то, что програм-
мное обеспечение управляющих систем представляет собой целост-
ную систему, т. е. система программного обеспечения есть часть
более крупного образования и представляет собой- совокупность
взаимодействующих компонент , [2]. Отметим, что с увеличением
размеров системы опа постепенно становится сложной, а затем и
чрезвычайно сложной. Часто функциональные свойства систем не-
возможно выразить современными методами описаний. В таких ус-
ловиях повышается роль моделирования, которое в настоящее время
представляет собой одно из самых эффективных средств преодоле-
ния затруднений, связанных со сложностью систем. Модели помо-
гают глубже понять общее назначение системы, общие особенности
автоматизированного комплекса, в рамках которого система должна
функционировать, особенности аппаратных средств, на которых сис-
тема может быть реализована, и т. и. Применение модели на этапе
разработки программного обеспечения облегчает восприятие и осо-
знание возможностей системы и способствует выработке совокупно-
сти правил построения программного обеспечения, которые можно
было бы принять в качестве стандарта во всех ведущихся разра-
ботках программного обеспечения, и этим обеспечить высокую сте-
пень повторяемости результатов и совместимости создаваемых про-
граммных систем.

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

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

Попытаемся создать концептуальную модель систем управления
РТК с использованием концепций абстрактных представлений, ие-
рархических структур и модульных построений.

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

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

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

Обычно на условной границе между системой и окружающей
средой определяют совокупности правил для осуществления обмена
информацией, которые определяют содержание понятий интерфей-
сов системы [3].

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

Разработанная модель (см. рисунок) создавалась ради облегче-
ния возможности выработки общих принципов построения програм-
много обеспечения систем управления РТК.

Концептуальная модель системы управления РТК

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

Заметим, что обоснованное структурирование предполагает на-
личие соответствующих критериев. Ограничимся лишь концептуаль-
ными «руководящими» принципами структурирования, так как вы-
работка критериев не входит в задачу настоящего изложения.

Известно, что общим способом структурирования является иерар-
хическое упорядочение [4]. Прежде чем приступить к структури-
рованию процессов абстрактного информационного объекта, сфор-
мулируем основные «руководящие» принципы, из которых и будем
исходить.

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

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

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

Наконец, при «настройке» концептуальной модели на конкрет-
ное применение могут возникнуть трудности, обусловленные нали
чием па каждом уровне рамок ограниченного набора общих функ-
ций. Чтобы избежать этих осложнений, необходимо предусмотреть
возможность выбора из заранее подготовленных совокупностей
функциональных возможностей на каждом иерархическом уровне.
Такие совокупности должны быть ориентированы на обеспечение
проявления конкретных функциональных свойств системы. В кон-
цептуальной модели они отображаются соответствующими подмно-
жествами функциональных процессов. Набор общих функций, от-
ражающих лишь суть выполняемых действий на иерархических
уровнях, и совокупности функциональных возможностей, присущих
каждому иерархическому уровню, образуют двумерную структуру
функциональных процессов абстрактного информационного объекта.
Совокупности возможностей обычно называют подмножествами
функций. Возможность выбора подмножества функций на иерархи-
ческих уровнях можно принять за четвертый руководящий принцип
структурирования.

Таким образом, мы определили четыре основных «руководящих»
принципа структурирования процессов абстрактного информацион-
ного объекта:

ограничение функциональной нагрузки на каждом иерархиче-
ском уровне;

обеспечение функциональной и информационной изолированно-
сти иерархических уровней;

выделение на иерархических уровнях ограниченного набора об-
щих функций, отражающих лишь суть выполняемых действий;

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

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

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

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

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

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

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

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

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

В заключение отметим, что идеи, лежащие в основе изложенной
концепции создания программного обеспечения системы управления
РТК, заложены в разработанную в ЛИИАН систему алгоритмиче-
ских модулей управления роботами АМУР-80 [5]. С использовани-
ем этой системы создано и прошло испытание программное обеспе-
чение системы управления сварочным роботом, которое осуществля-
лось совместными усилиями ЛИИАН, Института прикладной
математики им. М. В. Келдыша АН СССР в кооперации с други-
ми организациями. Испытания, проведенные в натурных, услови-
ях, прошли успешно и показали, что использование разработанной
методики способствовало созданию целостной системы программного

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

ЛИТЕРАТУРА

1.	Хатвани Й., Янош Й. Программные изделия для систем проектирования
и управления производством.— ТИИЭР, 1980, т. 68, № 9, с. 13—17.

2.	Управление, информация, интеллект/Под ред. А. И. Берга и др. М.: Мысль,
1976. 383 с.	'

3.	Интерфейс для программируемых приборов в системах автоматизации
эксперимента/Н. И. Гореликов, А. Н. Домарацкий, С. Н. Домарацкий, В. А.
Лискин, Н. В. Попенко, Л. С. Ситников. М.: Наука, 1981. 264 с.

4.	Лйнгер Р., Миллс X., Уитт Б. Теория и практика структурного программи-
рования. М.: Мир, 1982. 406 с.

5.	Пономарев В. М., Домарацкий А. И., Никифоров В. В. Система алгоритми-
ческих модулей управления роботом — АМУР-80: Препр. ЛНИВЦ АП СССР
№ 20. Л., 1981. 50 с.

УДК 681.32

СИСТЕМА ВЗАИМОДЕЙСТВИЯ
ПАРАЛЛЕЛЬНЫХ ПРОЦЕССОВ
В УПРАВЛЯЮЩИХ

МНОГОМАШИННЫХ КОМПЛЕКСАХ,
ПОСТРОЕННЫХ НА БАЗЕ МИКРО ЭВМ

А. Н. Домарацкий, А. В. Каширин, Н. Д. Проскурина

В настоящее время актуальна задача распределенных систем уп-
равления. Проводятся интенсивные исследования в этом направле-
нии (см., например, [1—3]). Однако существует ряд факторов, за-
трудняющих реализацию и использование распределенных систем
управления. Такое положение вынуждает искать оригинальные ре-
шения при проектировании программного обеспечения для много-
машинных систем управления, основываясь на идеях общего харак-
тера из предыдущих исследований и на имеющихся языковых воз-
можностях. Полученные решения имеют конкретное выражение в
виде совокупности понятий, функциональных моделей системы, мо-
дели структуры, организации программ и вычислительных процес-
сов в соответствии с используемыми методами программирования и
системой автоматизации проектирования программного обеспечения.
Примером такого подхода является комплекс работ, проводимых под
названием АМУР [4, 5].

В предлагаемой статье описывается логическая организация
взаимодействия программных процессов в многомашинных управ-
ляющих комплексах на основе микро-ЭВМ «Электроника-60».

Как и для любой программной системы, качество описания и ре-
зультаты проектирования непосредственно зависят от используемых
средств отображения принимаемых рещеций [6, 7]. Средства отобра-

2 Заказ м %og	чч
жения должны служить не столько иллюстрацией к тексту на есте-
ственном языке, сколько базой для построения абстрактных моделе!
разрабатываемой системы. Модели облегчают понимание как функ
циональных, так и нефункциональных характеристик программной
системы. При дальнейшем изложении будем стараться придержи
ваться принципа, высказанного в статье [8], т. е. думать не о пост-
роении хорошей модели вычислительной системы, а о построении
вычислительной системы, возможно более близкой к хорошей мо-
дели.

На используемом уровне абстракции достаточно понимания по-
нятия программного процесса как последовательности действий ло-
гической машины над данными из доступной памяти. Будем исполь-
зовать графическую систему обозначений, элементы которой (и
отношения между ними) показаны на рис. 1. Вопросы анализа и
сравнения используемой графической нотации в данной статье не
рассматриваются. Информацию о других способах отображения про-
граммных средств можно получить из работ [6, 9].

Исходные требования к описываемым ниже программным сред-
ствам вытекают из анализа принципов организации взаимодействия
программных процессов в одномашинной системе управления на
микро-ЭВМ «Электроника-60». Их описание и пример реализации
даются в работах [4, 5].

Базовая модель одномашинной системы управления изображена
на рис. 2. Система управления представляет собой совокупность
взаимодействующих последовательных процессов (функциональные
процессы). Эта совокупность разбивается на программные и внеш-
ние процессы. Внешние процессы составляют окружающую среду
для программных процессов и являются, концептуальными понятия-
ми, вводимыми для представления взаимного влияния состояний и
событий объектов окружающей и программной среды. Не принимая
во внимание детали реализации этого взаимного влияния, будем
считать, что отдельные «действия» внешних процессов выполняются
над данными в памяти вычислительной машины. Такое предположе-
ние позволяет использовать одинаковые понятия для программных
и внешних процессов, что вводит однородность в концептуальное
представление системы управления. Взаимодействие функциональ-
ных процессов осуществляется через общие элементы данных
(структуры данных) и через использование общих подпрограмм,
хранимых в памяти ЭВМ (рис. 3). Наряду с элементарными типами
данных машинного языка (байты, слова) используются семафорные
переменные, изменяемые с помощью операций UP и DOWN [10].

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

Дадим краткую формулировку требований к программным сред-
ствам, реализующим взаимодействие функциональных процессов в
многомашинном комплексе. Основное функциональное ограничение
на средства взаимодействия процессов заключается в необходимости
использования результатов программирования для одномашинной
системы управления в многомашинном варианте без какой-либо мо-
дификации, вплоть до уровня объектных модулей. Топология связей
отдельных ЭВМ многомашинного комплекса считается произвольной
(функциональные возможности устройств связи ЭВМ определяются
исходя из потребностей абстрактных моделей). Соответствие между
отдельными функциональными процессами и ЭВМ комплекса, где
они могут протекать, устанавливается статически при компоновке
системы. Ограничений на распределение множества функциональ-
ных процессов по отдельным ЭВМ не накладывается. Заметим, что
вопросы выбора топологии комплекса и распределения процессов в
данной статье не рассматриваются. Считается, что конкретная систе-
ма управления может быть реализована множеством способов.

Описываемые средства взаимодействия процессов опираются на
следующие проектные решения. Множество функциональных про-
граммных процессов (включая и общие данные) разбивается па под-
системы процессов. Между подсистемами процессов и ЭВМ комп-
лекса устанавливается взаимное однозначное соответствие. Процес-
сы одной подсистемы, «действия» которых выполняются над общими
данными из второй подсистемы (внешние данные), естественным
образом становятся внешними процессами ио отношению ко второй
подсистеме. Далее будем называть их внешними программными
процессами в отличие от внешних процессов, соответствующих про-
цессам окружающей среды. Будем считать, что в состав всех под-
систем входят копии всех общих программ, к. которым обращаются
процессы подсистем, в то время как каждая общая структура дан-
ных хранится в памяти только одной ЭВМ. Основная функция
средств взаимодействия процессов формулируется следующим o$j>a-
зом: во время выполнения «действий» программного процесса выде-
лить «действия» над внешними данными и реализовать их так, как
будто эти данные хранятся в памяти той же ЭВМ. Такие «действия»
разбиваются па два типа: семафорные операции над внешними се-
мафорными переменными и адресные команды (двухадресные и од-
ноадресные для ЭВМ «Электроника-60»), операнды которых являют-
ся внешними данными. Взаимодействие подсистем процессов рас-
сматривается как объединение сигнального (семафорные операции)
и информационного (адресные команды) взаимодействий.

Основу средств взаимодействия процессов составляет комплект
подпрограмм, копии которого хранятся в памяти каждой ЭВМ комп-
лекса. Попытка выполнить «действие» функционального процесса над
внешними данными сопровождается неявной передачей управления
средствам взаимодействия процессов, которые программно моделиру-
ют это «действие», используя аппаратные связи комплекса и собст-
венные данные. Каждая копия программы средств взаимодействия
процессов снабжается собственными данными, которые описывают
пути доступа к внешним данным для соответствующей подсистемы
функциональных процессов, а также информацию для выполнения
«действий» внешних программных процессов и являются множест-
вом дескрипторов, типы которых и отношение пути доступа между
ними изображены па рис. 4 (для случая, когда ЭВМ комплекса свя-
зываются через общую память). Дескриптор процесса включает в
себя информацию о состоянии процесса, значение его приоритета и
указатели на дескрипторы внешних данных, необходимых для про-
текания процесса. Дескриптор внешней структуры данных содержит
поля с информацией для его поиска при обработке неявного вызова
средств взаимодействия процессов из функциональных процессов,
индивидуальный код этой структуры данных и указатель места се
хранения. Местом хранения может быть либо локальная память
рассматриваемой ЭВМ, либо память соседней ЭВМ (с которой име-
ется физическая связь, например, общая память). Структура и со-
держание дескрипторов соседних ЭВМ и сегментов общей памяти су-
щественно зависят от реализации средств связи ЭВМ и несут ин-
формацию, необходимую для реализации абстракции внешних
программных процессов. Разбиение описания аппаратных средств
связи на два типа целесообразно для случая, когда сегмент общей
памяти связывает более двух ЭВМ комплекса. Выполненное струк-
турирование собственных данных средств взаимодействия процессов
способствует локализации модификаций при изменениях в разбиении
на подсистемы процессов, места хранения общих данных, топологии
связей ЭВМ комплекса.

Модели взаимодействия двух подсистем процессов через общие
данные изображены на рис. 5—7. В приведенных примерах исполь-
зуется такой уровень детализации «действий» процессов, при кото-
ром механизм вызова «действий» через аппаратную связь ЭВМ
(внешние действия) не уточняется. Полагается, что перед выполне-
нием внешнего «действия» средства взаимодействия процессов мо-
гут определить, как и в какой ЭВМ комплекса оно должно проис-
ходить, а во время выполнения внешнего «действия» — в какой
ЭВМ протекает данный внешний программный процесс. Началу вы-
полнения внешнего «действия» предшествует формирование пара-
метров для него. Общим моментом для всех моделей является спо-
соб неявного вызова средств взаимодействия процессов из «дейст-
вий» функциональных процессов над внешними данными. Вызов
средств взаимодействия процессов сопровождается подготовкой
(также неявной) параметров,' необходимых для поиска соответст-
вующих дескрипторов внешних данных (для микро-ЭВМ «Электро-
ника-60» таким механизмом может быть прерывание при обращении
к несуществующей памяти, если между элементами внешних дан-
ных и адресами незанятой области адресного пространства устанав-
ливается взаимно однозначное соответствие).

Взаимодействие подсистем процессов основывается на возможно-
стях СВП выполнять ряд типов внешних «действий». Для сигналь-
ного взаимодействия они показаны на рис. 5 и 6 (отметим, что ну-
мерация потоков информации па рисунках совпадает с порядком их
возникновения).

Для представления DOWN-операции над внешним семафором
вводятся понятия «образа» и «оригинала» внешнего семафора.
«Оригинал» семафора соответствует месту храпения действительно-
го состояния семафорной переменной,- «образ» семафора — семафор-
ной переменной, вводимой только для задержки функциональных
процессов на время выполнения DOWN-операции над «оригиналом»
внешнего семафора. Необходимость активации специального про-
цесса СВП при выполнении DOWN-операции над внешним семафо-
ром, связана с отмеченными выше особенностями реализации «дей-
ствий» внешних процессов пад семафорами.
Используются [ О
при неявном вызове ) . -
из функциональных I •
процессов	°

Глобальные
имена
данных СВП

Дескрипторы процессов

Используются
внешними
программными
процессами

Дескрипторы внешних
данных и данных,
требуемых внешним
программным процессом

Дескрипторы
соседних ЭВМ

Дескрипторы
сегментов общей
памяти

Рис. 4. Схема пути доступа к элементам данных средств взаимодействия процессов

Рис. 5. Выполнение UP-операции над внешним семафором

1,2 — индивидуальный код семафора; з — адрес семафора

Модель элементарною шага информационного взаимодействия
изображена на рис. 7. Ограниченный объем статьи не позволяет де-
тализировать отдельно «действия» моделирования адресной коман-
ды, поскольку их раскрытие связапо с условиями ветвления алго-
ритма моделирования (зависимость от количества операндов, места
их хранения). При их реализации используются два типа внешних
«действий»: определение значения операнда и выполнение заданной
машинной команды. Применяя первое действие, внешний програм-


Выполнение DOWN-онерации над внешним семафором

- индивидуальный код и адрес «образа» семафора; 4— адрес «оригинала» семафора; 5, 6 — адрес «образа» семафора
Рис. 7. Модель выполнения адресной команды с операндами — внешними элементами
данных

1 — код адресной команды (если команда двухадресная, то значение немодифицируе-
мого операнда); 2 — состояние процессора; 3— состояние счетчика команд и регист-
ров общего назначения

мный процесс получает значение элемента внешних данных по ука-
зателю пути доступа к нему. Результатом выполнения второго типа
внешнего «действия» является выполнение машинной команды,
задаваемой кодом операции, указателем пути доступа к эле-
менту внешних данных — операнду команды, а для двухадресных
команд — значением второго операнда. Значение состояния процес-
сора непосредственно после выполнения внешнего «действия» тако-
го типа используется для формирования состояния внешнего про-
граммного процесса при завершении моделирования адресной коман-
ды. Указатель пути доступа к элементу внешних данных включает
в себя код внешней структуры данных, указатель положения эле-
мента в структуре, способ адресации (косвенный или прямой),
применяем!*!! к элементу структуры.

В заключение отметим, что в статье приводятся модели взаимо-
действия функциональных процессов в многомашинной системе уп-
равления (являющейся расширением одномашинного варианта, опи-
санного в работах [4, 5]), для чего вводится и используется спе-
циальная графическая нотация. Все программные модули средств
взаимодействия процессов написаны на языке Ассемблера микро-
ЭВМ «Электроника-60». Система средств взаимодействия процессов
отлажена и успешно прошла этап тестирования.

ЛИТЕРАТУРА

1.	Hansen Р. В. The Architecture of Concurrent Programs. New Jersy: Prentic-
Hall: Inc. Englewood, 1977. 317 p.

2.	Язык программирования АДА. M.: Финансы и статистика, 1981. 189 с.

3.	Hansen Р. В. Multiprocessor Architecture for Concurrent Programs,— Com-
put. Architecture News, 1978, N 4, vol. 7, p. 4—32,
li. Пономарев В. М., Домарацкий А. Н., Никифоров В. В. Система алгоритми-
ческих модулей управления роботами — АМУР-80: Препр. ЛНИВЦ АН СССР
№ 20. Л., 1981. 50 с.

5.	Домарацкий А. Н., Никифоров В. В. Программное обеспечение устройства
контурного управления УКМ-772 для промышленных роботов.—Наст. сб.

6.	Питерс Л. Дж. Методы отображения и компоновки программных средств,—
ТИИЭР, 1980, т. 68, № 9, с. 55—66.

7.	Дейкстра Э. Дисциплина программирования. М.: Мир, 1978. 274 с.

8.	Деннинг П. Дж. Как научиться предсказывать.— ТИИЭР, 1980, т. 68, № 9,
с. 74-80.

9.	Зейв П. Определение требований к программному обеспечению,—ТИИЭР,
1980, т. 68, № 9, с. 46-55.

10.	Дейкстра Э. Взаимодействие последовательных процессов.— В кн.: Языки
программирования. М.: Мир, 1972, с. 9—84.

УДК 681.32

МУЛЬТИПРОГРАММНЫЕ

И МУЛЬТИПРОЦЕССОРНЫЕ СИСТЕМЫ
УПРАВЛЕНИЯ РОБОТОВ

А. Ф. Верещагин, А. А. Дмитриев, Т. Н. Сивашева

Система управления современного адаптивного робота решает зада-
чу целенаправленного взаимодействия ЭВМ и окружающей среды,
включающей исполнительный механизм и приводы, сенсоры и тер-
миналы, технологическое оборудование и человека-оператора. При
этом в системе управления параллельно выполняется группа дейст-
вий,» которые часто называют процессами. Если они связаны между
собой сигналами, говорят об асинхронных процессах, если связаны со
временем, то это синхронные процессы. Если время решения задачи
не превышает времени исполнения объектом этого решения, то го-
ворят о мультипрограммных системах реального времени. Именно
их используют при управлении физическими объектами от ЭВМ.

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

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

Мультипрограммные системы. Функции мультипрограммной си-
стемы — обеспечение множества взаимодействующих в ЭВМ задач
{Л, Тг,..., TN}, разделяющих разнообразные ресурсы, включающие,
кроме процессора, запоминающие устройства, регистры, флаги, под-
программы ввода—вывода (В/В) и т. д. (рис. 1).
//рсцессрр

Таймер

Регистры

Ректиатееры Рсргм

upmvuua

wzaeu

Рис. 1

ПРЕРЫВАНИЯ

Т7са/7рсграммы 3/8

МОНИТОР

Рис. 3

. управление
4* приводами

генератор
траекторий

Y' . диагностика
4 6 • системы

. опрос

•* 5 • датчиков

- . диалог

1 * с оператором

у. , планирование
2 ’ траекторий

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

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

рационных систем мини-ЭВМ и больших систем. Особенно полезно
для решения проблем управления роботами изучать операционные
системы мини-ЭВМ из-за их широкого использования при автомати-
зации технологических процессов различного назначения. Более
того, некоторые микро-ЭВМ, такие, как «Электроника-60» и СМ-1800,
могут непосредственно работать со штатными операционными си-
стемами, реализующими все необходимые функции средствами об-
щего типа. Требуемое для этого аппаратурное обеспечение (накопи-
тели на магнитных дисках, расширенная оперативная память) мо-
жет оказаться слишком дорогим и ненадежным в условиях массового
промышленного применения. Вместе с тем возможности достаточно
скромных аппаратных средств, содержащих микропроцессор (МП)
с блоками постоянной и оперативной памяти (постоянные запоми-
нающие устройства (ПЗУ) и оперативные запоминающие устройст-
ва (ОЗУ) соответственно), йнтерфейсные платы ввода — вывода для
сопряжения с объектом (рис. 2), в деле управления роботами далеко
еще не исчерпаны, а способность таких средств надежно работать
в производственных условиях существенно выше. В этом случае все
программное обеспечение должно храниться в постоянных запоми-
нающих устройствах и автоматически разворачиваться в рабочее
состояние после включения питания. В частности, архитектура мик-
ро-ЭВМ «Электроника-60» и ее штатные комплектующие модули
приспособлены для создания такой минимальной конфигурации си-
стемы управления.

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

В настоящее время все чаще появляются разработки так назы-
ваемых «кремниевых» операционных систем реального времени, ба-
зирующихся в постоянных запоминающих устройствах и обеспечи-
вающих простейшие, но достаточные для конкретного применения
средства управления задачами и их взаимодействием. Объем ядра
такой операционной системы в некоторых случаях не превосходит
100 байт. Создание специализированных операционных систем ре-
ального времени для обеспечения микропроцессоров и микро-ЭВМ,
встраиваемых в системы управления роботов, представляет собой
актуальную проблему, решение которой существенно упростит про-
граммирование робота для каждого нового применения.

В МВТУ им. Н. Э. Баумана ведется разработка и исследование
принципов построения малых операционных систем реального вре-
мени для минимальной конфигурации аппаратных средств, реали-
зуемых на микро-ЭВМ «Электроника-60». Исследования показали,
что ядро (монитор) такой операционной системы, решающей задачу
приоритетного обслуживания до 256 параллельных задач, занимает
объем около 450 слов в памяти микро-ЭВМ.

Монитор выполняет диспетчерские функции в мультипрограм-
мном обеспечении системы управления. Состав и структура монито-
ра частично представлены на рис. 3. Отдельные более или менее
автономные функции системы управления оформлены как парал-
лельно выполняемые на одном процессоре задачи (процессы) Ti,...
..., Те, взаимодействующие по принципу «поставщик—потребитель»
через буферы данных В,, ...,В4, представляющие собой общие обла-
сти памяти. Монитор реализует заранее заданную приоритетную
дисциплину обслуживания, но в зависимости от прерываний (аппа-
ратных или программных), поступающих для обработки в монитор
от пульта управления, датчиков, таймера и аварийных сигналов, эта
Дисциплина может быть изменена.

Задача Т, поддерживает дпалог с оператором, накапливая ди-
рективы и данные в буфере В, в форме, доступной для последую-
щего редактирования и исправления. Задача Тг становится актив-
ной, как только информация в Bt подготовлена для преобразования
ее в план действий робота и траекторию исполнительного органа
(в координатах рабочего пространства). Задача Т3 генерирует в ре-
альном времени желаемые траектории исполнительных приводов
манипулятора, выполняя обратное преобразование координат с конт-
ролем предприсанных скоростей и ускорений. Задача Т4 реализует
контуры управления следящих систем приводов, получая информа-
цию из буфера Bi, обновляемого с высокой частотой (50 Гц) за-
дачей J's, которая опрашивает датчики положения и другие сенсо-
ры. В результате в буфере B,t всегда имеется текущая информация
о фактическом функционировании робота и другого технологиче-
ского оборудования. Эти данные критически оцениваются задачей
Тв с отображением результатов оценки и рекомендаций на пульте
оператора, а при ненормальном ходе процесса вырабатываются ава-
рийные прерывания.

Построенная система открыта для включения других задач и ор-
ганизации других взаимодействий между задачами. В частности, за-
дача генерации траекторий робота (Т3) должна в некоторых слу-
чаях иметь своевременный доступ к информации, имеющейся в бу-
фере Bi, для корректировки траекторий, например, в зависимости
от скорости движения конвейера или фактических результатов ра-
боты. Все программы в этой системе должны быть написаны на
языке Ассемблера для достижения минимальных объемов исполь-
зуемой памяти. Однако в более мощных управляющих вычислитель-
ных системах, построенных на базе ЭВМ «Электроника-60» или
СМ-3, -4 с использованием, например, дисковых накопителей, анало-
гичные вопросы построения мультипрограммной системы управления
робота могут быть эффективно решены в рамках семейства опера-
ционных систем РАФОС и ОСРВ, а также языков MODULA-2 и
CASIC. Язык высокого уровня CASIC содержит специальные опе-
раторы для программирования аппаратуры КАМАК. В МВТУ
им. Н. Э. Баумана ведутся опытные разработки по применению ука-
занных языков и систем для управления адаптивными роботами но-
вых поколений.

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

Первое очевидное решение в нашей задаче управления робо-
том — передача функции управления приводами отдельному микро-
процессору. При этом может оказаться не слишком расточитель-
ным выделение каждому приводу персонального микропроцессора.
Его задача — организовать качественное слежение за уставками,
передаваемыми с центральной ЭВМ. Такая работа микропроцессора
в качестве контроллера оправдывается тем, что путем перепрограм-
мирования при одном и том же аппаратурном решении можно
44
»

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

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

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

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

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

С этой целью был построен двухпроцессорный управляющий ком-
плекс на базе аппаратуры КАМАК, обеспечивающей большую гиб-
кость и легкую перестраиваемость комплекса. В комплекс входит
микро-ЭВМ «Электроника-60», укомплектованная процессором М2,
дополнительной памятью ПЗ объемом 16К слов, а также интерфейс-
ными платами И7 (для сопряжения с дисплеем (ВТ-2002 или
VT-340)) и П4 (для связи с накопителем на гибких магнитных
дисках (ГМД)). Плата ИК объединяет ЭВМ с контроллером крейта
(КК). В крейт входят стандартные модули КАМАК, которые могут
быть необходимы системе, и микропроцессорный модуль на базе
БИС КР580ИК80А, занимающий нормальную позицию в крейте
(рис. 4).

Микропроцессорный модуль состоит из устройства связи (УС)
с магистралью крейта и микропроцессорной системы, содержащей,
кроме процессора, блоки оперативной и постоянной памяти, а также
интерфейс ввода—вывода. Обмен данными между7 ЭВМ и МП-моду-
лем происходит через регистры записи — чтения. которые соедине-
ны, с одной стороны, с пинтами записи и чтения магистрали, а с
Рис. 4

другой — с двунаправленной шиной данных модуля через устройст-
во связи.

Обмен информацией между ЭВМ и МП-модулем может иници-
ироваться как ЭВМ (путем установки запроса на прерывание мо-
дуля), так и самим модулем, который может выставить нужный
LAM-запрос на магистраль крейта. Аппаратное сопряжение никак
не ограничивает программиста при организации двустороннего об-
мена данными и программами.

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

Программное обеспечение микро-ЭВМ «Электроника-60» реша-
ется на базе языка CASIC в операционной системе РАФОС. При
этом управление аппаратурой КАМАК ведется с помощью дирек-
тив языка без применения ассемблера. Язык CASIC ориентирован
на программирование систем реального времени, позволяет описы-
вать параллельные действия в простых и естественных терминах и
работать с многими задачами в соответствии с системой приорите-
тов. Совместное использование языка программирования CASIC и
аппаратуры в стандарте КАМАК позволяет добиться гармоничного
сочетания программных и аппаратных средств при создании как ис-
следовательских комплексов, так и промышленных установок.

Программирование микропроцессорного модуля представляет со-
бой более сложную задачу. При помощи кросс-средств в операцион-
ной системе РАФОС возможно подготовить программы и потом за-
грузить их в микропроцессор. Из-за сравнительно низкой произво-
дительности и малого объема оперативной памяти программы для
микропроцессора должны быть как можно более эффективными.

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

УДК 681.32

ОРГАНИЗАЦИЯ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

МНОГОПРОЦЕССОРНЫХ СИСТЕМ УПРАВЛЕНИЯ

И. П. Белякова

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

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

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

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

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

наличие системных программ, обеспечивающих эксплуатацию си-
стемы управления;

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

В соответствии с этими требованиями в ЛИИАН разрабатывает-
Рис. i

Рис. 2

ся экспериментальная модульная распределенная система управле-
ния антропоморфным манипулятором. Аппаратная часть системы
представляет собой локальную сеть процессорных модулей (ПМ)
на основе микро-ЭВМ «Электроника-60» (рис. 1). Процессоры орга-
низованы в иерархическую структуру посредством специальных мо-
дулей связи. Управление системой во время ее разработки, отлад-
ки и эксплуатации осуществляет подсистема на основе специальной
системной микро-ЭВМ с соответствующими периферийными устрой-
ствами. Подключенная к системе мини-ЭВМ выполняет функции
разработки программного обеспечения.

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

Распределенная система управления представляет собой систе-
му иерархически организованных функциональных модулей, выпол-
няющих единую задачу управления. Состав, функциональное наз-
начение и связи отдельных модулей зависят от применения системы.
В основу построения системы управления могут быть положены
принципы, развитые для робототехнических комплексов [1, 2]. Мо-
дули разрабатываются как самостоятельные компоненты с исполь-
зованием языков любого уровня. Взаимодействие модулей осущест-
вляется с помощью специальной системы команд распределенной
системы обслуживания, в частности ее подсистемы взаимодействия.
Взаимодействие функциональных модулей с внешними устройства-
ми также выполняется через распределенную систему обслужива-
ния системой команд, аналогичной системе команд обращения к
удаленным модулям процессоров.

Отладка отдельных составляющих может производиться в систе-
ме разработки программного обеспечения или на реальной системе
управления средствами системы обслуживания. Специальная про-
грамма системы разработки программного обеспечения выполняет
компоновку всей системы управления из отдельных модулей с со-
ставлением соответствующих таблиц связей и дескрипторов. Система
загрузки загружает модули из библиотеки системы разработки про-
граммного обеспечения в отдельные процессорные модули. Таким
образом, функциональное программное обеспечение системы управ-
Рис. 3

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

Система взаимодействия входит как подсистема в распределен-
ную систему обслуживания, которая является резидентной системой
любой системы управления. Модули распределенной системы об-
служивания в одинаковом составе содержатся во всех процессор-
ных модулях. Эта система обеспечивает эксплуатацию многопро-
цессорной системы управления:

загрузку и сохранение функционального обеспечения;

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

запуск и остановку отдельных функциональных модулей;

диагностику ошибок системы;

взаимодействие с оператором;

взаимодействие между процессами и процессов с внешними
устройствами.

Распределенная система обслуживания включает в себя две под-
системы: «Оператор» и «Взаимодействие». Система «Оператор» со-
держит библиотеку стандартных программ («Загрузчик», «Отлад-
чик», программу ввода—вывода и т. д.) в каждом процессорном мо-
дуле, вызываемую к исполнению по командам с пульта оператора
системой ЭВМ. В библиотеку могут быть включены и функциональ-
ные модули с возможностью вызова их по именам с пульта опера-
тора. Кроме библиотеки, программа «Оператор» имеет программы
обслуживания связи с пультом оператора, прием—декодирование
команд и вызов к исполнению соответствующих программ, печать
сообщений об ошибках.

Подсистема «Взаимодействие» также имеет библиотеку про-
грамм реализации команд взаимодействия. Эти программы обслу-
живают вызовы из функциональных программных модулей команд
ЧТЕНИЕ, ЗАПИСЬ и ЧТЕНИЕ-ЗАПИСЬ данных из-в процес-
сорные модули и внешние устройства. Система взаимодействия
выполняет не только стандартный информационный обмен между
модулями и внешними устройствами, но и синхронизацию парал-
лельных процессов различных процессоров. Система поддерживает
стратегию один процессор—один функциональный процесс. Система
правил построения системы функциональных модулей обеспечивает
функционирование системы без взаимных блокировок.

Так как система управления антропоморфным манипулятором
имеет экспериментальное исследовательское назначение, ее про-
граммное обеспечение подлежит частной модификации. Для систем
специального назначения система разработки программного обеспе-
чения может быть временно подключена через сеть вычислительных
машин и после разработки программного обеспечения не использо-
ваться с сохранением программ па собственном диске системной
ЭВМ. Система разработки программного обеспечения является в
основном стандартной операционной системой (рис. 3) и содержит,
кроме обычных системных программ, позволяющих разрабатывать
модульные системы, системную программу компоновки системы
многопроцессорного управления. В процессе ее работы заполняют-
ся таблицы и адреса межпроцессорных связей.

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

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

Для функционирования системы разработки программного обес-
печения необходима связь с распределенной системой обслужива-
ния и работа под управлением одного оператора. Кроме того, она
должна быть программно совместима с базовой ЭВМ системы уп-
равления.

Рассмотренная организация программного обеспечения сетевых
управляющих систем показывает структуру системы, занимающей
промежуточное положение между слабо связанными сетевыми си-
стемами вычислительных машин [3] и тесно связанными структу-
рами многопроцессоров, предназначенных как для разработки, так
и для выполнения вычислительных задач [4]. Предложенный под-
ход к структуре программного обеспечения систем управления по-
зволяет разрабатывать их на основе стандартных микропроцессоров
и микро-ЭВМ и стандартных операционных систем. Такие системы
управления можно легко перестраивать, компоновать из готового
программного обеспечения.
ЛИТЕРАТУРА

1.	Никифоров В. В., Смирнов И. А., Чиганов В. А. Унификация архитектуры
и алгоритмической структуры средств управления промышленными робота-
ми.— В кн.: Алгоритмические модели в автоматизации исследований. М.:
Наука, 1980, с. 186—193.

2.	Управление роботами от ЭВМ/Под ред. Е. И. Юревича. Л.: Энергия, 1980.
264 с.

3.	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.

4.	Фуллер С. X., Устерхут Дж. К. Мультимикропроцессорные системы; Обзор
и примеры практической реализации.— ТИИЭР, 1978, т. 66, № 2, с. 135—150.
о РЕАЛИЗАЦИЯ

Z ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ

УДК 621.865.8.004.14:621.757

ПРОГРАММНЫЕ СРЕДСТВА
ДЛЯ ПЛАНИРОВАНИЯ ПРОЦЕССА
АВТОМАТИЧЕСКОЙ СБОРКИ

Д. Е. Охоцимский, А. К. Платонов, С. С. Камынин,

С. И. Гримайло, А. ТО. Каргашин, А. А. Кприльченко, Е. И. Кугушев

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

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

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

В статье рассматриваются программные средства разработанной
в Институте прикладной математики им. М. В. Келдыша АН СССР
автоматической сборочной системы, предназначенные для планиро-. ,
вания процесса автоматической сборки [1—4].	] >

Для задания и исполнения процесса сборки автоматическая ] j
сборочная система содержит ряд программных модулей. Часть из ] j

I...............................................................

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

При отладочных прогонах сборочного процесса часто возникает
необходимость внести исправления в те или иные данные, описы-
вающие сборку. Если при этом использовать только один диалого-
вый режим работы с системой, то могут возникнуть затруднения в
восстановлении смысла этих данных. Для более наглядного пред-
ставления процесса сборки в Институте прикладной математики
им. М. В. Келдыша АН СССР разрабатывался язык высокого уровня,
позволяющий описать процесс сборки, заданный в диалоговом режи-
ме работы с системой, в текстовой форме. Ясно, что возможность
представления процесса сборки па языке высокого уровня в свою
очередь требует наличия возможности осуществлять планирование
на этом языке, что может понадобиться, например, когда использо-
вание диалогового режима по каким-либо причинам оказывается за-
труднительным или вообще невозможным.

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

АВТОМАТИЗИРОВАННОЙ СБОРОЧНОЙ СИСТЕМЫ

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

Для того чтобы сборочный комплекс мог выполнить сборку в
автоматическом режиме, предварительно планируется и отрабаты-
вается процесс сборки и вводится соответствующая информация в
управляющую ЭВМ [3].

Программные средства автоматизированной сборочной системы
включают модули:

1)	задания и редактирования плана сборки;

2)	задания и редактирования планов сборочных операций;

3)	задания и редактирования движений;

4)	задания и редактирования планов условий;

5)	задания и редактирования коэффициентов следящей системы;

6)	управления автоматической сборкой.

Модули 1—5 необходимы для планирования и отработки сбороч-
ного процесса. Планирование целесообразно организовать иерархи-
чески. Весь процесс разбивается па сборочные операции, каждая из Г
которых состоит из последовательности движений. Движения могут
задаваться в виде последовательности позиций манипулятора, вво-
димых в память ЭВМ. Установку в позицию можно осуществлять
как вручную, так и с выносного пульта. Может быть задан пози-
ционный или контурный способ движения. В последнем случае ис-
пользовался прием формирования бегущей программной точки,
получаемой путем интерполяции между выбранными опорными точ-
ками при заданном времени перемещения между ними. Задание па-
раметров движения, их корректирование в процессе отладки вы-
полняются в диалоговом режиме с пульта алфавитно-цифрового
дисплея. При корректировании можно изменять значения парамет-
ров и осуществлять некоторые другие действия, в частности, до-
бавление или изъятие промежуточных опорных точек. Каждое
движение может отрабатываться независимо. Их объединение в
сборочную операцию проводится в диалоговом режиме. Переход от
движения к движению происходит на основе результатов выполне-
ния планов контроля условий, приписанных движениям. В планах
контроля условий может проверяться, например, факт достижения
позиции с заданной точностью, истечение заданного интервала
времени, наступление события, тот или иной результат тестирующе-
го движения и др. По структуре сборочная операция представляет
собой ориентированный граф, вершины которого отвечают движени-
ям и соответствующим планам контроля условий, а ребра — пере-
ходам от движения к движению. Отработанная сборочная операция
заносится в память ЭВМ и используется по вызову. При формиро-
вании сборочной операции полезно использовать аппарат формаль-
ных параметров. В этом случае сборочная операция играет роль
подпрограммы, параметры которой задаются перед исполнением. Та-
кой прием удобен в случае, когда в процессе сборки встречаются
однотипные операции, имеющие одинаковую структуру и состав,
как, например, при скреплении деталей с помощью нескольких бол-
тов и гаек.

Формирование сборочного процесса из сборочных операций реа-
лизуется в диалоговом режиме с использованием модуля 1. Сбороч-
ный процесс, как и отдельная операция, представляет по своей
структуре ориентированный граф, вершины которого отвечают вы-
зовам сборочных операции, а ребра — переходам от одной опера-
ции к другой.

Модуль 4 предназначен для формирования и редактирования
планов проверки условий. При анализе состояния может происхо-
дить его оценка по совокупности ряда критериев. Структура про-
цесса проверки ряда условий имеет вид ориентированного графа.
Результат проверки предыдущего условия определяет выбор по- . 1
следующего. Планы проверки условий формируются автономно и :
играют роль подпрограмм, используемых как в составе операции, ;
так и при объединении операций в сборочный процесс. Формирова- \;
ние и редактирование планов контроля условий выполняются также i I
в диалоговом режиме. В дальнейшем планы контроля условий бу-
дем называть составными условиями или просто условиями, а усло-
вия, указанные в этих планах,— элементарными условиями.

Модуль 5 предназначен для задания и корректирования набора
коэффициентов обратной связи цифровых следящих систем приво-
дов манипуляторов. Наборы коэффициентов хранятся в специаль-
ных массивах и используются по мере необходимости. В процессе
сборки может быть полезным изменение значений коэффициентов,
например их увеличение для повышения точности позиционирова-
ния или их уменьшение для увеличения податливости • манипуля-
тора.

Модуль 6 управляет движением сборочного комплекса в автома-
тическом режиме. Исполнение движения может быть задано для
всего сборочного процесса целиком либо для отдельных его опера-
ций, движений или их элементов, что очень удобно при формирова-
нии сборочного процесса и его отладке.

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

В дальнейшем разработанное программное обеспечение приме-
нялось при автоматической сборке картера двигателя внутреннего
сгорания.

ЯЗЫК ОПИСАНИЯ СБОРОЧНОГО ПРОЦЕССА

Планы сборки, планы сборочных операций, планы контроля условий
и другие объекты задаются в текстовом виде. Описание автомати-
ческой сборки разбито на несколько файлов: план сборки, планы
сборочных операций, описание движений, описание типов движений
[1], планы составных условий, описание элементарных условий.

Прежде чем описывать структуру языка, отметим несколько
принятых в нем соглашений. Все операторы языка начинаются с
одного из следующих ключевых слов: ВЕР — вершина плана;
ПЕР — переход к другой вершине плана; ПАР — параметр;
ВЫП — выполнить; ВЫХ — выход. В пределах одной строки
текста считается комментарием текст от символа «;» до следующе-
го символа «;» или до конца строки. Объектами языка являются
сборочные операции, составные и элементарные условия, их па-
раметры, вершины планов, контуры движений, типы и способы
движения [1] и т. д. Все объекты языка имеют текстовые имена,
которые задает программист. В отличие от ключевых слов имена
объектов языка заключаются в круглые скобки. Обращение к объ-
ектам осуществляется по их именам. Каждый объект может иметь
одно или несколько альтернативных имен, например полное имя и
сокращенное. Обращаться к объекту можно по любому из альтер-
нативных имен.

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

""В качестве примера приведем описание двух первых вершин
плана сборки масляного насоса;

; СБОРКА МАСЛЯНОГО НАСОСА

ВЕР (НАЧАЛО)

ВЫП (ЗАЖАТИЕ КРЫШКИ)

ПАР (КОНТУР) = (ЗАЖАТИЕ КРЫШКИ ЛР)

ПЕР НА (ВСТАВИТЬ БШ)

ВЕР (ВСТАВИТЬ БШ)

ВЫП (ВСТАВЛЕНИЕ ШЕСТЕРНИ)

ПАР (КОН. ПОДВОД ПР К Ш) = (ПОДВОД ПР К БШ)

ПАР (КОН. ПОДВОД Ш К ОТВ)=(ПОДВОД БШ К ОТВ)

ПАР (КОН. ПОИСК ПРИ ВСТАВЛЕНИИ Ш)=(ВСТАВИТЬ БШ)

ПАР (КОН. ПОВТОРИ. ПОДВОД Ш К ОТВ) = (ПОДВОД БШ к отв
ОТ ТОЧКИ 4)

ПАР (КОН. ОТВОД ПР ОТ Ш) = (ОТВОД ПР)

ПАР (ВЫДЕРЖКА ДЛЯ ПОДВОДА ПР К Ш) = 1

ПАР (ВЫДЕРЖКА ДЛЯ ПОДВОДА Ш К ОТВ)=15

ПАР (FI20)=600

ПАР (FI30)=250

ПАР (ALF2)=88

ПАР (ALF3)=-100

ПАР (ALF0)=1912

ПАР (ВЫДЕРЖКА ДЛЯ ОТВОДА ПР ОТ Ш) = 1

ПЕР НА (ВСТАВИТЬ МШ)

Поясним использованные сокращения: ПР — правая рука
(один из манипуляторов); ЛР — левая рука (другой манипуля-
тор) ; БШ — большая шестерня; МШ — малая шестерня; Ш —
шестерня; ОТВ — отверстие; КОН — контур движения.

Первая вершина плана сборки называется НАЧАЛО. В ней вы-
зывается операция ЗАЖАТИЕ КРЫШКИ. У этой операции один
формальный параметр, который называется КОНТУР. Этому пара-
метру приписывается фактическое значение — контур движения,
который называется ЗАЖАТИЕ КРЫШКИ ЛР. После выполнения
j операции переход всегда осуществляется на вершину ВСТАВИТЬ
БИТ.

J Вторая вершина плана сборки называется ВСТАВИТЬ БТП
• В ней выполняется операция вставления шестерни в отверстие
(имя операции — ВСТАВЛЕНИЕ ШЕСТЕРНИ). У этой операции
, несколько формальных параметров — КОН. ПОДВОД ПР К Ш,
j КОН. ПОДВОД Ш К ОТВ и т. д. Всем им приписываются факти-
? ческие значения либо по именам объектов, либо числовые. После
выполнения операции переход всегда осуществляется на вершину с
именем ВСТАВИТЬ МШ.

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

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

В каждой вершине плана операции описывается контур движе-
ния, которое запускается при попадании в данную вершину, состав-
ное условие и его параметры. Этим объектам могут присваиваться
постоянные значения или значения входных параметров операции.
Помимо этого, в каждой вершине описывается способ движения —
позиционный или контурный, тип движения — режим отслеживания
по каждой степени подвижности робота [4] и тип начала — тип на-
чала контура движения по каждой используемой в данном движе-
нии степени подвижности [1]. Считается, что по умолчанию способ
движения — КОНТУРНЫЙ, тип движения — НЕ МЕНЯТЬ по всем
степеням подвижности (т. е. такой же, какой был при исполнении
предыдущего движения), тип начала — АБСОЛЮТНЫЙ по всем
степеням подвижности, используемым в контуре движения (т. е.
начальная точка движения такая, какая записана в таблицах, хра-
нящих контур движения).

В некоторых специальным образом описанных вершинах испол-
нение операции закапчивается и вырабатывается числовой код от-
вета операции (0, 1, 2,...), который описан в этой вершине. Все та-
кие выходы могут быть поименованы.

Перечислим некоторые ключевые слова языка, которые употреб-
ляются для описания плана операции: ОПЕРАЦИЯ — заголовок
операции; КОНДВ — контур движения; УСЛДВ — условие дви-
женин; ТИПДВ — тип движения; ТИПНАЧ — тип начала;
СПДВ — способ движения.

Приведем пример операции вставления шестерни масляного на-
соса в отверстие его основания (в описании операции использова-.
ны те же сокращения, что и в плане сборки);

ОПЕРАЦИЯ (ВСТАВЛЕНИЕ ШЕСТЕРНИ)

ПАР (ПОДВОД ПР К Ш)

ПАР (КОН. ПОДВОД Ш К ОТВ)

ПАР (КОН. ПОВТОРНЫЙ ПОДВОД Ш К ОТВ)

ПАР (КОН. ПОИСК ПРИ ВСТАВЛЕНИИ Ш)

ПАР (КОН. ОТВОД ПР ОТ Ш)

ПАР (ВЫДЕРЖКА ПО ВРЕМЕНИ ДЛЯ ПОДВОДА ПР К Ш)

ПАР (ВЫДЕРЖКА ДЛЯ ПОДВОДА Ш К ОТВ)

ПАР (FI20); ПАРАМЕТРЫ ДЛЯ

ПАР (FI30); ПРОВЕРКИ

ПАР (ALF2); ПОПАДАНИЯ Ш

ПАР (ALF3); В ОТВ

ПАР (ALF0);

ПАР (ВЫДЕРЖКА ДЛЯ ОТВОДА ПР ОТ Ш)

................... ВЕРШИНА 1 .....................

ВЕР (ПОДВОД ПР К Ш)

КОНДВ (КОН. ПОДВОД ПР К Ш)

УСЛДВ (КОНЕЦ ПР И ОЖИД)

ПАР (ВРЕМЯ ОЖИД) = (ВЫДЕРЖКА ДЛЯ ПОДВОДА ПР К Ш)

ПЕР НА (СХВАТИТЬ Ш)

..................... ВЕРШИНА 2 ......................

ВЕР (СХВАТИТЬ Ш)

КОНДВ (СЖАТЬ СХВАТ ПР)

УСЛДВ (КОНЕЦ ПР И ОЖИД)

ПАР (ВРЕМЯ ОЖИД) =11

ПЕР НА (ПОДВОД Ш К ОТВ)

......-..............ВЕРШИНА 3 .......................

ВЕР (ПОДВОД Ш К ОТВ)

КОНДВ (КОН. ПОДВОД Ш К ОТВ)

УСЛДВ (КОНЕЦ ПР И ОЖИД)

ПАР (ВРЕМЯ ОЖИД) = (ВЫДЕРЖКА ДЛЯ ПОДВОДА Ш К ОТВ)

ПЕР НА (ВСТАВЛЕНИЕ Ш)

....................... ВЕРШИНА 4 ....................

ВЕР (ВСТАВЛЕНИЕ Ш)

КОНДВ (КОН. ПОИСК ПРИ ВСТАВЛЕНИИ Ш)

ТИПДВ (СИЛОВОЙ) ДЛЯ (ЗПР) (ПОИСК) ДЛЯ (4ПР), (5ПР)

ТИПНАЧ (НЕПРЕРЫВНЫЙ) ДЛЯ ВСЕХ СТЕПЕНЕЙ
(АБСОЛЮТНЫЙ) ДЛЯ ЗПР

УСЛДВ (ТЕСТ ЛИНЕЙНОЙ КОМБИНАЦИИ СТЕПЕНЕЙ 2, ЗПР)
ПАР (ВРЕМЯ ТЕСТА) = 1000

ПАР (FI20) = (FI20)

ПАР (FI3O) = (FI30)

ПАР (ALF2) = (ALF2)

ПАР (ALF3) = (ALF3)

ПАР (ALF0) = (ALF0)

ПЕР ЕСЛИ (ОСЬ ВСТАВЛЕНА) НА (РАЗЖАТЬ ПР)

ЕСЛИ (ОСЬ НЕ ВСТАВЛЕНА) НА (ПОВТОР ПОДВОД К ОТВ)

; ........................ВЕРШИНА	5 ......................

ВЕР (ПОВТОР ПОДВОД К ОТВ)

СПДВ (ПОЗИЦИОННЫЙ)

КОНТДВ (КОН. ПОВТОРНЫЙ ПОДВОД Ш К ОТВ)

УСЛДВ (ОЖИДАНИЕ ПОПАДАНИЯ ПР В ОКРЕСТНОСТЬ)

ПАР (РАДИУС ОКРЕСТНОСТИ) =2

ПЕР НА (ВСТАВЛЕНИЕ Ш)

; ....................... ВЕРШИНА	6 .....................

ВЕРШИНА (РАЗЖАТЬ ПР)

КОНДВ (РАЗЖАТЬ СХВАТ ПР)

УСЛДВ (КОНЕЦ ДВ И ОЖИД)

ПАР (ВРЕМЯ ОЖИД)=1

ПЕР НА (ОТВОД ПР)

; ........................ВЕРШИНА	7 ......................

ВЕР (ОТВОД ПР)

ТИПНАЧ (НЕПРЕРЫВНЫЙ)ДЛЯ ВСЕХ СТЕПЕНЕЙ

КОНДВ (КОН. ОТВОД ПР ОТ Ш)

ПЕР НА (КОНЕЦ)

;.........................ВЕРШИНА	8 ......................

' ВЕР (КОНЕЦ)

ВЫХ

’ КОНЕЦ

Поясним для примера описание первой вершины плана опера-
ции. Она называется ПОДВОД ПР К Ш. В ней запускается дви-
жение с контуром КОН. ПОДВОД ПР К Ш, который является па-
раметром операции. Условие, которое проверяется одновременно с
исполнением движения, называется КОНЕЦ ПР И ОЖИД. У него
один параметр — ВРЕМЯ ОЖИД, которому присваивается значение
формального параметра операции. ВЫДЕРЖКА ДЛЯ ПОДВОДА
ПР К Ш. Переход от этой вершины всегда происходит на вершину
СХВАТИТЬ Ш.

Файл описания типов. В этом файле описываются те имена, ко-
торые программист присваивает степеням подвижности робота, име-
на режимов, в которых может отслеживаться движение этих степе-
ней подвижности, и т. п.

На нижнем уровне автоматической сборочной системы всем сте-
пеням подвижности робота присвоены постоянные номера от 1 до
16 [4]. Обращаться к степеням подвижности можно по этим номе-
рам или ио именам, которые присваивает программист. Операторы
присвоения выглядят следующим образом:

; ИМЕНА СТЕПЕНЕЙ ПОДВИЖНОСТИ

СТЕПЕНЬ 1 - (ШР) ИЛИ (ПЛАТФОРМА ПР)

СТЕПЕНЬ 2 - (7ПР) ИЛИ (СХВАТ ПР)
СТЕПЕНЬ 16 - - (7ЛР) ИЛИ (СХВАТ ЛР)
СТЕПЕНЬ 9 -- (ИНСТРУМЕНТ)

Здесь степень свободы 1 получила два имени: 1ПР и ПЛАТФОР-
МА ПР (ПР — правая рука; ЛР — левая рука), степень 9 — имя
ИНСТРУМЕНТ (электрический инструмент робота, например элект-
рическая отвертка [1]).

Исполнение движения по каждой степени подвижности робота
может осуществляться в одном из нескольких режимов отслежива-
ния. Все режимы отслеживания имеют номера от 0 до 10. Так же,
как и для номеров степенен подвижности, режимам движения мо-
гут быть присвоены имена, удобные для работы. Операторы прис-
воения выглядят следующим образом:

; РЕЖИМЫ ОТСЛЕЖИВАНИЯ

РЕЖИМ 1 - (ОСНОВНОЙ)	V

РЕЖИМ 2 - (ЛИНЕЙНЫЙ ПОИСК) ИЛИ (ПОИСК)

РЕЖИМ 4- (СИЛОВОЙ)

РЕЖИМ 0 - (НЕ МЕНЯТЬ)

РЕЖИМ 10- (ОТКЛЮЧЕН) ИЛИ (ДВИГ. ОТКЛЮЧЕН)

Здесь режим движения 1 получает имя ОСНОВНОЙ, режим
2 - два имени - ЛИНЕЙНЫЙ ПОИСК и ПОИСК и т. д.

При запуске исполнения нового движения программная траек-
тория для каждой степени подвижности может начинаться одним из
четырех способов (типов начал). Типы начала имеют номера от 0
до 3. Операторы присвоения имен выглядят следующим образом:

;ТИПЫ НАЧАЛ

ТИП 0 - (НЕПРЕРЫВНЫЙ) ИЛИ (ИЗ IFR)
ТИП 1 - (АБСОЛЮТНЫЙ) ИЛИ (ИЗ IQ)
ТИП 2- (ОТНОСИТЕЛЬНЫЙ) ИЛИ (ИЗ IP)
ТИП 3 - (УСЛОВНЫЙ) ПЛИ (ИЗ IFRCP)

Движение манипулятора определяется последовательностью про-
граммных точек, через которые он должен пройти. Эта последова-
тельность называется контуром движения. Смысл информации, за-
писанной в точках контура движения, зависит от того, в каком
режиме этот контур будет исполняться [4]. Например, для степе-
ней подвижности, отслеживаемых в основном режиме, в контуре
хранится последовательность показаний датчиков положения для
программного движения каждой степени подвижности. Для режима
силового воздействия хранятся параметры, описывающие форму и
период отслеживаемого усилия и т. и. В зависимости от типа ин-
формации для хранения точки контура движения используется раз-
ное количество ячеек, меняется также и формат хранения информа-
ции в этих ячейках.

Каждому типу представления точки контура присваивается имя,
которое используется в файле описания контуров. Всего возможных
типов представления три — одна ячейка на точку, две ячейки на
точку и четыре байта на точку.

Операторы описания имен выглядят следующим образом:

; ФОРМАТ КОНТУРА

ФОРМАТ 1 — (ПОЗИЦИЯ) ИЛИ (1103) ИЛИ (КОЛЕБАНИЯ)
ФОРМАТ 2 -(МЯГКИЕ КОЛЕБАНИЯ)

ФОРМАТ 3 - (СИЛОВОЕ ВОЗДЕЙСТВИЕ) ИЛИ (СИЛА)

Каждый контур движения может быть исполнен двумя различ-
ными способами. В первом способе переход от отележивания оче-
редной точки, указанной в контуре движения, к следующей осуще-
ствляется после выполнения плана контроля условия, приписанного
этому движению, если этот контроль выработал код ответа 0.
В противном случае, либо если очередная точки — последняя в
контуре, исполнение движения прерывается. Во втором способе
движения отслеживается «бегущая» программная точка, формируе-
мая в результате линейной интерполяции между каждыми двумя
соседними точками, указанными в контуре. Исполнение движения
прерывается сразу же после выполнения плана условия. Способам
движения присваивается имя с помощью следующих операторов:

; СПОСОБ ДВИЖЕНИЯ

СПОСОБ 0 - ПОЗИЦИОННЫЙ

СПОСОБ 1 - КОНТУРНЫЙ

Описание контуров движения. В автоматической сборочной си-
стеме предусмотрена возможность хранения двухсот контуров дви-
жения. Каждый контур характеризуется своим номером и типом.
Тип контура указывает, какие степени подвижности используются
в данном движении и каков формат информации для хранения то-
чек контура.

В файле описания контуров движения хранятся имена, которые
программист присваивает контурам движения, а также описания
типов этих контуров. Приведем в качестве примера отрезок этого
файла:

КОНТУР 199 (РАЗЖАТЬ СХВАТ ПР)
ТИП (ПОЗИЦИЯ) ДЛЯ (СХВАТ ПР)
КОНТУР 194 (ОТВОД ПР) ИЛИ (ПОДЪЕМ ПР)
ТИП (ПОЗИЦИЯ) ДЛЯ (ШР), (2ПР), (ЗПР), (4ПР), (5ПР), 6ПР
КОНТУР 42 (ТЕСТОВОЕ ДВИЖЕНИЕ)

ТИП (ПОЗИЦИЯ) ДЛЯ (ЗПР), (СХВАТ ПР)
(СИЛА) ДЛЯ (4ПР)

В этом отрезке описано три контура движения с номерами 199,
194, 42. Контур 199 получил имя РАЗЖАТЬ СХВАТ ПР, контур
194 получил два имени — ОТВОД ПР и ПОДЪЕМ ПР. В контуре
199 задействована одна степень подвижности — СХВАТ ПР, ис-
пользуется формат хранения ПОЗИЦИЯ. В контуре 42 задейство-
вано три степени подвижности и используются два формата
хранения информации — ПОЗИЦИЯ и СИЛА.

Описание элементарных условий. В ходе исполнения автомати-
ческой сборки для перехода от движения к движению необходимо
контролировать наступление некоторых событий, например, истече-
ние заданного интервала времени, попадание показаний указанных
датчиков робота в заданную окрестность и т. п. Контроль за этими
событиями осуществляется при помощи специальных программных
модулей, входящих в состав модуля исполнения автоматической
сборки. Эти модули называются элементарными условиями. Каж-
дое элементарное условие имеет входные параметры, например, но-
мер датчика, радиус окрестности, длину интервала времени и т. п.
При обращении к элементарному условию выполняется однократная
проверка события, которое оно контролирует, и формируется вы-
ходной параметр — код ответа, указывающий, в каком состоянии
находится событие. Код ответа может принимать только целые зна-
чения (0, 1, 2,...). Каждому элементарному условию в автоматиче-
ской сборочной системе присваивается номер.	4

В файле описания элементарных условий описываются имена,
которыми программист обозначает элементарные условия, их пара-
метры и коды ответа. В качестве примера рассмотрим описание двух
элементарных условий:

ЭЛЕМЕНТАРНОЕ УСЛОВИЕ 7 (ВЗВОД СЧЕТЧИКА ВРЕМЕНИ) ИЛИ
(ВЗВОД Т)

ПАР (ЗАДЕРЖКА) ИЛИ (ИНТЕРВАЛ)

ВЫХОД О ВСЕГДА

ЭЛЕМЕНТАРНОЕ УСЛОВИЕ 9 (ОПРОС СЧЕТЧИКА ВРЕМЕНИ)

ИЛИ (ОПРОС Т)

ВЫХОД О (ВРЕМЯ ИСТЕКЛО) ИЛИ (КОНЕЦ ИНТЕРВАЛА)

ИЛИ (КОНЕЦ ЗАДЕРЖКИ)

ВЫХОД 1 (ВРЕМЯ НЕ ИСТЕКЛО)

Элементарное условие 7 получает два альтернативных имени —
ВЗВОД СЧЕТЧИКА ВРЕМЕНИ и ВЗВОД Т. Оно имеет один па-
раметр — ЗАДЕРЖКА (длина интервала времени). При выходе из
него коду ответа всегда присваивается ноль.

Элементарное условие 8 — ОПРОС Т — параметров не имеет, но
у пего дв-а возможных выхода. Выход с кодом ноль получает не-
сколько имен: ВРЕМЯ ИСТЕКЛО, КОНЕЦ ИНТЕРВАЛА, КОНЕЦ
ЗАДЕРЖКИ. Выход с кодом ответа один получает одно имя —
ВРЕМЯ НЕ ИСТЕКЛО.

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

В файле описания составных условий указываются имена, ко-
торые программист присваивает условиям, их параметрам и выхо-
дам (кодам ответа), и программируются планы проверки составных
условий.

Приведем пример плана контроля составного условия с именем
ОЖИДАНИЕ ВРЕМЕНИ:

УСЛОВИЕ (ОЖИДАНИЕ ВРЕМЕНИ) ИЛИ (ОЖ Т)
ПАР (ВРЕМЯ ОЖИДАНИЯ)

ВЕР (ЗАПУСК ТАЙМЕРА)

ВЫП (ВЗВОД Т)

ПАР (ИНТЕРВАЛ) = (ВРЕМЯ ОЖИДАНИЯ)

ПЕР НА (ТЕСТ Т)

ВЕР (ТЕСТ Т)
ВЫП (ОПРОС Т)
ПЕР ДЛЯ (ВРЕМЯ НЕ ИСТЕКЛО) НА (ТЕСТ Т)
{	ДЛЯ (ВРЕМЯ ИСТЕКЛО) НА (КОНЕЦ)

I .	’ ВЕР (КОНЕЦ)

ВЫХ

План контроля условия содержит три вершины, имеющие имена
ЗАПУСК ТАЙМЕРА, ТЕСТ Т и КОНЕЦ. У условия один входной
параметр (ВРЕМЯ ОЖИДАНИЯ) и одна выходная вершина (КО-
НЕЦ) . Поскольку выход один, то ему не присваивается имя. В вер-
шине ЗАПУСК ТАЙМЕРА выполняется элементарное условие
ВЗВОД Т с параметром, равным входному параметру условия.
После этого происходит переход на вершину ТЕСТ Т, в которой
выполняется проверка элементарного условия ОПРОС Т без пара-
метров. У этого элементарного условия два возможных кода ответа.
По коду ответа, названному ВРЕМЯ НЕ ИСТЕКЛО, происходит
переход на вершину ТЕСТ Т, по коду ответа ВРЕМЯ ИСТЕКЛО —
на вершину КОНЕЦ.

ЛИТЕРАТУРА

1.	Охоцимский Д. Е., Платонов А. К., Смольянов Ю. П., Гримайло С. И., Ка-
мынин С. С., Кугушев Е. И. Исследование многооперационной сборки с по-
мощью экспериментальной робототехнической системы — Ц кн.: Роботиза-
ция сборочных процессов. М.: Наука, 1985, с. 61—87.
2.	Смольянов Ю. П., Вахлии В. В., Волков А. В.. Гримайло С. И., Донцов В. Е.
Кугушев Е. И., Соколов С. М. Лабораторный макет сборочного робота.-/
В кн.: Роботизация сборочных процессов. М.: Наука, 1985, с. 88—102.

3.	Гримайло С. И. Программное обеспечение сборочного робота — В кн.: Ро-
ботизация сборочных процессов. М.: Наука, 1985, с. 103—122.

4.	Гримайло С. И., Кугушев Е. И., Ярошевский В. С. Цифровая следящая си-
стема для управления манипуляторами в процессе сборки: Препр. Ин-та
прикл. математики им. М. В. Келдыша АН СССР № 98. М., 1982. 28 с.

УДК 621.8

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

УСТРОЙСТВА КОНТУРНОГО УПРАВЛЕНИЯ УКМ-772
ДЛЯ ПРОМЫШЛЕННЫХ РОБОТОВ

А. Н. Домарацкий, В. В. Никифоров

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

В настоящей статье освещается опыт построения функциональ-
ного программного обеспечения устройства контурного управления
УКМ-772 промышленным роботом для дуговой электросварки.

Устройство УКМ-772 построено на базе использования микро-
ЭВМ «Электроника-60» (рис. 1). Интерфейсные блоки, обеспечива-
ющие взаимодействие процессора «Электроника-60» с внешними
устройствами, подключаются к общей шине «Электроники-60» либо
непосредственно, либо через адаптер, согласующий общую шину
«Электроники-60» с общей шиной специального вида.

Устройство контурного управления роботом для дуговой электро-
сварки должно обеспечивать сравнительно высокую точность дви-
жения рабочего органа по расчетной траектории (менее 1 мм), точ-
ность выдерживания требуемой ориентации (±5°) и контурной ско-
рости (±5%). Эти факторы существенно влияют на определе-
ние требований к алгоритмам, реализующим функции управления
(в том числе к алгоритму регулирования).

Существенным фактором, влияющим на требования к произво-
дительности процессора устройства числового программного управ-
Рис. 1. Общая структурная схема логического устройства УКМ-772

1 — процессор «Электроника-60»; 2 — оперативное запоминающее устройство; 3—
адаптер, согласующий общую шину А с общей шиной В; 4 — постоянное запоминаю-
щее устройство; 5 — фотосчитыватель; в — плата В1 интерфейса с пультом оператора
и фотосчитывателем; 7—пульт оператора; 8 — плата специального интерфейса с пуль-
том оператора; 9 — пульт обучения; 10— интерфейс с пультом обучения: 11 — таймер;

12 — цифроаналоговые преобразователи управления приводом робота; 13 — ввод пока-
заний кодовых датчиков робота; 14, 15 — соответственно ввод и вывод технологических
сигналов; 16 — контроллер накопителя на кассетной магнитной ленте; 17 — накопитель
на кассетной магнитной ленте; 13 — плата В21 интерфейса с перфоратором; 19 — пер-
форатор ПЛ-150

ления промышленного робота, является необходимость оперативного
расчета траектории движения рабочего органа непосредственно в
ходе воспроизведения программы управления роботом. Выполнение
интерполяции в рамках режима воспроизведения программы управ-
ления с решением прямой и обратной задач о положении механиз-
ма (например, «Универсал-15») в реальном времени может потре-
бовать использования процессоров с общей производительностью
порядка нескольких миллионов операций в секунду. В случае при-
менения устройства числового программного управления единствен-
ного процессора «Электроника-60» с производительностью 150 тыс.
операций в секунду приходится прибегать к использованию проме-
жуточной формы представления управляющей программы — рабо-
чей форме управляющей программы, которая в отличие от исходной
формы управляющей программы содержит не только узловые точки
представляемой траектории движения, но и информацию о резуль-
татах заблаговременно выполненной задачи интерполяции. Преобра-
зование исходной формы управляющей программы в рабочую фор-
му должно в таком случае осуществляться в рамках специального
режима работы системы (режим трансляции).

Число промежуточных точек расчетной траектории, координаты
которых представлены в рабочей форме управляющей программы,
может существенно превышать число узловых точек, представляе-
мых ее исходной формой. Это число может быть так велико, что
без принятия специальных мер объем внешней памяти, занимаемой
рабочей формой управляющей программы, окажется непомерно
большим. Кроме того, ограниченная пропускная способность канала
доступа к внешним устройствам может привести к тому, что воспро-
изведение такой рабочей формы управляющей программы (точнее,
управляющей программы, представленной в виде такой нерациональ-
но построенной рабочей формы) в реальном времени окажется во-
обще невозможным. Рациональное (существенно более компактное)
построение рабочей формы управляющей программы возможно по-
тому, что непосредственная запись значений координат всех про-
межуточных точек расчетной траектории обладает существенной из-
быточностью. В реальных ситуациях за счет несложных преобразо-
ваний «развернутой» (содержащей в явном виде значения координат
всех промежуточных точек) записи траектории движения рабочего
органа можно добиться сокращения объема памяти, требуемой для
представления траектории в несколько раз (и даже в несколько де-
сятков раз). При этом время обратного преобразования (в развер-
нутую форму) будет существенно меньше времени трансляции соот-
ветствующей исходной формы (на два-три порядка).

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

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

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

Со стороны модулей низшего иерархического уровня к ветвям
функциональных модулей примыкают контролируемые системой
внешние процессы (связь с внешними процессами осуществляется
Рис. 2. Алгоритмическая структура варианта функционального программного обеспе-
чения устройства управления УКМ-772

1—диспетчер режимов; 2 — дешифратор директив оператора; 3 — транслятор; 4 — ин-
терпретатор управляющей программы; 5 — интерпретатор технологических команд;

6— монитор экрана; 7 — диспетчер диалога; 8 — редактор текста; 9 — потактовый ин-
терпретатор примитивной формы управляющей программы; 10—14 — драйверы: техно-
логический пульта оператора, инженерного пульта, пульта обучения и привода соответ-
ственно; 15 — технологическое оборудование; 16—18 — пульт оператора, инженера,
обучения соответственно; 19— таймер

I — модуль А обращается к процедуре В; 11 — модуль А обращается к монитору В;
III — модуль А устанавливает значение флага, модуль В реагирует на это значение
в точках ветвления переходом на одну из альтернативных ветвей; IV— модуль А
открывает семафор, модуль В приостанавливается до открытия семафора и/или закры-
вает его

через внешние регистры системы, а также через систему внешних
прерываний).

Внешние процессы могут рассматриваться как отдельный (нуле-
вой) иерархический уровень. Алгоритмы функционирования этих
процессов определяются средствами, внешними по отношению к рас-
сматриваемой управляющей системе.

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

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

Первый иерархический уровень (низший уровень собственно
функциональных блоков системы) составляют драйверы внешних
устройств (процессов):

модули, реализующие алгоритмы регулирования (замыкают кон-
тур управления положением манипулятора);

модули индикации информации на табло пульта управления ро-
ботом;

модули ввода информации с клавиатуры пульта;

модули связи со сварочным оборудованием.

Драйвер привода активизируется по тактовым сигналам аппарат-
ного таймера с частотой несколько десятков герц (эта частота вы-
бирается в зависимости от требований точности реализации расчет-
ной траектории движения рабочего органа, соотношения между
объемом вычислений, требуемых для выполнения одного цикла ра-
боты алгоритма регулирования, и производительностью процессора,
выделенного для реализации этих вычислений).

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

Драйвер технологических процессов отвечает за своевременный
обмен информацией со сварочным оборудованием — обработку пре-
рываний, формирование сигналов, ввод—вывод значений технологи-
ческих признаков, формируемых на внешних (технологических) ре-
гистрах.

Драйверы пультов (оператора, настройщика, инженера) обеспе-
чивают формирование последовательности сообщений, поступающих
с пультов, а также вывод на индикационные табло сообщений, фор-
мируемых системой в ходе ее функционирования.

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

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

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

Диспетчер диалога выполняет синтаксический анализ введенной
строки, формирует внутренние коды вводимых сообщений. При вы-
воде сообщений диспетчер диалога формирует в буферной структу-
ре данных требуемую строку.

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

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

Четвертый (старший) иерархический уровень содержит модули
переключения режимов функционирования устройства.

При разработке программного, обеспечения устройства управле-
ния УКМ-72 широко применялась техника реализации модулей,
подсистем (и вариантов системы в целом) в виде асинхронных
программ, т. е. в виде совокупности вычислительных процессов,
внутренне замкнутых по управлению (и взаимодействующих друг
с другом за счет использования различных видов информационных
связей). Такие процессы иногда называют потоками.

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

Структура основных сигнальных связей, представляемых обра-
щениями к процедурам и мониторам (мониторным процедурам),
а также модификациями значений специальных сигнальных пере-
менных — логических признаков (флагов) и семафоров, отражена
на рис. 2. Сигнальные связи типа флагов и процедур реализуются
аппаратными средствами микропроцессора «Электроника-60».

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

В программном обеспечении устройства управления УКМ-772
реализована идея децентрализованного построения системы (в смыс-
ле отсутствия какого-либо привилегированного процесса). Осущест-
вление всех типов сигнальных взаимодействий в определенном
смысле возлагается на сами взаимодействующие модули (при этом
взаимодействующие модули могут обращаться к глобальным проце-
дурам, выражающим алгоритмы программной реализации нужных
сигнальных взаимодействий).

Разработка и испытания различных вариантов системы програм-
много обеспечения устройства управления УКМ-772 показали, что
изложенные выше принципы структурирования и реализации про-
граммного обеспечения для промышленных роботов достаточно ра-
циональны и эффективны. Следование структурным принципам
(и принципам реализации), учитывающим перспективу развития
программного обеспечения промышленных роботов, существенно
расширяет возможности использования разработанных программных
средств (в виде комплекта программных модулей и документов) в
новых системах.

УДК 007.52

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТА СУР-25
ДЛЯ ДУГОВОЙ СВАРКИ

С. М. Григорович, В. И. Кавинов, А. Е. Клепов,
К. В. Самвеляп, II. Ю. Юрии

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

В современном производстве сварные соединения обеспечивают
большую технологичность и прочность изделий. Это особенно спра-
ведливо для корпусных производств, когда сварка достигает 50—
70% общей трудоемкости изготовления изделий. Для таких произ-
водств автоматизация сварки дает большой экономический эффект.
Кроме того, корпусное производство характеризуется, как правило,
относительной мелкосерийностью и частой сменой типов сваривае-
мых деталей, а следовательно, особое значение приобретают вопро-
сы перепрограммирования и переналадки автоматизированного
участка.

При изготовлении корпусов различных изделий швы, имеющие
сложную пространственную конфигурацию, составляют 70—80% об-
щей протяженности сварных соединений. Применение робота на
подобных операциях возможно и целесообразно в силу того, что
основное его назначение и состоит в перемещении объектов (в дан-
ном случае сварочной горелки) по сложным пространственным тра-
екториям. Для таких работ робот является, пожалуй, единственным
средством автоматизации.

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

Отправной точкой проектирования программного обеспечения
системы управления робота для дуговой сварки являются требова-
ния, обусловленные самим процессом дуговой сварки, основными
из которых можно назвать следующие:

точность проведения горелки вдоль сварного шва в пределах
±1 мм;

необходимо обеспечить при перемещении манипулятора постоян-
ство скорости горелки вдоль шва в пределах ±5%;

поддержание параметров дуги (напряжение и ток) на заданном
уровне, изменение которого по программе возможно как для раз-
личных участков, так и в пределах одного участка шва;

надежное зажигание дуги и ее гашение на основе так называе-
мой процедуры заварки кратера;

для заливки объемных швов обеспечение режима поперечного
колебания горелки с изменяемыми частотой и амплитудой.

Анализ конкретных корпусных производств позволил определить
первоочередные объекты автоматизации и ряд дополнительных тре-
бований к роботу.

Так как изделия, процесс изготовления которых подлежит авто-
матизации, имеют сложную пространственную конфигурацию свар-
ных швов, применение универсального манипулятора является не-
пременным условием автоматизации технологического процесса
(в противовес сварочным автоматам).

Протяженность сварочного шва, заварка которого выполняется
за один проход без гашения дуги, приблизительно 1,0—1,5 м. Об-
щая протяженность швов на одном изделии составляет 10—12 м.
Это требование определяет как параметры сварочного оборудования,
так и свойства системы управления (такие, как объем оперативной
памяти, быстродействие и т. д.).

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

Все эти требования и легли в основу проектирования аппарат-
ных и программных средств промышленного робота СУР-25.

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

В качестве основного рабочего органа применен манипулятор
модульной конструкции РПМ-25. Его грузоподъемность и манипу-
ляционные возможности позволяют доставить горелку с необходи-
мым оборудованием в произвольной ориентации в пределах рабочей
зоны, обусловленной требованиями изготовляемой продукции. Для
обеспечения требуемой точности позиционирования манипулятор
снабжен 15-разрядными кодовыми датчиками.

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

Сварочное оборудование обеспечивает управление от ЭВМ режи-
мами сварки (током и напряжением), частотой и амплитудой меха-
нического колебателя горелки, а также вырабатывает ответные сиг-
налы для ЭВМ, характеризующие работу сварочного оборудования.

Для управления промышленным роботом в рамках агрегатиро-
ванных систем управления роботов и станков с числовым програм-
мным управлением была разработана система управления АС-2601
(рис. 1).

В качестве управляющей ЭВМ использована микро-ЭВМ «Электро-
ника-60». К ее шипе подключены устройства ввода/вывода, пульт
управления, оперативное запоминающее устройство (ОЗУ) с объ-
емом 28К слов, таймер и модуль сопряжения с шиной СМ-3. Для
подключения всех периферийных устройств, обеспечивающих управ-
ление оборудованием в системе, использован протокол обмена шины
СМ-3. Через модуль.связи шин процессор Ml осуществляет управ-
ление шиной СМ-3. Для подключения системы приводов манипуля-
тора и сварочного .оборудования применяются как стандартные в
агрегатированной системе модули ввода и вывода сигналов, так и
Рис. 1. Структура системы управления АС-2601

Специально разработанные модули управления движением степеней
подвижности манипулятора.

В состав сварочного оборудования включен датчик касания. Его
принцип действия заключается в том, что на электродную проволо-
ку подается высоковольтное напряжение от специального источни-
ка, который выдает сигнал ЭВМ в момент возникновения слаботоч-
ной дуги. Координаты объекта при этом определяются по показа-
ниям кодовых датчиков степеней подвижности манипулятора.

Как видно из приведенного состава аппаратных средств, в си-
стеме нет емкого внешнего накопителя. Поэтому для обеспечения
выполнения требований к протяженности шва необходимо позабо-
титься о методе сжатия информации о траекториях движения мани-
пулятора для ее размещения в оперативной памяти ЭВМ. Учиты-
вая, что быстродействие микро-ЭВМ «Электроника-60» ограничено,
был применен следующий подход обеспечения контурных движений
манипулятора РПМ-25.

Непрерывное движение манипулятора вдоль заданной траекто-
рии обеспечивается выдачей уставок положения- степеней подвиж-
ности с частотой, превышающей верхнюю границу полосы пропуска-
ния следящего привода (10—20 Гц). Расчет уставок в реальном
времени осуществляется программой линейной интерполяции на
основании последовательности координат опорных точек траектории
(хранится в памяти ЭВМ в обобщенных координатах манипулято-
ра — показания кодовых датчиков).

На основе этого представления определяются и остальные эле-
Рис. 2. Элементы траекторий движения сварочной горелки

Ti—эталонная траектория корневого шва; Та — траектория корневого шва; Т3 —тра-
ектория первого прохода; УТ — узловая точка; ОТ — опорная точка; БТ — базовая
точка; ТП — точка подхода; ПТ — промежуточная точка; ТК — точка касания; ВК —
вектор коррекции точки подхода; НИ—направление подхода

менты, необходимые для описания траекторий сварных швов
(рис. 2).

Штриховой линией изображено положение узла при обучении,
а сплошной — при выполнении сварки. Траектория корневого, шва
представлена последовательностью опорных точек. Изображены
также узловые точки, предназначенные для описания траекторий
с помощью отрезков известных кривых (прямые, дуги окружности).
Расчет истинных траекторий движения сварочной горелки осущест-
вляется по имеющемуся эталонному представлению корневого шва
и двум векторам — вектору смещения положения узла (ВС) и век-
тору смещения на проход при многопроходных швах (ВКП).

Показаны также траектории манипулятора при измерении поло-
жения узла. На основании запомненной информации, которая полу-
чена при обучении в виде координат точек касания электрода к
трем плоскостям узла и координат точек касания этих же плоско-
стей при сварке, рассчитывается вектор смещения узла.
Таблица 1

Код	Наименование операции	Код	Наименование операции
MOVE	Перемещение в точку	CRATR	Заварка кратера
LOOP	Перемещение по кон- туру	MTOUCH	Измерение положения узла
WELD	Заварка шва	NPASS	Заварка второго про-
FIRE	Зажигание дуги	PREPR	хода  Подготовка сопла к сварке

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

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

В результате анализа технологии изготовления различных дета-
лей были определены технологические операции и разработаны ал-
горитмы их выполнения. Список этих операций представлен в
табл. 1.	•

Состав операций обеспечивает быстрые транспортные перемеще-
ния сварочной горелки к различным участкам сварки, контурные
перемещения вдоль заданной траектории с возможностью измерения
в пределах различных участков скорости движения вдоль траекто-
рии и сварочных параметров. Для обеспечения гибкости робота и
расширения класса решаемых им задач процессы зажигания дуги
и заварки кратера выделены в отдельные операции, что позволяет
«сшивать» несколько следующих друг за другом участков и осуще-
ствлять настройку процесса заварки кратера на конкретные условия
окончания шва. Операции «Измерение положения узла» и «Завар-
ка второго прохода» обеспечивают коррекцию исходной траектории
движения сварочной горелки при смещении узла относительно по-
ложения при обучении и при реализации многопроходных швов.
Автоматическая очистка и опрыскивание защитным покрытием соп-
ла сварочной горелки предназначены для обеспечения длительной
работы робота без вмешательства человека-оператора.

Любое задание на работу роботу при таком подходе будет пред-
Таблица 2

Наименование действия	Символ, ВВОДИ- МЫЙ опе- ратором	Наименование действия	Символ, ВВОДИ- МЫЙ one ратором
Ручное управление	р	Корректировка ТХЗ	м
Формирование ТХЗ (обу-	ф	Исключение ТХЗ	Уга
чение)		Распечатка ТХЗ	Ли
Сброс ТХЗ	с	Диагностика системы	Дга
Копирование ПО па п/л	п	Контроль	Кга
Ввод ТХЗ с п/л	т	Останов	
Вывод ТХЗ на п/л	Зга		
Выполнение ТХЗ	Ви		

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

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

Список действий робота СУР-25 приведен в табл. 2.

Функциональное назначение действий робота ясно из их назва-
ния. Среди них есть основные, обеспечивающие такие режимы ра-
боты робота, как обучение — формирование технологического зада-
ния (ТХЗ), выполнение и корректировку технологического задания,
и сервисные, осуществляющие разнообразные вспомогательные ре-
жимы. Различные режимы выполнения технологического задания
предписываются дополнительной информацией в соответствующей
команде. Режим обучения обеспечивает в диалоге задание последо-
вательности операций и необходимой для них информации при руч-
ном управлении манипулятором. Функциональная схема программ-
ного обеспечения представлена на рис. 3.
Включение питания устройства управления

Рис. 3. Функциональная схема программного обеспечения робота СУР-25

t После запуска системы блок инициализации осуществляет на-
s’ чальпую установку всех необходимых массивов, спрашивает состоя-
[ ние внешних устройств и в диалоге с оператором настраивает изме-
| няемые параметры системы. После завершения работы этого блока
I управление передается блоку обработки команд оператора.

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

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

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

I Программное обеспечение робота для дуговой сварки СУР-25
может быть охарактеризовано следующим образом. Общий объем
памяти, занимаемый программным обеспечением, составляет 16К
слов. Общее количество программных модулей составляет 120 мо-
дулей. Из них 70 модулей, относящиеся к системной части, обес-
печивают функционирование робота на различных режимах, а 50
модулей, составляющих прикладное математическое обеспечение,
выполняют кинематические расчеты при изменении положения узла,
коррекции траекторий и т. д. Соотношение объемов памяти, зани-
маемых системной и прикладной частями, составляет примерно один
к- одному. Средства, обеспечивающие диалоговый режим с челове-
ком-оператором, составляют приблтгайтельно 15% объема памяти
системной части программного обеспечения. Объем адресуемой опе-
ративной памяти, остающейся для размещения технологических за-
даний, составляет 12К слов. Это позволяет запомнить 760 кадров
технологического задания, что составляет приблизительно 15 м мно-
гопроходимых швов.

Проведенная разработка программного обеспечения робота СУР-25
позволяет сделать заключение о том, что система управления кон-
турными движениями манипулятора антропоморфной кинематики,
предназначенная для широкого класса сварочных работ с возмож-
ностью формирования и выполнения технологических заданий при
развитом диалоге между роботом и человеком-оператором и осна-
щенная элементарными средствами адаптации к условиям рабочего
пространства, представляется в известном смысле предельной по
сложности для аппаратных средств, использующих ЭВМ класса
«Электроника-60». Подобные системы, по-видимому, могут образо-
вать самостоятельный класс в ряду систем управления промышлен-
ных роботов и занимать ступень между позиционными системами
управления и адаптивными системами управления, наделенными эф-
фективными средствами описания и анализа рабочего пространства
робота.

$ $ $

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

Описание процесса сварки с помощью технологического задания,
состоящего из операций, специфических для сварочного производст-
ва, позволяет существенно облегчить работу оператора при обуче-
нии робота и сократить объем информации, вводимой оператором
при этом.

Диалоговая форма общения между роботом и человеком-опера-
тором, реализованная в программном обеспечении системы управле-
ния, помогает оператору в выборе требуемого от него действия и
необходимой при этом информации.
УДК 007.52:62—52	,

СИСТЕМА УПРАВЛЕНИЯ

СВАРОЧНЫМ РОБОТИЗИРОВАННЫМ КОМПЛЕКСОМ
С ИСПОЛЬЗОВАНИЕМ МИКРО ЭВМ

Ф. Н. Кисилевский, В. Т. Тертышный, Н. Р. Швыдкип

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

В Институте электросварки имени Е. О. Патона АН УССР раз-
работана система управления робототехническим комплексом для
дуговой сварки, позволяющая в полной мере использовать преиму-
щества нового вида оборудования в сварочном производстве. Систе-
ма осуществляет управление комплексом оборудования, в который
входят:

манипулятор сварочного инструмента, имеющий пять степеней
подвижности с электроприводами постоянного тока;

манипулятор изделия с двумя степенями подвижности, приводи-
мыми в движение электроприводами постоянного тока;

комплект сварочного оборудования (источник . сварочного тока,
механизм подачи присадочной проволоки, водоохлаждаемая горелка,
газоаппаратура, механизм очистки и смазки горелки, механизм
обрезки проволоки и т. п.).

При разработке системы основное внимание было уделено реше-
нию следующих задач:

высокие качественные показатели управления (точность управле-
ния движением, адаптация к неточностям сборки и установки сва-
риваемых изделий);

максимальная надежность функционирования комплекса;

простота обслуживания и эксплуатации комплекса;

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

Функциональная структура системы управления включает три
иерархических уровня:

планирования и координации;

управления элементарными операциями в реальном масштабе
времени;

сервоуправления исполнительными устройствами.

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

Структурная схема системы приведена на рисунке.

Блок планирования и координации (БПК) включает, помимо
микропроцессора и модулей запоминающих устройств (ОЗУ — опе-
ративное и ППЗУ — программируемое постоянное), следующее пе-
риферийное оборудование: центральный пульт управления (ЦПУ);
выносной пульт оператора (ПО); устройство внешней памяти; устрой-
ство параллельного обмена для связи с внешним технологическим
оборудованием.

Обмен данными между микропроцессором и периферийными
устройствами осуществляется с помощью общей шины.

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

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

В качестве устройства внешней памяти в системе управления
использован накопитель на гибких магнитных дисках (НГМД).
Основное назначение устройства внешней памяти в системе — хра-
нение библиотеки программ технологического процесса. Однако
в сложных модификациях системы возможно хранить на магнитном
носителе и часть системных программ, организовав оверлейный
режим работы программного обеспечения.

Блок управления манипуляционной системой (БУМ) состоит из
микропроцессора с набором модулей памяти. Связь между блоками
БПК и БУМ осуществляется через устройство параллельного обмена.

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

При использовании в составе манипуляционной системы роботи-
зированного комплекса манипулятора изделия с цикловым управле-
нием в состав системы управления включается модуль циклового
управления манипулятором изделия (МУМИ), который также свя-
зан с БУМ через общую шину.

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

Широкий набор функций системы управления позволяет эффек-
тивно организовать управление технологическим процессом дуговой
сварки.

При разработке системы управления особое внимание было уде-
лено важнейшему этапу подготовки роботизированного комплекса
к выполнению технологического процесса — составлению програм-
мы технологического процесса. Система управления обеспечивает
возможность составления программы технологического процесса как
в режиме ОБУЧЕНИЕ, так и в режиме ВНЕШНЕЕ ПРОГРАМ-
МИРОВАНИЕ. И в том и в другом случае она составляется на
специально разработанном языке ROWEL.

При работе в режиме ОБУЧЕНИЕ средством взаимодействия
оператора с системой является выносной пульт обучения — пульт
оператора, по командам от которого система управления управляет
перемещением манипуляционной системы и формирует элементы
программы технологического процесса. Для облегчения работы опе-
ратора при ручном перемещении манипулятора предусмотрена воз-
можность выбора желаемой системы координат перемещения.
Помимо общепринятой системы координат звеньев манипулятора,
оператор может использовать опорную систему координат или
локальную систему координат.

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

При работе в опорной системе координат те же клавиши пульта
обучения соответствуют осям опорной неподвижной декартовой си-
стемы координат, связанной с выбранной базовой точкой манипуля-
ционной системы. При этом возможно как последовательное плоско-
параллельное перемещение вдоль осей X, Y, Z, так и изменение
ориентации инструмента путем поворота вокруг проходящих через
точку сварки вертикальной (движение 4) или горизонтальной и
перпендикулярной оси горелки (движение В) осей. Важно отме-
тить, что система управления обеспечивает полную развязку между
линейными и ориентирующими движениями, т. е. движения А и В
выполняются с сохранением положения рабочей точки инструмента
(точки сварки).

При работе в локальной системе координат клавиши пульта обу-
чения инициируют движение относительно текущего положения
сварочного инструмента: клавиши «Z» — вдоль оси сварочного ин-
струмента («к изделию» при направлении движения «+» и «от из-
делия» при направлении движения «—»); а клавиши «X» и «У»—
перпендикулярно оси инструмента. Ориентирующие движения в
локальной системе координат совпадают с аналогичными движе-
ниями в опорной системе координат.

Указанные способы ручного управления перемещением манипу-
лятора наряду с возможностью выбора скорости («высокая», «низ-
кая», «шаговая» с шагом 0,5 мм) позволяют оператору с минималь-
ными затратами времени установить инструмент в любое требуемое
положение.

Траектория перемещения сварочного инструмента записывается
в программу технологического процесса в виде координат опорных
точек типовых элементов — прямой, дуги окружности или замкну-
той окружности. Это избавляет оператора от изнурительного про-
цесса «обучения» робота всем промежуточным точкам траектории.

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

Эта же особенность системы управления позволяет формировать
программы технологического процесса в режиме ВНЕШНЕЕ ПРО-
ГРАММИРОВАНИЕ, т. е. в символьной форме с клавиатуры цент-
рального пульта управления, используя в качестве основы чертеж
изделия и технологическую картину. В языке ROWEL предусмотре-
ны специальные операторы для задания технологических парамет-
ров — скорости сварки, тока, напряжения дуги, значений времен-
82
ных интервалов циклограммы процесса сварки, характеристик коле-
баний и т. п. Кроме того, программа технологического процесса
может создаваться «комбинированным» способом: траектория пере-
мещения — в режиме ОБ^ ЧЕНИЕ, а технологическая и управляю-
щая информация — в режиме ВНЕШНЕЕ ПРОГРАММИРОВАНИЕ.

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

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

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

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

Сформированная' и отлаженная программа используется для
управления технологическим процессом.

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

полный начальный контроль (тестирование) аппаратных средств
системы управления (процессоров, запоминающих и периферийных
устройств) при включении питания;
текущий контроль работы процессора и состояния системных
программ при работе комплекса параллельно и независимо от вы-
полнения основных функций;

непрерывный контроль правильности отработки заданной траек-
тории перемещения манипуляционной системы;

блокировку управляемого оборудования при возникновении не-
предусмотренных ситуаций и передачу в этом случае управления
оператору.

Как показывает отечественный и зарубежный опыт, эффектив-
ное использование робототехнических комплексов в сварочном про-
изводстве возможно только при наличии средств автоматической
коррекции исходной программы технологического процесса в соот-
ветствии с реальными условиями, т. е. средств адаптации. В раз-
работанной модели системы управления реализован алгоритм на-
чальной или установочной адаптации, сущность которого состоит в
корректировании траектории перемещения рабочего органа в соот-
ветствии с реальным положением сварного узла в рабочем про-
странстве манипулятора. Корректирование осуществляется путем
комбинации преобразований параллельного переноса и поворота,
причем параметры корректирующего оператора определяются в ре-
зультате сравнения положения свариваемого изделия и изделия, по
которому производилось программирование. Идентификация поло-
жения изделия выполняется при помощи процедуры «ощупывания»
трех плоскостей изделия, которая программируется в процессе под-
готовки программы технологического процесса. Для этого в языке
ROWEL предусмотрен ряд специальных операторов.

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

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

Разработанная модель системы по замыслу должна быть базо-
вой для создания гаммы модификаций. При этом переменными
элементами исполнения могут быть как аппаратные узлы, так и
модули системных программ. Возможные модификации системы
представлены в таблице.
Модифицируемая характеристика	Вариант исполнения	Что изменяется в базовой модели
Привод звеньев мани- пулятора  Используемый датчик обратной связи по по- ложению звена	Привод постоянного тока, шаговый привод, электрогпдропрпвод инкрементный, абсо- лютный	МУСП  МУСП
Кинематическая схема манипуляционной си- стемы	прямоугольная, сфери- ческая, цилиндриче- ская, антропоморфная	Программный модуль пре- образования координат в системных программах блока БУМ
Количество управля- емых сварочных робо- тов в составе комп- лекса	индивидуальное, груп- повое (до трех)	Количество блоков БУМ и БУСО, подключаемых к одному ВПК
Организация библио- теки программ техно- логического процесса	локальное, централизо- ванное	Замена устройства внеш- ней памяти па блок пере- дачи данных
Функциональные воз- можности	активная, пассивная.	Часть программных моду- лей ВПК вводится в со- став программного обес- печения БУМ; исключа- ются ПО, ЦПУ; вводятся индикационная панель, блок передачи данных

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

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

* * *

На базе существующей модели системы возможно создание гаммы
модификаций с более или менее широким набором функций.

Архитектура системы позволяет наращивание функций в на-
правлении более глубокой адаптации к неопределенности производ-
ственной среды.

Опытный образец системы управления демонстрировался в со-
ставе советско-болгарского роботизированного комплекса на Плов-
дивской ярмарке 1980 г. и награжден Золотой медалью ярмарки.

УДК 007.52

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ

ДЛЯ ДУГОВОЙ И ЭЛЕКТРОННО-ЛУЧЕВОЙ СВАРКИ
С ПРЯМОУГОЛЬНОЙ СИСТЕМОЙ КООРДИНАТ
И ДИСКРЕТНЫМ ПРИВОДОМ ДВИЖЕНИЯ

Ю. К. Цыганков

Робот для дуговой или электронно-лучевой сварки представляет
собой сложный комплекс оборудования, в который входят механи-
ческая манипуляционная система сварочного инструмента (свароч-
ная горелка или электронно-лучевая пушка), системы приводов
каждого движения манипуляционной системы, технологическое обо-
рудование (источники сварочного тока, механизмы подачи свароч-
ной проволоки, аппаратура газозащиты и т. п.), система управле-
ния всем оборудованием и программное обеспечение. В состав
оборудования могут входить и другие системы, расширяющие тех-
нологические возможности робота, например: система технического
зрения для выявления отклонений положения свариваемых соеди-
нений па изделии от заданных по чертежу или в процессе обуче-
ния; загрузочные и транспортные устройства, автоматизирующие
процессы установки свариваемого изделия на рабочую позицию и
снятия сваренного изделия, транспортировку изделия до и после
сварки. Один из вариантов технических средств робототехнического
комплекса (РТК) показан на рис. 1.

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

моугольной системе координат, должен иметь как минимум пять
независимых движений: три по координатам х, у, z и два угло-
вых — <р и 7 (рис. 2) [1].

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

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

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

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

Для упрощения задачи управления движением инструмента в
манипуляторе применен механизм ориентации, который обеспечи-
вает поворот сварочного инструмента вокруг точки сварки, т. е. при
ориентации сварочного инструмента точка сварки остае!ся пе-
Рис. 2. Схема размещения управляемых и информационных элементов на манипуля-
торе сварочного инструмента

Стрелки — направления перемещения звеньев; СИ — сварочный инструмент (сварочная
горелка); X, Y, Z — двигатели, приводящие в движение по соответствующим ^коорди-
натам звенья манипулятора; Ф, Г — двигатели ориентации сварочной горелки (поворо-
та и наклона соответственно); 1 — ограничитель перемещений в отрицательном на-
правлении по координате х; 2 — ограничитель перемещений в положительном направ-
лении по координате х и датчик точного отсчета; 3 — датчик грубого отсчета по коор-
динате х; 4 — ограничитель перемещений в отрицательном направлении по координате
у; 5, в — датчики точного и грубого отсчета соответственно по координате у; 7— огра-
ничитель перемещений в положительном направлении по координате у; 8, 10 — огра-
ничители перемещений соответственно в положительном и отрицательном направлениях
по координате z; 9 — датчик точного отсчета по координате z; 11, 12 — датчики и
ограничители перемещений по координатам ориентации (по координатам Г и Ф соот-
ветственно) ; 13 — подающий механизм сварочной проволоки

подвижной. Траектория точки сварки рассчитывается по трем коор-
динатам х, у, z, а ориентация по координатам <р и у не изменяет
положения точки сварки, т. е. они являются дополнительными,
определяющими направление сварочного инструмента.

Управление сварочным оборудованием сводится к заданию уста-
новленных режимов работы и поэтому не представляет сложности,
так как выполняется перед началом сварки, а в процессе сварки
остается неизменным.

Таким образом, объект управления — сварочный робот с обору-
дованием, расширяющим его технологические возможности,— пред-
ставляет собой сложную систему.

Микро-ЭВМ позволяют создавать системы управления с разны-
ми функциональными возможностями, для работы с различными
РТК путем настройки программного обеспечения или замены про-
граммных модулей практически без изменения состава технических
средств системы управления [1—9].
Рис. 3. Структурная схема программных модулей системы управления РТК для дуго-
вой сварки

При создании программного обеспечения РТК для дуговой свар-
ки необходимо учитывать особенности технологического процесса,
технические характеристики используемого оборудования и предъ-
являемые к нему требования:

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

высокий темп обработки информации (особенно при наличии
сенсорных устройств);

ограниченные ресурсы микро-ЭВМ;

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

обеспечение высокой надежности, так как сбой может привести
к аварии.

В общем случае программное обеспечение РТК состоит из двух
независимых подсистем (рис. 3):

программное обеспечение для реализации обучения робота;

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

Программное обеспечение для подготовки технологических про-
грамм (программы сварки изделия) методом обучения в процессе
их отработки не используется. Это обстоятельство позволяет разра-
батывать программные модули для каждой из указанных подсистем
независимо друг от друга.

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

Основное требование к системе обучения — сформировать техно-
логическую программу сварки (массив кадров) с учетом ограниче-
ний, накладываемых ресурсами микро-ЭВМ и технологическим про-
цессом.

Состав программных модулей подсистемы зависит от конкрет-
ных требований, связанных с удобством подготовки технологиче-
ских программ и составом оборудования РТК.

Подсистема отработки готовых программ должна обеспечивать
работу в реальном масштабе времени всего оборудования, входяще-
го в РТК.

Основным звеном РТК является сварочный робот, который вы-
полняет главную технологическую операцию — сварку.

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

Ориентация сварочной горелки (наклон и вращение) развязана
от основных движений (по осям X, Y, Z), т. е. не изменяется поло-
жение точки сварки [1, 10].

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

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

На рис. 3 показан состав программных модулей для системы
управления РТК, в который входит робот с дискретным приводом.

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

дискретного двигателя

задается частотой следования управляющих

импульсов.

Рассмотрим основные характеристики системы управления, ко-

торые обеспечивают программные

программы па микро-ЭВМ

данной

модули подсистемы
«Электроника-60».

отработки за-

Частотное управление шаговым двигателем в диапазоне свароч-
ных скоростей осуществляется изменением частоты от 0 до 1000 Гц.

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

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

Дискретный двигатель обеспечивает маршевые перемещения на
иастотах до 16 кГц, но из-за ограниченного быстродействия микро-
ВВМ скорость перемещения сразу по трем координатам лежит в
рределах до 4 кГц, а при движении только по одной координате —
h пределах 12—14 кГц в зависимости от исполнения конкретной
микро-ЭВМ «Электроника-60».

Прямое цифровое управление позволило существенно упростить

аппаратную часть системы управления и свести ее в основном к ре-
гистрам данных и состояния (например, блока параллельного обме-
на и стандартного набора микро-ЭВМ «Электроника-60»), работаю-
щих на элементы согласования уровней с нагрузкой (коммутатор
дискретного привода).

Объем памяти, необходимый для программных модулей, интер-
претирующих отрабатываемый кадр, осуществляющих интерполя-
цию и выдачу управляющих сигналов на дискретный привод, не
превышает 1,5 К слов. С модулями реакции па аварийные ситуации
и массивом кадров общий объем программы отработки не превышает
4К слов.

К преимуществам применения дискретного привода можно от-

нести:

одновременность выдачи управляющей информации прямо в
цифровой форме на все двигатели;

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

отсутствие программных модулей приема информации с датчи-
ков положения координат и расчета рассогласования;

отсутствие погрешностей, вызванных преобразованиями инфор-
мации из аналоговой формы в дискретную и наоборот;

существенное сокращение общего объема программных модулей;

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

простота осуществления коррекции траектории по информации
от сенсорных систем путем суммирования выдаваемых по координа-
там импульсов на данном шаге с поправкой.

В описанной системе управления сенсорная система не испыты-
валась. При ее наличии будет обеспечен контроль положения сва-
рочного инструмента относительно изделия. Таким образом, систе-
ма становится замкнутой.

К недостаткам такого технического решения можно отнести:
невозлгожность реализации программным путем плавных движе-
ний при низких частотах управления (малых скоростях движения
манипулятора);

затруднительность, а при больших скоростях невозможность реа-
лизации программным путем характеристик разгона и торможения;

отсутствие контроля положения рабочего органа в процессе от-
работки в разомкнутых системах, что требует дополнительных
устройств для предотвращения аварийных ситуаций, связанных с
отказами дискретного привода: установка датчиков наезда на пре-
пятствие, установка датчиков ограничения перемещения по всем
движениям (это приводит к необходимости разработки программных
модулей обработки информации с этих датчиков и принятия реше-
ний при аварийных ситуациях);

жесткие требования' к быстродействию микро-ЭВМ при прямом
цифровом управлении дискретным приводом (например, при часто-
те выдачи импульсов па двигатель 16 кГц резерв времени для
микро-ЭВМ составляет всего 62,5 мкс в сравнении с диапазоном
1—20 мс для систем с аппаратной развязкой; такое ограниченное
время не позволяет использовать систему прерываний— реакция на
прерывание в микро-ЭВМ «Электроника-60» составляет порядка
200 мкс — при организации программного обеспечения модулей вы-
дачи и увеличивает их количество, так как для больших скоростей
приходится создавать специальные модули; в процессе работы таких
модулей система не может реагировать ни на какие внешние собы-
тия, кроме аварийных; при возникновении аварийного события во
время отработки на большой скорости процесс движения заканчи-
вается некорректно, т. е. система теряет сведения о местоположении
рабочего инструмента и восстановить ее можно только при вмеша-
тельстве оператора);

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

Из всех педостатков отсутствие реакции системы на все внешние
события, не связанные с отработкой движения, кроме аварийных,—
самый существенный, так как при быстрых перемещениях время
таких участков, на которых система не реагирует на другие запро-
сы, зависит от пути перемещения и может составлять несколько
секунд.
Рнс. 4. Укрупненный алгоритм работы црн обучений

На рис. 4 и 5 изображены укрупненные алгоритмы подсистемы
обучения и отработки соответственно.

Выдача воздействия на двигатели и запись новой информации
об очередном шаге — асинхронные процессы. Расчет очередного
шага интерполяции начинается сразу же после выдачи управляю-
щей информации для реализации предыдущего шага. Для нормаль-
ной работы программных модулей интерполятора и модуля выдачи
необходимо выполнение следующего условия:

т. е. скорость расчета очередного шага должна быть больше ско-
Рис. 5. Укрупненный алгоритм работы при отработке задания

рости выдачи на двигатель (скорость выдачи на двигатель опреде-
ляется таймером и лежит в диапазоне от 0 до 16 кГц).

Скорость работы интерполятора зависит от числа одновременно
срабатываемых координат, при этом сохраняется зависимость

где к — количество одновременно отрабатываемых координат;
^=^12 кГц (для микро-ЭВМ «Электроника-60»).

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

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

При проектировании рассмотренного программного обеспечения
ставились следующие задачи:
создать такой состав модулей, которые могли бы реализовать
простейшие системы, выполняющие только отработку готовых про-
грамм, а информацию о технологической программе получать по
каналам связи от ЭВМ, управляющей участком или цехом (стои-
мость таких простых систем существенно снижается и, как след-
ствие, повышается их экономическая выгода, так как по возмож-
ностям выполнения готовых программ они не уступают системам
с программными модулями обучения, редактирования и другими
узлами, облегчающими настройку);

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

создать предпосылки для замены аппаратной части системы
управления программными модулями при использовании микро-ЭВМ
с большими быстродействием и объемом памяти;

применять для подготовки технологических программ и редак-
тирования ЭВМ верхнего уровня, не увеличивая состава про-
граммных модулей в самой системе управления;

использовать, для более сложных технологических процессов
(например, электронно-лучевой сварки) двухмашинный вариант си-
стемы управления, который устраняет недостатки одномашинного
варианта, связанного с «жесткой привязкой» ЭВМ при отработке
|быстрых перемещений;

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

В перспективе, когда будут стандартные интерфейсы и стабили-
зируется состав технических средств РТК, для них можно будет со-
здать отдельные программные модули, которые позволят генериро-
вать систему с заданными свойствами [6].

ЛИТЕРАТУРА

1.	Цыганков ТО. К. Перспективы создания и внедрения сварочных роботов.—
В кн.: Научные проблемы робототехники. М.: Паука, 1980, с. 30—35.

2.	Олейник А. И., Цыганков Ю. ТС. Робот для дуговой сварки в защитных га-
зах.— В кн.: Всесоюз. совет, по робототехническим системам, Владимир,
окт. 1978 г.: Тез. докл. М.: Наука, 1979, с. 47—51.

3.	Коростиль ТО. М., Цыганков Ю. ТС. Некоторые вопросы создания системы
управления сварочными роботами.— В кн.: Всесоюз. совещ. по робототех-
ническим системам, Владимир, окт. 1978 г.: Тез. докл. М.: Наука, 1979,
с. 52—57.

4.	Цыганков ТО. ТС. Один пз подходов к трактовке искусственного интеллек-
та в системах управления сварочным роботом.— В кп.: Робототехнические
системы в отраслях народного хозяйства: Тез. докл. II Всесоюз. совещ.
по робототехническим системам, Минск, 15—19 мая 1981 г. Минск:
БЕЛНИИТИ, 1981, с. 94—95.

5.	Гребенюк ТО. П., Недорезов В. М., Цыганков ТО. ТС. Многоуровневый подход
к использованию датчиков для адаптации сварочных роботов.— В кн.:
Робототехнические системы в отраслях народного хозяйства: Тез. докл.
II Всесогоз. совещ. по робототехническим системам, Минск, 15—19 мая
1981 г. Минск: БЕЛНИИТИ, 1981, с. 95.

6.	Никифоров В. В. Алгоритмические средства построения системы управле-
ния роботами.— В кн.: Алгоритмические модели в автоматизации иссле-
дований. М.: Наука, 1980, с. 186—193.

7.	Никифоров В. В., Смирнов Н. А., Чиганов В. А. Унификация архитектуры
и алгоритмической структуры средств управления промышленными ро-
ботами.— В кн.: Алгоритмические модели в автоматизации исследований.
М.: Наука, 1980, с. 186—193.

8.	Домарацкий А. Н., Кулаков Ф. М., Сурма С. В. Микропроцессорные систе-
мы управления манипуляционными роботами на основе стандарта
САМАС.— В кн.: Алгоритмические модели в автоматизации исследований.
М.: Наука, 1980, с. 156—163.

9.	Чвертко А. И., Патон В. Е-, Тимченко В. А. Оборудование для механизи-
рованной дуговой сварки и наплавки. М.: Машиностроение, 1981. 264 с.

10.	А.с.556016 (СССР). Устройство для пространственной ориентации свароч-
ной головки/В. В. Васильев, Г. И. Закс, А. И. Олейник, Ю. К. Цыгапков.
Опубл, в Б. И., 1977, № 16. 39 с.

УДК 007.52

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

ПРОМЫШЛЕННОГО ОКРАСОЧНОГО РОБОТА «КОЛЕР»

А. П. Федосеев, В. И. Григорьев, С. А. Чевтаев, Л. В. Цуева

В последнее время существенно увеличились выпуск и использова-
ние промышленных роботов с программным управлением, позволяю-
щих исключить применение ручного труда (особенно в тяжелых и
вредных для человека условиях) [1].

Заметное место среди них занимают роботы для нанесения лако-
красочных покрытий с контурной системой управления. К роботам
такого типа относится разработанный окрасочный робот «Колер».

В статье рассматриваются структура и состав программного
обеспечения системы управления робота «Колер», алгоритмы основ-
ных программ и работа всего комплекса в целом.

Система управления (рис. 1) выполнена на базе модулей агре-
гатированной системы и микро-ЭВМ «Электроника-60». На пульте
системы управления расположены клавиатура, с помощью которой
задаются режимы работы, и индикаторы состояния системы управ-
ления и робота.

В процессе обучения информация о положении звена манипуля-
тора поступает с модуля текущей координаты (МТК) в ЭВМ и
записывается в область оперативного запоминающего устройства
(ОЗУ), если на модуле пассивных сигналов (МПС) есть задавае-
мый с пульта обучения сигнал ЗАПИСЬ РАЗРЕШЕНА. Аналогично
обрабатываются функциональные команды ПОВОРОТ РАСПЫЛИ-
ТЕЛЯ и ВКЛЮЧЕНИЕ РАСПЫЛИТЕЛЯ, также задаваемые с
пульта обучения. Модуль силовых! реле (МСР) предназначен для
включения внешнего оборудования, в частности, для включения-
выключения гидростанции (ГС) и исполнения функциональных
Рис. 1. Структурная схема системы управления робота «Колер»

команд. Информация о состоянии внешнего оборудования поступает
на МПС и анализируется в ЭВМ.

В процессе воспроизведения в ЭВМ вырабатывается управляю-
щее воздействие с целью обеспечения движения по контуру, задан-
ному в процессе обучения. Управляющий цифровой сигнал преобра-
зуется в аналоговый в модуле управления координатой (МУК),
далее усиливается по мощности и напряжению в модуле сервоуси-
лителя и подается на золотник, управляющий подачей масла в
гидроцилиндр, который приводит в движение звено манипулятора.

Связь всех модулей осуществляется через ЭВМ. Логика работы
определяется заложенным программным обеспечением.

Структура программного обеспечения определялась следующим:
функциональными требованиями к системе управления;

элементной базой системы управления — управляющей ЭВМ и
модулями агрегативной системы;

наличием уже разработанных программных модулей.

Структура программного обеспечения системы управления робота
«Колер» приведена на рис. 2. Программное обеспечение реализует
работу робота в следующих режимах: обучение; воспроизведение;
работа с перфолентой; тестовый; чтение и запись параметров; руч-
ной.

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

Режим воспроизведения, предназначенный для отработки рабо-
чей программы, имеет три подрежима:

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

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

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

Режим работы с перфолентой служит для ввода и вывода пер-
фоленты с рабочей программой и содержит два подрежима:

ввод перфоленты с рабочей программой в ОЗУ;

4 Заказ JM5 2408

97
Рис. 2. Структура программного обеспечения системы
вывод перфоленты с рабочей программой из ОЗУ.

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

В режиме чтения и записи параметров осуществляется работа с
системными параметрами, определяющими характеристики системы.
Этот режим подразделяется на три подрежима:

поиск параметра по номеру с индикацией значения на пульте
управления;

запись нового значения параметра;

переход к чтению следующего по номеру параметра.

В ручном режиме могут быть выполнены следующие операции:
начальная установка устройств;

включение или выключение гидростанции;

выход манипулятора в нулевую точку;

удаление рабочей программы из ОЗУ.

Работа всех устройств и исполнение команд осуществляются по
сигналу ПРЕРЫВАНИЕ от пульта управления (по нажатию клави-
ши) и таймера. По сигналу ПРЕРЫВАНИЕ от таймера устройства
обмениваются информацией — осуществляется чтение фактического
положения звена манипулятора модуля текущей координаты и
запись рассчитанного воздействия на модуль управления координа-
той. При помощи таймера, таким образом, осуществляется привязка
к реальному времени, необходимая в режимах обучения и воспроиз-
ведения.

Программа «Диспетчер» предназначена для организации работы
программного обеспечения в зависимости от приоритетов поступаю-
щих заявок, сформированных по сигналу «прерывание»; программа
является модулем и может входить в состав программного обеспече-
ния любой агрегатированной системы с ЭВМ типа М-400, СМ-3
и -4, «Электроника-60». Рассматриваемый модуль не зависит от коли-
чества и состава внешних устройств. Для обеспечения функциони-
рования диспетчера составляются специальные таблицы, с помощью
которых выполняется привязка модуля к реальным внешним устрой-
ствам, порождающим прерывание, в данном случае — к пульту уп-
равления и к таймеру.

Программа «Диспетчер» выполняет следующие функции:

в соответствии с таблицей векторов прерываний заполняет векто-
ра прерываний адресами программ обработки заявок;

проводит начальные установки;

анализирует приоритет заявки, сформированной программой
обработки прерываний; если приоритет заявки выше текущего прио-
ритета диспетчера, то заявка обрабатывается сразу, если ниже —
записывается в очередь;

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

Для программного обеспечения робота «Колер» приоритет заяв-
ки от пульта управления выше приоритета заявки таймера, поэтому
сначала обрабатывается заявка от пульта управления.

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

Наибольший интерес представляют алгоритмы работы программ
режимов обучения (рис. 3) и воспроизведения (рис. 4).

Программы режима обучения служат для формирования рабочей
программы в ОЗУ системы управления и для выполнения функцио-
нальных команд в процессе обучения. В начальный момент происхо-
дит считывание выходного регистра данных пульта управления. Ес-
ли на регистре имеется код конца рабочей программы, то он
записывается по конечному ее адресу, запрещается обработка пре-
рываний от таймера и происходит выход в программу «Диспетчер».
В противном случае происходит чтение модуля пассивных сигналов
и анализируется поступление функциональной команды. Если она
не поступила, то происходит чтение модуля текущей координаты и
запоминание значения положения звена. Далее анализируется
признак записи в тело рабочей программы точки в абсолютных
координатах или в приращениях, происходит собственно запись и
выход в «Диспетчер». Если функциональная команда поступила, то
определяется ее вид и она отрабатывается путем засылки единицы
в соответствующий разряд модуля силовых реле. При разработке
формата рабочей программы исходили из условия экономии памяти
и было принято во внимание, что в режиме обучения оператор
практически никогда не перемещает все координаты манипулятора
одновременно. Следовательно, нет необходимости записывать нуле-
вые или близкие к нулю приращения, а достаточно ввести признак
отличного от нуля приращения по данной координате в ОЗУ. Ис-
пользование этого формата позволило сократить объем памяти,
требующийся на запись рабочей программы, в два раза по сравне-
нию с записью всех приращений. Наличие абсолютных координат
вызвано необходимостью обеспечения надежности записи и считы-
вания из ОЗУ траектории движения.

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

Рис. 4. Алгоритм программы режима воспроизведения
Если считанная информация — код функциональной команды, то
ее отработка выполняется аналогично отработке функциональной
команды в режиме обучения. Если нет, то по данным рабочей про-
граммы формируется управляющее воздействие согласно следующим
формулам:

ип =

_(^1П=	4- ц (Vgw — Vgn) -I- аеп + yVen, если Uln < 1023,

11023, если Uin 1023,

gn= Sn §n-it en = gn-i Фп,	= sn б/i-i,

где Un — управляющее воздействие, рассчитываемое после т?-го пре-
рывания таймера; gn, ф„ — заданное и фактическое значение поло-
жения координаты в момент re-го прерывания таймера; р — коэф-
фициент компенсатора; а, у — коэффициент при пропорциональной и
при дифференциальной составляющей регулятора соответственно.

Параметры корректирующих звеньев цифровой следящей систе-
мы определяются при помощи программы автоматической настройки
в тестовом режиме. После расчета значения управляющего воздей-
ствия выполняется запись его значения в соответствующий модуль
управления координатой при очередном прерывании от таймера.
Объем программного обеспечения составляет 6К слов.

ЛИТЕРАТУРА

1. Белянин П. Н. Промышленные роботы и их применение. М.: Машинострое-
ние, 1983. 312 с.

УДК 007.52

СИСТЕМА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
РОБОТИЗИРОВАННОГО

ТЕХНОЛОГИЧЕСКОГО КОМПЛЕКСА

В. А. Павлов

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

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

Штриховые линии — передача данных;
сплошные — передача управления от моду-
ля к модулю

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

Другой вариант организации
РТК предусматривает включение
в его состав центральной управ-
ляющей ЭВМ, на которую возла-
гаются функции диспетчеризации
работы оборудования и расчета
сменно-суточных заданий для
каждого технологического агрега-

та. В соответствии с этим программное обеспечение управляющей
ЭВМ в системе программного обеспечения автоматизированной си-
стемы управления РТК состоит из двух основных подсистем плани-
рования и оперативного управления. Они функционируют независи-
мо друг от друга, что позволяет в случае необходимости использо-

вать только одну из них.

Разработанная система программного обеспечения автоматизиро-
ванной системы управления РТК функционирует в рамках дисковых
операционных систем реального времени управляющих ЭВМ АСВТ
М-6000 и СМ-4. При этом программные модули, образующие подси-
стему управления, определены как диск-резидентные программы
реального времени, а программные модули подсистемы планирования
определены как фоновые диск-резидентные программы с меньшим
приоритетом. Структурная схема системы программного обеспече-
ния автоматизированной системы управления РТК приведена на
рис. 1.

Исходными данными для подсистемы планирования являются:
сведения о технологических агрегатах, работающих в составе РТК
в планируемом месяце; время выполнения i-й технологической опе-
рации на г-м технологическом агрегате (для всех операций и всех
агрегатов); время передачи контейнера с заготовками из автомати-
зированной транспортно-складской системы на i-й технологический
агрегат; время переналадки i-ro технологического агрегата /-Й на
к-ую технологическую операцию; месячный фонд времени работы
z-ro технологического агрегата; график распределения месячного
фонда времени по сменам; месячный план поставок участка. Все эти
данные сгруппированы в четырех дисковых файлах: файл сведений
об оборудовании РТК (PROV); файл технологической информации
(ТЕХМ); файл нормативов времени (NORM); файл производствен-
ной программы (PROG).

Подсистема планирования (программа PLAN) ставится на вы-
полнение оператором. РТК в конце каждого месяца. Программа
обеспечивает распределение плана по поставкам на следующий ме-
сяц между технологическими агрегатами РТК и определение после-
довательности запуска деталей на каждом технологическом агрега-
те исходя из критерия оптимизации загрузки оборудования. При
этом предполагается, что все технологические агрегаты работают
независимо друг от друга, а связь между ними по обрабатываемым
деталям в случае необходимости осуществляется через автоматизи-
рованную транспортно-складскую систему, т. е. заготовки на каждый
технологический агрегат поступают через нее со склада, а продукт,
полученный после обработки заготовки на данном агрегате, посы-
лается обратно на склад.

В результате работы подсистемы планирования формируются
стандарт-план работы РТК на планируемый месяц и сменно-суточ-
ные задания для всех технологических агрегатов РТК, выводимые
на печать для оператора РТК и всех заинтересованных служб
цеха. Сменно-суточные задания для всех технологических агрегатов
записываются в файл TASK, хранящийся во внешней памяти на
магнитных дисках и содержащий всю необходимую исходную ин-
формацию для работы подсистемы оперативного управления.

Подсистема оперативного управления состоит из программ уп-
равления технологическими агрегатами (число программ равно
числу технологических агрегатов РТК) — TOOL14-TOOLN, програм-
мы управления автоматизированной транспортно-складской системы
STORE, программы учета состояния склада — STATE и программы
обработки сменно-суточного задания — PROCS. Для запуска этой
подсистемы оператор РТК в начале каждой смены ставит на выпол-
нение программу обработки сменно-суточного задания. Дальнейшая
работа подсистемы осуществляется автоматически и в случае отсут-
ствия сбойных ситуаций не требует вмешательства оператора.

Программа PROCS проверяет наличие на складе заготовок, комп-
лектующих изделий, инструмента и пустой тары, необходимых для
выполнения сменно-суточного задания для каждого технологическо-
го агрегата, и ставит на выполнение соответствующую программу
TOOLi. В процессе своей работы программа PROCS использует
программу STATE, обеспечивающую формирование моделей мате-
риального и инструментального складов и работу с ними в соответ-
ствии с ведомостями поступления и отгрузки, которые вводятся в
ЭВМ оператором РТК. По запросам от программ PROCS и STORE
программа STATE осуществляет поиск в моделях складов запро-
шенных объектов и выдает в качестве ответа номер соответствую-
щей ячейки склада.
Программы управления технологическими агрегатами TOOLi
обеспечивают выполнение соответствующими технологическими аг-
регатами сменпо-суточных заданий. Для этого каждая программа
TOOLi управляет (посредством обращений к программе STORE)
своевременным подвозом к соответствующему технологическому аг-
регату пустой тары, заготовок и инструмента и передачей от техно-
логического агрегата на склад готовых изделий, осуществляет выда-
чу из внешней памяти ЭВМ на агрегат технологической программы
обрабатываемой детали, а также сигналов запуска этой технологиче-
ской программы. Предполагается, что каждый технологический агре-
гат имеет свое местное управляющее устройство. При наличии у
него своего блока памяти технологическая программа целиком пере-
писывается из внешней памяти ЭВМ в этот блок. В противном слу-
чае из ЭВМ осуществляется покадровая выдача технологической
программы (т. е. последовательная выдача команд управления) на
приемный регистр местного управляющего устройства. В ЭВМ от
технологического агрегата в первом случае поступает сигнал КО-
НЕЦ ОПЕРАЦИИ, во втором - КОНЕЦ ОТРАБОТКИ КАДРА. Эти
сигналы подаются в ЭВМ через систему прерываний и вызывают
активизацию программы управления соответствующим технологиче-
ским агрегатом. Кроме того, от каждого работоспособного агрегата
в ЭВМ поступает сигнал ГОТОВНОСТЬ. Пропадание его свидетель-
ствует о выходе агрегата из строя, что позволяет ЭВМ вовремя
среагировать на это событие.

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

Как уже упоминалось, обе подсистемы системы программного
обеспечения автоматизированной системы управления РТК могут
функционировать независимо друг от друга. Кроме того, для под-
системы управления разработан вариант с собственной операцион-
ной системой — алгоритмическая система управления роботами,
названная «Барс». Она обеспечивает в ЭВМ режим разделения вре-
мени, при котором в качестве пользователей ЭВМ выступают тех-
нологические агрегаты, промышленные роботы и человек-оператор.
Система предусматривает, кроме выдачи технологических программ
на технологические агрегаты, управление движением промышлен-
ных роботов, оснащенных датчиками очувствления. Она состоит из
двух основных частей (рис. 2) — системного программного обеспе-
чения и прикладного программного обеспечения. Системное програм-
мное обеспечение предназначено для организации вычислительных
процессов в управляющей ЭВМ, а прикладное программное обес-
печение — для реализации алгоритмов управления очувствленными
роботами и технологическими агрегатами.

Системное программное обеспечение в свою очередь делится
Рис. 2. Структура алгоритмической системы управления роботами «Барс»

на две части: «Диспетчер» и служебные программы. «Диспетчер»
представляет собой совокупность программных модулей, отвечаю-
щих за управление функционированием системы. К служебным от-
носятся программы, обеспечивающие контроль работоспособности
системы, связь с библиотекой стандартных подпрбграмм и другие
вспомогательные функции.

Прикладное программное обеспечение подразделяется на три
группы программ в соответствии с тремя основными подсистемами
промышленных роботов: программы управления исполнительными
устройствами, программы обработки сенсорной информации и про-
граммы связи с человеком-оператором. Программы управления ис-
полнительными устройствами обеспечивают расчет и выдачу управ-
ляющих воздействий на приводы роботов и выдачу технологических
программ на агрегаты. Программы второй группы осуществляют
обработку информации, поступающей с устройств очувствления ро-
ботов и технологических агрегатов. В настоящее время у роботов
используются ультразвуковые, фотоэлектрические и тактильные дат-
чики. В группу программ связи с оператором включены программы,
обеспечивающие диалог оператора РТК с управляющей ЭВМ и
транслятор с проблемно-ориентированного языка РОКОЛ, на кото-
ром осуществляется программирование действий роботов.

Все программные модули системы «Барс» можно разбить па ин-
формирующие и информируемые, т. е. на модули, являющиеся со-
ответственно источником и приемником информации. Для обеспече-
ния максимальной независимости модулей и обеспечения беспере-
бойной работы информируемых модулей обмен информацией между
ними осуществляется не непосредственно, а через буферные масси-
вы, организованные по циклическому принципу. Во время обработки
информируемым модулем одной записи информирующий модуль в
режиме разделения времени может заполнять буфер новыми запися-
ми. подготавливая тем самым данные для следующего цикла работы
информируемого модуля. Такая организация информационной связи
между программными модулями целесообразна при i4<t2, где
t\ и i2 — время цикла работы информирующего п информируемого
модуля.

Различные внешние факторы, такие, как ввод команды операто-
ром РТК, срабатывание одного из датчиков очувствления, поступле-
ние сигнала от технологического агрегата и т. п., вызывают поступ-
ление сигнала прерывания в ЭВМ и инициируют выдачу заявок на
активизацию определенных программных модулей системы. Так как
одновременно могут быть поданы заявки на активизацию нескольких
модулей, то для выбора наиболее важного из них в данный момент
времени введена система приоритетов. Каждому модулю системы
присвоен приоритет в соответствии с важностью выполняемой им
функции и необходимостью быстрой реакции в ответ на заявку от-
носительно активизации данного модуля. Используется система аб-
солютных приоритетов с дообслуживанием.

Для реализации процесса передачи управления модулям исполь-
зуются управляющие массивы: управляющие шкалы, управляющие
слова и информационные поля модулей. Управляющие шкалы слу-
жат для фиксации модулей, претендующих на процессорное время.
Каждому модулю соответствует определенный разряд в каждой из
шкал (в соответствии с приоритетом). Если он находится в единич-
ном состоянии, то модуль претендует на процессорное время (от-
крыт) по этой шкале. Управление передается модулю, имеющему
наивысший приоритет из числа модулей, открытых по всем шкалам.
В системе «Барс» введено три шкалы: шкала заданий фиксирует
наличие информации для работы модулей; шкала невыполненных
заданий служит для организации работы с буферами ограниченной
длины, т. е. для предотвращения случаев переполнения буферов;
в шкалу выжиданий заносится информация об ожидании програм-
мными модулями системы данных, запрошенных у других модулей.

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

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

Рассмотрим теперь кратко процесс программирования действий
роботов. Проблемно-ориентированный язык РОКОЛ построен по
типу языка ассемблера ЭВМ. Основные операторы языка РОКОЛ
служат для описания логики программ функционирования роботов.
Имеются основные операторы трех типов. Операторы первого типа
являются «расширенными» машинными командами, позволяющими
осуществлять арифметические и логические операции над массивами
данных и ветвления внутри программы. Основные операторы второго
типа реализуют выполнение элементарных действий робота (откры
вание и закрывание схвата, перемещение в пространстве в заданном
направлении, перемещение между двумя заданными точками и т.п.).
Основные операторы третьего типа обеспечивают взаимодействие
системы с сенсорной подсистемой робота, с человеком-оператором и
выдачу команд управления на технологические агрегаты.

В языке РОКОЛ имеются еще две группы специальных операторов
(операторы редактирования и управляющие операторы), которые
непосредственно не используются при написании программ функцио-
пирования роботов. Операторы редактирования позволяют вносить
корректировки в программы функционирования роботов, хранящие-
ся в памяти ЭВМ, и управляют режимами трансляции вводимых
программ. Управляющие операторы служат для задания режимов
работы роботов и ЭВМ, а также для оперативного вмешательства
оператора РТК в ход выполнения роботом заданной программы.

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

Введена возможность представления адресов в символьной форме
и использования литералов для ввода констант. При вводе операторов
языка РОКОЛ осуществляется автоматический контроль правильно-
сти формата вводимого оператора. В случае обнаружения ошибки
печатается диагностическое сообщение и человеку-оператору пре-
доставляется возможность повторить ввод. Аналогичный контроль
осуществляется при поиске в директиве указанной метки и при
поиске в библиотеке директивы с заданным именем. Кроме автома-
тического обнаружения ошибок, человек-оператор имеет возмож-
ность исправлять вводимые конструкции языка РОКОЛ с помощью
символа аннулирования.

Система программного обеспечения автоматизированной системы
управления РТК реализована на управляющих ЭВМ АСВТ М-6000
(или управляющих ЭВМ со сходной архитектурой АСВТ М-7000,
СМ-2) и СМ-4. Программные модули написаны на языке ФОРТРАН
и на языке Ассемблера. Подсистема оперативного управления, реа-
лизованная на микро-ЭВМ «Электроника-60», используется уже в
течение нескольких лет для управления интегральным роботом
ЛПИ-2М и другими очувствленными роботами,
СИСТЕМНОЕ

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ

УДК 681.142.2

СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
ЗАДАЧ РОБОТОТЕХНИКИ

А. К. Платонов, Ю. М. Лазутин, В. С. Ярошевский

В Институте прикладной математики им. М. В. Келдыша АН СССР
разработано системное программное обеспечение инструментально-
го вычислительного комплекса на базе мини-ЭВМ М-6000, используе-
мого для создания и отработки алгоритмов управления различными
робототехническими устройствами [1]. Комплекс позволяет готовить
программы и для микро-ЭВМ «Электроника-60». В его состав входят
мини-ЭВМ М-6000 и подключенные к ней каналами связи мини-ЭВМ
М-7000 и микро-ЭВМ «Электроника-60» (рис. 1). Центральной ма-
шиной комплекса является М-6000. К ней подключены магнитные
диски и лабораторные макеты робототехнических устройств. Когда
ресурсов М-6000 не хватает, дополнительные вычислительные мощ-
ности предоставляет М-7000. Подсистема М-6000 — «Электроника-60»
служит для подготовки и отладки программ для микро-ЭВМ
« Электроника-60».

Специфика использования инструментального комплекса заклю-
чается в непрерывной модификации и отладке алгоритмов управле-
ния различными робототехническими устройствами и реализующих
алгоритмы программ. В каждый момент времени на комплексе ре-
шается только одна задача. Это связано с тем, что управление в
реальном масштабе времени робототехническими устройствами
предъявляет довольно высокие требования к вычислительной маши-
не и ресурсов данного комплекса недостаточно для организации
мультипрограммирования. Недостаток вычислительных мощностей
препятствует также созданию универсальных средств, облегчающих
организацию работы программы в реальном масштабе времени. Для
каждого макета робототехнического устройства, как правило,
создается свой вариант таких средств, хорошо «подогнанный» к
данной задаче, и поэтому на этапе исполнения программы не тре^
буются какие-либо универсальные системные услуги.

В процессе отладки этап подготовки программы и этап исполне-
ния ее в реальном масштабе времени циклически сменяют друг
друга. Типичный цикл отладки изображен на рис. 2. Стандартное
системное программное обеспечения мини-ЭВМ М-6000 не приспо-
соблено к такому режиму использования ЭВМ, что значительно
снижало эффективность работы инструментального комплекса.
В связи с этим возникла настоятельная потребность в разработке
ческий дисплей]	Г^рафопостроитель |	Ви део терминал	|

НМД

М-7000

М-6000

Робототехнические устройства

Рис. 1. Структурная схема инструментального вычислительного комплекса
НМД — накопитель на магнитном диске

Рис. 2. Структурная схема типичного цикла отладки программы

Шириной стрелок показана относительная частота прохождения ветвей цикла

системного программного обеспечения, специально рассчитанного на
режим отладки.

В качестве базы была использована стандартная дисковая опера-
ционная система М-6000. В ходе разработки были значительно
улучшены уже имевшиеся в этой операционной системе средства
(путем замены соответствующих программ) и создан ряд новых.
В настоящее время в неизменном виде остались только транслято-
ры с ФОРТРАНА и с языка Ассемблера. Основной целью всех из-
менений и добавлений было сокращение времени, необходимого для
преобразования алгоритма в отлаженную программу. Для достиже-
ния этого используются два метода:

увеличение числа проходов цикла отладки (от модификации
текста программы до получения загрузочного модуля), выполняемых
за то же астрономическое время, за счет увеличения быстродействия
всех системных программ и упрощения интерфейса между ними и
пользователем;

повышение качества каждого прохода путем предоставления бо-
лее мощных гибких программных средств.

В объеме статьи невозможно подробно описать все системное
программное обеспечение, функционирующее на инструментальном
комплексе. Данная публикация носит обзорный характер. Рассмот-
рим те компоненты и те характеристики системного программного
обеспечения, которые, как показала практика, являются ключевыми
для эффективной отладки программ (язык программирования, сред-
ства для изменения программ, уровень диалога пользователя с ЭВМ,
быстродействие всех средств системного программного обеспечения),
а также основные характеристики созданной в Институте приклад-
ной математики им. М. В. Келдыша АН СССР дисковой операцион-
ной системы для мини-ЭВМ М-6000 и систему программирования
микро-ЭВМ «Электроника-60».

ДИСКОВАЯ ОПЕРАЦИОННАЯ СИСТЕМА
ДЛЯ МИНИ-ЭВМ М-6000

Как было отмечено выше, разработка описываемого здесь системного
программного обеспечения базировалась на стандартной дисковой
операционной системе М-6000. В процессе разработки была пол-
ностью заменена супервизорная часть этой операционной системы и
большинство обрабатывающих программ («Редактор», «Компонов-
щик» и т. д.). Кроме того, были изменены некоторые принципы
построения дисковой операционной системы. Была упрощена фай-
ловая система. Теперь все программы — и системные, и пользова-
тельские — хранятся в одной и той же области диска. Какая-либо
защита системных программ отсутствует, пользовательские програм-
мы имеют свободный доступ ко всему диску. Не используется ап-
парат защиты памяти ЭВМ М-6000, все программы работают в ре-
жиме супервизора. Это существенно упрощает написание программ,
работающих с макетами робототехнических устройств. Операции
ввода—вывода со стандартными внешними устройствами (оператор-
ский терминал, магнитный диск, перфолента, печатающее устройст-
во) выполняются не по прерываниям, а по опросам готовности.
Отказ от прерываний позволил значительно упростить супервизор-
ную часть операционной системы и сделал ее независимой от -тех
операций с системой прерываний, которые выполняют пользователь-
ские программы при работе с лабораторными макетами робототех-
нических устройств (облегчилось также написание таких программ).

Результатом всех этих доработок и изменений явилось создание
новой дисковой операционной системы, существенно превосходящей
по своим параметрам стандартную дисковую операционную систему
М-6000 (рис. 3).

Отметим основные отличительные характеристики созданной
ДОС:

Компактность. Резидентная часть операционной системы зани-
мает в памяти 2К слов. Резидентная программа выполняет операции
ввода—вывода с основными устройствами — операторским термина-
лом и НМД — и, кроме того, операции с файлами, а также орга-
низует загрузку нерезидентных частей дисковой операционной сис-
темы. Если услуги, предоставляемые нерезидентными частями систе-
мы, программе пользователя не нужны, она может занимать всю
незанятую резидентной программой память.

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

Рис. 3. Структурная схема дисковой опе-
рационной системы миии-ЭВМ М-6000

рентное выявление сбоев недостижимо, целесообразно таким образом

организовать работу с магнитным диском, чтобы снизить вероятность
возникновения сбоев.

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

меченным.

Для уменьшения вероятности возникновения сбоев в описывае-
мой дисковой операционной системе принята специальная дисципли-
на работы с файлами, отличающаяся тем, что перемещение на диске
какого-либо файла происходит только при его модификации или по
прямому указанию пользователя. Автоматическая операция «упа-
ковка диска» отсутствует. Освобождающиеся (при удалении файлов
или их модификации) области специальным образом помечаются,
соседние свободные области сливаются. Модифицированный файл
всегда записывается в ближайшую по размерам свободную область
диска. Если при этом она занимается не полностью, остаток ре-
гистрируется в каталоге как новая свободная область. Поскольку
файлы, хранящиеся на диске инструментального комплекса, имеют
самые разнообразные размеры, такая организация работы с файла-
ми не приводит к чрезмерному накоплению маленьких «дыр». Тем
не менее возможны ситуации, когда свободное пространство есть,
но необходимо завести файл, который ни в одну из «дыр» не вле-
зает. Для таких случаев используется программа полуавтоматиче-
ской упаковки диска. Эта программа переписывает файлы по одно-
му из конца области, занимаемой файловой системой, в начало: на
перепись каждого файла запрашивается разрешение пользователя.
Наиболее ответственным элементом файловой системы является
каталог. Перед каждым изменением каталога диска в рассматривае-
мой дисковой операционной системе выполняется копирование ка-
талога в специально отведенную область диска (не в файл).

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

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

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

Высокая производительность. По этому параметру описываемая
дисковая операционная система обладает существенно более высо-
кими характеристиками, чем стандартная. Это обеспечивается вы-
соким быстродействием всех системных программ и прежде всего
резидентной программы. Быстродействие ее обусловлено тщатель-
ной организацией операций ввода—вывода и рациональным распре-
делением функций между системными программами (как можно
меньше перезагрузок программ на стандартных режимах работы).
В результате этих мер время трансляции программ, написанных на
языке Ассемблера или на ФОРТРАНе, в разработанной дисковой
операционной системе уменьшилось примерно в полтора раза по
сравнению со стандартной.

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

ЯЗЫК ПРОГРАММИРОВАНИЯ

Язык Ассемблера и ФОРТРАН, трансляторы для которых имеются
на мини-ЭВМ типа М-6000, не совсем подходят на роль языков
программирования робототехнических задач, решаемых на инстру-
ментальном комплексе. Язык Ассемблера плох при отработке алго-
ритмов, поскольку из-за невысокого уровня языковых средств на-
писание программы и ее модификации отнимает довольно много
В времени, но позволяет добиться максимальной эффективности. На
В ФОРТРАНе трудно писать логические программы, так как он ориен-
 тирован на счетные задачи. Он не приспособлен к структурному
I программированию, поэтому затрудняются отладка и модификация
к программы. Кроме того, существующий транслятор выдает недоста-
В точно эффективные программы. Тем не менее долгое время
 ФОРТРАН был основным языком программирования на инстру-
 ментальном комплексе. На ФОРТРАНе писались как робототех-
К нические, так и чисто системные программы (редактор текстов, Ha-
ff пример, практически полностью написан на ФОРТРАНе).

 С течением времени в коллективе пользователей, работающих
Е на инструментальном комплексе, сформировались определенные
 взгляды на те требования, которым должен отвечать язык програм-
Е мирования, предназначенный для решения робототехнических sa-
lt дач. Некоторое влияние на эти взгляды оказало знакомство с рядом
 новых языков, появившихся в последнее десятилетие: PASCAL,
 ADA, С, EDISON. Вкратце эти требования можно сформулировать
 следующим образом: язык программирования робототехнических за-
 дач должен быть удобен для записи алгоритмов робототехники
В’ (для которых характерна прежде всего сложная и разветвленная ло-
К гика) и должен обеспечивать разумное и динамическое сочетание
 уровня языка и его эффективности. Реализовав и отладив алгоритм
к на языке высокого уровня, пользователь должен иметь возмож-
 ность пожертвовать в каком-то узком месте программы уровнем
к языка и добиться максимальной эффективности. Наличие каких-
ft либо средств для оптимизации результирующей программы не обя-
ft зательно, однако транслятор должен быть тщательно «подогнан»
ft к системе команд конкретной машины, особенно в части логических
К операций и операций манипулирования битами. Транслятор с языка
к должен быть достаточно быстродействующим (по крайней мере не
К уступать в этом отношении транслятору с ФОРТРАНе).

Б С учетом этих требований в Институте прикладной математики
f им. М. В. Келдыша АН СССР разработан язык программирования
к МЭЛ. Рассмотрим только самые общие его свойства. Язык МЭЛ —
I' это ориентированный на структурное программирование язык вы-
I сокого уровня, допускающий вставки на языке Ассемблера. Имеют-
Ь ся два типа данных — простая переменная и массив. В них могут-
| храниться целые и вещественные числа, восьмеричные констаптьц
I буквенно-цифровые символы и адреса. Данные могут быть локаль-
L ными в подпрограмме, локальными в модуле (группе подпрограмм),
Г глобальными, базированными. Размещение базированных данных в
? памяти ЭВМ определяется значением базы — какой-либо переменной
Е или константы. Элементарными операциями языка являются ариф-
( метические и логические операции, сдвиги, операции с адре-
' сами (определение адреса переменной или элемента массива,
косвенная адресация). Число исполнительных операторов ми-
! нимально: присвоение, вызов подпрограммы, циклы, безусловная
» передача управления и условный оператор. Во всех языковых кон-
I струкциях любая переменная может быть заменена произвольным
MD .SORT

DCEM SORT

DCER SORTO

DC D

SR SORT(A(1),N)	”	'

D=N

RU D=(D+1)/2
SORTO(A,N)

EJWl)

EH

SR SORTO(B(1),M)	'

DC I,J,W

RU J=0 1=1

RU IF(B(I)> B(I+D)) W=B(I) B(I)=B(I+D) B(I+D)=W
J=1

EF
1=1 + 1
EP(I+D<=M)

EF(J^O)
EH .

ED

$

Рис. 4. Пример программы, написанной на языке МЭЛ

выражением. Основные преимущества языка МЭЛ заключаются в
гибких средствах управления данными, в богатом наборе логических
операций и операций манипулирования битами, в свободном упо-
треблении выражений и в эффективных средствах управления по-
следовательностью выполнения операций. В ассемблерных вставках
могут использоваться объекты (переменные, метки), определенные
в языковой части программы. Пример программы, написанной на
языке МЭЛ, приведен на рис. 4.

Транслятор с языка МЭЛ реализован на М-6000 в двух версиях:
одна версия готовит объектные модули для мини-ЭВМ М-6000,
другая—для микро-ЭВМ «Электроника-60» (ассемблерная часть в
каждой версии, естественно, своя). Сам транслятор также написан
на языке МЭЛ.

Опыт эксплуатации языка МЭЛ показал, что он лучше, чем
ФОРТРАН, подходит для решения задач робототехники, а также
задач системного программирования.

СРЕДСТВА ДЛЯ ИЗМЕНЕНИЯ ПРОГРАММ

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

Набор команд редактора текстов практически идентичен набору
команд редактора текстов системы ДИМОН на ЭВМ БЭСМ-6 [2]
и имеет следующие основные возможности:

нумерация строк с любым заданным положительным шагом, со-
хранение нумерации между сеансами редактирования (по жела-
нию) ;

просмотр файла целиком и по частям (в заданном диапазоне но-
меров), удаление, включение, замена строк по номерам;

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

поиск и распечатка строк, содержащих заданную цепочку сим-
волов (поиск по образцу);

поиск строк, содержащих заданную цепочку символов С1, и за-
мена в этих строках 01 на другую заданную цепочку символов С2;

слияние файлов (включение в любое место редактируемого фай-
ла любой части любого символьного файла).

Программа «Редактор» работает в диалоговом режиме, команды
исполняются немедленно. Результирующей версии файла можно
присвоить новое имя, можно оставить старое, однако исходная вер-
сия файла всегда сохраняется в неизменном виде до конца редак-
тирования (все изменения записываются в специально для них отве-
денную область). Имеются средства для использования возможно-
стей операторского терминала по редактированию текста прямо на
экране.

Система условной обработки текста управляется содержащими-
ся в тексте командами условной «трансляции», которые выделяются
и исполняются драйвером псевдоустройства. Имеются команды, ана-
логичные командам AIF, ANOP, AGO, SETC макрогенератора. Зна-
чения параметров, фигурирующих в командах условной «трансля-
ции», могут задаваться не только в команде SETC, ио и в коман-
де дисковой операционной системы, объявляющей текстовый файл
псевдоустройством и инициирующей ввод с него. Указывая в данной
команде различные значения параметров, можно получать сущест-
венно отличающиеся версии программы. Однако получение этих
версий должно быть заранее запрограммировано с помощью команд
условной «трансляции». Средства условной трансляции применяют-
ся в основном для генерации различных версий системных про-
грамм. С помощью параметров задаются адреса внешних устройств,
тип процессора, типы интерфейсных блоков и т. д. Поскольку драй-
вер псевдоустройства никак не связан с каким-либо конкретным
транслятором, условная обработка текста может использоваться для
формирования программ на любом языке программирования.

УРОВЕНЬ ДИАЛОГА ПОЛЬЗОВАТЕЛЯ С ЭВМ

Уровень диалога пользователя с ЭВМ понимается здесь следующим
образом: чем меньше команд должен ввести пользователь в машину,
чтобы получить требуемый результат, и чем проще и понятнее от-
веты системного программного обеспечения, тем выше уровень диа-
лога. Команды разработанного системного программного обеспечения
емки и лаконичны. В них нет излишней общности, они рассчитаны
на наиболее часто встречающийся режим работы. Как правило, вся
информация, необходимая какой-либо системной программе для ра-
боты, может быть задана непосредственно в команде, запускающей
данную программу на исполнение (имя исходного файла, имя ко-
нечного файла и т. д.). Кроме того, весь диалог пользователя с си-
стемным программным обеспечением можно запрограммировать, по-
местив в текстовый файл все необходимые для диалога команды и
объявив его псевдоустройством. В этом случае одной командой за-
пускается деятельность любой сложности. Вмешательство пользова-
теля требуется только в тех случаях, когда возникает какая-либо
непредвиденная или конфликтная ситуация (нет требуемого фай-
ла или, наоборот, создаваемый файл уже есть и т. д.). В этих слу-
чаях программа, обнаружившая такую ситуацию, обращается за по-
мощью к пользователю. Программирование диалога повышает и об-
щую производительность системы, поскольку из диалога исключает-
ся человек — звено наименьшего быстродействия. Снижается также -
вероятность ошибки (неправильное задание имени файла и т. д.).

В настоящее время непременной компонентой системного про-
граммного обеспечения, претендующего на высокий уровень диало-
га пользователя с ЭВМ, является программное обеспечение машин-
ной графики. В системное программное обеспечение инструменталь-
ного комплекса входит программный комплекс ГРАФОР-М, ориен-
тированный на построение графиков [3]. Рисуя график в заданной
программистом прямоугольной области, программы комплекса авто-
матически масштабируют значения переменных, помечают задан-
ные точки кривой специальными маркерами, проводят и размечают
координатные оси. Изображение может также содержать различ-
ные геометрические фигуры, строки буквенно-цифровых символов.
Существуют две версии комплекса: для графопостроителя и для
графического дисплея СИГ ДА [4]. Последняя версия содержит
средства для 'программирования диалоговых устройств — светового
пера и клавиатуры дисплея.

БЫСТРОДЕЙСТВИЕ СИСТЕМНЫХ ПРОГРАММ

Быстродействие всех системных программ имеет очень большое зна-
чение для эффективности отладки программ пользователем, посколь-
ку непосредственно влияет на продолжительность типичного цикла
отладки и, следовательно, на число таких циклов, выполняемых за
то же астрономическое время. Кроме того, здесь есть и психологи-
ческие аспекты. Если какое-либо удобное средство реализуется про-
граммой, выполняющейся слишком медленно, пользователь будет
стараться применять его как можно реже. Поэтому при создании
всех программ рассматриваемого системного программного обеспе-
чения вопросам повышения быстродействия программ уделялось
особое внимание. Как показывает практика, основным замедляю-
щим фактором в системных программах являются обмены с магнит-
ным диском. На минимизацию числа обменов и были направлены
основные усилия разработчиков. Например, программа «Компонов-
щик» (одна из самых медленных) значительную часть времени тра-
тила на просмотр библиотеки стандартных подпрограмм. Введение
специального каталога библиотеки позволило значительно сократить
время работы программы «Компоновщик». Другим примером явля-
ется сегментация программы — разбиение ее на поочередно загру-
жаемые с диска сегменты. Такой прием дает существенную эконо-
мию оперативной памяти, однако может столь же существенно
увеличить время выполнения программы. В тех случаях, когда опе-
ративной памяти хватает (а она в настоящее время не самый дефи-
цитный ресурс), желательно избегать сегментирования программы.
Разработанный транслятор для языка МЭЛ состоит из одного сег-
мента. Более того, он однопроходный, т. е. просматривает исходный
текст программы всего один раз (за счет более активного использо-
вания имеющейся оперативной памяти и некоторого увеличения
пространства на диске, занимаемого объектным модулем). В резуль-
тате трансляция программы на языке МЭЛ выполняется примерно в
полтора раза быстрее, чем трансляция такой же по размерам про-
граммы па ФОРТРАНе. Это соотношение верно и для входящего в
транслятор с МЭЛ транслятора с языка Ассемблера.

ПРОГРАММИРОВАНИЕ МИКРО-ЭВМ
«ЭЛЕКТРОНИКА-60»

В описываемое системное программное обеспечение входят и сред-
ства программирования микро-ЭВМ «Электроника-60», которая от-
личается относительно небольшими габаритами и малой массой,
что создает хорошие предпосылки для построения на основе этой
ЭВМ систем управления различными робототехническими устройст-
вами. Однако программирование микро-ЭВМ «Электроника-60» пред-
ставляло собой непростую задачу. Трудности комплектации инстру-
ментальных комплексов на базе ЭВМ «Электроника-60» (отсутствие
или нехватка устройств для работы с натурными объектами и уст-
ройств внешней памяти на магнитных дисках) вынуждают исполь-
зовать для программирования ЭВМ «Электроника-60» инструмен-
тальные комплексы на базе других ЭВМ (например, СМ-3, -4).
Вследствие ограниченности ресурсов ЭВМ «Электроника-60» про-
граммирование ведется, как правило, на языке Ассемблера. В Ин-
ституте прикладной математики им. М. В. Келдыша АН СССР были
созданы средства программирования микро-ЭВМ «Электроника-60»,
базирующиеся на ЭВМ типа М-6000 [5]. В их число входит про-
граммный эмулятор ЭВМ «Электроника-60» (позволяющий готовить
программы для нее без ее участия), операционная система для
двухмашинного комплекса мини-ЭВМ М-6000 — микро-ЭВМ «Элект-
роника-60» и кросс-система программирования на базе языка МЭЛ.

Эмулятор моделирует архитектуру микро-ЭВМ «Электроника-60»
в объеме, необходимом для функционирования основных программ
Рис. 5. Структурная схема комплекса
ЭВМ «Электроника-60»—М-6000

перфоленточной операционной си-
стемы — транслятора с языка Ас-
семблера и «Компоновщика». Про-
граммная модель ЭВМ «Электро-
ника-60» имеет 16К байт опера-
тивной памяти и внешние устрой-
ства: фотосчитыватель перфолен-
ты, перфоратор и пишущую ма-
шинку. Физически операции вво-
да—вывода выполняются на соот-
ветствующих внешних устройст-
вах мини-ЭВМ М-6000. Перфолен-
та может подменяться файлами
на диске. В состав эмулятора вхо-
дит ретранслятор, позволяющий
восстановить текст программы па
языке Ассемблера. Потребность в

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

При очевидных достоинствах (пользователь работает на доста-
точно. комфортабельной ЭВМ М-6000, не нужна ЭВМ «Электрони-
ка-60») эмулятор обладает столь же очевидным недостатком: про-
граммная интерпретация на ЭВМ М-6000 системы команд ЭВМ
«Электроника-60» приводит к значительному замедлению выполняе-
мой в эмуляторе программы. Для того чтобы полностью проинтер-
претировать одну команду ЭВМ «Электроника-60», в эмуляторе вы-
полняется примерно сто команд ЭВМ М-6000. Поэтому для подготов-
ки больших программ эмулятор мало пригоден. Подготовка больших
программ для ЭВМ «Электроника-60» на. инструментальном комп-
лексе осуществлялась с помощью комплекса М-6000 — «Электрони-
ка-60» и с использованием кросс-системы на базе языка МЭЛ.

Операционная система двухмашинного комплекса (рис. 5) пред-
ставляет собой модифицированную перфоленточную операционную
систему ЭВМ «Электроника-60». Модификация состоит в том, что
все запросы на ввод—вывод от программы, находящейся в ЭВМ
«Электроника-60», передаются в ЭВМ М-6000 по каналу связи, ин-
терпретируются там специальной программой и выполняются на
внешних устройствах ЭВМ М-6000. Операции с перфолентой заме-
няются операциями с файлами. Загрузка программ в ЭВМ «Элект-
роника-60» осуществляется по каналу связи из ЭВМ М-6000. Поль-
зователь управляет работой системы через операторский терминал
мини-ЭВМ М-6000 и практически не замечает существования микро-
ЭВМ «Электроника-60». По комфорту и производительности работа
на двухмашинной системе примерно соответствует программирова-
нию мини-ЭВМ М-6000 на языке Ассемблера в рамках дисковой опе-
рационной системы.
Однако, как было отмечено выше, язык Ассемблера неудобен
для программирования робототехнических задач. В Институте при-
кладной математики им. М. В. Келдыша АН СССР создана кросс-
система программирования ЭВМ «Электроника-60» на базе языка
МЭЛ. На ЭВМ М-6000 имеется версия транслятора с этого языка,
которая переводит программу, написанную на МЭЛ, в объектный
модуль, содержащий команды ЭВМ «Эяектроника-60». Программа
«Компоновщик» дисковой операционной системы ЭВМ М-6000 (спе-
циальный режим работы этой программы) обрабатывает совокуп-
ности таких объектных модулей и выдает загрузочный модуль про-
граммы, готовый к выполнению на микро-ЭВМ «Электропика-60».
Его можно загрузить в нее по каналу связи или выдать на перфо-
ленту.

Двухмашинная система обладает также еще одним важным до-
стоинством: микро-ЭВМ «Электроника-60» имеет выход на устрой-
ства связи с натурными объектами, входящими в комплект мини-
ЭВМ М-6000. Кроме того, ЭВМ М-6000 может моделировать для
ЭВМ «Электроника-60» внешнюю среду.

* * *

Разработанное системное программное обеспечение широко исполь-
зуется в Институте прикладной математики им. М. В. Келдыша
АН СССР при решении задач по созданию систем управления для
мобильных роботов, сборочных роботов, роботов для дуговой сварки
[6—9]. Практика показала, что созданное системное программное
обеспечение хорошо обеспечивает режим отладки, характерный для
задач робототехники, и позволяет значительно ускорить решение
этих задач.

ЛИТЕРАТУРА

1.	Мямлин А. Н., Смольяков Ю. П., Силъвинский В. А., Федорин О. С., Дон-
цов В. Е., Лазутин Ю. М., Павловский В. Е. Комплекс моделирования и ма-
кетирования робототехнических систем.— В кн.: Всесоюз. совещ. по робо-
тотехническим системам, Владимир, окт. 1978: Тез. докл. М.: Наука, 1979,
с. 224-225.

2.	Усов С. А. Диалоговый монитор ДИМОН. М.: Наука, 1979. 125 с.

3.	Карпов И. И., Лазутин Ю. М., Ярошевский В. С. ГРАФОР-М: комплекс гра-
фических программ на ФОРТРАНе для ЭВМ М-6000; Препр. Ин-та прикл.
математики им. М. В. Келдыша АН СССР № 138. М., 1980. 28 с.

4.	Александров М. А., Лазутин Ю. М. Комплекс программ на ФОРТРАНе для
работы с графическим дисплеем СИГДА на ЭВМ М-6000: Препр. Ин-та
прикл. математики им. М. В. Келдыша АН СССР № 107. М., 1981. 22 с.

5.	Лазутин Ю. М., Яшкичев И. В. Система программирования микро-ЭВМ
«Электроника-60» на мини-ЭВМ М-6000: Препр. Ин-та прикл. математики им.
М. В. Келдыша АН СССР № 58. М., 1982. 21 с.

6.	Охоцимский Д. Е., Платонов А. К., Кугушев Е. И., Ярошевский В. С. Управ-
ление макетом шагающего аппарата при преодолении препятствий.— В кн.:
Исследование робототехнических систем. М.: Наука, 1982, 66—71 с.

7.	Гримайло С. И., Камынин С. С., Кугушев Е. И. Программное обеспечение
манипуляторов с очувствленными схватами: Препр. Ин-та прикл. матема-
тики им. М. В. Келдыша АП СССР № 104. М., 1981. 21 с.

8.	Платонов А. К., Кирильченко А. А., Кугушев Е. И. Использование локаль-
ных ориентиров для определения положения мобильного робота.— В кн.:
Проблемы машинного видения в робототехнике. М.: Ин-т прикл. матема-
тики им. М. В. Келдыша АН СССР, 1981, 36-47 с.

9.	Охоцимский Д. Е., Платонов А. К., Смольянов Ю. П., Гримайло С. И., Ка-
мынин С. С., Кугушев Е. И. Исследование многооперационной сборки с по-
мощью экспериментальной робототехнической системы.— В кн.: Роботиза-
ция сборочных процессов. М.: Наука, 1985, № 76, с. 61—88.

УДК 621.865.8.001.1

СПЕЦИАЛИЗИРОВАННАЯ ОПЕРАЦИОННАЯ СИСТЕМА:
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

ИССЛЕДОВАТЕЛЬСКОГО ИНСТРУМЕНТАЛЬНОГО
РОБОТОТЕХНИЧЕСКОГО КОМПЛЕКСА

А.	Ф. Верещагин, С. Л. Зенкевич, А. В. Назарова

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

разработка и исследование методов управления поведением ро-
бота (движением и обработкой сенсорной информации);

формирование, отладка и тестирование программ движения ро-
бота;

генерация управляющих программ и данных для рабочего (про-
мышленного) комплекса.

Рассмотрим программное обеспечение исследовательского ин-
струментального робототехнического комплекса на базе управляю-
щей ЭВМ СМ-4 и антропоморфного электромеханического манипу-
лятора УЭМ-2 (структурная схема комплекса приведена на рис. 1).

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

ЦП СМ-4 — центральный процессор
• мини-ЭВМ СМ-4;

ОЗУ — оперативное запоминаю-
щее устройство;

НМЛ — накопитель на магнитной
ленте;

НГМД — накопитель на гибком
магнитном диске;

НМД — накопитель на магнитном
диске;

КНМЛ — кассетный накопитель на
магнитной ленте;

УПО — устройство последователь-
ного обмена

Рис. 2. Структурная схема специа-
лизированной операционной системы

лизированной операционной системы — манипулировать с объекта-
ми. Таким образом, поскольку специализированная операционная
система совпадает с универсальной с точностью до объекта, с ко-
торым она работает, их структуры в общих чертах совпадают.

Операционная система (рис. 2) состоит из программ двух типов:
управляющих и обрабатывающих. Управляющие программы обеспе-
чивают функционирование системы в целом, обрабатывающие — ра-
ботают под управлением управляющих программ и выполняют в
основном преобразование данных.

К управляющим программам относятся:

управление заданиями (функции управления заданиями выпол-
няет интерактивный монитор, обеспечивающий интерфейс между че-
ловеком-оператором и системой);

управление данными (программы управления данными осущест-
вляют операции ввода-вывода, каталогизации наборов данных, фор-
матирования данных, т. е., вообще говоря, поддержания файловой
структуры);

управление задачами (функции управления задачами выполня-
ет супервизор, который обслуживает режим исполнения роботом ра-
бочей программы движения; основная задача супервизора — поддер-
Рис. 3. Основные операции, выполняемые в процессе формирования рабочей програм-
мы н ее исполнения

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

управление объектом (программы управления объектом — это
драйверы, обеспечивающие обмен данных между управляющей ЭВМ
и манипулятором).

К обрабатывающим программам относятся следующие:

транслятор с проблемно-ориентированного языка (проблемно-
ориентированный язык необходим для формирования программы
функционирования манипулятора);

трансляторы с языков программирования (специализированная
операционная система содержит трансляторы с ФОРТРАНа и ма-
кро-ассемблера, входящие в состав универсальной операционной си-
стемы, что дает пользователю возможность писать фрагменты уп-
равляющих программ на языке, наиболее подходящем для реализа-
ции алгоритма);

обслуживающие программы («Редактор», «Отладчик», «Загруз-
чик», «Библиотекарь» и т. д.);

программы пользователя (каждая из них реализует определенное
движение или группу движений манипулятора; программы объеди-
нены в библиотеку и могут использоваться либо самостоятельно,
либо как фрагмент формируемой пользователем задачи).

Управление заданием: команды монитора. Оператор общается с
роботом, используя либо команды монитора, либо команды некото-
рой служебной программы, вызываемой с помощью команды монито-
ра. Поэтому при разработке монитора в основу были положены сле-
дующие принципы:

команды монитора должны удовлетворять всем потребностям
оператора по выполнению стоящей перед ним задачи;

работа с операционной системой не должна требовать квалифи-
кации программиста.


Проведенный анализ позволил выявить следующие операции, вы-
полняемые человеком-оператором (рис. 3):





формирование и отладка программ движения робота в режиме
запоминаемой программы и в режиме запоминаемых данных (ре-

жим обучения);

исполнение программы движения;

передача данных рабочему комплексу;

тестирование внешних устройств, идентификация их параметров;

сервис.

Решение этих задач нашло свое отражение в выборе команд мо-
нитора. Заметим, что везде ниже: подсказки и сообщения системы

выделяются подчеркиванием; все имена, участвующие в описании
команд монитора, являются обобщенными, т. е. могут содержать,
кроме имени файла, еще и имя устройства.

Рассмотрим набор основных команд монитора специализирован-
ной операционной системы:

PROGRAM — формирование программы управления роботом на
проблемно-ориентированном языке. Формат команды:

PR06KAM

INPUT SOS-FILE = <ИМЯ_ВХОДНОГО_ТЕКСТОВОГО_ФАйЛА ! < CPLF >
ITIITPI it SOS-FILE = < ИМЯ_ВЫХОДНОГО_ТЕКСТОВОГО_*АЙЛА > L < CRLF >

OUTPUT RUN-FILE = < ИМЯ—ЗАДАЧИ > I < CRLF >

OPTION = < ПВ > ! < IM > I < EX > ! < CRLF >

Человеку-оператору предоставляется возможность воспользовать-
ся следующими ключами:

DB — отладочный режим (программа исполняется покомандно);

IM — имитация движения манипулятора на экране графического
дисплея в процессе исполнения;

ЕХ — немедленное исполнение сформированной задачи.

EDIT — создание новых текстовых файлов и редактирование уже
существующих. Формат команды:

EDIT

INPUT SOS-FILE = < ИМЯ_ВХОДНОГО_ТЕКСТОВОГО_ФАйЛА > ! < CRLF >

OUTPUT SOS-FILE = < ИМЯ-,ВЫХОДНОГО_ТЕК.СТОВОГО_ФАЙЛА > ! < CRLF >

RUN — исполнение программы движения, подготовленной в ре-
жиме PROGRAM. Формат команды:

RUN

TASK NAME = < ИМЯ-ЗАДАЧИ >

IMMEDIATE — режим интерпретатора команд человека-операто-
ра. Этот режим, по существу, эквивалентен режиму, обеспечиваемому
командой монитора PROGRAM с той лишь разницей, что операторы
языка управления интерпретируются, а не компилируются. Формат
команды:

IMMEDIATE

ACTION = К ИМЯ-ОПЕРАТОРА >

PARAMETERS:

< СПИСОК-ПАРАМЕТРОВ >
TRAIN — формирование, отладка и редактирование программы
движения в режиме запоминаемых данных (в режиме обучения).
Формат команды:

INPUT DATA NAME = < ИМЯ_ВХОДНЫХ_ДАННМХ > • < CRLF >

OUTPUT DATA NAME = < ИМЯ-ВЫХОДНЫХ_ДАННЫХ > ! < CRLF >	9

DEFAULT : PRM1 = < ЧИСЛО > ! PRM2 = < ЧИСЛО > ! ... ! < CRLF

OPTION = IM ! SN ! < CRLF,>

Команда TRAIN является многофункциональной и позволяет:

формировать и редактировать программу движения в диалого-
вом режиме, не приводя в движение исполнительный механизм (ре-
,жим off-line);

формировать и редактировать программу движения, используя
задающие органы (режим on-line), которыми могут служить: руко-
ятка, задающий исполнительный механизм, пульт, клавиатура дис-
плея;

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

ЕХЕС — исполнение программы движения, сформированной в ре-
жиме TRAIN. Формат команды:

ЕХЕС

DATA-NAME = < ИМЯ.ДАННЫХ >

OPTION =< АТ > • < ST > ! < CRLF >

POINT = < НОМЕР-ПОЗИНИИ >

Программа может выполняться в автоматическом или в поша-
говом режимах (ключи АТ и ST соответственно), как с первой,
так и с любой другой позиции (параметр <номер-позицпи>).

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

тестировать каналы связи ЭВМ—манипулятор;

калибровать телевизионную камеру;

выполнять преобразование файлов.

Язык управления движением. Формирование рабочей програм-
мы может проводиться двумя способами: в режиме запоминания
данных и в режиме запоминания команд. Последний способ более
перспективен, поскольку позволяет не только осуществить движе-
ние по жесткой программе, но и подстроить его (и вообще выбрать
поведение) в зависимости от показаний сенсорной системы.

Разработанный язык управления движением является языком
Таблица

Группа операторов	Формат оператора	Описание
Элементарные операторы управ- ления движением	PQ (j.Ql, Q2	Q6)  IPQ (j, А)	Перевод манипулятора в состоя- ние, характеризуемое обобщен- ными координатами QI, Q2, ...  ...,Q6  Перевод манипулятора в состоя- ние, характеризуемое вектором А
Операторы пере- дачи управления	JMP ((метка))  IJMP «событие), (метка))	Безусловная передача управления на указанную метку  Передача управления на указан- ную метку в случае возникнове- ния указанного события
Арифметические	QST (Q, Т)	Решение прямой задачи
операторы	SQ (n, S, Q)	Решение нелинейной обратной задачи
Макрооператоры	CLOS OPEN PNT (Т)  \	Закрыть схват  Открыть схват  Перевод манипулятора в состоя- ние, характеризуемое матри- цей Т

низкого уровня (по сути дела, языком Ассемблер) и включает в
себя следующие классы операторов:

элементарные операторы управления движением;

безусловные и условные операторы передачи управления;
арифметические операторы;

макрооператоры.

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

Управление задачей. Процесс исполнения сформированной про-
граммы движения (либо' в режиме запоминания данных — TRAIN,
либо в режиме запоминания команд — PROGRAM), вообще говоря,
состоит из двух связанных процессов: вычисления требуемых уп-
равляющих сигналов на приводы исполнительного механизма, вы-
полняемого ЭВМ, и отработки этих сигналов. Поскольку темпы про-
текания этих процессов различны, нельзя рассчитывать на то, что
отработка приводами заданных сигналов управления закончится к
моменту, когда ЭВМ подготовит их следующий набор. На самом
деле, возможны две следующие ситуации: управляющие сигналы
вычислены, а манипулятор не отработал предыдущую команду
(рис. 4, а), и, наоборот, манипулятор находится в состоянии ожида-
Щдя следующего управляющего сигнала (рис. 4, б).
Z////////////////////////Z

77777Z^7777777777777777777

Вычисление управляющих у

сигналов "	Z

ZzzzzzzzZZZZZZZZZZZZZZZZZ^

Zzzzz I

ЭВМ

Манипулятор
а

^/ZzzzzZzzzzzzzzzzzzzzz/^zzzzzzzzzzzzzzzzzzzZzzzzz/Zzzzzzzzz<zzzz

4	ЭВМ

t

m72ZZZZ/77ZZZZZ^
Отработка
-zzzzzzzzzzzzzzzzzZ

Манипулятор

Пауза

1

Рис. 4. Синхронизация процессов вы-
числения управляющих сигналов и
их отработки

Рис. 5. Мультизадачный режим ра-
боты исполняющей программы



t

Для того чтобы в некоторой степени скомпенсировать этот не-
желательный эффект, при реализации исполнения программы дви-
жения использован мультизадачный режим работы процессора
(рис. 5). Процесс исполнения сформированного оператором задания
содержит следующие задачи: '

вычисление точек позиционирования; интерполяция; вычисление
и выдача управления.

Такое разбиение может быть оправдано тем, что:

каждая из перечисленных выше задач представляет самостоя-
тельную вычислительную процедуру;

связь между задачами осуществляется только на уровне входных
(выходных) данных.

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

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

УДК 007.52:001.1

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

СИСТЕМЫ УПРАВЛЕНИЯ СВАРОЧНЫМ
РОБОТИЗИРОВАННЫМ КОМПЛЕКСОМ

В.	Т. Тертышный

Применение мини- и микро-ЭВМ в системах управления роботизи-
рованными технологическими комплексами (РТК), в частности для
дуговой сварки, выдвигает па первый план проблему создания про-
граммных средств, обеспечивающих эффективную работу комплек-
са. Говоря о работе комплекса, мы подразумеваем под этим не толь-
ко автоматическое выполнение заданной программы технологиче-
ского процесса, по и ее подготовку: составление, отладку,
редактирование.

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

Если в реализации автоматического режима работы комплекса
необходимость применения ЭВМ не всегда очевидна, то в сфере
подготовки и отладки программы технологического процесса послед-
ний подход обладает решающими преимуществами. К этому следует
добавить, что переход к РТК второго поколения и их дальнейшее
развитие связано в первую очередь с повышением уровня алгорит-
мической организации системы управления, которое без использо-
вания ЭВМ, естественно, невозможно.

Построение программного обеспечения систем управления РТК
имеет отличающих его от программных систем другого назначения
ряд специфических черт: высокий темп обработки информации;
большое количество асинхронных источников информации; ограни-
ченные ресурсы микро-ЭВМ.

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

В Институте электросварки им. Е. О. Патона АН УССР уже
длительное время ведутся работы по использованию мини- и микро-
ЭВМ для управления РТК как для точечной, так и для дуговой
сварки. Итогом этих работ явилось создание в рамках программы
многостороннего сотрудничества «Интерробот» системы управления
на базе микро-ЭВМ «Электроника-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.

ЛИТЕРАТУРА

1.	Кисилевский Ф. Н., Тертышный В. Т., Швыдкий И. Р. Система управления
роботизированным комплексом с использованием микропроцессоров.—
В кн.: Применение роботов и манипуляторов в сварке: Тр. конгр. РОБОТ-82.
Брно, 1982. 11 с.

2.	Тертышный В. Т. Метод установочной адаптации роботизированного комп-
лекса для сварки.— В кн.: Робототехнические системы в отраслях народ-
ного хозяйства Тез. докл. 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

СИСТЕМА ВЗАИМОДЕЙСТВИЯ
ПРОГРАММНЫХ МОДУЛЕЙ
ДЛЯ МНОГОПРОЦЕССОРНЫХ СИСТЕМ УПРАВЛЕНИЯ

И. П. Белякова, М. А. Утин
7 \

ПОСТАНОВКА ЗАДАЧИ

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

Для реализации программного взаимодействия подобных систем
принципиально возможно использование: языков высокого уровня
с параллельными конструкциями типа ADA [1], CPASCAL [2],
MODULA [3], СР [4]; сетевых операционных систем типа
DECNET; языка Ассемблера, позволяющего обращаться к регистрам
внешних устройств. Из этих трех подходов языки высокого уровня
наиболее предпочтительны, так как обеспечивают наибольшую про-
изводительность разработки программ и высокое качество докумен-
тирования.

Однако большинство языков для разработки параллельных про-
грамм реализованы либо для однопроцессорных вариантов [2], либо
для систем с общим адресным пространством [5], а реализация
языков в сетевой архитектуре не выполнена, к тому же не для
всех языков это будет эффективно. Сетевые системы имеют сложные
стандартизованные протоколы связи, снижающие скорость обмена
информацией, и поэтому обычно не используются для систем управ-
ления. Создание программы взаимодействия на языке Ассемблера
не оправдано с точки зрения производительности, сложности пов-
торного использования, сложности стыковки с программами, напи-
санными на языке высокого уровня. В связи с этим была поставле-
на задача разработки стандартной системы взаимодействия, выпол-
няемой в рамках распределенной операционной системы с помощью
программ, поддерживающих передачу данных через модули связи с
наибольшей эффективностью, и системы команд обращения из при-
кладных программ системы управления. Поставленная задача реша-
лась при следующих ограничениях на структуру программных и
аппаратных средств:

система управления представляет собой локальную сеть процес-
соров, связанных с помощью модулей-буферов двустороннего обмена
(без общего поля памяти), ограничений на топологию нет;

процессоры подключаются к шине другого процессора на правах
внешнего устройства, т. е. имеют фиксированные адреса регистров
состояний, данных и адреса векторов прерываний;

распределение программного обеспечения по процессорам стати-
ческое, определяемое в момент компоновки системы и фиксируемое
в момент загрузки;

каждому процессорному модулю соответствует единственный
функциональный процесс — программный модуль системы управ-
ления.

ОПИСАНИЕ СИСТЕМЫ ВЗАИМОДЕЙСТВИЯ

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

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

Для разделяемых структур данных {XJ определены допустимые
команды системы взаимодействия (см. таблицу). Никакие другие
операторы языка Ассемблера или языков высокого уровня не допу-
стимы при обращении к разделяемым переменным, что контроли-
руется трансляторами или компиляторами.

Для каждой разделяемой структуры данных X,- определяется
явно в команде системы взаимодействия соответствующая копия —
локальная структура данных аХ,-, над которой разрешены все опе-
рации последовательного языка программирования.

Реализация команд системы взаимодействия обеспечивает взаи-
моисключающее чтение—запись структуры данных из одних про-
цессов в другие с одновременной синхронизацией типа «рукопожа-
тие» для свободных процессов. Для несвободных процессов не вы-
полняется синхронизация, а осуществляется пересылка и прием
данных как неделимая операция. При взаимодействии свободных
Таблица

Команда	Содержание
S. READ X, ctX, N	Послать запрос на структуру данных X в модуль- источник, принять данные, скопировав их в локаль- ный буфер аХ размера N
М. WRITE X, аХ, N	Подготовить структуру данных X к использованию, скопировав из локального буфера аХ размера N; если запрос па структуру из модуля-приемника есть, послать по запрошенному адресу
S. WRITE X,aX,N	Послать запрос на разрешение переслать подготов- ленную структуру X в модуль-приемник, передать структуру данных при наличии разрешения
М. READ X, аХ, N	Принять структуру данных от модуля-источника, если есть запрос на передачу, скопировав структу- ру X в локальный буфер аХ размера N
3. WRRD X, аХ, N  Y, аУ, N	Послать запрос на разрешение передать блок па- раметров X процедуре-функции удаленного модуля, по разрешению передать блок параметров и запрос на чтение результата У; по готовности результата принять в локальный буфер аУ размера N
М. RDWR X, аХ, N  Y, аУ, N	Если есть запрос от модуля на передачу парамет- ров процедуры-функции, принять параметры в ло- кальный буфер аХ от первого в очереди процессо- ров, подготовить результат У и послать по запро- шенному адресу

Примечание: S. READ, . . . , М. RDWR — экстракоды команд; X — имя разделяемой
переменной; аХ — имя буфера локальной памяти процесса; — размер буфера

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

Команды системы взаимодействия объединяются в пары
М. READ-S. WRITE, М. WRITE - S. READ, S. RDWR —
M. WRRD для каждой структуры данных Х{. Команды типа М
выполняются в процессе-владельце структуры без запроса на взаи-
модействие с другим процессом. Команды типа S выполняются в
процессе-слуге, который всегда посылает запрос в процесс-владелец
на разрешение выполнить команду [4].

РЕАЛИЗАЦИЯ СИСТЕМЫ ВЗАИМОДЕЙСТВИЯ

Система взаимодействия реализована в виде двух составляющих
программ. Основная системная программа INTERACTION, обслу-
живающая выполнение экстракодов команд системы взаимодейст-

t	139
вия, представляет собой резидентную системную программу каж-
дого процессорного модуля. Интерфейсом между прикладной про-
граммой системы управления и программой INTERACTION служат
структуры данных (таблицы, дескрипторы, буферы), расположен-
ные в прикладной программе и формируемые системными програм-
мами средств разработки.

Прикладная программа каждого процессорного модуля оформ-
ляется в виде программного процесса, представленного указателем
записи содержимого его регистров в определенной структуре дан-
ных [2, 6], называемой дескриптором процесса:

D1PRI Указатель записи регистров

Тип процесса (свободный, несвободный)
Указатель фонового процесса

Разделяемые переменные представлены своими именами в таб-
лице разделяемых переменных TABLCV процесса:

TABLCV Имя первой переменной

Дескриптор первой переменной
Имя второй переменной
Дескриптор второй переменной
Имя г-й переменной
Дескриптор г-й переменной
Конец таблицы

Таблица TABLCV является основным интерфейсом между функ-
циональным процессом и системной программой INTERACTION,
имеет фиксированный адрес в системной памяти и содержит, кроме
имен переменных, адреса их дескрипторов {D,}. Дескрипторы в
свою очередь имеют всю информацию относительно переменных
{XJ:

О;	Указатель системного буфера переменной

Указатель дескриптора процесса

Указатель адреса процессорного модуля процесса,
разделяющего структуру

Дескрипторы переменных, разделяемых несколькими процесса-
ми (для служебных процессов), отличаются от приведенных тем,
что вместо указателя на адрес процессора имеют указатель на спи-
сок адресов процессоров, запрашивающих доступ к структуре дан-
ных.

Для каждой переменной X,- определен системный буфер СХ,:
для ее временного размещения и локальный аХ; для постоянного
использования прикладной программой последовательных операто-
ров. Системный буфер имеет следующую структуру:

WSj	Слово состояния буфера

GX,	Первое слово разделяемого массива

Последнее слово разделяемого массива

Конец буфера
Слово состояния буфера WS; имеет отдельный бит, указываю-
щий на наличие запроса на прием—передачу разделяемой структу-
ры X,-, и бит, указывающий на состояние буфера «пуст—полон».
Буфер считается пуст, если его структура скопирована либо в ло-
кальный буфер, либо в другой процессорный модуль, и полон, если
копирования не было. Эти два бита являются определяющими для
синхронизации процессов и выполнения команд системы взаимодей-
ствия. Свободные процессы задерживаются при исполнении команд
READ, если буфер пуст, и при исполнении WRITE — если полон.

Программа INTERACTION содержит две основные ветви: про-
грамму декодирования и выполнения экстракодов *TRAPDC и про-
грамму декодирования аппаратных прерываний INTERDC от моду-
лей межпроцессорной связи. Эти две ветви пересекаются, исполь-
зуя общие подпрограммы передачи сообщений через модули связи.
В целом обе ветвп имеют три уровня подпрограмм: обеспечивающий
интерфейс с программой пользователя (первый); выполняющий
формирование сообщений и сборку сообщений (второй); осуществ-
ляющий передачу пакетов через модуль связи (третий). Все уровни
взаимодействуют через передачу параметров и вызов процедур, что
позволяет достаточно просто модифицировать любой из уровней про-
граммы. Выполнение любой ветви программы состоит максимум из
двух фаз посылки—приема запроса и приема—передачи данных.
Каждая из этих фаз выполняется как непрерываемая неделимая
операция.

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

ЛИТЕРАТУРА

1.	Язык программирования АДА: Предварительное описание: Пер. с англ.—
М.: Финансы и статистика, 1981. 189 с.

2.	Hansen Р. R. The Architecture of Concurrent Programmes. N. Y.: Prentice-
Hall, 1977. 317 p.

3.	Wirth N. Modular A Language for Modular Multiprogramming.—Software
Practice and Exper., 1977, vol. 7, p. 3—35.

4.	Mao T. W., Yen R. T. Communication Port: A Language Concept for Concur-
rent Programming.— IEEE Trans, on Software Eng. March, 1980, vol. SE-6,
N 2, p. 194—204.

5.	Ruhr R. ]. A. Concurrent High Level Language Models Applied to Multimi-
croprocessor System Development. Operating Systems. N. Y.r North-Holland,
1978, p. 45-63.

6.	Wirth N. Desing and Implementation of Module.- Software Practice and
Exper., 1977, vol. 7, p. 67—84.
УДК 681.32

ОРГАНИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ПОЛУНАТУРНОГО МОДЕЛИРОВАНИЯ РОБОТОВ

А. И. Казьмин, А. А. Менн, А. А. Петров

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

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

невозможность учета в моделях различных неидеалъностей и
малых параметров сенсоров и эффекторов роботов, а также труд-
ность формального описания внешней среды;

большое машинное время реализации достаточно полных мате-
матических моделей;	4

сложность внесения изменений в программы при модификации
моделей из-за большого числа взаимных связей отдельных блоков
программных реализаций моделей;

необходимость совместного моделирования различных по частот-
ному спектру непрерывных и дискретных процессов, а также логи-
ческих и алгоритмических процедур, разнородных технических си-
стем (от механических конструкций до бортовых ЭВМ).

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

Моделирование принято называть полупатурным, если наряду с
компонентами, реализуемыми на цифровых или аналоговых средст-
вах вычислительной техники, в контуре моделирования используются
и реальные (натурные) элементы моделируемой системы.

Одним из перспективных вычислительных средств для организа-
ции полунатурных моделирующих комплексов являются локальные
сети ЭВМ [1, 2], представляющие собой объединение нескольких
ЭВМ (в общем случае разнородных), от которых требуется возмож-
ность совместного решения единой задачи (в отличие от использо-
вания ЭВМ в глобальных сетях). В то же время локальные сети
имеют принципиальные особенности по сравнению с многомашин-
ными вычислительными комплексами, заключающиеся в наличии
системной поддержки обмена информацией между любыми ЭВМ
сети, а также специальных аппаратно-программных средств, обеспе-
чивающих унифицированное расширение системы за счет подклю-
чения новых ЭВМ и реальной аппаратуры.

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

единая система программирования, позволяющая использовать
Структурная схема комплекса полунатурного моделирования

общий для всей сети язык и устраняющая трудоемкий этап согла-
сования программ, выполняемых на разных ЭВМ;

специальные системные средства для организации параллельных
вычислительных процессов;

системная поддержка контроля и диагностики ошибок при моди-
фикации программных модулей и структуры их взаимосвязей;

простота включения в контур моделирования сенсоров, эффекто-
ров и другой реальной аппаратуры, замены одних элементов дру-
гими, а также замещения их машинными моделями;

интерактивный режим работы не только на стадии подготовки и
отладки модели, но и непосредственно в процессе полунатурных экс-
периментов.

Попытка выполнения некоторых из перечисленных требований
была предпринята при разработке программного обеспечения мно-
гомашинной гибридной вычислительной системы (ГВС) «Русалка»
и создании на ее основе комплекса полунатурного моделирования
роботов [2, 3] (см. рисунок).

Цифровая часть ГВС представляет собой расширяемую локаль-
ную сеть иерархического типа, а аналоговая часть может рассмат-
риваться как один из специализированных процессоров сети. На
верхнем уровне сети используются ЭВМ Единой системы (ЕС), ра-
ботающая под управлением одной из операционных систем, начиная
с версии ОС-4.1 ЕС. На следующем уровне к сети подключаются
ЭВМ типа СМ. Между ЭВМ второго уровня отсутствуют непосред-
ственные интерфейсы, так как программы, выполняемые на этих
ЭВМ, в большинстве случаев независимы друг от друга. Каналы
связи для второго уровня реализованы программно и обмен инфор-
мацией между ЭВМ этого уровня возможен только через ЭВМ ЕС.
К ЭВМ второго уровня посредством системных магистралей могут
подсоединяться микро-ЭВМ, специализированные вычислительные
устройства и реальная аппаратура.

С целью проведения полунатурных исследований роботов ГВС
«Русалка» была сопряжена с электромеханическим манипулятором
типа УЭМ-2 (шесть степеней подвижности, не считая схвата)
[4], а также с телевизионной камерой и другими сенсорами. Си-
стема сопряжения обеспечивает двустороннюю связь эффекторов и
сенсоров робота с вычислительной частью комплекса, контроль пе-
редаваемой информации, возможность подключения дополнительной
реальной аппаратуры. Специально разработанный пульт дистанци-
онного управления позволяет исследователю, находящемуся вблизи
рабочей зоны робота (в удалении от вычислительной системы),
в ходе полунатурных экспериментов удобно взаимодействовать со
всеми подсистемами, менять параметры и структуру исследуемых
моделей и алгоритмов в различных режимах, оперативно наблюдая
соответствующие изменения функционирования робота.

На машинах первого и второго уровней были использованы мо-
дифицированные в разной степени стандартные операционные си-
стемы ЕС и СМ ЭВМ. Выбор типа базовой операционной системы
предопределялся распределением функций между ЭВМ. Для расче-
тов, требующих больших объемов памяти, применяется ЭВМ ЕС.
Этот тип ЭВМ используется также для упрощающих аналитических
преобразований математической модели робота [5]. Как уже отме-
чалось, на верхнем уровне применяется операционная система
ОС ЕС, к которой, помимо пакетов прикладных программ модели-
рования, добавлен системный пакет, обеспечивающий согласование
файловых структур ЕС и СМ ЭВМ. Важной доработкой ОС ЕС, по-
зволившей повысить скорость взаимодействия ЭВМ ЕС и СМ, яви-
лось развитие так называемого графического метода доступа и
объединение его вместе с физическим в новый метод доступа 16].

Большей модификации подверглась использованная в качестве
базовой на втором уровне операционная система реального времени
ОС РВ на ЭВМ СМ-4 — многопользовательская операционная си-
стема, обеспечивающая интерактивный режим работы при подготов-
ке программ [5]. Однако многопользовательский режим почти всег-
да приводит к очень существенному для управляющих ЭВМ не-
достатку — большому времени реакции на внешние прерывания и
обращения к внешним устройствам, в том числе и к аналого-циф-
ровым (АЦП) и цифроаналоговым преобразователям (ЦАП), что
является совершенно недопустимым для робототехнических задач.
Так, для ОС РВ время реакции на прерывание может достигать
5-Ю-3 с. Кроме того, значительные трудности при отладке про-

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

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

Запоминание отложенных прерываний требует небольшой памя-
ти, так как их число не может превышать количество аппаратных
источников.	'

Уменьшение длительности обращения к внешним устройствам

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

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

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

исполнен

как в пользовательском, так и в монопольном режиме.

Переключение с режима на режим происходит при выполнении спе-



циальных команд, введенных в автокод в виде библиотечных мак-

рооператоров. Одновременно с этим переключение может выполнять-
! ся и из программы, написанной на ФОРТРАНе, с помощью обраще-
’ ния к специальным подпрограммам. Как правило, имена и
‘ параметры макрооператоров и подпрограмм идентичны. Введены
следующие основные операторы: RTON — включить монопольный
режим; RTOFF — включить пользовательский режим; INRT — вклю-
чить монопольный режим, запомнив предыдущий; INUSR — вклю-
чить пользовательский режим, запомнив предыдущий; OUT — вер-
нуться в ранее запомненный режим.

Пребывание в монопольном режиме не может продолжаться бес-
конечно долго. С каждым оператором RTON и INRT задается па-

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

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

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

Система программирования построена таким образом, что транс-
ляция всей многомашинной программы осуществляется на одной
ЭВМ. Использование различных трансляторов с одного и того же
языка (например, ФОРТРАНа), входящих в системы программиро-
вания разных ЭВМ (ЕС и СМ), оказалось неоправданным из-за до-
вольно многочисленных различий в диалектах языка.

Если в решении задач используется ЭВМ ЕС, то трансляция и
компоновка всей программы проводится на этой ЭВМ. Машинно-за-
висимые программы представляются совокупностью секций. Каждая
секция может быть написана на языке Ассемблера ЭВМ либо ЕС,
либо СМ. В состав любой секции могут входить специальные опера-
торы взаимодействия между ЭВМ. Кроме того, в секции, предна-
значенные для выполнения на ЭВМ СМ, включаются операторы вза-
имодействия с аналоговой частью и реальной аппаратурой [7].

Единая многомашинная программа обрабатывается претрансля-
тором, в состав которого входит кросс-ассемблер СМ ЭВМ. Он тран-
слирует команды и операторы СМ ЭВМ в операторы порождения
констант языка Ассемблера ЕС ЭВМ. Претранслятор вырабатывает
листинг СМ-программы. После претранслятора программа обраба-
тывается транслятором с языка Ассемблера ЕС ЭВМ, на выходе
которого формируется объектный модуль ЕС ЭВМ и загрузочный
модуль СМ ЭВМ. После сборки и загрузки многомашинной програм-
мы в память ЭВМ ЕС загруженная программа пересылает в ЭВМ
СМ секции, предназначенные для выполнения на машине этого
типа.

Машинно-зависимыми являются и программы на ФОРТРАНе.
Их можно выполнять только на той машине, на которой выполня-
ются трансляция и сборка программы. Единая программа облегчает
организацию взаимодействия между ЭВМ, но в то же время задача
контроля за изменениями, вносимыми в программы в процессе мо-
делирования, не решается. В связи с этим в состав системы про-
граммирования введен машинно-независимый язык, названный
языком компоновки CL [2]. Язык сборки выполняет две роли: исполь-
зуется как универсальный язык Ассемблера и задает структуру про-
граммы. Блоки программы, написанные на языке CL, могут транс-
лироваться в машинные коды ЕС, а также СМ ЭВМ или команды
взаимодействия с реальной аппаратурой в зависимости от той ЭВМ,
на которой будет выполняться этот блок. То, что CL-программы
структурированы по управлению и информационным связям, позво-
ляет организовать строгий контроль изменяемых и вновь вносимых
в программу блоков.

Программа на языке CL представляет собой совокупность взаи-
модействующих блоков. Каждый из них имеет заголовок следую-
щего формата: <имя> BLOCK ((входные параметры>/<выходные
параметры)) (параметры настройки). Списки входных и выходных
параметров разделены, и запрещено использование одних и тех же
имен в обоих списках одновременно. Каждое имя входного и выход-
ного параметра может дополняться указанием его типа. Тип дан-
ных используется для контроля за согласованностью .связей вход-
ных и выходных данных различных блоков. Параметрами настрой-
ки можно задавать назначение блоков на ЭВМ, устанавливать
адреса интерфейсных каналов ЭВМ, если соответствующий блок
должен взаимодействовать с реальной аппаратурой (натурной ча-
стью), определять другие свойства блоков, которые могут изменять-
ся при различных запусках программы.	,

Тело блока может содержать вложенные блоки. Терминальные
блоки представляют собой либо команды универсального ассембле-
ра (такие блоки являются машинно-независимыми), либо секции
одного из ассемблеров ЕС и СМ ЭВМ.

Таким образом, язык CL может задавать структуру и машинно-
зависимых программ. Именно поэтому он рассматривается как язык
более высокого уровня, а транслятор с него выделяет машинно-
зависимые блоки и передает их на вход соответствующего трансля-
тора.

Аналогично системе программирования ЕС ЭВМ построена си-
стема программирования СМ ЭВМ. Для нее разработан транслятор
с языка РЕФАЛ. Это дает возможность ввести кросс-транслятор с
ассемблером в систему программирования СМ ЭВМ и использовать
его (с небольшими модификациями) для получения загрузочных мо-
дулей для ЭВМ типа «Электроника-60».

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

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

Разработанные алгоритмы ввода и анализа сенсорной (в первую
очередь зрительной) информации позволяют в реальном времени
выделять контуры объектов на силуэтных изображениях, осуществ-
лять классификацию этих объектов в соответствии со списком, ука-
занным при обучении, определять координаты их геометрических
центров, а также ориентацию на плоскости [8]. Достоинствами
этой системы являются также автоматический выбор порога кван-
тования видеосигнала и существенная разгрузка цифрового процес-
сора при выполнении операций, связанных с вводом и предвари-
тельной обработкой изображений.

Метод формирования движений манипуляционного робота в не-
знакомой среде, не требующий предварительного анализа вида и
расположения препятствий, описан в публикациях [9—11]. Этот
метод основан на построении пути обхода запретных зон в простран-
стве шарнирных углов и требует лишь локальной информации о на-
личии помехи движению в некоторой окрестности робота. В свобод-
ной зоне траектория движения строится как решение дифферен-
циальных уравнений, минимизирующее рассогласование между
заданным и текущим состояниями робота. При обнаружении пре-
пятствий правая часть этих уравнений видоизменяется так, чтобы
обеспечить в соответствии с разработанными алгоритмами обход как
выпуклых, так и невыпуклых запретных областей в сечениях про-
странства шарнирных углов без застревания в тупиках. Формиро-
вание специальной штрафной функции выполняется аналоговой
частью вычислительной системы, а цифровая часть используется
для управления логикой изменения правой части уравнений генера-
тора движении по сигналам датчиков приближения к препятствиям.
Одновременно с изменениями шарнирных углов формируются и
изменения их производных до требуемого порядка, что облегчает
отработку задаваемых движений эффекторами робота. При этом
можно воспользоваться комбинированной системой управления [3,
10], в которую включается динамическая модель, позволяющая в
значительной мере учесть динамику манипулятора и приводов и
использовать в контурах обратных связей сравнительно простые ре-
гуляторы, на которые возлагается лишь коррекция программного
управления.

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

ЛИТЕРАТУРА

1.	Казьмин А. И., Менн А. А., Пономарев Н. В., Лополитов В. Н. Автомати-
зация полунатурного моделирования на многомашинных комплексах.—
Автоматика и телемеханика, 1982, № 7, с. 157—164.

2.	Казьмин А. И., Менн А. А., Пономарев Н. В. Программное обеспечение ло-
кальной сети ЭВМ, взаимодействующей с реальной аппаратурой.— В кн.:
Применение гибридных вычислительных систем для моделирования и ав-
томатизации научных исследований Под. ред. А. И. Казьмина. М., 1982,
с. 87—105. (Вопр. кибернетики НС по комплексной проблеме «Кибернети-
ка»),

3.	Коган Б. Я., Петров А. А. Гибридные вычислительные системы и модели-
рование роботов.— В кн.: Научные проблемы робототехники. М.: Наука,
1980, с. 34-47.

4.	Попов Е. П., Верещагин А. Ф., Зенкевич С. Л. Манипуляционные роботы:
динамика и алгоритмы. М.: Наука, 1978. 400 с.

5.	Манолов О. В., Пономарев Н. В., Коган Я. С. Пакет программ для получе-
ния динамической модели, используемой в комбинированной системе уп-
равления манипуляционным роботом.— В кн.: Вычислительные процессы
I в гибридных ЭВМ и комплексах: Препр. Ин-та электродинамики АН УССР
Г № 231. Киев, 1980, с. 9—11.

[	6. Казьмин А. И., Менн А. А. Система автоматизации программирования ГВС
«Русалка» для полунатурного моделирования.— В кн.: Автоматизация
i программирования аналого-цифровых и микропроцессорных систем. М.:
; МДНТП, 1982, с. 30—36.

7.	Дудкин М. В., Казьмин А. И., Менн А. А. Гибридный АССЕМБЛЕР. Гиб-
ридный диалоговый отладчик. Математическое обеспечение ГВС «Русал-
ка». М.: Ин-т проблем управления, 1980. 63 с.

8.	Кузъм.ин С. А., Петров А. А. Алгоритмы классификации и определения
параметров силуэтных изображений в системе технического зрения ро-
бота.— В кн.: Проблемы машинного видения в робототехнике. М.: Ин-т
прикл. математики им. М. В. Келдыша АН СССР, 1981, с. 140—151.

9.	Тулепбаев В. Б. Формирование программных движений манипуляционно-
го робота.— В кн.: Проблемы управления в технике, экономике, биологии.
М.: Наука, 1981. с. 191—196.

10.	Petrov A. A., Sirota I. М. Control of a Robot-Manipulator with Obstacle Avoi-
dance under little Information about the Environment: Prepr. of the 8th
triennial World Congr. of IFAC. Kyoto, 1981, vol. 14, p. 54—59.

11.	Петров А. А. Комбинированное управление действиями манипуляционно-
го робота в сложной среде,— PocitaCe a umela intelligencia (Comput. and
Artificial Intelligence), 1982, vol. 1, N 1, p. 83—96.
УДК 621.865		

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
СИСТЕМЫ ГРУППОВОГО УПРАВЛЕНИЯ
ЦИКЛОВЫМИ РОБОТАМИ

В.	3. Рахманкулов, Д. В. Сатаров

Системы управления современных роботов, как правило, разрабаты-
ваются для управления одним, реже двумя роботами (например,
СУ-202М). Система управления может быть создана по принципу
жесткой логики или как устройство с хранимой в памяти програм-
мой. Первое направление, как показывают тенденции развития, все
более ориентируется на конкретное применение, второе — позволя-
ет создавать устройства с большей универсальностью и гибкостью.
При этом применение микропроцессорной техники способствует сни-
жению их стоимости. Быстродействие и производительность микро-
процессоров и микро-ЭВМ, которые быстро совершенствуются,
становятся достаточными для осуществления управления группами
роботов.

Такое построение системы имеет преимущества, когда роботы
расположены вблизи друг от друга и технологический процесс тре-
бует их совместной работы. Задачи синхронизации и обмена данны-
ми при формировании команд управления проще решать в рамках
одного устройства управления.

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

Коррекция параметров может быть осуществлена обслуживаю-
щим персоналом участка с помощью видеотерминала, специального
пульта, вводом с гибкого магнитного диска после подготовки ин-
формации на другой ЭВМ.

Структура аппаратной части. Система строится на базе микро-
ЭВМ (например, СМ-1800) или микроконтроллера, использующих в
качестве центрально го процессорного элемента микропроцессор
КР580ИК80А и имеющих более 8К байт оперативной памяти.

Основными элементами одного из вариантов системы управления
роботами (рис. 1) являются:

микро-ЭВМ СМ-1800 с видеотерминалом и внешним запоминаю-
щим устройством (ВЗУ) на гибких магнитных дисках;

интерфейс (радиальный, последовательный);

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

Особенностью системы является то, что команды управления все-
ми роботами и ответные сигналы передаются по одной слаботочной
линии интерфейса, максимальная длина которой может составлять
500 м, а токи управления роботами формируются в схеме сильно-
точных коммутаторов, которая располагается в непосредственной
близости от роботов. Таким образом, микро-ЭВМ и ее периферий-
ные устройства (ВЗУ, видеотерминал и др.) могут быть вынесены
в отдельное помещение.

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

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

Все эти процессы должны протекать в реальфом масштабе вре-
мени, т. е. время также является параметром системы, что накла-
дывает дополнительные трудности на этапе создания и отладки про-
граммного обеспечения [2].

В связи с этим целесообразно создавать программное обеспече-
ние системы на базе универсального монитора (или диспетчера) ре-
жима реального времени [3]. Общая структура программного обес-
печения системы показана на рис. 2.

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

Системный монитор позволяет обслуживать программы в двух
режимах: реального времени и разделения времени. В первом слу-
чае механизм обслуживания программ строится на основе фиксиро-
ванных приоритетов, которые присваиваются программам реального
времени — модулям системы. В течение определенного периода вре-
мени обслуживается программа с наивысшим приоритетом, а затем
монитор запрещает все прерывания и проверяет, не появились ли
программы с более высоким приоритетом в очереди программ,
ожидающих обслуживания. Продолжительность такого анализа со-
ставляет для данного монитора реального времени и микро-ЭВМ
СМ-1800 от 0,2 до 1 мс, что вместе с выбранным квантом времени
обслуживания программ определяет реакцию системы на поступаю-
щую информацию.

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

Монитор реального времени. Монитор занимает приблизительно
1К байт оперативного запоминающего устройства (ОЗУ) для своих
программ и еще приблизительно 1К байт для таблиц и данных.
Рис. 1. Структурная схема аппаратной части системы управления роботами

Программа изменения параметров системы	Программа формирования команд управления	Программа связи с роботами
Программа связи с ВЗУ	Монитор реального времени (диспетчер)	
Программа связи с видеотерминалом	Программа формирования команд управления в ошибочных ситуациях	

Рис. 2. Структура программного обеспечения системы управления роботами

Возможности монитора:

обслуживание программ реального времени в заданный момент
времени;

обслуживание программ реального времени с заданной частотой;

реализация задержки до начала обслуживания программ реаль-
ного времени;

немедленное начало обслуживания программы реального време-
ни без задержки;

прерывание программ реального времени;

обнуление статуса прерывания программ реального времени;

изменение начального адреса программы реального времени;
создание новой программы реального времени;

занесение программы реального времени в очередь программ ре-
жима разделения времени;

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

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

Каждая программа, которая работает под управлением монито-
ра реального времени, имеет свое стандартное описание — дескрип-
тор, куда заносятся основные параметры программы. Все дескрип-
торы имеют длину 32 байта и располагаются строго последователь-
но в ОЗУ микро-ЭВМ. Совокупность дескрипторов образует
таблицу основных параметров программ.

Когда нужно, чтобы программа реального времени начала вы-
полняться, она активизируется соответствующей системной командой
и помещается в очередь в соответствии со своим приоритетом вме-
152
Пози- ция	Номер байта	Содержимое
Ml	00	Адрес следующего де- скриптора в очереди
	01	
М2	02	Приоритет программы
М3	03	Статус регистра
	Бит 0	Программа обслужива- ется
	Бит 1	Программа преждевре- менно снята с обслу- живания
	Бит 2	Определен период вре- мени
	Бит 3	Программа помещена в очередь режима-ре-
		ального времени
	Бит 4	Обслуживание про- граммы прерывалось
	Бит 5	Программа ожидает об-
		служивания
	Бит 6	Программа помещена в очередь режима раз- деления времени
	Бит 7	Используется статус регистра 2
М4	04	Время до начала еле-
	05	дующего обслужива- ния
М5	06	Интервал времени меж-
	07	ду прекращением об- служивания программы и началом следующего обслуживания

Пози- ция	Номер байта	Содержимое
Мб	08	Адрес входа в про-
	09	грамму
М7	10	Адрес входа в про-
	И	грамму после прерыва- ния
М8	12	Число обслуживании
	13	программы
М9	14	Общее время обслужи-
	15	вания
М10	16	Максимальный интер-
	17	вал времени обслужи- вания программы на одном шаге
МИ	18	Адрес первого байта 'текста программы
	19	
М12	20	Адрес последнего байта
	21	текста программы
М13	22	Статус регистра 2
М14	23  24	Указатель стека
М15	25	Дополнительные байты
М19	31	

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

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

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

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

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

продолжение работы системы (управление возвращается в про-
грамму формирования команд для роботов, задержка учитывается):

запрещается внесение новых деталей в систему, продолжение
обработки деталей, уже внесенных в обрабатывающую линию;

управление роботами передается оператору;

останов.

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

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

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

Команды управления роботами. Каждое управляющее слово име-
ет стандартный формат 2 байта. В управляющих словах использу-
ется смешанное кодирование команд:

(1 (2 (3 (4 (5 (6 (7 (8)
(9 (10 (И (12 (13 (14 (15 (16)

Коды команд управления представлены в табл 1
Номер бита	Значение
1-3  4	Номер робота в системе счисления по основанию 2  Наличие «1» означает движение по рельсовым путям к ванне с номером, который указан в позициях (9-13) и (14-16)
5-6	«10» - опускание схвата в ванну  «01» - подъем схвата из ванны
7-8	«10» - захват детали  «01» - опускание детали
9-13  14-16	Номер ванны в системе счисления по основанию 2  Номер позиции в ванне в системе счисления по основанию 2

Серия команд управления для каждого из роботов передается
но радиальному последовательному интерфейсу,'и после их выпол-
нения устройство сопряжения выдает ответные сигналы.

Серия команд содержит информацию об одиночных тактах дви-
жения для каждого из роботов. Если к микро-ЭВМ приходит со-
общение, что команда не выполнена, либо сообщение вообще от-
сутствует, то на экране видеотерминала высвечивается содержимое
серии команд и управление передается программе управления в
ошибочных ситуациях.

‘	ЛИТЕРАТУРА

Т.

f 1. Макаров И. М., Рахманкулов В. 3. Групповое управление роботами-манипу-
ляторами с распределенно-централизованной организацией обработки ин-

|	формации.— В кн.: Микропроцессорные системы управления в робототех-

нике. М.: Наука, 1984, с. 35—45.

2.	Мартин Дж. Программирование для вычислительных систем реального
времени. М.: Наука, 1975. 359 с.

3.	Шоу А. Логическое проектирование операционных систем. М.: Мир, 1981.
360'с.
, АЛГОРИТМЫ

4 УПРАВЛЕНИЯ РОБОТАМИ

УДК 621,865.8,001.1

СИСТЕМА УПРАВЛЕНИЯ РОБОТОМ
КАК КОНЕЧНЫЙ АВТОМАТ

С.	Л. Зенкевич, А. В. Назарова

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

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

Простая система управления. Прежде чем перейти к формализа-
ции грамматики входного языка, познакомимся в качестве иллюстра-
ции с гипотетической системой позиционного управления роботом,
включающей в себя, в частности, пульт, позволяющий вводить с по-
мощью кнопок следующие команды: АВТОМАТ (а), ШАГ (иг), ОБУ-
ЧЕНИЕ (о), ВВОД (в), ЗАПОМНИТЬ (з), СТОП (с), (в скобках да-
ны сокращения, используемые ниже). Пусть каждая точка позициони-
рования, в которую требуется перевести схват манипулятора,
характеризуется набором чисел, однозначно определяющих конфигу-
рацию манипулятора, а также скоростью перемещения схвата к этой
точке. Будем этот набор данных называть кадром.

Работа системы с точки зрения пользователя заключается в сле-
дующем. Нажатие кнопки «ОБУЧЕНИЕ» переводит систему в режим
обучения, в котором оператор может некоторым образом выставить
требуемую конфигурацию манипулятора и, нажав кнопку «ЗАПОМ-
ПИТЬ», записать текущее состояние исполнительного механизма в
требуемом формате в кадр. Для окончательного формирования кадра
вводится с помощью переключателей и кнопки «ВВОД» значение
скорости. Кнопки «АВТОМАТ» и «ШАГ» обеспечивают соответст-
венно непрерывное и пошаговое исполнение сформированной програм-
мы движения. Кнопка «СТОП» аварийно прерывает работу системы.

Набор приведенных выше команд отражает потребности опера-
тора, связанные с обучением и управлением манипуляционным робо-
том, в общих чертах совпадает с командами существующих в на-

стоящее время пультовых систем управления.

Рис. 1. Структурная схема системы управления с функциональным пультом в качестве
задающего устройства

Грамматика языка управления. Уже приведенный пример прос-
той пультовой системы демонстрирует необходимость следования
некоторым правилам при вводе оператором команд в процессе обу-
чения и управления роботом, которые можно рассматривать как пра-
вила построения синтаксически верных конструкций входного языка
системы управления L(G), порожденного некоторой грамматикой G.

Напомним, что грамматикой G называется четверка (Г, N, В, Р),
где Т — множество терминальных символов; А —множество нетерми-
нальных символов; B^N — начальный нетерминальный символ; Р —
множество правил подстановки (продукций) [1, 2]. Тогда порождае-
мым грамматикой языком L(G) называется множество цепочек тер-
минальных символов, выводимых из В с помощью продукций Р.

Будем рассматривать каждую команду оператора (или соответст-
вующую кнопку пульта управления) как терминальный символ из Т,
а последовательность команд — как слово, порожденное грамматикой
G. Тогда для рассмотренного выше примера системы управления
грамматика входного языка будет иметь следующий вид:

Г={а, ш, о, в, з, с}

А= {КОМАНДА, АВТОМАТ, ШАГ, ОБУЧЕНИЕ, СКОРОСТЬ}

В= КОМАНДА

Р= {КОМАНДА ->а АВТОМАТ

КОМАНДА -*ш ШАГ

КОМАНДА -*о ОБУЧЕНИЕ

КОМАНДА ->-с КОМАНДА

АВТОМАТ -*с КОМАНДА

ШАГ -*ш ШАГ

ШАГ ->-а АВТОМАТ

ШАГ ->с КОМАНДА

ОБУЧЕНИЕ-^з СКОРОСТЬ
ОБУЧЕНИЕ -*с КОМАНДА
ОБУЧЕНИЕ -+а АВТОМАТ
СКОРОСТЬ -*в ОБУЧЕНИЕ
СКОРОСТЬ —>-с КОМАНДА}.

• Заметим, что наличие рекурсии в правилах подстановки для нетер-
миналов ШАГ и ОБУЧЕНИЕ позволяет легко осуществить цикличе- ?
ски повторяемые операции, в данном случае — это пошаговое испол- j
нение программы движения и запоминание параметров точек пози-
ционирования в режиме обучения.

Примером допускаемых грамматикой цепочек (или последователь-
ностей вводимых оператором команд) являются, например, следую-
щие: «ас» (автоматическое исполнение сформированной ранее
программы движения); «шшша» (обход трех точек позиционирования
в шаговом режиме и дальнейшее исполнение программы в автомати-
ческом режиме); «озвзва» (формирование программы движения, .
состоящей из двух точек, и ее исполнение). На рис. 2 показана сеть
переходов [3], графически иллюстрирующая правила подстановки
Р, и представляющая собой ориентированный граф, узлы которого
соответствуют нетерминальным символам, а дуги — терминальным.
На рис. 3 показаны деревья грамматического разбора слов, приведен-
ных выше в качестве примеров допускаемых грамматикой последо-
вательностей.

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

A+tB

A-tC

B+gD

С-+hE,

где t, g, h^T — терминальные символы, а А, В, C, D, E — нетерми-
нальные символы, не может служить порождающей грамматикой для
языка системы управления с пультом в качестве задающего устройст-
ва (на рис. 4 показан фрагмент соответствующей сети переходов),
поскольку на появление во входной последовательности символа (или
команды) t система не может соответствующим образом отреагиро-
вать до тех пор, пока не появится следующий за t символ (в рассмат-
риваемом случае это символы g или h).

Для того чтобы грамматика могла порождать устраивающий нас
язык, достаточно, чтобы все продукции удовлетворяли следующим
двум условиям:
КОМАНДА

Рис. 2. Граф переходов конечного автомата для простой системы с функциональным

пультом в качестве задающего устройства

Рис. 4. Пример грамматики, недопустимой для языка системы управления с пультом
в качестве задающего устройства

а

КОМАНДА

АВТОМАТ

Рис. 3. Грамматический разбор слов
а — «ас»; б — «шшша» ; в — «озвзва»

КОМАНДА

КОМАНДА

ШАГ

ШАГ

ОБУЧЕНИЕ

ОБУЧЕНИЕ

Рис. 3

ОБУЧЕНИЕ

АВТОМАТ
альтернативные замены одного и того же символа должны начи-
наться с различных терминальных символов:

Уо —> tiNi)

правая часть каждой продукции должна начинаться терминалом:
если Уо~то а^Т ($e=TUN).

Такие грамматики называются 5-грамматиками [1]. Заметим,
что рассмотренный выше в качестве примера язык управления порож-
ден 5-грамматикой.

Система управления как конечный автомат. Проектирование алго-
ритмов, осуществляющих грамматический разбор входных последо-
вательностей, представляет собой сложную задачу [1, 2], кроме
того, сами программные модули, реализующие грамматический раз-
бор, довольно громоздки, что делает практически невозможным их
использование в условиях ограниченной памяти ЭВМ (алгоритмы
грамматического разбора составляют основную компоненту трансля-
торов с языков программирования). Второе условие эквивалентно
тому, что входной язык является регулярным (т. е. порожденным
грамматикой, все продукции которой имеют вид	и, следо-

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

Конечный автомат К есть пятерка (5, 50, Т, Р, F), где S — конеч-
ное множество состояний автомата; S^S — начальное состояние;
Т — конечный входной алфавит; Р — отображение множества SXT
в S, определяющее правила перехода автомата из одного состояния
в другое как функцию текущего состояния и входного символа;
F^S — множество заключительных состояний автомата [3, 4].

Для того чтобы получить описание конечного автомата, распой/
нающего регулярное множество, порожденное описанной выше грам-
матикой, необходимо выполнить следующие операции:

считать терминальное множество грамматики входным алфави-
том автомата;

считать нетерминальное множество грамматики множеством со-
стояний автомата, а начальный символ — начальным состоянием;

включить в число правил перехода автомата переход из состоя-
ния А в состояние В по входу t, если грамматика содержит продук-
цию A-+tB.

Тогда применительно к рассмотренной системе управления мани-
пуляционным роботом атрибуты конечного автомата выглядят сле-
дующим образом:

5={КОМАНДА, АВТОМАТ, ШАГ, ОБУЧЕНИЕ, СКОРОСТЬ}
5„=КОМАНДА

Т={а, ш, о, в, з, с).

Правила перехода Р можно представить в виде графа (он совпа-
дает с графом, изображенным на рис. 2). Поскольку цепочки входных
символов не имеют признака окончания, все состояния являются
допустимыми, т. е. F=S.
Расширенный конечный автомат. Использование формализма ап-
парата конечных автоматов в том виде, в каком он здесь был сформу-
лирован, для некоторых прикладных задач бывает неудобно. Дейст-
вительно, рассмотрим такую ситуацию, когда один из параметров,
характеризующих точку позиционирования, например скорость,
остается неизменным для всех точек формируемого задания, хотя и
может меняться от одного задания к другому. Тогда целесообразно
определить этот параметр в самом начале процесса обучения, а не
вводить его для каждой точки позиционирования отдельно. Такая
система умолчаний бывает чрезвычайно удобна, особенно для систем,
характеризующихся большим количеством параметров, описывающих
точку позиционирования, ввод которых существенно увеличивает
затраты времени на обучение, в то время как использование системы
умолчаний значительно повышает эффективность процесса обуче-
ния. Непосредственное использование сформулированного выше
подхода приводит к необходимости работы с языками, порожденными
_контекстно-зависимЬ1МИ грамматиками. Действительно, некоторые
: продукции, определяющие грамматику, в этом случае будут иметь
I следующий вид:

PisA-^ptstB

p2sA-+pzstC,

где з — сентенциональная форма.

Таким образом правила подстановки будут зависеть от того, ка-
кой терминальный символ (рг или р2) вводился на этапе формирова-
ния умолчаний.

Известно, что работа с контекстно-зависимыми грамматиками
существенно затруднена. Воспользуемся тогда следующим подходом.
Введем в описание конечного автомата вектор переключателей
П= (л,, л2, • • •, л„) с целочисленными компонентами. В этом случае
формальное описание расширенного конечного автомата будет вы-
глядеть следующим_ образом. Расширенным конечным автоматом К
назовем шестерку К= (S, £0, П, Т, Р, F), где £ — конечное множество
состояний автомата; S^S начальное состояние; П — вектор переклю-
чателей с целочисленными компонентами; Т — конечный входной
алфавит; Р — отображение множества £ХПХ7’ в S; F—SxH — мно-
жество заключительных состояний автомата. Заметим, что одним из
отличий такого конечного автомата от обычного является расшире-
ние области определения отображения Р.

Применим этот подход к рассмотренной системе управления с
функциональным пультом в качестве задающего устройства. Пусть
переключатель л принимает два значения:

( 0, если скорость вводится явно,
Л - Л л

(1, если скорость вводится по умолчанию.

Тогда расширенный конечный автомат может быть описан сле-
дующим образом:

5= {КОМАНДА, АВТОМАТ, ШАГ, ОБУЧЕНИЕ, СКОРОСТЬ)
П={л)
рационной системы, функционирующих

50=КОМАНДА

Г={а, ш, о, в, з, с}
при графе переходов,
представленном на
рис. 5.

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

в условиях развитого диалога

оператор-робот.

В систему управления с функциональным пультом, реализован-
ную на базе ЭВМ «Электроника-60», входили пульт обучения, со-
держащий 16 кнопок (т. е. оператор мог ввести 16 команд), три
10-позиционных переключателя для ввода данных в диапазоне О—
999, а также индикационное устройство, позволяющее выводить стро-
ку из 16 символов. Эквивалентный конечный автомат мог находить-
ся в 35 состояниях. Каждая точка позиционирования характеризо-
валась шестью координатами и четырьмя параметрами, три из
которых вводились с использованием системы умолчании (предва-
рительной настройки автомата).

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

Пусть, например, манипулятор должен обойти следующую после-
довательность точек: Р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, ...

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

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

* * *

Примененный для проектирования программного обеспечения робо-
тотехнических систем подход, основанный на представлении системы
управления робота как конечного автомата, позволяет:

получить хорошо структурированное программное обеспечение
робототехнического комплекса;

обеспечить эффективную реализацию языка обучения и управ-
ления в системе с функциональным пультом в качестве задающего
устройства;

эффективно и экономно (как с точки зрения быстродействия,
так и с точки зрения занимаемой памяти) строить программное
обеспечение.

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

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

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

ЛИТЕРАТУРА

1.	Льюис Ф., Розенкранц Д., Стирнз Р. Теоретические основы проектирования
компиляторов. М.: Мир, 1979. 654 с.

2.	Вайнгартен Ф. Трансляция языков программирования. М.: Мир, 1977. 190 с.

3.	Хант 9. Искусственный интеллект. М.; Мир, 1978. 558 с.

4.	Биркгоф Г., Барти Т. Современная прикладная алгебра. М.: Мир, 1976.
400 с.
п

УДК 007.52

СИНТЕЗ

ПРОГРАММНЫХ КОРРЕКТИРУЮЩИХ ЗВЕНЬЕВ
ЦИФРОВОЙ СЛЕДЯЩЕЙ СИСТЕМЫ

ПРОМЫШЛЕННОГО ОКРАСОЧНОГО РОБОТА «КОЛЕР»

В. И. Григорьев, С. А. Чевтаев

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

Функциональная схема цифровой следящей системы одного
звена робота показана на рис. 1. Управляющее воздействие, которое
должно быть выработано в микро-ЭВМ «Электроцика-60» на основе
хранящейся в памяти информации о траектории, заданной при обу-
чении и считанной с модуля текущей координаты (МТК) информа-
ции о фактическом положении манипулятора, подается на модуль
управления координатой (МУК). Чтение модуля текущей координа-
ты и засылка управляющего воздействия на модуль управления
координатой осуществляются по сигналу прерывания от таймера с
периодичностью То.

Модуль управления координатой состоит из накопителя (ревер-
сивного счётчика) с двумя входами — положительным (от ЭВМ) и
отрицательным (от датчика углового положения) — и подсоедйнен-
ного к его выходу 10-разрядного цифроаналогового преобразователя
(ЦАП). Работа накопителя может быть описана следующими урав-
нениями:

o(i)=c„u-(cp(i)-<po),

ont7=Cn-i+C/n	(1)

при nTBKt< (n+l)/^ (re=0, 1,2,...).

Здесь o(i) — выходная величина накопителя в момент времени t;
опи — составляющая выходной величины накопителя, соответствую-
щая входу со стороны ЭВМ, в течение интервала времени nT0^t<
<(n+l)7’(); Un — управляющее воздействие, поданное из ЭВМ на
модуль управления координатой по re-му прерыванию от таймера,
т. е. в момент времени t=nT<>', cp(i) —фактическое положение мани-
пулятора в момент времени £; <ро=<р(О); 1=0, п=0 — соответствуют
началу работы программы воспроизведения.

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

Датчик углового положения — фотоэлектрического типа, 11-раз-
рядный. Однако принятая схема считывания использует его младший
разряд для определения направления движения, вследствие чего
число уровней отсчета (при движении в одном направлении) соответ-
ствует 10-разрядпому датчику, т. е. равно 1024. Тем не менее в каче-
стве единицы измерения углового положения используется дискрета
ll-разрядного датчика. Кроме того, датчики трех наиболее протя-
женных звеньев («руки»), в основном определяющих пространствен-

Рис, 1. Функциональная схема цифровой следящей системы одной координаты робота
«Колер»

ное положение рабочего органа (распылителя), для уменьшения
цепы дискреты подсоединены к своим звеньям через редукторы с
передаточным отношением 1 :4. Таким образом, для указанных
звеньев цена дискреты равна 360° : 4:2048=0,0439°, а для двух
«кистевых» звеньев она равна 360°: 2048=0,1758°.

Синтез программных корректирующих звеньев, т. е. вывод фор-
мул, по которым должно рассчитываться в ЭВМ управляющее
воздействие, был осуществлен на основе экспериментально опреде-
ленных динамических характеристик объекта управления, под кото-
рым понималась вся внешняя по отношению к управляющей ЭВМ
часть цифровой следящей системы (см. рис. 1). Были определены
импульсные переходные характеристики объекта управления путем
подачи в течение такта времени на модуль управления координатой
импульса с амплитудой £70 и регистрации с модуля текущей коорди-
наты фактического положения звена манипулятора <р„; импульсная
характеристика для момента времени t=nT0 определялась по
формуле

со (геТо) (нТо),

где коэффициент усиления объекта управления

- fc=(cpoo—фо)/СЛ>;

нормированная импульсная переходная характеристика

h (пТ0) = (ф„—ф0) / (ср.»—ср0).

Импульсная характеристика объекта управления является одно-
временно в силу уравнения (1) переходной характеристикой той
Рис. 2. Импульсные переходные характеристики объекта управления ЦСС первой коор-
динаты робота «Колер» при различной амплитуде импульеа С70

1 — ±50; 2 — ±100; 3—±200; 4 — ±300; точки — расчетные значения по формуле (2)
при Т,=0,77 с, 7’2=0,06 с

Рис. 3. Структурная схема линейной модели объекта управления

непрерывной части объекта управления, входом которой служит
выход канала цифрового интегратора сигнала от ЭВМ.

Экспериментально определенные коэффициенты усиления при
средней и большей амплитуде импульса близки к единице, а при ма-
лых амплитудах — нелинейно зависят от £70. Типичные нормирован-
ные импульсные характеристики первой координаты робота показаны
на рис. 2. Факт их различия при разной амплитуде импульса также
свидетельствует о нелинейности реального объекта. Там же показаны
расчетные значения, соответствующие переходной характеристике
апериодического звена второго порядка:

h(0 =1—7’1/ (7’1-7’2) •е-,/г‘+Т’2/ (Т,~Т2)(2)

где Г,=0,77 с, Т2=0,06 с постоянные времени. Сопоставление расчет-
ных значений с экспериментальными кривыми показывает, что не-
прерывная часть объекта управления в линейном приближении мо-
жет быть описана апериодическим звеном второго порядка.

Таким образом, объект управления можно представить в виде
линейной модели (рис. 3), первое звено которой — цифровой инте-
гратор [см. уравнение (1)] со входом только от ЭВМ, второе — экстра-
полятор нулевого порядка или фиксатор [1, с. 61], третье — аперио-
дическое звено второго порядка.

Найдем дискретную передаточную функцию объекта управления
Wo (z);

Так как дискретная передаточная функция непрерывной части
объекта управления с экстраполятором пулевого порядка может быть
представлена в виде

W / \	1 ф( 1	1	1 _

z | s у/'Щ’Д1) (7'^’4 1) i

'• _ z-1 a-jl T^(I\-T2)	- T2) 1

““ z { S T±S 4- 1	' T2S +1 J

__ z — 1 / z	Г1 z .___________T2 z \________

Z \ Z — 1	T1 — T 2 z —’	T1 — 7 2 Z — d2 )

__ z 4- b

a di) (z — d2) ’

где (Л=ехр(—7’0/7’1),	d2=exp(-Z’ JT2),

а=(7’1(1-^)-7,2(1-^))/(Л-7’2),

A— T2 (1 — <Z2) <7t — Tj (1 — d,) d2

Л (1 - di) - T2 (1 - d2)

то дискретная передаточная функция объекта управления есть

Ю,С) = ~+т~ W« W = —<"-t,)i, - «) •	<3>

Зададимся требованиями к качеству управления. Имея в виду
практически необходимую точность движения в процессе окраски,
а также то обстоятельство, что вследствие нелинейности реального
объекта действительная точность будет несколько хуже расчетной
при использовании линейной модели, примем для синтеза корректи-
рующих звеньев следующие требования к качеству цифровой следя-
щей системы:

максимальная ошибка еПих при отслеживании гармонического
задающего воздействия вида [2, с. 31]

g(nT0)—gn=A sin (юГоп)

(4)

с амплитудой Л=500 дискрет и круговой частотой ю^1с-1 в устано-
вившемся режиме должна быть не более 4 дискрет (на конце «руки»
манипулятора это соответствует максимальной ошибке 5 мм при мак-
симальной скорости 610 мм/с);

запас устойчивости должен соответствовать показателю колеба-
тельности Л/^1,5 [2, с. 40].

С целью достижения указанных достаточно высоких требований
зададимся структурой цифровой следящей системы комбинированного
типа (рис. 4), включающей в себя корректирующее звено в разомкну-
том контуре (IVK(z)) и последовательное корректирующее звено в
замкнутом контуре IVv(z). Задержка между задающим воздействием
g и формированием ошибки e„=g„-i—<рп введена в связи с тем, что
вследствие аппаратной реализации управляющее воздействие, вычис-
ленное после га-го прерывания таймера, засылается на модуль управ-
ления координатой ио (п+1)-му прерыванию, т. е. передаточные
функции корректирующих звеньев отличаются от передаточных
функций, соответствующих вычислительным формулам, задержкой
на такт:

WK(z)=WK”(z)z-1,	IPp(z)=Wp"(z)z-‘.

Передаточная функция по ошибке цифровой следящей системы
принятой структуры записывается.в виде

ф ( Е<У1 _ г-1 -wk(z)wo (г)

Фе^~ G(Z)~ l + V7p(z)IP0(Z) '

Эту передаточную функцию можно представить также в виде
произведения

Фе(2)=Фе‘1(2)ФеР(2),

Рис. 4. Структурная схема цифровой следящей системы одной координаты робота
«Колер»

передаточных функций по ошибке разомкнутого контура

OeK(z)=z-1-WK(z)Wo(z)	(5)

и замкнутого контура

Фе₽(г)=1/(1+Жр(г)Жо(г)),	(6)

а саму ошибку ЦСС в целом — как ошибку отработки замкнутым кон-
туром

£'(z)=Oep(z)£K(z)	(7)

ошибки разомкнутого контура

£K(z)=CV(z)G(z).	(8)

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

Попытаемся определить его передаточную функцию из условия
Ф/(z)=0, т. с. из условия идеально точного воспроизведения задаю-
щего воздействия разомкнутым контуром (с задержкой по времени
па один такт):

WK (z) Wo (z) = И\-« (2) z-i Wo (z) = z-\	(9)

Из уравнения (9) с учетом выражения (3) получим

ту в (z\ —	1	— 1 (z — П (z — ^i)	/4 n\

Wg.(z) ~ a	z(z + b)	•
Передаточную функцию (10) можно реализовать наиболее просто
с помощью следующей вычислительной формулы:

. V ,Т'В = XVgn + [Л (Vgn+1 — Vgn) + V (Vg„+1 — 2Vgn + Vgn-!) — bUn-u

(H)

где Un B — управляющее воздействие компенсатора, вычисляемое
после ra i’o прерывания таймера; Vg„=gn—gn-i— первая обратная
разность задающего воздействия, которая записывается в память
системы управления при обучении [3]; Х= (1—di—d2+dld2'); ц=
= (1—cZid2)/n; v=did2/a.

На выполнение содержащихся в формуле (11) четырех умноже-
ний и шести сложений на микро-ЭВМ «Электроника-60» необходимо
8 мс, что при пяти управляемых звеньях выдвигает требование
7’()>40 мс. Помимо этого, понадобится время для реализации коррек-
тирующего звена в замкнутом контуре и на отработку технологиче-
ских операций. Таким образом, реализация идеального компенсатора
(10) связана предположительно с необходимостью выбора достаточно
большого периода квантования по времени. Это весьма нежелательно
для работы замкнутого контура, которая будет необходима, посколь-
ку ввиду нелинейности реального объекта управления, неточности
оценки его параметров и их изменения во времени рассматриваемый
компенсатор не сможет обеспечить на практике нулевую ошибку.

Попробуем упростить компенсатор. Используем тот факт, что
T^Ti. Пренебрежем Т2. При 7’2=0 имеем

<72=0, а=1—di, b=0, X=l, v=0,	(12)

ц=1/ (1—di)

и алгоритм (10) упрощается до вида

tAr = Vgn + p(Vgll+I-Vgn),	(13)

т. е. содержит всего одно умножение и два сложения. Это позволяет
уменьшить затраты времени на реализацию компенсатора по сравне-
нию с ранее рассмотренным вариантом в четыре раза.

Примем в качестве алгоритма вычисления управляющего воздей-
ствия компенсатора формулу (13), которой соответствует следующая
передаточная функция компенсатора:

17е(2)=ц(2-1)(2-(ц-1)/ц)/22.	(14)

Однако коэффициент ц выберем не по выражению (12), а из ус-
ловия достижения наивысшего возможного порядка астатизма.

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

к , _ (z - di) (z - d2) - pa (z - (p - l)/p) (z -|- 6)

l e	z (z - djlz - d2)
Согласно формуле (8) и теореме о конечном значении [1, с. 42]
установившееся значение ошибки разомкнутого контура будет равно

Boo = lim|^rJ_QE«(2)G(z)}.	(16)

Таким образом, для достижения наивысшего порядка астатизма
необходимо, чтобы числитель ФЕк(г) (см. выражение (14)) содержал
наибольшую возможную степень (z—1), т. е. в данном случае имел бы
множитель (z—I)2. Нетрудно убедиться, что при Ц--Ц*, где

ц* =--------( —-----. —Ъ.—\	(17)

Л - Тг Н - di l-d2 )'	, [ 1

имеют место следующие соотношения:

(z—d,) (z—d2)—p*a(z—(ц*—l)/p*) (z+&) = (1—р*а) (z—I)2,

_______Т^г (d, - d2y_________(z - I)2	18

— (Л - zvp (1 - dt) (1 - d2) z (z - d^ (z - d,) •	'

Подстановка выражения. (18) в соотношение (16) показывает, что
при ступенчатом задающем воздействии (скачке по положению), т. е.
при

gn = А01 (n), G (z) = Aoz[(z — 1),
и линейном задающем воздействии (скачке по скорости), т. е. при

gn = ATo^l (л), G (z) = АХТО	,

установившаяся ошибка равна нулю, а при параболическом задаю-
щем воздействии (скачке по ускорению), т. е. при

gn = 1/2A27’o2n2l(H),

G(z) = 11гА2Т0Ч (z + l)/(z — I)3,

установившаяся ошибка отлична от нуля и равна

8°° — А2Т02Т1Т2 [ (1 _ dl) (1 _	(Г1 _ Гг)

Таким образом, компенсатор с алгоритмом (13) и коэффициентом
ц, определенным согласно формуле (17), даже без корректирующего
звена в замкнутом контуре обеспечивает астатизм второго порядка
цифровой следящей системы с объектом управления, описываемым
уравнением (13).

Заметим, что при 7\/7’о>4и TjT^l формула (17) для расчета
коэффициента ц* с высокой степенью точности (погрешность менее
0,5 %) может быть заменена простой приближенной формулой

р*=(7’1+Т3)/7’о+О,5.

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

Из формулы (6) с учетом выражений (5), (7) и (17) имеем

Wp (z) Wo (z) + 1 = ФЕК (2) G {z)!E (z) =

_	Т\Тг (rfi - rf2)2 - I)2	G (z)

(r1-T’2)a(l-d1)(l-d2)z(z-d1)(z-d2) E(z) '

Подставляя в это выражение

z=(l+A7’o/2)/(l-^7,o/2)	(19)

и обозначая

^(А)=ИМА)ИМА),

для дискретной частотной характеристики замкнутого контура цифро-
вой следящей системы W(jk), которая при псевдочастоте Z.<0,5/7’0
практически совпадает с круговой частотой со, получим следующее
соотношение:

ww+1=]2х '

х (А )й (1 - & 4-) G (А) / (1 + А -4 таг) х

х (1 + А4'таг)(1 + А^)Е(А)-

Возьмем модуль от обеих частей этого уравнения и, учитывая, что
в области низких частот

| ИДА)+11 — 1 ИДА) |,

а также тот факт, что при гармоническом задающем воздействии (4)
|G(A)|=H, а \Е (jh) | =smax — максимальной ошибке при его отра-
ботке, получим для модуля частотной характеристики замкнутого
контура следующее условие типа запретной области:

Iw	^гх7([‘ +

+(4-ГМ1Г-	™

Далее синтез регулятора проводился частотным методом с исполь-
зованием логарифмических амплитудных (L) и фазовых (Ф) частот-
ных характеристик (рис. 5).

Объект управления имеет следующую дискретную частотную ха-
рактеристику, определяемую путем подстановки выражения (19) в
Рис. 5. Логарифмические амплитудные L и фазовые ф частотные характеристики, ис-
пользуемые при синтезе последовательного корректирующего звена в замкнутом кои-
туре

Ьнск, фиск — нескорректированная цифровая следящая система; Ьпд, фпд — характери-
стики с ПД-регулятором; Ln — с П-регулятором; I и II— запретные области для ампли-
тудной и для фазовой характеристик соответственно

формулу (3):

Ж0(А) =

1

То



/, . .. То 1 + di \ / Т<

(21)

1 4~ ^2 \

i -d2;

а частотная характеристика нескорректированной системы отличает-
ся от выражения (21) лишь дополнительным фазовым множителем
(1—j'kTo/2') / (1+]КТо12), порождаемым задержкой на один такт между
опросом модуля текущей координаты и выдачей управления на мо-
дуль управления координатой.

Замкнутая система без регулятора (нескорректированная) не-
устойчива (ср. £нск И 1|)Hck).

Использование регулятора пропорционально-дифференциального
типа с алгоритмом

"=аеп+^(еп—8п-1),	-	(22)

дискретной передаточной функцией

Wp (z) = ((a+f)z-f) /z2

и дискретной частотной характеристикой

ТГР (А) = а (1 4- АП (-%- + 0,5)) (1 - А 4М1 + А

позволяет достичь заданных требований по точности и запасу устой-
чивости: при 7’о=О,О5 с, сс=О,11, у=5,73 ни амплитудная Апд, ни фа-
зовая характеристика фпд не заходят в соответствующие запретные
области, определяемые для логарифмической амплитудной характери-
стики формулой (19), а для логарифмической фазовой характеристи-
ки — показателем колебательности М=1,5 [2, с. 43].

Заметим, что использование регулятора пропорционального типа
не позволяет одновременно выполнить оба условия (см. рис. 5) — при
сс=О,О75, Т’о=О,О5 (7=0) обеспечивается заданный запас устойчиво-
сти, однако требуемая точность не достигается (La заходит в запрет-
ную область).

Синтезированные корректирующие звенья [см. выражения (13) и
(22) ] были реализованы в составе программного обеспечения системы
управления робота «Колер» [3].

Качество работы ЦСС было подвергнуто экспериментальной про-
верке. Эксперименты показали, что при гармоническом задающем воз-
действии с Л=500 дискрет и о><0,75 с-1 максимальная ошибка дейст-
вительно меньше 4 дискрет. Однако при <о>0,75 с-1 ошибка етах>4,
максимальная ошибка растет с увеличением частоты и при ш=1 с1
достигает 7 дискрет. Это расхождение с расчетом не является неожи-
данным и объясняется игнорированием нелинейности реального
объекта управления. Получение нелинейной модели объекта управ-
ления и использование ее для расчета цифровой следящей системы
должно быть предметом специального рассмотрения.

ЛИТЕРАТУРА

1.	Федоров С. М., Литвинов А. П. Автоматические системы с цифровыми ма-
шинами. М.: Энергия, 1965. 235 с.

2.	Бесекерский В, А. Динамический синтез систем автоматического регулиро-
вания. М.: Наука, 1970. 130 с.

3.	Федосеев А. Н., Григорьев В. И., Чевтаев С. А., Цуева Л. В. Программное
обеспечение промышленного окрасочного робота «Колер».— Наст. сб.

УДК 007.52:62—52:001.2

ИЕРАРХИЧЕСКАЯ ОРГАНИЗАЦИЯ

АЛГОРИТМОВ ПЕРЕРАБОТКИ ИНФОРМАЦИИ
ПРИ УПРАВЛЕНИИ СВАРОЧНЫМИ РОБОТАМИ

В. Т. Тертышный

При анализе задач и синтезе алгоритмов управления промышленны-
ми роботами общепринятым является иерархический подход [1, 2],
последовательное применение которого обеспечивает четкую струк-
турную организацию технических и программных средств системы
управления. Очевидно, что в рамцах этого общего подхода необходи-
ма конкретизация функций отдельных уровней иерархии, соответст-
вующая области применения робота.

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

Все многообразие функций системы управления сварочными робо-
тами логично разделить на две группы:

планирование технологического процесса;

выполнение технологического процесса.

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

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

Исходная информация для алгоритмов уровней планирования мо-
жет поступать как от оператора (технолога-программиста), так и от
автоматических систем более высокого уровня—АСУ ТП, САПР и
т. д. Результатом работы алгоритмов этого уровня является готовая к
исполнению программа технологического процесса.

Алгоритмы, реализующие ее исполнение, образуют последующие
уровни иерархии.

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

Сформированные на уровне координации инструкции управления
являются исходной информацией для алгоритмов уровня элементар-
ных операций.

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

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

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

Описанная иерархия задач управления сварочным роботом может ,
быть наглядно представлена в виде структурной схемы (рис. 1). Для
того чтобы такая схема могла служить исходным материалом для син-
теза системы управления комплексом, в схеме необходимо отразить
способы подключения системы сбора информации о состоянии комп-
лекса (внутренние сенсоры) и его операционной среды (внешние сен-
соры) и способы восприятия команд оператора. Совершенно очевидно,
что обратной связью через датчики положения звеньев манипулятора
следует охватить уровень сервоуправления. Команды оператора долж-
ны восприниматься на входе уровня планирования (операторы языка
программы обработки изделия) и на входе уровня элементарных опе-
раций (команды ручного управления комплексом, которые могут по-
требоваться, в частности, при формировании программы технологиче-
ского процесса методом обучения). Кроме того, необходим обратный
информационный поток (внутренняя обратная связь в системе), по-
зволяющий задачам верхних уровней при необходимости в любой мо-
мент получить информацию о текущем состоянии элементов комплек-
са (в частности, текущем положении рабочего органа). Для этого в
состав уровня элементарных операций должны быть включены алго-
ритмы решения «прямой» задачи кинематики. В результате получаем
представленную на рис. 2 схему обработки информации. Конкретные
варианты реализации любой системы неадаптивного управления робо-
том могут рассматриваться как частные случаи этой схемы, получен-
ные исключением каких-либо блоков (или исключением отдельных
алгоритмов из состава этих блоков).

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

Рис. 2. Информационные связи между алгоритмическими уровнями в адаптивной си-
стеме управления

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

Включение же в состав алгоритмической структуры дополнитель-
ных уровней влечет за собой сокращение объема памяти, занимае-
мой программой технологического процесса, повышение производи-
тельности робота в процессе программирования, «транспортабель-
ность» программы технологического процесса, т. е. возможность вос-
производить одну и ту же программу в комплексах, использующих
манипуляторы с различными кинематическими схемами. Более рого,
оказывается, что выигрыш в памяти, получаемый за счет сокращения
объема программы технологического процесса, компенсирует затраты
(аппаратурные в виде дополнительной памяти для храпения про-
грамм) на размещение дополнительных программ.

Теперь перейдем к адаптивным системам управления.

Применительно к сварочным роботам принято рассматривать два
вида адаптации: установочную и текущую.

Алгоритм установочной адаптации включается в состав уровня ко-
ординации. Этот алгоритм обрабатывает информацию от внешних
сенсоров положения изделия в рабочей зоне и формирует оператор
коррекции, который в процессе отработки очередного фрагмента про-
граммы технологического процесса остается неизменным. Таким обра-
зом, процесс обработки сенсорной информации и собственно адаптация
(коррекция программы в соответствии с состоянием внешней среды)
разделены во времени.

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

Имеющиеся па сегодняшний день языки, которые могут быть ис-
пользованы в сварочном роботе, относятся к классу языков Ассемблера
и предусматривают довольно детальное (практически на уровне типо-
вых элементов траектории) описание поведения робота. В таком слу-
чае текущая адаптация может быть реализована путем формирования
и обработки дополнительных (не присутствующих в программе техно-
логического процесса) операторов. Действительно, предположим, что
в программе технологического процесса задан оператор формирования
прямолинейного отрезка сварного шва, а реальная траектория стыка
непрямолинейна. В таком случае необходима аппроксимация реальной
траектории стыка отрезками из имеющегося набора (если геометриче-
скими элементами траектории являются не только прямые) и переда-
ча соответствующих операторов на обработку алгоритмами уровня ко-
ординации. Это означает, что в рассмотренной нами иерархии необхо-
димо ввести дополнительный уровень самопрограммирования, который
выполняет функции «автоматического программиста», моделируя ра-
боту оператора в процессе составления программы технологического
процесса. Исходной информацией для этого уровня должна служить,
с одной стороны, сенсорная информация, с другой — информация о
текущем состоянии манипулятора (выше мы уже обсуждали способ
ее получения).

Алгоритмы уровня самообучения могут быть органически вклю-
чены в состав уровня координации в том случае, если программа тех-
нологического процесса задается на уровне законченных технологиче-
ских операций (например, «заварить стык от точки Ai до точки /12,
движение осуществлять в направлении вектора В1»). При этом
функции алгоритмов уровня координации будут следующими:

по данным от сенсоров найти начало стыка в окрестности точки 41;

по данным от сенсоров найти реальное направление стыка в ок-
рестности вектора В1;

периодически обрабатывая информацию от сенсоров, формировать
команды построения элементарных отрезков траектории, обеспечивая
аппроксимацию траектории стыка с требуемой точностью;

по данным от сенсоров найти конец стыка в окрестности точки 42
и сформировать соответствующую последовательность команд.

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

Не претендуя на всеобъемлющую полноту анализа, пспытаемся
рассмотреть эту задачу в первом приближении. Введем следующие
обозначения:

ЬТ — период выдачи сигналов управления исполнительными ме-
ханизмами;

— время решения задачи динамической коррекции траектории
алгоритмами уровня сервоуправления;

t2 — время решения задачи интерполяции алгоритмами уровня
элементарных операций;

t2" ~ время решения обратной задачи кинематики алгоритмами
уровня элементарных операций;

Тъ — время отработки комплексом минимального ио длине эле-
мента траектории (прямолинейного или дугообразного);

t/ — время «распаковки» одного оператора языка задания прог-
раммы технологического процесса алгоритмами уровня координации;

ts" — время решения задачи коррекции координат алгоритмами
уровня координации;

te — время предварительной обработки сенсорной информации
системой сбора информации о состоянии внешней (операционной)
среды;

t3"' — время решения задачи адаптации на основе предваритель-
но обработанной сенсорной информации алгоритмами уровня коор-
динации;

Та — период адаптивного управления.

Вкратце поясним смысл введенных параметров.

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

Время Тэ характеризует требуемую производительность системы
управления и определяется длиной минимального программируемого
отрезка на уровне инструкций управления (исходная информация
алгоритмов уровня элементарных операций) с заданной максималь-
ной технологической скоростью перемещения сварочного инстру-
мента vT.	л

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

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

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

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

6T>tt.

При этом отметим, что

67’=П.

В системе имеется только один массив, хранящий программу тех-
нологического процесса. Объем массива М пропорционален суммар-
ной длине стыков обрабатываемого изделия. Поскольку обычно
8T>ti, на основе такой системы легко построить систему группового
управления, для которой должно соблюдаться следующее соотноше-
ние между временными параметрами:

Здесь к — количество одновременно управляемых манипуляторов;
ta - дополнительные затраты машинного времени, связанные с орга-
низацией мультипрограммного режима.

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

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

67’>Л+/2'+^",	(1)

7’в>£/+7’а {t&ti +t2" )/б7’+^м.	(2)

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

f Первое из указанных соотношений должно соблюдаться при лю-
бом варианте структуры технических средств. Второе соотношение
обязательно лишь в случае однопроцессорной структуры системы.
Для двухпроцессорной системы, в которой один процессор реализует
алгоритмы двух нижних уровней иерархии (при этом в состав внеш-
них устройств включаются при необходимости и модули управления
приводом с соответствующей коррекцией значения ^), а второй про-
цессор реализует алгоритмы более верхних уровней, соотношение (2)
необходимо скорректировать:

7'а>^'+7’э?г/б7’'ц+ги.

Здесь ц — пропускная способность канала передачи информации
между процессорами; п — максимальный объем (максимальная дли-
на) инструкции управления.

Очевидно, что аналогично предыдущему варианту неадаптивиой
системы можно реализовать групповое управление, добавив соответ-
ствующее количество процессоров, отрабатывающих алгоритмы
нижних уровней иерархии:

7’э>А:(^,+7’эге/б7’т])+^м.

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

для однопроцессорной системы

Тя>1з'~Нз"+Тэ (^l + ^2,+ ^2,/)/67’+iM;

для двухпроцессорной системы

?’э>С'+<з"+7’эм/67’т]+к;

для системы группового управления

Тя>к (С'-Н3"+Тэп/6Т1]) +tM.

Естественно, что соотношение (1) сохраняется и в этом варианте.

Вариант 4. Система управления с текущей адаптацией. Для та-
кой системы важнейшим ограничением является необходимость
обеспечить заданную периодичность замыкания обратной связи через
средства сбора сенсорной информации. Здесь также возможен ряд
конфигураций структуры технических средств.	л

Для однопроцессорной системы, в которой единственный профес-
сор обрабатывает все алгоритмы управления, а также выполняет
предварительную обработку сенсорной информации, соотношения
между временными параметрами имеют следующий вид:

TB>tc^t3"'+t3'+TB (t,+h'+t2") /6T+ta.

Для системы с дополнительным сенсорным прсдпроцессором по-
лучим

Га>£с,

TB>t3"'+t3'+Ta(,tl+t2'+t2")/8T+tK.

И, наконец, для системы, в которой алгоритмы управления реа-
лизуются двумя процессорами и, кроме того, имеется сенсорный
180
препроцессор, ограничительные соотношения представляются в
следующем виде:

Ta>te,

T.>t3"'+ts'+T.nl8Ti\+ta,

8T>tl+t2'+t2.".

* * *

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

Во всех рассмотренных вариантах алгоритмических структур
анализируются как минимум две структуры технических средств:
однопроцессорная и мультипроцессорная (двух- или трех-). Таким
образом, четко видны две стратегии развития систем:

наращивание функциональных возможностей системы путем
постепенного включения в состав программного обеспечения един-
ственного процессора всех новых программных модулей;

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

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

Второе же направление представляет наиболее экономичную
стратегию развития возможностей системы управления, позволяя
получать на каждом этапе оптимальное соотношение между возмож-
ностями системы и включенными в ее состав аппаратными средства-
ми. Такой путь есть последовательное применение принципа
модульности по отношению к рассматриваемому виду систем управ-
ления, а реальной технической предпосылкой к осуществлению яв-
ляется появление микропроцессоров невысокой стоимости и доста-
точной производительности. Способы оптимального распределения
функций между процессорами должны опираться на рассмотренную
иерархическую структуру алгоритмов обработки информации в
процессе управления комплексом.
ЛИТЕРАТУРА

1.	Попов Е. П., Верещагин А. Ф., Зенкевич С. Л. Манипуляционные роботы:
динамика и алгоритмы. М.: Наука, 1978. 400 с.

2.	Управление роботами от ЭВМ/Под ред. Е. И. Юревича. Л,: Энергия, 1980.
264 с.

УДК 007.52'

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

СИСТЕМЫ ТЕХНИЧЕСКОГО ЗРЕНИЯ

ПРОМЫШЛЕННОГО РОБОТА

К. Н. Ступин

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

Рассматриваемая в данной работе система технического зрения
создана на базе микро-ЭВМ «Электроника-60», серийной телевизион-
ной камеры «Взор» и пневматического манипулятора МП-8. Область
применения системы технического зрения — сборочные операции, в
процессе выполнения которых необходимо осуществлять захватыва-
ние произвольно расположенных в рабочем поле объектов, а также
их идентификацию в рамках заранее определенного набора. Система
технического зрения может также применяться как система контроля
качества, автоматической сортировки и укладки. При создании систе-
мы технического зрения были сделаны следующие допущения:

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

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

телевизионная камера удалена от плоскости рабочей зоны на-
столько, а объекты, с которыми работает система технического зре-
ния, таковы, что при их смещении в пределах рабочей зоны двумер-
ные образы объектов меняются несущественно с точки зрения ре-
шаемых задач;

объекты хорошо контрастируют с фоном, не перекрываются и не
касаются один другого.

Система технического зрения работает в реальном масштабе вре-
мени, т. е. обработка видеоинформации не вносит задержки в дей-
ствие манипулятора. Общая схема работы системы технического зре-
ния при выполнении, например, автоматической сборки такова.

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

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

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

Идентификация объекта осуществляется по принципу «ближай-
шего соседа» с использованием сформированного на этапе обучения
каталога эталонов. Если объект идентифицирован, то для него ста-
новится доступной информация о тех операциях, которые над ним
надо проделать. В то же время система технического зрения распо-
лагает информацией, достаточной для захватывания объекта мани-
пулятором, причем такие данные система получает до идентификации
объекта.

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

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

Рассмотрим более подробно этапы обработки видеоинформации
в системе технического зрения.

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

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

Предварительная обработка и ввод информации в систему техни-
ческого зрения осуществляются специализированным устройством —
препроцессором. В целях повышения достоверности выходной ин-
формации в препроцессоре реализована следующая мажоритарная
процедура обработки видеоинформации. Препроцессор принимает от
телевизионной камеры три последовательные строки изображения,
проводит дискретизацию аналогового сигнала с двумя уровнями по
яркости (черный — белый) и числом элементов в строке, равным 192.
Информация по каждой из трех вводимых строк помещается в свой
буфер, содержащий 192 двоичных разряда. Далее, по принципу «два
из трех» формируется результирующий буфер. Препроцессор анали-
зирует содержимое этого буфера и определяет положение переходов
от белого к черному и наоборот. Полученные таким образом коорди-
наты контурных точек помещаются в буфер вывода, откуда посту-
пают в ЭВМ.

Описанная процедура обработки выполняется за время обратного
хода развертки после «третьей» строки, прямого и обратного ходов
«четвертой» строки, которая в данном кадре пропускается. Обмен с
ЭВМ начинается с момента заполнения буфера вывода. Чтобы пе
терять каждую четвертую строку в кадре, вводятся подряд четыре
кадра со сдвигом на одну строку. После перегруппировки в памяти
ЭВМ формируется массив координат контурных точек, определимых
с помощью горизонтальной развертки. Этот массив упорядочен по
возрастанию координаты X (номер строки). Вся дальнейшая обра-
ботка видеоинформации осуществляется в ЭВМ.

Вычисление координат центра площади двумерного изображения.
Координаты центра площади двумерного изображения объекта
являются характеристиками положения объекта в рабочем поле и,
кроме того, фигурируют в качестве параметров при вычислении всех
признаков формы, используемых при идентификации.

В случае непрерывного контура положение центра площади от-
носительно контура не зависит от ориентации объекта. Дискретиза-
ция контура делает положение центра площади чувствительным к
изменению ориентации. Это особенно сильно проявляется, если в
качестве центра берется не центр площади, а центр тяжести системы
контурных точек. В этом случае при изменении ориентации объекта
происходит «перетекание» контурных точек, что ведет к существен-
ному изменению положения центра.

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

n Li

Хс= X I (f/i,2j —Уг.2гЭ/Ч

,=1 ;=1
N Li

Ус = X X

i=l j=l
N Li

i=l 3=1

где yi.i — декартова координата J-й контурной точки в г-й строке для
системы, связанной с телевизионной камерой; Lt — количество кон-
турных точек в г'-й строке изображения, деленное на два; N — коли-
чество строк в кадре.

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

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

координата, огвечающая положению точки в строке (У);

признак, показывающий, к которой из двух строк (текущей или
предыдущей) принадлежит данная точка;

признак, показывающий, какой является точка в строке (четной
или нечетной).
Проводится сортировка слиянием этих массивов по возрастанию
координаты Y. Далее, в процессе просмотра массива слияния опре-
деляются координаты дополнительных контурных точек. Эти точки
появляются, если расстояние между нечетным и четным элементом
массива слияния (разность координат У) оказывается больше или
равно двум. Вторая координата (X) определяется с учетом признака
четности. Одновременно с восстановлением полного контура прово-
дится вычисление периметра. При этом используется признак прина-
длежности к текущей (предыдущей) строке.

Таким образом, после завершения восстановления контура ока-
зываются вычисленными два из восьми используемых признаков фор-
мы — площадь и периметр. Остальные признаки вычисляются в ре-
зультате обработки массива координат контурных точек полного кон-
тура. К этим признакам относятся:

SR — среднее арифметическое расстояний от контурных точек до
центра площади;

S^i — разброс расстояния до центра относительно SR;

Птах, Rmm — соответственно максимальное и минимальное рассто-
яние до центра;

/шах, /min — соответственно максимальный и минимальный момент
инерции относительно главных центральных осей инерции контура,
рассматриваемого как совокупность материальных точек единичной
массы.

Выбор именно таких признаков формы продиктован тем, что они
мало зависят от ориентации объекта и могут быть достаточно быстро
вычислены по следующим формулам:

Sr = J Ri/m, SЛ„ = § (Ri - SR)z/m,
1=1 1=1

Rrnax == max {У?,}, Rmin = min {RJ,

/max= (SX,X~2KSX Y + K2SY,Y) I (R2+l) ,

/ШН1= (№5х,х+27Г5х,У+5у.т)/(/<2+1),

где	. v ' '

Rl = ((Xi-Xc)2+-(Kl-rc)2)'\

m	m

Sx, x = 5 (Xf - Xc)2; Sy,y = 3 (Yi-Yc)\
i=l	i=l

m

5 (Х,-ХС)(У;-УС);

1=1

К = (Sx,x — Sy,y — ((Sx,x — Sy'Y)3 + 4tSx, у)’/г)/25лг,у;

т — количество точек в полном контуре.

Кроме признаков формы, вычисляется положение главной цен-
тральной оси инерции, момент относительно которой минимален.
Это положение определяется углом наклона оси инерции к оси X:

ALFA=arctg(—К).
Вместе с координатами центра площади это дает системе техни-
ческого зрения информацию, достаточную для захватывания объекта
манипулятором.

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

На этапе идентификации объекта, находящегося в рабочем поле
системы технического зрения, вычислеппып вектор признаков срав-
нивается со всеми «эталонами» из каталога рабочих объектов. Объ-
ект идентифицируется с тем «эталоном», расстояние до которого в
пространстве признаков минимально.

Программное обеспечение системы технического зрения построе-
но по модульному принципу и требует порядка 20К байт памяти
ЭВМ. Время обработки видеоинформации от одиночного объекта со-
ставляет приблизительно 2 с.

УДК 658.(112.011.56:681.3.06

О ГИБКОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

В СИСТЕМАХ УПРАВЛЕНИЯ

ПРОИЗВОДСТВЕННЫМИ ОБЪЕКТАМИ

В. М. Гуревич, А. К. Григорян, В. Е. Вовнобой

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

Рассмотрим подход к построению гибкого программного обеспе-
чения.

Гибкость управления (подход «сверху»). Под гибкостью (У)
будем понимать свойство системы (S') наилучшим образом (К) обе-
спечивать требуемые характеристики управления Y = {у\, у2, . • .
. . . , у я} при их возможных отклонениях D = {di, d2, . . ., d^}.
Пусть величина (dC) характеризует гибкость системы по управле-
нию yi. Тогда общую гибкость системы характеризует функция
F (S) = (dt) при i = (1, N), где щ — вес отклонения di.

Пусть К — это некоторые ограничения, при которых имеет смысл
требуемая гибкость F. К ограничениям могут относиться такие по-
нятия, как критерии точности управления или устойчивости систе-
мы, критерии минимизации или ограничения ресурсов, критерии
удобства эксплуатации и т. д. Если задано Y = Н (X), то задача
построения гибкой системы управления сводится к нахождению та-
кого функционала G (Y, D), что удовлетворяются критерии К и
F (5) = max.

Отклонения D могут касаться различных параметров управле-
ния. Выделим следующие случаи: параметризация входов (D = gi (X),
где X - - входы системы); параметризация выходов (D =
= g2 (У), где Y — выходы системы); параметризация функции,
когда D g3 (Я). От способа формализуемости и представления
D зависит сложность G. В большинстве практических случаев D
задается как векторный параметр с независимыми или слабозави-
симыми компонентами типа списков, таблиц и т. д. Предельно слож-
ный случай, когда D задан неявно и сильно взаимосвязан с Н. Тог-
да удобно для задания G (Н (X), D) использовать некоторую аде-
кватную модель.

Выбором модели определяются языковые средства для описания
G, а их реализация сводится к интерпретации G (Н (X), D). Функ-
ция G и параметры отклонения D обеспечивают способность системы
к адаптации. Определение методов реализации G ( Н (X), D) в про-
граммном обеспечении системы определяется ее архитектурой. Мно-
гоуровневая модульная организация позволяет декомпозировать!) по
слоям и модулям и упростить выбор G в каждом отдельном случае.

Гибкость прогр.мч (подход «снизу»). Определим адаптируемость
программы как свойство быть примененной для решения других
мало отличающихся задач (алгоритмов). Элементарными изменениями
в некотором языке назовем действия по изменению одной языковой
единицы текста [1]. Очень часто класс близких алгоритмов формули-
руется именно в этих терминах. Конкретные элементарные изме-
нения и их полнота зависят от языка. В статье [1] приведен пример
множества элементарных изменений для языка булевых формул
и показана их программная интерпретация.

Будем говорить, что алгоритмы Alt А2, описанные на языке ЭД,
отличаются друг от друга в к точках или отклоняются на к, если
к элементарных изменений переводят их друг в друга. К элементар-
ным изменениях относятся замена, удаление или вставка перемен-
ной, константы, метки, операции и т. д. Обозначим к = d (Ai(OLa),
а величину

rA = d (4i, 42)/maxL (А) при i — 1, 2

назовем мерой близости Ai и А2. Здесь L (4J — длина текста (ко-
личество языковых элементов).

Пусть е ЕЕ Е есть способ отображения А, в программу Р (Лг)
на языке ф. В частном случае ЭД и ф могут совпадать.

Определим меру близости двух программ как

гр = d (Р (4г), Р (A2))l max L (Р (4г)) при г = 1,2.

Будем говорить, что е сохраняет близость, если с-окрестность
любого алгоритма Ai отображается в бс-окрестность реализующей
ее программы Р (Ai), где b = const, т. е. справедливо утверждение

А} г (Ai, Aj^c^r (Р (Л), Р (4;))<&с.

Пример отображения е, не сохраняющего близость, т. е. сопостав-
ляющего «близким» алгоритмам «далекие» программы, рассмотрен
в статье [1].

Определим на {А} две операции параметризации: по данным и
по управлению. Параметризация по данным подобна алгебраиче-
скому действию «вынесение за скобки» некоторых констант и пере-
менных и заключается в их систематической замене параметрами.
Она позволяет свести далекие алгоритмы к близким. Параметри-
зация по управлению определяется следующим образом: в точках
несоответствия двух алгоритмов Ai и А3 вводится механизм распо-
знавания параметра, по которому выбирается соответствующий ал-
горитм.

Общие части Ai и А2 объединяются, так как близость текстуаль-
ная. Будем считать адаптацией алгоритма А3 его свойство альтерна-
тивного выбора вариантов и свяжем с ней некоторый механизм ра-
спознавания и выбора соответствующей альтернативы из {Ai, Л2}>
т. е. назовем А3 адаптирующимся к Ai и А2.

Рассмотрим следующие случаи:

Ai совпадает с А2 с точностью до констант или переменных (тог-
да механизм выбора определен только вначале для подстановки
значений параметров, остальная часть алгоритмов совпадает);

Аг и А2Лразличаются в п точках (механизм выбора определен во
всех п точках);

Ai и А2 различаются везде (тогда механизм выбора определен
вначале и А3 есть объединение двух алгоритмов).

В каждом из этих случаев основным критерием выбора структу-
ры А3 является выполнение неравенства

L (А3) < L (Ai) 4- L (А2).

Из определения и метода построения следует, что если га (Aj,
А2) = с, то

rA (Ai, А3) = гА (А3, А3) = с + const.

Если е — отображение, сохраняющее близость, то для соответ-
ствующих им программ справедливы выражения

гР (Р (А3), Р (Ai)) = гР (Р (Из), Р (А3)) = Ьс}1

' Ь(Р(А3))^Ь(Р(А1)+Р(А3)).

Если га (Ai, А2) = 1, т. е. алгоритмы отличаются почти во всех
точках, то механизм выбора в А3 целесообразно вводить только вна-
чале. В этом случае

L (А3) = L (Ai) 4- L (А3).

Определим гибкость алгоритма А3 как

/ (4з) = / (d (Al, А3)) =
где п — число точек параметризации; di (Ai, А2) — отклонение ал-
горитмов в этих точках. Тогда / (А3)	1 при п = di (Ai, Л2) =

= L (Лх), a min / (Л3) = 0, когда Ai и А2 совпадают. Это соответ-
ствует интуитивному понятию «гибкости». Приведенные понятия
можно распространить на случай т алгоритмов Ai, А2, . . ., Ат.
Итак, для обеспечения адаптируемости алгоритма А необходимо:

определить близкую окрестность А, в которой он будет адапти-
роваться, и выбрать отображение е: А —> Р (Л), сохраняющее бли-
зость;

в точках возможных отклонений от А программа Р (Л) должна
быть параметризована по данным и по управлению с введением ме-
ханизма выбора.

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

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

Существующая теория и практика создания сложных програм-
мных систем основаны на принципе многоуровневой архитектуры
£2]. Каждый уровень состоит из одного или нескольких абстрактных
машин-процессоров (рг) и объединяющего их управления. Любой
процессор есть реализация некоторой абстрактной машины, которая
выполняет отдельный алгоритм, состоящий из процедур для выше-
стоящих уровней. Важно отметить, что процессоры, выполняющие
алгоритмы, не связаны с понятием аппаратуры или программного
обеспечения. Пара (рп, р^ определяет новый процессор ргг+1,
для которого Pi является программой, a prt — интерпретатором. При
таком подходе процессор рг является основным структурным эле-
ментом этой архитектуры, обладающим механизмом наст^цйки
(адаптации) посредством программы р. Гибкость процессора1 рг
зависит от количества и длины интерпретируемых им программ и
способа их фиксации. Пара процессор — программа определяет по-
тенциальную гибкость процессора, а размещение программы р
(фиксация) в динамически изменяемой среде позволяет максимально
реализовать эту гибкость.

Каждому уровню архитектуры соответствует своя область поня-
тий, свое множество процессоров и присущая этому уровню гибкость.
Назовем эту гибкость горизонтальной (внутриуровневой). Чем
ниже уровень, тем ближе он к аппаратуре и шире его возможности
адаптации. С поднятием наверх уровни специализируются и проис-
ходит «утрата гибкости». Этому способствует также принцип «уп-
рятывания» информации внутри модуля или уровня, когда для свя-
зи с вышестоящим уровнем доступно лишь «узкое» окно [2].

Гибкость, обусловленную переходами с уровня на уровень, назо-
вем вертикальной (межуровневой) гибкостью.

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

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

Архитектура программного обеспечения для устройств числово-
го программного управления — пример гибкой организации. Тре-
буется создать гамму устройств числового программного управле-
ния с расширенной областью применения на максимально унифици-
рованном аппаратно-программном обеспечении. Каждое устройство
этого семейства должно обеспечивать способы модификации Для рас-
ширения или переконфигурации своих функциональных возможно-
стей. Каждая неделимая аппаратная единица образует процессор
нижнего, нулевого уровня. Первый уровень составляет операцион-
ная система "устройств числового программного управления [3], яв-
ляющаяся процессором, интерпретирующим логический уровень
связи с аппаратурой. Процессоры, распределяющие аппаратные
ресурсы и специализирующие устройства для обслуживания уст-
ройств числового’программного управления, представляют уровни
второй и третий. Технологический процессор является четвертым
уровнем и состоит из технологических программ и программ управ-
ления электроавтоматикой станков, роботов и другого вспомогатель-
ного оборудования. Для адаптации этого уровня и всего устройства
числового программного управления к технологии обработки, стан-
кам, роботам и другому вспомогательному оборудованию пользова-
телям предоставляются проблемно-ориентированные языки «Ярус-2»
[4] (для электроавтоматики) и «Технолог» (для технологии). Посред-
ством программирования на них пользователь может создавать тех-
нологические процессоры для своих объектов управления.

Пятый уровень образуют процессоры технологически ориентиро-
ванных диалогов (язык «Диалог» [5]) для автоматизации проекти-
рования технологических программ.

ЛИТЕРАТУРА

1.	Григорян А. К., Золотаревская М. Я. Модификация логических алгорит-
мов и программ,— Автоматика и телемеханика, 1982, № 7, с. 198—212.

2.	Мобильность программного обеспечения / Под ред. П. Брауна. М.: Мир,
1980. 257 с.
3.	Вовнобой В. Е., Гуревич В. М., Григорян А. К. Операционная система ЧПУ
на базе «Электроника НЦ80-31».— Станки и инструмент, 1983, № 12, с. 11—12.

4.	ВоклерИ.Э., Григорян А. ККузнецов О. ПМарковский А. В., Ши-
пилина Л. Б. Проблемы разработки языков логического программирования
и их реализация на микро-ЭВМ на примере языка Ярус-2.— Автоматика и
телемеханика, 1985, № 6, с. 149—159.

5.	Бронштейн Г. В., Городецкий М. С., Гуревич В. М. Программирование
обработки на токарпых станках с ЧПУ в режиме диалога.— Станки и инстру
мент, 1984, № 4, с. 11—13.

УДК 007.52-621.86

РЕГУЛЯРНЫЙ АЛГОРИТМ

ПРОКЛАДКИ МАРШРУТА МОБИЛЬНОГО РОБОТА
С ИСПОЛЬЗОВАНИЕМ ТОЛЬКО
ЛОКАЛЬНОЙ ИНФОРМАЦИИ

А. А. Петров, И. М. Сирота

Большинство известных методов планирования движений роботов
в'среде со стационарными’препятствиями основано на предполо-
жении, что либо среда априорно известна и представлена неко-
торой моделью, либо препятствия можно распознать в достаточно
большой! окрестности робота с помощью систем технического
зрения, дальномеров или других дистанционных датчиков. Однако
не менее важен иной класс задач, когда робот способен перемещать-
ся’только «вслепую», узнавая о возможности прохождения того или
иного участка лишь в малой его окрестности. Например, мобиль-
ный робот обнаруживает участок со слишком слабым грунтом,
только непосредственно приблизившись к нему; манипуляционный
робот часто может получить лишь локальную информацию о при-
ближении своих звеньев к препятствию от тактильных датчиков.
Имеется очень мало публикаций, где рассматриваются для подоб-
ных случаев неэвристические (регулярные) методы обхода препят-
ствий, т. е. такие, которые гарантировали бы нахождение пути
в заданную цель, если он объективно существует, а в противном
случае — установление факта принципиальной недостижимости
цели. Регулярные алгоритмы формирования движений роботов
в совершенно неизвестной среде Уна основании только локальной
информации 5 были «"предложены и развивались в работах [1—3].
Позднее простейший из этих алгоритмов был повторен в статье'[4].
Несколько иные подходы к решению этой задачи представлены
в публикациях [5,6].

Рассмотрим новый регулярный метод обхода препятствий робо-
том «вслепую», который использует получаемую в процессе дви-
жения локальную информацию не только для гарантированного на-
хождения пути в цель (или установления факта ее недостижимости),
но и’для построения модели среды с целью последующего формирова-
ния более рациональных траекторий, чем впервые прокладываемый
маршрут. Для построения движений робота воспользуемся извест-
ным подходом (см. публикации [1—4, 7—101), основанным на про-
кладке траектории изображающей точки, являющейся отображением
робота в конфигурационном пространстве, которое, например, может
быть пространством обобщенных координат манипуляционного робо-
та или же пространством параметров, характеризующих положение
и ориентацию мобильного робота. В конфигурационном простр нстве
имеются запретные зоны, соответствующие недопустимым конфигура-
циям робота.

Следует подчеркнуть, что для поставленной задачи движения ро-
бота «вслепую» в неизвестной среде геометрическую модель конфигу-
рационного пространства нельзя получить априорно еще до начала
движения (в отличие, скажем, от задач, решаемых в статьях) [8—
101). Построение в процессе движения робота модели конфигурацион-
ного пространства будем осуществлять на основе неявно задаваемого
графа. Рассмотрим случай двумерного конфигурационного простран-
ства, хорошо иллюстрирующий многие практически важные задачи
планирования маршрута мобильного робота. Предложенный метод
позволяет прокладывать траекторию изображающей точки в области,
содержащей заранее неизвестные запретные зоны произвольной
формы, требуя в каждый текущий момент только сигнала о том,
находится ли изображающая точка в свободном пространстве или
на границе запретной зоны.

МОДЕЛЬ КОНФИГУРАЦИОННОГО ПРОСТРАНСТВА

Введем обозначения: 0 — конфигурационное пространство; SyCZ
________________	п

СТ 0, где/ — 1, п,— односвязные запретные зоны; S — 0 \ (J Sy—

Г~1
часть конфигурационного пространства, не занятая запретными
вонами; оу GZ S — граница запретной зоны S у; S \ [J о,- — свобод-
7=1

ное пространство. Будем предполагать, что все границы где
7 — 1, п, имеют конечную длину и что минимальное расстояние
между любыми двумя запретными зонами больше некоторой положи-
тельной величины А. Пусть известны начальное положение изобра-
жающей точки 0Н ЕЕ S и целевое положение 9аЕ 0.

Так как область S связна, цель 0“ S достижима для изоб-
ражающей точки. В противном случае, когда 0Ц €= Sy, где 1 jп,
цель недостижима.

с Модель конфигурационного пространства в явном виде можно
было бы описать следующим образом. Проведем из точки 0Ц все воз-
можные касательные к выпуклым участкам границ запретных зон
Оу (рис. 1, а). Точки касания обозначим через О.{, где к = 2, К
(Ог = 0н), а ближайшую к Ок точку пересечения линии <40ц с какой-
либо границей Оу, где 1	/'С п, (если такая точка существует) —
Рис. 1. Построение модели конфигурационного пространства
а — вид конфигурационного аространства} б — граф G

через С\. Ясно, что О\С^ CZ S. Поставим в соответствие точкам 0Ц,
0^ и Сic, где к = 1, К, вершины графа G, а все возможные направ-
ленные отрезки OitCic (если точки Сц не существует, то берется отре-
зок О»0Ц) и участки границ, соединяющие каждую точку CL о;
с каждой точки 6С Оц будут соответствовать дугам этого графа G
(рис. 1, б). Вообще говоря, дугам можно приписать определенную
стоимость.

Теорема. Цель 0й достижима для изображающей точки тогда
и только тогда, когда на графе G существует путь из точки О± =
= 0В в точку 0Ц. Этот путь определяет траекторию изображающей
точки.

По построению графа G всякому пути из точки Ог в точку 0Ц на
этом графе соответствует траектория L CZ S, соединяющая 0" с 0“
и состоящая из отрезков касательных 0*0* С 8 и участков границ
CitOv CZ о, CZ 8, где 1 < v К. Если цель достижима для изоб-
ражающей точки, то существует некоторая траектория Li CZ 8,
соединяющая точки U" и 0Ц. Посредством непрерывной деформации
в 8 траектория Li всегда может быть преобразована в кривую, имею-
щую форму траектории L. Следовательно, на графе G существует
путь из точки О, в точку 0Ц.

Если же цель недостижима, то 0Ц е= S,-, и на графе G нет<дуг
С\0”. Так как 0й — изолированная вершина, то пути из О} в 0" не
существует. Теорема доказана.

В процессе движения робота взвешенный ориентированный граф
G, задающий модель конфигурационного пространства, строится
в неявном виде с помощью операторов порождения вершин, соответ-
ствующих перемещениям изображающей точки. Обозначим через
Г = {Г1; Г2, . . Гп} набор операторов, позволяющий, начиная
с вершины О± — 0Н, строить все последующие вершины графа G.
Конкретное содержание каждого оператора зависит от используемого
метода поиска пути. Однако в любом случае набор Г содержит опера-
тор Гъ который применяется к вершине Ot, и порождает вершину Ск
(или сразу 0й), определяя дугу ОкСк (или <4011). Оператор Г] соот-
ветствует перемещению изображающей точки из Ок по линии 6\.0‘'
до попадания на какую-либо границу пу, где 1	< п, или же до

достижения цели.

Остальные операторы Г2, . 0 ., Гт ив набора Г применяются к вер-
шинам, соответствующим точкам Ск ёЕ о,, где	и 1

и, и порождают вершины Ov, где 1 < v К (точки Ov о;),
определяя дуги, исходящие ив Ск. Каждый из этих операторов
соответствует перемещению изображающей точки вдоль границы
до достижения очередной (например, в порядке удаленности от
Ск вдоль границы) точки касания Ov €= ог Для обнаружения точек
касания в процессе движения изображающей точки по границе
можно контролировать угол а между направлением движения в
текущей точке гЕ о, и направлением отрезка я0ц (см, рис 1, а):
в точках касания sin а = 0.

АЛГОРИТМ ПОСТРОЕНИЯ ПУТИ

Используя предложенную модель, можно строить различные алго-
ритмы поиска пути роботом «вслепую» с учетом конкретных особен-
ностей решаемых задач. При синтезе алгоритма следует иметь в
виду, что дуги графа G имеют стоимость, определяемую, например,
длиной соответствующих отрезков траектории, энергозатратами
робота на перемещение по ним, либо какими-то другими критериями,
а эффективность решения задачи в общем случае зависит не только
от стоимости окончательно найденного маршрута (простого пути
на графе G), но и от затрат на сам процесс поиска этого маршрута.
В соответствии с этим можно рассмотреть следующие два класса
задач:

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

Б — затраты, допустимые в процессе поиска пути, существенно
ограничены, а стоимость проложенного маршрута не столь важна
(например, он будет использован лишь однократно либо может быть
улучшен впоследствии по мере обучения робота функпионированищ
в данной среде).

Для решения задач класса А при использовании предложенной
модели могут быть применены многие известные алгоритмы поиска
Пути на графах (например, алгоритм Л*), позволяющие по графу G
строить рациональные или даже оптимальные (в классе траекторий,
определяемом способом построения графа) маршруты изображающей
точки.

При решении задач класса Б необходимо иметь в виду, что «еле
пой» робот для получения цовой локальной информации о среде
должен фактически передвигаться в ней согласно перемещениям изоб-
ражающей точки в соответствии с алгоритмом поиска пути на графе
G. Ясно, что в случае физических движений робота сам процесс
нахождения маршрута (в отличие от «мысленного» планирования дви-
жения робота в известной среде) требует ощутимых затрат, которые
можно охарактеризовать стоимостью того пути s, который прошла
изображающая точка в процессе поиска, т. е. суммой стоимостей по-
строенных дуг графа.

В известных публикациях эта особенность практически никак не
учитывается. Здесь предлагается метод, позволяющий принимать
ее во внимание, для чего описанная модель конфигурационного
пространства определенным образом модифицируется: если на участ-
ке границы щ, соответствующем дуге CkOv, имеется точка выхода
прямой О;Г0Ц из запретной зоны 2у, то вводится дополнительная
вершина Оа, где 1 < а К, и рассматривается содержащий ее
граф G' 5 G. Такая модификация позволяет строить такой маршрут
s, который содержит не всю дугу CkOv, а только ее часть СкОа. Кроме
того, что очень важно, это дает возможность сформулировать признак
для установления факта недостижимости цели без полного построе-
ния графа G'.

Предлагаемый алгоритм поиска пути на графе G’ использует
набор операторов Г = {Г1; Гл, Гп}. Операторы Гл и Гп определяют
две дуги, исходящие из Ск при обходе границы соответственно по
часовой стрелке и против нее либо до первой из встретившихся по
пути точек: точки Ov, где а = 0, или точки Оа выхода прямой CkQn из
зоны 2,, либо до возврата изображающей точки в Ск. В последнем
случае на графе G' образуется петля, т. е. дуга начинается и кон-
чается в вершине Ск.

Алгоритм содержит следующие основные этапы.

1.	К вершине Ок применяется оператор Г1? в результате чего
либо осуществляется переход в вершину 0Ц (т. е. достигается цель,
тогда — конец программы), либо строится вершина Ск. Важно, что
вершину Ск не надо сравнивать с построенными ранее вершинами
Сц, где р. = 1, к, так как при принятом представлении конфигура-
ционного пространства в виде графа она никогда не совпадает ни
с одной из них.

2.	К вершине Ск сначала применяется один из пары операторов
(Гл, Гп). При этом либо образуется петля (изображающая точка
возвращается в С*), либо строится вершина Ov. В первом случае
делается вывод, что цель недостижима — конец программы. Во вто-
ром случае, если О-* совпадает с какой-либо из вершин построен-
ных ранее, то — переход к этапу 3, если же — Ok+i есть внбвь
построенная вершина, то — переход к этапу 1 (к: = к + 1).

3.	В установленном для каждого конкретного случая порядке,
не оказывающем влияния на факт сходимости алгоритма, к тем ив
построенных вершин С\, к которым до сих пор был применен только
один оператор (Гл или Гп), применяется оставшийся оператор этой
пары (соответственно Гп или Гл), и этот процесс продолжается
до тех пор, пока либо не будет построена новая вершина Ok+i (тог-
496
да — переход к этапу 1 (к‘.—к + 1)), либо не будет удовлетворено
условие 2 описываемого ниже признака недостижимости цели
(тогда — конец программы).

Признак недостижимости цели. Она недостижима при выполне-
нии хотя бы одного из двух условий: 1) на графе G' образовалась
петля; 2) ко всем вершинам С\-, начиная с некоторого номера М к,
были применены оба оператора Гл и Гп, и каждый раз оказывались
построенными ранее найденные вершины с номерами и > М.

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

Если цель объективно недостижима, то на графе G' не будет дуг
т. е. вершина 0Ц не может быть построена. Покажем, что в этом
случае имеет место признак недостижимости. Предположим против-
ное. Тогда каждый раз этап 3 будет заканчиваться формированием
новой вершины О]!+1. Действительно, если бы ко всем вершинам
от С* до Сх уже были применены оба оператора Гл и Гп, но каждый
раз оказывалось бы, что построенная вершина совпадает с ранее
найденной вершиной 0^, где 1 <; ц &, то был бы обнаружен при-
знак недостижимости (по условию 2), что противоречит предположе-
нию. Ввиду конечности графа G’ процесс построения новых вершин не
может продолжаться бесконечно, следовательно, при отсутствии
пути в 0Ц обнаружение признака недостижимости неизбежно.

Достаточность условия 1 признака недостижимости вытекает из
теоремы Жордана, так как если образовалась петля, то прямая
пересекает границу о у только один раз (в точке С\); Oi ЕЕ S, сле-
довательно, 0Ц ЕЕ Sy, где 1	7 ‘С п- Для доказательства достаточ-

ности условия 2 мысленно удалим из конфигурационного простран-
ства те из запретных зон Sy, на границах которых по алгоритму до
обнаружения условия 2 не построены точки, соответствующие верши-
нам графа G’. Очевидно, что если в полученном таким образом новом
конфигурационном пространстве, содержащем запретные зоны Sy
гДе 71 = 1, пп цель недостижима, то она недостижима и в исходном
конфигурационном пространстве. Справедливо утверждение: при
выполнении условия 2 признака недостижимости всякая касательная,
проведенная из 0Ц к границе оу,, где 1 <7 Д -Д т, пересекает по
крайней мере одну из запретных зон Sp, где 1 Д р Д их, на отрезке от 0Ц
до точки касания. Довольно громоздкое доказательство этого утверж-
дения опустим (укажем лишь, что в нем используется теорема Жорда-
на). Из этого утверждения следует, что при выполнении условия 2 не
существует отрезка ОДП СЕ S, т. е. цель недостижима.

Завершая описание алгоритма, отметим, что посредством исключе-
ния циклов из построенного пути на графе G' можно регулярным
образом найти простой путь, определяющий маршрут робота при
последующих перемещениях между точками, соответствующими
0" и 0Ц.

Доказательство сходимости алгоритма. В процессе отработки
предложенного алгоритма могут встретиться два случая: либо уста-
навливается признак недостижимости цели, либо он не обнаружи-
вается. В первом случае устанавливается факт недостижимости
данной цели, во втором — этап 2 может завершиться либо построе-
нием новой вершины Ок+1 и возвратом к этапу 1, либо переходом
к этапу 3. Как было показано выше, в результате выполнения этапа
3 при этих условиях всегда будет построена такая вершина (?a+i, при-
менение к которой оператора 1\ на этапе 1 приведет к переходу в
вершину 9Ц, т. е. и в этом случае «зацикливания» алгоритма не про-
изойдет. Сходимость доказана.

Заметим, что в доказательстве сходимости алгоритма никак не
использовались ни порядок перебора на этапе 3 построенных ранее
вершин С/r, ни порядок применения операторов Гл и Гп, ни конкрет-
ный способ перевода изображающей точки из текущего положения
в одну из ранее построенных вершин С* — все это можно варьировать
при настройке алгоритма с учетом особенностей конкретных решае-
мых задач.

РЕЗУЛЬТАТЫ МОДЕЛИРОВАНИЯ

Работа представленного алгоритма в задачах планирования движе-
ний роботов в сложных незнакомых средах исследовалась с помощью
машинного моделирования. Программная реализация алгоритма на
языке ФОРТРАН-IV при использовании операционной системы
RT-11 потребовала приблизительно ЮК байт оперативной памяти
(для графов, содержащих не более 60 вершин). Была проведена боль-
шая серия машинных экспериментов, в которых моделировалась
прокладка маршрута в цель для мобильного робота, снабженного дат-
чиками, сигнализирующими только о факте контакта робота с пре-
пятствием (что свидетельствует о попадании изображающей точки
на границу какой-то из запретных зон). Эта задача отличается до-
статочной наглядностью, поскольку она эквивалентна задаче поиска
пути изображающей точки, помещенной в центр робота, в целевую
точку в двумерном конфигурационном пространстве.

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

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

Начало

маршрута в незнакомой среде, если и не привели бы к зациклива-
нию движения робота, то потребовали бы перебрать все потенциаль-
но возможные траектории, фактически просканировав все доступное
пространство, прежде чем сделать обоснованный вывод, что в та-
кой среде цели вообще достичь нельзя. Действуя в соответствии с
предложенным алгоритмом, робот достаточно быстро установил факт
принципиальной недостижимости цели (см. рис. 2, б) и прекратил
движение, послав соответствующее сообщение оператору.

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

С

sh sh

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

допускается работа с препятствиями произвольной формы без их
аппроксимации какими-либо простыми геометрическими элементами
и не требуется предварительное построение запретных зон в кон-
фигурационном пространстве (это стало возможным благодаря пред-
ложенной модели конфигурационного пространства в виде неявно
задаваемого графа, который может наращиваться в процессе движения
робота «вслепую» на основе только локальной информации о его
контактах с препятствиями);

использование сформированной модели, сконцентрировавшей в'
себе приобретенные знания о среде, позволяет выделять на пост-
роенном графе путь, соответствующий рациональному маршруту
робота, рассчитанному на последующие перемещения между задан-
ными точками;

эффективно реализуется на ЭВМ и может быть адаптирован
к конкретным особенностям решаемой задачи с помощью вариации
ряда настраиваемых процедур.

ЛИТЕРАТУРА

1.	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.

2.	Петров А. А., Сирота И. M. Формирование движений манипуляционного
робота при обходе препятствий в условиях ограниченной информации
о среде.— Автоматика и телемеханика, 1983, № 4, с. 29—40.

3.	Сирота И. М. Планирование движения автономного робота для транспор-
тировки грузов в ГПС без маршрутопроводов.— В кн.: Состояние и развитие
гибких производственных систем. М.: МЦНТИ; МНИИПУ, 1986, с. 275 —
285.

4.	Lumelsky V. J. On Non-heuristic Motion Planning in Unknown Environment:
Prepr. 1st IFAC Symp. Robot Contr. Barcelona (Spain), 1985, p. 257—262.

5.	Кирилъченко А. А., Карпов И. И., Платонов А. К. Метод подцелей в задаче
выбора трассы мобильного робота в условиях неопределенности: Препр.
Ин-та прикл. математики им. М. В. Келдыша АН СССР № 16. М., 1983.
27 с.

6.	Ильин В. А., Ильина Т. Р., Кориков А. М. Вопросы теории алгоритмов
управления движением роботов в условиях неполной информации о внеш-
ней среде.— В кн.: Информационные и управляющие системы роботов. М.:
Ин-т. прикл. математики им. М. В. Келдыша АН СССР; МГУ им. М. В. Ло-
моносова, 1982, с. 170—177.

7.	Петров А. А., Перфильева И. М. Об управлении движениями роботов-ма-
нипуляторов с помощью ГВС. — В кн.: Тез. докл. VII Всесоюз. совещ.
по пробл. управления. М.; Минск: Ин-т пробл. управления; Ин-т техн,
кибернетики АН БССР, 1977, с. 294—297.

8.	Lozano-Perez Т. Automatic Planning of Manipulator Transfer Movements.—
IEEE Trans. Syst., Man and Cybern., 1981, vol. SMC-U, N 10, p. 681— 698;

9.	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.

10.	Малышев В. А., Тимофеев А. В. Алгоритмы построения программных дви-
жений манипулятора с учетом конструктивных ограничений и препятствий.—
Техн, кибернетика, 1978, № 6, с. 64—72.
УДК 621.865.8-5.С01.5

ПРОГРАММНО-АЛГОРИТМИЧЕСКОЕ ОБЕСПЕЧЕНИЕ
ДЛЯ*1 АНАЛИЗА ИЗОБРАЖЕНИЙ

В СИСТЕМАХ ТЕХНИЧЕСКОГО ^ЗРЕНИЯ

А. М. Михайлов

Техническое зрение становится неотъемлемой частью адаптивных
роботов и играет все большую роль по мере повышения степени ин-
теллектности робототехнических систем. Быстро растет число про-
мышленных применений систем технического зрения.

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

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

Как показал анализ алгоритмов технического зрения с точки
зрения реализуемости, многие теоретически хорошо проработанные
подходы оказались неадекватными [1].

Некоторые замечания по терминологии. Следует различать меха-
ническое переснятие в память изображения объекта и анализ этого
изображения. В последнее время все чаще можно встретить термин
«понимание изображения». В первом случае выходная информация
имеет вид матрицы яркостей {рпт} при п, т = 1, N, -где рпт —
яркость точки матрицы с координатами (п, т)\ N X N — формат
кадра. Во втором случае выходная информация системы зрения
имеет вид некоторой модели наблюдаемого объекта или сцены. Таким
образом, понимание изображения сводится к . построению и интер-
претации модели сцены.

Термин «распознавание» часто используется в смысле, идентич-
ном термину «классификация». При распознавании система выполняет
классификацию, т. е. определяет типы объектов. Результатом анали-
за является модель структуры наблюдаемых объектов и (или) их
взаимосвязи.

Типичные задачи, 'решаемые системами технического зрения.
В целом задачи можно подразделить на дву- и трехмерные, пред-
метные и структурные, статические и динамические [2].

Целью анализа изображений в двумерных предметных задачах
обычно являются:

выделение объектов на изображении;

распознавание типов объектов независимо от их угловой ориен-
тации, положения на плоскости и в заданных пределах от масштаба;

определение плоскостных и угловых координат объектов.
В трехмерных предметных задачах основная дополнительная опе-
рация — это определение дальности до выделенных объектов.

Структурные задачи связаны с построением и анализом машинных
моделей таких объектов, как чертежи, рисунки,изображения печат-
ных плат, кристаллов интегральных схем и др.

Динамические задачи возникают при необходимости мониторинга
объектов изображения в реальном масштабе времени.

Машинные модели. Используемые в качестве внутреннего машин-
ного представления при анализе изображений модели можно под-
разделить на векторные (интегральные) и структурные [2].

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

В простейшем случае (метод эталонного сравнения) оператор
преобразования имеет вид тривиальной единичной матрицы Е:

Е {р<{>} = {p(i~>},

где I — номер изображения, т. е. модель изображения — это матри-
ца изображения, формат которой совпадает с форматом кадра. Оче-
видный недостаток такого подхода состоит в том, что требуется слиш-
ком много памяти из-за большой размерности каждого эталона
(TV X N точек). Тем не менее такой подход находит применение
в задачах контроля качества, где зачастую требуется всего один эта-
лон — контрольный образец. Другой недостаток этого метода —
сложность обеспечения инвариантного распознавания при поворотах
и сдвигах. Эталонный метод использует применение при необходимо-
сти детального контроля сложной структуры.

Операторное распознавание (линейное) в общем случае имеет
следующий вид:

3 p(i)	где к = 1, К.

П, 7П=1

Здесь {pnm} — матрица г-го) изображения; {/iLi} — к-я матрица
оператора; fP — к-й признак г-го изображения; к — номер признака.

К достоинствам операторного распознавания относятся:
снижение размерности модели (К TV X 7V);

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

повышение надежности распознавания за счет осреднения при
суммировании.

Недостатком подхода является сложность обнаружения малых
дефектов объекта как следствие операции осреднения.

Структурная модель представляет собой набор выделенных струк-
турных элементов изображения объекта (например, множество узло-
вых точек) и отношений между ними:

(aiLa]) при i, / = 1, J,
где J — число выделенных элементов объекта; L — некоторое отно-
шение; — i-я узловая точка.

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

Критерии интерпретации моделей. Выбор критерия зависит от
типа используемой модели. Рассмотрим ряд критериев интерпрета-
ции векторных моделей.____

Пусть при к = 1, К — вектор признаков i-го класса, где
i G / — общее число распознаваемых классов.

Алгоритмы интерпретации могут быть основаны, в частности, на
среднеквадратичном критерии

3 (4-

1=1 2

или критерии Чебышева

шах | Д. — min,
лек	ier

где fi; при к = 1, К — вектор признаков классифицируемого вход-
ного объекта.

Эти критерии используют аддитивную пространственную норму.
Более эффективным критерием в отношении помехоустойчивости яв-
ляется мультипликативный критерий вида

3 шах{|4|7(|4^ + с),1Г1/(14\ f-c)}.

1=1

где константа с зависит от динамического диапазона признаков.

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

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

В общем случае локальные операции можно представить в сле-
дующем виде:

Рпт = / {Pn+i, m+P ПРИ О’ /) W X W И Т1,Ш — T^N

где / — арифметическая или логическая функция, значение кото-
рой зависит от состояния всех элементов изображения локального
окна; п, т — координаты точки в матрице выходного изображения;
W X W — формат локального окна, значительно меньший формата
кадра; N X N — формат кадра.
Последовательность точек изображения, проходимых центром
локального окна, зависит от типа системы сканирования. Исполь-
зуются три вида сканирования: линейное, полярное и контурное.

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

Нелокальные операции выражаются в общем случае в виде

У — f {Pnm} при (п, т) s S,

где у — результат линейного или нелинейного преобразования /;

S — множество точек, проходимых в процессе сканирования.

Рассмотрим несколько примеров локальных операций (формат
окна W X W выбран равным 3x3):

сглаживающий фильтр:

_ _ f 1, если pn+i> т+.’= 1 V (г, у) gXX[W,

Рпт [о, ~|;

расширяющий фильтр:

io,-];
оконтуривающий фильтр:

1

И	8,

ij=-l

1, если р =1
’ -	~пт

о, п-

Варьируя логическую функцию локального окна форматом
3x3, можно получить 2812 различных типов препарирования бинар-
ных изображений, поскольку общее число входных ситуаций филь- '
тра равно 512. Фильтр программируется в общем виде:

Pl	при	ООО	ООО	ООО
Pl	при	ООО	ООО	001
Рз	при	ООО	ООО	010
Р&12	при	111	111	111

где /ь£Е{0, 1} и i=l,512.

В системе технического зрения, разработанной в составе комплек-
са ПИКОМ [2], рассматриваемый фильтр реализован аппаратно на
базе микро-ЭВМ «Электроника-60» и выполняет одну операцию пре-
парирования изображения за 20 мс. Операции фильтрации могут
проводиться итеративно и сопровождаться при необходимости сменой
логической фильтрующей функции.
Такая аппаратура позволяет создавать системы обработки изоб-
ражений с обратной связью, в которой за такт времени в 20 мс’срав-
ниваются по заданной логике входной кадр и кадр, поступивший па
обратной связи (рис. 1):

= (Тп ф / (Д7п_1))тоа 2>

где 1п — изображение, поступившее в и-й момент времени; z-1 —
элемент задержки; А1п — рассогласование между изображениями;
/ — локальный фильтр; © — операция поточенного сложения кадров,
по mod2 или по какой-либо другой логической функции.

Структура с обратной связью по изображению позволяет управ-
лять динамикой изменения образов.

Рис. 1. Структурная схема обработки изображений с обратной связью

Рассматриваемый метод локальной фильтрации применяется для
обработки бинарных изображений. Непосредственное перенесение-
этого способа на случай многоградационных изображений невозмож-
но, так как невозможно запрограммировать реакцию фильтра на все
входные ситуации вследствие резкого увеличения их числа. Действи-
тельно, уже в случае 16 градаций яркости, когда для представления
одной точки изображения требуется четыре двоичных разряда, число'
входных ситуаций в рамке 3x3 составит 29Х4	64 млрд.

Однако если изменить понятие входной ситуации, то способ ло-
кальной фильтрации можно использовать и в случае многограда-
ционных изображений. Для этого под входной ситуацией будем по-
нимать не состояние девяти разрядов (гп г2, . . ., i9) локального окна
W X W, где ij G= {0,15}, а состояние перепадов яркости в цепочке-
последовательно взятых соседних разрядов. Тогда входная ситуа-
ция описывается, например, в виде = г2, i2 ©= i3, i3 ф it, = г8,
iB = Ч =/= Ч, h = Ч- При таком подходе общее число входных
ситуаций равно 256. Опыт показывает, что с помощью так определен-
ного фильтра с многоградационными изображениями могут быть
эффективно выполнены те же основные операции, что и с бинарными,
и в том числе оконтуривание.

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

с (INT (п + R cos (2n/c/7V)) == сп {к),

s (INT (т + R sin (2nk/N)) = sm (к)

для каждой контурной точки с координатами (п, т) ЕЕ С, где С —
множество всех контурных точек, просматриваются точки с (к),
s (к) локальной окружности, где к — О, М — 1.

Здесь R — радиус локальной окружности; М — число дискрет-
ных точек локальной окружности.

С помощью соответствующего выбора логической функции
/ {сп (к), sm (к)}, где к = О, М — 1, можно идентифицировать тип
каждой контурной точки (лежащая на прямолинейном отрезке,
угловая, ветвление и т. д.).

Этапы обработки изображений. В системах технического зрения
можно выделить три этапа обработки: предварительная обработка,
построение описаний, интерпретация описаний.

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

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

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

/р = I SoРп (р, ф), т (р, ф) exp (- /2rap/2V) | при р = pmin, pmax, (1)
где р — полярный радиус; <р — полярный угол; N — число дискрет-
ных полярных углов; pmjn, pmax — минимальный и максимальный
радиусы полярной системы сканирования, центр которой помещается
в центр тяжести распознаваемого объекта. Пространственная ин-
вариантность вектора признаков /р, где р = pmin, ртах, определяется
тем, что амплитудные характеристики одномерных преобразований
Фурье по окружностям не зависят от угловой ориентации распознавае-
мого объекта. Используемое число концентрических окружностей
обусловливается сложностью внутренней структуры объекта и
требованиями к помехоустойчивости распознавания. Информация,
•содержащаяся в фазовой характеристике преобразования, определя-
ет угловую ориентацию объекта.

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

ввода изображений и локальной фильтрации;

контурных описаний;

полярного распознавания;

интерпретации векторных моделей;

управляющий модуль верхнего уровня.

Первый модуль реализует этап предварительной обработки.
В процессе сканирования локального окна форматом W X W для
каждой точки р-пщ матрицы входного изображения в локальной
•окрестности анализируются перепады яркости (в случае многограда-
ционных изображений) или состояния разрядов (в случае бинарных).
Значение яркости соответствующей точки рпт выходного изобра-
жения является функцией состояния локального окна. На входе и
на выходе данного модуля информация имеет вид матриц изображе-
ний.

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

Модуль полярного сканирования реализует соотношение (1) и
находит пространственно-инвариантный вектор признаков. При этом
возможно движение центра полярного сканирования в непрерывном
режиме построчно либо перемещение скачками в центр тяжести оче-
редного распознаваемого объекта. Выходная информация модуля
имеет вид последовательности векторов признаков.

Модуль интерпретации сравнивает вектора признаков в темпе их
поступления с эталонными векторами, число которых равно числу
распознаваемых классов. Сравнение осуществляется в соответствии
с аддитивными и мультипликативными критериями. При интерпре-
тации структурных модулей работа проводится с описаниями в виде
наборов характерных точек и отношений между ними.

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

Прикладной пример. Для иллюстрации работы системы анализа
изображений рассмотрим локализацию заданного объекта в некото-
Рис. 2. Локализация контактных площадок кристаллов интегральных схем

а — исходное изображение (большие белые пятна — локализуемые контактные площадки;
остальные мелкие объекты — помехи); б — частично отфильтрованное;

рой структуре. Такая задача возникает, в частности, при анализе фраг-
ментов кристаллов интегральных схем. На рис. 2, а приведено ис-
ходное изображение, содержащее контактные площадки, форма ко-
торых близка к прямоугольной, и помехи, образованные бликами и
напыленными проводниками.

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


Рис. 2 (окончание)

— полностью очищенное фильтрацией от помех; г — локализованная угловая контактная
площадка

итераций локальной фильтрации показана на рис. 2, б—г. Опреде-
ление места каждой контактной площадки в общей структуре про-
водится с помощью модуля полярного распознавания.

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

Рассмотренный в работе подход к построению систем технической
зрения позволяет создавать системы анализа изображений, решаю-
щие достаточно общие задачи, такие, как:

пространственно-инвариантное распознавание и локализация
объектов;

распознавание структурных изображений и рельефов сцен;

управление динамикой изображений.

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

ЛИТЕРАТУРА

1.	Куафе Ф. Взаимодействие робота с внешней средой. М.: Мир. 1985. 285 с.

2.	Вычислительная техника в робототехнических системах и ГАП: Учеб, посо-
бие для втузов/ В. 3. Рахманкулов, Ж. П. Ахрамеев, В. В. Герасимов,
А. М. Михайлов, С. А. Переслени, Е. В. Наумов: Под ред. И. М. Макарова.
М.: Высш, шк., 1986. 144 с. (Робототехника и гибкие автоматизирован-
ные/производства. В 9 кн.; Кн. 4).

УДК 681.32

МОДЕЛИРОВАНИЕ РОБОТИЗИРОВАННОГО
ОБОРУДОВАНИЯ В ЗАДАЧАХ

ОРГАНИЗАЦИОННО-ТЕХНОЛОГИЧЕСКОГО
УПРАВЛЕНИЯ ГИБКИМИ АВТОМАТИЗИРОВАННЫМИ
ПРОИЗВОДСТВАМИ

В. А. Исаченко, В. С. Шишкин, В. Я. По лыска ли н

Состав и структура модели. Современное роботизированное техно-
логическое оборудование (РТО) представляет собой сложную тех-
ническую систему, характеризуемую большим многообразием сос-
тавляющих ее элементов. Если для описания системы выбрана сово-
купность наименований переменных хг, х2, . . ., хп, то состояние
этой системы в произвольный момент времени t определяется набо-
ром значений xt (£), х2 (t), . . ., хп (t), где xt (i) — значение перемен-
ной Xt при I = 1, 2, . . ., п в момент времени t.

Формально структура модели РТО описывается набором

N = (Q, S, F, Мо),

(О

где Q = {qt, q2, . . ., q10} — набор переходов; S = {sr, s2, . . ., si?) —
набор позиций; F —связи между элементами и sf, Мо — началь-
ная маркировка, сопоставляющая каждой позиции наличие или
отсутствие объекта.
Модель технологического оборудования
в виде К-сети

Кружок — позиция; жирная черта — пе-
реход; точка внутри кружка — маркер; gj
при г — 1, 10 и при з = 1, 3—основ-
ные и вспомогательные переходы соответ-
ственно; Sj — имеется хотя бы одна партия
деталей на обработку и (или) контроль; sa,
s3 и ss — s, и s9, st — оборудование соответ-
ственно не занято, исправно, загружено;
Ss, snt «и — разрешающие позиции; s10 —
оператор на месте; st2 — оборудование не-
исправно (профилактическое обслуживание
по потребности); s13 и s14 — su — оборудо-
вание не занято (соответственно обработан-
ная партия деталей отправлена на склад
и из-за поломки оборудования необрабо-
танная партия передана на другой станок)

В процессе эксплуатации оборудование переходит из одного сос-
тояния в другое. Модель переходов, или, говоря, другими словами,
модель РТО в виде Е-сети [1] представлена на рисунке.

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

В общем случае комбинация из четырех булевых переменных поз-
воляет идентифицировать 16 различных состояний РТО, однако фи-
зический смысл имеют лишь девять из них (см. таблицу).

Допустимые состояния РТО

м	Состояние оборудования	Иденти- фикатор	Код	Переход на рисун- ке
1.	Простой межоперационный	Zo	1000	X
2.	Загрузка	Z1	1101	91
3.	Наладка	z2	1100	?2
4.	Готовность	z3	1110	9"
5.	Обработка	z4	1111	
6.	Разгрузка яри аварийном или нормальном за- вершении работы	Zs	1001	Qst ?io
7.	Техническое обслуживание плановое или по потребности	Z6	0000	94, 9b
	Ремонт в процессе			
8.	наладки	z?	0100	9з
9.	обработки	Z8	0110 if	98
Оборудование исправно и находится в состоянии «межоперацион-
ный простой» (х4 = 1; х2 = х3 ~ х4 = 0) с момента ввода в эксплуа-
тацию, окончания обработки очередной партии деталей или окон-
чания сложного ремонта (планового или внеочередного).

В состоянии «загрузка» (х4 = х2 = 1; х3 = 0; х4 — 1) РТО на-
ходится при поступлении с оперативного склада (или накопителя)
очередной партии деталей или технологической оснастки, в состоя-
нии «наладка» (х4 = х2 = 1; х3 = х4 = 0) — с момента поступления
технологической оснастки, необходимой для обработки очередной
партии деталей, до окончания этой операции.

В состояние «готовность» (х4 = х2 = х3 = 1; х4 = 0) РТО пере-
водится после окончания наладки, в состояние «разгрузка» (х4 = 1;
х2 = хз — 0; х4 = 1) — после передачи обработанной партии дета-
лей и технологической оснастки на оперативный склад или нако-
питель.

Кроме шести основных состояний (см. № 1—6 в таблице), обору-
дование может находиться в состоянии ремонта. Причем здесь воз-
можны следующие случаи (см. соответственно № 7—9 в таблице):

^1 = х2 = х3 = х4 — 0 (оборудование не выполняет никаких
операций);

х4 = 0; х2 = 1; х3 = х4 — 0;

х4 = 0; х2 = х3 = 1; х4 — 0.

Состояние капитального ремонта оборудования не рассматри-
вается в связи с большими межремонтными интервалами.

Для переходов q4, q2 и qe реализуются соответственно следующие
логические функции:

«1 Л «2 Л S3,

S', /\ (»4 ® 8И),

$9 Д ф s10).
>

Каждому переходу ставится в соответствие математическое ожи-
дание и дисперсия времени срабатывания.

Закон изменения состояния оборудования zt (t) можно записать
в виде

Zi (t) = Д + a (тц. — t),

где Д — ожидаемое время прерывания в состоянии гг; а — —1 —
скорость изменения состояния оборудования; т/- — момент времени
перехода оборудования из состояния гг в состояние Zj.

В процессе убывания величина z, (t) достигает значения, равного
нулю в момент времени t* = tz + Tft, что означает, что совершает-
ся «мгнэьенный» скачок и оборудование переходит из состояния z;
в одно из разрешенных состояний Zj.

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

Прежде всего объект может перемещаться только из входной
позиции перехода в его выходную позицию. Для этого перемещения
необходимо, чтобы соответствующий переход стал активным, что
возможно лишь в том случае, когда в каждой из его входных пози-
ций имеется хотя бы один объект. Исключение составляют переходы
qY и д2, активизация которых осуществляется в соответствии с ло-
гическими функциями

«5 Л ($11 © «4) И S9 Д (Sg © Slo).

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

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

Важной особенностью модели РТО является наличие в ней раз-
решающих позиций Sg, sn и si?, которые играют управляющую роль
для тех переходов, с которыми они связаны, и позволяют организо-
вать в модели условные ветвления и переключения при перемеще-
нии объекта:

{А — оборудование неисправно (поломки в процессе наладки),
В — отсутствует оператор,

С — оборудование налажено;



'Ai—оборудование неисправно (поломка в процессе обработки),

В — отсутствует оператор,

D — оборудование не налажено (требуется подналадка),

Е — партия деталей обработана,

А2— оборудование неисправно (профилактическое обслуживание по
потребности);



А3— оборудование неисправно (плановое профилактическое обслу-
живание),

р — оборудование не занято (обработанная партия деталей отправ-
лена на склад).

Выбор пути перемещения (разрешающая процедура) объекта из
позиций si, и л? осуществляется в соответствии с выражением

Qi = t Р (<7,:)н > N =

j1 при Р (?.)н > г < Р (?(i+a))H,
10 при Р(?4)н<г,

где Р(?г)н — координата нижней границы участка на отрезке (0, 1),
характеризующего относительное время пребывания оборудования
в состоянии qt; г — реализация равномерно распределенной в ин-
тервале (0, 1) случайной величины; i — / (s7-) — множество номеров
переходов, связанных с позицией s/ (г + а) — номер перехода,
ближайшего к переходу и выходящему из одной и той же пози-
ции Sj.

Расчет вероятности перемещения объекта из позиции s} к пере-
ходу q} осуществляется по формуле

P^^ = PzJ^Pz. при i = f(Sj),

где Pz. — вероятность пребывания оборудования в состоянии qt.

Для расчета вероятности пребывания оборудования в состоянии
qt используется выражение

Рг, = П₽И Ч е

где tQ — время пребывания оборудования в состоянии qt в интер-
вале планирования 71; Т\— режимный фонд времени работы обору-
дования в интервале планирования Т.

Процесс взаимодействия элементов модели можно представить
следующим образом.

В начальный момент времени t0 ЕЕ Т (до запуска модели) в пози
циях s2, s3, s6 — s-г, s9 и s10 помещаются маркеры, обеспечивающие
при поступлении объекта условия активизации для соответствую-
щих переходов. Начальная маркировка отражает нахождение обо-
рудования в состоянии межоперационного простоя.

При возбуждении генератора X внешним источником в позиции
Si формируется маркер и запускается переход q1, что соответствует
выдаче локальной системой управления технологическим оборудо-
ванием сообщения о начале загрузки РТО:

Уч = (Zfc, тк, I),

где Уч — сообщение о состоянии оборудования в момент времени
tit ЕЕ Г; Zu — код состояния оборудования в момент времени т»;
I — дополнительная информация, варьируемая в различных сооб-
щениях и содержащая, например, номер станка, шифр детали, но-
мер операции и т. п.

Дальнейшее функционирование модели осуществляется в соответ-
ствии со схемой, представленной на рисунке

Программное обеспечение модели. В режиме отображения мо-
дель РТО функционирует в рамках локальной вычислительной сети
мини- и микро-ЭВМ. Основными компонентами этой сети являются:
локальная система управления технологическим оборудованием:
центральная ЭВМ;

автоматизированное рабочее место диспетчера;

модули связи локальной системы управления технологическим
оборудованием и автоматизированным рабочим местом диспетчера
с центральной ЭВМ

В качестве центральной ЭВМ используется ЭВМ СМ-4 с опера-
ционной системой ОС РВ и комплектом программ, необходимых для
обработки информации, поступающей ст системы диагностики РТО
214
или от оператора локальной системы управления. В качестве внеш-
ней памяти для хранения этой информации используются накопи-
тели на магнитных дисках.

Для связи локальной системы управления и автоматизированного
рабочего места диспетчера с ЭВМ СМ-4 используется модуль даль-
ней связи, выполненный на аппаратуре в стандарте КАМАК.

Программное обеспечение модели оформлено в виде отдельного
модуля, включающего в себя программы:

ввода оперативных директив и организации вычислительного
процесса;

организации и ведения информационных массивов модели;

выдачи и отображения результатов моделирования.

Оператор локальной системы управления непосредственно взаи-
модействует с драйвером терминала или модулем интерфейса клавиа-
туры, рассчитанного на работу с дисплеем типа ВИДЕОТОН-340.

При работе с моделью оператором локальной системы управле-
ния используется набор директив.

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

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

Первоначальные исходные данные, требуемые для функциониро-
вания модели РТО, вводятся с терминала диспетчера или переписы-
ваются с помощью программы организации информационных мас-
сивов из базы данных системы организационно-технологического
управления ГАП.

Диспетчер непосредственно взаимодействует с драйвером тер-
минала или модулем интерфейса клавиатуры.

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

Для реализации режима имитации программное обеспечение мо-
дели включает в себя также датчики случайных чисел, равномерно
распределенных в интервале (0, 1), и программу имитации моментов
перехода оборудования из одного состояния в другоег

ЛИТЕРАТУРА

1. Костин, А. Е. Принципы моделирования сложных дискретных систем:
Учеб, пособие. М.: МИЭТ, 1983.
СРЕДСТВА ПРОГРАММИРОВАНИЯ

И МОДЕЛИРОВАНИЯ ДЛЯ РОБОТОВ

И ГИБКИХ ПРОИЗВОДСТВЕННЫХ СИСТЕМ

УДК 681.32

ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РАЗРАБОТКИ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ГИБКИХ АВТОМАТИЗИРОВАННЫХ ПРОИЗВОДСТВ

М. В. Дудкин, А. И. Казьмин, А. А. Меин,
В. Н. Пополитов

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

Однако прежде чем рассматривать методы автоматизации проекти-
рования программного обеспечения отметим некоторые особенности
систем управления гибких производств [1].

Распределенная система управления. Технической базой систем
управления ГАП служит, как правило, распределенный вычисли-
тельный комплекс, упрощенная структурная схема которого показа-
на на рисунке. Как и в других публикациях о распределенных сис-
темах управления (см., например, [2, 31), будем абстрагироваться от
физической реализации среды передачи, так как создаваемые инстру-
ментальные средства должны быть применимы при различных реа-
лизациях среды передачи.

Использование функциональной схемы распределенной системы
управления имеет большое значение для проектирования инструмен-
тальных средств поддержки разработки. Функциональная схема оп-
ределяет предполагаемое распределение задач между вычислитель-
ными машинами распределенной системы управления и типы инфор-
мационных связей между задачами. Функциональная схема распреде-
ленной системы управления, примененная в разработках ГАП [1]в
показана на рисунке (функциональная схема не отражает структуры
соединений ЭВМ, поэтому структурная и функциональная схемы
могут в общем случае не совпадать).

В функциональной схеме распределенной системы управления
выделены три группы ЭВМ:
a

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

первая условно названа контроллерами (ЭВМ-контроллеры управ-
ляют технологическим оборудованием; в качестве примера контрол-
леров сошлемся на ЭВМ, входящие в состав числового программного
управления (ЧПУ) станков, или на ЭВМ, управляющие роботами);

вторая — ЭВМ-координаторы (объединяют контроллеры в систе-
му управления производственным модулем или группой модулей);

третья группа ЭВМ, выделенная на функциональной схеме, —
ЭВМ, планирующие работу оборудования (функции этой группы
мало изменяются при переходе на распределенное управление; как
и в случае централизованных систем автоматического управления,
планирующие ЭВМ решают задачи календарного и оперативного
планирования, учета, ведения документации и т. д.).

Анализ функциональной схемы системы управления показывает,
что при распределенном управлении появляется один существенно
новый компонент — ЭВМ-координаторы.

Введение ЭВМ-координаторов создает следующие преимущества:
упрощается организация совместной работы нескольких контрол-
леров;

появляются дополнительные возможности развития системы уп-
равления за счет введения новых координаторов и контроллеров или
модификации программного обеспечения уже работающих ЭВМ (при
этом существенно, что модификация программного обеспечения
имеет локальный характер);

упрощаются программное обеспечение и технические средства
контроллеров (появляется возможность использовать контроллеры,
которые не имеют специальной ориентации на работу в составе гиб-
кого автоматизированного производства);

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

управление контроллерами (выдача заданий контроллерам и про-
верка результатов выполнения заданий, которые могут выдаваться
различным контроллерам строго последовательно или последова-
тельно-параллельно; последовательно-параллельный способ управ-
ления требует от координаторов наличия режима разделения вре-
мени, что усложняет их программное обеспечение, однако при этом
способе может быть достигнуто ускорение технологического процесса
за счет одновременной работы нескольких контроллеров);

обмен информацией с другими ЭВМ-координаторами (информа-
ционные связи, которые должны быть установлены между коорди-
наторами, в значительной степени зависят от особенностей конкрет-
ного производства; при изменении производственного процесса,
как правило, возникает необходимость в изменении информационных
связей; вследствие этого желательно иметь такие инструментальные
средства, которые позволяют программировать связные функции и
не затрагивают при этом функции управления контроллерами);

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

Перечисленные задачи определяют набор инструментальных
средств, требуемых для поддержки разработки системы управления
ГАП, состоящий из операционной системы реального времени, не-
обходимой для последовательно-параллельного управления контрол-
лерами, языка и исполнительной системы для программирования
информационных связей между координаторами [4], а также систе-
мы отладки взаимосвязанных программ, выполняющихся на одной
или нескольких ЭВМ-координаторах. Механизмы удаленного фай-
лового доступа уже подробно рассматривались в литературе (см.,
например, публикацию [5]), поэтому в статье эти механизмы не за-
трагиваются.

Операционная система ЭВМ-координатора. Обычно операцион-
ные системы не относят к числу инструментальных средств. В уни-
версальных ЭВМ операционные системы создают вычислительную
сРеДУ, в которой выполняются прикладные программы. Однако д
случае ЭВМ-координаторов создание постоянной вычислительной
среды, по-видимому, нецелесообразно, поскольку для этих ЭВМ
трудно выделить сколько-нибудь постоянный набор действий, эф-
фективно используемый в широком классе приложений. Включение
в операционную систему избыточных возможностей завышает тре-
бования к техническим характеристикам ЭВМ-координаторов. В то
же время желательно применять в качестве координаторов микро-
ЭВМ с небольшим объемом памяти: в этом случае можно включать
в состав системы управления столько ЭВМ, сколько требует функ-
циональная схема системы управления ГАП, не ограничивая их
число из экономических соображений.

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

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

Основу операционной системы составляет диспетчер процессов.
Любая процедура пользователя может быть объявлена процессом,
который диспетчер будет рассматривать как самостоятельную еди-
ницу исполнения. Все процессы должны быть объявлены стати-
чески, до начала исполнения каких-либо процедур. Для каждого
процесса диспетчер формирует блок управления, в котором сохра-
няются данные, необходимые для запуска процесса и его работы.
Одна и та же процедура может принадлежать двум и более про-
цессам (в этом случае для каждого процесса формируется свой блок
управления).

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

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

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

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

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

Множество состояний процессов ограничено тремя элементами.
Процесс может быть:

ждущим (если он задержан до наступления некоторого события);

готовым (если все события, ожидаемые процессом, уже сверши-
лись);

активным (если он получает в свое распоряжение процессор).

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

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

Язык для организации информационных связей между коорди-
наторами. При создании языка преследовались следующие цели
[4, 61:

обеспечить легкое описание (а при необходимости и изменение
описания) информационных связей между координаторами;

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

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

Язык включает три основных понятия: порт, связь между пор-
тами и исключительная ситуация.

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

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

В языке имеются операторы, описывающие связи портов. Метод
описания связей между портами продемонстрируем на следующем
примере:

СВЯЗАТЬ Pl, Т1 => Р2. Т2, РЗ. ТЗ,	(1)

где Р1—РЗ — имена портов, а Т1—ТЗ — имена ЭВМ-координаторов,
в которых эти порты размещены.

Допускается задание одновременных связей одного порта с не-
сколькими другими, как в выражении (1), а также альтернативных
связей. Одновременные связи определяют широковещательную пере-
дачу сообщений, а альтернативные — предусматривают возможность
передачи информации в резервный порт при отказе ЭВМ, где разме-
щалась основная копия порта.

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

Связь может устанавливаться только между активными и пассив-
ными портами или портами с внешним управлением. Активный порт
может инициировать передачу или чтение данных, а пассивный
лишен такой возможности. Синхронный порт может задерживать опе-
рацию обмена с другим портом, в то время как асинхронный передает
информацию независимо от того, занят или свободен взаимодейст-
вующий с ним порт. Порт с внешним управлением становится актив-
ным не после операции чтения или записи в него, а по специальной
команде, которая может поступить, например, от операторов «иск-
лючительная ситуация». Такие операторы позволяют установить со-
ответствие между ошибками, возможными при передаче данных,
и процедурами их обработки.

В результате появляется возможность эффективно реагироват >
на такие ошибочные ситуации, как превышение допустимого вре-
мени ожидания данных, их искажение и др.

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

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

В каждый момент времени каждому процессу соответствует неко
торое состояние. Это означает, что совокупность процессов может
быть описана множеством пар процесс— состояние (размерность мно-
жества равна количеству процессов в системе). Расширением множе-
ства состояний можно максимально конкретизировать описание хода
взаимодействия процессов в распределенной системе.

Будем считать пару процесс—состояние (р—s) существующей,
если процесс р имеет состояние s. Отсюда легко получаются понятия:
«появление пары процесс—состояние», «отсутствие пары», «история
пары процесс—состояние».

Введем понятие «индикатор отладки». Индикатор есть логическая
величина, ассоциированная с парой процесс—состояние. Значение
true индикатор отладки имеет, если существует пара процесс—со-
стояние, ассоциированная с ним. Событие отладки есть функция
индикаторов отладки, сконструированная по правилам, вводимым
в каждом конкретном случае. Система отладки должна отслеживать
значение индикаторов и проверять, какие события получили значе-
ние true. При наступлении заказанного программистом события от-
ладки исполняется то отладочное действие, которое установлено для
данного события. Простейшими из отладочных действий являются
прерывание работы и выход в диалог с программистом, ведущим сеанс
отладки.

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

При отладке межмашинных взаимодействий процессов возникает
одна специфичная проблема. Если использовать традиционные сред-
ства, программисту время от времени придется пересаживаться с пуль-
та одной ЭВМ за пульт другой. Чтобы избежать этого, применяются
средства, позволяющие работать с программой с единого пульта.
В составе распределенного комплекса выделяется специальная «отла-
дочная» ЭВМ, управляющая вычислительным процессом во всех взаи-
модействующих машинах. В каждой ЭВМ, имеющей отлаживаемые
программы, размещается небольшая часть распределенного отлад-
чика, отображающая состояние вычислительного процесса в состоя-
ние индикаторов отладки. Изменения в их состоянии передаются
«отладочной» ЭВМ. При наступлении события начинают действовать
специальные процедуры, которые могут привести к временному пре-
кращению вычислительного процесса только в той ЭВМ, где насту-
пило ожидаемое событие, или в произвольной группе связанных
ЭВМ.

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

ЛИТЕРАТУРА

1.	Распределенный вычислительный комплекс для управления технологиче-
скими процессами (структура и программное обеспечение)/А. И. Казьмин!
А. А. Менн, М. В. Дудкин, И. В. Золотарев, Б. Д. Мандель, В. Н. Попо-
литов, В. Г. Сперанский, А. В. Шерстюк, В. В. Шаталов: Препр. М.: Ин-т
пробл. управления, 1984. 47 с.

2.	Kramer JMagee J., Sloman M., Lister A. CONIC: an integrated approach
to distributed computer control systems.— IEEE Proc., 1983, p. 1 —10.

3.	May D. OCCAM.- Singplan Notes, 1983, vol. 18, N 4, p. 69—79.

4.	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: IFAC. 1984, vol. 2, p. 149—153.

5.	Introduction to DECNET (AA-1055A-TK). Mainard (Mass.): DEC, 1981.
79 p.

6.	Менн A . A., Пакштас А. А. Технология подготовки программ для распреде-
ленных вычислительных сетей.— В кн.: Междунар, науч.-техн. конф.
«Программное обеспечение ЭВМ», Калинин, 1984: Тез. докл. Секция 3. Кали-
нин: НПО «Центрпрограммсистем», 1984, с. 87—89.

УДК 519.682

. язык

ДЛЯ РЕАЛИЗАЦИИ АЛГОРИТМОВ УПРАВЛЕНИЯ
В РОБОТОТЕХНИКЕ

II.	Е. Богомолов, Ю. М. Лазутин, В. С. Ярошевский

Основной областью применения ориентированного на структурное
программирование языка высокого уровня МЭЛ является создание
математического обеспечения задач робототехники и связанных с ни-
ми задач системного программирования, решаемых на мини- и мик-
ро-ЭВМ.

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

Разработка программного обеспечения робототехнического комп-
лекса, как и всякого реализуемого на ЭВМ крупного проекта, начи-
нается с решения проблем: какие программные средства, какой язык
программирования использовать для формирования алгоритмов
управления. Выбор должен осуществляться с учетом требований и
особенностей проблемной области (робототехники). Желательно,
чтобы язык был мощным, ноне перегруженным редко используемыми
конструкциями.

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

ориентация на структурное программирование (программы долж-
ны быть понятны не только их разработчику);

мобильность, переносимость программ не только на разные вер-
сии операционной системы, но и на другие типы ЭВМ;

открытость языка (возможность его дальнейшего развития для
создания специализированных языков робототехники: языка прог-
раммирования сборки, сварки и т. д.);

широкий спектр логических операций;

мощный набор управляющих операторов (операторов передачи
управления);

наличие средств организации структур данных;

возможность разделения генерируемого кода на изменяемую и не-
изменяемую части для последующего размещения управляющих
программ роботов в постоянной памяти (ППЗУ/ПЗУ);

модульное программирование и жесткий контроль за числом и
типом параметров;

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

В языке МЭЛ в той или иной степени реализованы перечисленные
требования. Он развивался на основе ФОРТРАНа. С точки зрения
авторов язык ФОРТРАН обладает рядом недостатков, в частности:
на каждой строке размещается только один оператор и недопустим
комментарий (программа «разбухает» и теряется ее обозримость);

отсутствуют операторы структурного программирования (появ-
ляется множество лишних меток и сильно усложняется чтение про-
граммы);

нет доступа к внешним устройствам с языкового уровня (необхо-
димы лишние подпрограммы и функции, написанные на языке Ас-
семблера).

Эти недостатки были учтены при разработке языка МЭЛ.

Па первом этапе создания транслятора считалось, что развивать
сложные типы и структуры данных нет необходимости и можно огра-
ничиться только словным типом (для мини-ЭВМ — два байта), ко-
торого достаточно для реализации простых программных комплек-
сов. В первой версии языка существовало три типа программных мо-
дулей: головная программа (PR), подпрограмма (SR), функция (FN).
Каждый объект языка имел свой оператор-описатель. Указывались
все объекты, используемые в программе, в том числе и формальные
параметры (как на ФОРТРАНе параметры-массивы). Имелся опера-
тор условного ветвления с альтернативами. Из операторов циклй
был реализован только RP. Допускались не все операции из совре-
менного набора. Кроме того, для упрощения транслятора (он в то вре-
мя был написан на ФОРТРАНе) в арифметических выражениях от-
сутствовали приоритеты операций, значение выражения вычислялось
слева направо. Для лаконичности программирования обозначения
всех операторов языка сделаны двухбуквенными.

Опыт эксплуатации показал, что такой язык достаточно слаб и не
защищает от ошибок пользователя. Несмотря на структурную кон-
струкцию оператора передачи управления, программа содержала
много меток. Вследствие этого получили развитие конструкции услов-
ной передачи управления и цикла. Добавились операторы: альтерна-
тивы (AF и CF) в конструкцию условного ветвления IF; заголовка
цикла (RW и RU); альтернативных условий (АР, SP, ХР, СР) в цик-
ле. Появилась возможность ввести условие в операторе закрытия
цикла ЕР. Введение указанных операторов сильно структурировало
программы и позволило практически полностью отказаться от исполь-
зования меток. В то же время стала сказываться диспропорция раз-
вития языка: чрезмерное увеличение объема операторов-описателей
DC по сравнению с исполнительной частью программ; слабое разви-
тие арифметических выражений.

Для уменьшения объема операторов DC были введены модули (MD
и ED), с помощью которых пользователь управляет областью дей-
ствия описателей. Одновременно снизилась нагрузка на програм-
му «Редактор внешних связей», так как многие идентификаторы из
внешних по отношению к подпрограммам и функциям превратились
во внутренние для объемлющего модуля. Благодаря этому умень-
шился объем программ, улучшилась их обозримость. Программы,
работающие с одним и тем же набором данных, сгруппировались.

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

Опытная эксплуатация в течении года этой версии языка МЭЛ
выявила следующее:

описание формальных параметров одновременно в операторах
SR/FN и в DC излишне и приводит к ошибкам;

одного словного типа данных Недостаточно;

желательно введение в язык структур данных.

Фактически опытная эксплуатация показала, что исполнитель-
ные (управляющие) операторы хорошо проработаны и удовлетвори-
тельны по мощности, а средства представления структур и типов
данных развиты слабо. Двойное описание формальных параметров
было легко исключено. Введение же различных типов данных потре-
бовало тщательного рассмотрения проблем их задания и преобразо-
вания. Определившись со способом описания (указывается в квадрат-
ных скобках [ ... 1), разработчики решили запретить подразумевае-
мое преобразование типов данных. Были введены следующие четыре
типа: БАЙТ, СЛОВО, ДВОЙНОЕ СЛОВО С ФИКСИРОВАННОЙ
ТОЧКОЙ, ПЛАВАЮЩАЯ ТОЧКА. Одновременно определили ба-
зированный способ доступа, что позволило организовывать сложные
структуры данных. В языке МЭЛ считается, что все структуры ста-
тические. Формирование динамического изменения структур в на-
стоящее время возложено на пользователя — эта возможность не
запрещена.

Дальнейшая эксплуатация языка привела к появлению типа дан-
ных АДРЕС [D] (порядковые числа), так как проверка условий для
адресного типа выполняется на ЭВМ с системой команд семейства
«Электроника-60» иначе, чем для словного типа. Кроме того, были
введены операции логического сдвига через С-разряд.

Мы не касались описания реализации оператора безусловного пе-
рехода СО. Структуризация конструкций управления последова-
тельностью действий позволила, как отмечалось, писать программы
практически без меток. Поэтому на определенном этапе разработ-
чики хотели вообще убрать из языка метки и оператор GO. Однако
с расширением типов и классов формальных параметров появилась
возможность передавать адреса меток в качестве параметров. Благо-
даря этому оператор GO стал использоваться как удобное средство
обработки аварийных ситуаций: при обнаружении ошибки во вложен-
ной подпрограмме^функции управление единообразно передается на
соответствующий модуль, что повышает надежность, наглядность
программы, способствует структуризации всего комплекса.

Последней появившейся в МЭЛ конструкцией являются операторы
распараллеливания процессов: ВТ, GT, ЕТ. Они являются специ-
фичными для робототехнических систем и подразумевают разработ-
ку операционной системы непосредственно пользователем (либо связь
с операционной системой реального времени, стандартно установ-
ленную на данной ЭВМ).

В системе программирования, поддерживающей язык МЭЛ, есть
возможность разделения программ на постоянную (ПЗУ) и перемен-
ную (ОЗУ) части. Она задается командой управления работой транс-
лятора и к языку непосредственного отношения не имеет. Следует
отметить, однако, что эта возможность позволила освободить пользо-
вателя от большого объема работ по разнесению рабочих перемен-
ных и обрабатывающих их программ в разные части адресного про-
странства.

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

Приводимое описание МЭЛ предназначено для программистов,
знакомых с одним из языков высокого уровня мини- или микро-ЭВМ
(например, PLM, Ch,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 — приоритет операции (большему
Таблица 3

Содержание операции	1	2	3	4	5	6
Присвоение левому операнду значения		L = В	0	В	В	В
правого				w	w	w
				I	I	I
				F	F	F
				D	D	D
Сложение по модулю 2	#	L#R	1	В	В	В
Логические операции				w	D	D
'ИЛИ'	V	LVR	2	w	W	W
'И'	л	LAR	3	D	В	D
				D	w	D
				в	D	D
Сдвиг						
ар ифметический						
вправо		L = >R	4			
влево	=	L< = R	4	I	W	I
	:				w	W	W
логический				B	В	В
вправо		L > R	4	w	В	W
влево		L<R	4	I	В	I
циклический				в	W	В
вправо		L> R	4			
влево		L<R	4			
Инверсия				— R	5	нет	В	В
					w	w
					I	I
					F	F
Сложение	+	L + R	5	в	В	В
Вычитание		L-R	5	w	W	W
				I	r	I
				F	F	F
				[ D	В	D
				D	W	D
				В	D	D
				W	D	D
				J D	D	W
Умножение	*	L*R	6	В	В	В
Деление	у/	L/R	6	W	W	w
Остаток от деления		L\R	6	I	I	I
				F	F	F
Косвенная адресация	@	@R	7	нет	W	w
					D	w
Определение адреса			8	нет	В	D
					w	D
					I	D
					F	D
					D	D
значению числа соответствует больший приоритет); 4, 5 — тип ле-
вого и правого операнда соответственно; 6 — тип результата.

Для операции присвоения левый операнд может быть переменной
или произвольным арифметическим выражением, в котором послед-
ней выполняемой операцией является косвенная адресация.

ОФОРМЛЕНИЕ ПРОГРАММЫ

Алгоритм на языке МЭЛ записывается как последовательность моду-
лей, которые бывают описательными и исполняемыми.

Описательный модуль начинается оператором MD, заканчивается
оператором ED и служит для ограничения области действия иденти-
фикаторов. Внутри описательного модуля можно поместить один
или несколько любых других модулей.

Исполняемый модуль начинается одним из следующих операто-
ров: PR (головная программа), SR (подпрограмма), FN (функция),
а заканчивается оператором EN. Кроме ограничения области дей-
ствия определенных в нем идентификаторов, исполняемый модуль
описывает преобразование (обработку) данных, т. е. содержит испол-
няемые операторы.

За оператором начала всякого модуля следует оператор DC,
описывающий используемые идентификаторы.

В общем виде структура модулей языка МЭЛ следующая:

исполняемый

PR, SR, FN

DC, X, ...

ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ ОБЛАСТЬ ДЕЙСТВИЯ

EN	ИДЕНТИФИКАТОРОВ X, ...

описательный

MD	ОБЛАСТИ ДЕЙСТВИЯ

DC X, ...

ВЛОЖЕННЫЙ

МОДУЛЬ

DCY, ...	ИДЕНТИФИКАТОРОВ	ИДЕНТИФИКАТОРОВ

ВЛОЖЕННЫЙ Y, ...	X, ...

МОДУЛЬ

ED

Операторы программы записываются построчно с произвольным
размещением. Никаких дополнительных символов для продолжения
оператора на следующей строке не требуется. Разделителем являет-
ся пробел или группа пробелов. Комментарий начинается символом
«;». Признаком окончания комментария является либо тот же символ,
либо конец строки.

Пробелы не допустимы внутри констант (за исключением тексто-
вых, в которых пробелы несут смысловую нагрузку), идентификато-
ров, многосимвольных операций, между идентификатором массива и
открывающей скобкой указателя номера элемента, между идентифи-
катором подпрограммы или функции и скобкой, открывающей спи-
сок параметров, между меткой и двоеточием, определяющим ее.
ОПЕРАТОРЫ ЯЗЫКА МЭЛ

Оператор-описатель DC имеет формат:

ИС[(КЛАСС)(ТИП) (СПОСОБ ДОСТУПА)] (СПИСОК ЭЛЕМЕНТОВ)

формат элементов списка:

ИДЕНТИФИКАТОР ((РАЗМЕРПОСТЬ>)/(ПАЧАЛЬНЫЕ ЗНАЧЕНИЯ) /

Каждый идентификатор из списка занимает участок памяти в со-
ответствии с заданным классом, типом, размерностью и располагает-
ся в памяти последовательно за предыдущим идентификатором. На-
чальный адрес списка определяется способом доступа.

В списке идентификаторов могут быть заданы, кроме текстового
имени идентификатора, его размерность (для классов «переменные»,
«подпрограммы», «функции») и начальное значение (для класса «пе-
ременные»).

Размерность переменной означает, что описывается массив с ука-
занным числом элементов. Если необходимо определить начальный
элемент, отличный от единицы, то задается пара — начальный и
конечный элементы, разделенные двоеточием. Допустимы отрицатель-
ные номера элементов.

Размерность подпрограммы/функции — это число параметров при
обращении к ней. В случае переменного числа параметров ставится
символ $.

Начальное значение — последовательность константных выраже-
ний (по количеству не превосходящая число простых переменных,
зарезервированное описываемым идентификатором). Для повторяю-
щихся значений допустима конструкция

N * (ЗНАЧЕНИЕ)

Здесь N — число повторений.

Для идентификаторов с базированным способом доступа после
символа * требуется задание адреса. Возможны следующие спосо-
бы его задания:

*	ИДЕНТИФИКАТОР

*	# ИДЕНТИФИКАТОР

♦ПЕРЕМЕННАЯ (КОНСТАНТНОЕ
ВЫРАЖЕНИЕ)

♦	# ПЕРЕМЕННАЯ (КОНСТАНТ-

НОЕ ВЫРАЖЕНИЕ)

♦	КОНСТАНТНОЕ ВЫРАЖЕНИЕ

♦	# КОНСТАНТНОЕ ВЫРАЖЕНИЕ

Адрес описываемого идентификатора
содержится по адресу указан ого и ен
тификатора
совпадает с адресом указанного иден-
тификатора
содержится по адресу указанного эле-
мента массива
совпадает с адресом указанного эле-
мента массива
совпадает с указанной константой
содержится по указанному адресу

По умолчанию: если опущен символ типа, то он считается слов-
ным (W): если опущен символ класса идентификатора, то идентифи-
катор считается переменной; если опущен способ доступа, то он счи-
тается внутренним (R).

Заголовок описательного модуля следующий:

MD ИДЕНТИФИКАТОР
Заголовком исполнительного модуля может быть один из операто-
ров:

PR ИДЕНТИФИКАТОР

SR ИДЕНТИФИКАТОР

FN[<THH>] ИДЕНТИФИКАТОР

SR ИДЕНТИФИКАТОР (PAR1, PAR N)

FN[<THH>] ИДЕНТИФИКАТОР (PARI, PAR N)

Параметр PAR имеет формат:

[<КЛАСС><ТИП>] ИДЕНТИФИКАТОР (<РАЗМЕРНОСТЬ>)

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

ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ

Оператор присваивания имеет формат:

ПЕРЕМЕННАЯ = АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ
или

ПЕРЕМЕННАЯ (АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ) = АРИФМЕТИ-
ЧЕСКОЕ ВЫРАЖЕНИЕ

или

(® (АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ) = АРИФМЕТИЧЕСКОЕ ВЫРА-
ЖЕНИЕ

По адресу, определенному в левой части равенства, заносится зна-
чение выражения, полученное в правой части равенства.

Операторы безусловного перехода бывают двух видов.

Оператор безусловного перехода на метку имеет формат:

GO ИДЕНТИФИКАТОР

Метка-идентификатор должна быть либо описана в операторе DC
и задана в программе среди исполнительных операторов следующим
образом:

ИДЕНТИФИКАТОР:,..

либо присутствовать среди формальных параметров подпрограммы
функции.

Операторы пропуска образуют конструкцию, которая начинается
с заголовка SK, может содержать одно или несколько продолжений
CS и заканчивается оператором ES. Выполняемые передачи функцио-
нально могут быть описаны операторами:

SK	GO LABEL

CS	GO LABEL

ES LABEL: ...
Оператор условного перехода может быть записан в виде простого
оператора IF, который имеет формат:

IF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ EF

Если условие истинно, то выполняются все исполняемые операто-
ры до оператора EF, иначе управление передается на первый ис-
полняемый оператор, следующий за EF.

Условие — логическое выражение. Различают следующие усло-
вия:

простое — выражение вида

(АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ & АРИФМЕТИЧЕСКОЕ ВЫРА-
ЖЕНИЕ)

Здесь & — любая из операций отношения: «<3> (меньше), «>»
(больше), «=» (равно), в*» (не равно), «<=» или «=<» (не больше),
«=^>» или «^>=» (не меньше);

пустое — пара из открывающей и закрывающей круглых скобок —
считается всегда истинным;

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

Если операнд условия повторяется на том же месте в последую-
щем простом условии, то можно использовать символ вместо повто-
рения операнда.

Конструкция составного IF служит для организации ветвлений
по ряду условий и включает четыре оператора следующего формата:

IF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
AF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
CF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
EF

Количество и порядок операторов AF и CF произвольны. Состав-
ной IF можно описать с помощью уже введенных конструкций язы-
ка МЭЛ:

IF	УСЛОВИЕ	ИСПОЛНЯЕМЫЕ  ОПЕРАТОРЫ	IF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕ- РАТОРЫ GO END EF
AF	УСЛОВИЕ	ИСПОЛНЯЕМЫЕ	IF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕ-
		ОПЕРАТОРЫ	РАТОРЫ GO END EF
CF	УСЛОВИЕ	ИСПОЛНЯЕМЫЕ	IF УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕ-
		ОПЕРАТОРЫ	РАТОРЫ EF
EF			END: ...

Условия операторов составного IF просматриваются последова-
тельно. В случае истинности текущего условия (при IF, AF или CF)
выполняются идущие следом операторы до очередного AF, CF или
EF. Иначе проверка условий продолжается. После исполняемых опе-
раторов при IF, AF управление передается в конец конструкции на
оператор, следующий за EF. В случае CF — после исполняемых опе-
раторов продолжаются проверки условий составного IF.

Оператор цикла может начинаться тремя различными способами:

RU ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ

RW УСЛОВИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ

RP АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ ИСПОЛНЯЕМЫЕ ОПЕРАТО-
РЫ

Оператор RU ставит служебную метку, которая указывает начало
цикла, после чего выполняется тело цикла.

Оператор RW ставит служебную метку начала цикла и проверяет
условие. Если оно истинно, то выполняется тело цикла.

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

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

Функционально операторы цикла эквивалентны последователь-
ностям действий:

RU ОПЕРАТОРЫ

RP АРИФМЕТИЧЕСКОЕ ВЫ-
РАЖЕНИЕ

RW УСЛОВИЕ ОПЕРАТОРЫ

АР УСЛОВИЕ ОПЕРАТОРЫ

SP УСЛОВИЕ ОПЕРАТОРЫ

СР УСЛОВИЕ ОПЕРАТОРЫ

ХР УСЛОВИЕ ОПЕРАТОРЫ

ЕР

BEGIN: ОПЕРАТОРЫ

X = АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ
RU

BEGIN: IF УСЛОВИЕ

ОПЕРАТОРЫ GO END

AF ( ) GO ALT1

EF

ALT/: IF УСЛОВИЕ

ОПЕРАТОРЫ GO END

AF ( ) GO ALT/' -f-1

EF

ALT/: IF УСЛОВИЕ

ОПЕРАТОРЫ GO BEGIN

AF( ) GO ALT/ -f- 1

EF

ALT/: IF УСЛОВИЕ ОПЕРАТОРЫ

AF( ) GO ALT/+1

EF

ALT/: IF УСЛОВИЕ

ОПЕРАТОРЫ GO EXIT

AF( ) GO ALT/ 4- 1

EF

END:

ПРОВЕРКА РАБОЧЕЙ

ЯЧЕЙКИ X

ALT/:

EXIT;
ЕР УСЛОВИЕ	END: IF «НЕ» УСЛОВИЕ GO EXIT EF

ПРОВЕРКА РАБОЧЕЙ

ЯЧЕЙКИ X

ALT/:

EXIT:

ПРОВЕРКА РАБОЧЕЙ ЯЧЕЙКИ X:

Х = Х-1 1F(X = O) GO EXIT EF GO BEGIN

Работа с подпрограммами и функциями включает обращения к
ним и возврат после их выполнения.

Вызов подпрограмм и функций имеет формат:

ИДЕНТИФИКАТОР (Р1, P.V)

Здесь ИДЕНТИФИКАТОР — название подпрограммы или функ-
ции; Р1, . . РА — список фактических параметров. Параметры
могут отсутствовать. Допустимо применение арифметических выра-
жений в качестве фактических параметров. Скобки при имени под-
программы или функции обязательны даже при отсутствии факти-
ческих параметров, в этом случае надо писать

ИДЕНТИФИКАТОР ( )

Вызов функции возможен только в арифметическом выражении.

Оператор возврата из подпрограмм и функций записывается в
виде

RT	— возврат из подпрограмм

RT АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ -- возврат из функций

Перед оператором EF в подпрограммах оператор RT необязате-
лен. В качестве значения функции в вызывающую программу пере-
дается значение арифметического выражения.

Операторы ввода—вывода ориентированы на работу с терминалом
пользователя. Получение твердых копий обеспечивается средствами
операционной системы.

Вывод осуществляется с помощью оператора WR, записываемого
следующим образом:

WR (UI U2 ... Uy) (ELI, EL2, ..., ELN)

Во вторых скобках стоит список выводимых элементов, для каж-
дого из которых в первых скобках указывается формат вывода U, с
помощью которого можно задавать печать соответственно целого чис-
ла (I), восьмеричного числа (К), числа в формате с плавающей точ-
кой (F), двух символов, хранящихся в слове (А), одного пробела
(X), текста, расположенного между кавычками («. . .»).

Специальными символами указываются: перевод строки (/), вклю-
чение подавления при выводе всех пробелов, кроме заданных в «. . .»
или спецификацией X (—), отмена подавления пробелов (+).

Запятая и пробел игнорируются.

Перед символами I, К, А, X, / может стоять число, означающее
коэффициент повторений данной спецификации.
Элементы списка могут иметь следующие форматы:

ИДЕНТИФИКАТОР

—	вывод соответствующей переменной или всего массива;

ИДЕНТИФИКАТОР (АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ-1, АРИФМЕ-
ТИЧЕСКОЕ ВЫРАЖЕНИЕ-2)

—	вывод элементов массива от элемента с номером, равным значе-
нию выражения-1, до элемента с номером, равным значению выра-
жения-2.

Допустимы также конструкции вида

ИДЕНТИФИКАТОР (:АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ)
и

ИДЕНТИФИКАТОР (АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ:)

эквивалентные соответственно конструкциям

ИДЕНТИФИКАТОР (^АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕ)
и

ИДЕНТИФИКАТОР (АРИФМЕТИЧЕСКОЕ ВЫРАЖЕНИЕМ)

Здесь N — размерность массива.

Формат вывода зациклен, т. е. если декодирован последний символ
формата, а список вывода не исчерпан, то формат опять начинает де-
кодироваться с первого символа.

Ввод осуществляется с помощью оператора RD, читающего ин-
формацию по свободному формату. Оператор записывается следую-
щим образом:

RD(EL1, EL2, ..., ELM)

Здесь ELI, . . ., ELA'' — список ввода, имеющий такую же фор-
му, как и список вывода в операторе вывода.

Формат ввода определяется по набираемому на клавиатуре зна-
чению очередного элемента:

если первый символ «@», то вводится восьмеричное число;

если вводятся только цифры, то они интерпретируются как целое
десятичное число;

если первым является символ двойные кавычки, то вводится тек-
стовое значение до «закрывающего» такого же символа;

ввод символа / означает, что последующие символы будут набраны
в новой строке.

Ввод каждого элемента списка заканчивается запятой или про-
белом. Если введено меньше значений, чем требуется в списке ввода,
то оставшиеся элементы не изменяются. Если пользователь наберет
на клавиатуре две запятые подряд, то соответствующий элемент спис-
ка ввода сохранит свое значение,
ОПЕРАТОРЫ ПРОГРАММИРОВАНИЯ

ПАРАЛЛЕЛЬНЫХ ПРОЦЕССОВ

Операторы ВТ, СТ, ЕТ позволяют инициировать параллельное вы-
полнение нескольких частей программы и имеют следующий формат:

ВТ (’ИМЯ ПРОЦЕССА-!’) ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ

СТ (’ИМЯ ПРОЦЕССА-А’) ИСПОЛНЯЕМЫЕ ОПЕРАТОРЫ
ЕТ

Имена процессов могут отсутствовать. Оператор ВТ отмечает
точку ветвления в программе и указывает начало одного из процес-
сов. Операторы СТ (их может быть несколько) разграничивают ос-
тальные параллельно исполняемые части программы. Операторы,
стоящие за ЕТ, начнут выполняться только после того, как завер-
шатся все инициированные процессы.

ДИРЕКТИВЫ УПРАВЛЕНИЯ РАБОТОЙ ТРАНСЛЯТОРА

Директива управления печатью листинга имеет вид:

LS RQ

На месте R может быть поставлено:

N — нет печати текста исходной программы;

S — есть печать исходной программы;

А — печать исходной программы и печать расширений транслируемых
операторов на языке Ассемблера.

На месте Q может быть указано:

N — нет печати дополнительной информации (дополнительная информация —
это перечень идентификаторов и признаков их использования);

S — печать дополнительной информации без адресов переменных, массивов
и меток, без служебных имен, без неиспользуемых COMMON переменных;

С — печать дополнительной информации без адресов, без служебных имен;

А — печать дополнительной информации с адресами (таблица распределения
памяти).

Стандартным значением и для В, и для Q является S.

Директивы управления режимом трансляции:

TR, AS — следом за строкой, содержащей этот текст, располагаются пред-
ложения языка Ассемблера (автокодная вставка);

TR ML, TR MLG — строки, которыми заканчивается текст на языке Ас-
семблера, если далее соответственно следует или не следует исполняемый опера-
тор языка МЭЛ;

TR SF, TR SM — все подпрограммы, для которых не оговорено специаль-
но, транслируются с соглашением о связях соответственно языка ФОРТРАН или
языка, МЭЛ;

TR RO — произвести разделение программы на изменяемую и неизменяе-
мую части.

РЕАЛИЗАЦИЯ

Транслятор с языка МЭЛ полностью написан на нем же, что облег-'
чает адаптацию к новым ЭВМ. Транслятор функционирует в рамках
дисковой операционной системы ЭВМ М-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-х годов характеризуется_возрастанием роли ннтерак-
тшщ1.ого.>_а.также_независимого (off-line) программирования. [1, 2].
Это обусловлено необходимостью сокращения трудоемкости ввода
данных о пространственном положении объектов в программу управ-
ления роботов и повышения их точности и эффективности процесса
программирования за счет использования языков высокого уровня,
средств моделирования робототехнических комплексов без привле-
чения реального оборудования. В экспериментальных системах за-
дачно-ориентированпого программирования (например, ACRONYM,
RAPT, LM-GEO, PLACE [ 1,4]) к тому же предпринимаются попытки
автоматического построения движения робота на основе методов ис-
кусственного интеллекта.

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

значительное повышение «интеллектуальности» системы, разви-
тие задачно-ориентированного программирования типа систем SMGR
[5], ARPAS, LM-GEO [3], ACRONYM;

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

При современном состоянии методов искусственного интеллекта
первое направление имеет главным образом теоретическое значение.

Одной из перспективных концепций второго направления явля-
ется графическое программирование.

В соответствии с этой концепцией пользователь может выполнять
все процедуры, связанные с моделированием среды функционирова-
ния робота, составлением и отладкой программы для конкретной тех-
нологической задачи, на уровне манипуляций с графическими обра-
зами, формируемыми средствами интерактивной машинной графики.
Конечной целью является замена традиционных методов программи-
рования роботов интерактивной работой с графическими образами в
системе с высоким уровнем сервиса. Известно, что графические образы
обрабатываются людьми более эффективно, чем алфавитно-цифровая
информация, и в наиболее современных системах средства графическо-
го диалога становятся частью среды выполнения программ (система
Symphony для ЭВМ IBM-PC, система Lisa) и языков программиро-
вания (таких, например, как SmaRtalk [61).

Рассмотрим построенную на основе графического подхода систе-
му автоматизации программирования роботов АПРОГРАФ [7].
Программирование в этой системе осуществляется в три этапа:
формирование графических образов, играющих роль геометриче-
ской модели объектов рабочего пространства или выполняющих
функцию его разметки;

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

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

Программное обеспечение АПРОГРАФ построено по модульному
принципу. Принята концепция расширяемого ядра: к системе могут
быть подключены новые модули, обеспечивающие в данной реализа-
ции существенное увеличение базовых возможностей. Структура си-
стемы представлена на рис. 1. В ядро входят база графических дан-
ных, процессор графических инструкций. Обязательными являются
также модули Графический редактор (формирующий графический
образ) и Интерпретатор (предназначенный для работы с програм-
мами на языке графического программирования). Специально выде-
лены дисплейно-зависимые модули, что позволяет легко адаптировать
АПРОГРАФ к различным типам графических устройств. Интерфейс
системы технического зрения используется при автоматизации соз-
дания графических образов, постпроцессор позволяет генерировать
программы на языке программирования роботов.

Первые версии системы АПРОГРАФ разработаны на языке ФОРТ-
РАН на ЭВМ Мусгоп, часть функций (в том числе и трехмерная гра-
240
фика) реализована на отечественной ЭВМ ДВК-2. Последующие реа-
лизации написаны на языке программирования «С», который машин-
но-независим, обладает возможностями реализации операций, обыч-
но программируемых на языке Ассемблера: адресная арифметика,
битовые операции, спецификация регистров и т. п. Язык «С» соот-
ветствует современным структурным требованиям, достаточно выра-
зителен, создает коды, эффективные как с точки зрения экономии
памяти, так и по быстродействию.

Организация графических данных. Описание графических обра-
зов в системе имеет многоуровневую структуру.

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

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

Для работы с крупными фрагментами контурной цепи как с еди-
ным целым введено понятие графического объекта, идентифицируе-
мого уникальным именем и задаваемого индексами своих начальной
и конечной точек в контурной цепи. Объекты имеют следующие атри-
буты: ориентация, координаты первой вершины (начала) объекта,
число вершин.

В системе АПРОГРАФ принято представление объемных изобра-
жений сеткой многоугольников, но допускается возможность введе-
ния и более сложных пространственных примитивов (цилиндр, сфе-
ра и т. п.). Атрибутами элемента, описывающего вершину сетки, яв-
ляются координаты и тип связи с предыдущей вершиной. Однако
в отличие от двумерного случая имеется несколько контурных цепей
и вводится понятие грани. Она представляет собой совокупность свя-
занных элементов, лежащих в одной плоскости, и может обладать ат-
рибутами (цвет, прозрачность). Объектам в трехмерном варианте
приписываются атрибуты: ориентация и координаты первой верши-
ны. Имеется возможность создавать иерархически организованные
группы объектов.

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

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

Приведем список базовых инструкций процессора, разделенных
на группы по уровню используемых графических данных (в скобках
указаны допустимые мнемонические имена инструкций):
инструкции работы с элементами:

создание графических примитивов (линии (SET-LINE, L),
точки (SET-POINT, Р), в двумерном варианте — дуги (SET-
ARC, С), окружности (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;

выполнение произвольной части программы с возможностью его
прерывания по требованию оператора.

Модуль Интерпретатор может работать в одном из двух режимов:
ввод директив или команд и выполнение программы. В первом осу-
ществляется ввод с клавиатуры терминала текста директивы или
команды, при этом директива немедленно выполняется, а команда
выполняется и/или включается в текст программы в зависимости от
ответа оператора на соответствующий запрос. Во втором режиме
команды последовательно выбираются из текста графической прог-
раммы и выполняются. В любой момент выполнение программы мо-
жет быть прервано оператором (при этом Интерпретатор переходит
в режим ввода директив) и затем продолжено по директиве CONT.

Формирование графических образов с помощью системы техни-
ческого зрения. Применение системы технического зрения при под-
готовке графических данных в системе АПРОГРАФ имеет своей
целью упростить процедуру формирования графических образов,
необходимых для программирования роботов, в случае, когда ис-
точником информации о форме и взаимном расположении объектов
может (или должна) быть сама рабочая среда. Имеется два варианта
использования системы технического зрения совместно с модулем
Графический редактор для подготовки графических данных. В мо-
ниторном режиме формируемое системой технического зрения изо-
бражение выводится на экран графического дисплея в качестве фона,
на котором пользователь создает контурные изображения требуемых
объектов. Контурный режим использования системы технического
зрения реализуется путем загрузки непосредственно в рабочий бу-
фер «Графического редактора» описаний контуров областей сегмен-
тированного изображения, приведенных к формату контурных це-
пей графических объектов модулем Интерфейс системы технического
зрения.

Синтез траекторий движения робота. В качестве примера исполь-
зования системы АПРОГРАФ рассмотрим разработанную систему
синтеза траекторий движения сборочного робота, кинематическая
схема которого представлена на рис. 2. Робот имеет шесть степеней
свободы. Углы в шарнирах обозначены соответственно 017 . . ., 0в.

На рис. 3 представлено контурное изображение этого робота, соз-
данное в системе АПРОГРАФ.

Синтез траекторий осуществляется поэтапно:

1)	задание графической модели сборочного поля, робота, а также
кинематики робота;

2)	интерактивный синтез опорных точек траекторий;

3)	построение траектории и вычисление координат подвижных
сочленений робота;

4)	визуализация движений робота.

Этапы 1, 2 и 4 реализуются средствами языка графического прог-
раммирования GBASIC. Для построения траектории робота необ-
ходимо включить в систему модули, рещающие обратную задачу ки-
нематики для моделируемого робота. В данной системе преобразо-
вание характеристик положения и движения захватного устройства
в координаты шарниров робота основано на методе аналитического
обращения матрицы Якоби [8].

Пусть S — вектор состояния (положения) захватного устрой-
ства, тогда состояние и скорость движения захватного устройства
можно описать соответственно уравнениями

s	= f(0!, во),	. ;

S = J (0) 0,

где J(0) = kz- — матрица Якоби.
Рис. 3. Контурное изображение робота, созданное в системе АПРОГРАФ

Траектория разбивается на малые отрезки, осуществляется пере-
ход от дифференциалов к линейным приращениям, и полученная си-
стема разрешается относительно Д0г. Сформированные данные пере-
даются программе на языке GBASIC, которая визуализирует полу-
ченное решение для данного отрезка траектории.

Известно, что разработка программы для сборочного робота тра-
диционным способом может иметь трудоемкость в несколько челове-
ко-месяцев и требует высокой квалификации программиста. Исполь-
зование графических моделей в системе АПРОГРАФ упрощает про-
цесс разработки программ и резко снижает трудоемкость отладки
за счет использования визуального контроля правильности каждо-
го действия моделируемого робота.

ЛИТЕРАТУРА

1.	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.

2.	Логинов А. И. Система автоматизации программирования сборочных про-
мышленных роботов.— В кн.: Методы расчета гибких автоматизированных
производств. М.: МИФИ, 1984, с. 363—399.

3.	Mazer Е. LM-GEO, Geometric Programming of Assembly robots.— In:
Advanced Software in robotics. Amsterdam: North-Holland, 1984, p. 214—
221 •

4.	Якович H. Программные средства моделирования, упрощающие построение
- рабочих мест с роботами.— Электроника, 1983, т. 56, № 20, с. 48—53.

5.	Pertin-Groccaz J. S. М. G. R.— A Geometric and Relational Modeller for
Robotic Applications.— In: Proc. Intern. Conf. Adv. Robot. 9—10 sept.
1985, Tokyo (Japan). Tokyo, 1985, p. 23—31.
6.	BYTE, Special Issue ou Smalltalk, 1981, vol. 6,' N 8. 480 p.

. 7. Переслени С. А., Рахманкулов В. 3. Система графического программирова-
ния для робототехнических комплексов.— В кн.: III Всесоюз. конф. «Робо-
ты и робототехнические системы», Челябинск, 1983: Тез. докл. Челябинск:
Челяб. политехи, ин-т, 1983, т. 2, с. 130—131.

8. Верещагин А. Ф., Минаев Л. И. Принципы построения специализированных
вычислителей для позиционного супервизорного управления манипуляцион-
ным роботом,— Изв. АН СССР. Техн, кибернетика, 1978, № 4, с. 56—65.

УДК 681.32

АЛГОРИТМИЧЕСКОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
ПРОБЛЕМНО-ОРИЕНТИРОВАННОЙ ДИАЛОГОВОЙ
СИСТЕМЫ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ
ИНТЕГРИРОВАННЫХ ПРОИЗВОДСТВЕННЫХ
КОМПЛЕКСОВ МЕХАНИЧЕСКОЙ ОБРАБОТКИ

В. II. Войтов, С. П. Кузьмин, М. И. Ремизов,

Т. В. Уханова



























Проблемно-ориентированная диалоговая система имитационного мо-
делирования интегрированных производственных комплексов (ИПК)
предназначена для решения задач системного анализа и выбора па-
раметров организационно-технологической структуры, исследования
алгоритмов оперативно-календарного планирования и управления,
а также других задач, возникающих на различных этапах исследо-
вания, проектирования, реорганизации, технологической подготов-
ки и функционирования гибкого автоматизированного производства
[1].

ФОРМАЛИЗАЦИЯ ФУНКЦИОНИРОВАНИЯ ИИК
(на примере ИПК механообработки)

Работу ИПК механообработки формально можно рассматривать как
функционирование сложной иерархической системы массового обслу-
живания, или так называемой (Ксхемы [2]. Пример графического
изображения (/-схемы ИПК некоторой типовой структуры представ-
лен на рис. 1.

Основными элементами (Г схемы являются потоки событий, по-
токи заявок на обслуживание и приборы обслуживания, состоящие
из каналов обслуживания и накопителей.

Поток событий представляет собой последовательность событий,
происходящих* в некоторые, вообще говоря, случайные моменты
времени. Кроме моментов наступления событий, каждое из них мо-
жет характеризоваться набором признаков события (неоднородные
события).

При моделировании ИПК в качестве основных событий целесо-
образно выделить:
поступление в ИПК и выход из него транспортной партии дета-
лей;

начало и окончание штабелирования транспортной партии дета-
лей;

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

начало и окончание обработки транспортной партии деталей на
одной из групп основного оборудования;

поломка (отказ) штабелера, тележки (транспортного робота) или
основного оборудования;

начало и окончание ремонта (восстановления) штабелера, тележ-
ки или основного оборудования;

начало и окончание наладки основного оборудования.

С учетом приведенных событий в (?-схеме ИПК возможны сле-
дующие виды потоков событий:

поток поступлений транспортных партий деталей в ИПК;

поток окончаний штабелирования транспортных партий деталей;

поток окончаний обработки транспортных партий на оборудова-
нии;

потоки отказов штабелера, тележки и основного оборудования;

потоки восстановления (окончания ремонта) штабелера, тележки
и основного оборудования;

поток окончаний переналадки основного оборудования.

Потоки событий в (2-схеме ИПК порождают, в свою очередь,
потоки заявок на обслуживание (на штабелирование, транспорти-
ровку, обработку, наладку основного оборудования и ремонт шта-
белера, тележки и основного оборудования).

Некоторые виды потоков событий являются в то же время пото-
ками обслуженных заявок.

Обслуживание заявок в (2-схеме осуществляется каналами об-
служивания пяти видов:

основным технологическим оборудованием;

транспортным оборудованием центрального склада (штабелером);

межоперационным транспортным оборудованием (транспортными
роботами или тележкой);

наладчиками основного оборудования;

ремонтниками оборудования.-

В рассматриваемой (2-схеме как модели ИПК некоторого уровня
циркулируют три типа заявок на обслуживание:

собственно заявки-детали (транспортные партии);

заявки-запросы, сопровождающие обслуживание заявок-деталей;
заявки-запросы от приборов (каналов) обслуживания.

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

К заявкам второго типа относятся информационные запросы
на:

штабелирование деталей в пределах центрального склада;

транспортировку деталей между центральным складом и проме-
жуточными накопителями в соответствии с маршрутной технологией.
Рис. 1. Модель функционирования ИПК механообработки в виде Q-схемы

Ш Т, О, Н, Р — каналы штабелера, тележки, основного оборудования, наладчиков и ре-
монтников соответственно; Днш, Днт> Дно, Днн, Днр — диспетчеры накопителей соответ-

> ствующих каналов обслуживания

9 Заказ № 2408
Заявками третьего типа являются информационные запросы на:
восстановление штабелера, тележки и основного оборудования;
наладку основного оборудования.

Потоки заявок на обслуживание в силу нерегулярности порож-
дающих их событий, а также ограниченной пропускной способности
каналов обслуживания приводят к образованию очередей заявок,
для хранения которых используются накопители двух типов:

списки заявок-запросов на обслуживание тем или иным каналом;

списки заявок-деталей, отображающие физические накопители
транспортных партий.

Накопители первого типа имеются в следующих приборах об-
служивания: штабелера, тележки, ремонтников и наладчиков.

Ко второму типу относятся накопители, соответствующие цент-
ральному складу и промежуточным накопителям реального ИПК.

Процесс функционирования (?-схемы ИПК состоит в диспетчи-
ровании заявок в накопителях и блокировке каналов и накопите-
лей.

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

Блокировка каналов и накопителей соответствует реакции сис-
темы управления на различные ситуации, возникающие в ИПК,
и возможна как на входе, так и на выходе.

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

Блокировка выхода канала означает, что обслуженная им заявка
по тем или иным причинам не может его покинуть, и приводит к
одновременной блокировке его входа. На выходе могут быть бло-
кированы каналы штабелера и тележки.

Блокировка входа накопителя означает невозможность поступ-
ления заявок вследствие его полной занятости. В (J-схеме ИПК бло-
кированными на входе могуи быть накопители центрального
склада и накопитель основного оборудования, т. е. те накопители,
которым соответствуют накопители заявок-деталей.

В общем случае (J-схема ИПК многофазная, многоканальная,
комбинированная (в том смысле, что включает как сквозные потоки
заявок, так и потоки заявок, движущихся по обратным связям),
с потоками неоднородных событий, с ограниченными и неограни
ченными очередями, приоритетная и с ненадежными обслуживаю-
щими приборами^ восстановлением).

С формальной точки зрения (?-схему различной сложности в^об-
щем случае можно однозначно задать в виде

Q = <W, U, Н, Z, R, Л>,

где W — множество потоков заявок на обслуживание; U — мно-
жество потоков обслуживаний; Н — множество собственных пара-
метров структуры (/-схемы; R — оператор сопряжения, отражаю-
щий взаимосвязь элементов структуры (7-схемы между собой (т. е.
связи, по которым осуществляется прохождение заявок); Z — мно-
жество возможных состояний собственных элементов (7-схемы; А —
оператор возможных алгоритмов поведения заявок в (7-схеме.

Множество W определяет режимы поступления заготовок в сис-
тему во времени и по количеству (партионность и периодичность
запуска деталей в обработку), а множество U — распределение
продолжительностей процессов обслуживания (например, станко-
емкости операций, временных затрат на наладку, ремонт, транспор-
тировку и штабелирование).

Применительно к ИПК как объекту моделирования выбранного
уровня рассмотрения параметры (7-схемы можно, в свою очередь,
конкретизировать следующим образом:

Н = <L, К, N, Е>,

Z = <Z* Z*>,

Д = ВоК, BN, Dn, Dk, М),

где L — количество фаз приборов обслуживания в (7-схеме; К —
вектор, определяющий количество каналов обслуживания по фазам;
N — вектор, определяющий количество накопителей по фазам; Е —
матрица, определяющая емкости накопителей в каждой фазе об-
служивания; ZK, ZN — множество возможных состояний соответст-
венно каналов обслуживания (например, свободен, занят произво-
дительно или непроизводительно и т. д.) и накопителей (в смысле
возможной заполненности); В%, Bq, BN — правила (алгоритмы)
блокировки соответственно каналов обслуживания на входе и вы-
ходе и накопителей (имеет смысл рассматривать блокировку только
входа накопителей); DN, DK — диспетчирующие правила соответст-
венно поступления заявок в накопители и выбора заявок из нако-
пителей на обслуживание в канале; М — множество возможных
маршрутов прохождения заявок по фазам (приборам) обслуживания.

ФУНКЦИОНАЛЬНО-АЛГОРИТМИЧЕСКАЯ СТРУКТУРА
ПРОБЛЕМНО-ОРИЕНТИРОВАННОЙ ДИАЛОГОВОЙ СИСТЕМЫ
ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ ИПК

Реализованная на базе системы имитационного моделирования на
ФОРТРАНЕ (СИМФОР) [3] проблемно-ориентированная диалоговая
система имитационного моделирования ИПК может функциониро-
вать под управлением операционной системы разделения функций

(РАФОС) на управляющих вычислительных комплексах типа СМ-4,
«Электроника-100/25», СМ-1420, «Электроника-79», имеющих не ме-
нее 128К байт оперативной памяти.

Процесс создания требуемого варианта имитационной модели
в проблемно-ориентированной диалоговой системе имитационного
моделирования ИПК включает в себя генерацию в интерактивном
режиме текстов СИМФОР и специального проблемно-ориентирован-
ного программного обеспечения.

Укрупненная схема моделирующего алгоритма имитационной
модели ИПК. механообработки приведена на рис. 2.

Функциональная структура проблемно-ориентированной диало-
говой системы имитационного моделирования ИПК включает три
взаимодействующих между собой компонента:

пакет моделирующих программ;

программный генератор моделей;

информационная подсистема.

Пакет моделирующих программ представляет собой набор про-
граммных модулей, написанных на языке ФОРТРАН и реализую-
щих различные функции, необходимые для моделирования ИПК
как производственно-технологического объекта.

В состав пакета моделирующих программ входят как специаль-
ные модули, реализующие проблемную ориентацию системы имита-
ционного моделирования, так и стандартные модули СИМФОР,
обеспечивающие моделирование дискретных процессов (дискретный
вариант СИМФОР).

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

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

В состав пакета моделирующих программ входят управляющие,
функциональные и вспомогательные подпрограммы.

Управляющие подпрограммы, предназначенные для управления
процессом моделирования, осуществляют взаимодействие специаль-
ных подпрограмм и подпрограмм СИМФОР и реализуют следующие
возможности:

программное управление процессом моделирования на основе
анализа и ведения модельного времени (STEXR);

интерактивный контроль за процессом моделирования (STSUP);

интерактивное вмешательство в процесс моделирования: просмотр
состояния объектов, вывод накопленных статистик, изменение зна-
чений объектов и т. д. (STMIN);

распознавание модельных событий и вызов соответствующих под-
программ, реализующих эти события (EVNTS);

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

поступление партии деталей в ИПК (ARRL),

окончание выполнения технологической операции над тран-
спортной партией деталей на основном оборудовании (FPROC),
окончание транспортировки передаточной партии деталей по-

средством тележки (FRROC1),

окончание штабелирования передаточной партии деталей

(FPROC2),

окончание переналадки основного оборудования (FSETP),
выход транспортной партии готовых деталей из ИПК (OUTSM),
отказ основного оборудования (REFUS),

окончание восстановления основного оборудования (REVIV),

отказ тележки (REFUS1),

окончание восстановления тележки (REVIV1),

отказ штабелера (REFUS2),

окончание восстановления штабелера (REVIV2),

условное окончание моделирования и расчет необходимого
количества наблюдений для получения статистически значимых
результатов (SAMPL);

реализация процессов, сопровождающих события:

загрузка оборудования и определение момента окончания об-
работки партии деталей или отказа основного оборудования
(LDER2),

загрузка тележки и определение момента окончания тран-
спортировки партии деталей или отказа тележки (LDER4);

загрузка штабелера и определение момента окончания шта-
белирования транспортной партии деталей или отказа штабе-
лера (LDER5),

переналадка оборудования и определение момента окончания
переналадки (SETUP),

считывание информации из файлов исходных данных или
генерация маршрутной технологии для поступления в ИПК
транспортных партий деталей (GNTEN),

генерация пооперационных трудоемкостей обработки партий
деталей (GNOPT),

планирование наступления событий через заданный или вы-
численный промежуток времени (DELAY);

расчет приоритетов заявок на обслуживание и диспетчирование
загрузки обслуживающих средств:

расчет статического приоритета для выбора партии деталей
из очереди на загрузку (PRIRS),

расчет динамического приоритета для выбора партии из оче-
реди на загрузку (PRIRD),

выбор партии деталей из очереди на обработку в соответст-

вии с заданным правилом диспетчирования (LDER1),
выбор партии деталей из очереди на транспортировку в соот-
ветствии с правилом диспетчирования загрузки транспортного
устройства (LDER3).
В состав вспомогательных подпрограмм входят как специальные
модули, так и стандартные модули СИМФОР, осуществляющие сле-
дующие функции:

инициализация переменных и массивов модели;

сбор информации для статической обработки и построения гра-
фиков и гистограмм;

вывод результатов моделирования;

организация работы со списками (очередями) модели.

Кроме того, в состав вспомогательных подпрограмм входят слу-
жебные подпрограммы.

Подпрограммы инициализации выполняют:

вызов специальных подпрограмм инициализации (USINT);

диалоговую коррекцию значений параметров транспортно-на-
копительной системы (USI1);

считывание исходных данных из файлов оборудования и ини-
циализацию рабочих массивов модели по оборудованию (USI2);
диалоговое задание значений параметров переналадок и па-
раметров входного потока деталей-заявок и потока их обслужи-
вания, а также инициализацию массивов сбора статистик и
вспомогательных массивов и переменных (USI3);

инициализацию массивов и переменных СИМФОР до начала
каждой реализации (STDAT);

восстановление начальных состояний постоянных объектов
модели (RETIM);

Подпрограммы сбора информации осуществляют:

сбор статистик по основному и транспортному оборудованию,
величине незавершенного производства (TIMOD);

передачу данных по характеристикам прохождения заявок-
деталей через систему для сбора статистик (FSTAT), в том числе
стоимостных (FSTAT1);

сбор статистик по характеристикам прохождения заявок-де-
талей через систему (CCCOL) и по характеристикам использова-
ния основного и транспортного оборудования (CCTIM);

сбор статистик для построения гистограмм (CCHIS) и гра-
фиков (CCGPL).

Подпрограммы вывода результатов моделирования реализуют:
вызов специальных подпрограмм вывода результатов (USOUT);
вывод исходной информации по оборудованию и номенкла-
туре обрабатываемых деталей (USO1) и исходных значений пара-
метров имитационной модели (USO2);

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

вывод результатов моделирования в графической и таблич-
ной форме (PRGPL).

Подпрограммы работы со списками (все они являются подпро-
граммами СИМФОР) выполняют:

копирование информации, характеризующей заявку, из спис-
ка в рабочий массив (FCOPY);

занесение записи в указанный список (FILEM) и ее извле-
чение (RMOVE) .
Служебные специальные подпрограммы осуществляют:
поиск для группы оборудования транспортной партии дета-
лей, претендующей на обработку (NFRES);

создание на основе исходной планово-технологической инфор-
мации гистограммы периодичности поступления передаточных
партий в ИПК и вычисление среднего времени между поступле-
ниями партий заготовок в ИПК (TRANS);

идентификацию деталей, поступающих в ИПК (HIST);

определение номера партии деталей и группы оборудования,
на котором она прошла обработку (NATR);

расчет суммарного критерия затрат (OUTGRT).

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

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

Кроме того, программный генератор моделей позволяет полу-
чать программные реализации имитационных моделей, эффективные
с точки зрения быстродействия и допустимой размерности, что
достигается за счет:

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

генерации наиболее эффективных текстов подпрограмм с точки
зрения состава входящих в них блоков (т. е. функционально или
логически законченных частей текста подпрограммы в виде набора
операторов на ФОРТРАНе);

наиболее эффективного использования оперативной памяти ЭВМ.

Функциональная схема программного генератора моделей пред-
ставлена на рис. 3.

Информационная подсистема представляет собой программу, пред-
назначенную для автономного от процесса моделирования создания
и коррекции двух хранящихся в виде файлов прямого доступа
исходных информационных массивов:

планово-технологической информации;

организационно-технологической структуры.

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

Каждая группа оборудования описывается в массиве организа-
ционно-технологической структуры следующими параметрами: на-
256 •
Рис. 3. Функциональная] схема программного генератора] моделей проблемно-ориентирован-
ной диалоговой системы имитационного моделирования

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

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

ЛИТЕРАТУРА

1.	Войтов В. Я., Ремизов М. И., Уханова Т. В. Диалоговая система имита-
ционного моделирования процессов функционирования автоматизированных
технологических комплексов.— В кн.: Математическое, информационное и
программное обеспечение систем управления промышленных роботов и
ГАП. М.: МДНТП, 1984, с. 54-59.

2.	Советов Б. Я., Яковлев С. А. Моделирование систем. М.: Высш. шк. 1985.
272 с.

3.	Операционная система СМ ЭВМ РАФОС: Справочник/Л. И. Валикова,
Г. В. Вигдорчик, А. Ю. Воробьев, А. А. Лунин. М.: Финансы и статистика,
1984. 207 с.
УДК 519.682:621.868.8

СТАНДАРТИЗАЦИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ
В РОБОТОТЕХНИКЕ

Н. Е. Богомолов, Ю. М. Лазутин, В. С. Ярошевский

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

Для эффективной модифицируемости программ, снижения стои-
мости их разработки желательны стандартизация используемых в
робототехнических задачах языков программирования, определение

Рис. 1» Классификация языков программирования роботов
предъявляемых к ним требований. Это позволит разработчику про-
граммно-математических средств более точно сформулировать стоящие
перед ним проблемы, будет способствовать использованию уже раз-
работанных программных модулей, их унификации.

В настоящее время утвержден стандарт по языкам программи-
рования роботов [1], в котором учтены замечания, высказанные
при обсуждении временных технических условий ГОСТ 26064-83
«Роботы промышленные. Устройства программного управления. Язы-
ки программирования и кодирования информации».

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

Классификация языков программирования роботов начинается
с разделения их на два класса: инструментальные языки програм-
мирования и языки аналитического программирования (рис. 1). Ин-
струментальный язык программирования предназначен для:

разработки и отладки алгоритмов;

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

написания операционных систем реального времени;

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

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

В качестве предпочтительных управляющих и инструменталь-
ных ЭВМ выбраны 16-разрядные мини- и микро-ЭВМ типа «Электро-
ника-60», СМ-2,-4, М-6000. Этот выбор обусловлен тем, что:

машины данного класса наиболее распространены и доступны;

с помощью 16-разрядных слов могут быть организованы числен-
ные расчеты, точность которых достаточна в большинстве случаев
для нужд робототехники;

16-разрядное слово хорошо соответствует разрядности датчиков,
существующих в настоящее время и используемых для сбора ин-
формации о внешней среде;

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

Необходимо отметить, что предложенный ГОСТ не запрещает
разрабатывать устройства управления на базе ЭВМ с иной архи-
тектурой. На более мощной ЭВМ может быть установлена расши-
ренная версия программно-математического обеспечения. При этом,
однако, должна обеспечиваться преемственность версий. Выполне-
ние указанных условий способствует достижению портативности
программных продуктов.

Инструментальные языки делятся на четыре подкласса по
двум независимым критериям.

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

Вторым критерием классификации является ориентированность
языка на задачи робототехники.

В каждом из введенных четырех подклассов инструментальных
языков выделяют три уровня:

язык Ассемблера,

макроязыки,
языки с собственным синтаксисом.

Уровень языка определяет производительность программирова-
ния на нем. Как показывают проводившиеся исследования, число
операторов, отлаженных в день квалифицированным программис-
том, является величиной приблизительно постоянной независимо
от уровня языка [2]. Объем же текста программы, необходимый
для решения данной задачи, с переходом на язык высокого уровня
уменьшается.

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

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

Для достижения максимальной эффективности на «критических»
участках разрабатываемых программ инструментальный язык должен
предоставлять средства записи части текста программы на языке
Ассемблера данной ЭВМ, что позволяет сохранить достоинства язы-
ков высокого уровня и обеспечить выполнение заданных требова-
ний к программе на критических участках по быстродействию, объе-
му памяти и т. д. Кроме того, такие «автокодные вставки» дают
возможность реализовывать функции, не предусмотренные в языке
программирования, но реализуемые системой команд управляющей
ЭВМ.

Стандарт предъявляет требования к инструментальным языкам
программирования, хотя они и не обладают особенностями, при-
сущими исключительно программному обеспечению систем управ-
ления промышленными роботами, а могут использоваться для ре-
шения более широкого спектра задач. Однако инструментальные
языки являются теми средствами, которые подготавливают про-
граммно-операционную среду и от правильного выбора которых за-
висят и эффективность, и качество работы программиста. Поэтому
в стандарте предъявляются требования к программным изделиям
и документам, реализованным на таких языках программирования,
как, например, ФОРТРАН.

При классификации языков аналитического программирования
в соответствии с уровнями описания управляющей программы уст-
ройства программного управления промышленного робота выделяют:

нижний уровень — язык описания управляющей программы, на
котором непосредственно программируют требуемые действия робо-
та, перемещения его степеней подвижности, операции по сбору ин-
формации о внешней среде и собственно состоянии;

следующий уровень — язык описания работы (движения про-
мышленного робота и контрольные операции), на котором возможно
введение «обобщенных» операций (под ними понимаются именован-
ные совокупности действий), к которым можно обращаться по имени;

е
Рис. 2. Конфигурации средств программирования промышленного робота

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

Более подробно иерархия средств программирования промыш-
ленных роботов представлена на рис. 1.

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

Классификация языков аналитического программирования, дан-
ная в стандарте, проведена по возрастанию сложности, соответст-
вует различным уровням подробности описания функционирования
промышленного робота, общности и привязки к конкретному обо-
рудованию. Каждому уровню сопоставляется определенный этап
разработки управляющего программного комплекса. Таким обра-
зом, с реализацией языка аналитического программирования оче-
редного уровня будет формализован и автоматизирован соответст-
вующий этап разработки управляющей программы.

Стандарт требует использовать принципы модульного и струк-
турного программирования, которые обеспечивают возможность раз-
работки программного продукта коллективом программистов, лег-
кую модификацию программ при сопровождении, надежное тести-
рование [31.

Остается открытым ряд важных вопросов, в частности:
отсутствие хороших критериев оценки эффективности трансля-
тора, надежности получаемых программ;

в связи с тем, что разные версии трансляторов могут генериро-
вать различный объем кода, не разработаны параметры измерения
скорости трансляции;

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

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

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

ЛИТЕРАТУРА

1.	Промышленные роботы. Устройства программного управления. Языки
программирования и кодирования информации. Основные положения:
ГОСТ 26085-84.

2.	Шнейдерман Б. Психология программирования.: Пер. с англ. М.: Радио и
связь, 1984. 303 с.

3.	Дингер Р., Миллс X., Уитт Б. Теория и практика структурного програм-
мирования.: Пер. с англ. М.: Мир, 1982. 406 с.
ПРИЛОЖЕНИЕ

РЕКОМЕНДАЦИИ ДЛЯ РАЗРАБОТЧИКОВ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ
И ГИБКИХ АВТОМАТИЗИРОВАННЫХ ПРОИЗВОДСТВ *

Рабочая группа по программному обеспечению Научного совета по проб-
леме «Робототехника и автоматизированное производство» при Отделении меха-
ники и процессов управления АН СССР выработала ряд рекомендаций в области
программного обеспечения роботов и гибких производственных систем (ГПС).
Для широкой аудитории представляют интерес материалы по проблемам на-
дежности программно-аппаратных средств робототехнических комплексов (РТК)
и ГПС, требования к архитектуре и составу оборудования устройств управ-
ления со стороны программного обеспечения и описания архитектуры программ-
ного обеспечения локальных сетей для ГПС.

Критерии и программно-аппаратные средства
обеспечения надежности робототехнических систем,
станков с ЧПУ и ГПС

Основные показатели надежности	'_

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

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

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

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

* Рекомендации были обсуждены на заседании Рабочей группы по программному
обеспечению Научного совета по проблеме «Робототехника и автоматизированное
производство» при Отделении механики и процессов управления АН СССР
27 ноября 1985 г. Материал подготовлен к печати Р. К. Казаковой.
I

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

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

Такой критерий может быть определен в процессе испытания каждого образ-
уй ца оборудования и программного обеспечения по соответствующим методикам.

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

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

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

Аппаратура	Программное обеспечение

наличие логических ошибок в проекте или его несовершенство
ошибки изготовления	неправильное кодирование

внутренняя ненадежность	несовершенство отладки

компонентов

временный износ	рост неопределенности программ

вследствие внесения изменений

Программно-аппаратные средства обеспечения надежности

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

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

Гибкость по отказам в РТК и ГПС

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

Предсказуемость поведения при п-кратпых отказах должна считаться
важнейшей характеристикой надежности программного обеспечения. Пред-
сказуемость поведения зависит от предположений о надежности программных
и аппаратных элементов, алгоритмов диагностики неисправностей и алгорит-
мов перестройки в случае обнаружения отказа. Только при определенных пред-
положениях о характере ошибок можно требовать создания таких алгоритмов
диагностики и (или) перестройки программного обеспечения.

Необходимые мероприятия

В качестве необходимых мероприятий для обеспечения надежности можно ре-
комендовать разработать:

систему мероприятий по организации экспертизы проектов РТК и
ГПС и совместного проектирования программных и аппаратных средств;

специальную элементную базу (в том числе датчики состояний);

ГОСТы и методики проведения испытаний с целью уточнения основ-
ных критериев надежности оборудования и программного обеспечения;

математическую модель надежности ГПС, учитывающую надежность
аппаратных, программных, механических и человеческих компонентов ГПС.

Требования

к разработчикам перспективных систем УЧПУ

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

Для надежной работы оборудования в программном обеспечении и в аппаратной
защите системы от ошибок программ и оператора в УЧПУ должны содержаться
средства, обеспечивающие:

программное отключение силового электропитания объекта управле-
ния;

формирование . сигналов готовности и/или неисправности оборудова-
ния;

подтверждение правильности работы программы и ЭВМ, дополненное
средствами прекращения работы системы при отсутствии такого подтверж-
дения;

защиту памяти и процессоров от кратковременных выключений элек-
тропитания;

программный доступ к средствам защиты от несанкционированного
обращения к памяти, процессорам и другим элементам оборудования си-
стемы.

Для облегчения отладки и развития программного обеспечения конструк-
ция УЧПУ должна обеспечивать возможность:

подключения инструментальной ЭВМ с расширенным составом тер-
миналов и внешней памятью на магнитных дисках (такая ЭВМ должна
входить в комплект разрабатываемых средств УЧПУ);

аппаратного прерывания процессора при обращении к заданной груп-
пе ячеек памяти и/или при выполнении команд из заданной области па-
мяти;

аппаратной поддержки трассирования работы программы;

использования переносного пульта для управления работой УЧПУ
в процессе отладки технологического процесса.

Для расширения областей использования УЧПУ необходимо обеспечить
возможность:

опроса аналоговых, импульсных, кодовых, фазовых и других типов
датчиков (путем замены функциональных плат);

непосредственного управления (минуя следящий привод нижнего
уровня) двигателями системы;

связи УЧПУ по последовательному и параллельному каналам с дру-
гими ЭВМ;

наращивания при. необходимости числа координат системы;

наращивания числа процессоров системы и комплексирования их
в многомашинные и мультипроцессорные комплексы;

наращивания оперативной памяти и замены ее на ППЗУ после завер-
шения отладки программного обеспечения системы;

накопления информации о суммарном времени работы УЧПУ с ука-
занием числа включений, сбоев и времени работы в автоматическом режиме;

измерения интервалов времени с дискретностью порядка 1 мс (с помо-
щью программно доступных часов и таймера).

Замечание. Аппаратные средства должны позволять осуществлять
опрос конфигурации оборудования на системном уровне программного обеспе-
чения.
Требования к операционной системе УЧПУ

Для снижения накладных расходов операционной системы (ОС) путем учета
конкретных свойств оборудования при ее разработке необходимо предусмотреть
возможность:

прямого обращения к внешним устройствам (минуя директивы ОС);
изменения пользователем драйверов внешних устройств;

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

доступа пользователя к сигналам неисправности оборудования на'уров-
не ОС и ее внутренним регистрам и таблицам.

Для обеспечения эффективной разработки’прикладного и базового программ-
ного обеспечения в цеховых условиях в ОС должны быть обеспечены:
реакция на сигналы неисправности оборудования;

сохранение файлов при частичном повреждении носителей инфор-
мации;

адаптация к неисправностям оборудования и носителей информации;
телекоммуникационное управление УЧПУ;

удаленная загрузка и выгрузка содержимого ОЗУ;

запись и чтение файлов памяти УЧПУ;

удаленный запуск задач.

Архитектура

и программное обеспечение локальных сетей для ГПС

При проектировании локальных сетей ЭВМ для ГПС целесообразно принять
во внимание следующее.

1.	Физический канал («среда передачи данных») влияет на программное
обеспечение локальной сети через характеристики задержек в канале и надеж-
ности канала.

Для локальных сетей ГПС гарантируемое быстродействие канала с учетом
программно-аппаратного обеспечения передачи данных должно составлять
(бит/с):

для организации диалога с оператором	1200

для организации режима DNC между удаленными ЭВМ и
устройством управления технологическим оборудованием (1,2-т-5-103) К

для связи ЭВМ в многомашинной распределенной системе
управления	(5-ь20)-103К

Наиболее надежный алгоритм контроля правильности передачи данных
определяется составом оборудования и соответствующим ему протоколом об-
мена. Перспективным для ГПС в пределах цеха является протокол IEEE 802. 4.
Желательно иметь аппаратную реализацию не менее трех уровней этого про-
токола.

2.	Архитектура сложной локальной сети ГПС должна предусматривать
включение в ее состав специальных устройств или программ («шлюзов») для
объединения разнотипных ЭВМ, имеющих различные протоколы обмена и воз-
можность выделения подсетей со специализированным функциональным на-
значением.

В случае, если загрузка программами ЭВМ типа «Электроника-60» произ-
водится через одну (центральную) ЭВМ, оснащенную терминальным оборудо-
268
ванием, возможно следующее архитектурное решение для связи ЭВМ: за
жаемая ЭВМ подключается к загружающей в качестве внешнего устройства,
а загружающая ЭВМ к загружаемой'—через интерфейсный канал.

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

Топология и тип доступа к магистрали локальной сети ГПС могут быть
следующими:

топология общей шины со случайным типом доступа (там, где нагрузка
на шину допустима с точки зрения времени задержки передачи данных);

топология шины или кольца с маркерным доступом в остальных случаях.

Первый вид более подходит для ранних этапов проектирования техноло-
гии для ГПС (системы со сквозным САПР), когда число абонентов точно не уста-
новлено, а время доступа к ним не является критическим. С точки зрения про-
стоты программного обеспечения, эффективности и надежности обмена тополо-
гия кольца предпочтительнее.

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

процедурное описание сети с использованием таблиц адресов абонентов
(удаленный вызов процедур);

разработка средств связывания программ в разных ЭВМ (создание языков
описания локальной сети).

При этом обеспечиваются высокая эффективность программного обеспече-
ния и простота технологии загрузки программ обмена, простота изменения
и модификации программного обеспечения сети.
СОДЕРЖАНИЕ

Предисловие	3

1 ПРОБЛЕМЫ РАЗРАБОТКИ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ

Научные проблемы создания программного обеспечения робототехниче-
ских систем ....................................................

И. М. Макаров, Д. Е. Охоцимский, А. К. Платонов

Языковые средства разработок программного обеспечения промышлен-
ных роботов ....................... ............................

Н. А. Смирнов, В. В. Никифоров

Концептуальная модель системы управления робототехническими комп-
лексами ........................................................

А. Н. Домарацкий

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

А. Н. Домарацкий, А. В. Каширин, Н. Д. Проскурина

Мультипрограммные и мультипроцессорные системы управления робо-
тов ............................................................

А. Ф. Верещагин, А. А. Дмитриев, Т. Н. Сивашева

Организация программного обеспечения многопроцессорных систем уп-
равления .......................................................

И. П. Белякова

2 РЕАЛИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РОБОТОВ

Программные средства для планирования процесса автоматической
сборки.............................................................. 52

Д. Е. Охоцимский, А. К. Платонов, С. С. Камынин, С. И. Гримайло,
А. Ю. Каргашин. А. А. Кирильченко, Е. И. Кутушев

Программное обеспечение устройства контурного управления УКМ-772
для промышленных роботов............................................ 64

А. Н. Домарацкий, В. В. Никифоров

Программное обеспечение робота СУР-25 для дуговой сварки ....	70

С. М. Григорович, В. И. Кавинов, А. Е. Клепов, К. В. Самвелян,
И. Ю. Юрин

Система управления сварочным роботизированным комплексом с исполь-
зованием микро-ЭВМ.................................................. 79

Ф. Н. Кпсилевс.кий, В. Т. Тертышный, Н. Р. Швыдкий

Программное обеспечение роботов для дуговой и электронно-лучевой
сварки с прямоугольной системой координат п дискретным приводом
движения............................................................ 86

Ю. К. Цйганков
Программное обеспечение промышленного окрасочного робота «Колер» 96

А.	П. Федосеев, В. И. Григорьев, С. А. Чевтаев, Л. В. Цуева

Система программного обеспечения роботизированного технологического
комплекса.......................................................... 103

В.	А. Павлов

3 СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ РОБОТОВ

Системное программное обеспечение задач робототехникп...........

А. К. Платонов, Ю. М. Лазутин, В. С. Ярошевский

Специализированная операционная система: программное обеспечение
исследовательского инструментального робототехнического комплекса

А.	Ф. Верещагин, С. Л. Зенкевич, А. В. Назарова

Программное обеспечение системы управления сварочным роботизиро-
ванным комплексом...............................................

В.	Т. Тертышный

Проблемно-ориентированный интерпретатор для микропроцессорных
систем управления движением.....................................

В. Т. Тертышный, Л. Н. Куца

Система взаимодействия программных модулей для многопроцессорных
систем управления...............................................

И. II. Белякова, М. А. Утин

Организация программного обеспечения полунатурного моделирования
роботов ...........................................................

А. И. Казьмин, А. А. Менн, А. А. Петров

142

Программное обеспечение системы группового управления цикловыми
роботами.........................................................

В. 3. Рахманкулов, Д. В. Сатаров

4 АЛГОРИТМЫ УПРАВЛЕНИЯ РОБОТАМИ

Система управления роботом как конечный автомат................... 15b

С. Л. Зенкевич, А. В. Назарова

Синтез программных корректирующих звеньев цифровой следящей сис-
темы промышленного окрасочного робота «Колер»......................164

В. И. Григорьев, С. А. Чевтаев

Иерархическая организация алгоритмов переработки информации при
управлении сварочными роботами..................................., 173

В. Т. Тертышный

Программное обеспечение системы технического зрения промышленного
робота............................................................ 182

К. Н. Ступин

О гибкости программного обеспечения в системах управления производ-
ственными объектами............................................... 187

В. М. Гуревич, А. К. Григорян, В. Е. Вовнобой

Регулярный алгоритм прокладки маршрута мобильного робота с исполь-
зованием только локальной информации.............................. 192

А.	А. Петров, И. М. Сирота
Программно-алгоритмическое обеспечение для анализа изображений
в системах технического зрения............................. 201

А. М. Михайлов

Моделирование роботизированного оборудования в задачах организа-
ционно-технологического управления гибкими автоматизированными
производствами............................................. 210

В.	А. Исаченко, В. С. Шишкин, В. Я. Полыскалин

б СРЕДСТВА ПРОГРАММИРОВАНИЯ И МОДЕЛИРОВАНИЯ ДЛЯ

РОБОТОВ И ГИБКИХ ПРОИЗВОДСТВЕННЫХ СИСТЕМ

Инструментальные средства разработки программного обеспечения гиб-
ких автоматизированных производств................................ 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.

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