Читать книгу: «Системный подход к управлению высокотехнологичными проектами. 2-е издание, переработанное и дополненное», страница 6

2.6. Синтез системы

На основании принятых решений завершается выполнение проекта (синтез) и процесс интеграции системы. Синтез открывает содержание «как» для каждого пункта «что» и «как хорошо». Продукция синтеза системы включает базовую физическую архитектуру (как спроектировано) и результаты маркетинга подсистем. Место синтеза в общем процессе СИ показано на рис. 5.

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

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

Важнейшим элементом в процессе развития параллельного инжиниринга стало освоение трехмерного электронного макета изделия (ЭМИ), используемого командами проекта 24 часа в сутки. На ЭМИ разрабатывают чертежи и сборки, а также управляют комплектом документации. Работа с ЭМИ существенно снижает время проектирования и затраты. Электронный цифровой макет изделия становится средоточием информации о продукте, определения в ГОСТ 2.051…2.058. Он создается и направляется системой управления данными о продукте, которая поддерживает выпуск технической документации и управление конфигурацией изделия.

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

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

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

Рис. 12. Три этапа «зрелости» ЭМИ

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

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

На базе 3-Д моделей макета второго этапа ЭМИ-2 после «замораживания» всех проектных решений конструкции выпускается рабочая документация (РКД), которая передается намеченным производителям для согласования и доработки технологий производства. Компоненты РКД включают 3-Д модели и сборки согласно ЭМИ, производственные чертежи, спецификацию (график работ), извещения об изменениях, алфавитную базу данных проекта для справочных нужд. Все чаще на сложных изделиях вместо РКД передают в технологическую службу образмеренные (аннотированные) 3-Д модели деталей, согласно стандартам ISO 16792:2015, ASME Y14.41—2012, MIL-STD-31000A.

Разработанная и скорректированная рабочая документация служит основой для финального макета изделия ЭМИ-3 (справочная геометрия, сертификация). Этот макет строится в завершающей стадии конструирования на основании производственных чертежей с технологическими изменениями и служит источником для стадий производства, эксплуатации, разработки модификаций на следующих этапах ЖЦ. Также ЭМИ-3 включает базу сертификационных расчетов на прочность, сборник требований по установке систем и оборудования.

В стандарте ГОСТ Р 58301—2018 «Управление данными об изделии. Электронный макет изделия. Общие требования» предложена классификация моделей, привязанных к основным фазам жизненного цикла. Функциональный макет ЭМИ-Ф включает взаимосвязанную совокупность данных, описывающих устройство, состав, характеристики, принципы работы и возможные нарушения исправного состояния изделия. Конструкторский макет ЭМИ-К содержит взаимосвязанную совокупность данных, описывающих конструкцию и требования к изготовлению и сборке изделия. Технологический макет ЭМИ-Т концентрирует взаимосвязанную совокупность данных, описывающих технологию изготовления и используемых для планирования, оценки и организации процесса производства изделия. Эксплуатационный макет ЭМИ-Э включает взаимосвязанную совокупность данных, описывающих эксплуатационные свойства изделия и требования к процессу его технической эксплуатации.

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

В каждом узле большого проекта должен работать один или несколько ЭМИ-интеграторов, чьи задачи состоят в следующем:

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

• проводить анализ проблем и подтверждать корректность ЭМИ (особенно после фаз интеграции), т.е. проверки, что нет «коллизий», аномальных данных, «наездов» деталей друг на друга;

• управлять качеством данных ЭМИ (рекомендуется иметь выделенного сотрудника, занятого на этой конкретной позиции);

• помогать менеджерам связывать параллельные виды деятельности и интегрировать их результаты внутри процессов параллельного инжиниринга.

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

