中央PPCの状況センター（モスクワ地方の列車）-私たちは多くの仕事の地獄をしました

テスト中



高品質の乗客サービスと乗客インフラストラクチャの信頼性の高い運用を確保するには、適切な機器制御が必要です。 簡単に言えば、情報をキャプチャして処理するシステムです。 ある時点で、中央通勤旅客会社（モスクワ地域で電車でお越しの方）は、手動制御技術を回避するという点で突破口を望んでいました。 主なアイデアは、緊急事態に迅速に対応するために、運用プロセスを監視、制御、理解、予測する単一のシンクタンクを作成することでした。





これが、CACがCPPKのアーキテクチャに統合された方法です。 プロジェクトに2年間。 二年！ ベンダーは次のとおりです。参照情報モジュール-Talend MDM。 統合分析システム-Oracle BI 11g、Pentaho DI（オープンソースアナログ-Pentaho BA、Spago BI、JasperSoft BI）、DBMS -MS SQL Server 2012、オーディオビジュアルシステム-YCD、Samsung、通信コラム-国内メーカー、ビデオ分析、ビデオ監視カメラ- Synesis、Samsung、Verint、Axis。 IPテレフォニー-Cisco。



一般に、ここからデータを収集した場所とそれらを使用して何をしたかを示します。 そして、なぜ私たちの座標グリッドの鉄道のキロメートルは、700から1300メートルの範囲のブロックセクションに置き換えられます。

センターの仕事

全般-統合された分析に基づいて、旅客サービスプロセスの集中管理を実行し、輸送サービスの品質向上を目的とした経営上の意思決定の運用上の採用をサポートします。 すでに結果を見ることができました：駅のリアルタイムスケジュールボード、ビデオ分析とチケット印刷機のネットワークの開発のおかげでチケットオフィスのキューが大幅に削減され、さらに「舞台裏」で多くのインフラストラクチャの変更があります。



長期的なタスクに加えて、運用上のソリューションを必要とするタスクがあります。 たとえば、サブシステムの1つが、列車が遅れていると報告した場合、ラインのさらに下の乗客はすぐに遅れることを警告されます（このためのディスプレイには別の列があります）。 交通スケジュールからの逸脱は、GIS、ロシア鉄道管理センター、GLONASS / GPS監視サブシステムからの情報に基づいて、特定のアルゴリズムに従って自動的に計算されます。



すべてのサブシステムの実装-コントロールセンターから乗客へのLANのようなインフラストラクチャへの通知-とデータ比較のロジックの記述には2年かかりました（そして、まだ続いています）。 ケーブルを敷設し、カラムを取り付け、一連の分析ソフトウェアを作成し、情報交換を接続し、ハードウェアをインストールし、一般にそのような大規模プロジェクトで行われたすべてを行いました。 結果は、状況センターの従業員だけでなく、乗客にも表示されます。

入力ソースには次のものがあります。

-列車内のGPS / GLONASS （CPPKの自社艦隊の列車が対象）およびロシアの鉄道インフラストラクチャ。 これらのデバイスを組織的に（一部の列車はリースで所有しておらず、所有者はロシア鉄道です）、純粋に物理的に供給することは困難でした。 同僚がこれらの鉄片をどのように配置するかについては、おそらく次の物語の記事で何らかの形で伝えます。 これらのセンサーは、列車がどこにあるかを正確に知るために必要です。 そのようなセンサーが登場する前の遠い時代には、すべての派遣は鉄道の公式信号によって行われました。 アラームがトリガーされた後、列車の動きを監視するために、以前のレイアウトが移動されました。 エラーは10分ですが、「ノイズのある」データがない非常に信頼性の高いシステムです。



-停止ポイントでのビデオ分析カメラ。 プラットフォーム上の危険な状況（たとえば、プラットフォームの端を越える）に関するビデオ分析を行いました。 しかし、鉄道の訓練場が非常に温室効果のある環境ではないことは明らかです。雪の波紋、太陽のまぶしさ、光沢のある列車...-これらはすべて誤検知につながり、アルゴリズムの長い訓練が必要です。 ビデオ付きの部屋で-少し簡単に。 たとえば、ビデオデータに基づいて、興行収入をリアルタイムでカウントします。 路線が4人を超える場合、駅の上級レジ係は自動通知を受け取り、追加のチケットオフィスを開くか、乗客をチケットマシンに誘導できます。



