ПНСТ 636-2022 Интеллектуальные транспортные системы. Коммерческие перевозки. Контроль автомобильных перевозок в цепочке поставок. Часть 1. Архитектура и определения данных

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Интеллектуальные транспортные системы

КОММЕРЧЕСКИЕ ПЕРЕВОЗКИ. КОНТРОЛЬ АВТОМОБИЛЬНЫХ ПЕРЕВОЗОК В ЦЕПОЧКЕ ПОСТАВОК

Часть 1

Архитектура и определения данных

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

Москва Российский институт стандартизации 2022

Предисловие

• 1 РАЗРАБОТАН Обществом с ограниченной ответственностью «ТранснавиСофт» (ООО «Транс-навиСофт»)

• 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 57 «Интеллектуальные транспортные системы»

• 3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 1 февраля 2022 г. № 10-пнст

Правила применения настоящего стандарта и проведения его мониторинга установлены ГОСТР 1.16—2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 127083 Москва, ул. Мишина, д. 35 и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 123112 Москва, Пресненская набережная, д. 10, стр. 2.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты» и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

© Оформление. ФГБУ «РСТ», 2022

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

Содержание

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

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

• 3 Термины и определения

• 4 Сокращения

• 5 Определение данных бизнес-процессов в цепочке поставок

• 5.1 Бизнес-моделирование и основные варианты использования

• 5.2 Обзор бизнес-процессов

• 5.3 Системная архитектура данных высокого уровня

• 5.4 Архитектура данных

• 5.5 Определения концепции данных

Приложение А (справочное) Модули АСН.1 для концепций данных, определенных в настоящем стандарте

Приложение Б (справочное) Интерпретация номера VIN

Приложение В (справочное) Пример бизнес-процессов и рабочих процессов

Приложение Г (справочное) Сектор описательной информации

Библиография

Введение

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

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

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

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

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

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

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

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

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

ПНСТ 636—2022

ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Интеллектуальные транспортные системы

КОММЕРЧЕСКИЕ ПЕРЕВОЗКИ. КОНТРОЛЬ АВТОМОБИЛЬНЫХ ПЕРЕВОЗОК В ЦЕПОЧКЕ ПОСТАВОК

Часть 1

Архитектура и определения данных

Intelligent transport systems. Commercial freight. Automotive visibility in the distribution supply chain.

• Part 1. Architecture and data definitions

Срок действия с 2022—08—01 до 2025—08—01

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

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

Настоящий стандарт устанавливает требования:

• а) к определению динамического расположения в области хранения/соединения;

• б) к обеспечению последовательного использования VIN по [1], [2] в качестве основного идентификатора;

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

Примечания

• 1 Область применения настоящего стандарта не стандартизирует носители данных или средства их сбора.

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

• 3 Движение автомобилей в контейнерах выходит за рамки настоящего стандарта.

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

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

ГОСТ ISO 15394 Упаковка. Линейные символы штрихового кода и двумерные символы на этикетках для отгрузки, транспортирования и приемки. Общие требования

ГОСТ ISO/IEC 15418 Информационные технологии. Технологии автоматической идентификации и сбора данных. Идентификаторы применения GS1 и идентификаторы данных ASC МН 10 и их ведение

ГОСТ Р ИСО 22742 Автоматическая идентификация. Кодирование штриховое. Символы линейного штрихового кода и двумерные символы на упаковке продукции

ГОСТ Р ИСО/МЭК 8824-1 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации

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

ГОСТ Р ИСО/МЭК 8824-2 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 2. Спецификация информационного объекта

ГОСТ Р ИСО/МЭК 8824-3 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 3. Спецификация ограничения

ГОСТ Р ИСО/МЭК 8824-4 Информационная технология. Абстрактная синтаксическая нотация версии 1 (АСН.1). Часть 4. Спецификация для параметризации АСН.1

ГОСТ Р ИСО/МЭК 8825-1 Информационная технология. Правила кодирования АСН.1. Часть 1. Спецификация базовых (BER), канонических (CER) и отличительных (DER) правил кодирования

