Разработка программного комплекса с целью оптимизации способа хранения данных об измерениях счетчиков

• Введение
• 1. Описание объекта и постановка задач проекта
• 1.1 Описание предметной области
• 1.2 Общая характеристика автоматизированный системы мониторинга и учета электроэнергии на фидерах контактной сети
• 1.3 Структура объекта автоматизированной системы мониторинга и учета электроэнергии на фидерах контактной сети
• 1.3.1 Общее описание структуры
• 1.3.2 Информационно-измерительный комплекс
• 1.3.3 Измерительно-вычислительный комплекс
• 1.3.4 Система обеспечения единого времени
• 1.4 Состав функций реализуемых системой
• 1.5 Сравнение с современными автоматизированными системами коммерческого учета электроэнергии
• 1.5.1 Комплекс технических средств «Энергия»
• 1.5.2 АСКУЭ ITEK-210
• 1.5.3 Автоматизированная система учета и контроля электроэнергии «Марсел»
• 1.5.4 Автоматизированная система коммерческого учета электроэнергии (АСКУЭ)" МСР-Энерго"
• 1.5.5 Программно-технический комплекс «Энергоконтроль»
• 1.5.6 Автоматизированная система контроля и управления энергоресурсами «Спрут»
• 1.6 Постановка задач проекта
• 2. Рассмотрение и анализ используемых средств
• 2.1 Языки программирования
• 2.1.1 Java
• 2.1.2 JavaScript
• 2.2 SpringMVC
• 2.3 JSP
• 2.4 PostgreSQL
• 2.5 Hibernate
• 3. Практическая часть
• 3.1 Концептуальная модель базы данных
• 3.2 Логическая модель базы данных
• 3.3 Физическая модель базы данных
• 3.4 Описание программного комплекса
• 3.4.1 Алгоритмическое обеспечение программного комплекса
• 3.4.2 Основные требования к программному обеспечению
• 3.4.3 Описание программы «MigrationCsvInDB»
• 3.4.4 Описание программы «WebViewer»
• 4. Затраты на создание программного обеспечения
• 4.1 Расчет стоимости программного обеспечения
• 5. Технические способы и средства защиты от электрического тока
• 5.1 Условия, с учетом которых устанавливаются технические способы и средства защиты от электрического тока
• 5.2 Обоснование и конструкция принятых технических средств
• 5.3 Расчет защитного заземления
• Заключение
• Библиографический список

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

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

Автоматизированные системы коммерческого учета электроэнергии (АСКУЭ), внедренные в последнее время в сети железных дорог, позволяют решить вопрос коммерческого учета электроэнергии. Однако АСКУЭ ОАО «РЖД» не решают вопросы оперативного мониторинга распределения электроэнергии в контактной сети, от которой потребляется значительный объем электроэнергии, что в свою очередь не позволяет корректировать уровень небаланса электроэнергии в контактной сети.

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

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

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

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

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

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

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

Исходя из вышестоящих проблем, было решение о разработке данного проекта, целью которого является:

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

реализация средства для просмотра и анализа информации.

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

1. Описание объекта и постановка задач проекта

1.1 Описание предметной области

В ОАО «РЖД» для электроснабжения электрических железных дорог используются контактная сеть и тяговые подстанции.

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

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

Рисунок 1.1 — Схема тяговой подстанции на постоянном токе

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

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

Фидеры контактной сети представляют собой линию электропередачи, соединяющую контактную сеть с тяговой подстанцией.

1.2 Общая характеристика автоматизированный системы мониторинга и учета электроэнергии на фидерах контактной сети

Автоматизированные системы коммерческого учета электроэнергии (АСКУЭ), внедренные в последнее время в сети железных дорог, позволяют решить вопрос коммерческого учета электроэнергии. Однако АСКУЭ ОАО «РЖД» не решают вопросы оперативного мониторинга распределения электроэнергии в контактной сети, от которой потребляется значительный объем электроэнергии, что в свою очередь не позволяет корректировать уровень небаланса электроэнергии в контактной сети.

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

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

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

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

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

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

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

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

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

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

эффективность работы устройств усиления мощности тяговых подстанций (ППН, ВДУ, БАРН и др.).

К основным информативным параметрам относятся:

напряжение, ток (со знаком), значение активной и реактивной мощности (со знаком) по фидерам контактной сети и вводам 3,3 кВ с заданным интервалом времени;

приращение активной и реактивной энергии по фидерам контактной сети и вводам 3,3 кВ на заданном интервале;

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

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

1.3 Структура объекта автоматизированной системы мониторинга и учета электроэнергии на фидерах контактной сети

1.3.1 Общее описание структуры

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

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

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

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

Рисунок 1.2 — Структурная схема системы

Система обеспечения единого времени (СОЕВ) формируется на всех уровнях иерархии и обеспечивает единое время на всех ИИК, ИВКЭ и ИВК, входящих в Систему.

На первом уровне (ИИК) обеспечивается:

автоматическое выполнение измерений и первичной обработки значений тока, напряжения, мощности, полученной и отданной электроэнергии по всем контролируемым электрическим присоединениям с выбранным интервалом: 3 секунды, 6 секунд, 30 секунд, 1 минута или 30 минут;

автоматическое выполнение измерений величин времени и интервалов времени;

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

автоматическая коррекция времени в ИИК;

хранение результатов измерений, информации о состоянии средств измерений в специализированной БД не менее 31 суток;

синхронизация времени ИИК с единым календарным временем

безопасность хранения информации и программного обеспечения (далее ПО) в соответствии с ГОСТ Р 52 069.0 и ГОСТ Р 51 275;

предоставление доступа к измеренным значениям параметров и «Журналам событий» со стороны ИВКЭ;

конфигурирование и параметрирование технических средств и ПО;

диагностика работы технических средств.

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

На втором уровне обеспечивается: автоматический сбор в УСПД ИВКЭ результатов измерений со всех ИИК, входящих в состав данного ИВКЭ:

автоматический сбор в УСПД ИВКЭ данных о состоянии средств измерений («Журналов событий») со всех ИИК, входящих в состав данного ИВКЭ;

автоматический сбор с ИИК текущей информации о параметрах энергопотребления;

автоматическая коррекция времени в ИВКЭ;

автоматическое хранение результатов измерений, состояний средств и объектов измерений в памяти УСПД не менее 31 суток;

ведение «Журнала событий» ;

синхронизация времени ИВКЭ с единым календарным временем;

механическая защита от несанкционированного доступа и пломбирование УСПД;

программная защита УСПД при параметрировании за счет установки пароля;

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

В состав технических средств второго уровня входят:

УСПД, обеспечивающий интерфейс доступа к ИИК и ИВК, а также интерфейс пользователя через жидкокристаллический сенсорный экран;

технические средства приема-передачи данных (каналообразующая аппаратура);

УССВ.

На третьем уровне обеспечивается:

автоматический и/или по запросу сбор результатов измерений со всех ИВКЭ подстанций, входящих в состав;

автоматический и/или по запросу сбор данных о состоянии средств измерений («Журналов событий») со всех ИВКЭ, входящих в состав АСУЭФКС;

автоматическое хранение результатов измерений, журналов событий системы, журналов событий ИИК, журналов событий УСПД в базе данных не менее трех лет;

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

автоматическая коррекция времени в ИВК;

автоматическая передача результатов измерений, данных о состоянии средств измерений в ИВК;

синхронизация времени ИВК с единым календарным временем.

В состав технических средств третьего уровня входят:

серверы для обеспечения функции сбора и хранения результатов измерений с уровня ИВКЭ;

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

технические средства приема-передачи данных;

АРМ.

Система обеспечения единого времени (СОЕВ) выполняет законченную функцию измерений времени, имеет нормированные метрологические характеристики и обеспечивает синхронизацию времени при проведении измерений количества электроэнергии с 5,0 с/сутки. СОЕВ обеспечивает синхронизацию времени на всех уровнях системы.

1.3.2 Информационно-измерительный комплекс

ИИК построены на базе 32-разрядного микропроцессора STM32 с архитектурой ядра Cortex M4, выполняющего первичную обработку результатов измерений, и одноплатного компьютера Тион-Про-28 на базе 32-разрядного микропроцессора Freescale iMX287 с архитектурой ядра АRM9, выполняющего функции сохранения данных в энергонезависимую память и их передачи по сети на верхний уровень системы.

Программное обеспечение ИИК представляет собой программу для контроллера аналого-цифрового преобразователя (АЦП) и программу для модуля хранения и связи с ИВКЭ. Программа контроллера АЦП выпол — нена с использованием языка программирования C++ и компилятора GCC и обеспечивает выполнение следующий функций:

прием данных с АЦП тока и АЦП напряжения;

периодическую калибровку АЦП;

буферизацию данных;

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

обработку данных по запросу (вычисление спектральных характеристик);

передачу данных на модуль хранения и связи с ИВКЭ;

функции самодиагностики.

Программа модуля хранения и связи с ИВКЭ выполняется под управлением операционной системы Windows CE 6.0, выполнена с ис — пользованием языка программирования C++ и обеспечивает выполнение следующих функций:

прием данных с контроллера АЦП;

долговременное хранение данных;

установление связи по протоколу TCP/IP с ИВКЭ и постоянный контроль соединения;

передачу текущих и накопленных данных на ИВКЭ;

управление режимами работы АЦП;

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

функции самодиагностики.

Эта программа, ее состав, алгоритмы, будут подробно описание в нижеследующих разделах, согласно заданию.

1.3.3 Измерительно-вычислительный комплекс

В состав технического обеспечения ИВК входят:

серверы ССДТ и СТП;

АРМы пользователей и эксплуатационного персонала;

коммуникационное оборудование;

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

Коммуникационное оборудование обеспечивает:

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

обеспечение информационного взаимодействия ИВКЭ с ИВК, ИВК с внешними информационными системами;

резервирование каналов и средств связи;

контроль функционирования каналов связи;

автоматическое хранение результатов измерений, журналов событий ИИК, УСПД и системы (не менее 3 лет).

Программное обеспечение ИВКЭ выполняется под управлением операционной системы Windows CE 6.0 и.net Microframework, выполнено с использованием языка программирования C# и обеспечивает выполнение следующих функций:

установление связи по протоколу TCP/IP с ИИК и постоянный контроль соединения;

прием данных с ИИК по протоколу TCP/IP;

долговременное хранение данных;

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

