Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 34 reacties

OpenSynergy heeft op de Cebit zijn Coqos-besturingssysteem voor in-car head units gelanceerd. Het deels gevirtualiseerde systeem voldoet aan de Autosar-standaard en werd gedemonstreerd op een Intel Atom-platform.

Autofabrikanten hebben in het afgelopen decennium te maken gehad met een wildgroei aan ecu's in hun modellen. De processors worden gebruikt voor de besturing van allerhande functionaliteit, van de richtingaanwijzer tot het navigatiesysteem en de motor. De tientallen besturingseenheden zorgen voor een toenemende complexiteit en lange ontwikkelingstrajecten. Een groot aantal autofabrikanten en toeleveranciers heeft zich verenigd in de Automotive Open System Architecture (Autosar), die tot doel heeft om een gestandaardiseerde softwarearchitectuur voor automobiele toepassingen te ontwikkelen. Het Duitse softwarebedrijf OpenSynergy lanceerde op de Cebit een besturingssysteem dat compatibel is met Autosar en geschikt is voor ARM- en x86-hardware.

Coqos is een real-time besturingssysteem dat de componenten van de Autosar-omgeving verbindt met een gevirtualiseerd gastbesturingssysteem. Op dit moment wordt alleen de Linux 2.6-kernel ondersteund. In de Autosar-omgeving draaien functies die kritisch zijn voor de veiligheid van het voertuig, zoals stabiliteits- en tractiecontrole, cruise-control en afstandsbewaking. Het gastbesturingssysteem wordt gebruikt voor infotainmentapplicaties van bijvoorbeeld de communicatie en navigatiesystemen. Door deze programma's in een virtuele machine te draaien, moet voorkomen worden dat veiligheidskritische functies van de auto door kwaadwillende personen vanuit de infotainmentomgeving gemanipuleerd kunnen worden. De scheiding zorgt er tevens voor dat de kritische functies binnen een opgegeven tijd uitgevoerd worden en maakt het mogelijk om het gastbesturingssysteem af te sluiten of te rebooten terwijl de basisfuncties van de auto in werking blijven. De beide werelden hebben toegang tot een interface voor audio en graphics.

OpenSynergy Coqos diagram

OpenSynergy was aanwezig als partner van Intel in het paviljoen dat de chipgigant op de Cebit had afgehuurd. Het softwarebedrijf demonstreerde zijn besturingssysteem op een evaluatiebord met een Atom-processor. Op de gevirtualiseerde Linux-kernel draaide een open source navigatieapplicatie en tevens was het demosysteem voorzien van een richtingaanwijzer. Om de scheiding tussen Linux en de veiligheidskritische functies te demonstreren, werd de Linux-kernel geboot terwijl de richtingaanwijzer bedienbaar bleef. Magneti Marelli toonde een demonstratie van een port van de iDrive-interface die deze toeleverancier voor BMW had gemaakt. Ook hier werd gebruikgemaakt van het Coqos-framework en een Atom-platform.

OpenSynergy verwacht dat Autosar in 2010 zijn intrede in nieuwe automodellen zal doen. De nieuwe BMW 7-serie heeft reeds zijn netwerk- en geheugenmanagement en een groot deel van de diagnosefuncties via Autosar geïmplementeerd.

OpenSynergy Coqos demosysteem met Intel Atom

Magneti Marelli demosysteem met Intel Atom
Moderatie-faq Wijzig weergave

Reacties (34)

Dit geeft idd een hoop mooie mogeljikheden maar ook een hoop extra risico.
Je wilt niet dat een hacker je remmen op afstand kan bedienen of dat je politie je onboard pc hacked om je onopvallend te kunnen volgen...

Daarnaast is het veel storingsgevoeliger, zowieso met nieuwere auto's. Die zitten vol met sensoren en regelaars. Die wil je niet meer tweedehands kopen..Een auto zonder sensoren doet het of is kapot maar zo´n auto kan ook heel veel storingen hebben zonder dat er daadwerkelijk iets echt kapot is.
Ik vind het dan ook vreemd dat T.net en de automakers zo'n systeem echt zien zitten.

