P 50.1.027-2001

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

Информационные технологии поддержки жизненного

цикла продукции

АВТОМАТИЗИРОВАННЫЙ ОБМЕН ТЕХНИЧЕСКОЙ ИНФОРМАЦИЕЙ

Основные положения и общие требования

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

ГОССТАНДАРТ РОССИИ Москва

P 50.1.027-2001

Предисловие

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

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

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

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

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

© ИПК Издательство стандартов, 2001

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

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

Информационные технологии поддержки жизненного цикла продукции

АВТОМАТИЗИРОВАННЫЙ ОБМЕН ТЕХНИЧЕСКОЙ ИНФОРМАЦИЕЙ

Основные положения и общие требования

Р 50.1.027-2001

БЗ 12-2000/28

Редактор В.П. Огурцов Технический редактор Л.А. Гусева Корректор Т.И. Кононенко Компьютерная верстка С В. Рябовой

Изд. лиц. № 02354 от 14.07.2000. Сдано в набор 14.08.2001. Подписано в печать 09.10.2001. Формат 60 х 84 Vs. Бумага офсетная. Гарнитура Таймс. Печать офсетная. Усл.печл. 4,65. Уч.-иэд.л. 3,90.

Тираж 506 экз. Зак. 953. Изд. Nq 2763/4. С 2278.

ИПК Издательство стандартов, 107076, Москва, Колодезный пер., 14. http://www.standards.ru    e-mail:    info@standards.ru

Набрано в Издательстве на ПЭВМ Филиал ИПК Издательство стандартов — тип. “Московский печатник”, 103062, Москва, Лялин пер., 6.

Плр № 080102

которым следует символ пробела. Требования к содержанию полей приведены в приложении В. Во всех записях значения даты и даты-времени должны соответствовать универсальному скоординированному времени (см. 5.3.1.2).

Таблица 3 — Заголовочные записи файла передаваемой единицы данных

Идентификатор записи Наименование записи Описание specversion: Версия стандарта Строка, идентифицирующая стандарт, определяющий формат и содержание файла данных srcdocid: Идентификатор данных передающей системы Строка, идентифицирующая связанные данные, к которым этот файл принадлежит или на который дается ссылка dstdocid; Идентификатор данных принимающей системы Строка, идентифицирующая переданные данные. Должна быть идентична полю «dstdocid:» файла описания datfilid: Идентификатор способа обработки данных Строка, определяющая требования к обработке, необходимой для использования данных d-type: Тип данных Идентификатор типа файла данных (см. приложение Е) rorient: Ориентация растрового изображения Направление последовательности элементов изображения по горизонтали и направление последовательности линий rpelcnt: Счетчики элементов растрового изображения Целочисленные счетчики элементов изображения, содержащихся в линии, и самих линий rdensity: Плотность растрового изображения Строковое представление числового значения плотности растрового изображения Doccls: Метка конфиденциальности Строка, характеризующая уровень конфиденциальности файла данных. Состав меток определяется соглашением Origfilid: Исходное наименование файла Строка, содержащая исходное наименование файла данных в передающей системе notes: Примечания Произвольный текст, содержащий любые разрешенные для заголовочных записей символы

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

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

Таблица 4 — Применяемость записей файлов передаваемой единицы данных

Кодовая буква файла данных (см. таблицу 3) Заголовочная запись specversion: srcdocid: dstdocid: datfilid: d-type: rorient: rpelcnt: rdensity: doccls: •o a i о notes: А • •* •* • Яб - - - • JBS • В • •* •* • 1 - - - • & • С • •* •* - • - - - • MS • D • • * •* - • - - - • & • Е • •* •* - MS - - - • & • F • • * •* - • - - - • & # G • •* •* - - - - • MS • н • • * •* - • - - - • • J • •* •* - • • • • & •

Я

P 50.1.027—2001

Окончание таблицы 4

