Верификация и валидация в аппаратном обеспечении: в чем разница?

Иногда аппаратная разработка может выглядеть совершенно правильной на испытательном стенде: MCU стабильно работает на частоте 160 МГц, датчики обмениваются данными по I²C, а источник питания удерживает 12 В при полной нагрузке. Но продукт, который формально соответствует всем требованиям, все равно может не оправдать ожиданий, когда попадет к пользователю.

Верификация и валидация (V&V) помогают закрыть разрыв между соответствием требованиям и соответствием реальным потребностям. Некоторые команды по аппаратной разработке путают эти два термина. Команды, которые рассматривают V&V как один этап или пропускают один из них, потому что прототип «и так работает», могут столкнуться с проблемами слишком поздно: во время аудита или уже после вывода продукта в эксплуатацию.

В этой статье мы объясним, что означают верификация и валидация в аппаратной разработке и чем они отличаются. Мы также рассмотрим, как V&V связаны с требованиями через V-модель, как создать план V&V и как избежать распространенных ошибок.

Ключевые выводы

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

Что такое верификация?

Верификация — это процесс проверки того, соответствует ли аппаратная часть заданным требованиям и инженерным спецификациям. Она отвечает на вопрос: правильно ли мы создаем продукт?

Цель верификации — заменить предположения доказательствами. Вместо того чтобы просто считать, что схема работает, команда сопоставляет проект или физический прототип с заданными требованиями и фиксирует доказательства того, выполняются они или нет.

Верификация может включать такие действия, как:

• Анализ требований: Проверка того, что требования сформулированы ясно, согласованно, достижимо, прослеживаемо и проверяемо.
• Анализ проекта: Сопоставление схем, топологии PCB, механических чертежей и интерфейсов с заданными требованиями и правилами проектирования.
• Анализ и моделирование: Использование расчетов или моделей для проверки таких параметров, как тепловые запасы, целостность сигнала, временные характеристики или энергопотребление.
• Инспекция: Проверка физического оборудования, габаритов, сборки, компонентов или соединений на соответствие проектной документации.
• Испытания и измерения: Измерение параметров аппаратной части и сравнение результатов с требуемыми пределами или ожидаемым поведением по проекту.

Что такое валидация?

Валидация — это процесс проверки того, действительно ли аппаратная часть работает для своего предполагаемого применения, пользователей и рабочей среды. Она отвечает на вопрос: тот ли продукт мы создаем?

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

Валидация может включать такие действия, как:

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

Верификация и валидация в процессе аппаратной разработки.

Разница между верификацией и валидацией

V&V часто используют одни и те же инженерные инструменты: испытания, измерения, инспекции и анализ. Разница заключается в том, что именно вы пытаетесь доказать полученным результатом.

Например, испытание в термокамере может верифицировать, что продукт работает в заданном диапазоне от −20 °C до 60 °C. Валидация же задает вопрос, соответствует ли этот диапазон реальной потребности. Если продукт установлен в корпусе, находящемся под прямыми солнечными лучами и нагревающемся до 75 °C, он может успешно пройти верификацию и все равно отказать в эксплуатации. Та же термокамера может использоваться и для валидации, если испытание проводится по температурному профилю, с которым готовый продукт, как ожидается, столкнется в реальных условиях.

Верификация обычно дает более прямой результат «прошел/не прошел» относительно заданного требования и может применяться к отдельным требованиям, проектам или аппаратным элементам. Валидация рассматривает систему шире — как интегрированное целое — и оценивает, приемлемо ли ее общее поведение для предполагаемого применения.

В процессе, управляемом требованиями, верификация формирует доказательства того, что отдельные технические требования выполнены. Затем валидация проверяет, соответствует ли готовый продукт потребности заинтересованных сторон в реальных условиях эксплуатации, и может показать, что какое-то требование было неполным или неверным.

Как V&V вписываются в V-модель

V-модель показывает, как организовать V&V в рамках проекта аппаратной разработки.

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

V-модель процесса системной инженерии.

Каждому уровню слева соответствует уровень испытаний справа, и эти соответствия обеспечивают прослеживаемость. Каждое требование связывается с действием V&V и доказательствами, которыми оно проверяется, причем команда планирует это действие еще в процессе разработки. 

Например, требование о том, что вход 12 В должен оставаться в пределах ±5% при полной нагрузке, можно проверить на нескольких уровнях: по номиналам компонентов на схеме, с помощью моделирования питания платы и путем измерения на собранном изделии.

В рамках этой структуры у V&V разные роли:

• Верификация подтверждает на каждом уровне, что созданное решение соответствует требованиям и проекту с левой стороны. Анализ, расчеты и моделирование начинаются слева, а испытания и измерения проходят по правой стороне вверх.
• Валидация проверяет соответствие потребностям заинтересованных сторон в верхней левой части. Она начинается с валидации требований относительно этих потребностей и возвращается в верхней правой части как системная проверка: удовлетворяет ли готовый продукт потребности заинтересованных сторон и предполагаемое применение?

Как создать план V&V

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

План V&V обычно охватывает шесть решений:

• Определите область охвата: Решите, какой продукт, подсистемы или аппаратные функции охватывает план, что остается за его пределами и на какие области в первую очередь направляются усилия V&V с учетом рисков.
• Свяжите действия V&V с требованиями: Свяжите технические требования с действиями верификации, а потребности заинтересованных сторон — с действиями валидации. Тогда у каждого пункта будет четкий путь к доказательной базе.
• Выберите методы: Решите, как будет верифицироваться каждое требование — с помощью инспекции, анализа, демонстрации, испытаний или другого подходящего метода, — и как будет валидироваться каждая потребность заинтересованных сторон — с помощью испытаний сценариев использования, испытаний в условиях окружающей среды, пользовательской оценки или полевых испытаний.
• Определите условия и критерии приемки: Укажите конфигурацию аппаратной части, рабочие условия, оборудование и измеримый результат, по которому будет определяться, прошло ли действие проверку или нет.
• Спланируйте, кто что делает и когда: Назначьте ответственности, необходимые ресурсы и сроки, а также соотнесите каждое действие с соответствующим этапом аппаратной разработки, например со сборками прототипа, EVT, DVT или PVT.
• Определите, как фиксируются результаты и доказательства: Опишите, как будет записываться каждый результат и как он будет связываться с подтверждающими доказательствами, а также какие действия потребуется повторить после изменений в проекте.

Распространенные ошибки и как их избежать

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

В таблице ниже показаны распространенные ошибки в V&V и лучшие практики, которые помогают их избежать.

Преимущества V&V

Изменения аппаратной части на поздних этапах разработки обычно обходятся дороже, чем изменения программного обеспечения. Повторный выпуск платы, изменение оснастки или неудачная сертификационная проверка требуют реального времени и бюджета, а аппаратную часть в уже поставленном устройстве сложно «патчить». Именно поэтому verification и validation имеют особое значение в аппаратной разработке. При совместном применении они дают командам четыре основных преимущества:

• Более раннее выявление проблем: Обзоры, моделирование и ранние прототипы выявляют пробелы в требованиях, ошибки проектирования и упущения. На этом этапе исправление обычно сводится к изменению спецификации или схемы.
• Подтверждение для каждого требования: Verification связывает каждое требование с результатом, чтобы команда могла показать, что именно было проверено, каким образом и с каким итогом. Эти свидетельства также помогают при подтверждении соответствия, а для регулируемого оборудования, например медицинских устройств, они обычно требуются как часть управления разработкой.
• Соответствие реальному использованию: Validation проверяет готовый продукт в контексте его среды эксплуатации, пользователей и задач. Это позволяет выявить проблемы, которые можно упустить при проверке требования за требованием, например дрейф датчика или блики на дисплее при солнечном свете.
• Основа для следующего цикла: Измеренные запасы по параметрам и выявленные отказы помогают вносить изменения в конструкцию, готовить будущие ревизии и следующие поколения продукта. Они также показывают, где требования нужно ужесточить или, наоборот, ослабить.

Программные инструменты для управления Verification & Validation

Разработка аппаратной части включает множество требований и результатов испытаний, и их ручное отслеживание по всему проекту может быть сложной задачей. В итоге команды могут получить набор разрозненных файлов и несвязанных инструментов, таких как:

• Электронные таблицы и документы: Практичны для небольших проектов с ограниченным числом требований и тест-кейсов. По мере расширения охвата V&V поддержание прослеживаемости и готовности к аудиту может потребовать ручного сопровождения, а записи могут перестать быть согласованными.
• Системы отслеживания задач (например, Jira, GitHub): Эти инструменты можно адаптировать для организации работ по V&V и связывания связанных элементов с помощью ссылок, полей или тегов. Но поддержание прослеживаемости требований и полного покрытия V&V обычно требует дополнительной настройки и пользовательских плагинов.
• Специализированные инструменты управления требованиями: Предназначены для структурирования требований и прослеживаемости. Но в зависимости от инструмента планирование испытаний и сбор свидетельств могут требовать отдельных модулей или интеграций с внешними средствами тестирования. 

Для команд, которые хотят планировать и отслеживать действия V&V вместе с требованиями в общем рабочем пространстве, Requirements Portal связывает требования с планами verification, тестовыми прогонами, свидетельствами и историей изменений. Так команды могут видеть, что уже проверено, а что еще требует внимания.

Заключение и следующие шаги

Кратко: verification доказывает, что ваша аппаратная часть соответствует спецификации, а validation — что она действительно работает для пользователя. Чтобы это работало, V&V не может быть лишь финальным чек-листом. Его нужно встраивать в процесс разработки продукта с первого дня.

Если вы хотите глубже разобраться в подходах к V&V, полезно продолжить с такими материалами:

• NASA Systems Engineering Handbook дает практические рекомендации по планированию и выполнению V&V для аппаратных продуктов космического класса.
• Guide to the Systems Engineering Body of Knowledge (SEBoK) дает более широкий взгляд на V&V с точки зрения системной инженерии.
• INCOSE V&V Across Product Lifecycle охватывает V&V на разных стадиях жизненного цикла, V-модель, методы V&V, тест-кейсы и критерии успеха.

Если вы готовы перейти от теории к практике, попробуйте Requirements Portal, чтобы связывать тест-кейсы с требованиями и электронными проектами, отслеживать покрытие и сохранять инженерные свидетельства.

Часто задаваемые вопросы

Verification — это то же самое, что Validation?

Нет. Verification проверяет аппаратную часть на соответствие определенным требованиям. Validation проверяет, отражают ли требования и сам продукт потребности заинтересованных сторон в реальном использовании.

Что выполняется первым: Verification или Validation?

Оба направления нужно планировать на раннем этапе, и ни одно из них не является единственной фазой. Verification начинается с обзоров, анализа и моделирования по мере развития проекта. Validation начинается с проверки требований на соответствие потребностям заинтересованных сторон и становится более заметной по мере формирования интегрированного продукта.

Какие методы V&V наиболее распространены?

К распространенным методам V&V относятся обзоры, инспекции, анализ, моделирование, демонстрации и испытания. Один и тот же метод может поддерживать как verification, так и validation — в зависимости от того, проверяет ли он заданное требование или оценивает продукт в контексте предполагаемого использования.