特開 2024-76749 乗船者支援システム、ならびに乗船者支援システムのためのサーバ、通信機およびクライアント

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

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

(11)【公開番号】P2024076749

(43)【公開日】2024-06-06

(54)【発明の名称】乗船者支援システム、ならびに乗船者支援システムのためのサーバ、通信機およびクライアント

(51)【国際特許分類】

   H04M 11/00 20060101AFI20240530BHJP

   H04Q 9/00 20060101ALI20240530BHJP

   B63B 49/00 20060101ALI20240530BHJP

【ＦＩ】

H04M11/00 301

H04Q9/00 311H

B63B49/00 Z

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2022188463

(22)【出願日】2022-11-25

(71)【出願人】

【識別番号】000010076

【氏名又は名称】ヤマハ発動機株式会社

(74)【代理人】

【識別番号】110002310

【氏名又は名称】弁理士法人あい特許事務所

(72)【発明者】

【氏名】井上 良太

(72)【発明者】

【氏名】小野 利彦

(72)【発明者】

【氏名】竹内 章

(72)【発明者】

【氏名】北澤 康弘

(72)【発明者】

【氏名】橋本 晴彦

(72)【発明者】

【氏名】木下 嘉理

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

5K048

5K201

【Ｆターム（参考）】

5K048AA06

5K048BA35

5K048BA44

5K048DB01

5K048DC01

5K048EB10

5K048FB05

5K048FB09

5K048FC03

5K048GB05

5K048HA04

5K048HA06

5K048HA21

5K201AA02

5K201BA02

5K201CC02

5K201DC02

5K201EA05

5K201EA07

5K201EC06

5K201ED04

5K201ED09

5K201EF10

5K201FB08

(57)【要約】

【課題】船舶の状況をリアルタイムで監視・判定でき、したがって適切な対処に関する情報を短時間に提供できる乗船者支援システムを提供する。
【解決手段】乗船者支援システム１００は、船舶５に装備される機器の情報を収集して送信する通信機１と、通信機から情報を受信して蓄積するサーバ２と、サーバと通信して当該サーバから情報の提供を受けるクライアント３と、を含む。通信機は、定期送信周期でサーバへ情報を送信する定期送信モードと、定期送信周期よりも短い周期でサーバへ情報を送信する高速送信モードとを有する。サーバは、通信機から受信した情報に基づいて船舶の状況を判定し、その判定の結果に基づき、対処に関する情報をクライアントに送信する。クライアントは、サーバから提供される情報を使用者に提供する。サーバは、乗船者による復旧のための対処が可能かどうかを判定し、その判定結果の情報をクライアントに送信することが好ましい。
【選択図】図１

【特許請求の範囲】

【請求項1】

船舶に装備される機器の情報を収集して送信する通信機と、
前記通信機から情報を受信して蓄積するサーバと、
前記サーバと通信して当該サーバから情報の提供を受けるクライアントと、を含み、
前記通信機は、定期送信周期で前記サーバへ情報を送信する定期送信モードと、前記定期送信周期よりも短い周期で前記サーバへ情報を送信する高速送信モードとを有し、
前記サーバは、前記通信機から受信した情報に基づいて前記船舶の状況を判定し、その判定の結果に基づき、対処に関する情報を前記クライアントに送信し、
前記クライアントは、前記サーバから提供される情報を使用者に提供する、乗船者支援システム。

【請求項2】

前記サーバは、前記船舶の状況の判定結果に基づき、乗船者による復旧のための対処が可能かどうかを判定し、その判定結果の情報を前記クライアントに送信する、請求項１に記載の乗船者支援システム。

【請求項3】

前記サーバは、前記通信機から受信する複数の情報の組合せに基づいて、前記船舶の状況を判定する、請求項１に記載の乗船者支援システム。

【請求項4】

前記通信機は、前記サーバからの指令に応答して、前記定期送信モードから前記高速送信モードに切り替わる、請求項１に記載の乗船者支援システム。

【請求項5】

前記通信機は、前記船舶内に装備される指令装置からの指令に応答して、前記定期送信モードから前記高速送信モードに切り替わる、請求項１に記載の乗船者支援システム。

【請求項6】

前記サーバは、前記クライアントのウェブブラウザによって操作されるウェブアプリケーションプログラムを備えており、前記ウェブアプリケーションプログラムによって前記クライアントからの入力を受け付け、かつ前記クライアントに情報を提供する、請求項１に記載の乗船者支援システム。

【請求項7】

前記クライアントは、前記サーバにアクセス可能なアプリケーションプログラムを備え、前記アプリケーションプログラムの機能によって、前記サーバとの間で情報を授受する、請求項１に記載の乗船者支援システム。

【請求項8】

請求項１～７のいずれか一項に記載の乗船者支援システムにおいて用いられる前記サーバ。

【請求項9】

請求項１～７のいずれか一項に記載の乗船者支援システムにおいて用いられる前記通信機。

【請求項10】

請求項１～７のいずれか一項に記載の乗船者支援システムにおいて用いられる前記クライアント。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、乗船者支援システム、ならびに乗船者支援システムのためのサーバ、通信機およびクライアントに関する。

【背景技術】

【0002】

船長は、船舶の運航および安全管理に関する最高責任者であり、船体、推進機、その他の装備品の点検に関する責任、および出航前の様々な準備に関する責任を負う。航海中に生じるトラブルへの対処も船長の責任である。

【0003】

しかし、とりわけ、プレジャーボートに代表される小型船舶の船長の持つスキルは、必ずしも一様ではない。しかも、大型船舶とは異なり、船長以外に専門的な技術知識を有する乗員が乗り合わせることは必ずしも期待できない。したがって、とりわけ航海中に生じる船舶のトラブルに対する対処が容易でない場合もある。トラブルが生じたときの基本的な対処は、船舶に備えられるマニュアルに従って、原因を特定し、その特定された原因に対する適切な対処を行うことである。原因の特定またはその対処が困難な場合には、電話または無線通信によって救援を求めることになる。典型的には、マリーナやボートディーラのスタッフに対して救援が要請される。推進機にトラブルが生じて自力航行が不可能であれば、救援者が当該船舶まで行き、必要な修理を行うか、あるいは当該船舶を曳航するなどの救援措置を行う。

【0004】

特許文献１は、船体のリスクを管理するための機能を提供する船団運営支援システムを開示している。具体的には、船団を構成する船舶のセンシング機器が取得したセンシング結果が、通信端末から所定の時間間隔（たとえば、１分ごと）にサーバに送信されて、サーバに蓄積される。サーバは、センシング結果と閾値とを比較して異常判定を行い、異常が発生している場合には、船団を構成する各船舶に異常検知結果を送信する。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２１２１－１０８０１４号公報（図１０）

【発明の概要】

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

【0006】

