JP2020201912A - 船舶動静共有航行支援システム - Google Patents

Abstract

【課題】 船舶の衝突予防に有益な機能を、より多くの操船者に対して、より理解が容易な態様で提示することが可能な船舶動静共有航行支援システムを提供する。【解決手段】 操船者及び船舶を識別する情報と船舶動静情報履歴とを紐づけて管理し、操船中はマップデータで規定された形式に変換された船舶動静共有データをユーザインターフェイスに表示するので、船舶の衝突予防に有益な機能を、より理解が容易な態様で提示することが可能となり、操船者と船舶が特定された船舶動静情報履歴が管理されるので、操船者や運航事業者等対する安全性の向上のための情報や保険の適用に関する情報等を提供できるようになるので、より多くの操船者に対して船舶動静共有航行支援システムを利用するインセンティブを提供することが可能となる。【選択図】 図５

Description

本発明は、船舶動静共有航行支援システムに関する。

船舶の安全な航行のための国際的なルールとして、海上における衝突の予防のため国際規則に関する条約（Convention On the InternationaL REGulations for Preventing Collisions at Sea：COLREGS）や、海上における人命の安全のための国際条約（International Convention for the Safety of Life at Sea：SOLAS）等があり、対応する国内法として、海上衝突予防法や船舶安全法等がある。これらの条約は、船舶の通行に関する基本的なルールを定めるとともに、一定の船舶に対しては、衝突を予防するための各種装置の搭載を義務付けている。このような義務を有する船舶は一般的に「SOLAS船」と呼ばれている

SOLASで規定された代表的な装置としては、VHF（Very High Frequency）と呼ばれる周波数帯（VHFバンド）を使用し、船舶において遭難・安全通信、港務通信、電気通信業務、水先業務等に用いられる「国際VHF」と呼ばれている無線通信システムや、国際VHF帯の専用チャネルを使用して船舶の位置や動静等の状態を自動識別するための信号を送受信する自動船舶識別装置（Automatic Identification System：ＡＩＳ）、対象となる物標を自動的に捕捉し、物標までの方位や距離を計算して表示するとともに、衝突の危険性を自動的に判断する自動レーダープロッティング装置（Automatic Radar Plotting Aids：ARPA）等がある。

図１は、船舶の航行状況や通信環境のイメージを示す図である。海上では、基本的には有線による通信ができないため、無線による通信が行われる。船舶では主に衛星通信が利用されているものの、沿岸部であれば携帯電話網が利用できる場合もある。ＡＩＳは船舶の位置や動静等に関するデータを国際VHF帯のチャネルを使用して船舶間でデジタルデータ通信を行うものであるが、通信衛星でＡＩＳ信号を受信する衛星ＡＩＳや、陸上でＡＩＳ信号を受信するＡＩＳ海岸局も運用されており、受信されたＡＩＳデータをインターネット上で提供するサービスも開発されている。

国際航海に従事しない５００トン以上の船舶や国際航海に従事する３００トン以上の船舶のような大型船にＡＩＳの搭載義務があるものの、小型船舶等のようなＡＩＳ搭載が義務付けられていない非SOLAS船については、ＡＩＳによる船舶動静を把握することができない。沿岸部における衝突事故も多くはプレジャーボートや漁船に関するものであるため、携帯電話やスマートフォン等の通信端末を利用した船舶動静情報の共有も進められている。

特許文献１には、ＡＩＳ搭載船からVHF帯で受信したＡＩＳ情報と、GPS受信機能を備えた情報通信端末から受信したＡＩＳ非搭載船の船舶情報とをインターネットを介してメインサーバに集約して一元化し、通信端末に配信する船舶運航監視システムが開示されている。
特許文献２には、所定の位置的な条件を満たすＡＩＳ搭載船の航海情報及びＡＩＳ非搭載船から位置情報を取得する情報配信装置から船舶情報を取得し、自己位置を基準とした警報通知ゾーンに侵入した船舶に関する警報を出力する通信端末が開示されている。

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

ＡＩＳやＡＲＰＡ等のSOLASで規定された衝突予防装置は、国内航海のみを行う小型船舶には搭載義務はない。また、大型の船舶を操船するためには海技免状及び所定のトレーニングが必要であるため、このような装置は、訓練された有資格者が使用することを前提としてデザインされおり、一般的なユーザにとって直感的に理解できるようなユーザインターフェイスにはなっていない。さらに、ＡＩＳや国際VHFのような所定の電波を発する装置の使用には、免許の取得や無線局開設に関する電波法上の手続きが必要となり、小型船舶を含むすべての船舶に対して使用を義務付けることは困難な状況にある。

海上交通安全法や港則法では、交通制限が必要な工事作業や輻輳海域における工事作業を行う場合には、実施海域付近を航行する船舶の安全を確保する観点から、警戒船を配備することが要求されており、警戒船の乗組員についても一定の要件を課している。警戒船の任務には、実施海域に異常接近する船舶に対して注意を喚起することや、異常を発見した場合には実施海域内の関係者にその情報を通報すること等があり、実施海域の状況を踏まえてＡＩＳや国際VHFを装備することになっている。しかし、これらの設備を搭載していない船舶を監視することや、音声コミュニケーションを図ることは困難である。

上記の特許文献に記載されたような情報端末を用いる場合には、より多くの船舶が同様の情報端末を搭載していなければ、船舶の動静を共有することができず、衝突を回避するための行動を判断することは困難である。また、国際VHFは、衝突を回避するための音声コミュニケーションに用いられるが、携帯電話による通話やスマートフォンで動作するアプリ上のチャット機能等では、通信相手を特定できなければ通話することができないため、相手が特定されていない船舶に対して衝突を回避するために緊急のコミュニケーションを図ることはできない。

また、プレジャーボートや漁船では、自己位置を公表することに抵抗感もあり、ＡＩＳやスマートフォンアプリを用いて位置情報を提供する装置の搭載を非SOLAS船にも義務付けることが困難である状況に鑑みると、通信端末を搭載するモチベーションを高めて普及を図る必要がある。
本発明は上述した課題を解決するためになされたものであり、船舶の衝突予防に有益な機能を、より多くの操船者に対して、より理解が容易な態様で提示することが可能な船舶動静共有航行支援システムを提供することを課題とする。

上述した課題を解決するために、実施形態にかかる船舶動静共有航行支援システムは、少なくとも操船者を識別する操船者識別情報、船舶を識別する船舶識別情報、並びに船舶の位置及び動静を示す船舶動静情報履歴を管理するデータベースと、船舶の少なくとも位置情報示す船舶位置データを受信し、前記データベースに記憶させるバックエンドサービスと、 を含むバックエンドプラットフォームと、ユーザインターフェイスに対するデータ出力及びびユーザからの操作入力を受け付けるフロントエンドと、前記バックエンドプラットフォームと前記フロントエンドとのインターフェイスであるアプリケーションプログラミングインタフェース（Application Programming Interface：ＡＰＩ）と、を備え、前記ユーザインターフェイスは、前記データベースで管理された前記船舶動静情報に基づいて、マップデータで規定された形式に変換された船舶動静共有データを表示し、前記ＡＰＩは、前記ユーザインターフェイスを提供するアプリケーションを実行する通信端末が搭載された船舶の前記船舶識別情報と当該船舶を操船する操船者の前記操船者識別情報とを紐づける入力を、前記ユーザインターフェイスから受け付け、前記バックエンドサービスは、前記船舶識別情報及び前記操船者識別情報と、前記船舶動静情報とを紐づけて、前記船舶動静情報履歴として前記データベースに記憶させる。

操船者及び船舶を識別する情報と船舶動静情報履歴とを紐づけて管理し、操船中はマップデータで規定された形式に変換された船舶動静共有データをユーザインターフェイスに表示するので、船舶の衝突予防に有益な機能を、より理解が容易な態様で提示することが可能となり、操船者と船舶が特定された船舶動静情報履歴が管理されるので、操船者や運航事業者等対する安全性の向上のための情報や保険の適用に関する情報等を提供できるようになるので、より多くの操船者に対して船舶動静共有航行支援システムを利用するインセンティブを提供することが可能となる。

船舶の航行状況や通信環境のイメージを示す図である。 サービスモデルを示すスキーム図である。 システム全体のネットワーク概要構成図である。 通信機器間の関係を説明するためのプロトコルスタックを示す図である。 アプリケーションレイヤにおける各機器の機能ブロック図である。 船舶動静共有航行支援システムのユースケースを示す図である。 アプリの実行によって表示されるトップ画面のイメージ図である。 アカウント関連のテーブル構造とリレーションの一例を示す図である。 船舶関連のテーブル構造とリレーションの一例を示す図である。 操船者情報管理画面の例である。 船舶情報管理画面の例である。 プロジェクト情報管理画面の例である。 プロット関連のテーブル構造とリレーションの一例を示す図である。 マップ表示画面のレイヤ構造について説明する図である。 マップ表示の縮尺と船舶アイコンの表示態様との関係を示す図である。 レイヤ構成によって画面上に生成されたマップ表示のイメージ図である。 船舶アイコンの表示可否について判定するフローチャートである。 ヒートマップを表示したマップ画面のイメージ図である。 衝突予測画面のイメージ図である。 レーダーモード表示にかかる処理を示すフローチャートである。 警告対象船抽出処理を示すフローチャートである。 注意対象船抽出処理を示すフローチャートである。 仮想無線の機能を使用者に提示する画面イメージを示す図である。 接続から待機中の処理を示すシーケンス図である。 ＰＴＴ通話時の処理を示すシーケンス図である。 グループ無線機能を実行している陸上管理端末の画面イメージである。 グループ無線に係る処理を示すシーケンス図である。 航路再生アニメーションのイメージ図である。 操船を開始してから終了するまでの処理の流れを概略的に示す図である。 ある操船者の操船履歴の表示例である。 プロジェクトにおける操船履歴の表示例である。 監視領域を設定するためのプロット作成画面の例である。 監視領域として登録された位置情報と船舶情報に関するデータ構成を説明する図である。 航行中の船舶が監視領域に接近した際にアプリに表示される画面のイメージである。 航行中の船舶が監視領域に接近した際にアプリに表示される画面のイメージである 監視領域に接近する船舶を検出する処理を示すフローチャートである。 警告領域ドキュメントに関する処理のフローチャートである。 陸上の管理者が使用しているブラウザに警告を表示する例を示す図である。

以下、図面を用いて実施形態を説明する。
［１ システムの全体構成］
［１．１ サービスモデル］
まず、船舶動静共有航行支援システムの利用形態について説明する。図２は、サービスモデルを示すスキーム図である。サービスプロバイダ１０が船舶動静共有航行支援システムを用いたサービスを提供しており、船舶の操船を行う操船者２０、船舶の運航を行う運航事業者３０、船舶の運航を伴う工事を行う工事業者４０、船舶保険を提供している保険会社５０、及び港湾、工事エリア、漁網設置エリア等の船舶の運航に関する規制が必要な水域を管理する水域管理者６０が、サービスプロバイダ１０が提供するサービスを利用している。

SOLAS船以外にも衝突予防手段を講じるべき船舶には、プレジャーボートのような個人用途の小型船舶に限らず、漁船、作業船、警戒船等の業務船もある。別の観点からは、船舶動静情報は、保険の事故検証や料率算定においても検証データや統計データとしても利用できる。さらに、港湾においては、過密なスケジュールで出入りする船舶の動静や停泊位置を管理しなければならず、漁業や工事では、船舶同士の衝突だけでなく、定置網や養殖いかだ等の漁業関連設備や工事関連設備等の障害物への衝突も予防する必要がある。このように、船舶動静に関する情報を必要とするステークホルダーは多岐にわたるため、図２に示すように、サービス利用者として様々な主体が想定されている。

