ISO 26262

ISO 26262  är en internationell standard för funktionell säkerhet för vägfordon. Standarden förbereddes för utgivning av den tekniska kommittén ISO / TC 22 / SC 32 "Elektriska, elektroniska komponenter och typer av system i allmänhet" från International Organization for Standardization och har hittills gått igenom 2 upplagor: den första - i november 2011 [ 1] och den andra - i december 2018 [2] .

Standardens fullständiga namn är "Road Vehicles - Functional Safety".

Standardens omfattning

Även om titeln på standarden anger att den täcker vägfordonens funktionella säkerhet, är dess omfattning i praktiken begränsad till elektriska och/eller elektroniska system relaterade till utförande av säkerhetsrelaterade funktioner och installerade på masstillverkade vägfordon. Exempel på sådana system är elektroniska dragkontrollsystem, högspänningsomriktare, elektroniska styr- och bromskontroller, relälogikkretsar.

Standarden gäller inte mopeder och unika system för specialfordon, såsom elektroniska stödsystem för funktionshindrade förare. Det är tillåtet att använda standarden i kombination med funktionssäkerhetsstandarder inom andra industriområden, vilket delvis täcks av standardens del 8.

Standardens struktur

Den senaste utgåvan av standarden består av 12 delar:

Kort översikt över vissa delar av standarden

Del 1 - Ordförråd

Den första delen av standarden introducerar termer och definitioner som aktivt används i framtiden. Standarden, tillsammans med lånevillkor från IEC 61508, har några mycket karakteristiska och på vissa ställen specifika för fordonsindustrins termer och begrepp, vars förståelse är avgörande för en bra läsning av följande kapitel.

Funktionell säkerhet  - frånvaron av en oacceptabel risknivå förknippad med faror orsakade av felaktigt funktionellt beteende hos elektroniska/elektriska system.

Begreppet funktionell säkerhet inom standarden upprepar idéerna i IEC 61508-standarden, som anses vara "moder"-standarden i förhållande till ISO 26262, det vill säga när den senare skapades var den till stor del baserad på den då existerande IEC 61508.

Del 2 - Funktionell säkerhetshantering

Den andra delen av standarden beskriver principerna för funktionssäkerhetsstyrning inom ett företag och inom ett projekt, både på utvecklingsstadiet och vid produktion, drift, underhåll och avveckling. En mer detaljerad beskrivning av rutinerna för att förbereda och genomföra en funktionssäkerhetsrevision, funktionssäkerhetsbedömning och bekräftande granskningar ges.

Diagrammet visar strukturen för del 2 av standarden. Konventionellt kan den delas in i 3 delar: projektoberoende och projektberoende delar av funktionell säkerhetsledning, samt funktionell säkerhetsledning under produktion, drift, underhåll och avveckling.

Den projektoberoende delen av funktionell säkerhetsledning syftar till att skapa och upprätthålla en säkerhetskultur, kvalitetsledningssystem, regler, processer, tillvägagångssätt för att säkerställa funktionssäkerhet, hantering av funktionssäkerhetsavvikelser och kompetensen hos specialister som är involverade i utvecklingen av enheter.

För att uppnå den funktionella säkerheten för de utvecklade enheterna är det nödvändigt att ha ett kvalitetsledningssystem (QMS) i organisationen , medan QMS kan byggas utifrån vilken standard som helst. Så ISO 9001 , IATF 16949 eller ASPICE kan användas som standard för ett QMS. Närvaron av ett QMS i en organisation säkerställer att de processer som beskrivs i ISO 26262 kommer att bygga på de befintliga processerna för utveckling av kvalitetsenheter och på så sätt uppnå deras funktionella säkerhet på rätt nivå av tillförlitlighet och kvalitet. I avsaknad av ett QMS är implementeringen av ISO 26262 i en organisation en osannolik och tidskrävande uppgift.

