JP5421398B2 - 船舶安全管理システム - Google Patents
船舶安全管理システム Download PDFInfo
- Publication number
- JP5421398B2 JP5421398B2 JP2012008729A JP2012008729A JP5421398B2 JP 5421398 B2 JP5421398 B2 JP 5421398B2 JP 2012008729 A JP2012008729 A JP 2012008729A JP 2012008729 A JP2012008729 A JP 2012008729A JP 5421398 B2 JP5421398 B2 JP 5421398B2
- Authority
- JP
- Japan
- Prior art keywords
- notification
- record
- ship
- status
- warning
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Traffic Control Systems (AREA)
Description
本発明は、船舶運航管理技術の技術分野に属する発明である。
船舶運航管理技術とは、船舶の自動識別システム(Automatic Identification System:AIS)を船舶に搭載することにより、地上側のシステムから船舶の行動を随時把握する技術である。AISを用いた船舶運航管理技術では、位置、船名、針路、速力、目的地が船舶のAISから送信されるので、これらのデータを画面上に表示させることで目視による船舶の行動認定が可能になる。このようなAISを用いた船舶運航管理技術が導入されている背景には、船舶の衝突、座礁、沈没による当事者損害、第３者損害が深刻視されている状況がある。"当事者損害"とは、船舶の爆発や火災により人命、船舶、貨物に損害が発生することである。"第３者損害"とは、貨物流出により海洋汚染が発生することである。
このような社会背景において、船舶の運航基準は厳格化する傾向にあり、近年では支配下船舶の安全航行に関する管理規定が新たに法制化されている。具体的にいうと、経営トップ、安全統括管理者、運航管理者は、船舶の安全運航に関る情報を入手し、運航基準に従い、運航の可否判断を行う等の責任を有することが新しい法定基準として明文化されることになっている。これは船舶の安全航行及び事故防止を実現するためである。
上述したように、厳格化された法定基準において、船舶の安全運航に関る情報を入手し、運航基準に従い、運航の可否判断を行う等の責任を有していることから、安全統括管理者、運航管理者は、全支配下船舶の動静を把握し、尚且つ、各船舶が置かれている状況と今後遭遇が想定される状況変化を常時認定する必要がある。しかし、昼夜平日祝休日を問わず、船舶の状況や気象、海象を常時認定する勤務体制をとるのは人員体制の面で不可能な面が多い。
たとえ企業側が充分な人員体制を引いていたとしても、いざ、海難事件が発生した場合、海難事件の審判廷や法廷において上述したような法定基準を遵守していたという事実を立証するのは困難である。法定基準を遵守していたという事実立証の困難性は、運航に携わる企業の経営基盤を危うくするものであり、海難事故についての何等かのリスクヘッジが産業界から渇望されている現状にある。
ここで、特許文献１に記載された先行技術に従い、船舶に対する情報提供を行うことが考えられる。つまり、運航管理センタにおいて、複数の基地局からの到来角度に基づき船舶の航行位置、更に速度、方向、沿岸からの距離を算出して運航監視を行う。そして、海況情報により悪天候である運航海域内に船舶が存在する場合、船舶の船上ユーザが所持している携帯電話に対して警報を送出するのである。しかし、悪天候である運航海域の船舶に警報を発したとしても、その警報の内容を確認したかどうかの履歴は残らないし、また、地上の安全統括管理者、運航管理者である地上ユーザがどのように対処したかについても、履歴が残ることはない。従って、上記警報の発令後に海難事故が発生した場合、企業側は、上記運航基準を遵守していたことを充分主張することができないという問題は依然として残る。
本発明の目的は、海難事件が発生した場合、法定基準を遵守していたという事実の立証を容易にすることができ、船舶の安全航行及び事故防止を実現することができるシステムを提供することである。
上記課題を解決するため、本発明にかかる船舶安全管理システムは、
船舶の位置を取得する取得手段と、
海象又は気象についての警報発令を示す情報を受信する受信手段と、
警報時の運航経過を示すログを用いることで、船舶の動態管理を行う管理手段と、
船舶の運航に関与する船上ユーザ、及び、地上ユーザとの通信を行う通信手段とを備え、
前記通信手段は、
海象又は気象についての警報が発令され、尚且つ、管理対象となる船舶の中に警報発令海域を現在位置とするものが存在する場合、当該船舶の運航に関与する船上ユーザ及び地上ユーザに警報発令を通知すると共に、警報発令通知に対する確認応答を船上ユーザ及び地上ユーザから受信し、
前記管理手段は、
当該警報発令の通知がなされた日時、及び、警報発令通知に対する確認応答がなされた日時を運航ログに登録する
ことを特徴としている。
船舶の位置を取得する取得手段と、
海象又は気象についての警報発令を示す情報を受信する受信手段と、
警報時の運航経過を示すログを用いることで、船舶の動態管理を行う管理手段と、
船舶の運航に関与する船上ユーザ、及び、地上ユーザとの通信を行う通信手段とを備え、
前記通信手段は、
海象又は気象についての警報が発令され、尚且つ、管理対象となる船舶の中に警報発令海域を現在位置とするものが存在する場合、当該船舶の運航に関与する船上ユーザ及び地上ユーザに警報発令を通知すると共に、警報発令通知に対する確認応答を船上ユーザ及び地上ユーザから受信し、
前記管理手段は、
当該警報発令の通知がなされた日時、及び、警報発令通知に対する確認応答がなされた日時を運航ログに登録する
ことを特徴としている。
何れかの海域に海象又は気象についての警報が発令された場合、その警報発令海域に存在する船舶の管理として、船上ユーザ及び地上ユーザに対する警報発令通知が完了したか否か、船上ユーザ及び地上ユーザによる通知内容の確認が完了したか否かが運航ログに残るから、ある船舶が遭遇した警報発令に関する事象のそれぞれについて、状態管理のログをシステム内に残すことができる。万が一、何れかの船舶に海難事故が発生したとしても、運航管理者が法定基準を遵守していたことの後日の立証が容易になり、海難事故について強固なリスクヘッジを実現することができる。また、船上ユーザに対する連絡が完了したか否か、地上ユーザによる連絡内容の確認が完了したか否かという状態管理のログがシステムに残ることから法定基準を遵守しようというモチベーションを高めることができ、海難事故の発生数を極力少なくすることができる。
かかる課題解決手段を具備したシステムの発明は、本願の特許請求の範囲における第１項の請求項に記載されている。ここで、このシステムの発明に、別の発明特定事項を追加したり、また、このシステムの発明の発明特定事項を上位概念のものから下位概念のものに置き換えることで、上記再生装置の発明に、更なる効果を奏させることができる。これら、発明特定事項の追加、発明特定事項の下位概念化のバリエーションには以下のものがあり、これらのバリエーションは、請求項２以下の従属請求項に区分けして記載されている。
任意的であるが、警報発令時の運航経過を示すログは、通知状態レコードと、通知状態明細レコードとを用いて表現され、
前記通知状態レコードは、管理下にある船舶に対してどのような通知がなされたかを示すと共に、船上ユーザによる当該通知に対する確認状態のためのフィールドを有するテーブルであり、当該フィールドは初期値として確認待ちを示す値に設定され、
前記通知状態明細レコードは、通知状態レコードに示される通知に対する地上ユーザによる確認状態歴のためのフィールドを有するテーブルであり、当該フィールドは初期値として確認待ちを示す値に設定され、
前記船上ユーザによる確認状態の遷移は、警報発令通知に対する船上ユーザからの確認応答の受信時において通知状態レコードにおけるフィールドの値を更新して、確認済み状態を示させることでなされ、
前記地上ユーザによる確認状態の遷移は、警報発令通知に対する地上ユーザからの確認応答の受信時において、通知状態レコードにおけるフィールドの値を更新して、確認済み状態を示させることでなされ
前記安全管理システムは、通知状態レコード、通知状態明細レコードを対象にしたサーチエンジンを備え、サーチエンジンは、ユーザからのキーワード入力を受け付けて、データベースに記憶されている複数の通知状態レコード、複数の通知状態明細レコードのうち、入力されたキーワードに合致するものを探し出し、キーワードに合致する通知状態レコード及び通知状態明細レコードを一覧表示に供してもよい。
前記通知状態レコードは、管理下にある船舶に対してどのような通知がなされたかを示すと共に、船上ユーザによる当該通知に対する確認状態のためのフィールドを有するテーブルであり、当該フィールドは初期値として確認待ちを示す値に設定され、
前記通知状態明細レコードは、通知状態レコードに示される通知に対する地上ユーザによる確認状態歴のためのフィールドを有するテーブルであり、当該フィールドは初期値として確認待ちを示す値に設定され、
前記船上ユーザによる確認状態の遷移は、警報発令通知に対する船上ユーザからの確認応答の受信時において通知状態レコードにおけるフィールドの値を更新して、確認済み状態を示させることでなされ、
前記地上ユーザによる確認状態の遷移は、警報発令通知に対する地上ユーザからの確認応答の受信時において、通知状態レコードにおけるフィールドの値を更新して、確認済み状態を示させることでなされ
前記安全管理システムは、通知状態レコード、通知状態明細レコードを対象にしたサーチエンジンを備え、サーチエンジンは、ユーザからのキーワード入力を受け付けて、データベースに記憶されている複数の通知状態レコード、複数の通知状態明細レコードのうち、入力されたキーワードに合致するものを探し出し、キーワードに合致する通知状態レコード及び通知状態明細レコードを一覧表示に供してもよい。
サーチエンジンが受け付け可能なキーワードとして、ユーザ名、船舶、領域、日付があり、また一覧表示の指定として、昇順指定、降順指定も可能である場合、これら通知状態レコード、通知状態明細レコードにおける項目を、ユーザがサーチエンジンに設定した条件でソートして表示に供することができる。様々な態様で、警報時の運航経過のログを作成することができるから、万が一、海難事故が発生したとしても、その要求に応じた証拠資料を、迅速に作成することができる。
任意的であるが、前記データベースは、複数の気象状態レコードと、複数の通知条件データとを含み、
各気象状態レコードは、ある船舶が属する領域の気象状態を示すデータであり、その気象状態を通知するための通知分類を含み、
各通知条件データは、ユーザに対する通知の条件付けを規定するデータであり、条件付けは、通知がどのような類型に属するかを示す通知分類と、通知がどのような内容であるかを示す通知内容とによって規定され、
何れかの船舶から取得した最新の位置情報の船舶コードが何れかの通知条件テーブルに設定されており、その通知条件テーブルに、発令内容が通知条件として設定されている場合、その警報と同一の警報内容を示す気象状態レコードをデータベースから探し出して、この気象状態レコードに対応する通知状態レコード、通知状態明細レコードを作成してもよい。
各気象状態レコードは、ある船舶が属する領域の気象状態を示すデータであり、その気象状態を通知するための通知分類を含み、
各通知条件データは、ユーザに対する通知の条件付けを規定するデータであり、条件付けは、通知がどのような類型に属するかを示す通知分類と、通知がどのような内容であるかを示す通知内容とによって規定され、
何れかの船舶から取得した最新の位置情報の船舶コードが何れかの通知条件テーブルに設定されており、その通知条件テーブルに、発令内容が通知条件として設定されている場合、その警報と同一の警報内容を示す気象状態レコードをデータベースから探し出して、この気象状態レコードに対応する通知状態レコード、通知状態明細レコードを作成してもよい。
通知状態レコードのうち、どのような内容の警報、注意報を地上ユーザ、船上ユーザに対する通知の対象にするかを通知条件テーブルにて規定することができるので、船上ユーザ−、地上ユーザに対する通知の内容種別を絞ることができる。通知条件テーブルを用いた条件付けにより、地上ユーザ、船上ユーザに対する通知は、気象、海象に関する警報、注意報のうちシステム運営者が特に選んだ特定のものに絞られることになるから、警報通知が高頻度になされることによる作業効率低下を抑制することができる。
任意的であるが、前記管理手段は、船舶の識別子を用いてデータベースにおけるマスタレコードを検索することで、船舶を管理するワークグループと、そのグループ配下のユーザとを探し出して、探し出されたユーザについての情報を、通知状態レコードと対応付けることにより、通知状態明細レコードを作成し、また探し出されたユーザのアドレスをマスタレコードから取得し、
前記通信手段は、マスタレコードから取得したアドレスを宛て先として、メール又はメッセージを送信することで警報発令の通知を行ってもよい。
前記通信手段は、マスタレコードから取得したアドレスを宛て先として、メール又はメッセージを送信することで警報発令の通知を行ってもよい。
管理対象となる船舶の船舶コードを用いて船舶を管理する配船担当者、運航管理者等のデータベースの検索を行い、地上ユーザ、船上ユーザを特定するので、既存のデータベースの延長線上で、警報時の経過を示すログを作成することができ、体系的なデータベース構築を実現することができる。
任意的であるが、前記データベースには、 警報通知に応じて作成された気象状態レコードに示される警報の区分が発令データであるか、更新データであるか、解除データであるかを判定して、
警報通知に応じて作成された気象状態レコードが発令データであれば、全ての警報を通知するための通知条件データを探し出すための検索を実行して、探し出された通知条件テーブルに基づき通知状態レコードを作成し、
警報の受信に応じて作成された気象状態レコードが更新データであれば、この通知状態レコードに示される警報内容のうち、増減が発生したものを通知するための通知条件データを探し出すための検索を実行して、探し出された通知条件テーブルに基づき通知状態レコードを作成し、
警報の受信に応じて作成された気象状態レコードが解除データであれば、この通知状態レコードに示される警報内容のうち、減少が発生したものを通知するための通知条件データを対象として、解除データと一致する通知内容を有する通知条件データを探し出すための検索を実行して、探し出された通知条件テーブルに基づき通知状態レコードを作成してもよい。
任意的であるが、前記データベースには、 警報通知に応じて作成された気象状態レコードに示される警報の区分が発令データであるか、更新データであるか、解除データであるかを判定して、
警報通知に応じて作成された気象状態レコードが発令データであれば、全ての警報を通知するための通知条件データを探し出すための検索を実行して、探し出された通知条件テーブルに基づき通知状態レコードを作成し、
警報の受信に応じて作成された気象状態レコードが更新データであれば、この通知状態レコードに示される警報内容のうち、増減が発生したものを通知するための通知条件データを探し出すための検索を実行して、探し出された通知条件テーブルに基づき通知状態レコードを作成し、
警報の受信に応じて作成された気象状態レコードが解除データであれば、この通知状態レコードに示される警報内容のうち、減少が発生したものを通知するための通知条件データを対象として、解除データと一致する通知内容を有する通知条件データを探し出すための検索を実行して、探し出された通知条件テーブルに基づき通知状態レコードを作成してもよい。
警報の通知が警報、更新、解除の何れであるかを判定し、増加／減少がなされた通知内容についてのみ通知条件テーブルに対する検索を実行するので、重複通知の発生を回避することができる。重複通知を排除して前の通知からの差分についてのみ通知状態レコードが作成されることになるから、地上ユーザ、船上ユーザによる警報確認の頻度を抑制することができ、業務効率の低下を避けることができる。
任意的であるが、前記管理下にある船舶から位置情報を取得した際、位置情報の取得日時と、現在日時との差分を所定の時間差と比較して、所定の時間差を上回れば、直前の位置情報の取得日時から所定の時間が経過した時点の通知状態レコードとして通信状態が"ロスト"に設定された船舶状態レコードを作成し、その後、船舶側で滞留していた位置情報を受信して、滞留していた位置情報のそれぞれについて、通信状態を"ロスト期間中"とした通知状態レコードを作成し、
前記サーチエンジンにおいては、
"ロスト"又は"ロスト期間中"を示す通信状態が設定された通知状態レコードを一覧表示に供することを特徴にしてもよい。
前記サーチエンジンにおいては、
"ロスト"又は"ロスト期間中"を示す通信状態が設定された通知状態レコードを一覧表示に供することを特徴にしてもよい。
上記発明によれば、船舶において通信不通期間が発生した場合、その期間経過後の位置情報取得時に、船舶側で送信を滞留していた位置情報をデータベースに記録し、これらの滞留分の位置情報については、通信状態をロスト期間中とした船舶状態レコードを作成するので、通信不通期間において、船舶がどういう航路をとったかを明確に把握することができる。
船舶のロスト状態を加味した動的管理を行うには、NTT-docomo（登録商標）等により提供される船舶電話を導入することも考えられるが、船舶電話は導入コストが高く、また常時接続が要求されるため運用コストの問題が顕著化する。これに対して上記限定事項が追加された本発明では、安価で汎用性が高い携帯電話により船舶の動態管理を実現するので、低コストでの動的管理を実現することができる。これにより海運業界にもたらす恩恵は大きい。
(第１実施形態)
以降、図面を参照しながら船舶安全管理システムの実施形態について説明する。以降の説明は、「ＸＸ.ＹＹ.ＺＺ」という形式の章番号を用いた章分け記載を採用する。上記章番号の大きな分類「ＸＸ」は、説明に参照すべき図面の図番号に対応している。小さな分類「ＹＹ」「ＺＺ」は、説明に参照すべき図面中の参照符号や、説明の順序に対応している。
以降、図面を参照しながら船舶安全管理システムの実施形態について説明する。以降の説明は、「ＸＸ.ＹＹ.ＺＺ」という形式の章番号を用いた章分け記載を採用する。上記章番号の大きな分類「ＸＸ」は、説明に参照すべき図面の図番号に対応している。小さな分類「ＹＹ」「ＺＺ」は、説明に参照すべき図面中の参照符号や、説明の順序に対応している。
１.システムの全体構成
図１は、船舶安全管理システムの内部構成と、本システムに関連するシステム外サーバとを描いた図である。
船舶安全管理システムは、運送依頼をどの船舶に割り当てるかという配船処理を実行すると共に、その配船がなされた船舶の運航を動的に管理するものである。船舶安全管理システムは、事業所における地上ユーザによる操作に供され、事業所に設置された大型ディスプレイを通じて運送依頼をどの船舶に割り当てるかという配船表を多数の職員に閲覧させることができる。本実施形態では、地上ユーザとして配船担当者、運航管理者、船主他関係者を例示している。
図１は、船舶安全管理システムの内部構成と、本システムに関連するシステム外サーバとを描いた図である。
船舶安全管理システムは、運送依頼をどの船舶に割り当てるかという配船処理を実行すると共に、その配船がなされた船舶の運航を動的に管理するものである。船舶安全管理システムは、事業所における地上ユーザによる操作に供され、事業所に設置された大型ディスプレイを通じて運送依頼をどの船舶に割り当てるかという配船表を多数の職員に閲覧させることができる。本実施形態では、地上ユーザとして配船担当者、運航管理者、船主他関係者を例示している。
船舶安全管理システムは、構内ネットワークを通じて接続された複数のクライアント装置、サーバ装置から構成される典型的なサーバ・クライアントシステムであり、AIS設備を搭載した社船の他、AIS設備を搭載していない定期用船の動態管理を行う。クライアントには、地上クライアント装置１と、携帯端末２と、船上クライアント装置３とがある。サーバ装置とは、構内ネットワークに存在するシステム内サーバのことである。この他、図１には、本システムに関連するシステム外サーバとして気象協会サーバ１０、AISサーバ１１を描いている。
１.２ 携帯端末２
携帯端末２は、船舶一覧、個別船舶状況表示、現在地表示を実現する。メールやメッセージを通じて、警報発令や警報内容の更新、警報解除の通知を受けることができる。更に、これらのメール、メッセージについての応答を送信することにより、警報通知に対する確認応答をすることができる。
携帯端末２は、船舶一覧、個別船舶状況表示、現在地表示を実現する。メールやメッセージを通じて、警報発令や警報内容の更新、警報解除の通知を受けることができる。更に、これらのメール、メッセージについての応答を送信することにより、警報通知に対する確認応答をすることができる。
１.３ 船上クライアント装置３
船上クライアント装置３は、船舶上に設置されたパーソナルコンピュータであり、データベースにおける更新済みスクリプトを実行することでデータセットの取得を行う。船上クライアント装置１が通常のクライアント装置と異なるのはAISトランスポンダと接続されている点である。より詳しくいうと、この船上クライアント装置には、VHFアンテナ、GPSアンテナ、運航計器、AIS表示パーソナルコンピュータ、レ−ダがAISトランスポンダを介して接続されていて、船上クライアント装置１は、これらを通じて自船舶の位置を特定する緯度、経度、海領域を取得することができる。そして取得した位置を示す位置情報を船舶外部に送信することもできる。この位置情報の自動発信は、例えば５分間隔でなされる。通信可能エリアは、携帯電話会社のサービスエリアである。通信不能エリアでは、船舶パーソナルコンピュータにデータを蓄積し、通信可能になった際にサーバに送信する。注意喚起がなされた場合、船長、機関士は、船内警戒行動をとる。対濃霧の船内警戒行動としては、船長当直、目視・レーダー監視、AIS監視の強化、減速航行がある。対風系の船内警戒行動としては、避難判断がある。
船上クライアント装置３は、船舶上に設置されたパーソナルコンピュータであり、データベースにおける更新済みスクリプトを実行することでデータセットの取得を行う。船上クライアント装置１が通常のクライアント装置と異なるのはAISトランスポンダと接続されている点である。より詳しくいうと、この船上クライアント装置には、VHFアンテナ、GPSアンテナ、運航計器、AIS表示パーソナルコンピュータ、レ−ダがAISトランスポンダを介して接続されていて、船上クライアント装置１は、これらを通じて自船舶の位置を特定する緯度、経度、海領域を取得することができる。そして取得した位置を示す位置情報を船舶外部に送信することもできる。この位置情報の自動発信は、例えば５分間隔でなされる。通信可能エリアは、携帯電話会社のサービスエリアである。通信不能エリアでは、船舶パーソナルコンピュータにデータを蓄積し、通信可能になった際にサーバに送信する。注意喚起がなされた場合、船長、機関士は、船内警戒行動をとる。対濃霧の船内警戒行動としては、船長当直、目視・レーダー監視、AIS監視の強化、減速航行がある。対風系の船内警戒行動としては、避難判断がある。
AIS情報の送信は、無線LANカードを通じてなされる。ここでは、位置、船名、針路、速力、目的地を含むAIS情報が自動定時送信の対象になる。船上クライアント装置３は、自船が警報発令海域に存在すると通知された場合、アラーム音を鳴動する。このアラーム音の鳴動は、船上ユーザが警報受信操作をするまで継続する。船上ユーザが警報受信操作を行えば、当該鳴動は停止する。以上がクライアントについての説明である。続いて、システム内サーバの詳細について説明する。システム内サーバには、WEBサーバ４、アプリケーションサーバ５、データベースサーバ６、WEBサーバ７がある。
１.４ WEBサーバ４
WEBサーバ４は、システムの管理対象となる領域についての警報電文を受信して、その警報電文に含まれる海域に存在する船舶が探し出された場合、リレーショナルデータベースをサーチして、その船舶の運航に関連する地上ユーザを特定する。そうして特定した地上ユーザ各人を宛て先とするメールを作成する。こうして作成される１通のメールで、地上ユーザは管理担当になっている船舶のうち、どれが警報発令海域に存在するかを知得することができる。その応答メールが地上ユーザから送信されれば、これを受信する。
WEBサーバ４は、システムの管理対象となる領域についての警報電文を受信して、その警報電文に含まれる海域に存在する船舶が探し出された場合、リレーショナルデータベースをサーチして、その船舶の運航に関連する地上ユーザを特定する。そうして特定した地上ユーザ各人を宛て先とするメールを作成する。こうして作成される１通のメールで、地上ユーザは管理担当になっている船舶のうち、どれが警報発令海域に存在するかを知得することができる。その応答メールが地上ユーザから送信されれば、これを受信する。
１.５ データベースサーバ５
データベースサーバ５は、データベースの保存／読出し／書込みを行う。AIS情報の物理ファイルの蓄積はアプリケーションサーバ６で行われる。AIS情報のデータ蓄積は、データベースサーバ５で行われる。AIS情報の物理ファイル転送は、船舶クライアントPC３からアプリケーションサーバ６に対してのみ行われる。
データベースサーバ５は、データベースの保存／読出し／書込みを行う。AIS情報の物理ファイルの蓄積はアプリケーションサーバ６で行われる。AIS情報のデータ蓄積は、データベースサーバ５で行われる。AIS情報の物理ファイル転送は、船舶クライアントPC３からアプリケーションサーバ６に対してのみ行われる。
１.６ アプリケーションサーバ６
アプリケーションサーバ６は、FTPを通じてクライアントからAIS情報を受け取り蓄積する。こうして蓄積したAIS情報をシステム内サーバに転送する。船上クライアント装置３へのファイル転送は、システム内サーバにおけるFTPクラスのプロパティによって規定される。船舶から自動送信されるAIS情報の受信時、及び、警報電文の受信時において、この受信に伴うデータ処理を実行する。また、警報発令情報の自動受信・蓄積を行う際、船舶位置情報と、警報電文とのマッチングを行い、警報発令海域の船舶に対して自動情報発信を行い、船上ユーザの確認状態区分を、送信待ちから確認待ちへと変化させる。内容確認がなされれば、確認待ち状態から確認済み状態に変化する。地上ユーザが確認したことの自動登録がなされれば、地上ユーザの確認状態区分を未確認状態から確認済み状態に遷移させる。サーバは、AIS情報、警報電文を受信する度に、AIS情報受信といったトランザクション、警報発令といったトランザクションに関連するデータ処理を実行する。AIS情報の受信時においては、AIS情報に示される位置を船舶の現在位置とするレコードをデータベースに追加する。
アプリケーションサーバ６は、FTPを通じてクライアントからAIS情報を受け取り蓄積する。こうして蓄積したAIS情報をシステム内サーバに転送する。船上クライアント装置３へのファイル転送は、システム内サーバにおけるFTPクラスのプロパティによって規定される。船舶から自動送信されるAIS情報の受信時、及び、警報電文の受信時において、この受信に伴うデータ処理を実行する。また、警報発令情報の自動受信・蓄積を行う際、船舶位置情報と、警報電文とのマッチングを行い、警報発令海域の船舶に対して自動情報発信を行い、船上ユーザの確認状態区分を、送信待ちから確認待ちへと変化させる。内容確認がなされれば、確認待ち状態から確認済み状態に変化する。地上ユーザが確認したことの自動登録がなされれば、地上ユーザの確認状態区分を未確認状態から確認済み状態に遷移させる。サーバは、AIS情報、警報電文を受信する度に、AIS情報受信といったトランザクション、警報発令といったトランザクションに関連するデータ処理を実行する。AIS情報の受信時においては、AIS情報に示される位置を船舶の現在位置とするレコードをデータベースに追加する。
警報電文の受信時においては、現在位置の管理がなされている船舶の中に、警報電文に含まれる海域コードの海域に存在するものが存在するか否かを判定して、存在する場合、警報発令というトランザクションに関連するレコードをデータベースに追加する。併せてこの警報発令というトランザクションに関連するデータ処理を実行する。こうすることで、後日の警報発令時における運航経過の追跡が容易になる。
１.７ WEBサーバ７
WEBサーバ７は、日本気象協会のサーバから自動送信される警報電文を受信する。以上がシステム内サーバについての説明である。続いて、システム外サーバについて説明する。システム外サーバには、気象協会サーバ１０、AIS情報サーバ１１がある。以上がシステム外サーバについて説明する。
WEBサーバ７は、日本気象協会のサーバから自動送信される警報電文を受信する。以上がシステム内サーバについての説明である。続いて、システム外サーバについて説明する。システム外サーバには、気象協会サーバ１０、AIS情報サーバ１１がある。以上がシステム外サーバについて説明する。
１.１０ 気象協会サーバ１０
気象協会サーバ１０は、警報電文の自動発信を行う。警報の種類としては、一般警報(風、霧、氷)、強風警報(強)、暴風警報(暴)、台風警報(台)、うねり警報(う)、警報なし(無)がある。上記の括弧書きは、メールで警報発令を通知する際の略称であり、"霧"は濃霧、"氷"は着氷、"強"は強風警報、"暴"は暴風警報、"台"は台風警報、"う"はうねり警報、"無"は無し又は解除を示す。警報電文の自動発信は、６時間間隔、２４時間間隔でなされる。警報発令海域は、気象庁の地方海上予報区の細分海域であり、３７海域に区分されているものをいう。サーバからユーザへの随時臨時警報は、１５分間隔、２４時間間隔でなされる。
気象協会サーバ１０は、警報電文の自動発信を行う。警報の種類としては、一般警報(風、霧、氷)、強風警報(強)、暴風警報(暴)、台風警報(台)、うねり警報(う)、警報なし(無)がある。上記の括弧書きは、メールで警報発令を通知する際の略称であり、"霧"は濃霧、"氷"は着氷、"強"は強風警報、"暴"は暴風警報、"台"は台風警報、"う"はうねり警報、"無"は無し又は解除を示す。警報電文の自動発信は、６時間間隔、２４時間間隔でなされる。警報発令海域は、気象庁の地方海上予報区の細分海域であり、３７海域に区分されているものをいう。サーバからユーザへの随時臨時警報は、１５分間隔、２４時間間隔でなされる。
２.システムでなされる処理の解説
図２は、図１のシステム構成図をベースにして、このベースとなるシステム構成図に、1)、2)、3)、4-1)、4-2)、5)、5-1),5ー2)の処理の解説を書き加えたものである。
1)は、AIS情報の送信が船上クライアント装置２によってなされることを解説するものである。
図２は、図１のシステム構成図をベースにして、このベースとなるシステム構成図に、1)、2)、3)、4-1)、4-2)、5)、5-1),5ー2)の処理の解説を書き加えたものである。
1)は、AIS情報の送信が船上クライアント装置２によってなされることを解説するものである。
2)は、地方海上警報電文の自動送信が気象協会サーバ１０によってなされることを解説するものである。
3)は、AIS情報に示される位置情報と、警報電文とのマッチングがデータベースサーバ６によってなされることを解説するものである。
4-1)は、警報注意報発令海域の船舶に対する船上ユーザへの通知がWEBサーバ４によってなされることを解説するものである。
3)は、AIS情報に示される位置情報と、警報電文とのマッチングがデータベースサーバ６によってなされることを解説するものである。
4-1)は、警報注意報発令海域の船舶に対する船上ユーザへの通知がWEBサーバ４によってなされることを解説するものである。
4-2)は、地上ユーザへの警報注意報発令の通知がWEBサーバ４によってなされることを解説するものである。
5)は、警報受信操作をするまでのPCアラームの継続鳴動を示す。
5-1)は、船上ユーザからの確認応答に起因する確認状態区分変化(確認待ち→確認済み)がデータベースサーバ６によってなされることを解説するものである。
5)は、警報受信操作をするまでのPCアラームの継続鳴動を示す。
5-1)は、船上ユーザからの確認応答に起因する確認状態区分変化(確認待ち→確認済み)がデータベースサーバ６によってなされることを解説するものである。
5-2)は、地上ユーザからの確認応答に起因する確認状態区分変化(確認待ち→確認済み)がデータベースサーバ６によってなされることを解説するものである。
３.本システムでなされる業務内容
以下、本システムを用いた業務内容について説明する。本システムを用いた業務内容には、日々配船業務と、気象警報発令時業務と、安全管理業務とがある。
３.本システムでなされる業務内容
以下、本システムを用いた業務内容について説明する。本システムを用いた業務内容には、日々配船業務と、気象警報発令時業務と、安全管理業務とがある。
『日々配船業務(位置情報確認)』とは、配船担当者がオーダーに対して打鍵(キー入力)を行った上、運航指示を与えて、また船舶から動静報告を受け付ける業務である。
『気象警報発令時業務』とは、警報発令の受信を行い、必要に応じて注意喚起を行い、また、必要に応じて状況報告を行う業務である。
『安全管理業務(注意喚起業務)』とは、サーバの地上ユーザの確認状態区分が未確認状態である場合であって、船舶受信状況の確認要求がサーバからなされた際、かかる確認要求に対してクリック操作を行えば、会社が登録を行ったことの自動登録を行い、その結果、サーバにおける地上ユーザの確認状態区分を、未確認状態から確認状態に遷移させる業務である。
『気象警報発令時業務』とは、警報発令の受信を行い、必要に応じて注意喚起を行い、また、必要に応じて状況報告を行う業務である。
『安全管理業務(注意喚起業務)』とは、サーバの地上ユーザの確認状態区分が未確認状態である場合であって、船舶受信状況の確認要求がサーバからなされた際、かかる確認要求に対してクリック操作を行えば、会社が登録を行ったことの自動登録を行い、その結果、サーバにおける地上ユーザの確認状態区分を、未確認状態から確認状態に遷移させる業務である。
図３は、日々配船業務(位置情報確認)、気象警報発令時業務、安全管理業務(注意喚起記録)のそれぞれにおいて、地上事業所、船舶、システム外のサーバ、システム内サーバがそれぞれどのような処理を実行するかを表形式で示した図である。横方向は、日々配船業務(位置情報確認)、気象警報発令時業務、安全管理業務(注意喚起記録)のそれぞれに割り当てられている。縦方向の項目は、地上事業所、船舶、システム外のサーバ、システム内サーバのそれぞれに割り当てられている。
日々配船業務(位置情報確認業務)について説明する。日々配船業務に対応する縦の欄の下向きの矢印y1は、配船担当者から船舶への電話を通じた運航指示を模式的に示す。上向きの矢印y2は、船舶から配船担当者への動静報告を模式的に示す。
下向きの矢印y3は、船舶からWEBサーバ４への位置情報の自動発信を模式的に示す。上向きの矢印y4は、WEBサーバ４からディスプレイへの位置確認を模式的に示す。以上の報告、位置確認により、事業所内の地上ユーザは、船舶の位置をリアルタイムに確認することができる。
下向きの矢印y3は、船舶からWEBサーバ４への位置情報の自動発信を模式的に示す。上向きの矢印y4は、WEBサーバ４からディスプレイへの位置確認を模式的に示す。以上の報告、位置確認により、事業所内の地上ユーザは、船舶の位置をリアルタイムに確認することができる。
気象警報発令時業務について説明する。気象警報発令時業務に対応する縦の欄の下向きの矢印y11は 気象協会サーバ１０からWEBサーバ４への警報電文の自動送信を模式的に示す。警報電文の自動受信がなされれば、WEBサーバ４は、ステージg1になる。ステージg1は、警報電文の受信・蓄積である。このステージg1では、位置情報と警報電文とのマッチングを行い、海域の船舶ユーザへの自動情報発信を行う。この際、船舶の状態を送信待ち状態から確認待ち状態に遷移させる。
4つに枝別れする上向きの矢印y12は、気象協会サーバ１０から配船担当者、運航管理者、船舶関係会社への警報通知メール発信及び警報通知メール自動受信を模式的に示す。画面h1、画面h2は、船上クライアント装置３における表示内容の遷移を模式的に示す。画面h1において、警報発令表示がポップアップされ、警報音の出力がなされる。クリックがなされると画面h1から画面h2への遷移がなされる。クリックがなされると、内容確認がされたとして警報音が停止する。その後、船舶は航行警戒行動をとる。
下向きの矢印y13は、船上クライアント装置３からWEBサーバ４への確認レスポンスの発信を模式的に示す。サーバにおける船舶確認状態区分は、確認待ち状態から確認状態に遷移する。
左上向きの矢印y21,y22は、配船担当者、運航管理者から船舶ユーザへの注意喚起を模式的に示す。左向きの矢印y23は、船員関係会社から船舶ユーザへの注意喚起を模式的に示す。
左上向きの矢印y21,y22は、配船担当者、運航管理者から船舶ユーザへの注意喚起を模式的に示す。左向きの矢印y23は、船員関係会社から船舶ユーザへの注意喚起を模式的に示す。
左上向の矢印y31,y32は、船舶から配船担当者、運航管理者への状況報告を模式的に示す。左向きの矢印y33は、船舶から船舶関係会社への状況報告を模式的に示す。
以上のように、警報の発令時では以上のような警報通知メールの発信と、状況報告とがなされるから、船上ユーザ、地上ユーザによる管理が徹底されることになる。
安全管理業務の内容について説明する。安全管理業務に対応する縦の欄の上向きの矢印y41は、WEBサーバ４から配船担当者への船舶受信状況の確認送信を模式的に示す。下向きの矢印y42は、配船担当者からWEBサーバ４への応答発信を模式的に示す。ステージg3は、確認送信時及び応答発信時の確認状態区分の変化を模式的に示す。これにより、WEBサーバ４における地上ユーザの確認状態区分は、確認待ち状態から確認状態に遷移する。
以上のように、警報の発令時では以上のような警報通知メールの発信と、状況報告とがなされるから、船上ユーザ、地上ユーザによる管理が徹底されることになる。
安全管理業務の内容について説明する。安全管理業務に対応する縦の欄の上向きの矢印y41は、WEBサーバ４から配船担当者への船舶受信状況の確認送信を模式的に示す。下向きの矢印y42は、配船担当者からWEBサーバ４への応答発信を模式的に示す。ステージg3は、確認送信時及び応答発信時の確認状態区分の変化を模式的に示す。これにより、WEBサーバ４における地上ユーザの確認状態区分は、確認待ち状態から確認状態に遷移する。
続いて、フローチャートを用いて、船舶の動態管理の処理手順について説明する。
４.船舶の動態管理の処理手順
図４は、船舶の動態管理の処理手順を示すフローチャートである。ステップＳ１０１においてデータ入力を行い、ステップＳ１０２において運航指示を行った後、ステップＳ１０３ーステップＳ１０４のループに移る。ステップＳ１０３は、AIS情報を受信したかどうかの判定であり、ステップＳ１０４は、海象・気象についての警報が発令されたかどうかの判定である。AIS情報を受信した場合、発信元船舶をサーチし(ステップＳ１０５)、受信したAIS情報に示される現在位置を更新して(ステップＳ１０６)、ループに戻る。警報発令時には、警報発令海域を現在位置とする1つ以上の船舶を特定し(ステップＳ１０７)、ステップＳ１０８において、警報発令時における経過管理を開始する。
４.船舶の動態管理の処理手順
図４は、船舶の動態管理の処理手順を示すフローチャートである。ステップＳ１０１においてデータ入力を行い、ステップＳ１０２において運航指示を行った後、ステップＳ１０３ーステップＳ１０４のループに移る。ステップＳ１０３は、AIS情報を受信したかどうかの判定であり、ステップＳ１０４は、海象・気象についての警報が発令されたかどうかの判定である。AIS情報を受信した場合、発信元船舶をサーチし(ステップＳ１０５)、受信したAIS情報に示される現在位置を更新して(ステップＳ１０６)、ループに戻る。警報発令時には、警報発令海域を現在位置とする1つ以上の船舶を特定し(ステップＳ１０７)、ステップＳ１０８において、警報発令時における経過管理を開始する。
５.警報発令時における管理手順
５.１ フローチャートにおける処理手順
図５は、警報発令時における管理手順を示すフローチャートである。船舶ユーザ、地上ユーザに対して警報発令を通知するための警報通知メールを送信し(ステップＳ１１０)、船上ユーザの確認状態区分を確認待ちに変更する(ステップＳ１１１)。船上ユーザの確認状態区分を確認待ちに変更して(ステップＳ１１２)、ステップＳ１１３−ステップＳ１１４のループに移行する。ステップＳ１１３−ステップＳ１１４のループは、船上ユーザからの応答受信待ち(ステップＳ１１３)、地上ユーザからの応答受信待ち(ステップＳ１１４)を繰り返すものである。
５.１ フローチャートにおける処理手順
図５は、警報発令時における管理手順を示すフローチャートである。船舶ユーザ、地上ユーザに対して警報発令を通知するための警報通知メールを送信し(ステップＳ１１０)、船上ユーザの確認状態区分を確認待ちに変更する(ステップＳ１１１)。船上ユーザの確認状態区分を確認待ちに変更して(ステップＳ１１２)、ステップＳ１１３−ステップＳ１１４のループに移行する。ステップＳ１１３−ステップＳ１１４のループは、船上ユーザからの応答受信待ち(ステップＳ１１３)、地上ユーザからの応答受信待ち(ステップＳ１１４)を繰り返すものである。
ステップＳ１１５は、ステップＳ１１３がYesである場合実行されるステップであり、警報発令海域に属する船舶の船上ユーザの確認状態区分を確認待ちから確認済み状態に変更する。
ステップＳ１１６は、ステップＳ１１４がYesになった際実行されるものであり、地上ユーザの確認状態区分を確認待ち状態から確認済み状態に変更する。
ステップＳ１１６は、ステップＳ１１４がYesになった際実行されるものであり、地上ユーザの確認状態区分を確認待ち状態から確認済み状態に変更する。
５.２ AIS情報の内部構成
本システムの動態管理は、AIS情報の存在が大前提である。以下、AIS情報を通じて取得することができる情報要素について詳しく説明する。AIS情報は複数のセンテンスから構成される。これらAIS情報におけるセンテンスには、AISセンテンスを示す「VDM」、船舶の現在位置における緯度、経度を示す「GGA」,「GLL」、船舶、船舶針路を示す「VTG」、船舶の目的地を示す「VDO」がある。
本システムの動態管理は、AIS情報の存在が大前提である。以下、AIS情報を通じて取得することができる情報要素について詳しく説明する。AIS情報は複数のセンテンスから構成される。これらAIS情報におけるセンテンスには、AISセンテンスを示す「VDM」、船舶の現在位置における緯度、経度を示す「GGA」,「GLL」、船舶、船舶針路を示す「VTG」、船舶の目的地を示す「VDO」がある。
VDMのセンテンスについて説明する。VDMは、!--VDM.x,x,x,x,a,s--s,x*hhから構成される。!はカプセル化センテンス開始識別子、--は、通信機IDであり、GPでGPS、AIでAIS装置であることを示す。VDMはVDOセンテンスであり、AIS自船メッセージである。1つ目のxは必要センテンス数、xはセンテンスの連番、xは複数センテンスにおけるメッセージID,aはAISチャネル,s--sは符号化されたAIS電文、xは符号化時に付加したビット数、hhはチャネルサムである。
「GGA」は、「$--GGA、hhmmss.ss、llll.ll、a、yyyyy.yy、a、xx、x.x、x.x、M、x.x、M、x.x、xxxx*hh」という形式のテキストセンテンスから構成される。"$"は、センテンス開始識別子、"--"は通信機IDであり、GPS受信機、AIS装置の何れかを示す。"GGA"はGPSセンテンスであり、GPS位置情報を示す。"hhmmss.ss"は測位時刻を示す。"llll.ll"は緯度を示す。"a"は、llll.llに示される緯度がN(北緯)／S(南緯)の何れかを示す。"yyyy.yy"は経度を示す。"a"は、東経／西経の何れかを示す。1つ目のxはGPS精度、xxは測位に使用した衛星数、1つ目のx.xはHDOP、2つ目のx.xは平均海水面からのアンテナの高度、1つ目のMは平均海水面からのアンテナの高度の単位、3つ目のx.xはWGS-84楕円体からの平均海水面の高度差、2つ目のMはWGS-84楕円体からの平均海水面の高度差の単位、4つ目のx.xはDGPSデータのエイジ、xxxxはDGPSの基準局のID、"hh"はチェックサムである。これらGGA、GLLは、船上クライアントにAISトランスポンダを介して接続された、VHFアンテナ、GPSアンテナ、レーダーによって取得されたものである。
「GLL」は、$--GLL、llll.ll、a、yyyy.yy、a、hhmmss.ss、A、a*hhという形式のテキストセンテンスから構成される。"$"は、センテンス開始識別子、"--"は通信機IDであり、GPS受信機、AIS装置の何れかを示す。"GLL"はGPSセンテンスであり、地理的位置データ(緯度／経度)を示す。"llll.ll"は緯度を示す。"a"は、llll.llに示される緯度がN(北緯)／S(南緯)の何れかを示す。yyyy.yyは経度を示す。"a"は、東経／西経の何れかを示す。hhmmss.ssは測位時刻を示す。"A"はステータスを示す。"a+hh"のaは、単独測位、DGPS、推測航法、手動入力、シミュレータ、無効の何れかのモードを示す。hhはチェックサムを示す。
「VTG」は、$--VTG、x.x、T、x.x、M、x.x、N、x.x、K、a*hhという形式のテキストセンテンスによって構成される。"$"はセンテンス開始識別子、"--"は通信機IDであり、GPS受信機、AIS装置の何れかを示す。"VTG"はVTGセンテンスであり対地針路及び対地速力を示す。"x.x"は真北に対する進行方向、"T.x.x"は磁北に対する進行方向、"M x.x"は対地速度(ノット)を示す。"N x.x"は対地速度(Km/h)を示す。"K a+hh"の"a"は、単独測位、DGPS、推測航法、手動入力、シミュレータ、無効の何れかのモードを示す。hhはチェックサムである。
VDOのセンテンスについて説明する。VDOは、!--VDO.x,x,x,x,a,s--s,x*hhから構成される。!はカプセル化センテンス開始識別子、--は、通信機IDであり、GPでGPS、AIでAIS装置であることを示す。VDOはVDOセンテンスであり、AIS自船メッセージである。1つ目のxは必要センテンス数、xはセンテンスの連番、xは複数センテンスにおけるメッセージID,aはAISチャネル,s--sは符号化されたAIS電文、xは符号化時に付加したビット数、hhはチャネルサムである。
以上がAIS情報についての説明である。
５.３ 船上クライアント装置１からAIS情報サーバへのAIS情報転送
船上クライアント装置のローカルドライブには、所定の構造のディレクトリが存在する。その所定の構造とは、船上クライアント装置におけるコンフィグレーションファイルで指定されたルートディレクトリの配下に船舶IDディレクトリが存在し、更にその配下に、未処理ディレクトリ、処理済みディレクトリ、エラーディレクトリ、XMLディレクトリが存在するというものである。AIS情報を送信するにあたっては、未処理ディレクトリに、AIS情報を格納した送信可能状態ファイルを配置する。このAIS情報を格納した送信可能状態ファイルには、船舶ID＋YYYYMMMDD#HH24MISS.txtというファイル名が付与される。AIS情報を含む送信可能状態ファイルは、クライアントにおけるファイル送信アプリケーションによって、リレーショナルデータベースサーバ６との通信が確立して送信可能状態になった際、サーバに順次送信されてゆく。
５.３ 船上クライアント装置１からAIS情報サーバへのAIS情報転送
船上クライアント装置のローカルドライブには、所定の構造のディレクトリが存在する。その所定の構造とは、船上クライアント装置におけるコンフィグレーションファイルで指定されたルートディレクトリの配下に船舶IDディレクトリが存在し、更にその配下に、未処理ディレクトリ、処理済みディレクトリ、エラーディレクトリ、XMLディレクトリが存在するというものである。AIS情報を送信するにあたっては、未処理ディレクトリに、AIS情報を格納した送信可能状態ファイルを配置する。このAIS情報を格納した送信可能状態ファイルには、船舶ID＋YYYYMMMDD#HH24MISS.txtというファイル名が付与される。AIS情報を含む送信可能状態ファイルは、クライアントにおけるファイル送信アプリケーションによって、リレーショナルデータベースサーバ６との通信が確立して送信可能状態になった際、サーバに順次送信されてゆく。
５.４ AIS情報サーバからシステム内データへのAIS情報転送
次に、AIS情報サーバからシステム内サーバへのAIS情報の転送について説明する。AIS情報は、AIS情報のサーバによってFTPを通じて供給される。FTPによる取得を前提にしているから、転送にあたっては転送対象となるAISデータファイルのファイル名を特定する必要がある。そこでWEBサーバ７は、以下の最新ファイル名取得処理、AIS情報データファイル取得処理にてAIS情報を格納したファイルのファイル名を取得する。
次に、AIS情報サーバからシステム内サーバへのAIS情報の転送について説明する。AIS情報は、AIS情報のサーバによってFTPを通じて供給される。FTPによる取得を前提にしているから、転送にあたっては転送対象となるAISデータファイルのファイル名を特定する必要がある。そこでWEBサーバ７は、以下の最新ファイル名取得処理、AIS情報データファイル取得処理にてAIS情報を格納したファイルのファイル名を取得する。
最新ファイル名取得処理は以下の通りである。リレーショナルデータベースをオープンして、抽出キーとしてコンフィグレーションファイルに設定されている船舶IDを設定する。設定された各船舶のそれぞれについて取込日時が最新となるレコードのファイルIDを取得する。取得できた場合、データセットに設定して返却値とする。取得できなかった場合、ヌルを返却値とする。
AIS情報データファイル取得処理は以下の通りである。上記最新ファイル名取得処理で取得した船舶ID及びファイルIDを取得する。ここで取得されるファイルIDはZIPファイルのファイル名となる。続いてFTPクラスを生成し、各プロパティを設定する。このFTPクラスにおけるプロパティには、FTPユーザID、FTPパスワード、FTPサーバアドレス、FTPサーバ側ディレクトリ、FTPサーバ側ファイル名、ダウンロード用のローカルディレクトリ、ダウンロード用のローカルファイル名がある。これらのうち、FTPユーザID、FTPパスワード、FTPサーバアドレスとしては、サーバのコンフィグレーションファイルから取得したものを設定する。FTPサーバ側ディレクトリとしては取得した船舶IDと、ファイルIDから抜き出された年月日とを用いて設定する。FTPサーバ側ファイル名としては、取得したファイルIDを用いて設定する。ダウンロード用のローカルディレクトリとしてはコンフィグレーションから取得したものを用いる。ダウンロード用のローカルファイル名としては、取得したファイルIDを用いる。以上、FTPのGETコマンドでファイルを取得する。FTPクラスの設定を経てFTPのGETコマンドを発行することにより、FTPサーバであるAISサーバ１１からAIS情報を格納したファイルをダウンロードする。取得できた場合、ファイル名リストファイルに設定する。以上がAIS情報データファイル取得処理についての説明である。
６.データベースの内部構成
上記システムは、リレーショナルデータベースマネジメントシステム(RDBMS)であり、C言語、Java（登録商標）言語やSQL（Structured Query Language）等の高級プログラミング言語を用いて記述することができる。このデータベースを構成する個々のレコードは、マスタと、テーブルとに分類できる。「マスター」は、更新が予定されていない情報の集まりからなるレコードである。一方、「テーブル」は、トランザクションの発生に応じた発生・更新・削除が予定されている情報の集まりからなるレコードである。リレーショナルデータベースは高級プログラミング言語での記述が可能であるから、これらのマスタやレコードのデータ構造を、クラス構造体を用いて定義することができる。本実施形態のデータベースで特徴的なのは、"AIS情報受信"というトランザクションや"警報通知"というトランザクションが発生する度に、データベースに新たなレコードが追加されてゆく点である。
上記システムは、リレーショナルデータベースマネジメントシステム(RDBMS)であり、C言語、Java（登録商標）言語やSQL（Structured Query Language）等の高級プログラミング言語を用いて記述することができる。このデータベースを構成する個々のレコードは、マスタと、テーブルとに分類できる。「マスター」は、更新が予定されていない情報の集まりからなるレコードである。一方、「テーブル」は、トランザクションの発生に応じた発生・更新・削除が予定されている情報の集まりからなるレコードである。リレーショナルデータベースは高級プログラミング言語での記述が可能であるから、これらのマスタやレコードのデータ構造を、クラス構造体を用いて定義することができる。本実施形態のデータベースで特徴的なのは、"AIS情報受信"というトランザクションや"警報通知"というトランザクションが発生する度に、データベースに新たなレコードが追加されてゆく点である。
６.１ マスタ、テーブル
図６は、リレーショナルデータベースにおけるマスタと、テーブルとを示す。リンクは、レコードにおけるフィールド同士のリレーションを模式的に示す。本図において船舶状態レコード、気象状態レコード、通知状態レコード、通知状態明細レコード、通知条件テーブルが重ね合わされた形態で記載されているのは、同じデータ構造で、そのフィールドの内容が異なるレコードが複数存在することを象徴的に表している。ユーザマスタレコード(m#user)は、ユーザID、ユーザグループIDからなり、ワークグループマスタ(m#work#group)は、ユーザグループID、ユーザIDからなる。ユーザマスタとワークグループマスタとは、ユーザIDを同一のフィールドとして具備することでリレーションr1を有している。船舶管理グループマスタ(m#ship#management#group)は、船舶IDと、ワークグループIDとから構成され、ワークグループIDを共通のフィールドとすることで船舶管理グループマスタと、ワークグループマスタとは、リレーションr2を有している。
図６は、リレーショナルデータベースにおけるマスタと、テーブルとを示す。リンクは、レコードにおけるフィールド同士のリレーションを模式的に示す。本図において船舶状態レコード、気象状態レコード、通知状態レコード、通知状態明細レコード、通知条件テーブルが重ね合わされた形態で記載されているのは、同じデータ構造で、そのフィールドの内容が異なるレコードが複数存在することを象徴的に表している。ユーザマスタレコード(m#user)は、ユーザID、ユーザグループIDからなり、ワークグループマスタ(m#work#group)は、ユーザグループID、ユーザIDからなる。ユーザマスタとワークグループマスタとは、ユーザIDを同一のフィールドとして具備することでリレーションr1を有している。船舶管理グループマスタ(m#ship#management#group)は、船舶IDと、ワークグループIDとから構成され、ワークグループIDを共通のフィールドとすることで船舶管理グループマスタと、ワークグループマスタとは、リレーションr2を有している。
ユーザグループマスタ(m#user#group)は、ユーザグループID、親ユーザグループID、共通コード、役割IDを有しており、これらのうち、ユーザグループIDを共通のフィールドとして具備することで、ユーザグループマスタは、ユーザマスタとリレーションr3を有している。
役割マスタ(m#role)は役割IDを、権限マスタは役割ID、機能IDを具備しており、役割IDを共通のフィールドとして具備することで、役割マスタ、権限マスタはリレーションr4を有している。役割マスタは、配船担当等、地上ユーザが担う役割を示す権限マスタは、配船業務の責任の存在等を示す。警報通知時の状態管理に関連する役割として、役割マスタ、権限マスタに規定されているのは、"確認者"、"電話連絡者"である。
役割マスタ(m#role)は役割IDを、権限マスタは役割ID、機能IDを具備しており、役割IDを共通のフィールドとして具備することで、役割マスタ、権限マスタはリレーションr4を有している。役割マスタは、配船担当等、地上ユーザが担う役割を示す権限マスタは、配船業務の責任の存在等を示す。警報通知時の状態管理に関連する役割として、役割マスタ、権限マスタに規定されているのは、"確認者"、"電話連絡者"である。
"確認者"は、クライアント装置における詳細表示やメール・メッセージの送受信によって、警報通知の確認をせねばならない責務を負ったものである。
"電話連絡者"は、電話を通じて警報通知の確認をせねばならない責務を負った者である。電話連絡者が確認者とは別に存在するのは、電話により警報を地上ユーザに通知し、それの応答を受信した場合、システム上には何等履歴が残らず、その警報発令時の経過を管理し得ないからである。
"電話連絡者"は、電話を通じて警報通知の確認をせねばならない責務を負った者である。電話連絡者が確認者とは別に存在するのは、電話により警報を地上ユーザに通知し、それの応答を受信した場合、システム上には何等履歴が残らず、その警報発令時の経過を管理し得ないからである。
機能マスタ(m#function)は、機能ID、機能グループIDを具備しており、機能グループマスタ(m#function#group)は、機能グループID、親機能グループIDを具備している。これら機能マスタ、機能グループマスタは、機能グループIDを共通のフィールドとして具備することでリレーションr5を有している。
船舶状態レコード(t#ship#state)は、船舶ID、取得日付、取得時刻、目的地、現在地ID、気象領域ID、気象取得日付、気象取得時刻、現在地(緯度)、現在地(経度)といったフィールドを具備している。気象状態レコード(t#weather#state)は、領域ID、取得日付、取得時刻をといったフィールドを有し、これらは船舶状態との共通の項目になるから、領域ID、取得日付、取得時刻によって、船舶状態レコードは、気象状態とリレーションr6,r7,r8を有する。
船舶状態レコード(t#ship#state)は、船舶ID、取得日付、取得時刻、目的地、現在地ID、気象領域ID、気象取得日付、気象取得時刻、現在地(緯度)、現在地(経度)といったフィールドを具備している。気象状態レコード(t#weather#state)は、領域ID、取得日付、取得時刻をといったフィールドを有し、これらは船舶状態との共通の項目になるから、領域ID、取得日付、取得時刻によって、船舶状態レコードは、気象状態とリレーションr6,r7,r8を有する。
通知状態レコード(t#notification#state)は、船舶ID、取得日付、取得時刻、通知分類ID、通知内容IDから構成され、これらのうち船舶ID、取得日付、取得時刻は船舶状態レコードとの共通のフィールドであるから、船舶ID、取得日付、取得時刻において、通知状態レコードは、船舶状態とリレーションr9,r10,r11を有している。
通知状態明細レコード(t#notification#state#detail)は、船舶ID、取得日付、取得時刻、通知分類ID、通知内容ID、ユーザIDから構成され、これらのうち取得日付、取得時刻、通知分類ID、通知内容IDは船舶状態との共通のフィールドであるから、船舶ID、取得日付、取得時刻、通知分類ID、通知内容IDにおいて、通知状態明細は、通知状態とリレーションr21,r22,r23,r24,r25を有している。
通知状態明細レコード(t#notification#state#detail)は、船舶ID、取得日付、取得時刻、通知分類ID、通知内容ID、ユーザIDから構成され、これらのうち取得日付、取得時刻、通知分類ID、通知内容IDは船舶状態との共通のフィールドであるから、船舶ID、取得日付、取得時刻、通知分類ID、通知内容IDにおいて、通知状態明細は、通知状態とリレーションr21,r22,r23,r24,r25を有している。
通知条件テーブルは、船舶ID、通知分類ID、通知内容IDから構成される。これら通知状態レコード、通知状態明細レコード、通知条件テーブルにおいて、通知分類ID、通知内容IDは、コードマスタに定義されたコード１、コード２を用いて表現される。コードマスタは、コード１、コード２といったフィールドを有しており、通知条件テーブルにおける通知分類ID、通知内容IDは、このコードマスタにおけるコード１、コード２を用いて定義される。以上のコード１、コード２において、通知状態レコード、通知条件テーブルは、リレーションr31,r32,r33,r34を有している。コード１とは発令分類であり、地方海上警報電文等の種別を示す。コード２は、コード１に示される分類の地方海上警報電文がどのような内容であるかを示す。具体的には、波浪、濃霧、台風、津波等を示す。
以上がリレーショナルデータベースについての説明である。
７.画面の基本遷移
対話画面は、テキストボックス、メニュー表示／非表示を切り替えるためのボタン、リンク、展開縮小ボックス、リストボックス、入力支援付きのテキストボックス、スクロールバー、チェックボックス、階層化チェックボックスから構成され、サーチエンジンにおけるGUIを実現するものである。以上のリレーショナルデータベースにて規定された船舶状態レコード、通知状態レコード、通知条件テーブルは、クライアントにおけるブラウザによって閲覧可能である。この閲覧を可能にするため、船舶安全管理システムにおけるクライアント装置となるパーソナルコンピュータ、携帯端末の画面仕様は、図７、図８に示すものとなる。
７.（ａ） 基本画面遷移
図７は、画面の基本遷移を示す。図７（ａ）は機能画面遷移を示す。起動時においてログイン画面g1となり、ログイン実行によりヘッダ・メニューが付加されたスタートページg2になる。機能リンクを通じて各機能画面g3になる。また、機能画面g3からは、スタートページリンクを通じて元の画面に戻る。
７.画面の基本遷移
対話画面は、テキストボックス、メニュー表示／非表示を切り替えるためのボタン、リンク、展開縮小ボックス、リストボックス、入力支援付きのテキストボックス、スクロールバー、チェックボックス、階層化チェックボックスから構成され、サーチエンジンにおけるGUIを実現するものである。以上のリレーショナルデータベースにて規定された船舶状態レコード、通知状態レコード、通知条件テーブルは、クライアントにおけるブラウザによって閲覧可能である。この閲覧を可能にするため、船舶安全管理システムにおけるクライアント装置となるパーソナルコンピュータ、携帯端末の画面仕様は、図７、図８に示すものとなる。
７.（ａ） 基本画面遷移
図７は、画面の基本遷移を示す。図７（ａ）は機能画面遷移を示す。起動時においてログイン画面g1となり、ログイン実行によりヘッダ・メニューが付加されたスタートページg2になる。機能リンクを通じて各機能画面g3になる。また、機能画面g3からは、スタートページリンクを通じて元の画面に戻る。
機能単位遷移
図７（ｂ）は、船舶クライアント装置における機能単位遷移を示す。機能単位遷移とは、システムから供給される個々の機能を発揮する際になされる画面遷移を示す。これらの機能には、船舶状況管理や通知状態管理がある。船舶における機能単位遷移では、先ず初期表示である船舶状況一覧の画面g5になり、検索実行を経て船舶状況一覧画面g6になる。
図７（ｂ）は、船舶クライアント装置における機能単位遷移を示す。機能単位遷移とは、システムから供給される個々の機能を発揮する際になされる画面遷移を示す。これらの機能には、船舶状況管理や通知状態管理がある。船舶における機能単位遷移では、先ず初期表示である船舶状況一覧の画面g5になり、検索実行を経て船舶状況一覧画面g6になる。
７.（ｃ）通知状態管理
図７（ｃ）は、通知状態管理の画面遷移を示す。先ず、通知状態管理の初期表示の画面g7になり、検索実行により通知状態の画面g8となる。詳細機能の呼び出しにより通知内容詳細の画面g9になり、戻り手順により通知状態管理になる。
７.（ｄ）通知条件設定
図７（ｄ）は、通知条件設定の画面遷移を示す。先ず、通知条件設定の初期表示の画面g10になり、検索実行により通知条件一覧の画面g11となる。新規機能の実行呼出しにより通知条件一覧及び通知条件設定の画面g12になり、リンク選択により通知条件設定の画面g13になる。
図７（ｃ）は、通知状態管理の画面遷移を示す。先ず、通知状態管理の初期表示の画面g7になり、検索実行により通知状態の画面g8となる。詳細機能の呼び出しにより通知内容詳細の画面g9になり、戻り手順により通知状態管理になる。
７.（ｄ）通知条件設定
図７（ｄ）は、通知条件設定の画面遷移を示す。先ず、通知条件設定の初期表示の画面g10になり、検索実行により通知条件一覧の画面g11となる。新規機能の実行呼出しにより通知条件一覧及び通知条件設定の画面g12になり、リンク選択により通知条件設定の画面g13になる。
８.携帯電話の画面遷移
図８は、携帯電話であるクライアントの画面における基本遷移を示す。ログイン画面g21からログイン手順を経て船舶一覧の画面g22になり、リンク選択を経て個別船舶状況の画面g23になる。更に、リンク選択を経て現在地表示の画面g24になる。逆に、現在地表示から「戻り」の手順を経て個別船舶機能表示になり、戻り手順を経て船舶一覧になる。最後にログアウト手順を経ることでログイン画面g21にもどる。以上がクライアント画面の画面遷移の概要についての説明である。画面内容の詳細については後段に説明の場を譲る。
図８は、携帯電話であるクライアントの画面における基本遷移を示す。ログイン画面g21からログイン手順を経て船舶一覧の画面g22になり、リンク選択を経て個別船舶状況の画面g23になる。更に、リンク選択を経て現在地表示の画面g24になる。逆に、現在地表示から「戻り」の手順を経て個別船舶機能表示になり、戻り手順を経て船舶一覧になる。最後にログアウト手順を経ることでログイン画面g21にもどる。以上がクライアント画面の画面遷移の概要についての説明である。画面内容の詳細については後段に説明の場を譲る。
９.気象状態レコード、船舶状態レコード
本システムにおける動態管理の基盤を支えるのは、上述したようなリレーショナルデータベースの構成要素のうち、気象状態レコード及び船舶状態レコードである。各気象状態レコードは、ある船舶が属する領域の気象状態を示すテーブル形式のデータであり、その気象状態を通知するための通知分類を含み、各船舶状態レコードは、気象状態レコードに示される気象状態において、船舶がどのような状態になっているかを示すテーブル形式のデータである。
本システムにおける動態管理の基盤を支えるのは、上述したようなリレーショナルデータベースの構成要素のうち、気象状態レコード及び船舶状態レコードである。各気象状態レコードは、ある船舶が属する領域の気象状態を示すテーブル形式のデータであり、その気象状態を通知するための通知分類を含み、各船舶状態レコードは、気象状態レコードに示される気象状態において、船舶がどのような状態になっているかを示すテーブル形式のデータである。
９.（ａ） 船舶状態レコード
以下、船舶状態レコードについて説明する。船舶状態レコードは、AIS情報受信というトランザクションが発生した際、リレーショナルデータベースに追加されるレコードであり、図９（ａ）は、船舶状態レコード(t#ship#state)のテーブル構造を示す。本図では、テーブル日本語名、テーブル物理名の二段表記で、テーブルの名称を表現している。また、日本語名、物理名の二段表記で、テーブルにおける個々のフィールドを表現している。"物理名"とは、C言語、SQL等のコンピュータプログラミング言語で宣言された変数名であり、コンパイル言語による翻訳やインタプリタによる解釈が可能なテキスト文字列そのものである。"日本語名"とは、その物理名における変数名を、人間が理解しやすい内容で表現したものである。テーブルやフィールドの表記には、断らない限りこの日本語名を用いることとし、物理名は括弧書きで表記する。
以下、船舶状態レコードについて説明する。船舶状態レコードは、AIS情報受信というトランザクションが発生した際、リレーショナルデータベースに追加されるレコードであり、図９（ａ）は、船舶状態レコード(t#ship#state)のテーブル構造を示す。本図では、テーブル日本語名、テーブル物理名の二段表記で、テーブルの名称を表現している。また、日本語名、物理名の二段表記で、テーブルにおける個々のフィールドを表現している。"物理名"とは、C言語、SQL等のコンピュータプログラミング言語で宣言された変数名であり、コンパイル言語による翻訳やインタプリタによる解釈が可能なテキスト文字列そのものである。"日本語名"とは、その物理名における変数名を、人間が理解しやすい内容で表現したものである。テーブルやフィールドの表記には、断らない限りこの日本語名を用いることとし、物理名は括弧書きで表記する。
船舶状態レコード(t#ship#state)は、船舶CD(ship#cd)と、取得日付(acquisition#date)と、取得時刻(acquisition#time)と、目的地(destination#name)と、到着予定日付(eta#date)と、到着予定時刻(eta#time)と、速度(speed)と、現在地ID(plesent#place#id)と、気象領域ID(weather#area#id)と、気象取得日付(weather#acquisition#date)と、気象取得時刻(weatheｒ#acquisition#time)と、現在地の緯度(latitude)、現在地の経度(longitude)と、速度(speed#km)と、対真北の進行方向(advance#direction#due)と、対磁北の進行方向(advance#direction#magnetic)と、削除フラグ(delete#flg)とから構成される。以下、船舶状態レコードの用途について説明する。
９.（ａ）.１ 船舶状態レコードの用途
船舶状態レコードは、主として船舶動態地図作成処理に用いられる。船舶動態地図作成処理とは、船舶状態レコードに登録されている船舶最新情報の現在地ID及び緯度・経度により地図作成向けに用意する領域に基づいた位置を地図イメージファイルへ船舶名称と共に設定し、どの海域にどの船舶が航海しているかを一目で確認できるようにするものである。
船舶状態レコードは、主として船舶動態地図作成処理に用いられる。船舶動態地図作成処理とは、船舶状態レコードに登録されている船舶最新情報の現在地ID及び緯度・経度により地図作成向けに用意する領域に基づいた位置を地図イメージファイルへ船舶名称と共に設定し、どの海域にどの船舶が航海しているかを一目で確認できるようにするものである。
動態地図作成処理について説明する。先ず船舶状態レコードで船舶毎に最新の船舶状態レコードを取得する。この取得条件は、船舶毎に、船舶状態レコードの取得日時が最新のものを取得するというものである。続いて、船舶分以下の処理を行う。地図作成マスタより、船舶状態レコードの船舶位置から設定位置情報を取得して、内部情報保持クラスに、設定位置情報を設定する。地図画像ファイルをビットマップオブジェクトとして取得し、各船舶の船舶位置情報をビットマップオブジェクトに設定する。作成した画像ファイルをコンフィグレーションファイルに定義したディレクトリに保存して、作成履歴情報をXMLファイルで保存する。このような船舶動態地図を、システム内のクライアントパーソナルコンピュータや携帯端末に表示させることで地上ユーザは、船舶の位置をリアルタイムに確認することができる。以上が、船舶状態レコードの主たる用途である。
９.（ｂ） 通知状態レコード
次に、通知状態レコードについて説明する。通知状態レコードは、警報通知受信というトランザクションが発生した際、リレーショナルデータベースに追加されるレコードであり、管理下にある船舶に対してどのような通知がなされたかを示すと共に、船上ユーザによる当該通知に対して確認がなされたかどうかの区分(確認状態区分)を有するレコードであり、当該フィールドは初期値として確認待ちを示す値に設定される。
次に、通知状態レコードについて説明する。通知状態レコードは、警報通知受信というトランザクションが発生した際、リレーショナルデータベースに追加されるレコードであり、管理下にある船舶に対してどのような通知がなされたかを示すと共に、船上ユーザによる当該通知に対して確認がなされたかどうかの区分(確認状態区分)を有するレコードであり、当該フィールドは初期値として確認待ちを示す値に設定される。
図９（ｂ）は、通知状態レコード(t#notification#state)のデータ構造を示す。本図では、テーブル日本語名、テーブル物理名の二段表記で、テーブルの名称を表現している。また、日本語名、物理名の二段表記で、テーブルにおける個々のフィールドを表現している。通知状態レコードは、船舶CD(ship#cd)と、取得日付(acquisition#date)と、取得時刻(acquisition#time)と、通知分類ID(notification#shared#id)と、通知内容ID(notification#content#id)と、船舶確認状態区分(ship#confirm#kbn)と、船舶状態確認日時(ship#confirm#date)と、警報注意報発生区分(warning#generate#kbn)と、通知区分(notification#kbn)と、通知日付(notification#date)と、通知時刻(notification#time)と、警報情報(warning#info)と、注意報情報(advisory#info)と、気象情報詳細(weather#info#detail)とから構成される。通知分類には、警報、警報注意報、注意報、気象、海象といったものがある。以上が通知状態レコードについての説明である。
通知区分は、「通知済み」、「通知なし」に設定される。ここで通知区分が「通知済み」に設定されるのは、通知状態レコードにおける通知内容IDと、一致する通知条件テーブルが存在することが要件になる。「通知なし」の設定は、通知状態レコードにおける通知内容IDと一致する通知条件テーブルが存在しないことが要件になる。
１０.個々の船舶状態レコードにおける情報内容の一覧表示
通知のそれぞれについて通知状態レコードが作成されるため、地上クライアント装置におけるサーチエンジンのGUIには、個々の船舶状態レコードにおける情報内容の一覧表示が可能になる。図１０は、所定の検索条件に一致する船舶状況情報の全てを一覧表示に供する画面（船舶状況機能画面）の一例を示す。本図における船舶状況情報とは、２００件の検索結果のことであり、本図では、その上位２０件が一覧表示の対象になっている。一件当りの検索結果である船舶状況情報は、船舶状態レコードの情報と、気象情報とを対応付けたものである。これらのうち強調表示が施されたつばめ丸についての船舶状況情報を説明する。つばめ丸についての船舶状況情報は、取得日時が2012年6月13日であり、目的地は水島港、ETAは2012年6月13日 18:00、速度は、6.0ノット、現在地は鳴門海峡、取得日時は2012年06月13日9:00,風速は8ノット、波高は3cmであることを示す。警報として暴風波浪警報、注意報として濃霧注意報が発令されていることを示す。図中のETA(Estimated Time Arrival)とは船舶の予定到着時刻を示す。
１０.個々の船舶状態レコードにおける情報内容の一覧表示
通知のそれぞれについて通知状態レコードが作成されるため、地上クライアント装置におけるサーチエンジンのGUIには、個々の船舶状態レコードにおける情報内容の一覧表示が可能になる。図１０は、所定の検索条件に一致する船舶状況情報の全てを一覧表示に供する画面（船舶状況機能画面）の一例を示す。本図における船舶状況情報とは、２００件の検索結果のことであり、本図では、その上位２０件が一覧表示の対象になっている。一件当りの検索結果である船舶状況情報は、船舶状態レコードの情報と、気象情報とを対応付けたものである。これらのうち強調表示が施されたつばめ丸についての船舶状況情報を説明する。つばめ丸についての船舶状況情報は、取得日時が2012年6月13日であり、目的地は水島港、ETAは2012年6月13日 18:00、速度は、6.0ノット、現在地は鳴門海峡、取得日時は2012年06月13日9:00,風速は8ノット、波高は3cmであることを示す。警報として暴風波浪警報、注意報として濃霧注意報が発令されていることを示す。図中のETA(Estimated Time Arrival)とは船舶の予定到着時刻を示す。
１１.通知条件テーブル
船舶状態レコードに示される船舶の現在状況はリアルタイムに変化するため、何等かの事象が発生した場合、船上ユーザ及び地上ユーザにそのような事象発生を通知せねばならない。地上ユーザ及び船上ユーザに対する通知をどのような条件下で実行するかは、通知条件テーブルを用いてルール付けされる。以下、通知条件テーブルのデータ構造と、この通知条件テーブル設定のためのGUIとについて説明する。
船舶状態レコードに示される船舶の現在状況はリアルタイムに変化するため、何等かの事象が発生した場合、船上ユーザ及び地上ユーザにそのような事象発生を通知せねばならない。地上ユーザ及び船上ユーザに対する通知をどのような条件下で実行するかは、通知条件テーブルを用いてルール付けされる。以下、通知条件テーブルのデータ構造と、この通知条件テーブル設定のためのGUIとについて説明する。
通知条件テーブルとは、ユーザに対する通知の条件付けを規定するテーブル形式のデータであり、通知条件テーブルによる条件付けは、通知がどのような類型に属するかを示す通知分類と、通知がどのような内容であるかを示す通知内容とによって規定される。
１１.（ａ）データ構造
図１１（ａ）は、通知条件テーブル(t#notification#condition)の詳細なデータ構造を示す。本図では、テーブル日本語名、テーブル物理名の二段表記で、テーブルの名称を表現している。また、日本語名、物理名の二段表記で、テーブルにおける個々のフィールドを表現している。通知条件テーブル(t#notification#condition)は、船舶コード(ship#cd)、通知分類ID(notification#share#id)、通知内容ID(notification#content#id)、発令時メール送信(announce#mail#send)、発令時メッセージ送信(announce#message#send)、解除時メール送信(release#mail#send)、解除時メッセージ送信(release#message#send)からなる。この通知条件は、通知条件設定画面を通じて設定される。
１１.（ａ）データ構造
図１１（ａ）は、通知条件テーブル(t#notification#condition)の詳細なデータ構造を示す。本図では、テーブル日本語名、テーブル物理名の二段表記で、テーブルの名称を表現している。また、日本語名、物理名の二段表記で、テーブルにおける個々のフィールドを表現している。通知条件テーブル(t#notification#condition)は、船舶コード(ship#cd)、通知分類ID(notification#share#id)、通知内容ID(notification#content#id)、発令時メール送信(announce#mail#send)、発令時メッセージ送信(announce#message#send)、解除時メール送信(release#mail#send)、解除時メッセージ送信(release#message#send)からなる。この通知条件は、通知条件設定画面を通じて設定される。
警報注意報のうち、発令内容の更新がなされた場合であって、その発令内容の更新が、複数の警報、注意報のうち一部の発令である場合、発令時メール送信、発令時メッセージ送信が「送信」が設定されていればその一部発令においてもメール・メッセージ送信がなされることになる。
また警報注意報のうち、発令内容の更新がなされた場合であって、その発令内容の更新が、複数の警報、注意報のうち一部の解除である場合、解除時メール送信、解除時メッセージ送信が「送信」に設定されていればその一部解除においてもメール・メッセージ送信がなされることになる。しかし解除時メール送信、解除時メッセージ送信は「送信無」に設定しておくことが一般的であると思われる。解除時においては、メール・メッセージの送信を省いても支障がないからである。
また警報注意報のうち、発令内容の更新がなされた場合であって、その発令内容の更新が、複数の警報、注意報のうち一部の解除である場合、解除時メール送信、解除時メッセージ送信が「送信」に設定されていればその一部解除においてもメール・メッセージ送信がなされることになる。しかし解除時メール送信、解除時メッセージ送信は「送信無」に設定しておくことが一般的であると思われる。解除時においては、メール・メッセージの送信を省いても支障がないからである。
通知条件設定のためのメニュー
図１１（ｂ）は、通知条件設定のための設定メニューを示す。本図に示すように、通知条件設定のための設定メニューは、通知分類を入力するためのテキストボックスt1、通知内容を入力するためのテキストボックスt2、メール、メッセージについての発令時送信有無の設定のためのセレクションボックスb1,b2、メール、メッセージについての解除時送信有無の設定のためのセレクションボックスb3,b4によって構成される。通知条件テーブルによる条件付けの意義は以下の通りである。通知条件テーブルにより条件付けを行わないと、警報の通知頻度が高くなり、警報確認が煩雑になるという弊害が考えられるからである。また警報通知の信憑性が問われる等の弊害が発生するからである。以上が通知条件テーブルについての説明である。
図１１（ｂ）は、通知条件設定のための設定メニューを示す。本図に示すように、通知条件設定のための設定メニューは、通知分類を入力するためのテキストボックスt1、通知内容を入力するためのテキストボックスt2、メール、メッセージについての発令時送信有無の設定のためのセレクションボックスb1,b2、メール、メッセージについての解除時送信有無の設定のためのセレクションボックスb3,b4によって構成される。通知条件テーブルによる条件付けの意義は以下の通りである。通知条件テーブルにより条件付けを行わないと、警報の通知頻度が高くなり、警報確認が煩雑になるという弊害が考えられるからである。また警報通知の信憑性が問われる等の弊害が発生するからである。以上が通知条件テーブルについての説明である。
１２.通知状態明細レコード
上記のように、船舶における事象発生が地上ユーザ及び船上ユーザに通知された場合、これら地上ユーザ、船上ユーザによる確認がなされたかどうかを詳細に管理せねばならない。この管理のために用いられるのが通知状態明細レコードである。次に通知状態明細レコードについて説明する。通知状態明細レコードは、通知状態レコードに示される通知に対する地上ユーザによる確認がなされたかどうかを示すための確認状態区分を有するテーブルであり、当該確認状態区分は初期値として確認待ちを示す値に設定される。
上記のように、船舶における事象発生が地上ユーザ及び船上ユーザに通知された場合、これら地上ユーザ、船上ユーザによる確認がなされたかどうかを詳細に管理せねばならない。この管理のために用いられるのが通知状態明細レコードである。次に通知状態明細レコードについて説明する。通知状態明細レコードは、通知状態レコードに示される通知に対する地上ユーザによる確認がなされたかどうかを示すための確認状態区分を有するテーブルであり、当該確認状態区分は初期値として確認待ちを示す値に設定される。
この通知状態明細レコードにおいて地上ユーザによる確認状態の遷移は、警報通知に対する地上ユーザからの確認応答の受信時において通知状態明細レコードにおける地上ユーザ確認状態区分のフィールドの値を更新して、確認済み状態を示させることでなされる。
図１２は、船舶状態レコードと、通知状態レコードと、通知状態明細レコードとの関係を示す図である。通知状態明細レコードは、図１２の右端に描かれている。その左側の船舶状態レコード、通知状態レコードは、図９に示したものと同じである。本図では、テーブル日本語名、テーブル物理名の二段表記で、テーブルの名称を表現している。また、日本語名、物理名の二段表記で、テーブルにおける個々のフィールドを表現している。通知状態明細レコード(t#notification#state#detail)は、船舶CD(ship#id)と、取得日付(acquisition#date)と、取得時刻(acquistion#time)と、通知分類ID(notification#share#time)と、通知内容ID(notification#content#ID)と、ユーザID(user#ID)と、確認状態区分(notification#state#kbn)と、通知状態確認日時(notification#confirm#date)と、電話連絡確認日時(telephone#confirm#date)とから構成される。通知状態明細レコードの確認状態区分は、確認待ち状態、確認済み状態の何れかを示すが、確認がなされたかどうかは、警報の詳細表示が既読かどうかによって判断される。通知状態明細レコードの確認状態区分の既読の有無によって判断されるのは、警報通知時では、地上ユーザによる確認に迅速性が求められ、たとえ地上ユーザによる確認があったとしても、その確認時期が警報通知の時期が遅れたものであれば確認の意味をなさないからである。例えば、警報通知から一定期間が経過するまでに詳細表示が地上ユーザによってなされた場合、この既読の要件を具備したことになり、確認状態区分は確認済みに設定されることになる。一方、警報通知から一定期間が経過するまでに詳細表示が地上ユーザによってなされない場合、この既読がなされなかったと設定され、確認状態区分は確認待ちになるか、未確認状態として設定される。地上ユーザの電話による確認時において通知状態明細レコードにおける確認状態区分を自動的に記入することはできない。よって、電話連絡時においては、何れかの地上ユーザがこの確認状態区分をキー入力にする必要がある。
図１２は、船舶状態レコードと、通知状態レコードと、通知状態明細レコードとの関係を示す図である。通知状態明細レコードは、図１２の右端に描かれている。その左側の船舶状態レコード、通知状態レコードは、図９に示したものと同じである。本図では、テーブル日本語名、テーブル物理名の二段表記で、テーブルの名称を表現している。また、日本語名、物理名の二段表記で、テーブルにおける個々のフィールドを表現している。通知状態明細レコード(t#notification#state#detail)は、船舶CD(ship#id)と、取得日付(acquisition#date)と、取得時刻(acquistion#time)と、通知分類ID(notification#share#time)と、通知内容ID(notification#content#ID)と、ユーザID(user#ID)と、確認状態区分(notification#state#kbn)と、通知状態確認日時(notification#confirm#date)と、電話連絡確認日時(telephone#confirm#date)とから構成される。通知状態明細レコードの確認状態区分は、確認待ち状態、確認済み状態の何れかを示すが、確認がなされたかどうかは、警報の詳細表示が既読かどうかによって判断される。通知状態明細レコードの確認状態区分の既読の有無によって判断されるのは、警報通知時では、地上ユーザによる確認に迅速性が求められ、たとえ地上ユーザによる確認があったとしても、その確認時期が警報通知の時期が遅れたものであれば確認の意味をなさないからである。例えば、警報通知から一定期間が経過するまでに詳細表示が地上ユーザによってなされた場合、この既読の要件を具備したことになり、確認状態区分は確認済みに設定されることになる。一方、警報通知から一定期間が経過するまでに詳細表示が地上ユーザによってなされない場合、この既読がなされなかったと設定され、確認状態区分は確認待ちになるか、未確認状態として設定される。地上ユーザの電話による確認時において通知状態明細レコードにおける確認状態区分を自動的に記入することはできない。よって、電話連絡時においては、何れかの地上ユーザがこの確認状態区分をキー入力にする必要がある。
１２.１ 警報発令時の経過ログ
通知状態レコードは、ある船舶に対応付けて作成され、通知状態明細レコードは、船舶と、ユーザとの組み合わせについて一意に作成されるので、これら通知状態レコード、通知状態明細レコードを用いることにより、警報発令時の経過を示すログを構成することができる。
通知状態レコードは、ある船舶に対応付けて作成され、通知状態明細レコードは、船舶と、ユーザとの組み合わせについて一意に作成されるので、これら通知状態レコード、通知状態明細レコードを用いることにより、警報発令時の経過を示すログを構成することができる。
具体的にいうと、通知状態レコード、通知状態明細レコードは、警報発令時、発令内容の更新時、警報解除時に作成されるから、発令を示す通知状態レコード、これに対応する通知状態明細レコード、発令内容の更新を示す通知状態レコード、これに対応する通知状態明細レコード、警報解除を示す通知状態レコード、これに対応する通知状態明細レコードという一連の通知状態レコード、通知状態明細レコードの連鎖によって警報発令時の経過を示すログを構成することができる。よって、これらの通知状態レコード、通知状態明細レコードを永久保存の属性でリレーショナルデータベースに格納しておけば、海難事故があった際の経過履歴の解析を確実にすることができる。
ある船舶が航行している領域に、複数の警報、注意報が発令された場合、個々の発令に対して、通知状態レコード、通知状態明細レコードを生成してデータベースに保存されることになる。そしてこれらの通知状態レコード、通知状態明細レコードを日時順にソートして表示に供することで、警報発令時、更新時の運航履歴の追跡が容易になる。以上が通知状態明細レコードについての説明である。
１２.２ 通知状態レコード、通知状態明細レコードの用途
次に、通知状態レコード、通知状態明細レコードがどのように使用されるかという用途面について説明する。安全管理システムにおけるクライアント装置は、通知状態レコード、通知状態明細レコードを対象にしたサーチエンジンを備える。サーチエンジンは、ユーザからのキーワード入力を受け付けて、リレーショナルデータベースに記憶されている複数の通知状態レコード、複数の通知状態明細レコードのうち、入力されたキーワードに合致するものを探し出し、キーワードに合致する通知状態レコード及び通知状態明細レコードを一覧表示に供する。以上が通知状態レコード、通知状態明細レコードの用途面についての説明である。
次に、通知状態レコード、通知状態明細レコードがどのように使用されるかという用途面について説明する。安全管理システムにおけるクライアント装置は、通知状態レコード、通知状態明細レコードを対象にしたサーチエンジンを備える。サーチエンジンは、ユーザからのキーワード入力を受け付けて、リレーショナルデータベースに記憶されている複数の通知状態レコード、複数の通知状態明細レコードのうち、入力されたキーワードに合致するものを探し出し、キーワードに合致する通知状態レコード及び通知状態明細レコードを一覧表示に供する。以上が通知状態レコード、通知状態明細レコードの用途面についての説明である。
続いて、本システムの動態管理について説明すると共に、船舶に事象が発生した場合における通知状態レコードの検索、及び、通知状態明細レコードの作成の詳細について説明する。
１３.AIS情報に応じた船舶状態レコード、気象状態レコードの更新
FTPを通じてAIS情報を受信した際、そのAIS情報に対応する船舶の船舶状態レコードや気象状態レコードを更新し、またそのAIS情報がある領域への進入を意味するなら、進入データを作成して船舶進入という状態通知を実行せねばならない。
１３.AIS情報に応じた船舶状態レコード、気象状態レコードの更新
FTPを通じてAIS情報を受信した際、そのAIS情報に対応する船舶の船舶状態レコードや気象状態レコードを更新し、またそのAIS情報がある領域への進入を意味するなら、進入データを作成して船舶進入という状態通知を実行せねばならない。
「進入データ」とは、領域IDに示される領域に船舶が突入したというイベントを通知するための通知状態レコードである。進入イベントが発生するのは、管理下にある船舶が何れかの領域に入ったその瞬間であり、領域内で船舶が進行している際中は、「進入」のイベントは発生せず通知状態レコードは作成されない。しかし、領域IDに示される領域から船舶から離脱して、再度、その領域にはいった場合は、「進入」という事象が発生するから、「進入」に対応する通知状態レコードである進入データが作成されることになる。進入データによる状態通知は、状態通知の要件を満たす全ての通知条件テーブルを対象にして実行せねばならないから、通知条件テーブルの検索が前提となる。以上の処理を網羅したのが、図１３のフローチャートである。
図１３は、AISデータ処理の処理手順を示すフローチャートである。船舶状態レコード作成(ステップＳ１)、進入時における通知状態レコード作成(ステップＳ２)、警報発令時における通知状態レコード作成(ステップＳ３)という一連の手順を実行するというものである。
船舶状態レコードの作成において、現在地IDから取得日時に最も近い過去日時の気象状態レコードを取得し(ステップＳ４)、船舶状態レコードを作成する(ステップＳ５)。
船舶状態レコードの作成において、現在地IDから取得日時に最も近い過去日時の気象状態レコードを取得し(ステップＳ４)、船舶状態レコードを作成する(ステップＳ５)。
ステップＳ２の通知状態レコード作成について説明する。ステップＳ６において、進入を表す最新の通知状態レコード(２４時間以内のもの)を取得し、船舶状態レコードにおける現在地IDと、通知状態レコードにおける通知内容IDとを比較する(ステップＳ７)。
警報内容IDに対応する警報のElementary Bufferには、警報地域である領域のIDが含まれているので、これを海象Ｒの現在地IDと比較することにより、海象Ｒにおける現在地が、通知状態レコードで通知された警報領域に存在するかどうかを本ステップで判断することになる。もし異なるか存在しない場合、ステップＳ８において、通知条件テーブルを検索し、該当する通知条件テーブルが存在する場合、ステップＳ１０〜ステップＳ１６の処理をスキップする。該当する通知条件テーブルが存在しない場合、進入データとして、通知済みの通知状態レコードを作成する(ステップＳ１０)。船舶IDに対応するワークグループ配下のユーザIDを取得する(ステップＳ１１)。その後、対象ユーザ分だけ、進入データとなる通知状態明細レコードを作成する(ステップＳ１２)。ステップＳ１３では、メール送信の要否を判定する。メール送信要であれば、ステップＳ１５において送信用保持クラスに設定して、メール編集処理を実行する。ステップＳ１４では、メッセージ送信の要否を判定する。メッセージ送信要であれば、ステップＳ１６において送信用保持クラスに設定して、メッセージ編集処理を実行する。かかる編集処理を経て、メール、メッセージが作成されるから、以降、送信に供されることになる。以上がAIS情報受信処理についての説明である。
警報内容IDに対応する警報のElementary Bufferには、警報地域である領域のIDが含まれているので、これを海象Ｒの現在地IDと比較することにより、海象Ｒにおける現在地が、通知状態レコードで通知された警報領域に存在するかどうかを本ステップで判断することになる。もし異なるか存在しない場合、ステップＳ８において、通知条件テーブルを検索し、該当する通知条件テーブルが存在する場合、ステップＳ１０〜ステップＳ１６の処理をスキップする。該当する通知条件テーブルが存在しない場合、進入データとして、通知済みの通知状態レコードを作成する(ステップＳ１０)。船舶IDに対応するワークグループ配下のユーザIDを取得する(ステップＳ１１)。その後、対象ユーザ分だけ、進入データとなる通知状態明細レコードを作成する(ステップＳ１２)。ステップＳ１３では、メール送信の要否を判定する。メール送信要であれば、ステップＳ１５において送信用保持クラスに設定して、メール編集処理を実行する。ステップＳ１４では、メッセージ送信の要否を判定する。メッセージ送信要であれば、ステップＳ１６において送信用保持クラスに設定して、メッセージ編集処理を実行する。かかる編集処理を経て、メール、メッセージが作成されるから、以降、送信に供されることになる。以上がAIS情報受信処理についての説明である。
１４.気象データ取得
サーバによる気象協会サーバからの気象データ取得処理は以下の通りである。タイマーを停止し、気象協会サーバにおける監視対象のフォルダに未処理のファイルが存在するかどうかをチェックする。未処理のファイルがあればリレーショナルデータベースに取り込む。また監視フォルダに未処理の画像ファイルがないかどうかを判定する。未処理の画像ファイルがあれば管理のためのテーブルに登録する。ここで、１ファイルで詳細海域分を作成する。地方海上警報が複数発令されている場合、同一海域で地方海上警報が発生していることがあるので、アップデートにより地方海上警報電文の追記を行う。
サーバによる気象協会サーバからの気象データ取得処理は以下の通りである。タイマーを停止し、気象協会サーバにおける監視対象のフォルダに未処理のファイルが存在するかどうかをチェックする。未処理のファイルがあればリレーショナルデータベースに取り込む。また監視フォルダに未処理の画像ファイルがないかどうかを判定する。未処理の画像ファイルがあれば管理のためのテーブルに登録する。ここで、１ファイルで詳細海域分を作成する。地方海上警報が複数発令されている場合、同一海域で地方海上警報が発生していることがあるので、アップデートにより地方海上警報電文の追記を行う。
地方海上警報電文の解析／登録は以下の通りである。気象協会サーバからテキストファイルの取得を試み、取得できればテキストファイルを読み込む。そして読み込んだファイルにおける個々のセンテンスの解析を行い、テキストファイルをクローズする。
１４.（ａ）地方海上警報電文
地方海上警報電文について説明する。地方海上警報電文は、気象サーバから送信される。地方海上警報電文は、テキストデータであり、スペースコードで区切られた複数のセンテンスからなる。図１４（ａ）は、テキストデータである地方海上警報電文を示す。地方海上警報電文とは、ある海域を対象とした漢字電文警報のことであり、サーバから一個のファイルとして供給される。サーバから供給されるファイルには、以下のフォーマットのテキストデータが1つ以上包含されている。
１４.（ａ）地方海上警報電文
地方海上警報電文について説明する。地方海上警報電文は、気象サーバから送信される。地方海上警報電文は、テキストデータであり、スペースコードで区切られた複数のセンテンスからなる。図１４（ａ）は、テキストデータである地方海上警報電文を示す。地方海上警報電文とは、ある海域を対象とした漢字電文警報のことであり、サーバから一個のファイルとして供給される。サーバから供給されるファイルには、以下のフォーマットのテキストデータが1つ以上包含されている。
具体的にいうと、行番号１のカナ名称、行番号２の空行、行番号３の発令元、行番号４の観測日時−発表日時、行番号５の空行、行番号６の警報注意報−対象地域、行番号a(=10)の空行、行番号b(=11)の発令内容、行番号c(=12)の空行、行番号d(=13)の対象期間、行番号e(=14)の空行から構成される。
１４.（ａ）.１ 地方海上警報電文の解析
この図１４（ａ）の地方海上警報電文を解析して気象状態レコードを作成する。地方海上警報電文の解析処理は以下のようになされる。地方海上警報電文のうち発令元についてはそのまま取得する。地方海上警報電文のうち観測日時、発表日時については、日付・時間にファイル名の基準日時を足し合わせる。
１４.（ａ）.１ 地方海上警報電文の解析
この図１４（ａ）の地方海上警報電文を解析して気象状態レコードを作成する。地方海上警報電文の解析処理は以下のようになされる。地方海上警報電文のうち発令元についてはそのまま取得する。地方海上警報電文のうち観測日時、発表日時については、日付・時間にファイル名の基準日時を足し合わせる。
警報注意報、対象地域については半角スペースで、センテンス分割を行い、分割で得られた小センテンスを複数の配列要素[0][1]・・・・[n]のそれぞれに格納する。ここで、配列[0]には警報名を、配列[n]には対象地域を格納する。ここで対象地域は、海域の場合と、詳細海域の場合とがある。海域の場合は配下の詳細海域分のデータを作成せねばならない。この配下の詳細海域分のデータの求め方としては、対象海域の座標に重なっている詳細海域が配下とするという方式で、海域と詳細海域との対応をとってゆく。以上の処理を、対象地域が空行になるまで繰り返す。
１４.（ｂ）.気象状態レコード
この地方海上警報電文が発令された際、この地方海上警報電文本文は、気象状態レコードのフィールドとなる。図１４（ｂ）は、気象状態レコードのデータ構造を示す。気象状態レコードは、図１４（ｂ）に示すように、領域マスタ(m#area)、領域ID(area#id)、取得日付(acquisition#date)、取得時刻(acquisition#time)、天候ID(weather#id)、風力(wind#power)、波高(wave#height)、警報情報(warning#info)、注意報情報(advisory#info)、気象情報詳細(weather#info#detail)、発令区分(announce#kbn)、発令元(announce#origin)、観測日時(observation#date)、有効期限(expiration#date)から構成され、図１４（ａ）に示した地方海上警報電文は、警報電文、注意報情報として気象状態（海情報）の一部として組込まれ、検索に供される。
この地方海上警報電文が発令された際、この地方海上警報電文本文は、気象状態レコードのフィールドとなる。図１４（ｂ）は、気象状態レコードのデータ構造を示す。気象状態レコードは、図１４（ｂ）に示すように、領域マスタ(m#area)、領域ID(area#id)、取得日付(acquisition#date)、取得時刻(acquisition#time)、天候ID(weather#id)、風力(wind#power)、波高(wave#height)、警報情報(warning#info)、注意報情報(advisory#info)、気象情報詳細(weather#info#detail)、発令区分(announce#kbn)、発令元(announce#origin)、観測日時(observation#date)、有効期限(expiration#date)から構成され、図１４（ａ）に示した地方海上警報電文は、警報電文、注意報情報として気象状態（海情報）の一部として組込まれ、検索に供される。
１４.２ 詳細情報の構成
上記警報電文の情報要素のうち、発令元、観測日時、発表日時、警報注意報、対象地域、発令内容といった情報要素は、詳細情報の構成要素となる。詳細情報とは、警報電文の情報要素であって、警報発令時において、ユーザの操作に基づきポップアップ表示がなされるものをいう。ポップアップ表示は、船舶クライアント装置３にて、ユーザ操作ではなく自動受信した警報情報の内容により自動的に行われる。船上クライアントにてポップアップ表示がなされ、そのポップアップをクリックすることにより警報情報についての充分な確認がなされたと推定できる。
上記警報電文の情報要素のうち、発令元、観測日時、発表日時、警報注意報、対象地域、発令内容といった情報要素は、詳細情報の構成要素となる。詳細情報とは、警報電文の情報要素であって、警報発令時において、ユーザの操作に基づきポップアップ表示がなされるものをいう。ポップアップ表示は、船舶クライアント装置３にて、ユーザ操作ではなく自動受信した警報情報の内容により自動的に行われる。船上クライアントにてポップアップ表示がなされ、そのポップアップをクリックすることにより警報情報についての充分な確認がなされたと推定できる。
１５.警報電文による警報発令時の処理手順
続いて、警報電文による警報発令時の詳細について説明する。上述したように、気象状態レコードが、船舶状態レコードと関連付けられているから、発令日時に最も近い気象状態レコードと同じ領域IDをもつ船舶状態レコードを探し出せば、その船舶状態レコードに基づき、発令を通知すべきユーザを見つけることができる。
続いて、警報電文による警報発令時の詳細について説明する。上述したように、気象状態レコードが、船舶状態レコードと関連付けられているから、発令日時に最も近い気象状態レコードと同じ領域IDをもつ船舶状態レコードを探し出せば、その船舶状態レコードに基づき、発令を通知すべきユーザを見つけることができる。
安全管理システム外部のサーバによって地方海上警報が送信された場合、この送信に対応して以下の処理を実行する。
i)安全管理システム外部の気象協会サーバによって地方海上警報が送信された場合、この地方海上警報に対応する気象状態レコードを作成してデータベースに書き込み、作成した気象状態レコードに示される領域、日時、船舶IDを検索条件として、複数の船舶状態レコードに対する検索処理を行う。
i)安全管理システム外部の気象協会サーバによって地方海上警報が送信された場合、この地方海上警報に対応する気象状態レコードを作成してデータベースに書き込み、作成した気象状態レコードに示される領域、日時、船舶IDを検索条件として、複数の船舶状態レコードに対する検索処理を行う。
ii)検索条件に合致する船舶状態レコードが存在する場合、新たに作成された気象状態レコードと、その1つ前に作成された気象状態レコードとを用いて地方海上警報の発令区分に応じた通知状態レコードを作成してデータベースに書き込み、通知状態レコードを基にグループ配下のユーザについての通知状態明細レコードの作成を行ってデータベースに書き込む。
上記の過程において、各ユーザに対する通知を実行するため、サーバは以下の処理を行う。船舶IDを用いてデータベースにおけるマスタファイルを検索することで、船舶を管理するワークグループと、そのグループ配下のユーザとを探し出して、探し出されたユーザについての情報を、通知状態レコードと対応付けることにより、通知状態明細レコードを作成し、また探し出されたユーザのアドレスをマスタファイルから取得し、Webサーバは、マスタファイルから取得したアドレスを宛て先として、メール又はメッセージを送信することで警報発令の通知を行う。
図１５は、地方海上警報電文による警報発令時における通知状態作成処理の処理手順を示すフローチャートである。この通知状態レコードの作成は、更新があったかどうかを考慮する。「更新」とは、通知状態レコードの作成時において、発令分類は直前の通知状態レコードと同一であるが、発令内容が前回の通知状態レコードとは異なっていることをいう。通知状態レコードの更新時において直前の通知状態レコードから変化した項目が通知条件テーブルにて設定されている項目であれば、その更新データに基づき、ユーザへの通知がなされる。しかし、更新された通知状態レコードにおいて直前の通知状態レコードから変化した項目が通知条件テーブルにて設定されている項目でなければ、その更新データである通知状態レコードに基づき、ユーザへの通知がなされる。例えば、波浪が通知項目として通知条件テーブルに設定されているが、大雨、濃霧が通知項目として通知条件テーブルに設定されていないケースを想定する。そして、直前の通知状態レコードの通知分類が波浪であり、新たな通知状態レコードの通知内容が波浪、大雨、濃霧であると、この場合、大雨、濃霧は通知の対象外であるから、更新データに基づく地上ユーザ、船上ユーザに対する通知はなされない。
図１５のステップＳ２１では、取得日時が最も近い過去日時の気象状態レコードと関連する項目の検索条件で、船舶状態レコードを検索する。ここで検索条件としては、パーソナルコンピュータのコンフィグレーションファイルから取得した船舶ID、コンフィグレーションファイルから取得した取得日付＋取得時刻、作成された船舶状態レコードの気象領域ID、取得日付、領域時刻を用いる。
ステップＳ２２は、該当件数が2件以上かどうかの判定であり、２件以上であれば、ステップＳ２３〜ステップＳ３０をスキップする。該当件数が1件であれば、ステップＳ２３において、該当する気象状態レコードと、その1つ前の気象状態レコードとを取得し、ステップＳ２４において、警報−注意報用データ処理を実行する。
ステップＳ２５において、警報用の通知状態明細データの作成を行い、対象ユーザ分だけ、対象ユーザIDを取得する。ステップＳ２６では、船舶IDに対応するワークグループ配下のユーザ分の通知状態明細レコードを作成する。ステップＳ２７は、メール送信の要否判断である。
ステップＳ２５において、警報用の通知状態明細データの作成を行い、対象ユーザ分だけ、対象ユーザIDを取得する。ステップＳ２６では、船舶IDに対応するワークグループ配下のユーザ分の通知状態明細レコードを作成する。ステップＳ２７は、メール送信の要否判断である。
通知状態レコードが発令データである場合、通知条件テーブルにおける発令時メール送信が「送信」に設定されているかどうかでメール送信の要否を判断する。
通知状態レコードが更新データであり、その発令内容が、直前の発令内容から増加している場合(以下、更新(増加)時という)、通知条件テーブルにおける発令時メッセージ送信が「送信」に設定されているかどうかでメッセージ送信の要否を判断する。
通知状態レコードが更新データであり、その発令内容が、直前の発令内容から増加している場合(以下、更新(増加)時という)、通知条件テーブルにおける発令時メッセージ送信が「送信」に設定されているかどうかでメッセージ送信の要否を判断する。
通知状態レコードが更新データであり、その発令内容が、直前の発令内容から減少している場合(以下、更新(減少)時という)、通知条件テーブルにおける解除時メール送信が「送信」に設定されているかどうかでメッセージ送信の要否を判断する。
通知状態レコードが解除データである場合、通知条件テーブルにおける解除時メール送信が「送信」に設定されているかどうかでメール送信の要否を判断する。
通知状態レコードが解除データである場合、通知条件テーブルにおける解除時メール送信が「送信」に設定されているかどうかでメール送信の要否を判断する。
発令時メール送信要又は解除時メール送信要であれば、送信用保持クラスに設定して、メール編集処理を実行して、メールを作成し送信する(ステップＳ２８)。
ステップＳ２９は、メッセージ送信の要否判断である。
通知状態レコードが発令データである場合、通知条件テーブルにおける発令時メッセージ送信が「送信」に設定されているかどうかでメッセージ送信の要否を判断する。
ステップＳ２９は、メッセージ送信の要否判断である。
通知状態レコードが発令データである場合、通知条件テーブルにおける発令時メッセージ送信が「送信」に設定されているかどうかでメッセージ送信の要否を判断する。
通知状態レコードが更新データであり、その発令内容が、直前の発令内容から増加している場合(以下、更新(増加)時という)、通知条件テーブルにおける発令時メッセージ送信が「送信」に設定されているかどうかでメッセージ送信の要否を判断する。
通知状態レコードが更新データであり、その発令内容が、直前の発令内容から減少している場合(以下、更新(減少)時という)、通知条件テーブルにおける解除時メッセージ送信が「送信」に設定されているかどうかでメッセージ送信の要否を判断する。
通知状態レコードが更新データであり、その発令内容が、直前の発令内容から減少している場合(以下、更新(減少)時という)、通知条件テーブルにおける解除時メッセージ送信が「送信」に設定されているかどうかでメッセージ送信の要否を判断する。
通知状態レコードが解除データである場合、通知条件テーブルにおける解除時メッセージ送信が「送信」に設定されているかどうかでメッセージ送信の要否を判断する。
発令時メッセージ送信要又は解除時メッセージ送信要であれば、送信用保持クラスに設定して、メッセージ編集処理を実行して、メッセージを作成し送信する(ステップＳ２０)。
発令時メッセージ送信要又は解除時メッセージ送信要であれば、送信用保持クラスに設定して、メッセージ編集処理を実行して、メッセージを作成し送信する(ステップＳ２０)。
以上で、警報発令時における通知状態作成処理の処理手順について説明を終える。
１６.警報電文と、船舶位置情報とのマッチング
警報電文と、船舶位置情報とのマッチングとは、警報発令時における経過管理の基盤となる考えであり、このマッチング処理は、本実施形態において最も重要な考えである。以下、マッチングの具体的な処理手順について説明する。"マッチング"は、何れかの船舶から取得した最新のAIS情報の船舶コードと、同じ船舶コードが何れかの通知条件テーブルに設定されており、その通知条件テーブルに警報注意報発令が通知条件として設定されている場合、その警報注意報と同一の警報注意報を示す気象状態レコードをデータベースから探し出して、この気象状態レコードに対応する通知状態レコード、通知状態明細レコードを作成するという処理である。
１６.警報電文と、船舶位置情報とのマッチング
警報電文と、船舶位置情報とのマッチングとは、警報発令時における経過管理の基盤となる考えであり、このマッチング処理は、本実施形態において最も重要な考えである。以下、マッチングの具体的な処理手順について説明する。"マッチング"は、何れかの船舶から取得した最新のAIS情報の船舶コードと、同じ船舶コードが何れかの通知条件テーブルに設定されており、その通知条件テーブルに警報注意報発令が通知条件として設定されている場合、その警報注意報と同一の警報注意報を示す気象状態レコードをデータベースから探し出して、この気象状態レコードに対応する通知状態レコード、通知状態明細レコードを作成するという処理である。
ここで、通知条件テーブルにおける警報注意報に合致する気象状態レコードが存在する場合、直ちにユーザに警報注意報発令を通知するのではなく、直前に作成された気象状態レコードがどのような内容であったかに鑑みて、ユーザへの通知を行う必要がある。通知条件テーブルにおける警報注意報に合致する気象状態レコードと、その直前の気象状態レコードとが同じである場合、警報発令を通知することは、発令の頻度が高くなって発令に対する警戒感を薄れさせるからである。新たな気象状態レコードが検索された場合、その気象状態レコードにおける発令内容が、直前の気象状態レコードにおける発令内容と同じであればユーザに対する通知を行い、同じでなければ通知を行わない。つまり通知状態レコードが発令データ、解除データ、更新データの何れであるかに応じて、処理を変化させる必要がある。
「発令データ」とは、地方海上警報電文で示される津波、濃霧等が発生したことを示すイベントを通知するための通知状態レコードである。発令イベントが発生するのは、津波、濃霧が発生したその瞬間であり、津波、濃霧の発生継続中は、「発令」のイベントは発生せず通知状態レコードは作成されない。しかし、津波、濃霧等が止んで、その後、津波、濃霧等が再発した場合は、「発令」のイベントが発生することになるから、「発令」に対応する通知状態レコードである発令データが作成されることになる。
「解除データ」とは、地方海上警報電文で示される津波、濃霧等がなくなったことを示すイベントを通知するための通知状態レコードである。解除イベントが発生するのは、津波、濃霧がなくなったその瞬間であり、津波、濃霧の発生継続中は、「解除」のイベントは発生せず通知状態レコードは作成されない。しかし、津波、濃霧等が再発して、その後、再度津波、濃霧等がなくなった場合は、「解除」のイベントが発生することになるから、「解除」に対応する通知状態レコードである発令データが作成されることになる。
図１６は、発令内容に応じたデータ処理の処理手順を示すフローチャートである。ステップＳ３０において、発令区分の判定を行う。該当データが発令であり、前データが解除ならば発令データとする。該当データが発令であり、前データも発令で取得日付が有効期間外ならば発令データとする。該当データが発令であり、前データも発令で取得日付が有効期間内ならば更新データとする。該当データが解除であるなら、解除データとする。
発令データ時処理(ステップＳ３１)としては、通知条件テーブルの検索を繰り返す。つまり、ステップＳ３２において該当するデータの地方海上警報電文からコードマスタを参照して、通知内容IDを取得し、ステップＳ３３においてこの通知内容IDと一致する通知条件テーブルを取得した後、全警報、全注意報について通知条件テーブルの検索を繰り返す(ステップＳ３４〜ステップＳ３５)。
ここで、該当する場合は、ステップＳ３６において「通知済」で警報用の通知状態レコードを作成する。該当しない場合、「通知なし」で警報用の通知状態レコードを作成する。
更新データ時処理(ステップＳ３８)としては、該当するデータの地方海上警報電文からコードマスタを参照して、通知内容IDを取得し(ステップＳ３９)、この通知内容IDと一致する通知条件テーブルを取得して(ステップＳ４０)、通知条件テーブルの検索を増えた地方海上警報電文について繰り返す(ステップＳ４１〜ステップＳ４２）。ここで、該当する場合はその場で、該当あり「通知済み」で通知状態レコードを作成する(ステップＳ４３)。
更新データ時処理(ステップＳ３８)としては、該当するデータの地方海上警報電文からコードマスタを参照して、通知内容IDを取得し(ステップＳ３９)、この通知内容IDと一致する通知条件テーブルを取得して(ステップＳ４０)、通知条件テーブルの検索を増えた地方海上警報電文について繰り返す(ステップＳ４１〜ステップＳ４２）。ここで、該当する場合はその場で、該当あり「通知済み」で通知状態レコードを作成する(ステップＳ４３)。
解除データ時処理(ステップＳ５１)としては、ステップＳ５２において該当するデータの地方海上警報電文からコードマスタを参照して、通知内容IDを取得し、ステップＳ５３において、この通知内容IDと一致する通知条件テーブルを取得する。以上の取得を減った地方海上警報電文について繰り返す(ステップＳ５４−ステップＳ５５)。ここで、該当する場合はその場でステップＳ５６に移行し、ステップＳ５６において"該当あり"通知済みで通知状態レコードを作成する。"該当なし"の場合、「通知なし」で作成する。
以上が履歴更新についての説明である。
地方海上警報が発令されたか、地方海上警報が解除されたかは時々刻々と変化するから、地方海上警報が重ねて送信されたり、途中で地方海上警報が解除されることも有り得る。よって、本実施形態では、直前の状態と、現在の状態との組合せに応じて通知状態レコードを発令データ、解除データ、更新データの何れかに分類することにしている。
地方海上警報が発令されたか、地方海上警報が解除されたかは時々刻々と変化するから、地方海上警報が重ねて送信されたり、途中で地方海上警報が解除されることも有り得る。よって、本実施形態では、直前の状態と、現在の状態との組合せに応じて通知状態レコードを発令データ、解除データ、更新データの何れかに分類することにしている。
通知状態明細レコードの作成は地方海上警報発令時になされ、この際、メール・メッセージの送信がなされる。一方、ユーザから送信されるメール・メッセージは確認応答であるから、この受信に応じて、通知状態レコードにおける船舶の確認状態区分及び通知状態明細レコードにおける地上ユーザの確認状態区分を設定することになる。
１７.警報通知メールの送信
警報の発令時、又は、警報電文における発令内容の更新時において、かかる発令又は更新を通知するためユーザに送信されるメールを"警報通知メール"という。
１７.警報通知メールの送信
警報の発令時、又は、警報電文における発令内容の更新時において、かかる発令又は更新を通知するためユーザに送信されるメールを"警報通知メール"という。
図１７は、警報通知メールの送信手順を示すフローチャートである。本フローチャートでは、警報一致カウントという変数を使用する。「警報一致カウント」とは、地方海上警報が何回一致したかを示す変数である。ステップＳ６１〜ステップＳ６３のループは、ユーザリスト数の範囲でステップＳ６２を繰り返す。ステップＳ６２は、ユーザが管理する船舶を取得するものである。ステップＳ６３は、上記ループの終了条件を規定するものであり、通知状態レコードが解除データのみかを判定するものである。通知状態レコードが解除データのみでないなら、ステップＳ６３がNoになってステップＳ６４に移行し送信履歴の取得処理を行う。その後、ステップＳ６５〜ステップＳ６９のループに移行する。船舶IDが船舶IDの処理済み件数を下回る限り、ステップＳ６５〜Ｓ６９のループは継続する。ステップＳ６６は、船舶IDが一致する警報通知メールを取得し、ステップＳ６７は、履歴情報があり、尚且つ、船舶情報の警報内容が一致している警報通知メールが存在するかどうかの判定である。Noなら、ステップＳ６８に移行して警報通知メールをメッセージリストに追加する。YesならステップＳ６９において警報一致カウントをインクリメントした後、メッセージリストに追加する。
ステップＳ７０は、警報一致カウントがユーザ管理船舶数と一致するかどうかの判定であり、一致すれば、ステップＳ７１において、メッセージのテンプレートに値を設定することで、メール、メッセージの編集を行い、ステップＳ７２においてメール、メッセージの送信を行い、ステップＳ７３において送信履歴テーブルを更新する。
１８.携帯型のクライアント装置における船舶状況の表示
携帯型のクライアント装置においては、船舶毎に、船舶状態レコードに基づいて船舶の状況を表示することができる。以下、図１８を参照しながら個別船舶の状況について説明する。
１８.携帯型のクライアント装置における船舶状況の表示
携帯型のクライアント装置においては、船舶毎に、船舶状態レコードに基づいて船舶の状況を表示することができる。以下、図１８を参照しながら個別船舶の状況について説明する。
図１８（ａ）は、地方海上警報がない場合の個別船舶状況の画面を示す。地方海上警報がない場合、船舶状況におけるフィールド（目的地(千葉港)、ETA(2012年03月18日 16:00)、速度(5knot)、現在地(東京湾)、天候(晴れ)、風力(1m)、波高(0.5m)）が表示に供される。
図１８（ｂ）は、地方海上警報がある場合の個別船舶状況の画面を示す。地方海上警報がある場合、船舶状況におけるフィールド（目的地(四日市港)、ETA(2012年03月18日 18:10)、速度(5knot)、現在地(伊勢沖)、天候(曇り)、風力(8m)、波高(３m)）が表示に供される。この表示画面において、明細一覧の「詳細」ボタン押下された場合、通知内容詳細画面にリンクする。この際、メール、メッセージが送信され、ログインユーザ(地上ユーザ)の確認状態が確認済みとして更新される。
図１８（ｂ）は、地方海上警報がある場合の個別船舶状況の画面を示す。地方海上警報がある場合、船舶状況におけるフィールド（目的地(四日市港)、ETA(2012年03月18日 18:10)、速度(5knot)、現在地(伊勢沖)、天候(曇り)、風力(8m)、波高(３m)）が表示に供される。この表示画面において、明細一覧の「詳細」ボタン押下された場合、通知内容詳細画面にリンクする。この際、メール、メッセージが送信され、ログインユーザ(地上ユーザ)の確認状態が確認済みとして更新される。
図１８（ｃ）は、注意報がある場合の個別船舶状況の画面を示す。注意報がある場合、船舶状況におけるフィールド（目的地(水島港)、ETA(2012年03月18日21:50)、速度(10knot)、現在地(友ケ島水道)、天候(晴れ)、風力(0.5m)、波高(0m)）が表示に供される。
図１８（ｄ）は、通知内容詳細画面を示す。この画面は、図１８の画面における「詳細」ボタン押下時に表示されるものである。
図１８（ｄ）は、通知内容詳細画面を示す。この画面は、図１８の画面における「詳細」ボタン押下時に表示されるものである。
１９.確認応答メール、確認応答メッセージの受信手順
以上の画面が携帯電話に表示された後、携帯電話からは、確認応答を示すメール、メッセージが送信される。この確認応答メール、確認応答メッセージの受信手順は図１９に示す通りである。
図１９は、メール、メッセージの受信手順を示すフローチャートである。ステップＳ８１は、受信したメール、メッセージが確認応答であるか否かの判定であり、もしそうであれば、ステップＳ８２において、受信したメール、メッセージの通知分類ID、通知内容ID、ユーザIDに該当する項目をもつ通知状態明細レコードを検索する。ステップＳ８３は、該当する通知状態明細レコードが存在するかどうかの判定であり、もし存在するなら、ステップＳ８４において、受信したメール、メッセージに基づき、通知状態明細レコードの確認状態区分、通知状態確認日時を設定して処理を終了する。
以上の画面が携帯電話に表示された後、携帯電話からは、確認応答を示すメール、メッセージが送信される。この確認応答メール、確認応答メッセージの受信手順は図１９に示す通りである。
図１９は、メール、メッセージの受信手順を示すフローチャートである。ステップＳ８１は、受信したメール、メッセージが確認応答であるか否かの判定であり、もしそうであれば、ステップＳ８２において、受信したメール、メッセージの通知分類ID、通知内容ID、ユーザIDに該当する項目をもつ通知状態明細レコードを検索する。ステップＳ８３は、該当する通知状態明細レコードが存在するかどうかの判定であり、もし存在するなら、ステップＳ８４において、受信したメール、メッセージに基づき、通知状態明細レコードの確認状態区分、通知状態確認日時を設定して処理を終了する。
２０.（ａ）通知条件に一致する通知状態の全てを一覧表示
通知状態明細レコードは、管理者たるユーザについて作成されるものであるから、確認者を中心にした一覧表示も可能になる。図２０は、通知条件に一致する通知状態の全てを一覧表示に供する画面（通知状態機能画面）の一例を示す。本図における通知状態情報とは、１００件の検索結果のことであり、本図では、その上位１０件を示す。一件当りの検索結果である通知状態管理情報は、状態明細における取得日付−取得時刻(取得日時)、通知分類、通知内容に、通知日時、ユーザ毎の確認状態表示、確認日時を対応付けたものである。図２０（ａ）における確認状態表示は、通知状態レコードにおける船舶の確認状態と、地上ユーザによる確認状態とからなる。地上ユーザによる確認状態は、船舶(確認待ち、確認済み)、既読(○、×)、確認者(海運太郎、海運次郎、海運三郎といった氏名)、電話連絡者(海運太郎)の表示によってなされる。
通知状態明細レコードは、管理者たるユーザについて作成されるものであるから、確認者を中心にした一覧表示も可能になる。図２０は、通知条件に一致する通知状態の全てを一覧表示に供する画面（通知状態機能画面）の一例を示す。本図における通知状態情報とは、１００件の検索結果のことであり、本図では、その上位１０件を示す。一件当りの検索結果である通知状態管理情報は、状態明細における取得日付−取得時刻(取得日時)、通知分類、通知内容に、通知日時、ユーザ毎の確認状態表示、確認日時を対応付けたものである。図２０（ａ）における確認状態表示は、通知状態レコードにおける船舶の確認状態と、地上ユーザによる確認状態とからなる。地上ユーザによる確認状態は、船舶(確認待ち、確認済み)、既読(○、×)、確認者(海運太郎、海運次郎、海運三郎といった氏名)、電話連絡者(海運太郎)の表示によってなされる。
１件目の通知状態管理情報は、2012年04月01日 8:00:00という取得日時・通知日時で発生した警報注意報（暴風波浪警報、強風注意報）の確認状態（既読のステータスにすることが必要であり、確認者である海運太郎の確認を待っている状態）を示す。
３件目の通知状態管理情報は、2012年04月01日 14:00:00という取得日時・通知日時で発生した警報注意報（強風警報）の確認状態、つまり既読が必要であり、確認者である海運次郎の確認が2012年04月01日14:30:00に済んでいる状態を示す。
３件目の通知状態管理情報は、2012年04月01日 14:00:00という取得日時・通知日時で発生した警報注意報（強風警報）の確認状態、つまり既読が必要であり、確認者である海運次郎の確認が2012年04月01日14:30:00に済んでいる状態を示す。
図２０.（ａ）.１警報発令時における経過管理の具体例
図２０（ａ）の表示例を参照しながら、強風注意報発令時における経過について説明する。尚、図２０における日付けは、何れも2012年4月1日になっているから、この2012年4月1日における経過管理を説明の対象とする。
気象協会サーバ１０からの警報電文送信及び警報電文取得が3時間置きに行われているものとし、これらのうち、8:00に取得した警報電文が暴風波浪警報と、強風注意報とを含むものとしている。この8:00の暴風波浪警報及び強風注意報は警報発令の経過管理の契機になっている。そして8:00から3時間が経過した11:00に波浪警報、強風注意報がなされ、更に3時間が経過した14:00に強風警報がなされている。前の通知と比較すると、8:00における暴風波浪警報、強風注意報は、その直前の警報電文取得時にはなかったものだから、初めてのものである。11:00の波浪警報、強風注意報は、直前の8:00と比較して暴風警報が削除されたものだから、発令内容の減少を伴う警報注意報の更新があったものと捉えることができる。14:00の強風注意報は、直前の11:00の強風注意報と比較して警報の内容が波浪警報から強風警報に変化したものだから、警報の発令があったものと考えることができる。
図２０（ａ）の表示例を参照しながら、強風注意報発令時における経過について説明する。尚、図２０における日付けは、何れも2012年4月1日になっているから、この2012年4月1日における経過管理を説明の対象とする。
気象協会サーバ１０からの警報電文送信及び警報電文取得が3時間置きに行われているものとし、これらのうち、8:00に取得した警報電文が暴風波浪警報と、強風注意報とを含むものとしている。この8:00の暴風波浪警報及び強風注意報は警報発令の経過管理の契機になっている。そして8:00から3時間が経過した11:00に波浪警報、強風注意報がなされ、更に3時間が経過した14:00に強風警報がなされている。前の通知と比較すると、8:00における暴風波浪警報、強風注意報は、その直前の警報電文取得時にはなかったものだから、初めてのものである。11:00の波浪警報、強風注意報は、直前の8:00と比較して暴風警報が削除されたものだから、発令内容の減少を伴う警報注意報の更新があったものと捉えることができる。14:00の強風注意報は、直前の11:00の強風注意報と比較して警報の内容が波浪警報から強風警報に変化したものだから、警報の発令があったものと考えることができる。
8:00の強風注意報は発令であるから発令データである通知状態レコードと、対応する通知状態明細レコードとが作成される。11:00の強風注意報は更新(減少)であるから、更新(減少)データである通知状態レコードと、対応する通知状態明細レコードとが作成される。14:00の強風注意報は発令であるから発令データである通知状態レコードと、対応する通知状態明細レコードとが作成される。
8:00の暴風波浪警報、強風注意報は、地上ユーザ、船上ユーザに初めて知らされるものなので、船上クライアント装置３においては、警報音の鳴動がなされ、地上ユーザに対してはメール・メッセージの送信がなされる。8:00に対応する確認状態は、この鳴動及びメール・メッセージ送信に対応する内容になっている。つまり、確認者である海運太郎の確認によって既読による確認がなされ、また船舶における確認状態区分が確認待ちになっている。そしてこれらの確認日時として、8:30が記録されている。
11:00の警報注意報及び強風注意報は、暴風警報が解除されたという更新(解除)であり、通知条件テーブルにおいて、解除時メール送信、解除時メッセージ送信は「送信無」と設定されていると仮定すると、警報通知メールの送信はなされない。よって既読は「×」になっており、確認者による確認はなされていない。一方、船舶の確認状態区分も確認待ちになっている。
14:00における強風警報も初めて知らされるものなので、船上クライアント装置３においては、警報音の鳴動がなされ、地上ユーザに対してはメール・メッセージの送信がなされる。14:00に対応する確認状態は、この鳴動及びメール・メッセージ送信に対応する内容になっている。つまり、確認者である海運次郎によって既読による確認がなされ、また船舶における確認状態区分が確認済みになっている。そしてこれらの確認日時として、14:30が記録されている。
図２０（ａ）においては、11:00に得た千葉港、布良の海象について、地上ユーザ、船舶ユーザによる確認がどのようになされたかの確認経過を表示している。同様に、9:00における東京湾進入、15:00における伊勢沖進入について地上ユーザ、船舶ユーザによる確認がどのようになされたかの確認経過を表示している。海象については、地上ユーザによる既読がなされておらず、また船舶ユーザによる確認を待っている状態であることが示されている。
東京湾への進入については、確認者である海運次郎、電話連絡者である海運太郎による既読がなされ、船舶ユーザにおける確認がなされて、11:00という確認日時が記録されていることを示す。伊勢沖への進入については、既読がなされておらず、船舶ユーザにする通知の送信待ちになっていることを示す。
２０.（ｂ）注意報発令時における経過管理
注意報発令時における経過管理を説明する。ここで想定する時間的経過は17:00に波浪注意報がなされ、20:00に大雨波浪注意報が、23:00に濃霧波浪注意報がなされたというものである。図２０（ｂ）は、注意報発令についての通知条件テーブルにおける通知設定の一例を示し、図２０（ｃ）は、注意報発令の時間的経過を示す。ここで図２０（ｂ）の通知条件テーブルにおける通知設定は、波浪注意報の発令を通知するというものである。一方、図２０（ｃ）の時間的経過は、17:00に波浪注意報がなされ、20:00に大雨、波浪注意報が、23:00に濃霧波浪注意報が発令されたというものである。ここで図２０（ｂ）において、通知条件テーブルにおける通知設定は、「波浪注意報の発令を通知する」というものであるため、17:00の発令の段階で地上ユーザに対する通知がなされる。しかし、図２０（ｂ）において大雨注意報、濃霧注意報は通知設定の対象外であるから、通知条件テーブルの条件を具備せず注意報発令の通知はなされない。このように、通知を行うべき注意報の内容を通知条件テーブルで具体的に特定することにより、通知の頻度を低くすることができ、地上ユーザによる確認の手間を削減することができる。以上が経過管理についての説明である。
２０.（ｂ）注意報発令時における経過管理
注意報発令時における経過管理を説明する。ここで想定する時間的経過は17:00に波浪注意報がなされ、20:00に大雨波浪注意報が、23:00に濃霧波浪注意報がなされたというものである。図２０（ｂ）は、注意報発令についての通知条件テーブルにおける通知設定の一例を示し、図２０（ｃ）は、注意報発令の時間的経過を示す。ここで図２０（ｂ）の通知条件テーブルにおける通知設定は、波浪注意報の発令を通知するというものである。一方、図２０（ｃ）の時間的経過は、17:00に波浪注意報がなされ、20:00に大雨、波浪注意報が、23:00に濃霧波浪注意報が発令されたというものである。ここで図２０（ｂ）において、通知条件テーブルにおける通知設定は、「波浪注意報の発令を通知する」というものであるため、17:00の発令の段階で地上ユーザに対する通知がなされる。しかし、図２０（ｂ）において大雨注意報、濃霧注意報は通知設定の対象外であるから、通知条件テーブルの条件を具備せず注意報発令の通知はなされない。このように、通知を行うべき注意報の内容を通知条件テーブルで具体的に特定することにより、通知の頻度を低くすることができ、地上ユーザによる確認の手間を削減することができる。以上が経過管理についての説明である。
図２０（ａ）の表示画面において、明細一覧の「詳細」ボタン押下された場合、通知内容詳細画面にリンクする。この際、メール、メッセージが送信され、ログインユーザ(地上ユーザ)の確認状態が確認済みとして更新される。
２１.通知内容詳細画面の内容
図２１は、通知内容詳細画面を示す。この画面は、明細一覧の「詳細」ボタン押下時に表示されるものである。スクロールバー付きのウィンドゥw1は、確認者情報の一覧画面である。この確認者情報の一覧画面には、５件の確認者情報が示されており、個々の確認者情報は、確認者の氏名(海運太郎、次郎、三郎、四郎、五郎)と、確認日時(2012年04月01日)とを対応付け、確認ボタン、電話連絡確認日時、電話連絡完了ボタン、戻るボタンを配置したものである。電話連絡確認日時としては、初回表示時にシステム日付が表示され、既に日時が登録されていた場合、登録の日時を表す。
２１.通知内容詳細画面の内容
図２１は、通知内容詳細画面を示す。この画面は、明細一覧の「詳細」ボタン押下時に表示されるものである。スクロールバー付きのウィンドゥw1は、確認者情報の一覧画面である。この確認者情報の一覧画面には、５件の確認者情報が示されており、個々の確認者情報は、確認者の氏名(海運太郎、次郎、三郎、四郎、五郎)と、確認日時(2012年04月01日)とを対応付け、確認ボタン、電話連絡確認日時、電話連絡完了ボタン、戻るボタンを配置したものである。電話連絡確認日時としては、初回表示時にシステム日付が表示され、既に日時が登録されていた場合、登録の日時を表す。
図２１において確認ボタンの押下により安全管理規定上の会社側で確認した情報(確認状態、確認日時、確認者)が記録として通知状態レコードに登録される。
確認ボタンに加え電話連絡完了ボタンを押下すると、会社側で電話確認した情報(確認状態、確認日時、確認者)が記録として通知状態レコードに登録される。但し、登録を行えるのは、ワークグループマスタの警報メール送信メンバーに登録されているものに限られる。
確認ボタンに加え電話連絡完了ボタンを押下すると、会社側で電話確認した情報(確認状態、確認日時、確認者)が記録として通知状態レコードに登録される。但し、登録を行えるのは、ワークグループマスタの警報メール送信メンバーに登録されているものに限られる。
ウィンドゥw2は、この確認の対象となった通知内容の詳細を示す。本図においては、2012年4月15日09時観測され、2012年4月15日11時35分に発表された沖縄海上気象(沖縄南方海上の海上強風警報、東シナ海南部の地上風警報を含む)が通知内容の詳細として表示される。
以上のように本実施形態によれば、何れかの海域に海象又は気象についての警報が発令した場合、その警報発令海域に存在する船舶の管理として、船上ユーザ及び地上ユーザに対する警報発令通知が完了したか否か、船上ユーザ及び地上ユーザによる通知内容の確認が完了したか否かが通知状態レコード、通知状態明細レコードに残るから、これらの通知状態レコード、通知状態明細レコードで運航ログを構成することにより、ある船舶が遭遇した警報発令に関する事象のそれぞれについて、状態管理のログを船舶安全管理システム内に残すことができる。万が一、何れかの船舶に海難事故が発生したとしても、配船担当者や運航管理者が法定基準を遵守していたことの後日の立証が容易になり、海難事故について強固なリスクヘッジを実現することができる。また、船上ユーザに対する連絡が完了して、警戒航行行動を促したかどうか、地上ユーザによる連絡内容の確認が完了したか否かという状態管理のログがシステムに残ることから法定基準を遵守しようというモチベーションを高めることができ、海難事故の発生数を極力少なくすることができる。
以上のように本実施形態によれば、何れかの海域に海象又は気象についての警報が発令した場合、その警報発令海域に存在する船舶の管理として、船上ユーザ及び地上ユーザに対する警報発令通知が完了したか否か、船上ユーザ及び地上ユーザによる通知内容の確認が完了したか否かが通知状態レコード、通知状態明細レコードに残るから、これらの通知状態レコード、通知状態明細レコードで運航ログを構成することにより、ある船舶が遭遇した警報発令に関する事象のそれぞれについて、状態管理のログを船舶安全管理システム内に残すことができる。万が一、何れかの船舶に海難事故が発生したとしても、配船担当者や運航管理者が法定基準を遵守していたことの後日の立証が容易になり、海難事故について強固なリスクヘッジを実現することができる。また、船上ユーザに対する連絡が完了して、警戒航行行動を促したかどうか、地上ユーザによる連絡内容の確認が完了したか否かという状態管理のログがシステムに残ることから法定基準を遵守しようというモチベーションを高めることができ、海難事故の発生数を極力少なくすることができる。
(第２実施形態)
本実施形態は、船舶と船舶安全管理システムとの通信が不通になった際、この不通状態の履歴をどのように管理するかという改良に関する。第１実施形態に示したように、船舶安全管理システムとの通信には公衆無線LANのネットワークを採用しているから、船舶の位置が公衆無線LANのサービスエリアから外れた場合、船舶からのAIS情報の取得は不可能となる。この際、どのような挙動が発生するかというと、船舶のクライアント装置では、不通期間においてAIS情報が次々と作成されてゆき、船舶と、船舶安全管理システムとの通信が再開した際、それまで送信することができなかったAIS情報がまとめて送信されることになる。滞留していたAIS情報の一括送信という事態が想定されるので、本実施形態では、通知状態レコードを図２２のように改良する。
本実施形態は、船舶と船舶安全管理システムとの通信が不通になった際、この不通状態の履歴をどのように管理するかという改良に関する。第１実施形態に示したように、船舶安全管理システムとの通信には公衆無線LANのネットワークを採用しているから、船舶の位置が公衆無線LANのサービスエリアから外れた場合、船舶からのAIS情報の取得は不可能となる。この際、どのような挙動が発生するかというと、船舶のクライアント装置では、不通期間においてAIS情報が次々と作成されてゆき、船舶と、船舶安全管理システムとの通信が再開した際、それまで送信することができなかったAIS情報がまとめて送信されることになる。滞留していたAIS情報の一括送信という事態が想定されるので、本実施形態では、通知状態レコードを図２２のように改良する。
２２.通信状態フィールドを具備した通知状態レコード
図２２は、第２実施形態における通知状態レコードの内部構成を示す図である。（ａ）は通知状態レコード、（ｂ）は、通信状態の内容を示す。本図は、図９における通知状態レコードのデータ構造をベースとして作図されている。このベースとなる図９と図２２とが異なるのは、通知状態レコードのうち、AIS情報に対応するフィールドとして通信状態というフィールド、レコード区分というフィールドが存在しており、通信状態のフィールドに「ロスト期間中」か、「ロスト」か、「通常期間」かといった区別が表示される点である。またロスト状態が４８時間経過しているか否かをレコード区分フィールドに示している点である。ここでレコード区分フィールドが"1"ならば48時間の経過を示し、"0"ならば未経過を示す。このロスト期間中である場合、通知状態レコードにおける取得日付、取得時刻は空欄とする。「ロスト期間中」とは、前回のAIS情報の取得日時と、現在日時とが比較した場合に、予め定められた一定の時間以上の時間が経過しているものをいう。本実施形態では、この一定の時間として３時間を採用するが、この３時間という長さは目安であり、システムの運用実績を考慮して、この３時間を増減させることが望ましい。以上のように、船舶の「通信状態」は、通知状態レコードにフィールドを追加することで記録している。通信状態がロストと判定された時点で、船舶の最新の通知状態レコードの通信状態が通常である場合に限り、船舶コード、最新の船舶状態レコードの取得日時で通知状態レコードを作成する。以上が通知状態レコードについての改良である。続いて、通知状態レコード作成の改良について説明する。
図２２は、第２実施形態における通知状態レコードの内部構成を示す図である。（ａ）は通知状態レコード、（ｂ）は、通信状態の内容を示す。本図は、図９における通知状態レコードのデータ構造をベースとして作図されている。このベースとなる図９と図２２とが異なるのは、通知状態レコードのうち、AIS情報に対応するフィールドとして通信状態というフィールド、レコード区分というフィールドが存在しており、通信状態のフィールドに「ロスト期間中」か、「ロスト」か、「通常期間」かといった区別が表示される点である。またロスト状態が４８時間経過しているか否かをレコード区分フィールドに示している点である。ここでレコード区分フィールドが"1"ならば48時間の経過を示し、"0"ならば未経過を示す。このロスト期間中である場合、通知状態レコードにおける取得日付、取得時刻は空欄とする。「ロスト期間中」とは、前回のAIS情報の取得日時と、現在日時とが比較した場合に、予め定められた一定の時間以上の時間が経過しているものをいう。本実施形態では、この一定の時間として３時間を採用するが、この３時間という長さは目安であり、システムの運用実績を考慮して、この３時間を増減させることが望ましい。以上のように、船舶の「通信状態」は、通知状態レコードにフィールドを追加することで記録している。通信状態がロストと判定された時点で、船舶の最新の通知状態レコードの通信状態が通常である場合に限り、船舶コード、最新の船舶状態レコードの取得日時で通知状態レコードを作成する。以上が通知状態レコードについての改良である。続いて、通知状態レコード作成の改良について説明する。
２３.ロストの通信状態を通知状態レコードに設定するための設定手順
図２３は、ロストの通信状態を通知状態レコードに設定するための設定手順を示すフローチャートである。本フローチャートは、AISサーバのメイン処理開始時に実行されるものである。ロスト判定期間についてはアプリケーションコンフィグファイルに設定されている。ステップＳ１０１では初期化を行い、ステップＳ１０２において、ロストと判定される船舶の最新の船舶状態レコードを取得する。具体的には、船舶毎に、(最新取得日時＋ロスト判定時間)が経過している船舶状態レコードを取得する。
図２３は、ロストの通信状態を通知状態レコードに設定するための設定手順を示すフローチャートである。本フローチャートは、AISサーバのメイン処理開始時に実行されるものである。ロスト判定期間についてはアプリケーションコンフィグファイルに設定されている。ステップＳ１０１では初期化を行い、ステップＳ１０２において、ロストと判定される船舶の最新の船舶状態レコードを取得する。具体的には、船舶毎に、(最新取得日時＋ロスト判定時間)が経過している船舶状態レコードを取得する。
ステップＳ１０３では、取得レコード数が0以下かどうかの判定であり、0以下であれば、ステップＳ１１７において終了処理を実行する。もし0以下でないなら、ステップＳ１０４〜ステップＳ１１４のループを実行する。ステップＳ１０４は、ループの終了要件を規定するものであり、取得レコード数がレコード処理件数よりも大きいという条件を満たさなくなれば、ループを抜けてステップＳ１１５〜ステップＳ１１６に移行する。ステップＳ１１５は、登録カウントが0を上回るかどうかの判定であり、上回れば、ステップＳ１１６においてコミットを行う。ステップＳ１１５がNoなら、コミットを実行しない。ステップＳ１０４〜ステップＳ１１４からなるループは、船舶の通知状態レコードを取得して、ステップＳ１０６以降の処理を実行する。
ステップＳ１０６は、通信状態が「通常」かどうかの判定であり、通常でなければステップＳ１０７〜ステップＳ１１４をスキップする。通信状態が「通常」であれば、ステップＳ１０７〜ステップＳ１１４を実行する。ステップＳ１０７は、通信状態をロストとした通知状態レコードの登録であり、ステップＳ１０８は登録に成功したかどうかを判定する。成功すればステップＳ１０９において登録カウントをインクリメントする。成功しなければステップＳ１１０において警告ログを出力する。その後、ステップＳ１１１において、通知状態レコードに登録された船舶を管理するユーザ向けに、通知状態明細レコードへの登録、つまりロスト情報についての登録を行う。ステップＳ１１２では登録に成功したかどうかを判定する。ステップＳ１１３において成功すれば登録カウントをインクリメントする。成功しなければステップＳ１１４において警告ログを出力する。
以上が通信状態を「ロスト」に設定する際の設定手順についての説明である。続いて、「ロスト期間中」への設定の詳細について説明する。
２４.ロスト期間中の通信状態を通知状態レコードに設定するための設定手順
図２４は、「ロスト期間中」の通信状態を通知状態レコードに設定するための処理手順を示すフローチャートである。本フローチャートは、AISサーバによる通知データ作成処理の直前に実行される。ステップＳ１２１において、現在処理中の船舶AIS情報により、内部保持クラスの船舶コード、取得日付、取得日時を取得し、ステップＳ１２２において取得日時に対して日時変換を施す。具体的には、取得日時＋取得時刻という文字列連結を行う。ステップＳ１２３は、文字列からの日時型変換に成功したかどうかの判定であり、成功すればステップＳ１２４〜ステップＳ１２６を実行する。成功しなければステップＳ１２４〜ステップＳ１２６をスキップする。
２４.ロスト期間中の通信状態を通知状態レコードに設定するための設定手順
図２４は、「ロスト期間中」の通信状態を通知状態レコードに設定するための処理手順を示すフローチャートである。本フローチャートは、AISサーバによる通知データ作成処理の直前に実行される。ステップＳ１２１において、現在処理中の船舶AIS情報により、内部保持クラスの船舶コード、取得日付、取得日時を取得し、ステップＳ１２２において取得日時に対して日時変換を施す。具体的には、取得日時＋取得時刻という文字列連結を行う。ステップＳ１２３は、文字列からの日時型変換に成功したかどうかの判定であり、成功すればステップＳ１２４〜ステップＳ１２６を実行する。成功しなければステップＳ１２４〜ステップＳ１２６をスキップする。
ステップＳ１２４は、当日日時−取得日時≦ロスト判定期間という関係を満たすかどうかの判定である。もし満たせば、ステップＳ１２５において通信状態を『通常』とする。もし満たさなければステップＳ１２６において通信状態をロスト期間中とする。その後、ステップＳ１２７において終了を行う。
以下、具体例を挙げて説明する。例えば、取得時刻が13:05であり、現在時刻が20:00である場合、時間差は3時間以上であるから、その取得時刻に対応するAIS情報の通知状態レコードについては、通信状態が「ロスト期間中」に設定される。取得時刻が16:30であり、現在時刻が20:30である場合も、取得時間における時間差は3時間以上であるから、その取得時刻に対応するAIS情報の通知状態レコードについては、通信状態が「ロスト期間中」に設定される。取得時刻が19:00であり、現在時刻が21:00である場合、時間差は3時間以内であるから、その取得時刻に対応するAIS情報の通知状態レコードについては、通信状態は「通常状態」になる。
以下、具体例を挙げて説明する。例えば、取得時刻が13:05であり、現在時刻が20:00である場合、時間差は3時間以上であるから、その取得時刻に対応するAIS情報の通知状態レコードについては、通信状態が「ロスト期間中」に設定される。取得時刻が16:30であり、現在時刻が20:30である場合も、取得時間における時間差は3時間以上であるから、その取得時刻に対応するAIS情報の通知状態レコードについては、通信状態が「ロスト期間中」に設定される。取得時刻が19:00であり、現在時刻が21:00である場合、時間差は3時間以内であるから、その取得時刻に対応するAIS情報の通知状態レコードについては、通信状態は「通常状態」になる。
以上のように、受信したAIS情報が、３時間以上前に船舶で取得されたデータならば、通知状態レコードは、通信状態が"ロスト期間中"に設定される。これによりタイムラグを有しているものの、随時過去分から履歴が表示されてゆく。以上が通知状態レコード作成手順についての説明である。続いて、船舶状況一覧の詳細について説明する。
２５.船舶状況一覧画面
船舶状況一覧とは、AIS情報と、これに対応する日本気象協会情報の警報、確認状態を対応付けて、ソートした上表示するものである。図２５は、船舶状況一覧画面の一例を示す図である。
２５.船舶状況一覧画面
船舶状況一覧とは、AIS情報と、これに対応する日本気象協会情報の警報、確認状態を対応付けて、ソートした上表示するものである。図２５は、船舶状況一覧画面の一例を示す図である。
図２５における運航形態はソートの順序指定の１つである。順序設定としては、部門コードの昇順指定、船種コードの昇順指定、運航形態の昇順指定、船舶コードの昇順指定がある。
図２５においては、通信状態の導入に伴い、通知状態レコードの対象と"警報"のみとし、"注意報発令"や"船舶進入"は通知状態レコードの対象外としている。また通知状態レコードの対象を限定したため、本実施形態では、通知条件設定はなされないことにしている。
図２５においては、通信状態の導入に伴い、通知状態レコードの対象と"警報"のみとし、"注意報発令"や"船舶進入"は通知状態レコードの対象外としている。また通知状態レコードの対象を限定したため、本実施形態では、通知条件設定はなされないことにしている。
また船舶の運搬物の明確化の目的のため、"船種"の欄を追加している。船種としては、図２５に示すように"液安船"、"ケミカル船"、"貨物船"、"鋼材船"、"重油船"がある。これは、船舶状況の表示にあたって、その運搬物を明確にすることで、関係者の危機意識を高める狙いがある。
日本気象協会情報について説明する。日本気象協会情報は、"警報"と、"取得日時"とからなる。確認状態は、"船舶における確認状態"、"会社における確認状態"からなる。この画面で一覧表示されている複数船舶のうち、２行目の"かもめ"は、通信状態が"ロスト"に設定されているため、AIS情報における目的地、速度、日本気象協会情報における取得日時、警報、確認状態が何れも空欄になっている。
日本気象協会情報について説明する。日本気象協会情報は、"警報"と、"取得日時"とからなる。確認状態は、"船舶における確認状態"、"会社における確認状態"からなる。この画面で一覧表示されている複数船舶のうち、２行目の"かもめ"は、通信状態が"ロスト"に設定されているため、AIS情報における目的地、速度、日本気象協会情報における取得日時、警報、確認状態が何れも空欄になっている。
続いて、船舶状況一覧画面の上の2つのwarningについて説明する。
１行目のwarning表示は、確認状態が未確認である船舶が何隻存在するかという船舶隻数の表示を伴う。この未確認船舶の隻数表示にあたってサーチエンジンは、通知状態レコードにおける船舶確認状態が"未確認"であり、通知状態明細レコードにおける会社確認状態が"未確認"であり、通知状態レコードにおける通信状態が"ロストではない"という3つの条件の論理積を満たす船舶をデータベースからサーチして、これら船舶の件数をカウントする。そうして得られた船舶のカウント数をwarningと共に表示する。
１行目のwarning表示は、確認状態が未確認である船舶が何隻存在するかという船舶隻数の表示を伴う。この未確認船舶の隻数表示にあたってサーチエンジンは、通知状態レコードにおける船舶確認状態が"未確認"であり、通知状態明細レコードにおける会社確認状態が"未確認"であり、通知状態レコードにおける通信状態が"ロストではない"という3つの条件の論理積を満たす船舶をデータベースからサーチして、これら船舶の件数をカウントする。そうして得られた船舶のカウント数をwarningと共に表示する。
２行目のwarning表示は、ロスト状態が48時間以上経過している船舶が何隻存在するかという船舶隻数の表示を伴う。この船舶隻数表示にあたってサーチエンジンは、船舶状況レコードにおける通信状態が"ロスト"であり、最新のAIS情報の取得日時が現時刻から48時間を経過しているという2つの条件の論理積を満たす船舶をデータベースからサーチしてこれら船舶の件数をカウントする。そうして得られたカウント数をwarningと共に表示する。
以上が船舶状況一覧画面についての説明である。続いて、確認状態一覧画面の詳細について説明する。
２６.確認状態一覧画面
確認状態一覧画面とは、AIS情報と、これに対応する日本気象協会情報の警報、船舶の確認状態、会社の確認状態を対応付けて、ソートした上表示するものである。
２６.確認状態一覧画面
確認状態一覧画面とは、AIS情報と、これに対応する日本気象協会情報の警報、船舶の確認状態、会社の確認状態を対応付けて、ソートした上表示するものである。
図２５は、確認状態一覧画面の一例を示す。本画面では、横方向に"AIS情報"、"日本気象協会情報"、"船舶の確認状態"、"会社の確認状態"が存在する。"AIS情報"の表示爛は、"船種"、"船名"、"運航形態"、"現在地"、"通信状態"、"取得日時"、"目的地"、"ETA"から構成される。これらは図２２と同じである。日本気象協会情報も同じである。船舶の確認状態は、"確認状態"と、"確認日時"とによって表現されている。但し、確認状態一覧画面は、横方向の表示項目が多いため取得日時、確認日時の西暦表示、曜日表示、確認者の氏名の一部を省略して記載している。
会社の確認状態は、"確認状態"と、"確認日時"と、"確認者"と、"電話連絡日時"と、"電話連絡者"とによって表現されており、通知状態レコードと比較して項目が細分化されている。つまり図２６の確認状態一覧においては、AIS情報表示、日本気象協会情報表示は船舶状況一覧と同じになる。一方、船舶の確認状態、会社の確認状態は、詳細化されている。
図２６において、2012年10月12日の05:34にロストになり、2012年10月17日の14:05、17:00、18:00もロスト期間になっている。その後、2012年10月18日の13:09にはロスト期間が解除されている。これら05:34,14:05,17:00,18:00の取得日時においては、目的地、速度が空欄になっている。また船舶の確認状態、確認日時、会社の確認状態、確認日時も空欄になっている。以上のように、図２６の確認状態一覧では、滞留していたAIS情報、ロスト期間中への移行時期が示されているため、何時、ロスト期間中に突入したか、ロスト期間中船舶が何処に存在していたのかという経緯の把握が容易になる。
図２６の確認状態一覧画面においてもサーチエンジンによる船舶状態レコード、通知状態レコード、通知状態明細レコードに対するサーチは可能である。
図２６におけるサーチ仕様について説明する。初期設定としては、船舶情報取得日である当月の一日を指定し、確認状態を全件とする。検索条件として、日付はFrom-toの形式で指定する。船舶は、その位置のエリアで検索できるようにする。
図２６におけるサーチ仕様について説明する。初期設定としては、船舶情報取得日である当月の一日を指定し、確認状態を全件とする。検索条件として、日付はFrom-toの形式で指定する。船舶は、その位置のエリアで検索できるようにする。
図２５において通信状態がロスト期間中である場合、AIS情報表示においては、取得日時、目的地、速度、ETAは空欄になり、その直前にAIS情報を取得した日時が最新の取得日時になる。取得日時がそれ以降のAIS情報表示については、通信状態がロスト期間中として表示される。
図２６において会社状態、船舶状態の何れかが確認済みである場合、確認状態にカーソルをあてたとき、ツールチップを表示させる。未確認のときには表示させない。ツールチップでは、確認日時と、確認者とが表示されることになる。
図２６において会社状態、船舶状態の何れかが確認済みである場合、確認状態にカーソルをあてたとき、ツールチップを表示させる。未確認のときには表示させない。ツールチップでは、確認日時と、確認者とが表示されることになる。
続いて、確認状態一覧画面の上の2つのwarningについて説明する。
１行目のwarning表示は、確認状態が未確認である船舶が何隻存在するかという船舶隻数の表示を伴う。この未確認船舶の隻数表示にあたってサーチエンジンは、通信状態が"ロスト"又は"ロスト期間中でない"で、通知状態レコードにおける船舶確認状態が"未確認"であり、通知状態明細レコードにおける会社確認状態が"未確認"であるという3つの条件の論理積を満たす船舶をデータベースからサーチして、これら船舶の件数をカウントする。そうして得られた船舶のカウント数をwarningと共に表示する。
１行目のwarning表示は、確認状態が未確認である船舶が何隻存在するかという船舶隻数の表示を伴う。この未確認船舶の隻数表示にあたってサーチエンジンは、通信状態が"ロスト"又は"ロスト期間中でない"で、通知状態レコードにおける船舶確認状態が"未確認"であり、通知状態明細レコードにおける会社確認状態が"未確認"であるという3つの条件の論理積を満たす船舶をデータベースからサーチして、これら船舶の件数をカウントする。そうして得られた船舶のカウント数をwarningと共に表示する。
２行目のwarning表示は、ロスト状態が48時間以上経過している船舶が何隻存在するかという船舶隻数の表示を伴う。この船舶隻数表示にあたってサーチエンジンは、通知状態レコードにおける通信状態が"ロスト"であり、通知状態レコードにおけるレコード区分フィールドが「1(=48時間以上経過)」であるという2つの条件の論理積を満たす船舶をデータベースからサーチしてこれら船舶の件数をカウントする。そうして得られたカウント数をwarningと共に表示する。
２７.確認状態一覧の更新仮定
図２７は、通信不通状態が発生した場合における通知状態レコード作成の経過を模式的に示す図である。図中の(1)は、直前の取得から4時間が経過した後に取得されたAIS情報の受信を示す。かかる受信により、2012年10月17日20:00にAIS情報を取得した際の通知状態レコード、通知状態レコード、通知状態明細レコードがデータベースに追加されることになる。図中の(2)は、通信不通により滞留していたAIS情報の受信を示す。20:00の時点で船舶の通信が復帰した場合、古いAIS情報(16:05のAIS情報)から順次、アプリケーションサーバに送出され、処理される。その際、既に通知状態レコードには"ロスト"が設定されているため、これ以降作成される通知状態レコードの通信状態には、ロスト期間中と設定される。これは、現在日時との時間差が3時間以内になるまで続く。図中の(3)は、滞留していたAIS情報が取り込まれた際の通知状態レコード、通知状態明細レコードの追加を示す。これらのAIS情報に対応する通知状態レコード、通知状態明細レコードについては、通信状態がロスト期間に設定される。図中の(4)は、直前のAIS情報取得時点である13:00から3時間経過後、つまり、16:00における通知状態レコード、通知状態明細レコードの追加を示す。これにより、通信状態がロストであるAIS情報、船舶の確認状態情報、会社の確認状態情報が追加される。
図２７は、通信不通状態が発生した場合における通知状態レコード作成の経過を模式的に示す図である。図中の(1)は、直前の取得から4時間が経過した後に取得されたAIS情報の受信を示す。かかる受信により、2012年10月17日20:00にAIS情報を取得した際の通知状態レコード、通知状態レコード、通知状態明細レコードがデータベースに追加されることになる。図中の(2)は、通信不通により滞留していたAIS情報の受信を示す。20:00の時点で船舶の通信が復帰した場合、古いAIS情報(16:05のAIS情報)から順次、アプリケーションサーバに送出され、処理される。その際、既に通知状態レコードには"ロスト"が設定されているため、これ以降作成される通知状態レコードの通信状態には、ロスト期間中と設定される。これは、現在日時との時間差が3時間以内になるまで続く。図中の(3)は、滞留していたAIS情報が取り込まれた際の通知状態レコード、通知状態明細レコードの追加を示す。これらのAIS情報に対応する通知状態レコード、通知状態明細レコードについては、通信状態がロスト期間に設定される。図中の(4)は、直前のAIS情報取得時点である13:00から3時間経過後、つまり、16:00における通知状態レコード、通知状態明細レコードの追加を示す。これにより、通信状態がロストであるAIS情報、船舶の確認状態情報、会社の確認状態情報が追加される。
以上のように本実施形態によれば、船舶において通信不通期間が発生した場合、その期間経過後のAIS情報取得時に、船舶側で送信を滞留していたAIS情報をデータベースに記録し、これらの滞留分のAIS情報については、通信状態をロスト期間中とした通知状態レコードを作成するので、通信不通期間において、船舶がどういう航路をとったかを明確に把握することができる。
＜備考＞
以上の船舶安全管理システムのソフトウェアについて説明する。サーバOSとしては、WindowsServer2008 EnterPrise Edition（"Windows"は登録商標）に相当するソフトウェアを用いるのが望ましい。アプリケーションフレームワークとしては、ASP NET3.5に相当するソフトウェアを用いるのが望ましい。リレーショナルデータベースは、ORACLE（登録商標）、PostgreSQLを用いることが望ましい。AIS表示ソフトウェアとしては、アルファマップProが望ましい。
以上の船舶安全管理システムのソフトウェアについて説明する。サーバOSとしては、WindowsServer2008 EnterPrise Edition（"Windows"は登録商標）に相当するソフトウェアを用いるのが望ましい。アプリケーションフレームワークとしては、ASP NET3.5に相当するソフトウェアを用いるのが望ましい。リレーショナルデータベースは、ORACLE（登録商標）、PostgreSQLを用いることが望ましい。AIS表示ソフトウェアとしては、アルファマップProが望ましい。
本発明は、船舶による運輸業に利用することができる。
１ 地上クライアント装置
２ 携帯端末
３ 船上クライアント装置
４ WEBサーバ
５ データベースサーバ
６ アプリケーションサーバ
７ WEBサーバ
１０ 気象協会サーバ１０
２ 携帯端末
３ 船上クライアント装置
４ WEBサーバ
５ データベースサーバ
６ アプリケーションサーバ
７ WEBサーバ
１０ 気象協会サーバ１０
Claims (6)
- 船舶の船舶安全管理システムであって、
船舶の位置を取得する取得手段と、
海象又は気象についての警報発令を示す情報を受信する受信手段と、
警報時の運航経過を示すログを用いることで、船舶の動態管理を行う管理手段と、
船舶の運航に関与する船上ユーザ、及び、地上ユーザとの通信を行う通信手段とを備え、
前記通信手段は、
海象又は気象についての警報が発令され、尚且つ、管理対象となる船舶の中に警報発令海域を現在位置とするものが存在する場合、当該船舶の運航に関与する船上ユーザ及び地上ユーザに警報発令を通知すると共に、警報発令通知に対する確認応答を船上ユーザ及び地上ユーザから受信し、
前記管理手段は、
当該警報発令の通知がなされた日時、及び、警報発令通知に対する確認応答がなされた日時を運航ログに登録する
ことを特徴とする船舶安全管理システム。 - 警報時の運航経過を示すログは、通知状態レコードと、通知状態明細レコードとを用い表現されて、
前記通知状態レコードは、管理下にある船舶に対してどのような通知がなされたかを示すと共に、船上ユーザによる当該通知に対する確認状態のためのフィールドを有するテーブルであり、当該フィールドは初期値として確認待ちを示す値に設定され、
前記通知状態明細レコードは、通知状態レコードに示される通知に対する地上ユーザによる確認状態歴のためのフィールドを有するテーブルであり、当該フィールドは初期値として確認待ちを示す値に設定され、
前記船上ユーザによる確認状態の遷移は、警報発令通知に対する船上ユーザからの確認応答の受信時において通知状態レコードにおけるフィールドの値を更新して、確認済み状態を示させることでなされ、
前記地上ユーザによる確認状態の遷移は、警報発令通知に対する地上ユーザからの確認応答の受信時において、通知状態レコードにおけるフィールドの値を更新して、確認済み状態を示させることでなされ
前記船舶安全管理システムは、通知状態レコード、通知状態明細レコードを対象にしたサーチエンジンを備え、サーチエンジンは、ユーザからのキーワード入力を受け付けて、データベースに記憶されている複数の通知状態レコード、複数の通知状態明細レコードのうち、入力されたキーワードに合致するものを探し出し、キーワードに合致する通知状態レコード及び通知状態明細レコードを一覧表示に供する、請求項１記載の船舶安全管理システム。 - 前記データベースは、複数の気象状態レコードと、複数の通知条件データとを含み、
各気象状態レコードは、海上のある領域の気象状態を示すデータであり、その領域に対して発令されている警報の内容を含み、
各通知条件データは、ある船舶が航行する領域に対する警報の発令をユーザに通知するための条件を規定するデータであり、その条件は、その船舶に割り当てられた船舶コードと、通知対象の警報の類型を示す通知分類と、通知対象の警報の内容を示す通知内容とによって規定され、
何れかの船舶から取得した最新の位置情報が示す船舶コードが何れかの通知条件データに設定されており、かつ、その通知条件データに何らかの警報の内容が通知内容として設定されている場合、その警報の内容と同一の内容を含む気象状態レコードを前記データベースから探し出して、この気象状態レコードに対応する通知状態レコード、通知状態明細レコードを作成する
ことを特徴とする請求項２記載の船舶安全管理システム。 - 前記管理手段は、船舶の識別子を用いてデータベースにおけるマスタレコードを検索することで、船舶を管理するワークグループと、そのグループ配下のユーザとを探し出して、探し出されたユーザについての情報を、通知状態レコードと対応付けることにより、通知状態明細レコードを作成し、また探し出されたユーザのアドレスをマスタレコードから取得し、
前記通信手段は、マスタレコードから取得したアドレスを宛て先として、メール又はメッセージを送信することで警報発令の通知を行う
ことを特徴とする請求項１記載の船舶安全管理システム。 - 外部サーバから警報を受信した際、その警報に対応する気象状態レコードを作成して前記データベースに書き込み、その気象状態レコードが示す警報に応じて、その気象状態レコードが発令データであるか、更新データであるか、解除データであるかを判定して、
その気象状態レコードが発令データであれば、その気象状態レコードが示す全ての警報について、各警報を通知対象とする通知条件データを前記データベースから検索して、それらの通知条件データに基づき通知状態レコードを作成し、
その気象状態レコードが更新データであれば、その気象状態レコードが示す警報のうち、増減が発生したものについて、各警報を通知対象とする通知条件データを前記データベースから検索して、それらの通知条件データに基づき通知状態レコードを作成し、
その気象状態レコードが解除データであれば、その気象状態レコードが示す警報のうち、減少が発生したものについて、各警報を通知対象とする通知条件データを前記データベースから検索して、それらの通知条件データに基づき通知状態レコードを作成する
ことを特徴とする請求項３記載の船舶安全管理システム。 - 前記管理下にある船舶から位置情報を取得した際、位置情報の取得日時と、現在日時との差分を所定の時間差と比較して、所定の時間差を上回れば、直前の位置情報の取得日時から所定の時間が経過した時点の通知状態レコードとして通信状態が"ロスト"に設定された船舶状態レコードを作成し、その後、船舶側で滞留していた位置情報を受信して、滞留していた位置情報のそれぞれについて、通信状態を"ロスト期間中"とした通知状態レコードを作成し、
前記サーチエンジンにおいては、
"ロスト"又は"ロスト期間中"を示す通信状態が設定された通知状態レコードを一覧表示に供する
ことを特徴とする請求項２記載の船舶安全管理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012008729A JP5421398B2 (ja) | 2012-01-19 | 2012-01-19 | 船舶安全管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012008729A JP5421398B2 (ja) | 2012-01-19 | 2012-01-19 | 船舶安全管理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2013147131A JP2013147131A (ja) | 2013-08-01 |
| JP5421398B2 true JP5421398B2 (ja) | 2014-02-19 |
Family
ID=49045091
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012008729A Active JP5421398B2 (ja) | 2012-01-19 | 2012-01-19 | 船舶安全管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5421398B2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6178664B2 (ja) * | 2013-08-12 | 2017-08-09 | 株式会社ユー・エス・ジェイ | 遊戯用乗物の安全支援装置 |
| MX363499B (es) | 2014-07-16 | 2019-03-26 | Accuweather Inc | Sistema de deteccion de rayos, metodo y dispositivo. |
| WO2016039741A1 (en) | 2014-09-10 | 2016-03-17 | Accuweather, Inc. | Customizable weather analysis system |
| JP2016159854A (ja) * | 2015-03-04 | 2016-09-05 | ヤンマー株式会社 | 船舶 |
| WO2017210273A1 (en) | 2016-05-31 | 2017-12-07 | Accuweather, Inc. | Method and system for predicting the impact of forecasted weather, environmental and/or geologic conditions |
| KR101870271B1 (ko) * | 2016-06-02 | 2018-07-20 | 대우조선해양 주식회사 | 육상관제 시스템 및 데이터 구조와 그 운영 방법 |
| JP2017142856A (ja) * | 2017-05-02 | 2017-08-17 | アキュウェザー, インク.Accuweather, Inc. | カスタマイズ可能な気象分析システム |
| JP6326525B2 (ja) * | 2017-05-02 | 2018-05-16 | アキュウェザー, インク.Accuweather, Inc. | カスタマイズ可能な気象分析システム |
| JP2018152090A (ja) * | 2018-04-16 | 2018-09-27 | アキュウェザー, インク.Accuweather, Inc. | カスタマイズ可能な気象分析システム |
| JP2018190442A (ja) * | 2018-07-18 | 2018-11-29 | アキュウェザー, インク.Accuweather, Inc. | カスタマイズ可能な気象分析システム |
| CN113792108A (zh) * | 2021-09-17 | 2021-12-14 | 中远海运科技股份有限公司 | 一种基于时空数据的多维船舶搜索方法和系统 |
| CN115410366A (zh) * | 2022-07-22 | 2022-11-29 | 武汉光庭信息技术股份有限公司 | 交叉路口碰撞预警测试方法、系统、电子设备及存储介质 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4885759B2 (ja) * | 2007-02-15 | 2012-02-29 | 三井造船株式会社 | 船舶の情報処理方法及び船舶の情報処理システム |
| JP2010120561A (ja) * | 2008-11-21 | 2010-06-03 | Mitsubishi Heavy Ind Ltd | 船員位置記録システム及び船員位置記録方法 |
-
2012
- 2012-01-19 JP JP2012008729A patent/JP5421398B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2013147131A (ja) | 2013-08-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5421398B2 (ja) | 船舶安全管理システム | |
| US10691512B1 (en) | Notifying entities of relevant events | |
| US20210166143A1 (en) | Computer-Implemented Systems and Methods of Analyzing Spatial, Temporal and Contextual Elements of Data for Predictive Decision-Making | |
| US20210224701A1 (en) | Computer-implemented systems and methods of analyzing data in an ad-hoc network for predictive decision-making | |
| CN101252627B (zh) | 面向机场的应急救援车辆调度指挥系统 | |
| US20210081559A1 (en) | Managing roadway incidents | |
| US7058710B2 (en) | Collecting, analyzing, consolidating, delivering and utilizing data relating to a current event | |
| US8405501B2 (en) | Creating and monitoring alerts for a geographical area | |
| CN107615328A (zh) | 风险信息传输装置及风险信息传输方法 | |
| KR20080099311A (ko) | 네비게이션 시스템의 모바일 스테이션, 서버 및 동작 방법 | |
| US10642855B2 (en) | Utilizing satisified rules as input signals | |
| CN101657697A (zh) | 对点地址产生参考地理编码的系统、方法和计算机程序产品 | |
| US10846151B2 (en) | Notifying entities of relevant events removing private information | |
| US7933693B2 (en) | System and method for harvesting business intelligence from maritime communications | |
| CN105139606A (zh) | 一种低空飞行器信息交互系统 | |
| US11257176B1 (en) | Dynamic user interface of a sorting management system | |
| CN110874681B (zh) | 基于gis的石化企业应急资源管理与调度的方法 | |
| KR102536105B1 (ko) | 해상교통관제 이벤트 수집 관리 시스템 및 방법 | |
| US20220012651A1 (en) | Using randomness compensating factors to improve forecast accuracy | |
| JP2006031470A (ja) | 防災通報連絡方法及び防災通報連絡装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130516 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20131112 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131121 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5421398 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |