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

  • Вид работы:
    Дипломная (ВКР)
  • Предмет:
    Информационное обеспечение, программирование
  • Язык:
    Русский
    ,
    Формат файла:
    MS Word
    272,17 Кб
  • Опубликовано:
    2012-07-05
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!

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

АННОТАЦИЯ

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

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

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

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

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

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

SUMMARY

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.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).on the given paper we have described for the preparation and drafted a business plan for the development of this software module. this paper presents the data structures and algorithms of the program. 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. , 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.2 Формулировка задачи

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

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

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

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

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

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

.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. СИСТЕМНЫЙ АНАЛИЗ ПРОЕКТА

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

.1 Обзор существующих аналогов

В настоящее время не существует аналогов данному программному продукту.

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

продукта

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

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

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

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

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

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

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

2.3 Пути решения поставленной задачи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контейнеры;

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

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

Графы;

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

Итераторы;

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

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

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

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

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

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

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

Описание протокола SPA-BUSBUS использует асинхронный протокол последовательной передачи данных (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

Код символа (в 16 сс)

Зарезервированный символ

Примечание

0A

Перенос строки

Стартовый/конечный символ сообщения ведомого устройства

0D

Возврат каретки

Конечный символ сообщения ведущего/ведомого устройства

21

!

Для будущего использования

22

Для будущего использования

24

$

Код ASCII-символа сдвига

26

&

Символ продолжения

2F

/

Разделитель

3A

:

Разделитель блока данных

3C

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

3E

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

3F

?

Для будущего использования


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

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

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

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

“nTe/eXm/m”- заголовок;

“xxxx/xxxx/xxx/x”- данные;

“CC”- контрольная сумма;

“cr”- конечный символ.

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

<nT:xxxx/xxxx/xxx:CCcrlf

lf<nT:xxxx/xx&xx/xxx:CCcrlf

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

“nT”- заголовок;

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

“crlf” - конечные символы;

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

“T”- типсообщения;

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

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

“X”- тип данных;

“m”- номер данных - целые числа в диапазоне 1…999999;

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

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

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

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

Пример

Ведущее устройство:>2R1S1/2:CCcr

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

Типы сообщений

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

Сообщения ведомого устройства:(data) - сообщение с данными(acknowledge) -положительное подтверждение(nack) - отрицательное подтверждение

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

>nRe/eXm/m:CCcr

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

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

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

<nD:xxxx/xxxx/xxx:CCcrlf

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

<nD::CCcrlf

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

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

<nA::CCcrlf

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

<nN:A:CCcrlf

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

Коды ошибок:

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

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

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

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

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

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

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

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

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

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

Категории данных

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

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

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

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

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

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

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

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

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

Ведомые устройства обеспечивают данные категорий 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 цифры)- месяц- день месяцачасыминуты- секундымиллисекунды

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

>900WT: ss.nnn:CCcr

где ss - секунды- миллисекунды

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

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

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

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

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

>1WV41:0:

<1A:76

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

>1WV102:1:

<1A:76

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

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

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

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

где yy - год (последние 2 цифры)- месяц- день месяца- часыминутысекунды- миллисекунды

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

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

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

>1RE:CCcr<1D:08-09-18 18.00;00.060 1E2:03crlf

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

>1RE:CCcr<1D::49crlf

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

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

>1WV41:1:CCcr<1A:76crlf

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

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

гдеss - секунды- миллисекунды

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

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

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

>1RL:CCcr<1D:00.060 1E2:03crlf

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

>1RL:CCcr<1D::49crlf

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

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

>1RE1:CCcr<1D:08-09-18 18.00;00.060 1E2:03crlf

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

>1RE1:CCcr<1D::49crlf

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

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

>1WV41:2:CCcr<1A:76crlf

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

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

>1RE1:CCcr<1D:00-00-00 00.00;00.000 E51:03crlf

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

>1RE1:CCcr<1D:08-09-18 18.00;00.060 1E2:03crlf

>1RE2:CCcr<1D:08-09-18 18.00;00.060 1E2:03crlf

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

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

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

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

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

Файл данных

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

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

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

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

название и идентификатор станции

количество и тип каналов

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

CC,nnA,nnD<CR,LF>

Где CC - общее количество каналовколичество аналоговых (A) и дискретных (D) каналов

информация о каналах:

аналоговые

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

nn,id,p,cccccc,uu,a,b,skew,min,max<CR,LF>

где nn- номер каналаидентификатор канала-идентификатор фазы канала- цепь / компонент, который контролируется- единица измерения в канале,b - коээфициент преобразования к ЛА- сдвиг в канале с начала отсчета, max - нижняя и верхняя границы диапазона для выборок этого канала

дискретные

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

 nn,id,m<CR,LF>

где nn - номер каналаидентификатор каналанормальное состояние канала (0 или 1)

частота сети (в Гц)

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

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

<CR,LF>

sssss1,endsampl1<CR,LF>

…,endsampln<CR,LF>

где nrates - количество различных скоростей дискретизации-sssssn - частота дискретизации (в Гц)- endsampln- номер последней выборки для данной скорости.

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

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

mm-dd-yy,hh:mm:ss.ssssss<CR,LF>

где mm - месяц (01-12)- день месяца (01-31)

уу - последние две цифры годачасы (00-23)минуты (00-59).ssssss- секунды (от 0 с до 59.999999 с)

тип файла (ASCII или BINARY)

Файл данных

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

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

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

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

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

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

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

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

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

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

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

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

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

<CR><B><NV><FR><AC><time>

где<CR> - критерий пуска

<B> - количество блоков

<NV> - количество выборок в доаварийном блоке

<FR>- частота выборок

<AC> - маска аналоговых сигналов

<time>- время

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

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

>1RV67:CCcr< 1D:10:CCcrlf

>1VW69:2:CCcr< 1A:CCcrlf

