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

Глава 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.

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