Малышенко А.М. Лекции по искусственному интеллекту и нейросетевому управлению - файл n11.doc

Малышенко А.М. Лекции по искусственному интеллекту и нейросетевому управлению
скачать (859 kb.)
Доступные файлы (12):
n1.doc203kb.16.01.2009 00:58скачать
n2.doc240kb.18.02.2009 11:26скачать
n3.doc44kb.22.01.2009 01:05скачать
n4.doc85kb.22.01.2009 04:22скачать
n5.doc107kb.26.01.2009 01:06скачать
n6.doc68kb.13.01.2009 01:26скачать
n7.doc82kb.29.01.2009 00:52скачать
n8.doc440kb.06.02.2009 15:29скачать
n9.doc347kb.12.02.2009 09:49скачать
n10.doc244kb.19.02.2009 02:30скачать
n11.doc337kb.26.02.2009 01:05скачать
n12.doc91kb.19.03.2009 02:41скачать

n11.doc

Лекция 6

Предпочтительное использование экспертных систем

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

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

1) существуют эксперты в данной области, которые решают задачу значительно лучше, чем начинающие специалисты;

2) эксперты сходятся в оценке предлагаемого решения, иначе нельзя будет оценить качество разработанной ЭС;

3) эксперты способны вербализовать (выразить на естественном языке) и объяснить используемые ими методы, в противном случае трудно рассчитывать на то, что знания экспертов будут "извлечены" и вложены в ЭС;

4) решение задачи требует только рассуждений, а не действий;

5) задача не должна быть слишком трудной (т. е. её решение должно занимать у эксперта несколько часов или дней, недель, но не месяцы);

6) задача хотя и не должна быть выражена в формальном виде, но всё же должна относиться к достаточно "понятной" и структурированной области, т.е. должны быть выделены основные понятия, отношения и известные (хотя бы эксперту) способы получения решения задачи;

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

Использование ЭС в данном приложении может быть и возможно, но не оправдано.

Применение ЭС может быть оправдано одним из следующих факторов:

● решение задачи принесет значительный эффект, например экономический;

● использование человека-эксперта, а не ЭС, невозможно либо из-за недостаточного количества экспертов, либо из-за необходимости выполнять экспертизу одновременно в различных местах;

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

● использование ЭС целесообразно в тех случаях, когда эксперт не успевает в допустимое время принять решение;

● использование ЭС целесообразно при необходимости решать задачу в окружении, враждебном для человека.

Приложение соответствует методам ЭС,

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

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

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

3) задача должна быть достаточно сложна, чтобы оправдать затраты на разработку ЭС. Однако она не должна быть чрезмерно сложной (решение занимает у эксперта часы, а не недели), чтобы ЭС могла ее решать;

4) задача должна быть достаточно узкой, чтобы решаться методами ЭС, и практически значимой.

По сложности решаемых задач различают:

По стадии создания различают:

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


Разработка ЭС связана с определенными трудностями, которые необходимо хорошо знать, так же как и способы их преодоления. Рассмотрим подробнее эти проблемы.

  1. Проблема извлечения знаний экспертов. Ни один специалист никогда просто так не раскроет секреты своего профессионального мастерства, свои сокровенные знания в профессиональной области. Он должен быть заинтересован материально или морально, причем, хорошо заинтересован. Никто не хочет рубить сук, на котором сидит. Часто такой специалист опасается, что, раскрыв все свои секреты, он будет не нужен компании. Вместо него будет работать экспертная система. Избежать этой проблемы поможет выбор высококвалифицированного эксперта, заинтересованного в сотрудничестве.

  2. Проблема формализации знаний экспертов. Эксперты-специалисты в определённой области, как правило, не в состоянии формализовать свои знания. Часто они принимают правильные решения на интуитивном уровне и не могут аргументированно объяснить, почему принято то или иное решение. Иногда эксперты не могут прийти к взаимопониманию (фраза «встретились два геолога, у них было три мнения» – не шутка, а реальная жизнь). В таких ситуациях поможет выбор эксперта, умеющего ясно формулировать свои мысли и легко объяснять другим свои идеи.

  3. Проблема нехватки времени у эксперта. Выбранный для разработки эксперт не может найти достаточно времени для выполнения проекта. Он слишком занят. Он всем нужен. У него есть проблемы. Чтобы избежать этой ситуации, необходимо получить от эксперта, прежде чем начнется проект, согласие тратить на проект время в определенном фиксированном объеме.

  4. Правила, формализованные экспертом, не дают необходимой точности. Этой проблемы можно избежать, если решать вместе с экспертом реальные задачи. Не надо придумывать «игрушечные» ситуации или задачи. В условиях задач нужно использовать реальные данные, такие как лабора-торные данные, отчеты, дневники и другую информацию, взятую из практических задач. Постарайтесь говорить с экспертом на одном языке, используя единую терминологию. Эксперт, как правило, легче понимает правила, записанные на языке, близком к естественному, а не на языке типа LISP или PROLOG.

  5. Недостаток ресурсов. В качестве ресурсов выступают персонал (инженеры знаний, разработчики инструментальных средств, эксперты) и средства построения ЭС (средства разработки и средства поддержки). Недостаток благожелательных и грамотных администраторов порождает скептицизм и нетерпение у руководителей. Повышенное внимание в прессе и преувели-чения вызвали нереалистические ожидания, которые приводят к разочарова-нию в отношении экспертных систем. ЭС могут давать не самые лучшие решения на границе их применимости, при работе с противоречивыми знаниями и в рассуждениях на основе «здравого смысла». Могут потребоваться значительные усилия, чтобы добиться небольшого увеличения качества работы ЭС.

