Решим задачу за 30 минут!
Опубликуй вопрос и получи ответ со скидкой 20% по промокоду helpstat20
Данная работа не уникальна. Ее можно использовать, как базу для подготовки к вашему проекту.

Оглавление

Введение

1. Мультиагентный мониторинг автотранспортных средств

1.1 Постановка задачи

1.2 Вызовы экономики реального времени

1.3 Мультиагентная технология для управления ресурсами в реальном времени

1.4 Аппаратная архитектура системы

1.4.1 Спутниковый мониторинг автотранспорта

1.4.2 Бортовое оборудование

1.4.3 Диспетчерский центр (ДЦ)

1.5 Программное обеспечение

1.6 Описание мультиагентной системы диспетчеризации грузоперевозок

2. Мультиагентные технологии

2.1 Мультиагентные системы

2.2 Основные понятия архитектуры мультиагентных систем

2.3 Характеристики мультиагентных систем

2.4 Переговоры в мультиагентых системах

2.5 Формат сообщений

2.6 Онтологии

2.7 Существующие стандарты построения мультиагентных систем

2.8 FIPA (Foundation for Intelligent Physical Agents)

Библиографический список

Введение

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

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

Аппаратная реализация подобной системы в общем виде состоит из следующих подсистем :

· Подсистема навигации – спутниковая система определения координат GPS/ГЛОНАСС на базе группировки среднеорбитальных спутников;

· Бортовое оборудование, устанавливаемое на подвижные объекты – комплект, включающий в себя навигационный GPS(GPS/ГЛОНАСС)-приемник, контроллер, устройство приема/передачи информации, дополнительное оборудование (дискретные и аналоговые датчики и др.);

· Подсистема обмена информацией – реализуется на базе следующих вариантов: радиосеть местного оператора сотовой связи, транкинговая сеть, конвенциальная сеть (УКВ), radio-ethernet, спутниковая связь (Globalstart, Inmarsat, Thuraja);

· Подсистема контроля и управления – диспетчерский центр (ДЦ).

1. Мультиагентный мониторинг автотранспортных средств

1.1 Постановка задачи

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

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

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

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

1.2 Вызовы экономики реального времени

В настоящее время к бизнесу предъявляются новые требования. Согласно исследованию компании IBM (опрос порядка 1000 генеральных директоров [Скобелев]) основными вызовами современной компании являются:

· Рост сложности принятия решений по управлению бизнесом

Это проявляется в том в том, что нужно согласовано принимать решения в условиях множества игроков с различными интересами. В случае грузовых перевозок это интересы: водителя, грузовика(ТО) и заказчика и других.

· Неопределенность: трудно предсказать изменения спроса и предложения

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

· Событийность: часто случаются события, которые меняют планы

· Ситуативность: решение надо принимать по ситуации

· Многофакторность: много разных критериев, предпочтений и ограничений

· Высокая связность: принятие одного решения вызывает изменение других

· Индивидуальность: потребители требуют все более индивидуального подхода

· Трудоемкость: слишком много опций, чтобы просчитать последствия

· Оперативность: требуется высокая скорость принятия решений

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

1.3 Мультиагентная технология для управления ресурсами в реальном времени

Рис. 1

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

1.4 Аппаратная архитектура системы

1.4.1 Спутниковый мониторинг автотранспорта

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

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

Принцип работы заключается в отслеживании и анализе пространственных и временных координат транспортного средства.

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

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

Мобильный модуль может быть построен на основе приёмников спутникового сигнала, работающих в стандартах NAVSTAR GPS или ГЛОНАСС.

1.4.2 Бортовое оборудование

Система спутникового мониторинга транспорта включает следующие компоненты:

· транспортное средство, оборудованное GPS или ГЛОНАСС контроллером или трекером, который получает данные от спутников и передаёт их на серверный центр мониторинга посредством GSM, CDMA или реже спутниковой и УКВ связи. Последние два актуальны для мониторинга в местах, где отсутствует полноценное GSM-покрытие, таких как Сибирь или Дальний Восток;

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

