特表 2024-533429 鉄道指令管理用のシステム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-09-12

(54)【発明の名称】鉄道指令管理用のシステム及び方法

(51)【国際特許分類】

   B61L 23/00 20060101AFI20240905BHJP

   B61L 27/53 20220101ALI20240905BHJP

【ＦＩ】

B61L23/00 E

B61L27/53

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2024515588

(86)(22)【出願日】2022-07-27

(85)【翻訳文提出日】2024-05-02

(86)【国際出願番号】 US2022038487

(87)【国際公開番号】W WO2023038728

(87)【国際公開日】2023-03-16

(31)【優先権主張番号】17/473,484

(32)【優先日】2021-09-13

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】520050554

【氏名又は名称】ビーエヌエスエフ・レイルウェイ・カンパニー

【氏名又は名称原語表記】ＢＮＳＦ ＲＡＩＬＷＡＹ ＣＯＭＰＡＮＹ

【住所又は居所原語表記】２５００ Ｌｏｕ Ｍｅｎｋ Ｄｒｉｖｅ， ＡＯＢ ３， Ｆｏｒｔ Ｗｏｒｔｈ， ＴＸ ７６１３１， Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】100110423

【弁理士】

【氏名又は名称】曾我 道治

(74)【代理人】

【識別番号】100111648

【弁理士】

【氏名又は名称】梶並 順

(74)【代理人】

【識別番号】100221729

【弁理士】

【氏名又は名称】中尾 圭介

(72)【発明者】

【氏名】ピッカード、クリストファー・ニール

(72)【発明者】

【氏名】ウィリアムズ、カイル・キールティ

(72)【発明者】

【氏名】ハリソン、グレゴリー

(72)【発明者】

【氏名】ヘルム、ジェイムズ

【テーマコード（参考）】

5H161

【Ｆターム（参考）】

5H161AA01

5H161BB02

5H161BB20

5H161CC02

5H161FF07

5H161MM01

(57)【要約】

鉄道指令管理用のシステムが提示されている。システムは、指令、軌道セグメント、及び／又は軌道上の車両イベント及び／又は軌道セグメントに関係する多数のデータを受け取ることができる。車両及び／又はイベント固有のデータは、指令変更がインスタンス生成されるべきかどうか及びインスタンス生成されるべき指令変更の種類を判定するために、力閾値、時間閾値、環境閾値、及び／又はイベント閾値を含む１つ又は複数の閾値と比較することができる。指令に関係するセグメントが横断されているかどうかを判定するために軌道に沿った車両経路をトレーシングするように、専門的なアルゴリズムを実装することが可能であり、且つ、セグメントごとに特定のセグメントに固有のデータをクラスタ化するために、専門的なクラスタリングアルゴリズムを使用することができる。システムは、既存の軌道インフラストラクチャと統合されることが可能であり、且つ、更には、指令及び／又はその変更について結合されたシステム及び／又は要員に通知するためにアラートを生成することができる。

【特許請求の範囲】

【請求項1】

鉄道軌道内の軌道セグメント力を監視するシステムであって、
鉄道軌道及び少なくとも１つの資産に関係する複数のデータ、閾値、及び仕様を有する第１データベースを有するメモリと、
前記メモリに動作自在に結合された且つプログラムステップを実行するために機械可読命令を実行する能力を有するコンピュータプロセッサと、
を有し、前記プログラムステップは、
指令データ及び軌道に関係する軌道データを受け取るステップと、
前記プロセッサを介して、前記軌道データと関連する複数の軌道セグメントを識別するステップと、
前記指令データを少なくとも第１軌道セグメントと関連付けるステップと、
前記軌道上において配設された資産を識別するステップと、
資産データ及び前記資産に関係する位置データポイントを受け取るステップと、
前記位置データポイントを使用して前記軌道に沿った前記資産の経路を算出するステップと、
前記経路又は前記位置データポイントの少なくとも１つが前記第１軌道セグメントを横断するかどうかを判定するステップと、
前記プロセッサを介して、前記経路又は前記位置データポイントの少なくとも１つが前記第１軌道セグメントを横断している場合に前記第１軌道セグメントと関連する前記資産データを有する第１セグメントデータクラスタを生成するステップと、
前記第１セグメントデータクラスタを使用して前記第１軌道セグメントに印加されている合計力を算出するステップと、
少なくとも前記第１合計力を使用することにより、最小合計力を判定するステップと、
前記最小合計力が力閾値を充足している場合に第１アラートを生成するステップと、
を含む、システム。

【請求項2】

前記プログラムステップは、前記指令データを前記複数の軌道セグメントの第２軌道セグメントと関連付けるステップを更に含む、請求項１に記載のシステム。

【請求項3】

前記プログラムステップは、
前記経路が前記第２軌道セグメントを横断している場合に前記資産データを前記第２軌道セグメントと関連する第２セグメントデータクラスタ内において包含するステップを更に含む、請求項２に記載のシステム。

【請求項4】

前記プログラムステップは、
前記第２セグメントデータクラスタを使用して前記第２軌道セグメントに印加されている第２合計力を算出するステップと、
前記第１合計力を前記第２合計力と比較するステップと、
前記第１合計力及び前記第２合計力を使用して第２最小合計力を判定するステップと、
を更に含む、請求項３に記載のシステム。

【請求項5】

前記プログラムステップは、前記最小合計力が力閾値を充足している場合に第１指令変更をインスタンス生成するステップを更に含む、請求項１に記載のシステム。

【請求項6】

前記プログラムステップは、識別子を前記複数の軌道セグメントのそれぞれに割り当てるステップを更に含む、請求項１に記載のシステム。

【請求項7】

前記指令データは、減速命令を含む、請求項１に記載のシステム。

【請求項8】

前記第１指令変更は、前記減速命令を破棄するステップを含む、請求項７に記載のシステム。

【請求項9】

前記指令データは、圧縮減速命令を含む、請求項１に記載のシステム。

【請求項10】

前記プログラムステップは、タイムスタンプを受け取るステップを更に含む、請求項１に記載のシステム。

【請求項11】

前記プログラムステップは、前記タイムスタンプが第１時間閾値を充足している場合に第２アラートを生成するステップを更に含む、請求項１０に記載のシステム。

【請求項12】

前記プログラムステップは、前記タイムスタンプが第１時間閾値を充足している場合に指令変更をインスタンス生成するステップを更に含む、請求項１０に記載のシステム。

【請求項13】

鉄道に関係する指令を制御するシステムであって、
鉄道軌道及び少なくとも１つの資産に関係する複数のデータ、閾値、及び仕様を有する第１データベースを有するメモリと、
前記メモリに動作自在に結合された且つプログラムステップを実行するために機械可読命令を実行する能力を有するコンピュータプロセッサと、
を有し、前記プログラムステップは、
指令データ及び軌道に関係する軌道データを受け取るステップと、
前記プロセッサにより、前記軌道データと関連する複数の軌道セグメントを識別するステップと、
前記指令データを前記複数の軌道セグメントの少なくとも第１軌道セグメントと関連付けるステップと、
少なくとも前記第１軌道セグメントに関係する第１イベント基準を判定するステップと、
前記軌道上において配設された資産を識別するステップと、
資産データ及び前記資産に関係する位置データポイントを受け取るステップと、
前記位置データポイントを使用して前記軌道に沿った前記資産の経路を算出するステップと、
前記経路又は前記位置データポイントの少なくとも１つが前記第１軌道セグメントを横断しているかどうかを判定するステップと、
前記経路又は前記位置データポイントの少なくとも１つが前記第１軌道セグメントを横断している場合に前記資産データを前記第１イベント基準と比較するステップと、
前記資産データが前記第１イベント基準を充足している場合に前記第１軌道セグメントと関連する第１イベントカウントを増分するステップと、
前記第１軌道セグメントと関連する少なくとも前記第１イベントカウントを使用することにより、最小第１イベントカウントを判定するステップと、
前記最小第１イベントカウントが第１イベント閾値を充足している場合に第１アラートを生成するステップと、
を含む、システム。

【請求項14】

前記第１イベント基準は、第１速度閾値を含む、請求項１３に記載のシステム。

【請求項15】

前記プログラムステップは、前記指令データを前記複数の軌道セグメントの第２軌道セグメントと関連付けるステップを更に含む、請求項１３に記載のシステム。

【請求項16】

前記プログラムステップは、
前記経路が前記第２軌道セグメントを横断している場合に、
前記資産データを前記第１イベント基準と比較するステップと、
前記資産データが前記第１イベント基準を充足している場合に前記第２軌道セグメントと関連する第１イベントカウントを増分するステップと、
を更に含む、請求項１５に記載のシステム。

【請求項17】

前記プログラムステップは、
前記第１及び第２軌道セグメントと関連する前記第１イベントカウントを比較するステップと、
少なくとも前記第１軌道セグメントと関連する前記第１イベントカウント及び前記第２軌道セグメントと関連する前記第１イベントカウントを使用して前記最小第１イベントカウントを判定するステップと、
を更に含む、請求項１６に記載のシステム。

【請求項18】

前記プログラムステップは、第２イベント基準を判定するステップを更に含む、請求項１３に記載のシステム。

【請求項19】

前記プログラムステップは、前記経路又は前記位置データポイントの少なくとも１つが前記第１軌道セグメントを横断している場合に、且つ、前記最小第１イベントカウントが前記第１イベント閾値を充足している場合に、前記資産データを前記第２イベント基準と比較するステップを更に含む、請求項１８に記載のシステム。

【請求項20】

前記プログラムステップは、前記資産データが前記第２イベント基準を充足している場合に前記第１軌道セグメントと関連する第２イベントカウントを増分するステップを更に含む、請求項１９に記載のシステム。

【請求項21】

前記プログラムステップは、少なくとも前記第１軌道セグメントと関連する前記第２イベントカウントを使用して最小第２イベントカウントを判定するステップを更に含む、請求項２０に記載のシステム。

【請求項22】

前記第２イベント基準は、第２速度閾値を含む、請求項１８に記載のシステム。

【請求項23】

前記プログラムステップは、前記最小第１イベントカウントが第１イベント閾値を充足している場合に指令変更をインスタンス生成するステップを更に含む、請求項１３に記載のシステム。

【請求項24】

前記指令変更は、減速命令を変更するステップを含む、請求項２３に記載のシステム。

【請求項25】

前記プログラムステップは、前記最小第２イベントカウントが第２イベント閾値を充足している場合に第２アラートを生成するステップを更に含む、請求項２１に記載のシステム。

【請求項26】

前記資産は、列車である、請求項１３に記載のシステム。

【請求項27】

鉄道と関係する指令を管理する際に環境状態について補償する方法であって、
暗号化されたネットワークを介して、指令データ及び軌道に関係する軌道データを受け取るステップと、
プロセッサを介して、前記軌道データと関連する複数の軌道セグメントを識別するステップと、
前記指令データを前記複数の軌道セグメントの少なくとも第１軌道セグメントと関連付けるステップと、
前記軌道上において配設された資産を識別するステップと、
資産データ及び前記資産に関係する位置データポイントを受け取るステップと、
環境データを受け取るステップと、
複数のイベント基準を判定するステップと、
プロセッサを介して、前記位置データポイントを使用して前記軌道に沿った前記資産の経路を算出するステップと、
前記経路又は前記位置データポイントの少なくとも１つが前記第１軌道セグメントを横断しているかどうかを判定するステップと、
前記プロセッサを介して、前記経路又は前記位置データポイントの少なくとも１つが前記第１軌道セグメントを横断している場合に前記環境データが第１環境閾値を充足していると判定するステップと、
前記環境データが前記第１環境閾値を充足している場合に前記資産データを前記複数のイベント基準の第１イベント基準と比較するステップと、
前記資産データが前記第１イベント基準を充足している場合に前記第１軌道セグメントと関連する第１イベントカウントを増分するステップと、
前記第１軌道セグメントと関連する前記第１イベントカウントが第１イベント閾値を充足している場合に第１指令変更をインスタンス生成するステップと、
を有する方法。

【請求項28】

前記第１イベント閾値が充足されている場合に前記資産データを前記複数のイベント基準の第２イベント基準と比較するステップを更に有する、請求項２７に記載の方法。

【請求項29】

前記資産データが前記第２イベント基準を充足している場合に前記第１軌道セグメントと関連する第２イベントカウントを増分するステップと、
前記第１軌道セグメントと関連する前記第２イベントカウントが第２イベント閾値を充足している場合に第２指令変更をインスタンス生成するステップと、
を更に有する、請求項２８に記載の方法。

【請求項30】

前記環境閾値は、温度閾値である、請求項２７に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、一般に、バラスト障害に起因して発令された指令などとの関係における鉄道インフラストラクチャにおける減速命令などの指令の管理に関する。

【背景技術】

【0002】

レール輸送システムは、世界全体を通じた乗客及び物品の輸送及び供給を可能にするためにすべての大陸を横断している。鉄道インフラストラクチャの典型的なコンポーネントは、無数の地形及び地勢において敷設された軌道であり、鉄道軌道は、要素の最悪の事態に耐えるように且つ鉄道システムの全体を通じて機関車の支出を促進するように設計されている。このような危険な状態に対する軌道の不断の曝露に起因して、鉄道会社は、軌道の完全性の維持に注意を払わなければならず、軌道のセクションが損なわれ且つ損傷又は障害が迅速に対処されない場合には、結果は、悲劇的なのものとなり得る。

【0003】

軌道の一般的な構造は、いくつかのコンポーネントを含むことができる。一般には、多くの場合に破砕された石、砂利、又はその他の骨材から構成されるバラストと呼称される基礎が、軌道が敷設され得る圧縮された通路を提供しており、バラストの上部には、レール及び枕木が存在している。レールは、レール車両の車輪がその上部において転動し得る実際の表面を提供している。レールは、数千マイルにわたって互いに平行に延在しており、且つ、レール車両の車輪スパンは、軌道フットプリントにマッチングするように特別に設計及びサイズ設定されている。レールが横方向において分離した場合には、結果は、悲惨なものとなろう。従って、レールの間において一貫性のある且つ均一な距離を維持するために、枕木と呼称される横方向のスラット様のコンポーネントがレールの間において配設され且つこれらに結合されている。枕木は、木材、コンクリート、又は任意のその他の適切な材料であることが可能であり、且つ、枕木は、軌道の安定性を促進するために、バラストに又はその内部において固定することができる。枕木は、極端なレールトラフィックの重量がレールの分離をもたらさないように、レールの間の横方向張力の維持を支援するという非常に重要な目的を果たしている。

【0004】

枕木が横方向張力の維持において役割を果たしている一方で、別の主要なコンポーネントがバラストである。レールコンポーネントの周りのバラストの圧縮は、特に横方向のレール張力の維持との関係において、レールの安定性を格段に改善している。バラストは、バラストが支持しているレール上において継続的に移動する数百万又は数十億ポンドによって圧縮されている。バラストセクションの圧縮を妨げる軌道の保守作業（枕木交換、表面処理、など）が実行された際には、その場所における軌道の完全性が損なわれる可能性があり、その結果、フルスピードの列車がそのエリア上において移動することができなくなる。例えば、圧縮不足のバラストセクションを有する場所は、軌道構造（例えば、枕木及びレール）が様々な条件（温度、長手方向の力、制動力、など）に起因してアライメント状態を脱するように運動する相対的に大きなリスクを有する。軌道構造のミスアライメントを回避するために、しばしば「減速命令」と呼称される速度制限及び／又はその他の指令を乱れたバラストを有する特定の長さの軌道に対して発することができる。「減速命令」は、不良な軌道品質、気象現象、又はその他の状況などの既知の又は潜在的な低水準の軌道状態に起因した列車の脱線から乗員、列車、貨物、施設、及び一般大衆を保護することを意図した、列車運行に対して適用される一時的な速度制限である。

【発明の概要】

【発明が解決しようとする課題】

【0005】

但し、鉄道システムの効率も主要な懸念事項であることから、軌道の完全性との関係におけるこのような警戒は、列車のスループットと均衡させなければならない。相対的に低い速度において運行している列車は、ネットワークの速度を低減させる。減速命令の影響は、減速命令が発令されていなかった場合の最大認可速度との比較における減速命令範囲の距離における減速命令速度に基づき得る遅延分数を単位として計測することができる。

【課題を解決するための手段】

【0006】

本開示は、鉄道インフラストラクチャとの関係における指令管理用のシステム及び方法としての技術的利点を実現している。システムは、１つ又は複数の軌道セグメント上において発生する複数のイベントを考慮することが可能であり（can account a plurality of events）、且つ、このようなイベントが指令変更又は除去を目的として処理されるべき方式を判定するためにイベントデータを１つ又は複数のイベント閾値と比較することができる。システムは、更には、システムの閾値処理ロジックに伝達され得るセグメント固有のディスクリプタを生成し、これにより、システムが指令変更を判定する際に個々に対処されるべき指令エリア内のそれぞれのセグメントを考慮することを許容するために、セグメント固有のデータクラスタリングを実装することができる。システムは、鉄道軌道内の電流（及び／又はその障害）を介して生成され得るデータポイントを受け取ることが可能であり、且つ、車両が移動している又は移動していた軌道セグメントを識別するためにこのようなデータポイントを利用することが可能であり、且つ、更には、データポイントがシステムによって受け取られなかった軌道セグメントを車両が移動したかどうかをシステムが認識することを可能にし得る車両経路を判定するためにトレーシングロジック内においてこのようなデータポイントを更に実装することができる。システムは、複数のデータ及びその変形が、充足又はそのような閾値（satisfaction or such thresholds）の際に指令を変更し得る且つこれによって所与の鉄道軌道上における列車のスループットを大幅に増大し得る力閾値、温度閾値、及び又はイベント閾値などの１つ又は複数の閾値に基づいて自動化された指令変更ツールを提供し得るという点において、大きな技術的利点を実現している。

【0007】

本開示は、所与の指令に固有であり得る特定のイベント基準を充足する特定数のイベントの発生に基づいた指令の変更を可能し、これにより、事実上、１つ又は複数の指令の影響を受けた軌道のエリアにおいて最大スループットを保証するようにリアルタイムで所与の指令を適合させることにより、指令を考慮しつつ、列車のスループットを改善するという技術的問題を解決している。本開示は、指令データを受け取ることが可能であり、データを１つ又は複数の個々の軌道セグメントと関連付けることが可能であり、車両経路を判定することが可能であり、このような経路がセグメントを横断しているかどうかを判定することが可能であり、セグメント固有のデータクラスタを維持することが可能であり、このようなクラスタを１つ又は複数の閾値（力、イベント、及び／又は時間閾値を含む）と比較することが可能であり、指令がクラスタ／閾値比較の結果に基づいて変更されるべき方式を判定することが可能であり、且つ、このような指令変更をインスタンス生成することができる。

【0008】

本開示は、指令、関連する軌道セグメント、及びこのようなセグメントを横断する車両経路に関係するデータを受け取るように、利用するように、且つ生成するように適合された専門的なアルゴリズムを実装することにより、システムの性能及び機能を改善している。システムは、例えば、データポイントが不連続となるように連続的な軌道セグメントが車両存在の検出に失敗した際に、ある程度不完全なデータから車両経路を解明するためのトレーシングアルゴリズムを実装することができる。システムは、更には、イベント及び関係する指令に関する有意なアラート、通知、及びデータを提供するために、既存の軌道インフラストラクチャ及びシステムと統合することができる。システムは、例えば、鉄道運行の安全性及び効率性の両方を極大化させるためにセグメント固有のクラスタを生成するように、受け取られたデータを変換し且つ専門的なアルゴリズムにおいてこのような変換されたデータを実装するなどにより、鉄道運行の複数のエリア及び出口との関係において生成されたデータなどの「ビッグデータ」の有意な且つ極めて有利な使用を提供している。

【0009】

開示されている鉄道指令管理システムは、データベース、クライアント、積極型列車制御システム、及び／又は列車管理及びディスパッチシステムとの動作自在の通信状態にあるサーバーを含むことができる。鉄道指令管理システムは、更には、車両を検出するように、距離、位置、場所を計測するように、且つ／又は軌道及び／又は車両に関係するデータをキャプチャ及び／又は受信するように設計された複数のセンサ、ゲージ、レシーバ、トランシーバ、カメラ、サイレン、スピーカ、ライト、又は任意のその他の適切な装置又はメカニズムとの動作自在の接続状態にあり得る。鉄道指令管理システムは、指令データ、車両データ、セグメントクラスタ、閾値、タイムスタンプ、車両アイデンティティ、車両速度、車両方向、作業時刻及び日付、閾値充足の時刻及び日付、ディビジョンデータ、及び／又は任意のその他の関連データを含む関連データを収容するレコードを生成することができる。夜間除去プロセスに伴って、減速命令が朝において再発行される必要がある場合には、システムは、定期的に（例えば、３０分ごとに）チェックすることが可能であり、且つ、エスカレーション電子メールを１つ又は複数の関係者に送信することができる。

【0010】

１つ又は複数の指令変更及び／又はこのような変更に関係するアラートを生成することにより、マスデータの有意な使用を提供するシステムを提供することが本開示の目的の１つである。軌道及び／又は指令及び／又はセグメント固有のデータに基づいて指令を発令、変更、及び除去する方法を提供することが本開示の更なる目的である。これらの及びその他の目的は、少なくとも以下の実施形態によって提供されている。

【0011】

一実施形態において、本開示は、鉄道軌道内において軌道セグメント力を監視するシステムを含むことが可能であり、システムは、鉄道軌道及び少なくとも１つの資産に関係する複数のデータ、閾値、及び仕様を有する第１データベースを有するメモリと、メモリに動作自在に結合された且つプログラムステップを実行するために機械可読命令を実行する能力を有するコンピュータプロセッサと、を有し、プログラムステップは、指令データ及び軌道に関係する軌道データを受け取るステップと、プロセッサを介して、軌道データと関連する複数の軌道セグメントを識別するステップと、指令データを少なくとも第１軌道セグメントと関連付けるステップと、軌道上において配設された資産を識別するステップと、資産データ及び資産に関係する位置データポイントを受け取るステップと、位置データポイントを使用して軌道に沿った資産の経路を算出するステップと、経路又は位置データポイントの少なくとも１つが第１軌道セグメントを横断しているかどうかを判定するステップと、プロセッサを介して、経路又は位置データポイントの少なくとも１つが第１軌道セグメントを横断している場合に第１軌道セグメントと関連する資産データを有する第１セグメントデータクラスタを生成するステップと、第１セグメントデータクラスタを使用して第１軌道セグメントに印加されている合計力を算出するステップと、少なくとも第１合計力を使用して最小合計力を判定するステップと、最小合計力が力閾値を充足している場合に第１アラートを生成するステップと、を含む。この場合に、プログラムステップは、指令データを複数の軌道セグメントの第２軌道セグメントと関連付けるステップを更に含む。この場合に、プログラムステップは、経路が第２軌道セグメントを横断している場合に資産データを第２軌道セグメントと関連する第２セグメントデータクラスタ内において包含するステップを更に含む。この場合に、プログラムステップは、第２セグメントデータクラスタを使用して第２軌道セグメントに印加されている第２合計力を算出するステップと、第１合計力を第２合計力と比較するステップと、第１合計力及び第２合計力を使用して第２最小合計力を判定するステップ、を更に含む。この場合に、プログラムステップは、最小合計力が力閾値を充足している場合に第１指令変更をインスタンス生成するステップを更に含む。この場合に、プログラムステップは、識別子を複数の軌道セグメントのそれぞれに割り当てるステップを更に含む。この場合に、指令データは、減速命令を含む。この場合に、第１指令変更は、減速命令を破棄するステップを含む。この場合に、指令データは、圧縮減速命令を含む。この場合に、プログラムステップは、タイムスタンプを受け取るステップを更に含む。この場合に、プログラムステップは、タイムスタンプが第１時間閾値を充足している場合に第２アラートを生成するステップを更に含む。この場合に、プログラムステップは、タイムスタンプが第１時間閾値を充足している場合に指令変更をインスタンス生成するステップを更に含む。

