(58)【調査した分野】(Int.Cl.,DB名)
前記第2画面を表示するステップは、当該第2画面として、前記操作の種類を示す操作品目が並んだ画面を表示し、当該画面では、当該操作品目のうち、前記制御対象機器に対して前記ソフトウェアへ搭載することが任意な操作品目については第1の態様で表示し、当該制御対象機器に対して当該ソフトウェアへ搭載することが必須な操作品目については第2の態様で表示し、
前記生成指示を行うステップは、前記第1の態様で表示された操作品目についての選択に基づく設定、及び、前記第2の態様で表示された操作品目についての予め定められた設定を基に、当該生成指示を行うこと、
を特徴とする、請求項1に記載のソフトウェアの提供方法。
前記操作の種類を示す操作品目に関して、何れの操作品目にも共通に設けられる複数の設定項目が当該操作品目毎に並べられた画面を表示し、当該画面では、当該設定項目のうち、設定するか否かが任意の設定項目については第1の態様で表示し、設定するか否かが予め定められている設定項目については第2の態様で表示するステップをさらに含み、
前記生成指示を行うステップは、前記第1の態様で表示された設定項目についての選択に基づく設定、及び、前記第2の態様で表示された設定項目についての予め定められた設定を基に、当該生成指示を行うこと、
を特徴とする、請求項1に記載のソフトウェアの提供方法。
前記複数の画面として、前記ソフトウェアにおいて前記制御対象機器の通信機能を制御するために用いられる通信規格の選択を受け付けるための画面を表示するステップをさらに含み、
前記第1画面を表示するステップは、選択された前記通信規格に応じた当該第1画面を表示し、
前記第2画面を表示するステップは、選択された前記通信規格に応じた当該第2画面を表示し、
前記第3画面を表示するステップは、選択された前記通信規格に応じた当該第3画面を表示すること、
を特徴とする、請求項1に記載のソフトウェアの提供方法。
【発明を実施するための形態】
【0010】
以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
<背景>
まず、本実施の形態の背景について説明する。
近年、例えば家電等の電気機器をネットワークに接続し、これらの電気機器を制御するために、ホームネットワーク用の通信規格の業界標準化が進められている。そして、複数のメーカーで共通的に使用される通信規格が作成され、マルチベンダでの相互接続環境が整備されつつある。このような共通の通信規格には、例えばECHONET Lite(登録商標)があり、一般社団法人エコーネットコンソーシアムによって標準化が図られている。このような通信規格を用いることにより、ユーザの操作によって家電等の電気機器を制御することができる。
【0011】
図1は、本実施の形態の背景について説明するための図である。端末装置100は、ユーザが使用する端末であり、例えば、PC(personal computer)や携帯情報端末(いわゆる、スマートフォンやタブレット端末等)などを例示することができる。電気機器200は、制御対象の電気機器であり、例えば、エアコンディショナや照明器具、冷蔵庫などの家電を例示することができる。ネットワーク300は、端末装置100と電気機器200との間の情報通信に用いられる通信手段であり、例えば、インターネットを例示することができる。
【0012】
このような構成において、ユーザが端末装置100を操作することにより、ネットワーク300を介して端末装置100から電気機器200を制御したり、電気機器200から端末装置100へ情報を送信させたりするには、電気機器200に通信機能を持たせ、電気機器200の制御装置やセンサとの間で情報交換を行うことが必要になる。そこで、電気機器200の通信機能を制御して、電気機器200を制御する命令を受け付けたり電気機器200から情報を出力したりさせるためのソフトウェアが用いられる。このようなソフトウェアをインストールした制御部(電子回路基板)の一例としての通信制御基板400を電気機器200に搭載することにより、電気機器200の通信機能の制御が行われる。なお、電気機器200の通信機能の制御については、通信制御基板400を搭載することにより新たに電気機器200に備えられた通信機能を制御する場合もあれば、通信制御基板400の搭載前から電気機器200に備えられている通信機能を制御する場合もあるものとする。
【0013】
さらに説明すると、
図1に示すように、通信制御基板400には、上述したような電気機器200の通信機能を制御するためのソフトウェアである家電制御用ソフトウェアに加えて、通信モジュール制御用ソフトウェアおよび通信モジュールが含まれる。この通信モジュールとしては、例えばBluetooth(登録商標)モジュールを用いることができる。ここで、Bluetoothモジュールは、無線通信規格のモジュールであり、端末装置100のような外部機器と無線通信を行うためのものである。なお、本実施の形態では、Bluetoothモジュールを用いた構成に限られるものではなく、例えば、Wi−Fi(Wireless Fidelity)(登録商標)、Zigbeeなどの他の無線通信規格のモジュールを用いても良い。さらに、無線通信規格のモジュールを用いる構成に限られず、有線の通信規格を備えたモジュールを用いても良い。また、通信モジュール制御用ソフトウェアは、家電制御用ソフトウェアとBluetoothモジュールとの間でデータの送受信を行うためのソフトウェアである。図示の例では、通信モジュール制御用ソフトウェアにおけるプロトコルの一例として、IPv6(Internet Protocol Version 6)、6LoWPAN(IPv6 over Low power Wireless Personal Area Networks)を用いている。なお、通信モジュール制御用ソフトウェアにて用いるプロトコルについても、IPv6、6LoWPAN等のプロトコルに限られるものではなく、家電制御用ソフトウェアがデータの送受信を行うために使用可能なプロトコルであれば、どのようなプロトコルを用いても良い。
【0014】
このように構成された通信制御基板400は、家電制御用ソフトウェアの制御により、端末装置100からの制御信号を受け付けて電気機器200の機能実行手段を制御したり、機能実行手段から取得した情報を端末装置100へ出力したりする。ここで、機能実行手段としては、電気機器200の各種の機能を制御する制御装置、種々の動作を実行するアクチュエータ、電気機器200の動作に関する情報を取得する種々のセンサ等を例示することができる。例えば、電気機器200がエアコンディショナの場合について説明する。エアコンディショナ内には、独自の機能プログラムにより、例えば温度を設定したり風量を設定したりするための制御装置が予め搭載されている。そして、家電制御用ソフトウェアにより制御される通信制御基板400が、端末装置100から受信した温度設定命令や風量設定命令を制御装置に送って温度や風量の設定をさせたり、センサから温度や風量の設定値や測定値を取得して端末装置100へ送信したりすることができるようになる。
【0015】
そして、本実施の形態では、ユーザが画面に従って入力することにより、上述したような電気機器の通信機能を制御するための家電制御用ソフトウェアを生成(提供)するソフトウェア生成システム(ソフトウェアの提供方法)を提供する。また、本実施の形態では、電気機器の通信機能を制御するためのソフトウェアの一例として、電気機器の通信機能を制御するために電気機器に組み込まれるソフトウェアであるファームウェアを例にして説明する。
【0016】
なお、以下では、特に家電を制御するための通信規格であるECHONET Liteを用いて説明するが、このような構成に限られるものではない。本実施の形態に係るファームウェア生成システム1は、ECHONET Lite以外の他の通信規格を用いて、家電を含む種々の電気機器を制御する場合にも適用することができる。また、以下では、ファームウェア生成システム1により生成される家電制御用のファームウェアを、単に「ファームウェア」と称する場合がある。
【0017】
<ファームウェア生成システムの全体構成>
次に、本実施の形態に係るファームウェア生成システム1の全体構成について説明する。
図2は、本実施の形態に係るファームウェア生成システム1の全体構成例を示した図である。図示するように、このファームウェア生成システム1は、利用者端末10とファームウェア生成サーバ20とがネットワーク30を介して接続されることにより構成される。
【0018】
情報処理装置の一例としての利用者端末10は、ファームウェア生成システム1を利用する利用者が操作するコンピュータ装置であり、例えば、PCや携帯情報端末等が例示される。この利用者端末10は、ファームウェアを生成するために利用者が入力した情報(以下、利用者入力情報と称する)を受け付ける。この利用者入力情報には、例えば、ファームウェアがインストールされた通信制御基板400(
図1参照)により実現される通信機能を介して制御しようとする対象の機器(以下、対象機器と称する)の種類を指定する情報や、対象機器における制御しようとする機能を指定する情報が含まれる。そして、利用者端末10は、受け付けた利用者入力情報をファームウェア生成サーバ20にて識別可能(処理可能)な形式へ変換して、ファームウェア生成サーバ20へ送信する。以下では、利用者入力情報に変換を施した変換後のデータを、「サーバ送信用データ」と称する。
【0019】
ファームウェア生成サーバ20は、対象機器の通信機能を制御するためのファームウェアを生成するコンピュータ装置であり、例えば、PC、ワークステーション等が例示される。このファームウェア生成サーバ20は、利用者端末10から受信したサーバ送信用データを基に、ファームウェアを生成する。本実施の形態では、制御対象機器の通信機能を制御するためのソフトウェアを生成する外部装置の一例として、ファームウェア生成サーバ20が用いられる。
【0020】
ネットワーク30は、利用者端末10とファームウェア生成サーバ20との間の情報通信に用いられる通信手段であり、例えば、インターネット、LAN(Local Area Network)等である。
【0021】
<ハードウェア構成>
次に、本実施の形態に係るファームウェア生成サーバ20および利用者端末10のハードウェア構成について説明する。
図3は、本実施の形態に係るファームウェア生成サーバ20又は利用者端末10として用いられるコンピュータのハードウェア構成例を示す図である。
【0022】
図示するように、ファームウェア生成サーバ20又は利用者端末10は、演算手段であるCPU(Central Processing Unit)20aと、主記憶手段であるメモリ20cを備える。また、外部デバイスとして、磁気ディスク装置(HDD:Hard Disk Drive)20g、ネットワークインタフェース20f、ディスプレイ装置を含む表示機構20d、音声機構20h、キーボードやマウス等の入力デバイス20i等を備える。
【0023】
図3に示す構成例では、メモリ20cおよび表示機構20dは、システムコントローラ20bを介してCPU20aに接続されている。また、ネットワークインタフェース20f、磁気ディスク装置20g、音声機構20hおよび入力デバイス20iは、I/Oコントローラ20eを介してシステムコントローラ20bと接続されている。各構成要素は、システム・バスや入出力バス等の各種のバスによって接続される。
【0024】
また、
図3において、磁気ディスク装置20gにはOSのプログラムやアプリケーション・プログラムが格納されている。そして、これらのプログラムがメモリ20cに読み込まれてCPU20aに実行されることにより、ファームウェア生成サーバ20又は利用者端末10の各種機能が実現される。
【0025】
なお、
図3は、本実施の形態が適用されるのに好適なコンピュータのハードウェア構成を例示するに過ぎない。本実施の形態は、ファームウェアを生成する装置に広く適用できるものであり、図示の構成においてのみ本実施の形態が実現されるのではない。
【0026】
<利用者端末の機能構成>
次に、利用者端末10の機能構成について説明する。
図4は、本実施の形態に係る利用者端末10の機能構成例を示したブロック図である。
【0027】
図示するように、利用者端末10は、利用者が入力した利用者入力情報を受け付ける入力情報受付部11と、受け付けた利用者入力情報をサーバ送信用データへ変換するデータ変換部12と、サーバ送信用データをファームウェア生成サーバ20へ送信するデータ送信部13とを備える。
【0028】
入力情報受付部11は、利用者が入力した利用者入力情報を受け付ける。より具体的には、利用者は、例えば利用者端末10の表示機構により表示画面に表示される画面上で、対象機器を選択したり、対象機器において制御しようとする機能を選択したりすることにより、利用者入力情報を入力する。付言すると、対象機器に関してファームウェアを生成するために特定を要する項目がメニュー表示されるため、利用者は、表示されたメニューに基づき項目を選択して情報を入力すれば良い。利用者入力情報、および利用者入力情報を入力する際の画面の詳細については、後述する。本実施の形態では、入力情報受付部11は、表示部、受付部の一例として捉えることもできる。
【0029】
データ変換部12は、入力情報受付部11が受け付けた利用者入力情報を、サーバ送信用データへ変換する。サーバ送信用データの詳細については、後述する。
【0030】
データ送信部13は、データ変換部12により生成されたサーバ送信用データを、ファームウェア生成サーバ20へ送信する。本実施の形態では、データ送信部13は、ソフトウェアを生成する外部装置に対してソフトウェアの生成指示を送信する送信部の一例として捉えることもできる。
【0031】
なお、
図4に示す利用者端末10を構成する各機能部は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、利用者端末10を
図3に示したコンピュータにて実現した場合、例えば、磁気ディスク装置20gに格納されているOSのプログラムやアプリケーション・プログラムが、メモリ20cに読み込まれてCPU20aに実行されることにより、入力情報受付部11、データ変換部12、データ送信部13の各機能が実現される。
【0032】
<ファームウェア生成サーバの機能構成>
次に、ファームウェア生成サーバ20の機能構成について説明する。
図5は、本実施の形態に係るファームウェア生成サーバ20の機能構成例を示したブロック図である。
【0033】
図示するように、ファームウェア生成サーバ20は、主にデータの処理に関わる機能部として、サーバ送信用データを受け付けるデータ受付部21と、サーバ送信用データを基に、後述するソースコード(データ部)を生成するソースコード生成部22と、ソースコード(データ部)と後述するソースコード(手続き部)とを結合してファームウェアを生成するファームウェア生成部23とを備える。また、ファームウェア生成サーバ20は、主にデータの格納に関わる機能部として、後述するソースコード生成用フォーマットを格納するフォーマット格納部24と、ソースコード(手続き部)を格納するソースコード格納部25とを備える。
【0034】
データ受付部21は、利用者端末10からサーバ送信用データを受け付ける。
【0035】
ソースコード生成部22は、フォーマット格納部24から、ソースコード(データ部)を生成するために使用するフォーマット(以下、ソースコード生成用フォーマットと称する)を取得する。そして、ソースコード生成部22は、サーバ送信用データをソースコード生成用フォーマットに適用し、ソースコード生成用フォーマットに適合するようにサーバ送信用データを変換して、ソースコード(データ部)を生成する。ソースコード生成部22がソースコード(データ部)を生成する処理の詳細については、後述する。
【0036】
ファームウェア生成部23は、ソースコード格納部25から、予め定められたコードであるソースコード(手続き部)を取得する。このソースコード(手続き部)は、ソースコード(データ部)を参照して実行する手続きが記述されたコードである。さらに説明すると、このソースコード(手続き部)は、ソースコード(データ部)に記述された対象機器の機能を実現する機能実現手段との間で情報交換を行うための手続きが記述されたコードである。
【0037】
そして、ファームウェア生成部23は、取得したソースコード(手続き部)と、ソースコード生成部22により生成されたソースコード(データ部)とを結合して、ファームウェアのソースコードを生成する。また、ファームウェア生成部23は、生成したソースコードをコンパイルして、ファームウェアを生成する。そして、ファームウェア生成部23は、生成したファームウェアを利用者端末10へ送信する。
【0038】
付言すると、ソースコード生成部22が生成するソースコード(データ部)は、利用者が入力した利用者入力情報に応じて内容が変わる。一方で、ソースコード(手続き部)は、利用者が入力した利用者入力情報によらず一定である。言い換えると、ソースコード(手続き部)は、その記述内容が対象機器の種類および対象機器の機能によらない固定的なコードである。即ち、ソースコード(手続き部)は、ソースコード(データ部)がどのような内容であっても対応できるように、予め定められている。ソースコード(手続き部)の詳細については、後述する。
【0039】
フォーマット格納部24は、ソースコード生成用フォーマットを格納する。
【0040】
ソースコード格納部25は、ソースコード(手続き部)を格納する。
【0041】
なお、
図5に示すファームウェア生成サーバ20を構成する各機能部は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、ファームウェア生成サーバ20を
図3に示したコンピュータにて実現した場合、磁気ディスク装置20gに格納されているOSのプログラムやアプリケーション・プログラムが、メモリ20cに読み込まれてCPU20aに実行されることにより、データ受付部21、ソースコード生成部22、ファームウェア生成部23の各機能が実現される。また、フォーマット格納部24、ソースコード格納部25は、メモリ20cや磁気ディスク装置20g等の記憶手段により実現される。
【0042】
<利用者入力情報の説明>
次に、利用者が画面上で入力する利用者入力情報について説明する。
図6は、利用者入力情報の一例を示す図である。図示の例は、対象機器が「単機能照明」の場合の利用者入力情報である。「単機能照明」とは、電源のON・OFF設定や照度レベル設定等の単純な機能しか持たない照明機器である。
【0043】
より具体的には、「機器種別」は、対象機器の種別を示す。図示の例では「単機能照明」を示している。「機能種別」は、対象機器において制御しようとする機能の種別を示す。図示の例では「動作状態」の機能を示している。「動作状態」とは、電源のON・OFF設定の機能である。「命令種別」は、該当機能において使用する命令の種別を示す。図示の例では、「動作状態」の機能において、取得命令(即ち、単機能照明から情報を取得する命令)、操作命令(即ち、単機能照明を操作する命令)を使用することを示している。
【0044】
「インタフェース種別」は、ファームウェア(言い換えると、ファームウェアがインストールされた通信制御基板400(
図1参照))が対象機器(ここでは、単機能照明)との間でデータを送受信する際のインタフェースの種別を示す。そして、「取得用」は、取得命令にて用いられるインタフェースの種別を示し、「操作用」は、操作命令にて用いられるインタフェースの種別を示す。さらに、「ピンタイプ」は、インタフェースにおけるピンの入出力を示す。言い換えると、「ピンタイプ」は、ファームウェア(ファームウェアがインストールされた通信制御基板400)が対象機器との間でデータを送受信する際のインタフェースの形式を示す。なお、本実施の形態では、インタフェースの形式の一例としてピンタイプを挙げているが、インタフェースの形式に関して利用者が入力する情報としては、ピンタイプの情報に限られるものではない。「I/O関数」は、インタフェースにて対象機器から値を読み込む場合の手続き(又は、対象機器に値を書き込む場合の手続き)を定めた関数を示す。言い換えると、「I/O関数」は、インタフェースを介して(ここでは、ピンを介して)ファームウェア(ファームウェアがインストールされた通信制御基板400)と対象機器との間でデータをやり取りする場合の手続きを定めた関数(処理関数)の一例として捉えることができる。「パラメータ」は、インタフェースに関するパラメータ、言い換えると、I/O関数(処理関数)にて用いられるパラメータであり、インタフェースのピンタイプによって、パラメータの種類や数は変化する。
【0045】
図示の例では、取得用のインタフェースは「GPIO(General Purpose Input/Output)」であり、「GET_GPIO」の関数を使用する。また、ピンタイプが「GPIO」の場合、「パラメータ」はインタフェースにて用いるピン番号になる。そこで、「PIN27」のピン(ピン番号が27番のピン)を指定している。また、操作用のインタフェースも「GPIO」であり、「SET_GPIO」の関数を使用し、「PIN27」のピンを指定している。
【0046】
ただし、本実施の形態において、利用者入力情報は、
図6に示す構成に限られるものではない。例えば、Bluetooth、Wi−Fi、Zigbeeなどの通信制御基板400に含まれる通信モジュールを利用者が選択して、利用者入力情報として入力しても良い。また、本実施の形態では、家電を制御するための通信規格であるECHONET Liteを用いているが、上述したように、ECHONET Lite以外の他の通信規格を用いても良い。そこで、例えば、電気機器を制御するための通信規格を利用者が選択して、利用者入力情報として入力しても良い。
【0047】
<利用者入力情報を入力する際の画面の説明>
次に、利用者入力情報を入力する際に表示される画面について説明する。
図7〜
図14は、利用者入力情報を入力する際に表示される画面の一例を示す図である。
図7〜
図14に示すように、利用者端末10は、利用者入力情報の入力のために複数の画面を予め定められた順番で遷移して表示する。
例えば、利用者入力情報を入力するために1つの画面が表示され、その画面上で利用者入力情報を全て入力する場合には、一画面上で入力する情報が多くなり利用者の操作が煩雑になる場合がある。本実施の形態で表示される複数の画面では、例えば、利用者が画面上で利用者入力情報を入力すると、入力した情報が引き継がれて次の画面が表示される。このように、複数の画面が遷移して表示されることにより、一画面上で入力する情報が減り、利用者は画面に従って利用者入力情報を入力すれば良いため、ファームウェアの生成を簡易に行うことができる。また、例えば、複数の画面において、前の画面で入力した情報が引き継がれずに次の画面が表示される場合には、それぞれの画面上で、両立しない相互に矛盾した情報が利用者によって入力されてしまう場合がある。本実施の形態で表示される複数の画面では、前の画面で入力した情報が引き継がれて次の画面が表示されるため、複数の画面上で入力される情報の整合性が保たれ、例えば、相互に矛盾した情報を入力したために利用者が情報を入力し直すような手間が軽減される。なお、ここでは、対象機器が「電動ブラインド・日よけ」という家電の場合について説明する。
【0048】
まず、利用者が利用者端末10からファームウェア生成サーバ20にアクセスすると、ファームウェア生成サーバ20から画面の情報が送信される。そして、利用者端末10にて利用者入力情報を入力するための画面が表示される。なお、ここでファームウェア生成サーバ20から利用者端末10へ送信される画面の情報は、ファームウェアを生成するのに用いられる情報を受け付ける受付機能、ファームウェアの生成指示を行う生成指示機能を実現させるためのプログラムの一例として捉えることができる。即ち、利用者端末10は、ファームウェア生成サーバ20から画面の情報を受信することにより、入力情報受付部11にて画面を表示し、利用者から利用者入力情報を受け付けて、受け付けた利用者入力情報を基にソフトウェアの生成指示を行う。
【0049】
ここでは、まず、
図7(a)に示す画面が表示される。図示のように、「センサ関連機器」、「空調関連機器」、「住宅・設備関連機器」など、機器のグループが一覧で示される。これらのグループについては、ECHONET Liteで規定されている。
【0050】
次に、利用者が例えば「住宅・設備関連機器」のボタン1Aを選択すると、
図7(b)に示す画面が表示される。ここでは、「電動ブラインド・日よけ」、「電動シャッター」、「電動雨戸・シャッター」など、「住宅・設備関連機器」のグループに含まれる機器が一覧で示される。各グループにどのような機器が分類されるかについては、ECHONET Liteで規定されている。利用者は、この一覧の中から「電動ブラインド・日よけ」のボタン1Bを選択すれば良い。なお、ここで選択される「電動ブラインド・日よけ」の情報は、
図6に示す利用者入力情報の中の「機器種別」に対応する情報である。本実施の形態では、第1画面の一例として、
図7(a),(b)に示す画面が用いられる。
【0051】
利用者が「電動ブラインド・日よけ」を選択すると、次に、
図7(c)に示す画面が表示される。この画面は、対象機器(ここでは、電動ブラインド・日よけ)を制御するためのファームウェアの情報(デバイス情報)の入力を受け付ける画面である。具体的には、入力される情報は、「メーカーコード」、「事業場コード」、「商品コード」、「製造番号」、「製造年月日」である。これらの情報は、ファームウェアを識別するためにファームウェアへ固有に付与される情報として捉えることができる。なお、利用者は、マニュアル等により予め定められた規則に従って、これらの情報を入力すれば良い。なお、ここで入力される情報は、ソフトウェアへ付与される付与情報の一例として用いられる。
【0052】
「メーカーコード」には、例えば、対象機器のメーカーのメーカーコードやファームウェアを生成するメーカーのメーカーコードが入力される。これらのメーカーコードは、エコーネットコンソーシアムより付与される。「事業場コード」は、各メーカーの事業場のコードであり、メーカー毎に規定されたコードが入力される。「商品コード」は、例えば、対象機器の商品コードや通信制御基板400の商品コードであり、メーカー毎に規定されたコードが入力される。「製造番号」は、例えば、対象機器に付与された製造番号や通信制御基板400に付与された製造番号であり、メーカー毎に規定された製造番号が入力される。「製造年月日」は、例えば、対象機器を製造した日付や通信制御基板400を製造した日付であり、メーカー毎に規定された日付が入力される。なお、ここで入力される情報については
図6の例には示していないが、これらの情報も、利用者入力情報としてファームウェア生成サーバ20に送信される。
【0053】
利用者がこれらの情報を入力すると、次に、
図8(a)に示す画面が表示される。ここでは、オプションとして選択可能な必須項目(以下、オプション必須と称する)が示される。このオプション必須は、オプション項目の一例であり、機器の種別(例えば、電動ブラインド・日よけ)毎にECHONET Liteで規定されている項目である。図示の例では「エネルギー」、「快適生活支援」という2つのオプション必須が示されている。例えば、利用者が「エネルギー」の項目1Cを選択すると、以降の設定において、エネルギーの消費を抑制する機能を制御するための設定が行われる。より具体的には、オプション必須は、後述する操作項目と予め対応付けられており、利用者がオプション必須を選択すると、選択されたオプション必須に対応する1又は複数の操作項目が選択されることになる。
【0054】
利用者がオプション必須の選択可否を入力すると、次に、
図8(b)に示す画面が表示される。ここでは、対象機器に対する操作項目が並べられ、一覧で示される。言い換えると、対象機器において操作(制御)される機能の候補が、操作項目として一覧で示される。また、これらの操作項目は、対象機器に対して実行される操作の種類を示す項目(操作品目)として捉えることもできる。利用者は、この一覧の中から、対象機器において操作(制御)しようとする機能を選択(チェック)すれば良い。本実施の形態では、第2画面の一例として、
図8(b)に示す画面が用いられる。
【0055】
ここで、操作項目によっては、すでに選択済み(チェック済み)で変更できないような態様(言い換えると、第2の態様の一例)で表示される項目(以下、必須項目と称する)も存在する。図示の例では、「動作状態」、「異常発生状態」、「開閉動作設定」が必須項目であり、選択済みになっている。この必須項目は、対象機器に対して必須な操作内容にあたる操作項目、言い換えると、対象機器に対してファームウェアへ搭載することが必須な機能にあたる操作項目であり、ファームウェアへ搭載するか否かを利用者が選択しようとしても、その選択は受け付けられない。必須項目については、機器の種別(例えば、電動ブラインド・日よけ)毎にECHONET Liteで規定されている。即ち、例えば「電動ブラインド・日よけ」については、「動作状態」、「異常発生状態」、「開閉動作設定」の機能が必須であることがECHONET Liteで規定されているといえる。
【0056】
一方、必須項目ではない操作項目(以下、任意項目と称する)については、利用者が選択可能(チェック可能)な態様(言い換えると、第1の態様の一例)で表示される。この任意項目は、対象機器に対して任意な操作内容にあたる操作項目、言い換えると、対象機器に対してファームウェアへ搭載することが任意な機能にあたる操作項目であり、ファームウェアへ搭載するか否かの選択が受け付けられる。即ち、任意項目については、対象機器において操作する機能として選択するか否かを利用者が自由に決めることができるようになっている。図示の例では、例えば、「メーカー異常コード」、「異常内容」、「タイマ動作設定」などは任意項目であり、利用者の操作によって、選択済み(チェック済み)の状態にしたり、選択が外れた(チェックが外れた)状態にしたりされる。
なお、ここで選択される「動作状態」、「異常発生状態」、「開閉動作設定」、「メーカー異常コード」、「異常内容」、「タイマ動作設定」などの操作項目の情報は、
図6に示す利用者入力情報の中の「機能種別」に対応する情報である。
【0057】
また、上述したように、操作項目とオプション必須とは予め対応付けられているため、
図8(a)に示す画面上で利用者がオプション必須を選択した場合には、
図8(b)に示す画面において、選択したオプション必須の機能に対応する操作項目が必須項目として表示される。例えば、
図9(a)に示すように、利用者が「エネルギー」のオプション必須を選択したものとする。この場合、
図9(b)に示すように、「エネルギー」のオプション必須の機能に対応する操作項目として、例えば、「風検知状態」、「日差し検知状態」の操作項目がすでに選択済みの必須項目として表示される。
【0058】
図8(b)や
図9(b)に示す画面のように、利用者が操作項目を選択すると、次に、
図10(a)に示す画面が表示される。この画面は、何れの操作項目にも共通に設けられる複数の設定項目として、「取得」、「操作」、「状態変更時通知」を実装するか否か(実装又は未実装)を設定するための設定項目が操作項目毎に並べられた画面である。言い換えると、操作項目毎に、「取得」、「操作」、「状態変更時通知」を実装するか否か(実装又は未実装)を選択する画面である。ここで、「取得」、「操作」、「状態変更時通知」を実装するか否かの情報は、
図6に示す利用者入力情報の中の「命令種別」に対応する情報である。即ち、「取得」は、単機能照明から情報を取得する命令を示す。「操作」は、単機能照明を操作する命令を示す。なお、「状態変更時通知」は、対象機器が自機の状態変更を通知する命令を示す。この命令は、対象機器の状態が変化した場合に、状態が変更したことを対象機器から自発的に外部の機器に通知するための命令である。
【0059】
そして、画面上では、各操作項目において「取得」、「操作」、「状態変更時通知」が並んでおり、「取得」、「操作」、「状態変更時通知」に設けられた円の図形を左右に移動させることにより、実装するか否かの選択が行われる。例えば、「動作状態」の「取得」では、円の図形1Dが右に移動した状態にあり、「実装」が選択されている。一方、「動作状態」の「操作」では、円の図形1Eが左に移動した状態にあり、「未実装」が選択されている。ここで、利用者が「実装」を選択する場合には、円の図形1Eを図中右方向に移動させれば良い。
【0060】
なお、ECHONET Liteの規定により、「実装」、「未実装」が予め固定で決まっている項目、即ち、設定するか否か(実装させて設定内容を入力するか否か)が予め定められている項目も存在する。このような項目は、円の図形を左右に移動できないような態様(言い換えると、第2の態様の一例)で表示される。図示の例では、「動作状態」の「取得」、「状態変更時通知」では、円の図形を移動させることはできず、「実装」で固定されている。同様に、「異常発生状態」の「取得」、「状態変更時通知」は「実装」で固定されており、「操作」は「未実装」で固定されている。さらに、「開閉動作設定」の「取得」、「操作」、「状態変更時通知」は「実装」で固定されている。付言すると、利用者が、例えば、「動作状態」の「取得」の項目にある図形1Dを選択しても、「実装」又は「未実装」の選択(設定内容を入力するか否かの選択)は受け付けられず、
図10(b)に示す画面が表示される。
図10(b)の画面では、「実装」、「未実装」の設定変更が禁止されている旨のメッセージが示されている。
【0061】
また、「動作状態」の「操作」のように、設定するか否か(実装させて設定内容を入力するか否か)が任意のものについては、円の図形が左右に移動可能な態様(言い換えると、第1の態様の一例)で表示される。このような項目については、「実装」又は「未実装」の選択が受け付けられ、利用者は、円の図形を左右に移動させることにより、設定内容を入力するか否かを自由に決めることができる。
【0062】
そして、利用者が各操作項目の「取得」、「操作」、「状態変更時通知」について「実装」、「未実装」の選択を完了すると、次に、
図10(c)に示す画面が表示される。この画面は、「実装」が選択された操作項目についての設定を行う画面である。言い換えると、この画面では、設定するか否かが任意のものについて、利用者が「実装」を選択した項目や、最初から「実装」の設定が行われている項目についての設定が行われる。また、設定することが予め定められている項目(即ち、「実装」が固定で決まっている項目)についての設定が行われる。
図10(a)に示す例では、「動作状態」の「取得」および「状態変更時通知」、「異常発生状態」の「取得」および「状態変更時通知」、「開閉動作設定」の「取得」、「操作」および「状態変更時通知」、の合計7つの操作項目で「実装」が選択されている。そこで、
図10(c)に示す画面上では、これらの7つの項目についての設定が行われる。
【0063】
例えば、「動作状態」の「取得」について設定を行う場合、利用者が
図10(c)に示す設定ボタン1Fを選択すると、
図11−1(a)に示す画面が表示される。ここでは、ファームウェアがインストールされた通信制御基板400(
図1参照)が対象機器(ここでは、電動ブラインド・日よけ)との間でデータを送受信する際に使用されるインタフェースについての設定が行われる。より具体的には、「ピンタイプ」、「I/O関数」、「パラメータ」の設定が行われる。ここで設定される「ピンタイプ」、「I/O関数」、「パラメータ」の情報は、それぞれ、
図6に示す利用者入力情報の中の「インタフェース種別」の「ピンタイプ」、「I/O関数」、「パラメータ」に対応する情報である。
【0064】
そして、
図11−1(b)に示すように、ピンタイプとしては、例えば、「未接続」、「GPIO」、「SPI(Serial Peripheral Interface)」、「I2C(Inter-Integrated Circuit)」、「UART(Universal Asynchronous Receiver Transmitter )」が候補として表示され、利用者は表示された候補の中から使用するピンタイプを選択すれば良い。また、
図11−2(c)に示すように、I/O関数についても1又は複数の候補が表示され、利用者は表示された候補の中から使用するI/O関数を選択すれば良い。さらに、
図11−2(d)に示すように、パラメータについても1又は複数の候補が表示される。図示の例では、パラメータとしてピン番号の候補が示されている。例えば、ピン番号の27番を選択する場合、利用者は「PIN27」を選択すれば良い。最終的には、
図11−2(e)に示すように、選択した各項目の内容が表示される。利用者は、表示された内容で問題なければ「完了」のボタン1Gを選択する。このようにして、「動作状態」の「取得」についての設定が行われる。
【0065】
同様に、「異常発生状態」の「取得」、「開閉動作設定」の「取得」および「操作」についても、「ピンタイプ」、「I/O関数」、「パラメータ」の設定が行われる。
また、「状態変更時通知」については、対象機器が自機の状態の変更有無を確認する間隔(ポーリング間隔)の設定が行われる。このポーリング間隔の設定により、対象機器は、ポーリング間隔毎に自機の状態の変更有無を確認し、状態変更がある場合には外部の機器へ通知するように制御される。
図12(a)に示す例では、利用者の入力によりポーリング間隔が100ミリ秒として設定されている。なお、本実施の形態では、第3画面の一例として、
図10(c)、
図11−1、
図11−2に示す画面が用いられる。
【0066】
そして、利用者は、全ての操作項目(ここでは、7つの操作項目)の設定を行った後、「FINISH」のボタン1Hを選択すると、利用者入力情報の入力が完了し、
図12(b)に示す画面が表示される。この後、利用者が、例えば、画面上でファームウェア生成を受け付けるボタン(不図示)を選択することにより、データ変換部12が、入力情報受付部11が受け付けた利用者入力情報をサーバ送信用データへ変換し、データ送信部13が、サーバ送信用データをファームウェア生成サーバ20へ送信する。言い換えると、利用者が画面上でファームウェア生成を受け付けるボタンを選択することにより、データ送信部13は、複数の画面上で受け付けた利用者入力情報を基に、ファームウェア生成サーバ20に対してソフトウェアの生成指示を行う。
【0067】
また、ファームウェア生成サーバ20に対してソフトウェアの生成指示を行った後、
図12(c)に示す画面が表示される。
図12(c)に示す画面は、ファームウェアを通信制御基板400にインストールするための画面である。言い換えると、生成指示を基に生成されるファームウェアを通信制御基板400にインストールする指示を受け付けるための画面である。
図12(c)に示す例のように、例えば、ファームウェアをインストールする対象となる複数の通信制御基板400が表示される。利用者はこれらの通信制御基板400の中から、ファームウェアをインストールする通信制御基板400を選択すれば良い。利用者が通信制御基板400を選択し、さらに「実行」のボタン1Iを選択することにより、選択した通信制御基板400に対してファームウェアをインストールする処理が行われる。より具体的には、利用者端末10は、「実行」のボタン1Iの選択を受け付けると、例えばBluetooth等の通信規格により、ファームウェア生成サーバ20にて生成されたファームウェアを通信制御基板400に送信してインストールする処理を行う。なお、ファームウェアについては、「実行」のボタン1Iが選択されたことを契機にファームウェア生成サーバ20から利用者端末10へ送信されることとしても良いが、「実行」のボタン1Iが選択される前にファームウェア生成サーバ20から利用者端末10へ送信されることとしても良い。
【0068】
また、本実施の形態では、上述したように、利用者入力情報として、例えばBluetoothモジュールなどの通信制御基板400に含まれる通信モジュールを利用者が選択して入力しても良い。さらに、利用者入力情報として、例えばECHONET Liteなどの電気機器を制御するための通信規格を利用者が選択して入力しても良い。そこで、通信モジュールの選択を受け付けるための画面、電気機器を制御するための通信規格の選択を受け付けるための画面を表示する場合について、説明する。
【0069】
まず、通信モジュールの選択を受け付けるための画面について説明する。
図13(a)に示す画面では、選択可能な通信モジュールとして6つの通信モジュールが表示されている。より具体的には、
図13(a)に示す画面のように、各通信モジュールについて、例えば、通信モジュールのメーカー、通信モジュールの種類、型番の情報などが表示される。付言すると、各通信モジュールについて、通信モジュールを識別するための情報が表示される。利用者はこれらの情報を確認し、使用する通信モジュールを選択すれば良い。
【0070】
図13(a)に示す例では、例えば、メーカーが「A社」、種類が「Bluetoothモジュール」、型番が「aa」の通信モジュールが示されている。同様に、メーカーが「A社」、種類が「Bluetoothモジュール」、型番が「bb」の通信モジュールが示されている。また、「Bluetoothモジュール」以外の通信モジュールとして、「Wi−Fiモジュール」、「Zigbeeモジュール」が示されている。さらに、メーカーについては、「A社」、「B社」、「C社」等の複数のメーカーが示されている。
【0071】
また、この通信モジュールの選択画面は、例えば、利用者が利用者端末10からファームウェア生成サーバ20にアクセスした後、最初の画面として表示される。そして、例えば、利用者が通信モジュールを選択した後に、
図7(a)に示す画面に遷移する。なお、通信モジュールの種類に応じて、通信制御基板400が対象機器との間でデータを送受信する際のインタフェースの構成が変わる場合がある。インタフェースの構成が変われば、インタフェースについての設定内容も変わる。そのため、インタフェースについての設定を行うための画面及びその画面上で入力可能な情報、即ち、
図11−1及び
図11−2に示す画面の構成及びこれらの画面上で入力可能な情報も変わることになる。
【0072】
次に、電気機器を制御するための通信規格の選択を受け付ける画面について説明する。
図13(b)に示す画面では、選択可能な通信規格(プロトコル)の一例として、ECHONET Liteの他に、SEP2.0、KNXを示している。利用者は、これらの通信規格の中から使用する通信規格を選択すれば良い。なお、この通信規格の選択画面は、例えば、利用者が利用者端末10からファームウェア生成サーバ20にアクセスした後、最初の画面として表示される。そして、例えば、利用者が通信規格を選択した後に、
図13(a)に示す画面や
図7(a)に示す画面に遷移する。なお、通信規格に応じて、制御可能な対象機器や、対象機器に対して実行可能な操作内容が変わる場合がある。そのため、
図7〜
図14に示す画面の構成及びこれらの各画面上で入力可能な情報は、選択される通信規格に応じて変わる場合がある。
【0073】
また、
図7(c)に示す画面では、上述したように、メーカーコード等の情報が入力されるが、利用者が複数の対象機器を選択する場合、1度利用者が入力した情報を引き継ぐことによって、利用者が再度入力することを省略するようにしても良い。言い換えると、
図7(c)に示す画面を表示するにあたり、他の対象機器(他の制御対象機器)が選択された際に入力された情報がある場合には、入力された情報をこの画面上に表示して編集を受け付けることとしても良い。
【0074】
例えば、
図14(a)に示す画面のように、対象機器「電動ブラインド・日よけ」について、「メーカーコード」、「事業場コード」、「商品コード」、「製造番号」、「製造年月日」を利用者が入力したとする。この場合、入力された情報は利用者端末10内の記憶部に記憶される。そして、この後、利用者が他の対象機器として、例えば「電動シャッター」を選択した場合、
図14(b)に示す画面のように、「電動ブラインド・日よけ」にて1度利用者が入力した情報が入力された状態で表示される。言い換えると、利用者が他の対象機器として、例えば「電動シャッター」を選択した場合、記憶部に記憶された「電動ブラインド・日よけ」についての情報が読み込まれて、読み込まれた情報が入力された状態で画面表示が行われる。利用者は、入力された情報を確認し、編集する場合には編集を加えた上で、電動シャッター用の各種情報を設定すれば良い。
なお、利用者が複数の対象機器を選択する場合には、
図7(c)に示す画面で入力される情報に限らず、他の画面で入力される情報についても、1度利用者が入力した情報を引き継いで、利用者が再度入力することを省略するようにしても良い。例えば、
図11−1及び
図11−2に示す画面について、利用者が入力した「ピンタイプ」、「I/O関数」、「パラメータ」の情報を記憶しておき、他の対象機器が選択された場合に、記憶した情報を読み込んで表示しても良い。この場合、「ピンタイプ」、「I/O関数」、「パラメータ」の情報を、ソフトウェアへ付与される付与情報の一例として捉えることができる。
【0075】
<サーバ送信用データの説明>
次に、
図15を参照しながら、利用者端末10のデータ変換部12が生成するサーバ送信用データについて説明する。ここでは、データ変換部12が、
図6に示す利用者入力情報を変換して、サーバ送信用データを生成するものとして説明する。
【0076】
図15は、利用者入力情報の変換に用いられるキーの一例を示す図である。このようなキーは、ECHONET Liteにて規定されている。また、本実施の形態において独自に規定したキーも存在する。
図15に示すキーのうち、「0x0201」、「0x0001」のキーは、本実施の形態において独自に規定したキーであり、その他のキーはECHONET Liteにて規定されたものである。
【0077】
より具体的には、「0x02」のキーは、「単機能照明」のclass_groupコードを意味し、「単機能照明」が属しているグループである「住宅・設備関連機器」のキーを示す。「0x91」のキーは、「単機能照明」のclassコードを意味し、「単機能照明」のキーを示す。「0x01」のキーは、「単機能照明」のinstanceコードを意味し、対象機器を一意に識別するために付与されるキーである。instanceコードが付与されることにより、1つのファームウェアで複数の同種の対象機器の通信機能を制御する場合であっても、ファームウェアにてそれぞれの対象機器を識別できるようになる。
【0078】
また、「0x80」のキーは、「単機能照明」のpropertyコードを意味し、「単機能照明」の機能種別である「動作状態」を意味するキーである。「get」のキーは、命令種別である「取得」を意味するキーである。「set」のキーは、命令種別である「操作」を意味するキーである。「0x0201」のキーは、GPIOで用いられる取得用のI/O関数のコードを意味するキーである。「0x0001」のキーは、GPIOで用いられる操作用のI/O関数のコードを意味するキーである。「27」は、インタフェースで用いられるピン番号を意味するキーである。「GPIO」は、インタフェースで用いられるピンの入出力(GPIO)を意味するキーである。
【0079】
そして、サーバ送信用データは、
図15に示すキーを用いて、
図6に示す利用者入力情報を変換することにより生成される。
より具体的には、例えば、サーバ送信用データには、「住宅・設備関連機器」、「単機能照明」のキーである「0x02」、「0x91」のキーの情報が含まれている。これは、
図6に示す利用者入力情報の「機器種別」の「単機能照明」の情報に対応する。また、例えば、GPIOで用いられる取得用のI/O関数のキーである「0x0201」のキーの情報が含まれている。さらに、例えば、GPIOで用いられる操作用のI/O関数のキーである「0x0001」のキーの情報が含まれている。これらは、
図6の利用者入力情報の「I/O関数」の「GET_GPIO」、「SET_GPIO」の情報に対応する。その他、サーバ送信用データには、
図15に示す「0x01」、「0x80」、「get」、「set」、「27」、「GPIO」のキーの情報が含まれている。
【0080】
このようにして、データ変換部12は、キーを用いて利用者入力情報を変換し、サーバ送信用データを生成する。なお、
図15に示すような各種のキーの一覧は、例えば、利用者端末10が利用者入力情報を入力するための画面を読み込む際に、ファームウェア生成サーバ20から利用者端末10へ送信される。
【0081】
<ソースコード生成部による処理の説明>
次に、
図16(a)、(b)を参照しながら、ソースコード生成部22による処理について説明する。ここでは、ソースコード生成部22が、
図15に示すキーを基に生成されるサーバ送信用データからソースコード(データ部)を生成するものとして説明する。
【0082】
図16(a)は、サーバ送信用データに適用されるソースコード生成用フォーマットの一例を示す図である。このソースコード生成用フォーマットは、ECHONET Liteで規定されているものではなく、本実施の形態において独自に規定したものである。
【0083】
ここで、「機器種別」は、対象機器を識別するための情報を含むフォーマットである。「命令種別」は、命令の種別を識別するための情報を含むフォーマットである。「機能種別」は、対象機器において制御しようとする機能の種別を識別するための情報を含むフォーマットである。「データ種別」は、データ形式を識別するための情報を含むフォーマットである。ここで、データ形式とは、例えば、データの型、データが取り得る値の範囲などであり、ECHONET Liteで規定されているものもあれば、利用者が独自に定めたものもあるものとする。「インタフェース種別」は、対象機器との間でデータを送受信する際のインタフェースに関する情報を含むフォーマットである。
【0084】
また、
図16(b)は、ソースコード(データ部)の一例を示す図である。
図16(b)に示すソースコード(データ部)は、
図15に示すキーを基に生成されるサーバ送信用データに、
図16(a)のソースコード生成用フォーマットを適用することにより生成される。
【0085】
より具体的には、例えば、
図16(a)のフォーマット「機器種別」には、対象機器を識別するための情報として、「class_group」、「class」、「instance」のコードが定められている。また、
図15に示すキーを基に生成されるサーバ送信用データには、「class_group」として「0x02」、「class」として「単機能照明」のclassコードである「0x91」、「instance」として「0x01」が含まれている。そこで、「機器種別」のフォーマットの「class_group」、「class」、「instance」を、「0x02」、「0x91」、「0x01」で置換する。このようにして、
図16(b)に示すソースコード(データ部)のデータa1のコードが生成される。
【0086】
同様に、「命令種別」、「機能種別」、「データ種別」、「インタフェース種別」の各フォーマットについて、サーバ送信用データの該当コードで置換することにより、ソースコード(データ部)が生成される。ここで、「命令種別」のフォーマットを置換することにより、
図16(b)に示すデータa2のコードが生成される。「機能種別」のフォーマットを置換することにより、
図16(b)に示すデータa3のコードが生成される。「データ種別」のフォーマットを置換することにより、
図16(b)に示すデータa4のコードが生成される。「インタフェース種別」のフォーマットを置換することにより、
図16(b)に示すデータa5のコードが生成される。
【0087】
なお、ソースコード生成用フォーマットの各フォーマットでは、フォーマット間で関係のある情報同士が対応付けられている。そのため、各フォーマットから生成されるソースコード(データ部)のデータ(図示の例ではデータa1〜データa5)についても、データ間で関係のある情報同士が対応付けられている。
例えば、ソースコード(データ部)のデータa1には、1又は複数の対象機器の情報が記述される。ここで、ソースコード(データ部)のデータa2には命令種別の情報が記述されるが、データa1に記述されたどの対象機器の命令種別かがわかるように、対象機器と命令種別とを対応付けて記述される。さらに、ソースコード(データ部)のデータa3には機能の情報が記述されるが、どの対象機器のどの命令種別を使用する機能かがわかるように、データa1の対象機器及びデータa2の命令種別と対応付けて、機能の情報が記述される。同様に、データa4、データa5でも、データ間で関係のある情報同士が対応付けられる。
【0088】
また、ここでは、ソースコード生成用フォーマットとして、「機器種別」、「命令種別」、「機能種別」、「データ種別」、「インタフェース種別」の5つのフォーマットについて説明した。このうち、「機器種別」、「命令種別」、「機能種別」、「データ種別」の4つのフォーマットは、サーバ送信用データの内容によらず共通に用いられる。一方、「インタフェース種別」は、使用するインタフェースに応じたフォーマットが用いられる。例えば、「GPIO」のインタフェースが使用される場合には、「GPIO」用のフォーマットが用いられる。また、例えば、「SPI」のインタフェースが使用される場合には、「SPI」用のフォーマットが用いられる。
【0089】
このようにして、ソースコード生成部22は、サーバ送信用データに対してソースコード生成用フォーマットを適用して、ソースコード(データ部)を生成する。付言すると、ソースコード(データ部)は、対象機器の種類および特定の機能をソースコード生成用フォーマットに則って記述されたコードであると捉えることができる。
【0090】
<ファームウェア生成部による処理の説明>
次に、
図17(a),(b)を参照しながら、ファームウェア生成部23による処理について説明する。
図17(a),(b)は、ファームウェア生成部23により生成されるファームウェアのコードの一例を示す概念図である。
【0091】
図17(a)に示すソースコード(データ部)は、利用者が入力した利用者入力情報に応じて、ソースコード生成部22により生成されたものである。図示の例は、サーバ送信用データを「機器種別」のソースコード生成用フォーマットに適用して生成されたソースコード(データ部)を示している。より具体的には、利用者が、対象機器としてエアコンおよび冷蔵庫を選択した場合を示している。
【0092】
また、
図17(a)に示すソースコード(手続き部)は、ソースコード格納部25に格納されているものであり、利用者入力情報によらず一定である。図示の例では、「機器種別」に対応したソースコード(手続き部)を示しており、利用者がどのような機器を対象機器として選択したとしても対応できるように、予め定められている。例えば、図示のソースコード(手続き部)の3行目「全機器共通手続き(受信データ)」は、ファームウェアが外部からデータを受信した場合に、その受信データに基づいてどのような種類の家電についても実行できるように記述されたコードである。
【0093】
また、
図17(b)に示すソースコード(データ部)も、利用者が入力した利用者入力情報に応じて、ソースコード生成部22により生成されたものである。図示の例は、サーバ送信用データを「機能種別」のソースコード生成用フォーマットに適用して生成されたソースコード(データ部)を示している。より具体的には、利用者が、エアコンにて制御しようとする機能として、「温度自動」、「冷房モード」、「消費電力」を選択し、冷蔵庫にて制御しようとする機能として、「ドア開閉」、「急速冷蔵」、「消費電力」を選択した場合を示している。
【0094】
また、
図17(b)に示すソースコード(手続き部)も、ソースコード格納部25に格納されているものであり、利用者入力情報によらず一定である。図示の例では、「機能種別」に対応したソースコード(手続き部)を示しており、利用者がどのような機器を対象機器として選択し、対象機器において制御しようとする機能としてどのような機能を選択したとしても対応できるように、予め定められている。例えば、図示のソースコード(手続き部)の3行目「全機能共通手続き(受信データ)」は、ファームウェアが外部からデータを受信した場合に、その受信データに基づいてどのような家電の機能についても実行できるように記述されたコードである。
【0095】
このように、ソースコード(データ部)は、各ソースコード生成用フォーマットに応じて生成され、それと対応するソースコード(手続き部)が予め定められている。
図17(a)に示すソースコードは、「機器種別」に対応するソースコード(データ部)およびソースコード(手続き部)であり、
図17(b)に示すソースコードは、「機能種別」に対応するソースコード(データ部)およびソースコード(手続き部)である。また、
図17には示していないが、「命令種別」に対応するソースコード(データ部)およびソースコード(手続き部)、「データ種別」に対応するソースコード(データ部)およびソースコード(手続き部)、「インタフェース種別」に対応するソースコード(データ部)およびソースコード(手続き部)なども存在する。そして、ファームウェア生成部23は、これらの各フォーマットに対応するソースコード(データ部)とソースコード(手続き部)とを全て足し合わせる(結合する)ことにより、ファームウェアのソースコードを生成する。付言すると、ファームウェアのソースコードは、ソースコード(データ部)とソースコード(手続き部)とが分離して記述されたコードであると捉えることができる。
【0096】
次に、ファームウェア生成部23により生成されたファームウェアが実際に動作する場合の処理について説明する。ここでは、一例として、利用者が、エアコンを操作する入力を行い、そのデータ(以下、受信データAと称することとする)をファームウェアが受信したものとして説明する。
【0097】
ファームウェアの処理としては、「機器種別」、「命令種別」、「機能種別」、「データ種別」、「インタフェース種別」に対応するそれぞれのソースコード(手続き部)の処理が順番に実行される。
初めに、「機器種別」に対応するソースコード(手続き部)の処理が実行される。その際、「機器種別」に対応するソースコード(データ部)が参照される。ここでは、受信データAで対象機器として指定されたエアコンが、ソースコード(データ部)に記述されているか否かの検査(判定)などが行われる。
図17(a)に示す例では、エアコンはソースコード(データ部)に記述されているため、次の処理に進む。一方、受信データAで操作対象として指定された機器がソースコード(データ部)に記述されていない場合には、例えばファームウェアからエラーが返されて処理が終了する。
【0098】
次に「命令種別」に対応するソースコード(手続き部)の処理が実行される。その際、「命令種別」に対応するソースコード(データ部)が参照される。ここでは、受信データAで指定された命令種別(即ち、エアコンの命令種別)が、ソースコード(データ部)に記述されているか否かの検査などが行われる。また、上述したように、ソースコード(データ部)では、関係のある情報同士が対応付けられている。即ち、ソースコード(データ部)には、各家電と命令種別とが対応付けて記述されている。そのため、ここでは、ソースコード(データ部)の中で、エアコンの命令種別が記述された箇所を参照して、検査を行えば良い。なお、「機器種別」に対応するソースコード(手続き部)からは、ソースコード(データ部)の中でエアコンの命令種別が記述された箇所を参照するように指示される。そのため、「命令種別」に対応するソースコード(手続き部)の処理では、該当箇所を参照することができる。
【0099】
次に「機能種別」に対応するソースコード(手続き部)の処理が実行される。その際、「機能種別」に対応するソースコード(データ部)が参照される。ここでは、受信データAで指定された機能(即ち、エアコンの機能)が、ソースコード(データ部)に記述されているか否かの検査などが行われる。上述したように、機能に関しても、各家電及び命令種別の情報と対応付けて記述されている。そのため、ここでは、ソースコード(データ部)の中で、エアコン(及び命令種別)に対応する機能が記述された箇所を参照して、検査を行えば良い。なお、「命令種別」に対応するソースコード(手続き部)からは、ソースコード(データ部)の中でエアコン(及び命令種別)に対応する機能が記述された箇所を参照するように指示される。そのため、「機能種別」に対応するソースコード(手続き部)の処理では、該当箇所を参照することができる。
【0100】
例えば、
図17(b)に示す例の場合、受信データAで指定されたエアコンの機能が、「温度自動」、「冷房モード」、「消費電力」の何れかに該当するか順番にチェックする。ここで、受信データAの機能がどの機能にも該当しなければ、エラーとなり処理は終了する。一方、受信データAの機能が、例えば「温度自動」の機能に該当する場合、次の「データ種別」、「インタフェース種別」の処理に進む。
【0101】
同様に、「データ種別」に対応するソースコード(手続き部)の処理が実行される際には、「データ種別」に対応するソースコード(データ部)が参照される。ここでは、受信データAが、ソースコード(データ部)に記述されたデータ形式を満たすか否かの検査などが行われる。さらに、「インタフェース種別」に対応するソースコード(手続き部)の処理が実行される際には、「インタフェース種別」に対応するソースコード(データ部)が参照される。ここでは、受信データAで指定されたデータ送受信の方法が、ソースコード(データ部)に記述されているか否かの検査などが行われる。受信データAで指定されたデータ送受信の方法がソースコード(データ部)に記述されていれば、その送受信の方法で、エアコンに対してデータの送受信が開始される。
【0102】
<ファームウェア生成システム全体の処理の流れ>
次に、ファームウェア生成システム1全体の処理の流れについて説明する。
図18は、ファームウェア生成システム1においてファームウェアを生成する処理手順の一例を示したフローチャートである。ここで、ステップ101〜ステップ103の処理は、利用者端末10による処理に該当する。また、ステップ104〜ステップ106の処理は、ファームウェア生成サーバ20の処理に該当する。
【0103】
まず、利用者が利用者端末10の画面上で利用者入力情報を入力することにより、入力情報受付部11は、利用者入力情報を受け付ける(ステップ101)。次に、データ変換部12は、受け付けた利用者入力情報に対応するキーを用いて、利用者入力情報を変換してサーバ送信用データを生成する(ステップ102)。次に、データ送信部13は、生成されたサーバ送信用データをファームウェア生成サーバ20へ送信する(ステップ103)。
【0104】
次に、データ受付部21は、利用者端末10からサーバ送信用データを受け付ける(ステップ104)。次に、ソースコード生成部22は、フォーマット格納部24に格納されているソースコード生成用フォーマットを取得する。そして、ソースコード生成部22は、取得したソースコード生成用フォーマットを用いて、利用者端末10から受け付けたサーバ送信用データを変換してソースコード(データ部)を生成する(ステップ105)。次に、ファームウェア生成部23は、ソースコード格納部25からソースコード(手続き部)を取得する。そして、ファームウェア生成部23は、取得したソースコード(手続き部)と、生成されたソースコード(データ部)とを足し合わせて、ファームウェアを生成する(ステップ106)。そして、本処理フローは終了する。
【0105】
また、ファームウェアが生成された後には、例えば、利用者が利用者端末10にてファームウェアを取得する操作を行うことにより、生成されたファームウェアがファームウェア生成サーバ20から利用者端末10へ送信される。利用者は、送信されてきたファームウェアを、例えば通信制御基板にインストールし、その通信制御基板を対象機器に搭載することにより、対象機器の通信機能が制御される。ただし、通信制御基板を対象機器に搭載する構成に限られるものではなく、例えば、対象機器を制御する他の制御装置に通信制御基板を搭載して、この制御装置がファームウェアにより対象機器の通信機能を制御することとしても良い。
【0106】
なお、本実施の形態では、対象機器に、対象機器の各種の機能を制御する制御装置等が備えられているものとして説明したが、対象機器の中には、例えばLED(Light Emitting Diode)照明のように制御装置等を備えていない単純な構成のものも存在する。このような単純な構成の対象機器の場合、ファームウェアは、例えば、利用者端末10から受信した命令に従って、対象機器の動作を制御する。即ち、この場合、ファームウェアは、対象機器の通信機能を制御するとともに、対象機器の動作を制御するものとして捉えることができる。
【0107】
以上説明したように、本実施の形態に係るファームウェア生成システム1では、利用者が操作したい機器の種類や機能等を画面上で選択することにより、選択された機器や機能に対応したファームウェアが生成される。その際、ファームウェア生成サーバ20のファームウェア生成部23は、利用者入力情報に応じて生成されたソースコード(データ部)と、予め定められたソースコード(手続き部)とを足し合わせることにより、ファームウェアを生成する。
【0108】
また、例えば、ECHONET Liteの規定により、対象機器の候補として新しい機器が追加されたり、対象機器において制御しようとする機能として新しい機能が追加されたりした場合、
図15に示すキーのclassコードやpropertyコードが追加される。しかし、ソースコード生成用フォーマットおよびソースコード(手続き部)は変更しなくて良く、そのままのものを用いれば良い。即ち、新しい機器や機能に対応するファームウェアを生成する場合であっても、ソースコード生成部22は、ソースコード生成用フォーマットを用いて、利用者が画面上で選択した機器や機能に対応したソースコード(データ部)を生成する。そして、ファームウェア生成部23は、生成されたソースコード(データ部)とソースコード(手続き部)とを足し合わせることにより、ファームウェアを生成する。
【0109】
なお、本実施の形態では、利用者端末10がサーバ送信用データをファームウェア生成サーバ20へ送信し、ファームウェア生成サーバ20がファームウェアを生成する構成としたが、このような構成に限られるものではない。例えば、利用者端末10が、ファームウェア生成サーバ20の機能を有し、利用者端末10にてファームウェアを生成するような構成であっても良い。言い換えると、利用者端末10が、ファームウェア生成サーバ20のデータ受付部21、ソースコード生成部22、ファームウェア生成部23、フォーマット格納部24、ソースコード格納部25等の機能を備えることとしても良い。この場合、利用者端末10は、ファームウェアを生成するのに用いられる情報を受け付ける受付機能、ファームウェアの生成指示を行う生成指示機能を実現させるためのプログラムを有し、ファームウェアを生成するものとして捉えることができる。
【0110】
また、本発明の実施の形態を実現するプログラムは、磁気記録媒体(磁気テープ、磁気ディスクなど)、光記録媒体(光ディスクなど)、光磁気記録媒体、半導体メモリなどのコンピュータが読取可能な記録媒体に記憶した状態で提供し得る。また、インターネットなどの通信手段を用いて提供することも可能である。
【0111】
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。
【解決手段】利用者端末10の入力情報受付部11は、制御対象機器の通信機能を制御するためのソフトウェアを生成するのに用いられる情報を入力可能な複数の画面として、予め定められた複数の機器の中から制御対象機器の選択を受け付けるための第1画面、選択された制御対象機器に対して実行される操作の種類の選択を受け付けるための第2画面、選択された操作のためのデータをソフトウェアが搭載される制御部が送受信する際に使用されるインタフェースの設定内容の入力を受け付けるための第3画面を、予め定められた順番で遷移させて表示する。