特開2022-71825機器診断装置、遠隔機器監視方法、遠隔機器監視システム及び機器診断プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022071825
(43)【公開日】2022-05-16
(54)【発明の名称】機器診断装置、遠隔機器監視方法、遠隔機器監視システム及び機器診断プログラム
(51)【国際特許分類】
H04L 43/00 20220101AFI20220509BHJP
H04L 13/00 20060101ALI20220509BHJP
G06F 11/07 20060101ALI20220509BHJP
【ＦＩ】
H04L12/26
H04L13/00 313
G06F11/07 140Q
G06F11/07 175
【審査請求】未請求
【請求項の数】25
【出願形態】ＯＬ
(21)【出願番号】P 2021149787
(22)【出願日】2021-09-14
(31)【優先権主張番号】20204451.7
(32)【優先日】2020-10-28
(33)【優先権主張国・地域又は機関】EP
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
(71)【出願人】
【識別番号】521406178
【氏名又は名称】フルノヘラス エス．エイ．
【氏名又は名称原語表記】Ｆｕｒｕｎｏ Ｈｅｌｌａｓ Ｓ．Ａ．
【住所又は居所原語表記】１０ Ｔｈｅｔｉｄｏｓ ｓｔｒ． １６６７５ Ｇｌｙｆａｄａ， Ｇｒｅｅｃｅ
(74)【代理人】
【識別番号】100204825
【弁理士】
【氏名又は名称】渡辺 健一
(72)【発明者】
【氏名】ニコラス スタブロウ
【テーマコード（参考）】
5B042
5K030
5K035
【Ｆターム（参考）】
5B042KK13
5B042MA08
5B042MA09
5B042MC40
5K030GA12
5K030JA10
5K030MB20
5K030MC09
5K035AA03
5K035DD01
5K035FF04
5K035JJ01
5K035MM03
(57)【要約】
【課題】
水上の移動体にある舶用電子機器の故障に関する情報を提供し、遠隔機器監視センターとの間で通信し、故障した舶用電子機器の効率的なトラブルシューティングを可能にする。
【解決手段】
機器診断装置１０３は、遠隔機器監視センター１１３から、水上を移動する移動体１０１上の一つ又は複数の舶用電子機器１０７を監視するために提供される。機器診断装置１０３は、舶用電子機器１０７から一つ又は複数のメッセージを受信する受信部１２３と、一つ又は複数のメッセージに基づいて舶用電子機器１０７の故障を検出する検出部１２５と、故障の診断結果を示す故障検出情報を遠隔機器監視センター１１３に送信する送信部１２７とを含む。
【選択図】図１
水上の移動体にある舶用電子機器の故障に関する情報を提供し、遠隔機器監視センターとの間で通信し、故障した舶用電子機器の効率的なトラブルシューティングを可能にする。
【解決手段】
機器診断装置１０３は、遠隔機器監視センター１１３から、水上を移動する移動体１０１上の一つ又は複数の舶用電子機器１０７を監視するために提供される。機器診断装置１０３は、舶用電子機器１０７から一つ又は複数のメッセージを受信する受信部１２３と、一つ又は複数のメッセージに基づいて舶用電子機器１０７の故障を検出する検出部１２５と、故障の診断結果を示す故障検出情報を遠隔機器監視センター１１３に送信する送信部１２７とを含む。
【選択図】図１
【特許請求の範囲】
【請求項1】
移動体に搭載された１又は複数の電子機器を診断する機器診断装置であって、
前記電子機器を識別する識別データと、前記電子機器の警報状態を示す警報状態データを含む１又は複数のメッセージを電子機器から受信する受信部と、
前記警報状態データが示す、第１の時点における警報状態と該第１の時点より以前の第２の時点における警報状態との比較に基づいて前記電子機器の故障を検出し故障検出情報を出力する検出部と、
前記故障検出情報の出力を契機に、前記故障検出情報を故障が検出された前記電子機器の識別データとともに遠隔機器監視センターに送信する送信部と、
を備える機器診断装置。
前記電子機器を識別する識別データと、前記電子機器の警報状態を示す警報状態データを含む１又は複数のメッセージを電子機器から受信する受信部と、
前記警報状態データが示す、第１の時点における警報状態と該第１の時点より以前の第２の時点における警報状態との比較に基づいて前記電子機器の故障を検出し故障検出情報を出力する検出部と、
前記故障検出情報の出力を契機に、前記故障検出情報を故障が検出された前記電子機器の識別データとともに遠隔機器監視センターに送信する送信部と、
を備える機器診断装置。
【請求項2】
請求項１に記載の機器診断装置であって、
前記受信部は、バックグラウンドプロセスにより前記メッセージを受信する、
機器診断装置。
前記受信部は、バックグラウンドプロセスにより前記メッセージを受信する、
機器診断装置。
【請求項3】
移動体に搭載された１又は複数の電子機器を診断する機器診断装置であって、
前記電子機器を識別する識別データと、前記電子機器の警報状態を示す警報状態データを含む１又は複数のメッセージを前記電子機器から前記メッセージを予定された時間間隔で受信する受信部と、
前記時間間隔に基づいて定められた受信の時点を示すタイムスタンプのうち、第１のタイムスタンプと該第１のタイムスタンプが示す時点よりも以前の時点の第２のタイムスタンプとの間で前記警報状態データに変化があるかを前記メッセージに基づいて検知して故障検出情報を出力する検出部と、
前記故障検出情報の出力を契機に、前記故障検出情報を故障が検出された前記電子機器の識別データとともに前記遠隔機器監視センターに送信する送信部と、
を備える機器診断装置。
前記電子機器を識別する識別データと、前記電子機器の警報状態を示す警報状態データを含む１又は複数のメッセージを前記電子機器から前記メッセージを予定された時間間隔で受信する受信部と、
前記時間間隔に基づいて定められた受信の時点を示すタイムスタンプのうち、第１のタイムスタンプと該第１のタイムスタンプが示す時点よりも以前の時点の第２のタイムスタンプとの間で前記警報状態データに変化があるかを前記メッセージに基づいて検知して故障検出情報を出力する検出部と、
前記故障検出情報の出力を契機に、前記故障検出情報を故障が検出された前記電子機器の識別データとともに前記遠隔機器監視センターに送信する送信部と、
を備える機器診断装置。
【請求項4】
請求項３に記載の機器診断装置であって、
前記検出部はさらに、前記変化を検出したとき、
前記第１の時点の警報状態と前記第２の時点の警報状態をそれぞれデータベースに保存し、
前記メッセージを受信する毎に前記第１の時点の警報状態と前記第２の時点の警報状態を順次更新する、
機器診断装置。
前記検出部はさらに、前記変化を検出したとき、
前記第１の時点の警報状態と前記第２の時点の警報状態をそれぞれデータベースに保存し、
前記メッセージを受信する毎に前記第１の時点の警報状態と前記第２の時点の警報状態を順次更新する、
機器診断装置。
【請求項5】
請求項４に記載の機器診断装置であって、
検出部はさらに、前記警報状態の変化に対応するタイムスタンプをデータベースに記憶する、
機器診断装置。
検出部はさらに、前記警報状態の変化に対応するタイムスタンプをデータベースに記憶する、
機器診断装置。
【請求項6】
請求項１乃至請求項４のいずれかの請求項に記載の機器診断装置であって、
前記送信部はさらに、衛星通信リンクを使用して前記遠隔機器監視センターに前記故障検出情報を送信する、
機器診断装置。
前記送信部はさらに、衛星通信リンクを使用して前記遠隔機器監視センターに前記故障検出情報を送信する、
機器診断装置。
【請求項7】
請求項５に記載の機器診断装置であって、
前記送信部はさらに、
前記電子機器と前記受信部との接続を管理するデバイスマネジメントデータと、
前記送信部と前記衛星通信リンクとの接続を管理するコネクティビティデータと、
を含むＩｏＴポータルデータを前記遠隔機器監視センターに送信する、
機器診断装置。
前記送信部はさらに、
前記電子機器と前記受信部との接続を管理するデバイスマネジメントデータと、
前記送信部と前記衛星通信リンクとの接続を管理するコネクティビティデータと、
を含むＩｏＴポータルデータを前記遠隔機器監視センターに送信する、
機器診断装置。
【請求項8】
請求項６に記載の機器診断装置であって、
前記送信部は、
前記故障検出情報を第１の衛星通信リンクにより前記遠隔機器監視センターに送信し、
前記ＩｏＴポータルデータを前記第１の衛星通信リンクとは異なる第２の衛星通信リンクにより前記遠隔機器監視センターに送信する、
機器診断装置。
前記送信部は、
前記故障検出情報を第１の衛星通信リンクにより前記遠隔機器監視センターに送信し、
前記ＩｏＴポータルデータを前記第１の衛星通信リンクとは異なる第２の衛星通信リンクにより前記遠隔機器監視センターに送信する、
機器診断装置。
【請求項9】
請求項１乃至請求項７のいずれかの請求項に記載の機器診断装置であって、
前記移動体は水上を移動する船舶である、機器診断装置。
前記移動体は水上を移動する船舶である、機器診断装置。
【請求項10】
請求項１乃至請求項８のいずれかの請求項に記載の機器診断装置であって、
前記メッセージのメッセージタイプは、
前記電子機器から前記機器診断装置への１対１のデータ送信に関連付けられているＵＮＩＣＡＳＴメッセージタイプ、又は
データ送信が同時に前記複数の電子機器のグループにアドレス指定されるグループ通信に関連付けられるＭＵＬＴＩＣＡＳＴメッセージタイプ
のうち、少なくともいずれかを含む、
機器診断装置。
前記メッセージのメッセージタイプは、
前記電子機器から前記機器診断装置への１対１のデータ送信に関連付けられているＵＮＩＣＡＳＴメッセージタイプ、又は
データ送信が同時に前記複数の電子機器のグループにアドレス指定されるグループ通信に関連付けられるＭＵＬＴＩＣＡＳＴメッセージタイプ
のうち、少なくともいずれかを含む、
機器診断装置。
【請求項11】
請求項９に記載の機器診断装置であって、
前記検出部はさらに、
前記各メッセージのメッセージタイプをターゲットメッセージのタイプと比較し、
前記メッセージタイプがターゲットメッセージタイプと一致する場合、前記メッセージを解析し、
前記メッセージタイプがターゲットメッセージタイプと一致しない場合、前記メッセージを無視する、
機器診断装置。
前記検出部はさらに、
前記各メッセージのメッセージタイプをターゲットメッセージのタイプと比較し、
前記メッセージタイプがターゲットメッセージタイプと一致する場合、前記メッセージを解析し、
前記メッセージタイプがターゲットメッセージタイプと一致しない場合、前記メッセージを無視する、
機器診断装置。
【請求項12】
請求項９又は請求項１０に記載の機器診断装置であって、
前記メッセージは、ＮＡＴＩＯＮＡＬ ＭＡＲＩＮＥ ＥＬＥＣＴＲＯＮＩＣＳ ＡＳＳＯＣＩＡＴＩＯＮ（ＮＭＥＡ）０１８３メッセージに基づく、
機器診断装置。
前記メッセージは、ＮＡＴＩＯＮＡＬ ＭＡＲＩＮＥ ＥＬＥＣＴＲＯＮＩＣＳ ＡＳＳＯＣＩＡＴＩＯＮ（ＮＭＥＡ）０１８３メッセージに基づく、
機器診断装置。
【請求項13】
請求項１１に記載の機器診断装置であって、
前記検出部は、
前記解析に基づいて、前記メッセージの各メッセージにカプセル化されたＮＭＥＡ０１８３メッセージを識別して抽出し、
前記ＮＭＥＡ０１８３メッセージを事前定義された有効なＮＭＥＡ０１８３メッセージタイプと比較し、
前記ＮＭＥＡ０１８３メッセージが有効なＮＭＥＡ０１８３メッセージタイプの定義済みセットに属している場合は、ＮＭＥＡ０１８３メッセージの解析を続行し、
前記ＮＭＥＡ０１８３メッセージタイプが有効なＮＭＥＡ０１８３メッセージタイプの定義済みセットに属していない場合は、ＮＭＥＡ０１８３メッセージの解析を停止する、
機器診断装置。
前記検出部は、
前記解析に基づいて、前記メッセージの各メッセージにカプセル化されたＮＭＥＡ０１８３メッセージを識別して抽出し、
前記ＮＭＥＡ０１８３メッセージを事前定義された有効なＮＭＥＡ０１８３メッセージタイプと比較し、
前記ＮＭＥＡ０１８３メッセージが有効なＮＭＥＡ０１８３メッセージタイプの定義済みセットに属している場合は、ＮＭＥＡ０１８３メッセージの解析を続行し、
前記ＮＭＥＡ０１８３メッセージタイプが有効なＮＭＥＡ０１８３メッセージタイプの定義済みセットに属していない場合は、ＮＭＥＡ０１８３メッセージの解析を停止する、
機器診断装置。
【請求項14】
移動体に搭載された１又は複数の電子機器を遠隔から監視する遠隔機器監視システムであって、
請求項１乃至請求項１２のいずれかの請求項に記載の機器診断装置から送信される前記故障検出情報を受信する遠隔受信部と、
前記メッセージを分析して前記電子機器のトラブルシューティング情報を決定して該電子機器を遠隔監視する遠隔分析部と、
を備える遠隔機器監視システム。
請求項１乃至請求項１２のいずれかの請求項に記載の機器診断装置から送信される前記故障検出情報を受信する遠隔受信部と、
前記メッセージを分析して前記電子機器のトラブルシューティング情報を決定して該電子機器を遠隔監視する遠隔分析部と、
を備える遠隔機器監視システム。
【請求項15】
請求項１３に記載の遠隔機器監視システムであって、さらに、
前記電子機器のモデル及び該モデルに対応して故障を特定するアラームコードが保存された構成管理データベースを備え、
前記遠隔分析部は、前記メッセージが示す前記電子機器のモデル及びアラームコードに基づいて、前記構成管理データベースにあるトラブルシューティング指示を検索して前記電子機器のトラブルシューティング情報を決定する、
遠隔機器監視システム。
前記電子機器のモデル及び該モデルに対応して故障を特定するアラームコードが保存された構成管理データベースを備え、
前記遠隔分析部は、前記メッセージが示す前記電子機器のモデル及びアラームコードに基づいて、前記構成管理データベースにあるトラブルシューティング指示を検索して前記電子機器のトラブルシューティング情報を決定する、
遠隔機器監視システム。
【請求項16】
移動体に搭載された１又は複数の電子機器を遠隔から監視する遠隔機器監視方法であって、
前記電子機器を識別する識別データと、前記電子機器の警報状態を示す警報状態データを含む１又は複数のメッセージを電子機器からバックグラウンドプロセスで受信し、
前記警報状態データが示す第１の時点における警報状態と該第１の時点より以前の第２の時点における警報状態との比較に基づいて前記電子機器の故障を検出して故障検出情報を出力し、
前記故障検出情報の出力を契機に、前記故障検出情報を故障が検出された前記電子機器の識別データとともに前記遠隔機器監視センターに送信し、
前記移動体とは無線通信を介してデータが授受される遠隔機器監視センターにおいて、前記故障検出情報を受信し、
前記メッセージを分析して前記電子機器のトラブルシューティング情報を決定する、
遠隔機器監視方法。
前記電子機器を識別する識別データと、前記電子機器の警報状態を示す警報状態データを含む１又は複数のメッセージを電子機器からバックグラウンドプロセスで受信し、
前記警報状態データが示す第１の時点における警報状態と該第１の時点より以前の第２の時点における警報状態との比較に基づいて前記電子機器の故障を検出して故障検出情報を出力し、
前記故障検出情報の出力を契機に、前記故障検出情報を故障が検出された前記電子機器の識別データとともに前記遠隔機器監視センターに送信し、
前記移動体とは無線通信を介してデータが授受される遠隔機器監視センターにおいて、前記故障検出情報を受信し、
前記メッセージを分析して前記電子機器のトラブルシューティング情報を決定する、
遠隔機器監視方法。
【請求項17】
請求項１５に記載の遠隔機器監視方法であって、
構成管理データベースに保存された前記電子機器のモデル及び該モデルに対応して故障を特定するアラームコードと前記メッセージが示す前記電子機器のモデル及びアラームコードとを照合して前記構成管理データベースにあるトラブルシューティング指示を検索して前記電子機器のトラブルシューティング情報を決定する、
遠隔機器監視方法。
構成管理データベースに保存された前記電子機器のモデル及び該モデルに対応して故障を特定するアラームコードと前記メッセージが示す前記電子機器のモデル及びアラームコードとを照合して前記構成管理データベースにあるトラブルシューティング指示を検索して前記電子機器のトラブルシューティング情報を決定する、
遠隔機器監視方法。
【請求項18】
移動体に搭載された１又は複数の電子機器を診断する遠隔機器監視方法であって、
前記電子機器から前記電子機器を識別する識別データと、前記電子機器の警報状態を示す警報状態データを含む１又は複数のメッセージを予定された時間間隔で受信し、
前記時間間隔に基づいて定められた受信の時点を示すタイムスタンプのうち、第１のタイムスタンプと該第１のタイムスタンプが示す時点よりも以前の時点の第２のタイムスタンプとの間で前記警報状態データに変化があるかを前記メッセージに基づいて検知して故障検出情報を出力し、
前記故障検出情報の出力を契機に、前記故障検出情報を含むメッセージを前記遠隔機器監視センターに送信し、
前記移動体とは無線通信を介してデータが授受される遠隔機器監視センターにおいて、前記故障検出情報を受信し、
前記メッセージを分析して前記電子機器のトラブルシューティング情報を決定する、
遠隔機器監視方法。
前記電子機器から前記電子機器を識別する識別データと、前記電子機器の警報状態を示す警報状態データを含む１又は複数のメッセージを予定された時間間隔で受信し、
前記時間間隔に基づいて定められた受信の時点を示すタイムスタンプのうち、第１のタイムスタンプと該第１のタイムスタンプが示す時点よりも以前の時点の第２のタイムスタンプとの間で前記警報状態データに変化があるかを前記メッセージに基づいて検知して故障検出情報を出力し、
前記故障検出情報の出力を契機に、前記故障検出情報を含むメッセージを前記遠隔機器監視センターに送信し、
前記移動体とは無線通信を介してデータが授受される遠隔機器監視センターにおいて、前記故障検出情報を受信し、
前記メッセージを分析して前記電子機器のトラブルシューティング情報を決定する、
遠隔機器監視方法。
【請求項19】
請求項１６又は請求項１７に記載の遠隔機器監視方法であって、
前記変化を検出したとき、
前記第１の時点の警報状態と前記第２の時点の警報状態をそれぞれデータベースに保存し、
前記メッセージを受信する毎に前記第１の時点の警報状態と前記第２の時点の警報状態を順次更新する、
遠隔機器監視方法。
前記変化を検出したとき、
前記第１の時点の警報状態と前記第２の時点の警報状態をそれぞれデータベースに保存し、
前記メッセージを受信する毎に前記第１の時点の警報状態と前記第２の時点の警報状態を順次更新する、
遠隔機器監視方法。
【請求項20】
請求項１５乃至請求項１８のいずれかの請求項に記載の遠隔機器監視方法であって、
前記故障検出情報と前記識別データを、第１の衛星通信リンクを使用して前記遠隔機器監視センターに送信し、
さらに、
前記電子機器と前記受信部との接続を管理するデバイスマネジメントデータと、
前記送信部と前記衛星通信リンクとの接続を管理するコネクティビティデータと、
を含むＩｏＴポータルデータを、前記第１の衛星通信リンクとは異なる第２の衛星通信リンクにより前記遠隔機器監視センターに送信する、
遠隔機器監視方法。
前記故障検出情報と前記識別データを、第１の衛星通信リンクを使用して前記遠隔機器監視センターに送信し、
さらに、
前記電子機器と前記受信部との接続を管理するデバイスマネジメントデータと、
前記送信部と前記衛星通信リンクとの接続を管理するコネクティビティデータと、
を含むＩｏＴポータルデータを、前記第１の衛星通信リンクとは異なる第２の衛星通信リンクにより前記遠隔機器監視センターに送信する、
遠隔機器監視方法。
【請求項21】
請求項１５乃至請求項１９のいずれかの請求項に記載の機器診断装置であって、
前記移動体は水上を移動する船舶である、
遠隔機器監視方法。
前記移動体は水上を移動する船舶である、
遠隔機器監視方法。
【請求項22】
請求項２０に記載の遠隔機器監視方法であって、
前記メッセージのメッセージタイプは、
前記電子機器から前記機器診断装置への１対１のデータ送信に関連付けられているＵＮＩＣＡＳＴメッセージタイプ、又は
データ送信が同時に前記複数の電子機器のグループにアドレス指定されるグループ通信に関連付けられるＭＵＬＴＩＣＡＳＴメッセージタイプ
のうち、少なくともいずれかを含む、
遠隔機器監視方法。
前記メッセージのメッセージタイプは、
前記電子機器から前記機器診断装置への１対１のデータ送信に関連付けられているＵＮＩＣＡＳＴメッセージタイプ、又は
データ送信が同時に前記複数の電子機器のグループにアドレス指定されるグループ通信に関連付けられるＭＵＬＴＩＣＡＳＴメッセージタイプ
のうち、少なくともいずれかを含む、
遠隔機器監視方法。
【請求項23】
請求項２１に記載の遠隔機器監視方法であって、
前記各メッセージのメッセージタイプをターゲットメッセージのタイプと比較し、
前記メッセージタイプがターゲットメッセージタイプと一致する場合、前記メッセージを解析し、
前記メッセージタイプがターゲットメッセージタイプと一致しない場合、前記メッセージを無視する、
遠隔機器監視方法。
前記各メッセージのメッセージタイプをターゲットメッセージのタイプと比較し、
前記メッセージタイプがターゲットメッセージタイプと一致する場合、前記メッセージを解析し、
前記メッセージタイプがターゲットメッセージタイプと一致しない場合、前記メッセージを無視する、
遠隔機器監視方法。
【請求項24】
請求項２２に記載の遠隔機器監視方法であって、
前記メッセージは、ＮＡＴＩＯＮＡＬＭＡＲＩＮＥＥＬＥＣＴＲＯＮＩＣＳＡＳＳＯＣＩＡＴＩＯＮ（ＮＭＥＡ）０１８３メッセージに基づき、
前記解析に基づいて、前記メッセージの各メッセージにカプセル化されたＮＭＥＡ０１８３メッセージを識別して抽出し、
前記ＮＭＥＡ０１８３メッセージを事前定義された有効なＮＭＥＡ０１８３メッセージタイプと比較し、
前記ＮＭＥＡ０１８３メッセージが有効なＮＭＥＡ０１８３メッセージタイプの定義済みセットに属している場合は、ＮＭＥＡ０１８３メッセージの解析を続行し、
前記ＮＭＥＡ０１８３メッセージタイプが有効なＮＭＥＡ０１８３メッセージタイプの定義済みセットに属していない場合は、ＮＭＥＡ０１８３メッセージの解析を停止する、
遠隔機器監視方法。
前記メッセージは、ＮＡＴＩＯＮＡＬＭＡＲＩＮＥＥＬＥＣＴＲＯＮＩＣＳＡＳＳＯＣＩＡＴＩＯＮ（ＮＭＥＡ）０１８３メッセージに基づき、
前記解析に基づいて、前記メッセージの各メッセージにカプセル化されたＮＭＥＡ０１８３メッセージを識別して抽出し、
前記ＮＭＥＡ０１８３メッセージを事前定義された有効なＮＭＥＡ０１８３メッセージタイプと比較し、
前記ＮＭＥＡ０１８３メッセージが有効なＮＭＥＡ０１８３メッセージタイプの定義済みセットに属している場合は、ＮＭＥＡ０１８３メッセージの解析を続行し、
前記ＮＭＥＡ０１８３メッセージタイプが有効なＮＭＥＡ０１８３メッセージタイプの定義済みセットに属していない場合は、ＮＭＥＡ０１８３メッセージの解析を停止する、
遠隔機器監視方法。
【請求項25】
移動体に搭載された１又は複数の電子機器を診断するプログラムをコンピュータに実行させる機器診断プログラムであって、
前記電子機器を識別する識別データと、前記電子機器の警報状態を示す警報状態データを含む１又は複数のメッセージを電子機器からバックグラウンドプロセスにより受信させ、
前記警報状態データが示す第１の時点における警報状態と該第１の時点より以前の第２の時点における警報状態との比較に基づいて前記電子機器の故障を検出し故障検出情報を出力させ、
前記故障検出情報の出力を契機に、前記故障検出情報を故障が検出された前記電子機器の識別データとともに前記遠隔機器監視センターに送信させる、
機器診断プログラム。
前記電子機器を識別する識別データと、前記電子機器の警報状態を示す警報状態データを含む１又は複数のメッセージを電子機器からバックグラウンドプロセスにより受信させ、
前記警報状態データが示す第１の時点における警報状態と該第１の時点より以前の第２の時点における警報状態との比較に基づいて前記電子機器の故障を検出し故障検出情報を出力させ、
前記故障検出情報の出力を契機に、前記故障検出情報を故障が検出された前記電子機器の識別データとともに前記遠隔機器監視センターに送信させる、
機器診断プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電子機器の診断装置、遠隔機器監視方法、遠隔機器監視システム及び機器診断プログラムに関するものであり、より具体的には、水上を移動する船舶などの移動体等における機器の故障を判定し、陸上又は左記船舶以外の移動体設置される機器監視センターからトラブルシューティング指示を提供する装置及び方法に関する。
【背景技術】
【0002】
海運会社の乗組員は、船舶の完全性、安全性、及び可用性を確保するために専門化されているが、船舶には、船舶の安全性と効率的な作業を確保する多くの電子機器、すなわち舶用電子機器が搭載、設置されている。船舶に搭載されている舶用電子機器は、一般にその性能と機能の維持状況に応じて必要な部品を交換して使用される。
【0003】
乗組員は、舶用電子機器に異常が発生した場合、その状況を船舶管理会社に連絡する。その後、海運会社は、装置の故障をトラブルシューティングするための指示を得るために、取得した情報を機器監視センターに提供する。次いで、機器監視センターから船舶に対してトラブルシューティングに関する適切な指示がなされる。
【0004】
しかし、船舶会社と船舶との間のコミュニケーションは状況によって異なり、しばしば複雑で困難な状況に陥る。多くの場合、船舶の乗組員の作業負荷が高いために、装置の故障が報告されずに残ったり、時には誤報が機器監視センターに送られたりすることがあり、多くの場合、船舶が突然故障する結果を生じさせかねない。
【0005】
また、船舶の装置に問題があって装置を破損したことについて乗組員が非難されたくない場合、乗組員は装置が故障したことを入港時まで知らせることを躊躇するということも全くないわけではない。
【0006】
従って、船舶から得られる情報は、装置の故障に関連する詳細を欠いている可能性がある。舶用電子機器の障害に関連する完全な情報が不足しているため、舶用電子機器の障害の正確な原因を診断し、障害のトラブルシューティングに対応するガイダンスや指示を提供することが困難になりかねない。
【0007】
ところで、現在、衛星通信リンクは機器の遠隔機器監視のために船舶上の舶用電子機器に関連するリアルタイム情報を遠隔機器監視センターに提供するために使用されている。しかし、一般に、遠隔地の機器監視センターが受け取ったデータには大量の情報が含まれている可能性がある半面、それらのデータすべてが故障や診断に関連するとは限らない。
【0008】
そのような大容量のデータを処理するためには、高価なインフラストラクチャと、すべてのデータをふるいにかけて装置のデータ関連の故障を識別しトラブルシューティングの指示を提供する高度な処理能力を必要とする。また、一般的に、衛星通信を経由した通信は通信費用が高く、大量のデータ伝送には必ずしも適していない。従って、装置の故障を効果的かつ時間内にトラブルシューティングするために、船舶と機器監視センターとの間の直接的な双方向通信を提供する費用対効果の高いシステムとアーキテクチャが必要である。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特公表２０１４―２０３９９０号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
遠隔から船舶等の移動体に搭載される電子機器の障害の有無とその正確な原因を適宜に診断し、監視する機器診断装置、遠隔機器監視方法、遠隔機器監視システム及び機器診断プログラムを提供する。
【課題を解決するための手段】
【0011】
上記の問題を解決するために、本発明は、対象となる船舶等から衛星通信等の無線通信で繋げられた遠隔機器監視センターにより船舶上に搭載される１又は複数の舶用電子機器を監視する機器診断装置、及び遠隔機器監視方法、遠隔機器監視システム及び機器診断プログラムを提供する。
【0012】
本発明の機器診断装置は、１又は複数の電子機器から１又はそれ以上のメッセージを受信するように構成された受信部を含む。メッセージは識別データと呼ばれる、メッセージに関する情報、すなわちメッセージの送信方法、電子機器を識別するための識別番号若しくは機器名等を含む情報と、警報状態データである、機器の誤動作もしくは故障（アラーム）に関する或いは電子機器の測定値もしくは読み取り値（プロパティ）により警報状態を示す、電子機器自体の状態に関する情報から構成される。
【0013】
機器診断装置はさらに、識別データと警報状態データに基づいて１又は複数の舶用電子機器の故障を検出する検出部を含む。そして、故障が検出されたことを契機に、故障に関連する情報を遠隔機器監視センターに送信するように構成された送信部を備える。
【0014】
本発明の遠隔通信装置において、識別データと警報状態データは、米国海洋電子機器協会（ＮａｔＩｏｎａｌ Ｍａｒｉｎｅ Ｅｌｅｃｔｒｏｎｉｃｓ ＡｓｓｏｃｉａｔＩｏｎ：ＮＭＥＡ）により規定され管理される、０１８３メッセージに基づいてもよい。これは、音波探査機、ソナー、風速計、ジャイロコンパス、自動操舵装置、ＧＰＳ受信機その他海洋に関連する電子機器における、データに関する仕様である。
【0015】
本発明の機器診断装置において、検出部は、各メッセージのメッセージタイプをターゲットメッセージタイプと比較し、ここで、メッセージタイプがターゲットメッセージタイプと一致する場合、検出部はメッセージを解析し、メッセージタイプがターゲットメッセージタイプと一致しない場合、検出部はメッセージを無視するようにしてもよい。
【0016】
本発明の遠隔通信装置によれば、メッセージタイプは、ＵＮＩＣＡＳＴメッセージタイプか、ＭＵＬＴＩＣＡＳＴメッセージタイプのうち、少なくとも１つを含むことができる。ここで、ＵＮＩＣＡＳＴメッセージタイプは、舶用電子機器から機器診断装置への１対１の送信に関連している。また、ＭＵＬＴＩＣＡＳＴメッセージタイプは、データ送信が電子機器に対して同時に送信されるグループ通信に関連している。
【0017】
本発明の遠隔通信装置において、検出部は構文解析に基づいて、１又はそれ以上のメッセージの各メッセージ内に（オブジェクト指向プログラミングにより）カプセル化されたＮＭＥＡ０１８３メッセージを識別するようにしてもよい。すなわち、オブジェクト指向プログラミングにおいて、互いに関連するデータの集合とそれらに対する操作をオブジェクトとして一つのメッセージ単位にまとめ、外部に対して必要な情報や手続きのみを提供することでＮＭＥＡ０１８３メッセージを識別するのである。
【0018】
さらに、検出部は、ＮＭＥＡ０１８３メッセージを、有効なＮＭＥＡ０１８３メッセージタイプの予め定められたセットと比較することができる。ＮＭＥＡ０１８３メッセージが有効なＮＭＥＡ０１８３メッセージタイプの所定のセットに属している場合、検出部はＮＭＥＡ０１８３メッセージの解析を続行する。ＮＭＥＡ０１８３メッセージが有効なＮＭＥＡ０１８３メッセージタイプの所定のセットに属していない場合、検出部はＮＭＥＡ０１８３メッセージを無視する。
【0019】
本発明の機器診断装置において、検出部は第１のトリガー及び第２のトリガーを含むことができる。第１のトリガーは、バックグラウンドプロセスとして常に動作して、１又は複数の電子機器から、警報状態データを含む１又はそれ以上のメッセージを受信する。第１のトリガーは、警報状態データを用いて現在の警報状態（第１の時点における警報状態）と以前の警報状態（第１の時点より以前の第２の時点における警報状態）との比較に基づいてメッセージを処理することができる。
【0020】
第２のトリガーは、予定された間隔で実行されてもよく、これらの間隔はユーザによって事前定義されていてもよい。第２のトリガーは、メッセージを処理して最後に予定されたタイムスタンプと現在の予定されたタイムスタンプとの間で警報状態データに変化があるかどうかをチェックする。
【0021】
検出部は、第１のトリガー及び第２のトリガーによるメッセージの処理に基づいて、１又は複数の電子機器の故障に関連する情報を含むメッセージを、当該故障の診断をされた電子機器を識別するデータとともに遠隔機器監視センターに送信する。
【0022】
本発明の機器診断装置によれば、検出部は、１又は複数のメッセージに対する現在の警報状態及び以前の警報状態をデータベースに格納するようにしてもよい。そして、１又はそれ以上のメッセージを受信するたびに現在の警報状態を更新する。
【0023】
本発明の機器診断装置によれば、検出部は警報状態の変化をタイムスタンプで記憶させるようにしてもよい。最後の警報状態のタイムスタンプはデータベースにおいて書き換えられる。本発明の機器診断装置は、送信部は衛星通信リンクを使用して遠隔機器監視センターに情報を送信する。
【0024】
本発明の遠隔機器監視方法は、遠隔機器監視センターから船舶等の移動体にある１又は複数の電子機器から１又は複数のメッセージを受信する。ここで、各メッセージは、メッセージの送信方法、各電子機器を識別するための識別番号若しくは機器名等を含む情報から構成される電子機器との間の通信のための識別データと、機器の誤動作もしくは故障（アラーム）に関する、或いは電子機器の測定値もしくは読み取り値（プロパティ）に関する、電子機器の状態に関する情報から構成される警報状態データとがカプセル化されている。識別データと警報状態データとの組み合わせに基づいて、電子機器の故障を検出し、障害に関連する情報を遠隔機器監視センターに送信する。
【0025】
本発明の別の実施形態によれば、１又は複数の電子機器の障害を検出する際に、各メッセージのタイプをターゲットメッセージのタイプと比較するステップと、メッセージタイプがターゲットメッセージタイプに一致する場合にメッセージを解析し、一致しない場合はメッセージを無視する。
【0026】
本発明の別の実施形態によれば、１つ以上の電子機器を監視するための遠隔機器監視センターは陸上、又は対象となる船舶等以外の船舶にあり、対象となる船舶等にある１又は複数の電子機器を監視する。遠隔機器監視センターは、遠隔受信部によって１又はそれ以上のメッセージを受信する。上記メッセージは電子機器の故障に関連する情報を含んでおり、遠隔機器監視センターはさらに、受信されたメッセージを分析する遠隔分析部を含む。
【0027】
さらに、遠隔機器監視センターは解析された１つ以上のメッセージを解析し、解析に基づいて電子機器の故障を判定するように構成された遠隔アプリケーション部を含むことができる。ここで、１つ以上の船舶装置の故障の判定は、陸上又は対象となる船舶以外の船舶上にある遠隔機器監視センターから対象とする船舶等にある電子機器を監視する。
【0028】
本発明の遠隔機器監視方法によれば、遠隔機器監視センターから船舶等に搭載される１又は複数の電子機器を遠隔機器監視する方法であって、電子機器から１又はそれ以上のメッセージを受信する。１又はそれ以上のメッセージの各メッセージは船舶にある電子機器の故障に関連する情報を含んでおり、これらのメッセージを分析しその分析結果に基づいて電子機器を遠隔機器監視するためのトラブルシューティング情報を決定する。
【0029】
本発明の遠隔機器監視方法によれば、機器診断装置を使用して、機器診断装置と通信する電子機器を監視するハイブリッドアーキテクチャを構成する。機器診断装置は、１又は複数の電子機器から受信した１又はそれ以上のメッセージの解析に基づいて電子機器の故障を判定する。
【0030】
電子機器の故障が判定されると、機器診断装置は、第１の衛星通信リンクを使用して対応する電子装置の故障に関する情報を遠隔機器監視センターに直接提供する。この方法では、電子機器の障害に関連する関連情報のみが遠隔機器監視センターに提供され、遠隔機器監視センターが問題を診断してトラブルシューティング手順を短時間で提供できるようになる。
【0031】
さらに、デバイスＷＩＳＥ（ＤＷ）ゲートウェイに対するデバイスマネジメント（ＤＭ）サービスとコネクティビティマネジメント（ＣＭ）サービスは、第２の衛星通信リンクによって提供される。このように、第１の衛星通信リンクは、機器診断装置を用いて提供される電子機器の障害の遠隔機器監視及びトラブルシューティングに専用に使用されるので、ＤＭ／ＣＭサービスに依存することなく、デバイスの障害の迅速な監視及びトラブルシューティングを可能にする。
【0032】
異常が本発明による課題の解決手段であるが、あくまでも上記の要約は例示のみであり、いかなる点においても限定することを意図していない。上述の例示的な態様、実施形態、及び特徴に加えて、さらなる態様、実施形態、及び特徴は、図面及び以下の詳細な説明を参照することによって明らかになるであろう。
【0033】
本発明の機器診断装置、遠隔機器監視方法及び遠隔機器監視プログラムによれば、電子機器の遠隔機器監視及び診断のための装置及び方法を提供することができる。この装置は、主として船舶などの海上移動体に設置される電子機器を遠隔機器監視するために使用される。本発明の機器診断装置等は、電子機器の故障に関する情報を提供し、故障した電子機器を動作させるためのトラブルシューティング指示を得るために、遠隔機器監視センターと直接通信し、故障した電子機器の効率的かつ効果的なトラブルシューティングを可能にする。
【図面の簡単な説明】
【0034】
本実施形態の開示は一例として図示するものであり、添付図面の図面に限定されるものではない。
【図1】本発明の一実施形態による船舶の遠隔機器監視のための機器監視装置と遠隔機器監視センターとの関係を示す概略図である。
【図2】本発明の一実施形態による船舶の遠隔機器監視のために実装されたハイブリッドアーキテクチャを示す概略図である。
【図3】本発明の一実施形態による機器診断装置のブロック図を示す概略図である。
【図4】本発明の一実施形態によるＤＷコアの構成要素を示す図である。
【図5】本発明の一実施形態による遠隔機器監視センターからなる異なる構成要素を示す。
【図6】本発明の一実施形態によるトラブルシューティング命令を提供するために遠隔機器監視センターによって実行される方法のステップを示す。
【図7】本発明の一実施形態による船舶加入者に通知を提供するために遠隔機器監視センターによって実行される方法のステップを示す。
【図8】本発明の一実施形態による船舶の遠隔機器監視のためのＩｏＴポータルのブロック図を示す概略図である。
【図9】本発明の一実施形態による一以上の舶用電子機器と通信する機器診断装置を例示的に示す概略図である。
【図10】本発明の一実施形態による機器診断装置の初期化手順を例示的に示す概略図である。
【図11】本発明の一実施形態による船舶内の装置から機器診断装置によって受信される例示的なメッセージを示す。
【図12】本発明の一実施形態による第１のトリガーによって実行される方法のステップを示すフローチャートである。
【図13】本発明の一実施形態による第１のトリガーによって実行される機器故障診断と故障検出情報の送信を示す図である。
【図14】本発明の一実施形態による第２のトリガーによって実行される方法のステップを示すフローチャートである。
【図15】本発明の一実施形態による第２のトリガーによって実行される機器故障診断と故障検出情報の送信を示す図である。
【図16】本発明の一実施形態による警報状態を決定するために第２のトリガーによって使用される例示的な装置警報状態を示す。
【図17】本発明の一実施形態による２０分間の警報状態変化のための第２のトリガーの動作を示す例示的なテーブルを示す。
【図18】本発明の一実施形態による、トリガーによって処理され、ローカルデータベースに記録されるデータを含む例示的なテーブルを示す。
【図19】本発明の一実施形態による舶用電子機器からのデータが機器診断装置によって受信されるときの例示的な捕捉タイムチャートを示す。
【図20】本発明の一実施形態による初期化プロシージャの例示的なコールフローを示す。
【図21】本発明の一実施形態によるステータス取得コマンドの実行ステップを示す。
【図22】本発明の一実施形態によるログリストコマンドの実行ステップを示す。
【図23】本発明の一実施形態によるデータダウンロードコマンドの実行ステップを示す。
【図24】本発明の一実施形態によるエクスポート設定コマンドの実行ステップを示す。
【図25】本発明の一実施形態による船舶の遠隔機器監視のための方法ステップを示す概略図である。
【発明を実施するための形態】
【0035】
以下の説明は、本発明の完全な理解を促すために多数の具体的な例が詳細に記載される。本発明のシステム及び方法は、実施形態の開示が不明瞭になることを回避するためにのみブロック図形式で示される。
【0036】
本明細書の様々な箇所における「一実施形態において」という語句の出現は、必ずしもすべてが同じ実施形態を参照しているわけではなく、別個の実施形態又は代替の実施形態が他の実施形態と相互に排他的であるわけでもない。いくつかの実施形態の要件であってもよいが、すべての要件ではない様々な要件が記載されている。
【0037】
以下、本発明のいくつかの実施形態について図面を参照してより詳細に説明する。添付図面には、本開示のいくつかの実施形態が示されているが、すべてではない。実際、本開示の様々な実施形態は、多くの異なる形態で実施することができ、本明細書に記載される実施形態に限定されるものと解釈されるべきではない。むしろ、これらの実施形態は、本開示が適用可能な法的要件を満たすように提供される。同じ参照番号は、全体を通して同じ要素を参照する。
【0038】
本明細書で使用される場合、用語「データ」、「コンテンツ」、「情報」及び同様の用語は、本発明の実施形態に従って送信、受信及び／又は記憶することができるデータを指すために互換的に使用することができる。さらに、「プロセッサ」、「コントローラ」及び「処理回路」という用語及び同様の用語は、本発明の実施形態に従って情報を処理することができるプロセッサを指すために互換的に使用され得る。さらに、用語「電子機器」、「電子デバイス」及び「デバイス」は、本発明の実施形態によるシステムによって監視される電子機器を指すために互換的に使用される。
【0039】
以下の本発明の実施形態の説明では、遠隔機器監視の対象は船舶等に装備される舶用電子機器であるが、船舶に限らず、海洋、湖水、河川を含む広く水上を移動する移動体に適用され得るし、さらにオフショアなどの固定物にも適用され得る。
【0040】
電子機器も通信可能であればエンジンやポンプなどに備わる計器類であってもよいし、０１８３メッセージが想定する、音波探査機、ソナー、風速計、ジャイロコンパス、自動操舵装置、ＧＰＳ受信機その他海洋に関連する電子機器を含むが、ここでは舶用電子機器と記す。
【0041】
図１は、本発明の一実施形態による船舶の遠隔機器監視のための機器監視装置と遠隔機器監視センターとの関係を示す概略図である。
【0042】
船舶１０１上には１又は複数の舶用電子機器ａ―ｎが搭載されており、これらの機器は遠隔機器監視センターと衛星通信リンクを介して通信が可能である。舶用電子機器１０７ａ―ｎは、一つの船舶にあるとは限らず、他の船舶１０２等複数の船舶にそれぞれ搭載されていることも想定される。
【0043】
衛星による通信は、複数の通信衛星３０１ａ―ｎから経由する衛星通信を適宜選定可能であり、例えば、イリジウム衛星通信システムやインマルサットを用いることにより、一つの通信経路に限らず複数の経路から選定することが可能である。そして、機器診断装置１０３と遠隔機器監視センター１１３との通信は、その経路の全てが衛星通信リンクであってもよいし、一部に衛星通信リンクを含むものであってよい。
【0044】
本発明の遠隔機器監視システムのためのハイブリッドアーキテクチャは、１つ以上の舶用電子機器の遠隔機器監視及び診断のための遠隔機器監視センターへの直接的に衛星通信リンク（経路）を使用して、船舶内の１つ以上の舶用電子機器の故障に関連する情報を提供する機器診断装置を使用する。
【0045】
監視の対象となる舶用電子機器は、一つであってもよいし複数であってもよいが、複数であるのが一般的であるし、本発明の遠隔機器監視機器もより効果を発揮することになる。以下の本発明の各実施形態の説明では、舶用電子機器は１つであっても複数であってもよいことを前提とする。
【0046】
機器診断装置は船舶側に設置されており、船舶に搭載される１又は複数の各舶用電子機器と通信し機能における異常を判定する。さらに、舶用電子機器に関連する異常に関連する情報を、衛星通信リンクを介して遠隔機器監視センターに直接送信する。
【0047】
遠隔機器監視システムは、上記船舶とは離れた陸上、又は水上の別の移動体、例えば遠隔監視を行う専用船に設置されており、機器診断装置とは衛星通信リンクなどの無線通信を介してデータ授受を可能とする。
【0048】
次いで、データベースに接続する機器診断装置は、衛星通信リンクを介して、舶用電子機器に関連する異常に関連するトラブルシューティング指示を取得する。
【0049】
機器診断装置と遠隔機器監視システムとの間の直接的な通信を提供するハイブリッドアーキテクチャは、直接的な通信リンクのために、舶用電子機器の異常の原因を診断する効率を高める。直接通信をすることにより、デバイスの障害に関連する情報をリアルタイムで提供できトラブルシューティング時間を短縮することができる。すなわち、機器診断装置と遠隔機器監視センター間の直接通信リンクによる効果的な診断により、船舶が寄港する港湾でデバイスの問題を修正するために物理的な支援が必要な場合のトラブルシューティングの時間を短縮することができる。
【0050】
舶用電子機器が故障した場合は、トラブルシューティングのアドバイスとともに乗務員に警告が出され、最後に搭乗が必要な場合は、搭乗前に故障の正確な症状が特定され、エンジニアが正しいスペアパーツを準備し提供することができるようになる。
【0051】
図２を参照して、船舶の遠隔機器監視のためのハイブリッドアーキテクチャの詳細な構成と動作を以下に示す。
【0052】
図２は、本発明の一実施形態による、船舶の遠隔機器監視のために実装されたハイブリッドアーキテクチャ１００を示す概略図である。
【0053】
ハイブリッドアーキテクチャ１００は、船舶１０１と、遠隔機器監視センター１１３と、いわゆるＩｏＴ（モノのインターネット）ポータル１１５との間の通信リンクを含んでいる。遠隔機器監視センター１１３は、ここでは陸上に遠隔配置されており、海上の船舶１０１内の１又は複数の舶用電子機器１０７を監視する。船舶１０１は、ゲートウェイ装置１１１を含み、このゲートウェイ装置１１１は舶用電子機器１０７からデータを収集するハードウェア（スマートデバイス）である。
【0054】
ゲートウェイ装置１１１はＤＷゲートウェイ１２１を含んでおり、このＤＷゲートウェイ１２１はゲートウェイ装置１１１として機能しこれらの装置にアクセスする。そして、ユーザと１又は複数の舶用電子機器１０７との中間プロトコルにあるものとして機能し、ユーザは１又は複数の舶用電子機器１０７の故障について通知される。
【0055】
ＤＷゲートウェイ１２１は、舶用電子機器を監視するためにユーザをＤＷゲートウェイ１２１に接続するのに用いられる任意のアプリケーション間の中間プロトコル的位置づけとして動作する、ＤＷゲートウェイ１２１のサブ部であるＤＷコア１１９を含んでいる。このことは、ビジネスアプリケーションの選択からもたらされるデータを意味する。
【0056】
ＤＷゲートウェイ１２１はさらに、ＤＷコア１１９との直接的な通信を行うデータベース１０９を含んでいる。ＤＷコア１１９は、機器診断装置１０３における診断機能及びプラグイン１０５を含む。なお、機器診断装置１０３は舶用電子機器１０７の診断を行って外部にその情報を送信する最小限の機能を備えたイベントトリガーモジュールとして機能する。
【0057】
ハイブリッド・アーキテクチャ１００は、機器診断装置１０３が、舶用電子機器１０７の故障に関する情報を遠隔機器監視センター１１３に直接的に送信することを可能にする。機器診断装置１０３と遠隔機器監視センター１１３との間の直接的リンクは、システムの可搬性を高め、全体的なアーキテクチャを単純化する。これは、ハイブリッドアーキテクチャ１００が、トラブルシューティング命令を提供する際にリスクを引き起こす可能性のある障害の中間プロトコル点を排除するためである。
【0058】
さらに、ハイブリッド・アーキテクチャ１００は、例えば、舶用電子機器１０７に関連する情報にアクセスしながら、データ保護及びパスワード・ポリシーを利用することによって、遠隔機器監視システム全体のセキュリティを強化する。そして、第１の衛星通信リンクを介して遠隔機器監視センター１１３にルーティングされたトラフィックデータと、第２の衛星通信リンクを介してＩｏＴポータル１１５にルーティングされたトラフィックデータとの間のトラフィックの適切な分離を確実ならしめる。ここで、各ゲートウェイ装置１１１は、各衛星通信リンクに登録された固有のトークン（Ｔｈｉｎｋ Ｋｅｙ）を有しており、通常は認証と管理目的で同じトークンが使用される。
【0059】
２つの異なる衛星通信リンクを使用して、トラフィックを遠隔機器監視センター１１３に送信されるデータとＩｏＴポータル１１５に送信されるデータとを分離する利点は、ハイブリッドアーキテクチャがプラットフォーム（１１３及び１１５）のそれぞれの長所を利用することである。すなわち、ここでは２つのポータルを使用し独自のプラットフォーム、Ａｚｕｒｅユーザインターフェースとデータアナリティクスそれぞれを構成し、機器管理と接続管理を実現している。ＩｏＴポータル１１５からゲートウェイ装置１１１を介して舶用電子機器１０７に直接リモートアクセスサービスを開始する。これがこの２つの互いに異なる通信衛星リンクを利用する理由である。一つは遠隔機器監視センター１１３へのデータ送信（アウトゴーイングトラフィック）用であり、いま一つはＴＲ―５０による遠隔アクセスサービス（インバウンドトラフィック）とＩｏＴポータル１１５によるＶＰＮトンネリングである。ここで、ＤＭコア１１９を介して送信されるデータのルートが制御される。
【0060】
衛星通信リンクは、インマルサットＦＢＢからＶＳＡＴまで、あらゆる衛星通信事業者のネットワークが利用可能であり、イリジウム（Ｉｒｉｄｉｕｍ Ｃｅｒｔｕｓ）衛星を利用してもよい。
【0061】
遠隔機器監視センター１１３は、ユーザインターフェース、データアナリティクス、トラブルシューティングを提供する。ＩｏＴポータル１１５はデバイスマネジメント（デバイスマネジメントデータ）とコネクティビティマネジメント（コネクティビティデータ）を含むＩｏＴポータルデータ提供するものであり、遠隔機器監視センター１１３はこのＩｏＴポータル１１５を含んでいる。
【0062】
ＤＷコア１１９は、船舶１０１に設置されたコンピュータ操作可能なユニットにインストールされたソフトウェアであってもよい。機器診断装置１０３は、舶用電子機器１０７から１又はそれ以上のメッセージを受信するが、これらのメッセージには船舶１０１にある舶用電子機器１０７との通信のための識別データと、機器の誤動作もしくは故障（アラーム）に関する、或いはデバイスの測定値もしくは読み取り値（プロパティ）に関する、デバイスの状態に関する情報から構成される警報状態データとが結合されたデータを含んでおり、識別データと警報状態データの組み合わせはＮＭＥＡ０１８３メッセージに基づいている。
【0063】
より具体的には、各メッセージは２つの異なるカテゴリのデータの組合せを含んでいる。一つは、第１の識別データと呼ばれ、メッセージに関する情報、すなわちメッセージの送信方法、機器名等を含む情報から構成される。
【0064】
一つは、警報状態データと呼ばれ、機器の誤動作もしくは故障（アラーム）に関する、或いはデバイスの測定値もしくは読み取り値（プロパティ）に関する、デバイスの状態に関する情報から構成される。これは、デバイスの誤動作や障害（アラーム）、又はデバイスの測定値や読み取り値（プロパティ）などデバイスの状態に関する情報で構成されている。
【0065】
機器診断装置１０３は、識別データと警報状態データに基づいて、舶用電子機器１０７の故障を検出し、次いで、舶用電子機器１０７の故障に関連する情報を遠隔機器監視センター１１３に送信する。この際、舶用電子機器１０７の故障に関連する情報は第１の衛星通信リンクを用いて送信される。
【0066】
さらに、機器診断装置１０３は、舶用電子機器１０７から１又はそれ以上のメッセージを受信すると、解析されるメッセージのタイプを決定し、それに応じてメッセージを解析する。メッセージのタイプは、ユニキャストメッセージタイプとマルチキャストメッセージタイプの少なくとも１つが含まれている。
【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】
第２のトリガーは予定された時間間隔で動作し、１又は複数の舶用電子機器１０７（１又は複数の舶用電子機器１０７は互換的で相互に参照される）から１又はそれ以上のメッセージを受信する。第２のトリガーはメッセージを処理し、最後に（直近に）予定されたタイムスタンプと現在の予定されたタイムスタンプの間で警報状態データに変更があるかどうかをチェックする。
【0094】
さらに、検出部１２５は第１のトリガー及び第２のトリガーによるメッセージの処理に基づいて、舶用電子機器１０７の故障に関連する情報を含むメッセージを出力する。
【0095】
機器診断装置１０３は、送信部１２７を用いて舶用電子機器１０７の故障に関連する情報を遠隔機器監視センター１１３に送信する。送信部１２７は、故障に関する情報の出力を契機に、第１の衛星通信リンクを使用して舶用電子機器１０７の故障に関連する情報を遠隔機器監視センター１１３に送信する。
【0096】
機器診断装置１０３は、第１のトリガー及び第２のトリガーを使用して、障害に関連する関連情報を決定する。次いで、機器診断装置１０３は装置の故障に関連する関連情報のみを遠隔機器監視センター１１３に送信する。これらのトリガーは、１又は複数の警報タイプメッセージの受信時に実行される１又は複数のソフトウェアプロセス、サブルーチン、ファンクション、サービス、及びアルゴリズムのいずれであってもよい。トリガーは、ＤＷコア１０５の一部をなすプラグイン１０５を使用して定義することができる。
【0097】
ＤＷコア１１９の詳細な機能について、図４を参照して以下に説明する。
【0098】
図４は、本発明の機器診断装置の一実施形態による、ＤＷコア１１９の構成要素を示す。図から分かるように、ＤＷコア１１９は、プラグイン１０５及び機器診断装置１０３の二つのコンポーネントを含んでいる。
【0099】
本発明の一実施形態では、プラグイン１０５は舶用電子機器と通信するために１又は複数のプラグインを使用する。プラグイン１０５は、４つのプラグインを使用して船舶１０１における舶用電子機器１０７と通信する。４つのプラグインは、４つの個別のコマンドを実装する。プラグイン１０５は、プラグインを使用してＤＷコア１１９を介して、対応するコマンドを舶用電子機器１０７に送信する。
【0100】
さらに、舶用電子機器１０７は、対応するデータをプラグイン１０５に返信する。プラグイン１０５は舶用電子機器１０７との間の通信のためだけでなく、舶用電子機器１０７によって返信されたデータを処理するための機能も果たす。プラグイン１０５と舶用電子機器１０７との間のすべての通信はネットワークを介して行われるので、プラグイン１０５と舶用電子機器１０７との間には安全な接続を確立する必要がある。
【0101】
図５は、本発明の一実施形態による、遠隔機器監視センター１１３からなる異なる構成を示す。遠隔機器監視センター１１３は、いわゆるモノのインターネット（ＩｏＴ）ハブ１２９、イベントハブ１３１、ファンクション部１３３、コスモスデータベース１３５、構成管理データベース（ＣＭＤＢ）１３７、ウェブアプリケーション１３９、アプリケーションゲートウェイ１４１、及びＡｚｕｒｅ（登録商標）データレイクストレージ（ＡＤＬＳ）１４３を含んでいる。なお、ＡｚｕｒｅはＭｉｃｒｏｓｏｆｔ（登録商標）社が提供するクラウドサービスである。同様の機能を有するものであれば、Ａｚｕｒｅに限らず本発明の機器診断装置に適用することができる。
【0102】
ＩｏＴハブ１２９は、舶用電子機器１０７の故障に関する情報を船舶１０１から取得する。この情報は装置故障の原因を決定し、さらに装置故障のトラブルシューティングのための指示を与えるために遠隔機器監視センター１１３において用いられる。ＩｏＴハブ１２９は、船舶１０１内にある１又は複数の舶用電子機器１０７に対して中央管理するように配置されている。
【0103】
ＩｏＴハブ１２９は、デバイス認証又は承認、デバイスプロビジョニング、ＤＷコア１１９との双方向通信、モジュール（部）レジストリ、デバイス結合等のいくつかの機能を有する。ＩｏＴハブ１２９は、イベントハブ１３１にデータをルーティングする。ＩｏＴハブ１２９は、船舶１０１から１又はそれ以上のメッセージを受信する遠隔受信部として構成されている。メッセージには舶用電子機器１０７の故障に関する情報を含んでいる。
【0104】
イベントハブ１３１は、メッセージなどの形でＩｏＴハブ１２９から来るデータを分配するように構成してもよい。ＩｏＴハブ１２９は、ファンクション部１３３に接続されたシングルイベントハブ１３１のエンドポイントのみを有する。イベントハブ１３１は、舶用電子機器１０７の故障に関連する情報をＡｚｕｒｅデータレイクストレージ（ＡＤＬＳ）１４３及びＡｚｕｒｅコスモスデータベース１３５に格納する。
【0105】
ファンクション部１３３は、イベントハブ１３１からのデータポイントを処理し、コスモスデータベース（グローバルな分散型マルチモデルデータベース）１３５に転送する。ファンクション部１３３は、遠隔解析部として機能しＩｏＴハブから順番にやって来てイベントハブ１３１から受信される１又はそれ以上のメッセージを解析する。ファンクション部１３３はＭｉｃｒｏｓｏｆｔＡｚｕｒｅポータル上にＮＥＴＣＯＲＥを実装され、サーバレス演算オプションとして使用される。なお、コスモスデータベース１３５は、Ａｚｕｒｅプラットフォームに基づくデータベースであり、これはグローバルに分散されたマルチモデルのデータベースサービスである。
【0106】
ファンクション部１３３は、イベントハブ１３１から受信したデータを処理し、ＩｏＴ運用のための異なるシステムと連携し様々なプロセスやシステムを統合する。ファンクション部１３３は、さらに、単純なアプリケーションインターフェース及びマイクロサービスの構築を可能にする。ファンクション部１３３は、遠隔機器監視センター１１３においてより多くの機能を実装することを可能にし、より多くのオプションと形態を提供するストリーム分析に使用することができる。
【0107】
ファンクション部１３３はさらに、イベント駆動型プログラミングで使用され、ｈｔｔｐリクエスト、タイマ、イベントハブ入力（ファンクション部１３３内に実装された関数のトリガー）などによってトリガーされる。ファンクション部１３３はさらに、入力処理を可能にし、それをユーザが選択する記憶装置に保存することができる。
【0108】
ファンクション部１３３は、入力データを操作しそれをアプリケーションの構成管理データベース（ＣＭＤＢ）１３７から受領したデータとマッピングし、船舶の高リスク警報に加入をしたユーザに対して送信される電子メール警報のようなリアルタイム機能を追加する能力、機能性を提供する。なお、構成管理データベース（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｄａｔａｂａｓｅ）とは、情報システムの全コンポーネントに関する情報の統合された保管・管理（構成管理）を行うデータベースを指す。
【0109】
クエリ実行が非常に高速であるため、どのＡｚｕｒｅ領域でもマルチマスターレプリケーションが可能であり、ユーザの場所に迅速にクエリを実行できる。通常はＪＳＯＮドキュメントのテレメトリに依存するモノのインターネット（ＩｏＴ）ベースのシナリオを処理する機能を備えている。
【0110】
コスモスデータベース１３５は、ウェブアプリケーション１３９のための１次データストアとして機能し得る。ウェブアプリケーション１３９は、ファンクション部１３３から来るメッセージを解析及び分析するために構成された遠隔アプリケーション部である。コスモスデータベース１３５はまた、機器診断装置１０３からの「生」データを格納し、より深く、より記述的なデータポイント（事前に集約されたデータポイント）を捕捉する、より豊かな分析を可能にする。なお、コスモスデータベースとはＡｚｕｒｅの基盤上で動作可能であり、例えば、ＮｏＳＱＬを採用したデータベースサービスを指す。
【0111】
遠隔機器監視センター１１３は、構成管理データベース（ＣＭＤＢ）１３７を含んでおり、Ａｚｕｒｅプラットフォームをベースにすることもできる。構成管理データベース（ＣＭＤＢ）１３７は、ウェブアプリケーション１３９の構成管理データベース（ＣＭＤＢ）をホストする。さらに、プレゼンテーションのための迅速な検索を可能にするために、１つ以上のユーザ、顧客、船舶、及び機器のマッピングと最新のアラートをホストする。
【0112】
ウェブアプリケーション１３９は、上述したように、異なるデータベースから、解析されたメッセージの形式など、１又は複数の舶用電子機器１０７の故障に関連するすべての情報を取得する。ウェブアプリケーション１３９はさらに、この情報を使用して一つ以上の舶用電子機器１０７の故障の考えられる原因を特定する。
【0113】
さらに、ウェブアプリケーション１３９は、第１の衛星通信リンクを介して舶用電子機器１０７の故障をトラブルシューティングするための指示を与える。別の実施形態としては、ウェブアプリケーション１３９は取得した情報をエンジニアに提供し、エンジニアは一以上の舶用電子機器１０７の故障をトラブルシューティングするための手順を段階的に船舶１０１の乗組員に提供することもできる。
【0114】
ウェブアプリケーション１３９は、ポータルの柔軟なウェブホスティングを可能にするＡｚｕｒｅウェブアプリ上でホストされ得る。Ａｚｕｒｅウェブアプリケーションは、ウェブアプリケーション１３９の自動スケーリングのような機能を提供する。ユーザ定義のルールを使用することにより、ポータルユーザからの着信要求に応じて、ウェブアプリケーション１３９をスケールアウト及びスケールインすることができる。さらに、アプリケーションのより新しいバージョンを古いバージョンと共存させることができるため、通常の運用を中断することなく、本番環境でのテストをシームレスに実行することができる。他の実施形態として、ＡｚｕｒｅＤｅｖｏｐｓ、Ｇｉｔ、ＴＦＳ、Ｇｉｔｈｕｂなどを使用して、ＣＩ／ＣＤシナリオを簡単に有効化することができる。
【0115】
本一実施形態では、遠隔機器監視センター１１３は、Ａｚｕｒｅアプリケーションインサイトインサイトを備えることもできる。Ａｚｕｒｅアプリケーションインサイトは、Ａｚｕｒｅ監視機能であり、この機能使用して実行中のアプリケーションを監視することが可能になる。Ａｚｕｒｅアプリケーションインサイトには、複数のプラットフォームでのウェブ開発のための拡張可能なアプリケーションパフォーマンス管理（ＡＰＭ）サービスを含んでもよい。
【0116】
Ａｚｕｒｅアプリケーションインサイトにより、ライブＷＥＢアプリケーションの監視などの機能を実現することができ、パフォーマンス異常を自動的に検出して問題の診断に役立つ強力な分析を実行し、ユーザがＷＥＢアプリケーション１３９などで実際に何をしているかを理解するために使用することができる。Ａｚｕｒｅアプリケーションインサイトは、などのさまざまなプログラミング技術をサポートする可能性を有している。ＮＥＴ、Ｎｏｄｅ．ｊｓ、ＪａｖａＥＥ、ホストされたオンプレミス、ハイブリッド、任意のパブリッククラウドなどが含まれる。
【0117】
アプリケーションゲートウェイ１４１は、ウェブアプリケーション１３９を一般的なエクスプロイト及び脆弱性から集中的に保護するウェブアプリケーションファイアウォール（ＷＡＦ）を提供する。これは、一般的に知られている脆弱性を悪用する悪意のある攻撃からウェブアプリケーション１３９を保護する。アプリケーションゲートウェイ１４１が保護を提供するいくつかの一般的な攻撃としては、ＳＱＬインジェクション及びクロスサイトスクリプティングが挙げられる。
【0118】
Ａｚｕｒｅデータレイクストレージ（ＡＤＬＳ）１４３は非常にスケーラブルなデータストレージソリューションである。容量に制限のない任意の形式でデータを保存できる。これは、ビッグデータ及びアドバンスト・アナリティクスのシナリオのために構築されたアーキテクチャと組み合わされ、船舶１０１から来るデータのような大量のデータを処理するための高性能サービスを提供する。その目的のためにＡＤＬＳ１４３を使用してイベントハブ１３１から来る生データ（未加工データ）ポイントを格納し、機械学習サービスなどのサービスがこのデータを利用できるようにすることができる。
【0119】
本一実施形態では、遠隔機器監視センター１１３は、エンジニアへの報告／ダッシュボードプレゼンテーションのために、例えば、パワーＢＩ（登録商標）（マイクロソフト社が提供するセルフサービスとエンタープライズのビジネスインティジェンス）などの１又はそれ以上のビジネスインテリジェンスツールをさらに含むことができる。このツールは、ウェブアプリケーション１３９に埋め込むことができ、ＡＤＬＳ１４３からデータを得ることができる。
【0120】
遠隔機器監視センター１１３は、ビジネスインテリジェンスツールを使用して、一つ以上の舶用電子機器１０７の故障のダッシュボード表示をエンジニアに提供することができ、故障の原因をより容易に理解することができる。そして、船舶１０１の乗組員に対して、エンジニアが効果的なトラブルシューティング指示を行うことができる。
【0121】
図６は、本発明の一実施形態に従った、遠隔機器監視センター１１３によって実行され、船舶１０１上の１又は複数の舶用電子機器１０７を監視し、トラブルシューティング命令を提供する方法１００ｅのステップを示す。
【0122】
方法１００ｅは、ステップ１４５において、船舶１０１から一つ以上のメッセージ、例えば、舶用電子機器１０７の故障に関する情報を含む警報タイプのメッセージを受信すると開始する。
【0123】
ステップ１４７において、受信された警報状態に基づいて警報状態がオンかオフかを判断する。警報状態がオフである場合、本方法はステップ１４９で終了する。警報状態がオンである場合、方法はステップ１５１に進む。
【0124】
ステップ１５１において、メッセージは、例えば、メッセージで受信された機器モデル及びアラームコードに基づいて構成管理データベース（ＣＭＤＢ）１３７内のトラブルシューティング指示を検索することによって、このメッセージは分析され得る。
【0125】
遠隔機器監視センター１１３は第１の衛星通信リンクを経由して船舶１０１から機器モデル及び警報コードを直接取得することができる。さらに、ステップ１５３において、トラブルシューティング情報は、上記メッセージの分析に基づいて、舶用電子機器（１０７）の遠隔機器監視のために決定されてもよい。例えば、トラブルシューティングのステップが見つかったか否かを判断することができる。
【0126】
トラブルシューティングのステップがデータベースに見つからない場合、ステップ１５５において、遠隔機器監視センター１１３のエンジニアに、トラブルシューティングのステップを提供するように通知することができる。エンジニアは、トラブルシューティングのステップを決定し、それらを第１の衛星通信リンクを介して船舶１０１にいる乗組員に提供することができる。トラブルシューティングのステップが構成管理データベース（ＣＭＤＢ）１３７内に見つかると、ステップ１５７で、トラブルシューティング・ガイドが第１の衛星通信リンクを介して船舶１０１の乗組員に表示される。
【0127】
図７は、本発明の一実施形態による、船舶加入者に通知を提供するために遠隔機器監視センターによって実行される方法１００ｆのステップを示す。本方法は、ステップ１５９で開始する。ステップ１６１において、本方法は、イベントハブ１３１からデータを取得するステップを含む。
【0128】
データは、船舶１０１内の舶用電子機器１０７の故障に関連する情報を含むことができる。ステップ１６３で、データの直列化を実行することができる。ステップ１６５では、何らかのイベントが存在するかどうかを判定することができる。イベントが存在しないと判定されると、方法はステップ１６７で終了する。
【0129】
一方、イベントが存在する場合には、ステップ１６９に進む。ステップ１６９で、イベントのタイプを決定することができる。イベントタイプが「接続済み」である場合、ステップ１７１で、キャッシュされた接続性が更新され、メソッドは次のイベントの読み取りを継続する。イベントタイプが「プロパティ」である場合、ステップ１７３で、キャッシュされたプロパティが更新され、メソッドは次のイベントの読み込みを継続する。
【0130】
さらに、イベントタイプがアラームである場合、方法はステップ１７５に進む。ステップ１７５で、キャッシュされたアラームを更新することができる。さらに、検出されたアラームイベントについては、ステップ１７７において、そのアラームイベントが高リスクイベントに対応するか否かが判断される。アラームイベントが高リスクイベントに対応しない場合、メソッドは次のアラームイベントの読み込みを継続してもよい。
【0131】
一方、アラームイベントがハイリスクイベントである場合には、ステップ１７９に進む。ステップ１７９において、警報イベントに関連する通知が、船舶１０１の加入者に送信され得る。通知は、電子メール、ＳＭＳなどの形式で行われます。船舶１０１の加入者は、船舶１０１の所有者、船舶製造業者等を含むことができる。その後、メソッドは次のイベントの読み込みを続行する。
【0132】
図８は、本発明の一実施形態による、船舶１０１の遠隔機器監視のためのＩｏＴポータル１１５のブロック図を示す概略図である。ＩｏＴポータル１１５は、ＤＷゲートウェイ１２１とＩｏＴポータル１１５とを繋ぐ第２の衛星通信リンクを介してデバイス管理及び接続性管理を提供するために使用される。
【0133】
ＩｏＴポータル１１５は、メッセージキュー遠隔測定トランスポート（ＭＱＴＴ）フロントエンド２０１と、接続管理部２０３と、デバイス管理部２０５と、ＩｏＴ管理ポータル２０７と、ＩＯＴプラットフォームマシンーマシン（Ｍ２Ｍ）サービスアプリケーションインターフェース（ＡＰＩ）２０９とを含む。ＩｏＴポータル１１５は、遠隔機器監視センター１１３と通信する。ＭＱＴＴフロントエンド２０１は、ＭＱＴＴプロトコルを用いてＩｏＴポータル１１５とゲートウェイ装置１１１との間の通信を確立する。
【0134】
ＭＱＴＴは非常にシンプルで軽量なパブリッシュ／サブスクライブ・メッセージング・プロトコルであり、制約のあるデバイスや低帯域幅、高レイテンシー、又は信頼性の低いネットワーク向けに設計されている。なお、レイテンシー（遅延時間）とはリクエスト（データの送信、処理をリクエストする通知を発出）されたリソースが目的地に到達するまでにかかるネットワーク時間のことで、低レイテンシーとは良好な状態で遅延時間がほとんどないか、またはまったくないことを意味し、逆に高レイテンシーは悪い状態で、リクエストされたリソースが目的地に到達するまでに長い時間がかかることを意味する。
【0135】
設計の原則は、ネットワーク帯域幅とデバイスリソースの要件を最小限に抑えながら、信頼性と配信のある程度の保証を確保することである。これらの原則はまた、「マシンーマシン」（Ｍ２Ｍ）又は「モノのインターネット（ＩｏＴ）」関連のアプリケーション、及び帯域幅と電力が高価なアプリケーションにとって、プロトコルを理想的なものにする。ＭＱＴＴプロトコルの基本的な利点は軽量であることで、リソース帯域幅が非常に少ないデバイス向けに設計されている。これはＩｏＴの世界における通信のデフォルト標準でもある。
【0136】
ＭＱＴＴプロトコルはまた、複数の船舶に設置された複数の機器診断装置のための大規模な接続性管理及びデバイス管理のために、接続管理部２０３及びデバイス管理部２０５によって使用される。さらに、ＩｏＴ管理ポータル２０７は、ＩｏＴポータルに接続されているすべてのＤＷゲートウェイ及び接続を表示及び管理するために使用され得るウェブベースのアプリケーションである。ＩｏＴ管理ポータル２０７を使用すると、ＩｏＴポータル１１５に接続されているすべてのＤＷゲートウェイの表示と管理が容易になる。ＩｏＴ管理ポータル２０７は、デバイスの管理に役立つだけでなく、ユーザの管理、ファームウェアの更新、及び機器診断装置上で実行する必要がある他のすべてのバッチタイプ処理にも役立つ。
【0137】
さらに、ＩｏＴプラットフォームＭ２ＭサービスＡＰＩ２０９は、新しいデバイス、例えば、新しいゲートウェイデバイスがＩｏＴポータル１１５に接続することを可能にし、モバイル及びデスクトップアプリケーションが利用可能なデータと対話することを可能にするために使用されるＡＰＩのセットを含む。従って、ＩｏＴプラットフォームＭ２ＭサービスＡＰＩ２０９は、アプリケーションプログラムによって使用され、ＩｏＴポータル１１５とのインターフェースをする。
【0138】
図９は、本発明の一実施形態による、舶用電子機器１０７ａ―１０７ｎと通信する機器診断装置１０３を例示的に示す概略図である。
【0139】
機器診断装置１０３は、常にネットワークを監視し、１又は複数の舶用電子機器１０７ａ―１０７ｎからのデータを待機するサーバとして機能し得る。機器診断装置１０３が舶用電子機器１０７ａ―１０７ｎから１又はそれ以上のメッセージ（データ）を受信すると、機器診断装置１０３はデータを解析する。換言すれば、舶用電子機器１０７はそれが収集するデータのタイプのみを送信することができ、機器診断装置１０３は、それに応じて各舶用電子機器１０７からの各メッセージデータブロックを解析することができる。従って、機器診断装置１０３は、舶用電子機器１０７ａ―１０７ｎのそれぞれに対して別々のアルゴリズムを実施することができる。
【0140】
舶用電子機器１０７ａ―１０７ｎは、機器診断装置１０３との通信にＮＭＥＡ０１８３規格を使用することができる。１又はそれ以上のメッセージにはＮＭＥＡメッセージが含まれており、故障中の機器の名称、警報状態、アラームの説明など、デバイスの故障に関連する情報を提供する。舶用電子機器１０７ａ―１０７ｎは、他の装置からの異なるタイプのデータを測定することを担当するセンサであってもよい。
【0141】
図１０は、本発明の一実施形態による、機器診断装置１０３の初期化手順を例示的に示す概略図である。
【0142】
機器診断装置１０３がメッセージのタイプに基づいてメッセージを解析するために、ユーザは、ＤＷワークベンチ１１７によって提供されるＵＩを介して解析されるメッセージのタイプを設定することができる。すべてのメッセージ・タイプは、ドロップダウンリストの形式でユーザに提供される。
【0143】
加えて、機器診断装置１０３は、マシンのネットワークインターフェースを介してネットワークに接続することができる。ユーザは、再びＵＩ（ユーザインターフェース）を介して機器診断装置１０３のネットワークインターフェース、ＩＰアドレス及びポート番号を設定して、機器からのメッセージを聴くことができる。
【0144】
従って、初期化手順には機器診断装置１０３のための５つのパラメータを設定することを含まれている。図１０に示すように、５つのパラメータは、インターフェースアドレス（インターフェース）３０１、メッセージタイプ３０３、ＵＤＰ送信３０５、グループアドレス３０７、及びポート番号（ポート）３０９である。初期化手順は、一以上の舶用電子機器１０７から一以上のメッセージを受信するために機器診断装置１０３を配備する前に完了しなければならない。初期化手順の完了後にのみ、機器診断装置１０３は、舶用電子機器１０７と通信することができる。
【0145】
インターフェース３０１は、ホスト（すなわち、機器診断装置１０３）、より具体的にはホストのネットワークインターフェースを識別するＩＰアドレスを含み、ネットワーク内のホストの位置、いわばそのホストへの接続を確立する能力を提供する。メッセージタイプ３０３は、ＮＭＥＡ０１８３メッセージのタイプを定義する。
【0146】
ＮＭＥＡ０１８３メッセージタイプを定義することにより、機器診断装置１０３は、特定のイベントについてのみ舶用電子機器１０７を監視することができる。例えば、メッセージタイプ３０３をＡＬＲとして定義することによって、機器診断装置１０３は、アラームタイプメッセージのみを決定することができる。
【0147】
さらに、ＵＤＰ送信３０５は、メッセージタイプを定義するために使用される。舶用電子機器１０７からメッセージを受信すると、機器診断装置１０３は受信したメッセージのタイプが定義されたＵＤＰ送信タイプと一致するかどうかをチェックする。機器診断装置１０３は受信メッセージのタイプがＵＤＰ送信メッセージのタイプと一致する場合にだけ受信メッセージの解析を継続する。なお、グループアドレス３０７はＩＰマルチキャストグループアドレスである。
【0148】
さらに、グループ・アドレス３０７は機器診断装置１０３及び舶用電子機器１０７によって、マルチキャスト・メッセージを送受信するために使用される。機器診断装置１０３は、そのデータパケット内のＩＰ宛先アドレスとしてグループアドレス３０７を使用する。舶用電子機器１０７は、このグループアドレス３０７を使用して、そのグループからのパケットの受信及びそのグループへのパケットの送信に関心があることをネットワークに通知する。ポート３０９は、特定のプロセス又はネットワークサービスのタイプを識別する論理構造である。
【0149】
初期化手順の完了後、機器診断装置１０３は、舶用電子機器１０７から１かそれ以上のメッセージを受信することができる。メッセージを受信すると、機器診断装置１０３は、所定の構造に基づいてメッセージを解析する。定義済みの論理構造は、メッセージのどの部分又はブロックにどの情報が含まれるかが定義されている。この予め定義された構造は一意であり実行中のプロセス全体を通して変化せず、これにより機器診断装置１０３は各メッセージを正しく解析することができる。
【0150】
定義済みの構造はメッセージのタイプによって異なる場合がある。異なるタイプのメッセージは機器診断装置１０３に向けて舶用電子機器１０７の故障についての警告を示す警告タイプのメッセージであり得る。
【0151】
他のタイプのメッセージは、船舶の航海（例えば、ＧＰＳ、深度、速度等）に関連するデータを提供する特性タイプのメッセージを含んでもよい。さらに、メッセージのタイプは船舶１０１が遠隔機器監視センター１１３と接続されているか切断されているかの情報を提供する接続型メッセージであってもよい。
【0152】
本発明の一実施形態では、ユーザが船舶１０１内の舶用電子機器１０７の故障について船舶１０１を監視したい場合、ユーザは、図１０に示すように、機器診断装置１０３のメッセージタイプ３０３をＵＩ（ユーザインターフェース）上で「ＡＬＲ」に設定する。機器診断装置１０３は、メッセージが舶用電子機器１０７のいずれかから受信されたときにトリガーされる。機器診断装置１０３は、最初にメッセージを送信するために使用されるＩＰサービスのタイプを決定する。ＩＰサービスのタイプは、ユニキャスト又はマルチキャストである。
【0153】
ＩＰサービスのタイプを決定するために、機器診断装置１０３は、以下の規則のセットを使用する。
１．メッセージの先頭の確認
ａ メッセージが'＄'又は'！'で始まる場合、ＵＮＩＣＡＳＴ ＩＰサービスを用いてメッセージを解析
ｂ メッセージが"ＵｄＰｂＣ＼０＼ｓ"（＼０はＮＵＬＬ）で始まる場合、ＵＮＩＣＡＳＴ ＩＰサービスを用いてメッセージを解析
１．メッセージの先頭の確認
ａ メッセージが'＄'又は'！'で始まる場合、ＵＮＩＣＡＳＴ ＩＰサービスを用いてメッセージを解析
ｂ メッセージが"ＵｄＰｂＣ＼０＼ｓ"（＼０はＮＵＬＬ）で始まる場合、ＵＮＩＣＡＳＴ ＩＰサービスを用いてメッセージを解析
【0154】
メッセージがＵＮＩＣＡＳＴＩＰサービスを使用している場合、機器診断装置１０３は、以下のように構成される。
１．メッセージ内の第２の'＄'を検索する。これは、読み取るＮＭＥＡメッセージの開始を示す。
２．ＮＭＥＡメッセージを読み取り、メッセージのタイプを判別する（ＮＭＥＡメッセージのインデックス３ー６）。
３．ステップ１で決定したメッセージのタイプとターゲットメッセージのタイプ（例えば、「ＡＬＲ」）を比較する。
ａ 一致が続く場合はメッセージを無視し、解析を停止する。
４．メッセージのタイプに基づいてＮＭＥＡメッセージを解析する
１．メッセージ内の第２の'＄'を検索する。これは、読み取るＮＭＥＡメッセージの開始を示す。
２．ＮＭＥＡメッセージを読み取り、メッセージのタイプを判別する（ＮＭＥＡメッセージのインデックス３ー６）。
３．ステップ１で決定したメッセージのタイプとターゲットメッセージのタイプ（例えば、「ＡＬＲ」）を比較する。
ａ 一致が続く場合はメッセージを無視し、解析を停止する。
４．メッセージのタイプに基づいてＮＭＥＡメッセージを解析する
【0155】
メッセージがＭＵＬＴＩＩＣＡＳＴ ＩＰサービスを使用している場合、機器診断装置１０３は、以下のように構成される。
１． メッセージの前面（"「ＵｄＰｂＣ＼０＼ｓ："）を除外する。
２． メッセージの"＼ｓ："をスキャンして、最初のメッセージの最後を見つける。
ａ メッセージがＮＵＬＬの場合、終了する。
ｂ "＼ｓ："が見つからない場合、メッセージは１つだけである。
３．デバイス名とＩＤの検索
ａ "ＵｄＰｂＣ＼０＼ｓ"の次の６文字を読んで機器名とＩＤを確認する。
４．ＮＭＥＡメッセージを見つける。
ａ ＮＭＥＡメッセージの開始を示す最初の'＄'文字を検索する。
ｂ ＮＭＥＡメッセージを読み取り、メッセージのタイプを判別する（ＮＭＥＡメッセージのインデックス３ー６）。
ｃ メッセージのタイプとターゲットメッセージのタイプを比較する（例えば、「ＡＬＲ」）。
ｄ 一致する場合は、メッセージのタイプに基づいてＮＭＥＡメッセージの解析を続行する。一致しない場合は、メッセージを無視して解析を停止する。
５． メッセージポインタをメッセージの末尾（'＼ｓ：'で示される）に移動し、ステップ２を繰り返する。
１． メッセージの前面（"「ＵｄＰｂＣ＼０＼ｓ："）を除外する。
２． メッセージの"＼ｓ："をスキャンして、最初のメッセージの最後を見つける。
ａ メッセージがＮＵＬＬの場合、終了する。
ｂ "＼ｓ："が見つからない場合、メッセージは１つだけである。
３．デバイス名とＩＤの検索
ａ "ＵｄＰｂＣ＼０＼ｓ"の次の６文字を読んで機器名とＩＤを確認する。
４．ＮＭＥＡメッセージを見つける。
ａ ＮＭＥＡメッセージの開始を示す最初の'＄'文字を検索する。
ｂ ＮＭＥＡメッセージを読み取り、メッセージのタイプを判別する（ＮＭＥＡメッセージのインデックス３ー６）。
ｃ メッセージのタイプとターゲットメッセージのタイプを比較する（例えば、「ＡＬＲ」）。
ｄ 一致する場合は、メッセージのタイプに基づいてＮＭＥＡメッセージの解析を続行する。一致しない場合は、メッセージを無視して解析を停止する。
５． メッセージポインタをメッセージの末尾（'＼ｓ：'で示される）に移動し、ステップ２を繰り返する。
【0156】
ＮＭＥＡメッセージを解析するためのルールセットは次のとおりである。
１． メッセージの先頭の文字が'＄'又は'！'かチェックする。
ａ 見つからない場合は解析を停止する。
２． '＊'文字を検索してチェックサムを検索及び保存する。チェックサムは'＊'に続く２つの数字で示され、'＊'をＮＵＬＬに置き換える。
３． トーカーを得る。１又はそれ以上のメッセージを機器診断装置１０３に送信する装置である。舶用電子機器の名前は、'＄'又は'！'の後の２文字を解析して決定される。ＮＭＥＡメッセージのインデックス１と２
４． パラメータの先頭に移動（インデックス６、ＮＭＥＡメッセージの開始を示す'＄'又は'！'の文字の後）
５．'，'又はＮＵＬＬを読み取り
ａ'，'が見つかった場合は、ステップ４を繰り返してパラメータを保存し、次のパラメータに移動する。
ｂ ＮＵＬＬが検出された場合、メッセージが解析され、終了する。
１． メッセージの先頭の文字が'＄'又は'！'かチェックする。
ａ 見つからない場合は解析を停止する。
２． '＊'文字を検索してチェックサムを検索及び保存する。チェックサムは'＊'に続く２つの数字で示され、'＊'をＮＵＬＬに置き換える。
３． トーカーを得る。１又はそれ以上のメッセージを機器診断装置１０３に送信する装置である。舶用電子機器の名前は、'＄'又は'！'の後の２文字を解析して決定される。ＮＭＥＡメッセージのインデックス１と２
４． パラメータの先頭に移動（インデックス６、ＮＭＥＡメッセージの開始を示す'＄'又は'！'の文字の後）
５．'，'又はＮＵＬＬを読み取り
ａ'，'が見つかった場合は、ステップ４を繰り返してパラメータを保存し、次のパラメータに移動する。
ｂ ＮＵＬＬが検出された場合、メッセージが解析され、終了する。
【0157】
本発明の一実施形態では、機器診断装置１０３は、"ＡＬＲ"タイプのメッセージを受信するように初期化されてもよい。
【0158】
図１１は、本発明の一実施形態による、船舶内の装置から機器診断装置１０３によって受信される例示的なメッセージ３００ｃを示す。
【0159】
表１は、本発明の一実施形態による、受信メッセージごとに機器診断装置１０３によって処理及び格納されるパラメータを含む例示的な表である。
【0160】
【表1】
【0161】
この段階で、機器診断装置１０３はＵＩを使用する初期化プロセス（パラメータ２，３，４，７，９）の間、又は実行時（パラメータ１及び６）の間のいずれかにおいて、表１のパラメータ１から５、７及び９の値を既に設定している。パラメータＮｏ．８が真でない場合、機器診断装置１０３はメッセージを解析することに注意する必要がある。
【0162】
ＮＭＥＡメッセージの構文解析は、図１１に示されるメッセージを使用して例示的に示すことができる。メッセージ３００ｃは、識別データ及び警報状態データを示す複数のフィールドを含む。
【0163】
メッセージ３００ｃは"ＵｄＰｂＣ．＼ｓ："で始まる。機器診断装置１０３はパラメータＮｏ．７をＭＵＬＴＩＣＡＳＴに設定する。"ＵｄＰｂＣ．＼ｓ："の後の６文字は、機器名と機器のＩＤ（アイデンティティ）である。例示的なメッセージ３００ｃによれば、機器名及びそのＩＤは"ＧＰ０００１"であり、ここで、"ＧＰ"は機器名であり、"０００１"はアイデンティティである。
【0164】
次に、機器診断装置１０３は、ＮＭＥＡメッセージの開始についてメッセージ３００ｃを検索する。ＮＭＥＡメッセージの開始は"＄"で示される。"＄"の後の最初の２文字は機器名である。例示的なメッセージ３００ｃでは機器名は"ＧＰ"である。次の３文字はＮＭＥＡメッセージのタイプを示す。図示の例では、ＮＭＥＡメッセージタイプは"ＡＬＲ"である。ＮＭＥＡメッセージの本体、すなわちアラームイベント自体の値は最初のコンマの後、メッセージの最後の"＊"の前に含まれる。これらの値はすべてカンマで区切られ、イベントが発生した時刻から始まり、アラーム番号、アラーム条件、アラーム確認応答状態、アラームの説明が続く。従って、舶用電子機器１０７からの１又はそれ以上のメッセージは特定のタイプのメッセージを所定の規則に基づいて構文解析される。
【0165】
別の実施形態では、機器診断装置１０３は、例えばＡＬＲ型メッセージ（図１１で上述したように）を舶用電子機器１０７から受信すると、第１のトリガー及び第２のトリガーを実行する。第１のトリガーは、舶用電子機器１０７から１又はそれ以上のメッセージを受信するバックグラウンドプロセスとして常に動作するように構成される。１又はそれ以上のメッセージからの各メッセージは警報状態データを含んでおり、第１のトリガーは警報状態データを使用して現在の警報状態と以前の警報状態との比較に基づいてメッセージを処理する。
【0166】
さらに、機器診断装置１０３は第２のトリガーを実行するように構成されており、第２のトリガーは一以上の舶用電子機器１０７からメッセージを受信するために、予定された時間間隔で動作する。第２のトリガーは、最後に（直近に）予定されたタイムスタンプと現在の予定されたタイムスタンプの間で警報状態データに変更があるかどうかをチェックするためにメッセージを処理するように設定されている。そして、検出部１２５は第１のトリガー及び第２のトリガーによるメッセージの処理に基づいて、舶用電子機器１０７の故障に関連する情報を含むメッセージを遠隔機器監視センター１１３に送信する。
【0167】
最後に、機器診断装置１０３はローカルデータベース１０９にアクセスし、具体的には、データベース１０９に格納される以下の３つのテーブル、１．機器警報状態テーブル、２．アラームキー、３．機器警報状態リクエストにアクセスする。
【0168】
［機器警報状態テーブル］
機器警報状態テーブルは、舶用電子機器１０７に関連する情報と、機器診断装置１０３によって受信されたアラームの現在の状態及び以前の状態とを含んでいる。機器警報状態テーブルに含まれる情報の詳細を以下に示す。このテーブルには、次の１０のフィールドがある。
機器警報状態テーブルは、舶用電子機器１０７に関連する情報と、機器診断装置１０３によって受信されたアラームの現在の状態及び以前の状態とを含んでいる。機器警報状態テーブルに含まれる情報の詳細を以下に示す。このテーブルには、次の１０のフィールドがある。
【0169】
【表2】
【0170】
［アラームキーテーブル］
このテーブルは、各アラーム番号を特定のアラームキーにマッピングするために使用する。このテーブルには、次の３つのフィールドがある。
このテーブルは、各アラーム番号を特定のアラームキーにマッピングするために使用する。このテーブルには、次の３つのフィールドがある。
【0171】
【表3】
【0172】
［機器警報状態リクエストテーブル］
このテーブルには、警報状態の予定されたリクエストが最後に実行された時刻を保持するカラムがある。このテーブルには１つのフィールドがある。
このテーブルには、警報状態の予定されたリクエストが最後に実行された時刻を保持するカラムがある。このテーブルには１つのフィールドがある。
【0173】
【表4】
【0174】
図１２は、本発明の一実施形態による、第１のトリガーによって実行される方法４００ａのステップを示すフローチャートである。図１３は、メッセージの受信と第１のトリガーによって実行される警報状態の送信を示す図である。
【0175】
機器診断装置１０３は、警告メッセージの受信を決定するために、バックグラウンドプロセスとして第１のトリガーを継続的に実行する。機器診断装置１０３が警告メッセージを受信すると、ステップ４０１において機器診断装置１０３はトリガーが掛かり最初のトリガーを実行する。
【0176】
ステップ４０３で、受信されたアラームの状態がもしあれば、"機器警報状態テーブル"から検索（又は選択）され得る。これらのレコードは、機器から受信されたたアラームに関連付けられデータベース１０９に格納される。
【0177】
ステップ４０５において、上記レコードに基づいて、舶用電子機器１０７に対応するアラートタイプメッセージが機器診断装置１０３によって受信されたとき、受信したアラートメッセージが最初であるかどうかを判断することができる。そのために、機器診断装置１０３は、機器警報状態テーブル内の舶用電子機器１０７に対応する多数の警報状態レコードをチェックする。
【0178】
警報状態レコードの数が０（すなわち、舶用電子機器１０７に対応する警報状態の記録がない）である場合、機器診断装置１０３は受信したアラートメッセージが舶用電子機器１０７に対応するアラートタイプメッセージを受信した最初のものであると判断する。この場合、方法はステップ４０７に進む。ステップ４０７では、舶用電子機器１０７に対応する新たな警報状態を装置警報状態テーブルに挿入することができ、この方法はステップ４１５で終了する。
【0179】
一方、警報状態の数が０より大きい場合、機器診断装置１０３は、以前（又は以前のタイムスタンプ時）に１又は複数の舶用電子機器に対応するアラートタイプメッセージがあったと判断する。この場合、方法４００ａはステップ４０９に進む。
【0180】
ステップ４０９では現在の警報状態が機器警報状態テーブルからの以前の警報状態と比較され得る。さらに、ステップ４１１では舶用電子機器１０７に対応する１又は複数の警報状態が変化したかどうかを判定することができる。警報状態が変更されていないと判定された場合、プロセスは４１５で終了する。
【0181】
一方、警報状態が変化したと判定された場合、ステップ４１３において装置警報状態テーブル内の警報状態を更新することができ、本方法はステップ４１５で終了する。
【0182】
図１４は、本発明の一実施形態による、第２のトリガーによって実行される方法４００ｂのステップを示すフローチャートである。図１５は、メッセージの受信と第１のトリガーによって実行される警報状態の送信を示す図である。
【0183】
第２のトリガーは、舶用電子機器１０７から１又はそれ以上のメッセージを受信するために予定された時間間隔で動作する。第２のトリガーは、最後に（直近に）予定されたタイムスタンプと現在の予定されたタイムスタンプの間で警報状態データに変更があるかどうかをチェックするためにメッセージを処理する。
【0184】
第２のトリガーによるメッセージの処理に基づいて、検出部１２５はさらに、舶用電子機器１０７の故障に関連する情報を含むメッセージを遠隔機器監視センター１１３に送信する。そのために、ステップ４１７において第２のトリガーが実行を開始する。
【0185】
ステップ４１９で、現在スケジュールされているリクエストの時刻を取得することができる。ステップ４２１では、機器警報状態リクエストテーブルからのすべてのレコードが読み取られ、第２のトリガーのために予定されたリクエストが最後に実行された時刻が決定される。ステップ４２３では、受信した予定されたリクエストが機器診断装置１０３によって予定されたリクエストが受信された最初のときであるかどうかを、装置警報状態リクエストテーブル内にレコードが存在するかどうかをチェックすることによって決定することができる。
【0186】
予定されたリクエストの数が０である場合、機器診断装置１０３は、受信された予定されたリクエストが、予定されたリクエストを受信した最初のものであると判断する。この場合、方法はステップ４２５に進む。
【0187】
ステップ４２５で、現在の予定されているリクエストタイムスタンプを機器警報状態リクエストテーブルに挿入することができる。さらに、ステップ４２７において、以前に予定されたリクエストのタイムスタンプは、現在予定されたリクエストのタイムスタンプから所定の時間を減算することによって計算され、次いで、本方法はステップ４２９に進む。
【0188】
一方、予定されたリクエストの数がゼロでない場合、すなわち、現在予定されたリクエストが最初に予定されたリクエストでない場合、方法は直接ステップ４２９に進む。ステップ４２９で、機器警報状態テーブルからのすべてのアラームを読み出すことができる。
【0189】
ステップ４３１では、アラームイベントタイムスタンプが直前に予定されたリクエストタイムスタンプより後であるかどうかを判定することができる。機器診断装置１０３が、アラームイベントタイムスタンプが前に予定されたリクエストタイムスタンプより後でないと判断した場合（つまり、直前に予定されたリクエストタイムスタンプの前）、方法４００ｂは、次のアラームイベントの読み取りを継続してもよい（フローチャートのＡ）。
【0190】
一方、機器診断装置１０３が、アラームイベントタイムスタンプが前に予定されたリクエストタイムスタンプより後であると判断した場合、方法４００ｂはステップ４３３に進む（フローチャートのＢ）。ステップ４３３では、アラームイベントタイムスタンプが現在予定されたリクエストタイムスタンプより前であるかどうかが判定される。
【0191】
機器診断装置１０３が、アラームイベントタイムスタンプが現在予定されたリクエストタイムスタンプより前でないと判断した場合、方法４００ｂは、次のアラームイベントの読み取り（Ａ）を継続する。一方、機器診断装置１０３が、アラーム・イベントタイムスタンプが現在予定されたリクエストタイムスタンプより前であると判断した場合、方法はステップ４３５に進む。
【0192】
ステップ４３５では、警報状態が変化したかどうかを判定する。機器診断装置１０３は警報状態が変化していないと判断した場合、メソッドは次のアラームイベントの読み取りを継続する。
【0193】
一方、機器診断装置１０３は、警報状態が変化したと判定した場合、ステップ４３７に進む。ステップ４３７では、アラームメッセージを遠隔機器監視センター１１３に送信することができる。ステップ４３９で、装置警報状態リクエストテーブルを現在予定されたリクエストタイムスタンプで更新することができ、方法はステップ４４１で終了する。
【0194】
図１６は、本発明の一実施形態による、警報状態を決定するために第２のトリガーによって使用される例示的な装置警報状態表４００ｃを示す。
【0195】
図に示されるように、舶用電子機器におけるＥＩ０００１の機器警報状態を考慮して、第２のトリガーは、ＥＩ０００１のアラームＮｏ．３８０に対して現在の警報状態がＶ（ＯＦＦ）であり、タイムスタンプ：２０２０―０２―２７ １１：３７：０１．９７４．であると決定する。しかし、同じアラームＮｏ．３８０最後の変化アラーム条件が最後の変化タイムスタンプ：２０２０―０２―２７ １１：３６：５８．０００．でアラームの状態が確認されたので、最後の警報条件はＡ（ＯＮ）である。
【0196】
第２のトリガーは、現在の警報状態がアラームを発行する前の予定されたタイムスタンプと現在の予定されたタイムスタンプの間にあるかどうかをさらにチェックする。これがｔｒｕｅである場合、この期間中にアラーム条件の状態が変化したかどうかを確認する。ＹＥＳの場合、アラームが公開（通知）され、最後の警報条件領域はＡ（ＯＮ）に設定される。
【0197】
表５は、本発明の一実施形態による、２０分間の警報状態変化に対する第２のトリガーの動作を示す例示的なテーブル４００ｄを示している。
【0198】
【表5】
【0199】
ここでは例示的に、第２のトリガーは５分のスケジュール間隔を有すると仮定している。従って、第２のトリガーは５分毎に舶用電子機器１０７のうちの特定の機器の現在の警報状態と前の警報状態との間の警報状態の変化をチェックする。
【0200】
表からわかるように、０分から５分の間にある最初のタイムスタンプ間隔では、現在の警報状態は１（つまり、特定の機器に対応する警報状態が設定又はオンになっている）で、以前の（又は最後の）警報状態は０（つまり、特定の機器に対応する警報状態は、以前はＯＦＦであった。）ということになる。第２のトリガーは５分間の終わりに警報状態の変化を決定し、さらに現在の警報状態が１であると決定して最後の警報状態を１に設定し、そしてアラームを遠隔機器監視センター１１３に発する。
【0201】
５から７分の間の第２のタイムスタンプ間隔においては、警報状態に変化があるが、この警報状態の変化は、第２のトリガーの次の予定された間隔の前である。従って、機器診断装置１０３は、１０分で始まる次の予定された間隔を待つ。
【0202】
７から１０分の間の３番目のタイムスタンプ間隔では現在の警報状態は１で、以前の警報状態は０である。１０分経過した時点で、次のトリガーは警報状態に変化があり、現在の状態が１であると判断する。従って、第２のトリガーは最後のアラーム条件を１に設定しアラームを発する。
【0203】
１０から１５分の間の４番目のタイムスタンプ間隔においては、現在の警報状態と以前の警報状態に変化がないため、第２のトリガーは警報状態を発しない。さらに、１５から２０分の間の５番目のタイムスタンプ間隔では、現在の警報状態は０で、以前の警報状態は１である。この場合、２０分後の第２のトリガーは、現在の警報状態が０（ＯＦＦＦ）であると判断しアラート状態を発する。
【0204】
図１７は、本発明の一実施形態による、１又は複数の用電子機器１０７からのデータが機器診断装置１０３によって受信されるときの例示的な捕捉タイムチャートを示す。
【0205】
機器診断装置１０３は、舶用電子機器１０７からデータを受信するために、図１０に関して前述したように初期化される。図１７は、ある時間間隔（Ｘ軸）の間に受信されたデータのバイト数（Ｙ軸）を示している。この実施形態では３つの舶用電子機器からのデータのみがＵＤＰポート番号６０００４で受信されると考えられる。タイムチャートからわかるように、３つのデバイスからの平均遷移バイトは１秒間隔で約９Ｋバイトである。
【0206】
図１８は、本発明の一実施形態による、トリガーによって処理され、ローカルデータベースに記録されるデータを含む例示的なテーブル４００ｆを示す。
【0207】
図から分かるように、機器診断装置１０３は２６行のＡＬＲログをデータベース１０９に格納されている機器状態テーブルに記録する。機器状態テーブルには、アラーム番号、警報状態、アラーム確認状態、最終警報条件、タイムスタンプ、最終変更タイムスタンプ、ログ、説明等の情報が格納される。
【0208】
図１９は、本発明の一実施形態による機器診断装置１０３が遠隔機器監視センター１１３にデータを発するときの例示的な捕捉タイムチャートを示す。
【0209】
図から分かるように、以前の予定されたタイムスタンプ内と現在の予定されたタイムスタンプ内で状態に変化が生じたときに、必要な情報が最終的に１回だけ発せられる。
【0210】
図２０は、本発明の一実施形態による、初期化手順の例示的なコールフローを示す。
【0211】
初期化手順にはソケットの作成、認証、プロポーザル（提案）、及びコマンド送信の各手順が含まれる。ステップ５０１で、舶用電子機器１０７との接続が確立される。ソケットクリエーションの作成では、プラグインと舶用電子機器１０７との間の通信に使用されるソケットを作成する。ここでいうソケットは、ソケットインターネットがＴＣＰ／ＩＰと呼ぶ通信プロトコルを利用する際にそのＴＣＰ／ＩＰをプログラムから利用するためのプログラムの世界とＴＣＰ／ＩＰの世界を結ぶ特別な出入り口を指す。
【0212】
上記作成をするために、プラグインには舶用電子機器１０７に関連付けられたインターネットプロトコル（ＩＰ）アドレスとポート番号が提供される。ＩＰアドレスとポート番号は、プラグインに対して事前に定義されている場合がある。他の実施形態として、ユーザは、ＤＷワークベンチ１１７のグラフィカルユーザインターフェース（ＧＵＩ）のいずれかを介してＩＰアドレス及びポート番号をリアルタイムで提供してもよい。
【0213】
ソケットを作成するために、ステップ５０１において、デバイスとの接続確立のリクエストがプラグインによって送られてもよい。ステップ５０３で、デバイスからの接続リクエストに対する肯定応答がプラグインによって受信されソケットが作成される。
【0214】
ソケットが正常に作成された後の次のステップは認証ステップである。認証中に、ステップ５０５において、「認証」リクエストにおけるユーザ名及びパスワードがプラグインによって舶用電子機器１０７に送信される。これらユーザ名及びパスワードの２つの値が正しければ、ステップ５０７で「認証―ＯＫ」メッセージの肯定応答がプラグインによって受信される。認証が成功すると次のステップが実行される。そうでなければ舶用電子機器１０７が接続を「ドロップ」する。
【0215】
ユーザ名とパスワードは、プラグインのプログラミングコード内で静的に事前定義できる。他の実施形態として、ユーザは、ＤＷワークベンチ１１７のグラフィカルユーザインターフェース（ＧＵＩ）のいずれかを介してこれらの２つの値をリアルタイムで提供してもよい。
【0216】
認証が成功した後の次のステップとして、プロポーザル（又はネゴシエーション）ステップに移る。プロポーザル時に、プラグインは暗号化を使用するかどうかを決定する。プラグインが暗号化を使用することを決定した場合、プラグインはさらに、舶用電子機器１０７との通信に使用する暗号化のタイプを決定する。
【0217】
ステップ５０９では、プロポーザル時に、舶用電子機器１０７との通信に使用するために決定された暗号をプラグインによって送信することができる。さらに、デバイスが暗号化をサポートする場合、ステップ５１１において、舶用電子機器１０７からの「提案ＯＫ」メッセージの肯定応答がプラグインによって受信され得る。
【0218】
次のステップ５１３では、プラグインによって舶用電子機器１０７上で実行されるアクションのコマンド番号が舶用電子機器１０７に送信される。図１８から分かるように、コマンドがプラグインによって舶用電子機器１０７に送信され、ステップ５１５で１又はそれ以上のコマンドに対応する応答がプラグインによって受信される。
【0219】
【0220】
表６は、本発明の一実施形態による、プラグインに関連するコマンドを、それらに対応するコマンド番号及び説明と共に示す例示的な表である。
【0221】
【表6】
【0222】
各コマンドに対応するコマンド番号は予め定義されており、プラグイン及び舶用電子機器１０７に提供される。受信したコマンド番号に基づいて、舶用電子機器１０７は異なる結果を送信する。
【0223】
【0224】
図２１は、本発明の一実施形態による、ステータス取得コマンドの実行ステップを示す。
【0225】
ステップ５１７で、プラグイン１０５によって、ステータス取得コマンドが舶用電子機器１０７に送信される。ステータス取得コマンドは、舶用電子機器１０７のステータスを取得するために使用される。コマンドを受信した舶用電子機器１０７は、ステータス取得コマンドに対応するコマンド番号を決定し、ステップ５１９で舶用電子機器１０７のステータスをプラグイン１０５によって受信する。舶用電子機器１０７の状態は、ＪａｖａＳｃｒｉｐｔオブジェクト表記（ＪＳＯＮ）フォーマット文字列であってもよい。
【0226】
図２２は、本発明の一実施形態による、ログリストコマンドの実行ステップを示す。ステップ５２１で、舶用電子機器１０７に関連するログを取得するためにプラグイン１０５によって舶用電子機器１０７にログリストコマンドを送信する。これに応答して、ステップ５２３で、舶用電子機器１０７からのログリストデータがプラグイン１０５によって受信され得る。ログリストデータには、ｔａｒ．ｇｚファイルの名前が含まれている。このファイルは舶用電子機器１０７に関連するログを含むので、データダウンロードコマンドのパラメータとして使用することができる。
【0227】
図２３は、本発明の一実施形態による、データダウンロードコマンドの実行ステップを示す。プラグイン１０５はデータダウンロードコマンドを舶用電子機器１０７に送信する。データダウンロードコマンドは舶用電子機器１０７でログリストコマンドを実行するために使用される。さらに、データダウンロードコマンドは舶用電子機器に関連するログを含むｔａｒ．ｇｚファイルをデータベース１０９に格納する。
【0228】
図２４から分かるように、ステップ５２５において、データダウンロードコマンド（ＤａｔａＤｏｗｎｌｏａｄｉｎｇ ｃｏｍｍａｎｄ）はプラグイン１０５によって舶用電子機器１０７に送信される。これに応答して、ステップ５２７において、ｔａｒ．ｇｚの名前及びｔａｒ．ｇｚの内容を含むデータダウンロードデータ（Ｄａｔａ Ｄｏｗｎｌｏａｄｉｎｇ ｄａｔａ）がプラグイン１０５によって受信され得る。さらに、ステップ５２９では、プラグイン１０５によってハードディスク上のｔａｒ．ｇｚを保存してもよい。
【0229】
図２４は、本発明の一実施形態によるエクスポート設定コマンドの実行ステップを示す。
【0230】
エクスポート設定コマンドは舶用電子機器１０７に関連する設定を取得し、その設定を記憶するために使用される。ステップ５３１ではプラグイン１０５によって舶用電子機器１０７に設定のエクスポートコマンドが送信される。これに応答して、ステップ５３３で、舶用電子機器１０７に関連するエクスポート設定データがコアプラグイン１０５によって受信される。データは舶用電子機器１０７に関連する設定情報を含む別のｔａｒ．ｇｚファイルを含んでいる。さらに、ステップ５３５で、ｔａｒ．ｇｚファイルをプラグイン１０５によってハードディスクに保存してもよい。
【0231】
図２５は、本発明の一実施形態による、船舶の遠隔機器監視のための方法６００のステップを示す概略図である。
【0232】
ステップ６０１において、舶用電子機器１０７からのメッセージが機器診断装置１０３によって受信される。各メッセージは、船舶１０１上の１又は複数の舶用電子機器１０７を識別するための識別データと、機器診断装置１０３と舶用電子機器１０７との間で通信を行うための警報状態データとを含んでいる。さらに、各メッセージは船舶１０１上の舶用電子機器１０７の故障を示すＮＭＥＡ０１８３メッセージを含んでいる。さらに、各メッセージを解析して識別データ及び警報状態データを取得することができる。
【0233】
ステップ６０３において、識別データ及び警報状態データに基づいて、舶用電子機器１０７の故障が判定され得る。図１１に示されるメッセージ３００ｃは、識別データ及び警報状態データを指定する複数のフィールドを含む例示的なメッセージである。
【0234】
そのために、方法６００は第１のトリガー及び第２のトリガーを実行する。第１のトリガーは、舶用電子機器１０７から１又はそれ以上のメッセージを受信するためのバックグラウンドプロセスとして常に動作する。１つ以上のメッセージからの各メッセージは警報状態データを含んでいる。さらに、第１のトリガーは警報状態データを用いて現在の警報状態と以前の警報状態との比較に基づいてメッセージを処理する。第２のトリガーは舶用電子機器１０７からメッセージを受信するように、予定された時間間隔で動作する。第２のトリガーはメッセージを処理して、最後に（直近に）予定されたタイムスタンプと現在の予定されたタイムスタンプの間で警報状態データに変更があるかどうかをチェックする。
【0235】
ステップ６０５では、第１のトリガー及び第２のトリガーによるメッセージの処理に基づいて、舶用電子機器１０７の故障に関連する情報を含むメッセージを遠隔機器監視センター１１３に送信する。従って、方法６００は、一つ以上の舶用電子機器１０７の故障が発生した場合にのみ関連情報のみを遠隔機器監視センター１１３に送信し、これにより資源の有効利用が確保される。
【0236】
従って、本発明の一実施形態は、機器診断装置１０３を使用して、船舶にある舶用電子機器１０７の遠隔機器監視を提供することができる。機器診断装置１０３は舶用電子機器１０７と通信しており、さらに、第１の衛星通信リンクを介して遠隔機器監視センター１１３に直接的に接続されている。直接的な通信は、船舶１０１における舶用電子機器１０７の故障に関連する正確なリアルタイム情報を提供し、これにより、遠隔機器監視センターは舶用電子機器の故障の原因を効果的に判定し、それに応じて対応する正確なトラブルシューティング指示を提供することができる。さらに、直接的な通信は、１又は複数の舶用電子機器１０７の障害のトラブルシューティングに必要な時間を短縮する可能性のある障害点を排除する。従って、本一実施形態によれば、船舶における１つ以上の装置の遠隔機器監視のための改善された方法をもたらす。
【0237】
以上説明した実施形態は、例示の目的で本明細書に記載されており、多くのバリエーションに従う。本発明の思想或いは範囲から逸脱することなく、適用又は実施をカバーすることを意図した、種々の省略及び同等物の置換が考えられる。さらに、ここで使用される用語及び用語は説明の目的のためのものであり、限定的なものとみなすべきではないことは理解され得る。この説明の中で使用される見出しは、便宜のためだけのものであり、法的又は限定的な効果はない。
【0238】
本明細書及び特許請求の範囲において使用されるように、用語「例えば。」、並びに動詞「含む」、「有する」、「含む」、及びそれらの他の動詞形態は、１又は複数の構成要素又は他の項目のリストと併せて使用される場合、それぞれ、オープンエンドと解釈されるべきであり、これは、リストが他の追加の構成要素又は項目を除外するものとみなされるべきではないことを意味する。他の用語は、異なる解釈を必要とする文脈において使用されない限り、最も広い合理的な意味を用いて解釈されるべきである。
【0239】
遠隔機器監視及び支援システムのために提案されたハイブリッドアーキテクチャは、船主及び船舶管理会社に、船舶上のあらゆる種類の電子機器への直接アクセス及び制御を提供する。ハイブリッドアーキテクチャにより、遠隔機器監視及び支援システムは、船舶上に配置されたスマートデバイスを介して船舶に関する重要なデータを収集することができる。データはクラウドデータベースに転送されて保存され、ウェブポータルを通じて利用可能になる。
【0240】
船舶に搭載された電子機器の状態は陸上の遠隔機器監視センターで常時監視されており、異常が発生した場合には速やかに故障原因を分析し、修理の手配を行います。ハイブリッドアーキテクチャは、船内の電子機器をスマートデバイスに接続するモノのインターネット（ＩｏＴ）と、電子機器の遠隔機器監視を可能にするウェブポータルにスマートデバイスをベースにしている。
【0241】
しかしながら、電子機器の効率的な遠隔機器監視を実施し、遠隔機器監視センターからリクエストされたときに正確なトラブルシューティング指示をより短時間で得るために、スマートデバイスは、遠隔機器監視センターと直接通信する必要がある。さらに、スマートデバイスは、関連する情報のみを遠隔機器監視センターに送信できる必要がある。これにより、スマートデバイスと遠隔機器監視センター間の衛星通信に提供される帯域幅をタイムリーにトラブルシューティングし、有効に利用することができる。
【0242】
本明細書に記載される本発明の多くの変更及び他の実施形態は、これらの発明が関係する当業者には、上記の説明及び関連する図面に示される教示の利益を有することが思い付くであろう。従って、本発明は開示された特定の実施形態に限定されるものではなく、修正及び他の実施形態が添付の特許請求の範囲に含まれることが意図されていることが理解されるべきである。
【0243】
さらに、上述の説明及び関連する図面は、要素及び／又は機能の特定の例示的な組み合わせに関連して本発明の一実施形態を説明しているが、要素及び／又は機能の異なる組み合わせが、添付の特許請求の範囲の範囲から逸脱することなく、代替の実施形態によって提供され得ることを理解されたい。この点に関して、例えば、上述したものとは異なる要素及び／又は機能、ツール、ソフトウェア、及びサービスの組み合わせもまた、添付の特許請求の範囲のいくつかに記載され得るように企図される。本明細書では特定の用語を使用するが、それらは、限定の目的ではなく、一般的かつ記述的な意味でのみ使用される。
【符号の説明】
【0244】
１００ ハイブリッドアーキテクチャ
１０１ 船舶（移動体）
１０３ 機器診断装置
１０５ プラグイン
１０７ 舶用電子機器（電子機器）
１０７ａ―１０７ｎ 舶用電子機器
１０９ データベース
１１１ ゲートウェイデバイス
１１３ 遠隔機器監視センター
１１５ ＩｏＴポータル
１１７ ＤＷワークベンチ
１１９ ＤＷコア
１２１ ＤＷゲートウェイ
１２３ 受信部
１２５ 検出部
１２７ 送信部
１２９ ＩｏＴハブ
１３１ イベントハブ
１３３ ファンクション部
１３５ コスモスデータベース
１３７ 構成管理データベース（ＣＭＤＢ）
１４１ アプリケーションゲートウェイ
２０１ ＭＱＴＴフロントエンド
２０３ 接続性管理部
２０５ デバイス管理部
２０７ ＩｏＴ管理ポータル
２０９ ＩｏＴプラットフォームＭ２ＭサービスＡＰＩ
３０１ａ―ｎ 通信衛星
１０１ 船舶（移動体）
１０３ 機器診断装置
１０５ プラグイン
１０７ 舶用電子機器（電子機器）
１０７ａ―１０７ｎ 舶用電子機器
１０９ データベース
１１１ ゲートウェイデバイス
１１３ 遠隔機器監視センター
１１５ ＩｏＴポータル
１１７ ＤＷワークベンチ
１１９ ＤＷコア
１２１ ＤＷゲートウェイ
１２３ 受信部
１２５ 検出部
１２７ 送信部
１２９ ＩｏＴハブ
１３１ イベントハブ
１３３ ファンクション部
１３５ コスモスデータベース
１３７ 構成管理データベース（ＣＭＤＢ）
１４１ アプリケーションゲートウェイ
２０１ ＭＱＴＴフロントエンド
２０３ 接続性管理部
２０５ デバイス管理部
２０７ ＩｏＴ管理ポータル
２０９ ＩｏＴプラットフォームＭ２ＭサービスＡＰＩ
３０１ａ―ｎ 通信衛星
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】