JP2018101253A - 情報共有指令卓、及び情報共有指令プログラム - Google Patents

Abstract

【課題】共有した情報に基づいて指令を出す。【解決手段】情報共有司令卓が、所定の事態が起きた場合に、複数の指令システムのそれぞれから前記所定の事態に関連する情報を取得する通信手段と、前記取得した情報に基づいて、前記所定の事態を収束するための手順を特定し、該特定した手順を実行するための指令を前記複数の指令システムに対して出力する制御手段と、を備える。【選択図】図４

Description

本発明は、共有した情報を利用して指令を出すための、情報共有指令卓、及び情報共有指令プログラムに関する。

鉄道の列車運行の安全確保や乱れた運行の正常化を遂行する場面で用いる指令システムに於いて、災害・事件・事故が発生した場合に、自組織内からの通報連絡と他の関係部門からの通報連絡を基に速やかに原因を特定して対策を検討し原因を解消することが求められている。

ここで、一般的な指令システムの構成例について図１を参照して説明をする。図１を参照すると、一般的な指令システム群１０００は、輸送指令システム１０１０、旅客指令システム１０２０、運用指令システム１０３０、電力指令システム１０４０、信号通信指令システム１０５０、及び施設指令システム１０６０を備える。また、各指令システムは、指令員が利用する指令卓（司令卓１０１１〜司令卓１０６１）と、指令を出すために用いる各種の情報を格納するデータベース（データベース１０１２〜データベース１０６２）とを備えている。

ここで、各指令システムの具体的な内容については、例えば、非特許文献１に記載がある。そこで、ここでは各指令システムの詳細な説明は省略し、各指令システムの概略について説明をする。

輸送指令システム１０１０は、列車の運行に直接携わる指令システムであり、例えば駅や管下の列車集中制御装置（ＣＴＣ：Centralized Traffic Control）や、以下に説明する各指令システムから取得した情報に基づいて、列車を正確に運行するための指令を出す。
旅客指令システム１０２０は、列車の接続手配や乗客の忘れ物の検索手配など、乗客からの問い合わせなどに対応する。
運用指令システム１０３０は、車両や乗務員の運用を監視・把握する。
電力指令システム１０４０は、変電所の動作や、鉄道関係施設への給電状況を常時監視する。
信号通信指令システム１０５０は、鉄道信号機や列車無線といった信号機器や通信施設の状態を常時監視する
施設指令システム１０６０は、線路や沿線施設、沿線の気象状態を常時監視している。

そして、これらの各指令システムは、異常事態が発生した場合に、それぞれ単独で、あるいは他の指令システムと連携して、異常事態を収束するための指令を出す。このように一般的な指令システム群１０００では、指令の目的ごとに、指令システムを複数備えているのが一般的である。すなわち、指令の目的ごとに、ハードウェアが分かれているのが一般的である。

また、一般的な指令システム群１０００は、自身が備える各指令システム内で取得された情報に基づいて動作するのみならず、外部の関係機関から提供された情報に基づいた動作も行う。

例えば、図２に示すように火事や地震といった災害や事故の発生時に、災害の発生を発見した発見者が消防署に対して電話にて通報連絡を行ったとする。

この場合に、通報連絡を受けた消防署では、消防車等に消防署員を搭乗させて災害現場に赴かせる。これと共に、消防署では、現在発生している災害に基づいた被害が拡大しないように、列車運行用の一般的な指令システム群１０００に対しても災害の発生を通知する。

災害の発生を通知された一般的な指令システム群１０００では、災害の発生を旅客にアナウンスしたり、災害現場近くでの列車の運行を取りやめたりする。このように、外部の関係機関から提供された情報を利用することにより、列車をより適切に運行することが可能となる。
このような指令システムに関する技術の一例が、特許文献１や特許文献２に記載されている。

例えば、特許文献１には、輸送指令システム等に於いて、事故が発生した場合に、運転再開の見込みについてできるだけ正確かつ的確な情報を社員や列車利用者に提供するための技術が記載されている。

また、特許文献２には、電力指令システムと作業現場との間の電話連絡により鉄道設備の現地作業を管理する作業管理システムに於いて、作業内容の確認や指示を行うオペレータの負担を軽減するための技術が記載されている。

特開２０１６−１１３０２８号公報 特開２００２−０３２１０１号公報

"運転指令所"、［online］、［平成２８年９月３０日検索］、インターネット＜URL:https://ja.wikipedia.org/wiki/%E9%81%8B%E8%BB%A2%E6%8C%87%E4%BB%A4%E6%89%80＞

しかしながら、上述したような一般的な指令システム群１０００には、実際の運用に於いて以下のような複数の問題があった。以下、この問題点について説明をする。

上述したように、一般的な指令システム群１０００には、ハードウェアが異なる複数の指令システムが含まれている。そのため、この独立した専用の指令システムを個々に操作する必要が有り、高いハード的な専門性が必要になる問題があった。

より具体的には、各指令員が、個々の指令システムのハードウェア構成を理解していないという問題があった。そして、それぞれ独自操作が必要になる手順は何度も朱書きされた手順書を読んでも理解できないと云う問題もあった。更に指令システムが、個々に分かれているので、各指令システム間で同期が取れないという問題もあった。

また、個々の指令システムは、列車の正常運行を維持するため指令室に格納され、厳重なセキュリティで守られている。しかし個々の指令システムは、災害・事件・事故などが指令室で起きて、指令室が使えなくなると指令業務が滞ってしまう問題もあった。

