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

Как модель реального мира определяет архитектуру цифровых платформ

Аннотация

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

Эта книга начинается с простого вопроса: что такое объект?

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

На этой основе рассматривается архитектура PLM-системы Constructum. В ней KObject задаёт общий фундамент для различных типов объектов, а описание, атрибуты, административный контекст, связи и производные представления существуют как отдельные части модели. Такое разделение позволяет сохранить идентичность объекта независимо от изменений знаний о нём и построить архитектуру, в которой границы сервисов следуют из границ ответственности модели.

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

Книга не предлагает очередной набор технических решений для построения PLM. Её предмет — переход от понимания объекта к построению системы вокруг этого понимания.

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

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

Пролог

Каждый человек без труда отличит автомобиль от самолёта, насос от редуктора, карандаш от книги. Мы делаем это настолько естественно, что не задумываемся о самом процессе. Ребёнок, впервые увидев автомобиль, не знает, что такое колёсная база или двигатель внутреннего сгорания, — но уже понимает, что перед ним автомобиль.

Человек умеет мыслить объектами. Компьютер — нет.

Для компьютера не существует автомобиля. Не существует самолёта. Не существует даже документа. Для него существует лишь последовательность данных, смысл которой появляется только тогда, когда его определяет человек. Поэтому любая информационная система начинается не с программного кода. Она начинается с вопроса: что именно мы пытаемся представить?

Если ответить на этот вопрос неправильно, никакая архитектура уже не исправит ошибку. Можно использовать лучшие базы данных, самые быстрые алгоритмы, самые современные микросервисы. Но, если цифровая модель не соответствует реальному миру, пользователи начинают обходить систему: создают дополнительные таблицы, используют поля не по назначению, ведут учёт в Excel. И постепенно информационная система перестаёт отражать реальность. Она начинает отражать собственные ограничения.

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

Эта книга не посвящена языкам программирования. Не посвящена конкретной базе данных. Не посвящена микросервисам. Она не является руководством по выбору или внедрению PLM-системы. Она посвящена значительно более фундаментальной задаче: как представить объекты реального мира в цифровой системе так, чтобы сама система помогала человеку работать правильно, а не заставляла его приспосабливаться к ограничениям собственной модели данных.

Она адресована архитекторам информационных систем, инженерам-конструкторам, разработчикам PLM-платформ и всем, кто принимает решения о том, как цифровая система представляет инженерный объект. Книга опирается на отечественную систему ЕСКД, международные стандарты управления конфигурацией (ANSI/EIA-649, NASA CM Handbook, MIL-HDBK-61, CMII, ISO 10007) и стандарт ISO 10303 (STEP/PLCS). Нормативные положения отделены от авторских выводов и архитектурных решений.

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

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

Часть I. Что такое объект?

Глава 1. Почему компьютер не понимает, что такое автомобиль?

1.1. Очевидность, которая обманчива

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

Попробуйте провести мысленный эксперимент. Закройте глаза и представьте автомобиль. Скорее всего, перед вами возникнет вполне определённый образ — легковой, грузовой, спортивный. Но, почти наверняка вы не представляете одновременно тысячи деталей, из которых он состоит. Наше мышление сначала выделяет объект целиком, а уже затем, если это необходимо, рассматривает его составные части. Именно поэтому ребёнок узнаёт автомобиль задолго до того, как узнаёт слово «двигатель».

Теперь зададим тот же вопрос компьютеру. Ответ будет неожиданным: компьютер не знает, что такое автомобиль. Для него не существует автомобиля. Не существует двигателя. Не существует колес.

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

1.2. Что видит компьютер

Представим, что в базе данных появилась запись:

id = 12345
name = "Автомобиль"
weight = 1450
engine_power = 150

Для человека это очевидно: перед нами автомобиль. Для компьютера — нет.

Для него это набор значений, связанных определёнными правилами хранения. Число 1450 не знает, что это масса. Число 150 не знает, что это мощность двигателя. Строка "Автомобиль" сама по себе не создаёт понятия автомобиля.Смысл появляется только потому, что человек заранее определил:

1450 → масса
150  → мощность двигателя

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

1.3. Данные не равны объекту

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

«Автомобиль хранится в базе данных».

Но в базе данных не хранится автомобиль. В ней хранится представление автомобиля. Сам автомобиль находится в физическом мире. В базе находятся данные, которые позволяют системе работать с информацией об этом автомобиле.

То же самое относится к инженерным системам. В PLM не находится насос. В PLM находится информация о насосе. В CAD не находится самолёт. В CAD находится его цифровая модель. В ERP не находится изделие. В ERP находятся данные о номенклатуре, производстве, закупках, стоимости и других аспектах деятельности.

Это кажется очевидным, но именно здесь возникает большинство проблем моделирования. Если система не различает объект и данные о нём, постепенно данные начинают подменять объект.

Тогда возникает вопрос: что именно представляет запись в системе? Документ? Изделие? Описание изделия? Версию описания? Конкретный экземпляр? Вариант? Или просто набор данных?

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

1.4. Модель как договор между человеком и компьютером

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

Реальный мир
     ↓
Человеческое понимание
     ↓
Модель
     ↓
Информационная система

Модель сообщает системе:

• какие объекты существуют;
• какие данные относятся к этим объектам;
• какие отношения между объектами существуют;
• какие изменения допустимы;
• что означает каждое состояние данных.

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

Если в модели существует только Product, система будет видеть мир через понятие Product. Если в модели существует Product и ProductRevision, система сможет различать изделие и изменение его описания. Если существует отдельный ProductInstance, система сможет различать тип изделия и конкретный изготовленный экземпляр. Если существует отдельный Document, система сможет отличать изделие от документа, который его описывает. Каждое такое решение меняет не только структуру базы данных.

Оно меняет саму систему.

1.5. Почему ошибка модели опаснее ошибки кода

Ошибка в программном коде обычно обнаруживается. Программа падает. Тест не проходит. Сервис возвращает ошибку. Ошибку модели обнаружить значительно сложнее.

Система может работать годами. Пользователь создаёт изделие. Выпускает документ. Делает ревизию. Передаёт данные в производство. Формирует отчёт. Технически всё работает. Но если модель неправильно отвечает на вопрос, что именно является объектом, система постепенно начинает хранить неправильную картину мира. Пользователь начинает приспосабливаться. Если системе не хватает понятия, он использует другое поле. Если нельзя выразить нужную связь, он создаёт дополнительную запись. Если нельзя сохранить нужное состояние, он ведёт его в Excel. Если система не различает два разных инженерных понятия, пользователь начинает кодировать различие в названии, статусе или комментарии.

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

1.6. Почему интерфейс не исправляет плохую модель

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

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

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

1.7. Инженерная система делает проблему особенно сложной

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

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

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

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

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

Она начинается с объекта.

1.8. Первый принцип

Из всего сказанного можно сформулировать первый принцип книги:

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

Человек говорит: «Это автомобиль». Система должна иметь возможность представить:

Автомобиль
    ↓
самостоятельный объект

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

1.9. Связь с дальнейшим развитием модели

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

Все эти вопросы появляются из одного исходного решения: что именно мы считаем объектом? Поэтому выбор объекта является не частным решением разработчика базы данных. Это исходное решение всей информационной системы.

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

Человек воспринимает автомобиль как объект. Компьютер видит только данные.

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

Что существует?

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

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

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019.
• 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-2016. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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

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

2.1. Разговор, который происходит каждый день

На любом промышленном предприятии регулярно происходит один и тот же разговор. Руководитель собирает совещание и говорит: «Мы начинаем разработку нового насоса для магистральных трубопроводов». Присутствующие кивают. Обсуждаются сроки, бюджет, состав команды, требования заказчика. Назначается главный конструктор. Формируется рабочая группа.

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

А в информационной системе его ещё нет.

Возникает вопрос, который кажется философским, но на практике оказывается сугубо инженерным: существует ли этот насос?

Если ответить «нет», тогда что именно обсуждалось на совещании? Что утвердило руководство? На что выделено финансирование?

Если ответить «да», тогда информационная система должна уметь представить объект, который ещё не имеет ни одного описания.

2.2. Как человек решает этот вопрос

Человек не испытывает затруднений. Инженер говорит: «Мне нужен редуктор с передаточным отношением 1:50 и выходным моментом 500 Н·м».

В этот момент редуктор уже существует как объект инженерного мышления. У него есть назначение, есть ключевые требования, есть место в будущей системе. Но нет ни одного документа. Более того, человек способен удерживать этот объект в сознании на протяжении длительного времени. Между первым совещанием и выпуском первого чертежа могут пройти недели или месяцы. Всё это время объект обсуждается. По нему принимаются решения. Рассматриваются варианты. Меняются требования. И ни у кого не возникает мысли, что объекта «ещё нет» только потому, что чертёж ещё не выпущен.

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

Описание следует за объектом, а не наоборот.

2.3. Как решает этот вопрос информационная система

Для информационной системы ситуация сложнее. Компьютер не знает, что люди имеют в виду под словом «насос». Он видит только данные.

Если в базе есть документ — система знает о документе. Если есть спецификация — система знает о спецификации. Если есть трёхмерная модель — система знает о модели.

Но где сам насос?

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

Реальный мир:
  Объект
     ↓
  Описание
     ↓
  Документы

Информационная система:
  Документ
     ↓
  Запись о документе

  Спецификация
     ↓
  Запись о спецификации

  CAD-модель
     ↓
  Запись о модели

Вторая модель может прекрасно управлять документами. Но она не представляет сам объект. Это означает, что вопрос «что существует?» должен быть решён до вопроса «как это хранить?».

2.4. Объект существует до первого документа

Рассмотрим простой пример. Предприятие принимает решение разработать новый насос. В первый день проекта ещё нет чертежа. Нет CAD-модели. Нет спецификации. Но есть:

• назначение будущего изделия;
• требования заказчика;
• предполагаемые характеристики;
• ответственный инженер;
• бюджет проекта;
• сроки разработки;
• решение о начале работ.

Через неделю появляется первый эскиз. Через месяц — первая CAD-модель. Через три месяца — комплект конструкторской документации. Через полгода — первый изготовленный образец. Что произошло с объектом?

Он не возник в момент появления первого эскиза. Эскиз появился позже и стал первым его формальным описанием. Не возник он и в момент выпуска чертежа. Чертёж лишь зафиксировал уже существующее инженерное решение. Не возник он и в момент изготовления первого экземпляра. Изготовленный экземпляр — это уже конкретный предмет, созданный по определённому описанию.

Поэтому необходимо различать:

Объект
   │
   ├── существует
   │
   └── постепенно получает описания
           │
           ├── требования
           ├── эскиз
           ├── CAD-модель
           ├── чертёж
           └── спецификация

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

2.5. Что говорит инженерная практика

ГОСТ 2.101-2016 определяет изделие как предмет или набор предметов производства, подлежащих изготовлению по конструкторской документации. Это определение важно именно своей границей: изделие и документация — разные понятия. Документация предназначена для производства и применения изделия, но не является самим изделием.

ГОСТ 15.002-2018 рассматривает разработку продукции как процесс, начинающийся с формирования требований и технического задания, а не с выпуска полного комплекта конструкторской документации. Это означает, что инженерная деятельность вокруг будущего изделия начинается раньше появления чертежей.

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

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

Та же граница видна в практике Configuration Management.

ANSI/EIA-649-D рассматривает configuration item как объект, конфигурация которого подлежит управлению. Управление включает его идентификацию и управление информацией о его состоянии.

NASA Configuration Management Handbook формулирует это ещё яснее:

A CI may be identified at any point in the life cycle when its configuration needs to be controlled. Early identification does not require complete documentation.

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

Это важное различие.

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

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

2.7. ISO 10303-239: объект и его описание

Особенно наглядно это разделение представлено в ISO 10303-239, Product Life Cycle Support.

Модель различает:

• product_concept — концепцию продукта;
• product — продукт;
• product_instance — конкретный изготовленный экземпляр.

При этом концепция не является версией продукта, документом или конфигурацией. Она представляет самостоятельную сущность, которая существует до появления полного описания продукта.

Это существенно для нашей модели.

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

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

2.8. Жизненный цикл начинается не с документа

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

Замысел
      ↓
Определение требований (ТЗ)
      ↓
Проектирование
      ↓
Выпуск документации
      ↓
Изготовление
      ↓
Испытания
      ↓
Эксплуатация
      ↓
Обслуживание и ремонт
      ↓
Модернизация
      ↓
Снятие с эксплуатации

Документы появляются на этапе проектирования.

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

ГОСТ 15.002-2018 фиксирует начальные стадии разработки продукции через формирование требований и технического задания. Поэтому жизненный цикл разработки нельзя свести к выпуску конструкторской документации.

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

2.9. Парадокс первого документа

Рассмотрим ситуацию более внимательно. Конструктор получает задание разработать насос. Он открывает систему. Система предлагает создать документ. Но какой?

Чертёж? Ещё рано — конструкция не определена. Спецификацию? Состав изделия ещё неизвестен. Пояснительную записку? Возможно, но это уже описание, а не сам объект.

Получается парадокс.

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

Система требует результат там, где ещё идёт процесс.

В реальной инженерной практике этот парадокс решается просто: люди начинают работать вне системы. Проводят совещания, делают наброски, обсуждают варианты, формируют требования. И только когда появляется первый формальный документ, объект «появляется» в цифровой среде.

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

2.10. Что происходит, когда объект появляется вместе с документом

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

Первая: теряется начало жизненного цикла.

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

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

Система фактически говорит: «Вот чертёж — значит, вот изделие». Но чертёж является описанием изделия, а не самим изделием.

Третья: изменение документа начинает выглядеть как изменение объекта.

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

Четвёртая: разные области деятельности получают разные «объекты».

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

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

2.11. Один объект — много документов

Рассмотрим насос Н1. Он может быть описан:

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

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

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

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

Это различие станет основой следующей главы.

2.12. Что это означает для модели данных

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

Объект.

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

Описание.

Оно представляет знание об этом объекте в определённой области. В простейшем виде:

Объект
    │
    ├── Описание
    │      ├── Версия A
    │      └── Версия B
    │
    ├── Другое описание
    │      └── Версия A
    │
    └── Документы

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

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

2.13. Граница вопроса

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

Когда руководитель говорит: «Мы когда-нибудь сделаем новый насос», этого уже достаточно? Или это пока только намерение?

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

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

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

Это будет предметом следующих глав.

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

Глава 1 установила: информационная система не понимает объекты автоматически. Человек должен определить, что именно является объектом.

Глава 2 добавляет: после того как объект определён, его нельзя отождествлять с его описанием. Объект может существовать раньше первого документа.

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

Объект существует независимо от своего описания.

Ни документ, ни чертёж, ни CAD-модель, ни спецификация не создают изделие. Они фиксируют знание об изделии.

Это различие подтверждается совокупностью международных стандартов Configuration Management, ISO 10303-239 и отечественной инженерной практики. При этом важно различать источник и вывод: стандарты прямо допускают раннюю идентификацию объекта до завершения документации, а утверждение «объект существует до описания» является логическим выводом из этой модели, а не дословной формулировкой одного стандарта.

Для информационной системы это означает принципиальное требование:

объект должен быть представлен отдельно от его описания.

Он может существовать без чертежа. Может существовать без CAD-модели. Может существовать без спецификации. Описание появляется позже и развивается независимо.

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

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

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

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

Источники:

• ГОСТ 2.101-2016. Единая система конструкторской документации. Виды изделий. П. 3.1.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• ГОСТ 15.002-2018. Система разработки и постановки продукции на производство. Продукция производственно-технического назначения.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.2.
• NASA/SP-2016-610, Rev. 2, NASA Configuration Management Handbook, NASA, 2016. §3.1.
• ISO 10303-239, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
• CMII Institute, CMII Standard for Configuration Management, Release 3.0. §2.1.

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

Глава 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. Единая система конструкторской документации. Электронная структура изделия. Общие положения.

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

Глава 4. Когда изменение создаёт новый объект?

4.1. Разговор, который происходит без слов

Представим простую ситуацию. Владелец автомобиля отправляет его в ремонт. Меняют тормозные колодки, масляный фильтр, свечи зажигания. Автомобиль возвращается. Владелец говорит: «Мой автомобиль из ремонта». Никто не удивляется. Никто не спрашивает: «А это всё ещё тот же автомобиль?»

Теперь представим другую ситуацию. Тот же владелец приходит в автосалон. Ему предлагают новую модель той же марки. Название похоже. Логотип тот же. Но владелец говорит: «Это другой автомобиль». И снова никто не удивляется.

Человек проводит эту границу мгновенно и безошибочно. Замена колодок — ремонт. Новая модель — другой объект. При этом никто не формулирует явного правила. Никто не составляет перечень критериев. Граница существует в инженерной интуиции, которая формировалась десятилетиями практики.

Но попробуйте объяснить это компьютеру.

4.2. Почему компьютер не видит границы

Для информационной системы любое изменение выглядит одинаково. Заменён материал покрытия — новая запись. Изменён диаметр вала — новая запись. Добавлено новое крепёжное отверстие — новая запись. Система не знает, какое из этих событий сохраняет объект, а какое создаёт новый.

Если модель данных не содержит явного критерия, пользователь вынужден принимать решение самостоятельно. И здесь начинается проблема. Один инженер считает, что замена материала — это новое изделие. Другой считает, что это лишь уточнение документации. Третий полагает, что изменение цвета корпуса требует нового обозначения. Все трое могут быть по-своему правы в рамках своего опыта. Но система получает три разных ответа на один и тот же вопрос.

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

4.3. Как человек на самом деле проводит границу

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

Возьмём конкретный пример. Насос. Конструктор изменил материал корпуса: вместо чугуна использована сталь. Размеры остались прежними. Присоединительные отверстия на тех же местах. Расход и напор не изменились. Можно ли снять старый насос и поставить новый? Да. Инженер говорит: «Это тот же насос. Изменилось описание».

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

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

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

4.4. Form, Fit, Function: три слова, которые определяют границу

Принцип взаимозаменяемости формализован через три критерия, известных как FFF:

Form (форма) — геометрические характеристики объекта: размеры, контуры, масса, внешний вид.

Fit (посадка) — способность объекта занимать предназначенное ему место в системе: присоединительные размеры, допуски, интерфейсы.

Function (функция) — способность объекта выполнять предназначенную ему работу: производительность, мощность, точность, надёжность.

Если изменение сохраняет все три критерия, объект остаётся тем же. Изменяется его описание. Нарушение взаимозаменяемости является основанием для оценки необходимости новой идентификации объекта. В модели Constructum это оформляется как граница между изменением существующего описания и созданием нового объекта.

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

4.5. Что говорят стандарты управления конфигурацией

Стандарт ANSI/EIA-649-D «Configuration Management Standard» (2019) определяет:

A change that affects form, fit, or function of a configuration item shall be evaluated to determine whether a new configuration item identification is required.

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

Это ключевое положение. Стандарт не говорит: «любое изменение создаёт новый объект». Он говорит: изменение должно быть оценено. И критерий оценки — FFF. Если взаимозаменяемость сохранена, новая идентификация не требуется. Если нарушена — требуется.

NASA Systems Engineering Handbook (NASA/SP-2016-610 Rev. 2) рассматривает управление конфигурацией как сквозную дисциплину и развивает эту мысль через понятие функциональной и физической идентичности. Изменение конфигурации оценивается по его влиянию на характеристики, требования и взаимозаменяемость (interchangeability) элемента в составе общей системы. Если для замены необходимо переделать сопрягаемые элементы или модифицировать систему, взаимозаменяемость нарушена. Объект не может считаться тем же.

MIL-HDBK-61A «Configuration Management Guidance» (2001) формулирует ещё более строго:

A change is classified as affecting interchangeability when it alters the physical or functional characteristics that determine whether one item can be used in place of another.

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

CMII Institute в стандарте CMII Release 3.0 (§4.2) вводит дополнительное понятие:

A configuration item is identified by its ability to perform a required function. Changes that do not affect this ability are managed as revisions of the existing CI. Changes that do affect this ability require establishment of a new CI.

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

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

4.6. Как это закреплено в ЕСКД

Отечественная инженерная практика решает тот же вопрос через систему обозначений и правила внесения изменений.

ГОСТ Р 2.101-2023 «Единая система конструкторской документации. Виды изделий» устанавливает, что изделие имеет обозначение. Обозначение является идентификатором объекта. Если изделие сохраняет обозначение, оно считается тем же изделием. Если получает новое обозначение, оно считается новым.

Но когда необходимо менять обозначение? Ответ даёт инженерная практика, закреплённая в стандартах ЕСКД.

ГОСТ Р 2.503-2023 «Единая система конструкторской документации. Правила внесения изменений» прямо связывает допустимость изменения документа с взаимозаменяемостью. Стандарт устанавливает, что изменения в документы вносят, если они не нарушают взаимозаменяемость изделия с изделиями, изготовленными ранее. Если изменение нарушает взаимозаменяемость изделие получает новое обозначение, а изменения в документы ранее изготовленных изделий не вносятся.

Таким образом, ЕСКД и международные стандарты CM говорят об одном и том же, используя разную терминологию. Критерий один: взаимозаменяемость.

4.7. Практические примеры

Рассмотрим несколько ситуаций, чтобы убедиться, что критерий FFF работает не только в теории.

Болт М8×20. Изменено покрытие: оцинковка заменена на фосфатирование. Размеры те же. Резьба та же. Прочность та же. Болт можно вывернуть и ввернуть новый без каких-либо доработок. FFF сохранён. Это изменение описания.

Болт М8×20. Изменён на М10×30. Другой диаметр. Другая длина. Другая резьба. Старое отверстие не подходит. FFF нарушен. Это новый объект.

Редуктор. Изменён материал шестерни: сталь 40Х заменена на сталь 18ХГТ. Размеры те же. Передаточное отношение то же. Присоединительные размеры те же. Редуктор можно снять и поставить новый. FFF сохранён. Изменение описания.

Редуктор. Изменён диаметр выходного вала с 50 мм на 60 мм. Муфта не подходит. Подшипниковый узел другой. FFF нарушен. Новый объект.

Насос. Изменён поставщик уплотнения. Размеры уплотнения те же. Материал другой, но характеристики сохранены. Насос работает так же. FFF сохранён. Изменение описания.

Насос. Изменён расход с 100 м³/ч на 150 м³/ч. Другая производительность. Другая мощность двигателя. Другая характеристика. FFF нарушен. Новый объект.

4.8. Почему этот критерий не является произвольным

Может показаться, что FFF — это условность. Почему именно форма, посадка и функция? Почему не стоимость? Не масса? Не цвет?

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

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

Именно поэтому критерий привязан не к внутренним свойствам объекта, а к его отношению с окружением. Взаимозаменяемость — это свойство не объекта самого по себе, а объекта в контексте системы.

4.9. Что происходит, когда критерий не заложен в модель

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

Первый: всё является версией. Любое изменение фиксируется как новая Revision одного и того же объекта. Через несколько лет под одним идентификатором оказываются объекты, которые не являются взаимозаменяемыми. Инженер видит «Насос Н1, Revision C» и не может понять: можно ли заменить насос Revision A на Revision C без переделки? Система не отвечает на этот вопрос, потому что модель не содержит критерия.

Второй: всё является новым объектом. Любое изменение приводит к созданию нового идентификатора. Через несколько лет система содержит сотни объектов, которые по сути являются одним изделием с уточнённой документацией. Найти историю становится невозможно. Связи теряются. Отчётность усложняется.

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

4.10. Следствие для модели данных

Если принять принцип FFF как критерий идентичности, модель данных должна содержать два различных механизма. Первый механизм фиксирует изменение описания. Объект остаётся тем же. Изменяется его определение. Появляется новая версия определения.

Объект (изделие)
    |
    +-- Определение
            +-- Версия A
            +-- Версия B   ← изменение описания

Второй механизм фиксирует изменение идентичности. Появляется новый объект. Старый объект продолжает существовать. Новый объект получает собственную идентичность.

Объект A (изделие)
    |
    +-- Определение
            +-- Версия A

Объект B (новое изделие)   ← изменение идентичности
    |
    +-- Определение
            +-- Версия A

Эти два механизма не являются вариантами одного и того же. Они отвечают на разные вопросы. Первый: «Как изменилось наше знание об объекте?» Второй: «Появился ли новый объект в реальном мире?»

4.11. Граница применимости

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

Для программного обеспечения понятие взаимозаменяемости размыто. Программа не имеет физической формы. Её нельзя вынуть из системы и поставить другую без переделки интерфейсов. Критерий FFF в классическом смысле здесь не применим.

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

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

Эти ограничения не отменяют принцип. Они указывают, что FFF является инструментом, а не догмой. Инженер применяет его осознанно, понимая контекст.

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

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

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

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

Этот критерий закреплён в международных стандартах управления конфигурацией (ANSI/EIA-649-D, NASA Systems Engineering Handbook, MIL-HDBK-61A, CMII) и в отечественной системе ЕСКД (ГОСТ Р 2.101-2023, ГОСТ Р 2.503-2023). Он не является произвольным. Он отражает фундаментальное свойство инженерной деятельности: объект существует не изолированно, а в системе, и его идентичность определяется отношением с окружением.

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

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

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §5.3.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. (Раздел о Configuration Management и interchangeability).
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §3.2.
• CMII Institute, CMII Standard for Configuration Management, Release 3.0. §4.2.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ 2.114-2016. Единая система конструкторской документации. Технические условия.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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

Глава 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. Единая система конструкторской документации. Термины и определения.

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

Глава 5а. Сначала изделие, потом его определение

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

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

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

5а.1. Изделие начинают проектировать до того, как начинают его подробно определять

Представим начало разработки сложной системы.

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

Изделие A
│
├── Изделие B
├── Изделие C
├── Изделие D
└── Изделие E

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

Для B уже известно, что это двигатель. Для C — система управления. Для D — силовая установка. Для E — элемент конструкции.

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

B → ранее разработанное изделие

Некоторые только предстоит разработать:

C → новое изделие

Некоторые будут разрабатываться другой организацией:

D → соисполнитель

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

5а.2. Сначала появляются «кубики»

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

                     A
                     │
        ┌────────────┼────────────┐
        │            │            │
        B            C            D
     двигатель    управление   конструкция

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

Конструктор B получает задачу спроектировать двигатель:

B
│
├── B1
├── B2
└── B3

И снова сначала появляется структура:

двигатель
│
├── система питания
├── система управления
└── механическая часть

А уже затем начинается детальное определение этих составных частей. Процесс повторяется:

A
│
├── B
│   ├── B1
│   ├── B2
│   └── B3
│
├── C
│   ├── C1
│   └── C2
│
└── D
    ├── D1
    └── D2

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

5а.3. Структура появляется раньше полного определения

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

Структура изделия отвечает на вопрос: Из каких изделий должно состоять данное изделие?

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

Эти вопросы связаны, но они не совпадают. Чтобы спроектировать:

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

не обязательно уже иметь полностью определённые B, C и D. Достаточно, чтобы в проекте были идентифицированы сами изделия и установлены необходимые отношения между ними. Поэтому:

проектирование A
       ↓
определение его структуры
       ↓
идентификация B, C, D
       ↓
проектирование B, C, D
       ↓
их определения
       ↓
детализация

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

5а.4. Что говорит ГОСТ Р 2.711-2023

Эта логика хорошо согласуется с ГОСТ Р 2.711-2023 «Единая система конструкторской документации. Схема деления изделия на составные части». Особенно показательно примечание 1 к пункту 4.1:

Схему деления разрабатывают для документирования принимаемых проектных решений, связанных с использованием ранее разработанных изделий («заимствованные изделия» по ГОСТ Р 2.101) и с привлечением организаций-соисполнителей для разработки («кооперированные изделия» по ГОСТ Р 2.101), и для решения других организационно-технических задач на этапах разработки.

Это важная формулировка. Стандарт говорит не о готовом комплекте конструкторской документации, а именно о проектировании. И в процессе этого проектирования принимаются решения:

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

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

Главный конструктор фактически отвечает сначала на вопрос: Что должно войти в изделие и откуда это возьмётся?

И только затем на более низких уровнях проектирования появляется вопрос: Как именно устроена каждая из этих частей?

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

