7991

Разработка программного обеспечения модуля управления и отладки комплекса КИИБ

Курсовая

Информатика, кибернетика и программирование

Комплекс успешно применяется в испытательной лаборатории «Безопасность и ЭМС технических средств» в течение пяти последних лет. Имеется положительный опыт испытаний устройств и систем на базе микроконтроллеров Microchip, Atmel

Русский

2014-11-23

637 KB

4 чел.

Разработка программного обеспечения модуля управления и отладки комплекса КИИБ

СОДЕРЖАНИЕ

[1] Разработка программного обеспечения модуля управления и отладки комплекса КИИБ

[2] СОДЕРЖАНИЕ

[3]
ВВЕДЕНИЕ

[4]
1 НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ КОМПЛЕКСА КИИБ

[5]
2 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МОДУЛЯ УПРАВЛЕНИЯ И ОТЛАДКИ

[5.1] 2.1 Форма управления функционированием ПО - MainView

[5.2] 2.2 Форма просмотра памяти данных устройства – Form_view

[5.3] 2.3 Форма просмотра энергонезависимой памяти устройства – Form_eeprom

[5.4] 2.4 Форма просмотра памяти программ устройства – Form_prog

[5.5] 2.5 Форма выборочного просмотра памяти данных устройства – Form_watch

[5.6] 2.6 Форма отображения состояния выводов устройства – Form_pins

[5.7] 2.7 Форма внесения ошибок в работу устройства – Form_mistakes

[5.8] 2.8 Форма «Об авторе» – Form_author

[6] 3 ТЕСТИРОВАНИЕ МОДЕЛИ PIC16

[6.1] 3.1 Тестирование системы команд

[6.2] 3.2 Тестирование периферийных устройств

[7]
ЗАКЛЮЧЕНИЕ

[8]
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

[9]
ПРИЛОЖЕНИЕ А. ЛИСТИНГ ПРОГРАММЫ ДЛЯ ПРОСМОТРА ПАМЯТИ ПРОГРАММ МИКРОКОНТРОЛЛЕРА


ВВЕДЕНИЕ

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

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

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

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

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

Для решения данных проблем при проведении испытаний программно-технических средств ЖАТ на безопасность функционирования в испытательной лаборатории «Безопасность и ЭМС технических средств» Белорусского государственного университета транспорта разработан «Комплекс для проведения имитационных испытаний микропроцессорных систем железнодорожной автоматики на функциональную безопасность» (КИИБ).

Комплекс аппаратно-программных средств КИИБ предназначен для проведения ускоренных имитационных испытаний на функциональную безопасность в соответствии с IEC 61508, EN 50126, ОСТ 32.146 микропроцессорных систем управления ответственными технологическими процессами, в том числе систем управления движения поездов.

Комплекс успешно применяется в испытательной лаборатории «Безопасность и ЭМС технических средств» в течение пяти последних лет. Имеется положительный опыт испытаний устройств и систем на  базе микроконтроллеров Microchip, Atmel, цифровых сигнальных процессоров ADSP и др., в том числе многопроцессорных систем. Применение КИИБ при экспертизе и испытаниях позволило обнаружить ряд неисправностей, приводящих к опасному отказу устройства в целом. Некоторые из них, например отказы в микропроцессорной системе ССС-200-60, не были обнаружены при использовании других методов экспертизы и испытаний.

Тем не менее, данная версия КИИБ имеет ряд недостатков, среди которых отсутствие графической оболочки и работа на устаревшей платформе (библиотеки VCL). Главным недостатком КИИБ является проблемный механизм расширения базы моделей микроконтроллеров, что обусловлено внутренней структурой комплекса.

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


1 НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ КОМПЛЕКСА КИИБ 

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

Основными особенностями отказов в программируемых элементах являются:

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

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

Для анализа на безопасность микропроцессорных систем управления в испытательной лаборатории «Безопасность и ЭМС технических средств» Белорусского государственного университета транспорта была разработана новая версия «Комплекса для проведения имитационных испытаний микропроцессорных систем (МПС) железнодорожной автоматики на функциональную безопасность» КИИБ, в которой устранены недостатки предыдущей версии. Структурная схема КИИБ 4.0 представлена на рисунке 1.1.

КИИБ позволяет контролировать:

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