>1VW68:2:CCcr< 1A:CCcrlf

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

>1RM31:CCcr< 1D:0000000000000001FFFF000000010002:CCcrlf


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

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

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

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

Выводы по главе

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

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

ПРОГРАММНОГО ПРОДУКТА

Проектирование драйвера протокола SPA-BUS проводилась в несколько этапов, среди которых можно выделить следующие:

Разработка структуры программы

Разработка структур данных

Формулирование алгоритма решения задачи и представление его в виде программы

Описание модулей и элементов программы, а также описание работы с программой приведены в главе «Тестирование и документирование программного продукта».

.1 Проектирование процесса разработки программы

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

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

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

 

Рисунок 3.1 - Контекстная диаграмма разработки программного модуля

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

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

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

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

Название работы

Перечень этапов

Разработка требований (приложение А, рис. А.1).

Анализ требований и проектирование (приложение А, рис. А.2)

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

Написание кода приложения (приложение А, рис. А.3)

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

Тестирование (приложение А, рис. А.4)

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

Развертывание

обучение пользователей; рабочая эксплуатация


.2 Выбор программных средств для решения задачи

Выбор среды разработки программного обеспечения

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

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

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

.NET Framework, .NET Framework 3.5, .NET Framework 3.0, .NET CompactFramework - это интегрированный компонент Windows, который поддерживает создание и выполнение нового поколения приложений и веб-служб XML.PresentationFoundation (WPF) - WPF представляет собой набор типов .NET Framework, который можно использовать для создания внешнего вида клиентских приложений Windows. WPF состоит из таких компонентов, как расширяемый язык исправления для приложений XAML, элементы управления, привязка данных, двухмерная и трехмерная графика, анимация, стили, шаблоны, документы, мультимедийные данные, текст и типографические средства.- это независимая от обозревателя и платформы технология, позволяющая проектировать, разрабатывать и поставлять интерфейсы с поддержкой мультимедиа и многофункциональные приложения в Интернете.Forms - позволяет разрабатывать простые в развертывании и обновлении приложения с широкими графическими возможностями. Помимо этого, при доступе приложений Windows Forms к ресурсам на локальном компьютере обеспечивается более высокий уровень безопасности, чем при работе традиционных приложений Windows.

Язык XAML - это язык разметки для декларативной разработки приложений. Windows PresentationFoundation (WPF) реализует загрузчик XAML и обеспечивает поддержку языка XAML для типов WPF, поэтому большую часть пользовательского интерфейса приложения можно создавать с помощью разметки XAML..NET предоставляет платформу, которую можно использовать для создания веб-приложений. В ее состав входят такие службы, как управление состоянием, обработчики HTTP, модули HTTP и маршрутизация ASP.NET.- свободная интегрированная среда разработки модульных кроссплатформенных приложений. Развивается и поддерживается EclipseFoundation [16].служит в первую очередь платформой для разработки расширений, чем он и завоевал популярность: любой разработчик может расширить Eclipse своими модулями. Уже существуют JavaDevelopmentTools (JDT), C/C++ DevelopmentTools (CDT), разрабатываемые инженерами QNX совместно с IBM, и средства для языков Ada (GNATbench, Hibachi), COBOL, FORTRAN, PHP и пр. от различных разработчиков. Множество расширений дополняет среду Eclipse менеджерами для работы с базами данных, серверами приложений и др.JDT (JavaDevelopmentTools) - наиболее известный модуль, нацеленный на групповую разработку: среда интегрирована с системами управления версиями - CVS, GIT в основной поставке, для других систем (например, Subversion, MS SourceSafe) существуют плагины. Также предлагает поддержку связи между IDE и системой управления задачами (ошибками). В основной поставке включена поддержка трекера ошибок Bugzilla, также имеется множество расширений для поддержки других трекеров (Trac, Jira и др.). В силу бесплатности и высокого качества, Eclipse во многих организациях является корпоративным стандартом для разработки приложений.написана на Java, потому является платформо-независимым продуктом, за исключением библиотеки SWT, которая разрабатывается для всех распространённых платформ (см. ниже). Библиотека SWT используется вместо стандартной для Java библиотеки Swing. Она полностью опирается на нижележащую платформу (операционную систему), что обеспечивает быстроту и натуральный внешний вид пользовательского интерфейса, но иногда вызывает на разных платформах проблемы совместимости и устойчивости приложений.

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

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

Выбор языка программирования разработки программного обеспечения

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

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

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

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

3.3 Проектирование структуры программы

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

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

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

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

.4.1 Синхронизация времени на терминалах

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

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

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

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

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

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

.4.3 Алгоритм работы с осциллограммами

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

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

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

.4.4 Алгоритм работы линии

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

Рисунок 3-9. Алгоритм работы линии

Выводы по главе

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

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

ПРОДУКТА

.1 Тестирование программного продукта

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

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

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

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

.2 Руководство оперативного пользователя

Введение

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

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

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

Описание интерфейса программного продукта

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

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

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

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

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

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

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

Описание файла конфигурации

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

<SPAversion=”1.0” DT=”120428143212”>

<LineType=”COM” ComNumber=”1” ComBaudRate=”19200”>

<Station Number=”1” />

<Station Number=”3” />

<OSC PrefixDir=”.\\”>

<Station Number=”1” TDFile=”tor100.td” OMPFile=”tor100.omp” />

</OSC>

</Line>

</SPA>

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

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

Атрибут

Описание

Свойство

version

Номер версии, состоит из 2-х частей - версии и релиза

Обязательный

DT

Дата и время создания. Формат: ГГММДДЧЧИИСС, где ГГгод (последние 2 цифры); ММмесяц; ДДдень; ЧЧчас (24 часовой формат); ИИминуты; ССсекунды.

Обязательный

Name

Наименование объекта

