Der er mange ting, der skal tages højde for i forbindelse med designet af en elbil i topklassen.
En del af bilens software er baseret på open source-styresystemet Linux, der blandt andet bliver brugt til at styre underholdsningssystemet og vise data på den 17 tommer store touchskærmen, fortæller Teslas tekniske direktør JB Straubel i et interview med IDG News Service (IDGNS).
Skærmen giver adgang til forskellige aspekter af bilens ydeevne, samt køretøjets musiksystem.
Læs også: Første testkørsel af Tesla Model S
»Vi har skrevet et meste af softwaren selv. Alle skærmene, man kan se, er programmeret og designet her, og så har vi et helt hold af softwareingeniører, der har implementeret det og gjort det til virkelighed. Til styring af motor og den slags ting bruger vi ikke et operativsystem. Det kører i C-kode,« fortæller JB Straubel.
Adskillelsen, hvor Linux og underholdningssystemer er på den ene side, og hjemmelavet C-kode og bilens kritiske systemer er på den anden, er lavet, så bilens centrale kørefunktioner (fremdrift og den slags) ikke står og falder med, hvorvidt styresystemet crasher.
»Det er hovedpointen. Hele underholdningssystemet, touchskærme, og alle de applikationer, man kunne finde på at indlæse, er fuldstændigt adskilte fra bilens fremdrift. Hvis man blev nødt til at afbryde skærmene i bilen, mens man kører, så ville bilen kunne fortsætte uden problemer. Man ville ikke kunne følge med på Google Maps, men man ville stadig kunne køre og stoppe og alt muligt andet.«
Bilens tekniske finesser passer umiddelbart godt til virksomhedens kunder, som Teslas tekniske direktør beskriver som teknologisk kyndige og 'early adaptors', hvilket beskriver folk, der er hurtige til at tage ny produkter og teknologier i anvendelse.
»Jeg tror Model S i virkeligheden er et overgangsprodukt. Roadster var for hårdkogte fans og folk, der enten elsker ydeevne eller teknologi. Model S forsøger at lægge en bro henover kløften. Vi ser kunder med Model S, som er langt mere mainstream. Teslas mål er at rykke grænserne for teknologien i elektriske køretøjer og med tiden skubbe på en revolution i hele industrien,« siger JB Straubel.
»Vi kommer ikke til at bygge alle elbiler, men vi ønsker helt sikkert at ændre tankegangen og folks barrierer i forhold til, hvad de tror, er muligt, og vi presser prisen ned på vores køretøjer med hver efterfølgende generation,« fortæller den tekniske chef og tilføjer, at Model S koster omkring det halve af Roadster og estimerer, at selskabets tredje generations platform kommer til at være endnu billigere.
»Måske omkring 30.000 dollar (ca. 180.000 kroner, red)«.
JB Straubel fortæller desuden til IDGNS, at Tesla-bilens batterier er lithium-ion. I den forbindelse påpeger han, at batteriteknologien hele tiden forbedrer sig. Han vurderer, at batterierne bliver syv-otte procent bedre om året, og han mener, at batterierne er på kanten til at kunne konkurrere med benzinbilernes rækkevidde.
Batterier er da - måske ikke overraskende - også et af de udviklingsområder, som Tesla fokuserer mest på.
»Batterier er stadig i toppen af listen. Det er stadig noget af det vigtigste i køretøjet. Software er også meget kritisk for os, og vi investerer en masse arbejde i god software.«
Techworld: Tesla CTO talks Model S, batteries and in-car Linux
Med mindre der kun er én tråd til hele motorstyringen (mon dog), så skal der nok som minimum et lille realtidsoperativsystem til at skifte mellem de respektive parallelle programmer til overvågning og styring af de forskellige kritiske funktioner.
Alt andet ville undre mig såre.
Måske kører det ikke ud af en computer, men flere, som så kommunikerer asynkront vha. e.g. CAN. Hver computer laver kun en ting.
Hvis det kører på en enkelt computer er der jo nok et scheduler, men at kalde det et operativsystem er måske lige i overkanten hvis man sammenligner med linux. Der er nok ikke noget der hedder kernel space/user space og alt det der ellers kendetegner operativsystemer. Men det kan da godt være at definitionen af ordet strækker sig helt ned til en scheduler.
Jeg vil æde min gamle hat på, at de har brugt et afprøvet, kommercielt produkt, som f.eks. QNX Neutrino: http://www.qnx.com/products/neutrino-rtos/...
QNX kalder det selv for et OS, og det har da også kernel/userspace sammen med realtidsfunktionalitet.
Virksomhed installerer operativsystem på datamat og udvikler deres eget programmel ovenpå. RYD FORSIDEN!
Med mindre der kun er én tråd til hele motorstyringen (mon dog), så skal der nok som minimum et lille realtidsoperativsystem til at skifte mellem de respektive parallelle programmer til overvågning og styring af de forskellige kritiske funktioner. Alt andet ville undre mig såre.
Du behøver ikke et operativsystem, for at lave multitasking. Der findes mange muligheder, for at løse problemet.
En simpel en, er at lave en simpel task-switcher. På microcontrollere, vil den typisk bestå af en push af registre, samt en load af stackpointeren, samt pop af registre igen. Det koster kun få liniers kode. Du laver så interrupt rutiner mv. til at manuelt styre task-switchingen, uden fancy operativsystem. Ofte vælges et hovedtask, der kun er en løkke, hvor der står task(1), task(2), task(3) osv. og forfra, og i alle løkker, hvor der intet er at lave, skiftes til dette task. Den opstarter så næste task, hvorfra den kom. Naturligvis, kan man også lave hovedtasken, så den i nogle tilfælde, springer et task over, hvis det ønskes, men som regel, vil det pågældende task selv hurtigt returnere, hvis der intet er at lave. I f.eks. en venteløkke, vil hovedtasken task(0) normalt kaldes hurtigt, så snart det er tjekket, at der stadigt intet er at lave (polling).
Det er meget nemt at lave multitasking uden operativsystem, og det er også nemt at lave realtidssoftware. Men, det kræver, at du til gengæld, selv har lidt begreb om, hvordan processoren fungerer, og kan prioritere dine interrupts, og skrive interrupt rutiner.
Mange vælger at undgå multitaskingen, og lave det hele interrupt styret. Det er også muligt. Igen, er det vigtige, at prioritere sine interrupts korrekt, når du laver et realtidssystem, samt at skrive koden, så den er hurtig nok.
En tredie måde, er at lave alt i en stor løkke, som gentages og gentages. Hele processoren, genstartes måske 10 - 100 gange i sekundet. Det kan ske, af en indbygget watch-dog timer i processoren, eller af eksternt hardware. Dette er en meget sikker metode, fordi det sikrer, at indstruktionspointeren ikke kan "løbe løbsk". Selve kodningen, fungerer ved, at de forskellige dele - uanset om de er parallele eller ej - skrives til, at være periodiske, og at kunne "fittes ind" i den pågældende løkke. Det er så bare, at sætte dine rutiner efter hinanden, og det er så godt som parallelt.
Den største ulempe, er at du har en fixed repetationshastighed, for din løkke. Men ofte betyder det intet, hvis din repetationsløkke er hurtig nok, og din CPU er hurtig nok. Har du et problem, du ikke kan løse i et enkelt gennemløb, vil man lave en tilstandsmaskine, således du bruger to, eller flere gennemløb. Det første man gør, når man laver koden på den måde, er at sikre at de data, som overleveres imellem genstarter, er korrekte. Det kan ske, ved at de gemmes dobbelt, eller tredobbelt, og at softwaren så undersøger, at de er korrekte - og hvis der er fejl, så tager højde for dette, f.eks. i form af fejlkorrigering, og reinitialiseringer af hardware mv.
Denne metode, er ofte den foretrukne, når det skal være stabile systemer. Du er sikker på dine løkkers repetationshastighed, og systemet har særlig stor robusthed, fordi en støjpuls, ikke vil hive noget ud af fatning. Ved næste genstart fanges problemet, og det hele virker korrekt, f.eks. et millisekund efter, hvis kodningen er gjort korrekt.
De fleste professionelle, vil derfor undgå operativsystemer. Operativsystemer, er ofte for dårlige, og ikke så sikre, som kode hvor alt går i løkke, der genstartes 100 - 1000 gange i sekundet.
Ofte, har man i øvrigt i bunden af koden, en lille ekstra test, i form af en tæller, så der kan ses at hele koden er nået igennem. Sker en fejl, så vil tælleren ikke matche den i toppen af koden, og softwaren kan tage højde for, at noget er gået galt. Der kan også være en fejl-LED, der tændes permanent, hvis der opstår fejl, for at indikere, at noget er galt.
Programmet kan dupplikeres, så samme kode, er i hukommelsen 3 eller 4 gange, og lige efter reset, sendes eksekveringen til en af de fire programmer på skift. Hvis de skrives af forskellige programmører, så opdages, hvis de ikke virker ens. Og opstår en bitfejl i programhukommelsen, så kan det også opdages, og den pågældende kode, kan kobles ud, samtidigt med fejl-LED's tændes.
Dem, der er vandt til, at programmere microcontrollere, vil nok ikke bruge et operativsystem, og hellerikke et realtids operativsystem. Det er ganske enkelt ikke så sikkert.
Ovenstående er godt, i mange styringssammenhænge, hvor du har en løkke som repeteres. Det gælder ofte i f.eks. servosystemer, bremsesystemer osv.
Men, i nogle tilfælde, ønskes måske operationer, der ikke kan nås i et enkelt gennemløb. Så er standard metoden, at bruge en tilstandsmaskine. Der vil som regel bruges flere bits, på at indikere tilstanden, således at hvis der skulle opstå fejl i hukommelsen, at det så ikke går galt.
Et alternativ til en tilstandsmaskine, er en lille "fortolker". Fortolkeren er langsom, men mere sikker, end compileret kode. Fortolkerløkken genstartes måske 1000 gange i sekundet, og er designet til, at udføre et passende antal indstruktioner, for hver gang løkken udføres. Typisk, vil man fortolke noget maskinkode til en simpel processor, som man har en compiler til. En sådan fortolker, koster næsten ingen kode. Det, som er interessant, er at man kan lave fortolkeren fejltollerent, således at alt der læses fra hukommelsen, læses dobbelt, og sikres er korrekt. Alle data, som gemmes i hukommelsen, kan gemmes dobbelt, eller flere gange, så data kan automatisk fejlrettes, hvis der er fejl. En sådan fortolker gør, at du kan oversætte noget kode, f.eks. C, til en simpel processor, som du har lagt fortolkning ind for, og du opnår ganske vist noget langsom kode, men det er ekstremt sikkert, da fortolkeren hele tiden genstartes, indstruktionspointeren kan ikke løbe løbsk, og alle variable, indstruktioner osv. læses redundant fra hukommelsen, og fejlrettes. Fortolkeren kan fungere, så den har flere tasks, der fortolker samme kode tidsforskudt, og dermed fanger evt. støjproblemer.
Kommentarer (6)