【0012】

別の実施形態において、本開示は、鉄道に関係する指令を制御するシステムを含むことが可能であり、システムは、鉄道軌道及び少なくとも１つの資産に関係する複数のデータ、閾値、及び仕様を有する第１データベースを有するメモリと、メモリに動作自在に結合された且つプログラムステップを実行するために機械可読命令を実行する能力を有するコンピュータプロセッサと、を有し、プログラムステップは、指令データ及び軌道に関係する軌道データを受け取るステップと、プロセッサにより、軌道データと関連する複数の軌道セグメントを識別するステップと、指令データを複数の軌道セグメントの少なくとも第１軌道セグメントと関連付けるステップと、少なくとも第１軌道セグメントと関係する第１イベント基準を判定するステップと、軌道上において配設された資産を識別するステップと、資産データ及び資産に関係する位置データポイントを受け取るステップと、位置データポイントを使用して軌道に沿った資産の経路を算出するステップと、経路又は位置データポイントの少なくとも１つが第１軌道セグメントを横断しているかどうかを判定するステップと、経路又は位置データポイントの少なくとも１つが第１軌道セグメントを横断している場合に資産データを第１イベント基準と比較するステップと、資産データが第１イベント基準を充足している場合に第１軌道セグメントと関連する第１イベントカウントを増分するステップと、第１軌道セグメントと関連する少なくとも第１イベントカウントを使用して最小第１イベントカウントを判定するステップと、最小第１イベントカウントが第１イベント閾値を充足している場合に第１アラートを生成するステップと、を含む。この場合に、第１イベント基準は、第１速度閾値を含む。この場合に、プログラムステップは、指令データを複数の軌道セグメントの第２軌道セグメントと関連付けるステップを更に含む。この場合に、プログラムステップは、経路が第２軌道セグメントを横断している場合に資産データを第１イベント基準と比較するステップと、資産データが第１イベント基準を充足している場合に第２軌道セグメントと関連する第１イベントカウントを増分するステップと、を更に含む。この場合に、プログラムステップは、第１及び第２軌道セグメントと関連する第１イベントカウントを比較するステップと、少なくとも第１軌道セグメントと関連する第１イベントカウント及び第２軌道セグメントと関連する第１イベントカウントを使用して最小第１イベントカウントを判定するステップと、を更に含む。この場合に、プログラムステップは、第２イベント基準を判定するステップを更に含む。この場合に、プログラムステップは、経路又は位置データポイントの少なくとも１つが第１軌道セグメントを横断している場合に且つ最小第１イベントカウントが第１イベント閾値を充足している場合に資産データを第２イベント基準と比較するステップを更に含む。この場合に、プログラムステップは、資産データが第２イベント基準を充足している場合に第１軌道セグメントと関連する第２イベントカウントを増分するステップを更に含む。この場合に、プログラムステップは、第１軌道セグメントと関連する少なくとも第２イベントカウントを使用して最小第２イベントカウントを判定するステップを更に含む。この場合に、第２イベント基準は、第２速度閾値を含む。この場合に、プログラムステップは、最小第１イベントカウントが第１イベント閾値を充足している場合に指令変更をインスタンス生成するステップを更に含む。この場合に、指令変更は、減速命令を変更するステップを含む。この場合に、プログラムステップは、最小第２イベントカウントが第２イベント閾値を充足している場合に第２アラートを生成するステップを更に含む。この場合に、資産は列車である。

【0013】

別の実施形態において、本開示は、鉄道に関係する指令の管理において環境状態について補償する方法を含むことが可能であり、方法は、暗号化されたネットワークを介して、指令データ及び軌道に関係する軌道データを受け取るステップと、プロセッサを介して、軌道データと関連する複数の軌道セグメントを識別するステップと、指令データを複数の軌道セグメントの少なくとも第１軌道セグメントと関連付けるステップと、軌道上において配設された資産を識別するステップと、資産データ及び資産の関係する位置データポイントを受け取るステップと、環境データを受け取るステップと、複数のイベント基準を判定するステップと、プロセッサを介して、位置データポイントを使用して軌道に沿った資産の経路を算出するステップと、経路又は位置データポイントの少なくとも１つが第１軌道セグメントを横断しているかどうかを判定するステップと、プロセッサにより、経路又は位置データポイントの少なくとも１つが第１軌道セグメントを横断している場合に環境データが第１環境閾値を充足していると判定するステップと、環境データが第１環境閾値を充足している場合に資産データを複数のイベント基準の第１イベント基準と比較するステップと、資産データが第１イベント基準を充足している場合に第１軌道セグメントと関連する第１イベントカウントを増分するステップと、第１軌道セグメントと関連する第１イベントカウントが第１イベント閾値を充足している場合に第１指令変更をインスタンス生成するステップと、を有する。第１イベント閾値が充足されている場合に資産データを複数のイベント基準の第２イベント基準と比較するステップを更に有する。資産データが第２イベント基準を充足している場合に第１軌道セグメントと関連する第２イベントカウントを増分するステップと、第１軌道セグメントと関連する第２イベントカウントが第２イベント閾値を充足している場合に第２指令変更をインスタンス生成するステップと、を更に有する。この場合に、環境閾値は温度閾値である。

【0014】

本開示については、例として本開示の原理を示す添付図面との関連において提供されている以下の詳細な説明により、容易に理解することができよう。図面は、本開示の１つ又は複数の例示用の実施形態の設計及び有用性を示しており、この場合に、同一の要素は、同一の参照符号又はシンボルによって参照されている。図面中の物体及び要素は、必ずしも、正確な縮尺、割合、又は正確な位置関係において描かれてはいない。その代わりに、本開示の原理の例示に重点が合焦されている。

【図面の簡単な説明】

【0015】

【図1】本開示の１つ又は複数の例示用の実施形態による圧縮トラッキングシステムの概略図を示す。

【図2】本開示の１つ又は複数の例示用の実施形態による圧縮に関係する減速命令管理システムの例示用のブロック図を示す。

【図3A】本開示の１つ又は複数の例示用の実施形態による指令制御システムを例示するフローチャートを示す。

【図3B】本開示の１つ又は複数の例示用の実施形態による指令制御システムを例示するフローチャートを示す。

【図3C】本開示の１つ又は複数の例示用の実施形態による指令制御システムを例示するフローチャートを示す。

【図4A】本開示の１つ又は複数の例示用の実施形態による指令変更システムを例示するフローチャートを示す。

【図4B】本開示の１つ又は複数の例示用の実施形態による指令変更システムを例示するフローチャートを示す。

【図5】本開示の１つ又は複数の例示用の実施形態による圧縮監視システムを例示するフローチャートを示す。

【図6】本開示の１つ又は複数の例示用の実施形態による力トラッキングシステムを例示するフローチャートを示す。

【図7】本開示の１つ又は複数の例示用の実施形態によるトン数判定システムを例示するフローチャートを示す。

【図8A】本開示の１つ又は複数の例示用の実施形態による減速命令除去システムを例示するフローチャートを示す。

【図8B】本開示の１つ又は複数の例示用の実施形態による減速命令除去システムを例示するフローチャートを示す。

【図9】本開示の１つ又は複数の例示用の実施形態による指令管理統合システムを例示するフローチャートを示す。

【図10】本開示の１つ又は複数の例示用の実施形態による軌道セグメント上の力をトラッキングする方法のブロック図を示す。

【図11】本開示の１つ又は複数の例示用の実施形態による指令管理トラッキングチャートの例示用のレンダリングを示す。

【発明を実施するための形態】

【0016】

添付図面に含まれている且つ以下の説明において詳述されている非限定的な例を参照し、以下の記述説明において提示されている本開示の好適なバージョン及びその様々な特徴及び有利な詳細について更に十分に説明する。周知のコンポーネントの説明は、本明細書に記述されている主要な特徴を不必要に曖昧にすることのないように省略されている。以下の説明において使用されている例は、本開示が実装及び実施され得る方法の理解を促進することを意図したものである。従って、これらの例は、請求項の範囲を限定するものとして解釈してはならない。

【0017】

図１は、本開示の１つ又は複数の実施形態による圧縮トラッキングシステム１００の概略図を示している。システム１００は、データベース１０４に動作自在に結合された１つ又は複数のサーバー１０２を含むことができる。サーバー１０２は、ネットワーク接続１０６を介して１つ又は複数のクライアント１０８、１１０、１１２、１１４、１１６、１１８、１１２０に動作自在に結合することができる。クライアントは、物理的装置（例えば、携帯電話機１１２、コンピュータ１１０、１１６、タブレット１１８、車両１２０、オンボードコンピュータ、ウェアラブル装置、作業者、作業者に関係する装置、アラート装置、又はその他の適切な装置）、プログラム、又はアプリケーションであり得る。一例において、クライアントは、ウォッチ、スマートウォッチ、トーテム、トークン、バッジ、又はその他の任意のその他のウェアラブル装置を含むことができる。別の実施形態において、サーバー１０２は、ネットワーク１０６を介して積極型列車制御（ＰＴＣ）システム１０８に動作自在に結合することができる。例えば、ＰＴＣシステム１０８は、当技術分野において既知のものと同様であり得る。別の例において、ＰＴＣシステム１０８は、車両及び作業者データを受け取り且つ／又は取得し且つデータをサーバー１０２に送信する能力を有するサーバー１０２との動作自在の接続状態にあるネットワーク接続されたコンピュータ１０８であり得る。別の実施形態において、サーバー１０２は、ネットワーク１０６を介して列車管理及びディスパッチ（ＴＭＤＳ）システム１１０に動作自在に結合することができる。例えば、ＴＭＤＳシステム１１０は、当技術分野において既知であるものと同様であり得る。別の例において、ＴＭＤＳシステム１１０は、車両、軌道、保守、及び／又は作業者データを受け取り且つ／又は取得し且つ／又はデータをサーバー１０２に送信する能力を有するサーバー１０２との動作自在の接続状態にあるネットワーク接続されたコンピュータ１１０であり得る。別の実施形態において、サーバー１０２は、レール車両などの車両１２０との動作自在の通信状態にあり得る。例えば、システム１００は、レール車両１２０がサーバー１０２との間においてデータを受信及び／又は送信することができるように構成することができる。

【0018】

システム１００は、鉄道に関係する指令の生成、発布、変更、及び／又は終了を促進するために鉄道システム又は鉄道インフラストラクチャと統合することができる。当業者は、システム１００によって包含されている検出、キャプチャされたデータ、計測、判定、アラート、などが、ネットワーク１０６又はその他の動作自在の接続を介して、全体として鉄道システムに発布することが可能であり且つ／又は鉄道システムからアクセス可能であり得ることを理解するであろう。一実施形態において、サーバー１０２は、機械可読命令１２２を含むことが可能であり、且つ、別の実施形態において、サーバー１０２は、機械可読命令１２２にアクセスすることができる。別の実施形態において、機械可読命令は、指令生成モジュール１２４、指令変更モジュール１２６、データキャプチャモジュール１２８、トレーシングモジュール１３０、指令関連付けモジュール１３２、クラスタリングモジュール１３４、力判定モジュール１３６、イベント監視モジュール１３８、アラート生成モジュール１４０、及び／又はアラート供給モジュール１４２に関係する命令を含むことができる。

【0019】

上述のシステムコンポーネント（例えば、１つ又は複数のサーバー１０２、ＰＴＣシステム１０８、ＴＭＤＳシステム１１０、及び１つ又は複数のクライアント１１２、１１４、１１６、１１８、など）は、データが送信され得るように、ネットワーク１０６を介して互いに通信自在に結合することができる。ネットワーク１０６は、インターネット、イントラネット、又はその他の適切なネットワークであり得る。データ送信は、ＶＰＮトンネル又はその他の適切な通信手段上において暗号化、暗号解除することができる。ネットワーク１０６は、ＷＡＮ、ＬＡＮ、ＰＡＮ、又はその他の適切なネットワークタイプであり得る。クライアント、サーバー１０２、又は任意のその他のシステムコンポーネントの間におけるネットワーク通信は、ＰＧＰ、Ｂｌｏｗｆｉｓｈ、Ｔｗｏｆｉｓｈ、ＡＥＳ（登録商標）、３ＤＥＳ、ＨＴＴＰＳ、又はその他の適切な暗号化を使用して暗号化することができる。システム１００は、アプリケーションプログラミングインターフェイス（ＡＰＩ）、ＰＣＩ、ＰＣＩ－Ｅｘｐｒｅｓｓ（登録商標）、ＡＮＳＩ－Ｘ１２、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、又はその他の適切な通信プロトコル又は媒体を介して本明細書において開示されている様々なシステム、コンポーネント、及びモジュールを介して通信を提供するように構成することができる。これに加えて、サードパーティシステム及びデータベースをネットワーク１０６を介してシステムコンポーネントに動作自在に結合することもできる。

【0020】

システム１００のコンポーネント（例えば、サーバー１０２、ＰＴＣシステム１０８、ＴＭＤＳシステム１１０、及びクライアント）との間において送信されるデータは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）、ＴＣＰ／ＩＰ、ＸＭＬ、ＨＴＭＬ、ＡＳＣＩＩ、ＳＭＳ、ＣＳＶ、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）、又はその他の適切なフォーマットを含む任意のフォーマットを含むことができる。データ送信は、メッセージ、フラグ、ヘッダ、ヘッダプロパティ、メタデータ、及び／又はボディを含むことが可能であり、或いは、これらのものを有する任意の適切なフォーマットにより、カプセル化及びパケット化することもできる。

【0021】

１つ又は複数のサーバー１０２は、ハードウェア、ソフトウェア、又はこのためのハードウェア及びソフトウェアの適切な組合せにおいて実装することが可能であり、且つ、メモリ１０４に対するアクセスを有する１つ又は複数のプロセッサ１４４を有する１つ又は複数のサーバー上において動作する１つ又は複数のソフトウェアシステムを有することができる。１つ又は複数のサーバー１０２は、電子ストレージ、１つ又は複数のプロセッサ、及び／又はその他のコンポーネントを含むことができる。１つ又は複数のサーバー１０２は、ネットワーク１０６及び／又はその他の演算プラットフォームを介した情報の交換を可能にするために通信ライン、接続、及び／又はポートを含むことができる。また、１つ又は複数のサーバー１０２は、本明細書において１つ又は複数のサーバー１０２に帰せられている機能を提供するために協働する複数のハードウェア、ソフトウェア、及び／又はファームウェアコンポーネントを含むことができる。例えば、１つ又は複数のサーバー１０２は、ＳａａＳ（Ｓｏｆｔｗａｒｅ－ａｓ－ａ－Ｓｅｒｖｉｃｅ）及びＰａａＳ（Ｐｌａｔｆｏｒｍ－ａｓ－ａ－Ｓｅｒｖｉｃｅ）機能を含む１つ又は複数のサーバー１０２として協働する演算プラットフォームのクラウドによって実装することができる。これに加えて、１つ又は複数のサーバー１０２は、メモリ１０４を内部に含むことができる。

【0022】

メモリ１０４は、情報を電子的に保存する一時的ではないストレージ媒体を含み得る電子ストレージを有することができる。電子ストレージの電子ストレージ媒体は、１つ又は複数のサーバー１０２と共に一体的に（例えば、実質的に非着脱自在に）提供され得るシステムストレージ及び／又は、例えば、ポート（例えば、ＵＳＢ（登録商標）ポート、ファイアワイヤ（登録商標）ポート、など）又はドライブ（例えば、ディスクドライブ、など）を介して１つ又は複数のサーバー１０２に着脱自在に接続可能であり得る着脱自在のストレージの一方又は両方を含むことができる。電子ストレージは、光学的に読み取り可能なストレージ媒体（例えば、光学ディスク、など）、磁気的に読み取り可能なストレージ媒体（例えば、磁気テープ、磁気ハードドライブ、フロッピードライブ、など）、電荷に基づいたストレージ媒体（例えば、ＥＥＰＲＯＭ、ＲＡＭ、など）、半導体ストレージ媒体（例えば、フラッシュドライブ、など）、及び／又はその他の電子的に読み取り可能なストレージ媒体の１つ又は複数を含むことができる。電子ストレージは、１つ又は複数の仮想ストレージリソース（例えば、クラウドストレージ、仮想プライベートネットワーク、及び／又はその他の仮想ストレージリソース）を含むことができる。電子ストレージは、データベース又はパブリック又はプライベート分散型台帳（例えば、ブロックチェーン）を含むことができる。電子ストレージは、機械可読命令１２２、ソフトウェアアルゴリズム、制御ロジック、１つ又は複数のプロセッサによって生成されたデータ、１つ又は複数のサーバーから受け取られたデータ、１つ又は複数の演算プラットフォームから受け取られたデータ、及び／又は本明細書において記述されているように１つ又は複数のサーバーが機能することを可能にし得るその他のデータを保存することができる。また、電子ストレージは、ネットワーク１０６を介してアクセス可能であるサードパーティデータベースを含むこともできる。

【0023】

１つ又は複数のプロセッサ１４４は、１つ又は複数のサーバー１０２内においてデータ処理能力を提供するように構成することができる。従って、１つ又は複数のプロセッサ１４４は、デジタルプロセッサ、アナログプロセッサ、情報を処理するように設計されたデジタル回路、情報を処理するように設計されたアナログ回路、状態機械、及び／又はＦＰＧＡ又はＡＳＩＣなどの情報を電子的に処理するためのその他のメカニズムの１つ又は複数を含むことができる。１つ又は複数のプロセッサ１４４は、単一エンティティであることが可能であり、或いは、複数の処理ユニットを含むこともできる。これらの処理ユニットは、物理的に同一の装置内において配置することが可能であり、或いは、１つ又は複数のプロセッサ１４４は、単独で又は協働状態において動作する複数の装置の処理機能又はソフトウェア機能を表すこともできる。

【0024】

１つ又は複数のプロセッサ１４４は、ソフトウェア、ハードウェア、ファームウェア、ソフトウェア、ハードウェア、及び／又はファームウェアのなんらかの組合せ、及び／又は１つ又は複数のプロセッサ１４４上において処理能力を構成するためのその他のメカニズムを介して機械可読命令１２２又は機械学習モジュールを実行するように構成することができる。本明細書において使用されている「機械可読命令」という用語は、機械可読命令コンポーネント１２２に帰されている機能を実行する任意のコンポーネント又はコンポーネントの組を意味することができる。これは、プロセッサ可読命令の実行の際の１つ又は複数の物理的プロセッサ１４４、プロセッサ可読命令、回路、ハードウェア、ストレージ媒体、又は任意のその他のコンポーネントを含むことができる。

【0025】

１つ又は複数のサーバー１０２は、１つ又は複数の機能モジュールを有する機械可読命令１２２を有するように構成することができる。機械可読命令１２２は、メモリ１０４に対するアクセスを有する１つ又は複数のプロセッサ１４４を有する１つ又は複数のサーバー１０２上において実装することができる。機械可読命令１２２は、単一のネットワーク接続されたノードであることも可能であり、或いは、複数のネットワーク接続されたノードの分散型アーキテクチャを含みうる機械クラスタであることもできる。機械可読命令１２２は、更に詳細に後述するように、様々な機能を実装する制御ロジックを含むことができる。機械可読命令１２２は、システム１００と関連する特定の機能を含むことができる。これに加えて、機械可読命令１２２は、データベース、分散型台帳、又はブロックチェーンを処理し得る、読み取り得る、且つこれらにデータを書き込み得るスマートコントラクト又はマルチシグネチャコントラクトを含むことができる。

【0026】

図２は、圧縮に関係する減速命令管理システム２００の概略図を示している。一実施形態において、システム２００は、指令管理システム２０２、圧縮トラッキングシステム２０４、及び／又はアラート管理システム２０６を含むことができる。一実施形態において、指令管理システム２０２は、鉄道システム内の減速命令などの鉄道システム内の指令を生成、発布、及び／又は変更するように構成することができる。別の実施形態において、圧縮トラッキングシステム２０４は、軌道下における圧縮をトラッキングするために鉄道軌道インフラストラクチャに跨って印加される力を監視するように構成することができる。別の実施形態において、アラート管理システム２０６は、指令及び／又はトラッキングされている圧縮に関係するアラートなどの鉄道インフラストラクチャに跨るアラートを生成及び供給するように構成することができる。例示用の一実施形態において、指令管理システム２０２は、指令生成モジュール１２４と、指令変更モジュール１２６と、を含むことができる。別の実施形態において、圧縮トラッキングシステム２０４は、データキャプチャモジュール１２８と、トレーシングモジュール１３０と、指令関連付けモジュール１３２と、クラスタリングモジュール１３４と、力判定モジュール１３６と、イベント監視モジュール１３８と、を含むことができる。別の実施形態において、アラート管理システム２０６は、アラート生成モジュール１４０と、アラート供給モジュール１４２と、を含むことができる。

【0027】

一実施形態において、指令生成モジュール１２４は、鉄道インフラストラクチャに関係する特定の命令について鉄道要員に指示するために指令を生成することができる。例えば、指令生成モジュール１２４は、特定のエリアが保守を経験したということを通知する入力を鉄道要員から受け取ることができる。一実施形態において、指令生成モジュール１２４は、このような入力に基づいて保守を最近受けた軌道の特定のセクション用の減速命令を生成することができる。別の例において、指令生成モジュール１２４は、保守が実行されたという通知を鉄道インフラストラクチャから受け取ることができる。別の例において、指令生成モジュール１２４は、鉄道インフラストラクチャに関係する任意のその他のデータを受け取ることが可能であり、且つ、指令が生成されるべきかどうかを判定するために、このようなデータを利用することができる。例えば、指令生成モジュール１２４は、特定のタイプの作業が軌道のセクションに実行されたという通知を受け取ることが可能であり、且つ、このような作業が減速命令を必要とし得ると判定することができる。別の実施形態において、指令生成モジュール１２４は、鉄道インフラストラクチャに関係する指令の生成を促進するために任意の方式で構成することができる。

