Процессы системной инженерии для поддержания жизненного цикла сложных технических систем Текст научной статьи по специальности «Экономика и бизнес»

Баданов А.Ю., Рызванов Р.А. ©

Инженер 2к.; Инженер-программист 2к.

Центральный аэрогидродинамический институт (ЦАГИ), г. Жуковский

ПРОЦЕССЫ СИСТЕМНОЙ ИНЖЕНЕРИИ ДЛЯ ПОДДЕРЖАНИЯ ЖИЗНЕННОГО ЦИКЛА СЛОЖНЫХ ТЕХНИЧЕСКИХ СИСТЕМ

Аннотация

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

Ключевые слова: жизненный цикл, системная инженерия, процессы системной инженерии, движок системной инженерии.

Keywords: life cycle, systems engineering, life cycle processes, systems engineering engine.

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

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

Для детального управления ЖЦ при создании ЛА в системной инженерии NASA существует 17 технических процессов. Это процессы системного проектирования: с подходом сверху-вниз для каждого продукта в системной структуре; процесс реализации продукта для подхода снизу-вверх для каждого компонента в системной структуре; процессы технического менеджмента для планирования и контроля сборки системы; процессы сборки компонентов для обеспечения технических решений.

На рисунке 1 приведена итеративная многомерная V-модель жизненного цикла сложной системы.

© Баданов А.Ю., Рызванов Р. А., 2016 г.

Рис. 1 - Итеративная V- модель жизненного цикла

<

рабочее

проектирование

Рис.2 - V-модель упрощённого представления ЖЦ сложный системы с вехами

системной инженерии

В системной инженерии применяются следующие процессы: Процесс определения ожиданий стейкхолдеров (заинтересованных лиц).

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

• функционирующие конечные продукты и продукты обеспечивающих систем слоя продукта;

• ценовая доступность;

• интерфейс пользователя;

• ожидаемые навыки и возможности операторов или пользователей;

• ожидаемое количество одновременной работы пользователей;

• критерии эффективности системы и человека;

• технические стандарты, правила, законы;

• факторы безопасности;

• защиты окружающей среды;

• качество;

• надежность;

• удобство поддержки;

• электромагнитная совместимость;

• удобство тестирования;

• удобство транспортировки;

• удобство использования и утилизации.

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

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

Процесс логической декомпозиции.

Процесс логической декомпозиции(РБ8) используется для понимания определённых технических требований и отношений между ними. А также для преобразования определенных требований в набор моделей логических декомпозиций и их связей с техническими требованиями для более низких уровней в системной иерархии. Также процесс логической декомпозиции задает входные данные для процесса определения проектного решения.

Процесс определения проектного решения.

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

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

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

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

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

Процесс валидации продукта.

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

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

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

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

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

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

Процесс управления техническим риском.

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

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

Этот процесс для конечных продуктов и обеспечивающих систем используется:

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

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

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

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

цикла.

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

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

Процесс технической оценки.

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

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

При сравнении процессов жизненного цикла стандарта ISO/IEC 15288 и процессов NASA становиться ясно, что основные процессы повторяют друг друга, причем если процессы NASA дают более полное описание по сравнению с редакцией стандарта 2008 года, то редакция стандарта 2015 года дополняет процессы системной инженерии, что дает более полную картину для управления жизненным циклом. Для эффективного использования концепции управления жизненным циклом необходимо использовать практический опыт NASA, описанный в многочисленных книгах и статьях.

В 2015 годы была принята новая редакция стандарта ISO 15288, что привело к появлению новых процессов, взятых из лучших практик NASA, представленных в таблице 1.

Таблица 1

Процессы стандарта ISO/IEC 15288

КОЛЕС 15288:2008 КОЛЕС 15288:2015

