JP2016045673A

JP2016045673A - システム間連携装置

Info

Publication number: JP2016045673A
Application number: JP2014168972A
Authority: JP
Inventors: 佐藤　博明; Hiroaki Sato; 博明佐藤; 俊之山内; Toshiyuki Yamauchi
Original assignee: Hitachi Industry and Control Solutions Co Ltd
Current assignee: Hitachi Industry and Control Solutions Co Ltd
Priority date: 2014-08-22
Filing date: 2014-08-22
Publication date: 2016-04-04

Abstract

【課題】ハードウェアの構成およびプロトコルに依存しない形でサービスAPを実現できるため、開発量の低減、通信プロトコルの追加等による修正にかかわる作業量を低減することが可能なシステム間連携装置を提供する。
【解決手段】ハードウェアに接続される対象機器と、対象機器を制御内容を含むＡＰ制御データを出力するサービスアプリケーションと、を有し、サービスアプリケーションは、マルチ通信処理部を介してハードウェアと通信可能に接続されており、マルチ通信処理部は、サービスアプリケーションが生成する前記ＡＰ制御データを書き込むソフトウェアＩ/Ｆと、書きこまれたＡＰ制御データを取得し、対象機器に応じた通信プロトコルに必要な情報を付加する通信プロトコル処理部と、ハードウェアを制御するハードウェア制御部と、を有していることを特徴とするシステム間連携装置。
【選択図】図１

Description

本発明は、システム間連携装置に関する。

本技術分野の背景技術として、特開２００１−２５１３１８号がある（特許文献１）。この公報には、「複数のアプリケーションプログラム１１と、オペレーティングシステム１２と、両者の間に介在しデータの送受を司る通信ミドルウェア部１３を備える。通信ミドルウェア部は、ネットワークに接続されたデバイス１と、データ通信をするためのデバイスアクセス部１３ｂと、デバイスアクセス部に対し、デバイスとのデータの送受を命令する仮想メモリデータ管理部１３ａを有する。仮想メモリデータ管理部は、アプリケーションとの間で共通の通信手順を提供し、アプリケーションは、仮想メモリデータ管理部と通信することで、デバイスとデータの送受を可能とする。デバイス個々の通信プロトコルの相違は、デバイスアクセス部で吸収する。」と記載されている（要約参照）。

図７は、従来のシステム間連携装置７００の構成図を示したものであり、システム間連携装置７００がオフィスビル等の施設に設けられた例を示している。

本構成は、ひとつの制御装置内に実装されており、本実施例では、サービス機能として空調制御機能、入退室制御機能、ビル設備機器制御機能を持ったものとする。

本実施例におけるシステム間連携装置７００は、対象機器ＡＰ（Application Programming）７０１〜７０３、ハードウェア７０４〜７０６および対象機器７０７〜７０９を有している。

対象機器ＡＰとは、後述する対象機器を制御するためのソフトウェアのことをいい、本実施例では、空調制御用ＡＰ７０１、入退用ＡＰ７０２、ビル設備制御用ＡＰ７０３を有する。対象機器ＡＰが制御する対象機器が、対象機器毎に異なるハードウェアの通信ポートに接続されている場合には、対象機器ＡＰは、対象機器が接続されているハードウェアとプロトコルを認識し、それぞれのハードウェアに応じたハードウェア制御部と通信プロトコル処理を実装している。ハードウェア制御部および不図示の記憶部等に格納される通信プロトコルを有している。すなわち、対象機器ＡＰにおけるハードウェア制御部は、対象機器が接続されるハードウェアを認識したうえで作成・設置される。また、通信プロトコルも、対象機器ＡＰが制御する対象機器に応じたプロトコルを有する必要があるため、対象機器ＡＰが制御する対象機器を認識したうえで作成・格納される。

次に、対象機器とは、エアコン７０７等のような、ビル設備に設けられている機器をいい、本実施例では、Ｃ/Ｒ７０８およびセンサ/メータ等の設備機器７０９を有している。

また、ハードウェアとは、対象機器ＡＰや対象機器との間での通信に必要な信号処理や手順、またそれらを動作させるためのIC等のハードウェアとOS（オペレーティングシステム）で持つハードウェアI/Fのことをいう。例えばRS232C（７０４）、RS485（７０５）およびLAN（７０６）がある。

ここで、システム間連携装置７００において、空調制御用ＡＰによってエアコン７０７を制御する場合について、図８を用いて説明する。他の制御装置であるＣ/Ｒ（７０８）およびセンサ/メータ等の設備機器においても、その制御方法は同様である。

