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

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

6.1.

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

ЭС

РВ 181

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

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

висимости;

• многошаговость процесса управления, когда содержание каждого

шага не может быть заранее однозначно определено.

К причинам недостаточного развития ЭС РВ следует отнести также

отсутствие проработанной технологии проектирования и систематизиро-

ванного, четкого инструментария ддя разработки.

6.1.

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

и технологий их разработки

Интерес специалистов к ЭС из различных областей вызван по край-

ней мере тремя причинами:

ЭС ориентированы на решение широкого круга задач в неформа-

лизованных областях.

С помощью ЭС специалисты, не знающие программирования,

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

ЭС при решении практических задач достигают результатов не ус-

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

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

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

технологии

Исходя из этих результатов, обосновывается необходимость ком-

плексного рассмотрения вопросов технологии разработки ЭС РВ, на-

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

проектирования ЭС.

6.1.1.

Обзор областей применения ЭС РВ в энергетике

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

на АЭС, связанных с отказами оборудования

[115].

Например, на АЭС

в Японии количество таких отказов снизилось с 4 до 0,6 на реактор в год.

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

ративного персонала, остается приблизительно на неизменном уровне.

Сейчас около 50% нарушений на АЭС вызываются действиями персонала.

Это обстоятельство делает решение задач взаи.модействия человека с ма-

шиной не менее важной проблемой, чем проблема усовершенствования

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

В связи с актуальностью этих проблем Це}1тр Искусственного интел-

лекта (AI) Японского информационно-обрабатывающего исследователь-

ского центра (JIPDEC) в апреле 1986 г. провел исследование состояния

дел

[115].

Из этой публикации можно сделать вывод о том, что наиболь-

шее число разработок ЭС относится к таким отраслям, как строительство,

химическая и нефтеперегонная промышленность, электротехническое

машиностроение. При этом на долю энергетики приходится приблизи-

тельно 5% разработок, включающих в себя системы.

182 Глава 6.

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

• обеспечения работы ядерной электростанции (фирма Кансай Элек-

трик Пауэр);

• диагностики и системы восстановления энергетических систем (фир-

ма Киуцу Электрик Пауэр);

• диагностики электростанций (фирма Токио Электрик Пауэр);

• обеспечения руководства и принятия решений (Научно-исследова-

тельский институт Номура);

• обеспечения работы ядерной электростанции (фирма Мицубиси Ато-

мик Пауэр Индустриз).

Одной из таких ЭС является система LDIS, предназначенная для

диагностирования реактора с кипящей водой. Система LD1S строится

на базе портативной 16-битовой ЭВМ «Тосиба».

Методы ЭС используются для создания средств поддержки принятия

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

ния определенных функций безопасности. Такая ЭС построена в США

(система SPC). Данная система минимизирует нежелательные пос;>ед-

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

исследовательском институте электроэнергетики (США) сов.местно

с фирмой TAI начата разработка ЭС для классификации уровня аварий-

ных действий на основе определения правил, закладываемых в БЗ. Про-

тотип данной системы называется CEALMON. При нормальных условиях

эксплуатации на специальном дисплее системы отображается перечень

параметров АЭС, требующих внимания оператора.

По запросу оператора относительно отклонений от нормы какого-

либо параметра, ЭС а^1ализирует класс аварийной ситуации или под-

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

режим для вьщачи рекомендаций и ответов на изменение состояния АЭС

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

реактор моделировался на аналоговой ЭВМ, а ЭС — на цифровой.

Другим примером является ЭС поддержки оператора БЩУ, реали-

зованная на АЭС «Саванна Ривер» (США). Эта система, работающая

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

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

ализации не согласующихся между собой действий. Данная ЭС может

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

ния операций при эксплуатации АЭС.

Для анализа отказов по общим причинам в США создана ЭС под-

держки оператора SQU1MP, реализованная в ЛИСП-среде. В качестве

входной информации в ЭС задаются деревья событий, состояния ЭБ,

перечень событий, аварийные состояния. SQUIMP позволяет определить

вероятность путей развития событий, а также связанный с ними риск.

В Японском институте по исследованию атомной энергии (JAEPI)

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

ний, основанную на технике представления знаний, с целью оказания

экстренной помощи в случае повреждений АЭС. Было показано, что для

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

6.1.

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

ЭС

РВ 183

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

изменяющиеся во времени данные.

Для манипулирования изменшощимися во времени данными приме-

