JP6109997B1 - ソフトウェア生成システム、情報処理装置およびプログラム - Google Patents

Abstract

【課題】制御対象機器の通信機能を制御して当該制御対象機器を制御する命令を受け付けたり当該制御対象機器から情報を出力したりさせるソフトウェアを簡易に生成する。【解決手段】ファームウェア生成システムは、制御対象機器の情報を受け付けて当該制御対象機器の通信機能を制御するためのソフトウェアを生成するファームウェア生成サーバ２０と、制御対象機器の情報をファームウェア生成サーバ２０に送信する利用者端末と、を備える。利用者端末は、制御対象機器の情報をファームウェア生成サーバ２０へ送信し、ファームウェア生成サーバ２０は、利用者端末から送信された制御対象機器の情報を予め定められた第１のコードのフォーマットに適用して第１のコードを生成するソースコード生成部２２と、ソースコード生成部２２により生成された第１のコードおよび予め用意された第２のコードに基づいて、制御対象機器の通信機能を制御するソフトウェアを生成するファームウェア生成部２３と、を備える。【選択図】図５

Description

本発明は、ソフトウェア生成システム、情報処理装置およびプログラムに関する。

近年、インターネットの普及に伴い、あらゆるものをネットワークに接続するＩｏＴ（Internet of Things）という概念が提案されている。例えば家電等の電気機器をネットワークに接続し、これらの電気機器を制御する技術が知られている。

例えば、エアコンディショナ等の家電を制御する技術として、特許文献１には、電気機器に制御信号を送信するためのコントローラであって、携帯端末から送信された電気機器に対する指示を、サーバから受信するための通信部と、電気機器に対する制御信号を記憶するための記憶部と、プロセッサとを備え、プロセッサは、通信部から受信した電気機器に対する指示を電気機器に送信するとともに、サーバとの接続が継続されていないと判断した場合には、電気機器に対して、記憶部に記憶された制御信号であって、当該電気機器の特定の状態に対応する制御信号を送信するように構成されている、コントローラが開示されている。

また、例えば、照明器具を制御する技術として、特許文献２には、外部機器から照明光の制御を行う情報を含む制御信号を無線方式または有線方式により受信する通信部と通信部が受信した制御信号を点灯制御信号に変換する信号変換部とを有する通信ユニットと、光源を点灯させる点灯回路部と点灯制御信号に基づいて点灯回路部を制御する点灯制御部とを有する点灯ユニットと、を備え、点灯ユニットと接続する通信ユニットは、外部機器が送信する制御信号の信号方式に応じて通信方式が異なる通信ユニットと交換可能なことを特徴とする点灯装置が開示されている。

特開２０１５−１９８４２４号公報 特開２０１５−１０９１９６号公報

家電等の電気機器をネットワークに接続させ、このネットワークを介して電気機器を外部から制御したり、電気機器から情報を出力させたりするには、この電気機器に通信機能を持たせ、電気機器の制御装置やセンサとの間で情報交換を行うことが必要となる。そして、電気機器には多くの種類が存在し、様々な機能が設けられているため、電気機器の通信機能を制御するソフトウェアは、制御しようとする電気機器の種類や機能に応じて個別に生成されていた。このようなソフトウェアを人手で生成する作業には、一般に、非常に多くの時間と手間がかかる。そのため、かかるソフトウェアを手軽に生成する手段の提供が望まれていた。
本発明の目的は、制御対象機器の通信機能を制御して当該制御対象機器を制御する命令を受け付けたり当該制御対象機器から情報を出力したりさせるソフトウェアを簡易に生成することを目的とする。

かかる目的のもと、本発明は、制御対象機器の情報を受け付けて当該制御対象機器の通信機能を制御するためのソフトウェアを生成するサーバと、前記制御対象機器の情報を前記サーバに送信する端末装置と、を備え、前記サーバは、前記端末装置から送信された前記制御対象機器の情報を予め定められた第１のコードのフォーマットに適用して第１のコードを生成するコード生成部と、前記コード生成部により生成された前記第１のコードおよび予め用意された第２のコードに基づいて、前記制御対象機器の通信機能を制御するソフトウェアを生成するソフトウェア生成部と、を備えることを特徴とする、ソフトウェア生成システムを提供する。
また、前記端末装置は、前記制御対象機器に関して前記ソフトウェアを生成するために特定を要する項目をメニュー表示する表示手段と、前記表示手段により表示されたメニューに基づき、前記項目を選択することにより前記制御対象機器の情報を入力する操作を受け付ける操作受け付け手段と、を備えることを特徴とする。
さらに、本発明は、制御対象機器の情報を受け付ける受付部と、予め定められた第１のコードのフォーマットを格納したフォーマット格納部と、予め定められた第２のコードを格納したコード格納部と、前記受付部により受け付けた前記制御対象機器の情報を前記フォーマット格納部に格納された前記第１のコードのフォーマットに適用して第１のコードを生成するコード生成部と、前記コード生成部により生成された前記第１のコードおよび前記コード格納部から読み出した前記第２のコードに基づいて、前記制御対象機器の通信機能を制御するソフトウェアを生成するソフトウェア生成部と、を備えることを特徴とする、情報処理装置を提供する。
また、前記受付部により受け付けた前記制御対象機器の情報は、当該制御対象機器の種類および特定の機能の情報を含み、前記コード生成部により生成される前記第１のコードは、前記制御対象機器の種類および前記特定の機能を前記第１のコードのフォーマットに則って記述したコードであり、前記コード格納部に格納された前記第２のコードは、前記第１のコードを参照して実行する手続きが記述された、記述内容が前記制御対象機器の種類および当該制御対象機器の機能によらない固定的なコードであることを特徴とする。
さらに、前記コード格納部に格納された前記第２のコードは、前記制御対象機器の通信機能を制御し、当該制御対象機器の機能を実現する機能実現手段のうち、前記第１のコードに記述された機能についての機能実現手段との間で情報交換を行うための手続きが記述されたコードであることを特徴とする。
そして、本発明は、コンピュータを、制御対象機器の情報を受け付ける受付手段と、記憶装置から予め定められた第１のコードのフォーマットを読み出し、前記受付手段により受け付けた前記制御対象機器の情報を当該第１のコードのフォーマットに適用して第１のコードを生成するコード生成手段と、記憶装置から予め定められた第２のコードを読み出し、当該第２のコードおよび前記コード生成手段により生成された前記第１のコードに基づいて、前記制御対象機器の通信機能を制御するソフトウェアを生成するソフトウェア生成手段として、機能させることを特徴とする、プログラムを提供する。

本発明によれば、制御対象機器の通信機能を制御して当該制御対象機器を制御する命令を受け付けたり当該制御対象機器から情報を出力したりさせるソフトウェアを簡易に生成することができる。

