1 РАЗРАБОТАНЫ Научно-исследовательским центром (НИЦ) CALS-технологий "Прикладная логистика" при участии Всероссийского научно-исследовательского института стандартизации (ВНИИстандарт)

ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 431 "CALS-технологии"

2 ПРИНЯТЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Постановлением Госстандарта России от 2 июля 2001 г. N 256-ст

3 Настоящие рекомендации разработаны с учетом требований MIL Std 1840 C

4 ВВЕДЕНЫ ВПЕРВЫЕ

Настоящие рекомендации по стандартизации регламентируют основные правила электронного обмена, форматы представления технических данных об изделии <*> и распространяются на обмен между организациями или системами автоматизированного проектирования конструкторскими, технологическими, программными и другими проектными данными, представленными в электронном виде.

--------------------------------

<*> Под изделием в настоящих рекомендациях понимается любая продукция, изготавливаемая по конструкторской, технологической и программной документации.

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

ГОСТ 2.102-68 Единая система конструкторской документации. Виды и комплектность конструкторских документов

ГОСТ 2.301-68 Единая система конструкторской документации. Форматы

ГОСТ 2.601-95 Единая система конструкторской документации. Эксплуатационные документы

ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения

ГОСТ 17657-79 Передача данных. Термины и определения

ГОСТ Р 34.10-94 Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма

ГОСТ Р 34.11-94 Информационная технология. Криптографическая защита информации. Функция хэширования

ГОСТ Р ИСО 10303-21-99 Промышленные системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 21. Методы реализации. Кодирование открытым текстом структуры обмена

ГОСТ Р 50739-95 Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования

Р 50-605-80-93 Рекомендации. Система разработки и постановки продукции на производство. Термины и определения

3.1 В данных рекомендациях применяются следующие термины с соответствующими определениями:

3.1.1 автоматизированная система: По ГОСТ 34.003.

3.1.2 комплект носителей: Один или несколько носителей одного типа, содержащие информацию передаваемого пакета.

3.1.3 жизненный цикл изделия (ЖЦИ): По Р 50-605-80.

3.1.4 защита информации: По ГОСТ Р 50739.

3.1.5 иллюстрация: Изображение, график, диаграмма или иная форма графического представления информации.

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

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

3.1.8 канал связи: По ГОСТ 17657.

3.1.9 обыкновенный текстовый файл: Тип файла, содержащий произвольно отформатированные текстовые данные.

3.1.10 передаваемая единица данных: Множество файлов, состоящее из одного файла описания и одного или нескольких файлов данных.

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

3.1.12 передаваемый пакет: Множество, состоящее из одной или нескольких передаваемых групп.

3.1.13 растровые данные: Представление или хранение графики или текста в форме расположенных рядами элементов изображения.

3.1.14 связанные данные: Данные, имеющие внешние информационные ссылки.

3.1.15 несвязанные данные: Данные, не имеющие внешних информационных ссылок.

3.1.16 специальный словарный файл: Файл, состоящий из слов, имеющихся в словаре передающей системы и отсутствующих в словаре принимающей системы.

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

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

3.1.19 функция хэширования: По ГОСТ Р 34.11.

3.1.20 хэширование: Процесс вычисления функции хэширования.

3.1.21 электронная цифровая подпись (ЭЦП): По ГОСТ Р 34.10.

3.1.22 файл ЭЦП: Файл, содержащий значение ЭЦП и сведения о ней.

В настоящих рекомендациях приняты следующие сокращения:

АС - автоматизированная система;

ЖЦИ - жизненный цикл изделия;

ЭЦП - электронная цифровая подпись;

ИЭТР - интерактивное электронное техническое руководство;

DSSSL - язык программирования для описания спецификации и семантики стиля документа (от Document Style Semantics and Specification Language);

IGES - общее наименование серии стандартов ANSI/US PRO/IPO на обмен графическими данными (от Initial Graphics Exchange Specification);