サービスプロバイダ１０は、外部の情報プロバイダ７０からも情報の提供を受けてサービスを提供しており、情報プロバイダ７０から提供を受ける情報には、例えば、地図情報、気象情報、船舶動静情報、海難情報等がある。
操船者２０は、個人２１としてサービスを利用する場合もあるが、運航事業者３０に役務を提供する被用者２２の場合もある。また、運航事業者３０も、工事業者４０に対して役務を提供する協力会社（下請）３１の場合もある。このようなビジネスモデルの相違によって、サービスプロバイダ１０と各利用者との間にはさまざまな契約形態が存在している。

［１．２ ネットワーク構成］
［１．２．１ 全体構成］
次に、実施形態にかかる船舶動静共有航行支援システムのネットワーク構成について説明する。図３は、システム全体のネットワーク概要構成図である。船舶動静共有航行支援システムは、主に管理サーバ１００の機能によって提供される。管理サーバ１００は、インターネットINに接続されており、インターネットプロトコル（ＩＰ）によって、船舶動静等の情報を通信端末２００及び陸上管理端末３００に提供する。通信端末２００は、操船者２０が船上で使用することが想定されているので、使用場所は海や河川等の水上である。水上では有線のデータネットワークが利用できないので、携帯電話会社や衛星通信会社等の通信キャリア事業者がデータ通信サービスを提供しているキャリアネットワークCNを介して管理サーバ１００とのデータ通信を行う。

一方、陸上管理端末３００は、運航事業者３０あるいは工事業者４０の管理者が陸上の事務所で使用することが想定されており、インターネットINを介して管理サーバ１００とのデータ通信を行う。なお、運航事業者３０等の社内ネットワーク上に陸上管理端末３００を設置する態様も考えられ、例えば社員情報等を管理する他の社内システム３０１とデータ連携等を行ってもよい。また、通信端末２００と陸上管理端末３００とのデータ通信は、長距離無線LAN（Local Area Network）等を利用したプライベートネットワークPNでもよく、プライベートネットワークPNを経由してインターネットINに接続することによって、管理サーバ１００にアクセスする構成でも構わない。

船舶の動静情報は、後に詳しく説明するようにＡＩＳ送受信機８００が発するＡＩＳ信号に含まれる情報及び、通信端末２００の機能によって測位された位置情報に基づいて把握される。ここでＡＩＳ送受信機８００は、SOLAS、ITU（International Telecommunication Union）、IEC（International Electrotechnical Commission）等の規格に準拠した通信方式やメッセージ形式に従ってＡＩＳ情報を送受信する機器である。ＡＩＳ情報には、船舶の識別符号、船名、位置、針路、速力、目的地などの船舶情報が所定の形式で含まれている。一方、本実施形態における陸上ＡＩＳ受信装置８１０及び海上ＡＩＳ受信装置９００は、ＡＩＳ送受信機８００からＡＩＳ信号を受信し、所定のデータ形式に変換した上でデータを送信する装置である。

［１．２．２ プロトコルスタック］
ここで図４は、図３に示した通信機器間の関係を説明するためのプロトコルスタックを示す図である。ＡＩＳ送受信機８００は、ITU-R M.1371やIEC 61993、IEC 62287等で規定された物理層（L1）及びデータリンク層（L2）のプロトコルに準拠した信号を送出し、陸上ＡＩＳ受信装置８１０及び海上ＡＩＳ受信装置９００は、ＡＩＳ送受信機８００から受信した信号をこれらのプロトコルに従って解釈する。ＡＩＳ送受信機８００は、アプリケーション層では、グローバル・ポジショニング・システム（Global Positioning System：GPS）等の全球測位衛星システム（Global Navigation Satellite System：GNSS）を用いて生成した自船位置の測位データ及び船舶名やＭＭＳＩ番号（Maritime Mobile Service Identity）等の自船に関する情報をあわせて他船に送信するとともに、他船から受信した情報をプロッタ等のユーザインターフェイスに表示する。一般的に、米国海洋電子機器協会（National Marine Electronics Association：NMEA）（登録商標）が定めた規格が、船舶の運航に用いられるＡＩＳやGPS等のデータの共通フォーマットとして採用されており、測位機器や表示機器とＡＩＳ送受信機はシリアル通信プロトコルで通信が行われる。

陸上ＡＩＳ受信装置８１０は、アプリケーション層で動作する受送信プログラムによって、ＡＩＳ送受信機８００から受信したＡＩＳデータをIPネットワーク上で管理サーバ１００に送信する。また、海上ＡＩＳ受信装置９００は、ＡＩＳ送受信機８００から受信したＡＩＳデータをＢＬＥ（Bluetooth Low Energy）（登録商標）で通信端末２００に送信する。

スマートフォンやタブレット等の通信端末２００は、IPネットワーク通信用の無線通信手段として、携帯電話網で提供されるLTE（Long Term Evolution）（登録商標）の他、Wi-Fi（登録商標）通信手段が搭載されている。また、通信端末２００は、GPS等や基地局情報等から生成された測位データをアプリケーション（アプリ）上で利用できるように構成されており、BLE通信を介して海上ＡＩＳ受信装置９００から受信したＡＩＳ情報と測位情報とをあわせた船舶情報として、IPネットワーク上で管理サーバ１００に送信することができる。なお、GPS等の受信手段は、通信端末２００に内蔵された機器でもよいし、有線又は無線によって接続した外付けの機器でもよい。

管理サーバ１００及び陸上管理端末３００は汎用的なものでよく、物理層（L1）及びデータリンク層（L2）についても、有線でも無線いずれの通信規格に準拠した構成で構わない。管理サーバ１００は、アプリケーション層において、Webサーバ、データベース（DB）、及びAPI（Application Programming Interface）等が稼働しており、通信端末２００上や陸上管理端末３００をクライアントとするサーバとして機能する。アプリケーション層で用いられるプロトコルは、例えばHTTP等一般に広く用いられているものでよい。

なお、ＡＩＳに用いられるVHFバンドの利用には、送信出力等に応じて免許が必要となるが、Wi-Fi及びBLEでは、技術基準適合証明等がなされた機器を使用する限りは無線局の免許を必要としないアンライセンスバンドが利用できる。LTEバンドのように通信キャリア事業者が提供する通信サービスを利用する場合は、通信キャリア事業者が包括的に取得した免許による周波数帯の利用となる。なお、通信キャリア事業者から提供される通信規格は、本実施形態で例示したLTEに限らず、WiMAX（Worldwide Interoperability for Microwave Access）（登録商標）や5G（第5世代移動通信システム）等の移動体通信ネットワークにおける通信規格や、衛星移動通信におけるデータ通信規格でも構わない。
機器間の無線通信の方式は図４に示したような形態に限定されるものではなく、電波の到達範囲やライセンスの有無等に応じて適宜選択することが可能である。いずれにしても、管理サーバ１００との間でIPネットワーク上におけるデータ送受信が可能であれば、下位層はどのような通信方式でも構わない。

［１．２．３ アプリケーションレイヤの機能構成］
図５は、プリケーションレイヤにおける各機器内のコンポーネントを機能ブロックで表した図である。管理サーバ１００のクライアントとして通信端末２００と陸上管理端末３００があり、それぞれの処理能力やネットワーク通信量等の要素を勘案して、サーバ側で行う処理とクライアントサイドで行う処理を適切に分配する構成となっている。本実施形態では、クライアント側で負荷の高い処理を実行し、ネットワーク上のデータ量を抑制するエッジコンピューティングを行う構成としている。

なお、クライアントサイドの通信端末２００にインストールされたアプリケーションソフトウエアは一般的に「ネイティブアプリ」（本実施形態では略して「アプリ」）と呼ばれており、陸上管理端末３００のブラウザ上で提供される機能を実行するアプリケーションソフトウエアは一般的に「Webアプリ」（本実施形態では略して「Web」）と呼ばれている。本実施形態では、アプリケーションソフトウエアによって提供される、ユーザへのデータ提示やユーザからの操作入力を実現する機能を総称して「ユーザインターフェイス」と呼ぶものとする。また、ユーザインターフェイスを提供する各種ハードウエアやソフトウエア等のコンポーネントの総称を「フロントエンド」し、ユーザが直接は操作しないサーバサイドで実行される各種コンポーネントの総称を「バックエンド」とする。本実施形態では、APIによってコンポーネント間を疎結合することにより、フロントエンド及びバックエンドで使用されるプログラム言語やフレームワーク等に拘束されず、拡張性が高いシステムを構成することが可能となっている。

以下、各コンポーネントについて、より詳細に説明する。管理サーバ１００上には、フロントエンドとバックエンドを接続するサービスを提供するＡＰＩサーバ１１０と、フロントエンドとしてブラウザ３１０にサービスを提供するＷｅｂサーバ１２０と、フロントエンドに対してデータ管理や接続機能等を提供するための様々なバックエンドとなる音声サーバ１３０、データストア１４０、データベース１５０及びバックエンドサービス１６０と、ＡＩＳデータを受信するＡＩＳ受信サーバ１７０が構築されている。なお、管理サーバ１００は、特定のデータセンター内に構築されてもよいし、いわゆるクラウドサービス上で提供されるPaaS（Platform as a Service）上に構築されていてもよい。

通信端末２００は、測位機能を提供する測位プログラム２１０及び、ユーザインターフェイス機能を提供するアプリ２２０を備えており、陸上管理端末３００は、ブラウザ３１０を備えている。アプリ２２０及びブラウザ３１０に表示されるマップ情報は、情報提供サーバ７００から提供されるマップデータ７１０に基づいて生成される。マップデータ７１０は、航海用の海図として作成された海図データでもよいし、陸上と海上の情報を含む地図データであってもよく、地理情報システム（Geographic Information System：GIS）データとして利用可能なデータを用いればよい。GISデータを記述するための地理空間データ交換フォーマットとして、例えば、ジオメトリ (形状)やフィーチャー (地物)をひとまとまりのオブジェクトとして記述するGeoJSONを用いることができる。マップデータ７１０は、予め情報提供サーバ７００から通信端末２００や陸上管理端末３００にダウンロードされてもよいし、現在位置に応じて適宜読み込むような態様でもよい。

陸上ＡＩＳ受信装置８１０上の受送信プログラム８１１は、ＡＩＳ送受信機８００から受信したＡＩＳデータを管理サーバ１００に対して送信し、海上ＡＩＳ受信装置９００上の受送信プログラム９０１はＡＩＳ送受信機８００から受信したＡＩＳデータを通信端末２００に対して送信する。
管理サーバ１００上のＡＰＩサーバ１１０は、ユーザインターフェイスであるアプリ２２０及びブラウザ３１０に対してバックエンドサービスへ接続するためのＡＰＩを提供するサーバであり、図５には、本実施形態で提供されるＡＰＩのうち代表的なものを記載している。ＡＩＳコントローラ１１１は、ＡＩＳ受信サーバ１７０によって受信したＡＩＳデータをデータストア１４０及びデータベース１５０に保存するＡＰＩである。プロットコントローラ１１２、事業者コントローラ１１３、操船者コントローラ１１４、画像コントローラ１１５、船舶コントローラ１１６、及び航海コントローラ１１７は、アプリ２２０及びブラウザ３１０における操作に基づくデータの登録及び削除や、アプリ２２０及びブラウザ３１０に対するデータの提供等を行うＡＰＩである。