Экспертные системы требуют много времени на разработку. Так, создание системы PUFF для интерпретации функциональных тестов легких потребовало 5 человеко-лет, на разработку системы PROCPECTOR для разведки рудных месторождений ушло 30 человеко-лет, система XCON для расчета конфигурации компьютерных систем на основе VAX 11/780 потребовала 8 человеко-лет. ЭС последних лет разрабатываются более быстрыми темпами за счет развития технологий ЭС, но проблемы остались. Удвоение персонала не сокращает время разработки наполовину, потому что процесс создания ЭС – это процесс со множеством обратных связей. Все это необходимо учитывать при планировании создания ЭС.

  1. Неадекватность инструментальных средств решаемой задаче. Часто определенные типы знаний (например, временные или пространственные) не могут быть легко представлены на одном языке программирования задач (ЯПЗ), так же как и разные схемы представления (например, фреймы и продукции) не могут быть достаточно эффективно реализованы на одном ЯПЗ. Необходим тщательный анализ решаемых задач, чтобы определить пригодность предлагаемых инструментальных средств и сделать правильный выбор.

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

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

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

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

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

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



На этапе идентификации определяются задачи, которые подлежат решению, выявляются цели разработки, определяются эксперты и типы пользователей.

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

На этапе формализации выбираются инструментальные средства (ИС) и определяются способы представления всех видов знаний, формализуются основные понятия, определяются способы интерпретации знаний, моделируется работа системы, оценивается адекватность целям системы зафиксированных понятий, методов решений, средств представления и манипулирования знаниями.

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

Методология построения экспертных систем


Рассмотрим методику формализации экспертных знаний на примере создания экспертных диагностических систем (ЭДС).

Целью создания ЭДС является определение состояния объекта диагностиро-вания (ОД) и имеющихся в нем неисправностей.

Состояниями ОД могут быть: исправно, неисправно, работоспособно. Неис-правностями, например, радиоэлектронных ОД являются обрыв связи, замыкание проводников, неправильное функционирование элементов и т.д.

Число неисправностей может быть достаточно велико (несколько тысяч). В ОД может быть одновременно несколько неисправностей. В этом случае говорят, что неисправности кратные.

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

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

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

  1. Выделить множество всех неисправностей ОД, которые должна различать ЭДС.

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

  3. Для выбранных параметров следует выделить информативные значения или информативные диапазоны значений, которые могут быть как количественными, так и качественными. Например, точные количественные значения могут быть записаны в виде: задержка 25 нс, задержка 30 нс и т.д. Количественный диапазон значений может быть записан: задержка 25--40 нс, 40--50 нс, 50 нс и выше. Качественный диапазон значений может быть записан, например, в виде: индикаторная лампа светится ярко, светится слабо, не светится.

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

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

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

Таблица 1.1. Диагностические правила

Номер

Р1

Р2

Р3

Диагноз

Вероятность диагноза

Примечания

1




+++




Неисправен блок А1

0.95




2

12-15

+




Неисправен блок А2

0.80