5а.5. Ранее разработанное изделие не становится другим изделием

Здесь появляется ещё один важный момент.

Предположим, существует изделие Б123. В одном проекте оно используется как ранее разработанное (заимствованное):

Изделие A
    │
    └── Б123
         (заимствованное)

В другом проекте такое же изделие может быть включено в состав как часть, разрабатываемая в рамках текущего проекта:

Изделие B
    │
    └── Б123
         используется в текущей разработке

Само Б123 от этого не становится другим изделием. Меняется его роль в конкретной структуре. То же самое относится к соисполнителю. Одна и та же организация может участвовать в разработке/изготовлении Б123 в одном проекте и не участвовать в другом. Следовательно, такие сведения нельзя безоговорочно рассматривать как неизменные свойства самого изделия.

Это свойства участия изделия в конкретной структуре.

5а.6. ГОСТ Р 2.101-2023 показывает ту же границу

Эта мысль становится ещё яснее, если посмотреть на классификацию изделий в ГОСТ Р 2.101-2023.

Стандарт определяет несколько видов изделий, различающихся по своим характеристикам и роли в системе производства. Например, по конструктивно-функциональным характеристикам выделяются:

деталь
сборочная единица
комплекс
комплект

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

изделие собственного производства
кооперированное изделие
покупное изделие

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

Поэтому возникает естественное разделение:

                  Изделие
                     │
          ┌──────────┴──────────┐
          │                     │
     свойства изделия       участие в структуре
          │                     │
          │                     ├── происхождение
          │                     ├── изготовление
          │                     ├── количество
          │                     ├── позиция
          │                     └── соисполнитель

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

5а.7. В модели Constructum это становится свойством связи

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

KObject Б123

И есть его участие в составе A:

KObject A
      │
      └── KRelation ──→ KObject Б123

Сама связь может нести сведения, которые не принадлежат ни A, ни Б123 сами по себе:

KRelation
│
├── количество
├── позиция
├── происхождение
├── применяемость
├── соисполнитель
└── другие свойства вхождения

Это позволяет сохранить важное различие:

KObject
    = что существует

KRelation
    = как один объект участвует в отношении с другим

KDefinition
    = что мы определили об объекте

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

KObject A
KObject B
KRelation A → B

а KDefinition для B появится позже.

5а.8. Проектирование сверху вниз

Теперь можно увидеть более общую картину.

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

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

Затем B передаётся на следующий уровень проектирования:

B
├── B1
├── B2
└── B3

Затем B1:

B1
├── B1.1
├── B1.2
└── B1.3

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

Скорее наоборот:

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

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

5а.9. Почему изделие должно существовать раньше своего определения

Теперь возвращаемся к исходному вопросу.

Если конструирование начинается с формирования структуры, то изделие должно иметь возможность существовать до появления его полного определения. Иначе невозможно последовательно представить сам процесс проектирования. Получается парадоксальная ситуация:

Чтобы спроектировать A,
нужно сначала полностью определить B.

Чтобы определить B,
нужно сначала спроектировать B.

Но чтобы спроектировать B,
нужно уже знать, что B входит в A.

Такой порядок заставляет определение предшествовать тому этапу проектирования, на котором это определение ещё только должно возникнуть. Разделение изделия и определения снимает это противоречие.

A
│
├── B
├── C
└── D

Сначала можно зафиксировать сами изделия и их участие в структуре. Затем каждый из этих элементов может быть передан на следующий уровень проектирования. И только там начинается его собственное определение:

B
│
└── KDefinition B
       │
       └── Revision

5а.10. Revision появляется ещё позже

Отсюда следует и более ранний вывод Главы 5.

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

KObject
   │
   │ изделие идентифицировано
   ↓
структура и отношения
   │
   │ начинается проектирование
   ↓
KDefinition
   │
   │ появляется содержательное определение
   ↓
Revision
   │
   │ фиксируется состояние определения
   ↓
следующая Revision

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

Что должно существовать?
        ↓
Изделие

Как оно участвует в системе?
        ↓
Связь и структура

Что представляет собой изделие?
        ↓
Определение

Какое состояние этого определения зафиксировано?
        ↓
Revision

Это не искусственное разделение. Оно отражает разные этапы инженерного знания.

5а.11. Конструирование начинается до документа

Здесь можно сделать ещё один шаг.

Мы привыкли видеть результат работы конструктора в виде:

чертёж
спецификация
3D-модель
технические требования

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

замысел
   ↓
состав
   ↓
границы частей
   ↓
распределение разработки
   ↓
использование ранее разработанных изделий
   ↓
взаимодействие соисполнителей
   ↓
уточнение структуры
   ↓
определение изделий
   ↓
конструкторская документация

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

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

5а.13. Главный вывод

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

Сначала конструктор проектирует целое.

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

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

Каждая выделенная часть становится самостоятельным объектом проектирования. И только после этого начинается её собственное определение. Поэтому:

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

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

                Изделие
                   │
                   ↓
          проектирование структуры
                   │
          ┌────────┼────────┐
          ↓        ↓        ↓
        Изделие  Изделие  Изделие
           │        │        │
           ↓        ↓        ↓
      их собственное определение
           │
           ↓
        Revision

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

Сначала проектируется то, что должно существовать. Затем определяется то, что спроектировано.

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

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

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

Источники:

• ГОСТ Р 2.711-2023. Единая система конструкторской документации. Схема деления изделия на составные части. П. 4.1, прим. 1.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.113-75. Единая система конструкторской документации. Групповые и базовые конструкторские документы.
• ГОСТ 15.002-2018. Система разработки и постановки продукции на производство. Продукция производственно-технического назначения.
• ISO 10303-239, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.2.

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

Глава 6. Изменение — это процесс

6.1. Изменение не происходит само

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

Но тогда возникает следующий вопрос. Если изменение описания не является просто созданием новой Revision, что представляет собой само изменение?

На практике инженер говорит: «Нужно изменить конструкцию».

Но за этой короткой фразой скрывается целый процесс.

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

Изменение — это не момент появления новой Revision.

Изменение — это управляемый процесс, результатом которого становится новое состояние управляемой информации.

6.2. Как выглядит изменение без процесса

Представим простой сценарий. Конструктор открыл чертёж насоса Н1. Нашёл отверстие, которое нужно увеличить с 10 до 12 мм. Изменил значение. Сохранил файл. Файл теперь содержит новое значение.

Но произошло ли управляемое изменение?

Мы не знаем. Неизвестно:

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

Технически данные изменились. Инженерно управление изменением ещё не произошло.

Именно поэтому зрелая инженерная практика отделяет изменение данных от управления изменением.

6.3. Что говорит промышленная практика

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

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

Ключевое здесь — соответствие.

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

MIL-HDBK-61A также вводит понятие Engineering Change Proposal — предложения об инженерном изменении:

An ECP is a formal request to change the configuration of a CI. It shall include a description of the proposed change, the reason for the change, and an assessment of the impact on affected CIs.

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

6.4. ISO 10007: изменение как отдельный процесс

ISO 10007:2017 Quality management — Guidelines for configuration management определяет пять процессов управления конфигурацией:

Configuration management comprises:

• configuration management planning;
• configuration identification;
• configuration change management;
• configuration status accounting;
• and configuration audit.

Среди них отдельно выделено configuration change management — управление изменениями конфигурации.

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

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

ГОСТ Р ИСО 10007-2019 сохраняет ту же структуру.

Revision появляется внутри этого процесса как результат изменения описания.

6.5. ЕСКД: отечественная формализация изменения

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

Центральным документом является ГОСТ Р 2.503-2023 «Единая система конструкторской документации. Правила внесения изменений». Стандарт устанавливает, что изменение в конструкторскую документацию вносится на основании извещения об изменении. ГОСТ Р 2.504-2021 дополняет его в части внесения изменений в электронную конструкторскую документацию.

Извещение содержит сведения, необходимые для внесения изменения, включая:

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

Изменение не сводится к записи:

Revision A → Revision B

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

6.6. Что общего между стандартами

Если сопоставить CMII, EIA-649, NASA Systems Engineering Handbook, MIL-HDBK-61, ISO 10007 и ЕСКД, терминология различается, но структура процесса оказывается очень похожей.

Предложение об изменении
        ↓
Оценка влияния
        ↓
Утверждение / отклонение
        ↓
Реализация
        ↓
Верификация
        ↓
Учёт и отчётность

Названия различаются. Процесс один.

6.7. Почему недостаточно Revision

Теперь становится понятно, почему нельзя сделать Revision центром всей модели изменения.

Revision отвечает на вопрос: какое состояние описания зафиксировано?

Но Revision не отвечает сама по себе на вопросы: Почему возникла необходимость изменения? Кто предложил изменение? Какие последствия были оценены? Кто разрешил изменение? Когда оно вступило в действие? Какие изделия оно затрагивает? Как проверено его выполнение?

Если все эти сведения хранить внутри Revision, Revision превращается в контейнер для совершенно разных понятий.

Она начинает одновременно означать:

• состояние описания;
• предложение изменения;
• основание;
• решение;
• разрешение;
• результат реализации;
• историю процесса.

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

6.8. Baseline: относительно чего происходит изменение

Есть ещё один важный элемент процесса — baseline.

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

ISO 10007 указывает:

Configuration baselines shall be established at appropriate points in the life cycle to provide a basis for change management.

Базовая конфигурация создаёт контролируемую точку отсчёта для последующих изменений.

NASA Systems Engineering Handbook формулирует ту же идею:

Baselines are established at key points in the life cycle to provide a controlled reference for subsequent changes.

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

Таким образом:

Baseline B1
     │
     ├── Change 1
     │
     ▼
Baseline B2
     │
     ├── Change 2
     │
     ▼
Baseline B3

Baseline отвечает на простой вопрос: относительно чего мы определяем изменение?

Без этой точки отсчёта невозможно однозначно определить, что именно изменилось.

6.9. Кто принимает решение

Изменение редко затрагивает только одну инженерную область.

Изменение диаметра отверстия может затронуть:

• конструкцию;
• технологию;
• производство;
• закупки;
• испытания;
• эксплуатацию;
• качество;
• уже изготовленные изделия.

Поэтому в практике управления конфигурацией решение об изменении принимается не просто автором изменения.

В CMII и EIA-649 используется Configuration Control Board — CCB.

В NASA также используется CCB, причём состав участников определяется характером изменения.

В MIL-HDBK-61 используется механизм Engineering Change Review Board.

ISO 10007 говорит о назначенном органе или лице, ответственном за управление изменениями.

В ЕСКД решение оформляется в установленном организацией порядке.

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

изменение должно быть оценено с учётом всех затронутых областей.

Конструктор не всегда может самостоятельно определить последствия для производства. Производство не может самостоятельно определить последствия для конструкции. Эксплуатация не может самостоятельно определить влияние изменения на документацию.

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

6.10. Что должна хранить информационная система

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

Минимально необходимо иметь возможность восстановить:

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

Это уже не одна Revision. Это цепочка связанных сущностей.

Объект
     │
     └── Описание
            │
            ├── Revision A
            │
            └── Revision B
                   ↑
                   │
                Change
                   │
                   ├── Proposal
                   ├── Impact Assessment
                   ├── Decision
                   ├── Implementation
                   └── Verification

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

6.11. Изменение может не привести к новой Revision

Это ещё одно важное следствие.

Не каждое действие, связанное с изменением, обязательно приводит к новой Revision.

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

Поэтому нельзя строить процесс вокруг предположения:

Change = новая Revision

Правильнее:

Change
   │
   ├── rejected
   ├── cancelled
   ├── deferred
   └── implemented
            │
            └── новая Revision

Revision является возможным результатом процесса изменения, но не самим процессом.

6.12. Изменение объекта и изменение его описания

Теперь можно связать эту главу с выводом Главы 4.

Изменение начинается одинаково:

Предложение изменения
        ↓
Оценка
        ↓
Что именно изменилось?

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

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

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

                 Change
                   │
            ┌──────┴──────┐
            │             │
     тот же объект    новый объект
            │             │
      новая Revision   новый объект

Это означает, что решение о Revision нельзя принимать автоматически только потому, что пользователь изменил данные. Сначала необходимо определить, что именно изменилось.

6.13. Практический пример

Вернёмся к насосу Н1.

В Revision A отверстие имеет диаметр 10 мм. Инженер предлагает изменить его на 12 мм. Возникает Change C-1024.

Change C-1024
  Причина:
      изменение требований к креплению
  Затронуты:
      конструкторское описание
      технологический процесс
      спецификация
  Оценка:
      производство — допустимо
      технология — требуется изменение операции
      испытания — повторные испытания не требуются
  Решение:
      утверждено
  Реализация:
      Revision B
  Введение:
      с серийного изделия №250

В результате система хранит не просто:

Revision A → Revision B

Она хранит историю:

Почему появилась Revision B? → Change C-1024

Почему возник Change C-1024? → изменение требований

Кто оценивал? → конструктор + технолог

Что изменилось? → отверстие 10 → 12 мм

С какого изделия применяется? → №250

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

[Иллюстрация 7: Временная ось. На ней отмечены точки Baseline (B1, B2, B3). Между ними — изменения (Change 1, Change 2, Change 3). Каждое изменение ссылается на предыдущий Baseline.]

6.14. Граница применимости стандартов

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

Стандарты CM определяют процессы, роли, требования к контролю изменений, базовые конфигурации, учёт состояния и аудит.

Они не предписывают конкретную модель данных Constructum. Они не говорят, что Change, Revision, Proposal или Impact Assessment должны быть отдельными таблицами или объектами.

Это уже архитектурное решение.

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

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

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

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

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

Глава 6 добавляет: изменение является управляемым процессом.

Если объект остаётся тем же, изменение реализуется как новая Revision его описания.

Если изменился сам объект, результатом становится новый объект.

В обоих случаях решение должно быть прослеживаемым.

Модель данных должна поддерживать оба пути и не смешивать процесс изменения с результатом изменения.

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

Промышленность формализовала управление изменениями более полувека назад. CMII, EIA-649, NASA Systems Engineering Handbook, MIL-HDBK-61, ISO 10007 и ЕСКД описывают изменение как управляемый процесс.

Изменение начинается не с новой Revision. Оно начинается с предложения, проходит через оценку, решение, реализацию и верификацию, а затем приводит к новому состоянию управляемой информации.

Поэтому информационная система должна хранить не только:

Revision A → Revision B

но и ответ на вопросы:

• Почему?

• Кто?

• На каком основании?

• Что затронуто?

• Кто оценил?

• Кто утвердил?

• Когда вступило в силу?

• Как проверено?

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

Revision фиксирует состояние.

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

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

Часть I завершена. Мы установили, что изменение описания и изменение объекта — разные события, что Revision принадлежит описанию, и что изменение является управляемым процессом. В Части II мы перейдём к вопросу существования: что значит, что изделие изготовлено, и как система различает возможное и реальное.

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

Источники:

• CMII Institute, CMII Standard for Configuration Management, Release 3.0. §1.1, §2.1–2.4.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.3, §4.2.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §5.1, §5.3.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §2.1, §4.1.
• ISO 10007:2017, Quality management — Guidelines for configuration management. §3.1–3.5.
• ГОСТ Р ИСО 10007-2019. Менеджмент качества. Руководящие указания по менеджменту конфигурации.
• ГОСТ Р 2.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ 3.1128-88. Единая система технологической документации. Общие правила выполнения изменений технологической документации.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.114-2016. Единая система конструкторской документации. Технические условия.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• ГОСТ 15.002-2018. Система разработки и постановки продукции на производство. Продукция производственно-технического назначения.

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

Часть II. Что происходит с объектом?

Глава 7. Вариант — или изделие?

В этой главе слово «конфигурация» используется в прикладном смысле конфигуратора — как комбинация выбранных параметров и опций. Это значение не следует отождествлять с нормативным термином Configuration в Configuration Management. Это различие будет отдельно установлено в Главе 16а.

7.1. Разговор в отделе продаж

Представим автомобильный завод. В отдел продаж поступает заказ: «Нам нужен автомобиль с двигателем 2.0, автоматической коробкой, пакетом Winter и кожаным салоном». Менеджер открывает конфигуратор. Выбирает параметры. Система проверяет их совместимость. Комбинация допустима. Заказ принят.

Теперь представим тот же разговор на языке производства. Мастер цеха получает задание. Он не спрашивает: «Какую конфигурацию собрать?»

Он спрашивает: «Какое изделие изготовить?»

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

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

Но между этими двумя мирами существует граница, которую информационная система должна провести явно.

7.2. Что происходит в конфигураторе

Рассмотрим простой пример. Производитель насосов предлагает несколько вариантов:

Материал корпуса:
    чугун
    сталь
    нержавеющая сталь

Тип уплотнения:
    сальниковое
    торцевое

Присоединение:
    DN50
    DN80
    DN100

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

Сталь + торцевое + DN80       — допустимо
Чугун + сальниковое + DN50    — допустимо
Нержавеющая сталь + DN100     — допустимо
Чугун + торцевое + DN80       — недопустимо

Что существует после работы конфигуратора?

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

Конфигуратор отвечает на вопрос: Что можно получить?

Инженерное определение отвечает на другой вопрос: Что существует как самостоятельное изделие?

7.3. Пространство возможностей шире множества изделий

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

• 700 технически допустимыми;
• 300 экономически нецелесообразными;
• 150 никогда не проектировавшимися;
• 80 не имеющими отдельной документации;
• 30 требующими специальных испытаний;
• 10 реально определёнными изделиями.

Поэтому:

Множество возможных комбинаций
            >
Множество определённых изделий

Это не недостаток конфигуратора. Это нормальная ситуация.

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

7.4. Исполнение — не параметр

Здесь особенно важна отечественная инженерная терминология.

ГОСТ 2.113-75 использует понятие исполнения для изделий, объединённых общим групповым конструкторским документом. В стандарте закреплено требование:

«…должна быть обеспечена возможность самостоятельного применения, изготовления и учёта каждого исполнения».

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

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

7.5. Что говорит ГОСТ Р 2.101

ГОСТ Р 2.101-2023 определяет изделие как: «предмет или набор предметов производства, подлежащих изготовлению на предприятии».

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

Изделие — не любая математически допустимая комбинация параметров. Оно является предметом производства.

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

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

7.6. Когда вариант становится изделием

Представим насос:

Сталь
+
торцевое уплотнение
+
DN80

Конфигуратор говорит: комбинация допустима.

Но инженер задаёт следующий вопрос: Нужно ли для неё самостоятельное обозначение?

Если да:

Нужна ли собственная конструкторская документация?

Если да:

Нужна ли отдельная технология изготовления?

Если да:

Нужны ли отдельные испытания или отдельные правила приёмки?

Если предприятие принимает решение, что эта комбинация является самостоятельным изделием, появляется исполнение.

Теперь система может представить:

Исполнение Н1-Ст-Т-DN80

Обозначение:
    Н1-Ст-Т-DN80

Документация:
    определена

Технология:
    определена

Учёт:
    ведётся как самостоятельного изделия

Это уже не просто результат конфигуратора.

Это инженерно определённое изделие.

7.7. Модель вариантов не исчезает

Из этого не следует, что конфигуратор не нужен. Наоборот.

Конфигуратор остаётся механизмом управления пространством возможностей. Он позволяет:

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

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

«Если комбинация технически возможна, значит, изделие существует».

А это неверно.

7.8. Что говорит CMII

CMII формулирует этот принцип непосредственно через конфигурационную единицу. В стандарте CMII Release 3.0 (§2.3) приводится правило:

A configuration item is an aggregation of hardware, software, or other product that satisfies an end use function and is designated for configuration management. A CI must have a defined configuration that can be identified, controlled, and audited.

Обратите внимание на три требования: идентифицирована, управляема, аудируема.

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

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

7.9. Что говорят международные модели данных

ISO 10303-239 (PLCS) разделяет product_concept, product и product_instance. Концепция продукта описывает замысел или возможное решение. Продукт описывает определённое изделие. Экземпляр описывает конкретный изготовленный предмет.

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

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

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

7.10. 150% BOM и пространство возможностей

В западных PLM для управления вариантами широко используется концепция 150% BOM.

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

Продукт
    |
    +-- Компонент A — обязательный
    +-- Компонент B — обязательный
    +-- Компонент C — вариант 1
    +-- Компонент D — вариант 2
    +-- Компонент E — опция
    +-- Компонент F — опция

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

когда появляется конкретное изделие?

Пока существует только 150% BOM и правила выбора, система знает, что можно собрать. Она ещё не знает, что предприятие определило каждую конкретную комбинацию как самостоятельное изделие.

7.11. Групповая спецификация решает другую задачу

ГОСТ 2.113-75 решает задачу иначе.

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

Группа исполнений
    |
    +-- Исполнение 1
    |
    +-- Исполнение 2
    |
    +-- Исполнение 3

Здесь нижний уровень — не возможные варианты. Каждый элемент уже определён как самостоятельное изделие. Это принципиальное различие:

150% BOM
    ↓
Пространство возможностей

Группа исполнений
    ↓
Множество определённых изделий

Группа исполнений существует потому, что несколько изделий имеют общую конструктивную основу. Она не отвечает на вопрос:

«Какой вариант можно получить?»

Она отвечает на вопрос:

«Какие изделия относятся к этой группе?»

7.12. Модель исполнений

В модели исполнений каждое самостоятельное изделие получает собственное место в системе.

Например:

Насосы серии Н1
    |
    +-- Н1-Ч-С-DN50
    |
    +-- Н1-Ст-Т-DN80
    |
    +-- Н1-Нж-Т-DN100

Каждое исполнение:

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

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

7.13. Почему это важно для модели данных

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

Комбинация 001 → Product
Комбинация 002 → Product
Комбинация 003 → Product
...
Комбинация 1000 → Product

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

В ней появляются изделия, которые:

• никогда не проектировались;
• никогда не выпускались;
• не имеют документации;
• не имеют технологии;
• не имеют инженерного решения о самостоятельном учёте.

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

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

7.14. Что происходит в модели, которая различает вариант и изделие

В такой модели последовательность выглядит иначе:

Параметры
    ↓
Конфигуратор
    ↓
Допустимая комбинация
    ↓
Инженерное решение
    ↓
Исполнение
    ↓
Документация

До момента инженерного определения существует возможность. После него существует изделие. Это позволяет системе одновременно хранить:

Что возможно?
        ↓
Конфигурационная модель

Что определено?
        ↓
Исполнения

Что изготовлено?
        ↓
Экземпляры

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

7.15. Исполнение не равно экземпляру

Здесь важно не сделать следующую ошибку.

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

Например:

Исполнение:
    Насос Н1-Ст-Т-DN80

может быть изготовлено тысячу раз.

Получатся:

Экземпляр №0001
Экземпляр №0002
Экземпляр №0003
...
Экземпляр №1000

Исполнение отвечает на вопрос: Какое изделие определено?

Экземпляр отвечает на вопрос: Какой конкретный предмет изготовлен?

Это различие будет подробно рассмотрено в следующей главе.

7.16. Граница применимости

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

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

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

Для инженерных изделий ситуация иная.

Если каждый вариант требует:

• отдельной разработки;
• отдельной документации;
• отдельной технологии;
• отдельных испытаний;
• отдельного учёта,

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

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

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

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

Вернёмся к выводам, сделанным ранее.

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

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

Глава 6 установила: изменение является управляемым процессом.

Глава 7 добавляет: не всякая комбинация параметров является объектом. Объект существует как самостоятельное изделие тогда, когда он инженерно определён.

Конфигурация описывает возможность.

Исполнение описывает определённое изделие.

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

                   Изделие
                      │
          ┌───────────┴───────────┐
          ↓                       ↓
      Описание                Исполнение
          │                       │
      Revision                своё описание
                                  │
                               Экземпляр

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

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

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

Конфигурация описывает определённую совокупность характеристик изделия. Управление вариантами отвечает на другой вопрос — какие разновидности и комбинации могут быть предусмотрены. Исполнение отвечает на вопрос: какие изделия определены?

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

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

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

Возможность — ещё не изделие.

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

Это не запрет на управление вариантами. Это требование не смешивать пространство возможностей с множеством реально определённых изделий.

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

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

Источники:

1. CMII Institute, CMII Standard for Configuration Management, Release 3.0. §2.3.
2. ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.5.
3. ISO 10303-239, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
4. NATO CALS Office, NPDM Version 4.10 — NATO Product Data Model, STANAG 4613 / ALP-14.
5. ГОСТ 2.113-75. Единая система конструкторской документации. Групповые и базовые конструкторские документы.
6. ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
7. NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §3.3.

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

Глава 8 Что значит «изготовлено»?

8.1 Два разговора об одном насосе

Представим предприятие, которое выпускает промышленные насосы. В конструкторском отделе говорят: «Насос Н1 разработан. Документация утверждена. Можно запускать в производство». В производственном цехе говорят: «Насос Н1, экземпляр №12345, изготовлен. Прошёл испытания. Отгружен заказчику».

Оба разговора — об одном и том же насосе. Но они описывают разные сущности. Первый разговор относится к изделию как к инженерному объекту: его конструкции, документации, требованиям и описанию. Второй — к конкретному предмету, который существует в реальном мире, имеет серийный номер, дату изготовления, историю испытаний и конкретного владельца.

Человек легко различает эти сущности. Никто не путает чертёж насоса с насосом, стоящим в цехе. Никто не считает, что серийный номер принадлежит чертежу. Никто не спрашивает: «А какой экземпляр описывает Revision B?» — потому что Revision B относится к описанию изделия, а не к конкретному изготовленному предмету.

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

8.2 Тип и экземпляр: различие, которое кажется очевидным

Рассмотрим простую аналогию.

В библиотеке существует книга «Война и мир». Есть произведение и конкретное издание. Но на полке лежит конкретный экземпляр этой книги. У него может быть свой инвентарный номер, дата поступления, повреждение переплёта и история выдачи.

Другой экземпляр того же издания может не иметь ни одного из этих признаков.

То же самое происходит с инженерным изделием.

Изделие:
      Насос Н1
      Конструкция
      Требования
      Документация
      Revision A
      Revision B
      Revision C

Экземпляр:
      Насос Н1
      Серийный номер 12345
      Дата изготовления
      Результаты испытаний
      Фактическая комплектация
      Отклонения
      История эксплуатации

Изделие отвечает на вопрос:

Что это за изделие?

Экземпляр отвечает на другой вопрос:

Какой конкретный предмет изготовлен?

Эти вопросы нельзя объединить в одну сущность.

8.3 Три состояния одного изделия

В инженерной практике необходимо различать как минимум три состояния представления изделия:

Как спроектировано
      Изделие
      Конструкторская информация
      Revision
      Требования
      Структура
          ↓
Как изготовлено
      Конкретный экземпляр
      Серийный номер
      Дата изготовления
      Применённые описания
      Результаты испытаний
      Отклонения
          ↓
Как эксплуатируется
      Текущее состояние экземпляра
      История обслуживания
      Выполненные модификации
      Заменённые компоненты

Эти состояния связаны между собой, но не тождественны.

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

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

[Иллюстрация 9: Три вертикальных блока: «Как спроектировано», «Как изготовлено», «Как эксплуатируется». Между ними стрелки. Подпись: «Описание изделия, изготовленный экземпляр и эксплуатационная история — разные уровни представления».]

8.4 Почему экземпляр не является Revision

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

Экземпляр не является Revision, потому что экземпляр — это не новая версия описания. Это конкретный предмет, который был изготовлен.

Если Revision B означает изменение описания изделия, то появление экземпляра №12345 не является созданием Revision C. Экземпляр существует независимо от того, сколько Revision прошло описание изделия.

Например:

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

Экземпляр №12345
    изготовлен по Revision B

Revision фиксирует состояние описания. Экземпляр фиксирует существование конкретного предмета.

Это два разных объекта и два разных жизненных цикла.

8.5 Почему экземпляр нельзя отождествлять с результатом конфигурирования

Здесь особенно важно не смешивать два разных значения слова «конфигурация».

В управлении конфигурацией термин configuration имеет стандартизированное значение. ISO 10007 определяет конфигурацию через взаимосвязанные функциональные и физические характеристики изделия, описанные в информации о конфигурации. Configuration Management, соответственно, управляет информацией о состоянии изделия.

