「BACnetを利用した組み込みシステム開発」

私はソフテックに入社してから、通信プロトコルのプログラムを多数開発してきました。
開発してきた通信プロトコルは大きく分けると2つの分類があります。

(1)の標準的な通信プロトコルはTCP/IPを用いたIPネットワーク上で使用されるものが多いと感じています。異なるネットワークの装置と通信する場合、汎用的な通信プロトコルであれば選択肢が増え、システムの将来的な可能性が広がります。そのため、標準的な通信プロトコルが採用されます。
(2)のメーカー独自の通信プロトコルはRS-232やRS-422など通信機器同士が直接接続される場合が多いと感じています。通信対象の機器に特化する必要がある場合や、通信相手が決まっている場合、既存から変更できないといった場合に独自プロトコルが採用されているように思います。

今回のソフテックだよりではビル管理システムの標準プロトコルとして使われているBACnet(Building Automation and Control Network)の紹介をしたいと思います。

1つのビルには様々なメーカーのシステムが導入されています。例えば照明器具はA社、冷暖房はB社、電気システムはC社、防災システムはD社などです。各メーカーは担当するシステムに応じた通信プロトコルで各種機器の制御を行っています。その通信プロトコルは各システムそれぞれ自由に策定することができます。そのため、A社とB社の機器を制御したいとなったとき、A社、B社間で通信プロトコルが異なるため、制御することができないという問題がありました。
このような問題を解決するため、ビル管理制御システム用の通信プロトコルとして、策定されたのがBACnetになります。各機器がBACnetを使うことにより、異なるメーカーのシステムであっても、監視制御を行うことが可能になりました。
BACnetのシステム構成としては以下のようになります。

図1. BACnetシステム構成

上記図では各システム(照明機器、防災機器、電気機器、空調機器、防犯機器)の制御装置のみがBACnetを備え、それが監視制御用装置とつながっている構成としています。このような構成をとることで、各システムの中にある各機器は独自プロトコルとして実装可能です。そのシステムの上位機器がBACnetを備えることで、他のシステムと連携が取れるようになります。

BACnetは1995年12月、アメリカ暖房冷凍空調学会(ASHRAE : American Society of Heating, Refrigerating and Air-Conditioning Engineers)がANSI/ASHRAE Standard 135-1995(BACnet135-1995)を策定し、全世界に普及しました。
その後、以下のように発展し、今でも規格の更新が行われ続けています。

※attendaは追加補足事項という意味です。

日本ではBACnetの普及段階において、日本電気設備学会(IEIE)により独自の拡張を加えた規格が存在します。以下の規格になります。

1.IEIEJpは日本電気設備学会(IEIE)により独自の拡張を加えたためか、標準のBACnet通信機器と相互接続ができないという問題があります。そのため、2002年に、2.IEIEJp-Aを策定しましたが、これでもまだ相互接続ができない問題があります。また、IEIEJp-AはIEIEJpとも相互接続ができないという問題を抱えています。
3.はBACnet135-2004をベースにIEIEJで独自に機能追加した内容にも対応しています。
上記のようにBACnetを採用する上で、何の規格を採用するのかが非常に重要になっています。

BACnetはデータの集合体であるオブジェクトとそれにアクセスするための操作として、サービスがあります。
BACnetで定義しているオブジェクトは全部で54種類(ASHRAE135-2012)もあります。一部ではありますが、以下のようなものがあります。

　 　　 　 　　 　 　　 　

オブジェクト名	用途
Analog Input Object Type	アナログ入力用
Analog Output Object Type	アナログ出力用
Analog Value Object Type	アナログ値用
Binary Input Object Type	2値データ入力用
Binary Output Object Type	2値データ出力用
Binary Value Object Type	2値データ用
Device Object Type	機器情報用
Multi-state Input Object Type	多値データ入力用
Multi-state Output Object Type	多値データ出力用
Multi-state Value Object Type	多値データ用
Calendar Object Type	カレンダー
File Object Type	ファイルアクセス
Event Enrollment Object Type	イベント通知

表1. BACnetオブジェクト

サービスに関しては以下のサービス群があります。

　 　　 　