Ｗｅｂサーバ１２０は、ブラウザ３１０上で機能を実現するＷｅｂアプリを提供するサーバであり、本実施形態で提供される機能には、後に詳しく説明するように、仮想無線機能１２１、プロット作成機能１２２、情報管理機能１２３、マップ表示機能１２４、及び履歴出力機能１２５等がある。
音声サーバ１３０は、仮想無線機能を提供するサーバであり、本実施形態では、ハイパーテキスト・トランスファー・プロトコル（Hypertext Transfer Protocol：HTTP）によってクライアントとサーバ間の高速に接続するWebSocketを通信プロトコルとして用いている。

データストア１４０は、一般的にリアルタイムデータベース、NoSQLクラウド データベース、クラウドデータストア等と呼ばれるリアルタイムデータストアであり、Ｗｅｂサーバ１２０、アプリ２２０、ブラウザ３１０におけるフロントサイドでリアルタイム性の高い処理を行うためのデータを保管するために用いられる記憶手段であり、データベース１５０は、後に構成例を詳しく説明するリレーショナルデータベースとして構成された記憶手段である。バックエンドサービス１６０は、データストア１４０やデータベース１５０へのアクセスや認証処理等のバックエンドサービス機能を提供する。
ＡＩＳ受信サーバ１７０は、陸上ＡＩＳ受信装置８１０の受送信プログラム８１１からＡＩＳデータを受信するサーバであり、陸上ＡＩＳ受信装置８１０との間にいてＵＤＰ（User Datagram Protocol）接続される。

通信端末２００が備える測位プログラム２１０は、当該通信端末２００に搭載されたＧＰＳ等のＧＮＳＳアンテナで受信した測位信号や基地局からの信号に基づいて位置情報データを生成する。アプリ２２０は、測位プログラム２１０が生成した位置情報データに基づいて自船位置情報データを生成して送信する位置情報受送信機能２２１を備えており、当該アプリ２２０内においては自船の位置情報として用いられ、管理サーバ１００に送信された自船位置情報データは、他の通信端末２００上のアプリ２２０おいては他船の船舶動静情報として用いられる。位置情報受送信機能２２１は、自船の位置情報に加えて、位置情報の差分から船速及び針路を算出して、管理サーバ１００に送信する機能も備えている。
また、アプリ２２０は、後に詳しく説明するプロット作成機能２２２、情報管理機能２２３、マップ表示機能２２４、衝突予測機能２２５、履歴出力機能２２６、及び仮想無線機能２２７等を備える。

［２ データ構成］
［２．１ ユースケース］
本実施形態に係るデータ構成を説明するにあたって、図６を参照しながら、船舶動静共有航行支援システムのユースケースについて説明する。ユースケースにおいては、ユーザとして、水上で操船を行う操船者と、陸上で運航を管理する管理者とを想定する。操船者には、「船舶動静を共有する」、「情報を管理する」、「衝突を予測する」、「他船に連絡する」、「航海情報を記録する」、及び「プロットを作成する」、というユースケースが想定されている。一方、管理者は操船を行わないので、操船者と比較して「衝突を予測する」というユースケースが除外されている。

「船舶動静を共有する」では、自船及び他船の位置、船速、針路等の、船舶の動きあるいは停船状態に関する動静情報をマップ上で表示することによって共有する。「情報を管理する」では、操船者や企業の名称及び連絡先等のアカウント関連の基本情報や、船舶の名称や船舶登録番号等の船舶関連の静的情報をシステム上で管理する。「衝突を予測する」では、自船及び他船の相対関係から衝突可能性のある船舶の位置や距離及び衝突までの予測時間等に関してシステムから警告を受ける。「他船に連絡する」では、船舶間において衝突を回避するための音声コミュニケーションを図る。そして「プロットを作成する」では、何らかの地点あるいは領域としてマップ上で情報を提供するための設定を行う。プロットとしては、例えば、操船者に対して警告や注意を促す情報や、操船にとって有益な情報、海難時に救助を求める情報等が想定される。

ここで図７は、操船者が使用する通信端末２００上のアプリ２２０によって表示されるトップ画面のイメージ図である。マップ上には、船舶の位置を示すアイコン及び船舶名、プロットの位置及びプロット名・エリア名、並びに海図図式（記号）及び名称等が表示されている。
船舶を示すアイコンのうち、図中SI１は自船を表す。自船アイコンSI１上には、後に詳しく説明する仮想無線の使用状態を示すアイコンが表示されている。他船を示すアイコンとして、停船状態を示すSI２及び航行中であることを示すSI３が表示されている。他船アイコンSI２及びSI３は、いずれも赤と緑の点を舷灯に見立てた図形が船側に配置されることによって、他船の左舷及び右舷を直感的に把握可能な図形として操船者に対して提供される。また、停船アイコンSI２と航行中アイコンSI３の舷灯を比較すると、航行中アイコンSI３は灯火されている態様の図形となっている。これにより、航行中の他船の存在を直感的に把握することが容易になる。また、航行中アイコンSI３の船首方向には、船速及び針路に応じた速度ベクトル線が表示され、船尾方向には航跡線が表示されている。これらの情報は、自船及び他船に対して選択的に表示可能であり、これにより、船舶の動きを把握することが容易となる。

図７に示すように、画面上には、ユーザからの操作を受け付ける各種のボタンが表示されている。具体的には、メニュー表示を指示するメニューボタンＢ１、プロット作成メニューを表示するプロットボタンＢ２、仮想無線用のパネル表示を指示する仮想無線ボタンＢ３、自船の現在位置をマップ上の中央に移動させることを指示する現在位置ボタンＢ４、衝突予測に関する情報をユーザに示すレーダーモード画面への遷移を指示するレーダーモードボタンＢ５、及び自船の操船開始や終了を指示する操船ステータスボタンＢ６が表示されている。なお、操船ステータスボタンＢ６は、操船中においては異なる色等の特定の態様で表示するようにしてもよい。

［２．２ データベースのテーブル構造］
ここで、上述した機能を提供するために構成されたデータベースのテーブル構造について説明する。データベース１５０は、リレーショナルデータベースであり、操船者や船舶等が識別子（ＩＤ）により一意に特定され、以下に説明するように各種の情報と紐づけられている。

［２．２．１ アカウント関連のテーブル構造］
図８は、アカウント関連のテーブル構造とリレーションの一例を示す図である。アカウントとしては、図２において示したように、操船者２０、運航事業者３０、工事業者４０、保険会社５０、及び水域管理者６０のそれぞれに発行されうる。本実施形態では、操船者２０個人別の操船履歴の管理を行うために、操船を行う自然人別にアカウント（操船者ＩＤ）が発行される。操船者２０を被用者として管理する運航事業者３０や、契約上の権利義務に基づいて操船者２０の情報を取得する保険会社５０、法令上や契約上の権利義務等に基づいて操船者２０の操船状況を監視する水域管理者６０は、事業者別にアカウント（事業者ＩＤ）が発行される。また、複数の事業者による共同事業体（JV）あるいは単独の企業としての工事業者４０が複数の運航事業者３０を協力会社として業務を行う工事等の事業は、有期限のプロジェクトとして管理するものとし、プロジェクト別にアカウント（プロジェクトＩＤ）が発行される。これら事業者ＩＤやプロジェクトＩＤは、操船者ＩＤに紐づけられて、操船者が所属するグループとして識別する管理にも用いることができる。

図８に示すように、「操船者テーブル」、「事業者テーブル」、及び「プロジェクトテーブル」それぞれにおいて、操船者ＩＤ、事業者ＩＤ、プロジェクトＩＤによって識別される主体の基本情報が管理されている。プロジェクト毎に参画する事業者を特定して管理するために、プロジェクトＩＤと事業者ＩＤとを紐づけて管理する「プロジェクト事業者テーブル」が設定されている。「プロジェクト事業者テーブル」には、さらに、プロジェクトにおいて稼働する操船者や船舶を特定して管理するための「プロジェクト操船者テーブル」や「プロジェクト船舶テーブル」もＩＤによって紐づけられている。

操船者ＩＤには、操船者の船舶免許に関する情報を管理する「免許テーブル」が紐づけられており、免許番号や有効期限等の管理を行うことができる。また、操船者ＩＤに紐づけられた「操船履歴テーブル」は、操船毎の開始・終了時刻や距離を記録しており、事業者ＩＤやプロジェクトＩＤによって操船した事業を特定できる他、船舶ＩＤ、操船目的ＩＤ、及び役割ＩＤ等によって、操船した船舶や役割等を特定することによって乗船履歴としての管理を行うことができるようになっている。

［２．２．２ 船舶関連のテーブル構造］
引き続き図９は、船舶関連のテーブル構造とリレーションの一例を示す図である。船舶は船舶ＩＤによって一意に特定されており、船名や船舶番号等の静的な情報の他、本実施形態では、マップ上で船舶の位置を公表するか否かを示す「位置公表フラグ」も設定されている。これにより、位置を公表しない船舶については、船舶の衝突予防に必要な範囲においてマップ上に位置が表示される制御が可能となっている。

船舶ＩＤに紐づけられた「航海履歴位置テーブル」は、目的地、緯度、経度、船首方位、針路、船速、動静判定等の航海における動的な情報をデータ取得日時とともに履歴として管理するテーブルであり、操船者ＩＤ、事業者ＩＤ、プロジェクトＩＤ、操船履歴ＩＤ等とも紐づけられることによって、操船者や事業との関連も管理することができるようになっている。

また、船舶の属性情報が管理されており、船種ＩＤや船舶サイズＩＤによって正規化されている。本実施形態では、マップ上に表示する船舶のアイコンは、図９に貨物船の例を示すように、船種を連想できるイラストが画像データとして船種別に用意されている。貨物船やタンカー等の一般的な船種に限らず、自社船であることを示す「自社船」アイコンや、通信端末２００が搭載された船舶であることを示す「アプリ船」アイコン等があってもよい。本実施形態では、後に詳しく説明するように、これらの船種別アイコンを通常の表示態様としつつ、マップの表示範囲やモードに応じて異なる表示態様の船舶アイコンが用いられる。
また、マップ上の縮尺と船舶の大きさとの相対的な関係が維持されるように船舶アイコンの表示サイズを制御する構成となっており、図９に例示するように、「船舶サイズテーブル」で管理される船舶の全長及び型幅を示すデータに基づいて、アイコンの表示サイズを決定することができる。

ここで図１０は、操船者情報管理画面の例であり操船者の基本情報と合わせて、船舶免許に関する情報を参照及び入力するユーザインターフェイスとなっている。ここで入力されたデータは、図８に例示した「操船者テーブル」や「免許テーブル」に格納される。免許証を撮影した画像ファイルは、「免許テーブル」においては画像ＩＤで特定されるようになっている。

次に図１１は、船舶情報管理画面の例であり、船舶の基本情報と合わせて、船舶サイズや船種に関する情報を参照及び入力するユーザインターフェイスとなっている。また、船舶の外観を撮影した画像や船舶検査証の画像も登録できるようになっており、ここで入力されたデータは、図９に例示した「船舶テーブル」、「船種テーブル」、及び「船舶サイズテーブル」等に格納される。

