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

Глава 16. Почему разные PLM решают одну задачу по-разному?

16.1. Таблица, которая ничего не объясняет

Когда сравнивают PLM-системы, обычно составляют таблицу.

Управление документами — есть.

Управление структурами — есть.

Управление изменениями — есть.

Workflow — есть.

Управление конфигурацией — есть.

Effectivity — есть.

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

Но если функциональность одинакова, почему две системы, решающие одну задачу, могут иметь принципиально разные модели данных?

Почему в одной системе центральным объектом является Part Revision, а в другой — изделие как самостоятельная сущность?

Почему в одной системе изменение конструкции остаётся изменением Revision, а в другой изменение, нарушающее взаимозаменяемость, требует создания нового объекта?

Почему в одной системе варианты управляются через Configuration, Options и Effectivity, а в другой исполнение является самостоятельным объектом?

Ответ находится не в функциях.

Он находится в исходном вопросе, на который каждая система отвечает.

16.2. Два разных вопроса

Рассмотрим обычный инженерный процесс.

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

Движение идёт:

замысел
   ↓
объект
   ↓
описание
   ↓
изготовление

Но исторически многие PLM-системы строились вокруг другой точки входа. Не от объекта к описанию. А от данных к управляемому состоянию:

CAD-модель
   ↓
Part
   ↓
Revision
   ↓
Configuration

Оба подхода решают реальные задачи. Но они отвечают на разные вопросы.

Первый вопрос:

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

Второй вопрос:

Какие объекты реального мира существуют и как они изменяются во времени?

Это не синонимы. Первый вопрос оптимизирует управление инженерными данными. Второй — моделирование реальности.

И ответ на каждый из них приводит к разной архитектуре.

16.3. Модель Part → Revision: сила и ограничения

Классическая модель западных PLM часто строится вокруг двух понятий:

Part
 |
 +-- Revision A
 +-- Revision B
 +-- Revision C

Эта модель имеет очевидную силу.

Она позволяет хранить историю разработки. Видеть последовательность изменений. Управлять процессами согласования. Определять актуальное состояние данных. Связывать документы и структуры с определённой ревизией.

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

Но возникает семантический вопрос: Что такое Part? Это физическое изделие? Обозначение? Элемент структуры? Объект инженерной документации? Контейнер для версий?

В разных системах и разных компаниях ответ может отличаться.

Именно здесь начинается фундаментальное различие.

Если Part является контейнером для последовательности описаний, Revision естественным образом становится центральной сущностью управления.

Если же Part должен представлять самостоятельное изделие реального мира, возникает другая модель:

объект
   ↓
описание
   ↓
версия описания

В этой модели изменение Revision не означает изменение самого объекта.

16.4. Что именно является центром модели

Рассмотрим два случая.

В первом инженер говорит: «У меня есть Part Н1. Сейчас у него Revision C».

Главный объект системы — управляемая инженерная запись.

Во втором инженер говорит: «У меня существует насос Н1. Его конструкция сейчас описана Revision C».

Главный объект системы — насос. Revision описывает его состояние.

Разница кажется небольшой. Но она распространяется на всю модель.

Если изменяется описание, меняется Revision.

Если изменяется сам объект, должен измениться объект.

Если появляется новый объект, должен появиться новый объект.

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

Из исходного ответа на вопрос «что является первичным?» постепенно вырастает вся модель данных.

16.5. Это не вопрос правильной и неправильной системы

Важно не превратить это различие в утверждение, что одна архитектура правильная, а другая неправильная.

Модель Part → Revision решает реальную задачу.

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

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

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

Обе могут иметь:

• документы;
• BOM;
• workflow;
• изменения;
• ревизии;
• жизненные циклы;
• конфигурации;
• effectivity.

Но одинаковые функции не означают одинаковую семантику.

16.6. Почему это важно

Если система хранит данные десятилетиями, вопрос о первичности перестаёт быть философским.

Представим, что через десять лет необходимо ответить: Это то же изделие, которое существовало десять лет назад, или новое?

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

Если объект и его описание разделены, модель сама проводит эту границу:

KObject
   │
   ├── Definition
   │      ├── Revision A
   │      ├── Revision B
   │      └── Revision C
   │
   └── ...

Revision B означает изменение описания. Новый KObject означает новый объект.

Эти два события не смешиваются.

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

Глава 4 установила: граница между «тем же объектом» и «новым объектом» определяется взаимозаменяемостью.

Глава 5 установила: Revision фиксирует изменение описания, а не изменение объекта.

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

Поэтому вопрос Главы 16 является естественным продолжением всей предыдущей части книги: Какая сущность является первичной для PLM-модели?

Если ответ различается, различается и модель данных.

16.8. Главный вывод

Разные PLM-системы решают одну задачу по-разному не потому, что одни лучше, а другие хуже. Они могут отвечать на разные вопросы.

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

Другая: Какие объекты существуют и как они связаны с описаниями, версиями и экземплярами?

Оба подхода имеют право на существование.

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

Различие находится глубже функций.

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

Этот вопрос звучит просто: что существует?

Но ответ на него определяет всё.

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

В следующей главе: что такое Configuration Management на самом деле? И почему управление конфигурацией нельзя смешивать с управлением вариантами изделия?

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

Источники:

• CMII Institute, CMII Standard for Configuration Management, Release 3.0. §2.1, §4.2.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.2, §3.5.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.113-75. Единая система конструкторской документации. Групповые и базовые конструкторские документы.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §3.1.

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