TagTrace Handheld En håndholdt klient til RFID scanning

Transkript

1 TagTrace Handheld En håndholdt klient til RFID scanning Niels Simonsen Brinkø Kongens Lyngby 2009 IMM-B.Eng

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax

3 Forord Denne rapport er resultatet af det afsluttende eksamensprojekt på Diplom IT på Danmarks Tekniske Universitet. Den er udført i tidrummet 1. februar 2009 til 12. juni Formålet med opgaven er at vise den studerendes kompetencer og færdigheder inden for softwareudvikling, herunder analyse, design, implementering og test. Projektet udføres i samarbejde med 2Trace A/S. Rapporten er underlagt DTUs standardaftale for Diplom- og Kandidateksamensprojekter. i

4 Indhold Forord i 1 Indledning 1 2 Projektbeskrivelse RFID TagTrace TagTrace Handheld Arbejdsmetode Analyse TagTrace Overordnet Systemsammenhæng Use Cases Supplerende Kravspecifikation Domænemodel Design Softwarearkitektur GUI Forretningslogik Data Implementering Opbygning GUI ii

5 INDHOLD iii 5.3 Forretningslogik Data Test Scanning Skrivning af RFID tag Visning og Tilføjelse af information Webservice Generelt Supplerende Kravspecifikation Konklusion 51 A Grafik 53 B Screenshots 57 C CD 61

6

7 KAPITEL 1 Indledning Når varer i nutidens lagerløsninger flyttes rundt, foregår meget af registreringsarbejdet manuelt. Det involverer en medarbejder der registrerer hvor en bestemt vare er. Flere og flere lagerbygninger får lokationsbaseret lagerstyring for at optimere pladsen. Dette indebærer at en medarbejder skal scanne en stregkode på lokationen, hvor et produkt placeres, for at registrere hvor produktet er lagerført. Når produktet senere skal findes igen, er det blot at lave et opslag og finde hvilken lokation det sidst blev placeret på. Når produktet plukkes (afhentes) på lokationen registreres det igen og systemet ved nu, at det er blevet flyttet. Dette medfører en række manuelle arbejdsgange og fejlkilder i form af forkerte og glemte scanninger. Scannes et forkert produkt eller en forkert lokation kan det være svært, hvis ikke umuligt, at lokalisere det igen senere. Systemerne findes dog, er i brug mange steder. Problemet opstår, når produktet skal lastes i en container, trailer eller lastbil. Med de nuværende systemer er det medarbejderens ansvar at et produkt køres til den rigtige port. Med et RFID tag monteret på et produkt, kan der monteres en RFID læser på hver port som registrerer produkterne der bevæger sig igennem. Når et produkt registreres, kan der straks gives et signal til medarbejderen om produktet flyttes et korrekt sted hen eller om det flyttes til et forkert sted. Programmet TagTrace er udviklet til stationære og truckmonterede RFID læsere, og 1

8 2 KAPITEL 1. INDLEDNING er specialiset til, at formidle data mellem RFID enheder og eksisterende lager- og økonomistyringssystemer. Det ønskes at udvide TagTrace med en håndholdt terminal, der kan bruge RFID tags til at erstatte den funktionalitet der ligger i stregkoder på et lager. Efterhånden som produkter forsynes med RFID, vil der blive brug for små håndholdte computere, der kan læse RFID og stregkoder. Derfor ønsker 2Trace at der implementeres en prototype på en håndholdt klient der kan vise at teknologien virker og at denne kan kommunikere med det nuværende TagTrace. Den udviklede prototype viser, at det absolut er muligt at bruge det bagvedliggende TagTrace system til at udvikle en håndholdt løsning. Programmet er udviklet i Visual Studio 2008,.net Compact Framework og det er skrevet i C#. Der benyttes en webservice, til at stille noget af TagTrace databasens funktionalitet til rådighed for den håndholdte enhed. Da enheden ikke benytter nogen former for caching, skal alle dataforespørgsler foregå over netværket til databasen. Dette medfører at enheden, i det nuværende stadie, ikke kan arbejde uden netværksforbindelse. Det betyder også at visse opslag kan tage længere tid at udføre end hvad hensigtsmæssigt er. Programmet fremstår som en prototype, og der mangler derfor en del udvikling for at gøre det produktionsklar. Begreber som sikkerhed, caching og fejltolerance er ikke blevet diskuteret og det vil derfor være oplagt at begynde med disse, hvis programmet skal laves færdigt.

9 KAPITEL 2 Projektbeskrivelse 2.1 RFID Radio Frequency Identification (RFID) eller mere præcist passiv RFID er en teknologi der muliggør læsning af information om et produkt på samme måde som en stregkode bruges i dag. RFID fungerer ved at man monterer/klistrer et tag fast på et produkt. Dette tag indeholder en antenne samt en chip. Når antennen bevæger sig ind i et radiofelt vil der blive genereret strøm til chippen. Chippen kan herefter sende et svar eller blive skrevet med en ny værdi. Chippen behøver ikke være synlig og har derfor ikke de samme svagheder som en stregkode. RFID har eksisteret og været brugt i industrien i mange år, men på lavere frekvenser (LF, Low Frequency og HF, High Frequency) der har brugt det magnetiske felt i radiobølgerne til at opbygge energi. Dette har bevirket at aktiverings- og læseafstanden har været meget kort (omkring 50 cm) 1. I de senere år er der blevet udviklet rfid teknologi baseret på højere frekvenser (uhf, ultra high frequency) der benytter det elektriske felt i radiobølgerne 2. Dette bevirker at aktiverings- og læseafstanden er oppe på 4-5 m og giver samtidig mulighed for at læse flere hundrede tags af gangen. Dette gør derfor teknologien mere interessant for mærkning af varer, kasser, 1 Teknologisk Institut: 2 rfidusa.com, side 11 i 3

10 4 KAPITEL 2. PROJEKTBESKRIVELSE paller, bure og containere. Desværre giver den højere frekvens også problemer i forbindelse med skærmning. Et højfrekvent signal er ikke egnet til at gennemtrænge materialer og et UHF RFID tag placeret på væsker eller metal vil derfor ikke kunne læses. Hvis det ønskes at læse UHF RFID tags på disse materialer kræver det specielle hensyn eller tags. Fx bliver et tag placeret med lidt afstand (1-4 cm) til metal ikke dæmpet, men vil i mange tilfælde blive forstærket, da metallet udnyttes som reflektor. RFID tags indeholder et identifikationsnummer, på samme måde som en stregkode. Derudover er der også mulighed for at skrive ekstra data til et seperat område. Identifikationsnummeret på et RFID tag kan omkodes til et EAN128 stregkodeformat og RFID kan derfor meget nemt indgå i et allerede eksisterende system. I logistikbranchen findes der en fælles organisation, GS1, der står for udvikling og standardisering af stregkodeformater, dataformater og nu også RFID tags. Hvis en virksomhed ønsker at få en GS1 godkendt stregkode, skal virksomheden tilmeldes og får herefter tildelt et virksomhedsnummer, dette nummer vil indgå i virksomhedens stregkoder. Der findes stregkoder til stort set alle formål inden for logistikbranchen, helt fra simpel mærkning af et produkt med et produktnummer til avanceret mærkning af paller med informationer om batchnummer, udløbsdato, afsender, modtager og mange andre informationer. De fleste af disse stregkoder kan oversættes direkte til det format et RFID tag anvender og derfor kan RFID tags bruges i en virksomheds eksisterende systemer. RFID tags tages i første omgang primært i brug til pallemærkning. Pallemærkning er naturligt at vælge ud fra overvejelsen om prisen på det emne man ønsker at mærke. Paller indeholder mange produkter og har derfor en stor egenværdi og kan mærkes uden at den samlede pris stiger nævneværdigt. Et eksempel på et sted, hvor RFID vil fordyre et produkt, er en pakke gær til 25 øre mærket med et tag til 75 øre. De fleste steder vil RFID tags blive læst af en stationær RFID reader, ofte i forbindelse med en port, en gate. En RFID gate kan læse RFID tagget på et produkt mens det bevæger sig igennem, dette bevirker at personen der flytter produktet ikke behøver stoppe op for at registrere at produktet nu har flyttet sig til et andet sted. 2.2 TagTrace TagTrace er et RFID middleware program. Programmet hjælper med at implementere RFID på en simpel og enkel måde i eksisterende systemer. TagTrace sørger for at en virksomhed, uden at skifte økonomi- eller lagerstyringssystem, kan indføre RFID. Diagram over TagTraces sammenhæng med omkringliggende systemer kan ses i bilag A.3.

