Разработка программного обеспечения АРМ Экспедитора

На рисунке 2.1 Представлена общая схема интеграции АРМ грузоотправителя с системой АС Клиент УЗ.

 

 

Рисунок 2.1 - Схема интеграции АРМ  Экспедитора ХТЗ и системы  АС Клиент УЗ

 

2.1.1 Организация доступа  пользователей к системе АС  Клиент-УЗ

 

Доступ пользователей  к АС Клиент-УЗ осуществляется через  общую сеть Internet с использованием технологии Virtual Private Network (VPN).

IP-VPN – современная телекоммуникационная технология, позволяющая организовывать защищенные частные корпоративные сети, объединяющие отдельные локальные, расположенные в различных точках, зачастую на большом расстоянии друг от друга. При этом достигается высокое качество информационного обмена; совмещается гибкость и масштабируемость IP-сети с безопасностью и качеством частных сетей;  наблюдается высокая надежность сети.  Виртуальный канал позволяет связать территориально удаленные друг от друга офисы, филиалы, структурные подразделения и организовать несколько каналов связи, в том числе для доступа в Интернет. 

Для организации подключения  к АС Клиент-УЗ, рабочее место  пользователя должно быть подсоединено к общей сети Internet с пропускной способностью канала не менее 56 kBit/s.

 

2.1.2 Определение структуры, состава и формата реквизитов и атрибутов электронного перевозочного документа (ЭПД)

 

Система АС Клиент УЗ предусматривает  следующие варианты эксплуатации:

- работа в режиме  формирования и обработки электронных  данных перевозочных документов и подготовки бумажных перевозочных документов;

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

Таким образом, для интеграции предлагаемой системы АРМ Экспедиции грузов на ХТЗ  с системой АС Клиент-УЗ необходимо определить детальную структуру, состав и формат реквизитов и атрибутов электронного перевозочного документа.

Электронный документ разрабатывался соответственно примерному формату  электронного перевозочного документа, который применяется при перевозке грузов железнодорожным транспортом в внутреннем соединении, утвержденного Приказом Министерства инфраструктуры Украины от 22.04.2011 №61 «Об утверждении Примерного формата электронного перевозочного документа, который применяется при перевозке грузов железнодорожным транспортом в внутреннем соединении».

Анализируя в зависимости от этапа перевозки груза, на котором  создается электронный перевозочный документ, определяются такие его  состояния:

1. ЭПД, которое передается грузоотправителем.
2. ЭПД, который принято к перевозке.
3. ЭПД, который испытать изменения во время следования груза.
4. ЭПД, который прибыл на станцию назначения.
5. ЭПД, которое передается грузополучателем.
6. Раскредитованый ЭПД.

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

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

ЭПД состоит из электронных данных и ЭЦП. Электронные данные предоставляются  в тезисе document-data.  Состав электронных данных приведен ниже. ЭЦП в виде base64- сроки предоставляется в тезисе signature.

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

Структура, состав атрибутов и типы данных ЭПД приведенные в приложении Б.

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

2.1.3 Определение  электронных данных для создания электронного перевозочного документа

 

Каждый ЭПД содержит информацию, которая разрешает воссоздать все  состояния ЭПД:

- получить изменения, которые  были внесены на любом этапе  жизненного цикла;

-  проверить ЭЦП любой лица, которое вносило изменения в данных ЭПД.

Во время создания нового ЭПД  электронные данные должны содержать  тег OTPR из пространства имен, которое отвечает состоянию жизненного цикла ЭПД.  Соответствие стадий и пространств имен приведенное в таблице 2.1.

 

Таблица 2.1 -  Соответствие состояний и пространств имен

Состояние	Пространство  имен
ЭПД, которое передается грузоотправителем	Uz:rwc:document:project:1.1
ЭПД, который принято  к перевозке	Uz:rwc:document:accepted:1.1

 

Схемы, которые определяют форматы  тегов OTPR в соответствующих пространствах имен, приведенные в Приложении В.

Например, проект ЭПД может иметь  вид (рисунок 2.2):

Рисунок 2.2 – Фрагмент кода проекта электронного проездного документа в формате системы АС Клиент УЗ

 

2.1.4 Преобразования электронных данных ЭПД в последовательностьбайт для наложения или проверки электронной цифровой подписи (ЭЦП)

 

Для формирования последовательности байт для наложения или проверки ЭЦП электроне данные необходимо:

• представить в виде xml- документа, структура которого описана в Приложении Б;
• полученное xml- документ привести к канонической форме;
• документ в канонической форме превратить в массив байт с применением кодирования utf-8 в нормальной форме, согласно требованиям, указанным в стандарте W3C [4].

Процедура приведения xml-документа к канонической форме может отвечать спецификации требований консорциума w3c [5] . Кроме того xml- документ в канонической форме не должен содержать узлы таких типов:

• комментарий;
• декларация DOCTYPE;
• декларации DTD;
• пролог (<?xml ?>);
• текстовые узлы, которые состоят исключительно из пробельных символов.  К пробельным символам относятся символы:
• пробел (код 32);
• символ завершения сроки (код 10);
• символ табуляции (код 9).

Путем к тегу является список наименований тегов, которые  начинаются с OTPR , с символом “/”  в качестве разделителя.  Для определения  конкретного тега среди одноименных  тегов используется его порядковый номер, который необходимо указывать в квадратных скобках (рисунок 2.3).

 

