Распределенная информационно-управляющая система ПоТок-С

Обзор основных систем мониторинга и управления распределенными объектами. Обзор контроллеров и встраиваемых компьютеров. Особенности построения и концепция РИУС ПоТок-С. Требования к программному обеспечению системы. Выбор базовой операционной системы.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 27.11.2011
Размер файла 3,5 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Внешний вид логического модуля Siemens LOGO! представлен на рисунке 1.12.

Преимущества применения

высокая надёжность;

упрощение монтажа и ввода в эксплуатацию целевых систем;

увеличение количества обслуживаемых входов/выходов обеспечивается с помощью модулей расширения;

модули LOGO! имеют морские сертификаты (ABS, BV, DNV, GL, LRS), сертификаты UL, CSA и FM, маркировку СЕ, отвечают требованиям стандартов VDE 0631, IEC 1131, EN 55011 (класс В), ГОСТ Р 50377-92, ГОСТ 28244-89, ГОСТ 29216-91 (сертификат № РОСС DE.ME20.B00820).

Технические характеристики

Подключение устройств

- 8 каналов дискретного ввода (релейные или транзисторные);

- 4 канала дискретного вывода (релейные или транзисторные);

- Релейные выходы имеют нагрузочную способность до 10 А для активной и до 3 А для индуктивной нагрузки, а транзисторные выходы -до 0,3 А при 24В;

- разъём для подключения модуля памяти или компьютера.

Коммутационные модули (интерфейсы)

- Интерфейс для связи с ПК

Модули расширения

- Увеличение количества обслуживаемых входов/выходов (Максимальная конфигурация при этом: 24 дискретных и 8 аналоговых входов, 16 дискретных и 2 аналоговых выхода)

Системные устройства

- встроенные часы реального времени

Системный процессор

- Информация отсутствует

Память

- встроенное энергонезависимое запоминающее устройство (EEPROM);

- максимальный объём программы до 130 функциональных блоков.

Корпус

- 72 x 90 x 55 мм (ШхВхГ);

- крепёжный узел для монтажа на 35 мм профильную DIN-шину;

- степень защиты корпуса IP20.

Рабочий температурный диапазон

- 0...+55°C

Пользовательский интерфейс

- ЖК дисплей;

- клавиатура.

Операционная система

- нет

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

- 8 основных и 28 специальных функций;

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

- для разработки и отладки программ предназначен программный пакет LOGOISoft Comfort. Пакет позволяет осуществлять графический ввод и редактирование программы, а также отладку программы в режиме эмуляции логического модуля. Готовая программа может загружаться в память логического модуля через специальный кабель или записываться в модуль памяти через специальное устройство LOGOIProm.

Программируемый контроллер Siemens Simatic S7-200 CPU226

В источнике [22] рассмотрены логические контроллеры SIMATIC S7-200, которые предназначены для построения относительно простых систем автоматического управления, отличающихся минимальными затратами на приобретение аппаратуры и разработку системы. Контроллеры способны работать в реальном масштабе времени и могут быть использованы как для построения узлов локальной автоматики, так и узлов, поддерживающих интенсивный коммуникационный обмен данными через сети Industrial Ethernet, PROFIBUS-DP, МPI, AS-lnterface, PPI, а также через модемы.

Внешний вид контроллера Siemens Simatic S7-200 представлен на рисунке 1.13.

Технические характеристики

Подключение устройств

- 24 канала дискретного ввода;

- 16 каналов дискретного вывода;

- поддержка протоколов USS или ModBus.

Модули расширения

- увеличение количества входов/выходов (Максимальная конфигурация: 128 дискретных и 28 аналоговых входов, 112 дискретных и 7 аналоговых выхода)

Коммутационные модули (интерфейсы)

- 2x RS485

Системные устройства

- 6 счетчиков/таймеров (30 кГц);

- встроенные часы реального времени.

Системный процессор

- процессор, способный выполнять операции над числами с плавающей запятой и поддерживающие алгоритм ПИД-регулирования;

- время выполнения логической команды 0,22 мкс.

Память

- EEPROM: 24 КБайт;

- Память данных: 10 КБайт;

- Буферизация данных: 100 ч.

Корпус

- Размеры: 196мм x 80мм x 62мм;

- Монтаж на 35 мм DIN-шину или на плоскую поверхность;

- Степень защиты корпуса IP20.

Рабочий температурный диапазон

- 0...+55°C

Питание

- ~115/230B;

- 24В (постоянный ток).

Операционная система

- Информация отсутствует

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

- Для разработки и отладки программ предназначен программный пакет STEP 7 Micro/Win. Поддержка языков LAD (релейно-контактные схемы), STL (список инчтрукций), FBD (функциональных блоковых диаграмм)

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Выводы

В современных системах коммерческого учета контроллеры становятся одним из наиболее важных компонентов, промежуточным звеном в цепи обмена данными между полевым оборудованием (теплосчетчиками, электросчетчиками, датчиками и исполнительными механизмами) и средствами АСУ ТП верхнего уровня (рабочими станциями технологов, серверами, офисными компьютерами управленческих, коммерческих и технических отделов). В таблице 1.2 приведена сравнительная характеристика различных контроллеров и встраиваемых компьютеров.

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

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

Таблица 1.2 - Сравнение характеристик различных контроллеров и встраиваемых компьютеров

Название

Тип

Процессор

Память

Коммуникация

Вводы/ выводы

ОС/мОСРВ

Средства разработки ПО

Цена, $

ThinkIO

К

Geode 5C1200,

266 МГц

SDRAM: 128 Мб

RAM: 128 Кб

2xUSB1.1, RS232,

2xEthernet 10/100, PROFIBUS-DP, CANopen,

2xDI, 2xDO

Windows CE, Linux

CoDeSys, lSaGraf, ОРС Driver, SOPH.I.A., CFC 6

~1000

SCADAPack

К

32-разрядный,

120 МГц

RAM: 8 Мб,

Flash: 4 Мб

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