Wat kost het nu extra om een simpele controller ernaast te zetten, zodat je altijd een onafhankelijk systeem hebt? Een paar Watt in verbruik en een paar euro in kosten. Terwijl het risico enorm is. Virtualisatie geeft een stuk veiligheid, maar ook een stuk schijnveiligheid. Je gast OS kun je best rebooten, zolang dat geen spannende dingen doet met hardware versnelling, maar als er bijvoorbeeld een grafische kaart of versneller in het systeem zit kan je gast OS nog steeds (een poging wagen om) je hardware ook mee te nemen in de crash.
Daarnaast neemt de complexiteit enorm toe, terwijl je anders een simpele interface gebruikt om alle gegevens van het ene systeem naar het andere en terug te sturen. Die interface heb je zelfs in dit systeem waarschijnlijk al nodig, maar nu krijg je ook alle virtualisatie problemen erbij.

Het risico op gecompliceerde bugs komt elke keer terug bij een hardware revisie. Als je van een single core naar een dual core Atom gaat en Intel heeft een foutje gemaakt kun je je met 200 om een boom vouwen. Laat je die 2 systemen los van elkaar, dan valt misschien je dashboard uit, maar dan kun je de auto nog wel stilzetten.
In een vliegtuig zijn al die systemen ook dubbel of zelfs driedubbel gescheiden, waarbij elke koppeling tot in het onzinnige moet worden getest en beveiligd en bij een auto gooien we het maar op n hoop?
Ik vermoed dat je hier wat overhaaste conclusies trekt, niet dat ik het niet met je eens ben (de veiligheid en betrouwbaarheid moet bij dit soort systemen absoluut perfect zijn), maar het hier beschreven systeem is louter een demonstratie bedoeld om de toekomstige mogelijkheden te 'demonstreren'.

Het lijkt me voor zich spreken dat, helemaal bij BMW, elke kleine update - en al helemaal die op software/hardware gebied - uitvoerig zal worden getest voordat deze in productieauto's te zien zal zijn.
Wat kost het nu extra om een simpele controller ernaast te zetten, zodat je altijd een onafhankelijk systeem hebt?
Da's ook schijnveiligheid - een probleem met bv de voeding (evt veroorzaakt door dat 2e systeem) haalt ook het 1e systeem onderuit.
Wat mij betreft horen de "core" en de "fun" systemen dan ook te werken via geheel gescheiden circuits, inclusief onafhankelijke voedingen die apart gezekerd zijn. Je kan een communicatiebus tussen de twee bouwen, maar die mag m.i. uitsluitend n kant op werken, van "core" naar "fun" en e.e.a. moet goed beschermd worden aan de "core" kant tegen grappen als kortsluitingen, overspanningen en vage signalen op dit communicatiebus.

Er is gewoon geen goede reden waarom de core systemen van een auto op dezelfde unit zouden moeten draaien als de leuke dingen er omheen. Je zou daarin gewoon geen enkel risico moeten willen nemen.
Dat is dus al praktijk. De CAN bus is typisch gesplitst, met read-only access voor de infotainment laag. Navigatie is meer dan fun, maar heeft snelheidinput nodig n yoegang tot het audio systeem.
Als je het kunt lezen dan kan je het benvloeden. Ik doe niets anders bij bepaalde demo projecten waarbij ik 0,0 informatie van de constructeur heb en ik toch bepaalde functionaliteiten moet bekomen. Dan hijack ik een ID en submit mijn eigen bericht op de CAN. Het gaat er wel om dat je het goed doet natuurlijk zodat de gevolgen beperkt zijn ;)
Als dit op electronisch niveau is beveiligd dan lijkt me dat toch knap lastig. Als er een poort is waarop gewoon een "kopie" van bijvoorbeeld het actuele toerental en snelheid word aangegeven. Dan kan je wel proberen daar iets op te zetten maar dat maakt echt niet uit.
Met kopie bedoel ik dus dat het niet core -> fun -> core is (lus).

[Reactie gewijzigd door thegve op 9 maart 2009 19:54]

Het ging tijd worden dat de wildgroei aan automotive systeembussen een halt toegeroepen wordt en onderzoek wordt gedaan naar n systeem dat de hele auto aan kan. Momenteel vind je in BMW's, Volvo's, volkswagen, ... soms tot 7 systeembussen (een paar CAN-bussen, een paar LIN-bussen, en de snellere flexray bus) die beheerd worden door 1 of 2 controllers.
Op deze manier is het "electronica" gedeelte van een auto zeer complex en een nachtmerrie voor elke ancien automechanieker. (Tot op heden gaan mensen met autoproblemen nog steeds naar de garage en niet naar de pc-winkel)