Кодовая буква файла данных (см. таблицу 3) Заголовочная запись specversion: srcdoccid: :ppop|Sp datfilid: d-type: rorient: rpelcnt: rdensity: doccls: origfilid: notes: м • •* •* - jb$ - - - • JSS • N • •* •* - • - - - • & • О • •* •* - • - - - • & • Р • •* •* - • - - - • £$ • Q • •* • * - • - - - • & • R • •* •* - • •& •& •& • & • S • •* •* - • - - - • & • т • • * •* - • - - - • & • X • •* •* - • - - - • & • Z • •* •* - JBS - - - • & •

Обозначения: • — требуется; - — не требуется (запись не должна быть включена);

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

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

Таблица 5 — Форматы файлов данных

Тип файлов данных Нормативный документ Примечание Файлы данных, определенные в соглашении — Формат файлов определяется соглашением Файлы данных постра-ничного изображения в формате CGM ИСО 8632 (части 1-4) [8-11] — растровые ИСО/МЭК 11544 [12] в формате IGES ANSI/US PRO/IPO 100 [13] Файлы данных на языке PDL ИСО/МЭК 10180 [14] Файлы описания типа документа ИСО 8879 [1] Дополнительные требования к формату и содержанию файлов допускается определять в соглашении Файлы текста, размеченного в SGML Файлы текстовых объектов SGML

9

Окончание таблицы 5

