Нечеткая логика на практике. Статья о нечеткой логике обычно грешит двумя вещами

• Название: Статья о нечеткой логике обычно грешит двумя вещами
• Дата: 27.02.2023
• Размер: 2.11 Mb.
• Имя файла: Нечеткая логика на практике.docx
• Тип: Статья; #957319
• страница: 8 из 10

4. Применение

4.1. Области применения баз нечетких правил

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

— сохраняется возможность воздействия на процесс (управляемость процесса);

— существует накопленный опыт и проверенные знания;

— переменные (входы и выходы) можно измерять и наблюдать (измеримость);

— качественная экспертная оценка (если она математическая, то необходимо выбрать традиционное автоматическое управление);

— последовательная экспертная оценка (если она дискретная, то больше подходит использование экспертных систем).

4.2. Разработка приложения

Выбор операторов

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

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

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

Методология

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



Рис. 20. Методология разработки

Построение базы знаний

Этот процесс состоит из трех этапов:

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

— составление перечня качественных оценок, которые принимаются к рассмотрению и определяют, когда они являются истинными, а когда ложными: эти оценки станут лингвистическими термами базы правил;

— составление формулировок правил: они должны описывать поведение в каждом конкретном случае.

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

Обоснование базы знаний

Этот процесс состоит из нескольких этапов:

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

— симуляция «открытого контура»: эксперты сравнивают поведение базы правил с ожидаемым поведением;

— если процесс можно симулировать, то выполняется и симуляция «замкнутого контура».

Настройка

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

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

— если поведение необходимо оптимизировать производительность, обычно достаточно соответствующим образом настроить функции принадлежности;

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

4.3. Использование приложения

Функции оператора

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

Необходимо учитывать следующие особенности:

— полностью автономная система: конечный пользователь незнаком с нечеткой логикой и не осведомлен о ее использовании;

— блок управления с нечеткой логикой выполнен в виде «черного ящика» и может быть отсоединен или переведен в режим ручного управления оператором;

— оператор может модифицировать (настроить) функции принадлежности в зависимости от ситуации или может изменять производительность (например);

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

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

Изменение производительности

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

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

— изменяются размеры системы; необходимо изменить функции принадлежности;

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

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

4.4. Выбор применяемой технологии

Большинство современных приложений работают на стандартных аппаратных платформах (микроконтроллеры, ПЛК, микропроцессоры, микрокомпьютеры, и т.д.).

Разработано разнообразное ПО, предназначенное для построения баз нечетких правил для микроконтроллеров, ПЛК и микрокомпьютеров и позволяющее быстро создавать базы правил.

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

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

— операции, которые применяются для обработки нечеткого логического вывода, являются элементарными и выполняются над целыми числами;

— некоторые операции могут выполняться параллельно;

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

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

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

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

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



Рис. 21. Производительность компонентов и области применения

4.5. Стандарты

Компоненты

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

Программное обеспечение

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

В настоящее время рабочая группа, разрабатывает совместный стандарт языка «Нечеткая логика» для программируемых контроллеров (первая официальная редакция стандарта МЭК 61131-7 вышла в 1997). Другие инициативы в области стандартизации нечеткой логики должны также опираться на данный стандарт.