本実施の形態の背景について説明するための図である。 本実施の形態に係るファームウェア生成システムの全体構成例を示した図である。 本実施の形態に係るファームウェア生成サーバ又は利用者端末として用いられるコンピュータのハードウェア構成例を示す図である。 本実施の形態に係る利用者端末の機能構成例を示したブロック図である。 本実施の形態に係るファームウェア生成サーバの機能構成例を示したブロック図である。 利用者入力情報の一例を示す図である。 （ａ）〜（ｃ）は、利用者入力情報を入力する際に表示される画面の一例を示す図である。 （ａ）〜（ｃ）は、利用者入力情報を入力する際に表示される画面の一例を示す図である。 （ａ），（ｂ）は、利用者入力情報を入力する際に表示される画面の一例を示す図である。 （ａ），（ｂ）は、利用者入力情報を入力する際に表示される画面の一例を示す図である。 （ｃ）〜（ｅ）は、利用者入力情報を入力する際に表示される画面の一例を示す図である。 （ａ），（ｂ）は、利用者入力情報を入力する際に表示される画面の一例を示す図である。 利用者入力情報の変換に用いられるキーの一例を示す図である。 （ａ）は、サーバ送信用データに適用されるソースコード生成用フォーマットの一例を示す図である。（ｂ）は、ソースコード（データ部）の一例を示す図である。 （ａ），（ｂ）は、ファームウェア生成部により生成されるファームウェアのコードの一例を示す概念図である。 ファームウェア生成システムにおいてファームウェアを生成する処理手順の一例を示したフローチャートである。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
＜背景＞
まず、本実施の形態の背景について説明する。
近年、例えば家電等の電気機器をネットワークに接続し、これらの電気機器を制御するために、ホームネットワーク用の通信規格の業界標準化が進められている。そして、複数のメーカーで共通的に使用される通信規格が作成され、マルチベンダでの相互接続環境が整備されつつある。このような共通の通信規格には、例えばＥＣＨＯＮＥＴ Ｌｉｔｅ（登録商標）があり、一般社団法人エコーネットコンソーシアムによって標準化が図られている。このような通信規格を用いることにより、ユーザの操作によって家電等の電気機器を制御することができる。

図１は、本実施の形態の背景について説明するための図である。端末装置１００は、ユーザが使用する端末であり、例えば、ＰＣ（personal computer）や携帯情報端末（いわゆる、スマートフォンやタブレット端末等）などを例示することができる。電気機器２００は、制御対象の電気機器であり、例えば、エアコンディショナや照明器具、冷蔵庫などの家電を例示することができる。ネットワーク３００は、端末装置１００と電気機器２００との間の情報通信に用いられる通信手段であり、例えば、インターネットを例示することができる。

このような構成において、ユーザが端末装置１００を操作することにより、ネットワーク３００を介して端末装置１００から電気機器２００を制御したり、電気機器２００から端末装置１００へ情報を送信させたりするには、電気機器２００に通信機能を持たせ、電気機器２００の制御装置やセンサとの間で情報交換を行うことが必要になる。そこで、電気機器２００の通信機能を制御して、電気機器２００を制御する命令を受け付けたり電気機器２００から情報を出力したりさせるためのソフトウェアが用いられる。このようなソフトウェアをインストールした通信制御基板４００を電気機器２００に搭載することにより、電気機器２００の通信機能の制御が行われる。なお、電気機器２００の通信機能の制御については、通信制御基板４００を搭載することにより新たに電気機器２００に備えられた通信機能を制御する場合もあれば、通信制御基板４００の搭載前から電気機器２００に備えられている通信機能を制御する場合もあるものとする。

さらに説明すると、図１に示すように、通信制御基板４００には、上述したような電気機器２００の通信機能を制御するためのソフトウェアである家電制御用ソフトウェアに加えて、通信モジュール制御用ソフトウェアおよび通信モジュールが含まれる。この通信モジュールとしては、例えばＢｌｕｅｔｏｏｔｈ（登録商標）モジュールを用いることができる。ここで、Ｂｌｕｅｔｏｏｔｈモジュールは、無線通信規格のモジュールであり、端末装置１００のような外部機器と無線通信を行うためのものである。なお、本実施の形態では、Ｂｌｕｅｔｏｏｔｈモジュールを用いた構成に限られるものではなく、例えば、Ｗｉ−Ｆｉ（Wireless Fidelity）（登録商標）、Ｚｉｇｂｅｅなどの他の無線通信規格のモジュールを用いても良い。さらに、無線通信規格のモジュールを用いる構成に限られず、有線の通信規格を備えたモジュールを用いても良い。また、通信モジュール制御用ソフトウェアは、家電制御用ソフトウェアとＢｌｕｅｔｏｏｔｈモジュールとの間でデータの送受信を行うためのソフトウェアである。図示の例では、通信モジュール制御用ソフトウェアにおけるプロトコルの一例として、ＩＰｖ６（Internet Protocol Version 6）、６ＬｏＷＰＡＮ（IPv6 over Low power Wireless Personal Area Networks）を用いている。なお、通信モジュール制御用ソフトウェアにて用いるプロトコルについても、ＩＰｖ６、６ＬｏＷＰＡＮ等のプロトコルに限られるものではなく、家電制御用ソフトウェアがデータの送受信を行うために使用可能なプロトコルであれば、どのようなプロトコルを用いても良い。

このように構成された通信制御基板４００は、家電制御用ソフトウェアの制御により、端末装置１００からの制御信号を受け付けて電気機器２００の機能実行手段を制御したり、機能実行手段から取得した情報を端末装置１００へ出力したりする。ここで、機能実行手段としては、電気機器２００の各種の機能を制御する制御装置、種々の動作を実行するアクチュエータ、電気機器２００の動作に関する情報を取得する種々のセンサ等を例示することができる。例えば、電気機器２００がエアコンディショナの場合について説明する。エアコンディショナ内には、独自の機能プログラムにより、例えば温度を設定したり風量を設定したりするための制御装置が予め搭載されている。そして、家電制御用ソフトウェアにより制御される通信制御基板４００が、端末装置１００から受信した温度設定命令や風量設定命令を制御装置に送って温度や風量の設定をさせたり、センサから温度や風量の設定値や測定値を取得して端末装置１００へ送信したりすることができるようになる。

そして、本実施の形態では、ユーザが画面に従って入力することにより、上述したような電気機器の通信機能を制御するための家電制御用ソフトウェアを生成するソフトウェア生成システムを提供する。また、本実施の形態では、電気機器の通信機能を制御するためのソフトウェアの一例として、電気機器の通信機能を制御するために電気機器に組み込まれるソフトウェアであるファームウェアを例にして説明する。

なお、以下では、特に家電を制御するための通信規格であるＥＣＨＯＮＥＴ Ｌｉｔｅを用いて説明するが、このような構成に限られるものではない。本実施の形態に係るファームウェア生成システム１は、ＥＣＨＯＮＥＴ Ｌｉｔｅ以外の他の通信規格を用いて、家電を含む種々の電気機器を制御する場合にも適用することができる。また、以下では、ファームウェア生成システム１により生成される家電制御用のファームウェアを、単に「ファームウェア」と称する場合がある。

＜ファームウェア生成システムの全体構成＞
次に、本実施の形態に係るファームウェア生成システム１の全体構成について説明する。図２は、本実施の形態に係るファームウェア生成システム１の全体構成例を示した図である。図示するように、このファームウェア生成システム１は、利用者端末１０とファームウェア生成サーバ２０とがネットワーク３０を介して接続されることにより構成される。

利用者端末１０は、ファームウェア生成システム１を利用する利用者が操作するコンピュータ装置であり、例えば、ＰＣや携帯情報端末等が例示される。この利用者端末１０は、ファームウェアを生成するために利用者が入力した情報（以下、利用者入力情報と称する）を受け付ける。この利用者入力情報には、例えば、ファームウェアがインストールされた通信制御基板４００（図１参照）により実現される通信機能を介して制御しようとする対象の機器（以下、対象機器と称する）の種類を指定する情報や、対象機器における制御しようとする機能を指定する情報が含まれる。そして、利用者端末１０は、受け付けた利用者入力情報をファームウェア生成サーバ２０にて識別可能（処理可能）な形式へ変換して、ファームウェア生成サーバ２０へ送信する。以下では、利用者入力情報に変換を施した変換後のデータを、「サーバ送信用データ」と称する。本実施の形態では、制御対象機器の情報をサーバに送信する端末装置の一例として、利用者端末１０が用いられる。

情報処理装置の一例としてのファームウェア生成サーバ２０は、対象機器の通信機能を制御するためのファームウェアを生成するコンピュータ装置であり、例えば、ＰＣ、ワークステーション等が例示される。このファームウェア生成サーバ２０は、利用者端末１０から受信したサーバ送信用データを基に、ファームウェアを生成する。本実施の形態では、制御対象機器の通信機能を制御するためのソフトウェアを生成するサーバの一例として、ファームウェア生成サーバ２０が用いられる。