Необязательный


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

Атрибут

Описание

Свойство

Name

Наименование линии

Необязательный

Type

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

Обязательный

ComNumber

Номер последовательного порта. Считывается, если параметр Type=COM

Обязательный

ComBaudRate

Скорость последовательного порта. Считывается, если параметр Type=COM

Обязательный

ComCfg

Настройки COM-порта в формате: bps, где bколичество бит данных (5…8); pчетность (E-even, N-none, O-odd); sколичество стоповых бит (1..2).

Необязательный По умолчанию = «7E1»

RestoreWait

Параметр задает время, в мсек, ожидания между попытками инициализации линии. Диапазон от 100 до 60000 мсек.

Необязательный По умолчанию = 30000

ReplyTimeout

Параметр, задающий таймаут, в мсек, ответа оборудования. Диапазон от 10 до 60000 мсек.

Необязательный По умолчанию = 500

SyncTime

Параметр общей синхронизации времени. Может принимать значения: синхронизация включена 0синхронизация отключена

Необязательный По умолчанию = 0

SyncTimePeriod

Период синхронизации секунд и миллисекунд, в секундах. Учитывается только при SyncTime=1. Диапазон т 60 до 60000 сек.

Необязательный По умолчанию = 60

SyncDateTimePeriod

Период синхронизации с полной меткой времени, в минутах. Учитывается только при SyncTime=1. Диапазон т 60 до 60000 мин.

Необязательный По умолчанию = 60


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

Атрибут

Описание

Свойство

Name

Задает имя терминала, часть имени тега. По умолчанию «S<Adr>», где <Adr> - адрес терминала

Необязательный По умолчанию = «SX»

Number

SPA-адрес терминала. Максимальное значение зависит от типа используемого оборудования.

Обязательный

UnUse

Параметр включения станции в опрос при первом запуске.  Возможные значения: станция опрашивается 0станция не опрашивается

Необязательный По умолчанию = 1

Pass

SPA-пароль терминала

Необязательный По умолчанию = «001»

SessionQuota

Квота количества запросов к терминалу в течение одной сессии. Диапазон от 3 до 50.

Необязательный По умолчанию = 3

Type

Тип запрашиваемого устройства. При указании неверного типа устройства корректная работа не гарантируется. Возможные варианты: TORLOKвсе устройства серии ТОР LOK TORвсе устройства серии ТОР

Необязательный По умолчанию = «TOR»


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

Атрибут

Описание

Свойство

PrefixDir

Параметр определяет начальный путь для хранения осциллограмм

Обязательный

NameTemplate

Параметр задает шаблон имени сохраняемой осциллограммы. По умолчанию = r[ADR]_[YYYY]_[MM]_[DD]_[HH]_[SS]_[NN]_[FFF]

Необязательный

SessionQuota

Квота количества запросов к терминалу в течение одной сессии. Диапазон от 3 до 50.

Необязательный По умолчанию = 3


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

Атрибут

Описание

Свойство

Number

SPA-адрес терминала. Максимальное значение зависит от типа используемого оборудования.

Обязательный

Type

Тип запрашиваемого устройства. При указании неверного типа устройства корректная работа не гарантируется. Возможные варианты: TORLOKвсе устройства серии ТОР LOK TORвсе устройства серии ТОР

Необязательный По умолчанию = «TOR»

Dir

Окончание пути для сохраняемой осциллограммы

Необязательный

TDFile

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

Обязательный

OMPFile

Имя файла в формате «*.omp», который используется для считывания параметров ОМП.

Обязательный

AutoDownload

Автоматическое скачивание осциллограммы. Значения: автоматическое скачивание включено 0автоматическое скачивание отключено

Необязательный По умолчанию = 0

4.3 Руководство программиста

Общие сведения

Программный продукт предназначен для определения мест повреждений на ЛЭП. Программа обеспечивает:

Синхронизацию времени

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

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

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

Туннель для дистанционного конфигурирования терминала в виде SM-тега.

Данная программа написана на языке программирования C++ в среде разработки EclipseIDE.

Структура программы

В состав драйвера протокола SPA-BUS входят модули, представленные в таблице 4-6.

Таблица 4-6. Описание модулей

Модуль

Назначение

xml.h pugixml.hpp pugiconfig.hpp pugixml.cpp

Модуль для работы с XML-документами (представляет собой обертку над выбранной библиотекой)

BrsLogging.h BrsLogging.cpp SpecificLogLibrary.h

Модуль логирования (представляет собой обертку над выбранной библиотекой)

base_port.h base_port.cpp serial_port.h serial_port.cpp

Модуль для работы с портами ввода-вывода (пока поддерживается только последовательный порт)

packet.h packet.cpp

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

spa_manager.h spa_manager.cpp

Модуль чтения конфигурации и создания проекта

line.h line.cpp

Модуль линии

сircular_list.hpp

Вспомогательный класс, реализующий циклический список

dist_manager.h dist_manager.cpp dist_terminal.h dist_terminal.cpp dist_header.h dist_header.cpp

Модуль для работы с осциллограммами (чтение заголовков и тел осциллограмм, событий ОМП и конвертация осциллограммы в формат COMTRADE)

terminal.h terminal.cpp

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

sync_object.h sync_object.cpp

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

aux_funcs.h aux_funcs.cpp

Дополнительные функции

main.cpp

Главный модуль программы


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

Разработанные классы для описания SPA- объектов перечислены в таблице 4-7.

Таблица 4-7. Классы, описывающие SPA-объекты

Класс

Назначение

spa_object

Базовый класс для всех SPA-объектов

sync_object

Объект синхронизации

terminal

Объект терминала

dist_manager

Менеджер осциллограмм


В таблице 4-8 приведен перечень всех функций программы с описанием:

Таблица 4-8. Описание функций программы

Название функции и входные параметры

