JP2021150745A - 機器制御システム及び機器制御方法 - Google Patents

Abstract

【課題】正当な権限を有しない制御サーバによって制御対象機器が制御される事態を防止する。【解決手段】ＭＱＴＴプロトコルに従って通信を行うＩｏＴ機器３を制御可能な機器制御システム１であって、ＩｏＴ機器３を制御する第１制御サーバ５（第２制御サーバ６）と、ＩｏＴ機器３から第１制御サーバ５に送信されるメッセージの許否を判定する認可サーバ７と、を備える。認可サーバ７は、ＩｏＴ機器３からの制御サーバ宛メッセージ送信認可要求に対して許可情報を生成して返送する。ＩｏＴ機器３は、認可サーバ７から許可情報を受け付けた場合に、許可情報を含むメッセージを第１制御サーバ５へ送信する。第１制御サーバ５は、ＩｏＴ機器３からメッセージを受け付けた場合に認証サーバ７に対しメッセージに含まれる許可情報の有効性を検証し、その検証結果に応じてＩｏＴ機器３から送信されたメッセージの許否を判定する。【選択図】図１

Description

本発明は、機器制御システム及び機器制御方法に関する。

近年、ＩｏＴ（Internet of Things）と呼ばれる、様々な機器をインターネットに接続し、情報交換することにより相互に制御する仕組みが普及している。このようなＩｏＴの仕組みを利用し、工場内に設置された複数のＰＬＣ（Programmable Logic Controller）が検出するデータを含む、多種多様なデータをネットワーク経由で収集するシステムが提案されている（例えば、特許文献１参照）。

一般に、ＩｏＴにおける通信においては、ＴＣＰ／ＩＰスタックをベースに作成されたＭＱＴＴ（Message Queue Telemetry Transport）プロトコルが標準的な通信プロトコルとして利用されている。このＭＱＴＴプロトコルでは、ネットワーク内におけるエンティティのタイプとして、メッセージ・ブローカ（ブローカ）及びクライアントの２つが定義され、これらの間でメッセージが送受信される。

ＭＱＴＴプロトコルでは、ブローカ上に作成されるトピックを介してメッセージの送受信が行われる。ブローカは、あるトピック宛のメッセージをクライアントから受信すると、そのトピックからの受信を予め要求していた別のクライアントにそのメッセージを配信する。また、ＭＱＴＴプロトコルに従った通信を行う際、ブローカがクライアントに対してユーザ名及びパスワードを利用した認証を行うことで、ネットワーク上の安全性を確保している。このようなＭＱＴＴの仕組みを利用することにより、複数の機器からリアルタイムでデータを収集する一方、特定の機器に対して遠隔地から操作することができる。

特開２０１７−２２００５３号公報

ところで、ＩｏＴの普及に伴い、制御対象機器とその制御サーバがＭＱＴＴクライアントとしてブローカを介して通信するシステム構成が出てきている。このような構成では、制御対象機器が、単一のブローカを介して制御サーバ（制御アプリケーション）に対してメッセージを送信することが考えられる。制御対象機器がエアコンであり、単一のブローカを介してこのエアコンを制御する制御サーバが存在する場合を想定する。例えば、制御対象機器のセンサから収集されたエアコンの周辺温度のメッセージ（検出値）が制御サーバへ送信される。

このような環境下においても、既存のＭＱＴＴプロトコルに従えば、ＭＱＴＴクライアントである制御サーバおよび制御対象機器に対する認証は、それらとブローカとの間のみで行われる。このため、実際の通信段階において、制御対象機器と制御サーバは、相手がブローカとの間でどのように認証されたかを知らないまま、ブローカ上のトピックを介して通信を行うことになる。したがって、例えば、悪意の第三者によってブローカが不正アクセスされてしまうと、制御サーバに対し不正なメッセージを送信することが可能となる。不正なメッセージを受け付けた制御サーバは、不正なメッセージに基づき制御されることにより、制御対象となる制御対象機器の種別によっては重大な損害が発生する事態も想定される。

本発明は、このような実情に鑑みてなされたものであり、メッセージの送信元の制御対象機器が認可されているものであるかを判定することができる機器制御システム及び機器制御方法を提供することを目的の１つとする。

本実施形態の機器制御システムは、その一態様では、ＭＱＴＴプロトコルに従って通信を行う制御対象機器を制御可能な機器制御システムであって、前記制御対象機器を制御する制御サーバと、前記制御対象機器から前記制御サーバに送信されるメッセージの許否を判定する認可サーバと、を具備し、前記認可サーバは、前記制御対象機器からの制御サーバ宛メッセージ送信許可要求に対して許可情報を生成して返送し、前記制御対象機器は、前記認可サーバから前記許可情報を受け付けた場合に、前記許可情報を含む前記メッセージを前記制御サーバへ送信し、前記制御サーバは、前記制御対象機器から前記メッセージを受け付けた場合に前記認可サーバに対し前記メッセージに含まれる前記許可情報の有効性を検証し、その検証結果に応じて前記制御対象機器から送信された前記メッセージの許否を判定することを特徴とする。

本実施形態の機器制御方法は、その一態様では、ＭＱＴＴプロトコルに従って通信を行う制御対象機器を制御する制御サーバと、前記制御対象機器から前記制御サーバに送信されるメッセージの許否を判定する認可サーバと、を用いた機器制御方法であって、前記認可サーバにて、前記制御対象機器からの制御サーバ宛メッセージ送信認可要求に対して許可情報を生成して返送するステップと、前記制御対象機器にて、前記認可サーバから前記許可情報を受け付けた場合に、前記許可情報を含む前記メッセージを前記制御サーバへ送信するステップと、前記制御サーバにて、前記制御対象機器から前記メッセージを受け付けた場合に前記認可サーバに対し前記メッセージに含まれる前記許可情報の有効性を検証し、その検証結果に応じて前記制御対象機器から送信された前記メッセージの許否を判定するステップと、を有することを特徴とする。

