Геловани В.А. и др. Интеллектуальные системы поддержки принятия решений в нештатных ситуациях

Подождите немного. Документ загружается.

6.1.

Анализ областей применения

ЭС

РВ

201

Продолжение таблицы 6 2

Провфка

непро гиворечивости

Графическое

представление БЗ

Прослеживание вывода

Построение графичес-

кого интерфейса с

пользователем

Форматирование

экрана

Графическое

моделирование

Пояснения типа

"Почему" "Как"

Полное объяснение

Помощь

при консультации

Синтаксическая

помощь

Открытость системы

ИНТЕРФЕЙС С ПОЛЬЗОВАТЕЛЕМ

Управление

экраном:

Строчное Меню

Графическое

Моделирование

Объяснения типа:

"Почему" "Как"

Помощь

Многоплановое

решение

202

Става 6.

Технология

разработки диагностических систем

Продолжение таблицы 6.2

Таблица 6.2 (Продолжение)

Сохранение примеров

Многоплановое реше-

ние с учетом сте-

пени уверенности

Что будет, если

МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ

Язык реализации

Операционная

система

MSD

СИСТЕМНЫЙ ИНТЕРФЕЙС

Совместимость

по языкам

по базе да1П1ых

КОМПАНИЯ

SAV

Arch.

& Eng

Тек-

now-

Icdge

LISP

MSDOS

LISP

dBASE-III

MSDOS

VMS

CPASCA

dBASE-III

Neui

Data

MSDOS•

VMS

-t-

Exsys,

CA intell

«Большие» инструментальные средства, напротив, привязаны к соб-

ственным ОС. При построении ЭС на реальных объектах возможно

изменение окружения, требующее изменения ОС и компиляторов, что

может оказаться серьезной проблемой для «больших» инструментариев.

Для этапа разработки ЭС «большие» инструментарии имеют намного

лучший интерфейс по сравнению с «малыми». Их интерфейс включает как

структурированные синтаксические редакторы, так и различные способы

отладки (трассировка, точки прерывания и т.п.).

В свою очередь «малые» инструментарии или совсем не имеют ре-

дактора (Stimulus), или имеют, но не настолько богатый, как в «больших»

инструментариях.

Для этапа выполнения интеграция ЭС проще для «малых» инстру-

.ментариев. В силу того, что символьная обработка и числовые вычисления

вынесены в код высокого уровня, создаваемого «малым» инструмента-

рием, интерфейс этапа выполнения в них обычно более эффективен.

6.1.

Анализ областей применения

ЭС

РВ 203

С другой стороны, уровень абстракции для символьного представления

может не быть такого высокого уровня, как в «больших» инструментариях.

«Большие» инструментарии обеспечивают возможность вызова внеш-

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

ций С, Рог1гап(однако не на любом аппаратном обеспечении).

Проблема открытости инструментария касается в большей степени

«больших» инструментариев, поскольку в «малых» большинство особен-

ностей создает сам разработчик. Из всех рассмотренных в данной главе

инструментариев G2 является наиболее закрытым, так как пользователь

данного инструмента не может добавлять LISP-профамм (G2 разработана

на LISPe) в систему, а процедуры написанные на С и Fortrane могут быть

вызваны не на всех машинах, на которых работает G2.

Касаясь вопроса сопровождения и технического уровня, следует от-

метить, что «большие» инструментарии имеют, как правило, лучшую

поддержку, поскольку за ними стоят большие организации. Некоторые

из них (по крайней мере G2) даже предлагают доставку при исполь-

зовании инструментария. В этом отношении к небольши.м разработкам

следует относиться с большей внимательностью и осторожностью и быть

вполне уверенным, что при необходимости может быть обеспечена соот-

ветствующая поддержка

Сравнение инструментариев по различным аспектам (совместимость,

интерфейс этапа разработки, интерфейс этапа выполнения, открытость,

сопровождение), а не только по части особенностей реального времени