ネットワーク３０は、利用者端末１０とファームウェア生成サーバ２０との間の情報通信に用いられる通信手段であり、例えば、インターネット、ＬＡＮ（Local Area Network）等である。

＜ハードウェア構成＞
次に、本実施の形態に係るファームウェア生成サーバ２０および利用者端末１０のハードウェア構成について説明する。図３は、本実施の形態に係るファームウェア生成サーバ２０又は利用者端末１０として用いられるコンピュータのハードウェア構成例を示す図である。

図示するように、ファームウェア生成サーバ２０は、演算手段であるＣＰＵ（Central Processing Unit）２０ａと、主記憶手段であるメモリ２０ｃを備える。また、外部デバイスとして、磁気ディスク装置（ＨＤＤ：Hard Disk Drive）２０ｇ、ネットワークインタフェース２０ｆ、ディスプレイ装置を含む表示機構２０ｄ、音声機構２０ｈ、キーボードやマウス等の入力デバイス２０ｉ等を備える。

図３に示す構成例では、メモリ２０ｃおよび表示機構２０ｄは、システムコントローラ２０ｂを介してＣＰＵ２０ａに接続されている。また、ネットワークインタフェース２０ｆ、磁気ディスク装置２０ｇ、音声機構２０ｈおよび入力デバイス２０ｉは、Ｉ／Ｏコントローラ２０ｅを介してシステムコントローラ２０ｂと接続されている。各構成要素は、システム・バスや入出力バス等の各種のバスによって接続される。

また、図３において、磁気ディスク装置２０ｇにはＯＳのプログラムやアプリケーション・プログラムが格納されている。そして、これらのプログラムがメモリ２０ｃに読み込まれてＣＰＵ２０ａに実行されることにより、ファームウェア生成サーバ２０の各種機能が実現される。

なお、図３は、本実施の形態が適用されるのに好適なコンピュータのハードウェア構成を例示するに過ぎない。本実施の形態は、ファームウェアを生成する装置に広く適用できるものであり、図示の構成においてのみ本実施の形態が実現されるのではない。

＜利用者端末の機能構成＞
次に、利用者端末１０の機能構成について説明する。図４は、本実施の形態に係る利用者端末１０の機能構成例を示したブロック図である。

図示するように、利用者端末１０は、利用者が入力した利用者入力情報を受け付ける入力情報受付部１１と、受け付けた利用者入力情報をサーバ送信用データへ変換するデータ変換部１２と、サーバ送信用データをファームウェア生成サーバ２０へ送信するデータ送信部１３とを備える。

入力情報受付部１１は、利用者が入力した利用者入力情報を受け付ける。より具体的には、利用者は、例えば利用者端末１０の表示機構により表示画面に表示される画面上で、対象機器を選択したり、対象機器において制御しようとする機能を選択したりすることにより、利用者入力情報を入力する。付言すると、対象機器に関してファームウェアを生成するために特定を要する項目がメニュー表示されるため、利用者は、表示されたメニューに基づき項目を選択して情報を入力すれば良い。利用者入力情報、および利用者入力情報を入力する際の画面の詳細については、後述する。本実施の形態では、入力情報受付部１１は、表示手段、操作受け付け手段の一例として捉えることもできる。

データ変換部１２は、入力情報受付部１１が受け付けた利用者入力情報を、サーバ送信用データへ変換する。サーバ送信用データの詳細については、後述する。

データ送信部１３は、データ変換部１２により生成されたサーバ送信用データを、ファームウェア生成サーバ２０へ送信する。

なお、図４に示す利用者端末１０を構成する各機能部は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、利用者端末１０を図３に示したコンピュータにて実現した場合、例えば、磁気ディスク装置２０ｇに格納されているＯＳのプログラムやアプリケーション・プログラムが、メモリ２０ｃに読み込まれてＣＰＵ２０ａに実行されることにより、入力情報受付部１１、データ変換部１２、データ送信部１３の各機能が実現される。

＜ファームウェア生成サーバの機能構成＞
次に、ファームウェア生成サーバ２０の機能構成について説明する。図５は、本実施の形態に係るファームウェア生成サーバ２０の機能構成例を示したブロック図である。

図示するように、ファームウェア生成サーバ２０は、主にデータの処理に関わる機能部として、サーバ送信用データを受け付けるデータ受付部２１と、サーバ送信用データを基に、後述するソースコード（データ部）を生成するソースコード生成部２２と、ソースコード（データ部）と後述するソースコード（手続き部）とを結合してファームウェアを生成するファームウェア生成部２３とを備える。また、ファームウェア生成サーバ２０は、主にデータの格納に関わる機能部として、後述するソースコード生成用フォーマットを格納するフォーマット格納部２４と、ソースコード（手続き部）を格納するソースコード格納部２５とを備える。

データ受付部２１は、利用者端末１０からサーバ送信用データを受け付ける。本実施の形態では、制御対象機器の情報を受け付ける受付部の一例として、データ受付部２１が用いられる。

ソースコード生成部２２は、フォーマット格納部２４から、ソースコード（データ部）を生成するために使用するフォーマット（以下、ソースコード生成用フォーマットと称する）を取得する。そして、ソースコード生成部２２は、サーバ送信用データをソースコード生成用フォーマットに適用し、ソースコード生成用フォーマットに適合するようにサーバ送信用データを変換して、ソースコード（データ部）を生成する。ソースコード生成部２２がソースコード（データ部）を生成する処理の詳細については、後述する。本実施の形態では、予め定められた第１のコードのフォーマットの一例として、ソースコード生成用フォーマットが用いられる。また、第１のコードの一例として、ソースコード（データ部）が用いられる。さらに、第１のコードを生成するコード生成部の一例として、ソースコード生成部２２が用いられる。

ファームウェア生成部２３は、ソースコード格納部２５から、予め定められたコードであるソースコード（手続き部）を取得する。このソースコード（手続き部）は、ソースコード（データ部）を参照して実行する手続きが記述されたコードである。さらに説明すると、このソースコード（手続き部）は、ソースコード（データ部）に記述された対象機器の機能を実現する機能実現手段との間で情報交換を行うための手続きが記述されたコードである。

そして、ファームウェア生成部２３は、取得したソースコード（手続き部）と、ソースコード生成部２２により生成されたソースコード（データ部）とを結合して、ファームウェアのソースコードを生成する。また、ファームウェア生成部２３は、生成したソースコードをコンパイルして、ファームウェアを生成する。そして、ファームウェア生成部２３は、生成したファームウェアを利用者端末１０へ送信する。本実施の形態では、予め用意された第２のコードの一例として、ソースコード（手続き部）が用いられる。また、制御対象機器の通信機能を制御するソフトウェアを生成するソフトウェア生成部の一例として、ファームウェア生成部２３が用いられる。

付言すると、ソースコード生成部２２が生成するソースコード（データ部）は、利用者が入力した利用者入力情報に応じて内容が変わる。一方で、ソースコード（手続き部）は、利用者が入力した利用者入力情報によらず一定である。言い換えると、ソースコード（手続き部）は、その記述内容が対象機器の種類および対象機器の機能によらない固定的なコードである。即ち、ソースコード（手続き部）は、ソースコード（データ部）がどのような内容であっても対応できるように、予め定められている。ソースコード（手続き部）の詳細については、後述する。

フォーマット格納部２４は、ソースコード生成用フォーマットを格納する。本実施の形態では、第１のコードのフォーマットを格納したフォーマット格納部の一例として、フォーマット格納部２４が用いられる。

ソースコード格納部２５は、ソースコード（手続き部）を格納する。本実施の形態では、第２のコードを格納したコード格納部の一例として、ソースコード格納部２５が用いられる。