С помощью КИИБ можно проводить:

  •  функциональные испытания МПС (проверка полноты и корректности выполнения основных функций);
  •  испытания на функциональную безопасность технологических алгоритмов, реализованных программным способом;
  •  испытания на функциональную безопасность программного обеспечения МПС;
  •  испытания на функциональную безопасность МПС.

Блок загрузки выполняет подготовку работы системы моделирования и тактирование работы устройств. Непосредственно после запуска этого блока производится загрузка файлов модели, конфигурации и программ, в соответствии с которыми блоком формируются модели устройств.

Блок коммутации и протоколирования предназначен для передачи информации между элементами комплекса и создания протокола обмена сигналами между устройствами в виде файла *.stl.

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

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

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

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

Разработанная структура для новой версии КИИБ позволяет устранить такие недостатки предыдущей версии, как отсутствие средств визуализации и узкая специализация используемых моделей.


2 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МОДУЛЯ УПРАВЛЕНИЯ И ОТЛАДКИ

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

Общую структуру ПО можно представить следующим образом:

  •  Форма управления функционированием ПО (MainView) – главная форма, с ее помощью можно управлять работой остальных перечисленных ниже форм;
  •  Форма просмотра памяти данных устройства (Form_view);
  •  Форма просмотра энергонезависимой памяти устройства (Form_eeprom);
  •  Форма просмотра памяти программ устройства (Form_prog);
  •  Форма выборочного просмотра памяти данных устройства (Form_watch);
  •  Форма отображения состояния выводов устройства (Form_pins);
  •  Форма внесения ошибок в работу устройства (Form_mistakes);
  •  Форма «Об авторе» (Form_author);

2.1 Форма управления функционированием ПО - MainView

Внешний вид разработанной формы представлен на рисунке 2.1.

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

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

Вкладка «File» объединяет функции, позволяющие выполнять работу с файлами, необходимыми для создания модели (рисунок 2.2).

     Вкладка «Tools» отражает все доступные функции по просмотр состояния одной модели устройства (рисунок 2.3).

     Вкладка «AutoTest» содержит функцию запуска режима автоматического тестирования (рисунок 2.4).

     Вкладка «Option» объединяет функции, отвечающие за отладку модели устройства в ручном режиме (рисунок 2.5).

     Вкладка «Help» содержит функцию, вызывающую окно с данными об авторе разработанного проекта (рисунок 2.6).

  •  Блок «Microcontroller» – содержит информационную панель, на которой отражается марка микроконтроллера семейства PIC16, выбранный в качестве действующей модели.
  •  Блок «DLL» – содержит информационную панель, на которой отражены загруженные файлы расширения *.dll. Фактически его загрузка создает новое устройство, которое может участвовать в моделировании. Для управления загрузкой таких файлов имеются кнопки «Add DLL» (позволяет загрузить файл модели устройства) и «Delete DLL» (позволяет удалить выделенное в информационном окне устройство). Перечисленные функции продублированы в главном меню проекта (рисунок 2.2). При нажатии кнопки загрузки файла перед пользователем возникает диалог (рисунок 2.7).

Все поля разработанного диалога, отмеченные «*», являются обязательными для заполнения.

Данный диалог предлагает пользователю указать путь к файлу расширения *.dll; путь к файлу расширения *.cfg, который является файлом конфигурации выбранного микроконтроллера семейства PIC16; путь к файлу расширения *.hex, в котором находится загружаемая в микроконтроллер программа. Предоставляется возможность загрузить файл с вносимыми в работу микроконтроллера ошибками (ini-файл).