до 40 модулей

нет

язык релейной логики, C/C++, lSaGraf

~300

NetCore

ВК

300/500 МГц, MIPS32

RAM: до 64 Мб,

Flash: до 16 Мб

Ethernet 10/100, RS232, RS485,

USB 1.1, IDE

нет

Linux 2.4

C/C++, ПО совместимое с Linux

250 - 300

InorTek

К

Микро-контроллер i80C188

RAM: до 512 Кб,

EEPROM: до 64 Кб

MODBUS/RS, Ethernet 10/100

8xAI, 4xAO, 10xDI, 10xDO

нет

C/C++, встроенные библиотеки ПИ/ПИД-регулирования, ШИМ-управления

215 - 359

"Контар" МС8

К

неизвестно

Flash: 60 Кб,

RAM: 30Кб

RS232, RS485

Ethernet 10/100,

8xAI, 8xAO, 4xDI, 8xDO

Уникальная, записана производи-телем

КОНГРАФ, Алгоритмы для управления конкретными технологическими процессами

400 - 550

UN0-2052

ВК

GX1 300 МГц

RAM: 64/128 Мб

ModBus/ RTU, 2x CAN, Ethernet 10/100, RS232

2xAI,4xDI

4xDO

Windows CE .NET

ПО совместимое с Windows CE .NET

неизвестно

Siemens Simatic S7-200

К

20 МГц

EEPROM: 24 Кб,

SRAM: 10 Кб

2x RS485

24xDI,

16xDO

неизвестно

STEP 7 Micro/Win, LAD, STL (список инструкций), FBD

неизвестно

К - контроллер; ВК - встраиваемый компьютер.

2. ПОСТАНОВКА ЗАДАЧИ

Дипломная работа была выполнена в рамках проекта по модернизации существующей (и эксплуатирующейся) распределенной информационной системы ПТС-1 для филиала ПТС (Петербургские Телефонные Сети) ОАО “Северо-Западный Телеком”. Проект предусматривал:

обновление существующего ПО и СУБД;

перевод системы на качественно новый уровень, в разряд распределенных информационно-управляющих систем (новое название системы ПоТок-С);

обновление аппаратного обеспечения на всех уровнях системы;

проведение различных сопутствующих экспериментов;

монтажные и пуско-наладочные работы.

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

Задачи дипломной работы:

разработка специализированного низкоуровнего программного обеспечения контроллера ASK-Lab;

разработка высокоуровнего программного обеспечения системы видеоконтроля для визуального мониторинга состояния объектов управления;

проведение различных поддерживающих экспериментов на объектах системы.

Для большего понимания сути проекта и важности задач, решаемых в рамках дипломной работы, в следующих разделах приведено описание проблематики (система ПТС-1 и ее недостатки), общие требования к системам класса ИУС и концепция РИУС ПоТок-С.

2.1 Описание проблематики

В филиале ПТС ОАО “Северо-Западный Телеком” с 2000 г. запущена в эксплуатацию распределенная информационная система (РИС) ПТС-1. Система обеспечивает возможность мониторинга режима теплоснабжения зданий автоматических телефонных станций (АТС) путем получения данных с датчиков теплосчетчиков. Одной из ключевых задач системы является предупреждение выхода из строя телекоммуникационного оборудования.

Здания АТС расположены в разных районах города. Эти здания отапливаются с использованием городских ТЭЦ и оборудованы средствами учета и регулировки подачи горячей воды в отопительную систему АТС. В настоящее время количество объектов порядка 100.

К моменту начала работ по модернизации РИС ПТС-1, верхний уровень системы (диспетчерский пункт) был реализован на базе программных комплексов Кливер и АСТРУМ [7] с использованием СУБД ACCESS. Нижний уровень системы (оборудование на объектах АТС) реализован на теплосчетчиках отечественного производства (средства учета тепла), подключенных посредством модема в качестве узла РИС. Коммуникационная составляющая реализована на стандартных модемах с использованием телефонных линий общего пользования.

Контроль параметров теплоносителя на объектах осуществляется диспетчером цеха автоматизированного учета энергии (АУЭ) ПТС. Параметры, измеряемые и вычисляемые теплосчетчиками:

температура и давление воды;

объемный либо массовый расход воды;

перенесенная тепловая энергия в подающем и обратном трубопроводе (на входе и выходе системы отопления АТС).

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

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

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

2.2 Общие требования к системам класса ИУС (СДМУ)

Требования к системам дистанционного мониторинга и управления (СДМУ) [5] в зависимости от сферы их применения могут, естественно, отличаться. Типовая СДМУ должна обеспечивать:

немедленное получение в едином диспетчерском пункте системы (ДПС) сигналов тревоги при возникновении аварийных ситуаций на объекте,

получение на мнемосхеме пульта диспетчера (ПД) ДПС в режиме реального времени полной информации о технологическом процессе и состоянии оборудования объекта;

представление в графическом виде и отображение в удобной для восприятия форме состояния контролируемых объектов, а также принятой и сохраненной информации;

возможность оперативного вмешательства из ДПС в работу оборудования объекта при возникновении нештатных ситуаций;

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

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

возможность дистанционной настройки и диагностики технологических контроллеров (ТК) объектов;

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

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

Аппаратура СДМУ, устанавливаемая непосредственно на объектах, должна обладать возможностью гибкого конфигурировании в зависимости от технических особенностей объекта. Основой такой аппаратуры, как правило, являются технологические контроллеры (ТК). Каждый ТК должен иметь возможность подключения:

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

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

измерительных приборов, имеющих стандартный интерфейс и открытые протоколы связи;

контроллеров локальных систем автоматики, имеющих стандартный интерфейс и открытые протоколы связи;

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

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

2.3 Особенности построения и концепция РИУС ПоТок-С

При разработке архитектуры РИУС ПоТок-С, наряду с общими требованиями, изложенными ранее, были учтены дополнительные требования заказчика.

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

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

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

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

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

