Achtergrondinformatie QR-code op aanvoerbrief 2.xx.0

Transcriptie

1 Achtergrondinformatie QR-code op aanvoerbrief 2.xx.0 Door: Bert Velthuijs Datum 1e versie: 20 september 2012 Datum laatste wijziging Huidige Versie: 2.xx.0 Wijzigingen

2 Inhoudsopgave 1. Inleiding Ontwerpcriteria Verantwoording gemaakte keuzes Flexibiliteit en toekomstbestendigheid (backward compatibiliteit) Flexibiliteit voor de verschillende veilingen en andere gebruikers Efficiënte codering Fixed fields versus scheidingsteken Datamode Klok/BB Foutniveau...5 Appendix I: Algemene informatie QR-code Versies Foutcorrectie Datamodes Numeriek Alfanumeriek bit byte Kanji...7 2

3 1. Inleiding Vanuit de veilingen bestaat er een behoefte om informatie omtrent een levering in een QR-code op de bijhorende aanvoerbrief af te drukken. Hiermee wordt het namelijk mogelijk deze informatie snel met behulp van een scanner in het veilsysteem te zetten, zodat een storing in het EAB-systeem geen desastreuze gevolgen voor het veilproces meer hoeft te hebben. Gezien de beperkte ruimte op de brief, zal de gecodeerde informatie een subset zijn van de informatie die in de EAB aanwezig is. Begin 2012 is er een discussie op gang gekomen tussen Plantion en AntEater, waaruit naar voren kwam dat Plantion graag met de QR-code aan de slag wilde. AntEater heeft toen een voorstel voor een specificatie gemaakt, waarna in samenspraak met Plantion tot de definitieve vorm is gekomen. Dit document beschrijft de ontwerpcriteria, en bevat een verantwoording van de gemaakte keuzes. Als bijlage is een korte technische beschrijving van QR-codes in het algemeen opgenomen. De volledige specificatie van de opbouw van een QRcode staat beschreven in: ISO/IEC 18004:2000. Andere relevante documenten: - Specificatie QR-codes op aanvoerbrief: Technische specificatie van de datastrucuur. - Specificaties velden QR-code op aanvoerbrief zijn de kolomdefinities gespecificeerd. Zie ook: 2. Ontwerpcriteria De volgende ontwerpcriteria hebben een belangrijke rol gespeeld bij het totstandkomen hiervan: 1. Er moet voldoende flexibiliteit zijn voor toekomstige aanpassingen. Als er een veld toegevoegd wordt, mag dat niet leiden tot de situatie dat oude software de code niet meer kan lezen, d.w.z. de codering moet backward compatibility mogelijk maken. 2. De verschillende veilingen moeten vrij zijn hun eigen keuzes te maken bij de selectie van de informatie die zij willen coderen. Dit mag er niet toe leiden dat er verschillende software-versies nodig zijn in een applicatie die veilingbrieven van verschillende veilingen moet kunnen scannen. 3. De alfanumerieke velden moeten de volledige UNOA karakterset ondersteunen. 4. Er moet gewoekerd worden met de ruimte in de code. Daarom moet er een efficiënte codering gebruikt worden, zodat er een zo groot mogelijke hoeveelheid informatie in zo weinig mogelijk bits kan. 5. De oplossing moet relatief eenvoudig te implementeren zijn. Uiteraard leiden de criteria 1 t/m 4 wel tot enige complexiteit in de implementatie. De verhoogde complexiteit loont echter de moeite, gezien de behaalde voordelen. Het voor mensen leesbaar coderen van de informatie, zodat het b.v. met behulp van algemene QR-code software op een mobiele telefoon te bekijken is, is geen criterium geweest. De informatie in de QR-code staat namelijk ook op de aanvoerbrief waar de QR-code op staat, en is daar veel leesbaarder dan b.v. een csv-bestand ooit kan zijn, zelfs als er een titelregel aan toegevoegd is. 3. Verantwoording gemaakte keuzes Uitgangspunt voor de keuzes voor de implementatie zijn de bovengenoemde ontwerpcriteria. Genoemde criteria geven nog geen aanwijzingen voor de keuze van de foutcorrectiesterkte, de selectie van de te coderen informatie, de versie van de QR-code, of de afmeting in millimeters op de aanvoerbrief. Deze keuzes worden door elke veiling afzonderlijk bepaald, en zijn terug te vinden in het document Specificaties QRCode_Velden 3