ГОСТ Р ИСО/МЭК 8825-2 Информационная технология. Правила кодирования АСН.1. Часть 2. Спецификация правил уплотненного кодирования (PER)

ГОСТ Р ИСО/МЭК 8825-3 Информационная технология. Правила кодирования АСН.1. Часть 3. Спецификация нотации контроля кодирования (ECN)

ГОСТ Р ИСО/МЭК 8825-4 Информационная технология. Правила кодирования АСН.1. Часть 4. Правила XML кодирования (XER)

ГОСТ Р ИСО/МЭК 8825-5 Информационная технология. Правила кодирования АСН.1. Часть 5. Отображение определений W3C схемы XML в АСН.1

ГОСТ Р ИСО/МЭК 8825-6 Информационная технология. Правила кодирования АСН.1. Часть 6.

Регистрация и применение команд кодирования PER

ГОСТ Р ИСО/МЭК 15434 Автоматическая идентификация. Синтаксис для средств автоматического сбора данных высокой емкости

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

• 3 Термины и определения

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

• 3.1 архитектура: Фундаментальные концепции или свойства системы в ее среде, воплощенные в элементах, отношениях и структуре.

• 3.2 автомобиль: Любое самоходное механическое транспортное средство, включая легковые автомобили, фургоны, грузовые автомобили, самоходную строительную технику и самоходную сельскохозяйственную технику.

Примечание — См. также транспортное средство (3.13).

• 3.3 текущее местоположение: Физическое положение на момент запроса.

• 3.4 концепция данных: Характеристика, которая описывает и определяет основные характеристики отдельного объекта, такого как элемент данных, группа объектов данных или метаданные, обычно описываемые путем определения всего или некоторых из его класса объектов, свойств, области значений, концепции элемента данных, элемента данных, фрейм данных, сообщение, интерфейсный диалог, ассоциации, но не определяет конкретную область значений.

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

• 3.5 элемент данных: Объединение определенной концепции данных с определенной областью значений.

Примечание — Например, личную дату рождения можно объединить с областью значений «Дата» ДДММГГГГ для создания элемента данных: персональная дата рождения ДДММГГГГ; альтернативно, элемент данных может быть сформирован с использованием области значений «Дата» ГГГГ, образующей отдельный элемент данных «Персона».

• 3.6 пункт [место] назначения: Последняя обновленная конечная точка маршрута доставки.

• 3.7 распределительная цепочка: Ряд предприятий или организаций, занимающихся транспортировкой, хранением и продажей товаров покупателям.

Примечание — См. также распределительную цепочку поставок (3.8) и цепочку поставок (3.12).

• 3.8 распределительная цепочка поставок: Процесс транспортировки и распределения транспортных средств, мобильных установок и оборудования через распределительную цепочку.

• 3.9 тип местоположения: Функция объекта/точки, где были собраны данные.

• 3.10 пункт отправления: Начальная точка логистического движения автомобиля к месту назначения.

• 3.11 определение статуса: Идентификатор, указывающий, является ли автомобиль «Не готов» или «Готов» для следующей функции объекта или следующей точки поездки.

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

Примечание —См. также распределительную цепочку (3.7) и распределительную цепочку поставок (3.8).

• 3.13 транспортное средство: Такое как автомобиль, фургон, грузовик, тягач, сельскохозяйственное оборудование с приводом от машины, самоходное строительное оборудование.

Примечание — Термин «транспортное средство» в контексте данной части ISO (см. [3]) охватывает все виды автомобилей с автоматическим приводом.

• 3.14 VIN: Структурированная комбинация символов, присваиваемая автомобилю производителем для целей идентификации.

Примечание — См. [1] и [2], приложение Б.

• 4 Сокращения

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

АСН.1 — абстрактная синтаксическая нотация;

DFE — конечный выход;

DPT — диспетчерский портовый терминал;

DVP — автосалон дилера;

