Two Dimensional Bar Code As A Medium For Electronic ... - CiteSeerX

Two Dimensional Bar Code As A Medium For Electronic Data Interchange Robert B. Johnston Alvin Khin Choy Yap Department of Business Systems Monash University Clayton, Victoria, 3168. [email protected] Phone 61 3 99055803 Fax 61 3 99055159

Abstract The development in the late 1980s of two dimensional bar code symbologies capable of storing kilobytes of information in a single symbol and unlimited data in multiple symbols has led to the suggestion that bar code could be used as a medium for transmitting EDI messages. This paper considers whether such a suggestion targets any real business problem and whether such a system would work in practice. Results are reported of three studies conducted addressing different aspects of the feasibility of bar code EDI: its organisational feasibility, its technical feasibility and its practical feasibility.

Introduction Electronic Data Interchange, EDI, is defined by Emmelhainz as "the Interorgizational exchange of business documentation in structured, machine-processable form" (Emmelhainz, 1990, p4). It is normally assumed that the communications media involved in EDI are the usual telecommunications media. However, since the development, in the late 1980s, of two dimensional bar codes with a high data carrying capacity (Itkin and Martell, 1992; Pavlidis, Swatz and Wang, 1992) it is conceivable that structured business data could be transmitted in machine readable form between computer applications using paper as the medium of transmission. This idea has been termed "paper-based EDI" (Seidman, 1993). Since one of the aims of EDI is the elimination of paperwork in the business cycle, it would only make sense to consider this medium when a suitable printing surface remains even in an electronic trading situation. Transmission of shipment information is one such situation, not only because some form of delivery docket is often retained in this transaction but also because the packaging itself provides a potentially suitable medium. Although a number of authors have suggested 2D bar code as a replacement for conventional EDI for advance shipping information (Seidman, 1993; McCracken and Worthington, 1994; McCullouck, 1994; Piatek, 1994; David, 1995) and for import/export documentation (Martel, 1992), there appears to be no account of an actual implementation in the academic literature. All this begs the questions: is there any point in doing EDI this way; and would it work in practice? One reason to consider encoding delivery information in bar code form is that this way its transmission can then be synchronous with the delivery of goods. The conventional approach to transmission of shipment information via EDI using the Advanced Shipping Notice, ASN, transaction set has two disadvantages. Firstly, the ASN must somehow be

Two Dimensional Bar Code as a Medium for Electronic Data Interchange

identified with the physical shipment and, secondly, timing problems in sending or processing the ASN can disrupt goods receiving (McCracken and Worthington, 1994; David, 1995) especially in a Just-In-Time environment where many small shipments arrive daily from suppliers often situated close at hand. Also in a JIT environment telecommunication costs become significant. This paper reports an investigation of the feasibility of using a 2-D bar code symbology (PDF417) as a means of transmitting shipping information by printing the bar code symbols that encode the data on the normal human readable paper delivery docket. Three aspects of its feasibility have been studied (Yap, 1997); • Organisational feasibility: Are there problems with existing approaches to materials

replenishment for which bar code EDI would be a feasible, cost effective and sensible solution? To answer this question two interview case studies were conducted with two Melbourne based automotive manufacturers who are advanced users of EDI in a Just-InTime replenishment environment. • Technical feasibility: Do the hardware and software components currently exist from

which a practical and robust system for 2-D bar code EDI can be built? This question was investigated by building a prototype system using Windows based PC tools. • Practical feasibility: Would such a means of transmitting EDI withstand the rigors of the

practical physical environment? This was investigated by testing the bar coded delivery dockets for their ability to remain readable by machine after physical abuse. The paper is organised as follows. A brief overview of 2-D bar coding and its applications and relationship to EDI is given. Then the particular 2-D bar code symbology selected for this study is described in detail. A description of the three feasibility studies and their results follows, and then conclusions are drawn.

Two Dimensional Bar Codes. Conventional linear, or one dimensional bar codes have been used to automate the identification of products since about 1970 (Harmon and Adams, 1990). However their small data capacity (around 30 characters) limits their usefulness for the direct transmission of business data in machine readable form. Within the standard Electronic Commerce model (Johnston and Lee, 1996) their main role is to allow a connection to be made between physical shipments and Advanced Shipping Notice information sent by electronic means ahead of the physical shipment. A bar code printed on a delivery docket or on a carton encodes a shipment number that can be scanned at the receiving station and used to retrieve the pre-loaded shipping data sent via EDI. This application of linear bar codes is typical - the data encoded in the bar code is a key field or "licence plate" and additional information about the object marked with the bar code is necessarily held off-line on a database record to which the coded data is a key. This arrangement is necessary and desirable for many applications, such as point of sale systems, where the off-line data is changeable. However there are applications where, if the whole data record could be encoded into the bar code, the result would be desirable (McCullouck, 1994). These applications arise -

