ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИ И

Системы промышленной автоматизации и интеграция

БИБЛИОТЕКА ДЕТАЛЕЙ

Часть 31

Ресурсы реализации.

Интерфейс геометрического программирования

ISO 13584-31:1999 Industrial automation systems and integration — Parts library — Part 31: Implementation resources: Geometric programming interface

(IDT)

Издание официальное

Москва Ста ндартин форм 2016

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о стандарте

1    ПОДГОТОВЛЕН Научно-техническим центром ИНТЕК на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный

менеджмент»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 21 декабря 2010 г. № 874-ст

4    Настоящий стандарт идентичен международному стандарту ИСО 13584-31:1999 «Системы промышленной автоматизации и интеграция. Библиотека деталей. Часть 31. Ресурсы реализации. Интерфейс геометрического программирования» (ISO 13584-31:1999 «Industrial automation systems and integration — Parts library — Part 31: Implementation resources: Geometric programming interface»).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2016

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

мощности нумеруются: 1,2 и 3. Любой интерфейс /-го уровня мощности должен содержать все функции У-го уровня мощности для у < /. Таким образом, он может создавать виды У-го уровня геометрической мощности geometrical_power_level, если указанный уровень мощности установлен посредством инициализации вида. Для любой геометрической мощности интерфейса вид может быть также создан для уровня геометрической мощности geometrical_power_level, равного 0.

Определены три уровня реализации интерфейса (от 1 до 3). Все функции классифицированы в соответствии сданными уровнями. Рассматриваемая реализация должна обеспечивать (для выбранного приложения) все функции уровня, которому она принадлежит. Доступ к уровню интерфейса обеспечивается с помощью функции запроса.

5.1.2    Моделирование отсутствующих сущностей

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

5.2    Таблицы интерфейса

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

1)    таблица описаний интерфейса представляет все постоянные характеристики интерфейса (например, уровень интерфейса interface_level, характеристики невидимых линий hidden_line_capability и т. д.). Указанные значения запрашиваются прикладной программой, но не могут быть ею изменены. Эти значения зависят от реализации;

2)    таблица статуса интерфейса представляет значения модальных переменных (например, атрибуты визуализации). Начальное значение указанной переменной определено в настоящем стандарте либо как зависимое от вида (устанавливается в процессе инициализации интерфейса), либо как принимающее особые значения. Значения переменных таблицы статуса интерфейса запрашиваются прикладной программой. Они могут быть изменены прикладной программой за исключением переменных, зависящих от вида (например, единица длины вида view_length_unit, атрибут невидимых линий hiddenjine и т. д.).

Примечание — В первой версии настоящего стандарта уровень 3 соответствует созданию тел с неявной топологией (сущности твердого тела, очерчивание, булевы операции). Он известен как уровень «конструктивной блочной геометрии». В более поздних версиях создание явных топологических элементов (вершин, кромок, граней и т. д.) может быть представлено как уровень 4. Он известен как уровень «В-Rep» (уровень представления границ).

Описание содержимого таблиц интерфейса приведено в разделе 8.

5.3    Создание данных модели продукта

В настоящем подразделе приведена концепция создания геометрической модели внутри геометрической моделирующей системы с помощью прикладного программирования. В контексте библиотек деталей, соответствующих требованиям ИСО 13584, данный подраздел предназначен для разработчиков программного обеспечения библиотек деталей, создающих данные модели детали внутри некоторой системы CAD.

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

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

5.3.1 Ссылочные координатные системы видов (OVC)

Функциональный вид, созданный с помощью функций интерфейса, состоит из элементов геометрического представления geometric_representation_items. Каждый вид создается с помощью прикладного программирования внутри собственного контекста геометрического представления geometric_representation_context. Данный контекст называется координатной системой вида объекта object_view_modelling_coordinate_system (OVC). Прикладная программа не зависит от относительного 6

ГОСТ Р ИСО 13584-31—2010

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

Функция инициализации вида View_lnitialisation должна, следовательно, активизировать некоторый неописанный процесс позиционирования. На практике (в соответствии с особой философией CAD) процесс позиционирования может, например:

1)    определять новые локальные координатные системы, если CAD использует механизм создания экземпляров;

2)    подключать OVC к курсору для последующего позиционирования;

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

4)    вычислять правильное положение, если оно определяется положением экземпляра объекта, и инициализировать матрицу преобразования интерфейса;

5)    выполнять пустую операцию, если вид создан в начале глобальной координатной системы и позиционируется впоследствии пользователем CAD.

Если вид инициализирован как двухмерный, то 20-пространство является плоскостью координат х, у. В данном случае использование координаты z не имеет смысла для геометрических сущностей. Для них координата z равна 0.

Если данные библиотеки деталей удовлетворяют требованиям комплекса стандартов ИСО 13584 и несколько программ поставщика детали ссылаются на различные функциональные виды одной детали, то OVC, используемые в данных программах, зависят друг от друга. Абсолютная координатная система ассоциируется с деталью с помощью поставщика. Все программы поставщика детали, создающие функциональные ЗО-виды настоящей детали, должны использовать данную абсолютную координатную систему как их собственную OVC. Все программы поставщика детали, создающие функциональные 20-виды настоящей детали, должны:

1)    давать описание функционального 20-вида, созданного каждой программой поставщика детали, в соответствии со стандартом ИСО 128 (см. рисунок 1);

2)    выбирать в качестве OVC (для каждой программы поставщика детали) координатную систему, полученную из абсолютной координатной системы детали и из спецификации созданного функционального 20-вида (см. рисунок 1).

