Товары в корзине: 0 шт Оформить заказ
Стр. 1
 

39 страниц

319.00 ₽

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

Официально распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль".

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

Оглавление

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

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

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

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

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

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

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

Приложения

Показать даты введения Admin

Страница 1

У#'*’/

\

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

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

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

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

ч

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

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

Страница 2

Предисловие

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

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

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

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

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

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

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

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ Информационные технологии поддержки жизненного цикла продукции АВТОМАТИЗИРОВАННЫЙ ОБМЕН ТЕХНИЧЕСКОЙ ИНФОРМАЦИЕЙ Основные положения и общие требования

Р 50.1.027-2001

БЗ 12—2000/2*

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

Им. лиц. Xt 02354 от 14.07.2000. Сдано в набор 14.08.2001. Подписано в печать 09.10.2001. Формат 60 * 84 '/«• Бумага офсетная. Гарнитура Таймс. Печать офсетная. Усл.печд 4,65. Уч.-имл 3,90.

Тираж 506 эю. Зак. 953. Им X» 2763/4. С 2278

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

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

Плр N» 080102

Страница 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

III

Страница 4

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

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

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

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

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    комплект носителей: Один или несколько носителей одного типа, содержащие информацию передаваемого пакета.

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

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

Страница 5

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/1PO на обмен графическими данными (от 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

Страница 6

P 50.1.027-2001

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3

Страница 7

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

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

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

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

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

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

e)    смешанная единица, например содержащая данные о составе изделия по ИСО 10303-214 (4J, представленные в формате ГОСТ Р ИСО 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] и других — для задания стиля и оформления информации), которая должна быть указана в соглашении; этот файл необязателен;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Страница 8

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

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

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

Идентификатор

записи

Наименование записи

Описание

version:

Идентификатор

стандарта

Строка, идентифицирующая стандарт, в соответствии с которым формируется передаваемая единица данных

sresys:

Передающая система

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

srcdocid:

Идентификатор данных передающей системы

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

srcrclid:

Идентификатор связанных данных передающей системы

Строка, идентифицирующая связанные данные в передающей системе

chglvl:

Идентификатор и дата версии данных

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

dteisu:

Дата выпуска

Строка, содержащая дату и время выпуска исходных данных

dstsyy

Принимающая система

Строка, содержащая информацию, необходимую для идентификации принимающей системы

5

Страница 9

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

Идентификатор

записи

Наименование записи

Описание

dstdocid:

Идентификатор данных принимающей системы

Строка, используемая принимающей системой для идентификации переданных данных

dstrelid:

Идентификатор взаимосвязанных данных принимающей системы

Строка, идентифицирующая взаимосвязанные данные в принимающей системе

dtetm:

Дата передами

Строка, содержащая дату передачи или записи на носитель для обмена данными

dlvacc:

Состав квитанции о доставке

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

