Список сокращений3

Введение5

1. Системотехническая часть

1.1. Анализ предметной области

1.1.1. Информационная система управления парком порожних вагонов компаний-операторов.

1.1.1.1. Введение в предметную область

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

1.1.1.3. Организация связи между информационной системой распределения порожних вагонов и информационными системами ОАО "РЖД".

1.1.1.4. Система распределения порожнего парка вагонов

1.2. Обоснование необходимости создания информационной системы распределения парка порожних вагонов компаний-операторов

1.3. Разработка проекта в методологии SADT

1.4. Модель БД на основе Erwin

1.5. Математическое моделирование

1.6. Обоснование выбора среды реализации

1.6.1. Выбор системы управления базами данных

1.6.2. Выбор языка программирования

2. Конструкторско-технологическая часть

2.1.Технические требования

2.2.Инструкция пользователя

2.3.Руководство администратора информационной системы распределения парка порожних вагонов компаний-операторов

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

3.1.Определение себестоимости разрабатываемой системы

4. Безопасность и экологичность проекта

4.1. Охрана труда при работе с компьютером

4.1.2. Расчет снижения уровней шума от движения поездов

4.1.3. Охрана окружающей среды на железнодорожном транспорте

4.2. Безопасность в чрезвычайных ситуациях

4.2.1.Краткая характеристика поражающих факторов радиации

4.2.2. Мероприятия по повышению устойчивости работы объекта

4.2.3. Расчет противорадиационного укрытия

5. Патентный поиск

5.1. Регламент поиска

5.2. Используемые источники информации

5.3. Результаты поиска

5.4. Вывод

Заключение

Библиографический список

Приложение

В разные времена задача сокращения издержек в компании "Российские железные дороги" приобретала различные экономические или политические оттенки. Решая ее сегодня, компания отталкивается от анализа требований, которые возникают в нынешних быстро меняющихся экономических условиях.

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

Электронная синхронизация

Двенадцать лет назад в тогда еще Министерстве путей сообщения РФ была создана система фирменного транспортного обслуживания, предназначенная для формирования маркетинговой политики и реализации услуг железнодорожных грузовых перевозок. В настоящее время эта система не ограничивается выполнением маркетинговых функций, но также обеспечивает оперативную обработку огромного объема информации о грузовых перевозках. Тогда, в середине 90-х годов, требовалась ежемесячная обработка почти 1,5 млн. документов для приема груза к перевозке и примерно такого же количества документов для оформления дополнительных услуг.

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

Когда разработка системы ЭТРАН только начиналась, перед разработчиками была поставлена задача, создать систему, которая должна была автоматизировать жесткое соблюдение регламентов операций по принятым бизнес-правилам. Система ЭТРАН должна работать в строгом соответствии с утвержденными нормативными документами.

Еще одно жесткое требование, выдвигавшееся изначально, - система ЭТРАН должна быть централизованной. Раньше все программно-технические решения развертывались на уровне региональных (дорожных) вычислительных центров. У каждого вычислительного центра была возможность внести в программное обеспечение свои изменения, и возникала опасность нарушения целостности правил. Кроме того, велики были трудозатраты на поддержку в актуальном состоянии всех систем на местах. Необходимо было сделать так, чтобы только главный вычислительный центр РЖД имел возможность устанавливать новую версию и никто нигде не смог вмешаться в этот процесс.

Окончательное решение о разработке системы ЭТРАН было утверждено в феврале 2001 года. Но полнофункциональное внедрение ЭТРАН на всей территории России не было. В качестве опытных полигонов были выбраны Красноярская и Куйбышевская железные дороги, так как там работали наиболее инициативные кадры, готовые внедрять новые решения. К тому же на Куйбышевской дороге инициативы исходили не только от ИТ-персонала, но и от структур транспортного обслуживания.

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

В результате эксплуатации системы ЭТРАН РЖД получили солидный экономический эффект благодаря точности взыскания провозных платежей, потому что "зашитые" в систему правила расчетов минимизировали риски ошибок. Искажения, вызванные несвоевременным обновлением версий системы, теперь исключены. Объективная информация сразу же передается в смежные системы для проведения бухгалтерских проводок и оформления документов налоговой отчетности, обеспечивая тем самым снижение налоговых рисков компании и повышая точность финансового учета. Если раньше база данных отправления и база данных прибытия были не всегда корректными (не всегда совпадали), то теперь создан один единый электронный документ: что грузоотправитель передает в электронном виде, то и принимает система. Что привело к снижению издержек на донном этапе.

