107140, Москва, ул. Верхняя Красносельская, д.3, стр.5
Тел.: +7 (499) 929-83-71
Факс: +7 (499) 929-00-25
Главная » Пресс-центр » Публикации

Управление парками вагонов.

12 мая 2008 г.
Информационный портал «Логинфо», 03-2008
За полтора века своего существования железнодорожная сеть России стала третьей по размеру в мире. В условиях развития рыночной экономики Министерство путей сообщения было преобразовано в ОАО «Российские железные дороги», что стало началом реформирования отрасли. Внедрение новой технологии управления парками вагонов стало знаковым для процесса преобразования системы производства в сфере грузовых перевозок. О том, что происходит в сфере автоматизации управления парком, рассказывает руководитель департамента корпоративных проектов компании «ИнтэлЛекс» Титов Владимир Геннадиевич.

Статистический подход плановой экономики

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


Бизнес должен приносить прибыль

В настоящее время нет никаких точных доказательств, что парк вагонов ОАО «РЖД» перемещается по сети оптимальным образом. А бизнес компании-собственника, как и любого предприятия, должен приносить прибыль. И с математической точки зрения существует два способа ее увеличения: увеличить доход от парка вагонов и сократить издержки. Для сокращения расходов нужно уменьшить диспетчерский аппарат и сконцентрировать его в одном месте. Для увеличения дохода необходимо оптимально с точки зрения экономических критериев управлять движением вагона по сети железных дорог. Для получения необходимого результата автоматизированная системы управления парком должна анализировать данные обо всех заказах на перевозку грузов, дислокации вагонов на сети ОАО «РЖД» и текущее состояние вагона (в пути, загружается или разгружается, когда следующий ремонт) и определять под какой заказ должен ехать порожний вагон так, чтобы доход компании был максимален (или порожний пробег минимален). Желательно чтобы подобная система работала на относительно не дорогих вычислительных средствах.


Начало изменений

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

  • ведение правил расчёта и расчёт провозной платы по Прейскуранту 10-01;
  • ведение реестра парка подвижного состава находящегося под управлением системы; 
  • хранение заказов на предоставление подвижного состава; 
  • хранение оформленных перевозочных документов; 
  • хранение данных о дислокации вагонов; 
  • расчёт математической модели управления перемещением порожних вагонов; 
  • формирование комплекта перевозочных документов на перемещение порожних вагонов; 
  • хранение нормативно-справочной информации; 
  • обеспечение функционирования диспетчеров; 
  • формирование произвольной аналитической отчётности; 
  • мониторинг процесса расчёта модели; 
  • обновление версий программного обеспечения клиентов системы.

Первая реализация

Опытная эксплуатация АС ДРПВ началась в августе 2007 года на парке цементовозов ОАО «РЖД». В качестве критерия оптимизации был задан минимальный порожний пробег. Цементовозы были выбраны как несложный в технологическом плане род подвижного состава. 
На этапе реализации в ядро системы были добавлены следующие функции:

  • загрузка данных из АБД АВ по получению данных в реестр парка подвижного состава;
  • загрузка из АС ЭТРАН заказов на предоставление подвижного состава; 
  • загрузка из АС ЭТРАН оформленных перевозочных документов; 
  • загрузка из АС ЭТРАН данных о дислокации вагонов; 
  • передача в ЭТРАН комплекта перевозочных документов и управляющего воздействия для АСОУП на перемещение порожних вагонов; 
  • формирование заказной аналитической отчётности; 
  • автоматическая печать вагонных листов на станции. 

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


Один за всех

В настоящее время ежедневная потребность в погрузочном ресурсе по цементовозам составляет 1200 до 1500 вагонов, а общий объём парка, находящегося под управлением АС ДРПВ, составляет около 14000 вагонов. Распределение вагонов происходит на период до 12 суток вперед. При принятии решения, какой вагон будет отдан под какую заявку, учитывается различная информация, включая данные о ранее перевозимом грузе, порожнем пробеге, техническом состоянии вагона и т.д. 
Диспетчерское управление обеспечивает один человек, при этом в его задачи входит:

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

