ISO 26262

ISO 26262 on kansainvälinen standardi maantieajoneuvojen toiminnallisesta turvallisuudesta. Standardin valmisteli julkaistavaksi Kansainvälisen standardointijärjestön tekninen komitea ISO / TC 22 / SC 32 "Sähköiset, elektroniset komponentit ja järjestelmätyypit yleensä" , ja se on tähän mennessä käynyt läpi 2 painosta: ensimmäinen - marraskuussa 2011 [ 1] ja toinen - joulukuussa 2018 [2] .

Standardin koko nimi on "Road Vehicles - Functional Safety".

Standardin soveltamisala

Vaikka standardin otsikko osoittaa, että se kattaa maantieajoneuvojen toiminnallisen turvallisuuden, käytännössä sen soveltamisala rajoittuu turvallisuuteen liittyvien toimintojen suorittamiseen liittyviin sähköisiin ja/tai elektronisiin järjestelmiin, jotka on asennettu sarjatuotantoon valmistettuihin maantieajoneuvoihin. Esimerkkejä tällaisista järjestelmistä ovat elektroniset luistonestojärjestelmät, suurjänniteinvertterit, elektroniset ohjaus- ja jarrusäätimet, relelogiikkapiirit.

Standardi ei koske mopoja ja erikoisajoneuvojen ainutlaatuisia järjestelmiä, kuten vammaisten kuljettajien sähköisiä tukijärjestelmiä. Standardia saa käyttää yhdessä muiden teollisuusalueiden toiminnallisten turvallisuusstandardien kanssa, mikä on osittain katettu standardin osassa 8.

Standardin rakenne

Standardin uusin painos koostuu 12 osasta:

Osa 1 - Sanakirja. Sisältää termejä, määritelmiä, lyhenteitä ja kuvauksia tärkeimmistä ajatuksista ja käsitteistä, joita käytetään standardin kaikissa osissa.
Osa 2 - Toiminnallinen turvallisuusjohtaminen. Se sisältää kuvauksen toiminnallisen turvallisuusjohtamisen periaatteista yrityksessä ja projektin puitteissa sekä päävaiheet, joilla varmistetaan kehitettyjen järjestelmien toiminnallisen turvallisuuden vaatimustenmukaisuus.
Osa 3 - Konseptivaihe. Kuvaa vaiheet, jotka ovat tarpeen tutkittavan/kehitettävän järjestelmän kuvaamiseksi, sen aiheuttamien vaarojen tunnistamiseksi, kyseisten vaarojen riskien arvioimiseksi sekä turvallisuustavoitteiden ja turvallisuustoiminnallisten vaatimusten tunnistamiseksi.
Osa 4 - Kehitys järjestelmätasolla. Tässä osassa kuvataan tutkittavan tai kehitettävän järjestelmän arkkitehtuurille asetettavia vaatimuksia ottaen huomioon turvallisuuden, sen todentamisen ja validoinnin tekniset vaatimukset.
Osa 5 - Kehitys laitteistotasolla. Määrittää prosessit laitteistovaatimusten tunnistamiseksi tutkittavan/kehitettävän järjestelmän turvallisuuden kannalta, säännöt järjestelmälaitteiston arkkitehtuurin kehittämiseksi ottaen huomioon nämä vaatimukset, menetelmät sen todentamiseksi ja validoimiseksi.
Osa 6 - Kehitys ohjelmistotasolla. Määrittää prosessit ohjelmistovaatimusten tunnistamiseksi tutkittavan/kehitettävän järjestelmän turvallisuuden kannalta, säännöt järjestelmäohjelmiston arkkitehtuurin kehittämiselle nämä vaatimukset huomioon ottaen, menetelmät sen varmentamiseksi ja validoimiseksi.
Osa 7 - Tuotanto, käyttö, huolto ja käytöstä poistaminen. Kattaa menetelmät toiminnallisen turvallisuuden varmistamiseksi tutkittavan/kehitettävän järjestelmän elinkaaren vaiheissa sen kehityksen päättymisen jälkeisellä kaudella.
Osa 8 - Tukiprosessit. Se kattaa toimittajien kanssa työskentelyn ja yhteistyön prosessit, dokumentoinnin, muutosten kirjanpidon, konfiguroinnin, vaatimusten määrittelyn, valmiiden ohjelmistojen ja/tai laitteistojen varmentamisen, pätevöinnin ja käytön projekteissa sekä sellaisten järjestelmien käyttämisen projektissa, jotka eivät täytä toimittajien vaatimuksia. standardin ja standardin vaatimusten yhdistäminen muiden standardien vaatimuksiin toimintaturvallisuuden mukaisesti.
Osa 9 - Turvallisuuden ja autojen turvallisuuden eheystasojen analyysi ( ASIL - Automotive Safety Integrity Level). Tämä osa sisältää kuvauksen lähestymistavoista ASIL:n hajoamiseen, kriteerien määrittelyn erityyppisten komponenttien yhteiskäytölle järjestelmissä, riippuvien vikojen ja turvallisuuden analysoinnin.
Osa 10 - Ohjeet ISO 26262:lle. Sisältää tärkeitä esimerkkejä standardin osissa 2-9 käsiteltyjen vaatimusten soveltamisesta.
Osa 11 - Ohjeet ISO 26262:n soveltamiseen puolijohdesuunnittelussa. Määrittelee tärkeimmät ideat ja käsitteet standardin soveltamiseksi puolijohdekomponentteihin, kuten mikro-ohjaimiin tai integroituihin piireihin, mukaan lukien niiden turvallisuusanalyysi, vian ruiskutustestaus, vikamallin määrittely jne.
Osa 12 – ISO 26262:n mukauttaminen moottoripyöräsovelluksiin. Viimeisessä osassa kuvataan moottoripyöriä koskevan standardin soveltamisen piirteitä.