なお、図５に示すファームウェア生成サーバ２０を構成する各機能部は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、ファームウェア生成サーバ２０を図３に示したコンピュータにて実現した場合、磁気ディスク装置２０ｇに格納されているＯＳのプログラムやアプリケーション・プログラムが、メモリ２０ｃに読み込まれてＣＰＵ２０ａに実行されることにより、データ受付部２１、ソースコード生成部２２、ファームウェア生成部２３の各機能が実現される。また、フォーマット格納部２４、ソースコード格納部２５は、メモリ２０ｃや磁気ディスク装置２０ｇ等の記憶手段により実現される。

＜利用者入力情報の説明＞
次に、利用者が画面上で入力する利用者入力情報について説明する。図６は、利用者入力情報の一例を示す図である。図示の例は、対象機器が「単機能照明」の場合の利用者入力情報である。「単機能照明」とは、電源のＯＮ・ＯＦＦ設定や照度レベル設定等の単純な機能しか持たない照明機器である。

より具体的には、「機器種別」は、対象機器の種別を示す。図示の例では「単機能照明」を示している。「機能種別」は、対象機器において制御しようとする機能の種別を示す。図示の例では「動作状態」の機能を示している。「動作状態」とは、電源のＯＮ・ＯＦＦ設定の機能である。「命令種別」は、該当機能において使用する命令の種別を示す。図示の例では、「動作状態」の機能において、取得命令（即ち、単機能照明から情報を取得する命令）、操作命令（即ち、単機能照明を操作する命令）を使用することを示している。

「インタフェース種別」は、ファームウェアと対象機器（ここでは、単機能照明）との間のインタフェースの種別を示す。そして、「取得用」は、取得命令にて用いられるインタフェースの種別を示し、「操作用」は、操作命令にて用いられるインタフェースの種別を示す。さらに、「ピンタイプ」は、インタフェースにおけるピンの入出力を示す。「Ｉ／Ｏ関数」は、インタフェースにて対象機器から値を読み込む場合の手続き（又は、対象機器に値を書き込む場合の手続き）を定めた関数を示す。「変数」は、インタフェースに関する変数であり、インタフェースのピンタイプによって、変数の種類や数は変化する。

図示の例では、取得用のインタフェースは「ＧＰＩＯ（General Purpose Input/Output）」であり、「ＧＥＴ＿ＧＰＩＯ」の関数を使用する。また、ピンタイプが「ＧＰＩＯ」の場合、「変数」はインタフェースにて用いるピン番号になる。そこで、「ＰＩＮ２７」のピン（ピン番号が２７番のピン）を指定している。また、操作用のインタフェースも「ＧＰＩＯ」であり、「ＳＥＴ＿ＧＰＩＯ」の関数を使用し、「ＰＩＮ２７」のピンを指定している。

ただし、本実施の形態において、利用者入力情報は、図６に示す構成に限られるものではない。例えば、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ−Ｆｉ、Ｚｉｇｂｅｅなどの無線通信規格のモジュールを利用者が選択して、利用者入力情報として入力しても良い。

＜利用者入力情報を入力する際の画面の説明＞
次に、利用者入力情報を入力する際に表示される画面について説明する。図７〜図１１は、利用者入力情報を入力する際に表示される画面の一例を示す図である。ここでは、対象機器が「電動ブラインド・日よけ」という家電の場合について説明する。

まず、利用者が利用者端末１０からファームウェア生成サーバ２０にアクセスすると、ファームウェア生成サーバ２０から画面の情報が送信される。そして、利用者端末１０にて利用者入力情報を入力するための画面が表示される。ここでは、まず、図７（ａ）に示す画面が表示される。図示のように、「センサ関連機器」、「空調関連機器」、「住宅・設備関連機器」など、機器のグループが一覧で示される。これらのグループについては、ＥＣＨＯＮＥＴ Ｌｉｔｅで規定されている。

次に、利用者が例えば「住宅・設備関連機器」のボタン１Ａを選択すると、図７（ｂ）に示す画面が表示される。ここでは、「電動ブラインド・日よけ」、「電動シャッター」、「電動雨戸・シャッター」など、「住宅・設備関連機器」のグループに含まれる機器が一覧で示される。各グループにどのような機器が分類されるかについては、ＥＣＨＯＮＥＴ Ｌｉｔｅで規定されている。利用者は、この一覧の中から「電動ブラインド・日よけ」のボタン１Ｂを選択すれば良い。なお、ここで選択される「電動ブラインド・日よけ」の情報は、図６に示す利用者入力情報の中の「機器種別」に対応する情報である。

利用者が「電動ブラインド・日よけ」を選択すると、次に、図７（ｃ）に示す画面が表示される。この画面は、対象機器（ここでは、電動ブラインド・日よけ）の情報（デバイス情報）の入力を受け付ける画面である。入力される情報は、「メーカーコード」、「事業場コード」、「商品コード」、「製造番号」、「製造年月日」である。「メーカーコード」は、対象機器のメーカーコードであり、エコーネットコンソーシアムより付与される。「事業場コード」は、各メーカーの事業場のコードであり、メーカー毎に規定されている。「商品コード」は、商品毎（機器毎）のコードであり、メーカー毎に規定されている。「製造番号」は、各商品（各機器）に付与される製造番号であり、メーカー毎に規定されている。「製造年月日」は、対象機器を製造した日付であり、メーカー毎に規定されている。なお、ここで選択される情報については図６の例には示していないが、これらの情報も、利用者入力情報としてファームウェア生成サーバ２０に送信される。

利用者がこれらの情報を入力すると、次に、図８（ａ）に示す画面が表示される。ここでは、オプションとして選択可能な必須項目（以下、オプション必須と称する）が示される。このオプション必須は、機器の種別（例えば、電動ブラインド・日よけ）毎にＥＣＨＯＮＥＴ Ｌｉｔｅで規定されている項目である。図示の例では「エネルギー」、「快適生活支援」という２つのオプション必須が示されている。例えば、利用者が「エネルギー」の項目１Ｃを選択すると、以降の設定において、エネルギーの消費を抑制する機能を制御するための設定が行われる。

利用者がオプション必須の選択可否を入力すると、次に、図８（ｂ）に示す画面が表示される。ここでは、対象機器に対する操作項目が一覧で示される。言い換えると、対象機器において制御しようとする機能として選択可能な機能が、操作項目として一覧で示される。利用者は、この一覧の中から、対象機器において制御しようとする機能を選択（チェック）すれば良い。

ここで、操作項目によっては、すでに選択済み（チェック済み）で変更できないようになっている項目（以下、必須項目と称する）も存在する。図示の例では、「動作状態」、「異常発生状態」、「開閉動作設定」が必須項目であり、選択済みになっている。この必須項目についても、機器の種別（例えば、電動ブラインド・日よけ）毎にＥＣＨＯＮＥＴ Ｌｉｔｅで規定されている。即ち、例えば「電動ブラインド・日よけ」については、「動作状態」、「異常発生状態」、「開閉動作設定」の機能が必須であることがＥＣＨＯＮＥＴ Ｌｉｔｅで規定されているといえる。なお、ここで選択される「動作状態」、「異常発生状態」、「開閉動作設定」などの操作項目の情報は、図６に示す利用者入力情報の中の「機能種別」に対応する情報である。

利用者が操作項目を選択すると、次に、図８（ｃ）に示す画面が表示される。この画面は、操作項目毎に、「取得」、「操作」、「状態変更時通知」を実装するか否か（実装又は未実装）を選択する画面である。ここで、「取得」、「操作」、「状態変更時通知」を実装するか否かの情報は、図６に示す利用者入力情報の中の「命令種別」に対応する情報である。即ち、「取得」は、単機能照明から情報を取得する命令を示す。「操作」は、単機能照明を操作する命令を示す。なお、「状態変更時通知」は、対象機器が自機の状態変更を通知する命令を示す。この命令は、対象機器の状態が変化した場合に、状態が変更したことを対象機器から自発的に外部の機器に通知するための命令である。

