以下、図面を参照しつつ、本発明に従う各実施の形態について説明する。図中の同一または相当部分には同一符号を付してその説明は原則的には繰り返さないものとする。なお、以下で説明される各実施の形態および各変形例は、適宜選択的に組み合わされてもよい。
[実施の形態1]
図1は、実施の形態1に係る浸水報知システムが適用される船舶を模式的に示す図である。以下では、船舶に関して、船首と船尾とを結ぶ方向を「長さ方向」、右舷と左舷とを結ぶ方向を「幅方向」、長さ方向および幅方向の両方に直交する方向を「高さ方向」とも称する。高さ方向は、船舶の使用時において重力方向と概ね一致する。また、以下では、図1に示す船舶100に浸水報知システムが適用される例について主に説明するが、浸水報知システムが適用される船舶の種類は任意であり、貨物船であってもよいし、旅客船(たとえば、クルーズ船またはフェリー)であってもよい。
図1に示されるように、船舶100は、船首101と、船尾102と、上甲板103と、船底104とを含む。上甲板103上には、船橋105が設けられている。また、船橋105の後方(船尾102側)には、複数の乗員を収容可能な甲板室106が設けられている。甲板室106には、救命艇のような避難設備が収容されてもよい。船舶100は、船体の主要構造が鋼材で形成される鋼船である。
船舶100内には、隔壁によって区分された複数の区画が設けられている。以下、図2および図3を参照して、図1中に領域R100およびR200で示される部位の区画構造について説明する。なお、各区画内の設備については後述するため、図2および図3においては、区画内の設備の図示を割愛している。
図2は、図1中の領域R100で示される部位の区画マップを示す図である。図1中の領域R100で示される部位は、甲板室106直下の階層に位置し、船舶100内において乗員が居住するスペースに相当する。以下、領域R100で示される部位を、「居住スペース」とも称する。
図2に示すように、居住スペースの幅方向および長さ方向の各々は、隔壁によって仕切られている。居住スペースが隔壁で区画されることによって、部屋R1~R28と、通路V1~V8,V11,V12とが形成されている。図2に示される多数の扉のうち、扉D1~D9は水密扉に相当する。部屋R1~R28の各々は非水密区間である。一方で、通路V2,V7は水密可能に構成される。扉D1~D4を閉じることによって通路V2が水密区間になり、扉D7~D9を閉じることによって通路V7が水密区間になる。扉D1~D9の各々は、たとえばスライド式の水密扉である。扉D1~D9の各々は、扉の近傍に設けられた起動スイッチを乗員が押すことによって閉じるように構成される。また、扉D1~D9の各々は、後述する管理装置5(図5参照)によって遠隔操作可能に構成される。梯子Lは、甲板室106(図1)の床に設けられたハッチ(図示せず)につながっている。乗員は、梯子Lを登ってハッチを開けることで、甲板室106に入ることができる。なお、梯子Lの代わりに、階段が設けられていてもよい。
図2には示されていないが、居住スペースの高さ方向は甲板によって仕切られている。すなわち、居住スペースの天井および床は甲板で形成されている。居住スペースの天井を構成する甲板は、上甲板103(図1)に相当する。
図3は、図1中の領域R200で示される部位の区画マップを示す図である。領域R200で示される部位は、船底104に近い階層に位置し、複数の水密区間を含む。以下、領域R200で示される部位を、「水密スペース」とも称する。水密スペースに含まれる水密区間は、船艙であってもよいし、機関室であってもよい。
図3に示すように、水密区間S1~S6は、船舶100の幅方向および高さ方向の各々に並ぶように形成されている。水密区間S1~S6の高さ方向は、甲板Fによって仕切られている。水密区間S1~S6の幅方向は、隔壁BWによって仕切られている。図3には示されていないが、水密区間S1~S6の長さ方向も隔壁によって仕切られている。
図3に示す水密スペースにおいては、隣接する水密区間の境界にハッチH1~H9が設けられている。ハッチH1~H9の各々は水密ハッチに相当する。ハッチH1~H9の各々は、乗員によって開閉可能に構成される。ハッチH1~H9によって乗員の高さ方向の移動が可能になっている。ハッチH1~H9は、乗員が移動するとき以外は閉じた状態に維持される。なお、各水密区間の幅方向および長さ方向の少なくとも一方にハッチが設けられてもよい。
上記のように、船舶100(図1)内には、隔壁によって区分けされる複数の区画が存在する。たとえば、前述した部屋R1~R28(図2)と、通路V1~V8,V11,V12(図2)と、水密区間S1~S6(図3)との各々が、船舶100内の区画に相当する。以下では、区別して説明する場合を除いて、船舶100内の各区画を「区画B」と記載する。各区画Bを区分けする隔壁は、扉またはハッチのような開閉部を備えることがある。
以下、図4および図5を参照して、この実施の形態に係る浸水報知システムの構成について説明する。
図4は、各区画B内の設備を示す図である。図4において、区画B1およびB2は、乗員が自由に出入りできる区画である。区画B1と区画B2とは、隣り合うように配置され、隔壁BWによって隔てられている。区画B3は、予め許可を受けた乗員のみが出入りできる区画である。この実施の形態では、船橋105(図1)内の操舵室が区画B3に相当する。
図4に示すように、各区画Bは甲板F1,F2および隔壁BWによって区分けされている。甲板F1は区画B1~B3の天井を構成し、甲板F2は区画B1~B3の床を構成する。区画B1~B3の各々には、受信機3および監視カメラ4が設けられている。受信機3および監視カメラ4の各々は、甲板F1(すなわち、区画B1~B3の各々の天井)に設置されている。
船舶100内には、伝送媒体(たとえば、通信ケーブル)によってネットワークN1が形成されている。受信機3および監視カメラ4の各々は、ネットワークN1に接続されている。各受信機3および各監視カメラ4には、区画Bごとに固有の識別情報(以下、「区画ID」とも称する)が割り振られている。各受信機3および各監視カメラ4は、ネットワークN1に情報を送信するときに、自身が設置された区画Bを示す区画IDを一緒に送信するように構成される。船舶100内の受信機3および監視カメラ4の各々の数は、区画Bの数に対応する。船舶100における区画Bの数は任意であり、たとえば50個程度であってもよいし、100個以上であってもよい。
受信機3は、所定の受信範囲内に存在する第1携帯端末1が発信する識別信号(この実施の形態では、後述する乗員ID)を受信するように構成される。受信機3の受信範囲は、たとえば区画B内である。
監視カメラ4は、所定の監視範囲を監視するように構成される。監視カメラ4は、監視範囲の映像(より具体的には、映像に対応する電気信号)を取得するように構成される。監視カメラ4の監視範囲は、たとえば区画B内である。監視カメラ4は、浸水を検出するために使用される。さらに、他の災害(たとえば、火災)および不審者を検出するために、監視カメラ4を利用してもよい。
監視カメラ4はレンズおよびイメージセンサを含んで構成される。イメージセンサは結像面に配置され、レンズを通った光はイメージセンサによって映像に対応する電気信号に変換される。この実施の形態では、監視カメラ4が、魚眼レンズを備える魚眼カメラである。魚眼カメラを用いることで、広範囲の撮影(たとえば、360°全周囲撮影)が可能になる。魚眼カメラを天井に設置することで、浸水の状況を的確に表す映像を取得しやすくなる。
監視カメラ4は、浸水が発生したときに浸水の状況が分かる程度に鮮明な映像を取得可能に構成される。監視カメラ4が検出可能な電磁波の波長範囲は任意であるが、この実施の形態に係る監視カメラ4は、検出可能な波長範囲に可視光および赤外線を含むように構成される。監視カメラ4は暗視機能を有してもよい。監視カメラ4は、図示しない投光器(たとえば、可視光投光器および赤外線投光器)を備えてもよい。なお、区画Bの様態に応じてカメラの種類を変えてもよい。
区画B3には、管理装置5と、災害検出装置6とがさらに設けられている。管理装置5および災害検出装置6の各々は、ネットワークN1に接続されている。管理装置5は、船舶100内の各種センサおよび各種機器と通信可能に構成され、船舶100内で取得される各種の情報が管理装置5に集約されるようになっている。管理装置5は、操舵室内の乗員(たとえば、船長、または船長を補佐する乗員)によって操作され、船舶100内の設備を制御するように構成される。
災害検出装置6は、画像認識装置(たとえば、画像認識用のプログラムおよび回路を含む装置)を搭載したコンピュータによって構成される。各区画Bに設置された監視カメラ4によって取得される映像(以下、「カメラ映像」とも称する)は、各監視カメラ4から災害検出装置6へ逐次送信される。この際、カメラ映像は、そのカメラ映像が取得された区画Bを示す区画ID(すなわち、カメラ映像を取得した監視カメラ4の区画ID)と一緒に災害検出装置6へ送信される。災害検出装置6は、監視カメラ4の映像を用いて浸水が発生しているか否かを区画Bごとに判断するように構成される。
災害検出装置6は、たとえば公知の画像認識技術を利用してカメラ映像中の水面を特定し、水面の高さ(水位)が所定レベルを超えたか否かに基づいて浸水の有無を判断することができる。水位の検出を容易にするため、各区画B内に高さの指標(たとえば、量水板)を設置してもよい。なお、カメラ映像に基づいて浸水の有無を判断する手法は任意である。たとえば、予め用意した浸水発生時の映像とリアルタイムのカメラ映像とを比較することによって、浸水の有無を判断してもよい。
災害検出装置6は、浸水を検出すると、浸水を検出した旨を示す信号(以下、「浸水検出信号」とも称する)と、浸水を検出した監視カメラ4の区画IDとを、ネットワークN1を通じて管理装置5へ送信するように構成される。監視カメラ4によって浸水が検出されたことは、その監視カメラ4が設置された区画Bで浸水が発生していることを意味する。管理装置5は、災害検出装置6から浸水検出信号を受信することによって、浸水が発生したことを認識することができる。また、管理装置5は、浸水を検出した監視カメラ4の区画IDを用いて、浸水発生場所を特定することができる。
この実施の形態に係る浸水報知システムは、複数の第1携帯端末1と、複数の第2携帯端末2とを含む。第1携帯端末1および第2携帯端末2の各々は乗員ごとに携帯される。たとえば図4の例では、乗員U1~U3の各々が、第1携帯端末1を左手首に装着し、第2携帯端末2を右手に持っている。各第1携帯端末1および各第2携帯端末2には、乗員ごとに固有の識別情報(以下、「乗員ID」とも称する)が割り振られている。第1携帯端末1および第2携帯端末2の各々の数は、乗員の数に対応する。浸水報知システムにおける乗員の数は任意であり、たとえば5人程度の少人数であってもよいし、10人以上であってもよい。
第1携帯端末1は、乗員の身体に装着可能な通信端末(以下、「ウェアラブル端末」とも称する)である。すなわち、第1携帯端末1は、身体に装着された状態で乗員に携帯される。この実施の形態では、第1携帯端末1として、腕時計型のウェアラブル端末を採用する。しかしこれに限られず、第1携帯端末1は、衣服の一部に埋め込まれるタイプのウェアラブル端末であってもよいし、皮膚に貼り付けられるタイプのウェアラブル端末であってもよいし、メガネ型のウェアラブル端末であってもよい。
第2携帯端末2は、乗員が携帯して持ち運び可能な通信端末である。この実施の形態では、第2携帯端末2として、スマートフォンを採用する。しかしこれに限られず、第2携帯端末2は、他の携帯端末(たとえば、タブレット端末、または携帯型ゲーム機)であってもよい。
図5は、この実施の形態に係る浸水報知システムにおいて構築される通信ネットワークを示す図である。
図5に示すように、船舶100内には、無線LAN(Local Area Network)(以下「ネットワークN2」とも称する)が構築されている。第2携帯端末2および管理装置5の各々は、ネットワークN2に接続可能に構成される。船舶100は、ネットワークN2に接続可能な機器111、112、および113をさらに備える。機器111、112、および113の各々は、船舶100内で使用される機器であり、衛星通信機器を介してインターネットにアクセス可能なコンピュータであってもよいし、検出結果を管理装置5へ送信するセンサであってもよい。第2携帯端末2、管理装置5、機器111、機器112、および機器113は、ネットワークN2を通じて相互に無線通信可能に構成される。この実施の形態では、ネットワークN2を利用した通信C3がWiFi(登録商標)方式で行なわれる。
第1携帯端末1は、本体11と、ベルト12と、留め具13(たとえば、バックル)とを備える。本体11は、表示部11aと、操作部11bとを含む。ベルト12は本体11に接続されている。乗員は、手首にベルト12を巻いて留め具13でベルト12を留めることによって、第1携帯端末1を装着できる。第1携帯端末1は、防水構造を有し、水中でも使用可能な程度の防水性を有する。
第1携帯端末1の本体11は、発信機14、生体センサ15、および浸水センサ16を内蔵する。第1携帯端末1(ひいては、発信機14)が受信機3の受信範囲内に存在するときには、発信機14から発信される信号が受信機3に受信される。この実施の形態では、発信機14と受信機3との間の通信C1がBLE(Bluetooth(登録商標) Low Energy)方式で行なわれる。発信機14はBLE通信モジュールである。発信機14は、BLE規格のアドバタイズパケット(以下、「Aパケット」と表記する)を生成し、生成したAパケットを所定周期で無線送信する。所定周期は、BLE規格で定められており、20ms~10.24sの範囲で0.625msの整数倍である。発信機14は、たとえば約1sごとにAパケットを送信する。発信機14は、予め定められた送信強度でAパケットを送信する。送信強度は、固定値であってもよいし、状況に応じて可変であってもよい。たとえば、浸水センサ16が浸水を検知したときに発信機14の送信強度が強くなるようにしてもよい。また、ユーザが操作部11bを操作することによって、発信機14の送信強度を変更できるようにしてもよい。発信機14の送信電力を大きくするほど、発信機14の送信強度は強くなる。
生体センサ15は、第1携帯端末1を装着した乗員の生体情報(たとえば、脈拍、心拍、および体温)を取得するように構成される。生体センサ15は、乗員の脈拍、心拍、および体温の各々の検出値を出力してもよいし、これらの検出値を用いて評価した乗員の健康状態(たとえば、良い/普通/悪い/危険のような評価結果)を出力してもよい。生体センサ15の出力は、上記のAパケットに含まれる。なお、第1携帯端末1としてメガネ型のウェアラブル端末を採用する構成では、生体センサ15が、乗員の眼球の状態から乗員の心身に関する情報を収集するように構成されてもよい。
浸水センサ16は、浸水を検知するように構成される。浸水センサ16としては、公知の浸水検知器を採用できる。浸水センサ16の検知方式は任意であり、浸水によって電極間が通電することを利用した方式であってもよいし、水に反応して膨らむ膨張材を用いた方式であってもよい。浸水センサ16の出力(すなわち、浸水の有無を示す信号)は、上記のAパケットに含まれる。
上記のように、第1携帯端末1から発信されるAパケットには、前述した乗員IDのほかに、生体センサ15および浸水センサ16の各々によって取得される情報が含まれる。受信機3は、受信範囲内に存在する第1携帯端末1からAパケットを受信すると、Aパケットの受信強度を示す受信強度情報と、受信時刻を示す受信時刻情報と、自身が設置された区画Bを示す区画IDとをAパケットに付加して、これらの情報が付加されたAパケットをネットワークN1を通じて管理装置5へ送信する。
第2携帯端末2は、表示部21と、音入出力部22と、操作部23とを含む。表示部21は、たとえばタッチパネルディスプレイである。音入出力部22は、スピーカおよび集音マイクを含む。操作部23はカーソルキー(矢印ボタン)およびボタンを含む。ユーザは、操作部23を操作して、画面の切替え(ホーム画面/戻る/進む)、カーソルの移動、および決定を示す入力を行なうことができる。なお、操作部23を割愛して、第2携帯端末2をベゼルレスにしてもよい。
管理装置5は、本体51と、ディスプレイ52(たとえば、液晶ディスプレイ)と、入力装置53とを含む。図5には、入力装置53としてキーボードを例示しているが、入力装置53は任意である。各種ポインティングデバイス(たとえば、マウス、タッチパッド)および各種スイッチも、入力装置53として採用可能である。
第2携帯端末2は、通信装置24、プロセッサ25、RAM(Random Access Memory)26、および記憶装置27を内蔵する。管理装置5の本体51は、通信装置54、プロセッサ55、RAM56、および記憶装置57を内蔵する。プロセッサ25,55としては、たとえばCPU(Central Processing Unit)を採用できる。RAM26、56は、それぞれプロセッサ25、55によって処理されるデータを一時的に記憶する作業用メモリとして機能する。記憶装置27,57は、書き込まれた情報を保存可能に構成される。記憶装置27,57は、たとえばROM(Read Only Memory)および書き換え可能な不揮発性メモリを含む。記憶装置27,57は、ハードディスクドライブおよびSSD(Solid State Drive)の少なくとも一方を含んでもよい。記憶装置27,57には、各種制御で用いられるプログラムのほか、プログラムで使用される情報(たとえば、各種パラメータ)が予め格納されている。
この実施の形態では、第2携帯端末2と管理装置5との間の通信C2がsXGP(shared eXtended Global Platform)方式で行なわれる。通信装置24,54は、sXGP無線通信モジュールとWiFi無線通信モジュールと(いずれも図示せず)を含む。通信C3(すなわち、WiFi通信)で使用される周波数帯は2.4GHz帯であり、通信C2(すなわち、sXGP通信)で使用される周波数帯は1.9GHz帯である。これらの無線通信で使用される周波数は十分離れているため、通信C2,C3は干渉しないと考えられる。このように、通信C2では、ネットワークN2(すなわち、無線LAN)で使用される周波数帯と干渉しない周波数帯が使用されている。
通信C1(すなわち、BLE通信)で使用される周波数帯は、通信C3と同じ2.4GHz帯である。しかし、通信C1の通信距離は短く、電波強度も弱いため、BLE通信とWiFi通信とは干渉しにくい。通信C1の通信距離は、たとえば2.5m~50mの範囲内で設定される。
上記のように、この実施の形態に係る浸水報知システムでは、通信C1,C2,C3のいずれにおいても通信障害が生じにくい。通信のセキュリティーを高めるため、通信C1,C2,C3の各々において暗号化および復号が行なわれるようにしてもよい。
船舶100は、災害対策設備7をさらに備える。図4および図5に示す受信機3と監視カメラ4と管理装置5と災害検出装置6と災害対策設備7とは、いずれもネットワークN1に接続され、相互に有線通信可能に構成される。管理装置5は、受信機3、監視カメラ4、災害検出装置6、および災害対策設備7の各々から情報を取得するように構成される。管理装置5は、各区画Bの監視カメラ4が取得するカメラ映像をネットワークN1を通じて逐次取得する。管理装置5は、リアルタイムのカメラ映像をディスプレイ52に表示するように構成されてもよい。
災害対策設備7は、水密扉(たとえば、前述した図2に示す扉D1~D9)および水密ハッチ(たとえば、前述した図3に示すハッチH1~H9)を含む。災害対策設備7は、防火扉および消火装置をさらに含んでもよい。消火装置は、火災が発生したことを検知すると、消火剤(たとえば、水またはハロン)を散布するように構成される。災害対策設備7に含まれる各設備には、設備ごとに固有の識別情報(以下、「設備ID」とも称する)が割り振られている。災害対策設備7に含まれる各設備は、自身の状態を検出するセンサを備え、そのセンサ信号を設備IDと一緒に管理装置5へ送信するように構成される。たとえば、扉D1~D9(図2)およびハッチH1~H9(図3)の各々は、開閉状態(開状態/閉状態)を検出するセンサ(図示せず)を備える。管理装置5は、扉D1~D9(図2)およびハッチH1~H9(図3)の各々の開閉状態をディスプレイ52に表示するように構成されてもよい。管理装置5は、図3に示す水密スペースにおいてハッチH1~H9のいずれかが所定時間以上継続して開いているときに警報を発するように構成されてもよい。警報は、管理装置5から各乗員の第2携帯端末2へ送信されてもよい。
管理装置5は、災害対策設備7を制御するように構成される。たとえば、管理装置5は、図2に示す居住スペースの近くで浸水が発生したときに水密扉(たとえば、扉D1~D9)を閉駆動するように構成される。管理装置5によって閉駆動されている水密扉(すなわち、起動状態の水密扉)を乗員が開くことはできない。すなわち、水密扉が起動状態になると、乗員によって水密扉を開くことが禁止される。
管理装置5は、予め登録された全ての乗員、区画、および設備に関する情報を管理するように構成される。記憶装置57は、管理装置5に登録された乗員ごとの情報(以下、「乗員情報」とも称する)を記憶している。乗員情報は、乗員IDと紐付けられている。また、記憶装置57は、管理装置5に登録された区画Bごとの情報(以下、「区画情報」とも称する)を記憶している。区画情報は区画IDと紐付けられている。記憶装置57は、管理装置5に登録された設備(たとえば、災害対策設備7に含まれる設備)ごとの情報(以下、「設備情報」とも称する)を記憶している。設備情報は、設備IDと紐付けられている。管理装置5は、受信機3、監視カメラ4、災害検出装置6、および災害対策設備7の各々から取得される情報に基づいて、記憶装置57内の乗員情報、区画情報、および設備情報の各々を更新するように構成される。
図6は、管理装置5が管理する乗員情報の一例を示す図である。図6に示すように、この乗員情報は、乗員の生体情報と、乗員の所在を示す所在情報と、受信機3からの最新受信時刻と、浸水フラグAとを含む。管理装置5は、受信機3から受信した最新のAパケットに基づいて乗員情報を更新する。最新受信時刻は、受信機3が第1携帯端末1から最新のAパケットを受信した時刻に相当する。乗員IDおよび生体情報は、Aパケットに含まれる。管理装置5は、受信機3から受信したAパケットに基づいて、乗員が存在する区画Bを推定し、所在情報を更新する。所在情報は、たとえば乗員が存在する区画Bを示す区画IDである。管理装置5は、1つの受信機3からAパケットを受信した場合には、その受信機3の設置場所(区画B)に乗員が存在すると推定することができる。管理装置5は、複数の受信機3からAパケットを受信した場合には、最も受信強度が大きい受信機3の設置場所(区画B)に乗員が存在すると推定することができる。浸水フラグAは、乗員が水に浸かっているか否かを示すフラグである。浸水フラグAの初期値は0である。乗員が携帯する浸水センサ16が浸水を検知した場合には、管理装置5は浸水フラグAを1にする。浸水センサ16の検知結果は、Aパケットに含まれる。
図6には示していないが、乗員情報は、各乗員が携帯する第2携帯端末2の通信アドレスをさらに含む。管理装置5は、乗員ごとの情報を乗員IDと紐付けて管理している。第2携帯端末2は乗員ごとに携帯されているため、乗員IDは、第2携帯端末2を識別する情報としても機能し得る。乗員情報は、各乗員の名称および属性をさらに含んでもよい。
図7は、管理装置5が管理する区画情報の一例を示す図である。図7に示すように、この区画情報は、有人フラグと、浸水フラグBと、閉鎖フラグとを含む。管理装置5は、受信機3および災害検出装置6の各々から受信した情報に基づいて区画情報を更新する。区画IDは、受信機3から管理装置5に送信される情報に含まれる。
有人フラグは、区画Bごとに乗員が存在するか否かを示すフラグである。有人フラグの値(0/1)によって、区画Bが無人区画/有人区画のいずれであるかが示される。管理装置5は、受信機3から取得される区画IDおよび受信強度情報に基づいて、区画Bごとの乗員の有無を判断することができる。管理装置5は、受信機3からAパケットを受信しない場合には、その受信機3が設置された区画Bに乗員が存在しないと推定し、その区画Bの区画IDに対応する有人フラグを0にする。管理装置5は、受信機3からAパケットを受信した場合に、Aパケットの受信強度が所定強度以上であれば、その受信機3が設置された区画Bに乗員が存在すると推定し、その区画Bの区画IDに対応する有人フラグを1にする。
浸水フラグBは、区画Bごとに浸水が発生しているか否かを示すフラグである。浸水フラグBの初期値は0である。管理装置5は、災害検出装置6(図4)から前述の浸水検出信号を受信すると、浸水を検出した監視カメラ4の区画IDに対応する浸水フラグBを1にする。
閉鎖フラグは、区画Bが閉鎖されているか否かを示すフラグである。閉鎖フラグの初期値は0である。管理装置5は、災害対策設備7の起動状況(たとえば、図2に示す扉D1~D9のいずれが起動しているか)に基づいて、区画Bごとに閉鎖されているか否かを判断する。たとえば、図2に示す居住スペースにおいて、管理装置5が扉D1~D4を起動すると、乗員は扉D1~D4を開くことができなくなり、通路V2は閉鎖される。この場合、管理装置5は通路V2の区画IDに対応する閉鎖フラグを1にする。その後、管理装置5が扉D1~D4を起動していない状態に戻すと、乗員が扉D1~D4を開くことができるようになり、通路V2は開放される。この場合、管理装置5は通路V2の区画IDに対応する閉鎖フラグを0に戻す。
図8は、管理装置5が管理する設備情報の一例を示す図である。図8に示すように、この設備情報は、センサ信号と、起動フラグとを含む。
センサ信号は、災害対策設備7に含まれる設備の状態を示す信号であり、各設備に設けられたセンサから出力される。管理装置5は、たとえば扉D1~D9(図2)およびハッチH1~H9(図3)の各々から、開閉状態(開状態/閉状態)を示すセンサ信号を取得する。
起動フラグは、災害対策設備7の起動状況(たとえば、管理装置5によって起動されているか否か)を示すフラグである。起動フラグの初期値は0である。たとえば、管理装置5が図2に示す扉D1を閉駆動すると、扉D1は起動状態になる。この場合、管理装置5は扉D1の設備IDに対応する起動フラグを1にする。その後、管理装置5は、扉D1を起動していない状態に戻すときに、扉D1の設備IDに対応する起動フラグを0に戻す。
管理装置5は、乗員情報、区画情報、および設備情報をディスプレイ52に表示するように構成されてもよい。こうした構成では、ユーザがディスプレイ52の画面を見て、各乗員の状態(たとえば、健康状態)、各区画Bの状態(たとえば、乗員の有無)、および各設備の状態(たとえば、水密区間の開閉状態)を確認することが可能になる。
管理装置5は、受信機3から取得したデータを記憶装置57に保存してもよい。管理装置5は、受信機3から正常なデータが取得されているか否かを、過去のデータ(履歴)を用いて診断してもよい。管理装置5は、たとえば生体情報および所在情報の少なくとも一方が過剰に大きく変化した場合に何らかの異常が生じていると判断してもよい。また、管理装置5は、最新受信時刻から所定時間以上経過しても、次のAパケットを受信しない場合に何らかの異常が生じていると判断してもよい。管理装置5は、異常が生じていると判断した場合に警報を発するように構成されてもよい。警報は、管理装置5から各乗員の第2携帯端末2へ送信されてもよい。上記過去のデータ(履歴)は、ユーザによって参照可能に保存されてもよい。ユーザは、異常の原因を突き止めるために過去のデータ(履歴)を参照してもよい。
以下、図9~図13を参照して、この実施の形態に係る浸水報知システム(特に、第2携帯端末2および管理装置5)の動作について説明する。管理装置5による処理は、記憶装置57(図5)に記憶されているプログラムをプロセッサ55(図5)が実行することによって行なわれる。第2携帯端末2による処理は、記憶装置27(図5)に記憶されているプログラムをプロセッサ25(図5)が実行することによって行なわれる。ただしこれに限られず、プログラムによって提供される機能の一部または全部は、専用のハードウェアによって実現されてもよい。
図9は、管理装置5によって実行される情報管理に係る処理の手順を示すフローチャートである。このフローチャートに示される処理は、管理装置5によって繰り返し実行される。
まず、管理装置5は、ステップ(以下、単に「S」とも表記する)1において、各受信機3および各災害対策設備7から前述の情報を取得する。各受信機3および各災害対策設備7から管理装置5への情報の送信は、所定周期で行なわれてもよいし、管理装置5からの要求に応じて行なわれてもよい。
S2では、管理装置5が、上記S1で取得した情報を用いて、前述した乗員情報、区画情報、および設備情報(図6~図8参照)を更新する。
S3では、管理装置5が乗員の浸水の有無を判断する。S2において全ての乗員の浸水フラグA(図6)が0になった場合には、S3において乗員の浸水は無い(NO)と判断され、処理はS1に戻される。他方、S2において少なくとも1人の乗員の浸水フラグA(図6)が1になった場合には、S3において乗員が浸水している(YES)と判断され、処理がS4に進む。そして、S4において管理装置5が警報を発した後、処理はS1に戻される。警報は、管理装置5から各乗員の第2携帯端末2へ送信されてもよい。
図10は、第2携帯端末2および管理装置5によって実行される浸水報知処理の手順を示すフローチャートである。以下では、1つの第2携帯端末2の処理について説明するが、各乗員の第2携帯端末2が同じ処理を実行する。
S11では、各区画Bに設置された監視カメラ4のいずれかによって浸水が検出されたか否かを、管理装置5が判断する。管理装置5は、災害検出装置6(図4)から前述の浸水検出信号を受信したときに、監視カメラ4によって浸水が検出された(S11にてYES)と判断する。災害検出装置6から管理装置5へ浸水検出信号が送信されない期間(すなわち、S11にてNOと判断されている期間)は、S11が繰り返し実行される。S11が繰り返し実行されることによって、船舶100内の各区画Bにおける浸水の有無が常時監視される。
管理装置5は、災害検出装置6から浸水検出信号を受信すると(S11にてYES)、浸水が検出された区画Bの区画IDに対応する浸水フラグB(図7)を1にし、処理をS12に進める。管理装置5は、S12において浸水発生信号(すなわち、浸水が発生したことを示す信号)を各乗員の第2携帯端末2へ送信した後、S13において浸水報知モードに移行する。これにより、図10における管理装置5の処理は終了する。
第2携帯端末2は、S14において、管理装置5から上記浸水発生信号を受信したか否かを判断する。管理装置5から第2携帯端末2へ浸水検出信号が送信されない期間(すなわち、S14にてNOと判断されている期間)は、S14が繰り返し実行される。このように、第2携帯端末2は、管理装置5からの浸水発生信号を常時受け付ける状態になっている。
第2携帯端末2は、S12で管理装置5から送信された浸水発生信号を受信すると(S14にてYES)、S15において、浸水が発生したことをユーザ(乗員)へ報知した後、S16において浸水報知モードに移行する。これにより、図10における第2携帯端末2の処理は終了する。第2携帯端末2によるユーザへの報知処理は任意であり、表示部21(図5)への表示(たとえば、文字または画像の表示)で知らせてもよいし、音入出力部22(図5)により音(音声を含む)で知らせてもよい。
第2携帯端末2と管理装置5との両方が浸水報知モードになると、図11の処理が実行される。図11は、実施の形態1の浸水報知モードにおける第2携帯端末2および管理装置5の処理手順を示すフローチャートである。
S21では、管理装置5が浸水情報を取得する。浸水情報は、浸水発生場所と、乗員の位置と、浸水を検出した監視カメラ4により取得される映像(以下、「浸水映像」とも称する)とを含む。
管理装置5は、浸水を検出した監視カメラ4の位置(ひいては、監視カメラ4が設置された区画Bの位置)に基づいて浸水発生場所を特定することができる。この実施の形態では、図10のS11でYESと判断されると、浸水を検出した監視カメラ4の位置を示す区画IDの浸水フラグB(図7)が1になる。このため、管理装置5は、記憶装置57内の区画情報(図5)を参照して、浸水発生場所を示す区画ID(すなわち、浸水フラグBが1になっている区画ID)を取得することができる。
管理装置5は、乗員が携帯する第1携帯端末1からAパケット(ひいては、乗員ID)を受信した受信機3の位置(ひいては、受信機3が設置された区画Bの位置)に基づいて、その乗員の位置を特定することができる。特定された乗員の位置は、図9のS2の処理により、乗員IDごとの所在情報(図6)に書き込まれる。この実施の形態では、乗員が存在する区画Bを示す区画IDが所在情報(図6)に書き込まれる。このため、管理装置5は、記憶装置57内の乗員情報(図5)を参照して、各乗員の位置を取得することができる。
管理装置5は、ネットワークN1を通じて各区画Bの監視カメラ4からカメラ映像を逐次取得することができる。浸水発生場所に設置された監視カメラ4によって取得される映像が、浸水映像に相当する。
S22では、管理装置5が、上記S21で取得した浸水情報を各乗員の第2携帯端末2へ送信する。乗員の位置は乗員IDごとに異なるため、管理装置5は、乗員の位置と乗員IDとを紐付けて一緒に送信する。第2携帯端末2と管理装置5との間の通信C2(図5)はsXGP方式で行なわれる。浸水報知モードでは、管理装置5がS21およびS22を繰り返し実行する。
第2携帯端末2は、S23において、上記S22で送信された浸水情報を受信する。そして、第2携帯端末2は、S24において、船内図とカメラ映像とのいずれを表示するかを判断する。初期において第2携帯端末2に船内図とカメラ映像とのいずれを表示させるかは、第2携帯端末2の初期設定、またはユーザからの入力によって、予め第2携帯端末2に設定されている。この実施の形態では、初期において「船内図の表示」が選ばれており、S24においてカメラ映像を表示しない(NO)と判断されるものとする。S24においてNOと判断されると、第2携帯端末2は、S25において表示部21(図5)に船舶100の船内図を表示する。船舶100の船内図情報は、予め各乗員の第2携帯端末2の記憶装置27(図5)に格納されている。
図12は、実施の形態1の浸水報知モードにおいて第2携帯端末2が表示する船内図の一例を示す図である。図12に示すように、表示部21に表示される画面M100は、標題M101と、拡大マップM1と、全体図M2と、矢印ボタンM11~M14およびM21~M24と、表示切替ボタンM10とを含む。表示部21は、タッチパネルディスプレイであるため、ユーザ(すなわち、第2携帯端末2を携帯する乗員)の指またはペンが画面に触れたときに、触れられた画面位置を感知することができる。ユーザは、画面に触れることによって、矢印ボタンM11~M14,M21~M24および表示切替ボタンM10を操作することができる。
全体図M2は、船舶100の全体図(以下、「船全体図」とも称する)を表示するとともに、カーソルM20によって船全体図のいずれの部分が選択されているかを示している。船全体図のうちカーソルM20が位置する部分(すなわち、選択された部分)は他の部分(すなわち、選択されていない部分)とは異なる形態(たとえば、異なる色)で表示される。ユーザは、矢印ボタンM21~M24によってカーソルM20を上下左右に動かすことができる。カーソルM20によって選択された部分の名称が、標題M101に表示される。
拡大マップM1は、カーソルM20によって選択された部分を拡大した船内図を表示する。図12には、斜視図の例を示しているが、平面図にしてもよい。ユーザは、矢印ボタンM11~M14によって拡大マップM1を上下左右にスクロールすることができる。図12に示す例では、図2に示した居住スペースがカーソルM20によって選択されている。
拡大マップM1上には、第2携帯端末2を携帯する乗員の位置(以下、「本人位置」とも称する)と、他の乗員の位置(以下、「他人位置」とも称する)と、浸水発生場所と、昇降位置とが示されている。マークM3は、浸水発生場所を示すアイコンである。マークM4は、上の階層へつながる梯子の位置を示すアイコンである。マークM5は、本人位置を示すアイコンである。マークM51~M55は、他人位置を示すアイコンである。これらのマークは、図12に示すものに限られず、各マークが識別可能である範囲で適宜変更可能である。マークの色、模様、形、大きさ、あるいは他の表示形態(たとえば、点灯/点滅)を変えることによって、他のマークと区別することができる。
なお、第2携帯端末2は、管理装置5から受信した浸水情報(図11のS23)に基づいて、本人位置と、他人位置と、浸水発生場所とを取得することができる。浸水情報に含まれる乗員の位置(この実施の形態では、乗員が存在する区画Bを示す区画ID)が本人位置/他人位置のどちらであるかは、乗員の位置に紐付けられた乗員IDに基づいて判断することができる。また、昇降位置は、記憶装置27内の船内図情報(図5)に含まれる。
第2携帯端末2は、表示部21に表示される内容を画面M100から浸水映像に切り替えることができるように構成される。画面M100が表示部21に表示されているときにユーザが表示切替ボタンM10を押すと、図11のS24においてYESと判断されるようになり、図11のS26において第2携帯端末2の表示が船内図からカメラ映像に切り替わる。図11のS26では、第2携帯端末2が表示部21に浸水映像を表示する。
図13は、実施の形態1の浸水報知モードにおいて第2携帯端末2が表示する浸水映像の一例を模式的に示す図である。図13に示す浸水映像から、区画Bの底に水Wが溜まっている状況を把握できる。この実施の形態では、監視カメラ4として、区画Bの天井に設置された魚眼カメラを採用している。このため、監視カメラ4によって区画B全体のカメラ映像が取得される。浸水映像は、第2携帯端末2が管理装置5から受信した浸水情報(図11のS23)に含まれる。
図14は、受信機3および監視カメラ4の各々の変形例について説明するための図である。この実施の形態に係る受信機3および監視カメラ4は、区画Bの天井に設置されている。図14に示される受信機3Aおよび監視カメラ4Aの各々は、変形例に相当する。
受信機3に代えて受信機3Aを採用してもよい。しかし、隔壁BWに設置された受信機3Aの高さDA2は、区画Bの天井を構成する甲板F1に設置された受信機3の高さDA1よりも低くなる。このため、受信機3Aよりも受信機3のほうが浸水しにくくなる。
監視カメラ4に代えて監視カメラ4Aを採用してもよい。しかし、隔壁BWに設置された監視カメラ4Aの高さDB2は、区画Bの天井を構成する甲板F1に設置された監視カメラ4の高さDB1よりも低くなる。このため、監視カメラ4Aよりも監視カメラ4のほうが浸水しにくくなる。
監視カメラ4Aは、魚眼レンズではなく標準レンズ(たとえば、画角40°~60°程度のレンズ)を用いたカメラである。図15は、監視カメラ4Aによって取得される浸水映像の一例を模式的に示す図である。図15に示すように、標準レンズを用いたカメラでは、魚眼カメラ(図13参照)よりも撮影範囲が狭くなる。標準レンズを用いたカメラでは、区画B全体の映像を取得することができないことがある。
監視カメラ4Aは、首振り機能を有するカメラであってもよい。より具体的には、監視カメラ4Aは、撮影角度を可変とするアクチュエータを備えてもよい。監視カメラ4Aは、撮影角度(ひいては、監視範囲)を変えながら区画B全体の映像を取得するように構成されてもよい。
第2携帯端末2は、表示部21に表示される内容を浸水映像から画面M100に切り替えることができるように構成される。浸水映像(たとえば、図13)が表示部21に表示(たとえば、全画面表示)されているときにユーザが操作部23を操作すると、図11のS24においてNOと判断されるようになり、図11のS25において第2携帯端末2の表示がカメラ映像(たとえば、図13に示す浸水映像)から船内図(たとえば、図12に示す画面M100)に切り替わる。
浸水報知モードでは、第2携帯端末2が、図11の処理(すなわち、S23、S24、およびS24の判断結果に応じて選択されるS25/S26のいずれかの処理)を繰り返し実行する。S25およびS26の各々における表示は、S23で取得した最新の浸水情報に基づいて行なわれる。このため、図11のS26では、リアルタイムのカメラ映像(たとえば、動画)が第2携帯端末2に表示される。乗員は、第2携帯端末2に表示されるリアルタイムのカメラ映像を見て、刻一刻と変わる被害の状況を確認することができる。
浸水報知モードは、所定の終了条件が成立すると終了する。たとえば、ユーザが管理装置5に所定の停止操作を行なったときに浸水報知モードの終了条件が成立するようにしてもよい。
この実施の形態に係る浸水報知システムは、上述した浸水報知モードだけでなく、訓練モードでも動作し得る。訓練モードは、平常時に浸水発生時の状況を乗員に疑似体験させることにより乗員を訓練するモードである。所定の訓練開始条件が成立すると、第2携帯端末2および管理装置5が訓練モードになる。たとえば、ユーザが管理装置5に所定の訓練開始操作を行なったときに訓練開始条件が成立し、各乗員の第2携帯端末2と管理装置5とが訓練モードになるようにしてもよい。また、ユーザが第2携帯端末2に所定の訓練開始操作を行なったときに訓練開始条件が成立し、訓練開始操作が行なわれた第2携帯端末2と管理装置5とが訓練モードになるようにしてもよい。
第2携帯端末2と管理装置5との両方が訓練モードになると、図16の処理が実行される。図16は、実施の形態1の訓練モードにおける第2携帯端末2および管理装置5の処理手順を示すフローチャートである。
S31では、管理装置5が訓練情報を取得する。訓練情報は、模擬浸水場所と、乗員の位置と、模擬浸水映像とを含む。訓練情報に含まれる乗員の位置は、浸水情報に含まれる乗員の位置(図11のS21)と同じである。模擬浸水場所は、船舶100内の監視カメラ4のいずれかの位置(区画ID)である。模擬浸水場所は、ユーザによって予め管理装置5に設定されてもよいし、ランダムに選ばれてもよい。模擬浸水映像は、模擬浸水場所における模擬浸水の映像である。模擬浸水映像は、予め管理装置5の記憶装置57(図5)に格納されている。模擬浸水映像は、実際に浸水が発生した時に監視カメラ4によって取得される映像に近い映像であることが好ましく、監視カメラ4で撮影された動画であってもよいし、CG(Computer Graphics)であってもよい。
S32では、管理装置5が、上記S31で取得した訓練情報を第2携帯端末2へ送信する。乗員の位置は乗員IDごとに異なるため、管理装置5は、乗員の位置と乗員IDとを紐付けて一緒に送信する。
第2携帯端末2は、S33において、上記S32で送信された訓練情報を受信する。そして、第2携帯端末2は、S34において、船内図とカメラ映像とのいずれを表示するかを判断する。S34においてカメラ映像を表示しない(NO)と判断されると、第2携帯端末2は、S35において表示部21(図5)に船内図を表示する。他方、S34においてカメラ映像を表示する(YES)と判断されると、第2携帯端末2は、S36において表示部21(図5)に模擬浸水映像を表示する。S34~S36は、基本的には、図11のS24~S26と同じ処理である。ただし、S35では浸水発生場所の代わりに模擬浸水場所が使用され、S36では、浸水映像の代わりに模擬浸水映像が使用される。
S37では、第2携帯端末2が、訓練情報を受信(S33)してから所定時間が経過したか否かを判断する。所定時間が経過するまでの期間(すなわち、S37にてNOと判断されている期間)は、S34~S37が繰り返し実行される。第2携帯端末2を携帯する乗員は、この期間に避難経路を考えることができる。そして、所定時間が経過すると(S37にてYES)、第2携帯端末2は、S38において、以下に説明する入力画面を表示することによってユーザに避難経路の入力を要求する。
図17は、実施の形態1の訓練モードにおいて第2携帯端末2が表示する入力画面の一例を示す図である。図17に示すように、この入力画面は、図12に示す画面M100と概ね同じ内容を表示するとともに、メッセージM61と決定ボタンM62とをさらに表示する。メッセージM61は、ユーザに避難経路の入力を要求する。ユーザは、たとえば拡大マップM1上を指でなぞることによって、拡大マップM1上に避難経路を入力することができる。避難経路の入力後、ユーザによって決定ボタンM62が押されると、処理が図16のS39に進む。
図16のS39では、第2携帯端末2が、S38で入力された避難経路と、当該第2携帯端末2を識別する識別情報(たとえば、乗員ID)とを含む回答情報を管理装置5へ送信する。
管理装置5は、前述したS32の処理後、S40において、第2携帯端末2から避難経路を受信したか否かを判断する。避難経路の受信が確認されるまでの間(S40においてNOと判断されている期間)は、S40が繰り返し行なわれる。そして、管理装置5は、S39で第2携帯端末2から送信された避難経路および識別情報を受信すると(S40にてYES)、S41において、その避難経路を評価する。より具体的には、管理装置5は、ユーザによって入力された避難経路(以下、「入力経路」とも称する)が正しいか否かを判断する。たとえば、訓練条件ごとの最適な避難経路(以下、「最適経路」とも称する)が予め管理装置5の記憶装置57(図5)に格納されており、管理装置5は、入力経路と最適経路とが一致するか否かを判断する。訓練条件の例としては、本人位置、模擬浸水場所、模擬浸水映像が挙げられる。
S42では、管理装置5が、S41で評価した結果を示す評価情報を第2携帯端末2へ返信する。S43では、管理装置5から送信された評価情報を第2携帯端末2が受信する。そして、第2携帯端末2は、S44において、評価情報によって示される評価結果を表示部21(図5)に表示する。S44をもって、訓練モードは終了する。
上記の評価情報(ひいては、S44で表示される評価結果)は、入力経路の正否を含む。入力経路の正否は、記号(たとえば、○/×)で示されてもよいし、評価点数およびコメントの少なくとも一方によって示されてもよい。たとえば、第2携帯端末2は、入力経路と最適経路とが一致する場合には「合格」と表示し、入力経路と最適経路とが一致しない場合には「不合格」と表示するように構成されてもよい。上記の評価情報が評価点数を含む構成では、管理装置5は、入力経路が短いほど、入力経路の危険度が低いほど、入力時間(すなわち、入力画面(図17)を表示してからユーザによって避難経路が入力されるまでの時間)が短いほど、評価点数を高くしてもよい。上記の評価情報は、入力経路について講評するコメントを含んでもよい。
<利点>
以上のように、この実施の形態に係る浸水報知システムは、複数の第1携帯端末1と、複数の第2携帯端末2と、複数の受信機3と、複数の監視カメラ4と、管理装置5とを備える(図4参照)。船舶100の乗員ごとに第1携帯端末1および第2携帯端末2が携帯される。複数の受信機3と、複数の監視カメラ4と、管理装置5とは、船舶100(図1)内に設けられている。複数の第1携帯端末1の各々は、発信機14(図5)を有し、乗員ごとに固有の識別信号(たとえば、乗員IDを含むAパケット)を発信するように構成される。複数の受信機3の各々は、受信範囲内に存在する第1携帯端末1が発信するAパケットを受信するように構成される。複数の監視カメラ4の各々は、監視範囲の映像を取得するように構成される。管理装置5は、複数の受信機3、複数の監視カメラ4、および複数の第2携帯端末2の各々と通信可能に構成される(図5参照)。
管理装置5は、複数の監視カメラ4のいずれかによって浸水が検出された場合(図10のS11にてYES)に図11の処理を実行し(図10のS13)、浸水発生場所と乗員の位置と浸水映像とを含む浸水情報を、複数の第2携帯端末2の各々へ送信する(図11のS22)ように構成される。浸水発生場所は、浸水を検出した監視カメラ4の位置に基づいて特定される。乗員の位置は、その乗員が携帯する第1携帯端末1からAパケットを受信した受信機3の位置に基づいて特定される。浸水映像は、浸水を検出した監視カメラ4により取得される。
複数の第2携帯端末2の各々は、管理装置5から浸水情報を受信した場合(図11のS23)に、第2携帯端末2を携帯する乗員の位置(すなわち、本人位置)と、浸水発生場所と、浸水を検出した監視カメラ4により取得されるリアルタイムの映像(たとえば、図13に示す浸水映像)とを表示可能に構成される(図11のS24~S26)。図12に示す画面M100では、本人位置(マークM5)と浸水発生場所(マークM3)とが拡大マップM1上に同時に表示されている。一方、浸水映像は、図12に示す画面M100(すなわち、本人位置および浸水発生場所)とは同時には表示されず、別の画面で表示される。
受信機3が第1携帯端末1の発信機14からのAパケットを受信することは、発信機14が受信機3の周辺(より特定的には、受信範囲内)に存在することを意味する。上記の浸水報知システムは、Aパケットを受信した受信機3の位置を用いて、船舶100内の乗員の位置を的確に検出することができる。さらに、上記の浸水報知システムは、監視カメラ4により取得される映像に基づいて浸水の有無を判断することができる。監視カメラ4が浸水を検出したときには、浸水を検出した監視カメラ4の位置で浸水が発生している。上記の浸水報知システムは、浸水を検出した監視カメラ4の位置を用いて、浸水発生場所を的確に検出することができる。
上記の浸水報知システムが備える各第2携帯端末2は、浸水発生時に、第2携帯端末2を携帯する乗員の位置と、浸水発生場所と、浸水発生場所に設置された監視カメラ4により取得されるリアルタイムの映像とを表示することができる。乗員は、第2携帯端末2の表示により、自身の位置(すなわち、本人位置)と浸水発生場所とを確認することができる。また、乗員は、第2携帯端末2に表示されるリアルタイムの浸水映像を見て、刻一刻と変わる被害の状況を確認することができる。乗員は、第2携帯端末2の表示を見ながら、排水または防水のような初動対応(すなわち、浸水に対する避難以外の行動)と避難とのどちらを優先すべきかを判断することができる。このように、上記の浸水報知システムによれば、船舶100で浸水が発生したときに、浸水に対する初動対応および避難を適切に行なうための情報を乗員に与えることができる。
なお、第2携帯端末2は、本人位置と浸水発生場所とを別々に表示してもよい。たとえば、第2携帯端末2を携帯する乗員の位置から遠い場所で浸水が発生した場合には、画面M100(図12)において本人位置(マークM5)と浸水発生場所(マークM3)とは同時に表示されなくなる。ユーザは、カーソルM20を動かして、本人位置を示す拡大マップM1と、浸水発生場所を示す拡大マップM1とを切り替えることができる。図12に示す画面M100では、拡大マップM1上に他人位置(マークM51~M55)を示しているが、他人位置を示すことは必須ではない。
複数の第2携帯端末2の各々は、GPSを利用して位置を検出するGPSモジュールを含んでもよい。GPS衛星からの信号(GPS信号)を受信可能なエリア(たとえば、上甲板103上)では、第2携帯端末2のGPSモジュールを用いて、第2携帯端末2を携帯する乗員の位置を検出するようにしてもよい。そして、GPSモジュールによって取得される乗員の位置情報が第2携帯端末2から管理装置5へ送信されるようにしてもよい。
複数の第2携帯端末2の各々は、第2携帯端末2を携帯する乗員の位置(すなわち、本人位置)および浸水発生場所を示す船内図(たとえば、図12に示す拡大マップM1)の表示と、リアルタイムの浸水映像(たとえば、図13に示す浸水映像)の表示とを切替え可能に構成される(図11のS24~S26参照)。
一般に、携帯端末は、ユーザが携帯しやすい形状および大きさにすることが要求される。携帯端末に設けられる画面(表示部)のサイズを大きくすることには限界がある。上記の構成では、第2携帯端末2が上記の船内図とリアルタイム映像とを切り替えて表示することができる。このため、第2携帯端末2は、船内図とリアルタイム映像とのいずれか一方を選択して表示部21(図5)に大きく表示することができる。
この実施の形態に係る浸水報知システムでは、訓練モード(図16)において、管理装置5が、模擬浸水場所と乗員の位置と模擬浸水映像とを含む訓練情報を、複数の第2携帯端末2の各々へ送信する(図16のS32)ように構成される。複数の第2携帯端末2の各々は、管理装置5から訓練情報を受信した場合(図16のS33)に、第2携帯端末2を携帯する乗員の位置(すなわち、本人位置)と、模擬浸水場所と、模擬浸水映像とを表示可能に構成される。
上記の第2携帯端末2は、平常時に浸水発生時と同様の表示を行なうことができる。乗員は、平常時に浸水発生時の状況を疑似体験し、実際の浸水発生時にどのように行動するかを考えることができる。このように、上記の構成によれば、乗員の模擬訓練を行なうことができる。
複数の第2携帯端末2の各々は、第2携帯端末2を携帯する乗員からの避難経路の入力を受け付け(図17参照)、避難経路の入力(図16のS38)がなされた場合に、入力された避難経路を含む回答情報を管理装置5へ送信する(図16のS39)ように構成される。管理装置5は、回答情報を受信した場合(図16のS40にてYES)に、回答情報に含まれる避難経路を評価した結果を含む評価情報を、回答情報を送信した第2携帯端末2へ返信する(図16のS42)ように構成される。
上記の構成では、管理装置5が、乗員によって入力された避難経路(入力経路)が正しいか否かを評価するとともに、入力経路を評価した結果(たとえば、入力経路の正否)を含む評価情報を第2携帯端末2へ返信することで、各乗員に個別指導を行なうことができる。こうした個別指導を行なうことで、緊急な行動が求められる浸水発生時においても各乗員が適切に行動しやすくなる。
船舶100は、無線LAN(たとえば、図5に示すネットワークN2)を通じて相互に通信可能に構成される機器111~113を備える。そして、管理装置5と第2携帯端末2との間の通信方式は、無線LANで使用される周波数帯(たとえば、2.4GHz帯)と干渉しない周波数帯(たとえば、1.9GHz帯)を使用する通信方式である。
無線LANを利用することで、船舶100内の各種機器を通信可能に接続することができる。上記の浸水報知システムでは、船舶100に搭載される複数の機器(たとえば、機器111~113)を無線LANを通じて通信可能に接続しつつ、管理装置5と第2携帯端末2との通信は、無線LANを利用せずに、無線LANとは異なる通信方式(より特定的には、無線LANで使用される周波数帯と干渉しない周波数帯を使用する通信方式)で行なう。このため、上記の浸水報知システムによれば通信障害が生じにくくなる。
この実施の形態に係る浸水報知システムにおいて、ネットワークN2(すなわち、無線LAN)の通信方式はWiFiであり、第1携帯端末1の発信機14と受信機3との間の通信方式はBLEであり、管理装置5と第2携帯端末2との間の通信方式はsXGPである。こうした構成によれば、無線LANにおける通信C3、発信機14と受信機3との間の通信C1、および管理装置5と第2携帯端末2との間の通信C2のいずれにおいても、通信障害が生じにくくなる(図5参照)。
船舶100の乗員ごとに携帯される第1携帯端末1が、上記の発信機14に加えて、生体センサ15および浸水センサ16を有する(図5参照)。そして、管理装置5は、浸水センサ16の出力と生体センサ15の出力とを、受信機3およびネットワークN1を介して受信し、浸水センサ16が浸水を検知した場合(図9のS3にてYES)に警報を発する(図9のS4)ように構成される。
上記の構成では、乗員が誤って船舶100から落下した場合に、浸水センサ16が浸水を検知する。管理装置5は、浸水センサ16の出力を受信し、浸水センサ16が浸水を検知した場合に警報を発する。これにより、船舶100から落下した乗員の捜索を早期に開始することが可能になる。また、管理装置5は、生体センサ15の出力に基づいて乗員の生体情報を取得することができる。このため、乗員の健康状態を確認しながら乗員の捜索を行なうことが可能になる。また、管理装置5は、平常時における乗員の健康状態を生体センサ15の出力を用いて確認しながら生体センサ15の出力を記録し、乗員の健康状態に異常が生じた場合に、生体センサ15の過去の出力(履歴)を分析して乗員の健康状態を診断するように構成されてもよい。
この実施の形態に係る浸水報知システムでは、受信機3および監視カメラ4が、船舶100内において隔壁BWで区分けされた複数の区画Bの各々に1つずつ設けられている(図4参照)。この実施の形態では、船舶100の複数の区画Bに、部屋R1~R28(図2)と、通路V1~V8,V11,V12(図2)と、水密区間S1~S6(図3)とが含まれる。監視カメラ4は、区画Bの天井に設置されている。
上記構成によれば、区画Bごとに乗員の有無と浸水の有無とを検出することが可能になる。また、監視カメラ4を天井に設置することで、監視カメラ4によって浸水の状況を的確に表す映像を取得しやすくなるとともに、監視カメラ4が浸水しにくくなる。
この実施の形態では、船舶100の乗員全員が第1携帯端末1および第2携帯端末2を携帯する。ただしこれに限られず、船舶100の一部の乗員のみが第1携帯端末1および第2携帯端末2を携帯してもよい。たとえば、乗務員と乗客とを含む船舶では、乗務員のみが第1携帯端末1および第2携帯端末2を携帯してもよい。
[実施の形態2]
本開示の実施の形態2に係る浸水報知システムについて説明する。実施の形態2は実施の形態1と共通する部分が多いため、主に相違点について説明し、共通する部分についての説明は割愛する。
実施の形態2に係る浸水報知システムでは、船舶100において浸水が発生したときに、各乗員が携帯する第2携帯端末2が1つの避難経路を自動的に取得して表示する。これにより、各乗員が迅速に避難を行なうことが可能になる。より具体的には、実施の形態2に係る浸水報知システムは、基本的には、実施の形態1に係る浸水報知システムに準ずる構成(図1~図8参照)を有する。ただし、実施の形態2に係る浸水報知システムでは、浸水報知モードにおいて、第2携帯端末2および管理装置5が、図11の処理に代えて、図18の処理を行なうように構成される。
図18は、実施の形態2に係る第2携帯端末2および管理装置5が浸水報知モードにおいて実行する処理の手順を示すフローチャートである。この実施の形態においても、第2携帯端末2および管理装置5によって図10の処理が実行され、各区画Bに設置された監視カメラ4のいずれかによって浸水が検出された場合(図10のS11にてYES)に、浸水報知モードに係る処理(この実施の形態では、図18の処理)が実行される。
S21Aでは、管理装置5が浸水情報を取得する。この実施の形態では、浸水情報が、浸水発生場所と、乗員の位置と、浸水映像とに加えて、災害対策設備7(図5)の起動状況をさらに含む。管理装置5は、記憶装置57内の設備情報(図5)に含まれる設備ごとの起動フラグ(図8)を参照して、災害対策設備7の起動状況を取得することができる。
S22Aでは、管理装置5が、上記S21Aで取得した浸水情報を各乗員の第2携帯端末2へ送信する。浸水報知モードでは、管理装置5がS21AおよびS22Aを繰り返し実行する。
第2携帯端末2は、S23Aにおいて、上記S22Aで送信された浸水情報を受信する。そして、第2携帯端末2は、S251において、受信した浸水情報に基づいて1つの最適な避難経路を取得する。たとえば、第2携帯端末2は、浸水情報に基づいて船舶100の状況を総合的に評価して、避難先(以下、「目標地」とも称する)を決定するとともに、安全かつ最短な避難経路を取得する。第2携帯端末2は、浸水情報から現在の本人位置(以下、「現在地」とも称する)を取得することができる。第2携帯端末2は、浸水映像に基づいて浸水の状況を評価することができる。
第2携帯端末2は、浸水映像に基づいて目標地を決定してもよい。図19は、目標地を決定する方法の一例について説明するための図である。図19において、区画B11~B13の各々は、船舶100内の水密区間である。図19の例では、区画B11~B13のうち区画B11のみが浸水している。第2携帯端末2は、区画B11に設置された監視カメラ4により取得される映像に基づいて水面Wsの角度θを求めるとともに、水面Wsの角度θから、船首101および船尾102(図1)のいずれが早く沈むかを予測することができる。図19の例では、船尾102が早く沈むと予測される。この場合、第2携帯端末2は、図18のS251において目標地を船首101側に設定して、船首101側に避難するように乗員を誘導する。
図18のS252では、第2携帯端末2が、上記S251で取得した最適な避難経路を含む船内図を表示部21(図5)に表示する。図20は、図18のS252において第2携帯端末2が表示する船内図の一例を示す図である。
図20に示すように、表示部21に表示される画面M100Aは、図12に示す画面M100と概ね同じ内容(ただし、表示切替ボタンM10は含まない)を表示するとともに、避難ガイダンスM72をさらに表示する。また、画面M100Aが表示する拡大マップM1Aは、ラインM71を含む。ラインM71は、図18のS251で取得した最適な避難経路を拡大マップM1A上に示す。避難ガイダンスM72は、現在地および目標地の各々の名称と、詳細な状況説明とを表示する。
浸水報知モードは所定の終了条件が成立するまで継続され、浸水報知モードにおいては、第2携帯端末2が、図18の処理(すなわち、S23A、S251、およびS252)を繰り返し実行する。S251における最適な避難経路の取得、およびS252における船内図の表示は、S23Aで取得した最新の浸水情報に基づいて行なわれる。このため、第2携帯端末2に表示される最適な避難経路は、状況の変化に応じて随時更新される。たとえば、乗員が道を間違えて避難経路から外れた場合、あるいは新たな浸水が発生した場合に、第2携帯端末2に表示される最適な避難経路は変更され得る。
<利点>
以上のように、この実施の形態に係る浸水報知システムは、複数の第1携帯端末1と、複数の第2携帯端末2と、複数の受信機3と、複数の監視カメラ4と、管理装置5とを備える(図4参照)。複数の第1携帯端末1の各々は、発信機14(図5)を有し、乗員ごとに固有の識別信号(たとえば、乗員IDを含むAパケット)を発信するように構成される。複数の受信機3の各々は、受信範囲内に存在する第1携帯端末1が発信するAパケットを受信するように構成される。複数の監視カメラ4の各々は、監視範囲の映像を取得するように構成される。管理装置5は、複数の受信機3、複数の監視カメラ4、複数の第2携帯端末2、および船舶100が備える災害対策設備7の各々と通信可能に構成される(図5参照)。
管理装置5は、複数の監視カメラ4のいずれかによって浸水が検出された場合(図10のS11にてYES)に図18の処理を実行し(図10のS13)、浸水発生場所と乗員の位置と災害対策設備の起動状況と浸水映像とを含む浸水情報を、複数の第2携帯端末2の各々へ送信する(図18のS22A)ように構成される。
複数の第2携帯端末2の各々は、管理装置5から浸水情報を受信した場合(図18のS23A)に、浸水情報に基づいて1つの避難経路を取得するとともに、その1つの避難経路を表示可能に構成される(図18のS251およびS252)。
上記の浸水報知システムでは、第2携帯端末2が、浸水情報に基づいて取得した1つの避難経路を表示することができる。第2携帯端末2は、浸水情報に含まれる各種情報を総合的に評価して、最適な避難経路を決定することができる。上記の浸水報知システムによれば、浸水が発生したときに、第2携帯端末2に表示される避難経路に従って各乗員が迅速に避難を行なうことが可能になる。
この実施の形態では、船舶100の乗員全員が第1携帯端末1および第2携帯端末2を携帯する。ただしこれに限られず、船舶100の一部の乗員のみが第1携帯端末1および第2携帯端末2を携帯してもよい。乗務員と乗客とを含む船舶では、乗客のみが第1携帯端末1および第2携帯端末2を携帯してもよい。たとえば、熟練した乗務員と未熟な乗務員とを含む船舶では、未熟な乗務員のみが第1携帯端末1および第2携帯端末2を携帯してもよい。
実施の形態1と実施の形態2とを組み合わせてもよい。たとえば、乗務員と乗客とを含む船舶において、図11に示す浸水報知モードを実行する携帯端末(実施の形態1に係る第2携帯端末2)を乗務員に携帯させて、図18に示す浸水報知モードを実行する携帯端末(実施の形態2に係る第2携帯端末2)を乗客に携帯させてもよい。
第2携帯端末2および管理装置5は、複数種の浸水報知モード(たとえば、図11に示す浸水報知モード、および図18に示す浸水報知モード)を実行可能に構成されてもよい。浸水発生時にどちらの浸水報知モードを第2携帯端末2および管理装置5に実行させるかをユーザが予め第2携帯端末2および管理装置5に設定できるようにしてもよい。
実施の形態1に係る浸水報知モード(すなわち、図11に示す処理)において、S25の代わりに図18のS251およびS252が実行されるようにしてもよい。
[実施の形態3]
本開示の実施の形態3に係る浸水報知システムについて説明する。実施の形態3は実施の形態1と共通する部分が多いため、主に相違点について説明し、共通する部分についての説明は割愛する。
実施の形態3に係る浸水報知システムでは、船舶100において浸水が発生したときに、各乗員が携帯する第2携帯端末2が、選択可能な避難経路と閉鎖された通路との少なくとも一方を自動的に取得して表示する。こうした表示により、各乗員が避難しやすくなる。より具体的には、実施の形態3に係る浸水報知システムは、基本的には、実施の形態1に係る浸水報知システムに準ずる構成(図1~図8参照)を有する。ただし、実施の形態3に係る浸水報知システムでは、浸水報知モードにおいて、第2携帯端末2および管理装置5が図11の処理を実行するときに、管理装置5が、S21およびS22において、浸水発生場所と乗員の位置と浸水映像と災害対策設備7(図5)の起動状況とを含む浸水情報を取得し、取得した浸水情報を第2携帯端末2へ送信する。また、第2携帯端末2は、実施の形態1とは異なる内容のS25を実行する。以下、この実施の形態において第2携帯端末2が実行するS25について説明する。
この実施の形態では、第2携帯端末2が、図11のS25において、浸水情報に基づいて選択可能な避難経路を取得するとともに、選択可能な避難経路を示す船内図を表示部21(図5)に表示する。第2携帯端末2は、浸水情報から現在地を取得することができる。避難経路の目標地は、ユーザが予め第2携帯端末2に設定してもよいし、第2携帯端末2が浸水情報に基づいて決定してもよい。この実施の形態では、上の階層へつながる梯子の位置を、目標地とする。
第2携帯端末2は、浸水情報に含まれる災害対策設備7の起動状況に基づいて、現在地から目標地までの避難経路のうち、選択可能な避難経路を取得する。災害対策設備7が起動すると、平常時(すなわち、災害が発生していない時)に通ることができた通路が通れなくなることがある。たとえば、水密扉によって通路が閉鎖されることがある。また、浸水だけでなく火災も発生したときには、防火扉によって通路が閉鎖されたり、消火剤が散布された場所に立ち入ることができなくなったりすることがある。第2携帯端末2は、災害対策設備7の起動状況に基づいて、閉鎖された通路(すなわち、通ることができない通路)と、選択可能な避難経路とを取得することができる。
図21は、実施の形態3の浸水報知モードにおいて表示される選択可能な避難経路を示す船内図の一例を示す図である。第2携帯端末2は、図12に示す拡大マップM1に代えて、図21に示す拡大マップM1Bを表示する。
図21に示すように、拡大マップM1Bは、浸水発生場所を示すマークM3と、上の階層へつながる梯子の位置(すなわち、目標地)を示すマークM4と、本人位置(すなわち、現在地)を示すマークM5と、他人位置を示すマークM51~M55とを含む。
拡大マップM1Bは、起動中の設備を示すマークM81~M83をさらに含む。マークM81~M83によって、扉D7~D9が起動していることが示されている。扉D7~D9の各々は、水密扉であり、たとえば浸水による被害の拡大を抑制するために、管理装置5によって起動される。扉D7~D9が起動すると、乗員によって扉D7~D9を開くことは禁止される。すなわち、通路V7は閉鎖され、通ることができなくなる。こうした状況においては、通路V7を通る避難経路は選択できない。
拡大マップM1Bは、避難経路を示すラインER1およびER2をさらに含む。ラインER1およびER2によって示される2つの避難経路は、選択可能な避難経路に相当する。拡大マップM1B上にラインER1およびER2が表示されることによって、乗員は現時点で選択可能な避難経路を把握することができる。
第2携帯端末2は、図11のS25において、選択可能な避難経路に代えてまたは加えて、閉鎖された通路を表示するように構成されてもよい。図22は、実施の形態3の浸水報知モードにおいて表示される閉鎖された通路を示す船内図の一例を示す図である。第2携帯端末2は、図12に示す拡大マップM1に代えて、図22に示す拡大マップM1Cを表示する。
図22に示すように、拡大マップM1Cは、閉鎖された通路を示すマークM8を含む。図22の例では、通路V7が閉鎖されている。閉鎖された通路V7にマークM8が付与されることで、通路V7は他の通路とは異なる形態(たとえば、異なる模様)で表示されるようになる。マークM8によって、乗員は現時点で通ることができない通路を把握することができる。
拡大マップM1Cには、選択可能な避難経路が示されていないが、図21に示すラインER1およびER2を拡大マップM1Cに追加して、船内図上に、選択可能な避難経路と、閉鎖された通路との両方が示されるようにしてもよい。また、図21および図22の各々には、平面図の例を示しているが、斜視図にしてもよい。
<利点>
以上のように、この実施の形態に係る浸水報知システムでは、管理装置5から第2携帯端末2へ送信される浸水情報が、浸水発生場所と乗員の位置と浸水映像とに加えて、災害対策設備7(図5)の起動状況を含む。複数の第2携帯端末2の各々は、管理装置5から浸水情報を受信した場合(図11のS23)に、浸水情報に基づいて、選択可能な避難経路と閉鎖された通路との少なくとも一方を取得するとともに、船舶100の船内図上に、第2携帯端末2を携帯する乗員の位置(すなわち、本人位置)と、浸水発生場所と、選択可能な避難経路および閉鎖された通路の少なくとも一方とを表示可能に構成される(図21および図22参照)。こうした船内図の表示は、図11のS25において行なわれる。たとえば、図21に示す拡大マップM1Bでは、マークM5によって本人位置が示され、マークM3によって浸水発生場所が示され、ラインER1およびER2によって選択可能な避難経路が示される。また、図22に示す拡大マップM1Cでは、マークM5によって本人位置が示され、マークM3によって浸水発生場所が示され、マークM8によって閉鎖された通路が示される。
上記の浸水報知システムが備える各第2携帯端末2は、災害対策設備7の起動状況を含む浸水情報に基づいて、選択可能な避難経路と閉鎖された通路との少なくとも一方を取得して表示することができる。乗員は、こうした第2携帯端末2の表示により、現時点で選択可能な避難経路と、現時点で通ることができない通路との少なくとも一方を確認することができる。
[実施の形態4]
本開示の実施の形態4に係る浸水報知システムについて説明する。実施の形態4は実施の形態1と共通する部分が多いため、主に相違点について説明し、共通する部分についての説明は割愛する。
実施の形態4に係る浸水報知システムでは、各乗員が携帯する第2携帯端末2が、管理装置5からの指示に従って通信規制される。こうした通信規制により、通信障害が抑制される。より具体的には、実施の形態4に係る浸水報知システムは、基本的には、実施の形態1に係る浸水報知システムに準ずる構成(図1~図8参照)を有する。ただし、実施の形態4に係る浸水報知システムでは、管理装置5が、図10に示した処理に代えて、図23に示す処理を実行するように構成される。図23は、実施の形態4において管理装置5が実行する浸水報知処理の手順を示すフローチャートである。なお、図23中のS11~S13は、図10中のS11~S13と同じである。図23の処理では、S12とS13との間で、S121およびS122が実行される。
管理装置5は、S121において、第2携帯端末2ごと(ひいては、乗員ごと)の通信規制量を決定し、S122において、決定された通信規制量による通信規制を各乗員の第2携帯端末2に指示する。各乗員の第2携帯端末2は、管理装置5からの指示(S122)に従って通信が規制されるように構成される。
この実施の形態では、第2携帯端末2が発信可能なデータ量の上限値(以下、「許容データ量」とも称する)を、通信規制量として採用する。管理装置5からの指示(S122)に従って第2携帯端末2に許容データ量が設定される。第2携帯端末2に許容データ量が設定されると、第2携帯端末2は、許容データ量を超えるデータ量を発信することができなくなる。許容データ量が小さいほど、通信規制量が多いことを意味する。データ量は、パケット量で規定されてもよい。第2携帯端末2に許容データ量が設定されないことは、第2携帯端末2の通信が規制されないこと(すなわち、通信規制量=0)を意味する。
以下、図24を参照して、通信規制量を決定する方法の一例について説明する。図24は、乗員ごとの許容データ量を示す図である。
図24に示すように、管理装置5は、許容データ量が異なる5つの規制区分を用いて、第2携帯端末2ごとの許容データ量(すなわち、通信規制量)を決定する。この実施の形態では、乗員のリーダーおよびサブリーダーが管理装置5に登録される。管理装置5は、乗員の属性(たとえば、リーダー、サブリーダー)を乗員IDに紐付けて管理する。乗員の属性は、記憶装置57(図5)に記憶され、乗員情報として管理される。管理装置5は、乗員情報に基づいて第2携帯端末2ごとの通信規制量を決定する。
図24の例では、乗員ID「U-ID1」で識別される乗員がリーダーである。また、乗員ID「U-ID2」で識別される乗員がサブリーダーである。リーダー(U-ID1)が携帯する第2携帯端末2は、規制区分1に割り振られる。規制区分1の第2携帯端末2には、許容データ量が設定されない。すなわち、規制区分1の通信規制量は0である。サブリーダー(U-ID2)が携帯する第2携帯端末2は、規制区分1の次に通信規制量が少ない規制区分2に割り振られる。
規制区分2~5を許容データ量が多いほうから順に並べると、規制区分2、3、4、5となる。リーダーおよびサブリーダーのいずれでもない乗員が携帯する第2携帯端末2は、浸水発生場所からの距離に応じて規制区分3~5に振り分けられる。たとえば、浸水発生場所からの距離が第1閾値未満である乗員(U-ID3、U-ID4、…)は、規制区分3に割り振られる。浸水発生場所からの距離が第1閾値以上第2閾値未満である乗員(U-ID5、U-ID6、…)は、規制区分4に割り振られる。浸水発生場所からの距離が第2閾値以上である乗員(U-ID7、U-ID8、…)は、規制区分5に割り振られる。
上記のように決定される通信規制量に従って第2携帯端末2の通信規制が行なわれることによって、無線通信における通信障害が抑制される。図24の例では、管理装置5からの指示に従い、リーダー以外の乗員が携帯する複数の第2携帯端末2で通信規制が行なわれる。しかしこれに限られず、管理装置5が通信規制を指示する第2携帯端末2の数は任意であり、1つであってもよい。
<利点>
以上のように、この実施の形態に係る浸水報知システムでは、管理装置5が、複数の第2携帯端末2から選択された一乃至複数の第2携帯端末2に通信規制を指示するように構成される(図23のS122)。複数の第2携帯端末2の各々は、管理装置5からの指示に従って通信が規制されるように構成される。
上記の構成によれば、管理装置5が第2携帯端末2に通信規制を指示することによって、第2携帯端末2の通信規制が行なわれる。こうした構成によれば、データ通信量が回線の許容量を超えることに起因する通信障害を抑制することができる。また、第2携帯端末2の通信規制は、リーダー以外の乗員が携帯する複数の第2携帯端末2のパケットの発信期間を制限する(たとえば、毎秒0.1秒~0.2秒の期間だけパケットの発信を許可する)ような形としてもよい。このようにすることで、リーダーの第2携帯端末2が発信するパケットが他のパケットと輻湊して発生する通信障害を抑制することができる。
管理装置5は、複数の第2携帯端末2のうち乗員のリーダーが携帯する第2携帯端末2(たとえば、図24に示すU-ID1)の発信可能なデータ量が他の第2携帯端末2よりも多くなるように上記の指示(図23のS122)を行なうように構成される。
リーダーが携帯する第2携帯端末2は、他の第2携帯端末2から多くの情報が送られてきたり、多くの指示を他の第2携帯端末2へ伝達したりする可能性が高い。上記のように、リーダーが携帯する第2携帯端末2の発信可能なデータ量を多くすることで、リーダーが他の乗員と連絡をとりやすくなる。
管理装置5は、複数の第2携帯端末2のうち浸水発生場所から遠くに位置する第2携帯端末2ほど発信可能なデータ量が少なくなるように上記の指示(図23のS122)を行なうように構成される。乗員は、浸水発生場所からの距離に応じて、図24に示す規制区分3~5に振り分けられる。浸水発生場所に近いほうから、規制区分3、4、5となるように振り分けられる。
浸水発生場所から遠くに位置する第2携帯端末2ほど、通信の緊急性が低下する傾向がある。上記のように、浸水発生場所から遠くに位置する第2携帯端末2の通信規制量を多くすることで、浸水発生場所に近い乗員が緊急の連絡を行ないやすくなる。
[実施の形態5]
本開示の実施の形態5に係る浸水報知システムについて説明する。実施の形態5は実施の形態1と共通する部分が多いため、主に相違点について説明し、共通する部分についての説明は割愛する。
実施の形態5に係る浸水報知システムでは、船舶100において浸水が発生したときに、管理装置5が、浸水に対する乗員ごとの初動対応の計画をリーダーに送信し、リーダーにより計画が承認されると、各乗員の第2携帯端末2へ計画を送信する。このため、各乗員は、リーダーに承認された計画に従って浸水に対する初動対応(排水、防水、隔壁閉鎖、救護など)を効率良く行なうことができる。より具体的には、実施の形態5に係る浸水報知システムは、基本的には、実施の形態1に係る浸水報知システムに準ずる構成(図1~図8参照)を有する。ただし、実施の形態5では、乗員のリーダーおよびサブリーダーが管理装置5に登録される。また、各乗員の名称(たとえば、氏名または通称)も管理装置5に登録される。管理装置5は、乗員の名称および属性(たとえば、リーダー、サブリーダー)を乗員IDに紐付けて管理する。乗員の名称および属性は、記憶装置57(図5)に記憶され、乗員情報として管理される。
さらに、実施の形態5に係る浸水報知システムでは、浸水報知モードにおいて、管理装置5と全ての第2携帯端末2とが図11の処理を実行しつつ、管理装置5と乗員のリーダーが携帯する第2携帯端末2(以下、「リーダー端末」とも称する)とが、さらに図25の処理を実行する。
図25は、実施の形態5の浸水報知モードにおけるリーダー端末および管理装置5の処理手順を示すフローチャートである。この実施の形態においても、第2携帯端末2および管理装置5によって図10の処理が実行され、各区画Bに設置された監視カメラ4のいずれかによって浸水が検出された場合(図10のS11にてYES)に、浸水報知モードに係る処理(この実施の形態では、図11の処理および図25の処理)が実行される。
S51では、管理装置5が、浸水映像(すなわち、浸水を検出した監視カメラ4の映像)に基づいて、浸水による危険度が許容レベルを超えるか否かを判断する。管理装置5は、浸水映像中の水面の高さ(水位)が高いほど、浸水による危険度が大きいと推定してもよい。管理装置5は、浸水が発生した位置(すなわち、浸水を検出した監視カメラ4が存在する区画B)が上甲板103(図1)に近いほど、浸水による危険度が大きいと推定してもよい。
浸水による危険度が許容レベルを超えない場合(S51にてNO)には、管理装置5は、S52において、浸水に対する乗員ごとの初動対応の計画(以下、「第1計画」とも称する)を作成し、S53において、作成した第1計画をリーダー端末へ送信して承認を依頼する。
リーダー端末は、S54において第1計画を受信した後、S55において、以下に説明する承認画面を表示することによってユーザ(すなわち、リーダー)に第1計画の承認を要求する。
図26は、実施の形態5の浸水報知モードにおいてリーダー端末が表示する承認画面の一例を示す図である。図26に示すように、この承認画面は、浸水に対する乗員ごとの初動対応の計画(初期においては、第1計画)を示す表M201と、メッセージM202と、承認ボタンM203と、変更ボタンM204と、船内図表示ボタンM205と、カメラ映像表示ボタンM206とを含む。
表M201によって示される計画は、乗員ごとの役割(たとえば、リーダー、防水、排水、隔壁閉鎖、レスキュー要請)を含む。この実施の形態では、リーダーが計画を理解しやすいように、乗員ID(U-ID*)だけでなく乗員の名称(**)も表M201中に記載される。なお、初動対応の計画における役割は任意であり、図26に示されていない役割(たとえば、救護、または浸水状況の監視)も設定可能である。時間帯ごとに各乗員の役割を変えてもよい。初動対応の計画は、時間帯別に乗員ごとの役割を定めるものであってもよい。
メッセージM202は、浸水発生時刻と、浸水発生場所と、承認画面に関する説明とを含む。ユーザ(すなわち、リーダー)は、船内図表示ボタンM205およびカメラ映像表示ボタンM206を操作することにより、リーダー端末に表示される画面を切り替えることができる。ユーザが船内図表示ボタンM205を押すと、各乗員の位置を示す船内図(たとえば、図12に示す画面M100)がリーダー端末に表示される。ユーザがカメラ映像表示ボタンM206を押すと、リアルタイムの浸水映像(たとえば、図13に示す浸水映像)がリーダー端末に表示される。
ユーザは、変更ボタンM204を操作することによって、第1計画を変更することができる。ユーザが変更ボタンM204を押すと、役割ごとに乗員(たとえば、乗員IDまたは乗員の名称)の入力が可能になる。リーダー端末は、乗員の選択肢を表示し、表示された選択肢からユーザが所望の乗員を選べるようにしてもよい。ユーザによって第1計画が変更されると、再び承認画面がリーダー端末に表示される。ただし、表M201には、変更後の計画(以下、「第2計画」とも称する)が表示されるようになる。計画の変更は何度でも可能であり、表M201には最新の第2計画が表示される。
ユーザは、承認ボタンM203を押すことによって、第1計画または第2計画を承認することができる。初期に表M201に表示された第1計画が変更されることなく、承認ボタンM203が押されると、第1計画が承認される。第1計画が変更され、表M201に第2計画が表示された状態で承認ボタンM203が押されると、第2計画が承認される。ユーザによって承認ボタンM203が押されると、処理が図25のS56に進む。
図25のS56では、第2携帯端末2が承認結果を管理装置5へ送信する。S55においてユーザによって第1計画が承認された場合には、第2携帯端末2は、第1計画を承認することを示す承認情報を、上記の承認結果として管理装置5へ送信する。S55においてユーザによって第2計画が承認された場合には、第2携帯端末2は、第2計画を上記の承認結果として管理装置5へ送信する。
管理装置5は、前述したS53の処理後、S57において、第2携帯端末2から承認結果を受信したか否かを判断し、S58において、S53で第1計画を送信してから所定時間が経過したか否かを判断する。所定時間は、固定値(たとえば、30秒以上10分以下の時間)であってもよいし、状況に応じて可変であってもよい。管理装置5は、S53で第1計画を送信してから所定時間が経過するまでの期間(以下、「待機期間」とも称する)において承認結果の受信を待つ。管理装置5が承認結果を受信しない間は、S57においてNOと判断され、処理がS58に進む。また、待機期間においてはS58でNOと判断され、処理がS57に戻る。
待機期間内に管理装置5が承認結果を受信すると(S57にてYES)、処理がS60に進む。S60では、管理装置5が、承認された計画を各乗員の第2携帯端末2へ送信する。承認結果が承認情報である場合には、承認された計画は第1計画であり、承認結果が第2計画である場合には、承認された計画は第2計画である。第2携帯端末2は、S60で送信された計画を受信すると、受信した計画(すなわち、第1計画または第2計画)を表示するように構成される。第2携帯端末2は、計画によって示される当該第2携帯端末2を携帯する乗員の役割を、図12に示す画面M100中の所定位置(たとえば、標題M101の横)に表示してもよい。
他方、管理装置5が承認結果を受信することなく待機期間が経過すると(S58にてYES)、管理装置5は、S59において、浸水に対する乗員ごとの初動対応の計画を、リーダーではない乗員の第2携帯端末2へ送信して、計画の承認を依頼する。その後、処理はS57に進み、S58の待機期間はリセットされ、管理装置5は、S57およびS58において再び承認結果の受信を待つ。
S59で送信される計画は、第1計画と同じであってもよいし、第1計画とは異なる計画であってもよい。S59で送信される計画は任意に設定できる。S59における送信相手(すなわち、リーダーではない乗員)も任意に設定できるが、この実施の形態では乗員のサブリーダーとする。
乗員のサブリーダーが携帯する第2携帯端末2(以下、「サブリーダー端末」とも称する)は、S59で送信された計画を受信すると、前述した承認画面(図26)を表示することによってユーザ(すなわち、サブリーダー)に計画の承認を要求する。管理装置5は、サブリーダー端末からも待機期間内に承認結果を受信しなかった場合には、S59において、浸水に対する乗員ごとの初動対応の計画を、さらに別の乗員(すなわち、リーダーでもサブリーダーでもない乗員)の第2携帯端末2へ送信して、計画の承認を依頼してもよい。
前述のS51において浸水による危険度が許容レベルを超える(YES)と判断された場合には、管理装置5は、S61において乗員ごとの避難計画を作成する。その後、管理装置5は、S62において、個別の避難計画を各乗員の第2携帯端末2へ送信した後、S63において、乗員全員の避難計画をリーダー端末へ送信する。
避難計画は、たとえば所定のプログラムによって作成される。この実施の形態に係る避難計画は、乗員ごとの避難経路(たとえば、実施の形態2と同様の方法で作成される最適な避難経路)を含む。避難計画は、各乗員に対する指示をさらに含んでもよい。乗員が複数人で行動できるように、避難経路中に乗員の合流地点が設定されてもよい。
第2携帯端末2は、S62で送信された個別の避難計画を受信すると、受信した避難計画を表示するように構成される。第2携帯端末2が受信した個別の避難計画には、当該第2携帯端末2を携帯する乗員の避難経路が含まれる。第2携帯端末2は、たとえば、図20に示す画面M100Aを表示し、ラインM71によって拡大マップM1A上に避難計画の避難経路を示す。第2携帯端末2が受信した個別の避難計画に指示が含まれる場合には、指示の内容が避難ガイダンスM72に表示されてもよい。また、画面M100A(図20)に表示切替ボタンM10(図12)を追加して、ユーザの操作によってリアルタイムの浸水映像を表示できるようにしてもよい。
リーダー端末は、S63で送信された乗員全員の避難計画を受信すると、以下に説明する避難用画面を表示するように構成される。図27は、実施の形態5の浸水報知モードにおいてリーダー端末が表示する避難用画面の一例を示す図である。
図27に示すように、この避難用画面は、メッセージM301と、船内図表示ボタンM302と、カメラ映像表示ボタンM303と、乗員ごとの避難経路ボタンM311,M312,M313,…と、乗員ごとの通話ボタンM321,M322,M323,…とを含む。
メッセージM301は、浸水発生時刻と、浸水発生場所と、避難用画面に関する説明とを含む。避難経路ボタンM311,M312,M313,…のいずれかが押されると、リーダー端末は、管理装置5から受信した避難計画を参照して、対応する乗員の避難経路を表示する。たとえば、図20に示す拡大マップM1Aがリーダー端末に表示されてもよい。通話ボタンM321,M322,M323,…のいずれかが押されると、リーダー端末は、対応する乗員の第2携帯端末2と通話(たとえば、WiFi通話)を行なう。各乗員の第2携帯端末2の電話番号および通信アドレスは、予めリーダー端末に登録されている。各避難経路ボタンおよび各通話ボタンの横には、対応する乗員の識別情報が表示されている。この実施の形態では、リーダーが乗員を認識しやすいように、乗員ID(U-ID*)だけでなく乗員の名称(**)も記載されている。なお、避難用画面は、通話ボタンに代えてまたは加えて、各乗員の第2携帯端末2と電子メールを行なうための電子メールボタンを含んでもよい。
ユーザ(すなわち、リーダー)は、船内図表示ボタンM302およびカメラ映像表示ボタンM303を操作することにより、リーダー端末に表示される画面を切り替えることができる。ユーザが船内図表示ボタンM302を押すと、リーダー自身の避難経路を示す船内図がリーダー端末に表示される。たとえば、図20に示す拡大マップM1Aがリーダー端末に表示されてもよい。ユーザがカメラ映像表示ボタンM303を押すと、リアルタイムの浸水映像(たとえば、図13に示す浸水映像)がリーダー端末に表示される。
<利点>
以上のように、この実施の形態に係る浸水報知システムでは、各区画Bに設置された監視カメラ4のいずれかによって浸水が検出された場合(図10のS11にてYES)に、管理装置5が図11の処理および図25の処理を実行し(図10のS13)、浸水情報(図11のS22)に加えて第1計画(図25のS53)をリーダー端末(すなわち、乗員のリーダーが携帯する第2携帯端末2)へ送信するように構成される。リーダー端末は、管理装置5から第1計画を受信した場合(図25のS54)に承認結果(すなわち、第1計画を承認することを示す承認情報と、第1計画を変更した第2計画とのいずれか一方)を管理装置5へ返信する(図25のS56)ように構成される。管理装置5は、承認情報を受信した場合には第1計画を複数の第2携帯端末2の各々へ送信し、第2計画を受信した場合には第2計画を複数の第2携帯端末2の各々へ送信するように構成される(図25のS57およびS60)。
上記の浸水報知システムによれば、浸水が発生したときに、リーダーに承認された計画が各乗員の第2携帯端末2へ円滑に送信されるようになる。各乗員は、リーダーに承認された計画(すなわち、第1計画または第2計画)に従って浸水に対する初動対応(排水、防水、隔壁閉鎖、救護など)を効率良く行なうことができる。
管理装置5は、リーダー端末へ第1計画を送信してから所定時間が経過してもリーダー端末からの返信が来ない場合(S58にてYES)には、当該浸水報知システムが備える複数の第2携帯端末2のうちリーダーではない乗員(たとえば、サブリーダー)が携帯する第2携帯端末2に、浸水に対する乗員ごとの初動対応の計画を送信して承認を依頼する(図25のS59)ように構成される。
上記の構成によれば、浸水が発生したときに、何らかの事情によってリーダーが計画の承認を行なうことができない場合に、他の乗員(たとえば、サブリーダー)の承認によって計画を遂行することが可能になる。
この実施の形態では、第1計画および第2計画の各々が、乗員ごとの役割を含む(図26)。当該浸水報知システムが備える複数の第2携帯端末2の各々は、管理装置5から第1計画および第2計画のいずれかの計画を受信した場合に、第2携帯端末2を携帯する乗員の役割を表示可能に構成される。
上記の構成によれば、浸水が発生したときに、第2携帯端末2に乗員の役割が表示される。これにより、各乗員が決められた役割を迅速に遂行することが可能になる。
管理装置5は、各区画Bに設置された監視カメラ4のいずれかによって浸水が検出された場合(図10のS11にてYES)において図25の処理を実行し(図10のS13)、浸水を検出した監視カメラ4の映像に基づいて浸水による危険度を推定し、危険度が許容レベルを超える場合(図25のS51にてYES)には、第1計画の代わりに乗員ごとの避難計画をリーダー端末に送信する(図25のS63)ように構成される。
上記の構成によれば、浸水による危険度が大きい場合に、初動対応よりも避難を優先すべきことをリーダーに伝えることができる。
[他の実施の形態]
図12には、本人位置および浸水発生場所を示す船内図を表示し、かつ、浸水映像を表示しない画面M100を例示したが、本人位置および浸水発生場所を示す船内図と、リアルタイムの浸水映像との両方が、1つの画面上に同時に表示されるようにしてもよい。
上記各実施の形態に係る浸水報知システムでは、受信機3として固定式受信機を採用したが、浸水報知システムにおける複数の受信機は、可搬式受信機であってもよいし、自走式受信機であってもよい。
携帯端末(たとえば、第1携帯端末1および第2携帯端末2)は、携帯端末ごとに固有の識別情報(以下、「端末ID」とも称する)を管理装置5へ送信してもよい。管理装置5は、端末IDと乗員IDとを関連付ける変換情報(たとえば、テーブル)を保有してもよい。こうした構成では、変換情報によって端末IDが乗員IDに変換される。このため、端末IDが乗員IDとして機能する。
上記各実施の形態に係る浸水報知システムでは、位置検出用の信号(たとえば、Aパケット)を発信する発信機14が、第1携帯端末1に内蔵され、第2携帯端末2とは別に乗員に携帯される。しかしこれに限られず、位置検出用の信号を発信する発信機は、第2携帯端末2に内蔵されてもよい。
第2携帯端末2はウェアラブル端末であってもよい。第2携帯端末2としてウェアラブル端末を採用することで、第2携帯端末2が乗員の身体から離れた位置に置かれることが抑制される。第2携帯端末2の表示方式はプロジェクション方式であってもよい。通信C1,C2,C3(図5)の各々の通信方式も適宜変更可能である。
今回開示された実施の形態がすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。