обнаруживает значительную привлекательность небольших инструмента-

риев по сравнению с «большими».

В табл. 6.2 приведен краткий обзор характеристик других известных

средств разработки экспертных систем.

6.1.4. Основные требования и характеристики экспертных систем

реального времени СППР

В силу того, что ни один из инсгрументариев полностью не решает

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

приложений Поэтому при выборе или разработке инструментария для

практических приложений различные особенности (РВ-характеристики,

открытость, и др.) должны учитываться с равным весом. При таком под-

ходе отсутствие встроенных Р В-характеристик в «малых» инструментах,

требующее больших трудозатрат от разработчика на обеспечение этих

характеристик, компенсируется большей гибкостью и мобильностью по-

лучаемой системы.

Рассмотрим технологию построения ЭС, сочетающую в себе возмож-

ности и достоинства как «больших», так и «малых» инструментальных

средств.

Наиболее простым способом удовлетворения РВ-характеристик явля-

ется механизм «мгновенной фотографии». Например, несложная ЭС,

контролирующая протекание некоторого технологического процесса, от-

слеживает состояние объекта путем чтения и анализа показаний датчиков

и посылкой управляющих воздействий. Пример реализации механизма

«мгновенной фотофафии» приведен на рис. 6.3

204

Глава 6.

Технология

разработки диагностических систем

Начало

цикла

Прием показаний

датчиков

Анализ аоказшшй

датчиков

Корректировка БД,

если необходима

Рис.

6.3

При такой реализации

не

требуются

специальные механизмы, присущие ОС РВ.

На каждом цикле опроса показания датчи-

ков зачитываются

общую область данных

Затем специальная функция вызывается для

проверки отсутствия отклонений. Если

не-

обходима какая-либо реакция

на

возник-

шие отклонения, функция изменяет соот-

ветствующие параметры

общей области

данных

сообщает

об

этом головной про-

грамме. Этот механизм

не

полностью удо-

влетворяет требованиям реального времени.

Он подходит только для несложных процес-

сов

небольших систем. Здесь

нет

специ-

ального механизма управления асинхрон-

ными событиями. Обработка асинхронны-х

событий происходит аналогично нормаль-

ным событиям — чтением показаний дат-

чиков

начале каждого цикла. Гаранти-

рованное время отклика

такой системе

превышает время цикла опроса датчиков.

Наихудшим вариантом является ситуация,

когда резкое изменение показаний проис-

ходит сразу после чтения очередной порции

данных.

этом случае важное изменение

регистрируется только после начала следу-

ющего цикла. Такой механизм

не

позволяет системе контролировать

временные интервалы между «фотографиями». Очевидно, необходимы

специальные меры

для

решения этой проблемы. Наилучшим решением

является включение

проект механизмов, присущих ОС РВ.

К наиболее важным следует отнести реализацию следующих меха-

низмов:

• возможность выставлять

динамически изменять приоритеты задач

и осуществлять их прерьшания;

• должен присутствовать механизм обмена сообщениями между зада-

чами;

• необходим механизм блокировки

для

предотвращения прерываний

в критических ситуациях;

• механизмы взаимодействия

программами, написанными на других

языках высокого уровня;

• наличие развитых средств отладки.

В отличие

от

традиционных ЭС,

которых дается статическая уста-

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

ется протоколирование результатов

останов системы,

ЭС РВ

должна

быть способной получать новые порции информации, непрерывно

за-

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

6.2. Разработка спринт-технологии построения

СППР

РВ 205

типичной ситуация, при которой из-за возникновения новой ситуации

некоторые текущие процессы и выводы могут оказаться вторичными

и для предотвращения блокировки ЭС на длительное время должны

прерываться и удаляться самой системой в фоновом режиме.

Окружение ОС РВ постоянно изменяется. Поступающие значения

датчиков, также как выведенные факты, не остаются статичными в про-

цессе работы системы. Данные либо устаревают и теряют значимость

с течением времени, либо перестают быть осмысленными из-за событий,

