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

Ложечкин Александр Владимирович

МЕТОДЫ И СРЕДСТВА ИНТЕГРАЦИИ РАЗНОРОДНЫХИНФОРМАЦИОННЫХСИСТЕМ НА ЖЕЛЕЗНОДОРОЖНОМ ТРАНСПОРТЕ

Специальность 05.13.06 - Автоматизация и управление технологическими процессами и производствами (транспорт)

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата технических наук

Санкт-Петербург 2004

Работа выполнена в государственном образовательном учреждении

высшего профессионального образования «Петербургский государственный университет путей сообщения Министерства путей сообщения Российской Федерации».

Научный руководитель -Официальные оппоненты:

Ведущая организация -

доктор технических наук, профессор Яковлев Валентин Васильевич. Водяхо Александр Иванович, профессор, доктор технических наук Траньков Сергей Николаевич, доцент, кандидат технических наук ФГУП 'Типротранссигналсвязь"

Защита состоится «4» марта 2004 г. в 13:30 на заседании диссертационного совета Д218.008.02 при Петербургском государственном университете путей сообщения Министерства путей сообщения Российской Федерации по адресу: 190031, Санкт-Петербург, Московский пр., д. 9, ауд. 7-320.

С диссертацией можно ознакомиться в библиотеке университета. Автореферат разослан «4» февраля 2004 г.

Ученый секретарь диссертационного совета, кандидат технических наук, доцент

Культин В.Б.

Общая характеристика работы

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

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

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

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

• Несовместимость аппаратных и программных платформ, на которых построены интегрируемые системы;

• Несовместимость поддерживаемых ими протоколов доступа и форматов сообщений;

Несовместимость версий поддерживаемых стандартов обмена

информацией.

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

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

Предметом исследования в диссертации является задача последовательной увязки существующих АСУТП на железнодорожном транспорте, в частности систем автоматического управления процессом перевозок, по иерархическим уровням и интеграции их в единую систему сбора и обработки данных на базе предлагаемой структуры РСИ, основным принципом построения которой является выделение отдельного модуля ядра системы интеграции (ЯСИ).

Целью исследования является разработка методов построения РСИ для АСУ УПП на железнодорожном транспорте на основе предлагаемой структуры РСИ на базе ЯСИ.

В диссертации поставлены и решены следующие задачи:

• Выполнен анализ задачи интеграции АСУТП на транспорте, разбиение задачи на подзадачи и их классификация;

• Выполнен анализ и классификация проблем, возникающих при создании РСИ в транспортной отрасли;

• Разработана типовая структура РСИ для АСУТП на базе ЯСИ;

• Разработана методика создания РСИ на предлагаемой типовой структуре при решении .задачи интеграции АСУТП на транспортных предприятиях;

• Выработаны рекомендации по применению предлагаемого алгоритма решения задачи интеграции с использованием РСИ на базе ЯСИ для АСУТП на железнодорожном транспорте;

• Предложена методика расчета трудоемкости применения РСИ на базе ЯСИ.

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

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

• Предложена классификация подзадач и проблем, встающих перед разработчиками РСИ;

• Предложена типовая структура РСИ на базе ЯСИ для АСУТП на транспорте, разработана методика- определения параметров РСИ, требуемых для обеспечения заданного уровня качества обслуживания;

• Разработана методика сравнения и выбора программных продуктов верхнего уровня, используемых в качестве основы для построения РСИ;

• Разработана методика применения типовой структуры РСИ при решении задачи интеграции АСУТП;

• Предложена методика расчета трудоемкости применения типовой структуры РСИ на базе ЯСИ.

Практическая ценность диссертации состоит в применении предложенных методик построения РСИ на базе ЯСИ для решения задач интеграции АСУТП управления процессом перевозок ОАО РЖД. Создана система, интегрирующая между собой АСУТП «Модель процесса перевозок сетевая» (МППС) с ИС Государственного таможенного комитета (ГТК РФ) и ИС железных дорог Финляндии. В системе реализован обмен информацией о движении грузов через российско-финскую границу, требуемый для управления процессом перевозок, а также для решения задач планирования. Внедрение РСИ

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

Реализация результатов работы. Результаты исследований, полученные в диссертации, явились основой для проекта, осуществленного и внедренного в Главном Вычислительном Центре (ГВЦ) ОАО РЖД в 2000-2003 годах. Проект осуществлялся в составе работ по программе "TEDIM" (Telematics in Foreign Trade Logistics and Delivery Management - Телематика в логистике международной торговли и управлении поставками), включающих, в себя несколько проектов по разработке электронных решений в области международной торговли и логистики. Задача» проекта заключалась в автоматизации обмена документами при осуществлении экспортно-импортных операций между Российскими железными дорогами и дорогами Финляндии. Решение этой задачи позволяет увеличить скорость прохождения грузов через границу, снизить себестоимость перевозок и повысить эффективность управления транспортной отраслью на данном направлении' в целом. В указанной системе, перешедшей к данному моменту в промышленную эксплуатацию, РЖД, ГТК и финский грузооператор VR Cargo обмениваются железнодорожными накладными и таможенными разрешениями на перевозку. Разработанная РСИ реализует функции приема и обработки электронных документов в соответствии со схемой операциями экспорта и импорта, протоколирование выполняемых операций, обеспечение гарантированности доставки информации. Применение методики создания РСИ на базе ЯСИ, предложенной в диссертации, позволило создать и внедрить описанное решение в кратчайшие сроки.

Апробация работы. Основные положения диссертационной работы докладывались и обсуждались на таких конференциях, как:

• Международных научно-практических конференциях «Инфотранс» в 2002 и 2003 годах (Санкт-Петербург);

• Конференции «Платформа Microsoft» в 2001,2002 и 2003 годах (Москва);

• Конференция «Неделя науки в ПГУПС» в 2002 году (Санкт-Петербург);

• Семинары, проводимые компаниями Microsoft и Digital Design («Клуб архитекторов», «День разработчика» и др.) в Москве и Санкт-Петербурге. Публикации. Материалы диссертации опубликованы в 13 печатных

работах, а также в монографии автора диссертации.

Структура и объем работы. Диссертация состоит из введения, пяти частей и заключения. В приложении содержится список использованных источников. Общий объем работы 118 страниц, 30 иллюстраций, 7 таблиц.

Краткое содержание работы

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

Первый раздел посвящен детальному рассмотрению задачи разработки РСИ для АСУТП на транспорте. Вводится понятие «основной задачи: интеграции», производится обзор направлений задачи интеграции, классификация подзадач интеграции и анализ проблем, возникающих при их решении.

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

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

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

• Организации-перевозчики и собственники транспортной инфраструктуры (Российские и иностранные железные дороги, прочий сухопутный, водный и воздушный транспорт);

• Потребители транспортных услуг;

• Государственные организации (таможенные и пограничные службы);

• Прочие организации (посреднические организации и вспомогательные службы).

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

В данный момент часть этих документов пересылается по устаревшим каналам передачи данных (телекс, телеграф), часть, сообщений передается в бумажном виде, часть в электронном формате, но не соответствующем современным стандартам передачи данных. Все эти факторы существенно замедляют и усложняют процессы взаимодействия между организациями, участвующими в процессе перевозок. Для повышений эффективности взаимодействия существует возможность перевода части или всех видов коммуникаций на электронный способ передачи информации с использованием стандартов форматирования сообщений, таких, как используемые в Российских и иностранных железных дорогах и на транспорте стандартах EDI (Electronic Data Interchange): UN/EDIFACT и XI2, а также новых стандартах взаимодействия, основанных на стандарте XML (extensible Markup Language).

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

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