Программное обеспечение ИВК выполняется под управлением операционной системы Windows Server и обеспечивает выполнение следующих функций:

установление связи по протоколам TCP/IP и FTP с ИВКЭ и постоянный контроль соединения;

прием данных с ИВКЭ по протоколам TCP/IP и FTP;

долговременное хранение данных и их архивирование;

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

функции самодиагностики.

1.3.4 Система обеспечения единого времени

Система обеспечения единого времени (СОЕВ) — выполняет законченную функцию измерений времени, имеет нормированные метрологические характеристики и обеспечивает синхронизацию времени. Для обеспечения единства измерений в системе используется единое календарное время. УССВ как компонент СОЕВ обеспечивает:

автоматическую синхронизацию времени с внешним источником единого календарного времени;

неточность синхронизации — не более 1 с при частоте синхронизации не реже одного раза в сутки;

функционирование в составе СОЕВ, обеспечивающей синхронизацию устройств с точностью 5 секунд в сутки.

1.4 Состав функций реализуемых системой

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

Таблица 1.1 — Функции системы, периодичность их выполнения, степени централизации и критерии отказов

Продолжение таблицы1.1

1.5 Сравнение с современными автоматизированными системами коммерческого учета электроэнергии

Ввиду большой эффективности АСКУЭ на рынке присутствует большое количество коммерческих аналогов АСУЭФКС. Ниже представлены одни из самых популярных систем.

1.5.1 Комплекс технических средств «Энергия»

Комплекс технических средств «Энергия» (КТС «Энергия») предназначен для измерения электрической энергии, обработки полученной по каналам учета информации и выдачи результатов обработки в виде таблиц, графиков, ведомостей на видеомонитор и печатающее устройство IBM PC/AT совместимого компьютера. КТС «Энергия» предназначен также для построения автоматизированных систем учета и контроля электроэнергии и энергоносителей (АСУЭ) на предприятиях с развитой структурой энергопотребления. АСУЭ, построенная на базе КТС «Энергия», позволяет вести коммерческие расчеты за энергопотребление на предприятиях с любой схемой энергоснабжения. АСУЭ, построенная на базе КТС «Энергия», может применяться на промышленных предприятиях, рассчитывающихся за потребляемую энергию по двухставочным и дифференцированным зонным тарифам; на электростанциях, подстанциях при организации учета выработки и перетоков энергии; на предприятиях Энергосбыта при организации оперативного сбора информации о выработке и потреблении электроэнергии и введении ограничений на электропотребление. Связь в АСУЭ организуется: по выделенным двухпроводным симплексным линиям; по выделенным двухпроводным полудуплексным линиям; по телефонным линиям с использованием модемов; по радиоканалам, с применением средств связи КТС «КОРАТ» .

Таблица 1.2 — Технические характеристикиКТС «Энергия»

Используются операционные системы MS DOS и WINDOWS NT. Дополнительное применение в составе КТС «Энергия+» УСД Е443М3 (EURO), Е443М4 (EURO) и преобразователя «Исток-ТМ» позволяет организовать коммерческий и технический учет тепловой энергии и расходов жидких и газообразных энергоносителей в соответствии с ГОСТ 8.563−97 и «Правилами учета тепловой энергии и теплоносителей». Комплекс «Энергия» имеет Сертификаты Госстандарта России, стран СНГ: Казахстан, Украина, Беларусь, Узбекистан.

1.5.2 АСКУЭ ITEK-210

Устройство учета ITEK-210 предназначено для построения автоматизированных систем коммерческого и технологического учета электроэнергии (АСКУЭ), обеспечивающих контроль и учет параметров электрической энергии и мощности (активной и реактивной составляющих) по тарифным зонам суток. В качестве первичных измерительных преобразователей (ПИП) в АСКУЭ могут использоваться счетчики электроэнергии: индукционные, снабженные устройствами формирования импульсов; электронные с импульсным выходом. ITEK-210 может быть использован совместно или взамен ранее установленных систем ЦТ5000 (путем подключения к существующей матрице ПИП).

Основные возможности:

измерение, расчет и накопление в реальном времени параметров;

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

гибкая поддержка многотарифного учета потребления электроэнергии;

энергонезависимые память и часы;

ведение показаний счетных механизмов

генерация управляющих сигналов;

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

работа в распределенной среде;

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

средняя 3 и 30 минутная мощность.

скользящая средняя 30-ти мин. мощность.

прогнозируемое значение получасовой мощности и ее отклонение от договорного значения на конец текущего получаса.

отклонение от договорного значения (лимита) потребления энергии за прошедшие учетные периоды: сутки, месяц, квартал.

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

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

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

энергия, соответствующая показаниям счетных механизмов счетчиков.

усредненные значения мощности перетоков за текущие и прошедшие 1 и 30 минут.

значение энергии перетоков по тарифным зонам за текущие и прошедшие учетные периоды: сутки, рабочие/нерабочие дни месяца и квартала.

Таблица 1.3 — Технические характеристики АСКУЭ ITEK-210

1.5.3 Автоматизированная система учета и контроля электроэнергии «Марсел»

Система «МАРСЕЛ» предназначена для измерения потребленной и выданной электрической энергии и мощности, а также автоматического сбора, накопления, обработки, хранения и отображения полученной информации.

Функции системы:

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

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

построение графиков получасовых и трехминутных нагрузок.

Таблица 1.4 — Технические характеристики АСКУЭ «МАРСЕЛ»

1.5.4 Автоматизированная система коммерческого учета электроэнергии (АСКУЭ)" МСР-Энерго"

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

АСКУЭ «МСР-Энерго» адаптируется под заказчика, отвечает требованиям энергосбытовых организаций и обеспечивает выход на ФОРЭМ.

Функциональные задачи:

сбор и обработка информации о потребляемой электроэнергии;

вычисление необходимых заказчику параметров и долговременное хранение их в памяти eстройства сбора данных (УСПД);

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

Основные преимущества «МСР-ЭНЕРГО» :

передача данных для коммерческого учета осуществляется непосредственно с первого уровня системы (УСПД);

повышенная надежность за счет защиты информации;

масштабируемость;

открытая архитектура системы с возможностью наращивания функций;

работа на всех видах каналов связи;

поддержка распределенной (корпоративной) структуры управления;

гибкость и адаптируемость.

1.5.5 Программно-технический комплекс «Энергоконтроль»

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

Основные функции ПТК «Энергоконтроль» :

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

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

создание и ведение архивов потребленной энергии и газа;

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

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

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

автоматическое регулирование тепловых нагрузок.

Состав ПТК «Энергоконтроль» :

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

система сбора и обработки данных:

технические средства сбора данных;

среда передача данных;

оборудование диспетчерского центра.

Основные концепции, заложенные при разработке ПТК:

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

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

пакет программ, поставляемый пользователю, открыт для развития специалистами пользователя;

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

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

1.5.6 Автоматизированная система контроля и управления энергоресурсами «Спрут»

Назначение: АСКУЭ «Спрут» предназначена для обеспечения постоянного контроля за потреблением любого вида энергоресурсов на всех участках производства, снижения энергопотребления за счет оптимизации в реальном масштабе времени режимов работы оборудования, автоматизации управления технологическими процессами энергопотребления, а также контроля параметров качества электроэнергии в соответствии с ГОСТ 13 109–97 и контроля несанкционированного использования энергоресурсов.

В состав АСКУЭ «Спрут» входят:

— АРМ клиентов;

— сервера;

— контроллеры, выполняющие функции связи с коммутаторами и цифро-аналогового преобразования сигналов;

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

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

— исполнительные механизмы;

— вычислители;

— радио или телефонные модемы;

— сетевое оборудование;

— громкоговорители.

Основные особенности и характеристики АСКУЭ «Спрут» :

— возможность организации до 16 000 каналов контроля одним сервером;

— возможность контроля качества получаемой электроэнергии по 6-ти основным параметрам в соответствии с ГОСТ 13 109–97, а также измерение частоты подводимого напряжения, фазных (линейных) и межфазных напряжений;

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

— совместимость с интерфейсами RS 485, RS 232; датчиками с выходом типа «токовая петля» на 5 и 20 мА или «сухой контакт» ;

— возможность обработки аналоговых (до 10 кГц) и цифровых сигналов;

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

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

— «дружественный» интерфейс обмена с операторами под управлением WINDOWS;

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

— измерение токов от 0 до 2000 А в цепях до 400 В без дополнительных понижающих трансформаторов тока;

— монтаж датчиков тока без разрыва цепей и прерывания электроснабжения;

— 100% защита системы от взлома и возможность раннего обнаружения неисправности цепей съема первичной информации;

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

— планирование и распределение электроэнергии по потребителям и во времени на основе данных, хранимых в ПЭВМ;

— контроль работы оборудования в реальном масштабе времени;

— отключение оборудования в случае превышения установленных лимитов энергопотребления или нарушения установленного графика работы;

— хранение и выдача «генплана» предприятия, структурных схем подразделений с привязкой к ним схем электроснабжения с одновременным выводом данных об энергопотреблении по выбранному на схеме объекту;

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

Таким образом, сравнив технические характеристики представленных выше систем, следует отметить тот факт, что ни одна из них не удовлетворяет в полной мере всех требований ОАО «РЖД». Поэтому разработка автоматизированной системы учета электроэнергии на фидерах контактной сети (АСУЭФКС) является актуальной проблемой.

1.6 Постановка задач проекта

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

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

Таким образом, проанализировав данные проблемы, были сформулированы следующие четыре задачи:

выбрать СУБД для хранения данных;

разработать концептуальную модель базы данных для хранения данных об измерениях;

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

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

2. Рассмотрение и анализ используемых средств

2.1 Языки программирования

2.1.1 Java

Java — объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems (в последующем приобретенной компанией Oracle). Приложения Java обычно транслируются в специальный байт-код, поэтому они могут работать на любой виртуальной Java-машине вне зависимости от компьютерной архитектуры. Дата официального выпуска — 23 мая 1995 года.

Изначально язык назывался Oak («Дуб») разрабатывался Джеймсом Гослингом для программирования бытовых электронных устройств. Впоследствии он был переименован в Java и стал использоваться для написания клиентских приложений и серверного программного обеспечения. Назван в честь марки кофе Java, которая, в свою очередь, получила наименование одноименного острова (Ява), поэтому на официальной эмблеме языка изображена чашка с дымящимся кофе. Существует и другая версия происхождения названия языка, связанная с аллюзией на кофе-машину как пример бытового устройства, для программирования которого изначально язык создавался.

