Sunshine through autumn oak, Glen Roy

© CopyrightAndy Waddingtonand licensed forreuseunder thisCreative Commons Licence

来月10月17日に、関西地区で初めて実施するKNXの活動「第1回大阪KNX住宅・ビル制御テクノロジー・アプリケーションフォーラム」で「KNXとデマンドレスポンス」と題してお話させていただくことになり、このブログの場を借りて、話す内容を整理させていただいています。
前回までに、欧州におけるスマートグリッドに関する動向をご紹介し、続いて、欧州で、デマンドレスポンスがどのような位置づけにあるのかを確認しました。

今回は、KNX側からのスマートグリッド/スマートシティに対するアプローチであるKNX Cityについてご紹介しようと思ったのですが、その前に「KNXとは、そもそも何なのか?」を確認しておきたいと思います。

では、はじめましょう。

3.  KNXとは?

DRとKNX-その1」の冒頭では、KNXに関するファクトをご紹介しました。

日本でこそ存在感がありませんが、KNXは世界中でハウス・ビル制御プロトコルとして使われていて、KNX仕様の様々な製品が多くの製品ベンダーから提供されています。まず、どんな製品があるのか見てみましょう。

3.1  KNXの製品について

例えば「 KNX “wall switch” 」でGoogleのウェブ検索してみてください。約8,000件がヒットします。画像検索に切り替えると、機能本位のプラスチックでシンプルなものから、建物の内装に合わせた豪奢なものまで、多くのメーカーから製品が提供されていることが分かります。

上の写真では、KNXベンダー10社のKNXスイッチが並んでいます。
これらの製品表面上のオン・オフスイッチや、トグルスイッチのメカニズムの後ろに、そのオン・オフの状態やトグル状態をセンスするセンサーがあり、これらは、KNXのセンサーデバイスの1つということになります。
KNXのセンサーデバイスには、このようなPush-buttonタイプの他に、人感センサー、防犯センサー、温度センサー、照度センサーやタッチパネルの製品が各社から提供されています。ウェザーステーションとしていろいろな気象条件を検知するセンサー製品もあります。

次は、「KNX actuator」でGoogleのウェブ検索してみてください。約124,000件ヒットします。こちらは画像検索に切り替えてもあまり見かけ上魅力的な製品は見当たりませんが、どのような役割をするかは、このうち以下の図が分かりやすいでしょう。

図の上側左に、天井に設置した人感センサー(KNX presence detector)、右には壁に設置する多機能スイッチ(KNX multifunction push-button panel)があり、図の下側中央に防犯センサーとして、窓やドアの開閉を検知するセンサー(window contacts)につながった装置(KNX binary input module)が見えますが、これは、窓やドアが開いているか閉じているか、On/Off状態を他のKNXデバイスに伝えるためのものです。
検索対象だったアクチュエータについては、図下側右端に暖房装置のバルブを制御する装置(KNX heating actuator)と、中央に照明機器を制御する装置(KNX switch actuator)があります。

KNXアクチュエータの製品にも、このような暖房装置を制御したり、照明装置を単純にOn/Off制御したりするデバイスの他に、照度も制御できるディミングアクチュエータや、シャッター/ブラインドを制御するデバイス、エアコンに室温調整をするデバイスなどがあります。
KNXアクチュエータの他に、上図の左端にあるKNX用電源(KNX power supply)は、図中の緑色の線(KNX ツイストペアバスケーブル)に接続されたKNX製品に電力を供給するもので、これらのKNXシステム構築に必要なコンポーネントもKNX製品です。
その他にも、KNXネットワーク用ルータ/リピータと、他のプロトコルと連携するためのゲートウェイとなるKNX製品があります。

3.2 KNX製品間の制御メッセージ

先の図で、玄関につけた人感センサーで人の気配を感じると玄関の照明をつけるにはどうすれば良いでしょうか?単純に考えると、人感センサーと照明装置を物理的に配線すればよいですが、それでは、センサーと対で機能するアクチュエータごとに配線しなければならず、1組だけなら良いですが、複数のセンサー/アクチュエータを配線していくと、配線がスパゲティ状態になってしまいかねません。

