知財求人 - 知財ポータルサイト「IP Force」
▶ 中田 弦太朗の特許一覧 ▶ 井上 優太の特許一覧 ▶ 森 悠仁の特許一覧 ▶ 南 悠水の特許一覧 ▶ 渡邉 彩星の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024115486
(43)【公開日】2024-08-26
(54)【発明の名称】カメラを用いた列車遅延検出・提供システム
(51)【国際特許分類】
B61L 25/02 20060101AFI20240819BHJP
【ＦＩ】
B61L25/02 Z
【審査請求】有
【請求項の数】1
【出願形態】書面
(21)【出願番号】P 2023033186
(22)【出願日】2023-02-14
(11)【特許番号】
(45)【特許公報発行日】2024-01-04
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＰＹＴＨＯＮ
(71)【出願人】
【識別番号】523077756
【氏名又は名称】中田 弦太朗
(71)【出願人】
【識別番号】523077620
【氏名又は名称】井上 優太
(71)【出願人】
【識別番号】523077767
【氏名又は名称】森 悠仁
(71)【出願人】
【識別番号】523077778
【氏名又は名称】南 悠水
(71)【出願人】
【識別番号】523077789
【氏名又は名称】渡邉 彩星
(72)【発明者】
【氏名】中田 弦太朗
(72)【発明者】
【氏名】井上 優太
(72)【発明者】
【氏名】森 悠仁
(72)【発明者】
【氏名】南 悠水
(72)【発明者】
【氏名】渡邉 彩星
【テーマコード（参考）】
5H161
【Ｆターム（参考）】
5H161AA01
5H161BB01
5H161DD20
5H161FF07
5H161GG01
5H161GG12
5H161GG14
5H161GG15
5H161GG17
5H161GG21
(57)【要約】
【課題】鉄道利用の需要が高いにもかかわらず、遅延情報を速達するシステムが導入されていない路線においても都心の優れたシステムと同等の情報提供の速さで、新規路線への導入が現行のシステムより安価である新しいシステムの開発を目的としている。
【解決手段】カメラで検出した車両の通過時刻と予め調査した通過時刻を比較し、求めた遅延情報をＳＮＳ上で発信するシステムを提供する。
【選択図】図１
【解決手段】カメラで検出した車両の通過時刻と予め調査した通過時刻を比較し、求めた遅延情報をＳＮＳ上で発信するシステムを提供する。
【選択図】図１
【特許請求の範囲】
【請求項1】
カメラを用いた列車遅延を検出および提供するシステムであって、
画像認識部と、時刻照合部と、出力部と、データベースとを備え、
画像認識部は、
カメラで撮像された列車の画像から列車の帯の部分の画像を抽出し、当該抽出された画像を画素の配列と見なし、ＲＧＢで表された各画素を画像処理解析ライブラリを用いてＨＳＶに変換し、変換後の画素に対して二値化し、列車の帯の部分をみたす画素の割合の計算し、画像内の画素の割合が所定の割合を超えたか超えないかによって画像の状態を定義し、
定義された画像の状態が所定の割合を超えた状態から当該所定の割合を超えない状態に遷移した場合、列車の通過として判断し、
時刻照合部は、
時計の時刻を取得し、
計測場所付近の駅の時刻表に、その駅から計測地点までの所要時刻を足したものを計測地点での定刻時刻として、データベースに記憶し、
列車が通過したときに、データベースよりｎ番目（ｎ＝始発の列車カウントを１とする）列車の通過時刻との差を算出し、
データベース内の列車カウント変数ｎに１を足し、
データベースの時間と通過時刻との差を計算し、
差が所定時間以上の場合、遅延していることを伝える出力データのテンプレートを用意し、出力データには現在時刻、計測地点付近の駅の発車時刻、遅延時間を含み、
差が所定時間未満の場合は現在、平常運転ということを伝える出力データのテンプレートを用意し、
出力部は、
用意した出力データを外部のＳＮＳに発信することを特徴とするシステム。
画像認識部と、時刻照合部と、出力部と、データベースとを備え、
画像認識部は、
カメラで撮像された列車の画像から列車の帯の部分の画像を抽出し、当該抽出された画像を画素の配列と見なし、ＲＧＢで表された各画素を画像処理解析ライブラリを用いてＨＳＶに変換し、変換後の画素に対して二値化し、列車の帯の部分をみたす画素の割合の計算し、画像内の画素の割合が所定の割合を超えたか超えないかによって画像の状態を定義し、
定義された画像の状態が所定の割合を超えた状態から当該所定の割合を超えない状態に遷移した場合、列車の通過として判断し、
時刻照合部は、
時計の時刻を取得し、
計測場所付近の駅の時刻表に、その駅から計測地点までの所要時刻を足したものを計測地点での定刻時刻として、データベースに記憶し、
列車が通過したときに、データベースよりｎ番目（ｎ＝始発の列車カウントを１とする）列車の通過時刻との差を算出し、
データベース内の列車カウント変数ｎに１を足し、
データベースの時間と通過時刻との差を計算し、
差が所定時間以上の場合、遅延していることを伝える出力データのテンプレートを用意し、出力データには現在時刻、計測地点付近の駅の発車時刻、遅延時間を含み、
差が所定時間未満の場合は現在、平常運転ということを伝える出力データのテンプレートを用意し、
出力部は、
用意した出力データを外部のＳＮＳに発信することを特徴とするシステム。
【請求項2】
前記画像認識部は、夜間においては、さらに、車両の窓の座標範囲に相当する画素の部分の明度も測定し、当該明度が所定値以上になった時場合で且つ定義された画像の状態が所定の割合を超えた状態から当該所定の割合を超えない状態に遷移した場合、列車が通過したと判断することを特徴とする、請求項１に記載のシステム。
【請求項3】
カメラを用いた列車遅延を検出および提供するためにプロセッサによって実行されるプログラムであって、
カメラで撮像された列車の画像から列車の帯の部分の画像を抽出し、当該抽出された画像を画素の配列と見なし、ＲＧＢで表された各画素を画像処理解析ライブラリを用いてＨＳＶに変換し、変換後の画素に対して二値化し、列車の帯の色をみたす画素の割合の計算し、画像内の画素の割合が所定の割合を超えたか超えないかによって画像の状態を定義し、
定義された画像の状態が所定の割合を超えた状態から所定の割合を超えない状態に遷移した場合、列車の通過として判断し、
時計の時刻を取得し、
計測場所付近の駅の時刻表に、その駅から計測地点までの所要時刻を足したものを計測地点での定刻時刻として、データベースに記憶し、
列車が通過したときに、データベースよりｎ番目（ｎ＝始発の列車カウントを１とする）列車の通過時刻との差を算出し、
データベース内の列車カウント変数ｎに１を足し、
データベースの時間と通過時刻との差を計算し、
差が所定時間以上の場合、遅延していることを伝える出力データのテンプレートを用意し、出力データには現在時刻、計測地点付近の駅の発車時刻、遅延時間を含み、
差が所定時間未満の場合は現在、平常運転ということを伝える出力データのテンプレートを用意し、
用意した出力データを外部のＳＮＳに発信することを特徴とするプログラム。
カメラで撮像された列車の画像から列車の帯の部分の画像を抽出し、当該抽出された画像を画素の配列と見なし、ＲＧＢで表された各画素を画像処理解析ライブラリを用いてＨＳＶに変換し、変換後の画素に対して二値化し、列車の帯の色をみたす画素の割合の計算し、画像内の画素の割合が所定の割合を超えたか超えないかによって画像の状態を定義し、
定義された画像の状態が所定の割合を超えた状態から所定の割合を超えない状態に遷移した場合、列車の通過として判断し、
時計の時刻を取得し、
計測場所付近の駅の時刻表に、その駅から計測地点までの所要時刻を足したものを計測地点での定刻時刻として、データベースに記憶し、
列車が通過したときに、データベースよりｎ番目（ｎ＝始発の列車カウントを１とする）列車の通過時刻との差を算出し、
データベース内の列車カウント変数ｎに１を足し、
データベースの時間と通過時刻との差を計算し、
差が所定時間以上の場合、遅延していることを伝える出力データのテンプレートを用意し、出力データには現在時刻、計測地点付近の駅の発車時刻、遅延時間を含み、
差が所定時間未満の場合は現在、平常運転ということを伝える出力データのテンプレートを用意し、
用意した出力データを外部のＳＮＳに発信することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
カメラを用いた列車遅延検出・提供システム
【0001】
本発明は、カメラを用いた列車遅延検出・提供システムに関する。
【背景技術】
【0002】
鉄道では、毎日絶えず遅延が発生している。その原因は主に人身事故、ドア挟まり、急病人救護、機器トラブルがあり、遅延する時間も小さいものでは数分から大きいものでは数時間遅れることもある。列車の数分の遅延は重なると大きな遅延になり、利用者に大きな影響を与えることもある。そのため遅延が発生した場合には利用者はすぐにその情報を得る必要がある。
首都圏の鉄道（ＪＲ東日本）においては遅延情報を速達するシステム「ＡＴＯＳ（東京圏輸送管理システム）」が既に存在する。しかし、郊外を走る路線の中には鉄道利用の需要が高いにもかかわらずこのシステムが導入されていない路線が複数存在する。その中でも千葉県を走行しているＪＲ外房線ではＡＴＯＳが導入されていないが、２０２１年度の各路線の線区の輸送密度では、全ＪＲ路線３９５線区の中で第１３位に入っている。
また、提供される遅延情報は鉄道会社からのみしか発表されておらず、かつ数分単位での正確な情報提供が行われていない場合が多い。例えばヤフー株式会社が提供している「Ｙａｈｏｏ！路線情報」では、株式会社レスキューナウ（以下レスキューナウ）が配信している遅延情報をもとに遅延情報を利用者に提供している。レスキューナウが配信している情報は、鉄道会社への取材や発表した情報、全国の投稿モニターから得た情報で、鉄道遅延においては「首都圏ＪＲでは１５分以上、それ以外の路線では３０分以上の運行遅延が確認された鉄道路線（区間）の情報」と記されている。
首都圏の鉄道（ＪＲ東日本）においては遅延情報を速達するシステム「ＡＴＯＳ（東京圏輸送管理システム）」が既に存在する。しかし、郊外を走る路線の中には鉄道利用の需要が高いにもかかわらずこのシステムが導入されていない路線が複数存在する。その中でも千葉県を走行しているＪＲ外房線ではＡＴＯＳが導入されていないが、２０２１年度の各路線の線区の輸送密度では、全ＪＲ路線３９５線区の中で第１３位に入っている。
また、提供される遅延情報は鉄道会社からのみしか発表されておらず、かつ数分単位での正確な情報提供が行われていない場合が多い。例えばヤフー株式会社が提供している「Ｙａｈｏｏ！路線情報」では、株式会社レスキューナウ（以下レスキューナウ）が配信している遅延情報をもとに遅延情報を利用者に提供している。レスキューナウが配信している情報は、鉄道会社への取材や発表した情報、全国の投稿モニターから得た情報で、鉄道遅延においては「首都圏ＪＲでは１５分以上、それ以外の路線では３０分以上の運行遅延が確認された鉄道路線（区間）の情報」と記されている。
【0003】
特許文献１（特開２０２１－０７９７４２号公報）では、各列車の遅延情報をそれぞれ比較して影響度を出しているが、本発明では遅延を列車ごとに計算して、各データは独立したものとして扱うという点で違いがある。
特許文献２（特開２０１５－１４７４８１号公報）では、上方のアングルから列車を撮影し、画像を処理しているが、本発明では線路の左方のアングルもしくは右方のアングルから撮影するという点で違いがある。
特許文献３（特開２００３－３１２４７６号公報）では、牽引車、運搬車にそれぞれＩＤタグを設置するという改造を施し、それぞれ車両を検出しているが、本発明では既存の鉄道車両に改造を施すことなく列車を判別できるという点で違いがある。
特許文献２（特開２０１５－１４７４８１号公報）では、上方のアングルから列車を撮影し、画像を処理しているが、本発明では線路の左方のアングルもしくは右方のアングルから撮影するという点で違いがある。
特許文献３（特開２００３－３１２４７６号公報）では、牽引車、運搬車にそれぞれＩＤタグを設置するという改造を施し、それぞれ車両を検出しているが、本発明では既存の鉄道車両に改造を施すことなく列車を判別できるという点で違いがある。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２０２１－０７９７４２号公報
【特許文献2】特開２０１５－１４７４８１号公報
【特許文献3】特開２００３－３１２４７６号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
鉄道利用の需要が高いにもかかわらず遅延情報を速達するシステムが導入されていない路線においても都心の優れたシステムと同等の情報提供の速さで、新規路線への導入が現行のシステムより安価である新しいシステムの開発を目的としている。
【課題を解決するための手段】
【0006】
カメラで検出した車両の通過時刻と予め調査した通過時刻を比較し、求めた遅延情報をＳＮＳ上で発信するシステムを提供する。
【発明の効果】
【0007】
本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。
【図面の簡単な説明】
【0008】
【発明を実施するための形態】
【0009】
＜全体＞
定点にカメラを１つ設置し、カメラが車両を検知すると予め用意した定点における列車の通過時刻を記録したデータベースを参照し、現在時刻と比較することで電車の遅延を算出する。
算出した遅延時間と現在時刻に対応するＪＲ東日本の遅延証明書のリンクをＴｗｉｔｔｅｒ（登録商標）に投稿をする。
全てのプログラムはＰｙｔｈｏｎで作られており、Ｒａｓｐｂｅｒｒｙ Ｐｉ（登録商標）のような小型のコンピュータやプロセッサで動作させる。
定点にカメラを１つ設置し、カメラが車両を検知すると予め用意した定点における列車の通過時刻を記録したデータベースを参照し、現在時刻と比較することで電車の遅延を算出する。
算出した遅延時間と現在時刻に対応するＪＲ東日本の遅延証明書のリンクをＴｗｉｔｔｅｒ（登録商標）に投稿をする。
全てのプログラムはＰｙｔｈｏｎで作られており、Ｒａｓｐｂｅｒｒｙ Ｐｉ（登録商標）のような小型のコンピュータやプロセッサで動作させる。
【0010】
＜車両の検知について＞
基本的な車両の判別方法は、画像内の列車が映る領域をトリミング、色相、明度、彩度に応じて画像にマスクを掛け、特定の色（列車の帯に近い色）だけを残して、それ以外の色のピクセルを全て黒のピクセルで埋める処理をする。
次に、画像の合計のピクセル数から黒のピクセル数を引いて、列車の帯の色に近い色のピクセルの数を数え、一定値を超えた場合に列車の通過と判断する。また、上記の方法では夜間における車両の検出は、太陽光の明るさが失われたため色相情報が保存されないと考えたため、夜間においては車両の窓の座標の画素の明度を測定し、一定値以上になった時に列車が通過したと判断する手法を採用している。
昼間においては、撮影した写真のうち、列車が映る右側と左側（図６の写真内の白枠の部分２箇所）をトリミングし、上記の方法を利用してトリミングしたそれぞれの写真に列車が写っているかを確かめる。写真の状態は▲１▼「左側を検出したが右側は検出しなかった」、▲２▼「左側を検出し右側を検出した」、▲３▼「左側を検出しなかったが右側は検出した」、▲４▼「左側を検出せず、右側も検出しなかった」の４パターンである。撮影した２枚の写真のうち、１枚目の写真の状態が▲１▼、２枚目の写真の状態が▲２▼の場合（図６の状態）の時に、左側から通過したと判断することで、方向を検出することが可能となっている。なお、本実施例で説明している「写真の撮影」とは、「画像の撮像」と同義である。
基本的な車両の判別方法は、画像内の列車が映る領域をトリミング、色相、明度、彩度に応じて画像にマスクを掛け、特定の色（列車の帯に近い色）だけを残して、それ以外の色のピクセルを全て黒のピクセルで埋める処理をする。
次に、画像の合計のピクセル数から黒のピクセル数を引いて、列車の帯の色に近い色のピクセルの数を数え、一定値を超えた場合に列車の通過と判断する。また、上記の方法では夜間における車両の検出は、太陽光の明るさが失われたため色相情報が保存されないと考えたため、夜間においては車両の窓の座標の画素の明度を測定し、一定値以上になった時に列車が通過したと判断する手法を採用している。
昼間においては、撮影した写真のうち、列車が映る右側と左側（図６の写真内の白枠の部分２箇所）をトリミングし、上記の方法を利用してトリミングしたそれぞれの写真に列車が写っているかを確かめる。写真の状態は▲１▼「左側を検出したが右側は検出しなかった」、▲２▼「左側を検出し右側を検出した」、▲３▼「左側を検出しなかったが右側は検出した」、▲４▼「左側を検出せず、右側も検出しなかった」の４パターンである。撮影した２枚の写真のうち、１枚目の写真の状態が▲１▼、２枚目の写真の状態が▲２▼の場合（図６の状態）の時に、左側から通過したと判断することで、方向を検出することが可能となっている。なお、本実施例で説明している「写真の撮影」とは、「画像の撮像」と同義である。
【0011】
＜データベースについて＞
本来の通過時刻を記録したデータベースは、撮影場所を（カメラ設置場所）通過する前に出発した駅、すなわち時刻の基準となる駅から撮影場所までの平均所要時間を算出し、その算出した時間を時刻の基準となる駅の時刻表に足したデータを利用する。
また、毎年３月に行われているダイヤ改正にすぐ対応にするため、ダイヤ改正が行われたら自動でＪＲ東日本のホームページからデータを取得し、データベースの内容を書き換えるプログラムも作成した。これにより、実験場所以外でも簡単に対応することができる。
時刻表は秒数が載っていないため、基準の秒数を３０で統一した上で全てｈｈｍｍｓｓの形とした。（図７）
これは、多くの路線（首都圏の過密路線を除く）において１５秒単位でダイヤグラムが組まれているため、誤差が一番少なくなると予想したためである。
列車をカメラで検出したあとは、始発から数えた通過回数を基準にデータベースを参照し、現在時刻との比較を行うことで遅延を検出する仕組みである。
本来の通過時刻を記録したデータベースは、撮影場所を（カメラ設置場所）通過する前に出発した駅、すなわち時刻の基準となる駅から撮影場所までの平均所要時間を算出し、その算出した時間を時刻の基準となる駅の時刻表に足したデータを利用する。
また、毎年３月に行われているダイヤ改正にすぐ対応にするため、ダイヤ改正が行われたら自動でＪＲ東日本のホームページからデータを取得し、データベースの内容を書き換えるプログラムも作成した。これにより、実験場所以外でも簡単に対応することができる。
時刻表は秒数が載っていないため、基準の秒数を３０で統一した上で全てｈｈｍｍｓｓの形とした。（図７）
これは、多くの路線（首都圏の過密路線を除く）において１５秒単位でダイヤグラムが組まれているため、誤差が一番少なくなると予想したためである。
列車をカメラで検出したあとは、始発から数えた通過回数を基準にデータベースを参照し、現在時刻との比較を行うことで遅延を検出する仕組みである。
【0012】
＜Ｔｗｉｔｔｅｒ（登録商標）について＞
Ｔｗｉｔｔｅｒ（登録商標）には
・列車ごとの個別識別
・カメラの設置場所で通過を検出した時間
・撮影場所の最寄り駅の時刻表の時刻
・列車の種別、及び行き先
・遅延しているかどうか
・電子遅延証明書へのリンク
の六項目の情報を投稿する。（図８）
Ｔｗｉｔｔｅｒ（登録商標）には
・列車ごとの個別識別
・カメラの設置場所で通過を検出した時間
・撮影場所の最寄り駅の時刻表の時刻
・列車の種別、及び行き先
・遅延しているかどうか
・電子遅延証明書へのリンク
の六項目の情報を投稿する。（図８）
【0013】
＜アプリケーションについて＞
現在、このＴｗｉｔｔｅｒ（登録商標）投稿を利用したａｎｄｒｏｉｄアプリケーションを開発している。ＵＩは図９、図１０のようになっており、操作は、路線選択→駅選択→上り下り、平日休日の選択→時刻表から列車の選択→遅延情報表示という流れになっている。これによりＴｗｉｔｔｅｒ（登録商標）で文字を用いて検索を行うのではなく、視覚的に操作ができるようになるので利便性向上を図ることができる。
路線選択のアイコンにはそれぞれの路線の代表的な車両の前面イラストを貼り付けてある。
また、現状中央線のみの対応となっているが他路線も導入した際にはすぐに対応することができる。
現在、このＴｗｉｔｔｅｒ（登録商標）投稿を利用したａｎｄｒｏｉｄアプリケーションを開発している。ＵＩは図９、図１０のようになっており、操作は、路線選択→駅選択→上り下り、平日休日の選択→時刻表から列車の選択→遅延情報表示という流れになっている。これによりＴｗｉｔｔｅｒ（登録商標）で文字を用いて検索を行うのではなく、視覚的に操作ができるようになるので利便性向上を図ることができる。
路線選択のアイコンにはそれぞれの路線の代表的な車両の前面イラストを貼り付けてある。
また、現状中央線のみの対応となっているが他路線も導入した際にはすぐに対応することができる。
【0014】
＜本実施例の効果＞
提供される遅延情報は３０分以上のもののみであり、詳細な遅延情報が提供されないため不十分である。また、遅延情報の提供元に、鉄道会社以外が存在しないことも問題である。このシステムは鉄道会社とは異なる第二の遅延情報源となることが期待される。
また、現状ＪＲ東日本が詳細な遅延情報を提供するためにはＡＴＯＳというシステムを用いているが、使える路線は首都圏だけなど限定的で、それが導入されていない路線では正確な遅延情報はほとんど提供されない。その路線には、日光線、伊東線、成田線の成田～成田空港など、多くの観光客が利用する路線も含まれている。
このシステムはＡＴＯＳの導入コストより安価で済むため、需要があり、特にＡＴＯＳ未導入の路線への普及が期待される。
提供される遅延情報は３０分以上のもののみであり、詳細な遅延情報が提供されないため不十分である。また、遅延情報の提供元に、鉄道会社以外が存在しないことも問題である。このシステムは鉄道会社とは異なる第二の遅延情報源となることが期待される。
また、現状ＪＲ東日本が詳細な遅延情報を提供するためにはＡＴＯＳというシステムを用いているが、使える路線は首都圏だけなど限定的で、それが導入されていない路線では正確な遅延情報はほとんど提供されない。その路線には、日光線、伊東線、成田線の成田～成田空港など、多くの観光客が利用する路線も含まれている。
このシステムはＡＴＯＳの導入コストより安価で済むため、需要があり、特にＡＴＯＳ未導入の路線への普及が期待される。
【実施例0015】
図１は、本実施例のメインシステムの内部構成をブロック図で示す。
本実施例のメインシステムは、カメラ付きＲａｓｐｂｅｒｒｙ Ｐｉ（登録商標）のような小型コンピュータやプロセッサと、当該コンピュータと有線や無線などのネットワークなどの電磁的手段（図１のＬＡＮを参照）を介して接続される外部の出力手段（Ｔｗｉｔｔｅｒ（登録商標）などＳＮＳ）から構成される。また、本実施例の小型コンピュータは、画像認識部、時刻照合部、ＳＮＳ発信部から構成される。また、図示していないが、本実施例の小型コンピュータの内部および／または外部に、データベースが構築できる記憶部を設けて、小型コンピュータと信号（命令、データ）の送受信ができるように構成されてもよい。
本実施例の画像認識部は、例えば、カメラなどの撮像手段を通じて得られた画像を基に、特定の列車の特定部分の色彩を判別する。また、図４のｓ１からｓ３のような情報処理も実行する。
時刻照合部は、例えば、時刻に関する処理を行う。例えば、データベースに記録された時刻と列車の通過時刻との差異を計算する。また図４のｓ４からｓ１０、ｓ１２のような情報処理も実行する。
ＳＮＳ発信部（または出力部）は、外部のＳＮＳなどに、小型コンピュータの時刻情報部などで生成されたデータを基に、任意のＳＮＳに応じたデータなどを送信する。また、図４のｓ１１、ｓ１３のような情報処理も実行する。
データベースは、本実施例で説明するにあたり必要となるデータ（データ構造）を記憶する。
本実施例のメインシステムは、カメラ付きＲａｓｐｂｅｒｒｙ Ｐｉ（登録商標）のような小型コンピュータやプロセッサと、当該コンピュータと有線や無線などのネットワークなどの電磁的手段（図１のＬＡＮを参照）を介して接続される外部の出力手段（Ｔｗｉｔｔｅｒ（登録商標）などＳＮＳ）から構成される。また、本実施例の小型コンピュータは、画像認識部、時刻照合部、ＳＮＳ発信部から構成される。また、図示していないが、本実施例の小型コンピュータの内部および／または外部に、データベースが構築できる記憶部を設けて、小型コンピュータと信号（命令、データ）の送受信ができるように構成されてもよい。
本実施例の画像認識部は、例えば、カメラなどの撮像手段を通じて得られた画像を基に、特定の列車の特定部分の色彩を判別する。また、図４のｓ１からｓ３のような情報処理も実行する。
時刻照合部は、例えば、時刻に関する処理を行う。例えば、データベースに記録された時刻と列車の通過時刻との差異を計算する。また図４のｓ４からｓ１０、ｓ１２のような情報処理も実行する。
ＳＮＳ発信部（または出力部）は、外部のＳＮＳなどに、小型コンピュータの時刻情報部などで生成されたデータを基に、任意のＳＮＳに応じたデータなどを送信する。また、図４のｓ１１、ｓ１３のような情報処理も実行する。
データベースは、本実施例で説明するにあたり必要となるデータ（データ構造）を記憶する。
【0016】
図２は、本実施例のシステムの全体構成を示す。
本実施例のシステムは、カメラなどの撮像手段と、Ｒａｓｐｈｅｂｂｙ Ｐｉ（登録商標）と、ルーターと、Ｔｗｉｔｔｅｒ（登録商標）などの外部の出力手段から構成される。
本実施例のカメラなどの撮像手段は、線路上の列車の一部を撮像して、列車の特定部分の特定の色を判別するために用いられる。Ｒａｓｐｈｅｂｂｙ Ｐｉ（登録商標）は、図１のＲａｓｐｈｅｂｂｙ Ｐｉ（登録商標）と同様の機能を有している。ルーターは、図１のＬＡＮ上で使用される汎用のネットワーク機器である。
本実施例のシステムは、カメラなどの撮像手段と、Ｒａｓｐｈｅｂｂｙ Ｐｉ（登録商標）と、ルーターと、Ｔｗｉｔｔｅｒ（登録商標）などの外部の出力手段から構成される。
本実施例のカメラなどの撮像手段は、線路上の列車の一部を撮像して、列車の特定部分の特定の色を判別するために用いられる。Ｒａｓｐｈｅｂｂｙ Ｐｉ（登録商標）は、図１のＲａｓｐｈｅｂｂｙ Ｐｉ（登録商標）と同様の機能を有している。ルーターは、図１のＬＡＮ上で使用される汎用のネットワーク機器である。
【0017】
図３は、本実施例のシステムの全体構成の配置を示す。
図３では、図１や図２で示したカメラなどの撮像手段、Ｒａｓｐｈｅｂｂｙ Ｐｉ（登録商標）を示している。図３では、特に、カメラなどの撮像手段の最適な配置の一例を示しており、例えば、本実施例のカメラは、列車の特定部分を撮像できるように、障害物がないような建物の窓際などに設置される。また、別の実施例として、例えば、線路の数に応じて、複数のカメラを設置してもよい。
図３では、図１や図２で示したカメラなどの撮像手段、Ｒａｓｐｈｅｂｂｙ Ｐｉ（登録商標）を示している。図３では、特に、カメラなどの撮像手段の最適な配置の一例を示しており、例えば、本実施例のカメラは、列車の特定部分を撮像できるように、障害物がないような建物の窓際などに設置される。また、別の実施例として、例えば、線路の数に応じて、複数のカメラを設置してもよい。
【0018】
図４は、本実施例のメインシステムの動作をフローチャートで示す。
【0019】
ｓ１：撮影された列車の画像から列車の帯の部分の画像を抽出し、当該抽出された画像を画素の配列と見なし、ＯｐｅｎＣＶなどの画像処理および画像解析などのライブラリを用いて、ＲＧＢで表された各画素をＨＳＶに変換する。次に、変換後の画素に対して以下の手順で二値化、列車の帯の色をみたす画素の割合の計算を行う。まず、（データベースなどに）あらかじめ用意した列車の帯の色相の範囲と各（変換された）画素とを比較し、満たす画素（画素が当該色相の範囲内にあること）を１、満たさない画素（画素が当該色相の範囲内にないこと）を０として新たに画像を生成する。次に、これによって得られた二値画像の画素のうち、１である画素の割合が６０％などの所定割合を超えたと判定した場合はＹＥＳに、そうでない場合にはＮＯに分岐する。
【0020】
ｓ２：ｓ１と同様の処理を行う。ここで、画像の状態を定義する。ＹＥＳに分岐した場合の状態（図６の下側「２枚目の写真」の状態）をＢ、ＮＯに分岐した場合の状態（図６の上側「１枚目の写真」の状態）をＡとする。
【0021】
ｓ３：画像の状態がＡからＢに遷移した場合、列車の通過として扱い、以下のブロックを実行していく。
【0022】
ｓ４：小型コンピュータ内の時計の時刻を取得する。なお、小型コンピュータの時刻は一日おきに外部のｎｔｐサーバーと時刻を同期しているため、常に日本標準時での時刻提供を行う。
【0023】
ｓ５：まず、計測場所付近の駅の時刻表に、その駅から計測地点までの所要時間を足したものを計測地点での定刻時刻として、データベースに記憶する。
【0024】
ｓ６：列車が通過したときに、データベースよりｎ番目（ｎ＝始発の列車カウントを１とする）の列車の通過時刻との差を算出する。
【0025】
ｓ７：データベース内の列車カウント変数ｎに１を足し、次に通過する列車が、始発から何本目の電車かを記憶する。
【0026】
ｓ８：次にデータベースの時間と通過時刻の差を計算する。その差が２分以上（所定時間以上）の場合と、２分未満（所定時間未満）の場合で条件分岐する。
【0027】
ｓ９：２分以上（所定時間以上）の場合、遅延していることを伝えるツイートのテンプレートを用意する。このツイートには現在時刻、計測地点付近の駅の発車時刻、遅延時間などを掲載している。テンプレートは、データベースなどの任意の記憶手段に記憶されていてもよい。Ｔｗｉｔｔｅｒ（登録商標）の文字数に１４０字制限があり掲載できる情報に限りがあるため、ほかの情報を入れたい場合は情報を入れ替える必要がある。
【0028】
ｓ１０：その後、現在時刻、計測地点付近の駅の発車時刻、遅延時間をそのツイートに入れる。現在時刻はｓ４で取得した時刻から、計測地点付近の駅の発車時刻は計測地点のデータベースから、遅延時間はｓ６で取得したものを入れる。
【0029】
ｓ１１：ｓ１０で作成したツイートをＴｗｉｔｔｅｒ（登録商標）に発信する。
【0030】
ｓ１２：また、２分未満（所定時間未満）の場合は現在、平常運転ということを伝えるツイートのテンプレートを用意する。現在時刻はｓ１０と同じようにｓ４で取得したものを使用している。
【0031】
ｓ１３：ｓ１２で作成したツイートをＴｗｉｔｔｅｒ（登録商標）に発信する。
【0032】
図５は、本実施例のアプリの動作をフローチャートで示す。
【0033】
ｓ１４：「路線を選択」の画面はアプリを開いたとき最初に表示される画面である。この画面から遅延を検索したい路線のボタンを選び、次に表示される駅選択画面に遷移する。今回作成したアプリは試作版でＪＲ東日本の首都圏主要路線のボタンを実装したが、実際にボタンが動作するのは実験を行っている中央線のみである。本来はカメラを設置しシステムを運用した路線のみを表示する。ボタンの縦配置を基本とし、ボタンの増設はＡｎｄｒｏｉｄアプリ制作ソフト「Ａｎｄｒｏｉｄｓｔｕｄｉｏ」を利用して行う。ユーザビリティ向上のためにボタンの大きさは指で押しやすいサイズにし、スクロールできるようにしている。各ボタンにはそれぞれの路線のラインカラーを使い、ボタンの左から順番に路線記号、路線名、車両前面イラストの順番に配置している。
【0034】
ｓ１５：「駅を選択」では、ユーザーが実際に乗車する駅を選択する。前の路線選択と同様にボタンの縦配置を基本とし、ボタンの色には路線のラインカラーを採用、また駅それぞれのナンバリングも実際の駅名標にあるものと同じものを配置し利便性向上を図っている。
【0035】
ｓ１６：「その駅の鉄道会社の時刻表ページに移動」では、ＷｅｂＶｉｅｗを用いてアプリ内にユーザーが選択した鉄道会社の駅の時刻表のページを表示する。
【0036】
ｓ１７：「上り下りを選択」ではユーザーが乗車したい路線の上り下りを選択する。場合により平日、土休日の選択することがある。
【0037】
ｓ１８：「発車時刻を選択」ではユーザーの乗車したい列車の発車時刻を選択する。何時何分に乗車するのかを細かく決めることができる。
【0038】
ｓ１９：ユーザーがアプリ画面右上の「この列車を調べる」ボタンをタップし、かつ任意の列車別時刻表のページが開かれている時、アプリケーションは、ＷｅｂＶｉｅｗで表示されているページのＵＲＬを取得する。次に、取得したＵＲＬの．ｈｔｍｌを除く末尾６文字を抽出する。最後に、ＷｅｂＶｉｅｗは抽出された６文字の頭に「ＤＩＳＳ＿」を付した文字列をハッシュタグとするその列車の遅延情報が掲載されているＴｗｉｔｔｅｒ（登録商標）の投稿を表示する。
【0039】
図６は、本実施例の判別手法を示す。
プロセスは大きく分けて「写真の撮影」「列車が映っているかの判別」「ＳＮＳ上への情報の提供」である。
基本的な車両の判別方法は、画像内の列車が映る領域をトリミングし、色相・明度・彩度に応じて画像にマスクを掛け、車両の帯の色（中央線の場合はオレンジ色）の特定部分だけを残して、それ以外のピクセルを全て黒で埋める処理をする。
次に、画像の合計のピクセル数から黒のピクセル数を引いて、車両の帯の色のピクセル数を数え、一定値を超えた場合に列車が通過したと判断する。
また、上記の方法では太陽光の明るさが失われる夜間においては色相情報が保存されないと考えたため、車両の窓部分の画素の明度を測定し、一定値以上になった時に列車が通過したと判断する手法を採用している。
昼間においては、撮影した写真のうち、列車が映る右側と左側（図３の写真内の白枠の部分２箇所）をトリミングし、それぞれの写真に列車が写っているかを確かめる。検知の状況を場合分けすると▲１▼「左側→検出あり、右側→検出なし」、▲２▼「左側→検出あり、右側→検出あり」、▲３▼「左側→検出なし、右側→検出あり」、▲４▼「左側→検出なし、右側→検出なし」の４パターンとなる。例えば、図３のように１枚目の写真の状態が▲１▼、２枚目の写真の状態が▲２▼の場合、「列車が左から右に通過した」と判断することができる。
プロセスは大きく分けて「写真の撮影」「列車が映っているかの判別」「ＳＮＳ上への情報の提供」である。
基本的な車両の判別方法は、画像内の列車が映る領域をトリミングし、色相・明度・彩度に応じて画像にマスクを掛け、車両の帯の色（中央線の場合はオレンジ色）の特定部分だけを残して、それ以外のピクセルを全て黒で埋める処理をする。
次に、画像の合計のピクセル数から黒のピクセル数を引いて、車両の帯の色のピクセル数を数え、一定値を超えた場合に列車が通過したと判断する。
また、上記の方法では太陽光の明るさが失われる夜間においては色相情報が保存されないと考えたため、車両の窓部分の画素の明度を測定し、一定値以上になった時に列車が通過したと判断する手法を採用している。
昼間においては、撮影した写真のうち、列車が映る右側と左側（図３の写真内の白枠の部分２箇所）をトリミングし、それぞれの写真に列車が写っているかを確かめる。検知の状況を場合分けすると▲１▼「左側→検出あり、右側→検出なし」、▲２▼「左側→検出あり、右側→検出あり」、▲３▼「左側→検出なし、右側→検出あり」、▲４▼「左側→検出なし、右側→検出なし」の４パターンとなる。例えば、図３のように１枚目の写真の状態が▲１▼、２枚目の写真の状態が▲２▼の場合、「列車が左から右に通過した」と判断することができる。
【0040】
図７は、本実施例で使用するデータ構造の一例を示す。
列車の遅延の判断基準として、本来の通過時刻を記録したデータベースが必要となる。まず撮影場所（カメラを設置した場所）の前の駅の時刻に、そこから撮影場所までの平均所要時間を足して、撮影場所の列車の通過時刻を求める。各列車の通過時刻をカンマ区切りファイル形式でまとめたものをデータベースとして利用する。
駅の時刻表には秒数が載っていないため、基準の秒数を３０で統一した。これは、首都圏の過密路線を除く多くの路線でダイヤが１５秒単位で組まれているため、誤差を最低限に減らすことを考慮したからである。
列車をカメラで検出したあとは、始発から数えた通過回数を基準にデータベースを参照し、現在時刻との比較を行うことで遅延を検出する仕組みである。
Ａ列が撮影場所の列車の本来の通過時刻、Ｂ列が列車の種別、Ｃ列が行先（東京行きの場合空白）、Ｄ列が後述する「列車識別用ハッシュタグ」に関係する数字である。
また、毎年３月に行われているダイヤ改正にすぐ対応にするため、ダイヤ改正が行われたら自動でＪＲ東日本のホームページからデータを取得し、データベースの内容を書き換えるプログラムも作成する。
以上の手法を用いて列車の遅延を計算し、ＳＮＳ上で情報を提供する。実際に提供される内容は、
・カメラの設置場所で通過を検出した時間
・撮影場所の最寄り駅の時刻表の時刻
・列車の種別、及び行き先
・遅延しているか
・電子遅延証明書へのリンク
であり、情報提供の際に遅延と表示する基準は１２０秒（２分）以上である。
列車の遅延の判断基準として、本来の通過時刻を記録したデータベースが必要となる。まず撮影場所（カメラを設置した場所）の前の駅の時刻に、そこから撮影場所までの平均所要時間を足して、撮影場所の列車の通過時刻を求める。各列車の通過時刻をカンマ区切りファイル形式でまとめたものをデータベースとして利用する。
駅の時刻表には秒数が載っていないため、基準の秒数を３０で統一した。これは、首都圏の過密路線を除く多くの路線でダイヤが１５秒単位で組まれているため、誤差を最低限に減らすことを考慮したからである。
列車をカメラで検出したあとは、始発から数えた通過回数を基準にデータベースを参照し、現在時刻との比較を行うことで遅延を検出する仕組みである。
Ａ列が撮影場所の列車の本来の通過時刻、Ｂ列が列車の種別、Ｃ列が行先（東京行きの場合空白）、Ｄ列が後述する「列車識別用ハッシュタグ」に関係する数字である。
また、毎年３月に行われているダイヤ改正にすぐ対応にするため、ダイヤ改正が行われたら自動でＪＲ東日本のホームページからデータを取得し、データベースの内容を書き換えるプログラムも作成する。
以上の手法を用いて列車の遅延を計算し、ＳＮＳ上で情報を提供する。実際に提供される内容は、
・カメラの設置場所で通過を検出した時間
・撮影場所の最寄り駅の時刻表の時刻
・列車の種別、及び行き先
・遅延しているか
・電子遅延証明書へのリンク
であり、情報提供の際に遅延と表示する基準は１２０秒（２分）以上である。
【0041】
図８は、遅延が起きた際の実際のＴｗｉｔｔｅｒ（登録商標）の投稿例を示す。
また、利用客が自分の乗る予定のある特定の列車の遅延のみを検索できるようにするために、Ｔｗｉｔｔｅｒ（登録商標）ではカメラの設置場所に依存する基準の駅に縛られず、絶対的に列車に名前を付ける「列車識別用ハッシュタグ」（図８の「＃ＤＩＳＳ＿１５８２３１」）を投稿に添えている。
現在実装している列車識別用ハッシュタグは、ＪＲ東日本の提供する列車別時刻表のページのＵＲＬをもとに作成している。
Ｒａｓｐｂｅｒｒｙ Ｐｉ（登録商標）２台で動作させる方法とる予定だったが、プログラムの簡略化が可能かつ、コスト削減が可能である１台で動作させる手段をとった。
また、認識方法を昼夜で変更することで、昼夜での列車の識別、及び通過列車の方向検出に成功した。
画素の色相の検出により、影、日差しの外部的要因に影響されにくくなり、正確に遅延を検出することが可能になった。
利便性向上を図るためＡｎｄｒｏｉｄ（登録商標）で動作するアプリケーション（以下Ａｎｄｒｏｉｄアプリ）を作成した。アプリケーション開発環境にはＡｎｄｒｏｉｄ Ｓｔｕｄｉｏを使用し、Ａｎｄｒｏｉｄ１１、１２、１３のＡｎｄｒｏｉｄスマートフォンでの環境で動作することを確認している。
検索する手間を省くことによる利便性向上を目的とし、Ａｎｄｒｏｉｄアプリではボタン配置のみを基本とした。また、それぞれの路線のナンバリング、列車アイコンなどを配置し視覚的にも分かりやすくしている。
また、利用客が自分の乗る予定のある特定の列車の遅延のみを検索できるようにするために、Ｔｗｉｔｔｅｒ（登録商標）ではカメラの設置場所に依存する基準の駅に縛られず、絶対的に列車に名前を付ける「列車識別用ハッシュタグ」（図８の「＃ＤＩＳＳ＿１５８２３１」）を投稿に添えている。
現在実装している列車識別用ハッシュタグは、ＪＲ東日本の提供する列車別時刻表のページのＵＲＬをもとに作成している。
Ｒａｓｐｂｅｒｒｙ Ｐｉ（登録商標）２台で動作させる方法とる予定だったが、プログラムの簡略化が可能かつ、コスト削減が可能である１台で動作させる手段をとった。
また、認識方法を昼夜で変更することで、昼夜での列車の識別、及び通過列車の方向検出に成功した。
画素の色相の検出により、影、日差しの外部的要因に影響されにくくなり、正確に遅延を検出することが可能になった。
利便性向上を図るためＡｎｄｒｏｉｄ（登録商標）で動作するアプリケーション（以下Ａｎｄｒｏｉｄアプリ）を作成した。アプリケーション開発環境にはＡｎｄｒｏｉｄ Ｓｔｕｄｉｏを使用し、Ａｎｄｒｏｉｄ１１、１２、１３のＡｎｄｒｏｉｄスマートフォンでの環境で動作することを確認している。
検索する手間を省くことによる利便性向上を目的とし、Ａｎｄｒｏｉｄアプリではボタン配置のみを基本とした。また、それぞれの路線のナンバリング、列車アイコンなどを配置し視覚的にも分かりやすくしている。
【0042】
図９は、本実施例のアプリの表示例を示しており、選択できる路線の表示例を示す。
図９の上側、路線選択のボタンデザインはボタンの真ん中に路線名、左端に路線ナンバリング、右端にその路線を走る代表的な車両アイコンを配置した。
図９の上側、路線選択のボタンデザインはボタンの真ん中に路線名、左端に路線ナンバリング、右端にその路線を走る代表的な車両アイコンを配置した。
【0043】
図１０は、本実施例のアプリの表示例を示しており、選択された路線内の駅であって、選択できる駅の表示例を示す。
図１０において、駅選択のボタンデザインはボタン右寄りに駅名、左端に路線ナンバリングを配置、路線ナンバリングはＪＲ東日本に準拠している。
図１０のスマートフォン画面がアプリ画面の例になっており、▲１▼路線を選択→▲２▼駅を選択→▲３▼乗りたい列車の時刻表を選択→▲４▼遅延情報の表示という手順をたどることで、選択された列車の遅延情報がボタン操作のみで知れるようになった。遅延情報の表示には自分たちが投稿している遅延情報を、ＷｅｂＶｉｅｗを使い表示させている。
図１０において、駅選択のボタンデザインはボタン右寄りに駅名、左端に路線ナンバリングを配置、路線ナンバリングはＪＲ東日本に準拠している。
図１０のスマートフォン画面がアプリ画面の例になっており、▲１▼路線を選択→▲２▼駅を選択→▲３▼乗りたい列車の時刻表を選択→▲４▼遅延情報の表示という手順をたどることで、選択された列車の遅延情報がボタン操作のみで知れるようになった。遅延情報の表示には自分たちが投稿している遅延情報を、ＷｅｂＶｉｅｗを使い表示させている。
【0044】
また、発展可能性として、画像認識の精度を向上、路線バスなどにも使用できる可能性がある。バス停などにカメラを設置し、バス停の時刻表と比較することで、バス停停車時点でどのぐらい遅れているかがわかるようになる。路線バスは鉄道路線と違い、同じところを走らないので画像認識の他に機械学習などを用いてバスの色を判別できるようにすれば路線バスにも転用できると考えている。
【0045】
以上のように本発明の実施態様について説明したが、上述の説明に基づいて当業者にとって種々の代替例、修正又は変形が可能であり、本発明はその趣旨を逸脱しない範囲で前述の種々の代替例、修正又は変形を包含するものである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【手続補正書】
【提出日】2023-09-14
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
カメラを用いた列車遅延を検出および提供するシステムであって、
画像認識部と、時刻照合部と、出力部と、データベースとを備え、
画像認識部は、
カメラで撮像された列車の画像から列車の帯の部分の画像を抽出し、当該抽出された画像を画素の配列と見なし、ＲＧＢで表された各画素を画像処理解析ライブラリを用いてＨＳＶに変換し、変換後の画素に対して二値化し、列車の帯の色をみたす画素の割合の計算し、画像内の画素の割合が所定の割合を超えたか超えないかによって画像の状態を定義し、
定義された画像の状態が所定の割合を超えた状態から所定の割合を超えない状態に遷移した場合、列車の通過として判断し、
時刻照合部は、
時計の時刻を取得し、
計測場所付近の駅の時刻表のｎ番目（ｎ＝始発の列車カウントを１とする）列車の時刻に、その駅から計測地点までの所要時間を足したものを計測地点での定刻として、データベースに記憶し、
前記画像認識部が、前記ｎ番目列車が通過したと判断したときに、前記データベー スの前記ｎ番目列車の前記定刻と前記ｎ番目列車の通過時刻との差を算出し、
前記差が所定時間以上の場合、遅延していることを伝える出力データのテンプレートを用意し、出力データには現在時刻、計測地点付近の駅の発車時刻、遅延時間を含み、
前記差が所定時間未満の場合は現在、平常運転ということを伝える出力データのテンプレートを用意し、
出力部は、
用意した出力データを外部のＳＮＳに発信することを特徴とするシステム。
画像認識部と、時刻照合部と、出力部と、データベースとを備え、
画像認識部は、
カメラで撮像された列車の画像から列車の帯の部分の画像を抽出し、当該抽出された画像を画素の配列と見なし、ＲＧＢで表された各画素を画像処理解析ライブラリを用いてＨＳＶに変換し、変換後の画素に対して二値化し、列車の帯の色をみたす画素の割合の計算し、画像内の画素の割合が所定の割合を超えたか超えないかによって画像の状態を定義し、
定義された画像の状態が所定の割合を超えた状態から所定の割合を超えない状態に遷移した場合、列車の通過として判断し、
時刻照合部は、
時計の時刻を取得し、
計測場所付近の駅の時刻表のｎ番目（ｎ＝始発の列車カウントを１とする）列車の時刻に、その駅から計測地点までの所要時間を足したものを計測地点での定刻として、データベースに記憶し、
前記画像認識部が、前記ｎ番目列車が通過したと判断したときに、前記データベー スの前記ｎ番目列車の前記定刻と前記ｎ番目列車の通過時刻との差を算出し、
前記差が所定時間以上の場合、遅延していることを伝える出力データのテンプレートを用意し、出力データには現在時刻、計測地点付近の駅の発車時刻、遅延時間を含み、
前記差が所定時間未満の場合は現在、平常運転ということを伝える出力データのテンプレートを用意し、
出力部は、
用意した出力データを外部のＳＮＳに発信することを特徴とするシステム。