Описание функции

Классыbase_port, serial_port

virtual bool open()

Виртуальная функция открывает и инициализирует порт для принятия и отправки данных

virtual bool close()

Функция закрытия порта

virtual boolis_open() const

Функция проверяет, открыт ли порт

virtual size_tread_data(char * buf, size_tbuf_size)

Асинхронное чтение данных из порта в буфер размером buf_size.

virtual size_tread_data_until(char * buf, char * delim)

Асинхронное чтение данных из порта в буфер до разделителя

virtual size_twrite_data(const char * buf, size_tbuf_size)

Асинхронная запись данных в порт

void set_timeout(unsigned int timeout)

Установка периода ожидания данных из порта

virtualboolinit()

Инициализация порта

void timeout_expired(constbs::error_code&)

Функция вызывается по истечению периода ожидания данных при асинхронном чтении

void operation_completed(constbs::error_code&, size_t)

Функция вызывается по истечению асинхронных операций чтения и записи

voidwait()

Функция ожидает окончание асинхронных операций чтения и записи

virtualvoidcancel()

Функция принудительно завершает асинхронные операции чтения и записи

virtual port_typeget_type()

Функция возвращает тип порта

Классcircular_list<T>

size_t size() const

Возвращает количество элементов в циклическом списке

voidclear()

Очистка циклического списка

void push_front(_data_type _data)

Добавление элемента в начало циклического списка

void push_back(_data_type _data)

Добавление элемента в конец циклического списка

voidpop_front()

Удаление первого элемента циклического списка

voidpop_back()

Удаление последнего элемента циклического списка

circular_iteratorbegin_circular() const

Возвращает циклический итератор, установленный на начало списка

iteratorbegin() const

Возвращает итератор, установленный на начало списка

iteratorend() const

Возвращает итератор, установленный на конец списка

_data_type at(unsigned int index) _data_type operator[](unsigned int)

Возвращает элемент списка по его позиции

Класс packet

char * str() const

Метод возвращает указатель на строку SPA-сообщения

boolsend(base_port *)

Отправка SPA-запроса

slave_message_type read(base_port *, unsigned char address)

Чтение ответа на SPA-запрос с последующей проверкой пакета на корректность

size_tget_body(char *)

Метод возвращает блок данных сообщения SPA

slave_message_typecheck_slave_packet(unsigned char address) const

Проверка принятогоSPA-сообщения на корректность (проверка контрольной суммы и т.д.)

Класс spa_manager

boolparse_from_xml(const char *config_name)

Чтение файла конфигурации формата XML

voidrun()

Запуск драйвера на выполнение

static boolis_spa_node(xml_node)

Статическая функция проверяет имя узла XML-документа на название «SPA»

Класс line

static line* parse_from_xml_node(xml_node *)

Статический метод для создания объекта линии и чтения параметров этого объекта из узла XML-файла

staticvoidrun(line *)

Запуск линии

unsigned intget_counter() const

Получениезначениясчетчикаработоспособности линии.

const char * get_name() const

Метод возвращает название линии.

void add_spa_object(spa_object *)

Добавление SPA-объекта (объекта синхронизации, терминала или менеджера осциллограмм) в циклический список

terminal * find_terminal(unsigned char)

Поиск терминала в списке поегоSPA-адресу

Классspa_object,sync_object

static spa_object* create_spa_object(xml_node *)

Статическая функция для создания SPA-объекта и чтение его параметров из узла XML-документа

virtual request_resultnext_request(base_port *)

Метод выполняет первый из очереди запрос к терминалу

virtual boolget_answer(base_port *)

Метод ожидания результата на запрос

virtual spa_object_typeget_type() const

Метод возвращает тип SPA-объекта

static std::string get_string_nack(unsigned char)

Статический метод возвращает описание ошибки NACK-сообщения по его коду

Классterminal

static terminal* parse_from_xml(xml_node *)

Статическая функция для создания SPA-объекта терминала и чтение его параметров из узла XML-документа

booladd_event_RL(char *)

Метод разбирает событие из тела ответа на запрос RL и добавляет событие в буфер

booladd_event_RE(char *)

Метод разбирает событие из тела ответа на запрос RE и добавляет событие в буфер

Классdist_manager

static dist_manager * parse_from_xml(xml_node *)

Статическая функция для создания SPA-объекта менеджера осциллограмм и чтение его параметров из узла XML-документа

booladd_dist_header(const char *)

Метод разбираетзаголовок осциллограммы из строки и добавляет в буфер

boolwrite_dist()

Запись осциллограммы на диск в формате COMTRADE

Классdist_terminal

Статическая функция для создания объекта терминала и чтение его параметров из узла XML-документа

boolrenew_headers_file(const char *, dist_header *, size_t)

Методдляперезаписифайласзаголовкамиосциллограмм.

boolget_header_dist_from_file(const char *, unsigned char, dist_header *, unsigned char &)

Чтение заголовка осциллограммы с определенным номером из файла, также возвращает общее количество заголовков в файле

boolfind_not_download_dist(const char *, const char *)

Поиск еще не скачанной осциллограммы

void form_name_file_dist(const char *, unsigned char, char *) const

Метод формирует имя файла осциллограммы по шаблону

void read_dist_headers(const char *)

Чтение заголовков осциллограмм из файла. Данный метод вызывается один раз при старте программы

boolinit()

Инициализация объекта терминала - чтение ОМП-параметров и параметров трансформации.

boolread_transform_params()

Чтение параметровтрансформации из td-файла. Данные параметры необходимы для формирования файла осциллограммы в формате COMTRADE

boolread_omp_params()

Чтение OMP-параметров из файла. Данные параметры необходимы для формирования файла осциллограммы в формате COMTRADE

Классdist_header

static boolparse_from_string(const char *, dist_header *)