В работе выделяются 3 направления в области интеграции приложений (Таблица 1).

Таблица 1. Области интеграции приложений.

Область интеграции: Задача интеграции

Электронный обмен данными Создание РСИ, предоставляющей доступ к данным приложений в АСУ организации посредством открытых стандартов (EDIFACT, XML)

Промышленная интеграция • приложений Интеграция нескольких приложений! внутри организации между собой

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

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

учетом таких факторов, как необходимость обеспечения:

• Преобразований форматов сообщений 8 в связи с разнородностью используемых в АСУТП форматов сообщений;

• • Передачи информационных пакетов между разнородными каналами передачи информации, построенных на основе различных протоколов обмена данными;

• Треб) емого уровня качества передачи данных по существующим каналам передачи связи;

• Защи гы передаваемой информации от несанкционированного доступа;

• Управления реакцией на нештатные ситуации и контроля над производительностью системы;

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

В работе предложено разделить решение основной задачи интеграции на несколько уровней (Таблица 2).

Таблица 2. Уровни интеграции приложений.

Уровень интеграции Решаемые задачи;

Уровень интеграции процессов Обеспечение совместной работы процессов, автоматизированных в интегрируемых АСУ: ■ Синхронизация выполнения процессов- ■ • Транзакционность выполнения процессов.

Уровень интеграции приложений Обеспечение сопряжения различных архитектур и интерфейсов приложений: ■ Сетевая интеграция;: ■ Совместное управление; ■' Интеграция программных интерфейсов.

Уровень передачи: данных Обеспечение электронного обмена информацией. Этот класс задач решается с помощью класса приложений промежуточного слоя (middleware), так называемого МОМ-Message Oriented Middleware. С его помощью решаются задачи: ■ Обеспечение реализации обмена данными между участниками обмена один к одному, один ко многим, многие к одному, многие ко многим; ■1 Обеспечение гарантированности доставки сообщений; - ■ Обеспечение транзакционности передачи данных при разбиении посылки на несколько составляющих пакетов; •' Обеспечение доставки информации в режиме реального времени; ■ Обеспечение защиты передаваемой информации от несанкционированного доступа (НСД).

Уровень Предоставление доступа к данным, представленным в

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

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

■ Двоичное преобразование;

* Символьное преобразование;

* Преобразование форматов;

■ Смысловое преобразование;

_ ■ Криптографическое преобразование._

Помимо описанных выше уровней интеграции в работе также выделяется

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

Выполненный анализ задач, возникающих при разработке РСИ, позволил выявить независимость ряда задач, таких как задачи уровня интеграции процессов и приложений, от специфики интегрируемых АСУ ТП, что стало предпосылкой к созданию структуры РСИ на базе ЯСИ.

Второй раздел работы посвящен исследованию предлагаемой типовой структуры РСИ на базе ЯСИ, а также обоснованию преимуществ ее применения.

Принцип структуры на базе ЯСИ заключается в выделении подмножества задач интеграции • (Таблица 2) и решении их в отдельном модуле системы, называемом ЯСИ.

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

Протоколы

Типы • о сообщений"

АСУ ТП

Рисунок 1. Модель приложения АСУ ТП.

Приложение в АСУ ТП можно характеризовать в данной модели шкими параметрами, как:

• Количеством каналов передачи информации N ;

• Используемыми форматами сообщений в каналах

При этом под каналом передачи подразумевается - логический канал, позволяющий передать и/или получить сообщение определенного формата согласно используемому в канале протоколу. Среди» распространенных протоколов доступа к приложению можно выделить HTTP/S, FTP, DCOM, RMI, MSMQ, MQSeries и т.д. Под форматом сообщения понимается не только формат физического представления информации, но и используемый алфавит, а также семантическая структура сообщений (примеры форматов: SAP iDoc, XML, EDIFACTHTJ*.)

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

• РСИ многие-ко-многим (Рисунок 2). В этом методе интеграции приложения интегрируются каждое к каждому, то есть каждая связь между отдельными двумя приложениями осуществляется независимо от других.

• Используемыми протоколами передачи сообщений по каналам

и

РСИ на базе ЯСИ (Рисунок 3). В этом методе осуществляется интеграция каждого приложения с отдельным ядром; интеграции, внутри себя обеспечивающем передачу информации от одного приложения к другому.

Рисунок 3; Структура РСИ на базе ЯСИ."

В работе проведено сравнение указанных подходов. ЯСИ можно охарактеризовать тем же набором параметров модели, что и для приложения:

ЭД^ , (Т)я, • Очевидно, что количество входных каналов ЯСИ равно

сумме количества каналов у интегрируемых приложений:

(1)

п=1...М

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

Общее количество протоколов и форматов сообщений, которые необходимо реализовать в ЯСИ, зависит от коэффициента распространения того

или иного протокола и/или формата среди приложений рп:

где:

• №„с - количество приложений, использующих данный протокол или формат,

• прии - общее количество интегрируемых приложений.

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

Общее число связей при выборе РСИ на базе ЯСИ приложений равно:

(5)

Общее число связей при выборе РСИ многие-ко-многим равно:

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

использования РСИ на базе Я СИ вводятся следующие характеристики (их значения определяются экспертнб, применительно к конкретным условиям разработки и эксплуатации решения):

• С/? - оценка трудоемкости разработки модуля поддержки дополнительного формата сообщений;

• Ст - оценка трудоемкости разработки модуля поддержки дополнительного протокола;

• - оценка трудоемкости разработки ядра интеграции при выборе структуры РСИ на базе ЯСИ;

• - оценка трудоемкости разработки синхронизирующего центра-интеграции при выборе РСИ многие-ко-многим.

Единица измерения всех указанных характеристик трудоемкости условна и может определяться в зависимости от конкретных услоьий как человеко-месяц, человеко-день или как денежная единица. Таким образом, оценка общей" трудоемкости решения на базе ЯСИ определяется выражением

а для решения на базе структуры многие-ко-многим

Здесь С р и С т" - нормированные значения трудоемкости, приведенные к коэффициенту распространения форматов и протоколов среди всего множества форматов и протоколов:

Где л и у, - соответственно оценка трудоемкости разработки модуля поддержки /-того типа формата и протокола соответственно, т и / -

количество типов форматов сообщений и протоколов, - количество

входов, реализующих г-тый тип формата и протокола, N - общее число

интегрируемых входов в системе.

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

показанный на графике (Рисунок 4). Здесь показана ситуация £ Как

видно на графике, в этом случае трудоемкость использования типовой структуры РСИ на базе Я СИ становится ниже трудоемкости интеграции по модели многие-ко-многим при числе каналов в приложениях больше 6. Точка, в которой трудоемкость разработки модели многие-ко-многим становшся больше трудоемкости разработки решения с использованием ЯСИ, может меняться в сторону большего или меньшего числа интегрируемых приложений, но исходя из того, что функция (2) растет быстрее функции (1), такая точка всегда существует.

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

1 23456789 Количество каналов приложений

Рисунок 4. Оценка трудоемкости разработки решения в зависимости от количества каналов.

При использовании структуры РСИ на базе ЯСИ задачи интеграции делятся на четыре типа:

• Задачи интеграции процессов. Под этим понимаются задачи по обеспечению синхронизованиости и транзакционности выполнения технологических процессов по приложениям;

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

• Задачи управления движением сообщений между приложениями. А

именно управление маршрутизацией сообщений между приложениями, синхронизация процессов.

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

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

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

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

Разработанная методика оценки трудоемкости создания РСИ на базе ЯСИ и на базе структуры «многие-ко-многим» позволяет определять еще на начальных стадиях разработки менее трудоемкий метод.

В третьем разделе описывается методика выбора программного продукта верхнего уровня для реализации ЯСИ. В разделе предложен набор критериев для сравнения программных продуктов для реализации ЯСИ (Таблица 3).

Таблица 3. Критерии сравнения программных продуктов для реализации ЯСИ.

Платформа реализации (Windows, IBM, Sun и ДР-) Множество Экспертный

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

Стоимость лицензирования Численное Экспертный

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

1. Выбор актуального для создаваемого интеграционного решения набора критериев • Выбор критического (т.е. обязательного) набора

критериев

2. Определение актуальных и критически важных наборов значений критериев:

а. Для критериев со значением типа «Множество значений»

определяется множество актуальных значений

критически важных вариантов значений множестве критериев.

и множество

л;

-Л-JC » где П - индекс в

b. Для численных критериев определяется диапазоны значений

Pi

р:

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

и Вк.

3. Выбор продуктов для сравнения.

4. Выполнение экспертных оценок и заполнение таблицы сравнения дли критически важных критериев и вариантов значений, определение

значений

Л, » Pi > Pi для I

-того варианта продукта.

5. Отсеивание неподходящих по критическим критериям и вариантам значений вариантов продуктов для реализации.

6. Оценка на основания численных критериев и некритических критериев и вариантов значений.

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

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

В работе приведен базовый набор вариантов продукта для реализации интеграционного решения для принятия решения:

• Использование EDIFACT-сервера;

• Использование инфраструктуры IBM MQIntegrator;

• Использование инфраструктуры Microsoft BizTalk Server.

Проведен начальный; отбор вариантов и обоснована неэффективность использования EDIFACT-сервера в случае решения задачиЛ интеграции при наличии не только EDIFACT-сообщений (как и происходит при решении задачи интеграции в транспортной отрасли). Поскольку для транспортной отрасли наличие развитой технической поддержки производителя на всей территории Российской Федерации является: критическим критерием, фактически, в настоящее время выбор может производиться только из двух программных продуктов для интеграции:

• Использование инфраструктуры IBM MQIntegrator;

• Использование инфрастрз'ктуры Microsoft BizTalk Server.

В работе проведено сравнение этих вариантов по описанной выше методике в случае реализации интеграционного решения в МПС РФ и сделан вывод о преимуществе использования инфраструктуры Microsoft BizTalk Server.

В работе предложена методика создания интеграционного решения на основе ЯСИ на базе Microsoft BizTalk Server 2000/2002.

В четвертом разделе приведено описание методики расчета параметров ЯСИ для случая построения ядра интеграции на базе Microsoft BizTalk Server 2000, необходимых для обеспечения заданного качества обслуживания.

Основными параметрами, характеризующим качество обслуживания ЯСИ являются:

• Среднее время ожидания обслуживания сообщением ^ = t где У - время ожидания (как случайная величина);

• Вероятность ожидания обработки

• Вероятность занятости всех каналов в определенный момент времени ТС. В работе создана модель ЯСИ для расчета указанных параметров качества

обслуживания в зависимости от таких параметров, как:

• Число входных каналов обработки сообщений т;

• Производительность каждого из каналов обработки (количество сообщений в единицу времени) ;

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

• Система является системой с ожиданием. Для ЯСИ входная очередь сообщений является неотъемлемой частью системы;

• Все сообщения в очереди имеют равный приоритет;

• Каждое сообщение обрабатывается одним каналом, каждый канал в один момент времени обрабатывает одно сообщение;

• Поток заявок имеет распределение Пуассона с интенсивностью

• Длительность обработки сообщения в системе х имеет экспоненциальное

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

• Вероятность ожидания обработки

Р{у > 0}

Р{ у > f } = лё{пщ~х)1

Вероятность занятости всех каналов где

— вероятность незанятости всех каналов;

_ П

• Среднее время ожидания ^ ~ /?) *

Для расчетов модели в работе использовалась библиотека статистических функций Queueing ToolPak 4.0. На базе этой библиотеке разработан АРМ для расчета требуемых параметров ЯСИ, необходимых для достижения заданного уровня качества обслуживания (для двух случаев - упрощенного, с неограниченной длиной очереди и более сложного, с ограничением).

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

Пятый раздел посвящен описанию внедрения методики, описанной в диссертации на базе интеграционного решения, осуществленного в ГВЦ МПС РФ. Решение создано в составе работ по программе "TEDIM" (Telematics in Foreign Trade Logistics and Delivery Management - Телематика в логистике международной торговли и управлении поставками), включающая в себя несколько проектов по разработке электронных решений в области международной торговли и логистики. Цель программы "TEDIM" автоматизация обмена документами при осуществлении экспортно-импортных операций между транспортными, таможенными и торговыми организациями стран северной Европы.

МПС России принимает активное участие в этой программе. Задача описываемого проекта заключается в автоматизации обмена документами при

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

• ГВЦМПСРФ;

• Финская транспортная компания VR Cargo;

• Государственный таможенный комитет (ГТК) РФ. Организации обмениваются следующими документами:

• Железнодорожными накладными, оформляемыми отправляющей стороной;

• Таможенными разрешениями на перевозку, выдаваемыми органами ГТК РФ на основании информации в железнодорожной накладной.

Обмен документами между указанными организациями производится в соответствии с международным стандартом EDIFACT. Со стороны VR Cargo и таможенных органов используются специализированные EDIFACT-сервера. В ГВЦ МПС необходимая информация находится в системе МППС (Модель Перевозочного Процесса Сетевая). При операциях экспорта и импорта обмен документами организован по различным технологическим процессам (разные схемы маршрутизации документов).

ГВЦ МПС необходимо» обеспечить поддержку обмена EDIFACT-документами с финской стороной и органами ГТК РФ. Полученная информация должна передаваться в МППС. Все операции по пересылке сообщений и обработке должны протоколироваться. При обмене информацией используется следующая модель (Рисунок 5):

• Со стороны VR Cargo - железнодорожные накладные;

• Со стороны ГТК РФ - таможенные разрешения на перевозку;

• Со стороны ГВЦ МПС РФ - информация в системе МППС.

VR Cargo ГТК РФ

ГВЦ МПС РФ

Рисунок 5. Модель обмена информацией в интеграционном решении.

EDIFACT-сервер обеспечивает перемещение сообщений в формате EDIFACT в соответствии со схемой перемещения грузов из-за границы > ("операции Импорта") и перемещения груза из России за границу ("операции Экспорта"). В обоих случаях в процессе принимают участие три субъекта: ГВЦ МГТС, VR Cargo (Финляндия) и ГТК РФ.

Все субъекты - участники процесса обмениваются сообщениями, оформленными по стандартам EDIFACT. Разработанная система обеспечивает получение входящих сообщений, синтаксический' анализ, формирование выходящих сообщений и протоколирование процесса для последующего анализа. В качестве программного продукта для реализации ЯСИ используется Microsoft BizTalk Server 2000, выбранного по предлагаемой методике. Система реализует следующие функции:

• Прием и обработка документов в соответствии со схемой операции импорта;

• Прием и обработка документов в соответствии со схемой операции экспорта;

• Протоколирование выполняемых операций и возможность просмотра журнала;

• Повторная отправка сообщения, на которое не получена квитанция о доставке (обеспечение гарантированности доставки информации);

• Обмен сообщениями между партнерами с помощью электронной почты. Дистрибутив системы состоит из серверной и клиентской частей. Их

компоненты взаимодействуют друг с другом, используя протокол DCOM (Distributed Component Object Model).

Серверная часть включает в себя:

• ЯСИ на базе Microsoft BizTalk Server 2000;

• Тестовое приложение, используемое для проверки работоспособности системы, использовавшееся, в частности, для экспериментальной проверки результатов расчета требуемых для обеспечения заданного качества обслуживания параметров ЯСИ;

• Эмулятор обработки сообщений партнерами.

Клиентская часть включает в себя административный АРМ «Журнал событий», позволяющий просматривать журнал работы ЯСИ и выполнять повторную отправку требуемых документов. Документы от организаций-партнеров (VR Cargo и ГТК РФ) поступают в почтовые ящики или файловые каталоги системы. Обмен информацией с МППС происходит через механизм технологической почты на основе IBM MQSeries. Использование MQSeries позволяет обойти проблему организации межплатформенного взаимодействия (т.к. МППС функционирует на базе mainframe IBM) и обеспечивает гарантированность доставки информации путем дублирования отправки сообщений до получения подтверждения.

Применение методики, предложенной в диссертации, позволило реализовать описанное интеграционное решение в кратчайшие сроки.

Заключение

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

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

2. Разработана классификация задач и проблем, возникающих при разработке РСИ для АСУТП в железнодорожном транспорте, что позволяет ускорить процесс проектирования РСИ.

3. Впервые разработана типовая структура РСИ для АСУТП в транспортной отрасли, позволяющая решать задачи интеграции АСУТП с меньшими трудозатратами, чем существовавшие ранее методики. Разработана методика сравнения трудоемкости разработки РСИ с использованием предлагаемой структуры на базе ЯСИ и с использованием традиционной методики интеграции «многие-ко-многим».

4. Предложена методика разработки РСИ на базе ЯСИ, позволяющая значительно сокрагить трудоемкость проектирования систем интеграции для АСУТП при решении задач УПП за счет вынесения повторяющихся и независящих от стыкуемых АСУТП функций в отдельный модуль ЯСИ, а также существенно снизить количество ошибок проектирования за счет применения шаблонов проектирования.

5. Разработана методика сравнения и выбора программных продуктов верхнего уровня, применяемых в качестве основы для построения РСИ; в методике используется набор качественных и количественных характеристик программных продуктов, что позволяет осуществлять объективный выбор наиболее подходящего в каждом конкретном случае продукта.

6. Впервые в железнодорожной отрасли предложена методика определения параметров ЯСИ для интеграции АСУТП, необходимых для достижения заданного уровня качества обслуживания РСИ, что позволяет еще на этапе проектирования системы планировать необходимые затраты на аппаратные средства.

7. Разработанные методики создания РСИ на базе ЯСИ были использованы при создании проекта по интеграции АСУТП «МППС» в ГВЦ ОАО РЖД с ИС ГТК РФ и железными-дорогами-Финляндии, что позволило увеличить скорость прохождения грузов через границу, снизить себестоимость перевозок и повысить эффективность управления транспортной отраслью на данном направлении в целом.

Публикации по теме диссертации

1. А.В. Ложечкин. «Интеграция приложений для электронной коммерции с использованием Microsoft BizTalk Server 2000», 396 страниц, издательство «Русская редакция», Москва, 2002 год.

2. А.В. Ложечкин. «Использование Microsoft BizTalk Server 2000 для интеграции приложений и бизнес-процессов», журнал Byte, май 2001 года.

3. А.В. Ложечкин. «Технология Web Services», журнал «Открытые системы», ноябрь 2001 года.

4. А,В. Ложечкин. «Новые возможности Microsoft BizTalk Server 2002», журнал Byte, май 2002 года.

5. А.В. Ложечкин. «Использование сервера правил BizTalk Server при интеграции приложений», конференция «Платформа Microsoft», Москва, ноябрь 2003 (http://www.microsoft.ru/platform2004/reports/EAI-

04 BTS04Rules.ppt).