Программы на Java транслируются в байт-код, выполняемый виртуальной машиной Java (JVM) — программой, обрабатывающей байтовый код и передающей инструкции оборудованию как интерпретатор.

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

Часто к недостаткам концепции виртуальной машины относят снижение производительности. Ряд усовершенствований несколько увеличил скорость выполнения программ на Java:

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

широкое использование платформенно-ориентированного кода (native-код) в стандартных библиотеках;

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

По данным сайта shootout. alioth. debian.org, для семи разных задач время выполнения на Java составляет в среднем в полтора-два раза больше, чем для C/C++, в некоторых случаях Java быстрее, а в отдельных случаях в 7 раз медленнее. С другой стороны, для большинства из них потребление памяти Java-машиной было в 10−30 раз больше, чем программой на C/C++. Также примечательно исследование, проведенное компанией Google, согласно которому отмечается существенно более низкая производительность и большее потребление памяти в тестовых примерах на Java в сравнении с аналогичными программами на C++.

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

Выполнение дипломного проекта осуществлялось на Java7, поэтому рассмотрим ее более подробно.

Релиз версии состоялся 28 июля 2011 года. В финальную версию Java Standard Edition 7 не были включены все ранее запланированные изменения. Согласно плану развития (план «Б»), включение нововведений будет разбито на две части: Java Standard Edition 7 (без лямбда-исчисления, проекта Jigsaw, и части улучшений Coin) и Java Standard Edition 8 (все остальное), намеченный на конец 2012 года.

В новой версии, получившей название Java Standard Edition 7 (Java Platform, Standard Edition 7), помимо исправления большого количества ошибок, было представлено несколько новшеств. Так, например, в качестве эталонной реализации Java Standard Edition 7 использован не проприетарный пакет JDK, а его открытая реализация OpenJDK, а сам релиз новой версии платформы готовился при тесном сотрудничестве инженеров Oracle с участниками мировой экосистемы Java, комитетом JCP (Java Community Process) и сообществом OpenJDK. Все поставляемые Oracle бинарные файлы эталонной реализации Java Standard Edition 7 собраны на основе кодовой базы OpenJDK, сама эталонная реализация полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с проприетарными продуктами. К другим нововведениям относится интеграция набора небольших языковых улучшений Java, развиваемых в рамках проекта Coin, добавлена поддержка языков программирования с динамической типизацией, таких, как Ruby, Python и JavaScript, поддержка загрузки классов по URL, обновленный XML-стек, включающий JAXP 1.4, JAXB 2.2a и JAX-WS 2.2 и другие.

За 5 дней до выхода релиза Java Standard Edition 7 было обнаружено несколько серьезных ошибок в горячей оптимизации циклов, которая включена по умолчанию и приводит виртуальную машину Java к краху. Специалисты Oracle найденные ошибки за столь короткий срок исправить не могли, но пообещали, что они будут исправлены во втором обновлении (Java 7 Update 2) и частично в первом.

Список нововведений:

Поддержка динамически-типизированных языков (InvokeDynamic) — расширение JVM (семантики байт-кода), языка Javaдля поддержки динамически-типизированных языков.

Строгая проверка class-файлов — class-файлы версии 51 (Java Standard Edition 7) или более поздней версии должны быть проверены typechecking-верификатором; JVM не должна переключаться на старый верификатор.

Изменение синтаксиса языка Java (Project Coin) — частичные изменения в языке Java, предназначенные для упрощения общих задач программирования:

использование класса String в блоке switch.

закрытие используемых ресурсов в блоке try (try-with-resources) — работает при использовании интерфейса AutoCloseable.

объединенная обработка исключений в блоке catch (multi-catch exceptions) — перечисление обрабатываемых исключений в catch (… | … | …).

повторное выбрасывание исключений (rethrowing exceptions) — передача возникшего исключения «вверх» по стеку вызовов.

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

изменение вывода типа в Java generic при создании объекта.

использование двоичных чисел (binary literals) — префикс «0b» укажет, что используется двоичное число.

упрощение вызова методов varargs — уменьшение предупреждений при вызове метода с переменным числом входящих переменных.

Модификация загрузчика классов (class-loader) — избежание тупиковых ситуаций в неиерархической топологии загрузки классов.

Закрытие ресурсов, открытых URLClassLoader.

Обновление коллекций (JSR 166).

Поддержка Unicode 6.0.

Отделение языка пользователя и языка пользовательского интерфейса — обновление обработки языков для отделения локали от языка пользовательского интерфейса.

Новые интерфейсы I/O для платформы Java (nio.2).

Использование JDBC 4.1 и Rowset 1.1.

Внутри Java существуют несколько основных семейств технологий:

Java SE — Java Standard Edition, основное издание Java, содержит компиляторы, API, Java Runtime Environment; подходит для создания пользовательских приложений, в первую очередь — для настольных систем.

Java EE — Java Enterprise Edition, представляет собой набор спецификаций для создания программного обеспечения уровня предприятия.

Java ME — Java Micro Edition, создана для использования в устройствах, ограниченных по вычислительной мощности, например, в мобильных телефонах, КПК, встроенных системах;

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

Java Card — технология предоставляет безопасную среду для приложений, работающих на смарт-картах и?? других устройствах с очень ограниченным объемом памяти и возможностями обработки.

КомпаниейMicrosoftбыла разработана собственная реализацияJVM (MSJVM), включавшаяся в состав различных операционных систем, начиная сWindows 98 (также входила в Internet Explorer от версии 3 и выше, что позволяло использовать MSJVM (Microsoft java virtual machine) в ОС Windows 95 и Windows NT 4 после установки IE3+ на данные ОС).

MSJVM имела существенные отличия от Sun Java, во многом ломающие основополагающую концепцию переносимости программ между разными платформами:

отсутствие поддержкипрограммного интерфейсавызова удаленных методов (RMI);

отсутствие поддержки технологииJNI;

наличие нестандартных расширений, таких, как средства интеграции Java иDCOM, работающих только на платформе Windows.

Тесная интеграция Java с DCOM и Win32 поставила под вопрос кроссплатформенную парадигму языка. Впоследствии это явилось поводом для судебных исков со стороны Sun Microsystems к Microsoft. Суд принял сторону компании Sun Microsystems. В конечном счете между двумя компаниями была достигнута договоренность о возможности продления срока официальной поддержки пользователей нестандартной Microsoft JVM до конца 2007 года.

В 2005 году компанией Microsoft для платформы. netбыл представлен Java-подобный языкJ#, не соответствующий официальной спецификации языка Java и исключенный впоследствии из стандартного инструментария разработчикаMicrosoft Visual Studio, начиная с Visual Studio 2008.

Язык Java активно используется для создания мобильных приложений под операционную систему Android. При этом программы компилируются в нестандартный байт-код, для использования их виртуальной машиной Dalvik. Для такой компиляции используется дополнительный инструмент, а именно Software Development Kit, разработанный компанией Google.

Разработку приложений можно вести в среде Android Studio, NetBeans, в среде Eclipse, используя при этом плагин Android Development Tools (ADT) или в IntelliJ IDEA. Версия JDK при этом должна быть 5.0 или выше.

8 декабря 2014 года Android Studio признана компанией Google официальной средой разработки под ОС Android.

Следующие успешные проекты реализованы с привлечением Java (J2EE) технологий: RuneScape, Amazon, eBay, LinkedIn, Yahoo!

Следующие компании в основном фокусируются на Java (J2EE) технологиях: SAP, IBM, Oracle. В частности, СУБД Oracle Database включает JVM как свою составную часть, обеспечивающую возможность непосредственного программирования СУБД на языке Java, включая, например, хранимые процедуры.

Программы, написанные на Java, имеют репутацию более медленных и занимающих больше оперативной памяти, чем написанные на языке Си. Тем не менее, скорость выполнения программ, написанных на языке Java, была существенно улучшена с выпуском в 1997 — 1998 годах так называемого JIT-компилятора в версии 1.1 в дополнение к другим особенностям языка для поддержки лучшего анализа кода (такие, как внутренние классы, класс StringBuffer, упрощенные логические вычисления и т. д.). Кроме того, была произведена оптимизация виртуальной машины Java — с 2000 года для этого используется виртуальная машина HotSpot. По состоянию на февраль 2012 года, код Java 7 приблизительно лишь в 1.8 раза медленнее кода, написанного на языке Си.

Некоторые платформы предлагают аппаратную поддержку выполнения для Java. К примеру, микроконтроллеры, выполняющие код Java на аппаратном обеспечении вместо программной JVM, а также основанные на ARM процессоры, которые поддерживают выполнение байткода Java через опцию Jazelle.

Основные возможностиJava:

автоматическое управление памятью;

расширенные возможности обработки исключительных ситуаций;

богатый набор средств фильтрации ввода-вывода;

набор стандартных коллекций: массив, список, стек и т. п.;

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

наличие классов, позволяющих выполнять HTTP-запросы и обрабатывать ответы;

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

унифицированный доступ к базам данных:

на уровне отдельных SQL-запросов — на основе JDBC, SQLJ;

на уровне концепции объектов, обладающих способностью к хранению в базе данных — на основе Java Data Objects (англ.) и Java Persistence API;

поддержка обобщений (начиная с версии 1.5);

параллельное выполнение программ.

2.1.2 JavaScript

JavaScript (джаваскрипт) — прототипно-ориентированный сценарный язык программирования.

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

Основные архитектурные черты:

динамическая типизация;

слабая типизация;

автоматическое управление памятью;

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

функции как объекты первого класса.

На JavaScript оказали влияние многие языки, при разработке была цель сделать язык похожим на Java, но при этом легким для использования непрограммистами. Языком JavaScript не владеет какая-либо компания или организация, что отличает его от ряда языков программирования, используемых в веб-разработки.

Название «JavaScript» является зарегистрированным товарным знаком компании Oracle Corporation.

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

Несмотря на схожий с Си синтаксис, JavaScript по сравнению с языком Си имеет коренные отличия:

объекты, с возможностью интроспекции;

функции как объекты первого класса;

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

автоматическая сборка мусора;

анонимные функции.

В языке отсутствуют такие полезные вещи, как:

модульная система: JavaScript не предоставляет возможности управлять зависимостями и изоляцией областей видимости;

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

стандартные интерфейсы к веб-серверам и базам данных;

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