Met de ontwikkelingen van drive-by-wire, steer-by-wire en andere systemen waar een 0% foutentoleratie en allertheid van toepassing is, is flexray zeer sterk aan het opkomen bij de duurdere, innovatievere merken. De CAN bus wordt dan nog steeds gebruikt voor verwarming, lichten, radio, radiobediening op het stuur, airco, centrale deurvergrendeling, ...)

De dag dat er 1 processor en 1 systeem gestandaardiseerd zal worden is dit goed nieuws voor fabrikanten, herstellers en klanten. Ik kan alleen maar hopen dat dit snel een standaard wordt.

[Reactie gewijzigd door B-BOB op 8 maart 2009 20:13]

Er is geen (draadloze) verbinding met de buitenwereld? En ik neem aan dat de USB of CAN plug ook niet aan de buitenkant van de auto zit.

Bovendien hebben huidige auto's ook een CAN aansluiting voor het uitlezen en eventueel veranderen van de ECU (Engine Control Unit).

Ik zie dus niet zo'n gevaar voor wat betreft de veiligheid. Je moet er zelf niet al te veel mee gaan prutsen, maar dat geldt ook voor de mechanica in huidige auto's. Je kunt zoveel veranderen als je zelf wilt, dat is ook niet altijd bevorderlijk voor de veiligheid.
ECU (Engine Control Unit).
Maak daar maar Electronic Control Unit van. En daar heeft een gemiddelde moderne auto er tientallen van. Van motormanagement tot bluetooth interface boxje.
Dus elke auto met injectiemotor valt voor je af? Sensoren ontkom je zowiezo niet aan, hoe simpel ze soms ook zijn.
Ik rijd in een auto van 18 jaar oud met injectie, maar om de aansturing van die sensoren nou "boordcomputer" of regelaar te noemen die heel storingsgevooelig is vind ik weer wat ver gaan...
Je vergeet voor het gemak maar even dat er ook nog iets als een mechanische injectie bestaat?
bron
In die goede oude tijd was alles nog te overzien.
Aan de ene kant hoop ik dat door dit open systeem er veel meer gehobbied kan worden door enthousiastelingen op zowel autogebied als IT-gebied (geen proprietary interface op de open standaard).

Aan de andere kant hoop ik dat het systeem wel dusdanig in elkaar zit dat het niet zondermeer te "hacken" valt door iemand die zich toegang heeft weten te verschaffen tot het systeem in de auto van een ander... Zi te zien ligt de basis van een goede beveiliging er wel, en ik hoop dat deze goed in stand gehouden wordt.
Ik vrees dat dit misschien wel door de openheid riskant kan zijn, immers, iedereen kan lekken vinden, en dan kan je wel een patch maken, maar om heel eerlijk te zijn, welke auto is nu 24/7 aangesloten op het internet? Voor mijn gevoel is een auto nog steeds zoiets wat je hooguit 1x per jaar bij zijn beurt zal updaten.
Meeliften op iemand anders zijn WiFi is niet legaal tenzij diegene toestemming gaf (WEP of open geld niet als toestemming), en om wr een mobiel nummer te gebruiken om voor een tientje per maand via een SIM-kaart en Dongel een 3G verbinding (wat overigens ook niet 100% dekking heeft) op te zetten is k niet praktisch. En duur. En leuk als je naar het buitenland gaat of met je SUV over de savannes in Afrika gaat rijden.

Nee, doe mij maar zoveel mogelijk n de auto zelf. De cloud is geen cloud, maar een bubbel.
Onderbouwing? Artikel 138a stelt dat het brekenb van WEP illegaal is, maar een open AP mag je gewoon op: je doorbreekt geen beveiliging (lid 1a), je doet geen technische ingreep (lid 1b) om erop te kunnen, je gebruikt geen valse sleutel (lid 1c) en je geeft je niet voor een ander uit (lid 1d). De wet gaat uit van "toegestaan tenzij verboden".
Het is gewoon strafbaar om, zonder toestemming, van iemand zijn router/verbinding gebruik te maken. Dat geldt zowel voor beveiligde als onbeveiligde verbindingen. Dit staat bekend als "computervredebreuk" (als variant op huisvredebreuk). De aloude vergelijking, welke ook opgaat voor computers, als mijn voordeur open staat of niet op slot is, dan geeft dat geen recht mijn huis te betreden.

