Р 50.1.027-2001. Рекомендации по стандартизации. Информационные технологии поддержки жизненного цикла продукции. Автоматизированный обмен технической информацией. Основные положения и общие требования
Актуально на 01.11.2026.
Как цитировать: "Р 50.1.027-2001. Рекомендации по стандартизации. Информационные технологии поддержки жизненного цикла продукции. Автоматизированный обмен технической информацией. Основные положения и общие требования". Р 50.1.027-2001. https://bukva.ai/docs/trebovaniya-r-50-1-027-2001
(приняты и введены в действие Постановлением Госстандарта России от 02.07.2001 № 256-ст)
Примечание
Документ введен в действие с 01.07.2002.
РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ ПОДДЕРЖКИ
ЖИЗНЕННОГО ЦИКЛА ПРОДУКЦИИ
АВТОМАТИЗИРОВАННЫЙ ОБМЕН ТЕХНИЧЕСКОЙ ИНФОРМАЦИЕЙ
ОСНОВНЫЕ ПОЛОЖЕНИЯ И ОБЩИЕ ТРЕБОВАНИЯ
Continuous acquisition and life-cycle support. Automated
interchange of technical information. Overview
and general requirements
1 июля 2002 года
Предисловие
1 РАЗРАБОТАНЫ Научно-исследовательским центром (НИЦ) CALS-технологий «Прикладная логистика» при участии Всероссийского научно-исследовательского института стандартизации (ВНИИстандарт)
ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 431 «CALS-технологии»
2 ПРИНЯТЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Постановлением Госстандарта России от 2 июля 2001 г. № 256-ст
3 Настоящие рекомендации разработаны с учетом требований MIL Std 1840 C
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 представлена логическая структура передаваемого пакета.
Рисунок 1 — Логическая структура передаваемого пакета
5 Структура и состав передаваемой единицы данных
5.1 Структура передаваемой единицы данных
На нижнем уровне логической структуры пакета находятся передаваемые единицы данных, каждая из которых состоит из файла описания передаваемой единицы и файлов данных. Логическая структура передаваемой единицы данных приведена на рисунке 2.
Файл описания передаваемой единицы данных (далее — файл описания) содержит всю информацию, необходимую для однозначной идентификации передаваемой единицы данных, и содержит информацию о каждом файле, содержащемся в этой передаваемой единице данных.
Файл передаваемой единицы данных (далее — файл данных) имеет специальный формат и логически разделен на две части: идентификационный и содержательный блоки.
Идентификационный блок, приписываемый к файлу данных при формировании передаваемой единицы данных, состоит из записей, содержащих информацию, необходимую для корректного распознавания и обработки данных содержательного блока. Структура и состав этих записей определяются настоящими рекомендациями.
Содержательный блок состоит из собственно передаваемых данных.
Структура и состав содержательного блока каждого файла должны соответствовать требованиям, предъявляемым к типу передаваемой единицы данных (см. 5.3).
В минимальном варианте передаваемая единица данных состоит из одного файла описания и хотя бы одного файла данных.
Группирование файлов в передаваемые единицы данных и объединение их в передаваемую группу зависит от назначения передаваемой информации.
5.2 Состав передаваемой единицы данных
Каждая передаваемая единица данных представлена в формате, регламентированном настоящими рекомендациями. Дополнительные требования могут быть определены в договоре или иной форме соглашения между организациями, представляющими передающую и принимающую системы (в дальнейшем — соглашение).
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 Передаваемая единица данных постраничного изображения должна состоять из:
b) произвольного количества файлов постраничного изображения, дополнительные требования к которым оговариваются в соглашении;
c) произвольного количества специальных словарных файлов, содержание которых должно быть оговорено в соглашении;
d) произвольного количества файлов ЭЦП.
Под понятием «произвольное количество» здесь и ниже подразумевается: ни одного, один или несколько файлов обсуждаемого типа.
5.2.1.2 Передаваемая единица данных на языке PDL должна состоять из:
b) одного или нескольких файлов PDL, конкретный формат которых оговаривается в соглашении;
c) произвольного количества файлов ЭЦП.
5.2.1.3 Передаваемая единица данных на языке SGML должна состоять из:
b) произвольного количества файлов описания типа документа;
c) одного файла текста, размеченного по правилам SGML;
d) произвольного количества файлов объектов, выполненных в стандарте, отличном от SGML, таких как иллюстрации или аудио- или видеофайлы;
e) файла данных со спецификацией форматного вывода (на языке DSSSL [5] и других — для задания стиля и оформления информации), которая должна быть указана в соглашении; этот файл необязателен;
f) произвольного количества специальных словарных файлов;
g) произвольного количества оговоренных соглашением файлов;
h) произвольного количества файлов ЭЦП.
5.2.1.4 Передаваемая единица производственных данных должна состоять из:
b) произвольного количества файлов данных, содержащих чертежи в форматах IGES, STEP (см. 5.3.2.2.3) или в растровом формате, конкретные требования к которому должны быть оговорены в соглашении;
c) произвольного количества файлов данных о структуре и свойствах изделия, представленных в формате обменных файлов согласно ГОСТ Р ИСО 10303-21;
d) произвольного количества файлов данных по электротехнике и электронике, формат которых определяется соглашением;
e) произвольного количества файлов данных с управляющими программами для автоматизированного оборудования, формат которых определяется соглашением;
f) произвольного количества файлов ЭЦП.
5.2.1.5 Смешанная передаваемая единица данных должна состоять из:
b) хотя бы одного файла данных из типов, указанных в таблице 2, допустимые используемые форматы должны быть оговорены в соглашении;
c) произвольного количества файлов ЭЦП.
5.3 Форматы файлов передаваемой единицы данных
Данный раздел регламентирует правила присвоения наименований, формат и содержание файлов описания и идентификационного блока файлов данных.
5.3.1 Файл описания передаваемой единицы данных
5.3.1.1 Наименование файла описания
Наименование должно быть длиной четыре символа; первый символ должен быть D; последние три символа должны быть ASCII-представлением [6] алфавитно-числового идентификатора для передаваемой единицы данных. Этот 4-символьный идентификатор обеспечивает уникальное наименование для каждой передаваемой единицы данных в передаваемой группе. Алфавитно-числовой идентификатор для каждого файла описания должен начинаться с «001» и наращиваться в упорядоченной последовательности (с преобразованием в строку ASCII) для каждой добавляемой передаваемой единицы данных, содержащейся в передаваемой группе. Для построения действительных алфавитно-числовых идентификаторов должны применяться следующие правила.
a) После чисел от «001» до «999», исчерпанных как идентификаторы, в целях расширения группы идентификаторов должны использоваться ASCII буквы верхнего регистра от «A» до «Z»
b) Лексическая прогрессия должна развертываться от «001» до «ZZZ», например:
A00 . . . A09, A0A . . . A0Z, A10 . . . A1Z, . . . , AY0 . . . AYZ, AZ0 . . . AZZ
B00 . . . B09, B0A . . . B0Z, B10 . . . B1Z, . . . , BY0 . . . BYZ, BZ0 . . . BZZ
Z00 . . . Z09, Z0A . . . Z0Z, Z10 . . . Z1Z, . . . , ZY0 . . . ZYZ, ZZ0 . . . ZZZ
5.3.1.2 Формат файла описания
Файл описания должен состоять из записей фиксированной длины по 128 байт каждая. Все записи должны быть представлены в символьном формате ASCII. Назначение каждой записи указано в таблице 1, при этом записи файла описания должны всегда следовать в том порядке, в котором они приведены в таблице. Во всех записях значения даты и даты-времени должны соответствовать универсальному скоординированному времени [7] и использовать формат «YYYYMMDD/HHHH:SS», где «YYYY» — четырехзначный год, «MM» — месяц, «DD» — день месяца, «HHHH» — часы (в 24-часовой системе, первые два символа — часы, последние два символа — минуты), «SS» — секунды.
Каждая запись в качестве первых символов должна иметь идентификатор записи из таблицы 1; два последних символа идентификатора должны быть символом двоеточия и следующим за ним символом пробела. Для определения границ поля данных используется символ запятой, за которым следует символ пробела. Пробел после запятой не относится к данным, последующие пробелы являются частью данных.
Записи файла описания передаваемой единицы данных
| Идентификатор записи | Наименование записи | Описание |
|---|---|---|
| version: | Идентификатор стандарта | Строка, идентифицирующая стандарт, в соответствии с которым формируется передаваемая единица данных |
| srcsys: | Передающая система | Строка, содержащая информацию, необходимую для идентификации системы, в которой формируется передаваемая единица данных |
| srcdocid: | Идентификатор данных передающей системы | Строка, идентифицирующая данные в передающей системе. Состав строки определяется таблицей В.2 либо соглашением |
| srcrelid: | Идентификатор связанных данных передающей системы | Строка, идентифицирующая связанные данные в передающей системе |
| chglvl: | Идентификатор и дата версии данных | Символьная строка, идентифицирующая версию и дату последнего изменения данных (т.е. их актуальность) |
| dteisu: | Дата выпуска | Строка, содержащая дату и время выпуска исходных данных |
| dstsys: | Принимающая система | Строка, содержащая информацию, необходимую для идентификации принимающей системы |
| dstdocid: | Идентификатор данных принимающей системы | Строка, используемая принимающей системой для идентификации переданных данных |
| dstrelid: | Идентификатор взаимосвязанных данных принимающей системы | Строка, идентифицирующая взаимосвязанные данные в принимающей системе |
| dtetrn: | Дата передачи | Строка, содержащая дату передачи или записи на носитель для обмена данными |
| 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».
Пример файла описания приведен в приложении Б.
5.3.1.3 Запрет на использование символа NULL
В файлах описания и во всех заголовочных записях, описываемых настоящими рекомендациями, запрещено использование символа NULL (в таблице ASCII — положение 0/0).
5.3.2 Файл передаваемой единицы данных
5.3.2.1 Наименование файла данных
Наименование должно быть длиной восемь символов, где первые четыре символа должны быть такими же, как наименование файла описания (см. 5.3.1.1). Пятый символ должен быть кодом из таблицы 2, определяющим формат файла данных. Последние три символа должны быть символьным представлением алфавитно-числового идентификатора от «001» до «ZZZ», правила формирования которого аналогичны приведенным в 5.3.1.1.
Каждая заголовочная запись идентификационного блока файла данных должна быть фиксированной длины (в байтах), указанной в таблице 2, вне зависимости от типа носителя, применяемого для передачи информации. Каждая заголовочная запись должна быть дополнена до соответствующей длины в байтах при помощи символа пробела (позиция 2/0 таблицы ASCII).
Идентификационный блок файла данных должен быть фиксированной длины (в байтах), указанной в таблице 2. Идентификационный блок файла данных должен быть дополнен символами пробела (позиция 2/0 таблицы ASCII) до соответствующей длины в байтах. Размер идентификационного блока определяет начало действительных данных передаваемого файла.
5.3.2.2 Формат файла передаваемой единицы данных
5.3.2.2.1 Формат идентификационного блока файла данных
Идентификационный блок файла данных состоит из символьных записей в коде ASCII. Общий синтаксис записей идентификационного блока -<идентификатор>:<содержание>. В таблице 3 представлен полный список всех возможных записей идентификационного блока файлов данных. Общий синтаксис записи -<поле 1, поле 2, . . . , поле n>. Поля разделяются символом запятой, за которым следует символ пробела. Требования к содержанию полей приведены в приложении В. Во всех записях значения даты и даты-времени должны соответствовать универсальному скоординированному времени (см. 5.3.1.2).
Заголовочные записи файла передаваемой единицы данных
| Идентификатор записи | Наименование записи | Описание |
|---|---|---|
| specversion: | Версия стандарта | Строка, идентифицирующая стандарт, определяющий формат и содержание файла данных |
| srcdocid: | Идентификатор данных передающей системы | Строка, идентифицирующая связанные данные, к которым этот файл принадлежит или на который дается ссылка |
| dstdocid: | Идентификатор данных принимающей системы | Строка, идентифицирующая переданные данные. Должна быть идентична полю «dstdocid:» файла описания |
| datfilid: | Идентификатор способа обработки данных | Строка, определяющая требования к обработке, необходимой для использования данных |
| d-type: | Тип данных | Идентификатор типа файла данных (см. приложение Е) |
| rorient: | Ориентация растрового изображения | Направление последовательности элементов изображения по горизонтали и направление последовательности линий |
| rpelcnt: | Счетчики элементов растрового изображения | Целочисленные счетчики элементов изображения, содержащихся в линии, и самих линий |
| rdensity: | Плотность растрового изображения | Строковое представление числового значения плотности растрового изображения |
| Doccls: | Метка конфиденциальности | Строка, характеризующая уровень конфиденциальности файла данных. Состав меток определяется соглашением |
| Origfilid: | Исходное наименование файла | Строка, содержащая исходное наименование файла данных в передающей системе |
| notes: | Примечания | Произвольный текст, содержащий любые разрешенные для заголовочных записей символы |
5.3.2.2.2 Применяемость записей заголовочного блока файла передаваемой единицы данных
Применяемость записей заголовочного блока в зависимости от типа файла данных приведена в таблице 4. Идентификационный блок каждого файла данных каждого типа должен содержать все обязательные записи, указанные в таблице 4. Записи должны всегда следовать в том порядке, в котором они расположены в таблице, неиспользуемые записи опускаются.
| Кодовая буква файла данных (см. таблицу 3) | Заголовочная запись | ||||||||||
| specversion: | srcdocid: | dstdocid: | datfilid: | d-type: | rorient: | rpelcnt: | rdensity: | doccls: | origfilid: | notes: | |
| A |  |  * |  * |  |  | - | - | - |  |  |  |
| B |  |  * |  * |  | 1 | - | - | - |  |  |  |
| C |  |  * |  * | - |  | - | - | - |  |  |  |
| D |  |  * |  * | - |  | - | - | - |  |  |  |
| E |  |  * |  * | - |  | - | - | - |  |  |  |
| F |  |  * |  * | - |  | - | - | - |  |  |  |
| G |  |  * |  * | - |  | - | - | - |  |  |  |
| H |  |  * |  * | - |  | - | - | - |  |  |  |
| J |  |  * |  * | - |  |  |  |  |  |  |  |
| M |  |  * |  * | - |  | - | - | - |  |  |  |
| N |  |  * |  * | - |  | - | - | - |  |  |  |
| O |  |  * |  * | - |  | - | - | - |  |  |  |
| P |  |  * |  * | - |  | - | - | - |  |  |  |
| Q |  |  * |  * | - |  | - | - | - |  |  |  |
| R |  |  * |  * | - |  |  & |  & |  & |  |  |  |
| S |  |  * |  * | - |  | - | - | - |  |  |  |
| T |  |  * |  * | - |  | - | - | - |  |  |  |
| X |  |  * |  * | - |  | - | - | - |  |  |  |
| Z |  |  * |  * | - |  | - | - | - |  |  |  |
Обозначения: - требуется;- — не требуется (запись не должна быть включена);  - наличие записи определяется соглашением;* — должна быть идентична записи файла описания (см. таблицу 5), кроме производственных данных; & — обязательно для растровых данных типа 1 (см. таблицу Е.15). Не используется для файлов растровых данных других типов. | |||||||||||
Когда алфавитно-числовые данные, необходимые для размещения в записи, не существуют, должна быть использована символьная строка «NONE». Когда данные для этой записи неизвестны, должен быть использован ASCII-символ «0».
5.3.2.2.3 Формат содержательного блока файла данных
Форматы содержательного блока файлов данных каждого типа в составе передаваемой единицы данных должны соответствовать требованиям, определяемым стандартами и другими нормативными документами, указанными в таблице 5 и приложении Е.
| Тип файлов данных | Нормативный документ | Примечание | |
| Файлы данных, определенные в соглашении | - | Формат файлов определяется соглашением | |
| Файлы данных постраничного изображения | в формате CGM | ИСО 8632 (части 1 — 4) [8 - 11] | - |
| растровые | ИСО/МЭК 11544 [[12]](#p102294) | ||
| в формате IGES | ANSI/US PRO/IPO 100 [[13]](#p102296) | ||
| Файлы данных на языке PDL | ИСО/МЭК 10180 [[14]](#p102298) | ||
| Файлы описания типа документа | ИСО 8879 [[1]](#p102272) | Дополнительные требования к формату и содержанию файлов допускается определять в соглашении | |
| Файлы текста, размеченного в SGML | |||
| Файлы текстовых объектов SGML | |||
| Файлы иллюстративных данных | в формате IGES | ANSI/US PRO/IPO 100 [[13]](#p102296) | |
| растровые | ИСО/МЭК 11544 [[12]](#p102294), ИСО/МЭК 12064-1 [[15]](#p102300), EIA-538 [[16]](#p102302) | ||
| в формате CGM | ИСО/МЭК 8632 (части 1 — 4) [8 - 11] | ||
| в формате JPEG | ИСО/МЭК 10918 (части 1, 3, 4) [17 - 19] | ||
| Файлы данных, содержащие чертежи | в формате IGES | ANSI/US PRO/IPO 110 [[20]](#p102310) | Дополнительные требования к содержанию файлов допускается определять в соглашении |
| растровые | ИСО/МЭК 11544 [[12]](#p102294) | ||
| в формате STEP | ИСО 10303-201 [[21]](#p102312) или ИСО 10303-202 [[22]](#p102314) в формате ГОСТ Р ИСО 10303-21 | ||
| в формате CGM | ИСО/МЭК 8632 [8 - 11] | ||
| Файлы производственных данных | в формате STEP | ИСО 10303-203 [[2]](#p102274) в формате ГОСТ Р ИСО 10303-21 | |
| в формате IGES | ANSI/US PRO/IPO 110 [[20]](#p102310) | ||
| управления конфигурацией | ИСО 10303-203 [[2]](#p102274) или ИСО 10303-214 [[4]](#p102278) в формате ГОСТ Р ИСО 10303-21 | ||
| управления оборудованием в формате NCM | ИСО 3592 [[31]](#p102336), ИСО 4342 [[32]](#p102338), ИСО 4343 [[3]](#p102276), ИСО 10303-213 [[33]](#p102340) в формате ГОСТ Р ИСО 10303-21 | Дополнительные требования к формату и содержанию файлов допускается определять в соглашении | |
| по электротехнике и электронике в формате EDIF | EIA 548 [[34]](#p102342) | ||
| то же, в формате IGES | ANSI/US PRO/IPO 111 [[35]](#p102344) | ||
| Файлы данных с информацией о стиле и формате | ИСО 8879 [[1]](#p102272); ИСО/МЭК 10179 [[5]](#p102280) | ||
| Файлы, содержащие аудио- или видеоданные (файлы в формате MPEG) | мультиплексные | ИСО/МЭК 11172 (части 1 — 3) [23 - 25] | |
| видеоданные | |||
| аудиоданные | |||
| Файлы многоцелевых почтовых интернет-расширений (MIME) | RFC 2045 — RFC 2049 [26 - 29] | - | |
| Файлы, содержащие черно-белые или цветные иллюстрации | Формат файлов определяется соглашением | ||
| Обыкновенные текстовые файлы | ИСО/МЭК 8859-5 [[30]](#p102334) | Дополнительные требования к формату файлов допускается определять в соглашении | |
| Специальные словарные файлы | Формат файлов определяется соглашением | ||
| Файлы ЭЦП | - | ||
6 Обеспечение безопасности данных
Передача данных, представляющих коммерческую или военную тайну, должна проводиться в соответствии с установленными организационными правилами информационной безопасности.
Физическая безопасность и защита данных и идентификационных записей в передаваемой группе определяется характеристиками защиты передающей и принимающей систем. Организационная безопасность должна быть подробно описана в соглашении.
Метка конфиденциальности данных в заголовочной записи должна применяться для всех файлов данных. Значения меток конфиденциальности данных должны быть определены в соглашении.
6.1 Электронные цифровые подписи
ЭЦП предназначена для авторизации и обнаружения изменений либо ненамеренной порчи данных при информационном обмене. ЭЦП может указать, имели ли место изменения в подписанных данных или нет, но с ее помощью нельзя определить, где конкретно эти изменения возникли.
ЭЦП может быть применена к файлу описания, одному или нескольким файлам данных или передаваемому пакету в целом.
Цифровые подписи не защищают конфиденциальные данные от несанкционированного доступа.
6.1.1 Заголовочные записи подписи
Заголовочные записи ЭЦП должны быть сформированы в соответствии с таблицами 6, А.1 и требованиями настоящего раздела. Подписаны могут быть один или несколько файлов данных либо передаваемая единица данных в целом.
При использовании ЭЦП файл описания должен содержать одну запись «sighash:» для каждой подписи передаваемой единицы данных, а также по одной записи «sighash:» для каждого подписанного файла передаваемой единицы данных. Кроме записи «sighash:», для каждой подписи должны присутствовать по одной записи «siginfo» и «sigdata:». Записи об ЭЦП должны быть сохранены в файле описания в порядке, указанном в таблице 1. Записи об ЭЦП передаваемой единицы данных должны идти перед ЭЦП для файлов данных, подписанных индивидуально.
Записи об ЭЦП передаваемой единицы данных должны следовать в порядке, указанном в соответствующих полях записей siginfo и sigdata. (см. приложение А). Записи об ЭЦП файлов данных должны следовать в лексическом порядке файлов данных в передаваемой единице данных и в порядке, указанном в соответствующих полях записей siginfo и sigdata (пример приведен в приложении Б).
Порядок следования и правила формирования полей записей «sighash:», «siginfo» и «sigdata:» приведены в приложении А.
6.1.2 Цифровая подпись передаваемых данных
Хэширование и цифровая подпись вычисляются по всем передаваемым данным. Идентификационный блок также используется при вычислении хэширования. Хэширование вычисляется после того, как данные были подготовлены передающей системой. Проверка подписи выполняется перед преобразованиями данных в формат принимающей системы. ЭЦП, подтверждающая передаваемую единицу или файл данных, обеспечивает проверку целостности данных, включая предыдущие подписи.
6.1.2.1 ЭЦП передаваемых единиц данных
Генерируется хэшированием файлов данных, включая идентификационный блок, в лексическом порядке по именам файлов. ЭЦП вычисляется для передаваемой единицы данных целиком, и результат сохраняется в заголовочных записях цифровой подписи в файле описания. ЭЦП передаваемой единицы данных проверяется по получении файлов данных в том же лексическом порядке (по имени файла), который был применен при генерации подписи(ей).
6.1.2.2 ЭЦП файлов данных
Генерируется по всему файлу передаваемой единицы данных. Результат сохраняется в заголовочных записях цифровой подписи о конкретном файле данных в файле описания передаваемой единицы данных. Проверяется ЭЦП также по всему файлу данных.
6.1.3 Выбор алгоритмов хэширования и подписи
Если для вычисления ЭЦП используются алгоритмы хэширования и подписи, отличные от приведенных в таблице 7, то они должны быть особо оговорены в договоре или иной форме соглашения.
Значения кодов алгоритма хэширования и подписи
| Поле | Значение поля | Определение |
| sigalgid WHF | ||
| Асимметричный криптографический алгоритм с применением функции хэширования по ГОСТ Р 34.10. Значение версии всегда «NONE» | hshalgid | HFR |
| Алгоритм вычисления функции хэширования по ГОСТ Р 34.11. Значение всегда «NONE» | 6.1.4 Преобразование двоичных данных в строку ASCII | |
Результатом выполнения вышеуказанных алгоритмов являются двоичные данные. Для их включения в заголовочную запись файла необходимо преобразовать вычисленное значение хэширования, идентификатора открытого ключа и значение ЭЦП из двоичного в символьное представление. Каждый 4-битный блок должен быть преобразован в символ ASCII, начиная с наиболее значащих (первых) четырех бит, в соответствии с таблицей 8.
Значения двоично-символьного преобразования
При обработке принимающей системой данных хэширования и кодирования ключей обмена они конвертируются обратно к двоичной форме реверсированием этого преобразования.
6.1.5 Тип файла цифровой подписи
ЭЦП как отдельные файлы (файлы типа «D» рассмотрены в приложении Е) могут быть объединены в передаваемой единице данных с файлами данных (перечисленными в таблице 2). Эти подписи могут использоваться для проверки целостности данных, содержащихся в файлах данных, или для архивных целей. Данные в каждом файле типа D состоят исключительно из записей «sighash:», «siginfo:» и «sigdata:» (см. таблицу 6). Запись «sighash:» в файле типа D содержит поле имени файла данных, которому соответствуют подписи, все остальные поля опускаются. Значения полей записи «siginfo:» и «sigdata:» определяются таблицей А.1.
6.1.6 Определение подлинности ЭЦП
Средства определения подлинности ЭЦП и их источников находятся за пределами области действия настоящих рекомендаций. Обмен ключами ЭЦП, а также соответствующими им идентификаторами между системами, участвующими в передаче, проводится с использованием средств, не зависящих от обмена данными, которые используют этот механизм. Порядок использования ЭЦП должен быть описан в соглашении.
6.2 Криптографическая защита (шифрование) данных
Шифрование предназначено для защиты данных от несанкционированного доступа. Шифрование может быть применено к одному или нескольким файлам данных или передаваемой единице данных в целом.
Шифрование производится по всем передаваемым данным, включая идентификационный блок. Шифрование производится после того, как данные были подготовлены передающей системой. Дешифрование выполняется перед преобразованиями данных в формат принимающей системы.
6.2.1 Шифрование передаваемых единиц данных
Выполняется путем шифрования файлов данных, включая идентификационный блок, в лексическом порядке по именам файлов, и результат сохраняется в заголовочных записях данных шифрования в файле описания. Файл описания передаваемой единицы данных не шифруется. Дешифрование файлов данных производится по получении файлов передаваемой единицы данных в том же лексическом порядке (по именам файлов).
6.2.2 Шифрование файлов передаваемой единицы данных
Выполняется путем шифрования конкретного файла передаваемой единицы данных целиком. Результат сохраняется в заголовочных записях цифровой подписи о зашифрованном файле данных в файле описания передаваемой единицы данных.
6.2.3 Заголовочные записи шифрования
Информация о шифровании размещается в записях «encdata:» и «datinfo:» файла описания передаваемой единицы данных. Файл описания не шифруется. Когда к одному файлу данных применены и шифрование, и хэширование (как часть генерации цифровой подписи), то сначала применяется алгоритм шифрования, а хэширование вычисляется на зашифрованных данных.
6.2.4 Структура и поля заголовочных записей
Поля заголовочных записей заполняются в соответствии с таблицами 9, А.1 и требованиями настоящего раздела. Зашифрованная передаваемая единица данных должна содержать все входящие в нее файлы данных целиком, в лексическом порядке по именам файлов. Запись «encdata:» добавляется к файлу. Запись «encdata:» определяет зашифрованную передаваемую единицу данных и содержит идентификатор алгоритма, используемого для шифрования. Для каждого получателя зашифрованной передаваемой единицы данных запись «dstinfo:» должна быть добавлена к файлу описания. Запись «dstinfo:» идентифицирует получателя(ей) передаваемой единицы данных, используемый алгоритм шифрования и обеспечивает каждого получателя идентификатором ключа шифрования, записываемым в соответствующем поле.
Заголовочные записи шифрования и их назначение
Запись «encdata:» добавляется к файлу описания для каждого зашифрованного файла данных (исключая шифрование передаваемой единицы данных целиком). Для каждого получателя зашифрованных данных к файлу описания добавляется запись «dstinfo:». Поля в записях информации о шифровании разделяются символом пробела, следующей за символом запятой.
Порядок следования и пример формирования полей записей «encdata» и «dstinfo» приведены в таблице А.1.
6.2.5 Управление ключами шифрования
Средства и механизмы управления работой с ключами шифрования настоящими рекомендациями не регламентируются. Обмен ключами шифрования и соответствующими идентификаторами между системами, участвующими в передаче данных, должны обеспечиваться средствами, не зависящими от способа обмена данными. Способы и методы управления ключами шифрования описываются в соглашении.
7 Сжатие данных
Для сокращения количества носителей или ускорения электронной передачи данные могут быть сжаты. Сжатие файлов данных может быть выборочным, т.е. перед передачей могут быть сжаты один или несколько файлов данных либо вся передаваемая единица данных. Сжимаются все передаваемые данные целиком, включая идентификационный блок файла данных. Распаковка данных выполняется перед любыми преобразованиями данных в формат принимающей системы.
Информация о сжатии помещается в запись «cmpdata:» в файле описания передаваемой единицы данных. Сам файл описания не сжимается.
Если к одним и тем же данным применяются и сжатие, и шифрование, то в первую очередь осуществляется сжатие, а шифрование применяется уже к сжатым данным.
7.1 Заголовочные записи сжатия
Заголовочные записи сжатия кодируются в соответствии с таблицей 10. Сжатая передаваемая единица данных содержит в алфавитном порядке все файлы данных передаваемой единицы данных целиком. Запись «cmpdata:» добавляется к файлу описания и описывает алгоритм, используемый для сжатия передаваемой единицы данных. Для каждого файла данных (исключая сжатие передаваемой единицы данных целиком) запись «cmpdata:» добавляется к файлу описания. Поля в заголовочной записи сжатия разделяются символом запятой, за которым следует символ пробела. Пример заполнения записи приведен в приложении А.
7.2 Выбор алгоритма сжатия
Применение алгоритмов сжатия регламентируется соглашением. Некоторые распространенные алгоритмы и форматы перечислены в таблице 10.
Если используется алгоритм из таблицы 10, то значение кода идентификатора алгоритма сжатия равно значению соответствующего поля таблицы, иначе используется идентификатор алгоритма, определяемый соглашением.
| Идентификатор записи | Номер поля | Требование к заполнению |
| version: | 1 | Наименование стандарта |
| 2 | Идентификатор версии | |
| 3 | Действительная дата выпуска (утверждения) стандарта | |
| Например для передаваемых единиц данных, сформированных и переданных в соответствии с настоящим стандартом, символьная строка будет: version: Р 50.1.027-2001, 0, 20001215 | ||
| srcsys: | 1 | Наименование |
| 2 | Адрес | |
| 3 | Любая другая информация, оговоренная в соглашении | |
| Например: srcsys: НИЦ ABC, Москва, 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 | ||
| dtetrn: | Дата, когда передаваемая единица данных была передана передающей системой или записана на носитель, используемый для обмена данными | |
| 1 | Дата и время (время не обязательно) | |
| Например: dtetrn: 20000804/0000:00 | ||
| dlvacc: | Свободная форма записи, предоставляющая информацию о доставке, состав которой должен быть определен соглашением (например номер договора) | |
| filcnt: | Каждому счетчику файлов предшествует кодовая буква из таблицы 4, используемая для обозначения типа файла. Поля должны быть разделены ASCII-символом запятой, за которым следует ASCII-символ пробела («, »). Если в передаваемой единице данных нет соответствующего типа файлов, то кодовая буква и счетчик файлов опускаются | |
| 1 | Набор символьных строк | |
| Например: filcnt: T8, Q4, C1, 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: D001T010, 19980415/0800:00, 8437 | ||
| 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, 6C8BD8E8CC5E0CD4760985FBA456783FCDC50B843, NONE | ||
| 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») или восемь символов для файла данных (например «D001S002») |
| 2 | Идентификатор алгоритма сжатия (см. таблицу 10) | |
| 3 | Версия алгоритма, указанного в поле 2. Если у алгоритма нет версии, то значение поля равно «0» | |
| Например: cmpdata: D001Q004, ZIP, 2.04G | ||
srcdocid: Система наведения, вариант 4
srcrelid: Авионика СУ-27, вариант 2
chglvl: REVISION W/CHG, G, 2, 19980804/1209:33
dlvacc: раздел A006, контракт N33400-93-C1053, 19970915
docttl: система навигации СУ-27
rootfilid: D001T007, 19990802/0800:00, 54317
sighash: D001, ACA-WHF, 1, 1, 0, 467CD86C8E8CC10E2A8BD5FB045C50B834DC556F
siginfo: D001, В. Сидоров, , 19991221/2359:42, 1, NONE
sigdata: D001, HFR, NONE, NONE, 1, 0, 6C8BD8E8CC5E0CD4760985FBA456783FCDC50B843
sighash: D001T003, ACA-WHF, 1, 1, 0, 467CD86C8E8CC10E2A8BD5FB045C50B834DC556F
siginfo: D001T003, В. Сидоров, , 19991221/2359:43, 1, NONE
sigdata: D001T003, HFR, NONE, NONE, 1, 0, C5E0CD47606C8BD8E8C9FBA4DC50B5678C8385F43
| Идентификатор записи | Номер поля | Требование к заполнению |
| specversion: | Для любого типа файла данных, кроме типа A, строка, определяющая формат и содержание файла данных. Для файла данных типа A строка, особо оговариваемая в соглашении, где необходимо максимально подробно сформулировать условия подготовки пересылаемых данных, версию порождающей их программной системы, используемые трансляторы и устанавливаемые параметры. При отсутствии точного наименования спецификации (или просто его незнания, например в силу недоступности конфиденциальных данных фирмы) идентификатор может быть любой, но он должен быть однозначно определен соглашением и желательно увязан с какими-либо характерными признаками передающей системы (например AutoCAD R14.01) | |
| 1 | Номер документа | |
| 2 | Версия | |
| 3 | Редакция | |
| 4 | Дата принятия спецификации (документа). Формат даты должен быть «YYYYMMDD» | |
| Например: specversion: ИСО 10303-203, 0, 0, 19940101 | ||
| srcdocid: | 1) Строка должна быть равна строке записи идентификатора данных передающей системы («srcdocid:») файла описания. Исключением являются файлы передаваемых единиц производственных данных. 2) Для передаваемых единиц производственных данных первые 57 байт записи «srcdocid:» должны соответствовать таблице В.2. Оставшиеся байты должны быть заполнены символом пробела («») или использованы согласно соглашению | |
| dstdocid | Строка должна быть такой же, как идентификатор принимающей системы («dstdocid:») файла описания. Если объект передается более чем в одной передаваемой единице данных, то к идентификатору должны быть добавлены вводные слова «Multiple Documents» (многотомные документы) | |
| datfilid: | Строка должна содержать оговоренное в соглашении описание содержания и типа обработки данного файла. Например в соглашении можно потребовать включения этой записи для обозначения обработки, необходимой для использования данных | |
| d-type: | Зависит от типа файла | Если иначе не оговорено соглашением, эта запись должна принимать значения в соответствии с приложением Е |
| rorient: | Если строковое представление значения меньше трех символов, строка должна быть дополнена символом пробела. Если файл данных использует более одного значения ориентации, то значением должна быть символьная строка «MIXED» (смешанный). Поля должны быть разделены символом запятой, за которой следует символ пробела. Допустимые величины элементов изображения и линейного направления перечислены в ИСО/МЭК 11544 [[12]](#p102294) | |
| 1 | Выровненная по правому краю трехсимвольная строка. Задает направление последовательности элементов изображения по горизонтали | |
| 2 | Выровненная по правому краю трехсимвольная строка. Задает направление последовательности линий | |
| Например: rorient: 270, 90 | ||
| rpelcnt: | Поля должны быть разделены символом запятой, за которой следует символ пробела. Если файл данных использует более одного счетчика, то значением должна быть символьная строка «MIXED» | |
| 1 | Выровненная по правому краю шестисимвольная строка. Если величина меньше шести символов, строка должна быть дополнена символами пробела | |
| 2 | Выровненная по правому краю шестисимвольная строка. Если величина меньше шести символов, строка должна быть дополнена символами пробела | |
| Например: rpelcnt: 4400, 6800 | ||
| rdensity: | Выровненная по правому краю четырехсимвольная строка. Если строковое представление значения меньше четырех символов, строка должна быть дополнена символом пробела. Если плотность переменная, то должна быть использована символьная строка «MIXED». Допустимые величины плотности изображения перечислены в ИСО/МЭК 11544 [[12]](#p102294) | |
| Например: rdensity: 200 | ||
| doccls: | 1 | Символьная строка. Запись «doccls:» применяется при передаче всех файлов данных. Значения должны быть оговорены в соглашении. Если понятие конфиденциальности не применяется к данному файлу, то значением записи должна быть строка «NA» |
| Например: doccls: UNCLASSIFIED | ||
| origfilid: | Поля должны разделяться символом запятой и следующим за ним символом пробела | |
| 1 | Исходное наименование файла данных | |
| 2 | Дата и время создания файла (допускается отсутствие) | |
| 3 | Размер файла в байтах (допускается отсутствие) | |
| Например: origfilid: HW-01.01.dxf, 19970731/1659:59, 1167129 | ||
| notes: | Произвольный текст, содержащий разрешенные для заголовочных записей символы | |
| Позиция в записи | Наименование элемента данных | Содержание |
| 1 — 10 | Идентификатор записи | Символьная строка «srcdocid:» включает символ пробела в 10-й позиции, следующей за двоеточием |
| 11, 12 a | Тип данных | Код типа данных. Значением этого поля должен быть код типа данных в соответствии с таблицей Д.1, если иначе не было оговорено в соглашении (например шифр вида документов по ГОСТ 2.102, ГОСТ 2.601) |
| 13 — 32 a/n lj | Идентификатор документа | Идентификатор документа (например номер чертежа) |
| 33, 34 a/n rj | Идентификатор изменения | Номер версии. Цифровое значение версии преобразуют в символьный код, используя таблицу Д.3 |
| 35, 36 a/n | Вид сопроводительного документа | Код типа сопроводительных данных в соответствии с таблицей Д.2, если иначе не было оговорено в соглашении |
| 37 — 43 a/n | Идентификатор сопроводительного документа | Символьная строка, идентифицирующая сопроводительный документ |
| 44 a | Версия сопроводительного документа | Версия сопроводительного документа. Цифровое значение версии преобразуют в символьный код, используя таблицу Д.3 |
| 45 a | Общая метка конфиденциальности данных | Метка, определяющая допустимость распространения данных, ассоциированных с документом. Если иначе не было указано в соглашении, этот код должен быть «L» для ограниченного или «U» для неограниченного распространения данных |
| 46, 47 a | Метка конфиденциальности | Определяет уровень конфиденциальности, назначенный для листа. Используемые коды определяются соглашением |
| 48 — 52 n | Номер листа | Номер листа документа, имеющего унифицированную форму представления |
| 52, 53 a/n rj | Формат | Если данные представляют из себя документ, имеющий унифицированную форму представления. Коды формата должны соответствовать ГОСТ 2.301 |
| 54 — 57 n | Итого листов | Общее количество листов документа, имеющего унифицированную форму представления (определенном в позициях 13 — 27) |
| 58 — 128 a lj | Резерв | Резервное поле должно быть заполнено символами пробела либо его использование должно быть оговорено соглашением |
| Обозначения: a — только буквы ASCII верхнего регистра; a/n — алфавитно-числовой; только буквы ASCII верхнего регистра и цифры; lj — выровненный по левому краю, далее дополненный символом пробела; n — числовой; только ASCII — числа от «0» до «9», с ведущими нулями («0»); rj — выровненный по правому краю, неиспользуемые левые позиции заполнены ASCII-нулями («0»). | ||
ПРИМЕР ФРАГМЕНТА ФАЙЛА ПЕРЕДАВАЕМОЙ ЕДИНИЦЫ ДАННЫХ
specversion: Unigraphics 15. 0
srcdocid: Р 50.1.027-2001-2, 0, 20001222
notes: файл типа S (обменный файл согласно ГОСТ Р ИСО 10303-21; данные представлены по ИСО 10303-203)
FILE_DESCRIPTION ((' '), '2;1');
FILE_NAME ('as132-ug', '1999-01-13T11:17:57-06:00', (' '), (' '), 'STDEVELOPER 1.6', 'UNIGRAPHICS SOLUTIONS — UNIGRAPHICS 15.0', ' ');
FILE_SCHEMA (('CONFIG_CONTROL_DESIGN', ' '));
#10=PERSON_AND_ORGANIZATION_ROLE ('classification_officer');
#11=CC_DESIGN_PERSON_AND_ORGANIZATION_ASSIGNMENT (#3114, #10, (#3111));
#13=COORDINATED_UNIVERSAL_TIME_OFFSET (0, 0, .BEHIND.);
#14=LOCAL_TIME (0, 0, 0., #13);
#16=DATE_TIME_ROLE ('classification_date');
#17=CC_DESIGN_DATE_AND_TIME_ASSIGNMENT (#15, #16, (#3111));
#3103=CARTESIAN_POINT (' ', (42.5, 13., 37.0096189432334));
#3104=DIRECTION (' ', (0., -1., 0.));
#3105=DIRECTION (' ', (0., 0., -1.));
#3106=AXIS2_PLACEMENT_3D (' ', #3103, #3104, #3105);
#3107=ITEM_DEFINED_TRANSFORMATION (' ', ' ', #613, #3106);
#3108=(REPRESENTATION_RELATIONSHIP (' ', ' ', #2769, #2919)
REPRESENTATION_RELATIONSHIP_WITH_TRANSFORMATION (#3107)
SHAPE_REPRESENTATION_RELATIONSHIP());
#3109=NEXT_ASSEMBLY_USAGE_OCCURRENCE ('1009', ';
| Код | Документ |
|---|---|
| AM | Поправка |
| AN | Приложение |
| LT | Письмо |
| AT | Дополнение |
| NT | Заметка |
| SP | Спецификация |
Е.1 Тип A, файл данных, определенный в соглашении
Все файлы данных типа A должны быть обязательно подробно оговорены в соглашении. Формат индивидуальных кодов записи «dtype:» для файла данных типа A должен соответствовать приведенным в таблице Е.1 либо оговоренным в соглашении.
| Кодовая буква | Тип файла данных | DTYPE: код | Ссылочный документ | Описание |
| A | Файл, определенный в соглашении | PRJ, DT | - | Все коды записи «dtype:» для файлов данных типа A должны быть определены в соглашении |
| Проектный код | ||||
| PRJ | - | Строка, идентифицирующая конкретный проект. Значение должно быть определено в соглашении | ||
| Код подтипа файла данных | ||||
| DT | - | Строка, идентифицирующая подтип файла данных для данного проекта. Значение должно быть определено в соглашении | ||
| Примечания 1 Для кодов PRJ и DT может быть использована любая ASCII-строка с учетом ограничений по длине заголовочной записи из таблицы 3. 2 Пример записи «dtype:» для файла данных проекта под названием «PRODUCT_1», с определенным для него подтипом «FORMAT_A»: dtype: PRODUCT_1, FORMAT_A | ||||
Е.2 Тип B, файл многоцелевых почтовых Интернет-расширений (MIME)
Файлы типа B используются для передачи данных, закодированных в виде MIME как файла данных. Коды записи «dtype:» для файла данных типа B должны соответствовать приведенным в таблице Е.2 либо быть особо оговорены в соглашении.
| Кодовая буква | Тип файла данных | DTYPE: код | Ссылочный документ | Описание |
| B | Файл MIME | MIME | RFC 2046, RFC 2047, RFC 2049 [27 - 29] | Файл в формате MIME |
| Multipart/Mixed | Файл в формате MIME с инкапсулированными файлами данных | |||
| Примечание — Пример записи «dtype:» для файла MIME с несколькими инкапсулированными файлами данных: dtype: Multipart/Mixed | ||||
Е.3 Тип C, файл в формате CGM
Файлы данных типа C содержат иллюстрации и графические объекты согласно ИСО 8632. Для файла данных типа C запись «dtype:» имеет синтаксис <версия метафайла, палитра>. Коды записи «dtype:» должны соответствовать представленным в таблице Е.3 либо быть особо оговорены в соглашении.
| Кодовая буква | Тип файла данных | DTYPE: код | Ссылочный документ | Описание |
| C | Файл в формате CGM | Код версии метафайла | ||
| 1 | ИСО 8632 [8 - 11] | Метафайл Версия 1 | ||
| 2 | Метафайл Версия 2 | |||
| 3 | Метафайл Версия 3 | |||
| 4 | Метафайл Версия 4 | |||
| Код палитры | ||||
| A | ИСО 8632 [8 - 11] | Монохромный | ||
| B | Черно-белый | |||
| C | Цветной | |||
| Примечание — Пример записи «dtype:» для файла данных, содержащего CGM-иллюстрацию в метафайле версии 1 с черно-белым изображением: dtype: 1, B | ||||
Е.4 Тип D, файл ЭЦП
Файлы данных типа D должны содержать данные ЭЦП, определенные в 6.1.5. Код данных типа D должен соответствовать представленному в таблице Е.4.
Е.5 Тип E, файл в формате EDIF
Файл данных типа E содержит данные по электротехническому и электронному проектированию. Код записи «dtype:» для файла данных типа E должен соответствовать таблице Е.5 либо быть особо оговорен в соглашении.
Е.6 Тип F, обыкновенный текстовый файл
Файлы данных типа F должны быть описаны в соглашении. Допустимые коды записи «dtype:» для подтипов файла данных типа F должны соответствовать представленным в таблице Е.6 либо оговоренным в соглашении.
Необходимо иметь в виду, что подтип не определяет и не идентифицирует различия в файлах данных различных операционных систем. Это актуально для специальных символов (например конец строки, конец файла). Преобразование этих различий должно выполняться программным обеспечением по обработке данных на локальных системах. Для предотвращения непреднамеренного изменения переданных данных в соглашении должно быть особо оговорено, какая из систем (передающая либо принимающая) производит эти преобразования.
Е.7 Тип G, файл описания типа документа
Файл типа G должен состоять из описания типа документа без каких-либо иных данных согласно ИСО 8879. В случае, когда описание типа документа добавлено к началу файла, файл данных должен передаваться как тип T. Код записи «dtype:» для файла данных типа G должен соответствовать представленному в таблице Е.7 либо указанному в соглашении.
Е.8 Тип H, файл данных с информацией о стиле и формате
Файлы данных типа H необходимы для отображения размеченных SGML-данных. Коды записи «dtype:» для файла данных типа H должны соответствовать приведенным в таблице Е.8 либо быть особо оговорены в соглашении.
Е.9 Тип J, файл в формате JPEG
Допустимый код записи «dtype:» для файла данных типа J должен соответствовать представленному в таблице Е.9 либо указанному в соглашении.
| Кодовая буква | Тип файла данных | DTYPE: код | Ссылочный документ | Описание |
| J | Файл в формате JPEG | 0 | ИСО/МЭК 10918 [17 - 19] | Файл, содержащий изображение в формате JPEG |
| Примечание — Пример записи «dtype:» файла данных, содержащего отсканированную фотографию, закодированную в качестве цветного JPEG-изображения: dtype: 0 | ||||
Е.10 Тип M, файл аудио- или видеоданных в формате MPEG
Допустимые коды записи «dtype:» для файла данных типа M должны соответствовать представленным в таблице Е.10 либо быть указаны в соглашении.
Е.11 Тип N, файл текстового объекта SGML
Файлы данных типа N, содержащие текстовые объекты SGML, должны соответствовать ИСО 8879. Допустимый код записи «dtype:» для файла данных типа № должен соответствовать представленному в таблице Е.11 либо указанному в соглашении.
Е.12 Тип O, файл в формате NCM
Файлы данных типа O содержат производственные данные. Допустимые коды записи «dtype:» для файла данных типа O должны соответствовать представленным в таблице Е.12 либо быть особо оговорены в соглашении.
Е.13 Тип P, файл в формате PDL
Файлы данных типа P содержат данные по компоновке страниц в электронной форме. Коды записи «dtype:» для файла данных типа P должны соответствовать представленным в таблице Е.13 либо быть особо оговорены в соглашении.
Е.14 Тип Q, файл в формате IGES
Файлы данных типа Q могут быть любыми из нескольких типов иллюстрированных, чертежных, проектных или производственных данных об изделии. Допустимые коды записи «dtype:» для файла данных типа Q должны соответствовать представленным в таблице Е.14 либо быть особо оговорены в соглашении.
Е.15 Тип R, файл растровых данных
Файлы данных типа R содержат растровые данные. Допустимые коды записи «dtype:» для файла данных типа R должны соответствовать представленным в таблице Е.15 либо быть особо оговорены в соглашении.
Е.16 Тип S, файл в формате STEP
Файлы данных типа S содержат данные об изделии в ИСО 10303 (STEP). Допустимые коды записи «dtype:» для файла данных типа S должны соответствовать представленным в таблице Е.16 либо быть особо оговорены в соглашении.
Если файл данных использует более одного класса соответствия, код(ы) дополнительного класса соответствия должны быть разделены ASCII-символом запятой и ASCII-символом пробела. Допускается записывать только один, самый старший поддерживаемый класс соответствия используемого протокола применения.
Если файл данных не соответствует ни одному классу соответствия, в качестве кода класса должен быть использован символ нуля («0»).
Е.17 Тип T, текстовый файл SGML
Файлы данных типа T должны содержать текст с разметкой по стандарту SGML. Допустимые коды записи «dtype:» для файла данных типа T должны соответствовать представленным в таблице Е.17 либо быть особо оговорены в соглашении.
Е.18 Тип X, специальный словарный файл
Формат и содержание специальных словарных файлов в общем случае определяются соглашением. Допустимый код записи «dtype:» файла данных типа X должен соответствовать представленному в таблице Е.18 либо указанному в соглашении.
Е.19 Тип Z, файл данных с цветными или черно-белыми иллюстрациями
Формат файлов и их содержание для черно-белых либо цветных иллюстрационных данных должны быть указаны в соглашении. Допустимый код записи «dtype:» для файла данных типа Z должен соответствовать представленному в таблице Е.19 либо указанному в соглашении.
Ж.1 Требования к данным, передаваемым в растровом формате
Использование данных в растровой форме обеспечивает возможности просмотра, архивации и комментирования/аннотирования данных. Бумажная документация может требоваться в дополнение к растровым данным только для проверки растрового содержания данных. При выполнении работ по контрактам с зарубежными партнерами допускается использовать требования изменений в MIL-Std-1840 C [43].
1 Данные должны быть представлены на магнитной ленте с девятью треками.
2 Каждая лента должна иметь ярлык с номером.
3 Растровые данные должны быть представлены в виде файлов типа 1.
4 Размер изображения должен быть 512 x 512.
5 Растровая плотность изображения должна быть 200 PELS/Inch.
6 Растровая ориентация изображения должна быть горизонтальной.
7 Принятие решения об удовлетворительном качестве растровых данных должно быть основано на качестве передачи содержания и визуальном сравнении с рисунком оригинала. Сравнение должно проводиться после воспроизведения растрового образа на бумажном носителе.
Ж.2 Требования к данным об изделии в формате ИСО 10303 (STEP)
Обмен данными об изделии в формате ИСО 10303 (STEP) обеспечивает возможности просмотра, архивации, комментирования/аннотирования, извлечения части данных, редактирования и конвертирования данных.
1 Данные должны быть представлены на сменном магнитном носителе (дискете) с максимальной допустимой емкостью 1,44 Мбайт.
2 Каждая поставленная дискета должна иметь сопроводительный ярлык.
3 Данные должны быть представлены в виде обменного файла согласно ГОСТ Р ИСО 10303-21.
4 Структура данных должна соответствовать схеме «config_control_design» согласно ИСО 10303-203.
5 Состав данных должен включать объекты 1, 5 и 6-го классов соответствия.
6 В данных 1-го класса соответствия должны быть заполнены атрибуты всех объектов; использовать значения по умолчанию не допускается.
7 При использовании ссылок на объекты типа document допускается не передавать соответствующие документы в одном пакете с передаваемыми данными, если они являются нормативными. При ссылках на проектные документы их содержание должно быть передано в одном пакете с данными, если они не были переданы ранее в предшествующих сеансах.
8 Проверка качества данных должна осуществляться программным продуктом «AP 203 Conformance Checker», входящим в состав ППП «ST-Developer», версия 7.0. Результат проверки должен быть положителен. Проверка должна осуществляться до подготовки данных к отправке.
| [1] | ИСО 8879-86 <*> Обработка информации. Текстовые и офисные системы. Стандартный обобщенный язык разметки (SGML) |
|---|---|
| [2] | ИСО 10303-203-94 <*> Промышленные системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 203. Протокол применения. Проектирование пространственных механических деталей и узлов с управляемой конфигурацией |
| [3] | ИСО 4343-78 <*> Промышленные системы автоматизации. Программное управление оборудованием. Выходные данные NC процессора. Младшие элементы записей типа 2000 (команды постпроцессора) |
| [4] | ПМС ИСО 10303-214 <*> Промышленные системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 214. Протокол применения. Основные данные проектирования механики автомобилей |
| [5] | ИСО/МЭК 10179-96 <*> Информационные технологии. Языки обработки данных. Язык спецификации и семантики стиля документа (DSSSL) |
| [6] | ANSI X3.4-86 Американский стандартный код для информационного обмена |
| [7] | ИСО 8601-88 <*> Элементы данных и форматы обмена. Обмен информацией. Представление даты и времени |
| [8] | ИСО/МЭК 8632-1-99 <*> Информационная технология. Машинная графика. Метафайл для хранения и передачи данных описания образа. Часть 1. Функциональная спецификация |
| [9] | ИСО/МЭК 8632-2-92 <*> Информационная технология. Машинная графика. Метафайл для хранения и передачи данных описания образа. Часть 2. Символьное представление |
| [10] | ИСО/МЭК 8632-3-99 <*> Информационная технология. Машинная графика. Метафайл для хранения и передачи данных описания образа. Часть 3. Двоичное представление |
| [11] | ИСО/МЭК 8632-4-99 <*> Информационная технология. Машинная графика. Метафайл для хранения и передачи данных описания образа. Часть 4. Текстовое представление |
| [12] | ИСО/МЭК 11544-93 <*> Информационная технология. Кодированное представление графической и аудиоинформации. Последовательное двухуровневое сжатие образов |
| [13] | ANSI/US PRO/IPO 100-96 <***> Исходная спецификация графического обмена, цифровое представление данных об изделии для обмена, IGES 5.3 |
| [14] | ИСО/МЭК 10180-95 <*> Информационная технология. Языки обработки данных. Стандартный язык описания страниц (SPDL) |
| [15] | ИСО/МЭК 12064-1-95 <*> Информационная технология. Международный стандартизованный профиль FOD112. Открытый формат документа. Приложения для графических образов. Структура простого документа. Архитектура содержания растровой графики. Часть 1. Профиль применения документа (DAP) |
| [16] | EIA-538-88 <***> Схемы и управляющие функции кодирования для факсимильных аппаратов 4-й группы |
| [17] | ИСО/МЭК 10918-1-94 <*> Информационная технология. Кодирование и сжатие полутоновых графических образов. Требования и указания |
| [18] | ИСО/МЭК 10918-3-97 <*> Информационная технология. Кодирование и сжатие полутоновых графических образов. Расширения |
| [19] | ИСО/МЭК 10918-4-99 <*> Информационная технология. Кодирование и сжатие полутоновых графических образов. Регистрация профилей JPEG, профилей SPIFF, меток SPIFF, палитр SPIFF, маркеров APPn, типов сжатия SPIFF и организаций-разработчиков |
| [20] | ANSI/US PRO/IPO 110-94 <**> Исходная спецификация графического обмена. Протокол применения. Трехмерная разводка трубопроводов |
| [21] | ИСО 10303-201-94 <*> Промышленные системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 201. Протокол применения. Точное черчение |
| [22] | ИСО 10303-202-96 <*> Промышленные системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 202. Протокол применения. Ассоциативное черчение |
| [23] | ИСО/МЭК 11172-1-93 <*> Информационная технология. Кодирование видеоданных и ассоциированных аудиоданных для цифровых носителей со скоростями обмена порядка 1,5 Мбайт/с. Часть 1. Системы |
<*> Международные стандарты ИСО (ИСО/МЭК) — во ВНИИКИ Госстандарта России.
<**> Национальные стандарты США — в Интернете по адресу https://webstore.ansi.org/ansidocstore.
<***> Документы по стандартизации — в Интернете по адресу http:/www.cals.ru.
| [24] | ИСО/МЭК 11172-2-93 <**> Информационная технология. Кодирование видеоданных и ассоциированных аудиоданных для цифровых носителей со скоростями обмена порядка 1,5 Мбайт/с. Часть 2. Видеоданные |
|---|---|
| [25] | ИСО/МЭК 11172-3-93 <**> Информационная технология. Кодирование видеоданных и ассоциированных аудиоданных для цифровых носителей со скоростями обмена порядка 1,5 Мбайт/с. Часть 3. Аудиоданные |
| [26] | RFC 2045-96 <*> Многоцелевые почтовые Интернет-расширения (MIME). Часть 1. Формат содержательной части Интернет-сообщения |
| [27] | RFC 2046 <*> Многоцелевые почтовые Интернет-расширения (MIME). Часть 2. Типы средств |
| [28] | RFC 2047 <*> Многоцелевые почтовые Интернет-расширения (MIME). Часть 3. Расширения заголовка сообщения для текстов, не относящихся к стандарту ASCII |
| [29] | RFC 2049 <*> Многоцелевые почтовые Интернет-расширения (MIME). Часть 5. Критерии соответствия и примеры |
| [30] | ИСО/МЭК 8859-5-88 <**> Обработка информации. 8-битные однобайтные наборы кодированных графических символов. Часть 5. Латинский/кириллический алфавит |
| [31] | ИСО 3592-2000 <**> Промышленные системы автоматизации. Программное управление оборудованием. Выходные данные NC процессора. Структура файлов и формат выходного языка |
| [32] | ИСО 4342-85 <**> Промышленные системы автоматизации. Программное управление оборудованием. Входные данные NC процессора. Ядро языка представления программ |
| [33] | ПМС ИСО 10303-213 <**> Промышленные системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 213. Протокол применения. Процессы механической обработки деталей с использованием числового программного управления |
| [34] | EIA-548-88 <*> Формат обмена данными проектирования изделий электроники (EDIF 2.0) |
| [35] | ANSI/US PRO/IPO 111-97 <***> Исходная спецификация графического обмена (IGES). Протокол применения. Многослойные электротехнические изделия |
| [36] | EIA-274-D-79 <*> Обменный блочный формат данных для описания позиционного, контурного и контурно-позиционного оборудования с числовым программным управлением. Ассоциация электронной промышленности |
| [37] | ISBN 0-201-62628-4 <*> Справочное руководство по унифицированному формату документа (PDF) |
| [38] | Формат TIFF (TM), версия 6.0 <*>. Adobe Developers Association |
| [39] | RFC 2301-98 <*> Формат файла для факсов Интернет |
| [40] | RFC 2306-98 <*> Формат разметки файла графического образа (TIFF). Профиль для факсов |
| [41] | RFC 1866-95 <*> Язык разметки гипертекста 2.0 |
| [42] | ИСО/МЭК 10744-97 <**> Информационная технология. Язык структурирования гипермедийной информации на основе разметки по времени (HyTime) |
| [43] | MIL-Std-1840-97 C <*> Стандарт, согласованный Министерством обороны. Автоматизированный обмен технической информацией |
<*> Документы по стандартизации — в Интернете по адресу http:/www.cals.ru.
<**> Международные стандарты ИСО (ИСО/МЭК) — во ВНИИКИ Госстандарта России.
<***> Национальные стандарты США — в Интернете по адресу https://webstore.ansi.org/ansidocstore.