…what’s a sQRrl code doing on my repair label?

An optically scan-able label does not need to be powered up for triage.

The problem of system repair record-keeping and tracking is exacerbated by the lack of standards. Each manufacturer has a proprietary in-house solution. However, repair and refurbishing services are generally outsourced. Repair and refurbishment service providers often serve multiple product lines and have their own data tracking systems. Those systems are, generally speaking, not interoperable.

Creating a standardized dictionary of fields will expedite interoperability. Recently, the RLA Standards Committee released a standard—dynamic and extensible, that defines fields for the creation of optically scan-able labels—QR codes, that can communicate up to 4X the data of a bar code. With a capacity of over 4000 characters per label, there is sufficient space to provide a complete repair history. Of course, any manufacturer could create such a system, but then they are back to the same old story of conflicting systems. Often the various repair depots do not even use the same language let alone the same software. We can fix that!

The Standards Committee of the Reverse Logistics Association recently held a webinar1 on the use of sQRrl codes for the creation of an optically scan-able label to record the repair history of returned computers. The presentation by Ken Jacobsen, co-chair of the Standards committee and Rick Detches, a technical specialist with Eurosoft (UK) Ltd—a leading provider of computer diagnostic tools, demonstrated a complete solution to this daunting bottleneck in product lifecycle management.

With regards to this application of sQRrl codes to repair records, we discovered that only a few fields are necessary. The first field is a pointer to the URL where the entire repair record is kept. We have heard complaints that often paper repair records get lost or separated from returned systems, causing reprocessing and more manual intervention. At the entry point of triage, a QR code label can be affixed to the device that will, with an optical scan, connect to a Master Repair Record—regardless of the location of that record. Repair data on that label can be updated as the device is processed, updating the Master Repair Record throughout the procedure. The information is stored and retrieved optically and is attached physically to the product. A Master Repair Record (in the cloud or stored on a local system) is required, but manufacturers and repair depots do that as a matter of course. The optically scan-able sQRrl code label merely points to it.

The second field is a Diagnostic Event Record. We have defined this field to record minimal information but it is extensible by manufacturers or depots with proprietary codes. The minimal standardized information to be contained includes a time stamp for the event; the coded listing of subassembly failures; a coded final disposition of the event, and the identity of the site/technician conducting the event. These four pieces of information, at a minimum, are optically scan-able and physically attached to the product.

In order to enable this field, the standard includes an extensible list of components, and sub-assemblies, as well as disposition codes as part of the field definition. For other types of devices, e.g. printers, or TVs, appropriate standardized lists will also be developed. Regarding the list of components, technology is always evolving. This standard is dynamic. As new items are invented and deployed, the list will simply grow. The old items will remain since it is often the older systems that are “returned.” Floppy disk drives are not, in fact, coffee cup holders, and they always remain #7 in the list regardless of what they are called in whatever language. It is arbitrary, but extensible and published as a standard.

The same can be said for disposition codes. There are only so many possible dispositions; but industry may require more granularity in the language as we evolve. The RLA standards committee also posted such a list.

Contents (fields) of a Digital Toe Tag for Computers D52 a URL link to the Master Repair record D51 Diagnostic Event Record (see below for discussion) D57 date and time that the product was received D53 identification of receiving site D59 Disposition code including a time stamp (optional duplicate of D51) Optionally, the optical label may also contain D5F Detailed Repair Notes.

There are just a few more obvious pieces of information that can be included: a time and date stamp, and the name or identity of the receiving site. Optionally a final disposition code can be included along with a link to the full repair notes. Any of these fields may be encrypted by the manufacturer or made available for even the consumer to read.

Once fully deployed, product return intake personnel will be able to visually determine that a returned item has been returned before. Without power or peripheral connections, they will know when where and what happened on the previous return. Paperwork and product identity will be physically attached to the device: it can no longer be lost. Tracking and analytics can be enhanced. Language and disparate software systems can be harmonized. And to accomplish all of this, all that is needed is a simple label.

Use Models for Digital Toe Tags There are two use cases:

1. Unit arrives at receiving dock with RMA paperwork or

2. Unit arrives at receiving dock with minimal documentation

Best practices are that most returns arrive with valid RMA documentation. This information is most frequently obtained through an interview with a call-center. Again, frequently, this is followed by the email (or even snail mail) transmission of paperwork. Often even a shipping label or packaging material is sent to the RMA petitioner. Petitioners are instructed how to package and return the items to be returned.

In this case, it would be the Call Center that would generate the first level of a digital toe tag. Best practice at this time requires that the Call Center create a digital case number. Today this is imprinted on the RMA paperwork and generally on related shipping labels if sent to the petitioner. In the worst case, the petitioner is requested to hand write the RMA number onto the packaging label.