11 2.3. TAGTRACE HANDHELD 5 TagTrace tager sig af al kommunikation med RFID læsere og printere og kan tilpasses, så data fra RFID systemet sendes til virksomhedens eksisterende system på en måde som dette kan håndtere. TagTrace understøtter flade filer, webservices, databaser mm. TagTrace har et egenudviklet protokollag, der sørger for nem overgang mellem forskellige producenter af udstyr. TagTrace understøtter en avanceret scripting model, med scripts skrevet i C#, som placeres i databasen og kompileres ved program start. Disse scripts kan kobles direkte på den interne eventstruktur og kan derfor fungere som en normal komponent i det kørende system. Det primære formål med disse scripts er at filtrere indkommende RFID tags, samt styre de enkelte RFID readere og deres perifære enheder. TagTrace tilbyder desuden et web interface til nem overvågning af virksomhedens RFID installation og forretningsprocesser. Webinterfacet tilpasses delvist den enkelte kunde, for herved at give kunden den mest hensigtsmæssige måde at vise og manipulere data. Der er desuden en proof-of-concept (POC) klient til debugging og visning af realtidsdata. Klienten snakker direkte med TagTrace applikationen og kan manipulere opsætninger samt sende beskeder til forbundne enheder. POC klienten bruges desuden til at diagnosticere hvor god læserate en port kan præstere, ved at benytte signalstyrke samt hvilken antenne der læses fra. Ud fra disse oplysninger kan dårlige læsninger og døde områder findes. Alle data i TagTrace gemmes i en database. Denne database indeholder information som sammenkædning mellem produkter, RFID tags, grupperinger og bevægelser, oplysninger og opsætninger af enheder (RFID reader, printere mm), log filer for TagTrace og information om fysiske lokationer. Databasen er en Microsoft SQL Ser-ver 2005 og kan efter behov og forhold køres på Microsoft SQL Server 2005 Express Edition eller på en fuld skala Microsoft SQL Server. 2.3 TagTrace Handheld Formålet med TagTrace Handheld (TTH) er at kunne flytte funktionaliteten fra TagTrace ud til en håndholdt klient der kan tages med rundt på et lager eller i en butik. TTH skal kunne læse og håndtere stregkoder og RFID tags. Informationer omkring stregkoder og tags skal kunne hentes fra TagTrace serveren og vises i et overskueligt format på skærmen. En indlæst stregkode eller RFID tag skal kunne håndteres af TTH på samme måde

12 6 KAPITEL 2. PROJEKTBESKRIVELSE som TagTrace håndterer et RFID tag læst på en normal gate. TTH skal yderligere give mulighed for at oprette et nyt tag i TagTrace databasen, samt indtaste ekstra information om et givent tag. 2.4 Arbejdsmetode Da virksomhedens software ikke udvikles til internt brug vil det normalt være en kunde der stiller kravene, dette projekt har dog ingen kunde og udvikles derfor efter krav udarbejdet af virksomhedsvejleder samt den studerende. I virksomheden benyttes en Unified Process (UP) lignende udviklingsmodel. Udviklingen er ofte præget af at kunden ikke kender de præcise krav til systemet på forhånd og de krav der var stillet kan ændre sig undervejs. Det er derfor vigtigt for 2Trace at kunne inddrage kunden og fremvise delvist færdige implementeringer og få feedback på disse. Udviklingsmetoden læner sig derfor op af UPs brug af iterationer. Det er valgt, på baggrund af virksomhedens normale arbejdsmetoder, at bruge UP. Mange af principperne i UP kan sammenlignes med dem, der allerede bruges i virksomheden og virksomhedsvejlederen vil derfor have en bedre chance for at følge med og give kvalificeret vejledning Unified Process Unified Process (UP) er en meget brugt udviklingsmetode, den er ofte benyttet ved objektorienteret softwareudvikling. UP benytter sproget UML til at beskrive hvordan en given ting skal udvikles. UP består af fire udviklingsfaser: Inception, Elaboration, Konstruktion og Transition. Alle faser er iterative. Inception benyttes til at finde de generelle ideer og krav der skal stilles til systemet. Under denne fase udarbejdes use cases over de forskellige krav. Inceptionsfasen giver et beslutningsgrundlag for, om det er fornuftigt at fortsætte med projektet eller om det skal forkastes. Desuden giver det grundlag for en løs tidsestimering. Elaboration benyttes til at vælge en arkitektur samt til at tage en endelig beslutning om krav til systemet. Herunder færdiggøres analyse og design af systemet. Der bør desuden udvikles de vigtigste dele af systemet, ud fra tidligere use cases, for at give et endeligt beslutningsgrundlag for, om projektet stadig er muligt at udføre. Konstruktion bruges til at færdiggøre implementeringen af systemet. Det er i denne fase at små og mindre vigtige dele udvikles. Desuden er det vigtigt at udføre test

13 2.4. ARBEJDSMETODE 7 mens udviklingen foregår, så eventuelle fejl kan fanges. Dokumentation og manualer skal også påbegyndes. Transition bruges til at udføre betatest samt aflevering til slutbrugere. Enkelte fejl kan findes her og skal i så fald rettes i denne fase. Der bliver ikke tilføjet nye ting Backup og Versionsstyring Alle data der arbejdes på i projektet gemmes på en subversion server, dette bevirker at man til enhver tid kan gå tilbage i projektet og finde gamle eller slettede filer frem igen. Der laves daglig backup af subversion serveren. Som en del af subversion oprettes der en lokal kopi hver gang data på en klient opdateres. Dette bevirker at selvom server samt backup forsvinder, findes der stadig en stor del af data på alle klientmaskiner.

14 8 KAPITEL 2. PROJEKTBESKRIVELSE Tidsplan Da projektet har en relativt kort tidsfrist og da der kun er en person til at analysere, designe, dokumentere og udvikle vil UP principperne ikke blive overholdt fuldt ud. I tidsplanen vil der kun blive plads til een iteration, hvor der burde være flere. Selvom der kun er en iteration vil der dog stadig være mulighed for at fange fejl og ændre disse undervejs. Tidsplanen er tidligt i projektet estimeret vha. en procent sats for hvert større område. Inddelingen kan ses i figur 2.1. Figur 2.1: Estimeret arbejdsbyrde per område Tidsplanen er senere i projektet lagt mere fast. Til dette er der benyttet et Gantt diagram som kan ses i figur 2.2 og 2.3.

15 2.4. ARBEJDSMETODE 9 Figur 2.2: Tidsplan - Gantt Figur 2.3: Tidsplan - Datoer

16

17 KAPITEL 3 Analyse 3.1 TagTrace TagTrace består af en service der kører på en dedikeret server. Desuden har TagTrace en webløsning, der gør brug af Microsoft Internet Information Server (IIS) TagTrace Arkitektur TagTrace er opbygget omkring en modulopbygget, eventbaseret struktur. Dette betyder at ethvert modul kan lytte til en event eller udløse en event. TagTrace har flere typer events, den mest brugte er Command-eventen. Denne event modtager et CommandEvent objekt, som er opbygget så det kan extendes af andre objekter. CommandEvent objektet indeholder forskellige standardmetoder og -værdier, heriblandt modtager, synkronisering af tråde og mulighed for at få en kvittering efter at eventen er udført. Command-events kan udføres synkront og asynkront alt efter behov, dette styres af den der udløser eventen. Da disse objekter alle vil have CommandEvent objektet som fællesnævner, kan de 11

