1

Diplomaterv

Dolgozat címe: Utazási jegyek vásárlása, ellenőrzése, 1D és 2D

vonalkód algoritmusok implementálása

Konzulensek neve: Tihanyi Attila, Dr. Takács György

Hallgató neve: Szilvássy Balázs

Pázmány Péter Katolikus Egyetem Információs Technológiai Kar Műszaki Informatika Szak

2009. november 10.

2

PÁZMÁNY PÉTER KATOLIKUS EGYETEM

INFORMÁCIÓS TECHNOLÓGIAI KAR

DIPLOMATERV-TÉMA BEJELENTÉS

Név: Szilvássy Balázs

Tagozat: nappali Szak: Műszaki Informatika

Témavezető neve: Dr. Takács György, Tihanyi Attila

A dolgozat címe:

Utazási jegyek vásárlása, ellenőrzése, 1D és 2D vonalkód

algoritmusok implementálása

A dolgozat témája:

Mérje fel és elemezze a napjainkban leggyakrabban használt vonalkód technikákat. Válassza

ki és implementálja egy mobiljegyes alkalmazás céljának megfelelő vonalkódtípust. Értékelje

a kamera alkalmasságát a felhasznált vonalkód szemszögéből, és osztályozza az esetleges

hibaforrási lehetőségeket (orientáció, perspektivikus torzítás, zaj stb.).

Az elkészített programot értékelje az irodalomban szokásos módon. Az értékelés

eredményeit vesse össze az irodalmi adatokkal a fontosabb paraméterek (felismerési arány,

robosztusság stb.) szempontjából.

Dolgozzon ki egy jegyvásárlásra, ellenőrzésre alkalmas vonalkód technikára alapuló

bemutató rendszert. A bemutató rendszeren igazolja a kidolgozott vonalkód algoritmusok

működőképességét, állapítsa meg, és dokumentálja azok felhasználhatóságának korlátait.

Mutassa be a kidolgozott minta megoldás üzleti alkalmazhatóságát, és annak korlátait.

3

A témavezetést vállalom:

....................................................

(a témavezető aláírása)

Kérem a diplomamunka témájának jóváhagyását.

Budapest, 200. …………….

....................................................

(a hallgató aláírása)

A diplomamunka-témát az Információs Technológiai Kar jóváhagyta.

Budapest, 200. ……………

......................................................

Nyékyné dr. Gaizler Judit

Dékán

A diplomatervet átvettem:

Budapest, 200…………………….

....................................................

(a témavezető aláírása)

4

Pázmány Péter Katolikus Egyetem

Információs Technológiai Kar

Tanulmányi Osztály

1083 Budapest, Práter u. 50/A Tel/Fax: 886-4700 E-mail:

tanulmanyio@itk.ppke.hu

Nyilatkozat a hallgatói konzultáció rendszeres

látogatásáról

Szilvássy Balázs hallgató (neptunkódja CPXSHK) témavezetője

bejelentem, hogy a diplomaterv

címe: Utazási jegyek vásárlása, ellenőrzése, 1D és 2D vonalkód

algoritmusok implementálása

a diplomavédés időszakára (a Diplomaterv beadási határidő: 2009.

december 15.)

várhatóan

elkészül nem készül el

Budapest, 200

A konzulens neve:…………………………………

___________________________

Konzulens aláírása

5

Nyilatkozat az önálló munkáról

Alulírott Szilvássy Balázs, a Pázmány Péter Katolikus Egyetem Információs

Technológiai Karának hallgatója kijelentem, hogy ezt a diplomatervet

meg nem engedett segítség nélkül, saját magam készítettem, és a

diplomamunkában csak a megadott forrásokat használtam fel. Minden

olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva

más forrásból átvettem, egyértelműen a forrás megadásával

megjelöltem. Ezt a Diplomamunkát más szakon még nem nyújtottam be.

6

Tartalomjegyzék

Diplomaterv ...........................................................................................................................1

DIPLOMATERV-TÉMA BEJELENTÉS ..........................................................................................2

Nyilatkozat a hallgatói konzultáció rendszeres látogatásáról ...................................................4

Nyilatkozat az önálló munkáról ...............................................................................................5

Tartalomjegyzék .....................................................................................................................6

Ábrajegyzék ............................................................................................................................8

Összefoglaló ......................................................................................................................... 10

Magyar nyelvű összefoglaló .............................................................................................. 10

Summary in English........................................................................................................... 12

Deutschsprachige Zusammenfassung................................................................................ 13

Bevezetés ............................................................................................................................. 15

A feladat értelmezése ....................................................................................................... 16

A tervezés célja ................................................................................................................. 17

A feladat indokoltsága ...................................................................................................... 17

A diplomaterv felépítésének rövid vázlata ........................................................................ 18

1. Vonalkódtechnika ............................................................................................................. 19

1.1. Előzmények................................................................................................................ 19

1.2. Vonalkód és más automatikus azonosítási eljárások ................................................... 20

1.3. A vonalkódok fejlődése a kezdetektől napjainkig ........................................................ 21

1.4. Felhasznált eszközök .................................................................................................. 22

2. Vonalkód összefoglaló ...................................................................................................... 24

2.1. Vonalkódtechnikai kifejezések definiálása .................................................................. 24

2.1.1. Az általános vonalkód felépítése.......................................................................... 26

2.1.2. Kereskedelmi és ipari kódok ................................................................................ 29

2.2. Egydimenziós numerikus és alfanumerikus vonalkódok .............................................. 30

2.2.1. UPC és EAN ......................................................................................................... 30

2.2.2. 2 of 5 vonalkódok ................................................................................................ 34

2.2.3. Szélesség-modulált vonalkódok ........................................................................... 35

2.2.4. Codabar vonalkódok............................................................................................ 35

2.2.5 Code 39 alfanumerikus ipari vonalkód .................................................................. 36

2.2.6. Code 128 alfanumerikus ipari kód ....................................................................... 36

2.3. Stacked barcodes ....................................................................................................... 37

7

2.4. Kutatásom összefoglaló eredményei .......................................................................... 38

2.4.1. Az egydimenziós kódolás elégtelensége .............................................................. 41

2.5. Kétdimenziós vonalkódok .......................................................................................... 42

2.5.1. Datamatrix .......................................................................................................... 44

3. A Datamatrix vonalkód, mint elektronikus jegy ................................................................. 52

3.1. A Datamatrixszal kapcsolatos nehézségek .................................................................. 52

3.2. Nyílt forráskódok ....................................................................................................... 52

3.3. Datamatrix szemben a QR kóddal............................................................................... 53

3.4. A datamatrix kód írása ............................................................................................... 55

3.5. A datamatrix kód olvasása.......................................................................................... 56

3.6. A datamatrixszal kapcsolatos kihívások ...................................................................... 57

3.7. Vonalkód olvasó, mint mobiltelefonos alkalmazás...................................................... 58

4. Képfeldolgozási eljárások, saját program létrejötte ........................................................... 62

4.1. A Google ZXing nevű projektben való szerepem ......................................................... 62

4.2. A feladat konkretizálása és előkészítése ..................................................................... 63

4.3. A keretrendszer és a tesztképek két fontos szereplője................................................ 63

4.4. Datamatrix kód megtalálása egy képen ...................................................................... 65

5. Elektronikus jegy-rendszer bevezetése egy kitalált cégnél ................................................. 72

5.1. A rendszer céljának leírása a megrendelő cég szemszögéből ...................................... 72

5.2. A rendszer funkcionális követelményei ...................................................................... 73

5.3. A rendszer nem-funkcionális követelményei .............................................................. 74

5.4. Szakterületi követelmények vázlata ........................................................................... 75

5.5. Egy használati eset forgatókönyvének felvázolása ...................................................... 75

5.6. Az elektronikus utazási jegy bevezetésének célja ....................................................... 76

5.7. Létrehozandó termékek, szolgáltatások és elvégzendő feladatok ............................... 77

5.8. A rendszer architekturális modellje ............................................................................ 78

5.9. A rendszer tesztelési tervei ........................................................................................ 81

5.10. Elektronikus jegykezelő rendszer egy gyakorlati megvalósítása ................................ 84

Összefoglalás ........................................................................................................................ 97

Köszönetnyilvánítás ............................................................................................................ 103

Irodalomjegyzék ................................................................................................................. 104

Mellékletek ........................................................................................................................ 106

8

Ábrajegyzék

1. ábra: Egydimenziós vonalkód 21

2. ábra: Kétdimenziós vonalkód 21 3. ábra: A vonalkódok fejlődése 22 4. ábra: Morse-kódtáblázat 25 5. ábra: Vonalkód összehasonlító táblázat 26 6. ábra: Általános vonalkód felépítése 26 7. ábra: Diszkrét kódolás 28 8. ábra: Folytonos kódolás 28 9. ábra: CODE 39 típusú, minta vonalkód 29 10. ábra: Vonalkódok sokszínűsége 30 11. ábra: UPC-A vonalkód 31 12. ábra: UPC-A vonalkód rendszerazonosítói 31 13. ábra: UPC-E vonalkód 32 14. ábra: EAN-13 vonalkód 32 15. ábra: EAN-8 vonalkód 33 16. ábra: UPC kiegészítő kódolás 33 17. ábra: Standard 2 of 5 vonalkód 34 18. ábra: Interleaved 2 of 5 vonalkód 34 19. ábra: Szélesség modulált vonalkód 35 20. ábra: Codebar vonalkód 35 21. ábra: Code 39 vonalkód 36 22. ábra: Ál-kétdimenziós vonalkód 37 23. ábra: Saját egydimenziós vonalkód író és olvasó programom 38 24. ábra: Saját egydimenziós vonalkód író/olvasó programom szkennelés közben 39 25. ábra: Saját egydimenziós vonalkód író és olvasó programom szótárfájlja 40 26. ábra: Kétdimenziós vonalkódok [11] 42-44 27. ábra: A kétdimenziós datamatrix vonalkód tulajdonságai 45-46 28. ábra: A kétdimenziós datamatrix vonalkód magas szintű kódolása 47 29. ábra: A datamatrix vonalkód diagonális menti bejárása 47 30. ábra: Információkódolás folyamatábrája 49 31. ábra: Információkódolási folyamatábra Datamatrix esetén 51 32. ábra: QR kód hibajavítási szint táblázat 53 33. ábra: QR kód és Datamatrix helyigényét összehasonlító táblázat 54 34. ábra: QR kód és Datamatrix méretbeli különbsége 54 35. ábra: Datamatrix vonalkódot író és elmentő alkalmazás 55 36. ábra: Google ZXing Java SE változata újrafordítva működés közben 56 37. ábra: KaywaReader, mobiltelefonos alkalmazás 58 38. ábra: Teszt-keretrendszerem kezelőfelülete 63 39. ábra: Teszt-keretrendszerem képmegjelenítője 64 40. ábra: Teszt-keretrendszerem clusterező algoritmusának végeredménye 64 41. ábra: Teszt-keretrendszerem befoglaló négyzet számítás utáni eredménye 65 42. ábra: Teszt-keretrendszerem eredményképei binearizálás után 66 43. ábra: Teszt-keretrendszerem eredményképei első iterációs rossz binearizálás után

66

44. ábra: Teszt-keretrendszerem eredményképei első iterációs jó binearizálás után 67 45. ábra: Teszt-keretrendszerem eredményképe szándékosan rosszul paraméterezett vonalkódkeresésre

67

9

46. ábra: Teszt-keretrendszerem eredményképe clusterezés után 68 47. ábra: Teszt-keretrendszerem véglegesnek tekinthető eredményei 68 48. ábra: Teszt-keretrendszerem egy alternatívája módosított él-kereséssel 69 49. ábra: Tesztképek a keretrendszeremhez 71 50. ábra: Nem-funkcionális követelmények és mérésük 74 51. ábra: Egy lehetséges használati eset UML diagram 76 52. ábra: Ellenőrzés folyamatának adatfolyam modellje 78 53. ábra: Adatfolyam modell az ellenőr napi kódlekérdezésének folyamatáról 78 54. ábra: Szerver oldali adatfolyam modell 78 55. ábra: Szerverre befutó igény adatfolyam modellje 79 56. ábra: Az elektronikus mobiljegyek rendszerének rétegezett architektúra modellje

79

57. ábra: Az ellenőr oldali alrendszerek UML diagramja 81 58. ábra: A szerver oldali alrendszerek UML diagramja 81 59. ábra: Tesztelési lépések folyamatábrája a rendszer fejlesztésekor 82 60. ábra: Az Androidos mobilalkalmazásomhoz használt teszt datamatrix 87 61. ábra: Datamatrix kapacitástáblázata a különböző formátumokra [28] 88 62. ábra: Külön futási szálon végrehajtott SMS jegy értelmezés 89 63. ábra: A tárolt SMS jegyek megjelenítése 90 64. ábra: A tárolt SMS jegyek megjelenítése kétdimenziós Datamatrix vonalkódként

90

65. ábra: Elektronikus jegy vásárlásának és ellenőrzésének folyamata 96

10

Összefoglaló

Magyar nyelvű összefoglaló

Magyarországon a nyugati országokkal ellentétben rossz tendencia, hogy a

tömegközlekedéssel utazók többsége még mindig bliccel. 1-2 éve figyelhető meg az a

kezdeményezés, mely hivatott ezen az állapoton változtatni. Szigorították az ellenőrzéseket a

főbb vonalak mentén, továbbá az esti járatokon is egyértelművé teszik, hogy nem a

szórakozóhelyek búcsúajándéka az ingyenes hazaút. Ezek a szigorítások bár mérsékelték a

közlekedési vállalatok veszteségességét, a cégek továbbra sem termelnek profitot, ezért

komoly állami támogatásra szorulnak, ami pedig az adófizető polgárok pénzéből történik.

Korunk technológiai vívmányait kihasználva ez a ráfordított összeg sokkal hatékonyabban is

felhasználhatóvá válna más szektorokban.

Egy szintén új keletű fogalom az úgynevezett „zöld gondolkodás”, mely arra próbálja

ösztönözni a cégeket, hogy a mindennapi rutinműveleteket sokkal környezettudatosabban

végezzék el. A korszerű technológiai invesztíciókkal a kezdeti, magasabb költségek ellenére is,

hosszútávon kifizetődőbbé válik a „zöld gondolkodás”.

Jelen szakdolgozat témája egy olyan rendszer kifejlesztése, mely követi a mai

trendeket, ügyelve a környezettudatosságra, a kornak megfelelő technológiai háttérrel

felvértezve igyekszik a papír alapú vásárlást 21. századibbá tenni, és utat nyitni az

elektronikus kereskedelem világába. A rendszer főbb aspektusai a már szinte mindenki által

elérhető elektronikus készülékekben rejlő lehetőségek kiaknázása, a papír alapú vásárlás

leváltása, egy új, lehetséges alternatíva felvázolása úgy, hogy a végeredmény hatékonyabb,

biztonságosabb és nyomon követhetőbb legyen.

Diplomamunkámban sorra veszem a napjainkban leggyakrabban használt egy- és

kétdimenziós vonalkódolási technikákat, példákkal illusztrálva ezek előnyeit és korlátait.

Bemutatom egy választott egydimenziós vonalkód implementálásának kétféle - általam

használt - megközelítését, majd levonva a következtetést, miszerint célunk eléréséhez ezek

nem elégségesek, haladok tovább a kétdimenziós kódolások irányába. Bemutatom az általam

preferált kétdimenziós Datamatrix vonalkódot, pozitív tulajdonságait, és az írásához,

olvasásához használt alkalmazásokat és eszközöket. A továbbiakban beszélek az általam

11

épített rendszer egyik fő komponenséről, a mobiltelefonról. Egy általam programozott

keretrendszerben vizsgálom tesztképeken a Datamatrix vonalkód felismerhetőségét általános

célú mobiltelefon minőségű kamerák használatával. Irodalmi kutatást végezve

összehasonlítom az általam írt kép detekciós algoritmusokat a piacon kapható szoftverek

képességeivel egy-két példát külön ki is emelve. Végső soron vázolom majd egy elektronikus

jegyek vásárlását kiszolgáló rendszer üzleti lehetőségeit és az általam implementált bemutató

jellegű változatát.

12

Summary in English

Unlike the other Western countries the tendency is pretty bad in Hungary when using

the public transportation since the majority is still playing hooky. Finally a couple of years ago

the system introduced an improvement of this situation. On the main lines they toughened

up checking of the tickets and now it is made sure that everyone is aware of the fact that the

usage of a night bus is not included in the clubs’ entrance fee. There is no such a thing as a

free ride home. These aggravations restrained some losses of the transportation corporate

but it is still not making any profit which is still based on the massive support from the state

which comes from taxes. Using the technologies we have today the amount of money could

be spent more efficiently and on more useful purposes.

There is another new idea. The so called “Thinking Green”, which encourages companies in

the idea that the daily routine duties should be done with more focus on the environment.

Also that with the recent technology based investments even if at the beginning it might be

more expensive in long-terms “Thinking Green” will be paid-off.

This thesis is about a system following today’s trend. Paying attention to the

environment, making the paper based shopping more XXI. Century-like, opening up to the

world of electronic commercialism. The system’s main aspects are the utilization of the

electronic devices which are available to almost everyone and the potential alternative of

relaying the paper based shopping to a more efficient, safer, and more traceable issue.

In my thesis I look at today’s most used one- and two-dimensional barcode

techniques showing their pros and cons. I demonstrate two approaches of the

implementation of an elected one-dimensional barcode, taking conclusions, which says that

to reach our goal these barcodes are not sufficient and I move towards the two-dimensional

barcodes. I exhibit a two-dimensional barcode I prefer, the so called Datamatrix, its positive

features, and applications that are needed to read and write it. Henceforward I talk about a

main component of a system I have built, about the cell phones, and about a framework I

have programmed. Furthermore how it tests Datamatrix barcode’s recognizability by a

common call phone’s camera. Using literary research I compare the image detection

algorithms - which I have invented - with the softwares available on the market, highlighting

a couple of examples. Finally I outline the business opportunities of a shopping system, using

electronic tickets, and an exhibitory version, which I implemented.

13

Deutschsprachige Zusammenfassung

Die Mehrheit der Benutzer der öffentlichen Verkehrsmitteln fährt schwarz, das heißt ohne

gültigen Fahrschein. Diese Tendenz ist in Ungarn im Gegensatz zu den westeuropäischen

Ländern noch immer steigend. Die Initiative zur Änderung dieser Situation ist seit ein paar

Jahren zu beobachten. Dabei wurde die Kontrolle bei den Hauptlinien verschärft, und es

wurde auch eindeutig klar gemacht, dass die kostenlose Fahrt in der Nacht kein

Gratisangebot der Vergnügungsstätten und Discos ist. Obwohl diese Verschärfungen einen

Teil des Defizits der Verkehrsunternehmen verringert haben, sind die Firmen noch immer

nicht gewinnbringend. Sie benötigen hohe staatliche Unterstützungen, die mit dem Geld der

Staatsbürger finanziert werden. Wenn wir die heutigen technischen Errungenschaften nutzen

würden, könnte man dieses Geld in anderen Bereichen viel wirksamer verwerten.

Der Begriff „Grünes Denken”, der auch ziemlich neu ist, versucht die Firmen dazu zu

bewegen, die alltäglichen Routineaufgaben viel umweltbewusster zu erledigen und die

neuen technischen Errungenschaften auch trotz der anfänglich höheren Kosten

zu nutzen, denn das „Grüne Denken” wird sich auf lange Sicht lohnen.

In dieser Diplomarbeit geht es um die Entwicklung eines Systems, das den neuen

Trends folgt, auf das Umweltbewusstsein achtet und versucht, aufgrund des technischen

Hintergrunds von heute, den Kaufprozess zu modernisieren und statt Millionen von

Papierblättern zu verwenden, eher die Möglichkeiten des 21. Jahrhundertes zu nutzen und

den Weg für die Welt des elektronischen Handels zu bereiten. Die wichtigsten Aspekte des

Systems sind die Nutzung der vielen Möglichkeiten aller bekannten elektronischen Geräte

und die Vorstellung einer möglichen Alternative zur Ablösung des auf Papier gründenden

Kaufprozesses, deren Endergebnis man besser auf die Spur folgen kann und deswegen viel

wirksamer und sicherer ist.

Ich nehme mir in meiner Diplomarbeit die am öftesten benutzten ein- und

zweidimensionalen Strichcodes der Reihe nach vor, und zeige dabei ihre Vor- und Nachteile

auf. Ich präsentiere zwei von mir verwendete Annäherungsweisen der Implementierung

eines gewählten eindimensionalen Barcodes. Danach komme ich zur Schlussfolgerung, dass

diese Methoden hinsichtlich unseres Ziels nicht befriedigend sind, und gehe weiter in die

Richtung der zweidimensionalen Barcodes. Im Folgenden gebe ich die von mir bevorzugte

zweidimensionale Datamatrix Strichcode, ihre positiven Eigenschaften und die beim

14

Schreiben und Lesen verwendeten Anwendungen und Mittel bekannt. Im Weiteren schreibe

ich über die Komponente des von mir geplanten Systems, über das Handy, und untersuche

die Erkennbarkeit der Datamatrix Barcode auf Testbildern in einem von mir programmierten

Rahmensystem mit Hilfe von Kameras mit Handyqualität. Ich vergleiche aufgrund literalischer

Forschungen die von mir vorgestellten Algorithmen zur Imagedetektion mit den Fähigkeiten

der ähnlichen Produkte auf dem Markt. Zum Schluss schildere ich die Geschäftsmöglichkeiten

eines Systems zum Verkauf elektronischer Tickets und die von mir erstellte Demovariante.

15

Bevezetés

A városi tömegközlekedés a modern nagyvárosok egyik legfontosabb infrastruktúrája.

Manapság egyre nagyobb az igény arra, hogy minél gyorsabban, minél hatékonyabban,

valamint minél kényelmesebben jussunk el A pontból B-be. Ez a városi tömegközlekedés fő

profilja, azaz megtervezi és összehangolja a létező infrastrukturális lehetőségeket. Ez

természetesen hatalmas kiadásokkal jár, melyek nem maradhatnak fedezet nélkül.

Világviszonylatban egyre inkább elterjedt trendnek mondható az, hogy a nagyvárosi

tömegközlekedés félig piaci alapokon áll, azaz állami támogatásban részesül, ugyanakkor a

fennmaradó hiányt jegyek, bérletek értékesítésével pótolja. Ezek megvásárlásával szerzik

meg az utasok a jogot arra, hogy használhassák a városi tömegközlekedés szolgáltatásait. A

jegyek, bérletek értékesítése a rendszer egyik kényelmi szempontokból sarkalatos eleme. Az

utasoknak sok esetben hosszú, kígyózó sorokat kell végigállnia, hogy meg tudjanak venni egy

a következő időszakra, vagy egy másik körzetre szóló bérletet/jegyet. Kényelmi

szempontokból indokolt az elektronikus jegyrendszer bevezetése. Így az utasoknak nem kell a

pénztárak előtti sorokban tölteniük értékes idejüket, csupán egy SMS segítségével

megválthatják utazási jegyüket vagy bérletüket.

Általánosságban kijelenthető, hogy manapság 1 főre 1-2 mobiltelefon jut Magyarországon,

azaz csak a tömegközlekedésben részt vevő személyek elenyésző része nem rendelkezik az

elektronikus jegyrendszer használatához szükséges feltételekkel. Ennek ellenére számukra is

