Bert Moore

Introduction

A lot of work went into the creation of various identifier standards that make life easier and data entry more accurate. Yet despite the fact that some of these standards have been in existence for upwards of ten years, some hardware and software vendors don't seem to be aware of them. Here's what you need to know about them to make sure that your systems can use the features provided by these standards.

Data/Application Identifiers

When the Automotive Industry Action Group (AIAG) introduced its tiered label format, it revolutionized the way we look at bar code labeling. Instead of a single bar code to identify a product, the AIAG B-3 label introduced the concept of multiple bar codes to represent data important to the receiver.

They also introduced Data Identifiers (DIs), alphanumeric strings preceding data to indicate the intended use of the data (e.g., part number, P.O. Number, quantity).

Without DIs, AIAG members realized that there was no guarantee that the correct bar code symbol would be scanned in the correct order. With DIs, software can validate that the symbol scanned is the symbol intended to represent the type of data for a given database field.

In other words, they prevent telling the database that 50 shelf locations are stored in a carburetor in Warehouse 5.

The power of this concept resulted in the development of an inter-industry standard, ANSI/FACT-1 Data Identifiers (1992), applicable to virtually any industry and any application. An ANSI/FACT-1 DI is made up of 0 to 3 numerics followed by an upper case alphabetic.

The Uniform Code Council (UCC) and EAN International developed a similar series of all-numeric identifiers called Application Identifiers (AIs), for use with the UCC/EAN-128 symbol. The document is titled "ANS/UCC-4, UCC/EAN-128 Application Identifier Standard."

AIs can be 2 to 4 digits long, defined by the first one or two digits of the string.

A revision to ANSI/FACT-1, due out late this year, includes both identifier standards and provides mapping between the systems. The document also introduces the term Data Application Identifier (DAI) for generic reference to the two systems. There is a DI or AI for virtually every application, external as well as internal.

DIs are not technology-dependent. The AIAG, taking RFID manufacturers literally when they began talking about tags as "electronic labels," developed an electronic version of the B-3, DIs and all.

DAIs are also used in two-dimensional symbology standards and are referenced in most European and other world standards as well.

Symbology Identifiers

There are times, however, when it's impossible to include a DAI in a symbol (such as the fixed data content U.P.C. or the Interleaved 2-of-5 Shipping Container symbols) or where a special feature of the symbol must be known (such as the non-ASCII, non-transmittable FNC1 in UCC/EAN-128 symbols).

In these instances, you need to know the source symbology if you're to properly use the data.

Enter Symbology Identifiers (SIs), published by AIM USA. These identifiers aren't encoded in the symbol, they're generated by the bar code reader, a report on the decoding algorithm and special features used or encountered. SIs have a fixed three-character format: ]an (where a is alphabetic and n is numeric).

The transmitted SI for a Code 128 symbol would be ]C0. For a UCC/EAN-128 symbol, it would be ]C1. In some applications, this will be the only way to accurately, and automatically, differentiate between in-house or industry Code 128 and UCC/EAN-128 symbols. Without SIs, you wouldn't know how to process the data in the symbol.

SIs even provide a means to identify data that was key-entered instead of scanned.

Using DAIs/SIs

There's a misconception that, once you've chosen an identifier system, that's all you can use. It is true that the fewer variables you have, the simpler the system.

However, there are situations where both DIs and AIs could arrive at your Receiving dock or be provided to customers. You may use DIs internally along with U.P.C. How do you sort it all out?

Primarily, you use SIs. Since they identify the source symbology, it's easy to differentiate between standard Code 128 and UCC/EAN-128 -- or any other symbology within your system.

Your software needs to be able to check the SIs and DAIs, determine what the data represents, strip the identifiers, then route the data to the appropriate field in the database.

Using DAIs/SIs

Obviously, to take advantage of the various identifiers, your system has to be able to generate and recognize them.

And that's the problem.

Few bar code decoder manufacturers seem to be aware of the AIM USA symbology identifiers (first published in 1992). Most vendors provide their own symbology identifiers or allow users to program their own. But the formats aren't the same as the AIM USA identifiers. This means equipment changes will probably require programming changes for a different symbology identifier format.

For DAIs, it's a different story, a software story.

Many software developers aren't really part of the AIDC community. They've never heard of DAIs, much less SIs. And while some of them provide AIDC hardware with their systems, it's simply an add-on.

How do you handle identifiers with host software that is incapable of processing identifiers? If you're able to pre-process data, either through batch portable data collection or through a PC front-end on your host, you can parse data there and then ship it up to the host. Some bar code wedge readers and data collection terminals also have enough on-board intelligence to allow you to develop programs that use identifiers and then strip them before transmitting to the host. If you're running terminal emulation on an RFDC terminal, however, the answers are all bad.

RFDC base stations can sometimes strip DAIs (and SIs) before passing data to the host. Device mapping can be used in some cases to strip identifiers as well. Or you can have two look-up tables for data: one with and one without identifiers. As long as the data is known beforehand. If it's coming from outside, you're back to stripping them before you use them.

As Marilyn Sherry of AIAG commented, "stripping identifiers before they're used is like putting a penny in a fuse box." It works, but it's not a great idea. (For those too young to remember what a fuse box is...well, never mind, ask someone old to explain it to you.)

Why Bother?

In seminars I've given across the country, I almost always include Bert Moore's First Law: "Without proper planning, a successful AIDC system can become your worst nightmare."

Systems grow, new technologies and new applications are developed, and it becomes more difficult to manage the growth without proper planning. To paraphrase a popular expression "Change Happens."

Planning for change means using identifiers. They allow you to expand the system, change symbologies, and even add technologies without having to spend your whole life designing new data structures to avoid crashing the old ones.

You can write your own patches, do PC or terminal-based pre-processing, work around most of the problems. But you shouldn't have to.

If software doesn't recognize identifiers, it's not AIDC-driven software, it's just software (however good it may be). And bar code readers that don't offer AIM USA symbology identifiers aren't system readers, they're just readers (no matter how good they are).

Software and hardware vendors won't rush to change what they already have unless customers tell them they want to use identifiers. So, even if you're not planning to buy anything in the near future, ask vendors how they handle identifiers. And watch the reaction.

Is it worth the trouble?

Consider this: "Today's software is tomorrow's legacy."

Yeah. It's worth the trouble.