18 12 KAPITEL 3. ANALYSE sendes på Command-eventen og modtagere af eventen kan herefter checke at de er den korrekte modtager og hvilken type udvidelse der er tale om. En anden vigtig event der bør nævnes er Tag-eventen. Denne kaldes når et eller flere nye tags er set på en RFID reader. Denne event er valgt adskilt fra Commandeventen, da en tag-event kan forekomme meget ofte (op til flere hundrede gange per sekund). TagTrace indeholder en avanceret scripting udvidelse, scripts er skrevet i C# og gemmes i databasen. Udvidelsen gør det muligt for en kunde at tilpasse hvad der sker, når fx. programmet starter eller når et tag er set. Scriptet gør det muligt at modtage og udløse de samme events som systemet ellers benytter. Scriptets hovedformål er at tilbyde opbygning af avanceret logik til håndtering af rfid tags. Dette gøres ved at lade RFID readernes protokolobjekter udløse en scriptingevent med en liste af modtagne tags i. Hvilket script der skal udføres, er defineret i RFID readerens konfigurationsfil. Da TagTrace skal kunne kommunikere med mange forskellige typer enheder der alle bruger forskellige prokoller, er der opbygget en generisk protokolstruktur. Protokolstrukturen indeholder en server- samt en klientdel og al kommunikation foregår asynkront. En protokol opbygges ved at bygge ovenpå enten klient- eller serverdelen, da disse indeholder hvad der kræves for at sende, modtage og vedligeholde en forbindelse. Det er derfor kun nødvendigt at udvikle den klientspecifikke protokol. Opsætningen af en protokol foregår ved at den initialiseres med et standard klientobjekt. Klientobjektet indeholder bl.a. information om adresse, port, timeout, protokoltype, hvilke eksterne enheder der er tilsluttet samt andre protokolrelevante informationer. En ekstern enhed er i TagTrace simplificeret til at være en række nummererede indog udgange der enten er aktivt høje eller aktivt lave. En nummereret ind- eller udgang defineres til en funktion, fx en rød pære eller en portkontakt. Det er derfor nemt, i fx et script, at aktivere en rød lampe, uden at vide noget om, hvilket nummer udgang den er tilsluttet, eller om den er aktivt høj/lav. Da TagTrace er et middleware system, skal det kunne kommunikere med omverdenen. Denne del af systemet er det nødvendigt at tilpasse fra kunde til kunde. Derfor er følgende et eksempel på en løsning, med brug af flade filer. TagTrace overvåger en mappe for nye filer. Når en ny fil bliver skrevet loades denne ind og håndtering påbegyndes. Først checkes hvilken type fil det er, det kan fx være et dokument der skal printes, en ordre eller en oprettelse af et nyt tag. Herefter gemmes relevant information fra dokumentet i databasen og dokumentet slettes. Hvis dokumentet indeholder fejl eller ikke kan læses, flyttes det til en seperat mappe og der skrives en kvittering i form af en ny xml fil med en fejlbeskrivelse.

19 3.2. OVERORDNET SYSTEMSAMMENHÆNG TagTrace Web TagTrace indeholder også et simpelt web interface til overvågning og opsætning. Webinterfacet er opbygget så det ligner Microsoft Outlook, dette er valgt for at gøre det nemt at gå til for en ny bruger. Data til webinterfacet kommer fra samme database som TagTrace anvender, og der er derfor adgang til de samme informationer fra begge systemer. Funktioner og udseende kan tilpasses den enkelte kunde, så kunden kan få funktioner der relaterer til deres forretningsmodel. Funktioner kan inkludere effektivitet i form af antal produkter flyttet per time, hvor mange produkter der er på lager, hvor mange produkter der mangler at blive flyttet og mange andre. Opsætning af TagTrace foregår også fra webinterfacet. Herfra er det muligt at konfigurere klienter (RFID readere, printere o.l.) og eksterne enheder (lamper, kontakter o.l.). Da IIS anvendes, er der TagTrace også forberedt til at tilbyde webservices. Webservices anvendes endnu ikke i forbindelse med TagTrace, men der er dog udviklet en demo for at vise at det kan lade sig gøre Tilgang til TagTrace data Når TagTrace Handheld skal kommunikere med TagTrace serveren, kan dette foregå på to måder. Første måde er at lave en ny protokol og bygge denne ind i TagTrace servicen. Dette vil give direkte adgang til data der ikke gemmes i databasen og vil kunne udnytte de indre mekanismer i TagTrace (scripting, events og regler). Den anden mulighed er at bruge webservices, dette vil gøre at der ikke skal udvikles en ny protokol, da de fleste platforme allerede har indbygget håndtering af webservices. Hvis webservices bruges, vil der ikke være adgang til indre dele, af TagTrace og det kan derfor blive nødvendigt at udvikle dele der har samme funktionalitet som de der allerede findes i TagTrace. 3.2 Overordnet Systemsammenhæng For at give et overblik over den overordnede struktur, er figur 3.1 udarbejdet. Det viser i store træk de rammer, der er lagt for projektet på forhånd. RFID- og Barcodereadere er ikke obligatoriske, men er dog et krav for at opnå fuld funktionalitet.

20 14 KAPITEL 3. ANALYSE Figur 3.1: Overordnet Systemsammenhæng 3.3 Use Cases I følgende afsnit vil en del Use Cases for TagTrace Handheld blive beskrevet, hvis programmet ønskes færdigudviklest bør der laves use cases for alle funktionaliteter, og de eksisterende use cases bør udvides med flere alternative forløb. Da udviklingsmetoden UP er valgt er Use Cases grundstenen for den funktionalitet, der skal udvikles. Use Cases benyttes til at specificere ønsket funktionalitet samt definere de krav der måtte ønskes. Use Cases vist i rapporten kan være ændret eller tilføjet undervejs i projektets iterationer.

21 3.3. USE CASES 15 Use Case Navn Mål Scope Niveau Prækonditioner Success postkondition Fejl postkondition Primær aktør Trigger Tabel 3.1: Login på enhed Login på enhed Programmet forespørger TagTrace serveren om det indtastede login er korrekt og godkender herefter brugeren lokalt. Brugeren logges korrekt ind og har adgang til relevant funktionalitet System Primær Enheden er forbundet til et netværk Programmet starter korrekt og bruger er logget ind Programmet giver en fejlbesked og returnerer til login skærmen Bruger Programmet startes eller det har ikke været brugt et stykke tid Normalforløb Trin Aktivitet 1 Brugeren indtaster sit brugernummer og kodeord 2 Systemet godkender brugernummer og kodeord 3 Applikationen vises som logget ind Alternative forløb Trin Aktivitet 2a Fejl i godkendelse. Programmet returnerer fejl Prioritet Høj Performance Max 2 sekunder Frekvens Ofte Sekvensdiagram Figur 3.2

22 16 KAPITEL 3. ANALYSE Figur 3.2: Login sekvensdiagram Figur 3.3: Opret RFID sekvensdiagram

23 3.3. USE CASES 17 Use Case Navn Mål Scope Niveau Prækonditioner Tabel 3.2: Opret RFID tag Opret RFID tag Brugeren skal præsenteres for et skærmbillede der tilbyder indtastning af information i forbindelse med oprettelse af et nyt RFID tag. Der skal være mulighed for at scanne en stregkode og bruge data fra denne til at oprette RFID tagget System Primær Enheden er forbundet til netværk. Der findes en stregkode på det ønskede produkt. Brugeren er logget ind Et RFID tag udskrives En fejlbesked vises Bruger En brugerhandling udløser dette Success postkondition Fejl postkondition Primær aktør Trigger Normalforløb Trin Aktivitet 1 Bruger vælger relevant funktion 2 En stregkode scannes 3 Et RFID tag udskrives 4 En kvittering vises Alternative forløb Trin Aktivitet 2a Stregkoden kan ikke afløses 2a.1 Stregkoden indtastes manuelt 3b Der skal indtastes information om produktet 3b.1 Brugeren vises en indtastningsdialog til ekstra information om produktet Prioritet Middel Performance Under 2 sekunder Frekvens Ofte Sekvensdiagram Figur 3.3

24 18 KAPITEL 3. ANALYSE Tabel 3.3: Lagerfør produkt Use Case Navn Lagerfør produkt Mål Et produkt registreres som tilført lager og en eventuel lokation registreres. Brugeren får vist en kvittering på den udførte handling Scope System Niveau Primær Prækonditioner Varen er registreret i systemet. Varen har et RFID tag eller en stregkode. Bruger er logget ind Success postkondition Placering og navn på vare vises Fejl postkondition En fejlbesked vises Primær aktør Bruger Trigger En brugerhandling udløser dette Normalforløb Trin Aktivitet 1 Bruger vælger relevant funktion 2 Et RFID tag eller en stregkode scannes 3 Kvittering om placering og produkt vises Alternative forløb Trin Aktivitet 2a Produktet ønskes placeret på en bestemt lokation 2a.1 Lokationskode scannes eller indtastes 2b RFID tag eller stregkode er ikke kendt af systemet 2b.1 Bruger spørges om RFID tag eller stregkode skal oprettes 2b.2 Bruger vises "Tilføj info til vare" Prioritet Høj Performance Under 2 sekunder Frekvens Meget Ofte Sekvensdiagram Figur 3.4 Figur 3.4: Lagerfør sekvensdiagram

25 3.3. USE CASES 19 Tabel 3.4: Pluk produkt Use Case Navn Pluk produkt Mål Et produkt registreres som fraført lager og en kvittering vises for brugeren Scope System Niveau Primær Prækonditioner Produktet er lagerført. Produktet har RFID tag eller stregkode. Bruger er logget ind Success postkondition Navn på vare vises Fejl postkondition Fejlbesked vises Primær aktør Bruger Trigger En brugerhandling udløser dette Normalforløb Trin Aktivitet 1 En bruger vælger relevant funktion 2 Et RFID tag eller stregkode scannes 3 Kvittering for plukning vises Alternative forløb Trin Aktivitet 2a RFID tag og stregkode kan ikke læses 2a.1 Produktkode indtastes manuelt Prioritet Høj Performance Under 2 sekunder Frekvens Meget Ofte Sekvensdiagram Figur 3.5 Figur 3.5: Pluk vare sekvensdiagram