【0028】

一実施形態において、指令変更モジュール１２６は、指令生成モジュール１２４によって生成された指令などの指令を変更することができる。例えば、指令変更モジュール１２６は、（圧縮トラッキングシステム２０４及び／又はアラート管理システム２０６などから）データ又は通知を受け取ることが可能であり、且つ、指令が変更されるべきかどうかを判定するためにこのような受け取られたデータ及び／又は通知を利用することができる。例えば、指令変更モジュール１２６は、圧縮トラッキングデータを受け取ることが可能であり、且つ、減速命令が軌道の特定のセクションから解除されるようにこのようなデータが圧縮閾値を充足しているかどうかを判定することができる。別の実施形態において、指令変更モジュール１２６は、減速命令によって伝達されている最大許容速度を増大及び／又は減少させるように、減速命令が変更されるべきであると判定することができる。別の実施形態において、指令変更モジュール１２６は、停止命令又は任意のその他の指令を含む鉄道インフラストラクチャに関係する任意のその他の指令を変更することができる。

【0029】

例えば、指令変更モジュール１２６は、圧縮トラッキングシステム２０４及び／又はアラート管理システム２０６の一方又は両方からデータ及び／又は通知を受け取ることが可能であり、且つ、適切な変更を判定するために且つ／又はこのような変更を既存の指令に対して生成／実行するために、このようなデータ／情報を利用することができる。変更は、許容速度、減速命令の長さ、トン数要件の変更、及び／又は１つ又は複数の指令に対する任意のその他の変更を含むことができる。一例において、指令変更モジュール１２６は、指令変更を判定する際に、環境閾値、力閾値、イベント閾値、又は任意のその他の既定の閾値を考慮するために１つ又は複数の専門的なアルゴリズムを利用することができる。例えば、以下の表は、指令変更モジュール１２６が環境及び／又は力閾値などの１つ又は複数の閾値に少なくとも部分的に基づいて指令を判定及び／又は変更し得る方式を示し得る。

【0030】

【表1】

【0031】

別の実施形態において、上述の表は、一時的速度制限用の最小要件（例えば、指令）を収容することが可能であり、且つ、主には、バラストセクションを乱し得る作業活動に合焦することができる。別の例において、条件が許容する場合には、相対的に制限された速度及び／又は持続時間を対象とすることができる。別の実施形態において、太陽光がレール温度の評価における要因ではない時刻においては、特定のルール及び／又は例外を指令変更モジュール１２６によって利用することができる。例えば、圧縮速度制限（例えば、減速命令及び／又は指令）が有効であり、且つ、レール温度が温度閾値超において留まっている場合には、指令変更モジュール１２６は、上述の表の要件が遵守されるべきであると判定することができる。別の例において、温度が閾値温度未満に降下した場合には、まず上述の表に従って３０ｍｐｈに予め上げられたエリアに軌道スタビライザが対処することなしに実行される作業用の任意の圧縮減速命令は、２２００時～０９００時などの特定の時刻の間においては持ち上げられ（raised）又は除去されてもよい。別の例において、上述の表内において規定され得る必要とされるトン数又は列車の数が、レール温度が温度閾値未満に降下した時間の期間において影響を受けた軌道のセグメント上を通過した場合には、速度制限は、変更又は除去された状態において留まることができる。別の例において、特定の時点（例えば、０９００時）において、或いは、レール温度が温度閾値以上に上昇し且つ上述の表内において圧縮のために元々必要とされていたオリジナル力閾値又はイベント閾値に到達していない場合には、指令変更モジュール１２６は、速度制限を再確立することができる。別の例において、指令変更モジュール１２６は、最大力計測が力閾値を充足する時点まで且つ／又は特定のイベント基準を充足するイベントの数が１つ又は複数のイベント閾値を充足する時点まで或いは適格従業員が影響を受けた軌道のセグメントの検査を完了した時点まで、制限が有効な状態において留まり得ると決定することができる。

【0032】

例示用の一実施形態において、データキャプチャモジュール１２８は、鉄道軌道、鉄道車両、及び／又は鉄道インフラストラクチャに関係し得る無数のソースからデータを受け取り且つ／又はキャプチャするように構成することができる。例えば、データキャプチャモジュール１２８は、指令データ、軌道データ、セグメント識別データ、車両検出データ、速度データ、力データ、重量データ、レールデータ、レール温度、又は鉄道インフラストラクチャに関係する任意のその他のデータを受け取るように構成することができる。例えば、データキャプチャモジュール１２８は、このようなデータを保存し得る（データベース１０４などの）１つ又は複数のデータベースとの間の動作自在の通信状態にあり得る。別の実施形態において、データキャプチャモジュール１２８は、例えば、鉄道軌道に関係するデータをキャプチャするように構成することができる。例えば、データキャプチャモジュール１２８は、センサ、カメラ、温度計、レーダー、ＬＩＤＡＲ、又は鉄道インフラストラクチャに関係するデータをキャプチャ及び／又は収集するのに適した任意のその他のコンポーネント又はメカニズムを利用することができる。別の実施形態において、データキャプチャモジュール１２８は、要員、システム、又は鉄道インフラストラクチャデータに関係する任意のその他のエンティティから入力を受け取るように構成することができる。別の実施形態において、データキャプチャモジュール１２８は、１つ又は複数のレール車両によって担持される負荷及び／又は貨物に関係する情報を受け取るように構成することができる。別の実施形態において、データキャプチャモジュール１２８は、軌道上の車両の位置データポイントをキャプチャするように構成することができる。

【0033】

例えば、データキャプチャモジュール１２８は、鉄道軌道の１つ又は複数のセクションに印加される重量及び／又は力を計測するように動作し得るセンサと結合することができる。別の例において、データキャプチャモジュール１２８は、鉄道軌道上の列車を識別するために動作可能であるセンサと結合することができる。別の例において、データキャプチャモジュール１２８は、圧縮に関係する減速命令管理システム２００又は列車及び／又は列車の負荷に関係するデータを含み得るその他のシステムの別の部分からのデータを受け取るように構成することができる。別の実施形態において、データキャプチャモジュール１２８は、軌道の保守及び／又はバラストの乱れに関係するデータを受け取り且つ／又はキャプチャするためにセンサ又は利用可能な接続を利用するように構成することができる。一例において、データキャプチャモジュール１２８は、鉄道軌道内において有効であり得る電流などの電流に関係するデータを受け取るように構成することができる。例えば、データキャプチャモジュール１２８は、抵抗値、電圧、又は軌道内の電流に関する任意のその他の通知を計測するためにセンサ又はその他のコンポーネントを利用するように構成することができる。別の例において、データキャプチャモジュール１２８は、レール温度に関係するデータをキャプチャするように構成することができる。別の例において、データキャプチャモジュール１２８は、天候、温度、湿度、風速、及び／又は鉄道に関係する任意のその他の環境データを含む環境状態に関係するデータをキャプチャするように構成することができる。

【0034】

別の例示用の実施形態において、トレーシングモジュール１３０は、データキャプチャモジュール１２８からデータを受け取るように且つ鉄道軌道の１つ又は複数のセグメントに沿ったレール車両の経路をトレーシングするためにこのようなデータを利用するように、構成することができる。例えば、トレーシングモジュール１３０は、トレーシングモジュールが車両が検出された軌道のセクションをトラッキングし得るように、データキャプチャモジュール１２８と通信するように構成することができる。一実施形態において、データキャプチャモジュール１２８は、軌道上において移動する車両によって生成される軌道の電流の逸脱を検出するように構成することが可能であり、且つ、トレーシングモジュール１３０は、このようなデータを使用して経路車両をトレーシングするように構成することができる。別の実施形態において、トレーシングモジュール１３０は、トレーシングモジュール１３０が車両アイデンティティを特定の場所において移動している車両と関連付け得るように、軌道上において移動する車両の識別に関係する情報を受け取るように１つ又は複数のシステムと通信するように構成することができる。別の実施形態において、トレーシングモジュール１３０は、個々の軌道セグメントを識別することが可能であり、且つ、車両が通過した軌道セグメントを判定するように、データキャプチャモジュール１２８から受け取られたデータをこのような軌道セグメントと関連付けることができる。

【0035】

別の実施形態において、トレーシングモジュール１３０は、少なくとも第３軌道セグメント上において車両の経路を判定するために、少なくとも２つの軌道セグメントに関係する位置データポイントを利用するように構成することができる。例えば、データキャプチャモジュール１２８は、軌道上の車両の運動に関係する位置データポイントをキャプチャすることが可能であり、且つ、トレーシングモジュール１３０は、車両が２つのデータポイントの間であり得るものなどの第３セグメント上を移動したかどうか、並びに、第３軌道セグメントに関係する位置データポイントがデータキャプチャモジュール１２８によってキャプチャされなかったかどうか、を判定するために、このような２つのデータポイントの間の経路をトレーシングするように構成することができる。別の例において、トレーシングモジュール１３０は、このような位置データポイントを使用して軌道に沿った車両の経路をマッピングするように構成することができる。

【0036】

例示用の一実施形態において、指令関連付けモジュール１３２は、指令管理システム２０２によって生成及び／又は変更された指令に関係するデータなどの指令データを受け取るように構成することが可能であり、且つ、更には、このような指令データを鉄道軌道の１つ又は複数のセグメントと関連付けすることができる。例えば、指令は、１つ又は複数の軌道セグメントを含み得る軌道の特定の長さについて特定の速度を超過しないように鉄道車両に指示し得る減速命令であり得る。別の例において、指令関連付けモジュール１３２は、この指令データを受け取ることが可能であり、且つ、指令関連付けモジュール１３２が指令に関係したそれぞれの軌道セグメントを識別し得るように、これを指令によってカバーされているレールの全体長に含まれ得る軌道セグメントと関連付けることができる。別の実施形態において、指令関連付けモジュール１３２は、鉄道軌道及び／又は軌道セグメントを追加する指令管理システム２０２によって生成及び／又は変更された（generated and/or modified by the directive management system 202 add a railroad track and/or track segments）、指令の間の任意のその他の適切な関係を生成及び／又は認識するように構成することができる。

【0037】

別の例示用の実施形態において、クラスタリングモジュール１３４は、個々の軌道セグメントに関係するデータクラスタを生成するように構成することができる。例えば、クラスタリングモジュール１３４は、データキャプチャモジュール１２８及び／又はトレーシングモジュール１３０からデータを受け取るように且つこのような受け取られたデータを個々の軌道セグメントとの関係においてクラスタリングするように、構成することができる。例えば、クラスタリングモジュール１３４は、イベントが特定の軌道セグメント上において発生したと判定することが可能であり、且つ、このようなイベント及び／又はこのようなイベントに関係するデータが集計されるべきであるかどうかを判定することができる。別の例において、クラスタリングモジュール１３４は、車両が特定の軌道セグメント上を移動したと判定する且つ／又は受信することが可能であり、且つ、このようなイベントをその他の類似のイベントのクラスタと共に含むことができる。別の例において、クラスタリングモジュール１３４は、車両アイデンティティ及び／又は負荷と関係するデータを判定及び／又は受信することが可能であり、且つ、このようなデータを軌道セグメントに関係するデータクラスタ内において集計することができる。別の例において、クラスタリングモジュール１３４は、保守、作業指示、レール状態、又は特定の軌道セグメントと関連付けられるのに適した任意のその他のイベントなどの特定の軌道セグメントと関連する任意のその他のタイプのイベントをカウント及び／又は判定することができる。

【0038】

別の例示用の実施形態において、力判定モジュール１３６は、１つ又は複数の力が特定の軌道セグメント又は鉄道軌道に印加されていることを判定するように構成することができる。一実施形態において、力判定モジュール１３６は、データキャプチャモジュール１２８、トレーシングモジュール１３０、指令関連付けモジュール１３２、及び／又はクラスタリングモジュール１３４からデータを受け取ることが可能であり、且つ、軌道及び／又は軌道セグメントに印加される１つ又は複数の力を判定するために、このようなデータを利用することができる。一例において、力判定モジュール１３６は、列車の負荷に関係するデータを受け取ることが可能であり、且つ、列車が軌道の特定のセグメントに印加する力を判定するために、このようなデータを利用することができる。別の例において、力判定モジュール１３６は、システム２００の別の部分から負荷重量又は力判定を受け取ることができる。さらに別の例において、力判定モジュールは、特定の軌道セグメントに印加される合計力を算出するために、クラスタリングモジュール１３４によって生成されたデータクラスタを利用することができる。例えば、クラスタリングモジュール１３４は、このようなデータポイントに関係するこのような軌道セグメントに印加される力を判定するために、力判定モジュール１３６によって使用可能であるそれぞれのデータポイントを有するデータクラスタを生成することができる。別の例において、力判定モジュール１３６は、特定の軌道セグメントに印加される合計力を判定するために、クラスタリングモジュール１３４によって生成されたデータクラスタのそれぞれのデータポイントと関連する力を算出することができる。別の実施形態において、力判定モジュール１３６は、任意のその他の適切な方式によって軌道又は軌道セグメントに印加される１つ又は複数の力を算出、検知、又はさもなければ判定するように構成することができる。

【0039】

別の実施形態において、力判定モジュール１３６は、力を１つ又は複数の力閾値と比較するように構成することができる。例えば、力判定モジュール１３６は、変更及び／又は終了されるべき特定の指令について、指令と関連する軌道の少なくとも１つのセグメント上において算出された合計力が特定の力閾値を超過しなければならないと判定することができる。別の実施形態において、力判定モジュールは、印加される力が１つ又は複数の力閾値を充足しているどうかを判定するために、個々のイベント及び／又は力を１つ又は複数の力閾値と比較することができる。別の実施形態において、力判定モジュール１３６は、印加される力、合計力、又は圧縮トラッキングシステム２０４による圧縮トラッキングを促進するのに適した任意のその他の力計測及び／又は比較を判定する際に任意の数の力閾値を実装及び／又は利用することができる。

【0040】

別の例示用の実施形態において、イベント監視モジュール１３８は、イベントを特定の基準と比較するように且つこのようなイベントが軌道又は軌道セグメントのイベント合計において含まれるべきであるかどうかを判定するように、構成することができる。一実施形態において、イベント監視モジュール１３８は、イベント基準の判定及び／又は特定のイベント基準及び／又は閾値との間のこのようなデータの比較を促進するために、データキャプチャモジュール１２８、トレーシングモジュール１３０、指令関連付けモジュール１３２、クラスタリングモジュール１３４、及び／又は力判定モジュール１３６からデータを受け取るように構成することができる。別の実施形態において、イベント監視モジュール１３８は、１つ又は複数のイベント閾値を含むことが可能であり、且つ、このようなイベントがイベントカウントに含まれるべきかどうかを判定するために、データをこのような閾値と比較することができる。例えば、イベント監視モジュールは、軌道に対して車両によって印加された力を受信及び／又は判定することが可能であり、且つ、このような力をイベント閾値と比較することが可能であり、且つ、力がイベント閾値を充足している場合に、イベント監視モジュール１３８は、このようなイベントのイベントカウントを増分することができる。別の実施形態において、イベント監視モジュール１３８は、軌道又は軌道セグメント上において移動する車両の速度に関係するデータを受け取ることが可能であり、且つ、このような速度を速度閾値と比較することが可能であり、且つ、このような速度閾値が充足されている場合に、イベント監視モジュール１３８は、このようなイベントに関係するイベントカウントを増分することができる。別の実施形態において、イベント監視モジュール１３８は、車両タイプ、レールタイプ、レール温度、周辺温度、時刻、力、速度、及び／又は特定のカテゴリのイベントを監視及び／又はカウントするためにこのような基準と関係付けられる任意のその他の基準及び／又は閾値を含む任意の数のイベント基準を実装することができる。

【0041】

別の例示用の実施形態において、アラート生成モジュール１４０は、指令管理システム２０２及び／又は圧縮トラッキングシステム２０４からデータを受け取るように且つアラートが生成されるべきかどうかを判定するためにこのようなデータを利用するように、構成することができる。例えば、アラート生成モジュール１４０は、指令管理システム２０２から指令データを受け取ることが可能であり、且つ、このような指令がアラートの生成を必要とするかどうかを判定することができる。別の実施形態において、アラート生成モジュール１４０は、指令管理システム２０２から指令変更データを受け取ることが可能であり、且つ、このような指令変更がアラート生成を必要とするかどうかを判定することができる。別の実施形態において、アラート生成モジュール１４０は、力閾値が充足されたかどうか及び／又はイベント閾値が充足されたかどうかを通知するデータなどの圧縮トラッキングシステム２０４からのデータを受け取ることが可能であり、且つ、更には、このような閾値の一方又は両方が充足された場合にアラートが生成されるべきかどうかを判定することができる。別の実施形態において、アラート生成モジュール１４０は、アラートが生成されるべきかどうかを判定するために１つ又は複数のシステムからデータ及び／又は通知を受け取ることができる。例えば、アラート生成モジュールは、要員、ＰＴＣシステム、ＴＭＤＳシステム、又はアラート管理システム２０６及び／又は指令管理システム２０２及び／又は圧縮トラッキングシステム２０４との動作自在の通信状態にある任意のその他のシステムから入力を受け取ることができる。

【0042】

別の例示用の実施形態において、アラート供給モジュール１４２は、アラート生成モジュール１４０によって生成されたアラートを受け取るように且つ鉄道インフラストラクチャの全体を通じてこのようなアラートを供給するように、構成することができる。例えば、アラート供給モジュール１４２は、アラートをＰＴＣシステム、ＴＭＤＳシステム、及び／又はアラート管理システム２０６及び／又は指令管理システム２０２及び／又は圧縮トラッキングシステム２０４との動作自在の通信状態にある任意のその他のシステムに供給することができる。別の実施形態において、アラート供給モジュール１４２は、利用可能な接続タイプに基づいて供給の方法を優先順位付けするように構成することができる。別の実施形態において、アラート供給モジュール１４２は、アラートを指令管理システム２０２に供給するように構成することが可能であり、且つ、一実施形態において、指令管理システム２０２は、指令を変更するべきかどうかを判定するためにこのようなアラートを利用することができる。別の実施形態において、アラート供給モジュール１４２は、指令管理システム２０２などにより、指令が生成及び／又は変更されたと通知するように、アラートを圧縮トラッキングシステム２０４に供給することができる。別の実施形態において、アラート供給モジュール１４２は、鉄道システムの全体を通じて鉄道に関係する任意のその他のアラートを供給及び／又は送信するように構成することができる。

【0043】

図３Ａ、図３Ｂ及び図３Ｃは、本開示の例示用の実施形態による指令制御システム３００の特徴を実施する制御ロジックを例示するフローチャート図３００を示している。指令制御の制御ロジック３００は、サーバー（例えば、サーバー１０２）、機械学習モジュール、又はその他の適切なシステム上のアルゴリズムとして実装することができる。これに加えて、指令制御の制御ロジック３００は、指令管理システム２０２、圧縮トラッキングシステム２０４、及びアラート管理システム２０６を含む圧縮に関係する減速命令管理システム２００の１つ又は複数の特徴を実装又は内蔵することができる。指令制御の制御ロジック３００は、ソフトウェア、ハードウェア、アプリケーションプログラミングインターフェイス（ＡＰＩ）、ネットワーク接続、ネットワーク転送プロトコル、ＨＴＭＬ、ＤＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｄｏｊｏ、Ｒｕｂｙ、Ｒａｉｌｓ、その他の適切なアプリケーション、又はこれらの適切な組合せによって実現することができる。

【0044】

指令制御の制御ロジック３００は、データを同時に処理することによって複数のプロセス及びスレッドを生成するためにコンピュータプラットフォームの能力を活用することができる。指令制御の制御ロジック３００の速度及び効率性は、要員の安全性を促進するために複数のプロセスをインスタンス生成することにより、格段に改善されている。但し、プログラミングの当業者は、単一処理スレッドの使用も利用され得ると共に本開示の範囲に含まれることを理解するであろう。

【0045】

本実施形態の指令制御の制御ロジック３００のプロセスフローは、ステップ３０２において開始しており、この場合に、制御ロジック３００は、自身が適格作業の通知を受け取ったかどうかを判定している。例えば、制御ロジック３００は、軌道の特定の部分及び／又はセグメントに対して作業が実施されたという通知を受け取ることが可能であり、且つ、このような作業がバラストを乱し得るタイプである場合には、制御ロジック３００は、作業が適格作業であると判定することができる。別の実施形態において、制御ロジック３００は、このような適格な作業が実行されたという別のシステム及び／又は要員からの入力又はその他の通知を受け取ることができる。制御ロジック３００がこのような通知を受け取らない場合には、制御ロジック３００は、このような通知の受取りを待機することになる。制御ロジック３００がこのような通知を受け取った場合には、制御ロジック３００は、ステップ３０４に進んでいる。

【0046】

ステップ３０４において、制御ロジック３００は、指令生成をインスタンス生成することができる。例えば、制御ロジック３００は、適格作業に関係する指令が生成され得るように、指令生成プロセスをインスタンス生成することができる。例えば、制御ロジック３００は、適格作業が実行されたことから指令が生成されるべきであると要員に通知することができる。別の実施形態において、制御ロジック３００は、軌道の特定の部分と関係する指令を自身で生成することが可能であり、且つ、このような指令を送信することができる。別の実施形態において、制御ロジック３００は、指令を要求することができる。別の実施形態において、制御ロジック３００は、指令が生成され得る任意の適切なプロセスをインスタンス生成することができる。次いで、制御ロジック３００は、ステップ３０６に進んでいる。

【0047】

ステップ３０６において、制御ロジック３００は、指令データを受け取ることができる。例えば、制御ロジック３００は、指令のタイプ、指令の命令、指令が関連している軌道の部分、指令データが関連している軌道セグメント、又は指令に関係する任意のその他のデータを受け取ることができる。例えば、制御ロジック３００は、指令が、鉄道軌道の特定の部分上において速度を低減するように車両に命令し得る減速命令であることを受け取ることができる。別の実施形態において、制御ロジック３００は、指令が変更及び／又は終了され得る方式に関係するデータを受け取ることができる。例えば、制御ロジック３００は、指令を変更するために充足される必要がある力閾値に関係するデータを受け取ることができる。別の例において、制御ロジック３００は、指令が変更及び／又は解除されるために充足されなければならないイベントカウント閾値及び／又はイベント閾値を受け取ることができる。次いで、制御ロジック３００は、ステップ３０８及びステップ３８４に進んでいる。