-市民の訴え。 CPPKのスタッフ（駅の人々）と乗客（特に、確かに年金受給者）は、何をどのように行うかについて異なる願いを書いています。 これらの呼び出しは、システムおよびセンサーから収集された他のすべてのデータと同様に、ITSMに基づいて構築された運用監視および制御システムに書き込まれます。 実際、これは中央PPCのチケットのシステムです。





次のターミナルが使用されます。原理は、地下鉄駅の青赤柱の原理と同じです



-関連会社からのデータ。 たとえば、さまざまな修理サービスは、地域の機器の状態に関する情報を提供します。 ロシア鉄道はそのデータをCPPKに直接提供するため、スケジュールからの逸脱を明確に確認できます。



-セクション、ライン、ポリゴンに関する静的（正確には、リアルタイムで更新されない）情報 -これは問題分析にとって重要です。 しかし、ところで、彼女のアプリケーションはそれほど広くはありません。スケジュールグリッドは最大値に非常に近いなどです。 分析のおかげで9:05に別の列車が必要であることを理解したとしても、それをネットに配置することは困難です。 物理的に放っておけないか、ハヤブサやその他の制限をスキップする必要があります。 したがって、これは、現実の世界で優れた分析が容易に成り立つ例です。 物理的にできることから、列車の長さを変えたいと思っていますが、一部の海外の国とは異なり、ガベージコレクターの仕組みはありません-空のワゴンの単純な返却（アーキテクチャレベル）です。 そのため、何らかの方法で手動でドラッグして戻す必要があり、これは非常に困難です。 したがって、スケジュールではなく構成レベルでの最適化オプションも適切ではありません。 少なくとも次の数年で。 今のところ、「最初の2台の車だけが空港に行く」ことを忘れてください。

イベントのフィルタリングと相関

人間の介入を必要とせず 、特定のルールに従って単純に処理されるイベントがあります。 たとえば、重大ではない遅延（最大5分）は、列車の監視サブシステムから取得され（GPSセンサーとロシア鉄道の信号に基づいて）、乗客情報システムにすぐに表示されます（下のように駅に表示されます）。 長いキューの場合、ビデオ分析分析システムの結果に基づいて自動反応もトリガーされます。



次のタイプのイベントは、予測または相関です。 たとえば、列車が非常に遅い場合、最初の列車がスケジュールに追いついていない場合、同じレールのペアに沿って後続の列車（通常はパスは1つ）も遅くなります。 したがって、モデルを作成し、2つの列車の遅延をすぐに予測できます。 次に-この変化の影響を受ける3番目、4番目など、「水面上の円」が沈静化するまで。 そして、再び、すぐに乗客に自動的に通知します。



技術的には、システムは多数の単一イベントを生成します。 情報はヒープに集約され、最大遅延が計算されます。 通知する必要があるステーションの数を計算します。 原則として、遅延が短い場合は、次または数個の遅延のみが可能です。 長い場合は、追いつく機会なしに7〜10のステーションに通知する必要があります（彼らが叫ぶときに叫ぶ最小のレジで、ステーションには自動スケジュール更新システムがあります）。



遅延した人間の反応を必要とするイベントがあります。 たとえば、ある種の問題がありました-チケットが立ち上がった。 列車で重大ではない何かが壊れました-あなたはルートを終了し、予定外の修理にかけるか、何か他のことをするかを決める必要があります。 そして、設定されている場合は、どこに。 誰かにイベントを通知したり、CPPKで何かをしたりする必要がある場合があります。 次に、チケットはビジネスプロセスの自動化に進みます。 チケットマシンに不具合がある場合、アプリケーションは、これらのマシンを誰がどこでサービスするかに応じて、自動的に請負業者に飛びます。 プラットフォームのインフラストラクチャ（キャノピーが垂れ下がっていて、屋根が風から離れて曲がっていた）について話している場合-別のプロセス、これもすぐに責任があります。