Синтаксис языка JavaScript во многом напоминает синтаксис Си и Java, семантически же язык гораздо ближе к Self, Smalltalk или даже Лиспу.

В JavaScript:

все идентификаторы регистрозависимы;

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

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

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

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

ядро (ECMAScript);

объектная модель браузера (Browser Object Model или BOM);

объектная модель документа (Document Object Model или DOM);

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

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

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

Объектная модель браузера — браузер-специфичная часть языка, являющаяся прослойкой между ядром и объектной моделью документа. Основное предназначение объектной модели браузера — управление окнами браузера и обеспечение их взаимодействия. Каждое из окон браузера представляется объектом «window», центральным объектом DOM. Объектная модель браузера на данный момент не стандартизирована, однако спецификация находится в разработке WHATWGи W3C.

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

управление фреймами;

поддержка задержки в исполнении кода и зацикливания с задержкой;

системные диалоги;

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

управление информацией о браузере;

управление информацией о параметрах монитора;

ограниченное управление историей просмотра страниц;

поддержка работы с HTTP cookie.

Объектная модель документа — интерфейс программирования приложений для HTML и XML-документов. Согласно DOM, документ (например, веб-страница) может быть представлен в виде дерева объектов, обладающих рядом свойств, которые позволяют производить с ним различные манипуляции:

— генерация и добавление узлов;

— получение узлов;

— изменение узлов;

— изменение связей между узлами;

— удаление узлов.

Встраивание в веб-страницы

— расположение внутри страницы;

— расположение внутри тега;

— вынесение в отдельный файл.

Область применения:

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

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

Comet.comet — широкое понятие, описывающее механизм работы веб-приложений, использующих постоянные HTTP-соединения, что позволяет веб-серверу отправлять данные браузеру без дополнительного запроса со стороны браузера. Для таких приложений используются технологии, непосредственно поддерживаемые браузерами. В частности, в них широко используется JavaScript.

Браузерные операционные системы. JavaScript широко используется в браузерных операционных системах. Так, например, исходный код IndraDesktop WebOS на 75% состоит из JavaScript, код браузерной операционной системы IntOS — на 70%. Доля JavaScript в исходном коде eyeOS — 5%, однако и в рамках этой операционной системы JavaScript играет важную роль, участвуя в визуализации на клиенте и являясь необходимым механизмом для коммуницирования клиента и сервера.

Серверные приложения. Приложения, написанные на JavaScript, могут исполняться на серверах, использующих Java 6 и более поздних версий. Это обстоятельство используется для построения серверных приложений, позволяющих обрабатывать JavaScript на стороне сервера. Помимо Java 6, существует ряд платформ, использующих существующие движки (интерпретаторы) JavaScript для исполнения серверных приложений. (Как правило, речь идет о повторном использовании движков, ранее созданных для исполнения кода JavaScript в браузерах WWW.)

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

Среди известных JavaScript библиотек можно отметить Adobe life, Dojo Toolkit, Extjs, jQuery, Mootools, Prototype, Qooxdoo, Underscore.

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

По состоянию на ноябрь 2009 года, Internet Explorer, Opera, Firefox, Safari, и Google Chrome имеют отладчики сценариев.

Internet Explorer имеет три отладчика: Microsoft Visual Studio — самый полный из них, за ним следует Microsoft Script Editor (компонент Microsoft Office), и, наконец, свободный Microsoft Script Debugger, гораздо более простой, чем два других. Бесплатный Microsoft Visual Web Developer Express предоставляет ограниченную версию с отладочной функцией JavaScript в Microsoft Visual Studio. В восьмой версии в IE вместе с инструментами для разработчиков появился встроенный отладчик.

В Opera также имеется собственный отладчик — Opera Dragonfly.

Разрабатываемые веб-приложения в Firefox можно отлаживать при помощи расширений Firebug, Venkman.

В Safari входитотладчик JavaScript WebKit Web Inspector. Этот же отладчик доступен и в других браузерах, использующих WebKit: Google Chrome, Arora, Rekonq, Midori и др.

Большинство фреймворков автоматизированного тестирования JavaScript-кода предполагают запуск тестов в браузере. Это осуществляется при помощи HTML-страницы, являющейся контекстом тестирования, которая, в свою очередь загружает все необходимое для осуществления тестирования. Первыми такими фреймворками были JsUnit (создан в 2001 году), Selenium (создан в 2004 году). Альтернатива — запуск тестов из командной строки. В этом случае используются окружения, отличные от браузера, например, Rhino. Одним из первых инструментов такого рода является Crosscheck, позволяющий тестировать код, эмулируя поведение Internet Explorer 6 и Firefox версий 1.0 и 1.5 Другой пример фреймворка автоматизированного тестирования JavaScript-кода, не использующего браузер для запуска тестов — библиотека env. js, созданная Джоном Резигом. Она использует Rhino и при этом содержит эмуляцию окружения браузера и DOM.

Blue Ridge, плагин к фреймворку веб-приложений Ruby on Rails, позволяет осуществлять модульное тестирование JavaScript-кода как в браузере, так и вне его. Это достигается за счет использования фреймворка автоматизированного тестирования Screw. Unit и Rhino с env. js.

Главная проблема систем тестирования, не использующих браузеры, в том, что они используют эмуляции, а не реальные окружения, в которых выполняется код. Это приводит к тому, что успешное прохождение тестов не гарантирует того, что код корректно отработает в браузере. Проблемой систем тестирования, использующих браузер, является сложность работы с ними, необходимость осуществления рутинных неавтоматизированных действий. Для решения этого JsTestDriver, фреймворк автоматизированного тестирования, разрабатываемый Google, использует сервер, взаимодействующий с браузерами для осуществления тестирования. Сходным образом ведет себя Selenium Remote Control, входящий во фреймворк автоматизированного тестирования Selenium: он включает в себя сервер, запускающий и завершающий браузеры и действующий как HTTP-прокси для запросов к ним. Кроме того, в Selenium содержится Selenium Grid, позволяющий осуществлять одновременное тестирование JavaScript-кода на разных компьютерах с разными окружениями, уменьшая время выполнения тестов. Testswarm, имеющее поддержку фреймворков автоматизированного тестирования JavaScript-кода QUnit (библиотека jQuery), UnitTestJS (библиотека Prototype), JSSpec (библиотека MooTools), JsUnit, Selenium и Dojo Objective Harness, представляет собой распределенное средство поддержки непрерывной интеграции.

Негативное свойство, которым может обладать фреймворк автоматизированного тестирования JavaScript-кода — наличие зависимостей. Это создает риск отказа в работе тестируемого кода, успешно проходящего тесты, в среде с отсутствием этих зависимостей. Например, исходная версия JsUnitTest, фреймворка, созданного и использовавшегося для тестирования библиотеки Prototype, зависела от самой Prototype, изменяющего свойства объектов в глобальной области видимости. Включение в библиотеку JavaScript инструмента тестирования — распространенная практика. Так YUI Test 3 является частью Yahoo! UI Library и может быть безопасно использован для тестирования произвольного JavaScript-кода. QUnit — фреймворк автоматизированного тестирования, созданный разработчиками jQuery.

2.2 SpringMVC

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

Класс DispatcherServlet является основным контроллером фрэймворка и отвечает за делегирование управления различным интерфейсам, на всех этапах выполнения HTTP — запроса. Об этих интерфейсах следует сказать более подробно.

Spring MVC является фреймворком, ориентированным на запросы. В нем опредены стратегические интерфейсы для всех функций современной запросно-ориентированной системы. Цель каждого интерфейса? быть простым и ясным, чтобы пользователям было легко его заново имплементировать, если они того пожелают. MVC прокладывает путь к более чистому front — end — коду. Все интерфейсы тесно связаны с Servlet API.

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

Эта связь рассматривается некоторыми как неспособность разработчиков Spring предложить для веб — приложений абстракцию более высокого уровня. Однако эта связь оставляет особенности Servlet API доступными для разработчиков, облегчая все же работу с ним. Наиболее важные интерфейсы, определенные Spring MVC, перечислены ниже:

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

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

Controller: включен между Моделью (Model) и Представлением (View). Управляет процессом преобразования входящих запросов в адекватные ответы. Действует как ворота, направляющие всю поступающую информацию. Переключает поток информации из модели в представление и обратно;

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

ViewResolver: выбор, какое именно View должно быть показано клиенту;

HandlerInterceptor: перехват входящих запросов. Сопоставим, но не эквивалентен сервлет — фильтрам (использование не является обязательным и не контролируется DispatcherServlet-ом);

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

MultipartResolver: обеспечивает Upload — загрузку на сервер локальных файлов клиента;

Spring MVC предоставляет разработчику следующие возможности:

ясное и прозрачное разделение между слоями в MVC и запросах;

стратегия интерфейсов — каждый интерфейс делает только свою часть работы;

интерфейс всегда может быть заменен альтернативной реализацией;

интерфейсы тесно связаны с Servlet API;

высокий уровень абстракции для веб-приложений.

2.3 JSP

JSP (JavaServer Pages) — технология, позволяющая веб-разработчикам создавать содержимое, которое имеет как статические, так и динамические компоненты. Страница JSP содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов HTML, SVG, WML, или XML, и JSP — элементы, которые конструируют динамическое содержимое. Кроме этого могут использоваться библиотеки JSP-тегов, а также EL (Expression Language), для внедрения Java-кода в статичное содержимое JSP-страниц.

Код JSP-страницы транслируется в Java-код сервлета с помощью компилятора JSP-страниц Jasper, и затем компилируется в байт-код виртуальной машины java (JVM). Контейнеры сервлетов, способные исполнять JSP-страницы, написаны на платформонезависимом языке Java. JSP-страницы загружаются на сервере и управляются из структуры специального Java server packet, который называется Java EE Web Application. Обычно страницы упакованы в файловые архивы. war и. ear.

JSP является платформонезависимой, переносимой и легко расширяемой технологией для разработки веб-приложений.

2.4 PostgreSQL

Свободная объектно-реляционная система управления базами данных (СУБД). PostgreSQL является самым профессиональным СУБД. Она свободно распространяемая и максимально соответствует стандартам SQL.

От других СУБД PostgreSQL отличается поддержкой востребованного объектно-ориентированного и/или реляционного подхода к базам данных. Например, полная поддержка надежных транзакций, т. е. атомарность, последовательность, изоляционность, прочность. Благодаря мощным технологиям Postgre очень производительна. Параллельность достигнута не за счет блокировки операций чтения, а благодаря реализации управления многовариантным параллелизмом (MVCC). PostgreSQL очень легко расширять своими процедурами, которые называются хранимые процедуры. Эти функции упрощают использование постоянно повторяемых операций.

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