26 20 KAPITEL 3. ANALYSE Tabel 3.5: Vis info om produkt Use Case Navn Vis info om produkt Mål Programmer viser de informationer der er registreret i TagTrace om det scannede produkt. Scope System Niveau Primær Prækonditioner Produktet er registreret. Produktet har RFID tag eller stregkode. Bruger er logget ind Success postkondition Information om produktet vises Fejl postkondition Fejlbesked vises Primær aktør Bruger Trigger En brugerhandling udløser dette Normalforløb Trin Aktivitet 1 En bruger vælger relevant funktion 2 Et RFID tag eller stregkode scannes 3 Information om produkt vises Alternative forløb Trin Aktivitet 2a RFID tag og stregkode kan ikke læses 2a.1 Produktkode indtastes manuelt Prioritet Lav Performance Under 2 sekunder Frekvens Middel Sekvensdiagram Figur 3.6 Figur 3.6: Vis info sekvensdiagram

27 3.3. USE CASES 21 Tabel 3.6: Tilføj info til produkt Use Case Navn Tilføj info til produkt Mål Information om det scannede produkt tilføjes til TagTrace databasen og information om produkt vises Scope System Niveau Primær Prækonditioner Produktet er registreret. Produktet har RFID tag eller stregkode. Bruger er logget ind Success postkondition Information er tilføjet til produkt Fejl postkondition En fejlbesked vises Primær aktør Bruger Trigger En brugerhandling udløser dette Normalforløb Trin Aktivitet 1 En bruger vælger relevant funktion 2 Et RFID tag eller stregkode scannes 3 Indtastingsfelt for produkt vises Alternative forløb Trin Aktivitet 2a RFID tag og stregkode kan ikke læses 2a.1 Produktkode indtastes manuelt Prioritet Lav Performance Under 2 sekunder Frekvens Middel Sekvensdiagram Figur 3.7 Figur 3.7: Tilføj info sekvensdiagram

28 22 KAPITEL 3. ANALYSE 3.4 Supplerende Kravspecifikation Den supplerende kravspecifikation indeholder krav til produktet, som ikke er specificeret med use cases Generel Beskrivelse Programmet har til formål at erstatte samt udvide funktionaliteten af en stationær RFID reader og samtidig kombinere dette med funktionaliteten i en stregkodelæser. Programmet skal kommunikere med den allerede etablerede TagTrace database og udnytte de data der stilles til rådighed heri Specifikke krav Krav til udstyr Udstyret der skal udvikles til, er givet på forhånd. Det består af en Intermec CN3 med et IP30 RFID modul. En Intermec CN3 er en håndholdt computer der kan købes i flere forskellige konfigurationer, fx gsm modul, digitalkamera, gps, stregkodelæser, trådløst netværk m.fl. I forbindelse med dette projekt vil det være en enhed bestykket med stregkodelæser og trådløst netværk. Et IP30 RFID modul er en ekstern enhed der kommunikerer med en CN3 vha. bluetooth eller direkte kabelkommunikation. Et billede af udstyret er vedlagt i bilag A.2 RFID kommunikationen skal afkobles fra resten af programmet, så terminalen kan udskiftes med en hvilken som helst Windows Mobile 5 kompatibel enhed. Brugerkarakteristika Programmet skal kunne bruges af brugere uden forudgående kendskab til rfid og mobile enheder. Da mange brugere af denne type applikation vil være vant til at arbejde med stregkoder, er det vigtigt at allerede etablerede begreber genbruges så vidt det er muligt. Brugervenlighed Det er derfor et vigtigt aspekt at programmet fremstår meget brugervenligt og intuitivt.

29 3.4. SUPPLERENDE KRAVSPECIFIKATION 23 Da RFID ikke er retningsbestemt på samme måde som stregkoder, er det vigtigt at brugeren præsenteres for en overskuelig mulighed for at vælge mellem fundne RFID tags. Begrænsninger Før programmet kan bruges, skal brugeren logges ind. Dette gøres for at sikre sporbarheden og for at sikre systemet mod brugere der ikke er godkendte til at benytte det. Brugerdatabasen kan komme fra forskellige kilder, dette kan fx være Active Directory eller en specialiseret tabel i TagTrace databasen. Fejlhåndtering Der skal i programmet være mulighed for at aktivere en log funtion, denne funktion skal skrive alle handlinger til et lokalt lager. Loggen skal indeholde tidsstempel samt brugernavn og andre relevante informationer, der kan hjælpe med videre fejlsøgning. Performance Afviklingen af programmet er ikke tidskritisk, forstået på den måde at der ikke sker nogen skade ved at svartiden overstiger et sekund. At det er uhensigtmæssigt og uønsket at vente så længe på et svar er et andet aspekt. Da mange dele af programmet skal kommunikere med en server, vil det i mange tilfælde være netværk og server der sætter en naturlig begrænsning på hastigheden. Dette forsøges minimeret med mest mulig lokal caching. Programmeringsprog Programmet udvikles i C# med brug af.net Compact Framework. Sproget er valgt ud fra tidligere erfaring og det er samtidig det programmeringsprog der allerede bruges i virksomheden..net CF understøtter desuden webservices direkte, så hvis denne metode vælges spares en masse arbejde. Systemkrav På den mobile enhed: Windows Mobile 5 enhed med.net CF installeret. Stregkodescanner samt RFID læser. På serveren: Windows Server 2003 eller bedre. En installation af TagTrace..NET Framework 2.0

30 24 KAPITEL 3. ANALYSE 3.5 Domænemodel Domænemodellen nedenfor viser en fortolkning af de fysiske rammer der stilles for systemet. Det er væsenligt at understrege at modellen ikke har noget med det endelige udseende og design af softwaren at gøre. Modellen giver et overblik over, hvilke fysiske komponenter der skal tænkes ind i systemdesignet. Figur 3.8 er udarbejdet vha. de ovenstående use cases. Slutbruger - Brugeren der skal anvende enheden i sidste ende, dette kan være en lagermedarbejder eller lignende. Scanner - Den håndholdte enhed. Enheden skal understøtte mindst een måde at kommunikere med TagTrace serveren. Lokation - En fysisk lokation, fx. en dør, en hylde, en truck eller anden placering, der kan bestemmes unikt. Produkt - Et produkt, fx. en kasse, palle eller andet der kan mærkes og flyttes. Produktinfo - Information om et produkt. Disse data eksisterer som en mapning mellem produktets stregkode og produktet. Stregkode - Stregkode monteret på et produkt eller en lokation. RFID Tag - RFID tag monteret på produkt eller en lokation. Figur 3.8: Domænemodel

31 KAPITEL 4 Design Designfasen skrives med udgangspunkt i analysen. Her fastlægges standarder for samarbejde mellem forskellige komponenter og endelige teknologier vælges. Implementeringen udføres med udgangspunkt i designfasen, det er derfor vigtigt at designet er velovervejet for at det kan gennemføres. I designet indføres forskellige diagrammer, heriblandt sekvensdiagrammer og klassediagrammer, for at gøre systemet overskueligt og for at lette det videre arbejde. 4.1 Softwarearkitektur Det er valgt at bruge den Klassiske 3-lags model, hvor systemet inddeles i en lagstruktur og som muliggør nem udskiftning af enkelte komponenter. De tre lag er følgende: Graphical User Interface (GUI), Forretningslogik og Data. GUI - Inkluderer alle visuelle elementer, der vises til brugeren. Ydermere er alle events, der har forbindelse til det visuelle, inkluderet her. Forretningslogik - Skal indeholde al funktionalitet, der ikke har noget med GUI laget at gøre. Forretningslogikken sørger for at kommunikation 25

32 26 KAPITEL 4. DESIGN mellem GUI og datalaget. Forretningslogikken skal desuden, som navnet siger, indeholde forretningslogik (den primære programkode). Datalag - Der vil i programmet være flere forskellige datalag, dog alle udskiftelige og i samme niveau i systemet. Datalagene er kommunkation med TagTrace, kommunikation med lokal database, kommunikation med RFID læser samt kommunikation med stregkodelæser. Ved at opdele programmet i tydeligt adskilte lag, forbereder man programmet til nem videreudvikling, rettelse og udskiftning. Hvis en anden programmør skal overtage koden kan dette også gøre denne persons arbejde langt nemmere, da koden bør ende op med at være overskuelig. Et diagram over modellen kan ses i figur 4.1. Datalagene skal deles ekstra op, da programmet som skrevet, skal kunne abstrahere fra de enkelte hardwaretyper og kommunikationsformer med disse. Desuden skal det være muligt at skifte kommunikationen med TagTrace, så lige meget hvilken der vælges implementeret først, skal denne kunne udskiftes med en anden type senere (webservice med proprietær protokol eller omvendt). Figur 4.1: 3-Lagsmodel

