MODELING OF TRANSPORT SITUATION FOR THE INFORMATION MANAGEMENT SYSTEMS OF RAILWAY TRANSPORT

(1)

681.51.001.57:656.2

В

.

И

.

МОЙСЕЕНКО

,

В

.

В

.

РАДЧЕНКО

(

УкрГАЖТ

)

МОДЕЛИРОВАНИЯ

ПОЕЗДНОЙ

СИТУАЦИИ

ДЛЯ

ИНФОРМАЦИОННО

УПРАВЛЯЮЩИХ

СИСТЕМ

ЖЕЛЕЗНОДОРОЖНОГО

ТРАНСПОРТА

Розглянутопитаннямоделюванняпоїзноїситуаціїнастанції. Була побудованаматематичнамодельро -ботипристроївзалізничноїавтоматикитапоїзнихпересувань. Описаноспеціальнепрограмнезабеспечення, якедозволяєспростититаприскоритипроцесналагодженнясистемурізноманітнихрежимах.

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

The article considers the issues of modelling train situations at stations and develops a mathematical model of operation of railway automatics devices and movements of trains. The special software has been described, which allows essentially to simplify and speed up the process of systems arrangement in different modes.

Стремительное развитие вычислительной техники позволило создавать программно -аппаратныекомплексыспособныереализовывать любые технологические процессы. На дан -номэтапе железнаядорога остаетсяодним из самых привлекательных объектов автомати -зации. Технологические процессы довольно сложны и человек уже не справляется с та -кимбольшимколичествоминформации. Кроме того, установленные системы устарели и требуют замены. Дальнейшее развитиефунк -ций этих систем не возможно, поскольку элементнаябазаустарела [1; 2].

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

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

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

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

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

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

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

(2)

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

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

Разработка модели станции разбивалась на триэтапа. Напервомэтапепроисходилообуче -ние модели передаче основных информацион -ныхпосылок.

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

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

</TrackCircuit>

Формирование списка основных команд осуществлялосьнаоснованиисинтезированных графовпереходов. Дляпримера нарис. 1 пред -ставленграфпереходоврельсовойцепи.

Рис. 1. Графпереходоврельсовойцепи:

1 – рельсоваяцепьсвободна, незамкнута, неразмыкается; 2 – рельсоваяцепьзанята, незамкнута, неразмыкается;

3 – рельсоваяцепьсвободнаизамкнутавмаршруте; 4 – занятиерельсовойцепизамкнутойвмаршруте; 5 – отменамаршрута; 6 – искусственноеразмыкание

присвободнойрельсовойцепи; 7 – искусственное размыканиепризанятойрельсовойцепи; 8 – отказ

вработерельсовойцепи; 9 – ремонт

В процессе анализа сформированы все воз -можныепереходыизодногосостояниявдругое ивыявленывсе причиныэтихпереходов. Впо -следствии графы реализовывались впрограмм -ном обеспечении модели [4–6]. Для примера ниже представленкодреализации данногогра -фанаязыке C++ [7; 8]

void SwitchSect::StateAdapt() {

ushort state;

state = NO_DEFINED; if( _Coils[0] == SP_UP )

state = SECT_FREE;

else if( _Coils[0] == SP_DOWN ) state = SECT_BUSY;

if( _Coils[1] == Z_DOWN ) {

if( state == SECT_FREE ) state = SECT_ROUTE; else if( state == SECT_BUSY )

state = SECT_BROUTE; }

if( _Coils[2] == RI_UP ) {

if( state == SECT_FREE || state == SECT_ROUTE )

state = SECT_UCFREE;

else if( state == SECT_BUSY || state == SECT_BROUTE )

state = SECT_UCBUSY; }

SetState(state); }

(3)

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

другому. К примеру, автоматическая система оповещенияпередаваларабочему местудежур -ного по станции информацию об установке иотменефронтаработит. д.

Рис. 2. СтруктураподключенийАРМкмоделистанции

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

Передача каждой команды от АРМ серверу системы и в обратном направлении заверша -лась квитированием (рис. 3). Это позволяло

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

Основное окно модели представляет собой поле, содержащее путевое развитие станции и световую индикацию табло (рис. 4). Любой из элементов путевогоразвития можноактивизиро -ватьнажатиемкнопкиманипулятора «мышь».

Уровеньсистемы Уровеньмодели Информационное

сообщение

Квитирование

Информационное сообщение

Квитирование

t

Рис. 3. Диаграммапередачиинформационныхсообщений

(4)

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

работу системы путем формирования заведомо ложного сообщения. На рис. 5 представлен фрагмент видеограммы станции с установлен -ныммаршрутомотправления.

На рис. 6 изображено окно с командами по одному из объектов. У каждого элементапуте -вого развития свой перечень команд. Данный режимпередачисообщенийназванручнымили пошаговым.

Рис. 5. Маршрутотправления

Рис. 6. Списоккоманддлярельсовойцепи

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

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

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

(5)

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

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

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

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

Рис. 7. Проигрывательчерногоящика

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

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

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

БИБЛИОГРАФИЧЕСКИЙСПИСОК

1. Глушков В. М. Синтез цифровых автоматов. – М.: Физматгиз, 1962

2. Сапожников В. В. Дискретные устройства же -лезнодорожной автоматики, телемеханики и

связи / В. В. Сапожников, Ю. А. Кравцов, В. В. Сапожников. – М: Транспорт, 1988.

3. ТрухаевР. И. Моделипринятия решенийв ус -ловиях неопределенности. – М.: Наука, 1981. – 258 с.

4. АмосовН. М. Нейрокомпьютерыиинтеллекту -альные роботы / Н. М. Амосов, Т. Н. Байдык, А. Д. Гольцев. – К.: Наук. дум., 1994 – 272 с. 5. БорисовА. Н. Обработканечеткойинформации

в системах принятия решений / А. Н. Борисов, А. В. Алексеев, Г. В. Меркурьеваидр.

6. Hecht – Nielsen R/ Neurocomputing: picking the

human brain. // IEEE SPECTRUM 1998 – V.25.N3 – p. 36–41.

7. Krten, Rob, 1965 – Getting started with QNX

Neu-trino 2 – a guide for realtime programmers.

8. Bjarne Stroustrup AT&T Labs Murray Hill, New

Jersey, The C++ programming language.

9. Чепцов М. Н. Динамическая поездная модель района диспетчерского управления. Дис… канд. техн. наук. – Харьков, 2001.