скачать книгу бесплатно
В процессе синтеза нужно будет решить, могут ли требования к системе быть удовлетворены с использованием существующих готовых покупных комплектующих изделий и компонентов, или должны быть использованы заново созданные конструкции или технологии. Преимущество использования покупных деталей в том, что большинство поставщиков специализируются на производстве деталей, соответствующих установленным промышленным нормам и спецификациям, таким как ISO 9001. Также эти детали часто производятся в больших объемах, по относительно низкой цене за единицу. При отсутствии покупных модулей создание и валидация новой конструкции, отвечающей требованиям, может быть очень дорогостоящим, рискованным или трудоемким делом.
При принятии проектных решений следует начинать с выбора критериев оценки влияния решений на ход реализации проекта:
• когда решение связано с умеренным или высоким риском по результату;
• когда результат решения может привести к значительным задержкам графика работ или перерасходам;
• учитывать, что при закупке ПКИ есть 20% комплектующих, которые составляют 80% от общей стоимости объема ПКИ.
Полезно использовать проверенные принципы для выработки проектных решений ОКР:
• Лучше продвигаться по проекту, имея несколько запасных стандартных решений, чем опоздать с графиком в поисках одного «совершенного» варианта. Здесь лучшее будет врагом хорошего.
• В проекте надо использовать принцип «сделай это проще», чтобы снизить риски, стоимость разработки и эксплуатации.
При принятии любого решения следует помнить, что подавляющее большинство технических задач имеют множество решений. Поэтому не следует сожалеть о результате после принятия решения. Поправки возможно рассматривать только по данным последующего технического обзора, если выяснится, что при принятии решения не были учтены какие-то существенные факторы. Большинство концепций и проектов есть полезные, с низким риском, модификации предыдущих решений с относительно малой новизной. С них рекомендуется начинать разработку.
Для повышения эффективности формирования системы многие компании используют процедуру коллективного экспертного выбора конструкторских решений будущих изделий. Этап выбора базовых проектных решений, например, в компании Airbus, может длиться от 3 месяцев до 1,5 лет. В этом процессе участвуют эксплуатационники, конструкторы, технологи, производственники, закупщики, риск-разделенные партнеры. Предпочтительно работы проводятся при личном общении участников на единой площадке. В ходе этапа определяют перечень позиций, по которым должны быть приняты общие заключения, обсуждение и утверждение базовых конструкторских решений. Детально расписан процесс принятия решений и их количество на данном этапе. Примерами критериев принятия оптимальных решений могут быть масса системы, прочность, новизна технологии, стоимость, варианты конструкции, унификация, и др. Согласованный перечень проектных решений далее является руководством к действиям разработчиков на этапах предварительного и детального проектирования системы. Составляют соглашения об используемых в программе инструментах, формате данных, требований, критериев, коммуникации и др. Набор этих результатов должен быть задокументирован и является опорным при дальнейшей разработке сложных систем. Так повышается качество разработки, потому что за облик конструкции отвечают совместно эксперты разных направлений. Нет места ошибкам, типа недавно озвученной каким-то самолетостроителем РФ, что проблемы при работе одной из систем нового изделия связаны с тем, что ее проектирование поручили молодому специалисту.
Основной целью детального проектирования системы является интеграция всех компонентов в единую систему. Технический проект уточняет, как будет выглядеть реальная система и ее компоненты (размеры, формы и взаимное расположение). Он включает формирование и документирование подсистем, узлов, частей основной системы, и вспомогательных элементов. Здесь принимаются решения о том, будут ли подсистемы и компоненты функционировать вручную или автоматически, будут ли компоненты электронными, механическими, или гидравлическими, и так далее. На чертежах и моделях должны быть показаны все детали, необходимые для последующего изготовления, сборки и обслуживания системы.
Ранее при создании систем собирали все части вместе, и затем проводили испытания системы. Часто оказывалось, что система, включающая множество отдельных частей и большой объем программного обеспечения, слишком сложна для успешного объединения всего и сразу. Постепенно была внедрена фаза между сборкой и испытаниями, которую сегодня называют системной интеграцией. Это процесс, при котором пошагово объединяют все компоненты и подсистемы в одну систему, и обеспечивают их работу и функционирование как единого целого. Интеграция определяет координацию усилий по сборке функционирующей системы.
Управление интеграцией объединяет все области знаний в программе и связывает план разработки в одно целое, координируя различные процессы и действия в рамках программы. В число ключевых элементов управления интеграцией входят назначение системы, время, стоимость, контроль качества, персонал, коммуникации, риски, материально-техническое снабжение.
Конечной целью интеграции является обеспечение функционирования системных элементов в соответствии с указанными требованиями, конфигурационной документацией, требованиями к интерфейсу, применимыми стандартами, последовательностью и процедурами интеграции. Должны быть разработаны проектные спецификации для всех компонентов и элементов нижнего уровня, включая аппаратное обеспечение, программное обеспечение, пользователей, сборки и пакеты. Далее определяют, закупают и интегрируют компоненты в окончательную конфигурацию системы. Выполняют критический анализ системы, выявляют возможные проблемы с конфигурацией в отношении требований к системе, и, при необходимости, вносят в нее изменения.
При интеграции сначала последовательно собирают части в небольшие компоненты. Затем интегрируют крупные подсборки для объединения всей системы. Проводят проверку работоспособности отдельных компонентов и подсистем, чтобы заставить элементы системы работать правильно. Сравнивают результаты испытаний с ожидаемыми. При отклонениях отслеживают источник несоответствия и вносят необходимые коррективы в реализацию элемента. Процесс повторяется до достижения заданных результатов для каждой из подсистем. При этом заметно уменьшается количество ошибок, которые остаются в системе (скрытые дефекты). Также подтверждается, что система завершена, и готова к валидации. Сборку системы на основании разработанной документации может выполнить группа независимых команд, каждая из которых будет отвечать за одну или несколько входящих частей.
В ходе интеграции подключают новый компонент к системе так, чтобы ее не повредить. Компонент будет проверяться индивидуально в изолированных средах. Сначала подтверждается, что он функционирует так, как предполагалось, а затем проверяют, что он не причиняет вреда окружающим модулям и не приводит к их нежелательному поведению. После такой проверки компонент можно интегрировать в состав системы. По сути, вводится безопасное пространство для отказа, позволяющее инженеру принимать решения с реальными последствиями в гораздо меньшем масштабе, чтобы учиться на собственном опыте.
В результате процесса должны быть получены: интегрированный продукт со всеми системными взаимодействиями, документация и руководства, включая модели, данные и отчеты системного анализа, подтверждающие обоснование готовности системы. Формируют отчеты по интеграции продуктов (для поддержки процесса управления техническими данными), чертежи сборки, результаты верификации, требования к эмулятору (где приложимо).
Важным вопросом интеграции является применение правила копирования, то есть использования готовых компонентов, модулей, подсистем, покупаемых на рынке. При любом применении заимствованные части изделия должны проверяться на качество и верифицироваться так же, как новое оборудование.
Процесс интеграции продукта применяется не только к аппаратным и программным системам, но также к сервис-ориентированным решениям, спецификациям, планам и концепциям.
На этапе синтеза продукта эффективно применяют интеграционную методологию параллельного инжиниринга (подробности в разделе 3.2.2). Так названа совместная работа различных специалистов, сотрудничающих одновременно в общей среде, реальной или виртуальной, для создания общего дизайна, достигая сокращения времени цикла разработки продукта за счет лучшей интеграции мероприятий и процессов.
Важнейшим инструментом в процессе развития параллельного инжиниринга стало освоение трехмерного электронного макета изделия (ЭМИ), используемого командами проекта 24 часа в сутки. Работа с ЭМИ существенно снижает время проектирования и затраты. Электронный цифровой макет изделия становится средоточием информации о продукте, определения можно найти в ГОСТ 2.051…2.058.
Электронный макет в процессе разработки включает обычно три уровня.
Начальный макет ЭМИ-1 используется для предварительных компоновочных решений по продукту и включает: все внешние формы системы или секции, основные геометрические сведения о силовом наборе, важные интерфейсы, все системы координат, необходимые для позиционирования подсборок между собой, общие виды и внешние границы.
Данные решения проверяются на следующей стадии макета ЭМИ-2 (space allocation mock-up), макет распределения внутренних объемов продукта под компоненты и агрегаты, который развивает мастер-геометрию и служит для проработки использования допустимого пространства внутри изделия при его заполнении конструктивными элементами, определения расположения подсистем и частей оборудования, проверки их взаимной увязки. На базе 3D-моделей макета второго этапа ЭМИ-2 после «замораживания» всех проектных решений конструкции выпускается рабочая документация (РКД), которая передается намеченным производителям для согласования и доработки технологий производства.
Разработанная и скорректированная рабочая документация служит основой для финальной модели (макета) изделия ЭМИ-3 (справочная геометрия, сертификация). Этот макет строится в завершающей стадии конструирования на основании производственных чертежей и служит источником для стадий производства, эксплуатации, при разработке модификаций. Также ЭМИ-3 включает базу сертификационных расчетов на прочность, сборник требований по установке систем и оборудования.
В результате в ЭМИ включены технические данные системы, трехмерные (3-D) модели, документы и обеспечивающие процессы, необходимые для использования при дальнейших этапах работ. Сюда входят трехмерная модель системы, набор и система управления техническими документами проекта, система управления составом изделия, система управления жизненным циклом изделия, технологические данные, содержащие необходимые указания для производства, результаты расчетов, производственные данные для проектирования и изготовления оснастки, технологические процессы, библиотеки операций и переходов.
Требования к точности цифровых моделей изложены в ГОСТ Р 57700.23—2020 «Компьютерные модели и моделирование. Валидация. Общие положения». На этом этапе формируется набор цифровых двойников системы.
Цифровым двойником (ЦД) изделия называют систему, состоящую из цифровой модели изделия и двусторонних информационных связей с изделием и его составными частями, согласно ГОСТ Р 57700.37—2021 «Компьютерные модели и моделирование. Цифровые двойники изделий. Общие положения». В основе цифрового двойника лежит модель изделия, которая, в свою очередь, является «системой математических и компьютерных моделей, а также электронных документов изделия, описывающей структуру, функциональность и поведение вновь разрабатываемого или эксплуатируемого изделия на различных стадиях жизненного цикла». Она приближенно описывает структуру, функциональность и поведение вновь разрабатываемого или эксплуатируемого изделия на различных стадиях жизненного цикла. Эта виртуальная модель физической системы постоянно обновляется по следам изменений своего реального прототипа. Разрешением модели называют степень детализации и точности, достигаемую при представлении реального мира в статической или динамической (изменяемой во времени) модели.
Верификацией модели называют процесс подтверждения того, что получаемые от модели данные точно представляют требования разработчика. Валидацией модели называют процесс определения степени адекватности, с которой данные модели являются представлением объектов реального мира в части их использования. Иными словами, достаточно ли точно математическая модель описывает поведение реальной системы в отношении принимаемого решения. Различают валидацию требований и валидацию продукта. Целью валидации требований является контроль их правильности и полноты для достижения безопасности и удовлетворения потребностей потребителя в рамках заданных ограничений (например, стоимости, графика). Валидация продукта служит для установления соответствия продукта потребностям клиента.
В стандарте ГОСТ Р 58301—2018 «Управление данными об изделии. Электронный макет изделия. Общие требования» предложена классификация моделей, привязанных к основным фазам жизненного цикла. Функциональный макет ЭМИ-Ф включает взаимосвязанную совокупность данных, описывающих устройство, состав, характеристики, принципы работы и возможные нарушения работоспособного или исправного состояния изделия. Конструкторский макет ЭМИ-К содержит взаимосвязанную совокупность данных, описывающих конструкцию и требования к изготовлению (сборке) изделия. Технологический макет ЭМИ-Т концентрирует взаимосвязанную совокупность данных, описывающих технологию изготовления (сборки) изделия и используемых для планирования, оценки и организации процесса изготовления изделия. Эксплуатационный макет ЭМИ-Э включает взаимосвязанную совокупность данных, описывающих эксплуатационные свойства изделия и требования к процессу его технической эксплуатации.
Вышеперечисленный объем работ на регулярно актуализируемом ЭМИ и его компонентах, отработка электронных сборок, включающих до 50000 деталей, позволяют существенно повысить качество выдаваемой конструкторами документации, в 6—10 раз снизить стоимость затрат на корректировки конструкторских решений в производстве.
На этапе проектирования выполняется выпуск рабочей конструкторской документации в электронном виде. Системные спецификации проекта преобразуются в планы, эскизы, чертежи, блок-схемы или модели. Здесь система разбивается на уровни подсистем, компонентов и частей. Конкретизируются компоненты системы, размеры, взаимосвязи и общая конфигурация. Варианты конструкции элементов на каждом уровне сложности проверяются на совместимость друг с другом и с элементами на более высоких уровнях. Проводится контроль соответствия спецификациям и требованиям к стоимости системы, графику и характеристикам.
При этом уточняются следующие наборы данных.
1. Базовая конфигурация (см. раздел 1.5) системы на уровне элементов и компонентов. Она включает утвержденную документацию по конфигурации системы, списки компонентов и частей, их технические спецификации, инженерные чертежи, модели прототипов системы и интегрированные проектные данные.
2. Технические требования к производственному процессу или процессу обслуживания, для любых элементов или компонентов системы. Включают необходимые производственные процессы, такие как сварка, формование, резка, гибка, или процессы обслуживания и логистики. Также определяют транспортировку, упаковку, инфраструктуру баз данных проекта.
3. Материальная спецификация, которая включает технические требования, относящиеся к материалам элементов и компонентов системы. В нее входят сырье, вспомогательные материалы (краски, клеи и композиты), и любые коммерчески доступные материалы от поставщиков (кабели, трубы, элементы крепежа, и так далее) для подсистем.
При детальном проектировании для проверки конструкции широко используют моделирование на основе прототипов. Прототипом называют оперативно смоделированное представление системы, которое позволяет дизайнерам и пользователям его визуализировать, осмыслять, трогать и чувствовать для эффективной проверки дизайна. Прототипы бывают разных форм и уровней детализации, от концептуальных карточек и нарисованных вручную блок-схем до сложных версий системного интерфейса или макетов оборудования. Чем ближе прототип к реальной системе, тем выше его точность. Сюда же относятся обучающие устройства, копии компонентов реальной системы, например, тренажеры для обучения пользователей.
1.5 Конфигурация и технические данные системы
Конфигурацией системы, изделия или программного обеспечения называют комплекс функциональных и физических характеристик изделия, зафиксированных в документах требований и конструкторской документации. Под функциональными характеристиками понимаются показатели эффективности функционирования изделия, то, что интересует пользователя, эксплуатанта, покупателя: дальность поездки автобуса, количество перевозимых пассажиров, топливная эффективность, и др. Под физическими характеристиками изделия понимается информация, необходимая для его изготовления: состав изделия, размеры, допуски и посадки, материалы, шероховатости, а также требования конструктивных ограничений.
Описание конфигурации системы включает базовые данные, утвержденный состав изделия. Ведется контроль версий, так как конфигурация может изменяться на разных стадиях жизненного цикла изделия. Каждая подсистема будет выполнять функцию или набор функций системного уровня, перечисленных в базовой версии. С момента выбора архитектуры эти подсистемы будут называть конфигурационными элементами (КЭ). В общем случае, история КЭ документируется и отслеживается на протяжении всего жизненного цикла системы, ее проектирования, производства и использования. Целью процесса управления конфигурацией является обеспечение того, чтобы любые изменения в конструкции, производстве или использовании КЭ не изменяли и не ухудшали его способность удовлетворять функциональным требованиям.
В процессе распределения функциональных требований по разным КЭ нужно гарантировать, что каждое требование будет выполняться, по крайней мере, одной из подсистем или КЭ. Полученные распределения отображаются в виде «матрицы прослеживаемости требований». Некоторые функциональные требования являются общей ответственностью нескольких КЭ. Например, масса автомобиля является суммой масс всех КЭ. Если масса любого из них изменяется, то изменяется и общая масса автомобиля.
Ниже перечислены базовые варианты конфигурации, которые обычно контролируются в программе или проекте.
• Функциональный базовый вариант представляет исходную утвержденную документацию по конфигурации, в которой зафиксирована физическая архитектура системы на основе требований к производительности системного или верхнего уровня конфигурационного элемента (КЭ), функциональные возможности и характеристики интерфейса.
• Распределенный базовый вариант «как спроектировано» содержит утвержденную конструкторскую документацию для разрабатываемого КЭ, которая описывает функциональные характеристики, производительность и свойства интерфейса.
• Базовая версия продукта «как испытано» включает утвержденную техническую документацию, описывающую конфигурацию КЭ по результатам валидации на этапах производства, ввода в эксплуатацию и послепродажной поддержки его жизненного цикла.
На всех этапах разработки и эксплуатации систем необходимо наличие электронной документации по конфигурации с целью отслеживания, сравнения вариантов и ведения управления и изменений.
Частным случаем управления конфигурацией является проведение изменений в проекте. Изменением называют модификацию ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, управленческих и технологических процессов, и т. п. Правила внесения изменений в конструкцию изложены в ГОСТ 2.503—2013. Решения об изменениях проекта принимают, если в процессе проектирования выявлены места, где конструкция неудовлетворительна из-за невыполнения функций, сборки, обслуживания или внешнего вида. Некоторые изменения неизбежно происходят на разных этапах процесса проектирования. Причинами являются изменения требований клиентов, изменения в технологиях и ресурсах, и так далее. На более поздних фазах разработки, таких как этап рабочего проектирования, небольшое изменение в спецификации системы может оказать значительное влияние на всю систему. Следует определять причины изменений как можно раньше. Чем позже в проекте происходят изменения, тем дороже они становятся. Необходимо соблюдать надлежащую процедуру контроля изменений, чтобы свести к минимуму воздействие на всю разработанную систему. Одной из задач руководителя проекта является минимизация количества изменений конструкции для каждой подсистемы.
Общие данные программы, то есть многообразие видов используемой информации, можно разделить на технические данные, программное обеспечение, управленческую и финансовую информацию. Информацией называют организованные данные, которые имеют значение и ценность для получателя. В каждом проекте или программе должны быть определены наборы ключевых технических данных, используемых в течение жизненного цикла системы. Их основу составляют полные сведения о продукте, включая определение требований, конструирование, испытания, производство, упаковку, хранение, эксплуатацию, обслуживание, модификации и утилизацию продукта. Текущая версия конфигурации также входит в технические данные. ГОСТ Р 58675—2019 «Автоматизированная система управления данными об изделии. Общие требования» включает полезные рекомендации по составу информации.
Технические данные о продукте можно подразделить на три группы, информацию по определению продукта, по эксплуатации продукта, и иную, связанную с продуктом. На всех этапах жизненного цикла необходимо хранить объемные массивы исходных данных, результаты расчетов и верификационные отчеты. Для каждой создаваемой системы или изделия основным носителем информации и источником технических данных сегодня является электронная модель изделия (ЭМИ). Наличие такого объекта облегчает поддержку в эксплуатации, аккумулируя реальную информацию о наработке узлов и агрегатов, составе и ресурсе ПКИ, для парка, состоящего из десятков или сотен изделий, в том числе эксплуатируемых за рубежом. Наличие базы цифровых двойников (моделей изделия и его частей) позволяет быстро проводить при необходимости различные расчеты, например, оценивать остаточный ресурс деталей в эксплуатации при наличии повреждений или коррозионного износа.
Интегрированный объем технических данных об изделии можно классифицировать в соответствии с этапами его ЖЦ.
• Конструкторские данные, появляющиеся в процессе проектирования и разработки изделия. Включают сведения о составе изделия, его геометрических моделях, компонентах и их технических характеристиках, об их отношениях в структуре изделия, ЭМИ, сертификационные данные, результаты расчетов и моделирования, допуски на изготовление деталей.
• Технологические данные, формируемые на стадии технологической подготовки производства. Содержат материальные спецификации, сведения о способах изготовления и контроля изделия и его компонентов в процессе производства, в том числе входного контроля покупных изделий и материалов. Включают описание маршрутных и операционных технологий, норм времени и расхода материалов, управляющие программы для станков с ЧПУ, данные проектирования приспособлений, режущего и мерительного инструмента.
• Производственные данные, включая сведения о статусе конкретных экземпляров изделия и его компонентов в производственном цикле, перечни ПКИ, цепочки и графики поставок, данные по их монтажу во времени и пространстве, последовательность сборки компонентов и финальной сборки изделия.
• Данные о качестве, порождаемые на всех этапах контроля. Содержат сведения о степени соответствия экземпляров изделия и его компонентов заданным техническим требованиям, техническим условиям, требованиям стандартов, нормативно-технических документов системы качества.
• Руководства по эксплуатации и обслуживанию, содержащие сведения, необходимые для нормальной эксплуатации, организации обслуживания, ремонта и других действий, обеспечивающих работоспособность изделия, а также документы и руководства по эксплуатации и ремонту.
Данную информацию приходится актуализировать в эксплуатации, при ремонте или модернизации системы. Важно правильно выстроить стратегию продвижения корпорации по уровням цифровизации для получения положительного баланса между затратами и приобретениями.
Сегодняшний этап цифровизации (развития компьютерных технологий и связанных с этим сфер деятельности) часто называют «цифровой индустрией 4.0». Его характеризуют, например, следующими признаками (зависит от источников информации).
1. Компьютеризация для цифрового управления всеми основными компонентами производства.
2. Сетевое взаимодействие между компонентами.
3. Создание цифрового отображения или «виртуального двойника» предприятия (визуализация бизнес-процессов).
4. Прозрачность цифрового отображения аналитических систем с так называемыми «большими данными».
5. Прогнозирование.
6. Адаптивность бизнеса к изменяющимся внешним условиям.
Можно представить упрощенный вариант трехуровневой схемы иерархии информационной системы предприятия. На первом (верхнем) уровне расположен блок-интегратор бизнес-процессов, например, интеллектуальной системы управления предприятием (Intellectual Enterprise Management). На втором уровне логично расположить три обеспечивающих блока бизнес-процессов, связывающих первый (управленческий) уровень с третьим, нижерасположенным, производственным уровнем. Например, закупки и логистику, управление конфигурацией, управление знаниями. На третьем, фундаментном, уровне расположены три основных производственных направления организации: конструирование, производство и послепродажное обслуживание. Важным преимуществом построения такого «информационного дерева» является наличие на рынке альтернатив всего набора программного обеспечения для перечисленных блоков. Предложенное дерево возможно наращивать в разных направлениях, опять же в зависимости от структуры бизнес-процессов организации, их необходимой детализации, и др.
При формировании цифрового предприятия можно обратиться к сайту Министерства цифрового развития РФ. Там в дополнение к паспорту федерального проекта «Цифровые технологии» программы «Цифровая экономика» приведена дорожная карта по развитию «сквозной» цифровой структуры «Новые производственные технологии». Главной целью направления цифровизации не должны являться дорогостоящие развитие и смена версий программного обеспечения, это только часть бизнеса компании, обеспечивающая быстрое и качественное функционирование его компонентов, которая должна окупаться в процессе использования цифровых инструментов.
1.6 Верификация и валидация,
обзоры проекта
Создание системы сопровождается стратегией пошагового контроля результатов разработки. При этом выявление и устранение дефектов происходит раньше и с меньшими затратами. Для проверки результатов каждого шага разработки используются два метода: верификация и валидация.
Верификация представляет процесс подтверждения того, что требование или система соответствует входным данным. Верификация требования отвечает на вопрос: действительно ли система удовлетворяет этому определенному требованию?
Валидация обеспечивает соответствие системы потребностям и ожиданиям конечных пользователей. Она представляет процесс подтверждения, что набор требований, проект или система соответствует предназначению Заказчика. Как правило, проводится с привлечением внешних инстанций, регулирующих органов, представителей заказчика, межведомственных комиссий, и др.
Верификация выполняется на ранних этапах процесса разработки для подтверждения соответствия требованиям перед процессом валидации и передачей изделия в серийное производство. Результаты всех верификаций представляются группе по валидации как обеспечение соответствия заявленным спецификациям.
Верификация ориентирована на компоненты и подсистемы, и проводится:
• в процессе разработки;
• чтобы убедиться, что утвержденные требования будут выполнены;
• как правило, в лабораторных условиях (не натурных).
Основные задачи верификации при разработке перечислены ниже:
1. демонстрация соответствия конструкции и характеристик установленным требованиям на заданных уровнях;
2. обеспечение соответствия продукта разработанному проекту, отсутствия дефектов производства, и пригодности к применению;
3. подтверждение способности системы в целом выполнять требования программы в эксплуатации, включая инструменты, процедуры и ресурсы;
4. документирование результатов верификации, в том числе анализа рисков, результатов испытаний, отклонений, и проверенных решений проекта, включенных в хранилище данных.
На этапе интеграции системы или продукта выполняется верификация модулей и подсборок, чтобы убедиться, что утвержденные требования будут выполнены. Успешная верификация системы или ее компонента подтверждает, что синтез выполнен правильно и система соответствует требованиям. Используют четыре метода верификации: инспекцию, анализ, демонстрацию, испытания (тесты).
Инспекция или осмотр включает визуальное исследование продукта или компонента, при котором наблюдения проводятся в статической ситуации без использования специальных процедур. Применяют использование органов чувств, простые физические манипуляции, фиксацию механических или электрических показаний. Инспекция может выполняться в форме обзора, или включать знакомство с документацией и сравнение физических характеристик продукта с заранее установленными стандартами. Например, визуальный осмотр на отсутствие следов износа, или ударов и повреждений при транспортировке изделия.
Анализом именуют метод проверки с применением одобренных аналитических методов, математических моделей, динамических расчетов, алгоритмов, графиков для определения, выполняются ли для конструкции системы заданные требования. Выполняется на основании расчетных данных или результатов верификации компонентов нижестоящих уровней системной структуры. Широко используется на этапах проектирования, когда конечный продукт, прототип или инженерная модель недоступны.
Демонстрация является методом подтверждения рабочей характеристики, чтобы проверить, удовлетворяет ли демонстрируемый продукт требуемым рабочим характеристикам по определенным сценариям. Например, требование об обеспечении доступа водителя ко всем органам управления автомобилем может быть проверено экспертом на макете кабины или тренажере. По сравнению с испытаниями демонстрация подтверждает работоспособность без интенсивного сбора экспериментальной информации.
Испытания включают проверку на стенде динамики работы конечного продукта или подсистемы с целью получения детальных характеристик, либо сбора информации, достаточной для верификации путем дальнейшего анализа. Они выполняются для проверки на соответствие ранее разработанным системным целям, спецификациям и требованиям пользователей. При испытаниях измеряют различные технические характеристики объекта в сравнении с их целевыми значениями, чтобы убедиться, что система соответствует заявленным требованиям. Могут проводиться на готовых конечных продуктах, функциональных моделях, экспериментальных образцах или прототипах. Испытания позволяют получить данные в дискретных точках по каждому установленному требованию в заданном диапазоне контролируемых условий. Испытываемый образец, кроме штатных средств измерения, может быть дополнительно оснащен набором датчиков давлений, температур, напряжений, вибраций для измерения параметров в разных точках системы, и их последующего сравнения с расчетными данными.
Процесс испытаний и оценки системы включает проверку работы подсистем при объединении в целостную систему, оценку обоснованности проектных допущений, и проверку работы системы в различных условиях и режимах работы. Чтобы свести к минимуму необходимость перепроектировать всю систему из-за неисправных компонентов, на испытаниях следует сначала исследовать компоненты, затем подсистемы и работу всей системы. При завершении опытного производства и после интеграции система тестируется, чтобы убедиться, что она удовлетворяет поставленным требованиям.
Испытания являются наиболее ресурсоемкой методикой верификации. Они делятся на три группы.
1. Испытания, проводимые разработчиком, чтобы убедиться, что проект системы соответствует системным требованиям.
2. Испытания, выполняемые изготовителем или строителем для подтверждения качества работ.
3. Испытания, проводимые заказчиком, чтобы убедиться, что система соответствует требованиям пользователя и другим договорным соглашениям.
Если первая группа испытаний выявляет неадекватные характеристики из-за дефектной или плохой конструкции, то этап проектирования необходимо частично повторить. Планировать испытания следует заранее, чтобы выявить проблемы как можно раньше, так как повторение работ требует дополнительных затрат и времени.
Вторая группа испытаний необходима для проверки того, что компоненты и качество изготовления соответствуют системным спецификациям.
Третья группа испытаний состоит из проверочных тестов, обзоров и аудитов, проводимых с участием заказчика. Он должен убедиться, что системные требования выполнены, а документация по испытаниям является полной и точной. В этих испытаниях иногда выявляют недостатки конструкции, которые проектировщики не заметили.
Для сложных систем, связанных с обеспечением безопасности пользователя, выполняются специальные испытания с превышением норм типовых условий эксплуатации, чтобы определить фактические границы возможностей или точку отказа системы. При так называемых стресс-тестах к системе прилагается дополнительная испытательная нагрузка, чтобы определить ее способность работать в более тяжелых, чем это планировалось, условиях. Существует много других типов тестирования: прочностное тестирование, испытания узлов, работа системы в сети, эксплуатационные испытания, тестирование производства, тестирование безопасности, и др.
Методы верификации могут быть разбиты на подвиды.
1. Техническая оценка соответствия требованиям.
2. Поэтапные обзоры результатов.
3. Расчетный анализ.
4. Оценка безопасности компонентов.
5. Стендовые испытания на модельном прототипе или макете.