Блок CLK предлагает пользователю задать частоты (в МГц), на которых будут работать основные модули устройства: непосредственно сам микроконтроллер (MC), сторожевой таймер (WDT), таймер 1 (Tmr), АЦП (ADC). С помощью кнопки «Прочитать секцию из ini файла» все требуемые параметры могут быть загружены непосредственно из файла.

  •  Блок «Configuration of MC» представлен информационной панелью, на которой отражаются загруженные конфигурации каждой из задействованных моделей устройств. После успешной загрузки файла конфигурации у пользователя появляется возможность просмотра состояния памяти данных устройства (кнопка «Microcontroller View») и его энергонезависимой памяти (кнопка «EEPROM View»). Данные функции доступны и из главного меню (рисунок 2.3).
  •  Блок «Program» представлен информационной панелью, на которой отражаются загруженные файлы программ каждой из задействованных моделей устройств. После успешной загрузки программы появляется возможность просмотра состояния памяти программ выбранной модели устройства (кнопка «Program View»). Данная функция может быть вызвана из главного меню (рисунок 2.3).
  •  Блок «Manual Test» позволяет управлять работой одной модели устройства в режиме ручной отладки. Содержит 4 органа управления: кнопка имитации такта микроконтроллера («CLK for MC»), кнопка имитации такта для сторожевого таймера («CLK for WDT»), кнопка имитации такта для таймера 1 («CLK for TMR1»), кнопка имитации такта для АЦП («CLK for ADC»). Данная функциональность может быть вызвана и из главного меню (рисунок 2.5).
  •  Блок «Auto Test» позволяет управлять работой задействованных в процессе моделирования устройств в автоматическом режиме. В этом блоке для пользователя отражена служебная информация о параметрах моделирования (системное время, тактовая задержка и т.п.). Органы управления процессом автоматического тестирования: кнопка «AutoTest Manager» - запуск автоматического тестирования (данную функцию можно вызвать из вкладки «AutoTest» главного меню проекта); кнопка «All devs clk» - имитация такта работы для всех задействованных в моделировании устройств.

2.2 Форма просмотра памяти данных устройства – Form_view

Внешний вид разработанной формы показан на рисунке 2.8.

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

Поле формы графически разделено на два блока:

1) Блок «Program Counter and W Register» содержит 2 поля, в которых отображаются соответственно регистр Program Counter (программный счетчик) и регистр-аккумулятор W Register.

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

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

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

  •  Адрес регистра в памяти данных в 16-ричном виде (поле Address).
  •  Имя регистра (поле Name).
  •  Значение регистра в 16-ричном виде (поле HexValue).
  •  Значение регистра в двоичном виде (поле BinValue). Каждая из ячеек этого поля отображает бит регистра. Если ячейка красная, значит соответствующий бит установлен в «1», если ячейка погашена – бит в «0».

2.3 Форма просмотра энергонезависимой памяти устройства – Form_eeprom

Внешний вид разработанной формы показан на рисунке 2.9.

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

Сама память отображается в виде матрицы, где в качестве индексов находится 16-ричное значение адреса.

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

  •  Выделить ячейку памяти, в которой требуется изменить значение;
  •  С клавиатуры ввести требуемое 16-ричное значение в область ячейки;
  •  После нажатия кнопки «Enter» введенное значение записывается в выбранную ячейку памяти EEPROM.

2.4 Форма просмотра памяти программ устройства – Form_prog

Внешний вид разработанной формы показан на рисунке 2.10.

Данная форма позволяет пользователю просматривать всю доступную память программ выбранного устройства. Размер памяти зависит от конфигурации устройства.

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

Сама форма содержит несколько информационных полей:

  •  Поле «Address»  - адрес ячейки памяти программ;
  •  Поле «Instruction» - ассемблерный код команды, содержащийся по соответствующему адресу;
  •  Поле «HexValue» - код соответствующей инструкции в 16-ричном виде;
  •  Поле «BinValue» - код этой инструкции в двоичном виде.

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

2.5 Форма выборочного просмотра памяти данных устройства – Form_watch

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

Работа этой формы тесно связана с формой просмотра памяти данных Form_view. Порядок работы с формой Form_watch следующий:

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

Если подтверждение получено, то данный регистр добавляется на форму Form_watch (рисунок 2.12), иначе диалог просто закрывается.

  •  Для удаления регистра с формы выборочного просмотра требуется кликнуть левой клавишей мыши на область, отведенную под данный регистр. Появится диалог, запрашивающий подтверждение на удаление этого регистра из Form_watch (рисунок 2.13).

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

Форма Form_watch (рисунок 2.12) содержит следующие поля:

  •  Поле «DDLs Name» отражает имя модели устройства, в котором находится регистр памяти данных. Форма может работать одновременно с множеством участвующих в моделировании устройств, поэтому для распознавания принадлежности регистра используется имя конкретного устройства.
  •  Поле «Address»- содержит адрес регистра в модели устройства;
  •  Поле «Register's Name» - содержит имя регистра памяти данных;
  •  Поле «HexValue» - значение регистра в 16-ричном виде;
  •  Поле «BinValue» - значение регистра в двоичном виде.

2.6 Форма отображения состояния выводов устройства – Form_pins