6. А.В. Ложечкин. «Использование Microsoft BizTalk Server для интеграции приложений», партнерский семинар Microsoft, Санкт-Петербург, ноябрь 2000 года (http://www.microsoft.com/rus/events/past).

7. А.В. Ложечкин. «Архитектура и разработка систем интеграции приложений», конференция Microsoft DevDays, Санкт-Петербург-Москва, декабрь 2000 года (http://www.microsoft.com/rus/events/past).

8. А.В. Ложечкин. «Разработка распределенных приложений», конференция Microsoft DevDays, Санкт-Петербург, октябрь 2001 года (http://www.microsoft.com/rus/events/past).

и

9. А.В. Ложечкии. «Возможности продукта Microsoft BizTalk Server 2002 для интеграции приложений», конференция Платформа Microsoft 2002, Москва, ноябрь 2001 года (http://www.microsoft.ru/platform2002).

10.А.В. Ложечкин. «Интеграция приложений», конференция «Неделя науки», ПГУПС, май 2002 года.

11. А.В. Ложечкин. «Протокол SOAP. Использование SOAP Toolkit». «Мир ПК», декабрь 2000 года.

12. А.В. Ложечкин. «Разработка приложений с использованием BizTalk Server». «Компьютер Пресс», сентябрь 2000 года.

13. А.В. Ложечкин. «Реализация архитектуры публикатор-подписчик на базе Microsoft BizTalk Server 2002», конференция Платформа Microsoft 2003, Москва, ноябрь 2002 года

(http://www.microsoft.ru/platform2003/schedule.asp).

14. А.В. Ложечкин. «Использование технологий Web Services для интеграции приложений», конференция «Представление Microsoft Windows 2003», Санкт-Петербург, май 2003 года

(http://www.microsoft.ro/microsoft20031aunch/reports.aspx?id:=2).

Печ.л. - 1,6

Формат 60x84 1\16

Подписано к печати 02.02.04г.

Печать - ризография. Бумага для множит, апп

Тираж 100 экз._Заказ № ЭЗ,_

Тип. ПГУПС

190031, С-Петербург, Московский пр. 9

»-41 17

Содержание.

Введение.

1. Актуальность задачи интеграции приложений, ее анализ и классификация подзадач.

1.1. Основная задача интеграции.

1.2. Актуальность задачи интеграции в транспортном комплексе

1.3. Анализ существующих подходов.

1.4. Направления интеграции приложений.

1.4.1. Электронный обмен данными.

1.4.2. Промышленная интеграция приложений.

1.4.3. Интеграция бизнес-процессов между организациями

1.5. Проблемы интеграции.

1.6. Классификация задач интеграции.

1.6.1. Уровни интеграции.

1.6.1.1. Уровень преобразования данных.

1.6.1.2. Уровень передачи данных.

1.6.1.3. Уровень интеграции приложений.

1.6.1.4. Уровень интеграции процессов.

1.6.1.5. Управление интеграционным решением.

В настоящее время развитие информационных технологий (ИТ) на железнодорожном транспорте достигло достаточно высокого уровня и это выражено в частности в таких формах информационных систем (ИС), как автоматизированные системы управления технологическими процессами (АСУТП) и производствами (АСУП), а также системы технической подготовкой производства (АСТПП). При этом, наряду с задачами автоматизации отдельных технологических процессов и производств, все острее встает проблема интеграции уже созданных и вновь создаваемых систем в единый информационный комплекс, который позволил бы повысить качество управления, и, как следствие, эффективность работы отрасли в целом [1].

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

При разработке систем АСУ приходится решать целый ряд проблем, вызванных разнородностью систем, а также различным временем их создания:

• Несовместимость аппаратных и программных платформ, на которых построены интегрируемые системы;

• Несовместимость поддерживаемых ими протоколов доступа и форматов сообщений;

• Несовместимость версий поддерживаемых стандартов обмена информацией.

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

В настоящее время существуют методики решения отдельных подзадач задачи интеграции приложений, таких как обеспечение гарантированности доставки и преобразование форматов сообщений, совместное администрирование и др. [2], [3], [4], но ни одна из существующих методик не рассматривает задачу интеграции приложений в комплексе. В связи с этим в транспортной отрасли встает необходимость создания комплексной методики создания распределенных систем интеграции (РСИ), обобщающей опыт построения систем интеграции приложений и позволяющей понизить трудоемкость их создания и повысить качественные показатели процесса проектирования [1].

Системы АСУТП, АСУП и АСТПП состоят в конечном итоге из отдельных приложений, под которыми понимаются средства для решения задач информационного обмена, работающих на различных программных и аппаратных платформах. Поэтому задачу интеграции АСУ можно считать задачей интеграции приложений, решению которой в применении к АСУТП управления процессом перевозок (УПП) посвящена данная работа. По прогнозам [5], [6] рынок систем интеграции приложений ожидает рост более чем на 200% в течение ближайшего десятилетия, что подтверждает актуальность выбранной темы.

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

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

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

Третий раздел работы посвящен описанию методики сравнения и выбора базовых программных продуктов для реализации ядра РСИ. Проведен анализ возможных критериев для сравнения, дано описание алгоритма сравнения и выбора продукта. Также в разделе приведены рекомендации по базовому набору критериев для реализации РСИ для интеграции АСУ на транспорте и проведен выбор базового продукта для реализации РСИ АСУ У1Ш со стандартами международного обмена информацией EDIFACT.

Дополнением к третьему разделу является «Приложение 1. Методика построения ядра интеграции», содержащее описание методики создания РСИ в случае применения для реализации ЯСИ выбранного базового программного продукта - Microsoft BizTalk Server 2000.

Четвертый раздел содержит описание методики расчета параметров ЯСИ, необходимых для обеспечения заданного уровня качества обслуживания РСИ. Приведено описание методики расчета числа каналов обработки сообщений ЯСИ и производительности каждого из каналов, необходимых для обеспечения заданного времени ожидания обработки каждым сообщением во входной очереди.

Дополнительно четвертый раздел содержит краткое описание и пример использования разработанного автоматизированного рабочего места (АРМ) для расчета параметров ЯСИ в зависимости от требуемых показателей уровня качества обслуживания.

В пятом разделе приведено описания внедрения предложенной в работе методики создания РСИ на базе ЯСИ для проекта, осуществленного и внедренного в Главном Вычислительном Центре (ГВЦ) ОАО РЖД в 2000-2003 годах. Проект осуществлялся в составе работ по программе "TEDIM" (Telematics in Foreign Trade Logistics and Delivery Management - Телематика в логистике международной торговли и управлении поставками [7]), включающая в себя несколько проектов по разработке электронных решений в области международной торговли и логистики. Задача проекта заключалась в автоматизации обмена документами при осуществлении экспортно-импортных операций между Российскими железными дорогами и дорогами Финляндии. Решение этой задачи позволяет увеличить скорость прохождения грузов через границу, снизить себестоимость перевозок и повысить эффективность управления транспортной отраслью на данном направлении в целом. В указанной системе, перешедшей к данному моменту в промышленную эксплуатацию, РЖД, ГТК и финский грузооператор VR Cargo обмениваются железнодорожными накладными и таможенными разрешениями на перевозку. Разработанная РСИ реализует функции приема и обработки электронных документов в соответствии со схемой операциями экспорта и импорта, протоколирование выполняемых операций, обеспечения гарантированности доставки информации. Применение методики создания РСИ на базе ЯСИ, предложенной в диссертации, позволило создать и внедрить описанное решение в кратчайшие сроки.

В заключении содержатся основные выводы, полученные в работе.

4.5 Выводы

В данном разделе предложена методика определения параметров ЯСИ для интеграции АСУТП, необходимых для достижения заданного уровня качества обслуживания РСИ, что позволяет еще на этапе проектирования системы планировать необходимые затраты на аппаратные средства.

5 Описание примера внедрения распределенной системы интеграции по предлагаемой методике

Пятый раздел посвящен описанию внедрения методики, описанной в диссертации на базе интеграционного решения, осуществленного в ГВЦ МПС РФ.

5.1 Цели и задачи проекта

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

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

• ГВЦ МПС РФ;

• Финская транспортная компания VR Cargo;

• Государственный таможенный комитет (ГТК) РФ. Организации обмениваются следующими документами:

• Железнодорожные накладные, оформляются отправляющей стороной;

• Таможенное разрешение на перевозку, выдается органами ГТК РФ на основании информации железнодорожной накладной.

Обмен документами между указанными организациями производится в соответствии с международным стандартом EDIFACT. Со стороны VR Cargo и таможенных органов используются специализированные EDIFACT-сервера. В ГВЦ МПС необходимая информация находится в системе МППС (Модель Перевозочного Процесса Сетевая). При операциях экспорта и импорта обмен документами организован по различным технологическим процессам (разные схемы маршрутизации документов).

Со стороны ГВЦ МПС было необходимо обеспечить поддержку обмена EDIFACT-документами с финской стороной и органами ГТК РФ. Полученная информация должна передаваться в МППС. Все операции по пересылке сообщений и обработке должны протоколироваться. При обмене информацией используется следующая модель (Рисунок 16):

• Со стороны VR Cargo - железнодорожные накладные;

• Со стороны ГТК РФ - таможенные разрешения на перевозку;

• Со стороны ГВЦ МПС РФ - информация в системе МППС.

Ш. €«Tg® ГТК РФ

ГВЦ МПС РФ

Рисунок 16. Модель обмена информацией в интеграционном решении.

EDIFACT-сервер обеспечивает перемещение сообщений в формате EDIFACT в соответствии со схемой перемещения грузов из-за границы ("операции Импорта") и перемещения груза из России за границу ("операции Экспорта"). В обоих случаях в процессе принимают участие три субъекта: ГВЦ МПС, VR Cargo (Финляндия) и ГТК РФ.

Все субъекты - участники процесса обмениваются сообщениями, оформленными по стандартам EDIFACT. Разработанная система обеспечивает получение входящих сообщений, синтаксический анализ, формирование выходящих сообщений и протоколирование процесса для последующего анализа. В качестве программного продукта для реализации ЯСИ используется Microsoft BizTalk Server 2000, выбранного по предлагаемой методике.

Система реализует следующие функции:

• Прием и обработка документов в соответствии со схемой операции импорта;

• Прием и обработка документов в соответствии со схемой операции экспорта;

• Протоколирование выполняемых операций и возможность просмотра журнала;

• Повторная отправка сообщения, на которое не получена квитанция о доставке (обеспечение гарантированности доставки информации);

• Обмен сообщениями между партнерами с помощью электронной почты.

Дистрибутив системы состоит из серверной и клиентской частей. Их компоненты взаимодействуют друг с другом, используя протокол DCOM (Distributed Component Object Model).

Серверная часть включает в себя:

• ЯСИ на базе Microsoft BizTalk Server 2000;

• Тестовое приложение, используемое для проверки работоспособности системы, использовавшейся, в частности для экспериментальной проверки результатов расчета требуемых для обеспечения заданного качества обслуживания параметров ЯСИ;

• Эмулятор обработки сообщений партнерами.

Клиентская часть включает в себя административный АРМ «Журнал событий», позволяющий просматривать журнал работы ЯСИ и выполнять повторную отправку требуемых документов. Документы от организаций-партнеров (VR Cargo и ГТК РФ) поступают в почтовые ящики или файловые каталоги системы. Обмен информацией с МППС происходит через механизм технологической почты на основе IBM MQSeries. Использование MQSeries позволяет обойти проблему организации межплатформенного взаимодействия (т.к. МППС функционирует на базе мэйнфрейма IBM) и обеспечивает гарантированность доставку информации путем дублирования отправки сообщений до получения подтверждения.

5.4 Описание решения

5.4.1 Архитектура системы

Архитектура системы с точки зрения обмена данными между системами партнеров (VR Cargo, ГТК РФ) и МППС (МПС) представлена на рисунке (Рисунок 17). Система взаимодействует с внешними отправителями/получателями сообщений только через выделенные почтовые ящики, а с системой на базе Mainframe - через разделяемые с клиентом MQSeries файловые каталоги. Для операций протоколирования и внутренних операций BTS используются базы данных Microsoft SQL Server 2000.

Ж Сшр» ГТК РФ 0

F=J 1 о t:: ■ f вер на оазе wm uiziaiK и ть buL berver

Обработка и журналирование сообщений

Г J. i

Ч. if it *

Рисунок 17. Архитектура системы.

5.4.2 Формат обрабатываемых сообщений

Обмен данными с финскими партнерами (VR Cargo) и ГТК РФ производится в формате EDIFACT. Система обрабатывает следующие сообщения:

• IFCSUM (Forwarding and consolidation summary message) -входящие и исходящие сообщения. Электронный аналог железнодорожных накладных.

• CUSRES (Customs response message) - входящее сообщение. Сообщение CUSRES является ответом ГТК на сообщение IFCSUM, содержит разрешение/запрет на перевозку, выданное таможней.

• CONTRL - входящие и исходящие сообщения. Служебное сообщение CONTRL является ответом на полученное от партнера сообщение формата EDIFACT. Сообщение CONTRL представляет собой уведомление отправителя о получении входящего сообщения, либо результатах синтаксического разбора входящего сообщения.

Обмен данными с МППС производится во внутреннем согласованном формате (позиционный текстовый файл).

5.4.3 Протоколирование

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

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

Для сохранения журнала используется две базы данных MS SQL Server: стандартная БД для протоколирования MS BizTalk Server и дополнительная БД.

5.5 Технологические процессы предметной области

Система поддерживает технологические процессы двух типов: операция «импорт» и операция «экспорт». Ниже представлены блок-схемы, содержащие алгоритмы работы обмена сообщениями в обоих случаях.

5.5.1 Операция импорт

На рисунке ниже (Рисунок 18) приведена схема перемещения сообщений IFCSUM для операции импорта.

5.5.2 Операция экспорт

На рисунке ниже (Рисунок 19) приведена схема перемещения сообщений IFCSUM для операции экспорта. о

•IFCSUM

I»---------CQNTRL(IFCSUM)—

410.Получкние сообщения IFCSUMa/ip ее ат груэоотлр ai отель i А

Грузоотгравител

I ь VRCargo

М^'РИи

420. Вюдной контроль IFCSUtol формиро< ание CONTRL(IFCSUIUJ

433. Отсылка сообщении CONTRLOFCSUm. адресат грузоотправитель

IFCSUM

4BQ. Отсылка сообщения IFCSUMaflpecar таможня грузополучателя

CUSRES 1 I CONTRL. (JFCSUIVp I

CONTRLpFCSUMf о

ЭДрнмнр мани»

470. Получение сообщении CONTRL(IFCSUtu) адресат, таможни rpyion случают я I А к

CUSRES (IFCSUM5 I I

4Э0. Оживание сообщения CUSRES(IFCSUHl. адресат таможня груюлолучателя CONTRL | (CUSRES}

XQ'RHI JHflBIIHNt

OUJ. ьздднои контроль

CUSRES (IFCSUH/Ц форми-ро| ание CONTRL IX U 5 RE S3

510. Отсылка сообщения CONTRL CCUS RE Si адресат, там ox ня груэоп олуч ател я

W3 Передача IFCSUM ,ЭГРЛН

530. Огсылк а со общ ен ия CUSRES. адресат, гдооогтлрак отель

5GQ. Формирояание сообщения для hitainframe иэ CUSRES

ЯС'Рнали ропни*

540. Ос и дан ие сообщения CONTRL (CUSRES), адресат г рухо отп pai иге ль ft едом-л ение по

570. Передача CUSRES» (Л infra me System

455. Форм сообще Mainframe ир о» ание ним для w IFCSUM

457. Перед * Mai г ача IFCSUM iframe Ж£'рна JHP0H НИ*:

Рисунок 18. Технологический процесс операции импорт.

Рисунок 19. Технологический процесс операции экспорт.

Заключение

Предметом исследования в диссертации является задача последовательной увязки существующих АСУТП на железнодорожном транспорте, в частности систем автоматического управления процессом перевозок, по иерархическим уровням и интеграции их в единую систему сбора и обработки данных на базе предлагаемой структуры РСИ, основным принципом построения которой является выделение отдельного модуля ядра системы интеграции (ЯСИ).

Целью исследования является разработка методов построения РСИ для АСУ УПП на железнодорожном транспорте на основе предлагаемой структуры РСИ на базе ЯСИ.

В диссертации поставлены и решены следующие задачи:

1. Выполнен анализ задачи интеграции АСУТП на транспорте, разбиение задачи на подзадачи и их классификация;

2. Выполнен анализ и классификация проблем, возникающих при создании РСИ в транспортной отрасли;

3. Разработана типовая структура РСИ для АСУТП на базе ЯСИ;

4. Разработана методика создания РСИ на предлагаемой типовой структуре при решении задачи интеграции АСУТП на транспортных предприятиях;

5. Выработаны рекомендации по применению предлагаемого алгоритма решения задачи интеграции с использованием РСИ на базе ЯСИ для АСУТП на железнодорожном транспорте;

6. Предложена методика расчета трудоемкости применения РСИ на базе ЯСИ.

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

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

1. Предложена классификация подзадач и проблем, встающих перед разработчиками РСИ;

2. Предложена типовая структура РСИ на базе ЯСИ для АСУТП на транспорте, разработана методика определения параметров РСИ, требуемых для обеспечения заданного уровня качества обслуживания;

3. Разработана методика сравнения и выбора программных продуктов верхнего уровня, используемых в качестве основы для построения РСИ;

4. Разработана методика применения типовой структуры РСИ при решении задачи интеграции АСУТП;

5. Предложена методика расчета трудоемкости применения типовой структуры РСИ на базе ЯСИ.

Практическая ценность диссертации состоит в применении предложенных методик построения РСИ на базе ЯСИ для решения задач интеграции АСУТП управления процессом перевозок ОАО РЖД. Создана система, интегрирующая между собой АСУТП «Модель процесса перевозок сетевая» (Mill 1С) с ИС Государственного таможенного комитета (ГТК РФ) и ИС железных дорог Финляндии. В системе реализован обмен информацией о движении грузов через российско-финскую границу, требуемый для управления процессом перевозок, а также для решения задач планирования. Внедрение РСИ на базе ЯСИ позволяет существенно повысить эффективность взаимодействия контрагентов, участвующих в процессе перевозок (РЖД и иностранных железных дорог, государственных органов, грузооператоров и т.д.) при информационном обмене РЖД с ИС сторонних организаций. Применение разработанных в диссертации методик позволяет сократить время разработки и внедрения РСИ.

Результаты исследований, полученные в диссертации, являлись основой для проекта, осуществленного и внедренного в Главном Вычислительном Центре (ГВЦ) ОАО РЖД в 2000-2003 годах. Проект осуществлялся в составе работ по программе "TEDIM", включающая в себя несколько проектов по разработке электронных решений в области международной торговли и логистики. Задача проекта заключалась в автоматизации обмена документами при осуществлении экспортноимпортных операций между Российскими железными дорогами и дорогами Финляндии. Решение этой задачи позволяет увеличить скорость прохождения грузов через границу, снизить себестоимость перевозок и повысить эффективность управления транспортной отраслью на данном направлении в целом. В указанной системе, перешедшей к данному моменту в промышленную эксплуатацию, РЖД, ГТК и финский грузооператор VR Cargo обмениваются железнодорожными накладными и таможенными разрешениями на перевозку. Разработанная РСИ реализует функции приема и обработки электронных документов в соответствии со схемой операциями экспорта и импорта, протоколирование выполняемых операций, обеспечения гарантированности доставки информации. Применение методики создания РСИ на базе ЯСИ, предложенной в диссертации, позволило создать и внедрить описанное решение в кратчайшие сроки.

Основные положения диссертационной работы докладывались и обсуждались на таких конференциях, как:

• Международных научно-практических конференциях «Инфотранс» в 2002 и 2003 годах (Санкт-Петербург);

• Конференции «Платформа Microsoft» в 2001, 2002 и 2003 годах (Москва);

• Конференция «Неделя науки в ПГУПС» в 2002 году (Санкт-Петербург);

• Семинары, проводимые компаниями Microsoft и Digital Design («Клуб архитекторов», «День разработчика» и др.) в Москве и Санкт-Петербурге.

Материалы диссертации опубликованы в 13 печатных работах, а также в монографии автора диссертации.

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

1. Показано, что существующие и применяемые в настоящее время методики создания РСИ для АСУТП не удовлетворяют требованиям по снижению трудоемкости разработки, выдвигаемым в транспортной отрасли по причине использования неэффективной структуры системы интеграции, основанной на принципе объединения АСУ «многие-ко-многим».

2. Разработана классификация задач и проблем, встающих при разработке РСИ для АСУТП в железнодорожном транспорте, что позволяет ускорить процесс проектирования РСИ. Выявлены общие и независящие от специфики интегрируемых АСУТП компоненты РСИ, что позволяет вынести решения ряда задач, решаемых в традиционной структуре РСИ «многие-ко-многим» в повторяющихся модулях в отдельный общий модуль ЯСИ.

3. Впервые разработана типовая структура РСИ для АСУТП в транспортной отрасли, позволяющая решать задачи интеграции АСУТП с меньшими трудозатратами, чем существовавшие ранее методики. Разработана методика сравнения трудоемкости разработки РСИ с использованием предлагаемой структуры на базе ЯСИ и с использованием традиционной методики интеграции «многие-ко-многим».

4. Предложена методика разработки РСИ на базе ЯСИ, позволяющая значительно сократить трудоемкость проектирования систем интеграции для АСУТП при решении задач УПП за счет вынесения повторяющихся и независящих от стыкуемых АСУТП функций в отдельный модуль ЯСИ, а также существенно снизить количество ошибок проектирования за счет применения шаблонов проектирования.

5. Разработана методика сравнения и выбора программных продуктов верхнего уровня, применяемых в качестве основы для построения РСИ; в методике используется набор качественных и количественных характеристик программных продуктов, что позволяет осуществлять объективный выбор наиболее подходящего в каждом конкретном случае продукта.

6. Впервые в железнодорожной отрасли предложена методика определения параметров ЯСИ для интеграции АСУТП, необходимых для достижения заданного уровня качества обслуживания РСИ, что позволяет еще на этапе проектирования системы планировать необходимые затраты на аппаратные средства.

7. Разработанные методики создания РСИ на базе ЯСИ были использованы при создании проекта по интеграции АСУТП «МППС» в ГВЦ ОАО РЖД с ИС ГТК РФ и железными дорогами Финляндии, что позволило увеличить скорость прохождения грузов через границу, снизить себестоимость перевозок и повысить эффективность управления транспортной отраслью на данном направлении в целом.

1. Транспортная стратегия Российской Федерации (одобрена на заседании Госсовета Российской Федерации 29 октября 2003 года), http://www.mps.m/documents/index.html?he id=749.

2. David S. Linthicum, «Next Generation Application Integration: From Simple Information to Web Services», Addison-Wesley, 2003.

3. James Fenner, Application integration techniques, http://www.cs.ucl.ac.uk/staff/W.Emmerich/lectures/3C05-02-03/aswe21-essay.pdf.

4. Eric Roch, Application Integration Business and Technology Trends, EAI Journal, August 2002,http ://www. eaij ournal. com/PDF/E AITrendsRoch.pdf.

5. Middleware and Businessware Market Forecast and Analysis Summary, 2001-2005, IDC Research,http://www.idc.com/getdoc.ihtml?containerld=28373.

6. The Emerging Digital Economy, April 1998 report of the United States Department of Commerce,http:// www.unc.edu/depts/j omc/academics/dri/011 /growth.html.

7. Ismo Makinen, TEDIM as a concrete tool in networking logistics, http://www.ntf-research.org/NTFhjemmeside/Konference241102/papers/The%20TEDIM-programme.pdf.

8. А.Календарев, Понятие XML/EDIM, http://edocs.al.ru/xmledi/xmledi.htm.

9. Sungchul Hang, Method-Oriented B2B Application Integration, http:// www.towson .edu/~shong/teaching/cosc643/1.

10. David S. Linthicum, Where Enterprise Aplication Integration Fits with Web Services, Softwaremag.com, April 2003, http://www.softwaremag.com/L.cfm?Doc=2003-April/WebServices.

11. H. Игнатович, IBM MQSeries: архитектура системы очередей сообщений, "Открытые Системы". #09-10/1999,http -.//www, citforum.ru/programming/digest/ibmmq s. shtml.

12. OASIS and RosettaNet Collaborate on Standards Development, http://xml.coverpages.org/OASIS-RosettaNet.html.

13. A.B. Ложечкин. «Интеграция приложений для электронной коммерции с использованием Microsoft BizTalk Server 2000», издательство «Русская редакция», Москва, 2002.

14. Microsoft Corp. "Enterprise Solution Patterns Using Microsoft .NET", Microsoft Press, 2003.

15. S. Sundblad, P. Sundblad "Designing for Scalability with Microsoft® Windows® DNA", Microsoft Press, 2000.

16. Л.Б. Миротин, Т.А. Прокофьева, О.М. Лопаткин, А.Г. Некрасов, Зарубежная практика создания и функционирования транспортных терминальных комплексов, Железнодорожный транспорт. 2003. -№7. - С.47-52.

17. Gray Т., Enterprise QoS Survival Guide: 1999 Edition, http://qos.internet2.edu/wg/documents.shtml.

18. Ермаков E.T., Опыт работ по разработке и внедрению автоматизированных систем для станций, http://pktb.css-mps.ru/publich/005.html.

19. Mark F. Creamer, Heterogeneous Computing Comes of Age, Enterprise Systems Journal,http://www.sengi.com/downloads/PDFDOCs/White Paper-Enterprise Article-EAI Middleware 6-00.pdf.

20. Steve Craggs, File transfer for the future. Using modern file transfer solutions as part of an EAI strategy, White Paper,http://www.eaiindustrv.org/docs/member%20docs/eai/File Transferfor the Future.pdf.

21. IDC, IDC Forecasts Worldwide CRM Application Revenues (2001), 10.10.2001, http://www.idc.com/software/press/pr/gsw081501pr.stm.

22. Hancen, M. Open middleware standards are redefining EAI and B2B intergration, Intelligent EAI, 25.10.2001, http://www.inteligenteai.eom/feature/Q 10810/featl 1 .shtml

23. McVey, S., Cundiff, R., The Essential Supply Chain, TechnologyEvaluation.COM, 25.10.01, http://www.intranetiournal.com/features/supplychain.html.

24. Hansen, M., Mamorsky, P. Java Connector Architecture: The feature of EAI, EAI Journal, May 15, 2001.

25. Correia, J., The Global Economic Impact on the Application Integration and Middleware Markets, Gartner Group, Aug. 8, 2001.

26. Pezzini, M., Thompson, J., Ten Golden Rules for Starting Application Integration, Gartner Group, Nov. 20, 2001.

27. IBM MQSeries Workflow, Concepts and Architecture, version 3.2, www.ibm.com/software/integration/mqfamilv/library/manualsa/fmcgO/f mcgOmst.htm.

28. MQSeries Family White Paper, June 1999, www.ibm.com/software/integration/support/supportpacs/individual/supp ortpacs/mqsecf.pdf.

29. Касаткин A.B, Реализация систем технологической почты на основе промежуточного ПО (middleware) различных производителей, Readme, №6,1998.

30. Ложечкин А.В., Средства и принципы построения систем интеграции гетерогенных информационных комплексов, Неделя науки-2002, СПб, ПГУПС, 2002 г., с. 367-368.

31. D. Linthicum, A Promising And Perhaps Model Standard, www.ebizq.net/topics/scm/features/1471 .html.

32. D. Linthicum Middleware Basics: Not As Basic As You Might Think, vvww.ebizq.net/topics/messagingmiddleware/features/2049.html.

33. John Schmidt, Transforming EAI from Art to Science, www.businessintegrationiournal.com/Department.asp?DepartmentID:=5.

34. А.А.Орлюк, А.Н.Ефимов, А.Е.Нартов, Электронный документооборот перевозочного процесса, "Автоматика, связь информатика", №11, 2002 г., http://pktb.css-mps.ru/publich/asi 11 02 ed.doc.

35. А.А.Орлюк, Г.Н.Баврин Система ДИСПАРК: функциональные возможности и эффективность, "Автоматика, связь информатика", №4, 2002 г., http://pktb.css-mps.ru/publich/asi4 02 Orluk.htm.

36. П.А.Козлов, Информатизация и автоматизация управления -приоритетное направление отрасли, "Автоматика, связь информатика", №4, 2000 г., http://pktb.css-mps.ru/publich/asi4 00Kozlov.htm.

37. А.А.Орлюк, А.Н.Крестинин, Проблемы разработки и внедрения автоматизированных систем, "Автоматика, связь информатика", №4, 2000 г., http://pktb.css-mps.ru/publich/asi4 00 Orluk.htm.

38. А.В. Ложечкин. «Использование Microsoft BizTalk Server 2000 для интеграции приложений и бизнес-процессов», журнал Byte, №5, 2001.

39. А.А.Орлюк, Создание программных продуктов в условиях МПС, http://pktb.css-mps.ru/publich/001 .html.

40. А.В.Крестинин, Перспективы применения электронного обмена данными в грузовых перевозках в международном сообщении, http://pktb.css-mps.ru/publich/004.html.

41. Яковлев В.В., Локальные сети персональных ЭВМ, Ч. 1.-СП6: ПГУПС. 1993.

42. Д.А. Милованцев, Ю.А. Фонтанов, В.Г. Воронин, Информатизация государственных служб в период построения глобального информационного общества, Электросвязь. №7, 2003.

43. Н. Игнатович, IBM MQSeries: архитектура системы очередей сообщений, Открытые системы, #09-10/1999, http://www.citforum.ru/programming/digest/ibmmqs.shtml.

44. V. Narayan, Application integration environment for messaging/queuing model, Second International Symposium on Autonomous Decentralized Systems (ISADS'95),http://info.computer.org/proceedings/isads/7087/70870169abs.htm.

45. Rikard Land, Ivica Crnkovic, Software Systems Integration and Architectural Analysis A Case Study,http://csdl.computer.org/comp/proceedings/icsm/2003/1905/00/ 19050338abs.htm.

46. А.В. Ложечкин. «Технология Web Services», журнал «Открытые системы», №11, 2001.

47. Tommy Joseph, A Messaging-Based Architecture for Enterprise Application Integration, The Proceedings of 15th International Conference on Data Engineering,http://china.computer.org/proceedings/icde/0071/00710062abs.htm.

48. Steffen, Thomas, Modellierungsmethode zur Integration zwischenbetrieblicher Informationsfltisse, University of Paderborn, Paderborn 2002.http://gcc.upb.de/www/WI/WI2/wi2 Ht.nsf/L3KEY/e9f74b85337ea08cc 1256b670042b4ff?QpenDocument&TableRow=3.1.0#3.1.

49. Mark Davydov, Getting ERPs on the same page, Intelligent Enterprise, October 2000,http://www.intelligenteф.com/feature/2000/10/davydov0ct20■shtml.

50. Apex Technologies, Whitepaper on Enterprise Application Integration Technology, http://www.firstapex.eom/content/Pdfs/WP-EAI-l.Q.pdf.

51. John Williams, Keys to Enterprise Application Integration, The Proceeding of Technology of Object Oriented Languages and Systems (TOOLS),http://china.computer.org/proceedmgs/tools/0774/07740399.pdf.

52. A.B. Ложечкин. «Новые возможности Microsoft BizTalk Server 2002», журнал Byte, №5, 2002.

53. A.B. Ложечкин. «Протокол SOAP. Использование SOAP Toolkit». «Мир ПК», №12, 2000.

54. A.B. Ложечкин. «Разработка приложений с использованием BizTalk Server». «Компьютер Пресс», №9, 2000.

55. Daniel Serain, Iain Craig. «Middleware and Enterprise Application Integration». Springer Verlag, 2002.