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

Глава 5. Что версионируется: объект или знание о нём?

5.1. Слово, которое означает слишком много

В любой PLM-системе существует понятие, без которого невозможно представить управление инженерными данными. Это понятие — Revision. Ревизия. Версия. Изменение.

Слово кажется простым. Инженер говорит: «Выпущена ревизия B чертежа». Все понимают: документ изменился. Никто не удивляется. Никто не переспрашивает.

Но попробуйте задать другой вопрос: «Выпущена ревизия B изделия». Что это означает? Изменилось изделие? Или изменилось описание изделия? Или изменилось состояние данных в системе? Или изменился комплект документации, по которому изготавливается продукция?

Один и тот же механизм — Revision — начинает отвечать на несколько разных вопросов. И именно здесь начинается одна из самых глубоких неоднозначностей в моделировании PLM-систем.

5.2. Как человек говорит об изменениях

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

Конструктор говорит: «Я изменил чертёж». Не «я изменил деталь». Чертёж. Документ. Знание об объекте.

Технолог говорит: «Я обновил технологический процесс». Не «я изменил изделие». Процесс. Описание способа изготовления.

Производственник говорит: «Мы перешли на новую документацию». Не «мы начали делать другое изделие». Документацию. Комплект знаний.

Эксплуатационщик говорит: «Вышло новое руководство по эксплуатации». Не «появился новый объект». Руководство. Описание правил использования.

Во всех этих фразах человек говорит о знании об объекте, а не о самом объекте. Изделие остаётся тем же. Изменяется то, что мы о нём знаем и как это знание зафиксировано.

5.3. Но иногда меняется сам объект

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

Что произошло?

Это уже не просто новое знание о старом изделии. Изменилось само изделие в инженерном смысле. Появилась новая единица учёта. И здесь особенно важно не перепутать два события:

Изменилось описание
        ↓
Revision

Изменился объект
        ↓
Новый объект

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

5.4. Что говорит Configuration Management

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

MIL-HDBK-61A определяет управление конфигурацией как процесс поддержания соответствия характеристик изделия его требованиям, конструкции и эксплуатационной информации на протяжении жизненного цикла.

Ключевым здесь является именно соответствие. Система должна знать, какое состояние изделия описано и какое состояние фактически существует.

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

MIL-HDBK-61A также использует понятие Engineering Change Proposal — формального предложения об изменении конфигурационной единицы. Такое предложение содержит описание изменения, его причину и оценку влияния на затронутые конфигурационные единицы.

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

5.5. Ревизия фиксирует изменение знания

Здесь различие становится максимально чётким.

Изменение может затронуть объект. А может затронуть только документацию. Ревизия фиксирует второе.

CMII Institute в CMII Standard for Configuration Management формулирует этот принцип ещё строже: ревизия конфигурационной записи отражает изменение зафиксированного знания о конфигурационной единице, а физическое изменение управляется критериями взаимозаменяемости и может потребовать создания новой конфигурационной единицы.

Это важная граница.

Представим чертёж насоса. В ревизии A указана масса 120 кг. После проверки выяснилось, что расчёт был выполнен с ошибкой. Фактическая масса — 125 кг. Инженер исправляет чертёж. Изделие не изменилось. Изменилась информация о нём.

Насос Н1
    │
    └── Конструкторское определение
            │
            ├── Revision A
            │      масса = 120 кг
            │
            └── Revision B
                   масса = 125 кг

Объект остался тем же. Изменилось описание.

Теперь другая ситуация. Конструктор изменяет диаметр присоединения настолько, что насос больше нельзя установить вместо старого без доработки. Это уже другой случай:

Насос Н1
    │
    └── старое описание

Насос Н2
    │
    └── новое описание

Здесь появляется новый объект.

5.6. ЕСКД: изменение вносится в документацию

Отечественная инженерная практика выражает тот же принцип через систему ЕСКД.

ГОСТ 2.503-2013 «Правила внесения изменений» устанавливает порядок внесения изменений в конструкторские документы. Изменение оформляется через извещение об изменении — документ, устанавливающий изменение в конструкторской документации после её выпуска.

То есть изменение непосредственно фиксируется на уровне документации.