Внешний вид формы Form_pins представлен на рисунке 2.14.

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

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

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

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

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

2.7 Форма внесения ошибок в работу устройства – Form_mistakes

Внешний вид формы Form_mistakes представлен на рисунке 2.15.

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

1) Блок «Constant Mistakes» - блок формирования константных ошибок. Содержит поля:

  •  Поле «Address» - адрес регистра, в который требуется внести ошибку;
  •  Поле «Register's Name» - имя регистра, в который требуется внести ошибку;
  •  Поля «7»-«0» - поля каждого бита регистра. Эти поля являются редактируемыми. Они имеют три состояния: «х» - ошибка в бит не вносится; «0» - бит всегда будет установлен в ''0''; «1» - бит всегда будет установлен в ''1''. Изменение состояния происходит по клику левой кнопкой мыши в соответствующем поле.

2) Блок «Montage Mistakes» - блок формирования монтажных ошибок. Содержит поля:

  •  Поле «Address» - адрес регистра, в который требуется внести ошибку;
  •  Поле «Register's Name» - имя регистра, в который требуется внести ошибку;
  •  Поля «7»-«0» - поля каждого бита регистра. Эти поля являются редактируемыми. Они имеют три состояния: «х» - ошибка в бит не вносится; «&» - в бит вносится ошибка монтажное ''И''; «|» - в бит вносится ошибка монтажное ''ИЛИ''. Изменение состояния происходит по клику левой кнопкой мыши в соответствующем поле.

3) Блок «View Mistakes» - блок отображения уже внесенных в работу устройства ошибок. Содержит поля:

  •  Поле «Address» - адрес регистра, в который внесена ошибка;
  •  Поле «Register's Name» - имя регистра, в который внесена ошибка;
  •  Поля «7»-«0» - поля каждого бита регистра. Они имеют пять состояний: «х» - ошибка в бит не вносилась; «0» - бит установлен в ''0''; «1» - бит установлен в ''1''; «&» - в бит внесена ошибка монтажное ''И''; «|» - в бит внесена ошибка монтажное ''ИЛИ''.
  •  Поле «Type» - характеризует тип ошибки. Может содержать следующие показания: «С_And» - константная ошибка ''И''; «С_Or» - константная ошибка ''ИЛИ''; «М_And» - ошибка монтажное ''И''; «М_Or» - ошибка монтажное ''ИЛИ''.

Органы управления формой Form_mistakes:

  •  Кнопка «Add mistakes» - осуществляет внесение сформированных в блоках «Constant Mistakes» и «Montage Mistakes» ошибок в работу устройства;
  •  Кнопка «Update» - обновление информации об уже внесенных в устройство ошибках.

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

1) Форма Form_mistakes тесно связана с формой просмотра памяти данных Form_view. Для добавления необходимого регистра на форму внесения ошибок требуется вызвать форму Form_view. С помощью клика левой кнопкой мыши в отведенной для выбранного регистра области открывается диалог, запрашивающий подтверждение на добавление этого регистра на Form_mistakes (рисунок 2.16).

Если подтверждение получено, то данный регистр добавляется на форму Form_mistakes, иначе диалог просто закрывается.

2) Пользователем производится формирование и внесение ошибок (принцип пояснен выше).

3) Для удаления регистра с формы требуется кликнуть левой клавишей мыши на область, отведенную под данный регистр в блоке «View Mistakes». Появится диалог, запрашивающий подтверждение на удаление этого регистра из Form_mistakes (рисунок 2.17).

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

2.8 Форма «Об авторе» – Form_author

Внешний вид формы представлен на рисунке 2.18.

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

3 ТЕСТИРОВАНИЕ МОДЕЛИ PIC16

В данном разделе курсового проекта представлены разработанные тестовые программы для проверки правильности реализации системы команд и периферийных устройств микроконтроллера PIC16 и результаты их работы.

3.1 Тестирование системы команд

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

Для удобства и упрощения реализации тест системы команд разделили на следующие части:

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

Рассмотрим методику выполнения процесса тестирования на примере теста на правильное функционирование команд микроконтроллера.

Все тесты были разработаны в среде моделирования MPLab IDE, которая является специализированным эмулятором работы микроконтроллеров.

Код разработанного теста на ассемблере представлен ниже.

LIST P=16F877A

 #include <P16F877A.INC>

 

 ORG 0x00

