Разработка интерфейса взаимодействия
микропроцессорных систем диспетчерского управления и контроля с
автоматизированной системой управления грузовыми перевозками
Источник: Информационные управляющие
системы и компьютерный мониторинг (ИУС и КМ-2012) / Электронный
сборник трудов III международной научно-технической конференции студентов, аспирантов и молодых ученых. — Донецк, ДонНТУ — 2012, с. 35-38
Авторы: Гриневич И.Е., Жевжик С.Е., Зеленёва И.Я.
Предложен способ организации взаимодействия этих систем, описана структура интерфейса. Определены требования к передаче сообщений. Рассмотрен порядок действий в случае разрыва связи.
Автоматическое определение параметров операций прибытия, отправления, проследования поездов является затратным не только в аппаратном плане, но и в плане времени.
На сегодняшний день существуют различные виды автоматизированных систем. Условно их можно разделить на два вида: линейные и информационные. Линейные системы дают представление о прохождении подвижной единицей контрольного участка в определенный момент времени, информационные же системы дают информацию о конкретно взятой подвижной единице, которая должна преодолеть контрольный участок в некоторый (приблизительный) момент времени [1].
Для получения наиболее достоверной картины необходима реализация взаимодействия двух таких систем: получение точного времени прохождения и идентификация подвижной единицы.
Разработка интерфейса взаимодействия обеспечит унификацию взаимодействия микропроцессорных систем (МПЦ) диспетчерского управления, диспетчерской централизации (ДЦ) и диспетчерского контроля (ДК), с автоматизированной системой управления грузовыми перевозками (АСУГП) и, как следствие, существенно уменьшит затраты при подключении систем МПЦ различных разработчиков.
Реализация взаимодействия автоматизированного рабочего места (АРМ) АСУГП и МПЦ позволит обеспечить:
1) уменьшение затрат на введение необходимой информации за счет автоматического определения параметров операций прибытия, отправления, проследования поездов;
2) существенное повышение точности и полноты учета поездной работы в системе АСУГП.
В настоящее время на сети железных дорог широко используются системы диспетчерского управления (ДУ), основой которых служат устройства вычислительной и микропроцессорной техники. Переход к микропроцессорным и компьютерным системам от релейных и полупроводниковых в первую очередь обусловлен экономическими показателями: для создания комплекса устройств управления движением подвижных единиц ранних поколений были необходимы значительные затраты на интеграцию и расширение функциональных возможностей. Помимо того, диспетчерская централизация требует увеличения места, отведенного для аппаратуры, что ведет к снижению надежности аппаратуры, увеличению энергоёмкости и затрат на обслуживание.
Использование компьютерной и микроэлектронной техники делает возможной реализацию современных систем автоматики, в том числе и систем автоматизации управления железнодорожными перевозками, с помощью создания центров ДУ. Основой этих систем является применение компьютеров в качестве аппаратуры центрального поста, микроконтроллеров на линейном пункте, современных модемов для организации каналов передачи информации, отображение ситуаций на железнодорожных полигонах и конкретных их участках на мониторах операторов с помощью АРМ.
Компьютерные системы диспетчерской централизации реализуют не только минимально необходимый набор функций, связанный с непосредственным управлением станционными и перегонными объектами, но, за счет программного обеспечения, значительно их расширяют. Так, появилась возможность логической обработки информации о положении подвижных единиц и состоянии станционных объектов в устройствах центральных постов и линейных пунктов, формирования управляющих сигналов, воздействующих на устройства электрической централизации и автоблокировки с учетом фактического состояния объектов.
На современные системы диспетчерской централизации возлагаются функции передачи команд, обеспечивающих безопасность при частичных отказах в устройствах [2].
Системы МПЦ и рабочие узлы могут взаимодействовать:
– на линейном уровне – с системами станционной централизации на основе вычислительной техники (с микропроцессорными или релейно-процессорными системами диспетчерской централизации и диспетчерского контроля) и АРМ;
– на уровне серверов центров (полигонов) управления поездной работой (взаимодействие с центральными комплексами диспетчерского контроля и централизации – центральных постов).
Предлагается реализация взаимодействия рабочих узлов систем МПЦ и АСУГП путем обмена структурированными сообщениями в формате XML с использованием транспортного протокола TCP/IP в режиме TCP-соединения (используется программное обеспечение Socket API, которое имеет реализации в составе практически всех операционных систем).
Каждая передающая сторона (далее сервер) создает серверный сокет и ожидает соединения.
Каждая принимающая сторона (далее клиент) создает клиентский сокет и инициирует соединение с серверным сокетом передающей стороны.
После установления соединения клиентская сторона выполняет чтение информационных сообщений от серверной стороны, а серверная сторона ведет сессию передачи информационных сообщений.
Передача сообщений в сеансе взаимодействия должна отвечать следующим требованиям:
– сообщения нумеруются последовательно, начиная со стартового сообщения с порядковым номером «0». Порядковый номер задается атрибутом в главном теге сообщения. По достижению максимального возможного номера нумерация начинается с 1;
– стартовое сообщение содержит полную информацию по полигону взаимодействия для клиентской стороны;
– после стартового сообщения клиентской стороне предоставляются модификационные сообщения с информацией об изменениях;
– клиентская сторона контролирует целостность информационного потока путем проверки порядкового номера полученного сообщения. Если зафиксировано нарушение последовательности, клиентская сторона разрывает соединение, после чего обе стороны совершают действия для запуска нового сеанса взаимодействия;
– в случае аварийного завершения передачи соединение ликвидируется и сервер переходит в режим ожидания. В таком случае клиенту после установления соединения будет предоставлено стартовое сообщение с номером «0».
Обобщенная структура информационного сообщения показана на рис. 1:
Рисунок 1 – Обобщенная структура информационного сообщения
Предлагаемая структура взаимодействия АРМ и систем МПЦ показана на рис. 2:
Рисунок 2 – Предлагаемая структура взаимодействия АРМ и систем МПЦ
Информация, предоставленная системами МПЦ, передается серверной стороной клиентской стороне в виде информационных сообщений. На основе информации из сообщений формируются объекты (модели), которые будут записаны в СВОМ.
Клиентская сторона, представленная клиентскими сокетами для каждого АРМ, контролирует целостность информационного потока и имеет возможность запрашивать продолжение передачи сообщений с указанного номера. Для этого клиентом отправляется служебное сообщение с номером последнего обработанного сообщения.
Информация об изменениях, полученная из модификационных и стартовых информационных сообщений, заносится в локальный контейнер моделей. Каждые два часа серверный вариант контейнера моделей СВОМ обновляется путем внесения изменений из локальных контейнеров моделей.
Из-за вероятных сбоев связи или скачков напряжения возможен разрыв связи по причине отсутствия сети, отключением серверной стороны, аварийным выключением компьютера с запущенным АРМ. В таких случаях клиент и сервер начинают действия по возобновлению сеанса связи. Клиент с некоторым интервалом времени (около 6 мин) предпринимает попытки подключения к серверу. Если не удалось установить подключение, клиент предпримет новые попытки через некоторое время. Если же попытка удалась, то необходима проверка возможности восстановления информационного потока.
Возможность восстановления информационного потока существует в случае краткого интервала между обрывом и восстановлением связи между клиентом и сервером.
Клиентская сторона проверяет все принятые сообщения и осуществляет поиск последнего обработанного события с идентификатором, хранящимся в АСУГП. В случае нахождения сообщения с таким событием проверяется наличие необработанных событий в том же информационном сообщении и их обработка. Далее проверяется наличие более поздних информационных сообщений и их обработка, после чего серверу отправляется служебное сообщение-запрос с номером последнего обработанного сообщения. Серверная сторона анализирует ситуацию: если в очереди присутствуют последующие сообщения, возможно продолжение передачи сообщений с указанного номера, следовательно, сервер продолжает отправление модификационных информационных сообщений. Если в очереди у серверной стороны отсутствуют последующие сообщения, клиенту отправляется стартовое сообщение с номером «0», после чего предоставляются модификационные информационные сообщения.
Предложенная реализация взаимодействия автоматизированного рабочего места (АРМ) АСУГП и МПЦ позволит обеспечить уменьшение затрат на введение необходимой информации за счет автоматического определения параметров операций прибытия, отправления, проследования поездов, а также существенное повышение точности и полноты учета поездной работы в системе АСУГП. В связи с возможным восстановлением информационного потока стало возможным иметь точную поездную картину на полигоне без потерь данных даже после разрывов связи, что являлось целью разработки интерфейса взаимодействия.
1. Гавзов Д.В., Автоматизированные системы диспетчерского управления движением поездов [Текст] / Гавзов Д.В., Никитин А.Б. // Транспорт: наука, техника, управление. Сборник обзорной информации. Вып.2. М. ВИНИТИ. 1993г.
2. Пенкин Н. Ф.,
Диспетчерская централизация [Текст] / Пенкин Н. Ф.,
// М. Трансжелдориздат, 1963.