Прибуток:
- Здатність пояснити функціональну безпеку ISO 26262 і структуру ISO 21448 (SOTIF) та їхній вплив на системи, що містять штучний інтелект.
- Здатність керувати конфіденційністю даних, даними водія, кібербезпекою (ISO/SAE 21434) та етичними ризиками в автомобільному контексті
- Здатність підтримувати людську відповідальність за критично важливі для безпеки рішення, розуміючи, що результати ШІ не замінюють схвалення компетентного інженера
Ви знаходитесь у найбільш критичному підрозділі цього модуля. До цього часу ми розглядали ШІ як прискорювач від проектування до виробництва, від тестування до ланцюга постачання. Але вирішальне питання в автомобілебудуванні: чи зашкодить ця система комусь і хто буде відповідальний? У цьому розділі простою мовою розглядаються основи відповідального використання штучного інтелекту в критично важливих для безпеки галузях — функціональна безпека, SOTIF, кібербезпека, конфіденційність і етика. Основний принцип залишається незмінним: результат штучного інтелекту ніколи не замінює схвалення компетентного інженера; Критично важливі для безпеки рішення та відповідальність належать людині.
ISO 26262: функціональна безпека
ISO 26262 є стандартом функціональної безпеки для електричних/електронних систем дорожніх транспортних засобів. Функціональна безпека; Це пов’язано з тим, щоб у разі збою системи (поломка датчика, збій програмного забезпечення) це не призвело до небезпечної ситуації.
В основі цього стандарту лежить ASIL (рівень цілісності автомобільної безпеки). Небезпека оцінюється в трьох вимірах:
- Важкість: Наскільки погано було б, якби це сталося? (легкі травми або смерть)
- Вплив: як часто це відбувається?
- Керованість: наскільки водій може контролювати ситуацію?
Ці три об’єднані призводять до рівня від ASIL A (найнижчий) до ASIL D (найвищий, наприклад, гальмування, рульове керування). З підвищенням рівня вимоги до розробки, тестування та документації стають суворішими.
ГОЛОВНА
вибіркова система
Інтенсивність вимог
А.
Несправність внутрішнього освітлення
низький
Б.
заднє світло
середній
C.
Деякі функції ADAS
висока
Д.
Гальма, рульове управління, подушка безпеки
найвищий
Порада. Знання ГОЛОВНОГО рівня функції показує, скільки уваги потребує використання штучного інтелекту в цій функції. ЖОДНЕ рішення, засноване на результатах ШІ у функції, не може бути прийнято без незалежної перевірки безпеки.
ISO 21448 (SOTIF): безпека призначеної функції
Класична функціональна безпека (ISO 26262) зосереджується на питанні "що станеться, якщо система виходить з ладу?" Але є нова проблема в системах виявлення штучного інтелекту: навіть якщо система ніколи не дає збоїв, вона може бути неадекватною. Камера працює добре, але не може розпізнати засніжену плиту; Радар надійний, але він ігнорує нерухомий автомобіль як привидений сигнал. Тут немає збою апаратного/програмного забезпечення; Проблема знаходиться на межі передбачуваного обсягу функції.
ISO 21448 – SOTIF (Safety Of The Intended Functionality) усуває саме цю прогалину: управління ризиками, що виникають через нерозпізнані сценарії, межі виявлення та непередбачені ситуації, навіть якщо система працює, як задумано. У ADAS/автономному керуванні на основі ШІ SOTIF є таким же критичним, як і ISO 26262.
рамка
Фокус
приклад
ISO 26262
Ризик через невдачу
Датчик ламається, сигнал пропадає
ISO 21448 (SOTIF)
Ризик неадекватності/невизнання
Міцна камера не розпізнає снігову плиту
ISO/SAE 21434
кібербезпека
Системна атака, маніпулювання даними
Застереження: моделі ШІ є статистичними; Вони не можуть гарантувати, що будуть «правильно бачити кожну ситуацію». SOTIF має на меті звузити коло невідомих небезпечних сценаріїв у цих за своєю суттю обмежених системах і знизити ризик, що залишився, до прийнятного рівня. «Точність моделі на 99,9%» не є доказом безпеки.
ISO/SAE 21434: кібербезпека
Підключені та програмно визначені транспортні засоби вразливі до кібератак. Віддалений зловмисник може змінити команду гальмування, викрасти телеметрію або обдурити модель виявлення (змагальна атака: змусити модель неправильно розпізнати її, розмістивши маленьку наклейку на пластині). ISO/SAE 21434 — це інженерна основа для кібербезпеки транспортних засобів. У контексті штучного інтелекту виділяють два ризики: оману моделі (конкурентний) і отруєння навчальних даних (отруєння даних). Системи штучного інтелекту, які є критично важливими для безпеки, повинні бути протестовані проти цих атак.
Конфіденційність і особисті дані
Сучасний транспортний засіб — це «дата-центр на колесах»: розташування, поведінка за кермом, аудіосистема, навіть камера в салоні. Більшість із них є персональними даними, на які поширюється дія KVKK (Туреччина) та GDPR (Європа). VIN (номер шасі) може ідентифікувати транспортний засіб і опосередковано його власника. Основні принципи:
- Мінімізація даних: збирайте лише те, що необхідно.
- Обмеження за призначенням: не використовуйте дані для інших цілей, окрім тих, для яких вони були зібрані.
- Анонімізація/псевдонімізація: видалення або кодування особистої інформації.
- Чітка згода та прозорість: водій повинен знати, що збирається.
- Безпечне зберігання та передача.
Застереження: надсилання необробленого VIN-коду, історії місцезнаходжень або поведінки за кермом у загальнодоступний хмарний інструмент ШІ може бути як порушенням конфіденційності, так і контрактним ризиком. Працюючи з цими даними, зробіть їх анонімними та використовуйте інституційне середовище, захищене даними.
Етика та відповідальність інженера
Штучний інтелект несе з собою деякі етичні ризики:
- Зміщення: якщо навчальні дані переважають у певних умовах (наприклад, удень, світла шкіра, певні регіональні дороги), модель може працювати погано в недостатньо представлених умовах (ніч, інші умови). Це вразливість.
- Надмірна впевненість (упередженість автоматизації): люди сліпо довіряють автоматизації та ігнорують власні судження. Якщо інженер-випробувач перестає переглядати необроблені дані лише тому, що штучний інтелект каже «пройшло», це небезпечна тенденція.
- Втрата відповідальності: «Модель вирішила» не є захистом. Під рішенням завжди має стояти підпис.
Міні кейси
Випадок 1 – обмеження SOTIF. Система автоматичного екстреного гальмування пройшла всі лабораторні випробування, без збоїв. У полі, під низьким сонцем, біла вантажівка переплутає причеп із небом і запізно гальмує. Це не несправність, а вразливість SOTIF: система неушкоджена, але сценарій виходить за межі виявлення. Команда додає цей сценарій до тестової бібліотеки та посилює радіолокаційний синтез. Висновок: «Відсутність збою» не є доказом безпеки; Недостатність також є ризиком.
Випадок 2 - Неправдиві дані. Модель виявлення пішоходів була навчена переважно з денними даними; Згадування вночі значно нижче. Команда балансує та перенавчає нічні та слабкі дані та звітує про нічні сценарії окремо. Висновок: незбалансовані дані за певних обставин створюють смертельну вразливість.
Випадок 3 – Запобігання порушенню конфіденційності. Аналітик збирається вставити дані про автопарк у загальнодоступний інструмент штучного інтелекту, коли помічає, що дані містять необроблені номери VIN і GPS. Він працює в корпоративному середовищі шляхом анонімізації даних (vehicle_01..arac_50 замість VIN, код регіону замість місцезнаходження). Результат: Хвилинка уваги попередила серйозне порушення КВКК.
шаблони підказок
Шаблон 1 - ПОПЕРЕДНЯ/попередня оцінка ризику (проект):
Посада: Ви консультант з функціональної безпеки. Завдання: Готує чернетку для допомоги в аналізі небезпек і ризиків для функції. Контекст: Функція: автоматичне екстрене гальмування; міський та міжміський. Обмеження: точне призначення ASIL; Надайте перелік питань і пунктів, на які слід звернути увагу, щодо параметрів серйозності/впливу/контрольованості; вказують, що остаточне призначення належить уповноваженому інженеру безпеки. Вихід: розмір | питання оцінки | таблиця приміток уваги.
Шаблон 2 - сканування сценарію SOTIF:
Роль: Ви експерт SOTIF. Завдання: перелічіть сценарії, коли функція виявлення може бути «система непошкодженою, але невідповідною». Контекст: камера + радар; низьке сонце, сніг, вихід з тунелю, незвичайні об'єкти. Результат: Сценарій | чому неадекватність | рекомендація щодо скорочення.
Шаблон 3 – Контроль конфіденційності:
Посада: Ви консультант із захисту даних (KVKK/GDPR). Завдання: проведіть перевірку конфіденційності перед тим, як надати спільний доступ до набору даних. Контекст: телеметрія флоту; Стовпці містять VIN, GPS, рейтинг водіння. Обмеження: які поля є особистими даними, як вони мають бути анонімними, які я не повинен ділитися взагалі; сортування. Вихід: Поле | ризик | рекомендована діаграма транзакцій.
Шаблон 4 – Перевірка упередженості:
Роль: Ви аудитор безпеки та справедливості ML. Завдання: Скажіть мені, як шукати ризик зміщення в моделі виявлення. Контекст: виявлення пішоходів; дані навчання, зважені день/місто. Результат: Умова для перевірки | вимірювання | знак ризику.
Слабка підказка / Сильна підказка
Слабка підказка:
Чи безпечна ця система автономного гальмування, підтвердьте.
Спроба отримати дозвіл ШІ небезпечна; Схвалення належить уповноваженому інженеру.
Потужна підказка:
Роль: Ви консультант із функціональної безпеки та SOTIF. Завдання: перелічіть, які запитання я маю поставити та які докази я маю зібрати під час оцінки безпеки моєї функції автоматичного гальмування. Контекст: виявлення на основі ШІ; камера+радар; ASIL може бути високим. Обмеження: «Схвалити» систему; Надайте окремі списки запитань і доказів щодо ISO 26262 (дефект) і SOTIF (дефіцит); Підкресліть, що остаточне схвалення належить уповноваженому інженеру безпеки. Результат: Framework | питання | таблиця необхідних доказів.
Поширені помилки
- Плутаючи «відсутність несправності» з «безпечно». Дефіцит SOTIF може вбити без збоїв.
- Отримання дозволу безпеки ШІ. Схвалення та відповідальність несе уповноважений інженер.
- Помилкова точність моделі як доказ безпеки. Точність 99,9% не вказує на те, що рештою ризику вдалося керувати.
- Не захищає персональні дані. Ідентифікаційний номер/місце розташування/поведінка підпадає під дію KVKK/GDPR.
- Ігнорування упередженості та надмірної самовпевненості. Незбалансовані дані та сліпа довіра до автоматизації є вразливими місцями.
Підсумовуючи
- ISO 26262 керує ризиком через збій (за допомогою ASIL), тоді як ISO 21448/SOTIF керує ризиком збою без збою; Обидва є критично важливими для виявлення ШІ.
- ISO/SAE 21434 кібербезпека; Конкурентні атаки та атаки з отруєнням даних є специфічними загрозами ШІ.
- Мінімізація даних, обмеження цілей та анонімізація є обов’язковими в рамках KVKK/GDPR; VIN/місцезнаходження є персональними даними.
- Упередження, надмірна самовпевненість і втрата відповідальності є основними етичними ризиками.
- Результати ШІ не замінюють схвалення кваліфікованого інженера; Важливе для безпеки рішення та підпис завжди належать людині.
Аплікаційне завдання
Виберіть функцію безпеки (наприклад, утримання в смузі руху). (1) Обговоріть, чому рівень ASIL цієї функції може бути високим/низьким за параметрами тяжкості/експозиції/контрольованості. (2) Згенеруйте 5 сценаріїв «надійної, але неадекватної системи» за допомогою Шаблону 2. (3) Аудит конфіденційності відповідного набору даних за допомогою Шаблону 3. (4) Поясніть, чому слова «Модель підтверджено» не є захистом.
контрольний список
- [ ] Я оцінив ФАКТИЧНІ розміри функції (я залишив точне призначення органу).
- [ ] Я зробив різницю між ISO 26262 (несправність) і SOTIF (недостатність).
- [ ] Я взяв до уваги ризик кібербезпеки (конфлікт/отруєння).
- [ ] Я анонімізував та мінімізував особисті дані.
- [ ] Я перевірив ризики упередженості та надмірної впевненості.
- [ ] Я підтвердив, що дозвіл безпеки надано кваліфікованим інженером.