(57)【要約】  一態様に係るメッセージ送受信方法は、ブローカーを介してパブリッシャーとサブスクライバーとの間でメッセージ交換を行う出版購読システムにおいて、前記パブリッシャーにより出版されたメッセージを管理するミドルウェア部と、前記ブローカーを提供する関数を含むライブラリを記憶する記憶部と、を備える通信装置において実行されるものであって、前記ミドルウェア部が、コールバック関数の設定により前記ブローカーに対して購読を行う過程と、前記ブローカーが、デバイスにより出版された第１のメッセージを受信したときに、前記コールバック関数を呼び出すことにより、前記第１のメッセージを前記ミドルウェア部に渡す過程と、を備える。
2020158154.tif 000002
【特許請求の範囲】
【請求項１】
ブローカーを介してパブリッシャーとサブスクライバーとの間でメッセージ交換を行う出版購読システムにおいて、前記パブリッシャーにより出版されたメッセージを管理するミドルウェア部と、前記ブローカーを提供する関数を含むライブラリを記憶する記憶部と、を備える通信装置において実行されるメッセージ送受信方法であって、
前記ミドルウェア部が、コールバック関数の設定により前記ブローカーに対して購読を行う過程と、
前記ブローカーが、デバイスにより出版された第１のメッセージを受信したときに、前記コールバック関数を呼び出すことにより、前記第１のメッセージを前記ミドルウェア部に渡す過程と、
を備えるメッセージ送受信方法。
【請求項２】
前記ミドルウェア部が、前記コールバック関数が呼び出されたときに、前記第１のメッセージの保存を含む所定の処理が成功したか否かを戻り値に指定して関数を返す過程と、
前記ブローカーが、前記ミドルウェア部により返された前記関数に応じて、前記第１のメッセージが前記ミドルウェア部に到達したか否かを示す情報を前記デバイスに送信する過程と、
をさらに備える請求項１に記載のメッセージ送受信方法。
【請求項３】
前記ミドルウェア部が、関数呼び出しにより前記ブローカーに対して第２のメッセージの出版を行う過程
をさらに備える請求項１又は２に記載のメッセージ送受信方法。
【請求項４】
前記ブローカーが、前記第２のメッセージが前記デバイスに到達したか否かを戻り値に指定した関数を返す過程
をさらに備える請求項３に記載のメッセージ送受信方法。
【請求項５】
前記ミドルウェア部が、関数呼び出しにより前記ブローカーから前記デバイスの状態を示すデバイス状態情報を取得する過程
をさらに備える請求項１乃至４のいずれか１項に記載のメッセージ送受信方法。
【請求項６】
前記デバイス状態情報は、前記デバイスとの接続状態を示すセッション情報と前記デバイスの死活状態を示す死活情報との少なくとも一方を含む、請求項５に記載のメッセージ送受信方法。
【請求項７】
請求項１乃至６のいずれか１項に記載のメッセージ送受信方法をコンピュータに実行させるプログラム。
【請求項８】
ブローカーを介してパブリッシャーとサブスクライバーとの間でメッセージ交換を行う出版購読システムにおいて、前記パブリッシャーにより出版されたメッセージを管理するミドルウェア部と、
前記ブローカーを提供する関数を含むライブラリを記憶する記憶部と、
を備え、
前記ミドルウェア部が、コールバック関数の設定により前記ブローカーに対して購読を行い、
前記ブローカーが、デバイスにより出版された第１のメッセージを受信したときに、前記コールバック関数を呼び出すことにより前記第１のメッセージを前記ミドルウェア部に渡す、通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイスが生成したデータを出版購読モデルによりメッセージとして送受信する技術に関する。
【背景技術】
【０００２】
ＩｏＴ（Internet of Things）の普及に伴い、センサなどの多くのデバイスがデータの送受信を行う機能を備えるようになっている。多数のデバイス及びデバイスを管理するアプリケーションが個別に通信を行うと、通信相手が膨大になってしまい、通信相手を特定することが非常に手間である。【０００３】
そこで、個別に通信相手を特定することなしにメッセージのやり取りを行うブローカーベースの出版購読モデルの利便性が注目されており、近年、出版購読モデルがＩｏＴシステムの多くで採用されている。【０００４】
出版購読モデルを採用したＩｏＴシステムでは、パブリッシャー及びサブスクライバーが均質に分布するとは限らない。このため、ブローカーとアプリケーションとの間にすべてのメッセージを購読して一時的に保存するサーバが設けられることがある（例えば、非特許文献１、２を参照）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】中村優吾、外４名、「多様なＩｏＴデータストリームをクラウドレスで分散処理するミドルウェアの設計」、研究報告モバイルコンピューティングとパーベイシブシステム（ＭＢＬ） 2015.22 (2015): 1-8
【非特許文献２】L. Atozori et al, “Internet of the Things: A Survey”, Computer Networks 54 (2010) 2787-2805
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述したサーバを備えるＩｏＴシステムでは、ブローカーとサーバとの間のトラフィックが多くなり、輻輳が生じやすいといった問題がある。これはＩｏＴシステムの信頼性の低下につながる。【０００７】
本発明は、上記の事情に着目してなされたものであり、その目的は、高信頼なＩｏＴシステムを実現可能にする技術を提供することである。
【課題を解決するための手段】
【０００８】
本発明の第１の態様では、メッセージ送受信方法は、ブローカーを介してパブリッシャーとサブスクライバーとの間でメッセージ交換を行う出版購読システムにおいて、前記パブリッシャーにより出版されたメッセージを管理するミドルウェア部と、前記ブローカーを提供する関数を含むライブラリを記憶する記憶部と、を備える通信装置において実行されるものであって、前記ミドルウェア部が、コールバック関数の設定により前記ブローカーに対して購読を行う過程と、前記ブローカーが、デバイスにより出版された第１のメッセージを受信したときに、前記コールバック関数を呼び出すことにより、前記第１のメッセージを前記ミドルウェア部に渡す過程と、を備える。【０００９】
本発明の第２の態様では、前記メッセージ送受信方法は、前記ミドルウェア部が、前記コールバック関数が呼び出されたときに、前記第１のメッセージの保存を含む所定の処理が成功したか否かを戻り値に指定して関数を返す過程と、前記ブローカーが、前記ミドルウェア部により返された前記関数に応じて、前記第１のメッセージが前記ミドルウェア部に到達したか否かを示す情報を前記デバイスに送信する過程と、をさらに備える。【００１０】
本発明の第３の態様では、前記メッセージ送受信方法は、前記ミドルウェア部が、関数呼び出しにより前記ブローカーに対して第２のメッセージの出版を行う過程をさらに備える。【００１１】
本発明の第４の態様では、前記メッセージ送受信方法は、前記ブローカーが、前記第２のメッセージが前記デバイスに到達したか否かを戻り値に指定した関数を返す過程をさらに備える。【００１２】
本発明の第５の態様では、前記メッセージ送受信方法は、前記ミドルウェア部が、関数呼び出しにより前記ブローカーから前記デバイスの状態を示すデバイス状態情報を取得する過程をさらに備える。【００１３】
本発明の第６の態様では、前記デバイス状態情報は、前記デバイスとの接続状態を示すセッション情報と前記デバイスの死活状態を示す死活情報との少なくとも一方を含む。
【発明の効果】
【００１４】
第１の態様によれば、ミドルウェア部及びブローカーが別々の装置に設けられる場合に生じるような輻輳が緩和される。その結果、信頼性の高いＩｏＴシステムを実現することができる。【００１５】
第２の態様によれば、ミドルウェア部とデバイスとの間の到達保証を行うことができるようになる。その結果、ＩｏＴシステムの信頼性がより向上する。【００１６】
第３の態様よれば、ミドルウェア部がデバイスを制御するための制御指令などの情報をデバイスに提供することが可能になる。【００１７】
第４の態様によれば、ミドルウェア部とデバイスとの間の到達保証を行うことができるようになる。その結果、ＩｏＴシステムの信頼性がより向上する。【００１８】
第５の態様によれば、ミドルウェア部がデバイス状態情報をリアルタイムに取得することが可能になる。その結果、ＩｏＴシステムの信頼性がより向上する。【００１９】
第６の態様によれば、ミドルウェア部がメッセージ送信先であるデバイスが通信できる状態にあるか否かをリアルタイムに判断でき、メッセージがデバイスに到達する可能性が向上する。その結果、ＩｏＴシステムの信頼性がより向上する。【００２０】
要するに、本発明によれば、高信頼なＩｏＴシステムを実現可能にする技術を提供することができる。
【図面の簡単な説明】
【００２１】
【図１】図１は、本発明の一実施形態に係る通信システムを示すブロック図である。
【図２】図２は、図１に示した通信装置を示すブロック図である。
【図３】図３は、図２に示したミドルウェア部が出版を行う際のシーケンス図である。
【図４】図４は、図２に示したミドルウェア部が購読を行う際のシーケンス図である。
【図５】図５は、関連技術に係る通信システムを説明するブロック図である。
【図６】図６は、関連技術に係る通信システムを説明するブロック図である。
【発明を実施するための形態】
【００２２】
以下、図面を参照しながら本発明の実施形態を説明する。
【００２３】
＜関連技術＞
まず、図５及び図６を参照して関連技術に係る通信システムついて説明する。
【００２４】
図５は、関連技術に係る通信システム５０を概略的に示している。図５に示す通信システム５０は、ブローカーを介してパブリッシャーとサブスクライバーとの間でメッセージ交換を行うブローカーベースの出版購読（Ｐｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ；Ｐｕｂ／Ｓｕｂ）システムを含むＩｏＴシステムである。
【００２５】
Ｐｕｂ／Ｓｕｂシステムでは、ブローカーは、パブリッシャーとサブスクライバーとの間でメッセージを中継する。パブリッシャーはメッセージ送信者を指す。パブリッシャーは、トピックに対してメッセージを出版する（publish）。具体的には、パブリッシャーは、出版対象となるトピックを指定し、指定したトピックを示すトピック情報とデータとを含むメッセージをブローカーに送信する。サブスクライバーはメッセージ受信者を指す。サブスクライバーは興味のあるトピックを購読する（subscribe）。具体的には、サブスクライバーは、ブローカーに対して、興味のあるトピックの購読を登録する。ブローカーは、パブリッシャーからメッセージを受信すると、このメッセージを一時的に保存するとともに、このメッセージを、パブリッシャーが指定したトピックを購読しているサブスクライバーに送信する。
【００２６】
通信システム５０は、ミドルウェア部５１、ブローカー５２、デバイス５５、及びアプリケーション５６を備える。図５においては、デバイス５５として３つのデバイス５５−１、５５−２、５５−３が示され、アプリケーション５６として３つのアプリケーション５６−１、５６−２、５６−３が示されている。
【００２７】
ブローカー５２は、Ｐｕｂ／Ｓｕｂシステムにおけるブローカーである。ブローカー５２は、サーバなどのコンピュータ端末に実装される。ブローカー５２は、コンピュータ端末においてブローカープログラムを実行することにより実現される。
【００２８】
デバイス５５は、パブリッシャーとサブスクライバーとの少なくとも一方の機能を有する。例えば、デバイス５５−１はパブリッシャーの機能を有し、デバイス５５−２はパブリッシャー及びサブスクライバーの機能を有し、デバイス５５−１はサブスクライバーの機能を有する。例えば、デバイス５５−１は、センサを備え、センサによって生成されたセンサデータとトピック情報とを含むメッセージをブローカー５２に送信する。
【００２９】
ミドルウェア部５１は、ブローカー５２を実装するコンピュータ端末とは異なる、サーバなどのコンピュータ端末に実装される。ミドルウェア部５１は、コンピュータ端末においてプログラムであるＩｏＴミドルウェアを実行することにより実現される。
【００３０】
ミドルウェア部５１は、パブリッシャー及びサブスクライバーの機能を有し、Ｐｕｂ／Ｓｕｂモデルでブローカー５２と通信する。さらに、ミドルウェア部５１は、Ｐｕｂ／Ｓｕｂモデルとは異なるプロトコルでアプリケーション５６と通信する。アプリケーション５６は、ミドルウェア部５１を実装するコンピュータ端末とは異なるコンピュータ端末に実装される。
【００３１】
ミドルウェア部５１は、デバイス５５上のパブリッシャーにより出版されたメッセージを管理する。ミドルウェア部５１はすべてのトピックを購読する。これにより、デバイス５５により出版されたメッセージはすべて、ブローカー５２を通じてミドルウェア部５１へ伝送されることになる。ミドルウェア部５１は、アプリケーション５６から、購読したいトピックを示すトピック情報を受信する。ミドルウェア部５１は、アプリケーション５６から受信したトピック情報に基づいて、デバイス５５により出版されたメッセージを配信する。例えば、ミドルウェア部５１は、あるトピックに対して出版されたメッセージを受信すると、このメッセージを、そのトピックを購読することを望むアプリケーション５６に送信する。
【００３２】
アプリケーション５６−１がデバイス５５−２を制御するものである場合を想定する。アプリケーション５６−１は、デバイス５５−２を制御するための制御指令を含む制御信号をミドルウェア部５１に送信する。ミドルウェア部５１は、アプリケーション５６−１から制御信号を受信すると、デバイス５５−２が購読しているトピックに対して、制御指令を含むメッセージを出版する。ブローカー５２は、ミドルウェア部５１により出版されたメッセージを受信すると、このメッセージを、デバイス５５−２に送信する。デバイス５５−２は、ブローカー５２からメッセージを受信し、受信したメッセージに含まれるアプリケーション５６−１による制御指令に従って動作する。
【００３３】
関連技術に係る通信システム５０では、ブローカー５２は、コンピュータ端末において１つのプログラムを実行することにより実現され、他のモジュール（例えばミドルウェア部５１）とはネットワークを介して通信を行う。
【００３４】
上述した構成を有する通信システム５０では、以下に説明する３つの課題がある。
【００３５】
１．例えば、デバイス５５上のパブリッシャーは、ミドルウェア部５１がメッセージの保存を完了したかどうかを確認し、ミドルウェア部５１がメッセージの保存を完了していない場合にメッセージを再送する処理などを行いたいことがある。しかしながら、デバイス５５上のパブリッシャーとミドルウェア部５１との間でメッセージの到達保証を行うことが難しい。これは、Ｐｕｂ／Ｓｕｂシステムでは、パブリッシャーとブローカーとの間及びサブスクライバーとブローカーとの間のみの通信完了確認がなされることが一般的であるためである。具体的には、通信の完了を示す肯定応答情報を返答することで、二者間の通信が完了していることを示す到達保証が可能である。パブリッシャーとサブスクライバーとの間の到達保証を行うためには、三者での完了通知が必要になり、シーケンスが複雑化する。また、単に通信の完了だけでなく、データ保存を含む処理の完了も保証されることが望まれることがあり、この場合、シーケンスがさらに複雑になる。
【００３６】
２．デバイス５５との接続状態などのデバイス５５の状態を示すデバイス状態情報はブローカー５２に存在する。このため、ミドルウェア部５１がデバイスが通信できる状態にあるか否かを確認することが難しい。
【００３７】
３．ミドルウェア部５１とブローカー５２との間のトラフィックが大きくなり、輻輳が生じやすい。
【００３８】
ここで、上述した通信システム５０におけるミドルウェア部５１及びブローカー５２の機能について詳細に説明する。
【００３９】
図６を参照すると、ブローカー５２は、メッセージ配送部５２１を備える。メッセージ配送部５２１は、セッション管理部５２２及び応答部５２３を備える。
【００４０】
メッセージ配送部５２１は、Ｐｕｂ／ＳｕｂＡＰＩ（Application Programming Interface）を利用してデバイス５５からメッセージを受信する。メッセージ配送部５２１は、Ｐｕｂ／ＳｕｂＡＰＩを利用して、受信したメッセージをミドルウェア部５１に送信する。
【００４１】
さらに、メッセージ配送部５２１は、Ｐｕｂ／ＳｕｂＡＰＩを利用してデバイス制御部５１１からメッセージを受信する。メッセージ配送部５２１は、Ｐｕｂ／ＳｕｂＡＰＩを利用して、受信したメッセージを適切なデバイス５５に送信する。デバイス５５は、ブローカー５２からメッセージを受信してメモリに保存したときに、メッセージを正常に受信したことを示す肯定応答（acknowledgement）情報をブローカー５２に送信する。
【００４２】
セッション管理部５２２は、デバイス５５の状態を示すデバイス状態情報を保持し管理する。デバイス状態情報は、デバイス５５との接続状態を示すセッション情報を含む。さらに、セッション管理部５２２は、各デバイス５５がどのトピックを購読しているかを示す購読情報を保持し管理する。
【００４３】
応答部５２３は、メッセージ配送部５２１がミドルウェア部５１からメッセージを受信してデータベースに保存したときに、肯定応答情報をミドルウェア部５１に送信する。さらに、応答部５２３は、メッセージ配送部５２１がデバイス５５からメッセージを受信してデータベースに保存したときに、肯定応答情報をミドルウェア部５１に送信する。
【００４４】
ミドルウェア部５１は、デバイス制御部５１１、デバイス状態管理部５１２、及びデータ保存部５１３を備える。
【００４５】
データ保存部５１３は、ブローカー５２からメッセージを受信し、受信したメッセージに含まれるデータをデータベースに一時的に保存する。データ保存部５１３は、データベースから、過去に保存したデータなどのデータを読み出すことができる。ミドルウェア部５１は、非Ｐｕｂ／ＳｕｂＡＰＩを利用して、アプリケーション５６に、データ保存部５１３により読み出されたデータを提供する。
【００４６】
ミドルウェア部５１は、ブローカー５２に対してすべてのトピックの購読を登録する。これにより、デバイス５５により出版されたデータがすべてミドルウェア部５１に到着してデータベースに保存されることになる。このとき、上記の課題１、すなわち、デバイス５５がミドルウェア部５１においてデータをデータベースに保存できたかどうかを確認することができないという課題が生じる。Ｐｕｂ／Ｓｕｂシステムにおいて、通信が正常に完了したかを判断するのはブローカー５２であるので、ミドルウェア部５１がメッセージを受信してその保存を完了できたかといったトランザクションに関しては考慮されない。あくまで、デバイス５５には、デバイス５５とブローカー５２との間の通信が成功したか否かを示す情報しか通知されない。また、すべてのメッセージがミドルウェア部５１に受け渡されるため、ミドルウェア部５１とブローカー５２との間でトラフィックが大きくなり、上記の課題３も生じることになる。
【００４７】
デバイス状態管理部５１２は、ブローカー５２からデバイス状態情報を取得する。デバイス状態管理部５１２は、デバイス状態情報に基づいて各デバイス５５が通信できる状態にあるか否かを判断する。Ｐｕｂ／Ｓｕｂシステムでは、一般に、ミドルウェア部５１とブローカー５２との間にデバイス状態情報をやり取りするＡＰＩがない。このため、ミドルウェア部５１がデバイス状態情報をリアルタイムに取得することはできない。言い換えると、ミドルウェア部５１は、現在のデバイスの状態を知ることができない。これにより、上記の課題２が生じる。
【００４８】
デバイス制御部５１１はデバイス５５を制御するものである。デバイス制御部５１１は、非Ｐｕｂ／ＳｕｂＡＰＩを利用して、アプリケーション５６から制御信号を取得する。非Ｐｕｂ／ＳｕｂＡＰＩは、Ｐｕｂ／ＳｕｂＡＰＩとは異なる任意のＡＰＩである。制御信号は、制御対象のデバイス５５を示す制御対象情報と、デバイス５５を制御するための制御指令と、を含む。制御対象のデバイス５５が制御指令を受信できる状態にあるとデバイス状態管理部５１２が判断する場合に、デバイス制御部５１１は、Ｐｕｂ／ＳｕｂＡＰＩを利用して、ブローカー５２に、制御指令を含むメッセージを送信する。ブローカー５２は、ミドルウェア部５１から受信したメッセージを制御対象のデバイス５５に送信する。このときにも、課題１が生じる。すなわち、ミドルウェア部５１は、ブローカー５２がメッセージを正常に受信したか否かを確認することはできるが、制御対象のデバイス５５がメッセージを正常に受信したか否かを確認することはできない。さらに、課題２にあるように、ミドルウェア部５１は、デバイス状態情報をリアルタイムに取得することができないので、制御対象のデバイス５５が現在通信可能な状態にあるか否かを把握することができない。このため、状況がより複雑化する。
【００４９】
＜実施形態＞
次に、本発明の実施形態に係る通信システムについて説明する。
【００５０】
一実施形態は、ブローカーをライブラリとしてＩｏＴミドルウェアに組み込むことにより、上記の課題を解決する。ブローカーは、共有ライブラリとして用意され、ＩｏＴミドルウェア（ソフトウェア）にバイナリレベルでリンクされる。ミドルウェア部及びブローカーが同一プロセスとして動作する。言い換えると、ミドルウェア部及びブローカーは各々同一バイナリの一部分である。
【００５１】
［構成］
図１は、本発明の一実施形態に係る通信システム１０を概略的に示している。図１に示す通信システム１０は、ブローカーベースのＰｕｂ／Ｓｕｂシステムを含むＩｏＴシステムである。
【００５２】
通信システム１０は、通信装置１１、デバイス１５、及びアプリケーション１６を備える。図１においては、デバイス１５として３つのデバイス１５−１、１５−２、１５−３が示され、アプリケーション１６として３つのアプリケーション１６−１、１６−２、１６−３が示されている。デバイス１５−１、１５−２、１５−３はそれぞれ図５に示したデバイス５５−１、５５−２、５５−３と同様のものであり、アプリケーション１６−１、１６−２、１６−３はそれぞれ図５に示したアプリケーション５６−１、５６−２、５６−３と同様のものである。
【００５３】
通信装置１１は、サーバのようなコンピュータ端末であり得る。通信装置１１は、ハードウェア要素として、ＣＰＵ（Central Processing Unit）１２、記憶部としてのメモリ１３、及び通信インタフェース１４を備える。
【００５４】
ＣＰＵ１２は、プロセッサの一例である。メモリ１３は、主記憶装置及び補助記憶装置を含む。主記憶装置は、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）などの揮発性メモリであり、ワーキングメモリとしてＣＰＵ１２に使用される。補助記憶装置は、ハードディスクドライブ（ＨＤＤ）又はソリッドステートドライブ（ＳＳＤ）などの不揮発性メモリであり、ＩｏＴミドルウェア１３１などのプログラム、プログラムを実行するために必要なデータ、パブリッシャーにより出版されたメッセージに含まれるデータ（例えばセンサデータ）、デバイス状態情報、購読情報などを記憶する。
【００５５】
通信インタフェース１４は、外部装置（例えばデバイス１５やアプリケーション１６など）と通信するためのインタフェースである。
【００５６】
図２を参照すると、通信装置１１はミドルウェア部１３３及びブローカー１３４を備える。ミドルウェア部１３３は、ＣＰＵ１２においてＩｏＴミドルウェア１３１を実行することにより実現される。図１に示すように、ＩｏＴミドルウェア１３１には、ブローカーライブラリ１３２が組み込まれている。ブローカーライブラリ１３２はバイナリレベルでＩｏＴミドルウェア１３１にリンクされる。ブローカーライブラリ１３２は、ブローカー１３４を提供する関数を含む。この関数は、メッセージを送信する関数publish()を含む複数の関数により構成される。ＩｏＴミドルウェア１３１は、ＣＰＵ１２により実行されると、ＣＰＵ１２をミドルウェア部１３３及びブローカー１３４として動作させる。
【００５７】
ブローカー１３４は、Ｐｕｂ／Ｓｕｂシステムにおけるブローカーである。具体的には、ブローカー１３４は、パブリッシャーとサブスクライバーとの間でメッセージを中継する。
【００５８】
ミドルウェア部１３３は、デバイス１５上のパブリッシャーにより出版されたメッセージを管理する。ミドルウェア部１３３は、関数呼び出し（関数コール）によりブローカー１３４との間で通信を行う。例えば、ミドルウェア部１３３は、サブスクライバーとして動作するときには、コールバック関数を設定することによりブローカー１３４に対して購読を行う。ミドルウェア部１３３は、パブリッシャーとして動作するときには、関数呼び出しによりブローカー１３４に対して出版を行う。
【００５９】
ミドルウェア部１３３は、Ｐｕｂ／Ｓｕｂモデルとは異なるプロトコルでアプリケーション１６と通信する。アプリケーション１６は、通信装置１１とは異なるコンピュータ端末に実装される。
【００６０】
ミドルウェア部１３３はすべてのトピックを購読する。この場合、デバイス１５により出版されたメッセージはすべてブローカー１３４を介してミドルウェア部１３３へ伝送されることになる。ミドルウェア部１３３は、コールバック関数として関数subscribe_callback()を設定する。ブローカー１３４は、デバイス１５からメッセージを受信すると、メッセージに含まれるトピック情報及びデータを引数topic及びpayloadに指定してコールバック関数を呼び出す。これにより、ミドルウェア部１３３がデバイス５５により出版されたメッセージを取得する。ミドルウェア部１３３は、アプリケーション１６から、購読したいトピックを示すトピック情報を受信する。ミドルウェア部１３３は、アプリケーション１６から受信したトピック情報に基づいて、デバイス１５により出版されたメッセージを配信する。例えば、ミドルウェア部１３３は、デバイス１５によりあるトピックに対して出版されたメッセージを受信すると、このメッセージを、そのトピックを購読することを望むアプリケーション１６に送信する。ミドルウェア部１３３は、デバイス１５により出版されたメッセージに含まれるデータを、アプリケーション１６が利用可能なフォーマットに変換してよい。
【００６１】
アプリケーション１６−１がデバイス１５−２を制御するものである場合を想定する。アプリケーション１６−１は、デバイス１５−２を制御するための制御指令を含む制御信号をミドルウェア部１３３に送信する。ミドルウェア部１３３は、アプリケーション１６−１から制御信号を受信すると、制御指令を引数payloadに指定し、デバイス１５−２が購読しているトピックを示すトピック情報を引数topicに指定して、関数publish()を呼び出す。これにより、ブローカー１３４がデバイス１５−２にトピック情報と制御指令とを含むメッセージを送信する。デバイス１５−２は、ブローカー１３４からメッセージを受信し、受信したメッセージに含まれるアプリケーション１６−１による制御指令に従って動作する。
【００６２】
図２に示すように、ブローカー１３４は、メッセージ配送部１３４１を備える。メッセージ配送部１３４１は、セッション管理部１３４２及び応答部１３４３を備える。メッセージ配送部１３４１、セッション管理部１３４２、及び応答部１３４３は、関数としてブローカーライブラリ１３２に用意される。
【００６３】
メッセージ配送部１３４１は、Ｐｕｂ／ＳｕｂＡＰＩを利用してデバイス１５からメッセージを受信する。そして、メッセージ配送部１３４１は、デバイス１５から受信したメッセージをミドルウェア部１３３に渡す。具体的には、メッセージ配送部１３４１は、デバイス１５から受信したメッセージに含まれるトピック情報及びデータを指定してコールバック関数subscribe_callback()を呼び出す。
【００６４】
メッセージ配送部１３４１は、Ｐｕｂ／ＳｕｂＡＰＩを利用してデバイス１５にメッセージを送信する。具体的には、ミドルウェア部１３３がトピック情報及びデータ（例えば制御指令）を指定して関数publish()を呼び出す。それにより、トピック情報及びデータを含むメッセージがデバイス１５に送信される。
【００６５】
セッション管理部１３４２は、デバイス１５の状態を示すデバイス状態情報を管理する。デバイス状態情報は、デバイス１５との接続状態を示すセッション情報を含む。具体的には、セッション情報は、デバイス１５ごとに、デバイス１５と通信装置１１との間のセッションが確立中であるか否かを示す。なお、デバイス状態情報は、セッション情報に代えて又は追加して、デバイス１５の死活状態（正常性）を示す死活情報を含んでもよい。さらに、セッション管理部１３４２は各デバイス１５がどのトピックを購読しているかを示す購読情報を管理する。ミドルウェア部１３３は、セッション管理部１３４２に相当する関数を呼び出すことによりデバイス情報及び購読情報を取得する。
【００６６】
応答部１３４３は、ミドルウェア部１３３により出版されたメッセージがデバイス１５に到達したか否かを示す情報をミドルウェア部１３３に渡す。具体的には、応答部１３４３は、ミドルウェア部１３３により出版されたメッセージを送信してから所定の時間が経過するまでの間にデバイス１５から肯定応答情報を受信した場合に、メッセージがデバイス１５に到達したことを戻り値に指定した関数をミドルウェア部１３３に返す。また、応答部１３４３は、ミドルウェア部１３３により出版されたメッセージを送信してから所定の時間が経過するまでにデバイス１５から肯定応答情報を受信できなかった場合に、メッセージがデバイス１５に到達しなかったことを戻り値に指定した関数をミドルウェア部１３３に返す。
【００６７】
ミドルウェア部１３３は、デバイス制御部１３３１、デバイス状態管理部１３３２、及びデータ保存部１３３３を備える。
【００６８】
データ保存部１３３３は、デバイス１５により出版された、トピック情報とデータ（例えばセンサデータ）とを含むメッセージをデータベースに一時的に保存する。例えば、データ保存部１３３３は、データをトピック情報に対応付けてデータベースに一時的に保存する。上述したように、デバイス１５により出版されたメッセージはブローカー１３４に対して設定されたコールバック関数によりブローカー１３４からミドルウェア部１３３へ渡される。データ保存部１３３３は、データベースから、過去に保存したデータなどのデータを読み出す。ミドルウェア部１３３は、非Ｐｕｂ／ＳｕｂＡＰＩを利用して、適切なアプリケーション１６に、データ保存部１３３３により読み出されたデータを提供する。
【００６９】
ミドルウェア部１３３は、ブローカー１３４からのメッセージに応答して、データ保存部１３３３によるメッセージの保存を含む所定の処理が成功したか否か、すなわち、メッセージを正常に受信できたか否かをブローカー１３４に通知する。ミドルウェア部１３３は、データ保存部１３３３がメッセージを保存できた場合に、処理の成功を戻り値に指定した関数をブローカー１３４に返す。また、ミドルウェア部１３３は、データ保存部１３３３がメッセージの保存に失敗するなどのように所定の処理に失敗した場合に、処理の不成功を戻り値に指定した関数をブローカー１３４に返す。
【００７０】
デバイス状態管理部１３３２は、ブローカー１３４からデバイス状態情報及び購読情報を取得する。具体的には、デバイス状態管理部１３３２は、セッション管理部１３４２に相当する関数を呼び出し、それにより、デバイス状態情報及び購読情報を取得する。デバイス状態管理部１３３２は、デバイス状態情報に基づいて各デバイス１５が通信できる状態にあるか否かを判断する。
【００７１】
デバイス制御部１３３１は、デバイス１５を制御するものである。デバイス制御部１３３１は、非Ｐｕｂ／ＳｕｂＡＰＩ（Application Programming Interface）を利用して、アプリケーション１６から制御信号を取得する。制御信号は、制御対象のデバイス１５を示す制御対象情報と、デバイス１５を制御するための制御指令と、を含む。デバイス制御部１３３１が制御信号を受信すると、デバイス状態管理部１３３２がデバイス状態情報に基づいて制御対象のデバイス１５が通信できる状態にあるか否かを判断する。制御対象のデバイス１５が通信できる状態にない場合、デバイス制御部１３３１は、制御対象のデバイス１５が通信できる状態になるまで待機する。制御対象のデバイス１５が通信できる状態にある場合、デバイス制御部１３３１は、ブローカー１３４に対して、制御指令を含むメッセージを出版する。具体的には、デバイス制御部１３３１は、制御対象のデバイス１５に対応するトピック情報及び制御指令を指定して関数publish()を呼び出す。これにより、トピック情報と制御指令とを含むメッセージが制御対象のデバイス１５へ送信される。
【００７２】
Ｐｕｂ／Ｓｕｂシステムとして、例えば、ＭＱＴＴ（Message Queuing Telemetry Transport）を使用することができる。ＭＱＴＴを使用する場合、ブローカー１３４とデバイス１５との間のインタフェースはＭＱＴＴに則る。ブローカー１３４とミドルウェア部１３３との間はＭＱＴＴに依らず、関数呼び出しによるインタフェースをとる。
【００７３】
［動作］
上述した構成を有する通信装置１１の動作例について説明する。
【００７４】
図３は、ミドルウェア部１３３が出版を行う場合における通信装置１１の処理手順の一例を示している。
【００７５】
図３に示すように、ミドルウェア部１３３が関数呼び出しによりブローカー１３４に対してメッセージの出版を行い（ステップＳ３０１）、ブローカー１３４がそのメッセージをデバイス１５に送信する（ステップＳ３０２）。具体的には、ミドルウェア部１３３は、トピック情報を引数topicに指定し、データを引数payloadに指定し、関数publish()を呼び出す。これにより、トピック情報とデータとを含むメッセージがデバイス１５に送信される。必要に応じて、ブローカー１３４はメッセージをデバイス１５に再送信する（ステップＳ３０３）。
【００７６】
ブローカー１３４は、次のようにして、メッセージがデバイス１５に到達したか否かを戻り値に指定した関数を返す。これにより、ミドルウェア部１３３がメッセージがデバイス１５に到達したか否かを確認することが可能になる。
【００７７】
デバイス１５がメッセージを受信できないことがある。この場合、デバイス１５は肯定応答情報をブローカー１３４に送信することはない。ブローカー１３４は、メッセージの送信後に所定の時間が経過するまでにデバイス１５から肯定応答情報を受信できなかった場合に、デバイス１５がメッセージを受信できなかったと判断する。ブローカー１３４は、メッセージがデバイス１５に到達しなかったこと（timeout）を戻り値に指定した関数をミドルウェア部１３３に返す（ステップＳ３０４）。
【００７８】
一方、デバイス１５は、ブローカー１３４からメッセージを受信し、受信したメッセージをメモリに保存した場合には、肯定応答情報をブローカー１３４に送信する（ステップＳ３０５）。ブローカー１３４は、デバイス１５から肯定応答情報を受信すると、メッセージがデバイス１５に到達したこと（success）を戻り値に指定した関数をミドルウェア部１３３に返す（ステップＳ３０６）。
【００７９】
このようにして、ミドルウェア部１３３が出版を行う場合において、ミドルウェア部１３３とデバイス１５との間の到達確認が行われる。
【００８０】
図３に示すシーケンスは、ブローカー１３４からデバイス１５へのメッセージングがＭＱＴＴのＱｏＳ１（Quality of Service 1）である場合、具体的には、１回はメッセージがデバイス１５に到達することが保証されるプロトコルを使用する場合に対応する。
【００８１】
図４は、ミドルウェア部１３３が購読を行う場合における通信装置１１の処理手順の一例を示している。
【００８２】
図４に示すように、ミドルウェア部１３３がコールバック関数の設定によりブローカー１３４に対して購読を行う（ステップＳ４０１）。具体的には、ミドルウェア部１３３は、コールバック関数として関数subscribe_callback()を設定する。
【００８３】
その後に、デバイス１５がメッセージを出版する（ステップＳ４０２）。具体的には、デバイス１５は、トピック情報とセンサデータとを含むメッセージをブローカー１３４に送信する。必要に応じて、デバイス１５は出版を再度行う（ステップＳ４０３）。
【００８４】
ブローカー１３４は、デバイス１５からメッセージを受信すると、設定されたコールバック関数を呼び出すことにより、受信したメッセージをミドルウェア部１３３に渡す（ステップＳ４０４）。具体的には、ブローカー１３４は、受信したメッセージに含まれるトピック情報及びセンサデータを引数topic及びpayloadに指定して、設定されたコールバック関数を呼び出す。
【００８５】
ミドルウェア部１３３は、ブローカー１３４から受け取ったメッセージをメモリ１３に保存する処理を含む所定の処理を行う（ステップＳ４０５）。所定の処理は、メッセージの統計を計算する処理をさらに含んでよい。
【００８６】
続いて、ミドルウェア部１３３は、所定の処理が成功したか否かを戻り値に指定して関数を返す（ステップＳ４０６）。具体的には、ミドルウェア部１３３は、所定の処理が完了した場合には、処理の成功を戻り値に指定した関数をブローカー１３４に返し、そうでなければ、処理の不成功を戻り値に指定した関数をブローカー１３４に返す。
【００８７】
ブローカー１３４は、ミドルウェア部１３３により返された関数に応じた情報をデバイス１５に送信する（ステップＳ４０７）。具体的には、ブローカー１３４は、処理の成功が戻り値に指定されていた場合には、肯定応答情報をデバイス１５に送信し、処理の不成功が戻り値に指定されていた場合には、否定応答（negative acknowledgement）情報をデバイス１５に送信する。これにより、デバイス１５がメッセージがミドルウェア部１３３に到達したか否かを確認することが可能になる。なお、ブローカー１３４は否定応答情報を送信しなくてもよい。この場合、デバイス１５はブローカー１３４から肯定応答情報を受信できなかったときにメッセージがミドルウェア部１３３に到達しなかったと判断する。
【００８８】
このようにして、ミドルウェア部１３３が出版を行う場合において、ミドルウェア部１３３とデバイス１５との間の到達確認が行われる。
【００８９】
図４に示すシーケンスは、ブローカー１３４からデバイス１５へのメッセージングがＭＱＴＴのＱｏＳ１である場合に対応する。
【００９０】
なお、ミドルウェア部１３３とデバイス１５との間の到達保証が要求されないこともある。
【００９１】
［効果］
本実施形態に係る通信装置１１では、ブローカー１３４がライブラリとしてミドルウェア部１３３に組み込まれ、ミドルウェア部１３３とブローカー１３４との間の通信が関数コールにより行われる。このため、ミドルウェア部１３３とブローカー１３４との間の通信はネットワークを介さずに行われる。これにより、上述した関連技術で生じるような輻輳を低減することができる。さらに、ミドルウェア部１３３とブローカー１３４との間の通信はネットワークを介した通信よりも高速及び広帯域となり、より多数のデータの送受信が可能になる。その結果、ＩｏＴシステムの信頼性が向上する。
【００９２】
ミドルウェア部１３３は、ブローカー１３４に対してコールバック関数を設定することで購読を行う。ブローカー１３４は、デバイス１５により出版されたメッセージを受信した際にそのコールバック関数を呼び出すことによりそのメッセージをミドルウェア部１３３に渡す。ミドルウェア部１３３は、コールバック関数の戻り値に受信処理の結果（成功又は不成功）を指定し、ブローカー１３４は、戻り値に応じた応答をデバイス１５に送信する。これにより、デバイス１５が、メッセージがミドルウェア部１３３に到達したか否かを確認することが可能になる。
【００９３】
ミドルウェア部１３３は、出版に対応する関数コールを行い、その戻り値を待つ。ブローカー１３４は、デバイス１５からの応答の有無に応じて戻り値を設定する。これにより、ミドルウェア部１３３が、メッセージがデバイス１５に到達したか否かを確認することが可能になる。
【００９４】
デバイス状態情報を取得する関数がブローカーライブラリ１３２に用意される。これにより、ミドルウェア部１３３がデバイス状態情報をリアルタイムに取得することが可能になり、すなわち、現在のデバイス５５の状態を確認することが可能になる。
【００９５】
上述した実施形態では、ＩｏＴミドルウェア１３１及びブローカーライブラリ１３２などのプログラムは汎用プロセッサであるＣＰＵにより実行される。代替として、プログラムは専用のプロセッサにより実行されてもよい。
【００９６】
ＩｏＴミドルウェア１３１及びブローカーライブラリ１３２などのプログラムは、コンピュータで読み取り可能な記憶媒体に記憶された状態で通信装置１１に提供されてよい。この場合、例えば、通信装置１１は、記憶媒体からデータを読み出すドライブを備え、記憶媒体からプログラムを取得する。記憶媒体の例は、磁気ディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒなど）、光磁気ディスク（ＭＯなど）、半導体メモリを含む。また、プログラムを通信ネットワーク上のサーバに格納し、通信装置１１がサーバからプログラムをダウンロードするようにしてもよい。
【００９７】
本発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、各実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００９８】
１０…通信システム
１１…通信装置
１２…ＣＰＵ
１３…メモリ
１４…通信インタフェース
１５…デバイス
１６…アプリケーション
１３１…ＩｏＴミドルウェア
１３２…ブローカーライブラリ
１３３…ミドルウェア部
１３４…ブローカー
１３３１…デバイス制御部
１３３２…デバイス状態管理部
１３３３…データ保存部
１３４１…メッセージ配送部
１３４２…セッション管理部
１３４３…応答部
５０…通信システム
５１…ミドルウェア部
５２…ブローカー
５５…デバイス
５６…アプリケーション
５１１…デバイス制御部
５１２…デバイス状態管理部
５１３…データ保存部
５２１…メッセージ配送部
５２２…セッション管理部
５２３…応答部
【図１】
2020158154.tif 000003
【図２】
2020158154.tif 000004
【図３】
2020158154.tif 000005
【図４】
2020158154.tif 000006
【図５】
2020158154.tif 000007
【図６】
2020158154.tif 000008
【手続補正書】
【提出日】令和2年5月21日(2020.5.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ブローカーを介してパブリッシャーとサブスクライバーとの間でメッセージ交換を行う出版購読システムにおいて、前記パブリッシャーにより出版されたメッセージを管理するミドルウェア部と、前記ブローカーを提供する関数を含むライブラリを記憶する記憶部と、を備える通信装置において実行されるメッセージ送受信方法であって、
前記ミドルウェア部が、コールバック関数の設定により前記ブローカーに対して購読を行う過程と、
前記ブローカーが、第１のデバイスにより出版された第１のメッセージを受信したときに、前記コールバック関数を呼び出すことにより、前記第１のメッセージを前記ミドルウェア部に渡す過程と、
前記ミドルウェア部が、前記ブローカーから前記第１のメッセージを受け取ったことに応答して、前記第１のメッセージを第２のデバイスに送信する過程と、
を備えるメッセージ送受信方法。
【請求項２】
前記ミドルウェア部が、前記コールバック関数が呼び出されたときに、前記第１のメッセージの保存を含む所定の処理が成功したか否かを戻り値に指定して関数を返す過程と、
前記ブローカーが、前記ミドルウェア部により返された前記関数に応じて、前記第１のメッセージが前記ミドルウェア部に到達したか否かを示す情報を前記第１のデバイスに送信する過程と、
をさらに備える請求項１に記載のメッセージ送受信方法。
【請求項３】
前記ミドルウェア部が、第３のデバイスから、前記第１のデバイスを制御するための制御情報を受信する過程と、
前記ミドルウェア部が、関数呼び出しにより前記ブローカーに対して、前記制御情報を含む第２のメッセージの出版を行う過程と、
をさらに備える請求項１又は２に記載のメッセージ送受信方法。
【請求項４】
前記ブローカーが、前記第２のメッセージが前記第１のデバイスに到達したか否かを戻り値に指定した関数を返す過程
をさらに備える請求項３に記載のメッセージ送受信方法。
【請求項５】
前記ミドルウェア部が、関数呼び出しにより前記ブローカーから前記第１のデバイスの状態を示すデバイス状態情報を取得する過程
をさらに備える請求項１乃至４のいずれか１項に記載のメッセージ送受信方法。
【請求項６】
前記デバイス状態情報は、前記第１のデバイスとの接続状態を示すセッション情報と前記第１のデバイスの死活状態を示す死活情報との少なくとも一方を含む、請求項５に記載のメッセージ送受信方法。
【請求項７】
請求項１乃至６のいずれか１項に記載のメッセージ送受信方法をコンピュータに実行させるプログラム。
【請求項８】
ブローカーを介してパブリッシャーとサブスクライバーとの間でメッセージ交換を行う出版購読システムにおいて、前記パブリッシャーにより出版されたメッセージを管理するミドルウェア部と、
前記ブローカーを提供する関数を含むライブラリを記憶する記憶部と、
を備え、
前記ミドルウェア部が、コールバック関数の設定により前記ブローカーに対して購読を行い、
前記ブローカーが、第１のデバイスにより出版された第１のメッセージを受信したときに、前記コールバック関数を呼び出すことにより前記第１のメッセージを前記ミドルウェア部に渡し、
前記ミドルウェア部が、前記ブローカーから前記第１のメッセージを受け取ったことに応答して、前記第１のメッセージを第２のデバイスに送信する、通信装置。
【国際調査報告】
2020158154.tif 000009
2020158154.tif 000010
2020158154.tif 000011
2020158154.tif 000012