そして、画面上では、各操作項目の「取得」、「操作」、「状態変更時通知」に設けられた円の図形を左右に移動させることにより、実装するか否かの選択が行われる。例えば、「動作状態」の「取得」では、円の図形１Ｄが右に移動した状態にあり、「実装」が選択されている。一方、「動作状態」の「操作」では、円の図形１Ｅが左に移動した状態にあり、「未実装」が選択されている。ここで、利用者が「実装」を選択する場合には、円の図形１Ｅを図中右方向に移動させれば良い。

なお、ＥＣＨＯＮＥＴ Ｌｉｔｅの規定により、「実装」、「未実装」の設定が固定で決まっており、変更できない項目も存在する。図示の例では、「動作状態」の「取得」、「状態変更時通知」では、円の図形を移動させることはできず、「実装」で固定されている。同様に、「異常発生状態」の「取得」、「状態変更時通知」は「実装」で固定されており、「操作」は「未実装」で固定されている。さらに、「開閉動作設定」の「取得」、「操作」、「状態変更時通知」は「実装」で固定されている。付言すると、利用者が、例えば、「動作状態」の「取得」の項目にある図形１Ｄを選択すると、図９（ａ）に示す画面が表示される。図９（ａ）の画面では、「実装」、「未実装」の設定変更が禁止されている旨のメッセージが示されている。

そして、利用者が各操作項目の「取得」、「操作」、「状態変更時通知」について「実装」、「未実装」の選択を完了すると、次に、図９（ｂ）に示す画面が表示される。この画面は、「実装」が選択された操作項目についての設定を行う画面である。図８（ｃ）に示す例では、「動作状態」の「取得」および「状態変更時通知」、「異常発生状態」の「取得」および「状態変更時通知」、「開閉動作設定」の「取得」、「操作」および「状態変更時通知」、の合計７つの操作項目で「実装」が選択されている。そこで、図９（ｂ）に示す画面上では、これらの７つの項目についての設定が行われる。

例えば、「動作状態」の「取得」について設定を行う場合、利用者が図９（ｂ）に示す設定ボタン１Ｆを選択すると、図１０−１（ａ）に示す画面が表示される。ここでは、「ピンタイプ」、「関数（処理関数）」、「変数」の設定が行われる。ここで設定される「ピンタイプ」、「関数」、「変数」の情報は、図６に示す利用者入力情報の中の「インタフェース種別」の各項目に対応する情報である。

そして、図１０−１（ｂ）に示すように、ピンタイプとしては、例えば、「未接続」、「ＧＰＩＯ」、「ＳＰＩ（Serial Peripheral Interface）」、「Ｉ２Ｃ（Inter-Integrated Circuit）」、「ＩＲ（Infrared）」が候補として表示され、利用者は表示された候補の中から使用するピンタイプを選択すれば良い。また、図１０−２（ｃ）に示すように、関数についても１又は複数の候補が表示され、利用者は表示された候補の中から使用する関数を選択すれば良い。さらに、図１０−２（ｄ）に示すように、変数についても１又は複数の候補が表示される。図示の例では、変数としてピン番号の候補が示されている。例えば、ピン番号の２７番を選択する場合、利用者は「ＰＩＮ２７」を選択すれば良い。最終的には、図１０−２（ｅ）に示すように、選択した各項目の内容が表示される。利用者は、表示された内容で問題なければ「完了」のボタン１Ｇを選択する。このようにして、「動作状態」の「取得」についての設定が行われる。

同様に、「異常発生状態」の「取得」、「開閉動作設定」の「取得」および「操作」についても、「ピンタイプ」、「関数」、「変数」の設定が行われる。
また、「状態変更時通知」については、対象機器が自機の状態の変更有無を確認する間隔（ポーリング間隔）の設定が行われる。このポーリング間隔の設定により、対象機器は、ポーリング間隔毎に自機の状態の変更有無を確認し、状態変更がある場合には外部の機器へ通知するように制御される。図１１（ａ）に示す例では、利用者の入力によりポーリング間隔が１００ミリ秒として設定されている。
そして、利用者は、全ての操作項目（ここでは、７つの操作項目）の設定を行った後、「ＦＩＮＩＳＨ」のボタン１Ｈを選択すると、利用者入力情報の入力が完了し、図１１（ｂ）に示す画面が表示される。

＜サーバ送信用データの説明＞
次に、図１２を参照しながら、利用者端末１０のデータ変換部１２が生成するサーバ送信用データについて説明する。ここでは、データ変換部１２が、図６に示す利用者入力情報を変換して、サーバ送信用データを生成するものとして説明する。

図１２は、利用者入力情報の変換に用いられるキーの一例を示す図である。このようなキーは、ＥＣＨＯＮＥＴ Ｌｉｔｅにて規定されている。また、本実施の形態において独自に規定したキーも存在する。図１２に示すキーのうち、「０ｘ０２０１」、「０ｘ０００１」のキーは、本実施の形態において独自に規定したキーであり、その他のキーはＥＣＨＯＮＥＴ Ｌｉｔｅにて規定されたものである。

より具体的には、「０ｘ０２」のキーは、「単機能照明」のｃｌａｓｓ＿ｇｒｏｕｐコードを意味し、「単機能照明」が属しているグループである「住宅・設備関連機器」のキーを示す。「０ｘ９１」のキーは、「単機能照明」のｃｌａｓｓコードを意味し、「単機能照明」のキーを示す。「０ｘ０１」のキーは、「単機能照明」のｉｎｓｔａｎｃｅコードを意味し、対象機器を一意に識別するために付与されるキーである。ｉｎｓｔａｎｃｅコードが付与されることにより、１つのファームウェアで複数の対象機器の通信機能を制御する場合であっても、ファームウェアにてそれぞれの対象機器を識別できるようになる。

また、「０ｘ８０」のキーは、「単機能照明」のｐｒｏｐｅｒｔｙコードを意味し、「単機能照明」の機能種別である「動作状態」を意味するキーである。「ｇｅｔ」のキーは、命令種別である「取得」を意味するキーである。「ｓｅｔ」のキーは、命令種別である「操作」を意味するキーである。「０ｘ０２０１」のキーは、ＧＰＩＯで用いられる取得用のＩ／Ｏ関数のコードを意味するキーである。「０ｘ０００１」のキーは、ＧＰＩＯで用いられる操作用のＩ／Ｏ関数のコードを意味するキーである。「２７」は、インタフェースで用いられるピン番号を意味するキーである。「ＧＰＩＯ」は、インタフェースで用いられるピンの入出力（ＧＰＩＯ）を意味するキーである。

そして、サーバ送信用データは、図１２に示すキーを用いて、図６に示す利用者入力情報を変換することにより生成される。
より具体的には、例えば、サーバ送信用データには、「住宅・設備関連機器」、「単機能照明」のキーである「０ｘ０２」、「０ｘ９１」のキーの情報が含まれている。これは、図６に示す利用者入力情報の「機器種別」の「単機能照明」の情報に対応する。また、例えば、ＧＰＩＯで用いられる取得用のＩ／Ｏ関数のキーである「０ｘ０２０１」のキーの情報が含まれている。さらに、例えば、ＧＰＩＯで用いられる操作用のＩ／Ｏ関数のキーである「０ｘ０００１」のキーの情報が含まれている。これらは、図６の利用者入力情報の「Ｉ／Ｏ関数」の「ＧＥＴ＿ＧＰＩＯ」、「ＳＥＴ＿ＧＰＩＯ」の情報に対応する。その他、サーバ送信用データには、図１２に示す「０ｘ０１」、「０ｘ８０」、「ｇｅｔ」、「ｓｅｔ」、「２７」、「ＧＰＩＯ」のキーの情報が含まれている。

