Анализ средств и методов разработки программного обеспечения АРМ диспетчера

DOI:

Решение задач управления в современных системах автоматизации (АСУ) предусматривает интенсивный обмен информацией между всеми участниками системы. Этот обмен осуществляется как между людьми (диспетчерами, операторами и т.п.), так и между людьми и управляющими ЭВМ. Как правило, возможны два вида обмена информацией – документированный и недокументированный. При проектировании диалога «диспетчер – ЭВМ» высока степень формализации обмена информацией. Перспективным является создание реальной возможности ведения свободного диалога на естественном языке. Сегодня диспетчер в многоуровневой АСУ технологическими процессами и производствами получает информацию с монитора компьютера или с другой электронной системы отображения информации. Он имеет возможность воздействовать на объекты, находящиеся от него на значительном расстоянии, с помощью телекоммуникационных систем, контроллеров, интеллектуальных исполнительных механизмов [1-3]. Поскольку управление осуществляется удаленно, угроза жизни и здоровью персонала существенно снижается.

В работе [4] представлена цифровая микропроцессорная система телемеханики АМТ, предназначенная для управления объектами системы электроснабжения железнодорожного транспорта, расположенными на тяговых подстанциях, постах секционирования, пунктов параллельного соединения и с возможностью передачи информации диагностики устройств электроснабжения. Авторами в работе [5] рассматривается один из способов повышения надежности и экономичности распределения электрической энергии и мощности за счет обеспечения максимально эффективной оперативно-технологической деятельности распределительных сетевых компаний путем комплексной автоматизации процессов сбора, обработки, передачи информации и принятия решений о выполнении основных функций оперативнотехнологического управления.

Анализ современных разработок в области разработки систем диспетчерского управления в различных АСУ технологическими процессами и производствами позволяет сделать вывод о важности программно-аппаратной поддержки обмена информацией [6]. Назначение программного обеспечения (ПО) автоматизированного рабочего места (АРМ) диспетчера в рамках системы – это предоставление наглядного и простого для конечного пользователя графического интерфейса к техническим средствам АСУ [7].

К составу ПО АРМ диспетчера предъявляются следующие требования:

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

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

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

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

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

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

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

МАТЕРИАЛЫ И МЕТОДЫ

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

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

Технические средства диспетчерского пункта представлены персональным компьютером (ПК), интеллектуальным терминальным контроллером (ИТК) и УКВ трансивером.

Связь диспетчерского пункта с удаленными тяговыми подстанциями (ТП) осуществляется по радиоканалу. Управление радиосетью осуществляет ИТК диспетчерского пункта. ИТК подключается к ПК через коммуникационный порт.

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

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

• •    среда разработки;

• •   СУБД и формат таблиц;

• •   работа с COM-портом;

• •    протокол обмена данными между ПК и ИТК;

• •    графический интерфейс.

Отметим, что при создании ПО АРМ диспетчера существенное значение имеет время доступа, то есть интервал от момента поступления в систему запроса до момента представления соответствующей информации диспетчеру [8]. Здесь важным является не 0242

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

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

РЕЗУЛЬТАТЫ И ОБСУЖДЕНИЕ

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

В настоящее время существует множество языков программирования, причем большинство из них предоставляет сходные возможности. Поэтому выбор во многом определяется приверженностью разработчика тому или иному языку программирования [9]. Наиболее распространенными объектно-ориентированными языками являются C++, Object Pascal, Java. С учетом требований заказчика для разработки проекта был выбран язык Object Pascal, который отвечает ряду требований:

• •   поддерживает ООП;

• •   широко распространен (компиляторы этого языка существуют для

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

• •    имеет простой и удобный синтаксис (более близкий к естественному языку, чем в С++).

Для реализации данного проекта была выбрана система разработки приложений Borland Delphi, поскольку она обладает перечисленными ниже свойствами [10]:

• •    быстрота разработки приложения;

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

• •    низкие требования разработанного приложения к ресурсам компьютера;

• •    расширяемость за счет встраивания новых компонент и инструментов в среду;

• •    возможность разработки новых компонент и инструментов собственными средствами Delphi (существующие компоненты и инструменты доступны в исходных текстах)

• •    хорошо проработанная иерархия базовых классов;

• •    возможность работы с Win32 API, использования ассемблерных вставок, работы с указателями и др.;

• •    наличие интегрированных средств работы с базами данных: инструментальные средства, обеспечивающие обслуживание БД вне разрабатываемых приложений (BDE, Database Desktop и др.); компоненты, предназначенные для создания приложений, осуществляющих операции с БД.

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

СУБД и формат таблиц БД

В данном случае система не предполагала одновременной работы нескольких диспетчеров, поэтому для ее функционирования персональной СУБД, обеспечивающей возможность создания локальной БД на одном компьютере, было вполне достаточно. Основное достоинство такого подхода заключается в простоте реализации при сохранении необходимой функциональности. Отметим, что анализ информационных потоков на предпроектной стадии исследования выполняется на макроуровне, что позволяет понять общую схему работы объектов управления на ТП и усовершенствовать документооборот [8]. Анализ на микроуровне обеспечивает выявление элементов информационного отображения объекта управления на экране АРМ диспетчера, взаимосвязей между ними, структуры и динамики информационных потоков.

В качестве СУБД предполагается использовать Borland Database Engine, поскольку она, помимо прочего, включена в стандартную поставку Delphi. В Delphi так же имеется богатый набор стандартных компонент для работы с БД средствами BDE [12, 13].

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

BDE не имеет своего формата таблиц, однако поддерживает два вида локальных таблиц – dBase и Paradox. Каждый из этих видов имеет свои особенности.

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

Таблицы Paradox являются достаточно развитыми и удобными при создании БД [14].

Основные достоинства таблиц Paradox:

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

• •    поддерживается целостность данных;

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

• •    поддерживается защита таблиц с помощью паролей.

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

Работа с COM-портом

Для соединения компьютера и ИТК со стороны компьютера используется интерфейс, называемый COM-порт. Для этого интерфейса характерны простота и низкие аппаратные требования (в сравнении, например, с параллельным интерфейсом). Данный тип интерфейса остается наиболее распространенным в системах промышленной автоматизации [15-17].

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

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

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

Протокол обмена данными между ПК и ИТК

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

Спецификация протокола определена в документации к ИТК. На базе компоненты COM-порта, предоставляющей функции записи и чтения наборами байт, необходимо реализовать протокол обмена [18].

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

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

Графический интерфейс

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

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

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

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

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

Если визуальные компоненты создавать на форме динамически по информации из БД, то это сведет процесс проектирования линейных схем и добавления новых станций в систему к добавлению соответствующих записей в БД. Элементы будут автоматически размещаться на форме поверх графического изображения-подложки [20].

ЗАКЛЮЧЕНИЕ

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