The Application Level Events (ALE) Specification, Version 1.0 - GS1

More documents

Recommendations

Info

426 427 428 429 430 431 432 433 434 435 436 437 438 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 • A client or clients may make simultaneous requests for event cycle reports that may have differing event cycle boundaries and different report specifications. In this case, clients must necessarily share a common view of when and how frequently read cycles take place. Specifying the read cycle frequency outside of any event cycle request insures that clients cannot make contradictory demands on read cycles. • In cases where there are many readers in physical proximity (perhaps communicating to different ALE implementations), the read cycle frequency must be carefully tuned and coordinated to avoid reader interference. This coordination generally requires physical-level information that generally would be (and should be) unknown to a client operating at the ALE level. • The ALE API is designed to provide access to data from a wide variety of “Reader” sources, which may have very divergent operating principles. If the ALE API were to provide explicit control over read cycle timing, it would necessarily make assumptions about the source of read cycle data that would limit its applicability. For example, if the ALE API were to provide a parameter to clients to set the frequency of read cycles, it would assume that every Reader provides data on a fixed, regular schedule. In light of these considerations, there is no standard way provided by ALE for clients to control read cycle timing. Implementations of ALE may provide different means for this, e.g., configuration files, administrative interfaces, and so forth. Regardless of how a given ALE implementation provides for the configuration of read cycle timing, the ALE implementation always has the freedom to suspend Reader activity during periods when no event cycles requiring data from a given Reader are active. 7 Logical Reader Names In specifying an event cycle, an ALE client names one or more Readers of interest. This is usually necessary, as an ALE implementation may manage many readers that are used for unrelated purposes. For example, in a large warehouse, there may be ten loading dock doors each having three RFID readers; in such a case, a typical ALE request may be directed at the three readers for a particular door, but it is unlikely that an application tracking the flow of goods into trucks would want the reads from all 30 readers to be combined into a single event cycle. This raises the question of how ALE clients specify which reader devices are to be used for a given event cycle. One possibility is to use identities associated with the reader devices themselves, e.g., a unique name, serial number, EPC, IP address, etc. This is undesirable for several reasons: • The exact identities of reader devices deployed in the field are likely to be unknown at the time an application is authored and configured. • If a reader device is replaced, this unique reader device identity will change, forcing the application configuration to be changed. Copyright © 2005, 2004 EPCglobal Inc, All Rights Reserved. Page 14 of 71
465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 • If the number of reader devices must change – e.g., because it is discovered that four reader devices are required instead of three to obtain adequate coverage of a particular loading dock door – then the application must be changed. To avoid these problems, ALE introduces the notion of a “logical reader.” Logical readers are abstract names that a client uses to refer to one or more Readers that have a single logical purpose; e.g., DockDoor42. Within the implementation of ALE, an association is maintained between logical names such as DockDoor42 and the physical reader devices assigned to fulfill that purpose. Any ALE event cycle specification that refers to DockDoor42 is understood by the ALE implementation to refer to the physical reader (or readers) associated with that name. Logical names may also be used to refer to sources of raw EPC events that are synthesized from various sources. For example, one vendor may have a technology for discriminating the physical location of tags by triangulating the results from several reader devices. This could be exposed in ALE by assigning a synthetic logical reader name for each discernable location. Different ALE implementations may provide different ways of mapping logical names to physical reader devices, synthetic readers, and other sources of EPC events. This is a key extensibility point. At a minimum, however, all ALE implementations SHOULD provide a straightforward way to map a logical name to a list of read event sources, and where physical readers allow for independent control over multiple antennas and multiple tag protocols, each combination of (reader, antenna, protocol) should be treated as a separate read event source for this purpose. To illustrate, an ALE implementation may maintain a table like this: Logical Reader Name DockDoor42 DockDoor43 Physical Reader Devices Reader Name Antenna Protocol Acme42926 0 UHF Acme42926 1 UHF Acme43629 0 UHF Acme44926 0 UHF Acme44926 1 UHF Acme49256 0 UHF (It must be emphasized that the table above is meant to be illustrative of the kind of configuration data an ALE implementation might maintain, not a normative specification of what configuration data an ALE implementation must maintain.) More elaborate implementations of ALE, such as those that provide synthesized logical readers such as the triangulation example above, will require more elaborate configuration data. Tables of this kind may be established through static configuration, Copyright © 2005, 2004 EPCglobal Inc, All Rights Reserved. Page 15 of 71
Page 1 and 2: 1 2 3 The Application Level Events
Page 3 and 4: 52 53 54 55 56 57 58 59 60 61 62 63
Page 5 and 6: 115 116 117 118 119 120 121 122 123
Page 7 and 8: 171 172 173 174 175 176 177 178 179
Page 9 and 10: 256 257 258 259 260 261 262 263 264
Page 11 and 12: EPC1 EPC2 EPC3 EPC1 EPC2 EPC4 EPC3
Page 13: 388 389 390 391 392 393 394 395 396
Page 17 and 18: 535 536 537 538 539 540 541 542 543
Page 19 and 20: 591 592 593 594 595 596 597 Once re
Page 21 and 22: 629 630 Exception Name DuplicateSub
Page 23 and 24: 657 658 659 660 661 662 663 664 665
Page 25 and 26: 731 732 733 734 735 736 737 738 739
Page 27 and 28: 800 801 802 803 804 805 806 807 808
Page 29 and 30: 865 866 867 868 869 870 871 872 873
Page 31 and 32: 903 904 905 906 907 908 909 910 911
Page 33 and 34: 964 965 966 967 968 969 970 971 972
Page 35 and 36: 1007 1008 1009 1010 1011 1012 1013
Page 37 and 38: 1078 1079 1080 1081 1082 1083 1084
Page 39 and 40: 1151 1152 1153 1154 1155 1156 1157
Page 41 and 42: 1232 1233 1234 1235 1236 1237 1238
Page 43 and 44: 1331 1332 1333 1334 1335 1336 1337
Page 45 and 46: 1471 1472 1473 1474 1475 1476 1477
Page 47 and 48: 1611 1612 1613 1614 1615 1616 1617
Page 49 and 50: 1751 1752 1753 1754 1755 1756 1757
Page 51 and 52: 1875 1876 1877 1878 1879 1880 1881
Page 53 and 54: 2015 2016 2017 2018 2019 2020 2021
Page 55 and 56: 2155 2156 2157 2158 2159 2160 2161
Page 57 and 58: 2295 2296 2297 2298 2299 2300 2301
Page 59 and 60: 2435 2436 2437 2438 2439 2440 2441
Page 61 and 62: 2575 2576 2577 2578 2579 2580 2581
Page 63 and 64: 2660 2661 2662 2663 2664 2665 2666
Page 65 and 66:
2691 2692 2693 2694 2695 2696 2697
Page 67 and 68:
2741 2742 2743 2744 2745 2746 2747
Page 69 and 70:
2780 2781 2782 2783 2784 2785 2786
Page 71:
2818 2819 2820 2821 2822 2823 2824
show all

The Application Level Events (ALE) Specification, Version 1.0 - GS1

Create successful ePaper yourself

Delete template?

Save as template?