vrijdag 25 april 2014

Analyse - ideeverslag

Om de systeemdesignfase af te sluiten was het analyse - ideeverslag geschreven. Elke groepslid heeft hier de nodige onderwerpen voor onderzocht om zo het hoofdstuk "resultaten" te vullen met nuttige informatie. Zo waren onder meer de natuurkundige principes van lift en stuwkracht geanalyseerd, maar ook de boeidetectie en het afschrikken van vogels wordt behandeld. Dit alles is terug te lezen in het verslag waarmee ik DD2, DD3, DD4 en het onderstaande leerdoel mee wil aantonen.


  • Je kunt te verachten in -en output van je (sub-sub) systemen beschrijven op basis van natuurkundige grootheden, met behulp van metingen en natuurkundeformules.


Het verslag is via deze link te downloaden:     "download analyse - ideeverslag"


Programma van eisen & wensen versie 2

Door de nieuw toegepaste ontwerptools en systeemanalyses kon het PvE&W aangevuld worden. Vooral uit de procesboom en FMEA kwamen een aantal eisen op het gebied van veiligheid en waterdichtheid. Dit aangevulde pakket van eisen & wensen zal doorgaande het project als kwaliteitsbewaking voor het product dienen. Met dit bericht wil ik de beheersing van DD2 & DD3 bewijzen, zie hieronder het vernieuwde PvE&W.

Definitieve probleemstelling versie 2

Omdat de oude versie van de "definitieve" probleemstelling niet meer voldeed voor de systemdesignfase was een nieuw exemplaar geschreven. De meeste deelvragen van de oude versie zijn beantwoord via het analyse - ideeverslag. Daarom was het zaak nieuwe deelvragen te formuleren en ervoor te zorgen dat de centrale vraag nog steeds de essentie van het project omvat. Het ontwerpteam heeft dit gezamenlijk aangepakt. Het resultaat, een vernieuwde probleemstelling met relevante deelvragen voor de komende fases. Deze post geld als bewijslast voor DD2, DD3 & DD4, zie hieronder de probleemstelling.

FMEA

Met de FMEA was een analyse van het product uitgevoerd waaruit de mogelijke risico's op (gevaarlijke) defecten werdt bepaald. De uitslagen waren via kleur gecategoriseerd op de zwaarte van het mogelijke probleem. Deze tool leverde ook weer ontwerpinformatie op voor in het programma van eisen. Het resultaat, een overzicht van alle gebreken met prioriteitsverdeling voor het oplossen ervan. Het opzetten van een FMEA is bekend vanuit het vorige blok. Deze post geld als bewijslast voor DD2 & DD3, de FMEA analyse is hieronder te bezichtigen.

DFA

Via de DFA analyse was in grote lijnen duidelijk geworden hoe lang de assemblage van het product zou duren. Ook het te verwachten aantal assemblagestappen was bepaald. Hiervoor was de exploded view tekening, in solidworks gemaakt, van het product gebruikt. Nadat de hoofd -en subassemblys onderscheid waren konden de assemblagetijden bepaald worden a.d.h.v. het aangeleverde werkbestand door de docent. Zie hieronder de uitwerking, DD2 & DD3 wil ik hiermee aantonen.

Systeemlogica