Использование систем спутникового мониторинга повышает качество и эффективность работы корпоративного транспорта, и в среднем на 20-25% снижают расходы на топливо и содержание автопарка.

Контроллеры и треккеры

Большинство контроллеров и треккеров имеют схожие функциональные возможности:

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

· подключать внешние датчики через аналоговые или цифровые входы;

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

· хранить некоторый объём данных во внутренней памяти на период отсутствия связи;

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

Ранее по причине слабого охвата территорий сетями мобильной связи GSM/3G широко использовались контроллеры, которые накапливали данные во внутренней памяти. По возвращению объекта в место основной дислокации (автопарк), данные переносились на сервер по проводным каналам либо через Bluetooth или Wi-Fi. Многие из существующих GPS-трекеров и контроллеров имеют открытый протокол взаимодействия с сервером, а также позволяют выполнять настройку режимов работы при помощи SMS, CSD или при помощи GPRS соединения.

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

Собственной производственной базой для изготовления навигационных терминалов в России сегодня располагают около 50 предприятий. Трекеры ГЛОНАСС/GPS производят: М2М телематика, Standard, КБ Навис, Ижевский радиозавод, Российский институт радионавигации и времени и еще несколько десятков компаний.

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

Для целей мониторига и диспетчеризации ТС в моём случае, можно использовать GPS-ГЛОНАСС треккеры серии NAVIXY, так как они обладают следующими характеристиками:

· Поддержка GPS/ГЛОНАСС

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

· Резервный аккумулятор большой емкости (10.4 Ah) обеспечивает автономную работу устройства в течение 80 часов в режиме непрерывного мониторинга и более 90 дней с применением энергосберегающего режима

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

· Поддержка GSM 850/900/1800/1900 МГц, GPRS UDP и TCP, SMS

· Встроенная энергонезависимая память на 100,000+ точек маршрута (эквивалентно примерно 10 000 км). Используется, например, для накопления данных при нахождении вне зоны GSM-покрытия

· Имеет 4 дискретных входа и 4 программируемых выхода для подключения датчиков и внешних устройств.

Датчики

Для получения дополнительной информации на транспортное средство устанавливаются дополнительные датчики, подключаемые к GPS или ГЛОНАСС контроллеру, например:

· датчик расхода топлива (Датчики серии DFM, в зависимости от типа бака);

· датчик нагрузки на оси ТС (AS-2 либо AS-3);

· датчик уровня топлива в баке (DUT-E A5 или DUT-E A10);

· датчик температуры в рефрижераторе (датчики серии ReeferMate);

1.4.3 Диспетчерский центр (ДЦ)

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

1.5 Программное обеспечение

В качестве ОС на серверах можно использовать любую среду для запуска виртуальной машины Java. Такую среду предоставляют как бесплатные операционные системы семейства Linux (Ubuntu, Fedora, Debian), так и платные аналоги RedHat Linux или операционные системы семейства Microsoft Windows. Для наших целей подходит open-source решения, распространяемые со свободной лицензией, такие как Debian.

Java Virtual Machine (JVM) – среда для запуска java-приложений, распространяется также свободна, и может быть использована в данном проекте.

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

1.6 Описание мультиагентной системы диспетчеризации грузоперевозок

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

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

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

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

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

2. Мультиагентные технологии

2.1 Мультиагентные системы

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

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

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

· множество задач;

· среда, т. е. некоторое пространство, в котором существуют агенты и объекты;

· множество отношений между агентами;

· множество действий агентов (например, операций над объектами).

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

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

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

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

рисунок 2.1 Структура типичного агента

· автономностью – способностью функционировать без вмешательства человека, контролируя свои действия и внутреннее состояние;