Достоинства PostgreSQL:

открытое ПО соответствующее стандарту SQL. PostgreSQL — бесплатное ПО с открытым исходным кодом. Эта СУБД является очень мощной системой;

большое сообщество, существует довольно большое сообщество в котором вы запросто найдете ответы на свои вопросы;

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

расширения — существует возможность расширения функционала за счет сохранения своих процедур;

объектность — PostrgreSQL это не только реляционная СУБД, но также и объектно-ориентированная с поддержкой наследования и много другого.

Когда использовать PostgreSQL:

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

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

интеграция, если в будущем вы планируете переход на платные СУБД, например Oracle, то сделать это с PostgreSQL будет довольно просто по сравнению с другими бесплатными СУБД;

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

2.5 Hibernate

Hibernate? библиотека для языка программирования Java, предназначенная для решения задач объектно-реляционного отображения (ORM). Она представляет собой свободное программное обеспечение с открытым исходным кодом (open source). Данная библиотека предоставляет легкий в использовании каркас (фреймворк) для отображения объектно-ориентированной модели данных в традиционные реляционные базы данных.

Целью Hibernate является освобождение разработчика от значительного объема сравнительно низкоуровневого программирования по обеспечению хранения объектов в реляционной базе данных. Разработчик может использовать Hibernate как в процессе проектирования системы классов и таблиц «с нуля», так и для работы с уже существующей базой данных.

Hibernate не только решает задачу связи классов Java с таблицами базы данных (и типов данных Java с типами данных SQL), но и также предоставляет средства для автоматической генерации и обновления набора таблиц, построения запросов и обработки полученных данных и может значительно уменьшить время разработки, которое обычно тратится на ручное написание SQL — и JDBC-кода. Hibernate автоматизирует генерацию SQL-запросов и освобождает разработчика от ручной обработки результирующего набора данных и преобразования объектов, максимально облегчая перенос (портирование) приложения на любые базы данных SQL.

Hibernate обеспечивает прозрачную поддержку сохранности данных.

3. Практическая часть

3.1 Концептуальная модель базы данных

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

В чем же преимущество базы данных перед хранением информации в множестве однородных файлов?

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

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

В-третьих, увеличивается скорость доступа к информации программными методами. Код программы будет гораздо проще, когда обращения программы будут направлены СУБД, а не ОС. Это факт не только позволяет обеспечить мультиплатформенность системы, но и скорость работы сервисов по получению данных значительно увеличится.

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

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

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

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

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

тяговая подстанция;

счетчик тяговой подстанции;

измерение счетчика в один момент времени.

Создадим сущности концептуальной модели на основе этих объектов предметной области.

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

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

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

идентификатор подстанции, которой принадлежит данный счетчик;

счетчик, с которым данный соединен контактной сетью;

символьное имя счетчика;

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

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

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

Рисунок 3.1 — Концептуальная модель проектируемой базы данных

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

3.2 Логическая модель базы данных

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

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

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

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

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

Определившись с видом логической модели, спроектируем ее на основе сущностей концептуальной модели.

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

Рисунок 3.2 — ER-диаграмма сущности тяговой подстанции

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

В таблице ниже приведены все атрибуты отношения, краткое описание и тип данных.

Таблица 3.1 — Описание атрибутов отношения

Следующей сущностью будет Счетчик. На ее основе создадим отношение TS_METER. В данном отношении один атрибут (tsm_id) будет служить суррогатным первичным ключом, два атрибута (ts_id и tsm_nearby) — внешними ключами, которые ссылаются на номер тяговой подстанции и на номер счетчика соответственно. Во втором случае, следует отметить, что отношение будет ссылаться на самого себя.

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

Рисунок 3.3 — ER-диаграмма сущности счетчика В таблице 3.2 показано соотношение атрибутов сущности со свойствами счетчика.

Таблица 3.2 — Описание атрибутов модели

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

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

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

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

Таблица 3.3 — Описание атрибутов модели

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

Отношение TS_MENSURATION (ts_meter_id) связано с отношениемTS_METER (tsm_id) с кардинальностью много-к-одному, так много измерений, могут принадлежать одному счетчику, а у каждого измерения может быть только один счетчик.

Отношение TS_METER (ts_id) имеет связь с отношением TS (ts_id) с кардинальностью много-к-одному, потому что на подстанции находятся несколько счетчиков (около десяти), а каждый счетчик может иметь только одну подстанцию. Этот факт следует из предметной области. Отношение TS_METER также связано с самим собой: атрибут tsm_nearby связан с атрибутом tsm_id с кардинальностью один-к-одному.

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

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

3.3 Физическая модель базы данных

Физическая модель базы данных будет разрабатываться для СУБД PostgreSQL 9.4

Таблицы в базе данных будут создаваться операторами DDL языка SQL, стандарта SQL-92, поддержка которого осуществляется СУБД.

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

Таблица 3.4 — Соответствие типов логической и физической моделей

После того, как были определены типы данных, создадим таблицы, на основе отношений, описанных в логической модели. Для этого воспользуемся встроенной утилитой СУБД для написания SQL запросов. Создадим таблицу TS:

Листинг 3.1 — SQL запрос для создания таблицы TS

Выполнив данный запрос, СУБД помимо создания таблицы TS создаст дополнительно четыре вспомогательных объекта:

объект типа «последовательность» («sequence»). Этот объект содержит в себе автогенерируемую последовательность целых чисел (следует отметить, что объекты данного типа могу содержать данные любых типов). Эта последовательность необходима для того, что реализовать автоинкремент суррогатного первичного ключа таблицы. Такой объект будет создан один, так как таблица содержит только один атрибут типа serial;

объекты типа «ограничение» («constraint»). Объекты данного типа необходимы для обеспечения целостности данных: они ограничивают ввод каких-либо данных в ячейку таблицы или позволяют определять первичные либо внешние ключи. В данном запросе будет создано три объекта-ограничения, первые два из которых — на атрибут ts_id. Ограничение «NOT NULL» запрещает все значения null в ячейке, ограничение «PRIMARY KEY» определяет столбец как первичный ключ. Последний объект запретит пользователю давать имена станций типа null.

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

Листинг 3.2 — Создание таблиц TS_METER и TS_MENSURATION

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

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

Секционирование (англ. partitioning) — разделение хранимых объектов баз данных (в нашем случае таблиц) на отдельные части с раздельными параметрами физического хранения. Метод секционирования выбран не только для повышения производительности, но и в целях повышения управляемости и доступности для базы данных.

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

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

Листинг 3.3 — Запрос на разбиение таблицы на архивную и актуальную части Актуальная таблица будет содержать измерения счетчиков шести подстанций за одни сутки (20•60•24•6 = 172 800).

Но если чтение из таблицы будет происходить автоматически, например, при запросе записи с rec_id = 182 321 (максимальный порядковый номер записи будет 200 000), то при записи данных потребуется написать функцию. Код функции показан на листинге 3.4

Необходимо, после создании функции, написать триггер, который будет запускать функцию FUNC_ACTUAL_REC_WRITER () на выполнение при срабатывании метода INSERT.

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

Так же для удобства работы пользователя с базой данных будут созданы представления (View) для таблицы TS_MENSURATION.

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

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

Листинг 3.6 — Создание представления для таблицы измерений По аналогии cозданы представления для остальных тяговых подстанций.

3.4 Описание программного комплекса

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

Первая программа под названием «MigrationCsvInDB» (далее Программа 1) полностью автоматизирует процесс миграции данных. От пользователя лишь необходимо указать адрес и логин/пароль от базы данных и местонахождение csv файлов. Программа является многопоточной, что существенно повышает ее скорость работы.

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

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

3.4.1 Алгоритмическое обеспечение программного комплекса

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

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

Графическая схема алгоритма приведена на рисунке 3.6.

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

Программа 2 работает на полноценном паттерне MVC, который был реализован на фреймворке SpringMVC. На рисунке 3.3 изображена функциональная диаграмма программы.

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

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

Рисунок 3.6 — ГСА алгоритма потока

Рисунок 3.7 — Функциональная схема программы «WebViewer»

Этот процесс во времени показан ниже на рисунке.3.8.

Рисунок 3.8 — UML диаграмма последовательности

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

Программный комплекс состоит из двух программ: «MigrationCsvInDB» и «WebViewer» .

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

надежность работы;

расширяемость;

простота в поддержке и сопровождении;

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

платформонезависимость.

Процесс создания данного программного комплекса основан на гибкой методологии Agile и следующих принципах:

принцип модульности. Программа 1 не должна зависить от выбора платформы, СУБД, ORM;

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

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

3.4.3 Описание программы «MigrationCsvInDB»

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

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

невозможен качественный анализ данных стандартными средствами;

низкая скорость доступа к данным;

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

не читаемость данных, требуется импорт файлов в табличные процессоры (например, MSExcel), либо в СУБД (например, MSAccess);

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

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

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

Программа «MigrationCsvInDB» (далее Программа 1) разрабатывалась для осуществления переноса данных о показаниях счетчиков тяговых подстанций из csv файлов в базу данных под управлением СУБД PostgreSQL.

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

Преимущество данной структуры состоит в том, что она поддерживает принципы, описанные в пункте 3.3.1.

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

Слой контроллера отвечает за основной функционал Программы 1. Другими словами классы на этом слое несут ответственность за управление процессом миграции.

Теперь рассмотрим структуру программы подробно.

Рисунок 3.9 — Функциональная схема программы «MigrationCsvInDB»

Рисунок 3.10 — Обобщенная диаграмма классов

В иерархии классов (рисунок 3.10) на самом нижнем уровне, слое DAO (dataaccessobject) расположились классы сущностей.

Классы сущностей наследуются от базового класса AbstractDataTS и представляют собой POJO классы описания таблиц в физической модели или сущностей в логической.

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

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

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

Аннотация @Column сообщает ORM фреймворку, что поля являются колонками таблицы, имя которой указано в свойстве name аннотации @Table. Это свойство также присутствует в аннотации @Column и содержит имя атрибута, который это поле олицетворяет.