NCM - числовое программное управление оборудованием (от Numerical Control of Machines);

PDL - язык программирования для описания разметки страницы (от Page Description Language);

SGML - язык программирования для разметки крупных структурированных наборов данных (от Standard Generalised Markup Language);

STEP - общее наименование серии стандартов ИСО 10303 на обмен данными об изделии (от Standard for Exchange of Product Model Data).

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

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

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

Файл передаваемой единицы данных (далее - файл данных) имеет специальный формат и логически разделен на две части: идентификационный и содержательный блоки.

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

Содержательный блок состоит из собственно передаваемых данных.

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

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

Группирование файлов в передаваемые единицы данных и объединение их в передаваемую группу зависит от назначения передаваемой информации.

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

5.2.1 Типы передаваемых единиц данных

Всего выделено пять типов передаваемых единиц данных:

a) единица данных постраничного изображения (например отсканированных иллюстраций или текста);

b) единица данных, представленных на языке PDL, например текста;

c) единица данных, представленных на языке SGML, например текст, размеченный согласно ИСО 8879 [1];

d) единица производственных данных, например данные о составе и структуре изделия согласно ИСО 10303-203 [2], представленные в виде обменного файла по ГОСТ Р ИСО 10303-21, или данных согласно ИСО 4343 [3];

e) смешанная единица, например содержащая данные о составе изделия по ИСО 10303-214 [4], представленные в формате ГОСТ Р ИСО 10303-21, и эксплуатационную документацию, оформленную согласно ИСО 8879.

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

a) одного файла описания;

b) произвольного количества файлов постраничного изображения, дополнительные требования к которым оговариваются в соглашении;

c) произвольного количества специальных словарных файлов, содержание которых должно быть оговорено в соглашении;

d) произвольного количества файлов ЭЦП.

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

5.2.1.2 Передаваемая единица данных на языке PDL должна состоять из:

a) одного файла описания;

b) одного или нескольких файлов PDL, конкретный формат которых оговаривается в соглашении;

c) произвольного количества файлов ЭЦП.

5.2.1.3 Передаваемая единица данных на языке SGML должна состоять из:

a) одного файла описания;

b) произвольного количества файлов описания типа документа;

c) одного файла текста, размеченного по правилам SGML;

d) произвольного количества файлов объектов, выполненных в стандарте, отличном от SGML, таких как иллюстрации или аудио- или видеофайлы;

e) файла данных со спецификацией форматного вывода (на языке DSSSL [5] и других - для задания стиля и оформления информации), которая должна быть указана в соглашении; этот файл необязателен;

f) произвольного количества специальных словарных файлов;

g) произвольного количества оговоренных соглашением файлов;

h) произвольного количества файлов ЭЦП.

5.2.1.4 Передаваемая единица производственных данных должна состоять из:

a) одного файла описания;

b) произвольного количества файлов данных, содержащих чертежи в форматах IGES, STEP (см. 5.3.2.2.3) или в растровом формате, конкретные требования к которому должны быть оговорены в соглашении;

c) произвольного количества файлов данных о структуре и свойствах изделия, представленных в формате обменных файлов согласно ГОСТ Р ИСО 10303-21;

d) произвольного количества файлов данных по электротехнике и электронике, формат которых определяется соглашением;

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

f) произвольного количества файлов ЭЦП.

5.2.1.5 Смешанная передаваемая единица данных должна состоять из:

a) одного файла описания;

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

c) произвольного количества файлов ЭЦП.

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

5.3.1 Файл описания передаваемой единицы данных

5.3.1.1 Наименование файла описания

Наименование должно быть длиной четыре символа; первый символ должен быть D; последние три символа должны быть ASCII-представлением [6] алфавитно-числового идентификатора для передаваемой единицы данных. Этот 4-символьный идентификатор обеспечивает уникальное наименование для каждой передаваемой единицы данных в передаваемой группе. Алфавитно-числовой идентификатор для каждого файла описания должен начинаться с "001" и наращиваться в упорядоченной последовательности (с преобразованием в строку ASCII) для каждой добавляемой передаваемой единицы данных, содержащейся в передаваемой группе. Для построения действительных алфавитно-числовых идентификаторов должны применяться следующие правила.