【0048】

ステップ３０８において、制御ロジック３００は、レコードを生成することができる。例えば、レコードは、指令及び／又は指令に関係するデータを含むことができる。一実施形態において、レコードは、指令の時刻及び日付、指令の命令、及び／又は指令に関係する任意のその他のデータを含むことができる。別の実施形態において、ステップ３０８において生成されるレコードは、制御ロジック３００によって生成及び／又は変更された更なるデータを保存するように構成することができる。この結果、ステップ３０８において生成されたレコードは、指令及び関連するデータのみならず、指令及び／又はその変更に関係するイベント及び／又は車両及び／又は任意のその他のデータを含むことができる。次いで、制御ロジック３００は、ステップ３１０に進んでいる。

【0049】

ステップ３１０において、制御ロジック３００は、アラートを生成することができる。例えば、制御ロジック３００は、指令データが受け取られたことから、アラートが生成されるべきであると判定することができる。別の実施形態において、制御ロジック３００は、鉄道システムの間において且つ／又は鉄道要員にアラートを送信することができる。例えば、制御ロジック３００は、指令が鉄道軌道の特定の部分との関係においてインスタンス生成されたことを１つ又は複数のシステムのみならず、関連する要員に通知することができる。次いで、制御ロジック３００は、ステップ３１２に進んでいる。

【0050】

ステップ３１２において、制御ロジック３００は、軌道データを受け取ることができる。例えば、制御ロジック３００は、軌道場所データ、軌道セグメントデータ、軌道セグメント識別データ、軌道タイプ、軌道状態、又は軌道に関係する任意のその他のデータを受け取ることができる。次いで、制御ロジック３００は、ステップ３１４に進んでいる。

【0051】

ステップ３１４において、制御ロジック３００は、セグメントを判定することができる。例えば、制御ロジック３００は、ステップ３１２において軌道の特定の長さに関係するデータを受け取ることが可能であり、且つ、軌道のこのような長さがステップ３１４においてセグメント化されるべき方法を判定することができる。例えば、制御ロジック３００は、軌道の長さがセグメント化されるべき方法を軌道データ内において通知として受け取ることができる。別の実施形態において、制御ロジック３００は、軌道がセグメント化されるべき方法を軌道データに基づいて決定することができる。例えば、制御ロジック３００は、本線及び側線の両方が存在していると判定することが可能であり、且つ、更には、本線の一部分が側線とは異なるセグメントであるはずであると判定することができる。別の実施形態において、制御ロジック３００は、軌道の一部分がセグメントの長さによって複数のセグメントに分割され得るように、セグメントが特定の長さを有するはずであると判定することができる。別の実施形態において、制御ロジック３００は、特定の機器の存在、枕木の組成、レールタイプ、年齢、或いは、制御ロジック３００が１つ又は複数のセグメントに鉄道軌道の一部分をセグメント化することを可能にするのに適した任意のその他の基準を含む任意の適切なメカニズムによってセグメントを判定することができる。別の実施形態において、制御ロジック３００は、指令制御を可能にするのに適した任意の方式によって軌道セグメントを判定することができる。次いで、制御ロジック３００は、ハブ（have）３１６に進んでいる。

【0052】

ステップ３１６において、制御ロジック３００は、セグメントアイデンティティを割り当てることができる。例えば、制御ロジックは、識別子をステップ３１４において判定されたセグメントに割り当てることができる。別の実施形態において、制御ロジック３００は、それぞれのセグメントが識別される方式について軌道データから通知を受け取ることができる。別の実施形態において、制御ロジック３００は、識別番号をそれぞれのセグメントに割り当てることができる。別の実施形態において、制御ロジック３００は、セグメントアイデンティティ及び制御ロジック３００が１つ又は複数の軌道セグメントの間を弁別することを許容するのに適した任意の方式を識別及び／又は割当することができる。次いで、制御ロジック３００は、ステップ３１８に進んでいる。

【0053】

ステップ３１８において、制御ロジック３００は、指令を１つ又は複数の軌道セグメントと関連付けることができる。例えば、制御ロジックは、指令が関連付けられる軌道の長さを判定するために、ステップ３０６において受け取られた指令データを利用することができる。次いで、制御ロジック３００は、指令が関連付けられるべきセグメントを判定するために、ステップ３１２において受け取られた軌道データ、ステップ３１４において判定されたセグメント、及びステップ３１６において判定されたセグメントアイデンティティを利用することができる。例えば、制御ロジック３００は、指令によってカバーされているセグメントを判定することができる。次いで、制御ロジック３００は、ステップ３２０に進んでいる。

【0054】

ステップ３２０において、制御ロジック３００は、第１及び第２イベント基準を判定することができる。例えば、制御ロジック３００は、カウントするべきイベントの異なるタイプを判定することができる。例えば、制御ロジック３００は、カウントされるべきイベントについてその他のシステム及び／又は要員から通知を受け取ることができる。別の例において、制御ロジック３００は、第１及び第２イベントタイプに関係する基準を含むことができる。別の実施形態において、制御ロジック３００は、イベントの第１タイプがカウントされるべきであり且つイベントの第２タイプもカウントされるべきであると判定することができる。例えば、制御ロジック３００は、第１イベント基準が特定の速度において移動する車両を含むと判定することができる。別の例において、制御ロジック３００は、第２イベント基準が特定の負荷と共に移動する車両を含むことを判定することができる。別の実施形態において、制御ロジック３００は、第１又は第２イベント基準が特定の速度において移動する且つ特定の負荷を有する車両を含むと判定することができる。別の実施形態において、制御ロジック３００は、指令及び／又はその変更に関連する任意のその他の基準を利用することができる。別の実施形態において、制御ロジック３００は、制御ロジック３００がバラストの圧縮をトラッキングする且つ／又は指令が変更及び／又は終了されるべきかどうかを判定することを可能にするのに適した任意のイベント基準を利用することができる。次いで、制御ロジック３００は、ステップ３２２に進んでいる。

【0055】

ステップ３２２において、制御ロジック３００は、資産を検出することができる。例えば、制御ロジック３００は、軌道上の車両を検出することができる。別の例において、制御ロジック３００は、１つ又は複数のセンサ、システム、或いは、車両及び／又はその他の資産を検出するのに適した任意のその他のコンポーネントとの動作自在の通信状態にあり得る。次いで、制御ロジック３００は、ステップ３２４に進んでいる。

【0056】

ステップ３２４において、制御ロジック３００は、資産データを受け取ることができる。例えば、制御ロジック３００は、資産の識別、資産が搬送する負荷、資産が移動する速度、又は資産の関係する任意のその他のデータに関係するデータを受け取ることができる。別の実施形態において、制御ロジック３００は、資産に関係するデータをキャプチャする且つ／又は受け取るために、任意の数のセンサ又はその他のデータ収集器との動作自在の通信状態にあり得る。次いで、制御ロジック３００は、ステップ３２６に進んでいる。

【0057】

ステップ３２６において、制御ロジック３００は、位置データポイントを受け取ることができる。例えば、制御ロジック３００は、資産の検出の位置に関係するデータポイントを受け取ることができる。例えば、制御ロジック３００は、軌道内の電流を読み取るように構成された１つ又は複数のセンサとの通信状態にあることが可能であり、且つ、制御ロジック３００は、軌道上の資産の位置を検出するためにこのようなセンサを利用することができる。別の実施形態において、制御ロジックは、全地球測位システム、レーダー、低エネルギーＢｌｕｅｔｏｏｔｈ、或いは、鉄道軌道上の資産の位置を判定するための通信及び／又はプロトコル及び／又はデータの任意のその他のタイプを利用することができる。別の実施形態において、制御ロジック３００は、ステップ３１４及び３１６において判定及び／又は識別された特定の軌道セグメントと関連し得る位置データポイントを受け取ることができる。例えば、制御ロジック３００は、特定の軌道セグメント上の資産の位置を通知する位置データポイントをステップ３２６において受け取ることができる。次いで、制御ロジック３００は、ステップ３２８に進んでいる。

【0058】

ステップ３２８において、制御ロジック３００は、経路をトレーシングすることができる。例えば、制御ロジックは、鉄道軌道に沿った経路をトレーシングするためにステップ３２６において受け取られた位置データポイントを利用することができる。例えば、制御ロジック３００は、位置データポイントを受け取ることが可能であり、且つ／又は、資産が特定の軌道セグメント上に存在している且つ／又は存在していたことを認識することが可能であり、且つ、更には、識別された軌道セグメントを使用して軌道に沿った経路をトレーシングすることができる。例えば、制御ロジック３００は、資産が２つの別個の軌道セグメント上において配置されている且つ／又は配置されていたことを通知する位置データポイントを受け取ることができる。次いで、制御ロジック３００は、このような２つの軌道セグメントの間の経路をトレーシングすることが可能であり、且つ、経路が第３軌道セグメントを横断しているかどうかを判定することができる。この結果、制御ロジック３００は、鉄道軌道の１つ又は複数の軌道セグメントに沿った資産の経路を判定することができる。この結果、別の実施形態において、制御ロジック３００は、資産が特定の軌道セグメントに沿って移動したことを直接的に通知する位置データを制御ロジック３００がステップ３２６において受け取らなかった場合にも、１つ又は複数の軌道セグメントに適用されたイベント及び力を判定することができる。次いで、制御ロジック３００は、ステップ３３０に進んでいる。

【0059】

ステップ３３０において、制御ロジック３００は、ステップ３２８においてトレーシングされた経路が指令と関連するセグメントを横断したかどうかを判定することができる。例えば、制御ロジックは、ステップ３２８においてトレーシングされた経路をステップ３１８において指令と関連付けられたセグメントと比較することが可能であり、且つ、経路によって横断されたセグメントの任意のものが指令と関連付けられている／関連付けられていたかどうかを判定することができる。制御ロジック３００は、ステップ３２８においてトレーシングされた経路が指令と関連する１つ又は複数のセグメントを横断していないと制御ロジック３００が判定した場合に、ステップ３２２に進んでいる。次いで、制御ロジック３００は、ステップ３２８においてトレーシングされた経路が指令と関連する１つ又は複数のセグメントを横断していると制御ロジック３００が判定した場合に、ステップ３３２に進んでいる。

【0060】

ステップ３３２において、制御ロジック３００は、セグメントデータクラスタ内において資産データを含むことができる。例えば、制御ロジック３００は、経路によって横断された指令と関連するセグメントを判定することができる。別の実施形態において、制御ロジック３００は、指令と関連付けられ得るそれぞれの軌道セグメントと関連するデータクラスタを生成することが可能であり、且つ、資産が特定のセグメントに沿って移動している場合にこのようなデータクラスタ内において資産データを含むことができる。次いで、制御ロジック３００は、ステップ３３４及び３７２に進んでいる。

【0061】

ステップ３３４において、制御ロジック３００は、資産データを第１イベント基準と比較することができる。例えば、制御ロジック３００は、ステップ３２４において受け取られた資産データを利用することが可能であり、且つ、このようなデータをステップ３２０において判定された第１イベント基準と比較することができる。一実施形態において、複数の基準を第１イベントと関連付けることができる。別の実施形態においては、単一の基準を第１イベントと関連付けることができる。次いで、制御ロジックは、ステップ３３６に進んでいる。

【0062】

ステップ３３６において、制御ロジック３００は、資産データが第１イベント基準を充足しているかどうかを判定することができる。例えば、制御ロジック３００は、資産が第１イベント基準によって必要とされ得る特定の速度を充足したかどうかを判定することができる。資産データが第１イベント基準を充足していない場合に、制御ロジック３００は、ステップ３２２に戻るように進んでいる。資産データが第１イベント基準を充足している場合に、制御ロジックは、ステップ３３８に進んでいる。

【0063】

ステップ３３８において、制御ロジック３００は、セグメント第１イベントカウントを増分することができる。例えば、制御ロジック３００は、指令と関連するそれぞれのセグメントごとに適格なイベントを追跡することができる。例えば、制御ロジック３００は、１つ又は複数のイベントカウントを任意の特定のセグメントと関連付けることが可能であり、且つ、特定のイベント基準を充足しているイベントの数をカウントすることができる。次いで、制御ロジック３００は、ステップ３４０に進んでいる。

【0064】

ステップ３４０において、制御ロジック３００は、複数のセグメントが特定の指令と関連付けられているかどうかを判定することができる。複数のセグメントが指令と関連付けられていると制御ロジック３００が判定した場合に、制御ロジック３００は、ステップ３４２に進んでいる。複数のセグメントが指令と関連付けられてはいないと制御ロジック３００が判定した場合に、制御ロジック３００は、ステップ３４６に進んでいる。

【0065】

ステップ３４２において、制御ロジック３００は、指令と関連するそれぞれのセグメントごとに第１イベントカウントを判定することができる。例えば、制御ロジック３００は、制御ロジック３００が指令と関連するそれぞれのセグメントごとに第１イベントカウントを比較し得るように、指令と関連するそれぞれのセグメントごとに第１イベントカウントを追跡することができる。制御ロジック３００（The control logic 300）は、ステップ３４４に進んでいる。

【0066】

ステップ３４４において、制御ロジック３００は、それぞれのセグメントの第１イベントカウントを比較することができる。例えば、制御ロジックは、それぞれのセグメントごとに発生した第１イベント基準を充足するイベントの数を判定することができる。この結果、制御ロジック３００は、指令が変更される前に、指令が時期尚早に解除及び／又は変更されないように、指令と関連するそれぞれのセグメントが特定の基準を充足することを保証することができる。次いで、制御ロジック３００は、ステップ３４６に進んでいる。

【0067】

ステップ３４６において、制御ロジック３００は、最小第１イベントカウントを判定することができる。例えば、制御ロジックは、どのセグメントのどのイベントカウントが最低であるのかを判定するために、ステップ３４４において実施された比較を利用することができる。次いで、制御ロジック３００は、ステップ３４８に進んでいる。

【0068】

ステップ３４８において、制御ロジックは、第１イベント閾値が充足されているかどうかを判定することができる。例えば、制御ロジック３００は、ステップ３４６において判定された最小第１イベントカウントを利用することが可能であり、且つ、第１イベント閾値が充足されているかどうかを判定するために、このような最小イベントカウントを第１イベント閾値と比較することができる。この結果、制御ロジック３００は、指令が時期尚早に解除及び／又は変更されないように、特定の指令と関連するすべてのセグメントが第１イベント閾値を充足又は超過していることを保証している。第１イベント閾値が充足されていると制御ロジック３００が判定した場合に、制御ロジック３００は、ステップ３５０に進んでいる。第１イベント閾値が充足されていないと制御ロジック３００が判定した場合に、制御ロジックは、ステップ３５６に進んでいる。

【0069】

ステップ３５０において、制御ロジック３００は、アラートを生成することができる。例えば、制御ロジックは、第１イベント閾値が特定の指令と関連するすべての軌道セグメントによって充足及び／又は超過されていることを通知するアラートを生成することができよう。次いで、制御ロジック３００は、ステップ３５２に進んでいる。

【0070】

ステップ３５２において、制御ロジック３００は、資産データを第２イベント基準と比較することができる。例えば、第２イベント基準は、第１イベント基準とは異なり得る。別の実施形態において、制御ロジック３００は、第１イベント閾値が充足された後に第２イベント基準を充足するイベントをカウントすることを開始することができる。次いで、制御ロジック３００は、ステップ３５４に進んでいる。

【0071】

ステップ３５４において、制御ロジック３００は、イベントが第２イベント基準を充足しているかどうかを判定することができる。例えば、制御ロジック３００は、資産データを検討することが可能であり、且つ、資産データが第２イベント基準を充足しているかどうかを判定するために、ステップ３５２において実施された比較を利用することができる。例えば、第２イベント基準は、第１イベント基準に類似し得る。例えば、第２イベント基準は、車両の速度に関係付けることができる。別の実施形態において、第２イベント基準は、車両の重量に関係付けることができよう。別の実施形態において、第２イベント基準は、圧縮及び鉄道インフラストラクチャのトラッキングに関連する任意のその他の基準であり得る。資産データが第２イベント基準を充足してはいないと制御ロジック３００が判定した場合に、制御ロジックは、ステップ３５６に進んでいる。資産データが第２イベント基準を充足していると制御ロジック３００が判定した場合に、制御ロジック３００は、ステップ３５８に進んでいる。

【0072】

ステップ３５６において、制御ロジック３００は、資産を検出することができる。例えば、制御ロジック３００は、ステップ３２２と同様に資産を検出することができる。例えば、制御ロジック３００は、制御ロジックが再度ステップ３２４において始まるプロセスを開始し得るように、資産の検出を待機することができる。

【0073】

ステップ３５８において、制御ロジック３００は、セグメント第２イベントカウントを増分することができる。例えば、セグメント第２イベントカウントは、自身がセグメント上において発生する第１イベントタイプとは異なりセグメント上において発生する第２イベントタイプに対応しているという点を除いて、セグメント第１イベントカウントに類似し得る。例えば、指令と関連するそれぞれのセグメントは、第２イベントカウントを含むことができる。別の実施形態において、指令と関連するそれぞれのセグメントは、第１イベントカウント及び第２イベントカウントを含むことができる。次いで、制御ロジック３００は、ステップ３６０に進んでいる。

【0074】

ステップ３６０において、制御ロジックは、複数のセグメントが指令と関連しているかどうかを判定することができる。複数のセグメントが指令と関連していると制御ロジック３００が判定した場合に、制御ロジック３００は、ステップ３６２に進んでいる。複数のセグメントが指令と関連してはいないと制御ロジック３００が判定した場合に、制御ロジックは、ステップ３６６に進んでいる。

【0075】

ステップ３６２において、制御ロジックは、指令と関連するそれぞれのセグメントごとに第２イベントカウントを判定することができる。例えば、制御ロジック３００は、指令と関連するそれぞれのセグメントに関係付けられた第２イベントカウントを識別することができる。次いで、制御ロジック３００は、ステップ３６４に進んでいる。

【0076】

ステップ３６４において、制御ロジック３００は、指令と関連するそれぞれのその他のセグメントの第２イベントカウントを指令と関連するそれぞれのその他のセグメントの第２イベントカウントと比較することができる。次いで、制御ロジックは、ステップ３６６に進んでいる。

【0077】

ステップ３６６において、制御ロジックは、最小第２イベントカウントを判定することができる。例えば、制御ロジック３００は、どのセグメントのどのイベントカウントが最低であるのかを判定するために、ステップ３６４において実施された比較を利用することができる。別の実施形態において、指令と関連する単一のセグメントのみが存在している場合には、制御ロジック３００は、このようなイベントカウントが最小イベントカウントであると判定することができる。次いで、制御ロジックは、ステップ３６８に進んでいる。

【0078】

ステップ３６８において、制御ロジックは、最小第２イベントカウントが第２イベント閾値を充足しているかどうかを判定することができる。例えば、第２イベント閾値は、最小第２イベントカウントがこのような数を充足又は超過している場合に第２イベント閾値が充足され得るように、特定の数の第２イベントタイプを含むことができる。第２イベント閾値が最小第２イベントカウントによって充足されてはいないと制御ロジック３００が判定した場合に、制御ロジック３００は、ステップ３６６に戻るように進んでいる。最小第２イベントカウントが第２イベント閾値を充足していると制御ロジック３００が判定した場合には、制御ロジック３００は、ステップ３７０に進んでいる。

【0079】

ステップ３７０において、制御ロジック３００は、アラートを生成することができる。例えば、制御ロジック３００は、第２イベント閾値が充足されていることを通知するアラートを生成することができる。次いで、制御ロジックは、ステップ３９０に進んでいる。

【0080】

ステップ３７２において、制御ロジック３００は、セグメント合計力を算出することができる。例えば、制御ロジック３００は、１つ又は複数のセグメントに印加された合計力を判定するために、ステップ３３２において生成及び／又は追加されたデータクラスタを利用することができる。別の例において、制御ロジック３００は、合計力がそれぞれのセグメントごとに算出されるように、印加された力のすべてのものを集計することが可能であり又はその合計を生成することができる。次いで、制御ロジック３００は、ステップ３７４に進んでいる。

【0081】

ステップ３７４において、制御ロジック３００は、複数のセグメントが指令と関連しているかどうかを判定することができる。複数のセグメント又は指令と関連している（multiple segments or associated with the directive）と制御ロジック３００が判定した場合に、制御ロジックは、ステップ３７６に進んでいる。次いで、複数のセグメントが指令と関連してはいないと制御ロジック３００が判定した場合に、制御ロジックは、ステップ３７８に進んでいる。

【0082】

ステップ３７６において、制御ロジック３００は、それぞれのセグメントの合計力を比較することができる。例えば、制御ロジック３００は、ステップ３７２においてそれぞれのセグメントごとに算出された合計力を識別及び／又は認識することができる。次いで、制御ロジック３００は、ステップ３７８に進んでいる。

【0083】

ステップ３７８において、制御ロジック３００は、最小合計力を判定することができる。例えば、制御ロジック３００は、セグメントと関連する最低力を判定するために、ステップ３７６において実施された比較を利用することができる。別の実施形態において、複数のセグメントが指令と関連していない場合に、制御ロジック３００は、単一セグメント合計力が最小合計力であると判定することができる。次いで、制御ロジックは、ステップ３８０に進んでいる。

【0084】

ステップ３８０において、制御ロジック３００は、力閾値がステップ３７８において判定された最小合計力によって充足されているかどうかを判定することができる。例えば、力閾値は、特定の力であることが可能であり、且つ、最小合計力がこのような力を充足又は超過している場合に、力閾値が充足され得る。ステップ３７８において判定された最小合計力が力閾値を充足してはいない場合に、制御ロジック３００は、ステップ３７２に戻るように進んでいる。ステップ３７８において判定された最小合計力が力閾値を充足している場合には、制御ロジック３００は、ステップ３８２に進んでいる。

【0085】

ステップ３８２において、制御ロジックはアラートを生成することができる。例えば、制御ロジック３００は、最小合計力が力閾値を充足していることを通知するアラートを生成することができる。次いで、制御ロジックは、ステップ３９０に進んでいる。

【0086】

ステップ３８４において、制御ロジック３００は、時間データを受け取ることができる。例えば、制御ロジックは、時刻を制御ロジック３００に通知し得るクロックと同期化することができる。別の実施形態において、制御ロジック３００は、持続時間と関係するデータを受け取ることができる。例えば、制御ロジック３００は、指令の開始時刻を受け取ることが可能であり、且つ、指令が有効であった持続時間を監視することができる。別の実施形態において、制御ロジック３００は、指令について制御ロジック３００に通知するのに適した任意のその他の時間データを受け取ることができる。次いで、制御ロジック３００は、ステップ３８６に進んでいる。

