Table of Contents

Расширяющаяся сложность автомобильных платформ

Современные транспортные средства эволюционировали от механических систем, управляемых простыми микроконтроллерами, до распределенных вычислительных платформ, работающих на десятках электронных блоков управления (ECU). Высокопроизводительные транспортные средства теперь содержат более 100 миллионов строк кода, охватывающих несколько операционных систем, стеков промежуточного программного обеспечения и прикладных слоев. Это программное обеспечение работает на разнородном оборудовании - от недорогих микроконтроллеров, управляющих оконными подъемниками, до высокопроизводительных систем на чипах (SoC), выполняющих обнаружение объектов в реальном времени для автономного вождения. Проверка этих систем требует методов, которые могут справиться с экспоненциальными пространствами состояний, одновременным выполнением через распределенные узлы и строгими требованиями безопасности, которые не оставляют места для неуправляемых краевых случаев. По мере того, как архитектуры транспортных средств движутся к зональным и централизованным конструкциям, сложность взаимодействий между компонентами резко возрастает, требуя стратегий проверки, которые масштабируются с системной интеграцией.

Неоднородные домены обработки

Одна архитектура транспортного средства может интегрировать микроконтроллеры (MCU), работающие на AUTOSAR Classic, высокопроизводительные SoC со встроенными графическими процессорами для вывода ИИ и программируемые в полевых условиях массивы затворов (FPGA) для обработки сигналов с низкой задержкой. Каждый элемент обработки работает под различными моделями памяти, тактовыми доменами и неисправностями. Проверка целостности данных через кэш-когерентные межсоединения, обеспечение того, чтобы передача прямого доступа к памяти (DMA) не повреждала критически важные буферы, и доказательство того, что межпроцессорная связь отвечает срокам проверки, все требуют специализированных методов проверки. Например, контроллеру системы поддержки драйверов (ADAS) может потребоваться слияние данных с датчика камеры, обработанного на SoC, с радиолокационными данными, обработанными на выделенном MCU. Любое несоответствие в временной штамповке или сериализации данных может привести к неправильному моделированию окружающей среды, потенциально вызывая фантомное торможение или упущенное препятствие. Инженеры должны использовать среды

Многоуровневые программные стекы

Сложность программного обеспечения в автомобильных системах распространяется на несколько уровней абстракции. В основе операционная система реального времени (RTOS) или гипервизор управляет аппаратными ресурсами и обеспечивает пространственную и временную изоляцию. Выше этого промежуточное ПО, такое как AUTOSAR Adaptive или служба распределения данных (DDS), обеспечивает сервисно-ориентированную связь по IP-сетям. Функции приложений, начиная от электронного контроля стабильности до автоматического удержания полосы, выполняются как распределенные задачи. Проверка должна подтвердить, что гипервизор правильно распределяет память и время процессора, что стек промежуточного программного обеспечения не вводит неограниченные задержки и что прикладные задачи уважают свои сроки при всех заданных условиях нагрузки. Проблема заключается в том, что ошибки часто возникают на границах между этими уровнями. Неправильный протокол приоритетного наследования в ОС может привести к блокировке задачи критического торможения безопасности в процессе информационно-развлекательного обеспечения. Инструменты перекрестного критического торможения, которые проверяют контракты интерфейса и бюджеты использования ресурсов,

Конкурентность и распределенная функциональность

Функции транспортного средства по своей природе распределены. Один маневр, такой как автономное изменение полосы, требует координации между датчиками восприятия, центральным блоком планирования, приводами рулевого управления питанием и электронным контроллером стабильности. Эти компоненты взаимодействуют через гетерогенные шинные системы, включая CAN FD, FlexRay и автомобильный Ethernet с чувствительными ко времени сетями (TSN). Каждая сеть имеет различные задержки, механизмы отказоустойчивости и свойства синхронизации. Проверка того, что запрос на изменение полосы движения распространяется по всей цепочке в детерминистическом временном окне, даже при перегрузке сети или отказе узла, требует строгого сквозного анализа времени. Режимы отказов и анализ эффектов (FMEA) должны быть расширены для покрытия ошибок сетевого уровня, таких как потеря сообщений, условия отключения и дрейф синхронизации между кластерами, спровоцированными временем. Подходы, основанные на моделе систем, в сочетании с формальной верификацией времени графиков связи, все чаще применяются для гарантии того, что