Новая история

Новые требования возникли, когда стали появляться новые субъекты транспортного рынка. Если раньше клиент, обращаясь к МПС, а потом к РЖД, мог получить комплексную услугу, то теперь ему придется заключать договор с собственником подвижного состава и только после этого организовывать железнодорожные перевозки. Раньше вагоны принадлежали МПС и управление ими происходило принципам и законам, принятым в МПС, теперь из процесса выпало звено "вагоны": у их собственника в рамках договора с грузоотправителем возникла необходимость подсыла вагонов в точку погрузки груза, это означает необходимость оформления документов на порожний рейс.

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

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

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

В современных условиях необходимо иметь данные, например, не вообще о ста вагонах (скажем, цементовозах) на Московской дороге, а о 20 вагонах в точке А, 30 - в точка B и 50 - в точке С. Избыточность парка в точках, где он не востребован, и, наоборот, его недостаточность там, где вагоны нужны, приводит к экономическим рискам. В конечном счете, это невыгодно ни РЖД, которое теряет доходы, потому что не перевозит грузы, ни грузоотправителю, который упускает свои возможности.

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

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

Решение реализовано на основе трехуровневой архитектуры "клиент-сервер". Высокоскоростные расчеты математической модели, оптимизирующей перемещение порожних вагонов на основе различных критериев (с целью максимизации прибыли, выполнения всех заказов, сокращения порожнего пробега), выполняют серверы на базе процессоров Intel под управлением Windows Server 2003 или Sun SPARC под управлением Sun Solaris. Клиентская часть системы реализована для рабочих станций на платформе Windows.

Уже на стадии опытной эксплуатации АС ДРПВ удалось получить определенные результаты оптимизации использования парка РЖД, увидеть узкие места и получить более подробную информацию о техническом состоянии вагонов. Однако на фоне преимуществ обострялись и риски. Во-первых, до появления новых возможностей специалисты РЖД не обладали актуальной информацией о техническом состоянии вагонов. Это важно, поскольку ряд грузоотправителей, особенно работающих с международными перевозками, предъявляет повышенные требования к состоянию вагонов. Между тем их изъяны ранее нигде не фиксировались.

Второй риск связан с соблюдением нормативных сроков доставки. Когда система осуществляет "привязку" вагонов под заявку, есть риск, что вагон не успеет пройти расстояние за указанное время (например, если испортится погода в Новороссийске, порт будет перерабатывать грузы в меньшем объеме, это приведет к задержке вагонов).

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

Разрабатываемая информационная система позволяет принимать непосредственное участие в процессе распределения вагонов, выполняя следующие функции:

" слежение за парком порожних вагонов компании;

" сопоставление заявок на перевозку грузов с вагонами;

" выдача результатов распределения для просмотра и редактирования;

" дальнейшая отправка документа под погрузку.

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

В связи с высокой информатизацией железной дороги, разрабатываемая система должна взаимодействовать с уже существующими информационными комплексами, в частности, с Автоматизированной системой оперативного управления перевозками (АСО УП), Автоматизированной системой управления станцией (АСУ СТ), а также с Автоматизированной системой централизованной подготовки и оформления перевозочных документов (ЭТРАН). Из последней системы берется информация о перевозимом грузе (тип груза; тип вагона, пригодного для перевозки этого груза), о времени поздней погрузки груза, о станции погрузки. Из АСО УП берется информация о собственнике, типе, виде, пробеге, номере, регионе курсирования вагона, а также название станции, на путях которой он стоит, принадлежность этих путей (подъездные, запасные и т.д.). АСУ СТ предоставляет данные о номере парка, в котором находится вагон, и пути, где вагон в данный момент стоит.

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

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

1. Олег Седов "Борьба с издержками": Директор информационной службы. - Электрон. журн. - 20.06.2008.

2. Автоматизированная система централизованной подготовки и оформления перевозочных документов (ЭТРАН). Техническое задание. Мин.Транс. РФ - М.: 2000. 48 с