Вышеперечисленный объем работ нескольких проектных групп одновременно на регулярно актуализируемом ЭМИ и его компонентах, отработка электронных сборок, включающих до 50 000 деталей, позволяют существенно повысить качество выдаваемой конструкторами документации, в 6…10 раз снизить стоимость затрат на корректировки конструкторских решений в производстве. Первым самолетом, спроектированным с использованием электронной документации, был Boeing-777 (в серии с 1995 г.). Его проектирование, разработка и испытания с широким использованием моделирования и виртуального эксперимента, замена физических макетов на ЭМИ позволили получить (сравнительно с созданием предыдущих самолетов В-757, B-767) ряд преимуществ:

a) исключено более 3000 сборочных интерфейсов;

b) получено 90% снижения запросов на изменение РКД (т.е. в 10 раз);

c) на 50% ускорен цикл обработки запросов на изменения;

d) достигнуто 90% снижения переделок конструкции (т.е. в 10 раз);

e) обеспечено улучшение допусков на сборку фюзеляжа (повышена точность подгонки секций).

На рис.13 показано улучшение качества конструкторской документации на разных фазах ЖЦ при использовании ЭМИ. Здесь ПИ обозначает предварительные извещения об изменениях.

Рис. 13. Влияние ЭМИ на снижение числа изменений РКД

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

Напомним некоторые термины и принципы процесса интеграции.

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

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

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

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

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

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

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

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

Принцип планирования интеграции заключается в определении того, сколько времени потребуется для выполнения задач. Для чего определяют тип и количества ресурсов, задержки из-за внутренних и внешних факторов, связанных с выполнением задачи и др. Сетевое планирование прогнозирует влияние на бюджеты и график различных последовательностей и длительностей объектов, которые нужно интегрировать. Управленческий резерв может быть использован для борьбы с неопределенностями, связанными с проблемным или неумелым управлением. Интеграция с эмуляторами (имитаторы компонентов системы) позволяет впервые взглянуть на вопросы интеграции для построения подфункций, пока не станет доступным реальный объект, готовый к тестированию. Процедуры использования эмуляторов для выполнения интеграции, как правило, никогда не совпадают с интеграцией намеченных объектов. Часто производительность эмулятора значительно медленнее, чем у реального объекта.

Интеграция системы проводится на различных уровнях для достижения требуемого эффекта:

• интеграция на уровне компонентов: способность убедиться, что дискретная функция компонента соответствует общей системе, в которой он находится;

• на уровне системы: слияние отдельных функций и характеристик, ранее выполнявшихся дискретными элементами управления, в область общего управления;

• на уровне процесса: постепенное наращивание компонентов продукта в единое работающее и протестированное изделие;

• на функциональном уровне: идентификация интегрированных функций как объединения многих отдельных функций для формирования наглядного эффективного (измеримого) результата.

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

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

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

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

a) аспекты развития (графические ограничения, ресурсы, оборудование, рабочая сила);

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

c) планы тестирования (от ранней до поздней стадии). Желательно продемонстрировать функциональные связи (т.е. небольшие последовательные подфункции), которые при сквозном объединении раскрывают системную функцию.

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

Примерная последовательность шагов интеграции включает несколько этапов.

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

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

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

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

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

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

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

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

Входными данными для процесса интеграции системы являются следующие:

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

• утвержденные требования к системе и подсистемам;

• архитектура проекта высокого уровня, где определены интеграционные операции;

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

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

• разработанные аппаратно-программные компоненты и подсистемы, в которых завершена интеграция на своем уровне и они готовы к следующему уровню верификации.

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

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

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

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

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

5. Тестирование и поддержка оборудования и ПО. При использовании оборудования наземного обслуживания, испытательного оборудования, программного обеспечения следует использовать только те объекты, которые допущены к эксплуатации.

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

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

8. Требования к интерфейсу. Применимые интерфейсы и требования к тестированию должны быть определены и согласованы по всем направлениям по мере необходимости.

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

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

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

Процесс интеграции продукта применяется не только к аппаратным и программным системам, но также к сервис-ориентированным решениям, спецификациям, планам и концепциям.