当前位置：文档库 › EPCglobal 教材中文版_v1.1

EPCglobal 教材中文版_v1.1

2009
Foundation Certificate in EPC Architecture Framework 認證考試標準訓練教材
EPCglobal Taiwan
2009/9

目錄 1 前言 .......................................................................................................................................... 3 1.1 1.2 1.3 1.4 2 ARCHITECTURE FRAMEWORK 概論 ............................................................................................... 4 ARCHITECTURE FRAMEWORK 之目的 ........................................................................................... 6 基本技術原理 ....................................................................................................................... 7 ARCHITECTURE FRAMEWORK 基礎 ............................................................................................... 8
TAG & READER AIR PROTOCOL ................................................................................................ 12 2.1 2.2 2.3 2.4 2.5 2.6 UHF RFID 讀取器 ................................................................................................................. 12 READER 存取及控制之通訊協定.......................................................................................... 13 READER PROTOCOL ................................................................................................................... 14 LOW-LEVEL READER PROTOCOL (LLRP) ........................................................................................ 14 READER MANAGEMENT ............................................................................................................. 15 DISCOVERY, CONFIGURATION & INITIALIZATION (DCI)...................................................................... 16
3
APPLICATION LEVEL EVENTS (ALE)........................................................................................... 17 3.1 3.2 ALE 如何運作？ .................................................................................................................. 18 ALE 之功能介紹 .................................................................................................................. 18
4
EPC INFORMATION SERVICE (EPCIS) ........................................................................................ 21 4.1 4.2 4.3 物件交換的相互關係 ......................................................................................................... 23 資料交換的相互關係 ......................................................................................................... 23 企業間資料流通關係 ......................................................................................................... 24
5 6 7
OBJECT NAME SERVICE（ONS） ............................................................................................. 26 （） DISCOVERY SERVICE ................................................................................................................ 29 國際標準化組織(ISO，INTERNATIONAL ORGANIZATION FOR STANDARDIZATION) ................ 31 ，國際標準化組織
2

1
前言
EPCTM (簡稱 EPC)構想源自於 MIT 麻省理工學院----一項關於自動化辨識系統 (Automatic Identification Technology)的研究，利用早在第二次世界大戰已使用的 RFID(Radio Frequency Identification)科技，進行創新應用。集結全球主要零售商，MIT 於 1999 年成立 AUTO-ID Center，以零售業為出發點的構想下，成功研發 EPCTM。2003 年 10 月，Auto-ID Center 移轉 EPC 給 EPCglobal Inc.，其所代表的意義為 EPC 正式由學術研究進入商業應用階段，直到現在， EPCglobal 接手繼續標準研發與全球推廣工作。在 EPCglobal 裡，結構框架（Architecture Framework）為其相關標準之集合體，包括軟體、硬體、資料標準以及核心服務(Core service)等，由 EPCglobal、及其代理人或市場第三方設備供應商共同經營與運作，經由產品電子碼（EPC）之使用，強化商業流和電腦應用的共同目標，達成有效供應鏈管理。 EPCglobal 結構框架（Architecture Framework）的主要受益者，包括終端用戶（End user）和解決方案提供者（Solution Provider），其同時也是 EPCglobal 核心服務的使用者以及參與 EPCglobal 標準制定者。終端用戶採用 EPCglobal 標準和核心服務作為其商業運作的重要工具。而解決方案提供者為協助終端用戶使用 EPCglobal 標準和核心服務之重要夥伴。因此，由 EPCglobal 成員之間交互使用 EPCglobal 結構框架（Architecture Framework）內之構件所產生的綜效，稱為”EPCglobal Network”。
圖 1 、 EPCglobal Architecture Framework
3

1.1 Architecture Framework 概論
結構框架（Architecture Framework）概念分為三層：Identify 識別、Capture 擷取以及 Exchange 交換。結構框架（Architecture Framework）即在定義這三層內的標準介面與各構件扮演的角色。圖 2 、 EPCglobal Architecture Framework 概念圖
4

