НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН

Проект
Изображение Государственного Герба Республики Казахстан
НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН
СИСТЕМЫ ИНТЕЛЛЕКТУАЛЬНЫЕ ТРАНСПОРТНЫЕ
Требования к базам данных ситуационных центров
СТ РК ИСО 14827-1–_____
«Настоящий
национальный
стандарт
является
идентичным
осуществлением международного стандарта ИСО 14827-1: 2005 (E)
Настоящий проект стандарта
не подлежит применению до его утверждения
Комитет технического регулирования и метрологии
Министерства по инвестициям и развитию Республики Казахстан
(Госстандарт)
Астана
СТ РКISO 14827-1__
(проект, редакция 1)
Предисловие
1 ПОДГОТОВЛЕН И ВНЕСЕН Республиканским государственным
предприятием «Казахстанский институт стандартизации и сертификации» и
Акционерным обществом «Казахская академия транспорта и коммуникаций
им. М.Тынышпаева».
2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕПриказом Председателя
Комитета технического регулирования и метрологии Министерства по
инвестициям и развитию Республики Казахстан от __________________ №
________.
3 Настоящий стандарт идентичен международному стандарту ИСО
14827-1: 2005 (E) TICS – TransportInformationandControlSystems (ТИУС –
Транспортные информационные и управляющие системы)
Международный стандарт ИСО
14827-1: 2005 (E) разработан
Техническим Комитетом ISO/TC.
Перевод с английского языка (en).
Официальный экземпляр Международный стандарт ИСО 14827-1:
2005 (E), на основе которого разработан настоящий стандарт, и на которые
даны
ссылки,
имеются
в
Едином
государственном
фонде
нормативныхтехнических документов.
Степень соответствия – идентичная (IDT).
4 В настоящем стандарте реализованы положения Закона Республики
Казахстан от 7 января 2003 года N 370 Об электронном документе и
электронной цифровой подписи и Государственной программы
Информационный Казахстан-2020.
5 СРОК ПЕРВОЙ ПРОВЕРКИ201_ год
ПЕРИОДИЧНОСТЬ ПРОВЕРКИ5 лет
6 ВВЕДЕН ВПЕРВЫЕ
Информация об изменениях к настоящему стандарту публикуется в
ежегодно издаваемом информационном указателе «Нормативные
документы по стандартизации», а текст изменений и поправок – в
ежемесячно издаваемых информационных указателях «Национальные
II
СТ РКISO 14827-1__
(проект, редакция 1)
стандарты». В случае пересмотра (замены) или отмены настоящего
стандарта соответствующее уведомление будет опубликовано в
ежемесячно издаваемом информационном указателе «Национальные
стандарты».
Настоящий стандарт не может быть полностью или частично
воспроизведен, тиражирован и распространен в качестве официального
издания без разрешения Комитета технического регулирования и метрологии
Министерства по инвестициям и развитию Республики Казахстан.
III
СТ РКISO 14827-1__
(проект, редакция 1)
Содержание
Страницы
Предисловие
1
Введение
3
1 Область применения
5
2 Нормативные ссылки
6
3 Термины и определения
7
4 Символы и сокращенные термины
9
5 Требования
9
5.1 Двусторонний обмен данными
10
5.2 Определение высокого уровня
10
5.3 Определения описываютожидаемую функциональность
10
5.4 Сроки и другие вопросы
11
5.5 Дополнительные атрибуты
11
6 Требования к описанию формата сообщения
11
6.1 Имя
11
6.2 Определение
12
6.3 Замечания
12
6.4 Тело (текст) сообщения
12
6.5 Тип сообщения
12
6.6 Тип подписки
12
6.7 Первоначальная публикация
13
6.8 Последующие публикации
14
6.9 Идентификатор(Id)
14
Приложение А (обязательное) Спецификация информации об объекте
15
Приложение В (справочное) Примеры
16
Приложение С (справочное) Концепция операций
19
Библиография
20
IV
СТ РКISO 14827-1__
(проект, редакция 1)
НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН
СИСТЕМЫ ИНТЕЛЛЕКТУАЛЬНЫЕ ТРАНСПОРТНЫЕ
Требования к базам данных ситуационных центров
Дата введения
Предисловие
ИСО
(Международная
(интернациональная)
организация
по
стандартизации)
является
всемирной
федерацией
государственных
организаций по стандартизации (комитетов-членов ИСО). Работа по
подготовке международных стандартов обычно осуществляется через
технические комитеты ИСО. Каждый орган-член ИСО, заинтересованный в
деятельности, для которой был создан технический комитет, имеет право быть
представленным в этом комитете. Международные организации,
правительственные и неправительственные, сотрудничающие с ИСО, также
принимают участие в работе. ИСО тесно сотрудничает с Международной
электротехнической комиссией (МЭК) по всем вопросам стандартизации в
области электротехники.
Международные стандарты разрабатываются в соответствии с
правилами, приведенными в Директивах ИСО / МЭК, часть 2.
Основной задачей технических комитетов является подготовка
международных стандартов. Проекты международных стандартов, принятые
техническими комитетами, рассылаются комитетам-членам ИСО на
голосование. Публикация в качестве международного стандарта требует
одобрения, по меньшей мере, 75% комитетов-членов ИСО, участвующих в
голосовании.
Следует обратить внимание то, что некоторые из элементов этого
документа могут быть объектом патентных прав. ИСО не несет
ответственность за идентификацию какого-либо или всех таких патентных
прав.
ИСО 14827-1 был подготовлен Техническим комитетом ИСО/TC 204,
интеллектуальными транспортными системами, рабочей группой 9, в
сотрудничестве с:
Проект, редакция 1
1
СТ РКISO 14827-1__
(проект, редакция 1)
― (ERTICO) – Европейской автомобильной транспортной организацией
по реализации и координации телематики (телекоммуникации + информатика
– область, объединяющая средства телекоммуникации и автоматизированной
обработки данных);
―
Европейским комитетом по стандартизации (CEN);
― Американской ассоциацией дорожных и транспортных должностных
лиц штатов(AASHTO);
― Институтом инженеров транспорта (ITE);
― Национальной ассоциацией производителей электрооборудования
"(NEMA).
ИСО 14827 состоит из следующих частей, под общим названием
Транспортные информационные и управляющие системы ― интерфейсы
данных между центрами для транспортных информационных и управляющих
систем:
― Часть 1: Требования к описанию формата сообщений
― Часть 2: Datex-ASN – Служба обмена данными в абстрактной
синтаксической нотации (Datex – DataExchange, служба передачи данных
общего пользования, ASN – AbstractSyntaxNotation, Абстрактная
синтаксическая нотация)
2
СТ РКISO 14827-1__
(проект, редакция 1)
Введение
В 1980-х и 1990-х годах, все в большей степени становилась очевидной
перегрузка транспортных сетей, и для эффективного управления
ограниченной транспортной сетью были развернуты компьютерные
технологии. С того момента, все большую важность стала приобретать
интеграция соседних систем для обеспечения требуемых услуг на должном
уровне.
Одной из первых попыток по стандартизации интерфейса между
транспортными управляющими центрами явилась попытка Европейского
союза во главе с целевой группой DATEX(DataExchange, Датекс – служба
передачи данных общего пользования). Данная группа была создана в мае
1993 года, как горизонтальная (единая) группа деятельности по координации
расходящихся событий, которые проходили в рамках Программы передовой
транспортной телематики (АТТ). В рамках Программы ATT, были
разработаны три различные системы обмена данными, а именно
INTERCHANGE (ОБМЕН), EURO-TRIANGLE (ЕВРО-ТРЕУГОЛЬНИК) и
STRADA. Группа подготовила комплекс основных инструментов для
удовлетворения существующих потребностей, в том числе общий словарь
данных,
общий
набор
сообщений
EDIFACT
–
ElectronicDataInterchangeforAdministration,
CommerceandTransportation
(ЭДИФАКТ – обмен электронными данными для служб администрации,
коммерции и транспорта) и общую систему географического расположения
ссылок.
Исходное решение обеспечило общий интерфейс, который удовлетворил
основные требования существующих систем, и получил название Технические
условия на эксплуатационную совместимость сети для обмена данными
(Datex-Net). Во время первоначальных попыток по развертыванию этого
стандарта, было предположение, что структура сообщений должна быть
организована лучше и должна определяться скорее с помощью абстрактной
синтаксической нотации 1 (ASN.1), а не с помощью EDIFACT.
ASN.1 (абстрактная синтаксическая нотация 1) представляет собой
стандартные обозначения для определения типов данных и значений. Тип
данных – это класс информации (например, числовой, текстовой,
неподвижного изображения или видеоинформации). Значение данных
является примером такого класса. ASN.1 определяет несколько основных
типов и их соответствующие значения, а также правила для комбинирования
их в более сложные типы и значения. Эти типы и значения могут быть
закодированы в поток байтов в соответствии с любым из нескольких
стандартизированных правил кодирования.
3
СТ РКISO 14827-1__
(проект, редакция 1)
Попытки по стандартизации отношений между центрами управления
транспортом предпринимались и в других частях мира. В 1997 году все эти
попытки стали сливаться с попытками США, которые занимались разработкой
первоначального проекта ASN.1 структур для обмена данными в Абстрактной
синтаксической нотации (Datex-ASN). Эти структуры, называемые пакетами
данных, затем размещали в процессуальный контекст и представляли на
процесс стандартизации ИСО.
Часть представленного на рассмотрение документа имела дело со
спецификацией сообщений. Поскольку эта часть документа могла
применяться к различным протоколам, ее разместили в ИСО 14827-1.
Остальная часть первоначального представленного на рассмотрение
документа легла в основу протокола Прикладного уровня и была размещена в
ИСО 14827-2. Таким образом, часть 2 определяет только один способ
реализации сообщений, который указан в формате, описанном частью 1.
Благодаря гибкости, требуемой быстро развивающейся среде
информационной и управляющей систем транспорта, получившийся
международный стандарт использует очень общую структуру. Таким образом,
первоначально предназначенный международный стандарт для TICS –
TransportInformationandControlSystems
(ТИУС
–
Транспортные
информационные и управляющие системы) оказался достаточно гибким,
годным для практического использования и обмена всевозможными данными.
4
СТ РКISO 14827-1__
(проект, редакция 1)
Транспортные информационные и управляющие системы ―
интерфейсы
данных
между
центрами
для
транспортных
информационных и управляющих системЧасть 1:Требования к описанию
факторов сообщения
1 Область применения
Данная часть ИСО 14827 описывает формат, который должен
использоваться для документирования сообщений конечного приложения,
которые подлежат обмену среди центральных систем. Формат не зависит от
протоколов, используемых в рамках целесообразного подхода. Например,
данный формат может использоваться для определения обмена данными,
который может применяться к Datex-ASN (обмен данными в абстрактной
синтаксической
нотации),
к
CORBA
(CommonObjectRequestBrokerArchitecture―общая
архитектура
брокера
объектных запросов)или к другим протоколам приложений.
В общем, каждая система может рассматриваться, как состоящая из
интерфейсов, как показано на рисунке 1:
Обозначения:
1 интерфейс приложения
2 интерфейсоператора
3 интерфейс связи
4 интерфейсбазы данных
5 облако связи
6 сервер клиентской системы
7 система
ПРИМЕЧАНИЕ облако связи между системами может быть сложным или простым.
Рисунок 1 - Системный интерфейс
5
СТ РКISO 14827-1__
(проект, редакция 1)
Данная часть ИСО 14827 рассматривает только интерфейс связи и на
очень высоком уровне. Другие части определяют, как сообщения конечного
приложения может быть обменено с помощью различных протоколов
прикладного уровня.
Поскольку данная часть ИСО 14827 была разработана для
удовлетворения уникальных требований среды TICS (ТИУС – Транспортные
информационные и управляющие системы) в общем виде, следовательно,
также может быть использована для других обменов данными.
2 Нормативные ссылки
Следующие нормативные документы являются обязательными для
применения настоящего документа. Для датированных ссылок применяют
только указанное издание. Для недатированных ссылок применяют последнее
издание ссылочного документа (включая любые поправки).
ИСО/МЭК 7498-4, Системы обработки информации ― Взаимосвязь
открытых систем ― Базовая эталонная модель ― Часть 4: Структура
управления
ИСО/МЭК 8824-1, Информационные технологии ― Абстрактная
синтаксическая нотация один (ASN.1) ― Спецификация основной нотации
ИСО/МЭК 8824-2, Информационные технологии ― Абстрактная
синтаксическая нотация один (ASN.1) ― Информационная спецификация
объекта
ИСО/МЭК 8825-1, Информационные технологии ― Правила
кодирования ASN.1: Спецификация базовых правил кодирования (BER),
канонических правил кодирования (CER) и особых правил кодирования (DER)
ИСО/МЭК
8825-2,
Информационные
технологии
―
Правилакодирования ASN.1: Спецификация правил пакетного кодирования
(PER)
ИСО 9735, Электронный обмен данными для служб администрации,
коммерции и транспорта (EDIFACT) ― Применение правил уровневого
синтаксиса
6
СТ РКISO 14827-1__
(проект, редакция 1)
3 Термины и определения
Для настоящего документа используются следующие термины и
определения.
3.1прикладной уровень
верхний уровень семиуровневой модели OSI (OSI - Взаимодействие
открытых систем) так, как определено в ИСО/МЭК 7498-4
ПРИМЕЧАНИЕ Данный уровень определяет структуру, формат содержания пакета
данных наряду с правилами и процедурами для обмена пакетами данных.
3.2 центр
любые компьютеры или сеть, которые необходимы для удовлетворения
стандартизованного интерфейса по сети с фиксированной точкой связи,
независимо от того, является ли "центр" единственной системой в здании или
просто одним из многих, или даже если "центр" находится на определенном
расстоянии.
ПРИМЕЧАНИЕ Данная часть ИСО 14827 имеет дело только с взаимодействиями,
которые находятся между «центрами».
3.3 клиент
компьютер или приложение, которое запрашивает и принимает данные с
сервера с помощью какого либо вида протокола
3.4 команда
пакет данных, который подготавливается одной системой для того,
чтобы контролировать одну или некоторые функции другой системы
ПРИМЕЧАНИЕ Команды могут быть переданы в виде подписки (запроса) или
публикации (ответа) в зависимости от модели конкретного обмена данными.
3.5пакет передаваемых данных
субъект данных, который может быть отправлен между системами
конечного приложения в целях обмена информацией
ПРИМЕЧАНИЕ Пакет передаваемых данныхотносится к прикладному уровню
стека OSI (Взаимодействие открытых систем) и может быть разбит на несколько частей
протоколами низкого уровня.
7
СТ РКISO 14827-1__
(проект, редакция 1)
3.6сообщение конечного приложения
структура данных сообщения, которая связана с конкретным значением,
и при правильной отправке передаваемых данных в пакете, экземпляр
структуры может передавать информацию между системами
ПРИМЕЧАНИЕ структура данных, например, могла быть указана, для включения
перечня скоростей от детекторных станций. Одна эта структура могла использоваться для
определения содержания нескольких сообщений (например, перечень текущих скоростей
для обнаружения, перечень сохраненных скоростей, которые вызовут предупреждение
перегрузки, если текущие значения упадут нижеуказанного уровня, или запрос на список
местоположений, где текущая скорость меньше указанной скорости). Экземпляр (вариант)
сообщения будет содержать тогда фактические значения.
3.7экземпляр сообщения
конкретный экземпляр сообщения конечного приложения
3.8спецификация сообщения
документация, определяющая смысл сообщения, результат применения
данной части ИСО14827 для конкретного сообщения
3.9 профиль
международный стандарт, который определяет правила лишь при
совмещении с требованиями другого международного стандарта
ПРИМЕР Профиль приложения ― это профиль, который определяет приложение,
презентацию и сеансовые уровни (уровни модели OSI, обеспечивающие способы ведения
диалога между системами), ссылаясь на группу других международных стандартов.
3.10 протокол
набор формальных правил, описывающих, как передавать данные,
особенно по сети
3.11 публикация
данные ответа, которые были получены сервером, обычно в ответ на
подписку
ПРИМЕЧАНИЕ В некоторых случаях, публикация может быть обозначена
терминами “reply”― ответ" или “response” ― "ответ" (оба английских слова переводятся
одинаково ― примечание переводчика).
8
СТ РКISO 14827-1__
(проект, редакция 1)
3.12 сервер
компьютер или приложение, которое получает и реагирует на запросы
данных от клиентских компьютеров или приложений, использующих какой-то
вид протокола
3.13 подписка
пакет данных запроса, который подготовлен клиентом для запроса
текущей или будущей публикации (й)
ПРИМЕЧАНИЕ В некоторых случаях, подписка может быть обозначена словом “
request” -"запрос".
4 Символы и сокращенные термины
ASN.1
Абстрактная синтаксическая нотация 1 (ИСО/МЭК 8824-1 и
ИСО / я EC 8824-2)
BER
Базовые правила кодирования (ИСО/МЭК 8825-1)
CORBA
Общая архитектура брокера объектных запросов
Обмен данными в Абстрактной синтаксической
Datex-ASN
нотации
ЭДИФАКТ
Электронный обмен данными для служб
администрации, коммерции и транспорта (ИСО 9735)
OID
Идентификатор объекта
OSI
Взаимодействие открытых систем
PER
Правила компактного кодирования (ИСО / МЭК 8825-2)
TICS
Транспортные информационные и управляющие системы
5 Требования
Данная часть ИСО 14827 обеспечивает стандартизированный формат,
который может быть использован для описания сообщений конечного
приложения для нескольких прикладных протоколов; протокол каждого
приложения имеет свой собственный уникальный набор услуг. Для того чтобы
обеспечить практическое описание сообщений, был сделан ряд
9
СТ РКISO 14827-1__
(проект, редакция 1)
предположений об услугах, предоставляемых нижними уровнями стека
протоколов и общими концепциями проекта. Эти предположения
документированы в данном разделе.
ПРИМЕЧАНИЕ Ничто в данной части ИСО 14827 не снимает ответственности с
агентства, для обеспечения того, что сообщение не противоречит никакому правовому
обязательству, возложенному на него законодательством соответствующей страны.
5.1 Двусторонний обмен данными
Данная часть ИСО 14827 предполагает, что протокол предусматривает
стиль связи «запрос-ответ», где ответ может быть в другом формате, нежели
запрос. Кроме того, он признает, что некоторые протоколы позволяют серии
ответов на один запрос; таким образом, он разработан так, чтобы вводить
поправку на данную операцию. Он предполагает, что запросы не затребован, а
ответы почти всегда запрошены. Это предполагает, что есть только один тип
исходного ответа, который может быть получен для заданного запроса, и
только один вид последующего ответа для запросов, позволяющих несколько
ответов.
Если система хочет отправить незатребованное уведомление, для
которого не требуется ответ, (кроме гарантированной доставки), это должно
быть указано в публикации.
5.2 Определение высокого уровня
Данная часть ИСО 14827 обеспечивает только описание факторов
сообщений высокого уровня. Различные протоколы будут осуществлять этот
обмен по-разному. Правила для реализации этих сообщений в данном
протоколе должны быть определены в документации протокола, либо в
профиле приложения. Профиль конечного приложения также может
потребоваться для того, чтобы однозначно идентифицировать конкретные
правила для конкретного сообщения.
Например, ответ, который может встретиться несколько раз, вероятно,
будет отображен в пакете данных публикации в Datex-ASN, в то время, как
вероятность, будет отображен и на вызове метода в CORBA.
5.3 Определения описывают ожидаемую функциональность
В контексте данной части ИСО 14827, сообщение предполагает уровень
функциональности в пределах системы. Точная функциональность, требуемая
определенным сообщением, должна быть документирована в атрибуте
разрешения.
Например, если система А запрашивает маршрут поездки из точки Х в
точку Z, система B должна ответить запрашиваемыми данными (или
соответствующим значением ошибки). Таким образом, одно из
10
СТ РКISO 14827-1__
(проект, редакция 1)
функциональных требований, предъявляемых к системе В, состоит в том, что
она должна ответить запрашиваемыми данными (предположительно список
альтернативных маршрутов). Другие требования также могут быть наложены
(например, рассматриваются ли альтернативы любого режима движения).
Данная часть ИСО 14827 определяет такую функциональность, связывая
публикацию с каждым запросом; конкретные сообщения должны указать
дополнительные семантики (например, действительные режимы движения), в
случае необходимости.
5.4 Сроки и другие вопросы
Данная часть ИСО 14827 конкретно не рассматривает проблемы
распределения во времени; однако, исполнители должны быть в курсе, что
многие сообщения требуют определенных уровней исполнения, которые
некоторые протоколы не в состоянии удовлетворить.
5.5 Дополнительные атрибуты
Данная часть ИСО 14827 определяет те атрибуты, которые необходимы
для обеспечения однозначного обмена данными, оставаясь относительным
общего протокола. Эти атрибуты как указано должны быть определены для
каждого сообщения. Другие атрибуты могут быть документированы, если в
этом возникает необходимость.
Например, ИСО 14817-3 определяет схему классификации для
управления списками сообщений, среди других атрибутов. Другие
международные стандарты могут определять атрибуты, необходимые для
отображения сообщения для конкретного протокола. Сообщения в
соответствии с этой частью ИСО 14827 могут также включать в себя любые
такие атрибуты до тех пор, пока необходимые атрибуты, определенны этой
частью ИСО 14827.
6 Требования к описанию факторов сообщения
Сообщение конечного приложения: соответствует этой части ИСО
14827, должно быть формально описано с атрибутами, определенными в
следующих
подразделах.
Приложение
А
содержит
формальную
информационную спецификацию объекта ASN.1, используемую для
документирования этих атрибутов.
6.1 Имя
Каждому сообщению должно быть назначено уникальное описательное
имя. Это имя может использоваться некоторыми протоколами для
идентификации целей.
11
СТ РКISO 14827-1__
(проект, редакция 1)
6.2 Определение
Каждому сообщению должно назначается официальное, текстовое
определение. Текстовое определение может иметь ссылки на цифры и другую
информацию по мере необходимости. Определение обеспечивает значимое
описание сообщения и ясно показывает функциональность, требуемую
конечной системой.
Если сообщение используется в событийно-управляемом режиме,
определение установит, что представляет собой событие.
6.3 Замечания
Спецификация сообщения может также включать в себя
дополнительные замечания. Такие замечания не должны рассматриваться как
обязательные, но могут обозначаться для обеспечения более глубокого
понимания сообщения или обеспечения дополнительной информации для
читателя.
6.4 Тело (текст) сообщения
Тело (текст) сообщения должно быть полностью описано в этой области,
как тип ASN.1, с использованием обозначения, как указано в ИСО/МЭК 88241.
ПРИМЕЧАНИЕ
Это
позволит
последовательную
методологию
для
документирования данных; не подразумевает использование правил кодирования ASN.1.
Протокол может выбрать любое из правил кодирования ASN.1 или использовать другие
правила и процедуры (например, так, как описано для EDIFACT и CORBA).
6.5 Тип сообщения
Тип сообщения должен указывать, описывает ли сообщение структуру
подписки или публикации сообщения. Характеристики сообщения подписки
должны содержать атрибуты "тип подписки", "начальную публикацию" и
"последующие публикации". Характеристики сообщений публикации не
должны содержать данные атрибуты.
6.6 Тип подписки
Тип подписки должен включатся в спецификацию сообщения, является
ли тип сообщения "Подпиской". Данный атрибут указывает, при каких
режимах сообщение может быть использовано следующим образом:
― одиночный: экземпляр этого сообщения действителен при условии,
если запрос только для одного ответа. Ответ будет указан с помощью
атрибута "Первая публикация".
― событийно-управляемый: экземпляр этого сообщения действителен
при условии, если запрос для
событийно-управляемого уведомления.
12
СТ РКISO 14827-1__
(проект, редакция 1)
Непосредственно после получения, следует отправить экземпляр "первой
публикации", а когда определяемое событие будет обнаружено, следует
отправить экземпляр из "последующих публикаций". Событие должно быть
описано в пределах атрибута определения.
― периодический: экземпляр этого сообщения будет действительным
только в том случае, если запрос относится к периодическим обновлениям.
Непосредственно после получения, получатель должен отправить вариант
"первой публикации", а сервер должен периодически отправлять обновления
"последующих публикаций" в соответствии с правилами конкретного
протокола.
― одиночный или событийный: экземпляр этого сообщения должен
иметь силу, если запрос на тему для одного ответа или, если запрос на тему
для событийно-управляемого ответа; вариант этого сообщения не может быть
отправлен в качестве периодического запроса. Режим (или одиночный, или
событийный) должен четко указываться в пределах экземпляра сообщения.
Действие
приемной системы должно соответствовать обстоятельствам
заданного режима экземпляра сообщения.
― одиночный или периодический: экземпляр этого сообщения должен
иметь силу только в том случае, если запрос на тему для одного ответа или,
для периодического ответа; экземпляр этого сообщения не может быть
отправлен для событийно-управляемого запроса. Режим (или одиночный, или
периодический) должен четко указываться в пределах экземпляра сообщения.
Действие
приемной системы должно соответствовать обстоятельствам
заданного режима экземпляра сообщения.
― событийный или периодический: экземпляр этого сообщения должен
иметь силу только в том случае, если запрос на тему для событийно
управляемого ответа или периодического ответа; экземпляр этого сообщения
не может быть отправлен для запроса одного ответа. Режим (событийный,
либо периодический) должен быть четко указан в пределах экземпляра
сообщения. Действие
приемной системы должно соответствовать
обстоятельствам заданного режима экземпляра сообщения.
― одиночно-событийно-периодический: экземпляр этого сообщения
может запросить один ответ, событийно-управляемый или периодический.
Режим (одиночный, событийный, либо периодический) должен четко
указываться в экземпляре сообщения. Действие приемной системы должно
соответствовать обстоятельствам заданного режима экземпляра сообщения.
6.7 Первоначальная публикация
Атрибут «первоначальная публикация» должен включатся только в
спецификацию сообщений подписки. Он должен определять сообщение,
которое будет передано непосредственно после получения соответствующей
подписки.
13
СТ РКISO 14827-1__
(проект, редакция 1)
6.8 Последующие публикации
Атрибут последующих публикаций должен включатся только в
спецификацию сообщений подписки, которые не являются сообщениями типа
"одиночный". Он должен определять сообщение публикации, которое будет
передано для всех последующих сообщений после первой публикации.
6.9 Идентификатор (Id)
Каждому сообщению должен назначаться глобальный уникальный
идентификатор ASN.1 - идентификатор объекта в поле идентификации Id.
Некоторые протоколы могут использовать данный идентификатор, чтобы
определить скорее тип сообщения, нежели имя сообщения.
14
СТ РКISO 14827-1__
(проект, редакция 1)
Приложение А
(обязательное)
Спецификация информации об объекте
А.1 Общее
ISO 14827-MESSAGE ::= CLASS {
&namePrintableString (SIZE (0..255))
&definitionPrintableString (SIZE (0..65535))
&remarksPrintableString (SIZE (0..2000)) OPTIONAL
&MessageBody
&messageTypeENUMERATED {publication, subscription}
&subscriptionTypeENUMERATED {single, event-driven, single-or-event,
periodic, single-or-periodic, event-or-periodic,
single-event-periodic}
OPTIONAL
&initialPublicationPrintableString (SIZE (0..255)) OPTIONAL
&subsequentPublicationsPrintableString (SIZE (0..255)) OPTIONAL
&idOBJECT IDENTIFIER
}
WITH SYNTAX {
NAME &name
DEFINITION &definition
[REMARKS&remarks]
MESSAGE BODY &MessageBody
MESSAGE TYPE &messageType
[SUBSCRIPTION TYPE &subscriptionType]
[INITIAL-PUBLICATION &initialPublication]
[SUBSEQUENT-PUBLICATIONS &subsequentPublications]
ID &id
}
Приложение B
(справочное)
Примеры
В.1 Список запрашиваемых сотрудников
Простое сообщение может не содержать каких-либо данных вообще.
Например, сообщению по запросу списка всех сотрудников не требуется
никакая информация, кроме идентификатора.
requestEmployeeList ISO 14827-MESSAGE ::= {
NAME "Request Employee List"
15
СТ РКISO 14827-1__
(проект, редакция 1)
DEFINITION "Requests the current list of employees as stored
In the database."
MESSAGE BODY NULL
MESSAGE TYPE subscription
SUBSCRIPTION TYPE single
INITIAL-PUBLICATION publicationEmployeeList
ID {iso(1) std(0) 14827 part1(1) examples(1) 1}
}
В.2 Запрос сотрудников по названию
Более сложный запрос может содержать параметр по выявлению типов
сотрудников, о которых информация запрашивается. В этом случае,
тело(текст) сообщения будет определять структуру данных, используемую для
указания типа работников.
EmployeeType ::= UTF8String (SIZE (0..64))
requestEmployeeListByType ISO 14827-MESSAGE ::= {
NAME "Request Employee List by Type"
DEFINITION "Requests the current list of employees stored in
the database who have a title matching one of
those contained in the message body."
MESSAGE BODY SEQUENCE OF EmployeeType
MESSAGE TYPE subscription
SUBSCRIPTION TYPE single
INITIAL-PUBLICATION publicationEmployeeList
ID {iso(1) std(0) 14827 part1(1) examples(1) 2}
}
В.3 Ответ по списку сотрудников
Хотя подписка должна указывать точно, что публикация разрешена,
одна и та же публикация может быть использована, чтобы ответить на
несколько подписок. Например, следующая публикация была ранее указана
для каждого из указанных выше сообщений. Этот пример также показывает,
что текст (тело) сообщения может определятся в спецификации сообщения, в
дополнение к ссылке, используемой в приведенном выше примере.
publicationEmployeeList ISO 14827-MESSAGE ::= {
NAME "Employee List"
DEFINITION "Provides a listing of selected employees."
MESSAGE BODY SEQUENCE OF SEQUENCE
{
16
СТ РКISO 14827-1__
(проект, редакция 1)
employee-FirstName UTF8String,
employee-LastName UTF8String
}
MESSAGE TYPE publication
ID {iso(1) std(0) 14827 part1(1) examples(1) 3}
}
В.4 Запрос по обновлению сотрудников
Последний пример показывает, как сообщение может быть определено
не только для того, чтобы запрашивать первоначальный список сотрудников,
но и запрашивать обновления, когда нанимаются новые сотрудники.
requestEmployeeUpdateList ISO 14827-MESSAGE ::= {
NAME "Request Employee Update List"
DEFINITION "Requests the current list of employees as stored
in the database and, if the event-driven mode is
selected, updates as new employees are hired. If
the event-driven mode is selected for a given
instance of this message, a subsequent publication,
containing only the new name, shall be sent every
time a new employee is added."
MESSAGE BODY NULL
MESSAGE TYPE subscription
SUBSCRIPTION TYPE single-or-event
INITIAL-PUBLICATION publicationEmployeeList
SUBSEQUENT-PUBLICATIONS publicationEmployee
ID {iso(1) std(0) 14827 part1(1) examples(1) 4}
}
17
СТ РКISO 14827-1__
(проект, редакция 1)
Приложение C
(справочное)
Концепция операций
Эта часть ИСО 14827 обеспечивает механизм спецификации сообщений
на абстрактном уровне. Фактическая реализация этих сообщений будет
определяться другими международными стандартами.
Например, ИСО 14827-2 (Datex-ASN) определяет один из способов
обмена этими сообщениями. В этом протоколе, подписка будет отправлена
через интерфейс в пакете данных подписки Datex-ASN. Тем не менее, другие
международные стандарты могут определить, как обменять эти данные через
интерфейс CORBA. Такой международный стандарт может приравнять
каждую подписку к вызову метода и каждую публикацию к ответам на вызов
метода.
18
СТ РКISO 14827-1__
(проект, редакция 1)
Библиография
[1] ИСО/МЭК 7498-4, Системы обработки информации ― Взаимосвязь
открытых систем ― Базовая эталонная модель ― Часть 4: Структура
управления
[2] ИСО/МЭК 8824-1, Информационные технологии ― Абстрактная
синтаксическая нотация один (ASN.1) ― Спецификация основной нотации
[3] ИСО/МЭК 8824-2, Информационные технологии ― Абстрактная
синтаксическая нотация один (ASN.1) ― Информационная спецификация
объекта
[4] ИСО/МЭК 8825-1, Информационные технологии ― Правила
кодирования ASN.1: Спецификация базовых правил кодирования (BER),
канонических правил кодирования (CER) и особых правил кодирования (DER)
[5] ИСО/МЭК 8825-2, Информационные технологии ― Правила
кодирования ASN.1: Спецификация правил пакетного кодирования (PER)
[6] ИСО 9735, Электронный обмен данными для служб администрации,
коммерции и транспорта (EDIFACT) ― Применение правил уровневого
синтаксиса
19
СТ РКISO 14827-1__
(проект, редакция 1)
УДК 625.144.1:006.354МКС 45.040
Ключевые слова:центр, сообщение конечного
двусторонний обмен данными, атрибуты, тип подписки
20
приложения,
СТ РКISO 14827-1__
(проект, редакция 1)
УДК 625.144.1:006.354МКС 45.040
Ключевые слова:центр, сообщение конечного приложения, двусторонний
обмен данными, атрибуты, тип подписки
Исполнительный директор
по научной работе
АО «КазАТК им. М.Тынышпаева»
Б.Р. Кангожин
21