Unitate 10 / 11

Siguranță funcțională, SOTIF, Etică și confidențialitate

Câștiguri:

  • Abilitatea de a explica cadrele de securitate funcțională ISO 26262 și ISO 21448 (SOTIF) și efectele acestora asupra sistemelor care conțin inteligență artificială
  • Abilitatea de a gestiona confidențialitatea datelor, datele șoferilor, securitatea cibernetică (ISO/SAE 21434) și riscurile etice în contextul auto
  • Capacitatea de a menține responsabilitatea umană pentru deciziile critice pentru siguranță, înțelegând că rezultatul AI nu este un substitut pentru aprobarea inginerului competent

Te afli în cea mai critică unitate a acestui modul. Până acum am văzut AI ca un accelerator de la proiectare la producție, de la testare la lanțul de aprovizionare. Dar întrebarea decisivă în domeniul auto este: va dăuna acest sistem pe cineva și cine este responsabil? Această unitate acoperă într-un limbaj simplu cadrele de utilizare responsabilă a inteligenței artificiale într-o industrie critică pentru siguranță – siguranță funcțională, SOTIF, securitate cibernetică, confidențialitate și etică. Principiul de bază rămâne constant: ieșirea AI nu înlocuiește niciodată aprobarea inginerului competent; Decizia și responsabilitatea critică pentru securitate aparțin omului.

ISO 26262: siguranță funcțională

ISO 26262 este standardul de siguranță funcțională pentru sistemele electrice/electronice ale vehiculelor rutiere. Siguranta functionala; Este preocupat de a se asigura că atunci când un sistem se defectează (se defectează un senzor, se defectează un software) nu duce la o situație periculoasă.

În centrul acestui standard se află ASIL (nivelul de integritate al siguranței auto). Un pericol este evaluat în trei dimensiuni:

  • Severitate: Cât de rău ar fi dacă s-ar întâmpla? (rănire ușoară sau deces)
  • Expunere: Cât de des apare acest lucru?
  • Controlabilitate: Cât de mult poate șoferul să controleze situația?

Aceste trei combinate duc la un nivel de la ASIL A (cel mai scăzut) la ASIL D (cel mai ridicat, de exemplu frânare, direcție). Pe măsură ce nivelul crește, cerințele de dezvoltare, testare și documentare devin mai stricte.

PRINCIPALA

sistem de mostre

Intensitatea cerinței

A.

Defecțiune la iluminatul interior

scăzută

B.

lumina din spate

mediu

C.

Unele funcții ADAS

înalt

D.

Frână, direcție, airbag

cel mai înalt

Sfat: Cunoașterea nivelului PRINCIPAL al unei funcții vă spune cât de multă atenție necesită utilizarea AI în acea funcție. Nicio decizie bazată pe ieșirea AI într-o funcție nu poate fi acceptată fără o verificare independentă de securitate.

ISO 21448 (SOTIF): siguranța funcției prevăzute

Siguranța funcțională clasică (ISO 26262) se concentrează pe întrebarea „ce se întâmplă dacă sistemul eșuează?” Dar există o nouă problemă în sistemele de detectare a inteligenței artificiale: chiar dacă sistemul nu funcționează niciodată defectuos, poate fi inadecvat. Camera funcționează bine, dar nu poate recunoaște o placă de zăpadă; Radarul este solid, dar ignoră un vehicul staționar ca un semnal fantomă. Nu există nicio defecțiune hardware/software aici; Problema se află la limita scopului prevăzut al funcției.

ISO 21448 - SOTIF (Safety Of The Intended Functionality) abordează exact acest decalaj: gestionarea riscurilor care decurg din scenarii nerecunoscute, limite de detectare și situații neprevăzute, chiar dacă sistemul funcționează așa cum a fost proiectat. În ADAS/conducerea autonomă bazată pe inteligență artificială, SOTIF este la fel de critic ca ISO 26262.

cadru

Concentrează-te

exemplu

ISO 26262

Risc din cauza eșecului

Senzorul se întrerupe, semnalul dispare

ISO 21448 (SOTIF)

Risc de inadecvare/nerecunoaștere

Camera robustă nu recunoaște placa de zăpadă

ISO/SAE 21434

securitate cibernetică

Atacul de sistem, manipularea datelor

Atenție: modelele AI sunt statistice; Ei nu pot garanta că vor „vedea corect fiecare situație”. SOTIF își propune să restrângă scenariile periculoase necunoscute în aceste sisteme limitate în mod inerent și să reducă riscul rămas la un nivel acceptabil. „Modelul are o precizie de 99,9%” nu este o dovadă de securitate.

ISO/SAE 21434: securitate cibernetică