特許文献１の先行技術は、センシング機器によって検出された異常症状を船舶に通知するけれども、それに対する対処は、当該船舶および船団を構成する他の船舶の乗員に委ねられる。異常症状の原因の特定は必ずしも容易ではないから、その場での対処は行わずに、帰港後に対処するのが一般的であろう。１分程度の間隔で定期的に送られる特定のセンシング結果の情報だけでサーバにおいて原因を特定することも必ずしも容易ではないから、サーバから原因および／または対処に関する情報を提供することも難しい。

【0007】

そこで、この発明の一実施形態は、船舶の状況をリアルタイムで監視・判定でき、したがって適切な対処に関する情報を短時間に提供できる乗船者支援システムを提供する。

【0008】

また、この発明の一実施形態は、上記のような乗船者支援システムを構成する、サーバ、通信機、およびクライアントを提供する。

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

【0009】

この発明の一実施形態は、船舶に装備される機器の情報を収集して送信する通信機と、前記通信機から情報を受信して蓄積するサーバと、前記サーバと通信して当該サーバから情報の提供を受けるクライアントと、を含む、乗船者支援システムを提供する。前記通信機は、定期送信周期で前記サーバへ情報を送信する定期送信モードと、前記定期送信周期よりも短い周期で前記サーバへ情報を送信する高速送信モードとを有する。前記サーバは、前記通信機から受信した情報に基づいて前記船舶の状況を判定し、その判定の結果に基づき、対処（より具体的には、必要なまたは可能な対処）に関する情報を前記クライアントに送信する。前記クライアントは、前記サーバから提供される情報を使用者に提供する。情報が提供される使用者は、典型的には、一般ユーザ、メーカ、ディーラまたはマリーナの担当者等である。

【0010】

この構成によれば、通信機は、船舶に装備される機器の情報を収集してサーバに送信し、サーバは、これを受信して蓄積する。通信機は、定期送信周期でサーバへ情報を送信する定期送信モードのほかに、より短い周期でサーバへ情報を送信する高速送信モードを有している。したがって、高速送信モードにおいては、通信機は、サーバに対してより多くの情報を短時間に送信することができる。サーバは、高速送信モードの通信機から多くの情報を短時間に収集できることにより、船舶の状況を実質的にリアルタイムで監視・判定でき、その適切な判定に基づいて、適切な（可能な）対処についての情報をクライアントに送信できる。この情報が使用者に提供されることにより、短時間で適切な対処を行うことができる。

【0011】

たとえば、故障が生じた場合に、通信機を高速送信モードで作動させることにより、大量の情報を短時間でサーバへと収集し、短時間で適切な対処手順を導くことができる。船上で可能な対処手順であれば、たとえば乗船者自らが対処を行うことができる。乗船者は自らのスキルが低くても適切な対処手順に短時間で到達できるので、故障からの復旧を速やかに果たすことができる。この場合、マリーナ、ディーラ等から救援者が当該船舶へと向かう必要がなくなるので、救援者の負担も軽減される。

【0012】

一方、通信機は通常時には省電力の定期送信モードで作動させることができるので、船上での電力消費量を抑制できる。したがって、省電力と、必要時の高速データ送信とを両立できる。

【0013】

この発明の一つの実施形態において、前記サーバは、前記船舶の状況の判定結果に基づき、乗船者による復旧のための対処が可能かどうかを判定し、その判定結果の情報を前記クライアントに送信する。この構成により、サーバは、復旧のために乗船者が対処できるかどうかの判定結果の情報をクライアントに提供する。したがって、乗船者が対処可能かどうかを速やかに知ることができ、乗船者による対処が不可能であれば、速やかに救援活動を開始することができる。

【0014】

この発明の一つの実施形態において、前記サーバは、前記通信機から受信する複数の情報の組合せ（より具体的には複数の情報の相関）に基づいて、前記船舶の状況を判定する。この構成により、複数の情報の組合せに基づく判断を速やかに行うことができるので、乗船者に対する支援を適切に行える。

【0015】

この発明の一つの実施形態において、前記通信機は、前記サーバからの指令に応答して、前記定期送信モードから前記高速送信モードに切り替わる。この構成によれば、サーバが大量の情報を必要とするときに、高速送信モードを活用して高速に情報を送信でき、それ以外のときには、省電力の定期送信モードで通信機を動作させることができる。

【0016】

この発明の一つの実施形態において、前記通信機は、前記船舶内に装備される指令装置からの指令に応答して、前記定期送信モードから前記高速送信モードに切り替わる。この構成によれば、必要時に、乗船者が指令装置から指令を与えることで、高速送信モードを活用して高速に情報を送信でき、それ以外のときには、省電力の定期送信モードにより通信機を動作させることができる。

【0017】

この発明の一つの実施形態において、前記サーバは、前記クライアントのウェブブラウザによって操作されるウェブアプリケーションプログラムを備えており、前記ウェブアプリケーションプログラムによって前記クライアントからの入力を受け付け、かつ前記クライアントに情報を提供する。

【0018】

この発明の一つの実施形態において、前記クライアントは、前記サーバにアクセス可能なアプリケーションプログラムを備え、前記アプリケーションプログラムの機能によって、前記サーバとの間で情報を授受する。

【0019】

前述の様々な特徴は、２以上の任意の組合せで組み合せることもできる。

【0020】

この発明の一実施形態は、前述のような特徴を有する乗船者支援システムにおいて用いられる前記サーバを提供する。

【0021】

この発明の一実施形態は、前述のような特徴を有する乗船者支援システムにおいて用いられる前記通信機を提供する。

【0022】

この発明の一実施形態は、前述のような特徴を有する乗船者支援システムにおいて用いられる前記クライアントを提供する。

【発明の効果】

【0023】

この発明によれば、船舶の状況をリアルタイムで監視・判定でき、したがって適切な対処に関する情報を短時間に提供できる乗船者支援システム、ならびにこのような乗船者支援システムを構成する、サーバ、通信機、およびクライアントを提供できる。

【図面の簡単な説明】

【0024】

【図1】図１は、この発明の一実施形態に係る乗船者支援システムの概要を説明するための図である。

【図2】図２は、船舶の構成例を説明するためのブロック図である。

【図3】図３は、サーバの構成例を説明するためのブロック図である。

【図4】図４は、サーバに備えられる判定条件マスタの一例を示す。

【図5】図５は、サーバに備えられる復旧作業マスタおよび電子マニュアルファイルの一例を示す。

【図6】図６は、通信機の構成例を示すブロック図である。

【図7A】図７Ａは、ディーラクライアントの構成例を説明するためのブロック図である。

【図7B】図７Ｂは、ユーザクライアントの構成例を説明するためのブロック図である。

【図8】図８は、クライアントにおける表示画面の一例を示す。

【図9】図９は、サーバにおける処理例を説明するためのフローチャートである。

【図10】図１０は、通信機における処理例を説明するためのフローチャートである。

【図11】図１１は、船舶においてトラブルが発生したときの流れの一例を示す。

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

