Современный автомобиль давно перестал быть «просто техникой». Это сложная киберфизическая система, в которой миллионы строк кода управляют ключевыми функциями — от торможения и рулевого управления до механизмов защиты от взлома. В такой среде управление требованиями превращается не в бюрократию, а в фундамент безопасности, надежности и успеха всего проекта. Грамотно выстроенный процесс управления требованиями — это не просто каталог пожеланий, а стройная система, обеспечивающая создание корректного, безопасного и соответствующего стандартам продукта. Ключевая задача современной разработки — связать в единую логику требования из разных, но взаимозависимых областей.
Единый поток требований: функциональность, безопасность, киберзащита
Функциональная разработка (ASPICE)
Основу задают процессы нормальной разработки, которые описаны такими моделями, как ASPICE (Automotive SPICE). Он предписывает, чтобы при разработке продукта учитывались потребности стейкхолдеров, а сами требования к продукту были полными, непротиворечивыми, проверяемыми. Например, для функции адаптивного круиз-контроля должны быть четко определены ее предписанное функционирование, режимы работы и условия перехода между ними.
Функциональная безопасность (ISO 26262)
На базовый процесс «наслаиваются» требования функциональной безопасности. Появляется понятие Уровня полноты безопасности транспортного средства (ASIL). Здесь требования фокусируются на предотвращении и контроле потенциальных отказов — как систематических, так и случайных. ASIL указывает, какой объем усилий и ресурсов должен быть вложен для достижения требуемого уровня безопасности.
Например, для той же функции адаптивного круиз-контроля должны быть требования по обнаружению сбоев, переходе в безопасное состояние, информировании водителя. Они не должны противоречить общим архитектурным требованиям.
Кибербезопасность (ISO/SAE 21434)
Кибербезопасность добавляет еще одно измерение. Стандарт ISO/SAE 21434 требует проактивного выявления угроз и уязвимостей. Например, требование о проверке целостности обновления прошивки перед ее установкой должно быть согласовано с требованиями функциональной безопасности (чтобы обновление не нарушило критические функции) и с системными требованиями.
Учет обязательных регламентов
Разработка автомобиля также предполагает строгое соблюдение обязательных регламентов — Правил ООН, ТР ТС 018/2011 и других норм. Процесс управления требованиями должен обеспечивать прозрачную трассируемость: от нормативного требования — к системным и программным требованиям, а далее — к тестовым спецификациям и отчетам о верификации. Такой подход позволяет быстро и аргументированно демонстрировать соответствие изделия всем обязательным правилам.
Единая среда и разрешение конфликтов
Современный процесс управления требованиями должен обеспечивать единую среду, в которой видны и анализируемы все потоки требований. Это позволяет на ранних этапах выявлять конфликты. Например, когда требование по кибербезопасности ограничивает скорость передачи данных, что может противоречить требованию функциональной безопасности на минимальное время реакции.
Для демонстрации интерфейса среды управления требованиями использован СУТР АИС-Т.
На рисунке 1 приведен пример наличия настраиваемых связей:
«является частью» - требование распределяется на элемент архитектуры;
«декомпозиция» - требование является дочерним к родительскому.
Для того, чтобы обеспечить взаимосвязь процессов разработки, каждое требование к системе должно иметь свою «биографию», которая может быть отражена в атрибутах, например:
- источник: почему это требование появилось? (Правило ООН, запрос клиента, результат анализа безопасности по ISO 26262).
- обоснование: почему оно необходимо? Какую проблему решает или какую функцию обеспечивает?
- связь с родительским требованием: из какого более высокоуровневого требования оно вытекает?
- связь с дочерними требованиями/спецификациями: как оно детализируется на нижних уровнях (система, компонент, код).
- спецификация верификации: как именно проверяется его выполнение (тест-кейс, инспекция, анализ).
На рисунке 2 приведен пример настраиваемых атрибутов для цели безопасности: Уровень полноты безопасности (ASIL), Временной интервал сбоеустойчивости (FTTI), Безопасное состояние (Safe State).
Типичные ошибки и рекомендации по их устранению:
1. «Требования-повелители» без обоснования
Проблема: например, требование «Система должна иметь резервный датчик» без источника и объяснения. Это приводит к неоправданным затратам.
Решение: внедрение обязательных полей для фиксации источника и обоснования требования.
2. Отсутствие трассируемости между дисциплинами
Проблема: требование кибербезопасности по шифрованию не связано с сетевой архитектурой. В результате проектировщик сети может разработать архитектуру, где шифрование в реальном времени невозможно.
Решение: использовать единые инструменты, позволяющие устанавливать связи между требованиями разных типов.
3. Непроверяемые и расплывчатые формулировки
Пример: «Система должна быть надежной», «Интерфейс должен быть удобным».
Решение: применять принципы SMART. Требование должно быть конкретным, измеримым, достижимым, релевантным и ограниченным по времени. Вместо «надежной» — «Наработка на отказ (MTBF) должна составлять не менее 10 000 часов».
От требований к зрелому продукту
Управление требованиями в современных автомобильных проектах — это фундаментальная инженерная практика, которая напрямую определяет качество продукта, его безопасность и способность пройти сертификацию без задержек. Создание прозрачного, структурированного и проактивного процесса позволяет минимизировать риски, повысить управляемость разработки и обеспечить согласованность решений на всех уровнях. Это инвестиция, которая возвращается снижением количества критичных ошибок, ускорением процессов сертификации и выпуском действительно безопасного и надежного продукта.