RM Conformance Requirements - GS1 · An RM Conformance Certification Program will focus on testing a given company’s ... 110 providers enrolled in the certification program. ...
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
This document outlines the approach to conformance testing for the EPCglobal Reader Management (RM) 1.0.1 specification. The objective of the RM conformance certification program is to test and certify solution providers’ implementations of the EPCglobal RM functionalities. Certification of RM conformance provides confidence for buyers in the operational capability of a specific product’s implementation of the RM functionalities, while providing solution providers a benchmark to assure product functionality.
In the certification testing all the mandatory tests (arising out of SHALL clauses in the RM spec) will be tested and a vendor must pass all those mandatory tests. For optional features, if the vendor claims to support a specific optional feature, the corresponding optional feature test must be passed. Note that if the vendor does not pass the claimed optional features but passes all the mandatory feature tests, a compliance certificate will still be issued. The vendor will also be given a list specifying which optional tests the vendor has passed.
Status of this document This section describes the status of this document at the time of its publication. As of this writing, this conformance requirements document reflects the RM Specification as shown in the reference section later. Other documents may supersede this document. The latest status of this document series is maintained at the EPCglobal. This document has been reviewed by the working group and is in its final form of delivery to EPCglobal.
Acknowledgements EPC Global’s ALE 1.0 Conformance Requirements document has been used as the baseline for creation of this document. Most of the technical materials have been provided by Gerhard Gangl of 7id. The RM work group members have been instrumental in providing the ideas and details for this document.
Added SNMP Testing Notes clarifying how to test SNMP conformance for several tests
Added Pre-Test conditions for TCR1-3
Removed TCR9 (keeping original numbering scheme)
Altered TCR16 test to only require retrieving the EraseCount value
1.0.1
2006/05/22 Initial revision 1.0
2 Introduction 81 2
96
98
99 100 101
103 104 105 106
8
Technical implementations of the Reader Management (RM) specification may vary due 83 to distinct interpretations of the specification and/or use of proprietary technologies when 84 developing systems that implement the EPCglobal Architecture Framework. 85 Conformance testing provides a mechanism to ensure that solutions adhere to, and are 86 compatible with, the specified standard. The RM Conformance Certification Program 87 will provide solution providers a benchmark to assure product functionality according to 88 the RM specification, while imparting confidence on potential buyers in the operational 89 capability of a specific product’s implementation of the RM functionalities. 90
RM certification represents an endorsement that helps solution providers differentiate 91 their products and services within the marketplace. Certification of RM conformance 92 instills both product recognition and a level of public confidence sought by corporate 93 supply chains looking to partner with a solution provider of EPCglobal standard 94 compliant products. Implementation of an RM certification program will: 95
• Help move the industry toward RFID Interoperability
• Accelerate RM and EPC Implementations 97
• Publicly identify product vendors who support the EPCglobal standards.
The EPC Global Reader Management working group is responsible for defining the RM Certification test scenarios that the authorized testing agency will use in developing a test harness and associated test scripts.
3 Scope 102 An RM Conformance Certification Program will focus on testing a given company’s implementation of the RM protocol and its conformance to the RM 1.0.1 Specification. Note that the RM Conformance Certification Program is NOT intended to test the performance, reliability, or scalability of the tested product.
4 Program Overview The RM Certification Program will be offered by a certified testing laboratory to solution 109 providers enrolled in the certification program. Program Implementation and Certificate 110 definition are to be defined by EPCglobal US and a chosen Testing Laboratory. 111
An EPCglobal RM Conformance Certification Program will focus on testing the 112 following aspects of Reader Management Specification: 113
Solution providers who wish to submit their product(s) for testing must submit the 114 following to the testing laboratory: 115
• An Implementation Under Test (IUT) – a Reader supporting the RM 1.0.1 features 116
• A list of optional features the vendor claims to be supporting.
• Written documentation about the message format and bindings supported by the IUT
• A physical or simulated environment where the tags can be placed, read and removed from the readers area of operation.
The RM supports two distinct message formats (and corresponding bindings) through which it can communicate to the reader. These are XML and SNMP. A specific IUT may or may not support both formats but must support at least one.
In this document we call them SNMP Management Host and XML Management Host. Both of them use the same Reader Management Command Set to communicate with the reader.
In the context of RM conformance, the Conformance Tester implementing the tests will send RM commands and receive the responses and validate if the response is the expected response or not.
14
14
Reader Management Command Set
XML
TCP
SNMP
UDP
Content of Reader/Host Exchanges (abstract syntax)
6 Terminology 147 This document adopts terminology developed by the World Wide Web Consortium 148 [W3C-Conformance]: 149
• Certificate Issuer The organization that issues certificates of conformance, namely, 150 EPCglobal.
• Testing Laboratory An organization that carries out certification testing on behalf of 152 the Certificate Issuer
• Specification An EPCglobal specification for which conformance is tested. 154
• Implementation Under Test (IUT) A submission of hardware and/or software for 155 which certification is sought by an EPCglobal subscriber.
• System Under Test (SUT) The IUT together with any other apparatus required to 157 carry out the test.
• Test Method A description of the test that is applied to the SUT. There may be 159 more than one Test Method available for a given RM 1.0.1 specification requirement, each providing a different level of conformance testing.
• Test Report Quoting from [W3C-Conformance]: “A Test Report contains the 162 results of the testing effort. The test report should provide enough information that, if necessary, the testing effort could be duplicated. The testing report should contain:
• a complete description of the IUT,
• the name of the Testing Laboratory,
• the signature of a Testing Laboratory official,
• the date that the testing was completed,
• the name and version number of the Test Method
• the results of the Test Method
• an unambiguous statement indicating pass or fail.”
• RM Conformance Certification Program An EPCglobal US sponsored Software/Hardware solution certification program measuring RM 1.0.1 conformance.
• Certificate of Conformance Quoting again from [W3C-Conformance]: “The certificate of conformance is typically a summation of the Test Report. Since it is often used in the procurement process, it includes information most pertinent between the buyer and the seller.”
This section lists the commands a Management Software can issue to a reader. The commands have been grouped by reader objects to which the commands are applicable. The table also differentiates between the mandatory commands and the optional commands. For mandatory commands, the test case requirements are stated but for optional commands it is left upto the test lab to assign test case names and numbers.
These commands are required for conformance. Hard SHALL!
These commands are soft SHALL’s. If implemented X you SHALL implement this command.
These are optional commands which MAY be implemented
ReadPointOperStatusAlarm ReadPointOperStatusAlarm.getReadPointName MAY
SourceOperStatusAlarm SourceOperStatusAlarm.getSourceName MAY
NotificationChannelOperStatusAlarm NotificationChannelOperStatusAlarm.getNotificationChannelName MAY
189
190
191
192
193
Reader Management Command Summary:
25 Hard required SHALL commands 61 Soft required optional SHALL commands. If implemented X then implement this command. 39 Optional commands. 125 commands over all.
This section lists all the mandatory (SHALL) reader functionalities in terms of protocol sub clauses (section by section), requirements and if the clause is a Must (hard) or Optional (conditional) support for a reader.
Req.
No.
Protocol
SubClause
Requirements
(Requirements, Command, …) hard or conditional
Condition / Testcase / Remarks
1
4.1.2 Command Channel
A compliant Reader SHALL however have at least one command channel with a default address where it is listening to incoming commands. This default address SHALL be listed in the documentation of a compliant reader.
hard Covered by all testcases implicitly.
2
4.1.6 IOPort Object
If a reader device exposes its IOPorts, it SHALL implement the methods identified as such.
conditional This is optional. See command list.
4.1.7 Alarm Channel Object
A compliant system SHALL provide the means to create/ define AlarmChannels either using the commands specified in this specification, or through a Reader specific means, such as through the use of an out-of-band protocol, or via a configuration file.
conditional This is optional. See command list.
4.2 AlarmControl Objects
AlarmControls SHALL be implemented if AlarmChannels are implemented.
conditional This is optional. See command list.
4.3 Alarm Objects
Alarm objects SHALL be implemented if AlarmChannels are implemented.
conditional This is optional. See command list.
5 Reader Layer-Commands
All commands are atomic, meaning that they SHALL be executed either completely or not at all. For example, when adding arrays of things (e.g., FieldNames to a DataSelector), and one value is not supported or not known, then no values SHALL be added and error SHALL be raised.
hard Verified by design. Can only be tested on optional commands.
5 Reader Layer-Commands
If the command cannot be executed correctly, the return value SHALL be undefined and an error condition SHALL be raised.
hard TCR17
5 Reader Layer-Commands
All strings SHALL be capable of being represented with UTF-8 encoding
hard By design
5.1.1
ReaderDevice.getDescription Compliant systems SHALL implement this command.
5.1.3 ReaderDevice.getLocationDecription Compliant systems SHALL implement this command.
hard TCR2
5.1.4 ReaderDevice.setLocationDescription
Compliant systems SHALL implement this command if, and only if, the system implements setContact.
hard TCR2
5.1.5 ReaderDevice.getContact
Compliant systems SHALL implement this command.
hard TCR3
5.1.5.1 ReaderDevice.setContact
Compliant systems SHALL implement this command.
hard TCR3
5.1.6 ReaderDevice.getSerialNumber
Compliant systems SHALL implement this command.
hard TCR4
5.1.7 ReaderDevice.getOperStatus
Compliant systems SHALL implement this command.
hard TCR5 / TCR12
5.1.8 ReaderDevice.getOperStatusAlarmControl Compliant systems SHALL implement this command if, and only if, AlarmChannels are implemented.
conditional This is optional. See command list.
5.1.13 ReaderDevice.getIOPort Compliant systems SHALL implement this command. if, and only if, IOPort.create() is implemented.( Remove from Spec )
hard TCR6
5.1.14 ReaderDevice.getAllIOPorts Compliant systems SHALL implement this command.
hard TCR7
5.1.15 ReaderDevice.resetStatistics Upon receiving this command, the reader SHALL set all supported counters to zero.
hard TCR8
5.1.16 ReaderDevice.removeAlarmChannels If one or more of the AlarmChannels given are not known, or if some of the AlarmChannels to be removed are currently not associated with this Reader, these are ignored and all other AlarmChannels SHALL be removed and the command SHALL complete successfully. Compliant systems SHALL implement this command, if and only if, AlarmChannel.create() is implemented.
conditional This is optional. See command list.
5.1.17 ReaderDevice.removeAllAlarmChannels Compliant systems
SHALL implement this command if, and only if, AlarmChannel is implemented.
conditional This is optional. See command list.
5.1.18 ReaderDevice.getAlarmChannel Compliant systems SHALL
implement this command if, and only if, AlarmChannel.create() is implemented.
5.1.19 ReaderDevice.getAllAlarmChannels If no AlarmChannel are currently associated with this object, the command SHALL complete successfully and an empty list SHALL be returned. Compliant systems SHALL implement this command if, and only if, AlarmChannel.create() is implemented.
conditional This is optional. See command list.
5.2.3 NotificationChannel.getOperStatus Compliant systems SHALL
implement this command if, and only if, the system implements Notification Channels.
conditional This is optional. See command list.
5.2.4 NotificationChannel.setAdminStatus Compliant systems
SHALL implement this command if the system implements Notification Channels.
conditional This is optional. See command list.
5.2.5 NotificationChannel.getAdminStatus Compliant systems SHALL
implement this command if, and only if, the system implements Notification Channels.
systems SHALL implement this command if, and only if, the system implements Notification Channels and AlarmChannels.
conditional This is optional. See command list.
5.3.1 AlarmChannel.create The AlarmChannel SHALL implicitly be added to the list of all AlarmChannels kept by the ReaderDevice object. Compliant systems CAN implement this command. If it is not implemented, and Alarm Notifications are implemented, the system SHALL provide an alternate method of defining AlarmChannels.
conditional This is optional. See command list.
5.3.2 AlarmChannel.getName Compliant systems SHALL implement this command if AlarmChannels are implemented.
conditional This is optional. See command list.
5.3.3 AlarmChannel.getAddress Compliant systems SHALL implement this command if AlarmChannels are implemented.
conditional This is optional. See command list.
5.3.4 AlarmChannel.setAddress Compliant systems SHALL
implement this command if AlarmChannel.create is implemented.
conditional This is optional. See command list.
5.4.1 ReadPoint.getName Compliant systems SHALL implement this command.
hard TCR9 Covered by RP also
5.4.2 ReadPoint.getClassName Compliant systems SHALL implement this command.
hard TCR10
5.4.3 ReadPoint.getDescription Compliant systems SHALL implement this command
hard TCR11
5.4.4 ReadPoint.setDescription Compliant systems SHALL implement this command.
hard TCR11
5.4.5 ReadPoint.getAdminStatus Compliant systems SHALL implement this command.
hard TCR12
5.4.6 ReadPoint.setAdminStatus Compliant systems SHALL implement this command
hard TCR12
5.4.7 ReadPoint.getOperStatus Compliant systems SHALL implement this command.
hard TCR12
5.4.8 ReadPoint.getOperStatusAlarmControl Compliant systems conditional This is optional.
Each alarm message SHALL carry a Name field (of type String) identifying the type of Alarm message, e.g., “FreeMemoryAlarm”, “TagListFullAlarm”, “ReadPointOperStatusAlarm”. It SHALL matched on of the Alarm types specified in this section in this specification.
conditional This is optional. See command list.
Finally, each alarm message SHALL carry a Level field (of type AlarmLevel), indicating the severity level assigned to the alarm (SEVERE, WARNING, INFORMATION, CONFIGURATION).
conditional This is optional. See command list.
6.1.2 FreeMemoryAlarm The FreeMemory field SHALL carry the
value of ReaderDevice.FreeMemory when the alarm was triggered.
conditional This is optional. See command list.
6.1.3 FailedWriteAlarm
The ReadPointName field identifies the read point (an AntennaReadPoint) over which the write failure occurred. This SHALL be the value of that read point’s ReadPoint.Name element.
The FailedWriteCount field SHALL carry the value of AntennaReadPoint.FailedWriteCount element after the write failure occurred.
conditional This is optional. See command list.
6.1.4
FailedEraseAlarm The ReadPointName field identifies the read point (an AntennaReadPoint) over which the erase failure occurred. This SHALL be the value of that read point’s ReadPoint.Name element.
The FailedEraseCount field SHALL carry the value of AntennaReadPoint.FailedEraseCount element after the erase failure occurred.
conditional This is optional. See command list.
6.1.5 FailedKillAlarm The ReadPointName field identifies the read point (an AntennaReadPoint) over which the kill failure occurred. This SHALL be the value of that read point’s ReadPoint.Name element.
The FailedKillCount field SHALL carry the value of AntennaReadPoint.FailedKillCount element after the kill failure occurred.
conditional This is optional. See command list.
6.1.6 FailedLockAlarm The ReadPointName field identifies the read point (an AntennaReadPoint) over which the lock failure occurred. This SHALL be the value of that read point’s ReadPoint.Name element.
The FailedMemReadCount field SHALL carry the value of AntennaReadPoint.FailedMemReadCount element after the read failure occurred.
conditional This is optional. See command list.
6.1.7
FailedMemReadAlarm The ReadPointName field identifies the read point (an AntennaReadPoint) over which the memory read failure occurred. This SHALL be the value of that read point’s ReadPoint.Name element. The FailedMemReadCount field SHALL carry the value of
AntennaReadPoint.FailedMemReadCount element after the read failure occurred.
6.1.8 TTOperStatusAlarm The FromState field SHALL identify the originating OperationalStatus before the Alarm is generated.
The ToState field SHALL identify the OperationalStatus at the time the Alarm is generated.
conditional This is optional. See command list.
6.1.8.1 ReaderDeviceOperStatusAlarm Compliant systems SHALL implement this alarm if AlarmChannel is implemented.
conditional This is optional. See command list.
6.1.8.2
IOPortOperStatusAlarm The IOPortName message field SHALL identify the name of the IO Port that experienced the alarm-triggering state transition, i.e., the value of the respective IOPort.Name model element. Compliant systems SHALL implement this alarm if AlarmChannel and IOPort are implemented.
conditional This is optional. See command list.
6.1.8.3
ReadPointOperStatusAlarm The ReadPointName message field SHALL identify the name of the Read Point that experienced the alarm-triggering state transition, i.e., the value of the respective ReadPoint.Name model element.
Compliant systems SHALL implement this alarm if AlarmChannel is implemented.
conditional This is optional. See command list.
6.1.8.4 SourceOperStatusAlarm The SourceName message field SHALL identify the name of the logical source that experienced the alarm-triggering state transition, i.e., the value of the respective Source.Name model element.
Compliant systems SHALL implement this alarm if AlarmChannel is implemented.
conditional This is optional. See command list.
6.1.8.5
NotificationChannelOperStatusAlarm The NotificationChannelName message field SHALL identify
the name of the notification channel that experienced the alarm-triggering state transition, i.e., the value of the respective NotificationChannel.Name model element.
Compliant systems SHALL implement this alarm if AlarmChannel and NotificationChannel are implemented.
conditional This is optional. See command list.
8.3 Command Errors
SHALL: The error code and/or error name. At least one of these fields SHALL be included in the Error structure. The exact contents depend on the binding, and SHALL be constant at the binding level, e.g. MTB X can be defined as always including the error code (but not the error name)
SHALL (where applicable): Information about the error cause. For example, for input parameter errors, information on which parameter failed needs to be included. Depending on the binding, this can be either the name or the index of the parameter. Vendor extensions are allowed here.
SHALL (where applicable): A vendor name or identifier for the responses to vendor-specific commands SHALL be given.
9 Vendor Extensions Vendors SHALL use the error conditions defined above for the commands of the standard command set. Vendors CAN add additional information on the exact cause of the error.
These vendor-defined error conditions SHALL use names starting with <VENDOR>_ERROR…
hard By design
10 Message/Transport Bindings (MTBs) A compliant application SHALL implement at least one of the Message Formats and MAY implement more than one of the message formats. If a particular Message Format is implemented, the compliant application SHALL implement all of the operations labeled SHALL. If an operation is not supported, the Reader and/ or Host SHALL reply with ERROR_NOT_SUPPORTED.
hard By definition
10.4 SNMP MIB
In addition to compliance with the EPC Global Reader Management MIB, a compliant system that supports the SNMP binding SHALL implement support for the following IETF-standardized MIB groups:
the MIB-II System Group defined in the SNMPv2-MIB module, defined in RFC 3418,
the MIB-II IP Group, defined in the IP-MIB module, RFC 2011,
the MIB-II Interfaces Group, defined in IF-MIB module, RFC 2863
Protocol support for the management of Alarm Channels is optional; however, if a reader vendor chooses to support SNMP-based management of Alarm Channels, the vendor SHALL do so by implementing the SNMP-TARGET-MIB module, defined in RFC 3413.
The test cases mentioned in this section are the mandatory requirements only. For optional requirements, the test case naming and description are left upto the test lab.
9.1 Requirement command get/setDescription (TCR1)
TPId: TCR-1
Test Purpose: This test case verifies the implementation of the get/setDescription command.
Requirements Tested:
Pre-test conditions:
• The ReaderDevice Description attribute is set to NULL.
Step Step description Expected results
1 Power on the reader. Wait till reader boot up finished.
The reader should return its current operational status. If the reader is fully up the value should be “UP”. If any component of the reader is down, the aggregating status of the reader device should be “OTHER”. If the reader device is down the value should be “DOWN”.
219
220 221
9.6 Requirement command getIOPort (TCR6)
TPId: TCR-6
Test Purpose: This test case verifies the implementation of the getIOPort command.
Requirements Tested:
SNMP Testing Note: SNMP does not provide a mechanism to directly query for an object to be queried by name. For the SNMP test, the entire IOPort table should be queried using SNMP get and getnext operations, and the association of the name to the port done by the test suite with the results of the table query.
Pre-test conditions:
• The reader has an IOPort with the name e.g. “Input1”.
Test Purpose: This test case verifies the implementation of the getAllIOPorts command.
Requirements Tested:
SNMP Testing Note: SNMP does not provide a mechanism to directly query for a list by name. For the SNMP test, the entire IOPort table should be queried using SNMP get and getnext operations, and the list of names generated by the test suite with the results of the table query.
Pre-test conditions:
• None
Step Step description Expected results
1 Power on the reader. Wait till reader boot up finished.
Test Purpose: This test case verifies the implementation of the getClassName command.
Requirements Tested:
SNMP Testing Notes: SNMP requires that the data structures for different types of ReadPoints be predefined. As such, an SNMP management system would have to know a priori what ReadPoint class it is querying for. Because of this, an explicit ClassName attribute is redundant for SNMP. The conformance test should ensure that the antenna with the name “Antenna1” has an entry in the epcgAntennaReadPoint table.
Pre-test conditions:
• The reader has an antenna with the name Antenna1.
Step Step description Expected results
1 Power on the reader. Wait till reader boot up finished.
Attach the antenna1 to source1. Attach the read point antenna1 to the source1. The commands for this operations are out of scope for this document and can be done e.g. by reader protocol commands.
The reader should return the operational status for the antenna1 with value down, for source1 and the reader device with the value other. The value other on the source and reader device states the aggregation status of the operational status over objects.
The reader should return the operational status for the antenna1 and source1 with value down, for the reader device with the value other. The value other on the reader device states the aggregation status of the operational status over objects.
9.17 Requirement for a failed command behavior (TCR17)
TPId: TCR-17
Test Purpose: This test case verifies the behavior of a failed command call.
Requirements Tested:
SNMP Testing Notes: SNMP does not provide a mechanism to query an object directly by name. In this case, a get query should be issued for the epcgIOPort table for an index which is known to not be defined in the table.
Pre-test conditions: • None.
Step Step description Expected results
1 Power on the reader. Wait till reader boot up finished.
The reader should return an error “ERROR_IOPORT_NOT_FOUND”. The return value “report” is undefined in this case and depends on the binding which is used. For example: An XML binding would not return a return value for the command, it will return in the binding the error only.
255
256
257
258 259
260
10 References
[W3C-Conformance] D. Dardailler, “Conformance Testing and Certification Model for W3C Specifications,” W3C Note, http://www.w3.org/QA/2002/01/Note-qa-certif-261 20020102.html, January 2002. 262
263 264
[RM Spec] EPCglobal, The Reader Management (RM) Specification 1.0.1, May 31, 2007