Lyhyt katsaus joihinkin standardin osiin

Osa 1 - Sanasto

Standardin ensimmäinen osa esittelee termejä ja määritelmiä, joita käytetään aktiivisesti tulevaisuudessa. Standardissa ja IEC 61508:sta lainattujen termien ohella on joitain erittäin tunnusomaisia ja paikoin autoteollisuudelle ominaisia termejä ja käsitteitä, joiden ymmärtäminen on ratkaisevan tärkeää seuraavien lukujen hyvän lukemisen kannalta.

Toiminnallinen turvallisuus - ei ole hyväksyttävää riskitasoa, joka liittyy vaaroihin, jotka johtuvat elektronisten / sähköjärjestelmien virheellisestä toiminnallisesta käyttäytymisestä.

Standardin toiminnallisen turvallisuuden käsite toistaa IEC 61508 -standardin ajatuksia, joita pidetään "äiti"-standardina suhteessa ISO 26262:een, eli kun jälkimmäinen luotiin, se perustui suurelta osin silloin olemassa olevaan IEC:hen. 61508.

Osa 2 - Toiminnallinen turvallisuusjohtaminen

Standardin toisessa osassa kuvataan toiminnallisen turvallisuusjohtamisen periaatteet yrityksen sisällä ja projektin sisällä sekä kehitysvaiheessa että tuotannon, käytön, kunnossapidon ja käytöstäpoiston vaiheissa. Toiminnallisen turvallisuusauditon, toimintaturvallisuusarvioinnin ja vahvistusarvioinnin valmistelun ja suorittamisen menettelyistä on kuvattu tarkemmin.

Kaaviossa on esitetty standardin osan 2 rakenne. Perinteisesti se voidaan jakaa 3 osaan: toiminnallisen turvallisuusjohtamisen projektiriippuvainen ja projektiriippuvainen osa sekä toiminnallinen turvallisuusjohtaminen tuotannon, käytön, huollon ja käytöstäpoiston aikana.

Toiminnallisen turvallisuuden johtamisen projektiriippumaton osa tähtää turvallisuuskulttuurin, laadunhallintajärjestelmän, sääntöjen, prosessien, toimintatapojen toiminnan turvallisuuden varmistamiseen, toiminnallisen turvallisuuden eroavaisuuksien hallintaan ja laitekehitykseen osallistuvien asiantuntijoiden osaamisen luomiseen ja ylläpitämiseen.

Kehitettyjen laitteiden toiminnallisen turvallisuuden saavuttamiseksi organisaatiossa on oltava laadunhallintajärjestelmä (QMS) , kun taas QMS voidaan rakentaa minkä tahansa standardin pohjalta. Joten ISO 9001 , IATF 16949 tai ASPICE voidaan käyttää laadunhallintajärjestelmän standardina. Laadunhallintajärjestelmän läsnäolo organisaatiossa varmistaa, että ISO 26262:ssa kuvatut prosessit rakentuvat olemassa olevien prosessien päälle laadukkaiden laitteiden kehittämiseksi ja saavuttavat siten niiden toiminnallisen turvallisuuden oikealla luotettavuus- ja laatutasolla. Laadunhallintajärjestelmän puuttuessa ISO 26262:n käyttöönotto organisaatiossa on epätodennäköinen ja aikaa vievä tehtävä.

Toimintaturvallisuuden hallinnan projektikohtainen osa käsittelee monia organisaation laitekehitysprojektin näkökohtia ja kattaa kehityssuunnittelun, tarkastus- ja muutossäännöt, hajautetun kehityshallinnan, turvallisuusperustelun luomisen, toimintaturvallisuusauditoinnit, toimintaturvallisuusarvioinnit ja vahvistusarvioinnit.

Turvallisuussuunnittelu ja koordinointi ovat keskeisiä osa-alueita kaikissa laitekehitysprojekteissa ja ovat toiminnallisen turvallisuuspäällikön vastuulla. Hänellä on oikeus siirtää joitakin tehtäviä muille asiaankuuluvan pätevyyden omaaville asiantuntijoille, mutta hän on edelleen vastuussa turvallisuussuunnitelman laatimisesta, ajan tasalla pitämisestä ja nykyisen kehitystilanteen päivittämisestä. On tärkeää, että kaikki suunnitelmassa määritellyt toimet välitetään asianmukaisille vastuuhenkilöille (vastuu voidaan muotoilla RASIC-matriisin muodossa).

Turvallisuusperustelu on laadittava turvallisuussuunnitelman mukaisesti . Tämän asiakirjan tarkoituksena on osoittaa, että toiminnallinen turvallisuus on saavutettu tämän projektin puitteissa. Tehtävän suorittaminen tapahtuu oikein rakennettujen suojausargumenttien, eli selitysten "miksi tätä laitetta voidaan pitää toiminnallisesti turvallisena". Jokainen argumentti koostuu pääsääntöisesti 4 tasosta: ydin ja 3 tasoa.

Laitteen turvallisuuden validoinnissa käytetään kolmea lähestymistapaa: varmistusarvioinnit, toimintaturvallisuusauditoinnit ja toimintaturvallisuusarvioinnit.