Bottom — вид снизу; right side — вид справа; leftside — вид слева; front— вид спереди; back— вид сзади; top — вид сверху Рисунок 1 —Абсолютная координатная система детали (определяется поставщиком)

5.3.2 Геометрические единицы OVC

Используемые в OVC единицы длины и единицы плоского угла определяются тремя записями таблицы статуса интерфейса: единицы длины вида view_length_unit, масштабный фактор длины вида view_length_scale_factor и единицы угла вида view_angle_unit. Запись view_length_unit определяет

7

базовую единицу длины вида. Это может быть метр (metre) или дюйм (inch). Запись view_length_scale_ factor определяет мультипликативный масштабный фактор, на который умножается базовая единица длины. Запись view_angle_unit определяет единицу плоского угла вида. Это может быть радиан (rad), градус (deg) или град (grad). В настоящем стандарте термин «единица OVC» означает либо единицу длины вида view_length_unit, масштабированную с помощью множителя view_length_scale_factor (единицу длины координатной системы OVC_length_unif), либо единицу угла вида view_angle_unit (единицу угла координатной системы OVC_angle_unit).

Значения единиц измерения OVC представлены в разделе 8.2 настоящего стандарта. Данные значения по умолчанию могут быть переопределены поставщиком детали (вне используемой программы). Новые значения единиц составляют часть функциональной модели программы поставщика детали. Значения по умолчанию единиц измерения устанавливаются в процессе инициализации вида. Они могут запрашиваться, но не могут быть изменены прикладной программой. Все геометрические размеры, которые могут задаваться (вычисляться) прикладными программами, описаны как текущие единицы измерения OVC.

Интерфейс гарантирует правильное масштабирование при переходе из единиц OVC в единицы моделирующего пространства CAD. Указанное масштабирование называется «преобразование OVC — CAD». Оно применяется для всех элементов геометрических представлений, созданных с помощью функций интерфейса.

5.3.3    Содержимое вида

Функции интерфейса создают данные внутри баз данных систем, моделирующих продукт. Базы данных систем, моделирующих продукт, отличаются друг от друга. Точного описания каждой функции не существует на физическом уровне. Для точного описания работы какой-либо функции интерфейса настоящий стандарт определяет целевую базу данных CAD посредством логической модели в виде информационной модели на языке EXPRESS (см. раздел 6). Принято, что данная логическая модель может быть использована некоторым физическим способом в целевой CAD.

5.3.4    Временная база данных

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

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

Атрибуты визуализации прикрепляются к данным сущностям, если они созданы на модальной основе. Это может иметь место как в TDB, так и в CAD. В TDB атрибуты сущности могут быть изменены. Если сущность посылается из TDB в CAD, то атрибуты визуализации данной сущности сохраняют свои текущие значения в TDB.

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

В TDB и CAD имеются различные структурные соотношения. Сущности, посылаемые в CAD, структурированы с помощью комплектов. Комплекты — это объекты, постоянно присутствующие в базе данных CAD. Используется иерархическая структура комплектов. Для структур элементов TDB используются временные групповые структуры. Групповые структуры могут быть использованы для создания геометрических элементов. Данные групповые структуры также являются иерархическими. Максимальное количество сущностей, допускаемое в TDB при реализации интерфейса, должно быть не менее количества, установленного в разделе 9 настоящего стандарта.

Настоящий стандарт не дает описания какой-либо формы реализации указанной временной базы данных. Функции поставщика деталей должны быть эффективными.

5.3.5    Процесс удаления невидимых линий

В настоящем разделе дано описание концепции невидимых линий 20-видов, созданных интерфейсом.

8

ГОСТ Р ИСО 13584-31-2010

1.    В дополнение к имеющимся сущностям кривых 20-интерфейсы могут создавать «непрозрачные» заполненные области.

2.    Запись таблицы статуса интерфейса, называемая включенной невидимой линией hidden_ line_involved (HLI), указывает, включена или нет сущность кривой или сущность заполненной области (созданной интерфейсом) в процесс удаления невидимых линий. Если значение HLI «true», то каждая сущность кривой или сущность заполненной области (созданная функцией интерфейса) должна быть включена в процесс удаления невидимых линий и может подключаться к предварительно определенному стилю затенения изображения api_predefined_occlusion_style интерфейса прикладного программирования. Api_predefined_occlusion_style должен содержать атрибут view_level (представляющий действительное значение высоты сущности в некотором виртуальном ЗР-пространстве), а также атрибут имени пате, дающий описание того, как следует изменить сущность, если она становится невидимой. Непрозрачная заполненная область скрывает полностью или часть сущности кривой находящегося внутри области и имеющего меньшее значение уровня вида. Заполненная область не должна скрывать сущности кривых с тем же значением уровня вида.

3.    Если значение HLI «false», то созданные сущности кривой и заполненной области можно направлять в CAD, если прикладная программа запрашивает выполнение указанной передачи с помощью функции Fix_Ent (функция фиксирования сущности в CAD) или запрашивает их непосредственное создание в CAD в процессе построения вида. Если значение HLI «true», то сущность кривой и сущность заполненной области остаются в интерфейсе до окончания процесса удаления невидимых линий.

4.    Если прикладная программа запрашивает передачу в CAD сущности, включенной в процесс удаления невидимых линий, то либо с помощью функции FixJEnt, либо путем запроса на непосредственное его создание в CAD данная сущность подключается к предварительно определенному виртуальному стилю интерфейса прикладного программирования api_predefined_vitually_sent_style, то есть отправляется виртуально. Если сущность отправлятся виртуально, то указанный виртуальный стиль api_predefined_vitually_sent_style должен содержать атрибут задания имени интерфейса прикладного программирования api_set_name, определяющий (в формате строки) уникальное имя текущего открытого множества.

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

