System/produkt designdokument for Danish Rox

Transkript

1 System/produkt designdokument for Danish Rox Dansk Beton

2 Revisions historie Dato Version Beskrivelse Forfatter Her blev vores rapport helt færdig. Gruppe 2 0

3 Indholdsfortegnelse 1. INTRODUKTION Formål og omfang Referencer Definitioner og forkortelser Dokumentstruktur og læsevejledning Dokumentets rolle i en iterativ udviklingsproces SYSTEM OVERSIGT System kontekst System introduktion SYSTEMETS GRÆNSEFLADER Grænseflader til person aktører Grænseflader til eksterne system aktører Grænseflader til hardware aktører Grænseflader til eksterne software aktører Fra usbc.dll til C# kode Vægt LOGICAL VIEW Doxygen Implementering Doxygen klasse dokumentations eksempel For at se dokumentationen om klassen: Model.User Doxygen er dejlig Developmentview Oversigt over systemkonfigureringer Oversigt over systemkonfigurationer Systemkonfigureringer PROCESS VIEW Trådkommunikation Oversigt over processer PhysicalView Komponentbeskrivelser Database Vægt Robot GUI SCENARIOS VIEW Data model Implementering af persistens GENERELLE DESIGNBESLUTNINGER Arkitektur mål og begrænsninger Arkitektur mønstre

4 9.2.1 StrategyPatterns Patterns anvendt i robot dll ObservableCollections IChanged interface IDetailsName interface PluralNameAttribute Generelle brugergrænsefladeregler Exception og fejlhåndtering Implementeringssprog og værktøjer Implementeringsbiblioteker STØRRELSE OG YDELSE Oversættelse Oversættelse og linkning Kompilering af TheClawInterface Kompilering og programmering af ATMega Installation Prerequirements Installation af Database Installation af TheClawInterface KØRSEL Kørsels-hardware Kørsels-software Start, genstart og stop Fejludskrifter Fejludskrifter til robot dll HENVISNINGER

5 1. INTRODUKTION 1.1 Formål og omfang Dette er designdokumentet for projektet Danish Rox. Designet har taget udgangspunkt i opstillingen for Scorbot ER-4u med tilhørende Controllerbox, transport bånd, sensor og vægt. Dette dokument tjener formålet at give læseren et dybdegående indblik i de beregninger og metoder, der er blevet brugt til at udvikle dette projekt. Der vil i dette dokument blive redegjort for de designvalg vi har truffet i løbet af projektudviklingen. De valg vi har truffet vil blive uddybet. Der vil i stort omfang blive henvist til dette dokument fra hovedrapporten. Ligeledes vil der i dette dokument blive henvist til kravspecifikationen. Dette dokument skal derfor vurderes sammen med andre dele af projektdokumentationen. Dokumentet vil tydeligt fremstå meget teknisk, derfor forudsætter forståelse af indholdet, et indgående kendskab til teori og praktisk erfaring med projekter at denne type. Vi opfatter projektet som et produkt udviklet til Scorbot ER-4u. 1.2 Referencer - Kravspecifikation for DanishRox fra firmaet Dansk Beton 1.3 Definitioner og forkortelser Brugte forkortelser: I4PRJ4: Ingeniørhøjskolen Århus Projekt 4 Grp. 2: Styringsgruppen for Software Udvikling til projektet HW: Hardware SW: Software UML: Unified Modeling Language GUI: GraphicalUser Interface KISS: Keep It Simple and Stupid 3

6 1.4 Dokumentstruktur og læsevejledning Til at beskrive arkitekturen for vores projekt har vi valgt at benytte 4+1 ArchitectualView Model. Modellen bruges til at beskrive arkitekturen for SW systemer. De forskellige views bruges til at beskrive systemet fra flere vinkler. De 4 views er Logical view, Development view, Process view og Physical view. Det sidste view i modellen, +1 view, bruges til at beskrive systemet eller funktioner heri ved hjælp af use cases. Figure1 - Logicalview omhandler systemets funktionalitet for slutbrugeren. Ofte beskrevet ved hjælp af UML diagrammer som f.eks. klassediagrammer. - Developmentviewviser systemet fra programmørens synsvinkel. Det bruger UML komponent diagrammer til at beskrive systemets komponenter. Der bruges samtidig UML pakke diagrammer i dette view. - Processview omhandler det dynamiske aspekt af systemet. Heri forklares hvorledes systemets processer kommunikere med fokus på runtime som f.eks. skalerbarhed og ydeevne. Til at beskrive dette view benyttes aktivitets diagrammer. - Physicalview beskriver systemet fra ingeniørens synspunkt. Dette view er bedre kendt som Deploymentview og beskriver systemets opstilling, når det er færdigt udviklet og opstillet ude hos slutbrugeren. Der bruges UML deployment diagrammer 4