例えば、それぞれの指令システムと、この指令システムを制御するための指令卓が電源線や信号線などのケーブルで繋がれていて、ケーブルを外すと全く機能することが出来なかった、また、指令卓が据え付け式で指令室にボルトで固定されているため、災害時など指令室で執務が行えない時に指令卓を指令室の外に持ち出すことが出来ないという問題もあった。

他方、このようなもっぱらハード面に起因する問題のみならず、ソフト面に起因する問題もあった。例えば、個々の指令システムの担当者しか情報の正しい意味や重要度が判らないため、ソフト的な高い専門性が必要だったと云う問題があった。

具体的には、データ信号の通信により各指令システム間で、情報の共有が出来るようになっても、そもそも個々の指令システムで用語には同音異義語が多く意味やその重要度の尺度が揃っていないので、個々の指令システムの担当者しか情報の正しい意味や重要度が判らなかった。つまり、システム連係させるために、意味や重要度を揃える必要があった。

また、過去の似たような事例についての履歴情報が直ぐに検索できないという問題もあった。この点について図３を参照して説明をする。

図３には、各指令システムのデータベースに格納される格納データ（格納データ１０１３〜格納データ１０６３）と、各指令システムにて管理されている文書化された報告書（文書化された報告書１０１４〜文書化された報告書１０６４）を図示する。

例えば、輸送指令システム１０１０を例に取ると、データベースには、格納データ１０１３として「現在状況」を示すデータと「プログラムログ」とが格納されている。また、文書化された報告書には、過去の事象について、事象が発生した「対象地区」、時系列に沿って記憶された「時系列情報」、事象が発生した際の「旅客状況」及び事象が発生した際の「列車状況」などが記載されている。この文書化された報告書は、例えば紙媒体に記載され、ファイリング等されて管理されている。

このような状況下で、指令員は、図３の左側に記載の目的１１００として記載されている、対象地区等の情報を採取しようとする。
この場合に、各指令システムが備える指令卓を用いて、その指令システムのデータベースを参照することにより、上述したような格納データは採取できる。しかし、データベース内には過去の似たような災害・事件・事故の電子化された履歴情報などの蓄積が無く、保存されている文書化された報告書を検索するにしても、なかなか該当する過去の類似している事例を探し当てられない問題があった。この問題は、他の指令システムでも同様で、災害・事件・事故が実際に起こっても、参照できる履歴情報が直ぐに検索できない問題があり、更に、対策案を策定しても妥当性の評価が出来ないと云う問題があった。

そのため、災害・事件・事故に対応するための手順や、その手順を実現するための具体的な手段への分解については、図中に手段化１１２０として図示しているようにベテランが自らの経験やスキルを基に目的から手段に分解していた。また、各手段を実行する指令員は個々のシステムのみを操作していた。そのため、個々のシステムに対応した複数の指令員と、手段に分解することができるベテランとが揃わなくては、災害・事件・事故に適切に対応することが困難であった。そして、このような複数の指令員と、ベテランとが揃わない場合には、例えば、運行ダイヤが乱れたときの列車の運行立て直しにて、立てる対策のどの対策の適用がふさわしいのか分からないと云う問題があった。

具体的には、各駅に停車している列車の行先の変更する必要性の有無や、運行間隔の調整を行う必要性の有無や、列車の増便や減便を行う必要性の有無について適切に決定できなかった。他にも、ホームに入れる旅客の入場制限などの誘導や、ホームに入れない旅客の待機場所の確保や案内などをどのように行うのか等を迅速に判断することが困難であった。

そこで本発明は、共有した情報に基づいて指令を出すための、情報共有指令卓、及び情報共有指令プログラムを提供することを目的とする。

本発明の第１の観点によれば、所定の事態が起きた場合に、複数の指令システムのそれぞれから前記所定の事態に関連する情報を取得する通信手段と、前記取得した情報に基づいて、前記所定の事態を収束するための手順を特定し、該特定した手順を実行するための指令を前記複数の指令システムに対して出力する制御手段と、を備えることを特徴とする情報共有司令卓が提供される。

また、本発明の第２の観点によれば、コンピュータを情報共有司令卓として機能させるための情報共有司令プログラムであって、所定の事態が起きた場合に、複数の指令システムのそれぞれから前記所定の事態に関連する情報を取得する通信手段と、前記取得した情報に基づいて、前記所定の事態を収束するための手順を特定し、該特定した手順を実行するための指令を前記複数の指令システムに対して出力する制御手段と、を備える情報共有司令卓としてコンピュータを機能させることを特徴とする情報共有司令プログラムが提供される。

本発明によれば、共有した情報に基づいて指令を出すことが可能となる。

一般的な指令システム群の構成を示すブロック図である。 一般的な指令システム群と外部からの通報について示すブロック図である。 一般的な指令システム群が保持する情報を示すブロック図である。 本発明の実施形態の構成を示すブロック図である。 本発明の実施形態における可搬型多機能端末の構成を示すブロック図である。 本発明の実施形態における手段と目的の関係を示すイメージ図である。 本発明の実施形態における原因と事象の関係を示すイメージ図である。 本発明の実施形態が保持する情報を示すブロック図である。 本発明の実施形態における意思決定樹木を示すブロック図（１／３）である。 本発明の実施形態における意思決定樹木を示すブロック図（２／３）である。 本発明の実施形態における意思決定樹木を示すブロック図（３／３）である。 本発明の実施形態におけるモードの切り替えを示すブロック図（１／２）である。 本発明の実施形態におけるモードの切り替えを示すブロック図（２／２）である。 本発明の実施形態における手順化について示すイメージ図である。