それに対して、KNXでは、KNXデバイスはすべて論理的には1本のKNXバスにつながれており、そのバス上に、センサーが対となるアクチュエータにメッセージを送ることで制御します。

そのため、KNXセンサー、KNXアクチュエータには、それぞれマイクロプロセッサとメモリが備わっていて、センサーあるいはアクチュエータとして機能するプログラムと、制御する側/制御される側の相手情報をRAMに、KNXで規定された通信プロトコル処理をするプログラムをROMに保持しています。また、KNXバス上はシリアル通信なので、センサー側のKNXデバイスでは、マイクロプロセッサが作成した制御メッセージをシリアル変換する装置もKNXデバイスは保持しています。逆にアクチュエータ側のKNXデバイスでは、KNXバスからシリアル通信で受け取った制御メッセージをパラレル変換する装置を持ち、マイクロプロセッサが判断できるように変換し、必要に応じてアクチュエータの動作を起動します。

上図では、KNXデバイス:Aが温度センサーで、気温が28℃になるとMSG1をKNXデバイスDに送るようプログラムされています。(と言っても、実際にプログラムを組む訳ではなく、パラメタとして28℃のデータを設定することで、KNXデバイス:Aにそのような動きをさせることができるのです)
同様に、KNXデバイス:Dは、MSG1が届けばエアコンを起動するようにプログラムされています。(と言っても、こちらも実際にプログラムを組む訳ではなく、KNXデバイスAと論理的な関係が定義され、MSG1でエアコンを起動するよう、こちらもパラメタを変更するだけです)
KNXバス上は、上図の通り、KNXデバイス:BとCが存在しますが、MSG1の宛先アドレスが自分向けではないため、作動しません。

3.3 KNXデバイス間で授受されるメッセージの内部構造

ただ単に「KNXとはハウス・ビル制御用通信プロトコルである」と言われてもピンとこないと思いますが、3.1、3.2でご説明させていただいた通り、KNXデバイス間でメッセージを授受するための約束事(すなわちKNXの通信プロトコル)がKNXデバイスのROMに保持されており、KNXデバイス内のマイクロプロセッサは、そのROM内のプログラムを実行し、センサーからのメッセージを解釈して、アクチュエータが何らかの動作を起こすのだというKNXでの制御の流れを理解していただけたのではないかと思います。
では、そのメッセージの構造はどうなっているのか?おおざっぱに言うと次の通りです。

KNXの通信プロトコルの定義では、この図のようにメッセージ(あるいはテレグラム)はいくつかの部分から構成されていて、KNXバスに接続されたアクチュエータは、このメッセージの送信アドレスを見て自分宛てのメッセージでなければ無視します。なお、送信アドレスには、Eメールのグループアドレス相当の使い方ができるので、1つのKNXセンサーが1つのメッセージで複数のKNXアクチュエータにデータを送ることも可能です。
さて、メッセージが自分宛てだと判明した場合、KNXアクチュエータは、「秘密」の部分を適切に処理した後、メッセージ本体を調べます。
中には、「あなたの管理する照明を制御するスイッチがONになった(ので、照明をつけなさい)」というような意味のデータが、抽象化した形で入っています。
この例では、ON/Offを示す1ビットデータ型のデータで”1”がメッセージ本体に入っています。
例えば、玄関にある人感センサーが人の気配を感知して玄関照明用アクチュエータに「あなたの管理する照明をONにしなさい」とメッセージを送るのも、あらかじめ設定された室温に達したので温度センサーがエアコンの電源を入れるアクチュエータに対して「電源を入れなさい」とメッセージを送るのも、ON/Offを示す1ビットデータ型のデータで”1”をメッセージ本体として送ります。

KNXでは、このように、通信プロトコルレベルの標準化の他に、KNXデバイス間で授受するデータを、DPT(データポイントタイプ)として標準化しています。

 3.4  KNXとCENELEC 標準の関係

CENELEC(欧州電気標準化委員会)は、KNXをホーム・ビル制御の標準であるEN 50090に認定しています。少し詳しく内容を見ると以下の通りです。

