Разработка драйвера протокола SPA-BUS, позволяющего собирать данные с микропроцессорных терминалов РЗА

АННОТАЦИЯ Данная дипломная работа посвящена разработке системы определения места повреждения (ОМП) в электроэнергетических системах, строящейся на базе микропроцессорных терминалов РЗА.

Цель данной работы — разработка драйвера протокола SPA-BUS, позволяющего вовремя и без потерь собирать данные с микропроцессорных терминалов РЗА (например, ТОР-100-ЛОК производства «ИЦ «БРЕСЛЕР») для передачи на сервер системы.

В процессе выполнения работы было дано описание процессов разработки и составлен бизнес-план по разработке данного программного продукта.

В данной работе представлены структуры данных и алгоритмы работы программы.

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

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

SUMMARY

This thesis is devoted to development of the system of determination of a place of damage to the electro-power systems, the relay protection which was built on the basis of microprocessor terminals and automatic equipment.

The purpose of this operation is development of the driver of the SPA-BUS protocol allowing in time and without loss to collect data from the microprocessor terminals of relay protection and automatic equipment (for example, TOR-100-LOK).

Working on the given paper we have described for the preparation and drafted a business plan for the development of this software module.

In this paper presents the data structures and algorithms of the program.

We give a user manual, which addresses the appearance of the module forms detailing their functionality. To be able to further support the program was written guide programmer.

Besides, the thesis includes chapters that made economic evaluation of the effectiveness of the system under development, as well as address issues of safety and environmental project.

ВВЕДЕНИЕ

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

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

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

Учитывая географические особенности России, задача определения мест повреждений ЛЭП остаётся крайне важной и актуальной. Точное определение и своевременное устранение аварии экономит финансовые ресурсы энергокомпании. Таким образом, ОМП востребовано на рынке.

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

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

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

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

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

1.2 Формулировка задачи Целью данной работы является разработки системы для определения места повреждения на ЛЭП, строящуюся на основе микропроцессорных терминалов РЗА. Разрабатываемый модуль предназначен для сбора данных ОМП ЛЭП с терминалов с последующей передачей данных на сервер.

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

Обеспечивать синхронизацию времени;

Выполнять чтение буфера событий и циклический опрос терминала;

Обеспечивать чтение заголовков и тел осциллограмм и связанных с ним событий ОМП в файлы;

Конвертация осциллограмм в формат COMTRADE.

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

Требования к функционированию системы:

Надежность работы (предназначена для постоянной работы 24/7);

Удобство и простота пользования, понимания;

Контроль входных данных, предотвращение возникновения ошибок;

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

Журналирование работы;

ПП должен быть реализован на языке программирования С/С++;

Обеспечение кроссплатформенности на уровне кода. Целевыми платформами являются: семейства ОС Windows, Linux. В частности требуется поддержка ОС Linux, устанавливаемых на встраиваемые компьютеры MOXA (компилятор GCC 3.3.2/3.4.3), в связи с чем накладываются следующие ограничения:

Ограничение размера — объем занимаемой памяти на диске и ОЗУ должен быть приемлемым;

Ограничение на новизну компилятора. В частности, не должны использоваться возможности, введенные в стандарте C++11.

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

ПК с процессором не хуже Intel XScale IXP425 — 266 МГц.

Объем оперативной памяти не менее 20 Мбайт (зависит от числа используемых терминалов);

Объем свободного дискового пространства на жестком диске не менее 20 Мбайт;

Наличие последовательных портов, поддерживающих стандарт интерфейсовRS-232/422/485

Наличие сетевой карты, поддерживающей стандарт интерфейса Ethernet.

Развитие и модернизации модуля:

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

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

2. СИСТЕМНЫЙ АНАЛИЗ ПРОЕКТА До того как приступить к формулированию алгоритмов решения поставленной задачи и представлению их в виде программы, необходимо проанализировать требования к функциональным и рабочим характеристикам разрабатываемого программного модуля, определить структуру входных и выходных данных, а так же первичные требования к пользовательскому интерфейсу.