происщедших в состоянии системы. При этом система должна обраба-

тывать немонотонность двух видов:

• заносить заключения в БД лишь в том случае, если они не противо-

речат текущему состоянию БД;

• удалять из БД утверждения, оказавшиеся ложными, вместе с их

записями зависимости.

Существенным фактором в ЭС РВ являются временные ограниче-

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

выдаваемые результаты еще необходимы и имеют смысл. Требования

к времени отклика могут изменяться не только от одного приложения

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

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

реа.1изации. Время отклика является вопросом не только вьпислительных

мощностей, но и организации системы. Система должна обладать такими

механизмами, которые обеспечивают ее реконфигурацию в соответствии

с динамикой происходящих процессов. Другими словами, система ре-

ального времени должна быть способна концентрировать свои ресурсы

на тех целях, которые являются более важными в данной конкретной

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

иметь модульную и иерархическую структуру.

Для придания модульности знаниям они могут быть связаны с атри-

бутами, которые имеют отношение к определенным событиям или со-

стояниям системы. Имея эти атрибуты, иерархическая структура знаний

достигается с помощью правил, которые решают, какие модули правил

проверять.

6.2. Разработка спринт-технологии построения СППР РВ

СППР РВ применяются для контроля непрерывных технологичес-

ких процессов и поддержки принятия решений инженерно-техническим

персоналом, осуществляющим эксплуатацию технологических объектов.

В данной работе в качестве объекта применения технологии выбрана

ЭС,

разрабатываемая для обработки данных систем контроля и диагно-

стики энергоблоков Калининской АЭС. ЭС, содержащая информацию

о допустимых режимах работы энергоблока, непрерывно контролиру-

ет характер протекания процесса, обеспечивает, в случае необходимо-

сти,

выдачу предупредительной сигнализации о нарушениях и советы

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

ями по управлению энергоблоком.

206 Глава 6.

Технология

разработки диагностических систем

СПРИНТ-технология разработки ЭДС РВ базируется на методах

и принципах, реализуемых в рамках проблематики ЭС. Развитие ЭС

для сложных технологических объектов, какими являются АЭС, обусло-

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

и управлением. Трудности эти объясняются невозможностью полностью

описать объект с непрерывным технологическим процессом традицион-

ными методами математического моделирования. Разработка ЭС, в свою

очередь, является сложной научно-технической задачей и требует при-

менения специальной технологии. Данная работа посвящена разработке

подобной технологии и созданию на ее основе ЭС РВ для обработки

данных системы контроля энергоблока Калининской АЭС.

6.2.1.

Концептуальная модель СПРИНТ-технологии

Рассмотрим концептуальную модель СПРИНТ-технологии, при этом

кратко опишем предметную область без ориентации на используемые

в дальнейшем программные и технические средства. Выделим инфор-

мацию, которая содержится и обрабатывается в проектируемой системе.

При этом рассмотрим проблемно-ориентированную и системно-незави-

симую структуру данных (т. е. независимую от конкретной СУБД, ОС

и аппаратного обеспечения).

Разработка ЭС РВ для эксплуатации энергоблоков АЭС обладает

целым рядом особенностей, основные из которых — слабая структури-

зация проблем предметной области и необходимость принятия решений

в условиях неполной и нечеткой исходной информации.

Непременным условием повышения качества и снижения себесто-

имости разрабатываемой ЭС является использование технологии, обла-

дающей гибкостью, мобильностью и адаптивностью к изменяющимся

условиям внешней среды. Технология поддерживает реализацию различ-

ных классов задач:

• простых, с полностью формализованными процедурами и понятны-

ми алгоритмами реализации;

• слабоструктурированных, содержащих неопределенную исходную

информацию и неизмеряемые компоненты;

• неформализуемых процедур, базирующихся на неструктурированной

информации, которая определяется высокой степенью неопределен-

ности (прогноз, пуско-наладочные операции).