Door de hardware en softwarematige systemen schematisch weer te geven onstond een duidelijk overzicht van de opbouw. Elk hoofdcomponent was beschoud als een systeemblok met in -en output. Door deze met elkaar te verbinden werdt zichtbaar welk component iets ontvangt of doorgeeft aan een ander. Sensoren en actuatoren waren zo goed te onderscheiden. Het opstellen van logicaschemas was bekend vanuit mijn vorige opleiding. Voor andere systemen is deze weergavemethode ook prima toe te passen. Dit bericht geld als bewijslast voor DD2 en de onderstaande leerdoelen.


  • Je kunt een schema maken van de logica die in het systeem werkt: de hardwarematige kant.
  • Je kunt een schema maken van de logica die in het systeem werkt: de softwarematige kant.



    Zie hieronder de schema's.

    Natuurkundige systeemdefinitie

    De in -en output van het systeem was via natuurkundige grootheden aangegeven in een schema. Aan elke grootheid was een tolerantie verbonden. Door deze bandbreedte vast te leggen weet het ontwerpteam hoeveel speelruimte er is voor het verdere ontwerpen. Tegelijkertijd zijn er ook limieten bepaald om het project te handhaven. Van de gewichtsverdeling was een extra nauwkeurig overzicht gemaakt. Dit was nuttig voor de liftberekening in het analyse - ideeverslag. DD2 en het onderstaande leerdoel wil ik met deze post aantonen.


    • Je kunt gewenste in -en output van je (sub-sub)systemen beschrijven op basis van natuurkundige grootheden. 

    Zie hieronder de uitwerking.

    Morfologische kaart versie 2

    In de proof of conceptfase was de eerste morfologische kaart gemaakt. Voor de systemdesignfase was aanvullende informatie nodig over de integratie van het ballenkanon met de hovercraft. Ook zaken zoals de boeidetectie was veder onderzocht. Dit bracht als resultaat een verder gedefinieerd ontwerp op. Dit bericht geld als bewijslast voor DD2. Zie hieronder de morfologische kaart.

    Functieboom versie 2

    Toen het ontwerpteam in de systemdesignfase zat was het zaak de functieboom verder uit te breiden. Hiervoor was de vorige versie besproken en geupdate waar mogelijk. Subsystemen waren verder gespecificeerd, ook was in zekere maten gekeken naar sub-subsystemen. Dit resulteerde in een functieboom waar het team de fase mee kan afsluiten. Daaropvolgend zal het document waarschijnlijk nogmaals uitgebreid worden om de sub - subsystemen verder te specificeren. De beheersing van DD2, DD3 en het onderstaande leerdoel wil ik met deze post onderbouwen.


    • Je kunt een systeem opdelen in sub - en sub-subsystemen op een manier die bijdraagt aan het ontwerp.

    Zie hieronder de functieboom.

    Procesboom

    De procesboom, een onderhand bekende ontwerptool, was voor de hovercraft opgesteld. Daarvoor was de nadruk gelegd op het productgebruik zoals stond beschreven in de studiewijzer. Door het gebruik verder te analyseren, zoals bij het schetsen van gebruikerscenario's ook gebeurde, kon meer richting aan het ontwerp worden gegeven. Deze input was bijvoorbeeld bruikbaar voor het programma van eisen & wensen. Met dit bericht wil ik DD2 & DD3 aantonen. Zie hieronder de uitwerking.

    zaterdag 12 april 2014

    Proof of concept: ballenkanon

    Zoals een proof of concept voor de hovercraft was gemaakt gebeurde dit ook voor het ballenkanon. Dit was gerealiseerd in dezelfde week. In dit bericht is het eindresultaat te zien. Zie de eerdere post's voor meer informatie over het ontwerpproces achter het geheel. Dit bericht geld voor het aantonen van DD2 en het onderstaande leerdoel.


    • Je kunt een proof of concept bouwen.

    Proof of concept: hovercraft

    In de eerste week van het project was hard gewerkt aan de "Proof of concept" van het project. Het ontwerpteam had hiervoor materialen verzameld en ingekocht. In de voorgaande post's is het ontwerpproces terug te lezen, in dit bericht ziet u het eindresultaat van het eerste prototype hovercraft. DD2 en de onderstaande leerdoelen wil ik met dit bericht bewijzen.


    • Je kunt een proof of concept bouwen
    • Je kunt een test formuleren en uitvoeren voor een subsysteem

    vrijdag 11 april 2014

    Elektronisch subsysteem: aandrijving

    Vandaag was het verbeterde subsysteem voor de aandrijving van de hovercraft afgebouwd. In een eerdere staat werd onvoldoende vermogen geleverd door de accu. Via een H-brug schakeling was het gelukt de motoren op een zwaardere accu te laten draaien met de zelfde stuursignalen. Dit elektrotechnische systeem kan ook worden toegepast voor het eindmodel. De vergaarde kennis gaat zeker van pas komen. De beheersing van DD2 en het onderstaande leerdoel wil ik hiermee onderbouwen.

    • Je kunt in - en output van systemen en subsystemen schematisch weergeven.


     Zie hieronder de schema's en berekeningen van de schakeling. 

    Morfologische kaart

    Door het clusteren van ideeschetsen was het ontwerpteam in staat een morfologische kaart te creëren. Dit was gedaan via excel omdat met dit programma snel gestructureerde overzichten gerealiseerd kunnen worden. Op de y-as waren alle zoekvelden geplaatst om op de x-as de oplossingen te presenteren. Uit feedback van het vorige blok was geleerd om eerst een ontwerpgeest te verzinnen vooraleer de kaart wordt belijnd. Het betrekken van de ontwerpvisie was ook van belang. Aan deze punten was extra aandacht besteed waardoor een goed theoretisch gefundeerde keuze gemaakt kon worden. DD2 & DD3 wil ik bewijzen met dit bericht.

    Integraal idee

    Aan de hand van de ontwerpvisie en morfologische kaart kon het integrale idee samengesteld worden. Hiervoor was de kaart belijnd en het resultaat vastgelegd. De systeemopbouw van het ontwerp was hierdoor duidelijk geworden. Ook de geest van het idee was beschreven. Vanuit de opdrachtgever waren geen indicaties over vormtaalkarakter gegeven, dit is daarom achterwege gelaten. De vormgeving zal verder door het ontwerpteam ingevuld worden tijdens het project. Deze post geld als bewijslast voor DD2 & DD3. Zie hieronder de uitwerking.

    donderdag 10 april 2014

    Ontwerpvisie

    De eigen visie op de opdracht mag niet ontbreken voor een origineel eindresultaat. Omdat de ontwerpvisie de rode draad zal vormen door de rest van het project heen was deze bewust met het gehele team geformuleerd. Zo zit iedereen op een gelijke golflengte. Zoals is begrepen uit de feedback van het vorige blok zal de visie toegepast worden tijdens de belijning op de morfologische kaart.  Met deze post wil ik DD2 & DD3. Zie hieronder de ontwerpvisie van het team.

    Definitieve probleemstelling

    Eenmaal de fundatie van het project vorm kreeg kon de definitieve versie van de probleemstelling geschreven worden. In de probleemstelling heeft het ontwerpteam de essentie van het project zo goed mogelijk beschreven. De zoekvelden die hieruit resulteerde zijn van toepassing voor de morfologische kaart. Dit stuk geld als bewijslast voor DD2 & DD3. Zie hieronder de uitwerking.

    Programma van eisen & wensen

    Het PvE & W was in de proof of conceptfase gezamenlijk opgesteld door het ontwerpteam. Als input waren de eisen van de opdrachtgever gebruikt, maar ook eerder geschetste gebruikersscenario's. Het toepassen van gebruikersscenario's was een punt van feedback uit het vorige blok. Het PvE & W zal in de loop van het project als kwaliteitsbewaking voor het product fungeren. Dit bericht geld als bewijslast voor DD2 & DD3. Zie hieronder de uitwerking.

    Ideeschetsen & gebruikersscenario's

    Om tot een integraal idee te komen in de "proof of concept" fase was het zaak ideeën te genereren en deze al dan niet schetsmatig vast te leggen. Ieder groepslid had een aantal ideeschetsen verzorgd waar nuttige informatie uit resulteerde die verwerkt kon worden, bijvoorbeeld in het programma van eisen & wensen. Ondertussen wordt het schetsen van ideeën / oplossingen beschouwd als een algemene tool die tijdens elke fase inzetbaar is. Met dit bericht wil ik DD2, DD4 en het onderstaande leerdoel aantonen.


    • Je kunt een systeem ontwerpen volgens het V model.

    Zie hieronder de ideeschetsen & gebruikersscenario's. 

    Functieboom productsysteem

    Door een functieboom van het systeem op te zetten werd duidelijk welke apparatuur verzorgd moet gaan worden. De ideatie ervan verliep gezamenlijk met de ontwerpgroep zodat iedereen netjes op de hoogte is. De functieboom was gemaakt in een mindmapprogramma, dit leverde een overzichtelijk schema op. Dit was de eerste keer dat de functieboom aan bod kwam. Ik begrijp het nut van dit document in het kader van systeemgericht ontwerpen. DD2, DD3 en het onderstaande leerdoel wil ik bewijzen.


    • Je kunt een systeem opdelen in subsystemen en sub-subsystemen.


    Zie hieronder de uitwerking.

    Voorlopige probleemstelling

    Voor het begin van dit blok was de voorlopige probleemstelling geschreven. Deze bestaat uit een probleemschets, root cause analysis, kern van het onderzoek, het onderzoeksdoel en de centrale vraag met deelvragen. De combinatie hiervan resulteerde in een duidelijke beschrijving van de kwestie waar het in dit project om draait. Zoals uit de feedback van het vorige blok bekend was er gekeken naar de essentie van de opdracht. Deze zelfde insteek zal voor de definitieve probleemstelling toegepast gaan worden. Met deze post wil ik DD2, DD3 en het onderstaande leerdoel aantonen.


    • Je kunt een systeem ontwerpen volgens het V model.


    Zie hieronder de uitwerking.