本発明によれば、メッセージの送信元の制御対象機器が認可されているものであるかを判定することができる。

本実施の形態に係る機器制御システムのネットワーク構成の説明図である。 本実施の形態に係る機器制御システムの制御対象となるＩｏＴ機器の機能ブロック図である。 本実施の形態に係る機器制御システムが有する認可サーバの機能ブロック図である。 本実施の形態に係る機器制御システムが有するブローカの機能ブロック図である。 本実施の形態に係る機器制御システムが有する第１制御サーバの機能ブロック図である。 本実施の形態に係る機器制御システムにおいて、ＩｏＴ機器から制御サーバへメッセージを送信する際の動作を説明するためのシーケンス図である。 認可サーバで行われる認証に利用される認証情報テーブルの一例を示す図である。 認可サーバで許可情報（トークン）の管理に利用される許可情報テーブルの一例を示す図である。

ＩｏＴの普及に伴い、複数の制御サーバ（制御アプリケーション）が、単一のブローカを介して同一の制御対象機器に対して異なる制御を実行することが想定される。制御サーバは、クラウドアプリケーションやサービス提供アプリケーションと呼ぶこともできる。このような環境下においても、現状では、制御サーバ及び制御対象機器に対する認証が、それらとブローカとの間のみで行われる。このため、制御対象機器と制御サーバは、相手がブローカとの間でどのように認証されたかを知らないまま、ブローカ上のトピックを介して通信を行うことになる。したがって、例えば、悪意の第三者によってブローカが不正アクセスされてしまうと、制御サーバに対し不正なメッセージを送信することが可能となる。不正なメッセージを受け付けた制御サーバは、不正なメッセージに基づき制御されることにより、制御対象となる制御対象機器の種別によっては重大な損害が発生する事態も想定される。

本発明者は、ＭＱＴＴプロトコルに規定された、ブローカによるユーザ名及びパスワードを利用したクライアント認証では、上述したような認可されていない制御対象機器からのメッセージを判定することができない点に着目した。そして、ＭＱＴＴプロトコルにおける認証処理とは別に、送信を要求した制御対象機器かの正当性を検証する仕組みを採用することが、不正なメッセージによって制御サーバが実行され、制御対象機器が制御される事態の防止に寄与することを見出し、本発明に想到した。

すなわち、本発明に係る機器制御システムの骨子は、ＭＱＴＴプロトコルに従って通信を行う制御対象機器を制御可能な機器制御システムにおいて、制御対象機器を制御する制御サーバと、制御対象機器から制御サーバに送信されるメッセージの許否を判定する認可サーバと、を備え、認可サーバにて、制御対象機器からの制御サーバ宛メッセージ送信認可要求に対して許可情報を生成して返送し、制御対象機器にて、認可サーバから許可情報を受け付けた場合に、許可情報を含むメッセージを制御サーバへ送信し、制御サーバにて、制御対象機器からメッセージを受け付けた場合に認可サーバに対しメッセージに含まれる許可情報の有効性を検証し、その検証結果に応じて制御対象機器から送信されたメッセージの許否を判定することである。

本発明に係る機器制御システムによれば、認可サーバは、制御対象機器からの制御サーバ宛メッセージ送信認可要求に対して許可情報を生成して返送し、制御対象機器によって、メッセージを制御サーバへ送信する場合には、認可サーバで生成された許可情報を含むメッセージを送信する一方、制御対象機器からメッセージを受け付けた制御サーバは、認可サーバで許可情報の有効性が検証されることから、許可情報が含まれていない制御対象機器からのメッセージを受け入れることを回避することができる。

以下、本発明に係る機器制御システムの実施形態について、図面を参照して説明する。図１は、本実施の形態に係る機器制御システムのネットワーク構成の説明図である。図１に示すように、本実施の形態に係る機器制御システム１は、インターネット２を介して制御対象機器としてのＩｏＴ機器３（３ａ、３ｂ、３ｃ…３ｎ）が接続されている。以下においては、これらのＩｏＴ機器３ａ、３ｂ、３ｃ…３ｎを総称する際、ＩｏＴ機器３と呼ぶものとする。

ＩｏＴ機器３は、インターネット２を介して通信を行う機能を有する任意の機器で構成される。例えば、ＩｏＴ機器３は、任意の場所に設置されるエアコンやセンサ等で構成されるが、これに限定されない。また、ＩｏＴ機器３は、これらのエアコンやセンサ等を制御するＰＬＣ（Programmable Logic Controller）などの制御装置で構成されてもよい。例えば、ＩｏＴ機器３は、工場内の特定の区画の温度を検出する温度センサや、工場内の設備から排出される排水の流量を検出する流量センサで構成される。これらの温度センサや流量センサは、機器制御システム１からの要求に応じた制御を実行することができ、例えば、検出値などのメッセージを機器制御システム１に出力する。詳細について後述するように、ＩｏＴ機器３は、認可サーバ７から許可情報（トークン）を受け付けた場合に、許可情報を含むメッセージを第１制御サーバ５（第２制御サーバ６）へ送信する。

