EPCglobal ALE 1.1.1规范：应用层事件协议详解

5星 · 超过95%的资源需积分: 9 116 浏览量更新于2024-07-29 收藏 1.54MB PDF 举报

"ALE应用层事件协议，EPCglobal批准的标准，版本1.1.1，包含固定的错误修正" 《应用层事件（ALE）规范》是EPCglobal制定的一个标准，版本为1.1.1，它主要关注的是物联网（IoT）特别是电子产品代码（EPC）系统中的数据交换和事件处理。此规范分为核心规范部分，旨在提供一种在不同应用之间共享和处理EPC相关信息的标准化方法。 ALE协议的核心目标是定义一个应用层框架，用于处理EPC网络中的读写事件。这些事件可能包括RFID（射频识别）读取、写入、对象状态变化等。它允许系统集成商和开发者创建能够高效、准确地捕获和响应这些事件的应用程序，从而提高供应链的透明度和效率。此文档由EPCglobal在2009年3月13日发布，是前一版本1.1的更新，包含了对错误的修正。虽然EPCglobal在开发过程中尽力确保文档的正确性和技术准确性，但他们明确声明不对此文档的完整性和适应性提供任何形式的保证。用户在使用该文档时应理解，EPCglobal不对任何相反的声明、任何损害或损失负责。文档的免责声明强调了其提供的服务性质，指出由于技术和经验的不断进步，文档可能会需要进一步的修改。同时，它还强调未经许可的复制、修改和/或使用本文档是被禁止的，以保护知识产权。 ALE协议的详细内容可能涵盖以下几个方面： 1. 事件模型：定义了如何表示和处理各种类型的事件，如读取事件、写入事件和异常事件。 2. 接口规范：规定了应用程序与ALE服务之间的接口，以便于集成到不同的系统中。 3. 数据模型：描述了EPC数据的结构和格式，以及如何在事件中使用这些数据。 4. 安全性和隐私：讨论了如何在处理EPC事件时保护数据的安全性和个人隐私。 5. 性能和可伸缩性：指导如何设计系统以支持大规模的事件处理和高并发操作。 6. 错误处理和恢复机制：定义了当系统遇到问题时的处理流程，以确保系统的稳定运行。通过遵循ALE规范，企业可以构建出更加智能和自动化的工作流程，例如自动库存管理、防伪追踪和物流优化。该规范的实施有助于推动物联网技术在供应链管理领域的广泛应用，并促进相关行业标准的统一。

1 Introduction 438

This document specifies an interface through which clients may interact with filtered,

consolidated EPC data and related data from a variety of sources. The design of this

interface recognizes that in most EPC processing systems, there is a level of processing

that reduces the volume of data that comes directly from EPC data sources such as RFID

readers into coarser “events” of interest to applications. It also recognizes that

decoupling these applications from the physical layers of infrastructure offers cost and

flexibility advantages to technology providers and end-users alike.

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

479

480

Broadly speaking, client interactions with EPC data can be divided into reading activity

and writing activity. For reading activity, the processing done between the physical data

sources and client applications typically involves: (1) receiving EPCs and related data

from one or more data sources such as RFID readers; (2) accumulating data over

intervals of time, filtering to eliminate duplicate data and data that are not of interest, and

counting and grouping data to reduce the volume of data; and (3) reporting in various

forms. For writing activity, the processing typically involves: (1) isolating

(“singulating”) individual data carriers such as RFID Tags through one or more channels

such as RFID readers; (2) operating upon the data carriers by writing data, reading data,

or performing other operations; and (3) reporting in various forms. The interface

described herein, and the functionality it implies, is called “Application Level Events,” or

ALE.

The ALE 1.0 specification [ALE1.0], ratified by EPCglobal in September 2005, was the

first specification at this level of the architecture. The ALE 1.0 specification provided

only an interface for reading data (not writing), and only provided access to EPC data.

The present ALE 1.1 specification expands upon ALE 1.0 to address writing as well as

reading, and both the reading and writing aspects address not only EPC data but also

other data that may be present on EPC data carriers. In particular, the ALE 1.1

specification is designed to provide full access to the functionality of the EPCglobal UHF

Class 1 Gen 2 [Gen2] specification, when interacting with Gen2 RFID Tags. This