Nieuwe wetgeving
(...) is een recente wijziging van artikel 138a in het Wetboek van Strafrecht. Dit artikel stelt computervredebreuk (hacking) strafbaar. Margot Wiertz-Ermers van SOLV advocaten, gespecialiseerd in onder meer computercriminaliteit, legt uit: "De wetgever vindt het noodzakelijk dat hacking zo krachtig mogelijk kan worden bestreden en daarom is de wet per 1 september 2006 aangepast. Voorheen was het zo dat men strafbaar was wanneer men bij het binnendringen van een computersysteem van een ander enige beveiliging doorbrak.Dat is nu niet meer het geval. In de praktijk betekent dit dat ook wanneer meegelift wordt op een onbeveiligde verbinding, men een strafbaar feit pleegt."

[Reactie gewijzigd door Limbids op 8 maart 2009 10:34]

Zo lang je je auto pas kan openen en inschakelen met een al dan niet digitale sleutel is het niet n twee drie the hacken, simpelweg omdat je geen fysieke toegang tot de hard-/software hebt...

Edit:

Even de internet verbinding terzijde natuurlijk...

[Reactie gewijzigd door Swerfer op 7 maart 2009 14:41]

Aan de ene kant hoop ik dat door dit open systeem er veel meer gehobbied kan worden door enthousiastelingen op zowel autogebied als IT-gebied (geen proprietary interface op de open standaard).
God verhoede het :)

Ik zit in de auto R&D en ik weet zelf nog niet helemaal hoe alles in elkaar steekt maar om je een glimp te geven: om de motor af te stellen: 10 000 parameters, om de versnellingsbak af te stellen kan het om 900 tot 5000 parameters gaan, ABS / ESP / ASR: 500 parameters additionele parameters..

Succes h ;)

Zoiets moet gewoon bij wet verboden worden omdat het gevaarlijke situaties kan geven.
Aan de ene kant hoop ik dat door dit open systeem er veel meer gehobbied kan worden door enthousiastelingen
Automotive Open is iets heel anders dan Open Source onder bijvoorbeeld BSD licentie. Je kunt lid worden van Autosar (en dat is niet goedkoop) en kunt dan dingen leveren die binnen het framework passen (waar je allerlei dure tools voor nodig hebt).
Zoals ik het begrijp is Autosar bezig een standaard te ontwikkelen voor communicatie met de boordcomputersystemen, en daarnaast virtualisatie waar derden gebruik van kunnen maken. Hierop draait al een 2.6 kernel. Dan lijkt het me erg stug dat je bijvoorbeeld geen alternatief navigatie/MCE systeem hierop gaat kunnen draaien.
Windows is ook gesloten, toch draait Firefox erop. Het mooie van virtualisatie is juist dat het niet nodig is om het "moedersysteem" aan te passen om allerlei child-systemen hierop te kunnen draaien.
Qua motormanagement is weer heel wat anders natuurlijk, al verwacht ik bijna dat als dit niet open word gezet er wel weer vage mod chips op de markt zullen verschijnen om dit toch voor elkaar te krijgen.
Haha even de auto van de buurman een betere wegligging geven en hem wat sneller laten optrekken :+ .
Of andersom: zodat de Golf GTI van de buurjongen langzamer optrekt dan jouw lelijke eend van 60 jaar oud :+
Ik hoop dat een dergelijke standaard snel zijn doorgang vind. Naar mijn idee zal het juist een extra stukje zekerheid geven. Omdat de ontwikkeling van de soft- en hardware meer aandacht zal krijgen. (van meer verschillende ontwikkelaars). En als de veiligheid/betrouwbaarheid echt een issue is dan is een enkel stuurapparaat eenvoudiger redundant te maken dan twaalf. Al zal er niet voor worden gekozen om alle computers te vervangen voor een, omdat er dan te veel koperdraad door de auto getrokken moet worden. Liever dus lokaal een aantal stuurunits die met can onderling communiceren.

Een ander "leuk" idee als de systemen meer standaard worden kunnen ze taken makkelijker van elkaar over nemen. (kost wel weer meer koper) dus bv het stuurapparaat in de kofferbak valt uit, dan nemen de apparaten onder de kap en in het instrumenten paneel (voor een deel) de taken over eventueel ten koste van minder belangrijke taken.