4 3.1 Flexibiliteit en toekomstbestendigheid (backward compatibiliteit) Compatibiliteit met oudere software dwingt er toe om kolomdefinities met tag (ID) en veldbreedte-informatie aan de QR-code toe te voegen. Dit heeft de volgende voordelen: 1) Als er een veld toegevoegd wordt, kan oude software dit veld eenvoudigweg overslaan. 2) Als er een veld vervalt, kan oude software dit detecteren, en de overige informatie gewoon verwerken. 3) Als er in de toekomst meer posities nodig zijn voor een veld (b.v. productcode, ordernummer), kan dit in de kolomdefinitie aangepast worden, en oude software kan de informatie toch probleemloos verwerken (er van uitgaande dat men intern met grotere maximale veldbreedtes gewerkt heeft). 3.2 Flexibiliteit voor de verschillende veilingen en andere gebruikers Elke veiling moet vrij zijn om zijn eigen selectie te maken uit de beschikbare informatie, zodat er optimaal gebruik gemaakt kan worden van de ruimte in de QR-code voor hún veilproces. Dit mag er niet toe leiden dat software die met QR-codes van verschillende veilingen om moet kunnen gaan complex en onbetrouwbaar wordt. De bij 3.1 genoemde kolomdefinities voorzien hier in. Zolang dezelfde tags gebruikt worden voor dezelfde informatie, zal het niet nodig zijn om veilingspecifieke implementies te maken. Als QR-codes op de veilingbrieven gemeengoed zijn geworden, zal er steeds meer gebruik van gemaakt worden voor logistieke processen, niet alleen door de veiling, maar ook door b.v. kopers en transporteurs. Mogelijk komen uit dit gebruik nieuwe wensen naar voren m.b.t. de informatie in de QR-code. De gekozen opzet maakt deze uitbreidingen eenvoudig mogelijk, zonder impact op bestaande applicaties. Het is wel handig om te zorgen voor voldoende reserve-ruimte in de QR-code voor deze toekomstige uitbreidingen. Met het oog op algemene bruikbaarheid, niet alleen door de veiling, zijn er enkele velden algemeen verplicht gemaakt. Het gaat hier om velden waarvan wij verwachten dat alle veilingen die zullen willen coderen. 3.3 Efficiënte codering Fixed fields versus scheidingsteken Het scheiden van velden met een scheidingsteken heeft in zijn algemeenheid het voordeel dat, als de velden toevallig kort zijn, er minder data gecodeerd hoeft te worden. In het geval van een QR-code echter, moet er rekening gehouden worden met maximaal gevulde velden (worst case), en moet hier de keuze voor de versie van de QR-code op gebaseerd worden. Dat er minder data te coderen valt als de velden toevallig korter zijn, levert geen winst op, het datablok moet dan toch aangevuld worden met betekenisloze bits. Het optioneel coderen van velden als er toevallig ruimte over is, heeft niet veel zin, omdat een applicatie er nooit van uit kan gaan dat die extra gegevens beschikbaar zijn. Scheidingstekens kosten echter wel ruimte. Als scheidingstekens niet toegevoegd hoeven te worden (fixed fields), maakt dit de codering dus efficiënter Datamode Er moet één van de 4 in de QR-specificatie genoemde datamodes gekozen worden. Dit geldt dan voor alle data in de QR-code, en bepaalt direct het aantal bits per teken. Als we kijken naar de informatie die gecodeerd moet worden, valt op dat het, afhankelijk van het veld, numerieke óf alfanumerieke data betreft. Er kan dus niet standaard voor de numerieke (3.33 bit/teken) datamode gekozen worden. Bekijken we verder de mogelijke inhoud van de alfanumerieke velden, dan blijkt ook de alfanumerieke (5.5 bit/teken) datamode van de QR-code niet toereikend, omdat hier slechts een subset van de UNOA karakterset in past. Aangezien een kweker b.v. vrij is om een foto-id te kiezen, en een koper vrij moet zijn om zijn ordernummer te bepalen, zal dit in de praktijk problemen geven. De volgende mogelijkheid is bytes (8 bit/teken). Zouden we voor elk teken een byte gebruiken, dan zou dat een grote verspilling van bits betekenen. Het levert veel winst op om de datastroom zelf in bits te coderen, met een verschillende wijze van coderen voor numerieke velden en alfanumerieke velden. Dit heeft geleid tot ca. 3.3 bit/teken voor numerieke velden, en 6 bit/teken voor alfanumerieke velden. Of een veld boolean, numeriek of alfanumeriek is kan eenvoudig afgeleid worden uit de kolomdefinities. Dit kan gebeuren op een laag niveau in de software, de impact van het iets complexer coderen is dus zeer lokaal. 4

