RFID の読み取りステップ 1. 読み取り形態 RFID の読み取り形態はゲートタイプ ( 上側はなくても可 ) とベルトコンベアタイプを想定するゲートタイプではタグはフィルタがないため他 CH の信号に反応する CH が違うと同じ時間に通信できるため LBT では避けることができない問題があ

(1)

RFIDの読み取りステップ

1. 読み取り形態 RFID の読み取り形態はゲートタイプ（上側はなくても可）とベルトコンベアタイプを想定する。ゲートタイプでは、タグはフィルタがないため他 CH の信号に反応する。CH が違うと同じ時間に通信できるため、LBT では避けることができない問題がある。CH1 のゲートにあるタグが、CH2 のリーダ・ライタに反応しないよう、シールド板や電波吸収体が必要になる。また、近くでハンディターミナルを使用しても同様の問題が発生する。図 1 ゲートタイプゲートタイプで身入りの多重構造タグを読み取ることは不可能に近い。金属などの誘電体物質が箱の中に存在すると、電波の吸収、干渉が起こり基本的に内部のタグは読めない場合が多い。例え実験で読めたとしても、保証するのは原理的に不可能と思われる。図 2 多重構造の RF タグ読み取り RF タグは半導体から形成されているため、同じチップをたくさん使用すると価格が下がる。そ

(2)

のため、極力同じチップやインレイを使用すると価格が下がり、それにより RFID が普及すると思われる。しかし、異なるアプリケーションで同じチップ（エアーインターフェイス）を使用するためには、選択的読み取り機能が必要であるが、そのために RFID への格納データを工夫する必要がある。サプライチェーンにはいろいろな目的の RF タグが混在するようになる。図 3 に示すようにタグ A、タグ B およびタグ C に同じ種類の RF タグを使用する場合、読み取り距離はリーダ・ライタの出力を調整することにより対応することができる。製造業者はタグ A やタグ B のデータを読み取る必要性が高く、輸送業者はタグ C のデータを読み取る必要性が高い。輸送業者がタグ C のデータを読み取ろうとする場合、なにもしないと、タグ A およびタグ B も応答してくる。全てのタグを読み取ってから目的のタグを選別し、その情報で搬送ラインを制御しようとすると時間がかかりすぎて、搬送速度に対応できなくなってしまうことが多い。したがって、タグの選択的読み取りメカニズムが必要になる。図 3 RF タグの選択的読み取りベルトコンベアタイプでは、高速ベルトコンベア上の荷物の仕分けに RFID の利用が期待されているが、高速でタグとリーダ・ライタとが交信ができないと読み落とす可能性がある。LBT では待ち時間の間に荷物が通過してしまう可能性が高い。ミラーサブキャリア方式を使用すべきである。ゲート直前の RF タグと交信するためには、アンテナ出力を必要最小限にして、アンテナ間の干渉を最小限にすべきである。高速処理のため、リミットスイッチなどと併用し RF タグを確実に読み取る工夫が必要である。図 3 ベルトコンベアタイプ

A

B

A

B

A

B

A

B

A

包装タグ

製品タグ

梱包タグ

長距離・輸送単位番号、梱包数送り先等中～長距離・製品品番、製造者、販売者等短～中距離・製品品番、製造者等

A

B

C

A

B

A

B

A

B

A

B

A

B

A

B

A

B

A

B

A

包装タグ

製品タグ

梱包タグ

長距離・輸送単位番号、梱包数送り先等中～長距離・製品品番、製造者、販売者等短～中距離・製品品番、製造者等

A

B

C

(3)