Den projektspecifika delen av funktionell säkerhetshantering tar upp många aspekter av utvecklingsprojektet för enheter i en organisation och omfattar utvecklingsplanering, granskning och förändringsregler, distribuerad utvecklingsledning, skapande av säkerhetsfall, funktionssäkerhetsrevisioner, funktionssäkerhetsbedömningar och bekräftande granskningar.

Säkerhetsplanering och samordning är nyckelaspekter i varje enhetsutvecklingsprojekt och ansvarar för den funktionella säkerhetschefen. Han har rätt att delegera vissa uppgifter till andra specialister med relevant kompetens, men förblir ansvarig för att sammanställa säkerhetsplanen, hålla den uppdaterad och uppdatera aktuell utvecklingsstatus. Det är viktigt att alla åtgärder som specificeras i planen kommuniceras till lämpliga ansvariga personer (ansvaret kan formaliseras i form av en RASIC-matris).

Ett säkerhetsfall ska tas fram i enlighet med säkerhetsplanen . Syftet med detta dokument är att visa att funktionssäkerhet har uppnåtts inom ramen för detta projekt. Utförandet av uppgiften utförs på grund av korrekt byggda säkerhetsargument, det vill säga förklaringar av "varför den här enheten kan anses vara funktionell säker." Varje argument består som regel av 4 nivåer: kärnan och 3 nivåer.

Tre metoder används för att validera säkerheten hos en enhet: bekräftande granskningar, funktionssäkerhetsrevisioner och funktionssäkerhetsbedömningar.

Bekräftelsegranskningar används i förhållande till enskilda resultat av arbetet/uppgifterna och är avsedda att bekräfta dessa resultats tillräcklighet och adekvathet när det gäller deras användning i framtiden vid bildandet av ett säkerhetsfall. Bekräftande granskningar är mellanliggande milstolpar i livscykeln för funktionell säkerhet för en enhet under utveckling och måste slutföras innan produktionen startar (liksom innan säkerhetsanalysen påbörjas). Varje bekräftande granskning kan utföras av en eller flera funktionssäkerhetsspecialister, under vilken den bekräftande granskningen kontrollerar korrektheten, fullständigheten, integriteten och tillräckligheten hos produkten/dokumentet som lämnats in för granskning. Bilaga C till del 2 av standarden ger vissa detaljer om de viktigaste detaljerna i den bekräftande granskningen.

En funktionssäkerhetsrevision undersöker om utvecklingsprocesserna för elektriska och/eller elektroniska system som är relevanta för utförandet av säkerhetsrelaterade funktioner överensstämmer med ISO 26262-standarden vad gäller de utvecklingsprocesser som beskrivs där. Rekommenderas för enheter med ASIL B bland säkerhetsmålen och obligatoriskt för enheter med ASIL C och ASIL D. Baserat på resultatet av revisionen ges rekommendationer för enhetsutvecklaren, inklusive rekommendationer för att eliminera eventuella inkonsekvenser.

Funktionssäkerhetsbedömningen kontrollerar fullständigheten och kvaliteten på säkerhetsfallet som skapats för enheten under utveckling. Förutom en revision rekommenderas en bedömning för enheter med ASIL B bland säkerhetsmålen och är obligatorisk för enheter med ASIL C och ASIL D. Strukturen för de parametrar som ska utvärderas för bedömning av funktionssäkerhet beskrivs i detalj i bilaga D, del 2 av standarden. Baserat på resultaten av bedömningen bildas en slutsats om uppnående, icke-uppnående eller villkorad uppnående av funktionell säkerhet av enheten. Vid en villkorad prestation anges tydligt under vilka förhållanden enheten anses vara funktionssäker. Vid slutsats om bristande prestation anges skälen och nödvändiga justeringar, varefter bedömningen upprepas.

Del 3 - Konceptstadiet