Это не то же самое, что вариант, комбинация опций или результат работы конфигуратора. В Главе 16а мы отдельно рассмотрели проблему подмены этого понятия: в современных системах термин Configuration часто используется в контексте выбора вариантов и комплектаций, хотя нормативная семантика Configuration Management значительно шире.

Поэтому здесь мы будем говорить точнее.

Конфигуратор может сформировать конкретную комбинацию допустимых параметров:

Материал корпуса: сталь
Уплотнение:       торцевое
Присоединение:    DN80

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

После изготовления появляется другой факт:

Насос Н1
Серийный номер: 12345
Дата изготовления: 15.03.2026

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

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

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

Результат конфигурирования
    Материал: сталь
    Уплотнение: торцевое
    Присоединение: DN80
        ↓
    Насос №1001
    Насос №1002
    Насос №1003
    ...
    Насос №2000

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

8.6 Почему экземпляр не является вариантом

Вариант отвечает на вопрос о возможном различии между изделиями.

Экземпляр отвечает на вопрос о конкретном существующем предмете.

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

Производитель может определить несколько исполнений насоса:

Насос Н1-Д50
Насос Н1-Д80
Насос Н1-Д100

Каждое исполнение является самостоятельным изделием. Но каждое из них может быть изготовлено многократно:

Н1-Д80
    ├── Экземпляр №001
    ├── Экземпляр №002
    ├── Экземпляр №003
    └── ...

Исполнение отвечает на вопрос:

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

Экземпляр отвечает:

Какой конкретный предмет изготовлен?

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

8.7 Практический пример

Рассмотрим двигатель.

Производство изготовило двигатель с серийным номером 2026-0042. При изготовлении были применены:

• конструкторское описание Revision C;
• технологическое описание Revision B;
• утверждённое отклонение: замена поставщика уплотнения.

Двигатель прошёл испытания. Установлен на самолёт. Эксплуатируется. Через два года выполнен капитальный ремонт. Заменён компрессор. Внесена запись в формуляр.

Где всё это хранится?

Если система содержит только изделие и Revision, ни один из этих фактов не имеет естественного места в модели.

Серийный номер не является Revision. Отклонение не является Revision. Ремонт не является Revision. Формуляр не является Revision.

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

KProduct: Двигатель Д-100
    KDesignDefinition: Revision C
    KTechnologyDefinition: Revision B

Instance: Двигатель Д-100, №2026-0042
    Изготовлен: 10.02.2026
    Применено: KDesignDefinition Rev C
    Применено: KTechnologyDefinition Rev B
    Отклонение: замена поставщика уплотнения
    Испытания: пройдены 12.02.2026
    Установлен: Самолёт RA-12345
    Ремонт: 15.08.2028, замена компрессора

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

8.8 Экземпляр как точка трассируемости

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

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

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

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

Изделие может сказать: Для двигателя Д-100 предусмотрено уплотнение поставщика X.

Но только экземпляр может сказать: Двигатель №2026-0042 был изготовлен с уплотнением поставщика Y по утверждённому отклонению №D-17.

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

8.9 Применённое описание и экземпляр

Это особенно важно для управления конфигурацией. Допустим, существует:

KDesignDefinition
    Revision A
    Revision B
    Revision C

Revision C является текущей. Но это не означает, что каждый изготовленный двигатель соответствует Revision C. Один экземпляр мог быть изготовлен по Revision A, другой — по Revision B, третий — по Revision C.

Поэтому актуальное состояние информации и информация, применённая при изготовлении конкретного экземпляра, — разные вещи.

KProduct: Двигатель Д-100
    Definition
        ├── Revision A
        ├── Revision B
        └── Revision C
    Instances
        ├── №001 → Revision A
        ├── №002 → Revision A
        ├── №101 → Revision B
        └── №201 → Revision C

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

Таким образом, Revision описывает состояние описания, а экземпляр хранит факт того, какое состояние описания было применено к конкретному объекту.

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

8.10 Экземпляр и жизненный цикл

Изделие и экземпляр проходят разные жизненные циклы.

Изделие может существовать десятилетиями:

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

При этом экземпляры появляются и прекращают существование в разные моменты:

Насос №001
    изготовлен 2026
    эксплуатируется
    списан 2041

Насос №002
    изготовлен 2026
    эксплуатируется
    списан 2045

Насос №1500
    изготовлен 2034
    эксплуатируется

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

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

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

8.11 Граница применимости

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

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

В таких случаях достаточно учёта на уровне партии:

Партия №2026-04
    Изделие: Болт М8
    Количество: 100 000
    Изготовлено по: Revision B

Граница проходит там, где появляется необходимость индивидуального учёта. Если изделие:

• имеет формуляр;
• проходит индивидуальные испытания;
• имеет ограниченный ресурс;
• подлежит индивидуальному обслуживанию;
• должно быть прослежено по серийному номеру,

то экземпляр должен быть самостоятельным объектом модели.

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

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

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

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

Глава 8 добавляет: даже определённое изделие не является конкретным изготовленным экземпляром.

Это три разных уровня:

Уровень 1: Информация об изделии
    Что это?
    Каковы его функциональные и физические характеристики?
    Как оно описано?

Уровень 2: Изделие / исполнение
    Какая конкретная разновидность изделия определена?
    Какое описание и документация относятся к ней?

Уровень 3: Экземпляр
    Какой конкретный предмет изготовлен?
    Какой у него серийный номер?
    Когда он изготовлен?
    Какие описания были применены?
    Что с ним происходило после изготовления?

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

Смешивание уровней приводит к потере информации.

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

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

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

При этом термин «конфигурация» нельзя использовать как обозначение варианта или произвольной комбинации параметров. В стандартах управления конфигурацией он имеет специальное значение, связанное с функциональными и физическими характеристиками изделия и информацией, в которой эти характеристики описаны. Подмена этого термина понятием Variant Management является отдельной проблемой, рассмотренной в Главе 16а.

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

Экземпляр связан с изделием и с информацией, применённой при его изготовлении, но не заменяет ни само изделие, ни его описание.

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

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

В следующей главе: где живёт применяемость? Как информационная система связывает конкретное описание изделия с конкретным моментом производства и конкретным экземпляром?

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.6.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §6.2.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §5.4.
• ISO 10007:2017, Quality management — Guidelines for configuration management. §3.1.
• 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.601-2019. Единая система конструкторской документации. Эксплуатационные документы.
• ГОСТ 2.610-2019. Единая система конструкторской документации. Правила выполнения эксплуатационных документов.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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

Глава 9. Где живёт применяемость?

9.1. Вопрос, который задаёт производство

Представим цех. Мастер получает задание: изготовить партию насосов Н1. Он открывает систему и видит: конструкторское описание имеет Revision A, Revision B и Revision C. По какой изготавливать?

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

Инженер отвечает на этот вопрос легко. Он говорит: «Изделия с первого по сотое изготовлены по Revision A. Начиная со сто первого — по Revision B». Для человека это очевидно. Для системы необходимо формальное представление.

Именно эту задачу решает механизм, который в PLM получил название применяемости — effectivity.

9.2. Что такое применяемость

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

Первый:

Какая Revision является актуальной? Это вопрос о состоянии самого описания.

Второй:

Какая Revision была применена при изготовлении конкретного экземпляра? Это вопрос о производстве.

Эти вопросы не совпадают.

Revision C может быть актуальной в системе, в то время как конкретный насос №075 был изготовлен по Revision A. Revision A уже не является актуальной для нового производства, но она остаётся фактом истории конкретного экземпляра.

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

9.3. Применяемость возникает там, где описание встречается с производством

Объект изделия не имеет применяемости. Объект существует. Он не изготавливается. Изготавливается его конкретный экземпляр.

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

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

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

KProduct: Насос Н1
       |
       +-- KDesignDefinition
       |       Revision A
       |       Revision B
       |       Revision C
       |
       +-- KManufacturingDefinition
               |
               +-- Экземпляр №001
               |       Применено: KDesignDefinition Rev A
               |       Изготовлен: 15.01.2026
               |
               +-- Экземпляр №150
               |       Применено: KDesignDefinition Rev B
               |       Изготовлен: 20.04.2026
               |
               +-- Экземпляр №300
                       Применено: KDesignDefinition Rev C
                       Изготовлен: 10.07.2026

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

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

Применяемость связывает одно с другим.

9.4. Почему применяемость нельзя хранить только на Revision

Рассмотрим ситуацию. Насос №075 находится в эксплуатации. Обнаружен дефект. Необходимо определить: по какой документации изготовлен этот экземпляр? Какие изменения в нём учтены? Затрагивает ли дефект другие экземпляры?

Если применяемость хранится только на уровне Revision, система может ответить: Revision A действует для серийных номеров 001–100.

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

Если информация находится на стороне экземпляра, система отвечает непосредственно: Насос №075 изготовлен по KDesignDefinition Revision A, KTechnologyDefinition Revision A. Утверждённых отклонений нет. Дата изготовления: 10.02.2026.

Теперь система знает не только, какая Revision когда-то была применима. Она знает, что именно было применено к конкретному предмету.

Это и есть основа полной производственной трассируемости.

9.5. Почему актуальность и применённость — разные понятия

Рассмотрим ещё одну ситуацию.

Конструктор выпустил Revision C. Она утверждена. Она является актуальной. Но производство ещё не перешло на неё. Цех продолжает изготавливать по Revision B, потому что не израсходован запас заготовок.

В этот момент существуют два факта: актуальное описание — Revision C; применённое описание для текущего производства — Revision B.

Если система смешивает эти понятия, возникает ошибка.

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

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

Конструктор видит: Актуальное описание — Revision C.

Производство видит: Для данной партии применяется Revision B.

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

9.6. Три вида применяемости

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

Серийная применяемость (Serial Effectivity). Описание применяется к экземплярам, определяемым диапазоном серийных номеров.

Revision B действует для:
    серийный номер ≥ 101

Дата применяемости (Date Effectivity). Описание применяется начиная с определённой даты.

Revision B действует для:
    дата изготовления ≥ 01.04.2026

Партионная применяемость (Lot Effectivity). Описание применяется к определённой производственной партии.

Revision B действует для:
    партия №2026-04

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

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

9.7. Где должна находиться применяемость в модели данных

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

Изготавливается экземпляр.

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

В модели Constructum для индивидуально учитываемого изделия это выглядит так:

KProduct
      |
      +-- KDesignDefinition
      |       |
      |       +-- Revision A
      |       +-- Revision B
      |       +-- Revision C
      |
      +-- KManufacturingDefinition
              |
              +-- Instance №001
              |       appliedDesignRevision: A
              |
              +-- Instance №075
              |       appliedDesignRevision: A
              |
              +-- Instance №150
                      appliedDesignRevision: B

Здесь нет утверждения: Revision A «принадлежит» экземплярам №001–075. Есть другое утверждение: Экземпляры №001–075 были изготовлены с применением Revision A.

Это исторический факт производства.

9.8. Связь с управлением изменениями

Применяемость тесно связана с процессом управления изменениями, описанным в Главе 6.

Когда изменение утверждено, необходимо определить: с какого момента оно вступает в производство? Для каких экземпляров будет применяться? Распространяется ли оно на ранее изготовленные изделия?

Эти вопросы не решаются самим фактом появления новой Revision. Например:

Изменение:
    Утверждено: 15.03.2026
    KDesignDefinition: Revision A → Revision B

Производство:
    Перешло на Revision B: 01.04.2026

Экземпляры:
    №001–100 → Revision A
    №101 и далее → Revision B

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

Поэтому утверждение Revision и её применение при изготовлении — разные события.

9.9. Что происходит с ранее изготовленными изделиями

Появление новой Revision не изменяет автоматически уже изготовленные экземпляры. Если насос №075 был изготовлен по Revision A, появление Revision B не превращает его в изделие, изготовленное по Revision B. Это принципиально важно для эксплуатации.

Через несколько лет необходимо иметь возможность ответить: По какой документации был изготовлен насос №075? Ответ не должен зависеть от того, какая Revision является актуальной сегодня. Система должна сохранить исторический факт:

Instance №075
    изготовлен: 10.02.2026
    Design Revision: A

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

Таким образом, применяемость является частью истории конкретного экземпляра.

9.10. Граница применяемости

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

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

Партия №2026-04
    изготовлена по Revision B

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

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

Если необходимо ответить: «Что произошло именно с этим изделием?»

— экземпляр должен быть самостоятельным объектом модели.

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

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

Глава 9 добавляет: применяемость связывает описание с конкретным экземпляром в конкретный момент производства.

Она не является свойством объекта. Не является свойством Revision.

Она является фактом применения конкретного описания при изготовлении конкретного экземпляра.

Вместе эти главы формируют полную картину существования изделия в информационной системе:

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

Применяемость отвечает на вопрос: какое описание было применено при изготовлении конкретного экземпляра?

Это не вопрос об актуальности документации. Не вопрос о текущей Revision. Не вопрос о том, какая версия описания существует сегодня.

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

Международные стандарты управления конфигурацией и модель ISO 10303-239 различают описание изделия и конкретный экземпляр изделия. Требование фиксировать состояние as-built означает, что система должна сохранять информацию о том, что было фактически изготовлено и по какому описанию.

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

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

Не на уровне KProduct. Не как свойство Revision.

А как исторический факт производства.

Именно это позволяет через десять, двадцать или тридцать лет ответить на главный эксплуатационный вопрос: «По какому описанию был изготовлен именно этот экземпляр?»

Применяемость поэтому не является свойством Revision. Она является утверждением о применении определённого описания к определённому объекту в определённых условиях.

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

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §4.4.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §6.3.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §5.5.
• ISO 10303-239, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
• ГОСТ 2.601-2019. Единая система конструкторской документации. Эксплуатационные документы.
• ГОСТ 2.610-2019. Единая система конструкторской документации. Правила выполнения эксплуатационных документов.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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

Глава 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.

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

Глава 11. Объект сохраняется, описание изменяется

11.1. Насос, который живёт тридцать лет

Представим промышленный насос. Он разработан в 2026 году. Изготовлен. Установлен на нефтеперекачивающей станции. Эксплуатируется. Через пять лет выполнен капитальный ремонт. Через десять лет заменён поставщик уплотнений. Через пятнадцать лет модернизирована система контроля. Через двадцать лет изменены требования экологической безопасности. Через тридцать лет насос снят с эксплуатации.

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

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

11.2. Как человек удерживает идентичность

Человек не испытывает затруднений с этой задачей. Мы встречаем знакомого через двадцать лет. Он изменился. Другая причёска. Другая фигура. Другая одежда. Другая работа. Другой город. Но мы говорим: «Это тот же человек». Идентичность сохранена. Свойства изменились.

То же самое с инженерным объектом. Инженер говорит: «Это насос Н1». При этом он не перечисляет все текущие свойства. Он указывает на объект. Объект существует независимо от того, какие свойства ему приписаны в данный момент.

Это естественное свойство человеческого мышления: мы разделяем объект и его описание. Объект постоянен. Описание временно. Компьютер не делает этого разделения автоматически. Его необходимо заложить в модель данных явно.

11.3. Классическая модель: объект равен своим полям

Рассмотрим, как эта задача решается в традиционном подходе.

Product
    id          INTEGER
    name        VARCHAR
    material    VARCHAR
    weight      DECIMAL
    status      VARCHAR
    manufacturer VARCHAR

Объект представлен строкой в таблице. Его свойства являются полями. На первый взгляд это выглядит просто и понятно. Но проходит время. Появляется требование: хранить историю изменения материала. Добавляется таблица:

Product_Material_History
    product_id  INTEGER
    material    VARCHAR
    valid_from  DATE
    valid_to    DATE

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

Product
      id
      name
      material
      weight
      status
      manufacturer
      environmental_class
      digital_passport_id
      certification_status
      repair_level
      ...

 Product_Material_History
 Product_Status_History
 Product_Supplier_History
 Product_Certification_History
 ...

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

11.4. Проблема фиксированной схемы

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

Когда архитектор проектирует таблицу Product, он должен решить: какие поля будут у изделия? Название. Масса. Материал. Статус. Производитель.

Но через пять лет появляются новые понятия, которые никто не мог предвидеть. Экологический класс. Цифровой паспорт. Уровень ремонтопригодности. Статус сертификации по новому стандарту. Идентификатор в государственной системе учёта.

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

11.5. В этом различии появляется временная ось модели

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

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

Object
   │
   ├── Definition A
   ├── Definition B
   └── Definition C

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

Object остаётся.

Definitions сменяют друг друга.

Каждая Definition отвечает на свой вопрос: какое знание действовало в этот период? Именно поэтому история описания не является историей самого объекта. Она является историей знания об объекте.

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

11.6. Что происходит, когда меняется описание

Вернёмся к насосу Н1.

В 2026 году его описание выглядит так:

Насос Н1
    материал: Сталь 20
    масса: 850 кг
    производитель: Предприятие А

В 2030 году поставщик стали изменился. В 2035 году изменился материал корпуса. В 2040 году добавилось новое требование к экологической безопасности. Сам насос при этом не перестаёт быть насосом Н1. Изменяется информация о нём.

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

Объект
    |
    +-- существует
    |
    +-- сохраняет свою идентичность
    |
    +-- имеет изменяющееся описание

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

Изменяется не объект. Изменяется знание об объекте.

11.7. Почему нельзя просто менять поля

Можно возразить: зачем усложнять модель? Почему бы просто не обновлять значения?

UPDATE Product
SET material = '09Г2С'
WHERE id = 12345;

Для текущего состояния это работает. Но через десять лет возникает вопрос: Какой материал был у насоса в момент изготовления?

Если в таблице осталось только текущее значение, система ответит:

09Г2С

Но это может быть неверно. Экземпляр №12345 был изготовлен в 2026 году, когда действовало значение Сталь 20. В 2035 году материал был изменён в результате модернизации.

Если история не сохранена, система больше не знает, что происходило с объектом. Это не просто потеря старого значения. Теряется инженерный факт.

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

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

Именно здесь появляется Revision.

Если изменение не меняет самого объекта, а меняет его описание, создаётся новая Revision этого описания.

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

Revision A не заменяется Revision B. Обе остаются в истории.

Revision B не является новым насосом. Она является новым состоянием описания того же насоса.

Это позволяет системе одновременно хранить два факта:

Объект:
    Насос Н1
    остаётся тем же

Описание:
    Revision A
    Revision B
    Revision C
    изменяется во времени

Если же изменение нарушает критерий, установленный в Главе 4, и объект перестаёт быть взаимозаменяемым с прежним, это уже не изменение описания. Это новый объект.

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

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

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

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

11.9. Два уровня модели

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

Первый уровень — объект.

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

Второй уровень — описание.

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

Уровень объекта:
    Object
        |
        +-- стабильный идентификатор

Уровень описания:
    Attribute
    Definition
        |
        +-- Revision
    Document
        |
        +-- версии
    Context
        |
        +-- условия существования

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

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

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

Но PLM работает с другим масштабом времени. Изделие может существовать десятилетиями. За это время:

• меняются конструкторы;
• меняются технологи;
• меняются поставщики;
• меняются стандарты;
• меняются требования безопасности;
• меняются производственные площадки;
• появляются новые виды документации;
• выполняются ремонты и модернизации.

При этом инженер должен иметь возможность сказать: «Это тот же объект, но его описание изменилось».

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

11.11. Разделение, которое уже существует в инженерной практике

Это не исключительно компьютерная идея.

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

ГОСТ Р 2.503-2023 устанавливает правила внесения изменений в конструкторские документы. Само наличие процедуры изменения документации показывает важное различие: изменяется документированное описание изделия, а не произвольно меняется само изделие.

Аналогичное разделение существует и в международном управлении конфигурацией. Configuration Item является управляемым объектом, а configuration information содержит информацию о нём. Изменение информации не означает автоматически замену самого объекта.

В ISO 10303-239 это различие выражено непосредственно структурой модели: product и product_definition являются разными сущностями.

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

11.12. Где здесь Anchor Modeling

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

В упрощённом виде:

Anchor
    |
    +-- Attribute
    |      value A
    |      value B
    |      value C
    |
    +-- Attribute
           value A
           value B

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

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

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

11.13. Практическое следствие для архитектуры

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

Не организационно. Не через соглашения пользователей. Не через инструкцию «не изменяйте идентификатор».

Через структуру модели.

Object
    |
    +-- Attribute
    |
    +-- Definition
    |      |
    |      +-- Revision
    |
    +-- Document
    |
    +-- Context

Object является стабильной точкой. Все остальные сущности могут развиваться вокруг него.

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

Именно поэтому объект может быть известен системе раньше, чем появится полное описание. Сначала существует сам объект. Затем различные области системы добавляют своё знание о нём.

11.14. Граница применимости

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

Граница проходит там, где появляются три условия одновременно:

• объект живёт значительно дольше, чем версия программного обеспечения;
• описание объекта изменяется на протяжении жизненного цикла;
• история изменений является частью инженерного знания.

Для PLM все три условия выполняются. Изделия живут десятилетиями. Описание меняется постоянно. История критична для трассируемости.

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

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

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

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

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

Глава 11 добавляет: объект должен сохранять стабильную идентичность, а его описание должно изменяться во времени. Модель данных должна разделять эти два аспекта архитектурно.

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

Объект существует
        ↓
Идентичность сохраняется
        ↓
Описание изменяется
        ↓
Изменение описания фиксируется через Revision
        ↓
Изменение самого объекта создаёт новый объект

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

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

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

Объект реального мира постоянен. Его описание временно.

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

Международные стандарты CM, ISO 10303-239 и отечественная система ЕСКД используют различение объекта и информации о нём. В разных моделях оно выражено по-разному, но принцип один: изменение данных об объекте не должно автоматически означать замену самого объекта. Для модели данных это означает одно: система должна разделять объект и его изменяемые данные архитектурно.

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

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

Модель данных должна уметь хранить и то и другое, не смешивая.

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

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.2.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §3.4.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §2.3.
• ISO 10303-239, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• ГОСТ Р 2.051-2023. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения.
• Rönnbäck, L. et al. Anchor Modeling: An Agile Modeling Technique Using the Sixth Normal Form. 2010.

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

Глава 12. Связь как самостоятельный объект

12.1. Болт, который входит в три узла

Представим простой крепёжный элемент. Болт М8×20. Он используется в трёх разных узлах одного изделия: в креплении двигателя, в креплении корпуса, в креплении защитной крышки.

Сам болт один. Но связей три. И каждая связь имеет собственные свойства.

В креплении двигателя болт стоит в позиции 10, в количестве четырёх штук. В креплении корпуса — в позиции 25, в количестве восьми штук. В креплении крышки — в позиции 42, в количестве двух штук.

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

Если модель данных хранит только объекты:

Болт
Двигатель
Корпус
Крышка

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

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

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

12.2. Человек мыслит отношениями

Когда инженер смотрит на автомобиль, он не видит просто перечень деталей. Он видит структуру.

Двигатель соединён с коробкой передач. Коробка передач соединена с карданным валом. Карданный вал соединён с задним мостом. Подвеска связывает кузов с колёсами. Электрооборудование связывает аккумулятор с потребителями.

Инженер постоянно задаёт вопросы, относящиеся именно к отношениям:

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

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

Значит, связь является частью инженерного знания.

12.3. Ссылка и связь — не одно и то же

В обычной реляционной модели связь часто представляется внешним ключом:

assembly
    component_id → component

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

Нужно знать:

Assembly
    |
    └── Relation
            component: Bolt M8×20
            position: 10
            quantity: 4
            role: fastening
            applicability: ...
            valid_from: ...

Внешний ключ отвечает на вопрос: с чем связан объект?

Инженерная связь отвечает на более важный вопрос: что означает эта связь?

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

12.4. Когда связь становится самостоятельным объектом

Не всякая ссылка между объектами должна становиться отдельным объектом.

Если документ имеет автора, обычно достаточно сохранить ссылку:

Document
    author_id

Автор является свойством документа. Само отношение «документ написан автором» не требует отдельной инженерной сущности. Но ситуация меняется, когда отношение обладает собственной информацией и собственной жизнью.

Критерий прост. Связь является самостоятельным объектом, если:

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

Связь «изделие содержит компонент» удовлетворяет этим критериям. Она может иметь:

• позицию;
• количество;
• условие применения.

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

Здесь возникает важное практическое правило:

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

Если позиция, количество и условия применения находятся внутри Component, они теряют связь с конкретным узлом. Если они находятся внутри Assembly, они теряют связь с конкретным компонентом. Они должны существовать там, где им принадлежит — в самой связи.

12.5. KRelation

В модели Constructum эта идея выражается через самостоятельную сущность модели — KRelation, представляющую связь между объектами.

Упрощённо:

KObject A
    |
    └── KRelation
            |
            └── KObject B

KRelation не заменяет связанные объекты. Он не является ни первым объектом, ни вторым. Он представляет сам факт и смысл их отношения.

Например:

KProduct: Насос Н1
        |
        └── KRelation
                type: contains
                target: KProduct — Уплотнение У1
                quantity: 2
                position: 15
                applicability: ...

Насос существует самостоятельно. Уплотнение существует самостоятельно.

Связь между ними также существует самостоятельно.

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

12.6. Почему связь должна иметь собственную идентичность

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

Если есть:

A → B

зачем ещё один объект?

Ответ появляется, когда связь начинает изменяться. Сегодня:

A
 └── contains → B
                quantity: 4

Завтра:

A
 └── contains → B
                quantity: 6

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

Не A.

Не B.

Изменилось отношение между A и B.

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

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

Она может появиться. Может измениться. Может быть закрыта. Может быть заменена другой связью.

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

12.7. Связь может быть объектом изменения

Рассмотрим изменение конструкции.

В исходной структуре:

Насос Н1
    └── contains → Уплотнение У1
                     quantity: 2

После изменения:

Насос Н1
    └── contains → Уплотнение У1
                     quantity: 4

Сам насос не изменился как объект. Само уплотнение не изменилось как объект.

Изменилось количество применяемых уплотнений. Это изменение отношения.

А значит, если система должна хранить историю инженерных решений, она должна уметь версионировать или темпорально хранить именно отношение. Это особенно важно для BOM (почему используется термин “BOM” смотри главу 12б).

BOM — это не просто список объектов. BOM — это структура отношений между объектами.

Именно поэтому изменение BOM не всегда означает изменение самих объектов, входящих в неё.

12.8. Связь может иметь собственный контекст

Рассмотрим тот же болт.

Он может применяться:

Узел A
    quantity = 4

Узел B
    quantity = 8

Узел C
    quantity = 2

Кроме количества могут отличаться:

• позиция;
• условия использования.

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

Она является самостоятельным носителем инженерной информации.

12.9. Связь между Definition и объектом

Тот же принцип работает не только для структуры изделия.

Описание объекта также связано с объектом отношением.

Например:

KProduct
    |
    └── KDefinition
            |
            └── Revision

Здесь важно различать сами сущности.

KProduct — объект. KDefinition — описание этого объекта. Revision — версия описания.

Это не три записи об одном и том же. Это разные сущности, существующие для разных целей. Так же и Relation не является «полем объекта». Он представляет самостоятельное отношение между объектами.

12.10. Связь между экземпляром и применённым описанием

То же различие необходимо при работе с изготовленными экземплярами.

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

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

Например:

KProduct
    └── KDefinition
            ├── Revision A
            ├── Revision B
            └── Revision C

KInstance №003
    applied_revision: Revision B

Здесь Revision не превращается в экземпляр и не становится частью объекта Product. Revision остаётся версией описания. KInstance остаётся самостоятельным объектом.

Информация о применённой версии относится к экземпляру и позволяет восстановить состояние, в котором конкретный экземпляр был изготовлен.

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

12.11. Связь как часть истории изделия

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

Если система хранит только текущую структуру:

A → B

она знает только сегодняшнее состояние.

Но инженерный вопрос относится к прошлому.

Нужно знать:

2026:
    A → B
2028:
    A → C
2030:
    A → D

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

12.12. Отношения образуют граф

Из этого возникает важное следствие.