機器制御システム１は、例えば、クラウドサービスを提供するクラウドサービス事業者のネットワーク内に配設される。例えば、機器制御システム１は、ＭＱＴＴ（Message Queue Telemetry Transport）ブローカ（以下、単に「ブローカ」という）４、第１制御サーバ５、第２制御サーバ６及び認可サーバ（判定サーバ）７を含んで構成される。しかしながら、機器制御システム１の構成については、これに限定されるものではなく適宜変更が可能である。制御サーバの数は、２つに限定されず、１つ又は３つ以上含まれていてもよい。機器制御システム１は、クラウドサービス事業者のネットワーク以外のネットワークに配設されてもよい。

ブローカ４は、ＭＱＴＴプロトコルに従って、ＩｏＴ機器３から出力されたメッセージ（例えば、検出値）を機器制御システム１の特定の構成要素（第１制御サーバ５等）に配信する一方、機器制御システム１の構成要素からのメッセージ（例えば、指示信号）を特定のＩｏＴ機器３に配信する。また、ブローカ４は、ＭＱＴＴプロトコルに従って通信を行う際、通信対象となるＩｏＴ機器３との間において、ユーザ名及びパスワードを利用した認証を行う機能を有している。なお、ブローカ４は、ＭＱＴＴサーバと呼ばれることもある。

第１、第２制御サーバ５、６は、ＩｏＴ機器３を制御可能な制御サーバである。例えば、第１制御サーバ５（第２制御サーバ６）は、制御の一態様として、ＩｏＴ機器３が検出した検出値を収集するデータ収集制御を実行する。第２制御サーバ６（第１制御サーバ５）は、制御の一態様として、所定のＩｏＴ機器３を遠隔操作する遠隔操作制御を実行する。第１、第２制御サーバ５、６は、ＩｏＴ機器３に対して同一の制御を実行してもよいし、異なる制御を実行してもよい。詳細について後述するように、第１制御サーバ５（第２制御サーバ６）は、ＩｏＴ機器３からメッセージを受け付けた場合に認可サーバ７に対しメッセージに含まれる許可情報の有効性を検証し、その検証結果に応じて制御対象機器から送信されたメッセージの許否を判定する。

認可サーバ７は、ＩｏＴ機器３からの第１制御サーバ５（第２制御サーバ６）宛メッセージ送信認可要求に対して許可情報を生成する。そして生成した許可情報をＩｏＴ機器３へ返送する。そして、第１制御サーバ５（第２制御サーバ６）は、ＩｏＴ機器３からメッセージを受け付けた場合に認可サーバ７に対しメッセージに含まれる許可情報の有効性を検証し、その検証結果に応じてＩｏＴ機器３から送信されたメッセージの許否を判定する。より具体的にいうと、認可サーバ７は、ＩｏＴ機器３から第１制御サーバ５（第２制御サーバ６）に対するメッセージが正当な権限を有するＩｏＴ機器３であることを認可（証明）する許可情報を生成してＩｏＴ機器３へ返送する。そして、ＩｏＴ機器３からメッセージを受け付けた第１制御サーバ５（第２制御サーバ６）は、メッセージに含まれる許可情報の有効性を検証し、その検証結果に応じてＩｏＴ機器３から送信されたメッセージが、正当な権限を有するＩｏＴ機器３からのメッセージであるか否かを検証することで、ＩｏＴ機器３からのメッセージを受け入れるか否かを判定する。

以下、機器制御システム１の構成要素及びＩｏＴ機器３の機能について、図２〜図５を参照して説明する。なお、第１制御サーバ５及び第２制御サーバ６は、同一の機能を有するため、第１制御サーバ５について代表して説明し、第２制御サーバ６の説明を省略する。

図２は、本実施の形態に係る機器制御システム１の制御対象となるＩｏＴ機器３の機能ブロック図である。図２に示すように、ＩｏＴ機器３は、記憶部３１、処理部３２及び通信部３３を含んで構成されるが、これに限定されない。ＩｏＴ機器３の使用者又は管理者がＩｏＴ機器３を操作するために必要な操作部を備えるようにしてもよい。例えば、ＩｏＴ機器３は、所定機能を有する各種機器にＩｏＴ機器プログラム（以下、適宜「機器プログラム」という）をインストールすることで実現される機器で構成されるが、これに限定されない。

記憶部３１は、ＩｏＴ機器プログラム記憶部（以下、「機器プログラム記憶部」という）３１１及び認可情報記憶部３１２を有する。機器プログラム記憶部３１１は、ＩｏＴ機器３が各種処理を実行するためのプログラムを記憶する。各種処理には、操作実行処理などが含まれていてもよい。認可情報記憶部３１２は、後述の認可サーバ７が生成して返送された許可情報（トークン）及び許可情報の有効期限、認証情報などを記憶する。許可情報には、メッセージの送信先である第１制御サーバ５（第２制御サーバ６）を一意に識別するためのサービスＩＤや、ＩｏＴ機器３を一意に識別するための端末ＩＤを有する。

処理部３２は、認可要求処理部３２１及びメッセージ送信処理部３２２を有する。認可要求処理部３２１は、第１制御サーバ５（第２制御サーバ６）に対するメッセージ送信に対する許可情報（トークン）の生成を認可サーバ７に対し要求する処理（以下、「認可情報要求処理」という）を行う。認可情報要求処理は、ＩｏＴ機器３が第１制御サーバ５（第２制御サーバ６）に対してメッセージを送る際に実行される。なお、すでにＩｏＴ機器３が有効な許可情報を有している場合には、認可要求処理部３２１は、認可サーバ７に対し認可情報要求処理を実行しない。

メッセージ送信処理部３２２は、認可サーバ７から許可情報（トークン）を受け付けた場合に、許可情報（トークン）を含むメッセージを第１制御サーバ５（第２制御サーバ６）へ送信する処理（以下、「メッセージ送信処理」という）を行う。メッセージ送信処理は、ＩｏＴ機器３からメッセージ（例えば、ＩｏＴ機器３のセンサから収集された検出値）を第１制御サーバ５（第２制御サーバ６）へ送信する際に実行される。

