 |
Сетевая интегрированная российская информационно – управляющая система (СИРИУС)
|
|
|
|
Цель создания системы
Реформирование железнодорожного транспорта требует внедрения новых высокоэффективных методов управления перевозками на базе широкого использования современных информационных технологий и технических средств, позволяющих более эффективно реализовывать накопленный опыт и знания, содействовать принятию оптимальных управленческих решений.
Для решения подобных задач и была создана система СИРИУС – комплекс, объединяющий существующие информационные технологии управления перевозками в единое целое (рисунок 7.30.4). Система создана на новых принципах, реализуемых на современной программно-технической базе, и рассматривается как корпоративная и интегральная. Первое означает, что она формируется по одним и тем же правилам для однородных объектов (станции, отделения, железные дороги, ОАО «РЖД»), распределенных как по вертикали, так и по горизонтали управления. Второе свойство - «интегральность» - заключается в функционировании системы на основе единой информационной базы, предусматривающей идентичность представления информации об объектах в серверах различных уровней управления, а также использование единых источников сбора и обработки данных.
Основное назначение системы
Главная задача системы - оптимизация технологии перевозочного процесса, иными словами повышение качества услуг, предоставляемых грузоотправителям и грузополучателям. Система позволяет управлять вагонным парком, погрузочными ресурсами и грузопотоками, организовывать продвижение поездов в оптимальном режиме, с учетом всех многообразных факторов поездной обстановки, складывающейся на всем пути продвижения груза. Пользователь СИРИУСа видит на экране компьютера реальное состояние вагонных парков, погрузки-выгрузки и транзита. СИРИУС позволяет оперативно управлять собственными и арендованными вагонами, отслеживать движение массовых грузов, учитывать прохождение вагонов стран СНГ и Балтии по российским железным дорогам.
|
|
|
Рисунок 7.30.4 – Сетевая интегрированная российская информационно-управляющая система
Система реального времени
СИРИУС содержит планирующие и прогнозные модели. Имеет централизованную нормативную базу данных по всем показателям эксплуатационной работы сети, дорог, отделений дорог, станций, экономические оценки эффективности перевозочного процесса в целом и его частей.
В основу планирования и регулирования грузопотоков положен метод ситуационного моделирования взаимосвязанных между собой объектов управления. Он универсален и может быть применен для любых объектов (в том числе для транспортных коридоров, морских портов, сухопутных погранпереходов, районов массовой погрузки нефтепродуктов, угля, руды и т.д.) и одновременно учитывает сложившуюся ситуацию в реальном времени:
- наличие на сети, дорогах, отделениях, станциях погрузочных ресурсов, грузов, заявок, вагонов, поездов, локомотивов и бригад и т.д.;
- положение на местах погрузки (зарождение вагоно-, грузо- и поездопотоков);
- темпы продвижения транспортных и грузовых потоков, подвода порожних вагонов к местам погрузки и груженых к местам выгрузки или перевалки, темпы выгрузки.
При установившемся ритме работы все эти составляющие сбалансированы. В случае нарушения баланса по заданным критериям отклонений в ситуационной модели определяется конкретный момент, когда необходимо принятие управляющих решений, причем все происходит в режиме реального времени.
Кроме того, в системе введено новое понятие - «ресурсы объекта управления». Любой объект управления - станция, подъездной путь, диспетчерский участок, отделение или дорога в зависимости от ситуации имеют ресурс, т.е. нормированную загрузку, вместимость. В зависимости от конкретной ситуации увеличение загрузки и снижение ресурса приводит к уменьшению маневренности на объекте управления - это может быть необеспечение подач, замедление продвижения или «бросание» поездов и т.д. Определяются контрольные, допустимые точки отклонений от заданных нормативов, при достижении которых необходимо упреждающее принятие мер не только на данном объекте управления, но и на всех взаимосвязанных с ним.
|
|
|
Система СИРИУС в отведенной ей зоне ответственности решает главные целевые задачи ОАО «РЖД». Прежде всего, это стратегическая цель - обеспечение максимальной прибыли компании. Она реализуется совокупностью иерархически упорядоченных частных целей, средств и функций в сфере управления и информационно-технологических процессах функционирования производств компании, в том числе автоматизированными средствами экономического управления объектами и процессами на всех иерархических уровнях железнодорожного транспорта. Критерием оценки достижения стратегической цели компании ОАО «РЖД» является уровень устойчивости ее экономического положения, достигаемый за счет повышения конкурентоспособности по сравнению с другими видами транспорта, улучшения управления денежными потоками, оптимизации затрат всех видов ресурсов и налогообложения.
В этих целях система СИРИУС при организации планирования и управления эксплуатационной работой использует долгосрочные и среднесрочные маркетинговые прогнозы, представленные в виде грузопотоков, которые готовит система фирменного транспортного обслуживания (СФТО).
На основе бизнес-прогнозов по объемам и видам перевозок и принятых от клиентов заявок на перевозку грузов СФТО формирует сводный план перевозок с включением в него всех отдельных заявок. Задача СИРИУС - минимизировать расходы.
СИРИУС на основе сводного плана рассчитывает технические нормы эксплуатационной работы и обеспечивает выполнение сводного плана через механизм исполнения каждой согласованной заявки на перевозку, включая импорт и транзит через территорию России.
|
|
|
При поступлении и согласовании заявки на перевозку грузов система СИРИУС, используя нормативные и расчетные сроки доставки грузов в пункты назначения (сдачи), формирует на основе данных заявки календарные сроки прибытия и выгрузки вагонов.
Наряду с этим решается оптимизационная задача привязки-регулировки порожних вагонов из-под предстоящей выгрузки к пункту назначения для предстоящей погрузки. В первую очередь оптимизируются отдельные или комплексные критерии по стоимости с учетом возврата вагонов собственникам, запаса пробега до пункта погрузки и пункта последующего ремонта, минимизации суммарного оборота вагона и порожнего пробега на выполнение заявленных корреспонденций перевозимых грузов, приоритетности выполнения ритмичного либо согласованного подвода грузов в пункты назначения, использования резерва подвижного состава при сбоях в процессе выполнения плана перевозок и заявок.
В результате решения этой задачи определяются дефицит подвижного состава, возможные потери доходов ОАО «РЖД» от невыполнения заявок, неритмичной работы, штрафных санкций и т.д. и плановая обеспеченность заявок подвижным составом. СИРИУС организует планирование, регулирование, подвод порожних и подачу вагонов в места погрузки в соответствии с заявками отправителей, обеспечивая оформление и фиксацию факта подачи вагонов.
Архитектура построения системы и её реализация
Работы по реализации системы СИРИУС включают в себя две очереди:
Первая очередь. Система выполнена по модульной схеме. Причем ее модули могут располагаться как на одной, так и на нескольких ЭВМ. Это база данных АСОУП-2, источник данных (JDBC DataSource), сервис имен (RMI NameService) и удаленных объектов (RMI Remote Server), система регистрации событий (Logger System), сервер приложения СИРИУС (первый уровень ServerSIRIUS), Web-приложение (второй уровень ClientServerSIRIUS), приложение StdpManager (STDP) и Web-browser пользователя.
В момент загрузки системы стартуют приложения RMI NameService, ServerSIRIUS, ClientServerSIRIUS и StdpManager, каждое - в своем потоке. В момент инициализации ServerSIRIUS создается объект RMI RemoteServer, который регистрируется в RMI NameService. В момент инициализации ClientServerSIRIUS выполняет подключение к серверам ServerSIRIUS через запросы в RMI NameService указанных в файле свойств.
|
|
|
Архитектура первой очереди системы СИРИУС представлена на рисунке 7.30.5.
Пользователь системы формирует через WEB-browser и запрашивает требуемые данные. WEB-приложение второго уровня (ClientServerSIRIUS) принимает запросы пользователей, обрабатывает их и в зависимости от полученных параметров формирует запрос в одну или несколько систем ServerSIRIUS по RMI-соединению. Запросы в несколько систем отрабатываются в параллельном режиме.
Сервер ServerSIRIUS по полученным параметрам генерирует запрос и посылает его в свою базу данных АСОУП-2, получает результаты выполнения запроса, преобразует их и возвращает серверу ClientServerSIRIUS. Сервер ожидает ответы от всех систем, затем группирует из множества документов один и выполняет его преобразование по соответствующим правилам. Результат преобразования выдается пользователю, пославшему запрос.
В системе СИРИУС для использования сервисом имен RMI Name Service принят порт 24001, для сервера ServerSIRIUS - порт 24003. Сервер приложения StdpManager обеспечивает прием и обработку плановых сообщений задачи ДИСКОР.
 |