6.    Если отправленная виртуально сущность кривой частично скрыта заполненной областью, то ее видимая часть имеет текущий стиль кривой. Части виртуально отправленной сущности невидимой кривой обрабатываются в соответствии с атрибутом пате и требованиями предварительно определенного стиля затенения визуализации интерфейса прикладного программирования api_predefined_occlusion_ style.

Значения атрибута:    Сущности    кривой    и    заполненной области:

no_change    отправляются    без    каких-либо    изменений;

dashed (штриховая линия) отправляются как невидимые линии, если данное свойство существует в используемой системе CAD. В противном случае сущности кривой, границы заполненной области и штриховка отправляются как штриховые линии;

invisible (невидимая линия) отправляются как невидимые линии, если настоящее свойство существует в используемой системе CAD. В противном случае отправка не производится.

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

Включение точек в настоящем стандарте не рассматривается.

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

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

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

9

имени интерфейса прикладного программирования api_set_name в соответствии с предварительно определенным стилем виртуальной отправки api_predefined_virtualy_sent_style интерфейса прикладного программирования.

5.3.6 Процесс представления

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

Указанные цели достигаются нижеследующим способом (см. подразделы 6.2.4 и 6.2.5):

1)    все стили воспроизведения определяются либо как предварительно определенные стили, либо как внешне определенные стили;

2)    предварительно определенные стили соответствуют настоящему стандарту. Внешне определенные стили соответствуют как настоящему стандарту, так и любому другому стандарту серии, распространяющейся на обмен данными о деталях;

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

4)    интерфейс — это инструмент пользователя CAD для задания точных значений всех атрибутов изображений, зависящих от реализации для каждого предварительно определенного или внешне определенного стиля;

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

5.4 Структура сущностей

5.4.1 Структура группы в TDB

В используемых TDB сущности объединяются в группы, определяемые сущностью entity_ structured. Если функция предназначена для выполнения операций в группе, то она выполняет эти операции в режиме повторения (рекурсивно) для каждой соответствующей сущности группы. Если данная функция является функцией дублирования, то ее результатом также является группа. Указанная группа принадлежит текущей открытой группе, она имеет такую же групповую структуру, как и исходная функция. Дубликат открытой группы является замкнутой группой. Если данная функция является функцией модификации, то она сохраняет групповую структуру существующих сущностей, находящихся внутри модифицированной группы.

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

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

За исключением корневой группы каждая сущность (геометрическая или структурированная) должна принадлежать только одной группе (которая может быть корневой группой). Группы структурируются в соответствии с иерархической структурой дерева. Корнем дерева является корневая группа.

Группы могут быть:

-    созданными: они принадлежат текущей открытой группе или становятся текущей открытой группой;

-    открытыми повторно: все сущности, созданные в TDB после повторного открытия группы, принадлежат данной группе до ее закрытия;

-    закрытыми.

ГОСТ Р ИСО 13584-31-2010

Сущности, направляемые (созданные) в CAD, удаляются из групповой структуры.

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

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

Если группа является созданной, то: 1) она принадлежит текущей открытой группе; 2) она помещается на вершину стека. Таким образом, она становится текущей открытой группой.

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

Если группа открыта повторно, то она помещается на вершине стека. Это не изменяет свойства группы, которой принадлежит группа, открытая повторно.

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

Функция Remove_Ent_Grp удаляет сущности (геометрические или структурированные) из группы. По окончании выполнения функции сущность должна принадлежать корневой группе.

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

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

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

5.4.2 Структура сущностей, направляемых в CAD

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

1)    перед отправкой любых данных LMS инициализирует вид. Все данные, направляемые в CAD в промежуток времени между указанной инициализацией и окончанием работы прикладного программирования, должны принадлежать виду. Рассматривамый вид не должен содержать других видов;

2)    функция Open_Set открывает множество. Имя множества размещается на вершине заданного стека. Все геометрические сущности, направляемые в CAD, должны принадлежать настоящему множеству. Множество является подмножеством имеющегося содержимого вершины заданного стека или, если данный стек пуст, подмножеством вида.

Функция закрытия множества Close_Set применяется только для множества, которое уже находится на вершине данного стека. При вызове данной функции множество закрывается и его имя удаляется из стека. Если стек заполнен, то вершина стека содержит текущее открытое множество. Если стек пуст, то открытого множества нет. Закрытое множество не подлежит повторному открытию. Имя каждого множества должно быть уникальным внутри вида. Максимальный размер стека множества, допускаемый для TDB реализацией интерфейса, должен быть не менее, чем размер, установленный в разделе 9 настоящего стандарта.

Отображение между настоящей концептуальной структурой и структурой дерева ограниченной глубины, доступное в целевой системе CAD, производится следующим образом. Вершина структуры дерева CAD, если таковая существует, отображает структуру вида. Нижеследующие уровни, если они существуют, отображают первые уровни множеств и подмножеств структуры дерева. Если некоторое множество структуры дерева CAD является конечным (не делится на подмножества), то все сущности, принадлежащие подмножествам соответствующего концептуального множества, помещаются в данное конечное множество.

5.5 Имя геометрической или структурированной сущности

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

11

Значение указанного абстрактного типа данных либо равно 0, либо неизвестно. Если функция интерфейса не срабатывает и не позволяет создать некоторую сущность, то возвращаемое значение равно 0. Если сущность отправляется в CAD и доступ к сущности уже невозможен, то ее имя становится неизвестным. Неизвестное значение, как правило, возвращается функциями интерфейса, если сущность создана непосредственно в базе данных CAD. Если для функции интерфейса в качестве значений аргументов выбирается 0 или «неизвестное значение», то возвращаемое значение равно 0.

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