次に、本発明の実施形態について図面を参照して詳細に説明する。ここで、本実施形態は、概略、鉄道の列車運行の安全確保や乱れた運行の正常化を遂行する場面で用いる指令システムに於いて、災害・事件・事故が発生した場合に、自組織内からの通報連絡と他の関係部門からの通報連絡を基に速やかに原因を特定して対策を検討し原因を解消する、というものである。

次に、本実施形態全体の基本的構成について図４を参照して説明をする。図４に示すように、本実施形態の指令システム群３００は、一般的な指令システム群１０００と同様に複数の指令システムとして、輸送指令システム３１０、旅客指令システム３２０、運用指令システム３３０、電力指令システム３４０、信号通信指令システム３５０、及び施設指令システム３６０を備える。また、各指令システムは、指令員が利用する指令卓（司令卓３１１〜司令卓３６１）と、指令を出すために用いる各種の情報を格納するデータベース（データベース３１２〜データベース３６２）とを備えている。なおこれら複数の指令システムの概略は、上述の一般的な指令システム群１０００に含まれる同名の指令システムと同じであるので詳細な説明を省略する。

また、指令システム群３００には４００を介して可搬型多機能端末１００及びデータベース１５０が接続されている。この接続は、有線接続であってもよいが、その一部又は全部が無線接続であってもよい。

可搬型多機能端末１００には、可搬型多機能端末１００を情報共有指令卓として機能させるためのアプリケーションが組み込まれている。そして、このアプリケーションにより、可搬型多機能端末１００は情報共有司令卓として機能する。具体的には、可搬型多機能端末１００は、指令システム群３００に含まれる複数の指令システムそれぞれと通信を行うことにより、指令システム群３００に含まれる複数の指令システムそれぞれを操作して指令を出す。そのために、可搬型多機能端末１００には、指令システム群３００に含まれる複数の指令システムそれぞれを操作して指令を出すための使用権である操作権限２００が与えられている。なお、操作権限２００を与えられている可搬型多機能端末１００は、可搬型多機能端末１００の使用モードの管理も行う。使用モードの詳細については図１２や図１３を参照して後述する。

かかる可搬型多機能端末１００の具体的な構成について図５を参照して説明をする。図５を参照すると可搬型多機能端末１００は、通信部１０１、ディスプレイ１０２、ＣＰＵ１０３、操作受付部１０４及び記憶部１０５を含む。

通信部１０１は、４００に接続し、指令システム群３００に含まれる各指令システムやデータベース１５０と通信するための部分である。

ディスプレイ１０２は、ユーザインタフェースや、ユーザに対して提供する各種の情報を表示する装置であり、例えば液晶ディスプレイ等により実現される。ディスプレイ１０２に表示されるユーザインタフェースや各種の情報は、ＣＰＵ１０３により生成される。

ＣＰＵ１０３は、演算処理を行うＣＰＵ（Central Processing Unit）である。ＣＰＵ１０３は、可搬型多機能端末１００を情報共有司令卓として機能させるためのアプリケーションや、その他のプログラムや、各種のデータを記憶部１０５から読み込み、これらを用いた演算処理を行うことにより制御部として機能する。

操作受付部１０４はユーザからの操作を受け付けるための部分であり、例えばキーボードやマウスにより実現される。操作受付部１０４が受け付けた操作の内容は、ＣＰＵ１０３に対して通知される。可搬型多機能端末１００を利用する指令員は、ディスプレイ１０２に表示された内容を確認して、選択操作等の操作を行う。
なお、ディスプレイ１０２と、操作受付部１０４とをタッチパネルにより一体として実現するようにしてもよい。

記憶部１０５は、ＣＰＵ１０３が利用する各種のデータを格納する装置である。記憶部１０５は、例えば、ＯＳ（Operating System）や、可搬型多機能端末１００を情報共有司令卓として機能させるためのアプリケーションや、その他の各種の制御用プログラムを格納したＲＯＭ（Read Only Memory）と、ＣＰＵがプログラムを実行する上で一時的に必要とされるデータを格納するためのＲＡＭ（Random Access Memory）とにより実現される。

そして、ＣＰＵ１０３がＲＯＭかアプリケーションやＯＳを読み込み、読み込んだアプリケーションやＯＳをＲＡＭに展開させながら、これらのアプリケーションやＯＳに基づいた演算処理を行なう。そして、演算結果に基づいてディスプレイ１０２や操作受付部１０４を含む各種のハードウェアを制御することにより、本実施形態の機能は実現される。つまり、本実施形態は、ハードウェアとソフトウェアが協働することにより実現することができる。そして、このようにして実現された本実施形態により、以下で説明する各処理が行われる。

なお、可搬型多機能端末１００のハードウェアは、例えば、タブレット型の情報端末や、ノート型のパーソナルコンピュータにより実現することができる