· социальностью – способностью функционировать в сообществе агентов и обмениваться с ними сообщениями с помощью некоторого языка коммуникаций;

· реактивностью – способностью воспринимать состояние среды и своевременно реагировать на происходящие в ней изменения;

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

2.2 Основные понятия архитектуры мультиагентных систем

Основными понятиями, относящимися к архитектуре мультиагентных систем, являются:

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

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

Фреймворк агентов – набор программных средств направленных на создание (конструирование) агентов. Примерами таких средств являются Jade, Voyager, Aglets и Odyssey;

Инфраструктура агентов – представляет собой правила, по которым агенты должны взаимодействовать между собой и понимать друг друга, таким образом, определяя разделение знаний. Агентная инфраструктура имеет отношение к таким понятиям как:

ь Онтология – позволяет «понимать» сущность основных концепций системы;

ь Протоколы коммуникации – описывает язык коммуникаций агентов;

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

ь Протоколы взаимодействия – описывает соглашения для взаимодействия агентов.

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

Существуют несколько типов агентов, попадающих под определение агента среднего уровня:

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

Агент-посредник – агенты, которые используют знания для создания служб приложения более высокого уровня;

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

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

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

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

· Язык и протокол коммуникации агентов;

· Формат содержимого сообщений;

· Общая онтология.

2.3 Характеристики мультиагентных систем

Мультиагентным системам характерно следующее:

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

• отсутствует глобальный контроль системы;

• данные децентрализованы;

• асинхронное вычисление.

Наблюдается увеличивающийся интерес, относящийся к исследованию МАС. Причины, по которым это происходит, следующие: МАС способны обеспечить устойчивость против ошибок и эффективность; МАС позволяют взаимодействовать с существующим наследием систем; МАС способны решать задачи, в которых управление, данные, экспертные знания являются распределенными.

2.4 Переговоры в мультиагентых системах

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

Выделяют три главные темы исследования переговоров:

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

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

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

Переговоры в МАС могут содержать сложные рассуждения высокого уровня.

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

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

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

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

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

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

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

2.5 Формат сообщений

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

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

ACL (Agent Communications Language) представляет собой формат сообщения и протокол обработки сообщений, для поддержки общих знаний агентов. Этот язык может быть представлен как составляющая трех уровней:

1. Уровень коммуникаций, который описывает нижний уровень параметров коммуникации, таких как отправитель, приемник и коммуникационный идентификатор;

2. Уровень сообщений, который представляет протокол взаимодействия;

3. Уровень содержимого.

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

рисунок 2.2 Типичное сообщение языка ACL

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

sender: агент, отправляющий сообщения,

receiver: агент, получающий сообщения,?

content: контекстно-зависимая информация, описывающая сообщение.

in-reply-to: Строка, идентифицирующая сообщение соответствует параметру reply-with при ответе на сообщение,

?reply-with: идентификатор, используемый для ответа на данное сообщение

language: язык для интерпретации информации содержимого сообщения,

ontology: определяет онтологию интерпретации информации содержимого сообщения.

2.6 Онтологии

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

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

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

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

2.7 Существующие стандарты построения мультиагентных систем

Природа распределения и взаимодействия агентов исследуется различными группами ученых, работающими над стандартизацией взаимодействия мультиагентных систем. Некоторые из этих групп представляют собой FIPA (Foundation for Intelligent Physical Agents), OMG (Object Management Group), KAoS (Knowledge-able Agent- oriented System) и другие.

В данной работе использовался стандарт FIPA, о котором далее и пойдёт речь.

2.8 FIPA (Foundation for Intelligent Physical Agents)

The Foundation for Intelligent Physical Agents (FIPA) – это сообщество разработчиков, целью которых является стандартизация агентных технологий. Эта организация создала ряд спецификаций для непосредственного использования в мультиагентных системах. Самыми главными среди этих спецификаций являются Управление Агентами (Agent Management) и Язык Коммуникации Агентов (Agent Communication Language).

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

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

