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

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

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