7 til at beskrive dette view. - Scenarios beskriver arkitekturen ved hjælp af use cases, eller scenarier, som bliver det femte view. Scenarierne beskriver sekvenser mellem objekter samt processer. Her bruges UML use case diagrammer til at beskrive dette view. 1.5 Dokumentets rolle i en iterativ udviklingsproces Der bliver løbende i dette projektforløb taget noter til de valg og de diskussioner vi har haft angående udviklingen af systemet. De enkelte designmæssige valg vil blive uddybet og vurderet i dette dokument. De enkelte afsnit i dette dokument vil løbende blive udfyldt i udviklingsprocessen. 5

8 2. SYSTEM OVERSIGT Her henvises til kravspecifikationen punkt 2.1 systembeskrivelse og punkt systemoversigt 2.1 System kontekst Nedenstående figur viser aktørerne Bruger/Administrator, GUI, Vægt, Robot/Controllerbox, Transportbånd/Sensor, Keyboard/Mouse og VoiceDetector i et aktør kontekst diagram. Hvorledes de enkelte aktører interagere er uddybet i nedenstående MMI figur. class UC proj... User/Admin System GUI VoiceDetector Weight Keyboard/Mouse Robot/Controllerbox Conv eyerbelt/sensor Figure2 Nedenstående figur viser MMI (Man Machine Interface) til de aktører der anvender systemet. 6

9 Figure3 Brugeren er hoved aktøren i vores udviklede system. Brugeren logger på systemet og manipulerer med GUI vha. input devices som Keyboard, Mouse samt VoiceDetector. Når der bliver logget på systemet, brugt input devices eller der bliver ændret i værdierne i database, vil disse ændringer/handlinger blive logget i database. Samtidig vil der blive logget data på et BatchJob, når brugeren vælger at starte et. I gennemkørselen af et BatchJob anvendes først Conveyorbelt og Sensor. Herefter måler robotten siderne på elementet og flytter dette til Weight. Herefter logges oplysningerne om de enkelte elementer ligeledes i database. 7

10 2.2 System introduktion Systemets formål er at automatisere en manuel proces. Dette sker ved implementeringen af Scorbot ER-4u robotten samt programmel, der afvikles på en PC. Denne gør det muligt for en burger at styre samt at programmere robotten, til at udføre specifikke operationer, inden for robottens rækkevidde. De komponenter, som vores system består af, er beskrevet i punkt 2.1. Hovedfunktionaliteten består i at indsamle informationer og dimensioner om de elementer der placeres på transportbåndet, og efterfølgende på vægten, samt at placere disse i de korrekte opbevaringsrum. Informationerne og dimensionerne på disse elementer skal samtidig registreres, i den dertil udviklede database, i specifikke logs. Der vil på PC en være udviklet en GUImed henblik på brugervenlighed og på at minimere antallet af klik for at nå til målet. Ved hjælp af GUI en kan brugeren se logs hvis der skulle være sket nogen fejl i systemet. Brugeren kan desuden redigere users, robots, batch jobs og batch job task positions. Desuden vil det, vha.voicedetectoren, være muligt via stemmestyring at starte og stoppe et BatchJob. 8

11 3. SYSTEMETS GRÆNSEFLADER I dette afsnit beskrives grænsefladerne for brugere af systemet GUI. 3.1 Grænseflader til person aktører Bruger tager initiativ til at logge på PC en, åbne og browse i de forskellige logs, oprette Batch Jobs samt at aktivere og manipulere med robotten Scorbot ER-4u. Figure4 - Screenshot af GUI main Systemet har en grafisk brugergrænseflade som afvikles på PC. Den grafiske brugergrænseflade vil indeholde følgende informationer: 1. Log in window Figure5 - loginwindow 2. Hoved window The Claw Interface indeholder menu bar med: a. File Figure6 b. Robot 9