Vahvistuskatsauksia käytetään yksittäisten työn/tehtävien tulosten yhteydessä ja niiden tarkoituksena on vahvistaa näiden tulosten riittävyys ja riittävyys niiden käytön kannalta tulevaisuudessa turvallisuusperustelun muodostamisessa. Vahvistustarkastukset ovat välivaiheita kehitettävän laitteen toiminnallisen turvallisuuden elinkaaressa, ja ne on saatava päätökseen ennen tuotannon aloittamista (samoin kuin turvallisuusarvioinnin alkamista). Jokaisen varmistustarkastuksen voi suorittaa yksi tai useampi toimintaturvallisuusasiantuntija, jonka aikana vahvistustarkastelussa tarkistetaan tarkastettavaksi jätetyn tuotteen/asiakirjan oikeellisuus, täydellisyys, eheys ja riittävyys. Standardin osan 2 liitteessä C on joitain yksityiskohtia vahvistustarkistusprosessin tärkeimmistä yksityiskohdista.

Toimintaturvallisuusauditoinnilla selvitetään, ovatko turvallisuuteen liittyvien toimintojen suorittamisen kannalta merkitykselliset sähkö- ja/tai elektroniikkajärjestelmien kehitysprosessit ISO 26262 -standardin mukaisia siinä kuvattujen kehitysprosessien osalta. Suositellaan laitteille, joissa ASIL B on tietoturvatavoitteiden joukossa, ja pakollinen laitteille, joissa on ASIL C ja ASIL D. Auditoinnin tulosten perusteella annetaan suosituksia laitekehittäjälle, mukaan lukien suositukset mahdollisten epäjohdonmukaisuuksien poistamiseksi.

Toimintaturvallisuusarvioinnissa tarkistetaan kehitteillä olevalle laitteelle luodun turvakotelon täydellisyys ja laatu . Auditoinnin lisäksi arviointia suositellaan laitteille, joilla on ASIL B turvallisuustavoitteiden joukossa, ja se on pakollinen laitteille, joissa on ASIL C ja ASIL D. Toiminnallisen turvallisuuden arvioinnissa arvioitavien parametrien rakenne on kuvattu yksityiskohtaisesti standardin liitteessä D olevassa osassa 2. Arvioinnin tulosten perusteella muodostetaan johtopäätös laitteen toimintaturvallisuuden saavuttamisesta, saavuttamatta jättämisestä tai ehdollisesta saavuttamisesta. Ehdollisen saavutuksen tapauksessa on selkeästi osoitettu olosuhteet, joissa laite katsotaan toiminnallisesti turvalliseksi. Jos päätelmä saavuttamatta jättämisestä, syyt ja tarvittavat mukautukset ilmoitetaan, minkä jälkeen arviointi toistetaan.

Osa 3 - Konseptivaihe

Konseptivaiheessa alkaa ISO 26262:ssa tutkimuksen/kehityksen kohteena olevan laitteen (tuotteen) varsinainen kehittäminen.Laitteet ovat sähköisiä ja/tai elektronisia järjestelmiä, jotka liittyvät turvallisuuteen liittyvien toimintojen suorittamiseen. Laite on järjestelmä tai järjestelmäkokonaisuus, johon sovelletaan ISO 26262 -standardia ja joka toteuttaa kokonaan tai osittain ajoneuvon toiminnot. Tällaisia toimintoja voi olla esimerkiksi ajoneuvon liiketoiminto, jossa eri parametreistä riippuvan vääntömomentin arvon laskenta on osa sitä ja jonka toteuttaa luistonestolaite, joka puolestaan on laite.

Laitteen idean täydelliseksi ymmärtämiseksi annetaan ajoneuvon osan arkkitehtoninen kaavio, jossa on siinä olevien laitteiden nimitykset, niiden toiminnot ja ajoneuvon liikkeen toiminnot ja niiden suhde.

Laitteen kuvausta, sen toimintoja, suhteita muihin laitteisiin, alustavaa arkkitehtuuria ja ominaisuuksia sekä muita varhaisessa kehitysvaiheessa määriteltävissä olevia näkökohtia kutsutaan nimikemäärittelyksi. Laitemäärittely on pääasiakirja, josta minkä tahansa laitteen kehittäminen ISO 26262 -standardin mukaisesti alkaa.

Laitemäärittelyn ja tarkemmin sanottuna siinä määriteltyjen laitetoimintojen perusteella sen avulla määritetään vaarallisia tapahtumia, jotka voivat johtua laitteen virheellisestä käytöstä. Tätä varten tehdään vaaraanalyysi ja riskiarviointi (hazards analysis & risk assessment), jonka aikana selvitetään laitteen virheellisen käyttäytymisen vaarat, niitä seuraavat vaaratapahtumat (joille asetetaan kriittisyystaso) ja turvallisuustavoitteet. ovat päättäneet.

Harkitse esimerkiksi auton luistonestolaitetta. Yksi tällaisen ohjaimen toiminnoista on vääntömomentin arvon laskeminen erilaisista parametreista, kuten auton nopeudesta ja kaasupolkimen paineesta, riippuen. Tämä toiminto ei ehkä toimi oikein, nimittäin jos ajoneuvon nopeus on nolla ja kaasupoljinta ei paineta, voi syntyä tahaton vääntömomentti. Tämä luistonestolaitteen käyttäytyminen on virheellistä toimintaa . Tällaisen virheellisen toiminnallisen käyttäytymisen yhteydessä syntyy vaara - tahaton kiihdytys ja tämä vaara yhdistettynä erilaisiin käyttöolosuhteisiin ja ympäristöihin, esimerkiksi ajoneuvon ollessa paikallaan jalankulkualueella, voi johtaa vaarallisiin tapahtumiin (joita joskus kutsutaan riskitekijöiksi). ). Yksi tällainen vaarallinen tapahtuma voi olla jalankulkijoiden vakava loukkaantuminen ajoneuvon etutörmäyksessä heidän kanssaan. Tällaisen vaarallisen tapahtuman osalta tämän vaarallisen tapahtuman vakavuuden suuruus, jota kutsutaan riskiksi, arvioidaan. Tämä standardin riskitaso asetetaan käyttämällä automotive safety integrity level (ASIL) -tasoa , joka lasketaan standardissa annetusta riskimatriisista, joka perustuu analyysiin vaarallisen tapahtuman mahdollisuudesta, sen seurausten vakavuudesta ja todennäköisyydestä. sen välttämisestä kuljettajan tai muiden tienkäyttäjien toiminnan vuoksi. Tämä taso vaihtelee ASIL A:sta ASIL D:hen, jossa jälkimmäistä pidetään korkeimpana.

