ГОСТ Р 58908.1-2020/МЭК 81346-1:2009. Национальный стандарт Российской Федерации. Промышленные системы, установки, оборудование и промышленная продукция. Принципы структурирования и коды. Часть 1. Основные правила

Приложение C

(справочное)

 

ОБРАЩЕНИЕ С ОБЪЕКТАМИ

 

C.1 Общие положения

 

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

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

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

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

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

 

C.2 Создание и срок службы объекта

 

C.2.1 Общие положения

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

Таким образом, объект может быть создан с достаточно неполным пониманием того, чем он должен стать. В самом простом случае он является просто "заполнителем" для информации, которому присваивается имя и, возможно, он идентифицируется посредством кодового обозначения в контексте разрабатываемой системы. Данный заполнитель используется для сбора информации в процессе проектирования и разработки системы. Подобная "пустая" структура может быть расширена, например, для использования в качестве шаблона.

Как следствие этого, и особенно, если в работе участвуют несколько проектировщиков, вполне вероятно, что в системе объекты, которые очень тесно связаны или даже "одинаковы", определяются с точки зрения разных аспектов. Необходимо находить подобные близкие связи и устранять возможные повторы. См. C.2.3.

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

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

C.2.2 Реализация объекта

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

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

Примечание 1 - Ничто не мешает такому объекту быть идентифицированным из нескольких аспектов и адресованным системой кодовых обозначений. Для упрощения принимают, что участвует только один объект.

 

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

Необходимо интегрировать этот продукт как компонент рассматриваемой системы. Существует только два способа интегрировать эту информацию:

- Путем копирования. Информация, связанная с продуктом, копируется (частично или полностью по мере необходимости) в информацию, связанную с существующим объектом в системе (см. рисунок C.1).

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

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

 

 

Рисунок C.1 - Интеграция внешней информации

путем копирования

 

- Путем ссылки. На информацию, связанную с продуктом, ссылаются посредством идентификационного номера продукта, который, в свою очередь, ссылается на связанную с ним информацию (см. рисунок C.2).

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

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

 

 

Рисунок C.2 - Интеграция внешнего объекта путем ссылки

 

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

C.2.3 Отношения между тесно связанными объектами

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

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

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

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

См. рисунок C.3.

 

 

Рисунок C.3 - Три независимо определенных объекта

 

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

Есть два возможных, принципиально разных, подхода к данной проблеме:

- Разработчик решает, что эти три объекта должны оставаться отдельными в процессе разработки и проектирования. Их отношения должны быть описаны и поддерживаться, например, в используемой автоматизированной системе проектирования (см. рисунок C.4). К объектам обращаются с использованием трех различных кодовых обозначений. См. также C.2.4.

 

 

Рисунок C.4 - Три отдельных объекта с общими отношениями

 

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

 

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

- Разработчик решает, что три исходных объекта настолько тесно связаны, что их можно рассматривать как один. Информация, связанная с тремя объектами, затем объединяется и связывается с одним объектом. Информация должна быть соответствующим образом идентифицирована в общем контексте. Полученный объект рассматривается с помощью системы кодовых обозначений, состоящей из кодовых обозначений, которые имели исходные объекты (см. рисунок C.5).

 

 

Рисунок C.5 - Три объекта объединены в один

 

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

 

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

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

C.2.4 Роль набора кодовых значений

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

Очевидно, что набор кодовых обозначений может быть применен к "объединенному объекту", как описано выше и показано на рисунке C.5. В данном случае набор кодовых обозначений предоставляет альтернативные "адреса" для рассматриваемого объекта, причем все они в равной степени действительны.

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

C.2.5 Пример

Чтобы пояснить вышеприведенные принципы более конкретно, приведен следующий пример (см. рисунок C.6).

 

 

Рисунок C.6 - Представление технологической системы

 

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

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

Щит помещен в комнате. Комната является одной из нескольких комнат в здании с несколькими этажами.

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

 

 

Рисунок C.7 - Древовидные структуры технической системы

 

Переключение и защита

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

Автоматический выключатель

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

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

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

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