Рисунок 7.30.5 - Архитектура первой очереди системы СИРИУС
В ходе эксплуатации первой очереди системы были выявлены следующие недостатки:
• большая вероятность планового или непланового отключения одного из узлов системы, что приводит к неполному отображению выходных данных на сетевом уровне;
• восстановление соединений с удаленными серверами приложений «по требованию», что вызывало много нареканий пользователей при формировании выходных данных, так как первый запрос, инициирующий восстановление соединения с удаленной системой, отображался без данных этой системы;
• предметная область программного кода присутствовала в обоих серверах приложений. Это сдерживало развитие системы при реализации новых задач и требовало дополнительного программирования для достижения согласованной работы узлов системы с разными уровнями выпуска программного обеспечения;
• при наращивании функциональности системы потребовалось пересмотреть группировку программного кода между объектами WEB-приложения второго уровня системы для исключения взаимного влияния при внесении изменений;
• последовательное выполнение запросов при формировании сложных выходных форм. В большом количестве выходных форм системы СИРИУС выполняется от трех и более запросов к различным объектам базы данных АСОУП-2. Последовательное их выполнение и ожидание результата создает у пользователей впечатление медленно работающей системы.
|
|
|
Для устранения этих недостатков и решения вновь поставленных задач возникла необходимость внести изменения в архитектуру системы.
Вторая очередь. В архитектуре второй очереди было предложено усложнить систему вводом дополнительного уровня. Основные усилия были направлены на устранение недостатков и обеспечение гарантированного получения данных на сетевом уровне.
Архитектура системы СИРИУС второй очереди (рисунок 7.30.6) включает в себя следующие модули:
• базу данных АСОУП-2;
• источник данных (JDBC Data Source);
• сервис имен (RMI Name Service);
• сервер удаленных объектов (RMI Remote Server);
• представление дорожной базы данных (SQL Node System) - первый уровень системы;
• представление распределенной базы данных (SQL Multi System) -второй уровень системы;
• Web-приложение (Web Application) - третий уровень системы;
• приложение STDP Manager;
• систему регистрации событий (Logger System);
• Web-browser пользователя.
На дорожном уровне запускаются две копии сервера приложений СИРИУС: основная и копия горячего резерва. В момент загрузки системы стартуют приложения RMI Name Service, RMI Remote Server, SQL Node System, SQL Multi System, Web Application, STDP Manager (только на основном сервере) и активизируются объекты регистрации событий (Logger System) и источник данных (JDBC Data Source). Приложения SQL Multi System и Web Application на сервере горячего резерва могут не запускаться. В этом случае резервный сервер приложений может быть запущен как JAVA-приложение, а не под управлением WEB-сервера.
Каждое приложение системы СИРИУС стартует в своем потоке. Приложение SQL Node System при старте регистрируется в сервере удаленных объектов RMI Remote Server и в сервисе имен RMI Name Service.
В момент старта приложения SQL Multi System запускаются потоки контроля соединения с удаленными серверами SQL Node System других дорог (основных и резервных систем). При разрыве соединения эти потоки в автономном режиме пытаются восстановить разорванное соединение.
На дорожном уровне можно запускать и более одного сервера горячего резерва. В будущем планируется реализовать механизм балансировки нагрузки в группе представлений удаленных дорожных серверов при нормальной работе основных и резервных систем.
 |
