Efter att den teoretiska modellen utarbetats anpassades den till vad som var prak-tiskt genomförbart genom möten med ingenjörer på företaget. Resultatet blev en implementeringsmodell som användes som bas vid implementeringen. Här redo-visas skillnader mellan implementeringsmodellen och den teoretiska modellen.
4.3.1 Kommunikation
Den svagaste länken när det gäller kommunikationen är RS232, inte bara ur säker-hetssynpunkt. På grund av att datorns operativsystem, Windows, inte har realtids-möjligheter eller avbrott orsakade av inkommande RS232 via USB kan kommu-nikationen bli långsam trots att processorns klockfrekvens är hög. Detta illustreras i figur 4.5. Från det att ett meddelande kommit in tar det tiden T tills kommu-nikationsprocessen får köra. Om det kommer många bekräftelsemeddelanden är det risk att kommunikationen blir långsam, om processen måste vänta varje gång. Detta orsakas av att Windows inte har avbrott för RS232 via en USB-adapter, vilket är det som används vid uppgraderingen. Vid fast COM-port finns stöd för avbrott, men sådana portar är nu ovanliga i bärbara datorer. Vid mobil uppgrader-ing ute hos en kund används bärbara datorer med den USB till RS-232-adapter som Plockmatic säljer.
Kommunikationsprocessen Andra processer Kommunikationsprocessen Tiden T Meddelande kommer in Tid
Figur 4.5: Meddelandeproblematiken. Med för många bekräftelser från styrkortet kan kommunikationen bli långsam. Det tar tiden T innan kommunikationsprocessen får köra och kan hantera det inkomna meddelandet.
Det är viktigt att inte skicka för många bekräftelsemeddelanden, men det är också viktigt att inte låta det gå för långt åt motsatta hållet. Det finns en risk att flöda mikrokontrollern med meddelanden så att data går förlorad. Därför är det viktigt att noggrant testa vad mikrokontrollerna har för prestanda för mottagande. För att lösa problematiken skickas en räknare med varje meddelande via RS232. Räknaren ökar för varje meddelande och mikrokontrollern kan därför avgöra om ett meddelande försvunnit. Om så skulle ske begärs omsändning. Det är även
4.3. IMPLEMENTERINGSMODELL 33
viktigt att utreda om prestandan blir bäst om mikrokontrollern som agerar brygga mellanlagrar data eller på direkten skickar meddelanden vidare ut på CAN.
4.3.2 Initiering
Eftersom det bara sker kommunikation på CAN-nätverket då maskinen kör är det onödigt med tyst läge. Noderna svarar bara om styrkortet skickar någon form av
begäran. Det enda fall då noderna självmant skickar meddelanden är om någon lucka på maskinen öppnas, men ett sådant meddelande är kort och skulle inte störa en uppgradering.
4.3.3 Uppgradering
Enligt den teoretiska modellen ska styrkortet mellanlagra data som en buffert in-nan data skickas vidare. Det kan vara att föredra att styrkortet är helt transparent för kommunikationen, och bara skickar vidare meddelanden som kommer in utan att buffra. Det kan dock vara så att det behövs en buffert på grund av hur datorn skickar data. Om data kommer stötvis kan det vara fördelaktigt med en mellan-lagring som ser till att kommunikationen på CAN-bussen kommer mer jämt. Detta måste utredas under implementeringen. För att förenkla kommer noder med sam-ma program i ett inledningsskede att uppgraderas sekvensiellt. Boot-sektorerna kommer inte att modifieras, utan endast de sektorer som är tillgängliga för använ-dare kommer uppdateras.
4.3.4 Säkerhet
På grund av att större delen av Flashminnet vanligtvis används finns det inte mycket plats över till uppgraderingsprogrammet. Av den orsaken finns det med nuvarande hårdvara inte möjlighet att implementera förslaget som redovisades i 4.2.4, med lagring av flera versioner av mjukvaran. För att strategin skulle vara genomförbar behövs mikrokontroller med flera gånger större Flashminne än de som används i Plockmatics maskiner. Om något oförutsett skulle inträffa, som att upp-graderingssladden rycks ur eller att säkringen går mitt under en uppdatering går det att reparera skadan. Det kortet som drabbades kan installeras om manuellt på samma sätt som tidigare, genom att en sladd kopplas direkt till mikrokontrollern. Det medför merarbete men förstör inte hårdvaran.
34 KAPITEL 4. UTFORMNING
4.3.5 Verifiering
Det är inte säkert att den lösning för verifiering som valts i den teoretiska modellen är mest effektiv. Det kan vara enklare och lika effektivt att verifiera i noden innan datan skrivs till Flash. När datan sedan skrivits kan den läsas och jämföras mot det som finns i RAM. Det måste utredas och testas vilken version som är mest effektiv.
4.3.6 Flödesscheman
Om initiering, uppgraderingen och verifieringen ska implementeras som föreslagits i 4.3.2 till 4.3.5 ändras de flödesscheman som tidigare visats. I initieringsflödet försvinner tyst läge och får utseendet som visas i figur 4.6a. Huvudflödet blir kraftigt förenklat då ingenting längre sker parallellt, se figur 4.6b. Verifierings-schemat försvinner helt, medan uppgraderingsVerifierings-schemat får nya block, se figur 4.6c.
4.3. IMPLEMENTERINGSMODELL 35 Initiering CAN translate mode Order: Noder rapportera in Noder rapporterar in ID, modell och mjukvaruversion Noderna svarar i ID-nummrens prioritetsordning Behövs uppgradering? Nej Ja Slut. Visa resultat
(a) Schema över initieringsflödet, utan
tyst läge. Start i PC Slut. Visa resultat Noderna uppgraderas i ID-nummrens prioritetsordning. Verifiering sker innan skrivning till Flash Uppgradering Mjukvara verifieras och installeras i noder Initiering Initiera uppgradering
(b) Huvudflödet blir förenklat då ingen parallellitet längre finns.
Uppgradering Styrkort vidarebefodrar på CAN A Noder mellanlagrar i RAM
RAM fullt? Nej
Program skrivs till Flash Ja Hela programmet i Flash? Ja Nej Verifiera meddelande för meddelande Läs Flash och Jämför med RAM (c) Uppgraderingsflödet får nya block då verifieringen sker integrerat med uppgraderin-gen.
Kapitel 5
Genomförande och Resultat
I det här kapitlet redovisas utvecklingsarbetet och det resulterande systemet för uppgradering av Plockmatics maskiner.
5.1 Verifiering
På grund av den knappa tiden för projektet kunde tyvärr inte verifieringen inklud-eras i implementeringen. Verifieringen är en viktig del för att säkerställa att en uppgradering gått rätt till och att den nya mjukvaran kommer fungera. Effekten av att verifiering nu saknas är att oupptäckta fel kan uppstå som ger plötsliga krascher eller oförklarligt beteende.