2. RF タグのエアーインターフェイス 2-1. RF タグのデータ領域の構造 RF タグについては ISO/IEC 18000-63 に限定する。図 4 に RF タグのメモリ構造を示す。RF タグのメモリは基本的に 4 つのデータセグメントから構成されている。4 つのセグメントは RESERVED （メモリバンク 00-MB002）、UII（MB012）、TID（MB102）、ユーザ（MB112）である。 MB002はアクセスパスワードやキルパスワードのパスワード管理を行う。アクセスパスワードはメモリの情報にアクセス権限を設定するもので、キルパスワードはデータの消去権限を設定するものである。MB012はデータを検証するためのチェックサム（CRC-16）、格納するデータのプロトコル管理（PC）、格納するユニークな物品識別子とそのデータ（UII）から構成される。UII データは ISO/IEC 15459 シリーズに従ってデータを格納する。MB012の UII 領域のメモリ容量は EPC を除くアプリケーションでは 240 ビット以上が条件になっている。図 4 データ領域の構造 MB102は RF タグまたはインレイ製造企業のユニークな識別番号（タグ ID、TID）が書き込まれ、永久ロック（書き換え、消去できない）される。RF タグに関してプライバシー問題が提起されたとき、GS1 が中心となり、TID を使用しないエアーインターフェイスを考案した。これが ISO/IEC 18000-63 である。システム設計者は TID を使用しないシステム構築を目指すべきである。MB11₂ はユーザが自由に利用することができるデータ領域である。データ内容は当事者間で決めることもできる。MB11₂のデータ構造は 1 次元/2 次元シンボルおよび OCR と RF タグ間の変換を可能とする ISO/IEC 15434 のデータフォーマット 06（ASC MH10 データ識別子を使用するデータ）および ISO/IEC 15418 に適合しているものとする。平たく言うと、MB01₂の UII は 1 次元シンボルへのデータ格納方法で、MB112は 2 次元シンボルへのデータ格納方法を採用している。MB112の最初の 16 ビットを DSFID（Data Storage Format Identifier）およびプレカーソルと呼びアクセス方法（タグへのデータエンコード方法）やデータフォーマットを規定している。 2-2. MB012の PC MB012のプロトコル管理（PC）ビット構造を図 5 に示す。MB012のメモリ構造は、CRC（16 ビット）、 PC（16 ビット）および UII となっている。EPC を除くアプリケーションでは全体が 240 ビット以上という規定になっているが、最近は 240 ビットを超える RF タグも商品化されている。CRC は RF タグとリーダ・ライタ間で自動的に生成しているものが多い。したがって、ホストコンピュータは CRC を考慮する必要はない（CRC エラー時の再読み取り・書き込み処理は必要）。次の 16 ビットは PC ビットであるが、PC ビットには正確に情報を格納しなければならない。ビ USER（optional） TID UII RESERVED Bank 11 Bank 10 Bank 01 Bank 00 1Fh 0Fh 10h 00h MSB LSB TID [15:0] ・・・ TID [31:16] MSB LSB 2Fh 1Fh 0Fh 20h 10h 00h UII [15:0] UII [N:N-15] PC [15:0] CRC-16 [15:0] ・・・ 3Fh 2Fh 1Fh 0Fh 30h 20h 10h 00h MSB LSB Access Password [15:0] Access Password [31:16] Kill Password [15:0] Kill Password [31:16] ・・・ MSB LSB ・・・ Precursor,DSFID [15:0] 1Fh 0Fh 10h 00h RFU [15:0]

使用RFタグ

ISO/IEC18000-63

ISO/IEC18000-3M3