データベース１５０は、可搬型多機能端末１００が使用するデータを格納するためのデータベースである。データベース１５０には後述の処理により生成された履歴情報や、手順化された指令の情報が格納される。また、記憶部１０５が記憶していると説明した情報の一部又は全部がデータベース１５０に格納されるようにしてもよい。
以上、本実施形態の構成について説明をした。次に、本実施形態と一般的な指令システム群１０００の相違点について以下説明をする。

上述したように、一般的な指令システム１０００では、独立した専用システムを個々に操作する必要が有り高いハード的な専門性が必要になる問題があった。

より具体的には、指令の目的ごとハードウェアが分かれていたので、各指令員が、個々の指令システムのハードウェア構成を理解していないという問題があった。そして、それぞれ独自操作が必要になる手順は何度も朱書きされた手順書を読んでも理解できないと云う問題もあった。更に指令システムが、個々に分かれているので、各指令システム間で同期が取れないという問題もあった。

また、個々の指令システムは、列車の正常運行を維持するため指令室に格納され、厳重なセキュリティで守られている。しかし個々の指令システムは、災害・事件・事故などが指令室で起きて、指令室が使えなくなると指令業務が滞ってしまう問題もあった。

例えば、それぞれの指令システムと、この指令システムを制御するための指令卓が電源線や信号線などのケーブルで繋がれていて、ケーブルを外すと全く機能することが出来なかった、また、指令卓が据え付け式で指令室にボルトで固定されているため、災害時など指令室で執務が行えない時に指令卓を指令室の外に持ち出すことが出来ないという問題があった。

これらの問題を鑑み、本実施形態では、上述したようにアプリケーションにより可搬型多機能端末１００を情報共有司令卓として機能させると共に、可搬型多機能端末１００に対して操作権限２００を付与することによって、可搬型多機能端末１００に指令システムを構築する。これにより、このアプリケーションが、個々の指令システムをソフト的にデータの通信や共有と云うレイヤで接続するという役割を担うことができる。また、４００に各指令システムをするので、個々の指令システム同士の同期も取れるようになる。更に、４００に繋がる環境下に可搬型多機能端末１００を持ち出し指令業務が遂行できる。

このように、可搬型多機能端末１００に指令システムを構築することによって上述した指令の目的ごとハードウェアが分かれていることに起因する問題を解決することができる。

次に、上述した他の問題点であるソフト面に起因する問題点について説明をする。上述したように、一般的な指令システム群１０００では、個々の指令システムの担当者しか情報の正しい意味や重要度が判らないと云うソフト的な高い専門性が必要だったと云う問題があった。また、そもそも指令システムは個々の指令システムで用語には同音異義語が多く意味やその重要度の尺度が揃っていないので、個々の指令システムの担当者しか情報の正しい意味や重要度が判らなかった。

また、一般的な指令システム群１０００では、現在状況、プログラムログの様なデータは採取できるが、過去の似たような災害・事件・事故の電子化された履歴情報などの蓄積が無く、保存されている文書を検索するにしても、なかなか該当する過去の類似している事例を探し当てられない問題があった。それは他の指令システムでも同様で、災害・事件・事故が実際に起こっても、参照できる履歴情報が直ぐに検索できない問題があり、更に、対策案を策定しても妥当性の評価が出来ないと云う問題があった。

この点、本実施形態では、これらの問題を解決するために、可搬型多機能端末１００により実現される情報共有指令卓によって、各指令システムとのデータ信号の通信や共有が出来るようにする。そして、本実施形態ではこれに加えて、各指令システムを連係させるために、意味や重要度の尺度を揃える処理を行う。

かかる処理の基本的な考え方について、目的と手段の関係を示す図である図６を参照して説明をする。

図６を参照すると、手段１１、手段１２及び目的１３と、これらの関係が図について図示されている。

まず、手段と目的には因果関係が成り立つ。例えば、手段１１と目的１３は因果関係１５が成り立っている。仮に、目的１３との因果関係が見つからない手段であれば、それは手段と考えられたとしても目的１３の本当の手段ではない。

手段と目的の因果関係について具体例により説明する。例えば、現場での指令員同士の待ち合わせを例に取ると、（１）目的１３は駅を集合場所として、（２）手段１１を集合場所に向かう方法を徒歩で移動とすると、この場合、因果関係１５が成り立っている。

更に、（３）手段１２を自転車で移動とすると、駅と云う集合場所に向かう手段は一つではないと云う事を示していることになる。この手段１２は、手段１１から推測することが容易であるため、類推関係１６が成り立っていることとなる。

そして手段１１の徒歩で移動と手段１２の自転車での移動は、それぞれが目的１３を補完する要素であり、お互いに対比関係があることになる。これを図中で、対比関係１４として示す。

このように図６を参照して説明した目的と手段の関係を応用することにより導ける原因と事象の関係について図７を参照して説明する。

図７に示すように、事象２１と事象２２が起こる共通の原因３０はそれぞれ因果関係２５になる。更に事象２２は事象２１から類推できるので類推関係２６になる。また、事象２１と事象２２は、対比関係２４になる。

この原因と事象の関係について具体例により説明する。例えば、ここでも指令員同士の待ち合わせを例に取る。事象２１として待ち合わせ場所に相手が来ないと云う事象が起きている場合に、事象２２は駅の待ち合わせ場所を間違えた事象であるとする。

この場合事象２１として待ち合わせ場所に相手の指令員が来ないのであるから、もしかしたら相手の指令員が待ち合わせ場所にたどり着いていないかもしれない、それは駅の待ち合わせ場所を間違えたからではないか、というように事象２２を類推する事が出来る。これが類推関係２６である。