【0025】

以下では、この発明の実施の形態を、添付図面を参照して詳細に説明する。

【0026】

図１は、この発明の一実施形態に係る乗船者支援システムの概要を説明するための図である。乗船者支援システム１００は、船舶５に装備される機器の情報を収集して送信する通信機１と、通信機１からの情報を受信して蓄積するサーバ２と、サーバ２と通信するクライアント３とを含む。通信機１は、船舶５に備え付けられていてもよい。また、通信機１は、持ち運び可能な形態の装置として構成され、必要に応じて、乗船者によって船舶５に持ち込まれる装置であってもよい。

【0027】

通信機１およびサーバ２は、ネットワーク４を介して通信可能である。すなわち、通信機１およびサーバ２は、それぞれネットワーク４に対して通信可能に接続されている。ネットワーク４は、典型的にはインターネット４Ａを含む。通信機１は、たとえば、携帯電話網等の無線データ通信網４Ｂに通信可能に接続されており、その無線データ通信網４Ｂを介してインターネット４Ａに通信可能に接続されている。

【0028】

クライアント３は、ディーラのオフィスおよび／またはマリーナのオフィスに備えられるクライアント端末装置（以下、「ディーラクライアント３Ｄ」という。）であってもよい。また、クライアント３は、使用者が携帯するスマートフォン等のモバイル端末装置（以下、「ユーザクライアント３Ｕ」という。）であってもよい。

【0029】

ディーラクライアント３Ｄは、オフィスに構築されたローカルエリアネットワーク（図示せず）を介してインターネット４Ａに接続可能に構成されていてもよいし、無線データ通信網４Ｂを介してインターネット４Ａに接続可能に構成されていてもよい。ユーザクライアント３Ｕは、典型的には、無線データ通信網４Ｂを介してインターネット４Ａに接続可能に構成されている。また、ユーザクライアント３Ｕは、船内で通信機１に対してデータ通信可能に接続されてもよい。この場合、ユーザクライアント３Ｕは、通信機１を介してネットワーク４に接続可能であってもよい。

【0030】

図２は、船舶５の構成例を説明するためのブロック図である。船舶５は、船体５１と、船体５１に艤装された様々な機器（艤装機器）とを含む。艤装機器は、典型的には、操船のための入力機器（操船機器）、船舶５に艤装された機器を統括制御するためのコントローラ８１、船体５１に推進力を与える推進機、船体５１の進行方向を変更するための転舵機器を含む。

【0031】

入力機器は、この例では、ステアリングホイール５２およびリモコン５５を含む。

【0032】

推進機は、この例では、船外機６０を含む。具体的には、一機以上の船外機６０が船尾に配置されている。この例では複数機（より具体的には３機）の船外機６０が、船尾に左右に並んで取り付けられている。この例では、船外機６０は、エンジン６１（内燃機関）を動力源としてプロペラ６５を駆動するエンジン船外機である。むろん、電動モータを動力源とする電動船外機が適用されてもよい。３機の船外機６０を区別するときには、中央の船外機６０を「中央船外機６０Ｃ」といい、その左右の船外機６０をそれぞれ「左舷船外機６０Ｐ」および「右舷船外機６０Ｓ」という。

【0033】

転舵機器は、この例では、船外機６０を左右に転舵させるステアリング７０である。各船外機６０に対して一つのステアリング７０が設けられており、この例では、３個のステアリング７０が設けられている。中央船外機６０Ｃ、左舷船外機６０Ｐおよび右舷船外機６０Ｓにそれぞれ対応するステアリング７０を区別するときには、「中央ステアリング７０Ｃ」、「左舷ステアリング７０Ｐ」および「右舷ステアリング７０Ｓ」という。

【0034】

ステアリングホイール５２は、操船者によって回動操作される。ステアリングホイール５２の操作角は、操作角センサ５３によって検出され、ヘルムＥＣＵ（電子制御ユニット）５４に入力される。リモコン５５は、船外機６０が発生する推進力の方向（前進または後進）および推進力の大きさを調整するために操船者によって操作されるアクセルレバー５６を備えている。アクセルレバー５６の操作位置は、アクセル位置センサ５７によって検出され、リモコンＥＣＵ５８に入力される。

【0035】

船外機６０は、エンジン６１と、エンジン６１によって駆動されるプロペラ６５と、シフト機構６６と、エンジンＥＣＵ６３とを含む。シフト機構６６は、複数のシフト位置、すなわち、前進位置、後進位置および中立位置を有する。前進位置は、エンジン６１の駆動力によってプロペラ６５を前進回転させるシフト位置である。後進位置は、エンジン６１の駆動力によってプロペラ６５を後進回転させるシフト位置である。中立位置は、エンジン６１とプロペラ６５との間の動力伝達を遮断するシフト位置である。エンジンＥＣＵ６３は、シフト機構６６を作動させるシフトアクチュエータ６７の動作を制御し、それによって、推進力の方向を制御する。また、エンジンＥＣＵ６３は、エンジン６１のスロットルバルブを駆動するスロットルアクチュエータ６２の動作を制御し、それによって、推進力の大きさを制御する。

【0036】

ステアリング７０は、ステアリングアクチュエータ７１と、それを制御するステアリングＥＣＵ７２とを含む。ステアリングアクチュエータ７１は、ステアリング軸（図示せず）まわりに船外機６０を左右に回動させるための動力を発生する。それにより、船外機６０が船体５１に与える推進力の方向が左右に変化し、船舶５の進行方向が変化する。ステアリング７０は、船外機６０と一体のユニットであってもよいし、船外機６０とは別体のユニットであってもよい。図２には、ステアリング７０が船外機６０と一体のユニットとして構成されている例を示す。

【0037】

ヘルムＥＣＵ５４は、操舵指令線７５を介して、ステアリングＥＣＵ７２に接続されている。操舵指令線７５は、図示のように、ヘルムＥＣＵ５４と全てのステアリング７０とを直接接続していてもよい。また、操舵指令線７５は、ヘルムＥＣＵ５４と左舷ステアリング７０Ｐおよび／または右舷ステアリング７０Ｓの各ステアリングＥＣＵ７２とを直接接続し、中央ステアリング７０ＣのステアリングＥＣＵ７２は、ヘルムＥＣＵ５４に直接接続していなくてもよい。すなわち、中央ステアリング７０ＣのステアリングＥＣＵ７２が、左舷ステアリング７０Ｐおよび／または右舷ステアリング７０ＳのステアリングＥＣＵ７２を介して間接的にヘルムＥＣＵ５４に接続されるように、操舵指令線７５が構成されていてもよい。操舵指令線７５は、ヘルムＥＣＵ５４が発生する操舵指令信号を伝送する。操舵指令信号は、ステアリングホイール５２の操作方向（回動方向）および操作角に対応する信号であり、船外機６０の転舵方向および転舵角を指令する信号である。

【0038】