【0087】

ステップ３８６において、制御ロジック３００は、その第１時間閾値が充足されているかどうかを判定することができる。例えば、時間閾値は、ステップ３８４において受け取られた時間データが時刻が第１時間閾値にマッチングしていることを通知した場合に第１時間閾値が充足され得るような特定の時刻であり得る。別の実施形態において、第１時間閾値は、ステップ３８４において受け取られた時間データが特定の持続時間が第１時間閾値の持続時間を充足又は超過していることを通知した場合に第１時間閾値が充足され得るような持続時間閾値であり得る。第１時間閾値が充足されてはいないと制御ロジック３００が判定した場合に、制御ロジック３００は、ステップ３０６に戻るように進んでいる。第１時間閾値が充足されていると制御ロジック３００が判定した場合に、制御ロジック３００は、ステップ３８８に進んでいる。

【0088】

ステップ３８８において、制御ロジック３００は、アラートを生成することができる。例えば、制御ロジック３００は、第１時間閾値が充足されていることを通知するアラートを生成することができる。次いで、制御ロジック３００は、ステップ３９０に進んでいる。

【0089】

ステップ３９０において、制御ロジック３００は、指令変更を判定することができる。例えば、制御ロジックは、充足された閾値に基づいてインスタンス生成するべき指令変更のタイプを判定することができる。例えば、且つ、一実施形態において、力閾値がステップ３８０において充足されている場合に、制御ロジック３００は、指令が減速命令であるなどの場合に指令が解除されるべきであると判定することができる。別の実施形態において、且つ、一例として、第１イベント閾値がステップ３４８において充足されている場合に、制御ロジック３００は、指令が減速命令であるなどの場合に指令が相対的に大きな速度を許容するように変更されるべきであると判定することができる。別の実施形態において、且つ、一例として、第２イベント閾値がステップ３６８において充足されている場合に、制御ロジック３００は、指令が減速命令である場合に指令を解除するように、指令が変更されるべきであると判定することができる。別の実施形態において、制御ロジック３００は、利用された閾値及びステップ３４８、３６８、３８０、３８６、及び／又は３９２の任意のもの又はすべてに基づいて指令変更の任意のその他の適切なタイプを判定することができる。次いで、制御ロジックは、ステップ３９２及びステップ３９６に進んでいる。

【0090】

ステップ３９２において、制御ロジック３００は、第２時間閾値が充足されているかどうかを判定することができる。例えば、ステップ３９０において判定された指令変更が第１時間閾値がステップ３８６において充足されていることに起因したものであった場合には、制御ロジックは、最２時間閾値が充足された後に指令が再度インスタンス生成されるべきであるかどうかを判定するために第２時間閾値を利用することができる。別の実施形態において、第２時間閾値は、第１時間閾値と同様に、時間閾値及び／又は持続時間閾値であり得る。別の実施形態において、第２時間閾値は、任意の適切な時間閾値であり得る。第２時間閾値が充足されてはいないと制御ロジック３００が判定した場合に、制御ロジック３００は、ステップ３０６に戻るように進んでいる。第２時間閾値が充足されていると制御ロジック３００が判定した場合には、制御ロジックは、ステップ３９４に進んでいる。

【0091】

ステップ３９４において、制御ロジック３００は、アラートを生成することができる。例えば、制御ロジック３００は、第２時間閾値が充足されていることを通知するアラートを生成することができる。次いで、制御ロジックは、ステップ３９０に進んでいる。

【0092】

ステップ３９６において、制御ロジック３００は、指令変更をインスタンス生成することができる。例えば、制御ロジックは、指令変更のタイプとの関係においてステップ３９０において実施された判定を利用することが可能であり、且つ、ステップ３９６においてこのような変更をインスタンス生成することができる。例えば、制御ロジック３００は、減速命令の最大速度を変更することが可能であり、指令を終了することが可能であり、更なる命令を含むように指令を変更することが可能であり、命令を除去するように指令を変更することが可能であり、保守を必要とするように指令を変更することが可能であり、且つ／又は制御ロジック３００によって利用される閾値の充足又はその欠如に対処するのに適した任意のその他の指令変更を実行することができる。次いで、制御ロジック３００は、ステップ３９８に進んでいる。

【0093】

ステップ３９８において、制御ロジック３００は、アラートを生成することができる。例えば、制御ロジックは、指令変更がステップ３９６においてインスタンス生成されたことを通知するアラートを生成することができる。次いで、制御ロジック３００は、上述のステップの任意のものを終了又は反復することができる。

【0094】

図４Ａ及び図４Ｂは、本開示の例示用の実施形態による指令変更システム４００の特徴を実施する制御ロジックを例示するフローチャート図４００を示している。指令変更制御ロジック４００は、サーバー（例えば、サーバー１０２）、機械学習モジュール、又はその他の適切なシステム上のアルゴリズムとして実装することができる。これに加えて、指令変更制御ロジック４００は、指令管理システム２０２、圧縮トラッキングシステム２０４、及びアラート管理システム２０６を含む圧縮に関係する減速命令管理システム２００の１つ又は複数の特徴を実装又は内蔵することができる。指令変更制御ロジック４００は、ソフトウェア、ハードウェア、アプリケーションプログラミングインターフェイス（ＡＰＩ）、ネットワーク接続、ネットワーク転送プロトコル、ＨＴＭＬ、ＤＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、Ｄｏｊｏ、Ｒｕｂｙ、Ｒａｉｌｓ、その他の適切なアプリケーション、又はこれらの適切な組合せによって実現することができる。

【0095】

指令変更制御ロジック４００は、データを同時に処理することにより、複数のプロセス及びスレッドを生成するためにコンピュータプラットフォームの能力を活用することができる。指令変更制御ロジック４００の速度及び効率性は、要員の安全性を促進するために複数のプロセスをインスタンス生成することにより、格段に改善されている。但し、プログラミングの当業者は、単一処理スレッドの使用も利用され得ると共に本開示の範囲に含まれることを理解するであろう。

【0096】

本実施形態の指令変更制御ロジック４００は、ステップ４０２において開始している。ステップ４０２において、制御ロジック４００は、指令データを受け取ることができる。例えば、制御ロジック４００は、指令のタイプ、指令の命令、指令が関連している軌道の部分、指令データが関連している軌道セグメント、又は指令に関係する任意のその他のデータを受け取ることができる。例えば、制御ロジック４００は、指令が鉄道軌道の特定の部分上において速度を低減するように車両に命令し得る減速命令であることを受け取ることができる。別の実施形態において、制御ロジック４００は、指令が変更及び／又は終了され得る方式に関係するデータを受け取ることができる。例えば、制御ロジック４００は、指令を変更するために充足される必要がある力閾値に関係するデータを受け取ることができる。別の例において、制御ロジック４００は、指令が変更及び／又は解除されるために充足されなければならないイベントカウント閾値及び／又はイベント閾値を受け取ることができる。次いで、制御ロジック４００は、ステップ４０４に進んでいる。

【0097】

ステップ４０４において、制御ロジック４００は、レコードを生成することができる。例えば、レコードは、指令及び／又は指令に関係するデータを含むことができる。一実施形態において、レコードは、指令の時刻及び日付、指令の命令、及び／又は指令に関係する任意のその他のデータを含むことができる。別の実施形態において、ステップ４０４において生成されるレコードは、制御ロジック４００によって生成及び／又は変更された更なるデータを保存するように構成することができる。この結果、ステップ４０４において生成されるレコードは、指令及び関連するデータのみならず、指令及び／又はその変更と関係するイベント及び／又は車両及び／又は任意のその他のデータを含むことができる。次いで、制御ロジック４００は、ステップ４０６に進んでいる。

【0098】

ステップ４０６において、制御ロジック４００は、アラートを生成することができる。例えば、制御ロジック４００は、指令データが受け取られ、そしてアラートが生成されるべきである（directive data was received, and alert should be generated）と判定することができる。別の実施形態において、制御ロジック４００は、鉄道システムの間において且つ／又は鉄道要員にアラートを送信することができる。例えば、制御ロジック４００は、１つ又は複数のシステムのみならず関連する要員に、指令が鉄道軌道の特定の部分との関係においてインスタンス生成されたことを通知することができる。次いで、制御ロジック４００は、ステップ４０８に進んでいる。

【0099】

ステップ４０８において、制御ロジック４００は、軌道データを受け取ることができる。例えば、制御ロジック４００は、軌道場所データ、軌道セグメントデータ、軌道セグメント識別データ、軌道タイプ、軌道状態、又は軌道に関係するその他のデータを受け取ることができる。次いで、制御ロジック４００は、ステップ４１０に進んでいる。

【0100】

ステップ４１０において、制御ロジック４００は、セグメントを判定することができる。例えば、制御ロジック４００は、ステップ４０８において軌道の特定の長さに関係するデータを受け取ることが可能であり、且つ、ステップ４１０において軌道のこのような長さがセグメント化されるべき方式を判定することができる。例えば、制御ロジック４００は、軌道の長さがセグメント化されるべき方式を軌道データ内において通知として受け取ることができる。別の実施形態において、制御ロジック４００は、軌道データに基づいて軌道がセグメント化されるべき方式を決定することができる。例えば、制御ロジック４００は、本線及び側線の両方が存在していることを判定することが可能であり、且つ、更には、本線の一部分が側線とは異なるセグメントであるはずであると判定することができる。別の実施形態において、制御ロジック４００は、軌道の一部分がセグメント長によって複数のセグメントに分割され得るように、セグメントが特定の長さを有するべきであると判定することができる。別の実施形態において、制御ロジック４００は、特定の機器の存在、枕木の組成、レールタイプ、年齢、又は制御ロジック４００が１つ又は複数のセグメントに鉄道軌道の一部分をセグメント化することを可能にするのに適した任意のその他の基準を含む任意の適切なメカニズムによってセグメントを判定することができる。別の実施形態において、制御ロジック４００は、指令制御を可能にするのに適した任意の方式によって軌道セグメントを判定することができる。次いで、制御ロジック４００は、ステップ４１２を有するため（to have 412）に進んでいる。

【0101】

ステップ４１２において、制御ロジック４００は、セグメントアイデンティティを割り当てることができる。例えば、制御ロジックは、ステップ４１０において判定されたセグメントに識別子を割り当てることができる。別の実施形態において、制御ロジック４００は、それぞれのセグメントが識別されるべき方式の通知を軌道データから受け取ることができる。別の実施形態において、制御ロジック４００は、識別番号をそれぞれのセグメントに割り当てることができる。別の実施形態において、制御ロジック４００は、セグメントアイデンティティと、制御ロジック４００が１つ又は複数の軌道セグメントの間を弁別することを許容するのに適した任意の方式と、を識別及び／又は割り当てることができる。次いで、制御ロジック４００は、ステップ４１４に進んでいる。

【0102】

ステップ４１４において、制御ロジック４００は、指令を１つ又は複数の軌道セグメントと関連付けることができる。例えば、制御ロジックは、指令が関連付けられるべき軌道の長さを判定するために、ステップ４０２において受け取られた指令データを利用することができる。次いで、制御ロジック４００は、指令が関連付けられるべきセグメントを判定するために、ステップ４０８において受け取られた軌道データ、ステップ４１０において判定されたセグメント、及びステップ４１２において判定されたセグメントアイデンティティを利用することができる。例えば、制御ロジック４００は、指令によってカバーされているセグメントを判定することができる。次いで、制御ロジック４００は、ステップ４１６に進んでいる。

【0103】

ステップ４１６において、制御ロジック４００は、資産を検出することができる。例えば、制御ロジック４００は、軌道上の車両を検出することができる。別の例において、制御ロジック４００は、１つ又は複数のセンサ、システム、或いは、車両及び／又はその他の資産を検出するのに適した任意のその他のコンポーネントと動作自在の通信状態にあり得る。次いで、制御ロジック４００は、ステップ４１８に進んでいる。

【0104】

ステップ４１８において、制御ロジック４００は、資産データを受け取ることができる。例えば、制御ロジック４００は、資産、資産が搬送している負荷、資産が移動している速度、又は資産に関係する任意のその他のデータに関係するデータを受け取ることができる。別の実施形態において、制御ロジック４００は、資産に関係するデータをキャプチャし且つ／又は受け取るために、任意の数のセンサ又はその他のデータ収集器との動作自在の通信状態にあり得る。次いで、制御ロジック４００は、ステップ４２０に進んでいる。

【0105】

ステップ４２０において、制御ロジック４００は、位置データポイントを受け取ることができる。例えば、制御ロジック４００は、資産の検出の位置に関係するデータポイントを受け取ることができる。例えば、制御ロジック４００は、軌道内の電流を読み取るように構成された１つ又は複数のセンサとの通信状態にあることが可能であり、且つ、制御ロジック４００は、軌道上の資産の位置を検出するためにこのようなセンサを利用することができる。別の実施形態において、制御ロジックは、全地球測位システム、レーダー、低エネルギーＢｌｕｅｔｏｏｔｈ、或いは、鉄道軌道上の資産の位置を判定するための通信及び／又はプロトコル及び／又はデータの任意のその他のタイプを利用することができる。別の実施形態において、制御ロジック４００は、ステップ４１０及び４１２において判定及び／又は識別された特定の軌道セグメントと関連付けられ得る位置データポイントを受け取ることができる。例えば、制御ロジック４００は、特定の軌道セグメント上の資産の位置を通知する位置データポイントをステップ４２０において受け取ることができる。次いで、制御ロジック４００は、ステップ４２２に進んでいる。

【0106】

ステップ４２２において、制御ロジック４００は、環境データを受け取ることができる。例えば、制御ロジック４００は、環境データをキャプチャするように構成された１つ又は複数のセンサとの動作自在の通信状態にあり得る。別の例において、環境データは、湿度、温度、天候、気候、圧力、又は任意のその他の環境データを含むことができる。別の実施形態において、制御ロジック４００は、環境データを収集するように且つこのようなデータを制御ロジック４００に送信するように構成され得る１つ又は複数のその他のシステムからデータを受け取ることができる。次いで、制御ロジック４００は、ステップ４２４に進んでいる。

【0107】

ステップ４２４において、制御ロジック４００は、イベント基準を判定することができる。例えば、制御ロジック４００は、カウントするべきイベントの１つ又は複数のタイプを判定することができる。例えば、制御ロジック４００は、カウントされるべきイベントに関するその他のシステム及び／又は要員からの通知を受け取ることができる。別の例において、制御ロジック４００は、１つ又は複数のイベントタイプに関係する基準を含むことができる。別の実施形態において、制御ロジック４００は、複数のタイプのイベントがカウントされるべきであると判定することができる。例えば、制御ロジック４００は、イベント基準が特定の速度において移動する車両を含むと判定することができる。別の例において、制御ロジック４００は、イベント基準が特定の負荷と共に移動している車両を含むと判定することができる。別の実施形態において、制御ロジック４００は、イベント基準が特定の速度において移動する且つ特定の負荷を有する車両を含むと判定することができる。別の実施形態において、制御ロジック４００は、指令及び／又はその変更と関連する任意のその他の基準を利用することができる。別の実施形態において、制御ロジック４００は、制御ロジック４００がバラストの圧縮をトラッキングし且つ／又は指令が変更及び／又は終了されるべきであるかどうかを判定することを可能にするのに適した任意のイベント基準を利用することができる。次いで、制御ロジック４００は、ステップ４２６に進んでいる。

【0108】

ステップ４２６において、制御ロジック４００は、経路をトレーシングすることができる。例えば、制御ロジックは、鉄道軌道に沿った経路をトレーシングするために、ステップ４２０において受け取られた位置データポイントを利用することがきる。例えば、制御ロジック４００は、位置データポイントを受け取ることが可能であり且つ／又は資産が特定の軌道セグメント上に存在している且つ／又は存在していたことを認識することが可能であり、且つ、更には、識別された軌道セグメントを使用して軌道に沿った経路をトレーシングすることができる。例えば、制御ロジック４００は、資産が２つの別個の軌道セグメント上において配置されている且つ／又は配置されていたことを通知する位置データポイントを受け取ることができる。次いで、制御ロジック４００は、このような２つの軌道セグメントの間の経路をトレーシングすることが可能であり、且つ、経路が第３の軌道セグメントを横断しているかどうかを判定することができる。この結果、制御ロジック４００は、鉄道軌道の１つ又は複数の軌道に沿った資産の経路を判定することができる。別の実施形態においては、この結果、制御ロジック４００は、制御ロジック４００が資産が特定の軌道セグメントに沿って移動したことを直接的に通知する位置データポイントをステップ３２６において受け取らなかった場合にも、１つ又は複数の軌道セグメントに適用されたイベント及び力を判定することができる。次いで、制御ロジック４００は、ステップ４２８に進んでいる。

【0109】

ステップ４２８において、制御ロジック４００は、ステップ４２６においてトレーシングされた経路が指令と関連するセグメントを横断したかどうかを判定することができる。例えば、制御ロジックは、ステップ４２６においてトレーシングされた経路をステップ４１４において指令と関連付けられているセグメントと比較することが可能であり、且つ、経路によって横断されたセグメントの任意のものが指令と関連している／関連していたかどうかを判定することができる。制御ロジック４００は、ステップ４２６においてトレーシングされた経路が指令と関連付けられている１つ又は複数のセグメントを横断してはいないと制御ロジック４００が判定した場合に、ステップ４１６に進んでいる。次いで、制御ロジック４００は、ステップ４２６においてトレーシングされた経路が指令と関連付けられている１つ又は複数のセグメントを横断していると制御ロジック４００が判定した場合に、ステップ４３０に進んでいる。

【0110】

ステップ４３０において、制御ロジック４００は、ステップ４２２において受け取られた環境データが第１環境閾値を充足しているかどうかを判定することができる。例えば、環境閾値は、温度閾値であり得る。例えば、環境データは、レール温度及び／又はレール温度に影響し得る周辺温度を含むことができる。別の例において、環境データは、例えば、レール温度に影響し得るものなどの太陽及び／又は放射の量を通知し得るデータなどのＵＶインデックスを含むことができる。例えば、環境データが特定の温度を通知している場合に、環境閾値は、環境データが特定の温度を充足又は超過している場合に環境閾値が充足され得るような特定の温度であり得る。別の実施形態において、第１環境閾値は、ステップ４２２において受け取られた環境データが特定の湿度を通知している場合に且つ湿度が環境閾値の湿度を充足又は超過している場合に第２環境閾値が充足され得るような湿度閾値であり得る。別の実施形態において、第１環境閾値は、任意の適切な環境閾値であり得る。第１環境閾値が充足されていると制御ロジックが判定した場合に、制御ロジックは、ステップ４３２に進んでいる。第１環境閾値が充足されてはいないと制御ロジック４００が判定した場合には、制御ロジック４００は、ステップ４４０に進んでいる。

【0111】

ステップ４３２において、制御ロジックは、イベント閾値が充足されているかどうかを判定することができる。例えば、制御ロジック４００は、判定されたイベントカウントを利用することが可能であり、且つ、イベント閾値が充足されているかどうかを判定するためにこのようなイベントカウントをイベント閾値と比較することができる。この結果、制御ロジック４００は、指令が時期尚早に解除及び／又は変更されないように、特定の指令と関連する１つ又は複数のセグメントがイベント閾値を充足又は超過することを保証することができる。イベント閾値が充足されていると制御ロジック４００が判定した場合に、制御ロジック４００は、ステップ４３８に進んでいる。イベント閾値が充足されてはいないと制御ロジック４００が判定した場合には、制御ロジックは、ステップ４３４に進んでいる。

【0112】

ステップ４３４において、制御ロジック４００は、資産データを１つ又は複数のイベント基準と比較することができる。例えば、制御ロジック４００は、ステップ４１８において受け取られた資産データを利用することが可能であり、且つ、このようなデータをステップ４２４において判定されたイベント基準と比較することができる。一実施形態においては、複数の基準をイベントと関連付けることができる。別の実施形態においては、単一基準をイベントと関連付けることができる。次いで、制御ロジック４００は、ステップ４３６に進んでいる。

【0113】

ステップ４３６において、制御ロジック４００は、ステップ４１８において受け取られた資産データがステップ４２４において判定されたイベント基準を充足している場合にイベントカウントを増分することができる。例えば、制御ロジック４００は、指令と関連するそれぞれのセグメントごとに適格イベントを追跡することができる。例えば、制御ロジック４００は、１つ又は複数のイベントカウントを任意の特定のセグメントと関連付けることが可能であり、且つ、特定のイベント基準を充足するイベントの数をカウントすることができる。別の実施形態において、制御ロジック４００は、イベント基準を充足するイベントのイベントカウントを維持することができる。次いで、制御ロジック４００は、ステップ４３２に進んでいる。

【0114】

ステップ４３８において、制御ロジック４００は、指令変更をインスタンス生成することができる。例えば、制御ロジックは、イベントカウント閾値が充足されたというステップ４３２において実施された判定を利用することが可能であり、且つ、ステップ４３８においてこのような変更をインスタンス生成することができる。例えば、制御ロジック４００は、減速命令の最大速度を変更することが可能であり、指令を終了することが可能であり、更なる命令を含むように指令を変更することが可能であり、命令を除去するように指令を変更することが可能であり、保守を必要とするように指令を変更することが可能であり、且つ／又は、制御ロジック４００によって利用された閾値の充足又はその欠如に対処するのに適した任意のその他の指令変更を実行することができる。次いで、制御ロジック４００は、上述のステップの任意のものを終了又は反復することができる。

【0115】

ステップ４４０において、制御ロジック４００は、ステップ４２２において受け取られた環境データが第２環境閾値を充足しているかどうかを判定することができる。例えば、環境閾値は、温度閾値であり得る。例えば、環境データは、レール温度及び／又はレール温度に影響し得る周辺温度を含むことができる。別の例において、環境データは、レール温度に影響し得るものなどの太陽及び／又は放射の量を通知し得るデータなどのＵＶインデックスを含むことができる。例えば、環境データが特定の温度を通知している場合に、環境閾値は、環境データが特定の温度を充足又は超過している場合に環境閾値が充足され得るような特定の温度であり得る。別の実施形態において、第２環境閾値は、ステップ４２２において受け取られた環境データが特定の湿度を通知しており且つ湿度が環境閾値の湿度を充足又は超過している場合に第２環境閾値が充足され得るような湿度閾値であり得る。別の実施形態において、第２環境閾値は、任意の適切な環境閾値であり得る。第２環境閾値が充足されていると制御ロジックが判定した場合に、制御ロジックは、ステップ４４２に進んでいる。第２環境閾値が充足されてはいないと制御ロジック４００が判定した場合には、制御ロジック４００は、ステップ４４０に進んでいる。