PAWEC ’ 97

13 -

2


• When the data is essentially unchanging e.g. in labelling historical samples of products. • When reliance on a connection to a computer is not desirable e.g. hazardous goods

information in fire fighting situations. • When the data encoded is for once only use e.g. shipment information.

For these applications, high density bar codes, which use the vertical dimension of the symbol to carry extra information, have recently been develloped (Itkin and Martell, 1992; Pavlidis, Swatz and Wang, 1992). They can hold up to 2 kilobytes with a single symbol and unlimited data in multiple symbols. The concept is often referred to as a "portable data file" (Itkin and Martell, 1992).

Figure 1: Matrix Bar Codes: The Datacode And Philips Dot Code. (After Pavlidis (1992). These example do not necessarily represent legal codes). Two main approaches have been used to extend the data capacity and data density of bar codes; stacked linear bar codes and matrix symbols (Itkin and Martell, 1992; Pavlidis, Swatz and Wang, 1992; Johnston, 1997; Yap, 1997). The first approach is to stack a number of conventional (linear) bar code symbols of reduced height above each other. The second approach is to divide the whole area of the symbol into pixels and encode the information in the colour (light or dark) of the pixels. The matrix symbol systems have generally been developed for special applications and, while they can achieve high data density, they require complex, and often proprietary, equipment based on Charge Coupled Device (CCD) technology and pattern recognition software.

Figure 2: A PDF417 Stacked Bar Code Symbol. (This symbol encodes 1437 bytes of text data and is reproduced approximately full size.) By contrast, stacked bar codes can be read by conventional laser scanners and the output signal can be translated using conventional signal processing techniques. Several stacked bar code symbologies have had their symbology standards placed in the public domain (Pavlidis, Swatz and Wang, 1992). This is important for large scale Electronic Commerce adoption because it means that a number of independent scanner and printer manufacturers are being encouraged to support these symbologies as standard. The chief disadvantage of stacked bar

PAWEC ’ 97

13 -

3


codes is that reading is rather sensitive to symbol orientation. This is not a great problem for the applications discussed here where (compared to, say, a point of sale applications) the orientation can easily be controlled.

PDF417 The most sophisticated stacked 2 dimensional bar code symbology to date is PDF417 developed in 1989 by Symbol Technologies, a significant US bar code equipment manufacturer (Itkin and Martell, 1992). PDF417 appears set to become the dominant 2 dimensional bar code symbology for several reasons; • It is readable by conventional laser scanning equipment (most recently designed laser

readers support it) and printable on ink-jet printers. • Its symbology encoding standard is public domain. • Its use has been incorporated into the standards of a number of important bodies in the

U.S. including the Automatic Identification Manufacturers trade body AIM, the influential Automotive Industry Action Group, AIAG, and the American National Standards Institute, ANSI (Yap, 1997). • It has a very high data capacity and density. Each symbol can code up to 2725 bytes of

data at a density of about 300 - 500 bytes per square inch. • It is made less sensitive to scan orientation than other stacked bar codes through the use

of multiple encoding tables that allow partly read rows to be "stitched" back together, in memory, from the partial data of several consecutive scans. • It not only has error detection but also error correction that allows a corrupted

symbol to still be completely read. • PDF417 can encode binary data as well as ASCII text and can therefore encode sound

and pictures. Error correction is an important requirement of high density bar codes. Most linear bar codes use check digits and other features to detect an incorrect read. If a read is unsuccessful the user can either re-scan the symbol through another scan path or they can manually enter the data which is usually printed conventionally under the machine readable symbol. Neither of these options is available to the user of 2-D bar codes, firstly because they lack the symbol redundancy in the vertical dimension and, secondly, because it is impractical to accurately enter several thousand characters of data manually. Consequently, it is insufficient to just detect read errors with 2D bar codes: they also require error correction features. These are achieved using internal coding redundancy and checksums (Reed Solomon error correction routines (Blahut, 1984)). PDF417 allows for 9 levels of error correction. At level 0, none of the symbol data is devoted to error correction and no symbol corruption is tolerable. At level 8 approximately 50% of the symbol data is dedicated to error correction check sums and the symbol can still be completely decoded with approximately 50% of the symbol corrupted.

