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

Глава 10. Почему документ не является объектом изделия?

10.1. Чертёж на стене

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

Нет.

Что произойдёт, если чертёж заменить новой редакцией? Насос Н1 станет другим?

Нет.

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

Нет.

Это кажется очевидным, пока мы говорим о бумажных документах. Но в информационной системе граница часто стирается.

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

Но документ и изделие отвечают на разные вопросы.

Документ отвечает: «Что нам известно об изделии и как это знание зафиксировано?»

Изделие отвечает: «Что существует?»

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

10.2. Документ описывает объект

Вернёмся к насосу Н1. У него может быть:

KProduct: Насос Н1
    Конструкторское описание
        ├── Чертёж
        ├── Спецификация
        └── Электронная модель
    Технологическое описание
        ├── Технологический процесс
        ├── Операционные документы
        └── Нормы контроля
    Эксплуатационное описание
        ├── Руководство
        ├── Паспорт
        └── Формуляр

Все эти документы говорят о насосе Н1. Но ни один из них не является самим насосом.

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

Документ меняется. Объект остаётся тем же.

10.3. Один объект — множество документов

Это принципиально важно для PLM.

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

Чертёж? Но тогда куда отнести спецификацию?

Спецификация? Тогда куда отнести технологический процесс?

Технологический процесс? Тогда куда отнести эксплуатационную документацию?

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

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

Каждое описание существует в своей области знания. Документ фиксирует это знание.

10.4. Документ имеет собственную жизнь

Отделение документа от объекта не означает, что документ не является самостоятельной сущностью.

Напротив. Документ имеет собственную жизнь:

• он создаётся;
• изменяется;
• проходит согласование;
• утверждается;
• заменяется;
• архивируется;
• может быть отменён;
• может иметь собственные версии.

Но эта жизнь не является жизнью изделия.

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

Поэтому жизненные циклы документа и изделия нельзя отождествлять.

10.5. Что происходит, если сделать документ объектом

Рассмотрим типичную модель:

Document
    id
    revision
    status
    author
    created_at
    approved_at
    describes → Product

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

Document
    Product
    Revision
    Status
    Owner
    Project
    Lifecycle
    Effectivity
    ...

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

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

• что существует;
• как это устроено;
• какая редакция действует;
• кто отвечает;
• где используется;
• в каком состоянии находится.

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

10.6. Документ и Revision — не одно и то же

Есть ещё одна важная граница.

Документ может иметь версии. Но Revision не обязательно является версией документа. Revision фиксирует изменение определённого описания объекта.

Например:

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

Конкретная Revision может быть представлена несколькими документами:

Revision B
    ├── Чертёж №123
    ├── Спецификация №124
    └── Электронная модель №125

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

Object
    ↓
Revision
    ↓
Document

с единственной возможной структурой данных. Документ является носителем или представлением знания. Revision фиксирует состояние описания.

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

10.7. Документ не определяет существование изделия

Представим, что конструктор создал новую Revision.

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

Что изменилось?

Изменилось описание насоса. Но не обязательно изменился сам насос. Если Revision B исправляет размер отверстия на чертеже, физический насос Н1, изготовленный ранее, от этого не изменяется.

Поэтому система должна уметь одновременно хранить:

KProduct
    ↓
KDesignDefinition
    ├── Revision A
    └── Revision B

Instance №001
    applied_revision = A

Instance №002
    applied_revision = B

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

Он не превращается в «применение Revision». Он имеет собственное существование и хранит информацию о том, какая Revision была применена при его изготовлении.

10.8. Документ может исчезнуть, объект — нет

Есть ещё более простой тест.

Представим, что архив документов потерян. Все чертежи уничтожены. Исчезло знание. Но сам насос Н1 продолжает существовать.

Теперь обратная ситуация.

Насос Н1 уничтожен. Но его документация сохранилась. Чертёж продолжает существовать как документ.

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

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

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

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