【0116】

ステップ４４２において、制御ロジックは、イベント閾値が充足されているかどうかを判定することができる。例えば、イベント閾値は、カウントされたタイプＡイベントに関係付けることができる。一実施形態において、タイプＡイベントは、例えば、ステップ４３２においてイベント閾値と比較されたイベントと比較される異なる基準を含むことができる。例えば、タイプＡイベント用のイベント基準は、例えば、第２環境閾値がステップ４４０において判定された場合に充足されていることなどを理由として、異なり得る。例えば、イベント基準は、増大又は低減された速度限度、重量限度、又は任意のその他の基準を含むことができる。例えば、制御ロジック４００は、判定されたイベントカウントを利用することが可能であり、且つ、タイプＡイベント閾値が充足されているかどうかを判定するためにこのようなイベントカウントをイベント閾値と比較することができる。この結果、制御ロジック４００は、指令が時期尚早に解除及び／又は変更されないように、特定の指令と関連する１つ又は複数のセグメントがタイプＡイベント閾値を充足又は超過することを保証することができる。イベント閾値が充足されていると制御ロジック４００が判定した場合に、制御ロジック４００は、ステップ４５６に進んでいる。イベント閾値が充足されてはないと制御ロジック４００が判定した場合には、制御ロジックは、ステップ４４４に進んでいる。

【0117】

ステップ４４４において、制御ロジック４００は、資産データを１つ又は複数のタイプＡイベント基準と比較することができる。例えば、制御ロジック４００は、ステップ４１８において受け取られた資産データを利用することが可能であり、且つ、このようなデータをステップ４２４において判定されたタイプＡイベント基準と比較することができる。一実施形態においては、複数の基準をタイプＡイベントと関連付けることができる。別の実施形態においては、単一基準をタイプＡイベントと関連付けることができる。次いで、制御ロジック４００は、ステップ４４６に進んでいる。

【0118】

ステップ４４６において、制御ロジック４００は、ステップ４１８において受け取られた資産データがステップ４２４において判定されたタイプＡイベント基準を充足している場合にタイプＡイベントカウントを増分することができる。例えば、制御ロジック４００は、指令と関連するそれぞれのセグメントごとに適格イベントを追跡することができる。例えば、制御ロジック４００は、１つ又は複数のイベントカウントを任意の特定のセグメントと関連付けることが可能であり、且つ、特定のイベント基準を充足するイベントの数をカウントすることができる。別の実施形態において、制御ロジック４００は、タイプＡイベント基準を充足するイベントのタイプＡカウントを維持することができる。次いで、制御ロジック４００は、テップ４４２に進んでいる。

【0119】

ステップ４４８において、制御ロジックは、イベント閾値が充足されているかどうかを判定することができる。例えば、イベント閾値は、カウントされたタイプＢイベントに関係付けることができる。一実施形態において、タイプＢイベントは、例えば、ステップ４３２及び／又はステップ４４２においてイベント閾値と比較されたイベントと比較される異なる基準を含むことができる。例えば、タイプＢイベント用のイベント基準は、例えば、第２環境閾値がステップ４４０において判定された場合に充足されており且つタイプＡイベント閾値が充足されていることなどを理由として、異なり得る。例えば、イベント基準は、増大又は低減された速度限度、重量限度、又は任意のその他の基準を含むことができる。例えば、制御ロジック４００は、判定されたイベントカウントを利用することが可能であり、且つ、タイプＢイベント閾値が充足されているかどうかを判定するためにこのようなイベントカウントをイベント閾値と比較することができる。この結果、制御ロジック４００は、指令が時期尚早に解除及び／又は変更されないように、特定の指令と関連する１つ又は複数のセグメントがタイプＢイベント閾値を充足又は超過することを保証することができる。イベント閾値が充足されていると制御ロジック４００が判定した場合に、制御ロジック４００は、ステップ４５６に進んでいる。イベント閾値が充足されてはいないと制御ロジック４００が判定した場合には、制御ロジックは、ステップ４５０に進んでいる。

【0120】

ステップ４５０において、制御ロジック４００は、資産データを１つ又は複数のタイプＢイベント基準と比較することができる。例えば、制御ロジック４００は、ステップ４１８において受け取られた資産データを利用することが可能であり、且つ、このようなデータをステップ４２４において判定されたタイプＢイベント基準と比較することができる。一実施形態においては、複数の基準をタイプＢイベントと関連付けることができる。別の実施形態においては、単一の基準をタイプＢイベントと関連付けることができる。次いで、制御ロジック４００は、ステップ４５２に進んでいる。

【0121】

ステップ４５２において、制御ロジック４００は、ステップ４１８において受け取られた資産データがステップ４２４において判定されたタイプＢイベント基準を充足している場合にタイプＢイベントカウントを増分することができる。例えば、制御ロジック４００は、指令と関連するそれぞれのセグメントごとに適格イベントを追跡することができる。例えば、制御ロジック４００は、１つ又は複数のイベントカウントを任意の特定のセグメントと関連付けることが可能であり、且つ、特定のイベント基準を充足しているイベントの数をカウントすることができる。別の実施形態において、制御ロジック４００は、タイプＢイベント基準を充足しているイベントのタイプＢイベントカウントを維持することができる。次いで、制御ロジック４００は、ステップ４４８に戻るように進んでいる。

【0122】

ステップ４５４において、制御ロジック４００は、第１指令変更をインスタンス生成することができる。例えば、制御ロジックは、タイプＡイベントカウント閾値が充足されたというステップ４４２において実施された判定を利用することが可能であり、且つ、ステップ４５４において第１変更をインスタンス生成することができる。例えば、制御ロジック４００は、減速命令の最大速度を変更することが可能であり、指令を終了させることが可能であり、更なる命令を含むように指令を変更することが可能であり、命令を除去するように指令を変更することが可能であり、保守を必要とするように指令を変更することが可能であり、且つ／又は、制御ロジック４００によって利用された閾値の充足又は欠如に対処するのに適した任意のその他の指令変更を実行することができる。次いで、制御ロジック４００は、上述のステップの任意のものを終了又は反復することができる。

【0123】

ステップ４５６において、制御ロジック４００は、第２指令変更をインスタンス生成することができる。例えば、第２指令変更は、ステップ４５４における第１指令変更及び／又はステップ４３８における指令変更とは異なることも可能であり或いはこれと同一であることもできる。例えば、制御ロジックは、タイプＢイベントカウント閾値が充足されたというステップ４４２において実施された判定を利用することが可能であり、且つ、ステップ４５６において第２変更をインスタンス生成することができる。例えば、制御ロジック４００は、減速命令の最大速度を変更することが可能であり、指令を終了させることが可能であり、更なる命令を含むように指令を変更することが可能であり、命令を除去するように指令を変更することが可能であり、保守を必要とするように指令を変更することが可能であり、且つ／又は、制御ロジック４００によって利用される閾値の充足又はその欠如に対処するのに適した任意のその他の指令変更を実行することができる。次いで、制御ロジック４００は、上述のステップの任意のものを終了又は反復することができる。

【0124】

ステップ４５８において、制御ロジック４００は、ステップ４２２において受け取られた環境データが第３環境閾値を充足しているかどうかを判定することができる。例えば、環境閾値は、温度閾値であり得る。例えば、環境データは、レール温度及び／又はレール温度に影響し得る周辺温度を含むことができる。別の例において、環境データは、例えば、レール温度に影響し得るものなどの太陽及び／又は放射の量を通知し得るデータなどのＵＶインデックスを含むことができる。例えば、環境データが特定の温度を通知している場合に、環境閾値は、環境データが特定の温度を充足又は超過した場合に環境閾値が充足され得るような特定の温度であり得る。別の実施形態において、第３温度閾値は、ステップ４２２において受け取られた環境データが特定の湿度を通知しており且つ湿度が環境閾値の湿度を充足又は超過している場合に第２環境閾値が充足され得るような湿度閾値であり得る。別の実施形態において、第３環境閾値は、任意の適切な環境閾値であり得る。第３環境閾値が充足されていると制御ロジックが判定した場合に、制御ロジックは、ステップ４６０に進んでいる。第３環境閾値が充足されてはいないと制御ロジック４００が判定した場合には、制御ロジック４００は、ステップ４６０に進んでいる。

【0125】

ステップ４６０において、制御ロジックは、イベント閾値が充足されているかどうかを判定することができる。例えば、イベント閾値は、カウントされたタイプＣイベントと関係付けることができる。一実施形態において、タイプＣイベントは、例えば、ステップ４３２、４４２、及び／又は４４８においてイベント閾値と比較されたイベントと比較される異なる基準を含むことができる。例えば、タイプＣイベント用のイベント基準は、第３環境閾値がステップ４４０において判定された場合に充足されていることなどを理由として、異なり得る。例えば、イベント基準は、増大又は低減された速度限度、重量限度、又は任意のその他の基準を含むことができる。例えば、制御ロジック４００は、判定されたイベントカウントを利用することが可能であり、且つ、タイプＣイベント閾値が充足されているかどうかを判定するためにこのようなイベントカウントをイベント閾値と比較することができる。この結果、制御ロジック４００は、指令が時期尚早に解除及び／又は変更されないように、特定の指令と関連する１つ又は複数のセグメントがタイプＣイベント閾値を充足又は超過することを保証することができる。イベント閾値が充足されていると制御ロジック４００が判定した場合に、制御ロジック４００は、ステップ４６８に進んでいる。イベント閾値が充足されてはいないと制御ロジック４００が判定した場合には、制御ロジックは、ステップ４６２に進んでいる。

【0126】

ステップ４６２において、制御ロジック４００は、資産データを１つ又は複数のタイプＣイベント基準と比較することができる。例えば、制御ロジック４００は、ステップ４１８において受け取られた資産データを利用することが可能であり、且つ、このようなデータをステップ４２４において判定されたタイプＣイベント基準と比較することができる。一実施形態においては、複数の基準をタイプＣイベントと関連付けることができる。別の実施形態においては、単一基準をタイプＣイベントと関連付けることができる。次いで、制御ロジック４００は、ステップ４６４に進んでいる。

【0127】

ステップ４６４において、制御ロジック４００は、ステップ４１８において受け取られた資産データがステップ４２４において判定されたタイプＣイベント基準を充足している場合にタイプＣイベントカウントを増分することができる。例えば、制御ロジック４００は、指令と関連するそれぞれのセグメントごとに適格イベントを追跡することができる。例えば、制御ロジック４００は、１つ又は複数のイベントカウントを任意の特定のセグメントと関連付けることが可能であり、且つ、特定のイベント基準を充足しているイベントの数をカウントすることができる。別の実施形態において、制御ロジック４００は、タイプＣイベント基準を充足しているイベントのタイプＣイベントカウントを維持することができる。次いで、制御ロジック４００は、ステップ４６０に進んでいる。

【0128】

ステップ４６６において、制御ロジック４００は、第１指令変更をインスタンス生成することができる。例えば、制御ロジックは、タイプＣイベントカウント閾値が充足されたというステップ４６０において実施された判定を利用することが可能であり、且つ、ステップ４６６において第１変更をインスタンス生成することができる。例えば、制御ロジック４００は、減速命令の最大速度を変更することが可能であり、指令を終了することが可能であり、更なる命令を含むように指令を変更することが可能であり、命令を除去するように指令を変更することが可能であり、保守を必要とするように指令を変更することが可能であり、且つ／又は、制御ロジック４００によって利用された閾値の充足又はその欠如に対処するのに適した任意のその他の指令変更を実行することができる。次いで、制御ロジック４００は、上述のステップの任意のものを終了又は反復することができる。

【0129】

ステップ４６８において、制御ロジック４００は、イベント閾値が充足されているかどうかを判定することができる。例えば、イベント閾値は、カウントされたタイプＤイベントに関係付けることができる。一実施形態において、タイプＤイベントは、例えば、ステップ４３２及び／又はステップ４６０においてイベント閾値と比較されたイベントと比較される異なる基準を含むことができる。例えば、タイプＤイベント用のイベント基準は、第２環境閾値がステップ４４０において判定された場合に充足されており且つタイプＣイベント閾値が充足されていることなどを理由として、異なり得る。例えば、イベント基準は、増大又は低減された速度限度、重量限度、又は任意のその他の基準を含むことができる。例えば、制御ロジック４００は、判定されたイベントカウントを利用することが可能であり、且つ、タイプＤイベント閾値が充足されているかどうかを判定するためにこのようなイベントカウントをイベント閾値と比較することができる。この結果、制御ロジック４００は、指令が時期尚早に解除及び／又は変更されないように、特定の指令と関連する１つ又は複数のセグメントがタイプＤイベント閾値を充足又は超過することを保証することができる。イベント閾値が充足されていると制御ロジック４００が判定した場合に、制御ロジック４００は、ステップ４７６に進んでいる。イベント閾値が充足されてはいないと制御ロジック４００が判定した場合には、制御ロジックは、ステップ４７０に進んでいる。

【0130】

ステップ４７０において、制御ロジック４００は、資産データを１つ又は複数のタイプＤイベント基準と比較することができる。例えば、制御ロジック４００は、ステップ４１８において受け取られた資産データを利用することが可能であり、且つ、このようなデータをステップ４２４において判定されたタイプＤイベント基準と比較することができる。一実施形態においては、複数の基準をタイプＤイベントと関連付けることができる。別の実施形態においては、単一の基準をタイプＤイベントと関連付けることができる。次いで、制御ロジック４００は、ステップ４７２に進んでいる。

【0131】

ステップ４７２において、制御ロジック４００は、ステップ４１８において受け取られた資産データがステップ４２４において判定されたタイプＤイベント基準を充足している場合にタイプＤイベントカウントを増分することができる。例えば、制御ロジック４００は、指令と関連するそれぞれのセグメントごとに適格イベントを追跡することができる。例えば、制御ロジック４００は、１つ又は複数のイベントカウントを任意の特定のセグメントと関連付けることが可能であり、且つ、特定のイベント基準を充足しているイベントの数をカウントすることができる。別の実施形態において、制御ロジック４００は、タイプＤイベント基準を充足しているイベントのタイプＤイベントカウントを維持することができる。次いで、制御ロジック４００は、ステップ４６０に進んでいる。

【0132】

ステップ４７４において、制御ロジック４００は、第２指令変更をインスタンス生成することができる。例えば、第２指令変更は、ステップ４５４における第１指令変更及び／又はステップ４３８における指令変更とは異なることが可能であり或いはこれと同一であることもできる。例えば、制御ロジックは、タイプＤイベントカウント閾値が充足されたというステップ４６８において実施された判定を利用することが可能であり、且つ、ステップ４７４において第２変更をインスタンス生成することができる。例えば、制御ロジック４００は、減速命令の最大速度を変更することが可能であり、指令を終了することが可能であり、更なる命令を含むように指令を変更することが可能であり、命令を除去するように指令を変更することが可能であり、保守を必要とするように指令を変更することが可能であり、且つ／又は、制御ロジック４００によって利用された閾値の充足又はその欠如に対処するのに適した任意のその他の指令変更を実行することができる。次いで、制御ロジック４００は、上述のステップの任意のものを終了又は反復することができる。

【0133】

ステップ４７６において、制御ロジック４００は、イベント閾値が充足されているかどうかを判定することができる。例えば、イベント閾値は、カウントされたタイプＥイベントに関係付けることができる。一実施形態において、タイプＥイベントは、例えば、ステップ４３２及び／又はステップ４６０においてイベント閾値と比較されたイベント及び／又は本明細書において記述されているステップにおけるその他のイベントの任意のものと比較される異なる基準を含むことができる。例えば、タイプＥイベント用のイベント基準は、第３環境閾値がステップ４４０において判定された場合に充足されており且つタイプＤイベント閾値が充足されていることなどを理由として、異なり得る。例えば、イベント基準は、増大又は低減された速度限度、重量限度、又は任意のその他の基準を含むことができる。例えば、制御ロジック４００は、判定されたイベントカウントを利用することが可能であり、且つ、タイプＥイベント閾値が充足されているかどうかを判定するためにこのようなイベントカウントをイベント閾値と比較することができる。この結果、制御ロジック４００は、指令が時期尚早に解除及び／又は変更されないように、特定の指令と関連する１つ又は複数のセグメントがタイプＥイベント閾値を充足又は超過することを保証している。イベント閾値が充足されていると制御ロジック４００が判定した場合に、制御ロジック４００は、ステップ４７６に進んでいる。イベント閾値が充足されてはいないと制御ロジック４００が判定した場合には、制御ロジックは、ステップ４７８に進んでいる。

【0134】

ステップ４７８において、制御ロジック４００は、資産データを１つ又は複数のタイプＥイベント基準と比較することができる。例えば、制御ロジック４００は、ステップ４１８において受け取られた資産データを利用することが可能であり、且つ、このようなデータをステップ４２４において判定されたタイプＥイベント基準と比較することができる。一実施形態においては、複数の基準をタイプＥイベントと関連付けることができる。別の実施形態においては、単一の基準をタイプＥイベントと関連付けることができる。次いで、制御ロジック４００は、ステップ４８０に進んでいる。

【0135】

ステップ４８０において、制御ロジック４００は、ステップ４１８において受け取られた資産データがステップ４２４において判定されたタイプＥイベント基準を充足している場合にタイプＥイベントカウントを増分することができる。例えば、制御ロジック４００は、指令と関連するそれぞれのセグメントごとに適格イベントを追跡することができる。例えば、制御ロジック４００は、１つ又は複数のイベントカウントを任意の特定のセグメントと関連付けることが可能であり、且つ、特定のイベント基準を充足しているイベントの数をカウントすることができる。別の実施形態において、制御ロジック４００は、タイプＥイベント基準を充足しているイベントのタイプＥイベントカウントを維持することができる。次いで、制御ロジック４００は、ステップ４７６に戻るように進んでいる。

【0136】

ステップ４８２において、制御ロジック４００は、第３指令変更をインスタンス生成することができる。例えば、第３指令変更は、ステップ４６６における第１指令変更及び／又はステップ４７４における第２指令変更及び／又はステップ４３８における指令変更とは異なることが可能であり又はこれと同一であり得る。例えば、制御ロジックは、タイプＥイベントカウント閾値が充足されたというステップ４７６において実施された判定を利用することが可能であり、且つ、ステップ４８２において第３変更をインスタンス生成することができる。例えば、制御ロジック４００は、減速命令の最大速度を変更することが可能であり、指令を終了することが可能であり、更なる命令を含むように指令を変更することが可能であり、命令を除去するように指令を変更することが可能であり、維持を必要とするように指令を変更することが可能であり、且つ／又は制御ロジック４００によって利用された閾値の充足又はその欠如に対処するのに適した任意のその他の指令変更を実行することができる。制御ロジック４００は、上述のステップの任意のものを終了又は反復することができる。

【0137】

図５は、本開示の例示用の実施形態による圧縮監視システム５００の特徴を実施する制御ロジックを例示するフローチャート図５００を示している。圧縮監視制御ロジック５００は、サーバー（例えば、サーバー１０２）、機械学習モジュール、又はその他の適切なシステム上のアルゴリズムとして実装することができる。これに加えて、圧縮制御ロジック５００は、指令管理システム２０２及び／又は圧縮トラッキングシステム２０４及び／又はアラート管理システム２０６を含む圧縮に関係する減速命令管理システム２００の１つ又は複数の特徴を実装又は内蔵することができる。圧縮監視制御ロジック５００は、ソフトウェア、ハードウェア、アプリケーションプログラミングインターフェイス（ＡＰＩ）、ネットワーク接続、ネットワーク転送プロトコル、ＨＴＭＬ、ＤＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、Ｄｏｊｏ、Ｒｕｂｙ、Ｒａｉｌｓ、その他の適切なアプリケーション、又はこれらの適切な組合せによって実現することができる。

【0138】

圧縮監視制御ロジック５００は、データを同時に処理することにより、複数のプロセス及びスレッドを生成するためにコンピュータプラットフォームの能力を活用することができる。圧縮監視制御ロジック５００の速度及び効率性は、要員の安全性を促進するために複数のプロセスをインスタンス生成することにより、格段に改善されている。但し、プログラミングの当業者は、単一処理スレッドの使用も利用され得ると共に本開示の範囲に含まれることを理解するであろう。

【0139】

本実施形態の圧縮監視制御ロジック５００プロセスフローは、ステップ５０２において開始しており、この場合に、制御ロジック５００は、指令データを受け取っている。例えば、制御ロジック５００は、指令のタイプ、指令の命令、指令が関連している軌道の部分、指令データが関連している軌道セグメント、又は指令に関係する任意のその他のデータを受け取ることができる。例えば、制御ロジック５００は、指令が、鉄道軌道の特定の部分上において速度を低減するように車両に命令し得る減速命令であることを受け取ることができる。別の実施形態において、制御ロジック５００は、指令が変更及び／又は終了され得る方式に関係するデータを受け取ることができる。例えば、制御ロジック５００は、指令を変更するために充足される必要がある力閾値に関係するデータを受け取ることができる。別の例において、制御ロジック５００は、指令が変更及び／又は解除されるために充足されなければならないイベントカウント閾値及び／又はイベント閾値を受け取ることができる。一実施形態において、指令は、減速命令であり得る。次いで、制御ロジック５００は、ステップ５０４に進んでいる。

【0140】

ステップ５０４において、制御ロジック５００は、その第１時間閾値が充足されているかどうかを判定することができる。例えば、時間閾値は、時刻が第１時間閾値にマッチングしている場合に第１時間閾値が充足され得るような特定の時刻であり得る。別の実施形態において、第１時間閾値は、特定の持続時間が第１時間閾値の持続時間を充足又は超過している場合に第１時間閾値が充足され得るような持続時間閾値であり得る。第１時間閾値が充足されてはいないと制御ロジック５００が判定した場合に、制御ロジック５００は、ステップ５１４に進んでいる。第１時間閾値が充足されていると制御ロジック５００が判定した場合には、制御ロジック５００は、ステップ５０６に進んでいる。

【0141】

ステップ５０６において、制御ロジック５００は、除去要求を送信することができる。例えば、制御ロジック５００は、除去要求を指令管理システム２０２に送信することができる。一実施形態において、除去要求は、指令管理システム２０２が１つ又は複数の軌道セグメントからの指令の除去及び／又は指令の関連付け解除をインスタンス生成するための命令を担持することができる。別の実施形態において、ステップ５０６において制御ロジック５００によって送信される除去要求は、要員が指令を除去し得るように管理者（director）が除去されるべきであると鉄道要員に通知することができる。次いで、制御ロジック５００は、ステップ５０８に進んでいる。

【0142】