2.1 Обзор существующих аналогов В настоящее время не существует аналогов данному программному продукту.

2.2 Требования к функциональным возможностям программного

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

Синхронизация даты и времени на терминалах ОМП;

Чтение буфера событий на терминалах;

Скачивание осциллограмм с терминалов;

Хранение полученных с терминалов осциллограмм в формате COMTRADE;

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

Журналирование работы ПП.

2.3 Пути решения поставленной задачи Для решения поставленной задачи необходимо решить несколько основных вопросов:

Обеспечение кроссплатформенности;

Ознакомление с протоколом SPA-BUS;

Продумать алгоритм синхронизации времени на терминалах ОМП;

Работа с буфером событий и циклический опрос терминала;

Ознакомление с форматом COMTRADE;

Работа с осциллограммами;

Обеспечение кроссплатформенности Для обеспечения кроссплатформенности существует несколько способов:

Использование нескольких исходных текстов под разные платформы;

Использование условной компиляции;

Использование кроссплатформенных библиотек.

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

Существует несколько кроссплатформенных библиотек/фреймворков, написанных на C++:

Boost;

Qt.

Boost — собрание библиотек, расширяющих функциональность C++. Свободно распространяются по лицензии Boost Software License вместе с исходным кодом. Boost имеет заметную направленность на исследования и расширяемость (метапрограммирование и обобщённое программирование с активным использованием шаблонов). Boost можно считать стандартом де-факто и необходимым дополнением к STL[23].

Библиотеки Boost охватывают следующее:

Многопоточное программирование;

Контейнеры;

Юнит-тестирование;

Функциональные объекты;

Графы;

Работа с геометрическими данными;

Итераторы;

Математические и числовые алгоритмы;

Синтаксический и лексический разбор;

Метапрограммирование на основе препроцессора и шаблонов;

«Умные указатели»;

Обработка строк и текста.

Qt — кросс-платформенный инструментарий разработки ПО на языке программирования C++.

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

Существуют версии библиотеки для Microsoft Windows, систем класса UNIX с графической подсистемой X11, iOS, Android, MacOSX, Microsoft Windows CE, QNX, встраиваемых Linux-систем и платформыS60.

По причине наличия проблем портирования Qt под встраиваемые компьютеры MOXA серии UC-74XX-LXс ARM-процессором с предустановленной ОС Embedded Linux была выбрана библиотека Boost.

Описание протокола SPA-BUS

SPA-BUS использует асинхронный протокол последовательной передачи данных (1 стартовый бит, 7 бит данных, бит четности и 1 стоповый бит) во скоростью передачи 9600 бит/сек (также могут использоваться скорости 300, 1200, 2400 или 4800 бит/сек). Сообщение состоит из ASCII-символов[6].

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

Формат сообщений Сообщения включают только печатаемые ASCII-символы (0AH, 0DH, 20H-7EH). Всего включено 98 символов, из которых 11 зарезервированы для использования в SPA-BUS. Зарезервированные символы используются для управления, разграничения сообщения и особого назначения, они перечислены в таблице 2−1.

Таблица 2−1. Зарезервированные символы в сообщениях SPA-BUS

Максимальная длина сообщения 255 символов.

Сообщения ведущего устройства имеют следующий формат:

>nTe/eXm/m:xxxx/xxxx/xxx/x:CCcr

где">"-стартовый символ;

«nTe/eXm/m" — заголовок;

«xxxx/xxxx/xxx/x" — данные;

«CC" — контрольная сумма;

«cr" — конечный символ.

Сообщения ведомых устройств имеют следующие форматы:

lf

lf

где"lf<�"-стартовые символы;

«nT" — заголовок;

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

«crlf» — конечные символы;

«n" — номер (адрес) ведомого устройства — целые числа в диапазоне 1…999. Номер 0 не определен, а 900 используется для широковещательных запросов;

«T" — типсообщения;

