IEIEJ-G-0006:2006 BACnet システム インターオペラビリティガイドライン

アデンダム aIEIEJ-G-0006:2006
BACnet®システムインターオペラビリティガイドライン
アデンダムａスケジュールオブジェクト，カレンダオブジェクトの運用ガイド
BAS 標準インターフェース仕様推進拡張委員会
BAS 標準インターフェース仕様推進拡張委員会による決定：
規格 ( IEIEJ - G - 0006 : 2006 )の変更 (Change to Standard (IEIEJ - G - 0006 : 2006)) :アデンダム a. スケジュールオブジェクト，カレンダオブジェクトの運用ガイド(原規格条文に対して変更追加がわかる変更履歴付とする。取り消し線は 1 本線，追加は斜体赤字で表現)
章，節まとめて追加する場合は，通常の書体で記述する。
）[4.2.5 スケジュールオブジェクト型(Schedule Object Type) 追加]
4.2.5 スケジュールオブジェクト型 (Schedule Object Type)
BACnet®-2004 では，スケジュールオブジェクトに関して，Present_Value の演算方法が定義され，Schedule_Default プロパティや Out_Of_Service プロパティが追加された。本項では，これらに対する解釈の相違により，各デバイスの動作が異なるなど，インターオペラビリティを確保する上で問題となり得る部分について，ガイドラインとしての解釈を示すとともに，スケジュールオブジェクトの振る舞いを定義する。
0B

4.2.5.1 スケジュールオブジェクト関連の推奨値についてインターオペラビリティを確保するため，スケジュールオブジェクト関連のオブジェクト数，ARRAY要素数などに関して，推奨値を示す。
2B

1) スケジュールオブジェクトの数 スケジュールオブジェクトをサポートするコントローラが，コントローラあたりに持つべきスケジュールオブジェクトのインスタンス数を以下のように定義する。
ひとつのコントローラにおいて，スケジュールで操作可能なプロパティの数≦ スケジュールオブジェクト数＊登録プロパティ数※という式が成り立つように，スケジュールオブジェクト数と各スケジュールに登録可能な登録プロパティ数を持つことが可能でなければならない。
※登録プロパティ数とは，ひとつのスケジュールオブジェクトあたり，オブジェクトプロパティの参照リスト(List_Of_Object_Property_Reference)プロパティに設定可能なリストの最大要素数のことを示す。
2)

Weekly_Schedule プロパティと Exception_Schedule プロパティのサポートについて BACnet®-2004 では，表 12-28. Schedule オブジェクト型のプロパティ群 や 12.24.7 週間スケジュール (Weekly_Schedule)に，”Schedule オブジェクトの各々のインスタンスは Weekly_Schedule か空でない Exception_Schedule のいずれかをサポートするものとする”と示されており，Exception_Schedule プロパティと Weekly_Scheduleプロパティのうち，どちらか 1 つを最低限サポートすることが要求されている。さらに，BACnet®-2004の K.3.2 においては，”SCHED-B に適合する装置は少なくとも１つのカレンダと１つのスケジュールオブジェクトを所有しなくてはならない”と示されており，Exception_Schedule の ARRAY 要素の最低限ひ1／5

IEIEJ-G-0006:2006 BACnet システム インターオペラビリティガイドライン

アデンダム a

とつをサポートすることが定められている。スケジュールオブジェクトが本来目的としている機能を実現すること，コントローラの自立性を確保しシステムの信頼性を向上させること，さらに，インターオペラビリティを確保することを目的として，当ガイドでは，スケジュールオブジェクトをサポートするコントローラは，Weekly_Schedule と Exception_Schedule の両方をサポートすることを推奨する。
3) Exception_Schedule の要素数について システムにおけるスケジュールオブジェクトの運用において，ARRAY 型のプロパティである Exception_Schedule プロパティに関して，各コントローラでサポートするARRAY の要素数が共通もしくは，ある値以上であることが望まれる。Exception_Schedule の ARRAY 要
素数は，一般のビルの運用を考慮した上で，当ガイドでは 10 以上を推奨する。10 の根拠は，7 曜日+休日+2 特異日として使用することを想定した上で 10 としている。しかし，その実装においては，7 曜日+休日+2 特異日の使用に限定するものではない。また，Exception_Schedule の ARRAY 要素の個々の Indexに対して，特定の意味づけを持たせるものではない。
4)

