Глава 3. Один объект — несколько описаний

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

3.1. Один автомобиль, четыре разговора

Представим, что автомобиль уже существует. Он стоит в цехе, его можно увидеть, потрогать, измерить.

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

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

Технолог назовёт операции, оборудование, последовательность сборки, нормы времени и технологические ограничения. Для него автомобиль — это результат определённого процесса изготовления.

Производственник назовёт партии, маршруты, загрузку оборудования, исполнителей и сроки. Для него автомобиль — это изделие, которое необходимо изготовить в конкретных условиях производства.

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

При этом ни один из них не считает, что говорит о другом автомобиле. Все четверо понимают: объект один. Различается знание о нём.

3.2. Почему это кажется очевидным человеку

Для человека здесь нет противоречия.

Когда конструктор говорит: «У автомобиля двигатель расположен спереди», а технолог говорит: «Для установки двигателя требуется операция №40», они не противоречат друг другу.

Первый говорит о конструкции. Второй — о процессе изготовления. Если добавить эксплуатационщика: «Масло необходимо менять каждые 7 000 километров», появляется ещё один слой знания. Все эти утверждения относятся к одному автомобилю.

Человек естественным образом разделяет:

                    Автомобиль
                        │
        ┌───────────────┼───────────────┐
        │               │               │
   Конструкция       Технология     Эксплуатация
        │               │               │
   геометрия         операции       обслуживание
   материалы         оборудование   ограничения
   допуски            маршрут        регламент

Но информационная система сама этого разделения не понимает.

3.3. Как система обычно решает проблему

В традиционной информационной системе всё часто начинается с одной таблицы:

Product
    id
    name
    material
    weight
    status
    manufacturer
    ...

Потом появляется конструкторский модуль. В таблицу добавляются поля: design_number, drawing_number, cad_model. Затем появляется производство: work_center, routing, operation, batch. Потом эксплуатация: maintenance_interval, service_class, operating_conditions.

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

Кто изменяет material? Конструктор? Технолог? Производство? А кто отвечает за maintenance_interval? Что происходит, если конструктор меняет материал, а технолог ещё не изменил технологический процесс?

Формально изменяется одна запись Product. Инженерно изменяется только один аспект изделия.

Это разные вещи.

3.4. Описание не является объектом

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

Но это не соответствует инженерной практике.

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

Технолог может изменить маршрут обработки, не изменяя конструкцию.

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

Следовательно, описание должно существовать отдельно от объекта.

Объект
   │
   ├── Конструкторское описание
   │
   ├── Технологическое описание
   │
   ├── Производственное описание
   │
   └── Эксплуатационное описание

Объект остаётся один. Описание — разное.

3.5. Один объект — много описаний

Вернёмся к автомобилю.

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

Все эти документы описывают один и тот же объект. Но ни один из них этим объектом не является. Более того, все они могут изменяться независимо друг от друга.

Именно поэтому в модели должны существовать не только Product, но и отдельные сущности описания:

KProduct
    │
    ├── KDesignDefinition
    │
    ├── KTechnologyDefinition
    │
    ├── KManufacturingDefinition
    │
    └── KOperationalDefinition

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

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

Можно возразить: «Зачем создавать отдельные объекты? Давайте просто добавим поля в Product».

Проблема не в количестве полей. Проблема в ответственности. Представим:

Product
    design_data
    technology_data
    manufacturing_data

На уровне базы данных это может выглядеть аккуратно. Но кто владеет Product? Design Service? Technology Service? Manufacturing Service?

Если Product принадлежит Design Service, технологический сервис получает зависимость от конструктора. Если Product принадлежит Technology Service, конструктор получает зависимость от технологии. Если Product принадлежит всем, появляется коллективный владелец, который на практике означает отсутствие владельца.

Проблема возникла не из-за микросервисов. Она возникла раньше — на уровне модели данных.

3.7. Описание должно быть самостоятельным объектом

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

KProduct: Насос Н1
    │
    ├── KDesignDefinition
    │       ├── Revision A
    │       ├── Revision B
    │       └── Revision C
    │
    ├── KTechnologyDefinition
    │       ├── Revision A
    │       └── Revision B
    │
    └── KManufacturingDefinition
            └── Revision A