nach BCF STATUS,RP0 ;выбор нулевого банка регистров

 BCF STATUS,RP1

 ;Команда ADDWF

 MOVLW 0x05

 MOVWF 0x20

 MOVLW 0xAA

 ADDWF 0x20,0

 MOVWF 0x21

 MOVLW 0xAA

 ADDWF 0x20,1

 ;Команда ADDLW

 MOVLW 0xAA

 ADDLW 0x01

 MOVWF 0x22

 ;Команда SUBWF

 MOVLW 0xFB

 MOVWF 0x23

 MOVLW 0xAA

 SUBWF 0x23,0

 MOVWF 0x24

 MOVLW 0xAA

 SUBWF 0x23,1

 ;Команда SUBLW

 MOVLW 0xAA

 SUBLW 0x97

 MOVWF 0x25

 ;Команда DECF

 MOVLW 0xAA

 MOVWF 0x26

 DECF 0x26,0

 MOVWF 0x27

 DECF 0x26,1

 ;Команда DECFSZ+MOVF

 MOVLW 0x02

 MOVWF 0x28

 MOVWF 0x29

 MOVF 0x28,0

 MOVWF 0x30

 DECFSZ 0x28,1

 DECFSZ 0x28,0

 MOVLW 0xEE

 MOVWF 0x29

 ;Команда INCF

 MOVLW 0xCD

 MOVWF 0x31

 INCF 0x31,0

 MOVWF 0x32

 INCF 0x31,1

 ;Команда INCFSZ

 MOVLW 0xFE

 MOVWF 0x33

 MOVWF 0x34

 INCFSZ 0x33,1

 INCFSZ 0x33,0

 MOVLW 0xEE

 MOVWF 0x34

 ;Команда ANDWF

 MOVLW 0xC4

 MOVWF 0x35

 MOVLW 0xAA

 ANDWF 0x35,0

 MOVWF 0x36

 MOVLW 0xAA

 ANDWF 0x35,1

 ;Команда ANDLW

 MOVLW 0xAA

 ANDLW 0xD7

 MOVWF 0x37

 ;Команда IORWF

 MOVLW 0xC5

 MOVWF 0x38

 MOVLW 0xAA

 IORWF 0x38,0

 MOVWF 0x39

 MOVLW 0xAA

 IORWF 0x38,1

 ;Команда IORLW

 MOVLW 0xAA

 IORLW 0xD8

 MOVWF 0x40

 ;Команда XORWF

 MOVLW 0x63

 MOVWF 0x41

 MOVLW 0xAA

 XORWF 0x41,0

 MOVWF 0x42

 MOVLW 0xAA

 XORWF 0x41,1

 ;Команда XORLW

 MOVLW 0xAA

 XORLW 0xF1

 MOVWF 0x43

 ;Команда CLRF

 MOVLW 0xA7

 MOVWF 0x44

 CLRF 0x44

 ;Команда CLRW

 MOVLW 0xA7

 MOVWF 0x45

 CLRW

 MOVWF 0x45

 ;Команда COMF

 MOVLW 0xA7

 MOVWF 0x46

 COMF 0x46,0

 MOVWF 0x47

 COMF 0x46,1

 ;Команда RLF

 MOVLW 0xA7

 MOVWF 0x48

 RLF 0x48,0

 MOVWF 0x49

 RLF 0x48,1

 ;Команда RRF

 BCF STATUS,C

 RRF 0x48,0

 MOVWF 0x51

 MOVF 0x48,0

 MOVWF 0x50

 RRF 0x50,1

 ;Команда SWAPF

 MOVLW 0xA7

 MOVWF 0x52

 SWAPF 0x52,0

 MOVWF 0x53

 SWAPF 0x52,1

M1  NOP

 GOTO sled

 ;Команда GOTO

sled MOVLW 0xA7

 MOVWF 0x54

 GOTO M1

 GOTO nach

end

Пример выполнения этого теста в среде MPLab показан на рисунке 3.1.

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

Выполнение программы теста комплексом КИИБ представлено на рисунке 3.2.

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

3.2 Тестирование периферийных устройств

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

Тестирование проводилось для следующих периферийных устройств:

  •  таймер TMR0 (работа в режиме таймера и режиме асинхронного счетчика);
  •  таймер TMR1 (работа в режиме таймера, режимах асинхронного и синхронного счетчиков);
  •  таймер TMR2 (работа в режиме таймера).