Навигационные стандарты безопасности и нормативные мандаты

Правила функциональной безопасности и кибербезопасности составляют основу встраиваемой автомобильной проверки. Стандарты, такие как ISO 26262 для функциональной безопасности и ISO 21434 для кибербезопасности определяют всесторонние жизненные циклы разработки, которые требуют тщательного анализа, проектирования и проверки. Соблюдение этих стандартов не является обязательным — это необходимое условие для омологации транспортных средств на основных рынках во всем мире. Глубина требуемых доказательств увеличивается с каждым уровнем целостности безопасности, требуя систематического подхода к управлению требованиями, прослеживаемости и валидации.

Глубина проверки ASIL D

Системы, которым присвоен самый высокий уровень целостности безопасности автомобиля (ASIL D), такие как рулевое управление или тормозное управление, требуют самой строгой проверки. Инженеры должны продемонстрировать, что одноточечные и латентные показатели неисправности превышают определенные пороговые значения (например, > 99% покрытия для одноточечных неисправностей). Это достигается посредством систематических кампаний впрыска неисправностей как на аппаратном, так и на программном уровнях. Неисправности, такие как битовые перевертывания в памяти, застрявшие неисправности в входах датчиков и нарушения времени в коммуникационных каналах, должны быть вставлены и проверена реакция системы. Трудность заключается в поддержании приемлемого покрытия неисправностей без исчерпывающего перечисления неисправностей. Такие методы, как статистический впрыск неисправностей и анализ распространения неисправностей, используются для оценки покрытия, но они требуют тщательной проверки. Автоматизированные рамки впрыска неисправностей, которые интегрируются с испытательными стендами HIL, позволяют повторять и масштабировать кампании,

Создание согласованного дела о безопасности

Помимо тестирования, ISO 26262 требует создания кейса безопасности — структурированного аргумента о том, что система приемлемо безопасна. Этот аргумент должен быть подкреплен доказательствами, включая анализы опасностей, системные спецификации, проектные документы и отчеты о проверке. Отслеживание должно поддерживаться от каждого требования безопасности посредством его реализации до соответствующего результата испытаний. На практике поддержание этой прослеживаемости через сотни тысяч артефактов является серьезной проблемой. На практике сохранение этой прослеживаемости через сотни тысяч артефактов является серьезной проблемой. Изменения в одном компоненте могут аннулировать аргументы безопасности в другом месте, требуя непрерывного анализа воздействия и проверки регрессии. Автоматизация через инструменты управления требованиями имеет важное значение, но семантические связи между артефактами должны быть вручную рассмотрены и подтверждены, что делает это ресурсоемким усилием. Цифровые нити подходы, которые соединяют инженерные данные на протяжении жизненного цикла набирают силу, предлагая автоматизированный анализ прослеживаемости и воздействия, но они требуют согласованных стандартов данных и организационных обязательств.

Безопасность предполагаемой функциональности (SOTIF)

ISO 21448, также известный как Безопасность предполагаемой функциональности (SOTIF), расширяет проверку за пределы аппаратных ошибок для устранения ограничений в самой функциональности. Это особенно актуально для систем, которые полагаются на машинное обучение или сложную обработку датчиков. Например, система обнаружения пешеходов может не обнаружить человека, носящего необычную одежду, не из-за аппаратной ошибки, но потому, что данные обучения не охватывают этот сценарий. Проверка SOTIF требует идентификации условий запуска - крайних случаев, когда поведение системы небезопасно из-за ограничений производительности. Методологии включают тестирование на основе сценария, анализ покрытия области оперативного проектирования (ODD) и статистическую проверку производительности восприятия в различных условиях окружающей среды. Проблема заключается в том, что количество потенциальных условий запуска бесконечно, делая невозможной полноту. Инженеры должны расставлять приоритеты на основе риска и использовать структурированные исследования для обнаружения критических пробелов. Инструменты генерации сценариев с использованием комбинаторного тестирования или генеративных состязательных сетей появляются для систематического покрытия пространства ODD, хотя они требуют тщательной калибровки, чтобы избежать нере

