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.
1
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.
2
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)
3
Pázmány Péter Katolikus Egyetem Információs Technológiai Kar Tanulmányi Osztály 1083 Budapest, Práter u. 50/A
[email protected]
Tel/Fax: 886-4700
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
4
E-mail:
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.
5
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 6
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
7
Ábrajegyzék 1. ábra: Egydimenziós vonalkód 2. ábra: Kétdimenziós vonalkód 3. ábra: A vonalkódok fejlődése 4. ábra: Morse-kódtáblázat 5. ábra: Vonalkód összehasonlító táblázat 6. ábra: Általános vonalkód felépítése 7. ábra: Diszkrét kódolás 8. ábra: Folytonos kódolás 9. ábra: CODE 39 típusú, minta vonalkód 10. ábra: Vonalkódok sokszínűsége 11. ábra: UPC-A vonalkód 12. ábra: UPC-A vonalkód rendszerazonosítói 13. ábra: UPC-E vonalkód 14. ábra: EAN-13 vonalkód 15. ábra: EAN-8 vonalkód 16. ábra: UPC kiegészítő kódolás 17. ábra: Standard 2 of 5 vonalkód 18. ábra: Interleaved 2 of 5 vonalkód 19. ábra: Szélesség modulált vonalkód 20. ábra: Codebar vonalkód 21. ábra: Code 39 vonalkód 22. ábra: Ál-kétdimenziós vonalkód 23. ábra: Saját egydimenziós vonalkód író és olvasó programom 24. ábra: Saját egydimenziós vonalkód író/olvasó programom szkennelés közben 25. ábra: Saját egydimenziós vonalkód író és olvasó programom szótárfájlja 26. ábra: Kétdimenziós vonalkódok [11] 27. ábra: A kétdimenziós datamatrix vonalkód tulajdonságai 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 30. ábra: Információkódolás folyamatábrája 31. ábra: Információkódolási folyamatábra Datamatrix esetén 32. ábra: QR kód hibajavítási szint táblázat 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 35. ábra: Datamatrix vonalkódot író és elmentő alkalmazás 36. ábra: Google ZXing Java SE változata újrafordítva működés közben 37. ábra: KaywaReader, mobiltelefonos alkalmazás 38. ábra: Teszt-keretrendszerem kezelőfelülete 39. ábra: Teszt-keretrendszerem képmegjelenítője 40. ábra: Teszt-keretrendszerem clusterező algoritmusának végeredménye 41. ábra: Teszt-keretrendszerem befoglaló négyzet számítás utáni eredménye 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 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 8
21 21 22 25 26 26 28 28 29 30 31 31 32 32 33 33 34 34 35 35 36 37 38 39 40 42-44 45-46 47 47 49 51 53 54 54 55 56 58 63 64 64 65 66 66 67 67
46. ábra: Teszt-keretrendszerem eredményképe clusterezés után 47. ábra: Teszt-keretrendszerem véglegesnek tekinthető eredményei 48. ábra: Teszt-keretrendszerem egy alternatívája módosított él-kereséssel 49. ábra: Tesztképek a keretrendszeremhez 50. ábra: Nem-funkcionális követelmények és mérésük 51. ábra: Egy lehetséges használati eset UML diagram 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 55. ábra: Szerverre befutó igény adatfolyam modellje 56. ábra: Az elektronikus mobiljegyek rendszerének rétegezett architektúra modellje 57. ábra: Az ellenőr oldali alrendszerek UML diagramja 58. ábra: A szerver oldali alrendszerek UML diagramja 59. ábra: Tesztelési lépések folyamatábrája a rendszer fejlesztésekor 60. ábra: Az Androidos mobilalkalmazásomhoz használt teszt datamatrix 61. ábra: Datamatrix kapacitástáblázata a különböző formátumokra [28] 62. ábra: Külön futási szálon végrehajtott SMS jegy értelmezés 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 65. ábra: Elektronikus jegy vásárlásának és ellenőrzésének folyamata
9
68 68 69 71 74 76 78 78 78 79 79 81 81 82 87 88 89 90 90 96
Ö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 10
é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.
11
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.
12
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
13
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.
14
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.
15
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
megakadályozására.
16
ki
a
digitális
jegyek
hamisításának
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. 17
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.
18
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 karakterfelismeré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 19
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). 20
1. ábra: Egydimenziós vonalkód
2. ábra: Kétdimenziós vonalkód
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ódtechnoló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 21
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].
3. ábra: A vonalkódok fejlődése: (egydimenziós-, ál-kétdimenziós-, kétdimenziós-, dombornyomott vonalkód)
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
22
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.
23
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.
24
4. ábra: Morse-kódtáblázat
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]: 25
Vonalkód
Modul-mérete
típus
Jelpárok
Kódolható
Felhasznált
Biztonsági
száma
karakterszám
karakterszám
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
5. ábra: Vonalkód összehasonlító táblázat
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
6. ábra: Á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 26
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
27
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).
7. ábra: Diszkrét kódolás
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).
8. ábra: Folytonos kódolás
28
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:
9. ábra: CODE 39 típusú, minta 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/ 29
Egy másik példa a létező és használatos vonalkódok sokszínűségére (10. ábra):
10. ábra: Vonalkódok sokszínűsége
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 2szá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 30
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):
11. ábra: UPC-A vonalkód
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 12. ábra: UPC-A vonalkód rendszerazonosítói
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). 31
13. ábra: UPC-E vonalkód
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.
14. ábra: EAN-13 vonalkód
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.
32
15. ábra: EAN-8 vonalkód
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].
16. ábra: UPC kiegészítő kódolás
33
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.
17. ábra: Standard 2 of 5 vonalkód
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.
18. ábra: Interleaved 2 of 5 vonalkód
34
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).
19. ábra: Szélesség modulált vonalkód
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.
20. ábra: Codebar vonalkód
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).
35
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.
21. ábra: Code 39 vonalkód
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
36
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
37
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
38
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
39
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
40
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 egymind 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.
41
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
42
Datastrip Code
Dot Code A
MaxiCode
MiniCode
PDF 417
QR Code
Snowflake Code
43
Datamatrix
26. ábra: Kétdimenziós vonalkódok *11+
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].
44
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.
45
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.
27. ábra: A kétdimenziós datamatrix vonalkód tulajdonságai
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. 46
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).
28. ábra: A kétdimenziós datamatrix vonalkód magas szintű kódolása
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):
29. ábra: A datamatrix vonalkód diagonális menti bejárása
47
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. 48
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. u üzenet vektorhoz hozzárendelünk egy szabad c kódszót, vagy generálunk egyet
Üzenet: u
Kódszó: c c-t átküldjük a csatornán
e zajvektor hozzáadódik
Zaj: e
zajos csatorna
a csatorna végén vett v vektor: v = c + e
Dekódolt üzenet: u’
Vett üzenet: v hibajavított és dekódolt u’ üzent előállítása 30. ábra: Információkódolás folyamatábrája
49
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
50
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):
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)
ASCII üzenet „hello”
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.
ASCII vett üzenet „hello” Datamatrix vonalkód megépítése az adatokból négyzetes vagy téglalap alakú formában.
Dekódolás és hibajavítás
Datamatrix adat 0110110101 1000110110 1101100100 1010000000 stb.
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.
31. ábra: Információkódolási folyamatábra Datamatrix esetén
51
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.
52
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 ReedSolomon 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 32. ábra: QR kód hibajavítási szint táblázat
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 53
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+.
33. ábra: QR kód és Datamatrix helyigényét összehasonlító táblázat
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.
34. ábra: QR kód és Datamatrix méretbeli különbsége
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.
54
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
55
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 2008as, 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
56
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.
57
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+
37. ábra: KaywaReader, mobiltelefonos alkalmazás
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: 58
-
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.
o
Használjunk teljes képernyőméretet, ha lehetséges.
Gondosan tervezzük meg a felhasználói felületet.
Nem férnek el a párbeszédablakok a képernyőn
o
Igyekezzünk kis méretű párbeszédablakokat alkalmazni.
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
o
A felhasználói felületen keresztül gyakran kérünk input-ot
o
Használjunk görgetősávokat.
Ahol lehet, használjuk a hardware-es gombokat.
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
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.
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. 59
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
o
Cache-eljük az adatokat.
Adatvesztés, adatbiztonság
Használjunk
biztonsági
megoldásokat
a
kényes
adatok
továbbítására. o
Használjuk a lokális cache-t míg a szerver nem verifikálja magát.
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.
60
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.
61
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.
62
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
63
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).
39. ábra: Teszt-keretrendszerem képmegjelenítője
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).
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
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].
65
42. ábra: Teszt-keretrendszerem eredményképei binearizálás után
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).
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
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].
45. ábra: Teszt-keretrendszerem eredményképe szándékosan rosszul paraméterezett vonalkódkeresésre
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.
67
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).
46. ábra: Teszt-keretrendszerem eredményképe clusterezés után
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).
47. ábra: Teszt-keretrendszerem véglegesnek tekinthető eredményei
68
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.
48. ábra: Teszt-keretrendszerem egy alternatívája módosított él-kereséssel
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. 69
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
70
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
71
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.
72
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. 73
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
74
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. 2. 3. 4.
A felhasználó megérkezik egy BKV megállóhoz. Jegyet szeretne vásárolni elektronikusan. BKV megállóban a leendő utas SMS-t küld a BKV megadott telefonszámára 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.
75
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.
51. ábra: Egy lehetséges használati eset UML diagram
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).
76
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.
77
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):
52. ábra: Ellenőrzés folyamatának adatfolyam modellje
Napi kód lekérése: ellenőr adatfolyam modellje (53. ábra):
53. ábra: Adatfolyam modell az ellenőr napi kódlekérdezésének folyamatáról
Napi kód lekérése: központi adatfolyam modell (54. ábra):
54. ábra: Szerver oldali adatfolyam modell
78
Szerver oldalon beérkező igénylés adatfolyam modellje (55. ábra):
55. ábra: Szerverre befutó igény adatfolyam modellje
A rendszer rétegezett architektúra modellje (56. ábra):
56. ábra: Az elektronikus mobiljegyek rendszerének rétegezett architektúra modellje
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
o
Biztonsági másolatok készítését végző időzített alprogramok
Telefonhálózati interfész
Bejövő SMS-ek fogadására szolgáló alrendszer
79
o
Kimenő SMS-ek küldését szolgáló alrendszer
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 o
o
Hibaelhárítás
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
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
o
Ellenőrzési feladatokat kiszolgáló szubrutinok
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
80
Ellenőr oldali alrendszerek UML-je (57. ábra):
57. ábra: Az ellenőr oldali alrendszerek UML diagramja
Szerver oldali alrendszerek UML-je (58. ábra):
58. ábra: A szerver oldali alrendszerek UML diagramja
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, 81
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):
59. ábra: Tesztelési lépések folyamatábrája a rendszer fejlesztésekor
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
82
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 nemfunkcioná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.
83
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 84
á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 SMSjegy 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 85
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. )
86
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ő SMSekrő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):
60. ábra: Az Androidos mobilalkalmazásomhoz használt teszt datamatrix
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. 87
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 20x20as 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]
88
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, 22.2
2
egy
22x22-es
datamatrix
adatcelláinak
összes
lehetséges
változata
20
=2 =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
89
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)
63. ábra: A tárolt SMS jegyek megjelenítése
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):
64. ábra: A tárolt SMS jegyek megjelenítése kétdimenziós Datamatrix vonalkódként
90
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
91
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űkszá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.) 92
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)
93
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. 94
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
95
Az egész folyamat az alábbi ábrán szemléltethető (65. ábra):
SMS elküldése V3;15
SMS jegy megjelenítése
SMS szerver
SMS jegy ellenőrzése -
SMS feldolgozása
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
-
jegytípus vásárlási időpont megálló telefonszám
SMS kód összeállítása és küldése
Fizetés és logolás
20x20;-22111142211…
Összeg levonása a telefonszámhoz tartozó egyenlegről. Tranzakció rögzítése.
Datamatrix kód képzése
SMS titkosítása
SMS üzenet összeállítása
x345345&@345đsdߣ##sdf
V3;Arpad hid;200910111345
65. ábra: Elektronikus jegy vásárlásának és ellenőrzésének folyamata
96
Ö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 97
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.
98
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.) 99
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.
100
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 SMSrendelé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. 101
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.
102
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.
103
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/ 104
[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
105
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.
106