図１２は、プロジェクト情報管理画面の例であり、プロジェクトの基本情報と合わせて、プロジェクトに参加している事業者の一覧及び、事業者別の基本情報や当該プロジェクトに割り当てられている操船者と船舶に関する情報を参照するユーザインターフェイスとなっている。プロジェクトＩＤによって識別されるアカウントにおいては、「プロジェクトテーブル」で管理されるプロジェクトの基本情報を変更することは認められているが、事業者によって割り当てられた操船者や船舶に関する情報については参照しか認められていない。

［２．２．３ プロット関連のテーブル構造］
次に、図１３は、プロット関連のテーブル構造とリレーションの一例を示す図である。プロットはプロットＩＤで識別され、プロットの種類を示すプロットカテゴリ、プロットによって情報を共有すべき対象物が存在する位置情報、及びプロット対象物の画像ファイルが紐づけられている。船舶アイコンと同様に、プロットにおいてもプロットカテゴリに応じたアイコンが画像として用意されており、図１３に例示するように、「灯台」のような海図記号に対応したアイコンや、「浮遊物」のような一時的な状況を示すアイコンがある。

具体的には、プロットの種類によっては、海図記号やマリーナの位置のように恒常的な対象物を示す揮発性の低い情報もあるが、浮遊物や取締船のような一時的に存在する対象物を示す揮発性の高い情報もある。強風や波浪のような気象・海象も比較的短期間で変動する事象である。一方、工事エリアのように、比較的長期間ではあるものの、期間が限定された対象もある。すでにその位置に存在しない対象物や、定められた期間が終了した事象がマップ上にいつまでも表示されると、操船者に無用な警告を促してしまい、かえって安全な操船の妨げとなる場合もある。本実施形態では、「プロットカテゴリテーブル」の１項目として、プロットの属性に応じた表示期限の有無や時間の長さ等を示す表示期限フラグを設け、「プロットテーブル」には表示期限となる日時が登録されるようになっている。表示期限はプロット作成時にユーザが具体的に指定してもよいし、表示期限フラグの種類に応じて自動的に算出されてもよい。

また、「プロットテーブル」では、位置情報からなるプロットポイントが一点で特定されるプロットか、複数のプロットポイントで特定されるプロットかを識別する「プロットタイプフラグ」が設定されており、複数のプロットポイントで特定される場合には、図１３に例示した「定置網」と記載された図形のように、複数のプロットポイントを頂点とした直線で構成されるベクトル図形としてマップ上に表示可能となる。なお、ベクトル図形は、複数のプロットポイントを制御点とする曲線であってもよい。

［３ 船舶動静共有航行支援システムの機能］
以下、本実施形態に係る船舶動静共有航行支援システムの主要な機能について説明する。
［３．１ マップ表示機能］
［３．１．１ レイヤ構造］
図１４は、通信端末２００及び陸上管理端末３００において表示されるマップ表示画面のレイヤ構造について説明する図である。ベースとなるマップデータが表示されるマップレイヤの上層には、所定の項目に関する統計情報が視覚的にヒートマップとして表示されるヒートマップ表示エリアがあり、複数のプロットポイントで特定されたエリアがベクトル図形として表示されるエリア表示レイヤがあり、その上層に一点のプロットポイントで特定されるプロット情報アイコンがラスタ画像として表示される情報アイコン表示レイヤがある。さらにその上層には、船舶アイコン表示レイヤ、船名表示レイヤ、航跡表示レイヤ、及び速度ベクトル表示レイヤが積層されており、船舶のみ表示する場合の他に、航跡及び速度ベクトルを選択的に表示可能となっている。レーダーモード画面の選択時においては、船舶の衝突を予防するための注意及び警告領域を船舶アイコンの上に表示する警告表示レイヤがあり、さらにその上層には、船舶上の通信端末２００における仮想無線の状態を示す無線アイコン表示レイヤが配置されている。

本実施形態では、図１５に例示するように、マップの縮尺に応じて船舶アイコンの表示形態を異ならせている。小縮尺で広域マップを表示すると、表示範囲内に多数の船舶アイコンが表示対象船舶となるが、すべてのアイコンを一律に表示すると、アイコンが過度に密集した表示となってしまう。そこで、航行中の船舶は上述したイラストの船種別アイコンで表示するが、停泊中の船舶については粒アイコン（円形）で表示するとともに、船舶アイコンが重複する場合には船名のテキスト表示数を制限することによって、表示される情報量の削減を図っている。

中縮尺で中域マップを表示する場合は、いずれの表示対象船舶も船種別アイコンを用いて表示されるが、上述のように、航行中の船舶には舷灯を灯火した態様のアイコンが用いられ、停泊中の船舶に舷灯を消灯した態様のアイコンが用いられる。これらの船種別アイコンは、マップの縮尺に応じて、データベース１５０に登録された船舶サイズに対応した大きさに調整されて表示される。

大縮尺で詳細マップを表示する場合には、船舶の位置情報の変化量が大きくなるので、船種にかかわらず、単純な五角形や三角形等のベクトル図形を組み合わせたポリゴンとして生成されたポリゴン船舶アイコン表示される。これにより、船舶アイコン表示にかかる処理負荷を低減し、船舶の位置情報の変化に応じたスムーズなマップ表示を可能としている。ポリゴン船舶アイコンも、船種別アイコンと同様に、マップの縮尺に応じて、データベース１５０に登録された船舶サイズに対応した大きさに調整されて表示される。

ここで図１６は、図１４において例示したレイヤ構成によって画面上に生成されたマップ表示のイメージ図である。この例では、船舶アイコンと合わせて船名がテキスト表示されており、さらに、航行中の船舶アイコンの船首方向に速度ベクトルが表示されているが、いずれの船舶に関しても航跡は表示されていない。すなわち、個別情報の表示の要否や表示態様についてはレイヤ別に制御できるようになっており、図１４に示した航跡表示レイヤの表示をオフにした場合の例である。
船舶アイコンに関連付けて船舶の画像及び船名や動静情報等が表示されており、「浮遊物」アイコンに関連付けて画像及びコメントが表示されているが、これらの詳細情報はアイコンをタップ等する操作によって表示のオン・オフを選択できるようにしてもよい。

ところで、図１６において点線で表示されている船舶アイコンＳＩｄは、船舶位置を非公表としている船舶を意味している。漁船やプレジャーボート等の操船においては、自船の位置を公表されることを望まない操船者も存在するが、船舶の衝突を予防するためには衝突可能性のある他船の位置や動静を監視する必要がある。海上衝突予防法においては、「互いに他の船舶の視野の内にある船舶の航法」として、船舶の種類や状態に応じて、操船時にとるべき動作が定められている。そこで本実施形態では、自船から目視可能と考えられる位置に存在する船舶についてはマップ上に表示するが、目視範囲外に位置する船舶アイコンは表示しない制御を行う。なお、目視可能な距離としては、現実的には操船席の海面からの高さや気象・海象によっても異なるが、例えば、COLREGS及び海上衝突予防法においてマスト灯の明かりが視認できる距離として規定されている６海里（約１１ｋｍ）程度に設定してもよい。

また、ＡＩＳで動静情報が送信される間隔は、船速等の状態に応じて２秒から３分までの幅が定められているが、この時間間隔を超えて動静情報が更新されない場合には、当該船舶のＡＩＳデータを正常に受信できていない可能性がある。ＡＩＳデータが正常に受信されている場合には「停泊もしくは錨泊中で、３ノット以上で動かない」状態でも３分間隔で状態が送信されるので、航行中の船舶から３分を超えてデータが更新されない場合には、当該船舶はすでに他の位置に移動してしまっている、あるいは、何らかの理由により誤ったデータが記録された可能性がある。そこで本実施形態では、マップ上に表示すべき他船として抽出された位置情報のうち、７分以内に取得されたデータであれば通常のアイコン表示を行うが、７分から１０分の間は疑わしい情報であることを操船者に提示するためにグレー（灰色）のアイコンで他船を表示し、１０分を超える場合にはマップ上に表示しないものとしている。なお、かかる判定基準は必ずしも7分や１０分に限るものではなく、これより短い時間でも長い時間で設定しても構わない。

［３．１．２ 船舶アイコン表示可否判定］
図１７は、船舶アイコンの表示可否について判定するフローチャートである。処理が開始されると、まず自船の位置情報がデータストア１４０から取得され（Ｓ１０１）、次いで、画面の表示範囲内に存在する他船情報がデータストア１４０から取得される（Ｓ１０２）。ここで情報が取得された船舶数に対して、以下のステップＳ１０３からＳ１０６の処理が繰り返し実行される。

まず判定対象船舶の位置公表フラグを参照し、位置を公表しない船舶であると判定された場合は（Ｓ１０３；Ｎｏ）、次に、当該船舶が自船の位置から目視可能距離に存在するか否かが判定される（Ｓ１０４）。ここで当該他船が目視可能距離の範囲には存在しないと判定された場合は（Ｓ１０４；Ｎｏ）、当該他船の船舶アイコンはマップ上に表示されない（Ｓ１０５）。

一方、ステップＳ１０４の判定において自船から目視可能距離に存在すると判定された場合（Ｓ１０４；Ｙｅｓ）あるいはステップＳ１０３において位置を公表すると判定された場合（Ｓ１０３；Ｙｅｓ）は、次に、当該他船の位置情報を取得した時刻を参照し、１０分以内に取得されたか否かが判定され（S１０６）、１０分以内に取得された位置情報ではないと判定されると（Ｓ１０６；Ｎｏ）、当該他船は非表示となる（Ｓ１０５）。他方、１０分以内に取得された位置情報であると判定された場合には（Ｓ１０６；Ｙｅｓ）、次に、７分以内に取得された位置情報であるか否かが判定される（Ｓ１０７）。ここで、位置情報を取得してから7分以内ではないと判定された場合は（Ｓ１０７；Ｎｏ）、当該他船はグレー（灰色）のアイコンで表示され（Ｓ１０８）、7分以内であると判定された場合は（Ｓ１０７；Ｙｅｓ）、当該他船は通常のアイコンで表示される（Ｓ１０９）。

［３．１．３ ヒートマップ］
図１８は、ヒートマップを表示した例であり、マップ上には、指定された情報に対応した数値に応じた大きさや色の円がヒートマップとして表示されており、その他に、船舶アイコンや、無線アイコン、情報アイコン等が表示されている。この図に示す例では、情報アイコンとして、海図情報としての航路が表示されており、ヒートマップの円は、所定期間における漁船の量を示している。海上交通安全法では、一定の大型船には航路航行義務が定められているが、漁労中の漁船については航法の例外が定められているので、漁船の通航量について傾向を把握する目的で表示されている。なお、ヒートマップ表示対象とする情報の種類、量、期間等については任意に設定可能であり、表示形態についても、円に限らず、多角形や線等を用いてもよい。

［３．２ 衝突予測機能］
［３．２．１ 画面イメージ］
次に、衝突予測機能について説明する。図１９は、通信端末２００に表示される衝突予測画面のイメージ図である。この図に例示する画面は、本実施形態では「レーダーモード」と名付けられており、船舶レーダーの表示画面と同様に、自船を中心とした円上に方位を示す数値を配し、あわせて他船の動静情報をアイコンとして表示するモードである。図１９の例においては、レーダーモード画面における他船は、船種や船舶サイズに対応したアイコンではなく、円や三角形等の単純な図形と速度ベクトルで表示されている。