リモコンＥＣＵ５８は、出力指令線７６を介して、エンジンＥＣＵ６３に接続されている。出力指令線７６は、この例では、リモコンＥＣＵ５８と全ての船外機６０のエンジンＥＣＵ６３とを直接接続している。ただし、操舵指令線７５の場合と同様に、出力指令線７６は、中央船外機６０ＣのエンジンＥＣＵ６３を、左舷船外機６０Ｐおよび／または右舷船外機６０ＳのエンジンＥＣＵ６３を経由して、リモコンＥＣＵ５８に接続していてもよい。出力指令線７６は、リモコンＥＣＵ５８が発生する出力指令を伝送する。出力指令は、各船外機６０の推進力の方向および大きさを指令する信号である。

【0039】

船内には、データ通信のためのネットワーク、すなわち、船内ＬＡＮ（ローカルエリアネットワーク）８０が構築されている。コントローラ８１は、船内ＬＡＮ８０に接続されている。さらに、ヘルムＥＣＵ５４、リモコンＥＣＵ５８、ステアリングＥＣＵ７２、およびエンジンＥＣＵ６３は、いずれも、船内ＬＡＮ８０に接続されている。

【0040】

コントローラ８１は、ヘルムＥＣＵ５４から操舵指令の情報を得ることができ、リモコンＥＣＵ５８から出力指令の情報を得ることができる。

【0041】

また、コントローラ８１は、ステアリングＥＣＵ７２から各種の情報を得ることができる。たとえば、ステアリングＥＣＵ７２が受信した操舵指令の情報、ステアリング７０に備えられる各種センサ類７３の検出結果の情報を得ることができる。センサ類７３は、たとえば、転舵角センサを含む。転舵角センサは、船外機６０の実際の転舵角を検出する。転舵角センサは、ステアリングアクチュエータ７１の作動量を検出するセンサであってもよい。

【0042】

さらに、コントローラ８１は、エンジンＥＣＵ６３から各種の情報を得ることができる。たとえば、エンジンＥＣＵ６３が受信した出力指令の情報、船外機６０に備えられる各種センサ類６４の検出結果の情報を得ることができる。センサ類６４は、たとえば、スロットル開度センサ、エンジン回転速度センサ、エンジン温度センサを含む。スロットル開度センサは、スロットルバルブの開度を検出するセンサである。エンジン回転速度は、エンジン６１の回転速度を検出するセンサであり、クランク角センサであってもよい。クランク角センサの出力をエンジンＥＣＵ６３で処理することにより、エンジン回転速度情報が生成されてもよい。エンジン温度センサは、エンジン６１のシリンダブロックの温度（たとえば冷却水の温度）を検出するセンサであってもよいし、エンジン６１の排気温度を検出するセンサであってもよい。

【0043】

船内ＬＡＮ８０には、さらに、各種情報を表示するゲージ８２、および通信機１が接続されている。通信機１は、船舶５の状況等の情報をサーバ２（図１参照）に送信するための装置である。

【0044】

ゲージ８２は、たとえば、燃料残量、各船外機６０のエンジン回転速度およびシフト位置、バッテリ残量等を表示する表示装置の機能を有する。バッテリ残量とは、エンジン始動のために船外機６０に内蔵されるスタータモータ（図示せず）を作動させるために船体５１に搭載されるバッテリ８８の残容量である。バッテリ８８は、エンジン始動の際に放電し、エンジン運転中は船外機６０に内蔵の発電機（図示せず）によって充電される。ゲージ８２は、入力ボタンやタッチパネル等の入力装置８３を備えていてもよく、使用者がその入力装置８３を操作することによって、各種の指令を入力できるようになっていてもよい。入力装置８３は、ゲージ８２とは別に設けられてもよい。

【0045】

これらの他にも、船内ＬＡＮ８０には各種の艤装機器をデータ通信可能に接続することができる。サードパーティ製の艤装機器は、典型的には、ゲートウェイ８４を介して船内ＬＡＮ８０に接続される。図２には、サードパーティ製の艤装機器の例として、ＧＰＳ(Global Positioning System)受信機８５、魚群探知機８６およびオートパイロット装置８７を示す。

【0046】

ステアリングホイール５２およびリモコン５５が配置される操船席には、船外機６０の電源を投入／遮断し、さらにそれらのエンジン６１を始動／停止するために操作されるメインスイッチ７７が備えられている。また、操船席には、緊急時に船外機６０の推進力を無効化する（典型的にはエンジン６１を停止する）ためのキルスイッチ７８（緊急停止スイッチ）が備えられている。キルスイッチ７８は、たとえば、操船者が装着するランヤードケーブルに結合される操作端を備えており、操船者の落水時に作動して、船外機６０のエンジン６１を緊急停止させる。

【0047】

図３は、サーバ２の構成例を説明するためのブロック図である。サーバ２は、コンピュータとしての基本構成を有する。すなわち、プロセッサ２１、メモリ２２、ストレージ２３、通信インタフェース２４および入出力インタフェース２５を備え、それらが、内部でデータ通信可能に接続されている。

【0048】

プロセッサ２１は、メモリ２２に格納されたプログラムに従って動作することにより、様々な機能を実現する。具体的には、通信機１（図１参照）と通信し、通信機１からデータを収集してストレージ２３に蓄積する機能が実現される。また、ディーラクライアント３Ｄ（図１参照）と通信し、ディーラクライアント３Ｄにウェブページを提供し、そのウェブページ上でウェブアプリケーションサービスを提供する機能が実現される。ウェブアプリケーションサービスを提供するために、メモリ２２にはウェブアプリケーションプログラムが備えられている。また、ユーザクライアント３Ｕ（図１参照）と通信し、ユーザクライアント３Ｕが備えるアプリケーションに情報を提供する機能が実現される。ストレージ２３は、データを蓄積するための記憶領域を提供する。通信インタフェース２４は、ネットワーク４との通信を仲介する。入出力インタフェース２５は、キーボード等の入力装置２６およびディスプレイ等の出力装置２７を含み、マンマシンインタフェースを提供する。

【0049】

ストレージ２３には、判定条件マスタＭ１、復旧作業マスタＭ２、電子マニュアルファイルＭ３等が格納されている。

【0050】

図４は、判定条件マスタＭ１の一例を示す。判定条件マスタＭ１は、複数の判定条件レコードを含むテーブルによって定義されるデータベースである。各判定条件レコードは、前提条件フィールド、センサフィールドおよび異常閾値フィールドで構成されている。前提条件フィールドには、判定条件を適用する場合の前提条件が記述されている。センサフィールドには、判定条件を適用すべきセンサの種別が記述されている。異常閾値フィールドには、センサの検出値と比較すべき閾値が記述されている。

【0051】

