Part II: Organizational Prerequisites for Smart Materials, Automatic Identification, and Quality
Chapter 10: The Chorafas Classification/Identification System for Supply Chain Requirements
10.2 Benefits Resulting from Architecturing an Identification Code
The point was made in Chapter 10.1, that with DCS, each classification number has a dedicated identification code in one-to-one correspondence, and that an ideal ID code must be short and unique.
One can enrich this reference with the statement that this uniqueness should respond to functional requirements. The problem that arises most often is that there are conflicting functional criteria. What suits one department is not necessarily what another department wants to have.
There is also another challenge. Some of the functional requirements change over time, particularly those connected to marketing. In contrast, engineering drawings are rather stable; when they change, a different product is born. Based on these premises, the identification number of DCS has been divided into three parts, in order of priority:[2]
1. basic code, <bc>, for engineering characteristics 2. suffix, <s>, for commercial requirements
3. origin, <o>, for identification of the factory where the product is made
To better follow the rationale for this three-way division of ID, one should bring it into historical perspective. DCS was first developed in 1969 to serve the needs of Osram GmbH, a German lamp company that now operates in the United States as Osram-Sylvania. Osram had its base in Munich and Berlin. When the groundwork of the parallel code system was completed, an argument developed between the design engineers and the commercial executives. What is a lamp? Or, more precisely:
How should a given product be identified?
The most concise answer is that a product should be identified through its technical characteristics.
However, the commercial people argued that issues such as trademark, packaging, and some additional information (e.g., stamps put on a product) constitute equally valid references that must be coded; they cannot be omitted. As well, the argument was advanced that a coding system either satisfies every end-user's requirements, and thus stands a good chance of being adopted by everybody; or it does not, and therefore it never establishes itself, let alone becomes universal; it remains parochial.
The problem is that, in the general case, nobody has really thought out the answers well — despite the fact that on a number of occasions research demonstrated that much of today's confusion in item
coding by a typical firm originates in the matter-of-fact discrepancy between the engineering identification and sales identification of the same item.
Not everyone who works on the development of a coding methodology appreciates this principle. Even standards' bodies fail to observe it. Yet, since 1969, I have been able to ascertain this discrepancy a hundred times and did so with several companies — both those that have been successful in their efforts to classify and identify their wares and those that failed despite the time and money they spent on ID.
While the specifics of the work done for classification and identification reasons vary from one case to another, the bottom line is that the queries being asked are the same: What is a product? What is a factory? How should they be defined? How should they be identified? Fast and dirty answers will not do because they will not pass the test of time. It is not easy to identify a product, any product.
The research that I did both before and after DCS provided plenty of evidence that identification code and classification code should work in parallel with one another. Translating a given code into another, within a given industrial operation, has always caused delays, difficulties, and mistakes. A new code system should avoid such deficiencies. Exhibit 10.3 identifies the nuts and bolts of the adopted solution:
The basic code is allocated on the basis of the technical characteristics of an item (or data) as outlined in the classification code (taxonomy and <bc> oriented further definiens).
The suffix <s>, which complements the basic code, identifies commercial or secondary characteristics of an item (or data), depending on the family in which that item belongs (see Chapters 10.3 and 10.4).
The origin <o> indicates where an item was made (multiple production sites is a frequent case with globalization), or where the item is installed (this is the case with machines).
Exhibit 10.3: A Closer Look at the Structure of the Parallel Code System
Both suffix and origin depend on and complement the basic code. Neither can stand on its own.
Furthermore, if the origin is to be shown, the suffix must precede it. Item identification can be done through the basic code alone: five digits plus parity for a total of six; or through ten digits: <bc>, plus 2 for <s> and 2 for <o>.
The power of this coding solution is significantly increased through a higher radix than decimal. I have mentioned radix 32 as a possibility. In Osram's case, the hexadecimal system (radix 16) was chosen.
One can take a quick look into this approach and the possibilities that it offers in coding.
A radix 16 requires an equal number of distinct digits. This consists of 0…9 and A…F, used not as alphabetic characters but as numbers (10 to 15). Because 16 = 24, each number 1…E is written through four binary digits. Hence, in binary form, the basic code has 24 digits, including 4 bits for parity. But for man/information communication, it is written in a six-digit (five + parity) hexadecimal form. This
simplifies reading (see Exhibit 10.4).
Exhibit 10.4: Six-Digit (Five + Parity) Hexadecimal Form
Selection of the identification number structure has reflected a concern for transcription and
transmission requirements; it has been purposely chosen as a short number with a parity check. The use of a five-digit (plus parity) hexadecimal notation offers the ability to identify more than 1,000,000 items in a continuous assignment of numbers in <bc>, as no classification work needs to be done by the ID structure.
This identification potential is impressive, as in actual application only the difference in technical characteristics reflects itself into <bc>, and leads to a difference in the basic code. Nontechnical issues are presented by means of the <s>. Typically, the suffix employs two hexadecimal digits, and so does the origin. In hexadecimal code, this assures 256 possibilities for each.
The careful reader will appreciate the flexibility of this solution. If necessary, the identification capability of the basic code can be increased in either of two ways: by adding an extra hexadecimal digit to the left, bringing the identification potential to over 16,000,000 positions; or by switching to a number system of radix 32, thus making available roughly 33,500,000 positions with five digits plus parity.
Neither change will upset the numbers thus far allocated because either (and both) expansion(s) constitute(s) a system development within the chosen range of coding flexibility:
A five-digit (plus parity) hexadecimal number is a subset of a six-digit plus parity hexadecimal number.
A five-digit hexadecimal number is a subset of five-digit number radix 32.
A two-digit <s> and a two-digit <o> benefit from the second alternative: radix 32. The identification possibilities increase for each to 1024. Alternatively, the two-digit hex of <s> and <o> can be increased to three-digits (first alternative). Exhibit 10.5 presents the digit structure for radix 16 (hexadecimal) and for radix 32. The overall system for identification code is flexible, easy to apply, streamlined, and efficient.
Decimal Radix 16 Radix
32 Decimal Radix 32
0 0 16 G
1 1 17 H
2 2 18 J
3 3 19 K
4 4 20 L
5 5 21 M
6 6 22 N
7 7 23 P
8 8 24 R
9 9 25 S
10 A 26 T 11 B 27 U 12 C 28 W
Decimal Radix 16 Radix
32 Decimal Radix 32
13 D 29 X 14 E 30 Y 15 F 31 Z Note: I, O, Q, V are omitted to avoid confusion: I, O with one and zero; Q with O; V with U.
Exhibit 10.5: Digits of Radix 16 and 32
[2]See also D.N. Chorafas, Computer Erfolgreich Einsetzen, Verlag Moderne Industrie, Munich, 1970.