図１９に示す例では、自船の針路である２２５°を上方に配置したコースアップ表示となっているが、北（０°）を上として表示するノースアップ表示への変更を指示するノースアップボタンＢｎｕが設けられている。自船アイコンの近傍には、船舶名並びに、自船の船速及び針路がテキスト表示されている。
また、自船の座標を中心として、警告領域を意味する第１の扇形Ｆ１及び注意領域を意味する第２の扇形Ｆ２の２種類の扇形が表示されている。第１の扇形Ｆ１は現在の船速及び針路を維持した場合に所定時間（第１の時間）で到達する距離に相当する長さを半径とし、自船の針路から±5°の方角に広がる中心角１０°の扇形である。この第１の扇形Ｆ１は、警告対象を検出するための警告領域として用いられる。第１の時間は、例えば、５分や３分等であり、自船と他船との関係を認識し、自船が針路を保持するか避航動作を行う必要があるか判断するために適切な時間が設定される。

このように針路からある程度の広がりを持った領域を、所定時間以内に当該船舶が航行する可能性の高い領域と仮定して衝突を予測することにより、他船の動静の他、波や風等の外乱の影響による針路のずれも考慮した衝突予測を行うことができる。なお、半径の長さや針路からの角度は必ずしも上述した数値に限られるものではなく、気象や海象に応じて調整してもよいし、自船の船種や、現在船速、運動性能等に応じて調整してもよい。さらに、操船者が任意に設定できるようにしてもよい。

本実施形態では、警告領域すなわち第１の扇形で規定される範囲内に他船が存在する場合及び、自船の警告領域と他船の警告領域が重複する場合であって所定の要件を満たすときに、これらの他船を警告対象船として画面に表示する。このように警告対象船が存在する場合には、警告領域は、例えば赤色等の一般的に警告を連想させる警告色を用いて表示され、同様に警告対象船も警告色で表示される。

第２の扇形Ｆ２は現在の船速及び針路を維持した場合に、所定時間（第２の時間）で到達する距離に相当する長さを半径とし、自船の針路から±１１２．５°の方角に広がる中心角２２５°の扇形である。この第２の扇形Ｆ２は、注意対象を検出するための注意領域として用いられる。第２の時間は、例えば３分や１分３０秒等であり、自船が針路を変更した場合に衝突の危険が発生する可能性がある船舶（潜在的警戒対象船）の存在や、自船の動きを考慮せずに航行しており、衝突を回避するために自船が協力動作を行わなければならない可能性がある船舶（要協力動作対象船）の存在に対して注意を払うことを促すために適切な時間が設定される。

COLREGS及び海上衝突予防法においては、舷灯の照射範囲は船首方位から左右それぞれ１１２．５°と規定されており、当該角度が他船から自船の右舷及び左舷として認識される範囲に相当する。そして「互いに他の船舶の視野の内にある船舶の航法」として、「二隻の動力船が互いに進路を横切る場合において衝突するおそれがあるときは、他の動力船を右舷側に見る動力船は、当該他の動力船の進路を避けなければならない」と規定されている。他船の左舷（赤色の舷灯）を見る船舶側が避航船となり、原則的に避航動作を行う必要があるが、避航船の動作のみでは衝突を避けることができないと認められる場合には、衝突を避けるための協力動作を行う必要がある。従って、自船が保持船である場合でも他船の避航動作に関する注意を行うべき領域と仮定した注意領域を表示することによって、操船者に対して他船との衝突を回避するためのサポートを行うことが可能となる。

なお、第１の扇形と同様に、半径の長さや針路からの角度は必ずしも上述した数値に限られるものではなく、気象や海象に応じて調整してもよいし、自船の船種や現在船速や運動性能等に応じて調整してもよい。操船者が任意に設定できるようにしてもよい。
本実施形態では、注意領域すなわち第２の扇形で規定される範囲内に他船が存在する場合は、これらの他船を注意対象船として画面に表示する。このように注意対象船が存在する場合には、注意領域は、例えば黄色や橙色等の一般的に注意を連想させる注意色を用いて表示され、同様に注意対象船も注意色で表示される。
警告対象にも注意対象にも該当しない非注意対象船については、青色や緑色等の寒色系の非注意色で表示され、非注意対象船しか周囲に存在しない場合には、自船の警告領域及び注意領域についても非注意色で表示される。

［３．２．２ 警告表示処理］
図１９に例示されている他船や警告領域及び注意領域を表示する処理の詳細について、以下、図２０から図２２のフローチャートを参照しながら説明する。
図２０は、レーダーモード表示にかかる処理を示すフローチャートである。この処理は、本実施形態ではアプリ２２０側で実行されるが、管理サーバ１００側で実行される形態であっても構わない。

処理が開始されると、自船の位置情報、船速、針路等の船舶情報がデータストア１４０から取得され（Ｓ２０１）、続いてマップの表示座標系における自船の位置座標及び速度ベクトルが算出され（Ｓ２０２）、自船の位置座標を中心として上述した自船の警告領域及び注意領域が算出される（Ｓ２０３）。次いで、一定範囲内に存在する他船情報がデータストア１４０から取得される（Ｓ２０４）。一定範囲としては、例えば緯度０．１°（約１１ｋｍ）相当の範囲や、画面への表示範囲等、適宜設定が可能であってもよい。ここで情報が取得された船舶数に対して、以下の警告対象船抽出処理（Ｓ２１０）及び注意対象船抽出処理（Ｓ２２０）が繰り返し実行される。

図２１は、警告対象船抽出処理を示すフローチャートである。まず判定対象船が自船の警戒領域内、すなわち第１の扇形として算出された領域内に位置するか否かが判定され（S２１１）、警告領域内と判定された場合は（S２１１；Ｙｅｓ）、当該他船は警告対象（警告対象船）であることを示すアイコンで表示され（Ｓ２１２）、算出された自船から警告対象船までの距離及び操船者に対して警告を促すテキストメッセージを表示する処理が行われる（Ｓ２１３）。そして、警告色で自船の第１の扇形が表示され（S２１４）、処理は終了する。

ステップＳ２１１において判定対象船が自船の警戒領域内には位置しないと判定された場合は（Ｓ２１１；Ｎｏ）、次に、判定対象船の警告領域が自船の警告領域と重複するか否か判定される（Ｓ２１５）。図１９の例では、「Ｘ丸」の警告領域が自船の警告領域と重複している。ここで、判定対象船の警告領域が自船の警告領域と重複すると判定されると（Ｓ２１５；Ｙｅｓ）、当該他船が接近中かどうか判定される（Ｓ２１６）。警告領域が重複していても針路が交差しない場合には、当該他船は自船から遠ざかっているので警告する必要はない。また、針路が交差する予定であっても相当時間先である場合に警告すると、警告の効果が薄れてしまう可能性もある。そこで、当該他船が接近中であると判定された場合には（Ｓ２１６；Ｙｅｓ）、一定時間以内に交差するか否か判定され（Ｓ２１７）、一定時間以内である場合には（Ｓ２１７；Ｙｅｓ）、交差までの予測時間と警告を促すテキストメッセージが表示され（Ｓ２１８）、処理はＳ２１４の処理に移行して、警告色で自船の第１の扇形が表示される。
ステップＳ２１５、Ｓ２１６、及びＳ２１７の判定結果がいずれもＮｏである場合には、当該他船が現段階では警告対象として表示する必要がないので、非警告色で自船の第１の扇形が表示され（Ｓ２１９）、処理は終了する。

図２２は、注意対象船抽出処理を示すフローチャートである。処理が開始されると、判定対象の船舶がステップＳ２１０で警告対象船として処理されたか否か判定され（Ｓ２２１）、すでに警告対象船となっている場合には（Ｓ２２１；Ｙｅｓ）、注意対象船抽出処理は終了する。一方、警告対象船でないと判定された場合には（Ｓ２２１；Ｎｏ）、当該船舶が自船の注意領域すなわち第２の扇形内に位置するか否かが判定される（Ｓ２２２）。ここで、注意領域内であると判定された場合は（Ｓ２２２；Ｙｅｓ）、当該船舶を注意対象船としてのアイコンで画面に表示する処理が行われ（Ｓ２２３）、算出された自船から注意対象船までの距離及び操船者に対して注意を促す表示する処理が行われる（Ｓ２２４）。そして、注意色で自船の第２の扇形が表示され（Ｓ２２５）、注意対象船抽出処理は終了する。
ステップＳ２２２の判定において注意領域外であると判定された場合は（Ｓ２２２；Ｎｏ）、当該船舶を非注意対象船としてのアイコンで画面に表示する処理が行われ（Ｓ２２６）、非注意色で自船の第２の扇形が表示されて（Ｓ２２７）、注意対象船抽出処理は終了する。

上記の例では、衝突予測機能は操船者２０が使用する通信端末２００において実行されるが、変形例として、運航事業者３０が陸上から自社船の航行状況を監視する場合に、陸上管理端末３００のブラウザ上でリアルタイムの衝突予測を表示する態様や、保険会社５０が契約船舶に関する事故の検証する場合等において、特定の時点における衝突予測の状況を再生表示する等の態様があってもよい。あるいは、輻輳海域の管制を行う管理者に対して、船舶の衝突が予測される態様を提示するために用いられてもよい。また、上記の例では、警告や注意を促すメッセージはテキスト表示であるが、図形アイコンであっても、音声メッセージであっても構わない。

［３．３ 仮想無線機能］
次に、仮想無線機能について説明する。本実施形態における仮想無線は、ＳＯＬＡＳ及び船舶安全規則において規定されている国際VHFと類似した双方向音声通信を実現する機能であり、船舶動静共有航行支援システムの利用者間において、通信端末２００あるいは陸上管理端末３００が標準的に備えるマイクやスピーカ等の音声処理デバイスとＩＰ通信機能を利用してＩＰネットワーク上で半二重通信を可能とするものである。

［３．３．１ 仮想無線機能の画面イメージ］
図２３は、仮想無線の機能を使用者に提示する画面イメージを示す図である。通信端末２００に表示された画面上の仮想無線ボタンＢ３を押下すると、仮想無線操作パネルＴＰが表示される。仮想無線機能においても国際VHFと同様に、通話したい人が無線機のＰＴＴボタンＢｐｔｔを押下している間は音声を送信でき、ＰＴＴボタンＢｐｔｔを押していない場合は受信待機状態となるプッシュ・トゥ・トーク (Push to Talk：PTT)方式で通話が行われる。半二重通信では、ＰＴＴ発話者外の聴取者は、ＰＴＴボタンを押下している者（ＰＴＴ発話）のみ発話が可能であり、その他のユーザは聴取のみ可能（ＰＴＴ聴取）となって、ＰＴＴ発話者がＰＴＴボタンを開放するまで、ＰＴＴボタンの押下や発話ができない。仮想無線操作パネルＴＰ上の通話状態を示すステータスランプＳＰは、待機状態においては灰色で表示されているが、ＰＴＴ発話時には緑色で表示され、受信時には赤色で表示される。

また、国際VHFにおいては、チャネル１６（156.8MHz）が、遭難安全・呼出し専用の共通チャネルとなっており、当該チャネルで他船を呼び出した後に他のチャネルに移動して直接の通話を行う。仮想無線においても同様の運用が想定されており、チャネル番号をテンキーで入力した後にＰＴＴボタンを押下することによって、変更後のチャネルによる音声の送受信が可能となる。仮想無線操作パネルＴＰには、通話が終了し、チャネル１６を聴取する状態に移動するためのチャネル１６ボタンＢｃ１６も設けられている。

