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

Принятые решения пересылаются и проверяются на следующей стадии ЭМИ-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) планы тестирования (от ранней до поздней стадии). Желательно продемонстрировать функциональные связи (т.е. небольшие последовательные подфункции), которые при сквозном объединении раскрывают системную функцию.

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

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

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

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

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

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

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

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