Статический метод для создания объекта заголовка осциллограммы из строки

size_tget_line_count() const

Метод возвращает количество строк осциллограммы

unsigned short get_FRG() const

Метод возвращает частоту в Гц

unsigned short get_NVR() const

Метод возвращает количество выборок в доаварийном режиме

unsigned short get_count_AC() const

Метод возвращает количество заданных аналоговых сигналов

unsigned short get_time_rec() const

Метод возвращает период выборки в мсек

Класс CBLog

int Initialize(char* fileName, TBLogLevel logLevel, long maxLogSizeInKB, size_t filesNum, bool bAutoFlush, TBLogVerboseLevel verboseLevel)

Инициализация логера

int UnInitialize()

Деинициализация логера

int Write(TBlogstring msg, TBLogLevel msglevel, TBLogVerboseLevel verboseLevel, TBlogstring module )

Метод для добавления сообщения в лог

int SetVerboseLevel(TBLogVerboseLevel vl, TBlogstring module)

Установка нового фильтра по уровню подробности сообщений

int SetLogLevel(TBLogLevel ll, TBlogstring module)

Установка нового фильтра по уровню критичности сообщений

int DisableLogging(TBlogstring module)

Выключение логирования

Модульaux_funcs

size_tsymbol_count(const char * _str, char _symbol)

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

boolparse_posix_time(const char *, bpt::ptime&)

Функция разбора времени в формате posix из строки

unsigned short check_bit(unsigned short pos, unsigned short symb)

Проверка бита в числе

char * add_to_path(char * _path, const char * _str)

Добавляет путь в конец пути

boolpath_is_exist(const char * _path)

Проверка директории или файла на существование

boolcreate_directory(const char * _path)

Создание директории

boolcreate_directories(const char *_path)

Рекурсивное создание директорий

Модуль main

BOOL ctrl_handler(DWORD sig_type)

Функция-обработчик событий консоли в ОС Windows

void ctrl_handler(intsig_type)

Функция-обработчик сигналов в ОС Linux


Обращение к программе

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

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

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

Входные и выходные данные

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

Выходными данными являются файлы осциллограмм в формате COMTRADE и события из буфера RE, а также лог-файл.

Сообщение программного средства

Сообщения системы можно разделить на следующие группы:

Сообщения об отсутствии конфигурационного файла или ошибках в его формате;

Сообщения о нехватке памяти на диске для сохранения осциллограммы;

Сообщения об ошибках приема и отправки пакетов

Выводы по главе

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

5. ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ

ДИПЛОМНОГО ПРОЕКТА

.1 Описание программы

Данный программный продукт предназначен для создания системы определения места повреждений в электроэнергетических системах. Система ОМП строится на базе микропроцессорных терминалов релейной защиты и автоматики (например, ТОР 100-ЛОК), которые в автоматическом режиме анализируют аварийный режим и рассчитывают расстояние до места аварии.

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

.2 Описание рынка сбыта

Наиболее разветвленные сети линий электропередач принадлежат сетевым компаниям (например, «ФСК»), городским сетям.

.3 Расчет себестоимости программного продукта

Исходные данные

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

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

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

Степень сложности алгоритма функционирования - 1 группа сложности - программная продукция, реализующая оптимизационные и моделирующие алгоритмы.

Используемая информация представлена в виде справочно-нормативной информации.

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

Определение трудоемкости разработки программной продукции

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

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

Для данного проекта имеем следующие величины [8]:

(табл. 2) - Диспетчеризация;

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

Для данного проекта имеем следующие величины [8]:

(табл. 3);

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

- коэффициент учета режима обработки информации;

 - коэффициент учета вида используемой информации.

, ,  - значения коэффициентов вида информации для переменной, нормативно-справочной информации и баз данных соответственно;

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

Для данного проекта имеем следующие величины[8]: (табл. 4);

(табл. 17);

;

(табл. 18);

;

.

Получаем

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

- коэффициент учета сложности контроля информации;

 - коэффициент учета уровня используемого алгоритмического языка программирования;

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

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

Для данного проекта имеем следующие величины[8]:

(табл. 19);

(табл. 20);

(табл. 21);

;

(табл. 22).

Получаем.

Трудоемкости отдельных этапов разработки программного продукта представлены в таблице 5-1.

Таблица 5-1.Трудоемкость разработки программного продукта

Этап разработки ПП

Трудоемкость, человеко-дней

Техническое задание

57

Эскизный проект

117

Технический проект

77.16

Рабочий проект

81.07

Внедрение

29.62


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


где - трудоемкость i-й работы, чел. дни;

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

 - количество исполнителей, выполняющих i-ю работу, чел.

Принимая  человек, получим:.

Определение цены программного продукта

Цена программного продукта определяется по формуле:

где С- затраты на разработку программной продукции (сметная себестоимость);

К - коэффициент учета затрат на изготовление опытного образца программного продукта, как продукции производственно-технического назначения (К = 1,1 .. 1,2);

П - нормативная прибыль,

Расчет сметной себестоимости программного продукта.

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

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

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

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

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

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


где - балансовая цена i-го вида оборудования;

 - норма годовых амортизационных отчислений для оборудования i-го вида;

 - действительный годовой фонд времени, ч.;

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

При разработке данного программного продукта использовались компактный встраиваемый компьютер MOXAUC 7420-LXPlusи терминал «ТОР 100-ЛОК».


Для данного проекта имеем следующие величины [8]:

(табл. 52);

(табл. 65);

(табл. 66);

;

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

Получаем

