Рыбина Технология построения динамических 2011

вывода АТ-РЕШАТЕЛЬ мог инициировать действия (операции) над ИМ, изменяющие состояние модели за определенный промежуток модельного времени. Текущая версия АТ-РЕШАТЕЛЯ обладает широким спектром функциональных возможностей, в частности, при выполнении правил БЗ предусматривается не только изменение состояния рабочей памяти, но и вызов функций специальных компонентов, используя COM-технологию. Это позволяет разработать механизм взаимодействия между АТ-РЕШАТЕЛЕМ и подсистемой имитационного моделирования, реализовав необходимый интерфейс на стороне последней.

Вторая проблема – это совместное использование рабочей памяти подсистемой имитационного моделирования и другими компонентами комплекса АТ-ТЕХНОЛОГИЯ, что возможно путем разработки специального компонента – шлюза, в задачи которого входит синхронизация состояний рабочей памяти динамической ИЭС и состояния ИМ в каждый такт модельного времени в ходе проведения эксперимента с ИМ. Основными функциями данного компонента являются:

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

∙сканирование рабочей памяти в каждый такт модельного времени и передача информации об изменениях, внесенных в рабочую память компонентами комплекса АТ-ТЕХНОЛОГИЯ, подсистеме имитационного моделирования.

Технологическая реализация интеграции разработанных средств построения ИМ с базовыми подсистемами комплекса АТТЕХНОЛОГИЯ является весьма нетривиальной задачей, поэтому для этих целей был создан специальный программный стенд, обеспечивающий проведение отладки интеграционных механизмов различных компонентов комплекса [21].

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

141

стей: организация работы с отлаживаемыми системами в виде проектов; использование визуального проектирования новых компонентов и подсистем для комплекса АТ-ТЕХНОЛОГИЯ; блок отладки системы и ее основных компонентов, включающий компоненты управления процессом отладки, обработки ошибок и визуализации процесса отладки.

Использование процессов совместного функционирования прототипа подсистемы имитационного моделирования с отдельными подсистемами комплекса АТ-ТЕХНОЛОГИЯ, проведенное на программном стенде, продемонстрировало возможность в режиме реального времени передавать в рабочую память АТ-РЕШАТЕЛЯ данные об изменении состояния ИМ, а также получать и исполнять управляющие воздействия на модель, инициируемые АТРЕШАТЕЛЕМ во время вывода.

Поэтому следующим важным этапом развития средств комплекса АТ-ТЕХНОЛОГИЯ для поддержки построения динамических ИЭС является расширение возможностей АТ-РЕШАТЕЛЯ для осуществления временного (темпорального) вывода, что связано с созданием специального темпорального решателя. С этой целью было проведено сравнение различных моделей представления времени по нескольким критериям (естественность представления времени – от абстрактного до естественного; количество разработок по данной теме – от малого до большого; вычислительная сложность используемых алгоритмов – от низкой до высокой) на основе чего выбрана модель интервальной временной логики Аллена [14], обладающая достаточно сбалансированными характеристиками по всем критериям и имеющая развитый математический аппарат. Предварительные экспериментальные исследования, связанные с моделированием архитектуры прототипа темпорального решателя с использованием лицензионной системы G2, показали эффективность применения интервальной логики Аллена исходя из целей данной работы.

Дальнейшее развитие средств комплекса АТ-ТЕХНОЛОГИЯ для поддержки построения динамических ИЭС (так называемая «динамическая версия») предполагает расширение возможностей АТ-РЕШАТЕЛЯ для осуществления временного (темпорального) вывода, разработку средств, позволяющих получать данные из

142

внешних источников в режиме РВ, а также реализацию других механизмов построения динамических ИЭС в рамках задачноориентированной методологии.

2.1.5. Современные инструментальные средства имитационного моделирования

2.1.5.1. Общая характеристика инструментальных средств имитационного моделирования

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

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

[6], [7] и др.

GPSS (General Purpose Simulating System) – широко известный и распространенный язык для моделирования дискретных систем, который предназначен для написания ИМ систем с дискретными событиями. Наиболее удобно в системе GPSS описываются модели систем массового обслуживания, для которых характерны относительно простые правила функционирования составляющих их эле-

ментов [6], [7].

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

143

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

Исключительность СИМУЛА-67 заключается в том, что он является весьма удобным средством создания самих языков имитационного моделирования, например, средствами СИМУЛА можно реализовать GPSS.

Наибольший интерес в контексте данной работы вызывает инструментарий на базе РДО-метода построения ИМ. В 1993 году в МГТУ им Н.Э. Баумана В.В. Емельяновым был создан язык интеллектуального имитационного моделирования – РДО [7], а на его основе – интеллектуальная среда RAO-Studio для поддержки разработки имитационных моделей и систем управления.

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

Ниже приводится краткое описание среды имитационного мо-

делирования RAO-Studio [6], [7].

2.1.5.2. Анализ текущей версии среды имитационного моделирования RAO-Studio

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

RAO-Studio.

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

