遅い電車を予測する方法を学ぶ方法

貨物と乗客の両方の鉄道輸送は、我が国で最も人気のある輸送手段の1つです。 列車がレール上でのみ移動するという事実は、一方でモデルの変動性を単純化し、減少させる一方で、多くの依存関係を追加します。 トラックで予期しない状況が発生すると、ネットワーク全体に重大な影響を与える可能性があります。 1つの列車のスケジュールからの逸脱、またはレールでの事故は、方向全体の動きに影響を与える可能性があります。 これは、時間通りに商品を受け取らない会社と、仕事に遅れる、必要な電車に乗り遅れる、間違った電車に乗る、またはプラットフォームで30分（またはそれ以上）余分に過ごすことができる乗客の両方に影響します。



私の名前はアレクサンダー・ポドレフスキフです。私は電気鉄道チームのチームリーダーであるTutu.ruの主任開発者です。この記事では、列車のスケジュールからの逸脱を予測する方法について説明します。 また、GVZ RZDとは何か、郊外の鉄道輸送のシステムがどのように技術的に配置されているか、乗客が遅れていることについて話す方法についても説明します。

電車と電車の実際のフォローは何ですか

ロシア鉄道のメインコンピューティングセンター（GVCロシア鉄道）は、ロシア鉄道の情報サポートを主なタスクとする組織です。 本質的に、MCCはIT鉄道です。



MCCシステムには、膨大な量のデータが含まれ、処理されます。 前の記事で、Tutu.ruとMCCの相互作用について説明し、電車の基本スケジュールのデータとその移動オプションを操作しました。 その後すぐに、通勤電車の実際のルーティングに関するデータの使用も接続しました。



実際の追跡データはデータベース内のレコードのセットであり、各レコードは列車がルートのチェックポイントを通過したという事実です。 これらの事実は、駅の出入口にあるセンサーによって記録されます。 センサーには4つのタイプがあります。

• ASOUP（輸送の運用管理のための自動化システム）。 実際、これはトラックからのデータを集約し、すべての出荷を管理できるシステムです。 特に、貨物列車の編成、質量および長さ、貨物の到着の予測、道路と分岐点の交差点を通る列車、貨車およびコンテナの通過の会計（ ASOUP ）の計画の遵守 。 ここから、MCCは、列車が駅を通過したかどうかについての情報を受け取ります。
• 信号、信号、集中化およびブロック装置-列車の交通の安全性を規制および保証するために使用される一連の技術的手段（ 信号、集中化およびブロック装置 ）。 実際、これらのデバイスは鉄道スイッチのゲージであり、そこからデータがMCCに供給されます。
• SAIPS（車両を識別するための自動化システム）-線路に沿って立ち、通過する車を修正するデバイス。
  
  
  
  
• GIS（ロシア鉄道の地理情報システム）は、GLONASSベースの地理位置情報システムで、鉄道輸送のパフォーマンス、区間速度、交通安全違反などを監視できます。

各ステーションについて、MCCのデータは、インストールされている機器に応じて、いくつかのソースから取得できます。 さらに、ソースが異なると精度も異なる場合があります。 たとえば、信号システムのエラー確率はSAIPSよりもかなり低いことを分析しました。 したがって、同じイベントの両方のソースからのデータがある場合、シグナリングを優先します。 そして、現時点では、それがデータの主なソースである信号です。 さらに、ルートのページ上の各時刻のデータソースを提供します。 これは、まず第一に、このデータを持っているおおよその予測精度を理解できる上級ユーザー向けのストーリーです。



これらのデータはすべて、MCCシステムのDB2データベースに収集され、そこからパートナーは自分のニーズに合わせてデータを取得します。

MCCとの相互作用

テロ対策のセキュリティを確保するための規則では、10分以上前の実際の鉄道輸送の連続データを使用する必要があります。 さらに、システムの負荷が高いため、パートナー（ Tutu.ruなど）は数分に1回しかアクセスできません。 このため、ユーザーは実際の構成を追跡することはできませんが、10分前の追跡方法を追跡できます。 さらに、データはステーションのセンサーからのみ取得され、小さな停留所（プラットフォームがない場合もあります）または途中で、実際には何もありません。



また、ステーションの調査データが間違った構図に添付されている場合もあります。 原則として、このような状況はまれにしか発生せず、MCCの従業員によってかなり迅速に修正されます。 それでも、ローカルデータウェアハウスでこのようなケースを最小限に抑えるには、毎回自分自身を保証し、MCCに必要以上のデータ深さを要求する必要があります。 そして、この場合でも、データを100％確信することはできません。変数が多すぎて、あらゆる種類の「buts」があります。 ただし、エラーの程度は無視できます（100,000エントリあたり約1エラー）。

使用する