分類	用途
アラームおよびイベントサービス	値の変化やイベントの通知を行うためのサービス
ファイル操作サービス	ファイル操作(Read/Writeなど)を行うためのサービス
オブジェクト操作サービス	オブジェクト操作(Read/Writeなど)を行うためのサービス
リモート装置管理サービス	クライアントBACnetユーザがBACnet装置の管理を行えるようにするためのサービス
仮想端末サービス	クライアントBACnetユーザが他のBACnet装置と連携し、端末エミュレータとして動作させるためのサービス

表2. BACnetサービス群

上記の他にもI-amサービス、Who-isサービスなどがあり、BACnetネットワークへの参加状態がわかるようになっています。BACnetネットワークに参加することを参入、BACnetネットワークから離脱することを離脱といいますが、この参入離脱シーケンスがうまくいかないと、他の機器がBACnetネットワークに入ったと認識できません。前述した各規格は参入離脱シーケンスが少しずつ異なるため、相互接続できないという問題があります。

弊社で実装したBACnet組み込みシステムの実装例を紹介します。

システム構成としては以下のようになります。

図2. システム構成

元々独自のネットワーク通信プロトコルで構築していたシステムにBACnet変換器を設置し他のBACnet装置と通信ができるようにしました。弊社の開発対象はBACnet変換器になります。
開発は大きく分けると以下となります。

開発する上で気にする点としては性能になります。
独自ネットワークは他のシステムと直接つながっていないため、上位システムからの要求が発生した場合、BACnet変換器を介する必要があります。状態取得要求などは頻繁に上位システムから送られる可能性があるため、毎回BACnet変換器が各種機器に対し状態取得要求を行うような作りとすると、かなりのタイムロスとなってしまいます。そのため、BACnet変換器は必要なものだけをBACnetのアドレスに割り当て、そのアドレスに割り当てた状態を保持するようにしています。機器の状態変化が発生した場合はイベントとして、上位システムに通知するようにしています。
ただ、状態制御要求の場合は機器に通知しないと機器が動作しないため、機器に通知をします。
以下は各種動作の流れについて記載しました。青線が独自プロトコルになります。ピンク線がBACnetになります。

図3. 状態取得要求時の動作

図4. 状態制御要求時の動作

図5. 状態変化時の動作

今回紹介したBACnetは私が今まで開発した通信プロトコルと違い、かなり特殊だなという印象を受けています。理由としては通信プロトコルに規格、バージョンがあり、それぞれが微妙に異なるという点です。多少のバージョンアップがある通信プロトコルはありますが、その時はコマンドが増える、通信フォーマットが拡張されるという類であり、それを気にすることはありませんでした。BACnetのように規格毎に互換性を意識する通信プロトコルがありませんでした。
BACnetの場合はバージョンアップを気にする必要があります。バーションアップした規格の名称、例えば最新だとBACnet2012になりますが、策定年数を名称に入れる通信プロトコル自体珍しいと思います。
なぜBACnetはそうなのかを考えると、ビル管理システムで使われる装置が多岐にわたり、それぞれが進化するため、それに合わせて通信プロトコルを更新していかないといけないからなのかなと思いました。例えば今のエアコンは私の小さい頃はクーラーでした。温度調節は弱中強のようなざっくりとしたものでした。今では当然暖房機能も備えていて、温度センサーで勝手に温度調節をしてくれたり、人がいるところに集中的に送風できたりとなっています。照明器具も明るさの調節は点灯させる蛍光灯の数で調節していました。今は照明器具自体で明るさを制御できます。BACnetは機器のバージョンアップに合わせ対応していく必要があるため、更新頻度が高いと感じています。
今後の更新で、基本的な部分は変わることはないと思いますが、新しいオブジェクト、新しいサービスが追加されていくので、どんな内容が追加されていくのかを追跡する必要があります。開発者の視点からすると、開発したら終わりという訳ではなく、息の長い通信プロトコルであると感じています。ただ、システム構築者の視点からすると、各種機器メーカーの制限なく、そのシステムに合わせた最適な機器を選定できるという非常に大きいメリットがあります。そのため、BACnetが策定されてから、短い期間で多くのシステムで採用されたのだろうと考えています。