船舶アイコン上には、アプリ２２０が起動された通信端末２００を搭載している船舶における仮想無線の状態を示す無線アイコンが表示されており、待機状態を示す無線アイコンＴＩ１及び通話状態を示す無線アイコンＴＩ２は、アイコンの色によって区別されている。例えば待機状態を示す無線アイコンＴＩ１は灰色で表示され、通話状態を示す無線アイコンＴＩ２は緑色で表示されてもよい。

国際VHFは最大出力電力が２５Ｗであり、通信距離は５０〜８０ｋｍが目安となっているが、小型船舶等が主に使用する出力電力５Ｗの無線機では、通信距離は１０〜３０ｋｍが目安となっている。仮想無線はＩＰネットワーク上で実現される通信であるため、出力電力や通信距離の制約がなく、遠隔地間の通話も可能である。しかしながら、自船の航行に影響を及ぼすことがない遠隔地にある船舶からの通信を受信すると、混乱が生じる可能性がある。そこで本実施形態では、船舶間の通信に用いる仮想無線は衝突回避に必要な距離に限定することによって、かかる混乱が生じないようにしている。衝突回避に通信が必要な距離としては、例えば出力電力５Ｗの無線機の通信距離に準じて、半径１０ｋｍの範囲としてもよい。

［３．３．２ 仮想無線機能に関する処理］
以下、図２４及び図２５に示すシーケンス図を参照しながら、仮想無線機能に関する処理について説明する。図２４は、接続から待機中の処理を示すシーケンス図である。仮想無線は、通信端末２００に搭載されたアプリ２２０が、管理サーバ１００に構築されている音声サーバ１３０に接続することによって実現される。音声サーバ１３０は、データストア１４０を用いてアプリ２２０毎の接続状態等を管理する。本実施形態では、音声サーバ１３０で用いる通信プロトコルとして、上述の通りWebSocketを用いており、データストアとしては、インメモリベースのキー・バリュー・ストア（Key-Value Store：ＫＶＳ）であるRedisを用いることにより処理を高速化している。なお、通信プロトコルやデータストアの方式はこれらに限定されるものではない。

国際VHFのチャネルは周波数で特定されるが、本実施形態では、チャネルｉｄを用いて特定される。アプリ２２０が音声サーバ１３０に接続すると（ｓ１１０１）、アプリ２２０は設定されているチャネル番号に対応するチャネルｉｄを位置情報及びタイムスタンプとともに音声サーバ１３０に送信して、当該チャネルによる参加を要求する（ｓ１１０２）。音声サーバ１３０は、データストア１４０に対して、いったん登録されているチャネルを消去する（ｓ１１０３）。なお、この時点で受信している音声があれば受信を停止する。次いで、現在設定されているチャネルｉｄを、位置情報及びアプリ２２０と接続しているソケットを特定するソケットｉｄとともに送信して追加し（ｓ１１０４）、期限が設定されたタイムスタンプをセットする（ｓ１１０５）。音声サーバ１３０は、この一連の処理を行った後に、アプリ２２０に対してチャネルｉｄによる参加の通知を行う（ｓ１１０６）。この図においてチャネル設定に関するアプリ２２０側の処理は省略されているが、起動時には初期状態としてチャネル１６に設定されており、ステップｓ１１０２ではチャネル１６に対応するチャネルｉｄが送信される。その後、仮想無線操作パネルＴＰの操作に基づいてチャネルが変更された際には、変更後のチャンネル番号に対応するチャネルｉｄが送信される。

アプリ２２０は、例えば１０秒毎等の一定周期で現在位置を音声サーバ１３０に通知することによって、データストア１４０に記憶される位置情報を更新し続ける。より具体的には、チャネルｉｄ、位置情報、及びタイムスタンプがアプリ２２０から通知され（ｓ１１０７）、音声サーバ１３０は、チャネルｉｄ、ソケットｉｄ、及び位置情報をデータストア１４０に追加し（ｓ１１０８）、期限付きのタイムスタンプをセットする（ｓ１１０９）。音声サーバ１３０は、この一連の処理を行った後に、アプリ２２０に対して位置情報の通知に対する応答を行う（ｓ１１１０）。ステップｓ１１０７からｓ１１１０の処理は、アプリ２２０が終了されるまで（ｓ１１１１）繰り返される。
アプリ２２０が終了されるとタイムスタンプが更新されないので、音声サーバ１３０はタイムスタンプの期限切れを認識すると（ｓ１１１２）、データストア１４０からチャネルを消去して（ｓ１１１３）、ソケット接続が切断される。

図２５は、ＰＴＴ通話時の処理を示すシーケンス図である。この図では、発話を行うアプリを２２０Ａとし、音声通信を聴取する側のアプリを２２０Ｂとしている。アプリ２２０Ｂは一つのみ記載されているが、複数であっても動作は同じである。
アプリ２２０ＡのＰＴＴボタンＢｐｔｔが押下されると（ｓ１２０１）、アプリ２２０Ａは音声サーバ１３０にＰＴＴボタンＢｐｔｔがオン状態となった旨を通知する（ｓ１２０２）。この際、アプリ２２０Ａは、チャネルｉｄ、位置情報、半径、及び自船の船舶ＩＤを通知する。音声サーバ１３０は、通知に基づいてセッションルーム作成し（ｓ１２０３）、発話可能となった旨の通知を、作成したセッションルームｉｄと発話可能な船舶ＩＤとを含めてアプリ２２０Ａに送信する（ｓ１２０４）。これを受けて、アプリ２２０ＡはステータスランプＳＰ及び無線アイコンＴＩの状態を緑色に変更し（ｓ１２０５）、通信端末２００のマイクをオンにする処理を行う（ｓ１２０６）。

音声サーバ１３０は、ＰＴＴ聴取側のアプリ２２０Ｂを特定するためにデータストア１４０に記憶されている船舶情報を検索する（ｓ１２０７）。上述したように、本実施形態では、発話する船舶を中心として半径１０ｋｍの範囲に位置する船舶に対して通話可能としているので、音声サーバ１３０は、ステップｓ１２０２においてアプリ２２０Ａから通知された位置情報及び半径を用いて検索範囲を算出し、かかる範囲に該当する位置情報を備える船舶上のアプリ２２０Ｂのソケットｉｄをデータストア１４０から検索する。

音声サーバ１３０は、ステップｓ１２０７において検索されたソケットｉｄを用いて、ＰＴＴ通話の受信が可能となった旨の通知をセッションルームｉｄと発話する船舶ＩＤとを含めて聴取側アプリ２２０Ｂに対して送信する（ｓ１２０８）。当該通知を受けたアプリ２２０Ｂは、ステータスランプＳＰ及び無線アイコンＴＩの状態を赤色に変更するとともに、ＰＴＴボタンＢｐｔｔの操作を無効にする処理を行う（ｓ１２０９）。

これら一連の処理を経てＰＴＴ通話が可能な状態となると、発話側のアプリ２２０Ａから音声サーバ１３０に音声データが送信され（ｓ１２１０）、音声サーバ１３０から聴取側のアプリ２２０Ｂに対して音声データがブロードキャストされるようになる（ｓ１２１１）。そして、音声データを受信したアプリ２２０Ｂが音声データを再生することによって（ｓ１２１２）、アプリ２２０Ａが発した音声通話を聴取することが可能となる。音声データの生成には、Voice over Internet Protocol（VoIP）用のコーデックを利用すればよく、例えば、G711、G722、G726、GSM、iLBC、Speex、Opus等が知られている。あるいは、音声ファイルの圧縮に広く用いられているMP3、AAC、WMA、WAV、AC3、FLAC等を用いてもよい。

ＰＴＴボタンＢｐｔｔの押下が開放されてオフ状態となったことを発話側のアプリ２２０Ａが検知すると（ｓ１２１３）、アプリ２２０ＡはＰＴＴがオフ状態となった旨の通知を音声サーバ１３０に送信する（ｓ１２１４）。この通知を受信した音声サーバ１３０は、セッションルームで参加中のアプリ２２０に対して通話を終了する旨の通知をブロードキャストする（ｓ１２１５）。かかる通知を受けたアプリ２２０Ａ及び２２０Ｂは、ステータスランプＳＰ及び無線アイコンＴＩの状態を灰色に変更するとともに、ＰＴＴボタンＢｐｔｔの操作を有効にする処理を行う（ｓ１２１６）。

本実施形態では、操船者２０の間でアプリ２２０上の仮想無線機能を用いた通話の他に、陸上管理端末３００を用いて、運航事業者３０や工事業者４０が操船者２０と音声コミュニケーションを図るためのグループ無線機能も、仮想無線機能の一つとして実現されている。ここで図２６はグループ無線機能を実行している陸上管理端末の画面イメージである。グループ無線においては、法人アカウントあるいはプロジェクトアカウントに対して固有のセッションルームを割り当てるため、上述の仮想無線とは異なり、チャネルを指定するパネルは不要となる。したがって陸上管理端末３００の画面上には、グループ無線の通話状態を示すステータスランプＳＬ及びＰＴＴボタンＢｐｔｔは表示されているが、テンキーやチャネル１６ボタンＢｃ１６は設けられていない。図２６に示す例では、あるプロジェクトにおけるマップ表示画面が示されており、運航中の船舶の一覧と船舶アイコンが表示されている。なお、この図の例では、航行中の船舶と停船中の警戒船については異なる態様で表示することによって、プロジェクトにおける船種や役割の相違を視覚的に理解が容易となっている。

［３．３．３ グループ無線機能に関する処理］
図２７は、グループ無線に係る処理を示すシーケンス図である。この図において、ＰＴＴ発話側はアプリ２２０であり、ＰＴＴ聴取側はブラウザ３１０である。グループ無線においては、チャネルｉｄのかわりにグループ識別コードを用いるものとし、グループ識別コードとしては、例えば、事業者ＩＤやプロジェクトＩＤをハッシュ化したコードを用いる。アプリ２２０及びブラウザ３１０は、グループ識別コードを音声サーバ１３０に通知してグループ無線へ参加する（ｓ２１０１）。音声サーバ１３０は、通知されたグループ識別コードに基づいてデータストア１４０に記憶するグループメンバーリストに追加し（ｓ２１０２）、アプリ２２０及びブラウザ３１０に対してグループ無線へ参加した旨の通知を行う（ｓ２１０３）。

グループ無線においては、あらかじめ通話を行う対象範囲が特定されているので、上述の仮想無線のように距離による通話範囲を考慮する必要はない。したがって、アプリ２２０においてＰＴＴボタンのオン状態が検出されると（ｓ２１０４）、ＰＴＴオンである旨の通知を音声サーバ１３０に送信する際には船舶ＩＤのみを含める（ｓ２１０５）。なお、ブラウザ３１０がＰＴＴ発話側となる場合には、陸上の事務所に対して何らかの船舶ＩＤを付与しておいてもよいし、船舶ＩＤ以外の識別子を用いてもよい。
ＰＴＴオン通知を受信した音声サーバ１３０がセッションルーム作成（ｓ２１０６）からアプリ２２０がマイクをオンにする処理（ｓ２１０９）までの連の動作は、図２３において説明したステップｓ１２０３からｓ１２０６と同様であるため、詳細な説明は省略する。

