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


Интеллектуальная информационная система мониторинга (ИИСМ)


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

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

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

Прототип системы мониторинга) осуществляет взаимодействие систем через общий информационный ресурс – «Репозиторий событий» посредством стандартизованных WEB-сервисов и обеспечивает подтверждение из неизменяемого реестра блокчейн.

Взаимосвязь прототипа системы мониторинга с пользователями построена на использовании стандарта EPCIS для описания событий (EPC Information Services (EPCIS) Standard, Release 1.2, Ratified, Sep 2016):

  • EPCIS является стандартом GS1, который позволяет торговым партнерам обмениваться информацией о физическом движении и состоянии товаров, поддерживая 4 типа событий. Это помогает ответить на вопрос "что, где, когда и почему", чтобы удовлетворить потребительские и нормативные требования к точной и подробной информации о продукте.
  • EPCIS используется в сочетании GS1 Core Business Vocabulary (CBV). В CBV определяются значения данных, которые могут быть использованы для заполнения структуры данных по стандарту EPCIS.
  • EPCIS представляет собой набор стандартов интерфейса, один для сбора данных и один для запроса данных. Основной бизнес-словарь обеспечивает бизнес-контекст модели данных, предписанной в EPCIS.
  • Основной информационной единицей стандарта EPCIS является событие с объектом, идентифицированным ЕРС (Electronic Product Code).

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

  • 1. Сеть не включает технологии майнинга, чеканки, операций по расчётам или обмену криптовалют;
  • 2. Сеть не включает выпуск, оборот и гашение ценных бумаг;
  • 3. Сеть является приватной и обслуживает исключительно пользователей, зарегистрированных в ней и имеющих выданные центром сертификации (Certification Authority) сертификаты безопасности, осуществляющих операции в торговле, транспорте и логистике;
  • 4. Сеть реализуется на платформе Hyperledger Fabric 2.0, открытом программном обеспечении экосистемы Hyperledger;
  • 5. Оператором сети является ГП «Центр Систем Идентификации», он же осуществляет операции по регистрации пользователей и формирования всех необходимых крипто ресурсов для работы в сети;
  • 6. В рамках создаваемой сети пользовательская база распределена по определённым каналам. Предполагается на первом этапе создание логических каналов по отраслевому принципу. Данные реестров каждого канала недоступны для пользователей других каналов, если такая возможность не определена в криптографических ресурсах;
  • 7. Возможно создание логических каналов для конкретных крупных клиентов, к примеру, торговых сетей, в которых данные реестра изолированы от других пользователей сети;
  • 8. На каждом канале предполагается функционирование одного реестра;
  • 9. Работа с реестрами любого из каналов осуществляется исключительно с уровня умного контракта (Smart Contract или Chaincode в терминологии Hyperledger Fabric). Рядовые пользователи системы и их прикладные программные компоненты не имеют прямого доступа в реестр;
  • 10. Для «мягкого» входа в систему и технологической отработки новых решений, для клиентов предоставляется три типовых умных контракта, с достаточно широкими функциональными возможностями:
    • 1. Регистрация объекта контроля в реестре;
    • 2. Получение текущего состояния указанного объекта;
    • 3. Изменение текущего состояния объекта;
    • 4. Завершение операций по контролю объектов;
    • 5. Получение последовательного перечня транзакций с указанным объектом (трассировка перемещения и смена состояний);
    • 6. Проверка товара на контрафакт (отсутствие в реестре зафиксированных транзакций по бизнес-шагам «Маркировка» и «Отгрузка»);
    • 7. Подтверждение факта «Ввод в оборот» указанного объекта или объектов;
    • 8. Подтверждение факта «Товар не подлежит продаже» в случае нештатных ситуаций с объектом в процессе прохождения цепочки поставок, к примеру, диспозиция товара - товар повреждён, испорчен, товар утерян, зарезервирован, нет предыстории (попал в цепочку случайно или сознательно), товар отозван, выполнена процедура возврата товара, товар уничтожен;
    • 9. Подтверждение места происхождения товара;
    • 10. Указание факта «Объявлена аварийная ситуация» с последующим уведомлением о том, что авария устранена, и товар может далее двигаться по цепочке поставок.