a) После чисел от "001" до "999", исчерпанных как идентификаторы, в целях расширения группы идентификаторов должны использоваться ASCII буквы верхнего регистра от "A" до "Z"

b) Лексическая прогрессия должна развертываться от "001" до "ZZZ", например:

001 . . . 999,

A00 . . . A09, A0A . . . A0Z, A10 . . . A1Z, . . . , AY0 . . . AYZ, AZ0 . . . AZZ

B00 . . . B09, B0A . . . B0Z, B10 . . . B1Z, . . . , BY0 . . . BYZ, BZ0 . . . BZZ

. . .

. . .

. . .

Z00 . . . Z09, Z0A . . . Z0Z, Z10 . . . Z1Z, . . . , ZY0 . . . ZYZ, ZZ0 . . . ZZZ

5.3.1.2 Формат файла описания

Файл описания должен состоять из записей фиксированной длины по 128 байт каждая. Все записи должны быть представлены в символьном формате ASCII. Назначение каждой записи указано в таблице 1, при этом записи файла описания должны всегда следовать в том порядке, в котором они приведены в таблице. Во всех записях значения даты и даты-времени должны соответствовать универсальному скоординированному времени [7] и использовать формат "YYYYMMDD/HHHH:SS", где "YYYY" - четырехзначный год, "MM" - месяц, "DD" - день месяца, "HHHH" - часы (в 24-часовой системе, первые два символа - часы, последние два символа - минуты), "SS" - секунды.

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

Когда данные, размещаемые в записи, существуют (известные или неизвестные), но не поддерживаются по условиям соглашения, должна быть использована строка ASCII-символов "EMPTY". Когда данные, требуемые записью, не используются в конкретной передаваемой единице данных, используется строка ASCII-символов "NA". Когда данные, требуемые записью, не существуют, используется строка ASCII-символов "NONE".

Пример файла описания приведен в приложении Б.

5.3.1.3 Запрет на использование символа NULL

В файлах описания и во всех заголовочных записях, описываемых настоящими рекомендациями, запрещено использование символа NULL (в таблице ASCII - положение 0/0).

5.3.2 Файл передаваемой единицы данных

5.3.2.1 Наименование файла данных

Наименование должно быть длиной восемь символов, где первые четыре символа должны быть такими же, как наименование файла описания (см. 5.3.1.1). Пятый символ должен быть кодом из таблицы 2, определяющим формат файла данных. Последние три символа должны быть символьным представлением алфавитно-числового идентификатора от "001" до "ZZZ", правила формирования которого аналогичны приведенным в 5.3.1.1.

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

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

5.3.2.2 Формат файла передаваемой единицы данных

5.3.2.2.1 Формат идентификационного блока файла данных

Идентификационный блок файла данных состоит из символьных записей в коде ASCII. Общий синтаксис записей идентификационного блока -<идентификатор>:<содержание>. В таблице 3 представлен полный список всех возможных записей идентификационного блока файлов данных. Общий синтаксис записи -<поле 1, поле 2, . . . , поле n>. Поля разделяются символом запятой, за которым следует символ пробела. Требования к содержанию полей приведены в приложении В. Во всех записях значения даты и даты-времени должны соответствовать универсальному скоординированному времени (см. 5.3.1.2).

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

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

Когда алфавитно-числовые данные, необходимые для размещения в записи, не существуют, должна быть использована символьная строка "NONE". Когда данные для этой записи неизвестны, должен быть использован ASCII-символ "0".

5.3.2.2.3 Формат содержательного блока файла данных

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

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

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

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

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

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

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

6.1.1 Заголовочные записи подписи