このようにして、データ変換部１２は、キーを用いて利用者入力情報を変換し、サーバ送信用データを生成する。なお、図１２に示すような各種のキーの一覧は、例えば、利用者端末１０が利用者入力情報を入力するための画面を読み込む際に、ファームウェア生成サーバ２０から利用者端末１０へ送信される。

＜ソースコード生成部による処理の説明＞
次に、図１３（ａ）、（ｂ）を参照しながら、ソースコード生成部２２による処理について説明する。ここでは、ソースコード生成部２２が、図１２に示すキーを基に生成されるサーバ送信用データからソースコード（データ部）を生成するものとして説明する。

図１３（ａ）は、サーバ送信用データに適用されるソースコード生成用フォーマットの一例を示す図である。このソースコード生成用フォーマットは、ＥＣＨＯＮＥＴ Ｌｉｔｅで規定されているものではなく、本実施の形態において独自に規定したものである。

ここで、「機器種別」は、対象機器を識別するための情報を含むフォーマットである。「命令種別」は、命令の種別を識別するための情報を含むフォーマットである。「機能種別」は、対象機器において制御しようとする機能の種別を識別するための情報を含むフォーマットである。「データ種別」は、データ形式を識別するための情報を含むフォーマットである。ここで、データ形式とは、例えば、データの型、データが取り得る値の範囲などであり、ＥＣＨＯＮＥＴ Ｌｉｔｅで規定されているものもあれば、利用者が独自に定めたものもあるものとする。「インタフェース種別」は、対象機器との間でデータを送受信する際のインタフェースに関する情報を含むフォーマットである。

また、図１３（ｂ）は、ソースコード（データ部）の一例を示す図である。図１３（ｂ）に示すソースコード（データ部）は、図１２に示すキーを基に生成されるサーバ送信用データに、図１３（ａ）のソースコード生成用フォーマットを適用することにより生成される。

より具体的には、例えば、図１３（ａ）のフォーマット「機器種別」には、対象機器を識別するための情報として、「ｃｌａｓｓ＿ｇｒｏｕｐ」、「ｃｌａｓｓ」、「ｉｎｓｔａｎｃｅ」のコードが定められている。また、図１２に示すキーを基に生成されるサーバ送信用データには、「ｃｌａｓｓ＿ｇｒｏｕｐ」として「０ｘ０２」、「ｃｌａｓｓ」として「単機能照明」のｃｌａｓｓコードである「０ｘ９１」、「ｉｎｓｔａｎｃｅ」として「０ｘ０１」が含まれている。そこで、「機器種別」のフォーマットの「ｃｌａｓｓ＿ｇｒｏｕｐ」、「ｃｌａｓｓ」、「ｉｎｓｔａｎｃｅ」を、「０ｘ０２」、「０ｘ９１」、「０ｘ０１」で置換する。このようにして、図１３（ｂ）に示すソースコード（データ部）のデータａ１のコードが生成される。

同様に、「命令種別」、「機能種別」、「データ種別」、「インタフェース種別」の各フォーマットについて、サーバ送信用データの該当コードで置換することにより、ソースコード（データ部）が生成される。ここで、「命令種別」のフォーマットを置換することにより、図１３（ｂ）に示すデータａ２のコードが生成される。「機能種別」のフォーマットを置換することにより、図１３（ｂ）に示すデータａ３のコードが生成される。「データ種別」のフォーマットを置換することにより、図１３（ｂ）に示すデータａ４のコードが生成される。「インタフェース種別」のフォーマットを置換することにより、図１３（ｂ）に示すデータａ５のコードが生成される。

なお、ソースコード生成用フォーマットの各フォーマットでは、フォーマット間で関係のある情報同士が対応付けられている。そのため、各フォーマットから生成されるソースコード（データ部）のデータ（図示の例ではデータａ１〜データａ５）についても、データ間で関係のある情報同士が対応付けられている。
例えば、ソースコード（データ部）のデータａ１には、１又は複数の対象機器の情報が記述される。ここで、ソースコード（データ部）のデータａ２には命令種別の情報が記述されるが、データａ１に記述されたどの対象機器の命令種別かがわかるように、対象機器と命令種別とを対応付けて記述される。さらに、ソースコード（データ部）のデータａ３には機能の情報が記述されるが、どの対象機器のどの命令種別を使用する機能かがわかるように、データａ１の対象機器及びデータａ２の命令種別と対応付けて、機能の情報が記述される。同様に、データａ４、データａ５でも、データ間で関係のある情報同士が対応付けられる。

また、ここでは、ソースコード生成用フォーマットとして、「機器種別」、「命令種別」、「機能種別」、「データ種別」、「インタフェース種別」の５つのフォーマットについて説明した。このうち、「機器種別」、「命令種別」、「機能種別」、「データ種別」の４つのフォーマットは、サーバ送信用データの内容によらず共通に用いられる。一方、「インタフェース種別」は、使用するインタフェースに応じたフォーマットが用いられる。例えば、「ＧＰＩＯ」のインタフェースが使用される場合には、「ＧＰＩＯ」用のフォーマットが用いられる。また、例えば、「ＳＰＩ」のインタフェースが使用される場合には、「ＳＰＩ」用のフォーマットが用いられる。

このようにして、ソースコード生成部２２は、サーバ送信用データに対してソースコード生成用フォーマットを適用して、ソースコード（データ部）を生成する。付言すると、ソースコード（データ部）は、対象機器の種類および特定の機能をソースコード生成用フォーマットに則って記述されたコードであると捉えることができる。また、本実施の形態において、対象機器において制御しようとする機能は、特定の機能の一例として用いられる。

＜ファームウェア生成部による処理の説明＞
次に、図１４（ａ），（ｂ）を参照しながら、ファームウェア生成部２３による処理について説明する。図１４（ａ），（ｂ）は、ファームウェア生成部２３により生成されるファームウェアのコードの一例を示す概念図である。

図１４（ａ）に示すソースコード（データ部）は、利用者が入力した利用者入力情報に応じて、ソースコード生成部２２により生成されたものである。図示の例は、サーバ送信用データを「機器種別」のソースコード生成用フォーマットに適用して生成されたソースコード（データ部）を示している。より具体的には、利用者が、対象機器としてエアコンおよび冷蔵庫を選択した場合を示している。

また、図１４（ａ）に示すソースコード（手続き部）は、ソースコード格納部２５に格納されているものであり、利用者入力情報によらず一定である。図示の例では、「機器種別」に対応したソースコード（手続き部）を示しており、利用者がどのような機器を対象機器として選択したとしても対応できるように、予め定められている。例えば、図示のソースコード（手続き部）の３行目「全機器共通手続き（受信データ）」は、ファームウェアが外部からデータを受信した場合に、その受信データに基づいてどのような種類の家電についても実行できるように記述されたコードである。

また、図１４（ｂ）に示すソースコード（データ部）も、利用者が入力した利用者入力情報に応じて、ソースコード生成部２２により生成されたものである。図示の例は、サーバ送信用データを「機能種別」のソースコード生成用フォーマットに適用して生成されたソースコード（データ部）を示している。より具体的には、利用者が、エアコンにて制御しようとする機能として、「温度自動」、「冷房モード」、「消費電力」を選択し、冷蔵庫にて制御しようとする機能として、「ドア開閉」、「急速冷蔵」、「消費電力」を選択した場合を示している。

また、図１４（ｂ）に示すソースコード（手続き部）も、ソースコード格納部２５に格納されているものであり、利用者入力情報によらず一定である。図示の例では、「機能種別」に対応したソースコード（手続き部）を示しており、利用者がどのような機器を対象機器として選択し、対象機器において制御しようとする機能としてどのような機能を選択したとしても対応できるように、予め定められている。例えば、図示のソースコード（手続き部）の３行目「全機能共通手続き（受信データ）」は、ファームウェアが外部からデータを受信した場合に、その受信データに基づいてどのような家電の機能についても実行できるように記述されたコードである。

