Software & Systems

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

В статье рассматриваются средства параллельной обработки информации в интеллектуальных СППР РВ, создаваемых на основе высокоэффективного инструментального комплекса G2-GDA [2].

Уровни параллелизма

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

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

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

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

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

-     параллелизм на уровне отдельного модуля;

-     параллелизм на уровне отдельной команды.

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

Для представления знаний в СППР РВ наиболее продуктивной является объектно-ориентированная модель представления знаний в сочетании с продукционными правилами для поиска решения [1-3].

Рассматривая продукционные модели как средство представления и оперирования знаниями, можно выделить два уровня параллелизма [4,5]:

·          мелкоструктурный (fine-grain), относящийся к параллелизму внутреннего уровня;

·          крупноструктурный (large-grain), являющийся параллелизмом внешнего уровня.

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

Для реализации различных уровней параллелизма в СППР РВ необходимо наличие соответствующих средств поддержки. Опыт последних лет показал, что таким средством является комплекс конструирования экспертных систем РВ G2 (Gensym Corp.,USA) [2,4,6-8] и его графическое расширение GDA (G2 Diagnostic Assistant).

Параллелизм на уровне разработки

Комплекс G2-GDA поддерживает многопользовательский подход к созданию программного продукта (приложения). При этом каждый разработчик имеет доступ к соответствующей базе знаний (БЗ), находящейся на сервере, через средство TELEWINDOWS, которое обычно находится на другой ЭВМ (клиенте). G2-приложение может быть реализовано не только на различных ЭВМ, но и с использованием нескольких G2, взаимодействующих между собой. Таким образом, уже на уровне разработки приложения возможно максимально распараллелить работу и реализовать параллелизм самого верхнего уровня.

Параллелизм на уровне задач, процедур и программных модулей

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

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

Еще одним способом распараллеливания процесса поиска решения в системе G2 является распараллеливание внутри процедур и методов. Для этого применяется конструкция do in parallel, которая служит для одновременного выполнения нескольких независимых операторов и имеет следующий вид.

Все операторы Oi выполняются параллельно, и после их завершения выполняются операторы, следующие за оператором end.

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

Параллелизм на уровне правил

Комплекс G2-GDA поддерживает 6 типов правил: Initialy, Unconditionaly, Whenever, When, If, For.

Все правила типа Initialy начинают выполняться параллельно при запуске приложения. В этом правиле можно активизировать какую-либо процедуру, присвоить параметрам или переменным начальные значения, открыть нужные для работы подпространства. Например:

Initialy conclude that the actual-zn of m79 is 30

(при инициализации заключить, что параметр actual-zn объекта m79 есть 30);

Initialy start get-message( )

(при инициализации запустить процедуру get-message( )).

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

Правила типа When и Whenever похожи. Правило When активизируется, когда выполняется некоторое логическое условие, а Whenever активизируется, когда совершается некоторое событие. Если в данный момент времени активны несколько правил When или Whenever, то будут выполняться заключения каждого такого правила. Аналогично и для правила типа If, которое отличается от правила When тем, что на его основе можно строить сложные схемы рассуждений типа деревьев решений [4,8].

Примеры использования данных правил:

When actual-zn of m79 is normal conclude that the status of m79 is ok

(когда параметр actual-zn объекта m79 имеет нормальное значение, заключить, что параметр status объекта m79 есть ok);

Whenever actual-zn of m79 received a value

unconditionaly conclude that the level of m79 is work

(всякий раз, как параметр actual-zn объекта m79 получает значение, безусловно заключить, что параметр level объекта m79 есть work).

If actual-zn of m79 is normal conclude that the status of m79 is ok

(если параметр actual-zn объекта m79 имеет нормальное значение, заключить, что параметр status объекта m79 есть ok);

Правило типа For вместе с действием определяет пространство его выполнимости, например:

For any m conclude that status of m is оk

(для любого объекта m установить в атрибуте status значение оk).

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

Whenever actual-zn of m79 received a value

unconditionaly conclude that the status of m79 is ok

Whenever actual-zn of m79 received a value

unconditionaly conclude that the status of m79 is not_ok.

Так как оба правила выполняются независимо друг от друга и параллельно, то неясно, какое значение примет параметр status: ok или not_ok. Это довольно очевидный пример противоречивых правил, который легко обнаружить при заполнении БЗ. Но в большинстве случаев правила сложные, используются цепочки прямого (forward chaining) и обратного (backward chaining) связывания правил, когда противоречия могут быть скрыты и возникать только на стадии активизации правил, что может повлечь их некорректное выполнение. Таким образом, разработчику приложения требуются средства, позволяющие обнаруживать взаимозависимости правил и исключать возможные противоречия, ведущие к некорректности параллельной обработки.

Параллелизм внутри правил

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

·          for – позволяет выполнять определенные действия для объектов одного типа. Например, можно параллельно выводить заключение о состоянии любого из насосов (pump), присутствующих в системе:

for any pump

if the power of the pump is off and the flow of the pump > 0.001

then conclude that the condition of the pump is dripping

(для любого насоса, если питание насоса выключено и поток насоса больше 0.001, то заключить, что состояние насоса есть “протекающий”).

 every – позволяет выполнять определенные действия для некоторых атрибутов (параметров, переменных) объектов одного типа. Например, можно одновременно присваивать начальные или другие значения объему всех баков (tanks) системы:

conclude that the volume of every tank = 0

(заключить, что объем каждого бака равен 0).

local names (локальные имена) – задаются неявно посредством своего появления в общих правилах. Первое появление имени является его определением, а последующие – ссылки на представляемый им элемент. Использование локальных имен сокращает правила и делает их более наглядными, например:

For any pump P connected to any tank

if the flow of P < 1 and the flow of P > 0.001

then conclude that the condition of P is dripping

(символ P используется здесь как локальное имя для любого насоса).

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

Правила можно определять с использованием логической связки AND в консеквенте (заключении) правила, например:

whenever the actual-zn of M76 < the lowset of M76

then conclude that the status of M76 is lower

AND start show-mes (M76)

(правило означает, что всякий раз, как значение параметра actual-zn объекта M76 станет меньше нижней уставки, то правило активизируется и обе части консеквента будут выполнены параллельно, то есть будет сделано заключение, что параметр status объекта m76 понижен и запущена процедура выдачи сообщения show-mes).

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

Unconditionaly in order conclude that the status of Bolt1 is on

AND wait for 5 seconds

AND conclude that the status of Bolt1 is off

(в правиле все действия будут выполняться строго последовательно: устанавливается, что параметр status объекта Bolt1 (задвижка 1) есть on (открыто), затем ожидание 5 секунд и установка параметра status в состояние off (закрыто)).

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

Для организации логических и арифметических операций и их параллельной обработки (уровень внутреннего параллелизма) используются блоки AND (“И”), OR (“ИЛИ”), N TRUE (голосование), синхронизации и сдерживания.

Блок AND передает значение .true, если все его входы есть .true. Данному блоку необходимо дождаться значений на каждый вход, поэтому одновременное поступление значений на все входы минимизирует время ожидания. Блоку OR достаточно поступления на какой-либо один вход значения .true, в то время как другие входы могут быть не означены (unknown). Здесь параллелизм существенен в случае, когда все входы имеют значение false, так как иначе можно достаточно долго ожидать результата от рассматриваемого блока и тем самым задерживать контроль над протеканием процесса.

Пример информационной диаграммы потока, определяющей последовательно-параллельное выполнение блоков, приведен на рисунке 1, где блоки 1 и 4 – блоки суммирования, 2 – умножения, 3 – определения выхода за пределы значений, 5 – равенства и 6 – блок AND.

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

На данном уровне мы имеем внешний параллелизм. Обратимся теперь к внутреннему.

Блок N TRUE работает подобно функции голосования. Его результатом является .true, если N или более его входных значений есть .true. При простом последовательном отслеживании входных значений данного блока могут возникнуть проблемы, подобные использованию блока AND. Параллельная обработка входных данных позволяет минимизировать время вычисления результата.

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

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

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

Например, предположим, что Concurrency-window – 1 секунда. Если мы получаем значение в верхний входной порт и через полсекунды в нижний, блок полагает, что два значения приходят одновременно, сохраняет их в хронологии блока как пару и вычисляет новое значение. Однако, если при получении значения в один порт в другой порт значение приходит позже, чем через 1 сек, то это значение игнорируется. Такая тактика может привести к непозволительной задержке результата.

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

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

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

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

Исследования проводятся при финансовой поддержке РФФИ (проект 99-01-00049).

Список литературы

1. Башлыков А.А., Еремеев А.П. Экспертные системы поддержки принятия решений в энергетике. - М.: Изд-во МЭИ, 1994.

2. Попов Э.В., Фоминых И.Б., Кисель Е.Б., Шапот М.Д. Статические и динамические экспертные системы. - М.: Финансы и статистика, 1996.

3. Башлыков А.А., Вагин В.Н., Еремеев А.П. Экспертные системы поддержки интеллектуальной деятельности операторов АЭС //Вестник МЭИ. - М.: Изд-во МЭИ, 1995. - С. 27-36.

4. Еремеев А.П. Экспертные модели и методы принятия решений. - М.: Изд-во МЭИ, 1995.

5. Вагин В.Н., Еремеев А.П. Параллелизм в продукционных моделях представления знаний // Изв. АН СССР. Техническая кибернетика. - № 2. - 1994. - С. 48-55.

6. G2 Reference Manual. Version 3.0//Gensym Corp., Cambridge, MA, USA, 1993.

7. G2 Diagnostic Assistant Reference Manual. Version 1.1.// Gensym Corp ., Cambridge, MA, USA, 1995.

8. Еремеев А.П., Симонов Д.Н., Чибизова Н.В. Реализация прототипа системы поддержки принятия решений реального времени на основе инструментального комплекса G2 // Программные продукты и системы. - №3. - 1996. - С. 21-26.

9. Вагин В.Н., Еремеев А.П. Реализация концепции распределенного искусственного интеллекта и многоагентности в системах поддержки принятия решений на базе инструментального комплекса G2+GDA // Proc. of the Internat. Workshop Distributed Artificial Intelligence Multi-Agent Systems ”DAIMAS”97, June 15-18, 1997,St.-Peterburg, Russia. - С. 262-268.