Для записи правил с учетом изменений по времени следует ввести еще один параметр Р0 – время (еще один столбец в таблице). В этом случае диагноз может ставиться на основе нескольких строк таблицы, а в графе Примечания могут быть указаны использованные тесты. Диагностическая таблица в этом случае представлена в таблице 1.1.

Таблица 1.2. Динамические диагностические правила

Номер

Р0

Р1

Р2

Р3

Диагноз

Вероятность диагноза

Примечания

1

12:00

+

+

+







тест Т1

2

12:15

++

++

+

Неисправен блок А3

0.90




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

ЕСЛИ: Р2 = 1

ТО: тест = Т1, Т3, Т7,

где Т1, Т3, Т7 – тестовые процедуры, подаваемые на ОД при активизации (срабатывании) соответствующей процедуры.

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

Рассмотрим экспертную систему диагностирования (ЭСД) цифровых и цифроаналоговых устройств [83], [84], [85], в которой использовались системы продукций и фреймы, а также прямая и обратная цепочка рассуждений одновременно. В качестве объекта диагностирования (ОД) в ЭСД могут использоваться цифровые устройства (ЦУ), БИС, цифро-аналоговые устройства. На рис. 1.5 показано, что такая ЭСД работает совместно с автоматизированной системой контроля и диагностирования (АКД), которая подает в динамике воздействия на ОД (десятки, сотни и тысячи воздействий в секунду), анализирует выходные реакции и дает заключение: годен или не годен. В случае, если реакция проверяемого ОД не соответствует эталонным значениям, то подключается основанная на знаниях подсистема диагностирования. ЭСД запрашивает значения сигналов в определенных контрольных точках и ведет оператора по схеме ОД, рекомендуя ему произвести измерения в определенных контрольных точках или подтвердить промежуточный диагноз, и в результате приводит его к месту неисправности. Исходными данными для работы ЭСД являются результаты машинного моделирования ОД на этапе проектирования. Эти результаты моделирования передаются в ЭСД на магнитных носителях в виде тысяч продукционных правил. Движение по контрольным точкам осуществляется на основе модели, записанной в виде сети фреймов для ОД.




Рис. 1.5.  Общая структура экспертной системы диагностирования

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

ЭСД накапливает вероятностные знания о конкретных неисправностях с целью их использования при логическом выводе. При движении по дереву поиска решений на очередном шаге используется критерий – максимум отношения вероятности (коэффициента уверенности) постановки диагноза к трудоемкости распознавания неисправности. Коэффициенты уверенности автоматически корректируются во время работы ЭСД при каждом подтверждении или не подтверждении диагноза для конкретных ситуаций диагностирования. Трудоемкости элементарных проверок первоначально задаются экспертом, а затем автоматически корректируются в процессе работы ЭСД.

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

Инструментальное средство (ИС) для создания экспертной системы реального времени (ЭС РВ) впервые выпустила в 1985 г. фирма Lisp Machine. Это ИС называлось Picon, и оно исполнялось на символьных ЭВМ Symbolics.

Его успех на рынке привел к тому, что группа ведущих разработчиков Picon образовала в 1986 г. частную фирму Gensym, которая, значительно развив идеи, заложенные в Picon, выпустила в 1988 г. ИС под названием G2 версии 1.0. Ныне функционируют версии 4.1 и 5.0, готовится к выпуску версия 6.0.

Ряд других фирм с отставанием от Gensym на 2–3 года начали создавать (или пытаться создавать) свои ИС для экспертных систем реального времени.

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

Пока наиболее продвинутым ИС, безусловно, остается G2 (Gensym, США), за ним со значительным отставанием (реализовано менее 50% возможностей G2) следуют RT Works фирмы Talarian (США), COMDALE/C (Comdale, Канада), COGSYS (SC, США), ILOG Rules (ILOG, Франция).



Каждая из этих систем позиционируется её разработчиками как главная, а не в качестве “одной из”, что в значительной степени затрудняет их совместное использование.

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

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

Попытка разработать интеллектуальный компонент для своего продукта на принципах “натурального хозяйства” представляется сегодня таким же анахронизмом, как и разработка собственной реляционной СУБД вместо использования Oracle или Informix.

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

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

В настоящее время по утверждениям специалистов более 50 % ЭС создаются с использованием в качестве инструментального средства именно G2.