Jos riskin suuruus on hyväksyttävä (QM-taso) hankkeen puitteissa, katsotaan, että järjestelmän toimintaturvallisuus on taattu suhteessa tähän vaaralliseen tapahtumaan. Jos ei (ASIL A - ASIL D), vaaratilannetta on kehitettävä edelleen, jotta voidaan määrittää turvallisuussuojamekanismit sen riskin suuruuden pienentämiseksi hyväksyttävälle tasolle ja toiminnan turvallisuuden varmistamiseksi.

Ensimmäinen askel vaara-analyysin ja riskien arvioinnin jälkeen on turvallisuustavoitteiden muodostaminen . Nimestä huolimatta tietoturvatavoitteet ovat korkeatasoisia turvallisuusvaatimuksia, jotka varmistavat kyseisen laitteen turvallisuuden. Turvallisuustavoitteet määritellään analyysin perusteella kaikista vaaratilanteista, joita laitteen virheellinen toiminta voi aiheuttaa, ja ovat melko usein (mutta ei aina) vaaratilanteita synnyttävien vaarojen vastaisia väitteitä. Yllä olevassa esimerkissä vaarana oli "tahaton kiihdytys", joten turvallisuustavoite voisi olla "ajoneuvo ei saa kiihtyä tahattomasti".

Kun kaikki suojaustavoitteet on luotu, kukin tavoitteista analysoidaan laitteen ensisijaisen arkkitehtuurin mukaisesti sen varalta, mikä voisi aiheuttaa kyseisen suojaustavoitteen rikkomisen. Mikä tahansa deduktiivinen analyysi, kuten vikapuuanalyysi, STPA tai HAZOP, sopii tähän erinomaisesti.

Turvallisuustavoitteen rikkomisen syiden selvittämisen tulosten perusteella luodaan toimintahäiriöiden raportoinnin ja toimivuuden vähentämisen strategia. Tämä strategia (yleensä graafisessa muodossa) näyttää tarkalleen, mitä on tehtävä, jotta voidaan havaita viat, jotka johtavat turvallisuustavoitteen rikkomiseen, ja ilmoittaa tästä muille laitteille ja kuljettajalle. Käytännössä kuvataan myös laitteen ja ajoneuvon turvalliset tilat, joihin siirretään turvallisuustavoitteiden rikkomisen estämiseksi. Tämä strategia on perusta toiminnallisten turvallisuusvaatimusten muodostukselle . Nämä vaatimukset vastaavat kysymykseen "mitä on tehtävä turvallisuustavoitteiden rikkomisen estämiseksi?", Tai tarkastelemamme esimerkin perusteella "mitä on tehtävä, jotta ajoneuvo ei kiihdytä tahattomasti?".

Esimerkki turvallisuustoiminnallisesta vaatimuksesta olisi: "Kaikki luistonestolaitteen aiheuttama tahaton yli 0,3 g:n kiihtyvyys yli 100 ms:n ajan on havaittava ja estettävä." Pienemmillä kiihtyvyyden arvoilla tai sen esiintymisen kestolla voidaan olettaa, että turvallisuustavoitetta ei rikota, koska riski ei ole kovin suuri (todennäköisesti vaurion vakavuus on alhainen, mikä johtaa alhaiseen ASIL).

Turvallisuustoiminnalliset vaatimukset perivät ASIL-tietoturvatavoitteiden tason, joka johdetaan riskiarvioinnin tuloksista. On tärkeää ymmärtää, että vaatimukset määräävät, mitä turvallisuuden varmistamiseksi on tehtävä, ja ASIL-taso määrittää vain menetelmät, joita käytetään tulevaisuudessa laitetta kehitettäessä. Mitä korkeampi ASIL-taso, sitä vaativampaa kehitystyö on erilaisten analyyttisten, verifiointi- ja validointitöiden suorittamisen kannalta. Esimerkkinä tarkastelemme standardin osassa 4 esitettyä taulukkoa 1, jossa on mahdollisia menetelmiä korkean tason järjestelmäarkkitehtuurin luotettavuuden ja turvallisuuden analysoimiseksi.

Järjestelmäarkkitehtuurin analyysi

menetelmät		ASIL
menetelmät		A	B	C	D
yksi	Deduktiivinen analyysi	noin	+	++	++
2	Induktiivinen analyysi	++	++	++	++

o - tälle menetelmälle ei vaadita sen olevan pakollinen tai valinnainen;

+ — tämän menetelmän käyttöä suositellaan

++ - tämä menetelmä on erittäin suositeltavaa