På konceptstadiet börjar den faktiska utvecklingen av enheten (artikeln), som är föremål för forskning/utveckling i ISO 26262. Enheter är elektriska och/eller elektroniska system relaterade till utförandet av säkerhetsrelaterade funktioner. En enhet är ett system eller en uppsättning system som ISO 26262-standarden gäller och som helt eller delvis implementerar ett fordons funktioner. Sådana funktioner kan till exempel inkludera fordonets rörelsefunktion, där beräkningen av vridmomentvärdet beroende på olika parametrar är en del av den och implementeras av traktionskontrollkontrollen, som i sin tur är en anordning.

För en fullständig förståelse av idén med enheten ges ett arkitektoniskt diagram över en del av fordonet med beteckningen av enheter på den, deras funktioner och funktionerna för fordonets rörelse och deras förhållande.

En beskrivning av en enhet, dess funktioner, relationer med andra enheter, preliminär arkitektur och egenskaper och andra aspekter som kan definieras i ett tidigt utvecklingsskede kallas en artikeldefinition. Enhetsdefinitionen är huvuddokumentet från vilket utvecklingen av alla enheter i enlighet med ISO 26262-standarden börjar.

Baserat på enhetsdefinitionen, och för att vara exakt, enhetsfunktionerna som specificeras i den, används den för att fastställa farliga händelser som kan bli resultatet av felaktig användning av enheten. För att göra detta genomförs en faroanalys och riskbedömning (faroanalys & riskbedömning), under vilken farorna med felaktigt apparatbeteende fastställs, de farliga händelser som följer efter dem (för vilka kritikalitetsnivån är satt) och säkerhetsmål är bestämda.

Betrakta, som ett exempel, dragkraftsregulatorn för en bil. En av funktionerna hos en sådan styrenhet kommer att vara beräkningen av vridmomentvärdet beroende på olika parametrar, såsom bilens hastighet och mängden tryck på gaspedalen. Denna funktion kanske inte fungerar korrekt, nämligen vid noll fordonshastighet och inget tryck på gaspedalen kan ett ofrivilligt vridmoment genereras. Detta beteende hos styrenheten för traktionskontroll är felaktigt funktionellt beteende . När ett sådant felaktigt funktionellt beteende uppstår uppstår en fara  - oavsiktlig acceleration och denna fara, i kombination med olika driftsförhållanden och miljöer, till exempel att fordonet står stilla i en fotgängarzon, kan leda till farliga händelser (ibland kallade riskfaktorer) ). En sådan farlig händelse kan vara allvarliga skador på fotgängare på grund av en frontalkrock av ett fordon med dem. För en sådan farlig händelse uppskattas omfattningen av svårighetsgraden av denna farliga händelse, kallad risk. Denna risknivå i standarden ställs in med hjälp av bilsäkerhetsintegritetsnivån (ASIL) , som beräknas från riskmatrisen som ges i standarden baserat på en analys av möjligheten till en farlig händelse, svårighetsgraden av dess konsekvenser och sannolikheten av dess undvikande på grund av förarens eller andra trafikanters handlingar. Denna nivå sträcker sig från ASIL A till ASIL D, där den senare anses vara den högsta.

Om storleken på risken är acceptabel (QM-nivå) inom ramen för projektet, anses det att systemets funktionssäkerhet är säkerställd i förhållande till denna farliga händelse. Om inte (ASIL A till ASIL D), krävs ytterligare utveckling av den farliga händelsen för att fastställa säkerhetsmekanismerna för att minska storleken på risken till en acceptabel nivå och säkerställa funktionell säkerhet.

Det första steget efter faroanalysen och riskbedömningen är utformningen av säkerhetsmål . Trots namnet är säkerhetsmål höga säkerhetskrav som säkerställer att enheten i fråga är säker. Säkerhetsmålen är definierade baserat på en analys av alla farliga situationer som enhetens felaktiga funktionella beteende kan skapa, och är ganska ofta (men inte alltid) uttalanden som är motsatta till de faror som genererar farliga händelser. I exemplet ovan var faran "oavsiktlig acceleration", så säkerhetsmålet kan vara "fordonet får inte accelerera oavsiktligt".

