Доклад В.Аленькова "Подходы к архитектуре системы управления жизненным циклом энергоблока АЭС" на 47 заседании Русского отделения INCOSE 27 июля 2011г. -- вторая половина доклада.
5. Технология разработки архитектуры Выявление типов коллизий Формирование функций СУЖЦ Определение типовых архитектур Формирование вариантов архитектур Анализ Выбор варианта архитектуры
6. Основное назначение СУЖЦ Единая информационная модель Единое информационное пространство Проектирование в 3 D Средства коммуникации через Интернет Предотвращение и выявление коллизий жизненного цикла Современные информационные технологии Современные управленческие технологии Управление конфигурацией и изменениями Параллельный инжиниринг Коллаборативный инжиниринг Единая модель жизненного цикла Модели рабочих процессов
7.
8.
9.
10. Коллизии и их влияние на проект Жизненный цикл коллизии Выявление Анализ Идентификация Коллизия – одна из основных причин внесения изменений в проект! Решение об инициации изменения Оценка и анализ Планирование ЖЦ изменения Предотвра-щение Выполнение Верификация
11. Зависимость стоимости внесения изменений от стадии ЖЦ Источник : INCOSE Systems Engineering Handbook v. 3.2 Раннее выявление коллизий приводит к снижению стоимости внесения изменений
12. Коллизии, требующие выявления в СУЖЦ (1 /2) Intergraph SPF Межплатформенные и межогранизационные виртуальные коллизии Siemens Teamcenter Enovia Уровень PDM Intergraph P&ID, 3D, Electrical, Instrumentation NX CATIA Primavera АТОМСМЕТА Уровень CAx
13. Коллизии, требующие выявления в СУЖЦ (2 /2) Intergraph SPF Все виртуально-реальные коллизии Siemens Teamcenter Enovia Уровень PDM Intergraph P&ID, 3D, Electrical, Instrumentation NX CATIA Primavera АТОМСМЕТА Уровень CAx Уровень фиксации информации о реальном энергоблоке Архив ИД ИС Управления Закупками ИСУП КС
14. Типы коллизий, выявленные по результатам анкетирования сотрудников НИАЭП (1 /2) На соответствие требованиям Изменение Нормативных требований во время выпуска ТП Внесение доп. требований Заказчика при согласования РД Геометри-ческие Несовпадение мест стыковки РУ и внешних систем энергоблока Коллизии виртуальные Схемные Несоответствия электрических систем и АСУ, разрабатываемых ГенПроектировщиком и различными субподрядчиками, выявляемые при разработке РД и при проведении ПНР Несоответствия арматуры режиму гидроиспытаний, выявляемые при ПНР Актуальности Неактуальность 3 D моделей, используемых для Multi-D проектирования
15. Типы коллизий, выявленные по результатам анкетирования сотрудников НИАЭП (2 /2) Планирования сооружения Несоответствие графика поставки графику сооружения Несоответствие графика выпуска РД графику сооружения Коллизии виртуально-реальные По факту выполненных СМР По факту закупки и поставки Несоответствие по факту поставляемой арматуре Несоответствие сетевой модели графика сооружения натурным зависимостям Отклонения от РД, зафиксированные в ИД Несоответствие реального графика финансирования и финансирования по Multi-D модели Несоответствие фактически поставляемым строительным материалам и конструкциям Несоответствие материала изготавливаемых трубопроводов Отсутствие запланированных ресурсов на площадке Несоответствие по факту поставляемому оборудованию
16. Частота возникновения и трудоёмкость устранения типов коллизий (1 /2) Наименование коллизии Частота возникновения Трудоёмкость ( человеко-дни ) и длительность устранения Несоответствие по факту закупаемой и поставляемой арматуры 100% арматуры (некоторые позиции меняются несколько раз) 15 ч / дн (внесение изменений и согласование внутри НИАЭП) + 30 дн. (мин. срок согласования и утверждения у Заказчика) Несоответствие по факту поставляемого оборудования 30-40% оборудования (случаи замены основного оборудования редки) 30-80 ч / дн + 30 дн. Внесение дополнительных требований Заказчика во время согласования РД 30-50% 30 ч / дн +30 дн. Несоответствие строительных материалов при изготовлении и монтаже 60% 10-15 ч / дн + 30 дн. Несоответствие материала изготавливаемых трубопроводов 20% 30 ч / дн +30 дн. Отклонения от РД, зафиксированные в ИД 20% 15-65 ч / дн + 30 дн. Несоответствия электрических систем и АСУ, разрабатываемых ГенПроектировщиком и различными субподрядчиками, выявляемые при разработке РД и при проведении ПНР 20% (РД) , 50% (ПНР) 2 недели (субподрядчиком) + 10 ч / дн (НИАЭП) +30 дн.
17. Частота возникновения и трудоёмкость устранения типов коллизий ( 2/2) Наименование коллизии Частота возникновения Трудоёмкость ( человеко-дни ) и длительность устранения Несоответствие реального графика поставки графику сооружения происходит непрерывно, фиксируется 1 раз / месяц (в ходе актуализации) 10 ч / дн Несоответствие графика выпуска РД графику сооружения происходит непрерывно, фиксируется 1 раз / месяц Сложно оценимая трудоёмкость Отсутствие запланированных ресурсов на площадке происходит непрерывно, фиксируется 1 раз / месяц Сложно оценимая трудоёмкость Несоответствие сетевой модели графика сооружения натурным зависимостям происходит непрерывно, фиксируется 1 раз / месяц Сложно оценимая трудоёмкость Изменение нормативных требований (НТД) во время выпуска Тех. Проекта редко Большая сложно оценимая трудоёмкость Несовпадение мест стыковки РУ и внешних систем энергоблока редко Сложно оценимая трудоёмкость Несоответствия арматуры режиму гидроиспытаний, выявляемые при ПНР редко Сложно оценимая трудоёмкость Неактуальность 3D моделей, используемых для Multi-D н / д 15-20 ч / дн на помещение РО, 40 ч / дн на зону машзала Несоответствие реального графика финансирования и финансирования по Multi-D модели н / д н / д
19. Укрупненный состав функций СУЖЦ Проектирование Сооружение 1 Предотвращение коллизий 1.1 Управление конфигурацией 1.1.1 Консолидация информационной модели (ИМ) 1.1.2 Управление изменениями ИМ 1.1.3 Поддержка тиражирования типового энергоблока 1.2 Устранение повторного ручного ввода данных ИМ 1.2.1 Автоматизация обмена данными между интегрированными с СУЖЦ системами 1.3 Поддержка Коллаборативного инжиниринга 1.4 Поддержка Параллельного инжиниринга 2 Выявление коллизий 3 Управление развитием СУЖЦ 4 Обеспечение безопасности данных в масштабах СУЖЦ
24. Фиксация базовых конфигураций энергоблока в СУЖЦ 5. Сооружение 1. Разработка Концепт-проекта 4 . Разработка рабочей документации 3. Разработка технического проекта 2 . Разработка технического задания Заказчик Эксплуатант Заказчик Генпродрядчик Концепт-проект Техническое Задание Технический Проект Рабочая Документа-ция Исполните-льная Документа-ция
25. Фиксация базовых конфигураций энергоблока в СУЖЦ 5. Сооружение 1. Разработка Концепт-проекта 4 . Разработка рабочей модели 3. Разработка проектной модели 2 . Разработка модели требований Базис 4: ИД (Исполни-тельная модель) Заказчик Эксплуатант Заказчик Генпродрядчик « as built » Базис 1 : ТЗ (Модель требований) Базис 2: ТП (Проектная модель) Базис 3: РД (Рабочая модель) « as developed » « as designed » « as required » Концепт-проект
26.
27.
28. Развилки архитектуры интеграционных решений Интеграционные решения типа «точка-точка» Единый формат обмена данными? Формат обмена? Да Нет ISO 15926 STEP Средство реализации? XMPlant iRING
29. Необходим единый формат обмена данными Единый формат Упрощение создания интеграционных решений Унификация интеграционных решений Архитектура ИМ хранится децентрализовано С центральным репозиторием ИМ Наличие центрального Репозитория ИМ? Откуда Консолиди- ровать?
30. Контроль изменения элементов конфигурации в СУЖЦ СУЖЦ Информация о потенциальном изменении Изменение необходимо Экспертная оценка целесообразности проведения изменения СУЖЦ Обновленные данные о конфигурации ЭБ Анализ влияния изменения за счет трассировки информации Сквозное межсистемное проведение изменений Атомсмета Primavera Enovia Teamcenter SmartPlant Foundation
34. Параллельный инжиниринг vs Традиционный подход Формирование требований Проектирование Разработка РД Моделирование сооружения ЖЦ Энергоблока ЖЦ Энергоблока Формирование требований Проектирование Разработка РД Моделирование сооружения Параллельный инжиниринг – организационная технология проектирования и разработки, предполагающая выполнение работ разных стадий жизненного цикла с частичным перекрытием по времени Перекрытие выполняется как правило, в части анализа и согласования результатов предыдущих стадий ЖЦ Традиционный подход (водопад) Параллельный инжиниринг
35.
36. При Параллельном Инжиниринге многие коллизии, которые могут возникнуть на более поздних стадиях ЖЦ, выявляются и решаются на ранних стадиях, когда стоимость внесения изменений на порядки меньше Параллельный инжиниринг: уменьшение стоимости за счёт предотвращения и раннего выявления коллизий График стоимости внесения изменений График выявления коллизий при Параллельном Инжиниринге График выявления коллизий при традиционном подходе Требования Концепт Проект РД Сооружение Требования Концепт Проект РД Сооружение График накопленной стоимости изменений при Параллельном Инжиниринге Требования Концепт Проект РД Сооружение График накопленной стоимости изменений при традиционном подходе График частоты выявления коллизий График накопленной стоимости внесения изменений
41. Совместный инжиниринг ( Collaborative engineering) с использованием СУЖЦ Производитель Конструктор Управление закупками и кооперацией Поставщик Руководитель программы Управление сооружением Проектировщик СУЖЦ Совместная работа удаленных команд внутри СУЖЦ, использующей данные разных систем «Бесшовное» объединение инжиниринговой деятельности на всех этапах жизненного цикла ЭБ
42. СУЖЦ как средство реализации совместного инжиниринга (1/2) СУЖЦ Совместная работа с данными систем, интегрированных с СУЖЦ Управление коллизиями, возникающими в процессе создания ЭБ Управление конфигурацией и изменениями Распределённая разработка ЭБ на протяжении всего его жизненного цикла Оперативная информация о коллизиях возникающих, в процессе совместных работ Организация дискуссий и конференций для территориально распределённых команд, партнёров и поставщиков в рамках обсуждения коллизий Предоставление информации из других систем через интерфейс СУЖЦ широкому кругу заинтересованных лиц (руководство предприятия, территориально удалённые офисы, партнёры, поставщики) Реализация механизма трассировки данных и требований из разных систем в СУЖЦ с возможностью оценки влияния их друг на друга при проведении изменений Оперативная информация обо всех изменениях и новых данных в конфигурации ЭБ с реализацией механизмов их согласования со всеми задействованными сторонами
43. СУЖЦ как средство реализации совместного инжиниринга (2/2) СУЖЦ Интерфейс СУЖЦ, обеспечивающий возможность выполнения совместных работ Поддержка делового общения между участниками Обеспечение безопасного доступа к СУЖЦ при совместных работах Ускоренное освоение работы с системой в том числе и не инженерному персоналу Поддержка дискуссий (форумы) Синхронизация и индексирование данных Поддержка проведения совещаний с территориально удаленными участниками (Web-конференции) Обеспечение единства доступа (один логин и пароль) через СУЖЦ ко всем ИС, интегрированным с СУЖЦ Управление правами доступа к элементам данных при их совместном использовании
44. Отличие системы управления изменениями при коллаборативном инжиниринге Традиционный подход Коллаборативный инжиниринг Информация доступна после окончания разработки Работа в разрозненных информационных пространствах Информирование об начавшемся изменении в конце разработки Оперативный доступ к актуальной информации Единое информационное пространство Автоматическое уведомление об изменениях
46. Место СУЖЦ в информационном пространстве проекта Intergraph SPF СУЖЦ Уровень cPLM Siemens Teamcenter Enovia Уровень PLM Intergraph P&ID, 3D, Electrical, Instrumentation NX CATIA Primavera АТОМСМЕТА Уровень CAx
47. Развилки вариантов архитектуры Архитектура ИМ хранится децентрализовано С центральным репозиторием ИМ Консолидация данных напрямую из CAx систем Консолидация данных из PDM/PLM систем Наличие центрального Репозитория ИМ? Откуда Консолиди- ровать? Платформа Репозитория? Intergraph SPF DSS Enovia Siemens Teamcenter ISO 15926 Triplestore 1 2 № № рассматриваемого варианта архитектуры 2 3 3 4 4 2 3 4 AVEVA NET Portal PTC Windchill
48. Вариант реализации СУЖЦ – интеграция Intergraph SPF СУЖЦ Уровень PLM Siemens Teamcenter Enovia Уровень PDM Intergraph P&ID, 3D, Electrical, Instrumentation NX CATIA Primavera АТОМСМЕТА Уровень CAx
49.
50. Вариант реализации СУЖЦ –Регистр Intergraph SPF Уровень PLM Siemens Teamcenter Enovia Уровень PDM Intergraph P&ID, 3D, Electrical, Instrumentation NX CATIA Primavera АТОМСМЕТА Уровень CAx СУЖЦ Ссылки на данные ИМ
51. Вариант реализации СУЖЦ –Репозитарий Intergraph SPF Уровень PLM Siemens Teamcenter Enovia Уровень PDM Intergraph P&ID, 3D, Electrical, Instrumentation NX CATIA Primavera АТОМСМЕТА Уровень CAx СУЖЦ Консолидация данных ИМ
52. Варианты архитектуры Вариант архитектуры 1 Вариант архитектуры 2 Вариант архитектуры 3 Вариант архитектуры 4 SPF Teamcenter Primavera АТОМСМЕТА CAx CAx SPF Teamcenter Primavera АТОМСМЕТА CAx CAx Enovia SPF Teamcenter Primavera АТОМСМЕТА CAx CAx Primavera АТОМСМЕТА CAx CAx Enovia CAx
Зачем нужны современные информационные и управленческие технологии
Прямая автоматизация традиционных способов проектирования и конструирования приводит к не достижению целей данной автоматизации заключающихся в повышении эффективности как самого проектирования и конструирования так и всего жизненного цикла системы в связи с тем, что на данном этапе закладываются большая часть его стоимости. Так из анализа статистических данных проектов министерства обороны США следует что на этапе проектирования и конструирования принимаются решения определяющие 8 0 % стоимости жизненного цикла системы. Не умоляя значения остальных стадий жизненного цикла можно предположить что именно на повышение качества результатов данных стадий в первую очередь и должны быть направлены усилия.
Всего возможных вариантов архитектуры (комбинаций) – 13 шт. Рассматриваем только 4, почему? - Вариант архитектуры с Siemens или PTC как платформы репозитория не рассматриваем так как в них изначально не предусмотрена возможность хранения информационной модели энергоблока в ее строительной и технологической части ( P & ID , электрические схемы, 3 D модели (интелектуальные) строительных конструкций и т.д.) в связи с чем становится не возможным выполнять функции СУЖЦ по отношению к ним: управлять их конфигурацией и выявлять коллизии с ними, передавать их на стадии ЖЦ «Сооружение» и «Эксплуатация» без существенной доработки систем. (-4 варианта) - Вариант архитектуры с AVEVA как платформы репозитория не рассматриваем так как есть уже аналог – Intergraph, есть специалисты, обученные люди, опыт применения и т.д. Также в AVEVA Net Portal отсутствуют средства выявления коллизий и системы управления конфигурацией. Есть только накопление и просмотр документов. (-2 варианта). - Вариант архитектуры с ISO 15926 Triplestore (какой либо из имеющихся на рынке) не рассматриваем так как в них есть возможность консолидации данных но нет средств для удобной работы с ними (просмотра, навигации, выявления коллизий и т.д.) так как они являются СУБД (-2 варианта). - Вариант архитектуры с SPF как единой PDM/PLM системы не рассматриваем так как в нем отсутствует функционал по управлению конфигурацией и изменениями конструкторской части. (-1 вариант) Итого из 13 вариантов убираем 9 остается 4.
Всего возможных вариантов архитектуры (комбинаций) – 13 шт. Рассматриваем только 4, почему? - Вариант архитектуры с Siemens или PTC как платформы репозитория не рассматриваем так как в них изначально не предусмотрена возможность хранения информационной модели энергоблока в ее строительной и технологической части ( P & ID , электрические схемы, 3 D модели (интелектуальные) строительных конструкций и т.д.) в связи с чем становится не возможным выполнять функции СУЖЦ по отношению к ним: управлять их конфигурацией и выявлять коллизии с ними, передавать их на стадии ЖЦ «Сооружение» и «Эксплуатация» без существенной доработки систем. (-4 варианта) - Вариант архитектуры с AVEVA как платформы репозитория не рассматриваем так как есть уже аналог – Intergraph, есть специалисты, обученные люди, опыт применения и т.д. Также в AVEVA Net Portal отсутствуют средства выявления коллизий и системы управления конфигурацией. Есть только накопление и просмотр документов. (-2 варианта). - Вариант архитектуры с ISO 15926 Triplestore (какой либо из имеющихся на рынке) не рассматриваем так как в них есть возможность консолидации данных но нет средств для удобной работы с ними (просмотра, навигации, выявления коллизий и т.д.) так как они являются СУБД (-2 варианта). - Вариант архитектуры с SPF как единой PDM/PLM системы не рассматриваем так как в нем отсутствует функционал по управлению конфигурацией и изменениями конструкторской части. (-1 вариант) Итого из 13 вариантов убираем 9 остается 4.
Три основных подфункции управления конфигурацией это первая
Три основных подфункции управления конфигурацией это первая
Всего возможных вариантов архитектуры (комбинаций) – 13 шт. Рассматриваем только 4, почему? - Вариант архитектуры с Siemens или PTC как платформы репозитория не рассматриваем так как в них изначально не предусмотрена возможность хранения информационной модели энергоблока в ее строительной и технологической части ( P & ID , электрические схемы, 3 D модели (интелектуальные) строительных конструкций и т.д.) в связи с чем становится не возможным выполнять функции СУЖЦ по отношению к ним: управлять их конфигурацией и выявлять коллизии с ними, передавать их на стадии ЖЦ «Сооружение» и «Эксплуатация» без существенной доработки систем. (-4 варианта) - Вариант архитектуры с AVEVA как платформы репозитория не рассматриваем так как есть уже аналог – Intergraph, есть специалисты, обученные люди, опыт применения и т.д. Также в AVEVA Net Portal отсутствуют средства выявления коллизий и системы управления конфигурацией. Есть только накопление и просмотр документов. (-2 варианта). - Вариант архитектуры с ISO 15926 Triplestore (какой либо из имеющихся на рынке) не рассматриваем так как в них есть возможность консолидации данных но нет средств для удобной работы с ними (просмотра, навигации, выявления коллизий и т.д.) так как они являются СУБД (-2 варианта). - Вариант архитектуры с SPF как единой PDM/PLM системы не рассматриваем так как в нем отсутствует функционал по управлению конфигурацией и изменениями конструкторской части. (-1 вариант) Итого из 13 вариантов убираем 9 остается 4.
Всего возможных вариантов архитектуры (комбинаций) – 13 шт. Рассматриваем только 4, почему? - Вариант архитектуры с Siemens или PTC как платформы репозитория не рассматриваем так как в них изначально не предусмотрена возможность хранения информационной модели энергоблока в ее строительной и технологической части ( P & ID , электрические схемы, 3 D модели (интелектуальные) строительных конструкций и т.д.) в связи с чем становится не возможным выполнять функции СУЖЦ по отношению к ним: управлять их конфигурацией и выявлять коллизии с ними, передавать их на стадии ЖЦ «Сооружение» и «Эксплуатация» без существенной доработки систем. (-4 варианта) - Вариант архитектуры с AVEVA как платформы репозитория не рассматриваем так как есть уже аналог – Intergraph, есть специалисты, обученные люди, опыт применения и т.д. Также в AVEVA Net Portal отсутствуют средства выявления коллизий и системы управления конфигурацией. Есть только накопление и просмотр документов. (-2 варианта). - Вариант архитектуры с ISO 15926 Triplestore (какой либо из имеющихся на рынке) не рассматриваем так как в них есть возможность консолидации данных но нет средств для удобной работы с ними (просмотра, навигации, выявления коллизий и т.д.) так как они являются СУБД (-2 варианта). - Вариант архитектуры с SPF как единой PDM/PLM системы не рассматриваем так как в нем отсутствует функционал по управлению конфигурацией и изменениями конструкторской части. (-1 вариант) Итого из 13 вариантов убираем 9 остается 4.
Всего возможных вариантов архитектуры (комбинаций) – 13 шт. Рассматриваем только 4, почему? - Вариант архитектуры с Siemens или PTC как платформы репозитория не рассматриваем так как в них изначально не предусмотрена возможность хранения информационной модели энергоблока в ее строительной и технологической части ( P & ID , электрические схемы, 3 D модели (интелектуальные) строительных конструкций и т.д.) в связи с чем становится не возможным выполнять функции СУЖЦ по отношению к ним: управлять их конфигурацией и выявлять коллизии с ними, передавать их на стадии ЖЦ «Сооружение» и «Эксплуатация» без существенной доработки систем. (-4 варианта) - Вариант архитектуры с AVEVA как платформы репозитория не рассматриваем так как есть уже аналог – Intergraph, есть специалисты, обученные люди, опыт применения и т.д. Также в AVEVA Net Portal отсутствуют средства выявления коллизий и системы управления конфигурацией. Есть только накопление и просмотр документов. (-2 варианта). - Вариант архитектуры с ISO 15926 Triplestore (какой либо из имеющихся на рынке) не рассматриваем так как в них есть возможность консолидации данных но нет средств для удобной работы с ними (просмотра, навигации, выявления коллизий и т.д.) так как они являются СУБД (-2 варианта). - Вариант архитектуры с SPF как единой PDM/PLM системы не рассматриваем так как в нем отсутствует функционал по управлению конфигурацией и изменениями конструкторской части. (-1 вариант) Итого из 13 вариантов убираем 9 остается 4.
Всего возможных вариантов архитектуры (комбинаций) – 13 шт. Рассматриваем только 4, почему? - Вариант архитектуры с Siemens или PTC как платформы репозитория не рассматриваем так как в них изначально не предусмотрена возможность хранения информационной модели энергоблока в ее строительной и технологической части ( P & ID , электрические схемы, 3 D модели (интелектуальные) строительных конструкций и т.д.) в связи с чем становится не возможным выполнять функции СУЖЦ по отношению к ним: управлять их конфигурацией и выявлять коллизии с ними, передавать их на стадии ЖЦ «Сооружение» и «Эксплуатация» без существенной доработки систем. (-4 варианта) - Вариант архитектуры с AVEVA как платформы репозитория не рассматриваем так как есть уже аналог – Intergraph, есть специалисты, обученные люди, опыт применения и т.д. Также в AVEVA Net Portal отсутствуют средства выявления коллизий и системы управления конфигурацией. Есть только накопление и просмотр документов. (-2 варианта). - Вариант архитектуры с ISO 15926 Triplestore (какой либо из имеющихся на рынке) не рассматриваем так как в них есть возможность консолидации данных но нет средств для удобной работы с ними (просмотра, навигации, выявления коллизий и т.д.) так как они являются СУБД (-2 варианта). - Вариант архитектуры с SPF как единой PDM/PLM системы не рассматриваем так как в нем отсутствует функционал по управлению конфигурацией и изменениями конструкторской части. (-1 вариант) Итого из 13 вариантов убираем 9 остается 4.
Всего возможных вариантов архитектуры (комбинаций) – 13 шт. Рассматриваем только 4, почему? - Вариант архитектуры с Siemens или PTC как платформы репозитория не рассматриваем так как в них изначально не предусмотрена возможность хранения информационной модели энергоблока в ее строительной и технологической части ( P & ID , электрические схемы, 3 D модели (интелектуальные) строительных конструкций и т.д.) в связи с чем становится не возможным выполнять функции СУЖЦ по отношению к ним: управлять их конфигурацией и выявлять коллизии с ними, передавать их на стадии ЖЦ «Сооружение» и «Эксплуатация» без существенной доработки систем. (-4 варианта) - Вариант архитектуры с AVEVA как платформы репозитория не рассматриваем так как есть уже аналог – Intergraph, есть специалисты, обученные люди, опыт применения и т.д. Также в AVEVA Net Portal отсутствуют средства выявления коллизий и системы управления конфигурацией. Есть только накопление и просмотр документов. (-2 варианта). - Вариант архитектуры с ISO 15926 Triplestore (какой либо из имеющихся на рынке) не рассматриваем так как в них есть возможность консолидации данных но нет средств для удобной работы с ними (просмотра, навигации, выявления коллизий и т.д.) так как они являются СУБД (-2 варианта). - Вариант архитектуры с SPF как единой PDM/PLM системы не рассматриваем так как в нем отсутствует функционал по управлению конфигурацией и изменениями конструкторской части. (-1 вариант) Итого из 13 вариантов убираем 9 остается 4.