Щит

Объект "щит" также можно рассматривать с точки зрения более чем одного аспекта:

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

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

- Также он дает информацию о том, сколько пространства требуется щиту или сколько пространства он занимает.

Комната

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

На рисунке C.8 показаны более завершенные структуры системы.

 

 

Рисунок C.8 - Завершенные структуры технической системы

 

На рисунке C.9 показаны соответствующие объекты системы с одноуровневыми кодовыми обозначениями.

 

 

Рисунок C.9 - Структуры с обозначенными подобъектами

 

Рисунок C.9 также иллюстрирует случай, когда структуры были определены независимо друг от друга (ср. с рисунком C.3).

Для объединенных объектов (ср. с рисунком C.5). Можно считать, что:

- требуемая функция переключения (=QA1) обеспечивается функцией переключения (=Q1), предоставляемой автоматическим выключателем (-QA1);

- требуемая защитная функция (=FC1) обеспечивается защитной функцией (=F1), предоставляемой автоматическим выключателем (-QA1);

- требуемое пространство для щита (-UC1) определяется доступным пространством (+U1) в комнате (+R2).

Поэтому каждый из этих двух объектов может быть объединен в один, который содержит информацию как о требуемых, так и о фактических данных и к которому можно обратиться из обеих структур (см. рисунок C.10).

 

 

Рисунок C.10 - Структуры с объединенными и общими объектами

 

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

 

Таблица C.1

 

Возможные системы кодовых обозначений

 

Объект	Оба кодовых обозначения однозначны, к объединенному объекту можно обратиться из обеих структур	Только одно кодовое обозначение однозначное, второе отсылается к другому объекту, иерархически связанному с указанным объектом
Переключение	=WP1=WC1=QA1 -UC1-QA1=Q1	=WP1=WC1=QA1 -UC1-QA1...
Защита	=WP1=WC1=FC1 -UC1-QA1=F1	=WP1=WC1=FC1 -UC1-QA1...
Щит	-UC1 +B1+S3+R2+U1	-UC1 +B1+S3+R2...

 

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

Вторая графа таблицы C.1 может быть пояснена с помощью рисунка C.11.

 

 

Рисунок C.11 - Отношения, выраженные системами кодовых

обозначений, в которых оба обозначения однозначны

 

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

 

 

Рисунок C.12 - Отношения, выраженные системами кодовых

обозначений, одно обозначение которых неоднозначно

 

C.3 Ситуации, возникающие на протяжении жизненного цикла

 

C.3.1 Один объект для всех аспектов

Рисунок C.13 иллюстрирует ситуации в начале жизненного цикла объекта.

 

 

Рисунок C.13 - Ситуации в начале

жизненного цикла объекта, рассматриваемые

с точки зрения трех аспектов

 

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

Вторая ситуация показывает, что продукт, удовлетворяющий требованиям в качестве компонента, был обнаружен. Ссылка на внешнюю спецификацию продукта описана в C.2.2 и проиллюстрирована на рисунке C.2.

Примечание 1 - Термин "спецификация продукта" относится здесь к набору документов/информации, который описывает продукт со всех соответствующих аспектов, включая свойства, дополнительные документы и т.д. См. МЭК 62023.

 

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

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

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

 

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

C.3.2 Один объект для каждого аспекта

Рисунок C.14 аналогичным образом иллюстрирует ситуацию, когда объекты, определенные в различных структурах, хранятся отдельно, как описано в C.2.3 и показано на рисунке C.4.

 

 

Рисунок C.14 - Ситуации в начале жизненного цикла тесно

связанных объектов, каждый из которых доступен с точки

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

 

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

Вторая ситуация: компонентный объект был создан и идентифицирован в ориентированной на продукт структуре рассматриваемой системы. Этот объект имеет перекрестные ссылки на предыдущий функциональный объект.

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

- Объект в функционально-ориентированной структуре, который остается таким, какой он есть.

- Объект в ориентированной на продукт структуре со ссылкой на внешнюю спецификацию продукта, как описано в C.2.2 и показано на рисунке C.2.

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

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

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