USER（optional） TID UII RESERVED USER（optional） TID UII RESERVED Bank 11 Bank 10 Bank 01 Bank 00 1Fh 0Fh 10h 00h MSB LSB TID [15:0] ・・・ TID [31:16] 1Fh 0Fh 10h 00h MSB LSB TID [15:0] ・・・ TID [31:16] TID [15:0] ・・・ TID [31:16] MSB LSB 2Fh 1Fh 0Fh 20h 10h 00h UII [15:0] UII [N:N-15] PC [15:0] CRC-16 [15:0] ・・・ 2Fh 1Fh 0Fh 20h 10h 00h UII [15:0] UII [N:N-15] PC [15:0] CRC-16 [15:0] ・・・ 3Fh 2Fh 1Fh 0Fh 30h 20h 10h 00h MSB LSB Access Password [15:0] Access Password [31:16] Kill Password [15:0] Kill Password [31:16] ・・・ 3Fh 2Fh 1Fh 0Fh 30h 20h 10h 00h MSB LSB Access Password [15:0] Access Password [31:16] Kill Password [15:0] Kill Password [31:16] ・・・ Access Password [15:0] Access Password [31:16] Kill Password [15:0] Kill Password [31:16] ・・・ MSB LSB ・・・ Precursor,DSFID [15:0] 1Fh 0Fh 10h 00h RFU [15:0]

使用RFタグ

ISO/IEC18000-63

ISO/IEC18000-3M3

(4)

ット x10～x14 には UII のデータ長を書き込まなくてはならない。最大 32 ワードになる。ビット x15～x17 は以下のように設定する必要がある。

図 5 PC のビット構造

（a）ビット x15：MB11₂にデータを持たない場合は 0、持つものは 1 （b）ビット x16：PC に拡張部がない場合は 0、ある場合は 1

（c）ビット x17：UII に EPC を格納する場合は 0、EPC 以外を格納する場合は 1

一般的にサプライチェーン（EPC 以外）では x15：1、x16：0、x17：1 に設定する。x15 を 1 に設定した場合は、x18～x1F に ISO/IEC 15961 で規定される AFI を格納しなければならない。 2-3. MB112の DSFID およびプレカーソル MB11₂の最初の 8 ビットを DSFID と呼び次の 8 ビットをプレカーソルと呼んでいる。DSFID は図 6 に示すようにストレージ様式を決定する。ストレージ様式は 8 ビットのコードで更にアクセス方法とデータフォーマットに分類される。図 6 DSFID のビット構造アクセス方法はサプライチェーン用途ではノンディレクトリ方式を推奨している。ビット 2（x02） 1F 1E 1D 1C 1A 19

Numbering System Identifier (NSI)/ Application Family Identifier (AFI) 18 EPC/ ISO 17 0/1 XPC 16 0/1 0/1 User Mem. Length Indicator 1B 15 14 13 12 11 10

Protocol Control Bits run from 10 _HEX– 1F_HEX

000002: 1 Word , UII 10 Hex～1F Hex

000012: 2 Words , UII 10 Hex～2F Hex

000102 : 3 Words , UII 10 Hex～3F Hex

.

Bit 15:0 Non User Memory

Bit 15:1 User Memory Bit 17 : 0 EPC,NSI_{Bit 17 : 1 ISO,AFI} Bit 16 : 0 No Extension

Bit 16 : 1 Extension 32Word

1F 1E 1D 1C 1A 19

Numbering System Identifier (NSI)/ Application Family Identifier (AFI) 18 EPC/ ISO 17 0/1 XPC 16 0/1 0/1 User Mem. Length Indicator 1B 15 14 13 12 11 10

Protocol Control Bits run from 10 _HEX– 1F_HEX

000002: 1 Word , UII 10 Hex～1F Hex

000102 : 3 Words , UII 10 Hex～3F Hex

.

Bit 15:0 Non User Memory

Bit 15:1 User Memory Bit 17 : 0 EPC,NSI_{Bit 17 : 1 ISO,AFI} Bit 16 : 0 No Extension

Bit 16 : 1 Extension 32Word

Content Value Accuses method Tag-Data-Profile 3 Packed-Objects 2 Directory 1 No-Directory 0 Data format Content Value UPU 11 GS1 9 Data-Identifier-Algorithm 10 ISO/IEC 6523 4 ISO/IEC 15459 5 ISO/IEC 15961 Combined 8 IATA-Baggage 12 ISO/IEC 15434 3 Root-OID Encoded 2 Full featured 1 Not Format 0

