Title: EPCnetwork概略 Author(s): 鈴木茂哉 (shigeya@wide.ad.jp), 宇夫陽次朗 (yuo@iijlab.net) Date: 1/26/2005 本文書では、EPCglobalが仕様を規定しようとしているEPCnetworkについて概観 する。この文書は、公知の情報に基づいて構成しており、直接公開できない EPCglobalの内部文書に基づいた記述は避けている。そのため、一部、明確にか けていない部分もあるが、仕様策定中という状況を理解いただけたらと思う。 1. イントロダクション この文書では、編集時点でディスカッションされているEPCnetwork像の概略に ついて取りあげる。 Auto-IDシステムは、本来Auto-ID Center時代に提唱された、タグに情報を入れ る情報量を減らす(結果的にタグの単価は下がる *1)代わりに、ネットワーク でその情報を補うというコンセプトが核にある。物理的なアイテムと、インター ネット上の情報を紐付けるとも言える。 このコンセプトを実現するには、ソフトウエア的には、タグに振られたIDから 情報が納められている場所を見つける手段と、情報を保持するサービス、そし てこれらの連携を取るためのアプリケーションが必要であることになる。 これらのアプリケーションで扱う情報、特に、EPCglobalが主たるターゲットと しているサプライチェーンマネージメントでの利用を支えるために、ユースケー ス分析が行なわれ、仕様が規定されつつある。 Footnote *1 とはいえ、EPCglobal の Generation 2 タグのトランジスタ数は、 20年前に販売されていたIBM PCのCPU(8088) と比べても遥かに多いと 言われている。 2. EPCnetworkの設計ポリシー EPCnetworkは、以下のような点を留意してデザインされている。 - Service Oriented design - Layered - Extensible - Modular これらの点は、コンピュータシステムの設計を専門するものとしては、考慮す ることが当たり前の点であるが、EPCnetworkのユーザ企業を想定したとき、当 たり前とはいえない。 現時点でのEPCnetworkのユーザとしては、規模の大きい小売業者が第一のター ゲットとなっている。これらは、既存のソフトウエアパッケージを組み合わせ て組み立てるといった形で、いわゆるシステムインテグレータ、あるいは、社 内のIT担当者が組み立てるのが標準的なアプローチであろう。ここで、これら の企業では、ソリューションを手に入れるのが目的であって、拡張性について は、自社の必要とする拡張性に意識は留まるであろう。 一方、設計の現場では、どちらかというとユーザの視点よりも少し高い位置、 言うならば鳥瞰的な見地をもって設計されるべきであり、上記のコンセプトは これに基づいいる。つまり、ユーザ企業の意識よりは高いレベルで設計してい るというわけである。 3. EPCnetworkの全体像 EPCglobalの示しているアーキテクチャは、以下のような物である  (物理的なタグ情報を収集する部分)   RFID tag <---無線プロトコル---> RFID R/W <--->ALEコンポーネント | 「業務アプリケーション等」  (物に関する情報を処理・外部参照する部分)   「業務アプリケーション等」<----------> ONS | +------------------------> EPCIS<--->(ほか業務アプリケーションなど) +------------------------> EPCIS +------------------------> EPCIS それぞれの部分について、以下で説明する。 2.1. タグ タグは、ごま粒大のチップと、アンテナがボンディングされたものであり、電 源を持たず、これだけでは動かない。リーダからの電波により給電され、動作 する。 2.2. Reader/Writer コンポーネント(RFID R/W) タグを読む機器である。電波を発信しタグに給電しつつ、必要な情報をタグか ら取り出す。このとき、電波が届く範囲に分布したタグを必要に応じて選択 して読む機能を持っている。 2.3. ALE コンポーネント ALE (Application Level Event) は、Reader/Writerを含むリーダ層と、ビジネ スロジックを定義しているアプリケーション層の間に位置し、Reader/Writerか ら上がってくる生のイベントを解釈し、Applicationが必要とするイベント (ALE) へと変換する。 機能としては、「リーダからの情報の受信」「蓄積とフィルタリング」「外への イベントのレポート」がある。 かつて、Savant 1.0 の仕様の策定においての反省から、仕様は特定の実装方法 について言及することなく、考え方とAPIの定義となっている 注: ALE は、以前のSavantに当たる部分である。Savantは、リーダとのインター フェース、フィルタ、イベントルータの役割を果たしており、かつ、Java での実装を前提として設計されていた。 (注: Savantという用語は使わなくなっているのだが、一部のドキュメント にまだ残っている。ALEと読み替えるか、古いドキュメントだと解釈 すると良いだろう) 2.4. EPCIS EPCIS (Electric Product Code Information Service)は、以下のような情報を 保持する - EPCの観測にまつわる、履歴を伴うイベント情報 - 上記情報に関連した、トランザクションIDといった、アプリケーション すなわちビジネスロジックに関連した情報 EPCISは、以下のサービス群で構成されている - EPCIS Capturing Application - EPCIS Application - EPCIS repository ここで、EPCglobalが現段階で定義しようとしているのは、APIとデータモデル である。 残念ながら、我々ネットワークの専門家が言うところのプロトコルが定義され る形で、詳細が定義されているわけではなく、ハイレベルなデータモデルが定 義されているのみである。 EPCglobalが定義しているのは、サービスを組立てるのに必要な仕様であり、い わゆるオープンシステムでいうところの、プラグアンドプレイ形式のインター オペラビリティが確保できる仕様では無い。 以下、それぞれについて説明する。 2.3.1. EPC Capturing Application ALEから受け取った情報を統合することで、タグ情報に付加価値を付ける言い方 を変えると、ビジネスロジックが実装されるのがここである。 データの保存場所としては、しては、EPCIS repositoryが用いられる 2.3.2. EPCIS Repository EPCISに関連した情報、つまり、イベントに関わる情報と、アプリケーションに 関連した情報が納められる。 EPCISのデータモデルに従った形の情報を持つデータベースということができる だろう。 2.3.3. EPCIS Application EPCISに納められている情報にアクセスするアプリケーションである。 アプリケーションは、サーバ運用者が動かす場合も、システムを運用している パートナがアクセスする場合もある。 2.3.4. ONS EPCから、信頼できる(authoritative)EPCIS Repositoryを見つけるためのサービ スである。典型的には、当該のEPCを用いている製造者が用意したEPCISサーバが 返されることになる。 信頼できるレポジトリに納められるのは、たとえば、製造者、物理的な大きさ、 重さ商品についての情報といったベンダー固有の情報などが上げられるだろう。 現在のONSは、Domain Name System をベースに構築されているが、名前サービ スとしては、インターネットにアクセスするDNSベースのものだけではなく、ロー カルデータベースをもつ形式のものも併せて利用できるように設計されている。 3. データモデル データには、イベントデータと、オブジェクトについての情報の二つに大きく分 けられる。 イベントデータには、以下のようなものが含まれる - EPCの割り当てと、割り当て解除 - 集約化と、集約解除(パレット単位での集約化などのケース) - EPCの出現と消滅 オブジェクト情報には、以下のようなものがある - EPC - 製品情報 - 位置情報 - 時刻情報 以下、順に説明する 3.1. イベント型 3.1.1. EPCの割り当て EPCが特定のオブジェクトに割り当てられる時に起きるイベントである。 オブジェクトの位置、割り当てが起きた日時などが情報としてあげられる。 3.1.2. EPCの割り当て解除 EPCが特定のオブジェクトから割り当て解除される時に起きる操作を示す。 オブジェクトの位置、割り当てが解除された日時などが情報としてあげられる。 3.1.3. 集約化 パレット単位での集約化などの情報を示している。 たとえば、パレットの場合であれば、パレット自体のEPCと、パレットに乗って いるオブジェクトのEPCの紐付けがこの情報でなされることになる。 集約先のオブジェクトの情報と、集約されたオブジェクトの情報、 位置、集約の日時などが情報としてあげられる。 3.1.4. 集約解除 パレット単位での集約が解除された情報を示す。 集約先のオブジェクトの情報と、集約されたオブジェクトの情報、 位置、集約解除の日時などが情報としてあげられる。 3.1.5. EPCの出現 特定の場所で、あるEPCが観測されたことを示す。 オブジェクトの位置、観測日時などが情報としてあげられる。 3.1.6. EPCの消滅 特定の場所で、あるEPCが消滅したことを示す。 オブジェクトの位置、消滅日時などが情報としてあげられる。 3.2. データ型 いくつかのタイプの情報がメタな形で定義されている。こららについて簡単に 説明する。 3.2.1. EPC EPCも型として定義されるが、単にEPCとしてではなく、より抽象的なIDという 形で、モデル化されている。 意図は明らかでないが、IDという形で一般化されて表現されている。 3.2.2. 位置情報 位置情報は、単に物理的な位置を示すだけでなく、たとえば、部屋という、ある 意味で論理的な単位を指し示す必要や、ドア周辺や、荷物の積み卸し領域といっ た、特定の位置を示す必要がある。 これらを示すのに必要十分な記述モデルが定義されている。 3.2.3. 時刻情報 時刻情報の書式が定義されている。 3.2.4. 製品情報 EPCで示される製品に関連した情報を示す。 4. API 上記コンポーネントの内部がモデルとして定義されるとともに、コンポーネント 間のインターフェースがAPIとして定義されている。以下のようなインターフェ ースがある - Reader Protocol - ALE API - EPCIS API それぞれの詳細については、この文書では触れないが、仕様としては、実際の実 装に踏み込まず、ファンクショナルモデルの定義にとどまっている。 ----- Copyright Notice Copyright (C) WIDE Project (2005). All Rights Reserved