@Entity @Table (name = «data_ts1») public class DataTS1 extends AbstractDataTS { @Id @Column (name = «rec_id») @SequenceGenerator (name = «data_ts1_seq»

sequenceName = «data_ts1_seq»

allocationSize = 1) @GeneratedValue (strategy = GenerationType. SEQUENCE

generator = «data_ts1_seq») @NotNull private Integer rec_id;

@Column (name = «time_mensuration») @NotNull private Date timeMensuration;

@Column (name = «date_mensuration») @NotNull private Date dateMensuration;

@Column (name = «meter_id») @NotNull private Integer meter_id;

@Column (name = «voltage») private Double voltage;

@Column (name = «the_current») private Double the_current;

@Column (name = «power») private Double power;

@Column (name = «given_energy»)

Листинг 3.7 — Модель данных, лист 1

privateDouble given_energy;

@Column (name = «accepted_energy») private Double accepted_energy;

public void setRec_id (Integer rec_id) {

this. rec_id = rec_id; }

publicInteger getRec_id () {return rec_id; }

}

Листинг 3.7, лист 2

Выше классов моделей в иерархии находится слой DAO (DataAccessObject). В программном обеспечении DataAccessObject (DAO) — это объект, который предоставляет абстрактный интерфейс к какому-либо типу базы данных или механизму хранения. Определенные возможности предоставляются независимо от того, какой механизм хранения используется и без необходимости специальным образом соответствовать этому механизму хранения. Традиционно этот шаблон связывают с приложениями на платформе JavaEnterpriseEdition, взаимодействующими с реляционными базами данных через интерфейс JDBC, потому что он появился в рекомендациях от фирмы SunMicrosystems.

Интерфейс DAO реализует класс DataDAOImpl, код которого представлен в листинге ниже:

importnet. eutkin. main. entity. AbstractDataTS;

import org. springframework. orm. hibernate3. support. HibernateDaoSupport;

public class DataDAOImpl extends HibernateDaoSupport implements IDataDAO { @Override public void save (AbstractDataTS obj) { getHibernateTemplate (). save (obj);

} }

Листинг 3.8 — Код класса, реализующего интерфейс DAO

Класс HibernateDaoSupport, который входит в состав фрейморка Spring, отвечает за доступ к базе данных. Этот класс позволяет получить сессию, необходимую, чтобы создавать SQL или HQL запросы программно. В данном классе метод save использует метод getHibernateTemplate () класса HibernateDaoSupport для доступа к шаблонным действиям, например, сохранению объекта (экземпляр модели) в базу данных. Класс HibernateDaoSupport существенно облегчает реализацию паттерна DAO, программное обеспечение становится более простым в поддержке и сопровождении.

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

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

@Service publicclassDataServiceImplimplementsIDataService { privateIDataDAOTestdataDAOTest;

publicvoidsetDataDAOTest (IDataDAOTestdataDAOTest) { this. dataDAOTest= dataDAOTest;

} @Override @Transactional publicvoidsave (AbstractDataTSobj) { if (obj! = null) dataDAOTest. save (obj);

} }

Листинг 3.9 — Реализация класса слоя сервиса

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

public interface IDataService { public void save (AbstractDataTS obj);

}

Листинг 3.10 — Интерфейс для доступа к классам сервиса

Далее, согласно иерархии, следует интерфейс Runnable, реализует который класс NewThread.

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

Алгоритм работы потока описан в разделе алгормитческого обеспечения. Следует отметить, что класс NewThread использует вспомогательный класс EntityFactory, который создает тот тип сущности, которая необходим в данным момент работы программы.

import javenue. csv. Csv;

import net. eutkin. main. entity. AbstractDataTS;

import net. eutkin. main. factory. EntityFactory;

import net. eutkin. main. service. IDataService;

import java. io. File;

import java. io. FileReader;

import java. io. IOException;

import java. text. SimpleDateFormat;

import java. util. *;

import java. util. regex. Pattern;

public class NewThread implements Runnable { private String path;

private IDataService dataServiceTest;

Листинг 3.11 — Реализация класса NewThread, поля и конструктор, лист 1

/** * Constructor * @param path * @param dataServiceTest */ public NewThread (String path, IDataService dataServiceTest) { this. path = path;

this. dataServiceTest = dataServiceTest;

}

Листинг 3.11, лист 2

Рассмотрим классы, которые импортируются подробнее.

Классы из пакета net. eutkin. main уже были разобраны выше, поэтому опустим их описание.

Классы из пакета java. io служат для обеспечения доступа программного обеспечения к файловой системе:

класс File позволяет получить информацию о файле: права доступа, время и дата создания, путь к каталогу. А также осуществлять навигацию по иерархиям подкаталогов. Класс File может представлять имя определенного файла, а также имена группы файлов, находящихся в каталоге. Если класс представляет каталог, то его метод list () возвращает массив строк с именами всех файлов:

класс FileReader наследуется от абстрактного класса Reader и предоставляет функциональность для чтения текстовых файлов;

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

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

Класс java. util. regex. Pattern служит для создания регулярных выражений. Регулярные выражения представляет собой конечные автоматы, на вход которых поступает текст, на выходе — результирующая строка. Внутри выражения во входном тексте ищется подстрока, шаблон которой находится в регулярном выражении. У данного конечного автомата есть два состояния: искомая подстрока найдена, или нет. Класс используется в методе для проверки валидности имени файла.

@Override /** * метод читает построчно csv файл и вставляет новую запись в базу данных */ publicvoidrun () {…}

/** * получает строку файла, разбивает ее на составляющие элементы * и заполняет поля экземпляр требуемой модели * @paramlistстрока файла * @paramfileтекущий csv файл

Листинг3.12 — РеализацияклассаNewThread, методы, лист 1

* @return модель */ private static AbstractDataTS fillFieldsDataMens (List list, File file) throws NumberFormatException{…}

/** * проверяетимяфайланавалидность * @paramfileтекущийcsvфайл * @returnистина, еслиимяфайлавалидна */ privateBooleanvalidateFileName (Filefile) {…} /** * получаетномертяговойподстанцииилиномерсчетчика * взависимостиотнаборавходныхпараметроа * @paramcurrentFileтекущийcsvфайл * @paramitIsTsNumberфлаг, подстанциялибономерсчетчика * @returnвозвращаетидентификаторподстанцииилисчетчика */ privatestaticIntegergetIdFromFileName (FilecurrentFile, BooleanitIsTsNumber) {…}

/** * получаетсписокфайловвдиректории * @parampathдиректориясcsvфайлами * @returnсписоксименамифайлов */ @Deprecated privateSetgetListFiles (Stringpath) throwsException {…}

/** * получаетпараметризконфигурационногофайла * @paramnamePropertyимяпараметра * @returnpropertyvalueзначениепараметра * @throwsIOException */ privateStringgetPropFromProperties (StringnameProperty) throwsIOException{…}

Листинг3.12, лист 2

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

На верхнем слое расположен класс Inserter. Этот класс открывает корневую директорию, в которой расположены поддиректории с csv файлами, создает поток и отправляет их на обработку путь поддиректории ему на обработку.

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

Листинг 3.13, лист 2

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

Path = J: \TS PatternNameFile = ts_\d+_\d+_\d+_\d+. csv

Листинг 3.14 — СодержимоефайлаProperty. properties

Первый параметр является путем к директории. Его значение представляет собой строку. Так как символ-разделитель директорий является служебным символом в Java, он экранируется. Второй параметр — шаблон проверки имени файла соответственно. Этот шаблон есть конечный автомат в виде регулярного выражения, описанный в синтаксисе языка Perl, который является стандартом описания выражений де факто в мире программирования.

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

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

jdbc. driverClassName= org. postgresql. Driver jdbc. dialect=org. hibernate. dialect. PostgreSQLDialect jdbc. url=jdbc: postgresql: // localhost: 5432/Data jdbc. username=postgres jdbc. password=admin

Листинг 3.15 — Файл настройки базы данных Для работы программы необходим конфигурационный файл, который настраивает фреймворк Spring, связывает объекты друг с другом и инициализирует фабрику для получения сессии подключения к базе данных.

Рассмотрим его составные компоненты.

В начале конфигурационного файла формата xml подключаются XML Schema. XML Schema — язык описания структуры XML-документа и содержит:

словарь (названия элементов и атрибутов);

модель содержания (отношения между элементами и атрибутами и их структура);

типы данных.

Листинг 3.16 — Подключение XML Schema

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

Листинг 3.17 — Подключение jdbc. properties

После того, как программе стал доступен конфигурационный файл, подключим класс dataSource. Реализацию данного класса возьмем стороннего производителя, компанию Apache, потому что его реализации однотипны и не зависят от особенностей системы. Класс отвечает за подключение к СУБД через драйвер, специфичный для каждой СУБД.

Листинг 3.18 — Подключение класса dataSource

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

Листинг 3.19 — Подключение класса sessionFactory

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

Листинг 3.20 — Подключение классов-реализаций В старых версиях этого фреймворка необходимо было для каждого класса иметь собственный файл конфигурации в формате. xml, но в новых версиях их заменили одним файлом и аннотациями JPA. Этому способстовало развитие JPA, так как Hibernate использует эту технологию для доступа к данным посредствам jdbc:

Листинг 3.21 — КонфигурационныйфайлHibernatehibernate. cfg. xml

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

3.4.4 Описание программы «WebViewer»

В современном информационном обществе очень важно не только хранить информацию, но и эффективно ее использовать.

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

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

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

Обе программы, входящие в состав комплекса спроектированы по принципу «программирование на интерфейсах». Рассмотрим иерархию классов программы подробнее, она представлена на рисунке 3.11.

Иерархия содержит четыре уровня, каждый из которых выполняет определенную задачу. Следует отметить, что данная иерархия классов полностью соответствуетSOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation и Dependency inversion) принципам.

Каждый класс имеет ограниченную ответственность и выполняет только одну задачу. Например, класс «DataDAOImpl» отвечает только за доступ к данным, а класс «DataServiceImpl» — за управлением транзакциями.

Каждый интерфейс программы имеет собственную специализацию.

Все классы закрыты для модификаций, так как все служебные методы и поля имеют уровень доступ «private» (частный), а открытые — уровень доступа «public» (публичный).

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

Рисунок 3.11 — UML диаграмма классов Программы 2

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

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

