Городецкий. Городецкий В.И., Многоагентные системы (обзор). Многоагентные системы (обзор) В. И. Городецкий, М. С. Грушинский, А. В. Хабалов

• Название: Многоагентные системы (обзор) В. И. Городецкий, М. С. Грушинский, А. В. Хабалов
• Анкор: Городецкий
• Дата: 26.05.2022
• Размер: 0.64 Mb.
• Имя файла: Городецкий В.И., Многоагентные системы (обзор).doc
• Тип: Документы; #551918
• страница: 7 из 12

5.1. Архитектура взаимодействия системы агентов

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

5.1.1. Одноуровневая архитектура взаимодействия агентов

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

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

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

1.Начальный вызов. Агент - инициатор встречи устанавливает контакт с агентами заданных участников потенциальной встречи для выяснения их интереса к ней, при этом он указывает параметры встречи: дату, время, длительность, тему. Каждый секретарь спрашивает своего пользователя о том, проявляет ли он интерес к встрече. Если пользователь отвечает положительно, то его секретарь отвечает инициатору встречи о заинтересованности и указывает при этом “фактор ограничений”, который рассчитывается как сумма весов уже запланированных встреч на тот период, который предлагает инициатор встречи. Веса формируются таким образом:

вес=1, если запланированная встреча может быть передвинута;

вес=2, если такая встреча передвинуты быть не может.

Если агент отказывается от встречи, то он просто удаляется из списка участников и далее не рассматривается в задаче планирования.

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

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

Агент, который имеет наибольший фактор ограничений (он имеет меньше всех свободного времени для планируемой встречи и сокращает в наибольшей мере пространство поиска компромисса) получает статус МС (Most Constrained) и далее он берет на себя роль координатора переговоров. Фактически этому агенту назначается роль лидера в традиционной терминологии теории распределенных вычислений. Остальные агенты получают статусы МС2, МС3,... в порядке убывания их факторов ограниченности, последний из них - LC (Least Constrained).

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

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

5.1.2. Иерархическая архитектура взаимодействия агентов

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

Агент, осуществляющий координацию, может быть привязан к конкретному серверу, и тогда он называется “местом встречи агентов”. Место встречи агентов (AMP - Agent Meeting Place) - это агент, играющий роль брокера между агентами, запрашивающими некоторые ресурсы, которыми обладают другие агенты, и теми агентами, которые эти ресурсы могут предоставить. Архитектура AMP есть архитектура обычного агента (см. далее), дополненная некоторыми вспомогательными компонентами, наличие которых обусловлено ролью этого агента как координатора взаимодействия других агентов. Эти вспомогательные компоненты должны, с одной стороны, содержать унифицированное описание множества доступных через AMP агентов и их возможностей (ресурсов, функций и пр.) и, с другой, организовать унифицированный доступ к ним. Это обеспечивается такими компонентами AMP [10].

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

2. Связные порты, ответственные за прием и отправку агентов в AMP с помощью соответствующих протоколов.

3. Компонента установления подлинности агента по имени (опознание агента, “авторизация”).

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

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

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

7. Глубинный маршрутизатор, который ассистирует поверхностному при более специальных и сложных запросах.

8. Менеджер ресурсов; он регистрирует агентов на AMP и ассоциированные с ними ресурсы, а также управляет ресурсами AMP.

9. Среда исполнения агента, которая регистрируется в AMP и управляет доступом к компонентам агента; она интерпретирует сценарии, обеспечивает доступ к базовым возможностям и др.

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

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