Taulukosta käy ilmi, että ASIL:n eri tasoilla järjestelmän arkkitehtuuria analysoidaan eri lähestymistapoja ja niiden yhdistelmiä. Siten deduktiivisen analyysin, kuten vikapuuanalyysin, tapauksessa tämän menetelmän käyttöä suositellaan voimakkaasti vain ASIL C:ssä ja ASIL D:ssä, toisin kuin induktiivinen analyysi, sanotaan vikamoodien ja vaikutusten analyysi, jota suositellaan vahvasti kaikille ASIL-arvo.

Toiminnallisten turvallisuusvaatimusten luettelon muodostaminen päättää konseptivaiheen. Nämä vaatimukset yhdessä laitteelle asetettujen perusvaatimusten kanssa otetaan huomioon laitteen, sen arkkitehtuurin, ohjelmiston ja laitteiston tarkemmassa tutkimuksessa.

Osa 4 - Järjestelmätason kehitys

Standardin tämän osan ensimmäinen puolisko on omistettu järjestelmätason laitekehitykselle arkkitehtonisesta näkökulmasta.

Konseptivaiheen tulos turvallisuustoiminnallisten vaatimusten sarjan muodossa on pääsyöte laitekehityksen käynnistämiseksi järjestelmätasolla. Järjestelmä on tässä tapauksessa itse laite, jota pidetään "mustana laatikkona". Jokaista toiminnallista turvallisuusvaatimusta varten muodostetaan yksi tai useampi tekninen turvallisuusvaatimus . Nämä vaatimukset vastaavat edellä käytetyn turvallisuustoiminnallisuusvaatimusesimerkin mukaisesti kysymykseen "miten konseptivaiheen vaatimukset tulisi toteuttaa, jotta ajoneuvo ei kiihdy tahattomasti?".

Vastaus voisi olla:

Luistonestolaitteen puolelle tulisi asentaa mekanismi kuljettajan vetopyyntösignaalin (kaasupolkimen signaalin) uskottavuuden tarkistamiseksi, ja se toteutetaan vertaamalla kahta ohjaussignaalia, jotka kulkevat polkimelta ohjaimeen kahta linjaa pitkin.
Jos signaalit eivät täsmää, ohjain nollaa kuljettajan vetopyynnön hallittavasti 50 ms:n sisällä.
Luistonestolaitteen puolelta tulee tarkistaa mikrokontrollerin laskeman vaaditun vääntömomentin arvon uskottavuus, eikä nollapyynnössä ohjain saa luoda spontaanisti ulkoista vääntömomenttipyyntöä.
Momenttipyynnön lähtösignaali suurjänniteinvertteriin on lähetettävä sille kahden redundantin datalinjan kautta.

Nämä ovat vain muutamia turvallisuusteknisiä vaatimuksia, jotka voidaan johtaa yllä kuvattuun turvallisuustoiminnalliseen vaatimukseen. Niiden lisäksi voi tulla vaatimuksia erilaisista standardeista tai lainsäädäntöasiakirjoista, jotka selittävät kehitettävän laitteen puolen suojatoimenpiteitä koskevia erityisvaatimuksia (esim. suurjännitelaitteiden ylitehoa vaimentavia toimenpiteitä koskeva vaatimus seuraa UN ECE:stä sääntö 100, mutta se ei välttämättä seuraa suoraan mistään turvallisuustoiminnallisesta vaatimuksesta). Vaatimukset tulee jakaa järjestelmän ohjelmisto- ja laitteisto-osien kesken.

Teknisten turvallisuusvaatimusten perusteella muodostetaan turvallisuusmekanismien kuvaus , josta tulee osa olemassa olevaa järjestelmäarkkitehtuuria yksityiskohtaisen selvityksen jälkeen. Edes tällainen muunneltu arkkitehtuuri ei kuitenkaan välttämättä ole riittävän turvallinen. Uuden laitearkkitehtuurin turvallisuuden tarkistamiseksi, jonka koostumuksessa on suojaavia turvamekanismeja, suoritetaan ylimääräinen induktiivinen tai deduktiivinen analyysi. Tällaisen analyysin tulosten perusteella, esimerkiksi FMEA, saattaa olla tarpeen parantaa tai täydentää ehdotettuja suojamekanismeja, jotta toiminnalliset turvallisuusvaatimukset täyttyvät täysin.

Suojaavat turvamekanismit on jaettu 3 luokkaan - turvamekanismit, tunnistusmekanismit ja lievennysmekanismit. Ensimmäisiä käytetään estämään täysin vaaroihin ja vaarallisiin tapahtumiin mahdollisesti johtavien vikojen syntyminen, kun taas toiset yhdessä toimivat mahdollistavat tällaisten vikojen ilmenemisen havaitsemisen ja niiden seurausten pienentämisen niin, että riskitaso pysyy hyväksyttävänä. Esimerkkejä turvamekanismeista ovat redundanssi, havaitsemismekanismit jaksolliset automaattiset testaukset ja lievennysmekanismit ovat algoritmeja spontaanin vääntömomentin vaimentamiseen. Itse asiassa turvamekanismit mahdollistavat satunnaisten ja systemaattisten laitteistovikojen ja systemaattisten ohjelmistovikojen sekä niiden seurausten käsittelemisen.

Jokainen suojamekanismi on varustettava sen diagnostiikkavälineillä, jotta vältetään tilanne, jossa sen vika jää huomaamatta ja itse asiassa pääasiallinen toimintahäiriö, jota vastaan tämä suojamekanismi asennettiin, voi tapahtua esteettä.

