Vilka typer av problem existerar för inbyggda system

Permalänk

Vilka typer av problem existerar för inbyggda system

Tänkte ta tag i kandidatuppsatsen nu till VT22 och få det klart till sommaren. Jag läste datavetenskap och fick jobb så orkade inte lägga ned den tiden med att påbörja uppsatsen. Jag arbetar med inbyggda system, men har väl egentligen arbetat för kort tid för att avgöra vad för typ av problem det finns i branchen som skulle kunna lösas. Hade varit intressant att hitta något/några problem som kan försöka besvaras i en kandidatuppsats.

Är det någon som vet vilka slags problem det finns idag som kan vara värt att skriva om? Svårt eller tidskrävande att få till automatisering av leverans till inbyggda system?

Jag är även riktigt intresserad av blockkedjeteknik/decentralisering.

God jul SweClockers!

Permalänk
Medlem

Nedanstående är inte sexigt alls som blockkedjor och annan popoläristisk teknik utan mer åt hemorrojdhållet och ett verkligt problem för dem som sitter i skiten i förvaltningsrollen...

Minneshantering och minimeringar slitage av flashlagring samt verifiera att det inte får korruption med tiden även i miljöer som är mycket varma (30 grader varma teknikrum med utustning som befinner sig i 40 - 60 grader C meste hela tiden i sina kapslingar) - då menar jag inte vad som en utvecklare ser inför en leverans utan testmetoder i hur det ser ut 10-15 år drift senare för att knyta upp svansen på utvecklare som skriver kod som läcker minne över tiden eller skriver onödigt mycket mot flash-minne för en logfil som är 'bra att ha' eller en webbinteface som lämnar en skvätt filer kvar vid varje strömavbrott och som aldrig rensas och till sist fyller upp hela minne till sista biten och det går inte längre att ens boota om för att det är 0 byte kvar i filsystemet av ren jävla slarv!! i verifieringen senare (den som inte gjordes...), med resultatet av sönderskriven flash-minne, obsolenta komponenter, hur man skall föra över gammal kod i produkter från företag som inte längre finns till ny flash utan källkod eller annan 'intern' information 10-15 år senare i utrustning som knappt går att byta ut och måste finnas fungerande då de ingår i en del livsviktig infrastruktur.

Börja med att hitta verifikationsverktyg som kan analysera och försäkra att det inte skrivs en enda Byte i onödan till flash, räknat i tidspann flera år men också att kvalitetskontrollera och om nödvändigt skriva om flash-minne även för data som är mycket statisk eller aldrig skrivs om - innan de börja ha fel!!.

Det innebär då både att kunna upptäcka fel och ha redundant/paritets-kod så att fel som hittas kan repareras!.

Det för utrustning som sitter väldigt varmt (kanske mycket varmare i klimatskåp vid tester så att åldringen i flashminne går fortare) ideliga plötsliga strömbortfall både i korta (glitch) och med längre mellanrum och omstarten slumpmässigt för att simulera tex en miljö för en tågvagn där ström kan försvinna och återkoppla i ofta under en enda dag och tusentals event under ett år etc.

Dessa problem på gammal utrustning är tyvärr en del av min arbetsvardag... och detta är en rejäl "Pain in ass" för de som skall förvalta sådan utrustning även många år senare...

Och det här problemet med flashminne kommer att öka med dagens sjunkande kvalitet av flash-minne och glöm inte att det är mycket utrustning som inte har 'konsument-livspan' på 3 år utan måste hålla i 10 -15 år och ibland längre än så!!

sedan också det här att kunna fjärruppdatera eller på plats även om flashminnet är totalt sönderskrivet och har segment som redan från början har skrivfel och det enda som fungerar är uboot - ge verktyg även för de som förvaltar att kunna köra in ny firmware från scratch då man inte sitter i någon produktionsmiljö... eller företaget inte finns kvar längre 10 år senare!!

mina fem ören....