Доклад по междорожному обмену Добрый день, коллеги! Целью моего выступления является информирование вас о «Принципах организации междорожного обмена данными». Как вы все знаете, а кто не знает, тот после этого выступления узнает, что информирование соседней (или не соседней) дороги обеспечивает подготовку принимающей стороны к: приему поезда (вагонов, контейнеров и т.д.); планированию проведения с ним различных работ (продвижение по дороге до пункта назначения и его расформирования; сдачу его на следующую дорогу, порт, заграницу и т.д.); возможному информированию грузополучателя о доставке товара и т.д. Соответственно, основной функцией обмен информацией является планирование работ. Междорожный обмен может быть дальним (например, с.410 назначением на Калининградскую ж.д.) и ближним (между соседними дорогами при приеме/сдаче поездов). В настоящее время большая часть междорожного обмена строится на настроечных массивах НСИ, программах подготовки и передачи информации на стороне информатора и, естественно, программах приема и обработки поступившей информации на информируемой стороне. Однако есть часть, где определение необходимости передачи данных определяется непосредственно в самой программе формирования и передачи этих сведений (например, междорожный обмен сообщениями 4770 и 220 при приеме/сдаче поездов). Данная схема не несет некоего универсализма. К тому же, данный вид обмена не является максимально достаточным, т.к. каждый передаваемый «пакет» (сообщение, ряд сообщений) информации имеет конечную структуру и несет в себе определенный набор данных. Первым шагом по расширению объема передаваемой информации были разработаны и ведутся дополнительные таблицы MD_x_TEKN, содержащие данные дороги сдачи для использования на дороге приема. Соответственно, при обработке поступающих сообщений (4770, 220) данная информация используется, что накладывает свои ограничения и проблемы: возможное отсутствие записи в таблицы, проблемы при чтении и т.д. В дополнение к сказанному добавлю, что каждое входное сообщение имеет свои логический и форматный контроли, пусть в междорожном обмене они и ослаблены, и отдельными программами обработки и записи данных в БД. Так же в настоящее время нет практически никаких выходных документов, опираясь на которые можно было бы судить о подходе поезда, вагонов, локомотивов и т.д. В этом году в планах ПКТБ ЦКИ реализация междорожного обмена (только между дорогами РФ), построенного на обмене наборами данных, по структуре модельных областей (поездной, вагонной, контейнерной, отправочной, бригадной и локомотивной). В дальнейшем этот набор информации будет расширен передачей информации некоторых таблиц. Между АСОУП-2 соседних дорог по предстыковым и стыковым станциям по поездам, сдаваемым с одной дороги на другую, будет организован обмен информаций. Формирование и передача данных будет выполняться комплексом регламентированной выдачи информации АСОУП2 (далее КРВИ). Первое, уходим от дальнего информирования. Оно становится функцией, так называемого, ближнего информирования. С дороги сдачи на дорогу приема информация формируется и передается в объеме пакета, условно назовем их 3000, с.3ХХХ. Дополнительно с дороги, которой принадлежит стык, на соседнюю дорогу формируется с.220 (или его аналог). Пакет сообщений 3ХХХ и с.220 будет передаваться в связке. По поступлению пакета с.3ХХХ на дороге приема корректируются таблицы текущих данных, операция приема/сдачи фиксируется по приходу с.220, если стык принадлежит чужой дороге, или по сс.201, 202, 1042, 226, если стык «свой» (т.е. остается существующая технология учета операций приема/сдачи). Целевая схема организации потоков информации приведена на слайде. Формирование информации будет инициироваться входными сообщениями АСОУП: операции отправления/проследования предстыковой станции (станции определяются по НСИ КРВИ, аналог таблицы TN_MEJDOR): с.200 – сообщение об отправлении поезда; с.202 – сообщение о проследование поезда; с.226 – Сообщение о передвижении пассажирского поезда; с.1042 – сообщение об операциях с поездами и общих сведениях о них; операции изменения информации о поезде, при условии предварительно сформированного регламента: с.09 – корректировка данных ТГНЛ; с.19 – корректировка данных ТГНЛ пассажирского поезда; с.203 – расформирование поезда; с.204 – сообщение о временной остановке («бросании») и других задержках в продвижении поезда; с.208 – сообщение об объединении и разъединении составов поездов; с.209 – сообщение об изменении индекса поезда. операции изменения информации о локомотиве, при условии предварительно сформированного регламента: с.230 – об изменении состояния локомотива. операция сдачи поезда: с.200 – сообщение об отправлении поезда; с.202 – сообщение о проследование поезда; с.226 – Сообщение о передвижении пассажирского поезда; с.1042 – сообщение об операциях с поездами и общих сведениях о них; операция приема поезда (только формирование с.220): с.202 – сообщение о проследование поезда; с.201 – сообщение о прибытии поезда; с.226 – Сообщение о передвижении пассажирского поезда; с.1042 – сообщение об операциях с поездами и общих сведениях о них; Структура пакета Заголовок + пакет сообщений по поезду Заголовок имеет следующую структуру: <PFMM><4 пробела>, <дата и время>, <UNS>, <КД> <РЗ>. <дата и время> – дата и время формирования пакета (старт асинхронной обработки); <UNS> – условный номер входного сообщения, по которому сформирован пакет для передачи; <КД> – код дороги формирования; <РЗ> – резерв. В настоящее время РЗ=0. Структура пакета сообщений описана в документе «Информационное взаимодействие системы АСОУП-2 дорожного уровня с другими информационными системами»: Информация внутри пакета сгруппирована по объектам и операциям (см. рис.2.1). Рисунок 2.1 – Группировка по объектам и операциям Структура сообщений Одно сообщение содержит информацию по объекту по одной технологической операции с одной или более таблицами. В общем случае сообщение имеет следующую структуру: (:<КС> <кд> <время> : <префикс> <информация> : <префикс> <информация> : … : <префикс> <информация>:) где: <кс> – код сообщения; <кд> – код дороги формирования; <время> – время формирования сообщения; <префикс> – служебная информация; <информация> – ключевая информация для операций удаления и замены идентификатора объекта, информация по структуре строки передаваемой таблицы для операций вставки и изменения. Вот мы разобрались с формированием и передачей информации. Теперь поступившую информацию необходимо обработать и «уложить» в БД. Целевая схема обработки В целевой схеме организации междорожного обмена (после снятия с сопровождения комплекса АСОУП) пакет сообщений 3ХХХ поступает в общую входную очередь АСОУП-2, где должен быть обработан отдельным обработчиком входных сообщений. Для обеспечения последовательной корректировки таблиц текущих данных обработчик пакета сообщений 3ХХХ должен работать во взаимосвязи с основным обработчиком входных сообщений. При реализации целевой схемы, для обеспечения на дороге приема последовательной обработки пакета сообщений 3ХХХ по сдаче поезда и первых сообщений о проследовании, необходимо разработать механизм «задержки» сообщений о продвижении поезда (аналога в АСОУП). Целевая схема обработки пакета сообщений 3ХХХ приведена на рисунке 3.1 Рис.3.1 Целевая схема обработки пакета сообщений 3ХХХ Схема обработки пакета сообщений 3ХХХ формирования с.220 из АСОУП-2 и отказа от 4770(0) до начала До снятия с производственных полигонов комплекса АСОУП пакет сообщений 3ХХХ должен передаваться через отдельно организованную MQSeries очередь. На дороге приема регламент обработки входящих сообщений меняется в зависимости от принадлежности дорог иностранному государству: если одна из дорог принадлежит иностранному государству, то регламент обработки сообщений остается без изменений; если обе дороги принадлежат России, то по приходу пакета сообщений выполняются следующие действия: 1. пакет сообщений 3ХХХ помещается в отдельную MQSeries очередь с MessageId = <КД><UNS>, где <КД>(2 символа) – код дороги формирования; <UNS>(10 символов) – условный номер входного сообщения, по которому сформирован пакет для передачи; 2. формируется служебное сообщение 3003, формат сообщения приведен на слайде: 3. сообщение 3003 передается в АСОУП; 4. на промежуточном этапе (на этапе тестирования), идет роспись информации из сообщений 3ХХХ в таблицы MC_x_TEKC по принятой схеме. Обобщенная схема обработки пакета сообщений 3ХХХ приведена на рисунке 3.2. Рис.3.2 Схема обработки пакета сообщений 3ХХХ. Вот мы и разобрались с принципами обработки сообщений. Теперь обработанную информацию необходимо расписать по таблицам. Корректировка БД АСОУП-2 (до вывода из эксплуатации комплекса АСОУП) В зависимости от того является ли предстыковой, регламент делится на две части: станция стыковой или 4.1 Регламент по проследованию/отправлению поезда предстыковой станции: В АСОУП дороги приема данные из сообщений 4770, 220, 410 и т.п. расписываются по базе АСОУП, в АСОУП-2 дороги приема эти данные не передаются. По приходу сообщения 3003, в АСОУП дороги приема производится только форматный контроль, и обработка переходит в АСОУП-2. В синхронной задаче АСОУП-2, по полю MessageId (формируется на основе служебной фразы с.3003) из MQseries считывается пакет сообщений 3ХХХ и инициируется запись таблиц текущих данных и тематических таблиц АСОУП-2 данными из сообщений 3ХХХ, с пересчетом расчетных показателей. 4.2 Регламент по проследованию/отправлению поезда через стыковую станцию (до отказа от с.220): Так как заранее не известен порядок прихода в АСОУП сообщений 220, 3003 требуется реализовать два варианта обработки сообщений, а именно: а) Если первым в АСОУП поступает сообщение 220, то оно расписывается в базы АСОУП и АСОУП-2. После того как следом поступает сообщение 3003, необходимо откорректировать информацию на основе данных из пакета сообщений 3ХХХ, находящегося в очереди MQSeries, как в АСОУП-2 так и в АСОУП. б) В случае поступления первым сообщения 3003 должна быть произведена запись таблиц текущих данных и тематических таблиц АСОУП2 дороги приема данными из сообщений 3ХХХ. Сообщение 220 в базу данных АСОУП и АСОУП-2 не расписывается. Данная схема организации междорожного обмена позволяет: передавать гораздо больший объем информации с одной дороги на другую; изменять передаваемый набор данных без существенной корректировки ПО, ограничиваясь только изменениями в НСИ (набор передаваемой информации); осуществлять передачу сведений по всем объектам в составе поезда единой транзакцией. еще одним плюсом новой схемы можно назвать открытость настройки выдачи информации и контроль настроек. На этом у меня все. Спасибо за внимание. Если есть вопросы, готов на них ответить.