33 4.2. GUI GUI Den grafiske brugergrænseflade er brugerens indgang til programmet, det er også det øverste lag. Det er fra dette lag brugeren har mulighed for at interagere med programmet. Dette gøres ved at bruge knapper, menuer, lister, tekstbokse osv. Det er utrolig vigtigt at brugergrænsefladen opbygges på en overskuelig og intuitiv måde, da der potentielt kan forekomme brugere uden forudgående kendskab til lignende løsninger. I designet skal alle de grundlæggende skærmbilleder og funktioner fastlægges, så disse er lagt fast inden udviklingen startes. Der stræbes efter at udvikle en række standard skærmbilleder, da der vil være mange gange, hvor det samme skærmbillede kan bruges. Følgende skærmbilleder er fremkommet ved at bruge use cases fra analysen, et overblik kan ses i figur 4.2: Login - Use Case: 3.1 Skal give mulighed for at indtaste brugernummer samt kodeord. Programmet skal godkende disse og logge brugeren ind. Oversigt - Use Case: 3.1 Startbillede med funktionsvalg. Herfra skal det være muligt at vælge mellem programmets øvrige funktioner. Dette billede vil blive vist igen, hver gang en funktion er fuldført, medmindre andet er defineret. Opsætning - Baseret på Use Case 3.1. Dette skærmbillede skal indeholde opsætning af systemet. Skærmbilledet kan evt. indeholde faneblade til opsætning af forskellige dele. Data skal gemmes i xml format samt sættes i brug med det samme. Ved skift af data skal den nuværende bruger logges ud og indstillingerne skal træde i kraft. Scan - Skal scanne alle RFID tags samt stregkoder og vise en liste med dem. Ved klik på et emne skal der vises information omkring dette og brugeren skal godkende korrekt valg. Der skal desuden være mulighed for manuel indtastning. Pluk - Baseret på Use Case 3.4. Skal aktivere Scan. Det valgte produkt skal registreres som fraflyttet dets hidtidige lokation. Lagerfør - Baseret på Use Case 3.3. Skal aktivere Scan og scanne et produkt. Skal herefter aktivere Scan igen til scanning af en lokation. Det skal checkes at den scannede kode er en

34 28 KAPITEL 4. DESIGN lokationskode. Produktet skal registreres som lageført på den scannede lokation. Skriv RFID tag - Baseret på Use Case 3.2. Skriver ønsket information til et RFID tag inden for rækkevidde. Returnerer med status, om et tag blev tilskrevet eller ej. Vis/Tilføj Info - Baseret på Use Case 3.5. Skal vise information om et givent produkt og give brugeren mulighed for at indtaste ekstra information. Figur 4.2: Overordnet systemsammenhæng - Fuldt størrelse i bilag A Forretningslogik I følgende afsnit vil grundfunktionerne i programmet blive beskrevet. Hvordan den bagvedliggende implementering udføres vil ikke blive beskrevet nærmere her. Funktionaliteten beskrives i i grove træk, da det vigtigste er at få fastlagt, hvordan enkelte komponenter kommunikerer og sørge for at disse dele udvikles korrekt fra starten af. Funtionaliteten her defineres på baggrund af use cases fra analysen Opsætning Opsætningen skal gemmes i en xml fil lokalt på enheden. Filen skal indeholde information om programmets opsætning og skal kunne gemmes, hvis der udføres ændringer af opsætningen undervejs.

35 4.4. DATA Log Der skal oprettes en lokal log fil på enheden, hvor alle handlinger gemmes i et fastsat antal dage. Dette muliggør, at en tekniker kan lave fejlfinding på terminalen efter fejlen er sket. Det er et krav at logfunktionaliteten kan gradueres, så en terminal i testfasen kan sættes til at logge handlinger og fejlfindingsdata, hvorimod en terminal i produktion kan nøjes med at logge handlinger Konvertering mellem EAN128 og EPC For at kunne kommunikere ensartet med TagTrace skal alle stregkoder konverteres fra EAN128 til EPC. Til konvertering benyttes en komponent fra det eksisterende TagTrace, og derfor forklares dette ikke yderligere Scripting Ved læsning af et tag, skal der implementeres mulighed for at udføre en handling. Scripting på enheden skal vedlægges programmet i form af et seperat bibliotek, der kan aktiveres ved taglæsning. Scriptkoden skal modtage et RFID tag eller en stregkode og reagere på dette. Det kan være i form at omskrivning, logning eller noget helt andet. Scriptet skal herefter returnere koden igen eller en tom streng som tegn på, at der ikke skal gøres mere med det. 4.4 Data Det tredje og nederste lag sørger for dataadgang via forskellige kilder TagTrace Dataadgangen til TagTrace kan foregå på forskellige måder. Det følgende afsnit indeholder en beskrivelse af hver af de måder der er overvejet til projektet og tilsidst

36 30 KAPITEL 4. DESIGN en sammenligning og beslutning. TagTrace Proprietær Da TagTrace indeholder sit eget protokollag, er det en oplagt mulighed blot at benytte dette. TagTrace protokollaget har direkte adgang til interne events og vil kunne give brugeren fuld adgang til data om programmets tilstand samt udnytte den indbyggede scripting- og taghåndterings funktionalitet. Hvis det vælges at benytte TagTraces proprietære protokollag skal alle kommandoer der sendes frem og tilbage implementeres i TagTrace og herefter også i den håndholdte enhed. Hvis protokollen implementeres på denne måde vil hver håndholdt enhed optage en protokolinstans på TagTrace serveren. Noget af den funktionalitet der skal bruges af den håndholdte enhed vil kunne arves fra TagTraces Proof-of-concept program, da dette allerede kobler sig op imod TagTrace serveren og har adgang til interne events. TagTrace Webservice Vælges det at bruge webservices, vil dette medføre at der ikke skal udvikles en ny protokol, blot en række metoder på webserveren. Disse metoder vil ikke kunne få direkte adgang til TagTrace servicen, men vil kunne få adgang til alle data i databasen. Da TagTrace Handheld kan nøjes med at manipulere med data i databasen, er webservicen en oplagt mulighed. TagTrace handheld vil dog ikke kunne få direkte realtidsadgang til TagTrace servicens indre data eller kunne udnytte dens indbyggede script og taghåndtering. Der vil dog kunne udvikles en kobling mellem webservice og TagTrace som muliggør kommunikation og som derfor vil kunne opnå samme grad af funktionalitet som den proprietære protokol. Da webservices allerede har indbygget godkendelse af brugere, vil dette kunne udnyttes fra start af Enheder til læsning Både stregkodelæser og RFID læser vil have mange fællestræk. Derfor skal de begge bruge samme interface til standard funktionalitet som statusforespørgsler, initialisering, forbinde samt afbryde forbindelsen.

37 4.4. DATA RFID RFID modulet skal opbygges omkring et standardinterface, dette skal bygge videre på det tidligere interface til enheder. Dette interface skal indeholde mulighed for at læse og skrive tags, forespørge om status på RFID readeren, forbinde til enheden og afbryde forbindelsen til enheden. RFID interfacet skal ligeledes indeholde relevante events som programmet kan koble sig på, når et tag er blevet læst Stregkode Stregkodemodulet skal, som RFId modulet, opbygges over det tidligere Enheder interface. Det skal derudover indeholde mulighed for at starte læsning af stregkoder og forespørge om status. Stregkodelæsning skal begrænses til kun at læse stregkoder i EAN128 formattet. Dette sikrer at kun stregkoder der er kompatible med RFID tags kan læses.

38

39 KAPITEL 5 Implementering I dette afsnit gennemgås de mest interessante funktioner i projektet. Kildekoden til TagTrace Handheld vil være at finde på vedlagte cd. For at gøre visse punkter lettere læselige, vil der enkelte steder i teksten være indsat kildekode. Dermed slipper læseren for at have adgang til kildekoden på læsetidspunktet. TagTrace Handheld er udviklet i Visual Studio 2008 og skrevet i sproget C#. Følgende afsnit er inddelt i tidligere omtalte 3-lags struktur. Dette er valgt for at gøre afsnittet mere overskueligt og dermed også følge programmets opbygning. Det er vigtigt at bemærke at den implementerede udgave på ingen måde er produktionsklar og skal videreudvikles og færdiggøres inden den kan tages i brug i en virkelig situation. 33

