Fagartikkel - innvevde systemer

Design av sikkerhetskritiske innvevde systemer

Praktiske utfordringer ved implementering av feildeteksjon i kjøretid for SRAM (Static Random-Access Memories) med bruk av sjakkbrettalgoritmer.

Publisert Sist oppdatert

Ved design av sikkerhetskritiske systemer er de internasjonale sikkerhetsstandardene viktige for at vi velger de riktige prosessene og tilpassede teknikker for å oppdage og unngå farlige feil i sluttproduktet. Standardene sikrer at vi ikke faller i de samme fallgrubene som andre sikkerhetsingeniører før oss har gjort.

Om forfatterne

Henrik Nyholm: Sikkerhetsprogramvareingeniør i PIC- og AVR applikasjonsgruppene, ansvarlig for utvikling av produkter og programvare for sikkerhetskritiske systemer rettet mot ISO 26262 og IEC 60730. 

LinkedIn: https://www.linkedin.com/in/henrik-nyholm-877a07224 

Jacob Lunn Lassen: Leder for teknisk forretningsutvikling innen sikkerhetskritiske systemer, ansvarlig for markedsstrategi og prosjekter rettet mot ISO 26262, IEC 61508 og IEC 60730 med Microchips PIC- og AVR mikrokontrollere.

LinkedIn: https://www.linkedin.com/in/jacob-lunn-lassen-560b0b3/

Faren med standarder

Faren med standardene er imidlertid at de antar at du har detaljert kunnskap om den underliggende maskinvaren, slik som en mikrokontroller, noe som kan få mindre erfarne sikkerhetsingeniører til å implementere usikre design. Som et eksempel anbefaler IEC (International Electrotechnical Commission) 60730-standarden bruk av en “sjakkbrett” type minnetest for å oppdage DC-feil i variable minner for klasse B-programvare, noe som er mer utfordrende enn det kan virke som.

Logisk vs fysisk

Denne artikkelen beskriver hvordan den udokumenterte forskjellen mellom den logiske og fysiske utformingen av SRAM kan føre til at vi utilsiktet implementerer minnetester, slik som sjakkbrettalgoritmen, feil. Den nødvendige informasjonen er vanligvis ikke tilgjengelig i dataarket til standard mikrokontrollere, men heldigvis finnes det minnetestalgoritmer som ikke påvirkes av forskjellen mellom den logiske og fysiske utformingen av SRAM.

Hvorfor teste SRAM for defekter under kjøring 

SRAM-minner er åpenbart testet i produksjon av leverandøren av ICen, og produkter med defekter sendes ikke til forbrukere. Likevel kan og vil tilfeldige maskinvaredefekter dukke opp i løpet av levetiden til komponenten, noe som er en av grunnene til at det er nødvendig å teste maskinvaren i en mikrokontroller under kjøring i sikkerhetskritiske applikasjoner.

Sjakkbrettbasert minnetest 

Sikkerhetsstandarder som IEC 60730 (H.2.19.6.1) foreslår at en sjakkbrett- algoritme kan brukes til å identifisere visse defekter (DC-feil) i SRAM for applikasjoner som må overholde klasse B sikkerhetsnivå. Sjakkbrettesten velges ofte fordi den dekker de mest sannsynlige feilene i en SRAM og er relativt rask, noe som er praktisk for å minimere ytelsespåvirkningen på selve applikasjonen. I tillegg til DC-feil, hvor en bit permanent sitter fast høy eller lav, kan sjakkbrettalgoritmen også oppdage defekter, der nabobits påvirker hverandre.

Figur 1 – Potentielle koblingsfeil mellom nabobits.

Virkning av fysisk defekt

En SRAM består logisk sett av et antall bits organisert i ord. Ordene er vanligvis 8-, 16- eller 32-bits lange, men kan også være lengre. Fysisk er bitene organisert i matriser, der hver bit typisk har åtte nabobiter (se figur 1). En fysisk defekt i en bit kan påvirke en enkelt bit slik at den sitter fast høyt eller lavt (DC-feil), eller defekten kan være i separasjonen av to bits, i så fall en nabo-aggressorcelle (merket med lilla i figur 1) kan påvirke en offercelle (merket med gult i figur 1). Aggressor- offer-scenariet blir ofte referert til som koblingsfeil. Statistisk sett er det mer sannsynlig at DC-feilen oppstår, men det er fortsatt relevant å oppdage de mest sannsynlige koblingsfeilene.

Vanskelig å avsløre

Dersom en feil påvirker en enkelt bit, slik at biten sitter fast høyt eller lavt, kan den avsløres ved å skrive verdien én, bekrefte verdien én ved å lese den tilbake, og deretter skrive verdien null og bekrefte null ved å lese den tilbake som illustrert i figur 1. Hvis på den annen side defekten er en koblingsfeil mellom to nabobits, for eksempel bitkolonne 9 og 10 i rad 2, vil ikke visse mønstre, slik som alle enere eller alle nuller, avsløre koblingsfeilen ettersom cellene har samme verdi under testen.

Et sjakkbrettmønster vil avsløre slike koblingsfeil, ettersom nabocellene (til sidene, over og under) har motsatte binære verdier. Figur 1 (nederst til høyre) illustrerer at éneren i bit 10 har forurenset bit 9, og koblingsfeilen er avslørt siden bit 9 ikke holder forventet verdi, null.