Программный продукт G2 создан и поддерживается фирмой Gensym Corp., которая является общепризнанным лидером в области создания динамических экспертных систем реального времени. Проведённый сравнительный анализ системы G2 с другими оболочками экспертных систем (ЭС) показал, что перечень функциональных возможностей, реализованных в G2, практически в два раза превосходит её ближайших конкурентов.

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

Объектно-ориентированная технология:

Представление знаний:

Механизм рассуждений:

ЭС G2 отличается от большинства динамических ЭС такими характерными свойствами, как:

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

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

Базовый продукт фирмы Gensym – пятая версия системы G2 – это мощная объектно-ориентированная, графическая среда для разработки и сопровождения приложений, не имеющая сегодня достойных конкурентов среди инструментальных средств построения сложных интеллектуальных систем анализа и управления в динамически изменяющемся окружении. В G2 v.5.0 поддержаны все основные принципы объектно-ориентированного подхода.

Опыт использования G2 в различных прикладных областях показывает, что затраты на разработку по сравнению с традиционными методами (например с использованием языка C или C++) сокращаются примерно в 5–10 раз. Система регистрации версий выводят G2 на уровень современных CASE-средств. Изменение описаний классов и отношений во время исполнения позволяет не только экспериментировать со структурами данных непосредственно в процессе отладки, но и открывает возможности использования генетических алгоритмов, самомодифицирующихся и обучающихся систем.

Возможности G2 в части поддержки распределенных приложений на основе архитектуры клиент/сервер и легкая интеграция с разнородными источниками информации позволяют использовать ее в качестве связующего звена в гетерогенных распределенных вычислительных средах, объединяющих как технические средства (контроллеры, ведущих фирм и каналы связи), так и развитые СУБД (ORACLE, Sybes, INFORMIX, все ODBC совместимые СУБД). Передача объектов и массивов в качестве аргументов упрощает совместное использование данных как независимыми приложениями на базе G2, так и внешними по отношению к G2 программными системами. Безопасность и конфиденциальность распределенной обработки достигаются за счет системы уровней автоматической проверки прав доступа при установлении сетевого взаимодействия процессов через независимый монитор транзакций – G2 Standard Interface (GSI).

Программные продукты фирмы Gensym работают под управлением различных вариантов операционных систем UNIX и VMS (большинство современных рабочих станций фирм SUN, IBM, DEC, HP используют именно эти операционные системы), четвертая версия G2 может работать под управлением MS Windows NT и MS Windows 95. Последнее обстоятельство открывает возможность переноса приложений на базе G2 на персональные ЭВМ с i486, Pentium и DEC Aplha.

Открытость системы G2 и продуктов на ее основе обеспечивается ориентацией фирмы Gensym на промышленные стандарты. Являясь членом OMG, фирма Gensym сотрудничает в этой области со многими независимыми организациями и комитетами по стандартам. В части технических средств – это поддержка широкого спектра платформ DEC, HP, Sun, IBM, SG и ПК на базе процессоров x86 и Pentium. Развитый графический интерфейс, включающий элементы анимации, базируется на средствах Motif и MS Windows. В G2 поддержан стандарт ISO 8859-5 в части представления символов кириллицы, независимо от операционной среды. Эта особенность открывает российским разработчикам возможность использования русских имен в названиях классов, атрибутов и т.д., то есть полностью русскоязычного интерфейса.

Поддерживаемые сетевые протоколы: TCP/IP и DECnet. Архитектура клиент/сервер на уровне обмена данными поддерживается монитором транзакций GSI и DDE, на уровне объектов - CORBA, на уровне приложения – клиентской подсистемой Telewindows. Распределенная обработка обеспечивается интерфейсами G2–G2, G2–Telewindows и поддержкой вызова удаленных процедур.

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