Рассмотрим методику выполнения процесса тестирования на примере теста на правильное функционирование таймера TMR2.

Все тесты были разработаны в среде моделирования MPLab IDE, которая является специализированным эмулятором работы микроконтроллеров.

Код разработанного теста на ассемблере представлен ниже.

LIST P=16F877A

 #include <P16F877A.INC>

 ORG 0x00

 GOTO main

 ORG 0x04

 BTFSS PIR1,TMR2IF

 GOTO main

 MOVLW 0x33

 MOVWF 0x50

 BCF PIR1,TMR2IF

 GOTO m1

 ORG 0x100

main MOVLW 0xC0

 MOVWF INTCON

 BSF STATUS,RP0

 BSF PIE1,TMR2IE

 BCF STATUS,RP0

 MOVLW 0x04

 MOVWF T2CON

 

m1 MOVLW 0xF0

 MOVWF TMR2

 INCF 0x40,1

 GOTO $-1

 end

Пример выполнения этого теста в среде MPLab показан на рисунке 3.3.

Тест построен следующим образом: по адресу 0х04 (см. директиву ORG 0x04) размещена подпрограмма обработки прерывания от таймера TMR2. В главной программе, размещенной по адресу 0х100, TMR2 настраивается в режим таймера без предделителя, в его значащий регистр записывается константа. После осуществления данной настройки на каждом такте работы значащий регистр таймера инкрементируется, пока не возникнет его переполнение. После переполнения регистр TMR2 сбросится в 0, и выставится флаг прерывания от таймера. По реакции на этот флаг начнет выполняться программа обработки прерывания.

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

Производим выполнение данного теста в комплексе КИИБ с целью проверки аналогичности процесса работы периферийного устройства (рисунок 3.4).

После сравнительного анализа полученных результатов было принято решение о том, что разработанные в комплексе КИИБ периферийные устройства реализованы правильно в соответствие с документацией на семейство микроконтроллеров PIC.


ЗАКЛЮЧЕНИЕ

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

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

Было осуществлено тестирование системы команд и периферийных устройств моделей микроконтроллера PIC16. Программы для тестирования были разработаны в соответствии с документацией на данное семейство микроконтроллеров.


СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1) Сертификация и доказательство безопасности систем железнодорожной автоматики / Под редакцией Вл. В. Сапожникова. - М.: Транспорт, 1997. – 288 с.

2) Микропроцессоры в 3 кн. Кн.2: Средства сопряжения. Контролирующие и информационно-управляющие системы. Учебник для вузов. / – М.: Высшая школа, 1987.

3) РТМ 32 ЦШ 1115842.01-94. Безопасность железнодорожной автоматики и
телемеханики. Методы и принципы обеспечения безопасности микроэлектронных СЖАТ.

4) Архангельский А.Я. C++Builder 6. Справочное пособие. Книга 1. Язык C++. - М.: Бином-Пресс, 2002 г. - 544 с.

5) Справочник по среднему семейству микроконтроллеров PICmicro: Техническая документация DS33023A компании Microchip Techology Incorporated,USA: ООО «Микро-Чип» Москва -2002

6) Архангельский А.Я. C++Builder 6. Справочное пособие. Книга 2. Классы и компоненты. М.: Бином-Пресс, 2002 г. - 528 с.


ПРИЛОЖЕНИЕ А. ЛИСТИНГ ПРОГРАММЫ ДЛЯ ПРОСМОТРА ПАМЯТИ ПРОГРАММ МИКРОКОНТРОЛЛЕРА

Файл Prog_view.h

//---------------------------------------------------------------------------

//---------------------------------------------------------------------------

#ifndef Prog_viewH

#define Prog_viewH

//---------------------------------------------------------------------------

#include <Classes.hpp>

#include <Controls.hpp>

#include <StdCtrls.hpp>

#include <Forms.hpp>

#include <Grids.hpp>

#include <DB.hpp>

#include <DBGrids.hpp>

#include <DBTables.hpp>

#include "MC_View.h"

#include "ProgramCellMemory.h"

#include "MainView.h"

//---------------------------------------------------------------------------

class TForm_prog : public TForm

{

__published: // IDE-managed Components

TGroupBox *GroupBox1;

TStringGrid *StringGrid1;

void __fastcall FormClose(TObject *Sender, TCloseAction &Action);

private: // User declarations

public:  // User declarations

__fastcall TForm_prog(TComponent* Owner);