3. Полный документооборот заявок на перевозки грузов (ГУ-12) в системе ЭТРАН. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ. ОАО "РЖД". - М.: 2009 - 71 с

4. Оформление перевозочных документов при отправлении. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ. ОАО "РЖД". - М.: 2009 - 140 с

5. Технология VipNet: Диалог Сибирь - Электрон. портал. - Режим доступа: http://www.dialog-it.ru/sysint/?p=197

6. Расходы собственников сократятся: Газета "Октябрьская магистраль" (Октябрьская железная дорога). - Электрон. портал. - 12.02.2010. Режим доступа: http://press.rzd.ru/isvp/public/press?STRUCTURE_ID=4&layer_id=463&refererLayerId=461&id=238720

7. Временная технология перемещения ОАО "РЖД" порожних полувагонов ОАО "ПГК" под заказы ОАО "ПГК" на основе динамического распределения порожних вагонов к заказам ОАО "ПГК" .ОАО "РЖД": 2009 - 37 с

8. Авторское право: Электрон. Документ. Режим доступа: http://studio-hem.narod.ru/Kratko_ob_avtorskom_prave_i_smezhnih_pravah.doc //

9. Методические указания по проведению патентного поиска при дипломном проектировании для студентов очной и заочной форм обучения/ Т.М. Чиркова, М.В. Трошина - Самара: СамГУПС, 2007 - 12 с.

10. Официальный бюллетень Российского агентства по патентам и товарным знакам. Программы для ЭВМ. Базы данных. Топологии интегральных микросхем. ФИПС". - за период с 1999 по 2010 гг.

11. Федеральный закон РФ "Об основах охраны труда в Российской Федерации" от 17 июля 1999 г. №181-ФЗ

12. Cанитарно-эпидемиологические правила и нормативы "Гигиенические требования к персональным электронно-вычислительным машинам и организации работы. СанПин 2.2.2/2.4.1340-03"

13. Маслов Н.Н., Коробов Ю.И. Охрана окружающей среды на железнодорожном транспорте: Учеб. для вузов. М.: Транспорт, 1996. 238 с.

14. Проектирование защиты от транспортного шума и вибраций жилых и общественных зданий: Электрон.портал - 1999 - Режим доступа: http://www.complexdoc.ru/ntdtext/479826#TO0000009

15. Безопасность в чрезвычайных ситуациях. Гражданская оборона /М.А. Шевандин, Б.Б. Ботоев, Б.Н. Рубцов, С.Д. Тыльков и др.: Учебное пособие для студентов вузов ж.-д.трансп.; Под ред. М.А. Шевандина. - М.: Маршрут 2004. - 364 с.

16. Расчет противорадиационной защиты: Методические указания для разработки вопросов обеспечения безопасности жизнедеятельности в чрезвычайных ситуациях и гражданской обороны в дипломных проектах (работах) - Самара: СамГАПС, 2003.

17. Cравнение MS SQL Server 2008 с Oracle: Электр.портал-2010. Режим доступа:http://www.microsoft.com/sqlserver/2008/ru/ru/compare-oracle.aspx

18. C++: Википедия - Электрон энциклопедия. Режим доступа: http://ru.wikipedia.org/wiki/C++#.D0.A1.D1.80.D0.B0.D0.B2.D0.BD.D0.B5.D0.BD.D0.B8.D0.B5_C.2B.2B_.D1.81_.D1.8F.D0.B7.D1.8B.D0.BA.D0.B0.D0.BC.D0.B8_Java_.D0.B8_C.23

19. Решение задач линейного программирования средствами математических пакетов: методические указания к выполнению лабораторных, практических и контрольных работ по дисциплинам специальности 230201 "Информационные системы и технологии" для студентов очной и заочной форм обучения / сост. В.Г. Волик, Т.Б. Ефимова. - Самара : СамГАПС, 2006. -38 с.

20. В.И. Грекул. Проектирование информационных систем. Курс лекций: Электрон. портал-http://www.intuit.ru/department/se/devis/

21. ГОСТ 19.003-80 Единая система программной документации. Схемы алгоритмов и программ. Обозначения условные графические.

22. ГОСТ 34.201-89. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем.

23. ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. ИПК издательство стандартов.

Примечаний нет.