Єдиний цифровий реєстр обмежень швидкості

Петренко Антон Олександрович

Департамент з питань інформаційних технологій


Опис проєкту

Єдиний цифровий реєстр обмежень швидкості — заміна АСВВП, системі видачі та відміни попереджень на поїзди, технологія якої закріплена ще у 2005 році.

Суть зміни — перехід від логіки повідомлень до логіки реєстру. Сьогодні система обробляє телеграми про попередження; я пропоную, щоб вона вела саме попередження як об'єкт реєстра із життєвим циклом: заявка → погодження → дія → продовження або переведення в постійне → відміна → архів.

Це прибирає три речі одразу: ручне перенесення попереджень до постійнодіючого наказу про швидкості, паралельне ведення однакових журналів у ПЧ, ШЧ, ЕЧ і на станціях, та «сліпу зону» — дані про десятки тисяч обмежень накопичуються двадцять років і не аналізуються.

Проблема, яку вирішує проєкт

Обмеження швидкості — це щоденна реальність інфраструктури: виявили несправність колії, пристрою СЦБ чи контактної мережі — ввели попередження. Технологія його обробки не змінювалася з 2005 року і побудована навколо телеграми.

1. Заявку не можна подати з місця. Дорожній майстер, який виявив несправність, не вводить обмеження — він передає телеграму, яку вручну набирає диспетчер або відповідальний працівник ПЧ. Між виявленням і появою попередження в базі стоїть ланцюг ручних передач, кожна з яких — це і затримка, і можливість помилки в кілометрі, пікеті чи швидкості.

2. Розбіжність закладена в технологію як норма. Методичні рекомендації прямо передбачають ведення «Журналу реєстрації виявлених розбіжностей бази АСВВП із записами Книги ф. ДУ-60». Тобто система від початку проєктувалася з допущенням, що її дані розходяться з паперовим обліком на місцях, — і для цього розходження створено окремий журнал. Паралельно ті самі попередження вручну реєструються в ДУ-60 на станціях, у журналах заявок ПЧ, ШЧ, ЕЧ і в журналі приймання-здавання невведених телеграм. Один факт — чотири незалежні місця для запису.

3. Перетікання в наказ — ручна операція. Коли попередження діє довше 10 діб, воно переводиться в постійне окремим наказом начальника регіональної філії. Текст наказу готується руками, звірка з базою — теж руками (нормативно — щоквартально). Наказ і система можуть розійтися, і ніщо в процесі цьому не заважає.

4. Дані пишуться, але не читаються. АСВВП формує понад десяток вихідних довідок, але всі вони відповідають на питання «що діє зараз». Жодна не відповідає на питання «що діє роками». Ми не знаємо, які кілометри стабільно живуть під обмеженням, скільки разів на одному й тому ж місці попередження вводили, знімали і вводили знову, і в скільки хвилин затримки поїздів це обходиться. Інформація для цієї відповіді вже двадцять років лежить у базі.

Запропоноване рішення

Реєстр обмежень швидкості з чотирма рівнями. Перші три роблять процес чесним, четвертий — це власне інновація.

Рівень 1. Ініціація з місця роботи. Дорожній майстер, електромеханік, енергодиспетчер подає заявку зі свого робочого місця — з довідників кілометрів, об'єктів і причин, з валідацією, яка робить цілі класи помилок технічно неможливими для введення (неіснуючий пікет, швидкість поза допустимим рядом, перекриття з чинним обмеженням). ДПРЕД, або інший фахівець з роллю контролю попереджень, перестає бути машиністкою і стає контролером якості.

Рівень 2. Один запис замість чотирьох журналів. ДУ-60, журнали заявок дистанцій, журнал розбіжностей перестають бути окремими документами і стають представленнями (views) одного реєстру, які формуються автоматично. Журнал розбіжностей зникає не тому, що його скасували, а тому, що розходитися більше нема чому.

Рівень 3. Наказ генерується з реєстру. При наближенні до 10 діб дії система сама формує проєкт змін до наказу про дозволені швидкості з даних реєстру і відправляє його на погодження через «Мегаполіс.DocNet». Розбіжність між текстом наказу і базою стає структурно неможливою — це один і той самий запис. Відміна будь-якого обмеження вимагає явного накладення КЕП відповідальної особи: жодне попередження не зникає «саме по собі» за таймером.

Рівень 4. Аналітика накопиченого — важлива ідея кейсу. Реєстр з історією дозволяє вперше поставити питання, які сьогодні не мають адресата: — які ділянки найчастіше і найдовше перебувають під обмеженням; — де попередження знімають і вводять повторно на тому ж кілометрі — тобто ремонт не усунув причину; — скільки поїздо-хвилин затримки коштує кожне обмеження за рік. Це перетворює облік обмежень на інструмент планування ремонтів: не «де попросили», а «де це вже коштує найдорожче». Дані для цього не треба збирати — вони вже є.

Технологічно це не потребує заміни напольного обладнання: реєстр будується як надбудова над існуючою базою АСВВП зі збереженням чинних вихідних форм на перехідний період.

Очікуваний ефект для УЗ

Ефект від самого рішення розкладається на три категорії конкурсу:

Безпека. Обмеження швидкості — це елемент безпеки руху. Кожна розбіжність між базою, наказом і бланком ДУ-61 — це ризик, який сьогодні контролюється людською уважністю і щоквартальними звірками. Реєстр прибирає саму можливість розбіжності, а не бореться з її наслідками.

Швидкість. Реєстр робить цю цифру "скільки хвилин на рік поїзди втрачають на обмеженнях і на яких саме кілометрах?" обчислюваною. Навіть за консервативної оцінки — одне обмеження 40 км/год на 1 км при встановленій 80 км/год додає близько 0,7 хв кожному поїзду; при 30 парах поїздів на добу це понад 20 хвилин на добу з одного кілометра, і сотні поїздо-годин за рік з ділянки. Точні значення я порахую на реальних даних реєстру — і саме в цьому суть: сьогодні ця арифметика неможлива, завтра вона стає щоденним звітом.

Люди. Дорожній майстер перестає диктувати телеграми, ДПРЕД та інші учасники процесу перестає передруковувати, станція перестає вести журнал розбіжностей.

Що особисто мені дасть InnoTrans. Я поєдную дві рідко суміщені компетенції: 18 років в інфраструктурі та СЦБ, де я сам працював з цими попередженнями, і поточну роль розробника, який будує вебсистеми для УЗ. Мені не потрібен перекладач між «як воно влаштовано на дистанції» і «як це запрограмувати». Чого мені бракує — це побаченої на власні очі референсної архітектури: як цю задачу вже вирішили ті, хто пройшов цей шлях раніше. Повернуся не з фотографіями стендів, а з чернеткою технічного завдання на реєстр, звіреною з європейською практикою.

1775 голосів за проект