Det er korrekt, du kan slå tændingen fra med statknappen - men det vidste køren ikke, da det ikke var oplyst i indstruktionsbogen.
For scootere, findes ingen måde at slå tændingen fra.
Microcontrollere er gode til meget.
Men at involvere dem i en så simpel ting som at afbryde spændingen til brændstofpumpen er ikke noget jeg vil kalde (ekstra) sikkerhed.
Hvis det er microcontroleren, som styrer tændingen, er det ikke risikabelt. Fungerer den ikke, som den skal, kommer der ganske enkelt ingen gnist, og motoren går i stå.
Hvis microcontroleren styrer brændstofpumpen - og det eksempelvis er en 3-fase AC motor, og at microcontroleren leverer de 3 faser, så vil den gå i stå, hvis microcontroleren ikke leverer faserne.
En microcontroler, der "føler" på bremsesignalet, har ofte mulighed for at sikre, at ledningen er i orden. Det kan ske, ved at f.eks. måle modstanden på ledningen. På den måde, opdages f.eks. hvis der er lamper der ikke er i orden. Måske kræves, at bremseren trykkes ned, når bilen startes. Derved sikres, at bremsekontakt og lys er i orden, når lyset startes. En microcontroler, giver mange features, og er oftest langt mere sikker end et relæ.
Det som er problemet er softwarefolket. Når du har en opgave, som f.eks. ovenstående, så starter de med at beslutte den skal programmeres i f.eks. sun's java. Og køre under et microsoft operativsystem, eller Linux. De har ikke den mindste softwareprogrammeringskunnen, når det gælder sikkerhed. Nogle starter også med at kode, fra første dag - helt uden at overveje de sikkerhedsmæssige aspekter. Det som er nødvendigt, er at f.eks. lave programmerne, så de giver skiftende spændinger på udgangen og lign. At kunne lave dem, så der ikke er fejl, memory leaks osv. At de ikke pludselig swappe på en harddisk, og når bilisten bremser - så er der taget højde for det. Displayet siger "vent et øjeblik". Jo, vi har taget hensyn til fejlhåndtering, siger de stakkels programmører... Efter syv sekunder, virker bremsen.
De kan ikke programmere. Opgaverne i sådanne tilfælde, er af en art hvor du skal kunne stå inde for, at de besvares indenfor ganske kort tid - der må ikke være noget der swapper, eller ukendte faktorer. Du kan ikke bruge et operativsystem, der gør den slags. Og opryderen i Java, er måske destruktiv, fordi den forhindrer en bremsning. Det tog lige den tid, som skulle have været brugt på noget vigtigt. Alligevel, har gutterne valgt java, fordi java er sikre. Andre, vælger så straks C, eller C++. Alle disse valg er nærmest ligegyldigt.
Hvordan skal man med microcontroleren styre en brændstofpumpe, så den kører korrekt. Skal det være med et DC signal, hvor størrelsen varieres, eller med et AC signal. Det er ting, som kan betyde noget for sikkerheden. Fordi, at der måske sker noget andet i fejlsituationer, når der kræves AC, eller et skiftende signal fra microcontroleren. Skal det skiftende signal komme hele tiden - og hvordan skal man sikre, at det opfylder timingen? Måske slukker hele systemet automatisk, hvis der ikke kommer en puls inden 20 ms. Disse pulser, skal måske komme uafbrudt, og ellers lukker det ned, eller springer sikringer.
Mange "kodere" vil jeg højst betro, at programmere end PC, der skal vise ligegyldige oplysninger. De data, som virkeligt betyder noget, skal vises på en blinkende blå lampe ved siden af, og måske en kørende sirene. Og det skal være muligt, at se det væsentlige, uden softwaregutternes bras fungerer.
Som regel, vil sikkerhed derfor være opbygget i flere lag - hvor så meget som muligt, der intet betyder, lægges i PC software og laves af afdelingen for spøj og skimt, meddens de virkelige væsentlige ting, kodes i microcontrolere, af nogle der har styr på tingene og timingen til mindste deltalje. Ikke noget med stokastiske interrupt analyser i forbindelse med realtids software. Tingene skal bevises, og bevises ned i de mindste detaljer. Ellers, kan det ikke bruges.
Det som ikke er bevist, hører ikke under de sikrer komponenter.
Microcontrolere, er nogle af de mest sikre komponenter der findes - for selvom de kan hænge, så kan det nemt detekteres. Det betyder, at de kan genstarte, og det kan være taget højde for, hvordan tingene reagerer når signalerne ikke kommer fra microcontrolerne. Når de genstarter, er det ikke noget med at der først opstartes en linux, og efter 7 minutter, så er bilen atter klar til at bremse. Opstarten sker på millieskunder, eller mikrosekunder, således at en eventuel fejl, intet betyder for funktionen. I mange tilfælde, vil det derfor kodes uden operativsystem, for så har man styr på forholdende. Bruges et operativsystem, så er det et man har styr på - incl. dets forsinkelser og ramforbrug. I nogle tilfælde, kan forsinkelser være direkte specificeret i cycles.
Intet overlades til tilfældighederne, når det skal gøres så det fungerer - men, man forsøger, at gøre den del af softwaren og hardwaren så lille og simpel som muligt, for at reducere udviklingsomkostninger, og sikre optimal sikkerhed.
De dele, som intet betyder, får så deres egen processor, og måske windows CE operativsystem. Her, er så vigtigt, at sikre at eventuelle lamper der detekterer farer, også indikeres udenom operativsystemet. For der er ingen garanti for at det virker, eller at det viser sandheden. Måske "hænger" skærmbilledet, eller dele deraf. Opertivsystemer som windows CE, er kendetegnet ved at der ikke har været styr på noget igennem udviklingsprocessen, og der findes hverken timing specifikationer (cycles som ordrerne tager), eller et detaljeret ram forbrug, så man eksakt kan se, at forbruget i bytes, svarer til det som det skal være, og hverken er højere eller mindre. Ofte, står forbruget og stiger og stiger, i mange operativsystemer, hvorefter de så kræver en harddisk. Og de kære programmører, siger "jammen den skulle jo ryde op selv".