Рис. 2.3. Модель управления агентами

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

Агент – это некий вычислительный процесс, который наделен автономностью и коммуникативной функциональность в рамках приложения. Агенты обмениваются информацией с помощью Языка Коммуникации Агентов (Agent Communication Language). Агенты – это главные действующие сущности агентной платформы, которые представляют собой комбинацию одной или множества различных сервисных возможностей и операций, описанных в их характеристиках, внутри объединенной и интегрированной исполняемой модели. Агент должен иметь, по крайней мере, одного хозяина, который либо определяется организационными особенностями, либо должен быть при- вязан к конкретному пользователю, и он (агент) должен выражать хотя бы одно понятие для своей идентификации. Это понятие для идентификации называется Идентификатор Агента (Agent Identifier (AID)), который однозначно определяет агента в Множестве Агентов (Agent Universe). Агент может быть зарегистрирован как набор транспортных адресов, с которыми он может контактировать.

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

Система Управления Агентами (Agent Management System (AMS)) – это обязательный компонент агентного приложения. Система управления агентами проводит непосредственный контроль за существованием и использованием Агентной платформы. Только одна Система Управления Агентами может существовать в простой Агент- ной Платформе. Система Управления Агентами обслуживает каталог идентификаторов агентов, которые содержат транспортные адреса для зарегистрированных в Агентной Платформе агентов. Она представляет собой «белые страницы» возможностей для других агентов. Каждый агент должен регистрироваться в Системе Управления Агентами для получения действительного идентификатора.

Служба Транспортировки Сообщений (Message Transport Service (MTS)) – это стандартный коммуникационный метод коммуникации между агентами различных Агентных Платформ.

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

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

Необходимо отметить, что концепция Агентной Платформы не означает, что агенты должны «располагаться» на одном компьютере. FIPA предусматривает различные варианты Агентных Платформ – от простых процессов, содержащих «легкие» агентные потоки, до полностью распределенных платформ, построенных на собственных или открытых межплатформенных стандартах.

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

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

Заключение

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

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

Библиографический список

1. Чекинов Г.П., Чекинов С.Г. Применение технологии мультиагентных систем для интеллектуальной поддержки принятия решений. Сетевой электронный научный журнал “Системотехника”, No 1, 2003 г. ?

2. Тарасов В.Б. Агенты, мультиагентные системы, виртуальные сообщества: стратегическое направление в информатике и искусственном интеллекте// Новости искусственного интеллекта, No 2, 1998. – С. 5-63 ?

3. Котенко И.В., Станкевич Л.А. Командная работа агентов в реальном времени. Новости искусственного интеллекта, No 3 (57), 2003. – С. 25-31. ?

4. Roberto A. Flores-Mendez. Towards a Standardization of Multi-Agent System Frameworks

5. Тарасов В.Б. От мультиагентных систем к интеллектуальным организациям: философия, психология, информатика. ?

6. Келеберда И.Н., Лесная Н.С., Репка В.Б. Использование мультиагентного онтологического подхода к созданию распределенных систем дистанционного обучения, Educational Technology & Society, 7 (2), 2004. ?

7. Никольский С.Н. Структурные системные модели в задаче автоматизации проектирования. – М.: 2007. ?

8. FIPA Agent Management Specification, 03.12.2002. ?

9. Jeffrey M. Bradshaw. KAoS: An Open Agent Architecture Supporting Reuse, Interoperability, ?and Extensibility

10. Dejan Milojicic и др. MASIF. The OMG Mobile Agent System Interoperability Facility

11. Винер Н. Кибернетика, или управление и связь в животном и машине. М.: Наука. 1983.

4.84
Oksi.O
Большой поток заказов из вне (примеры в портфолио). А потому рейтинг минимум! Не использую тех.подъём! Качественное, грамотное исполнение по актуальным данным. По аналитике апеллирую исключительно официальными источниками!