Система CLIPS
CLIPS (C Language Integrated Production System) начала разрабатываться в космическом центре Джонсона NASA в 1984 году. CLIPS и документация на этот инструмент свободно распространяется через интернет по адресу: (http://www.ghg.net/clips/CLIPS.html). Язык CLIPS свободен от недостатков предыдущих инструментальных средств для создания ЭС, основанных на языке LISP. Язык CLIPS получил большое распространение в государственных организациях и учебных заведениях благодаря низкой стоимости, мощности, эффективности и переносимости с платформы на платформу.

Следует отметить, что несмотря на многочисленные преимущества функцио-нального программирования, некоторые задачи лучше решать в терминах объектно-ориентированного программирования (ООП), для которого характерны три основные возможности: ИНКАПСУЛЯЦИЯ (работа с классами), ПОЛИМОРФИЗМ (работа с родовыми функциями, поддерживающими различное поведение функции в зависимости от типа аргументов), НАСЛЕДОВАНИЕ (поддержка абстрактных классов). ООП поддерживает многие языки, в том числе Smalltalk, C++, Java, Common LISP Object System (CLOS). Язык CLIPS, в свою очередь, вобрал в себя основные преимущества С++ и CLOS.

Читатель может познакомиться с языком CLIPS, получив через Интернет полный комплект документации на английском языке, или прочитав изданную на русском языке книгу. В данном разделе лекции дается краткое неформальное введение в CLIPS, необходимое для программирования учебных задач.
Выбор в качестве инструментального средства CLIPS обусловлен двумя причинами: во-первых, эта ЭС, разработанная NASA, доказала свою эффективность и свободно распространяется через Internet; во-вторых, реализация CLIPS на языке С++ позволяет переносить конкретные ЭС на различные типы операционных систем. Кроме того, может быть обеспечена возможность работы в реальном масштабе времени, когда реакция системы на возмущения должна не превышать нескольких миллисекунд.



























Практическая разработка экспертных систем

в среде CLIPS



Постановка задачи




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

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

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

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


Таблица 7.1. Информативные параметры ТП

№№ п/п

Обозначение параметра


Название параметра

Единица измерения

Диапазон значений

1

Vr

Скорость резания

об/мин

A, B, C

2

Vm

Подача

мм/с

10-180 с шагом 10

3

T

Виды траектории




Круговая (T=0), по участкам 1(T=1), ..., по участкам 6(T=6)

4

I

Инструмент




алмазный (I=1), на бакелитовой основе (I=2), на эльборовой основе (I=3)

5

G

Геометрические параметры инструмента




тор (G=tor), линия (G=line), макс.радиус вращения Rm, угол контакта инструмента и детали J, угол заточки S

6

Ds

Размер детали

мм

10, 300, 800

7

Dm

Материал детали




Титан1 (Dm=1), Титан2 (Dm=2), Жаропрочная сталь (Dm=3)

8

Da

Требования к детали по точности




1, 2, 3

9

Dar

Достигнутая точность детали




1, 2, 3


Запишем со слов экспертов информационные образы управляющих решений в алфавите значений информационных параметров. В таблице 7.2 представлена база знаний (база правил) нашей экспертной системы управления технологическим процессом. Здесь достоверность это уверенность эксперта, что такое воздействие позволит достичь заданных параметров обработки Ds, Dm, Da, Dar на основе данного воздействия.


Таблица 7.2. База знаний ЭС

№№ п/п


Ds

Dm

Da

Dar

Управляющее воздействие

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

Прим.

1

10

1

1




Vr=A, Vm=10, T=0, I=1, G=tor

0,98




2

10

2

2




Vr=B, Vm=10, T=1, I=1, G=line, Rm=40, J=80, S=60

0,95




3

300

2







Vr=B, Vm=20, T=2, I=1, G=tor

0,92




4

300




3




Vr=C, Vm=40, T=3, I=2, G=line, Rm=50, J=75, S=75

0,97




5

800

2

2

1

Vr=B, Vm=60, T=4, I=2, G=line, Rm=60, J=70, S=70

0,94




6

800







< 3

Vr=C, Vm=80, T=6, I=3, G=line, Rm=60, J=60, S=75

0,90




7

800







3

Vr=B, Vm=40, T=6, I=3, G=line, Rm=60, J=60, S=75

0,90




Достоверность правильности управляющего воздействия должна автоматически корректироваться по результатам изготовления детали. В табл. 7.2 приведен учебный пример базы знаний, упрощенный для целей реализации. Здесь не сформулированы задачи работы с базой данных. База целей (конфликтное множество правил) является внутренним для CLIPS механизмом. В общем случае, в процессе обработки производится измерение параметров, и управляющие воздействия задаются в зависимости от результатов измерений и БЗ управляющих воздействий. Например в данном примере, пока точность детали Dar < 3, работает строка 6 таблицы 7.2, как только Dar достигло значения 3, начинает работать строка 7. Это и есть простейший пример работы ЭС в реальном времени.



Основы программирования в системе CLIPS


Отличительной особенностью CLIPS являются конструкторы для создания баз знаний (БЗ):

defrule

определение правил;

deffacts

определение фактов;

deftemplate

определение шаблона факта;

defglobal

определение глобальных переменных;

deffunction

определение функций;

defmodule

определение модулей (совокупности правил);

defclass

определение классов;

defintances

определение объектов по шаблону, заданному defclass;

defmessagehandler

определение сообщений для объектов;

defgeneric

создание заголовка родовой функции;

defmethod

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

Конструкторы не возвращают никаких значений, в отличие от функций, например:

(deftemplate person

(slot name)

(slot age)

(multislot friends))

(deffacts people

(person (name Joe) (age 20))

(person (name Bob) (age 20))

(person (name Joe) (age 34))

(person (name Sue) (age 34))

(person (name Sue) (age 20)))

Пример функции:

(deffunction factorial (?a)

(if (or (not (integerp ? a)) (< ? a0)) then

(printout t "Factorial Error!" crlf)

else

(if (= ? a0) then

1

else

(*? a (factorial ($-$ ? a1))))))

Правила в CLIPS состоят из предпосылок и следствия. Предпосылки также называют ЕСЛИ-частью правила, левой частью правила или LHS правила (left-hand side of rule). Следствие называют ТО-частью правила, правой частью правила или RHS правила (right-hand side of rule).

Пример правила представлен ниже:

(deftemplate data (slot x) (slot y))

(defrule twice

(data (x ? x) (y =(*2 ? x)))

)

(assert (data (x2) (y4)); f-0

(data (x3) (y9))); f-1

Здесь самая распространенная в CLIPS функция assert добавляет новые факты в список правил. В противоположность assert функция retract удаляет факты из списка фактов, например:

(defrule vis11

?doors < — (fit ? wdfit)

(test (eq ? wdfit no))



(assert (EVIDENCE OF MAJOR ACCIDENT))

(retract ? doors))

В этом правиле проверяется наличие факта doors и в случае его отсутствия факт doors удаляется из списка фактов задачи.

Функция modify является также весьма распространенной. Она позволяет в определенном факте поменять значение слота, например,

(deftemplate age (slot value))

(assert (age (value young)))

(modify 0 (value old))

Следующий пример описывает представление данных в виде фактов, объектов и глобальных переменных. Примеры фактов:

(voltage is 220 volt)

(meeting (subject "AI") (chief "Kuzin") (Room "3240"))

В первой строке приведен упорядоченный факт, во второй - неупорядоченный, в котором порядок слотов не важен.

CLIPS поддерживает следующие типы данных: integer, float, string, symbol, external-address, fact-address, instance-name, instance-address.

Пример integer:

594

23

+51

?17

Пример float:

594e2

23.45

+51.0

?17.5e?5

String — это строка символов, заключенная в двойные кавычки.

Пример string: "expert", "Phil Blake", "состояние $-0$", "quote="

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

If

оператор ветвления;

While

цикл с предусловием;

loop-for-count

итеративный цикл;

prong

объединение действий в одной логической команде;

prong$

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

return

прерывание функции, цикла, правила и т.д.;

break

то же, что и return, но без возвращения параметров;

switch

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

bind

создание и связывание переменных.

Функции CLIPS описываются в книгах. Среди логических функций (возвращающих значения true или false) следует выделить следующие группы:

Среди математических функций следует выделить следующие группы:

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

str-cat

объединение строк,

sym-cat

объединение строк в значение типа symbol,

sub-string

выделение подстроки,

str-index

поиск подстроки,

eval

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

build

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

upcase

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

lowcase

преобразование символов в символы нижнего регистра,

str-compare

сравнение строк,

str-length

определение длины строки,

check-syntax

проверка синтаксиса строки,

string-to-field

возвращение первого поля строки.

Функции работы с составными величинами являются одной из отличительных особенностей языка CLIPS. В их число входят:

create$

создание составной величины,

nth$

получение элемента составной величины,

members

поиск элемента составной величины,

subset$

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

delete$

удаление элемента составной величины,

explode$

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

implode$

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

subseq$

извлечение подпоследовательности из составной величины,

replace$

замена элемента составной величины,

insert$

добавление новых элементов в составную величину,

first$

получение первого элемента составной величины,

rest$

получение остатка составной величины,

length$

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

delete-member$

удаление элементов составной величины,

replace-member$

замена элементов составной величины.

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

stdin

устройство ввода,

stdout

устройство вывода,

wclips

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

wdialog

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

wdisplay

устройство для отображения правил, фактов и т.,п.,

werror

устройство вывода сообщений об ошибках,

wwarning

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

wtrase

устройство для вывода отладочной информации,

Собственно функции ввода-вывода следующие:

open

открытие файла (виды доступа r, w, r+, a, wb),

close

закрытие файла,

printout

вывод информации на заданное устройство,

read

ввод данных с заданного устройства,

readline

ввод строки с заданного устройства,

format

форматированный вывод на заданное устройство,

rename

переименование файла,

remove

удаление файла.

Среди двух десятков команд CLIPS следует назвать основные команды при работе со средой CLIPS:

load

загрузка конструкторов из текстового файла,

load+

загрузка конструкторов из текстового файла без отображения,

reset

сброс рабочей памяти системы CLIPS,

clear

очистка рабочей памяти системы,

run

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

save

сохранение созданных конструкторов в текстовый файл,

exit







выход из CLIPS.

В рамках нашего краткого описания опустим список функций для работы с методами родовых функций и список функций для работы с классами, объектами, слотами, обработчиками сообщений. С этим можно ознакомиться по документации. Список сообщений об ошибках приведен в [91].

В завершение следует иметь в виду, что CLIPS может не удовлетворительно работать в реальном времени, когда потребуется время реакции менее 0,1 сек. В этом случае надо исследовать на разработанном прототипе механизмы вывода для всего множества правил предметной области на различных по производительности компьютерах. Как правило, современные мощные компьютеры Intel обеспечивают работу с продукционными системами объемом 1000–2000 правил в реальном времени. Веб-ориентированные средства на базе JAVA (системы Exsys Corvid, JESS) являются более медленными, чем, например, CLIPS 6.0 или OPS-2000. Поэтому CLIPS – лучший на сегодня выбор для работы в реальном времени среди распространяемых свободно оболочек ЭС, разработанных на C++.

Программирование в CLIPS экспертной системы управления технологическим процессом


Программа ЭС управления ТП по обработке деталей сложной формы, разработанная на основе табл. 7.1 и табл. 7.2, выглядит следующим образом.

;;;===========================================

;;; Control Expert System of technological process

;;;

;;; This expert system administers technological process

;;; of creations of details of the complex form

;;;

;;; CLIPS Version 6.0 Example

;;;Author: Vladimir Makushkin, vmakushkin@mail.ru

;;;

;;; To execute, merely load, reset and run.

;;;===========================================
(deffacts initial-state

(Ds 800)

(Dm 2)

(Da 2)

(Dar 1))
(defrule rule1

(declare (salience 9098))

(Ds 10)

(Dm 1)

(Da 1)



(printout t "Rule1: Vr=A, Vm=10, T=0, I=1, G=tor" crlf))
(defrule rule2

(declare (salience 9095))

(Ds 10)

(Dm 2)

(Da 2)



(printout t "Rule2: Vr=B, Vm=10, T=1, I=1, G=line, Rm=40, J=80, S=60" crlf))
(defrule rule3

(declare (salience 9092))

(Ds 300)

(Dm 2)



(printout t "Rule3: Vr=B, Vm=20, T=2, I=1, G=tor" crlf))
(defrule rule4

(declare (salience 9097))

(Ds 300)

(Da 3)



(printout t "Rule4: Vr=C, Vm=40, T=3, I=2, G=line, Rm=50, J=75, S=75" crlf))
(defrule rule5

(declare (salience 9094))

(Ds 800)

(Dm 2)

(Da 2)

(Dar 1)



(printout t "Rule5: Vr=B, Vm=60, T=4, I=2, G=line, Rm=60, J=70, S=70" crlf))
(defrule rule6_7

(declare (salience 9090))

(Ds 800)

(Dar ? num)



(if (< ? num 3)

then

(printout t "Rule6: Vr=B, Vm=40, T=6, I=3, G=line, Rm=60, J=60, S=75" crlf)

else

(printout t "Rule7: Vr=C, Vm=80, T=6, I=3, G=line, Rm=60, J=60, S=75" crlf)))
Листинг 7.1. Программа ЭС управления ТП

по обработке деталей сложной формы (html, txt)

Эта программа сохраняется в виде файла с именем, например, robot.clp, далее в среде CLIPS выполняются команды: clear; load robot.clp; reset и run. Эта программа начинает работать. Входные воздействия заданы в данном примере через deffacts initial-state.

Активизация правил БЗ для конкретных воздействий, заданных в программе, дает конфликтное множество (базу целей) – правила rule5 и rule6_7, а затем по критерию максимальной достоверности первым выбирается управляющее воздействие на систему низшего уровня:

Rule5: Vr=B, Vm=60, T=4, I=2, G= line, Rm=60, J=70, S=70

В реальной жизни входные воздействия поступают через оператор read (ввод данных с заданного устройства), например, следующим образом:

(defrule Dar_parameter

(declare (salience 9101))

(Dar ? num)



(printout t "Ds parameter has value "crlf"

1) 10 "crlf" 2) 300 "crlf" 3) 800 "crlf" Choose 1—3 ")