このように、ソースコード（データ部）は、各ソースコード生成用フォーマットに応じて生成され、それと対応するソースコード（手続き部）が予め定められている。図１４（ａ）に示すソースコードは、「機器種別」に対応するソースコード（データ部）およびソースコード（手続き部）であり、図１４（ｂ）に示すソースコードは、「機能種別」に対応するソースコード（データ部）およびソースコード（手続き部）である。また、図１４には示していないが、「命令種別」に対応するソースコード（データ部）およびソースコード（手続き部）、「データ種別」に対応するソースコード（データ部）およびソースコード（手続き部）、「インタフェース種別」に対応するソースコード（データ部）およびソースコード（手続き部）なども存在する。そして、ファームウェア生成部２３は、これらの各フォーマットに対応するソースコード（データ部）とソースコード（手続き部）とを全て足し合わせる（結合する）ことにより、ファームウェアのソースコードを生成する。付言すると、ファームウェアのソースコードは、ソースコード（データ部）とソースコード（手続き部）とが分離して記述されたコードであると捉えることができる。

次に、ファームウェア生成部２３により生成されたファームウェアが実際に動作する場合の処理について説明する。ここでは、一例として、利用者が、エアコンを操作する入力を行い、そのデータ（以下、受信データＡと称することとする）をファームウェアが受信したものとして説明する。

ファームウェアの処理としては、「機器種別」、「命令種別」、「機能種別」、「データ種別」、「インタフェース種別」に対応するそれぞれのソースコード（手続き部）の処理が順番に実行される。
初めに、「機器種別」に対応するソースコード（手続き部）の処理が実行される。その際、「機器種別」に対応するソースコード（データ部）が参照される。ここでは、受信データＡで対象機器として指定されたエアコンが、ソースコード（データ部）に記述されているか否かの検査（判定）などが行われる。図１４（ａ）に示す例では、エアコンはソースコード（データ部）に記述されているため、次の処理に進む。一方、受信データＡで操作対象として指定された機器がソースコード（データ部）に記述されていない場合には、例えばファームウェアからエラーが返されて処理が終了する。

次に「命令種別」に対応するソースコード（手続き部）の処理が実行される。その際、「命令種別」に対応するソースコード（データ部）が参照される。ここでは、受信データＡで指定された命令種別（即ち、エアコンの命令種別）が、ソースコード（データ部）に記述されているか否かの検査などが行われる。また、上述したように、ソースコード（データ部）では、関係のある情報同士が対応付けられている。即ち、ソースコード（データ部）には、各家電と命令種別とが対応付けて記述されている。そのため、ここでは、ソースコード（データ部）の中で、エアコンの命令種別が記述された箇所を参照して、検査を行えば良い。なお、「機器種別」に対応するソースコード（手続き部）からは、ソースコード（データ部）の中でエアコンの命令種別が記述された箇所を参照するように指示される。そのため、「命令種別」に対応するソースコード（手続き部）の処理では、該当箇所を参照することができる。

次に「機能種別」に対応するソースコード（手続き部）の処理が実行される。その際、「機能種別」に対応するソースコード（データ部）が参照される。ここでは、受信データＡで指定された機能（即ち、エアコンの機能）が、ソースコード（データ部）に記述されているか否かの検査などが行われる。上述したように、機能に関しても、各家電及び命令種別の情報と対応付けて記述されている。そのため、ここでは、ソースコード（データ部）の中で、エアコン（及び命令種別）に対応する機能が記述された箇所を参照して、検査を行えば良い。なお、「命令種別」に対応するソースコード（手続き部）からは、ソースコード（データ部）の中でエアコン（及び命令種別）に対応する機能が記述された箇所を参照するように指示される。そのため、「機能種別」に対応するソースコード（手続き部）の処理では、該当箇所を参照することができる。

例えば、図１４（ｂ）に示す例の場合、受信データＡで指定されたエアコンの機能が、「温度自動」、「冷房モード」、「消費電力」の何れかに該当するか順番にチェックする。ここで、受信データＡの機能がどの機能にも該当しなければ、エラーとなり処理は終了する。一方、受信データＡの機能が、例えば「温度自動」の機能に該当する場合、次の「データ種別」、「インタフェース種別」の処理に進む。

同様に、「データ種別」に対応するソースコード（手続き部）の処理が実行される際には、「データ種別」に対応するソースコード（データ部）が参照される。ここでは、受信データＡが、ソースコード（データ部）に記述されたデータ形式を満たすか否かの検査などが行われる。さらに、「インタフェース種別」に対応するソースコード（手続き部）の処理が実行される際には、「インタフェース種別」に対応するソースコード（データ部）が参照される。ここでは、受信データＡで指定されたデータ送受信の方法が、ソースコード（データ部）に記述されているか否かの検査などが行われる。受信データＡで指定されたデータ送受信の方法がソースコード（データ部）に記述されていれば、その送受信の方法で、エアコンに対してデータの送受信が開始される。

＜ファームウェア生成システム全体の処理の流れ＞
次に、ファームウェア生成システム１全体の処理の流れについて説明する。図１５は、ファームウェア生成システム１においてファームウェアを生成する処理手順の一例を示したフローチャートである。ここで、ステップ１０１〜ステップ１０３の処理は、利用者端末１０による処理に該当する。また、ステップ１０４〜ステップ１０６の処理は、ファームウェア生成サーバ２０の処理に該当する。

まず、利用者が利用者端末１０の画面上で利用者入力情報を入力することにより、入力情報受付部１１は、利用者入力情報を受け付ける（ステップ１０１）。次に、データ変換部１２は、受け付けた利用者入力情報に対応するキーを用いて、利用者入力情報を変換してサーバ送信用データを生成する（ステップ１０２）。次に、データ送信部１３は、生成されたサーバ送信用データをファームウェア生成サーバ２０へ送信する（ステップ１０３）。

次に、データ受付部２１は、利用者端末１０からサーバ送信用データを受け付ける（ステップ１０４）。次に、ソースコード生成部２２は、フォーマット格納部２４に格納されているソースコード生成用フォーマットを取得する。そして、ソースコード生成部２２は、取得したソースコード生成用フォーマットを用いて、利用者端末１０から受け付けたサーバ送信用データを変換してソースコード（データ部）を生成する（ステップ１０５）。次に、ファームウェア生成部２３は、ソースコード格納部２５からソースコード（手続き部）を取得する。そして、ファームウェア生成部２３は、取得したソースコード（手続き部）と、生成されたソースコード（データ部）とを足し合わせて、ファームウェアを生成する（ステップ１０６）。そして、本処理フローは終了する。

また、ファームウェアが生成された後には、例えば、利用者が利用者端末１０にてファームウェアを取得する操作を行うことにより、生成されたファームウェアがファームウェア生成サーバ２０から利用者端末１０へ送信される。利用者は、送信されてきたファームウェアを、例えば通信制御基板にインストールし、その通信制御基板を対象機器に搭載することにより、対象機器の通信機能が制御される。ただし、通信制御基板を対象機器に搭載する構成に限られるものではなく、例えば、対象機器を制御する他の制御装置に通信制御基板を搭載して、この制御装置がファームウェアにより対象機器の通信機能を制御することとしても良い。

なお、本実施の形態では、対象機器に、対象機器の各種の機能を制御する制御装置等が備えられているものとして説明したが、対象機器の中には、例えばＬＥＤ(Light Emitting Diode)照明のように制御装置等を備えていない単純な構成のものも存在する。このような単純な構成の対象機器の場合、ファームウェアは、例えば、利用者端末１０から受信した命令に従って、対象機器の動作を制御する。即ち、この場合、ファームウェアは、対象機器の通信機能を制御するとともに、対象機器の動作を制御するものとして捉えることができる。