Изделие в цифровой системе — это не таблица деталей. Это граф объектов и отношений.

             KProduct
                │
          ┌─────┴─────┐
          │           │
      KRelation    KRelation
          │           │
       Component    Component
          │
      KRelation
          │
       Document

Каждый узел графа является самостоятельным объектом. Каждое значимое отношение между узлами также является самостоятельной сущностью.

Поэтому система хранит не просто набор записей. Она хранит структуру инженерного мира.

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

Эта идея не является особенностью модели Constructum. Она имеет прямое подтверждение в международных стандартах.

ISO 10303-239 (PLCS) вводит отдельную сущность product_definition_relationship. Она предназначена для представления отношения между двумя определениями изделия и содержит собственную семантику отношения. Стандарт не сводит отношение к технической ссылке между двумя записями.

NPDM (NATO Product Data Model, STANAG 4613) также разделяет объекты и отношения между ними. Модель использует отдельное представление отношений между компонентами продукта. Для таких отношений могут существовать собственные характеристики: количество, позиция, условия применения.

ANSI/EIA-649-D требует идентифицировать не только сами configuration items, но и отношения между ними. Конфигурация определяется не только набором объектов, но и тем, как эти объекты связаны.

Отечественная система ЕСКД выражает тот же принцип через спецификацию (ГОСТ 2.106-2019) и электронную структуру изделия (ГОСТ Р 2.053-2023). Спецификация не является простым перечнем деталей. Она фиксирует состав, позиции и количество — то есть отношения между изделием и его компонентами.

Во всех случаях отношение является частью модели, а не технической ссылкой.

12.14. Граница: не всякое отношение является инженерной сущностью

Здесь важно не превратить принцип в догму.

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

Например:

KDocument
    created_by = User

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

Но:

KAssembly
    contains
        component
        position
        quantity
        applicability
        validity

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

Граница проходит по смыслу.

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

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

Это позволяет сохранить модель строгой, не превращая её в механический граф всего со всем.

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

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

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

Глава 12 добавляет: отношения между объектами могут быть самостоятельными сущностями. Модель данных должна хранить не только объекты, но и смысл их связей.

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

Что существует?
        ↓
      Object

Как объект описан?
        ↓
    Definition

Как описание изменяется?
        ↓
     Revision

Как объекты связаны?
        ↓
     Relation

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

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

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

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

Объекты сами по себе не описывают инженерный мир.

Между ними существуют отношения. И эти отношения часто содержат не меньше инженерной информации, чем сами объекты.

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

Поэтому модель данных должна уметь хранить не только объекты, но и смысл отношений между ними.

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

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

Если система хранит только объекты, она знает, что существует. Если она хранит объекты и отношения, она знает, как устроен инженерный мир.

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

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

Источники:

• 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.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.3.
• ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.
• ГОСТ 2.102-68. Единая система конструкторской документации. Виды и комплектность конструкторских документов.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• Rönnbäck, L. et al. Anchor Modeling: An Agile Modeling Technique Using the Sixth Normal Form. 2010.

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

Глава 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
                              │
                              ↓
                    представление полной структуры

а не:

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

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

ЧАСТЬ III. Как модель становится системой?

Глава 13. Почему модель данных определяет архитектуру?

13.1. Разговор, который обычно начинают не с того места

Представим начало нового проекта PLM-системы.

Архитекторы обсуждают сервисы. Кто-то предлагает Product Service. Кто-то — Document Service. Отдельно Workflow Service, User Service, Notification Service. На доске появляются десятки блоков и стрелок. Обсуждают хранилища. API. Брокер сообщений. Контейнеры.

И только потом возникает вопрос: А что именно каждый из этих сервисов должен знать об объекте? Это кажется техническим вопросом. Но на самом деле он относится к модели данных.

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

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

13.2. Один объект — много областей знания

Вернёмся к насосу Н1.

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

Конструктор знает:

KProduct
    конструктивное описание
    геометрия
    материалы
    размеры
    состав
    Revision

Технолог знает:

KProduct
    технологическое описание
    операции
    оборудование
    маршрут
    технологические требования

Производство знает:

KProduct
    производственное состояние
    производственный процесс
    фактический выпуск
    ограничения производства

Эксплуатационная служба знает:

KProduct
    эксплуатационное описание
    условия применения
    обслуживание
    ограничения

Объект один. Знание о нём — разное.

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

13.3. Что происходит, если всё положить в один сервис

Представим систему, в которой существует один Product Service.

Он хранит всё:

Product Service
    │
    └── Product
          ├── Construction
          ├── Technology
          ├── Manufacturing
          ├── Operation
          ├── Documents
          ├── Workflow
          └── ...

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

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

Каждое изменение становится изменением одного большого объекта. Система начинает отражать не разделение инженерного знания, а техническое решение хранить всё вместе.

13.4. Проблема не в сервисах

Можно попытаться решить проблему противоположным способом. Разделить систему на сервисы:

Product Service
Document Service
Workflow Service
Technology Service
Manufacturing Service

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

Product Service
    владеет Product

Technology Service
    тоже изменяет Product

Manufacturing Service
    тоже изменяет Product

Возникает вопрос: кто имеет право изменять Product?

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

Сервисы появились. Независимости не появилось.

13.5. Модель данных должна разделять ответственность

Предыдущие главы дали для этого необходимую основу.

Мы уже различаем:

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

Это не просто удобная структура хранения. Каждое описание отвечает на свой вопрос.

Конструкторское описание отвечает: как устроено изделие? Технологическое: как его изготовить? Производственное: как организовано его производство? Эксплуатационное: как его использовать и обслуживать?

Эти вопросы различны. Значит, различна и ответственность за ответы.

13.6. Объект не принадлежит сервису

Здесь возникает важный принцип.

Если несколько сервисов работают с разными описаниями одного объекта, нельзя говорить, что сам объект принадлежит одному из этих сервисов. KProduct не принадлежит Design Service. Не принадлежит Technology Service. Не принадлежит Manufacturing Service. Он является общим объектом системы. Профильные сервисы управляют своими описаниями объекта.

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

                    KObject / Product
                           │
             ┌─────────────┼─────────────┐
             │             │             │
             ▼             ▼             ▼
        Construction   Technology   Manufacturing
        Definition     Definition   Definition
             │             │             │
             ▼             ▼             ▼
        Design Service Technology   Manufacturing
                       Service      Service

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

13.7. Единый реестр объектов

Но возникает другая проблема.

Если каждый сервис хранит свои данные самостоятельно, кто гарантирует, что речь идёт об одном и том же объекте? Представим:

Design Service
    Product ID = 12345

Technology Service
    Product ID = 12345

Manufacturing Service
    Product ID = 12345

Откуда взялся 12345?

Если каждый сервис генерирует идентификаторы самостоятельно, единого объекта больше нет. Получаются три локальных объекта, которые система должна каким-то образом считать одним.

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

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

Упрощённо:

                Object Registry
                      │
                 register()
                      │
                      ▼
                KObject ID=12345
                      │
          ┌───────────┼───────────┐
          │           │           │
          ▼           ▼           ▼
       Design      Technology  Manufacturing
       Service      Service      Service
          │           │           │
          └────── ID=12345 ───────┘

Это не означает, что реестр хранит всю информацию об объекте. Он хранит фундаментальный факт существования объекта и его общий идентификатор. Профильный сервис хранит данные своей области.

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

13.8. Почему идентификатор должен быть общим

Представим изменение конструкции.

Design Service сообщает:

Product 12345
Design Revision B created

Technology Service получает событие:

Product 12345
Design changed

Он не создаёт собственный объект. Он знает: 12345 — тот же объект, который существует и в его области.

Technology Service анализирует изменение и, если необходимо, создаёт новую технологическую Revision. Manufacturing Service получает то же событие и решает, влияет ли изменение конструкции на производство. Никто не передаёт другому сервису весь объект. Передаётся ссылка на один и тот же объект и информация о произошедшем изменении.

Это делает взаимодействие между сервисами значительно слабее.

13.9. Событие вместо прямого управления

Из разделения знания следует ещё один архитектурный принцип.

Если Design Service изменил своё описание, ему не нужно напрямую изменять данные Technology Service. Он фиксирует изменение. Система публикует событие. Например:

ProductDesignChanged
    objectId: 12345
    revision: B

Technology Service получает событие и принимает собственное решение. Manufacturing Service также получает событие и принимает собственное решение.

Это важно.

Событие сообщает: что произошло. Оно не говорит: что другой сервис обязан сделать внутри себя.

Поэтому каждый сервис сохраняет автономию.

13.10. Почему это возможно только при правильной модели

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

Что именно изменилось? Конструкция? Технология? Производство? Эксплуатация?

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

KProduct
    │
    ├── DesignDefinition
    ├── TechnologyDefinition
    ├── ManufacturingDefinition
    └── OperationalDefinition

событие становится семантически точным:

DesignDefinitionChanged

или:

TechnologyDefinitionChanged

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

13.11. Что происходит с базой данных

Отсюда следует ещё один важный вывод. Единый объект не означает единую базу данных.

Напротив. Каждый сервис может хранить собственные данные:

Design Service
    └── Design DB

Technology Service
    └── Technology DB

Manufacturing Service
    └── Manufacturing DB

Но все они используют общий идентификатор объекта.

KObject ID = 12345

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

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

13.12. Что означает «один объект в нескольких базах»

Здесь легко допустить ошибку в терминологии.

Если Design Service хранит:

product_id = 12345
geometry = ...
material = ...

а Technology Service:

product_id = 12345
operations = ...
route = ...

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

             Object 12345
                  │
       ┌──────────┼──────────┐
       │          │          │
       ▼          ▼          ▼
   Design DB   Tech DB    Mfg DB
       │          │          │
   geometry    route      process
   material    operations status

Объект один. Представлений его аспектов — несколько.

13.13. Архитектура появляется из модели

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

Потому что модель уже отвечает на вопросы:

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

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

В терминах Domain-Driven Design это соответствует принципу Bounded Context: каждый ограниченный контекст имеет свою модель, свой язык и свои правила. Конструкторское и технологическое описания — разные контексты. Попытка объединить их в одну модель приводит к семантическим конфликтам.

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

13.14. Почему это важнее выбора технологий

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

И наоборот.

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

Модель данных первична. Архитектурный стиль вторичен.

13.15. Почему модель должна появиться раньше сервисов

На практике часто происходит наоборот. Команда начинает с архитектуры:

API Gateway
    ↓
Product Service
    ↓
Document Service
    ↓
Workflow Service

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

Архитектура начинает бороться сама с собой. Причина появилась намного раньше. Команда начала проектировать систему до того, как определила модель. Правильная последовательность выглядит иначе:

Реальный мир
      ↓
Модель объектов
      ↓
Модель описаний и связей
      ↓
Границы ответственности
      ↓
Архитектура сервисов
      ↓
API и события
      ↓
Хранилища
      ↓
Технологии

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

Не наоборот.

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

Эта последовательность выражается в простой формуле:

Модель
   ↓
объекты
   ↓
отношения
   ↓
границы ответственности
   ↓
архитектура

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

13.16. Граница: модель определяет границы, но не реализацию

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

Из того, что модель определяет архитектурные границы, не следует, что она определяет всю реализацию. Модель определяет:

• какие объекты существуют;
• как они связаны;
• кто за них отвечает;
• где проходят границы ответственности.

Но она не определяет:

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

Эти решения вторичны. Границы останутся теми же. Модель останется той же.

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

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

Хорошая модель данных может быть реализована на разных технологиях.

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

13.17. Почему это не просто «хорошая практика»

Может показаться, что это очевидно. Любой архитектор скажет: «Конечно, модель данных важна».

Но на практике модель данных часто определяется в последнюю очередь. Сначала выбираются технологии. Потом проектируются сервисы. Потом API. Потом таблицы. И только после этого кто-то спрашивает: А какие объекты мы вообще моделируем?

К этому моменту модель уже существует. Неявно. Она записана в таблицах. В API. В DTO. В правилах сервисов. В событиях. В ограничениях базы данных. Но она появилась не из инженерной реальности. Она появилась из технических решений. И именно поэтому изменить её потом чрезвычайно трудно. Правильная последовательность требует дисциплины.

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

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

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

Глава 11 показала, что один и тот же объект может иметь изменяющееся описание.

Глава 12 показала, что отношения между объектами также могут иметь собственный смысл.

Глава 13 делает следующий шаг.

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

Она является её продолжением.

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

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

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

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

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

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

Реальный мир
      ↓
Модель данных
      ↓
Границы ответственности
      ↓
Архитектура
      ↓
API и события
      ↓
Хранилища
      ↓
Технологии

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

Технология определяет, как построить систему. Модель данных определяет, какую систему вообще нужно строить. Архитектура системы не должна создавать модель мира заново. Она должна реализовать уже определённые моделью границы.

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

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §2.1.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §2.1.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.102-68. Единая система конструкторской документации. Виды и комплектность конструкторских документов.
• ГОСТ 2.601-2019. Единая система конструкторской документации. Эксплуатационные документы.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• ГОСТ Р 2.052-2024. Единая система конструкторской документации. Электронная модель изделия. Общие положения.
• ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.
• ГОСТ Р 2.051-2023. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения.
• Evans, E. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003. Ch. 14 (Bounded Contexts).

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

Глава 14. Где проходят границы сервисов?

14.1. Разговор, который не состоялся

Представим совещание. Архитектор представляет проект новой PLM-системы. На экране — диаграмма сервисов. Product Service. Document Service. Workflow Service. User Service. Notification Service.

Кто-то спрашивает: «Почему именно так? Почему Product Service управляет и конструкцией, и технологией, и производством?»

Архитектор отвечает: «Потому что всё это относится к продукту».

Ответ кажется логичным. Но проходит полгода. Конструктор жалуется: «Я не могу изменить материал, пока технолог не завершит анализ». Технолог жалуется: «Я не могу обновить маршрут, пока производство не подтвердит наличие оборудования». Производство жалуется: «Я не могу начать выпуск, пока конструктор не утвердит последнюю версию».

Все трое работают с одним объектом. Но каждый из них заблокирован действиями другого. Потому что сервис один. И объект один. И изменение в одной области формально затрагивает все остальные.

Совещание, которое должно было состояться, не состоялось. Никто не задал главный вопрос: где проходят границы ответственности?

14.2. Как человек разделяет инженерную работу

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

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

Каждая область имеет собственные данные, собственные правила и собственную ответственность.

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

Один объект проходит через все эти области. Но знание об объекте в каждой области различно. Следовательно, возникает принцип:

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

14.3. Почему функциональное разделение не работает

Классический подход к проектированию сервисов основан на функциях. Документ-сервис управляет документами. Workflow-сервис управляет процессами согласования. User-сервис управляет пользователями.

Для простых бизнес-систем это работает. Заказ принадлежит системе заказов. Счёт принадлежит финансовой системе. Каждый объект имеет одного владельца. В инженерной системе ситуация иная.

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

Если создать один Product Service и поместить туда всё, сервис становится владельцем всей информации об изделии.

Product Service
    |
    +-- design data
    +-- technology data
    +-- manufacturing data
    +-- service data

Теперь любое изменение проходит через один сервис. Любая область зависит от всех остальных. Сервис постепенно превращается в монолит, даже если технически он называется микросервисом.

Проблема не в размере кода. Проблема в модели ответственности.

14.4. Разделение должно проходить по знаниям

Вместо этого модель должна разделять разные описания объекта.

KProduct
    |
    +-- KDesignDefinition
    |
    +-- KTechnologyDefinition
    |
    +-- KManufacturingDefinition

Здесь изделие одно. Но его описания различны.

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

Это позволяет построить соответствующие границы сервисов:

                 KObject Registry
                       |
                  KProduct: 12345
                 /        |        \
                /         |         \
               ↓          ↓          ↓
       Design Service  Technology  Manufacturing
             |           Service       Service
             ↓             ↓             ↓
     KDesignDefinition  KTechnology   KManufacturing
                        Definition      Definition

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

Здесь важно сформулировать принцип точнее.

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

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

14.5. Почему объект не принадлежит сервису

Здесь необходимо провести важное различие.

В классической архитектуре сервис обычно является владельцем своего объекта. Product Service владеет Product. Document Service владеет Document. User Service владеет User. Для инженерной платформы этого недостаточно.

Изделие не принадлежит Design Service. Оно не принадлежит Technology Service. Оно не принадлежит Manufacturing Service. Оно существует независимо от всех этих областей.

Следовательно, нужен отдельный объектный слой — единый реестр объектов.

KObject Registry
       |
       +-- KObject: 12345
               |
               +-- Design Service
               |      KDesignDefinition
               |
               +-- Technology Service
               |      KTechnologyDefinition
               |
               +-- Manufacturing Service
                      KManufacturingDefinition

Реестр отвечает за существование объекта и его общий идентификатор. Специализированные сервисы хранят и управляют своими описаниями этого объекта. Это принципиально отличается от ситуации, когда Product Service является владельцем всей информации о продукте. Общая схема выглядит так:

Object Registry
       │
       ├── Design
       ├── Context
       ├── Relation
       └── ...

Каждый специализированный сервис представляет собственную область знания. Реестр обеспечивает общий слой объектов. Ни один сервис не владеет объектом целиком.

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

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

Но это не решает проблему.

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

Неправильно:

Product
    design_data     (таблица 1)
    technology_data (таблица 2)
    manufacturing_data (таблица 3)

Правильно:

KProduct
    |
    +-- KDesignDefinition
    |
    +-- KTechnologyDefinition
    |
    +-- KManufacturingDefinition

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

Разница фундаментальна.

14.7. Что происходит при изменении

Рассмотрим простое изменение.

Конструктор изменяет материал корпуса насоса. В модели, где всё находится внутри Product Service, система видит изменение Product.

Но что именно изменилось?

Изменилась конструкция? Технология? Производство? Эксплуатация? Ответ приходится восстанавливать из бизнес-правил.

В объектной модели изменение локализовано:

KProduct: Насос Н1
    KDesignDefinition:
        Revision A → Revision B
    KTechnologyDefinition:
        Revision A
    KManufacturingDefinition:
        Revision A

Система фиксирует: изменилось конструкторское описание. Технологическое описание не изменилось. Производственное описание не изменилось. Объект остался тем же.

Изменение имеет собственную границу и собственную ответственность.

14.8. Общий объект не означает общую ответственность

Здесь возникает важный архитектурный принцип.

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

Они используют один идентификатор объекта:

KObject: 12345

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

Design Service
    KObject 12345
        └── KDesignDefinition

Technology Service
    KObject 12345
        └── KTechnologyDefinition

Manufacturing Service
    KObject 12345
        └── KManufacturingDefinition

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

Получается разделение:

              Общий объектный слой
                      │
                 KObject 12345
                /       |       \
               /        |        \
              ↓         ↓         ↓
          Design    Technology  Manufacturing
          Service     Service      Service

Объект один. Владение знаниями разделено.

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

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

Если Design Service должен изменять Product, Technology Service должен изменять тот же Product, а Manufacturing Service должен изменять тот же Product, то независимость становится формальной.

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

Получается распределённый монолит.

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

Изменение внутри одного описания не требует изменения других описаний.

14.10. Взаимодействие между сервисами

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

Например, Design Service завершил новую ревизию конструкторского описания. Он публикует событие:

DesignDefinitionRevisionCreated
    objectId: 12345
    definitionId: 67890
    revision: B

Technology Service может решить, требуется ли ему изменить технологическое описание. Manufacturing Service может определить, затрагивает ли изменение производство.

Но решение принимает каждый сервис в своей области.

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

Событие сообщает о факте. Ответственность остаётся внутри соответствующей области.

14.11. Почему это предотвращает ошибки

Если границы сервисов следуют из модели данных, система предотвращает ошибки на архитектурном уровне.

Конструктор не может изменить технологическое описание. Не потому, что интерфейс запрещает. А потому, что Technology Service не предоставляет такого API. Конструктор управляет KDesignDefinition. Технолог управляет KTechnologyDefinition. Граница заложена в модели.

Производство не может выпустить изделие без необходимого конструкторского описания. Не потому, что интерфейс показывает красное сообщение. А потому, что Manufacturing Service требует ссылку на соответствующее KDesignDefinition. Если описания нет, необходимое состояние не может быть сформировано.

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

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

Каждый работает в своей области.

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

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

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

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

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

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

В терминах Domain-Driven Design это соответствует принципу Bounded Context: каждый ограниченный контекст имеет свою модель, свой язык и свои правила. Конструкторское и технологическое описания — разные контексты. Попытка объединить их в один сервис приводит к семантическим конфликтам и потере автономии.

Международные стандарты PLM и продуктовых данных дают дополнительные подтверждения. ISO 10303-239 разделяет продукт и различные виды его определения и контекста. NATO Product Data Model также отделяет сам продукт от информации, описывающей его в различных аспектах.

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

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

14.13. Граница: модель определяет границы, но не реализацию

Было бы неверно утверждать, что модель данных определяет всё.

Она определяет:

• какие объекты существуют;
• как они связаны;
• кто за них отвечает;
• где проходят границы ответственности.

Но она не определяет:

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

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

Границы остаются теми же. Модель остаётся той же.

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

Глава 12 установила: связи между объектами являются самостоятельными сущностями. Глава 13 установила: модель данных определяет архитектуру системы. Единый реестр обеспечивает общий объектный слой. Событийная модель обеспечивает независимость сервисов. Глава 14 добавляет: граница ответственности сервиса должна следовать из различий в знаниях, правилах и жизненном цикле данных, которые он обслуживает.

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

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

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

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

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

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

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

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

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

Object Registry
       │
       ├── Design
       ├── Context
       ├── Relation
       └── ...

Функциональное разделение — Product Service, Document Service, Workflow Service, User Service — не решает проблему PLM, если оно приводит к тому, что один сервис становится владельцем всех аспектов изделия.

Разделение по областям знания — Design Service, Technology Service, Manufacturing Service — отражает реальную структуру инженерной деятельности. Это разделение не является усложнением. Оно является отражением того, как устроено предприятие.

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

Модель данных фиксирует это разделение. Архитектура системы следует из него.

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

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §2.2.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §2.2.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §2.1.
• 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.102-68. Единая система конструкторской документации. Виды и комплектность конструкторских документов.
• ГОСТ 2.601-2019. Единая система конструкторской документации. Эксплуатационные документы.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• ГОСТ Р 2.052-2024. Единая система конструкторской документации. Электронная модель изделия. Общие положения.
• ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.
• ГОСТ Р 2.051-2023. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения.
• Evans, E. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003. Ch. 14 (Bounded Contexts).

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

Глава 15. Может ли система запрещать ошибки?

15.1. От проверки к невозможности

Обычная информационная система работает следующим образом.

Пользователь выполняет действие. Система проверяет, допустимо ли оно. Если нет — возвращает ошибку.

Пользователь создаёт изделие без описания. Система отвечает: «Ошибка: необходимо указать описание».

Пользователь создаёт Revision непосредственно для изделия. Система отвечает: «Ошибка: операция недопустима».

Пользователь создаёт связь между несовместимыми типами объектов. Система отвечает: «Ошибка: такие объекты нельзя связать».

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

Это различие между проверкой и моделью. Проверка говорит: «Так делать нельзя». Модель говорит: «Такого состояния не существует».

Для инженерной системы это принципиально разные подходы.

15.2. Почему проверки недостаточно

Представим систему, которая запрещает создать Revision без указания KDefinition.

Через пользовательский интерфейс это действительно запрещено.

Но система имеет API. Есть импорт данных. Есть интеграция с ERP. Есть миграции. Есть административные инструменты. Есть другие сервисы.

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

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

15.3. Инвариант

Для этого в модели существуют инварианты.

Инвариант — это формальное условие, которое должно сохраняться для всех допустимых состояний модели.

В контексте Constructum это означает: модель не просто описывает, какие сущности существуют. Она определяет, какие комбинации этих сущностей вообще могут существовать вместе.

Например:

KObject
    |
    +-- KContext
    |
    +-- KDefinition
            |
            +-- Revision

Эта структура означает больше, чем набор таблиц. Она означает:

• KContext относится к KObject;
• KDefinition относится к KObject;
• Revision относится к KDefinition;
• Revision не является версией KObject.

Если попытаться представить Revision без KDefinition, нарушается сама структура модели.

15.4. Инвариант первый: объект первичен

KObject существует
        ↓
всё остальное относится к нему

Но не наоборот.

KContext относится к KObject. KAttribute относится к KObject. KDefinition относится к KObject. KRelation соединяет KObject с KObject.

Следовательно, эти сущности не могут существовать независимо от объектов, к которым они относятся. Это не ограничение интерфейса. Это следствие структуры данных.

Что это предотвращает?

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

15.5. Инвариант второй: идентичность не имеет свойств

KObject
    id: 12345

Не более.

KObject не содержит имени. Не содержит владельца. Не содержит статуса. Не содержит описания. Это не бедность модели. Это её сила.

Идентичность объекта должна оставаться неизменной, пока объект остаётся тем же объектом. Имя может измениться. Владелец может измениться. Статус может измениться. Описание может измениться. Но изменение этих характеристик не должно создавать новый объект.

Что это предотвращает?

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

15.6. Инвариант третий: Revision принадлежит описанию

KProduct
    |
    +-- KDesignDefinition
            |
            +-- Revision A
            +-- Revision B

Revision не принадлежит KProduct.

Revision принадлежит KDefinition.

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

Изменение конструкторского описания.

Что это предотвращает?

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

15.7. Инвариант четвёртый: изменение объекта создаёт новый объект

KProduct A
        ↓
KProduct B

Здесь необходимо вернуться к Главе 4.

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

Revision существует внутри KDefinition. KDefinition существует внутри KProduct.

Но KProduct не имеет Revision.

Следовательно, изменение, которое означает появление нового объекта, не должно записываться как Revision. Оно должно приводить к созданию нового KProduct.

Что это предотвращает?

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

15.8. Инвариант пятый: контекст не может существовать без объекта

KObject: 12345
    |
    +-- KContext
            owner: Иванов
            project: Проект А

Но не:

KContext
    owner: Иванов
    project: Проект А
    object: ???

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

Что это предотвращает?

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

15.9. Инвариант шестой: атрибут имеет время

KAttribute
    object: 12345
    type: material
    value: 09Г2С
    valid_from: 01.06.2031
    source: конструктор Петров
    basis: извещение №45

Атрибут не является простым значением.

Он является утверждением о состоянии объекта в определённый момент времени. Поэтому атрибут имеет:

• объект;
• значение;
• время действия;
• источник.

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

Что это предотвращает?

Ситуацию, в которой система хранит только последнее значение:

material = 09Г2С

и через десять лет невозможно определить:

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

Модель сохраняет не только значение. Она сохраняет утверждение вместе с его происхождением.

15.10. Инвариант седьмой: связь имеет смысл

KRelation
    from: KObject 12345
    to: KObject 67890
    type: contains
    position: 10
    quantity: 4

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

KProduct ──contains──> KProduct
KDocument ──describes──> KDefinition

Но:

KDocument ──contains──> KProduct

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

Что это предотвращает?

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

15.11. Инвариант восьмой: исполнение является объектом

KPExecutionGroup
    |
    +-- KProduct (исполнение 1)
    +-- KProduct (исполнение 2)
    +-- KProduct (исполнение 3)

Исполнение является KProduct.

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

KProduct.

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

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

Что это предотвращает?

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

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

конфигурация 047

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

15.12. Почему инварианты сильнее правил

Традиционная система проверяет правильность действий пользователя.

Пользователь нажимает кнопку. Система проверяет: допустимо ли действие? Если нет — показывает ошибку. Но такая проверка является внешней. Её можно обойти:

• вызвать API напрямую;
• импортировать данные;
• использовать другой клиент;
• выполнить миграцию;
• обратиться к другому сервису.

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

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

Правило говорит: «Не делай этого».

Инвариант говорит: «Это состояние невозможно».

15.13. Аналогия со строгой типизацией

В программировании есть похожий принцип.

Без строгой типизации:

x = "hello" + 42

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

Со строгой типизацией:

x: Integer = "hello" + 42

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

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

15.14. Валидация и инвариант — не одно и то же

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

Валидация отвечает на вопрос: «Корректны ли данные?»