図４において前提条件フィールドに一例として記述されている「アイドリング判定成立」とは、アイドリング判定が成立することを表す。アイドリング判定とは、船外機６０のエンジン６１がアイドリング状態であるかどうかの判定であり、同判定が成立であれば、アイドリング状態である。「停止判定成立」とは、停止判定が成立することを表す。停止判定とは、船外機６０のエンジン６１が停止状態かどうかの判定であり、同判定が成立であれば、停止状態である。これらの判定結果は、通信機１との間の通信によって取得される。「症状：始動不可が入力された」とは、故障の症状として、船外機６０のエンジン６１が始動できないことが入力されたことを表す。この入力は、典型的には、クライアント３の操作によって、ディーラスタッフ、マリーナスタッフ、使用者等が行い、その入力結果を、クライアント３との間の通信によってサーバ２が取得する。

【0052】

図４にセンサフィールドに一例として記述されている「回転数」は、エンジン回転速度センサを表す。対応する異常閾値の例は、８００ｒｐｍとなっている。すなわち、第１行の判定条件レコードは、アイドリング判定が成立しているときに、エンジン回転速度センサの検出値が８００ｒｐｍ未満であれば、異常が生じている、ことを判定条件の一つとして定義している。同様に、「吸気圧」は、エンジン６１の吸気圧を検出する吸気圧センサを表す。対応する異常閾値の例は、３０ｋＰａとなっている。すなわち、第２行の判定条件レコードは、アイドリング判定が成立しているときに、吸気圧センサの検出値が３０ｋＰａ未満であれば、異常が生じている、ことを判定条件の一つとして定義している。「メインスイッチ」は、メインスイッチ７７（図２参照）を表す。メインスイッチ７７のオン状態が値「１」で表され、そのオフ状態が値「０」で表される。第３行の判定条件レコードは、アイドリング判定が成立しているときに、メインスイッチ７７の値が１未満、すなわち「０」であれば、異常が生じている、ことを判定条件の一つとして定義している。「キルスイッチ」は、キルスイッチ７８（図２参照）を表す。前述のとおり、キルスイッチ７８は、たとえば、ランヤードケーブルを介して操船者と結合され、操船者の落水によって操作されてオンとなり、エンジン６１を強制停止させる。キルスイッチ７８のオン状態が「１」で表され、そのオフ状態が「０」で表される。第４行の判定条件レコードは、停止判定が成立しているときに、キルスイッチの値が０より大きい、すなわち「１」であれば、異常が生じている、ことを判定条件の一つとして定義している。「シフトポジション」は、シフト位置センサを表す。たとえば、ニュートラル位置の検出状態が「０」、前進位置または後進位置の検出状態（シフトイン状態）が「１」でそれぞれ表される。第５行の判定条件レコードは、始動不可の症状が入力された場合に、シフト位置センサの値が０よりも大きい、すなわち、シフトイン状態であれば、異常が生じている、ことを判定条件の一つとして定義している。「バッテリ電圧」は、エンジン始動用のバッテリ８８の電圧である。対応する異常閾値の例は、９Ｖとなっている。すなわち、第６行の判定条件レコードは、始動不可の症状が入力された場合に、バッテリ８８の電圧が９Ｖ未満であれば、異常が生じている、ことを判定条件の一つとして定義している。

【0053】

図５は、復旧作業マスタＭ２および電子マニュアルファイルＭ３の一例を示す。復旧作業マスタＭ２は、複数の復旧作業レコードを含むテーブルによって定義されるデータベースである。各復旧作業レコードは、センサフィールド、症状フィールド、復旧可否フィールドおよび作業コードフィールドを含む。復旧可否フィールドは、センサフィールドに記述された種別のセンサの値が、症状フィールドに記述された状態（異常値）であるときに、乗船者による復旧作業が可能かどうかを表す可否判定値（可または不可）が記述されている。作業コードフィールドには、センサフィールドに記述された種別のセンサの値が、症状フィールドに記述された状態（異常値）であるときに実行すべき作業内容の識別子である作業コードが記述されている。作業コードは、電子マニュアルファイルＭ３の該当作業記述箇所に紐付けされている。電子マニュアルファイルＭ３は、作業者が実行すべき作業内容を詳しく記したマニュアルを格納しているファイルである。復旧可否フィールドの値は、作業コードに対応する作業内容が、乗船者によって実行可能かどうかという観点で予め定めた内容が記述されている。たとえば、乗船者が洋上で作業を行う場合を想定し、必要な工具、作業中の水濡れなどを考慮し、実行可能かどうかが予め判断され、その判断の結果が記述される。

【0054】

サーバ２における異常の有無の判定は、個々のセンサの値が正常か異常かに基づいて行われるほか、複数のセンサの値の組合せ、センサの値と症状の組合せなど、複数の検出項目および／または入力項目の相関に基づく正常／異常の判定も実行される。たとえば、メインスイッチ７７を始動位置まで操作すると、スタータモータに給電するためのスタートスイッチ（図示せず）がオン状態となる。しかし、キルスイッチ７８がオン状態であれば、スタータモータへの給電は行われず、エンジン６１を始動できない。このような場合には、スタートスイッチのオン状態およびキルスイッチ７８のオン状態が検知されるので、サーバ２は、それらの２つのセンサ値（２つのスイッチの状態）の組合せ（相関）に基づいて、キルスイッチ７８が異常値であると判断する。この場合の復旧作業は、キルスイッチ７８の再接続（オフ状態の復元）であり、この復旧作業は、乗船者自身が船上で実行可能である。

【0055】

乗船者による復旧作業が不可と判定される場合とは、たとえば、船舶に通常では装備されていない工具または設備が必要な場合が該当する。また、たとえば、船外機６０の部品を露出させる必要がある場合のように、特殊技術が必要であったり、洋上での作業に適さなかったりする場合も該当する。このような復旧作業は、整備士が洋上で対処したり、船舶を陸まで曳航したうえで実行したりする必要があるので、乗船者による対処は不可と判定される。

【0056】

図６は、通信機１の構成例を示すブロック図である。通信機１は、プロセッサ１１、メモリ１２、通信インタフェース１３、無線通信器１４を含む。プロセッサ１１は、メモリ１２に格納されたプログラムに従って動作することにより、複数の機能を実現する。通信インタフェース１３は、船内ＬＡＮ８０を介するデータ通信のためのインタフェースである。無線通信器１４は、ネットワーク４を介してサーバ２にデータを無線送信するための装置である。

【0057】