Accuses

method

ISO/IEC15961-1 sec 7.2.5 ISO/IEC15961-2 ISO/IEC15962 Annex D ISO/IEC15961-1 sec 7.2.4 ISO/IEC15962 sec 11

4

3

2

1

0

5

6

7 Data format

Extend Syntax x00 x07 Content Value Accuses method Tag-Data-Profile 3 Packed-Objects 2 Directory 1 No-Directory 0 Content Value Accuses method Tag-Data-Profile 3 Packed-Objects 2 Directory 1 No-Directory 0 Data format Content Value UPU 11 GS1 9 Data-Identifier-Algorithm 10 ISO/IEC 6523 4 ISO/IEC 15459 5 ISO/IEC 15961 Combined 8 IATA-Baggage 12 ISO/IEC 15434 3 Root-OID Encoded 2 Full featured 1 Not Format 0 Data format Content Value UPU 11 GS1 9 Data-Identifier-Algorithm 10 ISO/IEC 6523 4 ISO/IEC 15459 5 ISO/IEC 15961 Combined 8 IATA-Baggage 12 ISO/IEC 15434 3 Root-OID Encoded 2 Full featured 1 Not Format 0

Accuses

method

ISO/IEC15961-1 sec 7.2.5 ISO/IEC15961-2 ISO/IEC15962 Annex D ISO/IEC15961-1 sec 7.2.4 ISO/IEC15962 sec 11

4

3

2

1

0

5

6

7 Data format

Extend Syntax x00 x07

(5)

は拡張構文を表すインジケータであるが、サプライチェーン用途ではビット 2＝0 を推奨している。ビット 3（x03）からビット 7（x07）はデータフォーマットを表しているが、サプライチェーン用途では x03 を推奨している。x03 の DSFID 値は ISO/IEC 15434 に基づいたディレクトリなしのデータ構文を使用することを表している。図 7 プレカーソルのビット構造表 1 6 ビットキャラクタエンコード表文字コード 2 進数文字コード 2 進数文字コード 2 進数文字コード 2 進数 Space 100000 0 110000 @ 000000 P 010000 <EOT> 100001 1 110001 A 000001 Q 010001 <Reserved> 100010 2 110010 B 000010 R 010010 <FS> 100011 3 110011 C 000011 S 010011 <US> 100100 4 110100 D 000100 T 010100 <Reserved> 100101 5 110101 E 000101 U 010101 <Reserved> 100110 6 110110 F 000110 V 010110 <Reserved> 100111 7 110111 G 000111 W 010111 ( 101000 8 111000 H 001000 X 011000 ) 101001 9 111001 I 001001 Y 011001 * 101010 : 111010 J 001010 Z 011010 + 101011 ; 111011 K 001011 [ 011011 , 101100 < 111100 L 001100 \ 011100 - 101101 = 111101 M 001101 ] 011101 . 101110 > 111110 N 001110 <GS> 011110 / 101111 ? 111111 O 001111 <RS> 011111 プレカーソルは図 7 に示すように、オフセット、コンパクションタイプおよびフォーマットエ

C

B

A

9

8 D

E

F

Format Envelope

Offset x08 x0F

Compaction Type

Compaction type 5 bit code 011 Numeric 010 Integer (binary) 001 Application defined 000 Content Binary Octet string 110 7 bit code 101 UTF-8 string 111 6 bit code 100 Binary data 1001 Format Envelope UN/EDIFACT 0100 ANSI ASC X12 0011 Complete EDI 0010 Transportation 0001 Content Binary

CII Syntax Rules 1000 ISO/IEC 15459 DI 0110 TEI 1100 GS1 AI 0101 ISO/IEC15962 Annex D

ISO/IEC15962 Annex E ISO/IEC15434

C

B

A

9

8 D

E

F

Format Envelope

Offset x08 x0F

Compaction Type

