2.7. Верификация и валидация

Одним из основных принципов системно-инженерного подхода является пошаговая проверка результатов работ на соответствие выставленным требованиям. Для проверки результатов каждого шага разработки используются два метода: верификация и валидация.

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

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

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

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

Вкратце различия применения верификации и валидации можно изложить следующим образом. Верификация проводится:

• в процессе разработки;

• чтобы убедиться, что утвержденные требования будут выполнены;

• как правило, в лабораторных условиях (не натурных);

• верификация ориентирована на компоненты и подсистемы.

Аналогом в РФ выступают компонентные испытания и проверки на моделирующих стендах.

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

Валидация выполняется:

a) в процессе или после процедуры интеграции системы;

b) обычно в реальных или смоделированных условиях эксплуатации;

c) для проверки ожиданий заинтересованных сторон;

d) желательно в составе полномасштабного варианта системы.

Аналогом в РФ являются сертификация, государственные или межведомственные испытания.

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

Основные задачи верификации при разработке перечислены ниже.

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

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

3. Повторение верификации в соответствии с планом, методом испытания или процедурой, когда отклонения (разброс данных) были вызваны недостаточной адаптацией к условиям окружающей среды в эксплуатации.

4. Фиксация записи результатов верификации, в том числе: корректирующих действий; уроков исправления, достигнутых результатов; компромиссов, анализа рисков, результатов испытаний; отклонений и проверенных решений проекта в хранилище данных предприятия.

Валидация может охватывать следующие действия.

• Тестирование производительности для проверки того, что продукт или система функционирует должным образом и соответствует ожиданиям клиентов.

• Испытание для подтверждения того, что изделие соответствует всем законодательным требованиям, требованиям безопасности и нормативным требованиям, включая формальные приемочные испытания.

• Испытание на срок службы (ресурс) для подтверждения того, что продукт будет продолжать функционировать в соответствии со своими требованиями на протяжении всего заданного срока службы.

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

• Испытания на надежность, чтобы доказать, что продукт будет надежно функционировать с точки зрения частоты отказов на протяжении всего расчетного срока службы.

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

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

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

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

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

При планировании испытаний требуется:

• разработать подробные квалификационные требования к испытаниям;

• определить подробные архитектуры компонентов для тестовых ресурсов (выявить, какие специальные установки, измерительные приспособления и тестовые заглушки необходимы);

• инициировать разработку и изготовление необходимых стендов;

• сформировать матрицы испытаний (выделить производные требования к функциональным и физическим архитектурам);

• написать детальные планы квалификации для каждого компонента с учетом ресурсов;

• создать сценарии тестирования с учетом нормативной документации;

• определить необходимые данные мотивации для каждого вида деятельности;

• написать программы испытаний и процедуры анализа результатов;

• определить графики по срокам испытаний и анализа.

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

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

Таблица 2

Для испытаний сложной техники широко применяют наземные стенды систем и компонентов, в том числе прочностные, где проводят статические и ресурсные испытания. Статические испытания определяют способность конструкции выдерживать высокие однократные нагрузки. Ресурсные испытания позволяют спрогнозировать поведение конструкции при повторяющихся нагрузках, характерных для типовой эксплуатации. В авиации, например, используют стенды для специальных испытаний, где проводят климатические тесты, а также испытания на внешние воздействия (попадание птиц, молниестойкость, пожаростойкость и др.). Полный набор базовых требований к испытаниям компонентов авиационной техники изложен в стандарте КТ-160 (DO-160G) «Условия окружающей среды и процедуры испытаний для бортового авиационного оборудования», содержащем 26 разделов. При работах по указанному стандарту используемые стенды должны быть предварительно сертифицированы на соответствие этим требованиям.

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

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

1) обеспечения правильной постановки задач моделирования (например, пользователи не могут вводить в расчет параметры, выходящие за пределы заданного диапазона режимов);

2) разработки процессов верификации и валидации инструментов, сертификации расчетных моделей на основе эксплуатационных данных и типовых экспериментов;

3) разработки и идентификации отраслевых стандартов для документации, управления конфигурацией и обеспечения качества моделирования;

4) разработки стандартного метода оценки достоверности результатов моделирования, представляемого уполномоченному органу, принимающему решения.

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

a) легко проверяемые требования;

b) пошаговые руководства по планированию, проведению и обработке испытаний;

c) модели и виртуальное моделирование;

d) надежная конструкция для изменения параметров компонента, процесса изготовления;

e) стандартизация процессов и документов;

f) применение ускоренных эквивалентно-циклических испытаний;

g) доступность испытательного оборудования (стендов) и измерительных систем;

h) независимость компонентов системы;

i) эмулятор оборудования для непроверенного программного обеспечения;

j) проверенное программное обеспечение для непроверенного оборудования;

k) модульное, «восходящее» (снизу-вверх) тестирование;

l) готовый план испытаний и процедуры тестирования, контроль критического пути графика работ.

В качестве примера важности верификации в космической программе рассмотрим происшествие с аппаратом Genesis в 2004 г. Он был запущен NASA в 2001 г. для сбора и анализа заряженных частиц, выдуваемых из короны Солнца (солнечного ветра). По плану возвращения на Землю, после входа в атмосферу капсула должна была выпустить первичный парашют, который бы замедлил и стабилизировал падение. Затем должен был раскрыться основной парашют для совершения мягкой посадки. Оба парашюта не сработали при приземлении, аппарат разбился о землю на скорости 350 км/час. Два разных комплекта контрольных датчиков (срабатывавших по величине ускорения торможения и по росту температуры) были включены наоборот (сравнительно со спецификациями). После работы аварийной комиссии выявлены причины происшествия:

1) схема использования датчиков для выпуска парашютов скопирована с предыдущей успешной модели;

2) верификационные требования расплывчаты, наземный тест срабатывания на центрифуге не затребован;

3) конструктор проверил срабатывание датчиков (открыто-закрыто), при этом не была проведена верификация ориентации датчиков;

4) электрик-монтажник некорректно провел верификацию ориентации по чертежу;

5) проверяющие вынесли решение, что проект системы выполнен правильно, так как скопирован с удачного аналога;

6) инженер, готовивший аппарат к полету, не замкнул обратную связь с проектантом, т.к. не потребовал обсудить результаты испытаний.

В результате аварии виновными признаны конструктор (не проведен обзор проекта) и испытатель (не выполнена верификация системы выпуска из-за копирования предыдущего решения).