Интеграция аппаратного и программного обеспечения и Co-Verification

Интерфейс между аппаратным и программным обеспечением является постоянным источником тонких и катастрофических ошибок. Неправильная конфигурация регистра прошивки, переходное напряжение без управления, повреждающее считывание датчика, или событие теплового дросселирования, которое сдвигает время выполнения, могут привести к сбоям, которые остаются скрытыми до тех пор, пока система не будет работать в полевых условиях. Эффективная проверка интеграции требует многоуровневого подхода, который постепенно создает реализм, от ранних виртуальных прототипов до окончательного тестирования оборудования в цикле.

Цепочка проверки MIL, SIL и HIL

Проверка Model-in-the-Loop (MIL) фокусируется на правильности алгоритма управления в моделируемой среде установки. Тестирование программного обеспечения в петле (SIL) запускает производственный код на главном компьютере, позволяя проводить высокопроизводительное регрессионное тестирование. Тестирование аппаратного обеспечения в петле (HIL) соединяет реальный ECU с моделированием транспортного средства и его среды, позволяя выполнять в реальном времени с возможностями впрыска неисправностей. Каждый шаг раскрывает различные классы проблем. MIL может выявлять логические ошибки в законах управления, SIL может обнаруживать ошибки реализации программного обеспечения, и HIL подтверждает, что программное обеспечение работает правильно на целевом оборудовании при реалистичных сроках и электрических условиях. Разрыв между SIL и HIL может указывать на то, что программное обеспечение взаимодействует с периферийными устройствами аппаратного обеспечения неожиданным образом - например, рутина обслуживания прерываний, которая занимает больше времени, чем ожидалось, из-за раздора шины, вызывая нарушение времени. Непрерывные методы интеграции , которые автоматизируют тесты MIL, S

Виртуальные платформы для ранней интеграции

Для того чтобы сместить верификацию раньше в цикле разработки, OEM-производители и поставщики все чаще принимают виртуальные платформы. Это программные модели полной аппаратной платы, которые могут выполнять целевой код до того, как будет доступен физический кремний. Виртуальные платформы позволяют детерминированное воспроизведение сложных взаимодействий и поддерживают крупномасштабное автоматизированное тестирование. Задача заключается в достижении достаточной точности в модели — неточные модели времени контроллеров памяти, кэша или шинных арбитров могут маскировать реальные проблемы. Инженеры должны постоянно калибровать модели виртуальной платформы против физических аппаратных измерений, чтобы гарантировать, что результаты проверки заслуживают доверия. Появление стандартных интерфейсов виртуальной платформы, таких как основанные на SystemC TLM-2.0 , улучшает совместимость и точность модели. В сочетании с формальный анализ уровней передачи регистров (RTL) конструкций , виртуальные платформы могут помочь выявить проблемы интеграции, которые иначе появлялись бы только во время тестирования HIL.

Интерфейс и проверка целостности сигнала

Аппаратно-программные интерфейсы определяются регистрами, линиями прерываний и разделяемыми областями памяти. Неправильная структура данных, условия гонки на общих буферах и неправильная синхронизация часто появляются только при определенных переплетениях событий аппаратного и программного обеспечения. Статические инструменты анализа, которые обеспечивают соблюдение контрактов интерфейса, такие как обеспечение того, что программное обеспечение соблюдает минимальное и максимальное время доступа к регистру, необходимы. Кроме того, проверка целостности сигнала на аппаратном уровне, включая анализ перекрестных сигналов, шума питания и электромагнитных помех, должна быть согласована с анализом времени программного обеспечения, чтобы гарантировать, что предельные электрические условия не вызывают повреждение данных, которые программное обеспечение не может обнаружить или обрабатывать. Среды смешанного сигнала, которые сочетают моделирование аналоговых схем с цифровой логикой и встроенным программным обеспечением становятся необходимыми для критически важных интерфейсов, таких как считывания датчиков и приводы привода.

Обеспечение детерминистского поведения в реальном времени