Identify 識別：對於大多數 EPCglobal Network 使用者而言，在供應鏈中實體物識別件的移動就像是貨物交易，其活動包括運送、接收等，需要透過 EPC 賦予物件以統一識別碼。EPCglobal 結構框架（Architecture Framework）定義物件識別標準，得以進行物件識別和交換，確保當某一使用者將實體物件送至另一使用者時，立即知道這個實體物件的 EPC 碼且能正確被判讀。圖 3 、 Identify：工廠出貨時，物流商讀取棧板標籤以識別貨物。
?
Capture 擷取擷取：為了分享 EPC 資料，使用者在自己的應用範圍內為新物件編製 EPC 碼，藉由讀取 EPC 碼以追蹤物件的移動，並收集資訊存放在使用者內部的紀錄系統。EPCglobal 結構框架（Architecture Framework）定義收集與紀錄 EPC 資料目的之主要基礎建設構件的介面標準，讓用戶能以相容互通的購件建構自家的內部系統。圖 4 、 Capture：物流商識別貨物後，記錄收集到的資料
Exchange 交換交換：在 EPCglobal Network 內得以相互交換資料，以及物件走出自家範圍外的移動資訊之可視度(Visibility)改善等使得終端用戶因此受惠。 EPCglobal 結構框架定義 EPC 資料交換標準，提供方法讓一終端用戶與約定的
5

另一用戶或是一般大眾分享 EPC 資料；同時，並提供 EPC Network 服務和其他共享服務之使用。圖 5、 Exchange：供應鏈不同成員針對各自所收集到的物件資訊進行交換分享
DATA EXCHANGE
1.2 Architecture Framework 之目的結構框架（Architecture Framework）的目標為使終端用戶真正受益，因此定義其軟體、硬體、資料標準與核心服務，並說明其間的關聯性，以下針對各個目標逐一說明。標準的角色扮演協助交易伙伴之間資訊與實體物件之交換：交易伙伴之間欲交換資訊，須先就結構與資料交換的定義和結構，以及交換的執行機制等取得共識。 EPCglobal 標準指的是資料標準和跨公司資料交換之標準。同樣地，交易伙伴間如欲交換實體物件，則必須先就實體物件附加雙方都知道的產品電子碼一事取得共識。EPCglobal 標準具備 RFID 設備與 EPC 編碼資料標準的規格。促進系統構件具競爭市場之存在價值：EPCglobal 標準定義系統構件之間的介面，促進不同廠商所生產的構件與構件間的互運性。因此可提供終端用戶不同的選擇，且不同系統和不同交易夥伴間得以交換資訊順暢。鼓勵創新：EPCglobal 標準定義的是介面，而非實行面。在介面標準確保不同系統之間的互運性要求下，鼓勵實施者創新自行開發的產品與系統。全球標準 EPCglobal 致力於全球標準的創造與應用。這個方針確保 EPCglobal Architecture Framework 能在全球各地使用，並為支援結構的方案提供者創造利基。EPCglobal 標準係開發作為全球使用，EPCglobal 致力於採用既有的全球標
6

準而且 EPCglobal 與知名全球標準組織共同批准 EPCglobal 內部開發的標準。，開放系統 EPCglobal Architecture Framework 之發展保持開放與客觀中立性。所有結構元素之間的介面以公開標準制訂。EPCglobal 標準係開發作為全球開放性使用，透過 EPCglobal 標準發展程序或是其他標準組織之等同程序，由 EPCglobal 社群組織共同制定。參與開發的團體都需通過 EPCglobal 標準開發程序，或其他標準組織中的類似程序。EPCglobal 的智慧財產權政策可確保 EPCglobal 標準能以自由與開放的權利，在一致性並最佳的系統中執行。
基本技術原理 1.3 基本技術原理 EPCglobal 結構框架（Architecture Framework）各單元背後的技術原理（）支撐後續標準及核心服務之發展，業者先有這些概念後，將有助於後面告章節的認知。唯一身份（唯一身份（Unique Identity）） EPCglobal 網路結構的一項基本原理是，為實體物件、貨物、位置、資產、或其他被用來追蹤的實體等分派一個獨一無二的身份。在 EPCglobal 網路結構中，這個獨特身份就是根據 EPCglobal 標籤資料規格所定義的產品電子碼其在結構框，架（Architecture Framework）中的特性如下：（） ? 唯一/序列化（Uniqueness/Serialization）：不重複物件編碼可續列化追蹤 ? 普遍性（Universality）：普遍適合不同產業與領域 ? 相容性（Compatibility）：可容納現存之編碼體系(轉碼機制) ? 聯邦化（Federation）：EPC 不是單一命名結構，是許多命名結構的邦聯 ? 擴充性（Extensibility）：由於相容與聯邦化促進大量採用可不斷的擴充 ? 表示法（Representation）：二位元與 URI ? 分散化（Decentralized）：號碼配置分散不衝突 ? 結構（Structure）：是結構化編碼不是隨機的 ? 輕省性（Light Weight）：結構化編碼是識別碼,不攜帶其他資訊分散實施（分散實施（Decentralized Implementation）） EPCglobal 網路希望將所有企業連結至單一全球網路。在邏輯上來說，EPCglobal 網路屬於由所有 EPCglobal 參與成員共同的資源。要考量延展性必然意味著無法由某中央管理機構，使用單一實體場所的電腦系統來執行這個共同資源。因此 EPCglobal 結構框架（Architecture Framework）採取分散作法，將功能散佈在（）數個服務個別 EPCglobal 成員的場所中。有些設施會由 EPCglobal 終端用戶自行營運。
7