Теперь изменение конструкции не означает изменение технологии. Изменение технологии не означает изменение конструкции. Каждое описание имеет собственную историю.

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

3.8. Revision относится к описанию

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

KProduct
    │
    ├── KDesignDefinition
    │       ├── Revision A
    │       └── Revision B
    │
    └── KTechnologyDefinition
            └── Revision A

Revision B означает: изменилось конструкторское описание. Она не означает:

появился новый автомобиль;
изменилась технология;
изменилось производство;
появился новый экземпляр.

Изменилось конкретное знание об объекте. Этот вывод станет особенно важным в Главе 5, где мы отдельно рассмотрим вопрос: что именно версионируется — объект или знание о нём?

3.9. Что говорят стандарты

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

ANSI/EIA-649-D рассматривает управление конфигурацией через процессы и ответственности, разделённые между различными областями деятельности. Границы процессов должны отражать естественные разделения инженерной работы.

NASA Systems Engineering Handbook (NASA/SP-2016-610 Rev. 2) рассматривает Configuration Management как сквозную дисциплину (crosscutting discipline), где различные инженерные области (Design, Manufacturing, Quality) имеют собственные зоны ответственности за конфигурационные данные.

ISO 10303-239:2024 (PLCS) идёт ещё дальше и формализует различие между продуктом и его определениями. В модели PLCS product и product_definition — разные сущности. При этом product_definition связан с product_definition_context, который указывает, в какой области (design, manufacturing, service) и на какой стадии рассматривается описание продукта.

NPDM (NATO Product Data Model, STANAG 4613) использует тот же фундаментальный принцип. В модели НАТО продукт отделён от информации о нём. Продукт представляет сам объект, а сведения о продукте находятся в связанных сущностях.

Отечественная инженерная практика следует той же логике:

ГОСТ 2.102-68 выделяет конструкторские документы как самостоятельный класс.
ГОСТ 3.1109-82 определяет технологическую документацию как отдельный класс инженерной информации.
ГОСТ 2.601-2019 определяет эксплуатационные документы как самостоятельный класс.
ГОСТ Р 2.052-2024 и ГОСТ Р 2.053-2023 разделяют электронную модель изделия и электронную структуру изделия как самостоятельные объекты инженерных данных.

Это разные виды инженерного знания, относящиеся к одному изделию.

3.10. Почему это важно для изменений

Представим насос Н1.

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

Если вся информация хранится внутри одного объекта Product, то система видит три изменения одного объекта. Но инженерно произошло другое:

KProduct: Насос Н1
    │
    ├── Design Definition
    │       январь → Revision B
    │
    ├── Technology Definition
    │       февраль → Revision B
    │
    └── Operational Definition
            март → Revision B

Три изменения. Три области знания. Три независимые истории.

Сам насос при этом остаётся тем же.

3.11. Почему это важно для ответственности

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

Конструктор отвечает за конструкцию. Технолог — за технологию. Производство — за производственный процесс. Эксплуатация — за эксплуатационные требования.

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

3.12. От модели к архитектуре

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

KProduct: Насос Н1
    │
    ├── KDesignDefinition
    │       → Design Service
    │
    ├── KTechnologyDefinition
    │       → Technology Service
    │
    └── KManufacturingDefinition
            → Manufacturing Service

Design Service управляет конструкторским описанием. Technology Service управляет технологическим описанием. Manufacturing Service управляет производственным описанием.

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

3.13. Единый объект остаётся общим

При этом необходимо сохранить одну общую точку. Все сервисы должны понимать, о каком объекте идёт речь.

KObject Registry
    │
    └── KObject: 12345
            │
            ├── Design Service
            │       KDesignDefinition
            │
            ├── Technology Service
            │       KTechnologyDefinition
            │
            └── Manufacturing Service
                    KManufacturingDefinition

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

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

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

Можно попытаться построить систему иначе:

Design Service      -> Product
Technology Service  -> Product
Manufacturing Service -> Product