Инвариант отвечает на вопрос: «Может ли такое состояние существовать в модели?»

Например, значение:

diameter = 150 mm

может быть структурно корректным. Но оно может быть инженерно неправильным. Модель не знает, должен ли конкретный насос иметь диаметр 150 или 160 мм, если это не выражено отдельным правилом предметной области.

Поэтому модель не может предотвратить все ошибки.

15.15. Что модель может запретить, а что нет

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

Не всякая ошибка может быть предотвращена моделью. Модель может запрещать структурно невозможные состояния. Она не может определить, правильно ли инженер выбрал материал или верно ли выполнил расчёт.

Модель может запретить:

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

Модель не может сама по себе запретить:

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

Первые ошибки нарушают структуру предметной области. Вторые нарушают инженерный смысл конкретных данных.

Для вторых существуют другие механизмы:

• экспертиза;
• согласование;
• верификация;
• расчёт;
• испытания;
• аудит.

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

15.16. Практический пример

Рассмотрим конкретную ситуацию.

Конструктор изменил диаметр выходного патрубка насоса. Взаимозаменяемость нарушена. По инженерному смыслу это уже новый объект.

В традиционной модели: Пользователь создаёт Revision C для Part «Насос Н1». Система позволяет. Запись существует. Формально всё корректно. Но по смыслу это ошибка: под одним обозначением оказались два разных объекта.

Через пять лет эксплуатационная служба спрашивает: «Можно ли заменить насос Revision A на Revision C?» Система не может дать однозначный ответ. Потому что модель не различает изменение описания и изменение самого объекта.

В модели с разделением: Пользователь пытается создать Revision C. Инженер определяет, что изменение затрагивает присоединительные размеры и нарушает взаимозаменяемость. Следовательно, это не новая Revision того же объекта. Создаётся новый KProduct:

KProduct: Насос Н1
        |
        +-- KDesignDefinition
                +-- Revision A
                +-- Revision B

KProduct: Насос Н2
        |
        +-- KDesignDefinition
                +-- Revision A

Между объектами может быть зафиксирована связь преемственности. Через пять лет система уже может ответить: «Насос Н2 — другой объект. Он не является взаимозаменяемой Revision насоса Н1».

Модель содержит различие.

15.17. Что это даёт через десять лет

PLM-система живёт десятилетиями.

Люди, которые создавали записи, уходят. Остаются данные.

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

Revision B означает изменение определённого описания. KProduct B означает другой объект. KContext означает условия существования. KAttribute означает утверждение о свойстве. KRelation означает типизированную связь. Каждое понятие имеет собственный смысл.

Это не удобство. Это требование долговечности.

15.18. Как инварианты связаны с архитектурой

Глава 13 ответила, почему модель становится архитектурой. Глава 14 показала, как из этого следуют границы сервисов. Глава 15 добавляет третий уровень — какие состояния допустимы внутри этих границ.

Инвариант:

Revision принадлежит Definition.

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

Инвариант:

KContext не существует без KObject.

означает, что Context Service работает с контекстом конкретного зарегистрированного объекта.

Инвариант:

KRelation имеет определённый тип и допустимых участников.

означает, что Relation Service отвечает за правила создания соответствующих связей.

Граница заложена в модели. Каждый сервис реализует свою часть модели. А совокупность инвариантов обеспечивает целостность системы.

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

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

Вместе эти главы формируют следующую последовательность. Модель определяет объекты. Объекты определяют области ответственности. Области ответственности определяют границы сервисов.

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

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

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

Не всех ошибок.

Содержательные ошибки — неверный размер, неправильный материал, ошибочный расчёт — остаются ответственностью инженера.

Но онтологические ошибки — создание несуществующего объекта, смешение объекта и его описания, подмена нового изделия новой Revision, создание исполнения как набора параметров — могут быть предотвращены структурой модели.

Это не ограничение свободы. Это отражение инженерной реальности. Модель не должна спрашивать пользователя каждый раз: «Ты уверен, что хочешь сделать это?»

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

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

В следующей главе: почему современные PLM-системы начали смешивать управление конфигурацией и управление вариантами, и к каким последствиям это приводит.

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

Источники:

• ISO 10007:2017, Quality management — Guidelines for configuration management.
• ГОСТ Р ИСО 10007-2019. Менеджмент качества. Руководящие указания по менеджменту конфигурации.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.052-2024. Единая система конструкторской документации. Электронная модель изделия. Общие положения.
• ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• ГОСТ 2.113-75. Единая система конструкторской документации. Групповые и базовые конструкторские документы.

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

Глава 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.

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

Глава 16а. Что такое Configuration Management и чем оно отличается от управления вариантами

16а.1. Один термин — две разные практики

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

Им называют состояние изделия, набор документов, структуру изделия, комбинацию опций, вариант продукта. Из-за этого легко возникает впечатление, что все эти понятия относятся к одной задаче.

Но стандарты Configuration Management используют термин значительно точнее.

Configuration Management — это не механизм выбора комплектации изделия.

Это дисциплина управления конфигурацией изделия и информацией, которая её описывает.

16а.2. Что говорит ISO 10007

ISO 10007:2017 Quality management — Guidelines for configuration management определяет Configuration Management через пять процессов:

• configuration management planning;
• configuration identification;
• configuration change management;
• configuration status accounting;
• configuration audit.

Иными словами, Configuration Management отвечает за систематическое управление конфигурацией на протяжении жизненного цикла.

В этом определении нет задачи выбора вариантов продукта. Нет Options. Нет Variant Management. Нет Feature Models. Нет 150% BOM.

Это не означает, что стандарты запрещают использовать такие механизмы. Они означают другое: управление вариантами не является определением Configuration Management.

16а.3. Что такое конфигурация

Здесь особенно важно не подменять стандартизированный термин другим значением.

ISO 10007 определяет Configuration как:

The interrelated functional and physical characteristics of a product as described in configuration information.

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

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

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

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

Управление вариантами работает с пространством допустимых разновидностей и комбинаций. Configuration Management управляет конфигурацией изделия в нормативном смысле — её составом, характеристиками, состоянием и изменениями.

Поэтому в дальнейшем необходимо строго различать:

Configuration
    ↓
характеристики изделия
    ↓
описание состояния изделия

и

Variant
    ↓
возможный вариант изделия
    ↓
выбор комбинации параметров

Это связанные понятия, но не одно и то же.

16а.4. Что делает Configuration Management

Рассмотрим изделие, которое уже существует как предмет инженерного учёта.

Для него существует определённое описание. Это описание изменяется. Появляется новая ревизия.

Изменение проходит установленную процедуру. Новая версия становится действующей. Система должна знать:

• какая информация относится к изделию;
• какая версия является действующей;
• какие изменения были выполнены;
• когда они вступили в силу;
• кто их утвердил;
• какое состояние было зафиксировано на определённый момент времени.

Именно эти задачи лежат в области Configuration Management.

Упрощённо:

Изделие
   ↓
Информация о конфигурации
   ↓
Идентификация
   ↓
Изменения
   ↓
Учёт состояния
   ↓
Аудит

Цель — сохранить управляемое и проверяемое состояние инженерной информации.

16а.5. Что делает управление вариантами

Теперь рассмотрим другую задачу.

Производитель выпускает семейство насосов. Допустимы:

Материал:
    чугун
    сталь
    нержавеющая сталь

Уплотнение:
    сальниковое
    торцевое

Присоединение:
    DN50
    DN80
    DN100

Но не все комбинации допустимы.

Нужно определить:

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

Это уже другая задача. Она относится к управлению вариативностью изделия.

В литературе и промышленной практике для неё используются понятия:

• Product Variant Management;
• Product Family Engineering;
• Feature Modeling;
• Product Line Engineering;
• Generic BOM;
• 150% BOM.

Здесь система работает не только с тем, что существует, но и с пространством того, что может быть произведено или сформировано.

16а.6. Два пространства

Разницу можно представить очень просто.

Configuration Management работает с состояниями управляемого изделия:

существующее изделие
       ↓
состояние
       ↓
изменение
       ↓
новое состояние

Управление вариантами работает с пространством возможных решений:

семейство изделия
       ↓
варианты
       ↓
ограничения
       ↓
допустимые комбинации

Они могут использовать общие данные. Но предмет управления различается.

16а.7. Почему эта граница особенно важна для инженерных изделий

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

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

Здесь важно понять, почему это работает.

Во-первых, выбранный вариант фиксируется автоматизированно по заранее определённым правилам. Покупатель не создаёт новую конструкцию. Он выбирает из пространства допустимых комбинаций. Система проверяет совместимость. Формирует заказ. Передаёт в производство. Для производственного процесса переход от выбора к изготовлению происходит бесшовно. Не требуется отдельного инженерного решения о том, существует ли данная комбинация как изделие. Правила уже определены. Комбинация допустима. Производство знает, что делать.

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

Это принципиальное наблюдение.

Менеджер вариантов не создаёт вариативность. Он управляет ею. Если вариативность не заложена в конструкцию, инструмент управления вариантами становится бесполезным.

Но в инженерной продукции ситуация иная. Предположим, комбинация параметров требует:

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

Тогда возникает вопрос: это просто возможный вариант или уже самостоятельное изделие?

Configuration Management не отвечает на этот вопрос.

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

Но инженерное решение о существовании самостоятельного изделия находится на другом уровне.

16а.8. Почему они встречаются в одной PLM

Современная PLM-платформа должна решать обе задачи.

Поэтому в одной системе могут одновременно существовать:

• Configuration Management;
• Change Management;
• Effectivity;
• Option Management;
• Variant Management;
• BOM Management.

Это нормально.

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

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

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

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

16а.9. Почему терминологическая точность здесь принципиальна

Слово configuration уже имеет нормативное содержание.

Поэтому книга не должна переопределять его под нужды конкретной программной реализации.

Если конфигуратор формирует комбинацию параметров, корректнее назвать её вариантом или результатом конфигурирования.

Если система управляет установленным состоянием изделия и информацией о нём, это Configuration Management.

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

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

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

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

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

Теперь можно сформулировать следующий вопрос: Как получилось, что Configuration Management и управление вариантами оказались тесно связаны в современных PLM-платформах?

Это уже не нормативный вопрос. Это вопрос истории и архитектурной эволюции.

16а.11. Главный вывод

Configuration Management и управление вариантами решают разные задачи.

Configuration Management управляет конфигурацией изделия, информацией о её состоянии, изменениями, учётом и аудитом.

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

Они могут использовать одну платформу и общие данные. Но объединение инструментов не превращает две задачи в одну.

Особенно важно сохранять значение термина configuration, установленное стандартами.

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

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

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

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

Источники:

• ISO 10007:2017, Quality management — Guidelines for configuration management. §3.1.
• ГОСТ Р ИСО 10007-2019. Менеджмент качества. Руководящие указания по менеджменту конфигурации.
• CMII Institute, CMII Standard for Configuration Management, Release 3.0. §1.1, §2.1.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.113-75. Единая система конструкторской документации. Групповые и базовые конструкторские документы.

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

Глава 16б. Как PLM эволюционировал от управления состоянием к управлению вариантами

16б.1. От одной задачи к нескольким

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

Configuration Management управляет конфигурацией изделия и информацией о её состоянии.

Управление вариантами решает другую задачу — работает с возможными разновидностями изделия.

Но современные PLM-платформы обычно должны решать обе задачи. Это не случайность.

PLM развивались не как чистая реализация одного стандарта. Они постепенно включали всё больше инженерных процессов.

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

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

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

16б.2. Эволюция существующей модели

Исторически Configuration Management сформировалось как дисциплина управления инженерной информацией, изменениями и состояниями.

Системы управления инженерными данными затем стали электронными системами управления документами. Следующим шагом стало управление структурой изделия.

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

Параллельно развивались Product Family Engineering, Product Line Engineering и управление вариативностью.

Эти направления решали новую задачу:

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

• features;
• options;
• variants;
• variability;
• feature constraints;
• generic BOM;
• 150% BOM.

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

Configuration Management
         │
         ├── идентификация
         ├── изменения
         ├── состояния
         └── аудит
                  │
                  │
                  ▼
         общая PLM-платформа
                  ▲
                  │
         ┌────────┴────────┐
         │                 │
  Variant Management   Product Line Engineering
         │
         ├── options
         ├── variants
         ├── features
         ├── constraints
         └── variability

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

16б.3. Когда новая задача использует старые сущности

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

Добавить:

• варианты;
• опции;
• правила;
• effectivity;
• дополнительные связи;
• дополнительные типы BOM.

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

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

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

16б.4. Почему это не обязательно ошибка

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

Нельзя сказать: «PLM сделали неправильно».

Коммерческая система должна решать реальные задачи предприятия.

Если пользователю необходимо управлять тысячами вариантов автомобиля, ему действительно нужны options, variants, effectivity и правила выбора.

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

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

16б.5. От управления состоянием к пространству возможностей

Именно здесь возникает семантический сдвиг.

В Configuration Management система отвечает: Что является текущим управляемым состоянием изделия?

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

Первый вопрос направлен на существующее состояние. Второй — на пространство возможностей.

Условно:

CM:
A → B → C

Это последовательность состояний информации. А управление вариантами выглядит иначе:

           ┌── Variant A
           │
Family ────┼── Variant B
           │
           ├── Variant C
           │
           └── Variant D

Это пространство возможных решений.

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

• существующим;
• возможным;
• выбранным;
• утверждённым;
• произведённым;
• описанным.

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

16б.6. Что показывает литература

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

В исследованиях Product Line Engineering появляется необходимость строить инфраструктуру управления эволюцией поверх Configuration Management.

Например, работа Anastasopoulos и соавторов Increasing efficiency and effectiveness of software product line evolution — an infrastructure on top of configuration management прямо рассматривает инфраструктуру Product Line Engineering как слой, работающий поверх Configuration Management.

Это важная деталь.

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

Другие работы по software product lines и feature models рассматривают отдельные модели вариативности.

Современные инженерные исследования также рассматривают интеграцию Configuration Management с Feature Models.

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

16б.7. Что делают коммерческие PLM

Вендоры PLM действительно объединяют соответствующие механизмы в одной платформе.

Например, Teamcenter предоставляет возможности управления конфигурацией BOM вместе с вариативностью, опциями, вариантами и effectivity.

Windchill также объединяет управление конфигурациями, options и variants.

Это не означает, что сами вендоры утверждают: Configuration Management = Variant Management.

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

Это важное различие.

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

16б.8. Где появляется проблема модели

Проблема возникает тогда, когда объединяется не только инфраструктура, но и смысл сущностей. Например:

одно понятие
     │
     ├── состояние изделия
     ├── вариант изделия
     ├── выбранная конфигурация
     └── производственное представление

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

На раннем этапе это удобно. На длинной дистанции возникает стоимость. Через несколько лет система должна ответить:

Это описание изменилось?

Или:

Появился новый вариант?

Или:

Был выбран другой вариант существующего семейства?

Или:

Было изготовлено другое исполнение?

Или:

Был создан новый объект?

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

16б.9. Эволюция без пересмотра основания

Именно здесь находится основной тезис этой главы.

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

существующая модель
        ↓
новая задача
        ↓
новое поле
        ↓
новая связь
        ↓
новый тип
        ↓
новое правило
        ↓
новая интерпретация

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

Это не чья-то ошибка. Это естественное свойство эволюции больших программных систем.

16б.10. Историческая реконструкция

Здесь необходимо сделать важную оговорку.

Последовательность, представленная в этой главе, является авторской исторической реконструкцией.

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

Configuration Management
        ↓
Product Data Management
        ↓
PLM
        ↓
Variant Management
        ↓
Product Line Engineering

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

Это аналитическая модель книги.

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

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

16б.11. Почему это важно для модели данных

Если новые задачи просто добавляются поверх старой модели, возникает соблазн считать:

Part
Revision
Configuration
Variant
Instance

разновидностями одной и той же сущности. Но это разные вопросы.

Revision отвечает на вопрос: Какая версия описания действует?

Variant: Какой возможный вариант выбран или допустим?

Instance: Какой конкретный изготовленный экземпляр существует?

Object: Что является самостоятельной сущностью инженерного учёта?

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

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

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

Глава 16 установила: различие между PLM находится не только в функциях, но в исходном вопросе и первичных сущностях.

Глава 16а установила: Configuration Management и управление вариантами являются разными задачами, несмотря на то что могут использовать одну платформу.

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

Теперь возникает следующий вопрос.

Если CAD, конфигуратор, ERP, копирование и генеративные инструменты производят данные, варианты и описания, в какой момент результат их работы становится самостоятельным объектом?

16б.13. Главный вывод

Современные PLM не являются неправильными.

Они являются результатом длительной эволюции, в которой к существующим механизмам управления инженерными данными добавлялись новые задачи: структуры, варианты, опции, effectivity, product lines и другие.

Во многих случаях это было разумным инженерным решением. Но эволюция имеет цену.

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

Именно поэтому сегодня в одной PLM-платформе рядом находятся Configuration Management и Variant Management.

Это не означает, что они являются одной дисциплиной.

Это означает, что система должна одновременно управлять тем, что существует, и тем, что возможно.

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

Следующая глава задаёт более фундаментальный вопрос:

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

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

Источники:

• ISO 10007:2017, Quality management — Guidelines for configuration management. §3.1.
• ГОСТ Р ИСО 10007-2019. Менеджмент качества. Руководящие указания по менеджменту конфигурации.
• Fowler, A. «Models and applications of configuration management». Omega, Vol. 21, No. 4, 1993, pp. 425–431. DOI: 10.1016/0305-0483(93)90075-V.
• Laqua, R. «Concepts for a product line knowledge base & variability». Proceedings of NetObjectDays 2002, Erfurt, October 2002. Fraunhofer IESE.
• Laqua, R., Knauber, P. «Configuration Management for Software Product Lines». 1st Deutscher Software-Produktlinien Workshop, Kaiserslautern, 2000, pp. 49–53.
• Anastasopoulos, M. et al. «Increasing efficiency and effectiveness of software product line evolution — an infrastructure on top of configuration management». Proceedings of the 13th International Software Product Line Conference (SPLC), ACM, 2009.
• Lameh, J., Dubray, A., Jankovic, M. «Towards a Configuration Management Integration to Feature Models in Model-Based Product Line Engineering». Proceedings of the Design Society, Vol. 3, 2023, pp. 3581–3590. DOI: 10.1017/pds.2023.359.
• PTC. Product Configuration Management. Documentation.
• Siemens Digital Industries Software. Teamcenter BOM Configuration Management. Documentation.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001.

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

Авторская оговорка.

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

Глава 16в. Как инженерный объект появляется в системе

16в.1. Вопрос, который книга ещё не задавала

На протяжении предыдущих глав книга отвечала на один вопрос: что является объектом?

Мы установили, что объект существует до описания. Что описание изменяется, а объект остаётся. Что исполнение является самостоятельным изделием. Что экземпляр отличается от типа. Что документ описывает объект, но не создаёт его.

Но есть другой вопрос. Как инженерный объект появляется в системе?

Не «что является объектом».

А:

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

В модели Constructum появление нового объекта означает появление нового KObject. Поэтому вопрос становится совершенно практическим:

Когда система имеет право создать новый KObject?

Ответ на этот вопрос определяет архитектуру всей платформы.

16в.2. Ни один инструмент не создаёт объект

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

CAD-модель. Конструктор завершил проектирование и передал геометрию в PLM.

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

Импорт из ERP. Внешняя система передала запись о номенклатурной позиции.

Копирование. Инженер скопировал существующее изделие как основу для нового.

Генеративный алгоритм. Система предложила вариант конструкции на основе заданных ограничений.

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

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

CAD создаёт геометрию. Конфигуратор создаёт результат конфигурирования. ERP передаёт данные. Копирование создаёт набор новых данных. Генеративный алгоритм создаёт вычислительный результат.

Но решение о том, что перед нами самостоятельный объект учёта, является отдельным инженерным решением.

16в.3. Карта не создаёт территорию

Здесь уместна простая аналогия.

Карта не создаёт территорию.

Чертёж не создаёт изделие.

CAD не создаёт объект.

Конфигуратор не создаёт объект.

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

Поэтому:

Инструмент
    ↓
Результат работы
    ↓
Инженерная идентификация
    ↓
KObject

Именно средний шаг является принципиальным.

16в.4. Идентичность не вычисляется. Она присваивается

Конфигуратор может вычислить комбинацию параметров. CAD может вычислить массу. Генеративный алгоритм может вычислить оптимальную форму. ERP может вычислить себестоимость.

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

Инженер может сказать:

«Да. Это становится самостоятельным изделием».

А может сказать:

«Нет. Это только один из вариантов существующего изделия».

Или:

«Это изменение существующего описания».

Или:

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

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

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

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

Результат работы инструмента
        ↓
Инженерная идентификация
        ↓
KObject

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

16в.6. KObject не может быть создан автоматически

Из этого следует важное архитектурное требование.

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

CAD не создаёт KObject. Конфигуратор не создаёт KObject. ERP не создаёт KObject. Копирование не создаёт KObject. Генеративный алгоритм не создаёт KObject.

Они могут инициировать процесс идентификации. Но создание KObject является результатом принятого решения.

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

Иначе появление объекта становится техническим побочным эффектом. Например:

пользователь изменил параметр
        ↓
конфигуратор сохранил результат
        ↓
система автоматически создала объект

В этом случае техническое действие инструмента незаметно становится актом инженерного учёта.

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

16в.7. Объект не создаётся. Объект выделяется

Инженер не создаёт физический объект нажатием кнопки.

Насос не появляется из конфигуратора. Самолёт не возникает из CAD-модели.

Происходит другое.

Инженер принимает решение: считать некоторую инженерную сущность самостоятельным объектом учёта.

Это выделение.

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

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

После идентификации она становится объектом инженерного учёта.

16в.8. Что говорит Configuration Management

Здесь появляется важная связь с предыдущими главами.

ISO 10007 определяет configuration identification как процесс определения и выбора конфигурационных единиц и присвоения им уникальных идентификаторов.

Это хорошо согласуется с моделью книги.

Идентификация — не вычисление. Не импорт. Не генерация.

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

Поэтому Configuration Management начинается не с того, что CAD что-то нарисовал. Он начинается тогда, когда инженерная единица определена и идентифицирована.

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

Но инструмент и акт идентификации — разные вещи.

16в.9. Что говорит ГОСТ 2.113

Отечественная инженерная практика особенно хорошо показывает эту границу на примере исполнений.

ГОСТ 2.113-75 рассматривает группу исполнений как изделия, для каждого из которых должна быть обеспечена возможность самостоятельного применения, изготовления и учёта.

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

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

16в.10. Практический пример

Рассмотрим производителя промышленных насосов. Конфигуратор получает:

Материал корпуса:
    чугун
    сталь
    нержавеющая сталь

Тип уплотнения:
    сальниковое
    торцевое

Присоединение:
    DN50
    DN80
    DN100

Система проверяет правила совместимости. Получает:

Сталь + торцевое + DN80
    допустимо

Чугун + сальниковое + DN50
    допустимо

Нержавеющая сталь + торцевое + DN100
    допустимо

Чугун + торцевое + DN80
    недопустимо

Конфигуратор выполнил свою работу. Но ни одного нового KObject ещё не появилось.

Система только определила допустимые результаты.

16в.11. Инженерная идентификация

Инженер рассматривает один из результатов:

Сталь + торцевое + DN80.

Теперь возникает инженерный вопрос: Это самостоятельное изделие или только допустимый вариант существующего изделия?

Инженер проверяет:

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

Если решение: «Это самостоятельное изделие», происходит идентификация.

Система создаёт:

KObject: 12345
KProduct:
    Насос Н1-Ст-Т-DN80

Обозначение:
    присвоено

Семейство:
    Насосы серии Н

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

• Definition;
• Revision;
• документы;
• требования;
• связи;
• контекст;
• дальнейшие изменения.

Но всё это появляется после того, как объект был выделен.

16в.12. А если это не новый объект?

Это принципиально важная часть процесса.

Допустим, инженер рассматривает другой результат конфигуратора:

Сталь + торцевое + DN100

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

Тогда нет основания создавать новый KObject. Результат остаётся вариантом или допустимой комбинацией параметров существующего изделия.

То есть один и тот же инструмент может породить результаты двух разных типов:

результат инструмента
        │
        ├── новый объект
        │      ↓
        │    KObject
        │
        └── вариант существующего объекта
               ↓
          объект не создаётся

Именно инженерная идентификация определяет, по какой ветви пойдёт результат.

16в.13. Универсальность закона

Во всех случаях схема одна:

Источник
    ↓
Результат работы
    ↓
Инженерная идентификация
    ↓
KObject

Различается только результат. Но решение одно и то же: является ли результат самостоятельным объектом инженерного учёта?

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

16в.14. Граница для массовых изделий

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

Например, производитель автомобиля заранее определил правила:

определённая комбинация
        ↓
определённый тип исполнения
        ↓
определённое обозначение

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

Но важно различать два события.

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

Это позволяет автоматизировать процесс, не смешивая вычисление с идентификацией.

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

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

Глава 7 установила: вариант и существующее изделие — разные понятия.

Глава 16а установила: Configuration Management нельзя смешивать с управлением вариантами.

Глава 16в делает следующий шаг:

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

Для появления нового объекта требуется инженерная идентификация.

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

Любой инженерный инструмент отвечает прежде всего на вопрос: Что получилось?

CAD отвечает: получилась геометрия.

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

ERP отвечает: получилась номенклатурная запись.

Генеративный алгоритм отвечает: получилась конструкция, удовлетворяющая заданным ограничениям.

В модели Constructum именно инженерная идентификация отвечает на вопрос: Что теперь существует как самостоятельная единица инженерного учёта?

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

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

После неё появляется самостоятельный объект.

Именно поэтому KObject не должен появляться как побочный эффект работы инструмента.

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

Система фиксирует это решение. Так появляется новый объект инженерного учёта.

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

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

Источники:

• ISO 10007:2017, Quality management — Guidelines for configuration management. §3.2, Configuration identification.
• ГОСТ Р ИСО 10007-2019. Менеджмент качества. Руководящие указания по менеджменту конфигурации.
• ГОСТ 2.113-75. Единая система конструкторской документации. Групповые и базовые конструкторские документы. П. 1.3.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• 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.

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

Глава 17. Что происходит, когда модель не соответствует практике?

17.1. Система, которую никто не использует

Представим предприятие. Три года назад внедрена PLM-система. Бюджет освоен. Серверы работают. Лицензии куплены. Обучение проведено. Формально проект завершён успешно.

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

PLM-система существует. Но не используется. Или используется формально: для хранения финальных версий документов, которые уже согласованы другими средствами.

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

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

Технологии не подвели. Сервисы работают. Интерфейс функционирует. Проблема находится глубже.

Модель данных не соответствует тому, как инженеры мыслят и работают.

И пользователи сделали единственное, что могли: обошли систему.

17.2. Почему пользователи обходят систему

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

реальная практика
       ↓
модель не может её выразить
       ↓
появляется обход

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

Первый: приспособиться.

Начать мыслить терминами системы. Забыть, как работает инженерная практика, и принять логику модели данных.

Иногда это возможно. Особенно если система решает простую задачу и требует от пользователя только освоить новую терминологию.

Но в инженерной системе проблема глубже. Пользователь не может изменить реальную практику только потому, что так устроена информационная система.

Второй: обходить.

Использовать систему формально, а реальную работу вести другими средствами.

Конструктор хранит актуальную таблицу изменений в Excel. Технолог ведёт рабочую версию маршрута в своей базе. Производство использует локальный учёт. А в PLM данные попадают только после того, как работа уже выполнена.

Третий: сопротивляться.

Требовать доработок. Создавать новые поля. Добавлять специальные статусы. Писать исключения. Участвовать в бесконечных совещаниях о том, как заставить систему поддерживать ещё один частный случай.

В результате модель постепенно усложняется. Но её исходная проблема остаётся.

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

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

17.3. Как возникает обход

Рассмотрим простой пример.

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

• само изделие;
• его конструктивное описание;
• изменения этого описания;
• изготовленные экземпляры;
• документы, которыми оформлено описание;
• применённую к конкретному экземпляру ревизию.

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

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

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

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

