SanDisk MemoryStick Pro Duo 16GB SDMSPD-016G-J95

￥5,380

Amazon.co.jp

I-O DATA USB 2.0/1.1対応 外付型ハードディスク 1TB HDC-EU1.0

￥9,280

Amazon.co.jp

J.1.1 BACnet/IP(B/IP)ネットワーク定義

BACnet/IPネットワークは単一のBACnetネットワーク番号が割り当てられたIPサブネットワークのひとつ以上のあつまりである。
BACnet相互作用は2つ以上のBACnetネットワークから成る。
これらのネットワークはBACnet/IPネットワーク、あるいは7,8,9および11節で規定している技術を用いることで可能となる。
この標準はJ.8節で述べているようにIPサブネットと似たIPマルチキャストをサポートしている。

J.1.2 B/IPネットワーク内でのアドレス付け

B/IPネットワークの場合、2オクテットのUDPポート番号につづいて4オクテットのIPアドレスからなる6オクテットが、個々のデバイス間通信について、
7,8,9および11節での技術でのMACアドレスに対して似たように機能する。
このアドレスはB/IPアドレスとして参照される。
デフォルトUDPポート番号は直メッセージおよび同報ともX’BAC0’であり、すべてのB/IPはそれをサポートする。
いくつかのケースでは、すなわち、同じIPサブネット上で独立に共存しているBACnetデバイスの2つのグループに対しては願わしい状況であり、
UDPポートは、プロトコル違反を考慮してローカルには異なる値で構成されるだろう。
この付加文書で対象としている”B/IP同報”の場所とは、ネットワークの一部にあって同報しているデバイスのサブネット、
およびアドレスのホスト部分にあるすべての1、および論議中のB/IPネットワーク上にあるデバイスのUDPポートを意味する。
適当なUDPポートで結合したIPマルチキャストアドレスはJ.8で定義している環境でB/IP同報の代わりとなる。

J.1.3 B/IP概念

BACnetネットワークは6.3.2で定義するようにローカル、リモート、グローバルを含む直メッセージや同報メッセージに関して他の非IPネットワークに対して機能する。
直メッセージは直接目的ノードに届く。
”ローカル同報”は単一B/IPネットワーク上のすべてのノードに届く。
”リモート同報”は発信元と異なるネットワーク番号を持つ単一のBACnetネットワーク上のすべてのノードに届く。
”グローバル同報”はすべてのネットワーク上のすべてのノードに届く。
単一B/IPネットワーク内同報、あるいは複数のB/IPネットワーク間、あるいはB/IPと非B/IPネットワーク間の管理はJ.4に記述されている。

J.2 BACnet バーチャルリンクレイヤー

BACnetバーチャルリンクレイヤー(BVLL)はBACnetネットワーク層(6節)と特定の通信サブシステムが持つ下位層の機能との間のインターフェイスを提供する。
この文書ではBACnet/IP直メッセージおよび同報メッセージをサポートするためのBACnetバーチャルリンクコントロール(BVLC) 機能を規定する。
この目的および個々のメッセージのフォーマットは以下の小節で述べる。

個々のBVLLメッセージは少なくとも3つのフィールドを持つことに注意。
1オクテットのBVLCタイプフィールドは下層の通信サブシテムやマイクロプロトコルが使われることを示している。
この場合、BVLCタイプX”81”はこの文書で定義するBACnet/IPを用いることを示している。
1オクテットのBVLC機能フィールドは通信サブシテムやマイクロプロトコルをサポートするための機能を定義している。
2オクテット長のBVLCフィールドはオクテット単位でBVLLメッセージの大きさである。

J.2.1 BVLC-Result:目的

このメッセージはBVLLサービス要求の結果が成功(ACK)したか、失敗(NAK)したかを確認するための仕組みを提供するものです。
これらには、以下のものがあります。
Write-Brordcast-Distribution-Table(ACK,NAK)
Read-Brordcast-Distribution-Table(NAKのみ)
Register-Foreign-Device(ACK,NAK)
Read-Foreign-Device(NAKのみ)
Delete-Foreign-Device-Table-Entry(ACK,NAK)
Distribute-Broadcast-To-Network(NAKのみ)

J.2.1.1 BVLC-Result:形式

BVLC-Resultメッセージは4つのフールドからなる。

BVLC タイプ　　　 　1オクテット　　　X"81" BACnet/IPに対するBVLL
BVLC機能 1オクテット X"00" BVLC-Result
BVLC長さ 2オクテット L BVLLメッセージ長(オクテット)
結果コード　　 2オクテット X"0000" 成功
　　　　　　 X"0010" Write-Brordcast-Distribution-Table NAK
X"0020" Read-Brordcast-Distribution-Table NAK
X"0030" Register-Foreign-Device NAK
X"0040" Read-Foreign-Device NAK
X"0050" Delete-Foreign-Device-Table-Entry NAK
X"0060" Distribute-Broadcast-To-Network NAK