När alla säkerhetsmål har genererats, analyseras vart och ett av målen enligt enhetens primära arkitektur för vad som kan orsaka ett brott mot det säkerhetsmålet. Alla deduktiva analyser, såsom felträdsanalys, STPA eller HAZOP, är utmärkt för detta.

Baserat på resultaten av att fastställa orsakerna till överträdelsen av säkerhetsmålet skapas en strategi för att rapportera fel och minska funktionaliteten. Denna strategi (vanligtvis i grafisk form) visar exakt vad som behöver göras för att upptäcka fel som leder till ett brott mot säkerhetsmålet, och för att meddela andra enheter och föraren om detta. Policyn beskriver också de säkra tillstånden för enheten och fordonet som övergår till för att förhindra att säkerhetsmålen bryts. Denna strategi ligger till grund för bildandet av funktionssäkerhetskrav . Dessa krav svarar på frågan "vad behöver göras för att förhindra brott mot säkerhetsmålen?", eller, givet exemplet vi överväger, "vad behöver göras för att fordonet inte ska accelerera oavsiktligt?".

Ett exempel på ett säkerhetsfunktionskrav skulle vara: "All oavsiktlig acceleration av fordonet över 0,3 g under mer än 100 ms orsakad av dragkraftsregulatorn måste upptäckas och förhindras." Med mindre värden på acceleration eller varaktighet av dess förekomst kan vi anta att säkerhetsmålet inte överträds, eftersom risken inte är särskilt stor (förmodligen kommer det att finnas en låg svårighetsgrad av skadan, vilket kommer att leda till en låg nivå av ASIL).

Säkerhetsfunktionskraven ärver ASIL-säkerhetsmålnivån, som härleder den från resultaten av riskbedömningen. Det är viktigt att förstå att det är kraven som avgör vad som behöver göras för att säkerställa säkerheten, och ASIL-nivån bestämmer bara uppsättningen av metoder som används i framtiden när man utvecklar en enhet. Ju högre ASIL-nivå, desto mer krävande är utvecklingen när det gäller att utföra olika analys-, verifierings- och valideringsarbeten. Som ett exempel, ta tabell 1, presenterad i del 4 av standarden, med möjliga metoder för att analysera tillförlitligheten och säkerheten hos en systemarkitektur på hög nivå.

Systemarkitekturanalys
Metoder ASIL
A B C D
ett Deduktiv analys handla om + ++ ++
2 Induktiv analys ++ ++ ++ ++

o - för denna metod finns det inget krav på att det är obligatoriskt eller valfritt;

+ — användning av denna metod rekommenderas

++ - denna metod rekommenderas starkt

Tabellen visar att på olika nivåer av ASIL används olika tillvägagångssätt och deras kombinationer för att analysera systemets arkitektur. När det gäller deduktiv analys, såsom felträdsanalys, rekommenderas således användningen av denna metod starkt endast vid ASIL C och ASIL D, till skillnad från induktiv analys, säg felläges- och effektanalys, som starkt rekommenderas för alla ASIL värde.

Bildandet av en lista över funktionella säkerhetskrav fullbordar konceptstadiet. Dessa krav, i kombination med de grundläggande kraven för enheten, beaktas i den vidare ingående studien av enheten, dess arkitektur, mjukvara och hårdvara.

Del 4 - Systemnivåutveckling

Den första hälften av denna del av standarden ägnas åt enhetsutveckling på systemnivå ur en arkitektonisk synvinkel.

Resultatet från konceptstadiet i form av en uppsättning säkerhetsfunktionskrav är den viktigaste ingången för att starta enhetsutveckling på systemnivå. Systemet i det här fallet är själva enheten, betraktad som en "svart låda". För varje funktionssäkerhetskrav genereras ett eller flera tekniska säkerhetskrav . Dessa krav, i enlighet med säkerhetsfunktionskravexemplet som använts ovan, svarar på frågan ”hur ska kraven i konceptstadiet implementeras så att fordonet inte accelererar oavsiktligt?”.