Рисунок 7.30.6 - Архитектура второй очереди системы СИРИУС
Пользователь системы формирует через WEB-browser запрос требуемых данных. WEB-приложение системы СИРИУС (Web application) принимает запрос пользователя, обрабатывает его и передает на выполнение объекту представления распределенных данных (SQL Multi System), который анализирует полученные параметры и в зависимости от них передает одному или более объектам представления дорожных систем (HADR Node System).
При плановом или неплановом отключении основного дорожного сервера приложений СИРИУСа объект «группа серверов» по кодам получаемых ошибок от объекта «представление дорожного сервера» (Node System) переадресовывает выполнение запросов через резервный дорожный сервер. При отключениях дорожных баз данных объект «Представление дорожной системы» (HADR Node System) по кодам возврата переадресовывает запросы объекту «группа серверов ГВЦ», который обеспечивает доступ данным к сетевой базе АСОУП-2 Главного вычислительного центра (ГВЦ) ОАО «РЖД», в которую данные дорог переносятся с использованием механизма репликации. Сервер приложения STDP Manager обеспечивает прием и обработку плановых сообщений задачи ДИСКОР. Приложение STDP Manager можно запустить и на сервере горячего резерва параллельно основной копии. В этом случае активной (работающей копией) будет только тот (один) экземпляр STDP Manager, который первым установит соединение.
Процесс обработки сообщений при разрыве соединения может перемещаться между серверами (первый, выполнивший соединение, будет обрабатывать запросы).
Наряду с изменениями архитектуры системы внесен целый ряд новшеств в технологию распределенного запроса. Все они направлены на повышение общей производительности системы и снижение нагрузки на базу данных. Число резервных систем с серверами приложений и баз данных системой не ограничивается. Рассмотренная архитектура построения второй очереди системы накладывает следующие ограничения:
• основные и резервные дорожные серверы приложений СИРИУСа не должны выключаться одновременно, при обновлении программного обеспечения системы (системного или системы СИРИУС) рекомендуется вначале выполнить обновления на резервном сервере, затем на основном;
• плановые отключения дорожных баз данных и базы данных ГВЦ должны быть разнесены во времени и периоды отключений не должны пересекаться.
По мере развития программно-аппаратных комплексов ИВЦ дорог и возникновения необходимости создания резервных систем баз данных на дорожном уровне эти серверы будут без проблем добавляться в систему СИРИУС. Вместе с тем целесообразно рассмотреть вопрос о совершенствовании структуры объектов моделей АСОУП-2 с учетом построения базы данных. В настоящее время она перегружена избыточными сведениями из-за многократного дублирования информации. Это создает излишнюю нагрузку на сервер базы.
Одним из принципов построения СИРИУСа является использование единой нормативной базы. К сожалению, ни в АСОУП-1, ни в АСОУП-2 она не предусмотрена, нет ее и в единой дорожно-сетевой базе ДВ-2. Разработчики системы СИРИУС нашли выход: используются нормативы технического плана эксплуатационной работы, которые имеются в системе ДИСКОР. Но это планы только дорожного уровня. Отсутствие в нормативной базе сетевых планов в определенной мере сдерживает реализацию в СИРИУСе анализа показателей ОАО «РЖД».
В настоящее время внедрены в промышленную эксплуатацию следующие разработки:
1. Универсальный пользовательский интерфейс СИРИУС, позволяющий получить информацию на текущий момент времени и на отчетные сутки:
• по наличию, состоянию и дислокации вагонных парков;
• по работе подвижного состава (расчлененный оборот каждого вагона по элементам перевозочного цикла);
• по грузовой модели дороги, наличию грузов на дороге, отделении, станции, в движении;
• по наличию по роду груза и дислокации груза с контролем срока доставки;
• по наличию и передаче транзитных вагонов;
• по приему и сдаче поездов и вагонов по межгосударственным, междорожным и внутридорожным стыкам;
• по контролю состояния и дислокации локомотивов.
2. Программное обеспечение по наполнению нормативной базы СИРИУС на основе плановых и суточных макетов системы ДИСКОР.
3. Унифицированный пользовательский интерфейс (УПИ) по наличию, состоянию и дислокации вагонных парков с разложением по дорогам, отделениям, станциям дислокации и роду подвижного состава, с разделением на порожние и груженые вагонов рабочего парка, парка ОАО «РЖД», государств-собственников, компаний-собственников, компаний-арендаторов, компаний-операторов, вагонов нерабочего парка (неисправные, в резерве, в спецтехнадобности, в остальных нуждах), вагонов, находящихся за балансом (в запасе, собственные на путях собственника, арендованные на путях арендатора).
4. УПИ по работе подвижного состава по станциям погрузки и дорогам назначения, в т.ч. экспортных грузов с разложением по дорогам, отделениям, станциям погрузки (норма, факт, среднесуточная погрузка) вагонов парка ОАО «РЖД», государств-собственников, компаний-собственников, компаний-арендаторов, компаний-операторов с разбивкой вагонов по роду подвижного состава.
5. УПИ по работе подвижного состава (погрузка) по роду груза и дорогам назначения, в т.ч. экспортных грузов с разложением по роду груза, станциям погрузки (норма, факт, среднесуточная погрузка) в вагонах парка ОАО «РЖД», государств-собственников, компаний-собственников, компаний-арендаторов, компаний-операторов с разбивкой вагонов по роду подвижного состава.
6. УПИ по работе подвижного состава (выгрузка) по станциям выгрузки и роду подвижного состава с разложением по дорогам, отделениям, станциям выгрузки (наличие, по обороту, выгрузка в текущие сутки, среднесуточная выгрузка, остаток под выгрузкой) в вагонах парка ОАО «РЖД», государств-собственников, компаний-собственников, компаний-арендаторов, компаний-операторов.
7. УПИ по работе подвижного состава (выгрузка) по роду груза и роду подвижного состава с разложением по роду груза, станциям выгрузки (наличие, по обороту, выгрузка в текущие сутки, среднесуточная выгрузка, остаток под выгрузкой) в вагонах парка ОАО «РЖД», государств-собственников, компаний-собственников, компаний-арендаторов, компаний-операторов, вагонов по отделениям дороги с разложением по роду груза, станциям выгрузки.
8. УПИ по грузовой модели дороги (наличие грузов на дороге, отделении, станции, в движении с возможностью, отбора грузов для стран СНГ, собственников, арендаторов, компаний-операторов) в вагонах парка ОАО «РЖД», государств-собственников, компаний-собственников, компаний-арендаторов, компаний-операторов.
9. УПИ по наличию местных грузов по роду груза и дислокации местного груза с контролем срока доставки грузов и регистрации факта просрочки с выдачей предупредительного сигнального знака, развоз и передача местного груза с выдачей задания на дорогах, отделениях, станциях, в движении в вагонах в вагонах парка ОАО «РЖД», государств-собственников, компаний-собственников, компаний-арендаторов, компаний-операторов.
10. УПИ по наличию и передаче транзитных вагонов с разложением по стыкам сдачи, нормы и факт передачи вагонов в вагонах парка ОАО «РЖД», государств-собственников, компаний-собственников, компаний-арендаторов, компаний-операторов, вагонов нерабочего парка.
11. УПИ по обмену поездов, вагонов и контейнеров по междорожным стыковым пунктам.
12. УПИ по отчетам и справкам о работе дороги с разложением по отделениям за сутки, декаду, месяц, с начала месяца по следующим показателям: погрузка, выгрузка, рабочий парк, прием, сдача, развоз, передача, оборот вагона, средний вес поезда, участковая скорость, наличие местных вагонов, статнагрузка, оборот местных и транзитных вагонов.
13. Сводный отчет:
· по наличию, состоянию и дислокации вагонных парков;
· по работе подвижного состава (погрузка, выгрузка);
· по грузовой модели дороги, наличию грузов на дороге, отделении, станции, в движении;
· по наличию груза и дислокации местного груза с контролем срока доставки грузов;
· по наличию и передаче транзитных вагонов;
· по приему и сдаче поездов и вагонов по междорожным стыкам;
· по контролю состояния и дислокации локомотивов.
14. УПИ по контролю состояния дислокации локомотивов:
· находящихся в грузовом движении;
· электровозов переменного и постоянного тока;
· тепловозов грузового движения;
· локомотивов эксплуатационного парка по следующим показателям:
- в движении;
- на станции по прибытии с поездом;
- после депо;
- в депо в ожидании работ;
- в ожидании ТО-2;
- на ТО-2;
- в отвлечении от грузового движения;
· локомотивов НЭП по следующим показателям:
- по виду ремонта ТР-2 по виду ремонта ТО-3;
- по виду ремонта ТО-4;
- по внеплановым видам ремонта.
Ближайшие планы по дальнейшему развитию функционального состава системы СИРИУС включают разработки:
- подсистемы контроля и анализа показателей эксплуатационной работы сети, железных дорог, отделений дорог с детализацией до линейных объектов управления с элементами экономической оценки;
- системы управления грузопотоками в транспортных коридорах;
- технологии, алгоритмов метода ситуационного моделирования взаимосвязанных между собой объектов управления;
- прогнозной части функционального состава;
- методики, технологии и алгоритмов по распределению погрузочных ресурсов на сетевом уровне.
СИРИУС и логистика
Система СИРИУС, интегрируя в себе комплекс информационно-управляющих и аналитических технологий, позволяет осуществлять на практике логистическое управлениегрузо- и вагонопотоками. Рассмотрим возможности реализации технологических решений СИРИУСа на примере организации работы районного логистического центра (РЛЦ).
Технология работы РЛЦ должна основываться на едином сквозном технологическом процессе работы транспортного узла, предусматривающем согласованный со всеми участниками перевозки подвод грузопотоков и подвижного состава (вагонов, судов, автомобилей и т.п.), обеспечивающий его дальнейшую перевозку. Единый технологический процесс должен базироваться на соответствующей современным условиям экономической и правовой основе. В нем необходимо четко регламентировать основные типовые обязательства сторон-участников перевозки, регулирующие их отношения.
Создание и внедрение на основе единого технологического процесса работы транспортного узла, автоматизированной системы управления транспортным комплексом должно быть информационно и технологически увязано с Международным логистическим центром по управлению грузопотоками, логистическими службами стран ближнего и дальнего зарубежья, Главным логистическим центром России, логистическими службами смежных видов транспорта, всеми участниками транспортного процесса, крупными производителями продукции, ЦУПом ОАО «РЖД», дорожными центрами управления перевозками (ДЦУ), центрами по управлению местной работой (ЦУМР) отделений дорог, станциями и всеми другими предприятиями и организациями, участвующими в перевозке.
Логистическое управление грузо- и вагонопотоками основывается на принципе диспетчеризации с использованием комплекса взаимосвязанных информационно-управняющих систем и технологий (рисунок 7.30.7):
• сетевой интегрированной информационно-управляющей системы СИРИУС;
• автоматизированной системы централизованной подготовки и оформления перевозочных документов «Электронная транспортная накладная» (ЭТРАН);
• автоматизированной системы обеспечения своевременной и адресной доставки грузов («Грузовой экспресс»);
• автоматизированной системы управления местной работой (АСУ ЦУМР).
Рисунок 7.30.7 - Комплекс взаимосвязанных информационно – управляющих автоматизированных систем по реализации логистических технологий
Груженый подвижной состав, например вагон с грузом, следующий в адрес порта, с момента появления информации о нем в автоматизированной системе учета наличия и продвижения подвижного состава и грузов (для железнодорожного транспорта это система ДИСПАРК) через взаимосвязь с другими системами (СИРИУС, ЭТРАН, «Грузовой экспресс», АСУ ЦУМР) ускоренно продвигается к месту (станции) назначения. Время его продвижения на всех этапах контролируется. Постоянно прогнозируется время прибытия на грузовой фронт под выгрузку и одновременно с этим планируется и постоянно прогнозируется подход судна, на которое должен быть перегружен груз из этого вагона. Определяется занятость грузовых фронтов и перегрузочных механизмов во взаимосвязи с текущим положением дел на перегрузочном пункте по работе с перегрузкой других влияющих грузов.
Экономисты ГЖД подсчитали, что использование данной СИРИУС позволяет дороге ежегодно экономить 235 млн. рублей. В частности, благодаря СИРИУСу на дороге в 2004 на 16 процентов вырос межремонтный срок пробега подвижного состава (благодаря оптимизации управления техническим обслуживанием и ремонтом), на 15 процентов увеличилась производительность единицы подвижного состава. Положительное влияние системы СИРИУС зафиксировано в общей сложности по 15 производственно-экономическим показателям. Всё это ещё раз говорит об эффективности данной системы, что обуславливает её дальнейшее развитие и внедрение на всей сети железных дорог России.
|
|
|