Примечание — На языке FORTRAN тип имени сущности entity_name_type представляется целым числом INTEGER. Нулевое значение отображается на 0. Неизвестное значение отображается на отрицательное целое. Таким образом, доступное имя сущности может отображаться только на положительное целое.

5.6    Координатная система и ее преобразование

Интерфейс имеет функции, которые могут изменять ссылочную координатную систему пространства с заданной OVC. Прикладные программы могут использовать такие четыре функции: Ref_Sys_3_ Pnt, Ref_Sys_2_Dir, Ref_Sys_Position_Relative и Ref_Sys_A2p. После изменения координатной системы (либо в TDB, либо в базе данных CAD) все сущности определяются в новой ссылочной координатной системе.

Для сохранения предшествующей ссылочной координатной системы функция Ref_Sys_A2p создает локальную координатную систему (сущность axis2_placemenf) из текущей ссылочной координатной системы вида объекта (OVC). Указанная замена ссылочной координатной системы на данную LCS производится так, что позволяет вернуться к исходной OVC.

5.7    Состояние ошибки интерфейса

Глобальная переменная ошибки error_variable задается, если идентифицируется состояние ошибки в процессе выполнения функции интерфейса. Эта переменная принимает целочисленное значение из таблицы статуса интерфейса. Оно совпадает с номером ошибки, определяемым функцией спецификации. При этом в таблицу статуса интерфейса вносится запись «error_origin» с указанием имени функции, где произошла ошибка. Запись «error_text» содержит сообщение, ассоциированное с номером ошибки. Именем функции должно быть синтаксическое имя на текущем используемом языке программирования (например, на языке FORTRAN). Сообщение должно быть переводом описания ошибки (см. подраздел 5.8.1). Указанные переменные ошибки могут запрашиваться и задаваться повторно с помощью прикладных программ.

Если переменная ошибки error_variable определена, значит, интерфейс находится в состоянии ошибки (error_state = true). В указанном состоянии ошибки могут работать только нижеследующие функции интерфейса, установленные в приложении А настоящего стандарта:

1)    функции запроса;

2)    функции перезагрузки из состояния ошибки Reset_Error_State.

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

1)    закрыть все открытые множества;

2)    закрыть открытый вид со значением error_state = true;

3)    сделать записи в файле ошибок: error_variable, error_origin, error_text,

4)    закрыть интерфейс.

5.8    Исправление ошибок

5.8.1 Методология исправления ошибок

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

ГОСТ Р ИСО 13584-31-2010

error_variable = zero, чтобы восстановить интерфейс в состоянии «отсутствие ошибки» (error_state = false). Выбираемая стратегия исправления ошибок интерфейса соответствует нижеследующей классификации ошибок:

-    класс I — ошибки, приводящие к заранее известной реакции системы;

-    класс II — ошибки, связанные с попыткой сохранить результаты или предшествующие операции;

-    класс III — ошибки, приводящие к непредсказуемым результатам, включая разрушение CAD.

Интерфейс распознает три ситуации выявления ошибки:

-    ситуация А — ошибка в функции интерфейса;

-    ситуация Б — ошибка в функции, вызываемой из интерфейса (функции CAD, функции операционной системы и т. д.);

-    ситуация В — ошибка вне интерфейса.

Если ошибки выявлены вне интерфейса (ситуация В), то либо прикладная программа принимает на себя управление выполнением операций, либо выполнение программы заканчивается ненормально. В последнем случае результаты являются непредсказуемыми (класс III), это может привести к разрушению CAD. Если тем не менее прикладная программа принимает на себя управление, то она может попытаться вернуться в LMS, чтобы попробовать закрыть интерфейс надлежащим образом (см. раздел 5.7). Операции, определенные в разделе 5.7, могут быть также выполнены самим интерфейсом. Это стандартная реакция на ошибки класса II.

Все ошибки, явно представленные в перечне как часть определения функции интерфейса, принадлежат к классу I. Они либо возникают внутри самого интерфейса (ситуация А), либо возникают, когда функция, вызванная из интерфейса, передает управление обратно некоторой функции интерфейса вместе с соответствующей информацией об ошибке (ситуация Б). Во всех случаях выявления ошибок класса I интерфейс задает значения переменным ошибки error_variable, error_origin и errorjtext. Если в процессе создания функции сущности имеет место сбой и сущность не может быть создана, то имя сущности, вычисленное функцией, устанавливается равным 0. Если функция интерфейса активизируется с более чем одним состоянием ошибки, то любой из соответствующих номеров ошибки может быть присвоен переменной ошибки.

Функция запроса lnq_Error_State позволяет исправлять ошибки с помощью прикладного программирования. Функция Reset_Error_State выводит интерфейс из состояния ошибки. Закрытие открытого вида при значении переменной error_state = true позволяет LMS заранее предупредить CAD о том, что вид является неправильным.

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

Каждая ошибка имеет свой индивидуальный номер:

1)    номера менее 1001 не используются. Они зарезервированы для последующих обновлений стандарта;

2)    номера ошибок от 1000 до 2000 зарезервированы для привязок языка программирования.

5.8.2 Сообщения об ошибках

Таблица 1 — Сообщения об ошибках входа

Номер ошибки Описание ошибки 1 Имя сущности не определено (значение равно 0, значение неизвестно) 2 Недопустимый тип сущности 3 Значение меры длины находится вне допустимого диапазона 4 Значение меры плоского угла находится вне допустимого диапазона 5 Целочисленное значение находится вне допустимого диапазона 6 Значение строки находится вне допустимого диапазона 7 Действительное значение находится вне допустимого диапазона

