Содержание к диссертации
Введение
1. Актуальность задачи интеграции приложений, ее анализ и классификация подзадач 14
1.1. Основная задача интеграции 15
1.2. Актуальность задачи интеграции в транспортном комплексе 16
1.3. Анализ существующих подходов 18
1.4. Направления интеграции приложений 18
1.4.1. Электронный обмен данными 19
1.4.2. Промышленная интеграция приложений 20
1.4.3. Интеграция бизнес-процессов между организациями 22
1.5. Проблемы интеграции 23
1.6. Классификация задач интеграции 24
1.6.1. Уровни интеграции 27
1.6.1.1. Уровень преобразования данных 27
1.6.1.2. Уровень передачи данных 28
1.6.1.3. Уровень интеграции приложений 30
1.6.1.4. Уровень интеграции процессов 31
1.6.1.5. Управление интеграционным решением 31
1.7. Заключение 33
2. Типовая архитектура распределенной системы интеграции на базе ядра интеграции и методика ее применения 34
2.1. Основной принцип построения РСИ на базе ЯСИ 34
2.2. Обоснование выбора структуры РСИ на базе ЯСИ 35
2.2.1. Математическая модель РСИ 35
2.2.2. Варианты построения структуры РСИ 36
2.2.3. Сравнение подходов к построению РСИ 38
2.2.4. Оценка и сравнение трудоемкости разработки 40
2.2.5. Зависимость трудоемкости от числа интегрируемых приложений 42
2.3. Описание структуры РСИ на базе ЯСИ 43
2.3.1. Модель РСИ 43
2.3.1.1. Организация 44
2.3.1.2. Система интеграции 44
2.3.1.3. Приложение 45
2.3.1.4. Состояние системы 45
2.3.1.5. Связь сущностей 46
2.3.1.6. Процессы 48
2.4. Транзакции 51
2.4.1. Короткоживущие транзакции 51
2.4.2. Обеспечение механизма транзакций 53
2.4.3. Долгоживущие транзакции 56
2.4.4. Алгоритм осуществления долгоживущих транзакций 57
2.4.5. Транзакционное выполнение процессов 59
2.5. Задачи ЯСИ 62
2.6. Заключение 63
3. Методика сравнения и выбора базовых программных продуктов для реализации ядра системы интеграции 64
3.1. Критерии сравнения программных продуктов для реализации ЯСИ 64
3.2. Алгоритм сравнения и выбора продукта 67
3.3. Анализ возможных вариантов выбора в текущих условиях 69
3.3.1. Использование EDIFACT-сервера 69
3.3.2. Использование самостоятельно-разработанного решения 70
3.3.3. Использование инфраструктуры IBM MQIntegrator 71
3.3.4. Использование инфраструктуры Microsoft BizTalk Server 72
3.4. Технологии интеграции 73
3.4.1 XML 73
3.4.1.1. Структура XML-документа 73
3.4.1.2. Доступ к XML-документу 75
3.4.1.3. Операции над документом 76
3.4.2. Протоколы доступа к приложениям 77
3.4.3. Синхронный и асинхронный вызов 80
3.4.4. Доступ к данным 80
3.4.4.1. Файловое хранилище 81
3.4.4.2. Реляционные базы данных 81
3.4.4.3. Иерархические хранилища 81
3.5. Сравнение платформ реализации системы электронного обмена данными 82
3.4 Выводы 87
4. Методика расчета параметров ядра системы интеграции для обеспечения заданного уровня качества обслуживания 88
4.1. Качество обслуживания ЯСИ 88
4.2. Модель ЯСИ 89
4.3. Расчет параметров качества обслуживания 90
4.4 Проверка предлагаемого метода расчета 92
4.5 Выводы 92
5 Описание примера внедрения распределенной системы интеграции по предлагаемой методике 93
5.1 Цели и задачи проекта 93
5.4 Описание решения 97
5.4.1 Архитектура системы 97
5.4.2 Формат обрабатываемых сообщений 98
5.4.3 Протоколирование 99
5.5 Технологические процессы предметной области 99
5.5.1 Операция импорт 100
5.5.2 Операция экспорт 100
5.6 Заключение 103
Заключение 104
Список использованной литературы 111
- Актуальность задачи интеграции в транспортном комплексе
- Оценка и сравнение трудоемкости разработки
- Критерии сравнения программных продуктов для реализации ЯСИ
- Расчет параметров качества обслуживания
Введение к работе
В настоящее время развитие информационных технологий (ИТ) на железнодорожном транспорте достигло достаточно высокого уровня и это выражено в частности в таких формах информационных систем (ИС), как автоматизированные системы управления технологическими процессами (АСУТП) и производствами (АСУП), а также системы технической подготовкой производства (АСТПП). При этом, наряду с задачами автоматизации отдельных технологических процессов и производств, все острее встает проблема интеграции уже созданных и вновь создаваемых систем в единый информационный комплекс, который позволил бы повысить качество управления, и, как следствие, эффективность работы отрасли в целом [1].
Только путем последовательной увязки существующих систем управления по иерархическим уровням и интеграции их в единую систему сбора и обработки данных и оперативного управления можно повысить качество и эффективность всех звеньев, участвующих в процессах транспортировки грузов.
При разработке систем АСУ приходится решать целый ряд проблем, вызванных разнородностью систем, а также различным временем их создания:
Несовместимость аппаратных и программных платформ, на которых построены интегрируемые системы;
Несовместимость поддерживаемых ими протоколов доступа и форматов сообщений;
Несовместимость версий поддерживаемых стандартов обмена информацией.
На транспорте задача интеграции усложняется в связи с распределенным характером информационного комплекса отрасли и необходимостью обеспечение надежности передачи информации.
В настоящее время существуют методики решения отдельных подзадач задачи интеграции приложений, таких как обеспечение гарантированности доставки и преобразование форматов сообщений, совместное администрирование и др. [2], [3], [4], но ни одна из существующих методик не рассматривает задачу интефации приложений в комплексе. В связи с этим в транспортной отрасли встает необходимость создания комплексной методики создания распределенных систем интефации (РСИ), обобщающей опыт построения систем интефации приложений и позволяющей понизить трудоемкость их создания и повысить качественные показатели процесса проектирования [1].
Системы АСУТП, АСУП и АСТПП состоят в конечном итоге из отдельных приложений, под которыми понимаются средства для решения задач информационного обмена, работающих на различных программных и аппаратных платформах. Поэтому задачу интеграции АСУ можно считать задачей интеграции приложений, решению которой в применении к АСУТП управления процессом перевозок (УГШ) посвящена данная работа. По прогнозам [5], [6] рынок систем интеграции приложений ожидает рост более чем на 200% в течение ближайшего десятилетия, что подтверждает актуальность выбранной темы.
Первый раздел работы содержит анализ актуальности задачи интеграции АСУ и построения распределенных систем интеграции (РСИ) в транспортном комплексе. Дано определение задачи интеграции, приведена классификация и анализ направлений решения задачи интеграции, таких как электронный обмен данными, промышленная интеграция приложений, интеграция бизнес-процессов между организациями. Также в первом разделе предложена классификация подзадач, возникающих при разработке РСИ и проведен их анализ. Сделан вывод об актуальности проблемы интеграции АСУ и о необходимости разработки новой методики интеграции для случая интеграции большого числа приложений.
Второй раздел работы содержит описание предлагаемой структуры РСИ на базе ядра системы интеграции (ЯСИ), основной принцип построения которой заключается в выделении подзадач задачи интеграции, не зависящих от специфики интеграции с конкретной АСУ (таких как синхронизация процессов и маршрутизация сообщений) и решении их в отдельном модуле системы - ядре интеграции.
Помимо этого, второй раздел содержит описание методики расчета трудоемкости реализации РСИ на базе ЯСИ и сравнение предлагаемого подхода с традиционным, что позволяет определить предпочтительный подход в каждом конкретном случае решения задачи интеграции. В разделе подтверждается вывод о преимуществе структуры РСИ на базе ЯСИ при большом числе интегрируемых приложений или при наличии перспективы их роста.
Третий раздел работы посвящен описанию методики сравнения и выбора базовых программных продуктов для реализации ядра РСИ. Проведен анализ возможных критериев для сравнения, дано описание алгоритма сравнения и выбора продукта. Также в разделе приведены рекомендации по базовому набору критериев для реализации РСИ для интеграции АСУ на транспорте и проведен выбор базового продукта для реализации РСИ АСУ УПП со стандартами международного обмена информацией EDIFACT.
Дополнением к третьему разделу является «Приложение 1. Методика построения ядра интеграции», содержащее описание методики создания РСИ в случае применения для реализации ЯСИ выбранного базового программного продукта- Microsoft BizTalk Server
2000.
Четвертый раздел содержит описание методики расчета параметров ЯСИ, необходимых для обеспечения: заданного уровня качества обслуживания РСИ. Приведено описание методики расчета числа каналов обработки сообщений ЯСИ и производительности каждого из каналов, необходимых для обеспечения заданного времени ожидания обработки каждым сообщением во входной очереди.
Дополнительно четвертый раздел содержит краткое описание и пример использования разработанного автоматизированного рабочего места (АРМ) для расчета параметров ЯСИ в зависимости от требуемых показателей уровня качества обслуживания.
В пятом разделе приведено описания внедрения предложенной в работе методики создания РСИ на базе ЯСИ для проекта, осуществленного и внедренного в Главном Вычислительном Центре (ГВЦ) ОАО РЖД в 2000-2003 годах. Проект осуществлялся в составе работ по программе "TED1M" (Telematics in Foreign Trade Logistics and Delivery Management - Телематика в логистике международной торговли и управлении поставками [7]), включающая в себя несколько проектов по разработке электронных решений в области международной торговли и логистики. Задача проекта заключалась в автоматизации обмена документами при осуществлении экспортно-импортных операций между Российскими железными дорогами и дорогами Финляндии. Решение этой задачи позволяет увеличить скорость прохождения грузов через границу, снизить себестоимость перевозок и повысить эффективность управления транспортной отраслью на данном направлении в целом. В указанной системе, перешедшей к данному моменту в промышленную эксплуатацию, РЖД, ГТК и финский грузооператор VR Cargo обмениваются железнодорожными накладными и таможенными разрешениями на перевозку. Разработанная РСИ реализует функции приема и обработки электронных документов в соответствии со схемой операциями экспорта и импорта, протоколирование выполняемых операций, обеспечения гарантированности доставки информации. Применение методики создания РСИ на базе ЯСИ, предложенной в диссертации, позволило создать и внедрить описанное решение в кратчайшие сроки.
В заключении содержатся основные выводы, полученные в работе.
Актуальность задачи интеграции в транспортном комплексе
На уровне интеграции приложений решаются задачи сопряжения различных архитектур и программных интерфейсов приложений. На этом уровне решаются следующие задачи: Сетевая интеграция. Для обеспечения совместной работы приложений необходимо обеспечить распределенный доступ к программным интерфейсам интегрируемых приложений. Например, для интеграции приложений, работающих на базе мэйнфрейма IBM и на базе Intel-сервера необходимо обеспечить интеграцию сетевых протоколов семейства SNA и TCP/IP. Также необходимо обеспечить интеграцию систем безопасности. Совместное управление. Для совместной работы систем на базе различных программных и аппаратных архитектур необходима интеграция систем управления, например, каталогов пользователей, позволяющая ассоциировать учетные записи пользователей в разных системах между собой для передачи информации с однократной аутентификацией пользователя (single sign-on). Интеграция программных интерфейсов. Для совместной работы приложений необходимо обеспечить возможность распределенного вызова программных интерфейсов одной системы из другой. Следует учесть, что помимо синхронного доступа также существует и возможность асинхронного доступа к программным интерфейсам. На верхнем уровне интеграции приложений решаются задачи совместной работы процессов, автоматизированных с помощью интегрируемых приложений. Для реализации уровня интеграции процессов необходимо решить задачи: Синхронизации процессов. Для совместной работы нескольких процессов необходимо обеспечить их синхронизацию, то есть возможность обмена информацией в установленные моменты времени. Для этого можно использовать шаги управления ходом процесса, инициирующие (продолжающие) выполнение при получении синхронизирующего сообщения от внешней системы. Транзакционности выполнения. При интеграции процессов в некоторых случаях необходимо обеспечить транзакционность выполнения процессов. При наличии поддержки на нижних уровнях интеграции (доступа к данным, передачи данных и интеграции приложений) реализация уровня интеграции процессов становится независимой от интегрируемых приложений, что позволяет с помощью общего ядра выполнения процесса, решающего задачи синхронизации процессов и транзакционности, интегрировать процессы, выполняемые в гетерогенных системах. Управление интеграционным решением необходимо на всех уровнях сразу, поскольку при управлении интеграцией происходит управление всем решением и требуется сохранение непротиворечивости управляющего воздействия. Задачи управления можно разбить на несколько подзадач: Управление конфигурацией. Задача управления конфигурацией заключается в выработке и применении настроек входящих в интегрированную систему приложений. Управление инфраструктурой. Заключается в создании и поддержании в работоспособном состоянии инфраструктуры (аппаратного и базового программного обеспечения), на которой базируется интеграционное решение. Управление безопасностью. Поскольку в последнее время задача обеспечения безопасности информационных систем стала очень актуальной, ее стоит выделить из управления инфраструктурой в отдельную подзадачу. В управление безопасностью входит выработка и осуществление действий, направленных на защиту интегрированной информационной системы от несанкционированного доступа, а также от информационных атак. Мониторинг производительности. Заключается в измерении параметров производительности системы и выработке действий, направленных на обеспечение необходимых значений этих параметров. Мониторинг нештатных ситуаций. Заключается в оповещении и оперативном урегулировании всех нештатных ситуаций, возникающих во время работы интегрированной системы. Таким образом, проведенный анализ задач, возникающих при разработке РСИ, позволил выявить независимость ряда задач, таких как задачи уровня интеграции процессов и приложений, от специфики интегрируемых АСУ ТП, что является предпосылкой к созданию структуры РСИ на базе ЯСИ.
Оценка и сравнение трудоемкости разработки
Для обеспечения этих свойств транзакций в монолитных системах используется журнал транзакций, в который записываются точки начала и конца транзакции, а также все операции изменения состояния системы, произведенные внутри транзакции. Это позволяет при наличии системного сбоя обеспечить атомарность транзакции (при отсутствии записи о завершении транзакции отменить все изменения состояния системы и таким образом вернуть систему в состояние до начала транзакции).
Многокомпонентная система. При поддержке транзакций в многокомпонентных системах применение общего журнала для нескольких участвующих в транзакции систем невозможно, поскольку это потребовало бы существенно большего числа связей между системами, участвующими в транзакции, повысило бы сложно и, как следствие, понизило бы надежность всей системы.
Вместо этого в многокомпонентных системах используют так называемый протокол двухфазного подтверждения (two phase commit) транзакции, который позволяет осуществить составную транзакцию, отвечающую критериям, описанным выше, на базе нескольких транзакций в монолитных системах. Протокол двухфазного подтверждения требует наличия в каждой из входящих в составную транзакцию систем реализации интерфейса диспетчера ресурсов (resource manager), позволяющего: Начать подготовку к осуществлению транзакции. Результатом этой операции должно быть осуществление всех необходимых в данной системе подготовительных операций: проверки доступности необходимых данных, установки блокировок и т.д. Вызывающая сторона должны быть оповещена о результате этого действия булевой переменной, значение которой соответствует успешности данной операции. Осуществить транзакцию. Результатом этой операции является осуществление изменений состояния системы в соответствие с требуемыми в транзакции действиями. Вызывающая сторона должна быть оповещена о результатах действия также булевой переменной, значение которой показывает: удалось или нет осуществить требуемые изменения состояния. Если изменения удалось осуществить, требуемые блокировки не должны сниматься до операции подтверждения транзакции, изменения не должны быть видны извне транзакции (но это зависит от выбранного уровня изоляции). Если изменения не удалось осуществить система должна быть возвращена в состояние, в котором она была до начала транзакции. Откатить транзакцию. Результатом этой операции является возврат системы в состояние, предшествующее транзакции. Данная операция не может быть неуспешной. Подтвердить транзакцию. Данная операция может быть осуществлена только с успешно завершившейся транзакцией. Она снимает все блокировки с данных системы и делает их доступными извне транзакции. Данная операция не может быть неуспешной. Помимо диспетчера ресурсов, реализованного в каждой из участвующих в транзакции систем, необходимо наличие внешнего компонента, координирующего работу диспетчеров ресурсов. Этот компонент называется диспетчер транзакции (transaction manager). Его задачей является взаимодействие с диспетчерами ресурсов всех систем, участвующих в составной транзакции для реализации протокола двухфазного подтверждения транзакции. Перед началом транзакции диспетчер транзакции опрашивает диспетчеры ресурсов всех систем, входящий в транзакцию. При этом вызывается операция подготовки к транзакции, и транзакция начинается только в случае готовности всех систем начать ее. Следующим шагом диспетчер начинает транзакцию в каждой из систем (параллельно или последовательно): В случае последовательного осуществления транзакции к следующей системе диспетчер переходит только при получении положительного ответа об осуществлении операции от предыдущей системы, участвующей в транзакции. Если получен отрицательный ответ, выполнение транзакции прекращается, вызывается операция отката транзакции на всех системах, уже выполнивших ее и транзакция считается не выполненной. В случае параллельного выполнения транзакции при получении первого отрицательного результата откат транзакции должен быть осуществлен на всех системах, успешно выполнивших транзакцию. К третьему этапу осуществления составной транзакции диспетчер подходит только в случае успешного завершения транзакции на всех системах, в ней участвовавших. Этот этап заключается в вызове операции подтверждения транзакции на всех системах. Эта операция не может быть неуспешной (поскольку она заключается только в снятии блокировок) и после ее окончания транзакция считается успешно завершенной.
Существующий алгоритм обеспечения многокомпонентных транзакций обладает целым рядом существенных недостатков и ограничений, сужающих область его применения при интеграции гетерогенных распределенных информационных комплексов. Основным источником ограничений является необходимость блокировки данных на время осуществления транзакции во всех участвующих в ней системах. Это зачастую просто невозможно, так как при интеграции распределенных информационных комплексов каналы связи и алгоритмы взаимодействия (например, использование серверов очередей) не могут обеспечить малое время отклика и высокую скорость передачи. Также возможны ситуации, при которых временные промежутки, в течение которых распределенные системы могут взаимодействовать, ограничены (например, установка соединения по коммутируемым линиям), а протокол двухфазного подтверждения транзакции требует постоянного соединения между системой, участвующей в транзакции и диспетчером транзакции. Другим недостатком является невозможность окончания операции в одной системе до окончания операции во всех остальных.
Критерии сравнения программных продуктов для реализации ЯСИ
Продукт Microsoft BizTalk Server (в настоящее время доступна вторая версия продукта) предназначена для решения задач интеграции приложений и электронного обмена данными. Для решения этих задач в Microsoft BizTalk Server входят два основных модуля: BizTalk Messaging, предназначенный для интеграции с различными средствами и протоколами передачи сообщений (HTTP, SMTP, MSQM, MQSeries и т.д.), средствами работы со стандартами представления сообщений (UN/EDIFACT и XI2, XML, ebXML, RosettaNet, flat files и т.д.), средствами интеграции с приложениями (SAP/R3, Axapta, Lotus и т.д.), средствами преобразования и маршрутизации сообщений; BizTalk Orchestration, предназначенный для создания и управления бизнес-процессами взаимодействия приложений и организаций, участвующих в электронном обменом данными. Также в BizTalk Server входят вспомогательные модули, предназначенные для мониторинга и архивирования сообщений (BizTalk Document Tracking), быстрого развертывания приложений (SEED Wizard). В следующем разделе будет произведено сравнение двух платформ построения системы электронного обмена данными: IBM MQIntergrator и Microsoft BizTalk Server. Этот раздел содержит обзор используемых при интеграции приложений технологий. Прежде всего, речь пойдет о технологии, лежащей в основе всей электронной коммерции и особенно направления интеграции приложений — XML. Также важны технологии связи, позволяющие общаться приложениям удаленными друг от друга — HTTP, SMTP, MSMQ. Этот подраздел посвящен наиболее универсальному способу представления информации из существующих и распространенных в наше время. Язык XML одинаково воспринимается на различных программных и аппаратных платформах, что делает возможным его применение для интеграции приложений. XML-документ представляет собой множество вложенных элементов, каждый из которых может иметь атрибуты (Рисунок 13). Как видно, XML-документ представляет собой иерархическую структуру элементов и атрибутов. Каждый элемент может содержать в себе другие элементы и иметь атрибуты. У каждого элемента и атрибута есть имя. Начало элемента выделяется тегом вида Имя Элемента , конец тегом / Имя Элемента . Между этими двумя тегами находится содержимое элемента — другие элемент и/или произвольный текст. Перед закрывающей скобкой открывающего элемент тега могут находиться атрибуты, в формате Имя_Атрибута="Значение атрибута". Это и есть минимальное описание того, что такое XML. Естественно что, поскольку в XML нет обязательных атрибутов и элементов, необходимо средство описания структуры и содержимого XML-файлов, которое позволило бы наложить ограничение на документ, например, указать, какие элементы должны быть обязательно, какие у них должны быть атрибуты и каких типов должны быть значения. Такие стандарты существуют, широко распространены три версии - DTD, XDR, XSD. Процесс проверки документа на соответствие схеме (описанию) называется валидированием (validation). Процесс валидирования производится XML-парсером (parser) при прочтении документа. XML-парсер — это программная библиотека, позволяющая представить XML-документа в виде структур данных в памяти программы. Помимо стандарта на представление документа в файле, существует также и стандарт на интерфейс программной библиотеки доступа XML-файлу (парсера). Этот стандарт носит имя DOM (Document Object Model) и, также как и сам стандарт XML, и стандарты схем DTD и XSD и сопутствующие стандарты, обсуждается, утверждается и публикуется W3-консорциумом (www.w3c.org). Этот интерфейс реализуется XML-парсерами, коих существует огромное множество, для разных языков программирования, разных платформ и технологий. Самым распространенным XML-парсером на платформе Microsoft является Microsoft XML Parser. Парсер представляет XML-документ в памяти программы, как набор объектов, связанных между собой: документа, узлов, атрибутов. Также парсер позволяет осуществить вспомогательные операции над документом. За время существования XML вокруг него образовалось достаточно большое количество технологий, позволяющих осуществлять различные операции над его содержимым. Прежде всего, это, конечно, стандарт XSLT (Extensible Stylesheet Language Transformation), позволяющий с помощью XML-файла определенного формата описать преобразование XML-документов. Эта технология вначале своего существования использовалась для преобразования XML-файлов в HTML-код для отображения в экране браузера. Технология ее работы состоит в следующем: с помощью определенного синтаксиса описывается фрагмент исходного документа, и описывается, во что он должен превратиться в результате. Например, можно сказать, что элемент name value-"John"/ необходимо преобразовать в HTML-фрагмент p John /p , а можно указать необходимость преобразования всех элементов name в теги р /р с подстановкой в содержимое тега значения атрибута value. Пример файла с таким XSLT-преобразованием (Рисунок 14).
Расчет параметров качества обслуживания
Предметом исследования в диссертации является задача последовательной увязки существующих АСУТП на железнодорожном транспорте, в частности систем автоматического управления процессом перевозок, по иерархическим уровням и интеграции их в единую систему сбора и обработки данных на базе предлагаемой структуры РСИ, основным принципом построения которой является выделение отдельного модуля ядра системы интеграции (ЯСИ).
Целью исследования является разработка методов построения РСИ для АСУ УПП на железнодорожном транспорте на основе предлагаемой структуры РСИ на базе ЯСИ.
В диссертации поставлены и решены следующие задачи: 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. Разработана классификация задач и проблем, встающих при разработке РСИ для АСУТП в железнодорожном транспорте, что позволяет ускорить процесс проектирования РСИ. Выявлены общие и независящие от специфики интегрируемых АСУТП компоненты РСИ, что позволяет вынести решения ряда задач, решаемых в традиционной структуре РСИ «многие-коми огим» в повторяющихся модулях в отдельный общий модуль ЯСИ.
