1、American National StandardDeveloped byANSI INCITS 371.3-2003for Information Technology Real Time Locating Systems (RTLS) Part 3: Application Programming InterfaceANSIINCITS371.3-2003ANSIINCITS 371.3-2003American National Standardfor Information Technology Real Time Locating Systems (RTLS) Part 3: Ap
2、plication Programming InterfaceSecretariatInformation Technology Industry Council (ITI)Approved July 25, 2003American National Standards Institute, Inc.AbstractThis standard defines an Application Programming Interface for Real Time Locating Systems (RTLS) foruse in asset management. This standard i
3、s intended to allow for compatibility and to encourage interop-erability of products for the growing RTLS market.Approval of an American National Standard requires review by ANSI that therequirements for due process, consensus, and other criteria for approval havebeen met by the standards developer.
4、Consensus is established when, in the judgement of the ANSI Board ofStandards Review, substantial agreement has been reached by directly andmaterially affected interests. Substantial agreement means much more thana simple majority, but not necessarily unanimity. Consensus requires that allviews and
5、objections be considered, and that a concerted effort be madetowards their resolution.The use of American National Standards is completely voluntary; theirexistence does not in any respect preclude anyone, whether he has approvedthe standards or not, from manufacturing, marketing, purchasing, or usi
6、ngproducts, processes, or procedures not conforming to the standards.The American National Standards Institute does not develop standards andwill in no circumstances give an interpretation of any American NationalStandard. Moreover, no person shall have the right or authority to issue aninterpretati
7、on of an American National Standard in the name of the AmericanNational Standards Institute. Requests for interpretations should beaddressed to the secretariat or sponsor whose name appears on the titlepage of this standard.CAUTION NOTICE: This American National Standard may be revised orwithdrawn a
8、t any time. The procedures of the American National StandardsInstitute require that action be taken periodically to reaffirm, revise, orwithdraw this standard. Purchasers of American National Standards mayreceive current information on all standards by calling or writing the AmericanNational Standar
9、ds Institute.American National StandardPublished byAmerican National Standards Institute, Inc.25 West 43rd Street, New York, NY 10036Copyright 2003 by Information Technology Industry Council (ITI)All rights reserved.No part of this publication may be reproduced in anyform, in an electronic retrieval
10、 system or otherwise,without prior written permission of ITI, 1250 Eye Street NW, Washington, DC 20005. Printed in the United States of AmericaCAUTION: The developers of this standard have requested that holders of patents that may be re-quired for the implementation of the standard disclose such pa
11、tents to the publisher. However, nei-ther the developers nor the publisher have undertaken a patent search in order to identify which, ifany, patents may apply to this standard. As of the date of publication of this standard, followingcalls for the identification of patents that may be required for
12、the implementation of the standard,notice of one or more such claims has been received. By publication of this standard, no positionis taken with respect to the validity of this claim or of any rights in connection therewith. The knownpatent holder(s) has (have), however, filed a statement of willin
13、gness to grant a license underthese rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to ob-tain such a license. Details may be obtained from the publisher. No further patent search is con-ducted by the developer or publisher in respect to any standard it process
14、es. No representation ismade or implied that this is the only license that may be required to avoid infringement in the use ofthis standard.iContentsPageForeword iiIntroduction v1 Scope . 12 Normative References 13 Terms and Definitions. 14 Symbols (and Abbreviated Terms). 15 The Service 26 Applicat
15、ion Programming Interface (API) . 37 Subroutine Calls . 48 Data Structures and Data Types 13Figures1 Architecture of SOAP-RPC Calls 3AnnexA XML Schemas for Remote Procedure Calls. 17iiForeword (This foreword is not part of American National Standard ANSI INCITS 371.3-2003.)ANSI INCITS 371.3-2003 is
16、one of a series of standards for Real Time Locating Sys-tems (RTLS) that provides, in real-time, the physical location and the tracking of as-sets, human resources, or any other category of mobile items. This series ofstandards is intended to foster compatibility and interoperability of RTLS. There
17、arethree standards in the series. Two airwave interface protocols are specified: one isdefined to provide a high-precision system operating at 2.4 GHz and a second to pro-vide a lower-precision system operating at 433 MHz. A single Application Program-ming Interface (API) is defined that provides a
18、unifying interface for either of the twoairwave interface protocols.Requests for interpretation, suggestions for improvement or addenda, or defect re-ports are welcome. They should be sent to InterNational Committee for InformationTechnology Standards (INCITS), ITI, 1250 Eye Street, NW, Suite 200, W
19、ashington,DC 20005.This standard was processed and approved for submittal to ANSI by INCITS. Com-mittee approval of this standard does not necessarily imply that all committee mem-bers voted for its approval. At the time it approved this standard, INCITS had thefollowing members:Karen Higginbottom,
20、ChairJennifer Garner, SecretaryOrganization Represented Name of RepresentativeApple Computer, Inc. David Michael Wanda Cox (Alt.)Farance, Inc. Frank Farance Richard Lutz (Alt.)Hewlett-Packard Company. Karen Higginbottom Scott Jameson (Alt.)Steve Mills (Alt.)EIA Edward Mikoski, Jr. Judith Anderson (A
21、lt.)Suan Hoyler (Alt.)IBM Corporation . Ronald F. Silletti Institute for Certification of Computer Professionals Kenneth M. Zemrowski Thomas Kurihara (Alt.)IEEE . Judith Gorman Richard Holleman (Alt.)Robert Pritchard (Alt.)Intel Corporation. Gregory Kisor Dave Thewlis (Alt.)Microsoft Corporation . M
22、ike Ksar Joseph Zajaczkowski (Alt.)National Institute of Standards & Technology Michael Hogan William LaPlant, Jr. (Alt.)Network Appliance . James Davis Oracle Corporation . Donald R. DeutschJim Melton (Alt.)Connie Myers (Alt.)Open Strategies . John Neumann Panasonic Technologies, Inc. Terence Nelso
23、n Rudolf Vitti (Alt.)Purdue University . Stephen Elliott Sony Electronics, Inc Ed Barrett Jean Baronas (Alt.)Sun Microsystems, Inc. Carman Mondello John Hill (Alt.) Douglas Johnson (Alt.)Carl Cargill (Alt.)iiiOrganization Represented Name of RepresentativeUCC Stephen Brown Frank Sharkey (Alt.)INCITS
24、 T20 Technical Committee on Real Time Locating Systems, which contributedto the development of this standard, had the following members:Larry Graham, ChairmanAnthony Cataldo, Vice-ChairmanMarsha A. Harmon, SecretaryOrganization Represented Name of RepresentativeAssociated FoodsTim VandemerweKent See
25、gmiller (Alt.)Automotive Industry Action Group (AIAG) Morris BrownBaxter Healthcare CorporationTuan BuiJames P. Martucci (Alt.)Bruno Associates, Inc. Thomas BrunoDefense Logistics Agency Dan KimballCarl Gardner (Alt.)Electronic Data Systems Corp (EDS) .Ben CameronTom Whall (Alt.)Elpas Israel Radomsk
26、yMathiew Bais (Alt.)FMC Technologies Mike CamutTom Nolasco (Alt.)Ford Motor Company Anthony CataldoHenry Ubik (Alt.)General Electric.Tom TomlinsonTed Robinson (Alt.)General Motors .Larry GrahamIITRI Andrew ONeillTom Lucas (Alt.)InfoGlyph.Pat McGowanInfoRay Technologies .Aaron SamuelLuz Erez (Alt.)No
27、rthrop Grumman .Roger SeeseJim Laurance (Alt.)Oak Ridge National Laboratory.Mark BucknerQED SystemsMarsha A. HarmonCraig K. Harmon (Alt.)RF CodeRoc Lastinger Armando Viteri (Alt.)RF Technologies .Larry CinpinskiEric Heinze (Alt.)Savi TechnologyPhil BoyleFraser Jennings (Alt.)Sovereign Tracking Syste
28、ms William RobinsonBryan Schmidt (Alt.)Spectrum Management.Dave WoodSteve Miller & AssociatesSteve MillerSymbol TechnologiesChris ZegelinMichael Hadley (Alt.)VerdaSee Solutions Fran SmithReuben Vasquez (Alt.)WCCN Publishing, Inc.Thomas PolizziWhereNet Tim HarringtonSandeep Jain (Alt.)ivThe following
29、 members served in the capacity of document coordinators:Tim HarringtonSandeep JainChris ZegelinThe following members served in the capacity of ad hoc committee chairs:Mark BucknerDan KimballTom PolizzivIntroductionThe INCITS 371 series of standards defines two Air Interface Protocols and a singleAp
30、plication Programming Interface (API) for Real Time Locating Systems (RTLS) foruse in asset management. This series of standards is intended to allow for compati-bility and to encourage interoperability of products for the growing RTLS market. Theseries consists of the following standards, under the
31、 general title “Information Tech-nology - Real Time Locating Systems.”ANSI INCITS 371.1 - 2.4-GHz Air Interface ProtocolANSI INCITS 371.2 - 433-MHz Air Interface ProtocolANSI INCITS 371.3 - The common API between either 2.4-GHz or 433-MHz BandRTLS and application programsThis document defines the Ap
32、plication Programming Interface. To be fully compliantwith this standard, Real Time Locating Systems (RTLS) must also comply either withANSI INCITS 371.1 or ANSI INCITS 371.2.An API is a boundary across which application software uses facilities of program-ming languages to invoke services. These fa
33、cilities may include procedures or opera-tions, shared data objects and resolution of identifiers. A wide range of services maybe required at an API to support applications. Different methods may be appropriatefor documenting API specifications for different types of services.The information flow ac
34、ross the API boundary is defined by the syntax and semanticsof a particular programming language, such that the user of that language may ac-cess the services provided by the application platform on the other side of the bound-ary. This implies the specification of a mapping of the functions being m
35、ade availableby the application platform into the syntax and semantics of the programming lan-guage.An API specification documents a service and/or service access method that is avail-able at an interface between the application and an application platform. The T20 RTLS API describes the RTLS servic
36、e and its access methods, to enableclient applications to interface with the RTLS system. This RTLS service is the mini-mum service that must be provided by a RTLS system to be T20 RTLS API compati-ble. Other services may be provided in addition to this.The version of the API standard is signified b
37、y x.y, such as 1.0. A major release ofthe RTLS API standard would increment the x, such as 2.0. A minor release wouldincrement the y, such as 1.1.Client applications using the RTLS API should ignore XML tags that may appear infuture enhancements to the RTLS API standard within a single major release
38、. Thisrequirement is intended to ensure backward compatibility.AMERICAN NATIONAL STANDARD ANSI INCITS 371.3-20031 American National Standard for Information Technology Real Time Locating Systems (RTLS) Part 3: Application Programming Interface 1 Scope This American National Standard defines an API s
39、pecification that serves as a boundary across which application software uses facilities of programming languages to invoke the services of the RTLS Air Interface Protocol standard as defined by INCITS T20. 2 Normative References 2.1 Referenced Documents The following standards contain provisions wh
40、ich, through reference in this text, constitute provi-sions of this American National Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this American National Standard are encouraged to investigate the p
41、ossibility of applying the most recent edi-tions of the standards indicated below. ISO/IEC 9075:1992(E), Information Technology Database Language SQL EXtensible Markup Language 1.0, as defined at the site: http:/www.w3.org/tr/rec-xml Simple Object Access Protocol, Version 1.1, as defined at the site
42、: http:/www.w3.org/tr/soap 2.2 Informative References ANSI INCITS 371.1-2003, Information technology - Real Time Locating Systems (RTLS) - Part 1: 2.4-GHz Air Interface Protocol ANSI INCITS 371.2-2003, Information technology - Real Time Locating Systems (RTLS) - Part 2: 433-MHz Air Interface Protoco
43、l 3 Terms and Definitions In addition to the terms and definitions listed below, the terms and definitions given in ANSI INCITS 371.1 and ANSI INCITS 371.2 also apply to this document. 3.1 RTLS tag: The radio frequency device that the RTLS system tracks and locates. 3.2 tag blink: A single RTLS blin
44、k of a radio frequency device. Within the API, a tag blink is uniquely defined by a Tag ID, and usually consists of numerous other fields. A field of a Tag Blink is equivalent to the property of a Tag Blink. Within the API, it is represented by a XML Tag. 3.3 XML tag: The marker that qualifies conte
45、nt in a XML document. 4 Symbols (and abbreviated terms) In addition to the abbreviations listed below, the symbols and abbreviated terms given in ANSI INCITS 371.1 and ANSI INCITS 371.2 also apply to this document. RTLS Real-time Locating System RPC Remote Procedure Call ANSI INCITS 371.3-20032 SOAP
46、 Simple Object Access Protocol XML eXtensible Markup Language HTTP HyperText Transfer Protocol 5 The Service 5.1 Purpose The real-time locating service is typically a Web Service. It receives RTLS tag blinks from the RTLS infrastructure, and delivers those blinks as the response to client requests,
47、over standard Internet protocols. In addition, it allows filtering and field selection on the contents of those blinks. 5.2 Description An RTLS service shall support message exchange using the SOAP 1.1 encoding. An RTLS service should listen and respond to client requests using the HTTP network prot
48、ocol. It should listen on port 80. An RTLS service may take advantage of the Persistent Connections feature, which is available in HTTP 1.1, but not in HTTP 1.0. This would yield significant performance benefits for repeated calls to the RTLS Service, as described in 7.4. An RTLS service shall maint
49、ain state of the last blink of all tags in the RTLS infrastruc-ture, since it was started. It may maintain state, from before its start time, by using a re-pository. An RTLS service shall support filtering and field selection, as described in 7.2.5 and 7.2.6. An RTLS Service should eliminate extraneous spaces in the content of query pa-rameters, such as filters. An RTLS service shall be able to create a Session, on request from the API, as described in 7.3. The session shall keep the state of the Query parameters. Requests to that session shall re