нялся следующий подход-

— програм.мы динамического моделирования вводятся в БЗ для

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

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

В том же институте была разработана диагностическая система

DISKET с новым механизмом умозаключений «IEPIAS».

данной систе-

ме динамические явления учитываются путем расширения представлений

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

разделение БЗ на несколько блоков знаний.

6.1.2. Обзор архитектур построения ЭС РВ в энергетике

Для эффективного решения одной из основных своих задач ЭС РВ

должна обладать рядом возможностей, таких как:

• описание оперативных знаний с помощью Я

ПОЗ;

• накопление, анализ, обобщение и хранение оперативных знаний;

• интерпретация в реальном времени поступающей информации в тер-

минах имеющихся знаний;

• вывод знаний, неявно представленных в ранее накопленных знаниях

(архивах событий, ситуаций);

• решение задач путем обработки информации из БЗ одновременно

с процессом управления;

• поддержка «дружественного» интерфейса с пользователем.

Термин «оперативные знания» является ключевым в теории и прак-

тике ЭС и представляет собой дальнейшее развитие понятия «знание»,

при этом существенно от него отличаясь. Обычно отмечают по крайней

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

данных временных рамках, наличие вариабельных классификационных

связей и ситуативных отношений [22, 82].

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

метную область оперативной деятельности ЛПР, а БД — совокупность

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

ментов времени. Типовая архитектура ЭС приведена на рис.

6.1

[22].

При настройке ЭС на решение задач в конкретной проблемной обла-

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

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

лучения заключений. В табл.

6.1

приведены степени важности различных

методов и моделей в зависимости от решаемых задач.

Так, например, система DISKET, разработанная в институте JAERI

(Япония), состоит из механизма умозаключений и базы знаний. Механизм

умозаключений распознает причину и тип повреждения с помощью БЗ

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

механизма состоит в том, что он позволяет рассматривать изменяющиеся

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

184

Глава 6.

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

Извлечение знаний

Модель знаний

управляемой системы

(модель предметной

области)

Оперативная

оценка текущих

ситуаций

•Р

Поиск плана

действий

(управляющих

решений)

Принятие

решений

(выбор плана

действий)

Информационное

состояние объекта

управления

Реализация

решений

Рис.

6.1

текущее состояние, но и предысторию прошлых состояний основных

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

явления повреждения р>еактора в процессе логического вывода.'

• БЗ системы DISKET состоит из 2-х частей:

-я часть

—

определение

данных,

в которую входят знания (гипотезы)

о причинах повреждений и последствиях.

2-я часть

—

определение правил, в которую входит знание зави-

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

правил.

В ЦНИИКА и ТАСНО-БИТ проводились работы по созданию, вне-

дрению и эксплуатации интеллектуальных систем поддержки при-

нятия решений при управлении энергосистемами (объединенное

дискретное управление Урала) и энергоблоками АЭС (Калининская,

Нововоронежская АЭС) (СПРИНТ). Архитектура данного класса

СППР представляет собой композицию архитектур средств: распре-

деленного сбора данных, распределенного хранения данных, пе-

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

принятия решений.

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

зе стандарт}1ых терминалов связи с объектами. Каждый терминал

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

стоянии которого он собирает и которым управляет.

6.1.

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

ЭС

РВ

185

Важность различных атрибутов оболочек ЭС

для конкретных функциональных применений

Ткблица 6.1

- очень

важен

менее

важен

МЕТОД ПОЛУЧЕНИЯ

ЗАКЛЮЧЕНИЯ

Диаг-

ности-

ка

Анализ

данных

интер-

прета-

ция

Проек-

тиро-

вание

синтез

Пред-

ска-

зание

моде-

лиро-

вание

Кон-

суль-

тация

обу-

чение

Пла-

ниро-

вание

Управ-1

ление

1!Обратный

вывод

Прямой

]вывод

I!Гипотетическое

заключение

I"Классная

доска"

МОДЕЛЬ ОБЪЕКТА

R БАЗЕ ЗНАНИЙ

Фреймы

Сети

]фреймов

!Семантические

объекты

сети

Пары

III

параметр-значение

| | ] | j

Логика

i 1 11 i

Продукции

II II 1

Достоверность

| - 1 ~ 1

.___;__.

1 1 1 - i

-"|---"|-р|"

—+

ДЕЙСТВИЯ

;правила

примеры

процедуры

•- +

186 Глава 6.

