Projekt: I4PRJ4 Dato: 18/12 2009 Titel: for Danish Rox
Dansk Beton Versionshistorie Ver. Dato Initialer Beskrivelse 1.00 12.09.09 Gr. 2 Use Cases beskrivelse 1.1 15.10.09 Gr. 2 Beskrivelse af hardware 1.2 16.10.09 Gr. 2 Funktionalitet Godkendelsesformular Forfatter(e): Gruppe 2 I4PRJ4 Godkendes af: Indsæt intern og evt. ekstern godkender Projektnummer: Dokument-id:.docx (filnavn) Antal sider: 23 Kunde: Intern projekt Ved underskrivelse af dette dokument accepteres det af begge parter, som værende kravene til udviklingen af det ønskede system. Sted og dato: <kunde underskrift> <leverandør underskrift> 1
Indholdsfortegnelse 1. INDLEDNING... 3 1.1 Formål... 3 1.2 Referencer... 3 2. GENEREL BESKRIVELSE... 4 2.1 Systembeskrivelse... 4 2.1.1 Systemoversigt... 4 2.1.2 Aktør-kontekst diagram... 5 2.1.3 Aktørbeskrivelser... 6 2.2 Systemets funktioner... 8 2.2.1 Use Case diagram(-mer)... 8 2.3 Systemets begrænsninger... 9 2.3.1 Omkring Robottens begrænsninger... 9 2.4 Systemets fremtid... 9 2.5 Brugerprofil... 9 2.6 Krav til udviklingsforløbet... 10 2.7 Omfang af kundeleverance... 10 2.8 Forudsætninger... 11 3. FUNKTIONELLE KRAV USE CASES... 12 3.1 Normal scenario for registrering af et element... 12 3.1.1 Use Case 1: Log In... 13 3.1.2 Use Case 2: Brugeren starter et batch job... 13 3.1.3 Use Case 3: Transportbånd starter med at køre... 13 3.1.4 Use Case 4: Sensoren registrerer elementet og transportbåndet og stopper... 14 3.1.5 Use Case 5: Klo aktiveres og fremføres til 1. Gribe position... 14 3.1.6 Use Case 6:Klo måler 1. Side af elementet... 14 3.1.7 Use Case 7: Klo roterer elementet og placerer dette på vægten... 15 3.1.8 Use Case 8: Kloen måler 2. Side af elementet... 15 3.1.9 Use Case 9: Klo måler 3. Side af elementet... 15 3.1.10 Use Case 10: Elementet vejes... 16 3.1.11 Use Case 11: Kloen griber elementet og flytter det til opbevaringsrummet.. 16 3.2 Use Case 12: Alle informationerne om elementet logges i databasen.... 16 3.3 Use Case 13: Log Off... 16 4. EKSTERNE GRÆNSEFLADE KRAV... 18 4.1 Bruger-grænseflade... 18 4.2 Hardware-grænseflade... 18 4.3 Kommunikations-grænseflade... 19 4.4 Software-grænseflade... 19 5. KRAV TIL SYSTEMETS YDELSE... 20 6. KVALITETSFAKTORER... 20 Hastighed 2 Brugevenlighed 5... 20 7. DESIGN KRAV... 21 8. ANDRE KRAV... 21 8.1 Myndighedskrav... 21 8.2 Øvrige krav... 21 9. DELLEVERINGER... 21 BILAG... 22 Datadefinitioner... 22 9.1 Ordliste... 22 9.2 Første udgave af en domænemodel (optional)... 23 2
1. INDLEDNING 1.1 Formål Vores firma Dansk Beton har indkøbt en Scorbot ER-4u robot med tilhørende programmel, med det formål at automatisere en eksisterende proces, der indtil nu er blevet foretaget manuelt. Projektet kaldes Danish Rox. Dette er et projekt inden for vores eget firma. Vi er dermed producent samt kunde. Vores firma producerer rektangulære betonelementer bestående af forskellige blandingstyper (forskellig massefylde og dimensioner) af varierende størrelse og vægt, der anvendes i større konstruktioner. Vores firma producerer pt. 5 forskellige typer af betonelementer. De enkelte elementer bliver produceret ved forskellige hastigheder, som derfor ankommer i vilkårlig rækkefølge på et transportbånd. Elementerne bliver manuelt sorteret efter materialetyper og derefter anbragt i tilhørende opbevaringsrum (etopbevaringsrum per materialetype). Operatøren registrerer manuelt størrelse og materialetype for hvert emne. Formålet med dette projekt er at automatisere processen hvad angår sortering samt registrering af størrelse og materialetype, samt at konstruerer en vægt på baggrund af den udleverede vejecelle. Samtidig har vi lavet et interface til en VoiceDetector, som vi modtager fra en anden projektgruppe. 1.2 Referencer Udleverede dokumenter: 1. Projektoplæg.doc 2. Controller-USB, Users Manual 3. Scorbase, Users Manual 4. Scorbot-ER 4u, Users Manual 5. Robotics and Materials Handling 1, Student Activities Book 6. RoboCell, Users Manual 7. Datablad for vejecelle 8. USBC-documentation 3
2. GENEREL BESKRIVELSE Et i forvejen eksisterende system, Scorbot ER-4u robot med tilhørende programmel, ønskes implementeret på vores virksomhed. Den overordnede ide med projektet Danish Rox er at automatisere en eksisterende manuel proces, for at effektivisere vores produktionsapparat. 2.1 Systembeskrivelse Den grundlæggende enhed er selve robotten Scorbot ER-4u, der har 6 frihedsgrader (rotationsakser). Robotten styres i dette projekt, Danish Rox, via en controller boks Controller- USB. Controllerboksen er via USB tilkoblet en PC, hvor styreprogrammet eksekveres. Desuden har controllerboksen en del analoge og digitale ind- og udgange. 2.1.1 Systemoversigt På nedenstående billede vises en skitse af det overordnede system der ønskes implementeret. Den grundlæggende enhed er Scorbot ER-4u robotten. Systemet består samtidig af en Controller-USB boks med med digitale I/O, en terminal til afvikling af programmet (PC med tilhørende skærm og mus), en vægt, et transportbånd og en sensor. Figur 1 Systemoversigts diagram 4
2.1.2 Aktør-kontekst diagram Nedenstående figur viser aktørerne Bruger/Administrator, GUI, Weight, Robot/Controllerbox, Conveyerbelt/Sensor, Keyboard/Mouse og VoiceDetector. class UC proj... User/Admin System GUI VoiceDetector Weight Keyboard/Mouse Robot/Controllerbox Conv eyerbelt/sensor Figur 2 Aktør-kontekst diagram 5
2.1.3 Aktørbeskrivelser I det følgende beskriver en primær aktør, en aktør der har et eller flere mål, der ønskes opfyldt af systemets Use Cases. En sekundær aktør beskriver derimod en aktør, der er en nødvendig deltager i en eller flere Use Case for at opfylde en primær aktørs mål. I nogle tilfælde kan en aktør både være primær og sekundær. Aktør navn:bruger/administrator Type [primær/sekundær]: Primær Beskrivelse: Brugeren skal kunne logge ind på systemet og derefter har brugeren nogle valgmuligheder som f.eks. at oprette en Batch, starte et BatchJob og se i de forskellige Logs. Antal samtidige aktører:1 Aktør navn: GUI Type [primær/sekundær]: Beskrivelse: GUI giver information videre og tager imod input fra brugeren Antal samtidige aktører:1 Aktør navn: Vægt Type [primær/sekundær]: Beskrivelse: Returnerer elementets vægt i gram Antal samtidige aktører:1 6
Aktør navn: Robot/Controllerbox Type [primær/sekundær]: Beskrivelse: Robotten måler volumen af elementet og lægger den over i lageret Antal samtidige aktører: 1 Aktør navn: Transportbånd/Sensor Type [primær/sekundær]: Beskrivelse: Transportbåndet kører elementet frem til Sensoren, og Sensoren stopper Transportbåndet når elementet er på det rigtige sted. Antal samtidige aktører: 1 Aktør navn: Keyboard/Mouse Type [primær/sekundær]: Beskrivelse: Bruges til at manipulere med GUI Antal samtidige aktører: 1 Aktør navn: VoiceDetector Type [primær/sekundær]: Beskrivelse: VoiceDectectoren starter eller stopper systemet. Antal samtidige aktører:1 7
2.2 Systemets funktioner Systemets funktioner, de funktionelle krav, er fundet og beskrevet vha. Use Case teknikken. De følgende diagrammer viser systemets funktioner udtrykt som Use Cases. Formålet med disse diagrammer er at give et overblik over funktionaliteten i det system, der skal udvikles. Hver af de på diagrammerne viste Use Cases er detaljeret specificeret i kapitel 3. 2.2.1 Use Case diagram(-mer) De enkelte krav til systemet bliver uddybende beskrevet i Use Cases. Aktørerne og funktionaliteterne i de enkelte funktioner, beskriver tilsammen det overordnede system. Figur 3 UseCase - diagram 8
2.3 Systemets begrænsninger 2.3.1 Omkring Robottens begrænsninger Robotten har nogle begrænsninger, som har indflydelse på hele systemet. Robotten kan kun køre i en bestemt hastighed, den kan maksimalt åbne kloen 7cm, hvilket betyder at klodser der er større end 7cm, ikke sorteres, og ikke mindst at transportbåndet ikke kan køre uafhængigt af robotten, hvilket giver os en mindre performance hastighed. Herudover har vi en vægt der ikke kan veje mere end 1000g, men det skal siges at det kun skal være muligt at veje 250g. Der er begrænsninger for rækkevidden for robotarmen. Derfor skal opstillingen af systemet, hvad angår afstand til vejecelle, conveyorbelt samt opbevaringsrum, bibeholdes. 2.4 Systemets fremtid Det er tiltænkt at vores firma Dansk Beton i fremtiden skal kunne producere flere typer af beton elementer. Dette forudsætter større lager kapacitet samt implementeringen af flere StorageSpace definitioner. Ydermere vil dette kræve at de eksisterende densiteters definitioner tages op til revision. Da de nye typer af beton elementer kunne tiltænkes at have en vægt der overstiger kapaciteten af den maksimale vægt, kunne det tænkes at denne skal udskiftes. Kloen på robotten kunne også skiftes ud til en klo som er større, så det vil være muligt at sortere elementer større end 7 cm. 2.5 Brugerprofil Målgruppen for projektet, Danish Rox, er medarbejdere ansat i produktion af beton elementer for vores firma Dansk Beton Brugervenligheden er i højsædet for implementeringen af Scorbot ER-4u robotten på vores virksomhed. Systemet er let at starte/stoppe og den automatiserede proces gør at der kræves meget lidt af brugeren. Det grafiske bruger interface er nemt at overskue og funktionaliteten er udviklet med henblik på brugervenlighed. 9
2.6 Krav til udviklingsforløbet Systemet ønskes udviklet vha. objektbaseret design og dokumenteret vha. UML. Yderligere skal systemet udvikles i sprogene T-SQL, XAML, C# og C. Projektet udvikles i en iteration, hvori de enkelte komponenter udvikles i flere iterationer, og afsluttes med aflevering af udviklingsdokumentation, programdokumentation, brugervejledning og program filer på CD-ROM. 2.7 Omfang af kundeleverance Der udarbejdes følgende dokumentation til projektet som afleveres med det færdige system. Udviklingsdokumentation som består af: o o Designdokument o Enhedstest o Accepttest o Hovedrapport Programdokumentation med kildekode (udleveres kun på CD-ROM). Brugervejledning Dokumentationen afleveres på papirform og på CD-ROM. og accepttest skal leveres til og godkendes af Steen Fredborg Krøyer samt dato for aflevering Efter at Danish Rox er afleveret til Steen Fredborg Krøyer, udleveres følgende dokumentation: - Designdokumentation - Programdokumentation med kildetekst. - Brugervejledning Denne dokumentation leveres på papirform samt på CD-ROM. Kildeteksten til programmer leveres både på papirform og på CD-ROM. 10
2.8 Forudsætninger Det forudsættes at IHA stiller en Scorbot ER-4u robot med tilhørende hardware samt software, tilgængelig for udviklingsgruppen i nødvendigt omfang under udviklingsforløbet. Det forventes samtidigt at gruppen fra projektets start til slut har et grupperum til sin disposition. Samtidig er det en forudsætning at vi får udleveret en fungerende VoiceDetector fra Voice- Detector projektgruppen. 11
3. FUNKTIONELLE KRAV USE CASES 3.1 Normal scenario for registrering af et element Aktør: Bruger Goal: Et element bliver kørt gennem hele systemet og sat i det korrekte opbevaringsrum. Precondition: Brugeren er gyldig og der er valgt et prædefineret batchjob. Postcondition: Et element bliver registreret i systemet, og lagt i opbevaringsrummet. 1. Log In 2. Bruger starter et batchjob 3. Transportbånd starter med at køre 4. Sensoren registrerer elementet og transportbåndet stopper 5. Klo aktiveres og fremføres til 1. Gribe position 6. Klo måler 1. Side af elementet 7. Klo roterer elementet og placerer dette på vægten 8. Klo måler 2. Side af elementet 9. Klo måler 3. Side af elementet 10. Elementet vejes 11. Kloen griber elementet og flytter det til opbevaringsrummet 12. Alle informationerne om elementet logges i databasen 13. Log Off 12
3.1.1 Use Case 1: Log In Aktør: Bruger Goal: Brugernavn findes og password accepteres og brugeren bliver logget på systemet. Precondition: Systemet promptes til log In Postcondition: Brugeren logger In og systemet åbnes 1: Systemet afventer at brugeren logger på 2: Brugeren indtaster sit brugernavn 3: Brugeren indtaster sit password 4: Systemet verificerer log in informationen 5: Brugeren bliver logget på systemet 6: Det indtastede brugernavn findes ikke 7: Det indtastede password passer ikke med medarbejdernummeret 3.1.2 Use Case 2: Brugeren starter et batch job Aktør: Bruger Goal: Batch jobbet starter og UserID, RobotID samt Started bliver logget. Precondition: Der er mindst et gyldigt batch job og robotten er homet. Postcondition: Batch jobbet kører 1. Brugeren vælger et batch job 2. Brugeren trykker på Start job 2.1 Brugeren bruger VoiceDetectoren til at starte et BatchJob vha. komandoen Start 3. Informationerne bliver logget i databasen. 3.1.3 Use Case 3: Transportbånd starter med at køre Aktør: System initieret Goal: Transportbåndet fører elementet frem. Precondition: En bruger er logget på,robotten er homet samt at der er valg et batchjob. Postcondition: Transportbåndet bliver sat i gang. 1: Transportbåndet starter med at køre 13
3.1.4 Use Case 4: Sensoren registrerer elementet og transportbåndet og stopper Aktør: System initieret Goal: Transportbåndet stoppes når elementet er placeret foran sensoren. Precondition: Transportbåndet kører og et element placeres på transportbåndet Postcondition: Transportbåndet stopper når elementet er foran sensoren 1: Sensoren registrerer elementet og transportbåndet stopper 3.1.5 Use Case 5: Klo aktiveres og fremføres til 1. Gribe position Aktør: System initieret Goal: Klo fremføres til 1. Gribe position Precondition: Et element er placeret foran sensoren og transportbåndet er stoppet og robotten er i homing position. Postcondition: Kloen er i 1. Gribe position 1: Kloen åbnes og stopper ved elementet 3.1.6 Use Case 6:Klo måler 1. Side af elementet Aktør: System initieret Goal: 1. Side af elementet bliver målt Precondition: Klo er i 1. Gribe position Postcondition: 1. Side af elementet bliver målt 1: Kloen lukker sig om elementet og er i 1. Måle position 2: Siden på elementet måles 14
3.1.7 Use Case 7: Klo roterer elementet og placerer dette på vægten Aktør: System initieret Goal: Elementet bliver roteret 90 grader og bliver placeret på vægten. Precondition: Kloen er i 1. måleposition Postcondition: Elementet er roteret og placeret på vægten 1: Kloen løfter elementet fra transportbåndet 2: Kloen roterer elementet 3: Elementet placeres på vægten 3.1.8 Use Case 8: Kloen måler 2. Side af elementet Aktør: System initieret Goal: Kloen slipper elementet og går til 2. Gribe position Precondition: Elementet er placeret på vægten. Postcondition: Kloen måler 2. Side af elementet. 1: Kloen roterer og måler 2. Side af elementet. 3.1.9 Use Case 9: Klo måler 3. Side af elementet Aktør: System initieret Goal: 2. Side af elementet bliver målt Precondition: Elementet er placeret på vægten Postcondition: 3. Side af elementet bliver målt 1: Kloen roterer og måler 3. Side af elementet 15
3.1.10 Use Case 10: Elementet vejes Aktør: System initieret Goal: Vægten på elementet vejes Precondition: Elementet er placeret på vægten Postcondition: Elementets vægt er vejet 1: Elementet vejes 3.1.11 Use Case 11: Kloen griber elementet og flytter det til opbevaringsrummet Aktør: System initieret Goal: Elementet bliver placeret i det korrekte opbevaringsrum Precondition: Elementets 3 sider er målt og vægten registreret Postcondition: Udfra densiteten bliver elementet placeret i opbevaringsrum. 1: Kloen løfter elementet fra vægten 2: Kloen placerer elementet i det korrekte opbevaringsrum 3: Robotten roterer til start position. 4: Tidspunktet for tasksended bliver logget i databasen. 3.2 Use Case 12: Alle informationerne om elementet logges i databasen. Aktør: System initieret Goal: At logge værdierne for Weight, Height, Width, Depth og Added. Precondition: Det loggede element skal være kørt gennem systemet. Postcondition: Værdierne bliver logget hvis elementet er gyldigt. 1: Verificere at elementet er gyldigt. 2: Værdierne bliver logget i databasen. 3.3 Use Case 13: Log Off Aktør: Bruger Goal: Brugeren bliver logget af systemet 16
Precondition: Brugeren er logget på systemet og systemet er ikke ved at køre elementer igennem Postcondition: Brugeren logges off og systemet lukkes. Al data er gemt 1: Brugeren logger af systemet 2: Systemet lukkes ned 3: Systemet kører og det er derfor ikke muligt at logge af. Fejlmeddelelse 17
4. EKSTERNE GRÆNSEFLADE KRAV 4.1 Bruger-grænseflade Til projektet skal der udvikles GUI, hvilket gør det muligt for brugeren at interagere med robotten. 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, batchjobs og batchjobtask positions. 4.2 Hardware-grænseflade Controller-USB Specifikationer: 12 volt power supply 0.1A Max. Digitale outputs: 8 digital outputs 24V max. 1 4: relays 5 8: open collectors sink/source configurable. Digital Inputs: 8 Dry Contacts or 0 24 V PNP/NPN (high/low) configurable 0.5A Max. Analog Outputs: 2 analog outputs: 8-bit resolution Output voltage 0 10V 20mA Max Analog Inputs: 4 analog inputs 8-bit resolution Digital signal Input voltage 0 10V. Intelitek>> Conveyor: Assv. Cat#015011 Rev. E Serial#35699026 18
Vægtcelle type MP20 straingauge: Wide Power Supply Range (+/-2.3 V to +/- 18V) Low Power 1.3 ma max Supply Current. AD620 instrumentsforstærker: Three Op Amp Sensor Specifikationer: SUNX Photo Electric Sensor CY-22 10-30V, is connected to input pin 1 on Controller-USB. USB Mouse: Standard USB mus USB Keyboard Standard USB keyboard Monitor Standard PC skærm 4.3 Kommunikations-grænseflade Der er brugt seriel com port til at kommunikere mellem PC og vejecellen, og data sendes via et RS-232 kabel. USB indgangen på PC er forbundet til Controller USB indgang 8. USB Controllerens indgang 9 er forbundet til Scorbot ER-4u robotten. Adgangen til databasen sker gennem IHA swebhotel10.iha.dk 4.4 Software-grænseflade Systemet skal køre på en Windows PC der understøtter.net 3.5 SP1 framework. LINQ to SQL: Se punkt 3.4 i Systemdesign dokumentet. 19
5. KRAV TIL SYSTEMETS YDELSE Ingen. 6. KVALITETSFAKTORER Vores GUI er designet til at være utrolig brugevenligt, og er derfor logisk opbygget. Vi har også lagt vægt på udvidelsesmuligheder for systemet. Det vil derfor være nemt at tilføje ekstra features og elementer til systemet. Systemet er samtidig meget pålideligt, og er driftsikkert. Det samlede system er let at genbruge, da projektet er designet med lowcoupling og highcohesion, samt let at vedligeholde koden. Der er ikke lagt vægt på hastigheden, da vi er begrænset pga. hardwaren. Hastighed 2 Brugevenlighed 5 Genbrugbarhed 4 Udvidelsesmulighed 5 Vedligeholdelsesvenlighed 3 Pålidelighed 5 20
7. DESIGN KRAV Robotsystemet skal implementeres på PC med Windows OS, der understøtter.net 3.5 SP1. En database, hvori alle relevante data fra processen kan opbevares og manipuleres. En IDE, hvori man kan fremstille programmer til styring af robot-processen (dette forudsætter blandt andet, at man designer og implementerer et programmeringssprog og en fortolker til formålet). En simulator (et program der simulerer robotten), som kan kobles på systemet i stedet for den fysiske robot. Dette vil blandt andet i et vist omfang kunne anvendes i forbindelse med test. Et styreprogram med grafisk brugergrænseflade (programmeres i WPF). Via brugergrænsefladen skal man blandt andet kunne starte/stoppe systemet, aflæse status for sorteringsprocessen, få vist relevante alarmer, arbejde med data i databasen og lave programmer til styring af robotten. Det er gruppens opgave at specificere brugergrænsefladen, men denne skal godkendes af virksomheden (vejlederen). 8. ANDRE KRAV Ingen. 8.1 Myndighedskrav De lovmæssige krav der er for opstilling af robotter og des lige på virksomheder i Danmark er ikke pålagt vores projektgruppe. Ansvaret for at de sikkerhedsmæssige, lovmæssige samt de arbejdsmiljømæssige love og regler er overholdt, ligger hos vores firma Dansk Beton. 8.2 Øvrige krav Ingen. 9. DELLEVERINGER De enkelt komponenter er udviklet iterativt, men projektet som helhed er lavet som en iteration, men forløbet er i to iteration. Hvor den første iteration er at forstå problemdomænet, og det andet er det færdige produkt. 21
BILAG Datadefinitioner Tekst er skrevet i MS Word 2007 med skrifttypen Times New Roman i størrelsen 12 med linie afstand 1.5 9.1 Ordliste Brugte forkortelser: I4PRJ4: Ingeniørhøjskolen Århus Projekt 4 Grp. 2: Styringsgruppen for Software Udvikling HW: Hardware SW: Software UML: UnifiedModelingLanguage GUI: Graphical User Interface UC: Use Case IDE: Integrated Development Environment 22
9.2 Første udgave af en domænemodel (optional) Figur 4 Domæne model 23