«e" — номер канала-целые числа в диапазоне 0…999. 0-й канал может быть опущен;

«e/e" — первый/последний канал (для групповых запросов);

«X" — тип данных;

«m" — номер данных — целые числа в диапазоне 1…999 999;

«m/m" — первый/последний номер данных (для групповых запросов).

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

Символ «:"разделяет различные части сообщений — заголовок от данных, данные от контрольной суммы.

Правильность сообщений проверяется включением в сообщение контрольной суммы и бита четности. Контрольная сумма включается в сообщение как 2 ASCII-символа, соответствующие числу в 16-й системе счисления, полученному сложением по модулю 2 (XOR) байтов сообщения.

Пример Ведущее устройство:>2R1S½:CCcr

Ведомое устройство: lf<2D:10.1/95:CCcrlf

Типы сообщений Сообщения ведущего устройства:

R (read) — чтение данных с ведомого устройства

W (write) -запись данных в ведомое устройство Сообщения ведомого устройства:

D (data) — сообщение с данными

A (acknowledge) -положительное подтверждение

N (nack) — отрицательное подтверждение Сообщение типа R (read) не имеет блока с данными и имеет следующий формат:

>nRe/eXm/m:CCcr

Сообщение типа W (write) имеет следующий формат:

>nWe/eXm/m:xxxx/xxxx/xx:CCcr

Заголовок сообщения типа D (data)включает только номер ведомого устройства и тип сообщения. Сообщениеимеет следующий формат:

lf

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

lf

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

Сообщения типа A (ack) не содержит блока с данными, а в заголовке только номер ведомого устройства и тип сообщения. Сообщение имеет следующий формат:

lf

Сообщение типа N (nack) имеет следующий формат:

lf

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

Коды ошибок:

0 — ошибка в контрольной сумме или четности;

1 — ведомое устройство занято;

2 — переполнение входного буфера ведомого устройства;

3 — сообщение сложное для ведомого устройства (ведомое устройство может ответить в случае, когда его программная часть преднамеренно упрощена);

4 — зарезервированный код ошибки;

5 — синтаксическая ошибка;

6 — ведомое устройство не содержит весь набор запрошенных данных;

7 — адресуемые данные невозможно считать или записать (из-за постоянной или временной блокировки). Сообщение типа Nс кодом ошибки 7 может быть отправлено как ответ на сообщение типа W, если адресуемая информация не существует или в нее не может быть записано новое значение. Сообщение типа Nс кодом ошибки 7 может быть отправлено как ответ на сообщение типа R, если адресуемые данные существуют и могут быть изменены, но не могут быть считаны;

8 — данные в сообщении типа Wнекорректны;

9 — неопределенное отрицательное подтверждение (например, внутренняя ошибка в программной части ведомого устройства).

Категории данных Данные, переданные каждым ведомым устройством, имеют одну из следующих логически категорий:

I — включает входные аналоговые и дискретные значения ведомого устройства;

O-включает выходные аналоговые и дискретные значения ведомого устройства;

S — обычно включает данные, устанавливающие параметры ведомого устройства;

V — внутренние переменные, включают следующие данные:

Дополнительные данные по контролируемому процессу или его событиям;

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

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

Некоторые общие функции программного обеспечения ведомого устройства;

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

С — состояние ведомого устройства представлено 2-мя битами. В сообщения состояние получает значения 0, 1, 2 или 3:

Бит состояния 0: сброс ведомого устройства или другая ситуация, которая, возможно, вызвала потерю данных о событии. Когда этот бит установлен (C=1 или C=3), ведомое устройство всегда отправляет в сочетании с событиями также событие xx. xxxE50до тех пор, пока бит не будет очищен;

Бит состояния 1: указывает о переполнении буфера событий ведомого устройства. Когда этот бит установлен (C=2или C=3), ведомое устройство всегда отправляет в сочетании с событиями также событие xx. xxxE51до тех пор, пока бит не будет очищен. Из-за переполнения ведомое устройство обычно прекращает добавлять новые события в буфер, и поэтому необходимо данный бит очистить;

