От объекта к системе

Глава 16б. Как PLM эволюционировал от управления состоянием к управлению вариантами

16б.1. От одной задачи к нескольким

Предыдущая глава установила принципиальное различие.

Configuration Management управляет конфигурацией изделия и информацией о её состоянии.

Управление вариантами решает другую задачу — работает с возможными разновидностями изделия.

Но современные PLM-платформы обычно должны решать обе задачи. Это не случайность.

PLM развивались не как чистая реализация одного стандарта. Они постепенно включали всё больше инженерных процессов.

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

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

Что происходит, если новую задачу добавляют не вместе с новой моделью, а поверх уже существующей?

16б.2. Эволюция существующей модели

Исторически Configuration Management сформировалось как дисциплина управления инженерной информацией, изменениями и состояниями.

Системы управления инженерными данными затем стали электронными системами управления документами. Следующим шагом стало управление структурой изделия.

Затем появились PLM-платформы, которые объединили управление инженерными данными, структурами, изменениями, процессами и жизненным циклом.

Параллельно развивались Product Family Engineering, Product Line Engineering и управление вариативностью.

Эти направления решали новую задачу:

Как описать не один продукт, а семейство продуктов, состоящее из большого количества возможных вариантов? Для этого появились собственные модели:

• features;
• options;
• variants;
• variability;
• feature constraints;
• generic BOM;
• 150% BOM.

В результате две области постепенно начали работать рядом. Это можно представить так:

Configuration Management
         │
         ├── идентификация
         ├── изменения
         ├── состояния
         └── аудит
                  │
                  │
                  ▼
         общая PLM-платформа
                  ▲
                  │
         ┌────────┴────────┐
         │                 │
  Variant Management   Product Line Engineering
         │
         ├── options
         ├── variants
         ├── features
         ├── constraints
         └── variability

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

16б.3. Когда новая задача использует старые сущности

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

Добавить:

• варианты;
• опции;
• правила;
• effectivity;
• дополнительные связи;
• дополнительные типы BOM.

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

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

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

16б.4. Почему это не обязательно ошибка

Здесь важно избежать слишком простого вывода.

Нельзя сказать: «PLM сделали неправильно».

Коммерческая система должна решать реальные задачи предприятия.

Если пользователю необходимо управлять тысячами вариантов автомобиля, ему действительно нужны options, variants, effectivity и правила выбора.

Если существующая модель уже умеет управлять структурой и изменениями, естественно использовать её как основу.

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

16б.5. От управления состоянием к пространству возможностей

Именно здесь возникает семантический сдвиг.

В Configuration Management система отвечает: Что является текущим управляемым состоянием изделия?

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

Первый вопрос направлен на существующее состояние. Второй — на пространство возможностей.

Условно:

CM:
A → B → C

Это последовательность состояний информации. А управление вариантами выглядит иначе:

           ┌── Variant A
           │
Family ────┼── Variant B
           │
           ├── Variant C
           │
           └── Variant D

Это пространство возможных решений.

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

• существующим;
• возможным;
• выбранным;
• утверждённым;
• произведённым;
• описанным.

Именно здесь возникает архитектурная проблема.

16б.6. Что показывает литература

Эта проблема не является исключительно наблюдением над коммерческими системами.

В исследованиях Product Line Engineering появляется необходимость строить инфраструктуру управления эволюцией поверх Configuration Management.

Например, работа Anastasopoulos и соавторов Increasing efficiency and effectiveness of software product line evolution — an infrastructure on top of configuration management прямо рассматривает инфраструктуру Product Line Engineering как слой, работающий поверх Configuration Management.

Это важная деталь.

Она показывает, что управление продуктовой линией и Configuration Management могут быть связаны, но не обязаны быть одной и той же задачей.

Другие работы по software product lines и feature models рассматривают отдельные модели вариативности.

Современные инженерные исследования также рассматривают интеграцию Configuration Management с Feature Models.

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

16б.7. Что делают коммерческие PLM

Вендоры PLM действительно объединяют соответствующие механизмы в одной платформе.

Например, Teamcenter предоставляет возможности управления конфигурацией BOM вместе с вариативностью, опциями, вариантами и effectivity.

Windchill также объединяет управление конфигурациями, options и variants.

Это не означает, что сами вендоры утверждают: Configuration Management = Variant Management.

Скорее речь идёт о другом. Одна платформа предоставляет механизмы для нескольких связанных задач.

Это важное различие.

Инфраструктура может быть единой. Семантика объектов при этом может оставаться различной.

16б.8. Где появляется проблема модели

Проблема возникает тогда, когда объединяется не только инфраструктура, но и смысл сущностей. Например:

одно понятие
     │
     ├── состояние изделия
     ├── вариант изделия
     ├── выбранная конфигурация
     └── производственное представление

Пользователь начинает воспринимать все эти состояния как разновидности одного объекта.

На раннем этапе это удобно. На длинной дистанции возникает стоимость. Через несколько лет система должна ответить:

Это описание изменилось?

Или:

Появился новый вариант?

Или:

Был выбран другой вариант существующего семейства?

Или:

Было изготовлено другое исполнение?

Или:

Был создан новый объект?

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

16б.9. Эволюция без пересмотра основания

Именно здесь находится основной тезис этой главы.

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

существующая модель
        ↓
новая задача
        ↓
новое поле
        ↓
новая связь
        ↓
новый тип
        ↓
новое правило
        ↓
новая интерпретация

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

Это не чья-то ошибка. Это естественное свойство эволюции больших программных систем.

16б.10. Историческая реконструкция

Здесь необходимо сделать важную оговорку.

Последовательность, представленная в этой главе, является авторской исторической реконструкцией.

Отдельные этапы хорошо подтверждаются литературой, стандартами и документацией существующих систем. Но единая историческая линия:

Configuration Management
        ↓
Product Data Management
        ↓
PLM
        ↓
Variant Management
        ↓
Product Line Engineering

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

Это аналитическая модель книги.

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

Источники подтверждают отдельные элементы этой картины, но не доказывают единую причинную цепочку.

16б.11. Почему это важно для модели данных

Если новые задачи просто добавляются поверх старой модели, возникает соблазн считать:

Part
Revision
Configuration
Variant
Instance

разновидностями одной и той же сущности. Но это разные вопросы.

Revision отвечает на вопрос: Какая версия описания действует?

Variant: Какой возможный вариант выбран или допустим?

Instance: Какой конкретный изготовленный экземпляр существует?

Object: Что является самостоятельной сущностью инженерного учёта?

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

Если они разделены, сама структура системы помогает сохранить смысл.

16б.12. Связь с предыдущими главами

Глава 16 установила: различие между PLM находится не только в функциях, но в исходном вопросе и первичных сущностях.

Глава 16а установила: Configuration Management и управление вариантами являются разными задачами, несмотря на то что могут использовать одну платформу.

Глава 7 установила: вариант не равен существующему изделию.

Теперь возникает следующий вопрос.

Если CAD, конфигуратор, ERP, копирование и генеративные инструменты производят данные, варианты и описания, в какой момент результат их работы становится самостоятельным объектом?

16б.13. Главный вывод

Современные PLM не являются неправильными.

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

Во многих случаях это было разумным инженерным решением. Но эволюция имеет цену.

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

Именно поэтому сегодня в одной PLM-платформе рядом находятся Configuration Management и Variant Management.

Это не означает, что они являются одной дисциплиной.

Это означает, что система должна одновременно управлять тем, что существует, и тем, что возможно.

Если модель данных не различает эти два пространства, пользователь начинает делать это сам — через соглашения, правила и интерпретации.

Следующая глава задаёт более фундаментальный вопрос:

В следующей главе: как инженерный объект появляется в системе? В какой момент результат работы инструмента становится самостоятельным объектом инженерного учёта?

Примечания к главе 16б

Источники:

• ISO 10007:2017, Quality management — Guidelines for configuration management. §3.1.
• ГОСТ Р ИСО 10007-2019. Менеджмент качества. Руководящие указания по менеджменту конфигурации.
• Fowler, A. «Models and applications of configuration management». Omega, Vol. 21, No. 4, 1993, pp. 425–431. DOI: 10.1016/0305-0483(93)90075-V.
• Laqua, R. «Concepts for a product line knowledge base & variability». Proceedings of NetObjectDays 2002, Erfurt, October 2002. Fraunhofer IESE.
• Laqua, R., Knauber, P. «Configuration Management for Software Product Lines». 1st Deutscher Software-Produktlinien Workshop, Kaiserslautern, 2000, pp. 49–53.
• Anastasopoulos, M. et al. «Increasing efficiency and effectiveness of software product line evolution — an infrastructure on top of configuration management». Proceedings of the 13th International Software Product Line Conference (SPLC), ACM, 2009.
• Lameh, J., Dubray, A., Jankovic, M. «Towards a Configuration Management Integration to Feature Models in Model-Based Product Line Engineering». Proceedings of the Design Society, Vol. 3, 2023, pp. 3581–3590. DOI: 10.1017/pds.2023.359.
• PTC. Product Configuration Management. Documentation.
• Siemens Digital Industries Software. Teamcenter BOM Configuration Management. Documentation.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001.

Типы доказательств:

Авторская оговорка.

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