12 Figure7 c. User Figure8 d. BatchJob Figure9 e. Log 10

13 Figure10 1. Log Level Figure11 2. Types Figure12 f. Help Figure Grænseflader til eksterne system aktører I nedenstående tekst stykke beskrives den kommunikationsprotokol der bruges for at kommunikere med vores database. Til at kommunikere med SQL serveren, har vi brugt LINQ (LanguageIntegrated Query) lag. LINQ laver forarbejde for os, og fungerer som et klasse-agtigt interface til vores database. Det gør det nemmere at opdatere databasen, f.eks. ved INSERT, UPDATE, DELETE. Udover er det nemmere at detektere fejl når man ændre i sine tabeller i databasen. Det man gør er at slette de gamle tabeller, indsætter de nye og compilere koden. Gør man dette får man en compilerings fejl. Dermed er det mere sikker kode, fordi compileren kan fortælle os 11

14 om vores fejl og derfor skal vi ikke køre så mange tests og sørge for alle mulige undtagelses/exception håndtering. 3.3 Grænseflader til hardware aktører Beskrivelse af kommunikationen mellem de enkelte HW enheder og hvordan systemet er koblet sammen. - Scorbot ER-4u robotten er forbundet til Controller USB indgang 9 (Robot 62-pin D- type highdensityconnector) - USB indgang på PC er forbundet til Controller USB indgang 8 (Robot 62-pin D-type highdensityconnector) - Controller USB powerkabel er forbundet til indgang 8 (Power Line 110/220VAC socket) - Sensoren er forbundet til controller USB via indgang 10 (Digital Input / Output terminals terminal 1, samt opencollecter + og -). - Conveyorbelt (transportbåndet) er forbundet til Controller USB via AXIS 8 (Axes 7 and 8 driver D9 connectors (separate for eachdevice)) indgangen. - Vejecellen er forbundet til operationsforstærker AD620 som er forbundet til STK500 KIT som er forbundet til RS232 som er forbundet til PC en. - LCD Display AVR181 er forbundet til STK500 KIT - Der er brugt seriel com port til at kommunikere mellem PC og vejecellen, og data sendes via et RS-232 kabel 3.4 Grænseflader til eksterne software aktører Beskrivelse af kommunikationen i SW enheder Fra usbc.dll til C# kode Til robot armen Scorbot-ER 4U er der leveret en dll, usbc.dll, som man kan kode op imod for at lave sin egen software til styring af robotten. Denne dll komponent er skrevet i c++. Udfordringen med at bruge den, har været at få C#, som er managed kode til at snakke sammen med en c++, som er unmanaged kode. Udfordringen her ligger i at når vi eksempelvis opretter en pointer i C# og den peger på noget 12