Заголовочные записи ЭЦП должны быть сформированы в соответствии с таблицами 6, А.1 и требованиями настоящего раздела. Подписаны могут быть один или несколько файлов данных либо передаваемая единица данных в целом.

Данные об ЭЦП содержатся в трех заголовочных записях - "sighash:", "siginfo" и "sigdata:".

При использовании ЭЦП файл описания должен содержать одну запись "sighash:" для каждой подписи передаваемой единицы данных, а также по одной записи "sighash:" для каждого подписанного файла передаваемой единицы данных. Кроме записи "sighash:", для каждой подписи должны присутствовать по одной записи "siginfo" и "sigdata:". Записи об ЭЦП должны быть сохранены в файле описания в порядке, указанном в таблице 1. Записи об ЭЦП передаваемой единицы данных должны идти перед ЭЦП для файлов данных, подписанных индивидуально.

Записи об ЭЦП передаваемой единицы данных должны следовать в порядке, указанном в соответствующих полях записей siginfo и sigdata. (см. приложение А). Записи об ЭЦП файлов данных должны следовать в лексическом порядке файлов данных в передаваемой единице данных и в порядке, указанном в соответствующих полях записей siginfo и sigdata (пример приведен в приложении Б).

Порядок следования и правила формирования полей записей "sighash:", "siginfo" и "sigdata:" приведены в приложении А.

6.1.2 Цифровая подпись передаваемых данных

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

6.1.2.1 ЭЦП передаваемых единиц данных

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

6.1.2.2 ЭЦП файлов данных

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

6.1.3 Выбор алгоритмов хэширования и подписи

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

6.1.4 Преобразование двоичных данных в строку ASCII

Результатом выполнения вышеуказанных алгоритмов являются двоичные данные. Для их включения в заголовочную запись файла необходимо преобразовать вычисленное значение хэширования, идентификатора открытого ключа и значение ЭЦП из двоичного в символьное представление. Каждый 4-битный блок должен быть преобразован в символ ASCII, начиная с наиболее значащих (первых) четырех бит, в соответствии с таблицей 8.

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

6.1.5 Тип файла цифровой подписи

ЭЦП как отдельные файлы (файлы типа "D" рассмотрены в приложении Е) могут быть объединены в передаваемой единице данных с файлами данных (перечисленными в таблице 2). Эти подписи могут использоваться для проверки целостности данных, содержащихся в файлах данных, или для архивных целей. Данные в каждом файле типа D состоят исключительно из записей "sighash:", "siginfo:" и "sigdata:" (см. таблицу 6). Запись "sighash:" в файле типа D содержит поле имени файла данных, которому соответствуют подписи, все остальные поля опускаются. Значения полей записи "siginfo:" и "sigdata:" определяются таблицей А.1.

6.1.6 Определение подлинности ЭЦП

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

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

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

6.2.1 Шифрование передаваемых единиц данных

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

6.2.2 Шифрование файлов передаваемой единицы данных

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

6.2.3 Заголовочные записи шифрования

Информация о шифровании размещается в записях "encdata:" и "datinfo:" файла описания передаваемой единицы данных. Файл описания не шифруется. Когда к одному файлу данных применены и шифрование, и хэширование (как часть генерации цифровой подписи), то сначала применяется алгоритм шифрования, а хэширование вычисляется на зашифрованных данных.

Выбор алгоритма шифрования особо оговаривается в соглашении.

6.2.4 Структура и поля заголовочных записей

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

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

Порядок следования и пример формирования полей записей "encdata" и "dstinfo" приведены в таблице А.1.

6.2.5 Управление ключами шифрования

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

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

Информация о сжатии помещается в запись "cmpdata:" в файле описания передаваемой единицы данных. Сам файл описания не сжимается.

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