Тип файлов данных Нормативный документ Примечание Файлы иллюстративных данных в формате IGES ANSI/US PRO/IPO 100 [13] Дополнительные требования к формату и содержанию файлов допускается определять в соглашении растровые ИСО/МЭК 11544 [12], ИСО/МЭК 12064-1 [15], EIA-538 [16] в формате CGM ИСО/МЭК 8632 (части 1-4) [8-11] в формате JPEG ИСО/МЭК 10918 (части 1, 3,4) [17-19] Файлы данных, содержащие чертежи в формате IGES ANSI/US PRO/IPO ПО [20] Дополнительные требования к содержанию файлов допускается определять в соглашении растровые ИСО/МЭК 11544 [12] в формате STEP ИСО 10303-201 [21] или ИСО 10303-202 [22] в формате ГОСТ Р ИСО 10303-21 в формате CGM ИСО/МЭК 8632 [8-1Ц Файлы производственных данных в формате STEP ИСО 10303-203 [2] в формате ГОСТ Р ИСО 10303-21 в формате IGES ANSI/US PRO/IPO 110 [20] управления конфигурацией ИСО 10303-203 [2] или ИСО 10303-214 [4] в формате ГОСТ Р ИСО 10303-21 управления оборудованием в формате NCM ИСО 3592 [31], ИСО 4342 [32], ИСО 4343 [3], ИСО 10303-213 [33] в формате ГОСТ Р ИСО 10303-21 Дополнительные требования к формату и содержанию файлов до-пускается определять в соглашении по электротехнике и электронике в формате EDIF EIA 548 [34] то же, в формате IGES ANSI/US PRO/IPO 111 [35] Файлы данных с информацией о стиле и формате ИСО 8879 [1]; ИСО/МЭК 10179 [5] Файлы, содержащие аудио-или видеоданные (файлы в формате MPEG) мультиплексные видеоданные аудиоданные ИСО/МЭК 11172 (части 1-3) [23-25] Файлы многоцелевых почтовых интернет-расширений (MIME) RFC 2045-RFC 2049 [26-29] — Файлы, содержащие черно-белые или цветные иллюстрации Формат файлов определяется соглашением Обыкновенные текстовые файлы ИСО/МЭК 8859-5 [30] Дополнительные требования к формату файлов допускается определять в соглашении Специальные словарные файлы Формат файлов определяется соглашением Файлы ЭЦП —

10

P 50.1.027-2001

6 Обеспечение безопасности данных

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

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

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

6.1    Электронные цифровые подписи

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

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

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

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

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

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

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

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

Таблица 6 — Назначение заголовочных записей ЭЦП

Запись Назначение sighash Содержит наименование подписанного файла, идентификационные данные алгоритма хэширования и значение хэширования в формате ASCII siginfo Содержит наименование подписанного файла, данные для идентификации подписавшего лица, данные об открытом ключе ЭЦП и о порядке следования подписей sigdata Содержит наименование подписанного файла, идентификационные данные применяемого алгоритма генерации ЭЦП и значение ЭЦП в формате ASCII

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

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

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

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

Генерируется хэшированием файлов данных, включая идентификационный блок, в лексичес-

11

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

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

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

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

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

Таблица 7 — Значения кодов алгоритма хэширования и подписи

Поле Значение поля Определение sigalgid WHF Асимметричный криптографический алгоритм с применением функции хэширования по ГОСТ Р 34.10. Значение версии всегда «NONE» hshalgid HFR Алгоритм вычисления функции хэширования по ГОСТ Р 34.11. Значение всегда «NONE»

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

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

Таблица 8 — Значения двоично-символьного преобразования

Битовая строка ASCII символ Битовая строка ASCII символ 0000 0 1000 8 0001 1 1001 9 0010 2 1010 А ООП 3 1011 в 0100 4 1100 с 0101 5 1101 D оно 6 1110 Е 0111 7 1111 F Примечание — В данном преобразовании используются ASCII символы верхнего регистра.

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

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

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

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

12

P 50.1.027-2001

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

6.2 Криптографическая защита (шифрование) данных

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 9 — Заголовочные записи шифрования и их назначение

Запись Назначение encdata: Содержит наименование зашифрованного файла, идентификационные и другие данные применяемого алгоритма шифрования dstinfo: Содержит наименование зашифрованного файла, идентификационные данные применяемого алгоритма шифрования и идентификационные данные получателя и его открытого ключа

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

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

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

13

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

7 Сжатие данных

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

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

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

7.1    Заголовочные записи сжатия

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

7.2    Выбор алгоритма сжатия

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

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

Таблица 10 — Значения кода идентификатора алгоритма сжатия

Поле Значение поля Определение cmpalgid GZIP формат файла GZIP (GNU zip) сжатия данных (RFC 1952) ZIP формат файла ZIP (фирма РК WARE) ARJ формат файла ARJ (фирма Aij Software) RAR формат файла RAR (фирма RarSoft)

14

P 50.1.027-2001

ПРИЛОЖЕНИЕ A (обязательное)

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

Таблица А.1 — Идентификаторы записей и общие требования к заполнению

Идентификатор записи Номер поля Требование к заполнению version: 1 Наименование стандарта 2 Идентификатор версии 3 Действительная дата выпуска (утверждения) стандарта Например для передаваемых единиц данных, сформированных и переданных в соответствии с настоящим стандартом, символьная строка будет: version: Р 50.1.027-2001, 0, 20001215 srcsys: 1 Наименование 2 Адрес 3 Любая другая информация, оговоренная в соглашении Например: srcsys: НИЦ АВС, Москва, 117234, а/я 23 srcdocid: Номер технического документа, номер чертежа изделия или идентификатор группы файлов базы данных srcrelid: Номер технического документа, номер чертежа изделия или идентификатор группы файлов базы данных chglvl: Значение полей записи приведено в таблице А. 2 1 Тип изменения 2 Номер версии 3 Номер изменения 4 Дата и время изменения (время не обязательно) Например: chglvl: REVISION W/CHG, G, 2, 19980804/1209:33 dteisu: Дата и время выпуска или самой последней проверки данных 1 Дата и время изменения (время не обязательно) Например: dteisu: 19980804/0000:00 dstsys: 1 Наименование 2 Адрес 3 Любая другая информация, оговоренная в соглашении Например: dstsys: АОЗТ «Каблук», Курск, 534127, а/я 10 dstdocid: Это может быть регистрационный номер (если такой существует по какому-нибудь каталогу или классификатору) или заголовок, или номер чертежа, или наименование группы файлов базы данных) 1 Символьный идентификатор Например регистрационный номер технической публикации: dstdocid: КС 681.2.002.031 РЭ dstrelid: Номер технического документа, номер чертежа изделия или идентификатор файла 1 Символьный идентификатор Например приложение к технической публикации: dstrelid: ИЕФ 581.6.003.362 РМ-01

