Разработка приложения для проверки состояния качества электроэнергии на городских объектах

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

1) Невозможность получения данных с прибора Satec PM175 удаленно, что снижает время обработки данных в лаборатории. Решение данной проблемы позволит получать данные от прибора по сети Internet. Данная технология предоставит возможность приобщить студентов к реальному использованию прибора, установленного на реальном объекте, и анализировать реальную картину качества электрической энергии на крупных объектах города Красноярск. Это позволит повысить интерес студентов к дисциплине «Основы электротехники» и «Основы электроэнергетики».

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

В ходе проектирования системы, преследуются следующие цели:

— изучение спецификации по эксплуатации анализатора качества электроэнергии (далее — КЭ) Satec PM175;

— изучение и тестирование протокола Modbus RTU;

— освоение среды графического программирования LabVIEW;

— получение навыков документирования требований по методологии Rational Unified Process — создание документа «Видение» и документа «Спецификация требований»;

— Создания серверного приложения в среде разработки программного обеспечения LabVIEW для взаимодействия автоматизированного рабочего места (далее — АРМ) и анализатора КЭ Satec PM175;

— Создание клиентского приложения в среде разработки программного обеспечения LabVIEW для удаленного анализа КЭ на различных объектах города Красноярск;

— Внедрение системы сбора данных с анализатора КЭ Satec PM175 в учебный процесс кафедры СААУП СФУ ИКИТ.

анализатор электроэнергия программный приложение

1. Создание документа «Видение»

1.1 Задачи

Важной задачей внедрения системы сбора показаний (далее — ССП) является создание специализированных АРМ и сервера. На данных АРМ представится возможность получать показания с сервера, хранить и обрабатывать показания.

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

В ходе решения данной задачи возникает ряд проблем, рассмотрим их подробнее в таблице 1,2

Таблица 1 — Решаемая проблема 1

Таблица 2 — Решаемая проблема 2

1.2 Определение позиции изделия

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

ССП с анализатора качества электроэнергии РМ175 основан на протоколах TCP/IP и ModBus, и разработан в среде разработки программного обеспечения Labview.

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

1.3 Сведения о пользователях

У ССП существует один пользователь, который выдает запросы серверу на снятия показаний и пересылку на АРМ, представляет показания в виде графиков.

1.4 Пользовательская среда

Система будет работать на платформе IBM PC.

Минимальные системные требования:

— Processor Pentium 4;

- RAM 1GB;

- HDD 500 Mb;

- Операционная система Windows Vista, Windows 7.

1.5 Краткий обзор изделия

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

В таблице 3 представлена сводка возможностей АРМ оператора ССП.

Таблица 3 — АРМ оператора ССП

1.5.1 Ограничения

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

- ПО разработано в среде Labview.

1.6 Показатели качества

1.6.1 Применимость

— Время необходимое для обучения пользователей — 1 рабочий день (8 часов);

- Время отклика на запрос — не более 10 секунд.

1.6.2 Надежность

Среднее время безотказной работы — 6 рабочих дней.

1.7 Другие требования к изделию

1.7.1 Применяемы стандарты

Система должна соответствовать всем стандартам интерфейса пользователя Microsoft Windows.

1.7.2 Эксплуатационные требования

Система должно поддерживать минимум 20 одновременно работающих пользователей. Максимальное количество одновременно работающих пользователей равно 50.

1.8 Требования к документации

1.8.1 Руководство пользователя

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

1.8.2 Интерактивная справка

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

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

Справка должна содержать максимально полную и подробную информацию по работе системы.

1.8.3 Руководство по установке и конфигурированию

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

1.9 Маркировка и пакетирование

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

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

2. Поиск актеров и вариантов использования

2.1 Поиск актеров

Интервью, проведенное с сотрудниками кафедры СААУП показло, что студенты, преподаватели и аспиранты предполагают использовать разрабатываемое ПО однотипно. Это позволило обобщить роли в одну (см. рисунок 1)