PAWEC ’ 97

13 -

4


Two Dimensional Bar Code As A Medium For Transmitting EDI It is clear from the data capacity of PDF417 that 2-D bar code could in principle be used as a medium for transmitting structured business information in a machine readable form from application to application, that is, as a medium for EDI. However, the following three question need to be asked of such a proposal • Does such a process solves any business problem that conventional EDI does not? • Does the equipment and software exist to build a cost effective and robust system? • Can bar codes printed on cardboard of paper survive the rigors of practical use?

A research project was undertaken (Yap, 1997) aimed at answering these three questions. The project consisted of three investigations: 1. Interviews with materials management and systems personal at Toyota Motor Corporation Australia and Ford Australia, both major automotive manufacturers in Melbourne, were conducted in mid 1996. These case studies built on previous ones in the same companies (Johnston and Lee, 1996; Lee, 1996) in which the use of EDI and bar coding in their material replenishment cycles was extensively documented. These two companies differ substantially in their approaches to materials replenishment, the former using a "pull" (DeToni, Caputo and Vinelli, 1988) discipline and the latter using a "push" discipline. They also use EDI extensively and are actively pursuing the Just-InTime philosophy. The distinction between push and pull approaches to JIT and their relationship to EDI is not generally discussed in the EDI literature, which generally implicitly assumes a push replenishment discipline (Johnston and Lee, 1996). It was therefore considered important to investigate the use of bar code EDI in both contexts because the information requirements are quite distinct. 2. A prototype system was constructed using PC based tools to enter, store, retrieve and print delivery dockets together with the PDF417 encoded version of each, and to recover and store the delivery docket database record by scanning the PDF417 symbols on the printed version of the delivery docket. 3. Tests were performed on the PDF417 symbols to determine the ability of the medium to withstand damage and distortion likely to occur in practical use, and to determine what level of error correction should be used in practical applications. The results of the studies are outlined in the following three sections.

The Business Opportunity For Bar Code EDI Ford Australia The Ford Motor Company of Australia Limited (Ford Australia), located near Melbourne, Australia, is a subsidiary of the Ford Motor Company at Dearborn, USA. Employing 7000 workers Ford Australia is the second biggest manufacturing enterprise in Australia. Ford produces about 125,000 vehicle units per year. It uses approximately 8000 local parts and 250 imported parts and has 220 parts suppliers. It is the largest consumer of locally manufactured

PAWEC ’ 97

13 -

5


parts and it is currently running an inventory of about 10 days stock (although the stock level of some component replenished by JIT is smaller than this) (Johnston and Lee, 1996; Lee, 1996). Ford currently requires about 95% of its part suppliers to send an ASN in advance of the physical shipment which is also accompanied by a printed delivery docket. The ASN pre-loads the receiving system and a Receipts List is printed from the ASN in the receiving area which is used to check the physical shipment. The ASN is identified with the physical shipment via the delivery truck registration number, which is used as a reference in the EDI ASN. Discussions with Ford materials management staff revealed the following problems with their current system; • Use of the truck registration number effectively limits the system to parts that are

delivered no more that once per day, and also caused problems when several supplier’s shipments were consolidated onto one truck. • Because of Ford’s leading position in the automotive industry and their increasing

insistence on JIT deliveries, many of Ford’s suppliers are positioned less that 10 minutes drive away from the Ford plant. Ford currently polls their EDI Value Added Network Service every 10 minutes to retrieve ASN data. Therefore, especially with parts that are being called up by JIT, there is no guarantee that the ASN arrives before the physical shipments, causing delays and congestion. • The EDI ASN process is dependent on computers at the supplier site, the Value Added

Network Service and at Ford all being operational. However, given the computer dependent nature of the automotive industry operations, this is generally the case. The first problem can be solved by using a unique identifier for the shipments, bar coded on the delivery docket or cartons. The second problem can only be solved within the existing framework by polling the VANS more frequently - and expensive option at a cost of $0.50 upwards per call. In the interview, Ford management considered the use of a delivery docket with all data bar coded using high density bar codes a feasible solution to all three problems. Ideally the delivery docket should be produced directly by scanning linear bar codes on the actual goods shipped. They did, however, point out that the ASN currently served to provide goods-intransit information that was useful in the advent of stock-outs. In further discussion they agreed that this information could probably be done without as more products went over to JIT delivery. In summary, managers at Ford, who were currently considering the use of bar coding on delivery dockets and who had also recently become aware of PDF417, considered that two dimensional bar coded shipment information would be a solution to problems that the asynchrony of the EDI ASN information and the actual shipments created, especially in a JIT delivery environment. Toyota Motor Company Australia The Toyota Motor Company Australia Limited (TMCA) is located in Melbourne, Australia and is a subsidiary of Toyota Motor Corporation (TMC) of Japan. The company produces