そして更に事象２１と事象２２とに共通な因果関係２５がある原因３０は、待ち合わせの日時と場所について、お互いに整合の確認を怠ったこととなる。

本実施形態では、図６を参照して上述した目的と手段の関係と、図７を参照して上述した原因と事象の関係を基に、指令員が行おうとする目的から手段化をする。

そのために、図８に示すように各指令システムの格納データ（格納データ３１３〜格納データ３６３）に、履歴情報を格納しておく。そして、可搬型多機能端末１００は、この履歴情報を参照して類似事象を抽出後、データベース１５０に仮想システムの意思決定樹木図として構築して、構築した意思決定樹木図を可搬型多機能端末１００のディスプレイ１０２に表示する。

この点、可搬型多機能端末１００が各指令システムの格納データから現在状況や、履歴情報を検索してきても、不足している情報がある場合が考えられる。しかしこの場合は、図６を参照して上述した目的と手段の関係と、図７を参照して上述した原因と事象の関係における、類推関係１６や類推関係２６と、対比関係１４や対比関係２４と、因果関係１５や因果関係２５によって、不足している情報に対して仮説を立てる事が出来る。

仮説は、例えば指導員が立てることが考えられる。また、立てた仮説が妥当であったか否かの検証も指導員が行うことができる。また、仮説や、その妥当性についての情報を利用した機械学習を可搬型多機能端末１００等のコンピュータで行うことにより、コンピュータにより、仮説を立てるようなことも考えられる。そして、機械学習を継続することにより、適切な仮説をコンピュータによって精度よく立てるようなことも可能となる。

また、他にも図６を参照して上述した目的と手段の関係と、図７を参照して上述した原因と事象の関係を用いて、同音異義語の候補を履歴情報から抽出し、指令員に適切な同音異義語を選択させる。このようにして可搬型多機能端末１００に同音異義語の対応を記憶させることができる。そのため、例えば可搬型多機能端末１００にて類似事象を抽出する場合や、可搬型多機能端末１００にて仮説を立てる場合に、可搬型多機能端末１００は、同音異義語であることを踏まえて処理を行うことができる。また、同様にして異音同義語を記憶させて利用するようにしてもよい。
また、可搬型多機能端末１００が、ブロックチェーン技術などを用いて自ら同音異義語や異音同義語を学習するようにしてもよい。

本実施形態では、このようにして可搬型多機能端末１００が各指令システムで使われている同音異義語の意味を統一したり、異音同義語を区別したりするので、個々の指令システムでのみ通用する用語のため使用できる指令員が限定されてしまう問題を解決することが可能となる。

また、同様にして指令員の選択に基づいて重要度の尺度も学習させるようにするとよい。重要度の尺度は、例えば重要性、緊急性、及び拡大性の３つの観点から決定するようにするとよい。

また、本実施形態の可搬型多機能端末１００では起きている事象に近づけるために、この仮説情報に数学の確立分野の期待値で情報を整える事が出来る。参考までに期待値を求める式である［数式１］は、以下の通りである。

［数式１］
期待値＝確率変数の実現値×発生する確率

ここで、確率変数の実現値は、ある事態が起きたことについての被害規模、対策に必要なコスト等に基づいて算出する。例えば、ある事態が起きたことにより、電車が何時間ぐらい遅れそうかということや、この事象の対策に必要な人材のコスト等により算出する。
発生する確率は、指令システム群３００に含まれる各指令システムに格納されている履歴情報等に基づいて算出する。

次に、期待値の具体的な利用方法について説明をする。図９に意思決定樹木図として示すように、指令員は、例えば災害・事件・事故などの所定の事態が起きたならば、現場状況５１０を基にして、次に用意する意思決定要素５２０を考え決めなければならない。しかしながら、可搬型多機能端末１００等を利用して入手している現場状況５１０だけでは、意思決定要素５２０を考え決めるには情報不足である場合も考えられる。

そのため、可搬型多機能端末１００は、指令システム群３００に含まれる各指令システムそれぞれの履歴情報を参照して、仮想ポイントと期待値を算出し、図１０に意思決定樹木図として示すように仮想ポイント５３０や仮想ポイント５４０を期待値と共に表示する。更に、仮想ポイントに対して参照してきた履歴情報から、仮想ポイント５３０や仮想ポイント５４０に関連した仮想ポイントである、仮想ポイント５３１、仮想ポイント５３２、仮想ポイント５３３、仮想ポイント５５０、仮想ポイント５６０、及び仮想ポイント５７０をシミュレーション結果として表示する。

ここで、図１０の例において、仮想ポイントは、各指令システムに対して指令を出すことにより収束すべき事態を仮想的なポイントとして表したものである。期待値は仮想ポイントとした事態に対応する期待値である。また、図１１の例は、それぞれ異なる駅において起きている事態についての仮想ポイントを、それぞれの駅の場所に対応して配置した意思決定樹木図である。

このようにして、上述した不足している情報も期待値で整えてはいるものの、やはり仮説である。
そこで本実施形態では、この仮説の精度を高めるために、シミュレーションを行い検証しながら仮説の精度を上げる。

具体的には、図１２及び図１３に示すように、可搬型多機能端末１００は自身の動作するモードをソフト的に切り替えることにより、本番モードＭ１、検証モードＭ２、教育モードＭ３使って、シミュレーションを行い検証しながら仮説の精度を上げる事が出来る。