day-schedule，listOfTimeValues の要素数 Weekly_Schedule の day-schedule や Exception_Schedule のlistOfTimeValues のリスト要素数に関して，BACnet®-2004 の K.3.2 には，”スケジュールオブジェクトは１日に少なくとも６つの登録をサポートしなくてはならない”とある。当ガイドでは，規定のこの文章に従い，スケジュールオブジェクトをサポートするコントローラは，少なくとも 1 日あたり 6 つの要素数をサポートすることとする。BACnet®-2004 の規定では，Weekly_Schedule と，単一もしくは複数のException_Schedule の要素から，1 日のスケジュールを定義することが可能である。この BACnet®-2004の K.3.2 にある ”６つの登録”とは，ひとつずつの Weekly_Schedule の day-schedule の要素やException_Schedule の listOfTimeValues の要素数を示しているのではなく，1 日あたりの要素数を示していることに注意しなければならない。

4.2.5.2 Present_Valueプロパティの演算とコマンド出力について
スケジュールオブジェクトの Present_Value の演算については，BACnet®-2004 の 12.24.4 に示されており，詳細はここには定義しない。しかし，コマンド出力のタイミングに関しては，明確な記述が存在しない。当ガイドでは，解釈の統一を図るため，コマンド出力のタイミングを以下のように定める。
(a) BACnetTimeValue に指定されている時刻にコマンド出力をする。スケジュールオブジェクトのPresent_Value と BACnetTimeValue の Value に変化がなかった場合でも，BACnetTimeValue に設定された時刻には，コマンドを出力する。但し，BACnetTimeValue の time が 00:00 の場合は，スケジュールオブジェクトの Present_Value と BACnetTimeValue の value が同じ時はコマンドは出力しない。
(b) Present_Value の演算の結果，Schedule_Default を出力する場合は，Present_Value の値が変化したときのみコマンド出力をする。
3B

BACnet®-2004 では，BACnetTimeValue に含まれるコマンドの値として，NULL を定義している。
この NULLのコマンドと Schedule_Default プロパティに関して，当ガイドでの解釈を以下に示す。
・当ガイドでは，システムの制御を適切に設計できることを目的として，Schedule_Default に NULL を設定してはならないものとする。その理由を以下に示す。
Exception_Schedule の BACnetTimeValue に時刻とともに NULL が指定されていた場合，その指定された時刻に，該当の ARRAY 要素は，出力コマンドの候補から外れることを意味する。NULL とともに，指定された時刻の出力コマンドの演算には，次に優先される ARRAY 要素，NULL だった場合はWeekly_Schedule の設定，これも NULL なら最終的には，Schedule_Default の設定が出力される。
Schedule_Default が NULL であった場合，スケジュールオブジェクトからのコマンド出力が NULL となる。スケジュールオブジェクトからの出力が NULL となった場合，他のアプリケーションからの出力が有効になるか，もしくは，Relinquish_Default が有効になり，設備に対して，その値がコマンド出力される。システムのコマンドプライオリティの設計によっては，このような動作は，予期せぬ動作を引き起こすこととなり，制御機能の設計が管理しきれないものとなる。以上の理由から，Schedule_Default にNULL を設定する運用を禁止する。
2／5

IEIEJ-G-0006:2006 BACnet システム インターオペラビリティガイドライン

アデンダム a・Weekly_Schedule と Exception_Schedule との関係において，例えば Weekly_Schedule で 8:30 ON，17:00OFF となっているときに Exception_Schedule で 10:00 ON 18:00 OFF としたいケースを考えると，このケースを実現するには Exception_Schedule で 8:30 以前に OFF という設定をしておく必要がある。
この 8:30 以前の OFF は 8:30 以前に Exception_Schedule を有効にするためのもので，通常はその日はException_Scheduleで運用するということで，Exception_Scheduleで00:00 OFFとする運用が考えられる。
（a）によりこのような運用を可能とする。
・Scheule_Default により，Present_Value が決まるケースでは，Present_Value の値が変化した場合のみ，コマンド出力を行うこととする。これによって特に 00:00 の不要なコマンドの出力，それに伴う Notification等の不要なメッセージを抑制する。
・00:00 をまたいで継続し，かつ 00:00 に出力されているべき値が Schedule_Default の値と異なる値のスケジュールを組みたい場合，規定上，00:00 の TimeValue が必ず存在しなければならない。しかし，そうすると(b)に記述した通り，00:00 に必ず出力が発生することになり，本来，実施したい動作とはことなる。
また，00:00 に予期せぬコマンドが出力される可能性があり，これは，ビルの運用上，問題となる可能性がある。日替わりをまたいだスケジュールを実現するためには，コントローラ側で下記のSchedule_Default の振る舞いを可能とすることを推奨する。
Schedule_Default は R(Required)なので，必ずしも Writable である必要はない。Read Only とし，コントローラ内で，Schedule オブジェクトの PV が変化する都度 Schedule_Default を，その PV の値にすれば，Schedule_Default の目的は達成でき，00:00 に予期せぬコマンドが発生することも回避できる。
4.2.5.3 Exception_ScheduleとWeeklyScheduleの書込みについて
Weekly_Schedule プロパティ，Exception_Schedule プロパティへの書込みは，プロパティをすべて書込みするか，Index を指定して書込みをするか，どちらでも問題はないが，セグメンテーションの可能性を考慮すると，Index を指定して書込みをすることが望ましい。当ガイドでは，Index を指定して書込みを行うことを推奨する。
4B