Using sQRrl codes, the call center would add an additional step to their process: They would create a sQRrl code label. The first, and only required field that the Call Center would have to generate is a URL address pointing to the location of the database record containing the actual repair record – we called the Master Repair Record. This can/should be a short ULR code. It is designed to be optically scanned so that read-ability is not an issue. In the sQRrl code schema this is field D52. The letter D designates it as a “diagnostic” field. Some manufacturers may opt to use a totally proprietary system based on a similar schema. They may use a field designator M52 indicating that the contents are proprietary.

The Call Center may also start to populate the next field D51 and create the beginnings of a Diagnostic Event Record. In that event, the Call Center would include the date of the call, list the malfunctioning items described by the petitioner, and indicate the site to which the return is being sent. In the example above, the resulting code would become D51[150815][317][][]D53 Joes E52 mxxp.rla.org for example.

The benefit of the creation of a sQRrl code is that it can be optically scanned without manually reading paperwork or opening packages. This string of 48 characters says that on Aug 15, 2015 a product was sent to Joes Computer Repair with a broken audio and monitor problems. It also includes a link to the full computer repair record. How easy is that?

In a second scenario, too often items are received at the dock with inadequate information. Receiving Triage now takes on the additional task of creating the sQRrl code label. However, after this system has matured, a visual examination would quickly determine whether the device had been previously in the system. The basic information in the main sQRrl code would correctly identify the product and its owner. Triage would be minimalized.

How Toe Tags Work To create the code, the Standards Committee had to develop a list of components that could fail. It was decided that the basic codes would only be recorded if the component/function failed. However, the field is extensible with more detailed codes and data.

In the webinar mentioned above, they offered an example of a device that was returned with two complaints: The audio did not work, and the monitor was flakey. Eurosoft (UK) Ltd reported how they could use sQRrl codes as an integral part of their diagnostic system.

Readers of this document will no doubt have experienced product logistical issues, particularly inconsistent return criteria, clear inbound and outbound directions or processes.

At the computer end of reverse logistics, Eurosoft has gathered input from various customers and industry best-practice testing to contribute a small, but significant measure in support of standardizing reverse logistics disposition labels and sQRrl codes.

To that end, Eurosoft sees an opportunity to significantly shorten and align an average 60 minute refurbishment triage, and average 25 minute disposition operations to improve reverse logistics operations in PC refurbishment.

Eurosoft’s ideas are presented in this document as a focus point for collecting significant and widely used data across computer sectors.

With membership in the RLA Standards Committee, Eurosoft continues to work in partnership with industry representatives in the shared goal of improving reverse logistic practices and processes for PCs.

Eurosoft Concept The process Eurosoft are proposing will include…

• Testing the unit with QA+WIN/Pc-Check for Windows.

• Converting the QAWIN FAIL output to a formatted output in conformance with RLA’s schema for sQRrl computer error codes as well as a schema to support the Eurosoft error codes.

Proposed Solution Eurosoft is planning an update to their Windows based diagnostic solution that will enable it to:

1. Gather information from system information XML output.

2. Gather test result information from test result XML output.

3. Parse gathered data, filter, sort, and output data suitable for RLA sQRrl Toe Tag

4. Future consideration: Display on screen, upon failure, the sQRrl code so operators can scan the data with their existing tools utilizing for example the refurbishment application developed by Connexus. Through this method, diagnostic outputs can be brought into the RLA process.

The perceived benefit of this approach is to take advantage of future refurbishment tools and processes implemented through RLA.

It is presumed that refurbishers who leverage the future RLA process will be equipped with scanning tools and an application for scanning sQRrl codes and reading and writing to Master Repair Records on a manufacturer’s cloud based database.

Proposed Process

In the proposed process, Eurosoft will output a Toe Tag Data File to a network folder via a mapped drive. A Windows Service created that will send diagnostic output to a label printer at the technician’s workstation.

Computer Industry Error Codes (Pass Fail: only failures listed)

Error Code Options Error code options will be offered in three options:

• Minimal: Basic failure record. (free)

• Extended: Complete failure record including test and error descriptions. (paid)

• Full: Complete failure record including test and error descriptions including disposition report. (paid)

Minimal A minimal set of standardized error codes could be a simple 2-digit component indicator for denoting a diagnostic failure of the component. The standard terse error code set would assign a number to a component type as shown below.

E50

Error codes will be filtered down to the component type so that the string for D51 could appear as follows.

D51 [150815][3 17][01][324]