Jotta vastuu turvamäärittelyjen ja suojausmekanismien toteuttamisesta erotettaisiin selkeästi laitteen laitteiston ja ohjelmiston välillä, käytetään muodollista asiakirjaa, jota kutsutaan laitteisto-ohjelmisto-rajapinnan määrittelyksi. Tällainen spesifikaatio kaappaa kaikki ohjelmiston ja AO:n väliset tietovirrat, erityisesti ne, jotka liittyvät suojausmekanismien toimintaan. Tämä dokumentti on tärkeä jatkossa, sillä sen suhteen testataan järjestelmän ohjelmisto- ja laitteistointegraatiota ja sen toimintaa kokonaisuutena.

Teknisten turvallisuusvaatimusten lisäksi on tärkeää muotoilla yleinen käsitys laitteen tuotannon, käytön, huollon ja käytöstä poistamisen vaatimuksista, koska nämä vaatimukset voivat vaikuttaa suojaturvamekanismien toteutukseen. Jos esimerkiksi haluat tukea laitteiden nopeaa palautusta ajoneuvossa, sulakkeiden käyttö voi monimutkaistaa tätä vaatimusta huomattavasti.

Tämän osan toinen puoli on omistettu järjestelmän integroinnin yhdeksi kokonaisuudeksi ja ajoneuvoon testaamiseen sekä erilaisten vaatimusten (mukaan lukien turvallisuusvaatimusten) testaamiseen.

Standardissa ehdotetaan sellaista testausrakennetta, jossa aluksi käytetään valmiita ohjelmistoja ja laitteistoja ja testataan niiden integrointia eli kokoamista yhdeksi järjestelmäksi - laitteeksi. Seuraavaksi testataan tämän laitteen onnistunutta toimintaa ja sen integrointia suurempaan järjestelmään tai ajoneuvoon. Tällöin toiminnallisen turvallisuuden kannalta tarkastetaan ensin kaikkien suojaavien turvamekanismien oikea toiminta ottamalla käyttöön keinotekoisia vikoja ja sitten laitteen vaatimustenmukaisuus esitettyjen teknisten ja toiminnallisten turvallisuusvaatimusten kanssa. Koko ajoneuvon tasolla varmistetaan, että laite ei toimintahäiriön sattuessa riko sille aiemmin määritettyjä turvallisuustavoitteita (turvallisuusvalidointi)

Laitteen integrointi- ja pätevyystestaukset kaikilla tasoilla voidaan suorittaa erilaisissa ympäristöissä:

Hardware-in-the-loop - ohjaimen testaus takaisinkytkentäsilmukassa ohjausobjektisimulaattorilla reaaliajassa;
Testauslaitteen testaus - ohjaimen testaus takaisinkytkentäsilmukassa todellisen ohjausobjektin kanssa telineessä reaaliajassa;
Ajoneuvon testaus - ohjaimen testaus takaisinkytkentäsilmukassa todellisen ohjausobjektin kanssa osana ajoneuvon prototyyppiä kohdeympäristössä ja reaaliajassa.

Osa 5 - Kehitys laitteistotasolla

Tämä standardin osa käsittelee laitteistotason toiminnallisen turvallisuuden vaatimuksia. Toteutettavien suojamekanismien ja toiminnallisen turvallisuuden teknisten vaatimusten analyysin perusteella on tarpeen määrittää, mitä tarkalleen ja miten on tehtävä laitteen laitteistokomponentin tasolla, jotta varmistetaan oikea turvallisuustaso yleensä.

Laitteistotason toimintaturvallisuuden vaatimukset sisältävät pääsääntöisesti yksityiskohtaiset parametrit, jotka ovat välttämättömiä suojaavien turvamekanismien toteuttamiseksi, kuten vahtikoirien toiminnan aikarajat, muistin eheystarkastusten tiheys jne. Kaikki nämä vaatimukset otetaan huomioon huomioon sähköpiiriohjaimen kehitysvaiheessa ja levyn topologiaa kehitettäessä sekä komponenttipohjaa valittaessa. Koska järjestelmällisiä vikoja voi esiintyä laitteistotasolla sekä järjestelmäarkkitehtuurin kehittämisen aikana, laitteisto vaatii myös ylimääräistä induktiivista tai deduktiivista analyysiä, joka paljastaa ehdotetun ohjainlaitteiston arkkitehtuurin haavoittuvuuksia, jotka voivat johtaa turvallisuustavoitteiden rikkomiseen tasoittaa koko järjestelmän.

Tällaisia haavoittuvuuksia kutsutaan epäonnistumisiksi, ja osa niistä voi johtaa turvallisuustavoitteiden rikkomiseen. Yksittäinen vika on vika, jota turvallisuussuojamekanismi ei kata ja joka johtaa suoraan turvallisuustavoitteen rikkomiseen. Kaksoisvika on vika, joka yhdistettynä toiseen itsenäiseen vikaan johtaa turvallisuustavoitteen rikkomiseen. Kaksoisvian yleistetty versio on monivika, mutta useat tason 3 ja sitä suuremmat viat ovat epätodennäköisiä ja siksi turvallisia ISO 26262:n mukaan. Piilevä vika on moninkertainen vika, jonka esiintymistä turvasuojamekanismi ei havaitse eikä kuljettaja havaitse sitä. Erilaisia suojausmekanismeja sovellettaessa oletetaan, että jäljelle jää ns. jäännösvikoja , eli vikoja, jotka eivät kuulu suojausmekanismien piiriin ja johtavat turvallisuustavoitteiden rikkomiseen. Eri ASIL:ien tapauksessa jäännösvikojen prosenttiosuus ei kuitenkaan saa ylittää standardissa määritettyä arvoa.

Näihin seikkoihin liittyy se, että laitteisto edellyttää sellaisten mittareiden laskemista, jotka osoittavat hyväksyttävän tason systemaattisia ja satunnaisia vikoja. Taulukoissa 4, 5 ja 6 on esitetty satunnaisvikamittareiden tavoitearvot.

