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

Глава 12а. Отступление. Почему в книге нет электронной структуры изделия

Здесь необходимо отдельно остановиться на терминологии ГОСТ Р 2.053-2023.

Стандарт вводит понятие электронной структуры изделия (ЭСИ) и устанавливает, что КД, содержащие ЭСИ, могут представляться в разных формах — в АС УДИ как совокупность информационных объектов, информационных наборов и связей между ними либо в виде файла в унифицированном или стандартизованном формате.

Поэтому проблема, о которой пойдёт речь ниже, не связана с электронной формой.

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

12а.1 Основная ЭСК — здесь всё работает

Стандарт определяет основную ЭСК как документ, содержащий сведения о составных частях, непосредственно входящих в изделие, но не включающий ЭСК этих составных частей.

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

A
├── B × 4
├── C × 2
└── D × 1

Основная ЭСК фиксирует непосредственный состав:

ЭСК A
├── B × 4
├── C × 2
└── D × 1

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

У составной части C может существовать собственная спецификация:

ЭСК C
├── E × 2
└── F × 1

И здесь ничего не ломается. Документы остаются самостоятельными. Они связаны с соответствующими изделиями и уровнями структуры.

12а.2 Полная ЭСК — здесь начинается проблема

Для полной ЭСК стандарт устанавливает уже другое правило.

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

Для нашего примера это означает:

Полная ЭСК A
│
├── B
│
├── C
│   └── ЭСК C
│       ├── E
│       └── F
│
└── D

Если структура C содержит собственные сборочные единицы, рекурсия продолжается. Документ начинает описывать другой документ. Тот — следующий. И так далее.

Получается документ-матрёшка.

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

12а.3 Где находится структура: в изделии или в документе?

Есть в ГОСТ Р 2.053-2023 ещё одна формулировка, на которую стоит обратить внимание. Пункт 5.3.2.1 устанавливает:

«Элементами структуры изделия в ЭСК могут быть изделия (СЧ) и ссылки на КД».

На первый взгляд это совершенно обычная формулировка. Но если рассмотреть её буквально, возникает ещё одно противоречие. ЭСК определена стандартом как электронный конструкторский документ. Следовательно, речь идёт об элементах, представленных в документе. И тогда получается:

ЭСК
│
├── изделие B
├── изделие C
└── ссылка на КД

То есть изделие становится элементом документа. Но изделие существует независимо от документа. Если рассматривать модель реального мира, структура выглядит иначе:

Изделие A
│
├── содержит → B
└── содержит → C

Здесь B и C являются составными частями изделия A. ЭСК лишь фиксирует это отношение:

Изделие A
   │
   ├── содержит → B
   └── содержит → C
           │
           ↓
          основная ЭСК C

Это принципиальное различие.

Изделие не является элементом документа. Оно является объектом, сведения о котором содержит документ.

Документ фиксирует существующую структуру, но не создаёт её своим содержанием. Здесь особенно хорошо видно различие между двумя утверждениями.

Первое:

Изделие B является составной частью изделия A.

Это утверждение относится к инженерной модели.

Второе:

В ЭСК A приведены сведения об изделии B.

Это утверждение относится к документу.

Они связаны, но это не одно и то же. Можно представить это следующим образом:

             РЕАЛЬНЫЙ МИР
                  │
                  ↓
          ┌────────────────┐
          │    Изделие A   │
          │                │
          │  ├── B         │
          │  └── C         │
          └────────────────┘
                  │
             фиксируется
                  ↓
          ┌────────────────────┐
          │     ЭСК A          │
          │                    │
          │  ├── сведения о B  │
          │  └── сведения о C  │
          └────────────────────┘

В первой модели B является частью A.

Во второй модели сведения о B являются частью основной ЭСК A. Это разные отношения.

И здесь возникает ещё одна проблема терминологии. Если принять формулировку ГОСТ буквально и считать изделия элементами структуры в ЭСК, то граница между структурой изделия и описанием структуры изделия исчезает. Получается:

структура изделия
        =
структура документа,
который эту структуру описывает

Но тогда возникает вопрос: что именно происходит, когда изделие существует, а соответствующий документ ещё не создан? Например:

A
└── B

Инженерная связь между A и B уже существует в модели изделия. ЭСК A может быть ещё не выпущена.

Следовательно:

структура изделия  -   существует
ЭСК                -   ещё не существует

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

Модель не должна зависеть от документа, который её описывает.

Именно поэтому в Constructum мы разделяем:

