(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024009073
(43)【公開日】2024-01-19
(54)【発明の名称】船舶動静共有航行支援システム
(51)【国際特許分類】
G08G 3/02 20060101AFI20240112BHJP
G01C 21/20 20060101ALI20240112BHJP
B63B 49/00 20060101ALI20240112BHJP
B63B 43/18 20060101ALI20240112BHJP
【FI】
G08G3/02 A
G01C21/20
B63B49/00 Z
B63B43/18
【審査請求】有
【請求項の数】1
【出願形態】OL
(21)【出願番号】P 2023193690
(22)【出願日】2023-11-14
(62)【分割の表示】P 2019110692の分割
【原出願日】2019-06-13
(71)【出願人】
【識別番号】518458218
【氏名又は名称】アイディア株式会社
(74)【代理人】
【識別番号】110003476
【氏名又は名称】弁理士法人瑛彩知的財産事務所
(72)【発明者】
【氏名】下川部 知洋
(72)【発明者】
【氏名】中野 智央
(72)【発明者】
【氏名】千葉 福太朗
(72)【発明者】
【氏名】齋藤 祐輔
(57)【要約】
【課題】 船舶の衝突予防に有益な機能を、より多くの操船者に対して、より理解が容易な態様で提示することが可能な船舶動静共有航行支援システムを提供する。
【解決手段】 操船者及び船舶を識別する情報と船舶動静情報履歴とを紐づけて管理し、操船中はマップデータで規定された形式に変換された船舶動静共有データをユーザインターフェイスに表示するので、船舶の衝突予防に有益な機能を、より理解が容易な態様で提示することが可能となり、操船者と船舶が特定された船舶動静情報履歴が管理されるので、操船者や運航事業者等対する安全性の向上のための情報や保険の適用に関する情報等を提供できるようになるので、より多くの操船者に対して船舶動静共有航行支援システムを利用するインセンティブを提供することが可能となる。
【選択図】
図5
【特許請求の範囲】
【請求項1】
少なくとも操船者を識別する操船者識別情報、船舶を識別する船舶識別情報、並びに船舶の位置及び動静を示す船舶動静情報履歴を管理するデータベースと、
船舶の少なくとも位置情報示す船舶位置データを受信し、前記データベースに記憶させるバックエンドサービスと、
を含むバックエンドプラットフォームと、
ユーザインターフェイスに対するデータ出力及びびユーザからの操作入力を受け付けるフロントエンドと、
前記バックエンドプラットフォームと前記フロントエンドとのインターフェイスであるアプリケーションプログラミングインタフェース(Application Programming Interface:API)と、
を備え、
前記ユーザインターフェイスは、前記データベースで管理された前記船舶動静情報に基づいて、マップデータで規定された形式に変換された船舶動静共有データを表示し、
前記APIは、前記ユーザインターフェイスを提供するアプリケーションを実行する通信端末が搭載された船舶の前記船舶識別情報と当該船舶を操船する操船者の前記操船者識別情報とを紐づける入力を、前記ユーザインターフェイスから受け付け、
前記バックエンドサービスは、前記船舶識別情報及び前記操船者識別情報と、前記船舶動静情報とを紐づけて、前記船舶動静情報履歴として前記データベースに記憶させる、船舶動静共有航行支援システム。
【請求項2】
前記バックエンドプラットフォームは、前記船舶動静情報の現在値を保管するデータストアをさらに備え、
前記バックエンドサービスは、前記データストアに前記船舶動静情報の最新情報を保管し、
前記フロントエンドは、前記データストアに保管された前記船舶動静情報を前記ユーザインターフェイスに表示させる、
請求項1に記載の船舶動静共有航行支援システム。
【請求項3】
前記船舶識別情報には、船舶サイズ及び船種が含まれ、
前記船舶動静共有データとして前記ユーザインターフェイスに表示される船舶を示す船舶アイコンは、前記船種に応じた画像デザインであり、前記船舶サイズの縮尺が前記マップデータの縮尺に対応している、
請求項1又は2に記載の船舶動静共有航行支援システム。
【請求項4】
前記船舶動静情報履歴には、日時情報、位置情報、船速情報及び針路情報が含まれ、
前記ユーザインターフェイスは、前記位置情報、前記船速情報及び前記針路情報に基づいて算出された衝突予測領域に基づいて船舶の衝突予測を実行し、前記衝突予測に基づく警告を表示する、
請求項1乃至3のいずれかに記載の船舶動静共有航行支援システム。
【請求項5】
前記衝突予測領域には、警告を促す警告領域及び注意を促す注意領域が含まれ、
前記警告領域は、前記針路情報及び船速情報に基づいて算出された、所定時間以内に当該船舶が航行する可能性の高い領域として提示され、
前記注意領域は、前記針路情報及び船速情報に基づいて算出された、他船の避航動作に関する注意を行うべき領域として提示される、
請求項4に記載の船舶動静共有航行支援システム。
【請求項6】
前記データベースは、少なくとも位置情報を含むプロット情報をさらに管理し、
前記APIは、前記ユーザインターフェイスから前記プロット情報の入出力を受け付け、
前記ユーザインターフェイスは、前記データベースに管理された前記プロット情報に対応するプロットデータを前記船舶動静共有データとあわせて表示する、
請求項1乃至5のいずれかに記載の船舶動静共有航行支援システム。
【請求項7】
前記プロットデータは、船舶の接近に関する監視対象である監視領域を意味し、
前記ユーザインターフェイスは、前記警告領域が前記監視領域と重複する場合には、警告を促す、
請求項6に記載の船舶動静共有航行支援システム。
【請求項8】
前記バックエンドは、アプリケーションレイヤで動作する通信プロトコルを介した音声通話機能を提供する音声サーバをさらに備え、
前記ユーザインターフェイスは船舶無線の操作インターフェイスを模した無線パネルを表示し、
前記音声サーバは、前記無線パネルにおける操作入力及び前記ユーザインターフェイスを提供するアプリケーションに紐づけられた前記船舶情報に基づいて、複数の前記ユーザインターフェイスに対して音声データの送受信を制御する、
請求項1乃至7のいずれかに記載の船舶動静共有航行支援システム。
【請求項9】
前記音声サーバは、前記無線パネルにおいて発話側の操作が検出された場合に、前記船舶情報に紐づいた前記船舶動静情報履歴に基づいて、前記発話側のアプリケーションに紐づけられた船舶から所定の範囲内に位置する船舶に紐づけられた前記アプリケーションを聴取側として特定して、音声データの送受信を制御する、
請求項8に記載の船舶動静共有航行支援システム。
【請求項10】
前記データベースは、前記操船者識別情報及び前記船舶識別情報に紐づけられた所属をグループとして識別するグループ識別情報をさらに管理し、
前記音声サーバは、前記無線パネルにおいて発話側の操作が検出された場合に、前記発話側のアプリケーションに紐づけられた前記グループ識別情報に基づいて、同一グループに属する前記アプリケーションを聴取側として特定して、音声データの送受信を制御する、
請求項8に記載の船舶動静共有航行支援システム。
【請求項11】
前記APIは、前記データベースに管理された前記操船者識別情報、前記船舶識別情報、及び船舶動静情報履歴に基づいて、操船者別の操船履歴及び船舶別の航海履歴を作成するためのデータを前記フロントサービスに提供し、
前記フロントサービスは、作成した前記操船履歴及び航海履歴を前記ユーザインターフェイスに表示する、
請求項1乃至10のいずれかに記載の船舶動静共有航行支援システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、船舶動静共有航行支援システムに関する。
【背景技術】
【0002】
船舶の安全な航行のための国際的なルールとして、海上における衝突の予防のため国際規則に関する条約(Convention On the InternationaL REGulations for Preventing Collisions at Sea:COLREGS)や、海上における人命の安全のための国際条約(International Convention for the Safety of Life at Sea:SOLAS)等があり、対応する国内法として、海上衝突予防法や船舶安全法等がある。これらの条約は、船舶の通行に関する基本的なルールを定めるとともに、一定の船舶に対しては、衝突を予防するための各種装置の搭載を義務付けている。このような義務を有する船舶は一般的に「SOLAS船」と呼ばれている
【0003】
SOLASで規定された代表的な装置としては、VHF(Very High Frequency)と呼ばれる周波数帯(VHFバンド)を使用し、船舶において遭難・安全通信、港務通信、電気通信業務、水先業務等に用いられる「国際VHF」と呼ばれている無線通信システムや、国際VHF帯の専用チャネルを使用して船舶の位置や動静等の状態を自動識別するための信号を送受信する自動船舶識別装置(Automatic Identification System:AIS)、対象となる物標を自動的に捕捉し、物標までの方位や距離を計算して表示するとともに、衝突の危険性を自動的に判断する自動レーダープロッティング装置(Automatic Radar Plotting Aids:ARPA)等がある。
【0004】
図1は、船舶の航行状況や通信環境のイメージを示す図である。海上では、基本的には有線による通信ができないため、無線による通信が行われる。船舶では主に衛星通信が利用されているものの、沿岸部であれば携帯電話網が利用できる場合もある。AISは船舶の位置や動静等に関するデータを国際VHF帯のチャネルを使用して船舶間でデジタルデータ通信を行うものであるが、通信衛星でAIS信号を受信する衛星AISや、陸上でAIS信号を受信するAIS海岸局も運用されており、受信されたAISデータをインターネット上で提供するサービスも開発されている。
【0005】
国際航海に従事しない500トン以上の船舶や国際航海に従事する300トン以上の船舶のような大型船にAISの搭載義務があるものの、小型船舶等のようなAIS搭載が義務付けられていない非SOLAS船については、AISによる船舶動静を把握することができない。沿岸部における衝突事故も多くはプレジャーボートや漁船に関するものであるため、携帯電話やスマートフォン等の通信端末を利用した船舶動静情報の共有も進められている。
【0006】
特許文献1には、AIS搭載船からVHF帯で受信したAIS情報と、GPS受信機能を備えた情報通信端末から受信したAIS非搭載船の船舶情報とをインターネットを介してメインサーバに集約して一元化し、通信端末に配信する船舶運航監視システムが開示されている。
特許文献2には、所定の位置的な条件を満たすAIS搭載船の航海情報及びAIS非搭載船から位置情報を取得する情報配信装置から船舶情報を取得し、自己位置を基準とした警報通知ゾーンに侵入した船舶に関する警報を出力する通信端末が開示されている。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開2006-163765号公報
【特許文献2】特開2017-102986号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
AISやARPA等のSOLASで規定された衝突予防装置は、国内航海のみを行う小型船舶には搭載義務はない。また、大型の船舶を操船するためには海技免状及び所定のトレーニングが必要であるため、このような装置は、訓練された有資格者が使用することを前提としてデザインされおり、一般的なユーザにとって直感的に理解できるようなユーザインターフェイスにはなっていない。さらに、AISや国際VHFのような所定の電波を発する装置の使用には、免許の取得や無線局開設に関する電波法上の手続きが必要となり、小型船舶を含むすべての船舶に対して使用を義務付けることは困難な状況にある。
【0009】
海上交通安全法や港則法では、交通制限が必要な工事作業や輻輳海域における工事作業を行う場合には、実施海域付近を航行する船舶の安全を確保する観点から、警戒船を配備することが要求されており、警戒船の乗組員についても一定の要件を課している。警戒船の任務には、実施海域に異常接近する船舶に対して注意を喚起することや、異常を発見した場合には実施海域内の関係者にその情報を通報すること等があり、実施海域の状況を踏まえてAISや国際VHFを装備することになっている。しかし、これらの設備を搭載していない船舶を監視することや、音声コミュニケーションを図ることは困難である。
【0010】
上記の特許文献に記載されたような情報端末を用いる場合には、より多くの船舶が同様の情報端末を搭載していなければ、船舶の動静を共有することができず、衝突を回避するための行動を判断することは困難である。また、国際VHFは、衝突を回避するための音声コミュニケーションに用いられるが、携帯電話による通話やスマートフォンで動作するアプリ上のチャット機能等では、通信相手を特定できなければ通話することができないため、相手が特定されていない船舶に対して衝突を回避するために緊急のコミュニケーションを図ることはできない。
【0011】
また、プレジャーボートや漁船では、自己位置を公表することに抵抗感もあり、AISやスマートフォンアプリを用いて位置情報を提供する装置の搭載を非SOLAS船にも義務付けることが困難である状況に鑑みると、通信端末を搭載するモチベーションを高めて普及を図る必要がある。
本発明は上述した課題を解決するためになされたものであり、船舶の衝突予防に有益な機能を、より多くの操船者に対して、より理解が容易な態様で提示することが可能な船舶動静共有航行支援システムを提供することを課題とする。
【課題を解決するための手段】
【0012】
上述した課題を解決するために、実施形態にかかる船舶動静共有航行支援システムは、少なくとも操船者を識別する操船者識別情報、船舶を識別する船舶識別情報、並びに船舶の位置及び動静を示す船舶動静情報履歴を管理するデータベースと、船舶の少なくとも位置情報示す船舶位置データを受信し、前記データベースに記憶させるバックエンドサービスと、 を含むバックエンドプラットフォームと、ユーザインターフェイスに対するデータ出力及びびユーザからの操作入力を受け付けるフロントエンドと、前記バックエンドプラットフォームと前記フロントエンドとのインターフェイスであるアプリケーションプログラミングインタフェース(Application Programming Interface:API)と、を備え、前記ユーザインターフェイスは、前記データベースで管理された前記船舶動静情報に基づいて、マップデータで規定された形式に変換された船舶動静共有データを表示し、前記APIは、前記ユーザインターフェイスを提供するアプリケーションを実行する通信端末が搭載された船舶の前記船舶識別情報と当該船舶を操船する操船者の前記操船者識別情報とを紐づける入力を、前記ユーザインターフェイスから受け付け、前記バックエンドサービスは、前記船舶識別情報及び前記操船者識別情報と、前記船舶動静情報とを紐づけて、前記船舶動静情報履歴として前記データベースに記憶させる。
【発明の効果】
【0013】
操船者及び船舶を識別する情報と船舶動静情報履歴とを紐づけて管理し、操船中はマップデータで規定された形式に変換された船舶動静共有データをユーザインターフェイスに表示するので、船舶の衝突予防に有益な機能を、より理解が容易な態様で提示することが可能となり、操船者と船舶が特定された船舶動静情報履歴が管理されるので、操船者や運航事業者等対する安全性の向上のための情報や保険の適用に関する情報等を提供できるようになるので、より多くの操船者に対して船舶動静共有航行支援システムを利用するインセンティブを提供することが可能となる。
【図面の簡単な説明】
【0014】
【
図1】船舶の航行状況や通信環境のイメージを示す図である。
【
図3】システム全体のネットワーク概要構成図である。
【
図4】通信機器間の関係を説明するためのプロトコルスタックを示す図である。
【
図5】アプリケーションレイヤにおける各機器の機能ブロック図である。
【
図6】船舶動静共有航行支援システムのユースケースを示す図である。
【
図7】アプリの実行によって表示されるトップ画面のイメージ図である。
【
図8】アカウント関連のテーブル構造とリレーションの一例を示す図である。
【
図9】船舶関連のテーブル構造とリレーションの一例を示す図である。
【
図13】プロット関連のテーブル構造とリレーションの一例を示す図である。
【
図14】マップ表示画面のレイヤ構造について説明する図である。
【
図15】マップ表示の縮尺と船舶アイコンの表示態様との関係を示す図である。
【
図16】レイヤ構成によって画面上に生成されたマップ表示のイメージ図である。
【
図17】船舶アイコンの表示可否について判定するフローチャートである。
【
図18】ヒートマップを表示したマップ画面のイメージ図である。
【
図20】レーダーモード表示にかかる処理を示すフローチャートである。
【
図21】警告対象船抽出処理を示すフローチャートである。
【
図22】注意対象船抽出処理を示すフローチャートである。
【
図23】仮想無線の機能を使用者に提示する画面イメージを示す図である。
【
図24】接続から待機中の処理を示すシーケンス図である。
【
図25】PTT通話時の処理を示すシーケンス図である。
【
図26】グループ無線機能を実行している陸上管理端末の画面イメージである。
【
図27】グループ無線に係る処理を示すシーケンス図である。
【
図28】航路再生アニメーションのイメージ図である。
【
図29】操船を開始してから終了するまでの処理の流れを概略的に示す図である。
【
図31】プロジェクトにおける操船履歴の表示例である。
【
図32】監視領域を設定するためのプロット作成画面の例である。
【
図33】監視領域として登録された位置情報と船舶情報に関するデータ構成を説明する図である。
【
図34】航行中の船舶が監視領域に接近した際にアプリに表示される画面のイメージである。
【
図35】航行中の船舶が監視領域に接近した際にアプリに表示される画面のイメージである
【
図36】監視領域に接近する船舶を検出する処理を示すフローチャートである。
【
図37】警告領域ドキュメントに関する処理のフローチャートである。
【
図38】陸上の管理者が使用しているブラウザに警告を表示する例を示す図である。
【発明を実施するための形態】
【0015】
以下、図面を用いて実施形態を説明する。
[1 システムの全体構成]
[1.1 サービスモデル]
まず、船舶動静共有航行支援システムの利用形態について説明する。
図2は、サービスモデルを示すスキーム図である。サービスプロバイダ10が船舶動静共有航行支援システムを用いたサービスを提供しており、船舶の操船を行う操船者20、船舶の運航を行う運航事業者30、船舶の運航を伴う工事を行う工事業者40、船舶保険を提供している保険会社50、及び港湾、工事エリア、漁網設置エリア等の船舶の運航に関する規制が必要な水域を管理する水域管理者60が、サービスプロバイダ10が提供するサービスを利用している。
【0016】
SOLAS船以外にも衝突予防手段を講じるべき船舶には、プレジャーボートのような個人用途の小型船舶に限らず、漁船、作業船、警戒船等の業務船もある。別の観点からは、船舶動静情報は、保険の事故検証や料率算定においても検証データや統計データとしても利用できる。さらに、港湾においては、過密なスケジュールで出入りする船舶の動静や停泊位置を管理しなければならず、漁業や工事では、船舶同士の衝突だけでなく、定置網や養殖いかだ等の漁業関連設備や工事関連設備等の障害物への衝突も予防する必要がある。このように、船舶動静に関する情報を必要とするステークホルダーは多岐にわたるため、
図2に示すように、サービス利用者として様々な主体が想定されている。
【0017】
サービスプロバイダ10は、外部の情報プロバイダ70からも情報の提供を受けてサービスを提供しており、情報プロバイダ70から提供を受ける情報には、例えば、地図情報、気象情報、船舶動静情報、海難情報等がある。
操船者20は、個人21としてサービスを利用する場合もあるが、運航事業者30に役務を提供する被用者22の場合もある。また、運航事業者30も、工事業者40に対して役務を提供する協力会社(下請)31の場合もある。このようなビジネスモデルの相違によって、サービスプロバイダ10と各利用者との間にはさまざまな契約形態が存在している。
【0018】
[1.2 ネットワーク構成]
[1.2.1 全体構成]
次に、実施形態にかかる船舶動静共有航行支援システムのネットワーク構成について説明する。
図3は、システム全体のネットワーク概要構成図である。船舶動静共有航行支援システムは、主に管理サーバ100の機能によって提供される。管理サーバ100は、インターネットINに接続されており、インターネットプロトコル(IP)によって、船舶動静等の情報を通信端末200及び陸上管理端末300に提供する。通信端末200は、操船者20が船上で使用することが想定されているので、使用場所は海や河川等の水上である。水上では有線のデータネットワークが利用できないので、携帯電話会社や衛星通信会社等の通信キャリア事業者がデータ通信サービスを提供しているキャリアネットワークCNを介して管理サーバ100とのデータ通信を行う。
【0019】
一方、陸上管理端末300は、運航事業者30あるいは工事業者40の管理者が陸上の事務所で使用することが想定されており、インターネットINを介して管理サーバ100とのデータ通信を行う。なお、運航事業者30等の社内ネットワーク上に陸上管理端末300を設置する態様も考えられ、例えば社員情報等を管理する他の社内システム301とデータ連携等を行ってもよい。また、通信端末200と陸上管理端末300とのデータ通信は、長距離無線LAN(Local Area Network)等を利用したプライベートネットワークPNでもよく、プライベートネットワークPNを経由してインターネットINに接続することによって、管理サーバ100にアクセスする構成でも構わない。
【0020】
船舶の動静情報は、後に詳しく説明するようにAIS送受信機800が発するAIS信号に含まれる情報及び、通信端末200の機能によって測位された位置情報に基づいて把握される。ここでAIS送受信機800は、SOLAS、ITU(International Telecommunication Union)、IEC(International Electrotechnical Commission)等の規格に準拠した通信方式やメッセージ形式に従ってAIS情報を送受信する機器である。AIS情報には、船舶の識別符号、船名、位置、針路、速力、目的地などの船舶情報が所定の形式で含まれている。一方、本実施形態における陸上AIS受信装置810及び海上AIS受信装置900は、AIS送受信機800からAIS信号を受信し、所定のデータ形式に変換した上でデータを送信する装置である。
【0021】
[1.2.2 プロトコルスタック]
ここで
図4は、
図3に示した通信機器間の関係を説明するためのプロトコルスタックを示す図である。AIS送受信機800は、ITU-R M.1371やIEC 61993、IEC 62287等で規定された物理層(L1)及びデータリンク層(L2)のプロトコルに準拠した信号を送出し、陸上AIS受信装置810及び海上AIS受信装置900は、AIS送受信機800から受信した信号をこれらのプロトコルに従って解釈する。AIS送受信機800は、アプリケーション層では、グローバル・ポジショニング・システム(Global Positioning System:GPS)等の全球測位衛星システム(Global Navigation Satellite System:GNSS)を用いて生成した自船位置の測位データ及び船舶名やMMSI番号(Maritime Mobile Service Identity)等の自船に関する情報をあわせて他船に送信するとともに、他船から受信した情報をプロッタ等のユーザインターフェイスに表示する。一般的に、米国海洋電子機器協会(National Marine Electronics Association:NMEA)(登録商標)が定めた規格が、船舶の運航に用いられるAISやGPS等のデータの共通フォーマットとして採用されており、測位機器や表示機器とAIS送受信機はシリアル通信プロトコルで通信が行われる。
【0022】
陸上AIS受信装置810は、アプリケーション層で動作する受送信プログラムによって、AIS送受信機800から受信したAISデータをIPネットワーク上で管理サーバ100に送信する。また、海上AIS受信装置900は、AIS送受信機800から受信したAISデータをBLE(Bluetooth Low Energy)(登録商標)で通信端末200に送信する。
【0023】
スマートフォンやタブレット等の通信端末200は、IPネットワーク通信用の無線通信手段として、携帯電話網で提供されるLTE(Long Term Evolution)(登録商標)の他、Wi-Fi(登録商標)通信手段が搭載されている。また、通信端末200は、GPS等や基地局情報等から生成された測位データをアプリケーション(アプリ)上で利用できるように構成されており、BLE通信を介して海上AIS受信装置900から受信したAIS情報と測位情報とをあわせた船舶情報として、IPネットワーク上で管理サーバ100に送信することができる。なお、GPS等の受信手段は、通信端末200に内蔵された機器でもよいし、有線又は無線によって接続した外付けの機器でもよい。
【0024】
管理サーバ100及び陸上管理端末300は汎用的なものでよく、物理層(L1)及びデータリンク層(L2)についても、有線でも無線いずれの通信規格に準拠した構成で構わない。管理サーバ100は、アプリケーション層において、Webサーバ、データベース(DB)、及びAPI(Application Programming Interface)等が稼働しており、通信端末200上や陸上管理端末300をクライアントとするサーバとして機能する。アプリケーション層で用いられるプロトコルは、例えばHTTP等一般に広く用いられているものでよい。
【0025】
なお、AISに用いられるVHFバンドの利用には、送信出力等に応じて免許が必要となるが、Wi-Fi及びBLEでは、技術基準適合証明等がなされた機器を使用する限りは無線局の免許を必要としないアンライセンスバンドが利用できる。LTEバンドのように通信キャリア事業者が提供する通信サービスを利用する場合は、通信キャリア事業者が包括的に取得した免許による周波数帯の利用となる。なお、通信キャリア事業者から提供される通信規格は、本実施形態で例示したLTEに限らず、WiMAX(Worldwide Interoperability for Microwave Access)(登録商標)や5G(第5世代移動通信システム)等の移動体通信ネットワークにおける通信規格や、衛星移動通信におけるデータ通信規格でも構わない。
機器間の無線通信の方式は
図4に示したような形態に限定されるものではなく、電波の到達範囲やライセンスの有無等に応じて適宜選択することが可能である。いずれにしても、管理サーバ100との間でIPネットワーク上におけるデータ送受信が可能であれば、下位層はどのような通信方式でも構わない。
【0026】
[1.2.3 アプリケーションレイヤの機能構成]
図5は、プリケーションレイヤにおける各機器内のコンポーネントを機能ブロックで表した図である。管理サーバ100のクライアントとして通信端末200と陸上管理端末300があり、それぞれの処理能力やネットワーク通信量等の要素を勘案して、サーバ側で行う処理とクライアントサイドで行う処理を適切に分配する構成となっている。本実施形態では、クライアント側で負荷の高い処理を実行し、ネットワーク上のデータ量を抑制するエッジコンピューティングを行う構成としている。
【0027】
なお、クライアントサイドの通信端末200にインストールされたアプリケーションソフトウエアは一般的に「ネイティブアプリ」(本実施形態では略して「アプリ」)と呼ばれており、陸上管理端末300のブラウザ上で提供される機能を実行するアプリケーションソフトウエアは一般的に「Webアプリ」(本実施形態では略して「Web」)と呼ばれている。本実施形態では、アプリケーションソフトウエアによって提供される、ユーザへのデータ提示やユーザからの操作入力を実現する機能を総称して「ユーザインターフェイス」と呼ぶものとする。また、ユーザインターフェイスを提供する各種ハードウエアやソフトウエア等のコンポーネントの総称を「フロントエンド」し、ユーザが直接は操作しないサーバサイドで実行される各種コンポーネントの総称を「バックエンド」とする。本実施形態では、APIによってコンポーネント間を疎結合することにより、フロントエンド及びバックエンドで使用されるプログラム言語やフレームワーク等に拘束されず、拡張性が高いシステムを構成することが可能となっている。
【0028】
以下、各コンポーネントについて、より詳細に説明する。管理サーバ100上には、フロントエンドとバックエンドを接続するサービスを提供するAPIサーバ110と、フロントエンドとしてブラウザ310にサービスを提供するWebサーバ120と、フロントエンドに対してデータ管理や接続機能等を提供するための様々なバックエンドとなる音声サーバ130、データストア140、データベース150及びバックエンドサービス160と、AISデータを受信するAIS受信サーバ170が構築されている。なお、管理サーバ100は、特定のデータセンター内に構築されてもよいし、いわゆるクラウドサービス上で提供されるPaaS(Platform as a Service)上に構築されていてもよい。
【0029】
通信端末200は、測位機能を提供する測位プログラム210及び、ユーザインターフェイス機能を提供するアプリ220を備えており、陸上管理端末300は、ブラウザ310を備えている。アプリ220及びブラウザ310に表示されるマップ情報は、情報提供サーバ700から提供されるマップデータ710に基づいて生成される。マップデータ710は、航海用の海図として作成された海図データでもよいし、陸上と海上の情報を含む地図データであってもよく、地理情報システム(Geographic Information System:GIS)データとして利用可能なデータを用いればよい。GISデータを記述するための地理空間データ交換フォーマットとして、例えば、ジオメトリ (形状)やフィーチャー (地物)をひとまとまりのオブジェクトとして記述するGeoJSONを用いることができる。マップデータ710は、予め情報提供サーバ700から通信端末200や陸上管理端末300にダウンロードされてもよいし、現在位置に応じて適宜読み込むような態様でもよい。
【0030】
陸上AIS受信装置810上の受送信プログラム811は、AIS送受信機800から受信したAISデータを管理サーバ100に対して送信し、海上AIS受信装置900上の受送信プログラム901はAIS送受信機800から受信したAISデータを通信端末200に対して送信する。
管理サーバ100上のAPIサーバ110は、ユーザインターフェイスであるアプリ220及びブラウザ310に対してバックエンドサービスへ接続するためのAPIを提供するサーバであり、
図5には、本実施形態で提供されるAPIのうち代表的なものを記載している。AISコントローラ111は、AIS受信サーバ170によって受信したAISデータをデータストア140及びデータベース150に保存するAPIである。プロットコントローラ112、事業者コントローラ113、操船者コントローラ114、画像コントローラ115、船舶コントローラ116、及び航海コントローラ117は、アプリ220及びブラウザ310における操作に基づくデータの登録及び削除や、アプリ220及びブラウザ310に対するデータの提供等を行うAPIである。
【0031】
Webサーバ120は、ブラウザ310上で機能を実現するWebアプリを提供するサーバであり、本実施形態で提供される機能には、後に詳しく説明するように、仮想無線機能121、プロット作成機能122、情報管理機能123、マップ表示機能124、及び履歴出力機能125等がある。
音声サーバ130は、仮想無線機能を提供するサーバであり、本実施形態では、ハイパーテキスト・トランスファー・プロトコル(Hypertext Transfer Protocol:HTTP)によってクライアントとサーバ間の高速に接続するWebSocketを通信プロトコルとして用いている。
【0032】
データストア140は、一般的にリアルタイムデータベース、NoSQLクラウド データベース、クラウドデータストア等と呼ばれるリアルタイムデータストアであり、Webサーバ120、アプリ220、ブラウザ310におけるフロントサイドでリアルタイム性の高い処理を行うためのデータを保管するために用いられる記憶手段であり、データベース150は、後に構成例を詳しく説明するリレーショナルデータベースとして構成された記憶手段である。バックエンドサービス160は、データストア140やデータベース150へのアクセスや認証処理等のバックエンドサービス機能を提供する。
AIS受信サーバ170は、陸上AIS受信装置810の受送信プログラム811からAISデータを受信するサーバであり、陸上AIS受信装置810との間にいてUDP(User Datagram Protocol)接続される。
【0033】
通信端末200が備える測位プログラム210は、当該通信端末200に搭載されたGPS等のGNSSアンテナで受信した測位信号や基地局からの信号に基づいて位置情報データを生成する。アプリ220は、測位プログラム210が生成した位置情報データに基づいて自船位置情報データを生成して送信する位置情報受送信機能221を備えており、当該アプリ220内においては自船の位置情報として用いられ、管理サーバ100に送信された自船位置情報データは、他の通信端末200上のアプリ220おいては他船の船舶動静情報として用いられる。位置情報受送信機能221は、自船の位置情報に加えて、位置情報の差分から船速及び針路を算出して、管理サーバ100に送信する機能も備えている。
また、アプリ220は、後に詳しく説明するプロット作成機能222、情報管理機能223、マップ表示機能224、衝突予測機能225、履歴出力機能226、及び仮想無線機能227等を備える。
【0034】
[2 データ構成]
[2.1 ユースケース]
本実施形態に係るデータ構成を説明するにあたって、
図6を参照しながら、船舶動静共有航行支援システムのユースケースについて説明する。ユースケースにおいては、ユーザとして、水上で操船を行う操船者と、陸上で運航を管理する管理者とを想定する。操船者には、「船舶動静を共有する」、「情報を管理する」、「衝突を予測する」、「他船に連絡する」、「航海情報を記録する」、及び「プロットを作成する」、というユースケースが想定されている。一方、管理者は操船を行わないので、操船者と比較して「衝突を予測する」というユースケースが除外されている。
【0035】
「船舶動静を共有する」では、自船及び他船の位置、船速、針路等の、船舶の動きあるいは停船状態に関する動静情報をマップ上で表示することによって共有する。「情報を管理する」では、操船者や企業の名称及び連絡先等のアカウント関連の基本情報や、船舶の名称や船舶登録番号等の船舶関連の静的情報をシステム上で管理する。「衝突を予測する」では、自船及び他船の相対関係から衝突可能性のある船舶の位置や距離及び衝突までの予測時間等に関してシステムから警告を受ける。「他船に連絡する」では、船舶間において衝突を回避するための音声コミュニケーションを図る。そして「プロットを作成する」では、何らかの地点あるいは領域としてマップ上で情報を提供するための設定を行う。プロットとしては、例えば、操船者に対して警告や注意を促す情報や、操船にとって有益な情報、海難時に救助を求める情報等が想定される。
【0036】
ここで
図7は、操船者が使用する通信端末200上のアプリ220によって表示されるトップ画面のイメージ図である。マップ上には、船舶の位置を示すアイコン及び船舶名、プロットの位置及びプロット名・エリア名、並びに海図図式(記号)及び名称等が表示されている。
船舶を示すアイコンのうち、図中SI1は自船を表す。自船アイコンSI1上には、後に詳しく説明する仮想無線の使用状態を示すアイコンが表示されている。他船を示すアイコンとして、停船状態を示すSI2及び航行中であることを示すSI3が表示されている。他船アイコンSI2及びSI3は、いずれも赤と緑の点を舷灯に見立てた図形が船側に配置されることによって、他船の左舷及び右舷を直感的に把握可能な図形として操船者に対して提供される。また、停船アイコンSI2と航行中アイコンSI3の舷灯を比較すると、航行中アイコンSI3は灯火されている態様の図形となっている。これにより、航行中の他船の存在を直感的に把握することが容易になる。また、航行中アイコンSI3の船首方向には、船速及び針路に応じた速度ベクトル線が表示され、船尾方向には航跡線が表示されている。これらの情報は、自船及び他船に対して選択的に表示可能であり、これにより、船舶の動きを把握することが容易となる。
【0037】
図7に示すように、画面上には、ユーザからの操作を受け付ける各種のボタンが表示されている。具体的には、メニュー表示を指示するメニューボタンB1、プロット作成メニューを表示するプロットボタンB2、仮想無線用のパネル表示を指示する仮想無線ボタンB3、自船の現在位置をマップ上の中央に移動させることを指示する現在位置ボタンB4、衝突予測に関する情報をユーザに示すレーダーモード画面への遷移を指示するレーダーモードボタンB5、及び自船の操船開始や終了を指示する操船ステータスボタンB6が表示されている。なお、操船ステータスボタンB6は、操船中においては異なる色等の特定の態様で表示するようにしてもよい。
【0038】
[2.2 データベースのテーブル構造]
ここで、上述した機能を提供するために構成されたデータベースのテーブル構造について説明する。データベース150は、リレーショナルデータベースであり、操船者や船舶等が識別子(ID)により一意に特定され、以下に説明するように各種の情報と紐づけられている。
【0039】
[2.2.1 アカウント関連のテーブル構造]
図8は、アカウント関連のテーブル構造とリレーションの一例を示す図である。アカウントとしては、
図2において示したように、操船者20、運航事業者30、工事業者40、保険会社50、及び水域管理者60のそれぞれに発行されうる。本実施形態では、操船者20個人別の操船履歴の管理を行うために、操船を行う自然人別にアカウント(操船者ID)が発行される。操船者20を被用者として管理する運航事業者30や、契約上の権利義務に基づいて操船者20の情報を取得する保険会社50、法令上や契約上の権利義務等に基づいて操船者20の操船状況を監視する水域管理者60は、事業者別にアカウント(事業者ID)が発行される。また、複数の事業者による共同事業体(JV)あるいは単独の企業としての工事業者40が複数の運航事業者30を協力会社として業務を行う工事等の事業は、有期限のプロジェクトとして管理するものとし、プロジェクト別にアカウント(プロジェクトID)が発行される。これら事業者IDやプロジェクトIDは、操船者IDに紐づけられて、操船者が所属するグループとして識別する管理にも用いることができる。
【0040】
図8に示すように、「操船者テーブル」、「事業者テーブル」、及び「プロジェクトテーブル」それぞれにおいて、操船者ID、事業者ID、プロジェクトIDによって識別される主体の基本情報が管理されている。プロジェクト毎に参画する事業者を特定して管理するために、プロジェクトIDと事業者IDとを紐づけて管理する「プロジェクト事業者テーブル」が設定されている。「プロジェクト事業者テーブル」には、さらに、プロジェクトにおいて稼働する操船者や船舶を特定して管理するための「プロジェクト操船者テーブル」や「プロジェクト船舶テーブル」もIDによって紐づけられている。
【0041】
操船者IDには、操船者の船舶免許に関する情報を管理する「免許テーブル」が紐づけられており、免許番号や有効期限等の管理を行うことができる。また、操船者IDに紐づけられた「操船履歴テーブル」は、操船毎の開始・終了時刻や距離を記録しており、事業者IDやプロジェクトIDによって操船した事業を特定できる他、船舶ID、操船目的ID、及び役割ID等によって、操船した船舶や役割等を特定することによって乗船履歴としての管理を行うことができるようになっている。
【0042】
[2.2.2 船舶関連のテーブル構造]
引き続き
図9は、船舶関連のテーブル構造とリレーションの一例を示す図である。船舶は船舶IDによって一意に特定されており、船名や船舶番号等の静的な情報の他、本実施形態では、マップ上で船舶の位置を公表するか否かを示す「位置公表フラグ」も設定されている。これにより、位置を公表しない船舶については、船舶の衝突予防に必要な範囲においてマップ上に位置が表示される制御が可能となっている。
【0043】
船舶IDに紐づけられた「航海履歴位置テーブル」は、目的地、緯度、経度、船首方位、針路、船速、動静判定等の航海における動的な情報をデータ取得日時とともに履歴として管理するテーブルであり、操船者ID、事業者ID、プロジェクトID、操船履歴ID等とも紐づけられることによって、操船者や事業との関連も管理することができるようになっている。
【0044】
また、船舶の属性情報が管理されており、船種IDや船舶サイズIDによって正規化されている。本実施形態では、マップ上に表示する船舶のアイコンは、
図9に貨物船の例を示すように、船種を連想できるイラストが画像データとして船種別に用意されている。貨物船やタンカー等の一般的な船種に限らず、自社船であることを示す「自社船」アイコンや、通信端末200が搭載された船舶であることを示す「アプリ船」アイコン等があってもよい。本実施形態では、後に詳しく説明するように、これらの船種別アイコンを通常の表示態様としつつ、マップの表示範囲やモードに応じて異なる表示態様の船舶アイコンが用いられる。
また、マップ上の縮尺と船舶の大きさとの相対的な関係が維持されるように船舶アイコンの表示サイズを制御する構成となっており、
図9に例示するように、「船舶サイズテーブル」で管理される船舶の全長及び型幅を示すデータに基づいて、アイコンの表示サイズを決定することができる。
【0045】
ここで
図10は、操船者情報管理画面の例であり操船者の基本情報と合わせて、船舶免許に関する情報を参照及び入力するユーザインターフェイスとなっている。ここで入力されたデータは、
図8に例示した「操船者テーブル」や「免許テーブル」に格納される。免許証を撮影した画像ファイルは、「免許テーブル」においては画像IDで特定されるようになっている。
【0046】
次に
図11は、船舶情報管理画面の例であり、船舶の基本情報と合わせて、船舶サイズや船種に関する情報を参照及び入力するユーザインターフェイスとなっている。また、船舶の外観を撮影した画像や船舶検査証の画像も登録できるようになっており、ここで入力されたデータは、
図9に例示した「船舶テーブル」、「船種テーブル」、及び「船舶サイズテーブル」等に格納される。
【0047】
図12は、プロジェクト情報管理画面の例であり、プロジェクトの基本情報と合わせて、プロジェクトに参加している事業者の一覧及び、事業者別の基本情報や当該プロジェクトに割り当てられている操船者と船舶に関する情報を参照するユーザインターフェイスとなっている。プロジェクトIDによって識別されるアカウントにおいては、「プロジェクトテーブル」で管理されるプロジェクトの基本情報を変更することは認められているが、事業者によって割り当てられた操船者や船舶に関する情報については参照しか認められていない。
【0048】
[2.2.3 プロット関連のテーブル構造]
次に、
図13は、プロット関連のテーブル構造とリレーションの一例を示す図である。プロットはプロットIDで識別され、プロットの種類を示すプロットカテゴリ、プロットによって情報を共有すべき対象物が存在する位置情報、及びプロット対象物の画像ファイルが紐づけられている。船舶アイコンと同様に、プロットにおいてもプロットカテゴリに応じたアイコンが画像として用意されており、
図13に例示するように、「灯台」のような海図記号に対応したアイコンや、「浮遊物」のような一時的な状況を示すアイコンがある。
【0049】
具体的には、プロットの種類によっては、海図記号やマリーナの位置のように恒常的な対象物を示す揮発性の低い情報もあるが、浮遊物や取締船のような一時的に存在する対象物を示す揮発性の高い情報もある。強風や波浪のような気象・海象も比較的短期間で変動する事象である。一方、工事エリアのように、比較的長期間ではあるものの、期間が限定された対象もある。すでにその位置に存在しない対象物や、定められた期間が終了した事象がマップ上にいつまでも表示されると、操船者に無用な警告を促してしまい、かえって安全な操船の妨げとなる場合もある。本実施形態では、「プロットカテゴリテーブル」の1項目として、プロットの属性に応じた表示期限の有無や時間の長さ等を示す表示期限フラグを設け、「プロットテーブル」には表示期限となる日時が登録されるようになっている。表示期限はプロット作成時にユーザが具体的に指定してもよいし、表示期限フラグの種類に応じて自動的に算出されてもよい。
【0050】
また、「プロットテーブル」では、位置情報からなるプロットポイントが一点で特定されるプロットか、複数のプロットポイントで特定されるプロットかを識別する「プロットタイプフラグ」が設定されており、複数のプロットポイントで特定される場合には、
図13に例示した「定置網」と記載された図形のように、複数のプロットポイントを頂点とした直線で構成されるベクトル図形としてマップ上に表示可能となる。なお、ベクトル図形は、複数のプロットポイントを制御点とする曲線であってもよい。
【0051】
[3 船舶動静共有航行支援システムの機能]
以下、本実施形態に係る船舶動静共有航行支援システムの主要な機能について説明する。
[3.1 マップ表示機能]
[3.1.1 レイヤ構造]
図14は、通信端末200及び陸上管理端末300において表示されるマップ表示画面のレイヤ構造について説明する図である。ベースとなるマップデータが表示されるマップレイヤの上層には、所定の項目に関する統計情報が視覚的にヒートマップとして表示されるヒートマップ表示エリアがあり、複数のプロットポイントで特定されたエリアがベクトル図形として表示されるエリア表示レイヤがあり、その上層に一点のプロットポイントで特定されるプロット情報アイコンがラスタ画像として表示される情報アイコン表示レイヤがある。さらにその上層には、船舶アイコン表示レイヤ、船名表示レイヤ、航跡表示レイヤ、及び速度ベクトル表示レイヤが積層されており、船舶のみ表示する場合の他に、航跡及び速度ベクトルを選択的に表示可能となっている。レーダーモード画面の選択時においては、船舶の衝突を予防するための注意及び警告領域を船舶アイコンの上に表示する警告表示レイヤがあり、さらにその上層には、船舶上の通信端末200における仮想無線の状態を示す無線アイコン表示レイヤが配置されている。
【0052】
本実施形態では、
図15に例示するように、マップの縮尺に応じて船舶アイコンの表示形態を異ならせている。小縮尺で広域マップを表示すると、表示範囲内に多数の船舶アイコンが表示対象船舶となるが、すべてのアイコンを一律に表示すると、アイコンが過度に密集した表示となってしまう。そこで、航行中の船舶は上述したイラストの船種別アイコンで表示するが、停泊中の船舶については粒アイコン(円形)で表示するとともに、船舶アイコンが重複する場合には船名のテキスト表示数を制限することによって、表示される情報量の削減を図っている。
【0053】
中縮尺で中域マップを表示する場合は、いずれの表示対象船舶も船種別アイコンを用いて表示されるが、上述のように、航行中の船舶には舷灯を灯火した態様のアイコンが用いられ、停泊中の船舶に舷灯を消灯した態様のアイコンが用いられる。これらの船種別アイコンは、マップの縮尺に応じて、データベース150に登録された船舶サイズに対応した大きさに調整されて表示される。
【0054】
大縮尺で詳細マップを表示する場合には、船舶の位置情報の変化量が大きくなるので、船種にかかわらず、単純な五角形や三角形等のベクトル図形を組み合わせたポリゴンとして生成されたポリゴン船舶アイコン表示される。これにより、船舶アイコン表示にかかる処理負荷を低減し、船舶の位置情報の変化に応じたスムーズなマップ表示を可能としている。ポリゴン船舶アイコンも、船種別アイコンと同様に、マップの縮尺に応じて、データベース150に登録された船舶サイズに対応した大きさに調整されて表示される。
【0055】
ここで
図16は、
図14において例示したレイヤ構成によって画面上に生成されたマップ表示のイメージ図である。この例では、船舶アイコンと合わせて船名がテキスト表示されており、さらに、航行中の船舶アイコンの船首方向に速度ベクトルが表示されているが、いずれの船舶に関しても航跡は表示されていない。すなわち、個別情報の表示の要否や表示態様についてはレイヤ別に制御できるようになっており、
図14に示した航跡表示レイヤの表示をオフにした場合の例である。
船舶アイコンに関連付けて船舶の画像及び船名や動静情報等が表示されており、「浮遊物」アイコンに関連付けて画像及びコメントが表示されているが、これらの詳細情報はアイコンをタップ等する操作によって表示のオン・オフを選択できるようにしてもよい。
【0056】
ところで、
図16において点線で表示されている船舶アイコンSIdは、船舶位置を非公表としている船舶を意味している。漁船やプレジャーボート等の操船においては、自船の位置を公表されることを望まない操船者も存在するが、船舶の衝突を予防するためには衝突可能性のある他船の位置や動静を監視する必要がある。海上衝突予防法においては、「互いに他の船舶の視野の内にある船舶の航法」として、船舶の種類や状態に応じて、操船時にとるべき動作が定められている。そこで本実施形態では、自船から目視可能と考えられる位置に存在する船舶についてはマップ上に表示するが、目視範囲外に位置する船舶アイコンは表示しない制御を行う。なお、目視可能な距離としては、現実的には操船席の海面からの高さや気象・海象によっても異なるが、例えば、COLREGS及び海上衝突予防法においてマスト灯の明かりが視認できる距離として規定されている6海里(約11km)程度に設定してもよい。
【0057】
また、AISで動静情報が送信される間隔は、船速等の状態に応じて2秒から3分までの幅が定められているが、この時間間隔を超えて動静情報が更新されない場合には、当該船舶のAISデータを正常に受信できていない可能性がある。AISデータが正常に受信されている場合には「停泊もしくは錨泊中で、3ノット以上で動かない」状態でも3分間隔で状態が送信されるので、航行中の船舶から3分を超えてデータが更新されない場合には、当該船舶はすでに他の位置に移動してしまっている、あるいは、何らかの理由により誤ったデータが記録された可能性がある。そこで本実施形態では、マップ上に表示すべき他船として抽出された位置情報のうち、7分以内に取得されたデータであれば通常のアイコン表示を行うが、7分から10分の間は疑わしい情報であることを操船者に提示するためにグレー(灰色)のアイコンで他船を表示し、10分を超える場合にはマップ上に表示しないものとしている。なお、かかる判定基準は必ずしも7分や10分に限るものではなく、これより短い時間でも長い時間で設定しても構わない。
【0058】
[3.1.2 船舶アイコン表示可否判定]
図17は、船舶アイコンの表示可否について判定するフローチャートである。処理が開始されると、まず自船の位置情報がデータストア140から取得され(S101)、次いで、画面の表示範囲内に存在する他船情報がデータストア140から取得される(S102)。ここで情報が取得された船舶数に対して、以下のステップS103からS106の処理が繰り返し実行される。
【0059】
まず判定対象船舶の位置公表フラグを参照し、位置を公表しない船舶であると判定された場合は(S103;No)、次に、当該船舶が自船の位置から目視可能距離に存在するか否かが判定される(S104)。ここで当該他船が目視可能距離の範囲には存在しないと判定された場合は(S104;No)、当該他船の船舶アイコンはマップ上に表示されない(S105)。
【0060】
一方、ステップS104の判定において自船から目視可能距離に存在すると判定された場合(S104;Yes)あるいはステップS103において位置を公表すると判定された場合(S103;Yes)は、次に、当該他船の位置情報を取得した時刻を参照し、10分以内に取得されたか否かが判定され(S106)、10分以内に取得された位置情報ではないと判定されると(S106;No)、当該他船は非表示となる(S105)。他方、10分以内に取得された位置情報であると判定された場合には(S106;Yes)、次に、7分以内に取得された位置情報であるか否かが判定される(S107)。ここで、位置情報を取得してから7分以内ではないと判定された場合は(S107;No)、当該他船はグレー(灰色)のアイコンで表示され(S108)、7分以内であると判定された場合は(S107;Yes)、当該他船は通常のアイコンで表示される(S109)。
【0061】
[3.1.3 ヒートマップ]
図18は、ヒートマップを表示した例であり、マップ上には、指定された情報に対応した数値に応じた大きさや色の円がヒートマップとして表示されており、その他に、船舶アイコンや、無線アイコン、情報アイコン等が表示されている。この図に示す例では、情報アイコンとして、海図情報としての航路が表示されており、ヒートマップの円は、所定期間における漁船の量を示している。海上交通安全法では、一定の大型船には航路航行義務が定められているが、漁労中の漁船については航法の例外が定められているので、漁船の通航量について傾向を把握する目的で表示されている。なお、ヒートマップ表示対象とする情報の種類、量、期間等については任意に設定可能であり、表示形態についても、円に限らず、多角形や線等を用いてもよい。
【0062】
[3.2 衝突予測機能]
[3.2.1 画面イメージ]
次に、衝突予測機能について説明する。
図19は、通信端末200に表示される衝突予測画面のイメージ図である。この図に例示する画面は、本実施形態では「レーダーモード」と名付けられており、船舶レーダーの表示画面と同様に、自船を中心とした円上に方位を示す数値を配し、あわせて他船の動静情報をアイコンとして表示するモードである。
図19の例においては、レーダーモード画面における他船は、船種や船舶サイズに対応したアイコンではなく、円や三角形等の単純な図形と速度ベクトルで表示されている。
【0063】
図19に示す例では、自船の針路である225°を上方に配置したコースアップ表示となっているが、北(0°)を上として表示するノースアップ表示への変更を指示するノースアップボタンBnuが設けられている。自船アイコンの近傍には、船舶名並びに、自船の船速及び針路がテキスト表示されている。
また、自船の座標を中心として、警告領域を意味する第1の扇形F1及び注意領域を意味する第2の扇形F2の2種類の扇形が表示されている。第1の扇形F1は現在の船速及び針路を維持した場合に所定時間(第1の時間)で到達する距離に相当する長さを半径とし、自船の針路から±5°の方角に広がる中心角10°の扇形である。この第1の扇形F1は、警告対象を検出するための警告領域として用いられる。第1の時間は、例えば、5分や3分等であり、自船と他船との関係を認識し、自船が針路を保持するか避航動作を行う必要があるか判断するために適切な時間が設定される。
【0064】
このように針路からある程度の広がりを持った領域を、所定時間以内に当該船舶が航行する可能性の高い領域と仮定して衝突を予測することにより、他船の動静の他、波や風等の外乱の影響による針路のずれも考慮した衝突予測を行うことができる。なお、半径の長さや針路からの角度は必ずしも上述した数値に限られるものではなく、気象や海象に応じて調整してもよいし、自船の船種や、現在船速、運動性能等に応じて調整してもよい。さらに、操船者が任意に設定できるようにしてもよい。
【0065】
本実施形態では、警告領域すなわち第1の扇形で規定される範囲内に他船が存在する場合及び、自船の警告領域と他船の警告領域が重複する場合であって所定の要件を満たすときに、これらの他船を警告対象船として画面に表示する。このように警告対象船が存在する場合には、警告領域は、例えば赤色等の一般的に警告を連想させる警告色を用いて表示され、同様に警告対象船も警告色で表示される。
【0066】
第2の扇形F2は現在の船速及び針路を維持した場合に、所定時間(第2の時間)で到達する距離に相当する長さを半径とし、自船の針路から±112.5°の方角に広がる中心角225°の扇形である。この第2の扇形F2は、注意対象を検出するための注意領域として用いられる。第2の時間は、例えば3分や1分30秒等であり、自船が針路を変更した場合に衝突の危険が発生する可能性がある船舶(潜在的警戒対象船)の存在や、自船の動きを考慮せずに航行しており、衝突を回避するために自船が協力動作を行わなければならない可能性がある船舶(要協力動作対象船)の存在に対して注意を払うことを促すために適切な時間が設定される。
【0067】
COLREGS及び海上衝突予防法においては、舷灯の照射範囲は船首方位から左右それぞれ112.5°と規定されており、当該角度が他船から自船の右舷及び左舷として認識される範囲に相当する。そして「互いに他の船舶の視野の内にある船舶の航法」として、「二隻の動力船が互いに進路を横切る場合において衝突するおそれがあるときは、他の動力船を右舷側に見る動力船は、当該他の動力船の進路を避けなければならない」と規定されている。他船の左舷(赤色の舷灯)を見る船舶側が避航船となり、原則的に避航動作を行う必要があるが、避航船の動作のみでは衝突を避けることができないと認められる場合には、衝突を避けるための協力動作を行う必要がある。従って、自船が保持船である場合でも他船の避航動作に関する注意を行うべき領域と仮定した注意領域を表示することによって、操船者に対して他船との衝突を回避するためのサポートを行うことが可能となる。
【0068】
なお、第1の扇形と同様に、半径の長さや針路からの角度は必ずしも上述した数値に限られるものではなく、気象や海象に応じて調整してもよいし、自船の船種や現在船速や運動性能等に応じて調整してもよい。操船者が任意に設定できるようにしてもよい。
本実施形態では、注意領域すなわち第2の扇形で規定される範囲内に他船が存在する場合は、これらの他船を注意対象船として画面に表示する。このように注意対象船が存在する場合には、注意領域は、例えば黄色や橙色等の一般的に注意を連想させる注意色を用いて表示され、同様に注意対象船も注意色で表示される。
警告対象にも注意対象にも該当しない非注意対象船については、青色や緑色等の寒色系の非注意色で表示され、非注意対象船しか周囲に存在しない場合には、自船の警告領域及び注意領域についても非注意色で表示される。
【0069】
[3.2.2 警告表示処理]
図19に例示されている他船や警告領域及び注意領域を表示する処理の詳細について、以下、
図20から
図22のフローチャートを参照しながら説明する。
図20は、レーダーモード表示にかかる処理を示すフローチャートである。この処理は、本実施形態ではアプリ220側で実行されるが、管理サーバ100側で実行される形態であっても構わない。
【0070】
処理が開始されると、自船の位置情報、船速、針路等の船舶情報がデータストア140から取得され(S201)、続いてマップの表示座標系における自船の位置座標及び速度ベクトルが算出され(S202)、自船の位置座標を中心として上述した自船の警告領域及び注意領域が算出される(S203)。次いで、一定範囲内に存在する他船情報がデータストア140から取得される(S204)。一定範囲としては、例えば緯度0.1°(約11km)相当の範囲や、画面への表示範囲等、適宜設定が可能であってもよい。ここで情報が取得された船舶数に対して、以下の警告対象船抽出処理(S210)及び注意対象船抽出処理(S220)が繰り返し実行される。
【0071】
図21は、警告対象船抽出処理を示すフローチャートである。まず判定対象船が自船の警戒領域内、すなわち第1の扇形として算出された領域内に位置するか否かが判定され(S211)、警告領域内と判定された場合は(S211;Yes)、当該他船は警告対象(警告対象船)であることを示すアイコンで表示され(S212)、算出された自船から警告対象船までの距離及び操船者に対して警告を促すテキストメッセージを表示する処理が行われる(S213)。そして、警告色で自船の第1の扇形が表示され(S214)、処理は終了する。
【0072】
ステップS211において判定対象船が自船の警戒領域内には位置しないと判定された場合は(S211;No)、次に、判定対象船の警告領域が自船の警告領域と重複するか否か判定される(S215)。
図19の例では、「X丸」の警告領域が自船の警告領域と重複している。ここで、判定対象船の警告領域が自船の警告領域と重複すると判定されると(S215;Yes)、当該他船が接近中かどうか判定される(S216)。警告領域が重複していても針路が交差しない場合には、当該他船は自船から遠ざかっているので警告する必要はない。また、針路が交差する予定であっても相当時間先である場合に警告すると、警告の効果が薄れてしまう可能性もある。そこで、当該他船が接近中であると判定された場合には(S216;Yes)、一定時間以内に交差するか否か判定され(S217)、一定時間以内である場合には(S217;Yes)、交差までの予測時間と警告を促すテキストメッセージが表示され(S218)、処理はS214の処理に移行して、警告色で自船の第1の扇形が表示される。
ステップS215、S216、及びS217の判定結果がいずれもNoである場合には、当該他船が現段階では警告対象として表示する必要がないので、非警告色で自船の第1の扇形が表示され(S219)、処理は終了する。
【0073】
図22は、注意対象船抽出処理を示すフローチャートである。処理が開始されると、判定対象の船舶がステップS210で警告対象船として処理されたか否か判定され(S221)、すでに警告対象船となっている場合には(S221;Yes)、注意対象船抽出処理は終了する。一方、警告対象船でないと判定された場合には(S221;No)、当該船舶が自船の注意領域すなわち第2の扇形内に位置するか否かが判定される(S222)。ここで、注意領域内であると判定された場合は(S222;Yes)、当該船舶を注意対象船としてのアイコンで画面に表示する処理が行われ(S223)、算出された自船から注意対象船までの距離及び操船者に対して注意を促す表示する処理が行われる(S224)。そして、注意色で自船の第2の扇形が表示され(S225)、注意対象船抽出処理は終了する。
ステップS222の判定において注意領域外であると判定された場合は(S222;No)、当該船舶を非注意対象船としてのアイコンで画面に表示する処理が行われ(S226)、非注意色で自船の第2の扇形が表示されて(S227)、注意対象船抽出処理は終了する。
【0074】
上記の例では、衝突予測機能は操船者20が使用する通信端末200において実行されるが、変形例として、運航事業者30が陸上から自社船の航行状況を監視する場合に、陸上管理端末300のブラウザ上でリアルタイムの衝突予測を表示する態様や、保険会社50が契約船舶に関する事故の検証する場合等において、特定の時点における衝突予測の状況を再生表示する等の態様があってもよい。あるいは、輻輳海域の管制を行う管理者に対して、船舶の衝突が予測される態様を提示するために用いられてもよい。また、上記の例では、警告や注意を促すメッセージはテキスト表示であるが、図形アイコンであっても、音声メッセージであっても構わない。
【0075】
[3.3 仮想無線機能]
次に、仮想無線機能について説明する。本実施形態における仮想無線は、SOLAS及び船舶安全規則において規定されている国際VHFと類似した双方向音声通信を実現する機能であり、船舶動静共有航行支援システムの利用者間において、通信端末200あるいは陸上管理端末300が標準的に備えるマイクやスピーカ等の音声処理デバイスとIP通信機能を利用してIPネットワーク上で半二重通信を可能とするものである。
【0076】
[3.3.1 仮想無線機能の画面イメージ]
図23は、仮想無線の機能を使用者に提示する画面イメージを示す図である。通信端末200に表示された画面上の仮想無線ボタンB3を押下すると、仮想無線操作パネルTPが表示される。仮想無線機能においても国際VHFと同様に、通話したい人が無線機のPTTボタンBpttを押下している間は音声を送信でき、PTTボタンBpttを押していない場合は受信待機状態となるプッシュ・トゥ・トーク (Push to Talk:PTT)方式で通話が行われる。半二重通信では、PTT発話者外の聴取者は、PTTボタンを押下している者(PTT発話)のみ発話が可能であり、その他のユーザは聴取のみ可能(PTT聴取)となって、PTT発話者がPTTボタンを開放するまで、PTTボタンの押下や発話ができない。仮想無線操作パネルTP上の通話状態を示すステータスランプSPは、待機状態においては灰色で表示されているが、PTT発話時には緑色で表示され、受信時には赤色で表示される。
【0077】
また、国際VHFにおいては、チャネル16(156.8MHz)が、遭難安全・呼出し専用の共通チャネルとなっており、当該チャネルで他船を呼び出した後に他のチャネルに移動して直接の通話を行う。仮想無線においても同様の運用が想定されており、チャネル番号をテンキーで入力した後にPTTボタンを押下することによって、変更後のチャネルによる音声の送受信が可能となる。仮想無線操作パネルTPには、通話が終了し、チャネル16を聴取する状態に移動するためのチャネル16ボタンBc16も設けられている。
【0078】
船舶アイコン上には、アプリ220が起動された通信端末200を搭載している船舶における仮想無線の状態を示す無線アイコンが表示されており、待機状態を示す無線アイコンTI1及び通話状態を示す無線アイコンTI2は、アイコンの色によって区別されている。例えば待機状態を示す無線アイコンTI1は灰色で表示され、通話状態を示す無線アイコンTI2は緑色で表示されてもよい。
【0079】
国際VHFは最大出力電力が25Wであり、通信距離は50~80kmが目安となっているが、小型船舶等が主に使用する出力電力5Wの無線機では、通信距離は10~30kmが目安となっている。仮想無線はIPネットワーク上で実現される通信であるため、出力電力や通信距離の制約がなく、遠隔地間の通話も可能である。しかしながら、自船の航行に影響を及ぼすことがない遠隔地にある船舶からの通信を受信すると、混乱が生じる可能性がある。そこで本実施形態では、船舶間の通信に用いる仮想無線は衝突回避に必要な距離に限定することによって、かかる混乱が生じないようにしている。衝突回避に通信が必要な距離としては、例えば出力電力5Wの無線機の通信距離に準じて、半径10kmの範囲としてもよい。
【0080】
[3.3.2 仮想無線機能に関する処理]
以下、
図24及び
図25に示すシーケンス図を参照しながら、仮想無線機能に関する処理について説明する。
図24は、接続から待機中の処理を示すシーケンス図である。仮想無線は、通信端末200に搭載されたアプリ220が、管理サーバ100に構築されている音声サーバ130に接続することによって実現される。音声サーバ130は、データストア140を用いてアプリ220毎の接続状態等を管理する。本実施形態では、音声サーバ130で用いる通信プロトコルとして、上述の通りWebSocketを用いており、データストアとしては、インメモリベースのキー・バリュー・ストア(Key-Value Store:KVS)であるRedisを用いることにより処理を高速化している。なお、通信プロトコルやデータストアの方式はこれらに限定されるものではない。
【0081】
国際VHFのチャネルは周波数で特定されるが、本実施形態では、チャネルidを用いて特定される。アプリ220が音声サーバ130に接続すると(s1101)、アプリ220は設定されているチャネル番号に対応するチャネルidを位置情報及びタイムスタンプとともに音声サーバ130に送信して、当該チャネルによる参加を要求する(s1102)。音声サーバ130は、データストア140に対して、いったん登録されているチャネルを消去する(s1103)。なお、この時点で受信している音声があれば受信を停止する。次いで、現在設定されているチャネルidを、位置情報及びアプリ220と接続しているソケットを特定するソケットidとともに送信して追加し(s1104)、期限が設定されたタイムスタンプをセットする(s1105)。音声サーバ130は、この一連の処理を行った後に、アプリ220に対してチャネルidによる参加の通知を行う(s1106)。この図においてチャネル設定に関するアプリ220側の処理は省略されているが、起動時には初期状態としてチャネル16に設定されており、ステップs1102ではチャネル16に対応するチャネルidが送信される。その後、仮想無線操作パネルTPの操作に基づいてチャネルが変更された際には、変更後のチャンネル番号に対応するチャネルidが送信される。
【0082】
アプリ220は、例えば10秒毎等の一定周期で現在位置を音声サーバ130に通知することによって、データストア140に記憶される位置情報を更新し続ける。より具体的には、チャネルid、位置情報、及びタイムスタンプがアプリ220から通知され(s1107)、音声サーバ130は、チャネルid、ソケットid、及び位置情報をデータストア140に追加し(s1108)、期限付きのタイムスタンプをセットする(s1109)。音声サーバ130は、この一連の処理を行った後に、アプリ220に対して位置情報の通知に対する応答を行う(s1110)。ステップs1107からs1110の処理は、アプリ220が終了されるまで(s1111)繰り返される。
アプリ220が終了されるとタイムスタンプが更新されないので、音声サーバ130はタイムスタンプの期限切れを認識すると(s1112)、データストア140からチャネルを消去して(s1113)、ソケット接続が切断される。
【0083】
図25は、PTT通話時の処理を示すシーケンス図である。この図では、発話を行うアプリを220Aとし、音声通信を聴取する側のアプリを220Bとしている。アプリ220Bは一つのみ記載されているが、複数であっても動作は同じである。
アプリ220AのPTTボタンBpttが押下されると(s1201)、アプリ220Aは音声サーバ130にPTTボタンBpttがオン状態となった旨を通知する(s1202)。この際、アプリ220Aは、チャネルid、位置情報、半径、及び自船の船舶IDを通知する。音声サーバ130は、通知に基づいてセッションルーム作成し(s1203)、発話可能となった旨の通知を、作成したセッションルームidと発話可能な船舶IDとを含めてアプリ220Aに送信する(s1204)。これを受けて、アプリ220AはステータスランプSP及び無線アイコンTIの状態を緑色に変更し(s1205)、通信端末200のマイクをオンにする処理を行う(s1206)。
【0084】
音声サーバ130は、PTT聴取側のアプリ220Bを特定するためにデータストア140に記憶されている船舶情報を検索する(s1207)。上述したように、本実施形態では、発話する船舶を中心として半径10kmの範囲に位置する船舶に対して通話可能としているので、音声サーバ130は、ステップs1202においてアプリ220Aから通知された位置情報及び半径を用いて検索範囲を算出し、かかる範囲に該当する位置情報を備える船舶上のアプリ220Bのソケットidをデータストア140から検索する。
【0085】
音声サーバ130は、ステップs1207において検索されたソケットidを用いて、PTT通話の受信が可能となった旨の通知をセッションルームidと発話する船舶IDとを含めて聴取側アプリ220Bに対して送信する(s1208)。当該通知を受けたアプリ220Bは、ステータスランプSP及び無線アイコンTIの状態を赤色に変更するとともに、PTTボタンBpttの操作を無効にする処理を行う(s1209)。
【0086】
これら一連の処理を経てPTT通話が可能な状態となると、発話側のアプリ220Aから音声サーバ130に音声データが送信され(s1210)、音声サーバ130から聴取側のアプリ220Bに対して音声データがブロードキャストされるようになる(s1211)。そして、音声データを受信したアプリ220Bが音声データを再生することによって(s1212)、アプリ220Aが発した音声通話を聴取することが可能となる。音声データの生成には、Voice over Internet Protocol(VoIP)用のコーデックを利用すればよく、例えば、G711、G722、G726、GSM、iLBC、Speex、Opus等が知られている。あるいは、音声ファイルの圧縮に広く用いられているMP3、AAC、WMA、WAV、AC3、FLAC等を用いてもよい。
【0087】
PTTボタンBpttの押下が開放されてオフ状態となったことを発話側のアプリ220Aが検知すると(s1213)、アプリ220AはPTTがオフ状態となった旨の通知を音声サーバ130に送信する(s1214)。この通知を受信した音声サーバ130は、セッションルームで参加中のアプリ220に対して通話を終了する旨の通知をブロードキャストする(s1215)。かかる通知を受けたアプリ220A及び220Bは、ステータスランプSP及び無線アイコンTIの状態を灰色に変更するとともに、PTTボタンBpttの操作を有効にする処理を行う(s1216)。
【0088】
本実施形態では、操船者20の間でアプリ220上の仮想無線機能を用いた通話の他に、陸上管理端末300を用いて、運航事業者30や工事業者40が操船者20と音声コミュニケーションを図るためのグループ無線機能も、仮想無線機能の一つとして実現されている。ここで
図26はグループ無線機能を実行している陸上管理端末の画面イメージである。グループ無線においては、法人アカウントあるいはプロジェクトアカウントに対して固有のセッションルームを割り当てるため、上述の仮想無線とは異なり、チャネルを指定するパネルは不要となる。したがって陸上管理端末300の画面上には、グループ無線の通話状態を示すステータスランプSL及びPTTボタンBpttは表示されているが、テンキーやチャネル16ボタンBc16は設けられていない。
図26に示す例では、あるプロジェクトにおけるマップ表示画面が示されており、運航中の船舶の一覧と船舶アイコンが表示されている。なお、この図の例では、航行中の船舶と停船中の警戒船については異なる態様で表示することによって、プロジェクトにおける船種や役割の相違を視覚的に理解が容易となっている。
【0089】
[3.3.3 グループ無線機能に関する処理]
図27は、グループ無線に係る処理を示すシーケンス図である。この図において、PTT発話側はアプリ220であり、PTT聴取側はブラウザ310である。グループ無線においては、チャネルidのかわりにグループ識別コードを用いるものとし、グループ識別コードとしては、例えば、事業者IDやプロジェクトIDをハッシュ化したコードを用いる。アプリ220及びブラウザ310は、グループ識別コードを音声サーバ130に通知してグループ無線へ参加する(s2101)。音声サーバ130は、通知されたグループ識別コードに基づいてデータストア140に記憶するグループメンバーリストに追加し(s2102)、アプリ220及びブラウザ310に対してグループ無線へ参加した旨の通知を行う(s2103)。
【0090】
グループ無線においては、あらかじめ通話を行う対象範囲が特定されているので、上述の仮想無線のように距離による通話範囲を考慮する必要はない。したがって、アプリ220においてPTTボタンのオン状態が検出されると(s2104)、PTTオンである旨の通知を音声サーバ130に送信する際には船舶IDのみを含める(s2105)。なお、ブラウザ310がPTT発話側となる場合には、陸上の事務所に対して何らかの船舶IDを付与しておいてもよいし、船舶ID以外の識別子を用いてもよい。
PTTオン通知を受信した音声サーバ130がセッションルーム作成(s2106)からアプリ220がマイクをオンにする処理(s2109)までの連の動作は、
図23において説明したステップs1203からs1206と同様であるため、詳細な説明は省略する。
【0091】
一方、音声サーバ130がセッションルームを作成した後(s2106)、聴取側のアプリ220及びブラウザ310を特定するために、データストア140を検索してグループメンバーリストを取得する(s2110)。このグループメンバーリストで特定されたアプリ220及びブラウザ310に対して音声サーバ130は受信可能となった旨を通知する(s2111)。なお、当該通知を受信したアプリ220及びブラウザ310が行う処理(s2112)以降、アプリ220及びブラウザ310がステータスランプSP及び無線アイコンTIの状態を灰色に変更する処理(s2119)は、
図23において説明したステップs1209からs1216と同様であるため、詳細な説明は省略する。
【0092】
[2.5 航路再生機能]
次に、
図28に示す航路再生アニメーションのイメージを参照しながら、航路再生機能について説明する。この図においては、3枚のフレームが例示されている。アニメーション作成時のフレームレートは任意であるが、船速に応じて適宜決定するようにしてもよい。
【0093】
図9に例示したデータベース150の航海履歴位置テーブルを参照することによって、各フレーム作成を作成することができる。航路再生アニメーションの開始及び終了日時については、1航海分の全部であってもよいし、開始及び終了日時を指定できるようにしてもよい。なお、航路再生アニメーションは、再生が指示される都度作成してもよいし、作成されたアニメーションを動画ファイルとして保存できるようにしてもよい。
【0094】
図28に例示したフレームFL1、FL2、FL3は、「X丸」を自船とした航路再生であり、他船として「ABCD」が表示されている。フレームFL1においては、両船の針路が交差しており、自船が針路を維持すると衝突するおそれがある。「X丸」は「ABCD」を右に見る(赤色の左舷灯を見る)ので避航船となり、「ABCD」が保持船となる。FL1のシチュエーションにおいては、
図19を参照しながら説明したように、「X丸」側のアプリ220が提供する衝突予測機能によって、操船者20に警告がなされている。フレームFL2からは、警告を受けた「X丸」の操船者20が減速した上で右回頭を開始したことがわかり、その後、フレームFL3からは、「X丸」が「ABCD」の左舷側を通過することによって衝突を回避できたことがわかる。
【0095】
航路再生アニメーションの表示画面には、フレームFL3の表示例に示すように、再生箇所を示すシークバーを設けてもよく、警告が表示されていた時間帯等、再生時に注意するポイントに対応する再生箇所を示すマークと合わせて表示されるようにしてもよい。このような再生注視ポイントは、例えば警告表示や注意表示のような操船者に提示した情報に基づく条件設定であってもよいし、他の船舶との関係を所定のアルゴリズムで判定した操船危険度のような事後分析のための機能による条件設定であってもよい。
【0096】
[3.4 履歴出力機能]
次に、履歴出力機能について説明する。
図29は、操船を開始してから終了するまでの流れを概略的に示す図である。アプリ220は、操船開始及び終了を指示する操作インターフェイスを操船者20に対して提供する。
図29に示す例では、操船者20は、操船開始前に船舶、操船目的、及び役割を選択できるようになっており、これらの項目は、
図8及び
図9を参照して説明したベータベースの構成のように、正規化されて関連付けられており、予め選択可能な項目が特定されている。
【0097】
操船者20が操船開始ボタンBsを押下した操作は管理サーバ100に送信され、APIサーバ110によって提供される機能である航海コントローラ117に渡される。アプリ220から受信した操船者ID、船舶ID、操船目的ID、役割ID、及び日時とともに、操船開始日時がデータベース150の操船履歴テーブルに登録される。なお、操船者20が運航事業者30の業務として操船を行う場合には、操船者IDは事業者IDやプロジェクトIDに紐づけられているので、事業者IDやプロジェクトIDも操船履歴テーブルに登録される。
操船終了時には、操船者20が操船終了ボタンBeを押下した操作が管理サーバ100に送信されと、操船距離とともに操船終了日時が算出され、データベース150に登録される。
【0098】
このように、操船者20毎に、操船した船舶、操船目的、及び役割と紐づけた操船履歴をデータベース上で管理できる。警戒船や作業船の搭乗要員については、経歴情報を管理して港湾管理者に提出する必要がある場合もあり、例えば海上保安庁の行政指導指針である「海上における工事作業等の警戒船の配備等に関する指針」では、警戒船の船長及び専従警戒要員又は警戒業務管理者等としての経歴や、管理講習受講年月日及び当該講習主催者名も提出することが要求されている。海技免状の維持には乗船履歴を管理することが義務づけられているが、小型船舶操縦免許では履歴を管理する制度がないので、このような情報を、運航状態や操船履歴としてシステム上で管理することによって、操船者の経歴管理も容易となる。
【0099】
ここで、
図30は、ある操船者の操船履歴の表示例である。この例では、操船者20個人の操船回数、操船時間、及び操船距離の合計を示すとともに、操船した船舶別の情報も提示している。操船履歴を航海毎にリスト表示するページへ遷移することができ、航海毎の操船履歴として、操船日、操船時間、及び操船距離の他に、
図28を用いて説明したような注視ポイントが発生した回数等も表示してもよい。
また、
図31は、プロジェクトにおける操船履歴の表示例であり、プロジェクトに紐づけられた航海履歴がリスト表示されている。リストの各行には、船名、操船目的、操船者、役割、合計時間、及び合計距離が表示されている。
【0100】
[3.5 監視領域作成機能]
[3.5.1 プロット作成画面]
次に、監視領域作成機能について説明する。
図32は、監視領域を設定するためのプロット作成画面の例である。監視領域としては、例えば、警戒船の配置が義務付けられている工事作業等の実施海域や、大規模な油濁事故が発生している海域等が想定される。本実施形態では、プロジェクトの対象となる工事の実施海域が監視領域として設定されており、運航される警戒船がプロジェクトにおいて管理されている。そして、設定された監視領域に侵入する恐れのある船舶が検出された場合には、警戒船に対して警告が発せられる。
プロジェクトの管理者は、マップ上の複数の点を指定することによって、実施海域の緯度及び経度を登録することができ、画面上で設定した領域を確認すると、決定ボタンBdを押下することによって、画面上で指定された緯度及び経度からなる位置情報がデータベース150に登録されるようになっている。
【0101】
[3.5.2 プロット作成に関するデータ構成]
図33は、監視領域として登録された位置情報と船舶情報に関するデータ構成を説明する図である。マップ上で指定された点に対応する緯度・経度を示すデータは、
図13において説明したように、複数のプロットポイントを有することを示すフラグがたてられたプロットIDに紐づけられた複数のプロットポイントIDとして管理される。
【0102】
一方、操船者20が使用するアプリ220が参照するデータストア140は、本実施形態においては、ドキュメント指向の非リレーショナルデータベースであり、監視領域を特定するプロットID、当該監視領域に配置されている警戒船の船舶ID、及びタイムスタンプが、一つのドキュメントとして管理されている。
また、データストア140には、航行中の船舶の警告領域(
図17参照)が監視領域に重複している船舶を管理するファイルも作成されている。警告領域ファイルには、監視領域を特定するプロットID、当該監視領域に警告領域が重複する船舶ID、及びタイムスタンプが一つのドキュメントとして管理されている。
【0103】
[3.5.3 警告表示例]
図34及び
図35は、航行中の船舶が監視領域に接近した際にアプリに表示される画面のイメージである。
図34の例では「甲丸」が自船であり、警戒船としてプロジェクトに登録されている。「あいう丸」が、監視領域に接近している他船であり、警告領域が監視領域と重複している。また、仮想無線が待機状態であることを示すアイコンが表示されている。
図32は、アプリ220によって表示された警告メッセージによって注意喚起された「甲丸」の操船者20が、「あいう丸」に対するコミュニケーションを促すべく、仮想無線のパネルを表示させている例である。
図35の例は、接近している船舶側のアプリ220に対して表示される警告例を示している。このように、監視領域に接近した船舶に対してアプリ220を通じた警告の表示や仮想無線による音声コミュニケーションを図ることができるので、工事エリア付近で停泊している船舶やすでに安全退避を行っている船舶に対しても警報を発令するといったような不要な警報の多発を回避することが可能となる。
【0104】
[3.5.4 監視領域に関する処理]
図36は、監視領域に接近する船舶を検出する処理を示すフローチャートであり、この処理はアプリ220によって実行される。処理が開始されると、自船の船舶IDを含む監視領域ドキュメントに設定されているプロットIDを含む警告領域ドキュメントがデータストア140に登録されているか否かが判定され(S301)、登録されている場合には(S301;Yes)、警告領域ドキュメント内の船舶IDに基づいて当該船舶の警告領域が計算される(S302)。次いで、計算された警告領域がプロットIDで特定された監視領域と警告領域とが重複するか否か判定され(S303)、重複すると判定された場合には(S303;Yes)、
図32に例示したような警告表示が実行されて(S304)、処理が終了する。
ステップS303の判定において監視領域と警告領域とが重複しないと判定された場合には(S303;No)、データストア140から警告領域ドキュメントが削除されたのちに(S305)、処理が終了する。
【0105】
ステップS301の判定において警告領域ドキュメントがデータストア140に登録されていないと判定された場合には(S301;No)、一定範囲内の周囲船舶の警告領域が計算され(S306)、計算された警告領域がプロットIDで特定された監視領域と警告領域とが重複するか否か判定される(S307)。監視領域と警告領域とが重複すると判定された場合には(S307;Yes)警告領域ドキュメントがデータストア140に登録され(S308)、重複しないと判定された場合には(S307;No)、警告領域ドキュメントが登録されることなく処理が終了する。
【0106】
次に
図37は、警告領域ドキュメントに関する処理のフローチャートである。操船中ステータスとなっているアプリ220は、データストア140に登録されたドキュメントを参照し、
図20で説明したように自船から一定範囲にある他船を抽出するとともに、監視領域ドキュメントも監視している。自船の船舶IDを含む警告領域ドキュメントがデータストア140に登録されているか否かが判定され(S311)、登録されていない場合には(S311;No)、自船の警告領域内に監視領域が存在するか否かが判定される(S312)。監視領域が存在すると判定された場合には(S312;Yes)、当該監視領域が一定時間以上継続して自船の警告領域と重複するか否かが判定される(S313)。自船の針路によっては、自船の警告領域が監視領域にわずかな時間だけ重複するような場合もあるため、一定時間以上継続して重複する場合のみ警告対象とすることが望ましい。
【0107】
ステップS313において一定時間以上継続して重複すると判定された場合には(S313;Yes)、データストア140に警告領域ドキュメントが登録され(S314)、タイムスタンプが更新されて(S315)、処理は終了する。ステップS312において警告領域内に監視領域が存在しないと判定された場合には(S312;No)は、警告領域ドキュメントが登録されずに処理は終了する。
【0108】
ステップS311において自船の船舶IDを含む警告領域ドキュメントが登録されていると判定された場合には(S311;Yes)、警告領域がすでに監視領域がから抜けているか否かが判定され(S316)、監視領域から抜けていると判定された場合には(S316;Yes)、当該警告領域ドキュメントをデータストア140から削除して(S317)、処理は終了する。一方、ステップS316において警告領域が監視領域から抜けていないと判定された場合には(S316;No)、当該警告ドキュメントのタイムスタンプが更新される(S315)。
【0109】
上述の例では、監視領域に接近する船舶が検出された際には警戒船のアプリ220に警告を表示するものとしているが、例えば漁業で利用するのであれば、
図38に例示するように、陸上の管理者が使用しているブラウザ310へ警告を表示するような態様でも構わない。この図の例では、監視領域としてプロット設定されている定置網に船舶が接近した際に、陸上の監視者に対して警告を表示する態様が示されている。
【0110】
[4 オフライン時対応の構成]
上記の例では、通信端末200がキャリアネットワークCNあるいはプライベートネットワークPNの通信圏内であることを前提としているが、海上においては、基地局からの距離や周囲の電波環境等によっては通信が不安定になる場合や、通信が途絶する場合がある。また、一般ユーザが用いている携帯電話やタブレットにおいて衛星データ通信を利用している場合は少ないと考えられるため、通信端末200が管理サーバ100にアクセスできない海域を航行する場合も想定される。
そこで、本実施形態では、通信状態が良好ではなく、通信端末200が管理サーバ100にアクセスできない環境においても、周囲の船舶が発するAIS電波を受信し、アプリ220単体で、自己位置と合わせて船をマップ表示し、衝突予測を実現する態様も備えている。
【0111】
図4を用いて説明したように、海上AIS受信装置900は、周囲の船舶が発するAIS信号をVHFバンドで受信し、BLE送信する機能を備えている。アプリ220は、受送信プログラム901から受信したAIS船舶位置データと、測位プログラム210で生成された自船位置データに基づいてマップ表示及び衝突予測を行うことができる。
【0112】
また、無線ネットワークの通信圏外においては、情報提供サーバ700にアクセスすることもできないので、マップデータ710についてもオフライン利用となるが、通信端末200のメモリにキャッシュされたマップデータを用いてマップ表示することができるように構成されている。
上述の例では、通信端末200と海上AIS受信装置900との接続にはBLEを用いる構成を説明したが、これに限らず、通信端末200とローカル接続が可能であれば、Wi-Fi等の他のアンライセンスバンドを利用した無線通信を用いてもよいし、イーサネット(登録商標)等の有線通信で接続する構成でもよい。
【0113】
[5 実施形態の効果]
以上、本実施形態に係る船舶動静共有航行支援システムによれば、自船及び周囲の他船の動静を操船者に対して提示するマップ画面は、直感的に把握しやすいユーザインターフェイスとなっており、システム利用者間の音声コミュニケーションを図ることが容易な構成となっている。そして、システムの利用にあたっては、無線利用に関する免許取得や無線局の開設手続きも不要であるため、AISや国際VHFの搭載が義務づけられていない非SOLAS船に対しても普及が容易となる。
【0114】
船舶動静共有航行支援システムは、船舶動静情報と操船者情報とを管理するプラットフォームとして用いることができ、APIを公表することによって幅広い利用が容易となる。
通信状況は不安定な海域においては、海上AIS受信装置900と通信端末200とをローカル接続することによって周囲のAIS船の動静を把握でき、通信端末200にキャッシュされたマップデータを用いてマップ表示機能が提供されるので、通信環境の変化に対応することが可能となる。
【0115】
また、自船の位置を公表しないことを希望する船舶については、概ね目視可能と想定される衝突予測に必要な距離に位置する船舶の動静のみ表示する機能を備えるので、匿名性と安全性を両立させることが可能となり、漁船やプレジャーボート等の非SOLAS船に対するシステム利用を促進することも容易となる。
【0116】
工事作業が実施される海域を監視領域としてプロット設定することができ、監視領域に接近する船舶の動静を監視し、当該船舶や警戒船に対して警告を発することが可能となっているので、工事作業における安全性や利便性の向上を図ることができる。また、このような監視領域の設定及び警告に関する機能は、港湾管理者や漁業者にとっても利便性が高い。
【0117】
また、データベースでは、操船者や船舶の情報が紐づけられて履歴管理されているので、警戒船の乗組員に関する乗船履歴や、保険料率の算定等にも利用することが可能となる。航海履歴はアニメーション再生することができるので、事故発生時における事後検証や、操船者の判断傾向や衝突事故の発生傾向を分析するために用いることもできる。操船者のキャリアアップや保険の優遇対象として操船履歴が用いられれば、非SOLAS船に対して、船舶動静共有航行支援システムの普及を促進することが容易となる。
したがって、船舶の衝突予防に有益な機能を、より多くの操船者に対して、より理解が容易な態様で提示することが可能となる。
【符号の説明】
【0118】
100…管理サーバ、110…APIサーバ、120…Webサーバ、130…音声サーバ、140…データストア、150…データベース、160…バックエンドサービス、170…AIS受信サーバ、200…通信端末、210…測位プログラム、220…アプリ、300…陸上管理端末、310…ブラウザ、700…情報提供サーバ、710…マップデータ、810…陸上AIS受信装置、811…受送信プログラム、900…海上AIS受信装置、901…受送信プログラム。
【手続補正書】
【提出日】2023-12-12
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
少なくとも操船者を識別する操船者識別情報、船舶を識別する船舶識別情報、並びに船舶の位置及び動静を示す船舶動静情報履歴を管理するデータベースと、
船舶の少なくとも位置情報示す船舶位置データを受信し、前記データベースに記憶させるバックエンドサービスと、
を含むバックエンドプラットフォームと、
ユーザインターフェイスに対するデータ出力及びびユーザからの操作入力を受け付けるフロントエンドと、
前記バックエンドプラットフォームと前記フロントエンドとのインターフェイスであるアプリケーションプログラミングインタフェース(Application Programming Interface:API)と、
を備え、
前記ユーザインターフェイスは、前記データベースで管理された前記船舶動静情報に基づいて、マップデータで規定された形式に変換された船舶動静共有データを表示し、
前記APIは、前記ユーザインターフェイスを提供するアプリケーションを実行する通信端末が搭載された船舶の前記船舶識別情報と当該船舶を操船する操船者の前記操船者識別情報とを紐づける入力を、前記ユーザインターフェイスから受け付け、
前記バックエンドサービスは、前記船舶識別情報及び前記操船者識別情報と、前記船舶動静情報とを紐づけて、前記船舶動静情報履歴として前記データベースに記憶させる、船舶動静共有航行支援システム。