Структура системы представлена на рисунках 2.1-2.2. В системе имеется возможность использования четырех типов АРМов. В настоящее время объекты ПТС можно разделить на две группы по признаку наличия автономного контура регулирования. Автономное регулирование тепловым режимом ряда станций осуществляется контроллером ECL Comfort 300 (DANFOSS). Верхний уровень системы включает в себя две подсистемы: чисто информационную ПТС-1 и информационно-управляющую ПТС-2, обслуживающую станции с контуром автономного регулирования.

С учетом опыта эксплуатации предыдущей версии системы, использование которой становится проблематичным при числе узлов порядка 100, в концепцию проекта РИУС ПоТок-С заложено требование обеспечения возможности развития системы по числу контролируемых объектов. Для реализации этого требования в подсистеме ПТС-1 используется СУБД ORACLE и мультиплицированный модемный канал.

Одним из ограничивающих требований к этой подсистеме являлась необходимость сохранения структуры коммуникационной компоненты в смысле использования не более одной телефонной линии на один узел теплоснабжения и теплорегуляторов ECL COMFORT-300 (DANFOSS) в качестве контроллеров локальной системы автоматического регулирования тепловых режимов.

Эти требования предопределили необходимость использования на теплопунктах станций, входящих в подсистему ПТС-2, контроллеров ASK-Lab верхнего уровня. Этот контроллер был разработан в СКБ Государственного Университета Аэрокосмического Приборостроения

Узлы теплоснабжения, входящие в подсистему ПТС-2 снабжены автоматизированными задвижками (рисунок 2.2а), управление которыми может осуществляться как теплорегулятором ECL COMFORT-300 в автономном режиме, так и в режиме ручного управления с АРМ инженера. Контроллер ASK-Lab кроме обеспечения работы с теплорегулятором ECL COMFORT-300, обеспечивает работу с теплосчетчиком. Обмен с верхним уровнем системы осуществляется по унифицированному протоколу ASK bus 3.1.

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

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

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

2.4 Требования к программному обеспечению системы

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

специализированное низкоуровнеаое программное обеспечение для контроллера ASK-Lab;

высокоуровневое программное обеспечение для системы видеоконтроля;

Требования к низкоуровнему программному обеспечению

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

возможность обращения к 3-м устройствам по одной линии связи (контроллер ASK-Lab, теплосчетчик и теплорегулятор ECL Comfort 300);

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

энергонезависимое хранение параметров контроллера;

обмен данными с ПК по линии связи (телефонная линия или прямое соединение контроллера и ПК);

использование протокола ASK bus 3.1 в качестве протокола сетевого и транспортного уровня для обмена данными с ПК;

обеспечение режима “прозрачности” (поддержка работы программного обеспечения предыдущей версии системы (РИС ПТС-1) для обмена данными с теплосчетчиками)

защита данных (использование алгоритма ГОСТ 28147-89 для кодирования-декодирования команд управления и особо важных данных);

считывание данных (параметров) с теплосчетчиков и теплорегулятора ECL Comfort 300;

изменения параметров теплорегулятора ECL Comfort 300;

управление силовыми устройствами (до 8-и);

протоколирование событий;

контроль времени выполнения задач.

Требования к высокоуровнему программному обеспечению

Разрабатываемое высокоуровневое программное обеспечение для системы видеоконтроля за объектами управления предназначено для работы совместно с модулем IP-видеокамеры [11] и должно обеспечить выполнение следующих функций:

прием видео- и аудио- потоков с IP-видеокамеры на ПК, с воспроизведением изображения и звука;

управление параметрами изображения и звука;

возможность переключения между подключенными к IP-видеокамере источниками видеосигнала (до 4-х камер);

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

возможность записи аудио-видео потока на жесткий диск ПК;

возможность управления режимами работы программного обеспечения с помощью “горячих” клавиш.