Taulukko satunnaisten virhemittareiden tavoitearvoista

	ASIL A	ASIL B	ASIL C	ASIL D
Yksittäisten ja jäännösvirheiden mittari	-	≥ 90 %	≥ 97 %	≥ 99 %
Piilevä kaksoisvikamittari	-	≥ 60 %	≥ 80 %	≥ 90 %
Turvallisuustavoitteen rikkomisen todennäköisyys satunnaisten vikojen vuoksi	-	< 1/h $10^{{-7}}$	< 1/h $10^{{-7}}$	< 1/h $10^{{-8}}$

Yksittäisten ja jäännösvikojen (SPF) metriikan lauseke:

${\displaystyle SPF=1-{\frac {\sum (\lambda _{SPF}+\lambda _{RF})}{\sum \lambda _{SR))}={\frac {\sum (\lambda _{MPF}+\lambda _{S})}{\sum \lambda _{SR))))$

missä on yksittäisten vikojen epäonnistumisprosentti; $\lambda _{SPF}$

$\lambda _{RF}$ — vikaprosentti jäännösvikojen osalta;

$\lambda _{SR}$ — epäonnistumisprosentti kaikkien vikojen osalta;

$\lambda _{S}$ — vikaprosentti turvallisten vikojen osalta;

$\lambda _{SR}$ — kaksoisvikojen epäonnistumisprosentti.

Double latent error (LF) -metriikan lauseke on:

$LF=1-{\frac {\sum \lambda _{MPF,lat)){\sum (\lambda _{SR}-\lambda _{SPF}-\lambda _{RF))))) = {\frac {\sum (\lambda _{MPF,det}+\lambda _{MPF,per}+\lambda _{S})}{\sum (\lambda _{SR}-\lambda _{SPF } -\lambda _{RF})}}$

missä on kaksinkertaisten piilevien vikojen epäonnistumisprosentti; $\lambda _{MPF,lat}$

${\displaystyle \lambda _{MPF,det))$ — vikaprosentti kaksinkertaisesti havaittavissa olevissa vioissa;

$\lambda _{MPF,per}$ — virheprosentti kuljettajan havaitsemien kaksoisvikojen osalta;

Laskettaessa todennäköisyyttä turvallisuustavoitteen rikkomisen satunnaisten vikojen (PMHF) vuoksi, otetaan huomioon kaikkien niiden vikojen kokonaismäärä, jotka voivat jollain tapaa johtaa turvallisuustavoitteen rikkomiseen (tällaisiin vioihin sisältyvät kaikki vaaralliset viat). PMHF-arvo voidaan laskea karkeasti seuraavan kaavan avulla:

${\displaystyle PMHF\approx \lambda _{SPF}+\lambda _{RF}+\lambda _{MPF,det}\times \lambda _{MPF,lat}\times T_{Elinikä))$ ,

missä - ajoneuvon käyttöikä, käytännössä sen oletetaan olevan 15-20 vuotta. ${\displaystyle T_{Elinikä))$

Laitteistoarkkitehtuurin toteuttaminen ja metritavoitteiden saavuttaminen on vain osa työtä laitteen toimintaturvallisuuden varmistamisessa. Lisäksi vaaditaan laitteistotestisykli, joka voidaan ehdollisesti jakaa kahteen osaan:

Testit, joilla varmistetaan toimintaturvallisuuden laitteistovaatimusten oikeellisuus ja täydellisyys:
- suojaavien turvamekanismien sähköinen testaus;
- turvamekanismien toiminnallinen testaus;
- testit, joissa vikoja tuodaan keinotekoisesti;
Testit, joiden tarkoituksena on tarkistaa laitteiston luotettavuus ja kestävyys ympäristön vaikutuksille ja lisääntyneille kuormituksille:
- ympäristötekijöiden vaikutustestit (ilmastotestit);
- laajennettu toiminnallinen testaus;
- tilastollinen testi;
- testit lisääntyneissä työkuormissa;
- tuhoavat testit ylikriittisissä toimintatiloissa;
- staattiset mekaaniset testit (taivutus);
- dynaamiset mekaaniset testit (värähtelyt);
- pakotetut (kiihdytetyt) testit;
- kemikaalinkestävyys ja turvallisuustestit;
- EMC- ja ESD-testit.

Testitulokset yhdessä metrilaskelmien kanssa ovat perusteita laitteiston toiminnallisten turvallisuusvaatimusten toteuttamiselle ja ovat yksi turvallisuusperustelun komponenteista.

Osa 6 - Kehitys ohjelmistotasolla

Tämä standardin osa käsittelee toiminnallisen turvallisuuden vaatimuksia ohjelmistotasolla. Toteutusta vaativien suojamekanismien ja toiminnallisen turvallisuuden teknisten vaatimusten analyysin perusteella on tarpeen määrittää, mitä ja miten laitteen ohjelmistokomponentin tasolla tehdään, jotta varmistetaan asianmukainen turvallisuustaso yleistä.

Ohjelmistotason toiminnalliset turvallisuusvaatimukset sisältävät pääsääntöisesti yksityiskohtaisen kuvauksen suojamekanismien toiminnan algoritmeista, millä logiikalla suojamekanismit tulee laukaista ja mitä sallittuja laskentatehomääriä on noudatettava. Kaikki nämä vaatimukset otetaan huomioon ohjelmistoarkkitehtuurin kehitysvaiheessa. Koska systemaattisia vikoja voi esiintyä ohjelmistotasolla sekä laitteistotasolla ja koko järjestelmän arkkitehtuuria kehitettäessä, ohjelmisto-osa vaatii myös ylimääräistä induktiivista tai deduktiivista analyysiä, joka mahdollistaa haavoittuvuuksien tunnistamisen ehdotetusta ohjainohjelmistoarkkitehtuurista. voi johtaa turvallisuustavoitteiden rikkomiseen koko järjestelmän tasolla.