5 Klok/BB De oplossing met de kolomdefinities maakt het mogelijk om b.v. voor Klok en voor BB andere velden te selecteren voor codering in de QR-code. Het heeft b.v. voor klok geen zin om ruimte voor een ordernummer te reserveren. Voor BB zijn misschien andere velden weer minder interessant, omdat deze gegevens over het algemeen al in de computer bij de koper staan, er is namelijk al een bestelling aan vooraf gegaan. 3.4 Foutniveau Er zijn vier foutniveaus gedefiniëerd in de QR-specificatie. Welk van de vier niveau's voor een bepaalde toepassing het beste is, hangt af van het soort beschadigingen men kan verwachten, van laag naar hoog niveau: L: Als nauwelijks aantasting verwacht wordt. Hiermee bereikt men de hoogste opslagcapaciteit. M: Is de verwachting dat een bepaalde verstoring (omgevingsinvloed) de hele QR-code meestal in ruwweg dezelfde wijze zal aantasten, dan is M de beste keuze, omdat bij een gegeven afmeting van de QR code de blokjes groter zijn dan bij bij Q of H. Dit niveau M wordt in de ISO specificatie als standaard aangeduidt. Q: Is de verwachte aantasting meestal lokaal (b.v. een afgescheurde hoek), dan is dit niveau een goede keuze. H: Een goede keuze als de verwachte aantasting uitsluitend lokaal is. Onze inschatting is dat eventuele aantasting van de QR code op de aanvoerbrief zich niet zal beperken tot b.v. een hoek, maar meer op de hele code in zal werken. Daarom denken wij dat voor deze toepassing M de beste keuze is, met Q als tweede keus. 5

6 Appendix I: Algemene informatie QR-code De QR-code is een tweedimensionale barcode met een geïntegreerde foutcorrectie. De QR-code is vierkant en bestaat uit vierkante zwarte en witte blokjes (modules), het aantal in verticale richting is daarom gelijk aan het aantal in horizontale richting. Modules worden gebruikt voor: codering van databits, codering van de foutcorrectie, en het bouwen van patronen voor positiedetectie en uitlijning. Het benodigde aantal modules voor een bepaalde toepassing hangt af van de hoeveelheid databits die gecodeerd moet worden, en de gekozen sterkte van de foutcorrectie. Het benodigde aantal databits hangt weer af van de wijze van coderen van de informatie in databits. Rond de QR-code moet een hoeveelheid witruimte aanwezig zijn, van minimaal 4 modules breed. De fysieke afmetingen op papier liggen met de keuze van het aantal modules nog niet vast, aangezien de afmeting van een module (een zwart of wit blokje) nog vrij te kiezen is. Er zijn natuurlijk praktische grenzen die in acht genomen moeten worden, in verband met de leesbaarheid. 1 Versies Er zijn 40 verschillende versies voor de QR-code gespecificeerd. Met de keuze van de versie ligt het aantal modules vast. Als ook de sterkte van de foutcorrectie gekozen is, is ook de beschikbare hoeveelheid databits bekend. Versie 1: 21x21 modules (kleinste QR-code) Per Versie: +4 modules Versie 40: 177x177 modules (grootste QR-code) Dit is exclusief de witruimte (minimaal 4 modules breed) die rond de QR-code aanwezig moet zijn. 2 Foutcorrectie De foutcorrectie is een Reed-Solomon error correction algorithm, en er zijn 4 verschillende niveau's van deze foutcorrectie gespecificeerd. Tabel 1: Foutcorrectie niveau's Foutniveau Oppervlak benodigd voor foutcorrectie L ± 20% van symbool ± 7% M ± 37% van symbool ± 15% Q ± 55% van symbool ± 25% H ± 65% van symbool ± 30% Sterkte van het Foutherstel De sterkte van het foutherstel geeft aan hoeveel modules beschadigd mogen zijn, voordat de databits niet meer uit de QR-code terug te winnen zijn. Tabel 2: Maximaal aantal databits voor QR-code versie 40 bij de verschillende foutcorrecties Foutniveau Max bits L M Q H Het is duidelijk te zien dat bij een sterkere foutcorrectie het aantal databits fors afneemt. Bij een gegeven aantal te coderen databits, en een gegeven ruimte op het papier, zullen dan de modules veel kleiner worden, 6