プロセッサ１１は、船内ＬＡＮ８０を介して、船体５１に装備された複数の機器からの情報を収集し、メモリ１２に格納するデータ収集機能を実行する。収集される情報は、船体５１に装備されている機器の機種名、個数、接続状況等を表す構成情報を含む。また、収集される情報は、様々なセンサ類の検出値を含む。具体的には、ヘルムＥＣＵ５４、リモコンＥＣＵ５８、ステアリングＥＣＵ７２およびエンジンＥＣＵ６３に接続されたセンサ類５３，５７，６４，７３の検出値が収集可能である。収集される情報は、さらに、ヘルムＥＣＵ５４、リモコンＥＣＵ５８、ステアリングＥＣＵ７２およびエンジンＥＣＵ６３が生成する情報を含んでいてもよい。このような情報は、各ＥＣＵが内部で生成する制御情報（制御指令その他のデータ）、各ＥＣＵが検出する故障情報などを含んでいてもよい。前述のとおり、メインスイッチ７７、キルスイッチ７８、スタートスイッチ等のスイッチ類もセンサと見なされ、それらの状態が検出値として収集される。プロセッサ１１は、さらに、船内ＬＡＮ８０に接続された様々な機器の状態を監視して、故障情報を生成する故障検知機能を有していてもよい。たとえば、各ＥＣＵの状態を監視し、電源電圧の瞬間的な低下に伴う動作の中断を故障（瞬停）として検出してもよい。収集された情報および生成された故障情報等は、メモリ１２に格納される。船内ＬＡＮ８０に接続された全ての機器からの情報が収集される必要はなく、たとえば、ゲートウェイ８４を介して接続されるサードパーティ製の機器は対象外であってもよい。

【0058】

プロセッサ１１は、これらの収集および／または自身が生成してメモリ１２に格納した情報の全部または一部を、無線通信器１４によって、サーバ２に向けて送信させる機能を有する。この実施形態では、２つの送信モード、すなわち、定期送信モードおよび高速送信モードが備えられている。

【0059】

定期送信モードは、定期送信周期でサーバ２へ情報を送信する通常送信モードである。定期送信周期は、たとえば１０分程度であってもよい。定期送信モードで送信される情報は、メモリ１２に格納した情報のうち、予め定めた定期送信情報に限られてもよい。故障情報等のとくに重要な情報は、定期送信情報に含められることが好ましい。定期送信情報は、サーバ２にアップロードされて蓄積され、主として、異常の有無、異常発生時の状況当を事後的に調査する目的で使用される。

【0060】

高速送信モードは、定期送信周期よりも短い高速送信周期でサーバ２へ情報を送信する緊急送信モードである。高速送信周期は、たとえば１秒程度であってもよい。高速送信モードで送信される情報は、定期送信モードで送信される情報よりも多いことが好ましい。具体的には、定期送信情報のほかに、故障原因の特定に有用な情報を可能な限り多く、サーバ２に送信することが好ましい。高速送信モードでサーバ２にアップロードされる情報は、主として、船舶５の状況をリアルタイムで監視・判定する目的で使用される。

【0061】

図７Ａは、ディーラクライアント３Ｄの構成例を説明するためのブロック図である。ディーラクライアント３Ｄは、コンピュータとしての基本構成を有している。たとえば、ディーラクライアント３Ｄは、クラムシェル型またはタブレット型のパーソナルコンピュータの形態を有していてもよい。

【0062】

ディーラクライアント３Ｄは、プロセッサ３１Ｄ、メモリ３２Ｄ、入力装置３３Ｄ、表示装置３４Ｄ、および通信インタフェース３５Ｄを含む。プロセッサ３１Ｄは、メモリ３２Ｄに格納されたプログラムを実行することにより様々な機能を実現する。入力装置３３Ｄは、表示装置３４Ｄの表示画面上のタッチパネルであってもよい。通信インタフェース３５Ｄは、ネットワーク４とのデータ通信を仲介する。通信インタフェース３５Ｄは、ディーラまたはマリーナ等のオフィスに設けられたローカルエリアネットワーク（図示せず）を介して、ネットワーク４（図１参照）と有線または無線でデータ通信するものであってもよい。また、通信インタフェース３５Ｄは、無線データ通信網４Ｂ（図１参照）に接続可能に構成されていてもよい。

【0063】

メモリ３２Ｄには、少なくともウェブブラウザのプログラムが格納されており、これをプロセッサ３１Ｄが実行することによって、ディーラクライアント３Ｄの使用者（ディーラスタッフ、マリーナスタッフ等）は、サーバ２が提供するウェブページを閲覧し、そのウェブページ上で提供されるウェブアプリケーションサービスを利用することができる。

【0064】

ディーラクライアント３Ｄの使用者は、ウェブページ９０（図８参照）を表示装置３４Ｄに表示させることができ、表示されたウェブページ９０から、顧客の船舶５の診断を要求したり、顧客の船舶５に生じている症状を入力したりすることができる。また、表示されたウェブページ９０から、顧客の船舶５に生じている症状の復旧に必要な作業内容を取得でき、かつその作業内容が乗船者によって実行可能かどうかについての情報を取得できる。

【0065】

図８に一例として示すウェブページ９０は、顧客の船舶５を特定するため情報を表示する船舶情報部９１と、船舶５を所有および／または使用する顧客の情報を表示する顧客情報部９２とを有している。ウェブページ９０は、さらに、表示情報を選択する表示情報選択部９３と、船舶５の状況を表示する情報表示部９４とを有している。

【0066】

表示情報選択部９３は、たとえば、通信機１が定期送信モードでサーバ２にアップロードする情報である通常ログ情報の閲覧を選択するための選択ボタン９３ａ(Normal Log)と、その通常ログの表示期間を指定する表示期間指定入力部９３ｂとを有する。表示情報選択部９３は、さらに、異常発生等のイベントの記録の閲覧を選択するための選択ボタン９３ｃ(Event Log)を有する。表示情報選択部９３は、さらに、通信機１が高速送信モードでサーバ２にアップロードする情報の表示を指令するための選択ボタン９３ｄ(Realtime Monitor)を有する。情報表示部９４は、選択ボタン９３ａ，９３ｃ，９３ｄの操作によって選択された情報を表示するエリアである。図８には、一例として、選択ボタン９３ｄが操作された場合のリアルタイムモニタ表示を示す。

【0067】

リアルタイムモニタのための選択ボタン９３ｄが操作されると、それに応答して、プロセッサ３１Ｄは、サーバ２に対して診断要求を送信する。この診断要求は、該当船舶５の通信機１の送信モードを高速送信モードに切り替えるべきことを表す高速送信モード指令を兼ねる。これを受信したサーバ２は、当該船舶５の通信機１に対して高速送信モード指令を送り、それに応じて、通信機１の送信モードが高速送信モードに切り替わる。その高速送信モードでサーバ２にアップロードされる情報が、ディーラクライアント３Ｄにおいて情報表示部９４に表示されることにより、船舶５の状況のリアルタイム表示が実現される。

【0068】

図８に示すリアルタイム表示の例は、検出項目９５（センサ種別等）、各検出項目の数値表示９６、各値の正常／異常表示９７、グラフ表示項目の選択ボタン９８、選択された表示項目のグラフ表示９９を含む。グラフ表示９９は、選択ボタン９８によって選択された検出項目の時間変化を表示する。数値表示９６、正常／異常表示９７およびグラフ表示９９は、サーバ２からの情報が更新されるたびに更新され、それによって、船舶５の状況をリアルタイムに表示できる。