Code reader could display: DATE: August 15, 2015 ERROR: Audio, Monitor DepotID: Joe’s Computer Repair OperatorID: 324

Extended (Eurosoft Diagnostic Error Codes) It may also be possible to include full diagnostic error codes on the sQRrl label.

Such entries will require more fields, but would contain the full diagnostic error code. Each Eurosoft diagnostic test group includes several error messages for each. The error codes for Audio and Monitor are shown below.

EE50 (proposed subset of the sQRrl code standards) img4

Error codes could be filtered down to the component type, test, and error code so that the string for D51 could appear as follows. D51 [150815][561X 306 0x00/3FF,350X 310 0x00/3FF][01][324] Code reader could display: DATE: August 15, 2015 ERROR: Audio: Failed Quick System Sound Test - The sound could not be played ERROR: Monitor: Failed LCD Dead Pixel Test - The operator has chosen to fail the device based on the appearance of the test DepotID: Joe’s Computer Repair OperatorID: 324

Full (Eurosoft Diagnostic Error Codes with Full Disposition Report) Just like the extended error code senario, error codes could be filtered down to the component type, test, and error code so that the string for could appear as follows.

D51 [150815][561X 306 0x00/3FF,350X 310 0x00/3FF][01][324]

In addition, the following strings would be incorporated into the toe tag data:

• D52 A URL link to the Master Repair record. • D57 Date and time that the product was received. • D53 Identification of receiving site. • D59 Disposition code including a time stamp (optional duplicate of D51) o 01 Repaired returned to sender o 02 Repaired returned to inventory o 03 Refurbished returned to market/channel o 04 Scavenged for reusable components o 05 Recycled o 06 Sent to landfill o 07 Returned to sender without repair. Invalid request. • Optionally, the optical label may also contain D5F Detailed Repair Notes.

The Eurosoft output data would appear similar to this example… D52 [https://www.pcbuilder.com/archive/repair/778654927] D51 [150815][561X 306 0x00/3FF,350X 310 0x00/3FF][01][324] D57 [130815][13:04] D53 [324] D59 [01][150815][15:22] D5F [Replaced sound card part# SB101x Serial# 00123598, and monitor part# SamsungLCD598 Serial# 56-7783-21]

Code reader could display:

MASTER REPAIR RECORD: https://www.pcbuilder.com/archive/repair/778654927 DATE: August 15, 2015 ERROR: Audio: Failed Quick System Sound Test - The sound could not be played ERROR: Monitor: Failed LCD Dead Pixel Test - The operator has chosen to fail the device based on the appearance of the test DEPOTID: Joe’s Computer Repair OPERATORID: 324 RECEIVED: August 13, 2015, 1:04PM RECEIVING SITE: Joe’s Computer Repair DISPOSITION CODE: Repaired returned to sender REPAIR NOTES: Replaced sound card part# SB101x Serial# 00123598, and monitor part# SamsungLCD598 Serial# 56-7783-21

Coverage for Non-Testable Items In addition to enhancing Eurosoft diagnostic operation to include sQRrl data output, Eurosoft proposes to add options for logging the condition of non-testable items such as cases, screens, chassis, etc. With this functionality added to Eurosoft’s diagnostic solution, the complete unit condition, including testable and non-testable items can be captured into the Master Repair Record.

Conclusion Actually, the conclusion is still in progress. The SQRrl Code committee was formed to standardise product labelling across several industries, including computers as they move through the PC lifecycle, which includes refurbishing. Several large organisations have taken part in its steering, and others are waiting for the outcome to unify their own service and returns processes.

This paper explored where the sQRrl code is now in conjunction with Eurosoft (UK) Ltd’s diagnostics work to support the standard AND provide extending test information. The sQRrl code initiative will continue, globally uniting various computer service and reverse logistics. It may be adopted higher up the chain with the OEM then activated by the consumer.

New devices, industry advice, customer acceptance and so on are all being reviewed. This is an excellent opportunity for the computer industry to get involved in a most practical standard that save time and money.

Acknowledgments: The Eurosoft concepts described above were jointly conceived with contributions from Ken Jacobsen and Bruce Brown.

---

Ken Jacobsen
Mr. Jacobsen is the Vice President of Business Devellopement for Connexus: a silicon valley software startup focused on warranty management. He was responsible for the creation of the InfraRed Data Association (IrDA) and for the establishment of the PCMCIA. He has provided technology brokering services for HP, Toshiba, and Lockheed. He was part of the Pocket Intelligence Program at SRI, International and has been involved in numerous startups. Most recently, he was a Director of the Global Software Entrepreneurial Training Program at Oulu University in Finland.