(assert (Dar =(read))))

Читателю предлагается самостоятельно дописать правила останова программы (halt) по условиям Da=Dar или достижению заданного значения Ds, а также правила для проверки граничных условий. Дотошный читатель, разобравшийся в программе, может спросить, зачем мне CLIPS, если такую простую программу я могу написать на любом языке программирования. Во-первых, это учебный пример с простейшей базой знаний. Во-вторых, в реальной жизни база знаний содержит сотни правил, управляющие параметры постоянно считываются с датчиков и видеокамер, и сразу же отрабатывается поиск в сети продукций новых управляющих воздействий. Простой программой в таком случае не обойтись.

Примером более сложной программы для решения задачи планирования последовательности действий робота (лекция 3, рис. 3.4) является фрагмент программы Д. Грим-шоу (www.ryerson.ca/~dgrimsha). Эта программа управления роботом по перекладыванию кубиков. Начальное состояние положения кубиков в стеке 1 и стеке 2 определяется путем перечисления кубиков сверху вниз. Задавая различные комбинации в deffacts initial-state, мы получим конкретные последовательности действий робота.

(deftemplate goal

(slot move)

(slot on-top-of))

(deffacts initial-state

(stack A B C)

(stack D E F)

(goal (move C) (on-top-of E)))

(defrule move-directly

?goal < — (goal (move ?block1) (on-top-of ?block2))

?stack-1 < — (stack ?block1 $?rest1)

?stack-2 < — (stack ?block2 $?rest2)



(retract ?goal ?stack-1 ?stack-2)

(assert (stack $?rest1))

(assert (stack ?block1 ?block2 $?rest2))

(printout t ?block1 "moved on top of" ?block2 crlf))