СПРИНТ-технология поддерживает представление знаний в виде

правил, фреймов, семантической сети и имеет набор вспомогательных

инструментов для создания, тестирования и внедрения приложений.

Это позволяет описывать процессы принятия решений в открытых

и динамических проблемных областях.

Средством интеллектуализации разрабатываемых приложений явля-

ется возможность данной технологии расширять БД и БЗ не только

за счет увеличения числа контролируемых параметров, но и за счет

введения новых понятий, приписываемых к параметрам.

6.2. Разработка спринт-технологии построения

СППР

РВ

207

Ключевым моментом данной технологии является предоставляемая

пользователю возможность самостоятельно разбивать приложение

на

от-

дельные задачи, модули (источники знаний).

Это

достигается

за

счет

использования архитектуры Рабочей Области (РО). РО

—

часть системы,

которая используется для хранения данных

знаний

является доступ-

ной:

по

чтению

—

всем задачам

источникам знаний,

по

записи

—

задачам

и ИЗ,

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

Администратора

БД и БЗ.

Объекты, помещаемые

РО, могут являться измеряемыми, расчетными

данными, промежуточными результатами, гипотезами, вариантами

или

окончательными решениями.

Эксперт

р—•^ •]

Эксперт

к И-

лпр

~W Администратор

2:^

СРЕДСТВА КОММУНИКАЦИИ

СРЕДСТВА ПРИНЯТИЯ РЕШЕНИЙ, ПРОЕКТИРОВАНИЯ, АДАПТАШО!

СРЕДСТВА ИНТЕРПРЕТАЦИИ МОДЕЛЕЙ ЗНАНИИ СИСТЕМЫ (РАБОЧАЯ ОБЛАСТЬ)

Рис. 6.4

208 Глава 6. Технология разработки диагностических систем

Кроме того в РО могут создаваться и модифицироваться объекты,

специфицирующие возникновение определенных ситуаций в контроли-

руемом объекте. Это используется для активизации задач и источников

знаний, необходимых для решения наиболее важной задачи в данный

момент времени. Архитектура с РО, представленная на рис. 6.4, выбрана

еще и по следующим причинам:

Для успешного контроля протекания технологического процесса

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

от различных подсистем, а также истории их изменения РО позволяет

решить эту проблему.

Для поддержки принятия решения может потребоваться совокуп-

ность большого числа независимых экспертных знаний. Такие области

экспертных знаний могут легко интегрироваться при помощи РО.

Архитектура с общей РО обеспечивает возможность параллельной

обработки, что является особенно актуальным в системах реального

времени.

В общей РО могут помещаться гипотезы, обеспечивающие мно-

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

работать в ситуации неполноты информации.

6.2.2. Организация БЗ реального времени как средство поддержки

концептуальной модели СППР

Атомная электростанция как объект человеко-машинного управле-

ния состоит из нескольких энергоблоков. Каждый энергоблок техноло-

гически представляется структурой, представленной на рис. 6.5.

Реакторное отделение

Машшпюе отделение

Реактор

1 контур

Вспомогательные

технологические системы

Турбина

Генератор

Вспомогательные технологические

системы

Рис.

6.5

В этой структуре элементы оборудования, такие, как реактор, 1-й

контур, турбина и генератор отнесены к классу основного технологичес-

кого оборудования Обеспечивающие работу основного технологического

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

ного оборудования

Очевидно, что технологический объект, подвергающийся диагно-

стике со стороны системы поддержки принятия решений, может иметь

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

следить которые в одной базе знаний достаточно трудно. Поэтому логично

6 2. Разработка спринт-технологии построения

СППР

РВ

209

Рис.

6.6

разбить сложный объект на бо-

лее простые составляющие и ор-

ганизовать анализ их состояния.

Иными словами, в СПРИНТ-тех-

нологии применен метод деком-

позиции энергоблока на диагно-

стические компоненты — техно-

логические системы. Объект раз-

бивается на несколько функци-

онально-законченных подсистем.