public class FiderGraphEntity { private Date time_line;

private Double current_fider;

private int meter_id;

private int numTS;

public Date getTime_line () { return time_line; }

public void setTime_line (Date time_line) { this. time_line = time_line;

} public Double getCurrent_fider () { return current_fider;

} public void setCurrent_fider (Double current_fider) { this. current_fider = current_fider;

}

Листинг3.22 — Класс FiderGraphEntity, лист 1

public int getMeter_id () { return meter_id;

} public void setMeter_id (int meter_id) { this. meter_id = meter_id;

} public int getNumTS () { return numTS;

} public void setNumTS (int numTS) { this. numTS = numTS;

} }

Листинг3.23, лист 2

Рассмотрим поля класса. Поле time_line представляет дату и время измерения. Учтем, что система построена на принципе реального времени, то измерения всех счетчиков единовремены. За обеспечение синхронизированности измерений отвечает СОЕВ (Система Обеспечения Единого Времени), которая была разобрана в разделе описания системы. Поэтому есть возможность сравнивать данные измерений, используя одну шкалу времени, то есть, для хранения даты-времени необходимо всего одно поле типа Date. Следует заметить тот факт, что в классе как тип поля использован стандартный класс Date из пакета java. util, вместо класса из пакета java. sql, который может хранить только дату.

Следующее поле с типом Double хранит значение тока на фидере, номер которого хранится в поле meter_id.

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

Так как все поля имеют уровень доступа private, то для применяются геттеры и сеттеры.

Класс отображает поля запроса вида SELECT … FROM. Так как подобная сущность в базе данных не хранится, то необходимость в аннотациях отсутствует.

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

Структура слоев DAO и сервиса аналогична структуре этих слов в Программе 1, однако, набор методов интерфейсов и классов, их реализующих, отличаются.

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

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

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

Рефлексия — это механизм исследования данных о программе во время ее выполнения. Рефлексия позволяет исследовать информацию о полях, методах и конструкторах классов, а также аннотациях. Можно также выполнять операции над полями и методами которые исследуются. Рефлексия в Java осуществляется с помощью JavaReflectionAPI. Этот интерфейс API состоит из классов пакетов java. lang и java. lang. reflect.

Рассмотрим, как с помощью этого API мы получим имя представления из аннотации:

String table1=ts1. getClass (). getAnnotation (Table. class). name ();

String table2=ts3. getClass (). getAnnotation (Table. class). name ();

Листинг 3.23 — Использование рефлексии для получения имени представления

Переменные table1иtable2 предназначены для хранения имен представлений, объекты ts1 и ts2 — модели, отображающие эти представления.

Получив имена представлений, сформируем текст SQL запроса.

Листинг 3.24 — ТекстSQLзапроса Это строковое значение помести в переменную queryтипа String.

Теперь воспользуемся объектом sessinFactory для получения сессии, чтобы полноценно работать с базой данных, например посылать запросы. Получив сессию с помощью метода getCurrentSession (), воспользуемся методом createSQLQuery (query), который позволяет отправить базе данных SQL запрос.

Драйвер JDBC позволяет использовает использовать два способа для добавления параметров в запрос: по имени параметра и по индексу. В данном случаем использован второй метод.

Листинг 3.25 — Получение коллекции с данными Далее при помощи стандартных средств драйвера jdbc передаем параметры запросы и посылаем его на выполнение. Результат запроса преобразовываем в коллекцию List.

Фреймворк Hubernate позволяет помимо SQL запросов создавать запросы на языке HQL (Hibernate Query Language). Преимущество это языка состоит в уменьшении объема кода, необходимо гораздо меньше операций для выполнения запроса.

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

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

в силу специфики запрос на HQL будет обработан фреймворком, преобразован в SQL запрос и только потом перенаправлен в СУБД через JDBC драйвер. SQL запрос отправляется сразу в JDBC драйвер;

язык имеет более широкие возможности, учитывается специфика СУБД.

В качестве другого примера SQL запроса рассмотрим метод класса-реализации DAO для получения баланса мощностей. Запрос суммирует значения мощностей одной подстанции за определенный период времени, а затем сохраняет полученные данные от СУБД в список, который хранит объекты класса «EntityJoin» .

Листинг3.26 — Метод showBalanceOfPower класса DataMensDAOImpl

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

public class EntityJoin { private Date date_mens;

private double power;

public Date getDate_mens () { return date_mens;

} public void setDate_mens (Date date_mens) { this. date_mens = date_mens;

} public double getPower () { return power;

} public void setPower (double power) { this. power = power;

} }

Листинг 3.27 — МодельEntityJoin

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

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

Класс в своем составе имеет три метода. Метод fiderGet отвечает за инициализацию JSP страницы. Например, загружает в форму введенные раннее пользователем данные.

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

@Controller publicclassFiderGraphController{ @Autowired privateIDataMensServicedataMensService;

/** * Формирует массив данных для передачи представлению * @param списокмоделей * @return */ private static StringBuilder createDataGraph (

List entities

) {…} /** * методреализуетприемзапросов Http POST * @param запрос * @param ответ * @return * @throws Exception */ @RequestMapping (value="/fider", method = RequestMethod. POST) public ModelAndView fiderPost (

HttpServletRequest request, HttpServletResponse response

) throws Exception {…}

/** * методреализуетприемзапросов Get * @param запрос * @param ответ * @return * @throws Exception */ @RequestMapping (value="/fider", method = RequestMethod. GET) public ModelAndView fiderGet (

HttpServletRequest request, HttpServletResponse response

) throws Exception {…}

Листинг 3.27 — Кодконтроллера Алгоритм работы контроллера рассмотрен в соответствующем разделе, который описывает алгоритмическое обеспечение.

В качестве представления используется набор JSP-страниц. JSP-страница представляет собой сервлет, который в результате вызова превращается в html-страницу.

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

Опишем прототип интерфейса.

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

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

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

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

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

4. Затраты на создание программного обеспечения

4.1 Расчет стоимости программного обеспечения

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

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

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

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

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

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

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

Модель оценки СОСОМО (COnstructiveCOstMOdel) — это алгоритмическая модель оценки стоимости разработки программного обеспечения, разработанная Барри Боэмом. Модель использует простую формулу регрессии с параметрами, определенными из данных, собранных по ряду проектов.

Основа COCOMO? модель, которая вычисляет стоимость разработки программного обеспечения в зависимости от оценок размера кода программы и комплекса «издержек», которые включают в себя субъективную оценку товара, оборудования, персонала и проектных характеристик.

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

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

В соответствии с таблицей 4.1 определяем поправочные коэффициенты.

Таблица 4.1 — Распределение сложности исполнения этапов разработки ПС

Код, написанный в ходе выполнения дипломного задания, не является уникальным, крайне похож на типовые примеры и изменен в соответствии с требованиями к интерфейсу, поэтому распределение трудозатрат будет определяться по первой строке таблицы. Коэффициенты: 70 для разработки, 20 для дополнительных требований и 10 для поддержки.

В результате компиляции программ получилось два. war файла (WebARchive). Для определения весовых коэффициентов воспользуемся таблицей 4.2.

Таблица 4.2 — Весовые коэффициенты сложности выводов

2 файла выводят 20 элементов (количество записей в базе не ограничено). Таким образом количество функциональных точек выводов Х₁ будет равно:

; (4.1)

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

Таблица 4.3 — Весовые коэффициенты сложности ввода

; (4.2)

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

Таблица 4.4 — Весовые коэффициенты сложности опросов вывода

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

Таблица 4.5 — Весовые коэффициенты опросов ввода

; (4.4)

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

Таблица 4.6 — Весовые коэффициенты сложности структуры данных

; (4.5)

В данном случае в качестве интерфейса может выступать один элемент, окно программы. Число элементов — от 6 до 10. Для определения коэффициентов воспользуемся таблицей 4.7.

Таблица 4.7 — Весовые коэффициенты сложности интерфейсов

; (4.6)

Общее количество функциональных точек системы:

X = X₁ + X₂ + X₃ + X₄ + X₅ + X₆; (4.7)

X = 63 + 98 + 36 + 12 + 21 + 7 =235

Далее рассмотрим поправки на факторы внешней среды, приведенные в таблице 4.8.

Таблица 4.8 — Факторы среды разработки

Таким образом, суммарное количество баллов:

N = 2+2+3+5+4+4+5+3+2+4+1+2 = 39.

Уровень их суммарного влияния:

Z = 0,65 + 0,39 = 1,04.

Уточненное количество функциональных точек:

R (F) = 235•1,1 = 244,4.

Код программы написан на языке программирования Java, показатель LOC на одну функциональную точку равен 53.

R (LOC) = 244,4•53 = 12 953,2.

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

Таблица 4.9 — Коэффициенты математической модели оценки трудозатрат

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

(4.8)

где Т — трудозатраты, выраженные в человеко-месяцах, Т = 0,56;

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

A — показатель, отражающий линейную зависимость роста трудозатрат от размерности;

Е - показатель показывающий, что при увеличении размерности ПО возрастает относительная трудоемкость.

По полученным данным определим денежные затраты на разработку ПС. Для примера будем считать месячный оклад программиста равным 15 000 рублей.

(4.9) ,

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

— тарифная ставка разработчик программного продукта, руб,;

— время разработки, месяцы.

Дополнительная заработная плата исполнителей составляет 12% от их основной заработной платы:

(4.10)

Районный коэффициент составляет 15% от основной и дополнительной заработной платы исполнителей, т. е.:

(4.11)

руб Отчисления на социальные нужды составляют 30,2% от всех выплат по заработной плате:

(4.12)

Размер ставки накладных расходов примем равным 120%

; (4.13)

Рассчитаем НДС:

руб Итого: общая стоимость разработки ПО составила 8400 + 2535,55 = 10 935,55 рубля.

5. Технические способы и средства защиты от электрического тока

5.1 Условия, с учетом которых устанавливаются технические способы и средства защиты от электрического тока

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

Электробезопасность должна обеспечиваться:

конструкцией электроустановок;

техническими способами и средствами защиты;

организационными и техническими мероприятиями.

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

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

номинального напряжения 220 В, рода и частоты 50 Гц тока электроустановки;

способа электроснабжения (стационарная сеть);

режима нейтрали источника питания (заземленная);

вида исполнения (стационарные);

условий внешней среды:

1) особо опасные помещения;

2) помещения повышенной опасности;

3) помещения без повышенной опасности (температура 20 °C, влажность 50%, выделения газов и пара отсутствует);

4) на открытом воздухе;

возможности приближения человека к токоведущим частям (отсутствует);

характера возможного прикосновения человека к элементам цепи тока:

1) однофазное (однополюсное) прикосновение;

2) двухфазное (двухполюсное) прикосновение;

3) прикосновение к металлическим нетоковедущим частям, оказавшимся под напряжением;

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

вид работ (эксплуатация).

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

Основными мерами защиты от поражения электрическим током являются:

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

электрическое разделение сети;

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

применение малых напряжений;

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

контроль и профилактика повреждений изоляции;

компенсация емкостной составляющей тока замыкания на землю;

применение специальных электрозащитных средств — переносных приборов и предохранительных устройств;

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

5.2 Обоснование и конструкция принятых технических средств

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

защитное заземление;

защитное зануление;

выравнивание (в т. ч. уравнивание) потенциалов;

малое напряжение;

электрическое разделение сетей;

защитное отключение;

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

компенсация токов замыкания на землю;

предупредительная сигнализация, защитная блокировка, знаки безопасности;

средства защиты и предохранительные приспособления.

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

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

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

Рисунок 5.1 — Схема включения человека в цепь замыкания на землю при прикосновении к корпусу электроустановки

Если человек коснется корпуса, на который произошло короткое замыкание одной из фаз, образуется электрическая цепь от поврежденной фазы и корпуса на землю и далее к другим фазам через сопротивления изоляции неповрежденных проводов (на рисунке показано условно выбранное направление переменного тока). При наличии защитного заземления ток замыкания проходит по двум параллельно включенным сопротивлениям: сопротивлению заземляющего устройства R и сопротивление человека R_ч. Токи в параллельных цепях распределяются обратно пропорционально электрическим сопротивлениям, поэтому при наличии малого электрического сопротивления заземляющего устройства (не выше 10 Ом) по сравнению с электрическим сопротивлением человеческого тела (сопротивление тела человека зависит от многих факторов, в качестве расчетного значения принимается величинаR_ч=1000 Ом) часть тока, проходящая через тело человека, будет мала и безопасна для его здоровья. Отсюда для обеспечения безопасности пригодно не всякое соединение с «землей», а только соединение, имеющее достаточно малое электрическое сопротивление.

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

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

при напряжении 380 В и выше переменного тока, 440 В и выше постоянного тока — во всех электроустановках;

при напряжении выше 42 В, но ниже 380 В переменного тока и от 110 В до 440 В постоянного тока в помещениях с повышенной опасностью, особо опасных и в наружных установках;

во взрывоопасных помещениях при всех напряжениях.

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

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

водопроводные трубы, проложенные в земле;

металлические конструкции зданий и сооружений, имеющие надежное соединение с землей;

металлические оболочки кабелей (кроме алюминиевых);

обсадные трубы артезианских скважин.

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

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

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

стальные трубы с толщиной стенок 3.5 мм, длиной 2 — 3 м;

полосовую сталь толщиной не менее 4 мм;

угловую сталь толщиной не менее 4 мм;

прутковую сталь диаметром не менее 10 мм, длиной до 10 м и более.

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

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

Наибольшее распространение зануление получило в трехфазных электрических сетях в виде трехфазных четырехпроводных электрических сетей с глухозаземленной нейтралью и напряжением 660/ 380, 380/220 и 220/127 В (в числителе — линейное напряжение, в знаменателе — фазное).

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

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

В качественулевых защитных проводников (РЕ-проводники) в электроустановках до 1000 В могут использоваться:

специально предусмотренные для этой цели проводники:

1) жилы многожильных кабелей;

2) изолированные или неизолированные провода в общей оболочке с фазными проводами;

3) стационарно проложенные изолированные или неизолированные проводники;

открытые проводящие части электроустановок:

1) алюминиевые оболочки кабелей;

2) стальные трубы электропроводок;

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

некоторые сторонние проводящие части:

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

2) арматура железобетонных строительных конструкций зданий при условии выполнения требований ПУЭ о непрерывности электрической цепи;

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

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

а

Рисунок 5.2 — Схема зануления электроустановок: а — схема и потенциальная диаграмма напряжений короткозамкнутой цепи, б — то же, с повторным заземлителем сR_m-R_Oiпри обрыве нулевого провода, лист 1

б

Рисунок 5.2, лист 2

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

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

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

Устройство защитного отключения — механический коммутационный аппарат или совокупность элементов, которые при достижении (превышении) дифференциальным током заданного значения при определенных условиях эксплуатации должны вызвать размыкание контактов. Может состоять из различных отдельных элементов, предназначенных для обнаружения, измерения (сравнения с заданной величиной) дифференциального тока и замыкания иразмыканияэлектрической цепи (разъединителя). [11]

Основная задача УЗО — защитачеловекаот поражения электрическим током и от возникновенияпожара, вызванного утечкой тока через изношенную изоляцию проводов и некачественные соединения.

С точки зрения электробезопасности УЗО принципиально отличаются от устройств защиты от сверхтока (предохранителей) тем, что УЗО предназначены именно для защиты от поражения электрическим током, поскольку они срабатывают при утечках тока значительно меньших, чем предохранители (обычно от 2 ампер и более для бытовых предохранителей, что во много раз превышает смертельное для человека значение). УЗО должны срабатывать за время не более 25−40 мс, то есть до того, как электрический ток, проходящий через организм человека, вызовет фибрилляцию сердца — наиболее частую причину смерти при поражениях электрическим током. [9]

5.3 Расчет защитного заземления

Основным параметром, характеризующим защитное заземляющее устройство, является сопротивление растеканию тока, которое в основном зависит от сопротивления земли. [10]

Данные:

U>1000 В, R_н=2,5 Ом, l=2,5 м, 3, d=40 мм, климатическая зона? 2, грунт — суглинок, расположение заземления — по контуру.

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

Определяется расчетное значение удельного сопротивления грунта с_расч, Ом•м, в месте устройства заземления с учетом повышающего коэффициента К:

(5.1)

Ом•м,

Где с_изм? удельное сопротивление грунта, полученное непосредственным измерением или принятое по приложению, Ом•м;

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

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

(5.2)

Ом,

Где l? длина вертикального электрода? заземлителя, м, d? диаметр заземлителя, м. При использовании в качестве электродов угловой стали ее эквивалентный диаметр d_yr= 0,95 В_уг, где В_уг — ширина полки уголка, м;

t? глубина заложения заземлителя, равная расстоянию от поверхности земли до середины заземлителя, м;

(5.3)

м.

t_n = 0,7? 0,8 м? глубина заложения полосы.

Полученное значение R₀ сравнивается с наибольшим доступным R_H: при R₀ ? R_h, что случается крайне редко, принимают заземлитель из двух электродов и расчет заканчивают; при R₀>R_h определяет число вертикальных заземлителей.

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

(5.4)

Затем уточняют количество заземлителей с учетом коэффициента использования (экранирования):

(5.5)

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

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

Значения коэффициента использования вертикальных заземлителей з_з приведены в приложении. Они зависят от схемы их расположения (в ряд или по контуру), отношения расстояния между отдельными заземлителями б к их длине l и приблизительного числа заземлителей N_np. Расстояние между заземлителями, расположенными в ряд, чаще всего принимают равным (1?2) l, а при расположении по контуру это расстояние, как правило, увеличивается до 3l. Значенияз_з находим методом интерполяции. Определяется длина соединительной полосы (горизонтального направления) L_п в зависимости от ранее принятого отношения б: при расположении в ряд

(5.6)

при расположении по контуру

(5.7)

м.

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

(5.8)

где? расчетное удельное сопротивление грунта, Ом-м, с учетом коэффициента сезонности К_п для горизонтального заземлителя

(5.9)

Ом•м,

Где В_п? ширина соединительной полосы, м (В_п = В_уг; при использовании в качестве горизонтального заземлителя стали круглого сечения В = 2d);

t_n? (0,7−0,8) м? глубина заложения полосы в грунт.

Определяется сопротивление растеканию тока с учетом коэффициента использования:

(5.10)

Ом,

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

Определяется результирующее сопротивление растеканию группового искусственного заземлителя как двух параллельных сопротивлений (электродов-заземлителей и соединительной полосы):

(5.11)

Ом,

Где

(5.12)

где сопротивление растеканию вертикальных заземлений при итоговых значениях N_yт и N_np, Ом;

Ом,

N_ут? число вертикальных заземлителей, окончательно принятых в расчете;

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

Так как R'_з? R_н, то количество заземлителей для обеспечения требований безопасности рассчитано, верно.

Заключение

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

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

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

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

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

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

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

Библиографический список

1. Язык программирования Java [Электронный ресурс] - Электрон. текстовые дан. — https: // ru. wikipedia.org/wiki/Java

2. Язык программирования Java [Электронный ресурс] - Электрон. текстовые дан. — https: // ru. wikipedia.org/wiki/JavaScript

3.

Введение

в представления PostgreSQL [Электронный ресурс] - Электрон. текстовые дан. — http://postgresql.ru.net/gruber/ch20.html

4. ОбъектDAO [Электронный ресурс] - Электрон. текстовые дан. — http://www.oracle.com/technetwork/java/dataaccessobject-138 824.html

5. Инструкция по работе с CSV файлами [Электронный ресурс] - Электрон. текстовые дан. — http://www.javenue. info/post/78

6. СТП ОмГУПС-1.2−05. Работы студенческие учебные и выпускные квалификационные: общие требования и правила оформления текстовых документов.

7. «Расчет затрат на создание программных средств: методические указания к выполнению экономического раздела дипломного проекта» / А. Н. Шендалев. Омск: Омский гос. ун-т путей сообщения, 2012.31 с.

8. Кларенс Хо, Роб Харроп. Spring 3 для профессионалов. — М.: «Вильямс», 2012. — 880 с. — ISBN 978−5-8459−1803−1.

9. ГОСТ Р 50 807−95. Устройства защитные, управляемые дифференциальным (остаточным) током. Общие требования и методы испытаний (МЭК 755−83). М., 2003.18 с.

10. Испытание эффективности и расчет защитного заземления: Методические указания к дипломному проектированию, практическим и лабораторным работам по охране труда / В. Ф. Харламов, Б. П. Баталов, Л. Я. Уфимцева. Омский ин-т инж. ж. ?д. транспорта, 1993.42 с.

11. Учебно-методический комплекс по дисциплине «Безопасность жизнедеятельности». [Электронный ресурс] Электрон. текстовые дан. — lib. znate.ru 2012. Режим доступа: http://lib. znate.ru/docs/index-202 682.html? page=20