Fysisk vs logisk utforming av SRAM

For at sjakkbrettalgoritmen skal fungere, er det nødvendig å vite hvilke bits som er nabobits. Dette viser seg å være et problem ettersom databladene normalt bare beskriver den logiske utformingen av SRAM og ikke hvordan SRAM er fysisk organisert.

For å forstå den fysiske utformingen av SRAM, må man skille mellom bitorienterte minner (BOM), der én bit kan nås om gangen, og ord-orienterte minner (WOM) der et n-bits ord leses og skrives på en gang. Mens de fleste minner i den virkelige verden er implementert som WOM, antar de klassiske minnetestingsalgoritmene i vitenskapelig litteratur ofte BOM-implementeringer.

Figur 2 – Eksempler på fysisk layout av ord-orienterte minner.

Fysisk organisering

For WOM-minner er det tre hovedkategorier av fysisk organisering av bitsene som utgjør ordet: tilstøtende (adjacent), flettet (interleaved) og undermatriser (sub-arrays). Mens en logisk layout plasserer hvert ord under det forrige ordet i samme kolonne (tilsvarende adresseplass), plasserer de tilstøtende minnene hvert ord i samme rad ved siden av hverandre som vist i figur 2. Interleaved arkitekturer separerer hver bit av ordet inn i de forskjellige kolonnene og radene i SRAM-matrisen. Til slutt plasserer sub-array-organiseringen hver bit av et ord i forskjellige fysisk separate blokker av SRAM. Realiteten er at du ikke kjenner den fysiske layouten som kreves for å implementere en sjakkbrettest på riktig måte.

Egenskaper og mangler

Den antatt enkleste tilnærmingen for å implementere en sjakkbrettalgoritme er å vekselvis skrive verdien 0xAA (forutsatt 8-bits dataord) til den første adressen og 0x55 i den neste adressen inntil alle adressene som testes er fylt med sjakkbrettmønsteret med enere og nuller. Mønsteret blir deretter verifisert for å oppdage eventuelle DC- eller koblingsfeil mellom naboceller. Prosessen gjentas deretter ved å bruke det omvendte mønsteret. 

Som allerede angitt, er det en hake: Et sjakkbrettmønster i logisk layout av minnet er kanskje ikke et sjakkbrettmønster i den underliggende fysiske layouten, som vist i figur 3.

Figur 3 – Datamønstrene til logisk vs fysisk SRAM.

Manglende info – hva nå?

Det kan virke innlysende å kompensere for forskjellen mellom den logiske og fysiske layouten, men den nødvendige informasjonen er sjelden tilgjengelig i dataarket til enheten. Så hva gjør du? Godta den lavere nedre dekningen – tross alt vil diagnostikken fortsatt dekke DC-feil og noen koblingsfeil mellom nabobits? Be om oppsettet fra IC-leverandøren, og lage en tilpasset implementering av sjakkbrettesten for hver enhet? Eller velge en annen algoritme?

Nå som du er klar over den potensielle mangelen ved sjakkbrettesten, kan du ta en informert avgjørelse.

Alternative algoritmer for testing av SRAM under kjøring

Teknikkene for minnetest som er foreslått i IEC 60730 for klasse C-sikkerhetsnivå har høyere feildeteksjonsdekning, men disse er algoritmer som faller inn under det som kan betraktes som produksjonstestalgoritmer: De tar lengre tid å kjøre, oppdager også sjeldnere feiltyper, men vil typisk ødelegge dataene som er lagret i SRAM når de opererer på hele SRAM og ikke i underblokker. Generelt tolererer vi ikke dette særlig godt for vårt innvevde design. Vi foreslår derfor at du vurderer hybride Mars-algoritmer tilpasset fra March-algoritmen for produksjonstest: Disse algoritmene er tilgjengelige i WOM-optimaliserte implementeringer og gir høy testdekning. Videre kan disse hybride March-algoritmene implementeres slik at de kjører på mindre overlappende deler av SRAM, for å unngå å slette alle dataene i SRAM på en gang, noe som betyr at en omstart av det innvevde systemet kan unngås. Ulempen med March-algoritmene er at de er mer beregningstunge enn de tradisjonelle sjakkbrettalgoritmene, men det er en utgift som kan være nødvendig i sikkerhetskritiske systemer.

March-test

Dersom du vurderer å bytte en tradisjonell sjakkbrettest med en March-test, kan du finne en slik implementering fra enkelte mikrokontrollerleverandører. Microchip er et av selskapene som tilbyr ytelsesoptimalisert implementering av en March C-algoritme som en del av deres programvarediagnosebibliotek. Microchip-implementeringen støtter testing av hele SRAM, vanligvis utført ved oppstart kun for å få maksimal testdekning, og også testing av mindre minneblokker, ment å redusere sanntidspåvirkningen på applikasjonen. Implementeringen kan lastes ned gratis fra Microchips nettside som en del av IEC 60730 Class B-biblioteket. Implementeringen er for PIC® og AVR® mikrokontrollere, men kan porteres til andre Microchip MCUer.

For mer informasjon om IEC 60730 Klasse B tester: https://www.microchip.com/PIC-AVR-IEC60730

Powered by Labrador CMS