Далее на каждую отдельную под-

систему заводятся своя база зна-

ний и база данных (рис. 6.6). В ре-

зультате этих действий появляет-

ся возможность работы с каждой

отдельной подсистемой отдельно.

Данное разбиение позволяет распараллелить обработку знаний, что

особенно важно в системах реального времени.

База знаний и база данных, связанные с объектом, служат для объ-

единения информации от подсистем или обработки ситуаций, в которых

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

Анализ существующих способов представления знаний показал, что

для задания и хранения знаний в базах знаний реального времени лучше

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

говоря, знания в системах реального времени должны храниться в виде:

ЕСЛИ «условие» ТО «действие 1* ИНАЧЕ «действие 2».

На выбор этой модели при организации БЗ реального времени

повлияли следующие причины:

• естественная простота записи;

• простота и наглядность в понимании;

• специфика задачи — унифицируемость данной модели очевидна —

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

ности функционально-логические юаимосвязи между отдельными

частями промышленного объекта;

• гибкость и струкгурируемость правил, их информационная емкость;

• возможность иерархической организации баз знаний, что особенно

важно при описании технологических объектов, структуру которых

можно было бы формализовать в терминах иерархии;

• возможность построения «быстрых» алгоритмов прямого и обратного

вывода на данной модели;

• возможность трансляции ее

двоичный исполняемый код, интерпре-

тация которого в режиме реального времени обеспечивает наимень-

шие временные затраты по сравнению с другими видами предста-

вления знаний (обеспечивается степенная сходимость к результату);

• возможность о[1еративного трассирования работы механизма вывода.

210 Глава 6.

Технология

разработки диагностических систем

6.2.2.1.

Продукционные правила как средство описания моделей

знаний реального времени

В данной системе формально продукция записывается в следующем

виде:

«Номер»: ЕСЛИ «Условие» ТО «Действие 1», «Действие 2»,

где «Номер» — служит для придания каждому правилу, входящему в базу

знаний, уникального адреса (идентификатора). Цель такой адресации --

обеспечить механизму вывода возможность условных и безусловных пе-

реходов от одного правила к другому в процессе вывода. Дело в том,

что в отличие от классического механизма вывода, где идет обычный

перебор правил до первого, у которого условие истинно, и выбор пра-

вила, вообще говоря, недетерминирован, в системе и при выполнении,

и при невыполнении условной части правила должно быть определено

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

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

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

каковым и является «номер» правила. Обеспечение способности пере-

хода, возможно, не является «врожденным» свойством продукционной

модели представления знаний, однако «вживление» данного свойства

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

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

такое важное свойство механизма вывода, как динамическое добавление

правил в базу знаний по мере его работы с правилами. Динамическое

добавление означает на практике многопроходность механизма вывода,

что также ведет к увеличению времени поиска. Именно поэтому меха-

низм вывода работает с жесткими моделями промышленных объектов.

Более того, здесь же заложена возможность досрочного окончания работы

с базой знаний.

«Условие», как указывалось выше, — есть правильно построенная

формула, суть которой составляют атомы, соединенные между собой

логическими операциями конъюнкции, дизъюнкции и отрицания.

Атомы — есть простые логические выражения, значения которых

также могут принимать только значения: ИСТИНА или ЛОЖЬ. Основой

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

Каждый датчик, в зависимости от типа, имеет свои нормальные (до-

пустимые) значения. К примеру, аналоговые — предельные верхнюю

и нижнюю уставки, дискретные — нормальные положения. Так вот атом

как раз, в большинстве случаев, есть выражение сравнения текущего

значения датчика с допустимым. Здесь также допустимы операции срав-

нения значений с константами, различные арифметические операции,

использование стандартных математических функций. Разрешенными

операциями являются следующие:

• Операции сравнения: «>», «<», «>=», «<=», «=», «! =».

• Арифметические операции: «+», «—», «*», «/», «%», «"».

• Использование скобок для задания порядка операций