以上説明したように、本実施の形態に係るファームウェア生成システム１では、利用者が操作したい機器の種類や機能等を画面上で選択することにより、選択された機器や機能に対応したファームウェアが生成される。その際、ファームウェア生成サーバ２０のファームウェア生成部２３は、利用者入力情報に応じて生成されたソースコード（データ部）と、予め定められたソースコード（手続き部）とを足し合わせることにより、ファームウェアを生成する。

また、例えば、ＥＣＨＯＮＥＴ Ｌｉｔｅの規定により、対象機器の候補として新しい機器が追加されたり、対象機器において制御しようとする機能として新しい機能が追加されたりした場合、図１２に示すキーのｃｌａｓｓコードやｐｒｏｐｅｒｔｙコードが追加される。しかし、ソースコード生成用フォーマットおよびソースコード（手続き部）は変更しなくて良く、そのままのものを用いれば良い。即ち、新しい機器や機能に対応するファームウェアを生成する場合であっても、ソースコード生成部２２は、ソースコード生成用フォーマットを用いて、利用者が画面上で選択した機器や機能に対応したソースコード（データ部）を生成する。そして、ファームウェア生成部２３は、生成されたソースコード（データ部）とソースコード（手続き部）とを足し合わせることにより、ファームウェアを生成する。

なお、本実施の形態では、利用者端末１０がサーバ送信用データをファームウェア生成サーバ２０へ送信し、ファームウェア生成サーバ２０がファームウェアを生成する構成としたが、このような構成に限られるものではない。例えば、利用者端末１０が、ファームウェア生成サーバ２０の機能を有し、利用者端末１０にてファームウェアを生成するような構成であっても良い。言い換えると、利用者端末１０が、ファームウェア生成サーバ２０のデータ受付部２１、ソースコード生成部２２、ファームウェア生成部２３、フォーマット格納部２４、ソースコード格納部２５等の機能を備えることとしても良い。この場合、利用者端末１０は、情報処理装置の一例として捉えることができる。

また、本発明の実施の形態を実現するプログラムは、磁気記録媒体（磁気テープ、磁気ディスクなど）、光記録媒体（光ディスクなど）、光磁気記録媒体、半導体メモリなどのコンピュータが読取可能な記録媒体に記憶した状態で提供し得る。また、インターネットなどの通信手段を用いて提供することも可能である。

以上、本発明の実施の形態について説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。

１…ファームウェア生成システム、１０…利用者端末、１１…入力情報受付部、１２…データ変換部、１３…データ送信部、２０…ファームウェア生成サーバ、２１…データ受付部、２２…ソースコード生成部、２３…ファームウェア生成部、２４…フォーマット格納部、２５…ソースコード格納部

Claims (6)

1. 制御対象機器の情報を受け付けて当該制御対象機器の通信機能を制御するためのソフトウェアを生成するサーバと、
   前記制御対象機器の情報を前記サーバに送信する端末装置と、を備え、
   前記サーバは、
   前記端末装置から送信された前記制御対象機器の情報を、制御対象機器の通信機能を制御するためのデータの型と当該データが取り得る値の範囲とを指定した予め定められた第１のコードのフォーマットに適用して第１のコードを生成するコード生成部と、
   前記コード生成部により生成された前記第１のコードおよび予め用意された第２のコードに基づいて、前記制御対象機器の通信機能を制御するソフトウェアを生成するソフトウェア生成部と、を備え、
   前記制御対象機器の情報は、当該制御対象機器の種類および特定の機能の情報を含み、
   前記第２のコードは、前記第１のコードを参照して前記制御対象機器に前記特定の機能を実行させる手続きが記述された、記述内容が当該制御対象機器の種類および当該制御対象機器の機能によらない固定的なコードであって、当該手続きは、当該制御対象機器の通信機能を制御するものとして受信したデータが前記型と前記範囲とを満たすか否かを検査する処理を含むことを特徴とする、ソフトウェア生成システム。
2. 前記端末装置は、
   前記制御対象機器に関して前記ソフトウェアを生成するために特定を要する項目をメニュー表示する表示手段と、
   前記表示手段により表示されたメニューに基づき、前記項目を選択することにより前記制御対象機器の情報を入力する操作を受け付ける操作受け付け手段と、
   を備えることを特徴とする、請求項１に記載のソフトウェア生成システム。
3. 前記制御対象機器の情報は、前記項目に応じた複数の種別に分類され、
   前記第１のコードは、前記複数の種別の種別毎に予め定められた前記第１のコードのフォーマットに則って、当該複数の種別の種別毎に記述され、
   前記第２のコードは、前記複数の種別の種別毎に記述されたコードであって、
   前記ソフトウェア生成部は、前記コード生成部により生成された前記第１のコードと前記第２のコードとを前記複数の種別の種別毎に対応させて前記ソフトウェアを生成することを特徴とする、請求項２に記載のソフトウェア生成システム。
4. 制御対象機器の情報を受け付ける受付部と、
   制御対象機器の通信機能を制御するためのデータの型と当該データが取り得る値の範囲とを指定した予め定められた第１のコードのフォーマットを格納したフォーマット格納部と、
   予め定められた第２のコードを格納したコード格納部と、
   前記受付部により受け付けた前記制御対象機器の情報を前記フォーマット格納部に格納された前記第１のコードのフォーマットに適用して第１のコードを生成するコード生成部と、
   前記コード生成部により生成された前記第１のコードおよび前記コード格納部から読み出した前記第２のコードに基づいて、前記制御対象機器の通信機能を制御するソフトウェアを生成するソフトウェア生成部と、を備え、
   前記制御対象機器の情報は、当該制御対象機器の種類および特定の機能の情報を含み、
   前記コード格納部に格納された前記第２のコードは、前記第１のコードを参照して前記制御対象機器に前記特定の機能を実行させる手続きが記述された、記述内容が当該制御対象機器の種類および当該制御対象機器の機能によらない固定的なコードであって、当該手続きは、当該制御対象機器の通信機能を制御するものとして受信したデータが前記型と前記範囲とを満たすか否かを検査する処理を含むことを特徴とする、情報処理装置。
5. 前記コード格納部に格納された前記第２のコードは、前記制御対象機器の通信機能を制御し、当該制御対象機器の機能を実現する機能実現手段のうち、前記第１のコードに記述された機能についての機能実現手段との間で情報交換を行うための手続きが記述されたコードであることを特徴とする、請求項４に記載の情報処理装置。
6. コンピュータを、
   制御対象機器の情報を受け付ける受付手段と、
   記憶装置から、制御対象機器の通信機能を制御するためのデータの型と当該データが取り得る値の範囲とを指定した予め定められた第１のコードのフォーマットを読み出し、前記受付手段により受け付けた前記制御対象機器の情報を当該第１のコードのフォーマットに適用して第１のコードを生成するコード生成手段と、
   記憶装置から予め定められた第２のコードを読み出し、当該第２のコードおよび前記コード生成手段により生成された前記第１のコードに基づいて、前記制御対象機器の通信機能を制御するソフトウェアを生成するソフトウェア生成手段として、機能させ、
   前記制御対象機器の情報は、当該制御対象機器の種類および特定の機能の情報を含み、
   記憶装置に記憶された前記第２のコードは、前記第１のコードを参照して前記制御対象機器に前記特定の機能を実行させる手続きが記述された、記述内容が当該制御対象機器の種類および当該制御対象機器の機能によらない固定的なコードであって、当該手続きは、当該制御対象機器の通信機能を制御するものとして受信したデータが前記型と前記範囲とを満たすか否かを検査する処理を含むことを特徴とする、プログラム。

Images