Системно-ориентированное проектирование

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

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

SDPD

 

Эффективным способом решения обозначенных сложностей является применение практик системной инженерии. Системная инженерия – это междисциплинарный подход и способы обеспечения процессов создания успешной системы (изделия).

ГК «ПЛМ Урал» занимается адаптацией практик системной инженерии применительно к процессам проектирования изделий. Данный подход называется «Системно-ориентированное проектирование» (или SDPD – System-driven product development).

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

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

СИСТЕМНАЯ ИНЖЕНЕРИЯ

Системно-ориентированное проектирование концентрирует свое внимание на следующих практиках системной инженерии:


 

Моделе-ориентированное проектирование

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

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

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


 

Бизнес-анализ

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

Данная ситуация в конечном итоге, как правило, приводит к следующим ситуациям:

  • Итоговое изделие имеет низкий спрос либо вообще не покупается (нет реальных потребителей).

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

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

  • В ходе реализации проекта выясняется отсутствие необходимых ресурсов (мощностей, специалистов, оборудования, технологий).

В рамках системно-ориентированного проектирования ГК «ПЛМ Урал» рекомендует сосредоточиться на реализации следующих этапов:

  • Разработка концепции использования (CONOPs) – это документ, в котором описывается, как система может работать с разных точек зрения заинтересованных сторон, таких как конечные пользователи, операторы, службы и клиенты.

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

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

  • Разработка ТЭО – документ, в котором представлена информация, из которой выводится целесообразность (или нецелесообразность) создания продукта или услуги. ТЭО содержит анализ затрат и результатов предлагаемого проекта. ТЭО позволяет инвесторам определить, стоит ли вкладывать деньги в предлагаемый проект.

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

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

  • Определены заинтересованные стороны – вы точно понимаете для чего или для кого создается система.

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

  • Определены основные ограничения – вы понимаете, что есть в вашем распоряжении, чего нет, кто мешает, а кто помогает, есть ли у вас ресурсы, мощности, техника, технологии и т.д.


 

Инженерия требований

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

  • В ходе реализации проекта, добавляются новые или меняются существующие требования (что влечет увеличение сроков и стоимости проекта).
  • Требования не выполняются.

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

Инженерия требований направлена на выявление и управление требованиями к проектируемому изделию.

Она включает в себя методики сбора, извлечения, фиксации, трансформации, анализа требований, систематизации трассировки требований с другой инженерной информацией.

В рамках процессов инженерии требований ГК «ПЛМ Урал» рекомендует уделить особое внимание следующим этапам:

  • Разработка контекстной диаграммы.
  • Разработка сценариев использования.
  • Выделение требований заинтересованных сторон.
  • Выделение системных требований.
  • Документирование требований.
  • Трассировка требований.
  • Анализ требований.
  1. Минимизация рисков изменения или добавления новых требований (за счет их детальной проработки).

  2. Инженерия требований создает основу для планирования, обеспечения и контроля выполнения требований.

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

 

Архитектурное проектирование

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

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

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

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

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

Успешная реализация практик архитектурного проектирования обеспечивает достижение следующих результатов:

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

 

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

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

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

Практики верификации (проверки) и валидации (приемки) – это важнейший этап работ по проектированию технической системы. 

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

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

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

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

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

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

  2. Планирование действий по верификации и валидации проектных решений – разработка планов, включающих конкретные действия по верификации и валидации и ответственных за их выполнение.

  3. Выполнение непосредственной верификации и валидации проектной документации – выполнение запланированных действий по верификации и валидации.

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

Применение практик (в рамках SDPD) позволяет:

  1. Трансформировать требования в мероприятия по верификации и валидации. 
  2. Проконтролировать выполнение процессов верификации и валидации.
  3. Получить отчетную информацию о проведенных проверках.
  4. Получить объективные доказательства того, что результаты проектирования удовлетворяют исходным требованиям.

Результатом применения практик (в рамках SDPD) является: 

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

 

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

Процесс проектирования неотъемлемо связан с процессом появления и изменения информации:

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

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

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

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

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

  1. Управление информационными объектами, описывающими проектируемое изделие (требования, модели, атрибуты, структуры, взаимосвязи, документы и т.д.)
  2. Управление версиями информационных объектов.
  3. Формирование отчетной информации (отчеты, графы, матрицы, схемы и т.д.)
  4. Хранение информации о конфигурациях (базовая конфигурация, варианты, опции).
  5. Управление изменениями.
  6. Управление трассировками объектов.
     

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

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

 

Результаты применения практик системно-ориентированного проектирования

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

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

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

  4. Сокращение стоимости, за счет принятия правильных проектных решений, сокращения вносимых изменений и снижение количества натурных испытаний.

Способы реализации системно-ориентированного проектирования

Практическая реализация системно-ориентированного подхода к проектированию базируется на инструментальных компонентах, методологии, компетенциях специалистов и осуществляется в рамках общей стратегии PLM предприятия, с использованием продуктов Siemens PLM Software:

 

  1. Teamcenter  – инструмент архитектурного моделирования (управление конфигурациями, требованиями, процессами и т.д).
  2. NX – инструмент 3D-моделирования. 
  3. Simcenter Amesim – инструмент имитационного моделирования.

ГК «ПЛМ Урал» предлагает набор документов, описывающих как методологию системной инженерии, так и методологию работы с конкретными программными продуктами. 

Подпишитесь на новости