ここで、本番モードＭ１は、実際に災害・事件・事故などの所定の事態が起きた場合に使用するモードである。また、検証モードＭ２や教育モードＭ３は、検証や教育を目的として実際に災害・事件・事故などの所定の事態が起きたと仮定してシミュレーションを行うモードである。

なお、本番モードＭ１においても実際に災害・事件・事故などの所定の事態が起きたと仮定してシミュレーションを行い、シミュレーション結果に基づいて指令システムに指令を出すことにより、訓練を実行するようにしてもよい。

例えば、本番モードＭ１で指令員８１２が本実施形態を利用することで得た履歴情報８１０を、検証モードＭ２で検証員８２２が実施形態を利用することで検証してフィードバック情報８２０を得る。そして、このフィードバック情報８２０と本実施形態を利用することで、教育モードＭ３で教育受講者に対して、情報の収集の仕方、不足している情報の仮説と期待値による補正の仕方などを伝え、過去の事例を用いた対応対策の訓練を行うことが出来る。このような訓練を受けた教育受講者は訓練結果８３０を得て、指令員８１２として本番モードＭ１で本実施形態を利用する。これにより、仮説の精度を上げる事が出来る。なお、検証員８２２や、教育受講者８３２を教育する教育者には、例えばベテランの指令員がなる。

なお、このようなモードの切り替えを繰り返す過程において得られた、履歴情報８１０（なぜその対策を用意したのかの経緯やノウハウを含む）や、フィードバック情報８２０や、その他の収集した情報、仮説を基に期待値で補正した情報、図１４を参照して後述する指令の手順化で作成した情報などを、可搬型多機能端末１００はデータベース１５０に蓄積していく。

そして、可搬型多機能端末１００は、データベース１５０に蓄積する際に、既に蓄積してある各種情報に対して、図６を参照して上述した目的と手段の関係と、図７を参照して上述した原因と事象の関係を基に、情報を継ぎ足し豊富な知識へと成長（ブロックチェーン化を行う）させていく。そして、このようにして得られた履歴情報も、本番モードＭ１で利用することにより、以後の指令業務に活用して役立てていく。

更に、このようなモードの切り替えを繰り返す過程において、本番や訓練で立てた仮説がどれほどの影響があるのか、立案した対策が実施できるのか、効果などを、シミュレーションで検証する事が出来る。

この点について具体例に基づいて説明をする。例えば、運行ダイヤが乱れたときの列車の運行立て直しでは、立てる対策として、どの対策の適用がふさわしいのか分からないと云う問題があった。

例としては「各駅に停車している列車の行先を変更する必要性の有無」、「運行間隔の調整の有無」、「列車の増便や減便の有無」、「ホームに入れる旅客の入場制限などの誘導」、「ホームに入れない旅客の待機場所の確保や案内」などについて、どの対策の適用がふさわしいのか分からないと云う問題があった。

そこで行うシミュレーションの方法は、図１４に指令７００−１、指令７００−２・・・指令７００−３の手順化として示すように、目的＝やりたいこととして定義して、手段１、手段２、手段３・・・手段ｈと云う具合に順次や同時に起動する計画を手順化（スケジュール化）することにより行う。手順化は、可搬型多機能端末１００が各指令システムの履歴情報を参照して、同一又は類似する目的に対応する過去の手順を参照したり、データベース１５０に蓄積されている履歴情報等を参照したりすることにより行う。

次にここで手順化した計画を、図１０に示すように、現場状況５１０（開始）から完了までの、仮想ポイント５３２、仮想ポイント５３３、仮想ポイント５６０、及び仮想ポイント５７０まで同期を取ったり、必要なリソースが使えたり使えなかったりをシミュレーションする。このシミュレーションを行う時に、上述した［数式１］により算出される期待値を用いて、妥当性を評価する。

具体的には、図１０を参照して説明すると、現場状況５１０から意思決定要素５２０を考える場合、この時点で考えることは現場状況５１０の情報だけでは不足している。そこで、可搬型多機能端末１００は、［数式１］により算出する期待値を用いて状況を数値化して評価判断する事をシミュレーションして指令員を支援する。

例えば図１０に示すように、仮想ポイント５３０の期待値Ｅｘ１＝データベース１５０×０．３＝４５と仮想ポイント５４０の期待値Ｅｘ２＝９０×０．７＝６３だったとすると期待値が高い値となった仮想ポイント５４０を選択したほうが好い事が支援されている。なお、本説明では、仮想ポイント５３０と仮想ポイント５４０の２つの仮想ポイントに分岐しているが、実際にはこれ以上に分岐していてもよい。例えば、１０以上の仮想ポイントに分岐していてもよい。

続いて、仮想ポイント５５０の期待値Ｅｘ５＝操作権限２００×０．６＝１２０と仮想ポイント５７０の期待値Ｅｘ６＝データベース１５０×０．４＝６０となり、期待値が高い仮想ポイント５５０を選択したほうが好いとシミュレーションして指令員を支援する。

そして仮想ポイント５３０を選択した場合についても更に検証を行い、仮想ポイント５３１から仮想ポイント５３２の期待値Ｅｘ３＝２０×０．７＝１４、仮想ポイント５３３の期待値Ｅｘ４＝４０×０．３＝１２となり、仮想ポイント５５０を選択した場合が期待値Ｅｘ５＝１２０でよりベターな選択となる事をシミュレーションして指令員を支援する事が出来る。