別の有用性：以前は、今月末に請負業者の横棒について知ることができましたが、今すぐに、原則として、どこかが間違っている場合、トップからの操作的な呼び出しは劇的に状況を変えます。



次のタイプのイベントはアラームです。つまり、ここと今のコントローラーの反応を必要とするものです。 アラームは重要度によって優先順位が付けられます。 このようなイベントの例は、ビデオ監視で見つかった放棄されたバッグです。 多くの場合、駅やレジからの民間警備会社の従業員からのメッセージがトリガーになります。



会社の長期プロセスを研究するために必要な複雑な相関関係もあります。 たとえば、最も興味深い相関関係の1つは、列車の動きが駅でのチケット販売にどのように影響するかです。 この調査では、データは機械と回転式改札口から取得されます。 十分に大きなサンプルで、人々がどの電車に乗ってどこへ行ったかを計算できます。 さらに、列車の人口を計算します。 カメラでカウントするのではなく、分析を使用して電車の人口を計算する必要がある理由は別の問題です。 まず、多くのコンポジションにはカメラがありません。 第二に、それらがどこにあるか、これらはセキュリティカメラです。 主な要件は頭を数える上から下への方向であるため、世界の慣例では、誰もそのようなカメラでそのようなカメラを数えません。 ロシアでも、センサーに基づいて人々を数える試みがありましたが、彼らは破壊者によって腐敗しています。 一般的に、列車の溶接されていない部分は、非常に迅速に破損したりねじを外したりします。 または最初にネジを外し、その後壊れた。 したがって-分析。





これは私たちのパイロットプロジェクトであり、これまでのところ、限定的でパイロットモードのシチュエーションセンターに関連付けられています。



しかし、乗客の流れに戻ります。 中央のPPCは、列車が運んでいる金額と、人口過多の有無に関心があります。 つまり、アクションのピークと領域を理解する必要があります。 たとえば、夕方には6〜8の完全に正確なピークがあります-ベラルーシの方向でオジンツォボまで作用し、その後、すでに平滑化されています。







リアルタイムで、地理情報システムが機能します。 このGISは、どの列車がどこへ、どこで何が起こったかを示しています。 これは、責任範囲で何が起こっているかを視覚化する最も重要な手段です。 中央制御センターは、CPPKの多くの詳細を考慮したカスタマイズされたRZDシステムを使用しますが、インフラストラクチャの所有者、つまりRZDのGISと必ず統合されます。



GIS鉄道員が実際の世界とどのように異なるかを理解するには、異なる座標グリッドを覚えておく必要があります。 私たちの国のキロメートルの柱は、それ自体が非常にきれいです。 ただし、ブロックセクション（制御システムの基本要素）の長さは700〜1300メートルの範囲です。 19世紀のいつか、クズマは何らかの方法で歩き、信号機に目印を付けたと考えられます。 私はウォッカを飲み、バラライカを演奏し、開発者のために多くの問題を作成しました。 しかし、実際には、これはもちろんそうではありません。



反応の最後の部分は 、インフラストラクチャと他の従業員を担当するステーションのレジ係からのフィードバックです。 彼らのレポートは処理チェーンを閉じます。 さらに-一般的な統計、レポート、予測、BI、さまざまなセクション-一般的に、経営陣が意思決定に必要なすべてのもの。 定期的な分析が行われ、何をどこで変更するかを検討します。 簡単なレベルでは、チケットの自動販売機が頻繁に故障する場合、やる気のある組織的および技術的な決定を下す機会があります。

それはどのように見えますか

このデータがアセンブリに表示されるシステムには、43のレポートと5つの情報パネルがあります。 ディスパッチャは、パネルをざっと見ただけで、誰もが覗き込むことなく、何をどのように、どのように機器パイロットがすべてを一度に見るかを決定します。 また、戦略的決定のためのレポートがあります。



サンプルレポート：







