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

Автор работы: Пользователь скрыл имя, 24 Ноября 2013 в 15:05, курсовая работа

Краткое описание

Степень интеграции элементов в микросхемах на сегодняшний день очень высока. В результате этого развития появились многофункциональные микросхемы, называемые микроконтроллерами. Они могут объединять себе микропроцессор, АЛУ, порты ввода/вывода, ПЗУ, ОЗУ и т. д. С помощью таких микросхем можно создавать сложные системы управления технологическими процессами. В качестве объектов управления могут быть практически любые устройства, в том числе и трехпозиционные термостаты. Цель данной курсовой работы ознакомиться с устройством микроконтроллера ATmega 128 и получить навыки разработки управляющих устройств. А так же укрепить знания в области программной части микроконтроллера и его программирования.

Содержание

1. Введение………………………………………………………………………3
2. Содержание задания (исходные данные)…………………………………...4
3. Описание элементов системы……………………………………………….5
3.1 Описание объекта управления……………………………………………..5
3.2. Описание микроконтроллера ATmega128………………………………..5
4. Описание системы индикации……………………………………………...15
4.1 Светодиоды ………………………………………………………………...15
4.2 Описание кнопок…………………………………………………………...15
5. Алгоритм управления………………………………………………………..16
6. Заключение…………………………………………………………………...17
7. Используемая литература……………………………………………………18

Прикрепленные файлы: 11 файлов

fАлександровисправленный_447153.doc

— 248.00 Кб (Просмотреть файл, Скачать документ)

~$служивание_стабиллизатора[1].doc

— 162 байт (Просмотреть файл, Скачать документ)

~$ФЕРАТ ГАЛАВСКИЙ.doc

— 162 байт (Просмотреть файл, Скачать документ)

Бутакова_Н_Н_0719_7942_6к_11сем_Администрирование в ИС.7z

— 119.76 Кб (Скачать документ)

Бутакова_Н_Н_0719_7942_6к_11сем_Администрирование в ИС.doc

— 261.00 Кб (Просмотреть файл, Скачать документ)

Бутакова_Н_Н_0719_7942_6к_11сем_ГАЛАВСКИЙ ИС.doc

— 382.50 Кб (Просмотреть файл, Скачать документ)

Курсовая работа Шилер.doc

— 2.06 Мб (Скачать документ)

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

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

Программист разрабатывает ИС (если ИС разрабатывается заново), содержащее в пределе все основные компоненты ЭС, и осуществляет его сопряжение с той средой, в которой оно будет использовано.

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

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

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

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

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

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

Решение задачи экспертной системой в режиме консультации состоит из следующих этапов:

      • система задает вопросы пользователю для формулирования задачи;
      • полученные данные сопоставляются с базой данных экспертной системы;
      • система задает пользователю дополнительные вопросы (этапы 2 и 3 могут повторяться);
      • выдача решения пользователю и запрос на необходимость разъяснения.

1.2 Классификация  экспертных систем

Экспертные  системы классифицируются по следующим  параметрам:

  1. По назначению: обучение, автоматизация, диагностика.
  2. По проблемной области.

Проблемная  область – совокупность предметной области и решаемых в ней задач. Задачи предметной области чаще всего определяются их типом: интерпретация;

– предсказание;

– диагностика; 

– конструирование;

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

– слежение;

– управление.

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

  1. По глубине анализа проблемной области:
    • поверхностные, в которых правила имеют следующий вид: если «условие», следовательно «действие». Процесс решения сводится к поиску таких образцов правил, которые сопоставляются с текущими данными в рабочей памяти;
    • глубинные экспертные системы в сравнении с поверхностными обладают следующей особенностью – для ситуации с отсутствием правил, система определяет, какие действия надо выполнить.
  2. По типу используемых методов и знаний:
    • традиционные;
    • гибридные.
  3. По классу:
    • простые (поверхностные традиционные для обычной рабочей станции);
    • гибридные (глубинные гибридные экспертные системы для мощной универсальной ЭВМ или интеллектуальной рабочей станции).
  4. По стадии существования:
    • при проектировании технических информационных объектов;
    • интегрированные в другие программные средства.
  5. По инструментальным средствам, используемым для создания экспертной системы.

 

 

 

 

 

 

 

 

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

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

2.1 Возможность разработки экспертной системы

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

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

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

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

2.2 Оправданность разработки экспертной системы

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

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

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

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

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

2.3 Разумность разработки  экспертной системы

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

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

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

Рисунок 2.1 –  Требования, обеспечивающие разумность применения ЭС

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

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

 

3 Этапы разработки экспертной системы

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

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

Рисунок 3.1 – Этапы  разработки экспертной системы

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

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

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

Обслуживание ИС Кильдибеков Обслуживание_стабиллизатора.doc

— 208.50 Кб (Просмотреть файл, Скачать документ)

Приложение Г (1).doc

— 41.00 Кб (Просмотреть файл, Скачать документ)

ПРОПП_Л_А_0719_6к_1сем_Микропроцессорные системы управления на _курсовая.doc

— 465.00 Кб (Просмотреть файл, Скачать документ)

ПРОПП_Л_А_0719_6к_1сем_Обслуживание информационных систем_курсовая исправленная.doc

— 695.00 Кб (Просмотреть файл, Скачать документ)

Информация о работе Разработка микропроцессорного устройства управления