更に、図１１に示すような列車運行のシミュレーションを、検証モードＭ２にて行うことが出来る。

このシミュレーションを行う時に、上述した［数式１］により算出される期待値を用いて、妥当性を評価するという検証を行う。主に検証モードＭ２では、図７を参照して上述した原因と事象の関係を用いて検証を進める。

例えば、列車の運行でブレーキのアラームがヒヤリハットとして起こってしまった場合、事象２１にヒヤリハットを設定して因果関係２５にあたる原因２３をブレーキの摩耗によるアラームと抽出する。これにより、事象３２と原因３から類推関係にあたる潜在的な他の車両でもブレーキの摩耗によるアラームが出る可能性があると云う事象３３を発見し、災害・事件・事故を未然に防ぐ対象リストの抽出や対策などを用意展開する事が出来る。

また、このシミュレーションは、図１２や図１３に示した３つのモードで使用する事が出来る。ここで、操作権限２００を各モードに対応した内容とすることによって、各モードを使い分けることが出来る。

具体的には、本番モードＭ１に対応する操作権限２００で可搬型多機能端末１００を起動すれば指令員８１２としての権限でシステムを使用する事が出来る。

また、検証モードＭ２に対応する操作権限２００で可搬型多機能端末１００を起動すれば検証員８２２としての権限でシステムを使用する事が出来る。

更に、教育モードＭ３に対応する操作権限２００で可搬型多機能端末１００を起動すれば教育受講者８３２としての権限でシステムを使用する事が出来る。

更に、収集できない情報があっても履歴情報を基に仮説を立てシミュレーションして期待値で補正する事で仮説の精度を高め、シミュレーションで検証した指令を実システム上で実行する事ができる。このシミュレーションを繰り返し実施すれば、データベース１５０に情報を蓄積し、可搬型多機能端末１００は、ブロックチェーン技術などを使用し自身で学習して精度を高めることが出来る。

なお、上述の本実施形態に含まれる各機器のそれぞれは、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。また、上記の本実施形態に含まれる各機器により行なわれる情報共有司令方法も、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。

プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ(Read Only Memory)、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ(Programmable ROM)、ＥＰＲＯＭ(Erasable PROM)、フラッシュＲＯＭ、ＲＡＭ(random access memory）)を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

また、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲に於いて種々の変更を施した形態での実施が可能である。

以上説明した本発明の実施形態は、鉄道の列車運行の安全確保や乱れた運行の正常化を遂行する場面で用いる指令システムに於いて、災害・事件・事故が発生した場合に、自組織内からの通報連絡と他の関係部門からの通報連絡を基に速やかに原因を特定して対策を検討し原因を解消することができる、という効果を奏する。
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１) 所定の事態が起きた場合に、複数の指令システムのそれぞれから前記所定の事態に関連する情報を取得する通信手段と、
前記取得した情報に基づいて、前記所定の事態を収束するための手順を特定し、該特定した手順を実行するための指令を前記複数の指令システムに対して出力する制御手段と、
を備えることを特徴とする情報共有司令卓。

（付記２) 前記手順は、前記所定の事態を収束するための手順に加えて、前記所定の事態が起きたことに関連して起きる他の事態を収束するための手順を含むことを特徴とする付記１に記載の情報共有司令卓。

（付記３) 前記制御手段が、実行すべき指令をユーザに選択させるために、複数の前記指令と、該複数の指令の実行順序とを前記ユーザに対して出力することを特徴とする付記１又は２に記載の情報共有司令卓。

（付記４) 前記ユーザに対して出力するとは、
前記複数の指令を、該複数の指令の実行順序に則して分岐していくツリー状に配置して表示することであることを特徴とする付記３に記載の情報共有司令卓。

（付記５) 前記指令のそれぞれを実行した場合に想定される効果を期待値として更に表示することを特徴とする付記４に記載の情報共有司令卓。

（付記６) 前記取得した情報に加えて、前記取得した情報と対比関係にある情報、前記取得した情報と因果関係にある情報、及び前記取得した情報と類推関係にある情報のそれぞれにも基づいて、前記所定の事態を収束するための手順を特定することを特徴とする付記１乃至５の何れか１項に記載の情報共有司令卓。

（付記７) 前記制御手段が、前記複数の指令システムそれぞれにおいて使用されている用語について、同音異義語の関係にあるのか否か、異音同義語の関係であるのか否か、の少なくとも一方又は双方について学習をし、該学習の学習結果も利用して前記所定の事態を収束するための手順を特定することを特徴とする付記１乃至５の何れか１項に記載の情報共有司令卓。

（付記８) 当該情報共有司令卓は、前記所定の事態が起きたものと仮定して動作するモードを有しており、該モードに遷移した場合に、
前記通信手段は、前記複数の指令システムのそれぞれから前記所定の事態に関連する情報を取得し、
前記制御手段は、前記取得した情報に基づいて、前記所定の事態を収束するための手順を特定し、該特定した手順を実行するための指令を、前記複数の指令システムに出力せずにユーザに対して出力することを特徴とする付記１乃至７の何れか１項に記載の情報共有司令卓。