3 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
3.1 Низкоуровневое ПО контроллера ASK-Lab
Обоснование выбора инструментальных средств для разработки ПО
Выбор необходимых аппаратных средств
Для разработки низкоуровнего ПО выбираются следующие аппаратные средства:
Контроллер;
Устройство программирования (далее программатор) для данного типа контроллера;
Аппаратной эмулятор для данного типа контроллера;
ПК для создания и отладки ПО;
Контроллер выбирается исходя из требований, предъявляемых к функциональности данного устройства. Требования к функциям контроллера были приведены в пункте 2.4.1. Для выбора контроллера возможно несколько вариантов.
Во-первых, использовать готовые решения на базе программируемых контроллеров или встраиваемых одноплатных компьютеров доступных на рынке. Подразумевается, что в этом случае будет использоваться одно универсальное устройство.
Во-вторых, использовать комбинацию из нескольких контроллеров или специализированных модулей расширения. Подразумевается, что будет использовано несколько простых устройств (выполняющих некоторые базовые функции).
В-третьих, разработать в рамках проекта собственный специализированный контроллер для решения необходимых задач.
Как показал обзор существующих решений по контроллерам и встраиваемым компьютерам (смотри подраздел 1.2), среди всего многообразия предлагаемых и доступных устройств нет готовых решений на базе одного устройства. Как правило, основным ограничивающим фактором является требование на наличие 3-х интерфейсов RS-232 и до 8-и каналов дискретного вывода в выбираемом контроллере.
Возможен второй вариант, когда берется существующий контроллер или встраиваемый компьютер и дополняется различными модулями расширения. В общем случае получается комплекс устройств, обладающий достаточно большой избыточностью дополнительных функциональных возможностей, и как следствие, большой стоимостью. Цена таких решений зависит от производителя компонентов и разнообразия предлагаемых функций, и, как правило, начинается от 1000 $.В рамках проекта требуется постепенное введение в эксплуатацию до 100 контроллеров, поэтому данный вариант не подходит с точки зрения большой стоимости аппаратной части.
Для реализации требуемых функций был выбран третий вариант - разработка собственного специализированного контроллера ASK-Lab (с перспективой дальнейшего коммерческого использования). Нельзя сказать, что данный контроллер предназначен только для работы в составе РИУС ПоТок-С. Контроллер ASK-Lab сочетает в себе универсальность и большую функциональность для целого ряда различных применений, а также невысокую стоимость. Технические характеристики контроллера ASK-Lab приведены в Приложении А.
Контроллер ASK-Lab построен на базе 4-х микропроцессоров PIC18F458, поэтому программатор следует выбирать из устройств, способных программировать микропроцессоры семейства PIC18XXX. В настоящее время доступны следующие программаторы: PICSTART Plus, MPLAB ICD 2, PRO MATE II. Программатор PRO MATE II сочетает в себе невысокую стоимость и возможность программировать различные типы и корпуса микропроцессоров семейства PIC16XXX и PIC18XXX. Поэтому PRO MATE II был выбран в качестве программатора.
Аппаратный эмулятор для контроллера - очень важный инструмент при разработке и отладке ПО. Эмулятор, подключенный к ПК, позволяет при помощи специализированного ПО (установленного на ПК) эмулировать работу реального контроллера. Программисту может быть предоставлена информация о текущем состоянии портов ввода-вывода, регистрах, переменных, памяти и т.д.
В данном случае требуется выбрать аппаратный эмулятор для микропроцессоров PIC18F458, так как логика работы контроллера ASK-Lab обеспечивается работой микропроцессоров PIC18F458. В настоящее время доступны следующие аппаратные эмуляторы: MPLAB ICD 2, MPLAB ICE 2000, MPLAB ICE 4000. Эмуляторы MPLAB ICE отличаются стабильностью работы и большой функциональностью. Эмулятор MPLAB ICE 4000 стоит дороже и имеет некоторые функции, которых нет у MPLAB ICE 2000, и которые не используются при разработкеПО в данном проекте. Поэтому MPLAB ICE 2000 был выбран в качестве аппаратного эмулятора.
В настоящее время в России подавляющее большинство рынка ПК представлено машинами на базе IBM PC совместимой архитектуры. Существует множество операционных сред, программных комплексов и технических средств, нацеленных именно на работу в составе ПК этого класса.
Разработка потребует меньше ресурсов и времени, если она будет вестись на IBM PC, вследствие наличия значительного опыта разработки на ПК именно этой архитектуры, наличия достаточного количества программного инструментария разработчика, а также печатной и электронной литературы.
Разработка ПО для контроллера будет вестись при помощи различных программно-инструментальных средств, установленных на ПК. Следует отметить, что эффективность использования этих средств не сильно зависит от характеристик используемого ПК. Рациональным будет выбор ПК с аппаратной базой, удовлетворяющей требованиям используемой операционной системы и необходимых программно-инструментальных средств.
Для разработки низкоуровнего ПО контроллера был выбран ПК следующей конфигурации:
Процессор: Intel Pentium 3;
Тактовая частота: 600 МГц;
Объем оперативной памяти: 128 Мб;
Объем дискового пространства HDD: 10 Гб;
Видеокарта: встроенная;
Звуковая карта: нет;
Монитор: 15”.
Выбор метода разработки ПО и среды программирования
В работе [8] приведена классификация и сравнительный анализ методов разработки специализированного прикладного ПО.
Линейный подход подразумевает, что для реализации любого участка программы, даже если он многократно повторяется, используется конкретный код. Основной недостаток такого подхода - большой объем кода и плохая структурированность программы. Такой метод подходит лишь для разработки ПО для простейших устройств
Процедурный подход подразумевает использование задач и функций. В данном подходе возможно неоднократное использование вызовов функций, выполняющих определенный программный код. На основе функций могут формироваться библиотеки, для последующего использования данных функций в других программах. Объем кода существенно ниже, а структурированность программы выше, чем при линейном подходе. Этот метод может быть использован для разработки ПО для устройств и встраиваемых систем, обладающих небольшой функциональностью.
Наличие развитой среды разработки в сочетании с системой библиотек, наработанных в результате систематического применения процедурного подхода, обеспечивает возможность создания узкоспециализированных эффективных ОСРВ (мОСРВ). Использование технологии ОСРВ ускоряет процесс разработки, обеспечивает некую внутреннюю структуру и упрощает понимание принципов работы ПО. Технология ОСРВ позволяет в каждом новом проекте использовать одно и тоже ядро ОСРВ (написанное и отлаженное единожды), а также различные библиотеки и драйвера.
Из-за ограниченности ресурсов микропроцессора, как правило, для встраиваемых систем управления нецелесообразно использовать полномасштабную ОСРВ, так как сама ОСРВ требует ресурсов для реализации своих базовых функций. В силу этого приходится решать задачу многокритериальной оптимизации по разделению ресурсов между ОСРВ и прикладными задачами применительно к конкретной реализации. Бурное развитие встраиваемых систем управления позволяет выделить из ОСРВ общего назначения некое подмножество - мОСРВ, предназначенных для управления заранее определенным на этапе проектирования количеством задач. мОСРВ имеют жесткие ограничения по ресурсам микропроцессора на реализацию базовых функций.
Линейный и процедурный подходы к разработке ПО являются традиционными. Скорость разработки специализированного ПО для микропроцессорных систем управления при использовании традиционных методов не может быть существенно увеличена из-за естественных ограничений на способность человека контролировать многосвязные проблемы.
Таким образом, можно констатировать тот факт, что в настоящее время широко начинают применяться платформенно-ориентированные мОСРВ, являющиеся неотъемлемой частью современных сред разработки прикладного ПО. Следовательно, для разработки ПО контроллера был выбран метод использования мОСРВ.
мОСРВ имеют жесткие ограничения по ресурсам микропроцессора. Так, например, считается, что эффективным будет использование той мОСРВ, которая отнимает не более 30% объема памяти программ и не более 10% процессорного времени при выполнении. В нашем случае выбран микропроцессор PIC18F458 (краткие технические характеристики приведены в Приложении Б). Для данного микропроцессора объем памяти программ составляет 32 Кбайта, объем памяти данных 1 Кбайт, тактовая частота до 40 МГц.
Помимо аппаратных ограничений при выборе конкретной мОСРВ, следует обратить внимание на доступность мОСРВ, практики ее использования и удобства написания ПО под нее. В СКБ ГУАП разработана мОСРВ А3 для микропроцессоров семейства PIC18XXX. мОСРВ А3 сочетает в себе малую требовательность к аппаратным ресурсам микропроцессора, широкие возможности по диспетчеризации задач и простоту использования. Имеется специализированный инструментарий Конструктор А3 для описания ПО под данную мОСРВ. Состав библиотек и драйверов постоянно обновляется. Конструктор А3 позволяет описать структуру взаимосвязей модулей системы, определить временные интервалы и условия запуска задач, а также описание межзадачного обмена. Код ядра мОСРВ A3 генерируется Конструктором А3 при трансляции проекта. Проект транслируется в проект для среды программирования Microchip MPLab IDE v6.xx. В Приложениях В, Г приведено краткое описание мОСРВ А3 и Конструктора А3.
В настоящее время накапливается опыт использования мОСРВ А3 для встраиваемых систем управления. А3 была успешно применена в качестве мОСРВ для многотарифного счетчика электроэнергии ЦЭ27XX. Учитывая простоту использования А3, эффективность ее работы и доступность инструментария, в качестве базовой мОСРВ была выбрана А3.
В качестве среды программирования была выбрана Microchip MPLab IDE v6xx (далее MPLab), т.к. именно в данную среду может быть транслирован проект из Конструктора А3. Данная среда программирования поддерживает все микропроцессоры семейства PICXXX, а также все типы программаторов и аппаратных эмуляторов, перечисленных выше. MPLab имеет удобный интерфейс, качественные средства отладки и мониторинга памяти и других ресурсов.
Разработка структуры ПО
Выше упоминалось, что контроллер ASK-Lab построен на базе 4-х микропроцессоров PIC18F458. На этих микропроцессорах построена внутриплатная одномастерная сеть на базе интерфейса I2С. Мастером сети является один из микропроцессоров, все остальные работают по отношению к мастеру одинаково как периферия. Каждый микропроцессор имеет набор стандартных аппаратно реализованных коммуникационных интерфейсов с оптической развязкой. Кроме стандартных коммуникационных интерфейсов, контроллер имеет внешний разъем, на который выведены порты с периферийных микропроцессоров. Эти особенности аппаратной составляющей контроллера необходимо учитывать при разработке ПО. Структурная схема контроллера ASK-Lab приведена на рисунке 3.1.
Программное обеспечение контроллера ASK-Lab было разработано на основе мОСРВ A3. Ядро мОСРВ, драйвера и библиотеки являются неизменной частью каждой системы. Для удобства проектирования систем под мОСРВ A3 используется специальное инструментальное программное обеспечение Конструктор А3.
Структура ПО контроллера ASK-Lab представлена на рисунке 3.2.

