Проектирование и реализация приема и передачи телемеханической информации в энергетике на примере протокола РПТ-ЭВМ

Международный Университет природы, общества и человека «Дубна»

Кафедра Системного анализа и управления

Курсовая работа

по теории и технологии проектирования

Тема: "Проектирование и реализация приема и передачи телемеханической информации в энергетике на примере протокола РПТ-ЭВМ"

                                                                                                     Выполнил:

                                                                                                            Группа ПС-31

                                                                                                             Руководитель:

Содержание

Содержание             

1. Постановка задачи             

2. Глоссарий проекта             

3. Дополнительные спецификации             

4. Проектирование             

4.1. Создание модели вариантов использования             

4.2. Анализ системы             

5. Реализация             

6. Список литературы             

1. Постановка задачи

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

В рамках данного проекта будет рассмотрена реализация приема и передачи телемеханической информации в рамках протокола ЦППС-ЭВМ. Протокол имеет 2 режима работы ЦППС-ЭВМ и ЭВМ-ЦППС.

Рассматриваемый протокол осуществляет связь между РЭС и ПЭС, ПЭС и подстанциями, подстанциями и некоторыми устройствами телемеханики (адаптер «СИСТЕЛ»). Протокол получает информацию через соm-порт, usb-порт компьютера, либо со специализированного адаптера. Прокол оперирует байтовым потоком. Во входном потоке выделяются кадры (фреймы) телемеханической информации (ТМИ), кадры цифробуквенной информации (ЦБИ), кадры состояния каналов телемеханики, а также служебные кадры.

Общий макет кадра выглядит следующим образом (рис. 1):

где КБ – байт начала кадра (байт «80»)

ДЛ – байт длины кадра

ИД – идентификатор режима работы протокола (ЦППС-ЭВМ),  при другом режиме работы данный байт просто отсутствует.

ИДТ – байт определяющий тип передаваемой информации

ИНФ – байты содержащие передаваемую информацию

КС – байт контрольной суммы

Если на обработку поступает цифробуквенная информация (ЦБИ), то все информационные байты, после проверки контрольной суммы передаются в соответствующий канал.

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

2. Глоссарий проекта

3. Дополнительные спецификации

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

Данный тип информации передается блоками из трех байт (рис. 2):

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

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

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

Телесигнализация (ТС) – измерение состояния дискретных величин, датчиков и т.п.

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

4. Проектирование

4.1. Создание модели вариантов использования

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

Действующие лица:

       Any User (Пользователь) – производит контроль за работой системы, отслеживает неполадки.

       Data Bases (базы данных) - *.dbf файлы, в которые занесены конфигурации протоколов, допустимые адреса телемеханики, конфигурации каналов.

       ProtMon/Zemon – программная часть приемно-передающего комплекса, в которую встраиваются протоколы.

       Any Protocol –

       Any device – какое–либо устройство телемеханики, либо порт компьютера, через которые передается информация.

       Flow (поток) –

       Any channel – канал связи, по которому в протокол поступает информация

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

       Web arm – встроенная система отображения получаемой и передаваемой информации

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

       Login (Войти в систему отображения).

       Run ProtMon/Zemon (Запустить ProtMon/Zemon).

       Load config (загрузить конфигурацию).

       Load channels (загрузить каналы).

       Form flow (Сформировать поток).

       Load flow (Загрузить поток в канал).

       Run Protocol with config (Загрузить протокол с его конфигурацией).

       Send flow to Protocol (Послать поток в протокол).

       Create RTDB (Создать базу данных реального времени).

       Load available TMI addresses to RTDB (Загрузить допустимые адреса телемеханической информации в протокол при запуске программного приложения).

       Send available TMI in Protocol (По запросу протокола произвести загрузку всех допустимых адресов телемеханической информации).

       Analize flow (Разбор потока, выделение в нем кадров).

       Pass date (Передача данных на встроенную систему просмотра и в БДРВ).

       Show information (Визуальное отображение информации).

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

Краткое описание:

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

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

4.2. Анализ системы

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

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

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

Причем классы (flow, available tmi addresses, config) – являются граничными классами, т.е. служат посредниками при взаимодействии внешних объектов с системой.

Класс (Protocol) – является управляющим классом, т.е. обеспечивает координацию поведения объектов в системе.

Классы (Increment frame finder, tmi register, information analyzer, control summ check, universal cleaner) – являются классами-сущностями, т.е. представляют собой ключевые абстракции разрабатываемой системы.

В результате имеем достаточно общую диаграмму классов (рис. 5):

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

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

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