1) アプリケーション
• EN50090-3-3:相互運用性とKNXの標準データタイプ(DPT)

2) 通信プロトコル
• EN50090-4-1:アプリケーションレイヤプロトコル
• EN50090-4-2:トランスポート/ネットワーク/データリンクレイヤプロトコル

3) 伝送メディア
• EN50090-5-1:KNX電力線通信(PL)
• EN50090-5-2:KNXツイストペア(TP)
• EN50090-5-3:KNX無線(RF)

4) システム管理
• EN50090-7-1:KNXマネジメント手続き

なお、KNX協会のCTOであるJoost Demarest氏の資料「International Standardization of Home and Building Automation」によると、EN 50090に関して、KNX協会はCENELECの「Cooperating Partner」であり、機能追加に関して委員会への「New Work Item proposal」を提出せず直接「standardization proposals」を提出する可能性がある(Possibility to submit⇒権利がある?)とされています。

3.5 KNXとCEN 標準の関係

CEN(欧州標準化委員会)は、KNXを3つの標準に指定しています。

まず、CENELECが認定したEN 50090の内容をEN 13321-1と認定するとともに、KNXnet/IPをEN 13321-2に、更に省エネビル向けの標準EN 15232にも認定しています。

なお、CENは、KNX以外に、LONWorks、BACnetもビルオートメーション制御システム(Building Automation Control System:BACS)標準として認定しています。

また、EUのスマートメーターに関する標準化指令M/441を受け、CENはスマートメーターインフラの参照アーキテクチャとして技術報告(Technical Report)TR50572を作成していますが、その中で、スマートメーターと住宅のインタフェースとしてEN 50090を参照しているようです。

 3.6 KNXと国際標準の関係

国際標準化団体である、国際標準化機構(International Organization for Standardization:ISO)と国際電気標準会議(International Electrotechnical Commission:IEC)の合同会議体であるISO/IEC JTC1では、家庭電子システム(Home Electronic System:HES)標準として、ISO/IEC 14543を定め、154543-3:KNX、14543-4:ECHONET、14543-5:IGRS(中国の家電制御標準)の3つを国際標準として認定しています。

これとは別に、ISOの技術委員会TC205では、BACS標準として、BACnetをISO 164484に認定しています。米国標準化団体ANSI/ASHRAEは、BACnetとKNXのマッピング仕様書をANSI/ASHRAE135に認定していましたが、ISOは、これをISO16484-5付録H1として採用しています。

なお、KNX協会はIECで系統制御機器とエネルギー管理システムの標準化を検討している技術委員会TC57内に新たに設けられた、(スマートグリッドと産業・ビル・ホームオートメーションのユースケース及びインタフェースを検討する)作業グループWG21にリエゾンを派遣しています。

本日は、ここまでとします。

通常、KNXの説明は、「ハウス・ビル制御プロトコルの国際標準である」というところから始まるのですが、今回、KNX製品からボトムアップ・アプローチで解説を試みました。

これでKNXの機能範囲が明確になったと(本人は)思いますので、次回はKNX Cityとスマートグリッドの関係について考えたいと思います。

最後に、今回もしつこく「第1回大阪KNX住宅・ビル制御テクノロジー・アプリケーションフォーラム」をご案内させていただきます。まだお席に余裕がございますので、皆様のご参加をお待ちしています。

第1回大阪KNX住宅・ビル制御テクノロジー・アプリケーションフォーラム
~ 現代都市生活のためのエコで快適な省エネ環境づくり ~

2014年10月17日(金) – 13:30開始

会場: ザ・リッツ・カールトン大阪

参加方法
フォーラム参加は無料です。案内状のダウンロードはこちらをクリックしてください。
職場や取引先の方にご自由に転送・配布していただいて結構です。

なお、席数は限られておりますのでご了承ください。準備の都合上、10月15日までに参加ご登録いただけますと幸いです。

KNXテクノロジー・アプリケーションフォーラムへの皆様のご参加を心よりお待ち申し上げております。

 

 

 

終わり