Критические для безопасности функции предъявляют строгие требования к срокам, часто измеряемым в микросекундах. Пропущенный срок для команды вмешательства в тормоза является нарушением безопасности. Проверка того, что система отвечает всем временным ограничениям в худших условиях, является одним из самых сложных аспектов автомобильной встроенной проверки. Тенденция к многоядерным процессорам еще больше усложняет анализ времени из-за борьбы за общие ресурсы.

Время исполнения наихудшего дела (WCET)

Современные процессоры с глубокими трубопроводами, предсказанием ветвей и общими кэшами чрезвычайно затрудняют жесткое связывание времени выполнения. Анализ времени на основе измерений зависит от качества используемых векторов тестирования; патологические случаи могут быть пропущены. Статические инструменты анализа WCET выводят границы, анализируя двоичный код против микроархитектурной модели, но они часто производят консервативные оценки, которые могут быть в несколько раз выше, чем типичные времена выполнения. Инженеры должны сбалансировать потребность в безопасных границах с необходимостью осуществимого проектирования системы. Если оценка WCET слишком высока, система может быть чрезмерно обеспечена, увеличивая затраты. Если она слишком низка, система может пропустить сроки в полевых условиях. Это напряжение требует строгой проверки самих оценок WCET через сквозные измерения времени на конечном оборудовании. Гибридные подходы, которые сочетают статический анализ с целевым измерением — например, использование статического анализа для выявления наихудших путей, а затем измерение этих путей на цели — предлагают практический компромисс.

Проверка разделения времени и пространства

Интегрированные архитектуры, которые объединяют функции различных критичностей на одном и том же оборудовании, полагаются на надежное разделение. Гипервизор или операционная система должны гарантировать, что некритическая задача не может задержать или повредить критическую задачу безопасности. Проверка разделения включает в себя демонстрацию того, что общие ресурсы - память, время процессора, кэш и полоса пропускания шины - правильно распределены и соблюдены. Методы включают аудит конфигурации блока защиты памяти (MPU) или блока управления памятью (MMU), тестирование при наихудшей нагрузке с интерферирующими задачами и проверку того, что ОС обеспечивает соблюдение бюджетов для времени процессора и распределения памяти. Формальные методы могут использоваться для доказательства того, что механизмы разделения правильно реализованы, но это требует формальных моделей аппаратного и программного стека, которые сложны для создания и обслуживания. Решения мониторинга времени выполнения, которые проверяют инварианты разделения во время работы, обеспечивают дополнительный уровень уверенности, особенно для систем смешанной критичности.

Формальная проверка времени

Формальные методы, такие как автоматы с временным временем и проверка модели, все чаще применяются к верификации в реальном времени. Такие инструменты, как UPPAAL, позволяют инженерам моделировать шаблоны активации задач, совместное использование ресурсов и задержки связи. Затем модель может быть тщательно проверена, чтобы проверить, что свойства сроков для всех возможных путей выполнения. Основная задача заключается в построении верных моделей поведения системы, которые не упрощают важные детали. Кроме того, разрыв между формальной моделью и фактической реализацией должен постоянно проверяться; любая уточнение или изменение в реализации может потребовать обновления модели. Несмотря на эти проблемы, формальная викторина времени была успешно применена к критически важным для безопасности подсистемам в аэрокосмических и автомобильных областях, особенно для проверки сквозных цепочек связи в сетях с временным заданием. Автоматизированная модель извлечения из исходного кода и системных описаний является активной областью исследований, которая обещает уменьшить ручное усилие построения формальных моделей.

Проверка кибербезопасности для подключенных автомобилей

Интеграция связи между транспортными средствами (V2X), обновления по воздуху (OTA) и облачные сервисы значительно расширили поверхность атаки современных транспортных средств. Проверка кибербезопасности теперь является обязательной деятельностью, руководствуясь такими стандартами, как ISO 21434 и Регламент ООН R155. Неисправности безопасности могут непосредственно влиять на функциональную безопасность, что делает необходимым скоординированную проверку обеих областей.

Моделирование угроз и оценка рисков