実際のフォローアップデータを取得して保存するために、MCCへの接続メカニズムが使用されました。 これは、計画されたスケジュールからデータを受信するのと似ています（ 以前の記事でメカニズムを説明しました）。 また、当社のWebサイトで使用するために、以前に構築したローカルデータとMCCベースのリンク、およびステーションの通信（アルゴリズムも前の記事で説明されています）は、多くの点で役立ちました。 この通信を使用して、エンティティの約90％を実際のフォローアップデータに接続することができました。 残りの列車については、列車と駅の数を検索することで新しい接続を見つけました。

それで、タスクは何でしたか：

サイトにスケジュールページ（ モスクワ-Petushkiなど ）があり、その表示のために「スケジュール」サービスがポーリングされます。 出発駅と目的駅の識別子、および旅行の日付を受け取り、それに応じて、これらの駅間を通過する電車のデータを含むオブジェクトのセットを提供します。 これには、列車の識別子-番号、開始/終了駅、時刻表、およびある駅から別の駅への特定の列車の旅に関する情報-到着/出発時刻、プラットフォームが含まれます。 回答には完全な鉄道ルートデータ（各中間駅の移動時間）が含まれていません。このような情報は大きすぎ、計算に時間がかかり、単純に不要でした。



ローカルデータベースのスケジュールデータと比較される実際のフォローアップデータに基づいて、可能性のある遅延/進行のマークを計算する必要がありました。 計算は、列車による制御点の通過に関する最後の記録ではなく、いくつかの記録に基づいている場合があります。 これは、さまざまなセンサーがさまざまな精度で機能する場合に発生します。 たとえば、ある駅では、実際の列車と計画された列車との間に大きな違いがあります。 そして、前の駅を通過するときを見てください。



つまり、列車がスケジュールから逸脱する可能性に関する情報をユーザーに表示するという課題に直面しました。







この問題を解決するためのMCCからの実際のフォローアップデータだけでは十分ではありません。 また、マイクロサービスを作成しました。そのタスクは、計画されたスケジュールからのデータだけでなく、駅の通過に関する実際のデータも含めて、列車IDで完全なルートを返すことです。

作業アルゴリズム

サービスのアルゴリズムは次のとおりです。入り口で列車の識別子を取得し、現在のルートを取得するためにスケジュールサービスに要求を行います。 次に、別のリクエスト-ローカル列車とMCCシステム内の列車との接続を保存するサービスへ。 接続がある場合、実際のデータストレージサービスから、コントロールポイントを通過する列車に関するすべての情報を取得します。 ストレージに接続がない場合、またはこれらの接続に実際のデータがない場合、列車番号と通過駅ごとにデータを受信するよう要求します。 2番目のケースでデータが見つかった場合、検索された列車と私たちの列車との間に新しい接続を確立し、そのために検索が実行されました。



ルートへの実際のフォローのデータを正しく混合するには、どの事実がどのステーションに属しているかを理解する必要があります。 実際のルートデータでは、ステーションはECPコード（Express-3システムのステーション番号）で識別されます。ルートのデータでは、ステーションは独自の識別子を持っています。



ステーションを一致させるために、さらに3つのサービスでリクエストが行われます。ステーションとMCC内のステーション間の通信サービスです。 これらの識別子に基づいて、MCCのローカルストレージサービスに対して、ステーションに関する完全な情報（ECP識別子付き）を取得する要求が行われます。 さらに、ローカルステーションのサービスに対して要求が行われ、そこからExpress-3コードが取得されます。 駅の通信を知って、私たちは駅の計画通過とこれらの駅の実際の通過で現在の日付の電車ルートを構築しています。



最初のバージョンでは、サービスはそのように機能しました-ページを開くと、スケジュール内の各列車に対してリクエストが行われ、キャッシュはありませんでした。 さらに、圧倒的多数の問い合わせはモスクワの「今日」の方向に向けられています（毎日100本以上の電車がここで運行しています）。



一般に、生産のメカニズムがユーザーの5％によってオンにされたとき、使用されたすべてのサービスに対して合計で約6000 rpsの負荷が発生しました。 インフラストラクチャはこれに対応できていませんでした。 作業を最適化し、リクエストの総数を減らす必要がありました。 この問題を次のように解決しました。