4.2.5.4 Exception_Scheduleの Periodについて
Exception_Schedule の Period プロパティは，該当する日付，日付の範囲，曜日，もしくは，カレンダオブジェクトの参照を定義可能である。日付や日付の範囲を指定していた場合，該当する日付はすでに過去のものとなっており，システムの日付が変更されない限り，その Exception_Schedule の要素が無意味となっていることが考えられる。無意味となった Exception_Schedule の要素の削除は，B-OWS が行うこととする。日付の変更の可能性などにより，対象の Exception_Schedule が意味のあるものとなる可能性もあるため，スケジュールオブジェクトをサポートするコントローラでは，削除を行わない。日付や時刻を管理する B-OWS がそのような Exception_Schedule の要素の削除を行う。
5B

4.2.5.5 List_Of_Object_Property_Referenceプロパティについて
BACnet®-2004 で は 規 格 上 は 全 て の オ ブ ジ ェ ク ト の 全 て の 書 込 み 可 能 な プ ロ パ テ ィ は
List_Of_Object_Property_Reference の対象にできる。また，BTL ガイドラインには“10.3 Schedule objects should
not be used to schedule complex or proprietary data types.”という項目があり，少なくとも基本データ型のプロパティは対象にできる。しかし，これはすべての基本データ型プロパティのサポートを必須とするという意味ではなく，どれをサポートするかはベンダーマターである。ビルの運用上，最低限必要と考えられる BO，BV，MO，MV の Present_Value を対象とすることを推奨する。
また，単一のプロパティを複数のスケジュールオブジェクトの List_Of_Property_Reference に登録すること
は，B-OWS でのアプリケーションを考慮したとき，各設備のスケジュール設定を表現する上で，処理が煩雑となることから，避けることが望ましい。
6B

4.2.5.6 Out_Of_Serviceプロパティについてスケジュールオブジェクトの設定情報を保持したまま，一時的にスケジュール動作からの除外/再登録について，この Out_Of_Service プロパティを使用する。規定上 Writable である必要はないが，一時的にスケジュ
7B

3／5

IEIEJ-G-0006:2006 BACnet システム インターオペラビリティガイドラインアデンダム aールを動作させないようにする機能はビルの運用上，または調整上，必要となることが多い。Out_Of_Serviceは Writable とすることを推奨する。また，Out_Of_Service が TRUE であるときの動作は，BACnet®-2004 の12.24.14 に示されるとおりとする。以下にその内容を抜粋する。
”論理値型の Out_Of_Service プロパティは，スケジュールオブジェクトの内部演算が，Present_Value プロパティの値を決定する為に使用される(TRUE FALSE)か，されない(FALSETRUE)かを示す。これが意味すると
ころは，Out_Of_Service の値が TRUE である場合，Present_Value プロパティは内部演算から切り離され，Present_Value プロパティが他のプロパティの変化に追従しないということである。Out_Of_Service が TRUEのとき，List_Of_Object_Property_Reference のメンバへ値を書込むなど Present_Value に依存する他の機能は，まるで Present_Value の変化が内部演算により発生したかのように，その変化に応じて反応する。”
4.2.5.7 Priority_For_Writingプロパティについて
スケジュールオブジェクトのコマンド出力時のコマンド優先順位だけではなく，ひとつのシステムにおいて，コマンド優先順位は統一されていなければ，制御機能の設計は不可能である。BACnet®-2004 の Table 19-1に，標準のコマンド優先順位が定義されているが，ここには，スケジュールオブジェクトのコマンド出力時の優先順位が定義されていない。当ガイドラインでは，インターオペラビリティを確保する目的で，スケジュールオブジェクトの Priority_For_Writing の値を 8 とする。BACnet®-2004 では，Manual Operator のコマンド優先順位を 8 としているが，これと同じ値とする。オペレータのマニュアル操作の後，スケジュールからの出力により，機器が動作する必要があること，スケジュールからの出力の後，オペレータのマニュアル操作により，機器が動作する必要があることから，Manual Operator のコマンド優先順位と同じ値を推奨する。
8B