40 34 KAPITEL 5. IMPLEMENTERING 5.1 Opbygning Programmet er implementeret med klassebiblioteker, så de enkelte komponenter der kommunikerer med hardware er udskiftelige. Dette betyder at størrelsen på det installerede program ikke påvirkes af hvor mange typer hardware der understøttes, men kun af den type hardware, der vælges installeret Pakkehierarki Programmet er opbygget, så funktionalitet der skal kunne udskiftes er placeret i seperate pakker (dll filer). TagTraceHandheld - Indeholder alle forms og programmets primære funktionalitet. TagTraceAux - Indeholder programfunktionalitet og samlet eventstyring. Desuden er interfaces defineret heri. TagTraceData - Indeholder komponenter til kommunikation med TagTrace server eller lokal database. Barcode - Indeholder komponenter til kommunkation med den fysiske stregkodelæser. RFID - Indeholder komponenter til kommunkation med den fysiske RFID læser Singleton Det er valgt at implementere moduler, hvor der kun må eksistere et af gangen, som Singletons. Det betyder at man fra et hvert sted i applikationen kan forespørge på en instans af objektet og få det samme som alle andre. En Singleton implementeres ved at have en offentlig statisk constructor og en privat dynamisk constructor. Desuden holdes en statisk reference til det dynamisk oprettede objekt. Når der senere forespørges efter objektet, returneres referencen til det samme objekt som blev oprettet tidligere. 1 // Reference Listing 5.1: Eksempel på Singleton contructor

41 5.2. GUI 35 2 s t a t i c readonly BarcodeScanner i n s t a n c e = new BarcodeScanner ( ) ; 3 // S t a t i c c o n t r u c t o r 4 s t a t i c BarcodeScanner ( ) 5 { 6 } 7 8 /// <summary> 9 /// Returns a threadsafe i n s t a n c e of ClientHandler 10 /// </summary> 11 public s t a t i c BarcodeScanner Instance 12 { 13 get { return i n s t a n c e ; } 14 } 5.2 GUI Den grafiske brugerflade er implementeret i Visual Studio Alle elementer der bruges i den grafiske brugerflade, er standardkomponenter fra.net 3.5 Frameworket. Der er implementeret grafiske visninger (forms), som følger den oversigt over GUI der er beskrevet i designafsnit 4.2. Blandt disse er forms til visning af information og valg af scannet data. Som udgangspunkt er forms opbygget med en MainMenu i bunden af skærmen. Her placeres handlinger, der afviger fra hovedforløbet (luk og fortryd). I toppen af skærmen er der placeret en titel. Denne angiver hele tiden hvor i programmet eller i et forløb man er. Imellem titlen og MainMenuen er der fri plads, denne benyttes til visninger, der har relevans for den aktive funktion. Den frie plads er udfyldt af paneler, et panel kan ses som en gruppering af visuelle elementer, der kan vises og skjules alt efter hvor langt i forløbet brugeren er. Udover paneler, er der oftest benyttet textbox, button og listbox. Alle grafiske visninger er udviklet vha. Visual Studios indbyggede drag and drop editor. Og alle interaktioner med brugeren foregår vha. events. En event kan udløses af en handling, fx et tryk på en knap eller et valg af et element i en liste. I forbindelse med fejl, vil der blive vist en simplificeret fejlmeddelelse på dansk, i form af et popup vindue. Fejlen vil i detaljer være logget i programmets logfil, der

42 36 KAPITEL 5. IMPLEMENTERING derfor senere kan danne grundlag for fejlfinding. De fleste fejl vil blive håndteret af programmet og vil blot afslutte den nuværende funktion eller give brugeren mulighed for at prøve igen. Da den nuværende implementering er en prototype, kan der dog opstå uforudsete og uhåndterede fejl, disse kan få programmet til at afslutte helt og præsentere brugeren for en fejlmeddelelse fra systemet. Denne meddelelse kan både forekomme på engelsk og på dansk, alt efter det bagvedliggende systems sprog og hvilken komponent der fejlede. Da de enheder programmet skal benyttes på, vil være forsynet med en trykfølsom skærm, er der lagt stor vægt på størrelse og brugbarhed af de forskellige visuelle elementer. Ofte til brugeren trykke på skærmen med fingeren eller en anden genstand, og skal arbejdet gå hurtigt, må det ikke være svært at ramme det rigtige sted. Knapper er gjort ekstra store og tekstfelter er ligeledes forstørret, for at lette både læsbarhed og præcision ved tryk. I bilag?? findes screenshots af programmets forskellige muligheder. Formen Scan er udviklet så den kan genbruges alle steder hvor det er nødvendigt at scanne et tag eller en rfid kode. Dette har været en oplagt mulighed, da alle scanninger vil foregå på samme måde. Formen oprettes med en titel og vises herefter. Den lytter på RFID trigger events, og aktiverer stregkode og RFID scanner ved tryk på knap på RFID håndtag. Formen er opbygget således at der først vises en instruktion, og når RFID triggeren aktiveres skiftes dette ud med en liste over fundne tags og stregkoder. Brugeren kan klikke på en af disse og se hvilke informationer der er gemt i databasen på TagTrace serveren og godkende eller afvise det valgte emne. Afvises det, vises listen over fundne emner igen. Godkendes det, lukkes formen med et DialogResult.OK. Eksempel på håndtering af returværdi fra Scan form kan ses i figur 5.2. Listing 5.2: Eksempel på håndtering af returværdi 1 // Close t h i s form i f user c a n c e l s in Scan dialog 2 i f ( scan. ShowDialog ( )!= DialogResult.OK) 3 { 4 t h i s. Close ( ) ; 5 } Da programmet skal køre på mobile enheder, som ofte har begrænsede ressourcer til rådighed i form af hukommelse og processorkraft, frigives alle ressourcer når en form lukkes. Dette gøres ved at lytte på formens Closing event, og når denne kaldes, frigive ressourcer og nulstille referencer. Ved at rydde grundigt op, sikres det, at der ikke bruges unødige ressourcer.

43 5.3. FORRETNINGSLOGIK Forretningslogik Forretningslogikken er placeret to steder: Det ene sted er i den kode fil der automatisk tilknyttes en form og det andet sted er i seperate klasser i projektet TagTraceAux Logfunktionalitet Klassen log implementerer en simpel logfunktion der skriver beskeder i en flad tekstfil på enheden. Filen placeres automatisk i samme mappe som programmet er startet fra. I en videreudvikling af programmet skal denne fil overføres løbende til serveren, så det er muligt for en administrator at fejlsøge en bestemt terminal uden at være i fysisk kontakt med den. Nye linier vil blive tilføjet i slutningen af filen. Alle linier starter med dato og klokkeslet, herefter kommer en valgfri tekststreng. Denne linie bør startes med navnet på hvilket modul der logger. Figur 5.3 er eksempel på en logfil, dato og tid var ikke indstillet på enheden. Listing 5.3: Eksempel på logfil 1 06/03/ : 4 6 : 5 6 LOGIN 1234 was logged in c o r r e c t l y 2 06/03/ : 4 7 : 0 8 LOGIN 1234 was logged out c o r r e c t l y 3 06/03/ : 4 7 : 3 4 RFID S t a r t i n g RFID device 4 06/03/ : 4 7 : 4 3 BARCODE I n i t i a l i z e 5 06/03/ : 4 8 : 3 5 LOGIN 1234 was logged in c o r r e c t l y 6 06/03/ : 4 8 : 3 8 RFID Trigger was a c t i v a t e d 7 06/03/ : 4 8 : 3 9 BARCODE Read : Opsætning Der benyttes en standard.net konfigurationsfil. Opbygningen af denne er dikteret af.net frameworket. Filen skal hedde App.Config, det er en ren xml fil, hvor konfigurationsvariable indsættes. I et.net program vil denne fil blive loadet og være

44 38 KAPITEL 5. IMPLEMENTERING tilgængelig i et array. Da der benyttes.net compact framework, eksisterer der ikke mulighed for direkte at bruge en standard konfigurationsfil. Derfor er der implementeret en metode der imiterer den normale.net opførsel. Koden til at indlæse en konfigurationsfil er lånt fra en artikel hos eggheadcafe 1 og save-metoden er egenudviklet Scripting Scripting er fravalgt i denne implementering. Der er dog flere muligheder for senere, at koble et scriptingsystem på. 5.4 Data Alle dataindsamlingsmetoder arver et overordnet interface. Enheder som RFID og stregkodelæser arver fra henholdsvis IBarcodeDevice og IRfidDevice, som igen arver fra IDevice. Dataforbindelser arver fra IDataConnection. Et grafisk overblik kan ses på figur 5.1. Disse interfaces indeholder definitioner af nødvendige metoder for enheder og dataforbindelser. Figur 5.1: Overblik over interfaces og deres tilknytninger 1