Каждое такое решение сначала кажется небольшим техническим компромиссом. Но компромиссы накапливаются.

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

Система начинает хранить не саму инженерную практику, а способы обхода собственных ограничений.

17.4. Модель становится частью проблемы

На этом этапе возникает опасная иллюзия.

Предприятие видит, что пользователи обходят систему, и делает вывод: система недостаточно функциональна. Покупается новый модуль. Добавляются новые поля. Появляются дополнительные workflow. Расширяется API. Меняется интерфейс. Иногда меняется вся технологическая платформа.

Но если исходная модель осталась прежней, проблема остаётся.

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

17.5. Неправильная последовательность

Предприятие решает построить новую PLM-платформу.

Архитектор выбирает технологии. Команда начинает разработку. Через полгода сервисы работают. API опубликованы. Интерфейс функционирует.

Через год пользователи начинают обходить систему. Через два года предприятие решает «переписать систему». Выбирает новые технологии. Через три года новая система работает.

Но модель данных та же. Проблемы те же. Пользователи снова обходят систему.

Технологии изменились. Модель — нет. И проблема не решена.

17.6. Правильная последовательность

Правильная последовательность начинается с другого вопроса.

Не: «Какую систему мы будем строить?»

И даже не: «Какие функции должна иметь система?»

Сначала необходимо определить: «Что существует в инженерном мире и что система должна уметь представить?»

Архитектор определяет модель данных. Какие объекты существуют? Как они связаны? Какие изменения относятся к объекту, а какие — к его описанию? Что является самостоятельным объектом? Что является документом? Что является экземпляром? Какие правила должны быть невозможны для нарушения?

Затем команда проверяет модель на реальных сценариях. Конструктор создаёт изделие. Изменяет его описание. Выпускает новую Revision.

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

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

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

Через пять лет предприятие решает обновить технологии. Меняет базу данных. Меняет язык программирования. Меняет протокол.

Модель остаётся. Данные сохраняют смысл.

Переход проходит без изменения самих инженерных понятий.

17.7. Граница: не всякое неудобство является признаком ошибки

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

Система не позволяет создать Revision для объекта. Это неудобно. Но это правильно. Revision принадлежит описанию.

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

Различие проходит по простой линии: ограничение отражает инженерную реальность или отражает техническую невозможность системы?

Если ограничение отражает реальность, оно является правильным. Пользователь может быть недоволен. Но ограничение защищает от ошибки.

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

Поэтому задача хорошей модели не в том, чтобы разрешать пользователю всё. Её задача — разрешать то, что соответствует реальному миру, и запрещать то, чего в этом мире быть не должно.

17.8. Что происходит, когда модель правильная

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

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

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

Изменения проходят как изменения соответствующих описаний и управляются установленным процессом.

Каждый работает в своей области. Система помогает. Не мешает.

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

Хорошая информационная система не заставляет человека подстраивать реальность под структуру базы данных. Она позволяет выразить реальность в данных.

17.9. Почему обучение не решает проблему

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

Проводят дополнительные курсы. Пишут инструкции. Назначают ответственных. Устанавливают контроль заполнения. Вводят KPI по использованию системы.

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

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

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

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

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

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

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

Глава 15 установила: модель может предотвращать онтологические ошибки.

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

Глава 17 добавляет: если модель не соответствует инженерной практике, пользователи обходят систему. Обучение и интерфейс не устраняют причину. Необходима модель, позволяющая выразить реальную практику.

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

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

Затем определить, какие изменения относятся к описанию, какие — к самому объекту, а какие создают новый объект.

Затем определить границы ответственности и архитектуры.

И только после этого оценивать, насколько хорошо система поддерживает работу людей.

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

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

Это не вина пользователей. Это не обязательно проблема интерфейса. И это не обязательно недостаток функциональности.

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

Конструктор видит изделие. Система видит запись. Инженер видит изменение конструкции. Система видит изменение нескольких полей.

Производство видит конкретный экземпляр. Система видит ещё одну строку в таблице изделий.

И тогда пользователь начинает строить вокруг системы собственную модель реальности. Система формально продолжает работать. Но постепенно она перестаёт быть источником истины.

Поэтому главный критерий хорошей модели данных — не количество поддерживаемых функций и не сложность архитектуры.

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

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

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

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

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

Источники:

• CMII Institute, CMII Standard for Configuration Management, Release 3.0. §1.1, §2.1–2.4.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.3, §4.2.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §5.1, §5.3.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §2.1, §4.1.
• ГОСТ Р 2.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.114-2016. Единая система конструкторской документации. Технические условия.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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

Глава 18. От модели данных к инженерной платформе

18.1. Здание, которое стоит на песке

Представим архитектора, который проектирует здание. Он выбирает фасад. Выбирает материалы отделки. Выбирает цвет стен. Выбирает форму окон. Всё красиво. Всё современно. Всё соответствует последним тенденциям.

Но фундамент не заложен. Или заложен неправильно. Грунт не исследован. Нагрузка не рассчитана. Несущие конструкции не определены.

Через пять лет здание начинает трескаться. Через десять — требует капитального ремонта. Через двадцать — сносится.

Не потому, что фасад был плох. А потому, что фундамент был слаб.

Информационная система устроена так же.

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

Модель данных — это фундамент.

Если фундамент неправилен, никакая технология не исправит модель. Можно заменить базу данных. Переписать сервисы. Изменить интерфейс. Перейти на другой язык программирования. Но если система продолжает хранить неправильные объекты и неправильные связи между ними, проблема остаётся.

18.2. Что меняется, а что остаётся

Рассмотрим инженерную платформу, которая существует двадцать лет.

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

Но сами инженерные объекты не исчезают вместе с технологиями.

Изделие остаётся изделием. Его описание остаётся описанием. Экземпляр остаётся конкретным экземпляром. Документ остаётся документом. Связь между объектами сохраняет свой смысл.

Меняется способ хранения и обработки информации. Не сама инженерная реальность.

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

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

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

18.3. Модель данных как архитектурный документ

В традиционном понимании архитектура системы описывается диаграммами сервисов, схемами взаимодействия, спецификациями API и инфраструктурными решениями.

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

Модель данных отвечает на другой вопрос: что система считает существующим?

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

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

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

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

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

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

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

18.4. Модель определяет границы ответственности

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

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

Ни одна из этих областей не должна владеть всем объектом целиком.

Объект один. Знаний о нём много.

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

Например:

                     KObject
                        │
          ┌─────────────┼─────────────┐
          │             │             │
       Design       Technology    Manufacturing
       Service        Service        Service
          │             │             │
      Definition     Definition    Definition
      Revision       Revision      Revision

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

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

18.5. Единый объект — разные области знания

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

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

Все эти сведения относятся к одному объекту или к связанным с ним объектам. Но они не являются одним и тем же знанием.

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

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

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

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

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

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

18.6. Почему неправильная модель не исправляется технологией

Предположим, система построена на неправильной модели.

Например, объект изделия не отделён от его описания.

Команда решает проблему технологически. Меняется база данных. Добавляется кэширование. Вводится событийная архитектура. Сервисы переводятся на другой язык программирования. Интерфейс полностью переписывается.

Но объект по-прежнему не отделён от описания.

Технология изменилась. Модель — нет.

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

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

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

18.7. Что происходит с данными

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

Формально центральная система существует. Фактически данные начинают жить в нескольких мирах. Через несколько лет никто точно не знает, какой источник является актуальным. Данные расходятся. Целостность теряется.

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

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

18.8. Почему это не вопрос интерфейса

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

Сделать более удобные экраны. Добавить подсказки. Упростить навигацию. Добавить ещё один workflow.

Но интерфейс является внешним слоем системы. Он показывает то, что содержит модель.

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

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

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

Интерфейс может скрыть проблему. Но не решить её.

18.9. Как строится платформа

Отсюда следует последовательность, которая кажется очевидной, но на практике часто нарушается.

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

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

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

Это не удобно. Это не быстро. Но это правильная последовательность.

Сначала модель. Потом архитектура. Потом технологии.

18.10. Правильная последовательность требует дисциплины

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

Но они не отвечают на главный вопрос: что именно система должна считать существующим?

Если этот вопрос не решён, команда начинает компенсировать отсутствие модели техническими механизмами. Система растёт. Но её внутренняя семантика становится всё менее определённой.

Правильная последовательность требует обратного подхода.

Сначала модель. Потом всё остальное.

Это не гарантирует идеальную систему. Но это позволяет проверять архитектуру относительно явно определённой модели мира.

18.11. Граница: модель определяет границы, но не реализацию

Было бы неверно утверждать, что модель данных определяет всё.

Она определяет:

• какие объекты существуют;
• как они связаны;
• кто за них отвечает;
• где проходят границы ответственности.

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

Эти решения важны. Но они вторичны. Они определяют, как реализована граница, а не где эта граница проходит.

Хорошая модель данных может быть реализована на разных технологиях.

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

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

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

ANSI/EIA-649-D «Configuration Management Standard» устанавливает требования к управлению конфигурационными данными на протяжении жизненного цикла конфигурационной единицы. Это принципиально: система управления конфигурацией должна быть рассчитана на долгосрочную работу с данными, а не только на возможности конкретного инструмента.

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

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

Эти документы не говорят, что существует единственная архитектура PLM.

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

18.13. ISO 10303-239

Тот же принцип виден в ISO 10303-239, Product Life Cycle Support.

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

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

Модель не обязана копировать PLCS.

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

18.14. NPDM

Аналогичный принцип используется в NATO Product Data Model.

NPDM разделяет product и информацию, связанную с его определением и характеристиками.

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

Это не означает, что Constructum является реализацией NPDM или ISO 10303-239.

Это означает, что выбранное в книге разделение имеет международные архитектурные аналоги.

18.15. Как это закреплено в ЕСКД

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

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

ГОСТ 2.113-75 определяет исполнение как конструктивную разновидность изделия. Это понятие не зависит от базы данных или интерфейса.

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

ГОСТ Р 2.052-2024 и ГОСТ Р 2.053-2023 описывают электронную модель изделия и электронную структуру изделия как отдельные инженерные понятия.

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

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

18.16. Модель не является программой

Это различие важно зафиксировать.

Модель данных не является программой. Она не является базой данных. Она не является API. Она не является микросервисом. Она не является интерфейсом.

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

Можно построить несколько разных программных систем на одной модели. Если смысл модели сохранён, данные продолжают означать то же самое.

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

Технологии одинаковы. Системы — разные.

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

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

Глава 16 установила: различие между PLM находится в исходном вопросе. Одна система спрашивает: как управлять состояниями? Другая спрашивает: что существует?

Глава 17 установила: если модель не соответствует практике, пользователи обходят систему.

Глава 18 добавляет: модель данных является фундаментом платформы. Технологии являются инструментами. Фундамент живёт дольше инструментов.

Вместе эти главы формируют последовательную картину. Сначала определяется, что является объектом. Затем определяется, что является его описанием. Затем определяется, что изменяется, а что остаётся тем же объектом. Затем определяется, как эти понятия должны быть представлены в системе.

И только после этого возникает вопрос о технологии.

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

Цифровая инженерная платформа начинается не с технологий. Не с микросервисов. Не с базы данных. Не с интерфейса.

Она начинается с модели данных.

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

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

Если модель правильная, технологии становятся инструментами. Их можно менять. Обновлять. Заменять.

Модель остаётся. Данные сохраняют смысл. Платформа может жить десятилетиями.

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

Платформа не живёт. Она выживает.

Поэтому инженерная платформа должна строиться от модели мира, а не от технологии.

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

Именно поэтому модель данных является фундаментом платформы.

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

В следующей главе: всё является объектом. Пользователь, документ, revision, исполнение, экземпляр, проект, группа, связь — все они являются объектами. И благодаря этому вся система начинает работать одинаково.

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

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001.
• 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.113-75. Единая система конструкторской документации. Групповые и базовые конструкторские документы.
• ГОСТ Р 2.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ Р 2.052-2024. Единая система конструкторской документации. Электронная модель изделия. Общие положения.
• ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.
• ГОСТ Р 2.051-2023. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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

ЧАСТЬ IV. Что находится внутри модели?

Глава 19. Всё является объектом

Предыдущие главы устанавливали смысл понятий. Теперь мы переводим эти понятия в минимальную структуру модели Constructum. Поэтому следующие главы не вводят новые философские основания, а формализуют уже полученные выводы.

19.1. Разные вещи — один фундамент

До этого момента мы рассматривали объекты с разных сторон.

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

На уровне содержания всё это совершенно разные вещи. Но возникает простой вопрос:

как система представляет сам факт их существования?

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

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

Именно здесь появляется KObject.

19.2. KObject — базовый класс

В объектно-ориентированной модели есть простой принцип.

Есть базовый класс, который определяет общую часть. От него наследуются конкретные классы, добавляющие свою семантику. Например:

              KObject
             /   |   \
            /    |    \
           ↓     ↓     ↓
      KProduct KDocument KUser

KProduct — конкретный тип объекта.

KDocument — другой тип объекта.

KUser — ещё один тип объекта.

Но каждый из них является KObject.

Именно это означает утверждение:

все объекты являются объектами.

Речь не о философии. Речь о структуре модели.

KObject задаёт общий фундамент. Конкретный наследник задаёт то, чем является объект.

19.3. Что общего у всех объектов

Представим изделие.

KProduct
    id = 12345

Теперь документ:

KDocument
    id = 67890

И пользователя:

KUser
    id = 24680

Их содержание совершенно различно.

Но на базовом уровне система работает с ними одинаково: каждый является самостоятельным объектом с собственным идентификатором.

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

Это и есть роль KObject.

19.4. Наследование не делает объекты одинаковыми

Важно не перепутать общий фундамент с одинаковым содержанием.

                         KObject
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
       KProduct          KDocument          KUser
      

Все эти классы имеют общий базовый механизм.

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

У KProduct будет свой набор допустимых сущностей и связей.

У KDocument — свой.

У KUser — свой.

Наследование отвечает только за общее основание.

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

Здесь важно зафиксировать это различие явно:

общий механизм существования
        ≠
общая семантика

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

19.5. Почему нельзя делать отдельный фундамент для каждого типа

Можно было бы построить систему иначе. Например:

ProductBase
DocumentBase
UserBase
ProjectBase
...

У каждого типа была бы собственная схема существования.

Но тогда вместе с каждым новым типом пришлось бы создавать новый механизм:

• идентификации;
• ссылок;
• связей;
• жизненного цикла;
• истории;
• интеграции с остальной системой.

Получилась бы система отдельных миров.

Вместо этого модель говорит:

KObject
   │
   ├── KProduct
   ├── KDocument
   ├── KUser
   ├── KProject
   └── ...

Новый тип получает общий фундамент автоматически.

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

19.6. Один объект может участвовать в разных отношениях

Единый фундамент нужен ещё по одной причине.

Система не существует ради хранения объектов по отдельности.

Объекты должны быть связаны. Изделие связано с документом. Изделие входит в структуру другого изделия. Документ относится к проекту. Пользователь связан с группой. Проект связан с организацией.

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

KObject ←── KRelation ──→ KObject

Связь знает, какие объекты она соединяет. Каждый из них имеет общий фундамент.

Это делает модель единой, не делая её однообразной.

19.7. Что означает «тип объекта»

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

Тип не является заменой KObject. KObject отвечает за общий механизм существования объекта. Конкретный тип отвечает за его смысл в модели.

Поэтому:

KProduct is-a KObject
KDocument is-a KObject
KUser is-a KObject

Но:

KProduct ≠ KDocument
KDocument ≠ KUser

Они разные типы одного общего класса.

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

19.8. Почему это важно для модели данных

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

Он не означает:

все данные должны храниться одинаково.

Не означает:

все объекты должны иметь одинаковые свойства.

Не означает:

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

Он означает только одно:

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

Поэтому система может знать:

KProduct 12345
KDocument 67890
KUser 24680

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

19.9. Откуда берётся содержимое объекта

Теперь можно задать следующий вопрос.

Если KObject содержит общий фундамент, где находятся остальные данные?

Ответ уже подготовлен предыдущими главами.

Описание находится в KDefinition.

Изменения описания — в Revision.

Свойства — в KAttribute.

Связи — в KRelation.

Административное состояние — в KContext.

То есть объект не превращается в одну большую запись.

Вокруг него существует модель:

                         KObject
                            │
          ┌─────────────────┼──────────────────┐
          │                 │                  │
    KDefinition         KAttribute         KContext
          │
       Revision
          │
       KRelation

Здесь важно видеть не дерево владения, а общий объектный фундамент.

KObject — начало.

Остальные сущности добавляют сведения о конкретном объекте.

19.10. Почему единый фундамент устойчив

PLM-система живёт десятилетиями.

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

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

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

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

Устойчивым должен быть общий объектный фундамент модели.

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

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

Глава 12 установила: связи являются самостоятельными объектами.

Глава 19 добавляет: все самостоятельные объекты модели имеют общий базовый класс KObject. Конкретные типы объектов являются его наследниками.

Эта глава не утверждает, что все объекты одинаковы.

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

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

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

Все самостоятельные объекты системы имеют общий базовый класс — KObject.

KObject определяет общую часть объекта.

KProduct, KDocument, KUser, KProject и другие типы наследуют этот фундамент и добавляют собственную семантику.

Поэтому:

единый фундамент не делает объекты одинаковыми.

Он позволяет разным объектам существовать внутри одной модели.

И это уже не абстракция. Это конкретная структура:

                         KObject
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
       KProduct          KDocument          KUser
          │
      KInstance

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

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

Источники:

• 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.052-2024. Единая система конструкторской документации. Электронная модель изделия. Общие положения.
• ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.
• ГОСТ Р 2.051-2023. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

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

Глава 20. KObject — общий фундамент объекта

20.1. Самый маленький общий знаменатель

Теперь мы знаем, что KObject — базовый класс.

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

Но что это? Изделию нужно описание. Документу нужно содержание. Пользователю нужны свойства. Проекту нужны участники. Связи имеют собственные характеристики.

Ничего из этого нельзя считать общей частью всех объектов.

Остаётся более простой уровень. Система должна знать:

этот объект существует.

И должна уметь отличить его от любого другого объекта. Поэтому фундамент начинается с идентификатора.

KObject
    id = 12345

Это не имя. Не номер изделия. Не обозначение документа. Не код проекта.

Это идентификатор самого объекта внутри модели.

20.2. Почему идентификатор не является именем

Рассмотрим объект:

KProduct
    id = 12345

Сегодня изделие называется:

Насос Н1

Через несколько лет его название может измениться:

Насос Н1А

Сам объект при этом не становится другим. Поэтому название не должно определять сам KObject.

Название — это информация об объекте.

KObject 12345
    │
    └── KAttribute
            name = "Насос Н1"

Позже:

KObject 12345
    │
    └── KAttribute
            name = "Насос Н1А"

KObject остаётся тем же. Изменилось знание о нём.

20.3. Почему свойства не входят в KObject

То же самое относится к инженерным свойствам.

У изделия может измениться:

• масса;
• материал;
• производитель;
• назначение;
• статус;
• любое другое значение, которое модель допускает изменять.

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

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

KObject
    │
    └── KAttribute
            ├── material
            ├── mass
            └── ...

KObject остаётся основой.

KAttribute хранит сведения об объекте.

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

20.4. Почему описание не входит в KObject

То же правило относится к описанию.

У одного объекта может быть несколько описаний. Например:

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

Каждое описание развивается независимо.

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

Если описание изменилось, KObject не меняется. Поэтому KObject не должен содержать Definition.

Он только является объектом, к которому Definition относится.

20.5. Почему контекст не входит в KObject

Та же граница действует для административного состояния.

Владелец может измениться. Проект может измениться. Группа владения может измениться. Административное состояние объекта может измениться.

Поэтому эти данные относятся к KContext.

KObject
    │
    └── KContext
            ├── owner
            ├── project
            └── owningGroup

Причём связь направлена именно так:

KContext знает, к какому KObject он относится.

KObject не обязан знать о существовании KContext. Это принципиально.

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

Поэтому объект и его административный контекст остаются разделёнными.

20.6. Почему состояние не входит в KObject

Объект может проходить через разные состояния:

в разработке
      ↓
в производстве
      ↓
в эксплуатации
      ↓
выведен из эксплуатации

Состояние изменяется. Сам объект при этом продолжает существовать.

Следовательно, состояние не может быть частью неизменяемого фундамента.

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

20.7. Что тогда действительно входит в KObject

Теперь можно сформулировать правило.

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

В первую очередь это:

KObject
    └── id

Именно здесь находится минимальная общая часть. Всё, что отвечает на вопросы:

что это за тип? как оно называется? какими свойствами обладает? как оно описано? в каком административном контексте находится? с чем связано?

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

20.8. Тип находится в наследнике

Здесь особенно важно исправить возможное недоразумение.

Нельзя говорить:

KObject не имеет типа.

Правильнее сказать:

KObject является базовым классом, а конкретный объект имеет конкретный тип — один из его наследников.

Например:

KObject
   │
   ├── KProduct
   ├── KDocument
   ├── KUser
   └── KProject

Конкретный объект:

KProduct
    id = 12345

является одновременно:

• конкретным KProduct;
• KObject.

Как и положено объекту-наследнику в объектно-ориентированной модели.

KObject задаёт общую часть.

KProduct добавляет специфику изделия.

KDocument добавляет специфику документа.

KUser добавляет специфику пользователя.

Поэтому типизация не исчезает. Наоборот — она становится частью самой структуры модели.

20.9. KObject не должен становиться «универсальной таблицей»

Есть соблазн решить проблему универсальности иначе:

KObject
    id
    type
    name
    owner
    status
    project
    material
    mass
    description
    ...

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

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

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

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

Модель делает обратное.

Она оставляет в KObject только действительно общую часть.

20.10. Что получается в результате

Теперь модель можно увидеть целиком:

                         KObject
                            │
          ┌─────────────────┼──────────────────┐
          │                 │                  │
       KProduct          KDocument           KUser
          │
          ├── KDefinition
          │       └── Revision
          │
          ├── KAttribute
          │
          ├── KContext
          │
          └── KRelation

Эти сущности относятся к одному объекту, но не являются внутренними полями KObject.

Здесь каждый уровень отвечает за свою задачу.

KObject:

какой объект существует?

Тип объекта:

чем является этот объект?

KAttribute:

что известно о его свойствах?

KDefinition:

как он описан?

Revision:

какое состояние этого описания зафиксировано?

KContext:

в каких административных условиях находится объект?

KRelation:

как этот объект связан с другими объектами?

Эти вопросы различаются. Поэтому они не должны быть сведены в одну сущность.

20.11. Почему это важно

Такое разделение позволяет изменять разные части модели независимо.

Изменилось название — объект не изменился. Изменилось свойство — объект не изменился. Появилась новая Revision — объект не изменился. Изменился административный контекст — объект не изменился. Изменились связи — объект не изменился.

Меняется информация вокруг объекта. Сам фундамент остаётся тем же.

Именно поэтому KObject может существовать на протяжении всего жизненного цикла объекта, не превращаясь в контейнер его текущего состояния.

20.12. Связь с предыдущими главами

Глава 11 установила: идентичность объекта стабильна, описание изменяется во времени.

Глава 19 установила: все самостоятельные объекты имеют общий базовый класс KObject. Конкретные типы объектов являются его наследниками.

Глава 20 добавляет: KObject содержит общую для всех объектов основу. Свойства, описания, контекст и связи относятся к другим сущностям модели.

Это не новая идея, появившаяся из технической реализации. Это следствие всей модели, построенной в предыдущих главах.

Если объект существует независимо от описания, если описание изменяется, если контекст изменяется, если свойства изменяются, а связи имеют собственную жизнь, то всё это нельзя помещать в сам объект.

Должна существовать устойчивая точка, относительно которой всё остальное определяется.

В KModel этой точкой является KObject.

20.13. Главный вывод

KObject — не «пустой объект». И не объект без типа.

Это базовый класс всех объектов модели.

Он содержит минимальную общую часть, необходимую для существования объекта в системе.

Конкретные наследники определяют, чем объект является. Другие сущности модели хранят сведения о нём:

                 KObject
                    │
          ┌─────────┼─────────┐
          ↓         ↓         ↓
      KProduct  KDocument   KUser
          │
     ┌────┼────┬────────┬────────┐
     ↓    ↓    ↓        ↓        ↓
 Attribute Definition Context Relation
                 │
              Revision

Эти сущности относятся к одному объекту, но не являются внутренними полями KObject.

Именно здесь проходит важная граница:

KObject — это не весь объект и не все знания о нём. Это общий базовый фундамент, на котором строятся конкретные типы объектов и всё остальное знание системы об этих объектах.

В следующей главе мы сделаем следующий шаг: если свойства не являются полями KObject, что именно представляет собой атрибут и почему он сам становится объектом модели?

Примечания к главе 20

Источники:

• 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.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.2.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• ГОСТ Р 2.052-2024. Единая система конструкторской документации. Электронная модель изделия. Общие положения.
• ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.
• Rönnbäck, L. et al. Anchor Modeling: An Agile Modeling Technique Using the Sixth Normal Form. 2010.

Типы доказательств:

Глава 21. KAttribute — знания об объекте

21.1. Поле, которое лжёт

Откройте любую таблицу базы данных. Найдите строку, которая представляет изделие.

Product
    id: 12345
    name: Насос Н1
    material: 09Г2С
    weight: 45.0
    status: in_production

Что вы видите? Вы видите объект. Его имя. Его материал. Его массу. Его статус. Всё кажется простым и понятным.

Но задайте один вопрос: когда материал стал 09Г2С?

Таблица не отвечает. Она хранит текущее значение. Предыдущее значение потеряно.

Задайте другой вопрос: кто изменил материал?

Таблица снова не отвечает. Она хранит значение, но не хранит событие изменения.

Задайте третий вопрос: на каком основании материал был изменён?

Таблица не знает об извещении об изменении. Не знает о решении конструктора. Не знает о результатах испытаний.

Поле хранит значение. Но не хранит знание. А инженерное знание — это не только значение.

Это значение, существующее в определённый момент времени, полученное из определённого источника и имеющее определённое основание.

При этом важно не перепутать две вещи.

KObject действительно содержит общую основу объекта. Но свойства объекта не являются частью этой основы.

KProduct остаётся KObject, но его материал, масса, обозначение или другие характеристики не становятся полями базового класса.

Они являются знаниями об объекте.

21.2. Почему поле не является знанием

Рассмотрим конкретную ситуацию.

Насос Н1 был разработан в 2026 году. Материал корпуса — Сталь 20. В 2031 году конструктор изменил материал на 09Г2С. В 2040 году возникает вопрос: Из какого материала изготовлен экземпляр №12345?

Если система хранит только текущее поле material = 09Г2С, ответить на этот вопрос невозможно. Текущее значение не говорит, какое значение действовало в момент изготовления конкретного экземпляра.

Чтобы ответить, система должна знать историю:

2026
    material = Сталь 20
2031
    material = 09Г2С

Но одной истории тоже недостаточно. Нужно знать: Кто установил значение? На каком основании? Когда оно вступило в действие? Какое утверждение оно заменило?

Тогда инженерное знание становится восстановимым.

KObject: 12345
    |
    +-- KAttribute: material
    |       value: Сталь 20
    |       valid_from: 01.01.2026
    |       valid_to: 01.06.2031
    |       source: конструктор Иванов
    |       basis: расчёт прочности №12
    |
    +-- KAttribute: material
            value: 09Г2С
            valid_from: 01.06.2031
            valid_to: (действует)
            source: конструктор Петров
            basis: извещение об изменении №45

Теперь система знает не только значение. Она знает, что было известно об объекте, когда это стало известно, кем было установлено и почему это стало известно.

Это принципиально другая модель данных.

21.3. Утверждение вместо значения

Вернёмся к тому, как инженер говорит об объекте.

Он не думает:

Product.material = 09Г2С

Он говорит:

«Материал корпуса этого насоса — 09Г2С».

И это утверждение имеет контекст. Кто это сказал? Когда? На основании чего? Для какого объекта? До какого момента это утверждение считалось действующим?