通信部３３は、ブローカ通信部３３１及び認可サーバ通信部３３２を有する。ブローカ通信部３３１は、ブローカ４との間の通信を行う。認可サーバ通信部３３２は、認可サーバ７との間の通信を行う。通信部３３とブローカ４及び／又は認可サーバ７と通信を行うことができる。通信部３３とブローカ４及び／又は認可サーバ７との間の通信は、有線により行われることが望ましいが、無線により行うようにしてもよい。

図３は、本実施の形態に係る機器制御システム１が有する認可サーバ７の機能ブロック図である。図３に示すように、認可サーバ７は、記憶部７１、処理部７２及び通信部７３を含んで構成されるが、これに限定されない。認可サーバ７の使用者又は管理者が認可サーバ７を操作するために必要な操作部を備えるようにしてもよい。例えば、認可サーバ７は、汎用的なコンピュータシステムに認可サーバプログラムをインストールすることで実現されるサーバ装置で構成されるが、これに限定されない。

記憶部７１は、認可サーバプログラム記憶部７１１、認証情報記憶部７１２及び認可情報記憶部７１３を有する。認可サーバプログラム記憶部７１１は、認可サーバ７が各種処理を実行するためのプログラムを記憶する。各種処理には、認可要求判定処理などが含まれる。認証情報記憶部７１２は、認証対象のＩｏＴ機器３を識別する端末ＩＤ、複数の制御サーバのうちサービスの提供先の制御サーバを一意に識別するためのサービスＩＤを記憶する。認可情報記憶部７１３は、認可要求処理部３２１が、認可サーバ７に対し認可情報要求処理を実行し、後述する認可情報生成部７２１により生成された許可情報（トークン）を記憶する。例えば、許可情報（トークン）には、ＩｏＴ機器３を一意に識別するための端末ＩＤ、資格情報、許可情報の有効期限などが含まれる。

処理部７２は、認可情報生成部７２１及び認可情報検証部７２２を有する。認可情報生成部７２１は、ＩｏＴ機器３からの第１制御サーバ５（第２制御サーバ６）宛の制御サーバ宛メッセージ送信認可要求に対する許可情報を生成する処理（以下、「認可情報生成処理」という）を行う。具体的には、認可情報生成部７２１は、認可情報生成処理において、ＩｏＴ機器３からの許可情報（トークン）要求に含まれる端末ＩＤとクライアント証明書を照合する。そして、許可情報（トークン）要求に含まれる端末ＩＤとサービスＩＤの組み合わせが認証情報記憶部７１２に記憶されていることをチェックする。チェックの結果、端末ＩＤとサービスＩＤの組み合わせが認証情報記憶部７１２に記憶されている場合には、認可サーバ７は、許可情報（トークン）要求を行ったＩｏＴ機器３を識別する端末ＩＤと、制御サーバ（サービス）を一意に識別するためのサービスＩＤと、を含む許可情報（トークン）を生成する。認可情報生成部７２１は、許可情報（トークン）に署名情報を埋め込む。したがって、許可情報（トークン）が改変された場合には、不正な許可情報（トークン）であることを検知することができる。なお、適切に認可情報生成処理が行われると、認可情報生成部７２１は、生成した許可情報（トークン）をＩｏＴ機器３へ返送する。本実施の形態では、許可情報として認可サーバ７の公開鍵が出力されるが、これに限定されない。認可情報検証部７２２は生成した許可情報（トークン）と有効期限の情報を認可情報記憶部７１３に記憶する。

認可情報検証部７２２は、第１制御サーバ５（第２制御サーバ６）がＩｏＴ機器３からメッセージを受け付けた場合にメッセージに含まれる許可情報（トークン）の有効性を検証要求に応じて許可情報（トークン）の有効性の検証を行う処理（以下、「認可情報検証処理」という）を行う。認可情報検証処理は、第１制御サーバ５（第２制御サーバ６）から認可情報検証要求を受け付けた際に実行される。適切に認可情報検証処理が行われると、認可情報検証部７２２は、検証結果を第１制御サーバ５（第２制御サーバ６）へ出力する。本実施の形態では、認可サーバ７の秘密鍵によるメッセージへの署名が許可情報（トークン）として出力されるが、これに限定されない。

通信部７３は、機器通信部７３１及び制御サーバ通信部７３２を有する。機器通信部７３１は、ＩｏＴ機器３との間の通信を行う。機器通信部７３１は、ＩｏＴ機器３との間でメッセージや許可情報（トークン）を送受する際に通信を行う。制御サーバ通信部７３２は、制御サーバ（例えば、第１制御サーバ５）との間の通信を行う。通信部７３とブローカ４及び／又は制御サーバとの間の通信は、有線により行われることが望ましいが、無線により行うようにしてもよい。

図４は、本実施の形態に係る機器制御システム１が有するブローカ４の機能ブロック図である。図４に示すように、ブローカ４は、記憶部４１、処理部４２及び通信部４３を含んで構成されるが、これに限定されない。ブローカ４の使用者又は管理者がブローカ４を操作するために必要な操作部を備えるようにしてもよい。例えば、ブローカ４は、汎用的なコンピュータシステムにブローカプログラムをインストールすることで実現されるサーバ装置で構成されるが、これに限定されない。ブローカ４は、サーバ装置の一部の機能により実現されてもよい。

