IT アーキテクトのための RFID ソリューション構築指針
ここでは、RFID システム構築に興味のある方、また、RFID システム構築に携わっている IT アーキテクトの方を対象に RFID システム構築において、事前に知っておくべき、あるいは確認しておくべき技術的ポイントについて解説します。
トピック
 | RFID システムのレイヤー モデル |
| データキャリア レイヤー |
| リーダー/ライター レイヤー |
| ミドルウエア レイヤー |
| アプリケーション レイヤー |
| まとめ |
RFID システムのレイヤー モデル
RFID システムと一口に言っても、1 台の PC にリーダー / ライターが接続され、それを利用するアプリケーションも同じ PC 上に存在するようなスタンドアロン型の小規模なものから、複数のリーダー / ライターが分散された複数の箇所に存在し、さらに読み取られた情報を企業間で共有するようなネットワーク型の大規模なものまで、その規模や利用目的は様々です。ここでは、RFID アプリケーションの本来の利用分野である、SCM システムやグローバル ロジスティクス システムなど、数百台のリーダー / ライターがネットワーク経由で連携するような比較的大規模な RFID アプリケーションの構築を想定した内容となっています。
ネットワークを介したリーダー/ライター制御やデータ参照などが発生する比較的大規模な RFID システムのレイヤー モデルは大きくデバイス レイヤーとシステム レイヤーに分類することが出来ます。さらに、デバイス レイヤーはデータキャリア レイヤーとリーダー/ライター レイヤーの 2 層に、システム レイヤーはミドルウエア レイヤーとアプリケーション レイヤーの 2 層の計 4 層に分類することができます。
RFID システムを IT アーキテクトという立場で捕らえたとき、システム全体をデバイス レイヤーとシステム レイヤーの 2 つに分けるという考えは非常に重要となります。なぜなら、RFID の導入により実現可能とされている効果の多くは、実は、システムに大きく依存しているからです。
例えば、RFID により実現されるシステムとして語られるものの 1 つにリアルタイム在庫管理システムがありますが、新聞や雑誌の RFID に関する記述の中には、RFID さえ導入すれば、明日にでもリアルタイム在庫管理システムが実現できるような表現をしているものもあります。しかし、実際に、リアルタイム在庫管理システムを実現しようとした場合、RFID 導入以前に、倉庫と本社間など、拠点間において在庫情報をリアルタイムで情報を共有するためのインフラが整備されているかなど、RFID の導入がすべてを解決するわけではないことに気づきます。それどころか、RFID が担う役割はリアルタイム在庫管理システム実現のためのごく一部に過ぎず、機能的にもコスト的からもシステム側における課題解決が重要であることに気づきます。例えば、リアルタイム在庫管理システムの場合、RFID が担う機能は、倉庫における在庫数の読み取り行為のリアルタイム化（自動化と精度向上）のみであり、読み取られた在庫情報が、在庫管理担当者の管理画面にリアルタイムに表示されるかどうかや、在庫数が基準値を下回っていた場合、自動発注が行われるなどの機能はシステムが担うことになります。
RFID システム構築に携わる IT アーキテクトの最初の仕事は、まず、RFID に関する正しい知識をつけた上で、情報システム全体において、RFID が担う機能と狭義のシステムが担う機能を明確に区別し、それぞれのレイヤーに担わせる機能を整理できるようになることです。
では、それぞれのレイヤーに担わせるべき機能やその理由、具体的な解決手法などについて説明します。
データキャリア レイヤー
このレイヤーは RF (IC) タグ・ラベルといった、媒体のレイヤーです。RFID と一口に言っても通信に使用する周波数帯や書き込み機能、複数同時認識機能の有無などにより、様々なタイプのものが存在します。さらに、IC チップやアンテナ自体が封入される媒体に特殊加工をすることにより金属に貼付した場合の性能劣化などを防ぐ機能を持つものなどもあります。一般的に、低価格なタグは、低機能であるため、タグの選定においては、単純に価格だけでなく、機能面から十分なタグ選定を行う必要があります。なお、タグに関する詳細な解説は他に譲ることとします。
IT アーキテクトとしてシステム設計を行う際、認識しておくべき重要なことは、RFID (ICチップ) をデータキャリアとしてとらえることです。つまり、IC チップはデータを運ぶ入れ物に過ぎないという考えです。もっと正確に表現すれば、記録される情報と記録される媒体を分けて考えるということです。例えば、12345 という商品管理 ID がある場合、この ID をバーコードに保存することも 2 次元バーコードとしても RFID に保存することも可能ですが、一度読み込まれてしまえば、システム的には 12345 という数字に過ぎません。
このように情報と媒体は独立した関係にあり、媒体が何であるかはシステム仕様に影響を与えるものではありません。もし、RFID を導入することで、上位システム仕様に影響を与える要素があるとするならば、それは、RFID の導入によってもたらされた商品管理のリアルタイム化 (自動化や精度向上) に対応するためのものであり、データキャリアが RFID であるためではありません。IT アーキテクトにとって重要なことは、媒体の種類よりも、それ自体に記録されている情報の内容や、それが、リアルタイムに閲覧できることをどう、付加価値とするかということになります。
リーダー/ライター レイヤー
IC チップを含めた媒体に記録されている情報を読み取るのはリーダー / ライターと呼ばれる機器になります。データキャリア レイヤーへのアクセスは実際、リーダー/ライター レイヤーを介して行うことになるため、その窓口となるインターフェースの仕様は IT アーキテクトやプログラマにとって最も関心のあるトピックスかもしれません。
多くの場合、リーダー/ライターの物理的インターフェースは RS - 232C などになります。最近では USB タイプのものも増えましたが、元々組み込み向けの製品も多いため、インターフェース技術としては比較的古い (シンプル) タイプのものが主流です。また、ソフトウエア インターフェースも物理的インターフェースに伴い基本的なスタイルはシリアル コマンドによる制御となります。メーカーによっては C/C++ 向けのライブラリや COM コンポーネントなどの高水準 API を提供している場合もありますが、主流ではありません。
IT アーキテクトとして把握しておくべき重要なことは、リーダー / ライターの物理的、ソフト的インターフェースの統一化は行われていないということです。RFID の規格には ISO 18000 シリーズなど、標準化の動きがありますが、リーダー / ライターのインターフェースの標準化は事実上手付かずの状態にあります。このような状態において、IT アーキテクトはどのようなリーダー / ライターでも対応可能なシステムを構築すべきですが、物理的にもソフト的にも仕様が決定していない現状においては、プラグ アンド プレイのようなエレガントな対処は難しいのが実情です。
ここでも重要となるが、デバイス レイヤーとシステム レイヤーの分離です。リーダー / ライター レイヤー以下をシステムと明確に分離しながら、システム全体をうまく機能させる方法を検討する必要があります。結論から言えば、デバイス レイヤーとシステム レイヤーを分離するためには、システム側に工夫が必要になります。例えば、システム側にリーダー/ライターにて読み取ったデータを受け取り、データベースに書き込む機能を持つ Web サービス API を用意し、読み取ったデータをシステムに転送できるようにしておけば、少なくとも、リーダー/ライターを変更する為に都度、システム側を変更する必要はありません。
マイクロソフトが提供する .NET Framework 2.0 および Visual Studio 2005 を利用することで、デバイスから得た情報を、上位の Web サービスに転送するといった機能を容易に実装することが可能となります。特にデバイス制御という観点では、.NET Framework 2.0 よりシリアル クラスが追加され、レガシー ポートを利用したデバイス制御ウエアの開発生産性が飛躍的に向上しています。
| • |
ミドルウエア レイヤー
スタンドアロンタイプの RFID システムにおいては明示的にミドルウエア レイヤーを設ける必要ありませんが、ある程度の規模のシステムを構築する場合、デバイス レイヤーの抽象化、他社とのデータ連携などの要求に対してスムーズに対応するために、ミドルウエア レイヤーを設けることが推奨されます。ミドルウエア レイヤーの実態は、Web サービスなど、SOA で実装されたリモート API 群となることが一般的です。リーダー / ライター制御機能や在庫数確認機能などを Web サービス API として実装することにより、上位アプリケーションからの呼び出しはもちろん、他社からのリクエストなどに対しても柔軟に対応することが可能となります。Web サービスはシステム プラットフォームに依存しないことに加え、Web で使用される各種プロトコルを利用したシステム連携技術であるため、ファイアウォール等の変更なども必要ないなどのメリットがあり、急速に普及が進んでいます。現在、RFID の世界的標準規格である EPC Global Network System においても、各機能は Web サービスとして実装されています。さらに、セキュリティの観点からも、基幹システムにダイレクトにアクセスを許可するのではなく、中間サーバなど、物理的、ソフト的にミドルウエア レイヤーを確保し、それを介して各種処理を行う方が適当です。ただ、ミドルウエア レイヤーは目に見えない機能であるため、運用管理という面で問題になることがありますので、ビジネス ロジックやビジネス プロセスの可視化なども検討する必要があります。
.NET Framework 2.0 および Visual Studio 2005 を利用すれば新規の Web サービスの開発、配置はもちろん、既存のビジネス ロジックの Web サービスによるラップなどを容易に行うことが可能です。.NET Fraemwork 2.0 では、Web サービスの相互接続性を保証する規格である WS-I Basic Profile 1.0 に対応し、Windows 以外のプラットフォームとの相互接続性も向上しています。さらに、BizTalk Server 2006 を利用すれば、分散した複数の Web サービを組み合わせ 1 つのビジネス プロセスとして組み上げるといった作業をビジュアルに行うことができ、ビジネス プロセスの可視化はもちろん、プロセスの変更などにも柔軟に対応することができます。
| • |
アプリケーション レイヤー
データキャリア レイヤーで説明したとおり、媒体と情報は独立しています。そのため、データキャリアを物理的に RFID に変更したからといって、何か新しい機能がアプリケーションに要求されるわけではありあません。もちろん、RFID の導入目的は、データキャリアを RFID に置き換えることではなく、その導入により得られる、在庫確認の自動化、精度向上、リアルタイム化などです。ただ、分散された拠点の在庫情報がリアルタイムで正確にわかったとき、それをどう活用するかは企業それぞれに異なります。しかし、リアルタイム化されたシステムにおいて、IT アーキテクトが考慮しなければならない、基本的な項目があります。それは、増加するデータへの対応です。データの取得が自動化され、システムがリアルタイム化されれば、インフラ上を流れるデータ量はバッチ型のシステムに比べ膨らむことは間違いありません。増加したデータに対しては、データをいかに処理するかというパフォーマンスという観点と、データをいかに利用するかと言うビジネス インテリジェンスの 2 つの観点からの考慮が必要です。
| • | パフォーマンスに対する考慮 |
リアルタイムにおいて、大容量データの処理は、悩ましい問題です。例えば、100 GB というデータがあったとき、単純に蓄積するということであれば、ハードディスクの大容量化と低価格化が進んだ現在においては全く問題ないでしょう。しかし、常に 100 GB のデータから、特定の情報を検索し、リアルタイムでレスポンスをしなければならないという処理を行うことは簡単ではありません。情報の処理や検索スピードは、処理するデータをメモリ空間に展開できるかどうかに大きく依存します。例えば、現在一般的に利用されている 32 bit ベースのシステムでは、物理的に対応可能なメモリ容量は 4 GB となっていますが、この 4 GB という容量は、決して多くはありません。システムの仕様決定においては、ストレージ容量や CPU 数はもちろん、64 bit 化によるメモリ容量の拡張など目的とするパフォーマンスを得られるよう注意する必要があります。また、リアルタイム型のシステムにおいては、システムダウンがビジネスの停止に直結するといわれています。パフォーマンスの確保においては、スピードはもちろん、障害耐性という観点からもシステム仕様を検討する必要があります。
Windows Server 2003 は最大で 64 CPU、1 TB の物理メモリに対応するとともに、GUI ベースでフォールトレランス設定などが可能であるため、安定したリアルタイム システム インフラを容易に構築することが可能です。
| • | ビジネスインテリジェンスの考慮 |
RFID の導入はデータの入力精度の向上につながります。システム導入の失敗例の中には、数億円をかけて、リアルタイム在庫管理システムと自動受発注システムを導入したのに、そもそもシステムに正確な情報が入力されず、システムが機能しなかったというものがあります。このようなシステムを正常に運用するために RFID の導入は効果的です。いずれにしても、正確に入力された情報をいかにビジネスに活用できるかが、RFID システム導入の評価に影響することは明らかです。
ビジネス インテリジェンスの機能強化の方向性には縦の強化と、横の強化があるとされています。縦の強化とは、あるひとつのデータを手法としていかに深く分析するかといったものです。データ マイニングの導入などは縦の強化の代表といえるでしょう。横の強化とは、データを必要な人が誰でも使えるようにするといった類のものです。いくら正確な在庫情報やデータ マイニングの結果が得られても、必要な人が利用できなければ意味がありません。従来、ビジネス インテリジェンスは経営者やアナリストなど、一部の人のためのものとされてきましたが、このような考えは誤りです。RFID の導入により得られたリアルタイム情報共有インフラを活かしてビジネス インテリジェンスの横の強化を行えば、RFID システム導入の効果を最大化することが可能となります。
マイクロソフトでは SQL Server 2005 を中核とするビジネス インテリジェンス プラットフォームを提供しています。SQL Server 2005 が提供する OLAP、データ マイニング機能は縦方向の強化機能を提供します。また、SQL Server 2005 Reporting Services や Excel Add - in for SQL Server Analysis Services は、全社的な情報共有など、横方向の強化機能を提供します。
| • | 詳細情報 |
まとめ
ここでは、IT アーキテクトのための RFID システム構築ガイドラインとして、RFID システムをレイヤーに分け、それぞれのレイヤー毎に基本的な指針や注意事項について説明してきました。ただ、現実のシステム構築においては、必ずしも論理的な最適解がベストな選択であるとは限りません。システムにより解決したい課題を明確にし、その課題 １ つ １ つに対して、論理的あるいは現実的な解決手段を適用していくことが重要です。