óriási előnyökkel jár az új rendszer, mivel a bérletpénztárak előtti sorok hosszúsága

várhatóan nagymértékben csökkenni fog. Ennek köszönhetően az olyan forgalmas helyeken,

ahol több pénztárablak is működik, egyszerre kevesebb nyitva tartó ablak is elegendő lehet.

Ugyanakkor egy időszakos forgalomnövekedés esetén az összes pénztárablak működésbe

állítható, így jóval rugalmasabb lesz a kiszolgálás, és az időszakos nagy tömegek (pl.

sportesemény, nemzeti ünnep, egyéb tömegrendezvény) kiszolgálása is gördülékenyebb lesz.

Indirekt módon itt utalnék arra, hogy természetesen nem lehetne jelenleg csak úgy

megszüntetni a papír alapú jegyvásárlást, hiszen nem várható el egy embertől sem, hogy

polgári kötelessége legyen legalább egy mobiltelefon birtoklása és ennek készségszintű

használata.

16

A rendszer egy másik előnye, hogy nagyon nagy pontossággal képes az utazásra jogosulatlan

személyek kiszűrésére a multidiszciplináris ismereteket igénylő implementációnak és a már

más területeken kiválóan teljesítő titkosítási eljárásoknak köszönhetően. Hamisítani ezen

okok miatt szinte lehetetlen, pontosabban értelmetlen, hiszen időigényes munka egy ilyen

kód visszafejtése. Ha az ellenőrökön át is jutna valaki egy hamisított kóddal, a szerveroldali

megoldásom pillanatok alatt kiszúrja a potenciális veszélyt, és megváltoztatja a titkosítási

kódot, melyet így újból hosszas munkával fejthetne vissza a tettes, és esetleg használhatna

újabb egy napi utazásra. Ebből kifolyólag a bliccelők száma a bevezetést követően az azt

megelőző időszak töredékére fog visszaesni. Nem elhanyagolható tény továbbá az sem, hogy

az elektronikus rendszer elterjedése kiváltja a korábbi papír alapú megoldásokat, mellyel

plusz pont érhető el a környezetvédők szférájában. Az elektronikus úton történő vásárlás

feleslegessé teszi majd a hatalmas mennyiségben gyártott papír alapú jegyeket és bérleteket,

illetve ezek lejárta után további hulladéktól kíméljük meg a környezetünket, mely jelenleg

túlnyomó részben nem újrahasznált szemétként fejezi be pályafutását.

A feladat értelmezése

Feladatom tehát egy olyan rendszer kidolgozása, mely utazási jegyek vásárlását és

ellenőrzését segíti elő a napjainkban egyre divatosabbá váló vonalkód-technikák

alkalmazásával. Meg kell találnom, hogy mely vagy melyek azok a vonalkódok, amik a

legalkalmasabbnak tekinthetőek a kitűzött cél eléréséhez. Vizsgálnom kell, hogy elektronikus

jegyek vásárlását milyen eszközök használatával tudnám lehetővé tenni, illetve hogy ezeknek

mik az előnyeik és hátrányaik, továbbá, hogy valós rendszerként is megállnák-e a helyüket.

Ezen felül meg kell terveznem a vásárlói oldalt kiszolgáló részt, mely az egész rendszer lelkéül

szolgál majd. Egy fontos részét jelentené dolgozatomnak annak kidolgozása is, hogy

megfelelő biztonsági rendszert építsünk ki a digitális jegyek hamisításának

megakadályozására.

17

A tervezés célja

A rendszer tervének célja egy olyan kliens-szerver architektúra kidolgozása, melyben

a vásárlók elektronikus eszközök segítségével tudják megvásárolni a korábbi, papír alapú

utazási jegyeket. További fontos tervezési szempontnak minősíthető a vásárolt jegyek

korszerűbb ellenőrzése, nyilvántartása, mely mind a kiszolgáló szerver oldalon, mind utazási

jegyek ellenőrök által történő ellenőrzések formájában valósulna meg. Ezáltal a polgároknak

lehetőséget tudnánk kínálni egy környezettudatosabb és kényelmesebb vásárlási forma

asszimilálására. Az üzemeltető cég számára pedig egy olyan módszert jelentene ez, mellyel

közel nullára redukálható a jegyhamisítások száma vagy egyáltalán a hamisítás kísérlete. Ezen

felül komoly és pontos vásárlói statisztikák készítésére és kimutatására adna lehetőséget. A

tervezett rendszerrel nyomon követhetőek lennének - más adatok mellett – a legterheltebb

utazási pontok. Számszerű adatokkal, korrelációkat lehetne felfedni ezen pontok és a vásárlás

dátuma között (például sportesemények nagyfokú látogatottsága), továbbá havi és éves

összesítések is pillanatok alatt kinyerhetőek lennének.

A feladat indokoltsága

Egyre több vészjósló hírről lehet hallani, mely szerint Földünk erőforrásainak és

élőkörnyezetének észnélküli kiaknázása komoly következményekkel fog járni, melyeket már

gyerekeink, unokáink, és az utánuk következő generációk fognak megsínyleni. Egy apró

papírjegy ugyan mit tehet hozzá vagy vehet el, gondolhatná egy laikus ember. Többségünk

fejében fel sem merül, hogy egy papírjegy elkészítéséhez is legalább egy fát ki kell vágni. A

fából varázsszóra sem lesz papír, azt el kell szállítani a feldolgozóüzembe, mely jó esetben a

természet segítségével történik, amikor folyókon úsztatják le a kivágott fatönköket. A

benzinevő motoros fűrészek okozta károk után pedig az elszállítás is újabb fosszilis

üzemanyag használatával történik. Az üzem működése is energiához kötött, a fát fel kell

dolgozni, vegyi anyagokkal keverni, és előállítani a kész végterméket. Erre majd még

nyomtatunk, majd méretre vágjuk és a felhasználási területekre kiszállítjuk. Mind-mind

energiaigényes műveletek sorozata. Ki gondolná, hogy egy utazási jegy ilyen hosszú utat jár

be, míg a zsebünkbe kerül?! Ha nem is váltjuk meg egy elektronikus rendszer kifejlesztésével

a világot, indirekt módon talán akkor is sokat könnyíthetünk a természet igénybevételén.

18

Egy másik hasonlóan fontos érv is áll még a kidolgozandó rendszer megvalósítása mellett.

Nevezetesen, hogy az utaztatás költségei kézben tarthatóbbak és nyomon követhetőbbek

legyenek. Szükséges, hogy az államnak pontos rálátása legyen az állapotokra. Egy

elektronikus utazási rendszer bevezetésével digitálisan archiválhatóak és elemezhetőek

lennének az adatok, tervezni lehetne a költségekkel, a fejlesztésekkel, és sokkal figyelemmel

kísérhetőbbé és elszámoltathatóbbá válna a tömegközlekedést kiszolgáló rendszer.

A diplomaterv felépítésének rövid vázlata

Diplomamunkámban végigveszem a manapság használt fontosabb egy- és

kétdimenziós vonalkódokat, írok ezek előnyeiről és hátrányairól. Bemutatom egy általam

választott - a mai napig használatban lévő - egydimenziós vonalkód olvasását és írását

lehetővé tévő program implementálását. Beszélek továbbá kétféle programozási

megközelítésről, melyeket az implementáláskor használtam. Ez után levonom a

következtetést, hogy az egydimenziós kódok használata vagy a kód tartalmának

korlátozottsága vagy a helyigénye miatt, számunkra nem alkalmas, ezért a kétdimenziós

kódolás irányába kell továbbhaladnunk. Bemutatom az általam preferált Datamatrix

vonalkódot, pozitív tulajdonságait, írásához és olvasásához használt alkalmazásokat és

eszközöket. Egy általam írt keretrendszerben vizsgálok majd általános minőségű

mobiltelefon kamerájával készített képekkel egyenértékű, Datamatrix kétdimenziós

vonalkódot tartalmazó tesztképeket. Majd bemutatom a hibaforrási lehetőségeket. Irodalmi

forrásokkal összevetve osztályozom az általam írt kép detekciós algoritmus használhatóságát.

Végső soron vázolom majd egy elektronikus jegyek vásárlását kiszolgáló rendszer üzleti

lehetőségeit és az általam implementált bemutató jellegű változatát, melynek alapjául egy

kliens-szerver architektúra szolgál, mely komoly biztonsági tényezők figyelembevételével

készült el.

19

1. Vonalkódtechnika

Napjainkban egyre nehezebb lépést tartani a rohanó világ tempójával. A

követelmények magasabbak, és az nyer, aki ezeknek eleget tud tenni. Polihisztorok már nem

léteznek, az emberiség tudása már oly szerteágazó és hatalmas, hogy egy ember ezt nem

lenne képes mind átlátni. Ennek következménye az is, hogy a számítástechnika fejlődésével

nemcsak a szoftver és a hardver vált szét, de külön specialisták foglalkoznak a hálózatokkal, a

multimédiával, és így van ez a vonalkódtechnikával is. Magyarországon több mint 20 éve

már, hogy az első vonalkódos szakcégek megjelentek. A magyar vonalkódos fejlesztések

szintúgy megtalálhatóak az APEH-nál, a könyvtárakban, gyógyszertárakban, a benzinkutaknál

vagy épp a legkülönbözőbb profilú iparvállalatoknál.

Az automatikus azonosítás, melynek a vonalkódtechnika, továbbá az optikai karakter-

felismerés, a rádiófrekvenciás azonosítás, mágnescsík-felismerés vagy a hangfelismerési

technika is része, több százmilliárd eurós piaci forgalmat tudhat magáénak. Ebből kifolyólag

érthető, hogy igény van az egyre korszerűbb és hatékonyabb megoldásokra.

A vonalkódtechnika és egyéb automatikus azonosítási technikák használta számtalan előnyt

hordoz magában. A korszerű informatikai rendszerekben, napjainkban, az egyetlen gyenge

láncszemet az ember testesíti meg, aki a számítógépet kezeli. Kutatások eredménye

bizonyítja, hogy az adatrögzítők átlag 300 karakterenként tévednek egyet hagyományos

adatbevitel esetén, amelyekből származó hibák jelentős része nem szűrhető ki

programokkal, de létrejöttük megelőzhető lett volna például vonalkódok alkalmazásával.

Továbbá az idő is egy nagyon fontos faktor, mely nem elhanyagolható tényező, akár

szolgáltatást nyújtunk, vagy éppen szeretnénk igénybe venni. Így a valós idejű robosztus

megoldásokra kell hangsúlyt fektetnünk.

1.1. Előzmények

Az évtizedekkel visszanyúló kezdeti kísérletezések és próbálgatások után az ’50-es,

illetve ’60-as évek elején jelentek meg az első gyakorlatilag is alkalmazható vonalkódolvasók,

és a mai szemmel már primitívnek tűnő vonalkódok. Az első alkalmazások szinte kivétel

nélkül válogató rendszerben történtek. A gyors fejlődés a ’70-es évek elején kezdődött és

20

napjainkig tart. Ugyanis ekkorra jutott a lézertechnika és a számítástechnika is olyan szintre,

hogy nagy tömegű adatot megbízhatóan és gyorsan volt képes felismerni, továbbítani és

feldolgozni.

Az első mozgósugaras lézer fényforrást használó szkenner még 60 kilógrammos volt, és

körülbelül 1973-ra tehető a piacra kerülésének időpontja [1]. Ez a szerkezet még diszkrét

logikával működött, amit aztán később a szoftver-vezérelt megoldások váltottak fel. A

mikroelektronika ugrásszerű fejlődése lehetővé tette „intelligens” hordozható olvasók és

terminálok kifejlesztését. Elérhetővé vált a számítógépekkel történő valós idejű

kommunikáció. A ’80-as évek elejére az egydimenziós vonalkódos technológia minden

tekintetben kiforrott. A technikai fejlődés azonban sohasem öncélú, hanem valós piaci

igények kiszolgálására alapul. A nagy tömegben előállított termékek áramlásának manuális

eszközökkel történő nyomon követése nagy élőmunka ráfordítást igényel, és ami még

hátrányosabb, hogy növekvő adatmennyiségek esetén az emberi tévesztések aránya

exponenciálisan nő. Így a folyamat nem állt meg, megszülettek az újabb vonalkód-típus

családok.

1.2. Vonalkód és más automatikus azonosítási eljárások

Automatikus azonosításnak azon eljárásokat és technológiákat nevezzük, melyek

lehetővé teszik, hogy emberi beavatkozás nélkül egy objektumról adatokat nyerjünk ki, és azt

további feldolgozásra alkalmas formára alakítsuk. Ide sorolandó többek között az

alakfelismerés, mágneses jelfelismerés, rádiófrekvenciás azonosítás és az optikai

jelfelismerés is. Az automatikus azonosítási eljárások közül mindegyiknek megvan a saját,

már jól kitaposott alkalmazási területe. Így például a hitelkártyák azonosítására a mágneses

felismerés szolgál, gépjárművek azonosítására pedig a rádiófrekvenciás megoldás terjedt

inkább el.

A vonalkódok (angolul: barcode) egy gépek által olvasható reprezentációi az információnak.

Általában fekete tintát használnak fehér háttéren, hogy az adatokat rögzítsük. Eredetileg a

vonalkódok a nevükből adódóan is paralel vonalakból álló információhordozók voltak,

melyek a váltakozó fehér és fekete vonalak szélességében kódolták az adatokat (1. ábra) [2].

Napjainkra persze ezek már kinőtték a dimenziójukat, és megjelentek újabb tagjaik, melyek

inkább hasonlítanak zajos, összepöttyözött fekete-fehér képekre (2. ábra).

21

A vonalkódok kiolvasásához általában optikai elven működő vonalkódolvasókat használnak,

de a mai csúcsteljesítményű számítógépekkel már könnyűszerrel megoldható, hogy a

digitalizált képből speciális képfeldolgozó szoftverekkel nyerjék ki az információt.

Valószínűleg észre sem vesszük, de valamennyi azonosítási eljárás közül talán a vonalkód-

technológia jelenik meg napjainkban a leginkább. Miért is van ez így? A kérdésre a választ

kezdetben a költséghatékony előállítás jelenthette, napjainkra pedig már olyan bejáratott

nemzetközi szabványok és megoldások állnak mögötte, melyek helyett igen nehéz lenne

bármi jobbal is előrukkolni. Nyomtatott adathordozó lévén, például a rádiófrekvenciás

megoldásokkal szemben, talán az egyik legolcsóbb automatikus azonosításra alkalmas

információhordozó. Egy tanulmány szerint vonalkódok implementálása napi szinten csupán

0,005 US$, míg a rádiófrekvenciás megoldás 0,07-0,30 US$ körül mozog [2]. Továbbá a

vonalkódok megvalósításának és a mai technológiai eszközöknek köszönhetően akár még

nagyobb távolságokból is biztonságosan olvasható. A mágneses eljárásokkal ellentétben nem

igényel közvetlen közelséget a leolvasásnál, hiszen optikai úton történik az egész folyamat.

Az optikai karakter-felismeréssel összehasonlítva pedig nyilvánvaló előnye, hogy kevésbé

sérülékeny, és egyes típusok esetén még nagyfokú rongálódás után is biztonságosan

kinyerhető az eredeti információ. Talán a rovásukra írható egyetlen hátrányuk, különösen az

1 dimenziós kódok esetén, hogy csak korlátozott adattartalom befogadását teszik lehetővé.

1.3. A vonalkódok fejlődése a kezdetektől napjainkig

Mint ahogy azt már korábban említettem, a legelső vonalkódos alkalmazások

osztályozó, válogató rendszerekben láttak napvilágot. Ezek zárt rendszerek voltak,

melyekben a vonalkódtípus és az eszközök kiválasztását külső szempontok nem motiválták.

Mint mindenhol, a zárt rendszeres megvalósítások a tömeges alkalmazhatóság természetes

korlátait képezik. Nem teszik ugyanis lehetővé például tulajdonosváltás esetén az előzőleg

vonalkóddal ellátott termékek azonosítását. A figyelem ezért már a kezdetektől fogva a

1. ábra: Egydimenziós vonalkód 2. ábra: Kétdimenziós vonalkód

22

kisebb-nagyobb mértékben nyitott rendszerekben alkalmazható vonalkódok és szabványok

felé fordult. Az első nagy lépés 1973-ban történt, mikor az USA-ban megalakult az UPC

(Uniform Products Code Council), és kiskereskedelmi alkalmazásokra elfogadta a róla

elnevezett vonalkódtípust [1].

Míg a tradicionális vonalkódokban korlátozott hosszúságban, csak numerikus adatokat

lehetett kódolni, az újabb szabványok már lehetővé tették karakterek implementálását is.

Egyesek csak az angol ABC nagybetűs elemeit, míg más vonalkódokkal a teljes ASCII

karakterkészlet kódolhatóvá vált. Az igény, hogy számokon kívül egyéb karaktereket is

vonalkódként tárolhassunk, illetve hogy azonosan kicsi felületre minél több adatot

zsúfolhassunk, továbbá hogy ezek információtartalma nagyfokú sérülés esetén is még

biztonságosan kinyerhető legyen, elvezetett a kétdimenziós mátrix kódokhoz (3. ábra). Az

első próbálkozások egydimenziós vonalkódok egymás alá pakolásával valósultak meg. Ezeket

angolul „stacked barcodes”-nak hívjuk. Később megjelentek ezek sokkal komplexebb formái

[11].

1.4. Felhasznált eszközök

Munkám során az algoritmusok implementálására kezdetben a Macromedia Flash 8

[16] – most már az Adobe terméke - fejlesztői környezetet, és Action Script 2.0-s [16]

szkriptnyelvet használtam. A későbbiekben Eclipse [32] fejlesztői környezetben folytattam a

feladatom és Java(1.4-es verzió) [18] nyelven kódoltam, hiszen a jövőben Symbian [17]

operációs rendszert futtató mobiltelefonokra terveztem átültetni az alkalmazásokat. Erre a

célra sokkal alkalmasabbnak találtam egy magas szintű nyelvet, mint a Java, mintsem egy

szkriptnyelvet. Mivel a két említett, modernebb 3GL-es nyelv (third-generation programming

language) szintaktikájában és szemantikájában is sok hasonlóságot mutat, így az

3. ábra: A vonalkódok fejlődése: (egydimenziós-, ál-kétdimenziós-, kétdimenziós-, dombornyomott vonalkód)

23

algoritmusok majd könnyebben konvertálhatóak át a Symbian-on futó C nyelv [17] számára

akár egy forráskód konvertáló program segítségével *20+.

Itt szeretném megjegyezni, hogy az általam használt két nyelv önmagában is alkalmas lenne

arra, hogy mobiltelefonon használják, de bizonyos korlátok miatt még sem ezekre esett a

választás az egydimenziós kódokkal való ismerkedés során. A Flash fejlesztői környezetnek

létezik egy Flash Lite [15] nevű változata, mely direkt mobiltelefonos alkalmazások

megírásához készült. A Flash futtatható fájljairól azt érdemes pár szóban megemlíteni, hogy

nagyon magas fokú az adattömörítése, azaz nagyméretű forráskódokból is kisméretű,

számára futtatható gépi kódot gyárt, továbbá hogy biztonsági rendszere hasonló a Java

„sandbox” modelljéhez, azaz, ha valamit szeretnénk, azt csak rajta keresztül tehetjük meg, és

ő majd eldönti, hogy jogunkban áll-e vagy sem. Ez utóbbit nevezzük virtuális gép

architektúrának, mikor a futtatható kód nem az alapul szolgáló operációs rendszer natív

hívásait használja, hanem egy virtuális gépben fut, ami értelmezi és végrehajtatja a kódot. A

virtuális gép architektúrát az „egyszer megír, több gépen futtat” igény szülte, mely annyit

jelent, hogy a programozónak nem kell minden platformra külön megírnia az alkalmazását,

hanem a virtuális gépeknek létezik több változata a különböző platformokra. Az egyetlen

probléma ezzel a megoldással csupán annyi volt, hogy Magyarországon - tudomásom szerint

- nem volt kapható olyan telefon, melynek szerves része lenne a Flash Player, mely ezt a

szükséges virtuális gépet testesíti meg, ami a futtatható kódot interpretálja és végrehajtatja

a mobiltelefon operációs rendszerével. Az interneten keresgélve főleg japán gyártmányú

mobiltelefonokon láttam ezt a kiszereltséget. (Ezen diplomadolgozat írásakor már kaphatóak

- többnyire Nokia márkájú - telefonok, melyek rendelkeznek ezzel a kiszereltséggel.)

A tiszta Java-s megvalósításnak pedig az állt útjában a kezdetekkor, hogy a különböző

mobiltelefonok különböző mértékben támogatták/támogatják a Java nyelvet, és nem lett

volna biztos, hogy az egyik telefonhoz megírt kód, más hasonló telefonon is futott volna.

24

2. Vonalkód összefoglaló

A vonalkódok megjelenésének és elterjedésének kezdete nem a matematikai

apparátus hiányában volt viszonylag késői, sokkal inkább az olvasáshoz és nyomtatáshoz

szükséges eszközökkel hozható összefüggésbe. Ezek elemi felbontása, érzékenysége,

hibatűrése és fizikai mérete jelentősen hatottak a kódolható adatmennyiség

meghatározásában. A lézertechnika fejlődése, amely lehetővé tette a kisebb méretek

melletti nagyobb megbízhatóságot, sem hozott nagyságrendi változást az így feldolgozható

információ méretében, ezért a fejlesztések a vonalkódok új típusainak kifejlesztése felé

folytatódott.

A különböző cégeknél indult fejlesztésekből mintegy harminc-negyven különböző

vonalkódtípus született, amelyek közül azonban csak egy tucatnyi vált elterjedtté, illetve

szabvánnyá, pontosabban többségében szabvány értékű ajánlássá.

A szabványosítást végző szervezetek illetve rendszerek közül a legfontosabbak:

- AIM, Automatic Identification Manufacturers Inc., AIM-Europe

- ANSI, American National Standard Institute

- CEN, European Standard Commitee

- EAN, European Article Numbering Association,

- UCC, Uniform Code Council

- EDI, Electronic Data Interchange,(EDIFACT,ODETTE,TRADACOMS stb.)

2.1. Vonalkódtechnikai kifejezések definiálása

A vonalkódok ősének sokan a Morse kódot tekintik (4. ábra), melyben az angol abc és

a számjegyek szerepelnek különböző hosszúságú jelek és a köztük lévő szünetek formájában.

25

Ezen szimbólumokból és a közéjük ékelt „szünetekből” építették fel a Morse üzeneteket [19].

Az említett jel, azaz az ábrán lévő egy fekete vagy fehér részegységet nevezzük elemi

információnak. Ez a digitális rendszerekben egy bitet jelent, vonalkódos nevén pedig

modulnak hívjuk.

Az egy dimenziós vonalkódok két lényeges pontban térnek el a Morse kódoktól. Az első az,

hogy a modulok közötti „szünet” nem egyszerűen a jelek elválasztására szolgál, hanem maga

a szünet-jel is információ értékű. Tehát a vonalkód sötét és világos modulok sorozatából áll.

Egy kódolandó karakter mindig rögzített számú modulból áll, és azon belül a sötét és világos

jelpárok száma is rögzített [1].

A továbbiakban a sötét modulokat az 1-es érték, a világos modulokat a 0-s érték jelenti majd.

A kódolás paramétereinek rögzítése egyben meghatározza a kódolható karakterek számát is,

hiszen meghatározott számú modulból csak meghatározott számú elempárt lehet véges és