includes reading and writing all memory banks, as well as exercising specific operations

such as “lock” and “kill.” In ALE 1.1, additional tag types may easily be accomodated in

the future. In addition to providing reading and writing functionality, the ALE 1.1

specification also provides new interfaces for defining tag memory fields, for managing

the naming of data source names (“logical readers”), and for securing the use of the APIs.

A complete list of changes from the ALE 1.0 specification may be found in Section 16.

The role of the ALE interface within the EPCglobal Network Architecture is to provide

independence between the infrastructure components that acquire the raw EPC data, the

architectural component(s) that filter & count that data, and the applications that use the

data. This allows changes in one without requiring changes in the other, offering

significant benefits to both the technology provider and the end-user. The ALE interface

described in the present specification achieves this independence through five means:

• It provides a means for clients to specify, in a high-level, declarative way, what data 478

they are interested in or what operations they want performed, without dictating an

implementation. The interface is designed to give implementations the widest

possible latitude in selecting strategies for carrying out client requests; such strategies

may be influenced by performance goals, the native abilities of readers or other

devices which may carry out certain filtering or counting operations at the level of

firmware or RF protocol, and so forth.

481

482

483

484

486

487

489

490

491

492

493

494

495

496

498

499

500

501

502

503

504

506

507

508

509

510

511

512

513

514

515

516

518

519

520

522

• It provides a standardized format for reporting accumulated, filtered data and results 485

from carrying out operations that is largely independent of where the data originated

or how it was processed.

• It abstracts the channels through which data carriers are accessed into a higher-level 488

notion of “logical reader,” often synonymous with “location,” hiding from clients the

details of exactly what physical devices were used to interact with data relevant to a

particular logical location. This allows changes to occur at the physical layer (for

example, replacing a 2-port multi-antenna reader at a loading dock door with three

“smart antenna” readers) without affecting client applications. Similarly, it abstracts

away the fine-grained details of how data is gathered (e.g., how many individual tag

read attempts were carried out). These features of abstraction are a consequence of

the way the data specification and reporting aspects of the interface are designed.

• It abstracts the addressing of information stored on Tags and other data carriers into a 497

higher-level notion of named, typed “fields,” hiding from clients the details of how a

particular data element is encoded into a bit-level representation and stored at a

particular address within a data carrier’s memory. This allows application logic to

remain invariant despite differences between the memory organization of different

data carriers (for example, differences between Gen 1 and Gen 2 RFID Tags), and

also shields application logic from having to understand complex layout or data

parsing rules.

• It provides a security mechanism so that administrators may choose which operations 505

a given application may perform, as a policy that is decoupled from application logic

itself.

The ALE specification does not specify a particular implementation strategy, or internal

interfaces within a specific body of software. Instead, this specification focuses

exclusively on external interfaces, admitting a wide variety of possible implementations

so long as they fulfill the contract of the interfaces. For example, it is possible to

envision an implementation of these interfaces as an independent piece of software that

speaks to RFID readers using their network wire protocols. It is equally possible,

however, to envision another implementation in which the software implementing these

interfaces is part of the reader device itself.

The objectives of ALE as described above are motivated by twin architectural goals:

1. To drive as much filtering, counting, and other low-level processing as low in the 517

architecture as possible (i.e., in first preference to readers or other devices, then to

low-level, application-independent software (“middleware” or embedded software),

and as a last resort to “applications”), while meeting application and cost needs;

2. At the same time, to minimize the amount of “business logic” embedded in the tags, 521

readers, embedded software/middleware, where business logic is either data or

processing logic that is particular to an individual product, product category, industry

or business process.

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

548

549

550

551

553

554

555

556

557

558

559

560

561

562

563

564

565

The Application Level Events (ALE) interface specified herein is intended to facilitate

these objectives by providing a flexible interface to a standard set of accumulation,

filtering, counting, writing, and other operations that produce “reports” in response to

client “requests.” The client will be responsible for interpreting and acting on the

meaning of the report (i.e., the “business logic”). The client of the ALE interface may be

a traditional “enterprise application,” or more commonly it may be new software

designed expressly to carry out an EPC-enabled operational process but which operates at

a higher level than the “middleware” or embedded software that implements the ALE

interface. Hence, the term “Application Level Events” should not be misconstrued to