Оператор ССП — сотрудник или учащийся кафедры СААУП, использующий ССП с анализатора качества электроэнергии РМ175 для проведения анализа и исследований качества электроэнергии на крупных объектах города Красноярск.

Рисунок 1 — Анализ актеров системы

2.2 Выявление вариантов использования

Существует 5 вариантов использования данной программы:

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

— Измерение силы тока;

— Измерение напряжения;

— Измерение мощности;

— Визуализация данных.

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

Таблица 4 — Варианты использования

2.3 Разработка диаграмм вариантов использования

Диаграмма вариантов использования в UML — диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне.

Основное назначение диаграммы — описание функциональности и поведения, позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать проектируемую или существующую систему. [1]

Все варианты использования показаны на рисунке 2.

Рисунок 2 — Диаграмма вариантов использования

3. Краткое описание вариантов использования

3.1 Структуризация вариантов использования

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

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

Рисунок 3 — Обобщение вариантов использования Результирующая диаграмма вариантов использования приведена на рисунке 4.

Рисунок 4 — Модифицированная диаграмма прецедентов системы

3.2 Реестр вариантов использования

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

Таблица 5 — Варианты использования

3.3 Конкретизация вариантов использования

3.3.1 О1. Отправка запроса

Этот вариант использования позволяет оператору ССП отправить запрос на сервер для получения данных с анализатора качества электроэнергии PM175.

Основное действующее лицо: Оператор ССП.

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

3.3.2 О2. Получение измерений

Этот вариант использования позволяет оператору ССП получать данные с объекта исследования в реальном времени.

Основное действующее лицо: Оператор ССП.

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

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

3.3.3 О3. Визуализация данных

Этот вариант использования позволяет оператору ССП приставлять показания с анализатора качества электроэнергии РМ175 в виде графиков.

Основное действующее лицо: Оператор ССП.

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

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

4. Описание ключевых прецедентов

4.1 Поиск ключевых вариантов использования

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

Для дальнейшей детализации выбраны три прецедента:

— О1: Отправка запроса;

— О2: Получение измерений;

— О3: Визуализация данных.

4.2 Прецедент О1: Отправка запроса

Оператор ССП отправляет запрос на снятие данных с прибора РМ175.

Действующее лицо этого прецедента — Оператор ССП.

4.2.1 Базовый поток

Прецедент начинается, когда Оператор ССП запускает программу-клиент.

1) Оператор ССП запускает программу-клиент;

2) Оператор ССП вводит IP-адрес компьютера-сервера в окно «IP-адрес»;

3) Оператор ССП выбирает характеристики, которые он хочет получить от прибора;

4) Оператор ССП нажимает кнопку «Запрос».

4.2.2 Альтернативный поток

Если при выполнении пункте 4.1.1.1 программа-клиент выдала ошибку соединения с сервером, то необходимо выполнить следующие действия:

1) Проверить правильность введенного IP-адреса;

2) Перейти к выполнению п. 1 основного потока событий.

4.2.3 Специальные требования

Время ответа сервера не должно превышать 1 минуты.

4.2.4 Предусловия

Перед тем, как начать работать с данным прецедентом, Оператор ССП должен убедиться в том, что компьютер-клиент подключен к сети Интернет.

4.2.5 Постусловия

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

4.2.6 Точки расширения

Если при выполнении пункта 1 основного потока событий, выясняется, что в программе-клиенте уже записан необходимый IP-адрес и выбраны необходимые на данный момент характеристики, то Оператор ССП может непосредственно приступить к выполнению пункта 4 основного потока событий (см. рисунок 5).

Рисунок 5 — Отправка запроса

4.3 Прецедент О2: Получение измерений

Оператор ССП сохраняет данные, полученные от сервера. Действующие лица этого прецедента — Оператор ССП.

4.3.1 Базовый поток событий