Системное ПО

Ядро мОСРВ

Ядро мОСРВ A3

Драйвера устройств

I2C

LCD

USART (RS 232)

Прикладное ПО

Высокий приоритет прерываний

Прерывание 1

Прерывание K

Фоновые задачи

Задача 1

Задача N

Рисунок 3.2 - Структура ПО контроллера ASK-Lab
Код ядра мОСРВ A3 генерируется программным обеспечением Конструктор А3 при трансляции проекта.
Модули с кодами драйверов устройств собраны в универсальную библиотеку драйверов. Библиотека предназначена для использования в составе мОСРВ A3. Основной функцией библиотеки является программная поддержка аппаратных модулей микропроцессора PIC18 и поддержка аппаратно-программных интерфейсов между микропроцессором и другими устройствами. Описание библиотеки драйверов приведено в Приложении Д.
Изменяемой частью ПО контроллера является прикладное ПО - это программные модули, реализующие функции, специфичные для конкретного приложения контроллера. Прикладное ПО от версии к версии может изменяться, и дополняться новыми программными модулями. Системное ПО, как правило, остается неизменным (состав драйверов может меняться).
Функции, предъявляемые к ПО контроллера были описаны выше. Учитывая специфику аппаратной части контроллера ASK-Lab, функции разделяются между микропроцессорами, входящими в его состав (условные обозначения микропроцессоров: PIC_Master - мастер сети, PIC_SPT и PIC_Danf - переферийные микропроцессоры). При написании ПО всей системы в целом следует особое внимание уделить вопросу межпроцессорного взаимодействия.
Функции микропроцессора PIC_Master;
Обмен с ПК по интерфейсу RS-232 и протоколу Ask-Bus v 3.1 (выполнение команд, принятых с ПК, поддержка информационного обмена между ПК и процессорами PIC_SPT и PIC_Danf);
Обмен с микропроцессорами PIC_SPT и PIC_Danf по интерфейсу I2С (PIC_Master - мастер сети);
Реализация процедуры ввода пароля (используется клавиатура и ЖК-индикатор, хранение пароля в энергонезависимой памяти EEPROM);
Ведение журнала событий (хранение в памяти программ);
Преобразование данных согласно алгоритму ГОСТ 28147-89 при выполнении команд, требующих разграничения доступа.
В ПО микропроцессора PIC_Master (и всех остальных) были использованы существующие модули и библиотеки (системное ПО) и разработаны новые (прикладное ПО). Список всех модулей, входящих в состав ПО микропроцессора PIC_Master представлен в таблице 3.1.
Таблица 3.1 - Список модулей, входящих в состав ПО микропроцессора PIC_Master

Модуль

Тип ПО

Описание

Main.asm

СА

Главный модуль проекта.

AskBus31.inc

С*

Формирование/разбор пакетов протокола ASK-Bus v.3.1

AskTrans.inc

С*

Формирование контрольной информации сетевого пакета на уровне ASK-Bus, являющегося ответным на запросный пакет с ПК