Таблица 2 — Сообщения об ошибках геометрии

Номер ошибки Описание ошибки 101 Попытка создания вырожденной сущности 102 Модуль вектора направления лежит вне установленного диапазона [EPS,МАХ] 103 Расстояние между двумя точками лежит вне установленного диапазона [EPS, МАХ] 104 Расстояние между двумя контурами менее EPS 105 Попытка создания вырожденного направления в процессе создания сущности 106 Попытка создания вырожденной оси axis2_placement в процессе создания сущности 107 Попытка создания вырожденной оси axis1_placement в процессе создания сущности 108 Попытка создания вырожденной базовой кривой в процессе создания сущности 109 Попытка создания вырожденного твердого тела в процессе создания сущности 110 Попытка создания точки вне параметрического диапазона сущности кривой 111 Попытка создания линии длиной вне установленного диапазона [EPS, МАХ] 112 Попытка создания дуги длиной менее EPS 113 Попытка создания самопересекающейся сущности контура 114 Попытка создания твердого тела с перекрытием 115 Заданные сущности являются идентичными 116 Заданные точки линейно зависимы 117 Заданные направления параллельны 118 Заданные сущности кривой параллельны (концентрические) 119 Заданные сущности не лежат в одной плоскости 120 Заданный отрезок слишком длинный 121 Слишком большой (маленький) радиус 122 Пересечение заданных сущностей кривой отсутствует 123 Выявлено пересечение заданных контуров 124 Выявлено пересечение осей поверхности 125 Выявлено перекрытие заданных контуров 126 Ось поворота не лежит на плоской поверхности 127 Геометрическое построение нецелесообразно 128 Неустойчивый процесс вычисления конической дуги 129 Сбой процесса аппроксимации замыкания контура 130 Сбой булевой операции

Таблица 3 — Сообщения об ошибках системы

Номер ошибки Описание ошибки 201 Переполнение временной базы данных 202 Ошибка при отправке сущности в CAD 203 Функция несовместима с текущим уровнем интерфейса 204 Функция несовместима с текущим уровнем мощности 205 Превышено максимально допустимое число точек по линии 206 Превышено максимально допустимое число сущностей контура 207 Превышено максимально допустимое число внутренних границ 208 Превышено максимально допустимое число групп 209 Превышено максимально допустимое число символов строки 210 Переполнение стека группы 211 Переполнение заданного стека 212 Сущность может быть использована только внутри временной базы данных

Таблица 4 — Сообщения об ошибках структуры сущностей

Номер ошибки Описание ошибки 301 Попытка закрыть корневую группу 302 Попытка повторно открыть открытую группу 303 Сущность является членом корневой группы 304 Сущность содержит текущую открытую группу 305 Попытка создания цикличной групповой структуры 306 Имя множества не является уникальным 307 Попытка закрыть корневое множество

Таблица 5 — Сообщения об ошибках стиля воспроизведения

Номер ошибки Описание ошибки 401 Источник протокола обмена неизвестен 402 Идентификатор внешнего стиля неизвестен 403 Сбой при назначении стиля штриховки 404 Стиль затенения невидимых линий не подключен

Таблица 6 — Сообщения об ошибках привязки языка программирования

Номер ошибки Описание ошибки 1001 Порядковый номер находится вне установленного диапазона 1002 Несоответствие порядкового номера и длины перечня 1003 Неправильно задана длина строки

ГОСТ Р ИСО 13584-31-2010

Содержание

1    Область применения.................................................................1

2    Нормативные ссылки.................................................................1

3    Термины, определения, обозначения и сокращения.......................................2

3.1    Термины и определения...........................................................2

3.2    Прочие термины и определения....................................................2

3.3    Сокращения.....................................................................3

4    Основные положения................................................................3

4.1    Требования к параметрическим описаниям...........................................3

4.2    Формат обмена параметрических описаний формы....................................4

4.3    Внутреннее представление данных, созданных в приемной системе CAD..................4

4.4    Библиотека поставщика и ответственность пользователя LMS...........................4

4.5    Совместимость..................................................................4

4.6    Точность геометрических построений................................................5

5    Интерфейс ........................................................................5

5.1    Спецификация и соответствие.....................................................5

5.1.1    Допустимые уровни реализации...............................................5

5.1.2    Моделирование отсутствующих сущностей.......................................6

5.2    Таблицы интерфейса.............................................................6

5.3    Создание данных модели продукта.................................................6

5.3.1    Ссылочные координатные системы видов (OVC)..................................6

5.3.2    Геометрические единицы OVC.................................................7

5.3.3    Содержимое вида...........................................................8

5.3.4    Временная база данных......................................................8

5.3.5    Процесс удаления невидимых линий............................................8

5.3.6    Процесс представления......................................................10

5.4    Структура сущностей.............................................................10

5.4.1    Структура группы в TDB......................................................10

5.4.2    Структура сущностей, направляемых в CAD.....................................11

5.5    Имя геометрической или структурированной сущности..................................11

5.6    Координатная система и ее преобразование..........................................12

5.7    Состояние ошибки интерфейса.....................................................12

5.8    Исправление ошибок..............................................................12

5.8.1    Методология исправления ошибок..............................................12

5.8.2    Сообщения об ошибках.......................................................13

6    Логическая модель целевой моделирующей системы......................................16

6.1 Элемент геометрического представления.............................................16

6.1.1    Схема API_ABSTRACT_SCHEMA...............................................18

6.1.2    Определения типов схемы API_ABSTRACT_SCHEMA:

основные понятия описания продукта и его поддержки.............................19

6.1.3    Определения типов схемы API_ABSTRACT_SCHEMA:

геометрические и топологические представления.................................21

6.1.4    Определения типов схемы API_ABSTRACT_SCHEMA: геометрические модели.........23

6.1.5    Определения типов схемы API_ABSTRACT_SCHEMA:

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

6.1.6    Определения сущностей схемы API_ABSTRACT_SCHEMA: основные понятия описания

и поддержки продукта........................................................25

6.1.7    Определения сущностей схемы API_ABSTRACT_SCHEMA: структуры представлений. . .27

6.1.8    Определения сущностей схемы API_ABSTRACT_SCHEMA:

структуры геометрических представлений.......................................31

6.1.9    Определения сущностей схемы API_ABSTRACT_SCHEMA:

геометрические математические сущности.......................................33

6.1.10 Определения сущностей схемы API_ABSTRACT_SCHEMA:

сущности геометрических кривых...............................................38

ГОСТ Р ИСО 13584-31-2010

6.1.11    Определения сущностей схемы API_ABSTRACT_SCHEMA:

геометрические конические сущности...........................................46

6.1.12    Определения сущностей схемы API_ABSTRACT_SCHEMA:

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

6.1.13    Определения сущностей схемы API_ABSTRACT_SCHEMA:

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

6.1.14 Определения сущностей схемы API_ABSTRACT_SCHEMA: сущности кривых..........55

6.1.15 Определения сущностей схемы API_ABSTRACT_SCHEMA: заполненные области......58

6.1.16    Определения сущностей схемы API_ABSTRACT_SCHEMA:

сущности геометрических поверхностей.........................................60

6.1.17    Определения сущностей схемы API_ABSTRACT_SCHEMA:

сущности поверхностей интерфейса прикладного программирования................63

6.1.18    Определения сущностей API_ABSTRACT_SCHEMA: сущности геометрических тел.....65

6.1.19    Определения сущностей схемы API_ABSTRACT_SCHEMA:

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

6.2    Визуализация элементов геометрического представления..............................74

6.2.1    Определения типов схемы API_ABSTRACT_SCHEMA: визуальное представление......75

6.2.2    Определения типов схемы API_ABSTRACT_SCHEMA:

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

6.2.3    Определения сущностей схемы API_ABSTRACT_SCHEMA: визуальное представление____77

6.2.4    Определения сущностей схемы API_ABSTRACT_SCHEMA:

внешне определенные стили визуального представления..........................84

6.2.5    Определения сущностей схемы API_ABSTRACT_SCHEMA:

предварительно определенные стили визуального представления...................88

6.3    Определения функций схемы API_ABSTRACT_SCHEMA................................91

6.3.1    Определения функций схемы API_ABSTRACT_SCHEMA:

геометрические и топологические представления.................................91

6.3.2    Определения функций схемы API_ABSTRACT_SCHEMA: поддержка ресурсов........103

6.3.3    Определения функций схемы API_ABSTRACT_SCHEMA: структуры представлений. .. .104

6.3.4    Определения функций схемы API_ABSTRACT_SCHEMA:

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

6.4    Глобальные правила схемы API_ABSTRACT_SCHEMA................................112

6.4.1    Правило unique_shape_representation..........................................112

7    Функциональные спецификации интерфейса............................................113

7.1    Соглашения об обозначениях.....................................................113

7.1.1    Представления функций.....................................................113

7.1.2    Представления типов данных.................................................114

7.1.3    Имена сущностей и аббревиатуры.............................................114

7.1.4    Имена функций............................................................115

7.2    Логическое описание функций интерфейса и привязки языка FORTRAN..................116

8    Таблицы интерфейса................................................................116

8.1    Таблица описаний интерфейса....................................................116

8.2    Таблица статуса интерфейса......................................................116

9    Размерности реализации интерфейса..................................................117

9.1 Минимальные размерности буферов интерфейса и структурированных типов данных......117

Приложение А (справочное) Логическое описание функций интерфейса и привязки

языка FORTRAN.........................................................119

Приложение В (справочное) Регистрация информационного объекта..........................294

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

ссылочным национальным стандартам Российской Федерации................295

Библиография.......................................................................296

ГОСТ Р ИСО 13584-31-2010

Введение

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

ИСО 13584 включает в себя: основные описания, логический ресурс, используемые данные, описания методологии, протоколы обмена видами, словари ссылок. Описания частей приведены в ГОСТ Р ИСО 13584-1-2006 «Системы промышленной автоматизации и интеграция. Библиотека деталей. Часть 1. Обзор и основные принципы». В настоящем стандарте рассмотрены ресурсы реализации.

В настоящем стандарте представлено описание интерфейса, позволяющего создавать модели продуктов внутри пользовательской системы с помощью прикладных программ, независимых от целевой пользовательской системы. Интерфейс может быть использован вне контекста стандартных данных библиотек деталей. Он позволяет разрабатывать прикладные программы, не зависящие от целевых CAD. В контексте ИСО 10303 настоящий интерфейс может быть применен на верхнем уровне стандартного интерфейса доступа к данным (SDAI) для геометрических построений с учетом имеющихся ограничений. Процесс создания данных модели продукта представляет собой прикладную программу (предлагаемую поставщиком библиотеки деталей), создающую геометрическую модель внутрь пользовательской системы. Данный интерфейс гарантирует ее независимость от целевой пользовательской системы.

ИСО 13584 разработан Техническим комитетом ИСО/ТК 184 «Системы автоматизации производства и их интеграция» и подкомитетом ПК 4 «Технические данные и языки программирования глобального производства».

ИСО 13584 состоит из следующих частей:

-    часть 1. Обзор и основные принципы;

-    часть 10. Общее описание. Концептуальная модель библиотеки деталей;

