En prototyp har tagits fram för att kunna avgöra om rätt val har gjorts för återställ-ningsverktyg under förstudien. Slutprodukten är uppbyggd av ett bibliotek som innehåller logiken och två gränssnitt. Det ena gränssnittet är grafiskt som är upp-byggd med hjälp av Windows Forms i Visual Studio. Det utvecklades för en för-enklad användning av produktens funktionaliteter. Det andra är ett kommando-radsgränssnitt som möjligen kan användas för återanvändning i framtiden inom företaget. I detta kapitel beskrivs detaljerna av prototypen mer ingående.
Projektets konsekvenser för samhället ur ekonomisk, social, etisk och miljömässig synvinkel diskuteras som följande. Tillämpning av integrationsmodellen för att ut-veckla en slutprototyp gör testningsarbete på företaget enklare så att tiden kan läg-gas till någon användbar aktivitet. Det är konsekvens för samhället ur ekonomisk och social synvinkel så att företaget kan använda sina resurser mer effektivt. Åter-ställningsprocessen förbättrar arbetsmiljö för att den är ett långt och tråkigt arbete som inte behöver göras. Projektet har inga direkta konsekvenser för miljön.
5.1 Integrationen
Integrationen på användargränssnitt- och applikationsgränssnittnivå enligt EAI i slutprodukten gör att produktutvecklingen gick snabbare genom att använda de befintliga resurserna på företaget än de skulle återutvecklas. Utvecklingsprocessen gick effektivt för att ägna tid åt nya funktioner som byggs på integrerade applikat-ioner. Utöver de fördelarna kan man också konstatera att produkten resulterades till ett långsiktigt åtagande som kräver att ha kontroll på saker som uppdateringar av delapplikationerna eller installation av de uppdaterade versionerna i slutpro-dukten.
Anledning för att använda applikationsprogrammeringsgränssnittnivå (API) för SOPS-hantering och flashprogrammering är att få bättre kontroll av hur olika me-toder implementeras och enklare fel hantering i systemprototypen. Mer konkreta fördelar för varje funktion tas upp i avsnitt 5.3. När det gäller användargränssnitt-nivå är den största fördelen att implementering blir väldigt enkelt med mindre kod och fel som gör att byta komponenten blir enklare. Mer konkreta nackdelar och fördelar för systemprototyp beskrivs under avsnitt 5.3.2.
40 | ANALYS OCH DISKUSSION
5.2 Modularitet
Prototypen byggdes med fokus på modularitet. Detta innebär att de ovanstående komponenterna implementeras på ett sätt som gör det möjligt att enkelt byta ut dem. I första hand innebär det att principerna inom objektorienterade programme-ring följs så att det finns en tydlig uppdelning av flödet. När det gäller uppdelning av olika processer är slutprodukten uppbyggd så att varje metod gör ett välavgrän-sat arbete.
Genom att tillämpa modularitet i återställningsverktyg är det enkelt att byta im-plementationen, till exempel genom att byta vilken komponent utför arbetet, utan att resten av applikationen påverkas. Strukturen av prototypen är byggd så att logi-ken är helt skild från själva gränssnittet vilket gör att implementationen av ett gra-fiskt gränssnitt och ett kommandoradsgränssnitt gjordes väldigt enkelt utan att ändra i modellen. Slutprodukten har möjlighet för utbytbarhet av integrerande ap-plikationer om det behövs framöver.
5.3 De integrerade komponenterna
Här beskrivs vilka komponenter har valts för integrationen för slutprototypen och anledning för gjorda val bland de applikationerna som var tillgängliga för att inte-greras som också diskuterades i avsnitt 2.4, Undersökta verktyg för integration. 5.3.1 Hantering av SOPS-filen
Hantering av SOPS-filen görs via MainLibrary. Att det redan krävs av andra kom-ponenter betyder att det kan återanvändas och slutprodukten behöver inga nya be-roenden. Applikationsprogrammeringsgränssnittnivå (API-nivå) integrationen in-nebär även bättre kontroll över processen som var fördelaktigt för att kunna upp-fylla kraven som ställdes på prototypen av företaget.
5.3.2 ECU-parametrar
DevelopmentTool används för att hantera parametrarna i styrenheterna. Eftersom verktyget DevelopmentTool används på användargränssnittnivå blev implemente-ring väldigt enkelt. Nackdelen med användargränssnittnivå integration för slutpro-totypen betyder också att uppdateringen av DevelopmentTool kommer att bli kom-plicerad. På grund av användning av detta verktyg kunde man återanvända meto-derna som fanns med i applikationen redan med hjälp av kommandoradsgränssnitt och bygga upp nya funktioner ovanpå dem.
41 | ANALYS OCH DISKUSSION
5.3.3 Annat ECU data
För hantering av annat ECU data som enheternas namn, CAN-adress och unikt komplettnummer valdes MainLibrary. Detta bibliotek förenklade utvecklingspro-cessen för att den hade en detaljerad API:n för att utgå ifrån. Det möjliggjorde även att processflödet som skapades för återställningsverktyget kunde styras på grund av API-nivå. Styrningen av flödet blev enkelt genom att spara bara det nödvändiga datat från styrenheterna i enkelt hanterbart format i slutprodukten. Det datat kunde vidare användas för flashning och reservdelsprogrammering.
5.3.4 Hantering av felkoder
I prototypen används MainLibrary för att hantera felkoder från styrenheterna. Detta på grund av att DevelopmentTool, som annars ansågs vara ett bättre alterna-tiv för uppgiften stödjer inte funktionen från sitt kommandoradsgränssnitt. Den enda svårigheten med användning av MainLibrary var att användaren inte får nå-gon beskrivning av felkoder i styrenheter, som är viktigt om användaren vill läsa av felkoden och vill veta mer om hur de felkoderna kan diagnostiseras.
5.3.5 Flashprogrammering
Flasher valdes för att utföra flashprogrammering. Integrationen av Flasher i slut-produkten var på API-nivå integrationen i EAI-modellen. Flasher hade ingen avgö-rande fördel utan snarare att de andra alternativen hade för stora nackdelar. Själva integrationsprocessen gick enkelt vid utveckling av slutprodukten efter en bra demo på vilka funktioner som anropas vid flashning i Flasher.
5.3.6 Reservdelsprogrammering
MainLibrary har också valts för reservdelsprogrammering återigen för att det måste implementeras som en del av andra komponenter, så det satt inga krav nya beroenden i slutprodukten. MainLibrary för reservdelsprogrammering var relativt enkelt att implementera och var väldigt bra förklarat i API:n. Eftersom även SOPS-läsning i återställningsverktyg från fordon görs via detta bibliotek var det smidigare att bygga på samma applikation än de andra alternativen.
5.4 Författarnas bidrag
Författarna var lika insatta i uppgiften och utveckling av slutprodukten. Alla do-kument som krävdes underhållning togs hand om av författarna ständigt under examensarbete. Skriftlig dokumentation av återställningsverktyg i form av en rap-port skrevs av båda författarna. För det första introducerades författarna till vilka verktyg som möjligen kan användas under integrationsprocessen av handledaren på Scania och vilka borde intervjuas angående de olika verktygen. Även första ut-kastet av återställningsprocessen togs fram av handledaren för att hjälpa författar-na att komma igång med examensarbete.
43 | SLUTSATSER