Дополнительная заработная плата. В статье учитываются все выплаты непосредственным исполнителям за время (установленное законодательством), не проработанное на производстве, в том числе: оплата очередных отпусков, компенсации за неиспользованный отдых, оплата льготных часов подросткам и др. Единый социальный налог. В статье учитываются отчисления в бюджет социального страхования по установленному законодательством тарифу от суммы основной и дополнительной заработной платы. В соответствии с Налоговым кодексом РФ, часть 2, введенным в действие федеральным законом №117-ФЗ от 5.08.2000 г., в сумму налога включены отчисления в государственные внебюджетные фонды: Пенсионный фонд РФ, Фонд социального страхования РФ и фонды обязательного медицинского страхования РФ.

Получаем

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

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

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

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

Эта статья тоже не учитывается.

Результаты расчета сметной стоимости программной продукции представлены в таблице 5-2.

Таблица 5-2. Результаты расчета сметной стоимости программной продукции

Наименование статьи

Сметная себестоимость

Удельный вес, %

Примечание

Материалы

0.00

0.00

не приобретались

Специальное оборудование

1821.81

0.28


Основная заработная плата

271384

42.25


Дополнительная заработная плата

54276.81

8.45


Единый социальный налог

97698.25

15.21


Накладные расходы

217107.2

33.80


Производственные командировки

0.00

0.00


Контрагентские расходы

0.00

0.00

сторонними организациями работ не выполнялось

ИТОГО:

642288.1

100.00



Цена продукта будет равна:


Расчет и сопоставление капитальных вложений по сравниваемым вариантам

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

;

Расчет и сопоставление эксплуатационных расходов по сравниваемым вариантам

Расходы, связанные с эксплуатацией программы  (р./год на потребителя программы), определяются как:


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

Расчет показателей эффективности и годового экономического эффекта от внедрения разработанной программы

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

Сводные экономические показатели по разработке программы приведены в таблице 5-3.

Таблица 5-3. Сводные экономические показатели по разработке программы

Показатель

Размерность

Программа

Затраты на разработку программы

руб./программу

642288.1

Капитальные вложения

руб./программу

832915

Эксплуатационные расходы

руб./программу

291972

Годовой экономический эффект

руб./год/программу

257010.7

Срок окупаемости

Год

2.18


Выводы по главе

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

6. БЕЗОПАСНОСТЬ И ЭКОЛОГИЧНОСТЬ ПРОЕКТА

.1 Анализ и оценка вредных факторов при разработке драйвера

протокола

Микроклимат рабочей зоны программиста

Лаборатория является помещением І категории (выполняются легкие физические работы), поэтому должны соблюдаться следующие требования:

оптимальная температура воздуха- 22° С (допустимая - 20-24° С)

оптимальная относительная влажность - 40-60% (допустимая - не более 75%)

скорость движения воздуха не более 0.1 м/с.

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

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

Освещение рабочего места

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

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

Опасность повышенного уровня напряженности электромагнитного поля.

Электромагнитные поля, характеризующиеся напряженностями электрических и магнитных полей, наиболее вредны для организма человека. Основным источником этих проблем, являются дисплеи (мониторы). Они представляют собой источники наиболее вредных излучений, неблагоприятно влияющих на здоровье программиста. ПЭВМ являются источниками таких излучений как: мягкого рентгеновского, ультрафиолетового 200-400 нм, видимого 400-700 нм, ближнего инфракрасного 700-1050 нм, радиочастотного 3 кГц-30 МГц, электростатических полей.

Так как работа программиста по виду трудовой деятельности относится к группе В - творческая работа в режиме диалога с ЭВМ, а по напряженности работы ко II категории тяжести [12] предусмотрены 3 перерыва - 2 на чаепитие (10-20 минут каждая) и одно на обед (1 час). Для уменьшения электромагнитного поля на рабочем месте установлены жидкокристаллические мониторы.

Электробезопасность. Статическое электричество.

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

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

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

Для уменьшения напряжённости применяются увлажнители и нейтрализаторы, антистатическое покрытия пола. Кроме того, при неисправности каких-либо блоков компьютера корпус может оказаться под током, что может привести к электрическим травмам или электрическим ударам. Для устранения этого, в лаборатории металлические корпуса оборудования подсоединены к заземляющей жиле. Электробезопасность рабочего места обеспечивается в соответствии с [5].

.2 Измеритель напряженности электрического и магнитного поля

промышленной частоты ИП-50

Назначение.

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

Измеритель ИП-50 работает от источника постоянного напряжения 9 В, типа "КРОНА", АА, и др.

Рабочие условия эксплуатации измерителя ИП-50:

температура окружающего воздуха (293 ± 10)º К

относительная влажность воздуха (65 ± 15) %

атмосферное давление (100 ± 5) кПа

Технические данные.

Измеритель ИП-50 имеет следующие характеристики, представленные в таблице 6-1.

Таблица 6-1. Характеристики измерителя ИП - 50

Рабочая частота

50 ± 1 Гц.

Диапазон измерения среднеквадратического значения напряженности магнитного поля

0,01 - 100 А/м

Первый поддиапазон

0,01 -1 А/м

Второй поддиапазон

1 - 100 А/м

Диапазон измерения среднеквадратического значения напряженности электрического поля

1 В/м - 100 кВ/м

Первый поддиапазон с ПИП N1

0,01 - 1 кВ/м

Первый поддиапазон с ПИП N2

0,001 - 0,1 кВ/м

Второй поддиапазон с ПИП N1

1 - 100 кВ/м

Второй поддиапазон с ПИП N2

0,1-10 кВ/м

Погрешность измерения, не более

± 10%


Состав.

Измеритель ИП-50 состоит из следующих основных частей:

ПИП напряженности магнитного поля и электрического поля N1 и N2;

А1 - блок интеграторов;

А2 - входной делитель напряжения;- измерительный усилитель;- АЦП с жидкокристаллическим индикатором;

ПИП напряженности магнитного поля промышленной частоты (индукционного типа) расположен непосредственно в корпусе измерителя ИП-50 параллельно нижней части корпуса. Его выход, через входной разъем, подключен к входу усилителя.