Заголовочные записи сжатия кодируются в соответствии с таблицей 10. Сжатая передаваемая единица данных содержит в алфавитном порядке все файлы данных передаваемой единицы данных целиком. Запись "cmpdata:" добавляется к файлу описания и описывает алгоритм, используемый для сжатия передаваемой единицы данных. Для каждого файла данных (исключая сжатие передаваемой единицы данных целиком) запись "cmpdata:" добавляется к файлу описания. Поля в заголовочной записи сжатия разделяются символом запятой, за которым следует символ пробела. Пример заполнения записи приведен в приложении А.

Применение алгоритмов сжатия регламентируется соглашением. Некоторые распространенные алгоритмы и форматы перечислены в таблице 10.

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

version: Р 50.1.027-2001,0,20001222

srcsys: НИЦ ABC, Москва, 117234, 21-я Парковая, к. 23-А

srcdocid: Система наведения, вариант 4

srcrelid: Авионика СУ-27, вариант 2

chglvl: REVISION W/CHG, G, 2, 19980804/1209:33

dteisu: 19990808/0000:00

dstsys: АБВ, ОН, 45343

dstdocid: 4SA6-11-4

dstrelid: 4SA6-11

dtetrn: 19991225/1400:24

dlvacc: раздел A006, контракт N33400-93-C1053, 19970915

filcnt: T8, Q4, C1, R1

ttlcls: UNCLASSIFIED

doccls: UNCLASSIFIED

doctyp: SS

docttl: система навигации СУ-27

transacttyp: SGML

rootfilid: D001T007, 19990802/0800:00, 54317

sighash: D001, ACA-WHF, 1, 1, 0, 467CD86C8E8CC10E2A8BD5FB045C50B834DC556F

siginfo: D001, В. Сидоров, , 19991221/2359:42, 1, NONE

sigdata: D001, HFR, NONE, NONE, 1, 0, 6C8BD8E8CC5E0CD4760985FBA456783FCDC50B843

sighash: D001T003, ACA-WHF, 1, 1, 0, 467CD86C8E8CC10E2A8BD5FB045C50B834DC556F

siginfo: D001T003, В. Сидоров, , 19991221/2359:43, 1, NONE

sigdata: D001T003, HFR, NONE, NONE, 1, 0, C5E0CD47606C8BD8E8C9FBA4DC50B5678C8385F43

cmpdata: D001, ZIP, 2. 04G

cmpdata: D001Q004, ZIP, 2. 04G

cmpdata: D001C001, RAR, 2. 01

specversion: Unigraphics 15. 0

srcdocid: Р 50.1.027-2001-2, 0, 20001222

dstdocid: 132 12-11. stp, 19940707/1500:59

moduleid: модуль K132

dtype: 203: 6

doccls: Unclass

notes: файл типа S (обменный файл согласно ГОСТ Р ИСО 10303-21; данные представлены по ИСО 10303-203)

ISO-10303-21;

HEADER;

FILE_DESCRIPTION ((' '), '2;1');

FILE_NAME ('as132-ug', '1999-01-13T11:17:57-06:00', (' '), (' '), 'STDEVELOPER 1.6', 'UNIGRAPHICS SOLUTIONS - UNIGRAPHICS 15.0', ' ');

FILE_SCHEMA (('CONFIG_CONTROL_DESIGN', ' '));

ENDSEC;

DATA;

#10=PERSON_AND_ORGANIZATION_ROLE ('classification_officer');

#11=CC_DESIGN_PERSON_AND_ORGANIZATION_ASSIGNMENT (#3114, #10, (#3111));

#12=CALENDAR_DATE (0, 1, 1);

#13=COORDINATED_UNIVERSAL_TIME_OFFSET (0, 0, .BEHIND.);

#14=LOCAL_TIME (0, 0, 0., #13);

#15=DATE_AND_TIME (#12, #14);

#16=DATE_TIME_ROLE ('classification_date');

#17=CC_DESIGN_DATE_AND_TIME_ASSIGNMENT (#15, #16, (#3111));

#18=ORGANIZATION ($, ' ', ' ');

#19=PERSON_AND_ORGANIZATION (#2011, #18);