FVP — парк готовых автомобилей;

МТ — морской транспорт;

РоО — начало координат;

RPT — приемный терминал;

UML — унифицированный язык моделирования;

VIN — идентификационный номер транспортного средства;

XML — расширяемый язык разметки.

• 5 Определение данных бизнес-процессов в цепочке поставок

  • 5.1 Бизнес-моделирование и основные варианты использования

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

Рисунок 1 — Представление международных участников автомобильной цепи поставок и их зависимость от используемых данных в формате UML

• 5.2 Обзор бизнес-процессов

  • 5.2.1 Распределительные цепочки поставок, учитывающие особенности перемещения грузов автомобилями

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

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

Внутри стран и в некоторой степени на континентах автомобили будут перемещаться автомобильным транспортом, из-за размеров и веса автомобилей эти международные перевозки в подавляющем большинстве случаев осуществляются морем.

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

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

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

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

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

• 5.2.2 Бизнес-процессы для автомобилей в распределительной цепочке поставок

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

Рисунок 2 — Сквозная логистика от сборочного завода до дилера

В приложении В приведены некоторые примеры варианта использования бизнес-процесса, примеры диаграмм последовательности бизнес-случаев и пример рабочего процесса с использованием представления UML. Возможны другие конфигурации и потоки.

В приложении Г (рисунок Г.1) приведен пример объема администрирования, необходимого для этого процесса.

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

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

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

Важно понимать, что не каждая «точка считывания», представленная в таблице Г.1 в качестве примера, будет присутствовать или потребуется в любой распределительной цепочке поставок. «Точки считывания» этой логистической цепочки могут быть описаны как широко последовательные, но могут варьироваться в зависимости от физического местоположения и характера бизнеса производителя, дилера или грузоотправителя, при этом некоторые из этих точек дублируются для приспособления к физическому воплощению распределительной цепочки, а также с другими «точками получения данных (точек считывания)», отсутствующими в конкретном экземпляре конкретной распределительной цепочки.

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

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

В таблице Г.1 описаны девять основных этапов «точек считывания» автомобильной цепочки поставок, каждая из которых включает несколько подразделов «точки считывания» или действий, в которых может потребоваться сбор данных. Не все эти подпункты присутствуют во всех физических экземплярах этой распределительной цепочки поставок, которые варьируются от одного производственного предприятия к другому, в зависимости от географического местоположения, местности и бизнес-моде-ли производителя.

Логистическому оператору для общих этапов «точки считывания», скорее придется иметь дело с автомобилями разных производителей — через хранилища и распределительные пункты, управляемые разными операторами и порты, как отправляющие, так и принимающие. Следовательно, существенным преимуществом является то, что определение данных и управление ими стандартизированы.

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

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

• 5.3 Системная архитектура данных высокого уровня

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

Независимо от того, где находится исследователь в системе распределения, он должен знать следующее:

• а) тип однозначного идентификационного кода;

• б) однозначную идентификацию автомобиля;

• в) день/дату/время сбора данных;

• г) географические координаты автомобиля на момент сбора данных;

• д) «тип» места, который определяет характер деятельности в этом месте;

• е) код транспортного статуса;

• ж) определение статуса (готов ли автомобиль к следующему этапу обработки).

Также полезно при интерпретации этих данных иметь однозначное «имя» для точки опроса. Однако, в то время как перечисления а)—е) являются важными данными, система будет работать без типа местоположения, кода транспортного статуса или определения статуса, поэтому эти компоненты являются «необязательными», но рекомендуются.

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

• а) осуществлять поиск по автомобилю;

• б) определить его текущее местоположение;

• в) определить историю его движения;

• г) определить его состояние через систему на сегодняшний день.

В таблице Г.2 приведен пример того, как производитель может отобразить запись для отдельного автомобиля, используя данные, определенные в настоящем стандарте.

• 5.4 Архитектура данных
  
  5.4.1 Концепция

  Архитектура данных была определена с точки зрения самого высокого уровня с целью:

• - минимизировать количество и сложность понятий данных и составляющих их элементов;

• - обеспечить объективность для хранилищ данных;

• - упростить транзитные операции с данными;

• - включить реализации конкретных реализаций без ущерба для взаимодействия данных;

• - избегать разных требований к данным (и определений) в разных «точках считывания» цепочки поставок.

В рамках настоящего стандарта семантика концепции данных должна соответствовать принципам по [5]. Синтаксис концепции данных должен быть определен и представлен с использованием АСН.1 (см. приложение А) по ГОСТ Р ИСО/МЭК 8824-1, ГОСТ Р ИСО/МЭК 8824-2, ГОСТ Р ИСО/МЭК 8824-3, ГОСТ Р ИСО/МЭК 8824-4, ГОСТ Р ИСО/МЭК 8825-1, ГОСТ Р ИСО/МЭК 8825-2, ГОСТ Р ИСО/МЭК 8825-3, ГОСТ Р ИСО/МЭК 8825-4, ГОСТ Р ИСО/МЭК 8825-5, ГОСТ Р ИСО/МЭК 8825-6.

Примечание — Согласно [6] в стандартах ИСО все данные должны быть указаны в единообразном формате, а АСН.1 — в выбранном формате, поскольку она является краткой и однозначной. Однако это не означает, что данные всегда должны представляться/передаваться другим сторонам с использованием АСН.1. Данные, для которых существует определение АСН.1, легко конвертируются в XML, UBL, UN/EDIFACT и т. д. в зависимости от среды, по которой они передаются, и стандартов приложений конечного пользователя, которым они соответствуют.

Упрощенная архитектура данных определяется как совокупный домен AutomotiveMovementRecord и должна содержать две основные концепции данных:

• а) автомобильный идентификатор, который однозначно идентифицирует отслеживаемую автомобильную единицу;

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

На рисунке 3 представлен обзор структуры данных.

Рисунок 3 — Обзор структуры данных

• 5.5 Определения концепции данных
  
  5.5.1 Автомобильный идентификатор

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

Есть два варианта для автомобильного идентификатора, предпочтение отдается транспортному средству. Если VIN хорошо виден, он всегда должен использоваться в качестве «автомобильного идентификатора», а не внутреннего автомобильного кода.

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

Эта идентификация отслеживания дополняет и не заменяет никакую транспортную документацию ODETTE/JAIF/AIAG.

Автомобильный идентификатор должен быть определен bASN.1 как:

Automotive18495ldentifier CHOICE { vin Vehicle-vin, Automotive18495-domesticCode, }

• 5.5.1.1 VIN автомобиля

Элемент данных вагона-автомобиля — Vehicle-vin UTF8String (17): VIN автомобиля, выраженный в виде строки символов — уникальный; идентификатор для транспортного средства по [1], [2]; определение в кодировке по [7], [8]; схема вагона-автомобиля.

• 5.5.1.2 Регистрационный номер автомобиля

Концепция элементов данных, относящихся к регистрационному номеру автомобиля, должна определяться как последовательность АСН.1 из 5 элементов данных: Automotive18495-domesticCode :: = SEQUENCE { startcompanyidentifier UTF8String(1 ),3f — ?

companyCode UTF8String(3), — 3-значный или символьный код компании

— создание внутреннего кода endCompanyldentifier UTF8String(1), — ?

domesticCode UTF8String(9) — внутренний код, сгенерированный компанией

endDomesticCode UTF8String(1 ),25 — %

}

— пример? MOR? 123abc789%

• 5.5.2 Регистрируемые параметры движения автомобиля

Регистрируемые параметры движения автомобиля — это концепция данных, включающая восемь элементов данных, семь из которых являются простыми элементами, а один — совокупным элементом из 10 подэлементов. Регистрируемые параметры движения автомобиля должны быть определены в АСН.1 как:

ISO-18495-1 DEFINITIONS AUTOMATIC TAGS::= BEGIN automotive18495Event::= SEQUENCE { id Automotivel 8495ldentifier, — Automotivel 8495—идентификатор utcTime DATE-TIME, --Automotivel8495Event—время UTC

localTime VisibleString (SIZE(18..21)), — Automotivel8495Event—местное время location Location 18495, —Automotivel 8495Event—местоположение

locType INTEGER (0..99) OPTIONAL, —Automotivel8495Event—тип данных местоположения locDesc UTF8String (1..10) OPTIONAL, —Automotivel8495Event—описание местоположения unece-tsc INTEGER (0..999) OPTIONAL, —Automotivel8495Event—код ЕЭК ООН statusDefinition BOOLEAN OPTIONAL, —Automotivel 8495Event—определение статуса }

Automotivel8495ldentifier CHOICE {

vin VisibleString (SIZE (17)), — VIN транспортного средства

domestic VisibleString (SIZE (15)), —Automotivel8495—регистрационный номер

}

GeoLocation3D::= SEQUENCE {

lat INTEGER (-900000000..900000001), — GeoLocation—географическая широта

Ion INTEGER (-1800000000.. 1800000001), — GeoLocation—географическая долгота }

END

Приложение А (справочное)

Модули АСН.1 для концепций данных, определенных в настоящем стандарте

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

Примечание — Особенно полезным новым приложением АСН.1 является международный стандарт, который определяет формат двоичной кодировки для информационного набора XML (XML Infoset) в качестве альтернативы формату документа XML. Он призван обеспечить более эффективную сериализацию, чем текстовый формат XML.

На рисунках А.1 и А.2 представлены концепции уровня стандартов и использования данных.

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

Уровень 5 EDI, сетевые стандарты ТС 154, IEEE, ITU, ИСО/МЭК, JTC1...

Формат агрегации данных

Уровень 4 Стандарты слежения цепей поставок

ТС 204, SWG 7.3 Z

[3]

Данные о местоположении: долгота и широта

Рисунок А.2 — Концепция уровня данных транспортных средств в управлении цепями поставок для настоящего стандарта

Приложение Б (справочное)

Интерпретация номера VIN

Б.1 VIN автомобиля

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

VIN по [1], с кодом всемирного идентификатора производителя (WMI) по [2], определяет содержание и структуру идентификационного номера транспортного средства (VIN), чтобы установить во всем мире унифицированную форму системы идентификационной нумерации дорожных транспортных средств.

VIN состоит из трех разделов: первый — раздел идентификатора мирового производителя (WMI), второй — раздел дескриптора транспортного средства (VDS) и последний — раздел индикатора транспортного средства (VIS).

Б.2 Описание VIN

На рисунке Б.1 представлен образец VIN: 1G1FP22PXS2100001.

Рисунок Б.1 — Описание VIN

Б.З Интерпретация образца VIN

• 1 — страна, в которой он был произведен (1 США, 2 CAN);

G — производитель мотора («Дженерал Моторе»);

• 1 — производитель («Шевроле»);

• 2 — тип кузова (2 двери-купе хэтчбек);

• 2 — удерживающая система (ручные ремни (Driv + Pass надувные));

Р — код двигателя (5.7LV8 (LT1) (1993-настоящее время));

X — контрольная цифра (например, «X»);

S — модельный год (1995);

2 — сборочный завод (св. Тереза);

100001 —производственная последовательность.

VIN не используют букву «I» или «О», чтобы избежать путаницы с «1» и «0».

Приложение В (справочное)

Пример бизнес-процессов и рабочих процессов

В.1 Диаграмма прецедентов использования UML при описании бизнес-процесса

На рисунке В.1 приведен пример «варианта использования» для бизнес-процесса, связанного с настоящим стандартом, в представлении UML.

Примечание — Возможны и другие случаи использования в бизнесе.

Трансграничный перевозчик

Рисунок В.1 — Пример схемы использования бизнес-процесса международных автомобильных перевозок

• В.2 Диаграмма последовательности бизнес-процесса