ПИП напряженности электрического поля промышленной частоты N1 или N2 (емкостного типа) подключается к входному разъему, расположенному на верхней крышке ИП-50. При этом происходит автоматическое отключение ПИП напряженности магнитного поля от входа усилителя.

Блок интеграторов совместно с ПИП формирует амплитудно-частотную характеристику измерителя.

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

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

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

На задней панели корпуса измерителя, под крышкой, расположен батарейный отсек.

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

Устройство и работа.

ПИП напряжённости магнитного поля измерителя ИП-50 представляет собой пассивный индукционный преобразователь. ПИП выполнен в виде катушки, которая содержит 4000 витков провода ПЭВ-1-0,1 мм и имеет диаметр 60 мм. Катушка жёстко крепится к нижней крышке корпуса измерителя.

При измерении переменного магнитного поля величиной 1 А/м частотой 50 Гц наведенная ЭДС катушки составит 5 мВ. Корпус измерителя служит электростатическим экраном и устраняет влияние на катушку электрического поля.

ПИП напряжённости электрического поля измерителя ИП-50 представляет собой пассивный преобразователь емкостного типа. ПИП выполнен из двустороннего стеклотекстолита толщиной 3 мм. Диаметр ПИП N1 равен 25 мм, а диаметр ПИП N2 - 100 мм. При измерении временного электрического поля напряженностью 1 кВ/м (верхняя граница первого амплитудного поддиапазона) на электродах ПИП N1 наведется ЭДС порядка 5 мВ, а на электродах ПИП N2 50 мВ. Таким образом, использование ПИП N2 при измерении напряжённости электрического поля повышает чувствительность измерителя ИП-50 в десять раз по сравнению с ПИП N1.

.3 Проведение электромагнитного мониторинга на рабочем месте

пользователя ПК при разработке драйвера протокола

Инструментальный контроль электромагнитной обстановки на рабочих местах пользователей персонального компьютера (ПК) производится[9]:

при вводе ПК в эксплуатацию и организации новых и реорганизации рабочих мест;

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

по заявкам предприятий и организаций

Инструментальный контроль уровней ЭМП должен осуществляться приборами с допускаемой основной относительной погрешностью измерений ± 20%.

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

Проведение измерений.

Измерение уровней переменных электрических и магнитных полей, статических электрических полей на рабочем месте, оборудованном ПК, производится на расстоянии 50 см от экрана на трех уровнях на высоте 0,5 м, 1,0 м и 1,5 м. Результаты мониторинга приведены в таблице 6-2.

Таблица 6-2. Результаты электромагнитного мониторинга.

Высота

Напряженность магнитного поля, А/м

Напряженность электрического поля, В/м

0,5 м

0,42

0,07

1,0 м

0,59

0,09

1,5 м

0,50

0,08


Максимальное значение напряженности (0.59 А/м) магнитного поля превышает допустимый уровень (0.2 А/м) превышает в 2.95 раза.

.4 Аттестация рабочего места пользователя ПК по электромагнитной

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

Отнесение условий труда к тому или иному классу вредности и опасности [13] при воздействии ЭМП и излучений осуществляется в соответствии с таблицей 6-3.

Таблица 6-3. Классы условий труда при действии неионизирующих ЭМП и излучений

Показатель

Класс условий труда


оптимальный

допустимый

опасный


1

2

3.1

3.2

3.3

3.4

4

Электромагнитные поля на рабочем месте пользователя ПЭВМ

-

≤ ВДУ

>ВДУ

-

-

-

-

Таблица 6-4. Временные допустимые уровни (ВДУ) воздействия на человека электромагнитных полей

Виды поля

ВДУ ЭМП (СанПин)

Электрическое

25 В/м

Магнитное

0,2 А/м


Сравнив результаты измерения ЭМП на рабочем месте (таблица 6-2) с данными таблицы ВДУ ЭМП создаваемых ПК (таблица 6-4) и проанализировав по таблице классов условий труда при действии ЭМП (таблица 6-3) был сделан вывод, что класс условий труда на рабочем месте относится к классу 3.1 (вредные условия труда).

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

.5 Расчет контурного защитного заземления ПК

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

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

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

В зависимости от расположения заземлителей по отношению к заземляемому оборудованию заземление бывает выносным и контурным. Заземлители выносных заземлений располагают сосредоточенно на расстоянии свыше 20 м от заземляемого оборудования, т е. вне зоны растекания тока замыкания на землю [5].

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

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

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

Заглубление полосы  (глубина траншеи) принимается равным 0,7 м. Заглубление стержня можно определить по формуле:

Согласно (6.2):

Удельное сопротивление грунта принимается равным 100 Ом ∙ м (тип грунта - суглинок). Тогда сопротивление вертикального одиночного заземлителя согласно (6.1):

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


где  - нормируемое сопротивление растеканию тока заземляющего устройства согласно [5], Ом. Коэффициент сезонности для второй климатической зоны принимается равным 1.6.

Из формулы (6.3):


что, после округления в большую сторону, даст  

Если принять, что вертикальные заземлители размещены в ряд, то длина полосы определяется:


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

Из (6.5) длина полосы равна:


Сопротивление растеканию тока соединительной полосы согласно (6.4):

Сопротивление вертикальных заземлителей с учетом сопротивления растеканию тока соединительной полосы:


Из (6.6):


Окончательное количество заземлителей:


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

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

Полученная величина  удовлетворяет требованиям .

.6 Расчет количества отходов при написании дипломного проекта

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

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


где - вес использованного картриджа, г.;

 - количество использованных пачек бумаги, шт.;

 - количество листов в пачке бумаги;

 - ресурс картриджа, листов на одну заправку.