CPPKの従業員が駅の典型的な指標からの急激な変化を見ることができる別のパネルがあります（これは緊急事態です）。







ディスパッチャがITスペシャリストを呼び出さないように、レポート用の視覚的なコンストラクターがあります。 マウスで列をドラッグするだけです。 便利に。 適切な期間のレポートごとに最大5分。 レポートコンストラクタは、原則として、分析ツールです（たとえば、Vykhinoまたはジャンクションステーションにマシンを配置した方がよい場合）。



駅での情報表示は、ほとんどドイツ人のものと同じです。 情報は30秒ごとに更新されます。 ディスプレイには、毎日のスケジュール、変更、キャンセル、追加機能を備えた「クイック」アップデートなどの統計情報が付属し、リアルタイム（30秒ごと）でGPS、GLONASS、ロシア鉄道の信号によるスケジュールからの列車の逸脱がプルアップされます。









生放送





駅キャッシャー画面



詳細情報がIVRにアップロードされます。 他のシステム用のAPIを作成しました。



フィールドワーカーの場合、シチュエーションセンターシステムの軽量バージョンがタブレットに表示されます-何が起こっているかについての通知がありますが、大まかに言えば、パネルにインフォグラフィックはありません。 AWPのキャッシャーでは、同様のデータも表示されるため、彼らは知っています。





中央に



新しい状況センターは2013年9月に完成しましたが、まだ多くの作業があります。 ちなみに、タイミングのために、特にビデオ分析はすべてのシーズンでテストされました。

まとめ

CACは、すべての航空会社の運用の監視、管理、分析の中核となっています。 これが今日の結果です。