F — идентификация ведомого устройства;

T — время;

D — дата и время;

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

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

A — допустимыеаварийные сигналы.

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

Ведомые устройства обеспечивают данные категорий C, F, T, D, L, Bи A только в канале 0. Данные категорий I, O, S, V и M доступны в 0 и других каналах.

Синхронизация времени на терминалах Для синхронизации времени на терминалах существует 2 команды:

Синхронизации полной даты и времени;

Синхронизация часов.

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

>900WD:yy-mo-ddhh.mm;ss.nnn:CCcr

где yyгод (последние 2 цифры)

mo — месяц

dd — день месяца

hhчасы

mmминуты

ss — секунды

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

>900WT: ss. nnn:CCcr

где ss — секунды

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

Работа с буфером событий и циклический опрос терминала События хранятся в циклическом буфере в энергонезависимой памяти. Буфер событий содержит до 250 событий. При появлении нового 251-го события самое старое событие безвозвратно теряется.

Существует возможность очистки буфера событий. Для этого используются SPA-команды:

Команда очистки буфера событий с полной меткой времени:

>1WV41:0:

<1A:76

Команда сброса регистраторов. При этом также сбрасываются аналоговые события и осциллограммы, а в буфере событий формируется событие сброса регистрации:

>1WV102:1:

<1A:76

Так же буфер событий очищается при форматировании.

Существует 2 способа чтения событий с терминалов:

Чтение очередного события осуществляется командой «RE». Формат сообщения с полной меткой времени:

yy-mo-ddhh.mm;ss.nnn[<�канал>]E<�код>

где yy — год (последние 2 цифры)

mo — месяц

dd — день месяца

hh — часы

mm-минуты

ssсекунды

nnn — миллисекунды

<�канал>-номер канала, ассоциированного с событием. Длина канала составляет 0.3 цифры. Если номер канала 0, то он может быть опущен.

<�код>-длина номера события 1 или 2 цифры. Значение может быть в пределах 0.63.

Пример посылки:

>1RE:CCcr

lf<1D:08−09−18 18.00;00.060 1E2:03crlf

При повторении команды «RE» события читаются одно за другим. Признаком окончания чтения событий является пустая строка в качестве ответа, например:

>1RE:CCcr

lf<1D:49crlf

Команда инициализации чтения событий «WV41:1» устанавливает указатель очередного события на начало буфера. Командой «RE» читаются только те события, которые были сформированы на момент поступления команды инициализации.

Пример посылки:

>1WV41:1:CCcr

lf<1A:76crlf

Процедура чтения событий всегда начинается с команды инициализации. Затем командой «RE» можно считать все сформированные события. При этом необходимо раз в 1 минуту циклически опрашивать терминал на предмет появления новых событий. Формат сообщения при этом:

ss.nnn[<�канал>]E<�код>

гдеss — секунды

nnn — миллисекунды

<�канал>-номер канала, ассоциированного с событием. Длина канала составляет 0.3 цифры. Если номер канала 0, то он может быть опущен.

<�код>-длина номера события 1 или 2 цифры. Значение может быть в пределах 0.63.

Пример посылки:

>1RL:CCcr

lf<1D:00.060 1E2:03crlf

При повторении команды «RL"последние события читаются одно за другим. Признаком окончания чтения последних событий является пустая строка в качестве ответа, например:

>1RL:CCcr

lf<1D:49crlf

Чтение событий по переднему и по заднему не переключаемому порту осуществляется независимо. Чтение очередного события осуществляется командой «RE1».

Пример посылки:

>1RE1:CCcr

lf<1D:08−09−18 18.00;00.060 1E2:03crlf

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

>1RE1:CCcr

lf<1D:49crlf

При появлении новых событий значимые ответы на команду «RE1» возобновляются.

Команда инициализации чтения событий «WV41:1» устанавливает указатель очередного события на начало буфера. Команда инициализации чтения новых событий «WV41:2» устанавливает указатель очередного события на конец буфера. Будут считаны только события, сформированные после этой команды:

>1WV41:2:CCcr

lf<1A:76crlf

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

Если с момента инициализации чтения событий буфер переполнился, и потерянные события не были считаны, очередным ответом на команду «RE1» будет событие переполнения буфера E51. Оно не сохраняется в буфере и формируется с нулевой меткой времени:

>1RE1:CCcr

lf<1D:00−00−00 00.00;00.000 E51:03crlf

Возможно повторное чтение события командой «RE2». Оно повторяет ответ на последнюю команду «RE1», в том числе событие переполнения буфера. Например:

>1RE1:CCcr

lf<1D:08−09−18 18.00;00.060 1E2:03crlf

>1RE2:CCcr

lf<1D:08−09−18 18.00;00.060 1E2:03crlf

Второй способ является более простым в реализации, но он поддерживается не всеми терминалами (например, терминалы серии ТОР-100 и ТОР-200, начиная с версии 02В). Поэтому выбран 1-й способ, поддерживаемый всеми терминалами.

Описание формата COMTRADE

Формат COMTRADE (Common Formatfor Transient Data Exchange for Power Systems) — это международный формат, предназначенный для хранения информации о значениях и параметрах электрических сигналов (например, ток, напряжение и дискретные (контактные) сигналы), считанных из промышленных электросетей. Он определяет общий формат для файлов данных и средств передачи, необходимых для обмена различными типами данных повреждения, тестов и моделирования.

Типы файлов осциллограмм:

Файл конфигурации

Файл данных Файл конфигурации Назначение файла конфигурации — обеспечивать информацию, необходимую для чтения и интерпретации значений данных в прилагаемых файлах данных. Имена файлов конфигурации имеют расширение"*.CFG".

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

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

название и идентификатор станции количество и тип каналов Формат строки:

CC, nnA, nnD

Где CC — общее количество каналов

nnколичество аналоговых (A) и дискретных (D) каналов информация о каналах:

аналоговые Формат строки:

nn, id, p, cccccc, uu, a, b, skew, min, max

где nnномер канала

idидентификатор канала

pидентификатор фазы канала

cccccc — цепь / компонент, который контролируется

uu — единица измерения в канале

a, b — коээфициент преобразования к ЛА

skew — сдвиг в канале с начала отсчета

min, max — нижняя и верхняя границы диапазона для выборок этого канала дискретные Формат строки:

nn, id, m

где nn — номер канала

idидентификатор канала

m-нормальное состояние канала (0 или 1)

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

Формат строки:

nrates

sssss1,endsampl1

…

sssssn, endsampln

где nrates — количество различных скоростей дискретизации

sssss1-sssssn — частота дискретизации (в Гц)

endsampl1 — endsamplnномер последней выборки для данной скорости.

отметки даты/времени-имеются 2 отметки: для значения в файле данных и для момента пуска.

Формат строки:

mm-dd-yy, hh: mm:ss.ssssss

где mm — месяц (01−12)

dd — день месяца (01−31)

уу — последние две цифры года

hhчасы (00−23)

mmминуты (00−59)

ss.ssssssсекунды (от 0 с до 59.999 999 с) тип файла (ASCII или BINARY)

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

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

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

Файлы данных должны быть разделены на строки. Каждая строка разделена на (n+2) колонок, где n — количество каналов в записи. Количество строк данных меняется в зависимости от длины записи и таким образом определяет размер файла. Количество колонок зависит от системы задач и также влияет на длину файла.

1-й столбец содержит номер выборки данных — целое число (например, 110), первое, из записанных в этой строке. Вторая колонка — время в миллисекундах, также целое число, второе от начала записи. Третья и остальные колонки содержат величины, которые представляют напряжения и дискретные сигналы (их значения в момент выборки). Единицы, в которых представлены значения аналоговых сигналов (токов и напряжений), записаны в файле конфигурации в строке, принадлежащей сигналу, номер которого в списке сигналов данного сеанса регистрации соответствует номеру его колонки в файле данных. Последующие выборки отделяются возвратом каретки и переводом строки.