15

Идентификатор записи	Номер поля	Требование к заполнению
dtetm:	Дата, когда передаваемая единица данных была передана передающей системой или записана на носитель, используемый для обмена данными
	1	Дата и время (время не обязательно)
	Например: dtetm: 20000804/0000:00
dlvacc:	Свободная форма записи, предоставляющая информацию о доставке, состав которой должен быть определен соглашением (например номер договора)
filcnt:	Каждому счетчику файлов предшествует кодовая буква из таблицы 4, используемая для обозначения типа файла. Поля должны быть разделены ASCII-символом запятой, за которым следует ASCII-символ пробела («, »). Если в передаваемой единице данных нет соответствующего типа файлов, то кодовая буква и счетчик файлов опускаются
	1	Набор символьных строк
	Например: filcnt: Т8, Q4, Cl, R1. Данная запись показывает, что передаваемая единица данных включает восемь файлов текста, закодированного и размеченного в SGML, четыре файла в формате IGES, один файл в формате CGM и один файл растровых данных
ttlcls:	Запись «ttlcls:» обязательна. Если понятие конфиденциальности не применимо к данной передаваемой единице данных, то как значение записи используется символьная строка «NA»
	1	Символьный идентификатор грифа конфиденциальности
	Например: ttlcls: NA
doccls:	Запись «doccls:» обязательна. Если секретность не применяется к данной передаваемой единице данных, то как значение записи используется строка «NA»
	1	Символьный идентификатор
	Например: doccls: NA
doctyp:	Символьная строка, используемая передающей системой для уникального распознавания типа данных
	Например для трехмерной модели изделия: doctyp: MD
docttl:	Символьная строка, содержащая заголовок данных, такой как заголовок технического руководства или наименование чертежа
	Например: docttl: руководство по ремонту
transacttyp:	Значениями этой записи могут быть «PAGE IMAGE», «PDL», «SGML», «PRODUCT DATA» и «MISCELLANEOUS»
	1	Символьный идентификатор (один из пяти)
	Например: transacttyp: PRODUCT DATA
rootfilid:	Это должен быть первый файл связанных данных в передаваемой единице данных (например первый элемент ИЭТР). В передаваемой единице данных должен быть только один корневой файл
	1	Наименование корневого файла данных
	2	Дата и время создания файла (допускается отсутствие)
	3	Размер файла в байтах (допускается отсутствие)
	Например: rootfilid:DOO1 ТО10, 19980415/0800:00, 8437

P 50.1.027-2001

Идентификатор записи Номер поля Требование к заполнению sighash: 1 Четыре символа для файла описания (например «D001») или восемь символов для файла данных (например «D001S002») 2 Идентификатор алгоритма хэширования (см. таблицу 7) 3 Версия алгоритма хэширования. Если идентификатора версии нет, то значение поля равно «0» 4 Вычисленное значение хэширования в формате ASCII Например: sighash: D001, WHF, 0,467CD86C8E8CC10E2A8BD5FB045C50B834DC556F siginfo: 1 Четыре символа для файла описания (например «D001») или восемь символов для файла данных (например «D001S002») 2 Наименование подписи (фамилия и инициалы подписавшего) 3 Заглавие подписи (должность подписавшего). Если поле не используется, его значение равно пустой строке (**) 4 Дата и время подписи 5 Первая подпись имеет значение «1». Значение поля для следующих подписей будет увеличиваться на 1. Если поле не используется, его значение равно «1» 6 Идентификатор открытого ключа подписи. Если поле не используется, его значение должно быть «NONE> Например: siginfo: D001T003, В. Сидоров, «» 19991221/2359:43, 1, NONE sigdata: 1 Четыре символа для файла описания (например «D001») или восемь символов для файла данных (например «D001S002») 2 Идентификатор алгоритма, используемого для генерирования ЭЦП (см. таблицу 7) 3 Версия алгоритма, указанного в поле 2. Если нет версии, то значение поля должно быть «0» 4 Идентификатор алгоритма хэширования (см. таблицу 7) 5 Версия алгоритма, указанного в поле 4. Если нет версии, то значение поля должно быть «0» 6 Определяет порядок применения подписей аналогично полю 5 записи «siginfo:» 7 Значение подписи, закодированное в ASCII символах (см. 6.1.4) Например: sigdata: D001, HFR, NONE, NONE, 1, 0,6C8BD8F8CC5E0CD4760985FBA456783FCDC50B843 encdata: 1 Четыре символа для файла описания (например «D001») или восемь символов для файла данных (например «D001S002») 2 Символьный идентификатор алгоритма, используемого для шифрования файла 3 Версия алгоритма, указанного в поле 2. Если у алгоритма нет версии, то значение поля равно «0» 4 Если нет дополнения, значение поля равно «0» 5 Если параметры инициализации ключа шифрования используются, то поле должно содержать символьную строку в соответствии с 6.1.4. Если инициализация ключа не используется, значение поля должно быть «NONE» Например: encdata: D001, WHF, 0, 0, 6C8BD8E8CC5E0CD476O985FBA456783FCDC5OB843, NONE