(defrule move-to-floor >

?goal < — (goal (move ?block1) (on-top-of floor))

?stack-1 < — (stack ?block1 $?rest)



(retract ?goal ?stack-1)

(assert (stack ?block1))

(assert (stack $?rest))

(printout t ?block1 "moved to the floor." crlf))

(defrule clear-upper-block

(goal (move ?block))

(stack ?top $? ?block $?)



(assert (goal (move ?top) (on-top-of floor))))

(defrule clear-lower-block

(goal (on-top-of ?block))

(stack ?top $? ?block $?)



(assert (goal (move ?top) (on-top-of floor))))

Результат работы CLIPS в данном случае будет следующий:

CLIPS$>$ (run)

A moved to the floor.

B moved to the floor.

D moved to the floor.

C moved on top of E

CLIPS$>$

В завершение лекции читателю может быть рекомендована книга Ж. Гурратано [94], содержащая множество примеров программирования ЭС на основе CLIPS.

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

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

  1. Попов Э.В. Экспертные системы: Решение неформализованных задач в диалоге с ЭВМ. – М.: Наука. Гл. ред. физ.-мат. лит., 1987.

  2. Марселлус Д. Программирование экспертных систем на Турбо Прологе: Пер. с англ. – М.: Финансы и статистика, 1994.

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

  4. Муромцев Д.И. Введение в технологию экспертных систем. – СПб: СПб ГУ ИТМО, 2005.







Лекция 6 Предпочтительное использование экспертных систем
Учебный материал
© nashaucheba.ru
При копировании укажите ссылку.
обратиться к администрации