Crypt.inc

С

Прямое и обратное преобразование данных по алгоритму Гост 28147-89 в режиме простой замены

Define.inc

СА

Модуль констант и объявлений.

Enter_Pswd.inc

П+

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

Ex_Flash.inc

С+

Работа с памятью программ микропроцессора

Init.inc

СА

Процедуры начальной инициализации микропроцессора

Kernvar.inc

СА

Модуль объявления переменных ядра.

Keyboard.inc

С

Опрос по требованию матричной клавиатуры с возвратом кода последней нажатой и отжатой клавиши

LCD.inc

С*

Настройка и вывод на ЖКД текстовой информации

Macros.inc

С*

Набор макросов, используемых ядром мОСРВ и библиотечными модулями.

MasterCMD.inc

П+

Выполнение команд (пришедших с ПК), предназначенных для выполнения микропроцессором PIC_Master

MI2C.inc

С

Обмен данными по интерфейсу I2С в режиме мастер с PIC18, работающими в режиме слэйв, либо другими внешними I2С слэйв-устройствами

Procs.inc

С*

Набор стандартных процедур, используемых ядром мОСРВ и библиотечными модулями.

Resetbufsbyto.inc

П+

Сброс буферов межзадачного обмена по условию

Setaskdevaddr.inc

П*

Установка адреса устройства для протокола ASK-Bus v3.1

Spt_strt.inc

П+

Формирование/разбор сетевых пакетов для обмена с СПТ 942 (посредством PIC_SPT) в режиме прозрачности

TaskCond.inc

СА

Условия запуска задач в мОСРВ.

UsartD.inc

С*

Обмен данными по интерфейсу RS-232 с внешним устройством с формированием пакета по символам границ пакета и по таймауту

Userdef.inc

СА

Модуль констант и объявлений пользователя.

ViewLevel.inc

П+

Формирование/разбор сетевых пакетов на уровне представления данных

Примечания к таблице:
С - системное ПО;
П - прикладное ПО;
А - код модуля (возможно частично) генерируется автоматически Конструктором А3 на основе схемы межзадачного обмена или других настроек;
* - код модуля модифицирован для данного проекта;
+ - код модуля заново разработан.
Описание структуры межзадачного обмена всех микропроцессоров для Конструктора А3 приведено в Приложении Е.
Функции микропроцессора PIC_SPT:
Обмен с теплосчетчиком по интерфейсу RS-232;
Обмен с микропроцессором PIC_Master по интерфейсу I2С (выполнение команд, принятых микропроцессором PIC_Master с ПК, поддержка информационного обмена между ПК и теплосчетчиком);
Управление силовыми устройствами (по командам с PIC_Master).
Список всех модулей, входящих в состав ПО микропроцессора PIC_SPT представлен в таблице 3.2.
Таблица 3.2 - Список модулей, входящих в состав ПО микропроцессора PIC_SPT

Модуль

Тип ПО

Описание

Main.asm

СА

Главный модуль проекта.

CmdDisp.inc

П+

Диспетчер команд, пришедших от PIC_Master

Define.inc

СА

Модуль констант и объявлений.

Init.inc

СА

Процедуры начальной инициализации микропроцессора

Kernvar.inc

СА

Модуль объявления переменных ядра.

Macros.inc

С*

Набор макросов, используемых ядром мОСРВ и библиотечными модулями.

Procs.inc

С*

Набор стандартных процедур, используемых ядром мОСРВ и библиотечными модулями.

Resetbufsbytos.inc

П+

Сброс буферов межзадачного обмена по условию

SI2C.inc

С

Обмен данными по интерфейсу I2С в режиме слейв с PIC18, работающим в режиме мастер

SlaveCMD.inc

П+

Выполнение команд пользователя (пришедших с ПК), предназначенных для выполнения микропроцессором PIC_SPT

TaskCond.inc

СА

Условия запуска задач в мОСРВ.

Usart.inc

С*

Обмен данными по интерфейсу RS-232 с внешним устройством с формированием пакета по таймауту

Userdef.inc

СА

Модуль констант и объявлений пользователя.