• 彼らは、リクエストが行われる列車の数を制限しました。 現在は、当日のすべての列車ではなく、次の列車のみに向けて出発しています。数時間以内に出発する列車、またはすでに出発している列車のみです。 これにより、リクエストが約2倍減少しました。 しかし、それだけでは十分ではありませんでした。
• 次に、個々の列車のデータではなく、列車の列車のデータをアップロードしました。 要素の数を変更する試みがありましたが、別の問題が表面化しました-パックのサイズを大きくすると、データが並列ではなく直列に生成されるため、ページの読み込みが大幅に遅くなります。
• 次の方法は、静的データ（列車と駅間のリンク）をキャッシュすることです。 この改善により、すでに全体像が大幅に改善されました。100％のユーザーの配信を可能にすることができました。 ただし、ピーク時（月曜日の朝と金曜日の夕方）にはまだ問題があり、サーバーに割り当てられたリソースが定期的に使い果たされました。
• 次に、合計を含むキャッシュを追加しました。列車のルート+計算されたすべての一致を含む実際のルートです。 これにより、ページの平均読み込みが大幅に加速しました。 しかし、最新の実際の追跡データを数分ごとに取得し、最終計算を実行するサービスは、どの電車が新しいデータを受信し、どのデータを受信して​​いないのかわからないため、最後のデータのダウンロードからの時間を確認する必要がありました。 この時間が以前よりも長い場合、キャッシュは完全にリセットされます。 これには効果があり、平均ページ読み込み時間が大幅に短縮されました。 しかし、データを受信し、それに応じてキャッシュをフラッシュする瞬間には、膨大な数のリクエストが原因で、ロード時間は依然として跳ね上がりました。 ピーク時には、グラフは心電図のように見えました。
• そして最後に、最終的なキャッシュがデータストレージサービスに追加され、今では状況が完全に平準化されました。 つまり、データベースへのクエリの結果がキャッシュされ、新しいデータが受信されると、このデータが受信された列車についてのみ更新されます。

その結果、実際のデータを使用して列車のルートを計算するスキームは次のとおりです。







列車の30〜50％の現在の日付のスケジュールの各ページで機能し、90パーセンタイルで最大100ミリ秒のページ読み込みのオーバーヘッドを提供します。

データ分析

得られたデータに基づいて、列車が遅れているか、予定よりも遅れていると結論付けることができます。



まず、特定の列車の実際のデータがあるかどうかを分析します。 彼らがそこにいなければ、列車は5分以上前に出発駅から出発するはずだったので、遅れる可能性があると書いていますが、これは起こりませんでした。



データがある場合、実際のシーケンスのデータが存在する最後または最後の2つのステーション（信頼性のため）のデータが分析されます。 スケジュールからの逸脱がある場合、列車は「遅く/非常に遅く/前に」とマークされます。 さらに、理由が記載されています-たとえば、前の駅への列車が数分遅れて到着したなどです。



別の小さいながらも有用な改善はこれです。 2つの駅-タラシカとキセリカを通過する列車のSemenov-Nizhny Novgorodがあるとします。 列車は9:20にSemyonovから始まり、9：43にTarasikhaに到着し、10：11にKiselikhaに到着し、10：32にNizhny Novgorodに到着します。 しかし、実際のデータによると、列車は10:02にのみタラシカに到着したことがわかります（つまり、すでに19分遅れています）。 Kiselikhaの人里離れたプラットフォームで凍った乗客が10:25のスケジュールを見て、スケジュールデータのみを表示した場合、その人はすでに列車が出発したと判断します。 しかし、実際には19分のスケジュールに追いつくことができないため、まだキセリカを出発していないため、この列車を示しています。







列車が最新のデータに基づいたスケジュールに従って運行している場合、次の駅が分析され、それに応じて実際のデータが通常来ます。 時間通りにデータがない場合、おそらく列車はステージ上のどこかに留まっており、すでに中間駅に到着していないという警告が表示されます。

しかし、それだけではありません。 ある人がチュクリンカのプラットフォームに立っているモスクワのスケジュールを見ることがあります。 ここでは、モスクワが道の出発点であるため、実際のフォローを伴うストーリーは機能しません。 情報がないか、情報がありますが、これは列車がすでに出発していることを意味します。 この場合、列車の移動速度を分析します。

回転数

ほとんどの場合、1日に1つの電車が複数の旅行を行いますが、ルートに沿って1日中走ります。 さらに、旅行のたびに、彼の数が変わり、ドライバーの乗組員も変わる可能性があります。 スケジュールが設定されているすべてのシステム（弊社とMCCの両方）では、これらは異なるオブジェクトです。 ただし、多くの場合、システムには列車が将来どのフライトに送られるかに関する情報があります。 構成自体は毎日異なる場合がありますが、固定されているのは多数のフライトです。 また、列車が最初の旅行で遅れて移動した場合、2番目の旅行も遅れて開始されます。 これらのルールには例外があります。たとえば、遅延が非常に大きい場合、2回目の旅行で別の列車が許可される場合がありますが、実際にはこれはめったに起こりません。



このような接続に関するデータがあるため、同じ列車が運行している列車の実際の数に関するデータも分析し、遅延の可能性に関する警告を表示します。 ただし、これは、前のフライトの遅延がユーザーが見ているフライトに影響を及ぼす可能性がある場合にのみ行われます。



一般的に、次回タラシハからキセリカに行くときは、列車の遅れを必ずお知らせします。