На первый взгляд всё выглядит нормально. Но теперь появляются три Product. У каждого собственный идентификатор. У каждого собственная история. У каждого собственное состояние. И возникает главный вопрос: это один объект или три?

Если один — кто отвечает за его существование? Если три — как доказать, что они представляют один и тот же объект?

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

Сначала должен существовать общий объект. Потом — независимые описания.

3.15. Модель Constructum

Из этого следует фундаментальная конструкция модели:

KObject
    │
    └── KProduct
            │
            ├── KDesignDefinition
            │       └── Revision
            │
            ├── KTechnologyDefinition
            │       └── Revision
            │
            └── KManufacturingDefinition
                    └── Revision

Здесь каждый уровень отвечает на свой вопрос.

KObject — что существует. KProduct — каким типом объекта является это изделие. KDefinition — каким образом этот объект описан в конкретной инженерной области. Revision — какая версия этого описания действует.

Такое разделение позволяет системе не смешивать объект, знание о нём и изменение этого знания.

3.16. Граница: не всякое знание должно становиться Definition

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

Конструкторское описание имеет собственную историю. Технологическое описание имеет собственную историю. Производственное описание имеет собственную историю.

Именно поэтому они должны быть разделены. Документ при этом остаётся способом фиксации знания. Он может быть связан с соответствующим описанием, но не заменяет его.

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

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

Глава 3 добавляет: один объект может иметь несколько независимых описаний.

Объект
   │
   ├── конструктивное описание
   ├── технологическое описание
   ├── эксплуатационное описание
   └── другие описания

Это не несколько объектов. Это несколько способов описать один объект. Объект остаётся одним. Описание зависит от области знания. Изменение одного описания не является изменением остальных.

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

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

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

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

Поэтому информационная система не должна пытаться поместить всё знание об объекте в одну сущность. Объект должен быть отделён от его описаний. Каждое описание должно иметь собственную ответственность и собственную историю изменений.

В модели это выражается следующим образом:

KProduct
    │
    ├── KDesignDefinition
    ├── KTechnologyDefinition
    ├── KManufacturingDefinition
    └── ...

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

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

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

Источники:

ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §2.2.
NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. (Раздел о CM как crosscutting discipline).
MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §2.1.
ISO 10303-239:2024, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
NATO CALS Office, NPDM Version 4.10 — NATO Product Data Model, STANAG 4613 / ALP-14.
ГОСТ 2.102-68. Единая система конструкторской документации. Виды и комплектность конструкторских документов.
ГОСТ 2.114-2016. Единая система конструкторской документации. Технические условия.
ГОСТ 2.601-2019. Единая система конструкторской документации. Эксплуатационные документы.
ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
ГОСТ 3.1109-82. Единая система технологической документации. Термины и определения основных понятий.
ГОСТ Р 2.052-2024. Единая система конструкторской документации. Электронная модель изделия. Общие положения.
ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.

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

Утверждение	Тип	Источник
Конструкторские документы являются самостоятельным классом	ПНУ	ГОСТ 2.102-68
Технологическая документация является самостоятельным классом	ПНУ	ГОСТ 3.1109-82
Эксплуатационные документы являются самостоятельным классом	ПНУ	ГОСТ 2.601-2019
`product` и `product_definition` (с контекстом) — разные сущности	ПНУ	ISO 10303-239:2024
Product отделён от информации о продукте	ПНУ	NPDM (STANAG 4613)
Разные области инженерной деятельности имеют собственные границы	ПНУ	ANSI/EIA-649-D, NASA SE Handbook
Электронная модель и структура — самостоятельные объекты	ПНУ	ГОСТ Р 2.052-2024, ГОСТ Р 2.053-2023
Один объект может иметь несколько независимых описаний	СС	ЕСКД, ЕСТД, CM, PLCS
Описание должно быть самостоятельной сущностью модели	ЛВА	Архитектурный вывод автора
Граница сервиса должна проходить между описаниями	АР	Архитектурное решение Constructum
Revision относится к описанию, а не к объекту	СС + ЛВА	Следствие разделения product / product_definition

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