PAWEC ’ 97

13 -

6


around 100,000 vehicle units per year. TMCA uses about 3000 locally sourced parts and about 5300 imported parts. It has 120 independent local parts suppliers, 19 TMCA owned local suppliers, two overseas Toyota affiliate suppliers and two overseas non-Toyota suppliers. It receives about 500 local deliveries a day and as a result of an extensive Just-InTime delivery initiative it currently carries about 4 hours stock of locally supplied parts (Johnston and Lee, 1996; Lee, 1996). While TMCA uses EDI to transmit Material Requirements Forecasts to almost all parts suppliers it has made a deliberate decision not to use EDI at the operational level. In keeping with the Toyota Production Systems principles (Monden, 1983) which the company has rigorously implemented, TMCA uses a "pull" (DeToni, Caputo and Vinelli, 1988) discipline for replenishments with local suppliers. They use the Kanban system, popularised by their parent company, together with a bar coded turnaround delivery docket. This is a manual control system based on cards (Kanban means card in Japanese) which act to both authorise replenishment and control stock levels of parts (Schonberger, 1987). Local parts are delivered directly to the production line where they are used. As Kanbans are released by consumption of the parts at the production line, they are delivered to a Kanban sorting area where they are sorted electro-mechanically into vendor part number sequence, using bar coded data on the Kanban. The sorting system also produces a delivery docket with a bar coded delivery number, on behalf of the supplier, and also transmits the expected delivery records to the receiving system. The Kanbans and the related delivery dockets are picked up by the vendor’s carrier upon the next delivery. Each vendor delivers parts at least twice a day. The transport driver must arrive during a pre-assigned delivery time window, and drop off the present delivery of parts together with the associated Kanbans and delivery docket. The delivery docket is scanned with a bar code reader by receiving staff to recall the expected receipt information and checked against the goods and the Kanbans. The parts are then taken to the production line with their Kanbans to complete the replenishment cycle. While this system elegantly satisfies Toyota’s information needs within a pull replenishment framework, it suffers two disadvantages which were recognised and discussed by the interviewees at Toyota. • Since the bar code on the Delivery Docket is of the "licence plate" type, this bar code

cannot be used by the supplier to access data on the delivery docket. It only serves as a turnaround key to data on TMCA’s systems. Toyota had rejected the idea of sending JIT call-up transactions sets by EDI to the suppliers on the grounds that it was not necessary using the Kanban pull systems and also, with 500 or more transactions per day, prohibitively expensive. Thus the suppliers do not obtain machine readable information on requirements that can be used to update their own systems. • A secondary result of the previous problem is that Toyota receives invoices from

suppliers which are based on data not ultimately derived from Toyota’s own data, as they would be in the conventional "push" EDI approach. (Toyota is in the process of implementing Evaluated Receipts System (Hammer, 1990) but many suppliers still send manual invoices). This leads to discrepancies that must be resolved by Accounts Payable. The company that produced the Kanban sorting system used by Toyota had recently suggested bar coding the delivery dockets using two dimensional bar codes (of a proprietary matrix

PAWEC ’ 97

13 -

7


symbol type). The production management staff interviewed believed that using high density bar coding to transmit the requirements information in publicly readable form would solve these problems and also be in keeping with trends in the industry for sharing information down the supply chain. Toyota had been criticised by suppliers in the past in this regard (Lee, 1996). To summarise this section, both Ford and Toyota saw distinct advantages in using high density bar codes as a means of transmitting shipping information. Within Ford’s push replenishment systems it would solve problems arising from the asynchronicity and high cost of the conventional EDI approach. These are the motivations for bar code EDI usually cited in the literature (McCracken and Worthington, 1994; David, 1995). In addition, discussions with Toyota revealed an entirely different opportunity of bar code EDI which was to send shipping information cheaply in the opposite direction, from customer to supplier. This opposite flow direction of information is characteristic of the difference between push and pull replenishment disciplines and it is interesting to note that the challenge of EDI in pull JIT approaches are seldom considered in the EDI literature (Johnston and Lee, 1996). For Toyota bar code EDI potentially provides a means of sharing information in a machine readable form with vendors at minimal cost, and some advantage, to Toyota.