記憶部４１は、ブローカプログラム記憶部４１１及びトピック記憶部４１２を有する。ブローカプログラム記憶部４１１は、ブローカ４が各種処理を実行するためのプログラムを記憶する。各種処理には、後述するトピック識別処理やメッセージ配信処理などが含まれる。トピック記憶部４１２は、制御サーバ又はＩｏＴ機器３から送信されたメッセージの送り先を特定するためのトピックを記憶する。トピックは、機器制御システム１のネットワーク管理者、或いは、ＩｏＴ機器３からの登録要求に応じてトピック記憶部４１２に記憶される。

処理部４２は、トピック識別処理部４２１及びメッセージ配信処理部４２２を有する。トピック識別処理部４２１は、制御サーバ又はＩｏＴ機器３から送信されたメッセージに含まれるトピックを識別する処理（以下、「トピック識別処理」という）を行う。メッセージ配信処理部４２２は、トピック識別処理部４２１が識別したトピックに従ってメッセージを配信する処理（以下、「メッセージ配信処理」という）を行う。

通信部４３は、制御サーバ通信部４３１、ＩｏＴ機器通信部（以下、「機器通信部」という）４３２を有する。制御サーバ通信部４３１は、制御サーバ（例えば、第１制御サーバ５）との間の通信を行う。機器通信部４３２は、ＩｏＴ機器３との間の通信を行う。通信部４３と制御サーバ、認可サーバ７及び／又はＩｏＴ機器３との間の通信は、有線により行われることが望ましいが、無線により行うようにしてもよい。

図５は、本実施の形態に係る機器制御システム１が有する第１制御サーバ５の機能ブロック図である。図５に示すように、第１制御サーバ５は、記憶部５１、処理部５２及び通信部５３を含んで構成されるが、これに限定されない。第１制御サーバ５の使用者又は管理者が第１制御サーバ５を操作するために必要な操作部を備えるようにしてもよい。例えば、第１制御サーバ５は、汎用的なコンピュータシステムに制御サーバプログラムをインストールすることで実現されるサーバ装置で構成されるが、これに限定されない。第１制御サーバ５は、クラウドアプリケーションのように、サーバ装置の一部の機能により実現されてもよい。

記憶部５１は、制御サーバプログラム記憶部５１１及び制御対象情報記憶部５１２を有する。制御サーバプログラム記憶部５１１は、第１制御サーバ５が各種処理を実行するためのプログラムを記憶する。制御対象情報記憶部５１２は、第１制御サーバ５が制御を実行する対象となる制御対象機器（ＩｏＴ機器）に関する情報（制御対象情報）を記憶する。例えば、制御対象情報には、制御対象となるＩｏＴ機器３の識別情報や操作可能な内容（操作内容）が含まれる。

処理部５２は、検証要求処理部５２１を有する。検証要求処理部５２１は、ＩｏＴ機器３からメッセージを受け付けた場合に認可サーバ７に対しメッセージに含まれる許可情報（トークン）の有効性の検証を要求する処理（以下、「検証要求処理」という）を行い、認可サーバ７で行われた認可検証処理の検証結果に応じてＩｏＴ機器３から送信されたメッセージの許否を判定する。認可検証処理は、第１制御サーバ５が特定のＩｏＴ機器３に対する制御を実行する前に実行される。

通信部５３は、ブローカ通信部５３１及び認可サーバ通信部５３２を有する。ブローカ通信部５３１は、ブローカ４との間の通信を行う。ブローカ通信部５３１は、ブローカ４を介してＩｏＴ機器３との間でメッセージを送受する際にブローカ４と通信を行う。認可サーバ通信部５３２は、認可サーバ７との間の通信を行う。通信部５３とブローカ４及び／又は認可サーバ７との間の通信は、有線により行われることが望ましいが、無線により行うようにしてもよい。

以下、本実施の形態に係る機器制御システム１において、ＩｏＴ機器３から制御サーバへメッセージを送信する際の動作について、図６を参照して説明する。図６は、本実施の形態に係る機器制御システム１において、ＩｏＴ機器３から制御サーバへメッセージを送信する際の動作を説明するためのシーケンス図である。以下では、ＩｏＴ機器３から第１制御サーバ５へメッセージを送信する際の動作について説明するものとする。機器制御システム１の管理対象となるＩｏＴ機器３は、説明の便宜上、全てエアコンであるものとする。

ＩｏＴ機器情報の登録に先立ち、ＩｏＴ機器３と認可サーバ７及び／又は第１制御サーバ５との間では、通信セキュリティが担保される。例えば、ＩｏＴ機器３と認可サーバ７及び／又は第１制御サーバ５との間には、予め暗号鍵を共有しておき、ＭＱＴＴプロトコルに従って通信される情報を暗号化することで、通信セキュリティを担保することができる。なお、ＩｏＴ機器３と認可サーバ７及び／又は第１制御サーバ５との間の通信プロトコルとして、ＭＱＴＴプロトコル以外のプロトコルを用いることで通信セキュリティを担保するようにしてもよい。