Значения данных должны представляться в формате целого числа из шести цифр (I6), разделяемых запятыми. Отсутствующие значения представляются 999 999. Дискретные сигналы (I1) представляются единицами и нолями.

Метка конца ASCII файла (EOF) («1А» НЕХ) помещается сразу после скрытого символа «возврат каретки/перевод строки» () в конце записи файла.

Пример файлов конфигурации и данных приведен в приложении С.

Работа с осциллограммами Основной проблемой сбора данных с терминалов ОМП является возможная потеря осциллограммы при неселективном пуске и запаздывание результатов анализа осциллограмм после окончания пуска. Следует обратить внимание на прекращение передачи осциллограммы во время пуска терминала.

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

Каждый терминал имеет файл с последними заголовками осциллограмм. Максимальное количество сохраненных заголовков равно 250. Заголовок можно считать командой «RM18». При этом необходимо до этого установить режим считывания заголовков. Это можно сделать командой «VW69:2».

Формат заголовка осциллограммы:

где — критерий пуска

— количество блоков

— количество выборок в доаварийном блоке

— частота выборок

— маска аналоговых сигналов

— время

Количество осциллограмм можно считать командой «RM67». В случае наличия осциллограмм (количество > 0) необходимо установить номер осциллограммы для скачивания, делается это командой «WV68:<�номер>». После можно уже считывать саму осциллограмму командой «RM31». В случае прихода некорректной строки ее можно считать заново командой «RM32».

Пример посылки:

>1RV67:CCcr

lf< 1D:10:CCcrlf

>1VW69:2:CCcr

lf< 1A: CCcrlf

>1VW68:2:CCcr

lf< 1A: CCcrlf

>1RM18:CCcr

lf< 1D:0,0,0,0,0,0,0,0 3 80 1 255 12-05-15 16.41;42.385:CCcrlf

>1RM31:CCcr

lf< 1D:01FFFF000000010002:CCcrlf

…

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

После скачивания всех блоков осциллограммы;

После скачивания каждого блока.

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

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

3. АРХИТЕКТУРНОЕ И ДЕТАЛЬНОЕ ПРОЕКТИРОВАНИЕ

ПРОГРАММНОГО ПРОДУКТА Проектирование драйвера протокола SPA-BUS проводилась в несколько этапов, среди которых можно выделить следующие:

Разработка структуры программы Разработка структур данных Формулирование алгоритма решения задачи и представление его в виде программы Описание модулей и элементов программы, а также описание работы с программой приведены в главе «Тестирование и документирование программного продукта».

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

Для программного модуля «Документация» бизнес-процесс разработки был смоделирован с помощью AllFusionProcessModeler.

Участниками процесса разработки программного обеспечения являются заказчик, исполнитель и руководитель. Контекстная диаграмма представляет собой самое общее описание системы и ее взаимодействие с внешней средой (рис. 3.1). Из нее видно, что для успешного выполнения проекта требуется тесное взаимодействие всех участников процесса разработки программы. Стрелка «Техническое задание» является управлением для работы «Разработка программного продукта», а стрелки «Заказчик», «Руководитель», «Разработчик» и «Средства разработки» являются механизмами (ресурсами выполняющими работу).

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

Рисунок 3.2 — Диаграмма декомпозиции для работы «Разработка программного продукта»

Для более детального рассмотрения процессов, работы на диаграмме декомпозиции (рис 3.2) разбиваются на более мелкие фрагменты (табл. 3.1).

Таблица 3.1 — Составы работ

3.2 Выбор программных средств для решения задачи Выбор среды разработки программного обеспечения Прежде чем выбрать среду разработки приложения следует рассмотреть возможные варианты и после этого выбрать наиболее подходящий. В число современных сред разработки программного обеспечения, подходящих для решения поставленной задачи можно отнести MicrosoftVisualStudio 2010 и EclipseIDE.