Структура продукционного имитатора, использующегося в RAO-Studio, представлена на рис. 32. Основными элементами РДО-имитатора являются модифицированная продукционная система и аппарат событий [5], [7]. Действия инициируются системой вывода, а нерегулярные события имитируются специальным блоком. При имитации состояние системы изменяется в соответствии с описанием нерегулярного события либо действия, которое началось или завершилось. После любого изменения состояния моделируемой системы вызывается система вывода, с помощью которой осуществляется просмотр в БЗ всех операций и проверка предусловий (могут ли они начаться). При нахождении таких операций инициируются события начала соответствующих действий.

Таким образом, представленная на рис. 32 продукционная система (БД, БЗ и система вывода), система имитации нерегулярных событий и аппарат ведения событий совместно осуществляют построение модели процесса [7]. На основании анализа результатов имитации на этой модели вычисляются различные показатели функционирования системы.

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

145

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

В лаборатории «Интеллектуальные системы и технологии» кафедры Кибернетики НИЯУ МИФИ инструментальный комплекс RAO-Studio v1.0 (РДО v2.0) включен в состав имитационномоделирующего стенда и активно используется как в рамках учебного процесса, так и в научно-исследовательской работе [23]. Разработан новый лабораторный практикум, позволяющий осуществлять целевую подготовку специалистов в области построения динамических ИЭС путем приобретения навыков создания ИМ для заданных ПрО, и проведения имитационных экспериментов с целью выявления закономерностей функционирования системы.

146

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

Это связано с тем, что очень часто для ДИС, связанных с управлением и принятием решений, возникает необходимость решения задачи оптимизации, применяя имитационные модели в совокупности с алгоритмами оптимизации. ИМ при таком подходе служит для оценки качества того или иного решения, а оптимизационный алгоритм осуществляет поиск наилучшего (или близкого к нему) решения. Механизм точек принятия решений в языке имитационного моделирования РДО позволяет гибко сочетать имитацию с оптимизацией, для чего используются алгоритмы поиска на графе состояний [6], [7].

Точки принятия решений в языке РДО описывают способы использования образцов ($Pattern) для моделирования процесса и принятия решений на уровне событий. Их описывают в от-

либо объект точек принятия решений. В версии РДО-языка 2.0 имеется два типа точек принятия решений [6]:

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

search – реализовать поиск на графе состояний.

На базе языка РДО и инструментального комплекса RAO-Studio существует множество типовых лабораторных ра-

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

плекса RAO-Studio.

147

2.2. Инструментальные средства проектирования и реализации агентов и многоагентных систем

2.2.1.Анализ зарубежных инструментальных средств

2.2.1.1.AgentBuilder

Безусловным лидером в области коммерческих ИС для поддержки построения МАС является инструментарий AgentBuilder [42] компании Reticular Systems, Inc., который состоит из двух компонентов: средств разработки (development tools) и окружения периода исполнения (run-time execution environment). Первый ори-

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

∙определение структуры МАС (состава агентов);

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

∙определение протоколов взаимодействия агентов;

∙генерация специального файла спецификации поведения агентов (представляет ментальную модель и желаемое поведение агента).

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

148

Для спецификации поведения агентов в системе AgentBuilder используется специальный ОО-язык RADL (Reticular Agent Defini-

tion Language).

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

NAME имя правила

WHEN Message Condition(s) IF Mental Condition(s)

THEN Private Action(s); Mental Change(s); Mes-

sage Action(s)

Спецификация поведения агентов и их ментальных моделей составляет специальный файл (agent definition file), который используется совместно с классами и методами из библиотеки действий агентов и библиотеки интерфейсов. Этот файл интерпретируется в рамках компонента Reticule’s Run Time Agent Engine, являющегося

частью AgentBuilder.

Как показано в [25], AgentBuilder является серьезной системой представления и манипулирования знаниями, однако в ней отсутствуют средства эксплицитного управления выводом, которые могли бы существенно увеличить функциональную мощность языка, нет и средств явной фиксации состояний агента, отличных от флагов и/или значений переменных. Не вполне ясно и то, как в спецификации моделей поведения могут быть учтены разные, но одновременно сосуществующие «линии поведения», что характерно для действительно интеллектуальных агентов. Непонятными остаются

149

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

2.2.1.2.Bee-gent

Всистеме Bee-gent [44] для проектирования и реализации МАС используется специальная МАС-библиотека, реализованная на языке Java, в системе используется множество базовых агентов (generic agents), среди которых можно выделить агентов окружения

(agent wrappers) и агентов посредников (mediation agents).

Поведение агентов, направленное на достижение определенных целей, базируется на спецификации «бесед» (message exchange) через протоколы взаимодействия (interaction protocol), такие протоколы представляются специальными графами, основными понятиями

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

Графы состояний агентов строятся с помощью специальных графических средств, предоставляемых системой Bee-gent на основании жизненного цикла ролей, определенных в виде регулярных выражений на этапе агентно-ориентированного анализа (например, методология Gaia [45]). Граф состояний регистрирует все имена состояний, в которых агент может находиться. На следующем шаге разработки определяются классы для каждого состояния . Каждое состояние в графе является экземпляром класса AwrIPState из агентной библиотеки фирмы Toshiba [42]. В конструкторе класса определяются условия, которые должны быть выполнены агентом

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

150