Читайте также:
|
Кабельные линии непосредственно после их сооружения и в процессе эксплуатации подвергаются испытаниям, с помощью которых выявляются ослабленные места или дефекты в изоляции и защитных оболочках кабелей, соединительной и концевой арматуре.
Причины возникновения таких ослабленных мест весьма различны. Они могут возникать при изготовлении кабеля на заводе-изготовителе, при прокладке кабелей и изготовлении кабельной арматуры в процессе монтажа кабельной линии. Ослабленные места в кабельных линиях возникают и в процессе эксплуатации из-за старения изоляции кабелей, коррозии оболочек кабелей, механических повреждений и др. Ослабленные места и дефекты имеют скрытый характер и под воздействием рабочего напряжения постепенно могут привести к аварийному выходу из строя кабельную линию.
В процессе испытания обращают внимание на характер изменения тока утечки. Кабельные линии считаются выдержавшими испытания, если не про-изошло пробоя и толчков тока утечки или его нарастания, после того как ток достиг установившегося значения. До и после испытаний повышенным напряжением измеряют сопротивление изоляции кабелей, которое не нормируется.
Сопротивление изоляции кабелей измеряют мегаомметром на напряже-ние 2500 В включенным по схеме между каждой жилой и жилами, соединен-ными с металлической оболочкой и броней кабеля. Для силовых кабелей на-пряжением до 1000 В сопротивление изоляции нормируется и должно быть не менее 0,5 МОм. Испытания кабелей повышенным напряжением не выявляют все слабые места изоляции новой кабельной линии. Некоторые дефекты монтажа и изготовления кабелей и муфт постепенно приводят к ослаблению изоляции и пробою.
КЛАССИФИКАЦИЯ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ
Не содержат встроенных средств, специально предназначенных для реализации ЭС, но позволяют разработать наиболее эффективный код, хотя и за более длительный период. Поэтому, как правило, ЭС не создаются с нуля на традиционных ЯП: первые прототипы (демо, исследовательский и даже действующий) пишутся на высокоуровневых средствах, например, оболочках ЭС. Лишь на стадии коммерческого или промышленного прототипов часть кода ЭС или даже вся ЭС переписывается на языках низкого уровня, т.е на традиционных ЯП. (см. концепцию быстрого прототипа)
Языки ИИ в той или иной мере содержат и в своей парадигме, и в конструкции языка средства, хорошо приспособленные для реализации ЭС. Например, связанные с символьным единообразным представлением, логическим основанием как лиспа, так и пролога + встроенный механизм логического вывода в прологе (метод резолюции). В ООЯ и на уровне представления сложных структур и сложно взаимосвязанных структур данных с учетом иерархии наследования развитой техники сопоставления с образцом при поиске и некоторые другие механизмы адекватны задачам ЭС. Замечание: для фреймового представления знаний наиболее адекватным является ООП, однако в них не встроен механизм логического вывода и отсутствует различные варианты наследования (same, unique, range), за исключением традиционного (override), когда потомки могут не только добавить свои свойства и методы и понаследовать родительские, но и переопределить родительские свойства и методы.
Специально разрабатывались, а именно для представления знаний и организация логического вывода знаний, поэтому в них зашиты изначально базовые примитивы для представления семантических сетей, фреймов, продукций и организации логического вывода для них
Как следует из пред. Лекции архитектура оболочки ЭС совпадает с ЭС за исключением отлаженной БЗ. Поэтому по сравнению с другими категориями инструментальных средств, здесь автоматизированы все процессы создания ЭС и акцент делается лишь на заполнении БЗ, которая, собственно, является программой ЭС. Поэтому напрямую разработчикам ЭС в случае использования оболочек может выступать пользователь не программист. Мы не стали отделять оболочки от средств автоматизации проектирования ЭС, т.к. современные оболочки ЭС зачастую содержат встроенные высокоуровневые средства автоматизации их проектирования и наоборот. Но несмотря на то, что оболочки самые высокоуровневые средства создания ЭС, им присущи 2 основных недостатка:
a. Встроенные в них механизмы не всегда адекватны специфике решаемой задачи и принятому в соответствующей предметной области стилю рассуждения эксперта
b. Более низкая эффективность результирующего кода
c. Кроме того, ЭС поставляется вместе с её оболочкой
Выходом из 1 недостатка является использование универсальных и настраиваемых оболочек ЭС. В случае настраиваемых оболочках ЭС имеется конечный набор различных вариантов реализации различных компонентов ЭС, в том числе и в разных парадигмах, но после их интеграции заполнение и отладка БЗ ведется в выбранной парадигме с выбранными настройками. В случае универсальных оболочек ЭС (LOOPS,KEE,ART), которые в разной степени интеграции интегрируют в себе различные парадигмы представления знаний: продукции, логика, сем сети, фреймы, – и разные парадигмы функционирования: процедурную (активные функции, пассивны данные), объектно-ориентированную (активные данные и функции одинаково), ориентированную на данные (активные данные), ориентированную на знания, например, продукционно-ориентированную (активные знания, пассивен МЛВ).
Классификация приведена в порядке уменьшения трудозатрат и времени разработки ЭС, в порядке уменьшения требований к квалификации разработчика, а также в порядке понижения эффективности результирующего кода.
Интеграция продукций с фреймами:
If <имя фрейма><имя слота> = «»
Фрейм «Экзамен»
| Frame Преподаватель | Frame Студент | Предмет | Билет = счастливый | Аудитория = удобная | Оценка =? |
If (Преподаватель = «не требовательный») & (Студент = «середнячок») then Оценка = «5»
Разработку любой сколь угодно сложной ЭС всегда надо рассматривать как эксперимент без надежной гарантии успеха в установленные сроки, т.к. на заключительной стадии разработки может оказаться, что выбранные методы инженерии знаний не подходят для адекватного решения всех поставленных задач. Почему? Ввиду неформальности решаемой задачи, ввиду отсутствия в среде универсальных оболочек механизмов, позволяющих автоматизировано выбрать той или иной специфики решаемой задачи адекватного средства представления и вывода. Т.е. понятие «универсальности» оболочек ЭС отличается от понятия универсальности в традиционных системах, где для решения любой алгоритмически разрешимой задачи гарантированно подойдет любой универсальный ЯП (не касаемся вопросов учета инфраструктуры).
Осталось:
Работа с БД в гуру:
txt vopros 1| ….|
otvet 1|Вар 1|
b. Создать БД
c. Выполнить Data transfer
d. Использовать
e. var
information manager -> data manager -> table structuring -> build new structure тут создали
information manager -> data manager -> data transfer
САМАЯ СЕРЬЕЗНАЯ РЕКОМЕНДАЦИЯ связана с тем, что …, а начать с одного поддерева дерева цели, вершиной которого будет одна подцель, которая и будет в начале отладки целью консультации.
Мин. Уровень требований к БЗ:
Правил не менее 50, но при этом акцент делать не на расширении знаний по горизонтали, а на углубленное представление знаний по некоторым веткам по вертикали. Не менее 5 веток.
Этапы проектирования:
Общие технологии разработки ЭС, кроме как концепции быстрого прототипа подразумевает, что разработчики создают не один, а с разу несколько прототипов ЭС на её различных стадиях:
· Демонстрационный прототип
· Исследовательский прототип
· Действующий прототип
· Промышленный прототип
· Коммерческий прототип
отличающихся как объемом отлаженного ТЗ, так и требованиями надежности, эффективности, качества интерфейса, юзабилити.
Например, в случае демо-прототипа, БЗ должна иметь 50-100 правил, при этом система может быть неустойчива в работе, не эффективна и требования к интерфейсу пониженные.
Далее идет наращивание БХ поэтапное и повышается требование к надежности и эффективности программного кода.
Только на стадиях промышленного и коммерческого прототипа особое внимание уделяется интерфейсу. Поэтому первый прототип ЭС пишется на инструментальных средствах (ИнСр) высокого уровня, например в среде оболочек ЭС, а тиражируемые, близкие к промышленной стадии проектирования переписываются на языках низкого уровня, но при этом!!! БЗ не переписывается по содержанию, хотя может измениться язык представления знаний. Поэтому целью концепции быстрого прототипа является распараллеливания процессов отладки БЗ и выбора/создания с нуля средства представления знаний.
Из-за неформального характера решаемых задач, неформального характера подбора ИнСр создания ЭС и отсутствия в традиционном понимании этого слова универсальных ИнСр создания ЭС (хотя сущ-ет универсальная оболочка ЭС), в случае сложной проблемной области решаемой задачи у заказчика нет надежной гарантии того, что данная задача может быть решена в установленные сроки или даже вообще может быть адекватно решена методами инженерии знаний.
Поэтому технологии создания ЭС подразумевает следующие этапы:
1. Идентификации: составление словаря используемых понятий, включающий вариант допустимых значений, понятия обобщающего и детализирующего характера
2. Концептуализации, когда устанавливаются типы связей между понятиями и словаря и представляется в графическом виде, например, дерево целей и/или графа, семантической сети.
3. Формализации: представление знаний, спроектированных на этапе концептуализации, в выбранном формализме на соответствующем языке представления знаний: продукция, фреймы, семантические сети, логика.
4. Реализация, тестирование, отладка
Отлаживать ЭС (её БЗ) надо начинать еще до этапа формализации и даже параллельно с другими этапами, когда становится понятной хотя бы одна подцель.
АРХИТЕКТУРА ЭКСПЕРТНЫХ СИСТЕМ
 | |||
 | |||