• 発券機サービス ：請負業者が関与し、規制期限の遵守を監視するBPAネットワークメンテナンスプロセスを実装しました。 今、頭の後ろで頭の温かい息なしにプロファイルされた締め切りが残っていません。 タブレットで使用するBPAのアプリケーションを登録するための追加のインターフェイスを作成しました。監視で問題がなければ、ステーションから直接チケットを送信できます。 BPAメンテナンス用の情報パネルが実装されました。シチュエーションセンターのマップには特別な「コマンドビュー」があり、右側のセクションで分析を確認できます。 「旅客施設の故障」カテゴリのインシデントに関する詳細な規制レポートを作成しました（これは、何、どのように、どこで、なぜかを理解するためです）。 「旅客施設の故障」カテゴリのインシデントに関するディスパッチャの作業に関する統合レポートが実装されました（これにより、問題に姓が付くようになります）。また、時間外に処理される「旅客施設の故障」カテゴリのインシデントの内部使用のためにレポートが作成されました。 また、管理用の同じレポートと、何がどのように行われているかに関する毎日の運用レポート、個々のデバイスのパフォーマンスに関する統計、インベントリ。 すべて2013年でした。 2014年には、チケットが異なるソースから複製された場合にチケットを1つに自動結合する分析機能と、既にクローズされたチケットの拡張機能が既にあり、問題が再び発生しました。 自動および手動のインシデント優先順位付けがあります。 BPAメンテナンスドキュメントがコンパイルされました。 計画には、現場の専門家による労働規律違反の状況を追跡するレポートに加えて、ステーションでのBPAのパフォーマンスを監視する情報パネルが含まれています。 うーん...しかし、さらに先に進みましょう、これは一方向にすぎません。
• 乗客用機器のメンテナンス ：ビデオカメラの修理と修理のためのパネルを作成し、上記と同じ請負業者向けの制御方式（自動アプリケーション、チケット、文書など-カメラが故障し、アプリケーションのある手紙がすぐに消えて、必要な文書が作成されるなど）。 サービス部門の同じレポート、アプリケーションの処理に関する概要レポート、およびインシデントに関する詳細レポート。 ほとんどの作業は2014年です。
• 市民の訴え ：分類による半自動チケットシステム、必要な構造へのチケットの転送、CPPKのすべての部門との作業があり、規制期限の実施を監視します。 少し後にITSMがファイルの保存（苦情、応答テキストなどのスキャン）の最終決定を行いました。その後、CACディスパッチャや停止センターのCACワークステーションの従業員に連絡するためのチケットをセットアップする必要がありました。 インシデントに関する詳細なレポートが実装され、統合レポートが計画されています。
• 旅客サービスに影響するイベントについてCPPC従業員に警告します。 これは、列車監視サブシステムから受信した情報に従って、列車が予定より遅れている場合の「スケジュール」カテゴリのインシデントの自動記録です。 パイロットゾーンの10ステーションは、自動的に「境界交差点」イベントをブロードキャストします（結果に基づいて-より多くのセキュリティ担当者を配置する方が簡単です、あまりにも頻繁に控除します）。 TsPPKは、乗客のサービスに影響を与えるイベント、特に電車のスケジュールからの逸脱に関する電子メールおよびSMSメッセージを介して。 レポートの作成：異常なイベント、怪我のインシデント、レポート、トリガーの登録。 その後、彼らは遠方の駅への非常に遅い列車に関する情報を台無しにした。 報告によると、標準で要求されている自動補充が行われます。
• 情報および分析のサポートのために、 CPPKの専門家は、さまざまなカテゴリのインシデントのソースからデータを受け取り、新しい産業プラットフォーム（Oracle BI）を導入し、運用レポートのデザイナーを構成し、基本レポートを新しいパネルに移動しました（既に使用できるように）。 その後、他の方向に現れるものを徐々にねじりました。
• 障害を検出し、停止点で修正するプロセスへの関与 。 とりわけ-ステーションの従業員のための「戦術的なビュー」へのアクセス権を持つ38ステーションAWPで展開。
• 停留所での現在のスケジュール ：2013年に、列車のスケジュールはカザン方向の10の停留所で表示されました。 その後、15の追加駅に、列車のスケジュールを表示するために83台のモニターが設置されました。 Vykhino駅での関税のパイロット撤回が実施されました。 乗客から受け取った提案によると、スケジュール出力は最適化されています。現在、両方向（モスクワからモスクワまで）のスケジュールが1つの画面に表示されています。 現在、モスクワとその地域の25の鉄道駅に170台のディスプレイが設置されています。
• 緊急通信 ：緊急緊急通信を行い、緊急通信ボタン付きのラックを設置しました。
• シチュエーションセンターの場合 ：ディスパッチセンターが実装されています。 CPPKの従業員が機器のリファレンスブックを管理するためのインターフェイスを開発し、BPAディレクトリの初期入力が完了しました。 さらに、たとえば、サービス提供のレベルに関する契約の満了に関する関係者への通知の自動送信、機器ディレクトリ内のBPAカードの属性の構成が拡張され、旅客機器施設のディレクトリを維持するための機器ディレクトリのインターフェイスが改善されました。
• 列車の動きの監視 ： 列車の動きを監視するためのサブシステムが実装されました（多くのセンサーが車に押し込まれました）。 レポート「モーションスケジュール」は洗い流され、スケジュールマネージャーと車両の情報パネルが実装されました。 電車にセンサーを設置し続けています。
• 外部の相互作用 ：外部のリソース、特にロシアの鉄道との情報交換は、時刻表や停止ディレクトリを含む15のディレクトリへのアクセスを提供するために実装されました。

誰がそのような物語を知っている-すべてのフレーズのために、少なくとも数ヶ月間、少なくとも十数人の地獄のような仕事。 タスクは、単純なもの（「すべての列車にグリースを塗って鉄をつける」）から複雑なもの（「レポートにCPPKのすべての機器の情報を表示する」など）でした。 実用的なエンジニア、アナリスト、アーキテクト、管理者、そしてもちろん開発者のために多くの仕事がありました。



私はこのプロジェクトに参加し続けています。 プロジェクトまたはその詳細について質問がある場合（ここで同僚-サイトの責任者であるチームリーダーの助けを求めます）、可能なことについてコメントでお伝えします。 しかし、すべてが可能であるとは限らず、鉄道は情報の公開性という点でまだ非常に具体的であると言わなければなりません。



質問がある場合は、コメントで質問するか、asmirnov @ croc.ruに連絡してください。