KObject
   │
   └── KRelation
          │
          ↓
     структура изделия
          │
          ↓
       KDefinition
          │
          ↓
        ЭСК

Здесь структура существует на уровне объектов и отношений. ЭСК является одним из способов её фиксации.

И ещё одна деталь делает формулировку п. 5.3.2.1 особенно показательной. Стандарт говорит, что элементами структуры в ЭСК могут быть не только изделия, но и ссылки на КД. Получается, в одном и том же множестве «элементов структуры изделия» оказываются сущности принципиально разной природы:

ЭСК
│
├── изделие
│
├── изделие
│
└── ссылка на документ

Изделие — объект инженерного (реального) мира. Ссылка — элемент информационной модели документа. Это уже не однородные элементы одной структуры. По сути, ЭСК начинает одновременно описывать:

1. состав изделия;
2. связи с документацией на составные части.

Именно поэтому ЭСК правильнее рассматривать как документ, фиксирующий сведения о структуре, а не как саму структуру изделия.

Здесь возникает и более простой вопрос: что именно означает выражение «электронная структура изделия»?

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

«Электронная» характеризует не саму структуру, а форму её представления.

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

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

Это небольшое, но принципиальное различие: структура относится к модели изделия, а электронность — к форме её представления.

Это различие кажется теоретическим только до тех пор, пока мы не начинаем проектировать информационную систему. Если считать ЭСК самой структурой, возникает необходимость хранить структуру внутри документа. Если считать структуру свойством модели изделия, всё становится значительно проще:

Изделие A
   │
   ├── KRelation → изделие B
   └── KRelation → изделие C

А затем из этой модели можно получить:

основную ЭСК A

или:

полную ЭСК A

или:

комплект КД A

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

изделие и его структура существуют независимо от документа, который их описывает. Документ фиксирует структуру, но не является самой структурой.

Поэтому формулировку п. 5.3.2.1 мы рассматриваем как нормативное описание представления структуры в ЭСК, а не как основание для построения самой модели изделия вокруг ЭСК.

12а.4 Почему в бумажной документации нет «полной спецификации»

В традиционной бумажной ЕСКД нет необходимости создавать документ, который содержал бы все спецификации изделия на всех уровнях вложенности.

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

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

И это принципиально другая конструкция. Комплект не превращает документы в один документ:

Комплект документации A
│
├── Спецификация A
├── Чертёж A
├── Спецификация B
├── Чертёж B
└── ...

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

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

12а.5 А что значит утвердить полную ЭСК?

Здесь проблема становится ещё серьёзнее.

У обычной ЭСК объект утверждения понятен:

ЭСК C
├── D
└── E

Утверждается документ ЭСК C.

При этом документы, относящиеся к D и E, имеют собственный жизненный цикл.

Но что означает утверждение полной ЭСК?

Полная ЭСК A
│
├── ЭСК B
│
└── ЭСК C
    ├── ЭСК D
    └── ЭСК E

Что именно теперь утверждается?

Только внешняя полная ЭСК A? Или одновременно все ЭСК, структуры которых она описывает?

Если ЭСК C изменена после утверждения полной ЭСК A, остаётся ли утверждение A действующим? Если изменение произошло в ЭСК D, должно ли оно привести к повторному утверждению ЭСК C, а затем и полной ЭСК A?

Получается каскад:

изменение ЭСК D
       ↓
изменение структуры C
       ↓
изменение полной ЭСК A

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

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

12а.6 Комплект документации решает эту задачу иначе

У комплекта документации такой проблемы нет.

Документы остаются самостоятельными:

Комплект A
│
├── Документ 1 — утверждён
├── Документ 2 — утверждён
├── Документ 3 — утверждён
└── Документ 4 — утверждён

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

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

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

Не:

один документ содержит другие документы и должен быть утверждён как единое целое,

а:

существует множество самостоятельных документов, объединённых в комплект.

12а.7 Структура изделия как совокупность “малых структур”

Здесь важно не уйти в противоположную крайность.

Посмотрим на то же изделие:

A
├── B
└── C
    ├── D
    └── E

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

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

Структура изделия A
        │
        ├── Спецификация A  →  непосредственный состав A
        ├── Спецификация C  →  непосредственный состав C
        └── Спецификация E  →  непосредственный состав E

Каждая спецификация — самостоятельная единица. Вместе они определяют полную структуру изделия.

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

12а.8 Электронный мир сохраняет ту же логику