ＩｏＴ機器３から第１制御サーバ５へメッセージが送信される場合、まず、ＩｏＴ機器３の処理部３２は、認可情報記憶部３１２に有効期限内の有効な許可情報（トークン）が記憶されているか判定する。認可情報記憶部３１２に有効期限内の許可情報（トークン）が記憶されている場合には、後述のＳＴ１１〜ＳＴ１６の処理は省略される。なお、認可情報記憶部３１２に記憶されている許可情報（トークン）は、有効期限が経過すると消去されるようにしてもよい。認可情報記憶部３１２に有効期限内の許可情報（トークン）が記憶されていない場合には、処理部３２のアプリケーションは、第１制御サーバ５に対するメッセージ送信に対する許可情報（トークン）の生成を通信部３３を通じて認可サーバ７に対し要求する認可情報要求処理を行う（ＳＴ１１）。認可情報要求処理では、認可要求処理部３２１は、端末ＩＤ、サービスＩＤを含めた情報を認可サーバ７へ送信する。端末ＩＤは、ＭＱＴＴＳで通信するＩｏＴ機器３を識別するためのＩＤである。サービスＩＤは、データ送信元である第１制御サーバ５（第２制御サーバ６）（サービス）を識別するためのＩＤである。認可要求処理部３２１は、端末ＩＤ、サービスＩＤに加えてテナントＩＤを含めた情報を認可サーバ７へ送信してもよい。テナントＩＤは、ＩｏＴ機器３が設置される顧客のＩＤである。テナントＩＤは、ＩｏＴ機器３の設置時に予め設定されている。通信部３３は、認可サーバ７に対しＴＬＳ（Transport Layer Security）でクライアント証明書により認証して接続し（ＳＴ１２）、端末ＩＤ、テナントＩＤ、サービスＩＤを含めた情報を認可サーバ７へ送信して許可情報（トークン）を要求する（ＳＴ１３）。

ＩｏＴ機器３から許可情報（トークン）要求を受け取ると、認可サーバ７は、ＩｏＴ機器３から受け取った許可情報（トークン）要求の認証を行う（ＳＴ１４）。許可情報（トークン）要求の認証では、許可情報（トークン）要求に含まれる端末ＩＤとクライアント証明書を照合するとともに、端末ＩＤとサービスＩＤの組み合わせが認証情報記憶部７１２に記憶されていることをチェックする。端末ＩＤとサービスＩＤの組み合わせが認証情報記憶部７１２に記憶されている場合には、認可サーバ７は、許可情報（トークン）要求を行ったＩｏＴ機器３を識別する端末ＩＤと、制御サーバ（サービス）を一意に識別するためのサービスＩＤと、を含む許可情報（トークン）を生成する。許可情報（トークン）には、署名情報が埋め込まれる。認可サーバ７は、生成した許可情報（トークン）を発行し（ＳＴ１５）、通信部３３は認可サーバ７から発行された許可情報（トークン）を処理部３２のアプリケーションへ発行する（ＳＴ１６）。

処理部３２のアプリケーションは、認可サーバ７から許可情報（トークン）を受け付けた場合に、許可情報（トークン）を含むメッセージ（サービスデータ）を第１制御サーバ５（第２制御サーバ６）へ送信する（ＳＴ１７）。通信部３３は、ブローカ４に対しＴＬＳ（Transport Layer Security）でクライアント証明書により認証して接続し（ＳＴ１８）、許可情報（トークン）を含むメッセージ（サービスデータ）をブローカ４へ送信する（ＳＴ１９）。ブローカ４は、ＩｏＴ機器３からメッセージを受け取ると、当該メッセージに含まれるトピックを識別し、そのトピックに応じた配信先にメッセージを配信する。ここでは、トピックに、制御サーバを識別する内容が含まれる。ブローカ４は、トピックを識別することで、配信先として第１制御サーバ５（第２制御サーバ６）を特定し、メッセージ（サービスデータ）を第１制御サーバ５（第２制御サーバ６）に送信する（ＳＴ２０）。

このとき、ブローカ４では、機器通信部４３２がＩｏＴ機器３から登録要求メッセージを受信する。トピック識別処理部４２１が登録要求メッセージに含まれるトピックを識別する。トピック識別処理部４２１は、トピック記憶部４１２に記憶されたトピック情報に基づいてトピックを識別する。メッセージ配信処理部４２２は、トピック識別処理部４２１が識別したトピックに応じてメッセージの配信先を決定する。機器通信部４３２は、メッセージ配信処理部４２２が決定したメッセージの配信先である第１制御サーバ５（第２制御サーバ６）にメッセージ（サービスデータ）を送信する。

ブローカ４を介してＩｏＴ機器３からメッセージを受け付けると、第１制御サーバ５（第２制御サーバ６）は、メッセージに含まれる許可情報（トークン）の有効性を検証するために、認可サーバ７に対し許可情報（トークン）とサービスＩＤを含む検証要求を行う（Ｓ２１）。検証要求を受け付けた認可サーバ７は、許可情報（トークン）の署名を検証するとともに、認可情報記憶部７１３に記憶されている情報を参照して、許可情報（トークン）が、検証要求を行った制御サーバのサービスＩＤに対して認可されていることをチェックして検証する（ＳＴ２２）。認可サーバ７は、チェックした許可情報（トークン）の検証結果を検証要求を行った制御サーバに対し送信する（ＳＴ２３）。

第１制御サーバ５（第２制御サーバ６）は、認可サーバ７から送信された検証結果に応じてＩｏＴ機器３から送信されたメッセージの許否を判定する（ＳＴ２４）。そして、認証結果がＯＫの場合には、第１制御サーバ５（第２制御サーバ６）は、正当な端末から送信されたメッセージ（サービスデータ）であるとして受け入れる。これに対し、認証結果がＮＧの場合には、第１制御サーバ５（第２制御サーバ６）は、不正アクセスにより送信元不明の端末から送信されたメッセージ（サービスデータ）であるとして受け入れない。認証結果の中には、認可サーバ７により付加される許可情報（トークン）の有効性を検証するための検証情報が含まれる。ここでは、検証情報として、認可サーバ７の公開鍵が含まれる。