Технология

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

• Комплекс средств распределенного хранения данных строится на ос-

нове системы управления распределенными базами данных Аспект

распределенности требует разработки метода интеграции инфор-

мации, которая накапливается в локальных базах данных (ЛБД)

Проблема интеграции решается путем введения в РБД общего язы-

ка определения данных, независимого от структур данных ЛБД

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

локальных БД в РБД.

Принципы интеграции информации в СУРБД означают, что ответ

на запрос либо может быть найден в ЛБД пункта обработки, либо он

должен находиться в удаленной ЛБД. В последнем случае в работе

СУРБД принимают участие средства передачи информации.

• Комплекс средств передачи информации базируется на элементах се-

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

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

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

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

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

• Комплекс средств распределенной обработки информации строится

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

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

ня представления знаний и соответствующего перехода от СУБД

к СУБЗ.

В памяти ЭВМ новому уровню соответствует своя логическая модель

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

позволяет логически упорядочить связи всех элементов информации

и создавать более эффективные планировщики процессов поиска

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

Структура технических средств СППР «СПРИНТ-РВ» применитель-

но к энергоблокам АЭС приведена на рис. 6.2. Здесь на блочном щите

управления (БЩУ) на обобщенной мнемосхеме энергоблока (ЭБ) ото-

бражается состояние энергоблока. Управление — после принятия реше-

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

с экранов мониторов системы СПРИНТ.

Средства оперативного контрюля состояния энергоблока и интеллек-

туальной поддержки принятия решений СПРИНТ размещены на индиви-

дуальных автоматизированных рабочих местах операторов (АРМ БЩУ):

начальника смены энергоблока (НСБ), заместителя начальника смены

энергоблока (ЗНСС), старшего инженера управления реактором (СИУР)

и старшего инженера управления турбиной (СИУТ). У СИУР в состав

его индивидуального АРМ входят также средства системы внутриреактор-

ного контроля (СВРК) и системы поддержки параметров безопасности

(СППБ). Последняя реализуется на базе «СПРИНТ-технологии».

Информация о состоянии энергоблока, включая систему управления

защит (СУЗ), исполнительные механизмы и параметры рабочей среды,

собирается в оперативную базу данных СППР через дублированную ло-

кальную вычислительную сеть, шлюз-ЭВМ контроллерными средствами

6.1.

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

ЭС

РВ

187

НИ

5 у

l»-..l,

. I- о X

I '^j ихл