   //Функция отображения текста программы микроконтроллера

void __fastcall PaintProg(HINSTANCE DLL_Prog);

};

//---------------------------------------------------------------------------

extern PACKAGE TForm_prog *Form_prog;

//---------------------------------------------------------------------------

#endif

Файл Prog_view.cpp

//---------------------------------------------------------------------------

#include <vcl.h>

#pragma hdrstop

#include "Prog_view.h"

//---------------------------------------------------------------------------

#pragma package(smart_init)

#pragma resource "*.dfm"

TForm_prog *Form_prog;

//---------------------------------------------------------------------------

__fastcall TForm_prog::TForm_prog(TComponent* Owner)

: TForm(Owner)

{

StringGrid1->Cells[1][0] = " Address";

StringGrid1->Cells[2][0] = "         Instruction";

StringGrid1->Cells[3][0] = " HexValue";

StringGrid1->Cells[4][0] = "        BinValue";

}

//---------------------------------------------------------------------------

void __fastcall TForm_prog :: PaintProg(HINSTANCE DLL_Prog)

{

vector<ProgramCellMemory>  Program;

vector<ProgramCellMemory>(__stdcall *GetProgram)();

if (DLL_Prog) {

 /*Вызов функции хзагрузки программы микроконтроллера

 из DLL*/

 GetProgram = (vector<ProgramCellMemory>(__stdcall *) ())

 GetProcAddress(DLL_Prog, "_GetProgram");

 Program =  GetProgram();

}

//Очистка StringGrid1

StringGrid1->RowCount=2;

StringGrid1->Rows[1]->Clear();

for(unsigned int i = 0; i < Program.size(); i++)

{

 String Addr,Name,HexValue,BinValue,Operand;

 //Запись текста программы в ListBox1

 Addr = IntToHex(Program.at(i).GetAddr(),4);

 Name = Program.at(i).GetName();

 HexValue = IntToHex(Program.at(i).GetHexValue(),4);

 BinValue = Form_view->IntToBin(Program.at(i).GetHexValue(),14);

 Operand = Program.at(i).GetOperand();

 StringGrid1->Cells[1][i+1]= Addr;

 StringGrid1->Cells[2][i+1]= Name+" "+Operand;

 StringGrid1->Cells[3][i+1]= "0x"+HexValue;

 StringGrid1->Cells[4][i+1]= BinValue;

 StringGrid1->RowCount=i+2;

}

int PCounter;

StringGrid1->Cols[0]->Clear();

int (__stdcall *GetPCounter)();

if (DLL_Prog)

 {

 //Получение значения программного счетчика из DLL

 GetPCounter = (int(__stdcall  *) ())

 GetProcAddress(DLL_Prog, "_GetPCounter");

 //Проверка существования функции GetPCounter

 if (GetPCounter) {

  PCounter = GetPCounter();

 }

 else

  ShowMessage ("Функция GetPCounter не найдена");

}

StringGrid1->Row = PCounter+1;

StringGrid1->Cells[0][PCounter+1]="*";

}

void __fastcall TForm_prog::FormClose(TObject *Sender, TCloseAction &Action)

{

Form4->SpeedButton2->Down = false;

Form4->ProgramViewCtrlP1->Checked=false;

}

//---------------------------------------------------------------------------

Рисунок 1.1 – Структура комплекса имитационного моделирования КИИБ

Рисунок 2.1 – Внешний вид формы MainView

Рисунок 2.2 – Вкладка «File» главного меню проекта

Рисунок 2.3 – Вкладка «Tools» главного меню проекта

Рисунок 2.4 – Вкладка «AutoTest» главного меню проекта

Рисунок 2.5 – Вкладка «Option» главного меню проекта

Рисунок 2.6 – Вкладка «Help» главного меню проекта

Рисунок 2.7 – Диалог загрузки файла модели

Рисунок 2.8 – Форма Form_view

Рисунок 2.9 – Форма Form_eeprom

Рисунок 2.10 – Форма Form_prog

Рисунок 2.11 – Диалог о подтверждении добавления регистра на форму Form_watch

Рисунок 2.12 – Внешний вид формы Form_watch

Рисунок 2.13 – Диалог о подтверждении удаления регистра с формы Form_watch

Рисунок 2.14 – Форма Form_pins