J.2.2 Write-Brordcast-Sistribution-Table:目的

このメッセージはBACnet同報管理装置(BBMD)にある同報管理テーブル(BDT)の初期化および更新のために提供されている。

J.2.2.1 Write-Brordcast-Sistribution-Table:形式

Write-Brordcast-Distribution-Tableメッセージは4つのフールドからなる。

BVLC タイプ　　　 　1オクテット　　　X"81" BACnet/IPに対するBVLL
BVLC機能 1オクテット X"01" Write-Brordcast-istribution-Table
BVLC長さ 2オクテット L BVLLメッセージ長(オクテット)
BDTエントリーリスト N*10オクテット

NはBDT内エントリーの数である。
各BDTエントリーは、同報ディストリビューションマスクと呼ばれる4オクテットに続いて6オクテットのBBMDのB/IPアドレスから構成される。
これは、どのように同報メッセージがIPサブネットに配布されるかを示している。(J.4.3.2参照)

J.2.3 Read-Brordcast-Distribution-Table:目的

このメッセージはBBMDのBDTの内容を検索するために提供されている。

J.2.3.1 Read-Brordcast-Distribution-Table:形式

Read-Brordcast-Distribution-Tableメッセージは3つのフィールドからなる。

BVLC タイプ　　　 　1オクテット　　　X"81" BACnet/IPに対するBVLL
BVLC機能 1オクテット X"02" Read-Brordcast-Distribution-Table
BVLC長さ 2オクテット X"0004" BVLLメッセージ長(オクテット)

J.2.4 Read-Brordcast-Distribution-Table-Ack:目的

このメッセージはBBMDの持つ現在のBDTを要求者に返すことである。空のBDTについては長さ0のリストとしてあらわされるだろう。

J.2.4.1 Read-Brordcast-Distribution-Table-Ack:形式

Read-Brordcast-Distribution-Table-Ackメッセージは4つのフィールドからなる。

BVLC タイプ　　　 　1オクテット　　　X"81" BACnet/IPに対するBVLL
BVLC機能 1オクテット X"03" Read-Brordcast-Distribution-Table-ACK
BVLC長さ 2オクテット L BVLLメッセージ長(オクテット)
BDTエントリーリスト N*10オクテット

Nは戻されたBDT内のエントリー数を示す。

J.2.5 Forwarded-NPDU:目的

BVLLメッセージはBBMDからの同報メッセージと登録された外部デバイスに転送されたメッセージで使用される。
発信元BACnet NPDUと同様に発信元ノードのソースアドレスを含んでいる。

J.2.5.1 Forwarded-NPDU:形式

Forwarded-NPDUメッセージは5つのフィールドからなる。

BVLC タイプ　　　 　1オクテット　　　X"81" BACnet/IPに対するBVLL
BVLC機能 1オクテット X"04" Forwarded-NPDU
BVLC長さ 2オクテット L BVLLメッセージ長(オクテット)
発信元B/IPアドレス 6オクテット
BACnet NPDU 可変長

J.2.6 Register-Foreign-Device:目的

このメッセージはJ.5.1で規定するような外部装置に同報メッセージを受信させるためにBBMDに登録させることにある。

J.2.6.1 Register-Foreign-Device:形式

BVLC タイプ　　　 　1オクテット　　　X"81" BACnet/IPに対するBVLL
BVLC機能 1オクテット X"05" Register-Foreign-Device
BVLC長さ 2オクテット X"0006" BVLLメッセージ長(オクテット)
有効時間 2オクテット T 有効時間(秒)

有効時間の値は、外部装置がBBMDに再登録なければならない時間(秒)である。

(略)

J.3 BACnet/IP直接メッセージ

B/IP装置はB/IPアドレスを用いてお互いに直接通信を行うことができる。おのおののNPDUはBVLL Original-Unicast-NPDUで送られる。

J.4 BACnet/IP 同報メッセージ

この節で、BACnet同報メッセージがB/IPネットワーク内でどのように管理するか規定する。

J.4.1 BACnet/IP 同報メッセージ、単一IPサブネット

このケースではB/IPネットワークは単一のIPサブネットから構成される。
”ローカル同報”はB/IP同報アドレスを用い、NPDUはBVLL Original-Broadcast-NPDUメッセージとして送られる。
すべてのノードが単一IPサブネットにあるため、各メッセージは自動的に全ノードに届く。図J-1参照。

図J-1 単一IPサブネットからなるB/IPネットワーク

J.4.2 B/IP同報管理、複数のIPサブネット