(Dent:

Счетмик файлов

Строка, содержащая счетчики файлов каждого типа в передаваемой единице данных

ttlcls:

Метка

конфиденциальности

названия

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

doccls:

Метка

конфиденциальности

данных

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

doctyp:

Тип данных

Строка, идентифицирующая тип данных

docttl:

Заголовок данных

Строка, идентифицирующая данные

transaettyp:

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

Строка, идентифицирующая тип передаваемой единицы данных

rootfilid:

Идентификатор корневого файла

Строка с наименованием корневого файла для связанных данных (например в формате SGML)

sigh ash:

Алгоритм хэширования и выработки ЭЦП

Строка, идентифицирующая подписанный ЭЦП файл данных и алгоритм используемой ЭЦП. На каждый подписанный файл должна быть одна запись «sighash:*

siginfo:

Информация об ЭЦП

Строка, содержащая информацию об ЭЦП, требуемую при аутентификации подписанного файла данных. Для одной ЭЦП должна быть одна запись «siginfo:*

sigdata:

Данные ЭЦП

Строка, содержащая ЭЦП и информацию, необходимую при аутентификации файла данных. Для одной ЭЦП должна быть одна запись «sigdata:»

Encdata:

Данные шифрования

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

dstinfo:

Данные получателя

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

empdata:

Данные сжатия

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

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

Страница 10

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

1

Кодовая буква

Тип файла данных

Фиксированная длина записи

Фиксированная длина блока

А

Файл данных, определенный в соглашении

256

2048

в

Файл многоцелевых почтовых Интернет-расширений MIME

256

2048

с

Файл в формате CGM

80

800

D

Файл ЭЦП

256

2048

Е

Файл в формате EDIF

80

800

F

Обыкновенный текстовый файл

80

800

G

Файл описания типа документа

256

2048

Н

Файл с информацией о стиле и формате

256

2048

I

Файл в формате 1 PC

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, К. Ц и, V, W

Зарезервированы

-

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

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

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

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

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

7

Страница 11

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

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

Идентификатор

записи

Наименование записи

Описание

speeversion:

1

Версия стандарта

Строка, идентифицирующая стандарт, определяющий формат и содержание файла данных

srcdocid:

Идентификатор данных передающей системы

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

dstdocid

Идентификатор данных принимающей системы

Строка, идентифицирующая переданные данные. Должна быть идентична полю «dstdocid:» файла описания

datfilid:

Идентификатор способа обработки данных

Строка, определяющая требования к обработке, необходимой для использования данных

d-type.

Тип данных Идентификатор типа файла данных (см. приложение F.)

rorient:

Ориентация растрового Направление последовательности элементов изображения по изображения горизонтали и направление последовательности линий

rpelcnt:

1—-- -j

Счетчики элементов ;Целочисленные счетчики хлементов изображения,

растрового изображения содержащихся в линии, и самих линий

rdensity:

Плотность растрового изображения

Строковое предста&псние числового значения плотности растрового изображения

Doccls:

Метка конфиден ци ал ьности

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

Origfilid

Исходное наименование файла

Строка, содержащая исходное наименование файла данных в передающей системе

notes:

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

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

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

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

Кодовая буква файла данных (см. таблицу 3)

Заголовочная запись

specvcreion:

srcdocid:

|

s

I

■о

rorient:

Ъ

j

&

V.

1

I

J

3

!

i

А

• •

•*

-

-

-

&

В

••

•*

1

-

-

-

&

С

• •

-

-

-

&

D

• •

• •

-

-

&

Е

••

• •

-

&

F

• •

••

-

-

-

&

G

• •

••

-

-

Н

• •

••

-

-

&

J

• •

••

-

&

&

Я

Страница 12

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

Заголовочная запись

Кодовая буква файла данных (см. таблицу 3)

speeversion:

|

J

datfilid:

|

■о

rorient:

|

doeeb

1

notes

М

••

••

MS

.

.

MS

N

• •

••

-

-

MS

О

••

•*

.

-

MS

Р

••

.

-

MS

0

• •

• •

.

.

MS

R

• •

•&

•&

•&

MS

S

• •

• •

.

-

MS

Т

• •

••

-

-

MS

X

• •

••

.

-

MS

г

• •

MS

.

MS

Обозначения:

• — требуется;

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

MS — наличие записи определяется соглашением;

• — должна быть идентична записи файла описания (см. таблицу 5), кроме производственных данных;

& — обязательно для растровых данных типа I (см. таблиц)' Е.15). Нс используется для файлов растровых ____данных других типов _

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

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

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

Тип файлов данных

Нормативный документ

Примечание

Файлы данных, определенные в соглашении

Формат файлов определяется соглашением

Файлы данных п остра-яичного изображения

в формате CGM

ИСО 8632 (части 1-4) (8-11)

растровые

ИСО/МЭК 11544 [12]

в формате IGES

ANSJ/US PRO/IPO 100 113)

Файлы данных на языке PDL

ИСО/МЭК 10180 1141

Файлы описания типа документа

ИСО 8879 (1]

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

Файлы текста, размеченного в SGML

Файлы текстовых объектов SGML

9

Страница 13

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

Тил файлов данных

Нормативный документ

Примечание

Файлы иллюстративных данных

i

в формате IGES

ANSI/US PRO/1PO 100 1131

Дополнительные требования к формату и содержанию файлов до-пускается определять в соглашении

растровые