КПЗ позволяет КАК МИНИМУМ среде текстового редактора в соответствии с синтаксисом языка представления знаний пополнять БЗ ЭС между консультациями. В развитых ЭС КПЗ позволяет заполнять БЗ в автоматизированном режиме, используя для этого либо продвинутую технику сопоставления с образцом, либо вопросно-ответный вариант, либо ЕЯ компоненту (на ест. языке). В современных ЭС роль КПЗ зачастую берет на себя компонента извлечения знаний, где активно используется технология DataMining.
DM – технология извлечения данных из структурированных данных, типа БД, электронных таблиц. Еще есть TextMining и WebMining, которые позволяют извлекать данные из веб-страниц и анализировать структуру… таким образом, автоматизируется процесс пополнения БЗ. Компонента DM строит исходя из данных за много лет в электронных таблицах по таким показателям, как температура, состав почвы и т.д. В современных динамических ЭС с элементами самообучения непосредственно сами ЭС способны пополнять свою БЗ новыми фактами и правилами. Например, такую систему можно сделать на основе метазнаний, но при этом автоматически сохраняется авторство правил и система способна настраиваться на работу с учетом этих правил или без, пока человек-эксперт не переведет эти знания в «человеческие».
МЛВ является встроенным и, несмотря на то, что является отдельным компонентом ЭС, его функционирование управляется другим компонентом, а именно БЗ, фактами + настройки системы, управляющей выводом:
· Стратегия направления вывода (например, в продукционных системах это прямой, обратный, комбинированный)
· Стратегия выборки правил (фифо, лифо, приоритет и др.)
· Стратегия означивания посылки (e.tryp) – после означивания каждого факта посылки правила делается попытка проверки истинности посылки, и в случае истинности правила исполняются несмотря на то, что в посылке могли остаться неозначенные факты. Passion - сначала вычисляются все факты в посылке, лишь потом она проверяется, при этом допускается, что остались неозначенные факты. Strong (стоит по умолчанию) – аналогично passion, но все факты должны быть не UNKNOW. (UNKNOW: e.unkn – задает порог «известности», т.е. читается не просто значение <> UNKNOW, а с учетом доверия, не менее порогового). На основе правил из БЗ и фактов, полученных от пользователя в ходе консультации, МЛВ пытается с учетом соотв. установок построить такую каузальную цепочку правил, которая в результате доказывает цель консультации.
· Стратегия тщательности вывода (абс, мин, средняя)
Компонента объяснения (см. лекцию отличия ЭС от традиционных систем)
В соот. с ходом логического вывода выдает на ЕЯ аргументацию, обоснование применяемого правила. Эта аргументация извлекается из БЗ экспертов и является её важной частью.
Рабочая память (база фактов)
Не путать с БД! Т.к. БД – это долговременное хранилище фактов и отделенное от приложения. Рабочая память – кратковременное на время консультации хранилище фактов, полученных от пользователя и фактов, выведенных системой в ходе консультации. Кроме того, БЗ многих ЭС помимо собственно знаний хранят долговременную базу фактов, например, знания описательного характера в виде фактов. Кроме того, в РП хранятся данные об использованных, откатившихся правилах, их ризоны, другая вспомогательная инфа, которая позволяет компоненте объяснения выводить адекватно ходу соот. вывода и оптимизировать ход вывода, сокращая пространство поиска. Конфликтный набор правил тоже размещается в РП.
Интерфейс конечного пользователя, эксперта и инженера по знаниям может различаться, т.к. конечному пользователю обычно не предоставляется возможность изменять БЗ системы, т.е. для него доступен зачастую только режим консультации, объяснения и обучения.
Архитектура ОБОЛОЧЕК ЭС практически полностью повторяет архитектуру ЭС, за исключением заполненной и отлаженной БЗ. Как следствие, обычно ЭС созданы под управлением оболочек, не являются независимыми и поставляются вместе с оболочками.
Коротко, об экспертах и инженерах по знаниям (ИПЗ). Если в качестве инструментального средства создания ЭС используется оболочка ЭС, то в команде разработчиков может отсутствовать программист, но эксперт и ипз должны присутствовать обязательно.
Т.о. в отличие от традиционных программ разработчиками ЭС напрямую пополняющую БЗ может быть не программист. ИПЗ – это специалист в области не только программирования (программной инженерии или прикладная информатика в областях), лингвистики и психологии. При прочих равных условиях предпочтении отдается тем ИПЗ, у которых наиболее развиты коммуникативные способности и толерантность, т.к. именно ИПЗ ответственен за извлечение знаний из экспертов. Кроме того, ИПЗ должен уметь работать с различными инструментальными средствами ЭС в использовании и создании и должен способен настраивать их для решения конкретной задачи. К эксперту есть более формализованные требования.
1. Помимо высокого уровня квалификации в узкой предметной области экспертизы (уровень должен быть значительно выше среднего и общепризнанный),
2. на начальных этапах разработки должен до половины времени уделять разработки, а последующих не менее 1/3 тестированию,
3. должен быть заинтересован (морально и материально)
4. должен верить в успех проекта
5. Самое главное, должен быть способен ВЕРБОЛИЗОВАТЬ свои знания, затратив на это достаточно времени.
Рассмотренная выше классификация ИССЭС сохраняется для различных вариантов реализации как СПЗ (средство представления знаний), так и парадигму функционирования, а также в случае разработки ЭС с интегрированным представлением знаний (такие системы сами автоматически способны в ходе вывода определиться с тем, в какой парадигме представлен текущий фрагмент БЗ и автоматически переключить парадигму функционирования в ходе логического вывода).
Дата добавления: 2014-12-19; просмотров: 52 | Поможем написать вашу работу | Нарушение авторских прав |