7 wat tot gevolg heeft dat de kans op een groot aantal onleesbare modules weer veel groter wordt. Een sterkere foutcorrectie betekent dus niet automatisch dat de betrouwbaarheid van de QR-code groter wordt. In de ISO specificatie wordt niveau M als standaard aangeduid, dit is dus meestal de beste keuze. 3 Datamodes Voor het coderen van de data kan gekozen worden uit vier gestandaardiseerde datamodes: Numeriek, Alfanumeriek, 8-bit byte of Kanji. Door de datamode te kiezen ligt het aantal bits/teken vast. Tabel 3: Aantal bits per teken Numeriek Alfanumeriek 8-bit byte Kanji Bits/teken 3,3333 (10 bits per 3 tekens) 5,5 (11 bits per 2 tekens) 8 (8 bits per teken) 13 (13 bits per teken) Door de informatie uit tabel 2 (aantal databits bij code 40) te combineren met die van tabel 3 (aantal bits/teken), kan eenvoudig het aantal tekens dat in een QR-code van versie 40 opgeslagen kan worden voor de verschillende datamodes en foutcorrectiesterkte bepaald worden: Tabel 4: Maximaal aantal tekens bij QR-code versie 40 Foutlevel Numeriek Alfanumeriek 8-bit byte Kanji L M Q H Numeriek Numerieke mode codeert tekens van de decimale cijferset (0-9) (ASCII waarden 30h-39h) Hierbij worden 3 tekens samen in 10 bits gecodeerd. Alleen positieve gehele getallen en nul kunnen hiermee gecodeerd worden. 3.2 Alfanumeriek Alfanumerieke mode codeert tekens van een set van 45 tekens. De tekens die in deze set zitten zijn de decimale cijferset (0-9) (ASCII waarden 30h-39h), 26 hoofdletters (A-Z) (ASCII waarden 41h-5Ah) en 9 symbolen (<spatie>, $, %, *, +,,., /, :) (ASCII waarden 20h, 24h, 25h, 2Ah, 2Bh, 2Dh, 2Eh, 2F, 3A). Hierbij worden 2 tekens samen in 11 bits gecodeerd. Deze mode is vooral handig voor het coderen van URL's. Elk teken in de URL dat niet in de set zit, kan namelijke eenvoudig gecodeerd worden met het %-teken gevolgd door een numerieke ASCII-code bit byte 8-bit byte mode codeert de tekens van de 8-bit extended ASCII set (tekens 00h-FFh). Hierbij wordt 1 teken in 8 bits gecodeerd. Dit is de eenvoudigste manier om een blok binaire data in een QR-code te zetten. 3.4 Kanji Kanji mode codeert de tekens van de Kanji set (tekens 8140h-9FFCh + E040h-EBBFh). Hierbij wordt 1 teken in 13 bits gecodeerd. Vooral interessant voor het coderen van Japanse of Chinese tekens. 7