6.1 Процессы соглашения 6.1.1 Закупка 6.2.1 Поставка 6.2. Обеспечение проектов 6.2.1 Описывание жизненного цикла 6.2.2 Управление инфраструктурой 6.2.3 Управление портфелем проектов 6.1 Процессы соглашения 6.1.1 Закупка 6.2.1 Поставка 6.2. Обеспечение проектов 6.2.1 Описывание жизненного цикла 6.2.2 Управление инфраструктурой 6.2.3 Управление портфелем проектов

ISO/IEC 15288:2008 ISO/IEC 15288:2015

6.2.4 Управление персоналом 6.2.4 Управление персоналом

6.2.5 Управление качеством 6.2.5 Управление качеством

6.3 Проектные процессы 6.2.6 Управление знаниями

6.3.1 Управление проектами 6.3 Проектные процессы

6.3.2 Планирование проекта 6.3.1 Управление проектами

6.3.3 Управление выполнением и контроль 6.3.2 Планирование проекта

проекта 6.3.3 Управление выполнением и контроль

6.3.4 Поддержка проектов проекта

6.3.5 Управление решениями 6.3.4 Поддержка проектов

6.3.6 Управление рисками 6.3.5 Управление решениями

6.3.7 Управление конфигурацией 6.3.6 Управление рисками

6.3.8 Управление информацией 6.3.7 Управление конфигурацией

6.3.9 Измерения 6.3.8 Управление информацией

6.4 Технические процессы 6.3.9 Измерения

6.4.1 Сбор требований 6.3.10 Обеспечение качества

6.4.2 Анализ требований 6.4 Технические процессы

6.4.3 Архитектурный дизайн 6.4.1 Анализ бизнес-процессов

6.4.4 Изготовление 6.4.2 Потребности стейкхолдеров и

6.4.5 Интеграция процессы определения требований

6.4.6 Верификация (проверка) 6.4.3 Выявление системных требований

6.4.7 Переход к эксплуатации 6.4.4 Определение архитектуры

6.4.8 Валидация (приёмка) (компоновка)

6.4.9 Эксплуатация 6.4.5 Тактико-технические требования

6.4.10 Обслуживание 6.4.6 Системный анализ

6.4.11 Вывод из эксплуатации 6.4.7 Изготовление

6.4.8 Интеграция

6.4.9 Верификация (проверка)

6.4.10 Переход к эксплуатации

6.4.11 Валидация (приёмка)

6.4.12 Эксплуатация

6.4.13 Обслуживание

Вывод из эксплуатации

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

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

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

Требования, вытекающее из более высокого уровня

Продукты уходят не на более высокий уровень

Процессы разработки системы

Процессы инженерии требовании

1. Определение стейкходцеров

2. Определение технических требовании

Процессы определения технических решений

3. Логическая дек омпозшшя

4. Определение конструкторских решений

Процессы управления

Процесс технического планирования 10. Техническое планирование

Процессы технического управления

11. Управление требованиями

12. Управление интерфейсами

13. Управление техническими рисками

14. Управление конфигурацией

15. Управление техническими данными

Процесс технической оценки 16. Техническая станса

Процесс аналн 13 технических решений

17. Анализ решений

Процессы воплощения системы

Процесс передачи в эксплуатацию 9. Передача пр одукта

Процессы оценки

7 Верификация 8. Ваирация

Процессы воплощения

5. Сборка

6. Интеграция

Тр.

ео о ванн я, уход ящ не н а более низкий уровень