図８は、従来のシステム間連携装置７００における通信処理を示したものである。

ここでは、図１における空調制御用ＡＰ７０１が、エアコン７０７を冷房２５℃で制御する場合を例に説明する。

空調制御用ＡＰ７０１は、ハードウェア制御部（ＲＳ２３２Ｃ）から対象機器であるエアコン７０７を制御するためのＡＰ送信データを作成し、送信する。このときハードウェア制御部（ＲＳ２３２Ｃ）は、エアコン７０７が接続されているRS232C（７０４）の通信ポート制御を実行するとともに、エアコン制御に必要なデータに対して、空調用プロトコルに必要な情報を負荷する。具体的には、図２に示すように、送信データとして運転開始、冷房、２５℃というデータ群に対して、空調用プロトコルに必要なデータを付加する。ＳＴＸ（データの開始を示す）、空調号機（制御対象のエアコン７０７の指定）、チェックコード（データの整合性をチェックするためのチェックコード）およびＥＴＸ（データの終了を示す）を付加する。このようにして空調通信プロトコルに必要なデータが付加されたデータを、対応するハードウェアＲＳ２３２Ｃに送信し、エアコン７０７は送信データの要求に応じて制御を実行する。そして、エアコン７０７は、ＳＲ２３２Ｃ（７０４）を介して空調制御用ＡＰ７０１にＡＰ受信データによって、制御結果を返信する。返信時には、送信時に付加したデータを削除し、エアコン制御に必要なデータを抽出して返信を行う。

上述した従来技術においては、サービスAPが通信にかかわるハードウェアおよび通信プロトコルを意識した作りとならざるを得なくなり、APの開発時の作業量、修正時の作業量が大きかった。また、通信機能が追加になった際、必ずAPと抱き合わせで実装することが必要となり、予めハードウェアや通信プロトコルのみを実装しておき、必要な時にAPを実装する等事前に拡張することができなかった。

そこで本発明は、ハードウェアの構成およびプロトコルに依存しない形でサービスAPを実現できるため、開発量の低減、通信プロトコルの追加等による修正にかかわる作業量を低減することが可能なシステム間連携装置を提供する。

上記課題を解決するために、本発明は、ハードウェアに接続される対象機器と、対象機器を制御内容を含むＡＰ制御データを出力するサービスアプリケーションと、を有し、サービスアプリケーションは、マルチ通信処理部を介してハードウェアと通信可能に接続されており、マルチ通信処理部は、サービスアプリケーションが生成する前記ＡＰ制御データを書き込むソフトウェアＩ/Ｆと、書きこまれたＡＰ制御データを取得し、対象機器に応じた通信プロトコルに必要な情報を付加する通信プロトコル処理部と、ハードウェアを制御するハードウェア制御部と、を有する。

本発明は、ハードウェアの構成およびプロトコルに依存しない形でサービスAPを実現できるため、開発量の低減、通信プロトコルの追加等による修正にかかわる作業量を低減することが可能なシステム間連携装置を提供することができる。

本実施例のシステム間連携装置１００の構成図を示したものである。初期化設定情報ｓ１を説明する図である。本実施例における空調制御ＡＰでエアコンを制御する例を示す。本実施例において、空調用制御ＡＰ１０１でエアコン１１７を制御した後に、空調用制御ＡＰ１０１に制御結果を返信する場合の例を示す。新たな空調制御機器として、RS232CではなくLANに接続されるタイプのものを新規に追加し、開発が必要になった場合の例である。プログラムの拡張における初期設定情報Ｓ１’を示したものである。従来のシステム間連携装置７００の構成図を示したものである。従来のシステム間連携装置７００における通信処理を示したものである。

以下、本実施例を図面を用いて説明する。

図１は、本実施例のシステム間連携装置１００の構成図を示したものであり、システム間連携装置１００がオフィスビル等の施設に設けられた例を示している。

システム間連携装置１００は、対象機器ＡＰ１０１〜１０３、マルチ通信処理部１０４、ハードウェア１１４〜１１６および対象機器１１７〜１１９を有している。ハードウェア１１４〜１１６および対象機器１１７〜１１９は、前述した図７における構成と同様なので説明を省略する。