MicrosoftVisualStudio 2010 — интегрированная среда разработки, включающая инструментальные средства для проектирования, кодирования, транслирования, отладки и выполнения программ. VisualStudio 2010 позволяет быстро создавать и внедрять разнообразные приложения на базе ОС Windows, веб-приложения и приложения для мобильных устройств.

В VisualStudio предлагается целый ряд шаблонов приложений, полезных при создании программ, и несколько языков программирования, на которых можно написать эти программы: VisualBasic, Visual C#, Visual C++, F# и т. д.

В приложениях, создаваемые с помощью VisualStudio, можно внедрять самые разные технологии. Ниже приведено описание некоторых из них [15]:

.NET Framework, .NET Framework 3.5, .NET Framework 3.0, .NET CompactFramework — это интегрированный компонент Windows, который поддерживает создание и выполнение нового поколения приложений и веб-служб XML.

Windows PresentationFoundation (WPF) — WPF представляет собой набор типов .NET Framework, который можно использовать для создания внешнего вида клиентских приложений Windows. WPF состоит из таких компонентов, как расширяемый язык исправления для приложений XAML, элементы управления, привязка данных, двухмерная и трехмерная графика, анимация, стили, шаблоны, документы, мультимедийные данные, текст и типографические средства.

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

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

Язык XAML — это язык разметки для декларативной разработки приложений. Windows PresentationFoundation (WPF) реализует загрузчик XAML и обеспечивает поддержку языка XAML для типов WPF, поэтому большую часть пользовательского интерфейса приложения можно создавать с помощью разметки XAML.

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

EclipseIDE — свободная интегрированная среда разработки модульных кроссплатформенных приложений. Развивается и поддерживается EclipseFoundation.

EclipseIDE служит в первую очередь платформой для разработки расширений, чем он и завоевал популярность: любой разработчик может расширить Eclipse своими модулями. Уже существуют JavaDevelopmentTools (JDT), C/C++ DevelopmentTools (CDT), разрабатываемые инженерами QNX совместно с IBM, и средства для языков Ada (GNATbench, Hibachi), COBOL, FORTRAN, PHP и пр. от различных разработчиков. Множество расширений дополняет среду Eclipse менеджерами для работы с базами данных, серверами приложений и др.

Eclipse JDT (JavaDevelopmentTools) — наиболее известный модуль, нацеленный на групповую разработку: среда интегрирована с системами управления версиями — CVS, GIT в основной поставке, для других систем (например, Subversion, MS SourceSafe) существуют плагины. Также предлагает поддержку связи между IDE и системой управления задачами (ошибками). В основной поставке включена поддержка трекера ошибок Bugzilla, также имеется множество расширений для поддержки других трекеров (Trac, Jira и др.). В силу бесплатности и высокого качества, Eclipse во многих организациях является корпоративным стандартом для разработки приложений.

Eclipse написана на Java, потому является платформо-независимым продуктом, за исключением библиотеки SWT, которая разрабатывается для всех распространённых платформ (см. ниже). Библиотека SWT используется вместо стандартной для Java библиотеки Swing. Она полностью опирается на нижележащую платформу (операционную систему), что обеспечивает быстроту и натуральный внешний вид пользовательского интерфейса, но иногда вызывает на разных платформах проблемы совместимости и устойчивости приложений.

Гибкость Eclipse обеспечивается за счёт подключаемых модулей, благодаря чему возможна разработка не только на Java, но и на других языках, таких как C/C++, Perl, Groovy, Ruby, Python, PHP, Erlang, Компонентного Паскаля, Zonnon и прочих.

В требованиях к программному продукту указана кроссплатформенность на уровне кода для ОС WindowsиLinux (в частности требуется поддержка Linux, устанавливаемых на встраиваемых компьютерах MOXA). Поэтому для разработки драйвера протокола SPA-BUSболее подходит EclipseIDE.

Выбор языка программирования разработки программного обеспечения В требованиях к программному продукту указаны языки программирования С и C++. Рассмотрим их.

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

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

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