Samanaikaisesti tällainen analyysi tehdään yleensä jokaiselle ohjelmistokomponentille erikseen: analyysi sovellusohjelmistolle, analyysi järjestelmäohjelmistolle, analyysi käyttöjärjestelmälle tai matalan tason ohjelmistolle jne. Analyysin tarkoituksena on myös korostaa riippuvaisia moduulien viat Ohjelmisto, kun yhden toiminnon viat johtavat peräkkäisiin virheisiin kaikissa riippuvaisissa toiminnoissa. Tämä on erityisen tärkeää käytettäessä ohjelmistomoduuleja, joiden vaatimuksissa on eri ASIL-tasot.

Ohjelmistokehityksessä keskitytään ohjelmointikielen käyttöön ja koodaussääntöihin. Ensinnäkin standardi suosittelee vain sellaisten kielten käyttöä, jotka täyttävät joukon kriteerit, kuten vahvan ja staattisen kirjoittamisen tuen . Lisäksi vain tästä vaatimuksesta seuraa käytännön mahdottomuus käyttää joitain ohjelmointikieliä, kuten Python . Eri kielten ohjelmointisääntöjen osalta on olemassa monia erilaisia ohjeita ja normatiivisia asiakirjoja, jotka säätelevät koodin kirjoittamista tietyllä ohjelmointikielellä turvallisuuteen liittyviä laitteita kehitettäessä. Yksi esimerkki tällaisista ohjeista on MISRA - sääntödokumenttisarja C :lle ja C++ :lle .

Kuten järjestelmäkehitys, myös ohjelmistokehitys vaatii ohjelmistojen todentamista ja validointia eri tasoilla. Joten luistonestolaitteen osalta tämä on testausta yksikkötasolla, ohjelmistomoduulien tasolla (yksiköiden kokoonpano), ohjelmistokerrosten tasolla ja koko laiteohjelmiston tasolla. Jokaisessa vaiheessa suoritetaan koodin staattinen analyysi, ajonaikaisten virheiden puuttuminen, suojamekanismien algoritmien toiminnan tarkistus ja paljon muuta. Samaan aikaan sekä integraatio- että pätevyystestausta suoritetaan eri ympäristöissä:

Ohjelmisto-silmukassa - ohjaimen laiteohjelmiston testaus takaisinkytkentäsilmukassa ohjausobjektin emuloinnilla samassa tietokoneessa ei reaaliajassa;
Prosessori silmukassa - ohjaimen laiteohjelmiston testaus (sijaitsee testilevyllä, jossa on kohdemikro-ohjain) takaisinkytkentäsilmukassa ohjausobjektisimulaattorilla ei-reaaliaikaisessa tilassa;
Hardware-in-the-loop - ohjaimen laiteohjelmiston testaus takaisinkytkentäsilmukassa ohjausobjektisimulaattorilla reaaliajassa.

Tärkeä rooli testauksessa on testikattavuuden keräämisellä, jolla perustellaan koko ohjelmiston toiminnallisuuden kattavuus testeillä.

Suhde muihin standardeihin

ISO 26262 -standardi on yksi tämän hetken nuorimmista ja jäsenneltyimmistä toiminnallisista turvallisuusstandardeista, sillä se tarjoaa monia esimerkkejä vaikuttavassa volyymissa ja rakenteeltaan samanlainen kuin klassisen V-mallin. Tämä standardi kattaa kuitenkin vain kehitteillä olevien laitteiden toimintojen virheellisen käytöksen ja tarjoaa lähestymistavan niiden torjumiseen.

Teknologioiden kehittyessä miehittämättömien ajoneuvojen alalla kävi selväksi, että klassisten virheellisten toimintatapojen lisäksi joillakin laitteilla voi olla tietyssä tilanteessa myös varsin oikeaa käyttäytymistä, mikä ei kuitenkaan ole toivottavaa ajoneuvon kannalta. tai kuljettaja. Esimerkki tästä on kamera, joka tallentaa ja tunnistaa tiellä olevat kohteet. Väärällä tunnistuksella tällainen kamera voi saada miehittämättömän ajoneuvon, johon se on asennettu, tekemään vääriä, mutta teknisesti oikeita päätöksiä, mikä puolestaan voi johtaa onnettomuuteen.

Tällaisten tapausten käsittelemiseksi ISO julkaisi vuonna 2019 ISO/PAS 21448 [3] -standardin , joka integroituu suhteellisen helposti ISO 26262:een ja kattaa aiemmin ongelmalliset kohdetoimintojen turvallisuuteen liittyvät alueet.

Lisäksi kehitteillä on ISO 21434 -standardi, jonka rakenteeltaan ISO 26262:n kaltaisena tulee sisältää lähestymistapoja ajoneuvojen tietoturvan varmistamiseen.

Muistiinpanot

↑ ISO 26262-1: 2011 . ISO (11.1.2011). Käyttöönottopäivä: 20.4.2020.
↑ ISO 26262-1: 2018 . ISO (12.1.2018). Käyttöönottopäivä: 20.4.2020.
↑ ISO/PAS 21448:2019 (englanniksi) . ISO . Käyttöönottopäivä: 28.6.2020.

Kirjallisuus

ISO 21448:2022