ТТ СГ_7_

advertisement
Общество с ограниченной ответственностью
«ТМХ-Сервис»
УТВЕРЖДАЮ:
Генеральный директор
ООО «ТМХ-Сервис»»
_______________ В.И.Гриненко
«___» февраля 2015 г.
СЕТЕВОЙ ГРАФИК
РЕМОНТА ЛОКОМОТИВОВ В
СЕРВИСНЫХ ЛОКОМОТИВНЫХ ДЕПО
ООО «ТМХ-Сервис»
Технические требования
к информационно-управляющей системе
Москва
2015 г.
-1-
ЛИСТ СОГЛАСОВАНИЯ
Ф.И.О.
ЛЯНГАСОВ
Сергей Леонидович
СУББОТИН
Роман Николаевич
Должность
Заместитель
генерального директора
ООО «ТМХ-Сервис»
по развитию
Заместитель
генерального директора по
организации ремонта ТПС
ООО «ТМХ-Сервис»
АБИСАЛОВ
Роман Хаджи-Мурадович
Заместитель
Генерального директора
по коммерции
ГРЕБЕНЮК
Александр Васильевич
Начальник департамента
управления сервисным
обслуживанием
АНДРЮШКОВ
Иван Васильевич
Начальник департамента
УПД и ЗО
РОЗВЕР
Денис Юрьевич
Начальник департамента
информационнотехнической поддержки
ЛАКИН
Игорь Капитонович
Начальник департамента
научно-технического
развития ООО «ТМХСервис»,
разработчик ТТ
-2-
Подпись, Дата
СОДЕРЖАНИЕ
ВВЕДЕНИЕ .................................................................................................................. 5
1. АНАЛОГИ ............................................................. Error! Bookmark not defined.
1.1. ЗАДАЧИ СИСТЕМЫ........................................................................................ 9
1.2. АСУ ТП ............................................................................................................ 11
1.3. ДИАГРАММЫ ГАНТА .................................................................................. 12
1.4. ОБЗОР РЫНКА ............................................................................................... 17
1.4.1. Уровень эксклюзивности задачи .......................................................... 17
1.4.2. SAP R/3 .................................................................................................... 17
1.4.3. 1С ............................................................................................................. 17
1.4.4. MS Project ................................................................................................ 18
1.4.5. IBM Maximo ............................................................................................ 18
1.4.6. EAM-системы ......................................................................................... 18
1.4.7. CLARIS Solutions .................................................................................... 18
1.4.8. АСУ ЦТР ................................................................................................. 20
1.4.9. Сетевой ТЧР Нижнеудинск ................................................................... 20
2. ИНФОРМАЦИОННЫЕ СИСТЕМЫ ТМХ-СЕРВИС ........................................ 21
2.1. АСУ ТМХ-СЕРВИС........................................................................................ 21
2.2. ИНТЕРНЕТ ...................................................................................................... 22
2.3. УПРАВЛЕНИЕ НАДЁЖНОСТЬЮ ЛОКОМОТИВОВ............................... 23
2.3.1. АСУНТ .................................................................................................... 23
2.3.2. ЕСМТ ....................................................................................................... 27
2.3.3. Мониторинг эксплуатации локомотивов ............................................. 28
2.4. МОДЕЛИ И ТЕХНОЛОГИЧЕСКИЕ КАРТЫ .............................................. 32
2.5. НСИ .................................................................................................................. 32
-3-
3. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ ................................................ 33
3.1. ОБЩИЕ ТРЕБОВАНИЯ ................................................................................. 33
3.2. МАСШТАБИРУЕМОСТЬ .............................................................................. 34
3.3. ОБЪЕМ БАЗЫ ДАННЫХ .............................................................................. 35
3.4. БЫСТРОДЕЙСТВИЕ...................................................................................... 35
3.5. СУБД ................................................................................................................ 36
3.6. СОПРОВОЖДЕНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ...................... 36
3.7. СОПРОВОЖДЕНИЕ ТЕХНОЛОГИЧЕСКОГО ОБЕСПЕЧЕНИЯ ............ 36
3.8. ФУНКЦИОНАЛЬНОСТЬ СИСТЕМЫ ......................................................... 37
4. УПРАВЛЕНИЕ ПРОЕКТОМ ............................................................................... 38
4.1. ЗАКАЗЧИК СИСТЕМЫ ................................................................................. 38
4.2. ОТВЕТСТВЕННЫЕ ИСПОЛНИТЕЛИ РАЗРАБОТКИ .............................. 38
4.3. ПИЛОТ-ПРОЕКТЫ 2015 ГОДА.................................................................... 38
5. МОДЕЛЬ УПРАВЛЕНИЯ ТМХ-СЕРВИС ......................................................... 39
© ООО «ТМХ-Сервис», 2015 г.
-4-
ВВЕДЕНИЕ
Настоящие технические требования посвящены очень важному элементу
автоматизированной системы управления (АСУ) ООО «ТМХ-Сервис»
(т.н. ERP-системы), которую необходимо разработать и внедрить в
производственный процесс технического обслуживания и ремонта
локомотивов: СЕТЕВОЙ ГРАФИК
РЕМОНТА ЛОКОМОТИВОВ В
СЕРВИСНЫХ ЛОКОМОТИВНЫХ ДЕПО (СЛД) ООО «ТМХ-Сервис» (далее
по тексту – «Сетевой график», «Система»).
Необходимость
разработки
и
внедрения
дополнительного
к
существующим или разрабатываемым информационным системам и
автоматизированным рабочим местам (АРМ) объясняется не только
возросшими объемами работы компании, а необходимостью решения ряда
актуальных задач, основными из которых на сегодняшний момент являются:
1. Обеспечение выполнения основных производственных показателей:
содержание исправного парка локомотивов в эксплуатации, обеспечение
пробега
планового пробега локомотивов и КТГ (иных показателей
надежности), обеспечение безопасности движения, межремонтных
нормативов пробега, планов ремонта.
2. Повышение эффективности производства, в первую очередь, за счет
снижение издержек (затрат на все виды используемых в производственном
процессе ресурсов).
Важно отметить, что решение одной задачи усложняет решение другой существенными обстоятельствами, влияющими (затрудняющими) на решение
стоящих задач являются:
 переходный период
(передача
управления локомотиворемонтным
комплексом от РЖД сервисной компании);
 отсутствие объективной оценки состояния переданных в управление
ресурсов (состояние основных и оборотных средств ремонтного
комплекса, квалификация персонала и т.п.), в том числе риски
несоответствия
переданных
ресурсов
по
количественному
и
качественному показателям, поставленным перед компанией задачам;
 отсутствие или несоответствие реальному состоянию дел нормативных
материалов (справочников) – каталогов, норм расхода, норм трудоемкости,
технологических карт и инструкции и т.п.;
 ограниченные финансовые ресурсы компании.