Переход к электронной форме не должен менять эту логику.

Каждая основная ЭСК остаётся самостоятельным электронным документом. Его можно согласовать. Утвердить. Изменить. Отменить. У него есть собственный жизненный цикл.

ЭСК A  →  самостоятельный электронный документ
ЭСК C  →  самостоятельный электронный документ
ЭСК E  →  самостоятельный электронный документ

Но электронный мир добавляет то, чего не было на бумаге: со всеми этими “малыми структурами” можно работать как с единым целым.

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

В электронном мире система может:

ЭСК A
    │
    ├── ЭСК C
    │       ├── ЭСК D
    │       └── ЭСК E
    │
    └── ЭСК B

взять все основные ЭСК и представить их как единое дерево. Не создавая новый документ. Не превращая самостоятельные документы в один документ-матрёшку - полную ЭСК. Просто вычислив представление на основе связей между самостоятельными документами.

Это и есть преимущество электронного мира:

“Малые структуры” остаются самостоятельными документами. Но система может работать с их совокупностью как с единым целым.

12а.9 Где именно ломается ГОСТ Р 2.053

Проблема ГОСТ Р 2.053 не в том, что он вводит электронную структуру изделия. И не в том, что он определяет ЭСК как электронный документ.

Проблема в полной ЭСК.

Вместо того чтобы сказать: полная структура изделия — это совокупность основных ЭСК, с которыми система может работать как с единым целым,

стандарт говорит: полная ЭСК — это документ, содержащий сведения о составных частях и их структурах, то есть ЭСК этих составных частей.

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

И вот здесь возникает матрёшка. Документ начинает включать другие документы. Утверждение одного документа начинает зависеть от утверждения других. Изменение вложенного документа начинает каскадировать вверх.

Правильная электронная модель выглядит иначе:

Самостоятельные ЭСК:
    ЭСК A    ← самостоятельный документ
    ЭСК C    ← самостоятельный документ
    ЭСК E    ← самостоятельный документ

Представление полной структуры:
    вычисляется системой из связей между ЭСК
    не является отдельным документом
    может быть сформировано по требованию

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

12а.10 Что значит утвердить ЭСК в этой модели

В модели совокупности “малых структур” объект утверждения очевиден:

ЭСК C
├── D
└── E

Утверждается документ ЭСК C. Именно он фиксирует непосредственный состав C.

Документы, относящиеся к D и E, имеют собственный жизненный цикл. Их изменение не требует повторного утверждения ЭСК C, если только сам состав C не изменился.

Если ЭСК D изменилась, это изменение касается ЭСК D. Оно не каскадирует автоматически в ЭСК C и тем более в представление полной структуры A.

Жизненный цикл изменения остаётся привязанным к тому уровню, на котором изменение произошло.

12а.11 Почему в этой книге нет ЭСИ как фундаментального понятия

В книге не отрицается нормативное понятие ЭСИ. Не утверждается, что ЭСК не нужна. Если нормативные требования требуют сформировать основную ЭСК или полную ЭСК, система должна уметь это сделать.

Но ЭСК не должна становиться фундаментальной сущностью модели данных.

В Constructum первична инженерная модель:

KObject ── KRelation ── KObject
              │
              ├── quantity
              ├── position
              ├── applicability
              └── history

Из этой модели естественным образом возникают структуры:

                    Модель изделия
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
     ЭСК уровня A    ЭСК уровня C    ЭСК уровня E
     (самостоятельный  (самостоятельный  (самостоятельный
      документ)         документ)         документ)

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

Полная структура изделия — не отдельный документ. Это представление, которое система вычисляет из связей между самостоятельными ЭСК.

Представление полной структуры:
    вычисляется из совокупности основных ЭСК
    не является самостоятельным документом
    не требует отдельного утверждения
    может быть сформировано по требованию

Именно поэтому в книге не используется термин «электронная структура изделия» как фундаментальное понятие модели.

Не потому, что электронная структура невозможна. Не потому, что ГОСТ не допускает её цифрового представления.

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

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

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

Поэтому в Constructum:

объекты → отношения → структура изделия
                         │
                         ├── ЭСК A
                         ├── ЭСК C
                         └── ЭСК E
                              │
                              ↓
                    представление полной структуры

а не:

один документ «полная ЭСК», включающий другие документы.

Структура существует в модели. ЭСК фиксирует её на конкретном уровне. Полная структура является представлением совокупности таких уровней а не документом-матрёшкой.