-    часть 20. Логический ресурс. Логическая модель выражений;

-    часть 24. Логический ресурс. Логическая модель библиотеки поставщика;

-    часть 26. Логический ресурс. Идентификация поставщика информации;

-    часть 31. Ресурсы реализации. Интерфейс геометрического программирования;

-    часть 42. Методология описания. Методология структурирования семейства деталей;

-    часть 101. Протокол обмена видами. Геометрический протокол обмена видами в параметрической программе;

-    часть 102. Протокол обмена видами. Протокол обмена видами в спецификации соответствия ИСО 10303.

V

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Системы промышленной автоматизации и интеграция

БИБЛИОТЕКА ДЕТАЛЕЙ

Часть 31

Ресурсы реализации.

Интерфейс геометрического программирования

Industrial automation systems and integration.

Parts library. Part 31. Implementation resources. Geometric programming interface

Дата введения 2011—09—01

1    Область применения

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

Настоящий стандарт распространяется на:

-    программы, генерирующие геометрические представления внутри моделирующих систем, не зависящих от целевых систем;

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

-    программы, структурирующие геометрические представления, созданные независимо от целевой системы;

-    программы, описывающие атрибуты стиля воспроизведения для символической визуализации созданных представлений;

-    программы, поддерживающие стандарты технического черчения для представления форм, включая 20-механизм для невидимых линий;

Настоящий стандарт не распространяется на:

-    точное управление изображением на мониторе приемного устройства;

-    точное определение данных, создаваемых приемной системой;

-    хранение параметрической модели в приемной системе.

2    Нормативные ссылки

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

ИСО 128:1982 Технические чертежи. Общие принципы воспроизведения (ISO 128:1982, Technical drawings — General principles of presentation)

ИСО 1539:1991 Информационные технологии. Языки программирования. FORTRAN (ISO 1539:1991, Information technology — Programming languages — FORTRAN)

Издание официальное

ИСО/МЭК 8824-1 Информационные технологии. Абстрактная синтаксическая нотация версии один (ASN. 1). Часть 1. Спецификация базовой нотации (ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN. 1) — Part 1: Specification of basic notation)

ИСО 10303-11:1994 Системы промышленной автоматизации и их интеграция. Представление данных о продукции и обмен данными. Часть 11. Методы описания: справочное руководство по языку EXPRESS (ISO 10303-11:1994, Industrial automation systems — Product data representation and exchange — Part 11: Description methods: The EXPRESS language reference manual)

ИСО 10303-41:1994 Системы промышленной автоматизации и их интеграция. Представление данных о продукции и обмен данными. Часть 41. Основные понятия описания и поддержки продукта (ISO 10303-41:1994, Industrial automation systems — Product data representation and exchange — Part 41: Fundamentals of product description and support)

ИСО 10303-42:1994 Системы промышленной автоматизации и их интеграция. Представление данных о продукции и обмен данными. Часть 42. Интегрированный ресурс: геометрические и топологические представления (ISO 10303-42:1994, Industrial automation systems — Product data representation and exchange — Part 42: Integrated resources: Geometric and topological representation)

ИСО 10303-43:1994 Системы промышленной автоматизации и их интеграция. Представление данных о продукции и обмен данными. Часть 43. Интегрированный ресурс: структуры представлений (ISO 10303-43:1994, Industrial automation systems — Product data representation and exchange — Part 43: Integrated resources: Representation structures)

ИСО 10303-46:1994 Системы промышленной автоматизации и их интеграция. Представление данных о продукции и обмен данными. Часть 46. Интегрированный групповой ресурс: визуальное представление (ISO 10303-46:1994, Industrial automation systems — Product data representation and exchange — Part 46: Integrated generic resources: Visual presentation)

3 Термины, определения, обозначения и сокращения

3.1    Термины и определения

В настоящем стандарте использованы термины по ИСО 13584-10:

-    абстрактная деталь (abstract part);

-    система автоматизированного проектирования (computer aided design system);

-    язык EXPRESS;

-    функциональный вид (functional view);

-    система управления библиотекой (library management system, LMS);

-    поставщик библиотеки (library supplier);

-    деталь (part);

-    библиотека деталей (parts library);

-    поставщик деталей (parts supplier);

-    продукт (product);

-    данные продукта (product data);

-    программа (program);

-    представление детали (representation of a part);

-    поставщик (supplier);

-    деталь поставщика (supplier part);

-    библиотека поставщика (supplier library);

-    структура (structure);

-    пользователь (user);

-    пользователь библиотеки (user library);

-    вид (view);

-    переменная управления видом (view control variable);

-    протокол обмена видами (view exchange protocol).

3.2    Прочие термины и определения

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

3.2.1 интерфейс прикладного программирования (Application Programming Interface; API): Множество функций, запускаемых из одной программы с помощью заданного синтаксиса, определенного в одной привязке.

2

ГОСТ Р ИСО 13584-31-2010

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

3.2.3    локальная координатная система (Local Coordinate System; LCS): Ортогональная правосторонняя координатная система, используемая для ориентации и расположения в пространстве геометрических сущностей. Локальная координатная система моделируется сущностью axis2_placement.

3.2.4    параметр (parameter): Переменная с описанными именем и типом значений.

3.2.5    параметрическая модель формы [parametric (shape) model]: Выражение параметрической формы посредством модели данных.

3.2.6    параметрическая программа формы [parametric (shape) program]: Выражение параметрической формы посредством программы, ссылающейся на API (интерфейс прикладного программирования).

3.2.7    параметрическая форма (parametric shape): Общее описание семейства родственных форм и множества параметров. Параметрическая форма дает описание особой функции, действующей из области параметров на множество форм.

