CC BY
39
МНОГОАГЕНТНЫЕ ТЕХНОЛОГИИ ПРИ РЕШЕНИИ ПРОИЗВОДСТВЕННЫХ ЗАДАЧ
Ю.Н. Фомина (Санкт-Петербургский государственный университет информационных технологий, механики и оптики)
Важнейшей характеристикой современной организации технологической подготовки производства (ТПП) является широкое использование кооперации, когда вокруг основных предприятий существует круг партнеров-субподрядчиков. Предприятия, выполняющие различные работы по ТПП, рассматривают использование современных форм кооперирования с другими предприятиями в этом же или смежных сегментах рынка как одно из основных направлений своего развития и укрепления на рынке товаров и услуг. Одной из таких эффективных форм организации является виртуальное предприятие (ВП) - это временная межпроизводственная кооперация ряда юридически независимых предприятий или лиц, обладающих ключевыми компетенциями для наилучшего выполнения рыночного заказа, базирующаяся на единой информационно-управленческой системе.
Как показали проведенные исследования, при совместном решении задач ТПП в распределенной среде целесообразно использовать многоагентные технологии. Они наилучшим образом подходят для решения задач, характеризующихся множественными решениями, имеют преимущества при использовании их в распределенной среде, применяются для динамического управления сетевыми ресурсами.
Применение таких технологий становится возможным, когда в информационно-управляющей среде (ИУС) ВП существуют общедоступные описания рынка заказов и рынка услуг. В качестве базового инструментального средства реализации ИУС ВП принята РБМ-система $,шагТеат. Предлагается реализовать агентов в виде программных модулей РБМ-системы, при этом инициализация их работы может происходить:
- в результате некоторого внешнего события, например, поступления заказа на выполнение работ по проектированию изделия или обращения к нему системы управления потоками заданий
БшатТеаш;
- через заданные интервалы времени;
- при поступлении сообщений от других агентов.
Автором предлагается при создании автоматизированной системы ТПП (АСТПП) ВП использовать четыре класса программных агентов: А, В, С и Б.
Агент класса А предназначен для выявления круга потенциальных исполнителей некой работы по ТПП и рассылки им уведомлений о появлении нового заказа. Тем самым данный вид агентов по-
зволяет автоматизировать взаимодействие участников ВП и ускорить процессы формирования активной сети для совместной реализации какого-либо проекта.
Предлагается осуществлять выбор потенциальных исполнителей (из участников ВП) по коду заказа. На их адреса (box ИУС или e-mail) осуществляется рассылка уведомлений.
Определены следующие функции агента класса A:
• определение числа заказов, входящих в текущий проект;
• определение кода k заказов проекта 3i, зарегистрированного в ИУС;
• определение множества возможных производителей (fflj) - исполнителей заказа i (с П, где П - множество участников виртуального предприятия);
• осуществление рассылки уведомлений потенциальным исполнителям;
• активизация агентов класса В и С и передача им сведений о проекте.
Предлагается производить активацию агента через механизм системы управления производственными заданиями WorkFlow SmarTeam.
Агент класса B предназначен для мониторинга состояния регистрации в ИУС предложений от участников ВП на выполнение заказа. Предполагается, что агенты данного вида должны отслеживать количество заявок потенциальных исполнителей на выполнение работ по ТПП. Если число таких предложений превысило предустановленный предел либо исчерпался заданный лимит времени ожидания, агент отправляет сообщение специалисту компании о текущем состоянии проекта: количество зарегистрировавшихся исполнителей, расчетный приоритет этих компаний как потенциальных партеров. Следует отметить, что такое уведомление может содержать информацию об отсутствии предложений на выполнение некоего заказа.
Определены следующие функции агента класса B:
• определение количества заявок (z) на выполнение определенного заказа;
• мониторинг состояния заказа;
• расчет приоритетов компаний-партнеров: Priority;
• составление отчета и передача его специалисту компании, ответственному за конфигурирование ВП;
• передача данных о состоянии заказов агенту класса С.
Для расчета приоритета того или иного партнера, по мнению автора, необходимо иметь данные обо всех сделках, заключенных с этим предприятием ранее. Предлагается использовать три характеристики проекта: время (x) и качество выполнения (у), а также прочие условия договора (z).
Как показал анализ, значения переменных x, у, z будут соответствовать следующим условиям: Ixe Z lye Z Ize Z jxe[0;3], |ye[0;3], |ze[0;3], где Z - множество целых чисел.
При этом каждому значению переменных соответствует оценка работы с партнером по четырехбалльной шкале (например, отлично, хорошо, удовлетворительно, плохо).
Таким образом, можно утверждать, что приоритет подрядчика (Priority) может быть рассчи-
. . 1n k,x„ + k,y„ + k3zn
тан по формуле: Priority=--—-—,
ni=i 3
где n - число ранее выполненных заказов для подрядчика; k1, k2, k3 - весовые коэффициенты атрибутов x, y и z соответственно; xn, yn, zn -значения атрибутов для n -го заказа. Значение Priority принадлежит промежутку [0,1].
Предполагается, что агент класса C ожидает поступления сведений от агентов класса B о завершении обследования всех, относящихся к текущему проекту заказов. После поступления сигнала о доопределении последнего заказа агент данного класса составляет отчет определенного вида (см. табл.).
Таблица
Пример реализации отчета агента класса C
Проект Заказы Подрядчики Приоритеты
Проект №1 Заказ №1 Подрядчик 1
Подрядчик 2
Заказ №2 Подрядчик 2
Подрядчик 3
Подрядчик 4
Генерируемый отчет отправляется специалисту предприятия, ответственному за размещение заказов на данный проект. Получение такого сообщения служит сигналом для начала работ по конфигурированию ВП.
Назначение данного типа агентов заключается в систематизации информации и в предоставлении ее пользователю в едином формате, в форме, удобной для восприятия и анализа ситуации распределения заказов в целом.
Определены следующие функции агента класса &
• ожидание сведений от агентов класса В о регистрации предложений от производителей по текущему проекту;
• сбор информации о заказах, потенциальных исполнителях и их приоритетах по всем заказам проекта (производится после поступления сообщения о прекращении мониторинга по последнему заказу проекта);
• составление отчета (см. табл.);
• передача отчета специалисту предприятия, ответственному за размещение заказов среди участников ВП.
При получении неудовлетворительных результатов поиска предложений от подрядчиков специалист компании вынужден будет смягчать требования технического задания по некоторым (или всем) заказам. Возможно предусмотреть, чтобы ответственный сотрудник предприятия мог получать промежуточные отчеты, описывающие текущее состояние проекта.
Агенты класса Б предназначены для проведения оптимизации распределения и конфигурирования заказов на ТПП среди участников ВП.
Определены следующие функции агента класса Б:
• получение предпочтительных значений критериев выбора лучшего предложения о реализации заказа (источник данных - технические задания на заказы работ по ТПП);
• получение значений характеристик договора из предложений подрядчиков;
• получение значений приоратов потенциальных исполнителей проекта;
• конфигурирование ВП;
• составление и передача отчета специалисту предприятия-заказчика о результатах поиска.
Пакет заказов на выполнение работ по ТПП
Агент Агент Агент
Ai At Am
Агент Bit Агент Bkt Агент Bnt
rkt ______
1 1
Агент Ci Агент Ck Агент Cn
■V^S, Sk Sn^'
Перечень предприятий-исполнителей по _ Агент
v^ D
имеющимся заказам
Алгоритм функционирования многоагентной ИУС
Управление процессами ТПП целесообразно осуществлять средствами WorkFlow PDM-системы SmarTeam. Данный ресурс может быть доступен через сеть Internet при нулевой установке. Экспериментально установлено, что WorkFlow Smar-Team можно использовать как основу для создания многоагентной системы (МАС).
Z
Z
S
S
S
Алгоритм взаимодействия программных агентов в рассматриваемой многоагентной ИУС представлен на рисунке.
Как показали проведенные исследования, реализация АСТПП как МАС позволяет решать задачи ТПП в условиях кооперации на основе децентрализованного управления, обеспечивая более высокий уровень автоматизации. Преимущества рассмотренного подхода, использующего методы многоагентных технологий состоят в большей гибкости системы и в ускорении ее работы за счет параллельного решения задач программами-агентами. Однако реализация предложенной МАС предъявляет значительно более высокие требова-
ния к уровню организации открытого информационного пространства для предприятий, участвующих в совместном решении задач ТПП (учет большего объема данных в PDM-системе, необходимых для реализации агентов).
Таким образом, можно сделать вывод, что использование принципов MAC позволяет реализовать главное требование к динамической модели управления деловыми процессами ВП - в режиме реального времени сформировать наилучшую для выполнения определенного проекта конфигурацию делового процесса из доступного множества моделей деловых процессов, оптимизационных алгоритмов и информации.
ОБЩАЯ СХЕМА ВЕРИФИКАЦИИ УТВЕРЖДЕНИЙ P-ЛОГИКИ С НЕИЗВЕСТНЫМИ ПАРАМЕТРАМИ
Д.Д. Еловков (Санкт-Петербургский государственный университет)
В последние годы много внимания уделяется методологиям создания качественных программных систем. В этой связи большое количество исследований проводится в области систем типов, верификации, проверки моделей и других механизмов статического анализа программ. Языки программирования сильно различаются по степени надежности и подверженности тем или иным ошибкам. Язык функционального программирования Хаскел [3] считается одним из наиболее надежных языков программирования общего назначения. Чистый функциональный подход обеспечивает полный контроль над побочными эффектами вычислений, исключая большой класс ошибок, присущих стандартным императивным языкам. Развитая система типов позволяет статически гарантировать сложные свойства Хаскел-про-грамм.
Одним из исследовательских проектов в области верификации функциональных программ является Prograшatica. Цель данного проекта -создание средств разработки высоконадежных Хаскел-программ [4]. В рамках проекта были разработаны верификационная логика для Хаскела, Р-логика, и автоматический верификатор утверждений Р-логики. Средства Prograшatica позволяют описывать свойства Хаскел-программы, выражая их в виде формул Р-логики [1], и в дальнейшем верифицировать их тем или иным способом. Одной из характерных черт инструментов разработки Prograшatica является то, что свойства можно описывать в любом месте программы, где могут встречаться объявления термов. Это способствует интеграции программирования и верификации в процессе разработки ПО.
Для верификации утверждений Р-логики с помощью автоматического верификатора Progra-шatica строит логический контекст, в котором следует проверять истинность данного утверждения [2]. Он состоит просто из утверждений эквивалентности, соответствующих определениям выражений, находящихся в области видимости верифицируемого утверждения. Однако для высказывания, определенного внутри функции, в области видимости также будут параметры функции, и корректность высказывания может, конечно же, зависеть от значений этих параметров. Но логический контекст, построенный для такого высказывания, не будет содержать никакой информации о параметрах функции, поскольку их определения недоступны и их значения могут быть любыми, в зависимости от того, как была использована данная функция в том или ином месте программы. Поэтому нельзя верифицировать высказывание Р-логики, корректность которого зависит от значений параметров содержащей данное высказывание функции.
В настоящей работе предлагается метод верификации таких высказываний. Идея метода состоит в том, чтобы учесть все места в программе, откуда непосредственно или косвенно вызывается функция, содержащая высказывание. Это даст информацию о всех возможных в данной программе значениях параметров нашей функции. И тогда останется лишь проверить, что высказывание истинно при всех этих значениях своих неизвестных параметров.
Сначала с функцией, содержащей высказывание, связывается предикат Р-логики, которому должны удовлетворять аргументы функции, чтобы