このケースではBACnet/IPネットワークは2つ以上のIPサブネットから構成される。
”ローカル同報”はB/IP同報アドレスを用い、NPDUはBVLL Original-Broadcast-NPDUメッセージとして送られる。
標準IPルータはそのような同報を転送しないので、付属の装置が、この機能を実行するのに必要である。
この装置は、BACnet/IP同報管理装置(BBMD)と呼ばれる。図J-2参照。

図J-2 2つのIPサブネットからなるB/IPネットワーク

J.4.3 BBMDのコンセプト

2つ以上のサブネットを含むB/IPネットワークの一部である各IPサブネットはひとつの、そして唯一のBBMDを持っている。
各BBMDは同報配布テーブル(BDT)と呼ばれるテーブルを所有している。それは与えられたB/IPネットワークの各BBMD内において同じものである。
もし、BBMDが登録された外部装置をはっきり指定するときには、外部装置テーブル(FDT)を所有することになる。

(略)

おかしい。

その1

日本人は飽食すぎる。

日本人ほど世界中の料理を食べる国はない。

フランス料理に始まり、イタリア、中国、韓国、タイ、ベトナム、インド、

。。。

要するに節操なくなんでも食べる。グルメ。

その2

国民が農業をやりたがらない。

農家の子供はみんな都会にでてサラリーマンになりたがる。

その結果、農業の担い手は高齢者ばかりとなり、

そのあとは畑、田んぼが捨てられる。

あまっている畑は多いのだ。

しかし、米は過剰に作られている。

政府は毎年、米を生産者から買い上げている。

しかし、日本人は米を食べなくなってきているので、米はあまる。

余った米はどうなるのか。いつまでも在庫として古古・・・米としているわけではない。

買い上げ費用と販売価格の差額、古米の保存費用と金がかかる。

そこで飼料として販売するのだ。これにも予算をつけてるという話だ。

一説によると、農業補助をやめれば全サラリーマンの税金を只にできるそうだ。

なんとも矛盾した話だ。

政策して米をつくらずほかの作物を作るしかないではないか。

しかし、農民は減反に反対する。

表面的には、食料自給率や食の安全などいっているが、

作ったものを政府が買ってくれるのでリスクがないだけの話だ。

マスコミも農民を弱者として扱うのをやめたらどうだろうか。

純粋にくじらがかわいそうとう理由からです。

日本人でもフォエールウッチングが好きな人はいる。

その前で、くじらを殺したらどうだろうか。

近所の川にいつごろか鯉が自然に増え始め、小さな橋のうえから、

子供たちや年寄りも見て楽しんでいる。えさをやる人もいる。

鯉を見るのも好きなのだ。

そこに、最近つりをする人が来た。

まわりの冷たい視線にかまわず得意げにつりをし続けた。

鯉は次の日から一匹も見かけなくなり、人も去った。

調査捕鯨という言葉もまやかしがありそうだ。

調査するために何百頭というくじらを獲る必要があるのだろうか。

朝日新聞の調査捕鯨に参加した人の意見が声欄にのっていたが、

調査の内容がくじらをそれほど殺さなくてはならない理由とは思えない。

オーストラリアと言い分のほうが客観的に見て正しい。

メーカの仕事だが、webを知っている人がいない。

信じられないような話が現実にはある。

もともと汎用機だけでやっていた現場なので、

ほとんどの人がCOBOLしかしらない。

そこに１人だけweb担当ということで入った。

まわりと技術的な話ができない。

相談もできない。

ただインターフェイスは決めなくてはならない。

汎用機とAPサーバ(Windows2003 server)とはCORBAで結ぶ。

フレームワークは使わないようにした。

一般的なMVCモデルにしたが、メーカツールの

フレームワークは使わない。

これはwebの技術がそのフレームワークで埋没してしまうため、

技術力がつかないと思ったため。

不安要素が多い仕事。どうなるんでしょう。

ここにきて、1つが一応片付き、もう１つも不具合対応だけとなり大分楽になりました。(-^□^-)

自問自答

プログラム作っているの楽しい?

>まーね。

しかし、今回のシミュレーションのプログラムは頭がおかしくなるくらい難しかった。

プログラムが難しくなる要素は「不確定な要素がいくつも重なったとき」。

今回はこれが多かった。

時間軸につていも、4つある。

次の仕事はデパートの売り上げをwebでみるというもの。

終わった仕事がRFタグによるセキュリティシステム。

と、仕事の分野がいろいろ。一貫性がない。

これはいいことなのか、悪いことなのか。

外であまり仕事をしたことがない(ユーザ常駐での)が、今回出た。

出た理由・・・・頼まれたから。たぶん違う。

「出会いを求めて」　うーん。「新しい体験」　これか。