könnyen kiszámítható módon kiválasztani. Illusztrálja ezt egy táblázat három vonalkódtípus

paramétereinek összehasonlításával (5. ábra) [1]:

4. ábra: Morse-kódtáblázat

26

Vonalkód

típus

Modul-mérete Jelpárok

száma

Kódolható

karakterszám

Felhasznált

karakterszám

Biztonsági

faktor

EAN/UPC 7 2 20 10 2.0

CODE 128 11 3 252 10 2.4

PDF 417 17 4 10480 2787 3.8

A biztonságos olvasás érdekében nem használják ki a teljes kódolható karaktermennyiséget,

hanem úgy választják ki a felhasznált karaktereket, hogy azok kódja a lehető legjobban

eltérjen egymástól. Így az apróbb nyomtatási hibák és az olvasási bizonytalanságok a

legkisebb valószínűséggel fognak karaktertévesztést eredményezni.

Minden vonalkódtípus egy általános elvrendszer szerint épül fel, ugyanakkor szinte

mindegyik megsérti az általános elvek legalább egyikét. (Ez a vonalkódok humán jellege [1].)

Saját irodalmi kutatásaimból összegyűjtött információk alapján azzal egészíteném még ki a

fentebb látható táblázatot, hogy interneten keresgélve sok pontatlan információval

szembesülhetünk. Talán a legcélszerűbb eljárás, amennyiben be akarunk törni a vonalkód

piacra, hogy mindig a specifikációt vesszük alapul, és szabványokra támaszkodunk.

2.1.1. Az általános vonalkód felépítése

A fentebb található ábrán az olvasás megkönnyítése érdekében lettek az egyes

részek indexszel ellátva a felső sorban (6. ábra). A vonalkódot általában a világos modulnak

megfelelő nagyobb háttérre nyomtatják, hogy az egész még jobban elkülöníthető legyen a

5. ábra: Vonalkód összehasonlító táblázat

6. ábra: Általános vonalkód felépítése

27

környezetétől. Ez a tiszta terület segíti az olvasókhoz kapcsolt dekódert a jelsorozat

kezdetének biztonságos felismerésében. Ezt hívják nyugalmi zónának.

Az 1-es és 15-ös indexen lévő részeket START és STOP karaktereknek hívják. Ez egy további

egyértelmű azonosító jelzés a kódolt adatterület meghatározásához. A START és STOP

karaktereket nem minden vonalkódtípus használja, de a legtöbb esetben legalább a nyitó

START karakter használatos. A kezdetet és a véget jelző START és STOP karakterek lehetnek

egyezőek vagy különbözőek is, sőt vannak olyan kódok, ahol magunk választhatjuk ki egy

karakterkészletből őket.

Vannak kódok, melyek a további biztonságos olvashatóságot megkönnyítendő még egy plusz

KÖZÉP karaktert is elhelyeznek. Ilyen a 8. indexen lévő résznél figyelhető meg. Van ahol ez

csak a vonalkód pontos kiolvasását segíti, de van ahol fontosabb elválasztó szerep is jutott a

számára, mint például a gyártóra és a termékre vonatkozó információ szeparálása.

A kódolt adatokat a START és a STOP karakterek között találhatjuk. Ezek hordozzák a

számunkra és nem a vonalkódolvasók számára fontos információkat. A kódolható adatok

hossza néhány típusnál rögzített, a többinél szabadon megválasztható, bár ez utóbbiaknál is

lehetnek bizonyos szabályok, mint például hogy csak páros számú karaktert használhatunk. A

kódolható adatok készletét minden esetben vonalkódtípusonként rögzített karaktertábla

tartalmazza. Egyes típusokkal csak számokat, másokkal már az angol ABC nagybetűit is, míg

ismét másokkal már a teljes ASCII karakterkészletet felhasználhatjuk.

A vonalkódban - általában a végén - szokott szerepelni egy további speciális karakter, az

ellenőrző karakter, amely egyszerűbb esetben a kódolt karakterek értékeiből, vagy a

karakterhez rendelt értékekből, aritmetikai számításokkal egy kiegészítő karaktert képez. Ez

beépül a vonalkódba, bizonyos esetekben a kódolt adatokhoz tartozóan. Visszaolvasásnál a

dekóderek is elvégzik a vonalkódtípushoz tartozó ellenőrző karakter kiszámítását, majd

összehasonlítják azzal az értékkel, amit a vonalkódban rögzítettek. Nem minden esetben

használják az ellenőrző karaktert, bizonyos esetekben pedig a felhasználó dönthet az

alkalmazásukról. Itt érdemes még említést tenni egy másik fontos kulcsszóról, az

önellenőrzésről (angolul self-checking), mely azt jelenti, hogy egy egyszerű nyomtatási vagy

szkennelési hibától egy karakter nem fog tudni egy másik karakterbe átkonvertálódni.

A vonalkód alatt található még egy számsorozat, az értelmező sor. Ez a kódolt adatok

megjelenítésére szolgáló, emberek számára meglévő kiegészítő információ, melynek

28

alkalmazása a vonalkód sérülése esetén lehet hasznos. Használata, elhelyezése, mérete és

formája többnyire rugalmasan kezelhető.

A vonalkódoknak szokott lenni még egy fontos rendszerjellemzője, az arányszám. Nevezzük

el az egymás melletti azonos értékeket, azaz 00 vagy 11 modulokat széles modulnak. Néhány

vonalkódtípusnál lehetőség nyílik arra, hogy a széles modul ne egyszerűen a modul

kétszerese legyen, hanem az arányszám által meghatározott. Az arányszámot mindig úgy kell

megadni, hogy a modulmérettel szorozva egész számot adjon, például 2:1, 7:3, 5:2, 3:1 stb.

Az arányszám alkalmazásával segíthetünk az esetleges, méretből adódó elhelyezési

problémák megoldásában. Az arányszám optimális és egyben maximális értéke 3:1.

Diszkrét kódolás alatt azt értjük, hogy a karakterek önmagukban is értelmezhetőek, nincs

szükség a többi kódra hozzájuk. Az ilyen kódolású karakterek általában vonallal kezdődnek és

fejeződnek is be, és a karakterek között karakter közötti szünetek találhatóak (7. ábra).

A folyamatos kódolás pedig éppen ennek az ellentettje, mikor a karakterek önmagukban

nem értelmezhetőek az előzőek tudta nélkül. Az ilyen kódolás végén általában egy termináló

karakter szokott állni (8. ábra).

7. ábra: Diszkrét kódolás

8. ábra: Folytonos kódolás

29

2.1.2. Kereskedelmi és ipari kódok

A kereskedelmi kódok, mint például az általunk is ismert élelmiszerüzletekben, a

termékeken látható vonalkódok. Ezek kiosztásáról nemzetközi szervezetek gondoskodnak.

Olyasmi ez, mint az interneten a domain nevek és az ezekhez tartozó aldomainek kiosztása. A

kereskedelmi vonalkódunk, ha nemzetközi szabványhoz igazodik, tartalmaznia kell egy

megjelölést, pontosabban egy rendszerazonosítót, továbbá a gyártó azonosítóját. Ezután

következik a termékkód, mellyel maga a termék azonosítható. Ezzel a módszerrel lehet

megoldani, hogy a termékek és gyártóik beazonosíthatóak legyenek. Az interneten keresve

olyan szervezetet, akik ezt a bejegyzést ingyen csinálják, nem találtam. Természetesen, mint

mindenhol, az adminisztrációs feladatokért fizetni kell. Magyarországon a Magyar Gazdasági

Kamara az illetékes szerv ez ügyben. Még egy fontos észrevétel a kereskedelmi kódokhoz az,

hogy ezek numerikus adatokat kódolnak. Formájuk a legtöbb esetben szigorúan rögzített,

hogy az azonosítás problémamentes legyen, viszont egyes kódtípusoknál egy speciális jelölő

karakter használatával fel lehet rúgni ezeket a szabályokat.

Az ipari kódokban lényegesebb különbség, hogy ezek már nem csupán numerikus, hanem az

abc karaktereinek kódolására is képesek. Természetesen más-más kód más-más mértékben

és hatékonysággal. Ezeket a kódokat alfanumerikus kódoknak nevezzük. Az ipari kódok

hossza általában szabadon választható. Az egydimenziós megvalósításoknál ezzel akár

nagyon vicces, átláthatatlan és használhatatlan, méteres vonalkódokat is gyárthatunk.

Itt van például egy CODE 39 vonalkód:

A fentebb látható CODE 39 típusú alfanumerikus vonalkódba a „HELLO VILAG BALU VAGYOK

MIZU VELETEK” karakterek sorozata lett bele kódolva egy ingyenes, nyílt forráskódú

programmal, melynek online változata innen érhető el (9. ábra):

http://www.terryburton.co.uk/barcodewriter/generator/

9. ábra: CODE 39 típusú, minta vonalkód

30

Egy másik példa a létező és használatos vonalkódok sokszínűségére (10. ábra):

2.2. Egydimenziós numerikus és alfanumerikus vonalkódok

Az alábbiakban összefoglalom a napjainkban használt, legfontosabb numerikus, azaz

csak számokat kódoló, illetve alfanumerikus, vagyis számokat és karaktereket is kódoló

vonalkódokat.

2.2.1. UPC és EAN

Az UPC talán az egyik legismertebb kódolási szabvány, legalább is az USA-ban. Ez az a

kód, amivel minden szupermarketekben találkozhatunk, de magazinokon, könyveken vagy

éppen újságokon is láthatunk. Az UPC-nek több formátuma van: UPC-A, UPC-E, UPC 2-

számos kiegészítése és az UPC 5-számos kiegészítése.

Az UPC-A 11 darab számot kódol. A 12. karakter egy ellenőrző karakter, melyet úgy

számítunk, hogy a páratlanodik indexen lévő értékeket összegezzük, majd vesszük a

10. ábra: Vonalkódok sokszínűsége

31

háromszorosát, majd ehhez hozzáadjuk a páros indexeken lévő számok összegét. Az

ellenőrzőszám az a legkisebb, pozitív egész szám, amelyet az előbb kiszámolt

végeredményhez adva, összegük tízzel történő osztása maradék nélkül végrehajtható. Egy

tipikus UPC-A vonalkód (11. ábra):

A kód alatt szerepel az emberi olvasást megkönnyítendő értelmező sor is. A legelső szám a

rendszerazonosítót jelöl, az utána következő 5 szám a gyártó kódja, a rákövetkező 5 a termék

kódja, a legutolsó pedig a generált ellenőrző szám. A rendszerazonosítók kiosztására az

alábbi táblázat szolgál alapul (12. ábra):

Rendszerazonosító szám Jelentés

0 Általános UPC kód

1 Fenntartott

2 Csomag

3 Gyógyszer

4 Saját belső kód

5 Kupon

6 Fenntartott

7 Általános UPC kód

8 Fenntartott

9 Fenntartott

Az UPC-E az UPC-A egy változata, ami egy sokkal tömörebb formátumot biztosít azáltal, hogy

a fölösleges extra nullákat eliminálja, továbbá hogy trükkösen az 5 hosszú gyártó kódból,

illetve az 5 hosszú termék kódból, egy 6 karakter hosszú kódot generál. Ezt a vonalkódtípust

általában olyankor használják, ha az UPC-A nem fér el a felhasználásra szánt felületen (13.

ábra).

11. ábra: UPC-A vonalkód

12. ábra: UPC-A vonalkód rendszerazonosítói

32

Az EAN-13 az UPC-A standardon alapul, mely szabványt az International Numbering

Association(EAN) in Europe fejlesztett ki. Ez a változat azért volt szükséges, mert az UPC-A

nem volt tökéletesen kitalálva nemzetközi használatra. Másrészt azért, mert az európaiak

nem szívlelték, hogy egy amerikai szabványügyi hivatal szerint működjenek. Az EAN-13 az

UPC-A egy kibővítése (14. ábra). Ebből kifolyólag, ami képes EAN-13 vonalkód olvasására, az

UPC-A kódot is probléma nélkül tud értelmezni. A két típus közötti egyetlen különbség, hogy

míg az UPC-A esetén egy 0-9 közötti intervallumból származó rendszerazonosítót használnak

csupán, addig EAN-13-nál ez egy 00-99-ig terjedő kétszámjegyű azonosító, ami valójában egy

országkódot jelent az esetek döntő többségében, de a korábbi UPC-A rendszerazonosítókra

is megvannak a neki megfelelő számok.

Az EAN-8 az UPC-E EAN megfelelője. Az EAN megfelelő alatt annyi értendő, hogy a korábban

említett rendszerazonosítást használja az egyszámjegyű helyett.

13. ábra: UPC-E vonalkód

14. ábra: EAN-13 vonalkód

33

A mellékelt ábrán látható, hogy az EAN-8 is egy rövidített formája az EAN-13-nak, továbbá az,

hogy az UPC-E-nél viszont egy picit hosszabb (15. ábra).

A JAN(Japanese Numbering Authority) kódok az EAN-13 japán megfelelői a 49-es

rendszerazonosítót használva.

Az UPC-A, UPC-E, EAN-13 és EAN-8 kódok mindegyike tartalmazhat a vonalkód jobb oldalán

egy plusz kiegészítő kódot. Ez általában nem olyan magas, mint az eredeti kód, és kiegészítő

információkat tartalmaz a termékkel kapcsolatban (16. ábra) [11].

15. ábra: EAN-8 vonalkód

16. ábra: UPC kiegészítő kódolás

34

2.2.2. 2 of 5 vonalkódok

A standard 2 of 5 vonalkód egy önellenőrző numerikus kód. Már az 1960-as évektől

használatosak. Annak a ténynek köszönhetően hívják 2 of 5-nek, hogy a numerikus

karakterek 5 modulból állnak, melyből kettő mindig széles modul. Az interleaved 2 of 5-tel

ellentétben itt az adat a vonalakba van kódolva, a vonalak szélessége tartalmazza az

információt, a szünetek fix hosszúságúak, és csupán a karakterek szeparálására szolgálnak

(17. ábra). A standard 2 of 5 kódot általában áruházi szortírozásnál, fényképelőhívásoknál

vagy repülőjegyeken használják [4]. Viszont mára már elavultnak számít, és az interleaved 2

of 5 használatát javasolják helyette.

Az industrial 2 of 5 a standard 2 of 5 egy másik elnevezése.

Az interleaved 2 of 5 a standard 2 of 5 ötletén alapszik azzal a különbséggel, hogy itt már a

szüneteknek nem csak szeparáló szerepe van, hanem szintén információ-hordozók. A kód

hossza szabadon választható, viszont csak páros számú számjegyeket tartalmazhat. Itt is

minden karakter 5 modulból áll, melyek közül 2 széles modul, és mindegyikük vagy csak

sötét, vagy csak világos. Ez úgy lehetséges, hogy az egyik karakter sötét moduljait a másik

karakter világos moduljai választják el egymástól. A kód karakterei tehát felváltva sötét és

világos modulokból állnak, páronként egymásba ékelve (18. ábra). A felhasználó dönthet

arról, hogy a kód tartalmazzon-e ellenőrző karaktert. Használatánál a párosság megtartására

ügyelni kell, amit gyakran az első karakterbe helyezett nullával oldanak meg.

17. ábra: Standard 2 of 5 vonalkód

18. ábra: Interleaved 2 of 5 vonalkód

35

2.2.3. Szélesség-modulált vonalkódok

Az MSI-t az MSI Data Corporation fejlesztette ki az eredeti Plessey kód alapján. Az

MSI-t szokás még Modified Plessey-nek is nevezni, melyet leltári tárgyak ellenőrzésénél

szoktak alkalmazni. Az MSI egy folytonos, nem önellenőrző kódolás. Bár ezen kódok hossza

tetszőleges lehet, a különböző alkalmazások általában különböző fix hosszúsággal használják.

A kód végére szokás egy moduló 10-es ellenőrző karaktert tenni. Minden karakter 8

modulból áll, 4 vonalból és 4 szünetből. Mint az eddig tárgyalt kódok is, ez is csupán

numerikus karaktereket tartalmazhat (19. ábra).

2.2.4. Codabar vonalkódok

A Codebar vonalkódokat 1972-ben találta fel Pitney Bowes. Ez egy diszkrét,

önellenőrző kódolás, ami 16 különböző numerikus és 4 fajta start/stop karakter tárolására

alkalmas. Ezt az azonosítást az amerikai vérbankok, fotólaborok és a FedEx légi számláin

használják. Mivel a kód önellenőrző, ezért nincsen semmilyen ellenőrző karakter a vonalkód

végére applikálva. Természetesen lehet úgy dönteni, hogy a nagyobb biztonság érdekében

szeretnénk egyet kreálni, ekkor viszont figyelnünk kell majd arra, hogy az ellenőrző karaktert

más vonalkód olvasók adatelemként fogják értelmezni.

Az A,B,C és D betűk a kódokban a 4 fajta, különböző START/STOP karaktert jelölik (20. ábra).

19. ábra: Szélesség modulált vonalkód

20. ábra: Codebar vonalkód

36

2.2.5 Code 39 alfanumerikus ipari vonalkód

A Code 39 volt a legelső alfanumerikus vonalkód (21. ábra). Még napjainkban is

használatos. Ez a standard vonalkódja az Egyesült Államok Védelmi Minisztériumának, illetve

az Egészségügyi Vonalkód Tanácsnak (HIBCC). A Code 39-et szokás még 3 of 9 kódnak vagy

USD-3-nak is nevezni.

A kód hossza szabadon választható. Fentebb már mutattam erre egy mókás példát, hogy

méteres vonalkódok is előállíthatóak vele. Egy karakter valójában 13 modulból áll, amiből az

utolsó 13. modul mindig a karaktereket elválasztó szünet, ezért nem is tekintjük a kód

részének. A fennmaradó 12 modulból 3 mindig széles modul, azaz két azonos 00 vagy 11

értéket tartalmaz. Ebből kifolyólag kezeljük úgy, mint egy 9 modulból álló kód, tudván, hogy

ebből 3 széles modul. Innen származik a neve is. A széles modulok megjelenítése a korábban

említett arányszám felhasználásával történik. Az ellenőrzőszám képzését a karakterekhez

rendelt értékek alapján számolhatjuk ki. A kódolás rögzített START és STOP karaktere a

karakterkészlet „*” (csillag) eleme, ezért nem tartozik érték az ellenőrzőszám képzéséhez. A

leképezhető karaktertábla a betűk közül csak az angol ABC nagy betűit tartalmazza. A kód

teljes ASCII kiterjesztéséhez alkalmazott megoldásban a $, /, % és + karaktereket a maradék

39 karakterrel párba rendezve azonosítjuk az első 128 ASCII karaktert.

2.2.6. Code 128 alfanumerikus ipari kód

A Code 128 sikerének oka a nagy sűrűség melletti nagy megbízhatóság a bőséges és

többféleképpen variálható karakterkészlettel. Az elnevezés az első 128 ASCII karakter

kódolhatóságából ered. A kód hossza itt is szintén szabadon választható. Egy karakter 11

modulból áll, a sötét és a világos modulpárok száma pedig három. Egy sötét vagy világos

21. ábra: Code 39 vonalkód

37

modulsorozat 1-4 közötti modulszámból épülhet fel. Három „A”, „B” és „C” jelzésekkel

megkülönböztetett típuskészlet létezik a takarékosabb kódolás érdekében. Ezek közül a B

jelű az alapvető, a másik kettővel csak számjegyeket kódolhatunk. A típus helyes kiválasztása

azért fontos, mert csupán numerikus adatok kódolása esetén sok helyet takaríthatunk meg,

szemben azzal a típuskészlettel, amikor betűket és számokat egyaránt kódolunk. Az „A” típus

jól alkalmazható az adatbevitel melletti szoftver vezérlésére is, hiszen a CR (Carrige Return),

LF (Line Feed), ESC és egyéb escape szekvenciák is kódolhatóak vele, míg a „C” típus

elsősorban a számsorok tömörítését segíti. A kód magába épít egy ellenőrző karaktert,

melyről a felhasználó nem szerez tudomást. Az ellenőrzőkarakter képzéséhez itt már a

kódolandó karakternek a karaktersorozatban elfoglalt sorszámát is figyelembe kell venni.

2.3. Stacked barcodes

A mikroelektronika fejlődésével egyre precízebb vonalkódolvasókat és -írókat

gyártottak, de ezzel még koránt sem sikerült megoldást nyújtani minden problémára. Voltak

olyan esetek, amikor sok információt kellett volna kinyomni kis felületre, viszont az 1

dimenziós vonalkódokkal ez nem volt kivitelezhető. A kezdeti próbálkozások az egydimenziós

vonalkódok egymás alá rendezésével történtek meg, mint például a Code 16k esetén. Ezek a

legelső „ál” kétdimenziós vonalkódok (22. ábra).

A Code 16k fizikai megjelenésében nagyon hasonlít a Code 49-re. A sorok száma 2 és 16

között változhat, és minden sor egyedi START és STOP karakterrel rendelkezik. Soronként 70

modulból áll, ami 5 karaktert tartalmaz. A sorokat egymástól és oldalról a nyugalmi zónától is

külön elválasztó vonal védi. A karakterek kódolása a Code 128 inverzeként történik. Több

ellenőrző karaktert tartalmaz, de soronkéntit nem. A vonalkód maximális kapacitása 77 ASCII

karakter vagy 154 számjegy.

22. ábra: Ál-kétdimenziós vonalkód

38

2.4. Kutatásom összefoglaló eredményei

Munkám során sikeresen elsajátítottam a vonalkódtechnika alapjait, olyan tudásra

tettem szert, melynek köszönhetően biztonsággal felismerem a legtöbb nemzetközileg is

használt egydimenziós és kétdimenziós datamatrix vonalkódtípust, és ismerem az ezek

mögött rejlő matematikai apparátusokat.

Leprogramoztam egy vonalkód író/olvasó keretrendszert Flashben, melybe tetszőleges

számú újabb kód implementálható a moduláris felépítésének köszönhetően. Ezen belül az

olvasásnál tovább realizálva a feladatomat a kapott információ elejére és végére random

hosszúságú 0-ást zajt raktam, ahogy ez a valós életben is előfordul a nyugalmi zónákat

illetően, és ezekből állítottam vissza az eredeti adatot olyan objektumba, melyből

lekérdezhető a vonalkód rendszerszáma, gyártószáma, termékkódja, és hogy az ellenőrző

karakter megfelelő-e.

23. ábra: Saját egydimenziós vonalkód író és olvasó programom

39

A fenti üzenetet generálta a programom, miután kiválasztottuk az UPC-A kódolási típust a

legördülő menüből majd beírtuk a tetszőleges, 11 hosszú számsorozatunkat (23. ábra). (A

programom validációt használ az input ellenőrzésére, és mivel tudja, hogy az UPC egy

numerikus kódolás, csak számokat enged beütni.)

Coding type changed for: UPC-A

Control Number created for: 12345678901 2

Code's binary representation:

000000000001010011001001001101111010100011011000101011110101010001001001000111010011

10010110011011011001010000000

A vonalkódra kattintás után elindul a szkennelés (24. ábra).

24. ábra: Saját egydimenziós vonalkód író és olvasó programom szkennelés közben

40

Majd a következő üzenet jelenik meg a kimeneti ablakban:

Code scanned and normalized,

random noises added at beginning and at the end.

Binary code:

000000000000101001100100100110111101010001101100010101111010101000100100100011101001

110010110011011011001010000000000