3.2.8    временная база данных (temporary database): Механизм, позволяющий хранить данные о конструкции или промежуточные данные перед передачей их в соответствующую систему CAD.

3.3 Сокращения

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

2D —двухмерный (two Dimensional);

3D —трехмерный (three Dimensional);

API — интерфейс прикладного программирования (Application Programming Interface);

CAD —автоматизированное проектирование (Computer Aided Design);

EPS —допуск на значение величины (Epsilon), см. 4.6;

HLI — включение невидимых линий (Hidden Line Involved), см. 5.3.5;

LCS — локальная координатная система (Local Coordinate System);

LMS — система управления библиотекой (Library Management System);

MAX — максимальное значение величины (Maximal value), см. 4.6;

OVC — координатная система вида объекта (Object View Coordinate system), см. 5.3.1;

SDAI — стандартный интерфейс доступа к данным (Standard Data Access Interface);

TDB — временная база данных (Temporary Data Base), см. 5.3.4.

4 Основные положения

4.1 Требования к параметрическим описаниям

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

Пример 1 — В ИСО 4014 [1] приведены описания тысяч различных видов болтов. Описание формы каждого вида болта в отдельности нецелесообразно.

2)    Каждое глобальное описание формы должно быть ассоциировано со множеством численных, строчных или булевых параметров, область значений которых характеризует каждую деталь рассматриваемого семейства. Механизм генерации каждой заданной формы (вне ее глобального описания с помощью особого множества v-значений параметров) должен быть детерминированным. Он определяет частную функцию f, действующую из области значений параметров D на множество форм S:

f: D —► S; s = f(v).

Данное описание называется параметрической формой.

Пример 2 — Гповальное описание двухмерного изображения сверху различных видов болтов, соответствующих требованиям ИСО 4014, зависит от двух действительных параметров L и D. Для каждой пары допустимых значений (I, d) параметров LuD рассматриваемый механизм генерирует детерминированную уникальную форму.

3)    Параметрическая форма описывается графическими взаимосвязями пользователя. Иначе говоря, рассматриваемый механизм дает описания геометрии с учетом ограничений. Вычислитель ограничений является частью данного механизма.

3

4.2    Формат обмена параметрических описаний формы

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

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

Примечание — Это допущение демонстрирует отличие между форматом обмена, описанным в настоящем стандарте (программой на языке FORTRAN, обращающейся к стандартному интерфейсу прикладного программирования), и вычислительной средой, используемой для создания указанного описания (например, диалоговой графической системой, такой как параметрическая система CAD).

4.3    Внутреннее представление данных, созданных в приемной системе CAD

Спецификация интерфейса должна:

-    быть достаточно точной для описания формы деталей их поставщиком;

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

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

4.4    Библиотека поставщика и ответственность пользователя LMS

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

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

2.    Библиотека может содержать геометрические описания разных поставщиков. Такая библиотека используется в контексте различных приложений. Указанный интерфейс позволяет поставщику библиотеки давать описания формы деталей, а пользователю библиотеки гарантирует сохранение уровня их воспроизведения. В настоящем стандарте для выполнения поставленной цели разрешается логическое управление поставщиком детали при воспроизведении ее формы (например, выбор поименованного стиля кривой). При этом:

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

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

4.5    Совместимость

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

2.    Если геометрическая моделирующая система поддерживает интерфейс SDAI [2], удовлетворяющий требованиям ИСО 10303-22, то интерфейс, описанный в настоящем стандарте, должен быть использован как аппликативный слой на верхнем уровне интерфейса SDAI.

ГОСТ Р ИСО 13584-31-2010

Аппликативный слой содержит:

-    решающую программу (далее — решатель) для вычисления геометрических сущностей с учетом ограничений;

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

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

4.6 Точность геометрических построений

Различные моделирующие системы обеспечивают различную числовую точность построений. Необходимо:

1)    гарантировать, чтобы поставщик программ действовал надлежащим образом при каждой «корректной» реализации интерфейса;

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

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

Определяют три ссылочные числовые границы:

1)    EPS — это минимальное значение меры, включенной в меру геометрической сущностью.

Пример 1 — Прикладная программа не может задавать отрезок длиной меньше EPS.

2)    МАХ — максимальное значение меры, включенной в меру геометрической сущностью.

Пример 2—Прикладная программа не может задавать дугу окружности радиусом более МАХ.

3)    ZERO_value (нулевое значение) — максимальное значение (математически вычисленного) расстояния между двумя точками, которые считаются совпадающими.

Пример 3 — Прикладная программа не может задавать контур (то есть замкнутую комбинированную кривую compositejcurve), для которого расстояние между конечной точкой предшествующего сегмента данной комбинированной кривой compositejcurvejsegment и начальной точкой последующего сегмента данной кривой превышает нулевое значение ZERO_value.

Все указанные ссылочные числовые границы созданного геометрического представления масштабируют:

1)    единицы длины вида view_length_unit масштабируют с помощью масштабного фактора view_ length_scale_factor меры длины !ength_measure\

2)    единицы угла вида view_angle_unit масштабируют с помощью меры плоского угла plane_angle_ measure.

В настоящем стандарте для ссылочных числовых границ установлены следующие значения:

1)    EPS = 10^-3;

2)    МАХ = 10⁴;

3)    ZERO_value = 10“⁶.

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

5 Интерфейс

5.1    Спецификация и соответствие

5.1.1    Допустимые уровни реализации

В настоящем стандарте приведено описание трех уровней реализации в соответствии с установленной геометрической мощностью интерфейса, имеющей значения: 2D-, ЗР-кривая, тело. Значения

5