Compaction type 5 bit code 011 Numeric 010 Integer (binary) 001 Application defined 000 Content Binary Octet string 110 7 bit code 101 UTF-8 string 111 6 bit code 100 Binary data 1001 Format Envelope UN/EDIFACT 0100 ANSI ASC X12 0011 Complete EDI 0010 Transportation 0001 Content Binary

CII Syntax Rules 1000 ISO/IEC 15459 DI 0110 TEI 1100 GS1 AI 0101 ISO/IEC15962 Annex D

(6)

ンベロープの情報が含まれる。ビット 8（x08）はオフセットを表し 02はオフセットなし、12は追加バイトがプレカーソルの一部として続くことを表している。ビット 9 からビット B はコンパクションタイプを表している。コンパクションタイプは 8 種類設定されているがサプライチェーン用途では 1002の 6 ビットコンパクションを推奨している。サプライチェーン用途での 6 ビットコンパクションは 7 ビットアスキーから最上位ビットを削除したものではない。サプライチェーンで用いる 6 ビットコンパクションのコード表を表 1 に示す。表 1 では ISO/IEC 15434 で使用している特殊文字が使用できるようになっている。ビット C～ビット F にはフォーマットエンベロープの情報が格納される。フォーマットエンベロープは MB112に格納されるデータの詳細構造を規定している。具体的には、フォーマットエンベロープは DSFID のデータフォーマットを 0x03（ISO/IEC 15434）指定した場合の ISO/IEC 15434 で規定されるフォーマットヘッダを指定する。サプライチェーンでは 01102を推奨している。 2-4. メモリ容量の計算 ISO/IEC 18000-63 でのメモリ容量の計算は次のように行う。 UII（MB012）バンクは PC と UII から構成され、図 4 の CRC は一般的にハードウェアで行われているので、 UII のメモリ容量＝UII バンクの容量－PC（16 ビット）で計算するとよい。ユーザ（MB11₂）バンクは DSFID、プレカーソル、ユーザから構成され、図 4 の RFU は使用されていないので、ユーザのメモリ容量＝ユーザバンクの容量－DSFIDE（8 ビット）－プレカーソル（8 ビット）で計算するとよい。 3. 読み取りメカニズム 3-1. アプリケーション側から見た必要なデータ 1 次元/2 次元リーダからのデータ出力は、（a）読み取ったデータを多数回一致し、確定したデータのみを一回だけアプリ側に送る。（b）センサーからいったん同じシンボル画像がなくなると、同一データの 2 度読み防止機能が解除される。従って、同じデータが入力された場合、アプリ側は 2 度入力として処理してしまう。したがってこれは、結果的にオペレータのミスとして処理され、アプリ側は何も処理しない。必要なデータが一回だけアプリ側に送信されるのが理想である。RFID のリーダ・ライタは読み取ったデータをできるだけ多くアプリ側に送信するように設計されている。例えば、リーダ・ライタから 100 回/秒以上のデータが送信される場合があるため、アプリ側で処理することができない。したがって、中間のミドルウェアをかませる必要がある。現在、RFID の対象となるシステムはほとんどが 1 次元/2 次元シンボルを利用しており、これを RFID 化した場合でもアプリ側のシステムは変更しないのが通例である。したがって、極力 RFID のリーダ・ライタをミドルウェアに接続し、ミドルウェアの出力を 1 次元/2 次元リーダの出力に合わせる努力が重要になる。 RFID のリーダ・ライタの制御は（a）一度、データを読み取ったタグは一定時間読み取らないように処理する。「一定時間」は原則的に RF タグがリーダ・ライタの読み取り範囲を通過する時間であるが、読み取り範囲内での作業停止が長くなると支障をきたす場合がある。HF タグではアンチコリジョンのメカニズムが異なるためこの機能は実現できない。RF タグの性能によってはこのスリープ時間が大きくばらつくものがあり、バラツキの最小スリープ時間内にリーダ・ライタの読み取り範囲を通過するようにするのが望ましい。（b）一度、データを読み取ったタグを励起されている間は読まないという処理だけを行わない方がよい。リーダ・ライタの読み取り範囲は RF タグ間の干渉、複数のアンテナ間の干渉、読み取り範囲にある物質の影響などにより、リーダ・ライタの読み取り範囲内であっても部分的に RF タグが励起されないエリアが存在するため、通常、チャタリングと呼ばれる現象が起こる。このチャタリングの影響を避けるために、一定時間読み取らないような処理