START + 1 23456 + MIDDLE + 78901 2 + STOP

Control Number passed. The code is valid.

System ID: 1 - Free digit

Manufacturer ID: 23456

Product ID: 78901

Control Number: 2

Ezt a framework-öt kétféle megközelítésből próbáltam bővíteni. A legelső változatban egy

külső szótárfájlból olvastattam be a vonalkód-típusra jellemző paramétereket, melynek

struktúráját én találtam ki (25. ábra). Az volt a célom vele, hogy minden típushoz legyen egy

szótárfájl, ami tartalmazza a vonalkód szempontjából fontos paramétereket, például a

számukra felhasználható karaktereket és az ezekhez hozzárendelt modulsorozatot, továbbá a

program írása és olvasása ettől teljesen független legyen.

25. ábra: Saját egydimenziós vonalkód író és olvasó programom szótárfájlja

41

A második megközelítésben úgy láttam jobbnak és hordozhatóbbnak a kódot, hogy a

kódtípusokhoz tartozó paramétereket is a programban tárolom, mindegyiket egy külön

objektumban, mert a szótárfájlos megoldásomnál rengeteg plusz munka volt az adatok

megfelelő „parse”-oltatásával, értelmezésével a programon belül. Ez utóbbi változatban

teljesen elkülönül a grafikus felület, továbbá az írás és az olvasás, maguktól a vonalkódoktól.

Írás esetén a vonalkód objektumoknak a framework átadja a kódolandó sztringet, majd az

objektum visszaad neki egy bináris, „0”-ás és „1”-es karakterekből álló sorozatot, ami már a

kódolt modulsorozatot tartalmazza. Erről semmi egyebet nem tud a keretrendszer, csak

annyit, hogy hogyan jelenítse meg. Olvasás esetén pedig egy ilyen bináris sorozatot adunk át

a vonalkódobjektumnak random hosszúságú „0”-ás zajjal az elején és a végén, majd az

objektum visszaadja a dekódolt adatot, illetve lekérdezhetőek tőle az egyes paraméterek

külön-külön is egy publikus interfacen keresztül.

2.4.1. Az egydimenziós kódolás elégtelensége

Ahogy láthattuk, az egydimenziós vonalkódok közül, azok, amelyek helyigénye

elfogadható lenne, csupán numerikus adatok kódolására alkalmasak. Az a néhány,

amelyekkel pedig alfanumerikus értékek is rögzíthetőek lennének, vagy csekély kapacitásúak,

vagy korlátlan adat rögzítése esetén hihetetlenül nagy méreteket öltenek, és ily módon

használhatatlanok komplexebb elektronikus rendszerekben. Az ál-kétdimenziós vonalkódok

sem hozták meg a kívánt sikert, ugyanis a kétdimenziós kódokkal szemben még mindig csak

egy barkácsmódszert jelentettek a problémák áthidalására. Természetesen mind az egy-

mind az ál-kétdimenziós vonalkódoknak megvan a saját, jól kitaposott felhasználási területe,

ahonnét a kétdimenziós vonalkódok a komplexitás és a migráció bonyolultsága miatt

valószínűleg sosem tudnák kiszorítani. De számunkra egy elektronikus jegy megvalósításánál

elsődleges szempont a minél kisebb méret, a gépek számára könnyű olvashatóság és a nagy

kapacitású, alfanumerikus és vezérlőkarakteres adattárolási lehetőség.

42

2.5. Kétdimenziós vonalkódok

Az egydimenziós vonalkódok egymás fölé rendezése nem bizonyult kellően nagy

denzitású kódolásnak. Még mindig igen korlátozott volt a mérete, és a hibavédelme sem volt

kellően magas. Így megjelentek az első valós kétdimenziós vonalkódok. Ezek mögött már

sokkal kigondoltabb és komplexebb matematikai apparátus működött. Több 100 vagy pár

ezer karakter kódolására is képesek egy kis felületen, ezen felül még a sérülésből fakadó

hibaarány is igen kis valószínűségű lett, amit a kódelméletből kölcsönzött hibajavító kódolási

eljárásoknak köszönhettek, mint például a Reed-Solomon kódolás.

Egy pár kétdimenziós vonalkód következzék most a változatosságuk reprezentálására a

teljesség igénye nélkül (26. ábra):

ArrayTag

Aztec Code

Code 1

CP Code

DataGlyphes

43

Datastrip Code

Dot Code A

MaxiCode

MiniCode

PDF 417

QR Code

Snowflake Code

44

Datamatrix

2.5.1. Datamatrix

A Datamatrix kétdimenziós vonalkódot a Siemens fejlesztette ki [13]. Az

ISO/IEC16022 specifikáció tartalmazza a Datamatrix leírását (27. ábra).

A Datamatrix egy 2 dimenziós vonalkód, ami körülbelül 1-2000 karakter tárolására alkalmas.

Ez a vonalkód négyzet alakú, és 0,001 inchtől egészen 14 inchig terjedhet az oldalankénti

mérete. Hogy a denzitását illusztráljam, 500 numerikus karakter egy 24-tűs nyomtatóval

kinyomtatva csupán 1 négyzet inchnyi területen is elfér.

A datamatrixot általában arra használják, hogy elektromos készülékek termék- és

szériainformációit kódolják velük. Japánban sebészi eszközök azonosítására is ezt

alkalmazzák. Továbbá lencsék identifikációjánál, áramköri nyáklapoknál és egyéb gyártás

folyamán keletkező termékek azonosítására használatosak még.

A datamatrixok olvasásához kétdimenziós szkennerre van szükségünk. Egyszerű lineáris

vonalkódolvasóval nem lehetséges az információ visszanyerése. Kétféle változata létezik

ezeknek a szkennereknek a piacon: lézeres és CCD kamerával működő. Ez utóbbira egy

nagyszerű példa a Japánban már évek óta használatos kétdimenziós, vonalkódos, személyi

információs lap, melyet a támogatott telefonok kamerájával lefényképezve, képfeldolgozási

eljárásokkal nyerhetjük ki az adatot belőle [5].

26. ábra: Kétdimenziós vonalkódok *11+

45

A kétdimenziós datamatrix vonalkód struktúrája és tulajdonságai

Egy 18x18-as, négyzetes datamatrix.

QUIT ZONE, az adatrégiót határoló külső

marker területe. Magyarul nyugalmi zóna.

Ennek a segítségével lehet behatárolni a

datamatrixszal kódolt adatrégiót.

A QUIT ZONE bal oldali és alsó része mindig

egybefüggő, azonos színű vonal. Ez alapján

fejjel lefelé lévő datamatrixról is biztosan meg

tudjuk mondani, hogy hogyan kell olvasni,

hiszen úgy kell csak rotálnunk, hogy a nyugalmi

zóna két egybefüggő marker vonala bal oldalt és

alul legyen.

A QUIT ZONE jobb oldali és felső része mindig

egy adategységnyi hosszú, váltakozó polaritású

rész. Az egységnyi hosszúság és szélesség segít

az adatcellák méretének meghatározásában,

továbbá perspektivikus torzítás esetén is

hasznunkra válhat az adatcellák méretének

pontos értelmezésében.

46

A datamatrix nyugalmi zónája által határolt

adatterület, a DATA AREA. Ez a rész

tartalmazza a kódolt információt.

Fehér alapon fekete polaritású datamatrix.

Fekete alapon fehér polaritású datamatrix. A

szabvány szerint a polaritás szabadon

változtatható, azaz, hogy fehér alapon feketével

kódolom az egyes cellákat vagy fordítva, de

általában az előbbit szokás használni.

Továbbá nem csupán négyzetes formája létezik

a datamatrixnak, hanem a szabvány szerint

engedélyezett a téglalap alakú is. Általában

nagyon hosszú kódolt információ esetén

találkozhatunk ezzel az esettel.

Egy adat datamatrix vonalkóddá való konvertálása két lépésben történik. Először az adatokat

8 bites kódszavakká alakítjuk egy kódtáblázat segítségével, ami az ASCII kódolási táblázat

minden értékéhez egy 8 bites reprezentációt rendel. Ezt hívjuk magas szintű kódolásnak.

27. ábra: A kétdimenziós datamatrix vonalkód tulajdonságai

47

Majd ezeket fekete-fehér négyzetekké alakítjuk. Ez utóbbi az alacsony szintű kódolás. A

kódszavakat úgy helyezzük el az adatterületen, hogy egy egyedi 45 fokos paralel, diagonális

vonal mentén helyezkednek majd el. Ahol szükséges, átlapolódás történik, hogy a négyzet

alakú adatterületre beférjen, melyet ezen diagonális vonalak mentén lehet végigjárni.

A lentebb található képen látható jelölés: X.Y, ahol X és Y természetes, egész számok, és X a

kódszót jelöli, azaz az aktuálisan kódolandó karaktert, Y pedig a kódszó bitjeit reprezentálja,

ami ugye 8 bites ábrázolás esetén egy 1-től 8-ig terjedő intervallumot ölel fel (28. ábra).

Ahogy fentebb már szó esett róla, a datamatrix kódszavait párhuzamos, diagonális vonalak

mentén helyezik el átlapolódások kíséretében, ezt szemlélteti a következő kép (29. ábra):

28. ábra: A kétdimenziós datamatrix vonalkód magas szintű kódolása

29. ábra: A datamatrix vonalkód diagonális menti bejárása

48

Mindezen felül még Reed-Solomon kódolást, az egyik leggyakrabban használt lineáris,

hibajavító kódoló osztályt is felhasználják, hogy a datamatrix a végleges formáját

elnyerhesse. Ez biztosítja, hogy a rosszul nyomtatott, törlődött, szemcsés vagy éppen

elszakadt kódokból is jó százalékkal visszaállítható legyen az eredeti adat. Ez a hibajavító kód

sokkal összetettebb, mint az egydimenziós kódoknál láthatott, paritásellenőrző bithez

hasonló eljárás. Ennek a kódnak polinomiális számításokon alapszik a hibajavító képessége,

de jelen dolgozatnak nem témája ennek ismertetése.

Még egy fontos dolgot meg kell említeni a datamatrix kódok kapcsán, még pedig, hogy

különböző módok léteznek az adatok kódolására, mint például a tisztán számadatos (DIGIT),

ASCII, vagy éppen tiszta szöveges (TEXT). Ennek lényege az, hogy minél kisebb elemszámú a

kód-abc-nk, annál takarékosabban és biztonságosabban tudjuk az információt kódolni. Az

egydimenziós vonalkódoknál jött elő az a fogalom, pontosabban igény, hogy

megakadályozzuk az átlapolódást. Ez annyit tesz, hogy ha megsérül egy adat, vagy rosszul

olvassa egy készülék, akkor vegye észre a hibát, és próbálja meg kijavítani annak érdekében,

hogy ne fordulhasson elő az, hogy egy hibás adat miatt egy értelmes, másik kódot kapunk.

Természetesen azoknál a kódoknál, ahol ellenőrző értéket is iktatnak, ennek nem sok a

valószínűsége, de mivel léteznek ellenőrző érték nélküliek, ezt egy példán keresztül

illusztrálom. Szemléltetésképpen nézzük a következőt (30. ábra):

Először is egy fogalom bevezetése, a kód-abc. Kód-abc-nek azon elemek halmazát értjük,

amelyekből a kódszavainkat összeálltjuk. Bináris jelek esetén a kód-abc a {0,1} halmaz.

És akkor a példa:

Egy biten szeretnénk tárolni binárisan adatokat

o Mivel bináris, ,0,1- a kód-abcnk. Azaz vagy 0-át vagy 1-et használhatunk csak.

o Mivel 1 biten szeretnénk tárolni adatot a lehetséges kódszavak

permutációja:

0 vagy 1, ez 2n-en lehetőség, azaz pontosan 21 = 2.

o Ez azt jelenti, hogy összesen két üzenetet tudunk csupán kódolni.

o „üzenet1”-nek feleltessük meg a „0” kódszót, „üzenet2”-nek pedig az „1”

kódszót.

o Van olyan rendszer, ahol elégséges csak két üzenet kódolása, de a

valóságban gyakran előfordul, hogy ez nem elegendő.

Ha például „üzenet3”-at szeretnék továbbítani, nincs rá lehetőség,

mert nem tudok kódszót hozzárendelni.

49

o A másik probléma az átlapolódás, azaz, ha egy zajos csatornán küldeném át a

kódszavamat, egy bitnyi hiba esetén „üzenet1”-ből már is „üzenet2” lett, és

ha ez egy ország bombázását elrendelő titkosított üzenet lenne, koránt sem

mindegy, hogy igen vagy nem a fogadó oldalon értelmezett, dekódolt

üzenet.

Az átlapolódás elkerülésének megértéséhez szükséges ismertetnem egy újabb fogalmat. A

kódelméletből ismert Hamming-távolság [27] alatt két azonos hosszúságú szöveges vagy

bináris jelsorozat eltérő bitjeinek, illetve karaktereinek a számát értjük.

Ez azt jelenti, hogy minél nagyobb a minimális Hamming-távolság a kódszavak között, annál

kisebb az átlapolódás fennállásának a veszélye. A fentebb bemutatott bináris, két kódszavas,

1 bites tárolásnál a Hamming-távolság mindössze 1. Ez volt az oka annak, hogy kis zaj esetén

is könnyen megeshet, hogy „üzenet1”-ből „üzenet2” lett. Leszögezhető tehát, hogy hatékony

kódoláshoz szükséges a kódszavak közötti minimális Hamming-távolság minél nagyobb

értékének elérése, amit úgy valósíthatunk meg, hogy kevés kódszót nagy bitpozícióbeli

eltéréssel használunk és/vagy több biten tároljuk. (Több bites tárolás esetén a helyigény is

megnő, aminek általában épp az ellenkezőjére van szükségünk.) A lényeg mindig ugyanaz,

hogy a felhasznált kódszavak bitpozícióbeli különbsége a lehető legnagyobb legyen. Minél

nagyobb a minimális Hamming-távolság a kódszavak között, annál nagyobb bithiba szükséges

ahhoz, hogy egyik kódszóból egy másikat kapjunk.

Üzenet: u Kódszó: c

u üzenet vektorhoz hozzárendelünk egy

szabad c kódszót, vagy generálunk egyet

zajos csatorna

c-t átküldjük a csatornán

Zaj: e e zajvektor hozzáadódik

Vett üzenet: v

a csatorna végén vett v vektor: v = c + e

Dekódolt üzenet: u’

hibajavított és dekódolt u’ üzent előállítása

30. ábra: Információkódolás folyamatábrája

50

Ahogy azt már fentebb írtam, hibajavító kódolásoknál beépített módszer van a hiba

fennállásának ellenőrzésére, illetve bizonyos számú bithiba javítására.

Datamatrix esetén a kód-abc-nk szintén bináris, hiszen csupán fekete vagy fehér cellákat áll

módunkban használni. Mivel a kódolni kívánt üzenetek elemi egységeire szánt tárolási méret

8 bitben kötött, a következőket mondhatjuk el:

28 = 256 kódszó áll rendelkezésünkre 00000000-tól egészen 11111111-ig.

Ez elegendő az ASCII táblázat elemeinek használatához, azaz minden elemhez tudunk

egy datamatrix kódszót rendelni.

Megállapíthatjuk, hogy mivel a lehetséges kódszavak közül mindet felhasználjuk, ha

az ASCII összes elemét kódolhatóvá szeretnénk tenni, 1 bitnyi hiba is átlapolódást

okozna, ezért mindenképpen szükségszerű hibajavító kódolás alkalmazása, ami jelen

esetben a Reed-Solomon hibajavító kód lesz, ugyanis a Datamatrix szabvány ezt

használja.

Továbbá azon is elgondolkodhatunk, hogy amennyiben a kódolt üzenetünkben nem

akarjuk felhasználni az ASCII tábla összes elemét, példának okáért tudjuk, hogy csak

számokat akarunk kódolni, amihez csupán 10 kódszó hozzárendelése elegendő, vagy

csak az angol ABC betűit akarjuk felhasználni, figyelmen kívül hagyva az ASCII

nyújtotta lehetőséget a vezérlési karakterek kiaknázására, nem kell az összes kódszót

lefoglalnunk. Az illusztráció végett maradva annál az eshetőségnél, mikor csupán

számokat kívánunk datamatrix kóddá konvertálni, látható, hogy a