Еще 4 человека находятся на горячей линии по решению оперативных вопросов, возникающих на станции и связанных в большинстве своем с определенным недопониманием некоторых технологических вопросов. Опыт эксплуатации уже к октябрю 2007 года показал, что порожний пробег снизился на 10%, парка вагонов хватает для реализации всех заказов. 
Внедрение системы у конкретного транспортного оператора имеет смысл, когда количество вагонов составляет 5000 единиц и более и большинство маршрутов движения трудно предсказать заранее (низкое число так называемых «вертушек»).


Программно-аппаратный комплекс

Архитектура АС ДРПВ представляет собой классическую трёхуровневую схему: сервер базы данных — сервер приложений — клиент. Система является централизованной, что позволяет принимать решения по управлению парком сразу по всей сети ОАО «РЖД» без каких-либо ограничений. Программные решения с такой архитектурой отличаются производительностью, надежностью, масштабируемостью и защищенностью данных.

Аппаратная платформа АС ДРПВ представляет собой комплекс серверов на платформе Intel, расположенных в Главном Вычислительном центре ОАО «РЖД». В целом требования к аппаратной платформе для развертывания системы следующие:

  • сервер БД – сервер, предназначенный для сбора, обработки и хранения информации, обеспечения централизованного контроля, а также формирования необходимой достоверной и оперативной отчетности; (любой сервер на базе процессоров Intel (Windows NT Server 2003) или SUN SPARC (SUN Solaris)); 
  • сервер приложений – сервер, предназначенный для обеспечения взаимодействия клиентских рабочих мест с сервером БД (любой сервер на базе процессоров Intel (Windows NT Server 2003)); 
  • сервер расчёта модели – сервер, предназначенный для высокоскоростного расчёта математической модели, оптимизирующей перемещение порожних вагонов на основе различных критериев (Максимизация прибыли, выполнение всех заказов, сокращение порожнего пробега);( любой сервер на базе процессоров Intel (Windows NT Server 2003) или SUN SPARC (SUN Solaris));

Для повышения отказоустойчивости системы в целом все серверные элементы системы могут быть зарезервированы.


Вопрос-ответ

В заключении ответы на вопросы начальника отдела логистики ОАО "Монди Сыктывкарский ЛПК" Игоря Кругляка и ведущего инженера ОАО "Первоуральский Новотрубный Завод" Олега Брезгина.

Каким образом и кем будут оформляться перевозочные документы на порожние вагоны? Сегодня это делают наши грузополучатели по нашим инструкциям. Можно ли будет это делать дистанционно с наших рабочих мест ЭТРАН без привлечения грузополучателя?

Возможны две принципиальные схемы работы: ручная и автоматическая.

Ручная: Система ДРПВ формирует заготовки комплекта перевозочных документов и передаёт его в систему ЭТРАН. Далее документ дооформляется на станции товарным кассиром и, наконец, сообщение 410 передаётся товарным кассиром в АСОУП.

Автоматическая: Система ДРПВ формирует комплект перевозочных документов и автоматически подписывает комплект документов с помощью ЭЦП и передан в ЭТРАН. Сообщение 410 передаётся автоматической процедурой АС ЭТРАН в АСОУП.

Если станция возврата порожнего вагона всегда одна и та же, можно ли автоматизировать полностью процесс оформления возврата вагонов?

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

Как быть с запорно-пломбировочными устройствами (ЗПУ), кто будет вносить их номера?

В случае с ручной схемой товарный кассир вводит номер ЗПУ в ЭТРАН при дооформлении документа. При автоматической схеме номер ЗПУ не вводится или прописывается вручную в вагонный лист.

Возможно ли уже сейчас применение технологии АС ДРПВ в отношении собственных (арендованных) вагонов для грузоотправителей и экспедиторских компаний.

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