（付記９) 前記所定の事態が起きたものと仮定して動作するモードと、通常に動作するモードとを切り替えることを繰り返すと共に、
前記繰り返しの過程で、前記制御手段が特定した手順が妥当であったか否かの検証の検証結果を蓄積し、該蓄積した検証結果にも基づいて、前記所定の事態を収束するための手順を特定することを特徴とする付記１乃至８の何れか１項に記載の情報共有司令卓。

（付記１０) コンピュータを情報共有司令卓として機能させるための情報共有司令プログラムであって、
所定の事態が起きた場合に、複数の指令システムのそれぞれから前記所定の事態に関連する情報を取得する通信手段と、
前記取得した情報に基づいて、前記所定の事態を収束するための手順を特定し、該特定した手順を実行するための指令を前記複数の指令システムに対して出力する制御手段と、
を備える情報共有司令卓としてコンピュータを機能させることを特徴とする情報共有司令プログラム。

１００ 可搬型多機能端末
１０１ 通信部
１０２ ディスプレイ
１０３ ＣＰＵ
１０４ 操作受付部
１０５ 記憶部
１１０、１１１０ 目的
１２０、１１２０ 手段化
１５０ データベース
２００ 操作権限
３００ 指令システム群
３１０、１０１０ 輸送指令システム
３１１、３２１、３３１、３４１、３５１、３６１、１０１１、１０２１、１０３１、１０４１、１０５１、１０６１ 司令卓
３１２、３２２、３３２、３４２、３５２、３６２、１０１２、１０２２、１０３２、１０４２、１０５２、１０６２ データベース
３１３、３２３、３３３、３４３、３５３、３６３、１０１３、１０２３、１０３３、１０４３、１０５３、１０６３ 格納データ
３１４、３２４、３３４、３４４、３５４、３６４、１０１４、１０２４、１０３４、１０４４、１０５４、１０６４ 文書化された履歴
３２０、１０２０ 旅客指令システム
３３０、１０３０ 運用指令システム
３４０、１０４０ 電力指令システム
３５０、１０５０ 信号通信指令システム
３６０、１０６０ 施設指令システム
１０００ 一般的な指令システム群

Claims (10)

1. 所定の事態が起きた場合に、複数の指令システムのそれぞれから前記所定の事態に関連する情報を取得する通信手段と、
   前記取得した情報に基づいて、前記所定の事態を収束するための手順を特定し、該特定した手順を実行するための指令を前記複数の指令システムに対して出力する制御手段と、
   を備えることを特徴とする情報共有司令卓。
2. 前記手順は、前記所定の事態を収束するための手順に加えて、前記所定の事態が起きたことに関連して起きる他の事態を収束するための手順を含むことを特徴とする請求項１に記載の情報共有司令卓。
3. 前記制御手段が、実行すべき指令をユーザに選択させるために、複数の前記指令と、該複数の指令の実行順序とを前記ユーザに対して出力することを特徴とする請求項１又は２に記載の情報共有司令卓。
4. 前記ユーザに対して出力するとは、
   前記複数の指令を、該複数の指令の実行順序に則して分岐していくツリー状に配置して表示することであることを特徴とする請求項３に記載の情報共有司令卓。
5. 前記指令のそれぞれを実行した場合に想定される効果を期待値として更に表示することを特徴とする請求項４に記載の情報共有司令卓。
6. 前記取得した情報に加えて、前記取得した情報と対比関係にある情報、前記取得した情報と因果関係にある情報、及び前記取得した情報と類推関係にある情報のそれぞれにも基づいて、前記所定の事態を収束するための手順を特定することを特徴とする請求項１乃至５の何れか１項に記載の情報共有司令卓。
7. 前記制御手段が、前記複数の指令システムそれぞれにおいて使用されている用語について、同音異義語の関係にあるのか否か、異音同義語の関係であるのか否か、の少なくとも一方又は双方について学習をし、該学習の学習結果も利用して前記所定の事態を収束するための手順を特定することを特徴とする請求項１乃至５の何れか１項に記載の情報共有司令卓。
8. 当該情報共有司令卓は、前記所定の事態が起きたものと仮定して動作するモードを有しており、該モードに遷移した場合に、
   前記通信手段は、前記複数の指令システムのそれぞれから前記所定の事態に関連する情報を取得し、
   前記制御手段は、前記取得した情報に基づいて、前記所定の事態を収束するための手順を特定し、該特定した手順を実行するための指令を、前記複数の指令システムに出力せずにユーザに対して出力することを特徴とする請求項１乃至７の何れか１項に記載の情報共有司令卓。
9. 前記所定の事態が起きたものと仮定して動作するモードと、通常に動作するモードとを切り替えることを繰り返すと共に、
   前記繰り返しの過程で、前記制御手段が特定した手順が妥当であったか否かの検証の検証結果を蓄積し、該蓄積した検証結果にも基づいて、前記所定の事態を収束するための手順を特定することを特徴とする請求項１乃至８の何れか１項に記載の情報共有司令卓。
10. コンピュータを情報共有司令卓として機能させるための情報共有司令プログラムであって、
    所定の事態が起きた場合に、複数の指令システムのそれぞれから前記所定の事態に関連する情報を取得する通信手段と、
    前記取得した情報に基づいて、前記所定の事態を収束するための手順を特定し、該特定した手順を実行するための指令を前記複数の指令システムに対して出力する制御手段と、
    を備える情報共有司令卓としてコンピュータを機能させることを特徴とする情報共有司令プログラム。

Images