15 data som bliver leveret af c++, kan garbagecollectoren ikke se at pointeren peger på noget. Dette betyder at, hvis der ikke bliver gjort noget, vil pointeren blive garbagecollectet. Dette har vi løst ved at bruge Pinvoke (Platform Invoke). Pinvoke er den del af CLR en - CommonLanguageRuntime. Disse metoder kan sørge for at få denunmanaged kode til at snakke sammen med den managed del vi laver i C#.net. Der findes en del funktioner under Pinvoke som vi har brugt f.eks. DllImport. DllImport er den metode vi anvender til at importere funktioner fra usbc.dll en. For at kunne bruge denne funktion skal man kende de entrypoints der er til dll en. Disse kan findes ved at åbne sin VisualStudiocommandopromt naviger hen til dll en. Når du står i biblioteket hvor dll en ligger skriv: dumpbin /exports usbc.dll > entrypoints.txt. Så vil alle entrypoints blive eksporteret til.txt filen. CallingConvension er den måde usbc.dll en vil blive kaldt på. Når disse funktioner er kaldt, kan man kalde sin funktion i dll en. Ud fra dokumentationen kan vi se at vores initialisering tager 4 parametre og herved kan vi bygge alle de funktioner op vi skal bruge. Alle metoder bliver oprettet som statiske eksterne funktioner. [DllImport(C:\\USBC\\USBC.dll, EntryPoint = "?Initialization@@YAHFFP6AXPAX@Z1@Z", CallingConvention = CallingConvention.Cdecl)] publicstaticexternbool InitializationDll(short smode, short ssystemtype, CallBackInitPtr fninitend, CallBackErrorPtr fnerrmessage); Efterfølgende lavede vi en wrapperklasse efter adapterpattern ideen, til at pakke kaldenetil robotten ind i. publicvoid InitializeRobot() { DllKald.InitializationDll(1, 0, initptr, errorptr); } Alle disse metoder bliver i sidste ende publiceret i et interface så det er nemt for den der skal snakke sammen med robotten at se hvilke metoder der er tilgængelige. Eksempelvis når vi skal lave vores simulator kan vi bare implementere det interface vi har lavet og så bør alle klasserne være implementeret. Så alt i lagene ovenover fungere, når interfacet er implementeret. voidinitializerobot(); Dette løser problemet med at få funktionerne ind i vores program, det andet problem der skal løses er den managed/unmanaged udfordring. Dette løses med Marshal keywordet. Med 13

16 marshal.allocglobal laver man en portionunmanagedramplads som kan anvendes uden at garbagecollectoren kommer og tager det. Ieksemplet neden for er det en stump på størrelse med et ConfigDataobject. Her efter laver vi så en pointer til configdata som vi kan bruge til at sende over til robotten. Efterfølgende vil robotten kunne returnere data til den lille stump unmanagedramplads, hvor vi så kan hente dataene fra. publicintptr InitConfigData(ConfigData configdata) { IntPtr configdataptr = Marshal.AllocHGlobal(Marshal.SizeOf(typeof(ConfigData))); Marshal.StructureToPtr(configData, configdataptr, false); returnconfigdataptr; } Til sidst når vi er færdig med at bruge vores unmanagedramplads er det vigtigt at vi deallokerer den igen så vi ikke fårmemoryleaks i vores program. Dette gøres ved at kalde Marshal.FreeHGlobal, herved bliver hukommelsen deallokeret igen. publicvoid ReleaseStructs() { Marshal.FreeHGlobal(configDataPtr); } I USBC.dll en er der mange metoder man kan importere. Vi har valgt dem vi syntes var mest interessante for vores system. De metoder vi har valgt at implementere er som følger. WatchMotion() GetCurrentPosition() CloseWatchDigitalInp() WatchDigitalInp() DefineVector() Teach() MoveLinear() CloseUSBC() Stop() Initialization() Home() Control() 14

17 CloseGripper() OpenGripper() GetJaw() CloseManual() MoveManual() EnterManual() IsOnlineOk() Den totale liste af eksporterbare metoder kan ses i den udleverede dokumentation, der ligger i BILAG - USBC-documentation.pdf og man kan se de mountpoints vi har eksporteret i bilags filens funktions Liste fra usbc.dll.txt Vægt Nedenstående tekst omhandler de beslutninger der er fortaget i forbindelse med implementeringen af interfacet til vejecellen i vores system. I projektet skulle vi finde densiteten for nogle elementer. Til dette skulle vi implementere en vægt, da vægten ikke er en del af robotsystemet, for at veje elementerne. Til dette formål har vi brugt CodeVision, STK50-kit, LCD-display af typen AVR181, vægtcelle af typen MP40, en operations forstærker af typen AD620 og MS Excel til rådighed. Vi startede med at programmere ATMega 16 chippen på STK500 kit ved hjælp af CodeVision. Formålet var at få outputtet fra vægtcellen ud på displayet og sendt dataene over COMPORT via serielkabel(rs232). 15