一方、音声サーバ１３０がセッションルームを作成した後（ｓ２１０６）、聴取側のアプリ２２０及びブラウザ３１０を特定するために、データストア１４０を検索してグループメンバーリストを取得する（ｓ２１１０）。このグループメンバーリストで特定されたアプリ２２０及びブラウザ３１０に対して音声サーバ１３０は受信可能となった旨を通知する（ｓ２１１１）。なお、当該通知を受信したアプリ２２０及びブラウザ３１０が行う処理（ｓ２１１２）以降、アプリ２２０及びブラウザ３１０がステータスランプＳＰ及び無線アイコンＴＩの状態を灰色に変更する処理（ｓ２１１９）は、図２３において説明したステップｓ１２０９からｓ１２１６と同様であるため、詳細な説明は省略する。

［２．５ 航路再生機能］
次に、図２８に示す航路再生アニメーションのイメージを参照しながら、航路再生機能について説明する。この図においては、３枚のフレームが例示されている。アニメーション作成時のフレームレートは任意であるが、船速に応じて適宜決定するようにしてもよい。

図９に例示したデータベース１５０の航海履歴位置テーブルを参照することによって、各フレーム作成を作成することができる。航路再生アニメーションの開始及び終了日時については、１航海分の全部であってもよいし、開始及び終了日時を指定できるようにしてもよい。なお、航路再生アニメーションは、再生が指示される都度作成してもよいし、作成されたアニメーションを動画ファイルとして保存できるようにしてもよい。

図２８に例示したフレームＦＬ１、ＦＬ２、ＦＬ３は、「Ｘ丸」を自船とした航路再生であり、他船として「ＡＢＣＤ」が表示されている。フレームＦＬ１においては、両船の針路が交差しており、自船が針路を維持すると衝突するおそれがある。「Ｘ丸」は「ＡＢＣＤ」を右に見る（赤色の左舷灯を見る）ので避航船となり、「ＡＢＣＤ」が保持船となる。ＦＬ１のシチュエーションにおいては、図１９を参照しながら説明したように、「Ｘ丸」側のアプリ２２０が提供する衝突予測機能によって、操船者２０に警告がなされている。フレームＦＬ２からは、警告を受けた「Ｘ丸」の操船者２０が減速した上で右回頭を開始したことがわかり、その後、フレームＦＬ３からは、「Ｘ丸」が「ＡＢＣＤ」の左舷側を通過することによって衝突を回避できたことがわかる。

航路再生アニメーションの表示画面には、フレームＦＬ３の表示例に示すように、再生箇所を示すシークバーを設けてもよく、警告が表示されていた時間帯等、再生時に注意するポイントに対応する再生箇所を示すマークと合わせて表示されるようにしてもよい。このような再生注視ポイントは、例えば警告表示や注意表示のような操船者に提示した情報に基づく条件設定であってもよいし、他の船舶との関係を所定のアルゴリズムで判定した操船危険度のような事後分析のための機能による条件設定であってもよい。

[３．４ 履歴出力機能]
次に、履歴出力機能について説明する。図２９は、操船を開始してから終了するまでの流れを概略的に示す図である。アプリ２２０は、操船開始及び終了を指示する操作インターフェイスを操船者２０に対して提供する。図２９に示す例では、操船者２０は、操船開始前に船舶、操船目的、及び役割を選択できるようになっており、これらの項目は、図８及び図９を参照して説明したベータベースの構成のように、正規化されて関連付けられており、予め選択可能な項目が特定されている。

操船者２０が操船開始ボタンＢｓを押下した操作は管理サーバ１００に送信され、ＡＰＩサーバ１１０によって提供される機能である航海コントローラ１１７に渡される。アプリ２２０から受信した操船者ＩＤ、船舶ＩＤ、操船目的ＩＤ、役割ＩＤ、及び日時とともに、操船開始日時がデータベース１５０の操船履歴テーブルに登録される。なお、操船者２０が運航事業者３０の業務として操船を行う場合には、操船者ＩＤは事業者ＩＤやプロジェクトＩＤに紐づけられているので、事業者ＩＤやプロジェクトＩＤも操船履歴テーブルに登録される。
操船終了時には、操船者２０が操船終了ボタンＢｅを押下した操作が管理サーバ１００に送信されと、操船距離とともに操船終了日時が算出され、データベース１５０に登録される。

このように、操船者２０毎に、操船した船舶、操船目的、及び役割と紐づけた操船履歴をデータベース上で管理できる。警戒船や作業船の搭乗要員については、経歴情報を管理して港湾管理者に提出する必要がある場合もあり、例えば海上保安庁の行政指導指針である「海上における工事作業等の警戒船の配備等に関する指針」では、警戒船の船長及び専従警戒要員又は警戒業務管理者等としての経歴や、管理講習受講年月日及び当該講習主催者名も提出することが要求されている。海技免状の維持には乗船履歴を管理することが義務づけられているが、小型船舶操縦免許では履歴を管理する制度がないので、このような情報を、運航状態や操船履歴としてシステム上で管理することによって、操船者の経歴管理も容易となる。

ここで、図３０は、ある操船者の操船履歴の表示例である。この例では、操船者２０個人の操船回数、操船時間、及び操船距離の合計を示すとともに、操船した船舶別の情報も提示している。操船履歴を航海毎にリスト表示するページへ遷移することができ、航海毎の操船履歴として、操船日、操船時間、及び操船距離の他に、図２８を用いて説明したような注視ポイントが発生した回数等も表示してもよい。
また、図３１は、プロジェクトにおける操船履歴の表示例であり、プロジェクトに紐づけられた航海履歴がリスト表示されている。リストの各行には、船名、操船目的、操船者、役割、合計時間、及び合計距離が表示されている。

[３．５ 監視領域作成機能]
[３．５．１ プロット作成画面]
次に、監視領域作成機能について説明する。図３２は、監視領域を設定するためのプロット作成画面の例である。監視領域としては、例えば、警戒船の配置が義務付けられている工事作業等の実施海域や、大規模な油濁事故が発生している海域等が想定される。本実施形態では、プロジェクトの対象となる工事の実施海域が監視領域として設定されており、運航される警戒船がプロジェクトにおいて管理されている。そして、設定された監視領域に侵入する恐れのある船舶が検出された場合には、警戒船に対して警告が発せられる。
プロジェクトの管理者は、マップ上の複数の点を指定することによって、実施海域の緯度及び経度を登録することができ、画面上で設定した領域を確認すると、決定ボタンＢｄを押下することによって、画面上で指定された緯度及び経度からなる位置情報がデータベース１５０に登録されるようになっている。

[３．５．２ プロット作成に関するデータ構成]
図３３は、監視領域として登録された位置情報と船舶情報に関するデータ構成を説明する図である。マップ上で指定された点に対応する緯度・経度を示すデータは、図１３において説明したように、複数のプロットポイントを有することを示すフラグがたてられたプロットＩＤに紐づけられた複数のプロットポイントＩＤとして管理される。

一方、操船者２０が使用するアプリ２２０が参照するデータストア１４０は、本実施形態においては、ドキュメント指向の非リレーショナルデータベースであり、監視領域を特定するプロットＩＤ、当該監視領域に配置されている警戒船の船舶ＩＤ、及びタイムスタンプが、一つのドキュメントとして管理されている。
また、データストア１４０には、航行中の船舶の警告領域（図１７参照）が監視領域に重複している船舶を管理するファイルも作成されている。警告領域ファイルには、監視領域を特定するプロットＩＤ、当該監視領域に警告領域が重複する船舶ＩＤ、及びタイムスタンプが一つのドキュメントとして管理されている。

[３．５．３ 警告表示例]
図３４及び図３５は、航行中の船舶が監視領域に接近した際にアプリに表示される画面のイメージである。図３４の例では「甲丸」が自船であり、警戒船としてプロジェクトに登録されている。「あいう丸」が、監視領域に接近している他船であり、警告領域が監視領域と重複している。また、仮想無線が待機状態であることを示すアイコンが表示されている。図３２は、アプリ２２０によって表示された警告メッセージによって注意喚起された「甲丸」の操船者２０が、「あいう丸」に対するコミュニケーションを促すべく、仮想無線のパネルを表示させている例である。図３５の例は、接近している船舶側のアプリ２２０に対して表示される警告例を示している。このように、監視領域に接近した船舶に対してアプリ２２０を通じた警告の表示や仮想無線による音声コミュニケーションを図ることができるので、工事エリア付近で停泊している船舶やすでに安全退避を行っている船舶に対しても警報を発令するといったような不要な警報の多発を回避することが可能となる。

[３．５．４ 監視領域に関する処理]
図３６は、監視領域に接近する船舶を検出する処理を示すフローチャートであり、この処理はアプリ２２０によって実行される。処理が開始されると、自船の船舶ＩＤを含む監視領域ドキュメントに設定されているプロットＩＤを含む警告領域ドキュメントがデータストア１４０に登録されているか否かが判定され（Ｓ３０１）、登録されている場合には（Ｓ３０１；Ｙｅｓ）、警告領域ドキュメント内の船舶ＩＤに基づいて当該船舶の警告領域が計算される（Ｓ３０２）。次いで、計算された警告領域がプロットＩＤで特定された監視領域と警告領域とが重複するか否か判定され（Ｓ３０３）、重複すると判定された場合には（Ｓ３０３；Ｙｅｓ）、図３２に例示したような警告表示が実行されて（Ｓ３０４）、処理が終了する。
ステップＳ３０３の判定において監視領域と警告領域とが重複しないと判定された場合には（Ｓ３０３；Ｎｏ）、データストア１４０から警告領域ドキュメントが削除されたのちに（Ｓ３０５）、処理が終了する。

ステップＳ３０１の判定において警告領域ドキュメントがデータストア１４０に登録されていないと判定された場合には（Ｓ３０１；Ｎｏ）、一定範囲内の周囲船舶の警告領域が計算され（Ｓ３０６）、計算された警告領域がプロットＩＤで特定された監視領域と警告領域とが重複するか否か判定される（Ｓ３０７）。監視領域と警告領域とが重複すると判定された場合には（Ｓ３０７；Ｙｅｓ）警告領域ドキュメントがデータストア１４０に登録され（Ｓ３０８）、重複しないと判定された場合には（Ｓ３０７；Ｎｏ）、警告領域ドキュメントが登録されることなく処理が終了する。

次に図３７は、警告領域ドキュメントに関する処理のフローチャートである。操船中ステータスとなっているアプリ２２０は、データストア１４０に登録されたドキュメントを参照し、図２０で説明したように自船から一定範囲にある他船を抽出するとともに、監視領域ドキュメントも監視している。自船の船舶ＩＤを含む警告領域ドキュメントがデータストア１４０に登録されているか否かが判定され（Ｓ３１１）、登録されていない場合には（Ｓ３１１；Ｎｏ）、自船の警告領域内に監視領域が存在するか否かが判定される（Ｓ３１２）。監視領域が存在すると判定された場合には（Ｓ３１２；Ｙｅｓ）、当該監視領域が一定時間以上継続して自船の警告領域と重複するか否かが判定される（Ｓ３１３）。自船の針路によっては、自船の警告領域が監視領域にわずかな時間だけ重複するような場合もあるため、一定時間以上継続して重複する場合のみ警告対象とすることが望ましい。

ステップＳ３１３において一定時間以上継続して重複すると判定された場合には（Ｓ３１３；Ｙｅｓ）、データストア１４０に警告領域ドキュメントが登録され（Ｓ３１４）、タイムスタンプが更新されて（Ｓ３１５）、処理は終了する。ステップＳ３１２において警告領域内に監視領域が存在しないと判定された場合には（Ｓ３１２；Ｎｏ）は、警告領域ドキュメントが登録されずに処理は終了する。