Функции микропроцессора PIC_Danf:
Обмен с терморегулятором ECL Comfort 300 по интерфейсу RS-232;
Обмен с процессором PIC_Master по интерфейсу I2С (выполнение команд, принятых процессором PIC_Master с ПК, поддержка информационного обмена между ПК и терморегулятором).
Состав модулей ПО микропроцессора PIC_Danf аналогичен составу модулей PIC_SPT. Отличие модулей в различных константах и определениях.
Обмен данными
Обмен данными между контроллером и ПК
операционный система компьютер управление
Структурная схема обмена данными между контроллером ASK-Lab и ПК приведена на рисунке 3.3.
Контроллер ASK-Lab поддерживает необходимые уровни протокола обмена до сетевого уровня. Остальные уровни поддерживаются внешним модемом. Как видно из рисунка 3.3, независимо от режима работы контроллера, данные, всегда проходят через транспортный уровень, который обеспечивает доставку сообщений. Режим простой трансляции данных (от ПК к периферии контроллера и обратно) реализован таким же способом. За основу транспортного уровня протокола взят протокол ASK-Bus v3.1. Описание протокола ASK-Bus v3.1 приведено в Приложении Ж.
Параметры обмена:
скорость передачи данных 2400 бит/сек (до 115200 бит/сек);
Биты данных 8;
Четность нет;
Стоповые биты 1;
Управление потоком нет.
Обмен данными между контроллером и периферийными устройствами
Связь ПК с теплосчетчиком и теплорегулятором обеспечивается в режиме трансляции данных. Формирование/разбор пакетов при обмене данными с теплосчетчиком и теплорегулятором в данном режиме производится непосредственно на ПК.
Сформированный пакет на ПК для теплосчетчика (либо теплорегулятора) вкладывается в поле данных пакета ASK-Bus. После разбора принятого контроллером ASK-Lab пакета поле данных передается на конечное устройство. Ответ от устройства принимается контроллером и без дополнительной обработки так же вкладывается в поле данных пакета ASK-Bus, и отправляется обратно на ПК, где и происходит разбор ответа устройства.
Примечание - данный режим работы контроллера ASK-Lab позволяет относительно быстро собрать систему на базе практически любых устройств с поддержкой последовательного интерфейса USART, т.к. весь протокол обмена с данным устройством будет реализован на ПК. Этот режим может быть так же использован как отладочный.
Работа контроллера ASK-Lab с теплосчетчиком СПТ942
Режимы обмена данных контроллера с теплосчетчиком:
Режим прозрачности - данные с ПК передаются на контроллер по интерфейсу RS-232 и протоколу обмена с теплосчетчиком. Контроллер, распознав начальный и конечный символы данного протокола, передает полученный пакет на теплосчетчик.
Режим команд - данные с ПК передаются на контроллер по интерфейсу RS-232 и протоколу ASK-Bus. Пакет данных для теплосчетчика вкладывается в поле данных пакета ASK-Bus. Команда 0x00 протокола ASK-Bus - передача данных на периферийное устройство. Контроллер, по этой команде извлекает поле данных из пакета и передает на периферийное устройство.
Параметры обмена:
скорость передачи данных 2400 бит/сек.;
Биты данных 8;
Четность нет;
Стоповые биты 1;
Управление потоком сигнал DTR (всегда активен).
Работа контроллера с ECL Comfort 300
Регулятор температуры ECL Comfort 300 Danfoss является полностью самостоятельным устройством, регулирующим температуру воды в контуре горячего водоснабжения и в контуре водяного отопления. Основными функциями контроллера при работе с ECL Comfort 300 являются функции удаленного мониторинга и изменения режимов работы регулятора. При наличии дополнительного коммуникационного модуля ECA87 для ECL Comfort 300 появляется возможность получать дополнительную информацию с ECL Comfort 300 и непосредственно управлять исполнительными устройствами данного регулятора.
Для обмена данными контроллера с регулятором температуры ECL Comfort 300 Danfoss используется режим команд (описан выше).
Параметры обмена:
скорость передачи данных 1200 бит/сек.;
Биты данных 8;
Четность да;
Стоповые биты 1;
Управление потоком нет.
Обеспечение робастности и защита информации
Важность аспекта защиты информации применительно к ИС обсуждалась в работах [1], [2]. Там же была предложена концепция использования многоуровневой системы защиты информации в распределенных системах коммерческого учета. Эта концепция с рядом модификаций была реализована в проекте.
При посылке команд записи (изменения) сетевые пакеты с командами и ответные пакеты должны быть преобразованы. Пакет, посылаемый с ПК, преобразуется с использованием ключа, производного от пароля, введенного инженером АРМ.
При получении пакета ПО контроллера делает обратное преобразование с использованием ключа, производного от пользовательского пароля (введенного на контроллере, аналогичному паролю ПО АРМ). Если контрольная сумма преобразованного блока корректна, производится проверка условия: принятое значение времени больше записанного в памяти контроллера. Если условие выполняется, контроллер выполняет команду. Ответный пакет преобразуется с использованием того же (пользовательского) ключа, содержит значение времени контроллера (значение системного таймера микропроцессора мастера сети).
Для преобразования данных используется алгоритм ГОСТ 28147-89 с постоянной таблицей замен. Контроллер ASK-Lab обеспечивает реализацию преобразования данных в режиме реального времени.
При передаче сообщений длина посылки искусственно увеличивается для обеспечения зашиты от сканирования. Для защиты от перехвата команд применен ряд дополнительных мер.
Ключи шифрации в контроллер ASK-Lab вводит администратор системы, и он же имеет возможность его изменения. Разработчики системы обеспечивают лишь первоначальный код доступа и лишены возможности считывания использованных кодов шифрации после введения ключей администратором системы.
Для защиты от атак при наличии сообщника в составе персонала, в контроллере ведется журнал, учета команд управления. Журнал доступен лишь для просмотра с АРМ инженера, но не может быть откорректирован. Эта информация позволяет фиксировать время и источник команд управления. Эта же информация обеспечивает возможность арбитража в случае незлонамеренных ошибок персонала.
Преобразование данных
Выше было сказано, что для передачи информации используется протокол ASK-Bus. Далее все упоминания полей касаются только протокола ASK-Bus.
Преобразованию подвергается поле STA (статус), CD (код команды) и поле DATA. Поле флагов протокола ASK-Bus должно содержать только признак необходимости преобразования, одинаковый для всех команд, требующих преобразования (старший бит = 1).
Состав преобразуемой информации приведен в таблице 3.3.
Таблица 3.3 - Состав преобразуемой информации

информация

поле ASK-Bus

длина

Поле статуса

STA

1

код команды

CD

1

параметры команды или пакет для внешнего устройства

DATA

N

системное время

DATA

4

дополнение до кратности 8 байт

DATA

L

Длина параметров команды N

DATA

1

контрольная сумма

DATA

2