-5-
Следствием перечисленных обстоятельств являются низкое качество
управления
производственным
процессом
на
уровнях
сервисного
локомотивного депо (СЛД) и филиалов. Основным способом решения стоящих
перед компанией задач является повышение качества управления
производственными процессами на уровнях СЛД и Филиалов, в т.ч. за счет
оценки состояния имеющихся ресурсов, задействованных в производственном
процессе, а так же точечное инвестирование в повышение их качества (в
первую очередь критически значимых ресурсов). Сетевой график – инструмент
управления, позволяющий производственному персоналу на уровне мастера,
старшего мастера, заместителя начальника депо по ремонту, начальника отдела
ремонта филиала и др. решать сложные производственные задачи.
Ключевой особенностью создаваемой согласно настоящим ТТ системы
должна стать мотивация ремонтного персонала на автоматический ввод в
информационную систему данных о состоянии (начале и окончании)
технологических операций путём открытия и закрытия нарядов на оплату работ
с привлечением мастера или бригадира исключительно как контролера
фактического выполнения работ ремонтным (подчиненным персоналом).
Полученная таким образом объективная информация, обрабатываемая по
соответствующим алгоритмам, позволит реализовать предполагаемый
функционал системы.
В первой главе ТТ поставлена задача проектирования, дан обзор
программных аналогов решаемой задачи создания системы «Сетевого график».
Глава важна для понимания миссии Системы, в т.ч. при сопоставлении с
существующими аналогами, с накопленным отечественным и мировым
опытом.
Во второй главе описан текущий уровень автоматизации и
информатизации технологических процессов в ООО «ТМХ-Сервис». Глава
необходима для точного позиционирования Сетевого графика в ERP-системе
компании.
В третьей главе сформулированы собственно технические требования
(ТТ) к системе управления технологическим процессом ТО и Р локомотивов – к
сетевому графику. Ключевым является раздел 3.8.
В четвёртой главе
описан порядок управления разработкой и
внедрением проекта «Сетевой график». Важен для понимания порядка
дальнейших действий по созданию Системы.
-6-
В пятой главе кратко сформулирована модель управления ТМХ-Сервис
при внедрении в её работу Сетевого графика. Глава является вспомогательной и
позволяет быстро познакомится с предлагаемым к разработке проектом.
-7-
ПРИМЕЧАНИЕ
Далее по тексту ключевая информация и важные комментарии будут
приводиться в выделенных цветом прямоугольниках
ПРИМЕЧАНИЕ
Далее по тексту термины «Информационно-управляющая система
технологических процессов технического обслуживания и ремонта
локомотивов», «Сетевой график» и «Система» следует рассматривать как
синонимы.
Встречающиеся в документе названия программных продуктов,
продукции, оборудования, фирм и др. являются зарегистрированными
товарными знаками соответствующих компаний.
При использовании материала настоящей публикации ссылки на
первоисточник обязательны.
© ООО «ТМХ-Сервис», 2015 г.
-8-
1. ПОСТАНОВКА ЗАДАЧИ ПРОЕКТИРОВАНИЯ
1.1. МИССИЯ СИСТЕМЫ
В 2014 году локомотиворемонтный комплекс ОАО «РЖД» перешёл на
полное сервисное обслуживание локомотивов. Ответственность за техническое
состояние локомотивов теперь несут сервисные компании, крупнейшей из
которых является ООО «ТМХ-Сервис» (далее по тексту – ТМХ-Сервис).
Численность компании превышает 48 тысяч человек. Более 23 тысяч секций
локомотивов ОАО «РЖД» переданы на полное сервисное обслуживание (ПСО)
в ТМХ-Сервис. Компания совместно с ОАО «РЖД» владеет девятью
локомотиворемонтными заводами «Желдореммаш». Для управления таким
крупным промышленным комплексом нужна автоматизация технологических
процессов, в т.ч. с использованием информационно управляющих систем.
ТМХ-Сервис имеет достаточно мощную информационную систему,
позволяющую автоматизировать управление основными ресурсами компании:
финансы, кадры, склад и др.
Создаются информационные системы
мониторинга технического состояния и режимов эксплуатации локомотивов,
управления жизненным циклом технической документации локомотивов и др.
В настоящее время остаётся не реализованной автоматизированная система
управления
собственно
технологическим
процессом
технического
обслуживания и ремонта локомотивов (ТО и Р), основу которого должен
составить автоматизированный сетевой график ТО и Р.
Настоящие
Технические Требования (ТТ) формулируют основные требования к Сетевому
графику как комплексу работ с целью объявления конкурса на разработку
программного обеспечения.
Миссия ТМХ-Сервис заключается в обеспечении надёжной работы
локомотивов в процессе тяги поездов на железных дорогах России. При этом
компания является коммерческой организацией, основным источником доходов
которой является эксплуатационный пробег локомотивов: техническое
обслуживание и ремонт локомотивов (в отличие от ранее существовавшей
системы бюджетирования ТО и Р) относятся к затратам, сокращение которых
приводит к увеличению прибыли компании. Сетевой график сервисных
локомотивных депо (СЛД) позволит во взаимодействии с другими
информационными системами компании получить следующие эффекты
(Рис.1.1):
-9-
- 10 -
1.1.1 Сокращение складских запасов за счёт использования алгоритмов
планирования запасных частей и материалов (в т.ч. с использованием
математического аппарата теории очередей, сетевого планирования,
методов статистического и факторного анализа и др.).
1.1.2 Сокращение простоя на ремонте и в ожидании ремонта за счёт
реализации прозрачного сетевого планирования с возможностью
интерактивной корректировки хода работ.
1.1.3 Повышение надёжности локомотивов за счёт автоматизации контроля
соблюдения технологических процессов.
1.1.4 Оптимизация использования трудовых ресурсов в процессе ТО и Р.
1.1.5 Создание
прозрачной
информационной
системы
управления
технологическими процессами.
ТРЕБОВАНИЕ 1
Система управления технологическими процессами технического
обслуживания и ремонта локомотивов (ТО и Р) должна привести к
существенному повышению эффективности работы ТМХ-Сервис с
получением экономического эффекта.
Рисунок 1.1 – Ключевые показатели качества работы ТМХ-Сервис
- 11 -
1.2. АСУ ТП
Автоматизированная система управления технологическим процессом
(АСУ ТП) – это одно из основных направлений информатизации и
автоматизации промышленных предприятий. АСУ ТП представляет собой
группу технических и программных средств, предназначенных для
автоматизации управления технологическим оборудованием на промышленных
предприятиях. Является частью общей автоматизированной системы
управления предприятием: применительно к настоящим ТТ – АСУ ТМХСервис.
На Рис.1.2 показан пример «классической» АСУ ТП. В СЛД в конечном
счёте должна быть создана аналогичная система: данные бортовых датчиков и
микропроцессорных систем управления (МСУ), автоматизированных систем
технического диагностирования и испытательных стендов (АСТД), датчики
депо (SMART-предприятие) и др. – всё это должно в перспективе объединить
автоматизированные и информационные системы в единую АСУ ТМ СЛД.
Основа системы – Сетевой график ремонта.
Рисунок 1.2 – Пример «классической» АСУ ТП
(по данным http://tms-samara.ru/Files/pr_2010_UPSV_bulat.jpg)
ТРЕБОВАНИЕ 2
Сетевой график ремонта позиционируется как ключевой элемент АСУ ТП
- 12 -
1.3. ДИАГРАММЫ ГАНТА
1.3.1. Требование визуализации управления
Основу АСУ ТП составляет Сетевой график - динамическая модель
производственного процесса, отражающая технологическую зависимость и
последовательность выполнения комплекса работ, увязывающая их
планирование и свершение во времени с учётом затрат ресурсов и стоимости
работ с выделением при этом узких (критических) мест.
Управление технологическим процессом – это комплекс работ. Однако
все их можно рассматривать как приложение к основе сетевого планирования –
визуальному отражению хода технологического процесса (например, по
Рис.1.2). Визуализация технологических процессов очень распространена в
АСУ ТП и позволяет существенно повысить эффективность управления через
визуальную систему поддержки принятия решений (СППР). Сетевой график
также должен быть наглядно визуализирован.
На Рис.1.3 представлен пример визуализации графика работ в виде графа.
Такое представление информации является очень наглядным, однако в ТТ не
является обязательным, что будет обосновано в последующих разделах
Рисунок 1.3 – Визуализация сетевого графика методом графов
(http://privetstudent.com/referaty/referaty-transport/679-obschie-principy-i-stadiiproektirovaniya-zheleznyh-dorog.html )
ТРЕБОВАНИЕ 3
Сетевой график должен обязательно иметь комплексную визуализацию.
Желательна возможность просмотра сетевого графика в виде графа.
- 13 -
1.3.2. Диаграммы Ганта
Одним из самых популярных способов визуализации процесса
управления являются диаграммы Ганта (англ. Gantt chart): столбчатая
диаграмма, предложенная Генри Гантом в начале 20 века именно для
управления технологическими процессами промышленного предприятия
(ткацкой фабрикой). В настоящее время диаграммы Ганта – одно из самых
популярных средств визуального управления технологическими процессами
(Рис.1.4, 1.5).
Диаграмма Ганта представляет собой отрезки, размещенные на
горизонтальной шкале времени. Каждый отрезок соответствует отдельному
проекту, задаче или подзадаче. Проекты, задачи и подзадачи, составляющие
план, размещаются по вертикали (каждой строке соответствует одно действие,
операция). Начало, конец и длина отрезка на шкале времени соответствуют
началу, концу и длительности задачи. На Рис.1.4 показан пример диаграммы
Ганта: каждая операция изображена синим квадратом, длина которого
пропорциональна продолжительности операции. Стрелки показывают: какая
операция после какой может выполняться.
Заход в депо
Приемка
Длина прямоугольника пропорциональна
длительности работ
Анализ ТУ-152
АРМ МСУ
Постановка в цех
Стрелка указывает
последовательность работ
План работ
Каждому прямоугольнику
соответствует одна операция. В
одной строке может быть только
один прямоугольник (операция)
ТО и Р
Сдача
Рисунок 1.4 – Принцип сетевого планирования в диаграммах Ганта
ТРЕБОВАНИЕ 4
Функциональную и графическую основу управления технологическими
процессами ТО и Р локомотивов должны составлять диаграммы Ганта
- 14 -
1.3.3. Комплексное использование диаграмм Ганта
Диаграммы Ганта (см.Рис.1.4, 1.5) менее наглядны, чем графы
(см.Рис.1.3), но гораздо удобней в управлении за счёт возможности их
комплексного использования, крепления данных к каждой операции (за счёт
резервирования всей строки за операцией), «сверления» и др. Диаграммы Ганта
позволяют
менеджерам
всех
уровней
визуально
контролировать
производственные процессы на нужном уровне детализации, при
необходимости производить «сверление»: получение диаграммы Ганта как
расшифровку одного из квадратов (в примере по Рис.1.4 – это, прежде всего,
блок операций «ТО и Р»). Комплексное использование возможностей принципа
диаграмм Ганта – главное их достоинство (Рис.1.5).
Диаграммы Ганта в Сетевом графике должны позволять:
1.3.3.1. Представлять технологический процесс в целом (от захода локомотива
в депо до его выхода), укрупненно и с точность до технологической
операции. Переход от одного уровня к другому должно быть возможно
в интерактивном режиме, в т.ч. путём двойного щелчка мышкой (double click) по квадрату интересующей операции операции .
1.3.3.2. Выводить в строке операции числовых и текстовых данных,
касающихся этой операции: время, стоимость, трудозатраты и др.
1.3.3.3. Позволять настраивать данные
индивидуальных настроек.
по
п.1.3.3.2
и
сохранения
1.3.3.4. Одновременно отображать типовой сетевой график, текущий план и
фактическое исполнение: все три, частично или один из них.
1.3.3.5. Распечатывать график.
1.3.3.6. Экспортировать данные в MS Excel? MS Project.
1.3.3.7. Обеспечивать информационное сопровождение с СУБД.
1.3.3.8. Иметь интерактивные возможности поддержки принятия решений.
1.3.3.9. Реализовывать другую функциональность, свойственную диаграммам
Ганта, в т.ч. реализованным в пакете программ MS Project
- 15 -
а - http://infostart.ru/public/100480/
б - http://infostart.ru/public/100480/
Рисунок 1.5 – Примеры комплексного использования диаграмм Ганта
ТРЕБОВАНИЕ 5
Диаграммы Ганта Сетевого графика должны иметь привязку ко всем
необходимым для управления данным СУБД, иметь возможность
«сверления», адаптации к решаемым задачам (например, вывод плановых и
фактических показателей, изменение плановой продолжительности операции
и др.)
- 16 -
1.4. ОБЗОР РЫНКА (АНАЛОГИ)
1.4.1. Уровень эксклюзивности задачи
Программное обеспечение для автоматизации сетевого планирования и
управления
промышленным
предприятием
является
достаточно
распространенным на рынке программ автоматизации технологических
процессов. Поэтому поставленную задачу автоматизации управления ТО и Р в
СЛД ТМХ-Сервис с определенным приближении можно считать типовой
задачей.
1.4.2. SAP R/3
Наиболее известным аналогом можно считать модули PM и QM
программного комплекса SAP R/3. В ОАО «РЖД» для создания АСУ ТП на
базе этих модулей разрабатывается пакет программ «ТОРО». Несмотря на ряд
преимуществ модулей PM и QM их внедрение имеет смысл только при
реализации комплексного управления (т.н. ERP-системы) на базе SAP R/3. В
ТМХ-Сервис в качестве базовой информационной системы принят пакет
программ 1С.
1.4.3. 1С
1С является в значительной степени отечественным аналогом пакета
программ SAP R/3. Более того, 1С принят в качестве базовой при
информатизации и автоматизации процессов управления в ТМХ-Сервис.
Рисунок 1.6 – Модель управления производственными процессами в 1С
( http://autoworks.com.ua/verxnie-urovni-asu-tp/struktura-sovremennoj-integrirovannoj-asu/ )
- 17 -
Имеется в 1С и модуль управления проектами, позволяющий реализовать
сетевое планирование, в т.ч. с использованием визуализации процессов в виде
диаграмм Ганта (см.Рис.1.5).
1.4.4. MS Project
Самым популярным в мире пакетом программ для реализации диаграмм
Ганта является программа управления проектами Microsoft Project, входящая в
расширенный пакет программ Microsoft Office. Пакет программ позволяет
реализовать любую конфигурацию системы, является самым гибким и
универсальным пакетом программ. MS Project не привязан к конкретным
задачам управления и требует полного цикла разработки технологии.
1.4.5. IBM Maximo
Достаточно популярен в мировой практике пакет программ IBM Maximo,
созданный для управления ремонтом и техническим обслуживанием
производственных активов. Состоит из шести основных функциональных
блоков управления: активами, обслуживанием, сервисами, снабжением,
материальными запасами и контрактами. Пакет IBM Maximo больше «заточен»
не под АСУ ТП, а под управление предприятием в целом (Enterprise Asset Management - EAM). Как и SAP R/3 пакет представляет интерес при комплексном
внедрении.
1.4.6. EAM-системы
Для
управления
ремонтом
и
техническим
обслуживанием
производственных активов существует ряд универсальных пакетов программ
(EAM-системы), имеющих комплексный функционал (планирование ремонтов,
складское снабжение, договорные отношения, учет активов и т.д.),
охватывающих все бизнес-процессы ремонта и обслуживания активов
предприятия. Однако настройка этих систем под задачи ТМХ-Сервис может
оказаться по трудоёмкости сопоставимой с созданием специализированной
системы. Более того, EAM-системы больше ориентированы на управление
предприятием в целом - Enterprise Asset Management.
1.4.7. Органайзеры
На рынке программного обеспечение существует большое число
программ, позволяющих планировать как работу специалиста, так и компании в
целом. Примером может служить программа MS Outlook. Технологию online
планирования можно считать глубоко проработанной, поэтому использования
опыта уже существующих систем обязательно
- 18 -
1.4.8. CLARIS Solutions
В качестве специализированной системы управления технологическими
процессами локомотиворемонтного предприятия могут служить разработки
компании CLARIS Solutions (Германия), предлагающей системные решения для
железнодорожных компаний (Рис.1.7): электронные паспорта локомотивов,
мониторинг их технического состояния, управление материалами и др.
Компания готова адаптировать своё программное обеспечение к задачам любой
локомотиворемонтной компании за 30-40 недель.
а - Опыт реализации АСУ ТП компании
б – Управление проектами
Рисунок 1.7 – Комплексные решения от Claris Solutions
(из презентации компании)
- 19 -
1.4.9. АСУ ЦТР
Опыт создания АСУ ТП имеется и в ОАО «РЖД» - в Отраслевом Центре
Внедрения (ОЦВ): созданы бета-версии сетевого графика и АРМ Мастера и
несколько других программных модулей, привязанных к программе АСУТ.
Совокупность работ по АСУ ТП ремонтных локомотивных депо имеет общее
название «АСУ ЦТР». Имеется опыт эксплуатации системы.
1.4.10. Сетевой ТЧР Нижнеудинск
В Иркутском государственном университете путей сообщения (ИрГУПС)
при участии Отраслевого центра внедрения (ОЦВ) был разработан и реализован
Сетевой график ремонта для ремонтного локомотивного депо «Нижнеудинск».
График позволял отслеживать ремонт локомотивов, поставленных на плановые
виды ремонта: ТР-1 и ТР-2.
Сетевой график ИрГУПС позволял в режиме online контролировать
выполнение ремонта с выводом информации на экран монитора в цеху депо, а
также передавать через СПД РЖД и отражать сетевой график в Дирекции по
ремонту ТПС ОАО «РЖД». График сопровождался вручную оператором депо.
1.4.11. Опыт Астанинского локомотиворемонтного депо
Интересный технологический опыт накоплен в Астанинском
локомотиворемонтном депо, где внедрена информационная система «СЕРВИС»
разработки ТОО «Камкор Менеджмент». Система применяется как инструмент
диспетчеризации и фиксирования текущей ситуации по эксплуатационному
парку локомотивов серий 2ТЭ10, ТЭП70, ТЭМ2, ВЛ40, ВЛ60 и ВЛ80. Система
включает в себя мониторинг проводимого сервисного обслуживания в разрезе
видов работ, качества их проведения, получения аналитических выходных
форм, а также сводных ведомостей выполненных сдельных работ.
ТРЕБОВАНИЕ 6
Т.к. рынок систем автоматизации управления технологическими процессами
(АСУ ТП) достаточно большой, то необходимо выбрать уже существующую
платформу программирования, а выбор Исполнителя работ по созданию АСУ
ТП ТМХ-Сервис должен происходить на конкурсной основе
- 20 -
2. ИНФОРМАЦИОННЫЕ СИСТЕМЫ ТМХ-СЕРВИС
2.1.
АСУ ТМХ-СЕРВИС
Основу системы управления ТМХ-Сервис составляет пакет программ
российской компании «1С», специализирующаяся на разработке, продаже и
поддержке компьютерных программ и баз данных делового назначения
«1С:Предприятие», «1С:Бухгалтерия», «1С:Зарплата», «1С:Кадры» и др.
(Рис.2.1). Пакет программ хорошо известен на рынке программного
обеспечения (ПО) и в дополнительных пояснениях не нуждается.
Рисунок 2.1 – 1С в ТМХ-Сервис
В ТМХ-Сервис уже автоматизировано управление складами, поставками,
персоналом, финансами. Решаются задачи управления конструкторской и
технологической подготовкой производства, номенклатурой производства (в
т.ч. систему управления каталогом) и оборудованием. Остаются не решенными
задачи
оперативного
планирования
управления
производственными
процессами и его потребностями в ресурсах.
За разработку 1С-приложений отвечает департамент информационнотехнической поддержки ТМХ-Сервис.
ТРЕБОВАНИЕ 7
Сетевой график должен быть состыкован и использовать данные системы
управления ТМХ-Сервис, построенной на базе пакета программ «1С»
- 21 -
2.2. ИНТЕРНЕТ
ТМХ-Сервис обслуживает локомотивы во всех регионах России, поэтому
имеет распределенную систему правления: в состав компании входят 9
филиалов (Рис.2.2): Дальневосточный (Хабаровск), Амурский (Комсомольскна-Амуре), Нижнеудинский (Нижнеудинск, Иркутск), Братский (Братск,
Красноярск), Западно-Сибирский (Новосибирск, Екатеринбург), Южный
(Воронеж), Западный (Нижний Новгород), Северо-Западный (Санкт-Петербург)
и Московский (Москва). Всего в 9 филиалов входит 93 сервисных
локомотивных депо, более 100 пунктов технического обслуживания
локомотивов (ПТОЛ и сервисных участков. Все подразделения ТМХ-Сервис
должны иметь единое информационное пространство. При этом
быстродействие должно обеспечивать комфортную работу в режиме online.
За разработку 1С-приложений отвечает департамент информационнотехнической поддержки ТМХ-Сервис.
Рисунок 2.2 – Филиальная сеть ТМХ-Сервис
ТРЕБОВАНИЕ 8
Сетевой график должен быть реализован как распределенная система
управления, работающая в Интернет и позволяющая реализовать удаленный
доступ к данным
- 22 -
2.3. УПРАВЛЕНИЕ НАДЁЖНОСТЬЮ ЛОКОМОТИВОВ
2.3.1. АСУНТ
В ТМХ-Сервис разрабатывается и внедряется Автоматизированная
система управления надёжностью локомотивов – АСУНТ (Рис.2.3). АСУНТ
строится с использованием международных (ISO), национальных (ГОСТ) и
корпоративных стандартов в области управления качеством, сервисным
обслуживанием, надёжностью и бережливым производством. В АСУНТ
главное внимание уделяется технологии технического обслуживания и ремонта
локомотивов, организации вертикали управления, реализации принципа
постоянного улучшения. В основу АСУНТ также положены принципы ITIL и,
прежде всего, процессы «Управление Инцидентами», «Управление
Проблемами» и «Управление Уровнем Сервиса» (Рис.2.4). В АСУНТ
инкапсулированы (по принципу «Встроенное качество») международные,
национальные и корпоративные ОАО «РЖД» стандарты в области управления
качеством, бережливого производства (Lean Production), статистического
анализа и управления надёжностью.
Для АСУНТ создаются свои программные продукты, взаимодействие с
которыми должно быть реализовано при реализации Сетевого графика
(Рис.2.5).
АСУНТ
ПРОГРАММНОЕ
ОБЕСПЕЧЕНИЕ (ПО)
ЕСМТ
Единая система мониторинга
технического состояния
локомотивов
АРМ МСУ
АРМ обработки данных МСУ
и диагностирование
(в т.ч. ЕСМ БС)
АСТД
Стационарная и переносная
диагностика
АСУЖТ, ТУ
Информационные системы
ОАО «РЖД»
(АСУТ, КАСАНТ, др.)
ТЕХНОЛОГИЧЕСКОЕ
ОБЕСПЕЧЕНИЕ
Концепция АСУНТ
Эскизный проект ЕСМТ
Эскизные проекты
АРМ МСУ и АСТД
АЛГОРИТМЫ
диагностирования
Руководства пользователей
и администраторов ПО
РЕГЛАМЕНТЫ
проведения работ
Приказы, Распоряжения,
другие нормативные документы
- 23 -
РЕСУРСНОЕ
ОБЕСПЕЧЕНИЕ
ГРУППЫ ДИАГНОСТИКИ
в подразделениях филиалов
ТМХ-Сервис
ТЕХНИЧЕСКИЕ СРЕДСТВА
Серверы, СУБД, ПК,
IT-оборудование
БАЗА ДАННЫХ
Листы регистрации инцидентов,
проблем и мероприятий,
НСИ, факторный анализ
Рисунок 2.3 – Структура работ по АСУНТ
1
ПЕРЕВОЗОЧНЫЙ ПРОЦЕСС И ЭКСПЛУАТАЦИЯ ЛОКОМОТИВОВ
ПЛАНОВОЕ ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ ЛОКОМОТИВОВ
СТАЦИОНАРНОЕ, ПЕРЕНОСНОЕ, БОРТОВОЕ ДИАГНОСТИРОВАНИЕ (АСТД)
3
2
ИНЦИДЕНТ
Нет
ITIL, ISO20000
ЭКСПЛУАТАЦИЯ
(АСУЖТ)
Зафиксирован
4
5
УПРАВЛЕНИЕ ИНЦИДЕНТАМИ
ITIL, ISO20000, 8D, Барьер и др.
ИНЦИДЕНТЫ
(ЕСМТ)
6
7
Да
Известная проблема?
Известная ошибка?
АНАЛИТИКА
(ЕСМТ)
Нет
8
УПРАВЛЕНИЕ ПРОБЛЕМАМИ
Поиск причин низкой надежности и путей ее повышения
Применение СТК1.10.003 и СТК1.05.515.1 М1.05.001, М1.05.002, М1.05.008, методик 8D,
5W, 5W2H1S и др.
9
10
Нет
Определена проблема?
Да
Известная ошибка
12
11
Можно устранить проблему?
Нет
Известная проблема
Да
13
Корректирующие мероприятия
14
15
Нет
ВАРИАНТЫ
РЕШЕНИЙ
Internet
Требуются изменения?
Да
16
УПРАВЛЕНИЕ
УРОВНЕМ СЕРВИСА
Управление KPI,
корреляционный анализ
Изменение или корректировка условий
эксплуатации и методики управления
Инцидентами и Проблемами
- 24 -
17
Рисунок 2.4 – Трёхконтурная модель управления АСУНТ ТМХ-Сервис
Первая группа программ (см.Рис.2.5, блок 1) связана с
диагностированием по данным бортовых МСУ локомотивов: МСУД, МПСУ,
МСУЭ, МСУ-ТП, МСУ-ТЭ, АСК, УСТА+УПУ, АПК «Борт», РПДА-Т, АСК
ВИС, УСАВП и др. В ТМХ-Сервис совместно с производителями МСУ ведётся
разработка Автоматизированных рабочих мест для расшифровки данных
бортовых МСУ и автоматизированного поиска инцидентов (АРМ МСУ –
блок1.1). АРМ МСУ внедряются в работу групп диагностики СЛД (блок 1.3).
По мере накопления опыта диагностирования по данным АРМ МСУ в
ТМХ-Сервис ведётся разработка алгоритмических защит (блок 1.2) для
принципиального исключения возможности допускать опасные режимы
эксплуатации со стороны машинистов (блок 1.4). Алгоритмические защиты
разрабатываются разработчиками МСУ по техническим заданиям ТМХ-Сервис,
согласованным с ОАО «РЖД». Замена программ на локомотивах ведётся
силами ТМХ-Сервис по согласованию с балансодержателями локомотивом.
Диагностические возможности МСУ ограничены, что приводит к
необходимости использования деповских стационарных и переносных
автоматизированных систем технического диагностирования (АСТД) – прежде
всего станций реостатных испытаний и вибродиагностики (блок 2).
Для управления процессами устранения инцидентов, проблем и
повышения уровня сервиса создаётся информационно-управляющая единая
система мониторинга технического состояния и режимов эксплуатации
локомотивов – ЕСМТ (блок 3). Разработка и сопровождения и программного
обеспечения ЕСМТ осуществляется компанией «АВП Технология» (блоки 3.1 –
3.3). Внедрение ЕСМТ идёт поэтапно: в группах диагностики (блок 3.4), в СЛД
в целом (блок 3.5) в центрах Мониторинга эксплуатации локомотивов (блок
3.7) и т.д. Описание ЕСМТ приведено в следующем разделе.
Сетевой график является логическим продолжение работ по АСУНТ
(блок 4) и реализуется как основа АСУ ТП СЛД, связывая при этом системы
АСУНТ и АСУ ТМХ-Сервис (блок 5).
ТРЕБОВАНИЕ 9
Сетевой график должен поддерживать технологические процессы АСУНТ на
уровне оперативного управления ТО и Р локомотивов в условиях СЛД.
- 25 -
АСУНТ
Автоматизированная система управления надёжностью локомотивов ТМХ-Сервис
1.1
ВНИКТИ (Коломна): тепловозы 2ТЭ116Ув/и, ТЭП70БС, ТЭМ18Дв/и.
В будущем: 2ТЭ25А
Разработка и доработка АРМ МСУ
для автоматизированной
расшифровки данных МСУ
1
Диагностирование по
данным бортовых
МСУ локомотивов:
МСУД, МПСУ, МСУЭ,
МСУ-ТП, МСУ-ТЭ,
АСК, УСТА+УПУ,
АПК «Борт», РПДА-Т,
АСК ВИС, УСАВП и др.
ДЦВ Красноярской ж.д.: электровозы ВЛ80р, ВЛ85
ЛЭС (Новочеркасск): электровозы 2/3ЭС5К, ЭП1М
1.3
Внедрение АРМ МСУ
в группах диагностики СЛД
(2013 – 2015)
АВП-Т: локомотивы с автоведением (УСАВП) и системами учёта
топлива (РПДА-Т)
НИИТКД: тепловозы с системой учёта топлива АПК «Борт»
1.2
Разработка алгоритмов защиты от
опасных режимов через
программные средства МСУ
1.4
Замена на локомотивах программ МСУ на
доработанные с алгоритмической защитой
(2014-2016)
Передача АСТД на аутсорсинг
(2015 – 2016)
2
Диагностирование по
данным деповских
автоматизированных
систем (АСТД):
«КИПАРИС»,
«ПРОГНОЗ»
ВНИКТИ (Коломна): разработка алгоритмических защит МСУ-ТЭ, МСУТП и УСТА тепловозов ТЭП70БС, 2ТЭ116У, 2ТЭ10МК, ТЭМ18Д и др.
ДЦВ Красноярской ж.д.: разработка защит МСУЭ электровозов ВЛ80р и
в для всех электровозов переменного тока с ВИП.
ЛЭС (Новочеркасск): разработка защит МСУД электровозов с ВИП
серий «Ермак» и ЭП1М
2.1
АВП-Т: на разработка защит УСАВП локомотивов ТЭП70 и ВЛ80С
НИИТКД (г. Омск): доработка программ автоматизации реостатных испытаний «КИПАРИС» и
вибродиагностирования «ПРОГНОЗ» для автоматизированной передачи данных в ЕСМТ о
результатах испытаний.
АВП-Т: стыковка ЕСМТ с АСТД и обработки данных в рамках инвест-программы АВП-Т
2.2
2.3
3.1
АВП-Т: разработка ЕСМТ по инвест-программе АВП-Т (2013 – 2015 гг.)
3
Разработка
информационноуправляющей системы
мониторинга
локомотивов
ЕСМТ
3.4
ВНЕДРЕНИЕ ЕСМТ
в работу групп диагностики
(2013-2015)
3.2
АВП-Т: сопровождение эксплуатации ЕСМТ в СЛД, сопровождение сервера ЕСМТ
3.3
АВП-Т: разработка локомотивной модели в ЕСМТ с пробегами (по инвест-программе АВП-Т)
3.5
ВНЕДРЕНИЕ ЕСМТ
в работу СЛД для управления
инцидентами и проблемами
(2014-2015)
3.6
ВНЕДРЕНИЕ ЕСМТ
в работу СЛД для сетевого
планирования и контроля
производственных процессов
(2015 – 2016)
3.7
ВНЕДРЕНИЕ ЕСМТ
в работу Центров Мониторинга
эксплуатации локомотивов
(при ЦУТР РЖД)
(2015)
4
Сетевой график ремонта локомотивов в СЛД
(Разработчик определяется путём проведения конкурса)
5
ERP-система ТМХ-Сервис (АСУ ТМХ-Сервис) на базе пакета программ 1С
Локомотивная модель, НСИ
Электронная технологическая и техническая нормативныая документация
Другие информационные системы ТМХ-Сервис
Рисунок 2.5 – Структура работ АСУНТ и место Сетевого графика
- 26 -
2.3.2. ЕСМТ
Для автоматизации функционирования АСУНТ и реализации принципа
«встроенное качество» в ТМХ-Сервис при участии компании «АВП
Технология» разработана информационно-управляющая компьютерная сетевая
система ЕСМТ – Единая система мониторинга технического состояния и
режимов эксплуатации локомотивов во взаимодействии с АСУЖТ. ЕСМТ
является инструментом для достижения целей АСУНТ, информационной
основой Мониторинга и АСУНТ в целом.
Принцип работы ЕСМТ заключается в следующем: по каждому
инциденту (ситуации, отличной от нормальной, т.е. возникновению ситуации,
препятствующей нормальной эксплуатации локомотивов), в системе
фиксируется «Инцидент» в виде Листа регистрации инцидента (ЛРИ).
Информация заносится в ЛРИ на протяжении устранения Инцидента –
«жизненного цикла Инцидента» через специальные экранные формы. Эта
информация позволяет управлять устранением Инцидента, контролировать
эффективность выполнения работ, а в дальнейшем – управлять Проблемами и
Уровнем Сервиса.
Внедрение ЕСМТ как информационной подсистемы АСУНТ позволяет:





управлять ходом расследования и устранения инцидентов;
автоматизировать формирование актов, протоколов, других документов;
контролировать ход устранения инцидентов;
формировать структурированную базу данных об инцидентах;
производить многофакторный анализ с выявлением системных проблем,
затратных технологий, узких мест, слабых и недисциплинированных
работников и многое другое, т.е. – управлять проблемами согласно ITIL;
 управлять корректирующими мероприятиями.
ТРЕБОВАНИЕ 10
Сетевой график должен позволять отслеживать жизненный цикл любого
инцидента: ситуации, отличной от нормальной эксплуатации локомотивов:
плановые ТО и Р, отказы и неплановые ремонты, замечания машинистов,
предотказные состояния и др.
ТРЕБОВАНИЕ 11
Сетевой график должен являться стыковочной информационной системой
между ЕСМТ и АСУ ТМХ-Сервис, позволяющей автоматизировать
контроль и управление технологическими процессами восстановления
работоспособности и ресурса локомотивов.
- 27 -
ЕСМТ
Единая информационно-управляющая систем мониторинга технического состояния и
режимов эксплуатации локомотивов
Основное окно ЕСМТ: окно управления инцидентами (2013)
Окно листа регистрации инцидентов (2013 – 2014)
Модуль взаимодействия с АРМ МСУ (2013 - 2014)
Модуль взаимодействия с АРМ АСТД (2014 - 2015)
Модуль формирования актов и писем (2014 – 2015)
Модуль эскалации проблем (2015)
Модуль управления ЗИП (2015)
Модуль рейтингов (2015)
Модуль рекламационной работы (2015)
АРМ приемки локомотива «Планшетник» (2016)
1
УПРАВЛЕНИЕ ИНЦИДЕНТАМИ
Мониторинг технического состояния
локомотивов по всем возможным
источникам информации
Регистрация инцидентов в ЕСМТ в виде
листов регистрации инцидентов
(Группы диагностики)
2
Получение данных из АСУТ-Т (2013 – 2014)
Получение данных из АСОУП (2015)
Получение из КАСАНТ (2015)
Передача данных в АСУТ-Т (2015)
Передача данных в КАСАНТ (2016)
ВЗАИМОДЕЙСТВИЕ С АСУЖТ
Обмен информацией между ЕСМТ и
информационными системами
ОАО «РЖД» (АСУЖТ)
Окно Локомотивный парк (2014 – 2015)
Окно событий с локомотивами по данным АСОУП (2015)
Окно анализа суточных пробегов локомотивов (2014 - 2015)
Окно анализа среднесуточных пробегов локомотивов (2015)
Лист регистрации заходов локомотива в депо - ЛРЗ (2015)
Модуль оперативного планирования ТР (2015)
Модуль прогнозного планирования ТР (2015)
Модуль управления отказами локомотивов (2015)
Модуль контроля выдачи локомотивов после ТО и Р (2015)
3
МОНИТОРИНГ ЭКСПЛУАТАЦИИ
ЛОКОМОТИВОВ
Контроль пробегов локомотивов,
оперативное и прогнозное
планирование, управление
восстановлением после отказов,
контроль выдачи локомотивов
(Центры Мониторинга при ЦУТР)
4
УПРАВЛЕНИЕ ПРОБЛЕМАМИ
Анализ причин инцидентов, поиск узких
мест, принятие корректирующих
мероприятий и воздействий
(Руководство СЛД, филиалов и ИА)
Модуль стандартных отчётов, в т.ч. ТО-15 (2013-2015)
Конструктор отчётов (2014)
Модуль СМК (система менеджмента качества) для работы с
ключевыми показателями качества - KPI (2014-2015)
Портал АСУНТ – ASUNT.ru, ТОП-100. Форум проблем.
Библиотека. Информационная поддержка работы в ЕСМТ и
АСУНТ в целом (2014 - 2015)
Модуль статистической обработки данных (2014 - 2015)
Модуль факторного анализа (2015)
Лист регистрации проблем - ЛРП (2015)
Окно управления проблемами (2015)
5
Окно администратора (2013 – 2015)
АДМИНИСТРИРОВАНИЕ
Сопровождение работы ЕСМТ
Модуль управления ролями (2014 - 2015)
Модуль аудита листов регистрации (2015)
6
ИНТЕРАКТИВНОЕ УПРАВЛЕНИЕ
Поддержка принятия решений,
рассылка, автоматический контроль
состояния работ
7
ПЕРСПЕКТИВНЫЕ
НАПРАВЛЕНИЯ
Модуль SMS и E-mail рассылок (2015)
Модуль интерактивного управления (2015)
Система поддержки принятия решений (СППР) (2015-2017)
Модуль контроля принятия решений (2015-2016)
Электронная подпись (2015-2016)
Прогнозирование потребности в ресурсах (2015 - 2016)
Управление рисками (2016)
Взаимодействие с АСУ «СЕТЕВОЙ ГРАФИК РЕМОНТА»
- 28 -
Рисунок 2.6 – Функциональность ЕСМТ
2.3.3. Мониторинг эксплуатации локомотивов
На базе ЕСМТ создаётся система Мониторинга эксплуатации
локомотивов, для чего в ЕСМТ имеется специальный Модуль Мониторинга
(ММ). ММ получает информацию из АСУЖТ (АСОУП), обрабатывает её и
формирует модель эксплуатации локомотивов. Модуль Мониторинга реализует
следующую функциональность:












формирование локомотивной модели в СУБД ЕСМТ;
получение и обработка данных из АСОУП;
сохранение в локомотивной модели данных из АСОУП;
сопровождение нормативно-справочной информации (НСИ), связанной с
эксплуатацией, техническим обслуживанием и ремонтом локомотивов;
расчёт суточных параметров работы локомотива;
мониторинг суточных параметров локомотивов.
прогноз постановки локомотива на ТО и Р (декадные, месячные,
квартальные и др. планы постановки на ремонт);
оперативное (Суточное и трёхсуточное) планирование постановки
локомотивов на ремонт;
управление неплановыми ремонтами;
контроль выдачи локомотивов из СЛД;
взаимодействие с ИСУЖТ (или другими системами автоматизации работы
ЦУТР);
ведение отчётности.
Основные пользователи ММ ЕСМТ – Центры мониторинга эксплуатации
локомотивов, создаваемые ТМХ-Сервис при центрах управления тяговыми
ресурсами ОАО «РЖД». Центры мониторинга отслеживают работу
локомотивов за пределами СЛД, планируют постановку локомотивов на
плановые и неплановые виды ремонтов и ТО в СЛД. Сетевой график
отслеживает проведение ТО и Р непосредственно в СЛД.
ТРЕБОВАНИЕ 12
Сетевой график должен функционировать
Локомотивной моделью ЕСМТ.
- 29 -
во
взаимодействии
с
- 30 -
1
АСУЖТ: АСОУП, ГИД «Урал», АСУТ-Т. ИСУЖТ и др.
Формирование информации и работе, дислокации, пробеге и коде состояния
локомотива
Сообщения АСОУП в режиме online
2
ЕСМТ
Взаимодействие с АСОУП. Сбор исходных данных о работе локомотивов
3.1
Событие N
Событие 2
Событие 1
Серия, номер
Код события
Пробег
Данные о поезде
Другие данные
3.2
3.3
Формируется как база данных,
каждая запись которой
соответствует одному
сообщению из АСОУП.
Хранится год.
События с
локомотивами
4
ЕСМТ
Ежедневный пересчёт данный о событиях локомотивов в карточки суточной
работы локомотива с данными о пробеге, работе и времени состояния в каждом
из возможных состояний
5.1
Работа за сутки 3
Работа за сутки 2
5.2
Работа за сутки 1
Серия, номер
Пробег
работа т*км бр
Время в минутах нахождения в
каждом из возможных кодов
состояния
Просмотр исходных данных
АСОУП
Формируется как база данных,
каждая запись которой
соответствует данным о работе
одного локомотива за сутки,
рассчитанная по данным записей
о событиях в АСУОУП
Суточная работа
локомотива
6
ОКНО СОБЫТИЙ
5.3
7
ОКНО ПРОБЕГОВ
ЛОКОМОТИВА
Работа с данными (карточками)
о суточной работе локомотива
8
ОКНО СТАТИСТИКИ
ПРОБЕГОВ ЛОКОМОТИВА
Работа с агрегированными
данными и статисткой работы
локомотивов за заданный
период времения
Рисунок 2.2 – Модуль мониторинга эксплуатации локомотивов ЕСМТ
- 31 -
2.4. МОДЕЛИ И ТЕХНОЛОГИЧЕСКИЕ КАРТЫ
При обнаружении отказа мастеру, слесарю и/или электромеханику
необходимо правильно идентифицировать отказавшую деталь или узел. При
этом заказать на складе ремонтный комплект (рем.комплект). А сам ремонт
произвести в соответствии с технологической картой. Все эти действия требуют
от исполнителя высокой квалификации. Для упрощения работы в ТМХ-Сервис
создаются соответствующие модели конструкции локомотивов, с помощью
которых работник депо может легко идентифицировать отказавший узел,
заказать рем. комплект и получить на экран монитора технологическую карту.
Взаимодействие сетевого графика с Моделями локомотивов является
обязательным условием работы.
ТРЕБОВАНИЕ 13
Сетевой график должен функционировать во взаимодействии с моделями
конструкции локомотивов.
2.5. НСИ
Для идентификации локомотивов и их узлов, места проведения работ,
деталей на складах, типа отказа и много другого в ТМХ-Сервис ведётся
соответствующая нормативно-справочная информация (НСИ). Именно НСИ
обеспечивает взаимодействие отдельных подсистем АСУ ТМХ-Сервис,
реализованных на разных платформах. Сетевой график также должен
использовать единую НСИ ТМХ-Сервис.
ТРЕБОВАНИЕ 14
Сетевой график должен функционировать с использованием единой
нормативно-справочной информации (НСИ) ТМХ-Сервис.
- 32 -
3. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ
3.1. ОБЩИЕ ТРЕБОВАНИЯ
3.1.1. Система управления технологическими процессами технического
обслуживания и ремонта локомотивов (ТО и Р) должна привести к
существенному повышению эффективности работы ТМХ-Сервис с
получением экономического эффекта.
3.1.2. Сетевой график ремонта позиционируется как ключевой элемент
АСУ ТП.
3.1.3. Сетевой график должен обязательно иметь комплексную визуализацию.
Желательна возможность просмотра сетевого графика в виде графа.
3.1.4. Функциональную и графическую основу управления технологическими
процессами ТО и Р локомотивов должны составлять диаграммы Ганта.
3.1.5. Диаграммы Ганта Сетевого графика должны иметь привязку ко всем
необходимым для управления данным, иметь возможность «сверления»,
адаптации к решаемым задачам (например, вывод плановых и
фактических показателей, изменение плановой продолжительности
операции и др.).
3.1.6. Т.к. рынок систем автоматизации управления технологическими
процессами (АСУ ТП) достаточно большой, то необходимо выбрать уже
существующую платформу программирования, а выбор Исполнителя
работ по созданию АСУ ТП ТМХ-Сервис должен происходить на
конкурсной основе.
3.1.7. Сетевой график должен быть состыкован и использовать данные
системы управления ТМХ-Сервис, построенной на базе пакета программ
«1С».
3.1.8. Сетевой график должен быть реализован как распределенная система
управления, работающая в Интернет и позволяющая реализовать
удаленный доступ к данным.
3.1.9. Сетевой график должен поддерживать технологические процессы
АСУНТ на уровне оперативного управления ТО и Р локомотивов в
условиях СЛД.
- 33 -
3.1.10. Сетевой график должен позволять отслеживать жизненный цикл любого
инцидента: ситуации, отличной от нормальной эксплуатации
локомотивов: плановые ТО и Р, отказы и неплановые ремонты,
замечания машинистов, предотказные состояния и др.
3.1.11. Сетевой график должен являться стыковочной информационной
системой между ЕСМТ и АСУ ТМХ-Сервис, позволяющей
автоматизировать контроль и управление технологическими процессами
восстановления работоспособности и ресурса локомотивов.
3.1.12. Сетевой график должен функционировать во взаимодействии с
Локомотивной моделью ЕСМТ.
3.1.13. Сетевой график должен функционировать во взаимодействии с
моделями конструкции локомотивов.
3.1.14. Сетевой график должен функционировать с использованием единой
нормативно-справочной информации (НСИ) ТМХ-Сервис
3.2. МАСШТАБИРУЕМОСТЬ
Масштабируемость - способность системы, сети или процесса
справляться с увеличением рабочей нагрузки (увеличивать свою
производительность) при добавлении ресурсов (обычно аппаратных). Система
должна позволять увеличивать производительность пропорционально
дополнительным ресурсам. Масштабируемость должна производиться без
структурных изменений системы.
Сетевой график должен позволять управлять:
3.2.1. Отдельным технологическим процессом (например, замена агрегата на
локомотиве) и его подпроцессами;
3.2.2. Группой процессов (например, техническое обслуживание или плановопредупредительный ремонт одного локомотива.
3.2.3. Заходом локомотива в сервисное локомотивное депо.
3.2.4. Работой СЛД в течение смены, суток, месяца, квартал и года.
3.2.5. ТО и Р и НР в целом по СЛД.
3.2.6. ТО и Р и НР в целом на полигоне.
3.2.7. ТО и Р и НР в целом в филиале.
3.2.8. ТО и Р и НР в целом в сервисной компании.
- 34 -
При этом должна быть обеспечена возможность «сверления»
(«проваливания», когда с элемента одного уровня сетевого графика можно
переходить на сетевой график подчиненного уровня.
3.3. ОБЪЕМ БАЗЫ ДАННЫХ
База данных Системы должна позволять выполнением ТО и Р и НР на
всём полигоне дорог, включающий в себя:
3.3.1. до двух сервисных компаний;
3.3.2. до 20 филиалов в компании;
3.3.3. до 50 полигонов;
3.3.4. до 500 линейных предприятий: депо, сервисных участков и ПТОЛ;
3.3.5. до 50 тыс. секций локомотивов;
3.3.6. до 500 секций локомотивов в одном СЛД;
3.3.7. до 300 ТО и Р и НР в одном СЛД одновременно;
3.3.8. до 90 тыс. задействованных работников депо в целом по компании;
3.3.9. до 5 тыс. человек на одном линейном предприятии;
3.3.10. до 20 уровней вложения сетевых графиков;
3.3.11. до 100 операций на каждом уровне вложения;
3.4. БЫСТРОДЕЙСТВИЕ
3.4.1. Ведение сетевого графика должно осуществляться в реальном масштабе
времени.
3.4.2. Вывод на экран Сетевого графика на экран (в т.ч. при «сверлении»)
должно происходить с задержкой не более 3 секунд.
3.4.3. Вывод на экран запрошенной стандартной отчётной формы должно
происходить с задержкой не более 10 секунд для оперативных справок
(за последние трое суток), не более 20 секунд за среднесрочный период
(за последние два месяца и менее) и не более 60 секунд для всех
остальных справок. Для нестандартных справок, запрошенных через
конструктор отчётов (SQL), время ожидания может быть увеличено в 3
раза.
- 35 -
3.5. СУБД
3.5.1. Система должна работать на СУБД «Oracle».
3.5.2. Все технические решения СУБД должны соответствовать современным
канонам построения СУБД.
3.5.3. Для организации СУБД выделяется отдельный сервер или используется
сервер ЕСМТ или 1С.
3.6. СОПРОВОЖДЕНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
3.6.1. Разработка и сопровождение жизненного цикла программного
обеспечения системы должно соответствовать международным
стандартам (ISO) в области программирования, а также рекомендациям
(best practice) комитета Software Engineering Coordinating Committee SWEBOK (Software Engineering Body of Knowledge).
3.7. СОПРОВОЖДЕНИЕ ТЕХНОЛОГИЧЕСКОГО ОБЕСПЕЧЕНИЯ
3.7.1. Разработка технологии работы системы осуществляется Заказчиком
системы или организациями, привлекаемыми Заказчиком к этой работе.
3.7.2. В разработке технологии работы системы должны быть задействованы
исполнительный аппарат (ИА), ТМХ-Сервис, филиалы и сервисные
локомотивные депо.
3.7.3. Разработка технологии должна вестись при непосредственном участии
группы главного технолога каждого из СЛД.
3.7.4. Согласование технологии работы системы определяется в техническом
задании на системы, составляемого совместно Заказчиком и
Исполнителем.
- 36 -
3.8. ФУНКЦИОНАЛЬНОСТЬ СИСТЕМЫ
3.8.1. Ведение сетевого графика ТО и Р и НР.
3.8.2. Взаимодействие с «1С Склад» в части получения материалов,
комплектующих и др. со склада для выполнения технологических
операций ТО и Р и НР.
3.8.3. Взаимодействие с «1С Зарплата» в части закрытия нарядов на
выполненные операции.
3.8.4. Взаимодействие с ЕСМТ в части планирования работ и закрытия листов
регистрации инцидентов.
3.8.5. Взаимодействие с НСИ-системами в части работы со справочниками.
Прежде всего – с технологическими картами.
3.8.6. Управление базами данными (СУБД).
3.8.7. Защитные функции и функции обеспечения безопасности Системы.
3.8.8. Формирование отчётности.
3.8.9. Интерактивная рассылка сообщений (SMS и e-mail).
- 37 -
4. УПРАВЛЕНИЕ ПРОЕКТОМ
4.1. ЗАКАЗЧИК СИСТЕМЫ
4.1.1. Место внедрения системы: Производственный блок ТМХ-Сервис
4.1.2. Руководитель внедрения Системы: заместитель генерального директора
ТМХ-Сервис по организации ремонта ТПС Субботин Роман
Николаевич.
4.1.3. Ответственный исполнитель от производственного блока: начальник
департамента управления сервисным обслуживанием Гребенюк
Александр Васильевич
4.2. ОТВЕТСТВЕННЫЕ ИСПОЛНИТЕЛИ РАЗРАБОТКИ
4.2.1. Разработчик программного обеспечения: победитель конкурса.
4.2.2. Место разработки системы: блок развития ИА ТМХ-Сервис.
4.2.3. Руководитель разработки: заместитель генерального директора ТМХСервис по развитию Лянгасов Сергей Леонидович.
4.2.4. Ответственный исполнитель работ: начальник департамента научнотехнического развития Лакин Игорь Капитонович.
4.2.5. Ответственный за информационное взаимодействие систем ТМХСервис с Сетевым графиком: начальник департамента информационнотехнической поддержки Розвер Денис Юрьевич.
4.2.6. Руководитель технико-экономического сопровождения Системы:
Заместитель Генерального директора по коммерции Абисалов Роман
Хаджи-Мурадович.
4.2.7. Ответственный за стыковку сетевого графика с Электронными
Моделями локомотивов: начальник департамента УПД и ЗО
Андрюшков Иван Васильевич
4.3. ПИЛОТ-ПРОЕКТЫ 2015 ГОДА
Ожидаются предложения от филиалов и СЛД.
- 38 -
5. СТРУКТУРА УПРАВЛЕНИЯ ТМХ-СЕРВИС
Структура
информационно-управляющей
производственными процессами ТМХ-Сервис
Пользователями Системы являются:
Системы
показана
управления
на Рис.5.1.
 СЛД, Сервисные участки и ПТОЛ (блок 10), осуществляющие плановые и
неплановые виды технического обслуживания и ремонта локомотивов
(ТО и Р). СЛД являются ключевыми пользователями Сетевого графика, с
помощью которого происходит управление основными процессами в депо:
планирование работ, работа со складом, выдача нарядов, закрытие
нарядов, контроль выполнения операций, планирование загрузки
мощностей депо, выдача инструмента и др.
 Группы диагностики и обслуживания МСУ (блок 11), созданные при
каждом сервисном локомотивном депо (СЛД) для мониторинга
технического состояния и режимов эксплуатации локомотивов по данным
бортовых микропроцессорных систем управления (МСУ). Группы
диагностики отвечаю за фиксацию всех видов инцидентов с локомотивами,
по которым формируются дополнительный объём работ при ТО и Р.
 Центры мониторинга (ЦМ) эксплуатации локомотивов ТМХ-Сервис (блок
12) созданные при Центрах управления тяговыми ресурсами ОАО «РЖД»
(ЦУТР) для Мониторинга пробегов, оперативного и прогнозного
планирования, контроля выдачи локомотивов из СЛД, управления
устранением отказов. ЦМ отвечают за мониторинг пробегов и работы
локомотивов, планирование ремонтов и контроль выдачи локомотивов с
ТО и Р.
 Филиалы ТМХ-Сервис (блок 13): осуществляют управление ТО и Р в
регионах, планируют материально-техническое обеспечение СЛД.
 Исполнительный аппарат ТМХ-Сервис и управляющая компания
«Локомотивные технологии» (блок 14): осуществляют управление
холдингом
в
целом,
планируют
инновационное
развитие
локомотиворемонтного комплекса.
Исходной информацией Системы являются данные об эксплуатации
локомотивов ОАО «РЖД» (блок 1), которые формируются в следующих
информационных системах:
- 39 -
 геоинформационные системы (блок 2: АСУЖТ - АСОУП, АСУТ-Т, ГИД
«Урал» и др.);
 системы контроля безопасности и надёжности (блок 3: КАС АНТ, КАСАТ,
АСУ БД, УРРАН и др.);
 системы расшифровки данных бортовых приборов безопасности (блок 4:
АСУ НБД, АРМ КЛУБ, АРМ САУТ и др.);
 данные из бортового журнала локомотива формы ТУ-152 (блок 5).
Дополнительно к информации из информационных систем ОАО «РЖД»
ТМХ-Сервис дополнительно самостоятельно получает данные:
 при осмотре локомотива при приемке на ТО и Р (блок 6: акт формы ТУ162, в будущем – АРМ «Планшетник»);
 из АРМ расшифровки данных бортовых микропроцессорных систем
управления (блок 7: АРМ МСУ различных типов МСУ: МСУД, МСУЭ,
МПСУ, МСУ-Т, УСТА+УПУ и др.);
 от деповских стационарных и переносных автоматизированных систем
технического диагностирования (блок 8: АСТД).
Вся информация, полученная из информационных систем (блоки 2 - 8)
фиксируется в листах регистрации инцидентов (ситуаций, отличных от
нормальной эксплуатации локомотивов) в единой информационноуправляющей системы мониторинга технического состояния и режимов
эксплуатации ТМХ-Сервис: ЕСМТ (блок 9). ЕСМТ обеспечивает три
следующих технологических процесса: «Управление Инцидентами»,
«Управление Проблемами», «Управление уровнем сервиса».
Собственно устранение инцидентов, зафиксированных в ЕСМТ (см.блок
9), осуществляется в СЛД с использованием информационно-управляющей
системы «СЕТЕВОЙ ГРАФИК» (блок 15). С помощью сетевого графика
осуществляется сетевое планирование работы СЛД, управление ТО и Р,
ведение и закрытие нарядов, взаимодействие со складом, наглядное отражение
процессов в виде многоуровневых диаграмм Ганта, информирование о
нарушениях графиков,
ведение личных накопительных нарядных карт
рабочих, взаимодействие с информационными системами ТМХ-Сервис.
- 40 -
Работа сетевого графика поддерживается Электронными Моделями
локомотивов (блок 16), включающими в себя электронную документацию на
локомотивы, технологические карты по видам оборудования, структуры
заказов ремонтных комплектов и др.
Также обеспечение работы Сетевого графика и его совместимость с
другими информационными система ТМХ-Сервис обеспечивается единым
хранилищем нормативно-справочной информации ТМХ-Сервис, включающей
в себя классификаторы, справочники и другие справочные материалы.
ЕСМТ (блок 9), Сетевой график (блок 15), Модели (блок 16) и НСИ (блок
17) взаимодействуют с ERP-системой ТМХ-Сервис, построенной на платформе
1С (блок 18).
Распределение функций управления между информационными системами
по Рис.5.1 приведено в Табл.5.1.
Примечание: в Табл.5.1 приняты следующие сокращения:
ЭК
МФТП
КО
ИПВО
СГРЛ
КСПТР
ОС
ОБС
– электронный каталог локомотива;
– модуль формирования технологических процессов ТО и Р
локомотива и его оборудования;
– классификатор отказов оборудования локомотивов;
– интегральный показатель веса отказа;
– сетевой график ремонта локомотивов;
– комплексная система поддержки технологии ремонта;
– основные средства (задействованные в технологическом процессе);
– оборотные средства (задействованные в технологическом процессе).
- 41 -
Таблица 5.1 -
№пп
1
2
3
4
5
6
7
8
9
10
11
12
ста
тус
13
Технические требования к информационно-управляющей системе:
СЕТЕВОЙ ГРАФИК РЕМОНТА ЛОКОМОТИВОВ В СЛД ООО «ТМХ-Сервис»
Функционал системы
Автоматизированное формирование сводной заявки потребных
материальных ресурсов в компании, с учетом ограничивающих
лимитов и остатков.
Автоматизированный поэтапный контроль исполнения заявки в
потребных материальных ресурсах.
Формирование единого визуализированного справочника деталей
и узлов локомотивов
Формирование
технологических
процессов
ремонта
и
обслуживания локомотивов их узлов, систем и агрегатов
Содействие в принятии решений по выбору технологического
процесса при устранении конкретного отказа
Формирование исходной потребности в запасных частях и
материалах на основании технологических процессов и лимитов
остатков.
Формирование исходной потребности в иных материальных
ресурсах (квалификация персонала, оснастка, оборудование,
основные средства).
Мониторинг надежности локомотивов, их узлов, систем и агрегатов,
а также эксплуатационного фактора.
Сбор, хранение и предоставление объективной информации об
условиях эксплуатации локомотива при расследовании причин
отказа.
Автоматизированный расчет интегрального показателя веса отказа
(определение приоритетов инвестирования).
Индивидуальный учет выполнения и продолжительности работ
ремонтного персонала СЛД, формирование нарядов на оплату
труда
Оперативное планирование ремонта локомотивов на основании
анализа наличия необходимых (трудовых) ресурсов
Мониторинг состояния производственных процессов в СЛД на
основании выявления лимитирующих ресурсов.
внедрение
разработка
АСБУ
УПП
да
да
1С
МТРиО
КАДРЫ
ОС
ОБС
ЭК
КСПТР
МФТП
КО
ЕСМТ
ИПВО
СГРЛ
ГРАФИК
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
да
-
- 42 -
да
да
да
да
да
да
да
да
да
2
в плане на 2015
год железнодорожного транспорта
Геоинформационные
системы
(АСУЖТ: АСОУП, АСУТ-Т, ГИД «Урал» и др.)
1
да
3
Учёт отказов технических средств железнодорожного транспорта
(КАС АНТ, КАСАТ, АСУ БД, УРРАН и др.)
-
-
-
да
Осмотр локомотива контролером.
ТУ-162, АРМ «Планшетник»
ЭКСПЛУАТАЦИЯ
ЛОКОМОТИВОВ в ОАО «РЖД»
6
7
Расшифровка данных бортовых МСУ
(АРМ МСУ)
4
Расшифровка данных бортовых приборов безопасности
(АСУ НБД, АРМ КЛУБ, АРМ САУТ и др.)
8
АСТД: деповские переносные и стационарные
автоматизированные системы технического диагностирования
(станции реостатных испытаний, вибродиагностика, Доктор и др.)
5
Замечания машинистов в бортовом журнале ТУ-152
(АСУ ЗМ и др.)
9
ЕСМТ
ЕДИНАЯ СИСТЕМА МОНИТОРИНГА ТЕХНИЧЕСКОГО СОСТОЯНИЯ И РЕЖИМОВ ЭКСПЛУАТАЦИИ ЛОКОМОТИВОВ
Управление инцидентами, проблемами, уровнем сервиса
10
15
СЕТЕВОЙ ГРАФИК
СЛД
ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ И РЕМОНТ
ЛОКОМОТИВОВ В СЛД, СО, ПТОЛ
ТО-2, ТО-3, ТР-1, ТР-2, ТР-3, СР:
планирование работ, работа со складом, выдача нарядов, закрытие
нарядов, контроль выполнения операций, планирование загрузки
мощностей депо, выдача инструмента и др.
(Более 100)
ГД
Планирование работы СЛД Управление ТО и Р,
ведение и закрытие нарядов, взаимодействие со складом,
наглядное отражение процессов в виде многоуровневых
диаграмм Ганта, информирование о нарушениях графиков,
ведение личных накопительных нарядных карт рабочих,
взаимодействие с информационными системами ТМХ-Сервис
11
ГРУППЫ ДИАГНОСТИКИ ПРИ СЛД
Расшифровка данных бортовых систем локомотивов (МСУ) с целью выявления
предотказных состояний, нарушений режимов эксплуатации и других инцидентов.
Создание листов регистрации инцидентов. ТО и Р МСУ
(в каждом СЛД)
ЦМ
16
17
МОДЕЛИ
12
ЦЕНТРЫ МОНИТОРИНГА ЭКСПЛУАТАЦИИ ЛОКОМОТИВОВ (ЦМ) ПРИ ЦЕНТРАХ
УПРАВЛЕНИЯ ТЯГОВЫМИ РЕСУРСАМИ ОАО «РЖД»
Мониторинг пробегов, оперативное и прогнозное планирование, контроль выдачи локомотивов
из СЛД, управление устранением отказов
(в каждом ЦУТР)
Электронная документация на локомотивы,
технологические карты по видам оборудования,
структура заказов ремонтных комплектов и др.
Технологические карты, 3D-модели, типовые сетевые
графики, конструкторская и технологическая документация
НСИ
НОРМАТИВНО-СПРАВОЧНАЯ
ИНФОРМАЦИЯ
Классификаторы, справочники
13
18
ФИЛИАЛЫ
Управление работой ТМХ-Сервис на полигонах и в СЛД
1С
14
ERP-система ТМХ-Сервис
ПРЕДПРИЯТИЕ, БУХГАЛТЕРИЯ, КАДРЫ, СКЛАД и др. модули
Управление экономикой и МТО, расчёт зарплаты, другие функции ERP-системы
ИА, ЛОКОТЕХ
Управление работой ТМХ-Сервис
- 43 -
Рисунок 5.1 – Информационная модель управления производственными процессами ТМХ-Сервис
- 44 -
Download