🚗 SEooC: продукт для автомобиля, которого еще нет 🧩

Как обеспечить функциональную безопасность по ISO 26262, если заранее неизвестно, в какой именно автомобиль попадет продукт?

Именно для этого в стандарте существует подход Safety Element out of Context (SEooC) — продукт вне контекста безопасности.

Система, чип или библиотека ПО создаются не под конкретное ТЗ заказчика, а на основе собственных гипотез и допущений.

🎯 Фундамент SEooC - допущения (Assumptions of Use)
Technical Safety Concept (TSC) в случае SEooC начинается не с «железа», а с допущений.

Разработчик обязан предположить:
▪️Assumed Safety Goals: какую цель безопасности на уровне автомобиля помогает достичь продукт.
▪️Assumed FSR: какие Functional Safety Requirements мог бы назначить OEM.

📌 Важно помнить:
ASIL Capability подтверждена только в рамках этих допущений.
Если проект выходит за их границы — это риск, который ложится на плечи интегратора.

📂 Что входит в Safety Manual
Чтобы разработчик устройства смог собрать свой Safety Case, вместе с SEooC-элементом передается Safety Manual — основной документ по интеграции элемента.

Для SEooC-System:
▪️Item Definition assumptions - границы и условия эксплуатации, на которые рассчитывал разработчик;
▪️стратегия Safe State - как элемент переходит в безопасное состояние, если что-то пошло не так.

Для SEooC-HW (например, MCU):
▪️FMEDA - расчет FIT-рейтов, метрик и эффективности диагностических мер;
▪️External Measures - перечень мер, которые должны быть реализованы снаружи, чтобы внутренние механизмы работали корректно.
Например:
внешний супервизор питания.

Для SEooC-SW (стеки, ОС):
▪️SWSR - Требования к софту и интерфейс HSI (Software Safety Requirements);
▪️ресурсный бюджет;
▪️Structural Coverage — доказательства полноты тестирования. Для ASIL D это MC/DC.

⚖️ Меры подтверждения: доверяй, но проверяй
Безопасность SEooC подтверждается не только заявлениями разработчика, но и отдельными отчетами по Confirmation Measures:
▪️Confirmation Reviews — подтверждение того, что TSC и FMEDA не содержат пробелов;
▪️Safety Audit Report — доказательство соответствия процессов разработки ISO 26262;
▪️Safety Assessment Report — итоговое заключение по безопасности.
📌 Для уровня ASIL D обычно привлекаются независимые эксперты уровня I3.

🤝 Нужен ли DIA?
Здесь есть важный нюанс.
Если поставляется готовый продукт из каталога (COTS), DIA обычно не требуется — условия уже описаны в Safety Manual.
Но если элемент дорабатывается совместно с заказчиком в рамках Distributed Development, DIA становится документом, который фиксирует зоны ответственности сторон.

🔍 Главная задача интегратора
При работе с SEooC особое внимание необходимо уделять разделу Assumptions.
Главная задача интегратора — провести Validation of Assumptions.

⚠️ Если допущения поставщика не совпадают с реальными условиями применения системы, Safety Case закрыть не получится.

Как вы считаете, что сложнее всего при интеграции SEooC-компонентов?

😃 [FTS] Экварта | Лицом к безопасности