Vehiculele conectate și definite de software sunt vulnerabile la atacurile cibernetice. Un atacator de la distanță poate modifica comanda de frânare, poate fura telemetria sau poate păcăli modelul de detectare (atac adversar: face ca modelul să-l recunoască greșit prin plasarea unui mic autocolant pe o farfurie). ISO/SAE 21434 este cadrul de inginerie pentru securitatea cibernetică a vehiculelor. În contextul inteligenței artificiale, se evidențiază două riscuri: înșelarea modelului (adversarial) și otrăvirea datelor de antrenament (data poisoning). Sistemele AI critice pentru securitate ar trebui testate împotriva acestor atacuri.

Confidențialitate și date personale

Vehiculul modern este un „centru de date pe roți”: locație, comportament de condus, sunet, chiar și cameră de cabină. Cele mai multe dintre acestea sunt date cu caracter personal și sunt acoperite de KVKK (Türkiye) și GDPR (Europa). VIN (numărul șasiului) poate identifica un vehicul și, indirect, proprietarul acestuia. Principii de bază:

  • Minimizarea datelor: Colectați doar ceea ce este necesar.
  • Limitarea scopului: Nu utilizați datele în alte scopuri decât scopul pentru care au fost colectate.
  • Anonimizare/pseudonimizare: eliminați sau codificați informațiile de identificare personală.
  • Consimțământ explicit și transparență: șoferul trebuie să știe ce se colectează.
  • Depozitare și transfer în siguranță.
Atenție: trimiterea unui VIN brut, a istoricului locațiilor sau a comportamentului de conducere către un instrument AI din cloud public poate fi atât o încălcare a confidențialității, cât și un risc contractual. Când lucrați cu aceste date, anonimizați-le și utilizați un mediu instituțional, protejat de date.

Etica și responsabilitatea inginerului

Inteligența artificială aduce cu ea câteva riscuri etice:

  • Prejudecăți: dacă datele de antrenament predomină în anumite condiții (de exemplu, în timpul zilei, piele deschisă la culoare, anumite drumuri regionale), modelul poate funcționa slab în condiții subreprezentate (noapte, condiții diferite). Aceasta este o vulnerabilitate.
  • Încredere excesivă (prejudecata de automatizare): Oamenii au încredere în automatizare și își depășesc propria judecată. Dacă inginerul de testare încetează să se uite la datele brute doar pentru că AI spune „trece”, aceasta este o tendință periculoasă.
  • Pierderea răspunderii: „Modelul a decis” nu este o apărare. Ar trebui să existe întotdeauna o persoană care semnează în spatele deciziei.

Mini studii de caz

Cazul 1 - limita SOTIF. Un sistem automat de frânare de urgență trece toate testele de laborator, fără defecțiuni. Pe câmp, în soarele scăzut, un camion alb își confundă remorca cu cerul și frână târziu. Aceasta nu este o defecțiune, ci o vulnerabilitate SOTIF: sistemul este intact, dar scenariul este în afara limitei de detectare. Echipa adaugă acest scenariu la biblioteca de teste și întărește fuziunea radarului. Concluzie: „Fără eșec” nu este dovada siguranței; Insuficiența este, de asemenea, un risc.

Cazul 2 - Date părtinitoare. Un model de detectare a pietonilor a fost antrenat predominant cu date de zi; Reamintirea nocturnă este semnificativ mai mică. Echipa echilibrează și reantrenează datele de noapte și de lumină slabă și raportează separat scenariile nocturne. Concluzie: Datele dezechilibrate creează o vulnerabilitate mortală în anumite circumstanțe.

Cazul 3 - Prevenirea încălcării confidențialității. Un analist este pe cale să lipească datele flotei într-un instrument public AI când observă că datele conțin locații brute VIN și GPS. Funcționează într-un mediu corporativ prin anonimizarea datelor (vehicle_01..arac_50 în loc de VIN, cod de regiune în loc de locație). Rezultat: Un moment de atenție a prevenit o încălcare gravă a KVKK.

șabloane prompte

Șablonul 1 - Evaluare prealabilă/risc (schiță):

Rol: Sunteți consultant în siguranță funcțională. Sarcină: Pregătește o schiță pentru a ajuta analiza pericolelor și riscurilor pentru o funcție. Context: Funcție: frânare automată de urgență; urban și intercity.Constrângere: atribuirea exactă a ASIL; Oferiți o listă de întrebări și puncte de atenție cu privire la dimensiunile de severitate/expunere/controlabilitate; indicați că sarcina finală revine inginerului de securitate autorizat.Ieșire: Mărime | întrebare de evaluare | tabel de note de atenție.

Șablonul 2 - Scanarea scenariului SOTIF:

Rol: Sunteți expert SOTIF. Sarcină: enumerați scenariile în care o funcție de detectare ar putea fi „sistemul intact, dar inadecvat”. Context: Cameră + radar; soare scăzut, zăpadă, ieșire din tunel, obiecte neobișnuite. Ieșire: Scenariu | de ce inadecvare | recomandare de reducere.

Șablon 3 - Controlul confidențialității:

Rol: Sunteți consultant în protecția datelor (KVKK/GDPR). Sarcină: Efectuați un audit de confidențialitate înainte de a partaja un set de date. Context: Telemetria flotei; Coloanele conțin VIN, GPS, scor de conducere. Constrângere: Ce câmpuri sunt date personale, cum ar trebui să fie anonimizate, ce nu ar trebui să împărtășesc deloc; sortare.Ieșire: Câmp | risc | diagramă de tranzacție recomandată.

Șablon 4 - Verificare părtinire:

Rol: Sunteți auditor de siguranță și corectitudine ML. Sarcină: Spuneți-mi cum să caut riscul de părtinire într-un model de detectare. Context: Detectarea pietonilor; datele de antrenament ponderate zi/oraș.Ieșire: Condiție de verificat | măsurare | semn de risc.

Prompt slab / Prompt puternic

Prompt slab:

Este sigur acest sistem de frânare autonom, confirmați.

Încercarea de a obține autorizația de securitate AI este periculoasă; Aprobarea aparține inginerului autorizat.

Solicitare puternică:

Rol: Sunteți consultant în siguranță funcțională și SOTIF. Sarcină: enumerați ce întrebări ar trebui să pun și ce dovezi ar trebui să adun în evaluarea siguranței funcției mele de frânare automată. Context: detectarea bazată pe inteligență artificială; camera+radar; ASIL poate fi ridicat. Constrângere: „Aprobați” sistemul; Furnizați liste separate de întrebări și dovezi în ceea ce privește ISO 26262 (defect) și SOTIF (deficiență); Subliniați că aprobarea finală revine inginerului de securitate autorizat. Ieșire: cadru | întrebare | tabelul de dovezi solicitate.

Greșeli comune

  • Confundând „fără defecțiune” cu „sigur”. Deficiența SOTIF poate ucide fără a funcționa defectuos.
  • Obținerea autorizației de securitate AI. Aprobarea și responsabilitatea revin inginerului autorizat.
  • Precizia modelului greșit ca dovadă de securitate. O acuratețe de 99,9% nu indică faptul că riscul rămas a fost gestionat.
  • Nu protejează datele personale. VIN/locația/comportamentul de conducere intră în domeniul de aplicare al KVKK/GDPR.
  • Ignorând părtinirea și excesul de încredere. Datele dezechilibrate și încrederea oarbă în automatizare sunt vulnerabilități.

Pe scurt

  • ISO 26262 gestionează riscul cauzat de defecțiune (cu ASIL), în timp ce ISO 21448/SOTIF gestionează riscul de defecțiune fără eșec; Ambele sunt critice în detectarea AI.
  • ISO/SAE 21434 securitate cibernetică; atacurile adverse și de otrăvire a datelor sunt amenințări specifice AI.
  • Minimizarea datelor, limitarea scopului și anonimizarea sunt obligatorii în domeniul de aplicare al KVKK/GDPR; VIN/locația sunt date personale.
  • Prejudecățile, excesul de încredere și pierderea responsabilității sunt principalele riscuri etice.
  • Ieșirea AI nu este un substitut pentru aprobarea inginerului calificat; Decizia și semnătura critică pentru securitate aparțin întotdeauna persoanei.

Sarcina de aplicare

Selectați o funcție legată de siguranță (de exemplu, menținerea benzii). (1) Discutați de ce nivelul ASIL al acestei funcții poate fi ridicat/scăzut de-a lungul dimensiunilor de severitate/expunere/controlabilitate. (2) Generați 5 scenarii „sistem solid, dar inadecvat” cu șablonul 2. (3) Auditul de confidențialitate a unui set de date relevant cu șablonul 3. (4) Explicați de ce a spune „Modelul confirmat” nu este o apărare.

lista de verificare

  • [ ] Am evaluat dimensiunile REALE ale funcției (am lăsat atribuția exactă autorității).
  • [ ] Am făcut distincția între ISO 26262 (defecțiune) și SOTIF (insuficiență).
  • [ ] Am luat în considerare riscul de securitate cibernetică (adversarial/otrăvire).
  • [ ] Am anonimizat și minimizat datele personale.
  • [ ] Am verificat pentru riscuri de părtinire și exces de încredere.
  • [ ] Am confirmat că autorizația de securitate este de la inginer calificat.