(7)

が必要になる。 3-2. 選択的読み取り自動車業界での RF タグの利用は、車の識別（I：VIN）、部品識別（25S）、輸送資材識別（25B）、輸送単位識別（J、1J～6J、現品表の同じ）、かんばん識別（25K）や便タグ識別（識別子未定）などがあり、これらのタグはすべて ISO/IEC 18000-63 を使用するため、「かんばん」を読ませる工程では「かんばん」以外のタグをフィルタリングして読ませる必要がある。また、自動車業界でも EPC コードを使用する企業もあり、この EPC コードに対応するかどうかを事前に確認する必要がある。フィルタリングの種類を以下に述べる。最低限（e）～（h）のどれかを実現する必要がある。（a）フィルタリング機能その1 MB012のPCビットのビット17でISOタグとEPCタグの選択的読み取りができる。EPC：ビット17＝0、 ISO：ビット17＝1 （b）フィルタリング機能その2 MB012のPCビットのビットhex18～hex1Fのデータ（AFI）で選択的読み取りができる。（c）フィルタリング機能その3 MB012のPCビットのビットhex17～hex1Fのデータ（AFI）で選択的読み取りができる（PCビットのビット17とAFI）。（d）フィルタリング機能その4 MB012のPCビットのビット17（EPC：ビット17＝0）とUII（ビットhex20～）の先頭8ビットで（ビットhex20～hex27）で選択的読み取りができる。（e）フィルタリング機能その5 MB012のUII（ビットhex20～）の先頭1～3キャラクタで選択的読み取りができる。（J、1J～6J、 25P、25S、15K、25K・・・・）（f）フィルタリング機能その6 MB01₂のPCビットのビット17（ISO：ビット17＝1）とUII（ビットhex20～）の先頭1～3キャラクタで選択的読み取りができる。（J、1J～6J、25P、25S、15K、25K・・・・）（g）フィルタリング機能その7 MB012のUII（ビットhex20～）の先頭1～3キャラクタの複数種類の選択的読み取りができる。（1J と2J、25Sと25B、15Kと25K・・・・）（h）フィルタリング機能その8 MB012のPCビットのビット17（ISO：ビット17＝1）とUII（ビットhex20～）の先頭1～3キャラクタの複数種類の選択的読み取りができる。（1Jと2J、25Sと25B、15Kと25K・・・・） 3-3. データ圧縮機能 8ビット（1キャラクタ）のデータをアプリ（ホストコンピュータ）からミドルウェアに送付するのでミドルウェアでプレカーソルのコンパクションタイプに対応してバイナリ、6ビットおよび 7ビットに変換してリーダ・ライタに送付し、RFタグに書き込む。ここでの6ビットコンパクションはISO 17364～ISO 17367で指定されるキャラクタセットを意味する。 3-4. データの連結機能 MB01（UIIバンク）とMB112 2とを連結して1つのデータとして使用する場合がある。この場合、MB012 のデータとMB112のデータとを連結してホストコンピュータに送る。 3-5. 電源 ON シーケンス 1 次元/2 次元リーダはほとんどがメニュー機能を持っており、設定された条件が不揮発性メモリに記憶されるため、電源 ON 時のシーケンスは不要であるが、RFID のリーダ・ライタでこの機能を持っているものはないので、毎回、電源 ON 時に条件設定をする必要がある。