Voldoen aan opkomende vereisten voor betrouwbare gegevensregistratie in autosystemen

Event data recorders (EDR's), vaak black boxes genoemd, zijn niet nieuw in auto-elektronica. EDR's registreren al bijna 50 jaar gegevens in auto's. Gedurende deze tijd is de elektronica in auto's enorm geëvolueerd. En met zoveel onderzoek naar zelfrijdende technologie, zullen er nog meer veranderingen komen.

Deze vooruitgang op het gebied van auto-elektronica heeft de uitdagingen in verband met EDR-datalogging aanzienlijk vergroot. Het is daarom verrassend dat in al die jaren het basisontwerp van EDR niet is veranderd. Een demontage van een vroege GM-airbagcontroller vertoont grote gelijkenis met de datalogging-architectuur die wordt gebruikt in de EDR's van vandaag. Toen en nu wacht de EDR op een gebeurtenis die wordt geactiveerd voordat de eerste gegevens in het niet-vluchtige geheugen worden geregistreerd. Deze benadering van datalogging uit de jaren 70 is blijven bestaan, terwijl andere subsystemen in het voertuig zich gedurende vele generaties hebben ontwikkeld.

Gedeeltelijk bestaat deze situatie omdat herinneringen niet als centraal in EDR-ontwerp zijn beschouwd. Als gevolg hiervan hebben de beperkingen van EEPROM en Flash op hun beurt de mogelijkheden van de huidige EDR's beperkt. In dit artikel gaan we in op deze perceptie en onderzoeken we een alternatieve oplossing om datalogging vooruit te helpen, zodat EDR's kunnen voldoen aan de betrouwbaarheidseisen van voertuigen van vandaag en morgen.

Wat drijft ontwerpwijzigingen in EDR's aan?

Nieuwe regelgeving in Europa en China die het gebruik van EDR's in de meeste klassen van motorvoertuigen verplicht stelt, voegt nieuwe aandacht toe aan EDR-ontwerp. Er is een algemene misvatting dat EDR's al heel lang verplicht zijn, maar dat is niet waar. Zelfs vandaag de dag verplicht Noord-Amerika het gebruik van EDR's niet. Desalniettemin is het gebruik van EDR's op grote schaal overgenomen door autofabrikanten en is het bijna alomtegenwoordig in Noord-Amerika. Europa en China gaan nog een stap verder door de EDR verplicht te stellen voor bepaalde categorieën voertuigen. In de voertuigen van vandaag nemen de bronnen van kritieke gegevens toe en voorschriften vereisen grotere hoeveelheden gegevensopslag voor betere besluitvorming.

Naast regelgeving is er ook een reële behoefte om in autonome voertuigen rekening te houden met verhoogde parameters. In L2+ gedeeltelijk autonome voertuigen (volgens de SAE-niveaus van rijautomatisering) zijn er bijvoorbeeld meer manieren waarop het systeem sensor- en beeldgegevens kan opslaan. Maar geen enkel systeem kan het volledige beeld geven van een kritieke gebeurtenis, met name een crash. Het wordt dus noodzakelijk dat sommige gegevens van ADAS worden opgeslagen in een EDR om de synchronisatie tussen ADAS-opslag en de EDR tot stand te brengen bij het analyseren van de gebeurtenis.

Uitdagingen in bestaand ontwerp

Laten we het bestaande EDR-ontwerp onderzoeken en de uitdagingen begrijpen bij het aannemen van nieuwe regelgeving. Afbeelding 1 toont een typisch Airbag-bedienings- en EDR-ontwerp.

klik voor afbeelding op volledige grootte

Figuur 1:Typisch EDR-ontwerp. (Bron:Cypress Semiconductor)

De EDR/Airbag-controller bewaakt de plotselinge verandering in voertuigsnelheid en acceleratie om het begin van een gebeurtenis te identificeren. Zodra de gebeurtenis is gedetecteerd, verzamelt de EDR gegevens over meerdere prestatie- en veiligheidsparameters. Afhankelijk van het type en de ernst van de gebeurtenis besluit de EDR-controller om het record te loggen tijdens de gebeurtenis of na afloop van de gebeurtenis. Over het algemeen wordt aangenomen dat tijdens een crash de hoofdbatterij is uitgeschakeld en wordt de voeding naar de EDR-controller geleverd door een back-upcondensator. Het datalogboek wordt dus gevoed door de back-upcondensatoren.

Een diepere duik in de architectuur laat zien dat huidige EDR's ofwel EEPROM of data flash niet-vluchtig geheugen gebruiken om data op te slaan. Aangezien deze geheugens paginagebaseerde schrijfbewerkingen gebruiken en een laag uithoudingsvermogen hebben (minder dan 10 ⁶ schrijfcycli), reserveert de EDR-controller een RAM-buffer ter grootte van één EDR-record om de gegevens lokaal op te slaan. De RAM-buffer bevindt zich in de MCU met een grootte tussen 8 KB en 16 KB om gegevens tijdelijk te bufferen voordat ze naar niet-vluchtig geheugen worden geschreven. De bemonstering stopt doorgaans 250 ms nadat de gebeurtenis is geactiveerd. Daarna wordt de inhoud van de RAM-buffer overgebracht naar het niet-vluchtige geheugen. Vanwege de lage schrijfsnelheden van EEPROM en dataflash kan dit proces enkele honderden milliseconden tot een seconde duren om 16 KB aan gegevens op te slaan. Het hele proces wordt getoond in figuur 2.

klik voor afbeelding op volledige grootte

Figuur 2:Een typisch voorbeeld van EDR-datalogging met EEPROM / Data Flash. (Bron:Cypress Semiconductor)

De back-upcondensatoren moeten zo zijn ontworpen dat ze voldoende energie leveren om de hele overdracht van stroom te voorzien. De condensatoren worden ook gebruikt om de airbags van stroom te voorzien. De belangrijkste taak van de EDR-controller is natuurlijk het activeren van de airbag en het beschermen van de inzittenden. Daarom, in een situatie waarin er niet genoeg back-up energie is, zal het activeren van de airbag voorrang krijgen boven het loggen van gegevens in niet-vluchtig geheugen. Daarom brengt het vertrouwen op back-upcapaciteit om gegevens te loggen gegevens in gevaar. In het ergste geval kunnen back-upcondensatoren door de opening uit het bord springen tijdens ongevallen, waardoor de hele operatie in gevaar komt.

Een andere overweging, voor datalogging, zou het gebruik van EEPROM en niet-vluchtig dataflashgeheugen de complexiteit vergroten. Aangezien de gegevensoverdracht naar het niet-vluchtige geheugen plaatsvindt met behulp van back-upcondensatoren die mogelijk niet altijd stabiel zijn, moet de gegevensintegriteit van het schrijfproces worden gegarandeerd. De gemakkelijkste manier zou een controlesom zijn, maar het voegt tijd en complexiteit toe aan de firmware.

Nieuwe architectuur met F-RAM-geheugen

Het gebruik van F-RAM als extern niet-vluchtig geheugen zou een geheel andere datalogging-architectuur mogelijk maken. Het is misschien niet duidelijk uit het blokdiagram in figuur 3, omdat F-RAM gewoon een onderdeel op het bord zou vervangen. Maar het maakt de ontwikkeling mogelijk van een andere firmware-architectuur waarvan de voordelen gemakkelijk op systeemniveau te zien zijn.

klik voor afbeelding op volledige grootte

Figuur 3:EDR-ontwerp met F-RAM. (Bron:Cypress Semiconductor)

F-RAM-technologie zorgt voor snel schrijven met willekeurige toegang in combinatie met onmiddellijke niet-vluchtigheid en vrijwel oneindige duurzaamheid. Dit elimineert de noodzaak voor RAM-buffers in de microcontroller om het EDR-record tijdelijk vast te houden. EDR-firmware kan het geheugen in F-RAM's verdelen in meerdere EDR-records. Eén record zal altijd het werkgeheugen zijn, terwijl de rest leeg is of vergrendeld is met gebeurtenisgegevens. Gegevens kunnen continu in een werkend EDR-geheugen worden ingelogd in een rollende buffer.

Om de rollende bufferarchitectuur te begrijpen, laten we zeggen dat het werkende EDR-geheugen gegevens 10 seconden kan vasthouden. Als er binnen 10 seconden geen gebeurtenis plaatsvindt, worden de gegevens in het werkgeheugen overschreven met nieuwe gegevens. Dit is mogelijk dankzij het vrijwel oneindige uithoudingsvermogen van F-RAM. Dit betekent dat tijdens gebeurtenissen, wanneer de EDR-controller nog steeds de ernst van de gebeurtenis beoordeelt en beslissingen neemt om de gegevens al dan niet te loggen, de gegevens al zijn opgeslagen in niet-vluchtig F-RAM, zoals weergegeven in afbeelding 4.

klik voor afbeelding op volledige grootte

Afbeelding 4:Een typisch voorbeeld van EDR-gegevensregistratie met F-RAM. (Bron:Cypress Semiconductor)

Aan het einde van het evenement is de enige beslissing die de EDR-controller hoeft te nemen, of hij het logboek bewaart of overschrijft. Als de gebeurtenis ernstig genoeg is om het record te bewaren, zou de EDR-controller het werkgeheugen vergrendelen in een EDR-gebeurtenisrecord en een nieuwe buffer in F-RAM gebruiken als werkgeheugen in afwachting van de volgende gebeurtenis. De firmwarestroom wordt weergegeven in Afbeelding 5.

klik voor afbeelding op volledige grootte

Afbeelding 5:Een typische firmwarestroom voor EDR-gegevensregistratie met F-RAM. (Bron:Cypress Semiconductor)

Het andere voordeel is dat de EDR-gegevensopslag een afzonderlijke gebeurtenis is die niet afhankelijk is van back-upcondensatoren. Het EDR-systeem kan werken met kleinere condensatoren, terwijl de gegevensintegriteit niet in gevaar komt. De firmware-complexiteit in de microcontroller om geheugen en opslag te beheren wordt ook verminderd. Tabel 1 toont een vergelijking tussen twee architecturen.

klik voor afbeelding op volledige grootte

Tabel 1:EDR-architectuurvergelijking op basis van niet-vluchtig geheugen in gebruik. (Bron:Cypress Semiconductor)

Met verplichte regelgeving om EDR's te implementeren met een toenemende vraag naar datalogs, moet de mogelijkheid om gegevens te verliezen uit het ontwerp worden gehaald en moet een veiligere en betrouwbaardere architectuur voor een betere gegevensintegriteit worden omarmd. F-RAM-technologie is speciaal ontwikkeld voor bedrijfskritische toepassingen zoals EDR's. Op F-RAM gebaseerde architecturen zullen voldoen aan de hoge eisen van de volgende generatie EDR's die speciaal zijn gebouwd voor de meest geavanceerde automobieleisen.

Verwante inhoud:

• Het optimaliseren van niet-vluchtige datalogging voor IoT-sensornodes voor het oogsten van energie
• Het veranderende gezicht van autosoftware
• Betrouwbaarheid van niet-vluchtige geheugensystemen verbeteren
• NOR flash vindt steeds grotere rol in auto-ontwerpen
• Hoe een auto-SerDes-standaard innovatie zal helpen
• Amazon grijpt diep in de automobielsector
• Hoe slimmere opslag de betrouwbaarheid van autonome voertuigen verbetert

Abonneer u voor meer Embedded op de wekelijkse e-mailnieuwsbrief van Embedded.