Рисунок 2.15 – Форма Form_mistakes

Рисунок 2.16 – Диалог о подтверждении добавления регистра на форму Form_mistakes

Рисунок 2.17 – Диалог о подтверждении удаления регистра с формы Form_mistakes

Рисунок 2.18 – Форма Form_author

Рисунок 3.1 – Выполнение теста команд в среде MPLab

Рисунок 3.2 – Выполнение теста команд в комплексе КИИБ

Рисунок 3.3 – Выполнение теста функционирования TMR2 в среде MPLab

Рисунок 3.4 – Выполнение теста функционирования TMR2 в комплексе КИИБ


 

А также другие работы, которые могут Вас заинтересовать

19275. История UML Описание UML. Сущности UML. Отношения UML. Диаграммы UML. Расширения языка UML. Диаграммы классов 290.15 KB
  Лекция 7. История UML Описание UML. Сущности UML. Отношения UML. Диаграммы UML. Расширения языка UML. Диаграммы классов. Диаграммы использования usecase диаграммы прецедентов. Диаграмма последовательности. Диаграмма кооперации. Диаграмма состояний. Диаграмма деятельности. ...
19276. Назначение CASE-средств. Архитектура CASE-средств. Классификация CASE-средств. Обзор CASE-средств. Системы автоматизированного проектирования 378.84 KB
  Лекция 8. Назначение CASEсредств. Архитектура CASEсредств. Классификация CASEсредств. Обзор CASEсредств. Системы автоматизированного проектирования. Обзор САПР. Компанииразработчики САПР. 8.1. Назначение CASEсредств Термин CASE расшифровывается как ComputerAssisted Software Engineerin...
19277. Проектирование фактографических ИС и хранилищ данных. Подходы к проектированию БД 298.35 KB
  Лекция 9. Проектирование фактографических ИС и хранилищ данных. Подходы к проектированию БД. Этапы нисходящего подхода к проектированию баз данных. Проектирование хранилищ данных. 9.1. Подходы к проектированию баз данных Можно выделить два основных подхода к про
19278. Назначение документальных ИС. Особенности представления и использо-вания документальной информации 244.3 KB
  Лекция 10. Назначение документальных ИС. Особенности представления и использования документальной информации. Типология документальных БД. Типология поисковых задач и режимы обслуживания. Основные процессы обработки и хранения документальной информации. 10.1. Наз...
19279. Лингвистическое обеспечение ИС. Состав лингвистического обеспечения ИС. Знаковые системы. Частотные словари, словари предметной области 267.3 KB
  Лекция 11. Лингвистическое обеспечение ИС. Состав лингвистического обеспечения ИС. Знаковые системы. Частотные словари словари предметной области. Кодификаторы классификаторы тезаурусы онтологии. Информационнопоисковые языки. 11.1. Лингвистическое обеспечен
19280. Структура информации и структура данных. Организация данных в документальных АИПС STAIRS и IRBIS 350.33 KB
  Лекция 12. Структура информации и структура данных. Организация данных в документальных АИПС STAIRS и IRBIS. Документоориентированная база данных Domino/Notes. Технологии поиска и обработки документальной информации. Уровневая модель представления информации в полнотекстовы...
19281. Использование коммуникативных форматов и протоколов. Объектная модель до-кумента (DOM). XML, RDF, OWL 287.37 KB
  Лекция 13. Использование коммуникативных форматов и протоколов. Объектная модель документа DOM. XML RDF OWL. Многоуровневые и многокомпонентные информационные ресурсы. Типология и структура распределенных ИР. Проектирование распределенных документальных информационных...
19282. Проектирование пользовательского интерфейса. Основные принципы и этапы проектирования пользовательского интерфейса 329.19 KB
  Лекция 14. Проектирование пользовательского интерфейса. Основные принципы и этапы проектирования пользовательского интерфейса: выбор структуры диалога разработка сценария диалога определение и размещение визуальных компонентов. Гибкие интерфейсы. Средства поддержк...
19283. Реинжиниринг информационных систем 180.12 KB
  Лекция 15. Реинжиниринг информационных систем Основные определения. Причины реинжиниринга ИС. Основные пути реинжиниринга ИС. Методологии реинжиниринга ИС. Этапы реинжиниринга ИС. Перспективы реинжиниринга ИС. 15.1. Основные определения В настоящее время существу...