17

P 50.1.027-2001

Содержание

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

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

3    Определения и сокращения................................................... 1

4    Структура передаваемого пакета технических данных............................... 2

5    Структура и состав передаваемой единицы данных................................. 3

5.1    Структура передаваемой единицы данных....................................... 3

5.2 Состав передаваемой единицы данных......................................... 3

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

6    Обеспечение безопасности данных.............................................11

6.1    Электронные цифровые подписи.............................................11

6.2    Криптографическая защита (шифрование) данных................................13

7    Сжатие данных............................................................14

7.1    Заголовочные записи сжатия................................................14

7.2    Выбор алгоритма сжатия....................................................14

Приложение А Записи файла описания передаваемой единицы данных...................15

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

Приложение В Записи идентификационного блока файла передаваемой единицы данных.....20

Приложение Г Пример фрагмента файла передаваемой единицы данных..................23

Приложение Д Кодирование типа данных.........................................24

Приложение Е Применение записи «dtype:» для различных типов файлов.................27

Е.1    Тип А, файл данных, определенный в соглашении................................27

Е.2    Тип В, файл многоцелевых почтовых Интернет-расширений (MIME).................27

Е.З    Тип С, файл в формате CGM................................................27

Е.4 Тип D, файл ЭЦП........................................................28

Е.5 Тип Е, файл в формате EDIF................................................28

Е.6 Тип F, обыкновенный текстовый файл........................................28

Е.7    Тип G, файл описания типа документа........................................29

Е.8    Тип Н, файл данных с информацией о стиле и формате...........................29

Е.9 Тип J, файл в формате JPEG................................................29

Е.10 Тип    М, файл аудио- или видеоданных в формате MPEG..........................30

Е.11 Тип    N, файл текстового объекта SGML.......................................30

Е.12 Тип    О, файл в формате NCM...............................................30

Е.13 Тип    Р, файл в формате PDL................................................31

Е.14 Тип    Q, файл в формате IGES...............................................31

Е.15 Тип    R, файл растровых данных.............................................31

Е.16 Тип    S, файл в формате STEP........................................... 32

Е.17 Тип Т, текстовый файл SGML..............................................32

Е.18 Тип X, специальный словарный файл.........................................33

Е.19 Тип Z, файл данных с цветными или черно-белыми иллюстрациями.................33

Приложение Ж Запись требований к формату данных в соглашении.....................34

Ж.1 Требования к данным, передаваемым в растровом формате.........................34

Ж.2 Требования к данным об изделии в формате ИСО10303 (STEP).....................34

Приложение И Библиография..................................................35

III

Идентификатор записи	Номер поля	Требование к заполнению
dstinfo:	1	Четыре символа для файла описания (например «D001») или восемь символов для файла данных (например «D001S002»)
	2	Символьный идентификатор алгоритма
	3	Версия алгоритма, указанного в поле 2. Если у алгоритма нет версии, то значение поля равно «0»
	4	Если поле не используется, его значение равно «NONE»
	5	Если нет дополнения, значение поля равно «0»
	6	Если поле используется, то двоичное значение ключа преобразуется и записывается в соответствии с 6.1.4. Если поле не используется, его значение равно «NONE»
	Например: dstinfo: D001T003, WHF, SS135HGC, NONE, 0, NONE