45 5.4. DATA RFID RFID klassen er opbygget som en singleton (se 5.1.2). Der benyttes en Intermec IP30 RFID reader med Bluetooth til at læse og skrive tags. RFID kommunikation er udviklet ved brug af Intermec RFID Resource Kit 2. ved at bruge Intermecs egne udviklingsbiblioteker, slipper programmøren for at skulle håndtere Basic Reader Interface protokollen (BRI) 3 og forbindelsesparametre. Når RFID klassen oprettes for første gang skal Initialize-metoden køres, se kode i 5.4. Denne metode initialiserer værdier, opretter BRIReader objektet og forbinder til events i dette. Listing 5.4: Oprettelse af RFID Reader 1 // Create BriReader ( RFID ) 2 t h i s. r f i d = new BRIReader ( form ) ; 3 4 // Hookup event f o r t r i g g e r and other s t u f f 5 r f i d. RFIDButtonEnable ( BRIReader. RFIDButtonIDs. CENTER) ; 6 r f i d. EventHandlerCenterTrigger += new CenterTrigger_EventHandlerAdv ( rfid_eventhandlercentertrigger ) ; 7 r f i d. EventHandlerTag += new Tag_EventHandlerAdv ( rfid_ EventHandlerTag ) ; 8 9 // L i s t e n f o r s t a r t and stop read events 10 TagTraceAux. Events. StartRFID += new startrfid ( Events_StartRFID ) ; 11 TagTraceAux. Events. StopRFID += new stoprfid ( Events_StopRFID ) ; Udløserknappen på RFID håndtaget udløser eventen EventHandlerCenterTrigger når knappen trykkes ned og igen når den slippes. Når en af disse handlinger sker, udløses en systemevent. Oftest vil denne event bruges til at aktivere stregkodelæser og RFID læser. Der læses kun tags når RFID readeren er aktiveret. Dette gøres ved at udløse en StartRFID event et sted i programmet. Når Intermec biblioteket registrerer et nyt tag udløses en event, denne event modtages i RFID modulet og data modtaget videresendes vha. NewRFID eventen. 2 DEVRESOURCEKIT 3

46 40 KAPITEL 5. IMPLEMENTERING Intermecs RFID bibliotek understøtter ikke skrivning til et tag. Det er derfor nødvendigt at gøre dette manuelt ved hjælp af en BRI kommando. Kommandoen WRITE bruges i denne sammenhæng til at skrive en hex streng til tagget på en bestemt position. Eksempel kan ses i figur 5.5. Listing 5.5: Manuel BRI kommando 1 // Build command s t r i n g, write Hex chars to a s p e c i f i c memory bank on the tag (EPC ID ) 2 S t r i n g cmd = "WRITE hex ( 1 : 4, " + ( item. Length / 2). ToString ( ) + " ) =H" + item ; 3 // Write to tag 4 t h i s. r f i d. Execute (cmd) ; 5 // Search f o r tags and make sure i t i s found Stregkode Stregkodescanning er udviklet ved brug af Intermec IDL Resource Kit - Data Collection. Klassen er opbygget stort set identisk med RFID (5.4.1), det er også en singleton og Intermecs udviklerbiblioteker benyttes. Som hardware benyttes den indbyggede stregkodescanner. For ikke at scanne forkerte stregkoder opsættes scanneren i Initialize metoden som vist i figur 5.6 Listing 5.6: Oprettelse af RFID Reader 1 // Define only read EAN barcodes 2 t h i s. bcr. symbology. DisableAll ( ) ; 3 t h i s. bcr. symbology. UPCEan. EnableEan13 = true ; 4 t h i s. bcr. symbology. UPCEan. EnableEan8 = true ; 5 t h i s. bcr. symbology. UPCEan. EnableUPCA = true ; 6 t h i s. bcr. symbology. UPCEan. EnableUPCE = true ; 7 t h i s. bcr. symbology. UPCEan. EnableUPCE1 = true ; 8 // Setup data format 9 t h i s. bcr. symbologyoptions. Postamble = " " ; 10 t h i s. bcr. symbologyoptions. Preamble = " " ;

47 5.4. DATA t h i s. bcr. symbologyoptions. globalsymbologyid = SymbologyOptions. EGlobalSymbologyID. Disable ; Data Det er valgt at implementere datalaget som en Webservice. Dette er gjort ud fra de overvejelser der er beskrevet i designafsnittet TagTrace Webservicen overholder IDataConnection interfacet, som indeholder beskrivelse af de forskellige metoder programmet skal kunne bruge. En webservice i.net fungerer i det fleste henseender præcist på samme måde, som hvis man havde lokale metoder. Webservicen inkluderes som en reference i projektet og der oprettes en instans af denne. Kald til metoder i webservicen kan nu foretages på præcis samme måde som hvis koden lå lokalt. Listing 5.7: Oprettelse og eksempel med webservice 1 /// <summary> 2 /// Reference to webservice 3 /// </summary> 4 TagTraceWebservice. TagTraceHandheld web = new TagTraceData. TagTraceWebservice. TagTraceHandheld ( ) ; 5 6 // Example of c a l l to webservice 7 Authenticated = web. Authenticate ( user, pass, C l i e n t ) ; Hvis et webservicekald fejler, skrives dette til logfilen og der returneres en værdi svarende til at metoden ikke kunne finde noget eller fejlede. Der er ikke implementeret fuld brugergodkendelse på webservicen, en bruger checkes blot mod databasen. For at udnytte den indbyggede godkendelse i en.net webservice skal dennes brugeroplysninger (Credentials) opsættes. For at dette skal virke, kræver det at klienten er konfigureret til den samme type godkendelse som serveren.

48 42 KAPITEL 5. IMPLEMENTERING Webservice På serversiden implementeres en webservice ved at sætte attributten [WebMethod] på en metode. Metoden skal være offentlig (public) og projektet gøres tilgængeligt på en webserver. Listing 5.8: Oprettelse og eksempel med webservice 1 // Get information about a product 2 [ WebMethod] 3 public S t r i n g [ ] [ ] GetProductInfo ( S t r i n g ident, Guid c l i e n t ) 4 {... } Da objekter returneret fra en webservice skal sendes over netværket, skal alle objekttyper der returneres være serialiserbare. Eksempel på serialiserbare objekter er tal, tekststrenge, simple arrays og booleans. Eksempler på ikke serialiserbare objekter er hashtable og dictionary. For at serialisere objekter der ikke er direkte serialiserbare, må de konverteres til et serialiserbart objekt. Fx kan et hashtable der indeholder tekststrenge konverteres til et 2 dimensionelt array. Denne form for konvertering bruges i metoden GetProductInfo, som det kan ses i figur 5.9. Listing 5.9: Eksempel på konvertering fra ikke serialiserbar til serialiserbar 1 foreach ( KeyValuePair < s t r i n g, s t r i n g > item in i n f o ) 2 { 3 a [ i ] = new S t r i n g [ 2 ] ; 4 a [ i ] [ 0 ] = item. Key ; 5 a [ i ] [ 1 ] = item. Value ; 6 i ++; 7 } Til at få adgang til TagTrace databasen benyttes en allerede udviklet komponent fra TagTrace. Adgangen til data i TagTrace er opdelt i sektioner, følgende to vil blive brugt her: Tag- og klientrelaterede. Der oprettes derfor instanser af Database.TagsDatabase og Database.Clients. Ved hvert kald til webservicen inkluderer den håndholdte enhed sit klient id. Dette id stammer fra TagTrace databasen, hvor hver enkelt enhed (printer, rfid reader o.l.) har et unikt id. Id et sendes med for at give mulighed for at kæde en flytning af et

49 5.4. DATA 43 tag til en bestemt enhed. Da TagTrace databasen endnu ikke understøtter opslag mellem stregkode/rfid og en lokation, benyttes en lokation, der altid er defineret i databasen for en klient. Metoderne SaveProductInfo og DeAuthenticate er ikke implementeret, da der ikke eksisterer bagvedliggende logik til at udføre dem. Authenticate metoden er implementeret, men kun med et fast defineret brugernavn og password.

50

51 KAPITEL 6 Test I følgende afsnit udføres test af funktionerne i programmet. Testen udføres som en blackbox test og der noteres for hver test, hvad der testes, hvad det forventede resultat er og hvad det faktiske resultat er. For at en test kan ses som bestået skal det forventede og det faktiske resultat stemme overens. I slutningen af afsnittet vil den Supplerende Kravspecifikation blive evalueret. Opstår der fejl vil disse blive beskrevet og forsøgt afklaret. Alle test er udført på en udviklingsmaskine og hastigheden af databasen og netværket kan derfor ikke sammenholdes med hastigheden, hvis programmet blev benyttet med en rigtig TagTrace server. 6.1 Scanning Test af scanning af stregkoder og tags. 45