Wat je nu ook nog vaak heb is dat al aanwezige redundantie niet gebruikt wordt. Bv als de abs sensor van het linkervoorwiel wegvalt heb je vaak geen snelheids signaal in je display meer. (en radio, navigatie en buitentemperatuur correctie ect.) terwijl je nog drie andere wielen met een sensor hebt en vaak is er gps voorhanden die eventueel gebruikt kan worden. (en als het een automaat is zijn er nog meer mogelijkheden). Dus als de verschillende stuurapparaten meer een taal spreken is het waarschijnlijk ook mogelijk dat er meer informatie gedeeld kan worden. Misschien een soort (virtueel)centrale database met alle actuele data.
Ok ik droom wel weer even verder.
Zoals wel vaker wordt betoogd: het geven van openheid zou het systeem niet veiliger of onveiliger moeten maken. Omgekeerd: het niet geven van openheid is schijnveiligheid. Daarmee worden wel stevige eisen aan het ontwerp van het geheel gesteld, want eventuele kwetsbaarheden zijn door iedereen te vinden.

In het schematische plaatje staat een mu-os. Neem aan dat men iets als "micro-os" bedoelt.

Een micro-os is een goed idee. Hopelijk heeft deze laag ook real-time functionaliteit. Het gaat er namelijk niet alleen om dat "fun" en "core" functioneel (toegang tot elkaars functies) gescheiden zijn. Het micro-os zal er ook voor moeten zorgdragen dat de core-functies voldoende capaciteit krijgen, iedere split-second. Een tweaker die tegen beter weten in toch 1080p op zijn in car entertainment systeem wil draaien zou de core-functies hiermee kunnen afknijpen zonder werkelijk toegang tot ze te hebben.

Vrijwel geen enkel OS voor algemeen gebruik heeft echte real-time features. Het is ook nog eens best lastig te realiseren. Het open karakter van dit systeem kan voor grote problemen zorgen als de real-time voorzieningen niet voldoende aanwezig zijn.

In de praktijk: als ik bij mijn auto snel de sleutel in het contact steek, de motor start en de achteruit-versnelling kies, dan laat het piepje van de parkeersensor een paar seconden op zich wachten. Op andere momenten klinkt het piepje direct als de achteruitversnelling wordt gekozen. Het missen van het piepje van de parkeersensor brengt je niet direct in levensgevaar. Je gaat na een tijdje echter wel op het systeem rekenen. Wordt hier de parkeersensor als niet-core naar de achtergrond gedrukt ten gunste van belangrijker taken? Of heeft de processor geen real-time functies en is het bij de start gewoon te druk?
Als ik er van uit ga dat het een moderne auto met can-technologie betreft met originele parkpilot, dan heeft de parkpilot waarschijnlijk een eigen stuurapparaat. Maar die is afhankelijk van diverse info van andere stuurapparaten. Bv het achteruit-rij signaal. Al deze apparaten moeten opstarten als je het contact aan zet, voeren een zelftest uit en checken of ze elkaar kunnen vinden. Dat geeft vaak wat vertraging. Het can-protocol heeft een prioriteits bit voor de diverse boodschappen en het bericht "achteruitrij lamp aan" zal wel geen hoge prioriteit hebben. Het is aannemelijk dat dit bericht iets vertraagt aan kan komen.

Er wordt hier boven gesproken over de (on)mogelijkheden van het draadloos hacken van auto controlesystemen maar ik weet wel dat er al diverse systemen zijn die de mogelijkheid hebben om via de onboard gsm alarm te slaan. En dat de systemen om via die weg inzicht in de onboard data te krijgen aanwezig is. Dus zo theoretisch is die mogelijkheid niet. En in de nabije toekomst zie ik het wel gebeuren dat er een soort ad-hoc intercar netwerk gaat komen om bv de verkeerslichten beter te laten functioneren en navigatie systemen sneller alternatieve routes te laten berekenen. (om maar een paar bescheiden mogelijkheden te noemen).

[Reactie gewijzigd door engibenchi op 8 maart 2009 21:11]

Bij VLD Ambassdor bussen is bij problemen met de motor het opnieuw "opstarten" van de bus meestal de oplossing (motormanagement wordt dan herstart namelijk).

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True