(If

30Q.

Рис. 6.2

188 Глава 6.

Технология

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

через каналы управляющих систем безопасности (УСБ), систем нормаль-

ной эксплуатации реакторного отделения (НЭ РО), нормальной эксплу-

атации турбинного отделения (НЭ ТО), систем технической диагностики

(ССТД), автоматизированной системы радиационного контроля (АСРК),

системы контроля и диагностики турбины (СКИД).

Информация о состоянии энергоблока попадает также в локальный

кризисный центр (ЛКЦ АЭС) и локальную вычислительную сеть обще-

станционного уровня.

двух последних пользователи оснащены АРМами

СПРИНТ.

6.1.3. Обзор технологий разработки ЭС РВ для СППР

Разработка ЭС является сложным, трудоемким процессом, требую-

щим нескольких человеко-лет. По оценкам специалистов этот процесс

может занимать от нескольких месяцев до нескольких лет

[123].

В лите-

ратуре по традиционным ЭС [123] отмечается сложившаяся технология

их разработки, включающая следующие этапы:

• этап идентификации, на котором осуществляется определение за-

дач,

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

которому предстоит решать эти задачи. Определяются эксперты и ка-

тегории пользователей;

• этап концептуализации включает в себя проведение содержательного

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

основных понятий и их взаимосвязей;

• на этапе формализации определяются способы представления зна-

ний, формализуются основные понятия и выбираются инструмен-

тальные средства для реализации;

• на этапе выполнения программируются компоненты системы, кон-

струируется прототип ЭС и наполняется БЗ;

• на этапе тестирования происходит выяснение правильности работы

системы, дееспособности применяемых стратегий поиска решений

и выявление дополнительной информации (метазнаний), которая

может улучшить качество получаемого решения;

• на этапе опытной эксплуатации во взаи.модействии с конечным

пользователем дается заключение о пригодности ЭС для решения

поставленных задач.

При такой многоэтапности и сложности процесса особую роль игра-

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

струментов для подцержки ЭС. Различные инструментальные средства

реализуют различные подходы к близким проблемам. Условно можно раз-

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

[157].

«Боль-

шие» инструментальные средства включают более одного механизма вы-

вода и представления знаний и имеют хорошо развитое окружение. Такие

инструменты используют преимущества специальных ОС. К этой ipynne

инструментариев относятся системы: Muse, Chronos, IF/PROmLOG, G2.

Каждый их них представляет собственную философию проектирования

6.1.

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

ЭС

РВ 189

Инструментальная система Muse состоит из набора языков представле-

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

для создания, тестирования и внедрения приложений. Пакет включает

редактор и многооконную среду для контроля в процессе реализации.

Суть архитектуры Muse заключается в том, что важные события

и цели располагаются условно на вспомогательной части рабочей памя-

ти,

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

и отфильтрованных данных. После обработки они посылаются на цен-

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

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

В системе Muse возможны как прямые, так и обратные цепи правил

(при более частом использовании прямых). Знания представляются либо

в виде правил, либо в виде фреймов. Вывод одного источника знаний

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

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

Muse, являются либо рабочие станции SUN, либо МС680хх. В настоящее

время разрабатывается поддержка для VAX VMS.

Инструментальная среда Chronos основана на правилах и задумана

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

непрерывным приемом данных. Она имеет развитый интерфейс, включа-

ющий «мышь» и меню, редактор правил и показ трассировки исполнения.

Сам инструментарий Chronos написан на языке ADA, однако знания этого

языка не требуется для использования Chronos.

Механизм вывода в данной системе является чисто прямым, по-

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

механизм вывода запускает задачи 3-х уровней приоритета. Высщий уро-

вень приоритета предназначен для приема внешних данных. Задачи 2-го

уровня приоритета проверяют, удовлетворяют ли какие-нибудь правила

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

фактов. Кроме обычных правил «если то» могут быть использованы пра-

вила «пока». Все правила исполняются в соответствии с приоритетом

и правило может быть объявлено непрерывным. Каждому факту в базе

фактов приписываются 4 време1шых атрибута:

дата создания

дата запуска

дата завершения

время входа в базу фактов

время, в которое факт был подтвержден

время, после которого факт перестал быть

значимым

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

незначимый факт удаляется

Chronos работает на PC AT (с математическим сопроцессором) и со-

вместимых с ним компьютерах, на VAX и UNIX-станциях. Chronos

разработан двумя французскими кампаниями Sagem и Euristic Systems.

Инструментальное средство IF/PROmLOG является версией ПРО-

ЛОГа, спроектированной в основном для РВ-окружения. ПРОЛОГ -^

90 Глава 6.

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

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

вилах и фактах. Он базируется на логике предикатов 1-го порядка.

Интерпретатор ПРОЛОГа включает механизм вывода, который использу-

ет обратный вывод для описания заключений от БЗ. Для удовлетворения

требованиям реального времени (РВ) IF/PROmLOG предлагает прямой

доступ к функциям ОС:

• управление задачами;

• семафоры для синхронизации задач;

• сообщения между задачами;

• управление прерываниями.

Имеется возможность также вызывать функции, написанные на ас-

семблере или языках типа «С» или «Fortran».

Инструментальная система G2 предназначена для очень больших

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

раметров одновременно. Возможности управления знаниями включак}т

развитый оконный интерфейс

«мышью» и всплывающими меню, графи-

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

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

большими и сложными БЗ. В состав БЗ может включаться документа-

ция. Для представления знаний G2 использует различные типы правил,

объекты и динамические модели.

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

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

вызваны несколькими способами:

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

• правила, связанные с определенным узловым объектом или узловым

классом, могут быть объединены узловым выражением;

• все правила, принадлежащие к категории определенных пользовате-

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

В G2 имеется имитатор, являющийся инструментом для модели-

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

переменных. В имитаторе реализована алгебра, производные 1-го порядка

и дифференциальные уравнения.

В G2 имеются вспомогательные on-line модули, которые обеспечи-

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

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

G2 реализована на LISP и работает на широком диапазоне машин,

включая PC

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

меньшее количество возможностей и более ограниченное окружение.

Важной особенностью инструментариев этой группы является то, что

они генерируют исходный код высокого уровня. Они не полностью ис-

пользуют какую-либо специфическую ОС, вследствие чего не могут иметь

улучшенные особенности, связанные с аспектом реального времени. Та-

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