4.2.5.8 延長運転課金機能とスケジュールオブジェクトについて
延長運転課金機能とスケジュールオブジェクトの運用について，記述する。延長運転課金機能を実現する
B-OWS ベンダの，実現方法，考え方に依存するので，一意の実現方法をガイドラインで定めることには，無理があると判断されるため，ここでは，運用例を示すにとどめる。
これまで伝統的にコアタイムスケジュールとそれに対する追加運転という概念のベンダ以外に，コアタイムスケジュールが変更となるケースを休日スケジュールと休日カレンダ，特異日 1 スケジュールと特異日 1
カレンダ，特異日 2 スケジュールと特異日 2 カレンダという考え方で実現してきたベンダも存在する（特異日をいくつ持つかはベンダによって異なる）。さらに，カレンダはシステムで一括管理する必要があるので，マスタは B-OWS が管理し，必要としているコントローラに展開する必要がある。
以上の状況を踏まえて，以下は規定上運用の範囲とみなされるので，運用例として記述する。
9B

運用例 1
Weekly_Schedule をコアタイムスケジュールとして，この Device にとっての休日カレンダ NO. 特異日 1 カレンダ NO.，特異日 2 カレンダ NO. を予め定めて，Exception_Schedule で CalendarReference で指定した NO.で，休日，特異日 1，特異日 2 として扱う。
運用例 2
残業延長機能は全て OWS で行う。特異日という概念は B-OWS で管理する。

4／5

IEIEJ-G-0006:2006 BACnet システム インターオペラビリティガイドライン

アデンダム a[4.2.6 カレンダオブジェクト型(Calendar Object Type) 追加]
4.2.6 カレンダオブジェクト型
本項では，4.2.5. に示すスケジュールオブジェクトについての解釈に従い，インターオペラビリティを確保する上で，必要となると考えられるカレンダオブジェクトの制限事項について，記述する。
1B

4.2.6.1 カレンダオブジェクト関連の推奨値について
1) コントローラあたりのカレンダオブジェクト数について B-BC 毎に，サポートするべきカレンダオブジェクト数は，スケジュールで操作可能なプロパティ数/ 1 スケジュールあたりに登録可能なプロパティ数* 特異日の種類(休日を含む)で計算される。例えば，スケジュールで操作可能なプロパティの数が 1,000 であるコントローラにおいて，ひとつのスケジュールあたりに登録可能なプロパティ数が 30 オブジェクト，特異日の種類(休日を含む)が 3 種類であった場合，サポートするべきカレンダオブジェクトの数は，100 となる。
10B

2) カレンダオブジェクトあたりの Date_List プロパティの要素数について 実際のシステムにおいては，セグメンテーションをサポートしているデバイス，サポートしていないデバイスが混在する可能性が考えられ，また，セグメンテーションのサポートは，必須でないことを考慮し，当ガイドラインでは，
Date_List の要素数は，ReadPropertyMultiple，AddListElement，RemoveListElement などの通信メッセージにおいて，Max_APDU_Length を超えない範囲とする。ネットワーク層のヘッダの長さにも依存するが，Date_List の要素のデータ型が，Date であった場合，1 日あたり 5 バイトの長さで定義可能であり，約 200要素(200 日)を設定可能であり，先 1 年間のカレンダ設定を行うことを想定すると，十分な日数であると判断できる。200 日以上を設定したいケースがないとは言い切れないが，このようなケースが発生した
場合，Exception_Schedule の要素を複数使用して，複数のカレンダオブジェクトにより，機能を実現可能である。
4.2.6.2 カレンダのマスタについて
BACnet®-2004 規定においては，カレンダオブジェクトは，スケジュールオブジェクトの Exception_Scheduleの Period で参照されることを想定して定義されており，カレンダオブジェクトの各プロパティの設定は，コントローラ毎，スケジュールオブジェクト毎となっているが，実際のビルの運用においては，カレンダの設定は，複数のコントローラをまたいでビル全体で共通であるケースが多いと考えられる。当ガイドラインでは，基本的に，システムとして，一括でカレンダを管理するデバイスが存在するものとする。また，機能分散の観点から，カレンダを一括で管理するデバイスは，各コントローラへカレンダオブジェクトの設定を展開する機能を持つ必要がある。
1B

4.2.6.3 カレンダオブジェクトのDate_List要素のうち，経過した日付の要素の扱いについてカレンダオブジェクトの Date_List の要素は，該当する日付がすでに過去のものとなっており，システムの日付が変更されない限り，その日付の要素が無意味となっているものが考えられる。無意味となった
Date_List の要素の削除は，B-OWS が行うこととする。日付の変更の可能性などにより，対象の Date_List が意味のあるものとなる可能性もあるため，カレンダオブジェクトをサポートするコントローラでは，削除を行わない。日付や時刻を管理する B-OWS がそのような Date_List の要素の削除を行う。
12B

5／5