図７は、認可サーバ７で行われる認証に利用される認証情報テーブルの一例を示す図である。図７に示すように、認証情報テーブルには、端末ＩＤ、サービスＩＤの情報が予め記憶される。なお、認証情報テーブルに記憶される内容は、これに限定されるものではなく適宜変更が可能である。認証情報テーブルは、例えば、認証情報記憶部７１２に記憶される。

認証情報テーブルの番号＃１の登録内容について説明する。番号＃１には、ＩｏＴ機器３ａ（機器３ａ）についての許可情報が記憶されている。番号＃１では、機器ＩＤとして「ＩｏＴ機器３ａ」が登録され、そのサービス先として「第１制御サーバ５」が登録されている。これは、ＩｏＴ機器３ａと第１制御サーバ５との組み合わせが有効であることを示している。したがって、認可サーバ７はＩｏＴ機器３ａから第１制御サーバ５に対するメッセージに対する許可情報の生成要求を受け付けた場合には、認証情報テーブルの番号＃１に基づいて認証を行い、許可情報（トークン）を生成して、ＩｏＴ機器３ａへ返送する。

図８は、認可サーバ７で許可情報（トークン）の管理に利用される認可情報テーブルの一例を示す図である。図８に示すように、認可情報テーブルには、端末ＩＤ、サービスＩＤ、及び許可情報（トークン）の有効期限の情報が記憶される。なお、認可情報テーブルに記憶される内容は、これに限定されるものではなく適宜変更が可能である。認可情報テーブルは、例えば、認可情報記憶部７１３に記憶される。

認可情報テーブルの番号＃１の登録内容について説明する。番号＃１には、ＩｏＴ機器３ａ（機器３ａ）についての許可情報が記憶されている。番号＃１では、機器ＩＤとして「ＩｏＴ機器３ａ」が登録され、そのサービス先として「第１制御サーバ５」が登録され、その有効期限として「2020/4/1」が登録されている。これは、ＩｏＴ機器３ａから第１制御サーバ５へのメッセージの送信が２０２０年４月１日まで有効であることを示している。このような許可情報が、ＩｏＴ機器３からの要求に応じて生成されて認可サーバ７の認可情報テーブルに記憶される。

一方、第１制御サーバ５は、ＩｏＴ機器３ａからメッセージを受け付けた場合、認可サーバ７に対しメッセージに含まれる許可情報（トークン）の有効性を検証する検証要求を行う。検証要求を受け付けた認可サーバ７は、認可情報テーブルの番号＃１に基づいて許可情報（トークン）の検証を行い、有効期限が有効であることを確認したうえで検証結果を第１制御サーバ５へ送信する。第１制御サーバ５は、その検証結果に応じてＩｏＴ機器３から送信されたメッセージの許否を判定する。

このように機器制御システム１においては、ＩｏＴ機器３からの第１制御サーバ５に対するメッセージを送信する際には、ＩｏＴ機器３は、認可サーバ７に対して許可情報（トークン）の生成を要求する。要求を受け付けた認可サーバ７は、許可情報（トークン）を生成してＩｏＴ機器３へ発行する。ＩｏＴ機器３は、生成された許可情報（トークン）をメッセージにつけて、ブローカ４を通じて第１制御サーバ５へ送信する。第１制御サーバ５は、メッセージを受け付けると、メッセージについた許可情報（トークン）の許可情報の有効性を認可サーバ７に対し問合せを行う。問い合わせを受けた認可サーバ７は、許可情報（トークン）の検証を行い、問合せを行ってきた第１制御サーバ５に対し検証結果を送信する。そして、検証結果を受け付けた第１制御サーバ５は、検証結果に基づいてメッセージの許否の判定を行い、検証結果がＯＫの場合は正当な送信元からのメッセージであるとして受け付け、検証結果がＮＧの場合は不正な送信元からのメッセージであるとして拒否する。これにより、ブローカ４の改変を必要とせずに、メッセージの送信元の制御対象機器が認可されているかどうかを判定することができる。

なお、本発明は上記実施の形態に限定されず、種々変更して実施することが可能である。上記実施の形態において、添付図面に図示されている構成要素の大きさや形状、機能などについては、これに限定されず、本発明の効果を発揮する範囲内で適宜変更することが可能である。その他、本発明の目的の範囲を逸脱しない限りにおいて適宜変更して実施することが可能である。

例えば、上記実施の形態では、機器制御システム１がＭＱＴＴプロトコルに従ってＩｏＴ機器３を制御する場合について説明している。しかしながら、ＩｏＴ機器３を制御する際の通信プロトコルは、これに限定されない。例えば、ＭＱＴＴプロトコルのように、非同期で通信制御を行うと共に、ブローカ４などの単一の制御装置で制御対象機器の認証を行う任意の通信プロトコルに適用することができる。

また、上記実施の形態では、ＩｏＴ機器３がブローカ４を介して認可サーバ７と通信を行う場合について説明している。しかしながら、認可サーバ７に対するＩｏＴ機器３の通信方法については、これに限定されるものではなく適宜変更が可能である。例えば、ＩｏＴ機器３は、ブローカ４を介在させることなく直接的に認可サーバ７と通信を行うような態様であってもよい。

さらに、上記実施の形態では、認可サーバ７にて、操作要求を認可サーバ７の秘密鍵で暗号化することで許可情報を生成する場合について説明している。しかしながら、許可情報の内容についてはこれに限定されるものではなく適宜変更が可能である。例えば、メッセージ認証コードを許可情報として利用することも可能である。この場合、ＩｏＴ機器３は、検証情報として、認可サーバ７との間で共有する秘密鍵を取得する。ＩｏＴ機器３は、この認可サーバ７と共有する秘密鍵によって許可情報であるメッセージ認証コードの有効性を検証することができる。