マルチ通信処理部１０４は、対象機器ＡＰ１０１〜１０３およびハードウェア１１４〜１１６をそれぞれ通信可能なように設けられ、接続される対象機器毎に応じたハードウェア制御処理部１１１〜１１３および通信プロトコル処理部１０８〜１１０を有している。さらに、対象機器ＡＰとのＩ/Ｆとして、ソフトウェアI/Fとしてバッファ１０５〜１０７を有する構成とする。尚、ソフトウェアI/Fはバッファ以外にも、API（Application Programming Interface）のようなI/Fでも良い。ここでは、対象機器ＡＰと、各対象機器ＡＰと通信を行うマルチ通信処理部を論理通信ポートと称する、例えば、論理通信ポート１は、空調用制御ＡＰ１０１、バッファ１（１０５）、空調用プロトコル１０８およびハードウェア制御部１１１のことをいう。

論理通信ポート１における本実施例のマルチ通信処理部１０４は、エアコン１１７がＲＳ２３２Ｃ（１１４）のみに接続されることを予め認識し、空調用プロトコル処理部１０８およびハードウェア制御部（ＲＳ２３２Ｃ）１１１を有している。

以下、図２〜４を用いながら、本実施例の動作を説明する。

まず、初期化に関して図２を用いて説明する。

図２は、初期化設定情報ｓ１を説明する図である。

マルチ通信処理部１０４は、初期起動時に通信に必要となるハードウェアの情報と通信プロトコルを記憶した、初期設定情報s1を取得する。初期設定情報s1は、ハードウェア制御装置に格納された情報であり、ソフトウェアで読み込み可能な形式で格納されているものである。初期設定情報s1には、通信ポートの名称、通信種別、伝送速度、対応する通信プロトコル情報、処理に必要なメモリ等の構築情報を記憶している。

例えば、図１における論理通信ポート１における通信ポート１は、ハードウェアがRS232C、対応するプロトコルが空調機制御用プロトコルであること、制御装置内の論理通信ポート1が空調機であることを認識し、通信に必要な初期設定を実行する。具体的には、空調機制御用の通信ポートとして、論理通信ポート1に割り付いた上位APとのインタフェースであるバッファ1（１０５）を構築する。同様に空調用制御AP（ap1）も、上記初期設定情報s1を取り込み、空調機器と通信を行うための通信ポートの情報を取得し、記憶する。以上により、初期設定が完了する。

図３は、本実施例における空調制御ＡＰでエアコンを制御する例を示す。

空調制御用ＡＰ１０１は、エアコン１１７を制御するために必要なデータＡＰ制御データｄ１として、例えば、運転の開始、停止の情報（図中では運転開始）、空調の動作モード（図中では冷房）、設定温度（図中では25℃）からなるデータを有する。空調制御AP１０１は、データＡＰ制御データｄ１をマルチ通信処理部１０４のバッファ1（１０５）へ書き込む。書き込まれたことで、マルチ通信処理部１０４内に制御データd1が取り込まれることとなる。

次に、マルチ通信処理部１０４は、空調用制御ＡＰ１０１からの指令に基づき、取り込んだ制御データd1に対して通信プロトコル１０８に必要な情報（pd1〜pd4）を付加し、マルチ通信処理送信データd2を生成する。ここで、STX（ｐｄ１）は、データの開始を示し、空調号機（ｐｄ２）は、相手空調機の指定、チェックコード（ｐｄ３）は、データの整合性をチェックするためのチェックコード、ETX（ｐｄ４）は、データの終了を示す。
そして、ハードウェア制御部１１１を介して、実際のRS232Cのハードウェア１１４を制御し通信回線へデータを送信する。これにより、通信相手のエアコン１１７に要求データを送信する。

図４は、本実施例において、空調用制御ＡＰ１０１でエアコン１１７を制御した後に、空調用制御ＡＰ１０１に制御結果を返信する場合の例を示す。

まず、要求を受け取ったエアコン１１７は、要求に応じた制御を実行した後に、その制御結果をプロトコルに沿ったデータとして返信する。マルチ通信処理部１０４は、ハードウェア（ＲＳ２３２Ｃ）から返信データd3を受信し、プロトコルのみに使用していたデータ（pd1〜pd4）を削除し、空調制御AP（ap1’）に必要な部分のみを抽出し、抽出したデータd4をバッファ1（１０５）に書き込む。空調制御AP１０１は、バッファ１（１０５）を読み出すことで、制御結果を受け取ることができる。

以上のように、サービスAPと通信に関連するハードウェア制御部と通信プロトコルを独立した構成とするようなマルチ通信処理部を設けることで、上位APは本来扱うべき処理のみの実装とすることができ、その分の開発量と通信プロトコルの追加を含めた修正にかかわる作業量が減ることとなり、効率化を図ることができる。

次に、プログラムの拡張に関して実施例を記述する。