mean that the client of the ALE interface is necessarily a traditional “enterprise

application.”

The ALE interface revolves around client requests and the corresponding reports that are

produced. Requests can either be: (1) immediate, in which information is reported on a

one-time basis at the time of the request; or (2) recurring, in which information is

reported repeatedly whenever an event is detected or at a specified time interval. The

results reported in response to a request can be directed back to the requesting client or to

a “third party” specified by the requestor.

In many cases, the client of ALE will be software that acts as an EPCIS Capturing

Application (see Section 2) or other business processing software. Since EPCIS is

another component of the EPCglobal Architecture Framework that deals with higher-

level EPC events, it is helpful to understand how ALE differs from EPCIS and other

software at higher levels of the architecture. The principal differences are:

• The ALE interface is exclusively oriented towards real-time processing of EPC data, 547

with no persistent storage of EPC data required by the interface (though

implementations may employ persistent storage to provide resilience to failures).

Business applications, in contrast, typically deal explicitly with historical data and

hence are inherently persistent in nature.

• The events communicated through the ALE interface are pure statements of “what, 552

where, and when,” with no business semantics expressed. Business applications, and

typically EPCIS-level data, does embed business semantics at some level. For

example, at the ALE level, there might be an event that says “at location L, in the

time interval T1–T2, the following 100 case-level EPCs and one pallet-level EPC

were read.” Within a business application, the corresponding statement might be “at

location L, at time T2, it was confirmed that the following 100 cases were aggregated

onto the following pallet.” The business-level event, while containing essentially the

same EPC data as the ALE event, is at a semantically higher level because it

incorporates an understanding of the business process in which the EPC data were

obtained.

The distinction between the ALE and EPCIS/business layers is useful because it separates

concerns. The ALE layer is concerned with dealing with the mechanics of data

gathering, and of filtering down to meaningful events that are a suitable starting point for

interpretation by business logic. Business layers are concerned with business process,

and recording events that can serve as the basis for a wide variety of enterprise-level

information processing tasks. Within this general framework, there is room for many

different approaches to designing systems to meet particular business goals, and it is

expected that there will not necessarily be one “right” way to construct systems. Thus,

the focus in this specification is not on a particular system architecture, but on creating a

very well defined interface that will be useful within a variety of designs.

566

567

568

569

570

571

572

573

574

575

576

577

578

579

580

582

583

584

585

586

587

588

589

590

591

592

For convenience, the ALE specification is divided into two parts. This Part I specifies at

an abstract level all interfaces that are part of the ALE specification, using UML notation.

Part II of the specification [ALE1.1Part2] specifies XML-based wire protocol bindings of

the interfaces, including XSD schemas for all data types, WS-I compliant WSDL

definitions of SOAP bindings of the service interfaces, and several XML-based bindings

of callback interfaces used in certain modes of reading and writing data.

Implementations may provide additional bindings of the API, including bindings to

particular programming languages.

2 Role Within the EPCglobal Network Architecture 581

[Much of the text in this section is adapted from [EPCAF], Section 8.]

The diagram below shows the relationships between several EPCglobal Standards, from a

data flow perspective. The plain green bars in the diagram below denote interfaces

governed by EPCglobal standards, while the blue “shadowed” boxes denote roles played

by hardware and software components of a typical system architecture. In any given

deployment the mapping of roles in this diagram to actual hardware and software

components may not be one-to-one. For example, in one deployment the “Filtering and

Collection” role may be implemented by a software component and the “RFID Reader”

role implemented by a hardware component. In another deployment, a “smart reader”

may combine the “Filtering and Collection” role and the “RFID Reader” role into a single

hardware component.

剩余228页未读，继续阅读

budjussy

粉丝: 0
资源: 1

EPCglobal ALE 1.1.1规范：应用层事件协议详解

分布式多协议中间件的架构与实现.pdf

3g-ale.pdf源文件下载

idoc ale 配置

SAP高級應用開發 (高清晰掃瞄版) 第3章 ALE技術

铁路通信协议

基于低级别读写器协议的无线射频识别中间件系统

CAN总线简介及应用

RFID应用集成中间件技术开发

USB总线接口芯片应用管理论文.doc

物联网安全技术的研究与应用.pdf

最新资源