Verslag

verslag.md

Verlag Project Containing

Herman ten Hoor Richard Brouwer Sietse van der Molen Maikel Wever Dave van Klink Inhoudsopgave:

1. Inleiding
2. De opdracht
3. Eisen van het project
4. Wensen van het project
5. Taakverdeling
6. Planning
7. Materialen en methoden

 

1. Inleiding

De haven van Rotterdam is de grootste haven van Europa met een goederenoverslag van 430 miljoen ton in 2010. In 2010 werd de haven bezocht door meer dan 34 duizend zeeschepen. Onze opdracht is om dit gigantische process te gaan simuleren. Deze opdracht moeten wij zien te volbrengen met een groep van vijf personen onder begeleiding van onze tutor: dhr. Oosterhaven.   2) Probleemstelling

De opdracht is om een simulator te maken te maken die de haven van Rotterdam nabootst. In de haven van Rotterdam kunnen twee dingen gebeuren met een container die binnenkomt, deze kan direct worden overgeplaatst op een ander vervoersmiddel, overslag genaamd, en deze kan tijdelijk worden geplaatst op een daarvoor bestemde ‘parkeerplaats’, opslag genoemd. De containers kunnen op vier manieren de haven binnen gebracht worden; door zeeschepen, binnenvaart schepen, treinen en vrachtauto’s. Het lossen van de containers gebeurt door middel van kranen, er zijn twee soorten kranen aanwezig in de haven; kranen die een container kunnen optillen, over de lengte verplaatsen en daarna laten zakken en kranen die daarnaast ook nog de container kunnen verplaatsen over de breedte van de kraan. Voor het verplaatsen van containers op het terein word uitsluiten gebruik gemaakt van AGV’s (Automatic Guided Vehicle). Een AGV is een soort onbemande auto. Deze zelfstandige machines zijn in staat om één container tegelijk te verplaatsen over het terein. De AGV’s doen dit helemaal uit zichzelf. Ze worden bestuurt door een centrale computer die de AGV’s vertelt waar en wanneer ze ergens heen moeten. In totaal zijn er honderd AGV’s op de haven. De opdracht die wij moeten realiseren is op te splitsen in drie onderdelen: • De controller: verzorgt alle informatie die nodig is voor het simuleren van de haven. • De simulator: Deze laat grafisch zien wat er gebeurt op de haven aan de hand van de informatie die hij krijgt van de controller. • De management app: deze app, welke draait op een Android interface, hetzij een Android tablet of een Android telefoon, laat alle informatie zien over de containers op de haven. Denk hierbij aan de inhoud, hoeveelheden, bestemmingen enzovoort.

3. Eisen van het project

 De simulatie moet 3D zijn, waarbij je gebruik mag maken van OpenGL.  Er moet een wiskundige verantwoording komen van de kortste route.  Er moet een complete UML analyse komen  Het verslag moet samenhangend, doorlopend en goed geschreven zijn.  De controller moet met de gegeven input werken, te weten datafiles in XML format, oplopend van klein naar (heel) groot. NB: er zitten fouten in de XML-files, en het programma moet dus zo robuust zijn dat het daar geen last van heeft.  De programma's moeten in Java geschreven worden.  De werking van de software moet getest worden, zó dat de opdrachtgever overtuigd raakt van de kwaliteit. Aanbeveling: gebruik Junit.   4) Wensen van het project

 Maak de weg waarover de AGV's rijden vierbaans zodat onbeladen AGV's beladen AGV's in kunnen halen.  Maak de grafieken op het android-platform real-time.  Maak het mogelijk dat de simulatie tot 100 keer versneld kan worden afgedraaid.  Maak het mogelijk dat via de simulator (het beeldscherm) een operator in kan grijpen wanner hij of zij dat noodzakelijk vindt. Bijvoorbeeld om de minimale afstand die de AGV's onderling moeten houden te veranderen als het erg druk is. Of om een bepaalde lading containers een hogere prioriteit te geven omdat er verwacht wordt dat er een lucratieve serie orders achterweg kan komen.  Gegevens van de containers staan in een database.  In de simulator het mogelijk maken dat een operator calamiteiten kan laten ontstaan, bv. De Operator geeft aan dat de een AGV of een Kraan etc..kapot gaat. Visueel moet direct duidelijk zijn dat er zich een probleem voordoet. Een calamiteit moet vanaf het toetsenbord (met -of zonder muis) invoerbaar zijn.  Een operator interface voor de simulator waarmee calamiteiten realtime (binnen 10 seconden) kunnen worden in gebracht en zichtbaar gemaakt kunnen worden. De reactie van de Controller moet realtime (binnen 30 seconden) en zichtbaar in de simulator zijn.  Het 'in-zoomen' op 1 container, die bekeken en gedraaid moet kunnen worden en waarvan de gegevens in een extra venster moeten komen.  Het 'in-zoomen' op één container, zie eis 7) maar nu zonder gebruik te maken van OpenGL.

  5) Proces

De taken zijn inmiddels verdeeld over de vijf projectleden zodat we met zijn allen lekker aan de gang kunnen, dit is het schema hoe de taken uiteindelijk verdeeld zijn:

Controller:

• Maikel: Comminucatie met Android, SocketServer, onderzoek naar een ORM en SQLite
• Dave: XML parser, dataopslag binnen de controller, comminucatie met de simulator Simulator:
• Sietse:
• Richard: Android:
• Herman: Interface, Graph module Algemeen:
• Richard: notulist
• Maikel: verslag, Subversion icm. Trac
• Dave: plan van aanpak, digitalisering UML

Wij zijn begonnen met het onderverdelen van mensen op de drie onderdelen van het project. Maikel en Dave hebben de controller gedaan, Sietse en Richard de simulator en Herman de Android app. We hebben direct de projecten die de IDE heeft gemaakt op Subversion gezet, zodat we direct konden samenwerken op een handige manier.

6. Voortgang binnen de deelprojecten Controller: Dave is begonnen met de XML parser, en Maikel met de ORM om de data van de parser in op te slaan. Beide onderdelen stonden vrij snel, maar hadden zo nog hun kinderziektes. De ORM wouden we in combinatie met SQLite gebruiken, maar vanwege de enorm slechte prestaties van SQLite (werkt niet goed met het NTFS logboek samen, waardoor de hdd te veel belast wordt), hebben we gekozen om een arraylist in het geheugen te maken voor dataopslag. Een nadeel hiervan is dat het geheugen kost, en niet opgeslagen blijft. Het voordeel is de snelheid van het geheugen ten opzichte van een harddisk, en niet te beschikking hebben tot SQL om data mee te verwerken/op te vragen. Omdat de eerste XML parser vastloopt op 2 velden met de naam ‘inhoud’ (deze staan wel in verschillende subtags), laat Dave deze taak vallen, en gaat verder met de opslag van data in het geheugen, en ontwerpt de eerste versie van ons protocol voor datatransport. Maikel neemt de XML parser nu op zich, en met gebruikmaking van de zogenaamde SAXparser, lossen we het probeem met het inhoud veld op. Bovendien haalt de SAXparser veel fouten uit de xml, die wij eerder nog zelf moesten detecteren. Na dit achter ons te hebben, is Dave begonnen aan het verwerken van de lijst met containers, en heeft het systeem gemaakt dat controleert op nieuwe containers om te verwerken. Ondertussen heeft Maikel een multithreaded SocketServer gemaakt, die het mogelijk maakt voor Dave’s nieuwe systeem om de simulator deze nieuwe containers af te handelen.

7. Planning

Periode 2 datum *week dag wie Actie 14/11/11 1 Ma Wo

Studenten+ docs

Studenten+ docs

Studenten Aftrap centrale bijeenkomst

< afmaken SON & OOP> 21/11/11 2 Wo Do Studenten+ docs Studenten centrale bijeenkomst , inleveren analyse 1, techn. Doc 1 , planning.

28/11/11 3

Wo Studenten+ docs

Studenten+ docs TestSessie1 in studielandschap bij G2049 a.d.h.v. ingeleverd testverslag** centrale bijeenkomst 05/12/11 4 Wo

Studenten+ docs

centrale bijeenkomst 

Individuele assessments volgens rooster 12/12/11 5

Wo Studenten+ docs

Studenten+ docs TestSessie2 in studielandschap bij G2049 a.d.h.v. ingeleverd testverslag** centrale bijeenkomst 19/12/11 6 Wo Studenten+ docs centrale bijeenkomst

09/01/12 7

Wo Studenten+ docs

Studenten+ docs TestSessie3 in studielandschap bij G2049 a.d.h.v. ingeleverd testverslag** inleveren rapport 16/01/12 8 Wo

Do Studenten+ docs

Studenten+ docs centrale bijeenkomst

Presentaties Engels Demonstraties

  7) Materialen en methoden

Voor dit project gaan wij gebruik maken van de programeer taal Java, de verschillende onderdelen die wij moeten programmeren worden hier in geschreven. Het grafische gedeelte van de simulator wordt gemaakt met jMonkeyEngine, dat is een ‘game engine’ gemaakt in Java. Omdat wij met vijf mensen aan één project werken maken wij gebruik van versie controle, dit voorkomt dat er fouten ontstaan als twee of meer mensen aan hetzelfde document werken. Wij maken gebruik van Subversion, wat draait op de server van Maikel. Er is ook een plugin van Subversion voor gebruik binnen Netbeans. Netbeans gebruiken wij om te programmeren in Java. Omdat Netbeans en Subversion zo goed samen werken hebben wij een goede versie controle op onze code. De data voor de controle komt binnen in XML bestanden, deze XML bestanden lezen wij uit en deze worden vervolgens doorgestuurd en opgeslagen in een SQLite database. Deze database wordt vervolgens met behulp van een ORM (Object Relational Mapping) uitgelezen in de Java code. Daarna kunnen wij aan de gang met die informatie. Om goed bij te houden wat wij aan het doen zijn en, veel belangrijker nog, wat wij nog moeten doen maken wij gebruik van Trac. Trac is een web gebasseerde project management tool die de volgende dingen bijhoudt:

• Wie doet wat
• Wie heeft wat gedaan
• Wat moet er nog gedaan worden
• Welke milestones moeten we halen
• Welke deadlines hebben wij
• Wanneer zijn we klaar De management tool die we gaan maken moet gaan draaien op een tablet die op Android draait. Hiervoor hebben wij twee Point of View tablet die vooralsnog op Andoird versie 2.2 draait. Wij gaan er van uit dat de tablet uiteindelijk op minimaal versie 3.0 (Codenaam Honeycomb) gaat draaien.

v