Многие автомобильные компании сталкиваются с распространенной проблемой при проведении аудитов по стандарту ISO 26262. Они определяют высокоуровневые цели безопасности (ЦББ). Они устанавливают интервал времени отказоустойчивости (ВТО). Однако во время оценки безопасности их техническая документация оказывается несостоятельной.
Почему это происходит? Причина кроется в переходе между требованиями функциональной безопасности (FSR) и требованиями технической безопасности (TSR).
Когда связь между высокоуровневыми функциональными концепциями и низкоуровневой инженерной реализацией слаба, команды сталкиваются с трудностями. Требования остаются расплывчатыми, физические параметры отсутствуют, и возникают логические пробелы. Это приводит к провалу тестов, перепроектированию на поздних этапах и задержкам запуска продукта.
В этом руководстве подробно описана стандартная четырехэтапная схема преобразования абстрактных целей безопасности в четкие, проверяемые и программируемые технические спецификации. Мы будем использовать реальный сценарий защиты от перезаряда батареи уровня ASIL-D, чтобы показать, как это работает в производственной среде.
Table of Contents
FSR против TSR: ключевое различие
Многие инженеры используют эти термины как синонимы. На самом деле они различны и обозначают разные уровни проектирования системы. Один определяет границы, другой — реализацию.
Требования к функциональной безопасности (FSR): что должна делать система.
Показатель FSR напрямую вытекает из основных целей безопасности. Это функциональное требование.
- Технологически нейтральный подход: В нем не указаны конкретные микросхемы, микроконтроллеры или коммуникационные шины.
- Поведенческий подход: В нем указаны условия срабатывания, необходимые действия системы и безопасное состояние.
- Ограничено по времени: Это напрямую связано с общей сетью FTTI.
- Пример: В случае перенапряжения в ячейке батареи система должна отключить цепь зарядки внутри FTTI, чтобы предотвратить тепловой разгон.
Технические требования безопасности (ТСБ): как их внедрить
TSR переводит FSR в инженерные термины. После выбора архитектуры системы вы пишете TSR для описания деталей реализации аппаратного и программного обеспечения, диагностики и связи.
- Специфика технологии: Оно напрямую подключается к вашим микроконтроллерам, аналоговым интерфейсам (AFE) и протоколам.
- Высококачественный количественный анализ: Он определяет интервалы выборки, допуск измерения, циклы выполнения и аппаратные выводы.
- Полностью проверяемо: Каждый TSR должен быть непосредственно тестируем с помощью аппаратного моделирования (HIL), внедрения ошибок или модульного тестирования программного обеспечения.
- Пример: Интерфейсный модуль должен измерять напряжение ячейки каждые 10 мс с точностью ±5 мВ, а микроконтроллер должен инициировать размыкание контакторов высоковольтного драйвера в течение 50 мс после обнаружения неисправности.
Четырехэтапная модель трансформации
При составлении отчетов TSR вам не нужно полагаться на догадки. Следование этому структурированному процессу гарантирует соответствие стандартам без каких-либо пробелов.
Шаг 1: Разбор FSR
Прежде чем составлять технические требования, разделите ваши FSR на четыре основных элемента:
- Условие срабатывания: Конкретная неисправность или сценарий, активирующий функцию безопасности.
- Основное действие: Физическая реакция системы.
- Ограничение по времени: Максимально допустимый временной интервал для получения ответа, рассчитанный на основе данных FTTI.
- Безопасное состояние: Окончательное, стабильное состояние системы после устранения неисправности (например, полная блокировка или самовосстановление).
Шаг 2: Сопоставление с архитектурой
Изучите архитектуру аппаратного и программного обеспечения вашей системы управления батареями (BMS). Назначьте каждую функцию безопасности определенному физическому уровню:
- Сенсорный слой: Аналоговые интерфейсные элементы, делители напряжения и датчики тока.
- Слой обработки: Основные микроконтроллеры и средства контроля безопасности.
- Уровень управления: Драйверы контакторов, переключатели и цепи предварительной зарядки.
- Уровень связи: CAN-трансиверы и внутренние шины SPI.
Шаг 3: Разработка технических требований (ТС)
Для каждого компонента, определенного на шаге 2, составьте конкретные технические задания (TSR) по этим четырем ключевым областям проектирования:
- Производительность и время: Разбейте общую схему FTTI на бюджет. Назначьте максимальные пределы задержки для датчика, программной логики и физических исполнительных механизмов.
- Механизмы безопасности: Добавьте средства диагностики и аппаратное резервирование для выявления неисправностей в одной точке.
- Требования к оборудованию: Укажите аппаратные характеристики, показатели безопасности и конфигурации сторожевого таймера.
- Интерфейсы и состояния: Определите правила защиты связи, обработки ошибок и восстановления.
Шаг 4: Обеспечение двусторонней прослеживаемости
Сопоставьте каждый регистр TSR с его исходным регистром FSR и убедитесь, что каждому регистру FSR соответствуют соответствующие регистры TSR. Такое сопоставление предотвращает две основные инженерные проблемы:
- Требования к подвешиванию: FSR, которым не хватает технической реализации.
- Золотое покрытие: TSR-файлы, которые добавляют ненужную аппаратную или программную сложность, не обеспечивая при этом безопасность родителей.
Пример из практики: защита от перезаряда батареи ASIL-D
Применим эту четырехэтапную схему к типичной функции безопасности системы управления зданием (BMS).
Базовый уровень целевого показателя безопасности
- Цель безопасности (ЦБ): Предотвратите тепловой разгон элементов батареи из-за перезарядки.
- Рейтинг ASIL: АСИЛ-Д
- FTTI: 100 мс
1. Требования к функциональной безопасности (ТФБ)
- FSR-02.01: Когда система управления батареей (BMS) обнаруживает напряжение на каком-либо элементе, превышающее 4,5 В, она должна отключить цепь зарядки в течение 100 мс и перейти в зафиксированное безопасное состояние.
- FSR-02.02: Система управления батареей (BMS) должна контролировать собственное оборудование для измерения напряжения. В случае обнаружения ошибки выборки она должна отключить цепь зарядки в течение 500 мс, чтобы избежать неконтролируемого перезаряда.
2. Технические требования безопасности (ТСБ)
Производительность и время TSR
- TSR-P1: Аналоговый интерфейсный модуль (AFE) должен завершить полный цикл измерения напряжения элемента в течение 10 мс. (Трассировка соответствует: FSR-02.01, FSR-02.02)
- TSR-P2: Погрешность измерения напряжения должна оставаться в пределах ±5 мВ во всем диапазоне рабочих температур и в течение всего срока службы изделия. (Соответствует стандарту FSR-02.01)
- TSR-P3: Программное обеспечение микроконтроллера должно обработать данные о напряжении, выполнить алгоритм защиты от перенапряжения и записать команду выключения в выходной регистр менее чем за 20 мс. (Трассировка: FSR-02.01)
- ТСР-П4: Аппаратная схема управления и контакторы должны физически разомкнуть и устранить дуговой разряд в течение 50 мс после получения команды от микроконтроллера. (Трассировка по: FSR-02.01)
Проверка бюджета по срокам: $$\text{Общее время цикла} = 10\text{мс (считывание)} + 20\text{мс (обработка)} + 50\text{мс (срабатывание)} = 80\text{мс}$$
Поскольку 80 мс меньше, чем 100 мс FTTI, конструкция оставляет безопасный запас в 20 мс.
Механизм безопасности TSRs
- ТСР-М1: Реализуйте двухканальный механизм завершения работы. Основной канал использует управление программным обеспечением главного микроконтроллера. Вторичный канал использует аппаратный компаратор на плате AFE для непосредственного срабатывания защитного выключателя, обхода программного обеспечения микроконтроллера и защиты от зависания процессора. (Ссылки на: FSR-02.01, FSR-02.02)
- ТСР-М2: Программное обеспечение микроконтроллера должно проверять исходные показания напряжения на каждом цикле. Любое значение, выходящее за пределы диапазона от 2,0 В до 5,0 В, должно быть помечено как аномальное для выявления залипания регистров АЦП. (Ссылка на: FSR-02.02)
- ТСР-М3: Микросхема AFE должна периодически выполнять внутреннюю диагностику, включая проверку опорного напряжения и обнаружение обрыва провода, сообщая о любых неисправностях микроконтроллеру в течение 50 мс. (Трассировка: FSR-02.02)
- ТСР-М4: Система должна считывать сигналы обратной связи высоковольтных контакторов для контроля за свариванием контактов. Если сигнал обратной связи не соответствует команде драйвера, активируйте резервный путь изоляции. (Ссылка на: FSR-02.01)
Требования к оборудованию TSR
- TSR-H1: Основной микроконтроллер безопасности должен соответствовать стандартам ASIL-D и включать аппаратные ядра с синхронизацией, блок защиты памяти (MPU) и защиту ECC для ОЗУ и флэш-памяти. (Ссылки на: FSR-02.01, FSR-02.02)
Интерфейс и состояние TSR
- ТСР-И1: Кадр шины CAN, содержащий команду отключения зарядки, должен использовать сквозную защиту (E2E), включая скользящий счетчик и CRC, для предотвращения повреждения данных или потери кадра. (Трассировка: FSR-02.01)
- TSR-I2: При возникновении перенапряжения система управления зданием (BMS) должна навсегда заблокировать систему в безопасном состоянии. Автоматическое восстановление не допускается. Система должна оставаться отключенной до тех пор, пока не будет выполнена диагностика авторизованным сервисным специалистом. (Ссылка на документ: FSR-02.01)
Вывод из инженерного анализа
Преобразование FSR в TSR — это не административная задача. Это ключевая часть проектирования системной и программной архитектуры.
Для руководителей проектов этот перевод определяет инженерные задачи и объем тестирования. Для разработчиков аппаратного обеспечения он устанавливает требования к компонентам и пути защиты. Для инженеров-программистов он определяет время выполнения циклов, конфигурацию памяти и стратегии диагностики.
Отказавшись от неструктурированного текста и используя систематический четырехэтапный метод, ваша команда сможет создавать системы безопасности, которые легко тестировать, готовы к внедрению в производство и соответствуют требованиям аудита ISO 26262.
Краткий раздел часто задаваемых вопросов (с учетом географического положения)
В1: В чем основное различие между FSR и TSR в стандарте ISO 26262?
Отвечать: FSR определяет требуемое поведение в плане безопасности на функциональном уровне без выбора конкретной технологии (что делает система). TSR определяет, как реализовать это поведение с использованием конкретного оборудования, программного обеспечения и параметров в рамках выбранной архитектуры системы (как это делается).
В2: Как FTTI соотносится с требованиями к синхронизации TSR?
Отвечать: FTTI устанавливает общий лимит времени для реагирования на инцидент безопасности. TSR должны разбить этот общий временной бюджет на более мелкие, измеримые пределы для отдельных этапов, включая выборку данных с датчиков, обработку данных микроконтроллером и перемещение исполнительных механизмов.
В3: Почему двусторонняя прослеживаемость имеет решающее значение для соответствия стандарту ASIL-D?
Отвечать: Прослеживаемость доказывает аудиторам, что ваши требования безопасности выполнены полностью. Она показывает, что каждое требование функциональной безопасности высокого уровня имеет реальную, проверенную техническую реализацию, и что в вашей критически важной для безопасности системе отсутствует непроверенный или избыточный код.