Svaret kan vara:

  1. På sidan av styrenheten för dragkraft bör en mekanism installeras för att kontrollera rimligheten av förarens signal för dragkraftsbegäran (signal från gaspedalen), implementerad genom att jämföra två styrsignaler som går längs två linjer från pedalen till styrenheten.
  2. Om signalerna inte överensstämmer med varandra återställer styrenheten på ett hanterbart sätt dragbegäran från föraren inom 50 ms.
  3. På sidan av traktionskontrollkontrollen bör rimligheten för värdet av det erforderliga vridmomentet som beräknats av mikrokontrollern kontrolleras och, vid nollbegäran, bör regulatorn inte spontant skapa en extern vridmomentbegäran.
  4. Utsignalen för vridmomentbegäran till högspänningsomriktaren måste skickas till den via två redundanta dataledningar.

Detta är bara några av de säkerhetstekniska krav som kan härledas från det säkerhetsfunktionskrav som beskrivs ovan. Utöver dem kan krav från olika standarder eller lagstiftningsdokument komma, som förklarar de särskilda kraven för skyddsåtgärder på sidan av enheten som utvecklas (t.ex. kravet på åtgärder för att absorbera överskottseffekt på högspänningsapparater följer av UN ECE Regel 100, men får inte följa direkt av något säkerhetsfunktionskrav). Kraven bör fördelas mellan mjukvaran och hårdvaran i systemet.

Baserat på en uppsättning tekniska säkerhetskrav bildas en beskrivning av säkerhetsmekanismer , som kommer att bli en del av den befintliga systemarkitekturen efter deras detaljerade studie. Men även en sådan modifierad arkitektur kanske inte är tillräckligt säker. För att verifiera säkerheten för en ny enhetsarkitektur med skyddande säkerhetsmekanismer i dess sammansättning, utförs ytterligare en induktiv eller deduktiv analys. Baserat på resultaten av en sådan analys, säger FMEA, kan det vara nödvändigt att förbättra eller komplettera de föreslagna skyddsmekanismerna för att fullt ut uppnå uppfyllandet av funktionssäkerhetskraven.

Skyddande säkerhetsmekanismer är indelade i 3 kategorier - säkerhetsmekanismer, detektionsmekanismer och begränsningsmekanismer. De förstnämnda används för att helt förhindra uppkomsten av fel som kan leda till faror och farliga händelser, medan de andra, i samverkan, gör det möjligt att upptäcka förekomsten av sådana fel och minska deras konsekvenser så att risknivån förblir acceptabel. Exempel på säkerhetsmekanismer är redundans, detektionsmekanismer är periodiska automatiska tester och begränsningsmekanismer är algoritmer för att undertrycka spontant vridmoment. Säkerhetsmekanismer gör det faktiskt möjligt att hantera slumpmässiga och systematiska hårdvarufel och med systematiska mjukvarufel, såväl som deras konsekvenser.

Varje skyddsmekanism måste vara utrustad med hjälp av dess diagnostik för att undvika en situation där dess fel förblir obemärkt och i själva verket kan huvudfelet, mot vilket denna skyddsmekanism installerades, uppstå utan hinder.

För att tydligt skilja ansvaret för att implementera säkerhetsspecifikationer och säkerhetsskyddsmekanismer mellan hårdvaran och mjukvaran för en enhet, används ett formellt dokument som kallas en hårdvaru-programvarugränssnittsspecifikation. En sådan specifikation fångar alla informationsflöden mellan programvara och AO, särskilt de som hänför sig till driften av säkerhetsskyddsmekanismer. Detta dokument är viktigt i framtiden, eftersom det är med hänsyn till det som mjukvaru- och hårdvaruintegrationen av systemet och dess drift som helhet kommer att testas.