Рисунок 2.3  – Обращение  к конкретному тегу CLIENT и VAGON c целью  внесения необходимых изменений  в документацию

 

 

2.1.5 Кодировка данных

 

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

Например, кодировка предусмотрена  для следующих значений атрибутов сущностей:

- вид клиента (клиентом  может являться как грузоотправитель, так и грузополучатель) и его  способы кодировки указаны в  таблице 2.2;

- тип скорости перевозки  груза (она может быть высокая,  грузовая и пассажирская) так же кодируется и это представлено в таблице 2.3;

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

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

 

Таблица 2.2 – Кодировка  возможных значений  клиента

ClientKind
Код	Наименования
1	грузоотправитель
2	грузополучатель

 

 

Таблица 2.3 – Кодировка  возможных значений  скорости передвижения состава

SpeedKind
Код	Наименования
1	большая
2	грузовая
3	пассажирская

Таблица 2.4 – Кодировка  возможных значений  необходимости  и вида охраны грузов

VOhrKind
Код	Наименования
1	Не предохранять груз
2	Предохранять груз
3	Предохранять груз по заявке грузоотправителя

 

 

 

2.2 Разработка мер для интеграции АРМ Экспедитора ХТЗ с внешней логистической системой ЭТРАН

 

В свою очередь, Российское  управление по железнодорожным перевозкам более десяти лет назад успешно  внедрило и эксплуатирует программное  обеспечение сходного назначения СФТО – проект ЭТРАН. Это программное обеспечение также  нацелено на решение задач обеспечения документного сопровождения грузов в электронном виде. В настоящий момент проект ЭТРАН обеспечивает информационную связь между транспортными компаниями России, Казахстана, Литвы и Финляндии.

Основные принципы работы системы ЭТРАН:

• создание системы на принципах централизации базы данных на сетевом уровне;
• уникальная идентификация клиентов (плательщиков), централизованное ведение единых лицевых счетов для расчета с клиентами во взаимодействии с ЕК АСУФР;
• создание и использование единого блока расчета тарифов и других платежей, исключение переборов/недоборов при расчете провозных платежей;
• освобождение товарных контор (агентов) от ввода информации заявок и перевозочных документов за счет передачи этой работы на грузоотправителя путем внедрения электронного обмена данными;
• создание технологии поддержки полного цикла от  регистрации и заключения договора с клиентами, приема заявки и оформления перевозочного документа, расчета за перевозки и контроля ритмичности доставки груза, раскредитования документов и выдачи грузов в пунктах назначения;
• многоцелевое использование базы данных заявок, в том числе смежными системами, для планирования и контроля работы в диапазоне от месячного периода до сменно-суточного, и текущего плана работы подразделений;
• формирование перевозочных документов на основе данных заявки путем их дополнения информацией о результатах погрузки – электронный документ первичен, а бумажные перевозочные документы – копия; переход на применение Электронной Цифровой Подписи;
• обеспечение уникальной нумерации перевозочных документов для всей территории железных дорог.

 

2.2.1 Организация обмена  данными между системами

 

Обмен информацией между  функциональными разделами системы ЭТРАН и приложениями конечных пользователей должен осуществляться методом репликаций баз данных, а также с помощью процедур чтения (записи) таблиц баз данных. Допускается обмен с использованием файлов данных определенной структуры, а также с помощью специализированных процедур ввода (вывода) информации через программные интерфейсы. В основу проектирования средств взаимодействия должна быть положена обработка данных в режиме реального времени с использованием протокола TCP/IP, архитектуры клиент-сервер,  сетей Интернета и Интранета, веб-технологии с центральной базой сетевого уровня.

Аппаратура связи должна обеспечивать виртуальное, прозрачное для приложений системы ЭТРАН IP-соединение. Допустимо использование любого типа подобного оборудования, например, того, которое используется при построении СПД отрасли, — маршрутизаторы фирмы «Cisco» и аппаратура фирмы «Siemens».

2.2.2 Требования  к аппаратным средствам, операционной  среде и способу подключения  компьютера,  подключаемого к  системе «ЭТРАН» с помощью технологии VIPnet.

Для подключения к  системе ЭТРАН и обеспечения  функционирования АРМ Экспедитора  ХТЗ необходимо располагать следующими вычислительными ресурсами:

• видеоподсистема с разрешением не менее 800х600;
• принтер формата А4;
• операционная система Windows 98 SE или Windows 2000;
• подключение к сети Интернет с эффективной скоростью работы с узлом доступа к системе ЭТРАН не менее 14 400 бит/сек;

Кроме того, следует  учесть, что ПО ViPNet Client может работать на IBM-совместимых компьютерах (стационарных или переносных) с модемом или сетевым адаптером со следующей рекомендуемой конфигурацией:

• процессор – не менее Pentium III;
• ОЗУ – не менее 512 Мбайт;
• свободное место на жестком диске – не менее 300 Мбайт;
• операционная система – Microsoft Windows 2000 (32 бит) SP4 с установленным обновлением системы безопасности KB835732 (локализация обновления обязательно должна соответствовать локализации ОС Windows), XP (32 бит), Server 2003 (32 бит)/Vista (32/64 бит), Server 2008 (32/64 бит), Windows 7 (32/64 бит), Server 2008 R2;
• на компьютере не должно быть установлено никаких других Персональных Сетевых Экранов (Firewall).