#3103=CARTESIAN_POINT (' ', (42.5, 13., 37.0096189432334));

#3104=DIRECTION (' ', (0., -1., 0.));

#3105=DIRECTION (' ', (0., 0., -1.));

#3106=AXIS2_PLACEMENT_3D (' ', #3103, #3104, #3105);

#3107=ITEM_DEFINED_TRANSFORMATION (' ', ' ', #613, #3106);

#3108=(REPRESENTATION_RELATIONSHIP (' ', ' ', #2769, #2919)

REPRESENTATION_RELATIONSHIP_WITH_TRANSFORMATION (#3107)

SHAPE_REPRESENTATION_RELATIONSHIP());

#3109=NEXT_ASSEMBLY_USAGE_OCCURRENCE ('1009', ';

', 'NBA1', #2931, #2781, );

ENDSEC;

END-ISO-10303-21;

Все файлы данных типа A должны быть обязательно подробно оговорены в соглашении. Формат индивидуальных кодов записи "dtype:" для файла данных типа A должен соответствовать приведенным в таблице Е.1 либо оговоренным в соглашении.

Файлы типа B используются для передачи данных, закодированных в виде MIME как файла данных. Коды записи "dtype:" для файла данных типа B должны соответствовать приведенным в таблице Е.2 либо быть особо оговорены в соглашении.

Файлы данных типа C содержат иллюстрации и графические объекты согласно ИСО 8632. Для файла данных типа C запись "dtype:" имеет синтаксис <версия метафайла, палитра>. Коды записи "dtype:" должны соответствовать представленным в таблице Е.3 либо быть особо оговорены в соглашении.

Файлы данных типа D должны содержать данные ЭЦП, определенные в 6.1.5. Код данных типа D должен соответствовать представленному в таблице Е.4.

Файл данных типа E содержит данные по электротехническому и электронному проектированию. Код записи "dtype:" для файла данных типа E должен соответствовать таблице Е.5 либо быть особо оговорен в соглашении.

Файлы данных типа F должны быть описаны в соглашении. Допустимые коды записи "dtype:" для подтипов файла данных типа F должны соответствовать представленным в таблице Е.6 либо оговоренным в соглашении.

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

Файл типа G должен состоять из описания типа документа без каких-либо иных данных согласно ИСО 8879. В случае, когда описание типа документа добавлено к началу файла, файл данных должен передаваться как тип T. Код записи "dtype:" для файла данных типа G должен соответствовать представленному в таблице Е.7 либо указанному в соглашении.

Файлы данных типа H необходимы для отображения размеченных SGML-данных. Коды записи "dtype:" для файла данных типа H должны соответствовать приведенным в таблице Е.8 либо быть особо оговорены в соглашении.

Допустимый код записи "dtype:" для файла данных типа J должен соответствовать представленному в таблице Е.9 либо указанному в соглашении.

Допустимые коды записи "dtype:" для файла данных типа M должны соответствовать представленным в таблице Е.10 либо быть указаны в соглашении.

Файлы данных типа N, содержащие текстовые объекты SGML, должны соответствовать ИСО 8879. Допустимый код записи "dtype:" для файла данных типа N должен соответствовать представленному в таблице Е.11 либо указанному в соглашении.

Файлы данных типа O содержат производственные данные. Допустимые коды записи "dtype:" для файла данных типа O должны соответствовать представленным в таблице Е.12 либо быть особо оговорены в соглашении.

Файлы данных типа P содержат данные по компоновке страниц в электронной форме. Коды записи "dtype:" для файла данных типа P должны соответствовать представленным в таблице Е.13 либо быть особо оговорены в соглашении.

Файлы данных типа Q могут быть любыми из нескольких типов иллюстрированных, чертежных, проектных или производственных данных об изделии. Допустимые коды записи "dtype:" для файла данных типа Q должны соответствовать представленным в таблице Е.14 либо быть особо оговорены в соглашении.