18 4. LOGICAL VIEW I LogicalView vises systemets funktionalitet for slutbrugeren. Dette sker fortrinsvist gennem klasse diagrammer og des lige. Vi har dog valgt at dokumentere vores klasser vha. programmet Doxygen v1.6.1 Nedenstående tekst er en beskrivelse af værktøjet Doxygen, samt implementeringen af dette. 4.1 Doxygen Implementering Doxygen er et opensource værktøj, som kan scanne og analysere ens kildefiler og derefter skabe brugbar dokumentation. Denne dokumentation kan være i form af html-filer, latex-dokumenter eller andre formater. Filosofien bag programmet er, hvis man skal skrive kommentarer i ens kildekode, så kan de ligeså godt bruges til noget fornuftigt. Måden det virker på, er at man bruger nogle tags i ens normale kommentarer, som doxygen kan genkende. Hermed skabes sigende beskrivelser af ens klasser, metoder, variabler osv. Kigger man den genererede dokumentation igennem, vil man blive mindet om at kommentere alle ens funktioner. Dette giver nogle kildefiler, man nemmere kan tage frem på et senere tidspunkt og have let ved at forstå. Programmet kan hentes på og ligger som bilag på vedlagte cd-rom. Manualen til programmet med beskrivelse af tags og eksempler er også vedlagt. For at bruge programmet bruges Doxygen GUI frontend. Der skal vælges en konfiguration, gemmes en konfiguration, vælges et workingdirectory og til sidst trykkes på Start. Ved at trykke på knappen Wizard får man 4 faneblade frem til at konfigurere med. I Project indtastes projektets navn, version, hvor kildefilerne ligger og hvor dokumentationen skal placeres. 16

19 Figure14 - Doxygen GUI Figure15 - Doxywizardproject I Mode vælges All entities og Optimize for C# output. Fig : Doxygen GUI Fig : doxywizard Project I Output sættesfluebeni HTML og with frames and a navigation tree vælges. I Diagrams vælges Use built-in class diagram generator. Figure16 - Doxywizard Mode Figure17 - Doxywizard Output doxywizard Mode doxywizard Output Figure18 - Doxywizard Diagrams Efter dokumentationen doxywizard Diagrams er skabt, kan man åbne index.html i folderen html inde i den valgte dokumentfolder. For at hjælpe med at danne de rigtige tags, og skabe kommentarer en smule hurtigere, benyttede vi doxycomment. Dette er en addon til Visual Studio, som implementerer 3 knapper i VS2008 (fig ). 17

20 Figure19 Trykker man på AddCodeComment bliver der tilføjet doxygen kommentarer og tags til den klasse/funktion/variabel man står i. 4.2 Doxygen klasse dokumentations eksempel Alt vores.net kode er dokumenteret inline i vores source filer. Vi har via Doxygen trukket det hele ud, for at få en html dokumentation over alle namespaces, classes, methods, properties og enums. Man kan også se arve hierarkiet og en masse andre nyttige informationer om vores struktur. 18

21 4.3 For at se dokumentationen om klassen: Model.User. 1. Åbnes dokumentationen på CD en. Klasse Dokumentation\html\ Figure20 2. Der klikkes så på Classes 3. Her kan den indbyggede søge funktion i Internet Explorer eventuelt bruges eller der kan scrolles ned i listen for at finde Model.User. Klik på Model.User Figure21 19

22 4. Øverst på siden kan der ses hvad klasser/interfaces den arver fra. Figure22 5. Længere nede på siden kan public properties og methods på klassen ses. Figure23 20

23 4.4 Doxygen er dejlig Det er utroligt nemt at bruge og giver et godt overblik for en ny udvikler som skal sætte sig ind i systemet. Figure24 21

24 5. Developmentview I Developmentviewvises systemet fra programmørens synsvinkel. Vi har valgt at opdele systemet i en 3-tier-model, som vises nedenfor. Denne model giver et overordnet overblik over hele systemet, samtidig med at de enkelte tiers er defineret. Hermed fremgår det tydeligt hvorledes systemet er koblet sammen og hvordan de enkelte lag kommunikerer med hinanden. 22

25 5.1 Oversigt over systemkonfigureringer Nedenstående figur 25 viser 3-tier-model for vores system. Figure25 23