ステップ５０８において、制御ロジック５００は、除去要求を受け取ることができる。例えば、指令管理システム２０２が除去要求を受け取ることができる。一実施形態において、除去要求の受取りは、指令が除去されるべきであると制御ロジック５００に通知することができる。次いで、制御ロジックは、ステップ５１０に進んでいる。

【0143】

ステップ５１０において、制御ロジック５００は、指令を終了することができる。例えば、指令が減速命令である場合に、制御ロジック５００は、もはや１つ又は複数の軌道セグメント上において速度の低減が存在しないように減速命令を破棄することができる。別の実施形態において、制御ロジック５００は、要員又は別のシステムを介して終了を要求することができる。次いで、制御ロジック５００は、ステップ５１２に進んでいる。

【0144】

ステップ５１２において、制御ロジック５００は、アラート生成要求を送信することができる。例えば、制御ロジック５００は、アラート生成要求をアラート管理システム２０６に送信することができる。別の実施形態において、制御ロジック５００は、アラート生成要求を制御ロジック５００との通信状態にある１つ又は複数のシステム及び／又は要員に送信することができる。次いで、制御ロジック５００は、上述のステップの任意のものを終了又は反復することができる。

【0145】

ステップ５１４において、制御ロジック５００は、第２時間閾値が充足されているかどうかを判定することができる。例えば、制御ロジック５００は、第２時間閾値が充足された後に指令が再インスタンス生成されるべきかどうかを判定するために第２時間閾値を利用することができる。別の実施形態において、第２時間閾値は、第１時間閾値と同様に、時間閾値及び／又は持続時間閾値であり得る。別の実施形態において、第２時間閾値は、任意の適切な時間閾値であり得る。第２時間閾値が充足されてはいないと制御ロジック５００が判定した場合に、制御ロジック５００は、ステップ５１６に進んでいる。第２時間閾値が充足されていると制御ロジック５００が判定した場合には、制御ロジックは、ステップ５２０に進んでいる。

【0146】

ステップ５１６において、制御ロジック５００は、力閾値が合計力によって充足されているかどうかを判定することができる。例えば、力閾値は、特定の力であることが可能であり、且つ、合計力がこのような力を充足又は超過している場合に力閾値は充足され得る。ステップ５１６において判定された合計力が力閾値を充足してはいない場合に、制御ロジック５００は、ステップ５１８に進んでいる。判定された合計力が力閾値を充足している場合には、制御ロジック５００は、ステップ５０６に進んでいる。

【0147】

ステップ５１８において制御ロジック５００は、指令場所と関連する軌道上の印加された力をトラッキングすることを継続することができる。例えば、制御ロジック５００は、指令場所において軌道にそれまで印加されていた合計力が力閾値を超過してはいないとステップ５１６において判定することが可能であり、制御ロジック５００は、これにより、合計力のトラッキングを継続するべきであると判定することができる。次いで、制御ロジック５００は、上述のステップの任意のものを終了又は反復することができる。

【0148】

ステップ５２０において、制御ロジック５００は、力閾値が合計力によって充足されているかどうかを判定することができる。例えば、力閾値は、特定の力であることが可能であり、且つ、合計力がこのような力を充足又は超過している場合に力閾値は充足され得る。ステップ５２０において判定された合計力が力閾値を充足してはいない場合に、制御ロジック５００は、ステップ５２２に進むことができる。判定された合計力が力閾値を充足している場合には、制御ロジック５００は、ステップ５０６に進むことができる。

【0149】

ステップ５２２において、制御ロジック５００は、通知を送信することができる。例えば、通知は、力閾値が充足されない状態において留まっているという通知を含むことができる。次いで、制御ロジック５００は、ステップ５２４に進んでいる。

【0150】

ステップ５２４において、制御ロジック５００は、通知を受け取ることができる。例えば、制御ロジック５００は、ステップ５２２において送信された通知を受け取ることができる。別の実施形態において、制御ロジック５００は、力閾値が充足されていないという通知を受け取ることができる。別の実施形態において、制御ロジック５００及び／又は指令管理システム２０２は、通知を受け取ることができる。次いで、制御ロジック５００は、ステップ５２６に進んでいる。

【0151】

ステップ５２６において、制御ロジック５００は、第１指令に関係する指令を生成することができる。例えば、ステップ５２６において生成される指令は、ステップ５０２において受け取られる指令及び／又はデータと同一又は類似のパラメータを含むことができる。別の実施形態において、ステップ５２６において生成される指令は、ステップ５２６において生成された指令の変更及び／又は終了が一例においては合計力計測による力閾値の充足に少なくとも部分的に依存し得るように、関係する合計力カウント及び計測を含むことができる。別の実施形態において、初期指令と関連する合計力計測は、ステップ５２６において生成される指令にキャリーオーバーすることができる。次いで、制御ロジック５００は、ステップ５２８及びステップ５３０に進んでいる。

【0152】

ステップ５２８において、制御ロジック５００は、アラート生成要求を送信することができる。例えば、制御ロジック５００は、アラート生成要求をアラート管理システムに送信することができる。別の実施形態において、制御ロジック５００は、新しい指令がステップ５２６において生成されていることからアラートが生成されるべきであると１つ又は複数のシステムに通知することができる。次いで、制御ロジック５００は、上述のステップの任意のものを終了又は反復することができる。

【0153】

ステップ５３０において、制御ロジック５００は、指令データを送信することができる。例えば、制御ロジック５００は、ステップ５２６において生成された指令に関係するデータを送信することができる。次いで、制御ロジック５００は、上述のステップの任意のものを終了又は反復することができる。

【0154】

一実施形態において、制御ロジック５００は、時刻及び／又は力閾値に基づいて指令の除去及び再発令を可能にすることができる。例えば、制御ロジック５００は、プロセスフロー５００を利用することにより、夜が明けた又は特定の時刻に到達したなどの場合に指令の除去を要求することができる。指令が除去されている間に、制御ロジック５００は、指令場所において軌道上に印加される合計力をトラッキングすることを継続することができる。別の実施形態においては、午前などの別の時刻に到達した際に、制御ロジック５００は、まず、力閾値が充足されたかどうかをチェックすることが可能であり、且つ、これが充足されている場合に、制御ロジック５００は、指令が除去された状態に留まることを要求することができる。別の実施形態において、第２時間閾値が充足された後に且つ合計力閾値が充足されてはいない場合に、制御ロジックは、力閾値が充足されない状態に留まっているという通知を送信することができる。別の実施形態において、制御ロジック５００は、力閾値が依然として充足されてはいないが時間閾値が充足されていることから軌道上において減速命令を継続させるように、類似のパラメータを有する且つ／又はさもなければ第１指令に関係付けられた新しい指令をインスタンス生成するためにこの通知を使用することができる。この結果、制御ロジック５００は、１つ又は複数の時間閾値が力閾値によって判定された場合に充足されていることに起因して、解除された指令を選択的に再確立することができる。

【0155】

図６は、本開示の例示用の実施形態による力トラッキングシステム６００の特徴を実施する制御ロジックを例示するフローチャート図６００を示している。力トラッキング制御ロジック６００は、サーバー（例えば、サーバー１０２）、機械学習モジュール、又はその他の適切なシステム上のアルゴリズムとして実装することができる。これに加えて、力トラッキング制御ロジック６００は、指令管理システム２０２、圧縮トラッキングシステム２０４、及びアラート管理システム２０６を含む圧縮に関係する減速命令管理システム２００の１つ又は複数の特徴を実装又は内蔵することができる。力トラッキング制御ロジック６００は、ソフトウェア、ハードウェア、アプリケーションプログラミングインターフェイス（ＡＰＩ）、ネットワーク接続、ネットワーク転送プロトコル、ＨＴＭＬ、ＤＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、Ｄｏｊｏ、Ｒｕｂｙ、Ｒａｉｌｓ、その他の適切なアプリケーション、又はこれらの適切な組合せによって実現することができる。

【0156】

力トラッキング制御ロジック６００は、データを同時に処理することにより、複数のプロセス及びスレッドを生成するためにコンピュータプラットフォームの能力を活用することができる。力トラッキング制御ロジック６００の速度及び効率性は、要員の安全性を促進するために複数のプロセスをインスタンス生成することにより、格段に改善されている。但し、プログラミングの当業者は、単一処理スレッドの使用も利用され得ると共に本開示の範囲に含まれることを理解するであろう。

【0157】

本実施形態の力トラッキング制御ロジック６００は、ステップ６０２において開始しており、この場合に、制御ロジック６００は、列車イベント及び力データを受け取っている。一実施形態において、列車イベントは、指令と関連する軌道セグメントを通過している列車を含むことができる。別の実施形態において、列車イベントは、指令と関連する軌道セグメント上を移動している特定の速度及び／又は特定の重量の列車を含むことができる。別の実施形態において、列車イベントは、保守インシデント、急制動インシデント、又はイベントの任意のその他のタイプを含む列車イベントの任意のその他の種類であり得る。別の実施形態において、力データは、例えば、軌道上の列車の重量及び／又は力計測を含むことができる。次いで、制御ロジック６００は、ステップ６０４に進んでいる。

【0158】

また、本実施形態の力トラッキング制御ロジック６００は、ステップ６２８において開始しており、この場合に、制御ロジック６００は、指令データを受け取っている。例えば、制御ロジック６００は、指令のタイプ、指令の命令、指令が関連している軌道の部分、指令データが関連している軌道セグメント、又は指令に関係する任意のその他のデータを受け取ることができる。例えば、制御ロジック６００は、指令が、鉄道軌道の特定の部分上において速度を低減するように車両に命令し得る減速命令であることを受け取ることができる。別の実施形態において、制御ロジック６００は、指令が変更及び／又は終了され得る方式に関係するデータを受け取ることができる。例えば、制御ロジック６００は、指令を変更するために充足される必要がある力閾値に関係するデータを受け取ることができる。別の例において、制御ロジック６００は、指令が変更及び／又は解除されるために充足されなければならないイベントカウント閾値及び／又はイベント閾値を受け取ることができる。次いで、制御ロジック６００は、ステップ６３０に進んでいる。

【0159】

ステップ６３０において、制御ロジック６００は、アラートを生成することができる。例えば、制御ロジックは、指令が受け取られたことを通知するアラートを生成することができる。別の例において、制御ロジック６００は、指令がインスタンス生成されたことを通知するアラートを生成することができる。次いで、制御ロジック６００は、ステップ６０４に進んでいる。

【0160】

ステップ６０４において、制御ロジック６００は、指令と関連する軌道セグメントなどの１つ又は複数の軌道セグメント上において作用されている合計力をトラッキングすることができる。別の実施形態において、制御ロジック６００は、ステップ６０２において判定された且つ／又は受け取られた力によって増分され得る合計力計算を維持することができる。次いで、制御ロジック６００は、ステップ６０６に進んでいる。

【0161】

ステップ６０６において、制御ロジック６００は、力閾値がステップ６０４において判定された合計力によって充足されているかどうかを判定することができる。例えば、力閾値は、特定の力であることが可能であり、且つ、合計力がこのような力を充足又は超過している場合に力閾値は充足され得る。ステップ６０４において判定された合計力が力閾値を充足してはいない場合に、制御ロジック６００は、ステップ６１２に進んでいる。ステップ６０４において判定された最小合計力が力閾値を充足している場合には、制御ロジック６００は、ステップ６０８に進んでいる。

【0162】

ステップ６０８において、制御ロジック６００は、アラートを生成することができる。例えば、制御ロジックは、力閾値が充足されていることを通知するアラートを生成することができる。次いで、制御ロジック６００は、ステップ６１０に進んでいる。

【0163】

ステップ６１０において、制御ロジック６００は送信することができる。例えば、制御ロジック６００は、ステップ６０８において生成されたアラートを送信することができる。別の実施形態において、制御ロジック６００は、合計力計算、力閾値、列車イベント、力データ、又は任意のその他のデータを送信することができる。次いで、制御ロジックは、ステップ６１８に進んでいる。

【0164】

ステップ６１２において、制御ロジック６００は、時間閾値が充足されているかどうかを判定することができる。例えば、時間閾値は、時刻が時間閾値とマッチングしている場合に時間閾値が充足され得るような特定の時刻であり得る。別の実施形態において、時間閾値は、特定の持続時間が時間閾値の持続時間を充足又は超過している場合に時間閾値が充足され得るような持続時間閾値であり得る。時間閾値が充足されてはいないと制御ロジック６００が判定した場合に、制御ロジック６００は、ステップ６０６に戻るように進んでいる。第１時間閾値が充足されていると制御ロジック６００が判定した場合には、制御ロジック６００は、ステップ６１４に進んでいる。

【0165】

ステップ６１４において、制御ロジック６００は、アラートを生成することができる。例えば、制御ロジック６００は、時間閾値が充足されていることを通知するアラートを生成することができる。次いで、制御ロジック６００は、ステップ６１６に進んでいる。

【0166】

ステップ６１６において、制御ロジック６００は、送信することができる。例えば、制御ロジック６００は、ステップ６１４において生成されたアラートを送信することができる。別の実施形態において、制御ロジック６００は、合計力計算、力閾値、列車イベント、力データ、又は任意のその他のデータを送信することができる。次いで、制御ロジックは、ステップ６１８に進んでいる。

【0167】

ステップ６１８において、制御ロジック６００は、指令を破棄することができる。例えば、制御ロジックは、減速命令を解除することができる。別の実施形態において、制御ロジック６００は、合計力閾値及び／又は時間閾値の充足に起因して破棄されるべきであると制御ロジック６００が判定した任意のその他の指令を破棄することができる。次いで、制御ロジック６００は、ステップ６２０に進んでいる。

【0168】

ステップ６２０において、制御ロジック６００は、指令が時間閾値に起因して破棄されたかどうかを判定することができる。例えば、指令は、合計力閾値が充足されている場合又は時間閾値が充足されている場合などに、ステップ６１８において制御ロジック６００によって破棄することができる。指令が時間閾値の充足に起因して破棄されてはいないと制御ロジック６００が判定した場合に、制御ロジック６００は、ステップ６２８に進んでいる。指令が時間閾値の充足に起因して破棄されていると制御ロジック６００が判定した場合には、制御ロジック６００は、ステップ６２２に進んでいる。

【0169】

図７は、本開示の例示用の実施形態によるトン数判定システム７００の特徴を実施する制御ロジックを例示するフローチャート図を示している。トン数判定制御ロジック７００は、サーバー（例えば、サーバー１０２）、機械学習モジュール、又はその他の適切なシステム上のアルゴリズムとして実装することができる。これに加えて、トン数判定制御ロジック７００は、指令管理システム２０２、圧縮トラッキングシステム２０４、及びアラート管理システム２０６を含む圧縮に関係する減速命令管理システム２００の１つ又は複数の特徴を実装又は内蔵することができる。トン数判定制御ロジック７００は、ソフトウェア、ハードウェア、アプリケーションプログラミングインターフェイス（ＡＰＩ）、ネットワーク接続、ネットワーク転送プロトコル、ＨＴＭＬ、ＤＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、Ｄｏｊｏ、Ｒｕｂｙ、Ｒａｉｌｓ、その他の適切なアプリケーション、又はこれらの適切な組合せによって実現することができる。

【0170】

トン数判定制御ロジック７００は、データを同時に処理することにより、複数のプロセス及びスレッドを生成するためにコンピュータプラットフォームの能力を活用することができる。トン数判定制御ロジック７００の速度及び効率性は、要員の安全性を促進するために複数のプロセスをインスタンス生成することにより、格段に改善されている。但し、プログラミングの当業者は、単一の処理スレッドの使用も利用され得ると共に本開示の範囲に含まれることを理解するであろう。

【0171】

本実施形態のトン数判定制御ロジック７００プロセスフローは、ステップ７０２において開始しており、この場合に、制御ロジック７００が開始している。次いで、制御ロジック７００は、ステップ７０４に進んでいる。

【0172】

ステップ７０４において、制御ロジック７００は、時刻が２２００時であるかどうかを判定することができる。一実施形態において、ステップ７０４において判定されている時刻は、任意の時刻であることが可能であり、或いは、任意の時刻と比較することができる。時刻が２２００時であると制御ロジック７００が判定した場合に、制御ロジック７００は、ステップ７０６に進んでいる。時刻が２２００時ではないと制御ロジック７００が判定した場合には、制御ロジック７００は、ステップ７１４に進んでいる。

【0173】

ステップ７０６において、制御ロジック７００は、除去要求を送信することができる。例えば、制御ロジック７００は、減速命令が除去されるための要求を送信することができる。次いで、制御ロジック７００は、ステップ７０８に進んでいる。

【0174】

ステップ７０８において、制御ロジック７００は、除去要求を受け取ることができる。例えば、制御ロジック７００は、即座の注意を必要とする状態又は状況についてディスパッチャに通知し得る（例えば、当技術分野において既知のものなどの）リアルタイムアラート供給（ＲＡＤＡＲ）メカニズムとの動作自在の通信状態にあることが可能であり且つ／又はこれを含むことができる。一実施形態において、ＲＡＤＡＲシステムは、要求を受け取ることができる。別の実施形態において、制御ロジック７００は、ＲＡＤＡＲシステムを含むことができる。次いで、制御ロジック７００は、ステップ７１０に進んでいる。

【0175】

ステップ７１０において、制御ロジック７００は、減速命令を取り消すことができる。例えば、制御ロジック７００は、減速命令を回避するためにディスパッチャから通知を受け取ることができる。次いで、制御ロジック７００は、ステップ７１２に進むことができる。

【0176】

ステップ７１２において、制御ロジック７００は、減速命令を除去することができる。次いで、制御ロジック７００は、上述のステップの任意のものを終了又は反復することができる。

【0177】

ステップ７１４において、制御ロジック７００は、時刻が０９００時であるかどうかを判定することができる。一実施形態において、ステップ７０４において判定されている時刻は、任意の時刻であることが可能であり、或いは、任意の時刻と比較することができる。時刻が０９００時であると制御ロジック７００が判定した場合に、制御ロジックは、ステップ７２０に進んでいる。時刻が０９００時ではないと制御ロジック７００が判定した場合には、制御ロジック７００は、ステップ７１６に進んでいる。

【0178】

ステップ７１６において、制御ロジック７００は、特定の減速命令と関連している且つトン数トラッカ７３２によってトラッキングされているトン数などの合計トン数が１０００００トン以上であるかどうかを判定することができる。別の実施形態において、合計トン数及び／又はトン数閾値は、任意のその他の適切な量であり得る。合計トン数が１０００００トン以上であると制御ロジック７００が判定した場合に、制御ロジック７００は、ステップ７０６に進んでいる。合計トン数が１０００００トン未満であると制御ロジック７００が判定した場合には、制御ロジックは、ステップ７１８に進んでいる。

【0179】

ステップ７１８において、制御ロジック７００は、合計トン数のトラッキングを継続することができる。例えば、合計トン数が１０００００トン以上ではないと制御ロジック７００が判定した場合に、制御ロジック７００は、ステップ７１６における力閾値が充足される時点まで合計トン数のトラッキングを継続すると判定することができる。

【0180】

ステップ７２０において、制御ロジック７００は、関連する減速命令を有する場所が、制御ロジック７００がステップ７０４などにおいて時間閾値の充足を判定したことに起因して取り消された減速命令を有していたかどうかを判定することができる。減速命令が、合計トン数がステップ７１６において判定され得るものなどの力閾値を充足することに起因した減速命令の取り消しなどとは対照的に、ステップ７０４における時間閾値などの時間閾値に起因して取り消されていると制御ロジック７００が判定した場合に、制御ロジック７００は、ステップ７３０に進んでいる。減速命令がステップ７０４などにおける時間閾値の充足に起因して取り消されてはいないと制御ロジック７００が判定した場合には、制御ロジック７００は、ステップ７２２に進んでいる。

【0181】

ステップ７２２において、制御ロジック７００は、複写要求を送信することができる。例えば、制御ロジック７００は、ステップ７２０において、初期減速命令が、充足のための合計とは対照的に、時間閾値の充足にのみ起因して破棄されていると判定することができる。一実施形態において、制御ロジック７００は、時間閾値の充足に起因した集合（aggregation）が、別の時間閾値がステップ７１４などにおいて充足されるなどの際に新しい減速命令を必要とし得ると判定することができる。例えば、且つ、制御ロジック７００によって例示されているように、制御ロジック７００は、この結果、温度が相対的に低く且つ（例えば、レール温度が相対的に低いことなどを理由として）バラストの圧縮解除などに起因した列車の脱線のリスクが相対的に低いなどの際には、夜間に減速命令を破棄することができる。また、別の実施形態において、制御ロジック７００は、減速命令が時刻に起因してのみ破棄された場合に、（ステップ７１６などにおいて必要とされている）合計必須トン数が充足されてはいないことから、新しい減速命令が複写されるべきであり且つ軌道の特定のエリアと関連付けられるべきであると判定することができる。別の実施形態において、制御ロジック７００は、特定の場所と当初関連付けられていた指令の複写が確立されることを要求することができる。この結果、且つ、一例として、トン数トラッカ７３２は、例えば、当技術分野において既知のＧＲＩＴなどのＧＲＩＴ７３４との動作自在の通信状態にあり得る。次いで、制御ロジック７００は、ステップ７２４に進んでいる。

【0182】

ステップ７２４において、制御ロジック７００は、類似の識別を使用することにより、オリジナルの減速命令の複写が生成されるようにすることができる。例えば、制御ロジックは、グラフィカルユーザーインターフェイス制限入力ツール（ＧＲＩＴ）７３４との動作自在の通信状態にあることが可能であり、且つ／又は、ＧＲＩＴ７３４を含むことができる。一実施形態において、制御ロジックは、ＧＲＩＴがオリジナル減速命令の直接的な複写を生成するようにすることが可能であり、且つ、既にトラッキングされている以前の減速命令からの同一のトン数が新しい減速命令にキャリーオーバーされ得るように、オリジナルの減速命令のＧＲＩＴ－ＩＤを新しい減速命令と関連付けることができる。次いで、制御ロジック７００は、ステップ７２６に進んでいる。

【0183】

ステップ７２６において、制御ロジック７００は、減速命令の複写要求がディスパッチャに送信されるようにすることができる。例えば、制御ロジック７００は、ディスパッチャが減速命令を複写するためのニーズを認知するように、ディスパッチャ（及び／又はＴＭＤＳ）に複写要求を送信することができる。次いで、制御ロジック７００は、ステップ７２８に進んでいる。

【0184】

ステップ７２８において、減速命令の複写を発行することができる。例えば、制御ロジック７００が減速命令の複写を発行することができる。別の実施形態においては、ＧＲＩＴ７３４が新しい減速命令の複写を発行することができる。別の実施形態において、減速命令の複写は、任意のその他の適切な方式で発行することができる。次いで、制御ロジック７００は、上述のステップの任意のものを終了又は反復することができる。