資料標準垂直分層（資料標準垂直分層（Layering of Data Standards）） EPCglobal結構框架（Architecture Framework）要滿足各種產業所需的資料交換標準。不過，每個產業對於必須交換的資料與其代表之意義都有特別規定。因此， EPCglobal標準以分層模式設計資料的掌控。在每一個資料標準內，存在所有使用 EPCglobal網路產業所通用的框架層次（Framework Layer）。在這之上有數層垂直於整體框架的資料標準，分別對應至個別產業的特別需求。
軟體標準分層實施（軟體標準分層實施（Layering of Software Standards）） EPCglobal 結構框架（Architecture Framework）主要著重於從商業流程中，藉由產品電子碼與射頻識別系統（RFID）的使用而開採新資料。多數 EPCglobal 標準的資料內容並不會倚賴如網路服務、XML、AS2 與 EDI 等之特定執行技術。每個企業都會有出自本身的需求與偏好，且不可避免地將隨著時間演變。為了提升 EPCglobal 標準可能的應用範圍，EPCglobal 軟體標準儘可能採用分層模式定義。在這種模式中，資料及（或）服務等的抽象內容將藉由如 UML 等之技術中立敘述語言加以定義。另一方面，抽象的規格與 XML 或網路服務等特定執行技術之間將被賦予關連性。擴充性（擴充性（Extensibility）） EPCglobal結構框架（Architecture Framework）清楚體認到演變是不可避免的。所有EPCglobal標準都具有接納擴充的設計原理。擴充包括標準本身藉推出新版而提升的部份，以及由特定企業、合作團體或產業垂直整合而開發出來，不適合在 EPCglobal規範中處理的擴充延伸部分。所有EPCglobal標準都有相同的擴充延伸點，並有清楚的機制程序。在儘可能的情況下，擴充機制可提升向下相容性與向上相容性。延伸機制同時允許非標準範圍的延伸擴充，得以由多數團體單獨進行而不致產生衝突。 1.4 Architecture Framework 基礎產品電子碼) EPC(產品電子碼產品電子碼產品電子碼是 EPC 網路架構的主要鍵值。產品電子碼被寫入 RFID 電子標籤中，使實體品項、貨物、位置、資產與其他可藉由 EPCglobal 網路加以追蹤，來達成該產業的商業目標。產品電子碼就像是將 EPCglobal 網路中所有流通資料綁在一起的繩子，同時也是 EPCglobal 結構框架（Architecture Framework）中每個角色與介面的中心部分。 EPC 是透過 RFID 標籤，被應用在識別實體物件上。而標準化的 EPC 標籤編碼
8

資料包括可獨一無二辨識各別物件的 EPC 號碼，及有效區分品項類別（Object Class）和品項序號（Serial Number）的過濾值（Hilter Value ）等。 T DS 1.4 主要是定義 EPCglobal 標籤資料標準亦即規範 RFID 標籤須符合 EPC ， Class-1 Gen 2 標準並且運作於 860 至 960MHz 間的頻率。此標準定義的範圍包括標簽中 EPC 的資料如何標準化、如何編碼、以及如何供後端 EPC 資訊系統使用。 EPC 碼被設計為支援各種產業中不同識別需求的編碼方案，這些不同的編碼方案都有其對應的領域；在 1.4 的版本中，編碼方案有：通用識別碼（GID）、序列化全球交易品項識別碼（SGTIN）、序列化運送容器碼（SSCC）、全球位址識別碼（GLN）、可回收資產全球識別碼（GRAI）、個別資產全球識別碼（GIAI）、全球服務關係碼（GSRN）、全球文件類型識別碼（GDTI）、以及美國國防部專用的 DOD 結構碼。圖 6、EPC 碼之結構
SGTIN: Serialized Global Trade Item Number EPC Manager (管理者管理者) 管理者在 EPCglobal 結構框架（Architecture Framework）中使用的身份（Identity）主要特徵就是「分散」。分散是藉由 EPC 管理者的概念來達成的。在本文中，「EPC 管理者」一詞指的是經過發佈中心（Issuing Agency）授權使用某部分 EPC 命名範圍權利的 EPCglobal 終端；也就是說，發佈中心已經正式的將特定編碼系統中某部分區塊的產品電子碼分配給 EPC 管理者，之後 EPC 管理者可以在沒有發佈中心的干預之下獨立分派物件類別與序號給實體物件或品項。在某個區塊。中，EPC 管理者可說是 EPC 的「主管單位」
9

EPC Manager Number(管理者代碼管理者代碼) 管理者代碼發佈中心指派 EPC 區塊給 EPC 管理者的方式，是發給 EPC 管理者一組單一號碼，叫做「EPC 管理者代碼」。終端使用者可能有數個管理者代碼，因此同時管理數個 EPC 區塊。產品電子碼定義中的所有編碼系統結構，能讓 EPC 管理者代碼在任何表達方式中都是以「指定欄位」出現。當 EPC 管理者代碼在任何表達方式中都是以指定欄位出現時，能讓所有系統立刻從 EPC 中找出相關的 EPC 管理者。這項特性對於確保整體系統的延展性相當重要，因為它讓原本必須集中管理的服務項目得以適當地分散給每個 EPC 管理者。例如，ONS 的搜尋基本上像是在一個大型地圖上搜尋整個 EPCIS 服務的某個 EPC，但是當 EPC 管理者代碼被放在指定欄位時，ONS 的搜尋便只需在一部分較小的地圖中執行，這些較小的個別 EPC 區塊則由不同的 EPC 管理者負責維護。當 EPC 碼分配給 EPC 管理者的同時，也分配了 EPC 管理者代碼。只要 EPC 碼中的 EPC 管理者欄位包含特定的 EPC 管理者代碼，並符合 EPC 標籤資料規格，EPC 管理者可自由授與任何 EPC 碼。代碼的「區塊」便只包括在指定欄位上有該 EPC 管理者代碼的所有 EPC。 GS1 編碼轉換目前由 EPC 標籤資料規格定義的編碼系統，許多是建立在既有產業編碼系統。例如，以 GS1 系列代碼定義的 EPC 有七種：SGTIN、SSCC、SGLN、GRAI 、 GIAI、GSRN, and GDTI。在這些 GS1 代碼中，EPC 管理者代碼部分是相同的，如同作為 GS1 代碼基礎的 GS1 公司前置碼（Company Prefix）。GS1 系列 EPC 的其他欄位是由 GS1 代碼現有欄位所組成。整體而言，這種嵌入可應用在任何具備管理者結構的現有編碼系統；也就是藉由整體配置獨特標頭號碼或欄位，進而達到分派動作的任何現有編碼系統。例如，美國國防部利用自己的 CAGE 與 DoDAAC 代碼發展出一套 EPC 編碼系統，單獨分配給 DoD 供應商，因此在發展「DoD 系列」編碼系統的 EPC 時，可作為 EPC 管理者代碼使用。將 EPC 管理者代碼分配給 EPC 管理者的同時也分配了某個區塊的代碼給 EPC ，
10

管理者。因為產品電子碼包括數個編碼系統之間的結盟，意味著 EPC 管理者代碼的 EPC 碼「區塊」並不一定是連續號碼，而通常是 EPC 管理者代碼相關身份類型中所包含的相連區塊例如當 EPC 管理者代碼屬於 GS1 公司前置碼時。，， EPC 管理者將被給予七種 GS1 系列 EPC 碼中的其中一個區塊（SGTIN SSCC 、、 SGLN、GRAI、GIAI、GSRN, and GDTI）。但是當 EPC 管理者代碼屬於美國國防部 CAGE/DoDAAC 代碼時，EPC 管理者將是在「DoD 建構」的編碼方案內被授予之 EPC 單一區塊。
11

2
Tag & Reader Air Protocol
在標籤資料識別與讀取器資料擷取之間擔任溝通橋樑的UHF Class 1 Gen 2標準（簡稱Gen 2），主要定義RFID標籤和詢答器在超高頻（860 MHz至960 MHz）、被動式反向散射、以及詢答器先言（Interrogator-Talks-First，ITF）之環境下物理及邏輯上的溝通規範。在被納入為ISO/IEC國際標準18000-6C後，已經成為目前供應鏈RFID應用的主流標準，目前EPCglobal正式公布的版本為1.2.0。此版本乃建基於1.1.0版，但比1.1.0版更符合品項層級標籤（Item-Level Tagging）貼附的需求規格，亦即針對ILT特性進行強化。新增功能包括：(1) 增加了標籤使用者記憶體Protocol Control Bit 15h 、(2) 有別於前一版本在標籤使用者記憶體上只能執行完全鎖定，1.2.0版新增了部分區塊鎖定（BlockPermaLocking）功能、(3) 延伸kill指令功能以及(4) 加強標準向上與向下相容能力。其功能為：將指令從RFID讀取器傳遞到標籤。從標籤回應命令將資訊傳到RFID讀取器。當RFID讀取器範圍內有大量的標籤時，讀取器能逐一識別每個標籤。提供標籤與讀取器彼此干擾最小化方式。標籤及讀取器間傳遞的資訊包含兩個部分：第一是從讀取器至標籤所下達的命令集，例如Read(讀取)、Write(寫入) 及Kill(殺除)等指令。第二則是儲存於標籤中的資料如EPC號碼及CRC(循環冗餘核對碼)。 2.1 UHF RFID 讀取器讀取器功能為：讀取一或多組天線範圍內RFID標籤上的EPC資料（根據讀取器通訊協定），並將EPC回傳至後端資訊系統（根據讀取器通訊協定）。當RFID標籤允許EPC碼被複寫時，讀取器可下達指令將EPC複寫至標籤（根據讀取器通訊協定）。當RFID標籤中除了已存的EPC碼之外，有額外使用者資料時，讀取器可下達指令（根據讀取器通訊協定）將使用者資料讀取並寫入（根據讀取器通訊協定）。
12

當RFID標籤包括刪除與鎖定等額外功能時，讀取器可下達指令（根據讀取器通訊協定）進行操作（根據讀取器通訊協定）。可提供其他如有條件過濾EPC號碼、統計讀取資料數等處理。一個UHF被動式標籤的RFID讀取器藉由一或多個天線在其場域內讀取標籤，過程中包含如下步驟：讀取器起始設定－包含工作環境下法規允許的使用頻段以及操作功率，例如在北美就是902-915 MHz或是2.4-2.485 GHz並用1瓦特的傳輸功率。每個頻段又會被切分成好幾個閘道（channel）以便讓接下來的讀取器運作信號通行，同時讀取器也會隨機在這些閘道間跳躍以確保所有的閘道不被外界干擾。開始盤點作業選擇天線發送一連串連續無調變的RF信號將天線可讀區內的標籤活化送出一或多個命令讓這些標籤回報其EPC號碼在等待標籤回應期間仍持續傳輸信號當某個標籤被識別時，在該標籤上執行更進一步的操作，例如讀取／寫入記憶體，或者殺除該標籤將盤點的執行結果如：讀取哪些標籤、執行哪些操作等回報予後端控制器圖7、UHF讀取器操作流程(資料來源：RFID Tribe)
2.2 Reader 存取及控制之通訊協定傳統上廠商都是在其硬體或軟體上寫出一個以上的客制化控制介面來達到這樣的目的，這些控制介面的作用幾乎都是在解決相同的問題，但是它們卻各自擁有
13

不相容的架構、控制模組、命令參數、甚至通訊協定等。即使廠商能提供驅動程式，當讀取器在硬體或韌體上有更新時，使用者的後端應用軟體也必須跟著變動，尤其當使用者採用了大量不同廠商提供的設備時，整體系統的維護更是產生可觀的成本。因此一套標準讀取器控制介面的需求就此誕生。為了解決使用者或廠商關於EPC設備上相容性的困擾，EPCglobal發展了兩項與讀取器控制介面相關的標準：Reader Protocol、Low-Level Reader Protocol。 2.3 Reader Protocol Reader Protocol之功能為：將命令從RFID讀取器傳送至物件標籤、讀取標籤資料、寫入資料至標籤、處理標籤使用者與標籤身份資料、並進行其他如殺除、鎖定等功能。以標籤讀取事件為基礎來達到讀取器控制。包括預先設定的觸發（trigger）參數、初步的過慮（filter）機制等。Reader Protocol RP）提供的是一個更抽象、從High-Level的角度、略過許多RFID （細部參數設定的標準，但提供完整的Report機制將讀取事件回傳予Client 端（或查詢端）使用者。 2.4 Low-Level Reader Protocol (LLRP) LLRP之功能為：將命令從RFID讀取器傳送至物件標籤、讀取標籤資料、寫入資料至標籤、處理標籤使用者與標籤身份資料、並進行其他如刪除、鎖定等功能。以標籤讀取事件為基礎來達到讀取器控制。 LLRP應用RFID空中通信協定的指令和計時的參數提供更底層讀取器運作，的存取控制。 LLRP目前是針對EPCglobal C1G2的空中協定，但其規格架構可以允許未來其他的空中介面協定整合進來。 LLRP應用的範圍在兩個端點之間：讀取器端（Reader）與客戶端（Client），負責兩點之間的溝通，並且與讀取器和標籤之間通信的介面協定（例如EPCglobal 之Gen 2）進行互動。
14

圖8、LLRP與空中介面應用於客戶端（Client）與標籤端(資料來源：RFID Tribe)
，可讓client端預先設定 LLRP架構中包含許多的規則（Rules）或規格（Specs）讀取器未來操作時可執行的動作，例如像是觸發時機或是標籤相關的操作，屆時讓讀取器全數負擔這些動作而不必動用到client端的資源。圖8、簡化的LLRP控制架構示意圖
2.5 Reader Management 針對RFID讀取器中，管理各個讀取器之設定、狀態監控、以及事件警示通知等功能標準，其功能為：可以搜尋RFID讀取器例如身份、天線數量等設定資訊。可以監控RFID讀取器的作業狀態，例如讀取的標籤數量、通訊頻道狀態、健全狀態監控、天線連線程度、傳遞能量等級等。
15

可控制RFID讀取器的設定，例如啟動/關閉特定天線或功能等。可以使用 RFID 讀取器管理功能，包括搜尋、韌體/軟體設定與更新，並管理讀取器耗電量。 2.6 Discovery, Configuration & Initialization (DCI) DCI 規定了 RFID 讀取器和存取控制器(Access Controller)及其運作之網路中溝通的介面標準，目的是讓讀取器及 Client 端，藉由網路的連接，能與其他設備溝通、交換組態設定資訊、並起始讀取器之運作，使讀取器的運作通訊協定（如 Reader Protocol 和 Low-Level Reader Protocol）能發揮效用，將所讀取的標籤相關資訊傳回給後端資訊系統簡單來說一符合 DCI 標準的存取控制器應提供之功能如下。。，讓讀取器能搜尋到一或多部存取控制器。讓存取控制器能搜尋到一或多部讀取器。讓讀取器能搜尋到一或多個 Client 端。讓讀取器及存取控制器之間交換及驗證身分識別資訊。讓 Client 端及存取控制器之間能驗證其連線和運作。讓存取控制器能對讀取器進行組態設定，包括升級讀取器的軟體及/或韌體。讓存取控制器能啟動讀取器，提供必要參數讓讀取器開始運作。讓讀取器及存取控制器之間能交換設備供應商特定的資訊。圖 9、存取控制器、讀取器、Client 端以及其他網路服務之關係
16

3
Application Level Events (ALE)
當商品包裝貼附內含 EPC 的 RFID 標籤後，供應鏈夥伴透過讀取器讀取在標籤中的資料，並將讀到的資料經由中介軟體，將其整理後送往企業內部的 EPCIS。由於讀取的資料很多，因此在過程中可能遇到資料重複的狀況，或是因為資料過多亦或未經彙整，造成系統處理資料時的負荷。這時便是 ALE 發揮功能的時候。 ALE 是 Application Level Events 的簡稱，雖然在 EPCglobal 的分組中它是分配在 Software Action Group 裡進行討論，但是實際上 ALE 並不是軟體，它是屬於一種介面，這個介面的設計在 1.0 版本時的目的是要能夠針對來自不同源頭的 EPC 資料在這個地方被過濾，並且加以彙整。在大多數的 EPC 流程系統與架構中，有一層的流程動作是負責來減少資料的量(volume)，尤其是針對經由讀取器讀取到的所有資料，因為這些資料來源有許多種，而資料可能是代表一般的訂單出貨，或是特殊活動，例如促銷商品，因此在標籤上涵蓋的資料以及企業後台要處理的資料對象都會因為商品管理設定的目的而有不同，必須有一個介面在這個位置負責「看守」資料的進出，以免多餘的資料或是未經整理的資料加重了系統的負擔。圖10、ALE在EPCglobal架構中負責執行的任務
ALE API
RFID Reader RFID Reader Middleware or other ALE Implementation ALE Engine Application 1
Application 2
Individual tag reads Several times / second for every tag that is in range
“Please give me: -a report every 60 seconds - from the readers at loading dock #5 -only Acme products, no item-level tags -only what’s changed”
ALE 這一層所負責的工作有下列三點：一、接受由一個到多個資料來源，例如讀取器所擷取的資料二、聚集透過某特定時段所收集的資料，經由過濾並且消除重複的 EPC 或是系統不需要的資料內容，將收集到的資料計算並且重組以降低資料量的負擔三、提供不同的資料格式並向 client 端提供 report。重點是，這些整理後的資料便可提供企業其他應用，這也是 ALE 在此的最大目的。
17

3.1 ALE 如何運作？如何運作？ ALE 在處理回應 client 端資料需求的規格大致有下列三個重點：一、選擇位置(Choose Locations)：指定必要的讀取器讀取資料並且列入提報，例如，在這個促銷活動中，相關的促銷商品送往指定的 Dock Door 22 號，並且運往 14 號貨架，那麼就透過 ALE 只設定收集該點的讀取資料；二、指定邊界(Specify boundaries)：指定何時開始擷取資料，何時將資料整合成報告。例如，持續擷取資料、特定時段擷取資料或是 trigger 資料；另外在某時段的尾聲停止擷取，或是依據現場的狀況擷取資料。三、訂定報告內容(Specify Report Content)：特別要求要哪一類的的資料，或是有哪些資料要被包含在報告裡面；或是針對報告內容是要目前的資料，還是增加或刪除某些資料；也可以針對某些資料集合進行相關的過濾動作，並且加以組合；甚至針對擷取的資料列表，或是進行運算。上述三種狀況將依據實際的情形選擇任何一種將資料送往 ALE 的應用介面。 Client 端如何向 ALE Engine 索取資料？大致上分成三種模式：一、訂閱模式(Subscribe Mode)：ALE Consumer 定義好報告格式後，將相關的定義送到 ALE Engine，當 EPCglobal 訂閱到報告時，ALE 便會依據定義提供報告給客戶端；是「Push」模式。二、被動的同步模式(Poll Mode)：依據客戶的需求，客戶主動在需求發出之後，ALE 將報告回覆至客戶端，報告是採取單一的報告發送，透過客戶端提出的定義狀態來持續進行。三、單次的立即模式(Immediate Mode)：每次客戶端提出需求，ALE Engine 便依據需求發出報告至客戶端。第二、三種都是在需求發出的同時便將報告回覆，而第一種則是必須在用戶登錄後自行擷取報告。 3.2 ALE 之功能介紹最新的 1.1 版本，除了支援 Gen2 規格及特性外，也針對標籤寫入、命名記憶區間的定義、讀取器的對應、安全特性等重點開發了新的 API，以下針對這些新的 API 重點說明。
介面名稱功能特徵描述 An interface through which clients may obtain filtered, consolidated 18
Reading API

介面名稱
功能特徵描述 EPC data from a variety of sources. RFID tags using RFID readers. In particular, clients may read
Writing API
An interface through which clients may cause operations to be performed on EPC data carriers through a variety of actuators. particular, clients may write RFID tags using RFID “readers” (capable of writing tags) and printers. In
Tag Memory Specification API Logical Reader configuration API
An interface through which clients may define interpretation schemes for structured non-EPC data from a variety of sources. An interface through which clients may define logical reader names for use with the Reading API and the Writing API, each of which maps to one or more sources/actuators provided by the implementation.
Access Control API
An interface through which administrative clients may define the access rights of other clients to use the facilities provided by the other APIs.
依照上表的說明，可以得知這五種介面的重點： Reading API ? 控制介面(提出需求與回應的介面) ? 回傳(callback)介面 (將資料 push 給登錄客戶) ? 多重相容性(相容 SOAP、HTTP、binary 等協定) 以促銷活動為例，不同的商品可能在不同的地點進行促銷，這樣的循環視為一個與 ALE Reading API client 端互動的最小單位。ALE client 端透過 ECSpec (Event Cycle Specification)來描述需要的資料類型，ALE 在選擇最適合的路徑來滿足 client 端所提出的需求。這些需求包括各種與讀取器間的互動以及讀取資料、主動的讀取標籤上的資訊，並且除去任何重複的資料、過濾所有來自下層包括 smart reader 或是 Gen2 空中介面的資訊。 Writing API ? 與 Reading API 相同，具備控制與回傳介面以系統 client 端索取報告為例，來自不同的 client 端下指令在各個讀取器讀取標籤資訊後整理回報，這樣的循環視為一個與 Writing API 下指令與回應互動的最小單位。ALE client 端透過 CCSpec (Command Cycle Specification)來描述透過怎樣的指令來運作管理標籤資訊，由於指令牽涉
19

到權限，每一個主動的 CCSpec 都必須擁有唯一的存取權(access)。ALE 在選擇同樣選擇最適合的路徑來滿足 client 端所提的需求，包括各種與讀取器間的互動以及讀取資料、透過介面的機制確保每個標籤資訊只出現一次、過濾所有來自下層包括 smart reader 或是 Gen2 空中介面的資訊。 Tag Memory API ? 負責處理使用者針對標籤記憶體中自行定義的非 EPC 格式資料 Logical Reader API ? 管理使用者定義的讀取器名稱與混合體(composites) Access Control API ? 管理 client 端依據權限或是角色辨別決定是否許可登錄
Tag1 Tag2 Tag3
Tag1 Tag2 Tag3 Tag4 Tag5 Tag5
Reader Cycle 4
Tag3
Tag3 Tag4 Tag5
Reader Cycle 5
Tag3 Tag5
Reader Cycle 6
Tag3 Tag5
Reader Cycle 7
Reader Cycle 1
Reader Cycle 2
Reader Cycle 3
Client 1 Event Cycle 1 Client 2 Event Cycle 1 Client 2 Event Cycle 2
Client 3 Event Cycle 1
Report
Report Report
Report Report
Report
透過上述的簡單說明希望能夠幫助讀者了解 ALE 的基本概念，ALE 規格設計的主要目的是為了能夠涵括一個功能完整但可供選擇的中介軟體，以便控制來自各方的各種不同裝置設備(devices)，像是若讀取器內嵌 ALE，以協助讀取器讀取標籤，而不是寫入標籤，這樣子當然也就不需要提供讀取器 Writing API。一般的硬體供應商應該依照各自的需求來參考 ALE 規格，並且選擇適當且必要的規格嵌入系統功能中。ALE 介面在 EPCglobal 網絡架構中的角色主要是為了提供一個獨立於需要 EPC 資料的架構元件、過濾及運算資料的架構元件以及需要使用該資料的應用之間。透過 ALE，能夠提供使用者或是技術服務提供者兩造間極大的助益。
20