52 46 KAPITEL 6. TEST Tabel 6.1: Test af Scanning Test Handling Forventet resultat Faktisk resultat 1 En EAN128 stregkode Stregkoden konverteres Som forventet scannes til korrekt EPC format og vises i listen 2 En ikke EAN128 Stregkoden registreres Som forvenetet stregkode scannes ikke af enheden 3 Et RFID tag aflæses Korrekt EPC format vises Som forventet i listen 4 Flere RFID tags aflæses Alle tags tilføjes til listen Som forventet samtidig med korrekt EPC format 5 En EAN128 stregkode Stregkoden konverteres Som forventet ind-tastes manuelt til korrekt EPC format og vises i listen 6 En ikke EAN128 Systemet returnerer en Som forventet stregkode indtastes fejl og tilføjer ikke noget manuelt til listen 7 Et RFID tag registreres Der tilføjes ikke ens linier Som forventet og en tilsvarende til listen stregkode scannes 6.2 Skrivning af RFID tag Test af skrivning til RFID tag. Tabel 6.2: Skrivning af RFID Test Handling Forventet resultat Faktisk resultat 1 Der skrives til et RFID Tagget skrives succesfuldt og enheden Som forventet tag inden for rækkevidde returnerer en kvittering 2 Der skrives til et RFID uden for rækkevidde på dette Tagget bliver ikke skrevet og enheden returnerer en kvittering Som forventet 6.3 Visning og Tilføjelse af information Tester visning af information i Scan skærmbilledet og i Vis Info skærmbilledet. Tester også tilføjelse af information til et tag.

53 6.4. WEBSERVICE 47 Tabel 6.3: Information om Tags Test Handling Forventet resultat Faktisk resultat 1 En scanning udføres og der klikkes på resultatet i listen Information der er gemt i TagTrace databasen vises Som forventet. 2 Test 1 udført, der klikkes Godkend 3 Test 2 udført, der klikkes Tilføj og indtastes noget tekst og klikkes Godkend Information der er gemt i TagTrace databasen vises igen Teksten vises sammen med tidligere information fra TagTrace databasen Som forventet Ny informationen vises ikke. Der er ikke implementeret funktionalitet til dette i TagTrace databaselaget. 6.4 Webservice Test af de forskellige kald til webservicen. Tabel 6.4: Webservice Test Handling Forventet resultat Faktisk resultat 1 Det forsøges at Plukke et tag der er kendt af TagTrace Kvittering vises og Tag- Trace databasen undersøges for korrekt data Som forventet 2 Det forsøges at Plukke et tag der ikke er kendt af TagTrace 3 Det forsøges at lagerføre et tag der er kendt af TagTrace til en lokation 4 Det forsøges at lagerføre et tag der ikke er kendt af TagTrace til en lokation 5 Det forsøges at vise info om et tag der er kendt af TagTrace 6 Det forsøges at logge ind med en korrekt bruger og kode 7 Det forsøges at logge ind med en forkert bruger og Der returneres en fejlmeddelelse Kvittering vises og Tag- Trace databasen undersøges for korrekt data Der returneres en fejlmeddelelse Der vises en liste med information registreret om tagget Brugeren logges ind Brugeren præsenteres for en fejlmeddelelse kode 8 Det forsøges at logge ud Brugeren logges ud og login skærmen vises Som forventet, dog siger fejlmeddelelsen ikke noget om hvad fejlen er Som forventet, dog er tagget ikke flyttet til den ønskede lokation, da denne del ikke er understøttet af TagTrace databasen endnu Som forventet, dog siger fejlmeddelelsen ikke noget om hvad fejlen var Som forventet Som forventet Som forventet Som forventet

54 48 KAPITEL 6. TEST 6.5 Generelt Test af funktioner der ikke passer ind i andre kategorier. Tabel 6.5: Generelt Test Handling Forventet resultat Faktisk resultat 1 En række handlinger udføres på enheden og logfilen Alle handlinger er logget med tidsstempel og en Stort set som forventet, ikke alle metoder skriver undersøges beskrivelse der giver til loggen 2 Der klikkes på opsætning og en værdi ændres og gemmes. mening Næste gang programmet startes bruges den nye værdi Som forventet 6.6 Supplerende Kravspecifikation Krav til Udstyr Punktet er opfyldt fuldt ud, da alt kommunikation med hardware er placeret i et selvstændigt bibliotek der er fuldt udskiftbart Bruger Karakteristika og Brugervenlighed Punktet er testet, og de brugere der har haft mulighed for at prøve programmet har udvist tilfredshed med opbygningen af menuer og knapper Begrænsninger Punktet er opfyldt, der er implementeret brugerkontrol i den håndholdte applikation. Login og logout gemmes i logfilen til senere brug.

55 6.6. SUPPLERENDE KRAVSPECIFIKATION Fejlhåndtering Fejlhåndtering er implementeret, dog er der ikke implementeret mulighed for at returnere detaljerede fejlbeskeder Performance Performance har ikke kunnet testes fuldt ud, da alle test er udført på en udviklingsmaskine. Test har dog vist at punktet kan overholdes, men at det afhænger af netværket og serverens belastning.

56

57 KAPITEL 7 Konklusion Lagerstyringsløsninger benytter i dag stregkoder til at bestemme lokationen på et produkt. Dette kræver mange manuelle arbejdsgange og der er risiko for menneskelige fejl. Indførelsen af RFID mærkning på produkter og paller giver mulighed for automatisk at checke om et produkt flyttes til et forkert sted. I forbindelse med indførelsen af RFID ønskes det at udvide programmet TagTrace med en håndholdt klient til læsning af RFID tags og stregkoder. Der ønskedes udviklet en prototype for at vise, om det er muligt at bruge TagTrace og TagTrace databasen i forbindelse med en håndholdt enhed. Der er udviklet en prototype, der benytter TagTrace webservices til kommunikation og som indeholder funktionalitet til registrering og visning af information om tags. Programmet fungerer efter hensigten og viser at det er muligt at udvide TagTrace med en håndholdt enhed. Det var et ønske at programmet skulle understøtte videreudvikling til enheder med Windows Mobile og forskelligt hardware og dette er lykkedes fuldt ud, ved at flytte hardwarespecifik funktionalitet ud i separate biblioteker. Testen viser at programmet fungererer og at det er muligt at arbejde videre på den påbegyndte model. 51

58 52 KAPITEL 7. KONKLUSION Udviklingsmuligheder Da programmet fungerer efter hensigten og de opstillede mål er nået, er det oplagt at undersøge, hvad der kræves for at færdigudvikle prototypen. Følgende liste opsummerer nogle af de vigtigste punkter der bør eller skal udvikles for at gøre programmet klar til videre brug. Færdigudvikling af Webservice - det er nødvendigt at færdigudvikle webservicen, herunder videreudvikling af TagTrace databasen, så den understøtter alle muligheder, som TagTrace Handheld tilbyder. Implementering af Caching - for at spare på kald til webservicen, vil det være en fordel at implementere en data cache. Denne kan implementeres som en komponent i forbindelse med datalaget og vil her være usynlig for resten af applikationen. Kryptering af forbindelse - kryptering ved hjælp af en standard https protokol kan forholdsvis simpelt implementeres. Dette vil sikre data sendt mellem TagTrace og TagTrace Handheld. Gemme fejlmeddelelser på server - en central logfunktion på serveren vil være at foretrække, dermed kan en administrator lettere fejlsøge og hjælpe en bruger.

59 BILAG A Grafik 53

60 54 BILAG A. GRAFIK Figur A.1: Overordnet systemsammenhæng

61 Figur A.2: Intermec CN3 med IP30 monteret 55

62 56 BILAG A. GRAFIK Figur A.3: 2Trace systemsammenhæng

63 BILAG B Screenshots Figur B.1: Login 57

64 58 BILAG B. SCREENSHOTS Figur B.2: Hovedmenu Figur B.3: Pluk - Foretag skærmbillede Figur B.4: Pluk liste skærmbillede Figur B.5: Pluk skærmbillede

65 59 Figur B.6: Pluk - Manglende info skærmbillede Figur B.7: Pluk - færdig skærmbillede Figur B.8: RFID skærmbillede Figur B.9: RFID skrevet skærmbillede

66 60 BILAG B. SCREENSHOTS Figur B.10: Setup skærmbillede Figur B.11: Setup - Afslut skærmbillede Figur B.12: Debug skærmbillede

67 BILAG C CD På vedlagte cd findes: Rapporten i pdf format Kildekode og eksekverbare filer til TagTraceHandheld Kildekode til TagTraceWebservice Alt indhold på cden kan desuden hentes i zip format på bachelor.zip. 61