【0069】

このような表示を高スキルの整備士等が確認することにより、船舶５の状況についての適切な判断が可能となる。それに応じて、乗船者に対する適切かつ迅速な支援が可能になる。また、正常／異常表示９７は、サーバ２における判定結果を表すので、この情報を得た高スキルの整備士等は、トラブル解消のための検査項目を予め絞ることができる。それによっても、適切かつ迅速な支援が可能になる。

【0070】

図７Ｂは、ユーザクライアント３Ｕの構成例を説明するためのブロック図である。ユーザクライアント３Ｕは、コンピュータとしての基本構成を有しており、より具体的には、モバイル端末装置、さらに具体的にはスマートフォンとしての基本形態を有している。ユーザクライアント３Ｕは、プロセッサ３１Ｕ、メモリ３２Ｕ、入力装置３３Ｕ、表示装置３４Ｕ、および無線通信インタフェース３５Ｕを含む。

【0071】

プロセッサ３１Ｕは、メモリ３２Ｕに格納されたプログラムを実行することにより様々な機能を実現する。入力装置３３Ｕは、表示装置３４Ｕの表示画面上のタッチパネルであってもよい。無線通信インタフェース３５Ｕは、ネットワーク４（より具体的には無線データ通信網４Ｂ）とのデータ通信を仲介する。無線通信インタフェース３５Ｕは、船内ＬＡＮ８０とのデータ通信を仲介するように構成されていてもよい。この場合、ユーザクライアント３Ｕは、船内ＬＡＮ８０および通信機１を介して、ネットワーク４に接続することができ、サーバ２との間でデータ通信を行うことができる。

【0072】

メモリ３２Ｕには、プロセッサ３１Ｕが実行可能なアプリケーションプログラム（いわゆるネイティブアプリケーションプログラム）が格納されており、これをプロセッサ３１Ｕが実行することによって、ユーザクライアント３Ｕの使用者（典型的には乗船者）は、アプリケーションプログラムの画面に、サーバ２が提供する情報を取得して表示させることができる。また、ユーザクライアント３Ｕの使用者は、アプリケーションプログラムの画面から、船舶５の診断を要求したり、船舶５に生じている症状を入力したりすることができる。また、ユーザクライアント３Ｕの使用者は、アプリケーションプログラムの画面から船舶５に生じている症状の復旧に必要な作業内容を取得でき、かつその作業内容が乗船者によって実行可能かどうかについての情報を取得できる。乗船者による作業が実行不可である場合には、作業内容の代わりに、救援を要請すべき旨の表示が提供されてもよい。

【0073】

図９は、サーバ２における処理例を説明するためのフローチャートである。クライアント３からの診断要求や症状の入力がない通常時には（ステップＳ１：ＮＯ）、サーバ２は、通信機１から定期送信周期で送信されてくる情報を受信し、その受信した情報をストレージ２３に蓄積する、通常ロギング動作（ステップＳ２，Ｓ３）を実行する。

【0074】

クライアント３から診断要求や症状の入力があると（ステップＳ１：ＹＥＳ）、サーバ２は、該当船舶５の通信機１に対して、高速送信モード指令を送信する（ステップＳ４）。これにより、通信機１の送信モードが、高速送信モードに切り替わる。サーバ２は、通信機１から高速送信周期で送信されてくる情報を受信し、ストレージ２３に蓄積する高速ロギング動作を実行する（ステップＳ５）。サーバ２は、必要な情報を受信すると、高速送信モード解除指令を通信機１へと送信してもよい（ステップＳ６）。高速送信モード解除指令を受信すると、通信機１は、その送信モードを定期送信モードへと切り替える。

【0075】

サーバ２は、高速ロギング動作によってサーバ２に蓄積した情報、およびクライアント３から入力された情報（症状）を判定条件マスタＭ１と照合し、船舶５の状況、具体的には、船舶５に異常が生じているかどうかを判定する（ステップＳ７）。サーバ２は、その判定結果に基づいて復旧作業マスタＭ２を参照し、該当する作業コードおよび復旧可否の情報を取得する（ステップＳ８）。サーバ２は、作業コードに紐付けられている電子マニュアルファイルＭ３の記事、すなわち作業手順を取得する（ステップＳ９）。そして、サーバ２は、その取得した作業手順および復旧可否の情報をクライアント３に送信する（ステップＳ１０）。

【0076】

図１０は、通信機１における処理例を説明するためのフローチャートである。通信機１のデフォルト送信モードは定期送信モードである（ステップＳ２１：ＹＥＳ）。高速送信モード指令が入力されない通常時には（ステップＳ２２：ＮＯ）、通信機１は、定期送信モードで動作し、定期送信動作を実行する。すなわち、通信機１は、定期送信周期が到来するたびに（ステップＳ２３：ＹＥＳ）、所定の定期送信情報を送信する（ステップＳ２４）。高速送信モード指令が入力されると（ステップＳ２２：ＹＥＳ）、通信機１は、送信モードを高速送信モードに切り替え（ステップＳ２５）、高速送信動作を実行する。すなわち、通信機１は、高速送信周期が到来するたびに（ステップＳ２６：ＹＥＳ）、所定の高速送信情報を送信する（ステップＳ２７）。高速送信情報は、定期送信情報とは異なる情報を含む。たとえば、高速送信情報は、定期送信情報を含み、さらに、定期送信情報以外の情報も含む。通信機１は、高速送信モード解除指令を受信するか（ステップＳ２８：ＹＥＳ）、または必要な情報の送信にかかる時間を考慮して予め定められる所定時間が経過すると（ステップＳ２９：ＹＥＳ）、高速送信モードを解除して、送信モードを定期送信モードに切り替える（ステップＳ３０）。

【0077】

高速送信モード指令は、サーバ２から通信機１へと送信される代わりに、船舶５に備えられた入力装置８３（図２参照）の操作によって通信機１に与えられてもよい。この場合、入力装置８３は、通信機１に送信モードを指令する指令装置の一例である。高速送信モード解除指令についても同様である。前述のように、通信機１が、所定時間の経過によって高速送信モードを解除するように構成されている場合には、高速送信モード解除指令は省かれてもよい。

【0078】

図１１は、船舶５においてトラブルが発生したときの流れの一例を示す。乗船者は、携帯電話機や無線通信装置（たとえば、ユーザクライアント３Ｕの機能を有するスマートフォン）を用いて、ディーラまたはマリーナの担当者に連絡をとり、状況を説明する。連絡を受けた担当者は、ディーラクライアント３Ｄを操作し、サーバ２が提供するウェブページから、当該船舶５の診断を要求する。必要に応じて、担当者は、ディーラクライアント３Ｄを操作し、そのウェブページ上で、症状や状況（ユーザの操作内容など）を入力する。

【0079】