Для работы с учётными системами предприятий реализованы необходимые web-сервисы Каждое обращение к сервисной службе получения или фиксации информации проходит процедуру аутентификации и отражается в системном журнале.

Сервисная служба системы содержит следующие сервисы:

  • 1. сервис аутентификации пользователей;
  • 2. сервис фиксации события с маркированным объектом в формате EPCIS документа;
  • 3. сервис предоставления по идентификационному ключу маркированного объекта реквизитов лицензиата ключа;
  • 4. сервис обнаружения локации объекта на момент запроса: локацию последней точки считывания, бизнес-шаг, диспозицию и другие мастер данные;
  • 5. сервис предоставления по идентификационному ключу маркированного объекта трассировки его перемещений (перечень реквизитов событий по всем бизнес-шагам цепочки поставки, которые прошёл объект);
  • 6. сервис просмотра по идентификационному ключу паллеты, групповой упаковки ее содержимого в указанной локации.
  • 7. сервис предоставления текущего состояния объекта из реестра блокчейн;
  • 8. сервис предоставления трассировки транзакций, зафиксированных в блокчейн для конкретного объекта или по указанной локации.

Прототип системы мониторинга содержит следующие компоненты:

  • КОМПОНЕНТЫ ЦЕНТРАЛЬНОГО УЗЛА СИСТЕМЫ
    • EPCIS-сервер с набором интерфейсов записи/чтения событий;
    • EPCIS-репозиторий и базу справочников;
    • личный кабинет пользователя;
    • мобильный АРМ фиксации событий и мониторинга.
  • СЕТЬ УЗЛОВ БЛОКЧЕЙН
    • Узлы одобрения транзакций (Endorsed peer’s)
    • Узлы очередизации транзакций в блоки (Orderer)
    • Узлы обновления реестра транзакций (Committing peer’s)
    • Реестр, включающий:
      • Базу состояний контролируемых объектов
      • Реестр блоков транзакций (блокчейн)



Реализуемая модель системы имеет условное наименование «Состояние товара». Существуют и другие модели интеграции технологий EPCIS и DLT/Blockchain, но их реализация зависит о конкретные пожелания клиентов и возможна в дальнейшем.

В модели «Состояние товара» содержание события не является единицей хранения и анализа в реестре блокчейн. События доступны в репозитарии EPCIS и на них строятся связанные данные (Linked Data). Модель ориентирована на обработку события на уровне Frontend DApp и фиксацию состояния объекта, возникающего при зафиксированном событии.

Далее Backend DApp компонент, включающий отдельные обработчики по каждому из состояний (функции умного контракта), выполняет все необходимые проверки, процедуру консенсуса и формирование транзакции в блокчейн, включающей код объекта (GTIN, LGTIN, SGTIN, SSCC) и цепочку зафиксированных и подтверждённых другими узлами состояний.

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


Структура модели «Состояние товара»

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

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



Центральный узел системы реализует стандарты GS1 Visibility Framework, EPCIS, CBV и имеет достаточно развитый административный набор компонент.

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

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

  • фиксацию информации, получаемой в реальном режиме времени от компонента фиксации событий EPCIS распределённом реестре, который размещён на том же узле;
  • работу по части формирования блоков транзакций в связке с объектами контроля и транзакциями;
  • шифрование и хеширование данных;
  • работу по алгоритму консенсуса, реализуемого на выбранной платформе блокчейн;
  • доступ к блокам реестра при запросах с уровня компонента DApp Frontend.

Программное обеспечение DApp Frontend обеспечивает интерфейсы работы участников системы с умным контрактом, данными в блокчейн, отрабатывая запросы, формируемые пользователями.

Сервисы Capture и Query обеспечивают работу с устройствами считывания RFID-меток или сканерами штриховых кодов и функции запросов в систему для получения информации по контролируемым объектам.

Репозитарий событий EPCIS обеспечивает хранение данных по событиям с контролируемыми объектами.

Реестр является основным элементом сети блокчейн, размещённым на всех узлах сети и содержащим цепочки блоков, в которых зафиксированы транзакции, ссылки на события в EPCIS. В блоки реестра помещаются транзакции, связанные с объектом и его состояния (общие и установленные при выполнении определённых бизнес-шагов в цепочке поставок как было изложено ранее).

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

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