26 For at se omfattende dokumentation om de enkelte klasser, henviser vi til punkt 4.3 i system design dokumentet. Nedenfor er de enkelte 3-tier-model lag beskrevet. Presentationlayer: I presentationlayer ligger vores RobotGUI. GUI en (graphicaluser interface) vil gøre det muligt for brugeren at interagere med robotten. Business layer: Her ligger alt vores funktionalitet. Funktionaliteten i robotsystemet er indkapslet i pakke diagrammer efter namespaces. Hvert namespace har en eller flere funktionaliteter Data accesslayer: Det sidste lag i robot systemet er data accesslayer. Dette lag giver adgang til databasen. F.eks. når vi skal inserte, update eller delete databasen. Dette gøres vha. LINQ to SQL. 5.2 Oversigt over systemkonfigurationer 5.3 Systemkonfigureringer Hvis man skal sætte robotten i simulations/ real mode kan man se på nedenstående billede, hvordan dette konfigureres Figure26 - screenshotbeskriv de forskellige mulige konfigureringer eller en prototypisk konfigurering. 24

27 6. PROCESS VIEW I ProcessView vises det hvorledes enkelte processer i systemet kommunikere. Da vi har få tråde er det let at overskue hvordan de kommunikerer. Derfor er der ligeledes ingen bekymringer hvad angår skalerbarhed, runtime samt systemets ydeevne. 6.1 Trådkommunikation Da USBC.dll en er opbygget asynkron, har vi i vores implementereting gjort den synkron, så vi bedre kan styre den fra vores BusinessLogic.RobotController klasse. På nedenstående diagram vises det hvorledes de to tråde synkroniseres. Figure27 25

28 6.2 Oversigt over processer Da der kører flere tråde i vores program, er det ikke altid tilladt at tilgå visse af disse kontroller fra en tråd, som ikke har oprettet dem. Derfor skal man altid sørge for, at man har adgang til at tilgå den pågældende kontrol. På nedenstående aktivitets diagram har vi prøvet på at demonstrere det. Hvis tråden ikke har adgang til den kontrol, den vil tilgå, fortæller den kontrollens ejer, at den skal udføre en metode på den kontrol. Den bliver så smidt i en kø, der vil afvikle den, så snart der er tid. Figure28 26

29 7. PhysicalView PhysicalView beskriver systemet, set fra en software udviklers synspunkt, som en samlet software pakke. Denne software pakke er implementeret i den fysiske hardware. Den fysiske hardware er vores egentlige deployment. På nedenstående diagram vises et deploymentview over vores system som HW/SW enheder. Deployment diagram Figure29 På diagrammet ses hvorledes de enkelte HW enheder er forbundet og hvorpå SW ligger. 27

30 Figure30 Her ses den fysiske opstilling Figure31 USB Controller 28

31 7.1 Komponentbeskrivelser I de nedenstående punkter er de enkelte HW/SW komponenter for vores system beskrevet Database Databasen ligger på IHA s netværk (webhotel10.iha.dk) Database server komponenten har ansvaret for at lagre data i databasen, så f. eks data fra en proces kan opbevares og manipuleres. Derudover skal man være forbundet til IHA-VPN forbindelse for at kunne anvende E09I4PRJGr2 databasen. Første brugbare version af database bestod i at logge en Bruger og Robot. Senere hen implementerede vi også et BatchJob. Derefter testede vi, at vi kunne indsætte, updatere, delete og ændre noget i vores database. Nedenstående diagram er ER diagrammet over vores database 29

32 Figure32 På ovenstående diagrammet kan man se en oversigt over de enkelte entiteter i vores database og data flowet i vores system. Derudover kan man se på de forskellige fremmede nøgler hvordan relationerne mellem tabellerne hænger sammen. Endvidere kan man se attributterne for hver tabel der er i databasen. Det røde U angiver, at attributten er unik. 30

33 Vi har i dette projekt valgt at implementere 3 forskellige Stored Procedures i vores database. Stored Procedures: Figure33 Stores procedures Vi har besluttet os for at oprette nogle Views fordi vi gerne vil beskytte noget af vores data. Samtidig må visse brugere kun se dele af dataene. Et View består af nogle rækker og koloner ligesom i en rigtig tabel, men et viewer aggregeret af data fra andre tabeller. Vi har i dette projekt valgt at oprette 3 forskellige Views i vores database. Figure34 - Screenshot af valllogs 31

34 Figure35 - Screenshot af vuserlogs Figure36 - Screenshot af vrobotlogs 32