診断要求を受けたサーバ２は、当該船舶５の通信機１に対して高速送信モード指令を送信する。それにより、通信機１は、高速送信モードに切り替わり、診断に必要な情報（構成情報、故障情報、各種センサ値）が高速でサーバ２へとアップロードされる（高速ロギング）。

【0080】

必要な情報が収集されると、サーバ２は、判定条件マスタＭ１、復旧作業マスタＭ２および電子マニュアルファイルＭ３を参照し、作業手順および乗船者による作業の可否の情報を、ウェブページ上でディーラクライアント３Ｄに提供する。作業手順の情報は、典型的には文字による記述を含み、好ましくは、さらに要部の図面表示を含む。

【0081】

ディーラクライアント３Ｄに表示された情報に基づいて、ディーラまたはマリーナの担当者は、乗船者に対して、状況を伝える。具体的には、乗船者による作業が可能である場合には、作業内容を乗船者に伝えて、復旧作業を促す。したがって、乗船者はマニュアルを参照するよりも一層速やかに適切な対処を行うことができる。しかも、マニュアルに頼るよりも対処法を理解しやすくなる利点もある。

【0082】

乗船者による復旧作業が不可能である場合には、ディーラまたはマリーナのスタッフは、救援に向かう旨を乗船者に伝え、救援の準備を行うことになる。救援者は、ディーラクライアント３Ｄを携帯して当該船舶５への救援に向かってもよい。その場合には、必要に応じて、当該船舶５に到着後に、必要な診断をサーバ２に対して追加で要求し、その診断結果の情報を得ることができる。

【0083】

前述のとおり、ディーラクライアント３Ｄには、高速送信モードでサーバ２にアップロードされた情報が、可視化されて伝達されてもよい。より具体的には、数値表示またはグラフ表示によって、サーバ２から情報提供されてもよい（図８参照）。とくに、異常が検知されたデータやセンサ値を強調して表示されることが好ましい。とりわけ、主推進機である船外機６０（とくにエンジン６１）およびそれに関わる操船機器（ステアリングホイール５２、リモコン５５等）の状態を表すデータやセンサ値の数値表示またはグラフ表示が可能であることが好ましい。このような表示を高スキルの整備士等が確認することにより、船舶５の状況についての一層適切な判断が可能であり、かつ乗船者に対する適切かつ迅速な支援が可能になる。とくに、サーバ２における判定結果がディーラクライアント３Ｄを介して高スキルの整備士等に伝達されることにより、トラブル解消のための検査項目を予め絞ることができる。それによっても、適切かつ迅速な支援が可能になる。

【0084】

乗船者がユーザクライアント３Ｕを保持しているときには、乗船者は、ディーラまたはマリーナの担当者に連絡をとる前に、サーバ２に対して診断要求を送信し、必要に応じて、症状や状況を入力してもよい。この場合には、サーバ２は、ユーザクライアント３Ｕに対して、作業手順および乗船者による作業可否の情報を提供する。乗船者による復旧作業が可能であれば、乗船者はその作業を実行して復旧を試みる。乗船者による復旧が不可能であれば、乗船者は、マリーナまたはディーラの担当者に連絡をとって、救援を要請する。

【0085】

このようにして、船舶５においてトラブルが生じたときに、迅速に船舶５の状況を判定し、適切な対処を行うことができる。乗船者による復旧が可能なときには、速やかにトラブルを解消できる。その場合には、マリーナまたはディーラからの救援の必要がなくなるので、救援側の負担も軽減される。

【0086】

通信機１は、通常時には省電力の定期送信モードで作動させることができるので、船上での電力消費量を抑制でき、かつ通信コストを抑制できる。その一方で、トラブル発生時には、高速送信モードが起動されることで、高速に大量の情報をサーバ２にアップロードできるので、サーバ２において、迅速な判定が可能になる。高速送信モードは、必要時に一時的に起動され、データ送信の周期および／または送信内容の変更は一時的であるので、電力消費量および／または通信コストが過大になることはない。

【0087】

サーバ２は、通信機１からアップロードされた情報や、ディーラクライアント３Ｄまたはユーザクライアント３Ｕから入力された情報に基づいて、速やかに判定を行う。とくに、単一のセンサ値または症状に基づく判定のみならず、複数のセンサ値や症状等の組合せ（相関）に基づく判定を行うことも可能である。それにより、高度なスキルを有する整備士に匹敵するレベルで船舶５の状況を速やかに判定できるので、乗船者に対する支援を適切かつ迅速に行える。

【0088】

以上、この発明の一実施形態について説明してきたが、この発明は、さらに他の形態で実施することもできる。

【0089】

たとえば、前述の実施形態では、ディーラクライアント３Ｄは、サーバ２が提供するウェブアプリケーションをウェブブラウザ上で使用する構成となっている。しかし、ユーザクライアント３Ｕと同様に、ディーラクライアント３Ｄにインストールされた専用のアプリケーションプログラムを使用する構成としてもよい。また、前述の実施形態では、ユーザクライアント３Ｕは、インストール済みの専用のアプリケーションプログラムを使用してサーバ２から情報を得る構成となっている。しかし、ディーラクライアント３Ｄと同様に、サーバ２が提供するウェブアプリケーションをウェブブラウザ上で使用する構成としてもよい。

【0090】

また、前述の実施形態では、乗船者からの連絡に対する対応をディーラまたはマリーナの担当者が行う例について説明したが、たとえば、ユーザ対応を行うコールセンターの担当者が同様の対応を行ってもよい。

【0091】

また、前述の実施形態では、推進機の例として船外機を挙げているが、船舶に備えられる推進機の構成は、船内機、船内外機、ジェット推進機等の様々な形態であり得る。

【0092】

その他、特許請求の範囲に記載された事項の範囲で種々の設計変更を施すことが可能である。

【符号の説明】

【0093】

１ 通信機、２ サーバ、３ クライアント、３Ｄ ディーラクライアント、３Ｕ ユーザクライアント、４ ネットワーク、５ 船舶、５１ 船体、５２ ステアリングホイール、５３ 操作角センサ、５４ ヘルムＥＣＵ、５５ リモコン、５６ アクセルレバー、５７ アクセル位置センサ、５８ リモコンＥＣＵ、６０ 船外機、６１ エンジン、６３ エンジンＥＣＵ、６４ センサ類、７０ ステアリング、７２ ステアリングＥＣＵ、７３ センサ類、７７ メインスイッチ、７８ キルスイッチ、８０ 船内ＬＡＮ、８１ コントローラ、８２ ゲージ、８３ 入力装置、８８ バッテリ、９０ ウェブページ、９４ 情報表示部、９５ 検出項目、９６ 数値表示、９７ 異常表示、９９ グラフ表示、１００ 乗船者支援システム、Ｍ１ 判定条件マスタ、Ｍ２ 復旧作業マスタ、Ｍ３ 電子マニュアルファイル

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8】

【図9】

【図10】

【図11】