Процессы проектирования целевой системы применяют для каждой структурной декомпозиции работ и каждого элемента вниз по иерарх 1С [ конструкции системы

Продукты с более низкого уровня

Процессы воплощения системы применяют для каждого элемента по всем выш естоящим уровням иерархии конструкции системы

Рис. 3 - «Движок» системной инженерии

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

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

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

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

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

На рисунке 4 показано, как три основных набора процессов «движка» системной инженерии (процесс проектирования системы, процесс создания (реализации) продукта и процесс технического менеджмента) применяются к каждому уровню продукта в структуре системы.

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

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

Информационный поток С более высокого уровня

Переход реализованного продукта на более высокий уровень

Комплексные процессы

Процесс технического плл жирования

10Техническое планирование

Процесс, техническое контроля

11 Управne Hse требованиями

12 правление интерфейсом

13 Управление техническими рисками 14управление конфигурацией

15 Управле ние данными

Процесс технической оценки

16Техническая оценка

Процесс анвлия текчичес« их решений

17 Анализ решений

Информационный поток на более низкий уровень

Структура системы

Проектирование системы

Реализация продукта снизу вверх

Рис. 4 - Применение «движка СИ» к структуре системы

Отметим также весьма важную особенность официальных стандартов системной инженерии, эти спецификации, например, базовый стандарт ISO/IEC 15288, носят явно выраженный рамочный характер, т.е. предполагается, что содержащиеся в этих стандартах рекомендации должны обязательно адаптироваться к условиям конкретной инженерной деятельности. Такой подход предполагает, что в определенной отрасли или в крупной корпорации с учетом рекомендаций официальных стандартов должны быть разработаны свои нормативно- технические акты, регулирующие инженерную деятельность. Подобные рекомендации разрабатываются профессиональными сообществами, государственными

организациями, осуществляющими закупки систем в интересах правительства, а также крупными корпорациями, занятыми созданием сложных систем. В качестве примера можно привести руководства Международного совета по системной инженерии (International Council on Systems Engineering — INCOSE), Руководство федерального управления гражданской авиации США (Federal Aviation Administration — FAA), Руководство военно-морского ведомства США, Руководство Министерства обороны США (Department of Defense), Руководство Национального космического агентства США — NASA (National Aeronautics and Space Administration). Кроме того, военные ведомства, которые в больших количествах закупают сложные системы, разрабатывают их.

Многие процессы системной инженерии оказались настолько востребованными, что на их основе были написаны программные средства, которые с успехом применяются агентствами в США (NASA, DoD) и коммерческими фирмами. Например, такие гиганты как Siemens PLM, Dassault Systems, Autodesk имеют программное обеспечение для управления техническими процессами и разработкой целевой системы на протяжении всего ЖЦ, но без понимания идеологии системной инженерии, большая вероятность не рационального использования данных инструментов. Важным моментом применения на практике процессов системной инженерии является то, что международный стандарт ISO 15288 не дает базовой идеологии системного мышления и не предоставляет конкретные механизмов для применения их на практике. И если программное обеспечение можно приобрести в виде готовых продуктов, то идеологию системного подхода к управлению жизненным циклом необходимо адаптировать с учетом применения лучших международных практик, в том числе DoD и NASA.

Список сокращений

IRL-интеграционные уровни готовности PBS-иерархическая структура продукта SEMP-План управление системной инженерии WBS-иерархическая структура работ TRL-уровни готовности технологий

Литература

1. NASA SP-2007-6105 Rev 1 Final 31Dec2007

2. ISO/IEC/IEEE 15288:2015 System and software engineering - System life cycle processes

3. SE Handbook v3 2 1 2011-0216 Approved INCOSE_8.5x11

4. Министерство промышленности и торговли Российской Федерации- Стандарты системной инженерии. Москва - Санкт-Петербург 2012 г.

5. Министерство промышленности и торговли Российской Федерации- Управление жизненным циклом технических систем. Москва - Санкт-Петербург 2012 г.

6. В.С. Криворученко, И.П. Дмитренко, А.Ю. Баданов, Р.А. Рызванов; «Уровни готовности и интеграции технологий», материалы XII международной научно-практической конференции «Интеграция науки и практики как механизм эффективного развития современного общества» 2014 г., г. Москва.

7. А.Ю. Баданов, Р.А. Рызванов; «Модель жизненного цикла системной инженерии для создания инновационного летательного аппарата», материалы XIX международной научно-практической конференции «Интеграция науки и практики как механизм эффективного развития современного общества» 12-13 апреля 2016г., г. Москва Институт стратегических исследований.