35 7.1.2 Vægt Til robot systemet er der skrevet i C# med udviklingsværktøjet Visual Studio Til at programmere ATMega 16 chippen har vi skrevet i C med CodeVision AVR Studio. Der er brugt SQL Server Management Studio 2008 til at udvikle databasen. For mere uddybende forklaring til værktøjerne, refereres der til Hovedrapporten under punktet Udviklingsværktøjer. Opstillingen af vægten består af en vægtcelle MP40 er koblet sammen med en AD620 operationsforstærker. Det analoge signal bliver forstærket. Dette forstærkede signal bliver sendt over til en ADC på STK500 kit som behandler signalet og konverterer det til et digitalt signal som sendes via et seriel kable RS-232 til PC en. Figure37 Vejecellens output giver et analog signal fra 0-10 V. Dette signal sendes gennem AD620, bliver delt op, og forstærket 2 gange. Derefter bliver det ene signal inverteret og adderet for at undertrykkecommon mode støj med 120 db. Figure38 Dette signal sendes til ATmega16 s indbyggede A/D konverter. ADC initieres til port A ben 0 som defineres til input. Vi enabler ADC hvor prescaleren bliver sat til Hz, da 33

36 ADC en skal køre mellem KHz for at undgå aliasering. Signalet konverteres vha. successive approximation som ses ved nedenstående figur. Figure39 Et analog signal kommer ind og bliver holdt i hold registret indtil konverteringen er færdig. D/A omsætteren gætter på værdien af det analog signal indtil det rammer det rigtige. Efter konvertering sendes signalet videre af kontrolregistret. Det digitale signal bliver nu lagret i en variable af typen long int. For at kunne sende over serielt kabelvha. seriel kommunikation, blev vi nødt til at konvertere signalet til char * (string). Når vi modtager signalet på PC siden, konverterer vi det til int. Denne værdi bruges af andre klasser til beregning af densiteten. For at programmere ATMega16 chippen, som ligger på STK 500 kit, kan det gøres vha. Code Vision AVR Studio. Dette bliver implementeret i C-kode. Når vi skal modtage signalet, har vi implementeret det i C#. Det digitale signal bliver behandlet i ATMega16 chippen. Det konverterede signal er af typen double, hvilket vi konverterer til enchar, for at sende over serielt kabel RS-232. Vi har desuden tilkoblet et LCD display af typen AVR 181, for at bekræfte at værdien er indenfor et passende interval. 34

37 Til at modtage signalet på PC siden, har vi lavet et interface, implementeret i C#, som læser fracomporten (IO enhed). Det modtagne signal, som er en streng, konverteres til en int Robot Da vi skal ned og kommunikere med robotten skal vi først finde ud af hvordan funktionaliteten i USBC`en er defineret. Dette kan ses i pkt 3.2 i designdokumentet. Vi kan nu vha. Visual Studio 2008 importer de funktioner der ligger i USBC`en. Disse funktioner importerer vi i klassen RobotInterface.DllCall, som vi kan bruge i Robot-klassen til at definere vores egne funktioner. Figure40klasse diagram for RobotInterface klassen Den ovenstående figur viser det overordnede klassediagram for robotinterfacet. Vores Adapter-patterns er RobotInterface.Robot-klassen sammenkoblet med DllCall-klassen. De andre klasser er beskrevet nedenfor. For omfattende information omhandlende de enkelte klasser se da venligst //klasse dokumentation/html/index.htmpå CD en ConfigData-klassen: den holder på de configurationsdata vi får fra robotten. ErrorInfo-klassen: Hvis der opstår en error, er det via denne klasse robotten giver os 35