Прецедент начинается, когда Оператор ССП выполнит прецедент «Отправка запроса».

Оператор ССП выполняет прецедент «Отправка запроса»;

Нажать кнопку «Сохранить».

4.3.2 Альтернативные потоки

Если при выполнении п. 2 основного потока событий программа-клиент выдала ошибку «Недостаточно свободного места на диске», то необходимо выполнить следующие действия:

1) Освободить необходимое место на жестком диске компьютера.

4.3.3 Специальные требования

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

4.3.4 Предусловия

Перед тем, как начать работы с данным прецедентом Оператор ССП должен выполнить прецедент «Отправка запроса». Так же на компьютере-клиенте должно быть установлено специализированное ПО — MicroSoft Exele, необходимое для открытия файла с полученными данными.

4.3.5 Постусловия

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

4.3.6 Точки расширения

На рисунке 6 показана схема потока событий прецедента О2: Получение измерений.

Рисунок 6 — Получение измерений

4.4 Прецедент О3: Визуализация данных Оператор ССП визуализирует данные полученные от сервера.

Действующие лица этого прецедента — Оператор ССП.

4.4.1 Базовый поток событий

Прецедент начинается, когда Оператор ССП выполняет прецедент «Отправка запроса».

Оператор ССП выполняет прецедент «Отправка запроса»;

Оператор ССП нажимает кнопку «Построить график».

4.4.2 Альтернативные потоки

Если при выполнении пункта 2 основного потока событий программа-клиент выдала ошибку «Недостаточно данных», то необходимо выполнить следующие действия:

1) Перейти к выполнению п. 1 основного потока событий.

2) Выбрать только 2 характеристики, которые будут отображать зависимость на графике.

4.4.3 Предусловия

Перед тем, как начать работы с данным прецедентом Оператор ССП должен выполнить прецедент «Отправка запроса».

4.4.4 Постусловия

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

4.4.5 Точки расширения

На рисунке 7 показана схема потока события для прецедента О3: Визуализация данных

Рисунок 7 — Визуализация данных

5. Классы

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

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

В нашей системе мы реализуем такие классы:

— VISA — предоставляет возможность для открытия COM-порта для передачи данных;

— ModBus — класс предоставляющий работу по протоколу ModBus RTU для сопряжения АРМ и прибора;

— Array — массив данных имеющий такие атрибуты как: size, index, new element;

— TCP — класс предоставляющий работу по протоколу TCP IP для передачи массива данных по среде Internet;

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

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

На рисунке 8 представлена диаграмма классов Рисунок 8 — Диаграмма классов

6. Моделирование взаимодействия

Диаграммы взаимодействия (interaction diagram) являются моделями, описывающими поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой в рамках данного варианта использованиях[2]. В языке UML есть две диаграммы взаимодействия:

— Диаграмма последовательности (рисунок 9);

— Диаграмма кооперации (рисунок 10).

Диаграммы последовательности (sequence diagrams) предназначены для представления динамики поведения объектов, отображая передачу сообщений между соответствующими классами.

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

Рисунок 9 — Диаграмма последовательности Рисунок 10 — Диаграмма кооперации

7. Моделирование конечных автоматов

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

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

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

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

