Главная
Коллекция "Otherreferats"
Программирование, компьютеры и кибернетика
Разработка интеллектуальных подсистем САПР
Разработка интеллектуальных подсистем САПР
Прикладные интеллектуальные системы. Экспертные системы, их определение, структура, трудности разработки. Классификация систем, основанных на знаниях. Способы интеллектуализации САПР (систем автоматизированного проектирования), их архитектура и концепции.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 24.03.2016 |
| Размер файла | 52,9 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Содержание
- Введение
- 1. Прикладные интеллектуальные системы
- 2. Введение в экспертные системы. Определение и структура
- 3. Классификация систем, основанных на знаниях
- 4. Трудности разработки экспертных систем
- 5. Способы интеллектуализации САПР
- 6. Архитектура интеллектуальных САПР
- 7. Основные концепции интеллектуальных CAПP
- Заключение
- Список литературы
Введение
Разработка интеллектуальных подсистем САПР производится в рамках теории искусственного интеллекта. Искусственный интеллект (ИИ) это область исследований, находящаяся на стыке наук. Специалисты, работающие в этой области, пытаются понять, какое поведение, считается разумным (анализ), и создать работающие модели этого поведения (синтез). Практической целью является создание методов и техники, необходимой для программирования "разумности" и ее передачи вычислительным машинам, а через них всевозможным системам и средствам.
Искусственный интеллект это программная система, имитирующая на компьютере мышление человека. Для создания такой системы необходимо изучить процесс мышления человека, решающего определенные задачи или принимающего решения в конкретной области, выделить основные шаги этого процесса и разработать программные средства, воспроизводящие их на компьютере. Следовательно, методы ИИ предполагают простой структурный подход к разработке сложных программных систем принятия решений.
Компьютерные программы, как правило, предназначены для решения строго определённых задач. Приспособить программу к решению новых задач можно, внеся в неё изменения, а для этого её нужно всю внимательно просмотреть. Но подробный просмотр занимает слишком много времени, а при внесении изменений в программе могут возникнуть дополнительные ошибки.
интеллектуальная подсистема экспертная архитектура
1. Прикладные интеллектуальные системы
Экспертные системы это наиболее распространенный класс ИС, ориентированный на тиражирование опыта высококвалифицированных специалистов в областях, где качество принятия решений традиционно зависит от уровня экспертизы, например, медицина, юриспруденция, геология, экономика, военное дело и др.
ЭС эффективны лишь в специфических "экспертных" областях, где важен эмпирический опыт специалистов.
Ежегодно крупные фирмы разрабатывают десятки ЭС типа "in-house" для внутреннего пользования. Эти системы интегрируют опыт специалистов компании по ключевым и стратегически важным технологиям.
Современные ЭС это сложные программные комплексы, аккумулирующие знания специалистов в конкретных предметных областях и распространяющие этот эмпирический опыт для консультирования менее квалифицированных пользователей.
Разработка экспертных систем, как активно развивающаяся ветвь информатики, направлена на использование ЭВМ для обработки информации в тех областях науки и техники, где традиционные математические методы моделирования малопригодны. В этих областях важна смысловая и логическая обработка информации, важен опыт экспертов.
Приведем некоторые условия, которые могут свидетельствовать о необходимости разработки и внедрения экспертных систем:
· нехватка специалистов, затрачивающих значительное время для оказания помощи другим;
· выполнение небольшой задачи требует многочисленного коллектива специалистов, поскольку ни один из них не обладает достаточным знанием;
· сниженная производительность, поскольку задача требует полного анализа сложного набора условий, а обычный специалист не в состоянии просмотреть (за отведенное время) все эти условия;
· большое расхождение между решениями самых хороших и самых плохих исполнителей;
· наличие конкурентов, имеющих преимущество в силу того, что они лучше справляются с поставленной задачей.
Подходящие задачи имеют следующие характеристики:
· являются узкоспециализированными;
· не зависят в значительной степени от общечеловеческих знаний или соображений здравого смысла;
· не являются для эксперта ни слишком легкими, ни слишком сложными.
· (время, необходимое эксперту для решения проблемы, может составлять от трех часов до трех недель).
Экспертные системы достаточно молоды первые системы такого рода,MYCINиDENDRAL, появились в США в середине 70-х годов. В настоящее время в мире насчитывается несколько тысяч промышленных ЭС, которые дают советы:
· при управлении сложными диспетчерскими пультами, например сети распределения электроэнергии;
· при постановке медицинских диагнозов;
· при поиске неисправностей в электронных приборах, диагностика отказов контрольно-измерительного оборудования;
· по проектированию интегральных микросхем;
· по управлению перевозками;
· по прогнозу военных действий;
· по формированию портфеля инвестиций, оценке финансовых рисков, налогообложению и т.д.
Современное состояние разработок в области ЭС в России можно охарактеризовать как стадию все возрастающего интереса среди широких слоев специалистов-финансистов, топ-менеджеров, преподавателей, инженеров, медиков, психологов, программистов, лингвистов. В последние годы этот интерес имеет пока достаточно слабое материальное подкреплениеявная нехватка учебников и специальной литературы, отсутствие символьных процессоров и рабочих станций, ограниченное финансирование исследований в этой области, слабый отечественный рынок программных продуктов для разработки ЭС.
Поэтому появляется возможность распространения "подделок" под экспертные системы в виде многочисленных диалоговых систем и интерактивных пакетов прикладных программ, которые дискредитируют в глазах пользователей это чрезвычайно перспективное направление. Процесс создания экспертной системы требует участия высококвалифицированных специалистов в области искусственного интеллекта, которых пока выпускает небольшое количество высших учебных заведений страны.
Наибольшие трудности в разработке ЭС вызывает сегодня не процесс машинной реализации систем, а домашинный этап анализа знаний и проектирования базы знаний. Этим занимается специальная наука инженерия знаний.
2. Введение в экспертные системы. Определение и структура
В качестве рабочего определения экспертной системы примем следующее.
Экспертные системы это сложные программные комплексы, аккумулирующие знания специалистов в конкретных предметных областях и тиражирующие этот эмпирический опыт для консультаций менее квалифицированных пользователей.
Обобщенная структура экспертной системы представлена на рисунке 9. Следует учесть, что реальные ЭС могут иметь более сложную структуру, однако блоки, изображенные на рисунке, непременно присутствуют в любой действительно экспертной системе, поскольку представляют собой стандарт defacto структуры современной ЭС.
В целом процесс функционирования ЭС можно представить следующим образом: пользователь, желающий получить необходимую информацию, через пользовательский интерфейс посылает запрос к ЭС; решатель, пользуясь базой знаний, генерирует и выдает пользователю подходящую рекомендацию, объясняя ход своих рассуждений при помощи подсистемы объяснений.
Пользователь специалист предметной области, для которого предназначена система. Обычно его квалификация недостаточно высока, и поэтому он нуждается в помощи и поддержке своей деятельности со стороны ЭС.
Инженер по знаниям специалист в области искусственного интеллекта, выступающий в роли промежуточного буфера между экспертом и базой знаний.
Интерфейс пользователя комплекс программ, реализующих диалог пользователя с ЭС как на стадии ввода информации, так и при получении результатов.
База знаний ядро ЭС, совокупность знаний предметной области, записанная на машинный носитель в форме, понятной эксперту и пользователю (обычно на некотором языке, приближенном к естественному).
Решатель программа, моделирующая ход рассуждений эксперта на основании знаний, имеющихся в БЗ. Синонимы: дедуктивная машина, машина вывода, блок логического вывода.
Подсистема объяснений программа, позволяющая пользователю получить ответы на вопросы: "Как была получена та или иная рекомендация?" и "Почему система приняла такое решение?" Ответ на вопрос "как" это трассировка всего процесса получения решения с указанием использованных фрагментов БЗ, то есть всех шагов цепи умозаключений. Ответ на вопрос "почему"ссылка на умозаключение, непосредственно предшествовавшее полученному решению, то есть отход на один шаг назад. Развитые подсистемы объяснений поддерживают и другие типы вопросов.
Интеллектуальный редактор БЗ программа, представляющая инженеру по знаниям возможность создавать БЗ в диалоговом режиме. Включает в себя систему вложенных меню, шаблонов языка представления знаний, подсказок и других сервисных средств, облегчающих работу с базой.
Следует подчеркнуть, что представленная структура является минимальной, что означает обязательное присутствие указанных на ней блоков. Промышленные прикладные ЭС могут быть существенно сложнее и дополнительно включать базы данных, интерфейсы обмена данными с различными пакетами прикладных программ, электронными библиотеками и т.д.
3. Классификация систем, основанных на знаниях
Класс ЭС сегодня объединяет несколько тысяч различных программных комплексов, которые можно классифицировать по различным критериям.
1. Классификация по решаемой задаче
o Интерпретация данных. Это одна из традиционных задач для экспертных систем. Под интерпретацией понимается процесс определения смысла данных, результаты которого должны быть согласованными и корректными. Обычно предусматривается многовариантпый анализ данных. Примеры: обнаружение и идентификация различных типов океанских судов по результатам аэрокосмического сканированияSIAP; определение основных свойств личности по результатам психодиагностического тестирования.
o Диагностика. Под диагностикой понимается процесс соотнесения объекта с некоторым классом объектов и/или обнаружение неисправности в некоторой системе. Неисправностьэто отклонение от нормы. Такая трактовка позволяет с единых теоретических позиций рассматривать и неисправность оборудования в технических системах, и заболевания живых организмов, и все возможные природные аномалии. Важной спецификой является здесь необходимость понимания функциональной структуры ("анатомии") диагностирующей системы. Примеры: диагностика и терапия сужения коронарных сосудовANGY; диагностика ошибок в аппаратуре и математическом обеспечении ЭВМ.
· Мониторинг. Основная задача мониторинганепрерывная интерпретация данных в реальном масштабе времени и сигнализация о выходе тех или иных параметров за допустимые пределы. Главные проблемы"пропуск" тревожной ситуации и инверсная задача "ложного" срабатывания. Сложность этих проблем в размытости симптомов тревожных ситуаций и необходимость учета временного контекста. Примеры: контроль за работой электростанций СПРИНТ, помощь диспетчерам атомного реактораREACTOR; контроль аварийных датчиков на химическом заводеFALCONи др.
· Проектирование. Проектирование состоит в подготовке спецификаций на создание "объектов" с заранее определенными свойствами. Под спецификацией понимается весь набор необходимых документовчертеж, пояснительная записка и т.д. Основные проблемы здесьполучение четкого структурного описания знаний об объекте и проблема "следа". Для организации эффективного проектирования и в еще большей степени перепроектирования необходимо формировать не только сами проектные решения, но и мотивы их принятия. Таким образом, в задачах проектирования тесно связываются два основных процесса, выполняемых в рамках соответствующей ЭС: процесс вывода решения и процесс объяснения. Примеры: проектирование конфигураций ЭВМ; синтез электрических цепейSYNи др.
· Прогнозирование. Прогнозирование позволяет предсказывать последствия некоторых событий или явлений на основании анализа имеющихся данных.
· Прогнозирующие системы логически выводят вероятные следствия из заданных ситуаций. В прогнозирующей системе обычно используется параметрическая динамическая модель, в которой значения параметров "подгоняются" под заданную ситуацию. Выводимые из этой модели следствия составляют основу для прогнозов с вероятностными оценками. Примеры: предсказание погодысистемаWILLARD; оценки будущего урожаяPLANT; прогнозы в экономикеECONи др.
· Планирование. Под планированием понимается нахождение планов действий, относящихся к объектам, способным выполнять некоторые функции.
· В таких ЭС используются модели поведения реальных объектов с тем, чтобы логически вывести последствия планируемой деятельности. Примеры: планирование поведения роботаSTRIPS; планирование промышленных заказовISIS; планирование экспериментаMOLGENи др.
· Обучение. Под обучением понимается использование компьютера для обучения какой-то дисциплине или предмету. Системы обучения диагностируют ошибки при изучении какой-либо дисциплины с помощью ЭВМ и подсказывают правильные решения. Они аккумулируют знания о гипотетическом "ученике" и его характерных ошибках, затем в работе они способны диагностировать слабости в познаниях обучаемых и находить соответствующие средства для их ликвидации. Кроме того, они планируют акт общения с учеником в зависимости от успехов ученика с целью передачи знаний. Примеры: обучение языку программирования ЛИСП в системе "Учитель ЛИСПа"; системаPROUSTобучение языку Паскаль и др.
· Управление. Под управлением понимается функция организованной системы, поддерживающая определенный режим деятельности. Такого рода ЭС осуществляют управление поведением сложных систем в соответствии с заданными спецификациями. Примеры: помощь в управлении газовой котельнойGAS; управление системой календарного планирования Project Assistant и др.
· Поддержка принятия решений. Поддержка принятия решения это совокупность процедур, обеспечивающая лицо, принимающее решения, необходимой информацией и рекомендациями, облегчающими процесс принятия решения. Эти ЭС помогают специалистам выбрать и/или сформировать нужную альтернативу среди множества выборов при принятии ответственных решений. Примеры: выбор стратегии выхода фирмы из кризисной ситуации CRYSIS; помощь в выборе страховой компании или инвестора CHOICE и др.
2. Классификация по связи с реальным временем
· Статические ЭС разрабатываются в предметных областях, в которых база знаний и интерпретируемые данные не меняются во времени. Они стабильны.
Пример: диагностика неисправностей в автомобиле.
· Квазидинамические ЭС интерпретируют ситуацию, которая меняется с некоторым фиксированным интервалом времени. Пример: микробиологические ЭС, в которых снимаются лабораторные измерения с технологического процесса один раз в 4-5 часов и анализируется динамика полученных показателей по отношению к предыдущему измерению.
· Динамические ЭС работают в сопряжении с датчиками объектов в режиме реального времени с непрерывной интерпретацией поступающих в систему данных. Примеры: управление гибкими производственными комплексами, мониторинг в реанимационных палатах.
Стадии разработки экспертных систем
Стадия существования характеризует степень проработанности и отлаженности ЭС. Обычно выделяют следующие стадии: демонстрационный прототип; исследовательский прототип; действующий прототип; промышленная система; коммерческая система.
Демонстрационным прототипом называют ЭС, которая решает часть требуемых задач, демонстрируя жизнеспособность метода инженерии знаний. При наличии развитых инструментальных средств (ИС) для разработки демонстрационного прототипа требуется в среднем примерно 1-2 мес., а при отсутствии 12-18 мес. Демонстрационный прототип работает, имея в БЗ 50-100 правил. Развитие демонстрационного прототипа приводит к исследовательскому прототипу.
Исследовательским прототипом называют систему, которая решает все требуемые задачи, но неустойчива в работе и не полностью проверена. На доведение системы до стадии исследовательского прототипа уходит 3-6 мес. Исследовательский прототип обычно имеет в БЗ 200-500 правил, описывающих проблемную область.
Действующий прототип надежно решает все задачи, но для решения сложных задач может потребоваться чрезмерно много времени и (или) памяти. Для доведения системы до стадии действующего прототипа требуется 6-12 мес., при этом количество правил в БЗ увеличивается до 500-1000.
Экспертная система, достигшая промышленной стадии, обеспечивает высокое качество решений всех задач при минимуме времени и памяти. Обычно процесс преобразования действующего прототипа в промышленную систему состоит в расширении БЗ (до 1000-1500 правил) и переписывании программ с использованием более эффективных ИС, например в перепрограммировании на языках низкого уровня. Для доведения ЭС от начала разработки до стадии промышленной системы требуется 1-1,5 года.
Обобщение задач, решаемых ЭС на стадии промышленной системы, позволяет перейти к стадии коммерческой системы к системе, пригодной не только для собственного использования, но и для продажи различным потребителям. Для доведения системы до коммерческой стадии требуется 1,5-3 года. При этом в БЗ системы 1500-3000 правил.
4. Трудности разработки экспертных систем
При разработке ЭС разработчиков поджидают различные трудности:
глобальные, имеющие отношение ко всему процессу разработки или к нескольким этапам разработки;
локальные, проявляющиеся в основном на некотором этапе разработки.
Глобальные трудности. Это общие проблемы, с которыми сталкивается коллектив, пытающийся применить технологию ЭС для решения своих задач.
Источником глобальных трудностей являются, по крайней мере, следующие факторы: недостаток ресурсов; ограничения существующих ЭС; длительность разработки ЭС. Рассмотрим эти факторы подробнее.
Недостаток ресурсов для создания ЭС выражается в нехватке человеческих, программных и аппаратных ресурсов. В связи с относительной новизной направления практически отсутствуют инженеры по знаниям, очень мало специалистов по разработке инструментальных средств (ИС) для систем ИИ и ЭС.
Ограничения программных ресурсов выражаются в слабом развитии ИС, что приводит к чрезмерной длительности и трудоемкости разработки ЭС.
Ограничения существующих ЭС можно разделить на ограничения, присущие существующим ИС, и на ограничения, присущие собственно ЭС. К ограничениям собственно ЭС следует отнести следующие: крайне слабые возможности по работе с динамическими мирами, требующими представления времени и (или) пространства; недостаточные возможности ЭС по генерации умозаключений, основанных на "здравом смысле"; ЭС плохо распознают ситуации, когда пользователь выходит за рамки их возможностей (что приводит к непредвиденным неудачам); как правило, ЭС не способны определить несогласованность (противоречивость) знаний, объяснить причину несогласованности и устранить ее. К ограничениям ИС можно отнести следующее: они могут оказать очень малую помощь в процессе приобретения и корректировки знаний в наиболее трудоемком аспекте разработки ЭС; существующие отечественные инструментальные средства, как правило, не позволяют использовать смешанное представление (например, правила и фреймы).
Процесс разработки ЭС довольно длительный, и это является существенным ограничением при выборе данного способа реализации задачи.
Локальные трудности. Инженер по знаниям на разных этапах создания ЭС может столкнуться с локальными трудностями.
На этапе идентификации основные трудности возникают при решении следующих проблем:
1. Определение пригодности методов инженерии знаний для решения предлагаемой задачи. При решении данной проблемы могут возникнуть следующие препятствия:
задача слишком сложна и не может быть решена доступными ресурсами в пределах заданных ограничений (время, тип ЭВМ и т.п.);
задача может быть решена ЭС, но пользователь не получит от ее решения существенной пользы;
задача может быть решена, но либо требуется ввести слишком много правил и объектов (что чрезмерно затянет процесс разработки), либо результирующая система работает слишком медленно.
Чтобы выявить сложность задачи, инженер должен разработать небольшой прототип ЭС, работа которого позволит надежно ответить на вопрос о приемлемости задачи. В простых случаях ответ на этот вопрос можно получить, имея опыт разработки ЭС, при анализе описания задачи. Для выявления полезности ЭС следует до ее разработки ответить на следующий вопрос: если ЭС буде работать хорошо, то будет ли это давать тот эффект, которого хочет достичь пользователь?
Другими словами, надо понять, не окажется ли, что для удовлетворения потребностей пользователя надо решать еще какие-то задачи, не предусмотренные в данной ЭС. Для преодоления последнего из перечисленных препятствий необходимо ограничить задачу или область ее приложения. Надежным средством выявления наличия или отсутствия данной трудности являете разработка прототипа.
2. Определение необходимых ресурсов. При решении этой проблемы возникают следующие препятствия: срок разработки ЭС назначается на основании анализа, выполненного инженером по знаниям, а потребностей пользователей (интерактивная природа процесса приобретения знаний существенно ограничивает эффективность ускорения разработки ЭС за счет увеличения числа разработчиков); попытка разработать ЭС без инженеров по знаниям, а только с помощью программистов приводит либо к чрезмерному увеличению сроков разработки, либо к ее полной неудаче.
3. Выбор эксперта. При работе с экспертом может оказаться, что процесс извлечения знаний протекает чрезвычайно неэффективно. Наиболее вероятной причиной этого обычно является неправильный выбор эксперта. При выборе эксперта к нему следует предъявлять следующие требования: высокая компетентность в данной проблемной области; способность ясно, просто и доходчиво выражать свои идеи и методы; наличие у эксперта заинтересованности в разработке ЭС; эксперт должен верить в полезность использования вычислительной техники при решении данной задачи (чем больше эксперт знает об ЭВМ и программировании, тем лучше); эксперт должен хотеть и быть способен уделять разработке ЭС примерно половину своего рабочего времени в первые полгода разработки и примерно одну треть времени в последующее время.
На этапе концептуализации могут встретиться следующие трудности:
1. К работе подключено излишне много экспертов. Инженер по знаниям, общаясь со всеми, не имеет возможности глубоко исследовать данную область. Инженеру рекомендуется работать только с одним или двумя экспертами. После построения прототипа для его тестирования и модификации целесообразно подключать дополнительных экспертов.
2. Инженер по знаниям выявляет правила, наблюдая за тем, как эксперт решает конкретные задачи, что может привести к образованию специфических правил. Для преодоления этой трудности инженер должен пытаться выявить общие принципы, используемые экспертом. Часто оказывается полезным введение понятий высокого уровня, которые эксперт фактически использует, но не называет, так как они им не вербализованы (в научной литературе такие понятия не введены). Введение этих понятий может позволить заменить несколько специфических правил одним общим.
3. После нескольких месяцев взаимодействия с экспертом инженер по знаниям выделил несколько сотен правил и представил их в выбранном языке. Однако начало проверки прототипа показывает, что многие фундаментальные понятия в приобретенных правилах отсутствуют (т.е. выявлены ошибки, допущенные на этапе концептуализации). Чтобы описанная выше ситуация не возникла, опытный инженер по знаниям осуществляет тестирование принятых решений в ходе всех этапов разработки, а не только по окончании этапа выполнения.
На этапе формализации основные проблемы относятся к выбору и использованию инструментальных средств. Можно выделить следующие трудности.
1. При использовании выбранного ИС инженеры по знаниям (разработчики) приходят к выводу, что в нем трудно представлять как понятия области экспертизы, так и управляющие структуры, необходимые для решения задачи. Выбор ИС и определение его пригодности для данного приложения весьма сложны и неформальны. Поэтому разработчики, как правило, могут оценить сделанный выбор только после разработки в нем небольшого прототипа. Если разработчики приходят к выводу, что выбранное инструментальное средство не подходит для данной проблемы, то необходимо либо выбрать другое ИС, либо разрабатывать новое (в этом случае практически дело сводится к откладыванию разработки ЭС на неопределенный срок).
2. Инженер по знаниям выбирает то ИС, которым он хорошо владеет, а не то, которое наиболее соответствует данной проблемной области. При этом, если ИС явно плохо подходит, инженер прилагает усилия к изменению исходной задачи (что может снизить или устранить практическую значимость создаваемой ЭС), чтобы она подходила под выбранное им ИС. Для устранения подобных затруднений руководитель проекта по разработке ЭС должен при выборе ИС проконсультироваться с несколькими инженерами по знаниям, чтобы убедиться в обоснованности сделанного выбора. Кроме того, сам инженер по знаниям должен осознавать наличие подобной ловушки и тщательно подходить к проблеме выбора инструментального средства.
3. В качестве ИС выбирается (на начальных этапах разработки ЭС) один из общецелевых языков программирования (например, Паскаль, Си, Фортран), что приводит к чрезмерному увеличению времени разработки ЭС или к полной неудаче всего проекта. Ошибочность подобного выбора состоит в том, что для выполнения таких наиболее трудоемких работ, как наполнение экспертной системы знаниями, тестирование и корректировка БЗ, общецелевые языки плохо приспособлены. Более правильно разработать ЭС, используя инструментальные средства, ориентированные на разработку экспертных систем, и затем, если ЭС будет работать медленно, переписать ее, используя общецелевые языки программирования.
4. Выбранное ИС содержит ошибки, препятствующие использованию многих из его свойств. Для предотвращения указанной трудности рекомендуется: избегать ИС, не находившихся в употреблении; не использовать инструментальные средства, которые более не сопровождаются разработчиком; выбирать то ИС, которое сопровождается разработчиком и было успешно использовано в других применениях.
В ходе этапа выполнения могут встретиться следующие основные трудности:
1. Эксперт теряет интерес к разработке ЭС. Время, которое он выделяет на работу с инженером по знаниям, постоянно сокращается. В подобных ситуациях рекомендуется: поддерживать интерес эксперта к работе, обеспечивая; дружественную обстановку; объяснять, что для успеха необходимы регулярные контакты (не реже 2-3 раз в неделю); помнить, что эксперт не специалист в программировании и ЭС, и не требовать от эксперта того, что он не умеет делать; предоставить эксперту возможность непосредственного наблюдения за результатами предлагаемых им изменений БЗ.
2. Эксперт при корректировке БЗ прототипа не совсем понимает, как система интерпретирует правила. Чтобы избежать указанного затруднения, рекомендуется: использовать в правилах ту же терминологию, которую использует эксперт; хранить в системе определения всех используемых понятий и иметь возможность выдавать их по требованию пользователя; если правила во внутреннем представлении "нечитаемы", то иметь средства для преобразования правил в вид, понятный пользователю.
3. Правила, введенные экспертом, в сложных ситуациях не позволяют прототипу ЭС получить качественные решения. Для преодоления данного затруднения рекомендуется: ориентировать эксперта на решение реальных, а не "игрушечных" задач; наблюдать за работой эксперта, стремясь выделить все типы возможных задач (подзадач); привлекать для оценки работы прототипа других экспертов.
4. Для построения ЭС было выбрано ИС без объяснительных способностей. После отработки ЭС разработчики пытаются дополнить ЭС этим механизмом, однако обычно сделать это чрезвычайно трудно. Чтобы не сталкиваться с подобными трудностями, разработчики должны выбирать ИС с объяснительными способностями. Объяснения ускоряют отладку, тестирование, модификацию прототипа и обеспечивают удобство для конечного пользователя и эксперта.
5. В процессе разработки ЭС знания об области экспертизы переплетаются с общими знаниями о решении задач (проблемно-независимыми знаниями), что затрудняет (делает невозможным) проведение модификации и развития ЭС. По сути дела, нарушается основной принцип разработки ЭС отделение знаний эксперта от остальных знаний и представление знаний эксперта в явном виде.
На этапе тестирования и опытной эксплуатации могут встретиться следующие трудности:
1. Тестирование не выполняется в ходе разработки, а впервые осуществляется после этапа выполнения. При подобном подходе вероятность отрицательной оценки ЭС очень велика. Кроме того, весьма вероятно, что перепроектирование ЭС придется начать с ранних этапов (идентификации и концептуализации). Общая рекомендация при разработке экспертных систем состоит в проведении тестирования и оценки как можно раньше. Поэтому на начальных этапах разработчики ЭС должны составить методику оценки пригодности и полезности конечного продукта, что позволит по ходу разработки (а не в ее конце) оценивать состояние проекта и прогнозировать срок его успешного завершения.
2. Пользователи (эксперты) находят процесс взаимодействия с ЭС трудным и неудобным: им не понятны сообщения системы, время реакции ее велико, возможности неочевидны и трудноиспользуемы и т.п. Для устранения подобных ситуаций целесообразно освободить пользователей от любой технической работы, непосредственно не связанной с областью экспертизы (работа с операционной системой, сопровождение словарей, взаимодействие с "недружественным" редактором). Недопустимо использовать аббревиатуры.
3. Если правил больше нескольких сотен, возникают затруднения с дальнейшей корректировкой и добавлением их, так как внесение одних изменений порождает цепь других, процесс перестает быть управляемым и кажется бесконечным. Выход из подобных ситуаций разработка системы сопровождения, запоминающей, какие задачи решены, какие получены результаты, какие правила использованы, когда и какие изменения внесены и т.п.
5. Способы интеллектуализации САПР
До последнего времени все САПР работали по "жестким" алгоритмам, в которых строго регламентирована постановка задачи и ее реализация. Однако такой подход не позволяет решать ряд важных для автоматизации проектирования вопросов: например, обеспечивать реализацию опыта пользователя в процессе проектирования, формализовать постановку разнообразных по содержанию задач проектирования в рамках одной САПР, обеспечивать взаимодействие ЭВМ и пользователя на языке, близком к естественному, и др. В связи с этим в САПР начинали получать распространение "мягкие" алгоритмы проектирования, в которых основная роль принадлежит не логике вычислений по цифровым, логико-математическим моделям, а семантике и прагматике семиотических, логико-лингвистических моделей. Теоретическую основу логико-лингвистических моделей и алгоритмов их обработки составляют методы ИИ.
Под интеллектуализацией САПР понимается разработка и программная реализация этих моделей и алгоритмов с целью решения задач автоматизированного проектирования. Интеллектуализация САПР возможна тремя способами:
1. Внешняя универсальная интеллектуализация с помощью инструментальных систем ИИ (ИСИИ). В этом случае к САПР подключается ИСИИ, настроенная на соответствующую предметную область (конструирование, технология и т.д.). В качестве ИСИИ могут использоваться различные оболочки экспертных, диалоговых, обучающих систем и т.д. Главное достоинство этого способа интеллектуализации высокая скорость разработки и малые финансовые затраты. Однако практика показала, что качество таких систем (скорость работы, требуемая память, надежность, мощность, учет всех особенностей предметной области) невысокое и ими можно пользоваться лишь как прототипами реальных систем на начальных этапах их разработки.
2. Внешняя специализированная интеллектуализация с помощью специализированных программных приставок, работающих на принципах ИИ. Этот способ целесообразно применять как развитие предыдущего в тех случаях, когда предъявляются повышенные требования к качеству работы интеллектуальной приставки либо когда нет соответствующих инструментальных интеллектуальных систем, с помощью которых можно было бы сгенерировать нужную приставку, либо когда сложно или невозможно состыковать САПР и инструментальные средства ИИ.
Данный способ, как и предыдущий, обычно не требует существенного изменения внутренней структуры и алгоритмов интеллектуализируемой САПР, поскольку внешняя интеллектуализация сводится, как правило, к улучшению сервисных характеристик САПР возможности формулировки типовой задачи проектирования на предметно-ориентированном языке (языке "деловой прозы"), более близком к естественному, чем обычные языки проектирования САПР, организации интеллектуального диалога с пользователем в процессе проектирования, организации обучения пользователя и т.д. Совокупность средств общения пользователя с САПР на предметно-ориентированном языке называется интеллектуальным интерфейсом.
3. Внутренняя интеллектуализация с помощью встроенных в САПР алгоритмов и методов ИИ. В отличие от двух предыдущих этот способ интеллектуализации затрагивает глубинные свойства САПР, прежде всего ее функциональные возможности проектирования, в том числе возможности синтеза, адаптации, самоорганизации, работы с нечеткой формулировкой задачи и т.д. В этом случае САПР с самого начала должна разрабатываться с учетом требований ее интеллектуализации, т.е. с применением соответствующих способов представления знаний и методов их обработки.
6. Архитектура интеллектуальных САПР
Архитектура обычных САПР. Под архитектуройCAПPбудем понимать систему концепций, определяющих построение структуры САПР и принципы ее функционирования. Архитектура обычных САПР включает следующие концепции:
· описание объекта и задач проектирования с помощью формализованных фиксированных символьно-цифровых языковых конструкций;
· ориентация работы САПР на жесткую, формализованную постановку задачи проектирования;
· использование процедуры моделирования в проектирующих (не конструкторских) САПР как основы процесса проектирования;
· использование "жестких", неадаптируемых и не учитывающих опыт пользователя алгоритмов проектирования и конструирования;
· фиксированная адаптируемая организация функционирования структуры САПР, задаваемая заложенными в САПР процедурами (управление с помощью алгоритмов);
· использование в качестве основы математического аппарата теории численных методов, теории множеств, имитационного моделирования;
· представление внутренней информации в САПР в основном в численном виде;
· использование традиционных языков программирования;
· хранение больших объемов информации в виде сосредоточенных или распределенных баз данных;
· представление выходной информации в основном в гиде алфавитно-цифровых таблиц, графиков или чертежей.
В состав структуры обычных САПР входят: блок трансляции конструкций входного языка; блок основной проектной процедуры (моделирования, трассировки, размещения и т.д.); блоки обработки результатов основной проектной процедуры (расчет, анализ, оптимизация); база данных.
Перечисленные особенности архитектуры обычных САПР пришли в противоречие с потребностями практики автоматизированного проектирования, что послужило основной причиной разработки новых концепций, положенных в основу интеллектуальных САПР.
7. Основные концепции интеллектуальных CAПP
1. Входная информация представляется в виде фраз на ограниченном естественном языке или на предметно-ориентированном языке, допускающем описание пользователем не только объекта задания на его проектирование, как в обычных САПР, но и самого алгоритма проектирования. Тем самым достигается высокая функциональная гибкость ИСАПР, возможность постановки и решения самых различных задач проектирования в рамках заданной предметной области. Данная концепция получила название "интеллектуального интерфейса".
Постановка задачи может быть не только достаточно свободной, по даже в определенных рамках нечеткой или некорректной для данной САПР. Эти недостатки в постановке задачи могут устраняться либо "по умолчанию" автоматически, либо путем диалога с пользователем, в процессе которого или ИСАПР настраивается на предложенную пользователем постановку задачи, или пользователь настраивает задачу на возможности ИСАПР, устраняя указываемые ею нечеткости или некорректности.
2. Информация представляется не в виде данных, т.е. чисел, а в виде знаний, т.е. характеризуется внутренней независимой от пользователя интерпретируемостью, структурированностью, ситуативными связями. Эта концепция влечет за собой: представление и обработку информации не только в числовом, но и в символьном виде; переход к языкам программирования, удобным для работы с символьной информацией (Си, Лисп и др.); разработку и применение в ИСАПР способов представления информации в виде знаний правил продукции, фреймов, семантических сетей; хранение информации в виде баз знаний, частью которых могут быть базы данных. При этом важным принципом функционирования ИСАПР является четкое разделение знаний и данных (смысловой и числовой информации) как в процессе хранения, так и в процессе использования.
3. Активность знаний выражается в том, что ИСАПР функционируют под управлением не алгоритмов (процедур), а данных. Это означает, что диспетчирование работы отдельных подсистем ИСАПР выполняется не с помощью внешней управляющей программы, а автоматически по факту наличия или отсутствия необходимых для работы этих подсистем данных или знаний. Вместо программного управления работой ИСАПР в этом случае используются процедуры контроля необходимой информациикак только она появляется, автоматически срабатывают процедуры ее обработки. Тем самым достигается гибкость и эффективность работы ИСАПР, реализуется принцип "наискорейшего информационного подъема" от исходных данных к конечному результату, самоорганизация работы САПР. По существу, в этой концепции выражен один из основных принципов практики"информация побуждает к действиям".
4. Представление информации в виде знаний, а не чисел приводит к тому, что ее обработка выполняется не численными, а логическими методами. В связи с этим основным математическим аппаратом ИСАПР является аппарат алгебры логики и его специфические алгоритмы дедуктивного или индуктивного логического вывода в условиях детерминированной, нечеткой или вероятностной информации.
5. Ориентированы ИСАПР не на процедуры моделирования и анализа, а на процедуры синтеза. В связи с этим в ИСАПР используются процедуры, характерные для решения задач синтеза. К ним относятся процедуры дедуктивного вывода от общего к частному декомпозиция, детализация, конкретизация, практическими примерами которых могут быть декомпозиция исходной задачи на подзадачи, доказательство теорем, построение графов задач, поиск знаний по образцу, составление документации.
Наряду с дедуктивными в ИСАПР используются и процедуры индуктивного вывода композиция, агрегирование, обобщение, практическими примерами которых могут быть формирование целого из частей, формализация эвристических знаний, выявление сущностей и построение понятий и т.д. Таким образом, математический аппарат ИСАПР характеризуется широким использованием методов обработки знаний с помощью процедур дедуктивного и индуктивного вывода.
6. Входная и выходная информация представляются с использованием принципов когнитивной психологии, нашедших практическое выражение в виде ряда специальных приемов визуального отображения информациииерархических меню, многооконного графического интерфейса, принципа "резиновой нити" при решении задач трассировки соединений на печатных платах, различные способы образного отображения действия пользователя и их результатов. Перечисленные приемы составляют вторую, графическую часть "интеллектуального интерфейса".
7. Обладают ИСАПР мощной системой интеллектуальной поддержки пользователя в виде экспертных систем, консультирующих пользователя по широкому кругу вопросов, касающихся эксплуатации ИСАПР и методики проектирования. Сюда входит диагностика ошибок пользователя и сбоев работы ИСАПР, выдача советов пользователю при постановке задачи и ее решении, обучение пользователя и т.д.
8. Сравнивая ИСАПР с традиционными САПР, следует отметить различный подход в них к описанию объекта проектирования пользователем (внешнее представление объекта) и представлению этого же объекта внутри программы (внутреннее представление объекта).
Заключение
Основой интеллектуальных технологий сегодня является обработка знаний. Системы, ядром которых является база знаний или модель предметной области, описанная на языке сверхвысокого уровня, приближенном к естественному, называют интеллектуальными. Будем называть такой язык сверхвысокого уровня языком представления знаний (ЯПЗ).
Чаще всего интеллектуальные системы применяются для решения сложных задач, где основная сложность решения связана с использованием слабо-формализованных знаний специалистов-практиков и где логическая (или смысловая) обработка информации превалирует над вычислительной.
Например, понимание естественного языка, поддержка принятия решения в сложных ситуациях, постановка диагноза и рекомендации по методам лечения, анализ визуальной информации, управление диспетчерскими пультами и др.
Фактически сейчас прикладные интеллектуальные системы используются в десятках тысяч приложений. Наиболее распространенным видом ИС являются экспертные системы.
Список литературы
1. Башмаков, А.И. Интеллектуальные информационные технологии: учеб. пособие / А.И. Башмаков, И.А. Башмаков - М.: Изд-во МГТУ им. Н.Э. Баумана, 2005. - 304 с.
2. Гаврилова, Т.А. Базы знаний интеллектуальных систем / Т.А. Гаврилова, В.Ф. Хорошевский. - СПб.: Питер, 2001. - 384 с.
3. Девятков, В.В. Системы искусственного интеллекта: учеб. пособие для вузов / В.В. Девятов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2001. - 352 с.
4. Романова, И.В. Разработка "Экспертной системы для определения уровня яркости электросветосигнальных огней аэродрома и значения вероятности взлета и посадки самолетов при плохих метеорологических условиях" / И.В. Романова // Анализ и синтез механических систем. - Омск: Изд-во ОмГТУ, 2006. - С.12-18.
5. Фейгина, Е.М. Представление знаний в системах искусственного интеллекта / Е.М. Фейгина. - Омск: Изд-во ОмГТУ, 1999. - 88 с.
6. Янишевская, А.Г. Электронный учеб. "Искусственный интеллект" / А.Г. Янишевская, И.В. Романова, И.С. Крысов. - М.: ВНТИЦ, 2005. - №50200500251.
Размещено на Allbest.ru
Подобные документы
Структура и классификация систем автоматизированного проектирования. Виды обеспечения САПР. Описание систем тяжелого, среднего и легкого классов. Состав и функциональное назначение программного обеспечения, основные принципы его проектирования в САПР.
курсовая работа [37,7 K], добавлен 18.07.2012Понятие и функции систем автоматизированного проектирования (САПР), принципы их создания и классификация. Проектирующие и обслуживающие подсистемы САПР. Требования к компонентам программного обеспечения. Этапы автоматизации процессов на предприятии.
реферат [19,8 K], добавлен 09.09.2015Эволюция систем автоматизированного проектирования от простых средств двухмерного рисования и разработки чертежей до программных продуктов, включающих поддержку цикла разработки и производства изделия. Требования к пользовательскому интерфейсу САПР.
курсовая работа [274,5 K], добавлен 19.12.2014Предпосылки внедрения систем автоматизированного проектирования. Условная классификация САПР. Анализ программ, которые позволяют решать инженерные задачи. Система управления жизненным циклом продукта - Product Lifecycle Management, ее преимущества.
контрольная работа [1,3 M], добавлен 26.09.2010Требования, предъявляемые к техническому обеспечению систем автоматизированного проектирования. Вычислительные сети; эталонная модель взаимосвязи открытых систем. Сетевое оборудование рабочих мест в САПР. Методы доступа в локальных вычислительных сетях.
презентация [1,1 M], добавлен 26.12.2013Понятие искусственного интеллекта. Представление знаний и разработка систем, основанных на знаниях. Распознавание образов и машинный перевод. Нейрокомпьютеры и сети. Экспертные системы, их структура,классификация и инструментальные средства построения.
курсовая работа [922,1 K], добавлен 12.01.2009Применение средств САПР для создания связи баз данных с чертежом. Создание связи между таблицами базы данных. Разработка команды САПР AutoСAD для гидромотора. Ввод промежуточных параметров. Определение полярных координат точек, секция отрисовки.
курсовая работа [1,8 M], добавлен 28.01.2016Основные цели и принципы построения автоматизированного проектирования. Повышение эффективности труда инженеров. Структура специального программного обеспечения САПР в виде иерархии подсистем. Применение методов вариантного проектирования и оптимизации.
презентация [259,7 K], добавлен 26.11.2014Технологии автоматизированного проектирования, автоматизированного производства, автоматизированной разработки и конструирования. Концептуальный проект предполагаемого продукта в форме эскиза или топологического чертежа как результат подпроцесса синтеза.
реферат [387,2 K], добавлен 01.08.2009Роль интеллектуальных информационных систем в развитии общества. Проблемы концептуального классификационного моделирования для систем, основанных на знаниях. Иерархическая структура универсума. Интенсиональность и параметричность классификации, структура.
реферат [15,4 K], добавлен 19.02.2011