Файлы данных типа R содержат растровые данные. Допустимые коды записи "dtype:" для файла данных типа R должны соответствовать представленным в таблице Е.15 либо быть особо оговорены в соглашении.

Файлы данных типа S содержат данные об изделии в ИСО 10303 (STEP). Допустимые коды записи "dtype:" для файла данных типа S должны соответствовать представленным в таблице Е.16 либо быть особо оговорены в соглашении.

Если файл данных использует более одного класса соответствия, код(ы) дополнительного класса соответствия должны быть разделены ASCII-символом запятой и ASCII-символом пробела. Допускается записывать только один, самый старший поддерживаемый класс соответствия используемого протокола применения.

Если файл данных не соответствует ни одному классу соответствия, в качестве кода класса должен быть использован символ нуля ("0").

Файлы данных типа T должны содержать текст с разметкой по стандарту SGML. Допустимые коды записи "dtype:" для файла данных типа T должны соответствовать представленным в таблице Е.17 либо быть особо оговорены в соглашении.

Формат и содержание специальных словарных файлов в общем случае определяются соглашением. Допустимый код записи "dtype:" файла данных типа X должен соответствовать представленному в таблице Е.18 либо указанному в соглашении.

Формат файлов и их содержание для черно-белых либо цветных иллюстрационных данных должны быть указаны в соглашении. Допустимый код записи "dtype:" для файла данных типа Z должен соответствовать представленному в таблице Е.19 либо указанному в соглашении.

Использование данных в растровой форме обеспечивает возможности просмотра, архивации и комментирования/аннотирования данных. Бумажная документация может требоваться в дополнение к растровым данным только для проверки растрового содержания данных. При выполнении работ по контрактам с зарубежными партнерами допускается использовать требования изменений в MIL-Std-1840 C [43].

Пример записи требований

1 Данные должны быть представлены на магнитной ленте с девятью треками.

2 Каждая лента должна иметь ярлык с номером.

3 Растровые данные должны быть представлены в виде файлов типа 1.

4 Размер изображения должен быть 512 x 512.

5 Растровая плотность изображения должна быть 200 PELS/Inch.

6 Растровая ориентация изображения должна быть горизонтальной.

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

Обмен данными об изделии в формате ИСО 10303 (STEP) обеспечивает возможности просмотра, архивации, комментирования/аннотирования, извлечения части данных, редактирования и конвертирования данных.

Пример записи требований

1 Данные должны быть представлены на сменном магнитном носителе (дискете) с максимальной допустимой емкостью 1,44 Мбайт.

2 Каждая поставленная дискета должна иметь сопроводительный ярлык.

3 Данные должны быть представлены в виде обменного файла согласно ГОСТ Р ИСО 10303-21.

4 Структура данных должна соответствовать схеме "config_control_design" согласно ИСО 10303-203.

5 Состав данных должен включать объекты 1, 5 и 6-го классов соответствия.

6 В данных 1-го класса соответствия должны быть заполнены атрибуты всех объектов; использовать значения по умолчанию не допускается.

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

8 Проверка качества данных должна осуществляться программным продуктом "AP 203 Conformance Checker", входящим в состав ППП "ST-Developer", версия 7.0. Результат проверки должен быть положителен. Проверка должна осуществляться до подготовки данных к отправке.

--------------------------------

<*> Международные стандарты ИСО (ИСО/МЭК) - во ВНИИКИ Госстандарта России.

<**> Национальные стандарты США - в Интернете по адресу https://webstore.ansi.org/ansidocstore.

<***> Документы по стандартизации - в Интернете по адресу http:/www.cals.ru.

--------------------------------

<*> Документы по стандартизации - в Интернете по адресу http:/www.cals.ru.

<**> Международные стандарты ИСО (ИСО/МЭК) - во ВНИИКИ Госстандарта России.

<***> Национальные стандарты США - в Интернете по адресу https://webstore.ansi.org/ansidocstore.