Technical Feasibility Of Bar Code EDI. In order to show that the hardware and software exist to create cost effective and robust bar code EDI systems a prototype system was built using PC windows based tools. This required the selection of the following development components. • Bar code scanner. At the time of evaluating the hardware options (early 1996) only two

scanners supporting PDF417 were available. The LS 4800 from Symbol Technologies which was selected is a conventional laser scanner and supports all commonly used linear bar code symbologies as well as PDF417. It has an integral decoder whose ASCII data output string can be sent directly to the PC keyboard buffer using a keyboard wedge. When the scanner detects the start and stop patterns characteristic of PDF417 in alters the scan pattern from linear to raster scan. It can fully read a PDF417 symbol in about 1 - 3 seconds. This unit costs about $2000. The other option was the Intermec J7010 Hand Held Imager which reads linear, stacked and matrix symbols using CCD camera technology but was almost twice the price of the LS 4800. • Bar code printing software. There are basically two types of bar code printing packages

on the market; those that allow the user to layout a complete bar code label and retrieve data for the label from various databases, and those that create a bar code as a picture object for use with other windows programs via Dynamic Data Exchange, DDE. The later type was most appropriate to this application and B-Coder (produced by TAL Industries, Philidelphia, PA.) was chosen. It costs about $500 and supports all major linear symbologies and PDF417. • Printer. PDF417 can be printed by any 300 DPI or better printer. A NEC Silentwriter

Laser printer was used. • Database and development environment. Microsoft Access Version 2.0 was used in this

project because of its support of DDE, relatively simple use and support of picture object types for data base fields.

PAWEC ’ 97

13 -

8


Delivery Docket Entry Program. A program was developed that allowed a typical delivery docket to be entered, stored on a database, retrieved and printed. The user interface incorporated standard Microsoft navigation metaphors. As delivery docket information from the screen buffer was used to create or update the data base records the data was sent to the B-coder program in background, using DDE, and the bar codes were returned as windows metafile pictures for storage with the delivery docket. The delivery docket had a fixed header and multiple line items. The field sizes and layout were derived form those used by Ford and Toyota and other examples (Eliason, 1991). While both Ford and Toyota required suppliers to send a single page delivery docket which could easily be encoded in a single PDF417 symbol, it was thought that, in the interests of generality and to fully test the bar code EDI concept, the program should handle delivery dockets with unlimited line items requiring more that one PDF417 symbol. When the delivery docket is printed, the bar codes appear on the last page of the delivery docket and incorporate a bar code counter and end of file indicator in the encoded data. As the level of error correction, and thus the capacity of the bar codes, was user selected, the overflow logic for bar code creation had to take account of this level setting using a lookup table of bar code capacity. Delivery Docket Reading Program A second program was developed with very similar user interface and database design to receive and store shipping information scanned from the bar coded paper delivery dockets. Thus the contents of the paper delivery docket could be recovered and scrolled though by the receiving clerk and actual received quantities could be entered before updating the database. The main technical issue was to allow the user to scan the entire delivery docket, which could have multiple bar codes, with minimum interaction with the keyboard. The program can detect out-of-order or incomplete scanning of the bar codes and display suitable messages, but if the sequence of scans is correct and complete, no interaction via the key board is needed. The prototype development demonstrated that the tools do exist and interface with each other sufficiently to make bar code EDI practical on a PC based platform. The availability of the same tools for mini or mainframe environments was not investigated, but down loading data to a PC front end seems a reasonable architecture anyway.

The Practicality Of Bar Code As A Medium For EDI A number of tests were conducted on the delivery dockets produced by the program described above to test to resilience of the systems to physical abuse of the documents, and also to determine the level of error correction the user should select given that this requires a tradeoff between tolerance of abuse and data capacity of the symbols. The abuse tests included • Drenching the paper to simulate rain damage • Marking the paper with footprints • Controlled obliteration of the symbols to simulate damage such a staining with ink blobs • Crumpling up

PAWEC ’ 97

13 -

9


• Faxing the delivery docket