ИСО/МЭК 11544 (121, ИСО/МЭК 12064-1 [15), EIA-538 (16)

в формате CGM

ИСО/МЭК 8632 (части 1-4)[8-11)

в формате JPEG

ИСО/МЭК 10918 (части 1, 3, 4) (17-19)

'Файлы данных, содержащие чертежи

I

в формате IGES

ANSI/US PRO/IPO 110 _1201

Дополнительные трсбо-

растровые

ИСО/МЭК 11544 (12)

в формате STEP

ИСО 10303-201 |2! | или ИСО 10303-202 ( 221 в формате ГОСТ Р ИСО 10303-21

в формате CGM

ИСО/МЭК 8632 (8-11)

ваиия к содержанию файлов допускается определять в соглашении

Файлы производственных данных

в формате STEP

ИСО 10303-203 |2) в формате ГОСТ Р ИСО 10303-21

в формате IGES

ANSI/US PRO/IPO 110 1201

управления конфигурацией

ИСО 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 135)

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

ИСО 8879 [1); ИСО/МЭК 10179 |5)

Файлы, содержащие аудио-или видеоданные (файлы в формате MPEG)

мультиплексные

видеоданные

аудиоданные

ИСО/МЭК 11172 (части 1-3) (23-251

Файлы многоцелевых почтовых интернет-расширений (MIME)

RFC 2045-RFC 2049 [26-29)

Файлы, содержащие черно-белые или цветные иллюстрации

Формат файлов определяется соглашением

Обыкновенные текстовые файлы

ИСО/МЭК 8859-5 (30)

»

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

Специальные словарные файлы

Формат файлов определяется соглашением

Файлы ЭЦП

10

Страница 14

P 50.1.027-2001

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запись

Назначение

sighash

Содержит наименование подписанного файла, идентификационные данные алгоритма хэширования и значение хэширования в формате ASCII

siginfo

Содержит наименование подписанного файла, данные для идентификации подписавшего лица, данные об открытом ключе ЭЦП и о порядке следования подписей

sigdata

Содержит наименование подписанного файла, идентификационные данные применяемого алгоритма генерации ЭЦП и значение ЭЦП в формате ASCII

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

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

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

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

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

11

Страница 15

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

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

Страница 16

P 50.1.027-2001

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запись

Назначение

enedata:

Содержит наименование зашифрованного файла, идентификационные и другие данные применяемого алгоритма шифрования

dstinfo:

Содержит наименование зашифрованного файла, идентификационные данные применяемого алгоритма шифрования и идентификационные данные получателя и его открытого ключа

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

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

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

13

Страница 17

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

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

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

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

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

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

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

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

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

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

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

Поле

Значение поля

Определение

cmpalgid

GZIP

формат файла GZIP (GNU zip) сжатия данных (RFC 1952)

ZIP

формат файла ZIP (фирма РК WARE)

ARJ

формат файла ARJ (фирма Arj Software)

RAR

формат файла RAR (фирма RarSoft)

14

Страница 18

P 50.1.027-2001

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

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

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

Идентификатор

записи

Номер поля

Требование к заполнению

version:

1

Наименование стандарта

2

Идентификатор версии

3

Действительная дата выпуска (утверждения) стандарта

Например для передаваемых единиц данных, сформированных и переданных в соответствии с настоящим стандартом, символьная строка будет: version: Р 50.1.027-2001. 0. 20001215

srcsys:

1

Наименование

2

Адрес

3

Любая другая информация, оговоренная в соглашении

Например: sresys: НИЦ АВС. Москва, 117234, а/я 23

srcdocid:

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

src relid:

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

chgM:

Значение полей записи приведено в таблице А.2

1

Тип изменения

2

Номер версии

3

Номер изменения

4

Дата и время изменения (время нс обязательно)

Например:

chgM: REVISION W/CHG, G. 2, 19980804/1209:33

dteisu:

Дата и время выпуска или самой последней проверки данных

1

Дата и время изменения (время не обязательно)

Например, dteisu: 19980804/0000:00

dstsys:

1

Наименование

2

Адрес

3

Любая другая информация, оговоренная в соглашении

Например:

dstsys: АОЗТ «Каблук», Курск. 534127, а/я 10

dstdocid:

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

1

1 Символьный идентификатор

Например регистрационный номер технической публикации: dstdocid: КС 681.2.002 031 РЭ

dst relid:

Номер технического документа, номер чертежа изделия или идентификатор файла

1

(Символьный идентификатор

Например приложение к технической публикации: dst relid: ИЕФ 581.6.003.362 РМ-01

15

Страница 19

Продолжение та&шцы А. 1

Идентификатор

записи

Номер поля

Требование к заполнению

dtctrn:

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

Дата и время (время не обязательно)

Например: dtclm: 20000804/0000:00

dlvacc:

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

filcnt:

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

1 | Набор символьных строк

Например: filcnt: Т8, Q4.C1, RI.

Данная запись показывает, что передаваемая единица данных включает восемь файлов текста, закодированного и размеченного в SGML, четыре файла в формате IGES, один файл в формате CGM и один файл растровых данных

(tlcls:

Запись «ttlcls:» обязательна. Если понятие конфиденциальности нс применимо к данной передаваемой единице данных, то как значение записи используется символьная строка «NA*

1

Символьный идентификатор грифа конфиденциальности

Например: ttlcls: NA

doccls:

Запись «doccls * обязательна. Если секретность нс применяется к данной передаваемой единице данных, то как значение записи используется строка «NA*

1

Символьный идентификатор

Например: docck: NA

doctyp:

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

Например для трехмерной модели изделия: doctyp. MD

docttl

Символьная

руководства

строка, содержащая заголовок данных, такой как заголовок технического или наименование чертежа

!

Например: docttl: руководство по ремонту

transaettyp:

Значениями этой записи могут быть «PAGE IMAGE», «PDL*, «SGML», «PRODUCT DATA» и «MISCELLANEOUS»

I

(Символьный идентификатор (один из пяти)

Например: transaettyp: PRODUCT DATA

rootfilid:

Эго должен быть первый файл связанных данных в передаваемой единице данных (например первый элемент ИЭТР). В передаваемой единице данных должен быть только один корневой файл

1

{Наименование корневого файла данных

2

Дата и время создания файла (допускается отсутствие)

3

Размер файла в байтах (допускается отсутствие)

Например: rootfilid:D001 ТО 10. 19980415/0800:00. 8437

16

Страница 20

P 50.1.027-2001

Продсмжение таблицы А. I

Идентификатор

записи

Номер поля

Требование к заполнению

sigh ash:

1

Четыре символа для файла описания (например «D001») или восемь символов для файла данных (например «D00IS002*)

2

Идентификатор алгоритма хэширования (см. таблицу 7)

3

Версия алгоритма хэширования. Если идентификатора версии нет, то значение поля равно *0»

4

Вычисленное значение хэширования в формате ASCII

Например:

sighash: D00I, WHF. 0.467CD86C8E8CC10E2A8BD5FB045C50B834DC556F

siginfo:

1

Четыре символа для файла описания (например «D001») или восемь символов для файла данных (например «DO0IS0O2*)

2

Наименование подписи (фамилия и инициалы подписавшего)

3

Заглавие подписи (должность подписавшего). Если поле нс используется, его значение равно пустой строке (**)

4

Дата и время подписи

5

Первая подпись имеет значение «1*. Значение поля для следующих подписей будет увеличиваться на 1.

Если поле нс используется, его значение равно «1*

6

Идентификатор открытого ключа подписи. Если поле не используется, его значение должно быть «NONE»

Например:

siginfo: D00IT003, В. Сидоров. «. 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.6C8BD8F8CC5E0CCW760985FBA456783FCDC50B843

encdata:

1

Четыре символа для файла описания (например «D00U) или восемь символов для файла данных (например «D001S002*)

2

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

3

Версия алгоритма, указанного в поле 2. Если у длгоритма нет версии, то значение поля равно «0*

4

Если нет дополнения, значение поля равно «0*

5

Если параметры инициализации ключа шифрования используются, то поле должно содержать символьную строку в соответствии с 6.1.4. Если инициализация ключа нс используется, значение поля должно быть «NONE*

Например:

encdata: D00I, WHF. 0. 0. 6C8BD8E8CC5E0CD476O985FBA456783FCDC5OB843, NONE

17