38 fejlmeddelelsen. CallBack-klassen: Den bliver brugt til de callbacks robotten giver os. DataPoint-klassen: den holder dataene i hukommelsen, så garbagecollectoren ikke kommer og tager dem. RobotPoint-klassen: den holder de koordinater som robotten skal bruge. PositionVector-klassen: den har en liste af RobotPoint, som den kan lagre i robotten. Robot-klassen: det er her vi implementerer de funktioner, som RobotInterface skal have GUI Efter tilføjelser er commited til databasen, kan de ikke slettes igen. Grunden til de ikke kan slettes er for at opretholde dataintegriteten. De fleste data kan dog stadig ændres, for at give en vis fleksibilitet. User Oplysninger om en bruger i systemet. Tilføje nye brugere til systemet. Felterne Username/Password/Name kan ændres som man vil. Dette kan være meget praktisk hvis man har en gæste bruger Guest, men gerne vil have hans navn ind i systemet. Hvis en bruger forlader firmaet kan man disable ham, ved at uncheck boksen. Bruger kan få yderligere rettigheder ved at få checked boksen ud for admin. Robot En robot i systemet som kan sættes til at udføre et BatchJob. Tilføje nye robotter. Ændrer robottens location hvis den bliver flyttet internt i firmaet. Hvis en robot ikke længere er aktiv eller er gået i stykker, kan Active sættes som unchecked. BatchJob Består af Name og KeepRunning, og en liste af BatchJobTaskPositions som den skal udføre når jobbet startes. Name kan blive brugt til at give et logisk navn, 36

39 udover det ID den får autogenereret. Så den er nemmere at finde igen. KeepRunning er unchecked hvis den kun skal køre en gang. Tilføje nye BatchJobs. Tilføje BatchJobTaskPositions til listen af ting der skal udføres. Rækkefølgen kan ændres via Drag n Drop. Fjerne BatchJobTaskPositions som ikke længere skal udføres. BatchJobTaskPosision indeholder information om hvad robotten skal udføre. Efter et BatchJobTaskPosition oprettet og gemt i databasen, kan det ikke slettes. Dette gøres for at undgå et BatchJob mister tasks. Ændre X, Y, Z, Pitch og Roll som bruges til nogen af opgave typerne. Ændre opgave type, f. eksmovelinear, OpenGripper, CloseGripper, etc. Yderligere kan der slås forskellige loggers til: GuiLogger Logger løbende til GUI en mens programmet kører. LogLevel kan ændres alt efter om man kun vil have fejl logget. 37

40 8. SCENARIOS VIEW I dette afsnit omtales vores use cases. De enkelte use case scenarier er uddybende beskrevet i kravspecifikationen punkt 3 og frem. På nedenstående UC diagram vises en oversigt over de scenarier vi har udarbejdet use cases for. Figure41 Figur 41 viser de scenarier der spiller en central rolle for vores system. De repræsenterer dermed alle vigtig funktionalitet for vores system og kan ikke undlades. 38

41 8.1 Data model De arkitekturer signifikante dele af datamodellen, hvad angår f.eks. stored procedures, views osv., er beskrevet i punkt Database. 8.2 Implementering af persistens I dette tekst afsnit beskriver vi hvordan vi persistere vores data i systemet. Til at persistere vores data anvender vi LINQ2SQLframeworket. Dette framework gør det lettere at lave forspørgelser til databasen. Samtidig sørger detteframework for at de data der bliver anvendt i systemet bliver gemt hvis de er blevet ændret siden sidste save. Her er der flere funktioner der hjælper udvikleren bl.a. SubmitChanges, Delete osv. Brugen af dette frameworkafkobler afhængigheden fraden specifikke database vi laver forspørgelser til. Frameworket er med til at minimere den mængde af SQL queries som ellers skulle laves. 39

42 9. GENERELLE DESIGNBESLUTNINGER I neden stående afsnit skriver vi om de design mønstre og værktøjer, som er blevet anvendt i projektet 9.1 Arkitektur mål og begrænsninger Målet for vores arkitektur var at lave en komponent baseret struktur så det er nemmere at opdele projektet i sub-systemer. Både for at øge muligheden for genbrug men også for at kunne udvikle komponenterne parallelt. 9.2 Arkitektur mønstre StrategyPatterns Figure42 - Klasse diagram af AllLog Vi har brugt Strategy design mønstret, da vi har nogle metoder der minder meget om hinanden, men de er implementeret til at udfører noget forskelligt. Vi har valg, at bruge dette design mønstre, da indkapslingen af hver metode gør at de nemmere kan skiftes ud og der kan tilføjes andre metoder. Mere info kan ses i bogen - Craig Larman - Applying UML and patterns 3. ed. s. 447 Singleton 40