図５は、新たな空調制御機器として、RS232CではなくLANに接続されるタイプのものを新規に追加し、開発が必要になった場合の例である。

図５では、空調用制御AP５０１の対象として、RS232C（５１３）に接続し空調制御プロトコル1(５０７)により対応できるエアコン1(５１６)が既に実装されていたとする。これに対して、LAN５１４に接続し、空調制御プロトコル2(５０８)に対応したエアコン2(５１７)に対応が必要になったと想定する。

この場合、マルチ通信処理部５０３においては、追加されるべき空調制御プロトコル2(５０８)を独立に開発実装し、さらに、従来とは異なるハードウェアであるLAN５１４に接続するためのハードウェア制御部2（５１１）を実装する。そして、ソフトウェアI/Fとしてのバッファ２（５０５）を実装する。

図６は、プログラムの拡張における初期設定情報Ｓ１’を示したものである。

初期設定情報s1’に示すように、空調用プロトコル2(５０８)に対応した通信ポートを初期設定情報s1’に登録しておくことで、マルチ通信処理部５０３が起動した際に、初期設定情報s1’に従い上位APとのI/Fに必要なソフトウェアI/Fであるバッファ2（５０５）を構築することが可能である。このように、本実施例の構成によれば、上位APがなくとも、通信プロトコルやハードウェア制御部を追加することが可能である。空調用プロトコル2(５０８)を利用するAPの実装が必要な場合は、マルチ通信処理部とは独立した形で開発、実装することができ、また、必要な際に制御装置に実装することで機能追加できる。追加以外にも、マルチ通信処理部の修正や上位APの修正が発生した場合においても、独立性が保たれることで、個々に作業が可能となる。このように、マルチ通信処理部に、バッファ等のソフトウェアI/Fを設け、構成を分けることで、APおよび通信処理部が独立して拡張可能となる。

１００システム間連携装置
１０１空調用制御ＡＰ
１０２入退用ＡＰ
１０３ビル設備制御用ＡＰ
１０４マルチ通信処理部
１０５バッファ１
１０６バッファ２
１０７バッファ３
１０８空調用プロトコル処理部
１０９Ｃ/Ｒ用プロトコル処理部
１１０設備機器用プロトコル処理部
１１１ハードウェア制御部１
１１２ハードウェア制御部２
１１３ハードウェア制御部３
１１４ＲＳ２３２Ｃ
１１５ＲＳ４８５
１１６ＬＡＮ
１１７エアコン
１１８Ｃ/Ｒ
１１９センサ/メータ等の設備機器

Claims

ハードウェアに接続される対象機器と、
前記対象機器を制御内容を含むＡＰ制御データを出力するサービスアプリケーションと、
を有し、
前記サービスアプリケーションは、マルチ通信処理部を介して前記ハードウェアと通信可能に接続されており、
前記マルチ通信処理部は、
前記サービスアプリケーションが生成する前記ＡＰ制御データを書き込むソフトウェアＩ/Ｆと、書きこまれた前記ＡＰ制御データを取得し、前記対象機器に応じた通信プロトコルに必要な情報を付加する通信プロトコル処理部と、前記ハードウェアを制御するハードウェア制御部と、を有していることを特徴とするシステム間連携装置。
請求項1に記載のシステム間連携装置において、
前記対象機器の制御結果をサービスアプリケーションに送信する場合は、
前記対象機器は、通信プロトコルに必要なデータを含むマルチ通信処理受信データを前記マルチ通信処理部に送信し、
前記マルチ通信処理部は、前記マルチ通信処理受信データに含まれる前記通信プロトコルに必要なデータを削除したＡＰ制御結果データを生成するとともに、前記ＡＰ制御結果データを前記ソフトウェアＩ/Ｆに書き込み、
前記サービスアプリケーションは、前記ソフトウェアＩ/Ｆから前記ＡＰ制御結果データを読み出すことにより、前記対象機器の制御結果を取得することを特徴とするシステム間連携装置。
請求項1に記載のシステム間連携装置において、
新たに対象機器を追加する場合には、
前記マルチ通信処理部において、前記新たに追加される対象機器が接続されるハードウェアを制御するためのハードウェア制御部と、前記新たに追加される対象機器に応じた通信プロトコルに必要な情報を付加する通信プロトコル処理部と、前記新たに追加される対象機器を制御内容を含むサービスアプリケーションから出力されるＡＰ制御データを書き込むソフトウェアＩ/Ｆと、を新たに設けることを特徴とするシステム間連携装置。