На рисунке В.2 приведен пример бизнес-операций и действий, когда «Грузоотправитель» доставляет автомобили «Грузополучателю».

Рисунок В.2 — Пример бизнес-процесса

Рисунок В.З — Пример бизнес-процесса, включая электронную документацию

• В.З Рабочий процесс

На рисунке В.4 приведен пример рабочего процесса доставки автомобилей (новых или подержанных) от «Грузоотправителя» к «Грузополучателю».

Экспорт автомобильная перевозка

Импорт автомобильная перевозка

Трансграничный перевозчик

Рисунок В.4 — Пример рабочего процесса доставки автомобилей от «Грузоотправителя» к «Грузополучателю»

Примечание — Возможны и другие сценарии рабочего процесса.

Приложение Г (справочное)

Сектор описательной информации

Г.1 Сквозной административный процесс для примера логистики автомобильной дистрибуции

На рисунке Г.1 приведен пример сквозного административного процесса для автомобильной логистики распределения.

Рисунок Г.1 — Пример сквозного административного процесса для автомобильной логистики распределения

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

Таблица Г.1 — «Точки считывания» цепочки поставок автомобильной дистрибуции от пункта отправления до пункта назначения

Продолжение таблицы Г. 1

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

В таблице Г.1 описаны девять основных «точек считывания» цепочки поставок автомобильной дистрибуции, каждая из которых включает несколько подразделов «точки считывания» или действий, в которых может быть целесообразным сбор данных. Не все эти подпункты «точки считывания»/действия, присутствуют во всех физических экземплярах этой распределительной цепочки поставок, которые варьируются от одного производственного предприятия к другому, в зависимости от географического местоположения, местности и бизнес-модели производителя.

Столбец 2 таблицы Г.1 содержит аббревиатуру для каждой «точки считывания» и десятичную ссылку для каждой «точки считывания», столбец 3 указывает действие в этой «точке считывания», а столбец 4 предоставляет уникальный ссылочный код для вида действия.

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

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

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

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

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

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

Таким образом, эти концепции данных и архитектуры «точки считывания» предлагаются для использования в тех случаях, когда соответствующие субъекты считают это целесообразным, и в настоящем стандарте определены только общие «точки считывания» в цепочке поставок автомобильной дистрибуции.

В таблице Г.2 показан типичный пример записи в базе данных для транспортного средства в пути с использованием всех этапов «точек считывания» (см. таблицу 1).

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

Таблица Г.2 — Типичная запись в базе данных для автомобиля в пути (идентификатор автомобиля: 1G1FP22PXS2100001)

Продолжение таблицы Г 2

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

Из данных приведенных в таблице Г.2, следует, что: автомобиль 1G1FP22PXS2100001 покинул сборочную линию (в Японии) в 6:07 утра 26 июля 2012 года и был перемещен на готовую стоянку автомобилей, где он был припаркован в парковочном отсеке в 35.078117 137.124851 или до 8:00 утра того же дня. Складские проверки показали, что он оставался в этом месте на автомобильной стоянке в течение трех дней до 29 июля, когда его перевезли на терминал отправляющего порта, где он прошел таможенную очистку, припаркован в бухте терминала отправляющего порта до 1 августа, когда он был погружен на свое транспортирующее судно. На борту судна не было никакой записи, но он был высажен в точке 51.461711.0.352025 (Тилбери, Великобритания) 15 августа и переехал в приемный портовый терминал, где на момент запроса он находился в парковочном отсеке на 51.456545 0.368258.

Библиография

УДК 004.73:006.354

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

Редактор Д.А. Кожемяк Технический редактор В.Н. Прусакова Корректор Р.А. Ментова Компьютерная верстка И.А. Налейкиной

Сдано в набор 02.02.2022. Подписано в печать 16.02.2022. Формат 60х84¹/₈. Гарнитура Ариал. Усл. печ. л. 3,26. Уч.-изд. л. 2,64.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ «РСТ» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.