{0,1,2,3,4,5,6,7,8,9- halmaz elemeihez elegendő lenne a 8 bites tárolás helyett

csupán 4 bit, hiszen 24=16 kódszó lehetséges felhasználásával implementálnánk ezt a

10 elemet. Ezen információ birtokában miért ne tehetnénk meg, hogy elhelyezek egy

jelzőkaraktert a datamatrix olvasójának, hogy csak számokat kódol az üzenetem, ami

annyit fog tenni, hogy egy normális 8 bites karakter helyén 2 darab 4 bites számot

fogok tárolni. Erre ad lehetőséget a Datamatrix szabvány különböző módú kódolása,

és így ugyanakkora területen sokkal több információt is képesek vagyunk kódolni, ha

tudjuk, pontosabban jelezzük, hogy nem kívánunk élni a teljes ASCII tábla

felhasználásának lehetőségével.

A vonalkódíró alkalmazásokba implementálható egy automata megoldás, mely megpróbálja

megkeresni a kódolandó szövegnek legmegfelelőbb formátumot, amennyiben ezt az

alkalmazandó vonalkód támogatja. Datamatrix esetén még arra is van lehetőség, hogy a

51

kódolási lépések között ugráljunk a kódolási módok között bizonyos speciális kódszavak

segítségével [3].

Egy datamatrix kód írása és olvasása a fenti folyamatábra alapján akkor a következőképpen

alakul (31. ábra):

ASCII üzenet „hello”

Kódolás A Datamatrix kódolási táblázata alapján hozzárendeljük az egyes karakterekhez

a nekik megfelelő bináris kódot.

h := 00100101 e := 01110111 l := 01101111 o := 10011100 (ezek csak kitalált értékek)

Reed-Solomon hibajavító kódolás alkalmazása vagy az adatblokkok végén, vagy nagyobb mátrixok esetén a cellák közé ékelve.

Datamatrix vonalkód megépítése az adatokból négyzetes vagy téglalap alakú formában.

Zajos csatorna miatt szennyeződés és sérülés keletkezhet a vonalkódon, ami folytán az olvasó egyes cellákat tévesen olvashat majd.

Képfeldolgozás QUIT ZONE alapján rotálás és térbeli transzformációk segítségével az adat zóna kiolvasása.

Datamatrix adat 0110110101 1000110110 1101100100 1010000000

stb.

Dekódolás és hibajavítás

ASCII vett üzenet „hello”

31. ábra: Információkódolási folyamatábra Datamatrix esetén

52

3. A Datamatrix vonalkód, mint elektronikus jegy

A korábbi fejezetben láthattuk, hogy okkal léptünk át az egydimenziós vonalkódok

felett, mikor az elektronikus jegyeinkhez keresünk egy hordozó médiumot. A kétdimenziós

kódok sokkal kisebb helyen sokkal több információt képesek tárolni. Szinte kivétel nélkül

mindegyik alkalmas ASCII elemek tárolására, továbbá a hibatűrő képességük is sokkal

megbízhatóbbá teszi őket. Így talán joggal kijelenthetjük, hogy jó úton haladunk az

elektronikus jegyünk formátumának rögzítése felé.

Mint az összes többi vonalkód esetében, a Datamatrix mellett is szólnak pro és kontra érvek.

De összehasonlítva a létező konkurenciával, elmondható róla, hogy az egyik legjobb hibatűrő

képességgel rendelkezik, a tárolható karakterek száma is az élmezőnybe emeli, és nem

lekicsinylendő az a tény sem, hogy egy jól bejáratott szabványról van szó.

3.1. A Datamatrixszal kapcsolatos nehézségek

Annak ellenére, hogy a Datamatrix egy nyílt szabvány, azaz ingyenesen

felhasználható, nem lehet találni ingyenes dokumentációt hozzá az interneten. Ezt nagyon jól

érzékelteti az a tény is, hogy bár a „datamatrix” kulcsszóra a Google kereső több mint másfél

millió találatot dobott ki, szinte majdnem minden oldalon más és más hibatűrési arányról

vagy épp kódolási kapacitásról beszélnek. Nagyon sok utánajárás és önálló munka szükséges

ahhoz, hogy valaki kiderítse, mik is a valós és pontos értékek.

3.2. Nyílt forráskódok

2008-ban vagy korábban, ha valaki fejébe vette, hogy szeretne implementálni egy

datamatrix írására és/vagy olvasására képes programot valamilyen tetszőleges programozási

nyelven, az vagy megvette az ehhez szükséges dokumentációkat, ISO szabványt, vagy idővel

szembesülnie kellett a sötétben tapogatózás nem kellemes érzésével.

53

Szerencsére ez a helyzet változott. Jelenleg több nyílt forráskódú rendszer is létezik már,

melyek szabadon letölthetőek és tanulmányozhatóak, illetve felhasználhatóak, és segítséget

nyújtanak képekből vonalkód adatainak kinyeréséhez. Bár ezek sajnos még mindig

gyerekcipőben járnak, és a „release notes”-ok szerint is még van rajtuk mit fejleszteni,

nagyon nagy segítséget nyújthatnak a munkánkban.

Két fontosabbat emelnék ki, melyekkel én is foglalkoztam:

- A „libdmtx” fantázianevű ingyenes projekt, mely talán jelenleg az egyik

legjobb szabadon felhasználható datamatrix vonalkód képből való kinyeréséhez

és értelmezéséhez, valamint ezen kétdimenziós kód írásához. Ez egy C-s

osztálykönyvtár, melyet jelenleg is fejlesztenek, és 2008. július végén készült el

egy újabb verzió belőle, ugyanis korábban egy ideig állt a projekt.

- A másik a Google által kezdeményezett ZXing fantázianevű Java csomag, melyen

szinte az összes fontosabb egydimenziós vonalkódot implementálták már, és a

kétdimenziós kódok közül is kész a QR kód, illetve a datamatrix részben. [23] A

dolgozatban tárgyalt későbbi munkám során én is ezt használom majd.

3.3. Datamatrix szemben a QR kóddal

A QR kód, azaz más néven Quick Respones kód szintén egy kétdimenziós vonalkód. A

három sarkán található három nagy marker-négyzetről ismerhető fel könnyen. A standard

szerint 21 * 21 modulból áll a legkisebb, míg 177 * 177-ből a legnagyobb QR kód. A Reed-

Solomon hibajavító kódolást alkalmazva 4 fajta hibajavítási szintet különböztet meg (32.

ábra) [24] :

Hibajavítási szint Maximum kódolható karakter

L (7%) 2953

M (15%) 2331

Q(25%) 1663

H(30%) 1273

A következő összehasonlító táblázat a QR és a Datamatrix vonalkódok helykihasználását

szemlélteti (33. ábra). A különböző sorokban ugyanazt a karakterláncot sokkal kisebb

32. ábra: QR kód hibajavítási szint táblázat

54

méretben lehetett datamatrixban kódolni. A negyedik csillagozott példában a karakterlánc

japán Kana karaktereket tartalmazott (a QR kódot eredetileg ilyen speciális, japán karakterek

effektív kódolására fejlesztették ki) *24+.

Ezen a két képen pedig már szemmel is jól látható a két kódolás eredménye (34. ábra).

Mindkettő a „http://google.com” karakterláncot kódolja.

Jól látható, hogy mindkét vonalkód hasonló megoldást használ az adatok tárolására, azaz

fekete-fehér cellák váltakozása rögzíti az információt valamilyen formában. A szembetűnő

különbség mindkét kód között a markerekben van. Míg a datamatrix kétdimenziós

vonalkódnál a marker mindig a legszélső, bal oldalt és alul egybefüggő, jobb oldalt és felül

fekete-fehér szaggatott, mindig páros hosszúságú vonal, a QuickResponse kódnál ezt a

szerepet a 3 fekete-fehér négyzet tölti be, mely a jobb alsó sarok kivételével mindegyik

csücsökben megtalálható. Ez utóbbi esetben is a negyedik csücsök kihagyása a

képfeldolgozást segíti, ugyanis így mindig ki lehet találni a kód pontos orientációját.

33. ábra: QR kód és Datamatrix helyigényét összehasonlító táblázat

34. ábra: QR kód és Datamatrix méretbeli különbsége

55

3.4. A datamatrix kód írása

A tesztjeim megkönnyítése érdekében, ahogy ezt már az egydimenziós kódoknál is

tettem, nem csak a datamatrix vonalkód olvasásával, hanem az írásával is sokat

foglalkoztam. Mivel szükségem volt tesztképekre, és 2008-ban még kevés, jó minőségű,

online fellehető, ingyenes, datamatrix kódot generáló program volt elérhető, módosítottam

egy Java alkalmazást, mely a begépelt szövegből és előre beállított paraméterekből

létrehozta a kétdimenziós datamatrix kódot, és felkínálta a lehetőséget ennek az

elmentésére (35. ábra). A program a dekódolt szöveg tartalmának megfelelő nevű jpg fájlt

ajánl fel elmentésre, de png és gif formátumú képfájlok támogatására is létrehoztam

segédosztályokat. Szeretném megemlíteni, hogy csupán a cél elérése érdekében,

haszonszerzés vágya nélkül használtam és bővítettem ki ezt az alkalmazást, hogy

tesztképeket tudjak generálni. Ily módon viszont sajnos nem áll módomban közéadni, mivel

nem rendelkezem a megfelelő jogokkal.

Terveztem még ennek a programnak a kibővítését különböző funkciókkal. Például a

zajgenerálással, hogy hibák keletkezzenek a vonalkódon, illetve a különböző térbeli

transzformációk használatával, hogy a valós képeket minél jobban tudjam szimulálni. De

mivel időközben egyre sűrűbben bukkantak fel az ingyenes datamatrix vonalkód generátorok

[12] [9], továbbá nem rendelkeztem a Datamatrix vonalkód szabványát leíró specifikációval,

hogy egy saját író és olvasó alkalmazást implementálhassak, letettem erről.

35. ábra: Datamatrix vonalkódot író és elmentő alkalmazás

56

3.5. A datamatrix kód olvasása

Jelenleg, a pár oldallal korábban már említett Google által kezdeményezett ZXing

nevű projekt kódját használom datamatrix vonalkód olvasásához (36. ábra) [23]. Ez a 2008-

as, akkori aktuális stádiumában még korántsem számított kész terméknek. Több

egydimenziós kód képről való olvasását implementálták már ebbe a Java csomagba, és a

kétdimenziós QR kódot is, de a datamatrix még mindig fejlesztés alatt áll. A kód egy kis

átalakításával sikerült „rávennem” a programot, hogy az egyszerűbb datamatrix képeket is

felismerje.

Első lépésben a program indulásakor rátallózhatunk egy vonalkódot tartalmazó képre, majd

a program az általa ismert vonalkód típusokat próbálja meg felismerni és dekódolni a képből.

36. ábra: Google ZXing Java SE változata újrafordítva működés közben

57

2008-ban a program részeként felismerhető vonalkódok a következők:

Egydimenziós:

o UPC-A

o UPC-E

o EAN_13

o EAN_8

o CODE_39

o CODE_128

Kétdimenziós:

o QR kód

o Datamatrix részben

Ez a program teljes egészében letölthető forráskóddal együtt Java SE (Java Standard Edition:

ezt használják desktop alkalmazásokhoz) és Java ME (Micro Edition: ezt használják

mobiltelefonos alkalmazások fejlesztéséhez) változatokban.

Legfrissebb tudomásom szerint a Datamatrix kód olvasását azóta sem implementálták, és

úgy tűnik, lehet, hogy nem is fogják.

3.6. A datamatrixszal kapcsolatos kihívások

Jelen állás szerint már létezik több szabadon felhasználható program, melyekkel

datamatrix kódot olvashatunk vagy éppen írhatunk. De ezek most még kisebb-nagyobb

hiányosságoktól szenvednek.

Főleg a képfeldolgozási algoritmusokon van még mit javítani, hiszen a valós életben szinte

biztos, hogy nem fogunk tudni olyan szép és tiszta vonalkódokat lefényképezni, mint

amilyeneket én itt most tisztán a kibővített programommal vagy más programmal

generáltam. A valóságban különböző fényviszonyok mellett, más-más szögből lefényképezett

vonalkódot, a mobiltelefon kamerájának kalibrációs paramétereinek ismerete nélkül, kell

tudnia az alkalmazásunknak, egy kódot detektálnia és értelmeznie minimális, a számára

rendelkezésre álló erőforrás felhasználásával.

58

3.7. Vonalkód olvasó, mint mobiltelefonos alkalmazás

Több, már létező piaci megoldás született a kétdimenziós vonalkódokban rejlő

lehetőségek kiaknázására.*25+ Szinte korlátlan a lehetőségek tárháza, ha arra gondolunk,

hogy nagyon kis helyen, ember számára olvashatatlan formátumban, viszont gép számára

könnyen értelmezhetően, nagy hibatűréssel, információt tudunk tárolni. Egy ilyen

megvalósítás a Japánban már évek óta sikeresen működő KaywaReader: *21+

Ennek sikere a robosztus alkalmazásban rejlik, mely letölthető közvetlen mobiltelefonra

WAP-on keresztül, és már futtatható is. De leszedhetjük a számítógépünkre is, és onnan

tetszőleges eszközzel töltjük át a mobiltelefonunkra, majd használjuk (37. ábra).

Ahhoz hogy egy ilyen mobiltelefonos alkalmazás sikeres legyen, több faktort figyelembe kell

vennünk. Egy ilyen fontos tényező véleményem szerint, hogy minél nagyobb lefedettséget

érjünk el mobilalkalmazásunkkal a telefonok között. Hogy a Java-s verziót említsem: a Google

által írt osztálykönyvtár akkor tud zökkenőmentesen működni, ha a mobiltelefonon futó Java

virtuális gépen megtalálható a MIDP 2.0-ás Java csomag. Ez az osztály felel a mobiltelefon

kamerájának Java-n keresztüli eléréséért. Viszont 2008-ban csak a legújabb modellekben volt

megtalálható. Sok ember számára megfelelő alternatíva az lenne, hogy a saját

mobiltelefonjaik alkalmazásával készítik el a képet, amit utána a vonalkód olvasóval

betallóznak, majd dekódolnak. Ezzel szinte már is lefedtünk minden kamerával rendelkező

mobiltelefont az alkalmazásunk számára, és valljuk meg, manapság már nem is nagyon

található olyan készülök, mely ne rendelkezne legalább egy darab, egyszerű, beépített

kamerával.

Érdemes további ajánlásokat figyelembe vennünk, ha azt szeretnénk, hogy mobiltelefonra

fejlesztett szoftverünknek jó visszhangja legyen *26+. Ezeket a javaslatokat négy fő csoportba

sorolhatjuk, melyek további kisebb alcsoportokra tagolódnak:

37. ábra: KaywaReader, mobiltelefonos alkalmazás

59

- Használhatóság

o Kisebb a képernyő mérete, mint egy normál PC-nek

Elimináljuk a felesleges UI(felhasználói interfész)

komponenseket.

Használjunk teljes képernyőméretet, ha lehetséges.

Gondosan tervezzük meg a felhasználói felületet.

o Nem férnek el a párbeszédablakok a képernyőn

Igyekezzünk kis méretű párbeszédablakokat alkalmazni.

o A vertikális- és horizontális orientáció változhat

Úgy tervezzük meg alkalmazásunkat, hogy mindkét orientációt

támogassák.

Használjunk teljes képernyőméretet.

Bizonyos alkalmazások megkövetelik, hogy csak az egyik

orientációt használják. Amennyiben a program funkcionalitása

ezt szükségessé teszi, ez is egy elfogadható megoldás.

o Nem elég nagy a képernyő, hogy megjelenítsük az adatokat

Használjunk görgetősávokat.

o A felhasználói felületen keresztül gyakran kérünk input-ot

Ahol lehet, használjuk a hardware-es gombokat.

o Véletlen aktiválás

A gomboknak elég nagynak kell lenniük mind ujjal való

használathoz, mind stylus-hoz.

Biztosítani kell lehetőséget arra, hogy a felhasználó bárhonnan

visszaléphessen az előző állapotba.

- Felhasználói felület és hardware limit

o A képernyő méret és a felbontás általában mindig más

Bizonyosodjunk meg róla, hogy a szövegek olvashatóak.

Készítsük fel termékünket a leggyakoribb méretekre.

o Bizonyos eszközök csak opcionálisak

Ne korlátozzuk a szövegbevitelt csak klaviatúrára.

Tegyük lehetővé programok telepítését többféle módon, mint

például web-ről vagy külső meghajtóról.

o A képernyő orientációja változhat

A képernyő rotációjához igazítsuk a felhasználói felületet, kivéve

ha ez a funkcionális működés miatt nem lehetséges.

60

o Jobb oldali klikkek, több gombos klikkek általában nehezen

kivitelezhetőek

Próbáljuk elkerülni a nehezen kivitelezhető gomblenyomásokat,

törekedjünk egyszerűségre.

- Korlátozott erőforrások figyelembe vétele

o Magas CPU utilizáció

Optimalizáljuk a feladatokat úgy, hogy a CPU mihamarabb

végezhessen, és visszaválthasson energiatakarékos üzemmódba.

Nagyfokú leterheltség esetén legyen lehetőség a részletesség

„lebutítására” például videó lejátszásnál.

o Az adattároló hardware használata

Puffereljük az adatokat, hogy minél kevesebb I/O műveletet

kelljen végrehajtanunk mind gyorsaság, mind a hardware

kímélése szempontjából.

o Optimalizált médialejátszás

- Kapcsolattartás

o Nem megbízható kapcsolat

Használjuk a rendszer eseményfigyelőit, hogy tisztában legyünk a

kapcsolat állapotával.

o Offline használat

Cache-eljük az adatokat.

o Adatvesztés, adatbiztonság

Használjunk biztonsági megoldásokat a kényes adatok

továbbítására.

Használjuk a lokális cache-t míg a szerver nem verifikálja magát.

o Szerver vagy web-service nem elérhető

Használjuk a lokális cache-t, és tekintsük kapcsolódási hibának,

míg el nem érhetőek.

o Szinkron kommunikáció

Használjunk aszinkron kommunikációt, hogy a válasz ne blokkolja

a futási szálat.

61

További ötletek, melyekkel egy vonalkódolvasó, mobiltelefonos alkalmazás értéke és

közkedveltsége talán nagyban növelhető:

Semacode-hoz hasonló kódok fejlesztése, melyekkel nem pusztán szöveges

információt dekódolhatunk, hanem belső utasításokat is adhatunk. Például kérjük a

böngészőt, hogy a dekódolt URL-t nyissa meg és töltse be. *22+ Rengeteg lehetőség

rejlik ebben, ha komolyabban belegondolunk, hiszen szinte korlátlan az elképzelések

tárháza. Egy komplett, új utasításnyelvet implementálhatunk, mellyel webcímet

tárolhatunk vonalkódban, és a mobiltelefon az adat értelmezése során, egy tag

alapján, azonnal megnyitja a címet egy böngészőben. Szintén egy másik utasítás-tag

arra lenne használható, hogy az utána lévő adatot a készülék névjegy adatként

kezelje, és azonnal hozzon létre egy új kontaktot belőle. Élelmiszereket ilyen

kódokkal felcímkézve, a mobiltelefonunk egy kattintásra receptötleteket jeleníthet

meg az adott termékkel kapcsolatban, vagy éppen megmutathatja számunkra a

vitamin és kalóriatáblázatát. Ezekből az illusztrációkból is látszik, hogy szinte

bármilyen területen felhasználhatóak lennének ezek a vonalkódok, létjogosultságuk

megkérdőjelezhetetlen.

Vonalkód kinyerésének lehetősége nem csupán videó folyamból (video stream),

hanem akciógomb lenyomására fényképezőből, vagy már korábban létrehozott és a

programba betallózott képből is lehetséges.

62

4. Képfeldolgozási eljárások, saját program létrejötte

Sikeresen eljutottunk odáig, hogy tudjuk, az elektronikus vásárlási rendszerünk

megvalósításához kétdimenziós vonalkódot akarunk használni, a nagy tárkapacitása, a magas

fokú hibatűrő képessége és a kis helyigénye miatt. Említettem, illetve be is mutattam általam

használt megoldásokat kétdimenziós datamatrix vonalkód írására és olvasására. Így

lehetőségünk nyílik tesztképek kreálására, illetve bizonyos szintig tesztképeken

végrehajtható vonalkódolvasási műveletek elvégzésére. Tisztáztuk, hogy mobiltelefonra

fejlesztett alkalmazásoknál sokkal korlátozottabbak a felhasználható erőforrások, így nem

lehet a tervezést egy górcső alá venni egy PC-kre szánt alkalmazásfejlesztéssel vagy éppen

egy web szerveren futóéval, más fajta megközelítésekkel kell élnünk.

Mindezen felül meg kell állapítanunk, ahhoz, hogy az elektronikus utazási jegyünk

ellenőrizhető is legyen, szükséges beleásnunk magunkat a képfeldolgozás színes világába, és

fel kell térképeznünk a lehetőségeinket.

4.1. A Google ZXing nevű projektben való szerepem

A ZXing a Google egy nyílt forráskódú tiszta Java-s fejlesztése Android alapú mobil

operációs rendszerekre, melyet bárki az Apache 2.0-ás licensz keretei között használhat.

Természetesen portolható az alkalmazás egyéb Java ME virtuális gépet futtató rendszerre is.

Ennek a licensznek a lényege röviden összefoglalva, hogy bárki felhasználhatja a kódot

ingyen és bérmentve, azzal a kikötéssel, hogy a módosított termékre is ugyan ezek a licensz

feltételek érvényesek. Még egy fontos pontja van, hogyha valami módosítást végzünk a

kódokon, fel kell tüntetnünk ezeket a változtatásokat is.

A ZXing projekt 2008. októberében még 0-ás verziószámmal futott. Egyik főbb hiányossága

volt, hogy a datamatrix kódok felismerése képekről, még korántsem volt tökéletes. (A

forráskódban ki is volt kommentezve az ehhez tartozó modul, belenyúlás nélkül nem

használható.) Legjobb tudomásom szerint jelenleg sem képes még valós, életszerű

helyzetben lefényképezett datamatrix kódot felismerni, és egyelőre nem is dolgoznak ennek

a modulnak fejlesztésén. Itt kerültem a képbe azáltal, hogy kifejeztem érdeklődésemet a

munkával kapcsolatban a Google egy fórumán, és az egyik felelős fejlesztő felvette velem a

kapcsolatot.

63

4.2. A feladat konkretizálása és előkészítése

Az én feladatom végső soron az lett, hogy próbáljak meg kifejleszteni olyan

algoritmust, mellyel nagy hatékonysággal lehet datamatrix képeket felismerni.

Több fizetős program próba verzióját is megvizsgáltam. Szándékosan megváltoztatott

tesztképekkel próbáltam felfedni gyenge pontjaikat, hogy végül egy olyan rendszert

alkothassak, mely nagyobb biztonsággal végzi a feladatát, mint ezek a piacon kapható

szoftvertermékek.

Ezután munkám kezdeti lépései voltak egy olyan keretrendszer megalkotása, melyben

grafikus felhasználói felületen(GUI) keresztül tölthetek be tetszőleges számú képet. Ezeken

több algoritmust ki is próbálhatok, majd a végeredményt megjeleníthetem és el is

menthetem. Természetesen szükségem volt ehhez még egy függvénykönyvtár

megalkotására, melyekkel a különböző képi transzformációkat tudtam könnyűszerrel,

bármilyen sorrendben végrehajtani. Ezen felül még gyártottam érvényes, saját datamatrix

kódokat a korábbi programommal, majd ezekből különböző verziójú tesztképeket

készítettem, melyek például perspektivikusan el vannak torzítva, vagy éppen meg vannak

forgatva. Továbbá más, az interneten fellelhető tesztképeket is felhasználtam a programom

hatékonyságának tesztelésére.

4.3. A keretrendszer és a tesztképek két fontos szereplője

A keretrendszerem három fő részből áll. Az egyik a program vezérléséért felelős

felhasználói felület. Itt lehet betölteni a képeket, algoritmusokat lefuttatni rá, illetve az

eredményeket kimenteni (38. ábra).

38. ábra: Teszt-keretrendszerem kezelőfelülete

64

A második rész a képek megjelenítésért felelős modul, mely minden számára átadott képet

tetszőleges feliratú új ablakban jelenít meg, és automatikus görgetősávval lát el, amennyiben

a kép nagyobb mint az ablak kerete (39. ábra).

A harmadik talán legfontosabb rész pedig egy statikus osztálykönyvtár létrehozása volt,

melyben közel 30 képfeldolgozási eljárást implementáltam, mint például a Laplace élkeresés,

binearizálás megadható küszöbértékkel, képek forgatása tetszőleges szögben, élesítés vagy

éppen elmosás, vagy akár a különböző Java-s képtípusok és mátrixok között konverziót

elvégző metódusok. Ezen felül még létrehoztam további olyan osztályokat, melyekkel a kép

pontjain tudok hatékonyabban dolgozni, clusterekbe rendezhetem őket, melyeket eltérő

színezéssel meg is jelenítek vagy éppen befoglaló négyzetet számíthatok rájuk (40-41. ábra).

39. ábra: Teszt-keretrendszerem képmegjelenítője

40. ábra: Teszt-keretrendszerem clusterező algoritmusának végeredménye

65

Szeretném akkor utólag bemutatni tesztképeim két fontos szereplőjét, a fentebb látható két

cicát, melyek az éjszakába nyúló programozások alkalmával is mindig mosolyt csaltak az

arcomra, és a hátteret is, melyre a továbbiakban majd részletesebben kitérek.

4.4. Datamatrix kód megtalálása egy képen

Az elgondolásom alapjául a datamatrix és szinte bármilyen egyéb vonalkód legfőbb

vonásai szolgáltak. Jellegzetesen fehér háttéren fekete vonalak vagy pöttyök váltakozása.

Ilyet egy képen lehetne keresni öntanuló vagy datamatrix mintázatú területen tanított

textúra szegmentációval. Vizsgálhatnánk a képen hol van nagy intenzitásváltozás, azaz sűrűn

előforduló fehérből-feketébe váltás vagy fordítva. De talán az egyik legegyszerűbb megoldás

a binearizálás. Ehhez egy saját függvényt írtam, melynek paraméterben átadható, hogy

milyen színértékek között színezzen valamit hasznos pixelnek, és milyenen ne (42. ábra) [31].

41. ábra: Teszt-keretrendszerem befoglaló négyzet számítás utáni eredménye

66

Erre azért van szükség, mert vannak olyan képek, ahol az ég, ajtófélfa vagy bármi más

fehérebb, mint a datamatrix nyugalmi zónája, vagy épp a háttérben álló macska ugyan olyan

fekete, mint a datamatrix sötét cellái. Ezzel a módszerrel iteratívan lehet változtatni az

értékeket, hogy a lehető legtöbb - számunkra – zajt kiszűrjük a képből, és akár már elsőre

csak a megfelelő ponthalmazt találjuk meg. Az alábbi képen (43. ábra) jól látható például,

hogy a korábbi paraméterekkel, az algoritmus binearizálás után semmi lényegi információt

nem talált, mivel a datamatrix fehér része valójában inkább szürke a fényviszonyok miatt, és

maga a flakon, amin szerepel, már az is világosabb, mint ő. Ezért van szükség az iteratívan

léptető színérték menti vágásra („thresholdolásra”) (44. ábra).

42. ábra: Teszt-keretrendszerem eredményképei binearizálás után

43. ábra: Teszt-keretrendszerem eredményképei első iterációs rossz binearizálás után

67

Egy másik szemléletes példa, ha a háttérben valami olyan fekete van, mint amilyen a

datamatrix adatainak jelölése. Az alábbi képen jól látható, hogy a cicának a mellkasa is

bekerült a datamatrix clusterébe, mivel színtartományban közel volt, továbbá mert a

távolságszámítás szerint is lehetne akár még a datamatrix adat-ponthalmaz része (45. ábra)

[30].

Ez utóbbi hibák kiküszöbölhetőek úgy, hogy a fekete pontokra binearizálunk [31], azaz arra,

ami a datamatrixban az adatot jelöli, viszont ugyan ezt megcsináljuk a fehér pontokra is, és

csak azon fekete pontokat vizsgáljuk, melyeket valami fehér zár közre. Így elkerülhető, hogy

a nyugalmi zónán kívül eső sötét pontot is adatpontnak vélje az algoritmus.

44. ábra: Teszt-keretrendszerem eredményképei első iterációs jó binearizálás után

45. ábra: Teszt-keretrendszerem eredményképe szándékosan rosszul paraméterezett

vonalkódkeresésre

68

Az egész eljárás lényege, hogy olyan sötét pontokat keresünk, melyeket fehér pontok zárnak

közre. Az ilyen fekete pontokon aztán végigjárunk, csoportokba zárjuk a pontokat, majd

további vizsgálatokat végzünk rajtuk, hogy tényleg datamatrix lehet-e a clusterezett

ponthalmaz (46. ábra).

Ezek után megkeresem a csoportosított ponthalmazok befoglaló polygonját, majd ezek

mentén kivágva a képrészletet vizsgálom meg, hogy valójában datamatrixot találtunk-e, vagy

az iteratív eljárással változtatni kellene a paramétereken, esetleg eljutottunk egy olyan

pontra, hogy túl régóta fut már a keresés, és valószínűleg nincs semmilyen vonalkód a képen.

Az alábbi két kép két különböző hátterű tesztképen mutatja a megtalált régiót (47. ábra).

46. ábra: Teszt-keretrendszerem eredményképe clusterezés után

47. ábra: Teszt-keretrendszerem véglegesnek tekinthető eredményei

69

Az algoritmus robosztussága tovább javítható a már korábban említett egyéb eljárások

használatával is, mint pl. az él-keresés vagy a textúra szegmentáció (48. ábra). Az előbbi

például azért lehet hasznos, mert tudjuk, hogy a datamatrix jobb oldalán és alul kötelező

jelleggel egy összefüggő sötét vonal található. Így ha a képet élesítjük, - mivel hogy a Laplace-

élkereső érzékeny a zajra [31] - majd egy magas értékkel thresholdoljuk és végül lefuttatjuk

rajta az él-keresést, bizonyos képeken hasznos plusz információhoz juthatunk.

Ezen a fent látható képen (48. ábra) ott jelentkezik a probléma, hogy a háttérben látható ajtó

mintázata is tartalmaz olyan egybefüggő vonalakat, mely akár datamatrix határoló

szimbólum is lehetne.

Összegezve az eredményeket, azt lehet elmondani, hogy Datamatrix vonalkód megtalálása

egy képen, koránt sem triviális feladat, és többféle járható út is kínálkozik. Az egyik legjobb

megoldást úgy érhetjük el, ha a különböző megközelítéseket mind felhasználjuk az eredmény

pontosításához. A három fő tényező, amiből én kiindultam, hogy életszerű képeken is

megtaláljam a datamatrixot, a következőek:

A datamatrix fehér és fekete cellákból épül fel.

o Alulátersztő szűrő alkalmazásával, jól beállított csúcsérték mellett

megtalálhatjuk a vonalkód összes fekete celláját, plusz rossz esetben még

némi zajt is a háttérből.

48. ábra: Teszt-keretrendszerem egy alternatívája módosított él-kereséssel

70

o Felüláteresztő szűrő alkalmazásával és jól beállított csúcsérték mellett

megtalálhatjuk a vonalkód összes fehér celláját, plusz szintén némi zajt a

háttérből, ha nem volt szerencsénk.

o Az alul- és felüláteresztő szűrők eredményeinek uniója tartalmazza majd a

vonalkódunkat, és némi zajt a háttérből [30].

o Ha nem csak egy csúcsérték alatt és felett vizsgálódunk, hanem két

csúcsérték között, akkor iteratívan végig tudunk menni a színskálán rekurzív

hívásokkal, és sokkal pontosabban ki tudjuk szűrni a háttérzajt, a legtöbb

esetben szinte teljesen el is tüntetve azt. Ehhez persze vagy tisztában kéne

lennünk a megfelelő színtartományokkal, ahol keresnünk kell, vagy minden

iterációnak meg kell próbálnia utolsó lépésként a vonalkód felismerést, és ha

nem sikerül, lépteti tovább a ciklust, illetve bizonyos idő elteltével akár

terminálhatja is magát.

A datamatrixnak a bal oldali és az alsó határoló cellája egybefüggő vonal, így

élkereséssel felfedezhető. Természetesen ez esetben is számolni kell a háttérből

eredő, hozzárakodó zajokkal.

A vonalkódoknak nagy az intenzitásváltozása, ergo olyan területet kell keresnünk a

képen, ahol kis részeket vizsgálva is sok a világos és sötét pixelek váltakozása.

Még egy használható információ, hogy tudjuk, a vonalkódot nyugalmi zóna veszi

körül, ami általában annyit takar, hogy a sötét polaritású vonalkódot fehér háttérre

nyomtatták.

Ezek az általam vázolt megoldások természetesen nem csupán datamatrix vonalkód

észlelésére lehetnek alkalmasak, hanem bármely vonalkódéra, mely a következő

tulajdonságok valamelyikével vagy mindegyikével rendelkezik:

Sötét és világos színekből épül fel.

Élek találhatóak benne.

Nagy az intenzitásváltozás (sötét és világos színek váltakozása).

Nyugalmi zóna veszi körül a vonalkódot, ami elüt a háttértől.

Olyan elektronikus eszközökön, ahol emberi beavatkozás is feltételezhető, mint például a

mobiltelefon, nagyban egyszerűsíthető az algoritmus egy olyan megoldással, hogy a kamera

által megjelenített képre egy célkeresztet teszünk, és a vonalkód sikeres megtalálásának

feltétele, hogy a célkereszt a vonalkód felett legyen a keresés elindításakor. Így rögtön meg

tudjuk állapítani a világos és sötét színek tartományát, hiszen a célkereszt közvetlen

71

közelében lévő pixelekről beszélünk. Egy másik alternatíva lehet a kamera képén egy

befoglaló négyszög megjelenítése, és a vonalkódnak ebben a négyszögben kell minél

pontosabban elhelyezkednie.

Tovább egyszerűsíthető a detektálás korlátozott erőforrásokkal rendelkező képeken, ha

kifejezetten meghatározzuk, hogy milyen vonalkódot keressen a program, ne neki kelljen

kitalálnia az összes lehetőség végigpróbálgatásával.

A képfeldolgozást taglaló alfejezetben végezetül szeretném még bemutatni az általam kreált,

eredeti tesztképeket, melyek mindegyike a valós szituációk egy vagy több különböző

eshetőségét igyekezett lefedni (49. ábra).

Eredeti „Balu vagyok” üzenetet kódoló kép.

Az eredet kép síkban megforgatva 90 fokkal.

Perspektivikusan torzított eredeti kép.

Hullámos felületre elhelyezett és megforgatott

kép.

Térben nyújtott és elforgatott kép.

Zajos kép.

Színskála-módosított és enyhén szemcsés kép.

Valóságszerű kép, térbeli torzítással, forgatással

és sok zavaró elemmel a háttérben.

Se egyéb zavaró tényező felvitele, se a

képminőség rontása nem változtatott az

algoritmusom hatásfokán.

49. ábra: Tesztképek a keretrendszeremhez

72

5. Elektronikus jegy-rendszer bevezetése egy kitalált

cégnél

Az utolsó fejezetben egy olyan rendszer megalkotását taglalom, melyet egy általam

kitalált, tömegközlekedéssel foglalkozó cég szeretne bevezetni. A rendszer természetesen az

elektronikus jegyek bevezetését és használatát valósítaná meg, a céget pedig a realitás

kedvéért akár a Budapesti Közlekedési Vállalatnak, más néven BKV-nak, is tekinthetjük, de

lényeges szempont, hogy a diplomamunkám alkalmazhatósága nem merül ki egy

szakterületen, bármely más céggel is szimulálható lett volna.

5.1. A rendszer céljának leírása a megrendelő cég szemszögéből

A megrendelő egy olyan elektronikus jegyrendszer bevezetését szeretné, mely

nagyban megkönnyíti az utasok jegyvásárlását, nyomon követhető, pontos statisztikát ad az

utazási szokásokról (így a járatok menetrendjének kialakításában is jelentős szerepet

kaphatnak ezek az adatok), valamint a tömegközlekedési járműveket jogtalanul használó

személyek kiszűrésére legalább akkora hatékonysággal képes, mint a jegy-alapú rendszer. Az

elektronikus jegy nem függhet a mobiltelefon típusától (természetesen reális keretek között,

pl. az 1 évnél nem idősebb telefonok 80%-án elérhetőnek kell lennie a szolgáltatásnak) és a

mobilszolgáltatótól. Használata nem bizonyulhat bonyolultabbnak, mint egy SMS elküldése,

valamint egy SMS vagy MMS fogadása, ugyanis az emberek nagy többsége ennek a technikai

tudásnak birtokában van, míg például a WAP használatát ennél jóval kevesebben sajátították

el, nem beszélve a legújabb technológiákról, melyeket csak egy viszonylag szűk, a technika

iránt fogékony réteg használ ki.

Az elektronikus jegyrendszer főként azok számára szeretné megkönnyíteni az utazást, akik

csak átutazóban vannak, vagy időszakosan tartózkodnak a városban, így az utazás

megkezdése előtt nem rendelkeznek utazásra jogosító szelvénnyel. Számukra az elektronikus

napijegy és vonaljegy bevezetése fontos. Egy másik célcsoport a rendszeres bérletvásárlók.

Ők ugyanis a bérletszelvény lejártakor kénytelenek sorban állni a bérletpénztárak előtt.

Számukra az elektronikusan igényelhető bérlet lenne a legsürgetőbb megoldás.

73

5.2. A rendszer funkcionális követelményei

Bemenetek az SMS-ek, melyek tartalmazzák a jegyrendelés követelményeit. Erre a

rendszer válasza egy megfelelően kódolt SMS-jegy, illetve SMS-bérlet, mely az

utazási feltételeknek megfelelő használat során érvényes utazást biztosít a

felhasználónak, ami ellenőrizhető.

A rendszernek alkalmasnak kell lennie nagy mennyiségű vásárlás valós idejű

kiszolgálására (telefontársaság vagy szolgáltató felelőssége).

Képesnek kell lennie nagyfokú terhelés mellett is megbízható működésre anélkül,

hogy a szolgáltatás minőségében érezhető csökkenés következne be.

Az SMS igénylése és a visszakapott elektronikus szelvény megérkezése között

maximum 30 másodperc telhet el átlagos üzemi terhelés mellett.

Szükséges, hogy a javasolt értéket meghaladó terhelés felett is stabil maradjon a

rendszer. Némi késleltetéssel, de mindenképp szolgálja ki a beérkező vásárlási

kérelmeket.

Az igényelt jegyeket több évre visszamenőleg archiválni kell, hogy visszakereshetőek

legyenek probléma esetén, vagy anonim statisztikák készítéséhez. A hosszú távú

archiválás nem tartalmazhat személyiségi jogokat sértő adatokat, továbbá a tárolt

rekordokból nem szabad, hogy kikövetkeztethető legyen a vásárló személye vagy

bármilyen személyes adata. Szükséges a magas fokú diszkréció megőrzése.

A rendszerben lévő adatok biztonsága az elvárható legnagyobb gondossággal legyen

biztosítva. Az adatok tartalmi információjának biztonságára kell figyelni, hogy azok

ne kerülhessenek ki illetéktelenek kezébe. Ezzel is csökkentve a rendszer

feltörhetőségét.

A jegyvizsgálóknál lévő SMS-jegy ellenőrző szoftver megbízhatósága 95% fölött kell,

hogy legyen. Továbbá az ellenőrző szoftver használata nem igényelhet komolyabb

műszaki tudást, cél a felhasználóbarát és egyértelmű kezelőfelület.

A rendszerben alkalmazott titkosító kódolás a termékek árához képest elvárható

nehézségű kell, hogy legyen, ugyanakkor az ellenőrök készülékein alkalmazott

dekódoló futása nem lépheti át az 1-2 másodperes futási időt.

Az ellenőrök készülékein az ellenőrzésnek körülbelül 3 másodpercen belül kell

lezajlania.

A rendszer egy bejövő SMS-re, amely tartalmazza a megálló kódját és a jegy típusát

küld egy megfelelően kódolt számsort tartalmazó SMS-jegyet.

74

A megállókban kihelyezett kódoknak nem szabad hosszúnak lenniük, és

mindegyiknek könnyen azonosíthatónak kell lennie.

Hibás SMS jegyrendelés esetén egy válasz SMS-t kap a felhasználó a hibásan

elküldött jegyrendelési igényéről, és nem kerül levonásra semmilyen extra összeg a

felhasználó egyenlegéről.

5.3. A rendszer nem-funkcionális követelményei

Minden BKV megállónak lesz egy saját egyedi azonosító kódja, melyet a jegy

rendeléskor meg kell adnia a vásárlónak, ezáltal lesz ellenőrizve, hogy melyik járatra

érvényes a menetjegy. Ezen felül egy normál SMS-jegy megvásárlásától számított 1 órán

keresztül érvényes. Átszálláskor természetesen új menetjegyet kell megváltani.

A vásárlók tájékoztatására minden BKV megállóban és járaton plakátok hirdetik, hogy milyen

formában és milyen tarifával vehető igénybe az elektronikus SMS-jegy szolgáltatás.

Egyéb nem-funkcionális követelmények, melyek konkrét pontosítást igényelnek (50. ábra):

Tulajdonság Mérés

Sebesség A másodpercenként feldolgozott tranzakciók száma

Méret A szoftver mérete kByte-ban

Egyszerű

használhatóság

Szükséges képzési idő

Felhasználóknak egyszerű használhatóság

Ellenőröknek részletesebb oktatást igényel

Megbízhatóság A hibák átlagos bekövetkezési ideje

Annak valószínűsége, hogy a rendszer nem áll rendelkezésre

Rendelkezésre állás

Robusztusság Újraindulási idő hiba után

A hiba okozta adat-meghibásodások valószínűsége

Hordozhatóság A célrendszerek száma

50. ábra: Nem-funkcionális követelmények és mérésük

75

5.4. Szakterületi követelmények vázlata

Ellenőrök oktatása az új rendszer használatával kapcsolatban. Jegyrendszer ismerete,

jelenlegi rendszer áttekintése, esetleges módosítása.

Jogi esetek felmérése az esetleges, jövőbeni, vásárlói panaszok kapcsán.

Programot üzemeltető, felügyelő, karbantartó, fejlesztő hozzáértő alkalmazottak

felvétele.

A rendszer folyamatos üzemeltetéséhez szükséges emberi erőforrások részletezése

műszakonként:

o Két felsőfokú informatikai végzettséggel rendelkező szakember (hiba esetén

mozgósítandóak, nem állandó felügyelet).

o Két középfokú informatikai végzettséggel rendelkező szakember (állandó

felügyelet).

o Két alkalmazás-adminisztrátor (a jegyrendszerben szereplő adatok

módosítása, beállítása, ellenőrzése).

o Igénytől függő számú jegyellenőr oktatás céljából, akik az új készüléket és

annak kezelhetőségét megtanítják az alkalmazottaknak.

5.5. Egy használati eset forgatókönyvének felvázolása

Felhasználó oldali forgatókönyv (51. ábra):

1. A felhasználó megérkezik egy BKV megállóhoz.

2. Jegyet szeretne vásárolni elektronikusan.

3. BKV megállóban a leendő utas SMS-t küld a BKV megadott telefonszámára

4. A központ rövid időn belül visszaküld egy válasz üzenetet, amely lehet elfogadó,

ilyenkor egy kódsorozatot és egy időpontot kap a leendő utas, így érvényes jeggyel

fog rendelkezni a megadott időpontig vagy lehet elutasító, ilyenkor pedig az

ügyfélszolgálat telefonszámát kapja meg, ahol érdeklődni tud a sikertelenség okáról.

5. Kellemes utazás a BKV járatán.

Ellenőr oldali forgatókönyv:

1. Műszak kezdete, az ellenőr a leolvasó készülékkel bejelentkezik a központba a saját

felhasználó nevével és jelszavával.

2. A bejelentkezés után a központból letöltődik az aznapi érvényes kódgenerálás.

76

3. Az ellenőr beállítja a leolvasó készüléknek az ellenőrizendő járat járatszámát, majd

felszáll.

4. Menetjegyek ellenőrzésekkor az egyik utasnak elektronikus jegye van, megkéri az

utast, hogy nyissa meg a válasz SMS-t, amely a kódot tartalmazza, majd mutassa fel a

leolvasó készüléknek.

5. A készülék leolvassa a kijelzőt, majd ellenőrzi, hogy a kód érvényes-e.

5.6. Az elektronikus utazási jegy bevezetésének célja

Időspórolás a jegyvásárlóknak.

Nem helyhez kötött jegyvásárlás lehetősége.

Jegyek érvényesség ellenőrzésének biztosítása.

Jegyekkel való visszaélés, csalás megelőzése.

Jegyellenőrök munkájának segítése (akár gyorsabbá tétele, persze ehhez ki kell

dolgozni a büntető rendszer meggyorsítását is).

Utasszállító vállalatok jegyekből származó bevételeinek biztosabbá tétele (talán

többen veszik meg, többet lehet ellenőrizni).

51. ábra: Egy lehetséges használati eset UML diagram

77

Egyszerűbb jegyvásárlás ( biztonságosabb: nem látják, hogy sorban áll, és nem tudják,

hogy pénz van nála, nem tudják, hol tartja a tárcát).

Környezetvédelem (a fölösleges szeméttermelés kiiktatása).

Vásárlási statisztikák alapján marketing és célirányosabb üzleti logika kigondolása a

nagyobb haszon érdekében.

Az elektronikus jegyek bevezetésénél élnünk kell a következő feltételezésekkel:

Az emberek inkább megveszik a jegyet így, mint várnak a sorokban.

A telefontársaságok, és az utasszállító vállalatok megegyezése/szerződése akár a

haszon megosztásának figyelembevételével, de létrejön.

5.7. Létrehozandó termékek, szolgáltatások és elvégzendő feladatok

Telefonvállalatokkal való szerződés, és a jegyrendszer programjának megvalósítása,

üzenetek kódolásának megoldása.

Telefonvállalatokkal való szerződés, és a jegyrendszer programjának megvalósítása,

üzenetek kódolásának megoldása.

Büntető rendszer megoldása, annak egyszerűsítése. (Helyben való fizetés telefon

útján történő megoldhatósága esetleg, kiszűrendő a "na akkor inkább leszállok"

megoldás.)

Jegyrendszer elérésének (SMS, MMS, WAP, web) megtervezése és leprogramozása.

Attól függően, hogy milyen kódolást választunk, annak megjelenítésének és a

bármilyen telefonra alkalmazhatóságának megoldása.

A rendszer egységei közötti kommunikáció specifikálása, az adatreprezentálás

módjának megalkotása, a biztonsági kockázatok felmérése.

Redundáns, telefonvonalra kapcsolt SMS-szerver konfigurálása, programozása.

Automatikus biztonsági mentések készítésének megszervezése, a tárolás biztosítása.

A központi szerver megfelelő védelmének kialakítása (tűzfal, jogosultságok

beállítása).

Telefonos alkalmazások megvalósítása (lehetőleg platform független nyelven).

Jegyellenőrző kapuk megvalósítása, és a rendszerbe történő integrálása.

78

5.8. A rendszer architekturális modellje

Az adatfolyam modell funkcionális szemszögből mutatja be, hogy hogyan dolgozza fel a

rendszer az adatokat, és ezek áramlását is. Ezen felül reprezentálja a különböző állapotok

között.

Az ellenőrzés adatfolyam modellje (52. ábra):

Napi kód lekérése: ellenőr adatfolyam modellje (53. ábra):

Napi kód lekérése: központi adatfolyam modell (54. ábra):

52. ábra: Ellenőrzés folyamatának adatfolyam modellje

53. ábra: Adatfolyam modell az ellenőr napi kódlekérdezésének folyamatáról

54. ábra: Szerver oldali adatfolyam modell

79

Szerver oldalon beérkező igénylés adatfolyam modellje (55. ábra):

A rendszer rétegezett architektúra modellje (56. ábra):

Alrendszerek definiálása:

Szerver

o Központi adatbázis

Regisztrált felhasználók hozzáadására és adminisztrálására szolgáló

alprogramok

Megállószámok megváltoztatását szolgáló szubrutinok

Jelenleg érvényes vonaljegyek és bérletek megváltoztatását szolgáló

szubrutinok

Vonaljegyek megváltoztatását szolgáló szubrutinok

Bérletek megváltoztatását szolgáló szubrutinok

Biztonsági másolatok készítését végző időzített alprogramok

o Telefonhálózati interfész

Bejövő SMS-ek fogadására szolgáló alrendszer

55. ábra: Szerverre befutó igény adatfolyam modellje

56. ábra: Az elektronikus mobiljegyek rendszerének rétegezett architektúra modellje

80

Kimenő SMS-ek küldését szolgáló alrendszer

o Kérésfeldolgozó szubrutinok

Adatbázis bejegyzések írását szolgáló műveletek

Kódgenerátor indítására és konfigurálására szolgáló alegység

Regisztrációs kérelmek kezelése

Adatbázis lekérdezési templatek

o Kódgenerátor

o Adminisztrációs felület

Adatbázis biztonságáért felelős alegységek

Régebbi adatbázisdumpokból adatok kinyerésére szolgáló

szubrutinok

Hibaelhárítás

o Vendég felület (online, bankkártyával történő bérletigénylésre)

Hitelesítés

Elektronikus készpénz átutalási megbízás

o Internetes felület (kódvalidáció lebonyolítására)

Ellenőr oldali telefonos alkalmazás validációs kérelmeinek fogadása

Kódvalidátor konfigurálása

Eredmény visszaküldése

Felhasználó oldali telefonos alkalmazás

o kommunikációs interfész

o grafikus felhasználói interfész

Ellenőr oldali telefonos alkalmazás

o Grafikus felhasználói interfész

Ellenőrzési feladatokat kiszolgáló szubrutinok

o Kommunikációs interfész

Napi kódot lekérő szubrutin

Nap végén a teljesítéseket szummázó szubrutin

o Képfelismerő modul

o Karakterfelismerő modul

o Kódvalidátor

81

Ellenőr oldali alrendszerek UML-je (57. ábra):

Szerver oldali alrendszerek UML-je (58. ábra):

5.9. A rendszer tesztelési tervei

Két részre bontjuk a tesztelési terveket:

szerver oldali tesztelés

ellenőrző készülék oldali tesztelés

Általános megjegyzések az egység- és rendszertesztekhez:

Igyekszünk a fejlesztési fázis már korai szakaszaiban a komponens és integrációs

teszteknél rálelni a lehető legtöbb hibára, mert később a kész termékből már

nehezebb lesz az esetleges bugokat, hibákat vagy hiányzó funkciókat kiemelni,

57. ábra: Az ellenőr oldali alrendszerek UML diagramja

58. ábra: A szerver oldali alrendszerek UML diagramja

82

pótolni. Ehhez a tesztelések során is mérföldköveket fektetünk le, és az egyes

mérföldkövek elérése mind felénk, mind a megrendelő számára a szoftver minőségét

igazoló informatív jellegű jel lesz.

Bevett tesztstratégiaként mi is használjuk azt az elvet, hogy egy szoftverben ahol egy

hiba van, annak környékén több is akad. Így igyekszünk nagyobb ráfordítást szentelni

az esetleges hiba-clusterek felfedésében, majd ezek után mindig végrehajtjuk a

regressziós teszteket.

Mivel sajnos az elvi felépítésből eredendő hibákat a komponens és integrációs

teszteknél nem tudjuk még felfedezni, a rendszertesztek fázisa után folyamatosan

összevetjük a specifikáció követelményeit a megfelelő tesztesetekkel, és review-kat

alkalmazunk.

A stabil és robusztus működés a megrendelő egy kiemelten fontos kívánsága, attól

hogy a definiált tesztesetek már nem jeleznek hibákat vagy hiányokat, a fejlesztői

gárdának mindenképpen implementálnia kell a rendszerbe worst-case-scenerio-s

megoldásokat is.

A tesztfolyamat a következő szigorú részekből tevődik össze (59. ábra):

Szerver oldali tesztelés:

Komponens teszt: A szerver oldali program moduláris felépítéséből adódó komponensek

egyedi tesztjeit a program bonyolultságának elenyésző komplexitása miatt a programozók

59. ábra: Tesztelési lépések folyamatábrája a rendszer fejlesztésekor

83

maguk végzik el. A komponenseknek eleget kell tenniük a komponens specifikálásakor

lefektetett követelményeknek, illetve elő- és utófeltételeknek.

Integrációs teszt: A tervezett interface-ek hibáinak felderítése végett, a komponensek

integrálása után egy szigorú integrációs tesztet vezetünk végig az SMS szolgáltatást nyújtó

szerződtetett telefontársaság(ok) és a szerveroldali feldolgozó program között, különböző

tesztstratégiákat figyelembe véve, hogy a későbbiek folyamán szinte közel 0-ára redukáljuk a

telefontársaság szolgáltatása miatt bekövetkező esetleges hibák megbúvásának esélyét.

Rendszerteszt: A DIN-ISO 9126-nak megfelelően hajtjuk végre a használhatóságra,

módosíthatóságra, funkcionalitásra, portabilitásra, megbízhatóságra és hatékonyságra

vonatkozó rendszerteszteket, hogy ráleljünk a szoftvertermékben rejlő funkcionális és nem-

funkcionális hibákra a rendszer viselkedésében.

White box teszt: Az SMS jegyek strukturális ismeretére alapozva a jó és rossz SMS jegyek

teszteseteire tesztadatokat generálunk, melyek lefedik az azonos ekvivalencia osztályokba

tartozó teszteseteket. A program generálja a helyes SMS-jegy igényeket és küldi a szervernek.

A szerver válasz SMS-eket küld a programnak vagyis elektronikus jegyeket, miután

feldolgozta a bejövő üzeneteket. Ezzel tesztelhető a szerver oldali helyes kiszolgálás

viselkedése.

Black box teszt: Teszt programmal a szerver oldali kiszolgálás tesztelése helytelen SMS-jegyek

esetén. A program generálja a helytelen SMS-jegyeket, például: "autó", "Imre", "gsgf987" és

küldi a szervernek. A szervernek észre kell venni a hibát és figyelmeztető SMS-t kell küldenie

a programnak további útmutatással.

Terhelés teszt: Teszt programmal a szerver oldali kiszolgálás tesztelése változó SMS-jegy

forgalom esetén. A program ciklusban generál 10.000 feldolgozandó SMS-t pár másodperc

alatt és a rendszer nem omolhat össze, szigorú elvárás a rendszerrel szemben a stabil

robosztus működés. Amennyiben a rendszer elbukik a terhelés teszten, javaslat a fejlesztői

gárdának a többszálú programozást támogató pool-ok használatára az erőforrások

szétosztása végett, így az SMS-ek feldolgozása érkezési sorrendben kis késleltetéssel, de

biztosan befejeződik.

84

További tesztek: A rendszerkövetelményeknek megfelelően az üres SMS-eket, illetve az olyat,

ahol az SMS jegy ára nem vonható le a feladótól (például ingyenes internetes SMS küldési

lehetőség), ezeket is le kell kezelnie a rendszernek.

Megrendelő tesztesetei: A megrendelő tesztadataival a szoftvertermék specifikációnak

megfelelő futását mutatjuk be.

Ellenőr oldali tesztelés:

Komponens teszt: az ellenőrök készülékein futó SMS-jegy detektáló, illetve -kinyerő, a jegy

értékét dekódoló és az ellenőr számára a készülék rendszerüzeneteit generáló komponensek

tesztelése.

Integrációs teszt: a fentebb említett készülék-komponsensek kommunikációjának átfogó

tesztelése előre definiált tesztesetekre.

White box teszt: Az SMS-jegyek hitelességének vizsgálata. A helyes formátumban küldött

SMS-jegyekre szkenelhető érvényes válasz SMS-jegyek küldése. Ha a szerver szándékosan

hamisított jegyet kap, akkor azt észre veszi és egyéb jelentést ír róla a felhasználónak és az

üzemeltetőnek is.

Black box teszt: A különböző SMS-jegyek beolvasásának a tesztelése. Ha a rendszer csak a

megadott formátumot olvassa SMS-jegynek. Például: Ha képet kap egy tárgyról, azt ne

értelmezze jegynek.

Szkenner teszt: A különböző telefonokról való leolvasás tesztelése. Eltérő kijelzőjű és

struktúrájú telefonok szkenelhetőségének tesztelése.

5.10. Elektronikus jegykezelő rendszer egy gyakorlati megvalósítása

Munkám végső fázisaként implementáltam egy működőképes elektronikus jegyek

kiszolgálását lehetővé tévő rendszert az eddig tárgyaltak alapján. Mivel diplomatémám egyik

fő aspektusa volt az utazási jegyek megvalósítása elektronikus vonalkódok formájában, így az

85

általam írt megoldásban is a kétdimenziós Datamatrix vonalkódot használom a jegyek

információtartalmának tárolásához.

A korábbi, általánosított példában főképp olyan megoldást taglaltam kezdetben, ahol az SMS-

jegy egy egyszerű szöveges SMS mindenféle vonalkód felhasználása nélkül. De nézzük is, hogy

ennek mik a hátulütői, és miért lenne célszerűbb az általam preferált kódot felhasználni.

Képzeljük el a jelenleg még papír alapon működő vonaljegyeket. Egyik

metróállomáson kilyukasztom, akkor kapok rá egy nyomtatott kis számsorozatot. Ha

két megállóval arrébb utazok, majd ott is újból kilyukasztok egy vonaljegyet, a két

számsort összevetve már is rengeteg mindent ki lehet találni belőle. Például könnyen

megtalálható, hogy mely pozíciók jelölik az aktuális dátumot és időt, illetve az

állomás sorszámát. Ily módon a jegy érvényességét igazoló számsorozat

könnyűszerrel hamisíthatóvá válik, ha ez bárkinek is érdekében állna. Mivel haladunk

a korral, oda kell figyelnünk a zöld-technológiák alkalmazására, és szükség van a

pontos és megbízható statisztikákra, idővel át fogunk térni az elektronikus jegyekre

mi is. Itt történik az első bökkenő, ha nem vagyunk elég felkészültek. Papír alapú

jegynél még visszatartó tényező volt, hogy jegyhamisításhoz az utazási jegy papírját is

hamisítani kéne. De egy digitális jegynél ennek már semmi akadálya. Hiszen az

elektronikus jegyek a készülékek memóriájában tárolódnának SMS formájában, és ha

valaki egy csöppnyi erőfeszítéssel visszafejti a számsorozat kódolását, továbbá meg

van áldva némi informatikai képzettséggel, könnyűszerrel kezdheti kreálni magának

az érvényes utazási jegyeket anélkül, hogy akár egy ellenőrnek is szemet szúrna ez.

Az első megoldás az lenne, hogy akkor titkosítsuk úgy az SMS tartalmát, hogy ne

lehessen könnyedén, rövid időn belül visszafejteni a kódolást. Ez működne is, hiszen

rengeteg jól bevált titkosítási algoritmus létezik már. Ugyanakkor ez a megoldás

magával vonná azt a következményt, hogy nem csak visszafejteni, de ellenőrizni is

sokkal nehezebbé válna az elektronikus jegy, hiszen ezután az ellenőr már nem tudja

megmondani ránézésre, hogy érvényes-e a kód. Persze lehetne játszani a kódolással,

hogy pl. bizonyos pozíciókba egyes napokon mindig ugyan az a kód szerepel, de ez is

könnyen kitalálható, továbbá bonyodalmasan kezelhető, és csak ránézésre

mondhatnánk meg, hogy egy jegy valódi lehet talán.

o Egyik megoldás lenne, hogy az ellenőr folyamatos összeköttetésben áll a

jegyeket kiállító szerverrel, és ellenőrzés alkalmával bepötyögi a kódolt

üzenetet a gépébe, ami aztán lekérdezi a szervertől, hogy történt-e ilyen

86

vásárlás. Ez borzasztó időigényes megoldás, ha mindenkit ellenőrizni

szeretnénk, kígyózó sorokban mérhetnénk a hatékonyságát. Továbbá a

mellégépelés esélye is igen magas.

o Egy másik megoldás lehetne, hogy az ellenőr készüléke képfeldolgozási

algoritmusokkal próbálja meg kinyerni a megnyitott SMS üzenet tartalmát, és

vagy lekérdezi a szervertől, hogy vásároltak-e ilyet, vagy ő maga dekódolja,

és állapítja meg, hogy a tartalom alapján érvényes lehet a jegy. Ez még

kivitelezhetőnek is hangzik, hiszen az SMS-ek szövegének betűtípusa

viszonylag könnyedén felismerhető OCR (Optical Character Recognition)

technológiával. Ugyan akkor balgaság lenne már is ilyen nagy fába vágni a

fejszénket, mert különböző telefonoknak különböző a kijelző mérete, a

világossága, egyeseknek tükröződik a felülete bizonyos fényviszonyok között,

másoknál sokkal kevesebb vagy épp több karaktert tudunk megjeleníttetni a

képernyőn egyszerre.

Ezekre mind gyógyír lenne a kétdimenziós Datamatrix vonalkód alkalmazása, ugyan is

teljesen indifferens számára, hogy mekkora képernyőn jelenítjük meg, hiszen

könnyűszerrel átméretezhető úgy, hogy még mindig olvasható marad a kód. Továbbá

aki egy Datamatrix SMS-jegyet szeretne visszafejteni, nem elég, hogy a titkosítással

meg kéne küzdenie, de még a vonalkódolás rejtelmeibe is bele kéne ásnia magát,

hogy sikerre vigye az akcióját.

Ezekre alapozva döntöttem amellett, hogy az én tesztrendszeremben a kétdimenziós

Datamatrix vonalkód fogja megtestesíteni az SMS-jegy hordozó formátumát.

Alapból természetesen egy mobiltelefonon sincsen olyan alkalmazás, ami képes lenne egy

SMS-ből Datamatrix kódot kreálni és a képernyőn megjeleníteni. Pedig ilyen alkalmazások

létrehozásához nincs is sok mindenre szükségünk. A választott programozási nyelvből ezeket

a funkciókat kell tudnunk elérni:

Tárolt SMS-ek tartalmának beolvasása. ( Létrehozás dátuma és a feladó címe is jól

jöhet. Az SMS megérkezésének dátuma jól jön, ha már több SMS jegyünk is van a

telefonon. A feladó számának lekérdezése pedig azt a lépést egyszerűsíti le, hogy

minden SMS-be bele kelljen olvasnia a programunknak, hogy vajon Datamatrix-jegyre

hasonlít-e a formátuma. Hiszen ha az utazási vállalat SMS-szerver számáról jött az

üzenet, biztos, hogy nem szülinapi jókívánság. )

87

Képernyőre rajzolás, hogy ki tudjuk tenni a feldolgozott kétdimenziós vonalkódot.

Én e célból a Google Android operációs rendszerét és az erre a platformra használható Java

programozási nyelvet választottam [33]. A 0.9-es verzióban volt beépített függvény a

programozók számára, hogy végigiteráljanak az összes tárolt SMS-en, de ez valahogy az 1.0-

ás verzióban már szó nélkül eltűnt. Én az 1.5-ös verziójú Android-ra fejlesztettem a

megjelenítő alkalmazásom, aminek az API-jából arra nyílik csupán lehetőségünk, hogy SMS

érkezéséről értesüljön a programunk, és az újonnan érkezett SMS-hez hozzáférjen.

Az egyik amit tehetünk, hogy míg az alkalmazásunk fut, értesülhet a beérkező SMS-

ekről, és ha a kiszolgáló szervertől jön SMS vagy az SMS tartalma megjeleníthető

Datamatrixként, akkor ezt elmenti az alkalmazás magának egy lokális adatbázisba,

amihez csak ő férhet hozzá, és ő is törölhet onnan.

Egy másik megoldás egy hivatalosan nem támogatott út, hogy tudjuk az SMS-ek

elérési útvonalát az operációs rendszeren, ráállítunk egy mutatót, és végigiterálunk

az elemeken. A probléma a hivatalosan nem támogatott megoldásokkal az, hogy

semmi sem garantálja, hogy ez mindig és mindenhol működni fog, így meg nehéz

piacképes alkalmazást készíteni. Az egyszerűség kedvéért, és mert szimulátorban

nem tudtam SMS-eket küldeni tesztelés céljából, egy helper osztályt hoztam létre,

amiben eltároltam 3 tesztadatot.

Ezt a 20x20-as, négyzetes Datamatrix-ot használtam a tesztadatok létrehozásakor, mely a

„V3;Arpad hid;200910111345” karakterek sorozatát kódolja (60. ábra):

Első kísérletezésekkor úgy próbáltam meg SMS-ben tárolni a Datamatrixot, hogy rögzítettem

egy fejlécet: „20x20;”, ami leírta a vonalkód teljes méretét a markereket is beleszámítva.

Majd az adatcellák következtek oly módon, hogy negatív szám jelezte, ha fekete cella jön.

60. ábra: Az Androidos mobilalkalmazásomhoz használt teszt datamatrix

88

Továbbá pontosvessző választott el minden cellát, és az egész számok azt jelezték, hogy az az

adott színből hány cella jön egymás után. Példa sor kódolására: „2;-1;7;-2;3;-1;1;-1;”.

De ez rendkívül pazarló megközelítésnek bizonyult. Pontosan 450 karakteres SMS keletkezett

így, ami nem elfogadható. A második megközelítésben negatív számok csak az adatsorok

elején lehettek, és azt jelölték, hogy sötét vagy világos a legelső cellacsoport. Utána a

pontosvesszők mindig színváltást jelöltek, így nem volt szükség mindig feltüntetni a negatív

értékeket. De ez sem bizonyult járható útnak, ugyanis 396 karakter volt még mindig az így

kreált SMS hossza. A harmadik és végső formátumomban végül a pontosvesszőket is

eltüntettem, azzal a feltételezéssel élve, hogy az azonos színcsoportba tartozó cellák 1 és 9

közötti értéket vehetnek csak fel. Feltehetnénk a kérdést, hogy ezt milyen alapon feltételezi

az alkalmazásom, és hát én fel is tettem magamnak ezt a kérdést. Az általam használt 20x20-

as négyzetes Datamatrixba közel 50 karakter tárolható, aminek én csupán csak a töredékét

használtam fel. A legkisebb használható Datamatrix mérete 8x8 (61. ábra). Amiket mi tárolni

kívánunk egy SMS jegyben, azok a következőek:

Milyen típusú a jegy (jelölheti akár egy rögzített szám)

Mely állomástól érvényes (szintén rögzíthető maximum 3 karakteren)

Mikortól érvényes (év első két száma elhagyható, feltéve, hogy 3000 után nem

akarjuk használni ugyanezt a rendszert)

Ezek az információk akár egy 14x14-es Datamatrixban már elférnek numerikus adatként.

61. ábra: Datamatrix kapacitástáblázata a különböző formátumokra [28]

89

Amennyiben a feltételezés még sem állja meg a helyét, és lehet a kódolandó vonalkódunkban

9-nél nagyobb, egybefüggő cella, úgy csak az SMS kódolás formátumának a feldolgozását kell

átírni hála a programom moduláris felépítésének. Erre az eshetőségre hagytam is egy

elágazást a program struktúrájában, hogy kezelje, ha paraméterként azt kapja, hogy a

feltételezéssel nem élhet.

Ezen felül egy negyedik fajta kódolás is elképzelhető még. Mégpedig, hogy a fekete-fehér

cellák minden lehetséges permutációjához hozzárendelünk egy értéket, úgy mintha csak egy

Hash-táblát készítenénk. Ha folytonosan inkrementált egész számokat is alkalmaznánk

csupán, egy 22x22-es datamatrix adatcelláinak összes lehetséges változata

222.2=220=1048576. Azaz a Datamatrix bármely sorát le tudjuk írni egy legrosszabb esetben 7

soros számmal. Ez annyit jelent, hogy legrosszabb esetben „fejléc + 20*7 + 20 szeparáló

karakter” ~= 160 karakteren tudunk tárolni 60 numerikus karaktert. Természetesen ehhez a

megoldáshoz szükség van arra, hogy a vásárlók készülékén is ott legyen a megfeleltetési

táblázat a Datamatrix felépítéséhez.

Folytatván a korábban megkezdett gondolatmenetet, lényegében ezzel a harmadik fajta SMS

kódolással sikerült 190 karakterre lezsugorítanom a 20x20-as Datamatrixot. Egy 14x14-es

mátrix esetén ez leszűkíthető egy SMS tartalmára. Amennyiben még is több SMS-ben férne

csak ki a kód, ilyen eshetőségre is szükségesek a szerződések a telefontársaságokkal. Biztos,

hogy meg lehet velük egyezni és kedvezményes áron küldeni a jegyeket, vagy pedig

belekalkulálni ezek összegét a vonaljegyek árába.

A mobiltelefonos alkalmazásom tehát végigiterál egy külön futási szálon a tárolt SMS-eken,

és ezt jelzi is a felhasználó felé (62. ábra):

62. ábra: Külön futási szálon végrehajtott SMS jegy értelmezés

90

Jelenleg úgy működik az eljárás, hogy minden SMS tartalmába beleolvas, és egy gyorstesztet

végez, megpróbálja megkeresni a fejlécet az első karaktereken. Amennyiben talál fejlécet,

megjelöli az SMS objektumot, és átadja egy teljes feldolgozásra. Ez a teljes értelmezés még

mindig mondhatja, hogy nem volt érvényes az SMS vonalkód tartalma, ha bármi problémája

merült fel a Datmatrix összeállítása közben. Majd a sikeresen értelmezett jegyeket a

létrehozásuk dátuma alapján egy görgethető listában megjeleníti: (63. ábra)

A felhasználónak csak annyi a dolga, hogy kiválasztja a dátum alapján bemutatásra szánt

jegyet, és a program meg is jeleníti az ellenőrnek (64. ábra):

63. ábra: A tárolt SMS jegyek megjelenítése

64. ábra: A tárolt SMS jegyek megjelenítése kétdimenziós Datamatrix vonalkódként

91

Ezt a megjelenített vonalkódot az ellenőr a ZXing vagy más hasonló, mobiltelefonon is futó,

vonalkódolvasó alkalmazással kiolvastatja, kinyeri belőle a Datamatrix vonalkód információ

tartalmát, amit átad a dekódoló kulcsának, és már is megjelenik számára az eredeti, SMS

szerver által összeállított üzenet: „V3;Arpad hid;200910111345”. Ezt a megjelenítést

természetesen szépen formázva jelenítjük meg majd az ellenőr felé, hogy ránézésből meg

tudja állapítani a jegy tartalmát.

Egy ilyen ellenőrzés a valóságban körülbelül a következő időtartamot öleli fel:

SMS jegyet megjelenítő alkalmazás elindítása és az aktuális jegy kiválasztása függ

attól, hogy csak ellenőr felszólítására történik meg ez, vagy már az ellenőrzőpont

elérésekor készen van a jegy bemutatásra.

Képfeldolgozó algoritmus futtatása az adat kinyerése érdekében 1-4 másodperc

Kinyert adat dekódolása 1-2 másodperc

Döntés a jegy érvényességéről 1-2 másodperc.

Zökkenőmentesen 10 másodperc alatt elvégezhető az ellenőrzés. Természetesen nagy

tömegben ez soknak számít, ha mindenkit ellenőrizni kívánunk. Ugyanakkor itt léphetne

életbe a beléptető rendszerek bevezetése, egy forgó fémtárcsa, ami kamerával van ellátva. Ez

a kamera és a hozzá tartozó feldolgozó egység akár összeköttetésben is állhat a központtal,

és mindenkinek be kell mutatnia az SMS jegyét az áthaladás érdekében. Esetleg egy ellenőr

vigyázhat a belépési pontoknál, hogy ne próbáljanak meg átsurranni, vagy ne rongálják meg a

készüléket. Reklamáció esetén, vagy a régi papíralapú utazási jegy használatakor is segítséget

tud nyújtani.

Az ellenőröknél található jegyellenőrző eszközök tartalmazhatnak egy cserélhető

memóriakártyát, amin folyamatosan logolnák az aznap beolvasott SMS jegyeket. Egy

komolyabb készülék GPS vagy GSM bázisállomások alapján még azt is hozzáfűzhetné a

rekordokhoz, hogy hol történt az adatok felvitele. Egy adatbázisból a koordinátához tartozó

megállót is ki tudná keresni magának. Ezeket a memóriakártyákat a munka végeztével a

készülékekkel együtt le kellene adni a vállalatnál, ahol egy szakember összegyűjtené őket,

majd lementené az információt róluk, és egy program elindításával megtörténne az SMS

szerver által jóváhagyott vásárlások és az ellenőrök által rögzített jegyek összevetése,

továbbá mindezek archiválása későbbi statisztikai vagy marketingcélokra. Ily módon azonnal

kitűnnének azok a rekordok, ahol az ellenőr olyan jegyet engedett át, amiért nem fizettek. Ez

92

esetben pedig azonnal le lehet cserélni a titkosítási kulcsot, és a hamisító másnap már fenn

fog akadni az ellenőrök rostáján.

A titkosításhoz használt dekódoló kulcsot a memóriakártyákat összegyűjtő szakember

minden éjszaka visszatölthetné az eszközökre, amennyiben erre szükség van, mert változott a

kód. Természetesen a készülékeknek az 1 évnél nem korábbi kulcsokat is meg kell őrizniük,

hogy például régebbi érvényes éves bérlet ne akadjon fenn a megváltoztatott titkosítás miatt.

Gondolni kell továbbá arra is, hogy az ellenőrök készüléke ilyen folyamatos használat mellett

hamar lemerülhet. Ezért töltőket, esetleg csereelemeket kell számukra biztosítani, vagy az

ellenőrző ajtók bevezetése felé kellene orientálódni.

Eljutottunk addig a pontig, hogy már tudjuk, hogy valósul meg az elektronikus utazási jegy

megjelenítése és ellenőrzése. Most ideje rátérni arra, hogy hogyan készül el egy ilyen

utazásra feljogosító, digitális adat.

De mielőtt erre rátérnék, még pár mondatban visszatérnék a biztonságosságot szolgáló

ötletekre mind az ellenőr oldalon, kis trükkök alkalmazásával, vagy akár szerveroldali komoly

titkosítás felhasználásával, továbbá pár, már korábban pedzegetett érdekes kérdés:

Felszállhasson-e valaki ellenőrzés nélkül? Random ellenőrzések elegek-e, beszállásnál

kell-e? Csak forgalmasabb helyeken van állandó ellenőrzés?

Mi történik, ha én elküldtem az SMS-t, de valamiért nem kapok választ a szervertől?

o Én készülékemben van a hiba (ellenőr lekérdezheti a szervert, hogy kapott-e

erről a számról SMS-t mostanában a szerver! Ha nem, akkor sajnáljuk,

szolgáltatójával beszéljen, miért nem továbbította az SMS-ét.)

o A szerver túlterhelt (ezért kell a szerződés, hogy ilyen ne fordulhasson elő,

garantálják nekünk, hogy ez nem esik meg.)

o Éterben veszett el az üzenet, és mondjuk csak fél óra múlva kapnám meg.

SMS karakterformátuma is egy bizonyos szabványos, jól olvasható fonttípus. Esetleg

a válaszkódot, ami betű és számok sorozata, is felismerhető kamerás rendszerrel.

(Érdemes lenne elgondolkodni azon, hogy a válaszkódban vannak bizonyos betűk-

számok, amik mindig változnak az adott dátumtól és esetleg óráktól függően. Így

ránézve is viszonylag biztonságosan megmondható, hogy valaki tényleg akkor vette-e

az SMS jegyét, azért, hogy ne legyenek akkora torlódások, ha esetleg elromlana a

kamerás felismerés.)

93

Egyszerű lineáris kódolást nincs értelme használni, mert küldünk pár SMS-t, és ha

még van kis affinitásunk is hozzá, pillanatok alatt visszafejthető a kódoló eljárás.

Egy jó megoldás lenne, hogy md5, sha-1, dsa vagy hasonló titkosítást használnánk. Itt

van pár példa php-n implementált md5(message digest)-ös kódolásra. A kódolt

szöveg formátuma:

o "jegy vásárlásának ideje - idő"

o "mettől jó - idő"

o "meddig jó -idő"

o "tel szám"

o "diákjegy"

o idő: év hónap nap óra perc másodperc

o tel szám: a szám, amiről vették

o diákjegy: opcionális a végén. Ha diákjegy, akkor van a kódolt üzenet végén

egy D betű, és kéretik felmutatni a diákit ellenőrzéskor.

o Például:

200903011516172009030416341120

090511114500+36303113416

9b1e5d18e5f8187876012f20ab218227

200903011516172009030416341120090511114500+36303113417

3bd67bda0af3659a2a5ee1c2f61273ed

200903011516172009030416341120090511114500+36303113418

fab5e8b5dc36152f7ddc2321a2156c44

o Online kipróbálható verzió: http://lnx.braviale.com/md5.php?md5=c

o Jól látható, hogy a sor végén 1 szám változása teljesen más kódot

eredményez. ==> ezek nem-lineáris kódolók. Ha egy ilyen SMS-t kapnék egy

barátomtól, ránézésre meg nem tudnám mondani, hogy mit tartalmaz.

Viszont, ha valaki próbálgatással rájön a kódolás formátumára, hiszen tudjuk,

hogy milyen adatoknak kéne szerepelnie a kódolt szövegben, és az

algoritmus típusára, onnantól kezdve bármikor gyárthat magának SMS

jegyet. Nem lenne egyszerű rájönni, de ha valakinek még is sikerülne, elég

költséges lehetne a BKV számára.

==> nyilvános kulcsú titkosítás

o ==> generált privát kulcs és hozzá tartozó publikus kulcs

o ==> az üzenetet a privát kulccsal kódoljuk (privát kulcs a szerveren)

94

o ==> a kódolt üzenetet csak a privát kulcshoz tartozó publikus kulccsal lehet

kinyitni (publikus kulcs az ellenőrök gépén)

o ha egy ellenőr gépét ellopják, semmire nem mennek vele

o az értelmes üzenetet, amit kódolt a szerver, csak publikus kulccsal lehet

visszafejteni

o publikus kulcsot meg csak a megfelelő privát kulcsból lehet generálni

o a privát kulcs pedig sohasem hagyja el a szervert.

o ha valamiért még is új privát kulcs kellene, ez lényegében egy text fájl, és

rövid időn belül generálható új, majd üzembe helyezhető

o ehhez az egészhez annyi kell, hogy az ellenőrök gépére egyszer minden privát

kulcs generálása utána a nekik megfelelő publikus kulcsot rátöltsük.

o az egész rendszer kibővíthető egy olyan „csalás” ellenőrzéssel, mivel ahhoz,

hogy egy jegy érvényes legyen, a formátuma is érvényes kell, hogy legyen. Az

általam találomra kitalált formátumnak a végén pedig ott van a mobilszám,

amiről rendelték. Szóval minden ellenőrzéskor valamilyen memóriakártyára

menti az ellenőrök gépe, hogy xy számról volt egy SMS jegy. Ugyanezt a

szerveroldalon is megtesszük. Így bármikor, ha összevetjük a két oldal

mentett adatait, ha az ellenőrzéskor olyan szám jelenik meg, amit a

szerveroldal még sosem logolt abban az időpontban, akkor biztos, hogy

hamisított jegyet engedtünk át, és generálunk új privát meg publikus kulcsot.

o nem akármilyen privát kulcsos kódolás kell, mert az terjedelmes, hosszú

kódolt szövegeket is tud generálni. Nekünk kifejezetten változó hosszúságú

privát kulcsú titkosítás kell, ahol meg tudjuk határozni, hogy maximum

milyen hosszú lehet egy kódolt üzenet, hiszen több oldalas SMS-t nem

fogunk küldeni a vásárlónak, ha meg egy oldalra sem fér ki, problémás a

gyors ellenőrzése.

o ==> a kódolás kiegészíthető azzal a már korábban tárgyalt megoldással, hogy

plusz karaktereket szúrunk a kódolt szöveg elejére, végére vagy bármilyen

pozícióba, melyeket naponta / fél naponta vagy bármilyen időközönként

változtatunk. Ehhez ugye az kell, hogy miután a szerver kódol egy SMS jegyet,

az adott pozícióba beszúrja a plusz karakter(ek)et. Ellenőrzéskor, meg az

ellenőr gépének is tudnia kell erről, hogy ne tekintse a kódolt üzenetnek.

Ezért ezt reggelente, mikor az ellenőrök találkoznak a központi helyükön, és

megbeszélik, hogy aznap ki hová megy, akkor megbeszélik, hogy délután 3ig

például egy A-t szúrunk a kódolt szöveg 2. pozíciójába, azután meg egy 9-est.

95

Az ellenőr gépén bekapcsoláskor megjelenik egy GUI, ahol be kell állítani,

hogy melyik nap, hánytól hányig, melyik indexben milyen plusz karakter lesz.

Ezt azért találtuk ki, hogy gyorsítható az ellenőrzés, mert így ránézésre is

nagyjából eldönthető egy sima jegyről (nem vonalkód-jegyről), hogy

érvényes-e vagy sem. Továbbá nehezíti az esetleges visszafejtést is, hisz így

már nem csak azt kell egy cracker-nek kitalálnia, hogy milyen algoritmussal

kódolták az üzenetet, és hogy milyen kulccsal, hanem számolnia kell azzal is,

hogy változó helyen változó tartalom lehet. Ezzel a módszerrel szintén, ha

sikeresen visszafejtené a kódot, maximum arra a napra tudna ingyen jegyet

kreálni.

Visszakanyarodva a szerveroldali megoldáshoz, ismertetném az általam készített SMS-szerver

működési alapjait:

A szinte minden mobiltelefonon megtalálható AT [29] parancsokkal végeztettem

számítógéphez csatlakoztatott GSM készülékkel az SMS-ek küldését és fogadását.

A Java Communication API*30+ használatával csatlakoztam Java programból a GSM

készülékhez, és adtam ki a bemeneti folyamára az AT parancsokat.

Poolingot használtam az SMS-ek érkezésének lekérdezésére, azaz, rövid

időközönként rákérdeztem a GSM készülékre, hogy jött-e új SMS. Amennyiben igen,

kiolvastam a tartalmát

o itt történik meg az SMS vásárlás értelmezése

o a jegytípus, a vásárlási időpont és a megálló rögzítése

o a mobilszámhoz tartozó egyenlegről az összeg levonása

o a műveletek logolása

Majd ezen információk alapján összeállítom a válasz SMS-t:

o összeállítom a sztring üzenetet

o titkosítom a privát kulccsal

o datamatrixszá kódolom

o A datamatrix képpontjait az SMS formátumba rögzítem

o majd elküldöm ezt a válasz SMS-t

96

Az egész folyamat az alábbi ábrán szemléltethető (65. ábra):

SMS elküldése

V3;15

SMS szerver

SMS feldolgozása

- jegytípus

- vásárlási időpont

- megálló

- telefonszám

Fizetés és logolás

Összeg levonása a telefonszámhoz

tartozó egyenlegről.

Tranzakció rögzítése.

SMS üzenet összeállítása

V3;Arpad hid;200910111345

SMS titkosítása

x345345&@345đsdߣ##sdf

Datamatrix kód képzése

SMS kód összeállítása és

küldése

20x20;-22111142211…

SMS jegy megjelenítése

SMS jegy ellenőrzése

- Datamatrix képből adat kinyerése

- Titkosított adat dekódolása

- Szöveges adat megjelenítése az

ellenőr számára olvasható

formátumban

65. ábra: Elektronikus jegy vásárlásának és ellenőrzésének folyamata

97

Összefoglalás

Az elképzelhető megoldások a régi papír alapú utazási jegy vásárlást megvalósító rendszer

részleges vagy teljes leváltására korszerűbb eszközökkel:

Olyan eszköz kell, mely szinte majdnem mindenki számára kényelmesen, bárhol és

bármikor elérhető:

o Mobiltelefonon alapuló elektronikus jegyvásárlás.

SMS alapú jegyvásárlás

MMS alapú jegyvásárlás

WAP alapú jegyvásárlás

Interneten keresztül történő jegyvásárlás

Olyan eszköz kell, mellyel környezetkímélőbb módon tudjuk leváltani a régi papír

alapú rendszert, ezzel is támogatva a mai trendeket és kiemelve környezetbarát

profilunkat, melyekkel nagy EU-s pályázatok is elnyerhetőek.

A régi papír alapú utazási jegy vásárlására alkalmas rendszer leváltása és korszerűbbé

tétele elektronikus rendszerrel:

o Teljes leváltása

o Részleges leváltása

A különböző típusú jegyek és bérletek megvásárlása:

o Minden típus megvásárlása a típus számára létrehozott telefonszámon

történjen.

o Bizonyos vásárlói input szükséges a megfelelő típus megvásárlásához. Pl.:

JEGY1 szó elküldése az 1-es típusú vonaljegy megvásárlásához.

Támogatások elnyerése, mellyel ösztönözni lehet az embereket, hogy átálljanak az új

rendszerre:

o Állami támogatás olcsóbb szolgáltatásért

o Ingyenes segítségnyújtás(plakátokon, interneten stb.)

o Kedvezményes árú, speciális promóciós jegyek(összevont jegyek, családi

jegyek bizonyos alkalmakra stb.)

Web-es háttér kiépítése:

o Regisztrálni lehet pl. interneten keresztül vagy kihelyezett irodában, mellyel

sok újdonság érhető el (ez nem a mobiltelefonos jegyvásárlás egyik módja

lenne, hanem egy plusz szolgáltatás azon felül. Olyasmi, mint amikor

98

regisztrálunk egy weboldalra, létrehozunk saját profilt, pénzt tudunk

feltölteni a profilunkhoz a cég számlájára történő átutalással stb.)

Olcsóbb jegyvásárlási lehetőség, vagy speciális ajánlatok, hiszen

nyomon követhető, hogy rendszeres jegyvásárlók vagyunk, így

kifizetődő az utaztatási vállalatnak, hogy "költsön" ránk.

A szülők meg tudnák venni a gyerekeknek a havi bérletet, melyet a

cég SMS-ben minden hónapban elküld a megadott telefonszámokra,

illetve akár manuálisan is újrakérhető az SMS-jegy elküldése, ha

véletlenül kitöröltük volna.

Áthidalható az SMS-ben történő fizetés, hiszen interneten

támogatottak azok a protokollok, melyekkel biztonságosan tudunk

banki átutalást végezni.

Ki lehet váltani az utólagos bérletbemutatást az Akácfa utcában,

hiszen bizonyítható, hogy vettünk jegyet, csak telefon nem volt

nálunk, vagy csupán kitöröltük véletlenül az SMS-jegyünket.

További interneten alapuló szolgáltatással járó előnyök, mint pl. a

direkt marketing, reklámok stb.

Olyan szolgáltatás kiépítése szükséges, mely egyszerűen, gyorsan és fennakadás

nélkül ellenőrizhető a közlekedési vállalat ellenőrei által.

Kamerás beléptető rendszerek kialakítása a nagyobb megállóknál, így is spórolva az

emberi ráfordításon, és elősegítve a teljes automatizálást.

Szerveroldali lehetőségek:

o Mindenképp szükséges a közlekedési vállalattal való egyeztetés, hogy

elismerjék a szolgáltatásunkat, mint érvényes elektronikus jegy.

o Különböző emelt díjas SMS-ek lehetnek szükségesek.

o Interneten való regisztrációnak és egyenleg feltöltésének lehetősége a

szolgáltatás igénybevételéhez (pl.: Skype-on keresztüli mobiltelefon hívás is

így működik).

o Garázsprojekt:

Előfizetéses, SMS küldésére és fogadására alkalmas mobileszköz

vásárlása.

99

Valamilyen módon számítógéphez kapcsolása (pl.: soros portra vagy

USB-re kapcsolása kábellel, bluethooth stb.).

SMS üzenetek fogadása és küldése AT parancsokkal a számítógép

felügyeletével.

Különböző eseményvezérlők lefuttatása SMS-érkezése esemény

hatására.

o Szerződés kötése telefontársaságokkal:

Ők kezelik a teljes hálózati forgalmat.

Ők intézik az SMS-ek utáni összegek levonását.

A programozási feladatok ezen része ily módon majdnem teljes

egészében átugorhatóak.

o Szerződés kötése külsős céggel:

Szinte ugyan azok a lehetőségek, mint ha hazai telefontársaságokkal

kötnénk, csak a kockázatok változnak.

Fő szempontok lennének a következőek:

Többféle SMS-jegy létezzen, hogy a jelenleg használt papír alapú rendszert teljesen ki

tudja váltani (szakaszjegy, vonaljegy, bérlet stb.).

o Kérdéses itt, hogy vállalni akarjuk-e a kockázatot, hogy a drága jegyeket is,

mint például az éves bérletet, ily módon lehessen megvenni.

Mi történik, ha valakinek sikerül kijátszania az ellenőrző számokat, és

nemes egyszerűséggel tud gyártani magának vagy bárki másnak éves

bérletet.

Egy éves bérlet több 10.000 Ft lehet. SMS-en keresztül kényelmes és

biztonságos-e ilyen tranzakciók bonyolítása?

Telefonos előfizetőknek pillanatok alatt megugraszthatja a

havi telefonegyenlegét.

Nem előfizetőknek van-e elég pénze az egyenlegén a

tranzakció lebonyolításához?

Mi történik, ha véletlenül rossz számra(erre az éves bérlet

előfizetésére szolgáló telefonszámra) küldünk egy SMS-t?

(Talán ezért lehet jó megoldás bizonyos vásárlói input

elvárása, ráadásul így nem kell 20 féle telefonszámot fejben

tartani attól függően, hogy milyen jegyet akarunk venni.)

100

Mivel digitális jegyről van szó, maga a jegy tartalma viszonylag könnyebben

hamisítható. Ezért elengedhetetlen szempont a megfelelő védelem.

o Vagy olyan bonyolult kódolási algoritmus kell, melyet szinte lehetetlen

bruteforce-szal elfogadható időn belül visszafejteni.

o Vagy lehet egyszerűbb a kódolás, melyet akár szemmel is könnyű ellenőrizni,

ilyenkor viszont mindenképpen szükséges, hogy a jegy azonosítója

személyhez és időponthoz kötött legyen, ezek valamilyen központi szerveren

tárolva legyenek, mely adatokat az ellenőrök könnyen és gyorsan

lekérdezhetnek.

SMS alapú jegy:

o Valamilyen számokból és/vagy betűkből álló kód megfelelő-e:

Ha egyszerű a kódolása, könnyen visszafejthető az algoritmusa, és mi

magunk is gyárthatunk jegyeket.

Ha bonyolult a kódolása, időigényessé válhat az ellenőrzése

ellenőrök számára.

MMS alapú jegy:

o Könnyebb lenne képbe kódolni a jegy valódiságát:

Kamerás megoldással pontosabban ellenőrizhető az emberi szem

számára nem egyértelmű kódolás.

Átmenetileg alkalmazható lenne bizonyos egyezményes jelek

használata, amiket naponta vagy akár több óránként változtatnának,

így nehéz lenne a hamisítás, mert sosem tudni, épp mi lesz a

következő egyezményes jel.

o Drágább és nagyobb információ forgalommal jár a hálózatokon az MMS-ek

küldése és fogadása.

WAP alapú jegy:

o A Wireles Application Protocol anno nagy lépés volt, de manapság a 3G-s

telefonok elterjedésével szinte alig használják már.

o Mindenesetre statisztikai adatokat kielemezve talán érdemes lehet ennek a

protokollnak a támogatása is.

A mai smartphone-ok támogatják a széles sávnak köszönhetően az internetelérést és

a főbb protokollokat, így biztonságosan vásárolhatunk neten keresztül is, sőt

bizonyos esetekben egyes előfizetésekhez még akár olcsóbban is jön ki, mintha SMS-t

küldenénk.

101

Kockázatok a szerveroldali megoldásoknál:

o Kivitelezhetetlen a projekt, ha nem sikerül egyezségre jutni a felelős

közlekedési vállalattal.

o Ahhoz hogy ne egy normál SMS díját fizessék a vásárlók, elő kell szerződnünk

a telefontársaságokkal, hogy a mi számainkra küldött SMS-ek ilyen és ilyen

árú emeltdíjas SMS-ek legyenek, melyek a vásárló számlájáról történnek

levonásra.

o Garázsprojekt:

Kis felvásárlói körnél még megoldható, de már több 100 fős SMS-

rendelés felett is szinte biztos, hogy nem tudjuk megoldani a hálózati

terhelést.

Nekünk kell állni az SMS küldés anyagi vonzatait.

Nekünk kell utánajárnunk a saját profitunknak, azaz, hogy az SMS

küldés árát fedezzük, illetve hogy még jól is járjunk vele.

Amennyiben kötelezővé tesszük az internetes regisztrációt és

egyenlegfeltöltést, úgy átugorhatjuk a telefontársaságokkal való

szerződést emeltdíjas SMS-ekre és a saját profitunkra vonatkozóan.

Az ilyesfajta "rákényszerítés", hogy egy új módszert

bevezessünk, szinte biztos, hogy a kezdeti stádiumban nem

fog robbanni, és ha be is indul, csak nagyon lassan lesz

számottevő felvásárlói kör növekedés.

o Szerződés kötése telefontársaságokkal:

Egyeztetni kell mindegyik szolgáltatóval, és szerződésben rögzíteni a

feltételeket.

Garantálni kell a telefontársaságoknak bizonyos forgalmat, különben

azt mondják, nem éri meg nekik.

Hatalmas haszonkulcsot tesznek rá a telefontársaságok, mellyel

rontják a:

Mi saját profitunkat, hiszen horribilis árért senki nem fogja

használni a szolgáltatásunkat.

Felhasználók hajlandóságát, hogy drágább elektronikus

jegyet vegyenek.

pl.: budapesti parkolási jegyek már SMS-ben is

vásárolhatóak: kb. 40-70 Ft a plusz díj, amit fizetnünk kell a

telefontársaságok miatt.

102

Programozási feladat szinte kizárólag csak a digitális jegy kódolása

marad.

o Szerződés kötése külsős céggel:

Nem kell minden telefontársasággal külön-külön egyeztetni és

szerződni.

Nem kell a telefontársaságok magas haszonkulcsát is beleszámítani

az elektronikus jegyek árába.

Nem kell bizonyos forgalmat garantálni ahhoz, hogy egyáltalán szóba

álljanak velünk.

A külsős cég árai lehetnek akár olcsóbbak, akár drágábbak is.

Szerződni kell, hogy biztosra menjünk, a pár 10 főstől akár a több

10000-es felhasználói kör kiszolgálására is megvan a megfelelő

infrastruktúrájuk.

Megmutattam elvont és gyakorlati megközelítésből a vonalkódok alkalmazását elektronikus

vásárlások területén, hogy milyen lépések szükségesek a téma feltérképezésére, és mikre

érdemes odafigyelni. A munkám olvasása során apránként álltak össze az elmélet különböző

részegységei, mint kis építőkockák, és a végén ezekből az összetevőkből, és alaposan

körbejárt és részletezett érvekből sikerült felépítenem egy kétdimenziós Datamatrix

vonalkóddal működő, utazási jegyek vásárlására lehetőséget adó, elektronikus rendszert.

103

Köszönetnyilvánítás

Köszönettel tartozom Tihanyi Professzor Úrnak a tanácsokért és bíztatásért, továbbá

hogy mindig számíthattam rá, még az utolsó pillanatokban is. Nagyon sokat tanultam abból,

hogy egy ilyen remek szakember kezei alatt dolgozhattam. És köszönöm Takács Professzor

Úrnak, hogy a csapat része lehettem, és hogy mindig bizalommal fordulhattam hozzájuk.

Nélkülük ez a munka nem jöhetett volna létre.

104

Irodalomjegyzék

[1] Allaga Gyula-Melis Zoltán-Sárkány Márta-Viszkey György —

Vonalkódtechnika: Automatikus azonosítás elméletben és gyakorlatban,

PRIM kiadó, 1995

[2] Wikipedia — Barcode: http://en.wikipedia.org/wiki/Barcode

[3] OPENBARCODES project — http://grandzebu.net/index.php

[4] The Barcode Software Center — http://www.makebarcode.com/specs/speclist.html

[5] KAYWA Reader — http://reader.kaywa.com/getit

[6] data matrix & qr codes — http://213.162.106.178/qrcodes.html

[7] IDAUTOMATION — http://www.idautomation.com/fonts/tools/sourcecode/

[8] libdmtx — http://www.libdmtx.org/

[9] Create a Data Matrix Symbol —

http://home.hiwaay.net/~csewell/CreateADMx.shtml

[10] Barcode Reading System using Image processing —

http://www.atilim.edu.tr/%7Emisafran/proje%20web/project.htm

[11] BarCode 1 — http://barcode-1.org/pub/russadam/stack.html

[12] SIEMENS — http://www.acuitycimatrix.com/Create%20DM.html

[13] SIEMENS — http://www.acuitycimatrix.com/Organizations.html

[14] BARCODE SYMBOLOGIES — http://www.barcodeisland.com/symbolgy.phtml

[15] Adobe Flash Lite — http://www.adobe.com/products/flashlite/

[16] Adobe Flash — http://www.adobe.com/products/flash/

[17] Symbian OS — http://www.symbian.com/

[18] Java, Sun Microsystems — http://java.sun.com/

105

[19] American Morse Code —

http://www.answers.com/topic/american-morse-code

[20] Tangible Software Solution, Inc. — http://tangiblesoftwaresolutions.com/

[21] „QR-kód: a szkennelhető web”, CHIP Magazin, pp. 28-29, May 2008

[22] Semacode Datamatrix — http://semacode.com/

[23] Google ZXing projekt — http://code.google.com/p/zxing/w/list

[24] Choosing the best 2D barcode format for mobile apps —

Semacode 2006 technical white paper

[25] A Concept of Using 2D Bar Codes in Retail Environmenat — Per Jonsson

[26] MID UI Issues and Suggestions —

http://software.intel.com/en-us/articles/mid-ui-issues-and-suggestions?cid=sw:mobile019

[27] Hamming-távolság —

http://hu.wikipedia.org/wiki/Hamming-t%C3%A1vols%C3%A1g

[28] Chapter 26. Datamatrix (2D-Barcode)—

http://hem.bredband.net/aditus/chunkhtml/ch26.html

[29] Short Message Service / SMS Tutorial — http://www.developershome.com/sms/

[30] Java Communication API — http://java.sun.com/products/javacomm/

[30] Rafael C. Gonzalez, Richard E. Woods, Digital Image Processing, 3d ed. New Jersey:

Pearson Prentice Hall, 2008, pp. 394-456 (Color Image Processing chapter)

[31] Rafael C. Gonzalez, Richard E. Woods, Digital Image Processing, 3d ed. New Jersey:

Pearson Prentice Hall, 2008, pp. 627-680 (Morphological Image Processing chapter)

[32] Eclipse — http://eclipse.org/

[33] Android SDK — http://developer.android.com/index.html

106

Mellékletek

A diplomamunkához csatolt CD-n a következők találhatóak:

1D barcode

o Az egydimenziós UPC-A vonalkódot olvasó és író Flash alkalmazás futtatható

fájlokkal, forráskóddal és a szótárfájllal.

DATAMATRIX képek

o Tesztképek a kép detekciós algoritmusaimhoz

DataMatrix_Recogniser

o A kép detektáló algoritmusokhoz írt Java-s keretrendszerem.

SMS_Server

o Java Communication API-t és kiegészítő .dll-eket használó Java nyelven írt

SMS szerver. (Önmagában, GMS készülék, és megfelelő SIM kártya nélkül

nem használható.)

SMSToDatamatrix

o Android operációs rendszerre írt SMS-t Datamatrixként megjelenítő

mobilalkalmazásom

AT_Hyperterminal.txt

o GSM készülék, megfelelő SIM kártya és hyperterminál használatával AT

parancsnyelven küldött SMS tesztüzenet. (PIN kikommentezve)

Diploma_SzilvássyBalázs.pdf

o Diplomamunkám pdf formátumban.