Utöver de tekniska säkerhetskraven är det viktigt att formulera den allmänna idén om kraven för produktion, drift, underhåll och avveckling av enheten, eftersom dessa krav kan påverka implementeringen av skyddande säkerhetsmekanismer. Till exempel, om du behöver stödja snabb återställning av enheter i ett fordon, kan användningen av säkringar avsevärt komplicera detta krav.

Den andra hälften av denna del ägnas åt att testa integrationen av systemet i en enda helhet och i fordonet, samt att testa det för överensstämmelse med olika krav (inklusive säkerhetskrav).

Standarden föreslår en sådan teststruktur, där till en början färdig mjukvara och hårdvara används och deras integration testas, det vill säga montering i ett enda system - en enhet. Därefter testas den framgångsrika driften av denna enhet och dess integration i ett större system eller fordon. I det här fallet, ur funktionssäkerhetssynpunkt, kontrolleras först den korrekta driften av alla skyddande säkerhetsmekanismer genom artificiell introduktion av fel och sedan enhetens överensstämmelse med de presenterade tekniska och funktionella säkerhetskraven. På nivån för hela fordonet verifieras att enheten, i händelse av ett fel, inte kommer att bryta mot de säkerhetsmål som tidigare identifierats för den (säkerhetsvalidering)

Integrations- och kvalifikationstestning av enheten på alla nivåer kan utföras i olika miljöer:

Del 5 - Utveckling på hårdvarunivå

Denna del av standarden tar upp kraven på funktionssäkerhet på hårdvarunivå. Baserat på analysen av de skyddsmekanismer som behöver implementeras och de tekniska kraven för funktionell säkerhet är det nödvändigt att bestämma exakt vad och hur som behöver göras på nivån för enhetens hårdvarukomponent för att säkerställa korrekt säkerhetsnivån i allmänhet.

Krav på funktionell säkerhet på hårdvarunivå innehåller som regel detaljerade parametrar som är nödvändiga för implementering av skyddande säkerhetsmekanismer, såsom tidsgränser för drift av vakthundar, frekvensen av minnesintegritetskontroller etc. Alla dessa krav tas med i beräkningen ta hänsyn till utvecklingsstadiet för den elektriska kretsstyrenheten, och när du utvecklar kortets topologi och när du väljer en komponentbas. Eftersom systematiska fel kan uppstå på hårdvarunivå, såväl som under utvecklingen av systemarkitekturen, kräver hårdvaran också ytterligare induktiv eller deduktiv analys, vilket kommer att avslöja sårbarheter i den föreslagna styrenhetens hårdvaruarkitektur som kan leda till brott mot säkerhetsmål vid nivån hela systemet.

Sådana sårbarheter kallas misslyckanden, och vissa av dem kan leda till brott mot säkerhetsmål. Ett enstaka fel är ett fel som inte täcks av en säkerhetsskyddsmekanism som direkt leder till ett brott mot ett säkerhetsmål. Ett dubbelt misslyckande  är ett misslyckande som, i kombination med ett annat självständigt misslyckande, resulterar i ett brott mot ett säkerhetsmål. En generaliserad version av dubbelfel är multipelfel, men flera fel på nivå 3 och högre anses vara osannolika och därför säkra enligt ISO 26262. Ett latent fel  är ett multipelfel, vars närvaro inte detekteras av säkerhetsskyddsmekanismen och inte uppfattas av föraren. Det antas att vid tillämpning av olika säkerhetsskyddsmekanismer kvarstår så kallade restfel , det vill säga fel som inte omfattas av säkerhetsskyddsmekanismerna och leder till brott mot säkerhetsmålen. För olika ASIL bör dock andelen kvarvarande fel inte överstiga det värde som anges i standarden.

Relaterat till dessa aspekter är det faktum att hårdvaran kräver beräkning av mått som visar en acceptabel nivå av systematiska och slumpmässiga fel. Tabellerna 4, 5 och 6 visar målvärdena för slumpmässiga felmätningar.