Проверка начинается с систематического анализа угроз и оценки рисков (TARA). Этот процесс идентифицирует активы, субъектов угроз и векторов атак, что приводит к спецификации требований безопасности. Общие требования включают в себя безопасную загрузку, безопасное обновление прошивки с защитой отката, мониторинг целостности среды выполнения и безопасные каналы связи. Проверка должна затем подтвердить, что эти требования правильно реализованы. Это включает в себя не только функциональное тестирование механизмов безопасности, но и состязательное тестирование, такое как тестирование проникновения, нечеткость интерфейсов протокола и анализ боковых каналов. Например, проверка безопасной цепи загрузки требует доказательства того, что каждый компонент в цепи аутентифицирует следующий компонент перед выполнением, и что процесс не может быть обойден с помощью сбоев напряжения или манипулирования часами. Автоматизированные инструменты моделирования угроз , которые интегрируются с инструментами проектирования системы, помогающими оптимизировать TARA, но качество анализа все еще сильно зависит от экспертизы домена.

Модуль безопасности Hardware Co-Verification

Многие автомобильные системы полагаются на аппаратный модуль безопасности (HSM) для управления криптографическими ключами и предоставления безопасных услуг. Совершенствование должно гарантировать, что ключи никогда не подвергаются воздействию за пределами границы HSM, что криптографические операции выполняются правильно, и что HSM соответствующим образом реагирует на атаки впрыска неисправностей. Это требует тесной координации между аппаратной верификацией (обеспечение правильной разработки HSM) и проверкой программного обеспечения (обеспечение правильного использования драйверов и кода приложения HSM). Методы включают формальную проверку реализации криптографических протоколов, впрыск неисправностей на интерфейсе HSM и тестирование для временных боковых каналов, которые могут утечка материала ключа. Анализ утечек по боковым каналам, который может утечка материала ключа. с использованием статистических методов становится стандартной частью проверки HSM, поскольку физические атаки на автомобильную электронику становятся все более изощренными.

Проверка безопасности жизненного цикла

В отличие от функциональной безопасности, кибербезопасность не является статическим свойством. Новые уязвимости обнаруживаются непрерывно, и транспортное средство должно быть защищено в течение всего срока его службы. Это означает, что проверка не является одноразовым событием. Каждое обновление OTA должно быть проверено, чтобы гарантировать, что оно не вводит новые уязвимости и что оно не нарушает существующие механизмы безопасности. Сам механизм обновления должен быть проверен, включая аутентификацию, проверку целостности и защиту от отката. Непрерывный мониторинг безопасности и планы реагирования на инциденты должны быть на месте, а инфраструктура проверки должна поддерживать быстрое регрессионное тестирование, когда уязвимость обнаружена в стороннем компоненте. Это сдвигает процесс разработки в сторону DevSecOps, с безопасностью, интегрированной в каждый этап непрерывной интеграции и развертывания. Автоматизированные пакеты тестирования регрессии безопасности, которые работают как на виртуальных платформах, так и на испытательных стендах HIL, позволяют быстро валидировать обновления без ущерба для безопасности.

Перекрестные задачи проверки

Помимо проблем, связанных с конкретными областями, ряд межсекторальных вопросов затрагивает все аспекты встраиваемой в автомобильную систему проверки. Эти проблемы требуют комплексных стратегий, охватывающих инженерные дисциплины и организационные границы.

Инструмент квалификация и уверенность

Сами инструменты проверки могут вводить ошибки. Ошибка компилятора, инструмент статического анализа, который пропускает нарушение, или тестовый узел HIL, который неправильно интерпретирует сигнал, могут привести к неправильным выводам о правильности системы. ISO 26262 требует, чтобы инструменты были классифицированы по их потенциальному воздействию (Уровень доверия к инструментам) и что инструменты, классифицированные как TCL1, требуют квалификации для более высоких уровней ASIL. Квалификация компилятора или формального инструмента проверки является серьезным усилием - это включает в себя обширные наборы тестов, аргументы проверки и иногда избыточную проверку с различными инструментами. Мета-задача проверки инструментов проверки напрягает ресурсы и подчеркивает необходимость надежных, хорошо характеризуемых инструментов. ] Фреймворки проверки с открытым исходным кодом с валидацией на основе сообщества появляются, но они все еще требуют тщательной оценки для использования в критически важных для безопасности разработках.