ISO 10303-239 PLCS разделяет сущность изделия и информацию, описывающую его состояние и характеристики. В модели существуют отдельные понятия product, product_definition и связанные с ними структуры данных.

NATO Product Data Model также разделяет изделие и информацию о нём. Product представляет сам продукт, тогда как информация о его определении и состоянии находится в связанных структурах.

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

ГОСТ Р 2.101-2023 определяет изделие как предмет или набор предметов производства.

ГОСТ 2.102 устанавливает виды и комплектность конструкторских документов.

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

Документ описывает изделие. Он не заменяет его.

10.10. Документ как самостоятельный объект системы

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

Наоборот.

Документ должен иметь собственную сущность в модели. Он должен иметь:

• собственный идентификатор;
• собственную историю;
• собственные версии;
• собственные отношения;
• собственный жизненный цикл;
• собственные права доступа.

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

Объект
    │
    ├── описывается → Definition
    │                    │
    │                    └── Revision
    │
    └── документируется → Document

Объект существует.

Definition описывает его в определённой области знания.

Revision фиксирует состояние этого описания.

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

Каждый уровень имеет собственную ответственность.

Здесь важно зафиксировать одну границу.

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

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

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

10.11. Почему это особенно важно для PLM

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

Появляется новое конструкторское решение. Затем технологическое решение. Затем производственное. Затем эксплуатационное. Появляются новые документы. Одни документы заменяются. Другие становятся архивными.

Но изделие продолжает существовать.

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

• самим изделием;
• его описаниями;
• версиями описаний;
• документами;
• экземплярами;
• применением конкретного описания при изготовлении.

Это значительно ближе к реальной инженерной деятельности.

10.12. Пример из жизненного цикла

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

В 2026 году создано конструкторское описание:

KProduct: Н1
KDesignDefinition
    Revision A

На его основе изготовлены экземпляры:

Instance №001 → Revision A
Instance №002 → Revision A
Instance №003 → Revision A

В 2027 году конструктор выпускает новую Revision:

KDesignDefinition
    Revision A
    Revision B

Изменяется описание. Но экземпляры №001–003 не изменяются.

В 2027 году изготовлены новые экземпляры:

Instance №004 → Revision B
Instance №005 → Revision B

Теперь система может ответить на два разных вопроса. Что является актуальным описанием Н1?

Revision B.

По какому описанию изготовлен экземпляр №002?

Revision A.

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

10.13. Граница между объектом и документом

Здесь проходит важная граница всей модели.

Объект отвечает на вопрос: что существует?

Definition отвечает на вопрос: как объект описан в определённой области?

Revision отвечает на вопрос: в каком состоянии находится это описание?

Document отвечает на вопрос: в какой документальной форме это знание зафиксировано?

Эти вопросы связаны. Но они не одинаковы.

Поэтому они не должны быть представлены одной сущностью.

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

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

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

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

Глава 10 добавляет: документ является способом фиксации знания. Он не является объектом изделия.

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

Объект существует. Описание представляет объект в определённой области. Revision фиксирует изменение этого описания. Документ фиксирует знание в документальной форме.

Это четыре разных уровня. И у каждого — собственная жизнь.

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

Документ не является объектом изделия. Он является способом фиксации и передачи знания об объекте.

Изделие существует независимо от документа. Оно может иметь множество документов, множество описаний и множество Revision. Изменение документа не обязательно означает изменение изделия.

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

Для модели данных это означает одно: объект изделия должен существовать самостоятельно. Документы должны существовать самостоятельно. Между ними должна существовать явная связь.

Тогда система может одновременно отвечать на разные вопросы:

• что существует;
• как это описано;
• какая Revision описания действует;
• каким документом это знание зафиксировано;
• какое описание было применено при изготовлении конкретного экземпляра.

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

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

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

Источники:

• ISO 10303-239, 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.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.102-68. Единая система конструкторской документации. Виды и комплектность конструкторских документов.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016.

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