cmpdata:	1	Четыре символа для файла описания (например «D001») или восемь символов для файла данных (например «D0Q1S002»)
	2	Идентификатор алгоритма сжатия (см. таблицу 10)
	3	Версия алгоритма, указанного в поле 2. Если у алгоритма нет версии, то значение поля равно «0»
	Например: cmpdata: D001Q004, ZIP, 2.04G

Таблица А.2 — Значения полей записи «chglvl:»

Тип изменения Номер версии Номер редакции Описание ORIGINAL 0 0 Подлинные данные ORIGINAL (W/CHG) 0 Порядковый номер редакции Подлинные данные с внесенными изменениями REVISION Порядковый номер версии 0 Полностью пересмотренные данные REVISION W/CHG Порядковый номер версии Порядковый номер редакции Пересмотренные данные с учтенными изменениями CHANGE (изменение) 0 Порядковый номер редакции Документ или данные, являющиеся изменением к материалу подлинника Прочее 0 0 Используется, когда ни один из перечисленных типов не применим Примечания 1    Значение поля «Номер версии» должно принимать значение «0», когда версия является исходным состоянием. 2    Значение поля «Номер редакции» должно принимать значение «0», когда редакция является исходным состоянием. 3    Понятие «редакция» обычно применяется к техническим руководствам, в то время как понятие «версия» — к чертежам и моделям. 4    Замечания, изменения и дополнения к стандартам и руководствам должны указываться с использованием поля «Номер версии».

18

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

Информационные технологии поддержки жизненного цикла продукции

АВТОМАТИЗИРОВАННЫЙ ОБМЕН ТЕХНИЧЕСКОЙ ИНФОРМАЦИЕЙ

Основные положения и общие требования

Continuous acquisition and life-cycle support. Automated interchange of technical information.

Overview and general requirements

Дата введения 2002—07—01

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

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

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

В настоящих рекомендациях использованы ссылки на следующие нормативные документы: ГОСТ 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    Определения и сокращения

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    файл ЭЦП: Файл, содержащий значение ЭЦП и сведения о ней.

3.2 Сокращения

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

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

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

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

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

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).

4 Структура передаваемого пакета технических данных

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

2

P 50.1.027-2001

Рисунок 1 — Логическая структура передаваемого пакета

5 Структура и состав передаваемой единицы данных

5.1 Структура передаваемой единицы данных

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

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

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

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

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

Рисунок 2 — Логическая структура передаваемой единицы данных

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

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

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

5.2 Состав передаваемой единицы данных

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

3

P 50.1.027-2001

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 Форматы файлов передаваемой единицы данных

P 50.1.027-2001

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

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

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

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

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

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

001 .. . 999,

А00 . . . А09, А0А . . . A0Z, А10 . . .A1Z, . . . , AY0 . . . AYZ, AZ0 . . . AZZ

В00 . . . В09, В0А . . . B0Z, В10 . . . 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» — четырехзначный год, «ММ» — месяц, «DD» — день месяца, «НННН» — часы (в 24-часовой системе, первые два символа — часы, последние два символа — минуты), «SS» — секунды.

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

Таблица 1 — Записи файла описания передаваемой единицы данных

Идентификатор записи Наименование записи Описание version: Идентификатор стандарта Строка, идентифицирующая стандарт, в соответствии с которым формируется передаваемая единица данных srcsys: Передающая система Строка, содержащая информацию, необходимую для идентификации системы, в которой формируется передаваемая единица данных srcdocid: Идентификатор данных передающей системы Строка, идентифицирующая данные в передающей системе. Состав строки определяется таблицей В.2 либо соглашением srcrelid: Идентификатор связанных данных передающей системы Строка, идентифицирующая связанные данные в передающей системе chglvl: Идентификатор и дата версии данных Символьная строка, идентифицирующая версию и дату последнего изменения данных (т. е. их актуальность) dteisu: Дата выпуска Строка, содержащая дату и время выпуска исходных данных dstsys: Принимающая система Строка, содержащая информацию, необходимую для идентификации принимающей системы

