| Душа болит за родные железные дороги. Хочется перевозить больше, лучше, быстрее, дешевле и обеспечить максимально высокий уровень безопасности. К сожалению, не всегда это получается, особенно в последнее время. Организация перевозок не в последнюю очередь зависит от работы устройств железнодорожной автоматики.
Для обеспечения безопасности движения необходим постоянный контроль работоспособности устройств управляющих стрелками и сигналами. Беда в том, что эта техника не новая, релейная и средствами диагностики, тем более дистанционными, не оснащена. Поэтому устройства приходится обслуживать по графику, в соответствии с которым электромеханики обязаны обходить станции и перегоны. Состояние устройства, зачастую, проверить могут только в ремонтно-технологическом участке, а потому работает оно или не работает, выработало ресурс или нет, а приходится его менять. В результате ходят механики по перегонам и станциям и заменяют приборы, которые могли бы еще лет пять спокойно работать. При данной организации работы теряется драгоценное время и оперативность оповещения о неисправностях, отсутствует возможность их прогнозирования. Итак, одной из важнейших задач является контроль за работой большого количества устройств автоматики, расположенных на протяжении многих километров и передача собранной информации обслуживающему персоналу в режиме реального времени.
Кроме того, для принятия эффективных решений по управлению движением требуется обладать объективной информацией о поездном положении. В данное время эта информация ограничена показаниями табло у дежурного по станции или парку. Проблема заключается в том, что движением управляют поездные и маневровые диспетчеры и эту информацию со станций они до сих пор получают по телефону. Отсюда и достоверность понятная.
Еще одной задачей является ведение протокола работы устройств автоматики и действий персонала, то есть реализация своего рода "черного ящика".
Над решением задач диспетчерского контроля (ДК) за работой устройств автоматики на железной дороге думают давно. Лаборатория систем автоматики кафедры "Автоматика и телемеханика на железных дорогах" Петербургского Государственного Университета Путей Сообщения этой проблемой занимается в течение пяти лет и сегодня можно сказать, что есть определенные успехи.
Около десяти станций и перегонов на Октябрьской и Московской железных дорогах оборудованы различными вариантами системы ДК нашей разработки.
Особенно дело двинулось, когда появились результаты эксплуатационных испытаний первой, пробной системы, разработанной на базе Micro PC (СТА N1/96). Удобство в работе и надежность Micro PC привели к созданию нового варианта системы ДК для маневрового диспетчера сортировочной станции.
Система предназначена для воссоздания поездной обстановки на станции на рабочем месте маневрового диспетчера и передачи этой информации другим заинтересованным пользователям, например, сменному инженеру дистанции, в обязанности которого входит регистрация отказов устройств и организация работы по их устранению. Кроме этого система позволяет фиксировать различные технологические ситуации на станции, например, прибытие составов, их роспуск, простой, накопление вагонов на путях сортировочных парков и представлять ее в удобной для диспетчера форме таблиц и диаграмм. Для этой цели используется не только данные о состоянии станционных устройств, но и сообщения из Вычислительного Центра, получаемые по каналу через модем.
Структурно система состоит из устройства съема данных и удаленного от него на расстояние около 1 км рабочего места маневрового диспетчера. Связь осуществляется по четырехпроводной линии.
В качестве устройства съема данных используется Micro PC, содержащее :
- процессорную плату 5025А;
- две платы дискретного ввода-вывода 5600;
- четыре OPTO RAС, специальным образом подключенных к дискретным датчикам.
Следует отметить, что для контроля за работой только одной половины сортировочной станции, включающей в себя три парка (парк приема, сортировочный парк и парк отправления), необходимо контролировать около полутора тысяч объектов. Если мы умножим это число на стоимость одного модуля оптронной развязки фирмы Crayhill, то получим цифру около 15000$. Цифра для нас по нынешним временам, увы, не малая. Поэтому, было принято решение при помощи стандартных модулей УСО организовать входную матрицу. Цена сразу упала на порядок, мы обошлись 96-го модулями I/O типа G4IDC5.
Правда, пришлось разработать и изготовить саму матрицу, однако затраты на это оказались несопоставимо меньшими, чем если бы мы решали задачу "в лоб". Оптронная матрица представляет собой модульную структуру, каждый из модулей которой позволяет подключать 16 дискретных сигналов постоянного или переменного тока напряжением от 12 до 30 В. Модули при помощи разъемов устанавливаются на "материнской" плате, которая в свою очередь стандартными кабелями OCTAGON SYSTEMS соединяется с OPTO RACами.
Рабочее место маневрового диспетчера реализовано на ПЭВМ типа IBM AT с многотерминальной видеоплатой, поддерживающей работу четырех мониторов.
После определения аппаратных средств встал вопрос о выборе операционной системы (ОС), под управлением которой будет функционировать система ДК. Исходя из требований к функциям системы ДК мы пришли к выводу, что данная ОС должна обладать, как минимум следующими возможностями :
- поддержка многозадачности;
- многопользовательский режим;
- масштабируемость;
- высокая производительность;
- работа в режиме реального времени;
- надежная и максимально быстрая передача больших объемов данных по низкоскоростному и не очень качественному каналу связи;
- простота подключения различных аппаратных устройств;
- работа на ограниченных системных ресурсах;
- надежная файловая система;
- возможность удаленного изменения версий программ;
- возможность интеграции с другими системами.
На наш взгляд, всеми вышеперечисленными свойствами обладает ОС QNX, что и определило ее выбор в качестве операционной среды реализации системы ДК.
Многозадачность требуется в связи с тем, что система ДК должна параллельно выполнять несколько взаимодействующих задач, а именно :
- сбор и первичная обработка данных;
- ретрансляция данных;
- отображение поездного положения;
- регистрация неисправностей;
- фиксация технологических ситуаций;
- прием сообщений из Вычислительного Центра;
- ведение протокола работы.
Очень мощным, с нашей точки зрения, является реализованный в QNX механизм обмена сообщениями, на базе которого система ДК была реализована в технологии клиент - сервер, повышающей надежность работы и позволяющей с незначительными издержками увеличивать как число устройств съема данных, так и потребителей информации.
Поддержка многопользовательского режима требуется в связи с тем, что в системе одновременно могут работать несколько пользователей. Подключение дополнительных рабочих мест пользователей планируется осуществить на базе локальной сети, одним из узлов которой будет рабочее место маневрого диспетчера. Поддержка
в QNX нескольких сетевых стандартов дает возможность для выбора : Ethernet, Arcnet, Token Ring и т.д.
Требование высокой производительности и работы в режиме реального времени становится понятным, если принять во внимание число контролируемых датчиков (в реализованном варианте их около 1500, а впоследствие будет как минимум в два раза больше) и заданную частоту съема их показаний - не менее 5 раз в секунду. Причем изменения состояний нескольких десятков датчиков происходят практически при каждом опросе.
Проблему надежной передачи данных по каналу связи удалось решить при помощи объединения в сеть QNX устройства съема и рабочего места диспетчера, что позволило использовать системный сетевой протокол и реализовать этот обмен независимым от среды передачи данных для прикладных программ. Сеть по последовательному каналу довольно устойчиво работает при скорости передачи данных в 4800 бод. Для увеличения пропускной способности сети мы использовали реализованный сетевым драйвером механизм сжатия/разжатия данных, являющийся прозрачным для прикладных программ. Не обошлось и без некоторых сложностей. ОС QNX гарантирует, в случае если при передаче сообщения какая-нибудь задача окажется заблокированной, то система через некоторое время автоматически снимет блокировку, вернув код ошибки. К сожалению, данный механизм почему-то не всегда срабатывает. Задача может зависнуть в таком состоянии на неопределенно долгое время. Пришлось отслеживать и исправлять данную ситуацию программным способом. Возможно это объясняется наличием ошибки в сетевом драйвере Net.fd версии 4.22 и при переходе на версию 4.23 удастся от нее избавиться.
Желание создать систему, не привязанную жестко к конкретным аппаратным средствам приводит к необходимости написания драйверов устройств. Тот кто писал и отлаживал драйверы устройств под DOS знает, что это занятие приятным не назовешь, особенное неудобство доставляет то, что интерфейс ОС для драйверов и прикладных программ абсолютно различный. Что касается QNX, то написание и отладка драйверов ничем не отличается от написания и отладки остальных программ. Программный интерфейс общий для всех программ. Довольно быстро были написаны драйверы для платы Octagon 5600 и многоэкранной видеокарты.
Так как в состав QNX входит большое число менеджеров устройств и различных драйверов, то во многих случаях можно просто воспользоваться предоставляемым сервисом, а не разрабатывать собственное программное обеспечение. В нашем случае, для подключения модема и организации сети между устройством съема и рабочим местом диспетчера использовался стандартный менеджер последовательных каналов. Подключение модема свелось к написанию нескольких строчек кода, а для организации сети не потребовалось ни одной!
Вследствии того, что QNX имеет небольшой размер и модульную структуру, стало возможным установить данную ОС на Micro PC. Ядро ОС, модуль сетевой поддержки, менеджер встроенной файловой системы и прикладные программы удалось разместить всего в 256Кб флеш-памяти и 100Кб статического ОЗУ. При работе требуется немногим более 1Мб оперативной памяти.
Инсталляция программного обеспечения на Micro PC производилась при помощи удобного средства EKit - пакета для установки QNX во встраиваемые системы.
Возможность удаленного изменения версий программ в нашем случае крайне необходима ,так как Micro PC в рабочем режиме не имеет ни экрана, ни клавиатуры, ни дисковода. Прозрачный доступ к файлам в сети QNX значительно облегчает нам жизнь, а менеджер встроенной файловой системы Efsys позволяет перепрограммировать флеш-память и статическое ОЗУ при помощи обычной команды копирования файлов.
После перезаписи имеется возможность программной перезагрузки удаленного компьютера с обновленной версией. С организацией программного перезапуска у нас возникли некоторые проблемы. Попытка его осуществления практически всегда приводила к тому, что перезапускаемая машина зависала намертво. Это затруднение удалось обойти установив параметр отмены "горячей" перезагрузки при генерации образа ОС.
Одной из основных задач, поставленных перед проектировщиками системы ДК, была задача предусмотреть возможность ее интеграции c уже имеющимися программными разработками. В качестве одной из таких разработок можно привести систему ведения графика исполненного движения, реализованную другими разработчиками в среде Windows NT. Учитывая негативный опыт, полученный при реализации собственных протоколов под DOS, было принято решение применять для стыковки исключительно стандартные протоколы. Де-факто, такими стандартными протоколами является семейство протоколов TCP/IP, что явилось еще одним весомым доводом в пользу системы, обеспечивающей их поддержку.
Пакет TCP/IP для QNX предоставляет разработчику не только возможность программировать на уровне Socket API, но и использовать преимущества сетевой файловой системы (NFS), вызовов удаленных процедур (RPC) в стандарте ONC, многих полезных служб, например, telnet и ftp.
Система ДК реализованная на базе передовых аппаратных и программных технологий способствует получению диспетчером достоверной информации и значительно облегчает управление оперативной работой станции. Ведение протокола работы позволяет обнаружить "узкие места" и избежать не нужных материальных затрат. В перспективе появляется задача автоматического формирования многочисленных документов, которые до сих пор заполняются вручную, но это предмет отдельного разговора.
Система разработана ОНИЛ систем автоматики кафедры "Автоматика и телемеханика на железных дорогах"
Б.Л. Горбунов, старший научный сотрудник ПГУПС
А.Е. Федоров, аспирант ГААП
ПГУПС, 190031, Санкт-Петербург, Московский пр.,9. ИМСАТ
тел. (812) 168-82-84
факс (812) 168-86-49; (812) 168-84-95.
|