Для длины преобразуемых данных Len должны выполняться условия: Len mod 8 = 0 и Len >= 16. Контрольная сумма - это сумма всех байтов данных, подвергаемых преобразованию, расположенных до нее (младшими вперед). Дополнение до кратности 8 байт производится заполнением пространства значением системного таймера.
Служебный и пользовательский пароль
Пароль, вводимый администратором в контроллер с помощью клавиатуры и дисплея, используется для получения ключа преобразования данных. Тот же пароль вводится при работе с инженерным ПО верхнего уровня.
Существует два типа пароля: служебный и пользовательский. Служебный пароль записывается при программировании контроллера и не подлежит изменению. Он используется при первоначальной настройке и техническом обслуживании системы, а также для смены пользовательского пароля. Пользовательский пароль задается с клавиатуры контроллера, и используется при формировании ключа для преобразования данных, передаваемых по сети при командах записи.
При изменении пароля сначала вводится старый пароль, при его правильности (т.е. при совпадении введенного значения с пользовательским паролем) предлагается ввести новый пользовательский пароль. Длина пароля - от 3 до 6 символов, пароль хранится в энергонезависимой памяти EEPROM контроллера. При успешном изменении пароля обнуляется счетчик времени, служащий для проверки корректности приходящих сетевых пакетов (при приеме каждой новой корректной команды, имеющей преобразованные данные, данный счетчик изменяется на значение поля «время сетевого пакета»).
Ключ преобразования данных
Для получения ключа преобразования данных должен использоваться пароль, вводимый пользователем в контроллер с помощью клавиатуры и дисплея.
На основе пароля формируется ключ, используемый для преобразования данных. Длина ключа - 256 бит. Расширение пароля до длины ключа осуществляется следующим образом:
преобразование пароля в BCD;
копирование получившейся строки на всю длину ключа;
выполнение операции XOR с неизменяемой константой, хранимой в энергонезависимой памяти контроллера, длина которой равна длине ключа.
Системное время
Текущее время вычисляет ПО на ПК, посылающее команду, это время должно возрастать для каждой следующей команды (например, число секунд с начала 2000 года). ПО контроллера проверяет порядок следования времени в командах и выполняет только команду со значением времени большим, чем предыдущая. Принятое значение времени хранится в энергонезависимой памяти контроллера. Механизм записи времени исключает порчу значения при пропадании питания. Значение времени записывается до начала реакции на команду.
Защита от сбоев и протоколирование событий
мОСРВ A3 обеспечивает некоторые функции по защите от сбоев и протоколированию событий, а именно:
контроль корректности функционирования программной системы;
контроль времени выполнения задач;
запись контекста ПО контроллера в случае исключительной ситуации для последующего анализа;
запись дампа памяти;
ведение журнала событий.
Методы отладки программного продукта
Очевидно, что написание работоспособного ПО - весьма трудоемкая задача. Написать сложное ПО без ошибок с первого раза практически невозможно. Поэтому очень важным является вопрос отладки ПО с целью быстрого, эффективного и надежного поиска и исправления ошибок. В следующих подразделах будут рассмотрены вопросы технических возможностей и особенностей отладки, используя среду программирования Microchip MPLab IDE v6.xx и специализированный инструментарий Конструктор А3.
Основные средства отладки среды программирования
Среда программирования Microchip MPLab IDE v6.xx предоставляет программисту довольно мощные средства отладки. В частности, MPLab содержит интегрированный отладчик и Object Browser для контроля за результатом процесса компиляции, а также ряд других сервисов нацеленных на поддержку процесса отладки. Использованные при разработке сервисы и методы отладки перечислены и описаны ниже.
Режимы запуска программы:
программная симуляция микропроцессора (MPLAB SIM)
использование аппаратного эмулятора (MPLAB ICE 2000)
Первый режим позволяет симулировать работу реального микропроцессора, но имеет ряд существенных ограничений. Так, например, отсутствует возможность работы с прерываниями, периферийными устройствами, встроенной энергонезависимой памятью (EEPROM) и памятью программ для операций чтения и записи. Этот режим можно использовать для запуска и отладки программ (фрагментов кода), не использующих вышеперечисленных ресурсов. Например, этот способ будет хорош при отладке различных математических функций, функций непосредственной обработки данных и д.р. При этом, процесс написания и отладки ПО может происходить с использованием одного ПК, без каких-либо других аппаратных средств.

Подобные документы

  • Описание и классификация современных информационно–поисковых систем. Гипертекстовые документы. Обзор и рейтинги основных мировых поисковых систем. Разработка информационно–поисковой системы, демонстрирующей механизм поиска информации в сети Интернет.

    дипломная работа [1,3 M], добавлен 16.06.2015

  • Автоматизация рабочих процессов управления и диагностики на транспортных средствах. Особенности типов архитектур бортовой информационно-управляющей системы. Электронные системы управления автомобилем. Антиблокировочная тормозная система транспорта.

    дипломная работа [2,8 M], добавлен 20.06.2017

  • Концепция операционных систем: главное назначение, основные функции и типы. Характеристика и оценка возможностей Microsoft Windows и Linux. Подбор операционной системы для рабочих персональных компьютеров и для сервера на предприятии ООО "Газ-сервес".

    дипломная работа [272,3 K], добавлен 16.06.2012

  • Анализ и способы построения online геоинформационных систем. Разработка набора инструментальных средств для создания информационно-справочной системы с географической привязкой в виде интернет-сервиса. Функциональное назначение программного продукта.

    дипломная работа [2,8 M], добавлен 11.04.2012

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

    курсовая работа [236,7 K], добавлен 09.03.2009

  • Программы системы "1С: Предприятие". Разработка, издание и поддержка компьютерных программ делового и домашнего назначения. Требования к техническому и программному обеспечению и к интерфейсам операционной системы. Средства разработки презентации.

    курсовая работа [2,6 M], добавлен 08.03.2015

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

    курсовая работа [1,9 M], добавлен 18.09.2013

  • Общая характеристика государственной системы научно-технической информации РФ: структура и виды информационных ресурсов, основной принцип функционирования. Задачи, цели и концепция создания распределенной информационно-аналитической системы (РИАС) ГСНТИ.

    презентация [554,3 K], добавлен 14.10.2013

  • Обзор и анализ предметной области. Актуальность проекта, сравнение аналогов, сферы применения. Виртуальная реальность: CAVE-системы, Leap Motion. Выбор методов построения системы. Обзор игровых движков. Использование баз данных. Разработка интерфейса.

    курсовая работа [4,6 M], добавлен 30.06.2017

  • Классификация информационных систем. Сортировка данных в MS Access. Фильтрация данных. Изменение структуры и вида таблицы. Базы данных в Internet. Требования к программному обеспечению. Запуск справочно-правовой системы "Гарант" и ее настройки.

    контрольная работа [1,5 M], добавлен 21.05.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.