Вмешательство в систему смешанной критики

Интеграция функций различной критичности на совместно используемом оборудовании вводит риск помех. Некритическая функция, генерирующая высокую пропускную способность памяти, может привести к тому, что критическая задача по безопасности пропустит свой крайний срок из-за выселения кэша или спора о шине. Проверка должна продемонстрировать, посредством комбинации анализа и тестирования, что помехи не нарушают гарантии безопасности. Методы включают анализ ограниченных помех, окрашивание кэша для пространственного разделения и наихудшее испытание нагрузки. Однако точное моделирование помех в сложных многоядерных системах остается исследовательской задачей, и практическая проверка часто полагается на чрезмерное предоставление и консервативные предположения. Вероятностный анализ времени , который учитывает статистический характер помех, привлекает внимание, но его принятие в сертификации безопасности по-прежнему ограничено.

Проверка ИИ и машинного обучения

Растущее использование глубоких нейронных сетей для восприятия и принятия решений представляет собой фундаментальную проблему проверки. Традиционная проверка на основе требований не очень хорошо применяется к изученным моделям. Вместо этого инженеры полагаются на массивные базы данных сценариев, тестирование с учетом покрытия и показатели надежности. Верификация должна решать такие вопросы, как искажение набора данных, состязательные примеры и производительность в условиях нераспространения. SOTIF стимулирует необходимость статистической проверки производительности восприятия, но определение достаточно безопасного уровня производительности для автономной функции, работающей в среде открытого мира, является постоянной проблемой исследования. Такие показатели, как покрытие нейронов и локальная состязательная надежность, изучаются в качестве прокси для полноты, но их корреляция с реальной безопасностью остается предметом обсуждения. Формальная проверка нейронных сетей с использованием теорий модуля удовлетворяемости (SMT) решающие показали перспективу для небольших сетей, но масштабирование до моделей производственного размера по-прежнему является значительной проблемой.

Цепочка поставок и интеграция наследия

Современные транспортные средства интегрируют компоненты от сотен поставщиков. Ответственность за проверку фрагментирована по всей цепочке поставок, требуя четких договорных определений деятельности по проверке и интерфейсов. Интеграционное тестирование часто выявляет несоответствующие предположения о сроках, форматах данных или обработке ошибок. Использование устаревших программных компонентов, в то время как экономически выгодно, несет долг по безопасности. Артефакты проверки для старых компонентов могут быть неполными или устаревшими. Когда устаревшая ECU интегрирована в новую архитектуру, ее взаимодействие с современными системами может выявить ранее спящие ошибки. Дополнительный контроль, где только изменения перепроверяются, требует точного понимания воздействия изменений, которое трудно достичь в сложных интегрированных системах. Цифровые двойные подходы , которые поддерживают живые модели поведения системы и статуса проверки по всей цепочке поставок изучаются для улучшения прослеживаемости и анализа воздействия.

Заключение

Проверка встроенных систем в автомобильной области требует дисциплинированного подхода, который объединяет различные технические и процедурные методологии. Проблемы охватывают сложность аппаратного обеспечения, параллелизм в реальном времени, правила безопасности и безопасности и новые границы функциональности на основе ИИ. Эти проблемы глубоко взаимосвязаны - исправление безопасности может изменить поведение в реальном времени, изменение оборудования может аннулировать случай безопасности, а обновление программного обеспечения может ввести новые условия запуска для SOTIF. Для решения этой проблемы требуется комплексная стратегия проверки, которая сочетает в себе раннюю виртуальную интеграцию, строгие аналитические методы, обширное динамическое тестирование и непрерывную проверку жизненного цикла. Организации, которые строят надежные, отслеживаемые и автоматизированные верификационные конвейеры, будут лучше всего оснащены для доставки безопасных, безопасных и надежных транспортных средств во все более программно-ориентированной отрасли. Принятие стандартизированных рамок, таких как те, которые продвигаются консорциумом AUTOSAR , и выравнивание с развивающимися нормативными требованиями, будет оставаться критическим, поскольку архитектуры транспортных средств продолжают развиваться в направлении более высоких уровней автоматизации и подключения.