ステップＳ３１１において自船の船舶ＩＤを含む警告領域ドキュメントが登録されていると判定された場合には（Ｓ３１１；Ｙｅｓ）、警告領域がすでに監視領域がから抜けているか否かが判定され（Ｓ３１６）、監視領域から抜けていると判定された場合には（Ｓ３１６；Ｙｅｓ）、当該警告領域ドキュメントをデータストア１４０から削除して（Ｓ３１７）、処理は終了する。一方、ステップＳ３１６において警告領域が監視領域から抜けていないと判定された場合には（Ｓ３１６；Ｎｏ）、当該警告ドキュメントのタイムスタンプが更新される（Ｓ３１５）。

上述の例では、監視領域に接近する船舶が検出された際には警戒船のアプリ２２０に警告を表示するものとしているが、例えば漁業で利用するのであれば、図３８に例示するように、陸上の管理者が使用しているブラウザ３１０へ警告を表示するような態様でも構わない。この図の例では、監視領域としてプロット設定されている定置網に船舶が接近した際に、陸上の監視者に対して警告を表示する態様が示されている。

［４ オフライン時対応の構成］
上記の例では、通信端末２００がキャリアネットワークCNあるいはプライベートネットワークPNの通信圏内であることを前提としているが、海上においては、基地局からの距離や周囲の電波環境等によっては通信が不安定になる場合や、通信が途絶する場合がある。また、一般ユーザが用いている携帯電話やタブレットにおいて衛星データ通信を利用している場合は少ないと考えられるため、通信端末２００が管理サーバ１００にアクセスできない海域を航行する場合も想定される。
そこで、本実施形態では、通信状態が良好ではなく、通信端末２００が管理サーバ１００にアクセスできない環境においても、周囲の船舶が発するＡＩＳ電波を受信し、アプリ２２０単体で、自己位置と合わせて船をマップ表示し、衝突予測を実現する態様も備えている。

図４を用いて説明したように、海上ＡＩＳ受信装置９００は、周囲の船舶が発するＡＩＳ信号をVHFバンドで受信し、BLE送信する機能を備えている。アプリ２２０は、受送信プログラム９０１から受信したＡＩＳ船舶位置データと、測位プログラム２１０で生成された自船位置データに基づいてマップ表示及び衝突予測を行うことができる。

また、無線ネットワークの通信圏外においては、情報提供サーバ７００にアクセスすることもできないので、マップデータ７１０についてもオフライン利用となるが、通信端末２００のメモリにキャッシュされたマップデータを用いてマップ表示することができるように構成されている。
上述の例では、通信端末２００と海上ＡＩＳ受信装置９００との接続にはBLEを用いる構成を説明したが、これに限らず、通信端末２００とローカル接続が可能であれば、Wi-Fi等の他のアンライセンスバンドを利用した無線通信を用いてもよいし、イーサネット（登録商標）等の有線通信で接続する構成でもよい。

［５ 実施形態の効果］
以上、本実施形態に係る船舶動静共有航行支援システムによれば、自船及び周囲の他船の動静を操船者に対して提示するマップ画面は、直感的に把握しやすいユーザインターフェイスとなっており、システム利用者間の音声コミュニケーションを図ることが容易な構成となっている。そして、システムの利用にあたっては、無線利用に関する免許取得や無線局の開設手続きも不要であるため、ＡＩＳや国際VHFの搭載が義務づけられていない非SOLAS船に対しても普及が容易となる。

船舶動静共有航行支援システムは、船舶動静情報と操船者情報とを管理するプラットフォームとして用いることができ、ＡＰＩを公表することによって幅広い利用が容易となる。
通信状況は不安定な海域においては、海上ＡＩＳ受信装置９００と通信端末２００とをローカル接続することによって周囲のＡＩＳ船の動静を把握でき、通信端末２００にキャッシュされたマップデータを用いてマップ表示機能が提供されるので、通信環境の変化に対応することが可能となる。

また、自船の位置を公表しないことを希望する船舶については、概ね目視可能と想定される衝突予測に必要な距離に位置する船舶の動静のみ表示する機能を備えるので、匿名性と安全性を両立させることが可能となり、漁船やプレジャーボート等の非SOLAS船に対するシステム利用を促進することも容易となる。

工事作業が実施される海域を監視領域としてプロット設定することができ、監視領域に接近する船舶の動静を監視し、当該船舶や警戒船に対して警告を発することが可能となっているので、工事作業における安全性や利便性の向上を図ることができる。また、このような監視領域の設定及び警告に関する機能は、港湾管理者や漁業者にとっても利便性が高い。

また、データベースでは、操船者や船舶の情報が紐づけられて履歴管理されているので、警戒船の乗組員に関する乗船履歴や、保険料率の算定等にも利用することが可能となる。航海履歴はアニメーション再生することができるので、事故発生時における事後検証や、操船者の判断傾向や衝突事故の発生傾向を分析するために用いることもできる。操船者のキャリアアップや保険の優遇対象として操船履歴が用いられれば、非SOLAS船に対して、船舶動静共有航行支援システムの普及を促進することが容易となる。
したがって、船舶の衝突予防に有益な機能を、より多くの操船者に対して、より理解が容易な態様で提示することが可能となる。

１００…管理サーバ、１１０…ＡＰＩサーバ、１２０…Ｗｅｂサーバ、１３０…音声サーバ、１４０…データストア、１５０…データベース、１６０…バックエンドサービス、１７０…ＡＩＳ受信サーバ、２００…通信端末、２１０…測位プログラム、２２０…アプリ、３００…陸上管理端末、３１０…ブラウザ、７００…情報提供サーバ、７１０…マップデータ、８１０…陸上ＡＩＳ受信装置、８１１…受送信プログラム、９００…海上ＡＩＳ受信装置、９０１…受送信プログラム。

Claims (11)

1. 少なくとも操船者を識別する操船者識別情報、船舶を識別する船舶識別情報、並びに船舶の位置及び動静を示す船舶動静情報履歴を管理するデータベースと、
   船舶の少なくとも位置情報示す船舶位置データを受信し、前記データベースに記憶させるバックエンドサービスと、
   を含むバックエンドプラットフォームと、
   ユーザインターフェイスに対するデータ出力及びびユーザからの操作入力を受け付けるフロントエンドと、
   前記バックエンドプラットフォームと前記フロントエンドとのインターフェイスであるアプリケーションプログラミングインタフェース（Application Programming Interface：ＡＰＩ）と、
   を備え、
   前記ユーザインターフェイスは、前記データベースで管理された前記船舶動静情報に基づいて、マップデータで規定された形式に変換された船舶動静共有データを表示し、
   前記ＡＰＩは、前記ユーザインターフェイスを提供するアプリケーションを実行する通信端末が搭載された船舶の前記船舶識別情報と当該船舶を操船する操船者の前記操船者識別情報とを紐づける入力を、前記ユーザインターフェイスから受け付け、
   前記バックエンドサービスは、前記船舶識別情報及び前記操船者識別情報と、前記船舶動静情報とを紐づけて、前記船舶動静情報履歴として前記データベースに記憶させる、船舶動静共有航行支援システム。
2. 前記バックエンドプラットフォームは、前記船舶動静情報の現在値を保管するデータストアをさらに備え、
   前記バックエンドサービスは、前記データストアに前記船舶動静情報の最新情報を保管し、
   前記フロントエンドは、前記データストアに保管された前記船舶動静情報を前記ユーザインターフェイスに表示させる、
   請求項１に記載の船舶動静共有航行支援システム。
3. 前記船舶識別情報には、船舶サイズ及び船種が含まれ、
   前記船舶動静共有データとして前記ユーザインターフェイスに表示される船舶を示す船舶アイコンは、前記船種に応じた画像デザインであり、前記船舶サイズの縮尺が前記マップデータの縮尺に対応している、
   請求項１又は２に記載の船舶動静共有航行支援システム。
4. 前記船舶動静情報履歴には、日時情報、位置情報、船速情報及び針路情報が含まれ、
   前記ユーザインターフェイスは、前記位置情報、前記船速情報及び前記針路情報に基づいて算出された衝突予測領域に基づいて船舶の衝突予測を実行し、前記衝突予測に基づく警告を表示する、
   請求項１乃至３のいずれかに記載の船舶動静共有航行支援システム。
5. 前記衝突予測領域には、警告を促す警告領域及び注意を促す注意領域が含まれ、
   前記警告領域は、前記針路情報及び船速情報に基づいて算出された、所定時間以内に当該船舶が航行する可能性の高い領域として提示され、
   前記注意領域は、前記針路情報及び船速情報に基づいて算出された、他船の避航動作に関する注意を行うべき領域として提示される、
   請求項４に記載の船舶動静共有航行支援システム。
6. 前記データベースは、少なくとも位置情報を含むプロット情報をさらに管理し、
   前記ＡＰＩは、前記ユーザインターフェイスから前記プロット情報の入出力を受け付け、
   前記ユーザインターフェイスは、前記データベースに管理された前記プロット情報に対応するプロットデータを前記船舶動静共有データとあわせて表示する、
   請求項１乃至５のいずれかに記載の船舶動静共有航行支援システム。
7. 前記プロットデータは、船舶の接近に関する監視対象である監視領域を意味し、
   前記ユーザインターフェイスは、前記警告領域が前記監視領域と重複する場合には、警告を促す、
   請求項６に記載の船舶動静共有航行支援システム。
8. 前記バックエンドは、アプリケーションレイヤで動作する通信プロトコルを介した音声通話機能を提供する音声サーバをさらに備え、
   前記ユーザインターフェイスは船舶無線の操作インターフェイスを模した無線パネルを表示し、
   前記音声サーバは、前記無線パネルにおける操作入力及び前記ユーザインターフェイスを提供するアプリケーションに紐づけられた前記船舶情報に基づいて、複数の前記ユーザインターフェイスに対して音声データの送受信を制御する、
   請求項１乃至７のいずれかに記載の船舶動静共有航行支援システム。
9. 前記音声サーバは、前記無線パネルにおいて発話側の操作が検出された場合に、前記船舶情報に紐づいた前記船舶動静情報履歴に基づいて、前記発話側のアプリケーションに紐づけられた船舶から所定の範囲内に位置する船舶に紐づけられた前記アプリケーションを聴取側として特定して、音声データの送受信を制御する、
   請求項８に記載の船舶動静共有航行支援システム。
10. 前記データベースは、前記操船者識別情報及び前記船舶識別情報に紐づけられた所属をグループとして識別するグループ識別情報をさらに管理し、
    前記音声サーバは、前記無線パネルにおいて発話側の操作が検出された場合に、前記発話側のアプリケーションに紐づけられた前記グループ識別情報に基づいて、同一グループに属する前記アプリケーションを聴取側として特定して、音声データの送受信を制御する、
    請求項８に記載の船舶動静共有航行支援システム。
11. 前記ＡＰＩは、前記データベースに管理された前記操船者識別情報、前記船舶識別情報、及び船舶動静情報履歴に基づいて、操船者別の操船履歴及び船舶別の航海履歴を作成するためのデータを前記フロントサービスに提供し、
    前記フロントサービスは、作成した前記操船履歴及び航海履歴を前記ユーザインターフェイスに表示する、
    請求項１乃至１０のいずれかに記載の船舶動静共有航行支援システム。