【0185】

ステップ７３０において、制御ロジック７００は、終了することができる。例えば、制御ロジック７００は、新しい減速命令に対するニーズが存在してはいないと判定することができる。例えば、制御ロジック７００は、オリジナルの減速命令がステップ７０４における時間閾値の充足に起因して取り消されている一方で、必須のトン数が（ステップ７１６との関係において記述されている合計力閾値などの）合計力閾値が充足されているようなラインを横断していると判定することができる。別の例において、制御ロジック７００は、減速命令が取り消されている間に１つ又は複数の軌道セグメントに跨って合計トン数のトラッキングを継続することが可能であり、且つ、このようなトン数を力閾値と比較することができる。次いで、制御ロジック７００は、上述のステップの任意のものを終了又は反復することができる。

【0186】

図８Ａ及び図８Ｂは、本開示の例示用の実施形態による減速命令除去システム８００の特徴を実施する制御ロジックを例示するフローチャート図８００を示している。減速命令除去制御ロジック８００は、サーバー（例えば、サーバー１０２）、機械学習モジュール、又はその他の適切なシステム上のアルゴリズムとして実装することができる。これに加えて、減速命令除去制御ロジック８００は、指令管理システム２０２、圧縮トラッキングシステム２０４、及びアラート管理システム２０６を含む圧縮に関係する減速命令管理システム２００の１つ又は複数の特徴を実装又は内蔵することができる。減速命令除去制御ロジック８００は、ソフトウェア、ハードウェア、アプリケーションプログラミングインターフェイス（ＡＰＩ）、ネットワーク接続、ネットワーク転送プロトコル、ＨＴＭＬ、ＤＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、Ｄｏｊｏ、Ｒｕｂｙ、Ｒａｉｌｓ、その他の適切なアプリケーション、又はこれらの適切な組合せによって実現することができる。

【0187】

減速命令除去制御ロジック８００は、データを同時に処理することにより、複数のプロセス及びスレッドを生成するためにコンピュータプラットフォームの能力を活用することができる。減速命令除去制御ロジック８００の速度及び効率性は、要員の安全性を促進するために複数のプロセスをインスタンス生成することにより、格段に改善されている。但し、プログラミングの当業者は、単一処理スレッドの使用も利用され得ると共に本開示の範囲に含まれることを理解するであろう。

【0188】

減速命令除去制御ロジック８００は、ステップ８０２、８０４、及び８３０において開始している。ステップ８０２において、制御ロジック８００は、積極型列車制御及び／又は中央集中型トラフィック制御列車イベント及びトン数を受け取ることができる。次いで、制御ロジック８００は、ステップ８０６に進んでいる。

【0189】

ステップ８０４において、制御ロジック８００は、軌道保証制御列車イベント及びトン数を受け取ることができる。次いで、制御ロジック８００は、ステップ８０６に進んでいる。

【0190】

ステップ８３０において、制御ロジック８００は、ＧＲＩＴに入力された圧縮減速命令などの圧縮減速命令を受け取ることができる。次いで、制御ロジック８００は、ステップ８３２に進んでいる。

【0191】

ステップ８３２において、制御ロジック８００は、トン数がトラッキングされることになることをユーザーに通知するために、ＧＲＩＴ内において提示され得るポップアップメッセージをインスタンス生成することができる。次いで、制御ロジック８００は、ステップ８３４に進んでいる。

【0192】

ステップ８３４において、制御ロジック８００は、オープン軌道欠陥を列挙し得るＧＲＩＴ内において提示されるポップアップメッセージをインスタンス生成することができる。次いで、制御ロジック８００は、ステップ８０６に進んでいる。

【0193】

ステップ８０６において、制御ロジック８００は、トン数計算ロジックをインスタンス生成することができる。例えば、制御ロジック８００は、本開示の原理に従って受け取られたトン数データに基づいて合計トン数を算出することを開始することができる。次いで、制御ロジックは、ステップ８０８、８１０、８１６、８１８、及び８２４に進んでいる。

【0194】

ステップ８０８において、制御ロジック８００は、１０００００トンに到達した減速命令を回避するためにフィールド電子メール通知を送信することができる。別の実施形態において、ステップ８０８における力閾値は、任意の適切なトン数であり得る。次いで、制御ロジック８００は、上述のステップの任意のものを終了又は反復することができる。

【0195】

ステップ８１０において、制御ロジック８００は、１０００００トン又はなんらかのその他の力閾値に到達した減速命令を取り消すために別の通知を送信することができる。次いで、制御ロジック８００は、ステップ８１２に進んでいる。

【0196】

ステップ８１２において、制御ロジックは、ディスパッチャ通知システムを介して取り消し通知を提供することができる。例えば、制御ロジックは、取り消し通知をＲＡＤＡＲシステムの全体を通じてディスパッチャに送信することができる。次いで、制御ロジック８００は、ステップ８１４に進んでいる。

【0197】

ステップ８１４において、制御ロジック８００は、ディスパッチャ確認メッセージを受け取ることが可能であり、且つ、減速命令を除去することが可能であり、或いは、減速命令が除去されたという通知を受け取ることができる。或いは、この代わりに、ディスパッチャは、除去プロセスの一部分でなくてもよい。次いで、制御ロジック８００は、ステップ８２２に進んでいる。

【0198】

ステップ８１６において、制御ロジック８００は、力閾値を超過した合計トン数を有する減速命令がいまだ除去されていない場合に、特定の時間インターバルにおいてエスカレーション電子メール通知を送信することができる。次いで、制御ロジック８００は、ステップ８２０に進んでいる。

【0199】

ステップ８１８において、制御ロジック８００は、特定の時間閾値が本開示の原理に従って充足されている場合に減速命令を取り消すために通知を送信することができる。例えば、制御ロジック８００は、夜間運行のために減速命令に対する通知を送信することができる。次いで、制御ロジック８００は、ステップ８２０に進んでいる。

【0200】

ステップ８２０において、ディスパッチャは、減速命令を除去することができる。一実施形態において、ディスパッチャは、例えば、ステップ８２２において、自動除去とは対照的に、減速命令を除去することができる。別の実施形態において、制御ロジック８００は、ディスパッチャが減速命令を手動によって除去しないように、ステップ８２２などにおいて自動除去を利用することができる。次いで、制御ロジック８００は、ステップ８２２に進んでいる。

【0201】

ステップ８２２において、制御ロジック８００は、トン数要件が充足された且つ／又は（夜間除去プロトコルなどの）時間閾値が充足された際に減速命令を自動的に除去することができる。次いで、制御ロジック８００は、上述のステップの任意のものを終了又は反復することができる。

【0202】

図９は、本開示の例示用の実施形態による指令管理統合システム９００の特徴を実施する制御ロジックを例示するフローチャート図９００を示している。指令管理統合制御ロジック９００は、サーバー（例えば、サーバー１０２）、機械学習モジュール、又はその他の適切なシステム上のアルゴリズムとして実装することができる。これに加えて、指令管理統合制御ロジック９００は、指令管理システム２０２、圧縮トラッキングシステム２０４、及びアラート管理システム２０６を含む圧縮に関係する減速命令管理システム２００の１つ又は複数の特徴を実装又は内蔵することができる。指令管理統合制御ロジック９００は、ソフトウェア、ハードウェア、アプリケーションプログラミングインターフェイス（ＡＰＩ）、ネットワーク接続、ネットワーク転送プロトコル、ＨＴＭＬ、ＤＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、Ｄｏｊｏ、Ｒｕｂｙ、Ｒａｉｌｓ、その他の適切なアプリケーション、又はこれらの適切な組合せによって実装することができる。

【0203】

指令管理統合制御ロジック９００は、データを同時に処理することにより、複数のプロセス及びスレッドを生成するためにコンピュータプラットフォームの能力を活用することができる。指令管理統合制御ロジック９００の速度及び効率性は、要員の安全性を促進するために複数のプロセスをインスタンス生成することにより、格段に改善されている。但し、プログラミングの当業者は、単一処理スレッドの使用も利用され得ると共に本開示の範囲に含まれることを理解するであろう。

【0204】

本実施形態の指令管理統合制御ロジック９００プロセスフローは、ステップ９０２、ステップ９０６、及びステップ９１２において開始している。ステップ９０２において、制御ロジック９００は、ＴＭＤＳからＧＵＩＤ関連付けを受け取っている。一実施形態において、鉄道軌道は、ＴＭＤＳが列車運動を既知の場所に関連付けることを許容する軌道のセグメント、待避線、及び信号機に分割することができる。別の実施形態において、これらのセグメントは、グローバルな一意の識別子（ＧＵＩＤ又はＵＩＤ）と呼称される一意の識別番号を有することができる。次いで、制御ロジック９００は、ステップ９０４に進んでいる。

【0205】

ステップ９０６において、制御ロジック９００は、ＴＭＤＳから列車イベント及びトン数データを受け取ることができる。次いで、制御ロジック９００は、ステップ９０８に進んでいる。

【0206】

ステップ９０４において、制御ロジック９００は、ネットワークのＧＵＩＤビューを構築することができる。例えば、制御ロジック９００は、（例えば、図１１において観察され得るものなどの）ＧＵＩＤをそれぞれが有し得る１つ又は複数の軌道セグメントを含む軌道チャートをレンダリングすることができる。次いで、制御ロジック９００は、ステップ９０８に進んでいる。

【0207】

ステップ９０８において、制御ロジック９００は、時間により、列車イベント及びトン数を軌道セグメントに関連付けることができる。例えば、制御ロジック９００は、列車イベント及びトン数を特定の軌道セグメントと関連付けられ得る特定のＧＵＩＤに関連付けることができる。次いで、制御ロジック９００は、ステップ９１０に進んでいる。

【0208】

ステップ９１２において、制御ロジック９００は、ＧＲＩＴから圧縮減速命令を読み取ることができる。次いで、制御ロジック９００は、ステップ９１４及びステップ９２２に進んでいる。

【0209】

ステップ９２２において、制御ロジック９００は、初期通知が制御ロジック９００によって生成された以降に特定の時間量が経過した場合に、ディスパッチャに通知することができる。例えば、制御ロジック９００は、電子メールをディスパッチャに送信することができる。次いで、制御ロジック９００は、上述のステップの任意のものを終了又は反復することができる。

【0210】

ステップ９１４において、制御ロジック９００は、ステップ９１２において読み取られたこのような圧縮減速命令をエンタープライズ資産管理（ＥＡＭ）システム及び／又は（例えば、当技術分野において既知のものなどの）解決策又は土地及び海岸線管理計画（ＬＳＭＰ）場所などのための（例えば、当技術分野において既知のものなどの）特定の鉄道インフラストラクチャ場所とマッチングさせることができる。次いで、制御ロジック９００は、ステップ９１０に進んでいる。

【0211】

ステップ９１０において、制御ロジック９００は、関連するＧＵＩＤＳを有する軌道セグメントなどのすべての軌道セグメントのトン数及び列車カウントを合計することができる。次いで、制御ロジック９００は、ステップ９１６に進んでいる。

【0212】

ステップ９１６において、制御ロジック９００は、最低軌道セグメントトン数が力閾値を超過しているかどうかをチェックすることができる。例えば、制御ロジック９００は、最低ＧＵＩＤＳトン数が１０００００トンなどの力閾値を充足又は超過しているかどうかをチェックすることができる。次いで、制御ロジック９００は、ステップ９１８及び９２０に進んでいる。

【0213】

ステップ９１８において、制御ロジック９００は、エンジニアリングフィールドに対する通知を生成することができる。例えば、制御ロジック９００は、エンジニアリングフィールドに対する電子メールを生成することができる。別の例において、制御ロジック９００は、最低軌道セグメントトン数が力閾値を超過している場合に減速命令が解除され得るように、エンジニアリングフィールドに通知することができる。次いで、制御ロジック９００は、上述のステップの任意のものを終了又は反復することができる。

【0214】

ステップ９２０において、制御ロジック９００は、ＲＡＤＡＲアラートのためにアプリケーションプログラミングインターフェイス（ＡＰＩ）を呼び出すことできる。次いで、制御ロジック９００は、上述のステップの任意のものを終了又は反復することができる。

【0215】

図１０は、本開示の一実施形態のブロック図を示している。一実施形態において、本明細書において開示されている且つ力、時間閾値、力閾値、イベント、などをトラッキングするように構成されたシステム及びモジュールは、第１時間閾値の充足に基づいて指令を破棄することができる。別の実施形態において、本明細書において開示されているシステム及びモジュールは、第２時間閾値の充足の際にこのような指令を再発令することができる。別の実施形態において、第１時間閾値の充足と第２時間閾値の充足の間の時間において、本明細書において開示されているシステム及びモジュールは、第２時間閾値の充足の際に新しい指令が必要とされるかどうかを本明細書において開示されているシステム及びモジュールが判定し得るように、１つ又は複数のレールセグメントに跨って力のトラッキングを継続するように構成することができる。１０００は、軌道セグメント上の力をトラッキングする第１の方法のブロック図を描いている。例えば、第１指令である指令１Ａが、発令され得ると共に、それぞれの列車イベント（例えば、重量を有する且つ指令と関連するセグメントを移動する列車）によって増分され得る力合計を含むことができる。別の例においては、時点Ａ（第１時間閾値の充足）において、指令１Ａは、指令が特定のガイドラインが軌道の特定の長さとの関係において発布されるようにもはや能動的にしないように、破棄することができる。一実施形態においては、「ゴースト指令」を発令することができる。例えば、ゴースト指令は、指令１Ａからの力合計を含む指令であり得るが、ゴースト指令が鉄道の運行に影響しないように、自身と関連付けられた有効なガイドラインを有してはいない。別の実施形態において、ゴースト指令は、指令１Ａとは異なり得るガイドラインなどのガイドラインを含むことができる。別の実施形態においては、時点Ｂ（例えば、第２時間閾値の充足）において、指令１Ａ及びゴースト指令によってトラッキングされている力合計が力閾値を充足していないなどの場合には、指令１Ｂを発令することができる。

【0216】

１００２は、軌道セグメント上の力をトラッキングする第２方法のブロック図を描いている。例えば、第１指令である指令１Ａは、軌道の特定の長さとの関係において鉄道に対する特定の命令を発布するために発令することができる。一実施形態において、「ゴースト指令」は、指令１Ａと同時に発令されることが可能であり、且つ、それぞれの列車イベント（例えば、重量を有する且つ指令と関連するセグメント上を移動している列車）によって増分され得る力合計を含むことができる。別の例においては、時点Ａ（例えば、第１時間閾値の充足）において、指令１Ａは、指令が軌道の特定の長さとの関係において特定のガイドラインが発布されるようにもはや能動的にしないように、破棄することができる。一実施形態において、ゴースト指令は、有効な指令１Ａの際に且つ破棄の後に、合計力を継続的にトラッキングすることができる。別の実施形態において、時点Ｂ（例えば、第２時間閾値の充足）において、ゴースト指令によってトラッキングされている力合計が力閾値を充足していないなどの場合に、指令１Ｂを発令することができる。別の実施形態において、ゴースト指令は、合計力が力閾値にいまだ到達していない場合に指令１Ｂが有効になった際／場合に、合計力のトラッキングを継続するこができる。別の実施形態において、ゴースト指令は、指令１Ａ及び／又は指令１Ｂとは異なり得るガイドラインなどのガイドラインを含むことができる。

【0217】

１００４は、軌道セグメント上の力をトラッキングする第３方法のブロック図を描いている。例えば、第１制限（例えば、速度制限）が、発令されることが可能であり、且つ、それぞれの列車イベント（例えば、重量を有する且つ指令と関連するセグメント上を移動している列車）によって増分され得る力合計を含むことができる。別の例において、時点Ａ（例えば、第１時間閾値の充足）において、第１制限は、第１制限がもはや軌道の特定の部分上において例えば速度を制限しないように、解除することができる。一実施形態において、制限は、解除されることが可能であり、且つ、力合計は、第１制限などとの関係においてそのトラッキングを継続することができる。別の実施形態において、時点Ｂ（例えば、第２時間閾値の充足）において、第１指令によってトラッキングされる力合計が力閾値を充足していないなどの場合に、第２制限を発令することができる。

【0218】

図１１は、本開示の別の実施形態を描いている。指令管理軌道チャート１１００は、鉄道軌道１１１０のレンダリングを含むことができる。一実施形態において、軌道チャート１１００は、１つ又は複数の軌道セグメント１１０４を含むことができる。別の実施形態において、それぞれの軌道セグメントは、自身と関連するセグメント固有の情報１１０６を含むことができる。一例において、それぞれのセグメント１１０４と関連する情報１１０６は、識別番号（例えば、「ＧＵＩＤ」）、そのセグメント上において判定された且つ／又はセグメントに印加されている最後の力（例えば、「トン数」）、及び／又はそのセグメント上に存在していた且つ／又は現時点においてセグメント上に存在している最後の列車に関係する車両識別情報（例えば、「ロコ」）を含むことができる。別の実施形態において、それぞれのセグメント１１０４は、合計力カウント（例えば、「合計トン数」）を含むことができる。例えば、それぞれのセグメント１１０４の合計力カウントは、力が軌道に印加されるのに伴って変化し得る。例えば、車両６３４２がセグメント５４６１０４上において移動するのに伴って、且つ、車両６３４２が２６１２のトン数を含む場合に、セグメント５４６１０４の合計力カウントは、２７３４５に到達するように、２６１２だけ含むことができる。別の実施形態において、セグメント５４６３０１は、車両６３４２がその上を通過するのに伴ってセグメント５４６３０１の合計力カントが２６１２（車両６３４２のトン数）に増大し得るように、車両６３４２がこれを横断する前にゼロの合計力カウントを有することができる。

【0219】

別の例において、軌道チャート１１００は、例えば、トレーシングモジュール１３０との関係において記述されているものと同様に、本開示のトレーシング能力を例示することができる。例えば、軌道チャート１１００内のセグメント１１０４のそれぞれは、自身の上部を車両が移動したかどうか又は現時点において車両をホスティングしているかどうかを通知することができる。一実施形態において、このような情報は、色による強調などを介して、軌道チャート１１００によって反映することができる。例えば、車両の存在を報告する軌道セグメント１１０４は、相対的に明るい色であることが可能であり、且つ、沈黙している且つ／又は車両の存在を報告していない軌道セグメント１１０４は、相対的に暗い色であり得る。一実施形態において、本開示によるシステム及びモジュールは、車両経路１１０２をトレーシングするために軌道セグメント１１０４を利用することができる。図１１によって示されている特定の例においては、軌道セグメント５４６１０４は、車両の存在を報告することが可能であり、これは、このようなセグメントの相対的に明るい色によって強調することができる。但し、セグメント５４６１０４に直接的に隣接する軌道セグメントは、この例においては、いずれも、車両の存在を報告してはいない。但し、セグメント５４６３０１は、相対的に明るい色によって通知されるように、車両の存在を報告している。一実施形態において、本開示によるシステム及びモジュールは、例えば、軌道電流の不規則性、障害を有するセンサ、などに起因した一貫性を有していないセグメント１１０４の報告などにも拘らず、車両経路１１０２をトレーシングするために、このようなデータポイントを利用することができる。

【0220】

本開示は、少なくとも以下の利点を実現している。
１．指令との関係において力及び／又はイベントをトラッキングすることによってレールスループットを極大化させている。
２．１つ又は複数の閾値に対する個人化された比較によってセグメント固有のデータ収集及び集計を可能にすることにより、安全性を改善している。
３．列車イベントとの関係において収集されたマスデータを利用する指令管理用のシステム及び方法を提供している。
４．セグメントごとに合計力、環境状態、及び特定のイベントを考慮することにより、圧縮トラッキングを改善している。
５．アルゴリズム的なクラスタ閾値処理に応答した自動指令変更を介して効率性を極大化させている。

【0221】

当業者は、本システムのこれらの利点（のみならず、本明細書において示されている利点）及び目的は、本発明のシステムにおいて組み立てられている且つ本明細書において記述されているコンピュータハードウェア及びその他の構造的コンポーネント及びメカニズムの特定の組合せを伴うことなしには不可能となるであろうことを容易に理解するであろう。当業者には既知の様々なプログラミングツールが、以上において記述されている特徴及び動作の制御を実装するために利用可能であることを更に理解されたい。更には、１つ又は複数のプログラミングツールの特定の選択肢は、本明細書及び添付の請求項において記述されている概念を実現するために選択される実装計画に課される特定の目的及び制約によって決定され得る。

【0222】

本特許文献における説明は、任意の特定の要素、ステップ、又は機能が、請求項範囲に含まれなければならない不可欠な又は重要な要素であり得ることを意味するものとして解釈してはならない。また、請求項は、いずれも、機能を識別する分詞句によって後続された状態において「ｍｅａｎｓ ｆｏｒ」又は「ｓｔｅｐ ｆｏｒ」という正確な用語が特定の請求項において明示的に使用されていない限り、添付の請求項又は請求項要素の任意のものとの関係において米国特許法第１１２（ｆ）条を発動させるものと解釈することはできない。請求項における「メカニズム」、「モジュール」、「装置（ｄｅｖｉｃｅ）」、「ユニット」、「コンポーネント」、「要素」、「部材」、「装置（ａｐｐａｒａｔｕｓ）」、「機械」、「システム」、「プロセッサ」、「処理装置」、又は「コントローラ」などの（但し、これらに限定されない）用語の使用は、請求項自体の特徴によって更に変更又は改善される当業者には既知の構造を意味するものとして理解及び解釈することが可能であり、且つ、米国特許法第１１２（ｆ）条を発動させるものと解釈することはできない。

【0223】

本開示は、その精神又は不可欠な特性を逸脱することなしに、その他の特定の形態において実施することができる。例えば、本明細書において記述されている新しい構造のそれぞれは、互いとの間のその基本的構成又は構造的関係性を保持しつつ、或いは、本明細書において記述されている同一又は類似の機能を実行しつつ、特定の局所的な変形又は要件に適するように変更することができる。従って、本実施形態は、限定ではなく、例示を目的としたものとして、すべての側面において見なすことを要する。従って、本発明の範囲は、以上の説明によってはなく、添付の請求項によって確立することができる。従って、請求項の均等性の意味及び範囲に含まれるすべての変更は、請求項の範囲に含まれるものとして解釈されたい。更には、請求項の個々の要素は、周知のものではなく、ありきたりのものでもなく、或いは、旧来のものでもない。その代わりに、請求項は、本明細書において記述されている独創的な発明概念を対象としている。

【図1】

【図2】

【図3A】

【図3B】

【図3C】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【国際調査報告】