Инженерное знание почти никогда не является просто значением. Оно является утверждением о некотором объекте. Поэтому в модели между объектом и значением появляется самостоятельное утверждение:

KObject
    |
    └── KAttribute
            |
            ├── value
            ├── valid_from
            ├── valid_to
            ├── source
            └── basis

KObject остаётся тем же. Изменяется утверждение о нём.

21.4. Объект постоянен. Утверждения изменяются

Это продолжение принципа, сформулированного ранее.

Объект существует. Знание об объекте появляется позже. Знание изменяется. Объект при этом остаётся тем же.

Представим историю материала корпуса:

KObject: Насос Н1

2026
    KAttribute
        material = Сталь 20

2031
    KAttribute
        material = 09Г2С

2036
    KAttribute
        material = 10ХСНД

Не существует трёх насосов. Существует один насос и три последовательных утверждения о его материале.

Именно поэтому изменение свойства не должно изменять KObject.

Если материал изменился — изменилось знание. Если изменилась масса — изменилось знание. Если изменился статус — изменилось знание. Если изменился источник знания — изменилось знание.

Сам объект остаётся тем же.

21.5. Время является частью утверждения

В обычной модели время часто находится где-то рядом с историей изменений.

В модели утверждений время является частью самого знания. Это принципиальная разница.

Утверждение:

material = 09Г2С

неполно. Полное утверждение:

material = 09Г2С
valid_from = 01.06.2031
valid_to = NULL
source = конструктор Петров
basis = извещение №45

Теперь система знает, когда это утверждение действует.

Поэтому можно задать вопрос: Какой материал был установлен для насоса 1 июня 2030 года?

И получить историческое значение.

Можно задать другой вопрос: Кто установил действующее значение? И получить источник.

Можно спросить: На каком основании материал был изменён? И получить основание.

Это уже не обычное хранение свойств. Это хранение инженерного знания.

21.6. Атрибут имеет собственную жизнь

Если утверждение имеет время, источник, основание и собственную историю изменений, оно перестаёт быть простым полем.

Оно становится самостоятельной сущностью модели.

KAttribute имеет:

• собственную идентификацию;
• ссылку на KObject;
• тип утверждения;
• значение;
• время действия;
• источник;
• основание;
• собственную историю версий.

Поэтому KAttribute является самостоятельной сущностью модели.

Это не означает, что атрибут становится самостоятельным без связи с KObject.

Наоборот.

KAttribute существует для того, чтобы утверждать что-либо о KObject.

Если KObject отвечает на вопрос: «Что существует?»

то KAttribute отвечает на вопрос: «Что система знает об этом объекте?»

Это разные вопросы. Здесь важно зафиксировать одну границу.

То, что атрибут является самостоятельным объектом модели, не означает, что любое значение должно превращаться в отдельный объект произвольной природы. Атрибут остаётся утверждением определённого типа, относящимся к конкретному объекту и имеющим собственные правила и время действия.

При этом KAttribute не является наследником KObject. Не всё, что является сущностью модели, обязано быть типом KObject. Атрибут — самостоятельная сущность, но она относится к объекту, а не является объектом того же уровня.

21.7. Почему изменение создаёт новое утверждение

В обычной объектной модели разработчик может сделать:

product.material = "09Г2С";

Старое значение исчезает.

В модели Constructum такое изменение не означает переписывание существующего знания. Предыдущее утверждение закрывается. Создаётся новое.

Старое утверждение
    valid_from = 2026
    valid_to   = 2031

Новое утверждение
    valid_from = 2031
    valid_to   = NULL

Это важный архитектурный принцип.

История не является побочным журналом изменения. История является частью модели знания.

Таким образом, временность не является дополнительной функцией аудита. Она является частью самого KAttribute.

21.8. Источник и основание

Инженерное знание почти всегда имеет происхождение.

Материал изменился потому, что:

• появился новый расчёт;
• были проведены испытания;
• изменилось требование заказчика;
• вышло извещение об изменении;
• конструктор принял новое решение.

Поэтому утверждение должно позволять установить происхождение знания. Например:

KAttribute
    type: material
    value: 09Г2С
    source:
        Конструктор Петров
    basis:
        Извещение об изменении №45
    valid_from:
        01.06.2031

Теперь система может восстановить не только состояние объекта, но и происхождение этого состояния.

Это особенно важно для PLM. Через десять лет вопрос обычно звучит не:

«Какое значение сейчас?»

Он звучит:

«Почему тогда приняли именно это решение?»

Именно здесь обычное поле базы данных оказывается недостаточным.

21.9. Что говорят стандарты

Это не только архитектурная идея Constructum.

ANSI/EIA-649-D рассматривает учёт состояния конфигурации как процесс сохранения информации об изменениях конфигурационных данных. Стандарт требует, чтобы информация о состоянии конфигурационной единицы была восстановима во времени.

NASA Systems Engineering Handbook требует вести историческую запись изменений конфигурационных данных, включая информацию о самом изменении, времени, причине и полномочиях утверждения.

MIL-HDBK-61A также требует прослеживаемости изменения конфигурационных данных до его источника, включая предложение об изменении, утверждающий орган и дату вступления в действие.

ISO 10303-239 (PLCS) формализует разделение между продуктом и информацией о нём. Характеристики продукта (characteristic) представлены как отдельные сущности, связанные с определениями продукта. Это подтверждает принцип: информация о свойствах изделия является самостоятельной сущностью, а не просто полем записи.

NPDM (NATO Product Data Model, STANAG 4613) использует аналогичный подход. Характеристики продукта отделены от самого продукта и связаны с ним через определения. Информация о продукте имеет собственную структуру и собственную историю.

Эти требования имеют общий смысл: информация о состоянии изделия должна быть восстановима во времени и прослеживаема до источника её изменения.

Constructum переводит это требование из процедурного уровня в модель данных.

21.10. Как это закреплено в ЕСКД

Отечественная инженерная практика выражает тот же принцип через извещение об изменении.

ГОСТ Р 2.503-2023 устанавливает порядок внесения изменений в конструкторскую документацию через извещение об изменении.

Изменение имеет:

• номер;
• дату;
• основание;
• содержание;
• перечень изменяемых документов;
• порядок введения изменения в действие.

Следовательно, изменение не является простым присваиванием нового значения полю. Оно имеет основание и историю.

Если система хранит только:

material = 09Г2С

то извещение об изменении невозможно связать с самим фактом изменения.

Если система хранит утверждение как самостоятельную сущность, связь становится естественной:

KObject
    |
    └── KAttribute
            |
            └── изменено на основании
                    |
                    └── KChangeNotice

Модель данных начинает отражать инженерную практику непосредственно.

21.11. Практический пример

Рассмотрим насос Н1. В 2026 году инженер установил:

material = Сталь 20
Источник: Иванов
Основание: Расчёт прочности №12

В 2031 году материал изменился.

Причина: Извещение об изменении №45
Новое значение: 09Г2С
Источник: Петров

Модель хранит:

KObject: Насос Н1
     |
     +-- KAttribute
     |       type: material
     |       value: Сталь 20
     |       valid_from: 2026
     |       valid_to: 2031
     |       source: Иванов
     |       basis: Расчёт №12
     |
     +-- KAttribute
             type: material
             value: 09Г2С
             valid_from: 2031
             valid_to: NULL
             source: Петров
             basis: Извещение №45

Теперь через двадцать лет можно восстановить историю. Не только текущее значение.

Можно восстановить последовательность решений.

21.12. Почему это важно для экземпляров

Здесь появляется особенно важное следствие.

Тип изделия и конкретный экземпляр — разные объекты.

Если насос Н1 имеет несколько ревизий описания, это не означает, что каждый изготовленный насос автоматически имеет последнюю ревизию.

Конкретный экземпляр является самостоятельным объектом. Он имеет собственные утверждения и собственный производственный контекст. Информация о том, какая Revision была применена при его изготовлении, относится к этому экземпляру и фиксируется в соответствующей связи/контексте применения.

Поэтому вопрос: «Какая Revision сейчас актуальна для KProduct?»

и вопрос: «Какая Revision была применена при изготовлении экземпляра №12345?»

— это разные вопросы.

Первый относится к текущему состоянию описания. Второй — к историческому факту конкретного изготовления.

KAttribute позволяет сохранять знания, необходимые для ответа на такие вопросы, не смешивая объект, его описание и конкретный экземпляр.

21.13. Почему это не просто EAV

На первый взгляд модель может показаться обычным EAV (Entity-Attribute-Value):

object_id
attribute
value

Но это принципиально не так. В EAV основная идея — вынести свойства в универсальную таблицу значений.

Здесь задача другая.

KAttribute представляет не просто значение, а утверждение, которое является частью модели инженерного знания.

Поэтому оно имеет:

KObject
    ↓
KAttribute
    ├── type
    ├── value
    ├── valid_from
    ├── valid_to
    ├── source
    └── basis

Кроме того, типы атрибутов остаются определёнными.

Поэтому гибкость модели не означает отказ от строгости.

21.14. Anchor Modeling: философия, а не реализация

В Главе 11 мы уже рассмотрели три подхода к хранению изменяемых данных: фиксированную схему, EAV и Anchor Modeling. Здесь зафиксируем лишь архитектурный принцип, который следует из этого анализа.

Объект и утверждения об объекте должны быть разделены. Не только на уровне таблиц.

На уровне модели.

KObject: 123
      |
      +-- KAttribute: material
      |       value: Сталь 20
      |       время: 01.01.2026
      |       источник: конструктор
      |
      +-- KAttribute: material
      |       value: 09Г2С
      |       время: 01.06.2031
      |       источник: конструктор
      |       основание: извещение №45
      |
      +-- KAttribute: weight
              value: 45.0 кг
              время: 01.01.2026
              источник: расчёт

Объект является точкой. Утверждения развиваются вокруг него. Каждое утверждение имеет собственную жизнь. Собственное время. Собственный источник. Собственное основание.

Это не технический приём. Объект существует. Знания об объекте появляются, изменяются, устаревают, заменяются.

Объект не меняется. Меняются утверждения.

21.15. Почему это важно для расширяемости

Рассмотрим ситуацию.

Через десять лет появляется новое требование: необходимо хранить экологический класс изделия.

В классической модели необходимо изменить структуру таблицы:

ALTER TABLE product
ADD environmental_class ...

Затем провести миграцию. Обновить код. Обновить интеграции. Изменить отчёты.

В модели утверждений структура фундаментального объекта не меняется. Появляется новый тип утверждения:

KObject: 12345
    |
    +-- KAttribute: material
    |       ...
    |
    +-- KAttribute: weight
    |       ...
    |
    +-- KAttribute: environmental_class
            value: класс II
            valid_from: 01.01.2036
            source: экологическая служба
            basis: стандарт ГОСТ Р ...

Объект не изменился. Структура модели не изменилась. Появилось новое знание.

Механизм тот же. История та же. Источник тот же.

Это важно для PLM-системы, которая должна жить десятилетиями.

Новые инженерные понятия будут появляться постоянно. Если каждое новое понятие требует изменения фундаментальной структуры, система постепенно становится заложником собственной истории.

Модель утверждений позволяет расширять область знаний без изменения механизма существования объектов.

21.16. Почему это не означает отсутствие строгости

Здесь возникает естественный вопрос.

Если любое свойство можно представить как KAttribute, не превращается ли модель в произвольное хранилище?

Нет.

Гибкость находится на уровне утверждений.

Строгость сохраняется на уровне типов объектов и допустимых отношений между ними.

Система знает:

• какие типы объектов существуют;
• какие типы атрибутов допустимы;
• какие значения допустимы;
• какие связи допустимы;
• какие изменения разрешены;
• какие утверждения могут существовать одновременно.

Например, система может разрешить:

KProduct
    └── KAttribute: material

но запретить:

KProduct
    └── KAttribute: document_author

если автор является характеристикой документа, а не изделия. Гибкость и строгость здесь не противоречат друг другу.

Они находятся на разных уровнях модели.

21.17. Связь с предыдущими главами

21.18. Главный вывод

Свойства объекта не являются его полями.

Они являются утверждениями об объекте.

Каждое утверждение имеет собственную жизнь: время появления, источник, основание и значение. Оно может быть изменено, заменено, подтверждено или прекращено. Объект при этом остаётся тем же.

Международные стандарты Configuration Management, ISO 10303-239, NATO Product Data Model и отечественная система ЕСКД сходятся в одном принципе: информация о состоянии изделия должна сохраняться во времени и быть прослеживаема до источника изменения.

Constructum переводит этот принцип в модель данных. KObject представляет то, что существует. KAttribute представляет то, что известно об этом объекте.

Поэтому атрибут — не поле таблицы и не потерянное при обновлении значение. Это самостоятельное утверждение о реальном объекте, имеющее собственное время, источник, основание и историю.

Именно это позволяет системе через десять, двадцать и тридцать лет ответить не только на вопрос: «Что известно об объекте сейчас?»

но и на гораздо более важный инженерный вопрос: «Что было известно об объекте тогда, кто это установил и на каком основании?»

В следующей главе: где существуют условия жизни объекта? Почему контекст — владелец, проект, организация — не является свойством объекта, а является самостоятельной сущностью.

Примечания к главе 21

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §4.3.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016. §5.3.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001. §4.2.
• 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.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• Rönnbäck, L. et al. Anchor Modeling: An Agile Modeling Technique Using the Sixth Normal Form. 2010.

Типы доказательств:

Глава 22. Почему KContext существует отдельно

22.1. Контекст отвечает не на вопрос «что это?», а на вопрос «в каких условиях существует?»

Вернёмся к насосу Н1.

Он существует. У него есть собственная идентичность. У него есть описание. У него есть свойства.

Но существует он не в пустоте.

Насос Н1 разработан на предприятии А. В рамках проекта Б. Под ответственностью определённого владельца. В определённой организационной структуре. В определённой компании.

Все эти обстоятельства не определяют, что является самим объектом.

Насос не становится другим насосом только потому, что изменился его владелец. Он не становится другим объектом потому, что его передали другой группе или изменились административные условия его использования.

Но эти обстоятельства определяют, в каких условиях объект существует и управляется.

Именно для этого в модели существует KContext.

Контекст отвечает не на вопрос: Что это за объект?

а на вопрос: В каких административных условиях этот объект существует сейчас?

Это принципиальное разделение.

22.2. Классическая модель: контекст как поля

В традиционном подходе такие сведения часто хранятся непосредственно в записи объекта.

Product
    id: 12345
    name: Насос Н1
    owner: Иванов
    project: Проект А
    organization: Предприятие Б
    status: in_production

На первый взгляд это выглядит естественно.

Владелец — поле. Проект — поле. Организация — поле. Статус — поле.

Но проходит время.

Владелец меняется. Объект передаётся другой группе. Меняется административное окружение. Изменяется состояние управления объектом.

Каждое такое изменение приходится записывать непосредственно в объект.

Проблема не в самом изменении. Проблема в том, что сведения об объекте и сведения об условиях его управления оказываются смешаны в одной сущности.

Тогда изменение административного состояния выглядит как изменение самого объекта. Но инженерно это не так.

Объект остаётся тем же. Меняются условия, в которых он существует и управляется.

22.3. Почему контекст не является свойством объекта

Рассмотрим конкретную ситуацию.

Насос Н1 разработан в 2026 году. В определённый момент его владельцем является Иванов. Объект находится в определённой группе и компании.

Позже владелец меняется. Насос Н1 стал другим?

Нет. Изменились условия управления объектом.

Позже объект переводится в другую группу. Насос Н1 стал другим?

Нет. Изменился административный контекст.

Поэтому сведения о владельце и группе не должны превращаться в свойства самого объекта только потому, что они связаны с ним.

Это и есть причина существования KContext как отдельной сущности.

22.4. KContext не является частью KObject

Здесь есть важное архитектурное уточнение.

В модели Constructum KObject и KContext существуют раздельно.

KObject не знает о KContext. Связь направлена в другую сторону: KContext относится к конкретному KObject.

Это принципиально. KObject не зависит от KContext на уровне своей структуры. Это не означает, что активный объект может существовать без контекста. В Constructum создание KObject и его первоначального KContext является атомарной операцией: активный KObject всегда имеет активный KContext. Контекст, напротив, не имеет смысла без объекта.

KObject
   │
   │
   │  объект не знает о контексте
   │
   ▼
KContext
   │
   └── target_object_id → KObject

Это направление связи выбрано намеренно.

KObject является фундаментальным фактом существования объекта. Он не должен зависеть от административного механизма, который определяет владельца, группу или другие условия управления этим объектом.

KContext является самостоятельной сущностью, которая относится к KObject и хранит административное состояние, связанное с этим объектом.

Такое разделение позволяет отделить данные об объекте от управления доступом к нему. KContext хранит административные условия существования объекта. На основании этих данных могут строиться производные представления — projections, используемые механизмами авторизации. Эти projections не являются источником истины. Они являются производным представлением основной модели.

Это даёт важное разделение:

KObject
    ↓
факт существования объекта

KContext
    ↓
административные условия его существования

Projection
    ↓
производные представления для управления доступом

Последний уровень является уже производным. Он вычисляется на основании данных модели и не является частью самого KObject.

22.5. Что такое KContext

KContext отвечает на вопрос: В каких административных условиях находится объект?

В текущей модели контекст связан с объектом через target_object_id.

Его собственное состояние имеет время действия:

valid_from
valid_to

Административные характеристики контекста представлены отдельными атрибутами. В частности, текущая реализация хранит владельца и группу владения как атрибуты KContext.

Упрощённо:

KObject: 12345
      ↑
      │ target_object_id
      │
KContext
      │
      ├── owner
      ├── owningGroup
      ├── valid_from
      └── valid_to

Таким образом, KContext не превращает административные сведения в свойства KObject.

Он хранит их отдельно.

22.6. Контекст как самостоятельная сущность

Если контекст имеет собственное время, собственный идентификатор и собственные атрибуты, он не является простым полем объекта. Это самостоятельная сущность.

Она имеет:

• собственную идентичность;
• время действия;
• ссылку на объект, к которому относится;
• административные атрибуты;
• собственный жизненный цикл.

При этом KContext не является копией KObject и не является альтернативным представлением объекта. Он существует для объекта, но не внутри объекта.

Это различие кажется небольшим, но для архитектуры оно принципиально.

22.7. Инвариант: объект первичен, контекст вторичен

Здесь необходимо сформулировать одно из фундаментальных правил модели.

KObject
   ↑
   │
   │ относится к
   │
KContext

Логически объект первичен. Контекст вторичен.

Контекст не имеет смысла без объекта, потому что сам вопрос «в каких условиях существует этот объект?» предполагает существование объекта.

Поэтому невозможно создать самостоятельный контекст, не относящийся ни к одному KObject.

Но в текущей реализации есть важное уточнение: KObject и его первоначальный KContext создаются как единое целое.

Это означает, что для активного объекта система не допускает состояния, при котором KObject уже зарегистрирован как активный объект, а его контекст отсутствует.

Таким образом, необходимо различать два утверждения:

логически:

KObject первичен → KContext относится к нему

технически:

создание KObject + первоначального KContext
является одной атомарной операцией

Это не противоречие. Первое утверждение описывает зависимость сущностей. Второе — правило их создания.

22.8. Почему невозможно создать контекст отдельно

Представим, что система разрешает создать KContext без объекта.

Пользователь создаёт контекст. Указывает владельца. Указывает группу. Определяет административные условия.

Но объекта, к которому всё это относится, нет. Что означает такой контекст?

Ничего.

Он не описывает условия существования какого-либо объекта.

Поэтому KContext не является самостоятельной административной записью, которую можно создать «на будущее».

Он всегда относится к конкретному KObject.

22.9. Почему KObject не знает о KContext

Это решение может показаться необычным.

Если KContext относится к KObject, почему бы просто не хранить context_id внутри KObject?

Потому что это создаёт обратную зависимость. Получилась бы модель:

KObject
   │
   └── context_id
          ↓
       KContext

Тогда фундаментальная сущность объекта начинает зависеть от административной сущности. Вместо этого модель использует обратное направление:

KObject
   ↑
KContext
   └── target_object_id

KObject остаётся независимым. Context Service может управлять контекстом, не изменяя структуру самого KObject.

Это особенно важно для распределённой системы. Данные об объекте и административное управление объектом могут находиться в разных границах ответственности.

KObject не должен знать, каким способом система определяет его владельца или область доступа.

Он просто существует.

22.10. Почему контекст не является ACL

На первый взгляд может показаться, что KContext — это просто механизм управления доступом (Access Control List).

Владелец определяет, кто имеет отношение к объекту. Группа определяет область управления. Из контекста строятся производные данные для проверки прав.

Но KContext и права — не одно и то же.

KContext отвечает на вопрос: В каких административных условиях существует объект?

Механизм прав отвечает на другой вопрос: Что конкретный пользователь имеет право сделать с этим объектом?

Эти сведения связаны, но не тождественны. Следовательно:

KContext
    ↓
административные факты
        +
        ↓
другие факты системы
    ↓
проекции
    ↓
решение о доступе

Само право не является свойством KObject.

22.11. Почему контекст не является папкой

Другое распространённое заблуждение: контекст — это папка, в которой хранится объект.

Проект — папка.

Группа — папка.

Организация — папка.

Но папка является механизмом организации хранения.

KContext — не механизм хранения. Объект не «лежит» в контексте. KContext фиксирует административные условия, связанные с объектом.

Это принципиально разные вещи.

Папка может быть изменена исключительно ради организации пользовательского интерфейса.

Изменение KContext является изменением административного состояния объекта.

22.12. Почему контекст не является проектом

Ещё одно заблуждение: контекст — это проект.

В ранних вариантах модели проект рассматривался как один из элементов контекста. Но текущая реализация KContext уже не хранит projectId. Контекст в актуальной версии модели содержит ссылку на объект, владельца и группу владения; проект не является его самостоятельным атрибутом.

Это важное уточнение.

Не следует расширять понятие KContext до универсального контейнера для всех административных сведений.

KContext имеет строго определённую ответственность. Он описывает административное состояние объекта в пределах данной модели.

22.13. Время является частью контекста

Контекст не является неизменным.

Владелец может измениться. Группа владения может измениться. Сам контекст может быть закрыт.

Поэтому KContext имеет собственный временной интервал:

valid_from
valid_to

История при этом не заменяется новым значением. Предыдущее состояние закрывается, а новое становится действующим.

Упрощённо:

KObject: 12345

KContext
    owner: Иванов
    group: Группа А
    valid_from: 2026
    valid_to:   2028

KContext
    owner: Петров
    group: Группа Б
    valid_from: 2028
    valid_to:   ...

Сам KObject остаётся тем же. Меняется административное состояние, связанное с ним.

Именно поэтому история должна принадлежать контексту и его атрибутам, а не превращать изменение контекста в изменение самого объекта.

22.14. Практический пример

Рассмотрим насос Н1.

В 2026 году он зарегистрирован в системе. Вместе с ним создаётся первоначальный KContext.

KObject: 12345
    ↑
    │
KContext
    owner: Иванов
    group: Группа А
    valid_from: 01.01.2026
    valid_to: (действует)

В 2028 году владелец меняется. Сам KObject не изменяется. Изменяется контекстное состояние:

KObject: 12345
    ↑
    │
KContext
    owner: Иванов
    group: Группа А
    valid_from: 01.01.2026
    valid_to: 01.06.2028

KContext
    owner: Петров
    group: Группа А
    valid_from: 01.06.2028
    valid_to: (действует)

В 2030 году меняется группа владения. Снова не возникает нового объекта. Изменяется административное состояние.

Так система может ответить не только на вопрос: Кто владеет объектом сейчас?

но и: Кто владел объектом в 2027 году?

Потому что история контекста не уничтожается при изменении текущего состояния.

22.15. Почему это важно для долгоживущих систем

PLM-система живёт десятилетиями. За это время меняются люди. Меняются группы. Реорганизуются компании. Изменяются административные полномочия.

Если такие сведения являются обычными полями KObject, история быстро превращается в историю изменений самого объекта.

Это смешивает два разных события: изменилось описание объекта

и

изменились условия управления объектом

Модель KContext разделяет эти события. Изменение владельца не является изменением Definition. Изменение группы не является новой Revision. Изменение административного состояния не создаёт новый KObject.

Это позволяет отдельно управлять историей объекта и историей условий его управления.

22.16. Контекст и производные представления

На этом месте возникает ещё один важный слой.

KContext хранит административные факты. Но проверка прав не обязана каждый раз заново собирать эти факты из основной модели.

На их основе строятся производные представления. Например:

KContext
   │
   ├── owner
   └── owningGroup
          │
          ▼
     Object Scope
          │
          ▼
   Effective Permissions

Такие проекции являются частью модели эксплуатации системы, но не частью самого объекта.

Они могут синхронизироваться и пересчитываться при изменении исходных данных.

Это важное архитектурное разделение: основная модель хранит факты, производная модель помогает быстро принимать решения на их основании.

Поэтому система управления доступом не должна превращать права в свойства KObject.

22.17. Связь с предыдущими главами

Глава 20 установила: KObject фиксирует сам факт существования объекта. Он не содержит его свойств, описания или контекста.

Глава 22 добавляет: условия существования и административного управления объектом также не должны смешиваться с самим объектом.

KContext является самостоятельной сущностью. Он относится к KObject. KObject не зависит от него на уровне своей структуры.

KContext хранит собственное временное состояние и административные атрибуты.

Производные проекции используют эти данные для решения задач доступа, но не становятся частью KObject.

Вместе эти главы формируют последовательную картину:

KObject
     │
     │ существует
     │
     ├── Definition
     ├── Revision
     ├── Attribute
     └── Relation

 KContext
     │
     └── административное состояние,
         связанное с KObject

 Projection
     │
     └── производное представление
         для задач доступа

22.18. Граница: KContext не является универсальным контейнером

Было бы неверно утверждать, что KContext может содержать любые сведения об объекте.

KContext не описывает конструкцию объекта.

Не содержит его Definition. Не содержит Revision. Не заменяет Attribute. Не является Relation. Не является ACL. Не является проектом.

Он отвечает только за свою часть модели: административное состояние, связанное с объектом.

Именно поэтому его можно отделить от KObject. Граница проходит по вопросу: Относится ли это знание к тому, что представляет собой объект, или к тому, в каких административных условиях он находится?

В первом случае речь идёт о самом объекте и его описании.

Во втором — о KContext.

22.19. Главный вывод

KContext существует отдельно не потому, что система требует ещё одну таблицу.

Он существует потому, что объект и условия его административного существования — разные сущности.

KObject отвечает за сам факт существования объекта.

KContext отвечает за административное состояние, связанное с этим объектом.

При этом KObject не знает о KContext. Связь направлена в другую сторону: KContext знает, к какому KObject он относится.

Это позволяет сохранить независимость фундаментального объекта от механизма его административного управления.

Логически объект первичен, контекст вторичен. Но технически в системе они создаются атомарно: активный KObject должен иметь активный KContext. Нельзя создать самостоятельный KContext без объекта и нельзя оставить активный объект без контекста.

Изменение контекста не является изменением самого объекта. Смена владельца не создаёт новый KObject. Смена группы не создаёт новую Revision. Изменение административного состояния не меняет Definition.

А производные представления прав строятся отдельно от самого объекта.

Так разделяются три разных уровня:

KObject
    ↓
что существует

KContext
    ↓
в каких административных условиях существует

Projection
    ↓
кому и как это доступно

Это разделение позволяет системе сохранять независимость объекта от его административной истории и одновременно хранить эту историю полностью.

В следующей главе: какие правила делают неправильные состояния модели невозможными? Если KObject, KAttribute, KContext и другие сущности имеют строгие отношения между собой, где проходят границы допустимого состояния системы?

Глава 23. Инварианты модели: почему неправильное состояние невозможно

23.1. От философии к формальным правилам

На протяжении всей книги мы выстраивали модель мира.

Объект существует до своего описания. Описание изменяется, объект остаётся тем же. Исполнение является самостоятельным объектом. Экземпляр отличается от типа. Контекст существует отдельно от объекта. Связь является самостоятельной сущностью. Атрибут является утверждением, имеющим собственную историю.

Но философия без формальных правил остаётся пожеланием.