На рисунке 11 изображена диаграмма состояний класса FileIO. После получения запроса (состояние Get Request) система начинает снятие показаний с прибора PM175. Во время снятия показаний система делает измерения качества электроэнергии сети. Для дальнейшего действия принятия решения служит аргумент `View', не нулевое значение которого указывает, что необходима дальнейшая отправка полученных данных в PolarPlot.

Рисунок 11 — Диаграмма состояний для FileIO

На рисунке 12 представлена диаграмма состояний для класса Modbus. После создания запроса на получение доступа (состояние Allow Request) следует стадия получение доступа. На этом этапе система должна получить разрешение на доступ (Access==1), только после этого она имеет право отправить запрос. В случает отказа в доступе (Access==0), система возвращается на предыдущий этап для проверки посланных данных.

Рисунок 12 — Диаграмма состояний Modbus

8. Физические диаграммы

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

— диаграммы компонентов;

— диаграммы развертывания.

Диаграмма компонентов (Component diagram) — диаграмма, которая отображает компоненты системы и связи между ними. Компонент представляет собой законченный элемент, который реализует определенный набор интерфейсов. Главным преимуществом компонента является его повторное использование в других системах. Диаграмма развертывания отображает способ взаимодействия компонентов с аппаратными средствами в физической системе, а также соединение аппаратных средств между собой. Основным элементом системы является узел. Узел — представление любого вычислительного ресурса. На рисунке 13 представлена физическая диаграмма, отображающая в себе диаграмму компонентов и диаграмму развертывания.

Рисунок 13 — Физическая диаграмма

Заключение

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

Рисунок 14 — Интерфейс сервера Интерфейс клиента представлен на рисунке 15, он интуитивно понятен и прост в освоении. После запуска клиентской части, появляется окно с пустыми полями «IP-адрес сервера» и «№ порта», которые клиенту необходимо заполнить.

Рисунок 15 — Интерфейс клиента

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

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

Система сбора данных должна визуализировать данные в виде трех диаграмм. Это гистограмма гармоник сети (рисунок 17), векторная диаграмма токов и напряжений (рисунок 16), а также диаграмма амплитудно-частотная характеристика (далее — АЧХ) (рисунок 16). Каждая диаграмма несет определенную смысловую нагрузку для пользователя и отображает разные данные, поэтому необходимо именно такое количество диаграмм.

Гистограмма гармоник отображает величины гармоник сети, по оси х должна быть шкала нумерации гармоник от 1−50, а по оси у — величина гармоник от 0−100.

Векторная диаграмма токов и напряжений показывает угловой сдвиг токов относительно напряжений по каждой фазе и их величину. Изображаются эти вектора в окружности с градусными рисками от 0 до 360, каждый вектор должен быть отличного цвета от других векторов. При построении диаграммы используются угловые сдвиги и величины данных характеристик. АЧХ отображает зависимость изменения значений амплитуды и частоты во времени. С анализатора КЭ возможно получить всю таблицу данных, а для построения АЧХ необходимо только визуализировать диаграмму. Каждую характеристику необходимо отобразить в своем окне что возможно сделать путем использования Mixed Waveform Plot.

Рисунок 16 — Слева — АЧХ, справа — векторная диаграмма Рисунок 17 — Гистограмма гармоник

Список использованных источников

1 Википедия. Свободная энциклопедия: электрон. статья Диаграмма прецедентов. URL: http://ru.wikipedia.org (дата обращения 27.03.2013)

2 Леоненков, А. В. Самоучитель UML / А. В. Леоненков .— 2-е изд., перераб. и доп.— СПб: БХВ-Петербург, 2004

3 Леоненков, А. В. Самоучитель UML / А. В. Леоненков .— 2-е изд., перераб. и доп.— СПб: БХВ-Петербург, 2004

4 Прибор для измерений показателей качества и учета электрической энергии PM175 -Руководство по установке и эксплуатации BG0440 Rev. A6.

5 LabVIEW: стиль программирования. Пер. с англ. под ред. Михеева П.- М.: ДМК Пресс, 2008 — 400 с.: ил.

6 Modbus: электрон. статья Оригинальная спецификация протокола Modbus. URL: http://www.modbus.org (дата обращения 15.10.2012).

7 Компьютерные сети. 4-е изд. / Э. Таненбаум. — СПб.: Питер, 2011. — 992 с.: ил.

8 Применение UML 2.0 и шаблонов проектирования.

Введение

в объектно-ориентированный анализ, проектирование и итеративную разработку. / Крэг Ларман.: Вильямс, 2013. — 736с.: ил.