The detailed test can be found in (Yap, 1997). It was found that the PDF417 bar codes were extremely tolerant to staining and obliteration. At the highest error correction levels about 50% of the symbol could be obliterated and the message still recovered exactly. (Note that unless the entire message can be reconstructed the decoder will not signal a good read and transmit data). Since using the highest level of error correction merely halves the capacity of the bar code, in an environment where few line items are used the highest error correction can probably be used without causing more than one bar code to be needed. However, the readability of PDF417 symbols is greatly compromised by crumpling and by faxing. Both a delivery docket crumpled up into a ball and flattened (as in accidental discarding) and one that had been faxed to and printed on an ink-jet plain paper fax machine could not be read at the highest error correction level. The former is not operationally important but the later could pose problems in some situations such as resolving disputes quickly. Presumably the resolution of the fax printer is insufficient, and it is speculated that the crumpling problem arises because the signal processor in the bar code reader expects to find a spatially regular clock signal (usually detected by a phase locked loop (Pavlidis, Swartz and Wang, 1990)) in the bar code pattern, which is destroyed when portions of the page are seen at slightly different angles.

Conclusion This paper has reported research designed to test the feasibility of using two dimensional bar code technology (specifically PDF417) as a means of delivering shipping information, in a machine readable form, from the point of view of organisational feasibility, technical feasibility and practical feasibility. Case studies indicated that there was a clear business advantage in using the technology both in push and pull type replenishment systems. The technical feasibility was demonstrated by the production of a practical and robust demonstration system using inexpensive hardware and PC based software tools. Finally the method of delivery appears to be sufficiently robust to physical abuse to be practical. PDF417 appears to have matured as a standard to the extent where there is probably no significant danger in committing to this symbology, and we can expect reports of application of it in Electronic Commerce contexts to increase in the near future.

References Blahut (1984). Theory and Practice of Error Control Codes, Reading, MA, Addison-Wesley. David (1995). “2-D or not 2-D Becomes Industry Controversy.” Automatic I.D. News(November), 6. DeToni, Caputo and Vinelli (1988). “Production Management Techniques: Push-Pull Classification and Application Conditions.” International Journal of Operations and Production Management 8(2), 35-51. Eliason (1991). Online Business Computer Applications, New York, Macmillan.

PAWEC ’ 97

13 -

10


Emmelhainz (1990). Electronic Data Interchange: A Total Management View, New York, Van Nostrand. Hammer (1990). “Reengineering Work: Don't Automate, Obliterate.” Harvard Business Review 68(4), 104-112. Harmon and Adams (1990). Reading Between the Lines: An Introduction to Bar Code Technology, Helmers Publishing Inc. Itkin and Martell (1992). A PDF417 Primer, Bohemia, NY, Symbol Technologies. Johnston (1997). Electronic Commerce: An Operational View, Melbourne, Department of Business Systems. Johnston and Lee (1996). “The Role of Electronic Commerce Technologies in Just-In-Time Replenishment.” Proceedings of Hawaii International Conference on Systems Science, Hawaii. Lee (1996). Rationale for Adopting Electronic Commerce in the Australian Automotive Industry, Unpublished Masters Thesis. Monash University, Melbourne, Australia Martel (1992). “PDF417 Aids EDI in Transportation.” EDI World (December). McCracken and Worthington (1994). “2D Codes Provide Larger Data Capacity for Automatic Identification Applications.” I&CS (December), 57-64. McCullouck (1994). “2D Bar-Code Applications in Construction.” Journal of Construction Engineering and Management 120(4), 739-751. Monden (1983). Toyota Production System, Norcross, Institute of Industrial Engineers. Pavlidis, Swartz and Wang (1990). “Fundamentals of Bar Code Information Theory.” IEEE Computer Magazine 23(4), 74-86. Pavlidis, Swatz and Wang (1992). “Information Encoding with Two-Dimensional Bar Codes.” IEEE Computer Magazine 25(6), 18-28. Piatek (1994). “Automative Industry Recommend 2-D Standards.” Automatic I.D. News (August), 54-56. Schonberger (1987). “The Kanban System.” Just-In-Time Manufacture, Voss, C.A. (Ed.). London, IFS Ltd. UK, 59-71. Seidman (1993). “BC Labels Turn High-Tech.” Distribution (January), 83-84. Yap (1997). The Feasibility of Using Two Dimensional Bar Codes as a Medium for Electronic Data Interchange, Unpublished Masters Thesis. Monash University, Clayton

PAWEC ’ 97

13 -

11