Изделие при этом может остаться тем же. Изменяется знание о нём. Это хорошо согласуется с уже установленным нами ранее принципом: документ описывает изделие, но не является изделием.

Если меняется документ, это ещё не означает, что появился новый объект.

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

На практике кажется естественным сделать так:

KProduct: Насос Н1
    Revision A
    Revision B
    Revision C

На первый взгляд всё удобно. Один объект, несколько ревизий.

Но что означает Revision B?

Изменился чертёж? Изменилась конструкция? Изменился технологический процесс? Изменилось производственное состояние? Появился новый вариант изделия?

Без дополнительных правил система не знает ответа.

Именно здесь возникает семантическая перегрузка Revision.

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

5.8. Что происходит, если разделение отсутствует

Рассмотрим простой пример. Есть насос Н1.

Насос Н1
    Revision A

Конструктор изменил чертёж, не изменив взаимозаменяемость изделия.

Создаётся:

Насос Н1
    Revision B

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

Что делать?

Если снова создать Revision C:

Насос Н1
    Revision A
    Revision B
    Revision C

система утверждает, что всё это один объект.

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

Если же создать новый объект:

Насос Н1
    Revision A
    Revision B

Насос Н2
    Revision A

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

Н1 и Н2 — разные изделия. A и B внутри Н1 — разные состояния знания о том же изделии.

Это два разных уровня изменения.

5.9. Модель данных должна различать эти уровни

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

Модель должна разделять:

Объект
    │
    └── Определение
            │
            ├── Revision A
            ├── Revision B
            └── Revision C

а не:

Объект
    ├── Revision A
    ├── Revision B
    └── Revision C

В первом случае Revision относится к определению. Во втором случае Revision относится непосредственно к объекту и неизбежно начинает смешивать изменение объекта с изменением знания о нём.

В модели Constructum это различие выражается явно:

KObject
    │
    └── KDefinition
            │
            └── KDefinitionRevision

KObject отвечает на вопрос «что это за объект?»

KDefinition отвечает на вопрос «как этот объект описан в данной области?»

Revision отвечает на вопрос «какая версия этого описания действует?»

Три разных вопроса. Три разных сущности.

5.10. Практическое следствие

Рассмотрим насос Н1.

KObject: Н1
    │
    └── KDesignDefinition
            │
            ├── Revision A
            │      чертёж
            │      масса = 120 кг
            │
            └── Revision B
                   чертёж
                   масса = 125 кг

Изменение чертежа создаёт Revision B. Но сам KObject остаётся тем же.

Если инженерная граница пройдена и появился новый объект:

KObject: Н1
    │
    └── KDesignDefinition
            ├── Revision A
            └── Revision B

KObject: Н2
    │
    └── KDesignDefinition
            └── Revision A

Н2 не является Revision Н1.

Это новый объект со своим описанием.

5.11. Почему это важно для долгоживущих систем

PLM-система живёт десятилетиями. Изделия, которые она описывает, переживают поколения инженеров. Люди, создававшие записи, уходят. Их знания теряются. Остаются только данные.

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

Что означает Revision B?

Изменение описания? Новый объект? Вариант конфигурации? Производственное состояние?

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

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

Каждое понятие имеет однозначное значение. Это не удобство. Это требование долговечности.

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

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

Глава 2 установила: объект существует до описания.

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

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

Вместе эти выводы формируют последовательную картину:

Объект
    │
    │ стабилен
    ▼
KObject
    │
    │ имеет описания
    ▼
KDefinition
    │
    │ изменяется во времени
    ▼
Revision

Объект остаётся тем же. Описание изменяется. Revision фиксирует изменение описания.

Если изменился сам объект — появляется новый объект.

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

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

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

Изменилось описание
        ↓
Revision

Изменился объект
        ↓
Новый KObject

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

Именно поэтому в Constructum Revision принадлежит Definition, а не KObject.

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

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §5.2.
• NASA/SP-2016-610, Rev. 2, NASA Configuration Management Handbook, NASA, 2016. §5.2.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §4.3.
• CMII Institute, CMII Standard for Configuration Management, Release 3.0. §5.1.
• ISO 10303-239, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
• ГОСТ 2.503-2013. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ 2.101-2016. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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