5

Окончание таблицы 1

Идентификатор записи Наименование записи Описание dstdocid: Идентификатор данных принимающей системы Строка, используемая принимающей системой для идентификации переданных данных dstrelid: Идентификатор взаимосвязанных данных принимающей системы Строка, идентифицирующая взаимосвязанные данные в принимающей системе dtetm: Дата передачи Строка, содержащая дату передачи или записи на носитель для обмена данными dlvacc: Состав квитанции о доставке Свободная форма записи, содержащая информацию о доставке, состав которой должен быть определен соглашением filcnt: Счетчик файлов Строка, содержащая счетчики файлов каждого типа в передаваемой единице данных ttlcls: Метка конфиденциальности названия Строка, содержащая метку уровня конфиденциальности или другие ограничения на заголовок данных. Использование и состав меток должны быть определены в соглашении doccls: Метка конфиденциальности данных Строка, содержащая наивысший уровень конфиденциальности или других ограничений на файлы в передаваемой единице данных в целом. Использование и состав меток должны быть определены в соглашении doctyp: Тип данных Строка, идентифицирующая тип данных docttl: Заголовок данных Строка, идентифицирующая данные transacttyp: Тип передаваемой единицы данных Строка, идентифицирующая тип передаваемой единицы данных rootfilid: Идентификатор корневого файла Строка с наименованием корневого файла для связанных данных (например в формате SGML) sighash: Алгоритм хэширования и выработки ЭЦП Строка, идентифицирующая подписанный ЭЦП файл данных и алгоритм используемой ЭЦП. На каждый подписанный файл должна быть одна запись «sighash:» siginfo: Информация об ЭЦП Строка, содержащая информацию об ЭЦП, требуемую при аутентификации подписанного файла данных. Для одной ЭЦП должна быть одна запись «siginfo:» sigdata: Данные ЭЦП Строка, содержащая ЭЦП и информацию, необходимую при аутентификации файла данных. Для одной ЭЦП должна быть одна запись «sigdata:» Encdata: Данные шифрования Строка, идентифицирующая зашифрованный файл данных и примененный алгоритм. Для каждого зашифрованного файла должна быть одна запись «encdata:» dstinfo: Данные получателя Строка, идентифицирующая получателя и данные, требуемые для дешифрования файла данных. Для каждого получателя зашифрованных файлов должна быть одна запись «dstinfo:» cmpdata: Данные сжатия Строка, идентифицирующая сжатый файл данных и примененный алгоритм сжатия. Для каждого сжатого файла должна быть одна запись «cmpdata:»

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

P 50.1.027-2001

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

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 — Кодовые буквы для наименования формата файла

Кодовая буква Тип файла данных Фиксированная длина записи Фиксированная длина блока А Файл данных, определенный в соглашении 256 2048 В Файл многоцелевых почтовых Интернет-расширений MIME 256 2048 С Файл в формате CGM 80 800 D Файл ЭЦП 256 2048 Е Файл в формате EDIF 80 800 F Обыкновенный текстовый файл 80 800 G Файл описания типа документа 256 2048 Н Файл с информацией о стиле и формате 256 2048 I Файл в формате IPC 256 2048 J Файл в формате JPEG 128 2048 м Файл, содержащий аудио- или видеоданные 128 2048 N Файл текстового объекта SGML 256 2048 О Файл в формате NCM 80 800 р Файл в формате PDL 128 2048 Q Файл в формате IGES 80 800 R Файл растровых данных 128 2048 S Обменный файл в формате STEP 80 800 Т Файл текста, размеченного в SGML 256 2048 X Специальный словарный файл 256 2048 Z Файл, содержащий иллюстрации 128 2048 I, К L, U, V, W Зарезервированы — —

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

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

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

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

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

7