JP2003140996A - ＢＡＣｎｅｔメッセージ解析表示装置 - Google Patents
ＢＡＣｎｅｔメッセージ解析表示装置Info
- Publication number
- JP2003140996A JP2003140996A JP2001336182A JP2001336182A JP2003140996A JP 2003140996 A JP2003140996 A JP 2003140996A JP 2001336182 A JP2001336182 A JP 2001336182A JP 2001336182 A JP2001336182 A JP 2001336182A JP 2003140996 A JP2003140996 A JP 2003140996A
- Authority
- JP
- Japan
- Prior art keywords
- message
- data
- tag
- bacnet
- analysis
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Computer And Data Communications (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
(57)【要約】
【課題】 ＢＡＣｎｅｔメッセージを解析表示する装置
で、メッセージ種類の追加、メッセージ構文の変更、新
規ベンダの追加などに対して、新規解析ルーチンの作成
追加、既存解析ルーチンの変更を必要としなくて上記変
更に容易に対応できるようにする。 【解決手段】 ＢＡＣｎｅｔメッセージの種類とそのメ
ッセージ構文情報をデータベースとして持ち、これを参
照して解析表示をおこない、メッセージの種類およびメ
ッセージ構文の変更があった場合には、データベースに
追加あるいは変更を加えることで対応することを特徴と
するメッセージ解析表示装置。
で、メッセージ種類の追加、メッセージ構文の変更、新
規ベンダの追加などに対して、新規解析ルーチンの作成
追加、既存解析ルーチンの変更を必要としなくて上記変
更に容易に対応できるようにする。 【解決手段】 ＢＡＣｎｅｔメッセージの種類とそのメ
ッセージ構文情報をデータベースとして持ち、これを参
照して解析表示をおこない、メッセージの種類およびメ
ッセージ構文の変更があった場合には、データベースに
追加あるいは変更を加えることで対応することを特徴と
するメッセージ解析表示装置。
Description
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】本発明は、ビル監視制御シス
テムで使用されているメッセージ（ＢＡＣｎｅｔメッセ
ージ）を解析表示する装置に関するものである。 【０００２】 【従来の技術】ＢＡＣｎｅｔメッセージは、ビル管理シ
ステムにおいて、お互いの制御装置の間で、監視制御の
ための情報を交信するために使用されているメッセージ
である（以降単にメッセージと記す）。このメッセージ
は、ＢＡＣｎｅｔ抽象構文記法（ＡＳＮ．１）で定義さ
れ符号化されたものでありバイナリデータである（ＢＡ
Ｃｎｅｔメッセージの構成については後のセクション参
照）。したがってメッセージを補足しても人間が直接に
その内容を解読することはできない。また一般のプロト
コール解析表示装置はＢＡＣｎｅｔ抽象構文記法で符号
化された内容を解読する機能を持っていない。ＢＡＣｎ
ｅｔメッセージ解析表示装置は上記のメッセージを捕捉
して解析および復号化して人間にとって分かりやすくま
た規格との比較が容易にできる形式で表示する装置であ
る。 【０００３】ＢＡＣｎｅｔメッセージの構成およびＢＡ
Ｃｎｅｔメッセージ解析表示装置に要求される条件につ
いて説明する。ＢＡＣｎｅｔメッセージの文法、すなわ
ち抽象構文とその符号化・復号化規則は、ANSI/ASHRAE
STANDARD 135-1995 "A DataCommunication Protocol fo
r Building Automation and Control Networks"で規定
されている。これはＡＮＳＩ規格になっている。なお、
ASHRAEとはAmerican Society of Heating, Refrigerati
ng and Air-Conditioning Engineersの略語で米国冷暖
房空調学会を指す。メッセージの本体部分はアプリケー
ションデータユニットでありＢＡＣｎｅｔ_ＡＰＤＵと
呼ばれる。 【０００４】図９にＢＡＣｎｅｔ_ＡＰＤＵの構成を示
す。ＢＡＣｎｅｔ_ＡＰＤＵは固定部７と可変部８で構
成されている。固定部７は情報の内容と位置が固定され
ている部分でＢＡＣｎｅｔ_ＡＰＤＵのタイプ（ＡＰＤ
Ｕ＿ＴＹＰＵ）、サービス選択（ＳＣ）などが定義され
ている。可変部８はＢＡＣｎｅｔ抽象構文化記法で定義
および符号化されていて、情報の内容と位置が固定され
ていない部分である。個々の情報はデータ識別子（タ
グ）を使用して符号化されている。即ちタグデータ化さ
れている。 【０００５】ＢＡＣｎｅｔメッセージで使用されるデー
タには単純型データと構造型データの２種類のデータ型
がある。単純型データには、ＮＵＬＬ値、論理値、符号
無し整数値、符号付き整数値、実数値、倍精度実数値、
オクタル値、文字ストリング、ビットストリング、列挙
値、日、時、ＢＡＣｎｅｔオブジェクトＩＤなどこれ以
上に分解できないデータである。この型のデータはアプ
リケーションで決まっているタグあるいはコンテックス
トから決まるタグを付加することで符号化される（アプ
リケーションタグとコンテックストタグについては後の
セクション参照）。構造型データは単純型データおよび
構造型データの組み合わせから構成されるデータであ
る。この型のデータは開始タグと終了タグを使用するこ
とで符号化される。すなわち構造型データは開始タグで
始まり終了タグで終わる形式となる。この間にタグ化さ
れた単純型データおよび構造型データが挿入される。構
造型データではデータの階層化が可能である。この場合
には構造型データがタグ化された構造型データを含む形
式となる。 【０００６】ＢＡＣｎｅｔメッセージではアプリケーシ
ョンタグとコンテックストタグの２種類のタグが使用さ
れる。アプリケーションタグは基本的なデータ型の識別
に使用される。タグ番号からデータ型が一意的に識別で
きる。コンテックストタグは構文によって発生が決まる
データを識別するために使用される。タグはタグ番号値
という意味しか持たずタグ番号値だけからデータを一意
的に識別することはできない。タグ番号がどんなデータ
であるかはそのコンテックストタグが使用される位置
（構文情報）から決まる。すなわちコンテックストタグ
データの場合その構文情報を知らないとタグ番号からデ
ータ型を知ることはできない。コンテックストタグは必
要とされるデータだけを選択的に発生させることを可能
とする。なお構造型データで使用される開始タグと終了
タグはコンテックストタグに属するタグである。 【０００７】ＢＡＣｎｅｔメッセージでは、固定部７で
定義されている情報であるＡＰＤＵ＿ＴＹＰＥとＳＣの
組み合わせてメッセージの種類が定義される。現在約５
０種類のメッセージが定義されている。メッセージ種類
に対して可変部８では多数の構文即ち構文木が定義され
る。ＢＡＣｎｅｔメッセージ解析表示装置は発生可能な
全てのメッセージ構文についての解析表示機能をもつこ
とが要求される。 【０００８】図１０に従来のＢＡＣｎｅｔメッセージ解
析表示装置の構成図を示す。入力部１はメッセージを捕
捉して解析表示処理部２に渡す。解析表示処理部２はメ
ッセージを解析し表示の処理をする。表示部３では解析
結果を表示する。解析表示処理部２は固定部７を解析す
るルーチンと可変部８を解析するルーチンを持ってい
る。可変部８ではメッセージ種類ごとに決まるメッセー
ジ構文が使用されているため、これを解析するためには
メッセージの種類ごとにコンテックストタグでのタグ番
号とタグデータ情報との関連付けをおこなう必要があ
る。これに対応するためメッセージの種類ごとに、すな
わちメッセージ種類で決まる構文木ごとに解析ルーチン
を準備している。メッセージは最初に固定部７が解析さ
れメッセージ種類が特定される。次にメッセージ種類ご
とに準備された可変部解析ルーチンでメッセージがタグ
データ単位で切り出されて処理される。 【０００９】従来装置では、メッセージの種類が追加に
なったり、メッセージ構文が変更になったりするたび
に、新規解析ルーチンの作成追加や既存解析ルーチンの
変更が必要になっていた。一方ＢＡＣｎｅｔメッセージ
ではベンダがベンダ独自のプライベートメッセージを定
義して使用することが認められている。この場合には同
一メッセージ種類（プライベートメッセージ種類）でも
そのメッセージ構文はベンダごとに異なったものになっ
ている。従来装置でこのプライベートメッセージに対応
するためにはベンダの数だけプライベートメッセージ解
析ルーチンを実装しなければならなかった。新たにベン
ダが加わるごとに新規プライベートメッセージ解析ルー
チンの作成追加が必要になっていた。こうした新規解析
ルーチンの作成追加あるいは既存解析ルーチンの変更に
は工数と時間がかかるという問題点があった。 【００１０】 【発明が解決しようとする課題】本発明は、ＢＡＣｎｅ
ｔメッセージのメッセージ種類の追加、メッセージ構文
の変更、あるいは新規ベンダの追加に対して、新規解析
ルーチンの作成追加、既存解析ルーチンの変更を必要と
しなくて、上記変更に容易に対応できるＢＡＣｎｅｔメ
ッセージ解析表示装置を実現することを目的とする。 【００１１】 【課題を解決するための手段】ＢＡＣｎｅｔメッセージ
として発生可能なメッセージの構文情報をデータベース
として持ち、このデータベースを参照して解析表示をお
こない、メッセージの追加あるいは変更に対してはこの
データベースの変更で対応することを特徴とする。 【００１２】 【発明の実施の形態】図１は本発明装置の構成図を示
す。１は入力部でありメッセージを捕捉して２の解析表
示処理部に渡す。２は解析表示処理部であり入力部１で
取り込んだメッセージの解析表示の処理をおこなう。４
はメッセージの構文および符号化に関するメッセージデ
ータベース（以降は単にデータベースと記す）である。
解析表示処理部２はこのデータベースを参照して処理を
する。５と６はＢＡＣｎｅｔメッセージの定義文書であ
る。５はＢＡＣｎｅｔメッセージの抽象構文を定義する
ＢＡＣｎｅｔメッセージ抽象構文定義文書である。６は
ＢＡＣｎｅｔメッセージの符号・復号化を規則化するＢ
ＡＣｎｅｔメッセージ符号化・復号化規則文書である。 【００１３】現在データベース４は、ＢＡＣｎｅｔメッ
セージ抽象構文定義文書５とＢＡＣｎｅｔメッセージ符
号化・復号化規則文書６のＢＡＣｎｅｔメッセージ定義
文書から手動で作成されている。３は表示装置であり解
析した結果を人間に読みやすくまたメッセージ定義文書
と比較しやすい形式で表示する。 【００１４】 【実施例】以下、具体例をもとに構成と動作を説明す
る。図２、図３および図４はＢＡＣｎｅｔメッセージに
関する構文と符号化をデータベース化したものの一例で
あり、それぞれメッセージ構文テーブル、コンテックス
トタグ要素テーブル、列挙値テーブルと呼ぶ。ただし列
挙値テーブルは列挙値データの種類ごとに存在する。 【００１５】図２のメッセージ構文テーブルは発生可能
なメッセージ構文を検索に容易なようにテーブル化した
ものである。補足したメッセージを走査してコンテック
ストタグに遭遇したときこのメッセージ構文テーブルを
検索して、メッセージがどの構文に対応するものであ
り、コンテックストタグデータがどんなデータであるか
を識別するために使用する。１レコードには対象とする
コンテックストタグを発生させるまでに至るメッセージ
構文情報が定義されている。図２では一部のデータだけ
が掲載されている。 【００１６】ＢＡＣｎｅｔメッセージでは、メッセージ
が開始タグによって階層化されていること、そしてこの
開始タグの順列で決まる階層内では発生するコンテック
ストタグはユニークであること、すなわち同じ階層では
同じコンテックストタグ番号は１回しか発生しないこ
と、という特性がある。この特性を利用することでメッ
セージ構文木を２次元のメッセージ構文テーブルに展開
できる。コンテクストタグ発生に至るまでのメッセージ
構文は、ＡＰＤＵ＿ＴＹＰＥ、サービス選択（ＳＣ）、
対象とするコンテックストタグ発生までの階層化情報
（すなわち開始タグ番号の順列、その順列の要素数）、
およびコンテクストタグ番号を指定することで定義でき
る。ただしプライベートメッセージの場合にはベンダご
とに異なった構文が定義されるため、更にベンダＩＤ
（Ｖ＿ＩＤ）、サービス番号（Ｓ＿ＮＯ）の指定が必要
である。ベンダＩＤが０の値はＡＳＨＲＡＥ（米国冷暖
房空調学会）に割り当てられている特別なベンダＩＤ番
号であるがここではプライベートメッセージは使用され
ない。したがってメッセージ構文テーブル上では、ベン
ダＩＤが０の場合を一般メッセージと解釈するようにし
て、一般メッセージとプライベートメッセージと区別し
ないで扱うようにしている。図２で、Ｖ＿ＩＤとＳ＿Ｎ
Ｏはプライベートメッセージの場合でのベンダＩＤとサ
ービス番号を示す。プライベートメッセージ以外ではＶ
＿ＩＤとＳ＿ＮＯの値は常に０である。Ｔ０，Ｔ１，Ｔ
２，Ｔ３はコンテックストタグ発生に至るまでの開始タ
グ番号の順列、ＣＮＴはその順列要素数を示す。ＣＮＴ
はコンテックストタグ発生時での階層の深さ（レベル）
に一致する（レベルについては後セクション参照）。図
２では実運用上で支障が無いように４個の開始タグ番号
（Ｔ０、Ｔ１、Ｔ２、Ｔ３）まで定義できるようになっ
ている。但し、Ｔ０，Ｔ１，Ｔ２，Ｔ３は、全てが有効
であるのではなく先頭から（ＣＮＴ＋１）までが有効で
ある。ＣＮＴＸＴ＿ＴＡＧはコンテックストタグ番号を
示す。ＥＬ＿ＩＤはコンテックストタグ要素インデック
スを示す。これは図３のテーブルとリンクするためもの
である。メッセージを走査してコンテックストタグに遭
遇したとき、メッセージのＡＰＤＵ＿ＴＹＰＥ、ＳＣ、
Ｖ＿ＩＤ、Ｓ＿ＮＯ、階層化情報、コンテックストタグ
を検索パラメータにセットして、図２のメッセージ構文
テーブルを検索する。入力メッセージのパラメータに合
致するレコードが得られてそのレコードから対応するコ
ンテックストタグ要素インデックス（ＥＬ＿ＩＤ）が導
かれる。 【００１７】図３のコンテックストタグ要素テーブルは
図２のメッセージ構文テーブルを補足するもので、ＥＬ
＿ＩＤとタグデータ情報とを結びつけるものである。図
３で、ＴＡＧ＿ＴＹＰＥはコンテックストタグ種類（開
始タグ（OPEN）、終了タグ（CLOSE）、あるいはそれ以
外（０））、ＤＡＴＡ＿ＴＹＰＥはＢＡＣｎｅｔメッセ
ージ定義文書で定義されているデータのタイプ、ＤＥＳ
ＣＲＩＰＴＩＯＮはデータ名称、ＥＮＵＭ＿ＴＹＰＥ
は、もしデータタイプが列挙値型であるとき、列挙値の
データ種類に対応している列挙値テーブル番号を示す。
この値は図４の列挙値テーブルにリンクする。ＥＮＵＭ
＿ＴＹＰＥはデータが列挙値型の場合にだけ有効であ
る。図２で求められたＥＬ＿ＩＤを入力としてこれに一
致するレコードを検索して求める。得られたレコードか
らタグデータ情報が得られる。なお図３では一部のデー
タだけが掲載されている。 【００１８】図４の列挙値テーブルは、図３のコンテッ
クストタグ要素テーブルを補足するものであり、列挙値
に対してその列挙値データ名称を定義しているテーブル
である。この列挙値テーブルは列挙値データの種類だけ
存在する。したがって図３のコンテックストタグ要素テ
ーブルはデータ種類に対応した列挙値テーブル番号を指
定する。このテーブル番号の列挙値テーブルから列挙値
に対応した列挙値データ名称を得る。図４で、ＥＮＵＭ
＿ＶＡＬＵＥは列挙値であり、ＥＮＵＭ＿ＤＡＴＡ＿Ｄ
ＥＳＣＲＩＰＴＩＯＮは列挙値データ名称である。 【００１９】図５に解析表示処理のフロー図を示す。図
６には、図５でブロック化されたタグデータの解析表示
処理部分のフロー図を示す。解析処理はＡＰＤＵ固定部
分の解析とＡＰＤＵ可変部分の解析に分けられる。可変
部分はタグデータで符号化されているためタグデータを
順次切り出して処理をする。メッセージは開始タグによ
り階層化されている。この階層の深さをレベルという変
数で管理する。メッセージの最初ではレベル値を０とし
て、開始タグに遭遇するごとに１だけ加算して、終了タ
グに遭遇するごとに１だけ減算するものとする。 【００２０】図５のフロー図について説明する。最初は
ポインタをメッセージの先頭にセットする。解析対象の
メッセージの全体の長さを記憶する。はじめに固定部を
走査して解析表示する。ＡＰＤＵ＿ＴＹＰＥ、ＳＣを記
憶する。次に可変部の解析に移る。可変部の走査の始め
でレベルを０にセットする。タグ情報からタグデータの
長さが分かるからこのデータ（タグデータ）を切り出
す。ポインタをタグデータの長さだけ進める。切り出し
たタグデータに応じて下記の処理をする。開始タグの場
合タグデータ解析表示処理（図６の処理）をしてからレ
ベルを１だけ加算する。即ち階層の深さを１だけ増加さ
せる。また開始タグ番号を開始タグ番号の順列として記
憶する。終了タグの場合にはレベルを１だけ減算してか
らタグデータ解析表示処理（図６の処理）をする。記憶
されている開始タグ番号の順列の最後の番号を削除す
る。それ以外のタグの場合には階層化情報に対する処理
は不要でありタグデータ解析表示処理（図６の処理）だ
けをする。ポインタがメッセージの最後を過ぎたかどう
かをチェックして最後をすぎたときは解析表示処理を終
了する。まだ最後を過ぎていないときはタグデータの切
り出し処理部に戻って処理を続ける。 【００２１】図６は切り出したタグデータを解析表示す
る部分のフロー図を示す。切り出したタグがアプリケー
ションタグがコンテックストタグかで処理を分岐する。
アプリケーションタグの場合、タグ番号とデータ情報は
固定であるからデータタイプとデータ値を求め人間に読
みやすい形式で表示するだけである。コンテックストタ
グの場合にはタグ番号からは直接にデータタイプ、デー
タ名称が求められないから図２のメッセージ構文テーブ
ルを検索して求めるようにする。ＡＰＤＵ＿ＴＹＰＥと
ＳＣからプライベートメッセージであるかどうかを判定
する。以下の３つのケースがプライベートメッセージに
該当する。（１）ＡＰＤＵ＿ＴＹＰＥ＝０でＳＣ＝１８
のとき、Confirmed Private Transferメッセージ。
（２）ＡＰＤＵ＿ＴＹＰＥ＝１でＳＣ＝４のとき、Unco
nfirmed Private Transfer メッセージ。（３）ＡＰＤ
Ｕ＿ＴＹＰＥ＝３でＳＣ＝１８のとき、Complex Ack fo
r Confirmed Private Transferメッセージ。上記プライ
ベートメッセージのときにはベンダＩＤ（Ｖ＿ＩＤ）と
サービス番号（Ｓ＿ＮＯ）を知る必要がある。Ｖ＿ＩＤ
とＳ＿ＮＯの双方がすでに決定済みかどうか（双方が０
でないかどうか）を判定する。決定済みの場合には一般
メッセージの処理に飛ぶ。未決定の場合にはタグデータ
からＶ＿ＩＤとＳ＿ＮＯを決定する。ＢＡＣｎｅｔメッ
セージ仕様によりこの時点で発生するコンテックストタ
グ番号は０か１である。タグ番号０はＶ＿ＩＤのデータ
を、タグ番号１はＳ＿ＮＯのデータを符号化したもので
ある。このタグ番号によって、Ｖ＿ＩＤ決定処理あるい
はＳ＿ＮＯ決定処理をしてタグデータを表示する。一般
メッセージでは、ＡＰＤＵ＿ＴＹＰＥ、ＳＣ、Ｖ＿Ｉ
Ｄ、Ｓ＿ＮＯ、Ｔ０，Ｔ１，Ｔ２，Ｔ３、ＣＮＴ、コン
テックストタグ番号を検索パラメータ入力として図２の
テーブルを検索して対応するメッセージ構文のレコード
を求める。ただしこのときプライベートメッセージ以外
では検索パラメータ上でＶ＿ＩＤとＳ＿ＮＯは常に０に
セットされる。検索によって得られたレコードからＥＬ
＿ＩＤを求めて更に図３のテーブルを検索することによ
り切り出したコンテックストタグのタグ番号に対応する
タグデータ情報（データタイプ、データ値、データ名
称）を求める。データが列挙型の場合には更に図４の列
挙値テーブルを検索することで列挙値データに対する列
挙値データ名称を求める。こうして求めた結果を人間に
読みやすい形式で表示する。 【００２２】図５および図６のフロー図によってメッセ
ージを先頭から走査してタグデータの発生ごとにタグデ
ータを順次切り出して解析していく。順次得られたデー
タタイプ、データ値、データ名称、列挙値データ名称の
結果を、元のバイナリデータとの比較が容易、抽象構文
記法での文書と比較が容易、さらに人間にも読みやすい
形式で表示する。 【００２３】図７と図８に本発明での解析表示装置での
表示結果を示す。上段部ウィンドウは補足したメッセー
ジを一覧表示する。中段部ウインドウは一覧表示から選
択したメッセージに対して詳細表示する。左側にはバイ
ナリデータを１６進表示し、右側にはこれを解析したタ
グデータを階層化して表示する。この表示形式はＢＡＣ
ｎｅｔメッセージ定義文書に準拠している。従って補足
したメッセージがＢＡＣｎｅｔメッセージ定義に合致し
ているかの比較が容易にできるようになっている。下段
部ウインドウは選択したメッセージを単純に１６進表示
してデバッグ用に使用される。 【００２４】図７は以下のように処理され表示されてい
る。ＡＰＤＵ＿ＴＹＰＥが０でＳＣが１２であることか
らRead Propertyメッセージであることがわかる。最初
のコンテックストタグ（タグ番号＝０）はレベル０で発
生している。図２を検索してＥＬ＿ＩＤが２４５である
ことが分かる。図３を検索して、このタグ情報は、デー
タタイプはＢＡＣ＿ＯＩＤ（ＢＡＣｎｅｔオブジェクト
ＩＤ）であり、データ名称は"Destination Object ID"
であることが分かる。図８は以下のように処理され表示
されている。ＡＰＤＵ＿ＴＹＰＥが３でＳＣが１２であ
ることからComplex Ack for Read Propertyメッセージ
であることがわかる。最初のコンテックストタグ（タグ
番号＝０）はレベル０で発生している。図２を検索して
ＥＬ＿ＩＤが２４５であることが分かる。図３を検索し
て、このタグ情報は、データタイプはＢＡＣ＿ＯＩＤで
あり、データ名称は"Destination Object ID"であるこ
とが分かる。２番目のコンテックストタグ（タグ番号＝
１）もレベル０で発生している。図２を検索してＥＬ＿
ＩＤが１５０であることが分かる。図３を検索して、こ
のタグ情報は、データタイプはＥＮＵＭ（列挙値）であ
り、データ名称は"Attribute ID"、であることが分か
る。ＥＮＵＭ＿ＴＹＰＥが１５であるから、これ（１
５）に対応する図４の列挙値テーブルを検索する。列挙
値６２に対応する列挙値データ名称"MAX APDU Length A
ccepted"が分かる。 【００２５】以下、本発明の応用例について説明する。
メッセージデータベースを処理プログラムと分離して外
部データベースとすることができる。この場合メモリデ
ータベースに比べて処理は多少遅くなるがデータベース
を修正しても処理プログラム側では結合処理をする必要
が無くなり、メッセージ構文の変更、即ちデータベース
の変更に対して更に柔軟に対応できるようになる。 【００２６】実施例でのデータベースはＢＡＣｎｅｔメ
ッセージ定義文書を参照して手動で作成されている。電
子化されたＢＡＣｎｅｔメッセージ定義文書から自動的
にデータベースを生成することも可能である。この場合
メッセージ構文の変更に対して更に柔軟に対応できるよ
うになる。 【００２７】 【発明の効果】ＢＡＣｎｅｔメッセージとして発生可能
なメッセージの構文情報をデータベースとして持ち、こ
のデータベースを参照して解析表示をおこなうという構
成によってメッセージ種類ごとに処理ルーチンを作成す
る必要がなくなる。メッセージの種類の追加、メッセー
ジ構文の変更が発生したときにはデータベースに変更を
加えるだけで対応できるようになる。プライベートメッ
セージはベンダごとに定義されるものでありメッセージ
構文はベンダごとに異なっている。このプライベートメ
ッセージの追加あるいは変更に対してもデータベースに
情報を追加あるいは変更を加えるだけで対応できるよう
になる。データベースを外部データベースとして持つこ
とによりデータベース変更に際してプログラムの再結合
処理が不要になりより柔軟にメッセージ変更に対応でき
るようになる。
テムで使用されているメッセージ（ＢＡＣｎｅｔメッセ
ージ）を解析表示する装置に関するものである。 【０００２】 【従来の技術】ＢＡＣｎｅｔメッセージは、ビル管理シ
ステムにおいて、お互いの制御装置の間で、監視制御の
ための情報を交信するために使用されているメッセージ
である（以降単にメッセージと記す）。このメッセージ
は、ＢＡＣｎｅｔ抽象構文記法（ＡＳＮ．１）で定義さ
れ符号化されたものでありバイナリデータである（ＢＡ
Ｃｎｅｔメッセージの構成については後のセクション参
照）。したがってメッセージを補足しても人間が直接に
その内容を解読することはできない。また一般のプロト
コール解析表示装置はＢＡＣｎｅｔ抽象構文記法で符号
化された内容を解読する機能を持っていない。ＢＡＣｎ
ｅｔメッセージ解析表示装置は上記のメッセージを捕捉
して解析および復号化して人間にとって分かりやすくま
た規格との比較が容易にできる形式で表示する装置であ
る。 【０００３】ＢＡＣｎｅｔメッセージの構成およびＢＡ
Ｃｎｅｔメッセージ解析表示装置に要求される条件につ
いて説明する。ＢＡＣｎｅｔメッセージの文法、すなわ
ち抽象構文とその符号化・復号化規則は、ANSI/ASHRAE
STANDARD 135-1995 "A DataCommunication Protocol fo
r Building Automation and Control Networks"で規定
されている。これはＡＮＳＩ規格になっている。なお、
ASHRAEとはAmerican Society of Heating, Refrigerati
ng and Air-Conditioning Engineersの略語で米国冷暖
房空調学会を指す。メッセージの本体部分はアプリケー
ションデータユニットでありＢＡＣｎｅｔ_ＡＰＤＵと
呼ばれる。 【０００４】図９にＢＡＣｎｅｔ_ＡＰＤＵの構成を示
す。ＢＡＣｎｅｔ_ＡＰＤＵは固定部７と可変部８で構
成されている。固定部７は情報の内容と位置が固定され
ている部分でＢＡＣｎｅｔ_ＡＰＤＵのタイプ（ＡＰＤ
Ｕ＿ＴＹＰＵ）、サービス選択（ＳＣ）などが定義され
ている。可変部８はＢＡＣｎｅｔ抽象構文化記法で定義
および符号化されていて、情報の内容と位置が固定され
ていない部分である。個々の情報はデータ識別子（タ
グ）を使用して符号化されている。即ちタグデータ化さ
れている。 【０００５】ＢＡＣｎｅｔメッセージで使用されるデー
タには単純型データと構造型データの２種類のデータ型
がある。単純型データには、ＮＵＬＬ値、論理値、符号
無し整数値、符号付き整数値、実数値、倍精度実数値、
オクタル値、文字ストリング、ビットストリング、列挙
値、日、時、ＢＡＣｎｅｔオブジェクトＩＤなどこれ以
上に分解できないデータである。この型のデータはアプ
リケーションで決まっているタグあるいはコンテックス
トから決まるタグを付加することで符号化される（アプ
リケーションタグとコンテックストタグについては後の
セクション参照）。構造型データは単純型データおよび
構造型データの組み合わせから構成されるデータであ
る。この型のデータは開始タグと終了タグを使用するこ
とで符号化される。すなわち構造型データは開始タグで
始まり終了タグで終わる形式となる。この間にタグ化さ
れた単純型データおよび構造型データが挿入される。構
造型データではデータの階層化が可能である。この場合
には構造型データがタグ化された構造型データを含む形
式となる。 【０００６】ＢＡＣｎｅｔメッセージではアプリケーシ
ョンタグとコンテックストタグの２種類のタグが使用さ
れる。アプリケーションタグは基本的なデータ型の識別
に使用される。タグ番号からデータ型が一意的に識別で
きる。コンテックストタグは構文によって発生が決まる
データを識別するために使用される。タグはタグ番号値
という意味しか持たずタグ番号値だけからデータを一意
的に識別することはできない。タグ番号がどんなデータ
であるかはそのコンテックストタグが使用される位置
（構文情報）から決まる。すなわちコンテックストタグ
データの場合その構文情報を知らないとタグ番号からデ
ータ型を知ることはできない。コンテックストタグは必
要とされるデータだけを選択的に発生させることを可能
とする。なお構造型データで使用される開始タグと終了
タグはコンテックストタグに属するタグである。 【０００７】ＢＡＣｎｅｔメッセージでは、固定部７で
定義されている情報であるＡＰＤＵ＿ＴＹＰＥとＳＣの
組み合わせてメッセージの種類が定義される。現在約５
０種類のメッセージが定義されている。メッセージ種類
に対して可変部８では多数の構文即ち構文木が定義され
る。ＢＡＣｎｅｔメッセージ解析表示装置は発生可能な
全てのメッセージ構文についての解析表示機能をもつこ
とが要求される。 【０００８】図１０に従来のＢＡＣｎｅｔメッセージ解
析表示装置の構成図を示す。入力部１はメッセージを捕
捉して解析表示処理部２に渡す。解析表示処理部２はメ
ッセージを解析し表示の処理をする。表示部３では解析
結果を表示する。解析表示処理部２は固定部７を解析す
るルーチンと可変部８を解析するルーチンを持ってい
る。可変部８ではメッセージ種類ごとに決まるメッセー
ジ構文が使用されているため、これを解析するためには
メッセージの種類ごとにコンテックストタグでのタグ番
号とタグデータ情報との関連付けをおこなう必要があ
る。これに対応するためメッセージの種類ごとに、すな
わちメッセージ種類で決まる構文木ごとに解析ルーチン
を準備している。メッセージは最初に固定部７が解析さ
れメッセージ種類が特定される。次にメッセージ種類ご
とに準備された可変部解析ルーチンでメッセージがタグ
データ単位で切り出されて処理される。 【０００９】従来装置では、メッセージの種類が追加に
なったり、メッセージ構文が変更になったりするたび
に、新規解析ルーチンの作成追加や既存解析ルーチンの
変更が必要になっていた。一方ＢＡＣｎｅｔメッセージ
ではベンダがベンダ独自のプライベートメッセージを定
義して使用することが認められている。この場合には同
一メッセージ種類（プライベートメッセージ種類）でも
そのメッセージ構文はベンダごとに異なったものになっ
ている。従来装置でこのプライベートメッセージに対応
するためにはベンダの数だけプライベートメッセージ解
析ルーチンを実装しなければならなかった。新たにベン
ダが加わるごとに新規プライベートメッセージ解析ルー
チンの作成追加が必要になっていた。こうした新規解析
ルーチンの作成追加あるいは既存解析ルーチンの変更に
は工数と時間がかかるという問題点があった。 【００１０】 【発明が解決しようとする課題】本発明は、ＢＡＣｎｅ
ｔメッセージのメッセージ種類の追加、メッセージ構文
の変更、あるいは新規ベンダの追加に対して、新規解析
ルーチンの作成追加、既存解析ルーチンの変更を必要と
しなくて、上記変更に容易に対応できるＢＡＣｎｅｔメ
ッセージ解析表示装置を実現することを目的とする。 【００１１】 【課題を解決するための手段】ＢＡＣｎｅｔメッセージ
として発生可能なメッセージの構文情報をデータベース
として持ち、このデータベースを参照して解析表示をお
こない、メッセージの追加あるいは変更に対してはこの
データベースの変更で対応することを特徴とする。 【００１２】 【発明の実施の形態】図１は本発明装置の構成図を示
す。１は入力部でありメッセージを捕捉して２の解析表
示処理部に渡す。２は解析表示処理部であり入力部１で
取り込んだメッセージの解析表示の処理をおこなう。４
はメッセージの構文および符号化に関するメッセージデ
ータベース（以降は単にデータベースと記す）である。
解析表示処理部２はこのデータベースを参照して処理を
する。５と６はＢＡＣｎｅｔメッセージの定義文書であ
る。５はＢＡＣｎｅｔメッセージの抽象構文を定義する
ＢＡＣｎｅｔメッセージ抽象構文定義文書である。６は
ＢＡＣｎｅｔメッセージの符号・復号化を規則化するＢ
ＡＣｎｅｔメッセージ符号化・復号化規則文書である。 【００１３】現在データベース４は、ＢＡＣｎｅｔメッ
セージ抽象構文定義文書５とＢＡＣｎｅｔメッセージ符
号化・復号化規則文書６のＢＡＣｎｅｔメッセージ定義
文書から手動で作成されている。３は表示装置であり解
析した結果を人間に読みやすくまたメッセージ定義文書
と比較しやすい形式で表示する。 【００１４】 【実施例】以下、具体例をもとに構成と動作を説明す
る。図２、図３および図４はＢＡＣｎｅｔメッセージに
関する構文と符号化をデータベース化したものの一例で
あり、それぞれメッセージ構文テーブル、コンテックス
トタグ要素テーブル、列挙値テーブルと呼ぶ。ただし列
挙値テーブルは列挙値データの種類ごとに存在する。 【００１５】図２のメッセージ構文テーブルは発生可能
なメッセージ構文を検索に容易なようにテーブル化した
ものである。補足したメッセージを走査してコンテック
ストタグに遭遇したときこのメッセージ構文テーブルを
検索して、メッセージがどの構文に対応するものであ
り、コンテックストタグデータがどんなデータであるか
を識別するために使用する。１レコードには対象とする
コンテックストタグを発生させるまでに至るメッセージ
構文情報が定義されている。図２では一部のデータだけ
が掲載されている。 【００１６】ＢＡＣｎｅｔメッセージでは、メッセージ
が開始タグによって階層化されていること、そしてこの
開始タグの順列で決まる階層内では発生するコンテック
ストタグはユニークであること、すなわち同じ階層では
同じコンテックストタグ番号は１回しか発生しないこ
と、という特性がある。この特性を利用することでメッ
セージ構文木を２次元のメッセージ構文テーブルに展開
できる。コンテクストタグ発生に至るまでのメッセージ
構文は、ＡＰＤＵ＿ＴＹＰＥ、サービス選択（ＳＣ）、
対象とするコンテックストタグ発生までの階層化情報
（すなわち開始タグ番号の順列、その順列の要素数）、
およびコンテクストタグ番号を指定することで定義でき
る。ただしプライベートメッセージの場合にはベンダご
とに異なった構文が定義されるため、更にベンダＩＤ
（Ｖ＿ＩＤ）、サービス番号（Ｓ＿ＮＯ）の指定が必要
である。ベンダＩＤが０の値はＡＳＨＲＡＥ（米国冷暖
房空調学会）に割り当てられている特別なベンダＩＤ番
号であるがここではプライベートメッセージは使用され
ない。したがってメッセージ構文テーブル上では、ベン
ダＩＤが０の場合を一般メッセージと解釈するようにし
て、一般メッセージとプライベートメッセージと区別し
ないで扱うようにしている。図２で、Ｖ＿ＩＤとＳ＿Ｎ
Ｏはプライベートメッセージの場合でのベンダＩＤとサ
ービス番号を示す。プライベートメッセージ以外ではＶ
＿ＩＤとＳ＿ＮＯの値は常に０である。Ｔ０，Ｔ１，Ｔ
２，Ｔ３はコンテックストタグ発生に至るまでの開始タ
グ番号の順列、ＣＮＴはその順列要素数を示す。ＣＮＴ
はコンテックストタグ発生時での階層の深さ（レベル）
に一致する（レベルについては後セクション参照）。図
２では実運用上で支障が無いように４個の開始タグ番号
（Ｔ０、Ｔ１、Ｔ２、Ｔ３）まで定義できるようになっ
ている。但し、Ｔ０，Ｔ１，Ｔ２，Ｔ３は、全てが有効
であるのではなく先頭から（ＣＮＴ＋１）までが有効で
ある。ＣＮＴＸＴ＿ＴＡＧはコンテックストタグ番号を
示す。ＥＬ＿ＩＤはコンテックストタグ要素インデック
スを示す。これは図３のテーブルとリンクするためもの
である。メッセージを走査してコンテックストタグに遭
遇したとき、メッセージのＡＰＤＵ＿ＴＹＰＥ、ＳＣ、
Ｖ＿ＩＤ、Ｓ＿ＮＯ、階層化情報、コンテックストタグ
を検索パラメータにセットして、図２のメッセージ構文
テーブルを検索する。入力メッセージのパラメータに合
致するレコードが得られてそのレコードから対応するコ
ンテックストタグ要素インデックス（ＥＬ＿ＩＤ）が導
かれる。 【００１７】図３のコンテックストタグ要素テーブルは
図２のメッセージ構文テーブルを補足するもので、ＥＬ
＿ＩＤとタグデータ情報とを結びつけるものである。図
３で、ＴＡＧ＿ＴＹＰＥはコンテックストタグ種類（開
始タグ（OPEN）、終了タグ（CLOSE）、あるいはそれ以
外（０））、ＤＡＴＡ＿ＴＹＰＥはＢＡＣｎｅｔメッセ
ージ定義文書で定義されているデータのタイプ、ＤＥＳ
ＣＲＩＰＴＩＯＮはデータ名称、ＥＮＵＭ＿ＴＹＰＥ
は、もしデータタイプが列挙値型であるとき、列挙値の
データ種類に対応している列挙値テーブル番号を示す。
この値は図４の列挙値テーブルにリンクする。ＥＮＵＭ
＿ＴＹＰＥはデータが列挙値型の場合にだけ有効であ
る。図２で求められたＥＬ＿ＩＤを入力としてこれに一
致するレコードを検索して求める。得られたレコードか
らタグデータ情報が得られる。なお図３では一部のデー
タだけが掲載されている。 【００１８】図４の列挙値テーブルは、図３のコンテッ
クストタグ要素テーブルを補足するものであり、列挙値
に対してその列挙値データ名称を定義しているテーブル
である。この列挙値テーブルは列挙値データの種類だけ
存在する。したがって図３のコンテックストタグ要素テ
ーブルはデータ種類に対応した列挙値テーブル番号を指
定する。このテーブル番号の列挙値テーブルから列挙値
に対応した列挙値データ名称を得る。図４で、ＥＮＵＭ
＿ＶＡＬＵＥは列挙値であり、ＥＮＵＭ＿ＤＡＴＡ＿Ｄ
ＥＳＣＲＩＰＴＩＯＮは列挙値データ名称である。 【００１９】図５に解析表示処理のフロー図を示す。図
６には、図５でブロック化されたタグデータの解析表示
処理部分のフロー図を示す。解析処理はＡＰＤＵ固定部
分の解析とＡＰＤＵ可変部分の解析に分けられる。可変
部分はタグデータで符号化されているためタグデータを
順次切り出して処理をする。メッセージは開始タグによ
り階層化されている。この階層の深さをレベルという変
数で管理する。メッセージの最初ではレベル値を０とし
て、開始タグに遭遇するごとに１だけ加算して、終了タ
グに遭遇するごとに１だけ減算するものとする。 【００２０】図５のフロー図について説明する。最初は
ポインタをメッセージの先頭にセットする。解析対象の
メッセージの全体の長さを記憶する。はじめに固定部を
走査して解析表示する。ＡＰＤＵ＿ＴＹＰＥ、ＳＣを記
憶する。次に可変部の解析に移る。可変部の走査の始め
でレベルを０にセットする。タグ情報からタグデータの
長さが分かるからこのデータ（タグデータ）を切り出
す。ポインタをタグデータの長さだけ進める。切り出し
たタグデータに応じて下記の処理をする。開始タグの場
合タグデータ解析表示処理（図６の処理）をしてからレ
ベルを１だけ加算する。即ち階層の深さを１だけ増加さ
せる。また開始タグ番号を開始タグ番号の順列として記
憶する。終了タグの場合にはレベルを１だけ減算してか
らタグデータ解析表示処理（図６の処理）をする。記憶
されている開始タグ番号の順列の最後の番号を削除す
る。それ以外のタグの場合には階層化情報に対する処理
は不要でありタグデータ解析表示処理（図６の処理）だ
けをする。ポインタがメッセージの最後を過ぎたかどう
かをチェックして最後をすぎたときは解析表示処理を終
了する。まだ最後を過ぎていないときはタグデータの切
り出し処理部に戻って処理を続ける。 【００２１】図６は切り出したタグデータを解析表示す
る部分のフロー図を示す。切り出したタグがアプリケー
ションタグがコンテックストタグかで処理を分岐する。
アプリケーションタグの場合、タグ番号とデータ情報は
固定であるからデータタイプとデータ値を求め人間に読
みやすい形式で表示するだけである。コンテックストタ
グの場合にはタグ番号からは直接にデータタイプ、デー
タ名称が求められないから図２のメッセージ構文テーブ
ルを検索して求めるようにする。ＡＰＤＵ＿ＴＹＰＥと
ＳＣからプライベートメッセージであるかどうかを判定
する。以下の３つのケースがプライベートメッセージに
該当する。（１）ＡＰＤＵ＿ＴＹＰＥ＝０でＳＣ＝１８
のとき、Confirmed Private Transferメッセージ。
（２）ＡＰＤＵ＿ＴＹＰＥ＝１でＳＣ＝４のとき、Unco
nfirmed Private Transfer メッセージ。（３）ＡＰＤ
Ｕ＿ＴＹＰＥ＝３でＳＣ＝１８のとき、Complex Ack fo
r Confirmed Private Transferメッセージ。上記プライ
ベートメッセージのときにはベンダＩＤ（Ｖ＿ＩＤ）と
サービス番号（Ｓ＿ＮＯ）を知る必要がある。Ｖ＿ＩＤ
とＳ＿ＮＯの双方がすでに決定済みかどうか（双方が０
でないかどうか）を判定する。決定済みの場合には一般
メッセージの処理に飛ぶ。未決定の場合にはタグデータ
からＶ＿ＩＤとＳ＿ＮＯを決定する。ＢＡＣｎｅｔメッ
セージ仕様によりこの時点で発生するコンテックストタ
グ番号は０か１である。タグ番号０はＶ＿ＩＤのデータ
を、タグ番号１はＳ＿ＮＯのデータを符号化したもので
ある。このタグ番号によって、Ｖ＿ＩＤ決定処理あるい
はＳ＿ＮＯ決定処理をしてタグデータを表示する。一般
メッセージでは、ＡＰＤＵ＿ＴＹＰＥ、ＳＣ、Ｖ＿Ｉ
Ｄ、Ｓ＿ＮＯ、Ｔ０，Ｔ１，Ｔ２，Ｔ３、ＣＮＴ、コン
テックストタグ番号を検索パラメータ入力として図２の
テーブルを検索して対応するメッセージ構文のレコード
を求める。ただしこのときプライベートメッセージ以外
では検索パラメータ上でＶ＿ＩＤとＳ＿ＮＯは常に０に
セットされる。検索によって得られたレコードからＥＬ
＿ＩＤを求めて更に図３のテーブルを検索することによ
り切り出したコンテックストタグのタグ番号に対応する
タグデータ情報（データタイプ、データ値、データ名
称）を求める。データが列挙型の場合には更に図４の列
挙値テーブルを検索することで列挙値データに対する列
挙値データ名称を求める。こうして求めた結果を人間に
読みやすい形式で表示する。 【００２２】図５および図６のフロー図によってメッセ
ージを先頭から走査してタグデータの発生ごとにタグデ
ータを順次切り出して解析していく。順次得られたデー
タタイプ、データ値、データ名称、列挙値データ名称の
結果を、元のバイナリデータとの比較が容易、抽象構文
記法での文書と比較が容易、さらに人間にも読みやすい
形式で表示する。 【００２３】図７と図８に本発明での解析表示装置での
表示結果を示す。上段部ウィンドウは補足したメッセー
ジを一覧表示する。中段部ウインドウは一覧表示から選
択したメッセージに対して詳細表示する。左側にはバイ
ナリデータを１６進表示し、右側にはこれを解析したタ
グデータを階層化して表示する。この表示形式はＢＡＣ
ｎｅｔメッセージ定義文書に準拠している。従って補足
したメッセージがＢＡＣｎｅｔメッセージ定義に合致し
ているかの比較が容易にできるようになっている。下段
部ウインドウは選択したメッセージを単純に１６進表示
してデバッグ用に使用される。 【００２４】図７は以下のように処理され表示されてい
る。ＡＰＤＵ＿ＴＹＰＥが０でＳＣが１２であることか
らRead Propertyメッセージであることがわかる。最初
のコンテックストタグ（タグ番号＝０）はレベル０で発
生している。図２を検索してＥＬ＿ＩＤが２４５である
ことが分かる。図３を検索して、このタグ情報は、デー
タタイプはＢＡＣ＿ＯＩＤ（ＢＡＣｎｅｔオブジェクト
ＩＤ）であり、データ名称は"Destination Object ID"
であることが分かる。図８は以下のように処理され表示
されている。ＡＰＤＵ＿ＴＹＰＥが３でＳＣが１２であ
ることからComplex Ack for Read Propertyメッセージ
であることがわかる。最初のコンテックストタグ（タグ
番号＝０）はレベル０で発生している。図２を検索して
ＥＬ＿ＩＤが２４５であることが分かる。図３を検索し
て、このタグ情報は、データタイプはＢＡＣ＿ＯＩＤで
あり、データ名称は"Destination Object ID"であるこ
とが分かる。２番目のコンテックストタグ（タグ番号＝
１）もレベル０で発生している。図２を検索してＥＬ＿
ＩＤが１５０であることが分かる。図３を検索して、こ
のタグ情報は、データタイプはＥＮＵＭ（列挙値）であ
り、データ名称は"Attribute ID"、であることが分か
る。ＥＮＵＭ＿ＴＹＰＥが１５であるから、これ（１
５）に対応する図４の列挙値テーブルを検索する。列挙
値６２に対応する列挙値データ名称"MAX APDU Length A
ccepted"が分かる。 【００２５】以下、本発明の応用例について説明する。
メッセージデータベースを処理プログラムと分離して外
部データベースとすることができる。この場合メモリデ
ータベースに比べて処理は多少遅くなるがデータベース
を修正しても処理プログラム側では結合処理をする必要
が無くなり、メッセージ構文の変更、即ちデータベース
の変更に対して更に柔軟に対応できるようになる。 【００２６】実施例でのデータベースはＢＡＣｎｅｔメ
ッセージ定義文書を参照して手動で作成されている。電
子化されたＢＡＣｎｅｔメッセージ定義文書から自動的
にデータベースを生成することも可能である。この場合
メッセージ構文の変更に対して更に柔軟に対応できるよ
うになる。 【００２７】 【発明の効果】ＢＡＣｎｅｔメッセージとして発生可能
なメッセージの構文情報をデータベースとして持ち、こ
のデータベースを参照して解析表示をおこなうという構
成によってメッセージ種類ごとに処理ルーチンを作成す
る必要がなくなる。メッセージの種類の追加、メッセー
ジ構文の変更が発生したときにはデータベースに変更を
加えるだけで対応できるようになる。プライベートメッ
セージはベンダごとに定義されるものでありメッセージ
構文はベンダごとに異なっている。このプライベートメ
ッセージの追加あるいは変更に対してもデータベースに
情報を追加あるいは変更を加えるだけで対応できるよう
になる。データベースを外部データベースとして持つこ
とによりデータベース変更に際してプログラムの再結合
処理が不要になりより柔軟にメッセージ変更に対応でき
るようになる。
【図面の簡単な説明】
【図１】本発明でのＢＡＣｎｅｔメッセージ解析表示装
置の構成図である。 【図２】データベースの一部であるメッセージ構文テー
ブルである。 【図３】データベースの一部であるコンテックストタグ
要素テーブルである。 【図４】データベースの一部である列挙値テーブルであ
る。 【図５】メッセージ解析表示処理のフロー図である。 【図６】タグデータの解析表示処理部のフロー図であ
る。 【図７】本発明でのＢＡＣｎｅｔメッセージ解析表示装
置での解析結果表示例１である。 【図８】本発明でのＢＡＣｎｅｔメッセージ解析表示装
置での解析結果表示例２である。 【図９】ＢＡＣｎｅｔ＿ＡＰＤＵの構成図である。 【図１０】従来でのＢＡＣｎｅｔメッセージ解析表示装
置の構成図である。 【符号の説明】 １ 入力部 ２ 解析表示処理部 ３ 表示部 ４ ＢＡＣｎｅｔメッセージデータベース ５ ＢＡＣｎｅｔメッセージ抽象構文定義文書 ６ ＢＡＣｎｅｔメッセージ符号化・復号化規則文書 ７ ＢＡＣｎｅｔ＿ＡＰＤＵ固定部 ８ ＢＡＣｎｅｔ＿ＡＰＤＵ可変部
置の構成図である。 【図２】データベースの一部であるメッセージ構文テー
ブルである。 【図３】データベースの一部であるコンテックストタグ
要素テーブルである。 【図４】データベースの一部である列挙値テーブルであ
る。 【図５】メッセージ解析表示処理のフロー図である。 【図６】タグデータの解析表示処理部のフロー図であ
る。 【図７】本発明でのＢＡＣｎｅｔメッセージ解析表示装
置での解析結果表示例１である。 【図８】本発明でのＢＡＣｎｅｔメッセージ解析表示装
置での解析結果表示例２である。 【図９】ＢＡＣｎｅｔ＿ＡＰＤＵの構成図である。 【図１０】従来でのＢＡＣｎｅｔメッセージ解析表示装
置の構成図である。 【符号の説明】 １ 入力部 ２ 解析表示処理部 ３ 表示部 ４ ＢＡＣｎｅｔメッセージデータベース ５ ＢＡＣｎｅｔメッセージ抽象構文定義文書 ６ ＢＡＣｎｅｔメッセージ符号化・復号化規則文書 ７ ＢＡＣｎｅｔ＿ＡＰＤＵ固定部 ８ ＢＡＣｎｅｔ＿ＡＰＤＵ可変部
Claims (1)
- 【特許請求の範囲】 【請求項１】ＢＡＣｎｅｔメッセージを解析表示する装
置において、メッセージの種類とその構文情報をデータ
ベースとして持ち、これを参照して解析表示の処理をお
こない、メッセージの種類および構文の追加と変更があ
った場合には上記データベースに追加あるいは変更を加
えることで対応することを特徴とする装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001336182A JP2003140996A (ja) | 2001-11-01 | 2001-11-01 | ＢＡＣｎｅｔメッセージ解析表示装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001336182A JP2003140996A (ja) | 2001-11-01 | 2001-11-01 | ＢＡＣｎｅｔメッセージ解析表示装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2003140996A true JP2003140996A (ja) | 2003-05-16 |
Family
ID=19151048
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001336182A Pending JP2003140996A (ja) | 2001-11-01 | 2001-11-01 | ＢＡＣｎｅｔメッセージ解析表示装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2003140996A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012215932A (ja) * | 2011-03-31 | 2012-11-08 | Azbil Corp | エンジニアリング装置 |
-
2001
- 2001-11-01 JP JP2001336182A patent/JP2003140996A/ja active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012215932A (ja) * | 2011-03-31 | 2012-11-08 | Azbil Corp | エンジニアリング装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6336123B2 (en) | Hierarchical based hyper-text document preparing and management apparatus | |
| US6836890B1 (en) | Methods and systems for message translation and parsing of data structures in a distributed component architecture | |
| US5828842A (en) | Method of creating information for executing network management operations from a simplified definition of an operation sequence and providing a network management operation sequence, used in the information | |
| US7852860B2 (en) | Protocol conversion apparatus, communication apparatus, method and program | |
| JP4153883B2 (ja) | 階層型データベース装置および階層型データベース装置における製品選定方法およびプログラム | |
| CN112104634A (zh) | 数据报文处理方法、系统、设备及可读存储介质 | |
| US6466934B2 (en) | External system interface method and system | |
| CN108762743A (zh) | 一种数据表操作代码生成方法及装置 | |
| WO2005086449A1 (ja) | プロトコルメッセージを簡易に制御可能な通信システムのシミュレーション装置及びシミュレーション方法 | |
| US5862336A (en) | Tracing system for analyzing an information distribution route by automatically gathering distribution histories from systems which the information is routed through | |
| US5857077A (en) | Tracing system having follow-up distribution section for distributing information based on a distribution history of prior distributed information stored in distribution history storing section | |
| JP4452211B2 (ja) | データ不整合検出装置および検出方法 | |
| CN112329043A (zh) | 信息加密处理方法、装置、计算机设备及介质 | |
| CN113608955B (zh) | 一种日志记录方法、装置、设备及存储介质 | |
| US7188162B1 (en) | Method and equipment for setting up a protocol/system protocol | |
| JPH07262103A (ja) | 符号復号化制御方式 | |
| US7174482B2 (en) | Process control bus monitoring and analysis | |
| JP2003140996A (ja) | ＢＡＣｎｅｔメッセージ解析表示装置 | |
| JPH1049539A (ja) | データベース管理システム | |
| KR102550102B1 (ko) | 설비를 제어하는 서버, 방법 및 컴퓨터 프로그램 | |
| JPH07271696A (ja) | プロトコルデータの解析表示方法 | |
| JP2007128363A (ja) | プログラマブル・コントローラ・システム | |
| JPH07239816A (ja) | エージェント・システム | |
| CN113709189A (zh) | 检测规则库的生成方法及系统、电子设备、存储介质 | |
| KR20030058025A (ko) | 에이티엠 망에서 망 관리 시스템 및 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041008 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20041122 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20041122 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070110 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070502 |