В паспортных данных на картриджи указывается ресурс, рассчитанный на 5% заполнения (экономичный режим). При реальной эксплуатации ресурс следует уменьшать на 30-50% (в зависимости от качества печати), поэтому вводим поправочный коэффициент равный 0,6.

Бытовые отходы

Количество бытовых отходов  рассчитывается по формуле:


где - число сотрудников на предприятии, чел.;

- норматив образования бытовых отходов на одного работающего;

- плотность бытовых отходов [6].

Согласно (6.11): .

Среднегодовое количество бытовых отходов на одного сотрудника равно 66 кг/год. Согласно [14] это количество не должно превышать 108 кг/год (для административных и других учреждений, офисов), т.е. количество отходов не превышает установленной нормы.

Выводы по главе

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

программный алгоритм интерфейс тестирование

ЗАКЛЮЧЕНИЕ

В ходе выполнения данной дипломной работы был разработан драйвера протокола SPA-BUS, позволяющий вовремя и без потерь собирать данные с микропроцессорных терминалов ОМП для передачи на сервер системы.

Для программного модуля работы с документацией с помощью AllFusion Process Modeler был смоделирован бизнес-процесс.

К основным достоинствам разработанного программного продукта можно отнести:

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

Надежность;

Кроссплатформенность (поддержка ОС Windowsи EmbeddedLinux);

Сбор информации с терминалов ОМП и ее передача на сервер.

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

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

Добавление возможности дистанционного конфигурирования терминала;

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

1. Шилдт Г. С++: базовый курс, 3-е издание. - Москва: Издательский дом «Вильямс», 2010. - 624 с.

. Страуструп Б. Дизайн и эволюция языка С++. - Питер: ДМК Пресс, 2006. - 448 с.

. Александреску А. Современное проектирование наС++: Обобщенное программирование и прикладные шаблоны проектирования. - Москва: Издательский дом «Вильямс», 2004. - 336 с.

. Безопасность жизнедеятельности. Учебник/Под ред. С.В. Белова. - М.: Высшая школа, 2011 - 680 с.

. ГОСТ 12.1.030-81 «Система стандартов безопасности труда. Электробезопасность. Защитное заземление, зануление.»

. SPA-Bus Communication Protocol V2.5. TechnicalDescription. Finland, 2001. 28 p.

. C37.111-1991 - IEEE Standard Common Format for Transient Data Exchange (COMTRADE) for Power Systems

8. Экономическое обоснование разработки программ и алгоритмов: Методические указания к выполнению организационно- экономической части дипломных проектов / Сост. Е.Ф. Перфилова; Чувашский ун-т. Чебоксары, 2001. 50 с.

. Безопасность жизнедеятельности: методические указания и контрольные задания/ сост. В.В. Ашмарин, Э.Н. Рябинина; Чуваш. ун-т, Чебоксары, 2009, 92 с.

. Экология: Метод.указания и контрольные задания/Сост. В.В. Ашмарин; Чуваш. ун-т. Чебоксары, 2010. 106 с

. Техническое описание и инструкция по эксплуатации ИП-50, 25с.

. Санитарно-эпидемиологические правила и нормативы. Гигиенические требования к персональным ЭВМ и организация работы. СанПин 2.2.2/2.4.1340-03. М.: "Книга сервис", 2003. - 16 с.

. Руководство по гигиенической оценке факторов рабочей среды и трудового процесса. Критерии и классификация условия труда. Руководство Р 2.2.2006 -05. 2005, 129с.

. #"551911.files/image092.jpg">

Рисунок А.1 - Диаграмма декомпозиции для работы «Разработка требований»

Рисунок А. 2 - Диаграмма декомпозиции для работы «Анализ требований и проектирование»

Рисунок А.3 - Диаграмма декомпозиции для работы «Написание кода приложения»

Рисунок А.4 - Диаграмма декомпозиции для работы «Тестирование»

Приложение Б

Б.1 Схема исследования и сводные экономические показатели

Приложение В

В.1 Пример осциллограммы в формате COMTRADE

Конфигурационный файл:

-LOC61,1

,8A,64D

1,Ia,,,A,01.697052,0,0,-32768,32767

,Ua,,,V,0155.5631,0,69.4444444444444,-32768,32767

,Ib,,,A,01.697052,0,138.888888888889,-32768,32767

,Ub,,,V,0155.5631,0,208.333333333333,-32768,32767

,Ic,,,A,01.697052,0,277.777777777778,-32768,32767

,Uc,,,V,0155.5631,0,347.222222222222,-32768,32767

,Io,,,A,0.848526,0,416.666666666667,-32768,32767

,Uo,,,V,031.11262,0,486.111111111111,-32768,32767

1,Внешн.сигн,0

,ПО,0

,I1>,0

,I2>,0

5,I0>,0

,dI1>,0

,dI2>,0

,dI0>,0

,Н.изм.ц,0

10,НЦН,0

,НЦТ,0

,СДП,0

,Вход1.1,0

,Вход1.2,0

,Вход1.3,0

,Вход1.4,0

,Вход1.5,0

,Вход1.6,0

,K1.1,0

20,K1.2,0

,K1.3,0

,K1.4,0

,K1.5,0

,no use,0

,nouse,0

50

,320

/15/12,15:10:08.019000

/15/12,15:10:08.119000

Файл данных:

,0,0,0,-1,1,-1,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

,1250,0,0,-1,1,-2,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

3,2500,0,0,-1,1,-2,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

4,3750,0,0,-1,1,-2,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

5,5000,0,0,-1,1,-2,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

6,6250,0,0,-1,1,-2,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

7,7500,0,0,-1,1,-2,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

8,8750,0,-1,-1,1,-1,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

9,10000,0,0,-1,1,-2,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

10,11250,0,0,-1,1,-2,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

,398750,0,0,-1,1,-2,0,1,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

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

 

Не нашли материал для своей работы?
Поможем написать уникальную работу
Без плагиата!