Gevinster:
- Evne til å forklare ISO 26262 funksjonell sikkerhet og ISO 21448 (SOTIF) rammeverk og deres effekter på systemer som inneholder kunstig intelligens
- Evne til å administrere personvern, sjåførdata, cybersikkerhet (ISO/SAE 21434) og etiske risikoer i bilsammenheng
- Evne til å opprettholde menneskelig ansvar for sikkerhetskritiske beslutninger ved å forstå at AI-utgang ikke er en erstatning for kompetent ingeniørgodkjenning
Du er i den mest kritiske enheten i denne modulen. Så langt har vi sett på AI som en akselerator fra design til produksjon, fra testing til forsyningskjede. Men det avgjørende spørsmålet i bilindustrien er: vil dette systemet skade noen og hvem er ansvarlig? Denne enheten dekker i klartekst rammeverket for ansvarlig bruk av AI i en sikkerhetskritisk bransje – funksjonell sikkerhet, SOTIF, cybersikkerhet, personvern og etikk. Kjerneprinsippet forblir konstant: AI-utgang erstatter aldri kompetent ingeniørgodkjenning; Sikkerhetskritisk beslutning og ansvar tilhører mennesket.
ISO 26262: funksjonell sikkerhet
ISO 26262 er funksjonssikkerhetsstandarden for elektriske/elektroniske systemer til veikjøretøyer. Funksjonell sikkerhet; Den er opptatt av å sikre at når et system svikter (en sensor går i stykker, en programvare svikter) fører det ikke til en farlig situasjon.
I hjertet av denne standarden er ASIL (Automotive Safety Integrity Level). En fare vurderes i tre dimensjoner:
- Alvorlighet: Hvor ille ville det være hvis det skjedde? (mindre skade eller død)
- Eksponering: Hvor ofte skjer dette?
- Kontrollerbarhet: Hvor mye kan sjåføren kontrollere situasjonen?
Disse tre kombinert resulterer i et nivå fra ASIL A (laveste) til ASIL D (høyest, f.eks. bremsing, styring). Etter hvert som nivået øker, blir krav til utvikling, testing og dokumentasjon strengere.
HOVED
prøvesystem
Kravintensitet
A.
Innvendig belysning funksjonsfeil
lav
B.
baklys
medium
C.
Noen ADAS-funksjoner
høy
D.
Bremse, styring, kollisjonspute
høyest
Tips: Å kjenne HOVEDnivået til en funksjon forteller deg hvor mye oppmerksomhet det krever å bruke AI i den funksjonen. INGEN beslutning basert på AI-utgang i en funksjon kan aksepteres uten uavhengig sikkerhetsverifisering.
ISO 21448 (SOTIF): sikkerhet for tiltenkt funksjon
Klassisk funksjonell sikkerhet (ISO 26262) fokuserer på spørsmålet "hva skjer hvis systemet svikter?" Men det er et nytt problem i deteksjonssystemer for kunstig intelligens: selv om systemet aldri svikter, kan det være utilstrekkelig. Kameraet fungerer fint, men kan ikke gjenkjenne en snødekt plate; Radaren er solid, men den ignorerer et stillestående kjøretøy som et spøkelsessignal. Det er ingen maskinvare-/programvarefeil her; Problemet er på grensen av det tiltenkte omfanget av funksjonen.
ISO 21448 - SOTIF (Safety Of The Intended Functionality) adresserer akkurat dette gapet: håndtering av risikoer som oppstår fra ukjente scenarier, deteksjonsgrenser og uforutsette situasjoner, selv om systemet fungerer som designet. I AI-basert ADAS/autonom kjøring er SOTIF like kritisk som ISO 26262.
Ramme
Fokus
eksempel
ISO 26262
Risiko på grunn av feil
Sensor bryter, signal forsvinner
ISO 21448 (SOTIF)
Risiko for utilstrekkelighet/ikke-anerkjennelse
Robust kamera gjenkjenner ikke snødekte plate
ISO/SAE 21434
cybersikkerhet
Systemangrep, datamanipulasjon
Forsiktig: AI-modeller er statistiske; De kan ikke garantere at de vil «se enhver situasjon riktig». SOTIF har som mål å begrense ukjente farlige scenarier i disse iboende begrensede systemene og redusere den gjenværende risikoen til et akseptabelt nivå. "Modellen er 99,9% nøyaktig" er ikke et bevis på sikkerhet.
ISO/SAE 21434: cybersikkerhet
Tilkoblede og programvaredefinerte kjøretøy er sårbare for cyberangrep. En ekstern angriper kan endre bremsekommandoen, stjele telemetri eller lure deteksjonsmodellen (motstridende angrep: få modellen til å feilkjenne den ved å plassere et lite klistremerke på en tallerken). ISO/SAE 21434 er det tekniske rammeverket for cybersikkerhet for kjøretøy. I sammenheng med kunstig intelligens skiller to risikoer seg ut: å lure modellen (motstridende) og forgifte treningsdataene (dataforgiftning). Sikkerhetskritiske AI-systemer bør testes mot disse angrepene.
Personvern og personopplysninger
Det moderne kjøretøyet er et "datasenter på hjul": plassering, kjøreatferd, lyd, til og med kabinkamera. Det meste av dette er personopplysninger og dekkes av KVKK (Türkiye) og GDPR (Europa). VIN (chassisnummer) kan identifisere et kjøretøy og indirekte dets eier. Grunnleggende prinsipper:
- Dataminimering: Samle kun det som trengs.
- Formålsbegrensning: Ikke bruk data til andre formål enn det de ble samlet inn for.
- Anonymisering/pseudonymisering: Fjern eller kode personlig identifiserende informasjon.
- Eksplisitt samtykke og åpenhet: Sjåføren skal vite hva som samles inn.
- Sikker lagring og overføring.
Forsiktig: Å sende rå VIN, posisjonshistorikk eller kjøreatferd til et offentlig AI-verktøy i skyen kan være både et brudd på personvernet og en kontraktsmessig risiko. Når du arbeider med disse dataene, anonymiser dem og bruk et institusjonelt, databeskyttet miljø.
Etikk og ingeniøransvar
Kunstig intelligens fører med seg noen etiske risikoer:
- Bias: Hvis treningsdataene dominerer visse forhold (f.eks. dagtid, lys hud, visse regionale veier), kan modellen yte dårlig under underrepresenterte forhold (natt, forskjellige forhold). Dette er en sårbarhet.
- Overtillit (automatiseringsskjevhet): Folk stoler blindt på automatisering og overstyrer sin egen dømmekraft. Hvis testingeniøren slutter å se på rådataene bare fordi AI-en sier «bestått», er dette en farlig trend.
- Tap av ansvar: «Modellen bestemte» er ikke et forsvar. Det skal alltid stå en person som skriver under ved avgjørelsen.
Mini casestudier
Tilfelle 1 - SOTIF-grense. Et automatisk nødbremsesystem består alle laboratorietester, uten funksjonsfeil. På feltet, i lav sol, tar en hvit lastebil feil tilhengeren sin med himmelen og bremser sent. Dette er ikke en funksjonsfeil, men en SOTIF-sårbarhet: systemet er intakt, men scenariet er utenfor deteksjonsgrensen. Teamet legger dette scenariet til testbiblioteket og styrker radarfusjon. Konklusjon: "Ingen feil" er ikke bevis på sikkerhet; Insuffisiens er også en risiko.
Tilfelle 2 - Forutinntatte data. En fotgjengerdeteksjonsmodell ble trent hovedsakelig med dagtidsdata; Tilbakekalling av natt er betydelig lavere. Teamet balanserer og omskoler data om natt og lite lys og rapporterer nattscenarier separat. Konklusjon: Ubalanserte data skaper en dødelig sårbarhet under visse omstendigheter.
Sak 3 – Forebygging av personvernbrudd. En analytiker er i ferd med å lime inn flåtedata i et offentlig AI-verktøy når han legger merke til at dataene inneholder rå VIN- og GPS-plasseringer. Det fungerer i et bedriftsmiljø ved å anonymisere dataene (vehicle_01..arac_50 i stedet for VIN, regionskode i stedet for plassering). Resultat: Et øyeblikks oppmerksomhet forhindret et alvorlig KVKK-brudd.
ledetekstmaler
Mal 1 - PRIOR/risikovurdering (utkast):
Rolle: Du er funksjonell sikkerhetsrådgiver. Oppgave: Forbereder et utkast for å hjelpe til med fare- og risikoanalyse for en funksjon. Kontekst: Funksjon: automatisk nødbremsing; urban og intercity.Begrensning: nøyaktig tildeling av ASIL; Gi en liste over spørsmål og oppmerksomhetspunkter om dimensjonene alvorlighetsgrad/eksponering/kontrollerbarhet; angi at endelig oppdrag ligger hos den autoriserte sikkerhetsingeniøren. Utdata: Størrelse | evalueringsspørsmål | oppmerksomhetsnotattabell.
Mal 2 - SOTIF-scenarioskanning:
Rolle: Du er en SOTIF-ekspert. Oppgave: Liste scenarier der en deteksjonsfunksjon kan være "system intakt, men utilstrekkelig". Kontekst: Kamera + radar; lav sol, snø, tunnelutgang, uvanlige objekter.Utgang: Scenario | hvorfor utilstrekkelighet | reduksjonsanbefaling.
Mal 3 – Personvernkontroll:
Rolle: Du er databeskyttelseskonsulent (KVKK/GDPR). Oppgave: Gjennomfør en personvernrevisjon før du deler et datasett. Kontekst: Flåtetelemetri; Kolonnene inneholder VIN, GPS, kjørescore. Begrensning: Hvilke felt er personopplysninger, hvordan skal de anonymiseres, hva skal jeg ikke dele i det hele tatt; sort.Output: Felt | risiko | anbefalt transaksjonsdiagram.
Mal 4 - Bias check:
Rolle: Du er en ML sikkerhets- og rettferdighetsrevisor. Oppgave: Fortell meg hvordan jeg skal se etter risiko for skjevhet i en deteksjonsmodell. Kontekst: Fotgjengerdeteksjon; treningsdata vektet dag/by. Utgang: Tilstand for å sjekke | måling | risikotegn.
Svak forespørsel / Sterk forespørsel
Svak melding:
Er dette autonome bremsesystemet trygt, bekreft.
Å prøve å få AI-sikkerhetsklarering er farlig; Godkjenningen tilhører den autoriserte ingeniøren.
Kraftig ledetekst:
Rolle: Du er funksjonell sikkerhets- og SOTIF-konsulent. Oppgave: List opp hvilke spørsmål jeg bør stille og hvilke bevis jeg bør samle inn i sikkerhetsvurderingen av min automatiske bremsefunksjon. Kontekst: AI-basert deteksjon; kamera+radar; ASIL kan være høy. Begrensning: 'Godkjenn' systemet; Gi separate lister over spørsmål og bevis i henhold til ISO 26262 (defekt) og SOTIF (mangel); Understrek at endelig godkjenning ligger hos den autoriserte sikkerhetsingeniøren. Utdata: Rammeverk | spørsmål | nødvendig bevistabell.
Vanlige feil
- Forveksler "ingen feil" med "sikker". SOTIF-mangel kan drepe uten funksjonsfeil.
- Får AI sikkerhetsklarering. Godkjenning og ansvar ligger hos den autoriserte ingeniøren.
- Ta feil av modellens nøyaktighet som bevis på sikkerhet. 99,9 % nøyaktighet indikerer ikke at den gjenværende risikoen er håndtert.
- Beskytter ikke personopplysninger. VIN/sted/kjøreatferd er innenfor rammen av KVKK/GDPR.
- Ignorerer skjevhet og overtillit. Ubalanserte data og blind tillit til automatisering er sårbarheter.
Oppsummert
- ISO 26262 styrer risikoen på grunn av feil (med ASIL), mens ISO 21448/SOTIF håndterer risikoen for feil uten feil; Begge er kritiske i AI-deteksjon.
- ISO/SAE 21434 cybersikkerhet; kontradiktoriske og dataforgiftningsangrep er AI-spesifikke trusler.
- Dataminimering, formålsbegrensning og anonymisering er obligatorisk innenfor rammen av KVKK/GDPR; VIN/sted er personopplysninger.
- Fordommer, overmot og tap av ansvar er de viktigste etiske risikoene.
- AI-utgang er ikke en erstatning for kvalifisert ingeniørgodkjenning; Den sikkerhetskritiske avgjørelsen og signaturen tilhører alltid personen.
Søknadsoppgave
Velg en sikkerhetsrelatert funksjon (f.eks. kjørefeltholding). (1) Diskuter hvorfor ASIL-nivået til denne funksjonen kan være høyt/lavt langs dimensjonene for alvorlighetsgrad/eksponering/kontrollerbarhet. (2) Generer 5 "system solide, men utilstrekkelige" scenarier med mal 2. (3) Konfidensialitet revidere et relevant datasett med mal 3. (4) Forklar hvorfor det å si "Modellen bekreftet" ikke er et forsvar.
sjekkliste
- [ ] Jeg evaluerte de FAKTISKE dimensjonene til funksjonen (jeg overlot den nøyaktige oppgaven til myndigheten).
- [ ] Jeg gjorde forskjellen mellom ISO 26262 (feil) og SOTIF (mangel).
- [ ] Jeg har tatt hensyn til cybersikkerhetsrisikoen (motstridende/forgiftning).
- [ ] Jeg anonymiserte og minimerte personopplysninger.
- [ ] Jeg sjekket for risikoer for skjevhet og overmot.
- [ ] Jeg har bekreftet at sikkerhetsklareringen er hos den kvalifiserte ingeniøren.