Модель данных становится защитой только тогда, когда она содержит инварианты — формальные утверждения о том, какие состояния системы допустимы, а какие нет.

Инвариант говорит не: «пользователю не следует делать этого».

Он говорит: «модель не должна позволять существовать такому состоянию».

Это принципиальное различие. Правило ограничивает действие. Инвариант ограничивает состояние.

23.2. Инвариант первый: объект первичен

KObject существует
        ↓
другие сущности относятся к нему

Но не наоборот.

KContext относится к KObject.

KAttribute относится к объекту, которому принадлежит утверждение.

KDefinition относится к объекту, который описывает.

KRelation связывает существующие объекты.

В допустимом состоянии модели зависимая сущность не может существовать без объекта или сущности, к которой она относится.

Это не означает, что все эти связи обязательно физически реализованы одним внешним ключом в одной базе данных. В распределённой системе разные части модели могут находиться в разных сервисах.

Инвариант определяет смысл допустимого состояния, а способ его обеспечения зависит от границы ответственности.

23.3. Инвариант второй: объект не смешивается со своим содержанием

KObject
    id: 12345

Сам KObject не хранит имя, описание, владельца, Revision или значение свойства.

Это не означает, что система ничего не знает об объекте.

Наоборот.

Вся информация о нём существует вокруг KObject:

KObject: 12345
    |
    ├── KProduct
    ├── KDefinition
    ├── KAttribute
    ├── KContext
    └── KRelation

Каждая из этих сущностей отвечает на свой вопрос. Что это за тип объекта? Как он описан? Какими свойствами он обладает? В каких административных условиях существует? С какими объектами связан?

Сам KObject не должен превращаться в контейнер для всех этих сведений. Это защищает модель от смешения разных понятий.

23.4. Инвариант третий: Revision принадлежит описанию

Revision не принадлежит непосредственно KProduct. Revision принадлежит KDefinition.

KProduct
    │
    └── KDefinition
            │
            ├── Revision A
            ├── Revision B
            └── Revision C

Это означает, что изменение описания не записывается как изменение самого объекта.

Если конструктор изменил чертёж, это изменение Revision.

Если изменилось описание изделия, это изменение Definition.

Если изменилось само изделие как самостоятельный объект инженерного учёта, это уже другой объект.

Граница между этими случаями определяется не названием поля revision, а структурой модели.

Что это предотвращает?

Ситуацию, в которой одна и та же сущность одновременно означает изделие, его описание и версию описания.

23.5. Инвариант четвёртый: изменение, нарушающее взаимозаменяемость, не является Revision

Это следствие предыдущего принципа.

Если изменение сохраняет критерий взаимозаменяемости, оно может быть отражено новой Revision существующего описания.

Если изменение нарушает взаимозаменяемость, оно относится уже к другому объекту.

Упрощённо:

тот же объект
      │
      └── изменение описания
              ↓
          Revision

другой объект
      │
      └── изменение,
          нарушающее взаимозаменяемость

Revision не является универсальным механизмом записи любого изменения. Она предназначена для изменения описания.

Это предотвращает ситуацию, когда разные инженерные объекты начинают существовать под одной и той же сущностью только потому, что система умеет хранить версии.

23.6. Инвариант пятый: KContext не существует без KObject

KContext всегда относится к конкретному KObject.

KObject: 12345
      ↑
      │ target_object_id
      │
KContext

Нельзя иметь контекст, который не относится ни к одному объекту.

Но здесь важно сделать различие между логическим инвариантом и способом его реализации.

В распределённой архитектуре KObject и KContext могут принадлежать разным сервисам и находиться в разных базах данных.

Поэтому Context Service не может поставить обычный PostgreSQL FOREIGN KEY на таблицу KObject, если эта таблица принадлежит другой базе.

Тем не менее правило остаётся: KContext допустим только для существующего KObject.

Это уже системный инвариант. Он обеспечивается границами сервисов, API регистрации объекта и протоколом создания контекста, а не одним внешним ключом.

23.7. Инвариант шестой: атрибут является временным утверждением

KAttribute
    object: 12345
    type: material
    value: 09Г2С
    valid_from: 01.06.2031
    source: конструктор Петров
    basis: извещение №45

Атрибут не является просто значением. Он фиксирует утверждение:

у объекта было такое значение в определённый период, полученное из определённого источника и на определённом основании.

Поэтому атрибут не должен существовать без объекта, к которому он относится. Он также не должен терять временную информацию.

Что это предотвращает?

Ситуацию, в которой система знает только:

material = 09Г2С

но не знает:

• когда это значение стало действующим;
• когда перестало быть действующим;
• откуда оно получено;
• на каком основании появилось.

Для PLM это принципиально. Без времени система хранит последнее значение. С временем она хранит историю инженерного знания.

23.8. Инвариант седьмой: связь имеет смысл

KRelation
    from: KObject 12345
    to: KObject 67890
    type: contains

Связь не является произвольной парой идентификаторов. Она имеет тип и смысл.

Не каждая связь допустима между любыми объектами. Например:

KProduct ──contains──> KProduct

может быть допустимой связью структуры изделия. А произвольное:

KUser ──contains──> KProduct

не приобретает инженерного смысла только потому, что технически два идентификатора существуют.

Следовательно, модель должна определять:

• какие типы связей существуют;
• какие объекты они соединяют;
• какие атрибуты принадлежат связи;
• какие ограничения действуют для конкретного типа связи.

Это защищает систему от отношений, которые технически можно записать, но которые не имеют смысла в предметной области.

23.9. Инвариант восьмой: исполнение является объектом

Исполнение является самостоятельным объектом.

Не набором параметров. Не строкой конфигурации. Не комбинацией выбранных опций.

KPExecutionGroup
    │
    ├── KProduct — исполнение 1
    ├── KProduct — исполнение 2
    └── KProduct — исполнение 3

У каждого исполнения есть собственное существование в модели. Это позволяет связать его с определением, документацией, структурой, атрибутами и другими объектами.

Что это предотвращает?

Ситуацию, когда производство получает условное:

«изготовить конфигурацию 047»

но в системе не существует самостоятельного объекта, который можно однозначно определить, описать и проследить.

23.10. Почему инварианты сильнее правил

Традиционная система часто работает следующим образом.Пользователь нажимает кнопку.

Система проверяет: допустимо ли это действие? Если нет — показывает ошибку.

Но интерфейс является внешним ограничением. Можно вызвать API напрямую. Можно импортировать данные из файла. Можно использовать другой клиент. Можно написать интеграцию, которая никогда не видела пользовательского интерфейса.

Поэтому настоящая защита должна находиться глубже интерфейса.

Инвариант говорит: это состояние системы недопустимо.

Но здесь необходимо сделать ещё одно уточнение.

Инвариант может быть обеспечен на разных уровнях.

уровень базы данных
        ↓
FK / UNIQUE / CHECK / ограничения

уровень сервиса
        ↓
транзакция / агрегат / API

уровень системы
        ↓
несколько сервисов /
протокол взаимодействия /
события / синхронизация

Поэтому фраза «инвариант делает состояние невозможным» означает:

система в целом не должна допускать такое состояние как допустимое состояние модели.

Это не всегда означает наличие одного SQL-ограничения, физически блокирующего запись.

23.11. Инвариант и граница сервиса

До этого момента мы рассматривали инвариант как свойство модели данных. Но в распределённой системе разные части одной модели могут находиться в разных сервисах и разных базах данных. В этом случае один PostgreSQL уже не способен выразить весь инвариант через внешний ключ.

Это не отменяет инвариант. Меняется место его обеспечения.

Часть инварианта может быть обеспечена структурой локальной модели. Другая часть — границей сервиса и его API. Ещё часть — согласованным взаимодействием нескольких сервисов.

Поэтому необходимо различать инвариант модели и механизм его реализации.

Инвариант отвечает на вопрос:

какое состояние системы допустимо?

Архитектура отвечает на другой вопрос:

где и каким механизмом это состояние обеспечивается?

Модель
   ↓
Инварианты
   ↓
границы ответственности
   ↓
локальные ограничения
   +
межсервисные правила

Это различие принципиально для распределённой архитектуры. Предположим:

                 Object Registry
                       │
                     KObject
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
       Design       Context       Relation
       Service      Service       Service
          │            │            │
     Definition     KContext      KRelation
      Revision

Каждый сервис владеет своей частью знания.

Design Service отвечает за Definition и Revision.

Context Service отвечает за KContext.

Relation Service отвечает за отношения.

Но объект остаётся одним и тем же объектом системы.

Поэтому инварианты должны существовать на двух уровнях.

Локальный инвариант может быть физически закреплён внутри одной транзакционной границы.

Например:

Revision → KDefinition

Если оба объекта находятся в одной базе, это может быть обеспечено внешним ключом.

Распределённый инвариант пересекает границы сервисов. Например:

KContext → KObject

Если KObject принадлежит Object Registry, Context Service не может использовать обычный FK к чужой базе.

Тогда инвариант обеспечивается самим протоколом системы:

регистрация KObject
        ↓
получение допустимого object_id
        ↓
создание KContext
        ↓
Context Service принимает только
существующий зарегистрированный объект

Так появляется важное архитектурное правило: граница сервиса не отменяет инвариант. Она определяет, каким способом этот инвариант обеспечивается.

Это и есть отличие модели от конкретной схемы базы данных.

Распределённый инвариант не означает, что каждый сервис знает всю модель. Он означает, что несколько сервисов совместно обеспечивают одно правило, каждый в пределах своей ответственности.

23.12. Кто отвечает за инвариант

В распределённой системе нельзя сказать, что «вся система отвечает за всё».

Это быстро приводит к ситуации, когда ни один сервис фактически ни за что не отвечает. Каждый инвариант должен иметь определённую границу ответственности.

Например:

Object Registry
    ↓
существование KObject

Design Service
    ↓
Definition / Revision

Context Service
    ↓
KContext и его административное состояние

Relation Service
    ↓
допустимые отношения

Сервис не должен произвольно изменять сущности другого сервиса. Он использует определённый интерфейс взаимодействия с владельцем соответствующего знания.

Так модель данных превращается в архитектурный принцип: границы знания определяют границы ответственности.

23.13. Инварианты и проекции

Есть ещё один слой модели, который возникает поверх основных объектов.

Основная модель хранит факты. Например:

KObject
KContext
KRelation
KAttribute

Но системе необходимо быстро отвечать на другой вопрос: может ли данный пользователь выполнить данное действие над этим объектом?

Для этого из основной модели строятся производные представления — проекции.

Упрощённо:

Основная модель
      │
      ├── KContext
      ├── KRelation
      ├── KAttribute
      └── другие данные
              │
              ▼
          события
              │
              ▼
          проекции
              │
              ├── object scope
              └── effective permissions

Проекция не становится новым источником истины. Она является производным представлением основной модели, подготовленным для конкретной задачи.

Это важно и для прав доступа.

KContext может содержать владельца и группу владения. Из этих и других данных строится область доступа объекта.

Из области доступа и назначенных прав формируется эффективное представление разрешений. Таким образом:

факты
  ↓
административное состояние
  ↓
проекции
  ↓
решение о доступе

Права не превращаются в свойства KObject. И изменение проекции не изменяет сам объект.

Это ещё один пример того, как одна модель может иметь несколько уровней представления, сохраняя единую семантику исходных данных.

23.14. Почему инварианты важны для долгоживущей системы

PLM-система может существовать десятилетиями.

Люди, которые её создавали, уходят. Меняются команды. Меняются технологии. Меняются интерфейсы. Меняются интеграции.

Но данные остаются.

Если допустимость состояния зависит только от знания конкретного разработчика, это знание постепенно теряется.

Если же оно закреплено в модели, система продолжает сохранять смысл данных. Через десять лет новый инженер должен понимать:

Revision — как Revision описания.

KContext — как административное состояние, связанное с объектом.

KAttribute — как временное утверждение.

KRelation — как типизированную связь.

KObject — как фундаментальный факт существования объекта.

Смысл не должен восстанавливаться из воспоминаний людей.

Он должен следовать из структуры модели.

23.15. Практический пример

Рассмотрим создание изделия.

Сначала система регистрирует объект.

KObject: 12345

Затем вместе с ним фиксируется его первоначальный административный контекст.

KObject: 12345
      ↑
KContext
      owner: Иванов
      group: Группа А

Затем появляется описание:

KObject: 12345
      │
      └── KDefinition
              │
              └── Revision A

Позже создаётся Revision B.

Объект остаётся тем же.

Затем появляются атрибуты.

KAttribute
    material = 09Г2С
    valid_from = ...

Затем возникают отношения с другими объектами.

KRelation
    KObject 12345
        │
        └── contains
                ↓
           KObject 67890

На каждом уровне модель не просто хранит запись.

Она фиксирует смысл.

Нельзя создать Revision без Definition.

Нельзя создать KContext без объекта.

Нельзя создать атрибут без объекта.

Нельзя создать отношение без связанных объектов и допустимого типа связи.

Именно совокупность этих ограничений создаёт целостную модель.

23.16. Что это предотвращает

Инварианты защищают не от ошибок интерфейса. Они защищают от ошибок смысла.

Без них система может содержать: Revision изделия, которой на самом деле является Revision документа.

Или: Context, который не относится ни к одному объекту.

Или: Attribute, для которого неизвестно, когда и откуда появилось значение.

Или: Relation, которая технически существует, но не имеет допустимого инженерного смысла.

Или: два разных инженерных объекта, записанных как один объект только потому, что система не различает изменение описания и изменение самого объекта.

Каждая такая ошибка может быть технически представлена в слабой модели.

В строгой модели для неё просто нет допустимого места.

23.17. Главный вывод

Инварианты являются формальным выражением модели мира.

Они говорят:

• объект существует независимо от своего содержания;
• зависимые сущности относятся к существующим объектам;
• Revision относится к описанию;
• изменение описания не смешивается с изменением самого объекта;
• KContext относится к KObject;
• атрибут хранит не только значение, но и время его действия;
• отношение имеет тип и инженерный смысл;
• исполнение является самостоятельным объектом.

Но в распределённой системе необходимо понимать слово «невозможно» правильно.

В одной базе данных невозможность может быть физически закреплена внешним ключом или другим ограничением.

В микросервисной системе часть инвариантов пересекает границы баз данных. Тогда они становятся распределёнными инвариантами и обеспечиваются совокупностью сервисов, их интерфейсов и протоколов взаимодействия.

Это не ослабляет модель.

Наоборот, это позволяет сохранить её смысл независимо от способа физического размещения данных. В результате модель данных выполняет гораздо более важную функцию, чем простое хранение информации.

Она определяет: какие состояния мира система вообще признаёт возможными.

Именно поэтому правильная модель способна сохранять смысл данных даже тогда, когда меняются приложения, сервисы, интерфейсы и люди, которые эти системы создавали.

В следующей главе: когда объект перестаёт существовать? Что происходит с объектом после завершения его жизненного цикла и почему «объект больше не существует» не означает «объекта никогда не существовало».

Глава 24. Когда объект перестаёт существовать?

24.1. Начало и конец существования

До сих пор мы в основном говорили о том, как объект появляется в системе.

Создаётся KObject. Для него создаётся административный контекст. Появляется описание. Появляются атрибуты, связи, изменения.

Но у любого объекта есть и другая сторона жизненного цикла. Он может быть закрыт. Изделие снято с производства. Документ выведен из действия. Проект завершён. Группа закрыта. Экземпляр больше не существует как действующий объект.

Возникает простой вопрос: Что должна сделать система с объектом, когда его существование заканчивается?

Самый простой ответ — удалить запись. Но для инженерной системы это неправильный ответ.

Удаление означает: такого объекта больше нет в базе.

Закрытие означает другое: объект существовал, но его активное существование завершилось.

Это принципиальная разница.

24.2. Удаление и закрытие — не одно и то же

Представим насос Н1. Он был зарегистрирован в 2026 году. В 2038 году его эксплуатация закончилась. Если удалить запись:

KObject 12345
    ↓
DELETE

система больше не знает, что такой объект когда-либо существовал.

Но инженерная история не исчезает вместе с окончанием эксплуатации. В 2039 году может возникнуть вопрос:

Какой насос был установлен на этой площадке в 2032 году?

Или:

Какая Revision использовалась при изготовлении этого экземпляра?

Или:

Кто отвечал за объект до его закрытия?

Если объект физически удалён из модели, ответить на эти вопросы невозможно.

Поэтому завершение существования объекта должно быть отдельным состоянием жизненного цикла.

создан
   ↓
существует
   ↓
изменяется
   ↓
закрыт

История при этом сохраняется.

24.3. KObject не исчезает из истории

KObject является фундаментальным фактом существования объекта.

Поэтому завершение жизненного цикла не означает уничтожение этого факта. Упрощённо:

KObject 12345
    │
    ├── существовал
    │
    ├── имел описание
    │
    ├── имел атрибуты
    │
    ├── имел контекст
    │
    ├── имел связи
    │
    └── был закрыт

После закрытия объект больше не является активным. Но его история остаётся частью системы.

Это позволяет отличить два совершенно разных утверждения:

объект не существует сейчас

и

объект никогда не существовал

Первое является нормальным состоянием жизненного цикла. Второе означает отсутствие самого факта.

Для PLM эти утверждения нельзя смешивать.

24.4. Что происходит с KContext

Закрытие объекта не означает, что его KContext превращается в бессмысленную запись. Контекст также имеет собственный временной интервал. Его активное состояние заканчивается.

KObject 12345
      ↑
      │
KContext
    valid_from: 2026
    valid_to:   2038

После этого контекст больше не является действующим. Но он остаётся историческим свидетельством того, в каких административных условиях объект существовал.

Это особенно важно для аудита. Система должна иметь возможность восстановить не только:

какой объект существовал?

но и:

в каком административном состоянии он находился в определённый момент?

Поэтому закрытие не уничтожает временную историю. Оно завершает её.

24.5. Что происходит с атрибутами

То же относится к атрибутам.

Если объект закрыт, его прежние значения не должны исчезать только потому, что объект больше не активен. Например:

KAttribute
    material = 09Г2С
    valid_from = 2027
    valid_to = 2038

После закрытия объекта это утверждение не становится ложным. Оно остаётся исторически верным. Вопрос:

Из какого материала был изготовлен насос Н1?

не становится бессмысленным только потому, что насос больше не эксплуатируется.

Исторические данные продолжают иметь значение.

24.6. Закрытие не создаёт новый объект

Здесь возникает ещё одно важное следствие.

Если объект закрывается, система не должна создавать вместо него новый KObject только потому, что его активное существование завершилось.

KObject 12345
    ↓
closed

а не:

KObject 12345
    ↓
deleted

KObject 67890
    ↓
бывший KObject 12345

Если инженерный объект тот же, его закрытие не меняет сам факт того, каким объектом он был. Новое состояние жизненного цикла не является новым объектом.

Это позволяет сохранить непрерывность истории.

24.7. Закрытие и изменение объекта

Необходимо также различать закрытие и изменение.

Если изменилось описание изделия, появляется новая Revision.

Если изменилось административное состояние, изменяется KContext.

Если объект перестал быть действующим, завершается его жизненный цикл.

Это три разных события.

изменение описания
        ↓
Revision

изменение административного состояния
        ↓
KContext

завершение существования
        ↓
закрытие KObject

Именно разделение этих событий позволяет не смешивать историю объекта с историей его описания и административного управления.

24.8. Закрытие и права доступа

Закрытие объекта также должно иметь последствия для административного управления.

После закрытия объект не должен продолжать вести себя как обычный активный объект. Это означает, что механизмы доступа должны учитывать состояние жизненного цикла.

Упрощённо:

активный объект
      ↓
обычные правила доступа

закрытый объект
      ↓
исторический объект
      ↓
ограниченный режим работы

Конкретные правила доступа зависят от политики системы. Но принцип остаётся:

закрытие объекта меняет его участие в текущем административном состоянии, но не уничтожает исторические данные.

24.9. Закрытие и проекции

Здесь снова появляется разделение основной модели и производных представлений.

Если объект закрыт, проекции, построенные для текущего состояния системы, должны перестать считать его активным объектом.

Например, объект больше не должен появляться среди текущих объектов пользователя только потому, что когда-то принадлежал его группе.

При этом исторические данные могут продолжать существовать. Получается два разных вопроса:

текущее состояние
        ↓
проекции активной модели

историческое состояние
        ↓
временные данные модели

Проекция не должна уничтожать историю. Она должна отражать актуальное состояние.

24.10. Закрытие и аудит

Для долгоживущей системы закрытие является событием, которое само должно быть прослеживаемым.

Нужно понимать:

• какой объект был закрыт;
• когда это произошло;
• кто инициировал операцию;
• в каком состоянии объект находился до закрытия.

Это особенно важно для конфигурационного управления.

Через несколько лет нельзя ограничиться ответом: «этого объекта сейчас нет».

Необходимо иметь возможность установить: объект существовал, использовался, имел определённое описание и определённый административный контекст, после чего его жизненный цикл был завершён.

24.11. Почему это важно для PLM

PLM работает не только с настоящим. Его задача — сохранять историю продукта на протяжении всего жизненного цикла.

Поэтому система должна одинаково хорошо отвечать на два вопроса:

Что существует сейчас?

и

Что существовало тогда?

Если система умеет только первое, она является текущим реестром. Если она умеет второе, появляется возможность инженерной прослеживаемости.

Например:

2032 год
   │
   ├── объект
   ├── Definition
   ├── Revision
   ├── Attribute
   ├── Relation
   └── Context

Даже если в 2040 году объект уже закрыт, система должна иметь возможность восстановить состояние, которое существовало в 2032 году.

Это одна из причин, почему временность проходит через разные уровни модели.

24.12. Главное различие

Вся глава может быть сведена к одному различию:

Удаление
    ↓
факт исчезает

Закрытие
    ↓
активное существование заканчивается
    ↓
история сохраняется

Для обычного приложения разница может показаться технической. Для инженерной системы она фундаментальна.

Изделия выводятся из эксплуатации. Документы отменяются. Проекты завершаются. Экземпляры перестают существовать.

Но прошлое не исчезает.

24.13. Связь с предыдущими главами

Глава 20 установила: KObject фиксирует факт существования. Он не содержит свойств, описания или контекста.

Глава 22 установила: KContext хранит административное состояние, связанное с объектом, и имеет собственное время действия.

Глава 24 добавляет: завершение жизненного цикла объекта является состоянием модели, а не уничтожением факта существования.

Вместе эти выводы формируют последовательную картину:

KObject
    │
    ├── создан        → факт существования зафиксирован
    ├── активен       → участвует в текущем состоянии системы
    ├── изменяется    → Revision, KContext, KAttribute
    └── закрыт        → исторический факт сохраняется

Закрытие не отменяет ни одного из предыдущих состояний.

Оно добавляет к ним последнее.

24.14. Главный вывод

Объект может перестать существовать как активный объект, но это не означает, что он перестаёт существовать как исторический факт.

Поэтому завершение жизненного цикла не должно быть обычным удалением записи. KObject сохраняет факт существования объекта. Его KContext сохраняет историю административных условий. Атрибуты сохраняют исторические утверждения. Definition и Revision сохраняют историю описания. Relations сохраняют историю связей.

Производные проекции отражают текущее состояние и могут исключать закрытые объекты из активных представлений. В результате система может одновременно хранить два состояния:

что существует сейчас

и

что существовало в прошлом

Это и есть принципиальная разница между системой, которая просто хранит текущие данные, и системой, которая сохраняет историю инженерного мира.

Закрытие завершает активное существование объекта. Оно не отменяет факт того, что объект существовал.

Примечание автора

В этой главе намеренно не вводится отдельная сущность для «истории удаления». История закрытого объекта формируется существующей моделью временных данных и жизненного цикла. Конкретный механизм закрытия и каскадного завершения связанных сущностей является частью реализации, а не отдельным понятием модели данных.

Эпилог

Мы начали с простого вопроса: что такое объект? И пришли к модели, которая позволяет системе сохранять смысл данных на протяжении десятилетий.

Э.1. От вопроса к модели

Мы начали с простого вопроса: Что такое объект?

На него оказалось недостаточно ответить одним классом или одной таблицей.

Объект должен быть зарегистрирован.

У него должно быть описание.

Описание может изменяться.

Его свойства имеют время и историю.

Он существует в определённых административных условиях.

Он связан с другими объектами.

Он может иметь разные представления и участвовать в разных процессах.

И однажды его активное существование заканчивается.

Но ни одно из этих изменений само по себе не должно стирать историю объекта. Из этого постепенно сложилась модель.

KObject
   │
   ├── Definition
   │       └── Revision
   │
   ├── Attribute
   │
   ├── KContext
   │
   └── KRelation

Это не набор таблиц. Каждая сущность отвечает на свой вопрос.

KObject — какой объект существует.

Definition — как этот объект описан.

Revision — какая версия этого описания действовала.

KAttribute — какое утверждение об объекте было справедливо и когда.

KContext — в каких административных условиях объект существовал.

KRelation — с какими другими объектами он связан и каким образом.

А инварианты определяют, какие сочетания этих сущностей вообще имеют смысл.

Э.2. Разделение, которое сохраняет смысл

В результате модель позволяет отделить то, что в традиционных системах часто оказывается смешано:

• объект
• описание
• свойство
• контекст
• связь
• история
• права

Это разделение важно не ради красоты модели. Оно необходимо потому, что инженерные данные живут десятилетиями.

Изделие меняется. Его описание меняется. Меняются люди и организации. Закрываются проекты. Появляются новые Revision. Меняются свойства. Меняются связи.

Но прошлое не должно исчезать только потому, что настоящее стало другим. Именно поэтому главный вопрос такой системы — не только:

Что существует сейчас?

но и:

Что существовало тогда?

Какой объект? С каким описанием? С какой Revision? С какими свойствами? В каком административном состоянии? С какими связями?

И на каком основании мы сегодня утверждаем, что всё было именно так?

Э.3. Модель как фундамент

Если модель способна ответить на эти вопросы, она становится основой не только для одной прикладной системы.

На такой модели можно строить разные классы инженерных информационных систем: PLM, системы управления конфигурацией, ERP и другие системы, которым необходимо сохранять сложные взаимосвязанные данные на протяжении длительного жизненного цикла.

При этом сама модель не является готовой прикладной программой. Она находится уровнем ниже.

Это описание того, как должны быть устроены данные и отношения между ними, чтобы поверх них можно было строить различные системы.

Именно поэтому разработка модели данных — это не вспомогательная работа перед программированием. Это проектирование самого фундамента будущей системы.

Э.4. Объект 12345

Теперь вернёмся к первоначальному вопросу.

Что такое объект?

Пусть в системе действительно существует объект 12345.

KObject: 12345

Спустя годы уже не так важно, кто именно его создал и каким был первый интерфейс системы.

Важно другое. Система должна суметь ответить:

Что это за объект?

Как он был описан?

Какие Revision существовали?

Какие свойства были у него тогда?

В каком контексте он находился?

С какими объектами был связан?

Что с ним произошло?

И почему система знает, что это именно тот объект?

Если модель отвечает на эти вопросы — она выполняет свою задачу. Потому что в конечном счёте вся сложная архитектура нужна для одной простой вещи:

не потерять смысл данных со временем.

Э.5. Откуда появилась эта книга

Эта книга написана не как отвлечённое исследование модели данных. Она появилась по следам реальной разработки.

Именно практическая работа заставляет проверять красивые идеи на конкретных объектах, связях, изменениях, правах, истории и ошибках, которые невозможно увидеть на диаграмме.

Некоторые решения в книге выглядят очевидными только после того, как пройден путь до них.

За каждым таким решением стоит вопрос: что произойдёт с моделью через пять, десять или двадцать лет?

Именно этот вопрос был главным ориентиром при её создании.

Э.6. Возвращение к началу

Поэтому книга заканчивается там же, где всё начиналось.

С объектом.

Например, с объектом 12345.

Он просто существует.

А всё остальное — описание, свойства, связи, контекст, изменения и история — должно помочь системе точно рассказать, что это за объект, каким он был и что с ним происходило.

В этом и состоит смысл модели.

Конец книги.

Для тех, кто хочет заглянуть под капот — KContext Service.

использовать:

Термины