Tabell med målvärden för slumpmässiga felmätningar
ASIL A ASIL B ASIL C ASIL D
Mätvärde för enstaka och återstående misslyckanden - ≥ 90 % ≥ 97 % ≥ 99 %
Latent dubbelfelmått - ≥ 60 % ≥ 80 % ≥ 90 %
Sannolikhet att bryta ett säkerhetsmål på grund av slumpmässiga fel - < 1/h < 1/h < 1/h

Uttrycket för måtten för enstaka och återstående fel (SPF):

var  är felfrekvensen för enstaka fel;

 — Felfrekvens för kvarvarande fel.

 — Felfrekvens för alla fel.

 — Felfrekvens för säkra fel.

 — Felfrekvens för dubbla fel.

Uttrycket för värdet för dubbelt latent fel (LF) är:

var  är felfrekvensen för dubbla latenta fel;

 — Felfrekvens för dubbla detekterbara fel.

 — Felfrekvens för dubbla fel som uppfattas av föraren.

Vid beräkning av sannolikheten för överträdelse av säkerhetsmålet på grund av slumpmässiga misslyckanden (PMHF) tas hänsyn till den totala frekvensen av alla fel som på något sätt kan leda till överträdelse av säkerhetsmålet (sådana fel inkluderar alla farliga fel). PMHF-värdet kan grovt beräknas med följande formel:

,

där  - fordonets livslängd, i praktiken tas den lika med från 15 till 20 år.

Att utföra hårdvaruarkitekturen och uppfylla metriska mål är bara en del av jobbet med att säkerställa en enhets funktionella säkerhet. Dessutom krävs en hårdvarutestcykel, som villkorligt kan delas upp i 2 komponenter:

  1. Tester som syftar till att verifiera riktigheten och fullständigheten av uppfyllandet av hårdvarukraven för funktionell säkerhet:
    • elektrisk testning av skyddande säkerhetsmekanismer;
    • funktionstestning av säkerhetsskyddsmekanismer;
    • tester med konstgjord introduktion av fel;
  2. Tester som syftar till att kontrollera hårdvarans tillförlitlighet och motståndskraft mot miljöpåverkan och ökade belastningar:
    • tester för påverkan av miljöfaktorer (klimattest);
    • utökad funktionstestning;
    • statistiskt test;
    • tester under ökad arbetsbelastning;
    • destruktiva tester vid superkritiska driftlägen;
    • statiska mekaniska tester (böjning);
    • dynamiska mekaniska tester (vibrationer);
    • påtvingade (accelererade) tester;
    • kemikaliebeständighet och säkerhetstester;
    • EMC- och ESD-tester.

Testresultat är tillsammans med metriska beräkningar argument för implementering av funktionssäkerhetskrav för hårdvara och är en av komponenterna i säkerhetsmotiveringen.

Del 6 - Utveckling på mjukvarunivå

Denna del av standarden tar upp kraven på funktionssäkerhet på mjukvarunivå. Baserat på analysen av de skyddsmekanismer som kräver implementering och de tekniska kraven för funktionell säkerhet, är det nödvändigt att bestämma vad exakt och hur man ska göra på nivån för enhetens mjukvarukomponent för att säkerställa rätt säkerhetsnivå i allmän.

Funktionssäkerhetskrav på mjukvarunivå innehåller som regel en detaljerad beskrivning av algoritmerna för driften av skyddsmekanismer, vilken logik som ska användas för att trigga skyddsmekanismerna och vilka tillåtna mängder datorkraft som måste iakttas. Alla dessa krav beaktas vid utvecklingen av mjukvaruarkitektur. Eftersom systematiska fel kan uppstå på mjukvarunivå, såväl som på hårdvarunivå och vid utveckling av arkitekturen för hela systemet, kräver mjukvarudelen också ytterligare induktiv eller deduktiv analys, vilket gör det möjligt att identifiera sårbarheter i den föreslagna mjukvaruarkitekturen för styrenheten som kan leda till brott mot säkerhetsmål på hela systemets nivå.