本発明の機器制御システム及びＩｏＴ機器操作方法は、メッセージの送信元の制御対象機器が認可されているものであるかを判定することができる効果を有するものであり、あらゆるＩｏＴ機器が接続される任意のネットワークに好適である。尚、本発明の一実施例では、ＩｏＴ機器を制御対象の機器、制御サーバをＩｏＴ機器に対して制御を実行する制御サーバとしていたが、ＩｏＴ機器を計測機器とし、制御サーバを各種センサからの計測データを計測機器経由で収集する収集サーバとしても本発明は成り立つ。このとき、収集サーバは、不正なメッセージ（計測データ）を受け付けず、メッセージの送信元が許可された計測機器からの計測データのみ受け付けることが可能となる。つまり、本発明は、機器制御システムのかわりに収集システムにおいても採用できる。

１ ：機器制御システム
２ ：インターネット
３、３ａ〜３ｎ：ＩｏＴ機器
３１ ：記憶部
３１１ ：機器プログラム記憶部
３１２ ：認可情報記憶部
３２ ：処理部
３２１ ：認可要求処理部
３２２ ：メッセージ送信処理部
３３ ：通信部
３３１ ：ブローカ通信部
３３２ ：認可サーバ通信部
４ ：ＭＱＴＴブローカ（ブローカ）
４１ ：記憶部
４１１ ：ブローカプログラム記憶部
４１２ ：トピック記憶部
４２ ：処理部
４２１ ：トピック識別処理部
４２２ ：メッセージ配信処理部
４３ ：通信部
４３１ ：制御サーバ通信部
４３２ ：機器通信部
５ ：第１制御サーバ
５１ ：記憶部
５１１ ：制御サーバプログラム記憶部
５１２ ：制御対象情報記憶部
５２ ：処理部
５２１ ：検証要求処理部
５３ ：通信部
５３１ ：ブローカ通信部
５３２ ：認可サーバ通信部
６ ：第２制御サーバ
７ ：認可サーバ
７１１ ：認可サーバプログラム記憶部
７１２ ：認証情報記憶部
７１３ ：認可情報記憶部
７１ ：記憶部
７２ ：処理部
７２１ ：認可情報生成部
７２２ ：認可要求判定処理部
７３ ：通信部
７３１ ：機器通信部
７３２ ：制御サーバ通信部

Claims (4)

1. ＭＱＴＴ（Message Queue Telemetry Transport）プロトコルに従って通信を行う制御対象機器を制御可能な機器制御システムであって、
   前記制御対象機器を制御する制御サーバと、
   前記制御対象機器から前記制御サーバに送信されるメッセージの許否を判定する認可サーバと、を具備し、
   前記認可サーバは、前記制御対象機器からの制御サーバ宛メッセージ送信認可要求に対して許可情報を生成して返送し、
   前記制御対象機器は、前記認可サーバから前記許可情報を受け付けた場合に、前記許可情報を含む前記メッセージを前記制御サーバへ送信し、
   前記制御サーバは、前記制御対象機器から前記メッセージを受け付けた場合に前記認可サーバに対し前記メッセージに含まれる前記許可情報の有効性を検証し、その検証結果に応じて前記制御対象機器から送信された前記メッセージの許否を判定することを特徴とする機器制御システム。
2. 前記機器制御システムは、前記制御サーバを少なくとも２以上具備し、
   前記認可サーバは、前記制御対象機器からの前記制御サーバのうち一の制御サーバ宛の前記制御サーバ宛メッセージ送信認可要求に対して前記許可情報を生成して返送し、
   前記制御対象機器は、前記認可サーバから前記許可情報を受け付けた場合に、前記許可情報を含む前記メッセージを前記一の制御サーバへ送信し、
   前記一の制御サーバは、前記制御対象機器から前記メッセージを受け付けた場合に前記認可サーバに対し前記メッセージに含まれる前記許可情報の有効性を検証し、その検証結果に応じて前記制御対象機器から送信された前記メッセージの許否を判定することを特徴とする請求項１に記載の機器制御システム。
3. 前記制御対象機器を一意に識別する端末ＩＤと前記制御サーバを一意に識別するサービスＩＤとの組み合わせを記憶する認証情報記憶部を更に備え、
   前記認可サーバは、前記制御対象機器から前記許可情報の要求を受け付けた場合には、要求を受け付けた前記制御対象機器の前記端末ＩＤと前記メッセージの送信先の前記制御サーバの前記サービスＩＤとの組み合わせが、前記認証情報記憶部に記憶されているかチェックし、前記チェックの結果、前記制御サーバの前記サービスＩＤとの組み合わせが前記認証情報記憶部に記憶されている場合には、前記認可情報を生成する
   ことを特徴とする請求項１または２に記載の機器制御システム。
4. ＭＱＴＴプロトコルに従って通信を行う制御対象機器を制御する制御サーバと、前記制御対象機器から前記制御サーバに送信されるメッセージの許否を判定する認可サーバと、を用いた機器制御方法であって、
   前記認可サーバにて、前記制御対象機器からの制御サーバ宛メッセージ送信認可要求に対して許可情報を生成して返送するステップと、
   前記制御対象機器にて、前記認可サーバから前記許可情報を受け付けた場合に、前記許可情報を含む前記メッセージを前記制御サーバへ送信するステップと、
   前記制御サーバにて、前記制御対象機器から前記メッセージを受け付けた場合に前記認可サーバに対し前記メッセージに含まれる前記許可情報の有効性を検証し、その検証結果に応じて前記制御対象機器から送信された前記メッセージ許否を判定するステップと、
   を有することを特徴とする機器制御方法。

Images