В целомC++ унаследовал много хорошего, что есть в C. Поэтому в рамках данной дипломной работы применение C++ предпочтительнее.

3.3 Проектирование структуры программы Драйвер должен иметь модульную структуру, позволяющую быстро перенести драйвер на другую платформу. Архитектура драйвера представлена на рисунке 3−3.

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

Рисунок 3−3. Архитектура драйвера

3.4 Программная реализация

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

Рисунок 3−4. Алгоритм синхронизации времени на терминалах

3.4.2 Работа с буфером событий и циклический опрос терминала Каждому терминалу отводится квота запросов. По истечению квоты управление передается следующему SPA-объекту. Каждый терминал необходимо опрашивать минимум раз в течение 60 секунд (запрос RL), в противном случае можно потерять событие, поскольку события хранятся в терминалах в циклическом перезаписываемом буфере. Также необходимо учитывать ситуацию переполнения буфера RL, поскольку терминал не будет отправлять новых событий до момента сброса бита переполнения. На рисунках 3−5 и 3−6 представлены алгоритмы формирования запроса и разбора ответного сообщения.

Рисунок 3−5. Алгоритм формирования запроса при работе с буфером событий Рисунок 3−6. Алгоритм разбора ответ на запрос при работе с буфером событий

3.4.3 Алгоритм работы с осциллограммами Каждому менеджеру осциллограмм отводится квота запросов. По истечению квоты управление передается следующему SPA-объекту. В менеджере осциллограмм имеется список терминалов, с которых необходимо скачивать осциллограммы. На рисунках 3−7 и 3−8 представлены алгоритмы формирования запроса и разбора ответного сообщения.

Рисунок 3−7. Алгоритм формирования запроса при работе с осциллограммами Рисунок 3−8. Алгоритм разбора ответ на запрос при работе с осциллограммами

3.4.4 Алгоритм работы линии Линия содержит список SPA-объектов (объект синхронизации, терминалы, менеджер осциллограмм). Все эти объекты опрашиваются поочередно по кругу. Алгоритм работы линии представлен на рисунке 3−9.

Рисунок 3−9. Алгоритм работы линии Выводы по главе В данной главе было проведено бизнес-проектирование процесса разработки драйвера протокола SPA-BUS. Каждый этап был детально рассмотрен и описан. В главе были описаны структура модуля и структура данных. Была подробно рассмотрена программная реализация и описаны основные алгоритмы, используемые в данном программном модуле.

4. ТЕСТИРОВАНИЕ И ДОКУМЕНТИРОВАНИЕ ПРОГРАММНОГО

ПРОДУКТА

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

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

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

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

4.2 Руководство оперативного пользователя Введение Настоящее руководство предназначено для оперативных пользователей драйвера протокола SPA-BUS. В данном документе описаны основные возможности, а также принципы работы с ним и требования к уровню подготовки пользователя.

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

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

Описание интерфейса программного продукта Драйвер протокола SPA-BUS представляет собой консольное приложение.

Способы запуска приложения:

Двойное нажатие на исполняемый файл «spa_driver.exe» для Windows и «spa_driver» для Linux;

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

На рисунке 4−1 показаны сообщения при успешном запуске программного продукта, на 4−2 — сообщения в случае отсутствия файла конфигурации или ошибки в нем.

Рисунок 4−1. Сообщение программы при успешном запуске Рисунок 4−2. Сообщение программы при неудачном запуске

Описание файла конфигурации Для работы программы необходим конфигурационный файл «spa_config.xml». Конфигурационныйфайл имеет следующую структуру:

…

Параметры узлов представлены в таблицах 4−1 — 4−5.

Таблица 4−1. Параметры узла «SPA»

Таблица 4−2. Параметры узла «Line»

Таблица 4−3. Параметры узла «Station»

Таблица 4−4. Параметры узла «OSC»

Таблица 4−5. Параметры узла «Station» в узле «OSC»