Samtidigt görs vanligtvis en sådan analys för varje mjukvarukomponent för sig: analys för applikationsprogramvara, analys för systemprogramvara, analys för operativsystemet eller lågnivåprogramvara etc. Syftet med analysen är också att lyfta fram beroende fel på moduler Programvara när fel i en funktion resulterar i kaskadfel i alla beroende funktioner. Detta är särskilt viktigt när man använder programvarumoduler med olika ASIL-nivåer i sina krav.

Viktig uppmärksamhet i mjukvaruutveckling ägnas åt användningen av ett programmeringsspråk och kodningsregler. För det första rekommenderar standarden användning av endast de språk som uppfyller ett antal kriterier, såsom stöd för stark och statisk typning . Dessutom följer endast från detta krav den praktiska omöjligheten att använda vissa programmeringsspråk som Python . När det gäller programmeringsregler på olika språk finns det många olika riktlinjer och normativa dokument som reglerar reglerna för att skriva kod på ett visst programmeringsspråk när man utvecklar enheter relaterade till säkerhet. Ett exempel på sådana riktlinjer är MISRA-regeldokumentserien för C och C++ .

I likhet med systemutveckling kräver mjukvaruutveckling också mjukvaruverifiering och validering på olika nivåer. Så för traktionskontrollern kommer detta att vara testning på enhetsnivå, på nivån för mjukvarumoduler (sammansättning av enheter), på nivån för mjukvarulager och på nivån för hela den fasta programvaran. I varje steg utförs en statisk analys av koden, en kontroll av frånvaron av körtidsfel, en kontroll av hur algoritmer för skyddsmekanismer fungerar och mycket mer. Samtidigt genomförs både integrations- och kvalifikationsprövningar i olika miljöer:

En viktig roll i testning spelas av insamlingen av testtäckning för att underbygga täckningen av hela utbudet av mjukvarufunktionalitet genom tester.

Förhållande till andra standarder

ISO 26262-standarden är en av de yngsta och mest strukturerade funktionssäkerhetsstandarderna för tillfället, eftersom den erbjuder många exempel i en imponerande volym och har en struktur som liknar den för den klassiska V-modellen. Denna standard täcker dock endast det felaktiga beteendet hos funktionerna hos enheterna som är under utveckling och erbjuder ett tillvägagångssätt för att parera dem.

Med utvecklingen av teknologier inom området för obemannade fordon blev det tydligt att förutom de klassiska felaktiga funktionella beteendena kan vissa enheter också ha ett ganska korrekt beteende i en viss situation, vilket ändå är oönskat ur fordonets synvinkel eller förare. Ett exempel på detta är en kamera som fångar och känner igen föremål på vägen. Med felaktig igenkänning kan en sådan kamera leda det obemannade fordonet som den är installerad på att fatta felaktiga men tekniskt korrekta beslut, vilket i sin tur kan leda till en olycka.

För att hantera sådana fall släppte ISO standarden ISO/PAS 21448 [3] 2019 , som relativt enkelt integreras med ISO 26262 och täcker tidigare problematiska områden relaterade till säkerheten för objektiva funktioner.

Dessutom är standarden ISO 21434 också under utveckling, som, med en struktur som liknar ISO 26262, kommer att behöva innehålla metoder för att säkerställa informationssäkerheten för fordon.

Anteckningar

  1. ↑ ISO 26262-1:  2011 . ISO (11/01/2011). Tillträdesdatum: 20 april 2020.
  2. ↑ ISO 26262-1:  2018 . ISO (12/01/2018). Tillträdesdatum: 20 april 2020.
  3. ↑ ISO/PAS 21448:2019  (engelska) . ISO . Tillträdesdatum: 28 juni 2020.

Litteratur